(57)【特許請求の範囲】
【請求項１】
放送信号を伝送する方法であって、
放送送信機が、放送サービスのサービスデータ及び前記サービスデータをシグナリングするためのサービスシグナリング情報を生成するステップであって、前記サービスデータはＭＭＴプロトコル（ＭＭＴＰ）を用いて伝達される第１サービスコンポーネント及びＲＯＵＴＥプロトコルを用いて伝達される第２サービスコンポーネントを含む、ステップと、
前記放送送信機が、前記サービスシグナリング情報を伝達する伝送セッションを識別するためのブートストラップ情報を含むサービスリストテーブルを生成するステップと、
前記放送送信機が、前記第１サービスコンポーネント、前記第２サービスコンポーネント、前記サービスシグナリング情報及び前記サービスリストテーブルを含む前記放送信号を放送ネットワークを介して伝送するステップと、
を含む、放送信号伝送方法。
【請求項２】
前記サービスリストテーブルは、前記放送サービスに対するプロトコル情報をさらに含み、
前記プロトコル情報は、前記放送サービスのための前記サービスシグナリング情報を伝達するために使われる伝送プロトコルを指示する、請求項１に記載の放送信号伝送方法。
【請求項３】
前記ブートストラップ情報は、前記サービスシグナリング情報を伝達する前記伝送セッションのＩＰ／ＵＤＰ情報を含み、
前記ＩＰ／ＵＤＰ情報により示される前記伝送セッションは、前記プロトコル情報に基づくＭＭＴＰセッション又はＲＯＵＴＥセッションの一方である、請求項２に記載の放送信号伝送方法。
【請求項４】
前記第２サービスコンポーネントは、前記放送サービスのＮＲＴサービスコンポーネントである、請求項３に記載の放送信号伝送方法。
【請求項５】
放送信号を伝送する装置であって、
プロセッサと送信機とを含み、
前記プロセッサは、
放送サービスのサービスデータ及び前記サービスデータをシグナリングするためのサービスシグナリング情報を生成し、前記サービスデータはＭＭＴプロトコル（ＭＭＴＰ）を用いて伝達される第１サービスコンポーネント及びＲＯＵＴＥプロトコルによって伝達される第２サービスコンポーネントを含み、
前記サービスシグナリング情報を伝達する伝送セッションを識別するためのブートストラップ情報を含むサービスリストテーブルを生成するよう構成され、
前記送信機は、前記第１サービスコンポーネント、前記第２サービスコンポーネント、前記サービスシグナリング情報及び前記サービスリストテーブルを含む前記放送信号を放送ネットワークを介して伝送するように構成される、放送信号伝送装置。
【請求項６】
前記サービスリストテーブルは、前記放送サービスに対するプロトコル情報をさらに含み、
前記プロトコル情報は、前記放送サービスのための前記サービスシグナリング情報を伝達するために使われる伝送プロトコルを指示する、請求項５に記載の放送信号伝送装置。
【請求項７】
前記ブートストラップ情報は、前記サービスシグナリング情報を伝達する前記伝送セッションのＩＰ／ＵＤＰ情報を含み、
前記ＩＰ／ＵＤＰ情報により示される前記伝送セッションは、前記プロトコル情報に基づくＭＭＴＰセッション又はＲＯＵＴＥセッションの一方である、請求項６に記載の放送信号伝送装置。
【請求項８】
前記第２サービスコンポーネントは、前記放送サービスのＮＲＴサービスコンポーネントである、請求項７に記載の放送信号伝送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関するものである。
【背景技術】
【０００２】
アナログ放送信号送信が終了するに従い、デジタル放送信号を送受信するための多様な技術が開発されている。デジタル放送信号はアナログ放送信号に比べてもっと多い量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータだけではなく多様な種類の付加データをさらに含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
すなわち、デジタル放送システムは、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ ｃｈａｎｎｅｌ、多チャネル）オーディオ、及び多様な付加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークの堅固性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）が向上しなければならない。
【課題を解決するための手段】
【０００４】
本発明の目的を達成するために、これに含まれて概略的に記載されたように、本発明は地上波放送ネットワークとインターネットを用いる次世代ハイブリッド放送を支援する環境で次世代放送サービスを効果的に支援することができるシステム及び関連シグナリング方案を提案する。
【発明の効果】
【０００５】
本発明は、サービス特性によってデータを処理して各サービス又はサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を制御することによって多様な放送サービスを提供することができる。
【０００６】
本発明は、同じＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）信号帯域幅を介して多様な放送サービスを伝送することによって伝送柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成することができる。
【０００７】
本発明によると、モバイル受信装置を使うか室内環境にあっても、エラーなしにデジタル放送信号を受信することができる放送信号送信及び受信方法及び装置を提供することができる。
【０００８】
本発明は、地上波放送ネットワークとインターネットを使う次世代ハイブリッド放送を支援する環境で次世代放送サービスを効果的に支援することができる。
【図面の簡単な説明】
【０００９】
本発明に対してもっと理解するために含まれ、本出願に含まれてその一部をなす添付図面は本発明の原理を説明する詳細な説明とともに本発明の実施例を示す。
【００１０】
【図１】本発明の一実施例による受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）を示す図である。
【図２】本発明の一実施例によるＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）の関係を示す図である。
【図３】本発明の一実施例によるＳＬＴを示す図である。
【図４】本発明の一実施例によるＳＬＳブートストラッピングとサービスディスカバリー過程を示す図である。
【図５】本発明の一実施例によるＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示す図である。
【図６】本発明の一実施例によるＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示す図である。
【図７】本発明の一実施例によるＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示す図である。
【図８】本発明の一実施例によるブートストラッピングプロトコルアーキテクチャを示す図である。
【図９】本発明の一実施例によるリンクレイヤーパケットのベースヘッダー構造を示す図である。
【図１０】本発明の一実施例によるリンクレイヤーパケットの追加ヘッダー構造を示す図である。
【図１１】本発明の他の実施例によるリンクレイヤーパケットの追加ヘッダー構造を示す図である。
【図１２】本発明の一実施例による、ＭＰＥＧ−２ＴＳパケットのためのリンクレイヤーパケットのヘッダー構造と、そのカプセル化過程を示す図である。
【図１３】本発明の一実施例によるＩＰヘッダー圧縮において、アダプテーションモードの実施例を示す図である（送信側）。
【図１４】本発明の一実施例によるＬＭＴ（Ｌｉｎｋ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）及びＲＯＨＣ−Ｕディスクリプションテーブルを示す図である。
【図１５】本発明の一実施例による送信機側のリンクレイヤー構造を示す図である。
【図１６】本発明の一実施例による受信機側のリンクレイヤー構造を示す図である。
【図１７】本発明の一実施例による、リンクレイヤーを介したシグナリング伝送構造を示す図である（送／受信側）。
【図１８】本発明の一実施例による次世代放送サービスに対する放送信号送信装置の構造を示す。
【図１９】本発明の一実施例によるＢＩＣＭ（ｂｉｔ ｉｎｔｅｒｌｅａｖｅｄ ｃｏｄｉｎｇ ＆ ｍｏｄｕｌａｔｉｏｎ）ブロックを示す。
【図２０】本発明の他の一実施例によるＢＩＣＭブロックを示す。
【図２１】本発明の一実施例によるＰＬＳのビットインターリービング過程を示した図である。
【図２２】本発明の一実施例による次世代放送サービスに対する放送信号受信装置の構造を示す。
【図２３】本発明の一実施例によるフレームのシグナリング階層構造を示す。
【図２４】本発明の一実施例によるＰＬＳ１データを示す。
【図２５】本発明の一実施例によるＰＬＳ２データを示す。
【図２６】本発明の他の一実施例によるＰＬＳ２データを示す。
【図２７】本発明の一実施例によるフレームのロジカル（ｌｏｇｉｃａｌ、論理）構造を示す。
【図２８】本発明の一実施例によるＰＬＳ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｌｉｎｇ）マッピングを示す。
【図２９】本発明の一実施例によるタイムインターリービングを示す。
【図３０】本発明の一実施例によるツイストされた行−列ブロックインターリーバの基本動作を示す。
【図３１】本発明の他の一実施例によるツイストされた行−列ブロックインターリーバの動作を示す。
【図３２】本発明の一実施例による各ＦＦＴモードによるメインＰＲＢＳジェネレーターとサブ−ＰＲＢＳジェネレーターから構成されたインターリービングアドレスジェネレーターのブロックダイアグラムを示した図である。
【図３３】本発明の一実施例による全てのＦＦＴモードに使われるメインＰＲＢＳを示した図である。
【図３４】本発明の一実施例によるフリクエンシインターリービングのためのインターリービングアドレス及びＦＦＴモードに使われるサブ−ＰＲＢＳを示した図である。
【図３５】本発明の一実施例によるタイムインターリーバのライティング（ｗｒｉｔｉｎｇ）オペレーションを示す。
【図３６】ＰＬＰ数によって適用するインターリービングタイプを表に示す図である。
【図３７】前述したハイブリッドタイムインターリーバ構造の第１実施例を含むブロック図である。
【図３８】前述したハイブリッドタイムインターリーバ構造の第２実施例を含むブロック図である。
【図３９】ハイブリッドタイムデインターリーバの構造の第１実施例を含むブロック図である。
【図４０】ハイブリッドタイムデインターリーバの構造の第２実施例を含むブロック図である。
【図４１】本発明の一実施例によるハイブリッド放送受信装置を示した図である。
【図４２】本発明の一実施例によるハイブリッド放送受信機のブロック図を示した図である。
【図４３】本発明の一実施例による次世代ハイブリッド放送システムのプロトコルスタックを示す。
【図４４】本発明の一実施例による次世代放送伝送システムのｐｈｙｓｉｃａｌ ｌａｙｅｒに伝達される伝送フレームの構造を示す。
【図４５】本発明の一実施例によるアプリケーション階層伝送プロトコルの伝送パケットを示した図である。
【図４６】本発明の一実施例による次世代放送システムがシグナリングデータを伝送する方法を示す。
【図４７】本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。
【図４８】本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。
【図４９】本発明の一実施例によるＦＩＣに基づくシグナリングを伝送する方法を示す。
【図５０】本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。
【図５１】本発明の他の実施例によるＦＩＣに基づくシグナリングを伝送する方法を示す。
【図５２】本発明の一実施例による次世代放送システムのサービスシグナリングメッセージフォーマットを示した図である。
【図５３】本発明の一実施例による次世代放送システムで使用するサービスシグナリングテーブルを示す。
【図５４】本発明の一実施例による次世代放送システムで使われるサービスマッピングテーブルを示した図である。
【図５５】本発明の一実施例による次世代放送システムのサービスシグナリングテーブルを示す。
【図５６】本発明の一実施例による次世代放送システムで使われるコンポーネントマッピングテーブルを示した図である。
【図５７】本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。
【図５８】本発明の一実施例による次世代放送システムのコンポーネントマッピングテーブルのシンタックスを示す。
【図５９】本発明の一実施例による次世代放送システムで各サービスに関連したシグナリングをブロードバンドネットワークを介して伝達する方法を示す。
【図６０】本発明の一実施例による次世代放送システムでＭＰＤをシグナリングする方案を示す。
【図６１】本発明の一実施例による次世代放送システムのＭＰＤデリバリーテーブルのシンタックスを示す。
【図６２】本発明の一実施例による次世代放送システムの伝送セッションインスタンスディスクリプションを示す。
【図６３】本発明の一実施例による次世代放送システムのソースフロー（Ｓｏｕｒｃｅ Ｆｌｏｗ）エレメントを示す。
【図６４】本発明の一実施例による次世代放送システムのＥＦＤＴを示す。
【図６５】本発明の一実施例による次世代放送システムが使用するＩＳＤＴを伝送する方法を示す。
【図６６】本発明の一実施例による次世代放送システムのシグナリングメッセージのデリバリー構造を示す。
【図６７】本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。
【図６８】本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。
【図６９】本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。
【図７０】本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。
【図７１】本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。
【図７２】本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。
【図７３】本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。
【図７４】本発明の一実施例によるＭＰＤの共通属性及びエレメントを示した図である。
【図７５】本発明の一実施例による伝送セッションインスタンスディスクリプションを示した図である。
【図７６】本発明の一実施例による次世代放送システムのソースフロー（Ｓｏｕｒｃｅ Ｆｌｏｗ）エレメントを示す。
【図７７】本発明の他の実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。
【図７８】本発明の他の実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。
【図７９】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを獲得する方法を示す。
【図８０】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを獲得する方法を示す。
【図８１】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを獲得する方法を示す。
【図８２】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを獲得する方法を示す。
【図８３】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを伝送する方法を示す。
【図８４】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを伝送する方法を示した図である。
【図８５】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを伝送する方法を示す。
【図８６】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを伝送する方法を示した図である。
【図８７】本発明の一実施例による次世代放送システムのサービスレイヤーシグナリングを伝送する方法を示した図である。
【図８８】本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを伝達する方法を示した図である。
【図８９】本発明の他の実施例による、シグナリングメッセージ（ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ）のヘッダー（ｈｅａｄｅｒ）のシンタックス（ｓｙｎｔａｘ）を示した図である。
【図９０】本発明の一実施例による、ＤＡＳＨ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ（ＤＡＳＨ初期化セグメント）を処理するプロトコルスタック（Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）を示した図である。
【図９１】本発明の一実施例による、ＬＣＴ（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）セッションインスタンスディスクリプション（ＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ；ＬＳＩＤ）の一部を示した図である。
【図９２】本発明の一実施例による、サービスシグナリングメッセージをフィルタリング（ｆｉｌｔｅｒｉｎｇ）するためのの情報を提供するシグナリングオブジェクトディスクリプション（Ｓｉｇｎａｌｉｎｇ Ｏｂｊｅｃｔ Ｄｅｓｃｒｉｐｔｉｏｎ；ＳＯＤ）を示した図である。
【図９３】本発明の一実施例による、シグナリングメッセージを含むオブジェクトを示した図である。
【図９４】本発明の一実施例による、ＴＯＩ構成ディスクリプション（ＴＯＩ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＤ）を示した図である。
【図９５】本発明の一実施例による、伝送パケットのペイロード（Ｐａｙｌｏａｄ）フォーマット（Ｆｏｒｍａｔ）エレメントを示した図である。
【図９６】本発明の一実施例による、ＴＯＩ構成インスタンスディスクリプション（ＴＯＩ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＩＤ）を示した図である。
【図９７】本発明の一実施例による、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）のペイロードのシンタックス（ｓｙｎｔａｘ）を示した図である。
【図９８】本発明の他の実施例による、ＦＩＣのペイロードのシンタックス（ｓｙｎｔａｘ）を示した図である。
【図９９】本発明の他の実施例による、サービスレベルシグナリングのシンタックス（ｓｙｎｔａｘ）を示した図である。
【図１００】本発明の他の実施例による、コンポーネントマッピングディスクリプション（ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ）を示した図である。
【図１０１】本発明の他の実施例による、ＵＲＬシグナリングディスクリプション（ＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ）のシンタックス（ｓｙｎｔａｘ）を示した図である。
【図１０２】本発明の他の実施例による、ＳｏｕｒｃｅＦｌｏｗエレメントを示した図である。
【図１０３】本発明の他の実施例による、シグナリング情報を放送ネットワークを介して獲得する過程を示した図である。
【図１０４】本発明の他の実施例による、シグナリング情報を放送ネットワークとブロードバンドネットワークを介して獲得する過程を示した図である。
【図１０５】本発明の他の実施例による、シグナリング情報をブロードバンドネットワークを介して獲得する過程を示した図である。
【図１０６】本発明の他の実施例による、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）を放送ネットワークを介して獲得する過程を示した図である。
【図１０７】本発明の他の実施例による、放送サービスのビデオセグメント及びオーディオセグメントを放送ネットワークを介して獲得する過程を示した図である。
【図１０８】本発明の他の実施例による、放送サービスのビデオセグメントは放送ネットワークを介して獲得し、放送サービスのオーディオセグメントはブロードバンドネットワークを介して獲得する過程を示した図である。
【図１０９】本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒの構成を示した図である。
【図１１０】本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの構成を示した図である。
【図１１１】本発明の一実施例によるＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）の構成を示した図である。
【図１１２】本発明の他の一実施例によるＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）の構成を示した図である。
【図１１３】本発明の一実施例によるＳｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎの構成を示した図である。
【図１１４】本発明の一実施例によるＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎの構成を示した図である。
【図１１５】本発明の一実施例による放送信号送信方法を示した図である。
【図１１６】本発明の一実施例による放送信号受信方法を示した図である。
【図１１７】本発明の一実施例による放送信号送信装置の構成を示した図である。
【図１１８】本発明の一実施例による放送信号受信装置の構成を示した図である。
【図１１９】本発明の一実施例による、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝達される場合、そのサービスディスクリプション情報を示す図である。
【図１２０】本発明の一実施例による、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。
【図１２１】本発明の一実施例による、セッションの外部経路を介したセッションディスクリプション情報送信方法を示す図である。
【図１２２】本発明の他の実施例による、セッションの外部経路を介したセッションディスクリプション情報送信方法を示す図である。
【図１２３】本発明のさらに他の実施例による、セッションの外部経路を介したセッションディスクリプション情報送信方法を示す図である。
【図１２４】本発明の一実施例による、初期化情報伝達のために拡張されたシグナリングメッセージを示す図である。
【図１２５】本発明の一実施例による、初期化情報伝達のためのメッセージフォーマットを示す図である。
【図１２６】本発明の他の実施例による、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。
【図１２７】本発明の一実施例によるサービスデータを処理する方法を示す図である。
【図１２８】本発明の一実施例によるサービスデータを処理する装置を示す図である。
【図１２９】本発明の一実施例によるＥＳＧブートストラップ情報を示した図である。
【図１３０】本発明の一実施例によるＥＳＧブートストラップ情報が伝送されるタイプを示した図である。
【図１３１】本発明の第１実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【図１３２】本発明の第２実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【図１３３】本発明の第３実施例によるＥＳＧブートストラッピングディスクリプションのシグナリングを示した図である。
【図１３４】本発明の第４実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【図１３５】本発明の第５実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【図１３６】本発明の第５実施例によるＧＡＴを示した図である。
【図１３７】本発明の第１実施例〜第５実施例の効果を示した図である。
【図１３８】本発明の一実施例による放送受信装置の流れ図を示した図である。
【図１３９】本発明の一実施例によるチャネルマップ構成方法を示した図である。
【図１４０】本発明の一実施例によるチャネルマップ構成方法を示した図である。
【図１４１】本発明の一実施例によるＦＩＣを示した図である。
【図１４２】本発明の一実施例によるＦＩＣを示した図である。
【図１４３】本発明の一実施例によるＦＩＣを示した図である。
【図１４４】本発明の一実施例によるＦＩＣを示した図である。
【図１４５】本発明の一実施例によるＦＩＣを示した図である。
【図１４６】本発明の一実施例によるＦＩＣを示した図である。
【図１４７】本発明の一実施例によるＳＳＣを示した図である。
【図１４８】本発明の一実施例による放送送信方法の流れ図を示した図である。
【図１４９】本発明の一実施例による放送受信方法の流れ図を示した図である。
【図１５０】本発明の一実施例による、受信機移動時の他の周波数へのハンドオーバー（ｈａｎｄｏｖｅｒ）状況を示す図である。
【図１５１】本発明の一実施例による、シームレスハンドオーバーのための情報伝達方案を示す図である。
【図１５２】本発明の他の実施例による、シームレスハンドオーバーのための情報伝達方案を示す図である。
【図１５３】本発明の一実施例による、シームレスハンドオーバーのための情報を示す図である。
【図１５４】本発明の一実施例によるローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【図１５５】本発明の一実施例による、ＦＩＣを用いて、受信機でサービスを表出する過程を示した図である。
【図１５６】本発明の他の実施例による、ローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【図１５７】本発明の他の実施例による、ローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【図１５８】本発明の他の実施例による、ローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【図１５９】本発明の他の実施例による、ＦＩＣを用いて、受信機でサービスを表出する過程を示した図である。
【図１６０】本発明の一実施例による、放送信号を生成処理する方法を示した流れ図である。
【図１６１】本発明の一実施例による放送システムを示した図である。
【図１６２】本発明のさらに他の実施例による放送システムのプロトコルスタックを示す図である。
【図１６３】本発明のさらに他の実施例によるＳＬＴを示す図である。
【図１６４】本発明のさらに他の実施例によるＳＬＴを示す図である。
【図１６５】本発明のさらに他の実施例によるＳＬＴを示す図である。
【図１６６】本発明のさらに他の実施例によるＬＳＩＤを示す図である。
【図１６７】本発明のさらに他の実施例によるソースフロー／リペアーフローに対するディスクリプションを示す図である。
【図１６８】本発明のさらに他の実施例による、シグナリングフローダイアグラムを示す図である。
【図１６９】本発明の一実施例による放送信号を伝送する方法を示す図である。
【図１７０】本発明の一実施例による放送信号を伝送する装置を示す図である。
【発明を実施するための形態】
【００１１】
本発明の好適な実施例について具体的に説明し、その例は添付の図面に示す。添付の図面を参照する下記の詳細な説明は、本発明の具現可能な実施例のみを示すものではなく、本発明の好適な実施例を説明するものである。下記の詳細な説明は、本発明に対する徹底した理解を提供するために細部事項を含む。しかし、本発明がこのような細部事項無しでも実行可能であることは当業者にとって明らかである。
【００１２】
本発明で使われる大部分の用語は、当該分野で広く使われる一般的な用語から選択されるが、一部の用語は出願人によって任意に選択されたものもあり、その意味は必要によって該当の説明部分で詳細に説明する。したがって、本発明は、用語の単純な名称や意味ではなく、用語が意図する意味に基づいて理解されなければならない。
【００１３】
本発明は、次世代放送サービスに対する放送信号の送信及び受信装置及び方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含むことができる。
【００１４】
図１は、本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ  ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示した図である。
【００１５】
放送ネットワークを介したサービスデリバリー（ｂｒｏａｄｃａｓｔ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）において、２つの方法があり得る。
【００１６】
第一の方法は、ＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）に基づいて、ＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔｓ）をＭＭＴＰ（ＭＭＴ  ｐｒｏｔｏｃｏｌ）を用いて伝送することである。第二の方法は、ＭＰＥＧ ＤＡＳＨに基づいて、ＤＡＳＨセグメントをＲＯＵＴＥ（Ｒｅａｌ  ｔｉｍｅ  Ｏｂｊｅｃｔ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を用いて伝送することである。
【００１７】
ＮＲＴメディア、ＥＰＧデータ、及び他のファイルを含む非時間コンテンツは、ＲＯＵＴＥで伝達される。シグナルは、ＭＭＴＰ及び／又はＲＯＵＴＥを介して伝達できる一方、ブートストラップシグナリング情報はＳＬＴ（ｓｅｒｖｉｃｅ  ｌｉｓｔ  ｔａｂｌｅ）によって提供される。
【００１８】
ハイブリッドサービスデリバリー（ｈｙｂｒｉｄ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）においては、ＨＴＴＰ／ＴＣＰ／ＩＰ上のＭＰＥＧ ＤＡＳＨがブロードバンド側で用いられる。ＩＳＯ ＢＭＦＦ（ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）のメディアファイルは、デリバリー、ブロードキャスト及びブロードバンドデリバリーに対するメディアカプセル化及び同期化フォーマットとして使用される。ここで、ハイブリッドサービスデリバリーとは、１つ又はそれ以上のプログラムエレメントがブロードバンドパス（ｐａｔｈ）を介して伝達される場合のことをいえる。
【００１９】
サービスは、３つの機能レイヤーを用いて伝達される。これらは、フィジカルレイヤー、デリバリーレイヤー、サービスマネジメントレイヤーである。フィジカルレイヤーは、シグナル、サービス公知、ＩＰパケットストリームがブロードキャストフィジカルレイヤー及び／又はブロードバンドフィジカルレイヤーで伝送されるメカニズムを提供する。デリバリーレイヤーは、オブジェクト及びオブジェクトフロートランスポート機能を提供する。これは、ブロードキャストフィジカルレイヤーのＵＤＰ／ＩＰマルチキャストで動作するＭＭＴＰ又はＲＯＵＴＥプロトコルによって可能であり、ブロードバンドフィジカルレイヤーのＴＣＰ／ＩＰユニキャストでＨＴＴＰプロトコルによって可能である。サービスマネジメントレイヤーは、下位であるデリバリー及びフィジカルレイヤーによって実行されるリニアＴＶ又はＨＴＭＬ５応用サービスのような全てのサービスを可能にする。
【００２０】
本図において、放送（ｂｒｏａｄｃａｓｔ）側のプロトコルスタック部分は、ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分とに分けられる。
【００２１】
ＳＬＴは、ＵＤＰ、ＩＰレイヤーを経てカプセル化されてもよい。ここで、ＳＬＴについては後述する。ＭＭＴＰは、ＭＭＴで定義されるＭＰＵフォーマットでフォーマットされたデータ、及びＭＭＴＰによるシグナリング情報を伝送することができる。これらデータは、ＵＤＰ、ＩＰレイヤーを経てカプセル化されてもよい。ＲＯＵＴＥは、ＤＡＳＨセグメントの形態にフォーマットされたデータとシグナリング情報、そして、ＮＲＴなどのノンタイムド（ｎｏｎ  ｔｉｍｅｄ）データを伝送することができる。これらデータも、ＵＤＰ、ＩＰレイヤーを経てカプセル化されてもよい。実施例によって、ＵＤＰ、ＩＰレイヤーによるプロセシングは一部又は全部省略されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であり得る。
【００２２】
ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分は、ＵＤＰ、ＩＰレイヤーで処理された後、リンクレイヤー（Ｄａｔａ  Ｌｉｎｋ  Ｌａｙｅｒ）で再びカプセル化されてもよい。リンクレイヤーについては後述する。リンクレイヤーで処理された放送データは、フィジカルレイヤーでエンコーディング／インターリービングなどの過程を経て放送信号としてマルチキャストされてもよい。
【００２３】
本図において、ブロードバンド（ｂｒｏａｄｂａｎｄ）側のプロトコルスタック部分は、前述したように、ＨＴＴＰを介して伝送されてもよい。ＤＡＳＨセグメントの形態にフォーマットされたデータとシグナリング情報、ＮＲＴなどの情報がＨＴＴＰを介して伝送されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であり得る。このデータは、ＴＣＰ、ＩＰレイヤーを経てプロセシングされた後、リンクレイヤーでカプセル化されてもよい。実施例によって、ＴＣＰ、ＩＰ、リンクレイヤーの一部又は全部は省略されてもよい。この後、処理されたブロードバンドデータは、フィジカルレイヤーで伝送のための処理を経てブロードバンドにユニキャストされてもよい。
【００２４】
サービスは、全体的にユーザに見せるメディアコンポーネントのコレクションであってもよく、コンポーネントは、種々のメディアタイプのものであってもよく、サービスは、連続的又は間欠的であってもよく、サービスは、実時間又は非実時間であってもよく、実時間サービスはＴＶプログラムのシーケンスで構成されてもよい。
【００２５】
図２は、本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）の関係を示した図である。
【００２６】
サービスシグナリングは、サービスディスカバリー及びディスクリプション情報を提供し、２つの機能コンポーネントを含む。これらは、ＳＬＴを介したブートストラップシグナリングとＳＬＳである。これらは、ユーザサービスを発見し、獲得するのに必要な情報を示す。ＳＬＴは、受信機が、基本サービスリストを作成し、各サービスに対するＳＬＳの発見をブートストラップできるようにする。
【００２７】
ＳＬＴは、基本サービス情報の非常に速い獲得を可能にする。ＳＬＳは、受信機が、サービスとそのコンテンツコンポーネントを発見し、これに接続できるようにする。ＳＬＴとＳＬＳの具体的な内容については後述する。
【００２８】
前述したように、ＳＬＴは、ＵＤＰ／ＩＰを介して伝送され得る。このとき、実施例によって、この伝送において最も堅固な（ｒｏｂｕｓｔ）方法を通じて、ＳＬＴに該当するデータが伝達されてもよい。
【００２９】
ＳＬＴは、ＲＯＵＴＥプロトコルによって伝達されるＳＬＳに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＲＯＵＴＥプロトコルによるＳＬＳにブートストラッピングすることができる。このＳＬＳは、前述したプロトコルスタックにおいてＲＯＵＴＥの上位レイヤーに位置するシグナリング情報であって、ＲＯＵＴＥ／ＵＤＰ／ＩＰを介して伝達され得る。このＳＬＳは、ＲＯＵＴＥセッションに含まれるＬＣＴセッションのうち１つを介して伝達され得る。このＳＬＳを用いて、所望のサービスに該当するサービスコンポーネントに接近することができる。
【００３０】
また、ＳＬＴは、ＭＭＴＰによって伝達されるＭＭＴシグナリングコンポーネントに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＭＭＴＰによるＳＬＳにブートストラッピングすることができる。このＳＬＳは、ＭＭＴで定義するＭＭＴＰシグナリングメッセージ（Ｓｉｇｎａｌｉｎｇ  Ｍｅｓｓａｇｅ）によって伝達され得る。このＳＬＳを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。前述したように、本発明では、ＮＲＴサービスコンポーネントは、ＲＯＵＴＥプロトコルを介して伝達され、ＭＭＴＰによるＳＬＳは、これに接近するための情報も含むことができる。ブロードバンドデリバリーにおいて、ＳＬＳはＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰで伝達される。
【００３１】
図３は、本発明の一実施例に係るＳＬＴを示した図である。
【００３２】
まず、サービスマネジメント、デリバリー、フィジカルレイヤーの各論理的エンティティー間の関係について説明する。
【００３３】
サービスは、２つの基本タイプのうち１つとしてシグナリングされ得る。第一のタイプは、アプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオ又はオーディオのみのサービスである。第二のタイプは、プレゼンテーション及び構成が、サービスの獲得によって実行されるダウンロードアプリケーションによって制御されるサービスである。後者は、アプリベースのサービスと呼ぶこともできる。
【００３４】
サービスのコンテンツコンポーネントを伝達するＭＭＴＰセッション及び／又はＲＯＵＴＥ／ＬＣＴセッションの存在と関連する規則は、次の通りである。
【００３５】
アプリベースのエンハンスメントがないリニアサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、又は（２）１つ以上のＭＭＴＰセッションのうち１つ（両方ともではない）によって伝達され得る。
【００３６】
アプリベースのエンハンスメントがあるリニアサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、及び（２）０個以上のＭＭＴＰセッションによって伝達され得る。
【００３７】
特定の実施例において、同一のサービスでストリーミングメディアコンポーネントに対するＭＭＴＰ及びＲＯＵＴＥの両者の使用が許容されないことがある。
【００３８】
アプリベースのサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは１つ以上のＲＯＵＴＥ／ＬＣＴセッションによって伝達され得る。
【００３９】
それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリーにおいて、ＬＣＴセッションは、オーディオ、ビデオ、又はクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアは、ＤＡＳＨセグメントとしてフォーマットされる。
【００４０】
それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージ又は全部又は一部のコンテンツコンポーネントを伝達する、１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ、又はＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。
【００４１】
ＮＲＴユーザサービス又はシステムメタデータのデリバリーのために、ＬＣＴセッションは、ファイルベースのコンテンツアイテムを伝達する。これらコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、又はサービスシグナリングやＥＳＧフラグメントのようなメタデータで構成され得る。サービスシグナリングやＥＳＧフラグメントのようなシステムメタデータのデリバリーも、ＭＭＴＰのシグナリングメッセージモードを通じて行われてもよい。
【００４２】
ブロードキャストストリームは、特定の帯域内に集中したキャリア周波数の観点で定義されたＲＦチャンネルの概念である。それは、［地理的領域、周波数］対によって識別される。ＰＬＰ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｉｐｅ）は、ＲＦチャンネルの一部に該当する。各ＰＬＰは、特定のモジュレーション及びコーディングパラメータを有する。それは、属しているブロードキャストストリーム内で唯一のＰＬＰＩＤ（ＰＬＰ  ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ここで、ＰＬＰはＤＰ（ｄａｔａ  ｐｉｐｅ）と呼ぶこともできる。
【００４３】
各サービスは、２つの形態のサービス識別子によって識別される。一方は、ＳＬＴで使用され、ブロードキャスト領域内でのみ唯一のコンパックな形態であり、他方は、ＳＬＳ及びＥＳＧで使用される全世界的に唯一の形態である。ＲＯＵＴＥセッションは、ソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションポートナンバーによって識別される。ＬＣＴセッション（それが伝達するサービスコンポーネントと関連する）は、ペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＬＣＴセッションに共通した属性及び個別ＬＣＴセッションに唯一の特定の属性は、サービスレイヤーシグナリングの一部であるＳ−ＴＳＩＤ（ｓｅｒｖｉｃｅ−ｂａｓｅｄ  ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれるＲＯＵＴＥシグナリング構造で与えられる。各ＬＣＴセッションは、１つのＰＬＰを介して伝達される。実施例によって、１つのＬＣＴセッションが複数個のＰＬＰを介して伝達されてもよい。ＲＯＵＴＥセッションの互いに異なるＬＣＴセッションは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＲＯＵＴＥセッションは、複数個のＰＬＰを介して伝達されてもよい。Ｓ−ＴＳＩＤに記述された属性は、各ＬＣＴセッションに対するＴＳＩ値及びＰＬＰＩＤ、デリバリーオブジェクト／ファイルに対するディスクリプタ、アプリケーションレイヤーＦＥＣパラメータを含む。
【００４４】
ＭＭＴＰセッションは、デスティネーションＩＰアドレス及びデスティネーションポートナンバーによって識別される。ＭＭＴＰパケットフロー（それが伝達するサービスコンポーネントと関連する）は、ペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ_ｉｄによって識別される。各ＭＭＴＰパケットフローに共通した属性及びＭＭＴＰパケットフローの特定の属性がＳＬＴに与えられる。各ＭＭＴＰセッションに対する属性は、ＭＭＴＰセッション内で伝達され得るＭＭＴシグナリングメッセージによって与えらえる。ＭＭＴＰセッションの互いに異なるＭＭＴＰパケットフローは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＭＭＴＰセッションは、複数個のＰＬＰを介して伝達されてもよい。ＭＭＴシグナリングメッセージに記述された属性は、各ＭＭＴＰパケットフローに対してｐａｃｋｅｔ_ｉｄ値及びＰＬＰＩＤを含む。ここで、ＭＭＴシグナリングメッセージは、ＭＭＴで定義された形態であるかあるいは後述する実施例によって変形が行われた形態であり得る。
【００４５】
以下、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【００４６】
この機能に専用であるよく知られているアドレス／ポートを有するＩＰパケットのペイロードに伝達されるシグナリング情報は、ＬＬＳと呼ばれる。このＩＰアドレス及びポートナンバーは、実施例によって異なって設定されてもよい。一実施例において、ＬＬＳは、アドレスが２２４．０．２３．６０であり、デスティネーションポートが４９３７／ｕｄｐであるＩＰパケットに伝達され得る。ＬＬＳは、前述したプロトコルスタック上で、「ＳＬＴ」で表現された部分に位置し得る。ただし、実施例によって、ＬＬＳは、ＵＤＰ／ＩＰレイヤーのプロセシングを経ずに、信号フレーム上の別個の物理チャンネル（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）を介して伝送されてもよい。
【００４７】
ＬＬＳデータを伝達するＵＤＰ／ＩＰパケットは、ＬＬＳテーブルという形態にフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの開始であり得る。全てのＬＬＳテーブルの最大の長さは、フィジカルレイヤーから伝達され得る最も大きいＩＰパケットによって６５，５０７バイトに制限される。
【００４８】
ＬＬＳテーブルは、ＬＬＳテーブルのタイプを識別するＬＬＳテーブルＩＤフィールド、及びＬＬＳテーブルのバージョンを識別するＬＬＳテーブルバージョンフィールドを含むことができる。ＬＬＳテーブルＩＤフィールドが示す値に応じて、ＬＬＳテーブルは、前述したＳＬＴを含むか、又はＲＲＴ（Ｒａｔｉｎｇ  Ｒｅｇｉｏｎ  Ｔａｂｌｅ）を含むことができる。ＲＲＴは、コンテンツ勧告レーティング（Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙ  Ｒａｔｉｎｇ）についての情報を有することができる。
【００４９】
以下、ＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）について説明する。ＬＬＳは、受信機によるサービス獲得のブートストラッピング及び速いチャンネルスキャンを支援するシグナリング情報であり、ＳＬＴは、基本サービスリスティングを構築し、ＳＬＳのブートストラップディスカバリーを提供するために使用されるシグナリング情報のテーブルであり得る。
【００５０】
ＳＬＴの機能は、ＭＰＥＧ−２システムでのＰＡＴ（ｐｒｏｇｒａｍ  ａｓｓｏｃｉａｔｉｏｎ  ｔａｂｌｅ）及びＡＴＳＣシステムで発見されるＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）とほぼ同一である。初めてブロードキャストエミッションを経験する受信機にとって、これは、開始される地点である。ＳＬＴは、受信機が、チャンネル名、チャンネルナンバーなどでそれが受信できる全てのサービスのリストを構築できるようにする、速いチャンネルスキャンを支援する。また、ＳＬＴは、受信機が各サービスに対してＳＬＳを発見できるようにするブートストラップ情報を提供する。ＲＯＵＴＥ／ＤＡＳＨで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＬＣＴセッションのデスティネーションＩＰアドレス及びデスティネーションポートを含む。ＭＭＴ／ＭＰＵで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＭＭＴＰセッションのデスティネーションＩＰアドレス及びデスティネーションポートを含む。
【００５１】
ＳＬＴは、ブロードキャストストリームで各サービスに関する次の情報を含むことによって、サービス獲得及び速いチャンネルスキャンを支援する。第一に、ＳＬＴは、視聴者にとって有意義であり、上／下の選択又はチャンネルナンバーを介した初期サービス選択を支援できるサービスリストのプレゼンテーションを許容するのに必要な情報を含むことができる。第二に、ＳＬＴは、各リスティングされたサービスに対してＳＬＳの位置を見つけるのに必要な情報を含むことができる。すなわち、ＳＬＴは、ＳＬＳを伝達する位置（ｌｏｃａｔｉｏｎ）に対するアクセス情報を含むことができる。
【００５２】
図示された本発明の一実施例に係るＳＬＴは、ＳＬＴルートエレメント（ｒｏｏｔ  ｅｌｅｍｅｎｔ）を有するＸＭＬドキュメントの形態に表現された。実施例によって、ＳＬＴは、バイナリフォーマット又はＸＭＬドキュメントの形態に表現することができる。
【００５３】
図示されたＳＬＴのＳＬＴルートエレメントは、＠ｂｓｉｄ、＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ、＠ｌａｎｇｕａｇｅ、＠ｃａｐａｂｉｌｉｔｉｅｓ、ＩｎｅｔＳｉｇＬｏｃ及び／又はＳｅｒｖｉｃｅを含むことができる。実施例によって、ＳＬＴルートエレメントは、＠ｐｒｏｖｉｄｅｒＩｄをさらに含むこともできる。実施例によって、ＳＬＴルートエレメントは、＠ｌａｎｇｕａｇｅを含まなくてもよい。
【００５４】
Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ、＠ｐｒｏｔｅｃｔｅｄ、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ、＠ｈｉｄｄｅｎ、＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅ、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ、＠ｓｌｓＰｌｐＩｄ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓｌｓＳｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ、＠ｃａｐａｂｉｌｉｔｉｅｓ及び／又はＩｎｅｔＳｉｇＬｏｃを含むことができる。
【００５５】
実施例によって、ＳＬＴの属性又はエレメントは追加／変更／削除されてもよい。ＳＬＴに含まれる各エレメントも、さらに別個の属性又はエレメントを有することができ、この実施例に係る属性又はエレメントの一部が省略されてもよい。ここで、＠表記されたフィールドは属性（ａｔｔｒｉｂｕｔｅ）に該当し、＠表記されていないフィールドはエレメント（ｅｌｅｍｅｎｔ）に該当し得る。
【００５６】
＠ｂｓｉｄは、全ブロードキャストストリームの識別子である。ＢＳＩＤの値は、地域的レベルで唯一であり得る。
【００５７】
＠ｐｒｏｖｉｄｅｒＩｄは、このブロードキャストストリームの一部又は全体を使用する放送会社のインデックスである。これは選択的な属性である。それが存在しないということは、このブロードキャストストリームが一つの放送会社によって使用されていることを意味する。＠ｐｒｏｖｉｄｅｒＩｄは図示していない。
【００５８】
＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ＳＬＴセクションのバージョンナンバーであり得る。ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ｓｌｔ内で伝達される情報に変化が生じると１ずつ増分し得る。それが最大値に到達すると、０にシフトされる。
【００５９】
＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒは、ＳＬＴの当該セクションのナンバーであって、１からカウントすることができる。すなわち、当該ＳＬＴセクションのセクションナンバーに該当し得る。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
【００６０】
＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは、当該セクションが一部であるＳＬＴのセクション（即ち、最大のｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒを有するセクション）の総ナンバーであり得る。ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒとｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは共に分割で伝送される場合、ＳＬＴの一部の「ＮのＭ部分」を示すと見ることができる。すなわち、ＳＬＴを伝送するにおいて、分割（ｆｒａｇｍｅｎｔａｔｉｏｎ）を通じた伝送を支援できる。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。フィールドが使用されない場合は、ＳＬＴが分割されて伝送されない場合であり得る。
【００６１】
＠ｌａｎｇｕａｇｅは、当該ｓｌｔである場合に含まれるサービスの主言語を示すことができる。実施例によって、このフィールド値は、ＩＳＯで定義される３−キャラクター言語コード（ｔｈｒｅｅ  ｃｈａｒａｃｔｅｒ  ｌａｎｇｕａｇｅ  ｃｏｄｅ）の形態であり得る。このフィールドは省略されてもよい。
【００６２】
＠ｃａｐａｂｉｌｉｔｉｅｓは、当該ｓｌｔである場合において全てのサービスに対する内容をデコードし、有意義に示すために要求されるケイパビリティを示すことができる。
【００６３】
ＩｎｅｔＳｉｇＬｏｃは、どこでブロードバンドを介して外部サーバーから全ての要求されるタイプのデータを獲得できるかを受信機に知らせるＵＲＬを提供することができる。このエレメントは、＠ｕｒｌＴｙｐｅを下位フィールドとしてさらに含むこともできる。この＠ｕｒｌＴｙｐｅフィールドの値に応じて、ＩｎｅｔＳｉｇＬｏｃが提供するＵＲＬのタイプを指示することができる。実施例によって、＠ｕｒｌＴｙｐｅフィールド値が０である場合、ＩｎｅｔＳｉｇＬｏｃはシグナリングサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールド値が１である場合、ＩｎｅｔＳｉｇＬｏｃはＥＳＧサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールドが、それ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【００６４】
Ｓｅｒｖｉｃｅフィールドは、各サービスについての情報を有するエレメントであって、サービスエントリーに該当し得る。ＳＬＴが指示するサービスの数（Ｎ）だけＳｅｒｖｉｃｅエレメントフィールドが存在し得る。以下、Ｓｅｒｖｉｃｅフィールドの下位属性／エレメントについて説明する。
【００６５】
＠ｓｅｒｖｉｃｅＩｄは、当該ブロードキャスト領域の範囲内で当該サービスを唯一に識別する整数であり得る。実施例によって、＠ｓｅｒｖｉｃｅＩｄのスコープ（ｓｃｏｐｅ）は変更されてもよい。＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは、ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤを有するＳＬＴサービス情報のシーケンスナンバーを示す整数であり得る。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ値は、各サービスに対して０から始まることができ、当該Ｓｅｒｖｉｃｅエレメントにおいてある属性が変化するたびに１ずつ増分することができる。ＳｅｒｖｉｃｅＩＤの特定の値を有する以前のサービスエレメントに比べていかなる属性値も変化しない場合、ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは増分しないはずである。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒフィールドは、最大値に到達した後、０にシフトされる。
【００６６】
＠ｐｒｏｔｅｃｔｅｄは、フラグ情報であって、当該サービスの有意義な再生のための１つ又はそれ以上のコンポーネントが保護された（ｐｒｏｔｅｃｔｅｄ）状態であるかを示すことができる。「１」（真）に設定されると、有意義なプレゼンテーションに必要な１つ以上のコンポーネントが保護される。「０」（偽）に設定されると、当該フラグは、サービスの有意義なプレゼンテーションに必要なコンポーネントが何にも保護されないことを示す。デフォルト値は偽である。
【００６７】
＠ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの「主」チャンネルナンバーを示す整数値である。このフィールドの一実施例は、１から９９９までの範囲を有することができる。
【００６８】
＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの「副」チャンネルナンバーを示す整数値である。このフィールドの一実施例は、１から９９９までの範囲を有することができる。
【００６９】
＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙは、当該サービスのカテゴリーを示すことができる。このフィールドが示す意味は、実施例によって変更されてもよい。一実施例によると、このフィールドの値が１、２、３である場合、それぞれ当該サービスは、リニアＡ／Ｖサービス（Ｌｉｎｅａｒ  Ａ／Ｖ  ｓｅｒｖｉｃｅ）、リニアオーディオサービス（Ｌｉｎｅａｒ  ａｕｄｉｏ  ｏｎｌｙ  ｓｅｒｖｉｃｅ）、アプリベースのサービス（ａｐｐ−ｂａｓｅｄ  ｓｅｒｖｉｃｅ）に該当し得る。このフィールドの値が０である場合、定義されていないカテゴリーのサービスであり得、このフィールドの値が０、１、２、３以外の他の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅは、サービスのショートストリングネームであり得る。
【００７０】
＠ｈｉｄｄｅｎは、存在し、「真」に設定される場合、ブール値であり得、これは、サービスがテストや独占使用のためのものであり、通常のＴＶ受信機によっては選択されないことを示す。存在しない場合、デフォルト値は「偽」である。
【００７１】
＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅは、当該サービスによって使用されるＳＬＳのプロトコルのタイプを示す属性であり得る。このフィールドが示す意味は、実施例によって変更されてもよい。一実施例によると、このフィールドの値が１、２である場合、それぞれ、当該サービスが使用するＳＬＳのプロトコルはＲＯＵＴＥ、ＭＭＴＰであり得る。このフィールドの値が０又はそれ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。このフィールドは、＠ｓｌｓＰｒｏｔｏｃｏｌと呼ぶこともできる。
【００７２】
ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ及びその下位属性／エレメントは、放送シグナリングと関連する情報を提供することができる。ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、ペアレントサービスエレメントのチャイルドエレメントであるＩｎｅｔＳｉｇＬｏｃが存在し得、その属性であるｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ ０ｘ００（ＵＲＬ  ｔｏ  ｓｉｇｎａｌｉｎｇ  ｓｅｒｖｅｒ）を含む。この場合、属性であるｕｒｌは、ｓｅｒｖｉｃｅ_ｉｄがペアレントサービスエレメントに対するｓｅｒｖｉｃｅｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ_ｉｄ＞を支援する。
【００７３】
又は、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、エレメントＩｎｅｔＳｉｇＬｏｃはｓｌｔルートエレメントのチャイルドエレメントとして存在し得、ＩｎｅｔＳｉｇＬｏｃエレメントの属性ｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ ０ｘ００（ＵＲＬ  ｔｏ  ｓｉｇｎａｌｉｎｇ  ｓｅｒｖｅｒ）を含む。この場合、ＵＲＬ_ｔｙｐｅ０ｘ００に対する属性ｕｒｌは、ｓｅｒｖｉｃｅ_ｉｄがペアレントサービスエレメントのｓｅｒｖｉｃｅＩｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ_ｉｄ＞を支援する。
【００７４】
＠ｓｌｓＰｌｐＩｄは、当該サービスに対してＳＬＳを伝達するＰＬＰのＰＬＰ ＩＤを示す整数を表現するストリングであり得る。
【００７５】
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４デスティネーションアドレスを含むストリングであり得る。
【００７６】
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対してＳＬＳデータを伝達するパケットのポートナンバーを含むストリングであり得る。前述したように、デスティネーションＩＰ／ＵＤＰ情報によってＳＬＳブートストラッピングを行うことができる。
【００７７】
＠ｓｌｓＳｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソースアドレスを含むストリングであり得る。
【００７８】
＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの主バージョンナンバーであり得る。デフォルト値は１である。
【００７９】
＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの副バージョンナンバーであり得る。デフォルト値は０である。
【００８０】
＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの主言語を示す３文字言語コードであり得る。このフィールド値の形式は、実施例によって変更されてもよい。
【００８１】
＠ｂｒｏａｄｂａｎｄｃｃｅｓｓＲｅｑｕｉｒｅｄは、受信機がサービスの有意義なプレゼンテーションを行うためにブロードバンドアクセスが必要であることを示すブール値であり得る。このフィールドの値がＴｒｕｅである場合、受信機は、有意義なサービス再生のためにブロードバンドにアクセスしなければならず、これは、サービスのハイブリッドデリバリーのケースに該当し得る。
【００８２】
＠ｃａｐａｂｉｌｉｔｉｅｓは、ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤであって、サービスに対する内容をデコードし、有意義に示すために要求されるケイパビリティを示すことができる。
【００８３】
ＩｎｅｔＳｉｇＬｏｃは、使用可能な場合、ブロードバンドを介してシグナリングや公知の情報に接続するためのＵＲＬを提供することができる。そのデータタイプは、ＵＲＬがどこにアクセスするかを示す＠ｕｒｌＴｙｐｅ属性を付け加える全てのＵＲＬデータタイプの拡張であり得る。このフィールドの＠ｕｒｌＴｙｐｅフィールドが意味することは、前述したＩｎｅｔＳｉｇＬｏｃの＠ｕｒｌＴｙｐｅフィールドが意味することと同一であり得る。属性ＵＲＬ_ｔｙｐｅ ０ｘ００のＩｎｅｔＳｉｇＬｏｃエレメントがＳＬＴのエレメントとして存在する場合、それは、シグナリングメタデータに対してＨＴＴＰ要求を行うために使用され得る。このＨＴＴＰ ＰＯＳＴメッセージボディーにはサービスタームが含まれてもよい。ＩｎｅｔＳｉｇＬｏｃエレメントがセクションレベルで現れる場合、サービスタームは、要求されたシグナリングメタデータオブジェクトが適用されるサービスを示すために使用される。サービスタームが存在しない場合、当該セクションの全てのサービスに対するシグナリングメタデータオブジェクトが要求される。ＩｎｅｔＳｉｇＬｏｃがサービスレベルで現れる場合、所望のサービスを指定するために必要なサービスタームがない。属性ＵＲＬ_ｔｙｐｅ ０ｘ０１のＩｎｅｔＳｉｇＬｏｃエレメントが提供されると、それは、ブロードバンドを介してＥＳＧデータを検索するのに使用することができる。当該エレメントがサービスエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該サービスに対してデータを検索するのに使用することができる。当該エレメントがＳＬＴエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該セクションで全てのサービスに対するＥＳＧデータを検索するのに使用することができる。
【００８４】
ＳＬＴの他の実施例において、ＳＬＴの＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ及び／又は＠ｌａｎｇｕａｇｅフィールドは省略されてもよい。
【００８５】
また、前述したＩｎｅｔＳｉｇＬｏｃフィールドは、＠ｓｌｔＩｎｅｔＳｉｇＵｒｉ及び／又は＠ｓｌｔＩｎｅｔＥｓｇＵｒｉフィールドに代替されてもよい。２つのフィールドは、それぞれシグナリングサーバーのＵＲＩ、ＥＳＧサーバーのＵＲＩ情報を含むことができる。ＳＬＴの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールド及びＳｅｒｖｉｃｅの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールドは、いずれも、前記のような方法で代替されてもよい。
【００８６】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、１は、当該フィールドが必須のフィールドであり、０..１は、当該フィールドがオプショナルフィールドであることを意味し得る。
【００８７】
図４は、本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリー過程を示した図である。
【００８８】
以下、サービスレイヤーシグナリング（ＳＬＳ、Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【００８９】
ＳＬＳは、サービス及びそのコンテンツコンポーネントを発見し、獲得するための情報を提供するシグナリングであり得る。
【００９０】
ＲＯＵＴＥ／ＤＡＳＨについて、各サービスに対するＳＬＳは、コンポーネントのリスト、どこでそれらを獲得できるのか、サービスの有意義なプレゼンテーションのために要求される受信機の性能のようなサービスの特性を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、ＳＬＳは、ＵＳＢＤ（ｕｓｅｒ  ｓｅｒｖｉｃｅ  ｂｕｎｄｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ、ＤＡＳＨ ＭＰＤ（ｍｅｄｉａ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｓｃｒｉｐｔｉｏｎ）を含む。ここで、ＵＳＢＤ又はＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、ＳＬＳ ＸＭＬフラグメントのうちの１つであって、サービスの具体的な技術的情報を記述するシグナリングハブとしての役割を果たすことができる。このＵＳＢＤ／ＵＳＤは、３ＧＰＰ ＭＢＭＳで定義されたことよりもさらに拡張されてもよい。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。
【００９１】
サービスシグナリングは、サービス自体の基本属性、特に、サービスを獲得するために必要な属性に焦点を置く。視聴者のためのサービス及びプログラミングの特徴は、サービスの公知又はＥＳＧデータとして現れる。
【００９２】
各サービスに対して別個のサービスシグナリングを有する場合、受信機は、ブロードキャストストリーム内で伝達される全ＳＬＳをパーシングすることなく所望のサービスに対する適切なＳＬＳを獲得すればよい。
【００９３】
サービスシグナリングの選択的なブロードバンドデリバリーに対して、ＳＬＴは、前述したように、サービスシグナリングファイルが獲得され得るＨＴＴＰ ＵＲＬを含むことができる。
【００９４】
ＬＬＳは、ＳＬＳ獲得をブートストラップするのに使用され、その後、ＳＬＳは、ＲＯＵＴＥセッション又はＭＭＴＰセッションで伝達されるサービスコンポーネントを獲得するのに使用される。記述された図面は、次のシグナリングシーケンスを示す。受信機は、前述したＳＬＴを獲得し始める。ＲＯＵＴＥセッションで伝達されるｓｅｒｖｉｃｅ_ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃１）、ソースＩＰアドレス（ｓＩＰ１）、デスティネーションＩＰアドレス（ｄＩＰ１）、及びデスティネーションポートナンバー（ｄＰｏｒｔ１）のようなＳＬＳブートストラッピング情報を提供する。ＭＭＴＰセッションで伝達されるｓｅｒｖｉｃｅ_ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃２）、デスティネーションＩＰアドレス（ｄＩＰ２）、及びデスティネーションポートナンバー（ｄＰｏｒｔ２）のようなＳＬＳブートストラッピング情報を提供する。
【００９５】
ＲＯＵＴＥを用いたストリーミングサービスデリバリーに対して、受信機は、ＰＬＰ及びＩＰ／ＵＤＰ／ＬＣＴセッションで伝達されるＳＬＳ分割を獲得することができる。反面、ＭＭＴＰを用いたストリーミングサービスデリバリーに対して、受信機は、ＰＬＰ及びＭＭＴＰセッションで伝達されるＳＬＳ分割を獲得することができる。ＲＯＵＴＥを用いたサービスデリバリーに対して、これらＳＬＳ分割は、ＵＳＢＤ／ＵＳＤ分割、Ｓ−ＴＳＩＤ分割、ＭＰＤ分割を含む。それらは一つのサービスと関連がある。ＵＳＢＤ／ＵＳＤ分割は、サービスレイヤーの特性を記述し、Ｓ−ＴＳＩＤ分割に対するＵＲＩレファレンス及びＭＰＤ分割に対するＵＲＩレファレンスを提供する。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれ参照することができる。ＭＭＴＰを用いたサービスデリバリーに対して、ＵＳＢＤは、ＭＭＴシグナリングのＭＭＴメッセージを参照し、それのＭＰテーブルは、サービスに属するアセット（ａｓｓｅｔ）のための位置情報及びパッケージＩＤの識別を提供する。ここで、Ａｓｓｅｔとは、マルチメディアデータエンティティーであって、一つのユニークなＩＤに連合され、一つのマルチメディアプレゼンテーションを生成するのに使用されるデータエンティティーを意味し得る。Ａｓｓｅｔは、一つのサービスを構成するサービスコンポーネントに該当し得る。ＭＰＴメッセージは、ＭＭＴのＭＰテーブルを有するメッセージであり、ここで、ＭＰテーブルは、ＭＭＴ Ａｓｓｅｔとコンテンツについての情報を有する、ＭＭＴパッケージテーブル（ＭＭＴ  Ｐａｃｋａｇｅ  Ｔａｂｌｅ）であり得る。具体的な内容は、ＭＭＴで定義された通りである。ここで、メディアプレゼンテーションとは、メディアコンテンツのバウンド／アンバウンドされたプレゼンテーションを成立させるデータのコレクションであり得る。
【００９６】
Ｓ−ＴＳＩＤ分割は、一つのサービスと関連するコンポーネント獲得情報と、当該サービスのコンポーネントに該当するＴＳＩ及びＭＰＤで発見されるＤＡＳＨ表現との間のマッピングを提供する。Ｓ−ＴＳＩＤは、ＴＳＩ及び関連するＤＡＳＨ表現識別子の形態のコンポーネント獲得情報、及びＤＡＳＨ表現と関連するＤＡＳＨ分割を伝達するＰＬＰＩＤを提供することができる。ＰＬＰＩＤ及びＴＳＩ値によって、受信機は、サービスからオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディア分割のバッファリングを開始した後、適切なデコーディング過程を適用する。
【００９７】
ＭＭＴＰセッションで伝達されるＵＳＢＤリスティングサービスコンポーネントに対して、記述された図面の「Ｓｅｒｖｉｃｅ ＃２」に示したように、受信機は、ＳＬＳを完了するためにマッチングされるＭＭＴ_ｐａｃｋａｇｅ_ｉｄを有するＭＰＴメッセージを獲得する。ＭＰＴメッセージは、各コンポーネントに対する獲得情報及びサービスを含むサービスコンポーネントの完全なリストを提供する。コンポーネント獲得情報は、ＭＭＴＰセッション情報、当該セッションを伝達するＰＬＰＩＤ、当該セッション内のｐａｃｋｅｔ_ｉｄを含む。
【００９８】
実施例によって、例えば、ＲＯＵＴＥである場合、２つ以上のＳ−ＴＳＩＤフラグメントが使用されてもよい。それぞれのフラグメントは、各サービスのコンテンツを伝達するＬＣＴセッションに対するアクセス情報を提供することができる。
【００９９】
ＲＯＵＴＥである場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ、又はこれらを伝達するＬＣＴセッションをサービスシグナリングチャンネルと呼ぶこともできる。ＭＭＴＰである場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、又はこれらを伝達するパケットフローをサービスシグナリングチャンネルと呼ぶこともできる。
【０１００】
図図示の実施例とは異なり、一つのＲＯＵＴＥ又はＭＭＴＰセッションは複数個のＰＬＰを介して伝達され得る。すなわち、一つのサービスは一つ以上のＰＬＰを介して伝達されてもよい。前述したように、一つのＬＣＴセッションは一つのＰＬＰを介して伝達され得る。図示されたものとは異なり、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＲＯＵＴＥセッションを介して伝達されてもよい。また、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＭＭＴＰセッションを介して伝達されてもよい。実施例によって、一つのサービスを構成するコンポーネントが、ＲＯＵＴＥセッションとＭＭＴＰセッションとに分けられて伝達されてもよい。図示してはいないが、一つのサービスを構成するコンポーネントが、ブロードバンドを介して伝達（ハイブリッドデリバリー）される場合もあり得る。
【０１０１】
図５は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。
【０１０２】
以下、ＲＯＵＴＥに基づいたデリバリーにおいて、サービスレイヤーシグナリングについて説明する。
【０１０３】
ＳＬＳは、サービス及びそのコンテンツコンポーネントの発見及び接近を可能にするために、受信機に、具体的な技術的な情報を提供する。それは、専用ＬＣＴセッションで伝達されるＸＭＬコーディングされたメタデータ分割の集合を含むことができる。当該ＬＣＴセッションは、前述したように、ＳＬＴに含まれたブートストラップ情報を用いて獲得することができる。ＳＬＳは、サービスレベル毎に定義され、それは、コンテンツコンポーネントのリスト、どのようにそれらを獲得するのか、サービスの有意義なプレゼンテーションを行うために要求される受信機の性能のようなサービスのアクセス情報及び特徴を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、リニアサービスデリバリーのために、ＳＬＳは、ＵＳＢＤ、Ｓ−ＴＳＩＤ及びＤＡＳＨ ＭＰＤのようなメタデータ分割で構成される。ＳＬＳ分割は、ＴＳＩ＝０である専用のＬＣＴ伝送セッションで伝達され得る。実施例によって、ＳＬＳフラグメントが伝達される特定のＬＣＴセッション（ｄｅｄｉｃａｔｅｄ  ＬＣＴ  ｓｅｓｓｉｏｎ）のＴＳＩは、異なる値を有してもよい。実施例によって、ＳＬＳフラグメントが伝達されるＬＣＴセッションが、ＳＬＴ又は他の方法によってシグナリングされてもよい。
【０１０４】
ＲＯＵＴＥ／ＤＡＳＨ ＳＬＳは、ＵＳＢＤ及びＳ−ＴＳＩＤメタデータ分割を含むことができる。これらサービスシグナリング分割は、リニア及びアプリケーションに基づいたサービスに適用され得る。ＵＳＢＤ分割は、サービス識別、装置性能情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ分割に対する参照、受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＳ−ＴＳＩＤ分割は、サービスのメディアコンテンツコンポーネントが伝達される１つ以上のＲＯＵＴＥ／ＬＣＴセッションに対する伝送セッションディスクリプション、及び当該ＬＣＴセッションで伝達されるデリバリーオブジェクトのディスクリプションを提供する。ＵＳＢＤ及びＳ−ＴＳＩＤは後述する。
【０１０５】
ＲＯＵＴＥに基づいたデリバリーにおけるＳｔｒｅａｍｉｎｇ Ｃｏｎｔｅｎｔ Ｓｉｇｎａｌｉｎｇにおいて、ＳＬＳのストリーミングコンテンツシグナリングコンポーネントはＭＰＤフラグメントに該当する。ＭＰＤは、主にストリーミングコンテンツとしてのＤＡＳＨ分割のデリバリーのためのリニアサービスと関連する。ＭＰＤは、分割ＵＲＬの形態のリニア／ストリーミングサービスの個別メディアコンポーネントに対するソース識別子、及びメディアプレゼンテーション内の識別されたリソースのコンテキストを提供する。ＭＰＤについての具体的な内容は後述する。
【０１０６】
ＲＯＵＴＥに基づいたデリバリーにおけるアプリベースのエンハンスメントシグナリングにおいて、アプリベースのエンハンスメントシグナリングは、アプリケーションロジックファイル、局部的にキャッシュされたメディアファイル、ネットワークコンテンツアイテム、又は公知のストリームのようなアプリベースのエンハンスメントコンポーネントのデリバリーに属する。アプリケーションはまた、可能な場合、ブロードバンドコネクション上で局部的にキャッシュされたデータを検索することができる。
【０１０７】
以下、本図に示したＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
【０１０８】
トップレベル又はエントリーポイントＳＬＳ分割はＵＳＢＤ分割である。図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
【０１０９】
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、一つのサービスに対するインスタンスであり得る。
【０１１０】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓ、＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉ、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄを含むことができる。
【０１１１】
＠ｓｅｒｖｉｃｅＩｄは、ＢＳＩＤの範囲内で唯一のサービスを識別する全世界的に唯一のＵＲＩであり得る。当該パラメータは、ＥＳＧデータ（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）とリンクするのに使用することができる。
【０１１２】
＠ａｔｓｃ：ｓｅｒｖｉｃｅｄは、ＬＬＳ（ＳＬＴ）において該当するサービスエントリーに対するレファレンスである。当該属性の値は、当該エントリーに割り当てられたｓｅｒｖｉｃｅＩｄの値と同一である。
【０１１３】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓは、当該サービスの状態を特定することができる。その値は、当該サービスが活性化されているかあるいは非活性化されているかを示す。「１」（真）に設定されると、サービスが活性化されていることを示す。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
【０１１４】
＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉは、ブロードキャスト上で選択的に、また、ブロードバンド上で伝達されるサービスのコンテンツコンポーネントに対するディスクリプションを含むＭＰＤ分割を参照することができる。
【０１１５】
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤ分割を参照することができる。
【０１１６】
ｎａｍｅは、ｌａｎｇ属性によって与えられるサービスのネームを示すことができる。ｎａｍｅエレメントは、サービスネームの言語を示すｌａｎｇ属性を含むことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
【０１１７】
ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの利用可能な言語を示すことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
【０１１８】
ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、受信機が当該サービスのコンテンツの有意義なプレゼンテーションを生成できるように要求されるケイパビリティを特定することができる。実施例によって、このフィールドは、前もって定義されたケイパビリティグループを特定してもよい。ここで、ケイパビリティグループは、有意義なプレゼンテーションのためのケイパビリティ属性値のグループであり得る。このフィールドは、実施例によって省略されてもよい。
【０１１９】
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄは、アクセスのブロードキャスト及び（選択的に）ブロードバンドモード上でサービスのコンテンツに属する情報に関連するトランスポートのコンテナであり得る。当該サービスに含まれるデータにおいて、そのデータをＮ個とすれば、そのそれぞれのデータに対するデリバリー方法が、このエレメントによって記述され得る。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及びｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。それぞれの下位エレメントは、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。
【０１２０】
ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する当該メディアコンポーネントを含む、多重化又は非多重化された形態のブロードキャスト上で伝達されるＤＡＳＨレプレゼンテーションであり得る。すなわち、それぞれのこのフィールドは、放送ネットワークを介して伝達されるＤＡＳＨレプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
【０１２１】
ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する構成メディアコンテンツコンポーネントを含む、多重化又は非多重化された形態のブロードバンド上で伝達されるＤＡＳＨレプレゼンテーションであり得る。すなわち、それぞれのこのフィールドは、ブロードバンドを介して伝達されるＤＡＳＨレプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
【０１２２】
ｂａｓｅＰａｔｔｅｒｎは、含まれた期間にペアレントレプレゼンテーションのメディア分割を要求するためにＤＡＳＨクライアントによって使用される分割ＵＲＬの全ての部分に対してマッチングされるように受信機によって使用される文字パターンであり得る。マッチは、当該要求されたメディア分割がブロードキャストトランスポート上で伝達されることを暗示する。それぞれのｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントとｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで表現されるＤＡＳＨレプレゼンテーションを受信できるＵＲＬアドレスにおいて、そのＵＲＬの一部分などは特定のパターンを有することができ、そのパターンがこのフィールドによって記述され得る。この情報を通じて、一定の部分のデータに対する区分が可能である。提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０１２３】
図６は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。
【０１２４】
以下、本図に示したＳ−ＴＳＩＤの具体的な内容について説明する。
【０１２５】
Ｓ−ＴＳＩＤは、サービスのコンテンツコンポーネントを伝達する伝送セッションに対する全体的なセッションディスクリプション情報を提供するＳＬＳ ＸＭＬ分割であり得る。Ｓ−ＴＳＩＤは、サービスのメディアコンテンツコンポーネントが伝達される構成ＬＣＴセッション、及び０個以上のＲＯＵＴＥセッションに対する全体的な伝送セッションディスクリプション情報を含む、ＳＬＳメタデータ分割である。Ｓ−ＴＳＩＤはまた、ＬＣＴセッションで伝達されるコンテンツコンポーネント及びペイロードフォーマットで対する追加情報だけでなく、サービスのＬＣＴセッションで伝達されるデリバリーオブジェクト又はオブジェクトフローに対するファイルメタデータを含む。
【０１２６】
Ｓ−ＴＳＩＤ分割の各インスタンスは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントの＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ属性によってＵＳＢＤ分割で参照される。図示された本発明の一実施例に係るＳ−ＴＳＩＤは、ＸＭＬドキュメントの形態に表現された。実施例によって、Ｓ−ＴＳＩＤは、バイナリフォーマット又はＸＭＬドキュメントの形態に表現されてもよい。
【０１２７】
図示されたＳ−ＴＳＩＤは、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ及び／又はＲＳを含むことができる。
【０１２８】
＠ｓｅｒｖｉｃｅＩＤは、ＵＳＤでサービスエレメントに該当するレファレンスであり得る。当該属性の値は、ｓｅｒｖｉｃｅ_ｉｄの当該値を有するサービスを参照することができる。
【０１２９】
ＲＳエレメントは、当該サービスデータを伝達するＲＯＵＴＥセッションについての情報を有することができる。複数個のＲＯＵＴＥセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、このエレメントは１個〜Ｎ個の個数を有することができる。
【０１３０】
ＲＳエレメントは、＠ｂｓｉｄ、＠ｓＩｐＡｄｄｒ、＠ｄＩｐＡｄｄｒ、＠ｄｐｏｒｔ、＠ＰＬＰＩＤ及び／又はＬＳを含むことができる。
【０１３１】
＠ｂｓｉｄは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのコンテンツコンポーネントが伝達されるブロードキャストストリームの識別子であり得る。当該属性が存在しない場合、デフォルトブロードキャストストリームのＰＬＰが当該サービスに対するＳＬＳ分割を伝達することであり得る。その値は、ＳＬＴでｂｒｏａｄｃａｓｔ_ｓｔｒｅａｍ_ｉｄと同一であり得る。
【０１３２】
＠ｓＩｐＡｄｄｒは、ソースＩＰアドレスを示すことができる。ここで、ソースＩＰアドレスは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのソースＩＰアドレスであり得る。前述したように、一つのサービスのサービスコンポーネントは、複数個のＲＯＵＴＥセッションを介して伝達されてもよい。そのため、当該Ｓ−ＴＳＩＤが伝達されるＲＯＵＴＥセッションではない他のＲＯＵＴＥセッションでそのサービスコンポーネントが伝送されてもよい。したがって、ＲＯＵＴＥセッションのソースＩＰアドレスを指示するためにこのフィールドが使用され得る。このフィールドのデフォルト値は、現在のＲＯＵＴＥセッションのソースＩＰアドレスであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、このフィールド値は、そのＲＯＵＴＥセッションのソースＩＰアドレス値であり得る。この場合、このフィールドはＭ、すなわち、必須のフィールドであり得る。
【０１３３】
＠ｄＩｐＡｄｄｒは、デスティネーションＩＰアドレスを示すことができる。ここで、デスティネーションＩＰアドレスは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションＩＰアドレスであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、このフィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションＩＰアドレスを指示してもよい。このフィールドのデフォルト値は、現在のＲＯＵＴＥセッションのデスティネーションＩＰアドレスであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、このフィールド値は、そのＲＯＵＴＥセッションのデスティネーションＩＰアドレス値であり得る。この場合、このフィールドはＭ、すなわち、必須フィールドであり得る。
【０１３４】
＠ｄｐｏｒｔは、デスティネーションポートを示すことができる。ここで、デスティネーションポートは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションポートであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、このフィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションポートを指示することができる。このフィールドのデフォルト値は、現在のＲＯＵＴＥセッションのデスティネーションポートナンバーであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、このフィールド値は、そのＲＯＵＴＥセッションのデスティネーションポートナンバー値であり得る。この場合、このフィールドはＭ、すなわち、必須フィールドであり得る。
【０１３５】
＠ＰＬＰＩＤは、ＲＳで表現されるＲＯＵＴＥセッションのためのＰＬＰのＩＤであり得る。デフォルト値は、現在のＳ−ＴＳＩＤが含まれたＬＣＴセッションのＰＬＰのＩＤであり得る。実施例によって、このフィールドは、当該ＲＯＵＴＥセッションでＳ−ＴＳＩＤが伝達されるＬＣＴセッションのためのＰＬＰのＩＤ値を有してもよく、当該ＲＯＵＴＥセッションのための全てのＰＬＰのＩＤ値を有してもよい。
【０１３６】
ＬＳエレメントは、当該サービスデータを伝達するＬＣＴセッションについての情報を有することができる。複数個のＬＣＴセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、このエレメントは、１個〜Ｎ個の個数を有することができる。
【０１３７】
ＬＳエレメントは、＠ｔｓｉ、＠ＰＬＰＩＤ、＠ｂｗ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅ、ＳｒｃＦｌｏｗ及び／又はＲｐｒＦｌｏｗを含むことができる。
【０１３８】
＠ｔｓｉは、当該サービスのサービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ値を指示することができる。
【０１３９】
＠ＰＬＰＩＤは、当該ＬＣＴセッションのためのＰＬＰのＩＤ情報を有することができる。この値は、基本ＲＯＵＴＥセッション値を上書きしてもよい。
【０１４０】
＠ｂｗは、最大の帯域値を指示することができる。＠ｓｔａｒｔＴｉｍｅは当該ＬＣＴセッションのスタートタイム（Ｓｔａｒｔ  ｔｉｍｅ）を指示することができる。＠ｅｎｄＴｉｍｅは、当該ＬＣＴセッションのエンドタイム（Ｅｎｄ  ｔｉｍｅ）を指示することができる。ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローに対して記述することができる。ＲｐｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアーフローに対して記述することができる。
【０１４１】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須フィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０１４２】
以下、ＲＯＵＴＥ／ＤＡＳＨのためのＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
【０１４３】
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＤＡＳＨメディアプレゼンテーションの公式化されたディスクリプションを含むＳＬＳメタデータ分割である（例えば、ある期間の間の一つのＴＶプログラム又は連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、メディアプレゼンテーション内で識別されたリソースに対するコンテキスト及び分割に対するソース識別子を提供する。ＭＰＤ分割のデータ構造及びセマンティクスは、ＭＰＥＧ ＤＡＳＨによって定義されたＭＰＤに従うことができる。
【０１４４】
ＭＰＤで伝達される１つ以上のＤＡＳＨレプレゼンテーションは、ブロードキャスト上で伝達され得る。ＭＰＤは、ハイブリッドサービスである場合のようなブロードバンド上で伝達される追加レプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、トンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
【０１４５】
図７は、本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。
【０１４６】
リニアサービスのためのＭＭＴ ＳＬＳは、ＵＳＢＤ分割及びＭＰテーブルを含む。ＭＰテーブルは、前述した通りである。ＵＳＢＤ分割は、サービス識別、装置性能情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ分割に対する参照、及び受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＭＰＵコンポーネントに対するＭＰテーブルは、サービスのメディアコンテンツコンポーネントが伝達されるＭＭＴＰセッションに対する伝送セッションディスクリプション、及びＭＭＴＰセッションで伝達されるアセットのディスクリプションを提供する。
【０１４７】
ＭＰＵコンポーネントに対するＳＬＳのストリーミングコンテンツシグナリングコンポーネントは、ＭＭＴで定義されたＭＰテーブルに該当する。ＭＰテーブルは、各アセットが単一のサービスコンポーネントに該当するＭＭＴアセットのリスト、及び当該コンポーネントに対する位置情報のディスクリプションを提供する。
【０１４８】
ＵＳＢＤ分割は、ＲＯＵＴＥプロトコル及びブロードバンドによってそれぞれ伝達されるサービスコンポーネントに対して、前述したようなＳ−ＴＳＩＤ及びＭＰＤに対する参照も含むことができる。実施例によって、ＭＭＴを通じたデリバリーにおいて、ＲＯＵＴＥプロトコルを介して伝達されるサービスコンポーネントはＮＲＴなどのデータであるので、この場合において、ＭＰＤは用いられなくてもよい。また、ＭＭＴを通じたデリバリーにおいて、ブロードバンドを介して伝達されるサービスコンポーネントはどのＬＣＴセッションを介して伝達されるかについての情報が必要でないので、Ｓ−ＴＳＩＤは用いられなくてもよい。ここで、ＭＭＴパッケージは、ＭＭＴを用いて伝達される、メディアデータの論理的コレクションであり得る。ここで、ＭＭＴＰパケットは、ＭＭＴを用いて伝達されるメディアデータのフォーマットされたユニットを意味し得る。ＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）は、独立してデコーディング可能なタイムド／ノン−タイムドデータのジェネリックコンテナを意味し得る。ここで、ＭＰＵでのデータはメディアコーデックアグノスティックである。
【０１４９】
以下、本図に示したＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
【０１５０】
図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
【０１５１】
図示された本発明の一実施例に係るＵＳＢＤは、ＸＭＬドキュメントの形態に表現された。実施例によって、ＵＳＢＤは、バイナリフォーマット又はＸＭＬドキュメントの形態に表現されてもよい。
【０１５２】
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであり得る。
【０１５３】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ、ａｔｓｃ：Ｃｈａｎｎｅｌ、ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｂｒｏａｄｂａｎｄ Ｃｏｍｐｏｎｅｎｔ及び／又はａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏを含むことができる。
【０１５４】
ここで、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、前述したものと同一であり得る。ｎａｍｅフィールドの下のｌａｎｇフィールドも、前述したものと同一であり得る。ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、実施例によって省略されてもよい。
【０１５５】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、実施例によってａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントをさらに含むことができる。このエレメントはオプショナルエレメントであり得る。ａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇは、コンテンツ諮問順位を特定することができる。このフィールドは図示していない。
【０１５６】
ａｔｓｃ：Ｃｈａｎｎｅｌは、サービスのチャンネルについての情報を有することができる。ａｔｓｃ：Ｃｈａｎｎｅｌエレメントは、＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎ及び／又はａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎを含むことができる。＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、実施例によって省略されてもよい。
【０１５７】
＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの主チャンネルナンバーを示す属性である。
【０１５８】
＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの副チャンネルナンバーを示す属性である。
【０１５９】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、サービスで使用される主要言語を示す属性である。
【０１６０】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅは、サービスの主要ジャンルを示す属性である。
【０１６１】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎは、当該サービスを表現するために使用されるアイコンに対するＵＲＬを示す属性である。
【０１６２】
ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、サービスディスクリプションを含み、これは多重言語であり得る。ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ及び／又は＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇを含むことができる。
【０１６３】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔは、サービスのディスクリプションを示す属性である。
【０１６４】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇは、ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性の言語を示す属性である。
【０１６５】
ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、ＭＰＵの形態で伝達されるサービスのコンテンツコンポーネントについての情報を有することができる。ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄ及び／又は＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄを含むことができる。
【０１６６】
＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに対するＭＭＴパッケージを参照することができる。
【０１６７】
＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに合わせて＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄによって参照された後に使用されるＭＭＴパッケージを参照することができる。
【０１６８】
ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、ＲＯＵＴＥを介して伝達されるサービスのコンテンツコンポーネントについての情報を有することができる。ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、＠ｓＴＳＩＤＰｌｐＩｄ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓＴＳＩＤＳｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを含むことができる。
【０１６９】
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤ分割を参照することができる。このフィールドは、前述したＲＯＵＴＥのためのＵＳＢＤでのＳ−ＴＳＩＤを参照するためのＵＲＩと同一であり得る。前述したように、ＭＭＴＰによるサービスデリバリーにおいても、ＮＲＴなどを介して伝達されるサービスコンポーネントはＲＯＵＴＥによって伝達され得る。そのためのＳ−ＴＳＩＤを参照するために、このフィールドが使用され得る。
【０１７０】
＠ｓＴＳＩＤＰｌｐＩｄは、当該サービスに対するＳ−ＴＳＩＤを伝達するＰＬＰのＰＬＰ ＩＤを示す整数を表現するストリングであり得る。（デフォルト：現在のＰＬＰ）
【０１７１】
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４デスティネーションアドレスを含むストリングであり得る。（デフォルト：現在のＭＭＴＰセッションのソースＩＰアドレス）
【０１７２】
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのポートナンバーを含むストリングであり得る。
【０１７３】
＠ｓＴＳＩＤＳｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソースアドレスを含むストリングであり得る。
【０１７４】
＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの主バージョンナンバーを示すことができる。デフォルト値は１である。
【０１７５】
＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの副バージョンナンバーを示すことができる。デフォルト値は０である。
【０１７６】
ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、ブロードバンドを介して伝達されるサービスのコンテンツコンポーネントについての情報を有することができる。すなわち、ハイブリッドデリバリーを想定したフィールドであり得る。ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉをさらに含むことができる。
【０１７７】
＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉは、ブロードバンドで伝達されるサービスのコンテンツコンポーネントに対するディスクリプションを含むＭＰＤ分割に対するレファレンスであり得る。
【０１７８】
ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、サービスのアベイラブルな（ａｖａｉｌａｂｌｅ）コンポーネントについての情報を有することができる。それぞれのコンポーネントに対する、タイプ、ロール、名などの情報を有することができる。各コンポーネント（Ｎ個）の数だけこのフィールドが存在することができる。ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄ及び／又は＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅを含むことができる。
【０１７９】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅは、当該コンポーネントのタイプを示す属性である。０の値はオーディオコンポーネントを示す。１の値はビデオコンポーネントを示す。２の値はクローズドキャプションコンポーネントを示す。３の値はアプリケーションコンポーネントを示す。４〜７の値は残す。このフィールド値の意味は、実施例によって異なって設定されてもよい。
【０１８０】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅは、当該コンポーネントの役割及び種類を示す属性である。
【０１８１】
オーディオに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が０と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｃｏｍｐｌｅｔｅ ｍａｉｎ、１＝音楽及び効果（Ｍｕｓｉｃ  ａｎｄ  Ｅｆｆｅｃｔｓ）、２＝対話（Ｄｉａｌｏｇ）、３＝解説（Ｃｏｍｍｅｎｔａｒｙ）、４＝視覚障害（Ｖｉｓｕａｌｌｙ  Ｉｍｐａｉｒｅｄ）、５＝聴覚障害（Ｈｅａｒｉｎｇ  Ｉｍｐａｉｒｅｄ）、６＝ボイスオーバー（Ｖｏｉｃｅ−Ｏｖｅｒ）、７−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１８２】
オーディオに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が１と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｐｒｉｍａｒｙ ｖｉｄｅｏ、１＝代替カメラビュー（Ａｌｔｅｒｎａｔｉｖｅ  ｃａｍｅｒａ  ｖｉｅｗ）、２＝他の代替ビデオコンポーネント（Ｏｔｈｅｒ  ａｌｔｅｒｎａｔｉｖｅ  ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）、３＝手話挿入（Ｓｉｇｎ  ｌａｎｇｕａｇｅ  ｉｎｓｅｔ）、４＝Ｆｏｌｌｏｗ ｓｕｂｊｅｃｔ ｖｉｄｅｏ、５＝３Ｄビデオの左側ビュー（３Ｄ  ｖｉｄｅｏ  ｌｅｆｔ  ｖｉｅｗ）、６＝３Ｄビデオの右側ビュー（３Ｄ  ｖｉｄｅｏ  ｒｉｇｈｔ  ｖｉｅｗ）、７＝３Ｄビデオの深さ情報（３Ｄ  ｖｉｄｅｏ  ｄｅｐｔｈ  ｉｎｆｏｒｍａｔｉｏｎ）、８＝Ｐａｒｔ ｏｆ ｖｉｄｅｏ ａｒｒａｙ ＜ｘ，ｙ＞ ｏｆ ＜ｎ，ｍ＞、９＝Ｆｏｌｌｏｗ−Ｓｕｂｊｅｃｔ ｍｅｔａｄａｔａ、１０−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１８３】
クローズドキャプションコンポーネントに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が２と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｎｏｒｍａｌ、１＝Ｅａｓｙ ｒｅａｄｅｒ、２−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１８４】
ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性の値が３と７との間であれば、ｃｏｍｐｏｎｅｎｔＲｏｌｅ２５５と同一であり得る。このフィールド値の意味は、実施例によって異なって設定されてもよい。
【０１８５】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇは、当該コンポーネントが保護されるか（例えば、暗号化されるか）を示す属性である。当該フラグが１の値に設定されると、当該コンポーネントは保護される（例えば、暗号化される）。当該フラグが０の値に設定されると、当該コンポーネントは保護されない（例えば、暗号化されない）。存在しない場合、ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性の値は０と同一であると推論される。このフィールド値の意味は、実施例によって異なって設定されてもよい。
【０１８６】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄは、当該コンポーネントの識別子を示す属性である。当該属性の値は、当該コンポーネントに該当するＭＰテーブルにおいてａｓｓｅｔ_ｉｄと同一であり得る。
【０１８７】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅは、当該コンポーネントの人が読み取り可能な名を示す属性である。
【０１８８】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０１８９】
以下、ＭＭＴのためのＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
【０１９０】
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＳＬＳメタデータ分割である（例えば、一つのＴＶプログラム、又はある期間の間の連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、分割に対するリソース識別子、及びメディアプレゼンテーション内で識別されたリソースに対するコンテキストを提供する。ＭＰＤのデータ構造及びセマンティクスは、ＭＰＥＧ ＤＡＳＨによって定義されたＭＰＤに従うことができる。
【０１９１】
本発明の実施例において、ＭＭＴＰセッションによって伝達されるＭＰＤは、ハイブリッドサービスである場合のようなブロードバンド上で伝達されるレプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、山の下やトンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
【０１９２】
以下、ＭＭＴのためのＭＭＴシグナリングメッセージについて説明する。
【０１９３】
ＭＭＴＰセッションがストリーミングサービスを伝達するために使用される場合、ＭＭＴによって定義されたＭＭＴシグナリングメッセージは、ＭＭＴによって定義されたシグナリングメッセージモードに応じてＭＭＴＰパケットによって伝達される。アセットを伝達するＭＭＴＰパケットと同一のｐａｃｋｅｔ_ｉｄ値に設定され得る、アセットに特定のＭＭＴシグナリングメッセージを伝達するＭＭＴＰパケットを除いて、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ_ｉｄフィールドの値は「００」に設定される。各サービスに対する適切なパケットを参照する識別子は、前述したように、ＵＳＢＤ分割によってシグナリングされる。マッチングするＭＭＴ_ｐａｃｋａｇｅ_ｉｄを有するＭＰＴメッセージは、ＳＬＴでシグナリングされるＭＭＴＰセッション上で伝達され得る。各ＭＭＴＰセッションは、そのセッションに特定のＭＭＴシグナリングメッセージ、又はＭＭＴＰセッションによって伝達される各アセットを伝達する。
【０１９４】
すなわち、ＳＬＴで特定のサービスに対するＳＬＳを有するパケットのＩＰデスティネーションアドレス／ポートナンバーなどを特定して、ＭＭＴＰセッションのＵＳＢＤに接近することができる。前述したように、ＳＬＳを運搬するＭＭＴＰパケットのパケットＩＤは、００などの特定の値として指定できる。ＵＳＢＤの前述したパッケージＩＤ情報を用いて、マッチングされるパッケージＩＤを有するＭＰＴメッセージに接近することができる。ＭＰＴメッセージは、後述するように、各サービスコンポーネント／アセットに接近するために使用することができる。
【０１９５】
次のＭＭＴＰメッセージは、ＳＬＴでシグナリングされるＭＭＴＰセッションによって伝達され得る。
【０１９６】
ＭＰＴメッセージ：このメッセージは、全てのアセットのリスト及びＭＭＴによって定義されたようなそれらの位置情報を含む、ＭＰテーブルを伝達する。アセットがＭＰテーブルを伝達する現ＰＬＰと異なるＰＬＰによって伝達されると、当該アセットを伝達するＰＬＰの識別子は、ＰＬＰ識別子ディスクリプタを使用したＭＰテーブルで提供され得る。ＰＬＰ識別子ディスクリプタについては後述する。
【０１９７】
ＭＭＴ ＡＴＳＣ３（ＭＡ３） ｍｅｓｓａｇｅ ｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）：このメッセージは、前述したように、ＳＬＳを含むサービスに特定のシステムメタデータを伝達する。ｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）については後述する。
【０１９８】
次のＭＭＴＰメッセージは、必要であれば、ＳＬＴでシグナリングされたＭＭＴＰセッションによって伝達されてもよい。
【０１９９】
ＭＰＩメッセージ：このメッセージは、プレゼンテーション情報の全てのドキュメント又は一部のドキュメントを含む、ＭＰＩテーブルを伝達する。ＭＰＩテーブルと関連するＭＰテーブルは、このメッセージによって伝達され得る。
【０２００】
ＣＲＩ（ｃｌｏｃｋ  ｒｅｌａｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）メッセージ：このメッセージは、ＮＴＰタイムスタンプとＭＰＥＧ−２ ＳＴＣとの間のマッピングのためのクロック関連情報を含むＣＲＩテーブルを伝達する。実施例によって、ＣＲＩメッセージは当該ＭＭＴＰセッションを介して伝達されなくてもよい。
【０２０１】
次のＭＭＴＰメッセージは、ストリーミングコンテンツを伝達する各ＭＭＴＰセッションによって伝達され得る。
【０２０２】
仮想的な受信機バッファーモデルメッセージ：このメッセージは、バッファーを管理するために受信機によって要求される情報を伝達する。
【０２０３】
仮想的な受信機バッファーモデル除去メッセージ：このメッセージは、ＭＭＴデカプセレーションバッファーを管理するために受信機によって要求される情報を伝達する。
【０２０４】
以下、ＭＭＴシグナリングメッセージのうち１つであるｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）について説明する。ＭＭＴシグナリングメッセージであるｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）は、前述した本発明によって、サービスに特定の情報を伝達するために定義される。本シグナリングメッセージは、ＭＭＴシグナリングメッセージの基本的なフィールドであるメッセージＩＤ、バージョン及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。本シグナリングメッセージのペイロードには、サービスＩＤ情報、コンテンツタイプ、コンテンツバージョン、コンテンツコンプレッション情報及び／又はＵＲＩ情報が含まれてもよい。コンテンツタイプ情報は、本シグナリングメッセージのペイロードに含まれるデータのタイプを示すことができる。コンテンツバージョン情報は、ペイロードに含まれるデータのバージョンを、コンテンツコンプレッション情報は、当該データに適用されたコンプレッションタイプを示すことができる。ＵＲＩ情報は、本メッセージによって伝達されるコンテンツと関連するＵＲＩ情報を有することができる。
【０２０５】
以下、ＰＬＰ識別子ディスクリプタについて説明する。
【０２０６】
ＰＬＰ識別子ディスクリプタは、前述したＭＰテーブルのディスクリプタのうち１つとして使用できるディスクリプタである。ＰＬＰ識別子ディスクリプタは、アセットを伝達するＰＬＰについての情報を提供する。アセットが、ＭＰテーブルを伝達する現在のＰＬＰと異なるＰＬＰによって伝達されると、ＰＬＰ識別子ディスクリプタは、そのアセットを伝達するＰＬＰを識別するために、関連するＭＰテーブルでアセットディスクリプタとして使用され得る。ＰＬＰ識別子ディスクリプタは、ＰＬＰ ＩＤ情報以外にＢＳＩＤ情報をさらに含むこともできる。ＢＳＩＤは、このディスクリプタによって記述されるＡｓｓｅｔのためのＭＭＴＰパケットを伝達するブロードキャストストリームのＩＤであり得る。
【０２０７】
図８は、本発明の一実施例に係るリンクレイヤープロトコルアーキテクチャーを示した図である。
【０２０８】
以下、リンクレイヤー（Ｌｉｎｋ  Ｌａｙｅｒ）について説明する。
【０２０９】
リンクレイヤーは、フィジカルレイヤーとネットワークレイヤーとの間のレイヤーであり、送信側では、ネットワークレイヤーからフィジカルレイヤーにデータを伝送し、受信側では、フィジカルレイヤーからネットワークレイヤーにデータを伝送する。リンクレイヤーの目的は、フィジカルレイヤーによる処理のために全ての入力パケットタイプを一つのフォーマットで要約すること、まだ定義されていない入力タイプに対する柔軟性、及び将来の拡張可能性を保障することである。また、リンクレイヤー内で処理すれば、例えば、入力パケットのヘッダーにある不必要な情報を圧縮するのにオプションを提供することによって、入力データを効率的に伝送できるように保障する。カプセル化、コンプレッションなどの動作はリンクレイヤープロトコルと呼ばれ、当該プロトコルを用いて生成されたパケットはリンクレイヤーパケットと呼ばれる。リンクレイヤーは、パケットカプセル化（ｐａｃｋｅｔ  ｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッドリダクション（Ｏｖｅｒｈｅａｄ  Ｒｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（Ｓｉｇｎａｌｉｎｇ  Ｔｒａｎｓｍｉｓｓｉｏｎ）などの機能を行うことができる。
【０２１０】
以下、パケットカプセル化について説明する。リンクレイヤープロトコルは、ＩＰパケット及びＭＰＥＧ−２ ＴＳのようなものを含む全てのタイプのパケットのカプセル化を可能にする。リンクレイヤープロトコルを用いて、フィジカルレイヤーは、ネットワークレイヤープロトコルタイプと独立して一つのパケットフォーマットのみを処理すればよい（ここで、ネットワークレイヤーパケットの一種としてＭＰＥＧ−２ ＴＳパケットを考慮）。各ネットワークレイヤーパケット又は入力パケットは、ジェネリックリンクレイヤーパケットのペイロードに変形する。さらに、入力パケットのサイズが特に小さいか又は大きい場合、フィジカルレイヤーリソースを効率的に用いるために、連鎖及び分割を行うことができる。
【０２１１】
前述したように、パケットカプセル化過程で分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワークレイヤーパケットが大きすぎるため、フィジカルレイヤーで容易に処理できない場合、ネットワークレイヤーパケットは２つ以上の分割に分けられる。リンクレイヤーパケットヘッダーは、送信側で分割を行い、受信側で再結合を行うために、プロトコルフィールドを含む。ネットワークレイヤーパケットが分割される場合、各分割は、ネットワークレイヤーパケットでの元の位置と同一の順序でリンクレイヤーパケットにカプセル化されてもよい。また、ネットワークレイヤーパケットの分割を含む各リンクレイヤーパケットは、結果的にフィジカルレイヤーに伝送されてもよい。
【０２１２】
前述したように、パケットカプセル化過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）も活用することができる。リンクレイヤーパケットのペイロードが多数のネットワークレイヤーパケットを含む程度にネットワークレイヤーパケットが十分に小さい場合、リンクレイヤーパケットヘッダーは、連鎖を行うためにプロトコルフィールドを含む。連鎖は、多数の小さい大きさのネットワークレイヤーパケットを一つのペイロードに結合したものである。ネットワークレイヤーパケットが連鎖すれば、各ネットワークレイヤーパケットは、元の入力順序と同一の順序でリンクレイヤーパケットのペイロードに連鎖することができる。また、リンクレイヤーパケットのペイロードを構成する各パケットは、パケットの分割ではない全体パケットであり得る。
【０２１３】
以下、オーバーヘッドリダクションについて説明する。リンクレイヤープロトコルの使用により、フィジカルレイヤー上でデータの伝送に対するオーバーヘッドを大きく減少させることができる。本発明に係るリンクレイヤープロトコルは、ＩＰオーバーヘッドリダクション及び／又はＭＰＥＧ−２ ＴＳオーバーヘッドリダクションを提供することができる。ＩＰオーバーヘッドリダクションにおいて、ＩＰパケットは、固定されたヘッダーフォーマットを有しているが、通信環境で必要な一部の情報はブロードキャスト環境で不要であることができる。リンクレイヤープロトコルは、ＩＰパケットのヘッダーを圧縮することによってブロードキャストオーバーヘッドを低減するメカニズムを提供する。ＭＰＥＧ−２ ＴＳオーバーヘッドリダクションにおいて、リンクレイヤープロトコルは、シンクバイト除去、ヌルパケット削除及び／又は共通ヘッダー除去（圧縮）を提供する。まず、シンクバイト除去は、ＴＳパケット当たり１バイトのオーバーヘッドリダクションを提供し、次に、ヌルパケット削除メカニズムは、受信機で再挿入できる方式で１８８バイトのヌルＴＳパケットを除去する。最後に、共通ヘッダー除去メカニズムが提供される。
【０２１４】
シグナリング伝送に対して、リンクレイヤープロトコルは、シグナリングパケットのための特定のフォーマットが、リンクレイヤーシグナリングを伝達するために提供され得る。これについては後述する。
【０２１５】
図示された本発明の一実施例に係るリンクレイヤープロトコルアーキテクチャーにおいて、リンクレイヤープロトコルは、入力パケットとして、ＩＰｖ４、ＭＰＥＧ−２ ＴＳなどの入力ネットワークレイヤーパケットを取る。将来の拡張は、他のパケットタイプとリンクレイヤーで入力され得るプロトコルを示す。リンクレイヤープロトコルは、フィジカルレイヤーで特定のチャンネルに対するマッピングについての情報を含む全てのリンクレイヤーシグナリングに対するシグナリング及びフォーマットを特定する。図面は、ＡＬＰがどのように様々なヘッダーコンプレッション及び削除アルゴリズムを介して伝送効率を向上させるためにメカニズムを含むかを示す。また、リンクレイヤープロトコルは、基本的に入力パケットをカプセル化することができる。
【０２１６】
図９は、本発明の一実施例に係るリンクレイヤーパケットのベースヘッダー構造を示した図である。以下、ヘッダーの構造について説明する。
【０２１７】
リンクレイヤーパケットは、データペイロードが後続するヘッダーを含むことができる。リンクレイヤーパケットのヘッダーは、ベースヘッダーを含むことができ、ベースヘッダーのコントロールフィールドに応じて追加ヘッダーを含むことができる。オプショナルヘッダーの存在は、追加ヘッダーのフラグフィールドから指示される。実施例によって、追加ヘッダー、オプショナルヘッダーの存在を示すフィールドはベースヘッダーに位置してもよい。
【０２１８】
以下、ベースヘッダーの構造について説明する。リンクレイヤーパケットカプセル化に対するベースヘッダーは階層構造を有する。ベースヘッダーは、２バイトの長さを有することができ、リンクレイヤーパケットヘッダーの最小長さである。
【０２１９】
図示された本発明の一実施例に係るベースヘッダーは、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。実施例によって、ベースヘッダーは、ＨＭフィールド又はＳ／Ｃフィールドをさらに含むことができる。
【０２２０】
Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは、リンクレイヤーパケットへのカプセル化の前の入力データのパケットタイプ又は元のプロトコルを示す、３ビットのフィールドである。ＩＰｖ４パケット、圧縮されたＩＰパケット（ｃｏｍｐｒｅｓｓｅｄ  ＩＰ  ｐａｃｋｅｔ）、リンクレイヤーシグナリングパケット、及びその他のタイプのパケットが、このようなベースヘッダーの構造を有し、カプセル化されてもよい。ただし、実施例によって、ＭＰＥＧ−２ ＴＳパケットは、これとは異なる特別な構造を有し、カプセル化されてもよい。Ｐａｃｋｅｔ_Ｔｙｐｅの値が“０００”、“００１”、“１００”又は“１１１”であると、ＡＬＰパケットの元のデータタイプは、ＩＰｖ４パケット、圧縮ＩＰパケット、リンクレイヤーシグナリング又はエクステンションパケットのうち１つである。ＭＰＥＧ−２ ＴＳパケットがカプセル化されると、Ｐａｃｋｅｔ_Ｔｙｐｅの値は“０１０”であり得る。他のＰａｃｋｅｔ_Ｔｙｐｅフィールドの値は、将来の使用のために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【０２２１】
Ｐａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＰＣ）フィールドは、ペイロードの構成を示す１ビットのフィールドであり得る。０の値は、リンクレイヤーパケットが一つの全体の入力パケットを伝達し、次のフィールドがＨｅａｄｅｒ_Ｍｏｄｅであることを示すことができる。１の値は、リンクレイヤーパケットが１つ以上の入力パケット（連鎖）や大きい入力パケット（分割）の一部を伝達し、次のフィールドがＳｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎであることを示すことができる。
【０２２２】
Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）フィールドは、０に設定される場合、追加ヘッダーがないことを示し、リンクレイヤーパケットのペイロードの長さが２０４８バイトよりも小さいことを示す、１ビットのフィールドであり得る。この数値は、実施例によって変更されてもよい。１の値は、下記に定義された１つのパケットのための追加ヘッダーが長さフィールドの次に存在することを示すことができる。この場合、ペイロードの長さは、２０４７バイトよりも大きく、及び／又はオプショナルフィーチャが使用され得る（サブストリーム識別、ヘッダー拡張など）。この数値は、実施例によって変更されてもよい。このフィールドは、リンクレイヤーパケットのＰａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドが０の値を有するときのみ存在し得る。
【０２２３】
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）フィールドは、０に設定された場合、ペイロードが入力パケットのセグメントを伝達し、下記に定義される分割のための追加ヘッダーが長さフィールドの次に存在することを示す、１ビットのフィールドであり得る。１の値は、ペイロードが１つよりも多い完全な入力パケットを伝達し、下記に定義された連鎖のための追加ヘッダーが長さフィールドの次に存在することを示すことができる。このフィールドは、ＡＬＰパケットのＰａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドの値が１であるときのみ存在し得る。
【０２２４】
長さフィールドは、リンクレイヤーパケットによって伝達されるペイロードのバイト単位の長さの１１ＬＳＢｓ（ｌｅａｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔｓ）を示す、１１ビットのフィールドであり得る。次の追加ヘッダーにＬｅｎｇｔｈ_ＭＳＢフィールドがあれば、長さフィールドは、Ｌｅｎｇｔｈ_ＭＳＢフィールドに連鎖し、ペイロードの実際の全長を提供するためにＬＳＢとなる。長さフィールドのビット数は、１１ビット以外に他のビットに変更されてもよい。
【０２２５】
したがって、次のパケット構造のタイプが可能である。すなわち、追加ヘッダーがない１つのパケット、追加ヘッダーがある１つのパケット、分割されたパケット、連鎖したパケットが可能である。実施例によって、各追加ヘッダーとオプショナルヘッダー、後述するシグナリング情報のための追加ヘッダーとタイプエクステンションのための追加ヘッダーによる組み合わせで、さらに多くのパケット構成が可能である。
【０２２６】
図１０は、本発明の一実施例に係るリンクレイヤーパケットの追加ヘッダーの構造を示した図である。
【０２２７】
追加ヘッダー（ａｄｄｉｔｉｏｎａｌ  ｈｅａｄｅｒ）は様々なタイプがあり得る。以下、シングルパケットのための追加ヘッダーについて説明する。
【０２２８】
１つのパケットに対する当該追加ヘッダーは、Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）＝“１”である場合に存在し得る。リンクレイヤーパケットのペイロードの長さが２０４７バイトよりも大きいか、又はオプションフィールドが使用される場合、Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）は１に設定され得る。１つのパケットの追加ヘッダー（ｔｓｉｂ１００１０）は図面に示す。
【０２２９】
Ｌｅｎｇｔｈ_ＭＳＢフィールドは、現在のリンクレイヤーパケットにおいてバイト単位の全ペイロードの長さのＭＳＢｓ（ｍｏｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔｓ）を示すことができる、５ビットのフィールドであり得、全ペイロードの長さを得るために、１１ＬＳＢを含む長さフィールドに連鎖する。したがって、シグナリングできるペイロードの最大長さは６５５３５バイトである。長さフィールドのビット数は、１１ビット以外の他のビットに変更されてもよい。また、Ｌｅｎｇｔｈ_ＭＳＢフィールドも、ビット数が変更されてもよく、これにより、最大に表現可能なペイロードの長さも変更されてもよい。実施例によって、各長さフィールドは、ペイロードではなく全リンクレイヤーパケットの長さを示してもよい。
【０２３０】
Ｓｕｂ−ｓｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒ Ｆｌａｇ（ＳＩＦ）フィールドは、ＨＥＦ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｆｌａｇ）フィールドの後にＳＩＤ（ｓｕｂ−ｓｔｒｅａｍ  ＩＤ）が存在するか否かを示すことができる、１ビットのフィールドであり得る。リンクレイヤーパケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンクレイヤーパケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。ＳＩＤについての詳細は後述する。
【０２３１】
ＨＥＦフィールドは、１に設定される場合、将来の拡張のために追加ヘッダーが存在することを示すことができる、１ビットのフィールドであり得る。０の値は、この拡張フィールダーが存在しないことを示すことができる。
【０２３２】
以下、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
【０２３３】
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝“０”である場合、追加ヘッダー（ｔｓｉｂ１００２０）が存在し得る。Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒは、リンクレイヤーパケットによって伝達される当該分割の順序を示すことができる、５ビットの符号なし整数であり得る。入力パケットの最初の分割を伝達するリンクレイヤーパケットに対して、当該フィールドの値は０ｘ０に設定され得る。当該フィールドは、分割される入力パケットに属する各追加セグメント毎に１ずつ増分し得る。
【０２３４】
ＬＳＩ（Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒ）は、１に設定される場合、当該ペイロードにある分割が入力パケットの最後のものであることを示すことができる、１ビットのフィールドであり得る。０の値は、それが最後の分割ではないことを示すことができる。
【０２３５】
ＳＩＦ（Ｓｕｂ−ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒ  Ｆｌａｇ）は、ＳＩＤがＨＥＦフィールドの後に存在するか否かを示すことができる、１ビットのフィールドであり得る。リンクレイヤーパケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンクレイヤーパケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。
【０２３６】
ＨＥＦフィールドは、１に設定される場合、リンクレイヤーヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、オプショナルヘッダー拡張が存在しないことを示すことができる。
【０２３７】
実施例によって、各分割されたセグメントが同一の入力パケットから生成されたことを示すパケットＩＤフィールドが追加されてもよい。このフィールドは、分割されたセグメントが順に伝送されれば必要でないので、省略されてもよい。
【０２３８】
以下、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
【０２３９】
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝“１”である場合、追加ヘッダー（ｔｓｉｂ１００３０）が存在し得る。
【０２４０】
Ｌｅｎｇｔｈ_ＭＳＢは、当該リンクレイヤーパケットにおいてバイト単位のペイロードの長さのＭＳＢビットを示すことができる、４ビットのフィールドであり得る。当該ペイロードの最大長さは、連鎖のために３２７６７バイトとなる。前述したものと同様に、詳細な数値は変更されてもよい。
【０２４１】
Ｃｏｕｎｔフィールドは、リンクレイヤーパケットに含まれたパケットの数を示すことができるフィールドであり得る。リンクレイヤーパケットに含まれたパケットの数に該当する２は、当該フィールドに設定され得る。したがって、リンクレイヤーパケットにおいて連鎖したパケットの最大値は９である。Ｃｏｕｎｔフィールドがその個数を指示する方法は、実施例毎に異なり得る。すなわち、１から８までの個数が指示されてもよい。
【０２４２】
ＨＥＦフィールドは、１に設定される場合、リンクレイヤーヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、拡張ヘッダーが存在しないことを示すことができる。
【０２４３】
Ｃｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈは、各パケットのバイト単位の長さを示すことができる１２ビットのフィールドであり得る。Ｃｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドは、最後のコンポーネントパケットを除いて、ペイロードに存在するパケットと同一の順序で含まれる。長さフィールドの数は、（Ｃｏｕｎｔ＋１）によって示すことができる。実施例によって、Ｃｏｕｎｔフィールドの値と同一の数の長さフィールドが存在してもよい。リンクレイヤーヘッダーが奇数のＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈで構成される場合、４個のスタッフィングビットが最後のＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドに後続することができる。これらビットは０に設定され得る。実施例によって、最後の連鎖したインプットパケットの長さを示すＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドは存在しないこともできる。この場合、最後の連鎖したインプットパケットの長さは、全ペイロードの長さから、各Ｃｏｍｐｏｎｅｎｔ_ｌｅｎｇｔｈフィールドが示す値の和を引いた長さで指示することができる。
【０２４４】
以下、オプショナルヘッダーについて説明する。
【０２４５】
前述したように、オプショナルヘッダーは、追加ヘッダーの後ろに追加されてもよい。オプショナルヘッダーフィールドは、ＳＩＤ及び／又はヘッダー拡張を含むことができる。ＳＩＤは、リンクレイヤーレベルで特定のパケットストリームをフィルタリングするのに使用される。ＳＩＤの一例は、多数のサービスを伝達するリンクレイヤーストリームにおいてサービス識別子の役割を果たす。適用可能な場合、サービスと、サービスに該当するＳＩＤ値との間のマッピング情報はＳＬＴで提供され得る。ヘッダー拡張は、将来の使用のための拡張フィールドを含む。受信機は、自身が理解できない全てのヘッダー拡張を無視し得る。
【０２４６】
ＳＩＤは、リンクレイヤーパケットに対するサブストリーム識別子を示すことができる８ビットのフィールドであり得る。オプショナルヘッダー拡張があれば、ＳＩＤは、追加ヘッダーとオプショナルヘッダー拡張との間に存在する。
【０２４７】
Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）は、下記に定義されたフィールドを含むことができる。
【０２４８】
Ｅｘｔｅｎｓｉｏｎ_Ｔｙｐｅは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）のタイプを示すことができる８ビットのフィールドであり得る。
【０２４９】
Ｅｘｔｅｎｓｉｏｎ_Ｌｅｎｇｔｈは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）の次のバイトから最後のバイトまでカウントされるＨｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ（）のバイトの長さを示すことができる、８ビットのフィールドであり得る。
【０２５０】
Ｅｘｔｅｎｓｉｏｎ_Ｂｙｔｅは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）の値を示すバイトであり得る。
【０２５１】
図１１は、本発明の他の実施例に係るリンクレイヤーパケットの追加ヘッダーの構造を示した図である。
【０２５２】
以下、シグナリング情報のための追加ヘッダーについて説明する。
【０２５３】
リンクレイヤーシグナリングがどのようにリンクレイヤーパケットに含まれるかは、次の通りである。シグナリングパケットは、ベースヘッダーのＰａｃｋｅｔ_Ｔｙｐｅフィールドが１００と同一であるときに識別される。
【０２５４】
図（ｔｓｉｂ１１０１０）は、シグナリング情報のための追加ヘッダーを含むリンクレイヤーパケットの構造を示す。リンクレイヤーヘッダーだけでなく、リンクレイヤーパケットは、シグナリング情報のための追加ヘッダー及び実際のシグナリングデータ自体の２つの追加部分で構成され得る。リンクレイヤーシグナリングパケットの全長はリンクレイヤーパケットヘッダーに示す。
【０２５５】
シグナリング情報のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって一部のフィールドは省略されてもよい。
【０２５６】
Ｓｉｇｎａｌｉｎｇ_Ｔｙｐｅは、シグナリングのタイプを示すことができる８ビットのフィールドであり得る。
【０２５７】
Ｓｉｇｎａｌｉｎｇ_Ｔｙｐｅ_Ｅｘｔｅｎｓｉｏｎは、シグナリングの属性を示すことができる１６ビットのフィールドであり得る。当該フィールドの詳細はシグナリングの仕様で定義され得る。
【０２５８】
Ｓｉｇｎａｌｉｎｇ_Ｖｅｒｓｉｏｎは、シグナリングのバージョンを示すことができる８ビットのフィールドであり得る。
【０２５９】
Ｓｉｇｎａｌｉｎｇ_Ｆｏｒｍａｔは、シグナリングデータのデータフォーマットを示すことができる２ビットのフィールドであり得る。ここで、シグナリングフォーマットとは、バイナリ、ＸＭＬなどのデータフォーマットを意味し得る。
【０２６０】
Ｓｉｇｎａｌｉｎｇ_Ｅｎｃｏｄｉｎｇは、エンコーディング／コンプレッションフォーマットを特定することができる２ビットのフィールドであり得る。このフィールドは、コンプレッションが行われなかったか、どのような特定のコンプレッションが行われたかを示すことができる。
【０２６１】
以下、パケットタイプの拡張のための追加ヘッダーについて説明する。
【０２６２】
将来にリンクレイヤーによって伝達されるパケットタイプ及び追加プロトコルの無制限に近い数を許容するメカニズムを提供するために、追加ヘッダーが定義される。前述したように、ベースヘッダーでＰａｃｋｅｔ_ｔｙｐｅが１１１である場合、パケットタイプの拡張が使用され得る。図（ｔｓｉｂ１１０２０）は、タイプの拡張のための追加ヘッダーを含むリンクレイヤーパケットの構造を示す。
【０２６３】
タイプの拡張のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって一部のフィールドは省略されてもよい。
【０２６４】
ｅｘｔｅｎｄｅｄ_ｔｙｐｅは、ペイロードとしてリンクレイヤーパケットにカプセル化される入力のプロトコルやパケットタイプを示すことができる、１６ビットのフィールドであり得る。当該フィールドは、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドによって既に定義された全てのプロトコルやパケットタイプに対して使用することができない。
【０２６５】
図１２は、本発明の一実施例に係る、ＭＰＥＧ−２ ＴＳパケットのためのリンクレイヤーパケットのヘッダーの構造、及びそのカプセル化の過程を示した図である。
【０２６６】
以下、入力パケットとしてＭＰＥＧ−２ ＴＳパケットが入力されたとき、リンクレイヤーパケットのフォーマットでついて説明する。
【０２６７】
この場合、ベースヘッダーのＰａｃｋｅｔ_Ｔｙｐｅフィールドは０１０と同一である。各リンクレイヤーパケット内で多数のＴＳパケットがカプセル化されてもよい。ＴＳパケットの数は、ＮＵＭＴＳフィールドを介してシグナリングされてもよい。この場合、前述したように、特別なリンクレイヤーパケットヘッダーフォーマットが使用されてもよい。
【０２６８】
リンクレイヤーは、伝送効率を向上させるために、ＭＰＥＧ−２ ＴＳのためのオーバーヘッドリダクションメカニズムを提供する。各ＴＳパケットのシンクバイト（０ｘ４７）は削除され得る。ヌルパケット及び類似のＴＳヘッダーを削除するオプションも提供される。
【０２６９】
不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（ＰＩＤ＝０ｘ１ＦＦＦ）を除去することができる。削除されたヌルパケットは、ＤＮＰフィールドを用いて受信機側で復旧することができる。ＤＮＰフィールドは、削除されたヌルパケットのカウントを示す。ＤＮＰフィールドを用いたヌルパケット削除メカニズムは、後述する。
【０２７０】
伝送効率をさらに向上させるために、ＭＰＥＧ−２ ＴＳパケットの類似のヘッダーを除去することができる。２つ以上の順次的なＴＳパケットがＣＣ（ｃｏｎｔｉｎｕｉｔｙ  ｃｏｕｎｔｅｒ）フィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。ＨＤＭフィールドは、ヘッダーが削除されたか否かを示すことができる。共通ＴＳヘッダー削除の詳細な過程は後述する。
【０２７１】
３つのオーバーヘッドリダクションメカニズムが全て行われる場合、オーバーヘッドリダクションは、シンク除去、ヌルパケット削除、共通ヘッダー削除の順に行うことができる。実施例によって、各メカニズムが行われる順序は変更されてもよい。また、実施例によって一部のメカニズムは省略されてもよい。
【０２７２】
ＭＰＥＧ−２ ＴＳパケットカプセル化を使用する場合のリンクレイヤーパケットヘッダーの全体的な構造が図（ｔｓｉｂ１２０１０）に示されている。
【０２７３】
以下、図示された各フィールドについて説明する。Ｐａｃｋｅｔ_Ｔｙｐｅは、前述したように、入力パケットのプロトコルタイプを示すことができる３ビットのフィールドであり得る。ＭＰＥＧ−２ ＴＳパケットカプセル化のために、当該フィールドは、常に０１０に設定され得る。
【０２７４】
ＮＵＭＴＳ（Ｎｕｍｂｅｒ  ｏｆ  ＴＳ  ｐａｃｋｅｔｓ）は、当該リンクレイヤーパケットのペイロードでＴＳパケットの数を示すことができる４ビットのフィールドであり得る。最大１６個のＴＳパケットが一つのリンクレイヤーパケットで支援され得る。ＮＵＭＴＳ＝０の値は、１６個のＴＳパケットがリンクレイヤーパケットのペイロードによって伝達されることを示すことができる。ＮＵＭＴＳの他の全ての値に対して、同じ数のＴＳパケットが認識される。例えば、ＮＵＭＴＳ＝０００１は、一つのＴＳパケットが伝達されることを意味する。
【０２７５】
ＡＨＦ（ａｄｄｉｔｉｏｎａｌ  ｈｅａｄｅｒ  ｆｌａｇ）は、追加ヘッダーが存在するか否かを示すことができるフィールドであり得る。０の値は、追加ヘッダーが存在しないことを示す。１の値は、１バイト長の追加ヘッダーがベースヘッダーの次に存在することを示す。ヌルＴＳパケットが削除されるかあるいはＴＳヘッダーコンプレッションが適用されれば、当該フィールドは１に設定され得る。ＴＳパケットカプセル化のための追加ヘッダーは、次の２つのフィールドで構成され、当該リンクレイヤーパケットでのＡＨＦの値が１に設定される場合にのみ存在する。
【０２７６】
ＨＤＭ（ｈｅａｄｅｒ  ｄｅｌｅｔｉｏｎ  ｍｏｄｅ）は、ＴＳヘッダー削除を当該リンクレイヤーパケットに適用できるか否かを示す１ビットのフィールドであり得る。１の値は、ＴＳヘッダー削除を適用できることを示す。０の値は、ＴＳヘッダー削除の方法が当該リンクレイヤーパケットに適用されないことを示す。
【０２７７】
ＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ  ｐａｃｋｅｔｓ）は、当該リンクレイヤーパケットの前に削除されたヌルＴＳパケットの数を示す７ビットのフィールドであり得る。最大１２８個のヌルＴＳパケットが削除され得る。ＨＤＭ＝０である場合、ＤＮＰ＝０の値は、１２８個のヌルパケットが削除されることを示すことができる。ＨＤＭ＝１である場合、ＤＮＰ＝０の値は、ヌルパケットが削除されないことを示すことができる。ＤＮＰの他の全ての値に対して、同じ数のヌルパケットが認識される。例えば、ＤＮＰ＝５は、５個のヌルパケットが削除されることを意味する。
【０２７８】
前述した各フィールドのビット数は変更可能であり、変更されたビット数に応じて、当該フィールドが指示する値の最小／最大値は変更され得る。これは、設計者の意図によって変更されてもよい。
【０２７９】
以下、シンクバイト削除（ＳＹＮＣ  ｂｙｔｅ  ｒｅｍｏｖａｌ）について説明する。
【０２８０】
ＴＳパケットをリンクレイヤーパケットのペイロードにカプセル化する場合、各ＴＳパケットの開始からシンクバイト（０ｘ４７）が削除され得る。したがって、リンクレイヤーパケットのペイロードにカプセル化されたＭＰＥＧ ２−ＴＳパケットの長さは（元の１８８バイトの代わりに）、常に１８７バイトである。
【０２８１】
以下、ヌルパケット削除（Ｎｕｌｌ  Ｐａｃｋｅｔ  Ｄｅｌｅｔｉｏｎ）について説明する。
【０２８２】
伝送ストリーム規則は、送信機のマルチプレクサの出力及び受信機のデマルチプレクサの入力でのビットレートが時間に対して一定であり、終端間の遅延も一定であることを要求する。一部の伝送ストリーム入力信号に対して、ヌルパケットは、一定のビットレートストリームに可変的なビットレートサービスを収容するために存在することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（即ち、ＰＩＤ＝０ｘ１ＦＦＦであるＴＳパケット）が除去され得る。この処理は、除去されたヌルパケットが受信機で元の正確な位置に再び挿入され得る方式で実行されるので、一定のビットレートを保障し、ＰＣＲタイムスタンプアップデートを行う必要がなくなる。
【０２８３】
リンクレイヤーパケットの生成の前に、ＤＮＰと呼ばれるカウンターは、まず、０にリセットされた後に、現在のリンクレイヤーパケットのペイロードにカプセル化される最初のヌルＴＳパケットではない、パケットに先行する各削除されたヌルパケットに対して増分され得る。その後、連続した有用なＴＳパケットのグループが現在のリンクレイヤーパケットのペイロードにカプセル化され、そのヘッダーでの各フィールドの値が決定され得る。生成されたリンクレイヤーパケットがフィジカルレイヤーに注入された後、ＤＮＰは０にリセットされる。ＤＮＰが最高の許容値に到達する場合、次のパケットもヌルパケットであれば、当該ヌルパケットは有用なパケットに維持され、次のリンクレイヤーパケットのペイロードにカプセル化される。各リンクレイヤーパケットは、それのペイロードに少なくとも１つの有用なＴＳパケットを含むことができる。
【０２８４】
以下、ＴＳパケットヘッダー削除（ＴＳ  Ｐａｃｋｅｔ  Ｈｅａｄｅｒ  Ｄｅｌｅｔｉｏｎ）について説明する。ＴＳパケットヘッダー削除は、ＴＳパケットヘッダー圧縮と呼ぶこともできる。
【０２８５】
２つ以上の順次的なＴＳパケットがＣＣフィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。重複したＭＰＥＧ−２ ＴＳパケットが２つ以上の順次的なＴＳパケットに含まれると、ヘッダーの削除は送信機側で適用することができない。ＨＤＭフィールドは、ヘッダーが削除されるか否かを示すことができる。ＴＳヘッダーが削除される場合、ＨＤＭは１に設定され得る。受信機側で、最初のパケットヘッダーを用いて、削除されたパケットヘッダーが復旧され、ＣＣが最初のヘッダーから順に増加することによって復旧される。
【０２８６】
図図示の実施例（ｔｓｉｂ１２０２０）は、ＴＳパケットのインプットストリームがリンクレイヤーパケットにカプセル化される過程の一実施例である。まず、ＳＹＮＣバイト（０ｘ４７）を有するＴＳパケットからなるＴＳストリームが入力され得る。まず、ＳＹＮＣバイトの削除過程を通じてシンクバイトを削除することができる。この実施例において、ヌルパケット削除は行われないと仮定する。
【０２８７】
ここで、図示された８個のＴＳパケットのパケットヘッダーにおいて、ＣＣ、すなわち、Ｃｏｕｎｔｉｎｕｉｔｙ Ｃｏｕｎｔｅｒフィールド値を除いた他の値が全て同一であると仮定する。この場合、ＴＳパケット削除／圧縮を行うことができる。ＣＣ＝１である最初のＴＳパケットのヘッダーのみを残し、残りの７個のＴＳパケットのヘッダーを削除する。処理されたＴＳパケットは、リンクレイヤーパケットのペイロードにカプセル化されてもよい。
【０２８８】
完成されたリンクレイヤーパケットを見ると、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは、ＴＳパケットが入力された場合であるので０１０の値を有することができる。ＮＵＭＴＳフィールドは、カプセル化されたＴＳパケットの個数を示すことができる。ＡＨＦフィールドは、パケットヘッダーの削除が行われたので１に設定され、追加ヘッダーの存在を知らせることができる。ＨＤＭフィールドは、ヘッダーの削除が行われたので１に設定され得る。ＤＮＰは、ヌルパケットの削除が行われなかったので、０に設定され得る。
【０２８９】
図１３は、本発明の一実施例に係るＩＰヘッダー圧縮において、アダプテーションモードの実施例を示した図である（送信側）。
【０２９０】
以下、ＩＰヘッダー圧縮（ＩＰ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。
【０２９１】
リンクレイヤーにおいて、ＩＰヘッダーコンプレッション／デコンプレッションスキームが提供され得る。ＩＰヘッダーコンプレッションは、ヘッダーコンプレッサー／デコンプレッサー及びアダプテーションモジュールの２つの部分を含むことができる。ヘッダーコンプレッションスキームはＲｏＨＣに基づくことができる。また、放送用途にアダプテーション機能が追加される。
【０２９２】
送信機側で、ＲｏＨＣコンプレッサーは、各パケットに対してヘッダーの大きさを減少させる。その後、アダプテーションモジュールは、コンテキスト情報を抽出し、各パケットストリームからシグナリング情報を生成する。受信機側で、アダプテーションモジュールは、受信されたパケットストリームと関連するシグナリング情報をパーシングし、コンテキスト情報を受信されたパケットストリームに添付する。ＲｏＨＣデコンプレッサーは、パケットヘッダーを復旧することによって元のＩＰパケットを再構成する。
【０２９３】
ヘッダーコンプレッションスキームは、前述したように、ＲＯＨＣをベースとすることができる。特に、本システムでは、ＲＯＨＣのＵモード（ｕｎｉ  ｄｉｒｃｔｉｏｎａｌ  ｍｏｄｅ）でＲＯＨＣフレームワークが動作することができる。また、本システムにおいて、０ｘ０００２のプロファイル識別子で識別されるＲＯＨＣ ＵＤＰヘッダーコンプレッションプロファイルが使用され得る。
【０２９４】
以下、アダプテーション（Ａｄａｐｔａｔｉｏｎ）について説明する。
【０２９５】
単方向リンクを介した伝送である場合、受信機がコンテキストの情報を有していないと、デコンプレッサーは、完全なコンテキストを受信する時まで、受信されたパケットヘッダーを復旧することができない。これは、チャンネル変更遅延及びターンオンディレイ（ｔｕｒｎ−ｏｎ  ｄｅｌａｙ）を招くことがある。このような理由で、コンプレッサーとデコンプレッサーとの間のコンフィギュレーションパラメータ及びコンテキスト情報は、常にパケットフローと共に伝送され得る。
【０２９６】
アダプテーション機能は、コンフィギュレーションパラメータ及びコンテキスト情報の帯域外伝送を提供する。帯域外伝送は、リンクレイヤーシグナリングを通じて行うことができる。したがって、アダプテーション機能は、コンテキスト情報の損失によるデコンプレッションエラー及びチャンネル変更遅延を減少させるために用いられる。
【０２９７】
以下、コンテキスト情報（Ｃｏｎｔｅｘｔ  Ｉｎｆｏｒｍａｔｉｏｎ）の抽出について説明する。
【０２９８】
コンテキスト情報の抽出は、アダプテーションモードに応じて様々な方法で行うことができる。本発明では、以下の３つの実施例について説明する。本発明の範囲は、後述するアダプテーションモードの実施例に限定されない。ここで、アダプテーションモードは、コンテキスト抽出モードと呼ぶこともできる。
【０２９９】
アダプテーションモード１（図示せず）は、基本的なＲＯＨＣパケットストリームに対していかなる更なる動作も加えられていないモードであり得る。すなわち、このモードでアダプテーションモジュールは、バッファーとして動作することができる。したがって、このモードでは、リンクレイヤーシグナリングにコンテキスト情報が含まれていない。
【０３００】
アダプテーションモード２（ｔｓｉｂ１３０１０）において、アダプテーションモジュールは、ＲｏＨＣパケットフローからＩＲパケットを検出し、コンテキスト情報（スタティックチェーン）を抽出することができる。コンテキスト情報を抽出した後、各ＩＲパケットは、ＩＲ−ＤＹＮパケットに転換され得る。転換されたＩＲ−ＤＹＮパケットは、元のパケットの代わりに、ＩＲパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
【０３０１】
アダプテーションモード３（ｔｓｉｂ１３０２０）において、アダプテーションモジュールは、ＲｏＨＣパケットフローからＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテキスト情報を抽出することができる。スタティックチェーン及びダイナミックチェーンはＩＲパケットから抽出することができ、ダイナミックチェーンはＩＲ−ＤＹＮパケットから抽出することができる。コンテキスト情報を抽出した後、それぞれのＩＲ及びＩＲ−ＤＹＮパケットは圧縮されたパケットに転換され得る。圧縮されたパケットのフォーマットは、ＩＲ又はＩＲ−ＤＹＮパケットの次のパケットと同一であり得る。転換された圧縮パケットは、元のパケットの代わりに、ＩＲ又はＩＲ−ＤＹＮパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
【０３０２】
シグナリング（コンテキスト）情報は、伝送構造に基づいてカプセル化され得る。例えば、コンテキスト情報は、リンクレイヤーシグナリングにカプセル化され得る。この場合、パケットタイプ値は１００に設定され得る。
【０３０３】
前述したアダプテーションモード２、３に対して、コンテキスト情報に対するリンクレイヤーパケットは、１００のＰａｃｋｅｔ Ｔｙｐｅフィールド値を有することができる。また、圧縮されたＩＰパケットに対するリンクレイヤーパケットは、００１のＰａｃｋｅｔ Ｔｙｐｅフィールド値を有することができる。これは、それぞれシグナリング情報、圧縮されたＩＰパケットがリンクレイヤーパケットに含まれていることを示すもので、前述した通りである。
【０３０４】
以下、抽出されたコンテキスト情報を伝送する方法について説明する。
【０３０５】
抽出されたコンテキスト情報は、特定のフィジカルデータ経路を介してシグナリングデータと共に、ＲｏＨＣパケットフローと別途に伝送され得る。コンテキストの伝送は、フィジカルレイヤー経路の構成に依存する。コンテキスト情報は、シグナリングデータパイプを介して他のリンクレイヤーシグナリングと共に伝送され得る。
【０３０６】
すなわち、コンテキスト情報を有するリンクレイヤーパケットは、他のリンクレイヤーシグナリング情報を有するリンクレイヤーパケットと共にシグナリングＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ_Ｔｙｐｅ＝１００）。コンテキスト情報が抽出された圧縮ＩＰパケットは、一般的なＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ_Ｔｙｐｅ＝００１）。ここで、実施例によって、シグナリングＰＬＰは、Ｌ１シグナリングパス（ｐａｔｈ）を意味してもよい。また、実施例によって、シグナリングＰＬＰは、一般的なＰＬＰと区分されず、シグナリング情報が伝送される特定の一般ＰＬＰを意味してもよい。
【０３０７】
受信側では、パケットストリームを受信するに先立ち、受信機がシグナリング情報を得る必要がある。受信機が、シグナリング情報を獲得するために最初のＰＬＰをデコードすると、コンテキストシグナリングも受信することができる。シグナリングの獲得が行われた後、パケットストリームを受信するためのＰＬＰが選択され得る。すなわち、受信機は、まず、イニシャルＰＬＰを選択して、コンテキスト情報を含めてシグナリング情報を得ることができる。ここで、イニシャルＰＬＰは、前述したシグナリングＰＬＰであり得る。この後、受信機は、パケットストリームを得るためのＰＬＰを選択することができる。これを通じて、コンテキスト情報は、パケットストリームの受信に先立って獲得できる。
【０３０８】
パケットストリームを得るためのＰＬＰが選択された後、アダプテーションモジュールは、受信されたパケットフローからＩＲ−ＤＹＮパケットを検出することができる。その後、アダプテーションモジュールは、シグナリングデータにおいてコンテキスト情報からスタティックチェーンをパーシングする。これは、ＩＲパケットを受信することと類似している。同一のコンテキスト識別子に対して、ＩＲ−ＤＹＮパケットはＩＲパケットに復旧され得る。復旧されたＲｏＨＣパケットフローはＲｏＨＣデコンプレッサーに送られる。その後、デコンプレッションが開始され得る。
【０３０９】
図１４は、本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）及びＲＯＨＣ−Ｕディスクリプションテーブルを示した図である。
【０３１０】
以下、リンクレイヤーシグナリングについて説明する。
【０３１１】
主に、リンクレイヤーシグナリングはＩＰレベル下で動作する。受信機側で、リンクレイヤーシグナリングは、ＳＬＴ及びＳＬＳのようなＩＰレベルシグナリングよりも先に獲得され得る。したがって、リンクレイヤーシグナリングはセッション設定の前に獲得できる。
【０３１２】
リンクレイヤーシグナリングに対して、入力経路に応じて、インターナルリンクレイヤーシグナリング及びエクスターナルリンクレイヤーシグナリングの２種類のシグナリングが存在することができる。インターナルリンクレイヤーシグナリングは、送信機側でリンクレイヤーで生成される。また、リンクレイヤーは、外部のモジュール又はプロトコルからシグナリングを取る。このような種類のシグナリング情報はエクスターナルリンクレイヤーシグナリングであると見なされる。一部のシグナリングがＩＰレベルシグナリングに先立って獲得される必要があれば、外部のシグナリングは、リンクレイヤーパケットのフォーマットで伝送される。
【０３１３】
リンクレイヤーシグナリングは、前述したように、リンクレイヤーパケットにカプセル化され得る。リンクレイヤーパケットは、バイナリ及びＸＭＬを含む全てのフォーマットのリンクレイヤーシグナリングを伝達することができる。同一のシグナリング情報がリンクレイヤーシグナリングに対して異なるフォーマットで伝送され得る。
【０３１４】
インターナルリンクレイヤーシグナリングには、リンクマッピングのためのシグナリング情報が含まれてもよい。ＬＭＴは、ＰＬＰに伝達される上位レイヤーセッションのリストを提供する。ＬＭＴはまた、リンクレイヤーで上位レイヤーセッションを伝達するリンクレイヤーパケットを処理するための追加情報を提供する。
【０３１５】
本発明に係るＬＭＴの一実施例（ｔｓｉｂ１４０１０）が図示された。
【０３１６】
ｓｉｇｎａｌｉｎｇ_ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットの符号なし整数フィールドであり得る。ＬＭＴに対するｓｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値は０ｘ０１に設定され得る。
【０３１７】
ＰＬＰ_ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
【０３１８】
ｎｕｍ_ｓｅｓｓｉｏｎは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤーセッションの数を提供する８ビットの符号なし整数フィールドであり得る。ｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値が０ｘ０１であれば、当該フィールドは、ＰＬＰでＵＤＰ／ＩＰセッションの数を示すことができる。
【０３１９】
ｓｒｃ_ＩＰ_ａｄｄは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤーセッションのソースＩＰアドレスを含む３２ビットの符号なし整数フィールドであり得る。
【０３２０】
ｄｓｔ_ＩＰ_ａｄｄは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤーセッションのデスティネーションＩＰアドレスを含む３２ビットの符号なし整数フィールドであり得る。
【０３２１】
ｓｒｃ_ＵＤＰ_ｐｏｒｔは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤーセッションのソースＵＤＰポートナンバーを示す１６ビットの符号なし整数フィールドであり得る。
【０３２２】
ｄｓｔ_ＵＤＰ_ｐｏｒｔは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤーセッションのデスティネーションＵＤＰポートナンバーを示す１６ビットの符号なし整数フィールドであり得る。
【０３２３】
ＳＩＤ_ｆｌａｇは、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤーセッションを伝達するリンクレイヤーパケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位レイヤーセッションを伝達するリンクレイヤーパケットがそのオプショナルヘッダーにＳＩＤフィールドを有さない。当該フィールドの値が１に設定されると、上位レイヤーセッションを伝達するリンクレイヤーパケットがそのオプショナルヘッダーにＳＩＤフィールドを有することができ、ＳＩＤフィールドの値が、当該テーブルで次のＳＩＤフィールドと同一であり得る。
【０３２４】
ｃｏｍｐｒｅｓｓｅｄ_ｆｌａｇは、ヘッダーコンプレッションが、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤーセッションを伝達するリンクレイヤーパケットに適用されるか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位レイヤーセッションを伝達するリンクレイヤーパケットは、そのベースヘッダーにＰａｃｋｅｔ_Ｔｙｐｅフィールドの０ｘ００の値を有することができる。当該フィールドの値が１に設定されると、上位レイヤーセッションを伝達するリンクレイヤーパケットは、そのベースヘッダーにＰａｃｋｅｔ_Ｔｙｐｅフィールドの０ｘ０１の値を有することができ、Ｃｏｎｔｅｘｔ_ＩＤフィールドが存在することができる。
【０３２５】
ＳＩＤは、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤーセッションを伝達するリンクレイヤーパケットに対するサブストリーム識別子を示す８ビットの符号なし整数フィールドであり得る。当該フィールドは、ＳＩＤ_ｆｌａｇの値が１と同一であるときに存在することができる。
【０３２６】
ｃｏｎｔｅｘｔ_ｉｄは、ＲＯＨＣ−Ｕディスクリプションテーブルに提供されたＣＩＤ（ｃｏｎｔｅｘｔ  ｉｄ）に対するレファレンスを提供する８ビットのフィールドであり得る。当該フィールドは、ｃｏｍｐｒｅｓｓｅｄ_ｆｌａｇの値が１と同一であるときに存在することができる。
【０３２７】
本発明に係るＲＯＨＣ−Ｕディスクリプションテーブルの一実施例（ｔｓｉｂ１４０２０）が図示された。前述したように、ＲＯＨＣ−Ｕアダプテーションモジュールは、ヘッダーコンプレッションに関連する情報を生成することができる。
【０３２８】
ｓｉｇｎａｌｉｎｇ_ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットのフィールドであり得る。ＲＯＨＣ−Ｕディスクリプションテーブルに対するｓｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値は“０ｘ０２”に設定され得る。
【０３２９】
ＰＬＰ_ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
【０３３０】
ｃｏｎｔｅｘｔ_ｉｄは、圧縮されたＩＰストリームのＣＩＤを示す８ビットのフィールドであり得る。当該システムにおいて、８ビットのＣＩＤは、大きいＣＩＤのために使用することができる。
【０３３１】
ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅは、ストリームを圧縮するために使用されるプロトコルの範囲を示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
【０３３２】
ａｄａｐｔａｔｉｏｎ_ｍｏｄｅは、当該ＰＬＰでアダプテーションモジュールのモードを示す２ビットのフィールドであり得る。アダプテーションモードについては前述した。
【０３３３】
ｃｏｎｔｅｘｔ_ｃｏｎｆｉｇは、コンテキスト情報の組み合わせを示す２ビットのフィールドであり得る。当該テーブルにコンテキスト情報が存在しなければ、当該フィールドは‘０ｘ０’に設定され得る。当該テーブルにｓｔａｔｉｃ_ｃｈａｉｎ（）又はｄｙｎａｍｉｃ_ｃｈａｉｎ（）バイトが含まれれば、当該フィールドは‘０ｘ０１’又は‘０ｘ０２’に設定され得る。当該テーブルにｓｔａｔｉｃ_ｃｈａｉｎ（）及びｄｙｎａｍｉｃ_ｃｈａｉｎ（）バイトが全て含まれれば、当該フィールドは‘０ｘ０３’に設定され得る。
【０３３４】
ｃｏｎｔｅｘｔ_ｌｅｎｇｔｈは、スタティックチェーンバイトシーケンスの長さを示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
【０３３５】
ｓｔａｔｉｃ_ｃｈａｉｎ_ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサーを初期化するために使用されるスタティック情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
【０３３６】
ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサーを初期化するために使用されるダイナミック情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
【０３３７】
ｓｔａｔｉｃ_ｃｈａｉｎ_ｂｙｔｅは、ＩＲパケットのサブヘッダー情報として定義することができる。ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｂｙｔｅは、ＩＲパケット及びＩＲ−ＤＹＮパケットのサブヘッダー情報として定義することができる。
【０３３８】
図１５は、本発明の一実施例に係る送信機側のリンクレイヤーの構造を示した図である。
【０３３９】
この実施例は、ＩＰパケットを処理することを仮定した実施例である。送信機側のリンクレイヤーは、機能的な観点から、大きく、シグナリング情報を処理するリンクレイヤーシグナリング部分、オーバーヘッドリダクション部分、及び／又はカプセル化部分を含むことができる。また、送信機側のリンクレイヤーは、リンクレイヤー全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンクレイヤーの入出力部分などを含むことができる。
【０３４０】
まず、上位レイヤーのシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）がリンクレイヤーに伝達され得る。また、ＩＰレイヤー（ｔｓｉｂ１５１１０）から、ＩＰパケットを含むＩＰストリームがリンクレイヤーに伝達され得る。
【０３４１】
スケジューラ（ｔｓｉｂ１５０２０）は、前述したように、リンクレイヤーに含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）は、スケジューラ（ｔｓｉｂ１５０２０）によってフィルタリング又は活用されてもよい。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）のうち、受信機で必要な情報はリンクレイヤーシグナリング部分に伝達されてもよい。また、シグナリング情報のうちリンクレイヤーの動作に必要な情報は、オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）又はカプセル化コントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３４２】
リンクレイヤーシグナリング部分は、フィジカルレイヤーでシグナリングとして伝送される情報を収集し、これを、伝送に適した形態に変換／構成する役割を果たすことができる。リンクレイヤーシグナリング部分は、シグナリングマネジャー（ｔｓｉｂ１５０３０）、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）、及び／又はチャンネルのためのバッファー（ｔｓｉｂ１５０５０）を含むことができる。
【０３４３】
シグナリングマネジャー（ｔｓｉｂ１５０３０）は、スケジューラ（ｔｓｉｂ１５０２０）から伝達されたシグナリング情報、及び／又はオーバーヘッドリダクション部分から伝達されたシグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を受信することができる。シグナリングマネジャー（ｔｓｉｂ１５０３０）は、伝達されたデータに対して、各シグナリング情報が伝送される経路を決定することができる。各シグナリング情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって決定された経路で伝達されてもよい。前述したように、ＦＩＣ、ＥＡＳなどの区分されたチャンネルで伝送されるシグナリング情報はシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に伝達され、その他のシグナリング情報はカプセル化バッファー（ｔｓｉｂ１５０７０）に伝達されてもよい。
【０３４４】
シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、別途に区分されたチャンネルを介してシグナリング情報を伝送できるように、関連するシグナリング情報を各区分されたチャンネルに合う形態にフォーマットする役割を果たすことができる。前述したように、フィジカルレイヤーには、物理的／論理的に区分された別個のチャンネルがあり得る。これら区分されたチャンネルは、ＦＩＣシグナリング情報や、ＥＡＳ関連情報を伝送するのに使用することができる。ＦＩＣ又はＥＡＳ関連情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって分類されてシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に入力されてもよい。シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、各情報を、それぞれの別個のチャンネルに合わせてフォーマットすることができる。ＦＩＣ、ＥＡＳ以外にも、フィジカルレイヤーが特定のシグナリング情報を別個の区分されたチャンネルを介して伝送するものと設計された場合には、その特定のシグナリング情報のためのシグナリングフォーマッタを付け加えることができる。このような方式を通じて、リンクレイヤーが、様々なフィジカルレイヤーに対して互換可能となり得る。
【０３４５】
チャンネルのためのバッファー（ｔｓｉｂ１５０５０）は、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）から伝達されたシグナリング情報を、指定された別個のチャンネル（ｔｓｉｂ１５０６０）に伝達する役割を果たすことができる。別個のチャンネルの数、内容は、実施例によって変更されてもよい。
【０３４６】
前述したように、シグナリングマネジャー（ｔｓｉｂ１５０３０）は、特定のチャンネルに伝達されないシグナリング情報をカプセル化バッファー（ｔｓｉｂ１５０７０）に伝達することができる。カプセル化バッファー（ｔｓｉｂ１５０７０）は、特定のチャンネルに伝達されないシグナリング情報を受信するバッファーの役割を果たすことができる。
【０３４７】
シグナリング情報のためのカプセル化（ｔｓｉｂ１５０８０）は、特定のチャンネルに伝達されないシグナリング情報に対してカプセル化を行うことができる。トランスミッションバッファー（ｔｓｉｂ１５０９０）は、カプセル化されたシグナリング情報を、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）に伝達するバッファーの役割を果たすことができる。ここで、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）は、前述したＰＬＳ領域を意味し得る。
【０３４８】
オーバーヘッドリダクション部分は、リンクレイヤーに伝達されるパケットのオーバーヘッドを除去し、効率的な伝送が可能にすることができる。オーバーヘッドリダクション部分は、リンクレイヤーに入力されるＩＰストリームの数だけ構成することができる。
【０３４９】
オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）は、上位レイヤーから伝達されたＩＰパケットの入力を受ける役割を果たすことができる。伝達されたＩＰパケットは、オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）を介してオーバーヘッドリダクション部分に入力されてもよい。
【０３５０】
オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）は、オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）に入力されるパケットストリームに対してオーバーヘッドリダクションを行うか否かを決定することができる。オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）は、パケットストリーム別にオーバーヘッドリダクションを行うか否かを決定することができる。パケットストリームにオーバーヘッドリダクションが行われる場合、ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）にパケットが伝達されてオーバーヘッドリダクションが行われ得る。パケットストリームにオーバーヘッドリダクションが行われない場合、カプセル化部分にパケットが伝達され、オーバーヘッドリダクションなしにカプセル化が行われ得る。パケットにオーバーヘッドリダクションを行うか否かは、リンクレイヤーに伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってカプセル化コントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３５１】
ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）は、パケットストリームに対してオーバーヘッドリダクションを行うことができる。ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）は、パケットのヘッダーを圧縮する動作を行うことができる。オーバーヘッドリダクションには様々な方法を使用することができる。前述した、本発明が提案した方法によってオーバーヘッドリダクションを行うことができる。この実施例は、ＩＰストリームを仮定しており、ＲｏＨＣコンプレシャーと表現したが、実施例によって名称は変更されてもよく、動作も、ＩＰストリームの圧縮に限定されず、全ての種類のパケットのオーバーヘッドリダクションがＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）によって行われてもよい。
【０３５２】
パケットストリームコンフィギュレーションブロック（ｔｓｉｂ１５１５０）は、ヘッダーが圧縮されたＩＰパケットのうち、シグナリング領域に伝送される情報とパケットストリームに伝送される情報を分離することができる。パケットストリームに伝送される情報とは、ＤＰ領域に伝送される情報を意味し得る。シグナリング領域に伝送される情報は、シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１５１６０）に伝達されてもよい。パケットストリームに伝送される情報はカプセル化部分に伝送されてもよい。
【０３５３】
シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１５１６０）は、シグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を収集し、これをシグナリングマネジャーに伝達することができる。シグナリング及び／又はコンテキスト情報をシグナリング領域に伝送するためである。
【０３５４】
カプセル化部分は、パケットをフィジカルレイヤーに伝達するのに適した形態にカプセル化する動作を行うことができる。カプセル化部分は、ＩＰストリームの数だけ構成することができる。
【０３５５】
カプセル化バッファー（ｔｓｉｂ１５１７０）は、カプセル化のためにパケットストリームを受信する役割を果たすことができる。オーバーヘッドリダクションが行われた場合、オーバーヘッドリダクションされたパケットを受信し、オーバーヘッドリダクションが行われていない場合、入力されたＩＰパケットをそのまま受信することができる。
【０３５６】
カプセル化コントローラー（ｔｓｉｂ１５１８０）は、入力されたパケットストリームに対してカプセル化を行うか否かを決定することができる。カプセル化が行われる場合、パケットストリームはセグメンテーション／コンカチネーション（ｔｓｉｂ１５１９０）に伝達されてもよい。カプセル化が行われない場合、パケットストリームはトランスミッションバッファー（ｔｓｉｂ１５２３０）に伝達されてもよい。パケットをカプセル化するか否かは、リンクレイヤーに伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってカプセル化コントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３５７】
セグメンテーション／コンカチネーションブロック（ｔｓｉｂ１５１９０）では、パケットに対して、前述した分割又は連鎖作業を行うことができる。すなわち、入力されたＩＰパケットが、リンクレイヤーの出力であるリンクレイヤーパケットよりも長い場合、一つのＩＰパケットを分割して多数個のセグメントに分けて複数個のリンクレイヤーパケットペイロードを作ることができる。また、入力されたＩＰパケットが、リンクレイヤーの出力であるリンクレイヤーパケットよりも短い場合、複数個のＩＰパケットをつなげて一つのリンクレイヤーパケットペイロードを作ることができる。
【０３５８】
パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）は、分割及び／又は連鎖されたリンクレイヤーパケットの構成情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報は、送信機と受信機が同じ情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報が送信機と受信機で参照されてもよい。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報のインデックス値が当該リンクレイヤーパケットのヘッダーに含まれてもよい。
【０３５９】
リンクレイヤーヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、カプセル化過程で発生するヘッダー情報を収集することができる。また、リンクレイヤーヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）が有する情報を収集することができる。リンクレイヤーヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、リンクレイヤーパケットのヘッダーの構造に応じてヘッダー情報を構成することができる。
【０３６０】
ヘッダーアタッチメントブロック（ｔｓｉｂ１５２２０）は、セグメンテーション及び／又はコンカチネーションされたリンクレイヤーパケットのペイロードにヘッダーを付け加えることができる。トランスミッションバッファー（ｔｓｉｂ１５２３０）は、リンクレイヤーパケットをフィジカルレイヤーのＤＰ（ｔｓｉｂ１５２４０）に伝達するためのバッファーの役割を果たすことができる。
【０３６１】
各ブロック乃至モジュール及び部分（ｐａｒｔ）は、リンクレイヤーにおいて一つのモジュール／プロトコルとして構成されてもよく、複数個のモジュール／プロトコルとして構成されてもよい。
【０３６２】
図１６は、本発明の一実施例に係る受信機側のリンクレイヤーの構造を示した図である。
【０３６３】
この実施例は、ＩＰパケットを処理することを仮定した実施例である。受信機側のリンクレイヤーは、機能的な観点から、大きく、シグナリング情報を処理するリンクレイヤーシグナリング部分、オーバーヘッドプロセシング部分、及び／又はデカプセレーション部分を含むことができる。また、受信機側のリンクレイヤーは、リンクレイヤー全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンクレイヤーの入出力部分などを含むことができる。
【０３６４】
まず、フィジカルレイヤーを介して伝送された各情報がリンクレイヤーに伝達され得る。リンクレイヤーは、各情報を処理して、送信側で処理する前の元の状態に戻した後、上位レイヤーに伝達することができる。この実施例において、上位レイヤーはＩＰレイヤーであり得る。
【０３６５】
フィジカルレイヤーで区分された特定のチャンネル（ｔｓｉｂ１６０３０）を介して伝達された情報がリンクレイヤーシグナリング部分に伝達され得る。リンクレイヤーシグナリング部分は、フィジカルレイヤーから受信されたシグナリング情報を判別し、リンクレイヤーの各部分に、判別されたシグナリング情報を伝達する役割を果たすことができる。
【０３６６】
チャンネルのためのバッファー（ｔｓｉｂ１６０４０）は、特定のチャンネルを介して伝送されたシグナリング情報を受信するバッファーの役割を果たすことができる。前述したように、フィジカルレイヤーに物理的／論理的に区分された別個のチャンネルが存在する場合、そのチャンネルを介して伝送されたシグナリング情報を受信することができる。別個のチャンネルから受信した情報が分割された状態である場合、完全な形態の情報になるまで、分割された情報を格納することができる。
【０３６７】
シグナリングデコーダー／パーサー（ｔｓｉｂ１６０５０）は、特定のチャンネルを介して受信されたシグナリング情報のフォーマットを確認し、リンクレイヤーで活用される情報を抽出することができる。特定のチャンネルを介したシグナリング情報がエンコーディングされている場合にはデコーディングを行うことができる。また、実施例によって、当該シグナリング情報の無欠性などを確認してもよい。
【０３６８】
シグナリングマネジャー（ｔｓｉｂ１６０６０）は、多数の経路を介して受信されたシグナリング情報を統合することができる。後述するシグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して受信されたシグナリング情報もシグナリングマネジャー（ｔｓｉｂ１６０６０）で統合することができる。シグナリングマネジャー（ｔｓｉｂ１６０６０）は、リンクレイヤー内の各部分に必要なシグナリング情報を伝達することができる。例えば、オーバーヘッドプロセシング部分に、パケットのリカバリーのためのコンテキスト情報などを伝達することができる。また、スケジューラ（ｔｓｉｂ１６０２０）に、制御のためのシグナリング情報を伝達することができる。
【０３６９】
シグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して、別個の特別なチャンネルで受信されていない一般的なシグナリング情報が受信されてもよい。ここで、シグナリングのためのＤＰとは、ＰＬＳ又はＬ１などを意味し得る。ここで、ＤＰは、ＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）と呼ぶこともできる。レセプションバッファー（ｔｓｉｂ１６０８０）は、シグナリングのためのＤＰから伝送されたシグナリング情報を受信するバッファーの役割を果たすことができる。シグナリング情報のデカプセレーションブロック（ｔｓｉｂ１６０９０）では、受信されたシグナリング情報をデカプセレーションすることができる。デカプセレーションされたシグナリング情報は、デカプセレーションバッファー（ｔｓｉｂ１６１００）を経てシグナリングマネジャー（ｔｓｉｂ１６０６０）に伝達されてもよい。前述したように、シグナリングマネジャー（ｔｓｉｂ１６０６０）は、シグナリング情報を組み合わせてリンクレイヤー内の必要な部分に伝達することができる。
【０３７０】
スケジューラ（ｔｓｉｂ１６０２０）は、リンクレイヤーに含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。スケジューラ（ｔｓｉｂ１６０２０）は、レシーバー情報（ｔｓｉｂ１６０１０）及び／又はシグナリングマネジャー（ｔｓｉｂ１６０６０）から伝達された情報を用いて、リンクレイヤーの各部分を制御することができる。また、スケジューラ（ｔｓｉｂ１６０２０）は、各部分の動作モードなどを決定することができる。ここで、レシーバー情報（ｔｓｉｂ１６０１０）は、受信機が予め格納していた情報を意味し得る。スケジューラ（ｔｓｉｂ１６０２０）は、チャンネル切り替えなどのようにユーザが変更する情報も用いて、制御に活用することができる。
【０３７１】
デカプセレーション部分は、フィジカルレイヤーのＤＰ（ｔｓｉｂ１６１１０）から受信されたパケットをフィルタリングし、当該パケットのタイプに応じてパケットを分離する役割を果たすことができる。デカプセレーション部分は、フィジカルレイヤーで同時にデコーディングできるＤＰの数だけ構成することができる。
【０３７２】
デカプセレーションバッファー（ｔｓｉｂ１６１１０）は、デカプセレーションのためにフィジカルレイヤーからパケットストリームを受信するバッファーの役割を果たすことができる。デカプセレーションコントローラー（ｔｓｉｂ１６１３０）は、入力されたパケットストリームに対してデカプセレーションを行うか否かを決定することができる。デカプセレーションが行われる場合、パケットストリームはリンクレイヤーヘッダーパーサー（ｔｓｉｂ１６１４０）に伝達されてもよい。デカプセレーションが行われない場合、パケットストリームはアウトプットバッファー（ｔｓｉｂ１６２２０）に伝達されてもよい。デカプセレーションを行うか否かを決定するにおいて、スケジューラ（ｔｓｉｂ１６０２０）から伝達されたシグナリング情報を活用することができる。
【０３７３】
リンクレイヤーヘッダーパーサー（ｔｓｉｂ１６１４０）は、伝達されたリンクレイヤーパケットのヘッダーを確認することができる。ヘッダーを確認することによって、リンクレイヤーパケットのペイロードに含まれているＩＰパケットの構成を確認することができる。例えば、ＩＰパケットは、セグメンテーションされているかあるいはコンカチネーションされていてもよい。
【０３７４】
パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）は、セグメンテーション及び／又はコンカチネーションで構成されるリンクレイヤーパケットのペイロード情報を含むことができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）の情報は、送信機と受信機が同じ情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）の情報が送信機と受信機で参照されてもよい。リンクレイヤーパケットに含まれたインデックス情報に基づいて、再結合（ｒｅａｓｓｅｍｂｌｙ）に必要な値を見つけることができる。
【０３７５】
再結合ブロック（ｒｅａｓｓｅｍｂｌｙ）（ｔｓｉｂ１６１６０）は、セグメンテーション及び／又はコンカチネーションで構成されたリンクレイヤーパケットのペイロードを元のＩＰストリームのパケットとして構成することができる。セグメントを一つに集めて一つのＩＰパケットとして再構成したり、コンカチネーションされたパケットを分離して複数個のＩＰパケットストリームとして再構成したりすることができる。再結合されたＩＰパケットは、オーバーヘッドプロセシング部分に伝達されてもよい。
【０３７６】
オーバーヘッドプロセシング部分は、送信機で行われたオーバーヘッドリダクションの逆過程として、オーバーヘッドリダクションされたパケットを元のパケットに戻す動作を行うことができる。この動作をオーバーヘッドプロセシングと呼ぶことができる。オーバーヘッドプロセシング部分は、フィジカルレイヤーで同時にデコーディングできるＤＰの数だけ構成することができる。
【０３７７】
パケットリカバリーバッファー（ｔｓｉｂ１６１７０）は、オーバーヘッドプロセシングを行うためにデカプセレーションされたＲｏＨＣパケット乃至ＩＰパケットを受信するバッファーの役割を果たすことができる。
【０３７８】
オーバーヘッドコントローラー（ｔｓｉｂ１６１８０）は、デカプセレーションされたパケットに対してパケットリカバリー及び／又はデコンプレッションを行うか否かを決定することができる。パケットリカバリー及び／又はデコンプレッションが行われる場合、パケットストリームリカバリーブロック（ｔｓｉｂ１６１９０）にパケットが伝達されてもよい。パケットリカバリー及び／又はデコンプレッションが行われない場合、パケットはアウトプットバッファー（ｔｓｉｂ１６２２０）に伝達されてもよい。パケットリカバリー及び／又はデコンプレッションを行うか否かは、スケジューラ（ｔｓｉｂ１６０２０）によって伝達されたシグナリング情報に基づいて決定されてもよい。
【０３７９】
パケットストリームリカバリーブロック（ｔｓｉｂ１６１９０）は、送信機で分離されたパケットストリームと、パケットストリームのコンテキスト情報とを統合する動作を行うことができる。これは、ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）で処理可能なように、パケットストリームを復旧する過程であり得る。この過程で、シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１６２００）からシグナリング情報及び／又はコンテキスト情報を受信することができる。シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１６２００）は、送信機から伝達されたシグナリング情報を判別し、当該コンテキストＩＤに合うストリームにマッピングできるようにパケットストリームリバーカレーブロック（ｔｓｉｂ１６１９０）にシグナリング情報を伝達することができる。
【０３８０】
ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）は、パケットストリームのパケットのヘッダーを復旧することができる。パケットストリームのパケットは、ヘッダーが復旧されることによって元のＩＰパケットの形態に復旧され得る。すなわち、ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）はオーバーヘッドプロセシングを行うことができる。
【０３８１】
アウトプットバッファー（ｔｓｉｂ１６２２０）は、ＩＰレイヤー（ｔｓｉｂ１６２３０）に出力ストリームを伝達するに先立ち、バッファーの役割を果たすことができる。
【０３８２】
本発明が提案する送信機と受信機のリンクレイヤーは、前述したようなブロック乃至モジュールを含むことができる。これを通じて、リンクレイヤーが上位レイヤーと下位レイヤーに関係なく独立して動作することができ、オーバーヘッドリダクションを効率的に行うことができ、上／下位レイヤーなどによって支援可能な機能の確定／追加／除去が容易となり得る。
【０３８３】
図１７は、本発明の一実施例に係る、リンクレイヤーを介したシグナリング伝送構造を示した図である（送／受信側）。
【０３８４】
本発明では、一つの周波数バンド内に複数個のサービスプロバイダー（放送会社）がサービスを提供することができる。また、サービスプロバイダーは、複数個のサービスを伝送することができ、一つのサービスは１つ以上のコンポーネントを含むことができる。ユーザは、サービス単位でコンテンツを受信することを考慮することができる。
【０３８５】
本発明は、ＩＰハイブリッド放送を支援するために、複数個のセッションベースの伝送プロトコルが使用されることを仮定する。各プロトコルの伝送構造に基づいて、そのシグナリングパス（ｐａｔｈ）で伝達されるシグナリング情報を決定することができる。各プロトコルは、実施例によって様々な名称が付与されてもよい。
【０３８６】
図示された送信側のデータ構造（ｔｓｉｂ１７０１０）において、サービスプロバイダー（Ｂｒｏａｄｃａｓｔｅｒｓ）は複数個のサービス（Ｓｅｒｖｉｃｅ  ＃１，＃２，…）を提供することができる。一般に、サービスに対するシグナリングは、一般的な伝送セッションを介して伝送することができるが（Ｓｉｇｎａｌｉｎｇ  Ｃ）、実施例によって、特定のセッション（ｄｅｄｉｃａｔｅｄ  ｓｅｓｓｉｏｎ）を介して伝送してもよい（Ｓｉｇｎａｌｉｎｇ  Ｂ）。
【０３８７】
サービスデータ及びサービスシグナリング情報は、伝送プロトコルに従ってカプセル化することができる。実施例によってＩＰ／ＵＤＰが使用されてもよい。実施例によってＩＰ／ＵＤＰレイヤーでのシグナリング（Ｓｉｇｎａｌｉｎｇ  Ａ）が追加されてもよい。このシグナリングは省略できる。
【０３８８】
ＩＰ／ＵＤＰで処理されたデータはリンクレイヤーに入力されてもよい。リンクレイヤーでは、前述したように、オーバーヘッドリダクション及び／又はカプセル化過程を行うことができる。ここで、リンクレイヤーシグナリングが追加されてもよい。リンクレイヤーシグナリングにはシステムパラメータなどが含まれてもよい。リンクレイヤーシグナリングについては前述した。
【０３８９】
このような処理を経たサービスデータ及びシグナリング情報は、フィジカルレイヤーでＰＬＰを介して処理されてもよい。ここで、ＰＬＰはＤＰと呼ぶこともできる。図図示の実施例では、Ｂａｓｅ ＤＰ／ＰＬＰが使用される場合を想定しているが、実施例によってＢａｓｅ ＤＰ／ＰＬＰなしに一般的なＤＰ／ＰＬＰのみで伝送が行われてもよい。
【０３９０】
図図示の実施例では、ＦＩＣ、ＥＡＣなどの特定のチャンネル（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）が使用されている。ＦＩＣを介して伝達されるシグナリングをＦＩＴ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）、ＥＡＣを介して伝達されるシグナリングをＥＡＴ（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔ  Ｔａｂｌｅ）と呼ぶことができる。ＦＩＴは、前述したＳＬＴと同一であることができる。このような特定のチャンネルは、実施例によって使用されなくてもよい。特定のチャンネル（Ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）が構成されていない場合、ＦＩＴとＥＡＴは、一般的なリンクレイヤーシグナリング伝送方法によって伝送されるかあるいは他のサービスデータのようにＩＰ／ＵＤＰを経てＰＬＰに伝送されてもよい。
【０３９１】
実施例によって、システムパラメータには、送信機関連パラメータ、サービスプロバイダー関連パラメータなどが含まれてもよい。リンクレイヤーシグナリングには、ＩＰヘッダー圧縮関連コンテキスト情報、及び／又は当該コンテキストが適用されるデータに対する識別情報が含まれてもよい。上位レイヤーのシグナリングには、ＩＰアドレス、ＵＤＰナンバー、サービス／コンポーネント情報、緊急警報（Ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ）関連情報、サービスシグナリングに対するＩＰ／ＵＤＰアドレス、セッションＩＤなどが含まれてもよい。詳細な実施例については前述した。
【０３９２】
図示された受信側のデータ構造（ｔｓｉｂ１７０２０）において、受信機は、全てのＰＬＰをデコードすることなく、シグナリング情報を活用して当該サービスに対するＰＬＰのみをデコードすることができる。
【０３９３】
まず、ユーザが、受信しようとするサービスを選択又は変更すると、受信機は、当該周波数にチューニングし、当該チャンネルと関連してＤＢなどに格納している受信機情報を読み込むことができる。受信機のＤＢなどに格納されている情報は、最初のチャンネルスキャンの際にＳＬＴを読み込んで構成されてもよい。
【０３９４】
ＳＬＴを受信し、当該チャンネルの情報を受信した後、既存に格納されていたＤＢをアップデートし、ユーザが選択したサービスの伝送経路及びコンポーネント情報を獲得したり、このような情報を獲得するために必要なシグナリングが伝送される経路についての情報を獲得したりする。ＳＬＴのバージョン情報などを用いて、当該情報の変更がないと判断される場合には、デコーディング又はパーシング手順を省略することができる。
【０３９５】
受信機は、当該放送ストリームにおいて、ＰＬＰのフィジカルシグナリングをパーシングし、当該ＰＬＰ内にＳＬＴ情報があるかどうかを把握することができる（図示せず）。これは、フィジカルシグナリングの特定のフィールドを介して指示されてもよい。ＳＬＴ情報に接近することによって、特定のサービスのサービスレイヤーシグナリングが伝送される位置に接近することができる。このサービスレイヤーシグナリングは、ＩＰ／ＵＤＰにカプセル化されて伝送セッションを介して伝達されてもよい。このサービスレイヤーシグナリングを用いて、当該サービスを構成するコンポーネントについての情報を獲得することができる。詳細なＳＬＴ−ＳＬＳの構造は、前述した通りである。
【０３９６】
すなわち、ＳＬＴを用いて、現在のチャンネルに伝送されている多数のパケットストリーム及びＰＬＰのうち、当該サービスの受信に必要な上位レイヤーシグナリング情報（サービスシグナリング情報）を受信するための伝送経路情報を獲得することができる。この伝送経路情報には、ＩＰアドレス、ＵＤＰポートナンバー、セッションＩＤ、ＰＬＰ ＩＤなどが含まれてもよい。ここで、実施例によって、ＩＰ／ＵＤＰアドレスは、ＩＡＮＡ又はシステムで予め指定されている値を使用してもよい。このような情報は、ＤＢ及び共有メモリ接近などの方法で獲得されてもよい。
【０３９７】
リンクレイヤーシグナリングとサービスデータが同一のＰＬＰを介して伝送されるかあるいは一つのＰＬＰのみが運用されている場合、ＰＬＰを介して伝達されるサービスデータは、リンクレイヤーシグナリングがデコードされる間、臨時にバッファーなどの装置に格納されてもよい。
【０３９８】
受信しようとするサービスに対するサービスシグナリング情報を用いて、当該サービスが実際に伝送される経路の情報を獲得することができる。また、受信するＰＬＰに対するオーバーヘッドリダクションなどの情報を用いて、受信されるパケットストリームに対してデカプセレーション及びヘッダーリカバリーを行うことができる。
【０３９９】
図図示の実施例（ｔｓｉｂ１７０２０）では、ＦＩＣ、ＥＡＣが使用され、Ｂａｓｅ ＤＰ／ＰＬＰの概念が想定された。前述したように、ＦＩＣ、ＥＡＣ、Ｂａｓｅ ＤＰ／ＰＬＰの概念は活用されなくてもよい。
【０４００】
以下では、説明の便宜のためにＭＩＳＯ又はＭＩＭＯ方式は２つのアンテナを使用するが、本発明は、２つ以上のアンテナを使用するシステムに適用されてもよい。本発明は、特定の用途に要求される性能を達成しながら、受信機複雑度を最小化するために最適化されたフィジカルプロファイル（又は、システム）を提案する。本発明の一実施例に係るフィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）は、該当する受信機が具現しなければならない全ての構造のサブセットであり、大部分の機能ブロックを共有するが、特定のブロック及び／又はパラメータではやや異なる。システム発展のために、ヒューチャープロファイルは、ＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を介して、単一ＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクシングされてもよい。本発明の一実施例に係るベースプロファイル及びハンドヘルドプロファイルは、ＭＩＭＯが適用されないプロファイルを意味し、アドバンスドプロファイルは、ＭＩＭＯが適用されるプロファイルを意味する。ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別できる。そして、本発明のプロファイルは、設計者の意図によって変更されてもよい。
【０４０１】
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。
【０４０２】
補助ストリーム：ヒューチャーエクステンション（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ、将来の拡張）のために又は放送社やネットワーク運営者の要求によって用い得るまだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
【０４０３】
ベースデータパイプ（ｂａｓｅ  ｄａｔａ  ｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ
【０４０４】
ベースバンドフレーム（又は、ＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
【０４０５】
セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値
【０４０６】
コーディングブロック（ｃｏｄｅｄ  ｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコーディングされたブロック又はＰＬＳ２データのＬＤＰＣエンコーディングされたブロックのうちの一つ
【０４０７】
データパイプ（ｄａｔａ  ｐｉｐｅ）：１つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連のメタデータを伝達する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）におけるロジカルチャネル
【０４０８】
データパイプユニット（ＤＰＵ，ｄａｔａ  ｐｉｐｅ  ｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット
【０４０９】
データシンボル（ｄａｔａ  ｓｙｍｂｏｌ）：プリアンブルシンボルでないフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）
【０４１０】
ＤＰ＿ＩＤ：当該８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内でデータパイプを唯一に識別する。
【０４１１】
ダミーセル（ｄｕｍｍｙ  ｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために使用されずに残っている容量を満たすために用いられる擬似ランダム値を伝達するセル
【０４１２】
ＥＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部
【０４１３】
フレーム（ｆｒａｍｅ）：プリアンブルから始まってフレームエッジシンボルで終了する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【０４１４】
フレームレペティションユニット（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ、フレーム反復単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む、同一の又は異なるフィジカルプロファイルに属するフレームの集合
【０４１５】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ、高速情報チャネル）：サービスと当該ベースデータパイプ間におけるマッピング情報を伝達するフレームでロジカルチャネル
【０４１６】
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコーディングされたビットの集合
【０４１７】
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同じ特定のモードに用いられる名目上のＦＦＴサイズ
【０４１８】
フレームシグナリングシンボル（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、ガードインターバル（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定の組合せせにおいてフレームの先頭で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【０４１９】
フレームエッジシンボル（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）：ＦＦＴサイズ、ガードインターバル、及びスキャッタパイロットパターンの特定の組合せせにおいてフレームの末尾で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【０４２０】
フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームにおいて同じフィジカルプロファイルタイプを有する全てのフレームの集合
【０４２１】
ヒューチャーエクステンションフレーム（ｆｕｔｕｒｅ  ｅｘｔｅｎｔｉｏｎ  ｆｒａｍｅ、将来の拡張フレーム）：プリアンブルで始まる、将来の拡張に用いられ得るスーパーフレーム内で物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【０４２２】
ヒューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである提案された物理層放送システム
【０４２３】
インプットストリーム（ｉｎｐｕｔ  ｓｔｒｅａｍ、入力ストリーム）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
【０４２４】
ノーマル（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除くデータシンボル
【０４２５】
フィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）：該当する受信機が具現すべき全ての構造のサブセット
【０４２６】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
【０４２７】
ＰＬＳ１：ＰＬＳ２をデコーティングするために必要なパラメータだけでなく、システムに関する基この情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｌｉｎｇ  ｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合
【０４２８】
ＮＯＴＥ：ＰＬＳ１データはフレームグループのデューレーション（ｄｕｒａｔｉｏｎ）において一定である。
【０４２９】
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合
【０４３０】
ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データ：フレームごとにダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＰＬＳ２データ
【０４３１】
ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データ：フレームグループのデューレーションにおいてスタティック（ｓｔａｔｉｃ、静的）であるＰＬＳ２データ
【０４３２】
プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅ  ｓｉｇｎａｌｉｎｇ  ｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ
【０４３３】
プリアンブルシンボル（ｐｒｅａｍｂｌｅ  ｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達とフレームの先頭に位置する固定された長さのパイロットシンボル
【０４３４】
プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に用いられる。
【０４３５】
将来の使用（ｆｕｔｕｒｅ  ｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書では定義されないが、将来に定義可能である。
【０４３６】
スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合
【０４３７】
タイムインターリービングブロック（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｂｌｏｃｋ、ＴＩ  ｂｌｏｃｋ）：タイムインターリーバメモリーの一つの用途に該当する、タイムインターリービングが実行されるセルの集合
【０４３８】
タイムインターリービンググループ（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｇｒｏｕｐ，ＴＩ  ｇｒｏｕｐ）：整数、ダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＸＦＥＣＢＬＯＣＫの数で構成された、特定のデータパイプに対するダイナミック（ｄｙｎａｍｉｃ、動的）容量割り当てが実行される単位
【０４３９】
ＮＯＴＥ：タイムインターリービンググループは一つのフレームに直接マッピングされてもよく、複数のフレームにマッピングされてもよい。タイムインターリービンググループは、一つ以上のタイムインターリービングブロックを含むことができる。
【０４４０】
タイプ１データパイプ（Ｔｙｐｅ １ ＤＰ）：全てのデータパイプがフレームにＴＤＭ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマッピングされるフレームのデータパイプ
【０４４１】
タイプ２データパイプ（Ｔｙｐｅ２ＤＰ）：全てのデータパイプがフレームにＦＤＭ方式でマッピングされるフレームのデータパイプ
【０４４２】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮcellsセルの集合
【０４４３】
図１８は、本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置の構造を示す。
【０４４４】
本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Ｉｎｐｕｔ  Ｆｏｒｍａｔ  ｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）ジェネレーションブロック（ＯＦＤＭ  ｇｅｎｅｒａｔｉｏｎ  ｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【０４４５】
本発明の一実施例に係る入力データは、ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳを主要入力フォーマットとすることができ、他のストリームタイプは一般ストリームとして扱う。これらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する当該帯域幅のスケジューリング及び割り当てを制御する。また本発明では、一つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリーム入力が同時に許容される。
【０４４６】
インプットフォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される一つ又は複数のデータパイプにデマチルプレクシングすることができる。データパイプは堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に影響を及ぼす。一つ又は複数のサービス又はサービスコンポーネントを一つのデータパイプによって伝達することができる。データパイプは、一つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連メタデータを伝達する物理層におけるロジカルチャネルである。
【０４４７】
また、データパイプユニットは、一つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【０４４８】
物理層への入力は、一つ又は複数のデータストリームで構成されてもよい。それぞれのデータストリームは、一つのデータパイプによって伝達される。インプットフォーマットブロック１０００は、一つ又はそれ以上の物理的経路（ｐｈｙｓｉｃａｌ  ｐａｔｈ又はＤＰ）を介して入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄ  ｆｒａｍｅ）に変換することができる。この場合、インプットフォーマットブロック１０００は、入力データ（ＴＳ又はＩＰ入力ストリーム）に対して伝送効率を増加させるためにヌルパケットディリーション（ｎｕｌｌ  ｐａｃｋｅｔ  ｄｅｌｅｔｉｏｎ）又はヘッダーコンプレッション（ｈｅａｄｅｒ  ｃｏｍｐｒｅｓｓｉｏｎ）を行うことができる。受信機は、ヘッダーの特定の部分に対する先験的な（ａ  ｐｒｉｏｒｉ）情報を有することができることから、この知られた情報（ｋｎｏｗｎ  ｉｎｆｏｒｍａｔｉｏｎ）は送信機で削除されてもよい。ヌルパケットディリーションブロック（３０３０）は、ＴＳ入力ストリームである場合にのみ利用可能である。
【０４４９】
ＢＩＣＭブロック１０１０で、パリティ（ｐａｒｉｔｙ）データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値コンステレーションシンボルにマッピングされる。当該シンボルは当該データパイプに用いられる特定のインターリービング深さにわたってインターリービングされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。
【０４５０】
フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマッピングし、周波数領域ダイバーシティのために、特に、周波数選択的フェーディングチャネルを防止するために周波数インターリービングを行うことができる。フレームビルディングブロックは、ディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロック、セルマッパー（ｃｅｌｌ  ｍａｐｐｅｒ）及びフリケンシーインターリーバ（ｆｒｅｑｕｅｎｃｙ  ｉｎｔｅｒｌｅａｖｅｒ）を含むことができる。
【０４５１】
ディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロックは、データパイプと該当するＰＬＳデータ間のタイミングを調節して、送信機側でデータパイプと該当するＰＬＳデータ間の同時性（ｃｏ−ｔｉｍｅ）を保障することができる。インプットフォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことにより、ＰＬＳデータはデータパイプの分だけ遅れる。ＢＩＣＭブロックの遅延は主にタイムインターリーバに起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次のタイムインターリービンググループの情報を、シグナリングされるデータパイプよりも１フレーム先立って伝達されるようにすることができる。ディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロックは、それに合わせてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。
【０４５２】
セルマッパーは、ＰＬＳ、データパイプ、補助ストリーム、及びダミーセルなどを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングすることができる。セルマッパーの基本機能は、それぞれのデータパイプ、ＰＬＳセルに対するタイムインターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマッピングすることである。（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集されてデータパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成されたダイナミックインフォメーション（ｄｙｎａｍｉｃ  ｉｎｆｏｒｍａｔｉｏｎ、動的情報）に応じて動作する。フリケンシーインターリーバは、セルマッパーから受信されたデータセルをランダムにインターリービングして周波数ダイバーシティを提供することができる。また、フリケンシーインターリーバは、単一フレームで最大のインターリービング利得を得るために、異なるインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（ｐａｉｒ、対）で動作することができる。
【０４５３】
ＯＦＤＭジェネレーションブロック１０３０は、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは順次にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
【０４５４】
具体的に、プリアンブルを各フレームの先頭に挿入した後、ＯＦＤＭジェネレーションブロック１０３０は、サイクリックプレフィックス（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）をガードインターバルとして有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシティのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、本発明は、様々なＦＦＴサイズ、ガードインターバル長さ、当該パイロットパターンの集合を提供する。
【０４５５】
また、本発明は、放送サービスを提供する２つ以上の異なる放送送信／受信システムのデータが同じＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクシングすることができる。この場合、２つ以上の異なる放送送信／受信システムは、それぞれ異なる放送サービスを提供するシステムのことをいう。それぞれ異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。
【０４５６】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように伝送される。本発明の一実施例に係るシグナリング情報は、ＰＬＳデータを含むことができる。ＰＬＳは、受信機でフィジカルレイヤー（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）データパイプに接続し得る手段を提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。
【０４５７】
ＰＬＳ１データは、ＰＬＳ２データをデコーティングするために必要なパラメータの他、システムに関する基この情報を伝達する固定されたサイズ、コーディング、変調を有するフレームにおいてＦＳＳで伝達される、ＰＬＳデータの一番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデューレーションにおいて一定である。
【０４５８】
ＰＬＳ２データは、データパイプ及びシステムに関するより一層詳細なＰＬＳデータを伝達するＦＳＳで伝送される、ＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコーティングするのに十分な情報を提供するパラメータを含む。さらに、ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータで構成される。ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データは、フレームグループのデューレーションの間にスタティック（ｓｔａｔｉｃ、静的）であるＰＬＳ２データであり、ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データは、フレームごとにダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＰＬＳ２データである。ＰＬＳデータに関する詳細な内容は後述する。
【０４５９】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックによって代替されてもよい。
【０４６０】
図１９は、本発明の一実施例に係るＢＩＣＭブロックを示す。
【０４６１】
図１９に示すＢＩＣＭブロックは、図１８を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０４６２】
前述したように、本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０４６３】
ＱｏＳが、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータは、それぞれ異なる方式で処理されなければならない。したがって、本発明の一実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することによって、各データパイプを独立して処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプを介して伝送される各サービス又はサービスコンポーネントに対するＱｏＳを調節することができる。
【０４６４】
（ａ）は、ＭＩＭＯが適用されないプロファイル（又は、システム）に適用されるＢＩＣＭブロックを示し、（ｂ）はＭＩＭＯが適用されるプロファイル（又は、システム）のＢＩＣＭブロックを示す。
【０４６５】
ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０４６６】
ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックのそれぞれの処理ブロックについて説明する。
【０４６７】
ＭＩＭＯが適用されないＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
【０４６８】
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は、選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作については後述する。
【０４６９】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながら、データＦＥＣエンコーダ５０１０の出力をインターリービングして、ＬＤＰＣコード及び変調方式の組合せせによって最適化した性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
【０４７０】
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４，ＮＵＱ−２５６，ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６，ＮＵＣ−６４，ＮＵＣ−２５６，ＮＵＣ−１０２４）を用いて、ベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調して、電力の正規化されたコンステレーションポイントｅlを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱは任意の形態を有するが、ＱＡＭ−１６及びＮＵＱは正方形の形状を有することが観察される。それぞれのコンステレーションが９０°の倍数だけ回転すると、回転されたコンステレーションは、元来のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均電力がお互い同一になる。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ  ｒａｔｅ）に対して特別に定義され、用いられるいずれか一つは、ＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによってシグナリングされる。
【０４７１】
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定されてもよい。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０４７２】
ＭＩＭＯが適用されるＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。
【０４７３】
ただし、処理ブロック５０００−１は、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で、ＭＩＭＯの適用されないＢＩＣＭの処理ブロック５０００と区別される。
【０４７４】
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
【０４７５】
セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。
【０４７６】
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いて、セルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号送信のために最適化されている。ＭＩＭＯ技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に、放送に対して、異なる信号電波特性による２つのアンテナ間の受信信号電力差又はチャネルの強いＬＯＳコンポーネントは、ＭＩＭＯから容量利得を得ることを難しくさせる。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの位相ランダム化及び回転ベースのプリコーディングを用いてこの問題を克服する。
【０４７７】
ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２×２ＭＩＭＯシステムのために意図される。本発明のＭＩＭＯエンコーディングモードは、ＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）と定義できる。ＦＲ−ＳＭエンコーディングは、受信機側における比較的小さい複雑度の増加で容量増加を提供することができる。また、本発明のＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。
【０４７８】
ＭＩＭＯ処理は、データパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ、対）であるＮＵＱ（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（ｐａｉｒ、対）（ｇ1,i及びｇ2,i）は、それぞれの送信アンテナの同じキャリアｋ及びＯＦＤＭシンボルｌによって伝送される。
【０４７９】
前述したブロックは、省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０４８０】
図２０は、本発明の他の実施例に係るＢＩＣＭブロックを示す。
【０４８１】
図２０に示す、ＢＩＣＭブロックは、図１８を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０４８２】
図２０は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。ＥＡＣ及びＦＩＣに関する詳細な説明は後述する。
【０４８３】
図２０を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。
【０４８４】
また、ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブラー、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて説明する。
【０４８５】
ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブリングされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコーディングすることができる。
【０４８６】
スクランブラーは、ＢＣＨエンコーディング及びショートニング（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャリングされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブリングすることができる。
【０４８７】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いて、スクランブリングされたＰＬＳ１／２データに外部エンコーディングを行い、ＢＣＨエンコーディング後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディング前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）することができる。
【０４８８】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、Ｃldpc及びパリティビットＰldpcは、それぞれのゼロが挿入されたＰＬＳ情報ブロックＩldpcから組織的にエンコーディングされ、その後に添付される。
【数１】
0006259114.tif 000002
【０４８９】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０４９０】
ショートニングがＰＬＳ１データ保護に適用されると、一部のＬＤＰＣパリティビットは、ＬＤＰＣエンコーディング後にパンクチャリングされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャリングされる。これらのパンクチャリングされたビットは伝送されない。
【０４９１】
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインターリービングすることができる。
【０４９２】
コンステレーションマッパー６０２０は、ビットインターリービングされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。
【０４９３】
前述したブロックは、省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０４９４】
図２１は、本発明の一実施例に係るＰＬＳのビットインターリービングを過程を示す図である。
【０４９５】
それぞれのショートニング及びパンクチャリングされたＰＬＳ１及びＰＬＳ２コーディングブロックは、図２１に示すように、１ビットずつインターリービングされる。追加パリティビットの各ブロックは、同じブロックインターリービング構造でインターリービングされるが、別途にインターリービングされる。
【０４９６】
ＢＰＳＫである場合、実数及び虚数の部分でＦＥＣコーディングビットを複製するために、ビットインターリービングのための２つのブランチが存在する。それぞれのコーディングブロックは、上位ブランチにまず書き込まれる。ビットは、サイクリックシフト値フロアー（ＮFEC／２）でモジューロＮFEC加算を適用することによって、下位ブランチにマッチングされる。ここで、ＮFECは、ショートニング及びパンクチャリング後のそれぞれのＬＤＰＣコーディングブロックの長さである。
【０４９７】
ＱＳＰＫ、ＱＡＭ−１６、ＮＵＱ−６４のような他の変調である場合、ＦＥＣコーディングビットは列方向に順次にインターリーバに書き込まれる。ここで、列の数は変調次数と同一である。
【０４９８】
読み出し動作で、一つのコンステレーションシンボルに対するビットは順次に行方向に読み出され、ビットデマルチプレクサブロックに入力される。これらの動作は列の最後まで続く。
【０４９９】
それぞれのビットインターリービンググループは、コンステレーションマッピング前にグループで１ビットずつデマチルプレクシングされる。変調次数によって、２つのマッピング規則がある。ＢＰＳＫ及びＱＰＳＫである場合、一つのシンボルにおいてビットの信頼度は同一である。したがって、ビットインターリービングブロックから読み出されたビットグループは、いかなる動作無しでＱＡＭシンボルにマッチングされる。
【０５００】
ＱＡＭシンボルにマッピングされたＱＡＭ−１６及びＮＵＱ−６４である場合、動作の規則が図２１（ａ）に説明されている。図２１（ａ）に示すように、ｉは、ビットインターリービングにおいて列インデックスに該当するビットグループインデックスである。
【０５０１】
図２１は、ＱＡＭ−１６に対するビットデマチルプレクシング規則を示す。この動作は、全てのビットグループがビットインターリービングブロックから読み出されるまで続く。
【０５０２】
図２２は、本発明の一実施例に係る、次世代放送サービスに対する放送信号受信装置の構造を示す。
【０５０３】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１８を参照して説明した、次世代放送サービスに対する放送信号送信装置に対応し得る。
【０５０４】
本発明の一実施例に係る、次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ＆  ｄｅｍｏｄｕｌａｔｉｏｎ  ｍｏｄｕｌｅ）９０００、フレームパーシングモジュール（ｆｒａｍｅ  ｐａｒｓｉｎｇ  ｍｏｄｕｌｅ）９０１０、デマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ  ＆  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０２０、出力プロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）９０３０、及びシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇ  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
【０５０５】
同期及び復調モジュール９０００は、ｍ個の受信アンテナから入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆過程に該当する復調を実行することができる。
【０５０６】
フレームパーシングモジュール９０１０は、入力信号フレームをパーシングし、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行していると、フレームパーシングモジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるへき信号及びデータの位置を、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることで取得し、放送信号送信装置によって生成されたスケジューリング情報を復元することができる。
【０５０７】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によって、ビット領域データをデインターリービングすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングによって伝送チャネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。
【０５０８】
出力プロセッサ９０３０は、伝送効率を向上させるために放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆過程を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を取得することができる。出力プロセッサ９０３０の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及びＧＳであり得る。
【０５０９】
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０５１０】
本発明の一実施例に係るフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、ノーマルデータシンボル、ＦＥＳを含む。
【０５１１】
プリアンブルは、高速ヒューチャーキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルに関する詳細な内容は後述する。
【０５１２】
ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、それによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルよりも高密度のパイロットパターンを有する。ＦＥＳは、ＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳの直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しに、ＦＥＳ内における周波数だけのインターポレーション（ｉｎｔｅｒｐｏｌａｔｉｏｎ、補間）及び時間的補間（ｔｅｍｐｏｒａｌ  ｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。
【０５１３】
図２３は、本発明の一実施例に係る、フレームのシグナリング階層構造（ｓｉｇｎａｌｉｎｇ  ｈｉｅｒａｒｃｈｙ  ｓｔｒｕｃｔｕｒｅ）を示す。
【０５１４】
図２３は、シグナリング階層構造を示しているが、これは、３つの主要部分であるプリアンブルシグナリングデータ（１１０００）、ＰＬＳ１データ（１１０１０）、及びＰＬＳ２データ（１１０２０）に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーティングできるようにする。ＰＬＳ２は、毎フレームごとに伝達され、２つの主要部分である、ＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データのスタティック（ｓｔａｔｉｃ、静的）及びダイナミック（ｄｙｎａｍｉｃ、動的）部分には、必要時にパディングが続く。
【０５１５】
本発明の一実施例に係るプリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳細な内容は、次のとおりである。
【０５１６】
ＦＦＴ＿ＳＩＺＥ：当該２ビットフィールドは、下記の表１で説明しているとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。
【表１】
0006259114.tif 000003
【０５１７】
ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表２で説明しているとおり、現スーパーフレームにおけるガードインターバル一部（ｆｒａｃｔｉｏｎ）の値を示す。
【表２】
0006259114.tif 000004
【０５１８】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームに提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームに提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドは、スーパーフレーム内でダイナミック（ｄｙｎａｍｉｃ、動的）に切り替えることができる。
【０５１９】
ＰＩＬＯＴ＿ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードか又は固定モードかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。
【０５２０】
ＰＡＰＲ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅ  ｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。
【０５２１】
ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来の使用のためにリザーブされる。
【０５２２】
図２４は、本発明の一実施例に係るＰＬＳ１データを示す。
【０５２３】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含む基本伝送パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全体デューレーションにおいて変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は、次のとおりである。
【０５２４】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：当該２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧを除いたプリアンブルシグナリングデータのコピーである。
【０５２５】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：当該２ビットフィールドは、ＦＲＵ当たりのフレーム数を示す。
【０５２６】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表３に示すようにシグナリングされる。
【表３】
0006259114.tif 000005
【０５２７】
ＮＵＭ＿ＦＳＳ：当該２ビットフィールドは、現フレームでＦＳＳの数を示す。
【０５２８】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０５２９】
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は互換不可能な変化を示す。デフォルト値は、００００である。当該標準で記述されたバージョンに対して、値が００００に設定される。
【０５３０】
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は互換可能である。
【０５３１】
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワークで地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジは、ヒューチャーキャストＵＴＢシステム当たりに用いられる周波数の数によって一つ以上の周波数で構成され得る。ＣＥＬＬ＿ＩＤの値が知られていないか、特定されていないと、当該フィールドは０に設定される。
【０５３２】
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。
【０５３３】
ＳＹＳＴＥＭ＿ＩＤ：当該１６ビットフィールドは、ＡＴＳＣネットワーク内でヒューチャーキャストＵＴＢシステムを唯一に識別する。ヒューチャーキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。ヒューチャーキャストＵＴＢシステムは、存在するなら、ＦＥＦ及び一つ以上のフィジカルプロファイルを伝達する。同じヒューチャーキャストＵＴＢシステムは、互いに異なる入力ストリームを伝達し、異なる地理的領域で異なるＲＦを用いることができるので、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは、一つの場所で制御され、ヒューチャーキャストＵＴＢシステム内で全ての伝送に対して同一である。一つ以上のヒューチャーキャストＵＴＢシステムはいずれも同じフィジカル構造及び構成を有するという同一ＳＹＳＴＥＭ＿ＩＤの意味を有することができる。
【０５３４】
次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦを含む）がシグナリングされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４よりも小さいと、使用されないフィールドはゼロで埋められる。
【０５３５】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレーム（ｉはループ（ｌｏｏｐ）インデックス）のフィジカルプロファイルタイプを示す。当該フィールドは、表８に示したものと同じシグナリングフォーマットを用いる。
【０５３６】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：当該２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを使用すると、フレームデューレーションの正確な値が得られる。
【０５３７】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームのガードインターバル一部の値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７によってシグナリングされる。
【０５３８】
ＲＥＳＥＲＶＥＤ：当該４ビットフィールドは将来の使用のためにリザーブされる。
【０５３９】
次のフィールドは、ＰＬＳ２データをデコードするためのパラメータを提供する。
【０５４０】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表４によってシグナリングされる。ＬＤＰＣコードに関する詳細な内容は後述する。
【表４】
0006259114.tif 000006
【０５４１】
ＰＬＳ２＿ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは、表５によってシグナリングされる。
【表５】
0006259114.tif 000007
【０５４２】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対する全てのコーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_partial_blockを示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５４３】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５４４】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５４５】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０５４６】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、現フレームグループの毎フレームごとに伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_partial_blockを示す。反復が使用されない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５４７】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられるＦＥＣタイプを示す。ＦＥＣタイプは表１０によってシグナリングされる。
【０５４８】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：当該３ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられる変調タイプを示す。変調タイプは、表１１によってシグナリングされる。
【０５４９】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが次のフレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０５５０】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、次のフレームグループの毎フレームごとに伝達されるＰＬＳ２に対する全体コーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_full_blockを示す。次のフレームグループで反復が使用されない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５５１】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０５５２】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０５５３】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。下記の表６は、当該フィールドの値を提供する。当該フィールドの値が００に設定されると、現フレームグループで追加パリティがＰＬＳ２に対して使用されない。
【表６】
0006259114.tif 000008
【０５５４】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５５５】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。表１２は、当該フィールドの値を定義する。
【０５５６】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５５７】
ＲＥＳＥＲＶＥＤ：当該３２ビットフィールドは、将来の使用のためにリザーブされる。
【０５５８】
ＣＲＣ＿３２：全体ＰＬＳ１シグナリングに適用される３２ビットエラー検出コード
【０５５９】
図２５は、本発明の一実施例に係るＰＬＳ２データを示す。
【０５６０】
図２５は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
【０５６１】
以下、ＰＬＳ２−ＳＴＡＴデータのフィールドについて具体的に説明する。
【０５６２】
ＦＩＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＦＩＣが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームに提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５６３】
ＡＵＸ＿ＦＬＡＧ：当該１ビットフィールドは、補助ストリームが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、補助ストリームは現フレームに提供される。当該フィールドの値が０に設定されると、補助フレームは現フレームで伝達されない。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５６４】
ＮＵＭ＿ＤＰ：当該６ビットフィールドは、現フレーム内で伝達されるデータパイプの数を示す。当該フィールドの値は１〜６４であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
【０５６５】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内で唯一に識別する。
【０５６６】
ＤＰ＿ＴＹＰＥ：当該３ビットフィールドは、データパイプのタイプを示す。これは、下記の表７によってシグナリングされる。
【表７】
0006259114.tif 000009
【０５６７】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：当該８ビットフィールドは、現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同じＤＰ＿ＧＲＯＵＰ＿ＩＤを有するようになる特定のサービスと関連しているサービスコンポーネントのデータパイプに接続するために用いることができる。
【０５６８】
ＢＡＳＥ＿ＤＰ＿ＩＤ：当該６ビットフィールドは、管理階層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤが示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであるか、サービスシグナリングデータのみを伝達する専用データパイプであり得る。
【０５６９】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表８によってシグナリングされる。
【表８】
0006259114.tif 000010
【０５７０】
ＤＰ＿ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅ  ｒａｔｅ）を示す。コードレート（ｃｏｄｅ  ｒａｔｅ）は、下記の表９によってシグナリングされる。
【表９】
0006259114.tif 000011
【０５７１】
ＤＰ＿ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は、下記の表１０によってシグナリングされる。
【表１０】
0006259114.tif 000012
【０５７２】
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：当該１ビットフィールドは、ＳＳＤモードが関連したデータパイプで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＳＳＤは使用される。当該フィールドの値が０に設定されると、ＳＳＤは使用されない。
【０５７３】
次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ現れる。
【０５７４】
ＤＰ＿ＭＩＭＯ：当該３ビットフィールドは、いかなるタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、下記の表１１によってシグナリングされる。
【表１１】
0006259114.tif 000013
【０５７５】
ＤＰ＿ＴＩ＿ＴＹＰＥ：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、一つのタイムインターリービンググループが一つのフレームに該当し、一つ以上のタイムインターリービングブロックを含むことを示す。１の値は、一つのタイムインターリービンググループが一つよりも多いフレームでに伝達され、一つのタイムインターリービングブロックのみを含むことを示す。
【０５７６】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：当該２ビットフィールド（許容された値は、１、２、４、８のみである）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値によって決定される。
【０５７７】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマッピングされるフレームの数であるＰIを示し、タイムインターリービンググループ当たりに１つのタイムインターリービングブロックが存在する（ＮTI＝１）。当該２ビットフィールドで許容されるＰIの値は、下記の表１２に定義される。
【０５７８】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されると、当該フィールドは、タイムインターリービンググループ当たりにタイムインターリービングブロックの数ＮTIを示し、フレーム当たりに一つのタイムインターリービンググループが存在する（ＰI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１２に定義される。
【表１２】
0006259114.tif 000014
【０５７９】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩJUMP）を示し、許容された値は、１、２、４、８（該当する２ビットフィールドはそれぞれ、００、０１、１０、１１）である。フレームグループの全てのフレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１、５、９、１３などのフレームに現れると、当該フィールドの値は４に設定される。全てのフレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。
【０５８０】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：当該１ビットフィールドは、タイムインターリーバ５０５０の可用性を決定する。データパイプに対してタイムインターリービングが使用されないと、当該フィールド値は１に設定される。反面、タイムインターリービングが使用されると、当該フィールド値は０に設定される。
【０５８１】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：当該５ビットフィールドは、現データパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は、０〜３１である。
【０５８２】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：当該１０ビットフィールドは、当該データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。当該フィールドの値は、ＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同じ範囲を有する。
【０５８３】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、下記の表１３によってシグナリングされる。
【表１３】
0006259114.tif 000015
【０５８４】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは、下記の表１４によってシグナリングされる。
【表１４】
0006259114.tif 000016
【０５８５】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、下記の表１５によってシグナリングされる。
【表１５】
0006259114.tif 000017
【０５８６】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングがインプットフォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表１６によってシグナリングされる。
【表１６】
0006259114.tif 000018
【０５８７】
ＤＮＰ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、下記の表１７によってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
【表１７】
0006259114.tif 000019
【０５８８】
ＩＳＳＹ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、下記の表１８によってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
【表１８】
0006259114.tif 000020
【０５８９】
ＨＣ＿ＭＯＤＥ＿ＴＳ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、下記の表１９によってシグナリングされる。
【表１９】
0006259114.tif 000021
【０５９０】
ＨＣ＿ＭＯＤＥ＿ＩＰ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（‘０１’）に設定される場合にＩＰヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、下記の表２０によってシグナリングされる。
【表２０】
0006259114.tif 000022
【０５９１】
ＰＩＤ：当該１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１又は１０に設定される場合にＴＳヘッダー圧縮のためのＰＩＤ数を示す。
【０５９２】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０５９３】
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０５９４】
ＦＩＣ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、ＦＩＣのバージョンナンバーを示す。
【０５９５】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１３ビットフィールドは、ＦＩＣの長さをバイト単位で示す。
【０５９６】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０５９７】
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０５９８】
ＮＵＭ＿ＡＵＸ：当該４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが使用されないことを示す。
【０５９９】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６００】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：当該４ビットは、現補助ストリームのタイプを示すための将来の使用のためにリザーブされる。
【０６０１】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：当該２８ビットフィールドは、補助ストリームをシグナリングするための将来の使用のためにリザーブされる。
【０６０２】
図２６は、本発明の他の実施例に係るＰＬＳ２データを示す。
【０６０３】
図２６は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は、一つのフレームグループのデューレーションにおいて変化可能である一方、フィールドのサイズは一定である。
【０６０４】
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は次のとおりである。
【０６０５】
ＦＲＡＭＥ＿ＩＮＤＥＸ：当該５ビットフィールドは、スーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
【０６０６】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナリングされる値によって示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、１の値は、次のスーパーフレームに変化があることを示す。
【０６０７】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナリングされる値によって示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、０００１の値は、次のスーパーフレームに変化があることを示す。
【０６０８】
ＲＥＳＥＲＶＥＤ：当該１６ビットフィールドは、将来の使用のためにリザーブされる。
【０６０９】
次のフィールドは、現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰにおけるループ（ｌｏｏｐ）に現れる。
【０６１０】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でデータパイプを唯一に示す。
【０６１１】
ＤＰ＿ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初のの開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、下記の表２１に示すとおり、フィジカルプロファイル及びＦＦＴサイズによって異なる長さを有する。
【表２１】
0006259114.tif 000023
【０６１２】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：当該１０ビットフィールドは、現データパイプに対する現タイムインターリービンググループでＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は、０〜１０２３である。
【０６１３】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６１４】
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
【０６１５】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームでＥＡＣの存在を示す。当該ビットは、プリアンブルでＥＡＣ＿ＦＬＡＧと同一の値である。
【０６１６】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：当該８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。
【０６１７】
ＥＡＣ＿ＦＬＡＧフィールドが１と同一であれば、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０と同一であれば、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
【０６１８】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１２ビットフィールドは、ＥＡＣの長さをバイトで示す。
【０６１９】
ＥＡＣ＿ＣＯＵＮＴＥＲ：当該１２ビットフィールドは、ＥＡＣが到達するフレーム前のフレームの数を示す。
【０６２０】
次のフィールドは、ＡＵＸ＿ＦＬＡＧフィールドが１と同一である場合にのみ現れる。
【０６２１】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：当該４８ビットフィールドは、補助ストリームをシグナリングするための将来の使用のためにリザーブされる。当該フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０６２２】
ＣＲＣ＿３２：全体ＰＬＳ２に適用される３２ビットエラー検出コード。
【０６２３】
図２７は、本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ）構造を示す。
【０６２４】
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームにおいてＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は最初に、一つ以上のＦＳＳにマッピングされる。続いて、ＥＡＣが存在すると、ＥＡＣセルは直後のＰＬＳフィールドにマッピングされる。次に、ＦＩＣが存在すると、ＦＩＣセルがマッピングされる。データパイプは、ＰＬＳの次にマッピングされたり、ＥＡＣ又はＦＩＣが存在する場合、ＥＡＣ又はＦＩＣの後にマッピングされる。タイプ１データパイプが最初にマッピングされ、タイプ２データパイプがその次にマッピングされる。データパイプのタイプの具体的な内容は後述する。一部である場合、データパイプは、ＥＡＳに対する一部の特殊データ又はサービスシグナリングデータを伝達することができる。補助ストリーム又はストリームは、存在するなら、データパイプの次にマッピングされ、そこには順にダミーセルが続く。前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順序で全て一緒にマッピングすると、フレームでセル容量を正確に満たす。
【０６２５】
図２８は、本発明の一実施例に係るＰＬＳマッピングを示す。
【０６２６】
ＰＬＳセルはＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングされる。ＰＬＳの占めるセルの数によって、一つ以上のシンボルがＦＳＳと指定され、ＦＳＳの数ＮFSSは、ＰＬＳ１におけるＮＵＭ＿ＦＳＳによってシグナリングされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳにおいて重大な事項であるが、ＦＳＳは、高いパイロット密度を有しているので、高速同期化、及びＦＳＳ内における周波数のみのインターポレーション（ｉｎｔｅｒｐｏｌｏａｔｉｏｎ、補間）を可能にする。
【０６２７】
ＰＬＳセルは、図示しているように、下方に向いて、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングされる。ＰＬＳ１セルは最初に、一番目のＦＳＳの一番目のセルから始まって、セルインデックスの昇順でマッピングされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、最初のＦＳＳの最後のセルインデックスまで下方に続けてマッピングされる。必要なＰＬＳセルの総数が、一つのＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアの数を超えると、マッピングは、次のＦＳＳに進み、最初のＦＳＳと全く同じ方式で続いて行われる。
【０６２８】
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、ＥＡＣ及びＦＩＣは、ＰＬＳとノーマルデータパイプとの間に配置される。
【０６２９】
以下では、本発明の一実施例に係るＦＥＣ構造及びエンコーディングについて説明する。前述したように、データＦＥＣエンコーダは、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示のＦＥＣ構造はＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに該当する同一値を有する。
【０６３０】
上述したとおり、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋbchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコーディングされたＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０６３１】
Ｎldpcの値は６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
【０６３２】
下記の表２２及び表２３は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。
【表２２】
0006259114.tif 000024
【表２３】
0006259114.tif 000025
【０６３３】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次のとおりである。
【０６３４】
１２−エラー訂正ＢＣＨコードがＢＢＦの外部エンコーディングに用いられる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は、全ての多項式をかけることによって得られる。
【０６３５】
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコーディングするために用いられる。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）がそれぞれのＩldpc（ＢＣＨ−エンコーディングされたＢＢＦ）から組織的にエンコーディングされ、Ｉldpcに添付される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。
【数２】
0006259114.tif 000026
【０６３６】
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２２及び表２３にそれぞれ与えられる。
【０６３７】
ロングＦＥＣＢＬＯＣＫに対してＮldpc−Ｋldpcパリティビットを計算する具体的な手順は、次のとおりである。
【０６３８】
１）パリティビット初期化
【数３】
0006259114.tif 000027
【０６３９】
２）パリティーチェックマトリクスのアドレスの一番目の行で特定されたパリティビットアドレスにおいて一番目の情報ビットｉ0を累算（ａｃｃｕｍｕｌａｔｅ）する。パリティーチェックマトリクスのアドレスの詳細な内容は、後述する。例えば、比率１３／１５に対して、
【数４】
0006259114.tif 000028
【０６４０】
３）次の３５９個の情報ビットｉs、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビットアドレスでｉsを累算（ａｃｃｕｍｕｌａｔｅ）する。
【数５】
0006259114.tif 000029
【０６４１】
ここで、ｘは、一番目のビットｉ0に該当するパリティビット累算器のアドレスを表し、Ｑldpcは、パリティーチェックマトリクスのアドレスで特定されたコードレート（ｃｏｄｅ  ｒａｔｅ）依存定数である。上記例である、比率１３／１５に対する、したがって情報ビットｉ1に対するＱldpc＝２４に続いて、次の動作が実行される。
【数６】
0006259114.tif 000030
【０６４２】
４）３６１番目の情報ビットｉ360に対して、パリティビット累算器のアドレスは、パリティーチェックマトリクスのアドレスの二番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉs、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器のアドレスは、式６から得られる。ここで、ｘは、情報ビットｉ360に該当するパリティビット累算器のアドレス、すなわち、パリティーチェックマトリクスの二番目の行のエントリーを示す。
【０６４３】
５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティーチェックマトリクスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めるのに用いられる。
【０６４４】
全ての情報ビットが利用された後、最終パリティビットが次のように得られる。
【０６４５】
６）ｉ＝１から始まって次の動作を順次に実行する。
【数７】
0006259114.tif 000031
【０６４６】
ここで、ｐi、ｉ＝０，１，．．．Ｎldpc−Ｋldpc−１の最終コンデンツは、パリティビットｐiと同一である。
【表２４】
0006259114.tif 000032
【０６４７】
表２４を表２５に代え、且つロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスを、ショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスに代える以外は、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔＬＤＰＣエンコーディング手順に従う。
【表２５】
0006259114.tif 000033
【０６４８】
図２９は、本発明の一実施例に係るタイムインターリービングを示す。
【０６４９】
（ａ）乃至（ｃ）は、タイムインターリービングモードの例を示す。
【０６５０】
タイムインターリーバは、データパイプレベルで動作する。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定されてもよい。
【０６５１】
ＰＬＳ２−ＳＴＡＴデータの一部に現れる次のパラメータはタイムインターリービングを構成する。
【０６５２】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０又は１）：タイムインターリービングモードを示す。０は、タイムインターリービンググループ当たりに複数のタイムインターリービングブロック（一つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、一つのタイムインターリービンググループは一つのフレームに（フレーム間インターリービング無しで）直接マッピングされる。１は、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックのみを有するモードを示す。この場合、タイムインターリービングブロックは、一つ以上のフレームにわたって拡散される（フレーム間インターリービング）。
【０６５３】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’であれば、当該パラメータは、タイムインターリービンググループ当たりにタイムインターリービングブロックの数ＮTIである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘１’である場合、当該パラメータは、一つのタイムインターリービンググループから拡散されるフレームの数ＰIである。
【０６５４】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりにＸＦＥＣＢＬＯＣＫの最大数を示す。
【０６５５】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１，２，４，８）：与えられたフィジカルプロファイルの同じデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩJUMPを示す。
【０６５６】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０又は１）：タイムインターリービングがデータフレームに利用されないと、当該パラメータは１に設定される。タイムインターリービングが利用されると、０に設定される。
【０６５７】
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫは、データグループの一つのタイムインターリービンググループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
【０６５８】
タイムインターリービングがデータフレームに利用されないと、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかし、スケジューラからのダイナミック（ｄｙｎａｍｉｃ、動的）構成情報のためのディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロックは相変らず必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、タイムインターリービンググループにグルーピングされる。すなわち、それぞれのタイムインターリービンググループは、整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（ｄｙｎａｍｉｃ、動的）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎのタイムインターリービンググループに存在するＸＦＥＣＢＬＯＣＫの数はＮxBLOCK_Group（ｎ）と表し、ＰＬＳ２−ＤＹＮデータにおいてＤＰ＿ＮＵＭ＿ＢＬＯＣＫでシグナリングされる。この際、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ（ｎ）は、最小値０から、最大の値が１０２３である最大値ＮxBLOCK_Group_MAX（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに当該）まで変化してもよい。
【０６５９】
それぞれのタイムインターリービンググループは、一つのフレームに直接マッピングされたり、ＰI個のフレームにわたって拡散される。また、それぞれのタイムインターリービンググループは、一つ以上（ＮTI個）のタイムインターリービングブロックに分離される。ここで、それぞれのタイムインターリービングブロックは、タイムインターリーバメモリーの一つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは、若干の異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービングブロックに分離されると、タイムインターリービンググループは一つのフレームにのみ直接マッピングされる。下記の表２６に示すように、タイムインターリービングには３つのオプションがある（タイムインターリービングを省略する追加オプションは除く）。
【表２６】
0006259114.tif 000034
【０６６０】
一般に、タイムインターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファーとしても働くことができる。これは、それぞれのデータパイプに対して２個のメモリーバンクによって達成される。一番目のタイムインターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み出される間に、二番目のタイムインターリービングブロックが二番目のバンクに書き込まれる。
【０６６１】
タイムインターリービングは、ツイストされた行−列ブロックインターリーバである。ｎ番目のタイムインターリービンググループのｓ番目のタイムインターリービングブロックに対して、列の数ＮcがＮxBLOCK_TI（ｎ，ｓ）と同一であるが、 タイムインターリービングメモリーの行の数Ｎrは、セルの数Ｎcellsと同一である（すなわち、Ｎr＝Ｎcells）。
【０６６２】
図３０は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
【０６６３】
図３０（ａ）は、タイムインターリーバにおける書き込み動作を示し、図３０（ｂ）は、タイムインターリーバにおける読み出し動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫは、タイムインターリービングメモリーの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作がつながる。そして、インターリービングアレイで、セルが対角線方向に読み出される。（ｂ）に示すように、一番目の行から（最も左側列から始まって行に沿って右に）最後の行まで対角線方向読み出しが進行される間に、Ｎr個のセルが読み出される。
【数８】
0006259114.tif 000035
【０６６４】
【数９】
0006259114.tif 000036
【０６６５】
結果的に、読み出されるセル位置は、座標
【数１０】
0006259114.tif 000037
によって算出される。
【０６６６】
図３１は、本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す。
【０６６７】
より具体的に、図３１は、
【数１１】
0006259114.tif 000038
とき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリーでインターリービングアレイを示す。
【０６６８】
【数１２】
0006259114.tif 000039
【０６６９】
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、ＮＴＩ＝１、ＩＪＵＭＰ＝１、ＰＩ＝１によってＰＬＳ２−ＳＴＡＴデータでシグナリングされる。それぞれＮｃｅｌｌｓ＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３，ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６，ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナリングされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナリングされ、これは
【数１３】
0006259114.tif 000040
につながる。
【０６７０】
一つのＯＦＤＭシンボルに該当するデータ上で動作するフリケンシーインターリーバの目的は、フレームビルダーから受信されたデータセルを無作為にインターリービングすることによってフリケンシーダイバーシティを提供することである。一つのフレームで最大インターリービング利得を得るために、２つの順次的なＯＦＤＭシンボルからなる全てのＯＦＤＭシンボルペアに対して異なるインターリービングシーケンスが用いられる。
【０６７１】
したがって、本発明の一実施例に係るフリケンシーインターリーバは、シンボルペアに対応するデータに適用するためのインターリービングアドレスを生成するためのインターリービングアドレスジェネレーターを含むことができる。
【０６７２】
図３２は、本発明の一実施例に係る各ＦＦＴモードによるメイン−ＰＲＢＳジェネレーター及びサブ−ＰＲＢＳジェネレーターで構成されたインターリービングアドレスジェネレーターのブロックダイアグラムを示す図である。
【０６７３】
（ａ）は、８Ｋ ＦＦＴモードに対するインターリービングアドレスジェネレーターのブロックダイアグラムを示し、（ｂ）は、１６Ｋ ＦＦＴモードに対するインターリービングアドレスジェネレーターのブロックダイアグラムを示し、（ｃ）は、３２Ｋ ＦＦＴモードに対するインターリービングアドレスジェネレーターのブロックダイアグラムを示す。
【０６７４】
ＯＦＤＭシンボルペアに対するインターリービング過程は、一つのインターリービングシーケンスを利用し、次のように説明される。
【数１４】
0006259114.tif 000041
このとき、ｘm,l,pは、ｍ番目のフレームでｌ番目のＯＦＤＭシンボルのｐ番目のセルであり、Ｎdataは、データセルの個数である：フレームシグナリングシンボルに対してＮdata＝ＣFSSであり、ノーマルデータに対してＮdata＝Ｃdataであり、フレームエッジシンボルに対してＮdata＝ＣFESである。
【数１５】
0006259114.tif 000042
【０６７５】
【数１６】
0006259114.tif 000043
このとき、Ｈl（ｐ）は、ＰＲＢＳジェネレーターによって生成されたインターリービングアドレスである。
【０６７６】
図３３は、本発明の一実施例に係る全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。
【０６７７】
（ａ）は、メイン−ＰＲＢＳを示し、（ｂ）は、各ＦＦＴモードのためのパラメータＮｍａｘを示す。
【０６７８】
図３４は、本発明の一実施例に係るフリケンシーインターリービングのためのインターリービングアドレス及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。
【０６７９】
（ａ）は、サブ−ＰＲＢＳジェネレーターを示し、（ｂ）は、フリケンシーインターリービングのためのインターリービングアドレスを示す。本発明の一実施例に係るサイクリックシフト値は、シンボルオフセットと呼ぶことができる。
【０６８０】
図３５は、本発明の一実施例に係るタイムインターリーバの書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す。
【０６８１】
図３５は、２つのＴＩグループに対する書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す。
【０６８２】
図面の左側に示すブロックは、ＴＩメモリーアドレスアレイ（ｍｅｍｏｒｙ  ａｄｄｒｅｓｓ  ａｒｒａｙ）を示し、図面の右側に示すブロックは、連続した２つのＴＩグループに対してそれぞれバーチャル（ｖｉｒｔｕａｌ）ＦＥＣブロックがＴＩグループの最も前にそれぞれ２個及び１個が挿入された場合の書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す。
【０６８３】
以下、ＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）モードによってコンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（Ｂｌｏｃｋ  Ｉｎｔｅｒｌｅａｖｅｒ，ＢＩ）を選択的に使用したり、両方とも使用するタイムインターリーバの構造及びタイムインターリービング方法を説明する。本発明の一実施例に係るＰＬＰは、上述したＤＰと同じ概念で使われるフィジカルパス（ｐｈｙｓｉｃａｌ  ｐａｔｈ）であり、呼称は設計者の意図によって変更可能である。
【０６８４】
本発明の一実施例に係るＰＬＰモードは、放送信号送信機又は放送信号送信装置で処理するＰＬＰ個数によって、シングルＰＬＰ（ｓｉｎｇｌｅ  ＰＬＰ）モード又はマルチプルＰＬＰ（ｍｕｌｔｉｐｌｅ  ＰＬＰ）モードを含むことができる。シングルＰＬＰモードは、放送信号送信装置で処理するＰＬＰ個数が一つである場合を意味する。シングルＰＬＰモードはシングルＰＬＰと呼ぶことができる。
【０６８５】
マルチプルＰＬＰモードは、放送信号送信装置で処理するＰＬＰ個数が一つ以上である場合であり、マルチプルＰＬＰモードは、マルチプルＰＬＰと呼ぶこともできる。
【０６８６】
本発明ではＰＬＰモードによって異なるタイムインターリービング方法を適用するタイムインターリービングをハイブリッドタイムインターリービング（Ｈｙｂｒｉｄ  Ｔｉｍｅ  Ｉｎｔｅｒｌｅａｖｉｎｇ）と呼ぶことができる。本発明の一実施例に係るハイブリッドタイムインターリービングは、マルチプルＰＬＰモードである場合、各ＰＬＰ別に（或いは、ＰＬＰレベルで）適用される。
【０６８７】
図３６は、ＰＬＰ個数によって適用するインターリービングタイプを表で示す図である。
【０６８８】
本発明の一実施例に係るタイムインターリーバは、ＰＬＰ＿ＮＵＭの値に基づいてインターリービングタイプ（Ｉｎｔｅｒｌｅａｖｉｎｇ  ｔｙｐｅ）が決定されてもよい。ＰＬＰ＿ＮＵＭは、ＰＬＰモードを示すシグナリングフィールド（ｓｉｇｎａｌｉｎｇ  ｆｉｅｌｄ）である。ＰＬＰ＿ＮＵＭの値が１である場合、ＰＬＰモードはシングルＰＬＰである。本発明の一実施例に係るシングルＰＬＰは、コンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）のみが適用されてもよい。
【０６８９】
ＰＬＰ＿ＮＵＭの値が１よりも大きい場合、ＰＬＰモードは、マルチプルＰＬＰである。本発明の一実施例に係るマルチプルＰＬＰは、コンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（Ｂｌｏｃｋ  Ｉｎｔｅｒｌｅａｖｅｒ，ＢＩ）が適用されてもよい。この場合、コンボリューションインターリーバはインターフレームインターリービング（Ｉｎｔｅｒ  ｆｒａｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックインターリーバはイントラフレームインターリービング（Ｉｎｔｒａ  ｆｒａｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。
【０６９０】
図３７は、上述したハイブリッドタイムインターリーバ構造の第１実施例を含むブロック図である。
【０６９１】
第１実施例に係るハイブリッドタイムインターリーバは、ブロックインターリーバ（ＢＩ）とコンボリューションインターリーバ（ＣＩ）を含むことができる。本発明のタイムインターリーバは、ＢＩＣＭチェーン（ＢＩＣＭ  ｃｈａｉｎ）ブロックとフレームビルダー（Ｆｒａｍｅ  Ｂｕｉｌｄｅｒ）との間に位置し得る。
【０６９２】
図３７及び図３８に示すＢＩＣＭチェーンブロックは、図１９に示すＢＩＣＭブロックの処理ブロック５０００のうちタイムインターリーバ５０５０以外のブロックを含むことができる。図３７及び図３８に示すフレームビルダーは、図１８のフレームビルディング１０２０ブロックと同じ役割を担うことができる。
【０６９３】
上述したとおり、ハイブリッドタイムインターリーバ構造の第１実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１である場合、ブロックインターリーバは適用されず（ブロックインターリーバオフ（ｏｆｆ））、コンボリューションインターリーバだけ適用される。ＰＬＰ＿ＮＵＭ＞１である場合、ブロックインターリーバとコンボリューションインターリーバが全て適用（ブロックインターリーバオン（ｏｎ））されてもよい。ＰＬＰ＿ＮＵＭ＞１である場合、適用されるコンボリューションインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１である場合に適用されるコンボリューションインターリーバの構造及び動作と同一乃至類似してもよい。
【０６９４】
図３８は、上述したハイブリッドタイムインターリーバ構造の第２実施例を含むブロック図である。
【０６９５】
ハイブリッドタイムインターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３７で説明した内容と同一である。ハイブリッドタイムインターリーバ構造の第２実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定され得る。第２実施例に係るハイブリッドタイムインターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この際、ＰＬＰ＿ＮＵＭ＝１である場合とＰＬＰ＿ＮＵＭ＞１である場合に適用されるコンボリューションインターリーバの構造及び動作が互いに異なってもよい。
【０６９６】
図３９は、ハイブリッドタイムデインターリーバの構造の第１実施例を含むブロック図である。
【０６９７】
第１実施例に係るハイブリッドタイムデインターリーバは、上述した第１実施例に係るハイブリッドタイムインターリーバの逆動作に相応する動作を行うことができる。したがって、図３９の第１実施例に係るハイブリッドタイムデインターリーバは、コンボリューションデインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  ｄｅｉｎｔｅｒｌｅａｖｅｒ，ＣＤＩ）とブロックデインターリーバ（Ｂｌｏｃｋ  ｄｅｉｎｔｅｒｌｅａｖｅｒ，ＢＤＩ）を含むことができる。
【０６９８】
ＰＬＰ＿ＮＵＭ＞１である場合に適用されるコンボリューションデインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１である場合に適用されるコンボリューションデインターリーバの構造及び動作と同一乃至類似してもよい。
【０６９９】
ハイブリッドタイムデインターリーバ構造の第１実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１である場合、ブロックデインターリーバは適用されず（ブロックデインターリーバオフ（ｏｆｆ））、コンボリューションデインターリーバだけ適用される。
【０７００】
ハイブリッドタイムデインターリーバのコンボリューションデインターリーバは、インターフレームデインターリービング（Ｉｎｔｅｒ  ｆｒａｍｅ  ｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックデインターリーバは、イントラフレームデインターリービング（Ｉｎｔｒａ  ｆｒａｍｅ  ｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。インターフレームデインターリービング及びイントラフレームデインターリービングの具体的な内容は、前述した内容と同一である。
【０７０１】
図３９及び図４０に示すＢＩＣＭデコーディング（ＢＩＣＭ  ｄｅｃｏｄｉｎｇ）ブロックは、図３７及び図３８のＢＩＣＭチェーン（ＢＩＣＭ  ｃｈａｉｎ）ブロックの逆動作を行うことができる。
【０７０２】
図４０は、ハイブリッドタイムデインターリーバの構造の第２実施例を含むブロック図である。
【０７０３】
第２実施例に係るハイブリッドタイムデインターリーバは、上述した第２実施例に係るハイブリッドタイムインターリーバの逆動作に相応する動作を行うことができる。ハイブリッドタイムデインターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３９で説明した内容と同一であることができる。
【０７０４】
ハイブリッドタイムデインターリーバ構造の第２実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。第２実施例に係るハイブリッドタイムデインターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この際、ＰＬＰ＿ＮＵＭ＝１である場合とＰＬＰ＿ＮＵＭ＞１である場合に適用されるコンボリューションデインターリーバの構造及び動作が互いに異なってもよい。
【０７０５】
図４１は本発明の一実施例によるハイブリッド放送受信装置を示した図である。ハイブリッド放送システムは、地上波放送ネットワーク及びインターネットを連動して放送信号を送信することができる。ハイブリッド放送受信装置は地上波放送ネットワーク（ブロードキャスト）及びインターネット（ブロードバンド）を介して放送信号を受信することができる。ハイブリッド放送受信装置はフィジカルレイヤーモジュール、フィジカルレイヤーＩ／Ｆモジュール、サービス／コンテンツ獲得コントローラー、インターネットアクセス制御モジュール、シグナリングデコーダー、サービスシグナリングマネージャー、サービスガイドマネージャー、アプリケーションシグナリングマネージャー、警報信号マネージャー、警報信号パーサー、タゲッティング信号パーサー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネントシンクロナイザー、タゲッティングプロセッサ、アプリケーションプロセッサ、Ａ／Ｖプロセッサ、デバイスマネージャー、データシェアリング及びコミュニケーションユニット、再分配モジュール、コンパニオンデバイス及び／又は外部モジュールを含むことができる。
【０７０６】
フィジカルレイヤーモジュール（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｍｏｄｕｌｅ（ｓ））は地上波放送チャネルを介して放送関連信号を受信及び処理し、これを適切な形態に変換してフィジカルレイヤーＩ／Ｆモジュールに伝達することができる。
【０７０７】
フィジカルレイヤーＩ／Ｆモジュール（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｉ／Ｆ Ｍｏｄｕｌｅ（ｓ））はＰｈｙｓｉｃａｌ ｌａｙｅｒ Ｍｏｄｕｌｅから獲得された情報からＩＰデータグラムを獲得することができる。また、フィジカルレイヤーＩ／Ｆモジュールは獲得されたＩＰデータグラムなどを特定のフレーム（例えばＲＳ Ｆｒａｍｅ、ＧＳＥなど）に変換することができる。
【０７０８】
サービス／コンテンツ獲得コントローラー（Ｓｅｒｖｉｃｅ／Ｃｏｎｔｅｎｔ Ａｃｑｕｉｓｉｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）はｂｒｏａｄｃａｓｔ及び／又はｂｒｏａｄｂａｎｄチャネルを介したサービス、コンテンツ及びこれに係わるシグナリングデータ獲得のための制御動作を遂行することができる。
【０７０９】
インターネットアクセス制御モジュール（Ｉｎｔｅｒｎｅｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ（ｓ））はＢｒｏａｄｂａｎｄチャネルを介してサービス、コンテンツなどを獲得するための受信機の動作を制御することができる。
【０７１０】
シグナリングデコーダー（Ｓｉｇｎａｌｉｎｇ Ｄｅｃｏｄｅｒ）はｂｒｏａｄｃａｓｔチャネルなどを介して獲得したシグナリング情報をデコードすることができる。
【０７１１】
サービスシグナリングマネージャー（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｍａｎａｇｅｒ）はＩＰデータグラムなどからサービススキャン及びサービス／コンテンツなどに係わるシグナリング情報抽出、パーシング及び管理を行うことができる。
【０７１２】
サービスガイドマネージャー（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｍａｎａｇｅｒ）はＩＰデータグラムなどからａｎｎｏｕｎｃｅｍｅｎｔ情報を抽出し、ＳＧ（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ） ｄａｔａｂａｓｅ管理し、Ｓｅｒｖｉｃｅ Ｇｕｉｄｅを提供することができる。
【０７１３】
アプリケーションシグナリングマネージャー（Ａｐｐ Ｓｉｇｎａｌｉｎｇ Ｍａｎａｇｅｒ）はＩＰデータグラムなどからアプリケーション獲得などに係わるシグナリング情報抽出、パーシング及び管理を行うことができる。
【０７１４】
警報信号パーサー（Ａｌｅｒｔ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）はＩＰデータグラムなどからａｌｅｒｔｉｎｇに係わるシグナリング情報抽出、パーシング及び管理を行うことができる。
【０７１５】
タゲッティング信号パーサー（Ｔａｒｇｅｔｉｎｇ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）はＩＰデータグラムなどからサービス／コンテンツ個人化あるいはタゲッティングに係わるシグナリング情報抽出、パーシング及び管理を行うことができる。また、タゲッティング信号パーサーはパーシングされたシグナリング情報をタゲッティングプロセッサに伝達することができる。
【０７１６】
ストリーミングメディアエンジン（Ｓｔｒｅａｍｉｎｇ Ｍｅｄｉａ Ｅｎｇｉｎｅ）はＩＰデータグラムなどからＡ／Ｖストリーミングのためのオーディオ／ビデオデータ抽出及びデコーディングを行うことができる。
【０７１７】
非実時間ファイルプロセッサ（Ｎｏｎ−ｒｅａｌｔｉｍｅ Ｆｉｌｅ Ｐｒｏｃｅｓｓｏｒ）はＩＰデータグラムなどからＮＲＴデータ及びａｐｐｌｉｃａｔｉｏｎなどのファイル形態データ抽出、デコーディング及び管理を行うことができる。
【０７１８】
コンポーネントシンクロナイザー（Ｃｏｍｐｏｎｅｎｔ Ｓｙｎｃｈｒｏｎｉｚｅｒ）はストリーミングオーディオ／ビデオデータ及びＮＲＴデータなどのコンテンツ及びサービスを同期化することができる。
【０７１９】
タゲッティングプロセッサ（Ｔａｒｇｅｔｉｎｇ Ｐｒｏｃｅｓｓｏｒ）はタゲッティング信号パーサーから受信したタゲッティングシグナリングデータに基づいてサービス／コンテンツの個人化関連演算を処理することができる。
【０７２０】
アプリケーションプロセッサ（Ａｐｐ Ｐｒｏｃｅｓｓｏｒ）はａｐｐｌｉｃａｔｉｏｎ関連情報及びダウンロードされたａｐｐｌｉｃａｔｉｏｎ状態を処理し、パラメータを表示することができる。
【０７２１】
Ａ／Ｖプロセッサ（Ａ／Ｖ Ｐｒｏｃｅｓｓｏｒ）はデコードされたａｕｄｉｏ及びｖｉｄｅｏ ｄａｔａ、ａｐｐｌｉｃａｔｉｏｎデータなどに基づいてオーディオ／ビデオレンダリング関連動作を遂行することができる。
【０７２２】
デバイスマネージャー（Ｄｅｖｉｃｅ Ｍａｎａｇｅｒ）は外部装置との連結及びデータ交換動作を遂行することができる。また、デバイスマネージャーは連動可能な外部装置の追加／削除／更新などの外部装置に対する管理動作を遂行することができる。
【０７２３】
データシェアリング及びコミュニケーションユニット（Ｄａｔａ Ｓｈａｒｉｎｇ ＆ Ｃｏｍｍ．）はハイブリッド放送受信機と外部装置間のデータ伝送及び交換についての情報を処理することができる。ここで、伝送及び交換可能なデータはシグナリング、Ａ／Ｖデータなどであり得る。
【０７２４】
再分配モジュール（Ｒｅｄｉｓｔｒｉｂｕｔｉｏｎ Ｍｏｄｕｌｅ（ｓ））は、放送受信機が地上波放送信号を直接受信することができない場合、次世代放送サービス及びコンテンツに対する関連情報を獲得することができる。また、再分配モジュールは、放送受信機が地上波放送信号を直接受信することができない場合、次世代放送システムによる放送サービス及びコンテンツ獲得を支援することができる。
【０７２５】
コンパニオンデバイス（Ｃｏｍｐａｎｉｏｎ ｄｅｖｉｃｅ（ｓ））は本発明の放送受信機に連結され、オーディオ、ビデオ、又はシグナリングデータを共有することができる。コンパニオンデバイスは放送受信機に連結された外部装置であり得る。
【０７２６】
外部モジュール（Ｅｘｔｅｒｎａｌ Ｍａｎａｇｅｍｅｎｔ）は放送サービス／コンテンツ提供のためのモジュールを意味することができ、例えば次世代放送サービス／コンテンツサーバーになることができる。外部モジュールは放送受信機に連結された外部装置であり得る。
【０７２７】
図４２は本発明の一実施例によるハイブリッド放送受信機のブロック図を示した図である。
【０７２８】
ハイブリッド放送受信機は次世代放送システムのＤＴＶサービスで地上波放送とブロードバンドの連動によるハイブリッド放送サービスを受信することができる。ハイブリッド放送受信機は地上波放送を介して伝送される放送オーディオ／ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ、 Ａ／Ｖ）コンテンツを受信し、これに関連したｅｎｈａｎｃｅｍｅｎｔ ｄａｔａあるいは放送Ａ／Ｖコンテンツの一部をブロードバンドを介して実時間で受信することができる。本明細書で、放送オーディオ／ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ、Ａ／Ｖ）コンテンツはメディアコンテンツを意味することができる。
【０７２９】
ハイブリッド放送受信機は物理階層コントローラー（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｃｏｎｔｒｏｌｌｅｒ、Ｄ５５０１０）、チューナー（Ｔｕｎｅｒ、Ｄ５５０２０）、物理的フレームパーサー（Ｐｈｙｓｉｃａｌ Ｆｒａｍｅ Ｐａｒｓｅｒ、Ｄ５５０３０）、連結階層パーサー（Ｌｉｎｋ Ｌａｙｅｒ Ｆｒａｍｅ Ｐａｒｓｅｒ、Ｄ５５０４０）、ＩＰ／ＵＤＰデータグラムフィルター（ＩＰ／ＵＤＰ Ｄａｔａｇｒａｍ Ｆｉｌｔｅｒ、Ｄ５５０５０）、ＡＴＳＣ３．０デジタルテレビコントロールエンジン（ＡＴＳＣ３．０ ＤＴＶ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ、Ｄ５５０６０）、ＡＬＣ／ＬＣＴ＋クライアント（ＡＬＣ／ＬＣＴ＋Ｃｌｉｅｎｔ、Ｄ５５０７０）、タイミング制御部（Ｔｉｍｉｎｇ Ｃｏｎｔｒｏｌ、Ｄ５５０８０）、シグナリングパーサー（Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ、Ｄ５５０９０）、ＤＡＳＨクライアント（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ Ｃｌｉｅｎｔ、ＤＡＳＨ Ｃｌｉｅｎｔ、Ｄ５５１００）、ＨＴＴＰ接続クライアント（ＨＴＴＰ Ａｃｃｅｓｓ Ｃｌｉｅｎｔ、Ｄ５５１１０）、ＩＳＯＢＭＦＦパーサー（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ Ｐａｒｓｅｒ、ＩＳＯ ＢＭＦＦ Ｐａｒｓｅｒ、Ｄ５５１２０）及び／又はメディアデコーダー（Ｍｅｄｉａ Ｄｅｃｏｄｅｒ、Ｄ５５１３０）を含むことができる。
【０７３０】
物理階層コントローラー（Ｄ５５０１０）はハイブリッド放送受信機が受信しようとする地上波放送チャネルのラジオ周波数（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ、ＲＦ）情報などを用いてチューナー（Ｄ５５０２０）、物理的フレームパーサー（Ｄ５５０３０）などの動作を制御することができる。
【０７３１】
チューナー（Ｄ５５０２０）は地上波放送チャネルを介して放送関連信号を受信及び処理し、これを適切な形態に変換することができる。例えば、チューナー（Ｄ５５０２０）は受信された地上波放送信号を物理的フレーム（Ｐｈｙｓｉｃａｌ Ｆｒａｍｅ）に変換することができる。
【０７３２】
物理的フレームパーサー（Ｄ５５０３０）は受信された物理的フレームをパーシングし、これに係わるプロセッシングによって連結階層フレーム（Ｌｉｎｋ Ｌａｙｅｒ Ｆｒａｍｅ）を獲得することができる。
【０７３３】
連結階層パーサー（Ｄ５５０４０）は連結階層フレームから連結階層シグナリング（Ｌｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）などを獲得するか、ＩＰ／ＵＤＰデータグラムを獲得するための関連演算を遂行することができる。連結階層パーサー（Ｄ５５０４０）は少なくとも一つのＩＰ／ＵＤＰデータグラムを出力することができる。
【０７３４】
ＩＰ／ＵＤＰデータグラムフィルター（Ｄ５５０５０）は受信された少なくとも一つのＩＰ／ＵＤＰデータグラムから特定のＩＰ／ＵＤＰデータグラムをフィルタリングすることができる。すなわち、ＩＰ／ＵＤＰデータグラムフィルター（Ｄ５５０５０）は連結階層パーサー（Ｄ５５０４０）から出力された少なくとも一つのＩＰ／ＵＤＰデータグラムの中でＡＴＳＣ３．０デジタルテレビコントロールエンジン（Ｄ５５０６０）によって選択されたＩＰ／ＵＤＰデータグラムを選択的にフィルタリングすることができる。ＩＰ／ＵＤＰデータグラムフィルター（Ｄ５５０５０）はＡＬＣ／ＬＣＴ＋などのアプリケーション階層伝送プロトコルパケットを出力することができる。
【０７３５】
ＡＴＳＣ３．０デジタルテレビコントロールエンジン（Ｄ５５０６０）は各ハイブリッド放送受信機に含まれたモジュール間のインターフェースを担当することができる。また、ＡＴＳＣ３．０デジタルテレビコントロールエンジン（Ｄ５５０６０）は各モジュールに必要なパラメータなどを各モジュールに伝達し、これによって各モジュールの動作を制御することができる。本発明で、ＡＴＳＣ３．０デジタルテレビコントロールエンジン（Ｄ５５０６０）はメディアプレゼンテーションディスクリプション（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ、ＭＰＤ）及び／又はＭＰＤ ＵＲＬをＤＡＳＨクライアント（Ｄ５５１００）に伝達することができる。また、本発明で、ＡＴＳＣ３．０デジタルテレビコントロールエンジン（Ｄ５５０６０）は伝送モード（Ｄｅｌｉｖｅｒｙ ｍｏｄｅ）及び／又は伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ、ＴＳＩ）をＡＬＣ／ＬＣＴ＋クライアント（Ｄ５５０７０）に伝達することができる。ここで、ＴＳＩはＭＰＤ又はＭＰＤ ＵＲＬ関連シグナリングなどのシグナリングメッセージを含む伝送パケットを伝送するセッション、例えばアプリケーション階層伝送プロトコルであるＡＬＣ／ＬＣＴ＋セッション又はＦＬＵＴＥセッションの識別子を示すことができる。また、伝送セッション識別子はＭＭＴのＡｓｓｅｔｉｄに対応することができる。
【０７３６】
ＡＬＣ／ＬＣＴ＋クライアント（Ｄ５５０７０）はＡＬＣ／ＬＣＴ＋などのアプリケーション階層伝送プロトコルパケットを処理し、複数のパケットを収集及び処理して一つ以上のＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（ＩＳＯＢＭＦＦ）オブジェクトを生成することができる。アプリケーション階層伝送プロトコルパケットには、ＡＬＣ／ＬＣＴパケット、ＡＬＣ／ＬＣＴ＋パケット、ＲＯＵＴＥパケット、及び／又はＭＭＴＰパケットが含まれることができる。
【０７３７】
タイミング制御部（Ｄ５５０８０）はシステムタイム情報を含むパケットを処理し、これによってシステムクロックを制御することができる。
【０７３８】
シグナリングパーサー（Ｄ５５０９０）はＤＴＶ放送サービス関連シグナリングを獲得及びパーシングし、パーシングされたシグナリングに基づいてチャネルマップなどを生成して管理することができる。本発明で、シグナリングパーサーはシグナリング情報から拡張されたＭＰＤ又はＭＰＤ関連情報などをパーシングすることができる。
【０７３９】
ＤＡＳＨクライアント（Ｄ５５１００）は実時間ストリーミング（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ）あるいは適応的ストリーミング（Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ）に係わる演算を遂行することができる。ＤＡＳＨクライアント（Ｄ５５１００）はＨＴＴＰ接続クライアント（Ｄ５５１１０）を介してＨＴＴＰサーバーからＤＡＳＨコンテンツを受信することができる。ＤＡＳＨクライアント（Ｄ５５１００）は受信されたＤＡＳＨ Ｓｅｇｍｅｎｔなどを処理してＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔオブジェクトを出力することができる。本発明で、ＤＡＳＨクライアント（Ｄ５５１００）はＡＴＳＣ３．０デジタルテレビコントロールエンジン（Ｄ５５０６０）に全体Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ＩＤ（Ｆｕｌｌｙ ｑｕａｌｉｆｉｅｄ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ＩＤ）又はセグメントＵＲＬを伝達することができる。ここで、全体Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ＩＤは、例えば、ＭＰＤ ＵＲＬ、ｐｅｒｉｏｄ＠ｉｄ及びｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄを結合したＩＤを意味することができる。また、ＤＡＳＨクライアント（Ｄ５５１００）はＡＴＳＣ３．０デジタルテレビコントロールエンジン（Ｄ５５０６０）からＭＰＤ又はＭＰＤ ＵＲＬを受信することができる。ＤＡＳＨクライアント（Ｄ５５１００）は受信されたＭＰＤ又はＭＰＤ ＵＲＬを用いて所望のメディアストリーム又はＤＡＳＨ ＳｅｇｍｅｎｔをＨＴＴＰサーバーから受信することができる。本明細書で、ＤＡＳＨクライアント（Ｄ５５１００）はプロセッサを意味することができる。
【０７４０】
ＨＴＴＰ接続クライアント（Ｄ５５１１０）はＨＴＴＰサーバーに対して特定の情報を要求し、ＨＴＴＰサーバーからこれに対する応答を受信して処理することができる。ここで、ＨＴＴＰサーバーはＨＴＴＰ接続クライアントから受信した要求を処理し、これに対する応答を提供することができる。
【０７４１】
ＩＳＯＢＭＦＦパーサー（Ｄ５５１２０）はＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔオブジェクトからオーディオ／ビデオのデータを抽出することができる。
【０７４２】
メディアデコーダー（Ｄ５５１３０）は受信されたオーディオ及び／又はビデオデータをデコードし、デコードされたオーディオ／ビデオデータをプレゼンテーションするためのプロセッシングを遂行することができる。
【０７４３】
本発明のハイブリッド放送受信機が地上波放送ネットワークとブロードバンドの連動によるハイブリッド放送サービスを提供するためには、ＭＰＤに対する拡張又は修正が要求される。前述した地上波放送システムは拡張又は修正されたＭＰＤを送信することができ、ハイブリッド放送受信機は拡張又は修正されたＭＰＤを用いて放送又はブロードバンドを介してコンテンツを受信することができる。すなわち、ハイブリッド放送受信機は拡張又は修正されたＭＰＤは地上波放送を介して受信し、ＭＰＤに基づいて地上波放送又はブロードバンドを介してコンテンツを受信することができる。以下では既存ＭＰＤと比較して拡張又は修正されたＭＰＤにさらに含まれなければならないエレメント及び属性（ａｔｔｒｉｂｕｔｅ）について記述する。以下で、拡張又は修正されたＭＰＤはＭＰＤとして記述されることができる。
【０７４４】
ＭＰＤはＡＴＳＣ３．０サービスを表現するために拡張されるか修正されることができる。拡張又は修正されたＭＰＤはＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ、Ｃｏｍｍｏｎ＠ｐｒｅｓｅｎｔａｂｌｅ、Ｃｏｍｍｏｎ．Ｔａｒｇｅｔｉｎｇ、 Ｃｏｍｍｏｎ．ＴａｒｇｅｔＤｅｖｉｃｅ及び／又はＣｏｍｍｏｎ＠ａｓｓｏｃｉａｔｅｄＴｏをさらに含むことができる。
【０７４５】
ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅはＭＰＤに含まれたセグメントのプレゼンテーションタイムのアンカー、すなわち基礎となる時間を示すことができる。以下で、ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅはＭＰＤの有効時間（ｅｆｆｅｃｔｉｖｅ ｔｉｍｅ）として使われることができる。ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅはＭＰＤに含まれたセグメントの中で一番早い再生時点を示すことができる。
【０７４６】
ＭＰＤは共通属性及び要素（ｃｏｍｍｏｎ ａｔｔｒｉｂｕｔｅｓ ａｎｄ ｅｌｅｍｅｎｔｓ）をさらに含むことができる。共通属性及び要素はＭＰＤ内のＡｄａｐｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎなどに適用されることができる。Ｃｏｍｍｏｎ＠ｐｒｅｓｅｎｔａｂｌｅはＭＰＤが記述しているメディアがプレゼンテーション可能なコンポーネントであることをを示すことができる。
【０７４７】
Ｃｏｍｍｏｎ．ＴａｒｇｅｔｉｎｇはＭＰＤが記述しているメディアのタゲッティング特徴（ｔａｒｇｅｔｉｎｇ ｐｒｏｐｅｒｔｉｅｓ）及び／又は個別化特徴（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ ｐｒｏｐｅｒｔｉｅｓ）を示すことができる。
【０７４８】
Ｃｏｍｍｏｎ．ＴａｒｇｅｔＤｅｖｉｃｅはＭＰＤが記述しているメディアのターゲットデバイス又はターゲットデバイスを示すことができる。
【０７４９】
Ｃｏｍｍｏｎ＠ａｓｓｏｃｉａｔｅｄＴｏはＭＰＤが記述しているメディアに係わるａｄａｐｔａｔｉｏｎＳｅｔ及び／又はｒｅｐｒｅｓｅｎｔａｔｉｏｎを示すことができる。
【０７５０】
また、ＭＰＤに含まれたＭＰＤ＠ｉｄ、Ｐｅｒｉｏｄ＠ｉｄ及びＡｄａｐｔａｔｉｏｎＳｅｔ＠ｉｄはＭＰＤが記述しているメディアコンテンツを特定するために要求されることができる。すなわち、ＤＡＳＨクライアントはＭＰＤに基づいて受信しようとするコンテンツをＭＰＤ＠ｉｄ、Ｐｅｒｉｏｄ＠ｉｄ及びＡｄａｐｔａｔｉｏｎＳｅｔ＠ｉｄに特定してＡＴＳＣ３．０デジタルテレビコントロールエンジンに伝達することができる。また、ＡＴＳＣ３．０デジタルテレビコントロールエンジンは該当のコンテンツを受信してＤＡＳＨクライアントに伝達することができる。
【０７５１】
図４３は本発明の一実施例による次世代ハイブリッド放送システムのプロトコルスタックを示す。図示のように、ＩＰに基づくハイブリッド放送を支援する次世代放送送信システムは放送サービスのオーディオあるいはビデオデータなどをＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（以下、ＩＳＯＢＭＦＦ）にカプセル化することができる。ここで、カプセル化はＤＡＳＨ ＳｅｇｍｅｎｔあるいはＭＭＴのＭＰＵ（Ｍｅｄｉａ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）などの形態を用いることができる。また、次世代放送システムはカプセル化されたデータを放送ネットワークとインターネットに同等にあるいは各伝送ネットワークの属性によって互いに異なるように伝送することができる。また、次世代放送システムはカプセル化されたデータをブロードキャスト又はブロードバンドの少なくとも一つを用いて伝送することができる。ブロードキャストを用いる放送ネットワークである場合、放送システムはＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ（以下、ＩＳＯＢＭＦＦ）の形態にカプセル化されたデータを実時間オブジェクト伝送を支援するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔプロトコルパケットを介して伝送することができる。例えば、放送システムはＲｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）又はＭＭＴＰのｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔなどでカプセル化することができる。そして、放送システムはカプセル化されたデータをまたＩＰ／ＵＤＰデータグラムに生成した後、これを放送信号に含めて伝送することができる。ブロードバンドを用いる場合、放送システムはカプセル化されたデータをＤＡＳＨなどのストリーミング技法などに基づいて受信側に伝達することができる。
【０７５２】
また、放送システムは放送サービスのシグナリング情報を次のような方法で伝送することができる。ブロードキャストを用いる放送ネットワークである場合、放送システムはシグナリングの属性などによって次世代放送伝送システム及び放送ネットワークのｐｈｙｓｉｃａｌ ｌａｙｅｒを介してシグナリング情報を伝送することができる。ここで、放送システムは放送信号内に含まれたｔｒａｎｓｐｏｒｔ ｆｒａｍｅの特定のｄａｔａ ｐｉｐｅ（以下、ＤＰ）などを介してシグナリング情報を伝送することができる。ブロードキャストを介して伝送されるシグナリング形態はビットストリーム又はＩＰ／ＵＤＰデータグラムにカプセル化された形態であり得る。ブロードバンドを用いる場合、放送システムは受信機の要求に対する応答としてシグナリングデータをリターンして伝達することができる。
【０７５３】
また、放送システムは放送サービスのＥＳＧあるいはＮＲＴコンテンツなどを次のような方法で伝送することができる。ブロードキャストを用いる放送ネットワークである場合、放送システムはａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔプロトコルパケット、例えばＲｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）、ＭＭＴＰのｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔなどでＥＳＧあるいはＮＲＴコンテンツをカプセル化することができる。そして、カプセル化されたＥＳＧあるいはＮＲＴコンテンツをまたＩＰ／ＵＤＰデータグラムに生成した後、これを放送信号に含めて伝送することができる。ブロードバンドを用いる場合、放送システムは受信機の要求に対する応答としてＥＳＧあるいはＮＲＴコンテンツなどをリターンして伝達することができる。
【０７５４】
図４４は本発明の一実施例による次世代放送伝送システムのｐｈｙｓｉｃａｌ ｌａｙｅｒに伝達される伝送フレームの構造を示す。次世代放送システムはブロードキャストを用いて伝送フレームを伝送することができる。図面で、伝送フレームの前部に位置するＰ１はｔｒａｎｓｐｏｒｔ ｓｉｇｎａｌ ｄｅｔｅｃｔｉｏｎのための情報が含まれたシンボルを意味することができる。Ｐ１はｔｕｎｉｎｇ ｉｎｆｏｒｍａｔｉｏｎを含むことができ、受信機はＰ１シンボルに含まれたｐａｒａｍｅｔｅｒに基づいてＰ１の次に位置するＬ１パートをデコードすることができる。放送システムはＬ１パートにｔｒａｎｓｐｏｒｔ ｆｒａｍｅ構成及び各ＤＰ（ｄａｔａ ｐｉｐｅ）の特性などについての情報を含ませることができる。すなわち、受信機はＬ１パートをデコードしてｔｒａｎｓｐｏｒｔ ｆｒａｍｅ構成及び各ＤＰ（ｄａｔａ ｐｉｐｅ）の特性などについての情報を得ることができる。また、受信機はＣｏｍｍｏｎ ＤＰを介してＤＰ間の共有すべき情報を獲得することができる。実施例によって、Ｔｒａｎｓｐｏｒｔ ｆｒａｍｅはＣｏｍｍｏｎ ＤＰを含まないこともできる。
【０７５５】
伝送フレームで、Ａｕｄｉｏ、Ｖｉｄｅｏ、ＤａｔａなどのコンポーネントはＤＰ１〜ｎで構成されたｉｎｔｅｒｌｅａｖｅｄ ＤＰ領域に含まれて伝送される。ここで、それぞれのサービス（チャネル）を構成するコンポーネントがそれぞれどのＤＰに伝送されるかはＬ１あるいはｃｏｍｍｏｎ ＰＬＰなどを介してシグナリングされることができる。
【０７５６】
また、次世代放送システムは伝送フレームに含まれたサービスについての情報を速かに獲得するための情報を伝送することができる。すなわち、次世代放送システムは次世代放送受信機がｔｒａｎｓｐｏｒｔ ｆｒａｍｅに含まれた放送サービス及びコンテンツ関連情報を速かに獲得するようにすることができる。また、当該ｆｒａｍｅ内で一つ以上の放送局で生成し出したサービス／コンテンツが存在する場合、受信機が放送局によるサービス／コンテンツを効率的に認知するようにすることができる。すなわち、次世代放送システムは伝送フレーム内に含まれたサービスに対するサービスリスト情報を伝送フレームに含ませて伝送することができる。
【０７５７】
放送システムは受信機が該当の周波数内の放送サービス及びコンテンツスキャンを迅速に行えるようにするために、別個のチャネル、例えばＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）などが存在する場合、これを介して放送サービス関連情報を伝送することができる。図４４の中間に示したように、放送システムはＴｒａｎｓｐｏｒｔ ｆｒａｍｅに放送サービススキャン及び獲得のための情報を含ませて伝送することができる。ここで、放送サービスに対するスキャン及び獲得についての情報を含む領域をＦＩＣと言うことができる。受信機はＦＩＣを介して一つ以上の放送局で生成及び伝送される放送サービスについての情報を獲得することができ、これによって受信機上で利用可能な放送サービスに対するスキャンを手軽くて早く遂行することができる。
【０７５８】
また、伝送フレームに含まれた特定のＤＰは該当のｔｒａｎｓｐｏｒｔ ｆｒａｍｅ内で伝送される放送サービス及びコンテンツに対するシグナリングを迅速で堅固に伝送することができるＢａｓｅ ＤＰとして動作することができる。Ｐｈｙｓｉｃａｌ ｌａｙｅｒのｔｒａｎｓｐｏｒｔ ｆｒａｍｅの各ＤＰを介して伝送されるデータは図４４の下端のようであり得る。すなわち、Ｌｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇあるいはＩＰデータグラムなどは特定の形態のＧｅｎｅｒｉｃ ｐａｃｋｅｔにカプセル化された後、ＤＰを介して伝送されることができる。ここで、ＩＰデータグラムはシグナリングデータを含むことができる。ここで、Ｌｉｎｋ（ｌｏｗ） ｌａｙｅｒ ｓｉｇｎａｌｉｎｇはｆａｓｔ ｓｅｒｖｉｃｅ ｓｃａｎ／ａｃｑｕｉｓｉｔｉｏｎ、 ＩＰ ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎのｃｏｎｔｅｘｔ ｉｎｆｏｒｍａｔｉｏｎ、ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔに係わるシグナリングなどを含むことができる。
【０７５９】
図４５は本発明の一実施例によるアプリケーション階層伝送プロトコルの伝送パケットを示した図である。アプリケーション階層伝送セッションはＩＰアドレス及びポート番号の組合せでなることができる。アプリケーション階層伝送プロトコルがＲｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）である場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）セッションで構成されることができる。例えば、一つのＬＣＴ伝送セッションを介して一つのメディアコンポーネント（例えば、ＤＡＳＨ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎなど）を伝達する場合、一つのアプリケーション伝送セッションを介して一つ以上のメディアコンポーネントをｍｕｌｔｉｐｌｅｘｉｎｇして伝送することができる。さらに、一つのＬＣＴ伝送セッションを介して一つ以上の伝送オブジェクト（Ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ）を伝達することができ、各伝送オブジェクトは伝送セッションを介して伝達されるＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎに関連したＤＡＳＨ Ｓｅｇｍｅｎｔとなることができる。
【０７６０】
例えば、アプリケーション階層伝送プロトコルがＬＣＴに基づく場合、次のように伝送パケットが構成されることができる。伝送パケットは、ＬＣＴヘッダー、ＲＯＵＴＥヘッダー及びペイロードデータを含むことができ、伝送パケットに含まれた複数のフィールドは次のようであり得る。
【０７６１】
ＬＣＴヘッダーは次のようなフィールドを含むことができる。Ｖ（ｖｅｒｓｉｏｎ）フィールドは該当の伝送プロトコルパケットのバージョン情報を示すことができる。Ｃフィールドは以下に説明するＣｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎフィールドの長さに関連したｆｌａｇを示すことができる。ＰＳＩフィールドはｐｒｏｔｏｃｏｌ−ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎであって、該当のプロトコルに特化した情報を示すことができる。Ｓフィールドはｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ（ＴＳＩ）フィールドの長さに関連したｆｌａｇを示すことができる。Ｏフィールドはｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）フィールドの長さに関連したｆｌａｇを示すことができる。ＨフィールドはＴＳＩ、ＴＯＩフィールドの長さにｈａｌｆ−ｗｏｒｄ（１６ｂｉｔｓ）を付け加えることができるかを表現することができる。Ａ（Ｃｌｏｓｅ Ｓｅｓｓｉｏｎ ｆｌａｇ）フィールドはセッションが終了するかあるいは終了が切迫したことを表現することができる。Ｂ（Ｃｌｏｓｅ Ｏｂｊｅｃｔ ｆｌａｇ）フィールドは伝送中のオブジェクトが終了するかあるいは終了が切迫したことを表現することができる。Ｃｏｄｅ ｐｏｉｎｔフィールドは該当のパケットのペイロードをエンコードあるいはデコードすることについての情報を示すことができる。例えば、ペイロードタイプなどがこれにあたることができる。Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎフィールドはｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌに関連した情報を含むことができる。例えば、ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌに関連した情報はＣｕｒｒｅｎｔ ｔｉｍｅ ｓｌｏｔ ｉｎｄｅｘ（ＣＴＳＩ）、ｃｈａｎｎｅｌ ｎｕｍｂｅｒ、又は該当のチャネル内のｐａｃｋｅｔ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒなどであり得る。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒフィールドは伝送セッションの識別子を示すことができる。Ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒフィールドは伝送セッションを介して伝送されるオブジェクトの識別子を示すことができる。
【０７６２】
ＲＯＵＴＥ（ＡＬＣ）ＨｅａｄｅｒはＦｏｒｗａｒｄ Ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ ｓｃｈｅｍｅなどに関連したペイロード識別子などの先立ったＬＣＴヘッダーの追加情報伝送を含むことができる。
【０７６３】
Ｐａｙｌｏａｄ ｄａｔａは該当のパケットのペイロードの実質的なデータ部分を示すことができる。
【０７６４】
図４６は本発明の一実施例による次世代放送システムがシグナリングデータを伝送する方法を示す。次世代放送システムのシグナリングデータは図示のように伝送されることができる。受信機が迅速なサービス／コンテンツスキャン及び獲得を支援するために次世代放送送信システムは該当のｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅによって伝達される放送サービスに対するシグナリングデータをＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（以下、ＦＩＣ）などを介して伝達することができる。本明細書で、ＦＩＣはサービスリストについての情報を意味することができる。別個のＦＩＣが存在しない場合、Ｌｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇが伝達される経路を介して伝達されることができる。すなわち、サービス及びサービス内のコンポーネント（オーディオ、ビデオなど）についての情報などを含むシグナリング情報はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内の一つ以上のＤＰを介してＩＰ／ＵＤＰデータグラムにカプセル化されて伝送されることができる。実施例によって、サービス及びサービスコンポーネントについてのシグナリング情報はａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔパケット（例えば。ＲＯＵＴＥパケット又はＭＭＴＰパケットなど）にカプセル化されて伝送されることができる。
【０７６５】
図４６の上端は前述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／獲得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどについての詳細な情報を含むシグナリングデータがＩＰデータグラムにカプセル化され、特定のＤＰを介して伝達されることができる。本明細書で、サービスなどについての詳細な情報を含むシグナリングデータはサービスレイヤーシグナリングと言える。
【０７６６】
図４６の中間は前述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／獲得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどについての詳細な情報を含むシグナリングデータがＩＰデータグラムにカプセル化され、特定のＤＰを介して伝達されることができる。また、サービスに含まれた特定のコンポーネントなどについての情報などを含むシグナリングデータの一部がアプリケーションレイヤー伝送プロトコル内の一つ以上の伝送セッションを介して伝達されることもできる。例えば、シグナリングデータの一部はＲＯＵＴＥセッション内の一つ以上の伝送セッションを介して伝達されることもできる。
【０７６７】
図４６の下端は前述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／獲得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどについての詳細な情報を含むシグナリングデータはＲＯＵＴＥセッション内の一つ以上の伝送セッションを介して伝達されることができる。
【０７６８】
図４７は本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。本明細書は、次世代放送受信装置が放送サービスをスキャンして獲得するためのシグナリング情報を提案する。次世代放送システムでは、特定の周波数内に一つ以上の放送局で生成し出した放送サービス及びコンテンツが伝送されることができる。受信機は該当の周波数内に存在する放送局及び該当の放送局のサービス／コンテンツを迅速で容易にスキャンするために前述したシグナリング情報を用いることができる。これは図示のようなｓｙｎｔａｘで示すことができ、これはＸＭＬなどの他のフォーマットで示すことができる。
【０７６９】
迅速なサービススキャン及び獲得のためのシグナリング情報はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ内の別個のチャネルであるＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）に伝達されることができる。また、前述したシグナリング情報はＰｈｙｓｉｃａｌ ｌａｙｅｒのｄａｔａ ｐｉｐｅ間の共有可能な情報を伝達することができるＣｏｍｍｏｎ ＤＰなどを介して伝達されることもできる。また、ｌｉｎｋ ｌａｙｅｒのシグナリングが伝達される経路を介して伝達されることもできる。また、前述したシグナリング情報はＩＰデータグラムにカプセル化され、特定のＤＰを介して伝達されることができる。また、前述したシグナリング情報はサービスシグナリングが伝達されるｓｅｒｖｉｃｅ ｓｉｇｎａｌｉｎｇ ｃｈａｎｎｅｌあるいはａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒのｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎなどを介して伝達されることもできる。
【０７７０】
迅速なサービススキャン及び獲得のためのシグナリング情報（ＦＩＣ情報）は次のようなフィールドの少なくとも一つを含むことができる。本明細書で、ＦＩＣ情報はサービス獲得情報と言える。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはシグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ ｏｆ ｓｔｒｕｃｔｕｒｅ ｏｆ ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ ｏｆ ｏｖｅｒａｌｌ ｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは該当のＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ ｄａｔａ ｖｅｒｓｉｏｎ ｏｆ ｔｈｉｓ ＦＩＣ ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣの内容に変更がある場合に増加することができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはブロードキャストストリームのパーティション数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが使われるために、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送されることができることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは一つのブロードキャスターによって使用されたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは前述したパーティション構造のバージョンを示すことができる。ｂａｓｅ＿ＤＰ＿ＩＤフィールドは該当のパーティションのベースＤＰに対する識別子を示すことができる。ベースＤＰはサービスシグナリングテーブルを含むことができる。サービスシグナリングテーブルは該当のパーティション内の全てのサービスに対するリストを含むことができる。すなわち、サービスシグナリングテーブルは伝送されるサービスをリスティングすることができる。また、各サービスに対する基本属性を定義することができる。ベースＤＰは該当のパーティション内で堅固なＤＰであってもよく、該当のパーティションに対する他のシグナリングテーブルを含むこともできる。ｂａｓｅ＿ＤＰ＿ｖｅｒｓｉｏｎフィールドは該当のベースＤＰを介して伝送されるデータの変化を示すバージョン情報を示すことができる。例えば、ベースＤＰを介してサービスシグナリングなどが伝達される場合、サービスシグナリングの変化が発生すればｂａｓｅ＿ＤＰ＿ｖｅｒｓｉｏｎフィールドは１ずつ増加することができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティションに属する少なくとも一つのコンポーネントの数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスに対する識別子を示すことができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは該当のサービスに関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは該当のサービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは該当のサービスを示す名前の長さを示すことが���きる。ｓｈｏｒｔ＿Ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは該当のサービスを示す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは該当のサービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドはＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」 ｆｌａｇと類似した属性を有することができる。例えば、該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドはサービス保護フラグ（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ ｆｌａｇ）であって、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるかを示すことができる。
【０７７１】
図４８は本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント獲得を支援するためのＦＩＣ情報（サービス獲得情報）はサービス及びコンポーネントデータを伝達するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎについての情報を含むことができる。図示のように、ＦＩＣ情報はバイナリフォーマットで表現できるが、実施例によってＸＭＬなどの他のフォーマットで表現できる。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはシグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ ｏｆ ｓｔｒｕｃｔｕｒｅ ｏｆ ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ ｏｆ ｏｖｅｒａｌｌ ｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは該当のＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ ｄａｔａ ｖｅｒｓｉｏｎ ｏｆ ｔｈｉｓ ＦＩＣ ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣの内容に変更がある場合に増加することができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはブロードキャストストリームのパーティション数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが使われるために、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送されることができることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは一つのブロードキャスターによって使用されたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは前述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティションに属する少なくとも一つのコンポーネントの数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣ内のｓｅｒｖｉｃｅ ｌｏｏｐデータの変化あるいは該当のサービスに関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは含まれたサービスデータに変化が発生する都度、１ずつ増加することができる。受信機はｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化あるいは該当のサービスに係わるシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは該当のサービスに関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは該当のサービスのカテゴリーを示すことができ、例えばＡ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは該当のサービスを示す名前の長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは該当のサービスを示す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは該当のサービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドはＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」 ｆｌａｇと類似した属性を有することができる。例えば、該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドはサービス保護フラグ（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ ｆｌａｇ）であって、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるかを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰアドレス形式を示すことができる。該当のフィールド値が０である場合はＩＰｖ４形式を、１である場合はＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むかを示すことができる。該当のフィールド値が１である場合はｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは放送ストリーム内で該当のサービスのコンポーネントデータを伝送するｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ（例えば、ＲＯＵＴＥ又はＭＭＴＰ ｓｅｓｓｉｏｎ）の数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合に該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは伝送セッションの詳細情報を含むシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ここで、伝送セッションの詳細情報を含むシグナリングは、例えば、ＲＯＵＴＥである場合、各ＲＯＵＴＥセッションの詳細ＬＣＴ伝送セッションについての情報を含むＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎなどであり得る。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは伝送セッションがサービスシグナリングを伝送するかを示すことができる。ｓｅ��ｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、該当の伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰ ｓｅｓｓｉｏｎ）を介して伝送されるデータがサービスシグナリングを含んでいることを示すことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する数のｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。Ｐａｒｔｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはパーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送社などによって用いられる放送ストリームの一部を示すことができる。ＦＩＣ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはＦＩＣレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。実施例によって前述したＦＩＣに含まれた各フィールドはＦＩＣ以外の他のテーブルに含まれて放送信号と一緒に伝送されることもできる。
【０７７２】
図４９は本発明の一実施例によるＦＩＣに基づくシグナリングを伝送する方法を示す。前述したＦＩＣに基づくシグナリングが伝達される実施例は以下の図のようであり得る。本明細書で、ＦＩＣに基づくシグナリングはサービス獲得情報又はサービス獲得シグナリングと言える。図示のように、フィジカルレイヤーシグナリングはサービス獲得情報に対するフィールドを含むことができる。サービス獲得情報に対するフィールドはサービス獲得情報（ＦＩＣ）のパーシング可否を受信機に知らせることができる。受信機はサービス獲得情報をパーシングし、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報によってサービスシグナリングのデータが変更されたかを確認することができる。サービスシグナリングデータが変更された場合、放送信号受信機はＬＳＩＤ＿ＤＰフィールドを用いて、伝送セッションの詳細情報を含むシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を確認することができる。放送受信機は該当のＤＰ識別子が指示するＤＰをパーシングして伝送セッションの詳細情報を確認することができる。すなわち、次世代放送システムのシグナリング方法は、フィジカルレイヤーシグナリングがサービス獲得情報のパーシング可否をシグナリングし、サービス獲得情報が伝送セッションの詳細情報の位置をシグナリングして伝送セッションの詳細情報を確認する手順を含むことができる。ここで、伝送セッションの詳細情報は、ＭＰＤ伝送テーブル、アプリケーションシグナリングテーブル、伝送セッションディスクリプタ（ＬＳＩＤ）及び／又はコンポーネントマッピングテーブル（ＣＭＴ）を含むことができる。
【０７７３】
図５０は本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント獲得を支援するためのＦＩＣ情報（サービス獲得情報）はサービス及びコンポーネントデータを伝達するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎについての情報を含むことができる。図示のように、ＦＩＣ情報はバイナリフォーマットで表現できるが、実施例によってＸＭＬなどの他のフォーマットで表現できる。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはシグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ ｏｆ ｓｔｒｕｃｔｕｒｅ ｏｆ ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ ｏｆ ｏｖｅｒａｌｌ ｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは該当のＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ ｄａｔａ ｖｅｒｓｉｏｎ ｏｆ ｔｈｉｓ ＦＩＣ ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣの内容に変更がある場合に増加することができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはブロードキャストストリームのパーティション数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが使われるために、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送されることができることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは一つのブロードキャスターによって使用されたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは前述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティションに属する少なくとも一つのコンポーネントの数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣ内のｓｅｒｖｉｃｅ ｌｏｏｐデータの変化あるいは該当のサービスに関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは含まれたサービスデータに変化が発生する都度、１ずつ増加することができる。受信機はｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて、ＦＩＣのサービスループのデータ変化あるいは該当のサービスに係わるシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは該当のサービスに関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは該当のサービスのカテゴリーを示すことができ、例えばＡ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは該当のサービスを示す名前の長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは該当のサービスを示す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは該当のサービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドはＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」 ｆｌａｇと類似した属性を有することができる。例えば、該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドはサービス保護フラグ（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ ｆｌａｇ）であって、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるかを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰアドレス形式を示すことができる。該当のフィールド値が０である場合はＩＰｖ４形式を、１である場合はＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むかを示すことができる。該当のフィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは放送ストリーム内で該当のサービスのコンポーネントデータを伝送するｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ（例えば、ＲＯＵＴＥ又はＭＭＴＰ ｓｅｓｓｉｏｎ）の数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは伝送セッションの詳細情報を含むシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ここで、伝送セッションの詳細情報を含むシグナリングは、例えば、ＲＯＵＴＥである場合、各ＲＯＵＴＥセッションの詳細ＬＣＴ伝送セッションについての情報を含むＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎなどであり得る。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは伝送セッションがサービスシグナリングを伝送するかを示すことができる。ｓ��ｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはは関連のサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する都度、該当のフィールドは１ずつ増加することができる。受信機はｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて、該当のサービスに係わるシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドはサービスシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する数のｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。Ｐａｒｔｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはパーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送社などによって使われる放送ストリームの一部を示すことができる。ＦＩＣ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはＦＩＣレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。実施例によって、前述したＦＩＣに含まれた各フィールドはＦＩＣ以外の他のテーブルに含まれて放送信号と一緒に伝送されることもできる。
【０７７４】
図５１は本発明の他の実施例によるＦＩＣに基づくシグナリングを伝送する方法を示す。前述したＦＩＣに基づくシグナリングが伝達される実施例は以下の図のようであり得る。本明細書で、ＦＩＣに基づくシグナリングはサービス獲得情報又はサービス獲得シグナリングと言える。図示のように、フィジカルレイヤーシグナリングはサービス獲得情報に対するフィールドを含むことができる。サービス獲得情報に対するフィールドはサービス獲得情報（ＦＩＣ）のパーシング可否を受信機に知らせることができる。受信機はサービス獲得情報をパーシングし、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報によってサービスシグナリングのデータが変更されたかを確認することができる。サービスシグナリングデータが変更された場合、放送信号受信機はＬＳＩＤ＿ＤＰフィールドを用いて、伝送セッションについての詳細な情報を含んでいるＬＳＩＤあるいはＬＳＩＤ ｔａｂｌｅなどをＬＳＩＤ＿ＤＰフィールドから識別したＤＰを介して獲得することができる。また、受信機はｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ、ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｉｇｎａｌｉｎｇ＿ＤＰなどの情報を用いてシグナリングデータの変化などを認知し、識別されたＤＰを介してシグナリングデータを獲得することができる。
【０７７５】
すなわち、次世代放送システムのシグナリング方法は、フィジカルレイヤーシグナリングがサービス獲得情報のパーシング可否をシグナリングし、サービス獲得情報が伝送セッションの詳細情報の位置をシグナリングして伝送セッションの詳細情報を確認する手順を含むことができる。ここで、伝送セッションの詳細情報は、ＭＰＤ伝送テーブル、アプリケーションシグナリングテーブル、伝送セッションディスクリプタ（ＬＳＩＤ）及び／又はコンポーネントマッピングテーブル（ＣＭＴ）を含むことができ、伝送セッションに対する各詳細情報は互いに異なる例によって伝達されることができる。
【０７７６】
図５２は本発明の一実施例による次世代放送システムのサービスシグナリングメッセージフォーマットを示した図である。本明細書で、サービスシグナリングメッセージはサービスなどについての詳細な情報を含むシグナリングデータ又はサービスレイヤーシグナリングと言える。サービスシグナリングメッセージはｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒとｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含む構造であり得る。ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはｂｉｎａｒｙあるいはＸＭＬフォーマットなどで表現できる。これは、ＩＰデータグラムあるいはａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔパケット（例えば、ＲＯＵＴＥあるいはＭＭＴＰなど）のペイロードに含まれて伝送されることができる。Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒのｓｙｎｔａｘはつぎのようであってもよく、これはＸＭＬなどの他のフォーマットで表されることができる。Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは次のフィールドを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドはｓｉｇｎａｌｉｎｇメッセージの識別子を示すことができる。例えば、シグナリングメッセージがｓｅｃｔｉｏｎ形態に表される場合、ｓｉｇｎａｌｉｎｇ ｔａｂｌｅ ｓｅｃｔｉｏｎのｉｄを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈフィールドは含まれているｓｉｇｎａｌｉｎｇメッセージの長さを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドはｓｉｇｎａｌｉｎｇメッセージに対する識別子の拡張情報を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドはｓｉｇｎａｌｉｎｇ＿ｉｄフィールドとともにシグナリングを識別する情報として使うことができる。例えば、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドはｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅのプロトコルバージョンなどを含むことができる。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドはｓｉｇｎａｌｉｎｇメッセージのバージョン情報を示すことができる。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは該当のシグナリングメッセージが含む内容が変更する場合に変更されることができる。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは含まれているｓｉｇｎａｌｉｎｇメッセージが現在利用可能であるかを示すことができる。このフィールドの値が‘１’である場合、現在含まれているｓｉｇｎａｌｉｎｇメッセージが現在利用可能であることを示すことができる。このフィールドの値が‘０’である場合、現在ｓｉｇｎａｌｉｎｇメッセージが利用できなく、後に同一のｓｉｇｎａｌｉｎｇ＿ｉｄ、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ、あるいはｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒを含むｓｉｇｎａｌｉｎｇメッセージが利用可能であることを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒフィールドは該当のｓｉｇｎａｌｉｎｇメッセージがｆｒａｇｍｅｎｔａｔｉｏｎされたかを示すことができる。このフィールドの値が‘１’である場合、該当のメッセージがｆｒａｇｍｅｎｔａｔｉｏｎされたことを示し、この場合、ｓｉｇｎａｌｉｎｇ＿ｍｅｓｓａｇｅ＿ｄａｔａ（）にシグナリングデー��の一部が含まれたことを示すことができる。このフィールドの値が‘０’である場合、ｓｉｇｎａｌｉｎｇ＿ｍｅｓｓａｇｅ＿ｄａｔａ（）に全てのシグナリングデータが含まれていることを示すことができる。ｐａｙｌｏａｄ＿ｆｏｒｍａｔ＿ｉｎｄｉｃａｔｏｒフィールドは現在ｓｉｇｎａｌｉｎｇメッセージヘッダー部分にｐａｙｌｏａｄ＿ｆｏｒｍａｔ値が含まれているかを示すことができる。このフィールドの値が‘１’である場合、ｓｉｇｎａｌｉｎｇメッセージヘッダー部分にｐａｙｌｏａｄ＿ｆｏｒｍａｔ値が含まれていることを示すことができる。ｅｘｐｉｒａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒフィールドは現在ｓｉｇｎａｌｉｎｇメッセージヘッダー部分にｅｘｐｉｒａｔｉｏｎ値を含んでいるかを示すことができる。このフィールドの値が‘１’である場合、ｓｉｇｎａｌｉｎｇメッセージヘッダー部分にｅｘｐｉｒａｔｉｏｎ値が含まれていることを示すことができる。ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは一つのｓｉｇｎａｌｉｎｇメッセージが多数のｆｒａｇｍｅｎｔに分けられて伝送される場合、現在ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅのｆｒａｇｍｅｎｔナンバーを示すことができる。ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは一つのｓｉｇｎａｌｉｎｇメッセージが多数のｆｒａｇｍｅｎｔに分けられて伝送される場合、該当のｓｉｇｎａｌｉｎｇメッセージの最後のデータを含むｆｒａｇｍｅｎｔのナンバーを示すことができる。ｐａｙｌｏａｄ＿ｆｏｒｍａｔフィールドはペイロードに含まれるシグナリングメッセージデータのフォーマットを示すことができる。実施例において、ｂｉｎａｒｙ、ＸＭＬなどを示すことができる。ｅｘｐｉｒａｔｉｏｎフィールドはペイロードに含まれたシグナリングメッセージの有効時間を示すことができる。
【０７７７】
図５３は本発明の一実施例による次世代放送システムで使用するサービスシグナリングテーブルを示す。本発明は次世代放送ネットワークで使用可能なサービスシグナリングテーブル／メッセージなどは次のようであってもよく、以下のような情報などを含んでシグナリングすることができる。各テーブル／メッセージに含まれた情報は相異なるテーブルに分けられて個別的に伝送されることができ、図示の実施例に限定されない。また、実施例によって互いに異なるテーブルに属するシグナリング情報は一つのテーブルに併合されて伝送されることもできる。Ｓｅｒｖｉｃｅ ｍａｐｐｉｎｇ ｔａｂｌｅはサービスの属性及びサービスに関連した情報を含むことができる。サービスの属性情報は、例えばアイディー、名前、カテゴリーなどの情報を含むことができ、サービスに関連した情報はサービスを獲得することができる経路情報などを含むことができる。ＭＰＤ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅはサービス／コンテンツに関連したＤＡＳＨ ＭＰＤを含むかＤＡＳＨ ＭＰＤを獲得することができる経路情報などを含むことができる。Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅはサービス内コンポーネント情報及びコンポーネントに関連した情報を含むことができる。コンポーネント情報は関連のＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ情報などを含むことができ、コンポーネント関連した情報はコンポーネントを獲得することができる経路情報などを含むことができる。ＬＳＩＤ ｔａｂｌｅはサービス／コンポーネントなどを伝達する伝送セッション及び伝送パケットの構成などについての情報を含むことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅはサービス内コンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎに対するＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ情報あるいはこれを獲得することができる経路などについての情報を含むことができる。Ａｐｐｌｉｃａｔｉｏｎ ｐａｒａｍｅｔｅｒ ｔａｂｌｅは放送サービスに関連したアプリケーションの詳細情報及びこれを獲得することができる経路などの関連情報を含むことができる。このようなシグナリングメッセージ／テーブルなどが放送ネットワークを介して伝送される場合、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）あるいはＳＳＣ（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌ）、あるいはａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ（例えば、ＲＯＵＴＥ又はＭＭＴＰ ｓｅｓｓｉｏｎ）などを介して伝送されることができる。また、インターネット（ブロードバンド）を介して伝送されることができる。
【０７７８】
図５４は本発明の一実施例による次世代放送システムで使われるサービスマッピングテーブルを示した図である。以下に説明する内容はシグナリングメッセージヘッダーの後に位置するサービスシグナリングメッセージ部分に含まれて伝送されることができる。
【０７７９】
サービスマッピングテーブルはサービスマッピングシグナリングについての情報を含むことができ、ＸＭＬ形態又はｂｉｎａｒｙ形態などで表現できる。サービスシグナリングの一つのサービスマッピングテーブルはサービス識別子（ｉｄ）、サービスタイプ、サービスネーム、チャネルナンバー、ＲＯＵＴＥセッション関連情報、ＭＰＤ関連情報、コンポーネントシグナリング位置情報を含むことができる。サービス識別子はサービスを識別する情報を示すことができ、ｉｄ属性で表現できる。サービスタイプ情報はサービスのタイプを示す情報であってもよく、ｓｅｒｖｉｃｅＴｙｐｅ属性で表現できる。サービスネーム情報はサービスの名前を示す情報であってもよく、ｓｅｒｖｉｃｅＮａｍｅ属性で表現できる。チャネルナンバー情報はサービスに係わるチャネルナンバーを示す情報であってもよく、ｃｈａｎｎｅｌＮｕｍｂｅｒ属性で表現できる。
【０７８０】
ＲＯＵＴＥセッション関連情報はｓｏｕｒｃｅＩＰ属性、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ属性、ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性を含むことができる。ｓｏｕｒｃｅＩＰ属性は関連データを含むＩＰデータグラムのソースアドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎ ＩＰ属性は関連データを含むＩＰデータグラムの目的地アドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は関連データを含むＩＰデータグラムの目的地ポートナンバーを示すことができる。
【０７８１】
また、ＲＯＵＴＥセッション関連情報は伝送セッションの詳細情報（ＬＳＩＤ）を含むことができ、例えば、各ＬＳＩＤ位置情報及び各ＬＳＩＤ位置情報のデリバリーモード情報を含むことができる。また、伝送セッションの詳細情報（ＬＳＩＤ）はブートストラップ情報を含むことができる。ＬＳＩＤに含まれたブートストラップ情報はデリバリーモードによるＬＳＩＤのブートストラップ情報を含むことができる。ブートストラップ情報に含まれた属性は以下に詳細に説明する。
【０７８２】
ＭＰＤ関連情報はＭＰＤ又はＭＰＤシグナリングロケーションについての情報を含むことができる。ＭＰＤについての情報はバージョン属性を含むことができ、ＭＰＤのバージョンを示すことができる。ＭＰＤシグナリングロケーション情報はＭＰＤ又はＭＰＤ ＵＲＬに係わるシグナリングを獲得することができる位置を示すことができる。ＭＰＤシグナリングロケーションに含まれたデリバリーモード情報は、ＭＰＤロケーションの際、グナリングのデリバリーモードを示すことができる。ＭＰＤシグナリングロケーションに含まれたブートストラップ情報はデリバリーモードによるＭＰＤ又はＭＰＤ ＵＲＬのブートストラップ情報を含むことができる。
【０７８３】
コンポーネントシグナリングロケーション関連情報はデリバリーモード属性を含むことができる。デリバリーモード属性は該当のコンポーネントシグナリングロケーション情報のデリバリーモードを示すことができる。ＭＰＤシグナリングロケーションに含まれたブートストラップインポ情報は、デリバリーモードによる該当のコンポーネントロケーションの際、シグナリングのブートストラップ情報を含むことができる。
【０７８４】
ブートストラップ情報はデリバリーモードによって次のような属性の少なくとも一つを含むことができる。
【０７８５】
ｓｏｕｒｃｅＩＰ属性は関連データを含むＩＰデータグラムのソースアドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎ ＩＰ属性は関連データを含むＩＰデータグラムの目的地アドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は関連データを含むＩＰデータグラムの目的地ポートナンバーを示すことができる。ｔｓｉ属性は関連データを含む伝送パケット（ｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔｓ）を伝達する伝送セッションに対する識別子を示すことができる。ＵＲＬ属性は関連データを獲得することができるＵＲＬを示すことができる。ｐａｃｋｅｔｉｄは関連データを含む伝送パケット（ｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔｓ）の識別子を示すことができる。
【０７８６】
図５５は本発明の一実施例による次世代放送システムのサービスシグナリングテーブルを示す。次世代放送システムで受信機が放送サービス及びコンテンツを受信することができるようにするために、放送サービスシグナリングを提供することができる。これは、シグナリングデータが同じ伝送セッション識別子（ＴＳＩ）を介して伝送される場合、受信機が関連シグナリングを獲得することができるようにする。サービスシグナリングテーブルは図示のようにバイナリフォーマットで表現されることができ、実施例によってＸＭＬなどの他の形態に表現できる。また、サービスシグナリングテーブルは前述したシグナリングメッセージフォーマットでカプセル化されることができる。サービスシグナリングテーブルは次のようなフィールドを含むことができる。ＳＳＴ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはサービスシグナリングテーブルのバージョンを示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ＳＳＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは該当のサービスシグナリングテーブルのデータバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティション内に含まれた少なくとも一つ以上のサービスの数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは該当のサービスの識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは該当のサービスの名前を示すことができる。ＭＰＤ＿ａｖａｉｌａｂｉｌｉｔｙフィールドはブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＭＰＤを獲得することができるかを示すことができる。ＣＭＴ＿ａｖａｉｌａｂｉｌｉｔｙフィールドはブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ（ＣＭＴ）を用いることができるかを示すことができる。ＡＳＬ＿ａｖａｉｌａｂｉｌｉｔｙフィールドはブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＡｐｐｌｉｃａｔｉｏｎ Ｓｉｇｎａｌｉｎｇ Ｔａｂｌｅ（ＡＳＴ）を用いることができるかを示すことができる。ＤＰ＿ＩＤフィールドはＭＰＤ、ＣＭＴ及び／又はＡＳＬをブロードキャストを介して伝達するＤＰの識別子を示すことができる。ＬＣＴ＿ＩＰ＿ａｄｄｒｅｓｓフィールドはＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルのＩＰアドレスを示すことができる。ＬＣＴ＿ＵＤＰ＿ｐｏｒｔフィールドはＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルのＵＤＰポートを示すことができる。ＬＣＴ＿ＴＳＩフィールドはＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネル伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ、ＴＳＩ）を示すことができる。ＭＰＤ＿ＴＯＩフィールドは、ＭＰＤがブロードキャストを介して伝達される場合、ＭＰＤの伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ）を示すことができる。ＣＭＴ ＴＯＩフィールドは、ＣＭＴがブロードキャストを介して伝達される場合、ＣＭＴの伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ）を示すことができる。ＡＳＴ＿ＴＯＩフィールドは、ＡＳＴがブロードキャストを介して伝達される場合、ＡＳＴの伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ）を示すことができる。ＭＰＤ＿ＵＲＬフィールドはブロードバンドを介してＭＰＤを獲得することができるＵＲＬ情報を示すことができる。ＣＭＴ＿ＵＲＬフィールドはブロードバンドを介してＣＭＴを獲得することができるＵＲＬ情報を示すことができる。ＡＳＴ＿ＵＲＬブロードバンドを介してＡＳＴを獲得することができるＵＲＬ情報を示すことができる。
【０７８７】
図５６は本発明の一実施例による次世代放送システムで使われるコンポーネントマッピングテーブルを示した図である。以下に説明する内容はシグナリングメッセージヘッダーの後に位置するサービスシグナリングメッセージ部分に含まれて伝送されることができる。コンポーネントマッピングテーブルはコンポーネントマッピングシグナリングについての情報を含むことができ、ＸＭＬ形態又はｂｉｎａｒｙ形態などで表現できる。サービスシグナリングの一つのコンポーネントマッピングテーブルは次のようなフィールドを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは該当のテーブルがＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅであることを示す識別子を含むことができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ ｓｙｎｔａｘなどのＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎフィールドはＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄフィールドは該当のコンポーネントに関連したサービスに対する識別子を示すことができる。Ｎｕｍ＿ｃｏｍｐｏｎｅｎｔフィールドは該当のサービスが含むコンポーネントの数を示すことができる。Ｍｐｄ＿ｉｄフィールドはコンポーネントに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。Ｐｅｒｉｏｄ＿ｉｄフィールドはコンポーネントに関連したＤＡＳＨ ｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ｉｄフィールドはコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。Ｓｏｕｒｃｅ＿ＩＰフィールドは該当のコンポーネントデータを含むＩＰ／ＵＤＰデータグラムのｓｏｕｒｃｅＩＰアドレスを示すことができる。Ｄｅｓｔ＿ＩＰフィールドは該当のコンポーネントデータを含むＩＰ／ＵＤＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスを示すことができる。ｐｏｒｔフィールドは該当のコンポーネントデータを含むＩＰ／ＵＤＰデータグラムのＰｏｒｔナンバーを示すことができる。ｔｓｉフィールドは該当のコンポーネントデータを含むａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎの識別子を示すことができる。ＤＰ＿ｉｄフィールドは該当のコンポーネントデータを伝送するｐｈｙｓｉｃａｌ ｌａｙｅｒ ｄａｔａ ｐｉｐｅの識別子を示すことができる。このような情報によって、ＣＭＴは各サービスに関連したコンポーネントを定義し、該当のコンポーネントを受信することができる位置又は経路を受信機に知らせることができる。
【０７８８】
図５７は本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ）は次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路についての情報をシグナリングすることができる。これはＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどで表現できる。コンポーネントマッピングテーブルディスクリプションは次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性はコンポーネントに関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＢｒｏａｄｃａｓｔＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連ｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。
【０７８９】
ＢＢＣｏｍｐはｂｒｏａｄｂａｎｄネットワークを介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＢＢＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連ｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。
【０７９０】
ＦｏｒｅｉｇｎＣｏｍｐは他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＦｏｒｅｉｇｎＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連ｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は該当のコンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｓｏｕｒｃｅＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎは一つのＸＭＬファイルあるいは先立って提案したシグナリングメッセージフォーマットでカプセル化されて伝送されることができる。図５７の下端に示したように、Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは前述した形態によることができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎあるいはその一部が含まれることができる。このような情報によって、ＣＭＴは各サービスに関連したコンポーネントを定義し、該当のコンポーネントについての情報を受信することができる位置又は経路を受信機に知らせることができる。
【０７９１】
図５８は本発明の一実施例による次世代放送システムのコンポーネントマッピングテーブルのシンタックスを示す。次世代放送システムは、受信機が放送サービスのコンポーネントを獲得することができるように、コンポーネントマッピングテーブル（ＣＭＴ）をシグナリングすることができる。これはｂｉｎａｒｙ又はＸＭＬなどの他の形態に表現されることができ、前述したシグナリングメッセージフォーマットでカプセル化されることができる。コンポーネントマッピングテーブルは次のようなフィールドを含むことができる。ＣＭＴ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはＣｏｍｐｏｎｅｎｔ Ｍａｐｐｉｎｇ Ｔａｂｅ（ＣＭＴ）の構造（ｓｔｒｕｃｔｕｒｅ）のバージョンを示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは該当のＣＭＴが提供するコンポーネント位置に係わるサービスの識別子を示すことができる。ＣＭＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは該当のＣＭＴのデータバージョンを示すことができる。ｎｕｍ＿ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍｓフィールドは該当のサービスに関連した少なくとも一つのコンポーネントを含むブロードキャストストリームの数を示すことができる。ＴＳＩＤフィールドは該当のブロードキャストストリームの伝送セッション識別子を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは該当のサービスに係わる少なくとも一つのコンポーネントを含むブロードキャストストリームのパーティション数を示すことができる。ＣＭＴは複数のパーティションを含むことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ｎｕｍ＿ｄａｔａ＿ｐｉｐｅｓフィールドは該当のサービスに係わる少なくとも一つのコンポーネントを含むパーティション内のデータパイプの数を示すことができる。ＤＰ＿ＩＤフィールドは各データパイプの識別子を示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓフィールドは各データパイプに含まれた伝送セッション（例えば、ＲＯＵＴＥセッション）の数を示すことができる。各データパイプは該当のサービスに係わる少なくとも一つのコンポーネントを含むことができる。ＩＰ＿ａｄｄｒｅｓｓフィールドは各伝送セッションのＩＰアドレスを示すことができる。ＵＤＰ＿ｐｏｒｔフィールドは各伝送セッションのＵＤ Ｐｐｏｒｔを示すことができる。ｎｕｍ＿ＬＣＴ＿ｃｈａｎｎｅｌｓフィールドは該当のサービスに係わるコンポーネントを含む伝送セッション内のＬＣＴチャネル数を示すことができる。ＬＣＴ＿ＴＳＩフィールドは伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ、ＴＳＩ）を示すことができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤフィールドは該当のＬＣＴチャネルを介して運ばれるＲｅｐｒｅｓｅｎｔａｔｉｏｎの識別子を示すことができる。Ｉｎｔｅｒｎｅｔ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは該当のＲｅｐｒｅｓｅｎｔａｔｉｏｎがインターネット又はブロードバンドを介しても受信されることができるかを示した識別子であり得る。ｎｕｍ＿ｉｎｔｅｒｎｅｔ＿ｏｎｌｙ＿ｒｅｐｔｎｓフィールドはインターネット又はブロードバンドを介して受信することができるＲｅ���ｒｅｓｅｎｔａｔｉｏｎの数を示すことができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤフィールドはｎｕｍ＿ｉｎｔｅｒｎｅｔ＿ｏｎｌｙ＿ｒｅｐｔｎｓのｌｏｏｐ内で、インターネット又はブロードバンドを介して受信することができるＲｅｐｒｅｓｅｎｔａｔｉｏｎの識別子を示すことができる。このような情報によって、ＣＭＴは各サービスに関連したコンポーネントを定義し、該当のコンポーネントを受信することができる位置又は経路を受信機に知らせることができる。
【０７９２】
図５９は本発明の一実施例による次世代放送システムで各サービスに関連したシグナリングをブロードバンドネットワークを介して伝達する方法を示す。次世代放送システムはサービスに関連したシグナリングをｂｒｏａｄｂａｎｄネットワークなどを介して受信機に伝達することができる。次世代放送システムはＵＲＬ Ｓｉｇｎａｌｉｎｇ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎを用いてｂｒｏａｄｂａｎｄネットワークなどを介してシグナリングを受信機に伝達することができる。これはＸＭＬ又はｂｉｎａｒｙなどの他の形態に表されることができる。ＵＲＬ Ｓｉｇｎａｌｉｎｇ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎは次のような属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性はシグナリングに関連したサービスの識別子を示すことができる。ＭＰＤ ＵＲＬ属性はブロードバンドＭＰＤのＵＲＬを示すことができる。ｃｓｔＵＲＬ属性はブロードバンドＣＭＴのＵＲＬを示すことができる。ＣＭＴは放送サービス内コンポーネントデータ獲得経路についての情報を含むことができる。ａｓｔＵＲＬ属性はブロードバンドＡＳＴのＵＲＬを示すことができる。ＡＳＴは放送サービスに関連したアプリケーションについての情報を含むことができる。受信機はディスクリプションを受信し、各シグナリングに対するＵＲＬに基づいて該当のシグナリングを受信することができる。このＵＲＬ Ｓｉｇｎａｌｉｎｇ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎは一つのＸＭＬファイルあるいは先立って提案したシグナリングメッセージフォーマットでカプセル化されて伝送されることができる。図面の下端に示したように、Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは先立って提案した形態によることができ、ヘッダーの後にＵＲＬ Ｓｉｇｎａｌｉｎｇ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎあるいはその一部が含まれることができる。
【０７９３】
図６０は本発明の一実施例による次世代放送システムでＭＰＤをシグナリングする方案を示す。次世代放送ネットワークで使用可能な放送サービスのＭＰＤのシグナリングメッセージは、図面の上端に示したように、シグナリングメッセージヘッダーとシグナリングメッセージでなることができる。Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは前述した形態によることができ、ＭＰＤ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅ情報は次のような情報を含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ情報は該当のシグナリングメッセージがＭＰＤあるいはＭＰＤを獲得することができる経路情報を含むシグナリングメッセージであることを識別することができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は該当のシグナリングメッセージのｓｙｎｔａｘなどのＭＰＤ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎ情報はＭＰＤ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄ情報は該当のシグナリング情報に関連したサービス識別子を示すことができる。Ｍｐｄ＿ｉｄ情報はシグナリングメッセージに関連したＤＡＳＨ ＭＰＤの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎ情報は該当のＭＰＤの変化などを示すバージョン情報を示すことができる。Ｄｅｌｉｖｅｒｙ＿ｍｏｄｅ情報はシグナリングメッセージが該当のＭＰＤを含んでいるかあるいは他の経路を介して伝達されるかについての情報を示すことができる。ＭＰＤ＿ｄａｔａ（）情報は、該当のシグナリングメッセージがＭＰＤを含む場合、ＭＰＤデータそのものを含むことができる。ＭＰＤ＿ｐａｔｈ情報はＭＰＤを獲得することができる経路についての情報を含むことができる。例えば、経路はＵＲＬなどを示すことができる。
【０７９４】
ＭＰＤ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎは次のような情報を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性はシグナリングに関連したサービスの識別子を示すことができる。ＭＰＤ＿ｉｄ属性はＭＰＤの識別を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎはＭＰＤの変化情報を示すことができるバージョン情報を示すことができる。ＭＰＤ＿ＵＲＬ属性はＭＰＤを獲得することができるＵＲＬ情報を含むことができる。また、ＭＰＤエレメントはＭＰＤ情報を含むことができる。ＭＰＤ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎは一つのＸＭＬファイルあるいは先立って提案したシグナリングメッセージフォーマットでカプセル化されて伝送されることができる。すなわち、Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは先立って提案した形態によることができ、その後にＭＰＤ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎあるいはその一部が含まれることができる。
【０７９５】
図６１は本発明の一実施例による次世代放送システムのＭＰＤデリバリーテーブルのシンタックスを示す。シグナリングメッセージヘッダーの後にはＭＰＤデリバリーテーブルの情報又はその一部が含まれることができ、ＭＰＤデリバリーテーブルの情報は次のようなフィールドを含むことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは関連の放送サービスの識別子を示すことができる。ＭＰＤ＿ｉｄ＿ｌｅｎｇｔｈフィールドは後続のＭＰＤ＿ｉｄ＿ｂｙｔｅｓ（）の長さを示すことができる。ＭＰＤ＿ｉｄ＿ｂｙｔｅｓフィールドはｓｉｇｎａｌｉｎｇメッセージに含まれるＭＰＤファイルの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎフィールドは該当のＭＰＤのデータの変化などのバージョン情報を示すことができる。ＭＰＤ＿ＵＲＬ＿ａｖａｉｌａｂｉｌｔｙフィールドは該当のシグナリングテーブル／メッセージ内にＭＰＤのＵＲＬ情報の存在有無を示すことができる。ＭＰＤ＿ｄａｔａ＿ａｖａｉｌａｂｉｌｔｙフィールドは該当のシグナリングテーブル／メッセージ内にＭＰＤそのものを含むかを示すことができる。該当の値が‘１’である場合、ＭＰＤそのものが該当のシグナリングテーブル／メッセージに含まれることを示すことができる。ＭＰＤ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドは後続のＭＰＤ＿ＵＲＬ＿ｂｙｔｅｓ（）の長さを示すことができる。ＭＰＤ＿ＵＲＬ＿ｂｙｔｅｓフィールドはｓｉｇｎａｌｉｎｇメッセージに含まれるＭＰＤ ＵＲＬを示すことができる。ＭＰＤ＿ｃｏｄｉｎｇフィールドは該当のｓｉｇｎａｌｉｎｇメッセージ内に含むＭＰＤファイルのエンコード方式を示すことができる。図面の下端のように、値によってＭＰＤファイルが互いに異なる形態のエンコード方式でエンコードされたことを示すことができる。例えば、ＭＰＤ＿ｃｏｄｉｎｇフィールドの値が‘０ｘ００’である場合、ＸＭＬで表現されるＭＰＤファイルそのものを含んでいることを示すことができる。また、その値が‘０ｘ０１’である場合、ｇｚｉｐに圧縮されたＭＰＤファイルが含まれていることを示すことができる。例えば、ｇｚｉｐに圧縮されているＭＰＤが複数のメッセージ／テーブルに分けられて伝送される場合、該当の複数のＭＰＤ＿ｂｙｔｅｓ（）をｃｏｎｃａｔｅｎａｔｅした後、ｕｎｇｚｉｐすることができる。ＭＰＤ＿ｂｙｔｅ＿ｌｅｎｇｔｈフィールドは後続のＭＰＤ＿ｂｙｔｅｓ（）の長さを示すことができる。ＭＰＤ＿ｂｙｔｅｓフィールドはＭＰＤ＿ｃｏｄｉｎｇ分野で指示されたエンコード方式によってｓｉｇｎａｌｉｎｇメッセージに含まれるＭＰＤファイルの実際データを含むことができる。次世代放送システムは前述したフィールドを含むＭＰＤデリバリーテーブルを介して受信機がサービスに係わるＭＰＤを受信又は獲得することができるようにする。
【０７９６】
図６２は本発明の一実施例による次世代放送システムの伝送セッションインスタンスディスクリプションを示す。アプリケーションレイヤー伝送方法がＲｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）である場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）セッションで構成されることができる。一つ以上の伝送セッション（Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ）の詳細情報は伝送セッションインスタンスディスクリプションを介してシグナリングされることができる。伝送セッションインスタンスティスクリプタはＲＯＵＴＥである場合にＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）と言える。特に、伝送セッションインスタンスディスクリプションはＲＯＵＴＥセッションを構成する各ＬＣＴ伝送セッションによって何が伝達されるかを定義することができる。各伝送セッションは伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ、ＴＳＩ）によってユニークに識別されることができる。伝送セッション識別子はＬＣＴヘッダーに含まれることができる。伝送セッションインスタンスディスクリプションは該当のセッションを介して伝送される全ての伝送セッションを記述することができる。例えば、ＬＳＩＤはＲＯＵＴＥセッションで運ばれる全てのＬＣＴセッションを記述することができる。伝送セッションインスタンスディスクリプションは伝送セッションと同一であるＲＯＵＴＥセッションを介して伝達されるか、あるいは異なったＲＯＵＴＥセッション又はユニキャストを介して伝達されることもできる。
【０７９７】
同一ＲＯＵＴＥセッションを介して伝達される場合、伝送セッションインスタンスディスクリプションは指定された伝送セッション識別子（ＴＳＩ）０を有する伝送セッションを介して伝達されることができる。伝送セッションインスタンスディスクリプションで参照される他のオブジェクトもＴＳＩ＝０で伝達されることができるが、伝送セッションインスタンスディスクリプションとは違うＴＯＩ値を有することができる。あるいは、ＴＳＩ≠０である分離された伝送セッションを介して伝達されることもできる。伝送セッションインスタンスディスクリプションはバージョンナンバー、有効（ｖａｌｉｄｉｔｙ）情報又は満了（ｅｘｐｉｒａｔｉｏｎ）情報の少なくとも一つを用いてアップデートされることができる。伝送セッションインスタンスディスクリプションは図示の形態以外にｂｉｔｓｔｒｅａｍなどで表されることができる。
【０７９８】
伝送セッションインスタンスディスクリプションは、ｖｅｒｓｉｏｎ属性、ｖａｌｉｄＦｒｏｍ属性、ｅｘｐｉｒａｔｉｏｎ属性を含むことができ、各伝送セッションに対してＴＳＩ属性及びＳｏｕｒｃｅＦｌｏｗ、ＲｅｐａｉｒＦｌｏｗ情報を含むことができる。ｖｅｒｓｉｏｎ属性は該当の伝送セッションインスタンスディスクリプションのバージョン情報を示すことができ、その内容がアップデートされる都度、バージョン情報は増加することができる。最高のバージョンナンバーを有する伝送セッションインスタンスディスクリプションが最近の有効なバージョンであるこをを示すことができる。ｖａｌｉｄＦｒｏｍ属性は該当の伝送セッションインスタンスディスクリプションがいつから有効であるかを示すことができる。ｖａｌｉｄＦｒｏｍ属性は実施例によって伝送セッションインスタンスディスクリプションに含まれないこともできる。この場合、該当の伝送セッションインスタンスディスクリプションは受信即時有効であることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は該当の伝送セッションインスタンスディスクリプションがいつ満了するかを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は実施例によって伝送セッションインスタンスディスクリプションに含まれないこともできる。この場合、該当の伝送セッションインスタンスディスクリプションは継続的に有効なものであることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性を有する伝送セッションインスタンスディスクリプションが受信されれば、該当のｅｘｐｉｒａｔｉｏｎ属性によることができる。ＴＳＩ属性は伝送セッション識別子を示すことができ、ＳｏｕｒｃｅＦｌｏｗエレメントは該当のＴＳＩに伝送されるソースフローの情報を提供し、詳細内容は以下に説明する。ＲｅｐａｉｒＦｌｏｗエレメントは該当のＴＳＩに伝送されるリペアーフローの情報を提供することができる。
【０７９９】
図６３は本発明の一実施例による次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す。ソースフローエレメントはＥＦＤＴエレメント、ｉｄＲｅｆ属性、ｒｅａｌｔｉｍｅ属性、ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性、Ａｐｐｌｉｃａｔｉｏｎ Ｉｄｅｎｄｔｉｆｉｅｒエレメント、ＰａｙｌｏａｄＦｏｒｍａｔエレメントを含むことができる。ＥＦＤＴエレメントはファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴはｅｘｔｅｎｄｅｄ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ（ＦＤＴ） ｉｎｓｔａｎｃｅを示すことができ、詳細な内容は以下に説明する。ｉｄＲｅｆ属性はＥＦＤＴの識別子を示すことができ、対応する伝送セッションによってＵＲＩで表現できる。ｒｅａｌｔｉｍｅ属性は該当のＬＣＴパケット拡張ヘッダー（ｅｘｔｅｎｓｉｏｎ ｈｅａｄｅｒ）を含むことを示すことができる。拡張ヘッダーはデリバリーオブジェクトのプレゼンテーションタイムを示すタイムスタンプを含むことができる。ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性は受信機に保存されるのに必要なデータの最大量を定義することができる。Ａｐｐｌｉｃａｔｉｏｎ Ｉｄｅｎｄｔｉｆｉｅｒエレメントは該当の伝送セッションで運ばれるアプリケーションにマッピングされることができる付加情報を提供することができる。例えば、レンダリングのための伝送セッションを選択するためのＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎ ＩＤ又はＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎのＡｄａｐｔａｔｉｏｎ Ｓｅｔパラメータが付加情報として提供されることができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントはソースフローのオブジェクトを運ぶＲＯＵＴＥパケットのペイロードフォーマットを定義することができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントはＣｏｄｅｐｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。Ｃｏｄｅｐｏｉｎｔ属性は該当のペイロードで使われるコードポイントを定義することができる。これはＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は該当のデリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性はフラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性はオブジェクトのデリバリー手順を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性はｓｏｕｒｃｅ ＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントはＦＥＣパラメータを定義することができる。これはＦＥＣ ｅｎｃｏｄｉｎｇ ｉｄ、ｉｎｓｔａｎｃｅ ｉｄなどを含むことができる。
【０８００】
図６４は本発明の一実施例による次世代放送システムのＥＦＤＴを示す。ＥＦＤＴはファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴはｉｄＲｅｆ属性、バージョン属性、ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ属性、ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ属性、ＦｉｌｅＴｅｍｐｌａｔｅエレメントを含むことができる。ｉｄＲｅｆ属性はＥＦＤＴの識別子を示すことができる。バージョン属性はＥＦＤＴインスタンスディスクリプタのバージョンを示すことができる。この属性はＥＦＤＴがアップデートされる都度、１ずつ増加することができる。受信されたＥＦＤＴの中で最高のバージョンナンバーを有するＥＦＤＴが現在有効なバージョンであることを示すことができる。ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ属性はオブジェクトに関連した一番目パケットを送信した後、該当のオブジェクトの最大有効時間（ｅｘｐｉｒｙ ｔｉｍｅ）を示すことができる。ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ属性は該当のＥＦＤＴによって記述されるオブジェクトの最大伝送サイズを示すことができる。ＦｉｌｅＴｅｍｐｌａｔｅエレメントはボディー部分のｆｉｌｅ ＵＲＬ又はｆｉｌｅテンプレートを詳細化することができる。
【０８０１】
前述した伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）ｅｌｅｍｅｎｔは図面の下端の伝送セッションインスタンスディスクリプタテーブル（ＬＳＩＤ ｔａｂｌｅ）によって伝送されることができる。ＬＳＩＤ ｔａｂｌｅは前述したｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅによって伝達されることができ、これはシグナリングメッセージヘッダーとシグナリングメッセージデータの部分に区分されることができる。シグナリングメッセージデータ部分は伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）又はその一部を含むことができる。シグナリングメッセージデータは伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）Ｔａｂｌｅを含むことができ、次のようなフィールドを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングｔａｂｌｅであることを示す識別子情報を示すことができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングｓｙｎｔａｘなどのシグナリングのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎフィールドは伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングデータの変化などを示すことができる。また、伝送セッションインスタンスディスクリプタテーブルは前述した伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）エレメントの内容をさらに含むことができる。
【０８０２】
図６５は本発明の一実施例による次世代放送システムが使用するＩＳＤＴを伝送する方法を示す。次世代放送システムはＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅ（ＩＳＤＴ）を伝送することにより、放送サービス内のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔのシグナリング情報を伝達することができる。放送サービス内コンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔのシグナリングメッセージはヘッダーとデータを含むことができる。Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは前述した形態によることができ、シグナリングメッセージデータはＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ ｄｅｌｉｖｅｒｙ情報又はその一部を含むことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ ｄｅｌｉｖｅｒｙ情報は次の情報を含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ情報はＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔあるいはその経路情報を含むシグナリングメッセージであることを識別することができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は該当のシグナリングメッセージのｓｙｎｔａｘなどのＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ情報はＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅのインスタンスに対する識別子を示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎ情報はＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄ情報は該当のコンポーネントに関連したサービスを識別することができる。Ｍｐｄ＿ｉｄ情報は該当のコンポーネントに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒｉｏｄ＿ｉｄ情報は該当のコンポーネントに関連したＤＡＳＨ ｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ｉｄ情報は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｖｅｒｓｉｏｎ情報は該当のＭＰＤの変化などを示すバージョン情報であり得る。Ｄｅｌｉｖｅｒｙ＿ｍｏｄｅ情報は該当のＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔを含んでいるか、他の経路を介して伝達されるかなどについての情報を示すことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａ（）情報はＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔデータそのものを含むことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔｐａｔｈ情報はＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔに対するＵＲＬなどのＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔを獲得することができる経路についての情報を含むことができる。このようなＩＳＤＴによって、受信機はコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔについての情報を受信することができる。
【０８０３】
図６６は本発明の一実施例による次世代放送システムのシグナリングメッセージのデリバリー構造を示す。前述したシグナリングデータがａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ、例えば、ＲＯＵＴＥに基づいて伝送される場合、図示のように伝達されることができる。すなわち、迅速なサービスのスキャンなどを支援するために、Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌなどを介して一部のシグナリングを伝達することができる。そして、シグナリングの一部は特定のｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎを介して伝送されることができ、またコンポーネントデータとともに混在されて伝達されることができる。
【０８０４】
迅速なサービスのスキャン及び獲得を支援するためのシグナリング情報は伝送セッションとは別個のチャネルを介して受信されることができる。ここで、別個のチャネルとは別個のデータパイプ（ｄａｔａ ｐｉｐｅ、ＤＰ）を意味することができる。また、サービスの詳細情報は別個の指定された伝送セッションを介して受信されることができる。この際、該当の伝送セッションはＴＳＩ＝０の値を有することができる。ここで、指定された伝送セッションを介して伝達される情報はＭＰＤデリバリーテーブル、アプリケーションシグナリングテーブル、伝送セッションインスタンスディスクリプションテーブル及び／又はコンポーネントマッピングテーブルを含むことができる。また、一部のシグナリング情報はコンポーネントデータとともに伝送セッションを介して伝達されることができ、例えばＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅがコンポーネントデータとともに伝達されることができる。
【０８０５】
図面の下端は次世代放送ネットワークで放送サービスを獲得する実施例を示す。受信機は、サービスが選択されれば、ブロードキャストをチューニングし、速いサービススキャン及び獲得のための情報を獲得し、パーシングすることができる。その後、速いサービススキャン及び獲得のための情報からサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプション（例えば、ＴＳＩＤ、ＬＳＩＤ）の位置が決定されれば、該当のディスクリプションを獲得し、パーシングすることができる。また、受信機はシグナリングを含む伝送セッションを確認し、これからシグナリングテーブルを獲得し、パーシングすることができ、所望のコンポーネントを決定することができる。この過程によって所望のコンポーネントをプレゼンテーションすることができる。すなわち、放送サービスは速いサービススキャン及び獲得のための情報から伝送セッションについての情報を獲得し、伝送セッションについての情報から所望のコンポーネントの位置を確認し、該当のコンポーネントを再生することにより、使用者に提供されることができる。
【０８０６】
図６７は本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント獲得を支援するためのＦＩＣ情報（サービス獲得情報）はサービス及びコンポーネントデータを伝達するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎについての情報を含むことができる。図示のように、ＦＩＣ情報はバイナリフォーマットで表現できるが、実施例によってＸＭＬなどの他のフォーマットで表現できる。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはシグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ ｏｆ ｓｔｒｕｃｔｕｒｅ ｏｆ ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ ｏｆ ｏｖｅｒａｌｌ ｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは該当のＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ ｄａｔａ ｖｅｒｓｉｏｎ ｏｆ ｔｈｉｓ ＦＩＣ ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣの内容に変更がある場合に増加することができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはブロードキャストストリームのパーティション数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが使われるために、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送されることができることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは一つのブロードキャスターによって使用されたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは前述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティションに属する少なくとも一つのコンポーネントの数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣ内のｓｅｒｖｉｃｅ ｌｏｏｐデータの変化あるいは該当のサービスに関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは含まれたサービスデータに変化が発生する都度、１ずつ増加することができる。受信機はｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて、ＦＩＣのサービスループのデータ変化あるいは該当のサービスに係わるシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは該当のサービスに関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは該当のサービスのカテゴリーを示すことができ、例えばＡ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは該当のサービスを示す名前の長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは該当のサービスを示す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは該当のサービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドはＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」 ｆｌａｇと類似した属性を有することができる。例えば、該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドはサービス保護フラグ（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ ｆｌａｇ）であって、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるかを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰアドレス形式を示すことができる。該当のフィールド値が０である場合はＩＰｖ４形式を、１である場合はＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むかを示すことができる。該当のフィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは放送ストリーム内で該当のサービスのコンポーネントデータを伝送するｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ（例えば、ＲＯＵＴＥ又はＭＭＴＰ ｓｅｓｓｉｏｎ）の数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは伝送セッションの詳細情報を含むシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ここで、伝送セッションの詳細情報を含むシグナリングは、例えば、ＲＯＵＴＥである場合、各ＲＯＵＴＥセッションの詳細ＬＣＴ伝送セッションについての情報を含むＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎなどであり得る。ＬＳＩＤ＿ｔｓｉフィールドは伝送セッションの詳細情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝��される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであり得る。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して該当のサービスに関連したサービスシグナリングが伝達されることができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは伝送セッションがサービスシグナリングを伝送するかを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは関連のサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する都度、該当のフィールドは１ずつ増加することができる。受信機はｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて、該当のサービスに係わるシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドはサービスシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｔｓｉフィールドはサービスシグナリングを伝達する伝送セッションの識別子などを示すことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する数のｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。Ｐａｒｔｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはパーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送社などによって使われる放送ストリームの一部を示すことができる。ＦＩＣ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはＦＩＣレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。実施例によって、前述したＦＩＣに含まれた各フィールドはＦＩＣ以外の他のテーブルに含まれて放送信号と一緒に伝送されることもできる。
【０８０７】
図６８は本発明の一実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント獲得を支援するためのＦＩＣ情報（サービス獲得情報）はサービス及びコンポーネントデータを伝達するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎについての情報を含むことができる。図示のように、ＦＩＣ情報はバイナリフォーマットで表現できるが、実施例によって、ＸＭＬなどの他のフォーマットで表現できる。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはシグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ ｏｆ ｓｔｒｕｃｔｕｒｅ ｏｆ ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ ｏｆ ｏｖｅｒａｌｌ ｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ）を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはブロードキャストストリームのパーティション数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが使われるために、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送されることができることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは一つのブロードキャスターによって使用されたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは前述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティションに属する少なくとも一つのサービスの数を示すことができる。各サービスは複数のシグナリングテーブルを含むことができる。例えば、コンポーネントとそのセグメントについての情報を含むＤＡＳＨ ＭＰＤ、ブロードバンド及び他のブロードキャストストリームに含まれたコンポーネントに対する識別子を含むＣＭＴ、アプリケーションシグナリングテーブルであるＡＳＴ及びＭＰＤ、ＣＭＴ、ＡＳＴの少なくとも一つのＵＲＬを含むＵＳＴ（ＵＲＬ ｓｉｇｎａｌｉｎｇ ｔａｂｌｅ）を含むことができる。これらのシグナリングテーブルは該当のサービスのシグナリングチャネルに含まれることができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣ内のｓｅｒｖｉｃｅ ｌｏｏｐデータの変化あるいは該当のサービスに関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する都度、１ずつ増加することができる。例えば、ＦＩＣ、ＭＰＤ、ＣＭＴ、ＡＳＴ又はＵＳＴに変化がある場合に１ずつ増加することができる。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて、ＦＩＣのサービスループのデータ変化あるいは該当のサービスに係わるシグナリングの変化を感知することができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは該当のサービスに関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは該当のサービスのカテゴリーを示すことができ、例えばＡ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは該当のサービスを示す名前の長さを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅフィールドは該当のサービスを示す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは該当のサービスの状態を示すことができ、その値によって、ａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドはＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」 ｆｌａｇと類似した属性を有することができる。例えば、該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドはサービス保護フラグ（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ ｆｌａｇ）であって、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるかを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰアドレス形式を示すことができる。該当のフィールド値が０である場合はＩＰｖ４形式を、１である場合はＩＰｖ６アドレス形式を用いることを示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓはブロードキャストストリーム内で該当のサービスのコンポーネントデータを伝送する伝送セッションの数を示すことができる。例えば、伝送セッションはＲＯＵＴＥセッションであり得る。次の情報は各ＲＯＵＴＥセッションに対して設定されることができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは伝送セッションの詳細情報を含むシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ここで、伝送セッションの詳細情報を含むシグナリングは、例えば、ＲＯＵＴＥである場合、各ＲＯＵＴＥセッションの詳細ＬＣＴ伝送セッションについての情報を含むＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎなどであり得る。ＬＳＩＤ＿ｔｓｉフィールドは���伝送セッションの詳細情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションである場合、ＬＳＩＤであり得る。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して該当のサービスに関連したサービスシグナリングが伝達されることができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは伝送セッションがサービスのコンポーネントシグナリングを伝送するかを示すことができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、該当の伝送セッションを介して伝送されるデータの中でサービスシグナリング（例えば、ＭＰＤ（ＤＡＳＨ Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）、ＣＭＴなど）を含んでいることを示すことができる。ここで、ＣＭＴはＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅであって、ブロードバンドを介して伝達されるコンポーネントの識別子を含むことができ、また他のブロードキャストストリームに含まれたコンポーネントについての情報も含むことができる。各サービスはサービスシグナリングチャネルを含むことができ、サービスシグナリングチャネルはＭＰＤ、ＣＭＴ、ＡＳＴ及び／又はＵＳＴを含むことができる。サービスシグナリングチャネルはサービスのための複数のラウトセッションの一つのシグナリングチャネルであってもよく、存在有無をｃｏｍｐｏｎｅｎｔ ｓｉｇｎａｌｉｎｇ ｆｌａｇを介して表すことができる。複数の伝送セッション（ＲＯＵＴＥ又はＭＭＴＰセッション）がシグナリング及びサービスのコンポーネントを伝送する場合、好ましくは前述したサービスシグナリングテーブルは一つの伝送セッションによって伝達されることができる。
【０８０８】
ＲＯＵＴＥ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する数のｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。Ｐａｒｔｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはパーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送社などによって使われる放送ストリームの一部を示すことができる。ＦＩＣ ｄｅｓｃｒｉｐｔｏｒｓフィールドはＦＩＣレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。
【０８０９】
実施例によって、前述したＦＩＣに含まれた各フィールドはＦＩＣ以外の他のテーブルに含まれて放送信号と一緒に伝送されることもできる。
【０８１０】
図６９は本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ）は次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路についての情報をシグナリングすることができる。これはＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどで表現できる。コンポーネントマッピングテーブルディスクリプションは次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性はコンポーネントに関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＢｒｏａｄｃａｓｔＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。
【０８１１】
ＢＢＣｏｍｐはｂｒｏａｄｂａｎｄネットワークを介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＢＢＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。
【０８１２】
ＦｏｒｅｉｇｎＣｏｍｐは他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＦｏｒｅｉｇｎＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は該当のコンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｓｏｕｒｃｅ ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。前述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性及びｄａｔａｐｉｐｅＩＤ属性は実施例によって選択的な属性であってもよく、ＣＭＴに選択的に含まれることができる。このＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎは一つのＸＭＬファイルあるいは先立って提案したシグナリングメッセージフォーマットでカプセル化されて伝送されることができる。下端に示したように、Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは前述した形態によることができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎあるいはその一部が含まれることができる。このような情報によって、ＣＭＴは各サービスに関連したコンポーネントを定義し、該当のコンポーネントについての情報を受信することができる位置又は経路を受信機に知らせることができる。
【０８１３】
図７０は本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ）は次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路についての情報をシグナリングすることができる。これはＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどで表現できる。コンポーネントマッピングテーブルディスクリプションは次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性はコンポーネントに関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＢｒｏａｄｃａｓｔＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｔｓｉ属性は放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。
【０８１４】
ＢＢＣｏｍｐはｂｒｏａｄｂａｎｄネットワークを介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＢＢＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。
【０８１５】
ＦｏｒｅｉｇｎＣｏｍｐは他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はＦｏｒｅｉｇｎＣｏｍｐに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は該当のコンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｓｏｕｒｃｅ ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。前述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性及びｄａｔａｐｉｐｅＩＤ属性は実施例によって選択的な属性であってもよく、ＣＭＴに選択的に含まれることができる。このＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎは一つのＸＭＬファイルあるいは先立って提案したシグナリングメッセージフォーマットでカプセル化されて伝送されることができる。下端に示したように、Ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒは前述した形態によることができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎあるいはその一部が含まれることができる。このような情報によって、ＣＭＴは各サービスに関連したコンポーネントを定義し、該当のコンポーネントについての情報を受信することができる位置又は経路を受信機に知らせることができる。
【０８１６】
図７１及び図７２は本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ）は次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路についての情報をシグナリングすることができる。これはＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどで表現できる。コンポーネントマッピングテーブルはＤＡＳＨ関連識別子とともに伝送パラメータエレメント（Ｄｅｌｉｖｅｒｙ Ｐａｒａｍｅｔｅｒ ｅｌｅｍｅｎｔ）及びペイロードフォーマットエレメント（ＰａｙｌｏａｄＦｏｒｍａｔ ｅｌｅｍｅｎｔ）を含むことができる。
【０８１７】
コンポーネントマッピングテーブルディスクリプションは次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性はコンポーネントに関連したサービスの識別子を示すことができる。Ｃｏｍｐｏｎｅｎｔエレメントは該当の放送サービス内のコンポーネントを示すことができる。ＣｏｍｐｏｎｅｎｔエレメントはｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ属性、ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメント及び／又はＰａｙｌｏａｄＦｏｒｍａｔエレメントの少なくとも一つを含むことができる。ｍｐｄＩＤ属性はコンポーネントに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。
【０８１８】
ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントは該当のコンポーネントが伝送される経路などの詳細情報を含むことができる。ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントはｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ、ｔｓｉ、ｄａｔａｐｉｐｅＩＤ及び／又はＵＲＬの少なくとも一つを含むことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は該当のコンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｓｏｕｒｃｅＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送されるｐｈｙｓｉｃａｌ ｌａｙｅｒ ｄａｔａ ｐｉｐｅの識別子を示すことができる。ＵＲＬ属性はインターネットなどを介して該当のコンポーネントデータを獲得することができるＵＲＬ情報を示すことができる。前述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性、ｄａｔａｐｉｐｅＩＤ属性及び／又はＵＲＬ属性は実施例によって選択的な属性であってもよく、ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントに選択的に含まれることができる。
【０８１９】
ＰａｙｌｏａｄＦｏｒｍａｔエレメントはＣｏｄｅｐｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。Ｃｏｄｅｐｏｉｎｔ属性は該当のペイロードで使われるコードポイントを定義することができる。これはＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は該当のデリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性はフラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性はオブジェクトのデリバリー手順を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性はｓｏｕｒｃｅ ＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントはＦＥＣパラメータを定義することができる。これはＦＥＣ ｅｎｃｏｄｉｎｇ ｉｄ、ｉｎｓｔａｎｃｅｉｄなどを含むことができる。
【０８２０】
図７３は本発明の一実施例によるコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ）は次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路についての情報をシグナリングすることができる。これはＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどで表現できる。コンポーネントマッピングテーブルディスクリプションはｓｅｒｖｉｃｅ＿ｉｄ属性、ｍｐｄ＿ｉｄ属性、ｐｅｒ＿ｉｄ属性、ＢｒｏａｄｃａｓｔＣｏｍｐエレメント、ＢＢＣｏｍｐエレメント及びＦｏｒｅｉｇｎＣｏｍｐエレメントを含むことができる。コンポーネントマッピングテーブルディスクリプションは次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性はコンポーネントに関連したサービスの識別子を示すことができる。ＣＭＴディスクリプションはｓｅｒｖｉｃｅ＿ｉｄ属性と同一であるレベルにｍｐｄＩＤ属性及びｐｅｒＩＤ属性を含むことができる。すなわち、ＢｒｏａｄｃａｓｔＣｏｍｐエレメント、ＢＢＣｏｍｐエレメント及びＦｏｒｅｉｇｎＣｏｍｐエレメントに共通的に適用されるｍｐｄＩＤ属性及びｐｅｒＩＤ属性を重複して記述せずにｓｅｒｖｉｃｅ＿ｉｄ属性と同一であるレベルで記述することができる。ｍｐｄＩＤ属性は該当のサービスに関連したＤＡＳＨ ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は該当のＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。
【０８２１】
ＢｒｏａｄｃａｓｔＣｏｍｐは同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐはｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｔｓｉ属性は放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。
【０８２２】
ＢＢＣｏｍｐエレメントはｂｒｏａｄｂａｎｄネットワークを介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐはｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬの少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。
【０８２３】
ＦｏｒｅｉｇｎＣｏｍｐは他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐはｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤの少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は該当のコンポーネントに関連したＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するＳｅｇｍｅｎｔのＢａｓｅ ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は該当のコンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｓｏｕｒｃｅ ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は該当のコンポーネントデータを含むＩＰデータグラムのｄｅｓｔｉｎａｔｉｏｎ ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は該当の放送ストリーム内で該当のコンポーネントデータが伝送されるｄａｔａ ｐｉｐｅの識別子を示すことができる。前述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性、ｔｓｉ属性及びｄａｔａｐｉｐｅＩＤ属性は実施例によって選択的な属性であってもよく、ＣＭＴに選択的に含まれることができる。このＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎは一つのＸＭＬファイルあるいは先立って提案したシグナリングメッセージフォーマットでカプセル化されて伝送されることができる。このような情報によって、ＣＭＴは各サービスに関連したコンポーネントを定義し、該当のコンポーネントについての情報を受信することができる位置又は経路を受信機に知らせることができる。
【０８２４】
図７４は本発明の一実施例によるＭＰＤの共通属性及びエレメントを示した図である。次世代放送システムはＤＡＳＨに基づくハイブリッド放送サービスを提供することができる。次世代放送システムはＤＡＳＨ ＭＰＤ内のＲｅｐｒｅｓｅｎｔａｔｉｏｎなどに関連したＳｅｇｍｅｎｔが互いに異なるｄｉｓｔｒｉｂｕｔｉｏｎ経路を介して伝達されることを示すことができる。ＭＰＤの共通属性及びエレメント（Ｃｏｍｍｏｎ ａｔｔｒｉｂｕｔｅｓ ａｎｄ ｅｌｅｍｅｎｔｓ）はａｄａｐｔａｔｉｏｎ ｓｅｔ、ｒｅｐｒｅｓｅｎｔａｔｉｏｎ及びｓｕｂ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎエレメントに共通的に存在することができ、図示のように、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置情報を含むことができる。次世代放送システムはＭＰＤの共通属性及びエレメントに含まれた関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置情報を用いて、ＤＡＳＨ ｃｌｉｅｎｔが関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎ又はセグメントの位置が分かるようにすることができる。ＭＰＤの共通属性及びエレメントは次のような属性及びエレメントを含むことができる。＠ｐｒｏｆｉｌｅｓ属性はプロファイル属性であって、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎのプロファイルを示すことができる。＠ｗｉｄｔｈ属性はディスプレイされるビデオメディアタイプの水平表示大きさ（ｈｏｒｉｚｏｎｔａｌ ｖｉｓｕａｌ ｐｒｅｓｅｎｔａｔｉｏｎ ｓｉｚｅ）を示すことができる。＠ｈｅｉｇｈｔ属性はディスプレイされるビデオメディアタイプの垂直表示大きさ（ｖｅｒｔｉｃａｌ ｖｉｓｕａｌ ｐｒｅｓｅｎｔａｔｉｏｎ ｓｉｚｅ）を示すことができる。＠ｓａｒ属性はビデオメディアコンポーネントタイプのｓａｍｐｌｅ ａｓｐｅｃｔ ｒａｔｉｏを示すことができる。＠ｆｒａｍｅＲａｔｅ属性はｒｅｐｒｅｓｅｎｔａｔｉｏｎの出力フレームレートを示すことができる。＠ａｕｄｉｏＳａｍｐｌｉｎｇＲａｔｅ属性はオーディオメディアコンポーネントタイプのサンプリングレートを示すことができる。＠ｍｉｍｅＴｙｐｅ属性は初期化セグメントのコンケートネーション（ｃｏｎｃａｔｅｎａｔｉｏｎ）のＭＩＭＥタイプを示すことができる。＠ｓｅｇｍｅｎｔＰｒｏｆｉｌｅｓ属性は該当のｒｅｐｒｅｓｅｎｔａｔｉｏｎをプロセスするのに必須なセグメントのプロファイルを示すことができる。＠ｃｏｄｅｃｓ属性は該当のｒｅｐｒｅｓｅｎｔａｔｉｏｎ内で使われるコーデックを示すことができる。＠ｍａｘｉｍｕｍＳＡＰＰｅｒｉｏｄ属性は含まれたメディアストリームの最大ＳＡＰ（ｓｔｒｅａｍ ａｃｃｅｓｓ ｐｏｉｎｔ）インターバルを示すことができる。＠ｓｔａｒｔＷｉｔｈＳＡＰ属性はＳＡＰとともに始まる各メディアセグメントの数を示すことができる。＠ｍａｘＰｌａｙｏｕｔＲａｔｅ属性は最大プレイアウトレートを示すことができる。＠ｃｏｄｉｎｇＤｅｐｅｎｄｅｎｃｙ属性はデコーディングのために一つ又はそれ以上の他のアクセスユニットに依存する少なくとも一つのアクセスユニットが存在するかを示すことができる。＠ｓｃａｎＴｙｐｅ属性はビデオメディアコンポーネントタイプのｓｏｕｒｃｅ ｍａｔｅｒｉａｌのスキャンタイプを示すことができる。ＦｒａｍｅＰａｃｋｉｎｇエ���メントはビデオメディアコンポーネントタイプのフレーム−パッキング情報を示すことができる。ＡｕｄｉｏＣｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎエレメントはオーディオメディアコンポーネントタイプのオーディオチャネル設定を示すことができる。ＣｏｎｔｅｎｔＰｒｏｔｅｃｔｉｏｎエレメントはは関連のｒｅｐｒｅｓｅｎｔａｔｉｏｎに対して使用されたコンテンツ保護スキームについての情報を示すことができる。ＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙエレメントはプロセッシングに必須に考慮されるエレメントについての情報を示すことができる。ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙエレメントはプロセッシングを最適化するために使われる付加情報を含むことができる。ＩｎｂａｎｄＥｖｅｎｔＳｔｒｅａｍエレメントはは関連のｒｅｐｒｅｓｅｎｔａｔｉｏｎにインベンドストリームが存在するかを示すことができる。Ｌｏｃａｔｉｏｎエレメントはは関連のｒｅｐｒｅｓｅｎｔａｔｉｏｎを獲得することができる位置情報を含むことができる。Ｌｏｃａｔｉｏｎエレメントはは関連のｒｅｐｒｅｓｅｎｔａｔｉｏｎを運ぶブロードキャストストリーム又は物理チャネルデータパイプ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｄａｔａ ｐｉｐｅｓ）についての情報を含むことができる。ＤＡＳＨ ｃｌｉｅｎｔ又は次世代放送受信装置はＬｏｃａｔｉｏｎエレメントを用いて関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを獲得することができる。すなわち、次世代放送システム受信装置は前述したＣＭＴを用いなくても、ＭＰＤのＣｏｍｍｏｎ ａｔｔｒｉｂｕｔｅｓ ａｎｄ ｅｌｅｍｅｎｔｓに含まれた位置情報を用いて関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置についての情報を獲得し、これに基づいて関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを獲得することができる。前述したｒｅｐｒｅｓｅｎｔａｔｉｏｎは実施例によってコンポーネントとして説明されることができる。
【０８２５】
また、他の実施例として、次世代放送システムは関連のＲｅｐｒｅｓｅｎｔａｔｉｏｎなどの伝送経路についての情報をＤＡＳＨ ＭＰＤ内のＢａｓｅ ＵＲＬ ｅｌｅｍｅｎｔの＠ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ属性に割り当てることができる。次世代放送システムは＠ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ属性を用いて、ＤＡＳＨ ｃｌｉｅｎｔにとって該当のｒｅｐｒｅｓｅｎｔａｔｉｏｎに関連したＳｅｇｍｅｎｔが伝達される経路についての情報が分かるようにすることができる。
【０８２６】
図７５は本発明の一実施例による伝送セッションインスタンスディスクリプションを示した図である。アプリケーションレイヤー伝送方法がＲｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）である場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）セッションで構成されることができる。一つ以上の伝送セッション（Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ）の詳細情報は伝送セッションインスタンスディスクリプションを介してシグナリングされることができる。伝送セッションインスタンスディスクリプタは、ＲＯＵＴＥである場合、ＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）と言える。特に、伝送セッションインスタンスディスクリプションはＲＯＵＴＥセッションを構成する各ＬＣＴ伝送セッションによって何が伝達されるかを定義することができる。各伝送セッションは伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ、ＴＳＩ）によってユニークに識別されることができる。伝送セッション識別子はＬＣＴヘッダーに含まれることができる。伝送セッションインスタンスディスクリプションは該当のセッションを介して伝送される全ての伝送セッションを記述することができる。例えば、ＬＳＩＤはＲＯＵＴＥセッションで運ばれる全てのＬＣＴセッションを記述することができる。伝送セッションインスタンスディスクリプションは伝送セッションと同一であるＲＯＵＴＥセッションを介して伝達されるか、あるいは異なったＲＯＵＴＥセッション又はユニキャストを介して伝達されることもできる。
【０８２７】
同じＲＯＵＴＥセッションを介して伝達される場合、伝送セッションインスタンスディスクリプションは指定された伝送セッション識別子（ＴＳＩ）０を有する伝送セッションを介して伝達されることができる。伝送セッションインスタンスディスクリプションで参照される他のオブジェクトもＴＳＩ＝０で伝達されることができるが、伝送セッションインスタンスディスクリプションとは違うＴＯＩ値を有することができる。あるいは、ＴＳＩ≠０の分離された伝送セッションを介して伝達されることもできる。伝送セッションインスタンスディスクリプションはバージョンナンバー、有効（ｖａｌｉｄｉｔｙ）情報又は満了（ｅｘｐｉｒａｔｉｏｎ）情報の少なくとも一つを用いてアップデートされることができる。伝送セッションインスタンスディスクリプションは図示の形態以外にｂｉｔｓｔｒｅａｍなどで表されることができる。
【０８２８】
伝送セッションインスタンスディスクリプションは、ｖｅｒｓｉｏｎ属性、ｖａｌｉｄＦｒｏｍ属性、ｅｘｐｉｒａｔｉｏｎ属性を含むことができ、各伝送セッションに対してＴＳＩ属性、ＳｏｕｒｃｅＦｌｏｗエレメント、ＲｅｐａｉｒＦｌｏｗエレメント、及びＴｒａｎｓｐｏｒｔｓｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメントを含むことができる。ｖｅｒｓｉｏｎ属性は該当の伝送セッションインスタンスディスクリプションのバージョン情報を示すことができ、その内容がアップデートされる都度、バージョン情報は増加することができる。最高のバージョンナンバーを有する伝送セッションインスタンスディスクリプションが最近の有効なバージョンであることを示すことができる。ｖａｌｉｄＦｒｏｍ属性は該当の伝送セッションインスタンスディスクリプションがいつから有効であるかを示すことができる。ｖａｌｉｄＦｒｏｍ属性は実施例によって伝送セッションインスタンスディスクリプションに含まれないこともでき、この場合、該当の伝送セッションインスタンスディスクリプションは受信即時有効であることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は該当の伝送セッションインスタンスディスクリプションがいつ満了するかを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は実施例によって伝送セッションインスタンスディスクリプションに含まれないこともでき、この場合、該当の伝送セッションインスタンスディスクリプションは継続的に有効であることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性を有する伝送セッションインスタンスディスクリプションが受信されれば、該当のｅｘｐｉｒａｔｉｏｎ属性によることができる。ＴＳＩ属性は伝送セッション識別子を示すことができ、ＳｏｕｒｃｅＦｌｏｗエレメントは該当のＴＳＩに伝送されるソースフローの情報を提供し、詳細内容は以下に説明する。ＲｅｐａｉｒＦｌｏｗエレメントは該当のＴＳＩに伝送されるリペアーフローの情報を提供することができる。ＴｒａｎｓｐｏｒｔｓｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメントは該当の伝送セッションに対する付加的な属性情報を含むことができる。伝送セッションインスタンスディスクリプションはＴｒａｎｓｐｏｒｔｓｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメント内に伝送セションションに対する付加的な属性情報を含むことができ、例えば、付加情報は伝送セッションに対するサービスシグナリング情報を含むことができる。
【０８２９】
図７６は本発明の一実施例による次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す。ソースフローエレメントはＥＦＤＴエレメント、ｉｄＲｅｆ属性、ｒｅａｌｔｉｍｅ属性、ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｄｔｉｆｉｅｒエレメント、ＰａｙｌｏａｄＦｏｒｍａｔエレメント及び／又はＳｏｕｒｃｅＦｌｏｗＰｒｏｐｅｒｔｙエレメントを含むことができる。ＥＦＤＴエレメントはファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴはｅｘｔｅｎｄｅｄ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ （ＦＤＴ） ｉｎｓｔａｎｃｅを示すことができ、その詳細な内容は以下に説明する。ｉｄＲｅｆ属性はＥＦＤＴの識別子を示すことができ、対応する伝送セッションによってＵＲＩとして表現できる。ｒｅａｌｔｉｍｅ属性は該当のＬＣＴパケット拡張ヘッダー（ｅｘｔｅｎｓｉｏｎ ｈｅａｄｅｒ）を含むことを示すことができる。拡張ヘッダーはデリバリーオブジェクトのプレゼンテーションタイムを示すタイムスタンプを含むことができる。ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性は受信機に保存されるのに必要なデータの最大量を定義することができる。ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｄｔｉｆｉｅｒエレメントは該当の伝送セッションで運ばれるアプリケーションにマッピングされることができる付加情報を提供することができる。例えば、レンダリングのための伝送セッションを選択するためのＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎ ＩＤ又はＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎのＡｄａｐｔａｔｉｏｎ Ｓｅｔパラメータが付加情報として提供されることができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントはソースフローのオブジェクトを運ぶＲＯＵＴＥパケットのペイロードフォーマットを定義することができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントはＣｏｄｅｐｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。Ｃｏｄｅｐｏｉｎｔ属性は該当のペイロードで使われるコードポイントを定義することができる。これはＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は該当のデリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性はフラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性はオブジェクトのデリバリー手順を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性はｓｏｕｒｃｅＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントはＦＥＣパラメータを定義することができる。これはＦＥＣ ｅｎｃｏｄｉｎｇ ｉｄ、ｉｎｓｔａｎｃｅ ｉｄなどを含むことができる。Ｓｏｕｒｃｅ ＦｌｏｗＰｒｏｐｅｒｔｙエレメントは該当のソースフローに対する属性情報を提供することができる。例えば、属性情報は該当のソースフローデータを運ぶブロードキャストの位置情報を含むことができ��。ここで、ブロードキャストの位置情報はブロードキャストストリーム内のデータパイプ又はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｉｐｅ（ＰＬＰ）についての情報を含むことができる。
【０８３０】
図７７は本発明の他の実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。図示のサービス獲得情報は前述したサービス獲得情報に加え、リンクレイヤーシグナリングについての情報をさらに含むことができる。リンクレイヤーシグナリングについての情報はリンクレイヤーシグナリングの存在有無を示すフラグ情報、リンクレイヤーシグナリングデータのバージョン情報及びリンクレイヤーシグナリングが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。迅速な放送サービススキャン及びサービス／コンポーネント獲得を支援するためのＦＩＣ情報（サービス獲得情報）はサービス及びコンポーネントデータを伝達するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎについての情報を含むことができる。図示のように、システム獲得情報はバイナリフォーマットで表現できるが、実施例によってＸＭＬなどの他のフォーマットで表現できる。
【０８３１】
システム獲得情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはシグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ ｏｆ ｓｔｒｕｃｔｕｒｅ ｏｆ ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ ｏｆ ｏｖｅｒａｌｌ ｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは該当のＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ ｄａｔａ ｖｅｒｓｉｏｎ ｏｆ ｔｈｉｓ ＦＩＣ ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣの内容に変更がある場合に増加することができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはブロードキャストストリームのパーティション数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが使われるために、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送されることができることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは一つのブロードキャスターによって使用されたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは前述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティションに属する少なくとも一つのコンポーネントの数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣ内のｓｅｒｖｉｃｅ ｌｏｏｐデータの変化あるいは該当のサービスに関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する都度、１ずつ増加することができる。受信機はｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化あるいは該当のサービスに係わるシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは該当のサービスに関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは該当のサービスのカテゴリーを示すことができ、例えばＡ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは該当のサービスを示す名前の長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは該当のサービスを示す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは該当のサービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドはＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」 ｆｌａｇと類似した��性を有することができる。例えば、該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドはサービス保護フラグ（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ ｆｌａｇ）であって、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるかを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰアドレス形式を示すことができる。該当のフィールド値が０である場合はＩＰｖ４形式を、１である場合はＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むかを示すことができる。該当のフィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは放送ストリーム内で該当のサービスのコンポーネントデータを伝送するｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ（例えば、ＲＯＵＴＥ又はＭＭＴＰ ｓｅｓｓｉｏｎ）の数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは伝送セッションの詳細情報を含むシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ここで、伝送セッションの詳細情報を含むシグナリングは、例えば、ＲＯＵＴＥである場合、各ＲＯＵＴＥセッションの詳細ＬＣＴ伝送セッションについての情報を含むＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎなどであり得る。ＬＳＩＤ＿ｔｓｉフィールドは伝送セッションの詳細情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであり得る。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して該当のサービスに関連したサービスシグナリングが伝達されることができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは伝送セッションがサービスシグナリングを伝送するかを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場��、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはは関連のサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する都度、該当のフィールドは１ずつ増加することができる。受信機はｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて該当のサービスに係わるシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドはサービスシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｔｓｉフィールドはサービスシグナリングを伝達する伝送セッションの識別子などを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇはサービス獲得情報がｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングを伝送するかを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎは関連のｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングデータの変化を示すことができる。該当のフィールドは、リンクレイヤーシグナリングデータに変化が発生する都度、１ずつ増加することができる。これにより、受信機はｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングの変化を感知することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ＤＰ ｆｉｅｌｄはＬ２ ｌａｙｅｒで使うことができるｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する数のｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。Ｐａｒｔｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはパーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送社などによって使われる放送ストリームの一部を示すことができる。ＦＩＣ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはＦＩＣレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。実施例によって、前述したＦＩＣに含まれた各フィールドはＦＩＣ以外の他のテーブルに含まれて放送信号と一緒に伝送されることもできる。
【０８３２】
図７８は本発明の他の実施例による次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント獲得を支援するためのＦＩＣ情報（サービス獲得情報）はサービス及びコンポーネントデータを伝達するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎについての情報を含むことができる。また、サービス獲得情報はリンクレイヤーシグナリングについての情報をさらに含むことができる。図示のように、サービス獲得情報はバイナリフォーマットで表現できるが、実施例によってＸＭＬなどの他のフォーマットで表現できる。
【０８３３】
サービス獲得情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはシグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ ｏｆ ｓｔｒｕｃｔｕｒｅ ｏｆ ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ ｏｆ ｏｖｅｒａｌｌ ｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ）を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはブロードキャストストリームのパーティション数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが使われるために、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送されることができることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは一つのブロードキャスターによって使用されたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは該当のパーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは前述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のパーティションに属する少なくとも一つのサービスの数を示すことができる。各サービスは複数のシグナリングテーブルを含むことができる。例えば、コンポーネントとそのセグメントについての情報を含むＤＡＳＨ ＭＰＤ、ブロードバンド及び他のブロードキャストストリームに含まれたコンポーネントに対する識別子を含むＣＭＴ、アプリケーションシグナリングテーブルであるＡＳＴ及びＭＰＤ、ＣＭＴ、ＡＳＴの少なくとも一つのＵＲＬを含むＵＳＴ（ＵＲＬ ｓｉｇｎａｌｉｎｇ ｔａｂｌｅ）を含むことができる。これらのシグナリングテーブルは該当のサービスのシグナリングチャネルに含まれることができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドはＦＩＣ内のｓｅｒｖｉｃｅ ｌｏｏｐデータの変化あるいは該当のサービスに関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する都度、１ずつ増加することができる。例えば、ＦＩＣ、ＭＰＤ、ＣＭＴ、ＡＳＴ又はＵＳＴに変化がある場合に１ずつ増加することができる。受信機はｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化あるいは該当のサービスに係わるシグナリングの変化を感知することができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは該当のサービスに関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは該当のサービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは該当のサービスを示す名前の長さを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅフィールドは該当のサービスを示す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは該当のサービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドはＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」 ｆｌａｇと類似した属性を有することができる。例えば、該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドはサービス保護フラグ（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ ｆｌａｇ）であって、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるかを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰアドレス形式を示すことができる。該当のフィールド値が０である場合はＩＰｖ４形式を、１である場合はＩＰｖ６アドレス形式を用いることを示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓはブロードキャストストリーム内で該当のサービスのコンポーネントデータを伝送する伝送セッションの数を示すことができる。例えば、伝送セッションはＲＯＵＴＥセッションであり得る。次の情報は各ＲＯＵＴＥセッションに対して設定されることができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは該当のサービスのコンポーネントデータを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは伝送セッションの詳細情報を含むシグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。ここで、伝送セッションの詳細情報を含むシグナリングは、例えば、ＲＯＵＴＥである場合、各ＲＯＵＴＥセッションの詳細ＬＣＴ伝送セッションについての情報を含むＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎなどであり得る。ＬＳＩＤ＿ｔｓｉフィールドは伝送セッションの詳細情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであり得る。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して該当のサービスに関連したサービスシグナリングが伝達されることができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは伝送セッションがサービスのコンポ���ネントシグナリングを伝送するかを示すことができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、該当の伝送セッションを介して伝送されるデータの中でサービスシグナリング（例えば、ＭＰＤ（ＤＡＳＨ Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）、ＣＭＴなど）を含んでいることを示すことができる。ここで、ＣＭＴはＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅであって、ブロードバンドを介して伝達されるコンポーネントの識別子を含むことができ、また、他のブロードキャストストリームに含まれたコンポーネントについての情報も含むことができる。各サービスはサービスシグナリングチャネルを含むことができ、サービスシグナリングチャネルは、ＭＰＤ、ＣＭＴ、ＡＳＴ及び／又はＵＳＴを含むことができる。サービスシグナリングチャネルはサービスのための複数のラウトセッションの一つのシグナリングチャネルであってもよく、存在有無をｃｏｍｐｏｎｅｎｔ ｓｉｇｎａｌｉｎｇ ｆｌａｇを介して表すことができる。複数の伝送セッション（ＲＯＵＴＥ又はＭＭＴＰセッション）がシグナリング及びサービスのコンポーネントを伝送する場合、好ましくは前述したサービスシグナリングテーブルは一つの伝送セッションによって伝達されることができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇはサービス獲得情報がｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングを伝送するかを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎはは関連のｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングデータの変化を示すことができる。該当のフィールドは、リンクレイヤーシグナリングデータに変化が発生する都度、１ずつ増加することができる。これにより、受信機はｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングの変化を感知することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ＤＰ ｆｉｅｌｄはＬ２ ｌａｙｅｒで使うことができるｌｉｎｋ ｌａｙｅｒ（あるいはｌｏｗ ｌａｙｅｒ）シグナリングを伝達するｐｈｙｓｉｃａｌ ｌａｙｅｒのＤａｔａ ｐｉｐｅ識別子を示すことができる。
【０８３４】
ＲＯＵＴＥ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する数のｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドは伝送セッションレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒｓフィールドはｓｅｒｖｉｃｅレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。Ｐａｒｔｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒｓフィールドはパーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送社などによって使われる放送ストリームの一部を示すことができる。ＦＩＣ ｄｅｓｃｒｉｐｔｏｒｓフィールドはＦＩＣレベルのｄｅｓｃｒｉｐｔｏｒを含むことができる。
【０８３５】
実施例によって、前述したサービス獲得情報に含まれた各フィールドはサービス獲得情報以外の他の情報とともに放送信号に含まれて伝送されることもできる。
【０８３６】
図７９は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを獲得する方法を示す。図面の上端は本発明の次世代放送システムで使用するサービスレイヤーシグナリングのフォーマットであって、サービスレイヤーシグナリングは図示のような形態にカプセル化されることができる。例えば、カプセル化されたサービスレイヤーシグナリングはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。次世代放送システムで先立って提案したサービスシグナリングを使う場合、図面の下端のように伝達することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８３７】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。
【０８３８】
また、図示のように、伝送セッションインスタンスディスクリプタは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅは伝送セッションインスタンスディスクリプタを含むことができる。本発明において、伝送セッションインスタンスディスクリプタはサービスレイヤーシグナリングの一つとして含まれて伝達されることもできる。
【０８３９】
図８０は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを獲得する方法を示す。次世代放送システムで先立って提案したサービスレイヤーシグナリングを使う場合、図面のように伝達することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８４０】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。
【０８４１】
また、図示のように、伝送セッションインスタンスディスクリプタは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅは伝送セッションインスタンスディスクリプタを含むことができる。本発明において、伝送セッションインスタンスディスクリプタはサービスレイヤーシグナリングの一つとして含まれて伝達されることもできる。
【０８４２】
また、速いサービス獲得情報はリンクレイヤーシグナリングが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤーシグナリングが伝達されるＰＬＰを識別し、その中に含まれたリンクレイヤーシグナリングを獲得することができる。図示のように、伝送リンクレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはリンクレイヤーシグナリングについての情報を含むことができる。受信機はｄａｔａ ｐｉｐｅなどを介してＬｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ（あるいはｌｏｗ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を獲得することができ、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌを介してＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅなどのサービス／コンポーネントシグナリングを獲得することができる。
【０８４３】
図８１は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを獲得する方法を示す。次世代放送システムでサービス／コンポーネントシグナリングのために３ＧＰＰ ｅＭＢＭＳシグナリングなどを使う場合、図示のように伝達されることができる。ここで、サービスレイヤーシグナリングはＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌを含むことができ、伝送セッションインスタンスディスクリプションをさらに含むことができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８４４】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌを含むことができる。
【０８４５】
また、図示のように、伝送セッションインスタンスディスクリプタは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅは伝送セッションインスタンスディスクリプタを含むことができる。本発明において、伝送セッションインスタンスディスクリプタはサービスレイヤーシグナリングの一つとして含まれて伝達されることもできる。
【０８４６】
図８２は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを獲得する方法を示す。次世代放送システムで３ＧＰＰ ｅＭＢＭＳシグナリングを使う場合、図面のように伝達することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８４７】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌを含むことができる。
【０８４８】
また、図示のように、伝送セッションインスタンスディスクリプタは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅは伝送セッションインスタンスディスクリプタを含むことができる。本発明において、伝送セッションインスタンスディスクリプタはサービスレイヤーシグナリングの一つとして含まれて伝達されることもできる。
【０８４９】
また、速いサービス獲得情報はリンクレイヤーシグナリングが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてリンクレイヤーシグナリングが伝達されるＰＬＰを識別し、その中に含まれたリンクレイヤーシグナリングを獲得することができる。図示のように、伝送リンクレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはリンクレイヤーシグナリングについての情報を含むことができる。受信機はｄａｔａ ｐｉｐｅなどを介してＬｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ（あるいはｌｏｗ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を獲得することができ、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌを介してＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅなどのサービス／コンポーネントシグナリングを獲得することができる。すなわち、次世代放送システムは物理的階層フレームにリンクレイヤーシグナリングが含まれたデータパイプ又はＰＬＰのシグナリング情報を含むことができる。
【０８５０】
図８３は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを伝送する方法を示す。図面の上端は本発明の次世代放送システムで使用するサービスレイヤーシグナリングのフォーマットであって、サービスレイヤーシグナリングは図示のような形態にカプセル化されることができる。例えば、カプセル化されたサービスレイヤーシグナリングは、左側上端に示したように、Ｇｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。あるいは、カプセル化されたサービスレイヤーシグナリングは、右側上端に示したように、Ｇｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。また、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８５１】
次世代放送システムで先立って提案したサービスシグナリングを使う場合、図面の下端のように伝達することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８５２】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。前述したように、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ１の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。また、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ２の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。また、ＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ３の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。これにより、受信機はサービスレイヤーシグナリングのａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ ｉｄ及びｖｅｒｓｉｏｎ情報を用いて所望のサービスレイヤーシグナリングをフィルタリングすることができる。例えば、ＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎを受信しよう��する場合、ｓｉｇｎａｌｉｎｇ ｉｄ０ｘＦ１を有するサービスレイヤーシグナリングを受信することができる。また、この際、バージョン情報を確認し、既に受信されたＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ該当のサービスレイヤーシグナリングをパーシングすることができる。これにより、受信機はサービスレイヤーシグナリングに対する不必要なパーシング動作を減らすことができ、プロセッシングオーバーヘッドを減少させることができる。前述したように、次世代放送システムはサービスレイヤーシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含ませることにより、受信端が所望の情報をフィルタリングすることができるように支援することができる。
【０８５３】
図８４は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを伝送する方法を示した図である。本発明の次世代放送システムで使用するサービスレイヤーシグナリングはカプセル化されることができる。例えば、カプセル化されたサービスレイヤーシグナリングはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。あるいは、カプセル化されたサービスレイヤーシグナリングはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。また、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８５４】
次世代放送システムで先立って提案したサービスシグナリングを使う場合、図示のように伝達されることができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８５５】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。前述したように、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ１の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。また、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ２の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。また、ＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ３の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。これにより、受信機はサービスレイヤーシグナリングのａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ ｉｄ及びｖｅｒｓｉｏｎ情報を用いて所望のサービスレイヤーシグナリングをフィルタリングすることができる。例えば、ＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎを受信しよう��する場合、ｓｉｇｎａｌｉｎｇ ｉｄ０ｘＦ１を有するサービスレイヤーシグナリングを受信することができる。また、この際、バージョン情報を確認し、既に受信されたＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ該当のサービスレイヤーシグナリングをパーシングすることができる。これにより、受信機はサービスレイヤーシグナリングに対する不必要なパーシング動作を減らすことができ、プロセッシングオーバーヘッドを減少させることができる。前述したように、次世代放送システムはサービスレイヤーシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含ませることで、受信端が所望の情報をフィルタリングすることができるように支援することができる。
【０８５６】
また、速いサービス獲得情報はリンクレイヤーシグナリングが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてリンクレイヤーシグナリングが伝達されるＰＬＰを識別し、その中に含まれたリンクレイヤーシグナリングを獲得することができる。図示のように、伝送リンクレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはリンクレイヤーシグナリングについての情報を含むことができる。受信機はｄａｔａ ｐｉｐｅなどを介してＬｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ（あるいはｌｏｗ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を獲得することができ、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌを介してＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅなどのサービス／コンポーネントシグナリングを獲得することができる。すなわち、次世代放送システムは物理的階層フレームにリンクレイヤーシグナリングが含まれたデータパイプ又はＰＬＰのシグナリング情報を含むことができる。
【０８５７】
図８５は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを伝送する方法を示す。本発明の次世代放送システムで使用するサービスレイヤーシグナリングはカプセル化されることができる。例えば、カプセル化されたサービスレイヤーシグナリングはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。あるいは、カプセル化されたサービスレイヤーシグナリングはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。また、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８５８】
次世代放送システムで３ＧＰＰ ｅＭＢＭＳシグナリングを使う場合、図面のように伝達することができる。次世代放送システムで先立って提案したサービスシグナリングを使う場合、図面の下端のように伝達することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８５９】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌを含むことができる。前述したように、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ４の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。また、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ５の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＳｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌの内容に変更がある場合に変更されることができる。また、ＭＰＤを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ６の値を有することができる。また、そのバージョン情報は０ｘ０２の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＭＰＤの内容に変更がある場合に変更されることができる。これにより、受信機はサービスレイヤーシグナリングのａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ ｉｄ及びｖｅｒｓｉｏｎ情報を用いて所望のサービスレイヤーシグナリングをフィルタリングすることができる。例えば、Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇ ｉｄ０ｘＦ４を有するサービスレイヤーシグナリングを受信することができる。また、この際、バージョン情報を確認し、既に受信されたＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ該当のサービスレイヤーシグナリングをパーシングすることができる。これにより、受信機はサービスレイヤーシグナリングに対する不必要なパーシング動作を減らすことができ、プロセッシングオーバーヘッドを減少させることができる。前述したように、次世代放送システムはサービスレイヤーシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含ませることで、受信端が所望の情報をフィルタリングすることができるように支援することができる。
【０８６０】
図８６は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリング及びリンクレイヤーシグナリングを伝送する方法を示した図である。本発明の次世代放送システムで使用するサービスレイヤーシグナリングはカプセル化されることができる。例えば、カプセル化されたサービスレイヤーシグナリングはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。あるいは、カプセル化されたサービスレイヤーシグナリングはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅの組合せで構成されることができる。また、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８６１】
次世代放送システムで３ＧＰＰ ｅＭＢＭＳシグナリングを使う場合、図面のように伝達することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅを介して伝送されることができる。放送信号フレームは物理階層シグナリング（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を含むことができる。物理階層シグナリングの情報は速いサービス獲得情報に対するフィールドを含むことができる。該当のフィールドは速いサービス獲得情報のバージョン情報を含むことができる。言い換えれば、該当のフィールドは物理的階層フレームが速いサービス獲得情報を含むかあるいは速いサービス獲得情報をパーシングしなければならないかを示すことができる。受信機は物理階層シグナリングの該当のフィールドを用いて速いサービス獲得情報を獲得することができる。次世代放送システムの放送信号はｐｈｙｓｉｃａｌ ｌａｙｅｒ ｆｒａｍｅ内に速いサービス獲得情報を含むことができる。速いサービス獲得情報はサービス識別子を含むことができ、サービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてサービスレイヤーシグナリング又は伝送セッションインスタンスディスクリプタの少なくとも一つが伝達されるＰＬＰを識別し、その中に含まれたサービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタを獲得することができる。図示のように、サービスレイヤーシグナリング情報又は伝送セッションインスタンスディスクリプタは該当のＰＬＰ内の０番目伝送セッションによって伝達されることができる。すなわち、サービスレイヤーシグナリングはサービス獲得情報に含まれたＰＬＰ識別子が指示するＰＬＰ内のｔｓｉ＝０にあたる伝送セッションによって伝達されることができる。言い換えれば、サービスレイヤーシグナリングが伝達される伝送セッションはその識別子が０に固定されることができる。
【０８６２】
図示のように、サービスレイヤーシグナリングは前述したｅｎｃａｐｓｕｌａｔｉｏｎ形態を有することができる。すなわち、サービスレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはサービスレイヤーシグナリングが伝達するメッセージの種類によってＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌを含むことができる。前述したように、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ４の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合に変更されることができる。また、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ５の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＳｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌの内容に変更がある場合に変更されることができる。また、ＭＰＤを含むサービスレイヤーシグナリングはｓｉｇｎａｌｉｎｇ ｉｄであって、０ｘＦ６の値を有することができる。また、そのバージョン情報は０ｘ０２の値を有することができ、バージョン情報は該当のサービスレイヤーシグナリングのシグナリングメッセージであるＭＰＤの内容に変更がある場合に変更されることができる。これにより、受信機はサービスレイヤーシグナリングのａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ ｉｄ及びｖｅｒｓｉｏｎ情報を用いて所望のサービスレイヤーシグナリングをフィルタリングすることができる。例えば、Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇ ｉｄ０ｘＦ４を有するサービスレイヤーシグナリングを受信することができる。また、この際、バージョン情報を確認し、既に受信されたＵｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ該当のサービスレイヤーシグナリングをパーシングすることができる。これにより、受信機はサービスレイヤーシグナリングに対する不必要なパーシング動作を減らすことができ、プロセッシングオーバーヘッドを減少させることができる。前述したように、次世代放送システムはサービスレイヤーシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含ませることで、受信端が所望の情報をフィルタリングすることができるように支援することができる。
【０８６３】
また、速いサービス獲得情報はリンクレイヤーシグナリングが伝達されるデータパイプ又はＰＬＰについての情報を含むことができる。すなわち、受信機は速いサービス獲得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いてリンクレイヤーシグナリングが伝達されるＰＬＰを識別し、その中に含まれたリンクレイヤーシグナリングを獲得することができる。図示のように、伝送リンクレイヤーシグナリングのフォーマットはＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅはリンクレイヤーシグナリングについての情報を含むことができる。受信機はｄａｔａ ｐｉｐｅなどを介してＬｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ（あるいはｌｏｗ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）を獲得することができ、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌを介してＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅなどのサービス／コンポーネントシグナリングを獲得することができる。すなわち、次世代放送システムは物理的階層フレームにリンクレイヤーシグナリングが含まれたデータパイプ又はＰＬＰのシグナリング情報を含むことができる。
【０８６４】
図８７は本発明の一実施例による次世代放送システムのサービスレイヤーシグナリングを伝送する方法を示した図である。サービスレイヤーシグナリングは前述したシグナリング又は３ＧＰＰ ｅＭＢＭＳシグナリングを含むことができる。次世代放送システムの放送信号にＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌが存在しない場合、図示のように迅速なサービススキャン及び獲得を支援するためのシグナリングデータがｐｈｙｓｉｃａｌ ｆｒａｍｅ内のｃｏｍｍｏｎ ｄａｔａ ｐｉｐｅ、ｄａｔａ ｐｉｐｅ又はＰＬＰを介して伝送されることができる。この場合、迅速なサービススキャン及び獲得などに係わるシグナリングデータはｌｉｎｋ（あるいはｌｏｗ）ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ形態にカプセル化されることができ、他のｌｉｎｋ（あるいはｌｏｗ）ｌａｙｅｒ ｓｉｇｎａｌｉｎｇなどと一緒に伝送されることができる。すなわち、フレーム内のＰＬＰはサービス獲得情報を含むシグナリングデータを伝送することができる。また、これはサービス／コンポーネントシグナリングあるいはコンポーネントデータと同一であるか別個のｄａｔａ ｐｉｐｅ又はＰＬＰを介して伝送されることもできる。サービス／コンポーネントシグナリングは先立って提案したシグナリングあるいは３ＧＰＰ ｅＭＢＭＳシグナリングなどが伝送されることができる。該当のシグナリングは前述したようにＧｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。ここで、ＳＭＨは実施例によってシグナリングフォーマットに含まれないこともできる。ここで、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８６５】
図面の下端はリンクレイヤーシグナリングに含まれたサービス獲得情報を用いてサービスレイヤーシグナリングを獲得する方法を示した図である。放送信号フレームのＰＬＰはリンクレイヤーシグナリングを含むことができる。リンクレイヤーシグナリングは前述した速いサービススキャン及び獲得情報を含むことができる。速いサービススキャン及び獲得情報はサービス識別子及び該当のサービスに対するサービスレイヤーシグナリングが含まれたＰＬＰ識別子情報を含むことができる。該当のＰＬＰ識別子によって指示されるＰＬＰはサービスレイヤーシグナリングを含むことができる。サービスレイヤーシグナリングは、前述したように、Ｇｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。サービスレイヤーシグナリングのｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅは伝送セッションインスタンスディスクリプション、ＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。次世代放送信号受信機はサービスレイヤーシグナリングをパーシングして所望のサービスを獲得することができる。
【０８６６】
図８８は本発明の一実施例による次世代放送システムでサービスレイヤーシグナリングを伝送する方法を示した図である。サービスレイヤーシグナリングは前述したシグナリング又は３ＧＰＰ ｅＭＢＭＳシグナリングを含むことができる。放送信号フレームのＰＬＰはリンクレイヤーシグナリングを含むことができる。リンクレイヤーシグナリングは前述した速いサービススキャン及び獲得情報を含むことができる。速いサービススキャン及び獲得情報はサービス識別子及び該当のサービスに対するサービスレイヤーシグナリングが含まれたＰＬＰ識別子情報を含むことができる。該当のＰＬＰ識別子によって指示されるＰＬＰはサービスレイヤーシグナリングを含むことができる。サービスレイヤーシグナリングは、前述したように、Ｇｅｎｅｒｉｃ ｐａｃｋｅｔ ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ ｐａｃｋｅｔ Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ ｄａｔａｇｒａｍ ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）及びｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅを含むことができる。サービスレイヤーシグナリングのｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅは伝送セッションインスタンスディスクリプション、ＭＰＤ ｄｅｌｉｖｅｒｙ ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。次世代放送信号受信機はサービスレイヤーシグナリングをパーシングして所望のサービスを獲得することができる。ここで、ＡＴＰＨはサービスレイヤーシグナリングに対するｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ ｉｄはサービスレイヤーシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎはサービスレイヤーシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。ｆｉｌｔｅｒｉｎｇ ｉｎｄｅｘを用いてサービスレイヤーシグナリングをフィルタリングする方法は前述したようである。
【０８６７】
図８９は本発明の他の実施例による、シグナリングメッセージ（ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ）のヘッダー（ｈｅａｄｅｒ）のシンタックス（ｓｙｎｔａｘ）を示した図である。
【０８６８】
本発明の他の実施例によるシグナリングメッセージはＸＭＬ形態に表現できる。この際、ＸＭＬ形態のシグナリングメッセージに含まれるシグナリング情報は、前述したようなあるいは後述したようなシグナリング情報に当たることができる。
【０８６９】
本発明の他の実施例による、シグナリングメッセージのヘッダーは、ｓｉｇｎａｌｉｎｇ＿ｉｄ情報、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈ情報、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ情報、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ情報、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ情報、ｉｎｄｉｃａｔｏｒ＿ｆｌａｇｓ情報、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ情報、ｐａｙｌｏａｄ＿ｆｏｒｍａｔ＿ｉｎｄｉｃａｔｏｒ情報、ｅｘｐｉｒａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ情報、ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒ情報、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒ情報、ｐａｙｌｏａｄ＿ｆｏｒｍａｔ情報、ｖａｌｉｄｆｒｏｍ情報、及び／又はｅｘｐｉｒａｔｉｏｎ情報を含むことができる。
【０８７０】
この実施例によるシグナリングメッセージのヘッダーに含まれるシグナリング情報の中で、前述したシグナリングメッセージのヘッダーに含まれるシグナリング情報と同一であるか類似した名称を有するシグナリング情報についての説明は、前述した説明に取り替える。
【０８７１】
ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報は、シグナリングメッセージのヘッダー部分にｖａｌｉｄｆｒｏｍ情報の値が含まれたかを示すことができる。例えば、ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報の値が‘１’である場合、シグナリングメッセージのヘッダー部分にｖａｌｉｄｆｒｏｍ情報が含まれていることを示すことができる。
【０８７２】
ｖａｌｉｄｆｒｏｍ情報は、ペイロード（ｐａｙｌｏａｄ）に含まれたシグナリングメッセージの可用開始時点を示すことができる。受信機はこれを用いて、ペイロードに含まれたシグナリングの可用開始時点を認知することができ、該当の時点からペイロードに含まれたデータをシグナリング情報として使うことができる。
【０８７３】
ここで、ペイロードは放送サービス又は放送コンテンツのデータ（放送サービスデータ）を含む放送信号内の領域を示すことができる。すなわち、シグナリング情報は、放送信号内で、放送サービスデータとは物理的にあるいは論理的に区分された領域を介して伝送されることが一般的である。しかし、本発明によると、ペイロード領域に余裕領域が存在する場合、あるいはシグナリング情報の送信のために割り当てられた領域の大きさより多量のシグナリング情報を送信しなければならない場合には、放送信号内のペイロード領域を介してシグナリング情報を伝送することができる。
【０８７４】
図９０は本発明の一実施例による、ＤＡＳＨ Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ（ＤＡＳＨ初期化セグメント）を処理するプロトコルスタック（Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）を示した図である。
【０８７５】
ＤＡＳＨ初期化セグメントは、前述したＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅのような形態又はＸＭＬ形態で伝送されることができる。
【０８７６】
初期化セグメント（ＤＡＳＨ初期化セグメント）は複数のセグメントにカプセル化された（ｅｎｃａｐｓｕｌａｔｅｄ）メディアストリーム（放送信号又は放送信号）を表出するために必要なメタデータ（シグナリング情報）を含むセグメントである。ここで、セグメントはＨＴＴＰ−ＵＲＬに関連したデータのユニットである。セグメントは放送サービス又は放送コンテンツのためのデータを含む。レプリゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）は伝送フォーマット内に一つ以上のメディアストリームを含むデータユニットである。レプリゼンテーションは一つ以上のセグメントを含むことができる。
【０８７７】
ＤＡＳＨ初期化セグメントは、送信機又は受信機で図示のプロトコルスタックによって処理されることができる。ＤＡＳＨ初期化セグメントは、プロトコルスタック（Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）上で一つ以上の経路を介して伝送されることができる。
【０８７８】
プロトコルスタックを調べると、シグナリング情報又は放送サービスデータは、多くの階層（ｌａｙｅｒ）のプロトコルによって処理されることができることが分かる。図面に示した「シグナリングチャネル（ｓｉｇｎａｌｉｎｇ ｃｈａｎｎｅｌ）、ＤＰ（Ｄａｔａ ｐｉｐｅ）」は第１階層に当たることができ、「ＦＩＣ及びリンクレイヤーフレーム（Ｌｉｎｋ ｌａｙｅｒ ｆｒａｍｅ）」は第２階層に当たることができ、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）は第３階層に当たることができ、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）は第４階層に当たることができ、ＲＯＵＴＥは第５階層に当たることができる。ここで、リンクレイヤーフレームは本明細書に説明されたリンクレイヤーパケットを含むことができる。
【０８７９】
ＤＡＳＨ初期化セグメントが処理されるプロトコルスタックは、図示の（１）の経路のように、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）のようなシグナリングデータがＩＰ／ＵＤＰに直接上げられて伝送される場合、先立って提案したＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄｅｌｉｖｅｒｙ ｔａｂｌｅのような形態の情報として伝送されるか、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）そのものがＩＰデータグラムなどの形態として、プロトコルスタックの処理によって伝送されることができる。前述したサービスシグナリング及び／又はコンポーネントシグナリングのための情報は図示の（１）の経路を介して一緒に伝送されることができる。
【０８８０】
本発明の一実施例によると、ＤＡＳＨ初期化セグメントは、経路（２）のようにシグナリングデータを伝送するための特定のセッション（ｓｅｓｓｉｏｎ）、又は経路（３）のようにコンポーネントデータを伝送するセッションを介してメディアデータと一緒に伝送されることができる。一例として、アプリケーション伝送プロトコル（ａｐｐｌｉｃａｔｉｏｎ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）はＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）が使われることができる。ＲＯＵＴＥセッションは、シグナリング情報を伝送するためのセッション及び／又は放送メディアに対するデータを伝送するセッションを含むことができる。放送システムは、シグナリング情報を伝送するセッションのＴＳＩの値を一定する値に固定し、受信機が該当のＴＳＩの値を有するセッションを介して伝送されるデータがシグナリング情報であることを識別することができる。
【０８８１】
図示の経路（２）、及び／又は経路（３）のように、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）のようなシグナリング情報（データ）が伝送される場合、伝送ストリーム又は伝送オブジェクトなどにおいて前述したシグナリングメッセージフォーマットのデータ、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）がどの部分に位置するかを識別する情報、及び／又はシグナリングメッセージフォーマットのデータや初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）を一緒に伝送されるデータの中で区分するための情報が、伝送プロトコルパケットの内部のフィールド、又は別個のシグナリング形態として提供されることができる。
【０８８２】
図９１は本発明の一実施例による、ＬＣＴ（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）セッションインスタンスディスクリプション（ＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ；ＬＳＩＤ）の一部を示した図である。
【０８８３】
本発明の一実施例による、ＬＣＴセッションインスタンスディスクリプタは、シグナリングメッセージフォーマットのデータ、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）が放送信号内でどの部分に位置するかを識別する情報、及び／又はシグナリングメッセージフォーマットのデータや初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）を、一緒に伝送されるデータの中で区分するための情報を提供することができる。
【０８８４】
ＬＣＴセッションインスタンスディスクリプタは、ＰａｙｌｏａｄＦｏｒｍａｔエレメントを含むことができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、＠Ｃｏｄｅｐｏｉｎｔ情報、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報、＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報、＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報及び／又は＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報を含むことができる。
【０８８５】
それぞれのエレメントは、図面に説明したような情報を提供するのに使われることができる。
【０８８６】
本発明の一実施例によると、放送受信機又は放送送信機は、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）が含まれるＲＯＵＴＥパケットを識別するために、ＬＳＩＤのＳｏｕｒｃｅＦｌｏｗエレメント内のＰａｙｌｏａｄＦｏｒｍａｔエレメントの＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報（又はフィールド）を使うことができる。
【０８８７】
一実施例として、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報値が‘０’である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は該当のＲＯＵＴＥパケットシグナリングメッセージフォーマットを含んでいることを示すことができる。＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報の値が‘０’である場合、このＰａｙｌｏａｄＦｏｒｍａｔエレメントに割り当てられた＠Ｃｏｄｅｐｏｉｎｔ情報の値とＬＣＴパケットヘッダー内の同一値のＣｏｄｅ ｐｏｉｎｔ（ＣＰ）を有するＲＯＵＴＥパケットは、前述したシグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｆｏｒｍａｔ）形態のデータを送信していることを示すことができる。初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）はこのシグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｆｏｒｍａｔ）に含まれて伝送されることができ、サービスシグナリング、コンポーネントシグナリングなどの他のシグナリングデータも同様な方法でシグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇ ｍｅｓｓａｇｅ ｆｏｒｍａｔ）に含まれてＲＯＵＴＥパケットを介して伝送されていることが識別されることができる。
【０８８８】
＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報の値が‘４’である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔフィールドは該当のＲＯＵＴＥパケットが初期化セグメントを含むメタデータ（シグナリング情報）を含むことを示すことができる。＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔフィールドの値が‘４’である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）を含むメタデータフォーマットがＲＯＵＴＥパケットを介して伝送されることを示すか、あるいは初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）が直接ＲＯＵＴＥパケットを介して伝送されていることを示すことができる。
【０８８９】
本発明の一実施例によると、放送システム（放送受信機及び／又は送信機）は、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報に新たな値（例えば、‘５’以上の値）を割り当て、サービスシグナリング（サービスレベルシグナリング情報）、及び／又はコンポーネントシグナリング（コンポーネントレベルシグナリング）などの他のシグナリングデータがＲＯＵＴＥパケットを介して直接伝送されることをシグナリングすることができる。
【０８９０】
本発明の他の実施例によると、放送システムは、この実施例で説明された＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報を用いる方法の外にも、ＬＳＩＤ内の他のフィールド又は新しい追加フィールドを介し、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）などのシグナリングデータが伝送されるＲＯＵＴＥパケットを識別することもできる。
【０８９１】
図９２は本発明の一実施例による、サービスシグナリングメッセージをフィルタリング（ｆｉｌｔｅｒｉｎｇ）するためのの情報を提供するシグナリングオブジェクトディスクリプション（Ｓｉｇｎａｌｉｎｇ Ｏｂｊｅｃｔ Ｄｅｓｃｒｉｐｔｉｏｎ；ＳＯＤ）を示した図である。
【０８９２】
本発明の一実施例によるシグナリングオブジェクトディスクリプションは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ｄａｔａＶｅｒｓｉｏｎ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、ＳｉｇｎａｌｉｎｇＯｂｊｅｃｔエレメント、＠ｔｏｉ情報、＠ｔｙｐｅ情報、＠ｖｅｒｓｉｏｎ情報、＠ｉｎｓｔａｎｃｅＩｄ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔ情報を含むことができる。
【０８９３】
＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報はシグナリングオブジェクトディスクリプションのバージョンを示す。
【０８９４】
＠ｄａｔａＶｅｒｓｉｏｎ情報はシグナリングオブジェクトディスクリプションのインスタンス（ｉｎｓｔａｎｃｅ）のバージョン（ｖｅｒｓｉｏｎ）を示す。シグナリングオブジェクトディスクリプション内に含まれた内容が変更される場合、＠ｄａｔａＶｅｒｓｉｏｎが変更されることができる。
【０８９５】
＠ｖａｌｉｄＦｒｏｍ情報はシグナリングオブジェクトディスクリプションのインスタンスの可用開始時点を示すことができる。これにより、受信機はシグナリングオブジェクトディスクリプションの可用開始時点を認知することができ、該当の時点からシグナリングオブジェクトディスクリプションに含まれた情報を使うことができる。
【０８９６】
＠ｅｘｐｉｒａｔｉｏｎ情報はシグナリングオブジェクトディスクリプションのインスタンスの可用完了時点を示すことができる。これにより、受信機はシグナリングオブジェクトディスクリプションの可用完了時点を認知することができ、よってシグナリングオブジェクトディスクリプションの情報を管理することができる。
【０８９７】
ＳｉｇｎａｌｉｎｇＯｂｊｅｃｔエレメントはシグナリング情報を含むオブジェクトを示す。シグナリングオブジェクトディスクリプションは一つ以上のシグナリングオブジェクトのシグナリング情報を含むことができる。
【０８９８】
＠ｔｏｉ情報はシグナリングオブジェクトに割り当てられたＴＯＩ（ＴｒａｎｓｍｉｓｓｉｏｎＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ）を示す。＠ｔｏｉ情報はシグナリングオブジェクトに係わるパケットを識別するのに使われることができる。受信機は＠ｔｏｉ情報をＬＣＴパケットのＴＯＩにマッピングして、それぞれのｏｂｊｅｃｔが伝送するシグナリングメッセージのｔｙｐｅ、及び／又はｖｅｒｓｉｏｎなどの以下の情報を識別することができる。
【０８９９】
＠ｔｙｐｅ情報はオブジェクトに含まれたシグナリングメッセージのタイプを識別する情報である。例えば、＠ｔｙｐｅ情報の値が０であればＬＳＩＤ（ＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が１であればＣＭＤ（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が２であればＡＳＤ（ＡｐｐｌｉｃａｔｉｏｎＳｉｇｎａｌｉｎｇＤｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が３であればＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が４であればＵＳＤ（ＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が５であればＩＳ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）がオブジェクト内でシグナリングメッセージとして伝送されることを示すことができる。
【０９００】
＠ｖｅｒｓｉｏｎ情報はシグナリングメッセージのバージョン（ｖｅｒｓｉｏｎ）を示す情報である。受信機はこのフィールド値の変化によってシグナリングメッセージの変更を識別することができる。
【０９０１】
＠ｉｎｓｔａｎｃｅＩｄ情報はシグナリングメッセージのインスタンスを識別する情報である。この情報は、受信機が、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）などのように、一つのサービス内に存在することができるシグナリングメッセージのインスタンスを区分するのに使われることができる。
【０９０２】
＠ｖａｌｉｄＦｒｏｍ情報はオブジェクトに含まれたシグナリングメッセージの可用開始時点を示すことができる。これにより、受信機はオブジェクトに含まれたシグナリングの可用開始時点を認知することができ、該当の時点からオブジェクトに含まれたシグナリングを使うことができる。
【０９０３】
＠ｅｘｐｉｒａｔｉｏｎ情報はオブジェクトに含まれたシグナリングメッセージの有効時間を示すことができる。これにより、受信機はオブジェクトに含まれたシグナリングの可用完了時間を認知することができ、よってシグナリングメッセージを管理することができる。
【０９０４】
＠ｐａｙｌｏａｄＦｏｒｍａｔ情報はオブジェクトに含まれるシグナリングメッセージデータのフォーマットを示すことができる。例えば、シグナリングメッセージはｂｉｎａｒｙ又はＸＭＬの形式で提供されることができ、＠ｐａｙｌｏａｄＦｏｒｍａｔ情報はこの形式を示す。
【０９０５】
シグナリングメッセージがＲＯＵＴＥなどのＬＣＴに基づくプロトコルで伝送される場合、それぞれのシグナリングメッセージをオブジェクトに設定して処理することができる。このプロトコルにおいてオブジェクトは固有のＴＯＩによって識別されることができるので、それぞれのＴＯＩにｖｅｒｓｉｏｎ、ｔｙｐｅなどシグナリングメッセージ関連情報をマッピングすることによってシグナリングメッセージをフィルタリングすることができる。前述したようなＳＯＤ（Ｓｉｇｎａｌｉｎｇ Ｏｂｊｅｃｔ Ｄｅｓｃｒｉｐｔｉｏｎ）は一つの伝送セッションにあたるシグナリングオブジェクトのフィルタリング情報を提供する。シグナリングオブジェクトディスクリプションはシグナリングを伝送するセッションの内部、又は外部手段を介して伝送されることができる。内部手段を介してシグナリングオブジェクトディスクリプションが伝送される場合、受信機は固有のＴＯＩ値（例えば、０又は０ｘＦＦＦＦなどの値）でシグナリングオブジェクトディスクリプションを識別し、一緒に伝送される他のシグナリングメッセージに先立ってシグナリングオブジェクトディスクリプションを解釈することができる。外部手段を介してシグナリングオブジェクトディスクリプションが伝送される場合、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）、ＳＬＴ（ｓｅｒｖｉｃｅ ｌｉｓｔ ｔａｂｌｅ）、別個のＩＰデータグラム、又は他のＲＯＵＴＥセッションなどの手段を介して、該当のセッションで伝送される他のオブジェクトに先立ち、シグナリングオブジェクトディスクリプションが伝送されるので、受信機はシグナリングメッセージの情報を予め獲得することができる。
【０９０６】
図９３は本発明の一実施例による、シグナリングメッセージを含むオブジェクトを示した図である。
【０９０７】
シグナリングメッセージがＲＯＵＴＥなどのＬＣＴに基づくプロトコルによって伝送される場合、それぞれのシグナリングメッセージをオブジェクトに設定して処理することができる。このプロトコルにおいてオブジェクトは固有のＴＯＩによって識別されることができる。受信機はそれぞれのＴＯＩにｖｅｒｓｉｏｎ、及び／又はｔｙｐｅなどシグナリングメッセージ関連情報をマッピングしてシグナリングメッセージをフィルタリングすることができる。互いに他の内容物を収容するオブジェクトには互いに異なるＴＯＩが付与されることができる。この場合、放送システムでは全てのオブジェクトが固有に識別されることができるので、既存のオブジェクト処理方法と互換可能な方法でシグナリングメッセージを処理することができる。
【０９０８】
図９３はＴＯＩフィールドの一部を固定長のシグナリングメッセージ関連情報技術のために使用する実施例を示す。この実施例では、３２ビットのＴＯＩフィールドが使われ、それぞれ１６ビットのＴｙｐｅとＶｅｒｓｉｏｎフィールドによって、オブジェクトを介して伝送されている前述したシグナリングデータのｔｙｐｅとｖｅｒｓｉｏｎを識別することができる。同様な方法で、前述したｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ情報、ｖａｌｉｄ ｆｒｏｍ情報、ｅｘｐｉｒａｔｉｏｎ情報、及び／又はｐａｙｌｏａｄ ｆｏｒｍａｔ情報の追加情報も、この実施例のＴｙｐｅ、Ｖｅｒｓｉｏｎのように、ＴＯＩフィールドの一部を固定長のフィールドに割り当てることによって伝達することができる。
【０９０９】
本発明の一実施例による、オブジェクトは、ｖエレメント、ｃエレメント、ＰＳＩエレメント、Ｓエレメント、Ｏエレメント、Ｈエレメント、Ａエレメント、Ｂエレメント、ＨＤＲ＿ＬＥＮエレメント、Ｃｏｄｅｐｏｉｎｔエレメント、Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎエレメント、Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ（ＴＳＩ）エレメント、Ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）エレメント、Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎｓエレメント、ＦＥＣ ｐａｙｌｏａｄ ＩＤエレメント、及び／又はＥｎｃｏｄｉｎｇ Ｓｙｍｂｏｌｓエレメントを含むことができる。ここで、エレメントは情報又はフィールドということもできる。
【０９１０】
ＰＳＩエレメントはＸエレメント及び／又はＹエレメントを含むことができる。
【０９１１】
ＴＯＩエレメントは、Ｔｙｐｅエレメント及び／又はＶｅｒｓｉｏｎエレメントを含むことができる。
【０９１２】
ｖエレメントはパケットのバージョンナンバーを示す。ｖエレメントはＡＬＣ／ＬＣＴのバージョンを示すことができる。ｖエレメントはこのオブジェクトを介してＡＬＣ／ＬＣＴ＋に従うパケットが伝送されることを示すことができる。
【０９１３】
ｃエレメントはＣｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌｆｌａｇに当たる。ｃエレメントはＣｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントの長さを示すことができる。例えば、ｃエレメントは、ｃエレメントの値が０である場合、ＣＣＩの長さは３２ビット、ｃエレメントの値が１である場合、ＣＣＩの長さは６４ビット、ｃエレメントの値が２である場合、ＣＣＩの長さは９６ビット、ｃエレメントの値が３である場合、ＣＣＩの長さは１２８ビットであることを示すことができる。
【０９１４】
ＰＳＩエレメントはＰｒｏｔｏｃｏｌ−Ｓｐｅｃｉｆｉｃ Ｉｎｄｉｃａｔｉｏｎ（ＰＳＩ）に当たることができる。ＰＳＩエレメントはＡＬＣ／ＬＣＴ＋の上位プロトコルに対する特定目的の指示子として使われることができる。ＰＳＩエレメントは現在パケットがｓｏｕｒｃｅ ｐａｃｋｅｔに当たるかあるいはＦＥＣ ｒｅｐａｉｒ ｐａｃｋｅｔに当たるかを示すことができる。
【０９１５】
Ｘエレメントはｓｏｕｒｃｅｐａｃｋｅｔを示す情報に当たることができる。Ｓｏｕｒｃｅとｒｅｐａｉｒ ｄａｔａのために互いに異なるＦＥＣ ｐａｙｌｏａｄ ＩＤフォーマットが使われる場合、このエレメントの値が‘１’であればｓｏｕｒｃｅ ｄａｔａのためのＦＥＣ ｐａｙｌｏａｄ ＩＤフォーマットであるこを示し、このエレメントの値が‘０’であればｒｅｐａｉｒ ｄａｔａのためのＦＥＣ ｐａｙｌｏａｄ ＩＤフォーマットであることを示す。あるいは、このエレメントの値が送信機で‘０’にセットされた場合、受信機はこのエレメント又はこのパケットを無視し、処理しないこともできる。
【０９１６】
ＳエレメントはＴｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ ｆｌａｇに当たることができる。ＳエレメントはＴｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒエレメントの長さを示す。
【０９１７】
ＯエレメントはＴｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ ｆｌａｇに当たることができる。ＯエレメントはＴｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒエレメントの長さを示すことができる。オブジェクトは一つのファイルを意味することができ、ＴＯＩは各オブジェクトの識別情報であって、ＴＯＩが０であるファイルはファイルに係わるシグナリング情報を含むことができる。
【０９１８】
ＨエレメントはＨａｌｆ−ｗｏｒｄｆｌａｇに当たることができる。ＨエレメントはＴＳＩ及びＴＯＩフィールドの長さにｈａｌｆ−ｗｏｒｄ（１６ｂｉｔｓ）を付け加えるかを指示する。
【０９１９】
ＡエレメントはＣｌｏｓｅ Ｓｅｓｓｉｏｎ ｆｌａｇに当たることができる。Ａエレメントはセッションの終了又は終了が切迫したことを示すことができる。
【０９２０】
ＢエレメントはＣｌｏｓｅ Ｏｂｊｅｃｔ ｆｌａｇに当たることができる。Ｂエレメントは伝送中のオブジェクトの終了又は終了が切迫したことを示すことができる。
【０９２１】
ＨＤＲ＿ＬＥＮエレメントはパケットのヘッダーの長さを示す。
【０９２２】
Ｃｏｄｅｐｏｉｎｔエレメントはこのパケットによって伝送されるペイロード（ｐａｙｌｏａｄ）のタイプを示す。ペイロードのタイプによって、更なるペイロードヘッダーがペイロードデータのプレフィックス（ｐｒｅｆｉｘ）に挿入されることができる。
【０９２３】
Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントはｌａｙｅｒ ｎｕｍｂｅｒｓ、ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ ｎｕｍｂｅｒｓ、ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒｓなどのＣｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ情報を含むことができる。Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントは必要なＣｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ関連情報を含むことができる。
【０９２４】
Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ（ＴＳＩ）エレメントはセッションの固有識別子である。ＴＳＩエレメントは特定の伝送子（ｓｅｎｄｅｒ）からの全てのセッション（ｓｅｓｓｉｏｎ）のいずれか一つのセッションを示す。ＴＳＩエレメントはｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎを識別する役目をする。ＴＳＩエレメントの値は一つのトラックのために使われることができる。
【０９２５】
Ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）エレメントはオブジェクトの固有識別子である。ＴＯＩエレメントは、セッション内で、どのジェクトにこのパケットが属するかを示す。ＴＯＩエレメントの値は一つのＩＳＯ ＢＭＦＦ ｏｂｊｅｃｔデータのために使われることができる。ＴＯＩエレメントはＩＳＯ ＢＭＦＦファイルのＩＤとｃｈｕｎｋのＩＤを含むことができる。ＴＯＩエレメントはＩＳＯ ＢＭＦＦファイルのＩＤとｃｈｕｎｋのＩＤの組合せをその値として有することができる。
【０９２６】
Ｔｙｐｅエレメントはこのオブジェクトを介して伝送されるデータの種類を識別することができる。例えば、Ｔｙｐｅエレメントはこのオブジェクトを介して伝送されるデータがシグナリングメッセージであることを示すことができる。
【０９２７】
Ｖｅｒｓｉｏｎエレメントはこのオブジェクトを介して伝送されるデータのバージョンを識別する。例えば、ＶｅｒｓｉｏｎエレメントはＴｙｐｅオブジェクトを介して識別されたデータの構造及び／又は内容の変更があるかを識別する情報を含むことができる。
【０９２８】
Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎｓエレメントは更なるヘッダー情報を含むことができる。
【０９２９】
ＦＥＣ ｐａｙｌｏａｄ ＩＤエレメントはＦＥＣ Ｐａｙｌｏａｄ識別子である。ＦＥＣ ｐａｙｌｏａｄ ＩＤエレメントはＴｒａｎｓｍｉｓｓｉｏｎ Ｂｌｏｃｋ又はｅｎｃｏｄｉｎｇ ｓｙｍｂｏｌの識別情報を含む。ＦＥＣ Ｐａｙｌｏａｄ ＩＤはファイルがＦＥＣエンコードされた場合の識別子を示す。例えば、ＦＥＣ Ｐａｙｌｏａｄ ＩＤは、ＦＬＵＴＥプロトコルファイルがＦＥＣエンコードされた場合、放送局又は放送サーバーがこれを区分するために割り当てることができる。
【０９３０】
Ｅｎｃｏｄｉｎｇ ＳｙｍｂｏｌｓエレメントはＴｒａｎｓｍｉｓｓｉｏｎ Ｂｌｏｃｋ又はｅｎｃｏｄｉｎｇ ｓｙｍｂｏｌのデータを含むことができる。
【０９３１】
図９４は本発明の一実施例による、ＴＯＩ構成ディスクリプション（ＴＯＩ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＤ）を示した図である。
【０９３２】
前述したように、ＴＯＩフィールドの一部を可変長のシグナリングメッセージ関連情報の記述のために使うことができる。可変長のＴＯＩフィールド内で、シグナリングメッセージ関連情報の記述のためには、ＴＯＩフィールドの構成情報が別に伝送されることができる。一実施例として、図示の表のようなＴＯＩ構成ディスクリプションがＴＯＩフィールドの構成についての情報を提供するために、送信及び／又は受信されることができる。この実施例においては、ＴＣＤ（ＴＯＩ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）は一つの伝送セッションにあたる伝送パケットのＴＯＩフィールド構成情報を提供する。ＴＣＤはシグナリングを伝送するセッションの内部及び／又は外部手段を介して伝送されることができる。ＴＣＤがシグナリングを伝送するセッションの内部手段を介して伝送される場合、固有のＴＯＩ値、一例として０又は０ｘＦＦＦＦなどの値によって識別して、一緒に伝送される他のシグナリングメッセージに先立って解釈されることができる。ＴＣＤがシグナリングを伝送するセッションの外部手段を介して伝送される場合、該当のセッションで伝達されるオブジェクトに先立ち、ＦＩＣ、別個のＩＰデータグラム及び／又は他のＲＯＵＴＥセッションなどの手段を介して伝送されるので、各パケットに含まれたＴＯＩフィールドの構成情報を受信機で予め分かるように処理することができる。＠ｔｙｐｅＢｉｔｓフィールド以下のフィールドはＴＯＩ内のそれぞれのフィールド長を示し、ＴＯＩ開始ｂｉｔから順にそれぞれの長さにあたるフィールド情報が記述されることを知らせる。
【０９３３】
本発明の一実施例によるＴＣＤは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ｄａｔａＶｅｒｓｉｏｎ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、＠ｔｙｐｅＢｉｔｓ情報、＠ｖｅｒｓｉｏｎＢｉｔｓ情報、＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報、＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報、＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報を含むことができる。
【０９３４】
＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報はＴＣＤのバージョンを識別する。＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報はＴＣＤのプロトコル又は構造に変更がある場合、これを識別する。
【０９３５】
＠ｄａｔａＶｅｒｓｉｏｎ情報はＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）のバージョンを識別する。＠ｄａｔａＶｅｒｓｉｏｎ情報は、ＴＣＤに含まれる内容が変更される場合、これを識別する。
【０９３６】
＠ｖａｌｉｄＦｒｏｍ情報はＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）の可用開始時点を示すことができる。受信機は＠ｖａｌｉｄＦｒｏｍ情報を用いてＴＣＤの可用開始時点を認知することができ、該当の時点からＴＣＤの情報を使うことができる。
【０９３７】
＠ｅｘｐｉｒａｔｉｏｎ情報はＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）の可用完了時点を示すことができる。受信機は＠ｅｘｐｉｒａｔｉｏｎ情報を用いてＴＣＤの可用完了時点を認知することができ、ＴＣＤの情報の使用を終了させることができる。受信機は＠ｅｘｐｉｒａｔｉｏｎ情報を用いて、ＴＣＤ情報を管理することができる。
【０９３８】
＠ｔｙｐｅＢｉｔｓ情報はＴＯＩフィールド内のｔｙｐｅフィールドの長さを示す。＠ｔｙｐｅＢｉｔｓ情報はｔｙｐｅフィールドの長さをビットで表現することができる。
【０９３９】
＠ｖｅｒｓｉｏｎＢｉｔｓ情報はＴＯＩフィールド内ｖｅｒｓｉｏｎフィールドの長さを示す。＠ｖｅｒｓｉｏｎＢｉｔｓ情報はｖｅｒｓｉｏｎフィールドの長さをビットで表現することができる。
【０９４０】
＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報はＴＯＩフィールド内ｉｎｓｔａｎｃｅＩＤフィールドの長さをビット数で示すことができる。
【０９４１】
＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報はＴＯＩフィールド内ｖａｌｉｄＦｒｏｍフィールドの長さをビット数で示すことができる。
【０９４２】
＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報はＴＯＩフィールド内ｅｘｐｉｒａｔｉｏｎフィールドの長さをビット数で示すことができる。
【０９４３】
＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報はＴＯＩフィールド内ｐａｙｌｏａｄＦｏｒｍａｔフィールドの長さをビット数で示すことができる。
【０９４４】
図９５は本発明の一実施例による、伝送パケットのペイロード（Ｐａｙｌｏａｄ）フォーマット（Ｆｏｒｍａｔ）エレメントを示した図である。
【０９４５】
本発明の一実施例によると、伝送パケットのペイロードを介してシグナリングメッセージを伝送することができる。このために、伝送パケットは図示のようなペイロードフォーマットエレメントを含むことができる。伝送パケット放送データを含むオブジェクトを伝送するパケットに当たる。本発明の伝送パケットが該当のパケットが処理されるプロトコルによってその名称が変わることができる。例えば、ＲＯＵＴＥを介してパケットが処理されれば、ＲＯＵＴＥパケットと言える。
【０９４６】
ペイロードフォーマットエレメントは、前述したようにＬＳＩＤに含まれることができる。
【０９４７】
本発明の伝送パケットのペイロードフォーマットエレメントは、＠Ｃｏｄｅｐｏｉｎｔ情報、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報、＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報、＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報、＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報及び／又はＴＣＩＤ（ＴＯＩ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）を含むことができる。
【０９４８】
＠Ｃｏｄｅｐｏｉｎｔ情報はこのペイロードのために使われるＣｏｄｅ ｐｏｉｎｔが何であるかを定義する。この情報は前述したＣＰエレメントと同様な役目をするか、同一値を有することができる。
【０９４９】
＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報はデータの送信のためのオブジェクトのペイロードのフォーマットを識別する。例えば、この情報はオブジェクトがシグナリングメッセージを伝送するか、ファイルを伝送するか、Ｅｎｔｉｔｙを伝送するか、Ｐａｃｋａｇｅを伝送するか、あるいは初期化セグメントを含むメタデータを送信していることを示すことができる。
【０９５０】
＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報はフラグメンテーション（Ｆｒａｇｍｅｎｔａｔｉｏｎ）のタイプを識別する。
【０９５１】
＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報はオブジェクトの伝送手順を識別する。例えば、この情報は現在ペイロードを介して伝送されるオブジェクトの手順を識別するのに使われることができる。
【０９５２】
＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報はソースＦＥＣペイロードＩＤ（Ｓｏｕｒｃｅ ＦＥＣ Ｐａｙｌｏａｄ ＩＤ）のフォーマットを定義することができる。
【０９５３】
ＴＣＩＤはＴＯＩフィールドの一部を可変長のシグナリングメッセージ関連情報の記述のために使用する場合、ＴＯＩフィールドの構成情報を含むことができる。
【０９５４】
図９６は本発明の一実施例による、ＴＯＩ構成インスタンスディスクリプション（ＴＯＩ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＩＤ）を示した図である。
【０９５５】
ＴＯＩフィールドの一部を可変長のシグナリングメッセージ関連情報の記述のために使い、一つの伝送セッション内でＴＯＩフィールドの構成が動的に変わることができる。
【０９５６】
可変長のＴＯＩフィールド内シグナリングメッセージ関連情報の記述のためには、ＴＯＩフィールド構成情報が別に伝送されることができ、このようなＴＯＩフィールド構成情報は、図示の形態で伝送されることができる。
【０９５７】
この実施例において、ＴＣＩＤは一つのＣｏｄｅｐｏｉｎｔ値にマッピングされるパケットグループにあたる伝送パケットのＴＯＩフィールド構成情報を提供する。ＴＣＩＤはＬＳＩＤのＳｏｕｒｃｅＦｌｏｗ内のＰａｙｌｏａｄＦｏｒｍａｔに含まれて伝送されることができる。ＴＣＩＤの内部フィールドは前述したＴＣＤと同様であってもよく、ＰａｙｌｏａｄＦｏｒｍａｔに一緒に含まれた＠Ｃｏｄｅｐｏｉｎｔと同一の値のＣＰ値を有するパケットのＴＯＩ構成を示すことができる。ＴＯＩの構成方法は前述したＴＣＤでの方法と同様であり得る。
【０９５８】
本発明の一実施例によるＴＣＩＤは、＠ｔｙｐｅＢｉｔｓ情報、＠ｖｅｒｓｉｏｎＢｉｔｓ情報、＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報、＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報、＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報を含むことができる。この情報についての説明は、同一名称を有する前述した情報についての説明に取り替える。
【０９５９】
図９７は本発明の一実施例によるＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）のペイロードのシンタックス（ｓｙｎｔａｘ）を示した図である。
【０９６０】
本発明では、サービスをスキャンするかサービスを獲得するための情報を含むシグナリングデータをＦＩＣというが、その名称に限定されなく、サービス階層（又はレベル）の下位階層で、より効果的に放送サービスを獲得するための情報を提供するシグナリングデータについて説明しようとする。一例として、このようなシグナリングデータはサービスリストテーブル、又はサービスリストエレメントなどの他の名称と呼ばれることができる。
【０９６１】
また、本発明では、説明の便宜のために、シグナリングデータの構造をｂｉｎａｒｙ形態のテーブルに示したが、該当のテーブルに属する同一乃至類似の情報は、ＸＭＬ形態に具現されることができる。
【０９６２】
本発明の一実施例によるＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓ情報、ｐａｒｔｉｔｉｏｎ＿ｉｄ情報、ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ＩＤ情報、ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報、ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報、及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントを含むことができる。
【０９６３】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報はＦＩＣの構造のバージョンを識別する情報である。
【０９６４】
ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ情報は放送ストリームを識別する情報である。全体放送ストリームを識別する情報に当たることができる。
【０９６５】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓ情報は放送ストリーム内でのパーティション（ｐａｒｔｉｔｉｏｎ）の数を示す情報である。一つの放送ストリームは一つ以上のパーティションに分けられることができ、それぞれのパーティションは、一つの放送社（又は放送ソース）によって使われる一つ以上のデータパイプ（ｄａｔａ ｐｉｐｅ）を含むことができる。
【０９６６】
ｐａｒｔｉｔｉｏｎ＿ｉｄ情報はパーティションを識別する情報である。
【０９６７】
ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報はパーティションの構造のバージョンを識別する情報である。
【０９６８】
ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報はパーティションを介して一つ以上のコンポーネントが伝送される放送サービスの数を示す。
【０９６９】
ｓｅｒｖｉｃｅ＿ｉｄ情報はサービス（又は放送サービス）を識別する情報である。
【０９７０】
ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報はＦＩＣによってシグナリングされるサービスのためのサービスエントリー（ｅｎｔｒｙ）に変更がある場合、この変更を識別する情報である。あるいは、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報はサービスシグナリングチャネル（又はサービスレベルシグナリング）に含まれる、サービスのためのシグナリングテーブルに変更がある場合、これを識別する情報である。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は該当の変更がある都度、その値を増加させて、変更があることを示すことができる。
【０９７１】
ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報はサービスのためのチャネル番号を示す。
【０９７２】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報はサービスのカテゴリーを示す。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は放送サービスがＡ／Ｖサービス、オーディオサービス、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）、Ａｐｐ ｂａｓｅｄ ｓｅｒｖｉｃｅ及び／又はＣｏＤ（Ｃｏｎｔｅｎｔ ｏｎ Ｄｅｍａｎｄ）であることを示すことができる。
【０９７３】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報の長さを示す。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が存在しない場合、‘０’の値を有することができる。
【０９７４】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報はサービスのＳｈｏｒｔ Ｎａｍｅを示す。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が示す各文字はＵＴＦ−８によってエンコードされることができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が奇数のバイト長を有する場合、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報によって識別される各カウントペア（ｐａｉｒ）のバイトペアの最後の二番目バイトは０ｘ００の値を有することができる。（Ｔｈｅ ｓｈｏｒｔ ｎａｍｅ ｏｆ ｔｈｅ Ｓｅｒｖｉｃｅ、ｅａｃｈ ｃｈａｒａｃｔｅｒ ｏｆ ｗｈｉｃｈ ｓｈａｌｌ ｂｅｅｎ ｃｏｄｅｄ ｐｅｒ ＵＴＦ−８［］。 Ｗｈｅｎ ｔｈｅｒｅ ｉｓ ａｎ ｏｄｄ ｎｕｍｂｅｒ ｏｆ ｂｙｔｅｓ ｉｎ ｔｈｅ ｓｈｏｒｔ ｎａｍｅ、 ｔｈｅ ｓｅｃｏｎｄ ｂｙｔｅ ｏｆ ｔｈｅ ｌａｓｔ ｏｆ ｔｈｅ ｂｙｔｅ ｐａｉｒ ｐｅｒ ｔｈｅ ｐａｉｒ ｃｏｕｎｔ ｉｎｄｉｃａｔｅｄ ｂｙ ｔｈｅ ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｆｉｅｌｄ ｓｈａｌｌ ｃｏｎｔａｉｎ ０ｘ００。）
【０９７５】
ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報はサービスの状態を示す。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は放送サービスがａｃｔｉｖｅ、ｉｎａｃｔｉｖｅ、ｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ、及び／又はｓｈｏｗｎ状態であることを示すことができる。
【０９７６】
ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報は放送サービス又は放送コンテンツの表出（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）が、現在パーティションのみで可能であるか、現在パーティションのみでは不可能であるが現在パーティションが必要であるか、他のパーティションが必要であるか、あるいは他の放送ストリームが必要であるかを識別する。
【０９７７】
ｓｐ＿ｉｎｄｉｃａｔｏｒ情報はサービス保護が適用されたかを示す。ｓｐ＿ｉｎｄｉｃａｔｏｒ情報は、意味ある表出のために必要な、放送サービスの一つ以上のコンポーネントに対し、ｐｒｏｔｅｃｔｉｏｎされたかを識別する。
【０９７８】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報は、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報及び／又はＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報が示すＩＰアドレスがＩＰｖ４アドレスであるか、あるいはＩＰｖ６アドレスであるかを識別する。
【０９７９】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報は、サービスのために、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報が存在するかを識別する情報である。
【０９８０】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報の値が‘１’にセットされた場合には存在するが、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報の値が‘０’にセットされた場合には存在しない。ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報はサービスのためのシグナリング情報を伝送するＩＰデータグラム（又はデータユニット）のソースＩＰアドレスを示す。ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＩＰｖ６のアドレスが使われる場合、１２８ビットを有することができる。
【０９８１】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報はサービスのためのシグナリング情報を伝送するＩＰデータグラム（又はデータユニット）のデスティネーションＩＰアドレスを示す。ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＩＰｖ６のアドレスが使われる場合、１２８ビットを有することができる。
【０９８２】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ情報はサービスのためのシグナリング情報を伝送するＵＤＰ／ＩＰストリームのためのデスティネーションＵＤＰポート番号を示す。
【０９８３】
ＳＳＣ＿ＴＳＩ情報はサービスのためのシグナリング情報（又はシグナリングテーブル）を伝送するＬＣＴチャネルのＴＳＩ（Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）を示す。
【０９８４】
ＳＳＣ＿ＤＰ＿ＩＤ情報はサービスのためのシグナリング情報（又はシグナリングテーブル）を含むデータパイプ（ＤＰ；Ｄａｔａ ｐｉｐｅ）を識別する情報である。シグナリング情報を伝送するデータパイプは、現在パーティション又は放送ストリーム内で一番堅固なデータパイプに当たることができる。
【０９８５】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報はパーティションのために定義されるパーティションレベルディスクリプションの数を示す。
【０９８６】
ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは一つ以上のパーティションレベルディスクリプタを含む。パーティションレベルディスクリプタは受信機でパーティションに近付くか、パーティションを獲得するか、パーティションを用いるために必要な情報を含むことができる。
【０９８７】
ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報はＦＩＣのために定義されるＦＩＣレベルディスクリプションの数を示す。
【０９８８】
ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは一つ以上のＦＩＣレベルディスクリプタを含む。ＦＩＣレベルディスクリプタはＦＩＣのための更なるシグナリング情報を含むことができる。
【０９８９】
図９８は本発明の他の実施例による、ＦＩＣのペイロードのシンタックス（ｓｙｎｔａｘ）を示した図である。
【０９９０】
本発明の他の実施例による、ＦＩＣのペイロードは、前述した実施例のＦＩＣのペイロードにＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報、ＳＳＣ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、及び／又はＳＳＣ＿ＵＲＬ＿ｄａｔａ情報をさらに含むことができる。
【０９９１】
ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報はサービスに係わるシグナリング情報（例えば、サービスシグナリングチャネル又はサービスレベルシグナリング）が伝達される経路を識別する情報である。ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報はサービスレベルシグナリングのデータがブロードバンド（インターネット）を介して伝送されるかを識別することができる。一例として、ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、その値が０ｘ０１を有するとき、放送ネットワークを介してサービスレベルシグナリングが伝送されることを示すことができる。ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、その値が０ｘ０２を有するとき、インターネットを介してサービスレベルシグナリングが伝送されることを示すことができる。
【０９９２】
ＳＳＣ＿ＵＲＬ＿ｌｅｎｇｔｈ情報はＳＳＣ＿ＵＲＬ＿ｄａｔａ情報の長さを示す。
【０９９３】
ＳＳＣ＿ＵＲＬ＿ｄａｔａ情報はサービスに係わるシグナリング情報を提供するサービス又は位置のＵＲＬを示す。
【０９９４】
この実施例で説明されなっかた他の情報についての説明は、前述した説明に取り替える。
【０９９５】
図９９は本発明の他の実施例によるサービスレベルシグナリングのシンタックス（ｓｙｎｔａｘ）を示した図である。
【０９９６】
受信機において、視聴者が所望の放送サービス及び／又は放送コンテンツを受信するために必要な情報をサービスレベルシグナリングと言える。サービスレベルシグナリングは、放送サービス及び放送サービスに含まれるコンポーネントに対する属性を説明する情報を含む。
【０９９７】
本発明の他の実施例による、サービスレベルシグナリングデータは、シグナリングメッセージヘッダー（ｈｅａｄｅｒ）及び／又はサービスシグナリングメッセージを含むことができる。
【０９９８】
本発明の他の実施例による、サービスレベルシグナリングデータは、＠ｓｅｒｖｉｃｅ＿ｉｄ情報、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、＠ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報、＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報、ＲＯＵＴＥＳｅｓｓｉｏｎエレメント、＠ｓｏｕｒｃｅＩＰＡｄｄｒ情報、＠ｄｅｓｔＩＰＡｄｄｒ情報、＠ｄｅｓｔＵＤＰＰｏｒｔ情報、＠ＬＳＩＤ＿ＤＰ情報、Ｔａｒｇｅｔｉｎｇエレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙエレメント、ＲｉｇｈｔＩｓｓｕｅｒＳｅｒｖｉｃｅエレメント、ＣｕｒｒｅｎｔＰｒｏｇｒａｍエレメント、ＯｒｉｇｉｎａｌＳｅｒｖｉｃｅＩｄｅｎｔｉｆｉｃａｔｉｏｎエレメント、ＣｏｎｔｅｎｔＬａｂｅｌｉｎｇエレメント、Ｇｅｎｒｅエレメント、Ｃａｐｔｉｏｎエレメント、及び／又はＰｒｏｔｅｃｔｉｏｎエレメントを含むことができる。
【０９９９】
＠ｓｅｒｖｉｃｅ＿ｉｄ情報は放送サービスを識別する情報である。
【１０００】
＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は放送サービスのカテゴリーを識別する情報である。例えば、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は放送サービスが、オーディオサービス、実時間放送サービス、非実時間放送サービス、ｌｉｎｅａｒ放送サービス、ａｐｐ−ｂａｓｅｄ放送サービスあるいはサービスガイドであることを識別することができる。
【１００１】
＠ｓｅｒｖｉｃｅ＿ｎａｍｅ情報は放送サービスの名称を示す。
【１００２】
＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報は放送サービスを伝送するチャネル番号を示す。このチャネル番号は、論理的／物理的チャネル番号に当たることができる。場合によって、このチャネル番号は、サービスレベルシグナリングのデータを伝送する論理的伝送経路又は伝送ユニットを識別する情報として使われることができる。
【１００３】
＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は放送サービスの状態を示す。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は放送サービスがアクティブ（ａｃｔｉｖｅ）であるか、あるいはインアクティブ（ｉｎａｃｔｉｖｅ）であるかを識別する情報を含むことができる。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は放送サービスがヒドン（ｈｉｄｄｅｎ）状態であるかを識別する情報を含むことができる。
【１００４】
＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報は放送サービスのためのデータ又はコンポーネントがどのように分配されて伝送されるかを示す情報である。
【１００５】
＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報は、放送サービス又は放送サービスに含まれる少なくとも一つのコンポーネントに対してサービスプロテクション（ｐｒｏｔｅｃｔｉｏｎ）が適用されたかを識別する情報である。＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報は放送サービスの意味ある表出のためのデータ単位又はコンポーネントにサービスプロテクションが適用されたかを識別する情報に当たることができる。
【１００６】
ＲＯＵＴＥ Ｓｅｓｓｉｏｎエレメントは放送サービス又は放送サービスに含まれるコンポーネントを伝送するＲＯＵＴＥセッションについての情報を含むエレメントである。
【１００７】
＠ｓｏｕｒｃｅＩＰＡｄｄｒ情報はＲＯＵＴＥパケット伝送するＩＰデータグラム（あるいはデータユニット）のソース（ｓｏｕｒｃｅ）ＩＰアドレスを示す。
【１００８】
＠ｄｅｓｔＩＰＡｄｄｒ情報はＲＯＵＴＥパケット伝送するＩＰデータグラム（あるいはデータユニット）のデスティネーション（ｄｅｓｔｉｎａｔｉｏｎ）ＩＰアドレスを示す。
【１００９】
＠ｄｅｓｔＵＤＰＰｏｒｔ情報はＲＯＵＴＥパケット伝送するＩＰデータグラム（あるいはデータユニット）のデスティネーションポート（ｐｏｒｔ）番号を示す。
【１０１０】
＠ＬＳＩＤ＿ＤＰ情報はＲＯＵＴＥセッションに係わる伝送パラメータ及び／又はＲＯＵＴＥセッション内の下位セッションを説明する情報（例えば、ＬＳＩＤ）を伝達するデータパイプを識別する情報である。
【１０１１】
Ｔａｒｇｅｔｉｎｇエレメントは個人化された放送サービス（タゲッティング放送）提供のための情報を含むエレメントである。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。
【１０１２】
Ｃｏｎｔｅｎｔ Ａｄｖｉｓｏｒｙエレメントは放送サービスに対する視聴等級についての情報を含むエレメントである。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。Ｒｉｇｈｔ Ｉｓｓｕｅｒ Ｓｅｒｖｉｃｅエレメントは放送サービスを適切に消費するための権限についての情報を含むエレメントである。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。
【１０１３】
Ｃｕｒｒｅｎｔ Ｐｒｏｇｒａｍエレメントは現在放送プログラムについての情報を含むエレメントである。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。
【１０１４】
Ｏｒｉｇｉｎａｌ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎエレメントは現在放送サービスに係わる元のサービスを識別することについての情報を含むエレメントである。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。
【１０１５】
ＣｏｎｔｅｎｔＬａｂｅｌｉｎｇエレメントはコンテンツレベリング（ｃｏｎｔｅｎｔ ｌａｂｅｌｉｎｇ）についての情報を含むエレメントである。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。Ｇｅｎｒｅエレメントは放送サービスのジャンルを区分するための情報を含む情報である。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。
【１０１６】
Ｃａｐｔｉｏｎエレメントは放送サービスのｃｌｏｓｅｄ ｃａｐｔｉｏｎ／ｓｕｂｔｉｔｌｅについての情報を含むエレメントである。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。
【１０１７】
Ｐｒｏｔｅｃｔｉｏｎエレメントは放送サービスに対するプロテクション（ｐｒｏｔｅｃｔｉｏｎ）関連情報を含むエレメントである。Ｐｒｏｔｅｃｔｉｏｎエレメントは前述した＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報が、放送サービス又は放送コンポーネントに対してプロテクションが適用された場合、このプロテクションに係わる詳細情報を提供することができる。このエレメントは別個のシグナリング構造としてサービスレベルシグナリングに含まれることができる。この場合、該当のサービスレベルシグナリングに対するリンク情報を含むことができる。
【１０１８】
図１００は本発明の他の実施例による、コンポーネントマッピングディスクリプション（ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ）を示した図である。
【１０１９】
本発明の他の実施例による、コンポーネントマッピングディスクリプションは、前述した実施例によるコンポーネントマッピングディスクリプションに含まれる情報又はエレメントに加え、＠ｐａｒｔｉｔｉｏｎＩＤ情報をさらに含むことができる。
【１０２０】
＠ｐａｒｔｉｔｉｏｎＩＤ情報は放送ストリーム上で放送局を示すｐａｒｔｉｔｉｏｎを識別する情報である。＠ｐａｒｔｉｔｉｏｎＩＤ情報は放送コンポーネントを伝送する出処を識別する情報として使われることができる。
【１０２１】
コンポーネントマッピングディスクリプションに含まれる他の情報又はエレメントについての説明は、同一名称を有する情報又はエレメントについては、前述した説明に取り替える。
【１０２２】
図１０１は本発明の他の実施例による、ＵＲＬシグナリングディスクリプション（ＵＲＬ ｓｉｇｎａｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ）のシンタックス（ｓｙｎｔａｘ）を示した図である。
【１０２３】
前述したように、放送サービスを説明するシグナリング情報は放送ネットワークだけでなく、ブロードバンドネットワークを介して伝送されることができる。放送サービスを説明するシグナリング情報がブロードバンドネットワークを介して伝送される場合、受信機はＵＲＬシグナリングディスクリプションを介して、該当のシグナリング情報を獲得することができる。
【１０２４】
本発明の他の実施例による、ＵＲＬシグナリングディスクリプションは、＠ｓｅｒｖｉｃｅ＿ｉｄ情報、＠ｓｍｔＵＲＬ情報、＠ｍｐｄＵＲＬ情報、＠ｃｍｔＵＲＬ情報、＠ａｓｔＵＲＬ情報、＠ｇａｔＵＲＬ情報、及び／又は＠ｅａｔＵＲＬ情報を含むことができる。
【１０２５】
＠ｓｅｒｖｉｃｅ＿ｉｄ情報はサービスを識別する情報である。
【１０２６】
＠ｓｍｔＵＲＬ情報は、ブロードバンドを介してＳＭＴ（Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ）が伝送される場合、ＳＭＴを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０２７】
＠ｍｐｄＵＲＬ情報は、ブロードバンドを介してＭＰＤが伝送される場合、ＭＰＤを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０２８】
＠ｃｍｔＵＲＬ情報は、ブロードバンドを介してＣＭＴ（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ）が伝送される場合、ＣＭＴを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０２９】
＠ａｓｔＵＲＬ情報は、ブロードバンドを介してＡＳＴ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｉｇｎａｌｉｎｇ Ｔａｌｂｅ）が伝送される場合、ＡＳＴを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０３０】
＠ｇａｔＵＲＬ情報は、ブロードバンドを介してＧＡＴ（Ｇｕｉｄｅ Ａｃｃｅｓｓ Ｔａｂｌｅ）が伝送される場合、ＧＡＴを提供するサーバー又は位置のＵＲＬを示す情報である。ＧＡＴはＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）のブートストラップ（ｂｏｏｔｓｔｒａｐ）のための情報を含むシグナリングメッセージに当たることができる。すなわち、ＧＡＴは受信機がＥＳＧに近付くために必要な情報を含むシグナリングメッセージに当たることができる。
【１０３１】
＠ｅａｔＵＲＬ情報は、ブロードバンドを介してＥＡＴ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｔａｂｌｅ）が伝送される場合、ＥＡＴを提供するサーバー又は位置のＵＲＬを示す情報である。ＥＡＴは非常警報関連情報と非常警報メッセージを含むシグナリングメッセージに当たることができる。
【１０３２】
図１０２は本発明の他の実施例による、ＳｏｕｒｃｅＦｌｏｗエレメントを示した図である。
【１０３３】
放送サービスのデータはＲＯＵＴＥセッションを介して、オブジェクト（Ｏｂｊｅｃｔ）単位で伝送されることができる。それぞれのオブジェクトは個別的に復元されることができる。一セッション内で、オブジェクトを伝送するためにｓｏｕｒｃｅプロトコルを定義することができ、ｓｏｕｒｃｅプロトコル内のｓｏｕｒｃｅ（ｏｂｊｅｃｔ）の伝達についての情報を含むＳｏｕｒｃｅＦｌｏｗエレメントを定義することができる。
【１０３４】
本発明の他の実施例による、ＳｏｕｒｃｅＦｌｏｗエレメントは前述したＳｏｕｒｃｅＦｌｏｗエレメントに含まれる情報／属性／エレメントの外に、＠ｌｏｃａｔｉｏｎ情報をさらに含むことができる。
【１０３５】
＠ｌｏｃａｔｉｏｎ情報はＳｏｕｒｃｅ Ｆｌｏｗのデータを伝送する位置又はデータユニットを示す情報である。＠ｌｏｃａｔｉｏｎ情報は放送ストリーム内でデータパイプを識別し、受信機は該当のデータパイプを介してＳｏｕｒｃｅ Ｆｌｏｗのデータが伝送されることが分かる。
【１０３６】
ＳｏｕｒｃｅＦｌｏｗエレメントに含まれる他の情報／属性／エレメントについての説明は、前述したＳｏｕｒｃｅＦｌｏｗエレメントについての説明に取り替える。
【１０３７】
図１０３は本発明の他の実施例による、シグナリング情報を放送ネットワークを介して獲得する過程を示した図である。
【１０３８】
受信機は、ＦＩＣに含まれるサービスを識別する情報を用いて、受信機が所望の放送サービスに係わるサービスシグナリングチャネルのデータが伝送される位置に近付くことができる。
【１０３９】
受信機は、ＦＩＣで、サービスシグナリングチャネルのデータを伝送するＩＰデータグラムのソースＩＰアドレス、デスティネーションＩＰアドレス及び／又はＵＤＰポート番号についての情報を獲得する。
【１０４０】
受信機は、ＦＩＣで、サービスシグナリングチャネルのデータを含むデータパイプを識別する情報を獲得する。受信機は、該当の情報を介して、サービスシグナリングチャネルのデータが伝送されるデータパイプに近付くことができる。
【１０４１】
受信機は、ＦＩＣに含まれたサービスシグナリングチャネルのデータを伝送するＬＣＴセッションを識別する情報を用いて、該当のＬＣＴセッションに近付くことができる。あるいは、サービスシグナリングチャネルのデータを伝送するＬＣＴセッションは、特定のＴＳＩを有するＬＣＴセッションに固定されることができる。この場合、受信機は別個の情報なしにも、サービスシグナリングチャネルのデータを得るために、この特定のＴＳＩを有するＬＣＴセッションに近付くことができる。受信機は、該当の位置に近付いてサービスシグナリングチャネルのデータを獲得することができる。
【１０４２】
受信機は、前述したＬＳＩＤを伝送するＬＣＴセッションに近付くこともできる。この場合、ＬＳＩＤを伝送するＬＣＴセッションのＴＳＩは固定されることができ、受信機は該当のＴＳＩを有するＬＣＴセッションに近付いてＬＳＩＤを獲得することができる。受信機は、ＬＳＩＤの情報を用いて、放送サービスに含まれるコンポーネントを獲得することができる。
【１０４３】
図１０４は本発明の他の実施例によるシグナリング情報を放送ネットワークとブロードバンドネットワークを介して獲得する過程を示した図である。
【１０４４】
受信機は、ＦＩＣに含まれるサービスを識別する情報を用いて、受信機が所望の放送サービスに係わるサービスシグナリングチャネルのデータが伝送される位置に近付くことができる。
【１０４５】
受信機は、ＦＩＣで、サービスシグナリングチャネルのデータを伝送するＩＰデータグラムのソースＩＰアドレス、デスティネーションＩＰアドレス及び／又はＵＤＰポート番号についての情報を獲得する。
【１０４６】
受信機は、ＦＩＣで、サービスシグナリングチャネルのデータを含むデータパイプを識別する情報を獲得する。受信機は該当の情報を介して、サービスシグナリングチャネルのデータが伝送されるデータパイプに近付くことができる。
【１０４７】
受信機は、サービスシグナリングチャネルのデータに近付いて前述したＵＲＬシグナリングテーブル又はＵＲＬシグナリングディスクリプションを獲得する。受信機は、ＵＲＬシグナリングテーブルに含まれる情報を用いて、サービスレベルシグナリングを提供するサーバー又は位置に近付き、ブロードバンドネットワークを介してサービスレベルシグナリングを獲得することができる。
【１０４８】
図１０５は本発明の他の実施例によるシグナリング情報をブロードバンドネットワークを介して獲得する過程を示した図である。
【１０４９】
受信機は、ＦＩＣに含まれるサービスシグナリングチャネルの伝送タイプを識別する情報が、サービスシグナリングチャネルのデータがブロードバンドネットワークを介して伝送されることを示す場合、ＦＩＣ内でサービスシグナリングチャネルのデータを提供するサーバー又は位置についてのＵＲＬ情報を獲得する。この場合、ＵＲＬ情報はサービスシグナリングチャネルのデータ全体を提供する一つのサーバー又は位置に対するＵＲＬを示すか、あるいはサービスシグナリングチャネルに含まれることができるそれぞれのシグナリング構造（ＳＭＴ、ＭＰＤ、ＣＭＴなど）を提供するそれぞれのサーバー又は位置のＵＲＬを示すことができる。
【１０５０】
受信機は、該当のＵＲＬ情報が示すサーバー又は位置に近付き、ブロードバンドネットワークを介してサービスシグナリングチャネルのデータを獲得する。
【１０５１】
図１０６は本発明の他の実施例によるＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）を放送ネットワークを介して獲得する過程を示した図である。
【１０５２】
受信機は、ＦＩＣに含まれるサービスのカテゴリーを識別する情報から、放送サービスがＥＳＧに当たることを認識し、該当のサービスに対するサービスシグナリングチャネルのデータを伝送するデータパイプを識別する情報を獲得することができる。
【１０５３】
受信機は、識別されたデータパイプに近付き、該当のデータパイプに伝送されるＥＳＧのデータを獲得することができる。
【１０５４】
このような過程によって、ＥＳＧを放送サービスとして取り扱うが、一般的な放送サービスに近付くために複雑なシグナリング構造を解釈する必要がなくなって、ＥＳＧをより効率的に獲得することができる。
【１０５５】
図１０７は本発明の他の実施例による放送サービスのビデオセグメント及びオーディオセグメントを放送ネットワークを介して獲得する過程を示した図である。
【１０５６】
受信機は、サービスシグナリングチャネルのデータを獲得し、サービスシグナリングチャネルのデータに含まれる、放送サービスのコンポーネントを説明する情報を含むシグナリング構造（例えば、ＣＭＴ）を獲得する。
【１０５７】
該当のシグナリング構造で、受信機は、放送サービスのビデオコンポーネントを伝送するデータパイプを識別する情報を獲得し、該当の情報を用いて、データパイプに近付く。受信機は該当のデータパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を獲得する。
【１０５８】
受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのビデオコンポーネントを伝送するＬＣＴセッションに近付いてビデオコンポーネントを獲得する。
【１０５９】
受信機は、放送サービスのオーディオコンポーネントを伝送するデータパイプを識別する情報を獲得し、該当の情報を用いて、データパイプに近付く。受信機は、該当のデータパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を獲得する。
【１０６０】
受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのオーディオコンポーネントを伝送するＬＣＴセッションに近付いてオーディオコンポーネントを獲得する。
【１０６１】
本発明によると、前述したシグナリング構造によって、放送サービスに含まれるそれぞれのコンポーネントがそれぞれの伝送経路を介して伝送される場合にも、該当のコンポーネントを効率的に探して獲得することができる効果がある。また、送信端では、余裕がある領域を介して、自由に放送サービスのコンポーネントを伝送することができ、よって、より多い放送データを効率的に伝送することができる効果がある。
【１０６２】
図１０８は本発明の他の実施例による、放送サービスのビデオセグメントは放送ネットワークを介して獲得し、放送サービスのオーディオセグメントはブロードバンドネットワークを介して獲得する過程を示した図である。
【１０６３】
受信機は、サービスシグナリングチャネルのデータを獲得し、サービスシグナリングチャネルのデータに含まれる、放送サービスのコンポーネントを説明する情報は含むシグナリング構造（例えば、ＣＭＴ）を獲得する。
【１０６４】
該当のシグナリング構造で、受信機は、放送サービスのビデオコンポーネントを伝送するデータパイプを識別する情報を獲得し、該当の情報を用いて、データパイプに近付く。受信機は、該当のデータパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を獲得する。
【１０６５】
受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのビデオコンポーネントを伝送するＬＣＴセッションに近付いてビデオコンポーネントを獲得する。
【１０６６】
一方、受信機は、放送サービスのコンポーネントを説明する情報を含むシグナリング構造から、オーディオコンポーネントがブロードバンドを介して伝送されることを認識し、該当のオーディオコンポーネントを伝送するサーバー又は位置のアドレスを獲得する。あるいは、受信機は、ＭＰＤを用いて、該当のオーディオコンポーネントのセグメントを提供するアドレスを獲得し、該当のアドレスからオーディオコンポーネントのセグメントを獲得する。
【１０６７】
前述したシグナリング構造によって、本発明によると、異種ネットワークを介して、一つの放送サービスに属するコンポーネントがそれぞれ伝送される場合にも、該当の放送サービスのためのコンポーネントに効率的に近付くことができる効果がある。
【１０６８】
図１０９は本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒの構成を示した図である。
【１０６９】
本発明の一実施例はｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅの伝送及び／又はシグナリング方案を提供することができる。本発明の一実施例によるｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅは次世代放送システムから伝送されるコンテンツ及びサービスを受信機で同期化して消費することができるようにする基準時間を提供することができる。
【１０７０】
本発明の一実施例によるｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅは連続的で周期的なｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値を含むことができる。ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅはシグナリングメッセージ及び／又は独立したストリームの形態で伝送されることができる。ここで、前述したシグナリングメッセージはシグナリング情報と同一であることができ、前述したシグナリングメッセージはＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）、Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ（ＳＭＴ）などを含むことができる。ここで、前述したＦＩＣはＳｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ（ＳＬＴ）と同一であることができ、ＳＭＴはＵｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＤ）と同一であることができる。
【１０７１】
本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅが独立したストリームの形態で伝送される場合、受信機がｃｌｏｃｋ ｒｅｆｅｒｎｃｅに近付くための情報を提供することができる。後述する、本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅがシグナリングメッセージを介して直接伝送される場合、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値を提供することができる。
【１０７２】
本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅはｐｈｙｓｉｃａｌ ｌａｙｅｒに含まれて伝送されることができ、ｐｈｙｓｉｃａｌ ｆｒａｍｅのｐｒｅａｍｂｌｅ及び／又はｂａｓｅ ＰＬＰ部分に含まれて伝送されることができる。ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅは送信機と受信機の時間を同期化するために必要な情報であり、エラーを減らすために比較的堅固度の高いｐｈｙｓｉｃａｌ ｌａｙｅｒに含まれることができる。
【１０７３】
本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｂｉｎａｒｙ ｆｏｒｍａｔ、ＸＭＬなどの多様な形式で表現できる。本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒはシグナリングメッセージ内の多様な位置に存在することができる。ここで、前述したシグナリングメッセージはローレベルシグナリングメッセージ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）、サービスレベルシグナリングメッセージ（ｓｅｒｖｉｃｅ ｌｅｖｅｌ ｓｉｇｎａｌｉｎｇ）を含むことができる。ここで、前述したローレベルシグナリングメッセージはＳＬＴ、ＲＲＴ（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ）などを含むことができ、前述したサービスレベルシグナリングメッセージはＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）などを含むことができる。ここで、前述したＳＬＴはＦＩＣ及び／又はＰＡＴと同一であることができ、前述したＵＳＢＤ／ＵＳＤはＳＭＴと同一であることができる。
【１０７４】
本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＴＳＩ＿ｆｌａｇフィールド、ＤＰ＿ＩＤ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＴＳＩ＿ｆｌａｇフィールド、ＤＰ＿ＩＤ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＴＳＩフィールド及び／又はＤＰ＿ＩＤフィールドを含むことができる。
【１０７５】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは固有値が割り当てられることにより、該当のｄｅｓｃｒｉｐｔｏｒがｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒであることを識別することができる。
【１０７６】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは該当のｄｅｓｃｒｉｐｔｏｒの長さをバイト数で示すことができる。
【１０７７】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰ ａｄｄｒｅｓｓの形式を示すことができる。このフィールドの値が０である場合はＩＰｖ４アドレスフォーマットが、１である場合はＩＰｖ６アドレスフォーマットが使われることを示すことができる。
【１０７８】
ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドはこのディスクリプションがｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むかを示すことができる。このフィールドの値が１である場合、このディスクリプタはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むことができる。
【１０７９】
ＴＳＩ＿ｆｌａｇフィールドはこのディスクリプションがＴＳＩフィールドを含むかを示すことができる。このフィールドの値が１である場合、このディスクリプタはＴＳＩフィールドを含むことができる。
【１０８０】
ＤＰ＿ＩＤ＿ｆｌａｇフィールドはこのディスクリプションがＤＰ＿ＩＤフィールドを含むかを示すことができる。このフィールドの値が１である場合、このディスクリプションはＤＰ＿ＩＤフィールドを含むことができる。
【１０８１】
ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ここで、前述したｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍは、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅが独立したストリームとして伝送される場合、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームを示すことができる。
【１０８２】
ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。
【１０８３】
ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。
【１０８４】
ＴＳＩフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＬＣＴ ｓｅｓｓｉｏｎなどのｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒを示すことができる。
【１０８５】
ＤＰ＿ＩＤフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍが伝送されるｄａｔａ ｐｉｐｅのｉｄｅｎｔｉｆｉｅｒを示すことができる。ここで、ｄａｔａ ｐｉｐｅはｐｈｙｓｉｃａｌ ｌａｙｅｒｐｉｐｅと同一であることができる。
【１０８６】
図１１０は本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの構成を示した図である。
【１０８７】
本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅがシグナリングメッセージを介して直接伝送される場合、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値を提供することができる。
【１０８８】
本発明の一実施例によるｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールド及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを含むことができる。
【１０８９】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは固有値が割り当てられることにより、該当のｄｅｓｃｒｉｐｔｏｒがｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒであることを識別することができる。
【１０９０】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは該当のｄｅｓｃｒｉｐｔｏｒの長さをバイト数で示すことができる。
【１０９１】
ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドは後続のｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドの形式を示すことができる。本発明の一実施例によると、このフィールドの値が０である場合は３２ビットのＮＴＰ ｔｉｍｅｓｔａｍｐ、１である場合は６４ビットのＮＴＰ ｔｉｍｅｓｔａｍｐ、２である場合は８０ビットのＰＴＰ ｔｉｍｅｓｔａｍｐが使われることができる。
【１０９２】
ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドは前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドによって決定されたｔｉｍｅｓｔａｍｐ形式で表現されるｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅの値を示すことができる。本発明の一実施例によると、このフィールドは送信端の現在時間、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの生成時間などを示すことができる。本発明の一実施例によると、このフィールドは送信端と受信端のｓｙｓｔｅｍ ｃｌｏｃｋ同期化に使われることができる。
【１０９３】
図１１１は本発明の一実施例によるＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）の構成を示した図である。
【１０９４】
本発明の一実施例によると、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒはｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌ ｌｅｖｅｌ、ｐａｒｔｉｔｉｏｎ ｌｅｖｅｌ及び／又はｓｅｒｖｉｃｅ ｌｅｖｅｌで伝送されることができる。
【１０９５】
本発明の一実施例によると、一つのｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌを介して一つのｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、前述したｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌを介して伝送される全てのコンテンツ及びサービスがこのｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを介して同期化されることができる。
【１０９６】
本発明の一実施例によると、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは前述したＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分に位置することができる。すなわち、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒはｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌ ｌｅｖｅｌで伝送されることができる。本発明の一実施例によると、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅはストリーム形態で伝送され、受信機はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたｂｏｏｔｓｔｒａｐ情報によってｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅが伝送される該当のストリームに近付くことができる。本発明の一実施例によると、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ＦＩＣを介してｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値が直接伝送されることができる。本発明の他の一実施例によると、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒに代わってｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値そのものが位置することができる。
【１０９７】
本発明の他の一実施例によると、一つのｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌは多数のｐａｒｔｉｔｉｏｎに分けられることができ、分けられた一つのｐａｒｔｉｔｉｏｎは一つのｂｒｏａｄｃａｓｔｅｒに割り当てられることができる。本発明の一実施例によると、一つのｐａｒｔｉｔｉｏｎを介して一つのｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、前述したｐａｒｔｉｔｉｏｎ内の全てのコンテンツ及びサービスがこのｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを介して同期化されることができる。
【１０９８】
本発明の一実施例によると、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは前述したＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分に位置することができる。すなわち、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒはｐａｒｔｉｔｉｏｎ ｌｅｖｅｌで伝送されることができる。本発明の一実施例によると、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅはストリーム形態で伝送され、受信機はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたｂｏｏｔｓｔｒａｐ情報によってｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅが伝送される該当のストリームに近付くことができる。本発明の一実施例によると、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ＦＩＣを介してｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値が直接伝送されることができる。本発明の他の一実施例によると、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒに代わってｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値そのものが位置することができる。
【１０９９】
本発明の一実施例によるＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）は、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールド、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒを含むことができる。
【１１００】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはＦＩＣのバージョンを示すことができる。
【１１０１】
ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドはｂｒｏａｄｃａｓｔ ｓｔｒｅａｍを識別することができる。
【１１０２】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ内に含まれたｐａｒｔｉｔｉｏｎの数を示すことができる。ここで、ｐａｒｔｉｔｉｏｎは放送局を示すことができる。
【１１０３】
ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドはｐａｒｔｉｔｉｏｎを識別することができる。
【１１０４】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはｐａｒｔｉｔｉｏｎレベルに含まれるディスクリプタの数を示すことができる。
【１１０５】
ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒはｐａｒｔｉｔｉｏｎレベルに含まれるディスクリプタを示すことができる。本発明の一実施例によると、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒがこのディスクリプタに含まれることができる。
【１１０６】
ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌレベルに含まれるディスクリプタの数を示すことができる。ここで、ｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌレベルはＦＩＣ及び／又はｂｒｏａｄｃａｓｔ ｓｔｒｅａｍレベルと同一であることができる。
【１１０７】
ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒはｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌレベルに含まれるディスクリプタを示すことができる。本発明の一実施例によると、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒがこのディスクリプタに含まれることができる。
【１１０８】
図１１２は本発明の他の一実施例によるＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）の構成を示した図である。
【１１０９】
本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅがｐａｒｔｉｔｉｏｎ ｌｅｖｅｌでストリーム形態で伝送される場合、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを一つのサービスに割り当てて、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームに近付く情報をシグナリングすることができる。
【１１１０】
本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームはｐａｒｔｉｔｉｏｎを構成する一つのサービスを介して伝送されることができる。本発明の一実施例によると、サービスがｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームを伝送するかどうかはｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドを介してシグナリングすることができ、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドにｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームのための特定の値が割り当てられることができる。本発明の一実施例によって、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドを介して該当のサービスがｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームを伝送するサービスであることが識別されれば、後続のＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＳＣ＿ＴＳＩフィールド及び／又はＳＳＣ＿ＤＰ＿ＩＤフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームに近付くためのｂｏｏｔｓｔｒａｐ情報として活用できる。
【１１１１】
本発明の一実施例によるＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）は、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールド、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＳＣ＿ＴＳＩフィールド及び／又はＳＳＣ＿ＤＰ＿ＩＤフィールドを含むことができる。
【１１１２】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドはＦＩＣのバージョンを示すことができる。
【１１１３】
ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドはｂｒｏａｄｃａｓｔ ｓｔｒｅａｍを識別することができる。
【１１１４】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドはｂｒｏａｄｃａｓｔ ｓｔｒｅａｍ内に含まれたｐａｒｔｉｔｉｏｎの数を示すことができる。ここで、ｐａｒｔｉｔｉｏｎは放送局を示すことができる。
【１１１５】
ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドはｐａｒｔｉｔｉｏｎを識別することができる。
【１１１６】
ｓｅｒｖｉｃｅ＿ｉｄフィールドはこのサービスがｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームを含むサービスであることをを識別することができる。
【１１１７】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドはサービスのタイプを示し、本発明の一実施例によるサービスがｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームを伝送するサービスであることを識別するのに使われることができる。
【１１１８】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは後続のＩＰ ａｄｄｒｅｓｓの形式を示すことができる。このフィールドの値が０である場合はＩＰｖ４アドレスフォーマット、１である場合はＩＰｖ６アドレスフォーマットが使われることを示すことができる。
【１１１９】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドはこのサービスがｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むかを示すことができる。このフィールドの値が１である場合、このサービスはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むことができる。
【１１２０】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＩＰ ｄａｔａｇｒａｍのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを示すことができる。ここで、前述したｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍは、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅが独立したストリームとして伝送される場合、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームを示すことができる。
【１１２１】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＩＰ ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを示すことができる。
【１１２２】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＩＰ ｄａｔａｇｒａｍのＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを示すことができる。
【１１２３】
ＳＳＣ＿ＴＳＩフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍを含むＬＣＴ ｓｅｓｓｉｏｎなどのｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒを示すことができる。
【１１２４】
ＳＳＣ＿ＤＰ＿ＩＤフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ ｓｔｒｅａｍが伝送されるｄａｔａ ｐｉｐｅのｉｄｅｎｔｉｆｉｅｒを示すことができる。ここで、ｄａｔａ ｐｉｐｅはｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｉｐｅと同一であることができる。
【１１２５】
図１１３は本発明の一実施例によるＳｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎの構成を示した図である。
【１１２６】
本発明の一実施例によると、一つのサービスで一つのｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、サービス内の全てのコンテンツ及びストリームがこのｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを介して同期化されることができる。
【１１２７】
本発明の一実施例は一つのサービスにあたるｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅのブートストラップ情報を伝送することができる。ここで、ブートストラップ情報はｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームに近付くための情報を示すことができる。
【１１２８】
本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値のシーケンスは別個のｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームとして構成され、該当のストリームパケットのペイロードを介して伝送されるか、コンポーネント伝送ストリームパケットのヘッダーに含まれて伝送されることができる。
【１１２９】
本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値がコンポーネントを伝送するストリームパケットのヘッダーに含まれて伝送される場合、ＬＣＴ ｐａｃｋｅｔ ｈｅａｄｅｒのＥＸＴ＿ＴＩＭＥ ｅｘｔｅｎｓｉｏｎを用いてｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値を伝送することができる。
【１１３０】
本発明の一実施例によると、一つのサービスを構成する内部のストリームを介してｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅが伝送されるとき、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームは＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドを介して識別されることができる。＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドはＲＯＵＴＥ ｓｅｓｓｉｏｎを構成するＬＣＴ ｓｅｓｓｉｏｎの中でｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するＬＣＴ ｓｅｓｓｉｏｎのＴＳＩ情報を示すことができる。本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームのＩＰ ａｄｄｒｅｓｓ及びＵＤＰ ｐｏｒｔ情報は＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドの前に存在するＲＯＵＴＥ Ｓｅｓｓｉｏｎ内部の他のフィールドを介して識別されることができる。本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームを伝送するＤＰについての情報は前述したＬＳＩＤ及びＣＭＴを介してシグナリングされることができる。ここで、ＬＳＩＤはＳ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）と同一であることができ、ＣＭＴはＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）と同一であることができる。
【１１３１】
本発明の他の一実施例はＳｅｒｖｉｃｅ ＤｅｓｃｒｉｐｉｏｎにＣｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ Ｂｏｏｔｓｔｒａｐフィールドを含ませることで、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームに近付くための情報をシグナリングすることができる。本発明の一実施例によるＣｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ Ｂｏｏｔｓｔｒａｐフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒと同様に、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰ ａｄｄｒｅｓｓ、ＵＤＰ ｐｏｒｔ、ＴＳＩ、ＤＰなどの情報を含むことができる。
【１１３２】
この図に示したＳｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎは＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールド及びＣｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ Ｂｏｏｔｓｔｒａｐフィールドを全て含んでいるが、本発明の一実施例によると、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎは前述した二つのフィールドのいずれか一つのみ含むことができ、二つのフィールドのいずれか一つを用いてｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームに近付くための情報（ｂｏｏｔｓｔｒａｐ情報）をシグナリングすることができる。
【１１３３】
本発明の一実施例によるＳｅｒｖｉｃｅ ＤｅｓｃｒｉｐｔｉｏｎはＵＳＢＤ／ＵＳＤと同一であることができ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎは、＠ｓｅｒｖｉｃｅ＿ｉｄフィールド、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、＠ｓｅｒｖｉｃｅ＿ｎａｍｅフィールド、＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールド、＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールド、＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールド、＠ＳＰ＿ｉｎｄｉｃａｔｏｒフィールド、ＲＯＵＴＥＳｅｓｓｉｏｎフィールド、＠ｓｏｕｒｃｅＩＰＡｄｄｒフィールド、＠ｄｅｓｔＩＰＡｄｄｒフィールド、＠ｄｅｓｔＵＤＰＰｏｒｔフィールド、＠ＬＳＩＤ＿ＤＰフィールド、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールド、Ｔａｒｇｅｔｉｎｇフィールド、Ｃｏｎｔｅｎｔ Ａｄｖｉｓｏｒｙフィールド、Ｒｉｇｈｔ Ｉｓｓｕｅｒ Ｓｅｒｖｉｃｅフィールド、Ｃｕｒｒｅｎｔ Ｐｒｏｇｒａｍフィールド、Ｏｒｉｇｉｎａｌ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、Ｃｏｎｔｅｎｔ Ｌａｂｅｌｉｎｇフィールド、Ｇｅｎｒｅフィールド、Ｃａｐｔｉｏｎフィールド、Ｐｒｏｔｅｃｔｉｏｎフィールド及び／又はＣｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ Ｂｏｏｔｓｔｒａｐフィールドを含むことができる。
【１１３４】
＠ｓｅｒｖｉｃｅ＿ｉｄフィールドはサービスを識別することができる。
【１１３５】
＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドはサービスのタイプを示すことができる。
【１１３６】
＠ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドはサービスの名前を示すことができる。
【１１３７】
＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドはサービスのチャネルナンバーを示すことができる。
【１１３８】
＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドはサービスのｓｔａｔｕｓを示すことができる。このフィールドは該当のサービスがａｃｔｉｖｅであるかあるいはｉｎａｃｔｉｖｅであるかを示すことができる。
【１１３９】
＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは該当のサービスが該当のパーティションに全て含まれているか、該当のパーティションに部分的に含まれているが該当のパーティションのみでプレゼンテーションが可能であるか、プレゼンテーションするために他のパーティションが必要であるかあるいはプレゼンテーションするために他の放送ストリームが要求されるかなどについての情報を示すことができる。
【１１４０】
＠ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは該当のサービスを成す一つ以上のコンポーネントがｐｒｏｔｅｃｔｅｄであるかを示すことができる。すなわち、該当のサービスがｐｒｏｔｅｃｔｅｄであるかを示すことができる。
【１１４１】
ＲＯＵＴＥ Ｓｅｓｓｉｏｎフィールドは該当のサービスが伝送されるＲＯＵＴＥ Ｓｅｓｓｉｏｎについての情報を示すことができる。
【１１４２】
＠ｓｏｕｒｃｅＩＰＡｄｄｒフィールドは該当のＲＯＵＴＥ Ｓｅｓｓｉｏｎのｓｏｕｒｃｅ ＩＰアドレスを示すことができる。
【１１４３】
＠ｄｅｓｔＩＰＡｄｄｒフィールドは該当のＲＯＵＴＥ Ｓｅｓｓｉｏｎのｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスを示すことができる。
【１１４４】
＠ｄｅｓｔＵＤＰＰｏｒｔフィールドは該当のＲＯＵＴＥ ＳｅｓｓｉｏｎのｄｅｓｔｉｎａｔｉｏｎＵＤＰポートナンバーを示すことができる。
【１１４５】
＠ＬＳＩＤ＿ＤＰフィールドは該当のＲＯＵＴＥ Ｓｅｓｓｉｏｎの伝送パラメータなどの情報を含むＬＳＩＤを伝達するｄａｔａ ｐｉｐｅを識別することができる。本発明の一実施例によると、このフィールドはＲＯＵＴＥ Ｓｅｓｓｉｏｎを構成する一つ以上のＬＣＴ ｓｅｓｓｉｏｎについての情報を含むＬＳＩＤを識別することができる。
【１１４６】
＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドはＲＯＵＴＥ ｓｅｓｓｉｏｎを構成するＬＣＴ ｓｅｓｓｉｏｎの中でｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するＬＣＴ ｓｅｓｓｉｏｎのＴＳＩ情報を示すことができる。
【１１４７】
Ｔａｒｇｅｔｉｎｇフィールドは該当のサービスに対するｔａｒｇｅｔｉｎｇパラメータを示すことができる。このフィールドについての詳細な説明は前述した。
【１１４８】
Ｃｏｎｔｅｎｔ Ａｄｖｉｓｏｒｙフィールドは該当のサービス関連ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報を示すことができる。本発明の一実施例によると、このフィールドはｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ ｒａｔｉｎｇ関連情報を含むことができる。このフィールドについての詳細な説明は前述した。
【１１４９】
Ｒｉｇｈｔ Ｉｓｓｕｅｒ Ｓｅｒｖｉｃｅフィールドは該当のサービス関連ｒｉｇｈｔ ｉｓｓｕｅなどについての情報を含むことができる。このフィールドについての詳細な説明は前述した。
【１１５０】
Ｃｕｒｒｅｎｔ Ｐｒｏｇｒａｍフィールドは現在プログラムなどについての情報を含むことができる。このフィールドについての詳細な説明は前述した。
【１１５１】
Ｏｒｉｇｉｎａｌ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールドは元のサービスを識別する情報を含むことができる。このフィールドについての詳細な説明は前述した。
【１１５２】
Ｃｏｎｔｅｎｔ Ｌａｂｅｌｉｎｇフィールドはｃｏｎｔｅｎｔ ｌａｂｅｌｉｎｇ関連情報を含むことができる。このフィールドについての詳細な説明は前述した。
【１１５３】
Ｇｅｎｒｅフィールドは該当のサービスのジャンル情報を含むことができる。
【１１５４】
Ｃａｐｔｉｏｎフィールドは該当のサービスのキャプション関連情報を含むことができる。
【１１５５】
Ｐｒｏｔｅｃｔｉｏｎフィールドは該当のサービスのｐｒｏｔｅｃｔｉｏｎ関連情報を含むことができる。
【１１５６】
Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ Ｂｏｏｔｓｔｒａｐフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒと同様に、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰ ａｄｄｒｅｓｓ、ＵＤ Ｐｐｏｒｔ、ＴＳＩ、ＤＰなどの情報を含むことができる。すなわち、このフィールドはｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅストリームに近付くための情報を含むことができる。
【１１５７】
図１１４は本発明の一実施例によるＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎの構成を示した図である。
【１１５８】
本発明の一実施例は前述したＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎに＠ｃｌｏｃｋＲｅｆＦｌａｇフィールドを付け加えて現在の放送ストリーム又は他の放送ストリームを介して伝送されるストリームの中でｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームを識別することができる。本発明の一実施例によると、＠ｃｌｏｃｋＲｅｆＦｌａｇフィールドがフィールド値１を有する場合、該当のコンポーネントがｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを含んで伝送することを示すことができる。
【１１５９】
本発明の一実施例によると、一つのサービスを介して伝送されるコンポーネントの中で＠ｃｌｏｃｋＲｅｆＦｌａｇフィールド値１を有するコンポーネントの数は最大１個に制約することができる。
【１１６０】
本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームのＴＳＩ及びＤＰ情報は先立って登場するＢｒｏａｄｃａｓｔＣｏｍｐフィールドの下位フィールドによって識別されることができ、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰ ａｄｄｒｅｓｓとＵＤＰ ｐｏｒｔ情報は前述したＳｅｒｖｉｃｅ ＤｅｓｃｒｉｐｔｉｏｎのＲＯＵＴＥ Ｓｅｓｓｉｏｎフィールドの下位フィールド及びＬＳＩＤから提供される情報によって識別されることができる。本発明の一実施例によると、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅを伝送するストリームが他の放送ストリームを介して伝送される場合、ＦｏｒｉｇｎＣｏｍｐフィールドの下位フィールドを介してこれを識別することができる。
【１１６１】
この図に示したフィールドについての詳細な説明は前述した。
【１１６２】
図１１５は本発明の一実施例による放送信号送信方法を示した図である。
【１１６３】
本発明の一実施例による放送信号送信方法は、放送サービス、放送サービスの速い獲得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報をエンコードする段階（ＳＬ１２８０１０）、エンコードされた放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を含む放送信号を生成する段階（ＳＬ１２８０２０）及び／又は放送信号を伝送する段階（ＳＬ１２８０３０）を含むことができる。ここで、前述した放送サービスはＡＴＳＣ３．０サービスを示すことができる。前述した第１シグナリング情報は前述したＦＩＣ及び／又はＳＬＴを示すことができる。前述した第２シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを示すことができる。前述した第３シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを示すことができる。
【１１６４】
本発明の他の一実施例によると、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報の少なくとも一つは送信側と受信側の時間的同期化のための時間情報を含むことができる。ここで、前述した時間情報はｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒを示すことができる。これについての詳細な説明は図１１０及び図１１１で前述した。
【１１６５】
本発明の他の一実施例によると、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報の少なくとも一つは送信側と受信側の時間的同期化のための時間情報を伝送するストリームに近付くための接近情報を含むことができる。ここで、前述した接近情報はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたフィールドを示すことができる。これについての詳細な説明は図１０９、図１１１及び図１１３で前述した。
【１１６６】
本発明の他の一実施例によると、時間情報は送信側と受信側の時間的同期化に使われる基準時間値及び／又は基準時間値のタイプを示す情報を含むことができる。ここで、前述した基準時間値はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを示すことができ、前述した基準時間値のタイプを示す情報はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドを示すことができる。これについての詳細な説明は図１１０で前述した。
【１１６７】
本発明の他の一実施例によると、接近情報は、時間情報を伝送するストリームを含むＩＰデータグラムの目的地ＩＰアドレス情報、時間情報を伝送するストリームを含むＩＰデータグラムのＵＤＰポートナンバー、時間情報を伝送するストリームを含むセッションを識別する情報及び／又は時間情報を伝送するストリームが伝送されるデータパイプを識別する情報を含むことができる。これについての詳細な説明は図１０９で前述した。
【１１６８】
本発明の他の一実施例によると、第１シグナリング情報は一つの放送ストリームを介して伝送される一つ以上のサービスについての情報を含み、時間情報は第１シグナリング情報のサービスレベルに含まれ、一つのサービス内の全てのコンポーネントの同期化のために使われることができる。これについての詳細な説明は図１１２、図１１３及び図１１４で前述した。
【１１６９】
本発明の他の一実施例によると、放送サービスは送信側と受信側の時間的同期化のための時間情報を提供する放送サービスにあたり、第１シグナリング情報は放送サービスに近付くための情報を含むことができる。これについての詳細な説明は図１１２で前述した。
【１１７０】
図１１６は本発明の一実施例による放送信号受信方法を示した図である。
【１１７１】
本発明の一実施例による放送信号受信方法は、放送サービス、放送サービスの速い獲得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報を含む放送信号を受信する段階（ＳＬ１２９０１０）、受信した放送信号から放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を抽出する段階（ＳＬ１２９０２０）及び／又は抽出された放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報をデコードする段階（ＳＬ１２９０３０）を含むことができる。ここで、前述した放送サービスはＡＴＳＣ３．０サービスを示すことができる。前述した第１シグナリング情報は前述したＦＩＣ及び／又はＳＬＴを示すことができる。前述した第２シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを示すことができる。前述した第３シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを示すことができる。
【１１７２】
本発明の他の一実施例によると、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報の少なくとも一つは送信側と受信側の時間的同期化のための時間情報を含むことができる。ここで、前述した時間情報はｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ、ｃｌｏｃｋ ｒｅｆｅｒｅｎｃｅ値及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒを示すことができる。これについての詳細な説明は図１１０及び図１１１で前述した。
【１１７３】
本発明の他の一実施例によると、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報の少なくとも一つは送信側と受信側の時間的同期化のための時間情報を伝送するストリームに近付くための接近情報を含むことができる。ここで、前述した接近情報はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたフィールドを示すことができる。これについての詳細な説明は図１０９、図１１１及び図１１３で前述した。
【１１７４】
本発明の他の一実施例によると、時間情報は送信側と受信側の時間的同期化に使われる基準時間値及び／又は基準時間値のタイプを示す情報を含むことができる。ここで、前述した基準時間値はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを示すことができ、前述した基準時間値のタイプを示す情報はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドを示すことができる。これについての詳細な説明は図１１０で前述した。
【１１７５】
本発明の他の一実施例によると、接近情報は、時間情報を伝送するストリームを含むＩＰデータグラムの目的地ＩＰアドレス情報、時間情報を伝送するストリームを含むＩＰデータグラムのＵＤＰポートナンバー、時間情報を伝送するストリームを含むセッションを識別する情報及び／又は時間情報を伝送するストリームが伝送されるデータパイプを識別する情報を含むことができる。これについての詳細な説明は図１０９で前述した。
【１１７６】
本発明の他の一実施例によると、第１シグナリング情報は一つの放送ストリームを介して伝送される一つ以上のサービスについての情報を含み、時間情報は第１シグナリング情報のサービスレベルに含まれ、一つのサービス内の全てのコンポーネントの同期化のために使われることができる。これについての詳細な説明は図１１２、図１１３及び図１１４で前述した。
【１１７７】
図１１７は本発明の一実施例による放送信号送信装置の構成を示した図である。
【１１７８】
本発明の一実施例による放送信号送信装置（Ｌ１３００１０）は、放送サービス、放送サービスの速い獲得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報をエンコードするエンコーダ（Ｌ１３００２０）、エンコードされた放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を含む放送信号を生成する生成部（Ｌ１３００３０）及び／又は放送信号を伝送する伝送部（Ｌ１３００４０）を含むことができる。ここで、前述した放送サービスはＡＴＳＣ３．０サービスを示すことができる。前述した第１シグナリング情報は前述したＦＩＣ及び／又はＳＬＴを示すことができる。前述した第２シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを示すことができる。前述した第３シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを示すことができる。
【１１７９】
図１１８は本発明の一実施例による放送信号受信装置の構成を示した図である。
【１１８０】
本発明の一実施例による放送信号受信装置（Ｌ１３１０１０）は、放送サービス、放送サービスの速い獲得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報を含む放送信号を受信する受信部（Ｌ１３１０２０）、受信した放送信号から放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を抽出する抽出部（Ｌ１３１０３０）及び／又は抽出された放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報をデコードするデコーダー（Ｌ１３１０４０）を含むことができる。ここで、前述した放送サービスはＡＴＳＣ３．０サービスを示すことができる。前述した第１シグナリング情報は前述したＦＩＣ及び／又はＳＬＴを示すことができる。前述した第２シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを示すことができる。前述した第３シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを示すことができる。ここで、前述した放送サービスはＡＴＳＣ３．０サービスを示すことができる。前述した第１シグナリング情報は前述したＦＩＣ及び／又はＳＬＴを示すことができる。前述した第２シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを示すことができる。前述した第３シグナリング情報は前述したＳＭＴ、Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを示すことができる。
【１１８１】
図１１９は本発明の一実施例による、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝送される場合、そのサービスディスクリプション情報を示す図である。
【１１８２】
本発明は、セッションディスクリプション情報が伝送セッションの外部経路を介して伝送される方法を提案する。ここで、セッションディスクリプション情報は、該当の伝送セッションの伝送特性、プロトコル、パケット構造などの情報を含むことができる。実施例によって、セッションディスクリプション情報は前述したＬＳＩＤにあたることができる。また、セッションディスクリプション情報は前述したＳ−ＴＳＩＤの中で、複数のＬＳエレメントにあたる情報であり得る。この場合、ここでのサービスディスクリプション情報はＳ−ＴＳＩＤにあたることができる。
【１１８３】
このセッションディスクリプション情報は、該当の伝送セッションを介して伝達されるかあるいは伝送セッションの外部経路を介して受信機に伝達されることができる。また、セッションディスクリプション情報は他のシグナリングメッセージに含まれて伝送されるか、あるいは該当の伝送セッションの内／外部に存在するサービスシグナリングチャネルなどの経路を介して伝送されることができる。サービスシグナリングチャネルを介して伝送される場合、セッションディスクリプション情報は他のシグナリングメッセージと一緒に伝送されることができる。
【１１８４】
まず、セッションディスクリプション情報が他のシグナリングメッセージに含まれて伝送される場合を説明する。
【１１８５】
セッションディスクリプション情報は前述した他のシグナリングメッセージに含まれて伝送されることができる。他のシグナリングメッセージにはＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤ、ＳＭＴ、ＣＭＴなどがあり得る。図示の実施例においては、セッションディスクリプション情報がサービスディスクリプション情報に含まれている。ここで、サービスディスクリプション情報は前述したＳＭＴ乃至Ｓ−ＴＳＩＤにあたることができる。
【１１８６】
ここで、セッションディスクリプション情報はサービスディスクリプション情報のＬＳＩＤエレメントに含まれることができる。ここで、ＬＳＩＤエレメントはサービスディスクリプション情報のＲＯＵＴＥ ｓｅｓｓｉｏｎエレメントの下位エレメントであり得る。セッションディスクリプション情報は該当のＲＯＵＴＥ ｓｅｓｓｉｏｎエレメントによって指示されるＲＯＵＴＥセッション（伝送セッション）のセッション情報を含むことができる。該当のＲＯＵＴＥセッションはＲＯＵＴＥ ｓｅｓｓｉｏｎエレメントの＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔなどの情報によって指示されることができる。このように、セッションディスクリプション情報がサービスディスクリプション情報に直接含まれて伝送される場合、セッションディスクリプション情報が記述する伝送セッションではセッションディスクリプション情報が伝達されないこともできる。これは重複を防ぐためであり得る。
【１１８７】
サービスディスクリプション情報内部の各エレメントは前述したようである。
【１１８８】
＠ｓｅｒｖｉｃｅ＿ｉｄは該当のサービスディスクリプション情報が記述するサービスの識別子を示すことができる。＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙは該当のサービスのカテゴリーを指示することができる。＠ｓｅｒｖｉｃｅ＿ｎａｍｅは該当のサービスの名前を示すことができる。＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒは該当のサービスに係わるチャネルナンバー情報を示すことができる。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓは該当のサービスの状態情報を示すことができる。＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎは該当のサービスのディストリビューション関連情報を示すことができる。＠ＳＰ＿ｉｎｄｉｃａｔｏｒは該当のサービスが保護（ｐｒｏｔｅｃｔｉｏｎ）されているかを指示することができる。ここで、該当のサービスのサービスコンポーネントの少なくとも一つでも保護されていれば、その該当のサービスが保護されていると指示されることができる。
【１１８９】
ＲＯＵＴＥ ｓｅｓｓｉｏｎエレメントは該当のサービス乃至サービスコンポーネントが伝達されるＲＯＵＴＥ ｓｅｓｓｉｏｎについての情報を含むことができる。ＲＯＵＴＥ ｓｅｓｓｉｏｎエレメントはサービスディスクリプション情報内に複数存在することができる。＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、及び＠ｄｅｓｔＵＤＰＰｏｒｔはそれぞれ該当のＲＯＵＴＥパケットを伝送するＩＰデータグラムのソースＩＰアドレス、デスティネーションＩＰアドレス、及びデスティネーションＰｏｒｔナンバー情報を含むことができる。すなわち、この情報は該当のＲＯＵＴＥセッションを指示することができる。
【１１９０】
＠ＬＳＩＤ＿ＤＰは該当のＲＯＵＴＥセッションのセッションディスクリプション情報が伝達されるＤＰ（又はＰＬＰ）を識別することができる。ここで、該当のＲＯＵＴＥセッションとは、ソースＩＰアドレス、デスティネーションＩＰアドレス及びデスティネーションＰｏｒｔナンバー情報によって識別されるＲＯＵＴＥセッションを意味することができる。
【１１９１】
＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤはセッションディスクリプション情報を伝達するセッションディスクリプションテーブルの識別子であって、該当のＲＯＵＴＥセッションのセッションディスクリプション情報を有するセッションディスクリプションテーブルを識別することができる。このフィールドはセッションディスクリプション情報がセッションディスクリプションテーブルに含まれて伝送される場合に活用できる。セッションディスクリプションテーブルはサービスシグナリングチャネルを介して他のシグナリングメッセージと一緒に伝送されることができる。
【１１９２】
＠ＬＳＩＤｕｒｌは該当のＲＯＵＴＥセッションのセッションディスクリプション情報がブロードバンドを介して伝送される場合、その位置を識別するためのＵＲＬ情報を有することができる。このフィールドはセッションディスクリプション情報がブロードバンドを介して伝送される場合に活用できる。
【１１９３】
Ｔａｒｇｅｔｉｎｇは該当のサービスに対するタゲッティングパラメータを示すことができる。すなわち、該当のサービスが受信機又はコンパニオンデバイスのためのサービスであるかを識別することができる。Ｃｏｎｔｅｎｔ Ａｄｖｉｓｏｒｙは該当のサービス関連コンテンツアドバイザリー情報、すなわち該当のサービスのレーティング関連情報を含むことができる。Ｒｉｇｈｔ Ｉｓｓｕｅｒ Ｓｅｒｖｉｃｅは該当のサービス関連の正当なイシュー関連情報を含むことができる。Ｃｕｒｒｅｎｔ Ｐｒｏｇｒａｍは現在プログラムについての情報を含むことができる。Ｏｒｉｇｉｎａｌ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎは元のサービスに関する識別情報を含むことができる。Ｃｏｎｔｅｎｔ Ｌａｂｅｌｉｎｇ情報は該当のサービスのコンテンツラベリング情報を含むことができる。Ｇｅｎｒｅは該当のサービスのジャンル情報を含むことができる。Ｃａｐｔｉｏｎは該当のサービスのキャプション関連情報を含むことができる。Ｐｒｏｔｅｃｔｉｏｎは該当のサービスのプロテクションに関連した情報を含むことができる。
【１１９４】
ここで、実施例について、伝送セッションがＲＯＵＴＥセッションである場合を説明したが、本発明はこれに限定されない。すなわち、ＭＭＴＰセッションなどの他の伝送セッションに対しても同一方式でこれらの実施例が適用されることができる。
【１１９５】
図１２０は本発明の一実施例による、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。
【１１９６】
前述したように、セッションディスクリプション情報はサービスシグナリングチャネルなどの経路を介して伝送されることができる。この場合、セッションディスクリプション情報は他のシグナリングメッセージと一緒に伝送されることができる。サービスシグナリングチャネルは実施例によって別個の伝送セッションを介して伝達されることもでき、ＲＯＵＴＥセッションなどの伝送セッション内部の一サブセッションによって伝達されることもできる。ここで、サブセッションはＬＣＴセッションにあたることができる。
【１１９７】
一つのサービスが複数の伝送セッションに分けられて伝達される場合、複数の伝送セッションに対するディスクリプション情報が必要であリ得る。この場合、各伝送セッションに対するセッションディスクリプション情報がサービスシグナリングチャネルを介して伝送されることができる。この際、それぞれの伝送セッションとセッションディスクリプションをマッピングする必要があり得る。このマッピングのために、前述した＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤ情報が活用できる。この情報によって、サービスディスクリプション情報が指示するＲＯＵＴＥセッションに対するセッションディスクリプション情報が獲得できる。これは、該当の情報とマッピングされるセッションディスクリプションテーブルを識別することで遂行できる。このようなマッピングはセッションディスクリプション情報がサービスディスクリプション情報に含まれて伝送される場合には不要であることができる。
【１１９８】
実施例によって、サービスシグナリングチャネルはＳＬＳが伝送されるＲＯＵＴＥセッション内のＬＣＴセッションを意味することができる。このＬＣＴセッションは前述したようにＴＳＩ＝０に特定されていることができる。
【１１９９】
図示の実施例（ｔ２０１０）は前述したシグナリングメッセージフォーマットを基本構造にし、セッションディスクリプション情報送信のために拡張された構造を有するメッセージフォーマットであり得る。セッションディスクリプション情報送信のために、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドをそれぞれＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎとＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤに分けられて定義することができる。
【１２００】
ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎはこのセッションディスクリプションテーブルのバージョン乃至プロトコルバージョンを示すことができる。ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤはこのテーブルが送信しているセッションディスクリプション情報の識別子であって、前述したサービスディスクリプション情報内の＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤと一致する値が使われることができる。これにより、ＲＯＵＴＥセッションとセッションディスクリプション情報間のマッピングが遂行されることができる。ＬＣＴ＿ｓｅｓｓｉｏｎ＿ｉｎｓｔａｎｃｅ＿ｄｅｓｃｒｉｐｔｉｏｎ（）にはセッションディスクリプション情報がバイナリ又はＸＭＬ形態に含まれることができる。すなわち、セッションディスクリプション情報の実際データがこれに含まれることができる。その他のセッションディスクリプションテーブル内の情報は前述したシグナリングメッセージフォーマットで説明したものと同一であることができる。
【１２０１】
図示の他の実施例（ｔ２０２０）はセッションディスクリプション情報伝達のためのセッションディスクリプションテーブルの他の実施例である。この実施例はＭＰＥＧ−２ＴＳプライベートセクション（ｐｒｉｖａｔｅ ｓｅｃｔｉｏｎ）に基づくフィールドの構成を有することができる。ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤ、ＬＣＴ＿ｓｅｓｓｉｏｎ＿ｉｎｓｔａｎｃｅ＿ｄｅｓｃｒｉｐｔｉｏｎ（）の意味は前述した実施例のそれと同様であり得る。その他のセッションディスクリプションテーブル内の情報は前述したシグナリングメッセージフォーマットで説明したものと同一であるこｔろができる。
【１２０２】
図１２１は本発明の一実施例による、セッションの外部経路を介したセッションディスクリプション情報送信方法を示す図である。
【１２０３】
この実施例において、一つのサービスは二つのＲＯＵＴＥセッションを介して伝送されることができる。この実施例において、一番目ＲＯＵＴＥセッションのセッションディスクリプション情報は該当のＲＯＵＴＥセッション（一番目ＲＯＵＴＥセッション）を介して伝送されることができ、二番目ＲＯＵＴＥセッションのセッションディスクリプション情報は二番目ＲＯＵＴＥセッションの外部経路であるサービスシグナリングチャネルを介して伝送されることができる。ここで、サービスシグナリングチャネルは一番目ＲＯＵＴＥセッションの内部に位置することができる。
【１２０４】
この実施例において、各シグナリングメッセージ及び／又はサービスコンポーネントデータの獲得手順について説明する。
【１２０５】
まず、受信機はＦＩＣからサービスシグナリングチャネルのブートストラップ情報を獲得することができる。これにより、受信機はサービスシグナリングチャネルに近付くことができる。ＦＩＣのＩＰアドレス、ＵＤＰポート情報を用いて近づくことができる。実施例によって、ＴＳＩ情報及び／又はＰＬＰＩＤ情報も必要であることができる。これは、前述したＳＬＴを用いてＳＬＳに近付くことに対応することができる。この場合、ＳＬＴはＦＩＣに対応し、ＳＬＳを伝達するＬＣＴセッションはサービスシグナリングチャネルに対応し、ＳＬＳはサービスシグナリングチャネル内の情報に対応することができる。この実施例において、ＦＩＣはフィジカル信号フレームの別個のチャネルを介して伝達されているが、ＳＬＴの場合は、ＩＰ／ＵＤＰを介してカプセル化され、ＰＬＰを介して伝達されることができる。
【１２０６】
その後、ブートストラップ情報を用いて近付いたサービスシグナリングチャネルからＳＭＴの情報が獲得できる。ＳＭＴから各ＲＯＵＴＥセッションに対するセッションディスクリプション情報が獲得できる。一番目ＲＯＵＴＥセッションに対するセッションディスクリプション情報は＠ＬＳＩＤ＿ＤＰ情報を用いて獲得できる。＠ＬＳＩＤ＿ＤＰが指示するＰＬＰに近付くことで、一番目ＲＯＵＴＥセッションのセッションディスクリプション情報が獲得できる。二番目ＲＯＵＴＥセッションに対するセッションディスクリプション情報は＠ＬＳＩＤＴ＿ｉｎｓｔａｎ ｃｅ＿ＩＤ情報を用いて獲得できる。＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤが指示するセッションディスクリプションテーブルが識別されることにより、二番目ＲＯＵＴＥセッションのセッションディスクリプション情報が獲得できる。
【１２０７】
これは、前述した実施例において、ＳＬＳを伝達するＲＯＵＴＥセッションのＬＣＴセッションに近付くことにより、ＳＬＳの情報が獲得される過程に対応することができる。ＳＬＳ情報からセッションディスクリプション情報、つまり各伝送セッションのどのサブセッション（ＬＣＴセッションなど）を介してサービスコンポーネントが伝達されるかについての情報が獲得できる。実施例によって、ＳＬＳのＳ−ＴＳＩＤ内のＬＳエレメントについての情報がこのセッションディスクリプション情報にあたることができる。この場合の実施例においては、別個のセッションディスクリプションテーブルが不要になることもできる。また、セッションディスクリプション情報はＳＬＳに含まれて伝達され、同じＰＬＰを介して伝達されるので、セッションディスクリプション情報が伝達されるＰＬＰに対する別個のＰＬＰＩＤ情報は不要になることもできる。
【１２０８】
その後、ＣＭＴから各サービスコンポーネントのＰＬＰＩＤが獲得できる。既に獲得したセッションディスクリプション情報を用いて、一番目／二番目ＲＯＵＴＥセッションの各ＴＳＩ情報が獲得できる。各ＴＳＩ情報は該当のサービスコンポーネントを伝達するＬＣＴセッションのＴＳＩ情報であり得る。この情報を用いて各サービスコンポーネントが獲得できる。また、ＭＰＤから各サービスコンポーネントのレプリゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）ＩＤが獲得できる。
【１２０９】
これは、前述した実施例において、ＳＬＳ内の情報（ＴＳＩなど）を用いて各ＬＣＴセッションに近付くことによって各サービスコンポーネントを獲得する過程に対応することができる。この場合の実施例において、Ｓ−ＴＳＩＤはＰＬＰＩＤ情報も含むこともできるので、別個のＣＭＴは不要であることができる。Ｓ−ＴＳＩＤ内の各セッションディスクリプション情報を用いて複数のＲＯＵＴＥセッション内の複数のＬＣＴセッションにそれぞれ近付くことができる。収集されたサービスコンポーネントに対し、ＭＰＤからレプリゼンテーションＩＤが獲得できる。
【１２１０】
図１２２は本発明の他の実施例による、セッションの外部経路を介したセッションディスクリプション情報送信方法を示す図である。
【１２１１】
この実施例において、一つのサービスは二つのＲＯＵＴＥセッションを介して伝送されることができる。この実施例において、一番目及び二番目ＲＯＵＴＥセッションのセッションディスクリプション情報はいずれも一番目ＲＯＵＴＥセッションを介して伝達されるサービスシグナリングチャネルを介して伝送されることができる。
【１２１２】
この実施例において、各シグナリングメッセージ及び／又はサービスコンポーネントデータの獲得手順は前述した実施例と同様である。ただ、この実施例においては、二つのＲＯＵＴＥセッションに対するセッションディスクリプション情報が全てセッションディスクリプションテーブルを介して伝達される。よって、＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤによって識別される二つのセッションディスクリプションテーブルが先に獲得された後、そのテーブル内のセッションディスクリプション情報を用いて、二つのＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントに近付くことができる。
【１２１３】
この実施例も、前述したＳＬＴ−ＳＬＳを用いた実施例に対応することができる。ＳＬＴを用いてＳＬＳを伝達するチャネル／経路に近付けば、ＳＬＳ内の情報を用いて、該当のサービスのサービスコンポーネントを伝達する経路に近付くことができる。この場合、サービスコンポーネントを伝達する経路は複数のＲＯＵＴＥセッションにわたって存在することができ、複数のＲＯＵＴＥセッション内の複数のＬＣＴセッションを介して各サービスコンポーネントが伝達されることができる。
【１２１４】
図１２３は本発明のさらに他の実施例による、セッションの外部経路を介したセッションディスクリプション情報送信方法を示す図である。
【１２１５】
この実施例において、一つのサービスは二つのＲＯＵＴＥセッションを介して伝送されることができる。この実施例において、一番目及び二番目ＲＯＵＴＥセッションのセッションディスクリプション情報は全て、一番目ＲＯＵＴＥセッションを介して伝達されるサービスシグナリングチャネルを介して伝送されることができる。
【１２１６】
この実施例において、各シグナリングメッセージ及び／又はサービスコンポーネントデータの獲得手順は前述した実施例と同様である。ただし、この実施例においては、サービスシグナリングチャネルが特定のＲＯＵＴＥセッションの一ＬＣＴセッションを介して伝達されるものでではなく、別個のＰＬＰ（ＤＰ）、ＩＰ、及びＵＤＰによって識別される別個のチャネルを介して伝達されることができる。この場合、全てのＲＯＵＴＥセッションに対し、そのセッションディスクリプション情報が外部経路を介して伝達されるので、サービスシグナリングチャネルは各セッションに対するセッションディスクリプションテーブルを有することができる。セッションディスクリプションテーブル内のセッションディスクリプション情報を用いて、二つのＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントに近付くことができる。
【１２１７】
この場合、サービスシグナリングチャネルが特定のＲＯＵＴＥセッションの一サブセッション（ＬＣＴセッションなど）を介して伝達されるものではないので、ＦＩＣ乃至ＳＬＴのブートストラッピング情報にはＴＳＩ情報は不要であることができる。
【１２１８】
図１２４は本発明の一実施例による、初期化情報伝達のために拡張されたシグナリングメッセージを示す図である。
【１２１９】
本発明は、前述した放送システムにおいて、サービスのサービスコンポーネントに係わる初期化情報を伝達する方法を提案する。前述したように、各サービスのサービスコンポーネントはＤＡＳＨセグメントにフォーマットされ、ＤＡＳＨレプリゼンテーション形態としてＬＣＴセッションを介して伝達されることができる。このサービスコンポーネントのための初期化情報が必要であることができる。ここで、初期化情報はＤＡＳＨの初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）にあたることができる。
【１２２０】
初期化情報は伝送セッションの内／外部に存在するサービスシグナリングチャネルを介して伝送されるか、各ＬＣＴセッションでメディアデータと一緒に伝送されることができる。ここで、メディアデータとはメディアセグメントを意味することができる。
【１２２１】
一つ目、初期化情報がサービスシグナリングチャネルを介して伝送される場合、初期化情報は他のシグナリングメッセージと一緒に伝送されることができる。一つのサービスが複数のコンポーネントで構成されて伝送される場合、複数の初期化情報が一つのシグナリングチャネルに含まれて伝送されることができる。この際、それぞれの初期化情報と各メディアデータ（サービスコンポーネント）がマッピングされる必要があり得る。
【１２２２】
このマッピングのための識別子が定義されることができ、これは＠ｉｓｄＩｎｓｔａｎｃｅＩＤと呼ばれることもできる。この情報は、初期化情報を含む初期化テーブルと、各コンポーネントをマッピングさせることができる。この初期化情報を用いて各サービスコンポーネントが初期化されることができる。
【１２２３】
図示のコンポーネントマッピングディスクリプション（Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ）は前述したようであるが、＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報をもっと有するように拡張された。＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報は放送ネットワークを介したコンポーネントを指示するＢｒｏａｄｃａｓｔＣｏｍｐエレメントの下部に位置し、該当のコンポーネントにマッピングされる初期化情報を有する初期化テーブルを識別することができる。その他のコンポーネントマッピングディスクリプション内部のフィールドは前述したようである。実施例によって、ＳＬＴ又はＳＬＳを構成するシグナリング情報の一つが、コンポーネントマッピングディスクリプションに代わって、＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報をもっと有するように拡張されることもできる。
【１２２４】
二つ目、初期化情報が各メディアデータ、つまりサービスコンポーネントのような経路を介して伝達されることもできる。すなわち、サービスコンポーネント（メディアセグメント）が伝達されるＬＣＴセッションを介して、該当のコンポーネントに係わる初期化情報が一緒に伝達されることもできる。この際、該当のデータが一般的なメディアセグメントであるか初期化情報であるかは伝送パケットのヘッダー情報を用いて区別されることができる。このようなヘッダー情報にはＴＯＩ値などがあり得る。
【１２２５】
図１２５は本発明の一実施例による、初期化情報伝達のためのメッセージフォーマットを示す図である。
【１２２６】
ここで、初期化情報伝達のためのメッセージフォーマットとは初期化テーブルのフォーマットを意味することができる。図示の実施例（ｔ７０１０）は前述したシグナリングメッセージフォーマットを基本構造にし、初期化情報送信のために拡張された構造を有するメッセージフォーマットであり得る。初期化情報送信のために、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドをそれぞれＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎとＩＳＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤに分けて定義することができる。
【１２２７】
ＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎはこの初期化テーブルのバージョン乃至プロトコルバージョンを示すことができる。ＩＳＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤはこのテーブルが送信している初期化情報の識別子であって、前述した拡張されたシグナリング情報内の＠ｉｓｄＩｎｓｔａｎｃｅＩＤと一致する値が使われることができる。これにより、各サービスコンポーネントと初期化テーブルの間のマッピングが遂行されることができる。このＩＤはサービスシグナリングチャネル内でユニークに付与されることができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａには初期化情報がバイナリ又はＸＭＬ形態に含まれることができる。すなわち、初期化情報の全部又は一部のデータがこれに含まれることができる。その他の初期化テーブル内の情報は前述したシグナリングメッセージフォーマットで説明したものと同一であり得る。
【１２２８】
図示の他の実施例（ｔ７０２０）は初期化情報伝達のための初期化テーブルの他の実施例である。この実施例は、ＭＰＥＧ−２ＴＳプライベートセクション（ｐｒｉｖａｔｅ ｓｅｃｔｉｏｎ）に基づくフィールド構成を有することができる。ＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、及びＩｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａ）は前述した実施例のそのものと同一であり得る。その他の初期化テーブル内の情報は前述したシグナリングメッセージフォーマットで説明したものと同一であり得る。
【１２２９】
Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａ構造の一実施例が示されている（ｔ７０３０）。このエレメントには該当の初期化情報のＵＲＬ情報である＠ｕｒｌと、初期化情報の実際データ部分であるＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ Ｄａｔａフィールドが含まれることができる。ＵＲＬはＭＰＤに記述された初期化情報（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）のＵＲＬと同一の値を有することができる。このＵＲＬ情報は個別初期化情報とレプリゼンテーションの間のマッピング情報に活用されることもできる。
【１２３０】
図１２６は本発明の他の実施例による、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。
【１２３１】
前述したセッションディスクリプション情報送信のためのセッションディスクリプションテーブルは図示のような構造（ｔ８０１０）を有することもできる。ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは前述したようであり、ＬＳＩＤ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａには後述するＬＳＩＤ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｉｏｎの全部又は一部分にあたるデータがＸＭＬ又はバイナリ形態に含まれることができる。ＬＳＩＤ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｉｏｎはセッションディスクリプション情報伝達に関するディスクリプションであり得る。その他のセッションディスクリプションテーブル内の情報は前述したシグナリングメッセージフォーマットで説明したものと同一であり得る。
【１２３２】
ＬＳＩＤ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｉｏｎ構造の一実施例が示されている（ｔ８０２０）。ＬＳＩＤ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｉｏｎは、＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔ及び／又はＬＳＩＤを含むことができる。＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、及び＠ｄｅｓｔＵＤＰＰｏｒｔはそれぞれ該当のセッションディスクリプション情報が記述するＲＯＵＴＥセッションのソースＩＰ、デスティネーションＩＰ、及びデスティネーションＵＤＰポートナンバー情報を含むことができる。ＬＳＩＤは該当のセッションディスクリプション情報を有することができる。
【１２３３】
図１２７は本発明の一実施例によるサービスデータを処理する方法を示す図である。
【１２３４】
本発明の一実施例によるサービスデータを処理する方法は、放送サービスのサービスコンポーネントを生成する段階、第１シグナリングデータ及び第２シグナリングデータを生成する段階、サービスコンポーネントと第２シグナリングデータを伝送パケットにカプセル化する段階、第１シグナリングデータと伝送パケットを放送ストリームにプロセッシングする段階及び／又は放送ストリームを伝送する段階を含むことができる。ここで、サービスデータを処理する方法は送信側の動作を基準に記述された。
【１２３５】
まず、放送サービスのサービスコンポーネントが生成されることができる（ｔ９０１０）。サービスは一つ以上のサービスコンポーネントを含むことができる。また、第１シグナリングデータ及び／又は第２シグナリングデータが生成されることができる（ｔ９０２０）。ここで、第１シグナリングデータは前述したＳＬＴにあたることができ、第２シグナリングデータは前述したＳＬＳにあたることができる。前述したように、第１シグナリングデータは第２シグナリングデータのを位置を指示するための情報を含み、第２シグナリングデータは放送サービスをシグナリングすることができる。サービスコンポーネント、第１シグナリングデータ及び／又は第２シグナリングデータは第１モジュールによって生成されることができる。ここで、第１モジュールはサービスプロバイダー側でサービスデータを生成するモジュールであり得る。
【１２３６】
生成されたサービスサービスコンポーネントと第２シグナリングデータが伝送パケットにカプセル化されることができる（ｔ９０３０）。ここで、伝送パケットは前述した伝送セッションに伝達されるパケットを意味することができる。実施例によって、伝送パケットはＲＯＵＴＥパケット又はＭＭＴＰパケットであり得る。この伝送パケットは第１伝送セッション又は第２伝送セッションのサブセッションを介して伝送されることができる。ここで、伝送セッションはＲＯＵＴＥセッション又はＭＭＴＰセッションであり得る。サブセッションはＲＯＵＴＥセッションのＬＣＴセッション、又はＭＭＴＰセッションのＭＭＴＰパケットフローを意味することができる。このカプセル化過程は各データがＲＯＵＴＥ／ＭＭＴＰパケットにカプセル化されることを意味することができる。このカプセル化過程は第２モジュールによって遂行されることができる。第２モジュールはＲＯＵＴＥ／ＭＭＴＰパケットへのカプセル化を行うレイヤーを担当するモジュールであり得る。
【１２３７】
その後、第１シグナリングデータ及び／又は伝送パケットが放送ストリームにプロセッシングされることができる（ｔ９０４０）。この過程はＳＬＴ及びＲＯＵＴＥ／ＭＭＴＰパケットにカプセル化されたデータがＩＰ／ＵＤＰにカプセル化されることを意味することができる。また、この過程はこのＩＰ／ＵＤＰに処理されたデータがフィジカルレイヤーでフィジカルレイヤープロセッシングを経る過程を意味することができる。ＩＰ／ＵＤＰカプセル化を経てフィジカルレイヤープロセッシングする過程は第３モジュールによって遂行されることができる。第３モジュールはＩＰ／ＵＤＰカプセル化及びフィジカルレイヤーを担当するモジュールであり得る。
【１２３８】
生成された放送ストリームは伝送されることができる（ｔ９０５０）。これは第４モジュールによって遂行されることができる。第４モジュールは放送ストリームを伝送する伝送モジュールなどにあたることができる。
【１２３９】
本発明の他の実施例によるサービスデータを処理する方法において、第２サービスシグナリングデータは第１伝送セッションの特定のサブセッションを介して伝送されることができる。これは前述したＳＬＳがＲＯＵＴＥセッションの特定のＬＣＴセッション、つまりＴＳＩ＝０を有するＬＣＴセッションを介して伝達されることに対応することができる。また、これはＳＬＳがサービスシグナリングチャネルを介して伝達されることに対応することもできる。ＴＳＩ＝０に識別されるＳＬＳを運ぶサブセッション（ＬＣＴセッション）は実施例によってサービスシグナリングチャネルと呼ばれることもできる。サービスコンポーネントは第１伝送セッション又は第２伝送セッションのサブセッションを介して伝送されることができる。サービスコンポーネントは、前述したように、ＲＯＵＴＥ／ＭＭＴＰセッションのサブセッション（ＬＣＴセッション又はＭＭＴＰパケットフロー）を介して伝達されることができる。
【１２４０】
本発明のさらに他の実施例によるサービスデータを処理する方法において、第１シグナリングデータは第２シグナリングデータが伝送される第１伝送セッションを指示するための情報を含むことができる。これは、前述したＳＬＴがＳＬＳの伝送されるＲＯＵＴＥ／ＭＭＴＰセッションを指示するためのブートストラップ情報を含むものに対応することができる。第２シグナリングデータは放送サービスのサービスコンポーネントへの接近情報を含むことができる。ＳＬＳ、特にその中のＳ−ＴＳＩＤは各サービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ情報を有することができる。また、ＳＬＳの中で、ＭＰＴメッセージは各サービスコンポーネントが伝達されるＭＭＴＰパケットフローのパケットＩＤ情報を有することができる。
【１２４１】
本発明のさらに他の実施例によるサービスデータを処理する方法において、第２シグナリングデータは第１伝送セッションのサブセッションのうち、放送サービスのサービスコンポーネントを伝送するサブセッションを識別する情報をさらに含むことができる。これは前述したＳＬＳが、ＳＬＳが伝送されるＲＯＵＴＥ／ＭＭＴＰセッションを介して伝達されるサービスコンポーネントの接近情報を有することに対応することができる。この場合、ＳＬＳはＴＳＩ情報又はパケットＩＤ情報のみでもサービスコンポーネントを有するサブセッションを識別することができる。同一伝送セッション内であるので、ＩＰアドレスなどの情報が別に必要でないこともできる。
【１２４２】
本発明のさらに他の実施例によるサービスデータを処理する方法において、第２シグナリングデータは放送サービスのサービスコンポーネントを伝送する第２伝送セッションを指示するための情報をさらに含むことができる。サービスコンポーネントがＳＬＳが伝送される伝送セッションとは違う伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のためにＳＬＳは関連情報を有することができる。この情報はＩＰアドレス、ＵＤＰポートナンバーなどの形態であり得る。
【１２４３】
本発明のさらに他の実施例によるサービスデータを処理する方法において、第２シグナリングデータは第２伝送セッションのサブセッションのうち、放送サービスのサービスコンポーネントを伝送するサブセッションを識別する情報をさらに含むことができる。前述したように、サービスコンポーネントがＳＬＳの伝送される伝送セッションとは違う伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のためにＳＬＳはＴＳＩ情報又はパケットＩＤ情報のみでもサービスコンポーネントを有するサブセッションを識別することができる。
【１２４４】
本発明のさらに他の実施例によるサービスデータを処理する方法において、第２シグナリングデータは放送サービスのサービスコンポーネントを伝送するサブセッションが伝達されるフィジカルパス（ｐａｔｈ）を指示する情報をさらに含むことができる。ここで、フィジカルパスはＰＬＰ〜ＤＰを意味することができる。前述したように、サービスコンポーネントがＳＬＳの伝送される伝送セッションとは違う伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のためにＳＬＳは該当のコンポーネントが伝達されるＰＬＰＩＤ情報を有することができる。
【１２４５】
本発明のさらに他の実施例によるサービスデータを処理する方法において、放送サービスのサービスコンポーネントを伝送するサブセッションはサービスコンポーネントに係わる初期化情報を含む伝送パケットをもっと伝達することができる。これは前述した初期化情報がメディアセグメントとともにＬＣＴセッションなどを介して伝達されるものにあたることができる。初期化情報を含む伝送パケットは伝送パケットのヘッダー情報を用いて識別されることができる。前述したように、初期化情報はパケットヘッダーのＴＯＩなどの情報を用いて識別されることができる。
【１２４６】
本発明の一実施例によるサービスデータを処理する方法を受信側で説明する。この方法は図面に示されていない。
【１２４７】
受信側での本発明の一実施例によるサービスデータを処理する方法は、放送信号を受信し、放送信号をパーシングする段階、放送信号から第１シグナリングデータを獲得し、これを用いて第２シグナリングデータを得る段階、第２シグナリングデータを用いて該当のサービスのサービスコンポーネントを得る段階及び／又は該当のサービスコンポーネントを用いてサービスを提供する段階を含むことができる。
【１２４８】
受信側でのサービスデータを処理する方法は、送信側でのモジュールに対応する受信側ハードウェアモジュール（例えば、受信モジュール、パーシングモジュール、再生モジュールなど）によって遂行されることができる。受信側でのサービスデータを処理する方法は、前述した送信側でのサービスデータを処理する方法の実施例に対応する実施例を有することができる。
【１２４９】
前述した段階は実施例によって省略されるか、あるいは類似／同一の動作を行う他の段階に取り替えられることができる。
【１２５０】
図１２８は本発明の一実施例によるサービスデータを処理する装置を示す図である。
【１２５１】
本発明の一実施例によるサービスデータを処理する装置は、前述した第１モジュール、第２モジュール、第３モジュール及び／又は第４モジュールを含むことができる。それぞれのブロック及びモジュールは前述したようである。
【１２５２】
本発明の一実施例によるサービスデータを処理する装置及びその内部モジュール／ブロックは、前述した本発明のサービスデータを処理する方法の実施例を遂行することができる。
【１２５３】
本発明の一実施例によるサービスデータを処理する、受信側の装置を説明する。本発明の一実施例による受信側の装置は示されていない。
【１２５４】
本発明の一実施例によるサービスデータを処理する、受信側の装置は、前述した受信側ハードウェアモジュールを含むことができる。それぞれのブロック及びモジュールは前述したようである。
【１２５５】
本発明の一実施例によるサービスデータを処理する受信側の装置は、前述した本発明のサービスデータを処理する方法の実施例を遂行することができる。
【１２５６】
前述した装置の内部のブロック／モジュールなどはメモリに記憶された連続した過程を行うプロセッサであってもよく、実施例によって装置の内／外部に位置するハードウェアエレメントであり得る。
【１２５７】
前述したモジュールは実施例によって省略されるか、あるいは類似／同一の動作を行う他のモジュールに取り替えられることができる。
【１２５８】
図１２９は本発明の一実施例によるＥＳＧブートストラップ情報を示した図である。
【１２５９】
本発明の一実施例は次世代放送ネットワークで使用可能なＥＳＧブートストラッピングディスクリプション（Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ｄｅｓｃｒｉｐｔｉｏｎ）のシグナリング方法を提供することができる。ＥＳＧブートストラッピングディスクリプションは以下のような情報を含み、該当の情報はシグナリング伝送ロケーションによってバイナリフォーマット又はＸＭＬフォーマットに定義されることができる。
【１２６０】
Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ（ＥＳＧ）ｄａｔａはＳｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｕｎｉｔ（ＳＧＤＵ）及び／又はＳｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｏｒ（ＳＧＤＤ）を含むことができる。ＳＧＤＤはＳＧＤＵがどのデリバリー経路を介して伝送されるかについての情報を含むことができる。ＳＧＤＵはサービス及び／又はプログラムについての情報を含むことができる。例えば、ＳＧＤＵは、サービス情報、プログラム情報、チャネル番号、放送局情報、キャプション、放送等級、及び／又は詳細要旨を含むことができる。サービス情報はサービスの名前及び／又はサービスの識別子を含むことができる。プログラム情報は、プログラムの名前及び／又はプログラムの識別子、プログラム開始時間情報、及び／又はプログラム終了時間情報を含むことができる。ＳＧＤＵはフラグメント単位で構成され、フラグメントの種類は、サービスフラグメント、コンデンツフラグメント、及び／又はスケジュールフラグメントの少なくとも一つを含むことができる。ＳＧＤＤ及びＳＧＤＵはいずれもＸＭＬファイルであり得る。ＥＳＧはＳｅｒｖｉｃｅ Ｇｕｉｄｅ（ＳＧ）及び／又はＥｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ（ＥＰＧ）として表現できる。また、ＥＳＧｄａｔａは簡略にＥＳＧとして表現できる。
【１２６１】
ＥＳＧブートストラッピングディスクリプションはＥｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ（ＥＳＧ）のブートストラッピングのための情報を含むことができる。ＥＳＧブートストラッピングディスクリプションはＥＳＧブートストラップ情報及び／又はＥＳＧのためのブートストラッピング情報によって表現できる。放送受信装置はＥＳＧブートストラッピングディスクリプション及び／又はＥＳＧブートストラップ情報に基づいてＥＳＧを受信、獲得、及び／又は処理することができる。
【１２６２】
ＥＳＧブートストラッピングディスクリプションは少なくとも一つのＳｅｒｖｉｃｅ Ｇｕｉｄｅ（ＳＧ） Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔを含むことができる。
【１２６３】
ＳＧ ＰｒｏｖｉｄｅｒはＥＳＧについての情報を提供する提供者を示すことができる。ＳＧ Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはｎａｍｅ ａｔｔｒｉｂｕｔｅ及び／又は少なくとも一つのＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔを含むことができる。
【１２６４】
ｎａｍｅ ａｔｔｒｉｂｕｔｅはＳＧ Ｐｒｏｖｉｄｅｒの名前を示すことができる。
【１２６５】
Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔは少なくとも一つのブートストラップ情報を含むことができる。Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔは、ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ、ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、ｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔ、ｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔ、ｔｓｉ ｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報であり得る。
【１２６６】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａが伝送されるタイプを指示することができる。具体的に、ｎｅｔｗｏｒｋ＿ｔｙｐｅ ｅｌｅｍｅｎｔはＳＧＤＤが伝送されるタイプを指示することができる。Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれたｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの数は一つであり得る。ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの属性値によって、Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔは以下に定義されたブートストラップ情報を選択的に含むことができる。参考として、「ＥＳＧブートストラッピングディスクリプションが伝送されるタイプ」は「ＥＳＧ ｄａｔａが伝送されるタイプ」に解釈できる。具体的に、「ＥＳＧブートストラッピングディスクリプションが伝送されるタイプ」は「ＳＧＤＤが伝送されるタイプ」に解釈できる。
【１２６７】
ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔはＥＳＧｄａｔａ、及び／又はＳＧ ｄａｔａのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを指示することができる。例えば、ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔはサービス及び／又はＥＳＧについての情報のためのサービスレイヤーシグナリング情報を伝送するパケットのＩＰ ｓｏｕｒｃｅ ａｄｄｒｅｓｓを含むことができる。具体的に、ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔはＳＧＤＤが伝送されるＩＰ ｓｏｕｒｃｅ ａｄｄｒｅｓｓを指示することができる。
【１２６８】
ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａ、及び／又はＳＧ ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを指示することができる。例えば、ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔはサービス及び／又はＥＳＧについての情報のためのサービスレイヤーシグナリング情報を伝送するパケットのＩＰ ｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓを含むことができる。具体的に、ｄｅｓｔＩＰＡｄｄｒｅｌ ｅｍｅｎｔはＳＧＤＤが伝送されるＩＰ ｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓを指示することができる。
【１２６９】
ｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａ、及び／又はＳＧ ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ番号を指示することができる。例えば、ｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔはサービス及び／又はＥＳＧについての情報のためのサービスレイヤーシグナリング情報を伝送するパケットのポート番号を含むことができる。具体的に、ｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔはＳＧＤＤが伝送されるｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ番号を指示することができる。
【１２７０】
ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、及び／又はｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａを伝送するＩＰパケットヘッダーに記述された情報を意味する。
【１２７１】
ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔは、ＥＳＧ ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ Ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。具体的に、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔはＳＧＤＤが伝送される伝送ストリーム識別子を指示することができる。
【１２７２】
ｐａｒｔｉｔｉｏｎＩＤｅｌ ｅｍｅｎｔは、ＥＳＧ ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を指示することができる。例えば、パーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）は放送社を識別することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。具体的に、ｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔはＳＧＤＤが伝送されるパーティション識別子を指示することができる。
【１２７３】
ｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔは、ＥＳＧ ｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。例えば、ＥＳＧ ｄａｔａがブロードキャストネットワークを介して伝送される場合、ｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔは一つの値を含むことができる。具体的に、ｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔはＳＧＤＤが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を指示することができる。
【１２７４】
外部周波数（Ｆｏｒｅｉｇｎ ｆｒｅｑｕｅｎｃｙ）を介して伝送されるＥＳＧ ｄａｔａの情報を知らせるために、Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔは選択的にｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔ、及び／又はｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔを含むことができる。
【１２７５】
ｔｓｉ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。例えば、ＥＳＧ ｄａｔａがブロードキャストを介して伝送される場合、ｔｓｉ ｅｌｅｍｅｎｔは少なくとも一つの値を含むことができる。具体的に、ｔｓｉ ｅｌｅｍｅｎｔはＳＧＤＤが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を指示することができる。
【１２７６】
ｄｏｗｎｌｏａｄＵＲＬｅｌ ｅｍｅｎｔはブロードバンドを介して伝送されるＥＳＧ ｄａｔａに近付くことができるＵＲＬを指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。例えば、ＥＳＧ ｄａｔａがブロードバンドを介して伝送される場合、ｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔは一つの値を含むことができる。具体的に、ｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔはＳＧＤＤが伝送されるＵＲＬを指示することができる。
【１２７７】
ＥＳＧｄａｔａがブロードキャストを介して伝送されるかそれともブロードバンドを介して伝送されるかによって、Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔはｔｓｉ ｅｌｅｍｅｎｔ及び／又はｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。
【１２７８】
放送伝送装置はサービスデータ及びシグナリング情報を含む放送信号を伝送することができる。シグナリング情報はＥＳＧブートストラップ情報を含むことができる。放送受信装置はサービスデータ及びシグナリング情報を含む放送信号を受信することができる。放送受信装置はシグナリング情報に含まれたＥＳＧブートストラップ情報に基づいてＥＳＧデータを獲得及び／又は処理することができる。
【１２７９】
図１３０は本発明の一実施例によるＥＳＧブートストラップ情報が伝送されるタイプを示した図である。
【１２８０】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅはＥＳＧ ｄａｔａが伝送されるタイプを指示することができる。ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値は固定された値ではなく、変更可能である。多くのタイプのＥＳＧ ｄａｔａが伝送される場合、それぞれのｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅを有するＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔが多数伝送されることができる。
【１２８１】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値が‘０ｘ０１’であれば、ＥＳＧ ｄａｔａは同一周波数内でＡＴＳＣ３．０ブロードキャストを介して伝送されることができる。この場合、放送受信装置は同一周波数内でＥＳＧ ｄａｔａを受信することができる。
【１２８２】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値が‘０ｘ０２’であれば、ＥＳＧ ｄａｔａは他の周波数内でＡＴＳＣ３．０ブロードキャストを介して伝送されることができる。この場合、放送受信装置は他の周波数内でＥＳＧ ｄａｔａを受信することができる。
【１２８３】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値が‘０ｘ０３’であれば、ＥＳＧ ｄａｔａはＡＴＳＣ３．０ブロードキャスト以外のＩＰブロードキャストを介して伝送されることができる。この場合、放送受信装置はＩＰブロードキャストを介してＥＳＧ ｄａｔａを受信することができる。
【１２８４】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値が‘０ｘ０４’であれば、ＥＳＧ ｄａｔａはブロードバンドを介して伝送されることができる。この場合、放送受信装置はブロードバンドを介してＥＳＧ ｄａｔａを受信することができる。
【１２８５】
図１３１は本発明の第１実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【１２８６】
本発明の第１実施例は次世代放送ネットワークでＥＳＧブートストラップ情報をＦａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）のＥＳＧブートストラッピングディスクリプタの形態で伝送する方法を提供することができる。本発明の第１実施例において、ＥＳＧは放送サービスに定義されない。また、ＦＩＣはＳｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ（ＳＬＴ）と言える。ＳＬＴは基本的なサービスリストを樹立し（ｂｕｉｌｄｉｎｇ）、サービスレイヤーシグナリング情報（ＳＬＳ）の発見をブートストラップするのに使われるシグナリング情報テーブルである。
【１２８７】
図面を参照すると、放送信号及び／又はアクチュアルストリームは特定の周波数の少なくとも一つの放送ストリームを含むことができる。例えば、アクチュアルストリーム（Ａｃｔｕａｌ Ｓｔｒｅａｍ）は「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。
【１２８８】
それぞれの放送ストリームは少なくとも一つのパーティションを含むことができる。それぞれのパーティションはそれぞれの放送社にあたることができる。あるいは、それぞれのパーティションはそれぞれの放送社から伝送する放送ストリームであり得る。
【１２８９】
それぞれのパーティションは少なくとも一つのＤＰ（又はＰＬＰ）及び／又はＦＩＣを含むことができる。例えば、第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰの識別子（ＤＰＩＤ）は‘１’であり得る。第２ＤＰの識別子（ＤＰＩＤ）は‘２’であり得る。第３ＤＰの識別子（ＤＰＩＤ）は‘３’であり得る。
【１２９０】
一つのＤＰは一つのＲｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＲＯＵＴＥ）セッションを含むことができる。また、複数のＤＰが一つのＲＯＵＴＥセッションを含むことができる。ＲＯＵＴＥセッションは少なくとも一つのサービス及び／又は少なくとも一つのコンポーネントを含むことができる。ＲＯＵＴＥセッションはＩＰ／ＵＤＰデータグラムと言える。
【１２９１】
例えば、第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。すなわち、第１ＲＯＵＴＥセッションは第１ＤＰを介して伝送される。第１ＲＯＵＴＥセッションは第１ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、第１ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、及び／又は第１ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒに特定されることができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／Ｖ Ｓｅｒｖｉｃｅ）を含むことができる。
【１２９２】
第１ＲＯＵＴＥセッションは少なくとも一つの伝送セッション（又はＬＣＴセッション）を含むことができる。例えば、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。
【１２９３】
第１伝送セッション（ｔｓｉ−ｖ）はビデオコンポーネントを含むことができる。ビデオコンポーネントはビデオデータを含む少なくとも一つのビデオセグメントを含むことができる。第２伝送セッション（ｔｓｉ−ａ）はオーディオコンポーネントを含むことができる。オーディオコンポーネントはオーディオデータを含む少なくとも一つのオーディオセグメントを含むことができる。第３伝送セッション（ｔｓｉ−ｓ）はサービスシグナリングチャネルコンポーネントを含むことができる。サービスシグナリングチャネルコンポーネントは、Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ（ＳＭＴ）、Ｃｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ（ＣＭＴ）、Ｇｕｉｄｅ Ａｃｃｅｓｓ Ｔａｂｌｅ（ＧＡＴ）、及び／又はＤＡＳＨ Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）の少なくとも一つを含むことができる。第４伝送セッション（ｔｓｉ−０）はＬＣＴ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）を含むことができる。ＬＳＩＤはＳｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ（Ｓ−ＴＳＩＤ）と言える。Ｓ−ＴＳＩＤはサービスの少なくとも一つのコンデンツコンポーネントを伝送する少なくとも一つの伝送セッションのための全体的なセッションディスクリプション情報を含むことができる。
【１２９４】
第２ＤＰ及び第３ＤＰは第２ＲＯＵＴＥセッションを含むことができる。すなわち、第２ＲＯＵＴＥセッションは第２ＤＰ及び／又は第３ＤＰを介して伝送される。第２ＲＯＵＴＥセッションは、第２ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、第２ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、及び／又は第２ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒに特定されることができる。
【１２９５】
第２ＲＯＵＴＥセッションは少なくとも一つの伝送セッション（又はＬＣＴセッション）を含むことができる。例えば、第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−１０１）、及び／又は第７伝送セッション（ｔｓｉ−１０２）を含むことができる。伝送セッション（又はＬＣＴセッション）は少なくとも一つの伝送オブジェクトを含むことができる。
【１２９６】
第５伝送セッション（ｔｓｉ−０）はＬＳＩＤを含むことができる。
【１２９７】
第６伝送セッション（ｔｓｉ−１０１）は、第１伝送オブジェクト（ｔｏｉ−０）及び／又は第２伝送オブジェクト（ｔｏｉ−１）を含むことができる。第１伝送オブジェクト（ｔｏｉ−０）はファイルデリバリーセッション内で伝送されるファイル及び／又はファイルの伝送に関連した属性を提供するＦｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ（ＦＤＴ）を含むことができる。あるいは、第１伝送オブジェクト（ｔｏｉ−０）はファイルデリバリーデータの詳細内容を明示するＥＦＤＴを含むことができる。第２伝送オブジェクト（ｔｏｉ−１）はＳｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｕｎｉｔ（ＳＧＤＵ）がどのデリバリー経路を介して伝送されるかについての情報を記述するＳｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｏｒ（ＳＧＤＤ）を含むことができる。
【１２９８】
第７伝送セッション（ｔｏｉ−１０２）は、第３伝送オブジェクト（ｔｏｉ−０）、第４伝送オブジェクト（ｔｏｉ−１）、及び／又は第５伝送オブジェクト（ｔｏｉ−２）を含むことができる。第３伝送オブジェクト（ｔｏｉ−０）はＦＤＴ及び／又はＥＦＤＴを含むことができる。第４伝送オブジェクト（ｔｏｉ−１）はＳＧＤＵを含むことができる。第５伝送オブジェクト（ｔｏｉ−２）はＳＧＤＵを含むことができる。ＳＧＤＵはフラグメント単位で構成され、フラグメントの種類はサービスフラグメント、コンデンツフラグメント、及び／又はスケジュールフラグメントの少なくとも一つを含むことができる。ＳＧＤＵはＥＳＧデータを含むことができる。ＳＧＤＤ及びＳＧＤＵはいずれもＸＭＬファイルであり得る。
【１２９９】
放送伝送装置はサービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、シグナリング情報はＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３００】
放送伝送装置はＦＩＣを含む放送信号を伝送することができる。
【１３０１】
ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを指示するＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプションを含むことができる。
【１３０２】
ＳＳＣブートストラップ情報（ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）はＳＭＴ及び／又はＣＭＴが伝送されるＳｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ（ＳＳＣ）についての情報を含むことができる。本発明の第１実施例において、ＥＳＧは別個の一つのサービスに定義されないため、ＦＩＣはサービスループ（Ｓｅｒｖｉｃｅ ｌｏｏｐ）にＳＳＣブートストラップ情報を含まないこともできる。
【１３０３】
本発明の第１実施例によるＦＩＣはＥＳＧブートストラップ情報をパーティションレベルのディスクリプタの形態に含むことができる。
【１３０４】
ＥＳＧブートストラップ情報は前述したＥＳＧブートストラップ情報及び／又はＥＳＧブートストラップディスクリプションと同一の情報を含むことができる。例えば、ＥＳＧブートストラップ情報はｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔ及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔを含むことができる。
【１３０５】
ｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはプロバイダーの数を指示することができる。
【１３０６】
Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔは提供者についての情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報を含むことができる。また、Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａ及び／又はＥＳＧについての情報を提供する提供者についての情報を含むことができる。Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔは前述したＳＧ Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔを示すことができる。それぞれのＰｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ、ｔｓｉ ａｔｔｒｉｂｕｔｅ、ＤＰ ａｔｔｒｉｂｕｔｅ、及び／又はＵＲＬ ａｒｒｔｉｂｕｔｅの少なくとも一つを含むことができる。
【１３０７】
ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅはＥＳＧ ｄａｔａが伝送されるタイプを指示することができる。ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅは前述したｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅを示すことができる。
【１３０８】
ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅはＥＳＧ ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ Ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を指示することができる。ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅは前述したｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔを示すことができる。
【１３０９】
ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅはＥＳＧ ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を指示することができる。ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅは前述したｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔを示すことができる。
【１３１０】
Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔはＲＯＵＴＥセッションを識別する情報を含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔはＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションブートストラップ情報はＲＯＵＴＥセッションの伝送経路情報を含むことができる。例えば、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ） ａｔｔｒｉｂｕｔｅ及び／又はｐｏｒｔ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。ＩＰ（ｓｒｃ／ｄｅｓｔ） ａｔｔｒｉｂｕｔｅは前述したｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ及びｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔを含むことができる。ｐｏｒｔ ａｔｔｒｉｂｕｔｅは前述したｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔを示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、及びｐｏｒｔ ｅｌｅｍｅｎｔの組合せは特定のＲＯＵＴＥセッションを識別することができる。
【１３１１】
ｔｓｉ ａｔｔｒｉｂｕｔｅはＥＳＧ ｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を指示することができる。例えば、ｔｓｉ ａｔｔｒｉｂｕｔｅはＳＧＤＤが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を指示することができる。図面を参照すると、例えば、ｔｓｉ ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−１０１」であり得る。
【１３１２】
ＤＰ ａｔｔｒｉｂｕｔｅはＥＳＧ ｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を指示することができる。ＤＰ ａｔｔｒｉｂｕｔｅは前述したｄａｔａｐｉｐｅＩＤｅｌ ｅｍｅｎｔを示すことができる。例えば、ＤＰ ａｔｔｒｉｂｕｔｅはＳＧＤＤが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を指示することができる。図面を参照すると、例えば、ＤＰ ａｔｔｒｉｂｕｔｅの値は「２」であり得る。
【１３１３】
ＵＲＬ ａｒｒｔｉｂｕｔｅはブロードバンドを介して伝送されるＥＳＧ ｄａｔａに近付くことができるＵＲＬを指示することができる。ＵＲＬ ａｒｒｔｉｂｕｔｅは前述したｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔを示すことができる。
【１３１４】
本発明の第１実施例によるＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。
【１３１５】
放送伝送装置はＬＳＩＤを含む放送信号を伝送することができる。
【１３１６】
例えば、第５伝送セッション（ｔｓｉ−０）に含まれたＬＳＩＤは、第６伝送セッションについての情報を含む第６伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第７伝送セッションについての情報を含む第７伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。
【１３１７】
それぞれの第６伝送セッションエレメント（ＴＳＩ−１０１）及び第７伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションが伝送されるＤＰを識別するＤＰ ａｔｔｒｉｂｕｔｅ、伝送セッションに含まれるソースフローについての情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアーフローについての情報を提供するＲｅｐａｉｒＦｌｏｗエレメントの少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントはＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するかを指示するｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間で伝送されることを指示することができる。また、例えば、ｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間で伝送されることを指示することができる。
【１３１８】
放送受信装置はＳＧＤＤを介して第７伝送セッションエレメント（ＴＳＩ−１０２）を獲得することができるが、該当の伝送セッションに伝送されるＳＧＤＵのＤＰ情報を得ることができないことができる。よって、本発明の第１実施例による放送伝送装置はＤＰ情報を含むＬＳＩＤを伝送することができる。
【１３１９】
放送受信装置はサービスデータ及びシグナリング情報を含む放送信号を受信することができる。シグナリング情報はＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３２０】
放送受信装置はＦＩＣを獲得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されることができる。
【１３２１】
放送受信装置はＦＩＣに基づいてＥＳＧブートストラップ情報及び／又はＬＳＩＤを獲得することができる。放送受信装置はＦＩＣのパーティションレベルディスクリプションに基づいてＥＳＧブートストラップ情報を獲得することができる。ＥＳＧブートストラップ情報はＦＩＣにパーティションレベルディスクリプタの形態に含まれることができる。本発明の第１実施例ではＥＳＧを別個の一つのサービスに定義しないため、ＦＩＣはサービスループ（Ｓｅｒｖｉｃｅ ｌｏｏｐ）にＳＳＣブートストラップ情報を含まないこともできる。ＬＳＩＤはそれぞれの伝送セッション別に伝送Ｄａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むことができる。また、放送受信装置はＥＳＧブートストラップ情報に含まれたＲＯＵＴＥセッションブートストラップ情報に基づいてＬＳＩＤを獲得することができる。この場合、ＬＳＩＤは前もって決定された伝送セッションを介して伝送されることができ、放送受信装置はＲＯＵＴＥセッションブートストラップ情報及び／又は前もって決定された伝送セッション情報に基づいてＬＳＩＤを獲得することができる。あるいは、放送受信装置はＦＩＣに含まれた別個のＬＳＩＤ伝送経路情報に基づいてＬＳＩＤを獲得することができる。
【１３２２】
放送受信装置はＥＳＧブートストラップ情報及び／又はＬＳＩＤに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。
【１３２３】
本発明の第１実施例による放送伝送装置がＥＳＧ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｃｈａｎｎｅｌ情報を獲得してＥＳＧデータを伝送（又はｄｅｌｉｖｅｒｙ）するためには、放送伝送装置はＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を付け加えることができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置はそれぞれの伝送セッション別にＤａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを獲得することができる。
【１３２４】
また、本発明の第１実施例による放送伝送装置はＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０ Ｐｒｏｆｉｌｅを付け加え、Ｄａｔａ ｐｉｐｅｌｉｎｅ情報を付け加えることができる。この場合、放送受信装置はＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを獲得することができる。
【１３２５】
図１３２は本発明の第２実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【１３２６】
本発明の第２実施例は次世代放送ネットワークでＥＳＧブートストラッピング情報をＦＩＣのＥＳＧブートストラッピングディスクリプタの形態で伝送する方法を提供することができる。本発明の第２実施例において、ＥＳＧは一つの放送サービスに定義されることができる。また、ＦＩＣのサービスループ（ｓｅｒｖｉｃｅ ｌｏｏｐ）内でＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙ ｅｌｅｍｅｎｔは該当のサービスがＥＳＧサービスであることを指示することができる。放送受信装置はＥＳＧブートストラップ情報をＦＩＣでＥＳＧブートストラッピングディスクリプタの形態で受信することができる。また、放送受信装置はＥＳＧブートストラップ情報を介してＥＳＧを獲得することができる。
【１３２７】
図面を参照すると、本発明の第２実施例によるアクチュアルストリーム（Ａｃｔｕａｌ Ｓｔｒｅａｍ）は「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例による放送ストリームは第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は第１ＤＰ、第２ＤＰ、第３ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／Ｖ Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。第２ＤＰ及び第３ＤＰは第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−１０１）、及び／又は第７伝送セッション（ｔｓｉ−１０２）を含むことができる。本発明の第２実施例によるＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。この図面に示されたアクチュアルストリーム（Ａｃｔｕａｌ Ｓｔｒｅａｍ）に対する内容は前述したアクチュアルストリーム（Ａｃｔｕａｌ Ｓｔｒｅａｍ）に対する内容を全て含むことができる。
【１３２８】
放送伝送装置はサービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報はＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３２９】
放送伝送装置はＦＩＣを含む放送信号を伝送することができる。
【１３３０】
ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを指示するＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。ＳＳＣＩＰ／Ｐｏｒｔエレメントは、ＳＳＣを伝送するｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、及び／又はＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを含むことができる。
【１３３１】
ＳＧＤＤが伝送される伝送セッションはＬＳＩＤが伝送される伝送セッションとは違うことができる。この場合、ＳＳＣブートストラップ情報（ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）はＥＳＧブートストラッピング情報に取り替えられることができる。例えば、ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは同一周波数内でＡＴＳＣ３．０ Ｂｒｏａｄｃａｓｔを介して伝送されるＥＳＧ ｄａｔａを識別するＥＳＧブートストラップ情報であり得る。この場合、ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントはＳＳＣについての情報を含まないことができる。ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントがＥＳＧブートストラップ情報を含むという内容はＦＩＣのＳｅｍａｎｔｉｃｓに含まれることができる。ＥＳＧブートストラップ情報はＥＳＧ ｄａｔａ及び／又はＳＧＤＤが伝送される経路を識別する情報であり得る。また、ＦＩＣはＳＳＣ及び／又はＬＳＩＤのブートストラップ情報及び／又は伝送経路についての情報を別にもっと含むことができる。また、ＳＳＣ及び／又はＬＳＩＤは前もって定義された特定の伝送セッションを介して伝送されることができる。
【１３３２】
ＳＧＤＤが伝送される伝送セッションはＬＳＩＤが伝送される伝送セッションと同一であることができる。すなわち、ＬＳＩＤはＳＧＤＤを含むことができる。この場合、ＳＳＣブートストラップ情報はＥＳＧブートストラップ情報にあたることができる。すなわち、ＳＳＣブートストラップ情報及び／又はＥＳＧブートストラッピング情報は、ＳＳＣ、ＬＳＩＤ、ＥＳＧ ｄａｔａ、及び／又はＳＧＤＤを識別することができる。例えば、ＳＳＣ ＩＰ／ＰｏｒｔエレメントはＳＳＣ、ＬＳＩＤ、ＥＳＧ ｄａｔａ、及び／又はＳＧＤＤを伝送するＩＰ／Ｐｏｒｔを識別することができる。ＳＳＣＤＰ＿ＩＤエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧ ｄａｔａ、及び／又はＳＧＤＤを伝送するＤＰを識別することができる。ＴＳＩエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧ ｄａｔａ、及び／又はＳＧＤＤを伝送する伝送セッションを識別することができる。ＳＳＣ ＩＰ／Ｐｏｒｔエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧ ｄａｔａ、及び／又はＳＧＤＤを伝送するｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、及び／又はＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒを含むことができる。この場合にも、ＳＳＣ及び／又はＬＳＩＤは前もって定義された特定の伝送セッションを介して伝送されることができる。
【１３３３】
また、ＦＩＣのパーティションレベルのディスクリプタは更なるＥＳＧブートストラップ情報をさらに含むことができる。例えば、パーティションレベルのディスクリプタに含まれるＥＳＧブートストラップ情報はｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔ及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔを含むことができる。例えば、Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔは提供者についての情報を含むことができる。また、Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａ及び／又はＥＳＧについての情報を提供する提供者についての情報を含むことができる。Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅ、ＳｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ、及び／又はＵＲＬ ａｒｒｔｉｂｕｔｅの少なくとも一つを含むことができる。ＳｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅはサービスを識別することができる。ＥＳＧブートストラップ情報に含まれるエレメント及び属性に対する内容は前述した内容と同一である。
【１３３４】
本発明の第２実施例によるＥＳＧは一つのサービスに定義されることができる。また、ＦＩＣサービスループ（Ｓｅｒｖｉｃｅ ｌｏｏｐ）内のＳＳＣブートストラップ情報はＥＳＧブートストラップ情報に活用できる。
【１３３５】
これにより、ＦＩＣのサービスループ（Ｓｅｒｖｉｃｅ ｌｏｏｐ）内のＳＳＣブートストラップ情報に対するｓｅｍａｎｔｉｃｓ定義時に別個の定義方案が必要であるが、ＦＩＣの大きさ増加を該当の情報の長さの分だけ減らすことができる利点がある。ＳＳＣブートストラップ情報を用いて表現することができないｎｅｔｗｏｒｋ ｔｙｐｅを介して伝送されるＥＳＧブートストラップ情報はパーティションレベル（ｐａｒｔｉｔｉｏｎ ｌｅｖｅｌ）のディスクリプタを介して別個の情報を伝送するようにする。
【１３３６】
本発明の第２実施例によるＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示することができる。
【１３３７】
放送伝送装置はＬＳＩＤを含む放送信号を伝送することができる。
【１３３８】
例えば、第５伝送セッション（ｔｓｉ−０）に含まれたＬＳＩＤは、第６伝送セッションについての情報を含む第６伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第７伝送セッションについての情報を含む第７伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。本発明の第２実施例によるＬＳＩＤは前述したＬＳＩＤに対する内容を全て含むことができる。
【１３３９】
放送受信装置はＳＧＤＤを介して第７伝送セッションエレメント（ＴＳＩ−１０２）を獲得することができるが、該当の伝送セッションを介して伝送されるＳＧＤＵのＤＰ情報を得ることができないこともある。したがって、本発明の第１実施例による放送伝送装置はＤＰ情報を含むＬＳＩＤを伝送することができる。
【１３４０】
放送受信装置はサービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報はＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３４１】
放送受信装置はＦＩＣを獲得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されることができる。
【１３４２】
放送受信装置はＦＩＣに基づいてＳＳＣブートストラップ情報及び／又はＥＳＧブートストラップ情報を獲得することができる。ＦＩＣはＥＳＧブートストラップ情報を含むことができる。
【１３４３】
ＳＧＤＤの伝送される伝送セッションがＬＳＩＤの伝送される伝送セッションとは違う場合、ＦＩＣのＳＳＣブートストラップ情報（ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）はＥＳＧブートストラッピング情報に取り替えられることができる。また、ＦＩＣはＳＳＣ及び／又はＬＳＩＤをブートストラップ及び／又は識別する別個の情報をさらに含むことができる。
【１３４４】
ＳＧＤＤの伝送される伝送セッションがＬＳＩＤの伝送される伝送セッションと同一である場合、ＳＳＣブートストラップ情報はＥＳＧブートストラップ情報にあたることができる。すなわち、ＳＳＣブートストラップ情報及び／又はＥＳＧブートストラッピング情報は、ＳＳＣ、ＬＳＩＤ、ＥＳＧｄａｔａ、及び／又はＳＧＤＤを識別することができる。以下では、ＳＧＤＤの伝送される伝送セッションがＬＳＩＤの伝送される伝送セッションと同一である場合を中心に説明する。
【１３４５】
また、ＦＩＣのパーティションレベルのディスクリプタは更なるＥＳＧブートストラップ情報をさらに含むことができる。ＬＳＩＤはそれぞれの伝送セッション別に伝送Ｄａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むことができる。
【１３４６】
放送受信装置はＦＩＣに基づいてＬＳＩＤを獲得することができる。例えば、放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＬＳＩＤを獲得することができる。
【１３４７】
また、放送受信装置はＦＩＣに基づいてＥＳＧブートストラップ情報を獲得することができる。例えば、ＦＩＣのＳＳＣブートストラップ情報はＥＳＧブートストラップ情報にあたることができる。
【１３４８】
放送受信装置はＥＳＧブートストラップ情報及び／又はＬＳＩＤに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。
【１３４９】
本発明の第２実施例による放送伝送装置がＥＳＧ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｃｈａｎｎｅｌ情報を獲得してＥＳＧデータを送信（又はｄｅｌｉｖｅｒｙ）するためには、放送伝送装置はＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を付け加えることができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置はそれぞれの伝送セッション別にＤａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを獲得することができる。
【１３５０】
また、本発明の第２実施例による放送伝送装置はＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０ Ｐｒｏｆｉｌｅを付け加え、Ｄａｔａ ｐｉｐｅｌｉｎｅ情報を付け加えることができる。この場合、放送受信装置はＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを獲得することができる。
【１３５１】
図１３３は本発明の第３実施例によるＥＳＧブートストラッピングディスクリプションのシグナリングを示した図である。
【１３５２】
本発明の第３実施例は次世代放送ネットワークでＥＳＧブートストラップ情報をＳＭＴのＲＯＵＴＥセッションエレメントを用いて伝送する方法を提供することができる。ＥＳＧは一つの別個のＳｅｒｖｉｃｅに定義されることができる。ＦＩＣのサービスループ（Ｓｅｒｖｉｃｅ ｌｏｏｐ）でＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示することができる。ＳＳＣチャネルを介してＳＭＴとＣＭＴが伝送されることができる。しかし、ＳＭＴｓｅｍａｎｔｉｃｓ定義を変更して定義するようにしなければならない。
【１３５３】
図面を参照すると、本発明の第３実施例によるアクチュアルストリーム（Ａｃｔｕａｌ Ｓｔｒｅａｍ）は「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例による放送ストリームは第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／Ｖ Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。この図に示された第１ＲＯＵＴＥセッションに対する内容は前述したＲＯＵＴＥセッションに対する内容を全て含むことができる。
【１３５４】
第２ＤＰ、第３ＤＰ、及び第４ＤＰは第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。
【１３５５】
第５伝送セッション（ｔｓｉ−０）はＬＳＩＤを含むことができる。
【１３５６】
第６伝送セッション（ｔｓｉ−ｓｓｃ）はＳＭＴ及び／又はＣｏｍｐｏｎｅｎｔ ｍａｐｐｉｎｇ ｔａｂｌｅ（ＣＭＴ）を含むことができる。
【１３５７】
第７伝送セッション（ｔｓｉ−１０１）は、第１伝送オブジェクト（ｔｏｉ−０）及び／又は第２伝送オブジェクト（ｔｏｉ−１）を含むことができる。第１伝送オブジェクトはＦＤＴ及び／又はＥＦＤＴを含むことができる。第２伝送オブジェクト（ｔｏｉ−１）はＳＧＤＤを含むことができる。
【１３５８】
第８伝送セッション（ｔｏｉ−１０２）は、第３伝送オブジェクト（ｔｏｉ−０）、第４伝送オブジェクト（ｔｏｉ−１）、及び／又は第５伝送オブジェクト（ｔｏｉ−２）を含むことができる。第３伝送オブジェクト（ｔｏｉ−０）はＦＤＴ及び／又はＥＦＤＴを含むことができる。第４伝送オブジェクト（ｔｏｉ−１）はＳＧＤＵを含むことができる。第５伝送オブジェクト（ｔｏｉ−２）はＳＧＤＵを含むことができる。ＳＧＤＵはＥＳＧデータを含むことができる。
【１３５９】
放送伝送装置はサービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１３６０】
放送伝送装置はＦＩＣを含む放送信号を伝送することができる。
【１３６１】
ＦＩＣはパーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを指示するＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。
【１３６２】
ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントはＳＳＣブートストラップ情報であり得る。ＳＳＣブートストラッピング情報はＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは同一周波数内でＡＴＳＣ３．０ Ｂｒｏａｄｃａｓｔを介して伝送されるＳＳＣブートストラッピング情報であり得る。本発明の第３実施例によるＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。
【１３６３】
本発明の第３実施例によるＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示することができる。
【１３６４】
放送伝送装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つを含む放送信号を伝送することができる。
【１３６５】
ＳＭＴは、ｓｅｒｖｉｃｅＩＤ ｅｌｅｍｅｎｔ、ｃａｔｅｇｏｒｙ ｅｌｅｍｅｎｔ、ｎｕｍ＿ｏｆ ＬＳＩＤ ｅｌｅｍｅｎｔ、少なくとも一つのＬＳＩＤ ｅｌｅｍｅｎｔ、ｎｕｍ＿ｏｆ Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔ、及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。
【１３６６】
ｓｅｒｖｉｃｅＩＤ ｅｌｅｍｅｎｔはサービスを識別することができる。ｃａｔｅｇｏｒｙ ｅｌｅｍｅｎｔはサービスのカテゴリーを識別することができる。例えば、サービスのカテゴリーはＥＳＧサービスを含むことができる。
【１３６７】
ｎｕｍ＿ｏｆＬＳＩＤ ｅｌｅｍｅｎｔはＬＳＩＤの数を指示することができる。ＬＳＩＤ ｅｌｅｍｅｎｔはＬＳＩＤについての情報を含むことができる。
【１３６８】
ＬＳＩＤ ｅｌｅｍｅｎｔはＲＯＵＴＥセッションブートストラップ情報を含むことができる。例えば、ＬＳＩＤ ｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ（又はａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ）、及び／又はＵＲＬ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ） ｅｌｅｍｅｎｔ、ｐｏｒｔ ｅｌｅｍｅｎｔ、ｔｓｉ ｅｌｅｍｅｎｔ、及び／又はＤＰ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。ＬＳＩＤ ｅｌｅｍｅｎｔに含まれるエレメント及び／又は属性に対する内容は前述した内容と同一である。また、たとえｅｌｅｍｅｎｔとａｔｔｒｉｂｕｔｅの間に違いがあっても、含まれる情報は同一であることができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔはＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションブートストラップ情報はＬＳＩＤの伝送経路についての情報を含むことができる。
【１３６９】
ｎｕｍ＿ｏｆ Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧについての情報を提供する提供者の数を指示することができる。Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔは提供者についての情報を含むことができる。
【１３７０】
Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報を含むことができる。また、Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａ及び／又はＥＳＧについての情報を提供する提供者についての情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ（又はａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ）、及び／又はＵＲＬ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ） ｅｌｅｍｅｎｔ、ｐｏｒｔ ｅｌｅｍｅｎｔ、ｔｓｉ ｅｌｅｍｅｎｔ、及び／又はＤＰ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔに含まれるエレメント及び／又は属性に対する内容は前述した内容と同一である。また、たとえ、ｅｌｅｍｅｎｔとａｔｔｒｉｂｕｔｅの間に違いがあっても、含まれる情報は同一であることができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ又はａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報を含むことができる。ＥＳＧブートストラップ情報はＥＳＧ ｄａｔａの伝送経路についての情報を含むことができる。例えば、ＩＰ（ｓｒｃ／ｄｅｓｔ） ｅｌｅｍｅｎｔ及びｐｏｒｔ ｅｌｅｍｅｎｔが第２ＲＯＵＴＥセッションを指示し、ｔｓｉ ｅｌｅｍｅｎｔの値が第５伝送セッション（ｔｓｉ−１０１）を指示し、ＤＰ ｅｌｅｍｅｎｔの値が第２ＤＰ（ＤＰ ＩＤ＝２）を指示することができる。
【１３７１】
第５伝送セッションに含まれたＬＳＩＤは、第６伝送セッションについての情報を含む第６伝送セッションエレメント（図示せず）、第７伝送セッションについての情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）、及び／又は第８伝送セッションについての情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、ＳｏｕｒｃｅＦｌｏｗエレメント、及び／又はＲｅｐａｉｒＦｌｏｗエレメントの少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントはｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間で伝送されることを指示することができる。
【１３７２】
ＣＭＴはサービス内のコンポーネントデータの獲得経路及び／又は伝送経路についての情報を含むことができる。また、ＣＭＴはブロードバンドを介して伝送されるコンポーネントについての情報を含むことができる。また、ＣＭＴは他のブロードキャストストリームにあるコンポーネントについての情報を含むことができる。ＣＭＴに関する内容は前述したＣＭＴに関する内容を全て含むことができる。例えば、ＣＭＴはｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ及び／又はｃｏｍｐｅｌｅｍｅｎｔを含むことができる。ｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅはサービスを識別することができる。ｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅは該当のコンポーネントに関連したサービスを識別する識別子である。ｃｏｍｐ ｅｌｅｍｅｎｔは該当のサービス内のコンポーネントについての情報を含むことができる。例えば、ｃｏｍｐ ｅｌｅｍｅｎｔは、同じ放送ストリームを介して伝送されるコンポーネントについての情報、ブロードバンドネットワークを介して伝送されるコンポーネント、及び／又は他の放送ストリームを介して伝送されるコンポーネントの少なくとも一つを含むことができる。ｃｏｍｐ ｅｌｅｍｅｎｔは、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとｍａｐｐｉｎｇされるｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅ、放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションを識別するｔｓｉ ａｔｔｒｉｂｕｔｅ、及び放送ストリーム内で該当のコンポーネントデータが伝送されるＤＰを識別するＤＰ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。放送受信装置はＣＭＴに基づいてサービスのコンポーネントを獲得することができる。
【１３７３】
放送受信装置はサービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報はＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１３７４】
放送受信装置はＦＩＣを獲得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されることができる。
【１３７５】
放送受信装置はＦＩＣに基づいてＳＳＣブートストラップ情報を獲得することができる。ＳＳＣはＳＭＴ及び／又はＣＭＴを含むことができる。
【１３７６】
放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを獲得することができる。ＳＭＴはＬＳＩＤエレメント及び／又はＰｏｒｖｉｄｅｒエレメントの少なくとも一つを含むことができる。ＬＳＩＤエレメントはＲＯＵＴＥセッションエレメントを含むことができる。ＬＳＩＤエレメントのＲＯＵＴＥセッションエレメントはＬＳＩＤ伝送経路情報を含むことができる。ＰｏｒｖｉｄｅｒエレメントのＲＯＵＴＥセッションエレメントはＥＳＧブートストラップ情報を含むことができる。
【１３７７】
Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙがＥＳＧサービスを指示する場合、ＳＭＴはＥＳＧブートストラップ情報を含むことができる。例えば、Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙがＥＳＧサービスを指示する場合、ＳＭＴに記述されたＬＳＩＤ伝送経路情報はＥＳＧブートストラップ情報に取り替えられることができる。ＳＭＴは、これに限定されずに、ＬＳＩＤ伝送経路情報及び／又はＥＳＧブートストラップ情報を全て含むことができる。
【１３７８】
放送受信装置はＳＭＴに基づいてＬＳＩＤ及び／又はＥＳＧブートストラップ情報を獲得することができる。Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙがＥＳＧサービスを指示する場合、ＳＭＴに記述されたＬＳＩＤ伝送経路情報はＥＳＧブートストラップ情報に取り替えられることができる。また、具体的に、ＳＭＴに含まれたＩＰ（ｓｒｃ／ｄｅｓｔ） ｅｌｅｍｅｎｔ、ｐｏｒｔ ｅｌｅｍｅｎｔ、ｔｓｉ ｅｌｅｍｅｎｔ、及び／又はＤＰ ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報であり得る。ＲＯＵＴＥセッションエレメントは、これに限定されず、ＬＳＩＤ及び／又はＥＳＧブートストラップ情報を全て含むことができ、放送受信装置はＳＭＴに基づいてＬＳＩＤ伝送経路情報及び／又はＥＳＧブートストラップ情報を全て獲得することができる。
【１３７９】
放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを獲得することができる。
【１３８０】
放送受信装置はＣＭＴに基づいてコンポーネントマッチング情報を獲得することができる。例えば、ＣＭＴはＣｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅ、ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又はＤＰ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１３８１】
放送受信装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。例えば、放送受信装置はＣＭＴのｔｓｉ ａｔｔｒｉｂｕｔｅに基づいてＬＳＩＤに記述される伝送セッションを獲得し、これにマッピングされるＤＰ情報を獲得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉ ａｔｔｒｉｂｕｔｅ及び／又はＤＰ ａｔｔｒｉｂｕｔｅに基づいて実際のコンポーネントを獲得することができる。例えば、実際コンポーネントはＥＳＧサービスのためのコンポーネントであり得る。
【１３８２】
具体的に、放送受信装置はＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報の少なくとも一つに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを獲得することができる。そして、放送受信装置はＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを獲得することができる。
【１３８３】
ＥＳＧデータも一つのファイルに定義することができるから、放送受信装置はＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅに基づいてＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置はｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅに基づいてＥＳＧサービスのためのＥＳＧデータを獲得することができる。この場合、ＥＳＧサービスはＥＳＧデータを含むファイルとして提供されることができる。
【１３８４】
本発明の第３実施例による放送伝送装置がＥＳＧ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｃｈａｎｎｅｌ情報を獲得してＥＳＧデータを伝送（又はｄｅｌｉｖｅｒｙ）するためには、放送伝送装置はＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を付け加えることができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントはＤＰ ａｔｔｒｉｂｕｔｅを含むこともできる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置はそれぞれの伝送セッション別にＤａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを獲得することができる。
【１３８５】
また、本発明の第３実施例による放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０Ｐｒｏｆｉｌｅを付け加えてＤａｔａ ｐｉｐｅｌｉｎｅ情報を付け加えることができる。この場合、放送受信装置はＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを獲得することができる。
【１３８６】
図１３４は本発明の第４実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【１３８７】
本発明の第４実施例は次世代放送ネットワークでＥＳＧブートストラップ情報をＳＭＴのサービスレベルディスクリプタを用いて伝送する方法を提供することができる。ＥＳＧは一つの別個のサービスに定義され、ＦＩＣのサービスループ（Ｓｅｒｖｉｃｅ ｌｏｏｐ）でＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示し、ＳＳＣチャネルを介してＳＭＴとＣＭＴが伝送されることができる。ＥＳＧサービスにマッピングされるＳＭＴはＥＳＧブートストラップディスクリプタを含むことができ、ＥＳＧブートストラップディスクリプタはサービスレベルディスクリプタに定義されることができる。
【１３８８】
図面を参照すると、本発明の第４実施例によるアクチュアルストリーム（Ａｃｔｕａｌ Ｓｔｒｅａｍ）は「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例による放送ストリームは第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／Ｖ Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。この図に示された第１ＲＯＵＴＥセッションに対する内容は前述した第１ＲＯＵＴＥセッションに対する内容を全て含むことができる。
【１３８９】
第２ＤＰ、第３ＤＰ、及び第４ＤＰは第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。この図に示された第２ＲＯＵＴＥセッションに対する内容は前述した第２ＲＯＵＴＥセッションに対する内容を全て含むことができる。
【１３９０】
放送伝送装置はサービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報はＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１３９１】
放送伝送装置はＦＩＣを含む放送信号を伝送することができる。
【１３９２】
ＦＩＣは前述したＦＩＣに関する内容を全て含むことができる。例えば、ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを指示するＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。
【１３９３】
ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントはＳＳＣブートストラップ情報であり得る。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは同一周波数内でＡＴＳＣ３．０ Ｂｒｏａｄｃａｓｔに伝送されるＳＳＣブートストラッピング情報であり得る。本発明の第４実施例によるＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。
【１３９４】
本発明の第４実施例によるＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示することができる。
【１３９５】
放送伝送装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つを含む放送信号を伝送することができる。
【１３９６】
ＳＭＴは前述したＳＭＴに関する内容を全て含むことができる。例えば、ＳＭＴはサービスを識別するｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ、サービスのカテゴリーを指示するｃａｔｅｇｏｒｙ ａｔｔｒｉｂｕｔｅ、ＲＯＵＴＥセッションについての情報を含む少なくとも一つのＲＯＵＴＥセッションエレメント、及び／又は少なくとも一つのサービスレベルディスクリプタを含むことができる。ＲＯＵＴＥセッションエレメントはＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションエレメントはＬＳＩＤブートストラップ情報（又はＬＳＩＤ伝送経路情報）を含むことができる。ｃａｔｅｇｏｒｙ ａｔｔｒｉｂｕｔｅはＥＳＧサービスを指示することができる。
【１３９７】
サービスレベルディスクリプタはＥＳＧブートストラップ情報を含むことができる。本発明の第４実施例によるＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを指示すれば、ＳＭＴはＥＳＧブートストラップ情報を含むサービスレベルのディスクリプタを含むことができる。放送伝送装置はサービスレベルのディスクリプタを介してＥＳＧブートストラップ情報を伝送することができる。
【１３９８】
ＬＳＩＤは前述したＬＳＩＤに関する内容を全て含むことができる。例えば、ＬＳＩＤは、第７伝送セッションについての情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第８伝送セッションについての情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションに含まれるソースフローについての情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアーフローについての情報を提供するＲｅｐａｉｒＦｌｏｗエレメントの少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するかを指示するｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間で伝送されることを指示することができる。また、例えば、ｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間で伝送されることを指示することができる。
【１３９９】
ＣＭＴは前述したＣＭＴに関する内容を全て含むことができる。例えば、ＣＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ及び／又は該当のサービス内のコンポーネントについての情報を含むｃｏｍｐ ｅｌｅｍｅｎｔを含むことができる。ｃｏｍｐ ｅｌｅｍｅｎｔは、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングされるｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅ、放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションを識別するｔｓｉ ａｔｔｒｉｂｕｔｅ、及び放送ストリーム内で該当のコンポーネントデータが伝送されるＤＰを識別するＤＰ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１４００】
放送受信装置はサービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報はＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１４０１】
放送受信装置はＦＩＣを獲得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されることができる。例えば、Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示することができる。また、ＦＩＣはサービスループ内にＳＳＣブートストラップ情報を含むことができる。ＳＳＣはＳＭＴ及び／又はＣＭＴを含むことができる。
【１４０２】
放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを獲得することができる。ＳＭＴは少なくとも一つのＲＯＵＴＥセッションエレメント及び／又は少なくとも一つのサービスレベルディスクリプタを含むことができる。
【１４０３】
放送受信装置はＳＭＴに含まれたＲＯＵＴＥセッションエレメントに基づいてＬＳＩＤを獲得することができる。ＲＯＵＴＥセッションエレメントはＲＯＵＴＥセッションブートストラップ情報を含むことができ、ＲＯＵＴＥセッションブートストラップ情報はＬＳＩＤ伝送経路情報を含むことができる。
【１４０４】
また、放送受信装置はＳＭＴに含まれたサービスレベルディスクリプタからＥＳＧブートストラップ情報を獲得することができる。Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを指示すれば、ＳＭＴはＥＳＧブートストラップ情報を含むサービスレベルのディスクリプタを含むことができる。
【１４０５】
放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを獲得することができる。放送受信装置はＣＭＴに基づいてコンポーネントマッチング情報を獲得することができる。例えば、ＣＭＴはＣｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅ、ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又はＤＰ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１４０６】
放送受信装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。例えば、放送受信装置はＣＭＴのｔｓｉ ａｔｔｒｉｂｕｔｅに基づいてＬＳＩＤで記述する伝送セッションを獲得し、これにマッピングされるＤＰ情報を獲得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉ ａｔｔｒｉｂｕｔｅ及び／又はＤＰ ａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを獲得することができる。例えば、実際コンポーネントはＥＳＧサービスのためのコンポーネントであり得る。
【１４０７】
具体的に、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報の少なくとも一つに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを獲得することができる。そして、放送受信装置はＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを獲得することができる。
【１４０８】
ＥＳＧデータも一つのファイルに定義することができるから、放送受信装置はＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅに基づいてＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置はｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅに基づいてＥＳＧサービスのためのＥＳＧデータを獲得することができる。この場合、ＥＳＧサービスはＥＳＧデータを含むファイルとして提供されることができる。
【１４０９】
本発明の第４実施例による放送伝送装置がＥＳＧ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｃｈａｎｎｅｌ情報を獲得してＥＳＧデータを伝送（又はｄｅｌｉｖｅｒｙ）するために、放送伝送装置はＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を付け加えることができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントはＤＰ ａｔｔｒｉｂｕｔｅを含むこともできる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを獲得することができる。
【１４１０】
また、本発明の第４実施例による放送伝送装置はＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０ Ｐｒｏｆｉｌｅを付け加えてＤａｔａ ｐｉｐｅｌｉｎｅ情報を付け加えることができる。この場合、放送受信装置はＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを獲得することができる。
【１４１１】
図１３５は本発明の第５実施例によるＥＳＧブートストラップ情報のシグナリングを示した図である。
【１４１２】
本発明の第５実施例は次世代放送ネットワークでＥＳＧブートストラップ情報をＧｕｉｄｅ Ａｃｃｅｓｓ Ｔａｂｌｅ（ＧＡＴ）を用いて伝送する方法を提供することができる。ＥＳＧは一つの別個のサービスに定義され、ＦＩＣのサービスループでサービスＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙはＥＳＧサービスを指示し、ＳＳＣチャネルを介してＳＭＴ、ＧＡＴ、及び／又はＣＭＴが伝送されることができる。ＥＳＧサービスにマッピングされるＳＭＴはＬＳＩＤが伝送されるＲＯＵＴＥセッション情報を含むことができる。本発明の第５実施例において、ＥＳＧサービスに対するＳＳＣはＧＡＴを含み、ＧＡＴはＥＳＧブートストラップ情報を含むことができる。
【１４１３】
図面を参照すると、本発明の第５実施例によるアクチュアルストリーム（Ａｃｔｕａｌ Ｓｔｒｅａｍ）は「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例による放送ストリームは第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／Ｖ Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。この図に示された第１ＲＯＵＴＥセッションに対する内容は前述した第１ＲＯＵＴＥセッションに対する内容を全て含むことができる。
【１４１４】
第２ＤＰ、第３ＤＰ、及び第４ＤＰは第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。この図に示された第２ＲＯＵＴＥセッションに対する内容は前述した第２ＲＯＵＴＥセッションに対する内容を全て含むことができる。
【１４１５】
放送伝送装置はサービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１４１６】
放送伝送装置はＦＩＣを含む放送信号を伝送することができる。
【１４１７】
ＦＩＣは前述したＦＩＣに関する内容を全て含むことができる。例えば、ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを指示するＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。
【１４１８】
ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントはＳＳＣブートストラップ情報であり得る。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣ ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは同一周波数内でＡＴＳＣ３．０ Ｂｒｏａｄｃａｓｔを介して伝送されるＳＳＣブートストラッピング情報であり得る。本発明の第５実施例によるＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。
【１４１９】
本発明の第５実施例によるＳｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示することができる。また、Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示すれば、ＧＡＴが必須に伝送されることができる。
【１４２０】
放送伝送装置は、ＳＭＴ、ＣＭＴ、ＧＡＴ、及び／又はＬＳＩＤの少なくとも一つを含む放送信号を伝送することができる。
【１４２１】
ＳＭＴは前述したＳＭＴに関する内容を全て含むことができる。例えば、ＳＭＴはサービスを識別するｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ、ＲＯＵＴＥセッションについての情報を含む少なくとも一つのＲＯＵＴＥセッションエレメントを含むことができる。ＲＯＵＴＥセッションエレメントはＲＯＵＴＥセッションブートストラップ情報（又は、ＬＳＩＤブートストラップ情報、ＬＳＩＤ伝送経路情報）を含むことができる。
【１４２２】
ＧＡＴはサービスに係わるサービスガイド（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ、ＳＧ）データソースについての情報を含むことができる。例えば、ＧＡＴはサービスを識別するｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ、サービスガイド提供者の数を指示するｎｕｍ＿ｏｆ＿ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔ、及び／又はサービスガイド提供者についての情報を含む少なくとも一つのＰｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔ（サービスガイド提供者エレメント）を含むことができる。
【１４２３】
Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａ及び／又はＥＳＧについての情報を提供する提供者についての情報を含むことができる。また、ＥＳＧブートストラップ情報は、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ、及び／又はＵＲＬ ａｒｒｔｉｂｕｔｅの少なくとも一つを含むことができる。
【１４２４】
ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅはＥＳＧブートストラッピングディスクリプションが伝送されるタイプを指示することができる。ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅは前述したｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅを示すことができる。
【１４２５】
ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラップ情報が外部周波数（Ｆｏｒｅｉｇｎ Ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を指示することができる。ｔｓ＿ＩＤ ａｔｔｒｉｂｕｔｅは前述したｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔを示すことができる。
【１４２６】
ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラップ情報が外部周波数（Ｆｏｒｅｉｇｎ ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を指示することができる。ｐａｒｔｉｔｉｏｎＩＤ ａｔｔｒｉｂｕｔｅは前述したｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔを示すことができる。
【１４２７】
Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔはＲＯＵＴＥセッションを識別する情報を含むことができる。例えば、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ） ｅｌｅｍｅｎｔ、ｐｏｒｔ ｅｌｅｍｅｎｔ、ａｎｎｏｕｎｃｅｍｅｎｔ＿ｔｓｉ ｅｌｅｍｅｎｔ、及びａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。ＩＰ（ｓｒｃ／ｄｅｓｔ） ａｔｔｒｉｂｕｔｅは、前述したｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ及びｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔを含むことができる。ｐｏｒｔ ａｔｔｒｉｂｕｔｅは前述したｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔを示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、及びｐｏｒｔ ｅｌｅｍｅｎｔの組合せは特定のＲＯＵＴＥセッションを識別することができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ｔｓｉ ｅｌｅｍｅｎｔはＥＳＧサービス及び／又はＥＳＧブートストラップ情報が伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を指示することができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰ ｅｌｅｍｅｎｔはＥＳＧサービス及び／又はＥＳＧブートストラップ情報が伝送されるＰＬＰ及び／又はＤＰを識別する識別子を指示することができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰ ｅｌｅｍｅｎｔは前述したｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔを示すことができる。
【１４２８】
ＵＲＬ ｅｌｅｍｅｎｔはブロードバンドを介して伝送されるＥＳＧブートストラップ情報及び／又はＥＳＧのためのシグナリング情報に近付くことができるＵＲＬを指示することができる。ＵＲＬ ｅｌｅｍｅｎｔは前述したｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔを示すことができる。
【１４２９】
ＣＭＴは前述したＣＭＴに関する内容を全て含むことができる。例えば、ＣＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ及び／又は該当のサービス内のコンポーネントについての情報を含むｃｏｍｐｅｌ ｅｍｅｎｔを含むことができる。ｃｏｍｐ ｅｌｅｍｅｎｔはＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングされるｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅ、放送ストリーム内で該当のコンポーネントデータが伝送される伝送セッションを識別するｔｓｉ ａｔｔｒｉｂｕｔｅ、及び放送ストリーム内で該当のコンポーネントデータが伝送されるＤＰを識別するＤＰ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１４３０】
ＬＳＩＤは前述したＬＳＩＤに関する内容を全て含むことができる。例えば、ＬＳＩＤは、第７伝送セッションについての情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第８伝送セッションについての情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションに含まれるソースフローについての情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアーフローについての情報を提供するＲｅｐａｉｒＦｌｏｗエレメントの少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントはＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するかを指示するｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間で伝送されることを指示することができる。また、例えば、ｒｅａｌｔｉｍｅ ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間で伝送されることを指示することができる。
【１４３１】
放送受信装置はサービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報はＦＩＣ、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１４３２】
放送受信装置はＦＩＣを獲得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されることができる。例えば、Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを指示することができる。また、ＦＩＣはサービスループ内にＳＳＣブートストラップ情報を含むことができる。また、Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを指示すれば、ＧＡＴが必須に伝送されることができる。
【１４３３】
放送受信装置はＦＩＣに基づいてＳＳＣブートストラップ情報を獲得することができる。ＳＳＣは、ＳＭＴ、ＣＭＴ、及び／又はＧＡＴを含むことができる。
【１４３４】
放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを獲得することができる。放送受信装置は、ＳＭＴに含まれたＲＯＵＴＥセッションエレメントに基づいて、ＲＯＵＴＥブートストラップ情報（又は、ＬＳＩＤブートストラップ情報、及びＬＳＩＤ伝送経路情報）を獲得することができる。また、放送受信装置はＳＭＴに基づいてＬＳＩＤを獲得することができる。具体的に、放送受信装置はＳＭＴのＲＯＵＴＥブートストラップ情報に基づいてＬＳＩＤを獲得することができる。
【１４３５】
放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＧＡＴを獲得することができる。また、放送受信装置はＧＡＴからＥＳＧブートストラップ情報を獲得することができる。
【１４３６】
放送受信装置はＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを獲得することができる。また、放送受信装置はＣＭＴに基づいてコンポーネントマッチング情報を獲得することができる。例えば、ＣＭＴは、ＣｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅ、ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又はＤＰ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１４３７】
放送受信装置は、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスを獲得することができる。例えば、放送受信装置は、ＣＭＴのｔｓｉ ａｔｔｒｉｂｕｔｅに基づいてＬＳＩＤで記述する伝送セッションを獲得し、これにマッピングされるＤＰ情報を獲得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉ ａｔｔｒｉｂｕｔｅ及び／又はＤＰ ａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを獲得することができる。例えば、実際コンポーネントはＥＳＧサービスのためのコンポーネントであり得る。
【１４３８】
具体的に、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報の少なくとも一つに基づいてＥＳＧ ｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを獲得することができる。そして、放送受信装置はＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを獲得することができる。
【１４３９】
ＥＳＧデータも一つのファイルに定義することができるから、放送受信装置はＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅに基づいてＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置はｃｏｎｔｅｎｔＬｉｎｋａｇｅ ａｔｔｒｉｂｕｔｅに基づいてＥＳＧサービスのためのＥＳＧデータを獲得することができる。この場合、ＥＳＧサービスはＥＳＧデータを含むファイルとして提供されることができる。
【１４４０】
本発明の第５実施例による放送伝送装置がＥＳＧ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｃｈａｎｎｅｌ情報を獲得してＥＳＧデータを伝送（又はｄｅｌｉｖｅｒｙ）するために、放送伝送装置はＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を付け加えることができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントはＤＰ ａｔｔｒｉｂｕｔｅを含むこともできる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置はそれぞれの伝送セッション別にＤａｔａ ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを獲得することができる。
【１４４１】
また、本発明の第５実施例による放送伝送装置はＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０ Ｐｒｏｆｉｌｅを付け加えてＤａｔａ ｐｉｐｅｌｉｎｅ情報を付け加えることができる。この場合、放送受信装置はＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを獲得することができる。
【１４４２】
図１３６は本発明の第５実施例によるＧＡＴを示した図である。
【１４４３】
本発明による次世代放送ネットワークで使用可能なシグナリング情報のフォーマットは次のようであることができる。シグナリング情報はシグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。シグナリングメッセージは、ｂｉｎａｒｙあるいはＸＭＬフォーマットなどで表現できる。また、シグナリングメッセージはＩＰデータグラム又はａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔパケット（例えば、ＲＯＵＴＥあるいはＭＭＴなど）のペイロードとして含まれて伝送されることができる。例えば、シグナリングメッセージはＧＡＴを含むことができる。
【１４４４】
シグナリングメッセージヘッダーは、Ｓｉｇｎａｌｉｎｇ＿ｉｄ ｅｌｅｍｅｎｔ及び／又はＳｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ ｅｌｅｍｅｎｔはシグナリングメッセージの識別子を示すことができる。例えば、Ｓｉｇｎａｌｉｎｇ＿ｉｄ ｅｌｅｍｅｎｔはＧＡＴシグナリングメッセージを指示することができる。Ｓｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔはサービスの識別子を示すことができる。例えば、Ｓｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔはＥＳＧサービスを指示することができる。一方、ＳＭＴにはＳｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔにマッピングされる識別子が存在することができる。
【１４４５】
ＧＡＴは少なくとも一つのサービスレベルのディスクリプタを含むことができる。例えば、ＧＡＴはＥＳＧブートストラッピングディスクリプタを含むことができる。
【１４４６】
ＥＳＧブートストラッピングディスクリプションはＥｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ（ＥＳＧ）のブートストラッピングのための情報を含むことができる。ＥＳＧブートストラッピングディスクリプションは、ＥＳＧブートストラップ情報及び／又はＥＳＧのためのブートストラッピング情報を含むことができる。放送受信装置は、ＥＳＧブートストラッピングディスクリプション及び／又はＥＳＧブートストラップ情報に基づいてＥＳＧを受信、獲得、及び／又は処理することができる。
【１４４７】
ＥＳＧブートストラッピングディスクリプションは少なくとも一つのＳｅｒｖｉｃｅ Ｇｕｉｄｅ（ＳＧ） Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔを含むことができる。
【１４４８】
ＳＧ ＰｒｏｖｉｄｅｒはＥＳＧについての情報を提供する提供者を示すことができる。ＳＧ Ｐｒｏｖｉｄｅｒ ｅｌｅｍｅｎｔはｎａｍｅ ａｔｔｒｉｂｕｔｅ及び／又は少なくとも一つのＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔを含むことができる。
【１４４９】
ｎａｍｅ ａｔｔｒｉｂｕｔｅはＳＧ Ｐｒｏｖｉｄｅｒの名前を示すことができる。
【１４５０】
Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔは少なくとも一つのブートストラッピング情報を含むことができる。Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔは、ｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ、ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔ、ｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔ、ｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔ、ｔｓｉ ｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報であり得る。
【１４５１】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａが伝送されるタイプを指示することができる。
【１４５２】
ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔは、ＥＳＧ ｄａｔａ、及び／又はＳＧ ｄａｔａのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを指示することができる。例えば、ｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧについての情報のためのサービスレイヤーシグナリング情報を伝送するパケットのＩＰｓｏｕｒｃｅ ａｄｄｒｅｓｓを含むことができる。
【１４５３】
ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔは、ＥＳＧ ｄａｔａ、及び／又はＳＧ ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを指示することができる。例えば、ｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔはサービス及び／又はＥＳＧについての情報のためのサービスレイヤーシグナリング情報を伝送するパケットのＩＰ ｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓを含むことができる。
【１４５４】
ｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔは、ＥＳＧ ｄａｔａ、及び／又はＳＧ ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ番号を指示することができる。例えば、ｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧについての情報のためのサービスレイヤーシグナリング情報を伝送するパケットのポート番号を含むことができる。
【１４５５】
ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔは、ＥＳＧ ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ Ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。
【１４５６】
ｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔは、ＥＳＧ ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ ｆｒｅｑｕｅｎｃｙ）を介して伝送される場合、該当の周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を指示することができる。例えば、パーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）は放送社を識別することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。
【１４５７】
ｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。例えば、ＥＳＧ ｄａｔａがブロードキャストを介して伝送される場合、ｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔは一つの値を含むことができる。
【１４５８】
ｔｓｉ ｅｌｅｍｅｎｔはＥＳＧ ｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。例えば、ＥＳＧ ｄａｔａがブロードキャストを介して伝送される場合、ｔｓｉ ｅｌｅｍｅｎｔは少なくとも一つの値を含むことができる。
【１４５９】
ｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔはブロードバンドを介して伝送されるＥＳＧ ｄａｔａに近付くことができるＵＲＬを指示することができる。この値はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔに含まれることができる。例えば、ＥＳＧ ｄａｔａがブロードバンドを介して伝送される場合、ｄｏｗｎｌｏａｄＵＲＬ ｅｌｅｍｅｎｔは一つの値を含むことができる。
【１４６０】
放送伝送装置はサービスデータ及びシグナリング情報を含む放送信号を伝送することができる。サービスデータはＥＳＧサービスを含むことができる。シグナリング情報はＧＡＴを含み、ＧＡＴはサービスレベルディスクリプタにＥＳＧブートストラップ情報を含むことができる。放送受信装置はサービスデータ及びシグナリング情報を含む放送信号を受信することができる。放送受信装置はシグナリング情報に含まれたＥＳＧブートストラップ情報に基づいてＥＳＧサービスを獲得及び／又は処理することができる。
【１４６１】
図１３７は本発明の第１実施例乃至第５実施例の効果を示した図である。
【１４６２】
本発明の第１実施例の効果を説明する。
【１４６３】
ＦＩＣ Ｐｕｒｐｏｓｅ（Ｆａｓｔ ｃｈａｎｎｅｌ ｓｃａｎ）に関し、本発明の第１実施例では、Ｆａｓｔ Ｓｃａｎとは関係ない情報が繰り返し伝送されることができる。例えば、ＦＩＣはパーティションレベルのディスクリプタにＥＳＧブートストラップ情報を含むことができる。よって、本発明の第１実施例では、ＥＳＧブートストラップ情報が繰り返し伝送されることができる。
【１４６４】
ＦＩＣ ｓｉｚｅに関し、本発明の第１実施例では、ＥＳＧがサービスに定義されないから、サービスループ（ｓｅｒｖｉｃｅ ｌｏｏｐ）から除かれる大きさ（ｓｉｚｅ）の分だけＦＩＣの大きさを減らすことができる。例えば、サービスループからＳＳＣブートストラップ情報が除かれる大きさの分だけＦＩＣの大きさを減らすことができる。また、ＥＳＧブートストラップ情報の分だけＦＩＣの大きさが増加することができる。
【１４６５】
ＦＩＣ ｓｅｍａｎｔｉｃｓ定義に関し、本発明の第１実施例では、ＥＳＧがサービスに定義されないから、ＦＩＣ ｓｅｍａｎｔｉｃｓ定義は明らかである。例えば、サービスループにはＥＳＧブートストラップ情報が含まれず、パーティションレベルのディスクリプタにＥＳＧブートストラップ情報が含まれる。
【１４６６】
ＥＳＧブートストラップ情報獲得時間に関連し、本発明の第１実施例では、ＥＳＧブートストラップ情報が変更されるとき、ＦＩＣも継続的に変更される。よって、本発明の第１実施例では、ＦＩＣに含まれたＥＳＧブートストラップ情報を速かに獲得することができる。
【１４６７】
明確なｓｅｍａｎｔｉｃｓ定義に関し、本発明の第１実施例では、ＥＳＧがサービスに定義されないから、ＦＩＣ ｓｅｍａｎｔｉｃｓ定義は明らかである。
【１４６８】
ＬＳＩＤの拡張に関連し、本発明の第１実施例では、ＤＰ情報のマッピングのためにＬＳＩＤにおけるＴＳＩとＤＰのマッピングに関する定義が必要である。
【１４６９】
一貫性に関し、本発明の第１実施例では、ＦＩＣは一貫性を維持し、ＳＳＣは存在しないこともできる。
【１４７０】
本発明の第２実施例の効果を説明する。
【１４７１】
ＦＩＣ Ｐｕｒｐｏｓｅ（Ｆａｓｔｃｈａｎｎｅｌｓｃａｎ）に関し、本発明の第２実施例では、Ｆａｓｔ Ｓｃａｎとは関係ない情報が繰り返し伝送されることができる。例えば、ＦＩＣはサービスループのＳＳＣブートストラップ情報がＥＳＧブートストラップ情報に取り替えられることができる。あるいは、ＳＳＣブートストラップ情報がＥＳＧブートストラップ情報にあたることができる。したがって、本発明の第２実施例では、ＥＳＧブートストラップ情報が繰り返し伝送されることができる。
【１４７２】
ＦＩＣ ｓｉｚｅに関連し、本発明の第２実施例では、ＦＩＣが、ＥＳＧブートストラップ情報のために、ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ ｎｕｍｂｅｒ、ＴＳＩ情報、及び／又はＤＰ情報などを含む場合には、ＦＩＣの大きさが増加しない。しかし、ＦＩＣがＥＳＧブートストラップ情報のために外部周波数（ｆｏｒｅｉｇｎ ｆｒｅｑｕｅｎｃｙ）のブロードキャスト情報及びブロードバンド情報を含む場合には、ＦＩＣの大きさが増加することができる。
【１４７３】
ＦＩＣ ｓｅｍａｎｔｉｃｓの定義に関し、本発明の第２実施例では、Ｓｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙ別にＳＳＣの用途が変わることができる。例えば、Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙがＥＳＧサービスを指示すれば、ＳＳＣブートストラップ情報はＥＳＧブートストラップ情報に取り替えられることができる。あるいは、ＳＳＣブートストラップ情報がＥＳＧブートストラップ情報にあたることができる。Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙがＥＳＧサービスを指示しなければ、ＳＳＣブートストラップ情報は元の目的のどおりに使われることができる。
【１４７４】
ＥＳＧブートストラップ情報獲得時間に関連し、本発明の第２実施例では、ＥＳＧブートストラップ情報が変更されるとき、ＦＩＣも継続的に変更される。したがって、本発明の第２実施例では、ＦＩＣに含まれたＥＳＧブートストラップ情報を速かに獲得することができる。
【１４７５】
明確なｓｅｍａｎｔｉｃｓの定義に関し、本発明の第２実施例では、Ｓｅｒｖｉｃｅ ＣａｔｅｇｏｒｙによるＳＳＣブートストラップ情報の定義が変更されることができる。また、本発明の第２実施例では、シグナリング情報はＳＭＴ及び／又はＣＭＴを含まないことができる。
【１４７６】
ＬＳＩＤの拡張に関連し、本発明の第２実施例では、ＤＰ情報のマッピングのためにＬＳＩＤにおけるＴＳＩとＤＰのマッピングに関する定義が必要である。
【１４７７】
一貫性に関連し、本発明の第２実施例では、サービスがＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙに分類されるにもかかわらず、シグナリング情報にＳＭＴ及び／又はＣＭＴが含まれないことができる。
【１４７８】
本発明の第３実施例の効果を説明する。
【１４７９】
ＦＩＣ ｓｉｚｅに関連し、本発明の第３実施例では、ＥＳＧサービスのためのＦＩＣの大きさはＡ／ＶサービスのためのＦＩＣの大きさと同一であることができる。
【１４８０】
ＦＩＣ ｓｅｍａｎｔｉｃｓの定義に関し、本発明の第３実施例では、ＦＩＣはＳＳＣが伝送される情報を指示するＳＳＣブートストラップ情報を含むことができる。
【１４８１】
ＥＳＧブートストラップ情報獲得時間に関し、本発明の第３実施例では、ＥＳＧブートストラップ情報はＦＩＣに含まれないから、第１実施例及び第２実施例よりはＥＳＧブートストラップ情報の獲得が遅れることができる。
【１４８２】
サービスシグナリング帯域幅（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｂａｎｄｗｉｄｔｈ）に関し、本発明の第３実施例では、ＳＭＴをたびたび送信しなければならないという点を考慮すれば、ＥＳＧブートストラップ情報をディスクリプタに入れれば、シグナリング帯域幅（Ｓｉｇｎａｌｉｎｇ Ｂａｎｄｗｉｄｔｈ）の側面で効率性はちょっと落ちることができる。
【１４８３】
明確なｓｅｍａｎｔｉｃｓの定義に関し、本発明の第３実施例では、ＳＭＴのＬＳＩＤ伝送情報に対する定義と提供者（Ｐｒｏｖｉｄｅｒ）に対する定義を区分しなければならない。
【１４８４】
ＬＳＩＤの拡張に関し、本発明の第３実施例では、ＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要であることができる。ＣＭＴはＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。
【１４８５】
本発明の第４実施例の効果を説明する。
【１４８６】
ＦＩＣ ｓｉｚｅに関連し、本発明の第４実施例では、ＥＳＧサービスのためのＦＩＣの大きさはＡ／ＶサービスのためのＦＩＣの大きさと同一であることができる。
【１４８７】
ＦＩＣ ｓｅｍａｎｔｉｃｓの定義に関し、本発明の第４実施例では、ＦＩＣはＳＳＣが伝送される情報を指示するＳＳＣブートストラップ情報を含むことができる。
【１４８８】
ＥＳＧブートストラップ情報獲得時間に関し、本発明の第４実施例では、ＥＳＧブートストラップ情報はＦＩＣに含まれないから、第１実施例及び第２実施例よりはＥＳＧブートストラップ情報の獲得が遅れることができる。ただ、本発明の第４実施例によるＥＳＧブートストラップ情報獲得時間は本発明の第３実施例によるＥＳＧブートストラップ情報獲得時間とは同一であり得る。
【１４８９】
サービスシグナリング帯域幅（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｂａｎｄｗｉｄｔｈ）に関し、本発明の第４実施例では、ＳＭＴをたびたび送信しなければならないという点を考慮すれば、ＥＳＧブートストラップ情報をディスクリプタに入れれば、シグナリング帯域幅（Ｓｉｇｎａｌｉｎｇ Ｂａｎｄｗｉｄｔｈ）の側面で効率性はちょっと落ちることができる。
【１４９０】
明確なｓｅｍａｎｔｉｃｓの定義に関し、本発明の第４実施例では、ＦＩＣはＳＳＣブートストラップ情報を含み、ＳＭＴはＥＳＧブートストラップ情報を含むから、明確なＳｅｍａｎｔｉｃｓの定義が可能である。
【１４９１】
ＬＳＩＤの拡張に関し、本発明の第４実施例では、ＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要であることができる。ＣＭＴはＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。
【１４９２】
一貫性に関し、本発明の第４実施例では、ＳＭＴのサービスレベルディスクリプタにＥＳＧブートストラップ情報が伝送される点が一貫しないことができる。
【１４９３】
本発明の第５実施例の効果を説明する。
【１４９４】
ＦＩＣ ｓｉｚｅに関連し、本発明の第５実施例では、ＥＳＧサービスのためのＦＩＣの大きさはＡ／ＶサービスのためのＦＩＣの大きさと同一であることができる。
【１４９５】
ＦＩＣ ｓｅｍａｎｔｉｃｓの定義に関し、本発明の第５実施例では、ＦＩＣはＳＳＣが伝送される情報を指示するＳＳＣブートストラップ情報を含むことができる。
【１４９６】
ＥＳＧブートストラップ情報獲得時間に関し、本発明の第５実施例によるＥＳＧブートストラップ情報獲得時間は本発明の第４実施例によるＥＳＧブートストラップ情報獲得時間よりは遅れることができる。
【１４９７】
サービスシグナリング帯域幅（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｂａｎｄｗｉｄｔｈ）に関し、本発明の第５実施例では、ＧＡＴをＳＭＴより頻繁に送信しなければ、帯域幅（Ｂａｎｄｗｉｄｔｈ）を減らすことができる。
【１４９８】
明確なｓｅｍａｎｔｉｃｓの定義に関し、本発明の第５実施例では、ＦＩＣはＳＳＣブートストラップ情報を含み、ＳＭＴはＲＯＵＴＥブートストラップ情報（ＬＳＩＤ伝送経路情報）を含み、ＧＡＴはＥＳＧブートストラップ情報を含むから、明確なＳｅｍａｎｔｉｃｓの定が義可能である。
【１４９９】
ＬＳＩＤの拡張に関し、本発明の第５実施例では、ＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要であることができる。ＣＭＴはＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。
【１５００】
図１３８は本発明の一実施例による放送受信装置の流れ図を示した図である。
【１５０１】
本発明の一実施例による放送受信装置は、ブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部の少なくとも一つを含むことができる。本発明の一実施例によるブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部は前述した内容を全て含むことができる。
【１５０２】
例えば、ブロードキャストインターフェースは放送ネットワークを介して放送信号を受信することができる。ブロードキャストインターフェースは、フィジカルレイヤーモジュール及びフィジカルレイヤーＩＰフレームモジュールを含むことができる。あるいは、ブロードキャストインターフェースは、チューナー及びフィジカルフレームパーサーの少なくとも一つを含むことができる。
【１５０３】
例えば、ブロードバンドインターフェースはインターネットを介してデータを伝送及び／又は受信することができる。ブロードバンドインターフェースはインターネット接近制御モジュールを含むことができる。
【１５０４】
例えば、制御部は、前述したシグナリングデコーダー、データベース、サービスシグナリングマネージャー、アラートシグナリングマネージャー、サービスガイドマネージャー、アプリケーションシグナリングマネージャー、タゲッティングシグナリングマネージャー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネント同期化部、タゲッティングプロセッサ、アプリケーションプロセッサ、アラーティングプロセッサ、Ａ／Ｖプロセッサ、再分配モジュール、サービス／コンテンツ獲得制御部、及び／又はコンパニオンスクリーンインターフェースの少なくとも一つを含むことができる。コンパニオンスクリーンインターフェースは、データシェアリング部及び／又は装置管理者の少なくとも一つを含むことができる。本発明の一実施例による制御部に含まれる構成要素に対する内容は前述した同一乃至類似の名称を有する構成要素に対する内容を全て含むことができる。
【１５０５】
また、制御部は、前述したフィジカルレイヤー制御部、リンクレイヤーフレームパーサー（又はリンクレイヤーフレームプロセッサ）、ＩＰ／ＵＤＰデータグラムフィルター、アプリケーションレイヤー伝送クライアント、タイミングコントロール、システムクロック、ＤＴＶコントロールエンジン、使用者入力受信部、シグナリングパーサー、チャネルマップデータベース、ＨＴＴＰアクセスクライアント、ＨＴＴＰアクセスキャッシュ、ＤＡＳＨクライアント、ＩＳＯ ＢＭＦＦパーサー、メディアデコーダー及びファイルデータベースの少なくとも一つを含むことができる。本発明の一実施例による制御部に含まれる構成要素に対する内容は前述した同一乃至類似の名称を有する構成要素に対する内容を全て含むことができる。
【１５０６】
放送受信装置は、ブロードキャストインターフェースを用いて、サービスデータ及びシグナリング情報を含む放送信号を受信することができる（ＣＳ１３３０１００）。
【１５０７】
シグナリング情報はサービスの獲得のための第１シグナリング情報を含むことができる。例えば、第１シグナリング情報は、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つを含むことができる。
【１５０８】
また、シグナリング情報は第１シグナリング情報のブートストラップ発見を提供する第２シグナリング情報を含むことができる。すなわち、シグナリング情報はサービスのためのブートストラップ情報を含む第２シグナリング情報を含むことができる。例えば、第２シグナリング情報はＦＩＣを含むことができる。
【１５０９】
また、サービスデータはＥＳＧデータを含むことができる。
【１５１０】
また、シグナリング情報はＥｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ（ＥＳＧ）データのためのＥＳＧブートストラップ情報を含むことができる。
【１５１１】
そして、放送受信装置は、制御部を用いて、シグナリング情報に基づいてサービスデータを獲得することができる（ＣＳ１３３０２００）。
【１５１２】
そして、放送受信装置は、制御部を用いて、サービスデータをデコードすることができる（ＣＳ１３３０３００）。
【１５１３】
例えば、ＥＳＧブートストラップ情報はＥＳＧデータの伝送タイプを指示するタイプ情報（又はｎｅｔｗｏｒｋ＿ｔｙｐｅ ａｔｔｒｉｂｕｔｅ）を含むことができる。
【１５１４】
例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータのｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓを指示するｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ ｅｌｅｍｅｎｔ（又はｓｏｕｒｃｅＩＰＡｄｄｒ ｅｌｅｍｅｎｔ）、ＥＳＧデータのｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓを指示するｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ ｅｌｅｍｅｎｔ（又はｄｅｓｔＩＰＡｄｄｒ ｅｌｅｍｅｎｔ）、及びＥＳＧデータのｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ ｎｕｍｂｅｒを指示するｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ ｎｕｍｂｅｒ ｅｌｅｍｅｎｔ（又はｄｅｓｔＵＤＰＰｏｒｔ ｅｌｅｍｅｎｔ）の少なくとも一つを含むことができる。
【１５１５】
例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータが伝送される周波数を識別するｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ ｅｌｅｍｅｎｔ、周波数のパーティションを識別するｐａｒｔｉｔｉｏｎＩＤ ｅｌｅｍｅｎｔ、ＥＳＧデータが伝送されるＰｈｙｓｉｃａｌ ｌａｙｅｒ Ｐｉｐｅ（ＰＬＰ）を指示するＰＬＰ ＩＤ ｅｌｅｍｅｎｔ（又はｄａｔａｐｉｐｅＩＤ ｅｌｅｍｅｎｔ）、ＥＳＧデータが伝送される伝送セッションを指示するＴＳＩ ｅｌｅｍｅｎｔ（又はｔｓｉ ｅｌｅｍｅｎｔ）、及び／又はブロードバンドを介して伝送されるＥＳＧデータの位置を指示するＵＲＬ ｅｌｅｍｅｎｔ（又はｄｏｗｎｌｏａｄＵＲＬ ａｔｔｒｉｂｕｔｅ）の少なくとも一つを含むことができる。
【１５１６】
また、第２シグナリング情報はＥＳＧブートストラップ情報を含むことができる。また、第２シグナリング情報はサービスのカテゴリーを指示するカテゴリー情報（又はＳｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙ ｅｌｅｍｅｎｔ）を含むことができる。また、カテゴリー情報はＥＳＧサービスを指示することができる。
【１５１７】
また、第１シグナリング情報は伝送セッションについての情報を含む伝送セッションｅｌｅｍｅｎｔを含み、伝送セッションｅｌｅｍｅｎｔは伝送セッションのためのＰｈｙｓｉｃａｌ ｌａｙｅｒ Ｐｉｐｅ（ＰＬＰ）を指示するＰＬＰ ＩＤ ｅｌｅｍｅｎｔ（又はＤＰ ａｔｔｒｉｂｕｔｅ）を含むことができる。
【１５１８】
以上、放送受信装置について説明したが、本発明の一実施例によれば、放送受信装置の反対機能を遂行することができる放送伝送装置を含むことができる。例えば、放送伝送装置は、制御部及び／又は伝送部を含むことができる。制御部は前述したサービスデータ及び／又は前述したシグナリング情報を生成することができる。また、伝送部は、サービスデータ及び／又はシグナリング情報を含む放送信号を伝送することができる。
【１５１９】
図１３９は本発明の一実施例によるチャネルマップ構成方法を示した図である。
【１５２０】
本発明の一実施例はデバイス性能（ｄｅｖｉｃｅ ｃａｐａｂｉｌｉｔｙ）によって差別化されたチャネルマップを構成する方法を提供することができる。それぞれのサービスに必要なデバイス性能（ｄｅｖｉｃｅ ｃａｐａｂｉｌｉｔｙ）の識別のため、本発明の一実施例によるＦＩＣはＦＩＣループにｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅを含むことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅはデバイス性能（ｄｅｖｉｃｅ ｃａｐａｂｉｌｉｔｙ）を識別することができる。放送受信装置はＦＩＣを受信し、ＦＩＣのｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅに基づいてデバイス性能（ｄｅｖｉｃｅ ｃａｐａｂｉｌｉｔｙ）に合う差別化されたチャネルマップを構成（又は生成）することができる。
【１５２１】
以下では、図面を参照して本発明の一実施例による放送信号の構造を説明する。
【１５２２】
特定の周波数を有する放送信号はシグナリング情報を含むことができる。例えば、シグナリング情報はＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣはＳＬＴと言える。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。
【１５２３】
特定の周波数を有する放送信号は同一コンデンツを含む高鮮明度ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＨＤ）サービス及び超高鮮明度ビデオ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＵＨＤ）サービスを含むことができる。それぞれのサービスは少なくとも一つのＲｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＲＯＵＴＥ）セッションを介して伝送されることができる。このために、放送信号は少なくとも一つのＲＯＵＴＥセッションを含むことができる。それぞれのＲＯＵＴＥセッションはサービスレイヤーシグナリング情報及び少なくとも一つのコンポーネントを含むことができる。また、それぞれのＲＯＵＴＥセッションは、ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ、及びｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ ｎｕｍｂｅｒの組合せによって識別されることができる。また、それぞれのＲＯＵＴＥセッションは少なくとも一つのＤＰ及び／又はＰＬＰを介して伝送されることができる。また、それぞれのＲＯＵＴＥセッションは少なくとも一つの伝送セッション（又はＬＣＴセッション）を含むことができる。それぞれの伝送セッションはＴＳＩによって識別されることができる。また、それぞれの伝送セッションはシグナリング情報及び／又はコンデンツコンポーネントを含むことができる。例えば、伝送セッションに含まれるシグナリング情報はサービスレイヤーシグナリング情報（ＳＬＳ）を含むことができる。また、コンデンツコンポーネントはビデオコンポーネント及び／又はオーディオコンポーネントを含むことができる。
【１５２４】
放送信号は第１ＲＯＵＴＥセッション及び第２ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションはＨＤサービスを含むことができる。第２ＲＯＵＴＥセッションはＵＨＤサービスのための付加情報を含むことができる。ＨＤサービスは第１ＲＯＵＴＥセッションを介して伝送されることができる。ＵＨＤサービスは第１ＲＯＵＴＥセッション及び第２ＲＯＵＴＥセッションを介して伝送されることができる。
【１５２５】
それぞれのサービスに対してそれぞれサービスレイヤーシグナリング情報が存在することができる。例えば、ＨＤサービスに対し、第１ＲＯＵＴＥセッションにＨＤサービスのためのサービスレイヤーシグナリング情報が存在することができる。また、ＵＨＤサービスに対し、第２ＲＯＵＴＥセッションにＵＨＤサービスのためのサービスレイヤーシグナリング情報が存在することができる。第１ＲＯＵＴＥセッションに存在するＨＤサービスのためのサービスレイヤーシグナリング情報はＵＨＤサービスのためのサービスレイヤーシグナリング情報として活用できる。ここで、サービスレイヤーシグナリング情報はＬＳＩＤ及びＳＳＣ（ＳＭＴ、ＭＤＰ、及び／又はＣＭＴ）の少なくとも一つを含むことができる。
【１５２６】
第１ＲＯＵＴＥセッションは、ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ（ｓｉｐ−ｈｄ）、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ（ｉｐ−ｈｄ）、及びｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ ｎｕｍｂｅｒ（ｕｄｐ−ｈｄ）の組合せによって識別されることができる。また、第１ＲＯＵＴＥセッションは第１ＤＰ（ｄｐ−１）及び第２ＤＰ（ｄｐ−２）を介して伝送されることができる。また、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−０）、第２伝送セッション（ｔｓｉ−ａ）、及び第３伝送セッション（ｔｓｉ−ｖ−ｂ）を含むことができる。第１伝送セッション（ｔｓｉ−０）はＬＳＩＤ及びシグナリングテーブルを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴの少なくとも一つを含むことができる。第２伝送セッション（ｔｓｉ−ａ）はオーディオコンポーネントを含むことができる。例えば、オーディオコンポーネントは少なくとも一つのオーディオセグメントを含むことができる。第３伝送セッション（ｔｓｉ−ｖ−ｂ）はベースビデオコンポーネントを含むことができる。例えば、ベースビデオコンポーネントは少なくとも一つのベースビデオセグメントを含むことができる。例えば、ベースビデオコンポーネントはＨＤサービスを提供するためのビデオコンポーネントである。
【１５２７】
第２ＲＯＵＴＥセッションは、ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ（ｓｉｐ−ｕｈｄ）、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ（ｉｐ−ｕｈｄ）、及びｄｅｓｔｉｎａｔｉｏｎｐｏｒｔｎｕｍｂｅｒ（ｕｄｐ−ｕｈｄ）の組合せによってｄ識別されることができる。また、第２ＲＯＵＴＥセッションは第３ＤＰ（ｄｐ−３）及び第４ＤＰ（ｄｐ−４）を介して伝送されることができる。また、第２ＲＯＵＴＥセッションは第４伝送セッション（ｔｓｉ−０）及び第５伝送セッション（ｔｓｉ−ｖ−ｅ）を含むことができる。第４伝送セッション（ｔｓｉ−０）はＬＳＩＤ及びシグナリングテーブルを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣはＳＭＴ、ＭＰＤ、及び／又はＣＭＴの少なくとも一つを含むことができる。第５伝送セッション（ｔｓｉ−ｖ−ｅ）はエンハンスメントビデオコンポーネントを含むことができる。例えば、エンハンスメントビデオコンポーネントは少なくとも一つのエンハンスメントビデオセグメントを含むことができる。例えば、エンハンスメントビデオコンポーネントはＵＨＤサービスを提供するためのビデオコンポーネント及び／又は付加情報である。
【１５２８】
以下ではＦＩＣについて説明する。
【１５２９】
ＦＩＣはＳｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ（ＳＬＴ）と言える。ＳＬＴは基本的なサービスリストを樹立し（ｂｕｉｌｄｉｎｇ）、サービスレイヤーシグナリング情報（ＳＬＳ）のブートストラップ情報を提供するシグナリング情報テーブルである。
【１５３０】
ＦＩＣは、ｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１５３１】
ｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅはサービスを識別する識別子である。
【１５３２】
ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは、サービスのためのコンデンツのデコーディング及び／又は意味ある再生のために要求されるデバイスの性能及び／又は性能グループを指示することができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅはＦＩＣに含まれることもでき、ＳＬＳに含まれることもできる。性能のカテゴリーは、Ｄｏｗｎｌｏａｄ Ｐｒｏｔｏｃｏｌ、ＦＥＣ Ａｌｇｏｒｉｔｈｍ、Ｗｒａｐｐｅｒ／Ａｒｃｈｉｖｅ Ｆｏｒｍａｔ、Ｃｏｍｐｒｅｓｓｉｏｎ Ａｌｇｏｒｉｔｈｍ、Ｍｅｄｉａ Ｔｙｐｅ、及び／又はＩｎｔｅｒｎｅｔ Ｌｉｎｋの少なくとも一つを含むことができる。
【１５３３】
例えば、Ｄｏｗｎｌｏａｄ Ｐｒｏｔｏｃｏｌに対し、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは、ＦＬＵＴＥ ｐｒｏｔｏｃｏｌ及び／又はＨＴＴＰの少なくとも一つを指示することができる。また、ＦＥＣ Ａｌｇｏｒｉｔｈｍに関し、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは、Ｃｏｍｐａｃｔ Ｎｏ−Ｃｏｄｅ ＦＥＣ ｓｃｈｅｍｅ及び／又はＲａｐｔｏｒ ａｌｇｏｒｉｔｈｍの少なくとも一つを指示することができる。また、Ｗｒａｐｐｅｒ／Ａｒｃｈｉｖｅ Ｆｏｒｍａｔに関連し、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは、ＤＥＣＥ ＣＦＦ ｃｏｎｔａｉｎｅｒ ｇｅｎｅｒａｌ ｆｏｒｍａｔ、ＺＩＰ ｆｏｒｍａｔ、ＤＥＣＥ ＣＦＦ ｃｏｎｔａｉｎｅｒ ｆｏｒｍａｔ、ＤＥＣＥ ＣＦＦ ｃｏｎｔａｉｎｅｒ ｆｏｒｍａｔ、ＤＥＣＥ ＣＦＦ ｃｏｎｔａｉｎｅｒ ｆｏｒｍａｔ、ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ ｆｏｒ ＡＡＣ ａｕｄｉｏ、ＡＴＳＣ ｃｏｍｐｌｉａｎｔ ＭＰＥＧ−２ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ、ＭＰ４ ｃｏｎｓｔｒａｉｎｅｄ ｃｏｎｔａｉｎｅｒ ｆｏｒｍａｔ、及び／又はＷ３Ｃ Ｗｅｂ Ａｐｐｓ Ｐａｃｋａｇｅの少なくとも一つを指示することができる。また、Ｃｏｍｐｒｅｓｓｉｏｎ Ａｌｇｏｒｉｔｈｍに関し、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅはＤＥＦＬＡＴＥ ａｌｇｏｒｉｔｈｍを指示することができる。また、Ｍｅｄｉａ Ｔｙｐｅに関し、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは、ＡＶＣ ｓｔａｎｄａｒｄ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＡＶＣ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＡＣ−３ａｕｄｉｏ、Ｅ−ＡＣ−３ ａｕｄｉｏ、ＭＰ３ ａｕｄｉｏ、Ｂｒｏｗｓｅｒ Ｐｒｏｆｉｌｅ Ａ（Ａ／１０５）、Ａｔｏｍ ｐｅｒ ＲＦＣ ４２８７、ＡＶＣ ｍｏｂｉｌｅ ｖｉｄｅｏ、ＨＥ ＡＡＣ ｖ２ ｍｏｂｉｌｅ ａｕｄｉｏ、ＨＥ ＡＡＣ ｖ２ ｌｅｖｅｌ ４ ａｕｄｉｏ、ＤＴＳ−ＨＤ ａｕｄｉｏ、ＣＦＦ−ＴＴ、ＣＥＡ−７０８ ｃａｐｔｉｏｎｓ、ＨＥ ＡＡＣ ｖ２ ｗｉｔｈ ＭＰＥＧ Ｓｕｒｒｏｕｎｄ、ＨＥ ＡＡＣ ｖ２ Ｌｅｖｅｌ ６ ａｕｄｉｏ、Ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ ３Ｄ ｖｉｄｅｏ（Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ）、Ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ ３Ｄ ｖｉｄｅｏ（Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ）、ＡＴＳＣ３．０ ＨＥＶＣ Ｖｉｄｅｏ １（ｅ．ｇ．ＨＤ ｖｉｄｅｏ）、ＡＴＳＣ３．０ ＨＥＶＣ Ｖｉｄｅｏ２（ｅ．ｇ．ＵＨＤ ｖｉｄｅｏ）、ＡＴＳＣ３．０ ＳＨＶＣ Ｖｉｄｅｏ １、ＡＴＳＣ３．０ ＨＤＲ Ｖｉｄｅｏ １、ＡＴＳＣ３．０ Ｗｉｄｅ Ｃｏｌｏｒ Ｇａｍｕｔ Ｖｉｄｅｏ １、ＡＴＳＣ３．０ Ｃｏｄｅｄ Ａｕｄｉｏ １（ｅ．ｇ．５．１．ｃｈａｎｎｅｌ ｓｕｒｒｏｕｎｄ ａｕｄｉｏ）、ＡＴＳＣ３．０ Ｃｏｄｅｄ Ａｕｄｉｏ ２（ｅ．ｇ．Ｉｍｍｅｒｓｉｖｅ／３Ｄ Ａｕｄｉｏ）、及び／又はＤｉａｌｏｇ ｌｅｖｅｌ ａｄｊｕｓｔｍｅｎｔの少なくとも一つを指示することができる。また、Ｉｎｔｅｒｎｅｔ Ｌｉｎｋに関し、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは、ｄｏｗｎｗａｒｄ ｒａｔｅ ５６，０００ ｂｐｓ ｏｒ ｂｅｔｔｅｒ、ｄｏｗｎｗａｒｄ ｒａｔｅ ５１２，０００ ｂｐｓ ｏｒ ｂｅｔｔｅｒ、ｄｏｗｎｗａｒｄ ｒａｔｅ ２，０００，０００ ｂｐｓ ｏｒ ｂｅｔｔｅｒ、及び／又はｄｏｗｎｗａｒｄ ｒａｔｅ １０，０００，０００ ｂｐｓ ｏｒ ｂｅｔｔｅｒの少なくとも一つを指示することができる。
【１５３４】
ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するパケットのｓｏｕｒｃｅ ａｄｄｒｅｓｓを指示することができる。
【１５３５】
ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するパケットのｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓを指示することができる。
【１５３６】
ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するパケットのｐｏｒｔ ｎｕｍｂｅｒを指示することができる。
【１５３７】
ＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送する伝送セッションを識別する識別子である。ただ、ＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅは固定された「０」の値を有することができる。ＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅが固定された「０」の値を有すれば、ＦＩＣはＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅを含まないこともできる。
【１５３８】
ＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するデータパイプ（又はフィジカルレイヤーパイプ）の識別子を指示することができる。
【１５３９】
ＦＩＣはＨＤサービスのための第１サービスｅｌｅｍｅｎｔ及びＵＨＤサービスのための第２サービスｅｌｅｍｅｎｔを含むことができる。
【１５４０】
第１サービスｅｌｅｍｅｎｔは、「ｓｉｄ−ｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、「０ｘ０１」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅ、「ｓｉｐ−ｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「ｕｄｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅ、「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又は「ｄｐ−１」の値を有するＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。ここで、「ｓｉｄ−ｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅはＨＤサービスを指示することができる。「０ｘ０１」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは性能情報がＨＤサービスを指示することができる。「ｓｉｐ−ｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、及び「ｕｄｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅの組合せは第１ＲＯＵＴＥセッションを指示することができる。「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅ及び「ｄｐ−１」の値を有するＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅはＨＤサービスのためのＳＬＳ（例えば、ＬＳＩＤ及びＳＳＣ）が伝送される経路を指示することができる。
【１５４１】
第２サービスｅｌｅｍｅｎｔは、「ｓｉｄ−ｕｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、「０ｘ０２」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅ、「ｓｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「ｕｄｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅ、「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又は「ｄｐ−３」の値を有するＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。ここで、「ｓｉｄ−ｕｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅはＵＨＤサービスを指示することができる。「０ｘ０２」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは性能情報がＵＨＤサービスを指示することができる。「ｓｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、及び「ｕｄｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅの組合せは第２ＲＯＵＴＥセッションを指示することができる。「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅ及び「ｄｐ−３」の値を有するＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅはＵＨＤサービスのためのＳＬＳ（例えば、ＬＳＩＤ及びＳＳＣ）が伝送される経路を指示することができる。
【１５４２】
以下ではＳＭＴについて説明する。
【１５４３】
ＳＭＴはサービスの属性（アイディー、名前、カテゴリーなど）情報及びサービスを獲得することができる経路情報を含むことができる。例えば、サービスを獲得することができる経路情報はサービスのためのＲＯＵＴＥセッションのブートストラップ情報及び／又はＳＬＳの伝送経路情報の少なくとも一つを含むことができる。
【１５４４】
ＳＭＴはＨＤサービスのための第１サービスマップ情報及びＵＤＨサービスのための第２サービスマップ情報を含むことができる。
【１５４５】
それぞれの第１サービスマップ情報及び第２サービスマップ情報はサービスを識別するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、サービスのためのＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む少なくとも一つのＲＯＵＴＥセッションｅｌｅｍｅｎｔを含むことができる。ＲＯＵＴＥセッションｅｌｅｍｅｎｔは、ｓｒｃＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅ、ｄｅｓｔＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅ、ｄｅｓｔＵＤＰＰｏｒｔ ａｔｔｒｉｂｕｔｅ、及び／又はＬＳＩＤ＿ＤＰ ａｔｔｒｉｂｕｔｅを含むことができる。ｓｒｃＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅ、ｄｅｓｔＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅ、及び／又はｄｅｓｔＵＤＰＰｏｒｔ ａｔｔｒｉｂｕｔｅの組合せはＲＯＵＴＥセッションブートストラップ情報と言える。ＬＳＩＤ＿ＤＰ ａｔｔｒｉｂｕｔｅはＳＬＳの伝送経路情報と言える。
【１５４６】
ｓｒｃＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するパケットのｓｏｕｒｃｅ ａｄｄｒｅｓｓを指示することができる。
【１５４７】
ｄｅｓｔＩＰ ａｄｄｒａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するパケットのｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓを指示することができる。
【１５４８】
ｄｅｓｔＵＤＰＰｏｒｔ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するパケットのｐｏｒｔ ｎｕｍｂｅｒを指示することができる。
【１５４９】
ＬＳＩＤ＿ＤＰ ａｔｔｒｉｂｕｔｅはサービスのためのＳＬＳを伝送するデータパイプ（又はフィジカルレイヤーパイプ）の識別子を指示することができる。
【１５５０】
第１サービスマップ情報はＨＤサービスを識別するｓｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔ、及びＨＤサービスのための第１ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第１ＲＯＵＴＥセッションｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、ＨＤサービスのためのｓｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔの値は「ｓｉｄ−ｈｄ」であり得る。また、ＨＤサービスのための第１ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｈｄ」、ｄｅｓｔＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｈｄ」、ｄｅｓｔＵＤＰＰｏｒｔ ａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｈｄ」であり得る。また、ＨＤサービスのための第１ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−１」であり得る。
【１５５１】
第２サービスマップ情報はＵＨＤサービスを識別するｓｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔ、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第１ＲＯＵＴＥセッションｅｌｅｍｅｎｔ、及びＵＨＤサービスのための第２ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第２ＲＯＵＴＥセッションｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、ＵＨＤサービスのためのｓｅｒｖｉｃｅ＿ｉｄ ｅｌｅｍｅｎｔの値は「ｓｉｄ−ｕｈｄ」であり得る。また、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｈｄ」、ｄｅｓｔＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｈｄ」、ｄｅｓｔＵＤＰＰｏｒｔ ａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｈｄ」であり得る。また、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−１」であり得る。また、ＵＨＤサービスのための第２ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｕｈｄ」、ｄｅｓｔＩＰａｄｄｒ ａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｕｈｄ」、ｄｅｓｔＵＤＰＰｏｒｔ ａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｕｈｄ」であり得る。また、ＵＨＤサービスのための第２ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−３」であり得る。
【１５５２】
以下ではＭＤＰについて説明する。
【１５５３】
ＭＰＤはリニア／ストリーミングサービスの個別的なメディアコンポーネントのためのリソース識別子を含むことができる。また、ＭＰＤはメディアプレゼンテーション内で識別されたリソースのコンテキスト（ｃｏｎｔｅｘｔ）を含むことができる。例えば、リソース識別子はサービスのためのコンポーネントに係わるレプリゼンテーションを識別する情報であり得る。
【１５５４】
ＭＰＤはメディアプレゼンテーションを構成する連続的な時間的区間についての情報を含む少なくとも一つのピリオドｅｌｅｍｅｎｔを含むことができる。それぞれのピリオドｅｌｅｍｅｎｔは、ピリオドを識別するｐｅｒＩｄ ａｔｔｒｉｂｕｔｅ及びコンポーネントについての情報を含む少なくとも一つのＲｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。それぞれのＲｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔはサービスのためのコンポーネントに係わるレプリゼンテーションを識別するｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅを含むことができる。また、それぞれのＲｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔはデコーディング及び／又はプレゼンテーションプロセスで該当のレプリゼンテーションが依存している少なくとも一つのコンプリメンタリーレプリゼンテーション（ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を指示するｄｅｐｅｎｄｅｎｃｙＩｄ ａｔｔｒｉｂｕｔｅを含むことができる。
【１５５５】
例えば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔは、オーディオコンポーネントについての情報を含む第１Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ、ＨＤサービスのためのベースビデオコンポーネントについての情報を含む第２Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ、及び／又はＵＨＤサービスのためのエンハンスメントビデオコンポーネントについての情報を含む第３Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔを含むことができる。第３Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔはＵＨＤサービスのために第２レプリゼンテーションに依存している。第１Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」、第２Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」、第３Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であり得る。また、第３Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔはｄｅｐｅｎｄｅｎｃｙＩｄ ａｔｔｒｉｂｕｔｅを含むことができ、ｄｅｐｅｎｄｅｎｃｙＩｄ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」を指示することができる。
【１５５６】
以下ではＣＭＴについて説明する。
【１５５７】
ＣＭＴはサービスのためのコンポーネントデータの伝送経路情報を含むことができる。例えば、伝送経路情報はサービスのためのコンポーネントデータが伝送されるＤＰ（又はＰＬＰ）を識別する情報であり得る。
【１５５８】
ＣＭＴはＨＤサービスのための第１コンポーネントマップ情報及びＵＤＨサービスのための第２コンポーネントマップ情報を含むことができる。
【１５５９】
それぞれの第１コンポーネントマップ情報及び第２コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ ａｔｔｒｉｂｕｔｅ、及び／又はコンポーネントの伝送経路情報を含む少なくとも一つのＣｏｍｐ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、Ｃｏｍｐ ｅｌｅｍｅｎｔはサービスのためのコンポーネントに係わるレプリゼンテーションを識別するｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅ及び／又はサービスのためのコンポーネントが伝送されるＤＰを指示するｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅはコンポーネントの伝送経路情報と指称することができる。
【１５６０】
第１コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ ａｔｔｒｉｂｕｔｅ、ＨＤサービスのためのオーディオコンポーネントの伝送経路情報を含む第１Ｃｏｍｐ ｅｌｅｍｅｎｔ、及び／又はＨＤサービスのためのベースビデオコンポーネントの伝送経路情報を含む第２Ｃｏｍｐ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、ｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅの値は「ｓｉｄ−ｈｄ」、ｐｅｒＩＤ ａｔｔｒｉｂｕｔｅの値は「ｐｅｒ−１」であり得る。また、ＨＤサービスのための第１Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であり得る。また、ＨＤサービスのための第２Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であり得る。
【１５６１】
第２コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ ａｔｔｒｉｂｕｔｅ、ＵＨＤサービスのためのオーディオコンポーネントの伝送経路情報を含む第１Ｃｏｍｐ ｅｌｅｍｅｎｔ、ＵＨＤサービスのためのベースビデオコンポーネントの伝送経路情報を含む第２Ｃｏｍｐ ｅｌｅｍｅｎｔ、及び／又はＵＨＤサービスのためのエンハンスメントビデオコンポーネントの伝送経路情報を含む第３Ｃｏｍｐ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、ｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅの値は「ｓｉｄ−ｕｈｄ」、ｐｅｒＩＤ ａｔｔｒｉｂｕｔｅの値は「ｐｅｒ−１」であり得る。また、ＵＨＤサービスのための第１Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であり得る。また、ＵＨＤサービスのための第２Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であり得る。また、ＵＨＤサービスのための第３Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ｄｐ−４」であり得る。
【１５６２】
以下ではＬＳＩＤについて説明する。
【１５６３】
ＬＳＩＤはＳｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ（Ｓ−ＴＳＩＤ）と言える。Ｓ−ＴＳＩＤはサービスの少なくとも一つのコンデンツコンポーネントを伝送する少なくとも一つの伝送セッションのための全体的なセッションディスクリプション情報を含むことができる。例えば、ＬＳＩＤはサービスのためのコンポーネントが伝送される伝送セッションを識別する情報を含むことができる。
【１５６４】
ＬＳＩＤはＨＤサービスのための第１ＬＳＩＤ及びＵＨＤサービスのための第２ＬＳＩＤを含むことができる。
【１５６５】
第１ＬＳＩＤは第１ＲＯＵＴＥセッションに含まれることができる。第１ＬＳＩＤはコンポーネントを伝送する少なくとも一つのＴｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔを含むことができる。それぞれのＴｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔは伝送セッションに含まれるソースフローについての情報を提供するＳｏｕｒｃｅＦｌｏｗ ｅｌｅｍｅｎｔを含むことができる。ＳｏｕｒｃｅＦｌｏｗ ｅｌｅｍｅｎｔは伝送セッションを介して伝送されるサービス（又はアプリケーションサービス）にマッピングされる付加的な情報を含むＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ ｅｌｅｍｅｎｔを含むことができる。例えば、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ ｅｌｅｍｅｎｔは、ＤＡＳＨコンデンツのレプリゼンテーション識別子（ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ）及び／又はＤＡＳＨメディアレプリゼンテーションのアダプテーションセットパラメータ（Ａｄａｐｔａｔｉｏｎ Ｓｅｔ ｐａｒａｍｅｔｅｒｓ）を含むことができる。レプリゼンテーション識別子はサービスのためのコンポーネントに係わる識別子であり、ｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅと言える。また、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ ｅｌｅｍｅｎｔはＣｏｎｔｅｎｔＩｎｆｏ ｅｌｅｍｅｎｔと言える。
【１５６６】
第１ＬＳＩＤは、オーディオコンポーネントを伝送する第１Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ及び／又はベースビデオコンポーネントを伝送する第２Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、第１Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ内のｔｓｉ ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ａ」、ｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であり得る。また、第２Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ内のｔｓｉ ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ｖ−ｂ」、ｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であり得る。
【１５６７】
第２ＬＳＩＤはエンハンスメントビデオコンポーネントを伝送する第３Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔを含むことができる。例えば、第３Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ内のｔｓｉの値は「ｔｓｉ−ｖ−ｅ」、ｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であり得る。
【１５６８】
図面では、それぞれのＲＯＵＴＥセッションはそれぞれ一つのＬＳＩＤ（伝送セッション情報）を含み、二つのＬＳＩＤが存在するが、これに限定されない。例えば、それぞれのサービスはそれぞれ一つのＬＳＩＤ（伝送セッション情報）を含むことができる。この場合、一つのＬＳＩＤは特定のサービスのための少なくとも一つのＲＯＵＴＥセッションに含まれる少なくとも一つのコンポーネントを伝送する少なくとも一つの伝送セッションについての情報を含むことができる。例えば、一つのＬＳＩＤは、ＵＨＤサービスのために、第１Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ、第２Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ、及び／又は第３Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔを全て含むことができる。
【１５６９】
図面を参照すると、本発明の一実施例による一つの周波数は、同一コンテンツを含む高鮮明度ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＨＤ）サービス及び超高鮮明度ビデオ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＵＨＤ）サービスを含むことができる。
【１５７０】
例えば、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅの値が「０ｘ００」であれば、デバイス性能はデジタル標準ビデオ（Ｓｔａｎｄａｒｄ−Ｄｅｆｉｎｉｔｉｏｎ、ＳＤ）サービスを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅの値が「０ｘ０１」であれば、デバイス性能はＨＤサービスを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅの値が「０ｘ０２」であれば、デバイス性能はＵＨＤサービスを示すことができる。
【１５７１】
モバイルデバイスのようにＵＨＤサービスを再生することができない装置は、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅに基づいてチャネルマップの構成の際、ＵＨＤサービスにあたるチャネルを除いてチャネルマップを構成することができる。
【１５７２】
また、ＴＶのようなフィクスドデバイス（ｆｉｘｅｄ ｄｅｖｉｃｅ）ではＨＤサービス及びＵＨＤサービスを全て再生することができるので、フィクスドデバイスはＨＤサービス及びＵＨＤサービスにあたるチャネルを全て含んでチャネルマップを構成することができる。
【１５７３】
図１４０は本発明の一実施例によるチャネルマップ構成方法を示した図である。
【１５７４】
本発明の一実施例は次世代放送ネットワークで同一コンデンツが多くのサービス形態で提供されるとき、これを識別するための方法を提供することができる。同一コンデンツがサービスされることを識別するため、本発明の一実施例によるＦＩＣはＦＩＣ ｌｏｏｐにｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅを含むことができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅはサービスのチャネル番号を指示することができる。放送受信装置はＦＩＣを受信し、ＦＩＣのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅに基づいて同一コンデンツを伝送するチャネル（又はサービス）を除いてチャネルマップを構成することができる。
【１５７５】
特定の周波数を有する放送信号はシグナリング情報を含むことができる。例えば、シグナリング情報はＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣはＳＬＴと言える。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。本発明の一実施例による放送信号の構造、ＦＩＣ、及び／又はＳＬＳは前述した内容と同一であるか前述した内容を全て含むことができる。
【１５７６】
本発明の一実施例によるＦＩＣはサービスｅｌｅｍｅｎｔ内にサービスのチャネル番号を指示するｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅを含むことができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅは、サービスのメージャーチャネル番号を指示するｍａｊｏｒＣｈａｎｎｅｌＮｏ ａｔｔｒｉｂｕｔｅ及び／又はサービスのマイナーチャネル番号を指示するｍｉｎｏｒＣｈａｎｎｅｌＮｏ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１５７７】
ＦＩＣは、ＨＤサービスのための第１サービスｅｌｅｍｅｎｔ及びＵＨＤサービスのための第２サービスｅｌｅｍｅｎｔを含むことができる。例えば、ＨＤサービス及びＵＨＤサービスは同一コンデンツを提供することができる。第１サービスｅｌｅｍｅｎｔは「ｃｎｕｍ−ｘ」の値を有するｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅを含むことができる。第２サービスｅｌｅｍｅｎｔは「ｃｎｕｍ−ｘ」の値を有するｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅを含むことができる。第１サービスｅｌｅｍｅｎｔのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅと第２サービスｅｌｅｍｅｎｔのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅは同一 「ｃｎｕｍ−ｘ」の値を有することができる。
【１５７８】
図面を参照すると、本発明の一実施例による一つの周波数は同一コンテンツを含む高鮮明度ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＨＤ）サービス及び超高鮮明度ビデオ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、ＵＨＤ）サービスを含むことができる。
【１５７９】
例えば、同一コンデンツがＨＤサービス及び／又はＵＨＤサービスのようなそれぞれのサービス形態で伝送されるとき、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅは同一値を有することができる。
【１５８０】
ＵＨＤ再生が可能な装置では同一コンデンツを伝送するＨＤチャネル（サービス）情報及び／又はＵＨＤチャネル（サービス）情報を重複して構成せず、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅに基づいてＵＨＤチャネルのみを選択してチャネルマップを構成することができる。
【１５８１】
図１４１は本発明の一実施例によるＦＩＣを示した図である。
【１５８２】
本発明の一実施例によるＦＩＣに関する内容は前述したＦＩＣに関する内容を全て含むことができる。また、本発明の一実施例ではＦＩＣに含まれる情報をｆｉｅｌｄとして表現したが、ＦＩＣはＸＭＬフォーマットであり得る。また、ＦＩＣに含まれる情報をｆｉｅｌｄでａｔｔｒｉｂｕｔｅとして表現することができる。
【１５８３】
本発明の一実施例によるＦＩＣは、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ ｆｉｅｌｄ、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄ、ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄ、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄの少なくとも一つを含むことができる。
【１５８４】
ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ ｆｉｅｌｄはＳｅｒｖｉｃｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＳＣＤ）が伝送されるか（又は存在するか）を指示することができる。ＳＣＤはＦＩＣに含まれないより多様で多くの量の更なるシグナリング情報を含むことができる。例えば、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ ｆｉｅｌｄの値が「Ｔｒｕｅ」であれば、シグナリング情報はＳＣＤを含むことができる。
【１５８５】
ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄはＳＣＤが伝送されるデータパイプ（又はＰＬＰ）の識別子を指示する。
【１５８６】
ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄは該当のサービスのＳＳＣブートストラップ情報が伝送されるデータパイプ（又はＰＬＰ）の識別子を指示する。
【１５８７】
ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄは基本的な段階のシグナリング情報がＳＳＣに伝送されるかを指示することができる。例えば、サービスシグナリングで使われるディスクリプションの種類又はテーブルの種類が違う場合、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄは基本的な段階のシグナリング情報がＳＳＣに伝送されるかを指示することができる。また、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄはオーディオコンポーネント及び／又はビデオコンポーネントに係わる基本的な段階のシグナリング情報が別個のシグナリングチャネル及び／又はシグナリングテーブルを介して伝達されるかを指示することができる。
【１５８８】
ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ ｆｉｅｌｄ及び／又はＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄはフィジカルレイヤーシグナリング情報に含まれることもできる。この場合、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ ｆｉｅｌｄは現在フレームにＳＣＤが存在するかを指示することができる。また、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄはＳＣＤが伝送されるデータパイプ（又はＰＬＰ）及び／又はフレームを指示することができる。
【１５８９】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述したＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ ｆｉｅｌｄ、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄ、ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄ、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄの少なくとも一つを含むことができる。
【１５９０】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを獲得することができる。そして、放送受信装置はＦＩＣ及び／又はＳＣＤに基づいてサービスを獲得することができる。
【１５９１】
図１４２は本発明の一実施例によるＦＩＣを示した図である。
【１５９２】
本発明の一実施例によるＦＩＣに関する内容は前述したＦＩＣに関する内容を全て含むことができる。また、本発明の一実施例ではＦＩＣに含まれる情報をｆｉｅｌｄで表現したが、ＦＩＣはＸＭＬフォーマットであり得る。また、ＦＩＣに含まれる情報をｆｉｅｌｄでａｔｔｒｉｂｕｔｅとして表現することができる。
【１５９３】
本発明の一実施例によるＦＩＣはＰｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄを含むことができる。
【１５９４】
Ｐｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄは該当のサービスを送信する提供者（又はＰｒｏｖｉｄｅｒ）の固有した識別子を指示する。例えば、Ｐｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄは該当のサービスがどの提供者から伝送されるかを指示することができる。
【１５９５】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は前述したＰｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄを含むことができる。
【１５９６】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを獲得することができる。そして、放送受信装置はＦＩＣ及び／又はＳＣＤに基づいてサービスを獲得し、該当のサービスの提供者を識別することができる。
【１５９７】
図１４３は本発明の一実施例によるＦＩＣを示した図である。
【１５９８】
本発明の一実施例によるＦＩＣに関する内容は前述したＦＩＣに関する内容を全て含むことができる。また、本発明の一実施例ではＦＩＣに含まれる情報をｆｉｅｌｄで表現したが、ＦＩＣはＸＭＬフォーマットであり得る。また、ＦＩＣに含まれる情報をｆｉｅｌｄでａｔｔｒｉｂｕｔｅとして表現することができる。
【１５９９】
本発明の一実施例によるＦＩＣはＰｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ ｆｉｅｌｄを含むことができる。
【１６００】
Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄｆｉｅｌｄは該当のサービスを送信する提供者（Ｐｒｏｖｉｄｅｒ）が属するグループの識別子を指示することができる。
【１６０１】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は前述したＰｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ ｆｉｅｌｄを含むことができる。
【１６０２】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを獲得することができる。そして、放送受信装置はＦＩＣ及び／又はＳＣＤに基づいてサービスを獲得し、該当のサービスの提供者のグループを識別することができる。
【１６０３】
例えば、放送受信装置はＰｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ ｆｉｅｌｄに基づいて提供者グループ別に受信されるサービスを区別することができる。すなわち、放送受信装置はＰｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ ｆｉｅｌｄとＳｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ ｆｉｅｌｄがＥＳＧであるサービスをマッピングして、ＥＳＧがどの提供者が提供しているサービスに対するＧｕｉｄｅを含んでいるかを判断することができる。
【１６０４】
図１４４は本発明の一実施例によるＦＩＣを示した図である。
【１６０５】
本発明の一実施例によるＦＩＣに関する内容は前述したＦＩＣに関する内容を全て含むことができる。また、本発明の一実施例ではＦＩＣに含まれる情報をｆｉｅｌｄとして表現したが、ＦＩＣはＸＭＬフォーマットであり得る。また、ＦＩＣに含まれる情報をｆｉｅｌｄでａｔｔｒｉｂｕｔｅとして表現することができる。
【１６０６】
本発明の一実施例によるＦＩＣはＮｕｍ＿ｐｒｏｖｉｄｅｒｓ ｆｉｅｌｄ及び／少なくとも一つの提供者ループを含むことができる。
【１６０７】
Ｎｕｍ＿ｐｒｏｖｉｄｅｒ ｓｆｉｅｌｄは該当の周波数を使う提供者（Ｐｒｏｖｉｄｅｒ又はＢｒｏａｄｃａｓｔｅｒ）の数を指示することができる。
【１６０８】
それぞれの提供者ループは、Ｐｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄ、少なくとも一つのサービスループ、Ｎｕｍ＿ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ ｆｉｅｌｄ、及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ ｆｉｅｌｄを含むことができる。
【１６０９】
Ｐｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄは該当のサービスを送信する提供者（又はＰｒｏｖｉｄｅｒ）の固有した識別子を指示する。例えば、Ｐｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄはそれぞれの提供者（ｐｒｏｖｉｄｅｒ又はｂｒｏａｄｃａｓｔｅｒ）に割り当てられる固有の識別子である。
【１６１０】
サービスループはサービスに関連した属性を含むことができる。具体的な内容は前述したものと同様である。
【１６１１】
Ｎｕｍ＿ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ ｆｉｅｌｄは提供者（ｐｒｏｖｉｄｅｒ）別に伝送されることができるディスクリプタの数を指示することができる。
【１６１２】
Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｆｉｅｌｄは提供者（ｐｒｏｖｉｄｅｒ）別に伝送されるディスクリプタを指示することができる。
【１６１３】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は前述した少なくとも一つのＰｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄを含むことができる。
【１６１４】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを獲得することができる。そして、放送受信装置はＦＩＣ及び／又はＳＣＤに基づいて少なくとも一つのサービスを獲得し、該当のサービスの提供者を識別することができる。
【１６１５】
図１４５は本発明の一実施例によるＦＩＣを示した図である。
【１６１６】
本発明の一実施例によるＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ ｆｉｅｌｄ、ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄ、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ ｆｉｅｌｄ、ＳＣＤ＿ＤＰ＿ＩＤ ｆｉｅｌｄ、Ｎｕｍ＿ｐｒｏｖｉｄｅｒｓ ｆｉｅｌｄ、ｐｒｏｖｉｄｅｒ＿ｉｄ ｆｉｅｌｄ、ｎｕｍ＿ｓｅｒｖｉｃｅｓ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｉｄ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ ｆｉｅｌｄ、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｆｉｅｌｄ、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ ｆｉｅｌｄ、ｓｐ＿ｉｎｄｉｃａｔｏｒ ｆｉｅｌｄ、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ ｆｉｅｌｄ、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ ｆｉｅｌｄ、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ ｆｉｅｌｄ、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ ｆｉｅｌｄ、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ ｆｉｅｌｄ、ＳＳＣ＿ＴＳＩ ｆｉｅｌｄ、ＳＳＣ＿ＤＰ＿ＩＩＤ ｆｉｅｌｄ、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄ、ｎｕｍ＿Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ ｆｉｅｌｄ、Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（） ｆｉｅｌｄ、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ ｆｉｅｌｄ、及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（） ｆｉｅｌｄの少なくとも一つを含むことができる。本発明の一実施例によるＦＩＣに含まれる情報は前述したＦＩＣに含まれる情報の内容を全て含むことができる。
【１６１７】
本発明の一実施例によるＦＩＣは、サービスのためのコンデンツのデコーディング及び／又は意味ある再生のために要求されるデバイスの性能及び／又は性能グループを指示する性能情報（又はｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄ）をさらに含むことができる。
【１６１８】
例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄは該当のサービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを指示することができる。例えば、ＵＤ／ＨＤ ｓｃａｌａｂｌｅ ｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄはＨＤを指示する値を有することができる。
【１６１９】
放送受信装置はＦＩＣを受信し、ＦＩＣの性能情報（又はｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄ）に基づいてデバイス性能（ｄｅｖｉｃｅ ｃａｐａｂｉｌｉｔｙ）に合う差別化されたチャネルマップを構成（又は生成）することができる。また、放送受信装置はＦＩＣの性能情報（又はｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄ）に基づいてサービスのための少なくとも一つのコンポーネントを獲得することができる。そして、放送受信装置はサービスのための少なくとも一つのコンポーネントをデコードすることができる。
【１６２０】
図１４６は本発明の一実施例によるＦＩＣを示した図である。
【１６２１】
特定の周波数を有する放送信号はシグナリング情報を含むことができる。例えば、放送信号は「ＢＣＳｔｒｅａｍＩＤ１」に識別されることができる。シグナリング情報はＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣはＳＬＴと言える。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されることができる。
【１６２２】
放送信号は第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは少なくとも一つのサービスを含むことができる。例えば、サービスの識別子は「ＳｒｖｃＩＤ１」の値を有することができる。サービスはＨＤサービス及び／又はＵＨＤサービスのための少なくとも一つのコンポーネントを含むことができる。ＨＤサービスのためのコンポーネントは第１ＲＯＵＴＥセッションの特定の伝送セッションを介して伝送されることができる。ＵＨＤサービスのための付加情報は第１ＲＯＵＴＥセッションの他の伝送セッションを介して伝送されることができる。
【１６２３】
サービスに対してサービスレイヤーシグナリング情報が存在することができる。例えば、ＨＤサービス及び／又はＵＨＤサービスに対し、第１ＲＯＵＴＥセッションにＨＤサービス及び／又はＵＨＤサービスのためのサービスレイヤーシグナリング情報が存在することができる。ここで、サービスレイヤーシグナリング情報はＬＳＩＤ及びＳＳＣ（ＳＭＴ、ＭＤＰ、及び／又はＣＭＴ）の少なくとも一つを含むことができる。
【１６２４】
第１ＲＯＵＴＥセッションは、ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ（ｓＩＰＡｄｒｓ１）、ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ（ＩＰＡｄｒｓ１）、及びｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ ｎｕｍｂｅｒ（Ｐｏｒｔ１）の組合せによって識別されることができる。また、第１ＲＯＵＴＥセッションは、第１ＤＰ（ＤＰ＿ＩＤ１）、第２ＤＰ（ＤＰ＿ＩＤ２）、及び／又は第３ＤＰ（ＤＰ＿ＩＤ３）を介して伝送されることができる。また、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−０）、第２伝送セッション（ｔｓｉ−ｓ）、第３伝送セッション（ｔｓｉ−ａ）、第４伝送セッション（ｔｓｉ−ｖ）、及び／又は第５伝送セッション（ｔｓｉ−ｅｖ）を含むことができる。第１伝送セッション（ｔｓｉ−０）は、ＬＳＩＤ及び／又は少なくとも一つのＬＳＩＤフラグメントを含むことができる。第２伝送セッション（ｔｓｉ−ｓ）は、シグナリングテーブル及び／又は少なくとも一つのＳＳＣフラグメントを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴの少なくとも一つを含むことができる。第３伝送セッション（ｔｓｉ−ａ）はオーディオコンポーネントを含むことができる。例えば、オーディオコンポーネントは少なくとも一つのオーディオセグメントを含むことができる。第４伝送セッション（ｔｓｉ−ｖ）はベースビデオコンポーネントを含むことができる。例えば、ベースビデオコンポーネントは少なくとも一つのベースビデオセグメントを含むことができる。例えば、ベースビデオコンポーネントはＨＤサービスを提供するためのビデオコンポーネントである。第５伝送セッション（ｔｓｉ−ｅｖ）はエンハンスメントビデオコンポーネントを含むことができる。例えば、エンハンスメントビデオコンポーネントは少なくとも一つのエンハンスメントビデオセグメントを含むことができる。例えば、エンハンスメントビデオコンポーネントはＵＨＤサービスを提供するためのビデオコンポーネント及び／又は付加情報である。
【１６２５】
以下ではＦＩＣについて説明する。
【１６２６】
ＦＩＣはＳｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ（ＳＬＴ）と言える。本発明の一実施例によるＦＩＣに関する内容は前述したＦＩＣに関する内容を全て含むことができる。
【１６２７】
ＦＩＣは「ＢＣＳｔｒｅａｍＩＤ１」の値を有する識別子ｅｌｅｍｅｎｔ及び／又は第１サービスｅｌｅｍｅｎｔを含むことができる。
【１６２８】
第１サービスｅｌｅｍｅｎｔは、「ＳｒｖｃＩＤ１」の値を有するｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ、「ＨＤ」の値を有するｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔを含むことができる。ＳＳＣ＿Ｂｏｏｔｓｔｒａｐ ｅｌｅｍｅｎｔは、「ｓＩＰＡｄｒｓ１」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「ＩＰＡｄｒｓ１」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、「Ｐｏｒｔ１」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅ、「ｔｓｉ−ｓ」の値を有するＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又は「ＤＰ＿ｉｄ１」の値を有するＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。ここで、「ＨＤ」の値を有するｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅはサービスが支援する最小限の性能（Ｃａｐａｂｉｌｉｔｙ）コードが「ＨＤ」であることを指示することができる。すなわち、サービスが「ＨＤ」及び「ＵＨＤ」の両者を支援することができる場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅは「ＨＤ」の値を有することができる。
【１６２９】
図１４７は本発明の一実施例によるＳＳＣを示した図である。
【１６３０】
以下ではＳＭＴについて説明する。
【１６３１】
図の（ａ）を参照すると、ＳＭＴはサービスの属性（アイディー、名前、カテゴリーなど）情報及びサービスを獲得することができる経路情報を含むことができる。本発明の一実施例によるＳＭＴに関連した内容は前述したＳＭＴに関する内容を全て含むことができる。
【１６３２】
ＳＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ ａｔｔｒｉｂｕｔｅ、サービスの名前を識別するＳｅｒｖｉｃｅＮａｍｅ ａｔｔｒｉｂｕｔｅ、サービスを支援するデバイスの性能を指示するＣａｐａｂｉｌｉｔｙ ａｔｔｒｉｂｕｔｅ、及び／又はサービスのためのＲＯＵＴＥセッションのブートストラップ情報を含むＲＯＵＴＥｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。
【１６３３】
例えば、Ｃａｐａｂｉｌｉｔｙ ａｔｔｒｉｂｕｔｅは「ＨＤ」及び「ＵＨＤ」の値を有することができる。すなわち、Ｃａｐａｂｉｌｉｔｙ ａｔｔｒｉｂｕｔｅはＨＤ及びＵＨＤの両者を支援することを指示することができる。
【１６３４】
以下ではＭＰＤについて説明する。
【１６３５】
ＭＰＤはリニア／ストリーミングサービスの個別的なメディアコンポーネントのためのリソース識別子を含むことができる。本発明の一実施例によるＭＰＤに関する内容は前述したＭＰＤに関する内容を全て含むことができる。
【１６３６】
ＭＰＤはＰｅｒｉｏｄ ｅｌｅｍｅｎｔを含むことができる。Ｐｅｒｉｏｄ ｅｌｅｍｅｎｔは少なくとも一つのオーディオコンポーネントについての情報を含む第１ＡｄａｐｔａｔｉｏｎＳｅｔ ｅｌｅｍｅｎｔ及び少なくとも一つのビデオコンポーネントについての情報を含む第２ＡｄａｐｔａｔｉｏｎＳｅｔ ｅｌｅｍｅｎｔを含むことができる。第１ＡｄａｐｔａｔｉｏｎＳｅｔ ｅｌｅｍｅｎｔはオーディオコンポーネントについての情報を含む第１Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔを含むことができる。第２ＡｄａｐｔａｔｉｏｎＳｅｔ ｅｌｅｍｅｎｔは、ベースビデオコンポーネントについての情報を含む第２Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ及びエンハンスメントビデオコンポーネントについての情報を含む第３Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔを含むことができる。
【１６３７】
第１Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ａ」、第２Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｖ」、第３Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｅｖ」であり得る。また、第３Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｅｌｅｍｅｎｔはｄｅｐｅｎｄｅｎｃｙＩｄ ａｔｔｒｉｂｕｔｅを含むことができ、ｄｅｐｅｎｄｅｎｃｙＩｄ ａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｖ」を指示することができる。
【１６３８】
以下ではＣＭＴについて説明する。
【１６３９】
ＣＭＴはサービスのためのコンポーネントデータの伝送経路情報を含むことができる。本発明の一実施例によるＣＭＴに関する内容は前述したＣＭＴに関する内容を全て含むことができる。
【１６４０】
ＣＭＴは第１サービスのための第１コンポーネントマップ情報を含むことができる。第１コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ ａｔｔｒｉｂｕｔｅ、第１サービスのためのオーディオコンポーネントの伝送経路情報を含む第１Ｃｏｍｐ ｅｌｅｍｅｎｔ（又はＢＣＣｏｍｐｏｎｅｎｔ ｅｌｅｍｅｎｔ）、第１サービスのためのベースビデオコンポーネントの伝送経路情報を含む第２Ｃｏｍｐ ｅｌｅｍｅｎｔ（又はＢＣＣｏｍｐｏｎｅｎｔ（ＨＤ） ｅｌｅｍｅｎｔ）、及び／又は第１サービスのためのエンハンスメントビデオコンポーネントの伝送経路情報を含む第３Ｃｏｍｐ ｅｌｅｍｅｎｔ（又はＢＣＣｏｍｐｏｎｅｎｔ（ＵＤ） ｅｌｅｍｅｎｔ）の少なくとも一つを含むことができる。
【１６４１】
例えば、第１サービスのための第１Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ａ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ１」であり得る。また、第１サービスのための第２Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｖ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ２」であり得る。また、第１サービスのための第３Ｃｏｍｐ ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｅｖ」、ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ３」であり得る。
【１６４２】
以下ではＬＳＩＤについて説明する。
【１６４３】
ＬＳＩＤはＳｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ（Ｓ−ＴＳＩＤ）と言える。本発明の一実施例によるＬＳＩＤに関する内容は前述したＬＳＩＤに関する内容を全て含むことができる。
【１６４４】
ＬＳＩＤは第１ＲＯＵＴＥセッションに含まれることができる。ＬＳＩＤは、オーディオコンポーネントを伝送する第１Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ、ベースビデオコンポーネントを伝送する第２Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ、及び／又はエンハンスメントビデオコンポーネントを伝送する第３Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔの少なくとも一つを含むことができる。例えば、第１Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ内のｔｓｉ ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ａ」、ｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ａ」であり得る。また、第２Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ内のｔｓｉ ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ｖ」、ｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｖ」であり得る。また、第３Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ ｅｌｅｍｅｎｔ内のｔｓｉ ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ｅｖ」、ｒｅｐｔｎＩＤ ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｅｖ」であり得る。
【１６４５】
図１４８は本発明の一実施例による放送送信方法の流れ図を示した図である。
【１６４６】
本発明の一実施例による放送伝送装置は制御部及び／又は伝送部を含むことができる。制御部は前述したサービスデータ及び／又は前述したシグナリング情報を生成することができる。また、伝送部は、サービスデータ及び／又はシグナリング情報を含む放送信号を伝送することができる。
【１６４７】
放送伝送装置は、制御部を用いて、同一コンデンツを提供する少なくとも一つのサービスのためのサービスデータを生成及び／又はエンコードすることができる（ＣＳ１４８０１００）。
【１６４８】
例えば、サービスデータは、オーディオコンポーネント、ベースビデオコンポーネント、及び／又はエンハンスメントビデオコンポーネントを含むことができる。
【１６４９】
また、放送伝送装置は、制御部を用いて、サービスのためのシグナリング情報を生成及び／又はエンコードすることができる（ＣＳ１４８０２００）。
【１６５０】
例えば、シグナリング情報は、サービスの獲得のための第１シグナリング情報（又はＳＬＳ）及び／又はサービスのためのブートストラップ情報を含む第２シグナリング情報（又は、ＦＩＣ）を含むことができる。第１シグナリング情報（又はＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つを含むことができる。第２シグナリング情報（又は、ＦＩＣ）はサービスのためのコンデンツのデコーディング及び／又は意味ある再生のために要求されるデバイスの性能及び／又は性能グループを指示する性能情報（例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅ）をさらに含むことができる。例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄは該当のサービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを指示することができる。例えば、ＵＤ／ＨＤｓｃａｌａｂｌｅ ｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄはＨＤを指示する値を有することができる。また、ＦＩＣは、同一コンデンツを提供する少なくとも一つのサービスのチャネル番号を指示するチャネル情報（又はｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅ）を含むことができる。また、シグナリング情報は第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するかを指示するフラグ情報（ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄ）及び／又は第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が伝送されるデータパイプ（又はＰＬＰ）の識別子を指示する識別子情報（ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄ）をさらに含むことができる。
【１６５１】
また、放送伝送装置は、制御部を用いて、サービスデータ及びシグナリング情報を含む放送信号を生成することができる。
【１６５２】
また、放送伝送装置は、伝送部を用いて、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる（ＣＳ１４８０３００）。
【１６５３】
図１４９は本発明の一実施例による放送受信方法の流れ図を示した図である。
【１６５４】
本発明の一実施例による放送受信装置は、ブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部の少なくとも一つを含むことができる。本発明の一実施例によるブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部は前述した内容を全て含むことができる。
【１６５５】
例えば、ブロードキャストインターフェースは放送ネットワークを介して放送信号を受信することができる。ブロードキャストインターフェースは、フィジカルレイヤーモジュール、及びフィジカルレイヤーＩＰフレームモジュールを含むことができる。あるいは、ブロードキャストインターフェースは、チューナー及びフィジカルフレームパーサーの少なくとも一つを含むことができる。
【１６５６】
例えば、ブロードバンドインターフェースはインターネットを介してデータを伝送及び／又は受信することができる。ブロードバンドインターフェースはインターネット接近制御モジュールを含むことができる。
【１６５７】
例えば、制御部は、前述したシグナリングデコーダー、データベース、サービスシグナリングマネージャー、アラートシグナリングマネージャー、サービスガイドマネージャー、アプリケーションシグナリングマネージャー、タゲッティングシグナリングマネージャー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネント同期化部、タゲッティングプロセッサ、アプリケーションプロセッサ、アラーティングプロセッサ、Ａ／Ｖプロセッサ、再分配モジュール、サービス／コンテンツ獲得制御部、及び／又はコンパニオンスクリーンインターフェースの少なくとも一つを含むことができる。コンパニオンスクリーンインターフェースは、データシェアリング部及び／又は装置管理者の少なくとも一つを含むことができる。本発明の一実施例による制御部に含まれる構成要素に対する内容は前述した同一乃至類似の名称を有する構成要素に対する内容を全て含むことができる。
【１６５８】
また、制御部は、前述したフィジカルレイヤー制御部、リンクレイヤーフレームパーサー（又はリンクレイヤーフレームプロセッサ）、ＩＰ／ＵＤＰデータグラムフィルター、アプリケーションレイヤー伝送クライアント、タイミングコントロール、システムクロック、ＤＴＶコントロールエンジン、使用者入力受信部、シグナリングパーサー、チャネルマップデータベース、ＨＴＴＰアクセスクライアント、ＨＴＴＰアクセスキャッシュ、ＤＡＳＨクライアント、ＩＳＯ ＢＭＦＦパーサー、メディアデコーダー及びファイルデータベースの少なくとも一つを含むことができる。本発明の一実施例による制御部に含まれる構成要素に対する内容は前述した同一乃至類似の名称を有する構成要素に対する内容を全て含むことができる。
【１６５９】
放送受信装置は、ブロードキャストインターフェース及び／又はブロードバンドインターフェースを用いて、同一コンデンツを提供する少なくとも一つのサービスのためのサービスデータ及びシグナリング情報を含む放送信号を受信することができる（ＣＳ１４９０１００）。
【１６６０】
サービスデータは、オーディオコンポーネント、ベースビデオコンポーネント、及び／又はエンハンスメントビデオコンポーネントを含むことができる。シグナリング情報は、サービスの獲得のための第１シグナリング情報（又はＳＬＳ）及び／又はサービスのためのブートストラップ情報を含む第２シグナリング情報（又は、ＦＩＣ）を含むことができる。第１シグナリング情報（又はＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つを含むことができる。第２シグナリング情報（又は、ＦＩＣ）は、サービスのためのコンデンツのデコーディング及び／又は意味ある再生のために要求されるデバイスの性能及び／又は性能グループを指示する性能情報（例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅ）をさらに含むことができる。例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄは該当のサービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを指示することができる。例えば、ＵＤ／ＨＤ ｓｃａｌａｂｌｅ ｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ ｆｉｅｌｄはＨＤを指示する値を有することができる。また、ＦＩＣは同一コンデンツを提供する少なくとも一つのサービスのチャネル番号を指示するチャネル情報（又はｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ ａｔｔｒｉｂｕｔｅ）を含むことができる。また、シグナリング情報は、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するかを指示するフラグ情報（ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ ｆｉｅｌｄ）及び／又は第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が伝送されるデータパイプ（又はＰＬＰ）の識別子を指示する識別子情報（ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ ｆｉｅｌｄ）をさらに含むことができる。
【１６６１】
例えば、使用者が第１サービス（ＳｒｖｃＩＤ１）を選択した場合、放送受信装置はＦＩＣに基づいて、ｍｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｃｏｄｅ ｆｉｅｌｄを獲得することができる。また、放送受信装置はＦＩＣに基づいて少なくとも一つのサービスに対するｍｉｎｉｍｕｍ Ｃａｐａｂｉｌｉｔｙ ｃｏｄｅ ｆｉｅｌｄを獲得することができる。本発明の一実施例による第１サービスはＵＤ／ＨＤを全て支援することができるサービスであってもよく、この場合、ｍｉｎｉｍｕｍ Ｃａｐａｂｉｌｉｔｙ ｃｏｄｅはＨＤを示すことができる。
【１６６２】
また、放送受信装置は、制御部を用いて、放送信号から第２シグナリング情報（又は、ＦＩＣ）を獲得することができる。例えば、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するかを指示するフラグ情報が「Ｔｒｕｅ」を指示すれば、放送受信装置はフラグ情報に基づいて放送信号から第２シグナリング情報を獲得することができる。
【１６６３】
また、放送受信装置は、制御部を用いて、第２シグナリング情報（又は、ＦＩＣ）からサービス属性及び／又は第１シグナリング情報（又は、サービスレイヤーシグナリング情報、ＳＬＳ）のブートストラップ情報を獲得することができる。例えば、第２シグナリング情報（又は、ＦＩＣ）は、ｓｅｒｖｉｃｅ＿ｉｄ ａｔｔｒｉｂｕｔｅ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｔｓｉ ａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿ＤＰ＿ｉｄ ａｔｔｒｉｂｕｔｅの少なくとも一つを含むことができる。
【１６６４】
また、放送受信装置は、制御部を用いて、シグナリング情報に基づいてサービスをフィルタリングすることができる（ＣＳ１４９０２００）。
【１６６５】
例えば、第２シグナリング情報（又は、ＦＩＣ）はサービスのデコーディングのために要求される性能情報を含み、放送受信装置は性能情報に基づいてデコーディング及び／又はプレゼンテーションすることができるサービスをフィルタリングすることができる。また、フィルタリングされたサービスは複数であり、獲得された第１シグナリング情報は全てのフィルタリングされたサービスの獲得のための情報であり得る。
【１６６６】
また、放送受信装置は、制御部を用いて、フィルタリングされたサービスのためのサービス属性及び／又はサービスレイヤーシグナリング情報（ＳＬＳ）のブートストラップ情報をチャネルマップに１次的に保存することができる。
【１６６７】
また、放送受信装置は、制御部を用いて、第２シグナリング情報（又は、ＦＩＣ）に基づいてフィルタリングされたサービスのための第１シグナリング情報（又は、ＳＬＳ）を獲得することができる（ＣＳ１４９０３００）。
【１６６８】
例えば、放送受信装置は第２シグナリング情報（又は、ＦＩＣ）からフィルタリングされたサービスのための第１シグナリング情報（又は、ＳＬＳ）ブートストラップ情報を獲得し、第１シグナリング情報（又は、ＳＬＳ）ブートストラップ情報に基づいて第１シグナリング情報（又は、ＳＬＳ）を獲得することができる。例えば、第１シグナリング情報（又は、ＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤの少なくとも一つを含むことができる。放送受信装置は第１シグナリング情報（又は、ＳＬＳ）に基づいてどのレプリゼンテーションが放送ネットワークを介して伝送されるかを決定することができる。
【１６６９】
また、放送受信装置は、制御部を用いて、フィルタリングされたサービスのための獲得された１シグナリング情報（又は、ＳＬＳ）に含まれた情報をチャネルマップに２次的に保存することができる（ＣＳ１４９０４００）。
【１６７０】
例えば、１シグナリング情報（又は、ＳＬＳ）に含まれた情報は、サービスの属性（アイディー、名前、カテゴリーなど）、サービスを獲得することができる経路情報、及び／又はサービスについての情報を含むことができる。サービスを獲得することができる経路情報は、サービスのためのコンポーネントに係わるレプリゼンテーションを識別する情報（ｒｅｐｔｎＩｄ ａｔｔｒｉｂｕｔｅ）、サービスのためのコンポーネントデータが伝送されるＤＰ（又はＰＬＰ）を識別する情報（ｄａｔａｐｉｐｅＩＤ ａｔｔｒｉｂｕｔｅ）、及び／又はサービスのためのコンポーネントが伝送される伝送セッションを識別する情報（ｔｓｉ ａｔｔｒｉｂｕｔｅ）の少なくとも一つを含むことができる。
【１６７１】
また、フィルタリングされたサービスが複数であれば、放送受信装置は、制御部を用いて、チャネル情報に基づいて複数のサービスの中で一つのサービスを選択することができる。
【１６７２】
また、放送受信装置は、制御部を用いて、チャネルマップに基づいてサービスデータを獲得することができる。
【１６７３】
また、放送受信装置は、制御部を用いて、サービスデータをデコーディングすることができる。
【１６７４】
本発明の一実施例による放送受信装置がベースレイヤーのベースビデオコンポーネントを受信及び／又は獲得すれば、放送受信装置はＨＤ関連のコンポーネントをデコードして出力することができる。
【１６７５】
また、放送受信装置がＵＨＤ関連のコンポーネントをデコーディング及び／又は出力するためには、ベースレイヤーのベースビデオコンポーネント及びエンハンスメントレイヤーのエンハンスメントビデオコンポーネントを全てデコードしなければならない。
【１６７６】
放送受信装置がＳＤまでだけ支援することができれば、放送受信装置は第１サービスを再生することができないであろう。
【１６７７】
放送受信装置がＨＤを支援することができれば、放送受信装置はＳＳＣに基づいてより詳細なサービス関連情報を受信することができる。また、放送受信装置はＳＳＣからサービスの全ての性能情報（ｃａｐａｂｉｌｉｔｙ）を獲得することができる。また、放送受信装置は、ＭＰＤ内の情報（ｅ．ｇ．Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＠ｄｅｐｅｎｄｅｎｃｙＩＤ）を介してｒｅｐｒｅｓｅｎｔａｔｉｏｎ間のｄｅｐｅｎｄｅｎｃｙ関係（すなわち、ｂａｓｅ／ｅｎｈａｎｃｅｄ ｌａｙｅｒ）、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの解像度（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎのｗｉｄｔｈ／ｈｅｉｇｈｔ ａｔｔｒｉｂｕｔｅ）などが分かることができる。また、本発明の一実施例によるＳＭＴのｃａｐａｂｉｌｉｔｙはＨＤ／ＵＤの二つの性能情報（ｃａｐａｂｉｌｉｔｙ）を有することができる。放送受信装置がＵＤを支援することができなければ、放送受信装置はＨＤにあたるコンポーネントを受信及び／又はデコードすることができる。
【１６７８】
放送受信装置がＵＤを支援することができれば、放送受信装置は、前述したシナリオの遂行後、ＵＤにあたるコンポーネントを受信及び／又はデコードすることができる。
【１６７９】
図１５０は本発明の一実施例による、受信機移動時の他の周波数へのハンドオーバー（ｈａｎｄｏｖｅｒ）状況を示す図である。
【１６８０】
特定のサービスを受信している受信機が移動する場合、同じサービスをシームレス（ｓｅａｍｌｓｓ）に視聴するための他の周波数へのハンドオーバー動作が必要であることができる。ここで、受信機の移動する場合には多くの状況があり得、特に受信機がモバイルデバイスである場合にあたることができる。
【１６８１】
特定のサービスを提供する送信機は地域別に複数存在することができる。受信機が特定の送信機がカバーする地域を外れて他の送信機がカバーする地域に移動する場合には、シームレスハンドオーバーのための情報又は動作がさらに必要であることができる。ここで、ＭＦＮ状況を仮定する。同じサービスが地域別に互いに異なる周波数を介して送出される状況を仮定する。
【１６８２】
図示の実施例において、受信機は送信機Ａ（Ｔｒａｎｓｍｉｔｔｅｒ Ａ）がカバーする地域を外れ、送信機Ｂがカバーする地域に移動することができる。その間、受信機はサービスＸを視聴していると仮定する。ここで、送信機ＡはサービスＸを周波数１０を介して送出し、送信機Ｂは同一サービスＸを周波数２０を介して送出することができる。サービスＸを持続的に再生するために、受信機は適切な周波数にチューニングするための情報を必要とすることができる。
【１６８３】
図１５１は本発明の一実施例による、シームレスハンドオーバーのための情報伝達方案を示す図である。
【１６８４】
前述したように、シームレスハンドオーバーのために、受信機は適切な情報を必要とすることができる。このような情報は、実施例によって、前述したＬＬＳ（Ｌｉｎｋ Ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ）、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）、ＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）、ＳＳＣ（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ）又はそれぞれのＳＬＳ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）を介して伝達されることができる。ここで、シームレスハンドオーバーのための情報はＣＩＤ（Ｃｅｌｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれることができる。
【１６８５】
図示の実施例はＣＩＤがリンクレイヤーシグナリングを介して伝達される場合を示した。
【１６８６】
図示の実施例において、ブロードキャストストリームを介してサービスデータが伝達されることができる。このブロードキャストストリームはブロードキャストストリームＩＤによって識別されることができる。ブロードキャストストリームは特定の帯域幅の中央周波数値に定義されるＲＦチャネルアブストラクション（ａｂｓｔｒａｃｔｉｏｎ）として、地域（ａｒｅａ）と周波数（ｆｒｅｑｕｅｎｃｙ）情報によって識別されることができる。ブロードキャストストリームは複数のＰＬＰを含むことができる。ＰＬＰはＤＰと呼ばれることもできる。この実施例では、ＢＳＩＤ＝１によって識別されるブロードキャストストリームを介してサービスデータが伝達されている。
【１６８７】
前述した伝送セッション、ＲＯＵＴＥ／ＭＭＴＰセッションは複数のＰＬＰを介して伝送されることができる（ＰＬＰＩＤ＝１，２，３）。伝送セッション、例えば、ＲＯＵＴＥセッションはＩＰ、ＵＤＰ情報（ＩＰ ａｄｄｒｅｓｓ １、ＵＤＰ ｐｏｒｔ ｎｕｍｂｅｒ １）によって識別されることができ、複数のＬＣＴセッションを含むことができる。各ＬＣＴセッションはサービスデータであるオーディオ／ビデオセグメントを伝達することができる。前述したように、特定のＬＣＴセッション（例えばｔｓｉ＝０であるＬＣＴセッション）を介してはＳＬＳが伝達されることができる。図示の実施例では、これをＳＣＳフラグメントとして表現した（ｔｓｉ＝ｓ）。図示の実施例では、ＬＳＩＤが使われ、これがさらに他のＬＣＴセッションに伝達されるものに表現されたが、実施例によってＬＳＩＤは前述したＳ−ＴＳＩＤに取り替えられることができ、このＳ−ＴＳＩＤはＳＬＳに含まれて伝達されることができる。また、ＦＩＣが使われ、このＦＩＣがＰＬＰではない別個のチャネルを介して伝達されるものに表現されたが、実施例によってＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）及びＳＬＴがＦＩＣの代わりに使われることができ、このＬＬＳは前述したようによく知られた（ｗｅｌｌ ｋｎｏｗｎ）ＩＰ／ＵＤＰを介して伝達されることができる。
【１６８８】
この実施例で、ＣＩＤはリンクレイヤーシグナリングによって伝達される（ｔ１５１０１０）。現在周波数で送出される全てのサービスに対し、隣接した送信機がこれを他の周波数を介して送出している場合、これについての情報を一つのＣＩＤ内に集めることができる。
【１６８９】
この場合、リンクレイヤーシグナリングがＣＩＤ情報を含むことができる。リンクレイヤーシグナリングはＳＬＴ、ＳＬＳなどの情報より受信機が先に獲得することができる情報であり、ＣＩＤが受信機によって速く獲得されるようにすることができる。もちろん、隣接した送信機が一部サービスに対してのみ他の周波数を介して送出している場合にも、リンクレイヤーシグナリングによってＣＩＤが伝達されることができる。この場合、ＣＩＤはサービス別にハンドオーバー情報を有することができる。例えば、一つの周波数に５個のサービスが含まれて伝送される場合、その中で２個のサービスに対してのみ隣接した送信機が他の周波数を介して送出中であれば、ＣＩＤはその２個のサービスに対するハンドオーバー情報を提供することができる。残りの３個のサービスに対してはハンドオーバー情報が不要であるので、ＣＩＤは関連情報を含まないか、あるいはサービスを同一周波数を介して送出している送信機についての情報を含むこともできる。
【１６９０】
シームレスハンドオーバーのための情報乃至ＣＩＤ情報に対する詳細な内容は後述する。
【１６９１】
図１５２は本発明の他の実施例による、シームレスハンドオーバーのための情報伝達方案を示す図である。
【１６９２】
前述したように、シームレスハンドオーバーのための情報はＳＬＳに含まれて伝送されることができる（ｔ１５２０１０）。ＳＬＳが含まれて伝送されるＬＣＴセッションをＳＳＣ（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ）と呼ぶこともできる。
【１６９３】
前述したように、ＳＬＳは各サービス別に、そのサービスに対するシグナリングを遂行することができる。ＳＬＳにＣＩＤ情報が含まれて伝送される場合、該当のＣＩＤはそのＳＬＳがシグナリングするサービスに対するハンドオーバー情報を含むことができる。
【１６９４】
例えば、ＳＬＳがサービス＃１をシグナリングする場合、そのＳＬＳに含まれて伝送されるＣＩＤはサービス＃１を同一又は異なった周波数を介して伝送する他の隣接送信機についての情報を含むことができる。したがって、移動中の受信機は該当のＣＩＤ情報を介してサービス＃１を絶え間なく再生することができる。
【１６９５】
ここで、ＣＩＤがＳＬＳに含まれて伝送されるという意味は、実施例によって、ＳＬＳにＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどのようなＣＩＤが含まれるという意味であり得る。また、実施例によって、ＳＬＳに含まれるＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどが拡張されてＣＩＤ情報を含むという意味であり得る。また、実施例によって、ＣＩＤがＳＬＳに含まれるＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどに分散されて伝送されるという意味であり得る。また、実施例によって、ＳＬＳにあたる情報を用いて、受信機がＣＩＤにあたる情報を計算することができるという意味であり得る。
【１６９６】
図示されていないが、前述したように、ＣＩＤ情報はＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）、ＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）などを介して伝達されることができる。ローレベルシグナリング乃至ＳＬＴを介して伝達される場合、前述したＳＬＴなどのためのよく知られたＩＰ／ＵＤＰを介してＣＩＤが伝達されることができる。該当のＣＩＤはＳＬＴによって記述されるサービス又は該当のブロードキャストストリームを介して伝達されるサービスに対するハンドオーバー情報を含むことができる。
【１６９７】
図１５３は本発明の一実施例による、シームレスハンドオーバーのための情報を示す図である。
【１６９８】
前述したように、このハンドオーバーのための情報はＣＩＤと呼ばれることができる。ＣＩＤは、隣接した送信機が送出している同一サービスを伝達するようにハンドオーバーされることができるように、送信機の位置、信号強度などの情報を提供することができる。ＣＩＤは実施例によって違うように構成されることができ、後述するホームセル送信機についての情報と各サービスに対するセルについての情報のいずれか一方のみを有することもできる。ここで、ホームセル送信機とは、それぞれの複数の放送サービスを伝送する現在周波数と同一の周波数を用いて、複数の同一放送サービスを送出している他の送信機を意味することができる。ここで、各サービスに対するセルについての情報とは、特定のサービスを伝送する現在周波数とは違う周波数を用いて、その特定のサービスを送出している他の隣接送信機についての情報を意味することができる。
【１６９９】
ＣＩＤは、該当のＣＩＤについての情報を示す部分と、ホームセル送信機についての情報を示す部分と、サービス別に該当のサービスを伝達する隣接送信機に対する部分とを含むことができる。実施例によって、ある一部分が省略／変更されることができ、新しい情報が付け加えられることもできる。例えば、ホームセル送信機が存在しない場合、サービス別の隣接送信機についての情報のみが含まれることもできる。ホームセル送信機及び隣接送信機は０個以上存在することができる。
【１７００】
ＣＩＤは、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄを含むことができる。
【１７０１】
＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎと＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎはそれぞれ該当のＣＩＤのメージャー／マイナープロトコルバージョン情報を示すことができる。
【１７０２】
＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄはＣＩＤに当たるブロードキャストストリームの識別子であり得る。ここで、ＣＩＤに当たるブロードキャストストリームとは該当のＣＩＤを送信しているブロードキャストストリームであってもよく、単に該当のＣＩＤが記述している他のブロードキャストストリームであり得る。
【１７０３】
ＣＩＤはＨｏｍｅ＿ｃｅｌｌ＿ｔｒａｎｓｍｉｔｔｅｒｓエレメントを複数含むことができる。これは前述したホームセル送信機についての情報にあたることができる。それぞれのＨｏｍｅ＿ｃｅｌｌ＿ｔｒａｎｓｍｉｔｔｅｒｓエレメントは、＠ｌａｔｔｉｔｕｄｅ、＠ｌｏｎｇｉｔｕｄｅ、＠ＡＥＲＰ、＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈ及び／又は＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓなどの情報を含むことができる。
【１７０４】
＠ｌａｔｔｉｔｕｄｅは該当のホームセル送信機の緯度情報を示すことができる。ここで、緯度情報は度（ｄｅｇｒｅｅ）の小数第４位（ｔｅｎ−ｔｈｏｕｓａｎｄｔｈｓ）までの正確度で示すことができる。緯度情報は正数／負数の緯度値に対する伝統的な用法で表記することができる。
【１７０５】
＠ｌｏｎｇｉｔｕｄｅは該当のホームセル送信機の経度情報を示すことができる。ここで、経度情報は度（ｄｅｇｒｅｅ）の小数第４位（ｔｅｎ−ｔｈｏｕｓａｎｄｔｈｓ）までの正確度で示すことができる。経度情報は正数／負数の経度値に対する伝統的な用法で表記することができる。
【１７０６】
＠ＡＥＲＰは該当のホームセル送信機の有効なＲＦパワーの理論的測定値であり、ＡＥＲＰはＡｖｅｒａｇｅ Ｅｆｆｅｃｔｉｖｅ Ｒａｄｉａｔｅｄ Ｐｏｗｅｒの略字である。ｄＢｋの単位で表現されることができ、Ｒａｄｉａｔｉｏｎのアンテナ中心の高さ（ｈｅｉｇｈｔ）によって調整されることができる。
【１７０７】
＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈはアンテナの方位角（ａｚｉｍｕｔｈ）パターンの、最大Ｎｕｌｌ値のデプス（ｄｅｐｔｈ）を示すことができる。この値は８ｄＢの倍数で表現されることができ、次に低い倍数値に切り捨てて（ｒｏｕｎｄ ｄｏｗｎ）表すことができる。２４ｄＢより大きな値はいずれも２４ｄＢに切り捨てられることができる。００値の場合、該当のデータがないことを意味することができる。
【１７０８】
＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓは、アンテナの方位角パターンが８ｄＢ又はピークＡＥＲＰより低い場合、オーディナルディレクション（ｏｒｄｉｎａｌ ｄｉｒｅｃｔｉｏｎｓ）を示すことができる。これは該当のビットポジションのゼロによって指示されることができる。ノーザン（ｎｏｒｔｈｅｒｎ）セクターはｍｓｂ値によって表されることができる。それぞれのつながるビットを時計方向に指示されることができる。したがって、ＮＥ（Ｎｏｒｔｈ Ｅａｓｔ）の場合、すぐ次のｍｓｂによって表されることができる。このような方式でＮＷ（Ｎｏｒｔｈ Ｗｅｓｔ）まで進むことができる。ＮＷの場合、ｌｓｂによって表されることができる。このフィールドの値が１１１１１１１１である場合、該当のデータがないことを意味することができる。
【１７０９】
ＣＩＤは複数のＳｅｒｖｉｃｅエレメントをさらに含むことができる。ここで、Ｓｅｒｖｉｃｅエレメントは前述したサービス別セル情報にあたることができる。このサービスエレメントはそれぞれのサービスに対し、そのサービスを他の周波数を介して送出している周辺の受信機についての情報を含むことができる。サービス当たり０個以上の隣接送信機があり得る。
【１７１０】
Ｓｅｒｖｉｃｅエレメントは＠ｓｅｒｖｉｃｅ＿ｉｄ及び／又は＠ｇｌｏｂａｌＵｎｉｑｕｅＳｅｒｉｖｅＩｄを含むことができる。それぞれは該当のサービスのサービスＩＤ及びグローバルにユニークなサービスＩＤを示すことができる。
【１７１１】
ＳｅｒｖｉｃｅエレメントはＣｅｌｌエレメントをさらに含むことができる。それぞれのＣｅｌｌエレメントは隣接した送信機についての情報を含むことができる。
【１７１２】
それぞれのＣｅｌｌエレメントは、＠ｌａｔｔｉｔｕｄｅ、＠ｌｏｎｇｉｔｕｄｅ、＠ＡＥＲＰ、＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈ及び／又は＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓを含むことができる。それぞれのフィールドは、該当のセル、つまり隣接送信機に対する緯度／経度情報、ＡＥＲＰ情報、相対的パターンデプス情報、ナルポジション情報などを示すことができる。フィールドに対する詳細な説明は前述したようである。ただし、この場合、ホームセル送信機についての情報ではなく、該当のサービスを他の周波数を介して送出している隣接送信機についての情報が使われることが違う。
【１７１３】
それぞれのＣｅｌｌエレメントは、＠ｆｒｅｑｕｅｎｃｙ、＠ｐｒｅａｍｂｌｅ、＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ、＠ＤＰ＿ｉｄ、＠ｐｒｏｖｉｄｅｒ＿ｉｄ、及び＠ｓｅｒｖｉｃｅ＿ｉｄ情報をさらに含むことができる。
【１７１４】
＠ｆｒｅｑｕｅｎｃｙは該当のサービスを他の周波数を介して送出している隣接送信機において、該当のサービスを送出しているその他の周波数についての情報を示すことができる。正確には、該当のサービスを送出している帯域幅の中央周波数（ｃｅｎｔｅｒ ｆｒｅｑｕｅｎｃｙ）情報を示すことができる。
【１７１５】
＠ｐｒｅａｍｂｌｅは該当のサービスを伝送するその他の周波数に対するプリアンブルシンボルについての情報を示すことができる。ここで、プリアンブルシンボルとは、信号フレームのブートストラップ情報、Ｌ１情報、プリアンブル情報又はＰ１情報などを示すことができる。
【１７１６】
＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄは該当の隣接送信機が該当のサービスを送出しているブロードキャストストリームの識別子を示すことができる。
【１７１７】
＠ＤＰ＿ｉｄは該当の隣接送信機が該当のサービスを送出しているＰＬＰ乃至ＤＰの識別子を示すことができる。ここで、実施例によって、このフィールドは該当のサービスのＳＬＴ情報が伝達されるＰＬＰのＩＤ情報を示すこともできる。また、実施例によって、このフィールドは該当のサービスのＳＬＳ情報が伝達されるＰＬＰのＩＤ情報を示すこともできる。また、実施例によって、このフィールドは該当のサービスのサービスデータが伝達されるＰＬＰの情報を示すこともできる。実施例によって、このフィールドはサービス別に複数存在することもできる。
【１７１８】
＠ｐｒｏｖｉｄｅｒ＿ｉｄは該当の隣接送信機が送出しているサービスのサービスプロバイダー識別子情報を示すことができる。
【１７１９】
＠ｓｅｒｖｉｃｅ＿ｉｄは該当の隣接送信機が送出しているサービスのサービス識別子を示すことができる。ホームセル送信機が送出している同一サービスに対して同一のＩＤ値を有することもでき、他のＩＤ値を有することもできる。同一のＩＤ値を有する場合、このフィールドの値はＳｅｒｖｉｃｅ＠ｓｅｒｖｉｃｅ＿ｉｄフィールドのような値を有することができる。
【１７２０】
図１５４は本発明の一実施例によるローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【１７２１】
ローレベルシグナリング情報は、物理的階層とローレベルシグナリングが伝達される階層の上位階層を連結させる役目をするシグナリング情報を含むことができる。受信機は、ローレベルシグナリング情報を用いて、物理的階層によって伝達された放送信号の中で、受信機が望む放送サービス／コンテンツを効率的に探し出すことができる。
【１７２２】
ローレベルシグナリング情報はＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）を含むことができる。ＦＩＣは他の名前で呼ばれることもでき、一例としてＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）と名付けられることもできる。
【１７２３】
本発明の一実施例では、各サービスのＭｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに付け加えて、受信機のサービススキャン（ｓｅｒｖｉｃｅ ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ ｒｅｎｄｅｒｉｎｇ）を効率的に進めることができる方案を提案する。
【１７２４】
図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｅｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７２５】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報はＦＩＣシグナリング構造のプロトコルのバージョンを識別する。
【１７２６】
Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報は放送ストリームを識別する情報である。
【１７２７】
ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報は、Ｓｅｒｖｉｃｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＳＣＤ）が伝送されるか（又は存在するか）を指示することができる。ＳＣＤはサービスレベルシグナリング情報を含むことができる。
【１７２８】
ＤＰ＿ｉｄ情報は、ローレベルシグナリング情報及び／又はサービスレベルシグナリング情報を伝送するデータパイプ（又はＰＬＰ）を識別する情報である。
【１７２９】
ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントはＦＩＣレベルのディスクリプタを含むことができる。
【１７３０】
ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報はＦＩＣによってスキャン可能な放送サービスの数を示す。
【１７３１】
ｐｒｏｖｉｄｅｒ＿ｉｄ情報は放送サービスを提供するプロバイダーを識別する情報である。
【１７３２】
ｓｅｒｖｉｃｅ＿ｉｄ情報は放送サービスを識別する情報である。
【１７３３】
ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報はサービスシグナリングチャネル（ＳＳＣ、又はサービスレベルシグナリング）のバージョンを示す情報である。
【１７３４】
ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報はサービスのチャネル番号を示す。
【１７３５】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報はサービスのカテゴリーを識別する。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は放送サービスがＡ／Ｖサービス、オーディオサービス、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）サービス、及び／又はＮＲＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ）サービスであるかを示すことができる。
【１７３６】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報はサービスの短いサービス名を示す情報の長さを示す情報である。
【１７３７】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報はサービスの短いサービス名を示す。
【１７３８】
ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報はサービスの状態を示す。例えば、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、サービスが、ａｃｔｉｖｅ状態、ｉｎａｃｔｉｖｅ状態、ｓｈｏｗ状態及び／又はｈｉｄｄｅｎ状態であることを示すことができる。
【１７３９】
ｓｐ＿ｉｎｄｉｃａｔｏｅｒ情報はサービスにサービス保護（ｓｅｒｖｉｃｅ ｐｒｏｔｅｃｔｉｏｎ）が適用されたかを示す情報である。
【１７４０】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報はサービスに関連したＩＰパケットに使われるＩＰバージョン情報を示す情報である。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報のｔｒｕｅ又はｆａｌｓｅ値によって、ＩＰｖ４又はＩＰｖ６であることを示すことができる。
【１７４１】
ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報はサービスシグナリングチャネルのソース（ｓｏｕｒｃｅ）ＩＰアドレスを示す情報が存在するかを識別する情報である。
【１７４２】
ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報はサービスをレンダリングするために要求される、受信機の最小性能を示す情報である。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報はＦＩＣによってシグナリングされる放送サービスをレンダリングするために受信機が備えなければならない最小限の性能を識別する。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は該当のサービスの表出（ｐｒｅｓｅｎｔａｔｉｏｎ）に必須に必要な最小性能プロファイル（ｍｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅ）を表現する。このプロファイル（ｐｒｏｆｉｌｅ）に対し、ＦＩＣのｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報と連関してその値の範囲が定義されることができる。
【１７４３】
ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報はサービスシグナリングチャネルを伝送するソース（ｓｏｕｒｃｅ）のＩＰアドレスを示す情報である。
【１７４４】
ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報はサービスシグナリングチャネルに対するデスティネーション（ｄｅｓｃｔｉｎａｔｉｏｎ）のＩＰアドレスを示す情報である。
【１７４５】
ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報サービスシグナリングチャネルに対するデスティネーション（ｄｅｓｃｔｉｎａｔｉｏｎ）のＵＤＰ ｐｏｒｔ番号を示す情報である。
【１７４６】
ＳＳＣ＿ＴＳＩ情報はサービスシグナリングチャネルのデータを伝送する伝送セッションを識別する情報である。
【１７４７】
ＳＳＣ＿ＤＰ＿ｉｄ情報はサービスシグナリングチャネルのデータを伝送するデータパイプを識別する情報である。
【１７４８】
ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報は放送サービスが基本であるかを識別する情報である。ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報はサービスシグナリングを伝達するＲＯＵＴＥセッションのようなＲＯＵＴＥセッションを介してオーディオ、ビデオあるいはキャプションデータが一緒に伝送され、サービスシグナリングを伝達するデータパイプを介して全てのデータが一緒に伝送されるかを識別する情報である。
【１７４９】
図の（ｂ）を参照すると、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスがリニア（ｌｉｎｅａｒ）サービスである場合、サービスをレンダリングするために受信機に要求される最小性能が、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）処理性能又はＵＨＤ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）処理性能であるかなどがｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報によって識別されることができる。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報が示すサービスのカテゴリーがリニア（ｌｉｎｅａｒ）サービスであり、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の値が‘ｘ１’である場合、該当のサービスは最小ＵＨＤをレンダリングすることができる装置（ｄｅｖｉｃｅ）のみが、ＦＩＣを用いた放送スキャンを介して、チャネルマップ（Ｃｈａｎｎｅｌ Ｍａｐ）に該当のサービスを付け加えるようにすることができる。これは、受信機が支援することができないサービスを提供する場合、チャネルマップに該当のサービスが含まれないようにして、使用者が視聴することができないサービスは選択しないことができるようにすることにより、チャネル選択時の効率性をはかることができる。
【１７５０】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスがアプリ（Ａｐｐ；Ａｐｐｌｉｃａｔｉｏｎ）サービスである場合、サービスをレンダリングするために受信機に要求される最小性能が、ブロードバンドを介してダウンロード可能な性能を備えなければならないか、ブロードバンドを用いなくてもダウンロード可能な性能を備えなければならないｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報によって識別されることができる。
【１７５１】
図１５５は本発明の一実施例による、ＦＩＣを用いて、受信機でサービスを表出する過程を示した図である。
【１７５２】
図の（ａ）を参照すると、受信機は放送信号内の特定の領域を介して伝送されるＦＩＣを獲得することができる。
【１７５３】
受信機はＦＩＣ内のｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報をパーシングして、ｓｅｒｖｉｃｅ＿ｉｄ情報によって識別されるサービスがアプリサービスであることを識別することができる。
【１７５４】
受信機はＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報が有する値のＭＳＢ（Ｍｏｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）をチェックする。
【１７５５】
受信機は、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報のＭＳＢが‘１’である場合、アプリサービスに含まれるコンポーネントがブロードバンドを介して伝送されていないと認識することができる。これはアプリサービスに含まれるコンポーネントが放送ネットワークを介して伝送されることを示すものである。したがって、放送ネットワークを介してコンポーネントをダウンロードすることができない受信機は、該当のアプリサービスをレンダリングすることができないことを認識することができる。したがって、放送ネットワークを介してコンポーネントをダウンロードすることができる受信機のみが、チャネルマップに該当のアプリサービスを含ませ、放送ネットワークを介してコンポーネントをダウンロードすることができない受信機は、チャネルマップに該当のアプリサービスを含ませないこともできる。
【１７５６】
本発明の一実施例において、受信機は、ＦＩＣのｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報のみを獲得した場合であっても、受信機で支援しないサービスをチャネルマップに登録しないようにすることで、支援しないサービスに対する誤作動確率を減らすことができる。
【１７５７】
図の（ｂ）を参照すると、ＵＳＤはＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントを含むことができる。ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントはそれぞれのサービスをレンダリングするために受信機に要求される性能についての情報を含むことができる。この例において、ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメント内の情報は、受信機がブロードバンドネットワークを介してなく、放送ネットワークを介して、特定のサービスのコンポーネントを受信することができなければならないことを示すことができる。
【１７５８】
図１５６は本発明の他の実施例による、ローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【１７５９】
本発明の他の実施例は、各サービスのＭｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに付け加え、受信機のサービススキャン（ｓｅｒｖｉｃｅ ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ ｒｅｎｄｅｒｉｎｇ）を効率的に進めることができる方案を提案する。
【１７６０】
図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｅｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７６１】
それぞれの情報又はエレメントについての説明は前述した説明に取り替える。
【１７６２】
この実施例では、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に１０ビットを割り当てることができる。この場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報が、後に付け加えられる性能（ｃａｐａｂｉｌｉｔｙ）関連情報の拡張を支援することができる。
【１７６３】
図の（ｂ）を参照すると、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の構造が示されている。
【１７６４】
例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスのカテゴリーがリニア（Ｌｉｎｅａｒ）サービスである場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられたビットの中で、４ビットビデオを処理するのに要求される性能を識別するビデオ性能プロファイル（Ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅ）に定義し、他の４ビットはオーディオを処理するのに要求される性能を識別するオーディオ性能プロファイルに定義することができる。
【１７６５】
例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスのカテゴリーがアプリ（Ａｐｐ；Ａｐｐｌｉｃａｔｉｏｎ）サービスである場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられたビットの中で、２ビットはアプリサービスをダウンロードするのに使われるプロトコル（Ｄｏｗｎｌｏａｄ ｐｒｏｔｏｃｏｌ）に関連して受信機に要求される性能プロファイル（Ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅ）として定義されることができる。
【１７６６】
図１５７は本発明の他の実施例による、ローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【１７６７】
本発明の他の実施例は、各サービスのＭｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに付け加えて、受信機のサービススキャン（ｓｅｒｖｉｃｅ ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ ｒｅｎｄｅｒｉｎｇ）を効率的に進めることができる方案を提案する。
【１７６８】
図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｅｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７６９】
それぞれの情報又はエレメントについての説明は前述した説明に取り替える。
【１７７０】
ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報はＦＩＣに含まれることができる最小性能情報の数を示す。ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報はＦＩＣで定義される最小性能プロファイル（ｍｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅ）の数を示す。最小性能プロファイルは最大４個までＦＩＣに含まれることができる。
【１７７１】
ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の値がどのタイプのコンポーネントに関連したものであるかを示す情報である。
【１７７２】
ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報はサービスの表出のために必須に必要な受信機の最小性能プロファイルを示す。ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報はサービスをレンダリングするために受信機に要求される最小限の性能を識別する情報である。
【１７７３】
図の（ｂ）を参照すると、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値によって該当の情報が示すコンポーネントが開示されている。例えば、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が‘００’である場合、最小性能プロファイルが適用されるコンポーネントがビデオコンポーネントであることを示すことができ、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が‘０１’である場合、最小性能プロファイルが適用されるコンポーネントがオーディオコンポーネントであることを示すことができ、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が‘１０’である場合、最小性能プロファイルが適用されるコンポーネントがアプリ（Ａｐｐ、Ａｐｐｌｉｃａｔｉｏｎ）コンポーネントであることを示すことができる。
【１７７４】
図１５８は本発明の他の実施例による、ローレベルシグナリング（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）情報を示した図である。
【１７７５】
本発明の他の実施例は、各サービスのＭｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに付け加えて、受信機のサービススキャン（ｓｅｒｖｉｃｅ ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ ｒｅｎｄｅｒｉｎｇ）を効率的に進めることができる方案を提案する。
【１７７６】
図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｅｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７７７】
それぞれの情報又はエレメントについての説明は前述した説明に取り替える。
【１７７８】
ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報はＦＩＣが定義するチャネル（Ｃｈａｎｎｅｌ）の最小性能プロファイル（ｍｉｎｉｍｕｍ ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅ）を示す。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報には８ビットが割り当てられることができる。８ビットに含まれる各ビットの組合せによって、最小性能プロファイルがどのコンポーネントタイプの性能プロファイル（ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅ）に当たるかを定義することができる。
【１７７９】
図の（ｂ）を参照すると、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられるビットの組合せ及びこれらが示す情報が示されている。
【１７８０】
８ビットの中で、ＭＳＢの２ビットは、性能プロファイル（ｃａｐａｂｉｌｉｔｙ ｐｒｏｆｉｌｅ）が適用されるコンポーネントのタイプを示す。例えば、２ビットの値が‘００’である場合、最小性能プロファイルが適用されるコンポーネントがビデオコンポーネントであることを示すことができ、２ビットの値が‘０１’である場合、最小性能プロファイルが適用されるコンポーネントがオーディオコンポーネントであることを示すことができ、２ビットの値が‘１０’である場合、最小性能プロファイルが適用されるコンポーネントがアプリ（Ａｐｐ、Ａｐｐｌｉｃａｔｉｏｎ）コンポーネントであることを示すことができる。
【１７８１】
８ビットの中で、２ビットを割り当てて、ビデオコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が‘００’である場合、ＨＤビデオチャネルが提供され、受信機はＨＤビデオを処理することができる能力が要求されることを示し、２ビットの値が‘０１’である場合、ＵＨＤビデオチャネルが提供され、受信機はＵＨＤビデオを処理することができる能力が要求されることを示す。
【１７８２】
８ビットの中で、２ビットを割り当てて、オーディオコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が‘００’である場合、既存の放送システム（例えば、ＡＴＳＣ１．０放送システム）で適用される形態のオーディオコンポーネントが提供され、受信機は既存の放送システムで提供される形態のオーディオコンポーネントを処理することができる能力が要求されることを示し、２ビットの値が‘０１’である場合、次世代放送システム（例えば、ＡＴＳＣ３．０放送システム）で適用される形態のオーディオコンポーネントが提供され、受信機は次世代放送システムで提供される形態のオーディオコンポーネントを処理することができる能力が要求されることを示す。
【１７８３】
８ビットの中で、２ビットを割り当てて、アプリケーションのコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が‘００’である場合、アプリケーションのコンポーネントがブロードバンドに提供され、受信機は該当のコンポーネントを受信処理するために、ブロードバンドを介したダウンロードを処理することができる能力が要求されることを示し、２ビットの値が‘０１’である場合、アプリケーションのコンポーネントがブロードバンドに提供されなく、受信機は該当のコンポーネントを受信処理するために、ブロードバンドでない他のネットワーク（例えば、放送ネットワーク）を介したダウンロードを処理することができる能力が要求されることを示す。
【１７８４】
図１５９は本発明の他の実施例による、ＦＩＣを用いて、受信機でサービスを表出する過程を示した図である。
【１７８５】
図の（ａ）を参照すると、受信機は放送信号内の特定の領域を介して伝送されるＦＩＣを獲得することができる。
【１７８６】
受信機は、ＦＩＣ内のｃｈａｎｎｅｌ＿ｃａｐａｃｉｔｙ＿ｐｒｏｆｉｌｅ情報（ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、及び／又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を含むことができる）を獲得する。
【１７８７】
受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の一部ビット又はｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報を用いて、性能プロファイルが適用されるコンポーネントのタイプを識別することができる。
【１７８８】
受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の一部ビット又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を用いて、それぞれのコンポーネントタイプに適用される最小性能プロファイルを識別することができる。
【１７８９】
本発明によると、受信機は、ＦＩＣレベルの情報を用いて、各チャネルを表出するために受信機に要求される性能が分かる。ＦＩＣに記述されるチャネルレベル（Ｃｈａｎｎｅｌ Ｌｅｖｅｌ）の性能（ｃａｐａｂｉｌｉｔｙ）は全チャネルに共通して適用されることができる、めったに変わらない性能（ｃａｐａｂｉｌｉｔｙ）として記述されることができる。
【１７９０】
図の（ｂ）を参照すると、ＵＳＤに含まれることができるＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントが開示されている。ＵＳＤに含まれるＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントはサービスレベルでの性能についての情報（Ｓｅｒｖｉｃｅ ｌｅｖｅｌ ｃａｐａｂｉｌｉｔｙ）を含むことができる。受信機がサービスを獲得する過程で、プログラム（又はイベント）別の性能（ｃａｐａｂｉｌｉｔｙ）はサービスレベルシグナリングによって記述されることができ、このようなサービスレベル（Ｓｅｒｖｉｃｅ ｌｅｖｅｌ）での性能（ｃａｐａｂｉｌｉｔｙ）についての情報はＦＩＣで記述される性能についての情報より優先順位を有することができる。ここで、性能についての情報は、前述したｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、及び／又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を含むことができる。
【１７９１】
図１６０は本発明の一実施例による、放送信号を生成処理する方法を示した流れ図である。
【１７９２】
送信機は一つ以上の放送サービスのための放送データをエンコードする（ＪＳ１６００１０）。
【１７９３】
送信機は一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコードする（ＪＳ１６００２０）。
【１７９４】
送信機は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードする（ＪＳ１６００３０）。
【１７９５】
送信機は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する（ＪＳ１６００４０）。
【１７９６】
本発明の一実施例によると、第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコードするのに要求される性能を識別する第１性能情報を含むことができる。
【１７９７】
図１６１は本発明の一実施例による放送システムを示した図である。
【１７９８】
本発明の一実施例による放送システムは、放送送信機Ｊ１６１１００及び／又は放送受信機Ｊ１６１２００を含むことができる。
【１７９９】
放送送信機Ｊ１６１１００は、放送データエンコーダＪ１６１１１０、シグナリングエンコーダＪ１６１１２０及び／又は放送信号生成器Ｊ１６１１３０を含むことができる。
【１８００】
放送受信機Ｊ１６１２００は、放送信号受信部Ｊ１６１２１０、プロセッサＪ１６１２２０及び／又はディスプレイ部Ｊ１６１２３０を含むことができる。
【１８０１】
放送データエンコーダＪ１６１１１０は一つ以上の放送サービスのための放送データをエンコードする。
【１８０２】
シグナリングエンコーダＪ１６１１２０は一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報及び／又は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードする。
【１８０３】
放送信号生成器Ｊ１６１１３０は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する。
【１８０４】
本発明の一実施例によると、第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコードするのに要求される性能を識別する第１性能情報を含むことができる。
【１８０５】
放送信号受信部Ｊ１６１２１０は、一つ以上の放送サービスのための放送データ、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報を含む放送信号を受信する。第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコードするのに要求される性能を識別する第１性能情報を含むことができる。
【１８０６】
プロセッサＪ１６１２２０は、第２レベルシグナリング情報及び第１レベルシグナリング情報を用いて、放送サービスを獲得し、放送サービスを表出するように制御する。
【１８０７】
ディスプレイ部Ｊ１６１２３０は放送サービス／コンテンツをディスプレイする。
【１８０８】
図１６２は本発明のさらに他の実施例による放送システムのプロトコルスタックを示す図である。
【１８０９】
前述したように、本発明による放送システムは二つ以上の伝送プロトコルを活用して放送データを伝送することができる。放送ネットワークを介したサービスデータ伝達において、ＭＭＴプロトコルによってＭＰＵにフォーマットされたサービスデータを伝送する方法及び／又はＤＡＳＨセグメントにフォーマットされたサービスデータをＲＯＵＴＥプロトコルによって伝送する方法があり得る。
【１８１０】
ＲＯＵＴＥ／ＭＭＴを介して伝達されるデータに対するサービスシグナリングデータもそれぞれＲＯＵＴＥ／ＭＭＴを介して伝達されることができる。サービスに対するＮＲＴコンポーネントはＭＭＴでないＲＯＵＴＥのみを介して伝達されることができる。ここで、実施例によって、ＮＲＴコンポーネントがＭＭＴのみを介して伝達されるようにすることもできる。これについては前述したようである。
【１８１１】
ＲＯＵＴＥ又はＭＭＴを介して処理されたサービスデータはＵＤＰ／ＩＰレイヤーを介してＩＰパケットに処理されることができる。ＩＰパケットはリンクレイヤーで（図示せず）リンクレイヤーパケットにカプセル化されることができる。リンクレイヤーパケットはフィジカルレイヤーで前述したフィジカルプロセッシング（エンコーディング、インターリービングなど）によって放送信号に処理されることができる。放送信号は放送ネットワークを介して伝送されることができる。
【１８１２】
ハイブリッドサービスである場合、サービスの少なくとも一つのサービスコンポーネントがブロードバンドを介して伝達されることができる。ブロードバンドを介してサービスデータが伝達される場合、サービスデータはＤＡＳＨセグメント形態に伝達されることができる。ブロードバンドを介した伝達のために、ＨＴＴＰ／ＴＣＰ／ＩＰプロトコルによってサービスデータが処理されることができる。処理されたデータはブロードバンドを介して伝達されることができる。
【１８１３】
サービスリスト生成のための情報などを含むＳＬＴも伝達されることができる。ＳＬＴは前述したようであり得る。ＳＬＴは各サービスのＳＬＳに近付くためのブートストラップ情報を含むことができる。ここで、ブートストラップ情報は放送サービスの速いスキャンと、サービス獲得のために必要な情報を提供する情報であり得る。
【１８１４】
ＳＬＴはＵＤＰ／ＩＰによって処理されてＩＰパケットの形態で伝達されることができる。この場合、ＳＬＴは特定のＩＰストリームを介して伝達され、リンクレイヤーパケットに処理されることができる。その後、ＳＬＴはＰＬＰの一つを介して伝達されることができる。すなわち、ＳＬＴは信号フレーム内で専用チャネルを介して伝達されず、ＰＬＰの一つを介して伝達されることができる。実施例によって、ＳＬＴはＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）を介して伝達されることができる。この場合、信号フレームはＦＩＣという専用チャネルを有することができる。このＦＩＣを介してＳＬＴが伝達されて、各サービスに対してＳＬＳを位置させることができる。
【１８１５】
前述したように、本発明による放送システムは二つ以上の伝送プロトコルを活用して放送データを伝送することができる。この場合、ＳＬＴは放送ネットワークを介して伝達されるサービスデータがどの伝送プロトコルによって伝送されるかを指示することができる。
【１８１６】
具体的に、ＳＬＴは各サービスに対するＳＬＳがどの伝送プロトコルを介して伝送されるかを指示することができる。実施例によって、ＳＬＴは各サービスのサービスデータ／サービスコンポーネントがどの伝送プロトコルを介して伝送されるかを指示することもできる。ＳＬＴは、これを指示するために、プロトコル情報を含むことができる。プロトコル情報はその値によって伝送プロトコルを指示することができる。例えば、プロトコル情報が０ｘ０１の値を有する場合、ＲＯＵＴＥプロトコルが使われることを指示することができる。プロトコル情報が０ｘ０２の値を有する場合、ＭＭＴプロトコルが使われることを指示することができる。プロトコル情報が０ｘ０３−０ｘＦＦの値を有する場合、将来の使用のためにプロトコルを残しておくことができる（ｒｅｓｅｒｖｅｄ）。
【１８１７】
このプロトコル情報はＳＬＴ上でいろいろの形態で位置することができる。実施例によって、ＳＬＴは各プロトコル別に該当のプロトコルによって伝達されるサービスのリストを提供することができる。実施例によって、ＳＬＴは各サービス別に該当のサービスがどのプロトコルによって伝達されるかを記述することもできる。詳細な実施例については後述する。
【１８１８】
実施例によって、ＳＬＴとＳＬＳでＰＬＰＩＤ情報は削除されることができる。この場合、前述したリンクレイヤーシグナリングであるＬＭＴが活用できる。すなわち、ＬＭＴは、それぞれのＰＬＰに対し、そのＰＬＰを介して伝達されるＩＰストリームを記述することができ、ＳＬＴのブートストラッピング情報はＩＰ／ＵＤＰ情報のみでＳＬＳを位置させることができる。この場合、受信システムは、ＬＭＴのＰＬＰ−ＩＰストリームマッピング情報と、ＳＬＴが指示するＩＰストリームを識別するための情報（ＩＰ／ＵＤＰ情報）を用いて、ＳＬＳがどのＰＬＰのどのＩＰストリームを介して伝送されるかが分かる。このような実施例で、ＳＬＳもＩＰストリームを識別する情報を持っていることができる。受信機がＳＬＳを活用するとき、ＰＬＰが識別される必要がある場合、受信機はＬＭＴの情報を活用することができる。
【１８１９】
図１６３は本発明のさらに他の実施例によるＳＬＴを示す図である。
【１８２０】
図示のＳＬＴは前述したＳＬＴ乃至ＦＩＣペイロードが拡張した形態を有することができる。前述したＳＬＴのフィールド、例えばＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ｐａｒｉｔｉｏｎ＿ｉｄ情報などは前述した実施例で記述されたようである。
【１８２１】
図示のＳＬＴは、各プロトコルに対し、該当のプロトコルを介して伝達されるサービスのリストを提供することができる。図示のＳＬＴはｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋフィールドをＳＬＴレベル（ＦＩＣレベル）に含むことができる。ｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋフィールドは該当のＳＬＴが記述するサービスを伝達するのに使われる伝送プロトコルの数を指示することができる。例えば、ＲＯＵＴＥプロトコルのみが使われる場合、このフィールドは１個の伝送プロトコルが使われることを指示することができる。あるサービスはＲＯＵＴＥプロトコルによって、他のサービスはＭＭＴプロトコルによって伝送される場合、このフィールドは２個の伝送プロトコルが使われることを指示することができる。
【１８２２】
図示のＳＬＴはｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋフィールドが指示する数によって、各プロトコルについての情報を含むｆｏｒ ｌｏｏｐを含むことができる。各プロトコルについての情報は、ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｔｙｐｅフィールド、ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールド、各ｓｅｒｖｃｉｃｅについての情報を含むｆｏｒ ｌｏｏｐ、ｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及び／又はｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）を含むことができる。
【１８２３】
ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｔｙｐｅフィールドは該当のプロトコルがどの伝送プロトコルであるかを指示することができる。例えば、このフィールドは該当の伝送プロトコルがＲＯＵＴＥプロトコルであるかあるいはＭＭＴプロトコルであるかを指示することができる。
【１８２４】
ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは該当のプロトコルによって伝達されるサービスの数を指示することができる。例えば、このフィールドはＲＯＵＴＥを介してＳＬＳが伝達されるサービスの数を指示することができる。その後、ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドが指示する値によって、各ｓｅｒｖｃｉｃｅについての情報を含むｆｏｒ ｌｏｏｐが位置することができる。
【１８２５】
各サービスについての情報は、該当のプロトコルによって伝達されるサービスについての詳細な情報であり得る。ＳＬＴは、該当のプロトコルによって伝達される各サービスに対し、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｐａｒｉｔｉｏｎ＿ｉｄ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報などを含むことができる。これについては前述したようである。
【１８２６】
該当のプロトコルによって伝達されるサービスについての情報は、該当のサービスのＳＬＳに対するブートストラップ情報を含む。ブートストラップ情報は、ＳＬＳ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ、ＳＬＳ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ、ＳＬＳ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ及び／又はＳＬＳ＿ＤＰ＿ＩＤを含むことができる。この情報は、それぞれＳＬＳが伝達される伝送セッションのソースＩＰアドレス、デスティネーションＩＰアドレス、及びデスティネーションＵＤＰポートナンバーを指示することができる。ＳＬＳ＿ＤＰ＿ＩＤはＳＬＳが伝達されるＰＬＰのＰＬＰ ＩＤを識別することができる。ＳＬＳ＿ＤＰ＿ＩＤは実施例によって省略されることができる。
【１８２７】
ブートストラップ情報のデスティネーションＩＰアドレスなどが指示するものは、該当のサービスが伝達される伝送プロトコルによって違うことができる。例えば、該当のサービス（又は該当のサービスのＳＬＳ）がＲＯＵＴＥプロトコルによって伝達される場合、ブートストラップ情報は該当のサービスのＳＬＳが伝達されるＲＯＵＴＥセッションを指示することができる。また、該当のサービスがＭＭＴプロトコルによって伝達される場合、ブートストラップ情報は該当のサービスのＳＬＳが伝達されるＭＭＴＰセッションを指示することができる。
【１８２８】
前述したように、特定のサービスのＳＬＳは、そのＳＬＳが伝達されるＲＯＵＴＥ／ＭＭＴＰセッションの専用チャネルを介して伝達されることができる。ＲＯＵＴＥセッションを介してＳＬＳが伝達される場合、ＳＬＳは該当のＲＯＵＴＥセッションのｔｓｉ＝０によって識別されるＬＣＴセッションを介して伝達されることができる。ＭＭＴＰセッションを介してＳＬＳが伝達される場合、ＳＬＳは該当のＭＭＴＰセッションのｐａｃｋｅｔ＿ｉｄ＝００に識別されるＭＭＴＰパケットフローを介して伝達されることができる。
【１８２９】
実施例によって、ＳＬＳは伝送セッションの専用チャネルでないチャネルを介して伝達されることもできる。この場合、ブートストラップ情報はＳＬＳがＲＯＵＴＥ／ＭＭＴＰセッションのどのチャネルを介して伝達されるかも指示する必要がある。このために、ＳＬＴはＳＬＳ＿ＴＳＩフィールドをさらに含むことができる。該当のサービスがＲＯＵＴＥによって伝達される場合、ＳＬＳ＿ＴＳＩフィールドはＳＬＳが伝達されるＲＯＵＴＥセッション内のＬＣＴチャネルを指示することができる。この場合、ＳＬＳ＿ＴＳＩフィールドはｔｓｉ値の形態を有することができる。該当のサービスがＭＭＴによって伝達される場合、ＳＬＳ＿ＴＳＩフィールドはＳＬＳが伝達されるＭＭＴＰセッション内のＭＭＴＰパケットフローを指示することができる。この場合、ＳＬＳ＿ＴＳＩフィールドはｐａｃｋｅｔ＿ｉｄ値の形態を有することができる。ＳＬＳ＿ＴＳＩフィールドは実施例によって省略可能である。
【１８３０】
すなわち、特定のサービスのＳＬＳのブートストラップ情報の意味は、前述したプロトコル情報（ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｔｙｐｅフィールド）によって違うことができる。ブートストラップ情報は特定のサービスが伝達されるのに使用された伝送プロトコルによってその意味が違うことができる。
【１８３１】
ＳＬＴは、プロトコルスタックレベルで、ｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及び／又はｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）を含むことができる。
【１８３２】
ｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはプロトコルスタックレベルで定義されるディスクリプタの数を指示することができる。このフィールドの値によってそれぞれのディスクリプタ（ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（））がＳＬＴに含まれることができる。このディスクリプタは該当のプロトコルに共通した情報を提供することができる。
【１８３３】
また、ＳＬＴは、ＳＬＴレベルでｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）を含むことができる。
【１８３４】
ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドはＳＬＴレベルで定義されるディスクリプタの数を指示することができる。このフィールドの値によってそれぞれのディスクリプタ（ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（））がＳＬＴに含まれることができる。このディスクリプタはＳＬＴで記述される全てのサービスに共通した情報を提供することができる。
【１８３５】
図１６４は本発明のさらに他の実施例によるＳＬＴを示す図である。
【１８３６】
この実施例によるＳＬＴも前述したＳＬＴ乃至ＦＩＣペイロードが拡張した形態を有することができる。前述したＳＬＴのフィールドは前述した実施例で記述されたようである。
【１８３７】
この実施例のＳＬＴは、それぞれのサービスに対し、該当のサービスが伝送されるのに使われる伝送プロトコル情報を提供することができる。具体的に、該当のサービスのＳＬＳが伝達されるのに使われる伝送プロトコルがＲＯＵＴＥであるか又はＭＭＴであるかを指示することができる。
【１８３８】
この実施例のＳＬＴはそれぞれのサービスに対してｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋフィールドを含むことができる。このフィールドは該当のサービスが伝達されるのに使われることができる伝送プロトコルの数を指示することができる。例えば、該当のサービスがＲＯＵＴＥを介して伝達されていれば、このフィールドは１の値を有し、該当のサービスがＲＯＵＴＥを介しても伝達され、ＭＭＴを介しても伝達されることができれば、このフィールドは２の値を有することができる。
【１８３９】
ｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋフィールドが指示する数のプロトコルについての情報が記述されることができる。各プロトコルについての情報は、該当のサービスのＳＬＳがＲＯＵＴＥを介して伝達されたとき、ＳＬＳを位置させる情報を含むことができる。また、各プロトコルについての情報は、該当のサービスのＳＬＳがＭＭＴを介して伝達されたとき、ＳＬＳを位置させる情報を含むことができる。
【１８４０】
ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｔｙｐｅフィールドは該当のサービスのＳＬＳが伝達される伝送プロトコルを指示することができる。前述したように、その値によってＲＯＵＴＥ又はＭＭＴプロトコルが指示されることができる。
【１８４１】
ＳＬＳ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ、ＳＬＳ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ、及びＳＬＳ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔは、該当のサービスのＳＬＳが伝達される伝送セッションのソースＩＰアドレス、デスティネーションＩＰアドレス、及びデスティネーションＵＤＰポートナンバーを指示することができる。ＳＬＳ＿ＤＰ＿ＩＤはＳＬＳが伝達されるＰＬＰのＰＬＰ ＩＤを識別することができる。ＳＬＳ＿ＤＰ＿ＩＤは実施例によって省略されることができる。
【１８４２】
前述した実施例と同様に、デスティネーションＩＰアドレスなどが指示するものは、該当のサービスが伝達される伝送プロトコルによって違うことができる。例えば、該当のサービス（又は該当のサービスのＳＬＳ）がＲＯＵＴＥプロトコルによって伝達される場合、ブートストラップ情報は該当のサービスのＳＬＳが伝達されるＲＯＵＴＥセッションを指示することができる。また、該当のサービスがＭＭＴプロトコルによって伝達される場合、ブートストラップ情報は該当のサービスのＳＬＳが伝達されるＭＭＴＰセッションを指示することができる。
【１８４３】
前述したように、該当のサービスのＳＬＳがＲＯＵＴＥ／ＭＭＴＰセッションの専用チャネルを介して伝達される場合、付加のｔｓｉ情報乃至ｐａｃｋｅｔ＿ｉｄ情報が不要であることができる。ただ、専用チャネルがない場合、ＳＬＳ＿ＴＳＩフィールドがもっと付け加えられることができる。ＳＬＳ＿ＴＳＩフィールドは、前述した実施例と同様に、ＳＬＳが伝達されるＬＣＴチャネル乃至ＭＭＴＰパケットフローを指示することができる。
【１８４４】
図示のＳＬＴはｎｕｍ＿ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒが指示する数のプロトコルスタックレベルディスクリプタ（ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（））を含むことができる。プロトコルスタックレベルディスクリプタは該当のプロトコルに共通した情報を含むことができる。
【１８４５】
図示のＳＬＴはｎｕｍ＿ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒが指示する数のサービスレベルディスクリプタ（ｓｅｒｖｉｃｅ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（））を含むことができる。サービスレベルディスクリプタは該当のサービスに共通した情報を含むことができる。
【１８４６】
図示のＳＬＴはｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒが指示する数のＳＬＴレベルディスクリプタ（ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（））を含むことができる。ＳＬＴレベルディスクリプタは前述したようである。
【１８４７】
実施例によって、一つのサービスが同時に二つ以上の伝送プロトコルを用いて伝達されることもできる。一つのサービスに含まれる複数のサービスコンポーネントの中で、あるサービスコンポーネントはＲＯＵＴＥプロトコルを介して伝達され、他のサービスコンポーネントはＭＭＴプロトコルを介して伝達されることができる。ここで、ＲＯＵＴＥプロトコルを介して伝達されるサービスコンポーネントはＮＲＴサービスコンポーネントであり得る。
【１８４８】
同時に二つ以上の伝送プロトコルを介して一つのサービスが伝達される場合、該当のサービスに対するＳＬＳはＭＭＴプロトコルによって伝達されることができる。すなわち、前述したブートストラップ情報（ＩＰ／ＵＤＰ情報など）はＭＭＴＰセッションを介して伝達されるＳＬＳを位置させることができる。この場合、ＭＭＴＰセッションを介して伝達されるＳＬＳはＭＭＴＰセッションを介して伝達されるサービスコンポーネントをアクセスするために必要な情報を有することができる。
【１８４９】
ここで、ＭＭＴＰセッションを介して伝達されるＳＬＳはＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントについての情報をさらに有することができる。ここで、ＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントについての情報は前述したａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔにあたることができる。前述したように、ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、Ｓ−ＴＳＩＤを獲得するためのＩＰ／ＵＤＰ情報、ＰＬＰ情報、ＵＲＩ情報などを含むことができる。したがって、受信機はＳ−ＴＳＩＤを獲得することができる。ここで、Ｓ−ＴＳＩＤはＲＯＵＴＥプロトコルによって伝達されるサービスコンポーネントに対する伝送セッションディスクリプション情報を提供することができる。Ｓ−ＴＳＩＤについては前述した。
【１８５０】
図１６５は本発明のさらに他の実施例によるＳＬＴを示す図である。
【１８５１】
図示の実施例のＳＬＴはＬＳＩＤについての情報をさらに含むように拡張された。このＬＳＩＤは前述したＬＳＩＤとは違うことができる。
【１８５２】
前述したＬＳＩＤはそれぞれのＲＯＵＴＥセッションに含まれることにより、該当のＲＯＵＴＥセッションに含まれるＬＣＴチャネルとそのチャネルを介して伝達されるサービスコンポーネントについて説明することができる。また、前述したＳ−ＴＳＩＤはサービスに基づくサービスを提供するシグナリング情報であって、特定のサービスに対するサービスコンポーネントを伝達する全てのＬＣＴチャネルについての情報を記述することができる。したがって、ＬＳＩＤはそれぞれのＲＯＵＴＥセッションについての情報なので、Ｓ−ＴＳＩＤと重複して使われないこともできる。実施例によって、ＬＳＩＤとＳ−ＴＳＩＤが一緒に使われることもできる。
【１８５３】
この実施例のＬＳＩＤはサービスに基づくシグナリング情報であって、ＳＬＴが記述する全てのサービスに対し、それぞれのサービスが有するサービスコンポーネントが伝達されるＲＯＵＴＥセッションとＬＣＴチャネルに対する伝送経路情報を含むことができる。Ｓ−ＴＳＩＤは、前述したように、一つのサービスに対し、そのサービスコンポーネントの伝送経路情報を含むことができる。すなわち、この実施例のＬＳＩＤは前述したＳ−ＴＳＩＤの集合と見なすことができる。この新形態のＬＳＩＤは各サービスのＳＬＳがＳ−ＴＳＩＤを提供する場合には活用されないこともできる。
【１８５４】
図示の実施例のＳＬＴは、前述した新形態のＬＳＩＤを獲得するための情報をもっと有することができる。図示のＳＬＴは、ＬＳＩＤ＿ｅｘｉｓｔ＿ｆｌａｇ、ＬＳＩＤ＿ＰＬＰ＿ＩＤ及び／又はＬＳＩＤ＿ｖｅｒｓｉｏｎフィールドをさらに含むことができる。他のフィールドは前述したようである。
【１８５５】
ＬＳＩＤ＿ｅｘｉｓｔ＿ｆｌａｇフィールドはＬＳＩＤが該当のブロードキャストストリームに存在するかを指示するフラグであり得る。このフィールドはｔｒｕｅ又はｆａｌｓｅの値を有することができる。このフィールドの値がｔｒｕｅである場合、ＳＬＴはＬＳＩＤ＿ＰＬＰ＿ＩＤフィールド及び／又はＬＳＩＤ＿ｖｅｒｓｉｏｎフィールドをさらに含むことができる。
【１８５６】
ＬＳＩＤ＿ＰＬＰ＿ＩＤフィールドはＬＳＩＤが伝達されるＰＬＰの識別子を示すことができる。ＬＳＩＤが伝送セッションを介して伝達される場合、その伝送セッションを識別するためのＩＰ／ＵＤＰ情報がさらに付け加えられることができる。ＬＳＩＤが信号フレームの専有チャネルを介して伝達される場合、このフィールドは省略されることができる。
【１８５７】
ＬＳＩＤ＿ｖｅｒｓｉｏｎフィールドは伝達されるＬＳＩＤのバージョン情報を示すことができる。ＬＳＩＤの情報が変更された場合、新たなバージョンナンバーを有することができる。
【１８５８】
図１６６は本発明のさらに他の実施例によるＬＳＩＤを示す図である。
【１８５９】
図示のＬＳＩＤは前述した新形態のＬＳＩＤであり得る。このＬＳＩＤは前述したＳ−ＴＳＩＤと構造が類似することができる。ただ、この実施例のＬＳＩＤは複数のサービスに対する伝送セッションディスクリプション情報を含むから、それぞれのサービスに対するサービスエレメントが付け加えられることができる。
【１８６０】
図示のＬＳＩＤは＠ｂｓｉｄ及び／又はＳｅｒｖｉｃｅエレメントを含むことができる。＠ｂｓｉｄフィールドは該当のＬＳＩＤが記述するサービスが伝達されるブロードキャストストリームを識別する情報を含むことができる。Ｓｅｒｖｉｃｅエレメントはそれぞれのサービスに対する伝送経路ディスクリプションを含むエレメントであり得る。
【１８６１】
それぞれのＳｅｒｖｉｃｅエレメントは、＠ｓｖｃＩＤ、＠ｖｅｒｓｉｏｎ、＠ｖａｌｉｄＦｒｏｍ、＠ｅｘｐｉｒｅｓ及び／又は複数のＲＳエレメントを含むことができる。
【１８６２】
＠ｓｖｃＩＤは該当のサービスのサービスＩＤを示すことができる。＠ｖｅｒｓｉｏｎ、＠ｖａｌｉｄＦｒｏｍ、及び＠ｅｘｐｉｒｅｓ情報はそれぞれ前述した伝送セッションインスタンスディスクリプション（前述したＬＳＩＤ）の＠ｖｅｒｓｉｏｎ、＠ｖａｌｉｄＦｒｏｍ、及び＠ｅｘｐｉｒｅｓフィールドに対応することができる。
【１８６３】
ＲＳエレメントは該当のサービスのサービスコンポーネントを伝送するＲＯＵＴＥセッションについての情報を有するエレメントであり得る。前述したＳ−ＴＳＩＤのＲＳエレメントに対することができる。
【１８６４】
＠ｂｓｉｄは該当のサービスを伝送するブロードキャストストリーム識別子を示すことができる。このフィールドは省略されることができる。省略される場合、このフィールドは前述した＠ｂｓｉｄと同一の値を有することを意味することができる。
【１８６５】
＠ｓＩｐＡｄｄｒ、＠ｄＩｐＡｄｄｒ、及び＠ｄｐｏｒｔフィールドは該当のＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス、及びデスティネーションＵＤＰポートナンバーを示すことができる。
【１８６６】
＠ｐｌｐＩＤは該当のＲＯＵＴＥセッションが伝達されるＰＬＰの識別子を示すことができる。このフィールドは省略されることができる。省略される場合、このフィールドはＳＬＴに含まれる＠ＬＳＩＤ＿ＰＬＰ＿ＩＤと同一の値を有することを意味することができる。
【１８６７】
ＲＳエレメントは複数のＬＳエレメントを含むことができる。それぞれのＬＳエレメントは該当のサービスのサービスコンポーネントを伝達するＬＣＴチャネルについての情報を含むことができる。
【１８６８】
ＬＳエレメントは、＠ｔｓｉ、＠ＰＬＰＩＤ、＠ｂｗ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅ、ｓｒｃＦｌｏｗ及び／又はＲｐｒＦｌｏｗエレメントを含むことができる。
【１８６９】
＠ｔｓｉは該当のＬＣＴチャネルセッション識別子を示すことができる。この情報を用いて、該当のサービスのサービスコンポーネントが収集されることができる。
【１８７０】
＠ＰＬＰＩＤは該当のＬＣＴチャネルが伝達されるＰＬＰの識別子を示すことができる。この値は省略されることができる。省略される場合、ＲＳエレメント下位の＠ＰＬＰＩＤと同一の値を有することを意味することができる。
【１８７１】
＠ｂｗは該当のＬＣＴチャネルの最大帯域幅（ｂａｎｄｗｉｄｔｈ）値を指示することができる。
【１８７２】
＠ｓｔａｒｔＴｉｍｅは該当のＬＣＴチャネルスタートタイム（Ｓｔａｒｔ ｔｉｍｅ）を指示することができる。
【１８７３】
＠ｅｎｄＴｉｍｅは該当のＬＣＴチャネルエンドタイム（Ｅｎｄ ｔｉｍｅ）を指示することができる。
【１８７４】
ＳｒｃＦｌｏｗエレメントはＲＯＵＴＥのソースフローに対して記述することができる。ＲｐｒＦｌｏｗエレメントはＲＯＵＴＥのリペアーフローに対して記述することができる。ｓｒｃＦｌｏｗ及びＲｐｒＦｌｏｗエレメントに対しては後述する。
【１８７５】
前述したように、この実施例によるＬＳＩＤは、複数のサービスに対し、各サービスに含まれるサービスコンポーネントの伝送セッションディスクリプション情報を提供することができる。したがって、この実施例のＬＳＩＤは前述したＳ−ＴＳＩＤと構造が類似することができる。
【１８７６】
図１６７は本発明のさらに他の実施例によるソースフロー／リペアーフローに対するディスクリプションを示す図である。
【１８７７】
図示のソースフローエレメントは、＠ｎｒｔ、＠ｍｉｎＢｕｆｆＳｉｚｅ、＠ａｐｐＩＤ、ＥＦＤＴ、Ｐａｙｌｏａｄ及び／又はＦＥＣＰａｒａｍｓを含むことができる。実施例によって、フィールドが追加／変更／削除されることができる。
【１８７８】
＠ｎｒｔは前述したソースフローエレメントの＠ｒｅａｌｔｉｍｅ属性と同一であることができる。＠ｍｉｎＢｕｆｆＳｉｚｅは前述したソースフローエレメントの＠ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性と同一であることができる。＠ａｐｐＩＤは前述したソースフローエレメントのＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒエレメントと同一であることができる。
【１８７９】
ＥＦＤＴエレメントは前述した放送システムのＥＦＤＴの実施例にあたることができる。ＥＦＤＴは、＠ｉｄｒｅｆ、＠ｖｅｒｓｉｏｎ、＠ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ、＠ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ、＠ｆｉｌｅＴｅｍｐｌａｔｅ及び／又はＦＤＴＰａｒａｍｅｔｅｒｓを含むことができる。
【１８８０】
＠ｉｄｒｅｆ、＠ｖｅｒｓｉｏｎ、＠ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ、＠ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ、及び＠ｆｉｌｅＴｅｍｐｌａｔｅは前述したＥＦＤＴエレメントの同名の属性乃至エレメントと同一であることができる。
【１８８１】
ＦＤＴＰａｒａｍｅｔｅｒｓはＥＦＤＴボディーのファイルＵＲＬ又はファイルテンプレートに対するパラメータを含むことができる。このエレメントはＦＬＵＴＥ ＦＤＴで定義されたどのパラメータでも含むことができる。
【１８８２】
Ｐａｙｌｏａｄエレメントは前述したソースフローエレメントのＰａｙｌｏａｄＦｏｒｍａｔエレメントと同一であることができる。Ｐａｙｌｏａｄエレメントは、＠Ｃｏｄｅｐｏｉｎｔ、＠ｆｏｒｍａｔＩＤ、＠ｆｒａｇ、＠ｏｒｄｅｒ及び／又は＠ｓｒｃＦｅｃＰａｙｌｏａｄＩＤ属性をさらに含むことができる。
【１８８３】
＠Ｃｏｄｅｐｏｉｎｔは前述したソースフローエレメントの＠Ｃｏｄｅｐｏｉｎｔ属性と同一であることができる。＠ｆｏｒｍａｔＩＤは前述したソースフローエレメントの＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性と同一であることができる。＠ｆｒａｇは前述したソースフローエレメントの＠ｆｒａｇｍｅｎｔａｔｉｏｎ属性と同一であることができる。＠ｏｒｄｅｒは前述したソースフローエレメントの＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性と同一であることができる。＠ｓｒｃＦｅｃＰａｙｌｏａｄＩＤは前述したソースフローエレメントの＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性と同一であることができる。
【１８８４】
ＦＥＣＰａｒａｍｓは前述したソースフローエレメントのＦＥＣＰａｒａｍｅｔｅｒエレメントと同一であることができる。
【１８８５】
ＲｐｒＦｌｏｗエレメントはリペアーフローについての情報を含むことができる。リペアーフローは少なくとも一つ以上のソースフローのデリバリーオブジェクトに対する保護（ｐｒｏｔｅｃｔｉｏｎ）を提供することができる。リペアーフローはＦＥＣに対するパラメータ情報、保護の対象となるデリバリーオブジェクトについての情報（ＰｒｏｔｅｃｔｅｄＯｂｊｅｃｔ）などを含むことができる。
【１８８６】
図示のソースフロー／リペアーフローエレメント及び前述した実施例によるソースフロー／リペアーフローエレメントはＳ−ＴＳＩＤのソースフロー／リペアーフローエレメントにも適用できる。
【１８８７】
図１６８は本発明のさらに他の実施例による、シグナリングフローダイアグラムを示す図である。
【１８８８】
この実施例はＰＬＰが伝送セッションを伝達することを示す。ここで、ＰＬＳはフィジカルレイヤーシグナリングであり、ＰＬＳについては前述した。この実施例でＦＩＣが活用されることを仮定したが、前述したように、ＦＩＣは使われないこともでき、ＳＬＴはＰＬＰの特定のＩＰストリームを介して伝達されることができる。特定のＩＰストリームを介して伝達されるＳＬＴ情報が先に獲得できる。
【１８８９】
ここで、ＳＬＴは前述したＬＳＩＤについての情報を有するＳＬＴであり得る。ＳＬＴのＬＳＩＤ＿ｆｌａｇ情報を用いて該当のブロードキャストストリームに存在するかが確認されることができる。また、ＳＬＴのＬＳＩＤ＿ＰＬＰ＿ＩＤ情報を用いて、ＬＳＩＤが伝達されるＰＬＰが識別されることができる。
【１８９０】
受信機がＬＳＩＤを獲得すれば、各サービスに対する伝送セッションディスクリプション情報を獲得することができる。この情報を用いて、それぞれのサービスがどのＲＯＵＴＥセッションのどのＬＣＴチャネルを介して伝達されるかが分かる。
【１８９１】
これとは別個に、ＳＬＴ内のブートストラップ情報を活用して、特定のサービスに対するＳＬＳが伝達される経路が位置されることができる。この実施例でＳＬＳが伝達されるＬＣＴチャネルはＴＳＩ ＳＬＳ１及びＴＳＩ ＳＬＳ３などとして表示された。ここで、ＳＬＳはＳＭＴとＭＰＤなどを含む。実施例によって、ＳＬＳはＵＳＢＤ、ＭＰＤなどを含むことができ、ＳＭＴは活用されないこともできる。
【１８９２】
図示の形態のＬＳＩＤが使われる場合、Ｓ−ＴＳＩＤは使われないこともできる。この場合、ＬＣＴチャネルのＳＬＳにはＳ−ＴＳＩＤが含まれないこともできる。実施例によって、ＬＣＴチャネルのＳＬＳはＳ−ＴＳＩＤを含むことにより、該当のサービスに対する伝送セッションディスクリプション情報を提供することができる。この場合、図示の形態のＬＳＩＤは使われないこともできる。実施例によって、図示の形態のＬＳＩＤ及びＳ−ＴＳＩＤが同時に使われることもできる。この場合、二つのシグナリング情報は重複した情報を有することができる。
【１８９３】
図１６９は本発明の一実施例による放送信号を伝送する方法を示す図である。
【１８９４】
本発明の一実施例による放送信号を伝送する方法は、サービスデータ及びサービスシグナリング情報を生成する段階、サービスリストテーブルを生成する段階、サービスコンポーネント、サービスシグナリング情報及びサービスリストテーブルを伝送パケットに処理する段階、リンクレイヤーパケットを生成する段階及び／又はリンクレイヤーパケットをフィジカルレイヤープロセッシングして放送信号を生成して伝送する段階を含むことができる。
【１８９５】
まず、送信側の第１モジュールは放送サービスのサービスデータ及びサービスデータをシグナリングするサービスシグナリング情報を生成することができる。ここで、サービスデータはＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）プロトコルによって伝達される第１サービスコンポーネント及びＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）プロトコルによって伝達される第２サービスコンポーネントを含むことができる。前述したように、ＲＯＵＴＥによってＮＲＴサービスコンポーネントが伝達されると仮定すれば、一つのサービスのサービスコンポーネントは複数の伝送プロトコルを用いて伝達されることができる。もちろん、放送サービスはその外にもブロードバンドを介して伝達されるサービスコンポーネントなどもさらに含むことができる。ここで、サービスシグナリング情報はＳＬＳを意味することができる。
【１８９６】
送信側の第２モジュールはサービスリストテーブルを生成することができる。サービスリストテーブルは前述したＳＬＴにあたることができる。ＳＬＴはＳＬＳが伝達される伝送セッションを識別するブートストラップ情報を含むことができる。ここで、伝送セッションはＲＯＵＴＥセッション又はＭＭＴＰセッションであり得る。ブートストラップ情報は、ＲＯＵＴＥセッション又はＭＭＴＰセッションのＩＰアドレス、ＵＤＰポートナンバーなどを意味することができる。第１モジュール及び第２モジュールはサービスプロバイダーに対応し、サービスを生成することを管理するモジュールであり得る。
【１８９７】
送信側の第３モジュールは、サービスコンポーネント、サービスシグナリング情報及び／又はサービスリストテーブルを伝送パケットに処理することができる。この段階は、放送ネットワークを介してサービスデータを伝送するために、サービスコンポーネントデータ、ＳＬＳ、及びＳＬＴをＵＤＰ／ＩＰによって処理してＩＰパケットにカプセル化する段階であり得る。ここで、伝送パケットはＩＰパケットであり得る。ここで、ＦＩＣは使われなく、ＳＬＴがＩＰパケットにカプセル化されてＰＬＰに伝達される場合を仮定した。第３モジュールはＵＤＰ／ＩＰレイヤーを管理するハードウェアモジュールであり得る。
【１８９８】
送信側の第４モジュールは伝送パケットをリンクレイヤープロセッシングして少なくとも一つのリンクレイヤーパケットを出力することができる。ここで、伝送パケットはＩＰパケットであり得る。リンクレイヤープロセッシングについては前述した。ここで、第４モジュールはリンクレイヤーにあたる動作を行うモジュールであり得る。第４モジュールはヘッダーコンプレション／オーバーヘッドリダクション乃至パケットカプセル化を遂行することができる。
【１８９９】
送信側の第５モジュールは少なくとも一つのリンクレイヤーパケットをフィジカルレイヤープロセッシングすることができる。第５モジュールはフィジカルレイヤーの動作を管理するモジュールであり得る。第５モジュールは、リンクレイヤーパケットをＢＢパケットに作り、これにエンコーディング、ビットインターリービング、星座マッピングなどの過程を遂行することができる。その後、第５モジュールは、タイムインターリービング、フレームビルディング、周波数インターリービングなどの段階を経て、ＯＦＤＭ方式によるモジュレーション過程を経ることができる。また、第５モジュールは、フィジカルレイヤープロセッシングされたデータを含む放送信号を伝送することができる。ここで、第４モジュールは第５モジュールに含まれることができる。第４及び５モジュールは一つの統合モジュールに取り替えられることができる。第５モジュールは複数の内部ブロックを含むことができる。第４モジュールは第５モジュールのブロックの一つに含まれることもできる。
【１９００】
本発明の他の実施例による放送信号を伝送する方法において、サービスリストテーブルは放送サービスに対するプロトコル情報をさらに含み、プロトコル情報は放送サービスのサービスシグナリング情報が伝達されるのに使われる伝送プロトコルを指示することができる。プロトコル情報は前述した＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅ乃至ｐｒｏｔｏｃｏｌ＿ｓｔａｃｋ＿ｔｙｐｅであり得る。
【１９０１】
本発明のさらに他の実施例による放送信号を伝送する方法において、ブートストラップ情報はサービスシグナリング情報が伝達される伝送セッションのＩＰ／ＵＤＰ情報を含むことができる。ＩＰ／ＵＤＰ情報は、プロトコル情報によってサービスシグナリング情報が伝達されるＭＭＴＰセッション又はＲＯＵＴＥセッションを識別することができる。ＩＰ／ＵＤＰ情報は、ＳＬＳが伝達される伝送セッションのソースＩＰアドレス、デスティネーションＩＰアドレス、及びデスティネーションＵＤＰポートナンバーを意味することができる。前述したように、プロトコル情報が示すように、デスティネーションＩＰアドレスなどが示す意味が変わることができる。ＩＰ／ＵＤＰ情報が指示する伝送セッションはＳＬＳを伝達するＲＯＵＴＥセッションあるいはＳＬＳを伝達するＭＭＴＰセッションであり得る。ＳＬＳがＭＭＴＰセッションを介して伝達される場合、ストリーミングデータはＭＭＴプロトコルによって伝達されることができる。この際、ＮＲＴデータがＲＯＵＴＥプロトコルを介してさらに伝達されることもできる。
【１９０２】
本発明のさらに他の実施例による放送信号を伝送する方法において、サービスシグナリング情報はＭＭＴプロトコルによって伝達されることができる。ここで、サービスシグナリング情報は、放送サービスの第１サービスコンポーネントが伝達されるＭＭＴＰセッションに対する伝送セッションディスクリプション情報を含むことができる。ＭＭＴＰセッションを介してＳＬＳが伝達される場合が仮定された。ＭＭＴＰセッションを介して伝達されるＳＬＳにはＵＳＢＤ及び／又はＭＭＴシグナリングメッセージが含まれることができる。ＭＭＴシグナリングメッセージ、特にＭＰＴメッセージは、ＭＭＴＰセッションを介して伝達されるサービスコンポーネントに近付くために必要な情報が含まれることができる。ＭＰＴメッセージはＲＯＵＴＥのＳ−ＴＳＩＤの役目をすることができる。ＭＭＴＰセッションを介して伝達されるサービスコンポーネントは、前述したように、第１サービスコンポーネントと呼ぶことができる。
【１９０３】
本発明のさらに他の実施例による放送信号を伝送する方法において、サービスシグナリング情報はＳ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）が伝達されるＭＭＴＰセッションを識別する情報をさらに含むことができる。前述したように、ＭＭＴＰセッションを介して伝達されるＳＬＳはＵＳＢＤを含むことができる。ＵＳＢＤは、ｒｏｕｔｅＣｏｍｐｏｎｅｎｔなどのエレメントを介してＳ−ＴＳＩＤを獲得するための情報を含むことができる。Ｓ−ＴＳＩＤは、放送サービスの第２サービスコンポーネントが伝達されるＲＯＵＴＥセッションに対する伝送セッションディスクリプション情報を含むことができる。Ｓ−ＴＳＩＤは、ＲＯＵＴＥセッションを介して伝達されるサービスコンポーネント（第２サービスコンポーネント）を獲得するための情報（ｔｓｉなど）を含むことができる。ここで、Ｓ−ＴＳＩＤそのものはＭＭＴＰセッションの一つを介して伝達されることができる。
【１９０４】
本発明のさらに他の実施例による放送信号を伝送する方法において、Ｓ−ＴＳＩＤは複数のＲＯＵＴＥセッションエレメントを含むことができる。ＲＯＵＴＥセッションエレメントは前述したＲＳエレメントを意味することができる。それぞれのＲＯＵＴＥセッションエレメントは該当のＲＯＵＴＥセッションを識別するＩＰ／ＵＤＰ情報及び複数のＬＣＴチャネルエレメントを含むことができる。ＩＰ／ＵＤＰ情報は、該当のＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス、及びデスティネーションＵＤＰポートナンバーを意味することができる。ＬＣＴチャネルエレメントは前述したＬＳエレメントを意味することができる。それぞれのＬＣＴチャネルエレメントは放送サービスの第２サービスコンポーネントが伝達されるＬＣＴチャネル伝送チャネル識別子情報を含むことができる。伝送チャネル識別子情報は前述したｔｓｉ情報を意味することができる。
【１９０５】
本発明のさらに他の実施例による放送信号を伝送する方法において、第２サービスコンポーネントは放送サービスに含まれるＮＲＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ）サービスコンポーネントであり得る。前述したように、一つの放送サービスがＲＯＵＴＥ及びＭＭＴプロトコルを同時に用いて放送ネットワークを介して伝達される場合、ＲＯＵＴＥプロトコルによってＮＲＴサービスコンポーネントが伝達され、ＭＭＴプロトコルによってストリーミングサービスコンポーネントが伝達されることができる。
【１９０６】
本発明の一実施例による放送信号を受信する方法を説明する。この方法は図面に示されていない。
【１９０７】
本発明の一実施例による放送信号を受信する方法は、受信側の第１モジュールが放送信号を受信する段階、受信側の第２モジュールが放送信号をフィジカルレイヤープロセッシングしてリンクレイヤーパケットを出力する段階、受信側の第３モジュールがリンクレイヤーパケットをリンクプロセッシングして伝送パケットを出力する段階、受信側の第４モジュールがＳＬＴを獲得してＳＬＳに近付く段階及び／又は受信側の第５モジュールがＳＬＳを用いて放送ネットワークに伝達されるサービスデータを獲得する段階を含むことができる。ここで、フィジカルレイヤープロセッシング、リンクプロセッシングなどは送信側のそれらの逆過程であり得る。ここで、ＳＬＳはＭＭＴＰセッションを介して伝達されることができる。ＳＬＳはＭＭＴＰセッションを介して伝達されるサービスコンポーネントを獲得するための情報を有することができる。また、ＳＬＳはＳ−ＴＳＩＤを得るために必要な情報を有することができる。Ｓ−ＴＳＩＤを用いて、ＲＯＵＴＥによって伝達されるＮＲＴサービスコンポーネントも獲得できる。
【１９０８】
本発明の実施例による放送信号を受信する方法は、前述した本発明の実施例による放送信号を伝送する方法に対応することができる。放送信号を受信する方法は、放送信号を伝送する方法で使われるモジュール（例えば、送信側の第１、２、３、４及び５モジュールなど）に対応するハードウェアモジュールによって遂行されることができる。放送信号を受信する方法は、前述した放送信号を伝送する方法の実施例に対応する実施例を有することができる。
【１９０９】
前述した段階は、実施例によって省略されるか、類似／同一の動作を行う他の段階に取り替えられることができる。
【１９１０】
図１７０は本発明の一実施例による放送信号を伝送する装置を示す図である。
【１９１１】
本発明の一実施例による放送信号を伝送する装置は、前述した送信側の第１、２、３、４、及び／又は５モジュールを含むことができる。それぞれのブロック、モジュールは前述したようである。
【１９１２】
本発明の一実施例による放送信号を伝送する装置及びその内部のモジュール／ブロックは、前述した本発明の放送信号を伝送する方法の実施例を遂行することができる。
【１９１３】
本発明の一実施例による放送信号を受信する装置を説明する。この装置は図面に示されていない。
【１９１４】
本発明の一実施例による放送信号を受信する装置は、前述した受信側の第１、２、３、４、及び／又は５モジュールを含むことができる。それぞれのブロック及びモジュールは前述したようである。
【１９１５】
本発明の一実施例による放送信号を受信する装置及びその内部のモジュール／ブロックは、前述した本発明の放送信号を受信する方法の実施例を遂行することができる。
【１９１６】
前述した装置内部のブロック／モジュールなどはメモリに記憶された連続した遂行過程を実行するプロセッサであってもよく、実施例によって装置の内／外部に位置するハードウェアエレメントであり得る。
【１９１７】
前述したモジュールは実施例によって省略されるか、類似／同一の動作を遂行する他のモジュールに取り替えられることができる。
【１９１８】
モジュール又はユニットはメモリ（又は格納ユニット）に記憶された連続した遂行過程を実行するプロセッサであり得る。前述した実施例に記述された各段階はハードウェア／プロセッサによって遂行されることができる。前述した実施例に記述されたそれぞれのモジュール／ブロック／ユニットはハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実行されることができる。このコードはプロセッサが読める記録存媒体に使われることができ、よって装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサによって読み取られることができる。
【１９１９】
説明の便宜のために、各図を分けて説明したが、各図に開示された実施例を併合して新たな実施例を具現するように設計することも可能である。そして、通常の技術者の必要によって、以前に説明した実施例を実行するためのプログラムが記録されているコンピュータで読める記録媒体を設計することも本発明の権利範囲に属する。
【１９２０】
本発明による装置及び方法は前述したような実施例の構成及び方法に限定して適用されることができるものではなく、前述した実施例を多様に変形することができるように、各実施例の全部又は一部が選択的に組合せられて構成されることもできる。
【１９２１】
一方、本発明が提案する方法をネットワークデバイスに備えられた、プロセッサが読める記録媒体に、プロセッサが読めるコードとして具現することが可能である。プロセッサが読める記録媒体はプロセッサによって読められるデータが記憶される全ての種類の記録装置を含む。プロセッサが読める記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、その上、インターネットを介した伝送などのキャリアウェーブの形態に具現されるものも含む。また、プロセッサが読める記録媒体はネットワークを介して連結されたコンピュータシステムに分散され、分散方式でプロセッサが読めるコードが記憶されて実行されることができる。
【１９２２】
また、以上では本発明の好適な実施例について例示の目的で説明したが、本発明は前述した特定の実施例に限定されなく、請求範囲で請求する本発明の要旨を逸脱しない範疇内で本発明が属する技術分野で通常の知識を有する者によって多様な変形実施が可能なであるのはもちろんのこと、このような変形実施は本発明の技術的思想や見込みから個別的に理解されてはいけないであろう。
【１９２３】
そして、この明細書では物の発明と方法の発明が一緒に説明されており、必要によって両発明の説明は補充的に適用されることができる。
【１９２４】
本発明の思想や範囲を逸脱しない範疇内で本発明の多様な変更及び変形が可能であるのは当業者に理解可能である。したがって、本発明は添付の請求項及びその同等な範囲内で提供される本発明の変更及び変形を全て含むものとして理解しなければならない。
【１９２５】
この明細書で装置及び方法の発明が一緒に言及され、装置及び方法の発明の説明は互いに補って適用されることができる。
【１９２６】
多様な実施例が本発明を実施するための最善の形態で説明された。
【産業上の利用可能性】
【１９２７】
本発明は一連の放送信号提供分野に利用される。
【１９２８】
本発明の思想や範囲を逸脱しない範疇内で本発明の多様な変更及び変形が可能であるのは当業者に明らかである。したがって、本発明は添付の請求項及びその同等な範囲内で提供される本発明の変更及び変形を全て含むものとして理解しなければならない。
【図１】
0006259114.tif 000044
【図２】
0006259114.tif 000045
【図３】
0006259114.tif 000046
【図４】
0006259114.tif 000047
【図５】
0006259114.tif 000048
【図６】
0006259114.tif 000049
【図７】
0006259114.tif 000050
【図８】
0006259114.tif 000051
【図９】
0006259114.tif 000052
【図１０】
0006259114.tif 000053
【図１１】
0006259114.tif 000054
【図１２】
0006259114.tif 000055
【図１３】
0006259114.tif 000056
【図１４】
0006259114.tif 000057
【図１５】
0006259114.tif 000058
【図１６】
0006259114.tif 000059
【図１７】
0006259114.tif 000060
【図１８】
0006259114.tif 000061
【図１９】
0006259114.tif 000062
【図２０】
0006259114.tif 000063
【図２１】
0006259114.tif 000064
【図２２】
0006259114.tif 000065
【図２３】
0006259114.tif 000066
【図２４】
0006259114.tif 000067
【図２５】
0006259114.tif 000068
【図２６】
0006259114.tif 000069
【図２７】
0006259114.tif 000070
【図２８】
0006259114.tif 000071
【図２９】
0006259114.tif 000072
【図３０】
0006259114.tif 000073
【図３１】
0006259114.tif 000074
【図３２（ａ）】
0006259114.tif 000075
【図３２（ｂ）】
0006259114.tif 000076
【図３２（ｃ）】
0006259114.tif 000077
【図３３】
0006259114.tif 000078
【図３４】
0006259114.tif 000079
【図３５】
0006259114.tif 000080
【図３６】
0006259114.tif 000081
【図３７】
0006259114.tif 000082
【図３８】
0006259114.tif 000083
【図３９】
0006259114.tif 000084
【図４０】
0006259114.tif 000085
【図４１】
0006259114.tif 000086
【図４２】
0006259114.tif 000087
【図４３】
0006259114.tif 000088
【図４４】
0006259114.tif 000089
【図４５】
0006259114.tif 000090
【図４６】
0006259114.tif 000091
【図４７】
0006259114.tif 000092
【図４８】
0006259114.tif 000093
【図４９】
0006259114.tif 000094
【図５０】
0006259114.tif 000095
【図５１】
0006259114.tif 000096
【図５２】
0006259114.tif 000097
【図５３】
0006259114.tif 000098
【図５４】
0006259114.tif 000099
【図５５】
0006259114.tif 000100
【図５６】
0006259114.tif 000101
【図５７】
0006259114.tif 000102
【図５８】
0006259114.tif 000103
【図５９】
0006259114.tif 000104
【図６０】
0006259114.tif 000105
【図６１】
0006259114.tif 000106
【図６２】
0006259114.tif 000107
【図６３】
0006259114.tif 000108
【図６４】
0006259114.tif 000109
【図６５】
0006259114.tif 000110
【図６６】
0006259114.tif 000111
【図６７】
0006259114.tif 000112
【図６８】
0006259114.tif 000113
【図６９】
0006259114.tif 000114
【図７０】
0006259114.tif 000115
【図７１】
0006259114.tif 000116
【図７２】
0006259114.tif 000117
【図７３】
0006259114.tif 000118
【図７４】
0006259114.tif 000119
【図７５】
0006259114.tif 000120
【図７６】
0006259114.tif 000121
【図７７】
0006259114.tif 000122
【図７８】
0006259114.tif 000123
【図７９】
0006259114.tif 000124
【図８０】
0006259114.tif 000125
【図８１】
0006259114.tif 000126
【図８２】
0006259114.tif 000127
【図８３】
0006259114.tif 000128
【図８４】
0006259114.tif 000129
【図８５】
0006259114.tif 000130
【図８６】
0006259114.tif 000131
【図８７】
0006259114.tif 000132
【図８８】
0006259114.tif 000133
【図８９】
0006259114.tif 000134
【図９０】
0006259114.tif 000135
【図９１】
0006259114.tif 000136
【図９２】
0006259114.tif 000137
【図９３】
0006259114.tif 000138
【図９４】
0006259114.tif 000139
【図９５】
0006259114.tif 000140
【図９６】
0006259114.tif 000141
【図９７】
0006259114.tif 000142
【図９８】
0006259114.tif 000143
【図９９】
0006259114.tif 000144
【図１００】
0006259114.tif 000145
【図１０１】
0006259114.tif 000146
【図１０２】
0006259114.tif 000147
【図１０３】
0006259114.tif 000148
【図１０４】
0006259114.tif 000149
【図１０５】
0006259114.tif 000150
【図１０６】
0006259114.tif 000151
【図１０７】
0006259114.tif 000152
【図１０８】
0006259114.tif 000153
【図１０９】
0006259114.tif 000154
【図１１０】
0006259114.tif 000155
【図１１１】
0006259114.tif 000156
【図１１２】
0006259114.tif 000157
【図１１３】
0006259114.tif 000158
【図１１４】
0006259114.tif 000159
【図１１５】
0006259114.tif 000160
【図１１６】
0006259114.tif 000161
【図１１７】
0006259114.tif 000162
【図１１８】
0006259114.tif 000163
【図１１９】
0006259114.tif 000164
【図１２０】
0006259114.tif 000165
【図１２１】
0006259114.tif 000166
【図１２２】
0006259114.tif 000167
【図１２３】
0006259114.tif 000168
【図１２４】
0006259114.tif 000169
【図１２５】
0006259114.tif 000170
【図１２６】
0006259114.tif 000171
【図１２７】
0006259114.tif 000172
【図１２８】
0006259114.tif 000173
【図１２９】
0006259114.tif 000174
【図１３０】
0006259114.tif 000175
【図１３１】
0006259114.tif 000176
【図１３２】
0006259114.tif 000177
【図１３３】
0006259114.tif 000178
【図１３４】
0006259114.tif 000179
【図１３５】
0006259114.tif 000180
【図１３６】
0006259114.tif 000181
【図１３７】
0006259114.tif 000182
【図１３８】
0006259114.tif 000183
【図１３９】
0006259114.tif 000184
【図１４０】
0006259114.tif 000185
【図１４１】
0006259114.tif 000186
【図１４２】
0006259114.tif 000187
【図１４３】
0006259114.tif 000188
【図１４４】
0006259114.tif 000189
【図１４５】
0006259114.tif 000190
【図１４６】
0006259114.tif 000191
【図１４７（ａ）】
0006259114.tif 000192
【図１４７（ｂ）】
0006259114.tif 000193
【図１４８】
0006259114.tif 000194
【図１４９】
0006259114.tif 000195
【図１５０】
0006259114.tif 000196
【図１５１】
0006259114.tif 000197
【図１５２】
0006259114.tif 000198
【図１５３】
0006259114.tif 000199
【図１５４（ａ）】
0006259114.tif 000200
【図１５４（ｂ）】
0006259114.tif 000201
【図１５５（ａ）】
0006259114.tif 000202
【図１５５（ｂ）】
0006259114.tif 000203
【図１５６（ａ）】
0006259114.tif 000204
【図１５６（ｂ）】
0006259114.tif 000205
【図１５７（ａ）】
0006259114.tif 000206
【図１５７（ｂ）】
0006259114.tif 000207
【図１５８（ａ）】
0006259114.tif 000208
【図１５８（ｂ）】
0006259114.tif 000209
【図１５９（ａ）】
0006259114.tif 000210
【図１５９（ｂ）】
0006259114.tif 000211
【図１６０】
0006259114.tif 000212
【図１６１】
0006259114.tif 000213
【図１６２】
0006259114.tif 000214
【図１６３】
0006259114.tif 000215
【図１６４】
0006259114.tif 000216
【図１６５】
0006259114.tif 000217
【図１６６】
0006259114.tif 000218
【図１６７】
0006259114.tif 000219
【図１６８】
0006259114.tif 000220
【図１６９】
0006259114.tif 000221
【図１７０】
0006259114.tif 000222