(57)【特許請求の範囲】
【請求項１】
放送信号を生成し、処理する方法であって、
一つ以上の放送サービスのための放送データを生成するステップと、
前記一つ以上の放送サービスの属性を説明する情報を含むサービスレイヤシグナリング情報を生成するステップと、
前記一つ以上の放送サービスを迅速にスキャンするための基本情報を含むサービスリストシグナリング情報を生成するステップと、
前記放送データ、前記サービスレイヤシグナリング情報、及び前記サービスリストシグナリング情報を含む放送信号を生成するステップと、
を有し、
前記サービスリストシグナリング情報は、前記サービスリストシグナリング情報内に記述される全ての放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第１性能情報を含み、
前記サービスリストシグナリング情報は、前記一つ以上の放送サービスの一つの放送サービスを識別するサービス識別情報を更に含み、
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された前記放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第２性能情報を更に含む、放送信号生成処理方法。
【請求項２】
前記サービスレイヤシグナリング情報は、サービスレイヤ特性を記述するＵＳＤを含む、請求項１に記載の放送信号生成処理方法。
【請求項３】
前記サービスリストシグナリング情報は、前記サービスレイヤシグナリング情報を伝送するＰＬＰを識別するＰＬＰ識別情報をさらに含む、請求項１に記載の放送信号生成処理方法。
【請求項４】
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された放送サービスが、リニアサービス、アプリケーションサービス又はＥＳＧサービスに該当するか否かを識別するサービスカテゴリー情報をさらに含む、請求項３に記載の放送信号生成処理方法。
【請求項５】
一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスの属性を説明する情報を含むサービスレイヤシグナリング情報、及び前記一つ以上の放送サービスを迅速にスキャンするための基本情報を含むサービスリストシグナリング情報を含む放送信号を受信する放送信号受信部であって、前記サービスリストシグナリング情報は、前記サービスリストシグナリング情報内に記述される全ての放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第１性能情報を含む、放送信号受信部と、
前記サービスリストシグナリング情報及び前記サービスレイヤシグナリング情報を用いて、前記一つ以上の放送サービスを提供するための制御機能を実行するプロセッサと、
を備え、
前記サービスリストシグナリング情報は、前記一つ以上の放送サービスの一つの放送サービスを識別するサービス識別情報を更に含み、
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された前記放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第２性能情報を更に含む、放送信号受信機。
【請求項６】
前記サービスレイヤシグナリング情報は、サービスレイヤ特性を記述するＵＳＤを含む、請求項５に記載の放送信号受信機。
【請求項７】
前記サービスリストシグナリング情報は、前記サービスレイヤシグナリング情報を伝送するＰＬＰを識別するＰＬＰ識別情報をさらに含む、請求項５に記載の放送信号受信機。
【請求項８】
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された放送サービスが、リニアサービス、アプリケーションサービス又はＥＳＧサービスに該当するか否かを識別するサービスカテゴリー情報をさらに含む、請求項７に記載の放送信号受信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関する。
【背景技術】
【０００２】
アナログ放送信号送信が終了することにより、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてより多量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータの他、様々な種類の付加データをさらに含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
すなわち、デジタル放送システムは、ＨＤ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ  ｃｈａｎｎｅｌ、多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかしながら、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークの堅固性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させなければならない。
【課題を解決するための手段】
【０００４】
前述した技術的課題を解決するための本発明の一実施例に係る放送信号生成処理方法は、一つ以上の放送サービスのための放送データをエンコーディングするステップと、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコーディングするステップと、前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコーディングするステップと、前記放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成するステップとを有し、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含む。
【０００５】
好適には、前記一つ以上の放送コンテンツのそれぞれは、一つ以上のコンポーネントを含み、前記第１性能情報は、前記性能情報が適用される、コンポーネントのタイプをさらに識別することを特徴とする。
【０００６】
好適には、前記一つ以上の放送サービスは、アプリケーションサービスを含み、前記第１性能情報は、前記アプリケーションサービスに含まれるコンポーネントをダウンロードするために用いられるダウンロードプロトコルをさらに識別することを特徴とする。
【０００７】
好適には、前記第１シグナリング情報は、放送サービスに対するサービス層属性を記述するＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）情報を含み、前記ＵＳＤ情報は、前記放送サービスの放送コンテンツを表出するために要求される性能を識別する第２性能情報を含むことを特徴とする。
【０００８】
好適には、前記第１性能情報が示す情報と前記第２性能情報が示す情報とが異なる場合、前記第２性能情報に優先順位を与えることを特徴とする。
【０００９】
好適には、前記第２レベルシグナリング情報は、前記第１レベルシグナリング情報を伝送するＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）を識別するＰＬＰ識別情報をさらに含むことを特徴とする。
【００１０】
好適には、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスが、リニア（ｌｉｎｅａｒ）サービス、アプリケーションサービス又はＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）サービスに該当するかを識別するサービスカテゴリー情報をさらに含むことを特徴とする。
【００１１】
前述した技術的課題を解決するための本発明の一実施例に係る、放送受信機は、一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報を含む放送信号を受信する放送信号受信部であって、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含む、放送信号受信部と、前記第２レベルシグナリング情報及び前記第１レベルシグナリング情報を用いて、前記放送サービスを取得し、前記放送サービスを表出するように制御するプロセッサとを備える。
【００１２】
好適には、前記一つ以上の放送コンテンツのそれぞれは、一つ以上のコンポーネントを含み、前記第１性能情報は、前記性能情報が適用される、コンポーネントのタイプをさらに識別することを特徴とする。
【００１３】
好適には、前記一つ以上の放送サービスは、アプリケーションサービスを含み、前記第１性能情報は、前記アプリケーションサービスに含まれるコンポーネントをダウンロードするために用いられるダウンロードプロトコルをさらに識別することを特徴とする。
【００１４】
好適には、前記第１シグナリング情報は、放送サービスに対するサービス層属性を記述するＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）情報を含み、前記ＵＳＤ情報は、前記放送サービスの放送コンテンツを表出するために要求される性能を識別する第２性能情報を含むことを特徴とする。
【００１５】
好適には、前記第１性能情報が示す情報と前記第２性能情報が示す情報とが異なる場合、前記第２性能情報に優先順位を与えることを特徴とする。
【００１６】
好適には、前記第２レベルシグナリング情報は、前記第１レベルシグナリング情報を伝送するＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）を識別するＰＬＰ識別情報をさらに含むことを特徴とする。
【００１７】
好適には、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスが、リニア（ｌｉｎｅａｒ）サービス、アプリケーションサービス、又はＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）サービスに該当するかを識別するサービスカテゴリー情報をさらに含むことを特徴とする。
【００１８】
好適には、前記プロセッサは、前記第１性能情報が示す受信機に要求される性能が、前記放送信号受信機によって支援される性能である場合にのみ、前記第１性能情報と関連した放送サービスをチャネルマップに含ませて、前記チャネルマップを生成することを特徴とする。
【発明の効果】
【００１９】
本発明は、サービス特性に応じてデータを処理して各サービス又はサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を制御することによって様々な放送サービスを提供することができる。
【００２０】
本発明は、同じＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）信号帯域幅で様々な放送サービスを伝送することによって伝送柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成することができる。
【００２１】
本発明によれば、モバイル受信装置を使用したり室内環境にいても、エラー無しでデジタル放送信号を受信することができる放送信号送信及び受信方法並びに装置を提供することができる。
【００２２】
本発明は、地上波放送網とインターネット網とを使用する次世代ハイブリッド放送を支援する環境で次世代放送サービスを効果的に支援することができる。
【００２３】
本発明のさらなる理解のために含まれ、本出願に含まれ、その一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に本発明の実施例を示す。
【図面の簡単な説明】
【００２４】
【図１】本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ  ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示した図である。
【図２】本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）の関係を示した図である。
【図３】本発明の一実施例に係るＳＬＴを示した図である。
【図４】本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリー過程を示した図である。
【図５】本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。
【図６】本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。
【図７】本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。
【図８】本発明の一実施例に係るリンクレイヤプロトコルアーキテクチャーを示した図である。
【図９】本発明の一実施例に係るリンクレイヤパケットのベースヘッダーの構造を示した図である。
【図１０】本発明の一実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。
【図１１】本発明の他の実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。
【図１２】本発明の一実施例に係る、ＭＰＥＧ−２ ＴＳパケットのためのリンクレイヤパケットのヘッダー構造、及びそのエンカプセレーション過程を示した図である。
【図１３】本発明の一実施例に係るＩＰヘッダー圧縮において、アダプテーションモードの実施例を示した図である（送信側）。
【図１４】本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）及びＲＯＨＣ−Ｕディスクリプションテーブルを示した図である。
【図１５】本発明の一実施例に係る送信機側のリンクレイヤの構造を示した図である。
【図１６】本発明の一実施例に係る受信機側のリンクレイヤの構造を示した図である。
【図１７】本発明の一実施例に係る、リンクレイヤを介したシグナリング伝送構造を示した図である（送／受信側）。
【図１８】本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置の構造を示す図である。
【図１９】本発明の一実施例に係るＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。
【図２０】本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【図２１】本発明の一実施例に係るＰＬＳのビットインターリービング過程を示す図である。
【図２２】本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す図である。
【図２３】本発明の一実施例に係るフレームのシグナリング階層構造を示す図である。
【図２４】本発明の一実施例に係るＰＬＳ１データを示す図である。
【図２５】本発明の一実施例に係るＰＬＳ２データを示す図である。
【図２６】本発明の他の実施例に係るＰＬＳ２データを示す図である。
【図２７】本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ、論理）構造を示す図である。
【図２８】本発明の一実施例に係るＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）マッピングを示す図である。
【図２９】本発明の一実施例に係るタイムインターリービングを示す図である。
【図３０】本発明の一実施例に係る、ツイストされた行−列ブロックインターリーバの基本動作を示す図である。
【図３１】本発明の他の実施例に係る、ツイストされた行−列ブロックインターリーバの動作を示す図である。
【図３２】本発明の一実施例に係る、各ＦＦＴモードによるメイン−ＰＲＢＳジェネレーターとサブ−ＰＲＢＳジェネレーターで構成されたインターリービングアドレスジェネレーターのブロックダイアグラムを示す図である。
【図３３】本発明の一実施例に係る、全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。
【図３４】本発明の一実施例に係る、フリケンシーインターリービングのためのインターリービングアドレス及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。
【図３５】本発明の一実施例に係る、タイムインターリーバの書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す図である。
【図３６】ＰＬＰ個数によって適用するインターリービングタイプを表で示す図である。
【図３７】上述したハイブリッドタイムインターリーバ構造の第１実施例を含むブロック図である。
【図３８】上述したハイブリッドタイムインターリーバ構造の第２実施例を含むブロック図である。
【図３９】ハイブリッドタイムデインターリーバの構造の第１実施例を含むブロック図である。
【図４０】ハイブリッドタイムデインターリーバの構造の第２実施例を含むブロック図である。
【図４１】本発明の一実施例に係るハイブリッド放送受信装置を示す図である。
【図４２】本発明の一実施例に係るハイブリッド放送受信機を示すブロック図である。
【図４３】本発明の一実施例に係る次世代ハイブリッド放送システムのプロトコルスタックを示す図である。
【図４４】本発明の一実施例に係る次世代放送伝送システムのフィジカルレイヤに伝達される伝送フレームの構造を示す図である。
【図４５】本発明の一実施例に係る、アプリケーション層伝送プロトコルの伝送パケットを示す図である。
【図４６】本発明の一実施例に係る、次世代放送システムがシグナリングデータを伝送する方法を示す図である。
【図４７】本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。
【図４８】本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。
【図４９】本発明の一実施例に係る、ＦＩＣベースシグナリングを伝送する方法を示す図である。
【図５０】本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。
【図５１】本発明の他の実施例に係る、ＦＩＣベースシグナリングを伝送する方法を示す図である。
【図５２】本発明の一実施例に係る次世代放送システムのサービスシグナリングメッセージフォーマットを示す図である。
【図５３】本発明の一実施例に係る、次世代放送システムで用いるサービスシグナリングテーブルを示す図である。
【図５４】本発明の一実施例に係る、次世代放送システムで用いられるサービスマッピングテーブルを示す図である。
【図５５】本発明の一実施例に係る、次世代放送システムのサービスシグナリングテーブルを示す図である。
【図５６】本発明の一実施例に係る、次世代放送システムで用いられるコンポーネントマッピングテーブルを示す図である。
【図５７】本発明の一実施例に係る、コンポーネントマッピングテーブルディスクリプションを示す図である。
【図５８】本発明の一実施例に係る、次世代放送システムのコンポーネントマッピングテーブルのシンタックスを示す図である。
【図５９】本発明の一実施例に係る、次世代放送システムにおいて各サービスと関連したシグナリングをブロードバンド網を介して伝達する方法を示す図である。
【図６０】本発明の一実施例に係る、次世代放送システムにおいてＭＰＤをシグナリングする方案を示す図である。
【図６１】本発明の一実施例に係る、次世代放送システムのＭＰＤデリバリーテーブルのシンタックスを示す図である。
【図６２】本発明の一実施例に係る、次世代放送システムの伝送セッションインスタンスディスクリプションを示す図である。
【図６３】本発明の一実施例に係る次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す図である。
【図６４】本発明の一実施例に係る次世代放送システムのＥＦＤＴを示す図である。
【図６５】本発明の一実施例に係る、次世代放送システムが用いるＩＳＤＴを伝送する方法を示す図である。
【図６６】本発明の一実施例に係る、次世代放送システムのシグナリングメッセージのデリバリー構造を示す図である。
【図６７】本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。
【図６８】本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。
【図６９】本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。
【図７０】本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。
【図７１】本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。
【図７２】本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。
【図７３】本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。
【図７４】本発明の一実施例に係るＭＰＤの共通属性及びエレメントを示す図である。
【図７５】本発明の一実施例に係る伝送セッションインスタンスディスクリプションを示す図である。
【図７６】本発明の一実施例に係る次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す図である。
【図７７】本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。
【図７８】本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。
【図７９】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す図である。
【図８０】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す図である。
【図８１】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す図である。
【図８２】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す図である。
【図８３】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。
【図８４】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。
【図８５】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。
【図８６】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。
【図８７】本発明の一実施例に係る、次世代放送システムのサービスレイヤシグナリングを伝送する方法を示す図である。
【図８８】本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。
【図８９】本発明の他の実施例に係る、シグナリングメッセージ（ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ）のヘッダー（ｈｅａｄｅｒ）のシンタックス（ｓｙｎｔａｘ）を示す図である。
【図９０】本発明の一実施例に係る、ＤＡＳＨ初期化セグメント（ＤＡＳＨ  Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）を処理するプロトコルスタック（Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）を示す図である。
【図９１】本発明の一実施例に係る、ＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションインスタンスディスクリプタ（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＬＳＩＤ）の一部を示す図である。
【図９２】本発明の一実施例に係る、サービスシグナリングメッセージをフィルタリング（ｆｉｌｔｅｒｉｎｇ）するための情報を提供するシグナリングオブジェクトディスクリプション（Ｓｉｇｎａｌｉｎｇ  Ｏｂｊｅｃｔ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＳＯＤ）を示す図である。
【図９３】本発明の一実施例に係る、シグナリングメッセージを含むオブジェクトを示す図である。
【図９４】本発明の一実施例に係る、ＴＯＩ構成ディスクリプション（ＴＯＩ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＤ）を示す図である。
【図９５】本発明の一実施例に係る、伝送パケットのペイロード（Ｐａｙｌｏａｄ）フォーマット（Ｆｏｒｍａｔ）エレメントを示す図である。
【図９６】本発明の一実施例に係る、ＴＯＩ構成インスタンスディスクリプション（ＴＯＩ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＩＤ）を示す図である。
【図９７】本発明の一実施例に係る、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）のペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。
【図９８】本発明の他の実施例に係る、ＦＩＣのペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。
【図９９】本発明の他の実施例に係る、サービスレベルシグナリングのシンタックス（ｓｙｎｔａｘ）を示す図である。
【図１００】本発明の他の実施例に係る、コンポーネントマッピングディスクリプション（ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ）を示す図である。
【図１０１】本発明の他の実施例に係る、ＵＲＬシグナリングディスクリプション（ＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ）のシンタックス（ｓｙｎｔａｘ）を示す図である。
【図１０２】本発明の他の実施例に係る、ＳｏｕｒｃｅＦｌｏｗエレメントを示す図である。
【図１０３】本発明の他の実施例に係る、シグナリング情報を放送網を介して取得する過程を示す図である。
【図１０４】本発明の他の実施例に係る、シグナリング情報を放送網及びブロードバンド網を介して取得する過程を示す図である。
【図１０５】本発明の他の実施例に係る、シグナリング情報をブロードバンド網を介して取得する過程を示す図である。
【図１０６】本発明の他の実施例に係る、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）を放送網を介して取得する過程を示す図である。
【図１０７】本発明の他の実施例に係る、放送サービスのビデオセグメント及びオーディオセグメントを放送網を介して取得する過程を示す図である。
【図１０８】本発明の他の実施例に係る、放送サービスのビデオセグメントは放送網を介して取得し、放送サービスのオーディオセグメントはブロードバンド網を介して取得する過程を示す図である。
【図１０９】本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。
【図１１０】本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。
【図１１１】本発明の一実施例に係るＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）の構成を示す図である。
【図１１２】本発明の他の実施例に係るＦＩＣの構成を示す図である。
【図１１３】本発明の一実施例に係るＳｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎの構成を示す図である。
【図１１４】本発明の一実施例に係るＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎの構成を示す図である。
【図１１５】本発明の一実施例に係る放送信号送信方法を示す図である。
【図１１６】本発明の一実施例に係る放送信号受信方法を示す図である。
【図１１７】本発明の一実施例に係る放送信号送信装置の構成を示す図である。
【図１１８】本発明の一実施例に係る放送信号受信装置の構成を示す図である。
【図１１９】本発明の一実施例に係る、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝達される場合において、そのサービスディスクリプション情報を示す図である。
【図１２０】本発明の一実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。
【図１２１】本発明の一実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。
【図１２２】本発明の他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。
【図１２３】本発明の更に他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。
【図１２４】本発明の一実施例に係る、初期化情報伝達のために拡張されたシグナリングメッセージを示す図である。
【図１２５】本発明の一実施例に係る、初期化情報伝達のためのメッセージフォーマットを示す図である。
【図１２６】本発明の他の実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。
【図１２７】本発明の一実施例に係る、サービスデータを処理する方法を示す図である。
【図１２８】本発明の一実施例に係る、サービスデータを処理する装置を示す図である。
【図１２９】本発明の一実施例に係るＥＳＧブートストラップ情報を示す図である。
【図１３０】本発明の一実施例に係る、ＥＳＧブートストラップ情報が伝送されるタイプを示す図である。
【図１３１】本発明の第１実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。
【図１３２】本発明の第２実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。
【図１３３】本発明の第３実施例に係るＥＳＧブートストラッピングディスクリプションのシグナリングを示す図である。
【図１３４】本発明の第４実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。
【図１３５】本発明の第５実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。
【図１３６】本発明の第５実施例に係るＧＡＴを示す図である。
【図１３７】本発明の第１実施例乃至第５実施例の効果を示す図である。
【図１３８】本発明の一実施例に係る放送受信装置の流れを示す図である。
【図１３９】本発明の一実施例に係るチャネルマップ構成方法を示す図である。
【図１４０】本発明の一実施例に係るチャネルマップ構成方法を示す図である。
【図１４１】本発明の一実施例に係るＦＩＣを示す図である。
【図１４２】本発明の一実施例に係るＦＩＣを示す図である。
【図１４３】本発明の一実施例に係るＦＩＣを示す図である。
【図１４４】本発明の一実施例に係るＦＩＣを示す図である。
【図１４５】本発明の一実施例に係るＦＩＣを示す図である。
【図１４６】本発明の一実施例に係るＦＩＣを示す図である。
【図１４７】本発明の一実施例に係るＳＳＣを示す図である。
【図１４８】本発明の一実施例に係る放送伝送方法の流れを示す図である。
【図１４９】本発明の一実施例に係る放送受信方法の流れを示す図である。
【図１５０】本発明の一実施例に係る、受信機移動時における他の周波数へのハンドオーバー（ｈａｎｄｏｖｅｒ）状況を示す図である。
【図１５１】本発明の一実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。
【図１５２】本発明の他の実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。
【図１５３】本発明の一実施例に係る、シームレスハンドオーバーのための情報を示す図である。
【図１５４】本発明の一実施例に係るローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【図１５５】本発明の一実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。
【図１５６】本発明の他の実施例に係る、ローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【図１５７】本発明の他の実施例に係る、ローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【図１５８】本発明の他の実施例に係る、ローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【図１５９】本発明の他の実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。
【図１６０】本発明の一実施例に係る、放送信号を生成処理する方法を示すフローチャートである。
【図１６１】本発明の一実施例に係る放送システムを示す図である。
【発明を実施するための形態】
【００２５】
本発明の好適な実施例について具体的に説明し、その例は添付の図面に示す。添付の図面を参照する下記の詳細な説明は、本発明の具現可能な実施例のみを示すものではなく、本発明の好適な実施例を説明するものである。下記の詳細な説明は、本発明に対する徹底した理解を提供するために細部事項を含む。しかし、本発明がこのような細部事項無しでも実行可能であることは当業者にとって明らかである。
【００２６】
本発明で使われる大部分の用語は、当該分野で広く使われる一般的な用語から選択されるが、一部の用語は出願人によって任意に選択されたものもあり、その意味は必要によって該当の説明部分で詳細に説明する。したがって、本発明は、用語の単純な名称や意味ではなく、用語が意図する意味に基づいて理解されなければならない。
【００２７】
本発明は、次世代放送サービスに対する放送信号の送信及び受信装置及び方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含むことができる。
【００２８】
図１は、本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ  ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示した図である。
【００２９】
放送網を介したサービスデリバリー（ｂｒｏａｄｃａｓｔ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）において、２つの方法があり得る。
【００３０】
第一の方法は、ＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）に基づいて、ＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔｓ）をＭＭＴＰ（ＭＭＴ  ｐｒｏｔｏｃｏｌ）を用いて伝送することである。第二の方法は、ＭＰＥＧ ＤＡＳＨに基づいて、ＤＡＳＨセグメントをＲＯＵＴＥ（Ｒｅａｌ  ｔｉｍｅ  Ｏｂｊｅｃｔ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を用いて伝送することである。
【００３１】
ＮＲＴメディア、ＥＰＧデータ、及び他のファイルを含む非時間コンテンツは、ＲＯＵＴＥで伝達される。シグナルは、ＭＭＴＰ及び／又はＲＯＵＴＥを介して伝達できる一方、ブートストラップシグナリング情報はＳＬＴ（ｓｅｒｖｉｃｅ  ｌｉｓｔ  ｔａｂｌｅ）によって提供される。
【００３２】
ハイブリッドサービスデリバリー（ｈｙｂｒｉｄ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）においては、ＨＴＴＰ／ＴＣＰ／ＩＰ上のＭＰＥＧ ＤＡＳＨがブロードバンド側で用いられる。ＩＳＯ ＢＭＦＦ（ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）のメディアファイルは、デリバリー、ブロードキャスト及びブロードバンドデリバリーに対するメディアエンカプセレーション及び同期化フォーマットとして使用される。ここで、ハイブリッドサービスデリバリーとは、１つまたはそれ以上のプログラムエレメントがブロードバンドパス（ｐａｔｈ）を介して伝達される場合のことをいえる。
【００３３】
サービスは、３つの機能レイヤを用いて伝達される。これらは、フィジカルレイヤ、デリバリーレイヤ、サービスマネジメントレイヤである。フィジカルレイヤは、シグナル、サービス公知、ＩＰパケットストリームがブロードキャストフィジカルレイヤ及び／又はブロードバンドフィジカルレイヤで伝送されるメカニズムを提供する。デリバリーレイヤは、オブジェクト及びオブジェクトフロートランスポート機能を提供する。これは、ブロードキャストフィジカルレイヤのＵＤＰ／ＩＰマルチキャストで動作するＭＭＴＰまたはＲＯＵＴＥプロトコルによって可能であり、ブロードバンドフィジカルレイヤのＴＣＰ／ＩＰユニキャストでＨＴＴＰプロトコルによって可能である。サービスマネジメントレイヤは、下位であるデリバリー及びフィジカルレイヤによって実行されるリニアＴＶまたはＨＴＭＬ５応用サービスのような全てのサービスを可能にする。
【００３４】
本図において、放送（ｂｒｏａｄｃａｓｔ）側のプロトコルスタック部分は、ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分とに分けられる。
【００３５】
ＳＬＴは、ＵＤＰ、ＩＰレイヤを経てエンカプセレーションされてもよい。ここで、ＳＬＴについては後述する。ＭＭＴＰは、ＭＭＴで定義されるＭＰＵフォーマットでフォーマットされたデータ、及びＭＭＴＰによるシグナリング情報を伝送することができる。これらデータは、ＵＤＰ、ＩＰレイヤを経てエンカプセレーションされてもよい。ＲＯＵＴＥは、ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、そして、ＮＲＴなどのノンタイムド（ｎｏｎ  ｔｉｍｅｄ）データを伝送することができる。これらデータも、ＵＤＰ、ＩＰレイヤを経てエンカプセレーションされてもよい。実施例によって、ＵＤＰ、ＩＰレイヤによるプロセシングは一部又は全部省略されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であり得る。
【００３６】
ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分は、ＵＤＰ、ＩＰレイヤで処理された後、リンクレイヤ（Ｄａｔａ  Ｌｉｎｋ  Ｌａｙｅｒ）で再びエンカプセレーションされてもよい。リンクレイヤについては後述する。リンクレイヤで処理された放送データは、フィジカルレイヤでエンコーディング／インターリービングなどの過程を経て放送信号としてマルチキャストされてもよい。
【００３７】
本図において、ブロードバンド（ｂｒｏａｄｂａｎｄ）側のプロトコルスタック部分は、前述したように、ＨＴＴＰを介して伝送されてもよい。ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、ＮＲＴなどの情報がＨＴＴＰを介して伝送されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であってもよい。このデータは、ＴＣＰ、ＩＰレイヤを経てプロセシングされた後、リンクレイヤでエンカプセレーションされてもよい。実施例によって、ＴＣＰ、ＩＰ、リンクレイヤの一部又は全部は省略されてもよい。この後、処理されたブロードバンドデータは、フィジカルレイヤで伝送のための処理を経てブロードバンドにユニキャストされてもよい。
【００３８】
サービスは、全体的にユーザに見せるメディアコンポーネントのコレクションであってもよく、コンポーネントは、種々のメディアタイプのものであってもよく、サービスは、連続的または間欠的であってもよく、サービスは、リアルタイムまたは非リアルタイムであってもよく、リアルタイムサービスはＴＶプログラムのシーケンスで構成されてもよい。
【００３９】
図２は、本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）の関係を示した図である。
【００４０】
サービスシグナリングは、サービスディスカバリー及びディスクリプション情報を提供し、２つの機能コンポーネントを含む。これらは、ＳＬＴを介したブートストラップシグナリングとＳＬＳである。これらは、ユーザサービスを発見し、獲得するのに必要な情報を示す。ＳＬＴは、受信機が、基本サービスリストを作成し、各サービスに対するＳＬＳの発見をブートストラップできるようにする。
【００４１】
ＳＬＴは、基本サービス情報の非常に速い獲得を可能にする。ＳＬＳは、受信機が、サービスとそのコンテンツコンポーネントを発見し、これに接続できるようにする。ＳＬＴとＳＬＳの具体的な内容については後述する。
【００４２】
前述したように、ＳＬＴは、ＵＤＰ／ＩＰを介して伝送され得る。このとき、実施例によって、この伝送において最もロバストな（ｒｏｂｕｓｔ）方法を通じて、ＳＬＴに該当するデータが伝達されてもよい。
【００４３】
ＳＬＴは、ＲＯＵＴＥプロトコルによって伝達されるＳＬＳに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＲＯＵＴＥプロトコルによるＳＬＳにブートストラッピングすることができる。このＳＬＳは、前述したプロトコルスタックにおいてＲＯＵＴＥの上位レイヤに位置するシグナリング情報であって、ＲＯＵＴＥ／ＵＤＰ／ＩＰを介して伝達され得る。このＳＬＳは、ＲＯＵＴＥセッションに含まれるＬＣＴセッションのうち１つを介して伝達され得る。このＳＬＳを用いて、所望のサービスに該当するサービスコンポーネントに接近することができる。
【００４４】
また、ＳＬＴは、ＭＭＴＰによって伝達されるＭＭＴシグナリングコンポーネントに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＭＭＴＰによるＳＬＳにブートストラッピングすることができる。このＳＬＳは、ＭＭＴで定義するＭＭＴＰシグナリングメッセージ（Ｓｉｇｎａｌｉｎｇ  Ｍｅｓｓａｇｅ）によって伝達され得る。このＳＬＳを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。前述したように、本発明では、ＮＲＴサービスコンポーネントは、ＲＯＵＴＥプロトコルを介して伝達され、ＭＭＴＰによるＳＬＳは、これに接近するための情報も含むことができる。ブロードバンドデリバリーにおいて、ＳＬＳはＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰで伝達される。
【００４５】
図３は、本発明の一実施例に係るＳＬＴを示した図である。
【００４６】
まず、サービスマネジメント、デリバリー、フィジカルレイヤの各論理的エンティティー間の関係について説明する。
【００４７】
サービスは、２つの基本タイプのうち１つとしてシグナリングされ得る。第一のタイプは、アプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオまたはオーディオのみのサービスである。第二のタイプは、プレゼンテーション及び構成が、サービスの獲得によって実行されるダウンロードアプリケーションによって制御されるサービスである。後者は、アプリベースのサービスと呼ぶこともできる。
【００４８】
サービスのコンテンツコンポーネントを伝達するＭＭＴＰセッション及び／又はＲＯＵＴＥ／ＬＣＴセッションの存在と関連する規則は、次の通りである。
【００４９】
アプリベースのエンハンスメントがないリニアサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、または（２）１つ以上のＭＭＴＰセッションのうち１つ（両方ともではない）によって伝達され得る。
【００５０】
アプリベースのエンハンスメントがあるリニアサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、及び（２）０個以上のＭＭＴＰセッションによって伝達され得る。
【００５１】
特定の実施例において、同一のサービスでストリーミングメディアコンポーネントに対するＭＭＴＰ及びＲＯＵＴＥの両者の使用が許容されないことがある。
【００５２】
アプリベースのサービスのブロードキャストデリバリーのために、サービスのコンテンツコンポーネントは１つ以上のＲＯＵＴＥ／ＬＣＴセッションによって伝達され得る。
【００５３】
それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリーにおいて、ＬＣＴセッションは、オーディオ、ビデオ、またはクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアは、ＤＡＳＨセグメントとしてフォーマットされる。
【００５４】
それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージまたは全体又は一部のコンテンツコンポーネントを伝達する、１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ、またはＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。
【００５５】
ＮＲＴユーザサービスまたはシステムメタデータのデリバリーのために、ＬＣＴセッションは、ファイルベースのコンテンツアイテムを伝達する。これらコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、またはサービスシグナリングやＥＳＧフラグメントのようなメタデータで構成され得る。サービスシグナリングやＥＳＧフラグメントのようなシステムメタデータのデリバリーも、ＭＭＴＰのシグナリングメッセージモードを通じて行われてもよい。
【００５６】
ブロードキャストストリームは、特定の帯域内に集中したキャリア周波数の観点で定義されたＲＦチャンネルの概念である。それは、［地理的領域、周波数］ペアによって識別される。ＰＬＰ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｉｐｅ）は、ＲＦチャンネルの一部に該当する。各ＰＬＰは、特定のモジュレーション及びコーディングパラメータを有する。それは、属しているブロードキャストストリーム内で唯一のＰＬＰＩＤ（ＰＬＰ  ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ここで、ＰＬＰはＤＰ（ｄａｔａ  ｐｉｐｅ）と呼ぶこともできる。
【００５７】
各サービスは、２つの形態のサービス識別子によって識別される。一方は、ＳＬＴで使用され、ブロードキャスト領域内でのみ唯一のコンパックな形態であり、他方は、ＳＬＳ及びＥＳＧで使用される全世界的に唯一の形態である。ＲＯＵＴＥセッションは、ソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションポートナンバーによって識別される。ＬＣＴセッション（それが伝達するサービスコンポーネントと関連する）は、ペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＬＣＴセッションに共通した属性及び個別ＬＣＴセッションに唯一の特定の属性は、サービスレイヤシグナリングの一部であるＳ−ＴＳＩＤ（ｓｅｒｖｉｃｅ−ｂａｓｅｄ  ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれるＲＯＵＴＥシグナリング構造で与えられる。各ＬＣＴセッションは、１つのＰＬＰを介して伝達される。実施例によって、１つのＬＣＴセッションが複数個のＰＬＰを介して伝達されてもよい。ＲＯＵＴＥセッションの互いに異なるＬＣＴセッションは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＲＯＵＴＥセッションは、複数個のＰＬＰを介して伝達されてもよい。Ｓ−ＴＳＩＤに記述された属性は、各ＬＣＴセッションに対するＴＳＩ値及びＰＬＰＩＤ、デリバリーオブジェクト／ファイルに対するディスクリプタ、アプリケーションレイヤＦＥＣパラメータを含む。
【００５８】
ＭＭＴＰセッションは、デスティネーションＩＰアドレス及びデスティネーションポートナンバーによって識別される。ＭＭＴＰパケットフロー（それが伝達するサービスコンポーネントと関連する）は、ペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ_ｉｄによって識別される。各ＭＭＴＰパケットフローに共通した属性及びＭＭＴＰパケットフローの特定の属性がＳＬＴに与えられる。各ＭＭＴＰセッションに対する属性は、ＭＭＴＰセッション内で伝達され得るＭＭＴシグナリングメッセージによって与えられる。ＭＭＴＰセッションの互いに異なるＭＭＴＰパケットフローは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＭＭＴＰセッションは、複数個のＰＬＰを介して伝達されてもよい。ＭＭＴシグナリングメッセージに記述された属性は、各ＭＭＴＰパケットフローに対してｐａｃｋｅｔ_ｉｄ値及びＰＬＰＩＤを含む。ここで、ＭＭＴシグナリングメッセージは、ＭＭＴで定義された形態であるか、または後述する実施例によって変形が行われた形態であってもよい。
【００５９】
以下、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【００６０】
この機能に専用であるよく知られているアドレス／ポートを有するＩＰパケットのペイロードに伝達されるシグナリング情報は、ＬＬＳと呼ばれる。このＩＰアドレス及びポートナンバーは、実施例によって異なって設定されてもよい。一実施例において、ＬＬＳは、アドレスが２２４．０．２３．６０であり、デスティネーションポートが４９３７／ｕｄｐであるＩＰパケットに伝達され得る。ＬＬＳは、前述したプロトコルスタック上で、「ＳＬＴ」で表現された部分に位置し得る。ただし、実施例によって、ＬＬＳは、ＵＤＰ／ＩＰレイヤのプロセシングを経ずに、信号フレーム上の別途の物理チャンネル（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）を介して伝送されてもよい。
【００６１】
ＬＬＳデータを伝達するＵＤＰ／ＩＰパケットは、ＬＬＳテーブルという形態でフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの開始であり得る。全てのＬＬＳテーブルの最大の長さは、フィジカルレイヤから伝達され得る最も大きいＩＰパケットによって６５，５０７バイトに制限される。
【００６２】
ＬＬＳテーブルは、ＬＬＳテーブルのタイプを識別するＬＬＳテーブルＩＤフィールド、及びＬＬＳテーブルのバージョンを識別するＬＬＳテーブルバージョンフィールドを含むことができる。ＬＬＳテーブルＩＤフィールドが示す値に応じて、ＬＬＳテーブルは、前述したＳＬＴを含むか、またはＲＲＴ（Ｒａｔｉｎｇ  Ｒｅｇｉｏｎ  Ｔａｂｌｅ）を含むことができる。ＲＲＴは、コンテンツ勧告レーティング（Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙ  Ｒａｔｉｎｇ）に関する情報を有することができる。
【００６３】
以下、ＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）について説明する。ＬＬＳは、受信機によるサービス獲得のブートストラッピング及び速いチャンネルスキャンを支援するシグナリング情報であり、ＳＬＴは、基本サービスリスティングを構築し、ＳＬＳのブートストラップディスカバリーを提供するために使用されるシグナリング情報のテーブルであり得る。
【００６４】
ＳＬＴの機能は、ＭＰＥＧ−２システムでのＰＡＴ（ｐｒｏｇｒａｍ  ａｓｓｏｃｉａｔｉｏｎ  ｔａｂｌｅ）及びＡＴＳＣシステムで発見されるＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）とほぼ同一である。初めてブロードキャストエミッションを経験する受信機にとって、これは、開始される地点である。ＳＬＴは、受信機が、チャンネル名、チャンネルナンバーなどでそれが受信できる全てのサービスのリストを構築できるようにする、速いチャンネルスキャンを支援する。また、ＳＬＴは、受信機が各サービスに対してＳＬＳを発見できるようにするブートストラップ情報を提供する。ＲＯＵＴＥ／ＤＡＳＨで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＬＣＴセッションのデスティネーションＩＰアドレス及びデスティネーションポートを含む。ＭＭＴ／ＭＰＵで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＭＭＴＰセッションのデスティネーションＩＰアドレス及びデスティネーションポートを含む。
【００６５】
ＳＬＴは、ブロードキャストストリームで各サービスに関する次の情報を含むことによって、サービス獲得及び速いチャンネルスキャンを支援する。第一に、ＳＬＴは、視聴者にとって有意義であり、上／下の選択またはチャンネルナンバーを介した初期サービス選択を支援できるサービスリストのプレゼンテーションを許容するのに必要な情報を含むことができる。第二に、ＳＬＴは、各リスティングされたサービスに対してＳＬＳの位置を見つけるのに必要な情報を含むことができる。すなわち、ＳＬＴは、ＳＬＳを伝達する位置（ｌｏｃａｔｉｏｎ）に対するアクセス情報を含むことができる。
【００６６】
図示された本発明の一実施例に係るＳＬＴは、ＳＬＴルートエレメント（ｒｏｏｔ  ｅｌｅｍｅｎｔ）を有するＸＭＬドキュメントの形態で表現された。実施例によって、ＳＬＴは、バイナリフォーマットまたはＸＭＬドキュメントの形態で表現することができる。
【００６７】
図示されたＳＬＴのＳＬＴルートエレメントは、＠ｂｓｉｄ、＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ、＠ｌａｎｇｕａｇｅ、＠ｃａｐａｂｉｌｉｔｉｅｓ、ＩｎｅｔＳｉｇＬｏｃ及び／又はＳｅｒｖｉｃｅを含むことができる。実施例によって、ＳＬＴルートエレメントは、＠ｐｒｏｖｉｄｅｒＩｄをさらに含むこともできる。実施例によって、ＳＬＴルートエレメントは、＠ｌａｎｇｕａｇｅを含まなくてもよい。
【００６８】
Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ、＠ｐｒｏｔｅｃｔｅｄ、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ、＠ｈｉｄｄｅｎ、＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅ、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ、＠ｓｌｓＰｌｐＩｄ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ、＠ｃａｐａｂｉｌｉｔｉｅｓ及び／又はＩｎｅｔＳｉｇＬｏｃを含むことができる。
【００６９】
実施例によって、ＳＬＴの属性またはエレメントは追加／変更／削除されてもよい。ＳＬＴに含まれる各エレメントも、追加的に別途の属性またはエレメントを有することができ、本実施例に係る属性またはエレメントの一部が省略されてもよい。ここで、＠表記されたフィールドは属性（ａｔｔｒｉｂｕｔｅ）に該当し、＠表記されていないフィールドはエレメント（ｅｌｅｍｅｎｔ）に該当し得る。
【００７０】
＠ｂｓｉｄは、全ブロードキャストストリームの識別子である。ＢＳＩＤの値は、地域的レベルで唯一であり得る。
【００７１】
＠ｐｒｏｖｉｄｅｒＩｄは、このブロードキャストストリームの一部又は全体を使用する放送会社のインデックスである。これは選択的な属性である。それが存在しないということは、このブロードキャストストリームが一つの放送会社によって使用されていることを意味する。＠ｐｒｏｖｉｄｅｒＩｄは図示していない。
【００７２】
＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ＳＬＴセクションのバージョンナンバーであり得る。ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ｓｌｔ内で伝達される情報に変化が生じると１ずつ増分し得る。それが最大値に到達すると、０にシフトされる。
【００７３】
＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒは、ＳＬＴの当該セクションのナンバーであって、１からカウントすることができる。すなわち、当該ＳＬＴセクションのセクションナンバーに該当し得る。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
【００７４】
＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは、当該セクションが一部であるＳＬＴのセクション（即ち、最大のｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒを有するセクション）の総ナンバーであり得る。ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒとｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは共に分割で伝送される場合、ＳＬＴの一部の「ＮのＭ部分」を示すと見ることができる。すなわち、ＳＬＴを伝送するにおいて、分割（ｆｒａｇｍｅｎｔａｔｉｏｎ）を通じた伝送を支援できる。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。フィールドが使用されない場合は、ＳＬＴが分割されて伝送されない場合であり得る。
【００７５】
＠ｌａｎｇｕａｇｅは、当該ｓｌｔの場合に含まれるサービスの主言語を示すことができる。実施例によって、このフィールド値は、ＩＳＯで定義される３−キャラクター言語コード（ｔｈｒｅｅ  ｃｈａｒａｃｔｅｒ  ｌａｎｇｕａｇｅ  ｃｏｄｅ）の形態であってもよい。本フィールドは省略されてもよい。
【００７６】
＠ｃａｐａｂｉｌｉｔｉｅｓは、当該ｓｌｔの場合において全てのサービスに対する内容をデコーディングし、有意義に示すために要求されるケイパビリティを示すことができる。
【００７７】
ＩｎｅｔＳｉｇＬｏｃは、どこでブロードバンドを介して外部サーバーから全ての要求されるタイプのデータを獲得できるかを受信機に知らせるＵＲＬを提供することができる。このエレメントは、＠ｕｒｌＴｙｐｅを下位フィールドとしてさらに含むこともできる。この＠ｕｒｌＴｙｐｅフィールドの値に応じて、ＩｎｅｔＳｉｇＬｏｃが提供するＵＲＬのタイプを指示することができる。実施例によって、＠ｕｒｌＴｙｐｅフィールド値が０である場合、ＩｎｅｔＳｉｇＬｏｃはシグナリングサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールド値が１である場合、ＩｎｅｔＳｉｇＬｏｃはＥＳＧサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールドが、それ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【００７８】
Ｓｅｒｖｉｃｅフィールドは、各サービスに関する情報を有するエレメントであって、サービスエントリーに該当し得る。ＳＬＴが指示するサービスの数（Ｎ）だけＳｅｒｖｉｃｅエレメントフィールドが存在し得る。以下、Ｓｅｒｖｉｃｅフィールドの下位属性／エレメントについて説明する。
【００７９】
＠ｓｅｒｖｉｃｅＩｄは、当該ブロードキャスト領域の範囲内で当該サービスを唯一に識別する整数であり得る。実施例によって、＠ｓｅｒｖｉｃｅＩｄのスコープ（ｓｃｏｐｅ）は変更されてもよい。＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは、ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤを有するＳＬＴサービス情報のシーケンスナンバーを示す整数であり得る。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ値は、各サービスに対して０から始まることができ、当該Ｓｅｒｖｉｃｅエレメントにおいてある属性が変化するたびに１ずつ増分することができる。ＳｅｒｖｉｃｅＩＤの特定の値を有する以前のサービスエレメントに比べていかなる属性値も変化しない場合、ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは増分しないはずである。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒフィールドは、最大値に到達した後、０にシフトされる。
【００８０】
＠ｐｒｏｔｅｃｔｅｄは、フラグ情報であって、当該サービスの有意義な再生のための１つまたはそれ以上のコンポーネントが保護された（ｐｒｏｔｅｃｔｅｄ）状態であるかを示すことができる。「１」（真）に設定されると、有意義なプレゼンテーションに必要な１つ以上のコンポーネントが保護される。「０」（偽）に設定されると、当該フラグは、サービスの有意義なプレゼンテーションに必要なコンポーネントが何にも保護されないことを示す。デフォルト値は偽である。
【００８１】
＠ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの「主」チャンネルナンバーを示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。
【００８２】
＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの「副」チャンネルナンバーを示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。
【００８３】
＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙは、当該サービスのカテゴリーを示すことができる。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２、３である場合、それぞれ当該サービスは、リニアＡ／Ｖサービス（Ｌｉｎｅａｒ  Ａ／Ｖ  ｓｅｒｖｉｃｅ）、リニアオーディオサービス（Ｌｉｎｅａｒ  ａｕｄｉｏ  ｏｎｌｙ  ｓｅｒｖｉｃｅ）、アプリベースのサービス（ａｐｐ−ｂａｓｅｄ  ｓｅｒｖｉｃｅ）に該当し得る。本フィールドの値が０である場合、定義されていないカテゴリーのサービスであり得、本フィールドの値が０、１、２、３以外の他の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅは、サービスのショートストリングネームであり得る。
【００８４】
＠ｈｉｄｄｅｎは、存在し、「真」に設定される場合、ブール値であり得、これは、サービスがテストや独占使用のためのものであり、通常のＴＶ受信機によっては選択されないことを示す。存在しない場合、デフォルト値は「偽」である。
【００８５】
＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅは、当該サービスによって使用されるＳＬＳのプロトコルのタイプを示す属性であり得る。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２である場合、それぞれ、当該サービスが使用するＳＬＳのプロトコルはＲＯＵＴＥ、ＭＭＴＰであり得る。本フィールドの値が０またはそれ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。本フィールドは、＠ｓｌｓＰｒｏｔｏｃｏｌと呼ぶこともできる。
【００８６】
ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ及びその下位属性／エレメントは、放送シグナリングと関連する情報を提供することができる。ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、ペアレントサービスエレメントのチャイルドエレメントであるＩｎｅｔＳｉｇＬｏｃが存在し得、その属性であるｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ ０ｘ００（ＵＲＬ  ｔｏ  ｓｉｇｎａｌｉｎｇ  ｓｅｒｖｅｒ）を含む。この場合、属性であるｕｒｌは、ｓｅｒｖｉｃｅ_ｉｄがペアレントサービスエレメントに対するｓｅｒｖｉｃｅｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ_ｉｄ＞を支援する。
【００８７】
または、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、エレメントＩｎｅｔＳｉｇＬｏｃはｓｌｔルートエレメントのチャイルドエレメントとして存在し得、ＩｎｅｔＳｉｇＬｏｃエレメントの属性ｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ ０ｘ００（ＵＲＬ  ｔｏ  ｓｉｇｎａｌｉｎｇ  ｓｅｒｖｅｒ）を含む。この場合、ＵＲＬ_ｔｙｐｅ０ｘ００に対する属性ｕｒｌは、ｓｅｒｖｉｃｅ_ｉｄがペアレントサービスエレメントのｓｅｒｖｉｃｅＩｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ_ｉｄ＞を支援する。
【００８８】
＠ｓｌｓＰｌｐＩｄは、当該サービスに対してＳＬＳを伝達するＰＬＰのＰＬＰ ＩＤを示す整数を表現するストリングであり得る。
【００８９】
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４デスティネーションアドレスを含むストリングであり得る。
【００９０】
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対してＳＬＳデータを伝達するパケットのポートナンバーを含むストリングであり得る。前述したように、デスティネーションＩＰ／ＵＤＰ情報によってＳＬＳブートストラッピングを行うことができる。
【００９１】
＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソースアドレスを含むストリングであり得る。
【００９２】
＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの主バージョンナンバーであり得る。デフォルト値は１である。
【００９３】
＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの副バージョンナンバーであり得る。デフォルト値は０である。
【００９４】
＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの主言語を示す３文字言語コードであり得る。本フィールド値の形式は、実施例によって変更されてもよい。
【００９５】
＠ｂｒｏａｄｂａｎｄｃｃｅｓｓＲｅｑｕｉｒｅｄは、受信機がサービスの有意義なプレゼンテーションを行うためにブロードバンドアクセスが必要であることを示すブール値であり得る。本フィールドの値がＴｒｕｅである場合、受信機は、有意義なサービス再生のためにブロードバンドにアクセスしなければならず、これは、サービスのハイブリッドデリバリーのケースに該当し得る。
【００９６】
＠ｃａｐａｂｉｌｉｔｉｅｓは、ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤであって、サービスに対する内容をデコーディングし、有意義に示すために要求されるケイパビリティを示すことができる。
【００９７】
ＩｎｅｔＳｉｇＬｏｃは、使用可能な場合、ブロードバンドを介してシグナリングや公知の情報に接続するためのＵＲＬを提供することができる。そのデータタイプは、ＵＲＬがどこにアクセスするかを示す＠ｕｒｌＴｙｐｅ属性を追加する全てのＵＲＬデータタイプの拡張であり得る。本フィールドの＠ｕｒｌＴｙｐｅフィールドが意味することは、前述したＩｎｅｔＳｉｇＬｏｃの＠ｕｒｌＴｙｐｅフィールドが意味することと同一であり得る。属性ＵＲＬ_ｔｙｐｅ ０ｘ００のＩｎｅｔＳｉｇＬｏｃエレメントがＳＬＴのエレメントとして存在する場合、それは、シグナリングメタデータに対してＨＴＴＰ要請を行うために使用され得る。このＨＴＴＰ ＰＯＳＴメッセージボディーにはサービスタームが含まれてもよい。ＩｎｅｔＳｉｇＬｏｃエレメントがセクションレベルで現れる場合、サービスタームは、要請されたシグナリングメタデータオブジェクトが適用されるサービスを示すために使用される。サービスタームが存在しない場合、当該セクションの全てのサービスに対するシグナリングメタデータオブジェクトが要請される。ＩｎｅｔＳｉｇＬｏｃがサービスレベルで現れる場合、所望のサービスを指定するために必要なサービスタームがない。属性ＵＲＬ_ｔｙｐｅ ０ｘ０１のＩｎｅｔＳｉｇＬｏｃエレメントが提供されると、それは、ブロードバンドを介してＥＳＧデータを検索するのに使用することができる。当該エレメントがサービスエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該サービスに対してデータを検索するのに使用することができる。当該エレメントがＳＬＴエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該セクションで全てのサービスに対するＥＳＧデータを検索するのに使用することができる。
【００９８】
ＳＬＴの他の実施例において、ＳＬＴの＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ及び／又は＠ｌａｎｇｕａｇｅフィールドは省略されてもよい。
【００９９】
また、前述したＩｎｅｔＳｉｇＬｏｃフィールドは、＠ｓｌｔＩｎｅｔＳｉｇＵｒｉ及び／又は＠ｓｌｔＩｎｅｔＥｓｇＵｒｉフィールドに代替されてもよい。２つのフィールドは、それぞれシグナリングサーバーのＵＲＩ、ＥＳＧサーバーのＵＲＩ情報を含むことができる。ＳＬＴの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールド及びＳｅｒｖｉｃｅの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールドは、いずれも、前記のような方法で代替されてもよい。
【０１００】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、１は、当該フィールドが必須のフィールドであり、０..１は、当該フィールドがオプショナルフィールドであることを意味し得る。
【０１０１】
図４は、本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリー過程を示した図である。
【０１０２】
以下、サービスレイヤシグナリング（ＳＬＳ、Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【０１０３】
ＳＬＳは、サービス及びそのコンテンツコンポーネントを発見し、獲得するための情報を提供するシグナリングであり得る。
【０１０４】
ＲＯＵＴＥ／ＤＡＳＨについて、各サービスに対するＳＬＳは、コンポーネントのリスト、どこでそれらを獲得できるのか、サービスの有意義なプレゼンテーションのために要求される受信機の性能のようなサービスの特性を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、ＳＬＳは、ＵＳＢＤ（ｕｓｅｒ  ｓｅｒｖｉｃｅ  ｂｕｎｄｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ、ＤＡＳＨ ＭＰＤ（ｍｅｄｉａ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｓｃｒｉｐｔｉｏｎ）を含む。ここで、ＵＳＢＤまたはＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、ＳＬＳ ＸＭＬフラグメントのうちの１つであって、サービスの具体的な技術的情報を記述するシグナリングハブとしての役割を果たすことができる。このＵＳＢＤ／ＵＳＤは、３ＧＰＰ ＭＢＭＳで定義されたことよりもさらに拡張されてもよい。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。
【０１０５】
サービスシグナリングは、サービス自体の基本属性、特に、サービスを獲得するために必要な属性に焦点を置く。視聴者のためのサービス及びプログラミングの特徴は、サービスの公知またはＥＳＧデータとして現れる。
【０１０６】
各サービスに対して別個のサービスシグナリングを有する場合、受信機は、ブロードキャストストリーム内で伝達される全ＳＬＳをパーシングすることなく所望のサービスに対する適切なＳＬＳを獲得すればよい。
【０１０７】
サービスシグナリングの選択的なブロードバンドデリバリーに対して、ＳＬＴは、前述したように、サービスシグナリングファイルが獲得され得るＨＴＴＰ ＵＲＬを含むことができる。
【０１０８】
ＬＬＳは、ＳＬＳ獲得をブートストラップするのに使用され、その後、ＳＬＳは、ＲＯＵＴＥセッションまたはＭＭＴＰセッションで伝達されるサービスコンポーネントを獲得するのに使用される。記述された図面は、次のシグナリングシーケンスを示す。受信機は、前述したＳＬＴを獲得し始める。ＲＯＵＴＥセッションで伝達されるｓｅｒｖｉｃｅ_ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃１）、ソースＩＰアドレス（ｓＩＰ１）、デスティネーションＩＰアドレス（ｄＩＰ１）、及びデスティネーションポートナンバー（ｄＰｏｒｔ１）のようなＳＬＳブートストラッピング情報を提供する。ＭＭＴＰセッションで伝達されるｓｅｒｖｉｃｅ_ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃２）、デスティネーションＩＰアドレス（ｄＩＰ２）、及びデスティネーションポートナンバー（ｄＰｏｒｔ２）のようなＳＬＳブートストラッピング情報を提供する。
【０１０９】
ＲＯＵＴＥを用いたストリーミングサービスデリバリーに対して、受信機は、ＰＬＰ及びＩＰ／ＵＤＰ／ＬＣＴセッションで伝達されるＳＬＳ分割を獲得することができる。反面、ＭＭＴＰを用いたストリーミングサービスデリバリーに対して、受信機は、ＰＬＰ及びＭＭＴＰセッションで伝達されるＳＬＳ分割を獲得することができる。ＲＯＵＴＥを用いたサービスデリバリーに対して、これらＳＬＳ分割は、ＵＳＢＤ／ＵＳＤ分割、Ｓ−ＴＳＩＤ分割、ＭＰＤ分割を含む。それらは一つのサービスと関連がある。ＵＳＢＤ／ＵＳＤ分割は、サービスレイヤの特性を記述し、Ｓ−ＴＳＩＤ分割に対するＵＲＩレファレンス及びＭＰＤ分割に対するＵＲＩレファレンスを提供する。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれ参照することができる。ＭＭＴＰを用いたサービスデリバリーに対して、ＵＳＢＤは、ＭＭＴシグナリングのＭＭＴメッセージを参照し、それのＭＰテーブルは、サービスに属するアセット（ａｓｓｅｔ）のための位置情報及びパッケージＩＤの識別を提供する。ここで、Ａｓｓｅｔとは、マルチメディアデータエンティティーであって、一つのユニークなＩＤに連合され、一つのマルチメディアプレゼンテーションを生成するのに使用されるデータエンティティーを意味し得る。Ａｓｓｅｔは、一つのサービスを構成するサービスコンポーネントに該当し得る。ＭＰＴメッセージは、ＭＭＴのＭＰテーブルを有するメッセージであり、ここで、ＭＰテーブルは、ＭＭＴ Ａｓｓｅｔとコンテンツに関する情報を有する、ＭＭＴパッケージテーブル（ＭＭＴ  Ｐａｃｋａｇｅ  Ｔａｂｌｅ）であり得る。具体的な内容は、ＭＭＴで定義された通りである。ここで、メディアプレゼンテーションとは、メディアコンテンツのバウンド／アンバウンドされたプレゼンテーションを成立させるデータのコレクションであり得る。
【０１１０】
Ｓ−ＴＳＩＤ分割は、一つのサービスと関連するコンポーネント獲得情報と、当該サービスのコンポーネントに該当するＴＳＩ及びＭＰＤで発見されるＤＡＳＨ表現との間のマッピングを提供する。Ｓ−ＴＳＩＤは、ＴＳＩ及び関連するＤＡＳＨ表現識別子の形態のコンポーネント獲得情報、及びＤＡＳＨ表現と関連するＤＡＳＨ分割を伝達するＰＬＰＩＤを提供することができる。ＰＬＰＩＤ及びＴＳＩ値によって、受信機は、サービスからオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディア分割のバッファリングを開始した後、適切なデコーディング過程を適用する。
【０１１１】
ＭＭＴＰセッションで伝達されるＵＳＢＤリスティングサービスコンポーネントに対して、記述された図面の「Ｓｅｒｖｉｃｅ ＃２」に示したように、受信機は、ＳＬＳを完了するためにマッチングされるＭＭＴ_ｐａｃｋａｇｅ_ｉｄを有するＭＰＴメッセージを獲得する。ＭＰＴメッセージは、各コンポーネントに対する獲得情報及びサービスを含むサービスコンポーネントの完全なリストを提供する。コンポーネント獲得情報は、ＭＭＴＰセッション情報、当該セッションを伝達するＰＬＰＩＤ、当該セッション内のｐａｃｋｅｔ_ｉｄを含む。
【０１１２】
実施例によって、例えば、ＲＯＵＴＥの場合、２つ以上のＳ−ＴＳＩＤフラグメントが使用されてもよい。それぞれのフラグメントは、各サービスのコンテンツを伝達するＬＣＴセッションに対するアクセス情報を提供することができる。
【０１１３】
ＲＯＵＴＥの場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ、またはこれらを伝達するＬＣＴセッションをサービスシグナリングチャンネルと呼ぶこともできる。ＭＭＴＰの場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、またはこれらを伝達するパケットフローをサービスシグナリングチャンネルと呼ぶこともできる。
【０１１４】
図示された実施例とは異なり、一つのＲＯＵＴＥまたはＭＭＴＰセッションは複数個のＰＬＰを介して伝達され得る。すなわち、一つのサービスは一つ以上のＰＬＰを介して伝達されてもよい。前述したように、一つのＬＣＴセッションは一つのＰＬＰを介して伝達され得る。図示されたものとは異なり、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＲＯＵＴＥセッションを介して伝達されてもよい。また、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＭＭＴＰセッションを介して伝達されてもよい。実施例によって、一つのサービスを構成するコンポーネントが、ＲＯＵＴＥセッションとＭＭＴＰセッションとに分けられて伝達されてもよい。図示してはいないが、一つのサービスを構成するコンポーネントが、ブロードバンドを介して伝達（ハイブリッドデリバリー）される場合もあり得る。
【０１１５】
図５は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。
【０１１６】
以下、ＲＯＵＴＥに基づいたデリバリーにおいて、サービスレイヤシグナリングについて説明する。
【０１１７】
ＳＬＳは、サービス及びそのコンテンツコンポーネントの発見及び接近を可能にするために、受信機に、具体的な技術的な情報を提供する。それは、専用ＬＣＴセッションで伝達されるＸＭＬコーディングされたメタデータ分割の集合を含むことができる。当該ＬＣＴセッションは、前述したように、ＳＬＴに含まれたブートストラップ情報を用いて獲得することができる。ＳＬＳは、サービスレベル毎に定義され、それは、コンテンツコンポーネントのリスト、どのようにそれらを獲得するのか、サービスの有意義なプレゼンテーションを行うために要求される受信機の性能のようなサービスのアクセス情報及び特徴を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、リニアサービスデリバリーのために、ＳＬＳは、ＵＳＢＤ、Ｓ−ＴＳＩＤ及びＤＡＳＨ ＭＰＤのようなメタデータ分割で構成される。ＳＬＳ分割は、ＴＳＩ＝０である専用のＬＣＴ伝送セッションで伝達され得る。実施例によって、ＳＬＳフラグメントが伝達される特定のＬＣＴセッション（ｄｅｄｉｃａｔｅｄ  ＬＣＴ  ｓｅｓｓｉｏｎ）のＴＳＩは、異なる値を有してもよい。実施例によって、ＳＬＳフラグメントが伝達されるＬＣＴセッションが、ＳＬＴまたは他の方法によってシグナリングされてもよい。
【０１１８】
ＲＯＵＴＥ／ＤＡＳＨ ＳＬＳは、ＵＳＢＤ及びＳ−ＴＳＩＤメタデータ分割を含むことができる。これらサービスシグナリング分割は、リニア及びアプリケーションに基づいたサービスに適用され得る。ＵＳＢＤ分割は、サービス識別、装置性能情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ分割に対する参照、受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＳ−ＴＳＩＤ分割は、サービスのメディアコンテンツコンポーネントが伝達される１つ以上のＲＯＵＴＥ／ＬＣＴセッションに対する伝送セッションディスクリプション、及び当該ＬＣＴセッションで伝達されるデリバリーオブジェクトのディスクリプションを提供する。ＵＳＢＤ及びＳ−ＴＳＩＤは後述する。
【０１１９】
ＲＯＵＴＥに基づいたデリバリーにおけるＳｔｒｅａｍｉｎｇ Ｃｏｎｔｅｎｔ Ｓｉｇｎａｌｉｎｇにおいて、ＳＬＳのストリーミングコンテンツシグナリングコンポーネントはＭＰＤフラグメントに該当する。ＭＰＤは、主にストリーミングコンテンツとしてのＤＡＳＨ分割のデリバリーのためのリニアサービスと関連する。ＭＰＤは、分割ＵＲＬの形態のリニア／ストリーミングサービスの個別メディアコンポーネントに対するソース識別子、及びメディアプレゼンテーション内の識別されたリソースのコンテキストを提供する。ＭＰＤについての具体的な内容は後述する。
【０１２０】
ＲＯＵＴＥに基づいたデリバリーにおけるアプリベースのエンハンスメントシグナリングにおいて、アプリベースのエンハンスメントシグナリングは、アプリケーションロジックファイル、局部的にキャッシュされたメディアファイル、ネットワークコンテンツアイテム、または公知のストリームのようなアプリベースのエンハンスメントコンポーネントのデリバリーに属する。アプリケーションはまた、可能な場合、ブロードバンドコネクション上で局部的にキャッシュされたデータを検索することができる。
【０１２１】
以下、本図に示されたＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
【０１２２】
トップレベルまたはエントリーポイントＳＬＳ分割はＵＳＢＤ分割である。図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
【０１２３】
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、一つのサービスに対するインスタンスであり得る。
【０１２４】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓ、＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉ、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄを含むことができる。
【０１２５】
＠ｓｅｒｖｉｃｅＩｄは、ＢＳＩＤの範囲内で唯一のサービスを識別する全世界的に唯一のＵＲＩであり得る。当該パラメータは、ＥＳＧデータ（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）とリンクするのに使用することができる。
【０１２６】
＠ａｔｓｃ：ｓｅｒｖｉｃｅｄは、ＬＬＳ（ＳＬＴ）において該当するサービスエントリーに対するレファレンスである。当該属性の値は、当該エントリーに割り当てられたｓｅｒｖｉｃｅＩｄの値と同一である。
【０１２７】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓは、当該サービスの状態を特定することができる。その値は、当該サービスが活性化されているか、または非活性化されているかを示す。「１」（真）に設定されると、サービスが活性化されていることを示す。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
【０１２８】
＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉは、ブロードキャスト上で選択的に、また、ブロードバンド上で伝達されるサービスのコンテンツコンポーネントに対するディスクリプションを含むＭＰＤ分割を参照することができる。
【０１２９】
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤ分割を参照することができる。
【０１３０】
ｎａｍｅは、ｌａｎｇ属性によって与えられるサービスのネームを示すことができる。ｎａｍｅエレメントは、サービスネームの言語を示すｌａｎｇ属性を含むことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
【０１３１】
ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの利用可能な言語を示すことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
【０１３２】
ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、受信機が当該サービスのコンテンツの有意義なプレゼンテーションを生成できるように要求されるケイパビリティを特定することができる。実施例によって、本フィールドは、予め定義されたケイパビリティグループを特定してもよい。ここで、ケイパビリティグループは、有意義なプレゼンテーションのためのケイパビリティ属性値のグループであり得る。本フィールドは、実施例によって省略されてもよい。
【０１３３】
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄは、アクセスのブロードキャスト及び（選択的に）ブロードバンドモード上でサービスのコンテンツに属する情報に関連するトランスポートのコンテナであり得る。当該サービスに含まれるデータにおいて、そのデータをＮ個とすれば、そのそれぞれのデータに対するデリバリー方法が、このエレメントによって記述され得る。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及びｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。それぞれの下位エレメントは、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。
【０１３４】
ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する当該メディアコンポーネントを含む、多重化または非多重化された形態のブロードキャスト上で伝達されるＤＡＳＨレプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、放送網を介して伝達されるＤＡＳＨレプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
【０１３５】
ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する構成メディアコンテンツコンポーネントを含む、多重化または非多重化された形態のブロードバンド上で伝達されるＤＡＳＨレプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、ブロードバンドを介して伝達されるＤＡＳＨレプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
【０１３６】
ｂａｓｅＰａｔｔｅｒｎは、含まれた期間にペアレントレプレゼンテーションのメディア分割を要求するためにＤＡＳＨクライアントによって使用される分割ＵＲＬの全ての部分に対してマッチングされるように受信機によって使用される文字パターンであり得る。マッチは、当該要求されたメディア分割がブロードキャストトランスポート上で伝達されることを暗示する。それぞれのｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントとｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで表現されるＤＡＳＨレプレゼンテーションを受信できるＵＲＬアドレスにおいて、そのＵＲＬの一部分などは特定のパターンを有することができ、そのパターンが本フィールドによって記述され得る。この情報を通じて、一定の部分のデータに対する区分が可能である。提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０１３７】
図６は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。
【０１３８】
以下、本図に示されたＳ−ＴＳＩＤの具体的な内容について説明する。
【０１３９】
Ｓ−ＴＳＩＤは、サービスのコンテンツコンポーネントを伝達する伝送セッションに対する全体的なセッションディスクリプション情報を提供するＳＬＳ ＸＭＬ分割であり得る。Ｓ−ＴＳＩＤは、サービスのメディアコンテンツコンポーネントが伝達される構成ＬＣＴセッション、及び０個以上のＲＯＵＴＥセッションに対する全体的な伝送セッションディスクリプション情報を含む、ＳＬＳメタデータ分割である。Ｓ−ＴＳＩＤはまた、ＬＣＴセッションで伝達されるコンテンツコンポーネント及びペイロードフォーマットに対する追加情報だけでなく、サービスのＬＣＴセッションで伝達されるデリバリーオブジェクトまたはオブジェクトフローに対するファイルメタデータを含む。
【０１４０】
Ｓ−ＴＳＩＤ分割の各インスタンスは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントの＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ属性によってＵＳＢＤ分割で参照される。図示された本発明の一実施例に係るＳ−ＴＳＩＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、Ｓ−ＴＳＩＤは、バイナリフォーマットまたはＸＭＬドキュメントの形態で表現されてもよい。
【０１４１】
図示されたＳ−ＴＳＩＤは、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ及び／又はＲＳを含むことができる。
【０１４２】
＠ｓｅｒｖｉｃｅＩＤは、ＵＳＤでサービスエレメントに該当するレファレンスであり得る。当該属性の値は、ｓｅｒｖｉｃｅ_ｉｄの当該値を有するサービスを参照することができる。
【０１４３】
ＲＳエレメントは、当該サービスデータを伝達するＲＯＵＴＥセッションに関する情報を有することができる。複数個のＲＯＵＴＥセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは１個〜Ｎ個の個数を有することができる。
【０１４４】
ＲＳエレメントは、＠ｂｓｉｄ、＠ｓＩｐＡｄｄｒ、＠ｄＩｐＡｄｄｒ、＠ｄｐｏｒｔ、＠ＰＬＰＩＤ及び／又はＬＳを含むことができる。
【０１４５】
＠ｂｓｉｄは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのコンテンツコンポーネントが伝達されるブロードキャストストリームの識別子であり得る。当該属性が存在しない場合、デフォルトブロードキャストストリームのＰＬＰが当該サービスに対するＳＬＳ分割を伝達することであり得る。その値は、ＳＬＴでｂｒｏａｄｃａｓｔ_ｓｔｒｅａｍ_ｉｄと同一であり得る。
【０１４６】
＠ｓＩｐＡｄｄｒは、ソースＩＰアドレスを示すことができる。ここで、ソースＩＰアドレスは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのソースＩＰアドレスであり得る。前述したように、一つのサービスのサービスコンポーネントは、複数個のＲＯＵＴＥセッションを介して伝達されてもよい。そのため、当該Ｓ−ＴＳＩＤが伝達されるＲＯＵＴＥセッションではない他のＲＯＵＴＥセッションでそのサービスコンポーネントが伝送されてもよい。したがって、ＲＯＵＴＥセッションのソースＩＰアドレスを指示するために本フィールドが使用され得る。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのソースＩＰアドレスであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのソースＩＰアドレス値であり得る。この場合、本フィールドはＭ、すなわち、必須のフィールドであり得る。
【０１４７】
＠ｄＩｐＡｄｄｒは、デスティネーションＩＰアドレスを示すことができる。ここで、デスティネーションＩＰアドレスは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションＩＰアドレスであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションＩＰアドレスを指示してもよい。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのデスティネーションＩＰアドレスであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのデスティネーションＩＰアドレス値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。
【０１４８】
＠ｄｐｏｒｔは、デスティネーションポートを示すことができる。ここで、デスティネーションポートは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションポートであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションのデスティネーションポートを指示することができる。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのデスティネーションポートナンバーであり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのデスティネーションポートナンバー値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。
【０１４９】
＠ＰＬＰＩＤは、ＲＳで表現されるＲＯＵＴＥセッションのためのＰＬＰのＩＤであり得る。デフォルト値は、現在のＳ−ＴＳＩＤが含まれたＬＣＴセッションのＰＬＰのＩＤであり得る。実施例によって、本フィールドは、当該ＲＯＵＴＥセッションでＳ−ＴＳＩＤが伝達されるＬＣＴセッションのためのＰＬＰのＩＤ値を有してもよく、当該ＲＯＵＴＥセッションのための全てのＰＬＰのＩＤ値を有してもよい。
【０１５０】
ＬＳエレメントは、当該サービスデータを伝達するＬＣＴセッションに関する情報を有することができる。複数個のＬＣＴセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは、１個〜Ｎ個の個数を有することができる。
【０１５１】
ＬＳエレメントは、＠ｔｓｉ、＠ＰＬＰＩＤ、＠ｂｗ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅ、ＳｒｃＦｌｏｗ及び／又はＲｐｒＦｌｏｗを含むことができる。
【０１５２】
＠ｔｓｉは、当該サービスのサービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ値を指示することができる。
【０１５３】
＠ＰＬＰＩＤは、当該ＬＣＴセッションのためのＰＬＰのＩＤ情報を有することができる。この値は、基本ＲＯＵＴＥセッション値を上書きしてもよい。
【０１５４】
＠ｂｗは、最大の帯域値を指示することができる。＠ｓｔａｒｔＴｉｍｅは当該ＬＣＴセッションのスタートタイム（Ｓｔａｒｔ  ｔｉｍｅ）を指示することができる。＠ｅｎｄＴｉｍｅは、当該ＬＣＴセッションのエンドタイム（Ｅｎｄ  ｔｉｍｅ）を指示することができる。ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローに対して記述することができる。ＲｐｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアフローに対して記述することができる。
【０１５５】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須フィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０１５６】
以下、ＲＯＵＴＥ／ＤＡＳＨのためのＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
【０１５７】
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＤＡＳＨメディアプレゼンテーションの公式化されたディスクリプションを含むＳＬＳメタデータ分割である（例えば、ある期間の間の一つのＴＶプログラムまたは連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、メディアプレゼンテーション内で識別されたリソースに対するコンテキスト及び分割に対するソース識別子を提供する。ＭＰＤ分割のデータ構造及びセマンティクスは、ＭＰＥＧ ＤＡＳＨによって定義されたＭＰＤに従うことができる。
【０１５８】
ＭＰＤで伝達される１つ以上のＤＡＳＨレプレゼンテーションは、ブロードキャスト上で伝達され得る。ＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達される追加レプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、トンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
【０１５９】
図７は、本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。
【０１６０】
リニアサービスのためのＭＭＴ ＳＬＳは、ＵＳＢＤ分割及びＭＰテーブルを含む。ＭＰテーブルは、前述した通りである。ＵＳＢＤ分割は、サービス識別、装置性能情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ分割に対する参照、及び受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＭＰＵコンポーネントに対するＭＰテーブルは、サービスのメディアコンテンツコンポーネントが伝達されるＭＭＴＰセッションに対する伝送セッションディスクリプション、及びＭＭＴＰセッションで伝達されるアセットのディスクリプションを提供する。
【０１６１】
ＭＰＵコンポーネントに対するＳＬＳのストリーミングコンテンツシグナリングコンポーネントは、ＭＭＴで定義されたＭＰテーブルに該当する。ＭＰテーブルは、各アセットが単一のサービスコンポーネントに該当するＭＭＴアセットのリスト、及び当該コンポーネントに対する位置情報のディスクリプションを提供する。
【０１６２】
ＵＳＢＤ分割は、ＲＯＵＴＥプロトコル及びブロードバンドによってそれぞれ伝達されるサービスコンポーネントに対して、前述したようなＳ−ＴＳＩＤ及びＭＰＤに対する参照も含むことができる。実施例によって、ＭＭＴを通じたデリバリーにおいて、ＲＯＵＴＥプロトコルを介して伝達されるサービスコンポーネントはＮＲＴなどのデータであるので、この場合において、ＭＰＤは用いられなくてもよい。また、ＭＭＴを通じたデリバリーにおいて、ブロードバンドを介して伝達されるサービスコンポーネントはどのＬＣＴセッションを介して伝達されるかに対する情報が必要でないので、Ｓ−ＴＳＩＤは用いられなくてもよい。ここで、ＭＭＴパッケージは、ＭＭＴを用いて伝達される、メディアデータの論理的コレクションであり得る。ここで、ＭＭＴＰパケットは、ＭＭＴを用いて伝達されるメディアデータのフォーマットされたユニットを意味し得る。ＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）は、独立してデコーディング可能なタイムド／ノン−タイムドデータのジェネリックコンテナを意味し得る。ここで、ＭＰＵでのデータはメディアコーデックアグノスティックである。
【０１６３】
以下、本図に示されたＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
【０１６４】
図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
【０１６５】
図示された本発明の一実施例に係るＵＳＢＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、ＵＳＢＤは、バイナリフォーマットまたはＸＭＬドキュメントの形態で表現されてもよい。
【０１６６】
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであり得る。
【０１６７】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ、ａｔｓｃ：Ｃｈａｎｎｅｌ、ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｂｒｏａｄｂａｎｄ Ｃｏｍｐｏｎｅｎｔ及び／又はａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏを含むことができる。
【０１６８】
ここで、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、前述したものと同一であり得る。ｎａｍｅフィールドの下のｌａｎｇフィールドも、前述したものと同一であり得る。ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、実施例によって省略されてもよい。
【０１６９】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、実施例によってａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントをさらに含むことができる。このエレメントはオプショナルエレメントであり得る。ａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇは、コンテンツ諮問順位を特定することができる。本フィールドは図示していない。
【０１７０】
ａｔｓｃ：Ｃｈａｎｎｅｌは、サービスのチャンネルに対する情報を有することができる。ａｔｓｃ：Ｃｈａｎｎｅｌエレメントは、＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎ及び／又はａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎを含むことができる。＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、実施例によって省略されてもよい。
【０１７１】
＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの主チャンネルナンバーを示す属性である。
【０１７２】
＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの副チャンネルナンバーを示す属性である。
【０１７３】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、サービスで使用される主要言語を示す属性である。
【０１７４】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅは、サービスの主要ジャンルを示す属性である。
【０１７５】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎは、当該サービスを表現するために使用されるアイコンに対するＵＲＬを示す属性である。
【０１７６】
ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、サービスディスクリプションを含み、これは多重言語であってもよい。ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ及び／又は＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇを含むことができる。
【０１７７】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔは、サービスのディスクリプションを示す属性である。
【０１７８】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇは、ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性の言語を示す属性である。
【０１７９】
ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、ＭＰＵの形態で伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄ及び／又は＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄを含むことができる。
【０１８０】
＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに対するＭＭＴパッケージを参照することができる。
【０１８１】
＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに合わせて＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄによって参照された後に使用されるＭＭＴパッケージを参照することができる。
【０１８２】
ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、ＲＯＵＴＥを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、＠ｓＴＳＩＤＰｌｐＩｄ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを含むことができる。
【０１８３】
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤ分割を参照することができる。このフィールドは、前述したＲＯＵＴＥのためのＵＳＢＤでのＳ−ＴＳＩＤを参照するためのＵＲＩと同一であり得る。前述したように、ＭＭＴＰによるサービスデリバリーにおいても、ＮＲＴなどを介して伝達されるサービスコンポーネントはＲＯＵＴＥによって伝達され得る。そのためのＳ−ＴＳＩＤを参照するために、本フィールドが使用され得る。
【０１８４】
＠ｓＴＳＩＤＰｌｐＩｄは、当該サービスに対するＳ−ＴＳＩＤを伝達するＰＬＰのＰＬＰ ＩＤを示す整数を表現するストリングであり得る。（デフォルト：現在のＰＬＰ）
【０１８５】
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４デスティネーションアドレスを含むストリングであり得る。（デフォルト：現在のＭＭＴＰセッションのソースＩＰアドレス）
【０１８６】
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのポートナンバーを含むストリングであり得る。
【０１８７】
＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソースアドレスを含むストリングであり得る。
【０１８８】
＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの主バージョンナンバーを示すことができる。デフォルト値は１である。
【０１８９】
＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの副バージョンナンバーを示すことができる。デフォルト値は０である。
【０１９０】
ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、ブロードバンドを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。すなわち、ハイブリッドデリバリーを想定したフィールドであり得る。ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉをさらに含むことができる。
【０１９１】
＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉは、ブロードバンドで伝達されるサービスのコンテンツコンポーネントに対するディスクリプションを含むＭＰＤ分割に対するレファレンスであり得る。
【０１９２】
ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、サービスのアベイラブルな（ａｖａｉｌａｂｌｅ）コンポーネントに対する情報を有することができる。それぞれのコンポーネントに対する、タイプ、ロール、名などの情報を有することができる。各コンポーネント（Ｎ個）の数だけ本フィールドが存在することができる。ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄ及び／又は＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅを含むことができる。
【０１９３】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅは、当該コンポーネントのタイプを示す属性である。０の値はオーディオコンポーネントを示す。１の値はビデオコンポーネントを示す。２の値はクローズドキャプションコンポーネントを示す。３の値はアプリケーションコンポーネントを示す。４〜７の値は残す。本フィールド値の意味は、実施例によって異なって設定されてもよい。
【０１９４】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅは、当該コンポーネントの役割及び種類を示す属性である。
【０１９５】
オーディオに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が０と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｃｏｍｐｌｅｔｅ ｍａｉｎ、１＝音楽及び効果（Ｍｕｓｉｃ  ａｎｄ  Ｅｆｆｅｃｔｓ）、２＝対話（Ｄｉａｌｏｇ）、３＝解説（Ｃｏｍｍｅｎｔａｒｙ）、４＝視覚障害（Ｖｉｓｕａｌｌｙ  Ｉｍｐａｉｒｅｄ）、５＝聴覚障害（Ｈｅａｒｉｎｇ  Ｉｍｐａｉｒｅｄ）、６＝ボイスオーバー（Ｖｏｉｃｅ−Ｏｖｅｒ）、７−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１９６】
オーディオに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が１と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｐｒｉｍａｒｙ ｖｉｄｅｏ、１＝代替カメラビュー（Ａｌｔｅｒｎａｔｉｖｅ  ｃａｍｅｒａ  ｖｉｅｗ）、２＝他の代替ビデオコンポーネント（Ｏｔｈｅｒ  ａｌｔｅｒｎａｔｉｖｅ  ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）、３＝手話挿入（Ｓｉｇｎ  ｌａｎｇｕａｇｅ  ｉｎｓｅｔ）、４＝Ｆｏｌｌｏｗ ｓｕｂｊｅｃｔ ｖｉｄｅｏ、５＝３Ｄビデオの左側ビュー（３Ｄ  ｖｉｄｅｏ  ｌｅｆｔ  ｖｉｅｗ）、６＝３Ｄビデオの右側ビュー（３Ｄ  ｖｉｄｅｏ  ｒｉｇｈｔ  ｖｉｅｗ）、７＝３Ｄビデオの深さ情報（３Ｄ  ｖｉｄｅｏ  ｄｅｐｔｈ  ｉｎｆｏｒｍａｔｉｏｎ）、８＝Ｐａｒｔ ｏｆ ｖｉｄｅｏ ａｒｒａｙ ＜ｘ，ｙ＞ ｏｆ ＜ｎ，ｍ＞、９＝Ｆｏｌｌｏｗ−Ｓｕｂｊｅｃｔ ｍｅｔａｄａｔａ、１０−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１９７】
クローズドキャプションコンポーネントに対して（ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が２と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｎｏｒｍａｌ、１＝Ｅａｓｙ ｒｅａｄｅｒ、２−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１９８】
ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性の値が３と７との間であれば、ｃｏｍｐｏｎｅｎｔＲｏｌｅ２５５と同一であり得る。本フィールド値の意味は、実施例によって異なって設定されてもよい。
【０１９９】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇは、当該コンポーネントが保護されるか（例えば、暗号化されるか）を示す属性である。当該フラグが１の値に設定されると、当該コンポーネントは保護される（例えば、暗号化される）。当該フラグが０の値に設定されると、当該コンポーネントは保護されない（例えば、暗号化されない）。存在しない場合、ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性の値は０と同一であると推論される。本フィールド値の意味は、実施例によって異なって設定されてもよい。
【０２００】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄは、当該コンポーネントの識別子を示す属性である。当該属性の値は、当該コンポーネントに該当するＭＰテーブルにおいてａｓｓｅｔ_ｉｄと同一であり得る。
【０２０１】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅは、当該コンポーネントの人が読み取り可能な名を示す属性である。
【０２０２】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０２０３】
以下、ＭＭＴのためのＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
【０２０４】
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＳＬＳメタデータ分割である（例えば、一つのＴＶプログラム、またはある期間の間の連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、分割に対するリソース識別子、及びメディアプレゼンテーション内で識別されたリソースに対するコンテキストを提供する。ＭＰＤのデータ構造及びセマンティクスは、ＭＰＥＧ ＤＡＳＨによって定義されたＭＰＤに従うことができる。
【０２０５】
本発明の実施例において、ＭＭＴＰセッションによって伝達されるＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達されるレプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、山の下やトンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
【０２０６】
以下、ＭＭＴのためのＭＭＴシグナリングメッセージについて説明する。
【０２０７】
ＭＭＴＰセッションがストリーミングサービスを伝達するために使用される場合、ＭＭＴによって定義されたＭＭＴシグナリングメッセージは、ＭＭＴによって定義されたシグナリングメッセージモードに応じてＭＭＴＰパケットによって伝達される。アセットを伝達するＭＭＴＰパケットと同一のｐａｃｋｅｔ_ｉｄ値に設定され得る、アセットに特定のＭＭＴシグナリングメッセージを伝達するＭＭＴＰパケットを除いて、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ_ｉｄフィールドの値は「００」に設定される。各サービスに対する適切なパケットを参照する識別子は、前述したように、ＵＳＢＤ分割によってシグナリングされる。マッチングするＭＭＴ_ｐａｃｋａｇｅ_ｉｄを有するＭＰＴメッセージは、ＳＬＴでシグナリングされるＭＭＴＰセッション上で伝達され得る。各ＭＭＴＰセッションは、そのセッションに特定のＭＭＴシグナリングメッセージ、またはＭＭＴＰセッションによって伝達される各アセットを伝達する。
【０２０８】
すなわち、ＳＬＴで特定のサービスに対するＳＬＳを有するパケットのＩＰデスティネーションアドレス／ポートナンバーなどを特定して、ＭＭＴＰセッションのＵＳＢＤに接近することができる。前述したように、ＳＬＳを運搬するＭＭＴＰパケットのパケットＩＤは、００などの特定の値として指定できる。ＵＳＢＤの前述したパッケージＩＤ情報を用いて、マッチングされるパッケージＩＤを有するＭＰＴメッセージに接近することができる。ＭＰＴメッセージは、後述するように、各サービスコンポーネント／アセットに接近するために使用することができる。
【０２０９】
次のＭＭＴＰメッセージは、ＳＬＴでシグナリングされるＭＭＴＰセッションによって伝達され得る。
【０２１０】
ＭＰＴメッセージ：このメッセージは、全てのアセットのリスト及びＭＭＴによって定義されたようなそれらの位置情報を含む、ＭＰテーブルを伝達する。アセットがＭＰテーブルを伝達する現ＰＬＰと異なるＰＬＰによって伝達されると、当該アセットを伝達するＰＬＰの識別子は、ＰＬＰ識別子ディスクリプタを使用したＭＰテーブルで提供され得る。ＰＬＰ識別子ディスクリプタについては後述する。
【０２１１】
ＭＭＴ ＡＴＳＣ３（ＭＡ３） ｍｅｓｓａｇｅ ｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）：このメッセージは、前述したように、ＳＬＳを含むサービスに特定のシステムメタデータを伝達する。ｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）については後述する。
【０２１２】
次のＭＭＴＰメッセージは、必要であれば、ＳＬＴでシグナリングされたＭＭＴＰセッションによって伝達されてもよい。
【０２１３】
ＭＰＩメッセージ：このメッセージは、プレゼンテーション情報の全てのドキュメントまたは一部のドキュメントを含む、ＭＰＩテーブルを伝達する。ＭＰＩテーブルと関連するＭＰテーブルは、このメッセージによって伝達され得る。
【０２１４】
ＣＲＩ（ｃｌｏｃｋ  ｒｅｌａｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）メッセージ：このメッセージは、ＮＴＰタイムスタンプとＭＰＥＧ−２ ＳＴＣとの間のマッピングのためのクロック関連情報を含むＣＲＩテーブルを伝達する。実施例によって、ＣＲＩメッセージは当該ＭＭＴＰセッションを介して伝達されなくてもよい。
【０２１５】
次のＭＭＴＰメッセージは、ストリーミングコンテンツを伝達する各ＭＭＴＰセッションによって伝達され得る。
【０２１６】
仮想的な受信機バッファーモデルメッセージ：このメッセージは、バッファーを管理するために受信機によって要求される情報を伝達する。
【０２１７】
仮想的な受信機バッファーモデル除去メッセージ：このメッセージは、ＭＭＴデカプセレーションバッファーを管理するために受信機によって要求される情報を伝達する。
【０２１８】
以下、ＭＭＴシグナリングメッセージのうち１つであるｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）について説明する。ＭＭＴシグナリングメッセージであるｍｍｔ_ａｔｓｃ３_ｍｅｓｓａｇｅ（）は、前述した本発明によって、サービスに特定の情報を伝達するために定義される。本シグナリングメッセージは、ＭＭＴシグナリングメッセージの基本的なフィールドであるメッセージＩＤ、バージョン及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。本シグナリングメッセージのペイロードには、サービスＩＤ情報、コンテンツタイプ、コンテンツバージョン、コンテンツコンプレッション情報及び／又はＵＲＩ情報が含まれてもよい。コンテンツタイプ情報は、本シグナリングメッセージのペイロードに含まれるデータのタイプを示すことができる。コンテンツバージョン情報は、ペイロードに含まれるデータのバージョンを、コンテンツコンプレッション情報は、当該データに適用されたコンプレッションタイプを示すことができる。ＵＲＩ情報は、本メッセージによって伝達されるコンテンツと関連するＵＲＩ情報を有することができる。
【０２１９】
以下、ＰＬＰ識別子ディスクリプタについて説明する。
【０２２０】
ＰＬＰ識別子ディスクリプタは、前述したＭＰテーブルのディスクリプタのうち１つとして使用できるディスクリプタである。ＰＬＰ識別子ディスクリプタは、アセットを伝達するＰＬＰに関する情報を提供する。アセットが、ＭＰテーブルを伝達する現在のＰＬＰと異なるＰＬＰによって伝達されると、ＰＬＰ識別子ディスクリプタは、そのアセットを伝達するＰＬＰを識別するために、関連するＭＰテーブルでアセットディスクリプタとして使用され得る。ＰＬＰ識別子ディスクリプタは、ＰＬＰ ＩＤ情報以外にＢＳＩＤ情報をさらに含むこともできる。ＢＳＩＤは、このディスクリプタによって記述されるＡｓｓｅｔのためのＭＭＴＰパケットを伝達するブロードキャストストリームのＩＤであり得る。
【０２２１】
図８は、本発明の一実施例に係るリンクレイヤプロトコルアーキテクチャーを示した図である。
【０２２２】
以下、リンクレイヤ（Ｌｉｎｋ  Ｌａｙｅｒ）について説明する。
【０２２３】
リンクレイヤは、フィジカルレイヤとネットワークレイヤとの間のレイヤであり、送信側では、ネットワークレイヤからフィジカルレイヤにデータを伝送し、受信側では、フィジカルレイヤからネットワークレイヤにデータを伝送する。リンクレイヤの目的は、フィジカルレイヤによる処理のために全ての入力パケットタイプを一つのフォーマットで要約すること、まだ定義されていない入力タイプに対する柔軟性、及び将来の拡張可能性を保障することである。また、リンクレイヤ内で処理すれば、例えば、入力パケットのヘッダーにある不必要な情報を圧縮するのにオプションを提供することによって、入力データを効率的に伝送できるように保障する。エンカプセレーション、コンプレッションなどの動作はリンクレイヤプロトコルと呼ばれ、当該プロトコルを用いて生成されたパケットはリンクレイヤパケットと呼ばれる。リンクレイヤは、パケットエンカプセレーション（ｐａｃｋｅｔ  ｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッドリダクション（Ｏｖｅｒｈｅａｄ  Ｒｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（Ｓｉｇｎａｌｉｎｇ  Ｔｒａｎｓｍｉｓｓｉｏｎ）などの機能を行うことができる。
【０２２４】
以下、パケットエンカプセレーションについて説明する。リンクレイヤプロトコルは、ＩＰパケット及びＭＰＥＧ−２ ＴＳのようなものを含む全てのタイプのパケットのエンカプセレーションを可能にする。リンクレイヤプロトコルを用いて、フィジカルレイヤは、ネットワークレイヤプロトコルタイプと独立して一つのパケットフォーマットのみを処理すればよい（ここで、ネットワークレイヤパケットの一種としてＭＰＥＧ−２ ＴＳパケットを考慮）。各ネットワークレイヤパケットまたは入力パケットは、ジェネリックリンクレイヤパケットのペイロードに変形する。追加的に、入力パケットのサイズが特に小さいかまたは大きい場合、フィジカルレイヤリソースを効率的に用いるために、連鎖及び分割を行うことができる。
【０２２５】
前述したように、パケットエンカプセレーション過程で分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワークレイヤパケットが大きすぎるため、フィジカルレイヤで容易に処理できない場合、ネットワークレイヤパケットは２つ以上の分割に分けられる。リンクレイヤパケットヘッダーは、送信側で分割を行い、受信側で再結合を行うために、プロトコルフィールドを含む。ネットワークレイヤパケットが分割される場合、各分割は、ネットワークレイヤパケットでの元の位置と同一の順序でリンクレイヤパケットにエンカプセレーションされてもよい。また、ネットワークレイヤパケットの分割を含む各リンクレイヤパケットは、結果的にフィジカルレイヤに伝送されてもよい。
【０２２６】
前述したように、パケットエンカプセレーション過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）も活用することができる。リンクレイヤパケットのペイロードが多数のネットワークレイヤパケットを含む程度にネットワークレイヤパケットが十分に小さい場合、リンクレイヤパケットヘッダーは、連鎖を行うためにプロトコルフィールドを含む。連鎖は、多数の小さい大きさのネットワークレイヤパケットを一つのペイロードに結合したものである。ネットワークレイヤパケットが連鎖すれば、各ネットワークレイヤパケットは、元の入力順序と同一の順序でリンクレイヤパケットのペイロードに連鎖することができる。また、リンクレイヤパケットのペイロードを構成する各パケットは、パケットの分割ではない全体パケットであり得る。
【０２２７】
以下、オーバーヘッドリダクションについて説明する。リンクレイヤプロトコルの使用により、フィジカルレイヤ上でデータの伝送に対するオーバーヘッドを大きく減少させることができる。本発明に係るリンクレイヤプロトコルは、ＩＰオーバーヘッドリダクション及び／又はＭＰＥＧ−２ ＴＳオーバーヘッドリダクションを提供することができる。ＩＰオーバーヘッドリダクションにおいて、ＩＰパケットは、固定されたヘッダーフォーマットを有しているが、通信環境で必要な一部の情報はブロードキャスト環境で不要なことがある。リンクレイヤプロトコルは、ＩＰパケットのヘッダーを圧縮することによってブロードキャストオーバーヘッドを低減するメカニズムを提供する。ＭＰＥＧ−２ ＴＳオーバーヘッドリダクションにおいて、リンクレイヤプロトコルは、シンクバイト除去、ヌルパケット削除及び／又は共通ヘッダー除去（圧縮）を提供する。まず、シンクバイト除去は、ＴＳパケット当たり１バイトのオーバーヘッドリダクションを提供し、次に、ヌルパケット削除メカニズムは、受信機で再挿入できる方式で１８８バイトのヌルＴＳパケットを除去する。最後に、共通ヘッダー除去メカニズムが提供される。
【０２２８】
シグナリング伝送に対して、リンクレイヤプロトコルは、シグナリングパケットのための特定のフォーマットが、リンクレイヤシグナリングを伝送するために提供され得る。これについては後述する。
【０２２９】
図示された本発明の一実施例に係るリンクレイヤプロトコルアーキテクチャーにおいて、リンクレイヤプロトコルは、入力パケットとして、ＩＰｖ４、ＭＰＥＧ−２ ＴＳなどのような入力ネットワークレイヤパケットを取る。将来の拡張は、他のパケットタイプとリンクレイヤで入力され得るプロトコルを示す。リンクレイヤプロトコルは、フィジカルレイヤで特定のチャンネルに対するマッピングに関する情報を含む全てのリンクレイヤシグナリングに対するシグナリング及びフォーマットを特定する。図面は、ＡＬＰがどのように様々なヘッダーコンプレッション及び削除アルゴリズムを介して伝送効率を向上させるためにメカニズムを含むかを示す。また、リンクレイヤプロトコルは、基本的に入力パケットをエンカプセレーションすることができる。
【０２３０】
図９は、本発明の一実施例に係るリンクレイヤパケットのベースヘッダー構造を示した図である。以下、ヘッダーの構造について説明する。
【０２３１】
リンクレイヤパケットは、データペイロードが後続するヘッダーを含むことができる。リンクレイヤパケットのヘッダーは、ベースヘッダーを含むことができ、ベースヘッダーのコントロールフィールドに応じて追加ヘッダーを含むことができる。オプショナルヘッダーの存在は、追加ヘッダーのフラグフィールドから指示される。実施例によって、追加ヘッダー、オプショナルヘッダーの存在を示すフィールドはベースヘッダーに位置してもよい。
【０２３２】
以下、ベースヘッダーの構造について説明する。リンクレイヤパケットエンカプセレーションに対するベースヘッダーは階層構造を有する。ベースヘッダーは、２バイトの長さを有することができ、リンクレイヤパケットヘッダーの最小長さである。
【０２３３】
図示された本発明の一実施例に係るベースヘッダーは、Ｐａｃｋｅｔ_Ｔｙｐｅフィールド、ＰＣフィールド及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。実施例によって、ベースヘッダーは、ＨＭフィールド又はＳ／Ｃフィールドをさらに含むことができる。
【０２３４】
Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは、リンクレイヤパケットへのエンカプセレーションの前の入力データのパケットタイプまたは元のプロトコルを示す、３ビットのフィールドである。ＩＰｖ４パケット、圧縮されたＩＰパケット（ｃｏｍｐｒｅｓｓｅｄ  ＩＰ  ｐａｃｋｅｔ）、リンクレイヤシグナリングパケット、及びその他のタイプのパケットが、このようなベースヘッダーの構造を有し、エンカプセレーションされてもよい。ただし、実施例によって、ＭＰＥＧ−２ ＴＳパケットは、これとは異なる特別な構造を有し、エンカプセレーションされてもよい。Ｐａｃｋｅｔ_Ｔｙｐｅの値が「０００」、「００１」、「１００」または「１１１」であると、ＡＬＰパケットの元のデータタイプは、ＩＰｖ４パケット、圧縮ＩＰパケット、リンクレイヤシグナリングまたはエクステンションパケットのうち１つである。ＭＰＥＧ−２ ＴＳパケットがカプセル化されると、Ｐａｃｋｅｔ_Ｔｙｐｅの値は「０１０」であり得る。他のＰａｃｋｅｔ_Ｔｙｐｅフィールドの値は、将来の使用のために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【０２３５】
Ｐａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＰＣ）フィールドは、ペイロードの構成を示す１ビットのフィールドであり得る。０の値は、リンクレイヤパケットが一つの全体の入力パケットを伝達し、次のフィールドがＨｅａｄｅｒ_Ｍｏｄｅであることを示すことができる。１の値は、リンクレイヤパケットが１つ以上の入力パケット（連鎖）や大きい入力パケット（分割）の一部を伝達し、次のフィールドがＳｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎであることを示すことができる。
【０２３６】
Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）フィールドは、０に設定される場合、追加ヘッダーがないことを示し、リンクレイヤパケットのペイロードの長さが２０４８バイトよりも小さいことを示す、１ビットのフィールドであり得る。この数値は、実施例によって変更されてもよい。１の値は、下記に定義された１つのパケットのための追加ヘッダーが長さフィールドの次に存在することを示すことができる。この場合、ペイロードの長さは、２０４７バイトよりも大きく、及び／又はオプショナルフィーチャが使用され得る（サブストリーム識別、ヘッダー拡張など）。この数値は、実施例によって変更されてもよい。本フィールドは、リンクレイヤパケットのＰａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドが０の値を有するときのみ存在し得る。
【０２３７】
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）フィールドは、０に設定された場合、ペイロードが入力パケットのセグメントを伝達し、下記に定義される分割のための追加ヘッダーが長さフィールドの次に存在することを示す、１ビットのフィールドであり得る。１の値は、ペイロードが１つよりも多い完全な入力パケットを伝達し、下記に定義された連鎖のための追加ヘッダーが長さフィールドの次に存在することを示すことができる。本フィールドは、ＡＬＰパケットのＰａｙｌｏａｄ_Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドの値が１であるときのみ存在し得る。
【０２３８】
長さフィールドは、リンクレイヤパケットによって伝達されるペイロードのバイト単位の長さの１１ＬＳＢｓ（ｌｅａｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔｓ）を示す、１１ビットのフィールドであり得る。次の追加ヘッダーにＬｅｎｇｔｈ_ＭＳＢフィールドがあれば、長さフィールドは、Ｌｅｎｇｔｈ_ＭＳＢフィールドに連鎖し、ペイロードの実際の全長を提供するためにＬＳＢとなる。長さフィールドのビット数は、１１ビット以外に他のビットに変更されてもよい。
【０２３９】
したがって、次のパケット構造のタイプが可能である。すなわち、追加ヘッダーがない１つのパケット、追加ヘッダーがある１つのパケット、分割されたパケット、連鎖したパケットが可能である。実施例によって、各追加ヘッダーとオプショナルヘッダー、後述するシグナリング情報のための追加ヘッダーとタイプエクステンションのための追加ヘッダーによる組み合わせで、さらに多くのパケット構成が可能である。
【０２４０】
図１０は、本発明の一実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。
【０２４１】
追加ヘッダー（ａｄｄｉｔｉｏｎａｌ  ｈｅａｄｅｒ）は様々なタイプがあり得る。以下、シングルパケットのための追加ヘッダーについて説明する。
【０２４２】
１つのパケットに対する当該追加ヘッダーは、Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）＝「１」である場合に存在し得る。リンクレイヤパケットのペイロードの長さが２０４７バイトよりも大きいか、またはオプションフィールドが使用される場合、Ｈｅａｄｅｒ_Ｍｏｄｅ（ＨＭ）は１に設定され得る。１つのパケットの追加ヘッダー（ｔｓｉｂ１００１０）は図面に示す。
【０２４３】
Ｌｅｎｇｔｈ_ＭＳＢフィールドは、現在のリンクレイヤパケットにおいてバイト単位の全ペイロードの長さのＭＳＢｓ（ｍｏｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔｓ）を示すことができる、５ビットのフィールドであり得、全ペイロードの長さを得るために、１１ＬＳＢを含む長さフィールドに連鎖する。したがって、シグナリングできるペイロードの最大長さは６５５３５バイトである。長さフィールドのビット数は、１１ビット以外の他のビットに変更されてもよい。また、Ｌｅｎｇｔｈ_ＭＳＢフィールドも、ビット数が変更されてもよく、これによって、最大に表現可能なペイロードの長さも変更されてもよい。実施例によって、各長さフィールドは、ペイロードではなく全リンクレイヤパケットの長さを示してもよい。
【０２４４】
Ｓｕｂ−ｓｔｒｅａｍ Ｉｄｅｎｔｉｆｉｅｒ Ｆｌａｇ（ＳＩＦ）フィールドは、ＨＥＦ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｆｌａｇ）フィールドの後にＳＩＤ（ｓｕｂ−ｓｔｒｅａｍ  ＩＤ）が存在するか否かを示すことができる、１ビットのフィールドであり得る。リンクレイヤパケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンクレイヤパケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。ＳＩＤについての詳細は後述する。
【０２４５】
ＨＥＦフィールドは、１に設定される場合、将来の拡張のために追加ヘッダーが存在することを示すことができる、１ビットのフィールドであり得る。０の値は、この拡張フィールダーが存在しないことを示すことができる。
【０２４６】
以下、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
【０２４７】
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「０」である場合、追加ヘッダー（ｔｓｉｂ１００２０）が存在し得る。Ｓｅｇｍｅｎｔ_Ｓｅｑｕｅｎｃｅ_Ｎｕｍｂｅｒは、リンクレイヤパケットによって伝達される当該分割の順序を示すことができる、５ビットの符号なし整数であり得る。入力パケットの最初の分割を伝達するリンクレイヤパケットに対して、当該フィールドの値は０ｘ０に設定され得る。当該フィールドは、分割される入力パケットに属する各追加セグメント毎に１ずつ増分し得る。
【０２４８】
ＬＳＩ（Ｌａｓｔ_Ｓｅｇｍｅｎｔ_Ｉｎｄｉｃａｔｏｒ）は、１に設定される場合、当該ペイロードにある分割が入力パケットの最後のものであることを示すことができる、１ビットのフィールドであり得る。０の値は、それが最後の分割ではないことを示すことができる。
【０２４９】
ＳＩＦ（Ｓｕｂ−ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒ  Ｆｌａｇ）は、ＳＩＤがＨＥＦフィールドの後に存在するか否かを示すことができる、１ビットのフィールドであり得る。リンクレイヤパケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンクレイヤパケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。
【０２５０】
ＨＥＦフィールドは、１に設定される場合、リンクレイヤヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、オプショナルヘッダー拡張が存在しないことを示すことができる。
【０２５１】
実施例によって、各分割されたセグメントが同一の入力パケットから生成されたことを示すパケットＩＤフィールドが追加されてもよい。このフィールドは、分割されたセグメントが順に伝送されれば必要でないので、省略されてもよい。
【０２５２】
以下、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
【０２５３】
Ｓｅｇｍｅｎｔａｔｉｏｎ_Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「１」である場合、追加ヘッダー（ｔｓｉｂ１００３０）が存在し得る。
【０２５４】
Ｌｅｎｇｔｈ_ＭＳＢは、当該リンクレイヤパケットにおいてバイト単位のペイロードの長さのＭＳＢビットを示すことができる、４ビットのフィールドであり得る。当該ペイロードの最大長さは、連鎖のために３２７６７バイトとなる。前述したものと同様に、詳細な数値は変更されてもよい。
【０２５５】
Ｃｏｕｎｔフィールドは、リンクレイヤパケットに含まれたパケットの数を示すことができるフィールドであり得る。リンクレイヤパケットに含まれたパケットの数に該当する２は、当該フィールドに設定され得る。したがって、リンクレイヤパケットにおいて連鎖したパケットの最大値は９である。Ｃｏｕｎｔフィールドがその個数を指示する方法は、実施例毎に異なり得る。すなわち、１から８までの個数が指示されてもよい。
【０２５６】
ＨＥＦフィールドは、１に設定される場合、リンクレイヤヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、拡張ヘッダーが存在しないことを示すことができる。
【０２５７】
Ｃｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈは、各パケットのバイト単位の長さを示すことができる１２ビットのフィールドであり得る。Ｃｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドは、最後のコンポーネントパケットを除いて、ペイロードに存在するパケットと同一の順序で含まれる。長さフィールドの数は、（Ｃｏｕｎｔ＋１）によって示すことができる。実施例によって、Ｃｏｕｎｔフィールドの値と同一の数の長さフィールドが存在してもよい。リンクレイヤヘッダーが奇数のＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈで構成される場合、４個のスタッフィングビットが最後のＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドに後続することができる。これらビットは０に設定され得る。実施例によって、最後の連鎖したインプットパケットの長さを示すＣｏｍｐｏｎｅｎｔ_Ｌｅｎｇｔｈフィールドは存在しないこともある。この場合、最後の連鎖したインプットパケットの長さは、全ペイロードの長さから、各Ｃｏｍｐｏｎｅｎｔ_ｌｅｎｇｔｈフィールドが示す値の和を引いた長さで指示することができる。
【０２５８】
以下、オプショナルヘッダーについて説明する。
【０２５９】
前述したように、オプショナルヘッダーは、追加ヘッダーの後ろに追加されてもよい。オプショナルヘッダーフィールドは、ＳＩＤ及び／又はヘッダー拡張を含むことができる。ＳＩＤは、リンクレイヤレベルで特定のパケットストリームをフィルタリングするのに使用される。ＳＩＤの一例は、多数のサービスを伝達するリンクレイヤストリームにおいてサービス識別子の役割を果たす。適用可能な場合、サービスと、サービスに該当するＳＩＤ値との間のマッピング情報はＳＬＴで提供され得る。ヘッダー拡張は、将来の使用のための拡張フィールドを含む。受信機は、自身が理解できない全てのヘッダー拡張を無視し得る。
【０２６０】
ＳＩＤは、リンクレイヤパケットに対するサブストリーム識別子を示すことができる８ビットのフィールドであり得る。オプショナルヘッダー拡張があれば、ＳＩＤは、追加ヘッダーとオプショナルヘッダー拡張との間に存在する。
【０２６１】
Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）は、下記に定義されたフィールドを含むことができる。
【０２６２】
Ｅｘｔｅｎｓｉｏｎ_Ｔｙｐｅは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）のタイプを示すことができる８ビットのフィールドであり得る。
【０２６３】
Ｅｘｔｅｎｓｉｏｎ_Ｌｅｎｇｔｈは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）の次のバイトから最後のバイトまでカウントされるＨｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ（）のバイトの長さを示すことができる、８ビットのフィールドであり得る。
【０２６４】
Ｅｘｔｅｎｓｉｏｎ_Ｂｙｔｅは、Ｈｅａｄｅｒ_Ｅｘｔｅｎｓｉｏｎ（）の値を示すバイトであり得る。
【０２６５】
図１１は、本発明の他の実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。
【０２６６】
以下、シグナリング情報のための追加ヘッダーについて説明する。
【０２６７】
リンクレイヤシグナリングがどのようにリンクレイヤパケットに含まれるかは、次の通りである。シグナリングパケットは、ベースヘッダーのＰａｃｋｅｔ_Ｔｙｐｅフィールドが１００と同一であるときに識別される。
【０２６８】
図（ｔｓｉｂ１１０１０）は、シグナリング情報のための追加ヘッダーを含むリンクレイヤパケットの構造を示す。リンクレイヤヘッダーだけでなく、リンクレイヤパケットは、シグナリング情報のための追加ヘッダー及び実際のシグナリングデータ自体の２つの追加部分で構成され得る。リンクレイヤシグナリングパケットの全長はリンクレイヤパケットヘッダーに示す。
【０２６９】
シグナリング情報のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって一部のフィールドは省略されてもよい。
【０２７０】
Ｓｉｇｎａｌｉｎｇ_Ｔｙｐｅは、シグナリングのタイプを示すことができる８ビットのフィールドであり得る。
【０２７１】
Ｓｉｇｎａｌｉｎｇ_Ｔｙｐｅ_Ｅｘｔｅｎｓｉｏｎは、シグナリングの属性を示すことができる１６ビットのフィールドであり得る。当該フィールドの詳細はシグナリングの仕様で定義され得る。
【０２７２】
Ｓｉｇｎａｌｉｎｇ_Ｖｅｒｓｉｏｎは、シグナリングのバージョンを示すことができる８ビットのフィールドであり得る。
【０２７３】
Ｓｉｇｎａｌｉｎｇ_Ｆｏｒｍａｔは、シグナリングデータのデータフォーマットを示すことができる２ビットのフィールドであり得る。ここで、シグナリングフォーマットとは、バイナリ、ＸＭＬなどのデータフォーマットを意味し得る。
【０２７４】
Ｓｉｇｎａｌｉｎｇ_Ｅｎｃｏｄｉｎｇは、エンコーディング／コンプレッションフォーマットを特定することができる２ビットのフィールドであり得る。本フィールドは、コンプレッションが行われなかったか、どのような特定のコンプレッションが行われたかを示すことができる。
【０２７５】
以下、パケットタイプの拡張のための追加ヘッダーについて説明する。
【０２７６】
将来にリンクレイヤによって伝達されるパケットタイプ及び追加プロトコルの無制限に近い数を許容するメカニズムを提供するために、追加ヘッダーが定義される。前述したように、ベースヘッダーでＰａｃｋｅｔ_ｔｙｐｅが１１１である場合、パケットタイプの拡張が使用され得る。図（ｔｓｉｂ１１０２０）は、タイプの拡張のための追加ヘッダーを含むリンクレイヤパケットの構造を示す。
【０２７７】
タイプの拡張のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって一部のフィールドは省略されてもよい。
【０２７８】
ｅｘｔｅｎｄｅｄ_ｔｙｐｅは、ペイロードとしてリンクレイヤパケットにエンカプセレーションされる入力のプロトコルやパケットタイプを示すことができる、１６ビットのフィールドであり得る。当該フィールドは、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドによって既に定義された全てのプロトコルやパケットタイプに対して使用することができない。
【０２７９】
図１２は、本発明の一実施例に係る、ＭＰＥＧ−２ ＴＳパケットのためのリンクレイヤパケットのヘッダーの構造、及びそのエンカプセレーションの過程を示した図である。
【０２８０】
以下、入力パケットとしてＭＰＥＧ−２ ＴＳパケットが入力されたとき、リンクレイヤパケットのフォーマットについて説明する。
【０２８１】
この場合、ベースヘッダーのＰａｃｋｅｔ_Ｔｙｐｅフィールドは０１０と同一である。各リンクレイヤパケット内で多数のＴＳパケットがエンカプセレーションされてもよい。ＴＳパケットの数は、ＮＵＭＴＳフィールドを介してシグナリングされてもよい。この場合、前述したように、特別なリンクレイヤパケットヘッダーフォーマットが使用されてもよい。
【０２８２】
リンクレイヤは、伝送効率を向上させるために、ＭＰＥＧ−２ ＴＳのためのオーバーヘッドリダクションメカニズムを提供する。各ＴＳパケットのシンクバイト（０ｘ４７）は削除され得る。ヌルパケット及び類似のＴＳヘッダーを削除するオプションも提供される。
【０２８３】
不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（ＰＩＤ＝０ｘ１ＦＦＦ）を除去することができる。削除されたヌルパケットは、ＤＮＰフィールドを用いて受信機側で復旧することができる。ＤＮＰフィールドは、削除されたヌルパケットのカウントを示す。ＤＮＰフィールドを用いたヌルパケット削除メカニズムは、後述する。
【０２８４】
伝送効率をさらに向上させるために、ＭＰＥＧ−２ ＴＳパケットの類似のヘッダーを除去することができる。２つ以上の順次的なＴＳパケットがＣＣ（ｃｏｎｔｉｎｕｉｔｙ  ｃｏｕｎｔｅｒ）フィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。ＨＤＭフィールドは、ヘッダーが削除されたか否かを示すことができる。共通ＴＳヘッダー削除の詳細な過程は後述する。
【０２８５】
３つのオーバーヘッドリダクションメカニズムが全て行われる場合、オーバーヘッドリダクションは、シンク除去、ヌルパケット削除、共通ヘッダー削除の順に行うことができる。実施例によって、各メカニズムが行われる順序は変更されてもよい。また、実施例によって一部のメカニズムは省略されてもよい。
【０２８６】
ＭＰＥＧ−２ ＴＳパケットエンカプセレーションを使用する場合のリンクレイヤパケットヘッダーの全体的な構造が図（ｔｓｉｂ１２０１０）に示されている。
【０２８７】
以下、図示された各フィールドについて説明する。Ｐａｃｋｅｔ_Ｔｙｐｅは、前述したように、入力パケットのプロトコルタイプを示すことができる３ビットのフィールドであり得る。ＭＰＥＧ−２ ＴＳパケットエンカプセレーションのために、当該フィールドは、常に０１０に設定され得る。
【０２８８】
ＮＵＭＴＳ（Ｎｕｍｂｅｒ  ｏｆ  ＴＳ  ｐａｃｋｅｔｓ）は、当該リンクレイヤパケットのペイロードでＴＳパケットの数を示すことができる４ビットのフィールドであり得る。最大１６個のＴＳパケットが一つのリンクレイヤパケットで支援され得る。ＮＵＭＴＳ＝０の値は、１６個のＴＳパケットがリンクレイヤパケットのペイロードによって伝達されることを示すことができる。ＮＵＭＴＳの他の全ての値に対して、同じ数のＴＳパケットが認識される。例えば、ＮＵＭＴＳ＝０００１は、一つのＴＳパケットが伝達されることを意味する。
【０２８９】
ＡＨＦ（ａｄｄｉｔｉｏｎａｌ  ｈｅａｄｅｒ  ｆｌａｇ）は、追加ヘッダーが存在するか否かを示すことができるフィールドであり得る。０の値は、追加ヘッダーが存在しないことを示す。１の値は、１バイト長の追加ヘッダーがベースヘッダーの次に存在することを示す。ヌルＴＳパケットが削除されるか、またはＴＳヘッダーコンプレッションが適用されれば、当該フィールドは１に設定され得る。ＴＳパケットエンカプセレーションのための追加ヘッダーは、次の２つのフィールドで構成され、当該リンクレイヤパケットでのＡＨＦの値が１に設定される場合にのみ存在する。
【０２９０】
ＨＤＭ（ｈｅａｄｅｒ  ｄｅｌｅｔｉｏｎ  ｍｏｄｅ）は、ＴＳヘッダー削除を当該リンクレイヤパケットに適用できるか否かを示す１ビットのフィールドであり得る。１の値は、ＴＳヘッダー削除を適用できることを示す。０の値は、ＴＳヘッダー削除の方法が当該リンクレイヤパケットに適用されないことを示す。
【０２９１】
ＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ  ｐａｃｋｅｔｓ）は、当該リンクレイヤパケットの前に削除されたヌルＴＳパケットの数を示す７ビットのフィールドであり得る。最大１２８個のヌルＴＳパケットが削除され得る。ＨＤＭ＝０である場合、ＤＮＰ＝０の値は、１２８個のヌルパケットが削除されることを示すことができる。ＨＤＭ＝１である場合、ＤＮＰ＝０の値は、ヌルパケットが削除されないことを示すことができる。ＤＮＰの他の全ての値に対して、同じ数のヌルパケットが認識される。例えば、ＤＮＰ＝５は、５個のヌルパケットが削除されることを意味する。
【０２９２】
前述した各フィールドのビット数は変更可能であり、変更されたビット数に応じて、当該フィールドが指示する値の最小／最大値は変更され得る。これは、設計者の意図によって変更されてもよい。
【０２９３】
以下、シンクバイト削除（ＳＹＮＣ  ｂｙｔｅ  ｒｅｍｏｖａｌ）について説明する。
【０２９４】
ＴＳパケットをリンクレイヤパケットのペイロードにカプセル化する場合、各ＴＳパケットの開始からシンクバイト（０ｘ４７）が削除され得る。したがって、リンクレイヤパケットのペイロードにカプセル化されたＭＰＥＧ ２−ＴＳパケットの長さは（元の１８８バイトの代わりに）、常に１８７バイトである。
【０２９５】
以下、ヌルパケット削除（Ｎｕｌｌ  Ｐａｃｋｅｔ  Ｄｅｌｅｔｉｏｎ）について説明する。
【０２９６】
伝送ストリーム規則は、送信機のマルチプレクサの出力及び受信機のデマルチプレクサの入力でのビットレートが時間に対して一定であり、終端間の遅延も一定であることを要求する。一部の伝送ストリーム入力信号に対して、ヌルパケットは、一定のビットレートストリームに可変的なビットレートサービスを収容するために存在することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（即ち、ＰＩＤ＝０ｘ１ＦＦＦであるＴＳパケット）が除去され得る。この処理は、除去されたヌルパケットが受信機で元の正確な位置に再び挿入され得る方式で実行されるので、一定のビットレートを保障し、ＰＣＲタイムスタンプアップデートを行う必要がなくなる。
【０２９７】
リンクレイヤパケットの生成の前に、ＤＮＰと呼ばれるカウンターは、まず、０にリセットされた後に、現在のリンクレイヤパケットのペイロードにエンカプセレーションされる最初のヌルＴＳパケットではない、パケットに先行する各削除されたヌルパケットに対して増分され得る。その後、連続した有用なＴＳパケットのグループが現在のリンクレイヤパケットのペイロードにエンカプセレーションされ、そのヘッダーでの各フィールドの値が決定され得る。生成されたリンクレイヤパケットがフィジカルレイヤに注入された後、ＤＮＰは０にリセットされる。ＤＮＰが最高の許容値に到達する場合、次のパケットもヌルパケットであれば、当該ヌルパケットは有用なパケットに維持され、次のリンクレイヤパケットのペイロードにエンカプセレーションされる。各リンクレイヤパケットは、それのペイロードに少なくとも１つの有用なＴＳパケットを含むことができる。
【０２９８】
以下、ＴＳパケットヘッダー削除（ＴＳ  Ｐａｃｋｅｔ  Ｈｅａｄｅｒ  Ｄｅｌｅｔｉｏｎ）について説明する。ＴＳパケットヘッダー削除は、ＴＳパケットヘッダー圧縮と呼ぶこともできる。
【０２９９】
２つ以上の順次的なＴＳパケットがＣＣフィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。重複したＭＰＥＧ−２ ＴＳパケットが２つ以上の順次的なＴＳパケットに含まれると、ヘッダーの削除は送信機側で適用することができない。ＨＤＭフィールドは、ヘッダーが削除されるか否かを示すことができる。ＴＳヘッダーが削除される場合、ＨＤＭは１に設定され得る。受信機側で、最初のパケットヘッダーを用いて、削除されたパケットヘッダーが復旧され、ＣＣが最初のヘッダーから順に増加することによって復旧される。
【０３００】
図示された実施例（ｔｓｉｂ１２０２０）は、ＴＳパケットのインプットストリームがリンクレイヤパケットにエンカプセレーションされる過程の一実施例である。まず、ＳＹＮＣバイト（０ｘ４７）を有するＴＳパケットからなるＴＳストリームが入力され得る。まず、ＳＹＮＣバイトの削除過程を通じてシンクバイトを削除することができる。この実施例において、ヌルパケット削除は行われないと仮定する。
【０３０１】
ここで、図示された８個のＴＳパケットのパケットヘッダーにおいて、ＣＣ、すなわち、Ｃｏｕｎｔｉｎｕｉｔｙ Ｃｏｕｎｔｅｒフィールド値を除いた他の値が全て同一であると仮定する。この場合、ＴＳパケット削除／圧縮を行うことができる。ＣＣ＝１である最初のＴＳパケットのヘッダーのみを残し、残りの７個のＴＳパケットのヘッダーを削除する。処理されたＴＳパケットは、リンクレイヤパケットのペイロードにエンカプセレーションされてもよい。
【０３０２】
完成されたリンクレイヤパケットを見ると、Ｐａｃｋｅｔ_Ｔｙｐｅフィールドは、ＴＳパケットが入力された場合であるので０１０の値を有することができる。ＮＵＭＴＳフィールドは、エンカプセレーションされたＴＳパケットの個数を示すことができる。ＡＨＦフィールドは、パケットヘッダーの削除が行われたので１に設定され、追加ヘッダーの存在を知らせることができる。ＨＤＭフィールドは、ヘッダーの削除が行われたので１に設定され得る。ＤＮＰは、ヌルパケットの削除が行われなかったので、０に設定され得る。
【０３０３】
図１３は、本発明の一実施例に係るＩＰヘッダー圧縮において、アダプテーションモードの実施例を示した図である（送信側）。
【０３０４】
以下、ＩＰヘッダー圧縮（ＩＰ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。
【０３０５】
リンクレイヤにおいて、ＩＰヘッダーコンプレッション／デコンプレッションスキームが提供され得る。ＩＰヘッダーコンプレッションは、ヘッダーコンプレッサー／デコンプレッサー及びアダプテーションモジュールの２つの部分を含むことができる。ヘッダーコンプレッションスキームはＲｏＨＣに基づくことができる。また、放送用途にアダプテーション機能が追加される。
【０３０６】
送信機側で、ＲｏＨＣコンプレッサーは、各パケットに対してヘッダーの大きさを減少させる。その後、アダプテーションモジュールは、コンテキスト情報を抽出し、各パケットストリームからシグナリング情報を生成する。受信機側で、アダプテーションモジュールは、受信されたパケットストリームと関連するシグナリング情報をパーシングし、コンテキスト情報を受信されたパケットストリームに添付する。ＲｏＨＣデコンプレッサーは、パケットヘッダーを復旧することによって元のＩＰパケットを再構成する。
【０３０７】
ヘッダーコンプレッションスキームは、前述したように、ＲＯＨＣをベースとすることができる。特に、本システムでは、ＲＯＨＣのＵモード（ｕｎｉ  ｄｉｒｃｔｉｏｎａｌ  ｍｏｄｅ）でＲＯＨＣフレームワークが動作することができる。また、本システムにおいて、０ｘ０００２のプロファイル識別子で識別されるＲＯＨＣ ＵＤＰヘッダーコンプレッションプロファイルが使用され得る。
【０３０８】
以下、アダプテーション（Ａｄａｐｔａｔｉｏｎ）について説明する。
【０３０９】
単方向リンクを介した伝送の場合、受信機がコンテキストの情報を有していないと、デコンプレッサーは、完全なコンテキストを受信する時まで、受信されたパケットヘッダーを復旧することができない。これは、チャンネル変更遅延及びターンオンディレイ（ｔｕｒｎ−ｏｎ  ｄｅｌａｙ）を招くことがある。このような理由で、コンプレッサーとデコンプレッサーとの間のコンフィギュレーションパラメータ及びコンテキスト情報は、常にパケットフローと共に伝送され得る。
【０３１０】
アダプテーション機能は、コンフィギュレーションパラメータ及びコンテキスト情報の帯域外伝送を提供する。帯域外伝送は、リンクレイヤシグナリングを通じて行うことができる。したがって、アダプテーション機能は、コンテキスト情報の損失によるデコンプレッションエラー及びチャンネル変更遅延を減少させるために用いられる。
【０３１１】
以下、コンテキスト情報（Ｃｏｎｔｅｘｔ  Ｉｎｆｏｒｍａｔｉｏｎ）の抽出について説明する。
【０３１２】
コンテキスト情報の抽出は、アダプテーションモードに応じて様々な方法で行うことができる。本発明では、以下の３つの実施例について説明する。本発明の範囲は、後述するアダプテーションモードの実施例に限定されない。ここで、アダプテーションモードは、コンテキスト抽出モードと呼ぶこともできる。
【０３１３】
アダプテーションモード１（図示せず）は、基本的なＲＯＨＣパケットストリームに対していかなる追加的な動作も加えられていないモードであり得る。すなわち、このモードでアダプテーションモジュールは、バッファーとして動作することができる。したがって、このモードでは、リンクレイヤシグナリングにコンテキスト情報が含まれていない。
【０３１４】
アダプテーションモード２（ｔｓｉｂ１３０１０）において、アダプテーションモジュールは、ＲｏＨＣパケットフローからＩＲパケットを検出し、コンテキスト情報（スタティックチェーン）を抽出することができる。コンテキスト情報を抽出した後、各ＩＲパケットは、ＩＲ−ＤＹＮパケットに転換され得る。転換されたＩＲ−ＤＹＮパケットは、元のパケットの代わりに、ＩＲパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
【０３１５】
アダプテーションモード３（ｔｓｉｂ１３０２０）において、アダプテーションモジュールは、ＲｏＨＣパケットフローからＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテキスト情報を抽出することができる。スタティックチェーン及びダイナミックチェーンはＩＲパケットから抽出することができ、ダイナミックチェーンはＩＲ−ＤＹＮパケットから抽出することができる。コンテキスト情報を抽出した後、それぞれのＩＲ及びＩＲ−ＤＹＮパケットは圧縮されたパケットに転換され得る。圧縮されたパケットのフォーマットは、ＩＲまたはＩＲ−ＤＹＮパケットの次のパケットと同一であり得る。転換された圧縮パケットは、元のパケットの代わりに、ＩＲまたはＩＲ−ＤＹＮパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
【０３１６】
シグナリング（コンテキスト）情報は、伝送構造に基づいてエンカプセレーションされ得る。例えば、コンテキスト情報は、リンクレイヤシグナリングにエンカプセレーションされ得る。この場合、パケットタイプ値は１００に設定され得る。
【０３１７】
前述したアダプテーションモード２、３に対して、コンテキスト情報に対するリンクレイヤパケットは、１００のＰａｃｋｅｔ Ｔｙｐｅフィールド値を有することができる。また、圧縮されたＩＰパケットに対するリンクレイヤパケットは、００１のＰａｃｋｅｔ Ｔｙｐｅフィールド値を有することができる。これは、それぞれシグナリング情報、圧縮されたＩＰパケットがリンクレイヤパケットに含まれていることを示すもので、前述した通りである。
【０３１８】
以下、抽出されたコンテキスト情報を伝送する方法について説明する。
【０３１９】
抽出されたコンテキスト情報は、特定のフィジカルデータ経路を介してシグナリングデータと共に、ＲｏＨＣパケットフローと別途に伝送され得る。コンテキストの伝送は、フィジカルレイヤ経路の構成に依存する。コンテキスト情報は、シグナリングデータパイプを介して他のリンクレイヤシグナリングと共に伝送され得る。
【０３２０】
すなわち、コンテキスト情報を有するリンクレイヤパケットは、他のリンクレイヤシグナリング情報を有するリンクレイヤパケットと共にシグナリングＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ_Ｔｙｐｅ＝１００）。コンテキスト情報が抽出された圧縮ＩＰパケットは、一般的なＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ_Ｔｙｐｅ＝００１）。ここで、実施例によって、シグナリングＰＬＰは、Ｌ１シグナリングパス（ｐａｔｈ）を意味してもよい。また、実施例によって、シグナリングＰＬＰは、一般的なＰＬＰと区分されず、シグナリング情報が伝送される特定の一般ＰＬＰを意味してもよい。
【０３２１】
受信側では、パケットストリームを受信するに先立ち、受信機がシグナリング情報を得る必要がある。受信機が、シグナリング情報を獲得するために最初のＰＬＰをデコーディングすると、コンテキストシグナリングも受信することができる。シグナリングの獲得が行われた後、パケットストリームを受信するためのＰＬＰが選択され得る。すなわち、受信機は、まず、イニシャルＰＬＰを選択して、コンテキスト情報を含めてシグナリング情報を得ることができる。ここで、イニシャルＰＬＰは、前述したシグナリングＰＬＰであり得る。この後、受信機は、パケットストリームを得るためのＰＬＰを選択することができる。これを通じて、コンテキスト情報は、パケットストリームの受信に先立って獲得できる。
【０３２２】
パケットストリームを得るためのＰＬＰが選択された後、アダプテーションモジュールは、受信されたパケットフローからＩＲ−ＤＹＮパケットを検出することができる。その後、アダプテーションモジュールは、シグナリングデータにおいてコンテキスト情報からスタティックチェーンをパーシングする。これは、ＩＲパケットを受信することと類似している。同一のコンテキスト識別子に対して、ＩＲ−ＤＹＮパケットはＩＲパケットに復旧され得る。復旧されたＲｏＨＣパケットフローはＲｏＨＣデコンプレッサーに送られる。その後、デコンプレッションが開始され得る。
【０３２３】
図１４は、本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）及びＲＯＨＣ−Ｕディスクリプションテーブルを示した図である。
【０３２４】
以下、リンクレイヤシグナリングについて説明する。
【０３２５】
主に、リンクレイヤシグナリングはＩＰレベル下で動作する。受信機側で、リンクレイヤシグナリングは、ＳＬＴ及びＳＬＳのようなＩＰレベルシグナリングよりも先に獲得され得る。したがって、リンクレイヤシグナリングはセッション設定の前に獲得できる。
【０３２６】
リンクレイヤシグナリングに対して、入力経路に応じて、インターナルリンクレイヤシグナリング及びエクスターナルリンクレイヤシグナリングの２種類のシグナリングが存在することができる。インターナルリンクレイヤシグナリングは、送信機側でリンクレイヤで生成される。また、リンクレイヤは、外部のモジュールまたはプロトコルからシグナリングを取る。このような種類のシグナリング情報はエクスターナルリンクレイヤシグナリングであると見なされる。一部のシグナリングがＩＰレベルシグナリングに先立って獲得される必要があれば、外部のシグナリングは、リンクレイヤパケットのフォーマットで伝送される。
【０３２７】
リンクレイヤシグナリングは、前述したように、リンクレイヤパケットにエンカプセレーションされ得る。リンクレイヤパケットは、バイナリ及びＸＭＬを含んだ全てのフォーマットのリンクレイヤシグナリングを伝達することができる。同一のシグナリング情報がリンクレイヤシグナリングに対して異なるフォーマットで伝送され得る。
【０３２８】
インターナルリンクレイヤシグナリングには、リンクマッピングのためのシグナリング情報が含まれてもよい。ＬＭＴは、ＰＬＰに伝達される上位レイヤセッションのリストを提供する。ＬＭＴはまた、リンクレイヤで上位レイヤセッションを伝達するリンクレイヤパケットを処理するための追加情報を提供する。
【０３２９】
本発明に係るＬＭＴの一実施例（ｔｓｉｂ１４０１０）が図示された。
【０３３０】
ｓｉｇｎａｌｉｎｇ_ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットの符号なし整数フィールドであり得る。ＬＭＴに対するｓｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値は０ｘ０１に設定され得る。
【０３３１】
ＰＬＰ_ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
【０３３２】
ｎｕｍ_ｓｅｓｓｉｏｎは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションの個数を提供する８ビットの符号なし整数フィールドであり得る。ｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値が０ｘ０１であれば、当該フィールドは、ＰＬＰでＵＤＰ／ＩＰセッションの個数を示すことができる。
【０３３３】
ｓｒｃ_ＩＰ_ａｄｄは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのソースＩＰアドレスを含む３２ビットの符号なし整数フィールドであり得る。
【０３３４】
ｄｓｔ_ＩＰ_ａｄｄは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのデスティネーションＩＰアドレスを含む３２ビットの符号なし整数フィールドであり得る。
【０３３５】
ｓｒｃ_ＵＤＰ_ｐｏｒｔは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのソースＵＤＰポートナンバーを示す１６ビットの符号なし整数フィールドであり得る。
【０３３６】
ｄｓｔ_ＵＤＰ_ｐｏｒｔは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのデスティネーションＵＤＰポートナンバーを示す１６ビットの符号なし整数フィールドであり得る。
【０３３７】
ＳＩＤ_ｆｌａｇは、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤセッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有さない。当該フィールドの値が１に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有することができ、ＳＩＤフィールドの値が、当該テーブルで次のＳＩＤフィールドと同一であり得る。
【０３３８】
ｃｏｍｐｒｅｓｓｅｄ_ｆｌａｇは、ヘッダーコンプレッションが、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤセッションを伝達するリンクレイヤパケットに適用されるか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットは、そのベースヘッダーにＰａｃｋｅｔ_Ｔｙｐｅフィールドの０ｘ００の値を有することができる。当該フィールドの値が１に設定されると、上位レイヤセッションを伝達するリンクレイヤパケットは、そのベースヘッダーにＰａｃｋｅｔ_Ｔｙｐｅフィールドの０ｘ０１の値を有することができ、Ｃｏｎｔｅｘｔ_ＩＤフィールドが存在することができる。
【０３３９】
ＳＩＤは、４個のフィールドＳｒｃ_ＩＰ_ａｄｄ、Ｄｓｔ_ＩＰ_ａｄｄ、Ｓｒｃ_ＵＤＰ_Ｐｏｒｔ、Ｄｓｔ_ＵＤＰ_Ｐｏｒｔによって識別される上位レイヤセッションを伝達するリンクレイヤパケットに対するサブストリーム識別子を示す８ビットの符号なし整数フィールドであり得る。当該フィールドは、ＳＩＤ_ｆｌａｇの値が１と同一であるときに存在することができる。
【０３４０】
ｃｏｎｔｅｘｔ_ｉｄは、ＲＯＨＣ−Ｕディスクリプションテーブルに提供されたＣＩＤ（ｃｏｎｔｅｘｔ  ｉｄ）に対するレファレンスを提供する８ビットのフィールドであり得る。当該フィールドは、ｃｏｍｐｒｅｓｓｅｄ_ｆｌａｇの値が１と同一であるときに存在することができる。
【０３４１】
本発明に係るＲＯＨＣ−Ｕディスクリプションテーブルの一実施例（ｔｓｉｂ１４０２０）が図示された。前述したように、ＲＯＨＣ−Ｕアダプテーションモジュールは、ヘッダーコンプレッションに関連する情報を生成することができる。
【０３４２】
ｓｉｇｎａｌｉｎｇ_ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットのフィールドであり得る。ＲＯＨＣ−Ｕディスクリプションテーブルに対するｓｉｇｎａｌｉｎｇ_ｔｙｐｅフィールドの値は「０ｘ０２」に設定され得る。
【０３４３】
ＰＬＰ_ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
【０３４４】
ｃｏｎｔｅｘｔ_ｉｄは、圧縮されたＩＰストリームのＣＩＤを示す８ビットのフィールドであり得る。当該システムにおいて、８ビットのＣＩＤは、大きいＣＩＤのために使用することができる。
【０３４５】
ｃｏｎｔｅｘｔ_ｐｒｏｆｉｌｅは、ストリームを圧縮するために使用されるプロトコルの範囲を示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
【０３４６】
ａｄａｐｔａｔｉｏｎ_ｍｏｄｅは、当該ＰＬＰでアダプテーションモジュールのモードを示す２ビットのフィールドであり得る。アダプテーションモードについては前述した。
【０３４７】
ｃｏｎｔｅｘｔ_ｃｏｎｆｉｇは、コンテキスト情報の組み合わせを示す２ビットのフィールドであり得る。当該テーブルにコンテキスト情報が存在しなければ、当該フィールドは「０ｘ０」に設定され得る。当該テーブルにｓｔａｔｉｃ_ｃｈａｉｎ（）またはｄｙｎａｍｉｃ_ｃｈａｉｎ（）バイトが含まれれば、当該フィールドは「０ｘ０１」または「０ｘ０２」に設定され得る。当該テーブルにｓｔａｔｉｃ_ｃｈａｉｎ（）及びｄｙｎａｍｉｃ_ｃｈａｉｎ（）バイトが全て含まれれば、当該フィールドは「０ｘ０３」に設定され得る。
【０３４８】
ｃｏｎｔｅｘｔ_ｌｅｎｇｔｈは、スタティックチェーンバイトシーケンスの長さを示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
【０３４９】
ｓｔａｔｉｃ_ｃｈａｉｎ_ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサーを初期化するために使用されるスタティック情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
【０３５０】
ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサーを初期化するために使用されるダイナミック情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
【０３５１】
ｓｔａｔｉｃ_ｃｈａｉｎ_ｂｙｔｅは、ＩＲパケットのサブヘッダー情報として定義することができる。ｄｙｎａｍｉｃ_ｃｈａｉｎ_ｂｙｔｅは、ＩＲパケット及びＩＲ−ＤＹＮパケットのサブヘッダー情報として定義することができる。
【０３５２】
図１５は、本発明の一実施例に係る送信機側のリンクレイヤの構造を示した図である。
【０３５３】
本実施例は、ＩＰパケットを処理することを仮定した実施例である。送信機側のリンクレイヤは、機能的な観点から、大きく、シグナリング情報を処理するリンクレイヤシグナリング部分、オーバーヘッドリダクション部分、及び／又はエンカプセレーション部分を含むことができる。また、送信機側のリンクレイヤは、リンクレイヤ全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンクレイヤの入出力部分などを含むことができる。
【０３５４】
まず、上位レイヤのシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）がリンクレイヤに伝達され得る。また、ＩＰレイヤ（ｔｓｉｂ１５１１０）から、ＩＰパケットを含むＩＰストリームがリンクレイヤに伝達され得る。
【０３５５】
スケジューラ（ｔｓｉｂ１５０２０）は、前述したように、リンクレイヤに含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）は、スケジューラ（ｔｓｉｂ１５０２０）によってフィルタリングまたは活用されてもよい。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）のうち、受信機で必要な情報はリンクレイヤシグナリング部分に伝達されてもよい。また、シグナリング情報のうちリンクレイヤの動作に必要な情報は、オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）またはエンカプセレーションコントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３５６】
リンクレイヤシグナリング部分は、フィジカルレイヤでシグナリングとして伝送される情報を収集し、これを、伝送に適した形態に変換／構成する役割を果たすことができる。リンクレイヤシグナリング部分は、シグナリングマネジャー（ｔｓｉｂ１５０３０）、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）、及び／又はチャンネルのためのバッファー（ｔｓｉｂ１５０５０）を含むことができる。
【０３５７】
シグナリングマネジャー（ｔｓｉｂ１５０３０）は、スケジューラ（ｔｓｉｂ１５０２０）から伝達されたシグナリング情報、及び／又はオーバーヘッドリダクション部分から伝達されたシグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を受信することができる。シグナリングマネジャー（ｔｓｉｂ１５０３０）は、伝達されたデータに対して、各シグナリング情報が伝送される経路を決定することができる。各シグナリング情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって決定された経路で伝達されてもよい。前述したように、ＦＩＣ、ＥＡＳなどの区分されたチャンネルで伝送されるシグナリング情報はシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に伝達され、その他のシグナリング情報はエンカプセレーションバッファー（ｔｓｉｂ１５０７０）に伝達されてもよい。
【０３５８】
シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、別途に区分されたチャンネルを介してシグナリング情報を伝送できるように、関連するシグナリング情報を各区分されたチャンネルに合う形態でフォーマットする役割を果たすことができる。前述したように、フィジカルレイヤには、物理的／論理的に区分された別途のチャンネルがあり得る。これら区分されたチャンネルは、ＦＩＣシグナリング情報や、ＥＡＳ関連情報を伝送するのに使用することができる。ＦＩＣまたはＥＡＳ関連情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって分類されてシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に入力されてもよい。シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、各情報を、それぞれの別途のチャンネルに合わせてフォーマットすることができる。ＦＩＣ、ＥＡＳ以外にも、フィジカルレイヤが特定のシグナリング情報を別途の区分されたチャンネルを介して伝送するものと設計された場合には、その特定のシグナリング情報のためのシグナリングフォーマッタを追加することができる。このような方式を通じて、リンクレイヤが、様々なフィジカルレイヤに対して互換可能となり得る。
【０３５９】
チャンネルのためのバッファー（ｔｓｉｂ１５０５０）は、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）から伝達されたシグナリング情報を、指定された別途のチャンネル（ｔｓｉｂ１５０６０）に伝達する役割を果たすことができる。別途のチャンネルの数、内容は、実施例によって変更されてもよい。
【０３６０】
前述したように、シグナリングマネジャー（ｔｓｉｂ１５０３０）は、特定のチャンネルに伝達されないシグナリング情報をエンカプセレーションバッファー（ｔｓｉｂ１５０７０）に伝達することができる。エンカプセレーションバッファー（ｔｓｉｂ１５０７０）は、特定のチャンネルに伝達されないシグナリング情報を受信するバッファーの役割を果たすことができる。
【０３６１】
シグナリング情報のためのエンカプセレーション（ｔｓｉｂ１５０８０）は、特定のチャンネルに伝達されないシグナリング情報に対してエンカプセレーションを行うことができる。トランスミッションバッファー（ｔｓｉｂ１５０９０）は、エンカプセレーションされたシグナリング情報を、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）に伝達するバッファーの役割を果たすことができる。ここで、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）は、前述したＰＬＳ領域を意味し得る。
【０３６２】
オーバーヘッドリダクション部分は、リンクレイヤに伝達されるパケットのオーバーヘッドを除去し、効率的な伝送が可能にすることができる。オーバーヘッドリダクション部分は、リンクレイヤに入力されるＩＰストリームの数だけ構成することができる。
【０３６３】
オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）は、上位レイヤから伝達されたＩＰパケットの入力を受ける役割を果たすことができる。伝達されたＩＰパケットは、オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）を介してオーバーヘッドリダクション部分に入力されてもよい。
【０３６４】
オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）は、オーバーヘッドリダクションバッファー（ｔｓｉｂ１５１３０）に入力されるパケットストリームに対してオーバーヘッドリダクションを行うか否かを決定することができる。オーバーヘッドリダクションコントローラー（ｔｓｉｂ１５１２０）は、パケットストリーム別にオーバーヘッドリダクションを行うか否かを決定することができる。パケットストリームにオーバーヘッドリダクションが行われる場合、ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）にパケットが伝達されてオーバーヘッドリダクションが行われ得る。パケットストリームにオーバーヘッドリダクションが行われない場合、エンカプセレーション部分にパケットが伝達され、オーバーヘッドリダクションなしにエンカプセレーションが行われ得る。パケットにオーバーヘッドリダクションを行うか否かは、リンクレイヤに伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってエンカプセレーションコントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３６５】
ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）は、パケットストリームに対してオーバーヘッドリダクションを行うことができる。ＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）は、パケットのヘッダーを圧縮する動作を行うことができる。オーバーヘッドリダクションには様々な方法を使用することができる。前述した、本発明が提案した方法によってオーバーヘッドリダクションを行うことができる。本実施例は、ＩＰストリームを仮定しており、ＲｏＨＣコンプレシャーと表現したが、実施例によって名称は変更されてもよく、動作も、ＩＰストリームの圧縮に限定されず、全ての種類のパケットのオーバーヘッドリダクションがＲｏＨＣコンプレシャー（ｔｓｉｂ１５１４０）によって行われてもよい。
【０３６６】
パケットストリームコンフィギュレーションブロック（ｔｓｉｂ１５１５０）は、ヘッダーが圧縮されたＩＰパケットのうち、シグナリング領域に伝送される情報とパケットストリームに伝送される情報を分離することができる。パケットストリームに伝送される情報とは、ＤＰ領域に伝送される情報を意味し得る。シグナリング領域に伝送される情報は、シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１５１６０）に伝達されてもよい。パケットストリームに伝送される情報はエンカプセレーション部分に伝送されてもよい。
【０３６７】
シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１５１６０）は、シグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を収集し、これをシグナリングマネジャーに伝達することができる。シグナリング及び／又はコンテキスト情報をシグナリング領域に伝送するためである。
【０３６８】
エンカプセレーション部分は、パケットをフィジカルレイヤに伝達するのに適した形態でエンキャプシュレートする動作を行うことができる。エンカプセレーション部分は、ＩＰストリームの数だけ構成することができる。
【０３６９】
エンカプセレーションバッファー（ｔｓｉｂ１５１７０）は、エンカプセレーションのためにパケットストリームを受信する役割を果たすことができる。オーバーヘッドリダクションが行われた場合、オーバーヘッドリダクションされたパケットを受信し、オーバーヘッドリダクションが行われていない場合、入力されたＩＰパケットをそのまま受信することができる。
【０３７０】
エンカプセレーションコントローラー（ｔｓｉｂ１５１８０）は、入力されたパケットストリームに対してエンカプセレーションを行うか否かを決定することができる。エンカプセレーションが行われる場合、パケットストリームはセグメンテーション／コンカチネーション（ｔｓｉｂ１５１９０）に伝達されてもよい。エンカプセレーションが行われない場合、パケットストリームはトランスミッションバッファー（ｔｓｉｂ１５２３０）に伝達されてもよい。パケットをエンカプセレーションするか否かは、リンクレイヤに伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってエンカプセレーションコントローラー（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３７１】
セグメンテーション／コンカチネーションブロック（ｔｓｉｂ１５１９０）では、パケットに対して、前述した分割または連鎖作業を行うことができる。すなわち、入力されたＩＰパケットが、リンクレイヤの出力であるリンクレイヤパケットよりも長い場合、一つのＩＰパケットを分割して多数個のセグメントに分けて複数個のリンクレイヤパケットペイロードを作ることができる。また、入力されたＩＰパケットが、リンクレイヤの出力であるリンクレイヤパケットよりも短い場合、複数個のＩＰパケットをつなげて一つのリンクレイヤパケットペイロードを作ることができる。
【０３７２】
パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）は、分割及び／又は連鎖されたリンクレイヤパケットの構成情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報は、送信機と受信機が同じ情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報が送信機と受信機で参照されてもよい。パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）の情報のインデックス値が当該リンクレイヤパケットのヘッダーに含まれてもよい。
【０３７３】
リンクレイヤヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、エンカプセレーション過程で発生するヘッダー情報を収集することができる。また、リンクレイヤヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、パケットコンフィギュレーションテーブル（ｔｓｉｂ１５２００）が有する情報を収集することができる。リンクレイヤヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、リンクレイヤパケットのヘッダーの構造に応じてヘッダー情報を構成することができる。
【０３７４】
ヘッダーアタッチメントブロック（ｔｓｉｂ１５２２０）は、セグメンテーション及び／又はコンカチネーションされたリンクレイヤパケットのペイロードにヘッダーを追加することができる。トランスミッションバッファー（ｔｓｉｂ１５２３０）は、リンクレイヤパケットをフィジカルレイヤのＤＰ（ｔｓｉｂ１５２４０）に伝達するためのバッファーの役割を果たすことができる。
【０３７５】
各ブロック乃至モジュール及び部分（ｐａｒｔ）は、リンクレイヤにおいて一つのモジュール／プロトコルとして構成されてもよく、複数個のモジュール／プロトコルとして構成されてもよい。
【０３７６】
図１６は、本発明の一実施例に係る受信機側のリンクレイヤの構造を示した図である。
【０３７７】
本実施例は、ＩＰパケットを処理することを仮定した実施例である。受信機側のリンクレイヤは、機能的な観点から、大きく、シグナリング情報を処理するリンクレイヤシグナリング部分、オーバーヘッドプロセシング部分、及び／又はデカプセレーション部分を含むことができる。また、受信機側のリンクレイヤは、リンクレイヤ全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンクレイヤの入出力部分などを含むことができる。
【０３７８】
まず、フィジカルレイヤを介して伝送された各情報がリンクレイヤに伝達され得る。リンクレイヤは、各情報を処理して、送信側で処理する前の元の状態に戻した後、上位レイヤに伝達することができる。この実施例において、上位レイヤはＩＰレイヤであってもよい。
【０３７９】
フィジカルレイヤで区分された特定のチャンネル（ｔｓｉｂ１６０３０）を介して伝達された情報がリンクレイヤシグナリング部分に伝達され得る。リンクレイヤシグナリング部分は、フィジカルレイヤから受信されたシグナリング情報を判別し、リンクレイヤの各部分に、判別されたシグナリング情報を伝達する役割を果たすことができる。
【０３８０】
チャンネルのためのバッファー（ｔｓｉｂ１６０４０）は、特定のチャンネルを介して伝送されたシグナリング情報を受信するバッファーの役割を果たすことができる。前述したように、フィジカルレイヤに物理的／論理的に区分された別途のチャンネルが存在する場合、そのチャンネルを介して伝送されたシグナリング情報を受信することができる。別途のチャンネルから受信した情報が分割された状態である場合、完全な形態の情報になるまで、分割された情報を格納することができる。
【０３８１】
シグナリングデコーダ／パーサ（ｔｓｉｂ１６０５０）は、特定のチャンネルを介して受信されたシグナリング情報のフォーマットを確認し、リンクレイヤで活用される情報を抽出することができる。特定のチャンネルを介したシグナリング情報がエンコーディングされている場合にはデコーディングを行うことができる。また、実施例によって、当該シグナリング情報の無欠性などを確認してもよい。
【０３８２】
シグナリングマネジャー（ｔｓｉｂ１６０６０）は、多数の経路を介して受信されたシグナリング情報を統合することができる。後述するシグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して受信されたシグナリング情報もシグナリングマネジャー（ｔｓｉｂ１６０６０）で統合することができる。シグナリングマネジャー（ｔｓｉｂ１６０６０）は、リンクレイヤ内の各部分に必要なシグナリング情報を伝達することができる。例えば、オーバーヘッドプロセシング部分に、パケットのリカバリーのためのコンテキスト情報などを伝達することができる。また、スケジューラ（ｔｓｉｂ１６０２０）に、制御のためのシグナリング情報を伝達することができる。
【０３８３】
シグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して、別途の特別なチャンネルで受信されていない一般的なシグナリング情報が受信されてもよい。ここで、シグナリングのためのＤＰとは、ＰＬＳまたはＬ１などを意味し得る。ここで、ＤＰは、ＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）と呼ぶこともできる。レセプションバッファー（ｔｓｉｂ１６０８０）は、シグナリングのためのＤＰから伝送されたシグナリング情報を受信するバッファーの役割を果たすことができる。シグナリング情報のデカプセレーションブロック（ｔｓｉｂ１６０９０）では、受信されたシグナリング情報をデカプセレーションすることができる。デカプセレーションされたシグナリング情報は、デカプセレーションバッファー（ｔｓｉｂ１６１００）を経てシグナリングマネジャー（ｔｓｉｂ１６０６０）に伝達されてもよい。前述したように、シグナリングマネジャー（ｔｓｉｂ１６０６０）は、シグナリング情報を組み合わせてリンクレイヤ内の必要な部分に伝達することができる。
【０３８４】
スケジューラ（ｔｓｉｂ１６０２０）は、リンクレイヤに含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。スケジューラ（ｔｓｉｂ１６０２０）は、レシーバー情報（ｔｓｉｂ１６０１０）及び／又はシグナリングマネジャー（ｔｓｉｂ１６０６０）から伝達された情報を用いて、リンクレイヤの各部分を制御することができる。また、スケジューラ（ｔｓｉｂ１６０２０）は、各部分の動作モードなどを決定することができる。ここで、レシーバー情報（ｔｓｉｂ１６０１０）は、受信機が予め格納していた情報を意味し得る。スケジューラ（ｔｓｉｂ１６０２０）は、チャンネル切り替えなどのようにユーザが変更する情報も用いて、制御に活用することができる。
【０３８５】
デカプセレーション部分は、フィジカルレイヤのＤＰ（ｔｓｉｂ１６１１０）から受信されたパケットをフィルタリングし、当該パケットのタイプに応じてパケットを分離する役割を果たすことができる。デカプセレーション部分は、フィジカルレイヤで同時にデコーディングできるＤＰの数だけ構成することができる。
【０３８６】
デカプセレーションバッファー（ｔｓｉｂ１６１１０）は、デカプセレーションのためにフィジカルレイヤからパケットストリームを受信するバッファーの役割を果たすことができる。デカプセレーションコントローラー（ｔｓｉｂ１６１３０）は、入力されたパケットストリームに対してデカプセレーションを行うか否かを決定することができる。デカプセレーションが行われる場合、パケットストリームはリンクレイヤヘッダーパーサ（ｔｓｉｂ１６１４０）に伝達されてもよい。デカプセレーションが行われない場合、パケットストリームはアウトプットバッファー（ｔｓｉｂ１６２２０）に伝達されてもよい。デカプセレーションを行うか否かを決定するにおいて、スケジューラ（ｔｓｉｂ１６０２０）から伝達されたシグナリング情報を活用することができる。
【０３８７】
リンクレイヤヘッダーパーサ（ｔｓｉｂ１６１４０）は、伝達されたリンクレイヤパケットのヘッダーを確認することができる。ヘッダーを確認することによって、リンクレイヤパケットのペイロードに含まれているＩＰパケットの構成を確認することができる。例えば、ＩＰパケットは、セグメンテーションされているか、またはコンカチネーションされていてもよい。
【０３８８】
パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）は、セグメンテーション及び／又はコンカチネーションで構成されるリンクレイヤパケットのペイロード情報を含むことができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）の情報は、送信機と受信機が同じ情報を有することができる。パケットコンフィギュレーションテーブル（ｔｓｉｂ１６１５０）の情報が送信機と受信機で参照されてもよい。リンクレイヤパケットに含まれたインデックス情報に基づいて、再結合（ｒｅａｓｓｅｍｂｌｙ）に必要な値を見つけることができる。
【０３８９】
再結合ブロック（ｒｅａｓｓｅｍｂｌｙ）（ｔｓｉｂ１６１６０）は、セグメンテーション及び／又はコンカチネーションで構成されたリンクレイヤパケットのペイロードを元のＩＰストリームのパケットとして構成することができる。セグメントを一つに集めて一つのＩＰパケットとして再構成したり、コンカチネーションされたパケットを分離して複数個のＩＰパケットストリームとして再構成したりすることができる。再結合されたＩＰパケットは、オーバーヘッドプロセシング部分に伝達されてもよい。
【０３９０】
オーバーヘッドプロセシング部分は、送信機で行われたオーバーヘッドリダクションの逆過程として、オーバーヘッドリダクションされたパケットを元のパケットに戻す動作を行うことができる。この動作をオーバーヘッドプロセシングと呼ぶことができる。オーバーヘッドプロセシング部分は、フィジカルレイヤで同時にデコーディングできるＤＰの数だけ構成することができる。
【０３９１】
パケットリカバリーバッファー（ｔｓｉｂ１６１７０）は、オーバーヘッドプロセシングを行うためにデカプセレーションされたＲｏＨＣパケット乃至ＩＰパケットを受信するバッファーの役割を果たすことができる。
【０３９２】
オーバーヘッドコントローラー（ｔｓｉｂ１６１８０）は、デカプセレーションされたパケットに対してパケットリカバリー及び／又はデコンプレッションを行うか否かを決定することができる。パケットリカバリー及び／又はデコンプレッションが行われる場合、パケットストリームリカバリーブロック（ｔｓｉｂ１６１９０）にパケットが伝達されてもよい。パケットリカバリー及び／又はデコンプレッションが行われない場合、パケットはアウトプットバッファー（ｔｓｉｂ１６２２０）に伝達されてもよい。パケットリカバリー及び／又はデコンプレッションを行うか否かは、スケジューラ（ｔｓｉｂ１６０２０）によって伝達されたシグナリング情報に基づいて決定されてもよい。
【０３９３】
パケットストリームリカバリーブロック（ｔｓｉｂ１６１９０）は、送信機で分離されたパケットストリームと、パケットストリームのコンテキスト情報とを統合する動作を行うことができる。これは、ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）で処理可能なように、パケットストリームを復旧する過程であり得る。この過程で、シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１６２００）からシグナリング情報及び／又はコンテキスト情報を受信することができる。シグナリング及び／又はコンテキストコントローラー（ｔｓｉｂ１６２００）は、送信機から伝達されたシグナリング情報を判別し、当該コンテキストＩＤに合うストリームにマッピングできるようにパケットストリームリバーカレーブロック（ｔｓｉｂ１６１９０）にシグナリング情報を伝達することができる。
【０３９４】
ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）は、パケットストリームのパケットのヘッダーを復旧することができる。パケットストリームのパケットは、ヘッダーが復旧されることによって元のＩＰパケットの形態に復旧され得る。すなわち、ＲｏＨＣデコンプレッサー（ｔｓｉｂ１６２１０）はオーバーヘッドプロセシングを行うことができる。
【０３９５】
アウトプットバッファー（ｔｓｉｂ１６２２０）は、ＩＰレイヤ（ｔｓｉｂ１６２３０）に出力ストリームを伝達するに先立ち、バッファーの役割を果たすことができる。
【０３９６】
本発明が提案する送信機と受信機のリンクレイヤは、前述したようなブロック乃至モジュールを含むことができる。これを通じて、リンクレイヤが上位レイヤと下位レイヤに関係なく独立して動作することができ、オーバーヘッドリダクションを効率的に行うことができ、上／下位レイヤなどによって支援可能な機能の確定／追加／除去が容易となり得る。
【０３９７】
図１７は、本発明の一実施例に係る、リンクレイヤを介したシグナリング伝送構造を示した図である（送／受信側）。
【０３９８】
本発明では、一つの周波数バンド内に複数個のサービスプロバイダー（放送会社）がサービスを提供することができる。また、サービスプロバイダーは、複数個のサービスを伝送することができ、一つのサービスは１つ以上のコンポーネントを含むことができる。ユーザは、サービス単位でコンテンツを受信することを考慮することができる。
【０３９９】
本発明は、ＩＰハイブリッド放送を支援するために、複数個のセッションベースの伝送プロトコルが使用されることを仮定する。各プロトコルの伝送構造に基づいて、そのシグナリングパス（ｐａｔｈ）で伝達されるシグナリング情報を決定することができる。各プロトコルは、実施例によって様々な名称が付与されてもよい。
【０４００】
図示された送信側のデータ構造（ｔｓｉｂ１７０１０）において、サービスプロバイダー（Ｂｒｏａｄｃａｓｔｅｒｓ）は複数個のサービス（Ｓｅｒｖｉｃｅ  ＃１，＃２，…）を提供することができる。一般に、サービスに対するシグナリングは、一般的な伝送セッションを介して伝送することができるが（Ｓｉｇｎａｌｉｎｇ  Ｃ）、実施例によって、特定のセッション（ｄｅｄｉｃａｔｅｄ  ｓｅｓｓｉｏｎ）を介して伝送してもよい（Ｓｉｇｎａｌｉｎｇ  Ｂ）。
【０４０１】
サービスデータ及びサービスシグナリング情報は、伝送プロトコルに従ってエンカプセレーションすることができる。実施例によってＩＰ／ＵＤＰが使用されてもよい。実施例によってＩＰ／ＵＤＰレイヤでのシグナリング（Ｓｉｇｎａｌｉｎｇ  Ａ）が追加されてもよい。このシグナリングは省略できる。
【０４０２】
ＩＰ／ＵＤＰで処理されたデータはリンクレイヤに入力されてもよい。リンクレイヤでは、前述したように、オーバーヘッドリダクション及び／又はエンカプセレーション過程を行うことができる。ここで、リンクレイヤシグナリングが追加されてもよい。リンクレイヤシグナリングにはシステムパラメータなどが含まれてもよい。リンクレイヤシグナリングについては前述した。
【０４０３】
このような処理を経たサービスデータ及びシグナリング情報は、フィジカルレイヤでＰＬＰを介して処理されてもよい。ここで、ＰＬＰはＤＰと呼ぶこともできる。図示された実施例では、Ｂａｓｅ ＤＰ／ＰＬＰが使用される場合を想定しているが、実施例によってＢａｓｅ ＤＰ／ＰＬＰなしに一般的なＤＰ／ＰＬＰのみで伝送が行われてもよい。
【０４０４】
図示された実施例では、ＦＩＣ、ＥＡＣなどの特定のチャンネル（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）が使用されている。ＦＩＣを介して伝達されるシグナリングをＦＩＴ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）、ＥＡＣを介して伝達されるシグナリングをＥＡＴ（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔ  Ｔａｂｌｅ）と呼ぶことができる。ＦＩＴは、前述したＳＬＴと同一であってもよい。このような特定のチャンネルは、実施例によって使用されなくてもよい。特定のチャンネル（Ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）が構成されていない場合、ＦＩＴとＥＡＴは、一般的なリンクレイヤシグナリング伝送方法によって伝送されるか、または他のサービスデータのようにＩＰ／ＵＤＰを経てＰＬＰに伝送されてもよい。
【０４０５】
実施例によって、システムパラメータには、送信機関連パラメータ、サービスプロバイダー関連パラメータなどが含まれてもよい。リンクレイヤシグナリングには、ＩＰヘッダー圧縮関連コンテキスト情報、及び／又は当該コンテキストが適用されるデータに対する識別情報が含まれてもよい。上位レイヤのシグナリングには、ＩＰアドレス、ＵＤＰナンバー、サービス／コンポーネント情報、緊急警報（Ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ）関連情報、サービスシグナリングに対するＩＰ／ＵＤＰアドレス、セッションＩＤなどが含まれてもよい。詳細な実施例については前述した。
【０４０６】
図示された受信側のデータ構造（ｔｓｉｂ１７０２０）において、受信機は、全てのＰＬＰをデコーディングすることなく、シグナリング情報を活用して当該サービスに対するＰＬＰのみをデコーディングすることができる。
【０４０７】
まず、ユーザが、受信しようとするサービスを選択または変更すると、受信機は、当該周波数にチューニングし、当該チャンネルと関連してＤＢなどに格納している受信機情報を読み込むことができる。受信機のＤＢなどに格納されている情報は、最初のチャンネルスキャンの際にＳＬＴを読み込んで構成されてもよい。
【０４０８】
ＳＬＴを受信し、当該チャンネルの情報を受信した後、既存に格納されていたＤＢをアップデートし、ユーザが選択したサービスの伝送経路及びコンポーネント情報を獲得したり、このような情報を獲得するために必要なシグナリングが伝送される経路に対する情報を獲得したりする。ＳＬＴのバージョン情報などを用いて、当該情報の変更がないと判断される場合には、デコーディングまたはパーシング手順を省略することができる。
【０４０９】
受信機は、当該放送ストリームにおいて、ＰＬＰのフィジカルシグナリングをパーシングし、当該ＰＬＰ内にＳＬＴ情報があるかどうかを把握することができる（図示せず）。これは、フィジカルシグナリングの特定のフィールドを介して指示されてもよい。ＳＬＴ情報に接近することによって、特定のサービスのサービスレイヤシグナリングが伝送される位置に接近することができる。このサービスレイヤシグナリングは、ＩＰ／ＵＤＰにエンカプセレーションされて伝送セッションを介して伝達されてもよい。このサービスレイヤシグナリングを用いて、当該サービスを構成するコンポーネントに対する情報を獲得することができる。詳細なＳＬＴ−ＳＬＳの構造は、前述した通りである。
【０４１０】
すなわち、ＳＬＴを用いて、現在のチャンネルに伝送されている多数のパケットストリーム及びＰＬＰのうち、当該サービスの受信に必要な上位レイヤシグナリング情報（サービスシグナリング情報）を受信するための伝送経路情報を獲得することができる。この伝送経路情報には、ＩＰアドレス、ＵＤＰポートナンバー、セッションＩＤ、ＰＬＰ ＩＤなどが含まれてもよい。ここで、実施例によって、ＩＰ／ＵＤＰアドレスは、ＩＡＮＡまたはシステムで予め指定されている値を使用してもよい。このような情報は、ＤＢ及び共有メモリ接近などの方法で獲得されてもよい。
【０４１１】
リンクレイヤシグナリングとサービスデータが同一のＰＬＰを介して伝送されるか、または一つのＰＬＰのみが運用されている場合、ＰＬＰを介して伝達されるサービスデータは、リンクレイヤシグナリングがデコーディングされる間、臨時にバッファーなどの装置に格納されてもよい。
【０４１２】
受信しようとするサービスに対するサービスシグナリング情報を用いて、当該サービスが実際に伝送される経路の情報を獲得することができる。また、受信するＰＬＰに対するオーバーヘッドリダクションなどの情報を用いて、受信されるパケットストリームに対してデカプセレーション及びヘッダーリカバリーを行うことができる。
【０４１３】
図示された実施例（ｔｓｉｂ１７０２０）では、ＦＩＣ、ＥＡＣが使用され、Ｂａｓｅ ＤＰ／ＰＬＰの概念が想定された。前述したように、ＦＩＣ、ＥＡＣ、Ｂａｓｅ ＤＰ／ＰＬＰの概念は活用されなくてもよい。
【０４１４】
以下では、説明の便宜のためにＭＩＳＯ又はＭＩＭＯ方式は２つのアンテナを使用するが、本発明は、２つ以上のアンテナを使用するシステムに適用されてもよい。本発明は、特定用途に要求される性能を達成しながら、受信機複雑度を最小化するために最適化されたフィジカルプロファイル（又は、システム）を提案する。本発明の一実施例に係るフィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）は、該当する受信機が具現しなければならない全ての構造のサブセットであり、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。システム発展のために、ヒューチャープロファイルは、ＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を介して、単一ＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクシングされてもよい。本発明の一実施例に係るベースプロファイル及びハンドヘルドプロファイルは、ＭＩＭＯが適用されないプロファイルを意味し、アドバンスドプロファイルは、ＭＩＭＯが適用されるプロファイルを意味する。ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別できる。そして、本発明のプロファイルは、設計者の意図によって変更されてもよい。
【０４１５】
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。
【０４１６】
補助ストリーム：ヒューチャーエクステンション（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ、将来の拡張）のために又は放送社やネットワーク運営者の要求によって用い得るまだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
【０４１７】
ベースデータパイプ（ｂａｓｅ  ｄａｔａ  ｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ
【０４１８】
ベースバンドフレーム（又は、ＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
【０４１９】
セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値
【０４２０】
コーディングブロック（ｃｏｄｅｄ  ｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコーディングされたブロック又はＰＬＳ２データのＬＤＰＣエンコーディングされたブロックのうちの一つ
【０４２１】
データパイプ（ｄａｔａ  ｐｉｐｅ）：１つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連したメタデータを伝達する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）におけるロジカルチャネル
【０４２２】
データパイプユニット（ＤＰＵ，ｄａｔａ  ｐｉｐｅ  ｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット
【０４２３】
データシンボル（ｄａｔａ  ｓｙｍｂｏｌ）：プリアンブルシンボルでないフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）
【０４２４】
ＤＰ＿ＩＤ：当該８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内でデータパイプを唯一に識別する。
【０４２５】
ダミーセル（ｄｕｍｍｙ  ｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために使用されずに残っている容量を満たすために用いられる擬似ランダム値を伝達するセル
【０４２６】
ＥＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部
【０４２７】
フレーム（ｆｒａｍｅ）：プリアンブルから始まってフレームエッジシンボルで終了する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【０４２８】
フレームレペティションユニット（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ、フレーム反復単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む、同一の又は異なるフィジカルプロファイルに属するフレームの集合
【０４２９】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ、高速情報チャネル）：サービスと当該ベースデータパイプ間におけるマッピング情報を伝達するフレームでロジカルチャネル
【０４３０】
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコーディングされたビットの集合
【０４３１】
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同じ特定モードに用いられる名目上のＦＦＴサイズ
【０４３２】
フレームシグナリングシンボル（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、ガードインターバル（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定組合せにおいてフレームの先頭で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【０４３３】
フレームエッジシンボル（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）：ＦＦＴサイズ、ガードインターバル、及びスキャッタパイロットパターンの特定組合せにおいてフレームの末尾で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【０４３４】
フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームにおいて同じフィジカルプロファイルタイプを有する全てのフレームの集合
【０４３５】
ヒューチャーエクステンションフレーム（ｆｕｔｕｒｅ  ｅｘｔｅｎｔｉｏｎ  ｆｒａｍｅ、将来の拡張フレーム）：プリアンブルで始まる、将来の拡張に用いられ得るスーパーフレーム内で物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【０４３６】
ヒューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである提案された物理層放送システム
【０４３７】
インプットストリーム（ｉｎｐｕｔ  ｓｔｒｅａｍ、入力ストリーム）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
【０４３８】
ノーマル（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除くデータシンボル
【０４３９】
フィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）：該当する受信機が具現すべき全ての構造のサブセット
【０４４０】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
【０４４１】
ＰＬＳ１：ＰＬＳ２をデコーティングするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｌｉｎｇ  ｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合
【０４４２】
ＮＯＴＥ：ＰＬＳ１データはフレームグループのデューレーション（ｄｕｒａｔｉｏｎ）において一定である。
【０４４３】
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合
【０４４４】
ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データ：フレームごとにダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＰＬＳ２データ
【０４４５】
ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データ：フレームグループのデューレーションにおいてスタティック（ｓｔａｔｉｃ、静的）であるＰＬＳ２データ
【０４４６】
プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅ  ｓｉｇｎａｌｉｎｇ  ｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ
【０４４７】
プリアンブルシンボル（ｐｒｅａｍｂｌｅ  ｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達とフレームの先頭に位置する固定された長さのパイロットシンボル
【０４４８】
プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に用いられる。
【０４４９】
将来の使用（ｆｕｔｕｒｅ  ｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書では定義されないが、将来に定義可能である。
【０４５０】
スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合
【０４５１】
タイムインターリービングブロック（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｂｌｏｃｋ、ＴＩ  ｂｌｏｃｋ）：タイムインターリーバメモリの一つの用途に該当する、タイムインターリービングが実行されるセルの集合
【０４５２】
タイムインターリービンググループ（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｇｒｏｕｐ，ＴＩ  ｇｒｏｕｐ）：整数、ダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＸＦＥＣＢＬＯＣＫの数で構成された、特定データパイプに対するダイナミック（ｄｙｎａｍｉｃ、動的）容量割り当てが実行される単位
【０４５３】
ＮＯＴＥ：タイムインターリービンググループは一つのフレームに直接マッピングされてもよく、複数のフレームにマッピングされてもよい。タイムインターリービンググループは、一つ以上のタイムインターリービングブロックを含むことができる。
【０４５４】
タイプ１データパイプ（Ｔｙｐｅ １ ＤＰ）：全てのデータパイプがフレームにＴＤＭ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマッピングされるフレームのデータパイプ
【０４５５】
タイプ２データパイプ（Ｔｙｐｅ２ＤＰ）：全てのデータパイプがフレームにＦＤＭ方式でマッピングされるフレームのデータパイプ
【０４５６】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮcellsセルの集合
【０４５７】
図１８は、本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置の構造を示す。
【０４５８】
本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Ｉｎｐｕｔ  Ｆｏｒｍａｔ  ｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）ジェネレーションブロック（ＯＦＤＭ  ｇｅｎｅｒａｔｉｏｎ  ｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【０４５９】
本発明の一実施例に係る入力データは、ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳを主要入力フォーマットとすることができ、他のストリームタイプは一般ストリームとして扱う。これらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する当該帯域幅のスケジューリング及び割り当てを制御する。また本発明では、一つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリーム入力が同時に許容される。
【０４６０】
インプットフォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される一つ又は複数のデータパイプにデマチルプレクシングすることができる。データパイプは堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に影響を及ぼす。一つ又は複数のサービス又はサービスコンポーネントを一つのデータパイプによって伝達することができる。データパイプは、一つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連メタデータを伝達する物理層におけるロジカルチャネルである。
【０４６１】
また、データパイプユニットは、一つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【０４６２】
物理層への入力は、一つ又は複数のデータストリームで構成されてもよい。それぞれのデータストリームは、一つのデータパイプによって伝達される。インプットフォーマットブロック１０００は、一つ又はそれ以上の物理的経路（ｐｈｙｓｉｃａｌ  ｐａｔｈ又はＤＰ）を介して入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄ  ｆｒａｍｅ）に変換することができる。この場合、インプットフォーマットブロック１０００は、入力データ（ＴＳ又はＩＰ入力ストリーム）に対して伝送効率を増加させるためにヌルパケットディリーション（ｎｕｌｌ  ｐａｃｋｅｔ  ｄｅｌｅｔｉｏｎ）又はヘッダーコンプレッション（ｈｅａｄｅｒ  ｃｏｍｐｒｅｓｓｉｏｎ）を行うことができる。受信機は、ヘッダーの特定部分に対する先験的な（ａ  ｐｒｉｏｒｉ）情報を有することができることから、この知られた情報（ｋｎｏｗｎ  ｉｎｆｏｒｍａｔｉｏｎ）は送信機で削除されてもよい。ヌルパケットディリーションブロック（３０３０）は、ＴＳ入力ストリームの場合にのみ利用可能である。
【０４６３】
ＢＩＣＭブロック１０１０で、パリティ（ｐａｒｉｔｙ）データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値コンステレーションシンボルにマッピングされる。当該シンボルは当該データパイプに用いられる特定インターリービング深さにわたってインターリービングされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。
【０４６４】
フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマッピングし、周波数領域ダイバーシティのために、特に、周波数選択的フェーディングチャネルを防止するために周波数インターリービングを行うことができる。フレームビルディングブロックは、ディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロック、セルマッパー（ｃｅｌｌ  ｍａｐｐｅｒ）及びフリケンシーインターリーバ（ｆｒｅｑｕｅｎｃｙ  ｉｎｔｅｒｌｅａｖｅｒ）を含むことができる。
【０４６５】
ディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロックは、データパイプと該当するＰＬＳデータ間のタイミングを調節して、送信機側でデータパイプと該当するＰＬＳデータ間の同時性（ｃｏ−ｔｉｍｅ）を保障することができる。インプットフォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことにより、ＰＬＳデータはデータパイプの分だけ遅れる。ＢＩＣＭブロックの遅延は主にタイムインターリーバに起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次のタイムインターリービンググループの情報を、シグナリングされるデータパイプよりも１フレーム先立って伝達されるようにすることができる。ディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロックは、それに合わせてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。
【０４６６】
セルマッパーは、ＰＬＳ、データパイプ、補助ストリーム、及びダミーセルなどを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングすることができる。セルマッパーの基本機能は、それぞれのデータパイプ、ＰＬＳセルに対するタイムインターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマッピングすることである。（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集されてデータパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成されたダイナミックインフォメーション（ｄｙｎａｍｉｃ  ｉｎｆｏｒｍａｔｉｏｎ、動的情報）に応じて動作する。フリケンシーインターリーバは、セルマッパーから受信されたデータセルをランダムにインターリービングして周波数ダイバーシティを提供することができる。また、フリケンシーインターリーバは、単一フレームで最大のインターリービング利得を得るために、異なるインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（ｐａｉｒ、対）で動作することができる。
【０４６７】
ＯＦＤＭジェネレーションブロック１０３０は、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは順次にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
【０４６８】
具体的に、プリアンブルを各フレームの先頭に挿入した後、ＯＦＤＭジェネレーションブロック１０３０は、サイクリックプレフィックス（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）をガードインターバルとして有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシティのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、本発明は、様々なＦＦＴサイズ、ガードインターバル長さ、当該パイロットパターンの集合を提供する。
【０４６９】
また、本発明は、放送サービスを提供する２つ以上の異なる放送送信／受信システムのデータが同じＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクシングすることができる。この場合、２つ以上の異なる放送送信／受信システムは、それぞれ異なる放送サービスを提供するシステムのことをいう。それぞれ異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。
【０４７０】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように送信される。本発明の一実施例に係るシグナリング情報は、ＰＬＳデータを含むことができる。ＰＬＳは、受信機でフィジカルレイヤ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）データパイプに接続し得る手段を提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。
【０４７１】
ＰＬＳ１データは、ＰＬＳ２データをデコーティングするために必要なパラメータの他、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームにおいてＦＳＳで伝達される、ＰＬＳデータの一番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデューレーションにおいて一定である。
【０４７２】
ＰＬＳ２データは、データパイプ及びシステムに関するより一層詳細なＰＬＳデータを伝達するＦＳＳで伝送される、ＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコーティングするのに十分な情報を提供するパラメータを含む。さらに、ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータで構成される。ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データは、フレームグループのデューレーションの間にスタティック（ｓｔａｔｉｃ、静的）であるＰＬＳ２データであり、ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データは、フレームごとにダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＰＬＳ２データである。ＰＬＳデータに関する詳細な内容は後述する。
【０４７３】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックによって代替されてもよい。
【０４７４】
図１９は、本発明の一実施例に係るＢＩＣＭブロックを示す。
【０４７５】
図１９に示すＢＩＣＭブロックは、図１８を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０４７６】
前述したように、本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０４７７】
ＱｏＳが、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータは、それぞれ異なる方式で処理されなければならない。したがって、本発明の一実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することによって、各データパイプを独立して処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプを介して伝送される各サービス又はサービスコンポーネントに対するＱｏＳを調節することができる。
【０４７８】
（ａ）は、ＭＩＭＯが適用されないプロファイル（又は、システム）に適用されるＢＩＣＭブロックを示し、（ｂ）はＭＩＭＯが適用されるプロファイル（又は、システム）のＢＩＣＭブロックを示す。
【０４７９】
ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０４８０】
ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックのそれぞれの処理ブロックについて説明する。
【０４８１】
ＭＩＭＯが適用されないＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
【０４８２】
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は、選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作については後述する。
【０４８３】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながら、データＦＥＣエンコーダ５０１０の出力をインターリービングして、ＬＤＰＣコード及び変調方式の組合せによって最適化した性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
【０４８４】
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４，ＮＵＱ−２５６，ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６，ＮＵＣ−６４，ＮＵＣ−２５６，ＮＵＣ−１０２４）を用いて、ベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調して、電力の正規化されたコンステレーションポイントｅlを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱは任意の形態を有するが、ＱＡＭ−１６及びＮＵＱは正方形の形状を有することが観察される。それぞれのコンステレーションが９０°の倍数だけ回転すると、回転されたコンステレーションは、元来のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均電力がお互い同一になる。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ  ｒａｔｅ）に対して特別に定義され、用いられるいずれか一つは、ＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによってシグナリングされる。
【０４８５】
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定されてもよい。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０４８６】
ＭＩＭＯが適用されるＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。
【０４８７】
ただし、処理ブロック５０００−１は、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で、ＭＩＭＯの適用されないＢＩＣＭの処理ブロック５０００と区別される。
【０４８８】
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
【０４８９】
セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。
【０４９０】
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いて、セルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号送信のために最適化されている。ＭＩＭＯ技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に、放送に対して、異なる信号電波特性による２つのアンテナ間の受信信号電力差又はチャネルの強いＬＯＳコンポーネントは、ＭＩＭＯから容量利得を得ることを難しくさせる。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの位相ランダム化及び回転ベースのプリコーディングを用いてこの問題を克服する。
【０４９１】
ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２×２ＭＩＭＯシステムのために意図される。本発明のＭＩＭＯエンコーディングモードは、ＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）と定義できる。ＦＲ−ＳＭエンコーディングは、受信機側における比較的小さい複雑度の増加で容量増加を提供することができる。また、本発明のＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。
【０４９２】
ＭＩＭＯ処理は、データパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ、対）であるＮＵＱ（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（ｐａｉｒ、対）（ｇ1,i及びｇ2,i）は、それぞれの送信アンテナの同じキャリアｋ及びＯＦＤＭシンボルｌによって送信される。
【０４９３】
前述したブロックは、省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０４９４】
図２０は、本発明の他の実施例に係るＢＩＣＭブロックを示す。
【０４９５】
図２０に示す、ＢＩＣＭブロックは、図１８を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０４９６】
図２０は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。ＥＡＣ及びＦＩＣに関する詳細な説明は後述する。
【０４９７】
図２０を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。
【０４９８】
また、ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブラー、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて説明する。
【０４９９】
ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブリングされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコーディングすることができる。
【０５００】
スクランブラーは、ＢＣＨエンコーディング及びショートニング（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャリングされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブリングすることができる。
【０５０１】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いて、スクランブリングされたＰＬＳ１／２データに外部エンコーディングを行い、ＢＣＨエンコーディング後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディング前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）することができる。
【０５０２】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、Ｃldpc及びパリティビットＰldpcは、それぞれのゼロが挿入されたＰＬＳ情報ブロックＩldpcから組織的にエンコーディングされ、その後に添付される。
【数１】
0006309622.tif 000002
【０５０３】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０５０４】
ショートニングがＰＬＳ１データ保護に適用されると、一部のＬＤＰＣパリティビットは、ＬＤＰＣエンコーディング後にパンクチャリングされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャリングされる。これらのパンクチャリングされたビットは伝送されない。
【０５０５】
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインターリービングすることができる。
【０５０６】
コンステレーションマッパー６０２０は、ビットインターリービングされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。
【０５０７】
前述したブロックは、省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０５０８】
図２１は、本発明の一実施例に係るＰＬＳのビットインターリービング過程を示す図である。
【０５０９】
それぞれのショートニング及びパンクチャリングされたＰＬＳ１及びＰＬＳ２コーディングブロックは、図２１に示すように、１ビットずつインターリービングされる。追加パリティビットの各ブロックは、同じブロックインターリービング構造でインターリービングされるが、別途にインターリービングされる。
【０５１０】
ＢＰＳＫの場合、実数及び虚数の部分でＦＥＣコーディングビットを複製するために、ビットインターリービングのための２つのブランチが存在する。それぞれのコーディングブロックは、上位ブランチにまず書き込まれる。ビットは、サイクリックシフト値フロアー（ＮFEC／２）でモジューロＮFEC加算を適用することによって、下位ブランチにマッチングされる。ここで、ＮFECは、ショートニング及びパンクチャリング後のそれぞれのＬＤＰＣコーディングブロックの長さである。
【０５１１】
ＱＳＰＫ、ＱＡＭ−１６、ＮＵＱ−６４のような他の変調の場合、ＦＥＣコーディングビットは列方向に順次にインターリーバに書き込まれる。ここで、列の数は変調次数と同一である。
【０５１２】
読み出し動作で、一つのコンステレーションシンボルに対するビットは順次に行方向に読み出され、ビットデマルチプレクサブロックに入力される。これらの動作は列の最後まで続く。
【０５１３】
それぞれのビットインターリービンググループは、コンステレーションマッピング前にグループで１ビットずつデマチルプレクシングされる。変調次数によって、２つのマッピング規則がある。ＢＰＳＫ及びＱＰＳＫの場合、一つのシンボルにおいてビットの信頼度は同一である。したがって、ビットインターリービングブロックから読み出されたビットグループは、いかなる動作無しでＱＡＭシンボルにマッチングされる。
【０５１４】
ＱＡＭシンボルにマッピングされたＱＡＭ−１６及びＮＵＱ−６４の場合、動作の規則が図２１（ａ）に説明されている。図２１（ａ）に示すように、ｉは、ビットインターリービングにおいて列インデックスに該当するビットグループインデックスである。
【０５１５】
図２１は、ＱＡＭ−１６に対するビットデマチルプレクシング規則を示す。この動作は、全てのビットグループがビットインターリービングブロックから読み出されるまで続く。
【０５１６】
図２２は、本発明の一実施例に係る、次世代放送サービスに対する放送信号受信装置の構造を示す。
【０５１７】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１８を参照して説明した、次世代放送サービスに対する放送信号送信装置に対応し得る。
【０５１８】
本発明の一実施例に係る、次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ＆  ｄｅｍｏｄｕｌａｔｉｏｎ  ｍｏｄｕｌｅ）９０００、フレームパーシングモジュール（ｆｒａｍｅ  ｐａｒｓｉｎｇ  ｍｏｄｕｌｅ）９０１０、デマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ  ＆  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０２０、出力プロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）９０３０、及びシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇ  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
【０５１９】
同期及び復調モジュール９０００は、ｍ個の受信アンテナから入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆過程に該当する復調を実行することができる。
【０５２０】
フレームパーシングモジュール９０１０は、入力信号フレームをパーシングし、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行していると、フレームパーシングモジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるへき信号及びデータの位置を、シグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることで取得し、放送信号送信装置によって生成されたスケジューリング情報を復元することができる。
【０５２１】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によって、ビット領域データをデインターリービングすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングによって伝送チャネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることによって、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。
【０５２２】
出力プロセッサ９０３０は、伝送効率を向上させるために放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆過程を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を取得することができる。出力プロセッサ９０３０の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及びＧＳであってもよい。
【０５２３】
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０５２４】
本発明の一実施例に係るフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、ノーマルデータシンボル、ＦＥＳを含む。
【０５２５】
プリアンブルは、高速ヒューチャーキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルに関する詳細な内容は後述する。
【０５２６】
ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、それによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルよりも高密度のパイロットパターンを有する。ＦＥＳは、ＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳの直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しに、ＦＥＳ内における周波数だけのインターポレーション（ｉｎｔｅｒｐｏｌａｔｉｏｎ、補間）及び時間的補間（ｔｅｍｐｏｒａｌ  ｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。
【０５２７】
図２３は、本発明の一実施例に係る、フレームのシグナリング階層構造（ｓｉｇｎａｌｉｎｇ  ｈｉｅｒａｒｃｈｙ  ｓｔｒｕｃｔｕｒｅ）を示す。
【０５２８】
図２３は、シグナリング階層構造を示しているが、これは、３つの主要部分であるプリアンブルシグナリングデータ（１１０００）、ＰＬＳ１データ（１１０１０）、及びＰＬＳ２データ（１１０２０）に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーティングできるようにする。ＰＬＳ２は、毎フレームごとに伝達され、２つの主要部分である、ＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データのスタティック（ｓｔａｔｉｃ、静的）及びダイナミック（ｄｙｎａｍｉｃ、動的）部分には、必要時にパディングが続く。
【０５２９】
本発明の一実施例に係るプリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳細な内容は、次のとおりである。
【０５３０】
ＦＦＴ＿ＳＩＺＥ：当該２ビットフィールドは、下記の表１で説明しているとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。
【表１】
0006309622.tif 000003
【０５３１】
ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表２で説明しているとおり、現スーパーフレームにおけるガードインターバル一部（ｆｒａｃｔｉｏｎ）の値を示す。
【表２】
0006309622.tif 000004
【０５３２】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームに提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームに提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドは、スーパーフレーム内でダイナミック（ｄｙｎａｍｉｃ、動的）に切り替えることができる。
【０５３３】
ＰＩＬＯＴ＿ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードか又は固定モードかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。
【０５３４】
ＰＡＰＲ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅ  ｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。
【０５３５】
ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来の使用のためにリザーブされる。
【０５３６】
図２４は、本発明の一実施例に係るＰＬＳ１データを示す。
【０５３７】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含む基本伝送パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全体デューレーションにおいて変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は、次のとおりである。
【０５３８】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：当該２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧを除いたプリアンブルシグナリングデータのコピーである。
【０５３９】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：当該２ビットフィールドは、ＦＲＵ当たりのフレーム数を示す。
【０５４０】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表３に示すようにシグナリングされる。
【表３】
0006309622.tif 000005
【０５４１】
ＮＵＭ＿ＦＳＳ：当該２ビットフィールドは、現フレームでＦＳＳの数を示す。
【０５４２】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０５４３】
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は互換不可能な変化を表す。デフォルト値は、００００である。当該標準で記述されたバージョンに対して、値が００００に設定される。
【０５４４】
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は互換可能である。
【０５４５】
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワークで地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジは、ヒューチャーキャストＵＴＢシステム当たりに用いられる周波数の数によって一つ以上の周波数で構成され得る。ＣＥＬＬ＿ＩＤの値が知られていないか、特定されていないと、当該フィールドは０に設定される。
【０５４６】
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。
【０５４７】
ＳＹＳＴＥＭ＿ＩＤ：当該１６ビットフィールドは、ＡＴＳＣネットワーク内でヒューチャーキャストＵＴＢシステムを唯一に識別する。ヒューチャーキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。ヒューチャーキャストＵＴＢシステムは、存在するなら、ＦＥＦ及び一つ以上のフィジカルプロファイルを伝達する。同じヒューチャーキャストＵＴＢシステムは、互いに異なる入力ストリームを伝達し、異なる地理的領域で異なるＲＦを用いることができるので、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは、一つの場所で制御され、ヒューチャーキャストＵＴＢシステム内で全ての伝送に対して同一である。一つ以上のヒューチャーキャストＵＴＢシステムはいずれも同じフィジカル構造及び構成を有するという同一ＳＹＳＴＥＭ＿ＩＤの意味を有することができる。
【０５４８】
次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦを含む）がシグナリングされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４よりも小さいと、使用されないフィールドはゼロで埋められる。
【０５４９】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレーム（ｉはループ（ｌｏｏｐ）インデックス）のフィジカルプロファイルタイプを示す。当該フィールドは、表８に示したものと同じシグナリングフォーマットを用いる。
【０５５０】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：当該２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを使用すると、フレームデューレーションの正確な値が得られる。
【０５５１】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームのガードインターバル一部の値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７によってシグナリングされる。
【０５５２】
ＲＥＳＥＲＶＥＤ：当該４ビットフィールドは将来の使用のためにリザーブされる。
【０５５３】
次のフィールドは、ＰＬＳ２データをデコーディングするためのパラメータを提供する。
【０５５４】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表４によってシグナリングされる。ＬＤＰＣコードに関する詳細な内容は後述する。
【表４】
0006309622.tif 000006
【０５５５】
ＰＬＳ２＿ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは、表５によってシグナリングされる。
【表５】
0006309622.tif 000007
【０５５６】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対する全てのコーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_partial_blockを示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５５７】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５５８】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５５９】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０５６０】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、現フレームグループの毎フレームごとに伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_partial_blockを示す。反復が使用されない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５６１】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられるＦＥＣタイプを示す。ＦＥＣタイプは表１０によってシグナリングされる。
【０５６２】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：当該３ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられる変調タイプを示す。変調タイプは、表１１によってシグナリングされる。
【０５６３】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが次のフレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０５６４】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、次のフレームグループの毎フレームごとに伝達されるＰＬＳ２に対する全体コーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_full_blockを示す。次のフレームグループで反復が使用されない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５６５】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０５６６】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０５６７】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。下記の表６は、当該フィールドの値を提供する。当該フィールドの値が００に設定されると、現フレームグループで追加パリティがＰＬＳ２に対して使用されない。
【表６】
0006309622.tif 000008
【０５６８】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５６９】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。表１２は、当該フィールドの値を定義する。
【０５７０】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５７１】
ＲＥＳＥＲＶＥＤ：当該３２ビットフィールドは、将来の使用のためにリザーブされる。
【０５７２】
ＣＲＣ＿３２：全体ＰＬＳ１シグナリングに適用される３２ビットエラー検出コード
【０５７３】
図２５は、本発明の一実施例に係るＰＬＳ２データを示す。
【０５７４】
図２５は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
【０５７５】
以下、ＰＬＳ２−ＳＴＡＴデータのフィールドについて具体的に説明する。
【０５７６】
ＦＩＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＦＩＣが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームに提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５７７】
ＡＵＸ＿ＦＬＡＧ：当該１ビットフィールドは、補助ストリームが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、補助ストリームは現フレームに提供される。当該フィールドの値が０に設定されると、補助フレームは現フレームで伝達されない。当該値は、現フレームグループの全体デューレーションにおいて一定である。
【０５７８】
ＮＵＭ＿ＤＰ：当該６ビットフィールドは、現フレーム内で伝達されるデータパイプの数を示す。当該フィールドの値は１〜６４であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
【０５７９】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内で唯一に識別する。
【０５８０】
ＤＰ＿ＴＹＰＥ：当該３ビットフィールドは、データパイプのタイプを示す。これは、下記の表７によってシグナリングされる。
【表７】
0006309622.tif 000009
【０５８１】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：当該８ビットフィールドは、現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同じＤＰ＿ＧＲＯＵＰ＿ＩＤを有するようになる特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために用いることができる。
【０５８２】
ＢＡＳＥ＿ＤＰ＿ＩＤ：当該６ビットフィールドは、管理階層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤが示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであるか、サービスシグナリングデータのみを伝達する専用データパイプであってもよい。
【０５８３】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表８によってシグナリングされる。
【表８】
0006309622.tif 000010
【０５８４】
ＤＰ＿ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅ  ｒａｔｅ）を示す。コードレート（ｃｏｄｅ  ｒａｔｅ）は、下記の表９によってシグナリングされる。
【表９】
0006309622.tif 000011
【０５８５】
ＤＰ＿ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は、下記の表１０によってシグナリングされる。
【表１０】
0006309622.tif 000012
【０５８６】
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：当該１ビットフィールドは、ＳＳＤモードが関連したデータパイプで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＳＳＤは使用される。当該フィールドの値が０に設定されると、ＳＳＤは使用されない。
【０５８７】
次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ現れる。
【０５８８】
ＤＰ＿ＭＩＭＯ：当該３ビットフィールドは、いかなるタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、下記の表１１によってシグナリングされる。
【表１１】
0006309622.tif 000013
【０５８９】
ＤＰ＿ＴＩ＿ＴＹＰＥ：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、一つのタイムインターリービンググループが一つのフレームに該当し、一つ以上のタイムインターリービングブロックを含むことを示す。１の値は、一つのタイムインターリービンググループが一つよりも多いフレームでに伝達され、一つのタイムインターリービングブロックのみを含むことを示す。
【０５９０】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：当該２ビットフィールド（許容された値は、１、２、４、８のみである）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値によって決定される。
【０５９１】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマッピングされるフレームの数であるＰIを示し、タイムインターリービンググループ当たりに１つのタイムインターリービングブロックが存在する（ＮTI＝１）。当該２ビットフィールドで許容されるＰIの値は、下記の表１２に定義される。
【０５９２】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されると、当該フィールドは、タイムインターリービンググループ当たりにタイムインターリービングブロックの数ＮTIを示し、フレーム当たりに一つのタイムインターリービンググループが存在する（ＰI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１２に定義される。
【表１２】
0006309622.tif 000014
【０５９３】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩJUMP）を示し、許容された値は、１、２、４、８（該当する２ビットフィールドはそれぞれ、００、０１、１０、１１）である。フレームグループの全てのフレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１、５、９、１３などのフレームに現れると、当該フィールドの値は４に設定される。全てのフレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。
【０５９４】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：当該１ビットフィールドは、タイムインターリーバ５０５０の可用性を決定する。データパイプに対してタイムインターリービングが使用されないと、当該フィールド値は１に設定される。反面、タイムインターリービングが使用されると、当該フィールド値は０に設定される。
【０５９５】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：当該５ビットフィールドは、現データパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は、０〜３１である。
【０５９６】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：当該１０ビットフィールドは、当該データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。当該フィールドの値は、ＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同じ範囲を有する。
【０５９７】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、下記の表１３によってシグナリングされる。
【表１３】
0006309622.tif 000015
【０５９８】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは、下記の表１４によってシグナリングされる。
【表１４】
0006309622.tif 000016
【０５９９】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、下記の表１５によってシグナリングされる。
【表１５】
0006309622.tif 000017
【０６００】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングがインプットフォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表１６によってシグナリングされる。
【表１６】
0006309622.tif 000018
【０６０１】
ＤＮＰ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、下記の表１７によってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
【表１７】
0006309622.tif 000019
【０６０２】
ＩＳＳＹ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、下記の表１８によってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
【表１８】
0006309622.tif 000020
【０６０３】
ＨＣ＿ＭＯＤＥ＿ＴＳ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、下記の表１９によってシグナリングされる。
【表１９】
0006309622.tif 000021
【０６０４】
ＨＣ＿ＭＯＤＥ＿ＩＰ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（「０１」）に設定される場合にＩＰヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、下記の表２０によってシグナリングされる。
【表２０】
0006309622.tif 000022
【０６０５】
ＰＩＤ：当該１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１又は１０に設定される場合にＴＳヘッダー圧縮のためのＰＩＤ数を示す。
【０６０６】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６０７】
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０６０８】
ＦＩＣ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、ＦＩＣのバージョンナンバーを示す。
【０６０９】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１３ビットフィールドは、ＦＩＣの長さをバイト単位で示す。
【０６１０】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６１１】
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０６１２】
ＮＵＭ＿ＡＵＸ：当該４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが使用されないことを示す。
【０６１３】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６１４】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：当該４ビットは、現補助ストリームのタイプを示すための将来の使用のためにリザーブされる。
【０６１５】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：当該２８ビットフィールドは、補助ストリームをシグナリングするための将来の使用のためにリザーブされる。
【０６１６】
図２６は、本発明の他の実施例に係るＰＬＳ２データを示す。
【０６１７】
図２６は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は、一つのフレームグループのデューレーションにおいて変化可能である一方、フィールドのサイズは一定である。
【０６１８】
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は次のとおりである。
【０６１９】
ＦＲＡＭＥ＿ＩＮＤＥＸ：当該５ビットフィールドは、スーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
【０６２０】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナリングされる値によって示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、１の値は、次のスーパーフレームに変化があることを示す。
【０６２１】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナリングされる値によって示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、０００１の値は、次のスーパーフレームに変化があることを示す。
【０６２２】
ＲＥＳＥＲＶＥＤ：当該１６ビットフィールドは、将来の使用のためにリザーブされる。
【０６２３】
次のフィールドは、現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰにおけるループ（ｌｏｏｐ）に現れる。
【０６２４】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でデータパイプを唯一に示す。
【０６２５】
ＤＰ＿ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初のの開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、下記の表２１に示すとおり、フィジカルプロファイル及びＦＦＴサイズによって異なる長さを有する。
【表２１】
0006309622.tif 000023
【０６２６】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：当該１０ビットフィールドは、現データパイプに対する現タイムインターリービンググループでＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は、０〜１０２３である。
【０６２７】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６２８】
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
【０６２９】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームでＥＡＣの存在を示す。当該ビットは、プリアンブルでＥＡＣ＿ＦＬＡＧと同一の値である。
【０６３０】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：当該８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。
【０６３１】
ＥＡＣ＿ＦＬＡＧフィールドが１と同一であれば、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０と同一であれば、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
【０６３２】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１２ビットフィールドは、ＥＡＣの長さをバイトで示す。
【０６３３】
ＥＡＣ＿ＣＯＵＮＴＥＲ：当該１２ビットフィールドは、ＥＡＣが到達するフレーム前のフレームの数を示す。
【０６３４】
次のフィールドは、ＡＵＸ＿ＦＬＡＧフィールドが１と同一である場合にのみ現れる。
【０６３５】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：当該４８ビットフィールドは、補助ストリームをシグナリングするための将来の使用のためにリザーブされる。当該フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０６３６】
ＣＲＣ＿３２：全体ＰＬＳ２に適用される３２ビットエラー検出コード。
【０６３７】
図２７は、本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ）構造を示す。
【０６３８】
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームにおいてＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は最初に、一つ以上のＦＳＳにマッピングされる。続いて、ＥＡＣが存在すると、ＥＡＣセルは直後のＰＬＳフィールドにマッピングされる。次に、ＦＩＣが存在すると、ＦＩＣセルがマッピングされる。データパイプは、ＰＬＳの次にマッピングされたり、ＥＡＣ又はＦＩＣが存在する場合、ＥＡＣ又はＦＩＣの後にマッピングされる。タイプ１データパイプが最初にマッピングされ、タイプ２データパイプがその次にマッピングされる。データパイプのタイプの具体的な内容は後述する。一部の場合、データパイプは、ＥＡＳに対する一部の特殊データ又はサービスシグナリングデータを伝達することができる。補助ストリーム又はストリームは、存在するなら、データパイプの次にマッピングされ、そこには順にダミーセルが続く。前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順序で全て一緒にマッピングすると、フレームでセル容量を正確に満たす。
【０６３９】
図２８は、本発明の一実施例に係るＰＬＳマッピングを示す。
【０６４０】
ＰＬＳセルはＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングされる。ＰＬＳの占めるセルの数によって、一つ以上のシンボルがＦＳＳと指定され、ＦＳＳの数ＮFSSは、ＰＬＳ１におけるＮＵＭ＿ＦＳＳによってシグナリングされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳにおいて重大な事項であるが、ＦＳＳは、高いパイロット密度を有しているので、高速同期化、及びＦＳＳ内における周波数のみのインターポレーション（ｉｎｔｅｒｐｏｌｏａｔｉｏｎ、補間）を可能にする。
【０６４１】
ＰＬＳセルは、図示しているように、下方に向いて、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングされる。ＰＬＳ１セルは最初に、一番目のＦＳＳの一番目のセルから始まって、セルインデックスの昇順でマッピングされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、最初のＦＳＳの最後のセルインデックスまで下方に続けてマッピングされる。必要なＰＬＳセルの総数が、一つのＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアの数を超えると、マッピングは、次のＦＳＳに進み、最初のＦＳＳと全く同じ方式で続いて行われる。
【０６４２】
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、ＥＡＣ及びＦＩＣは、ＰＬＳとノーマルデータパイプとの間に配置される。
【０６４３】
以下では、本発明の一実施例に係るＦＥＣ構造及びエンコーディングについて説明する。前述したように、データＦＥＣエンコーダは、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示のＦＥＣ構造はＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに該当する同一値を有する。
【０６４４】
上述したとおり、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋbchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコーディングされたＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０６４５】
Ｎldpcの値は６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
【０６４６】
下記の表２２及び表２３は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。
【表２２】
0006309622.tif 000024
【表２３】
0006309622.tif 000025
【０６４７】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次のとおりである。
【０６４８】
１２−エラー訂正ＢＣＨコードがＢＢＦの外部エンコーディングに用いられる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は、全ての多項式をかけることによって得られる。
【０６４９】
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコーディングするために用いられる。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）がそれぞれのＩldpc（ＢＣＨ−エンコーディングされたＢＢＦ）から組織的にエンコーディングされ、Ｉldpcに添付される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。
【数２】
0006309622.tif 000026
【０６５０】
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２２及び表２３にそれぞれ与えられる。
【０６５１】
ロングＦＥＣＢＬＯＣＫに対してＮldpc−Ｋldpcパリティビットを計算する具体的な手順は、次のとおりである。
【０６５２】
１）パリティビット初期化
【数３】
0006309622.tif 000027
【０６５３】
２）パリティーチェックマトリクスのアドレスの一番目の行で特定されたパリティビットアドレスにおいて一番目の情報ビットｉ0を累算（ａｃｃｕｍｕｌａｔｅ）する。パリティーチェックマトリクスのアドレスの詳細な内容は、後述する。例えば、比率１３／１５に対して、
【数４】
0006309622.tif 000028
【０６５４】
３）次の３５９個の情報ビットｉs、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビットアドレスでｉsを累算（ａｃｃｕｍｕｌａｔｅ）する。
【数５】
0006309622.tif 000029
【０６５５】
ここで、ｘは、一番目のビットｉ0に該当するパリティビット累算器のアドレスを表し、Ｑldpcは、パリティーチェックマトリクスのアドレスで特定されたコードレート（ｃｏｄｅ  ｒａｔｅ）依存定数である。上記例である、比率１３／１５に対する、したがって情報ビットｉ1に対するＱldpc＝２４に続いて、次の動作が実行される。
【数６】
0006309622.tif 000030
【０６５６】
４）３６１番目の情報ビットｉ360に対して、パリティビット累算器のアドレスは、パリティーチェックマトリクスのアドレスの二番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉs、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器のアドレスは、式６から得られる。ここで、ｘは、情報ビットｉ360に該当するパリティビット累算器のアドレス、すなわち、パリティーチェックマトリクスの二番目の行のエントリーを表す。
【０６５７】
５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティーチェックマトリクスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めるのに用いられる。
【０６５８】
全ての情報ビットが利用された後、最終パリティビットが次のように得られる。
【０６５９】
６）ｉ＝１から始まって次の動作を順次に実行する。
【数７】
0006309622.tif 000031
【０６６０】
ここで、ｐi、ｉ＝０，１，．．．Ｎldpc−Ｋldpc−１の最終コンデンツは、パリティビットｐiと同一である。
【表２４】
0006309622.tif 000032
【０６６１】
表２４を表２５に代え、且つロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスを、ショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスに代える以外は、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔＬＤＰＣエンコーディング手順に従う。
【表２５】
0006309622.tif 000033
【０６６２】
図２９は、本発明の一実施例に係るタイムインターリービングを示す。
【０６６３】
（ａ）乃至（ｃ）は、タイムインターリービングモードの例を示す。
【０６６４】
タイムインターリーバは、データパイプレベルで動作する。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定されてもよい。
【０６６５】
ＰＬＳ２−ＳＴＡＴデータの一部に現れる次のパラメータはタイムインターリービングを構成する。
【０６６６】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０又は１）：タイムインターリービングモードを示す。０は、タイムインターリービンググループ当たりに複数のタイムインターリービングブロック（一つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、一つのタイムインターリービンググループは一つのフレームに（フレーム間インターリービング無しで）直接マッピングされる。１は、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックのみを有するモードを示す。この場合、タイムインターリービングブロックは、一つ以上のフレームにわたって拡散される（フレーム間インターリービング）。
【０６６７】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝「０」てあれば、当該パラメータは、タイムインターリービンググループ当たりにタイムインターリービングブロックの数ＮTIである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝「１」である場合、当該パラメータは、一つのタイムインターリービンググループから拡散されるフレームの数ＰIである。
【０６６８】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりにＸＦＥＣＢＬＯＣＫの最大数を示す。
【０６６９】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１，２，４，８）：与えられたフィジカルプロファイルの同じデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩJUMPを示す。
【０６７０】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０又は１）：タイムインターリービングがデータフレームに利用されないと、当該パラメータは１に設定される。タイムインターリービングが利用されると、０に設定される。
【０６７１】
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫは、データグループの一つのタイムインターリービンググループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
【０６７２】
タイムインターリービングがデータフレームに利用されないと、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかし、スケジューラからのダイナミック（ｄｙｎａｍｉｃ、動的）構成情報のためのディレーコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロックは相変らず必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、タイムインターリービンググループにグルーピングされる。すなわち、それぞれのタイムインターリービンググループは、整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（ｄｙｎａｍｉｃ、動的）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎのタイムインターリービンググループに存在するＸＦＥＣＢＬＯＣＫの数はＮxBLOCK_Group（ｎ）と表し、ＰＬＳ２−ＤＹＮデータにおいてＤＰ＿ＮＵＭ＿ＢＬＯＣＫでシグナリングされる。この時、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ（ｎ）は、最小値０から、最大の値が１０２３である最大値ＮxBLOCK_Group_MAX（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに当該）まで変化してもよい。
【０６７３】
それぞれのタイムインターリービンググループは、一つのフレームに直接マッピングされたり、ＰI個のフレームにわたって拡散される。また、それぞれのタイムインターリービンググループは、一つ以上（ＮTI個）のタイムインターリービングブロックに分離される。ここで、それぞれのタイムインターリービングブロックは、タイムインターリーバメモリの一つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは、若干の異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービングブロックに分離されると、タイムインターリービンググループは一つのフレームにのみ直接マッピングされる。下記の表２６に示すように、タイムインターリービングには３つのオプションがある（タイムインターリービングを省略する追加オプションは除く）。
【表２６】
0006309622.tif 000034
【０６７４】
一般に、タイムインターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファーとしても働くことができる。これは、それぞれのデータパイプに対して２個のメモリバンクによって達成される。一番目のタイムインターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み出される間に、二番目のタイムインターリービングブロックが二番目のバンクに書き込まれる。
【０６７５】
タイムインターリービングは、ツイストされた行−列ブロックインターリーバである。ｎ番目のタイムインターリービンググループのｓ番目のタイムインターリービングブロックに対して、列の数ＮcがＮxBLOCK_TI（ｎ，ｓ）と同一であるが、 タイムインターリービングメモリの行の数Ｎrは、セルの数Ｎcellsと同一である（すなわち、Ｎr＝Ｎcells）。
【０６７６】
図３０は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
【０６７７】
図３０（ａ）は、タイムインターリーバにおける書き込み動作を示し、図３０（ｂ）は、タイムインターリーバにおける読み出し動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫは、タイムインターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作がつながる。そして、インターリービングアレイで、セルが対角線方向に読み出される。（ｂ）に示すように、一番目の行から（最も左側列から始まって行に沿って右に）最後の行まで対角線方向読み出しが進行される間に、Ｎr個のセルが読み出される。
【数８】
0006309622.tif 000035
【０６７８】
【数９】
0006309622.tif 000036
【０６７９】
結果的に、読み出されるセル位置は、座標
【数１０】
0006309622.tif 000037
によって算出される。
【０６８０】
図３１は、本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す。
【０６８１】
より具体的に、図３１は、
【数１１】
0006309622.tif 000038
のとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリでインターリービングアレイを示す。
【０６８２】
【数１２】
0006309622.tif 000039
【０６８３】
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝「０」、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝「１」、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝「１」、すなわち、ＮＴＩ＝１、ＩＪＵＭＰ＝１、ＰＩ＝１によってＰＬＳ２−ＳＴＡＴデータでシグナリングされる。それぞれＮｃｅｌｌｓ＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３，ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６，ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナリングされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナリングされ、これは
【数１３】
0006309622.tif 000040
につながる。
【０６８４】
一つのＯＦＤＭシンボルに該当するデータ上で動作するフリケンシーインターリーバの目的は、フレームビルダーから受信されたデータセルを無作為にインターリービングすることによってフリケンシーダイバーシティを提供することである。一つのフレームで最大インターリービング利得を得るために、２つの順次的なＯＦＤＭシンボルからなる全てのＯＦＤＭシンボルペアに対して異なるインターリービングシーケンスが用いられる。
【０６８５】
したがって、本発明の一実施例に係るフリケンシーインターリーバは、シンボルペアに対応するデータに適用するためのインターリービングアドレスを生成するためのインターリービングアドレスジェネレーターを含むことができる。
【０６８６】
図３２は、本発明の一実施例に係る各ＦＦＴモードによるメイン−ＰＲＢＳジェネレーター及びサブ−ＰＲＢＳジェネレーターで構成されたインターリービングアドレスジェネレーターのブロックダイアグラムを示す図である。
【０６８７】
（ａ）は、８Ｋ ＦＦＴモードに対するインターリービングアドレスジェネレーターのブロックダイアグラムを示し、（ｂ）は、１６Ｋ ＦＦＴモードに対するインターリービングアドレスジェネレーターのブロックダイアグラムを示し、（ｃ）は、３２Ｋ ＦＦＴモードに対するインターリービングアドレスジェネレーターのブロックダイアグラムを示す。
【０６８８】
ＯＦＤＭシンボルペアに対するインターリービング過程は、一つのインターリービングシーケンスを利用し、次のように説明される。
【数１４】
0006309622.tif 000041
このとき、ｘm,l,pは、ｍ番目のフレームでｌ番目のＯＦＤＭシンボルのｐ番目のセルであり、Ｎdataは、データセルの個数である：フレームシグナリングシンボルに対してＮdata＝ＣFSSであり、ノーマルデータに対してＮdata＝Ｃdataであり、フレームエッジシンボルに対してＮdata＝ＣFESである。
【数１５】
0006309622.tif 000042
【０６８９】
【数１６】
0006309622.tif 000043
このとき、Ｈl（ｐ）は、ＰＲＢＳジェネレーターによって生成されたインターリービングアドレスである。
【０６９０】
図３３は、本発明の一実施例に係る全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。
【０６９１】
（ａ）は、メイン−ＰＲＢＳを示し、（ｂ）は、各ＦＦＴモードのためのパラメータＮｍａｘを示す。
【０６９２】
図３４は、本発明の一実施例に係るフリケンシーインターリービングのためのインターリービングアドレス及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。
【０６９３】
（ａ）は、サブ−ＰＲＢＳジェネレーターを示し、（ｂ）は、フリケンシーインターリービングのためのインターリービングアドレスを示す。本発明の一実施例に係るサイクリックシフト値は、シンボルオフセットと呼ぶことができる。
【０６９４】
図３５は、本発明の一実施例に係るタイムインターリーバの書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す。
【０６９５】
図３５は、２つのＴＩグループに対する書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す。
【０６９６】
図面の左側に示すブロックは、ＴＩメモリアドレスアレイ（ｍｅｍｏｒｙ  ａｄｄｒｅｓｓ  ａｒｒａｙ）を示し、図面の右側に示すブロックは、連続した２つのＴＩグループに対してそれぞれバーチャル（ｖｉｒｔｕａｌ）ＦＥＣブロックがＴＩグループの最前方にそれぞれ２個及び１個が挿入された場合の書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す。
【０６９７】
以下、ＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）モードによってコンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（Ｂｌｏｃｋ  Ｉｎｔｅｒｌｅａｖｅｒ，ＢＩ）を選択的に使用したり、両方とも使用するタイムインターリーバの構造及びタイムインターリービング方法を説明する。本発明の一実施例に係るＰＬＰは、上述したＤＰと同じ概念で使われるフィジカルパス（ｐｈｙｓｉｃａｌ  ｐａｔｈ）であり、呼称は設計者の意図によって変更可能である。
【０６９８】
本発明の一実施例に係るＰＬＰモードは、放送信号送信機又は放送信号送信装置で処理するＰＬＰ個数によって、シングルＰＬＰ（ｓｉｎｇｌｅ  ＰＬＰ）モード又はマルチプルＰＬＰ（ｍｕｌｔｉｐｌｅ  ＰＬＰ）モードを含むことができる。シングルＰＬＰモードは、放送信号送信装置で処理するＰＬＰ個数が一つである場合を意味する。シングルＰＬＰモードはシングルＰＬＰと呼ぶことができる。
【０６９９】
マルチプルＰＬＰモードは、放送信号送信装置で処理するＰＬＰ個数が一つ以上である場合であり、マルチプルＰＬＰモードは、マルチプルＰＬＰと呼ぶこともできる。
【０７００】
本発明ではＰＬＰモードによって異なるタイムインターリービング方法を適用するタイムインターリービングをハイブリッドタイムインターリービング（Ｈｙｂｒｉｄ  Ｔｉｍｅ  Ｉｎｔｅｒｌｅａｖｉｎｇ）と呼ぶことができる。本発明の一実施例に係るハイブリッドタイムインターリービングは、マルチプルＰＬＰモードの場合、各ＰＬＰ別に（或いは、ＰＬＰレベルで）適用される。
【０７０１】
図３６は、ＰＬＰ個数によって適用するインターリービングタイプを表で示す図である。
【０７０２】
本発明の一実施例に係るタイムインターリーバは、ＰＬＰ＿ＮＵＭの値に基づいてインターリービングタイプ（Ｉｎｔｅｒｌｅａｖｉｎｇ  ｔｙｐｅ）が決定されてもよい。ＰＬＰ＿ＮＵＭは、ＰＬＰモードを示すシグナリングフィールド（ｓｉｇｎａｌｉｎｇ  ｆｉｅｌｄ）である。ＰＬＰ＿ＮＵＭの値が１である場合、ＰＬＰモードはシングルＰＬＰである。本発明の一実施例に係るシングルＰＬＰは、コンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）のみが適用されてもよい。
【０７０３】
ＰＬＰ＿ＮＵＭの値が１よりも大きい場合、ＰＬＰモードは、マルチプルＰＬＰである。本発明の一実施例に係るマルチプルＰＬＰは、コンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（Ｂｌｏｃｋ  Ｉｎｔｅｒｌｅａｖｅｒ，ＢＩ）が適用されてもよい。この場合、コンボリューションインターリーバはインターフレームインターリービング（Ｉｎｔｅｒ  ｆｒａｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックインターリーバはイントラフレームインターリービング（Ｉｎｔｒａ  ｆｒａｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。
【０７０４】
図３７は、上述したハイブリッドタイムインターリーバ構造の第１実施例を含むブロック図である。
【０７０５】
第１実施例に係るハイブリッドタイムインターリーバは、ブロックインターリーバ（ＢＩ）とコンボリューションインターリーバ（ＣＩ）を含むことができる。本発明のタイムインターリーバは、ＢＩＣＭチェーン（ＢＩＣＭ  ｃｈａｉｎ）ブロックとフレームビルダー（Ｆｒａｍｅ  Ｂｕｉｌｄｅｒ）との間に位置し得る。
【０７０６】
図３７及び図３８に示すＢＩＣＭチェーンブロックは、図１９に示すＢＩＣＭブロックの処理ブロック５０００のうちタイムインターリーバ５０５０以外のブロックを含むことができる。図３７及び図３８に示すフレームビルダーは、図１８のフレームビルディング１０２０ブロックと同じ役割を担うことができる。
【０７０７】
上述したとおり、ハイブリッドタイムインターリーバ構造の第１実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１である場合、ブロックインターリーバは適用されず（ブロックインターリーバオフ（ｏｆｆ））、コンボリューションインターリーバだけ適用される。ＰＬＰ＿ＮＵＭ＞１の場合、ブロックインターリーバとコンボリューションインターリーバが全て適用（ブロックインターリーバオン（ｏｎ））されてもよい。ＰＬＰ＿ＮＵＭ＞１の場合、適用されるコンボリューションインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１の場合に適用されるコンボリューションインターリーバの構造及び動作と同一又は類似してもよい。
【０７０８】
図３８は、上述したハイブリッドタイムインターリーバ構造の第２実施例を含むブロック図である。
【０７０９】
ハイブリッドタイムインターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３７で説明した内容と同一である。ハイブリッドタイムインターリーバ構造の第２実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定され得る。第２実施例に係るハイブリッドタイムインターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この時、ＰＬＰ＿ＮＵＭ＝１の場合とＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションインターリーバの構造及び動作が互いに異なってもよい。
【０７１０】
図３９は、ハイブリッドタイムデインターリーバの構造の第１実施例を含むブロック図である。
【０７１１】
第１実施例に係るハイブリッドタイムデインターリーバは、上述した第１実施例に係るハイブリッドタイムインターリーバの逆動作に相応する動作を行うことができる。したがって、図３９の第１実施例に係るハイブリッドタイムデインターリーバは、コンボリューションデインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  ｄｅｉｎｔｅｒｌｅａｖｅｒ，ＣＤＩ）とブロックデインターリーバ（Ｂｌｏｃｋ  ｄｅｉｎｔｅｒｌｅａｖｅｒ，ＢＤＩ）を含むことができる。
【０７１２】
ＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションデインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１の場合に適用されるコンボリューションデインターリーバの構造及び動作と同一又は類似してもよい。
【０７１３】
ハイブリッドタイムデインターリーバ構造の第１実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１の場合、ブロックデインターリーバは適用されず（ブロックデインターリーバオフ（ｏｆｆ））、コンボリューションデインターリーバだけ適用される。
【０７１４】
ハイブリッドタイムデインターリーバのコンボリューションデインターリーバは、インターフレームデインターリービング（Ｉｎｔｅｒ  ｆｒａｍｅ  ｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックデインターリーバは、イントラフレームデインターリービング（Ｉｎｔｒａ  ｆｒａｍｅ  ｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。インターフレームデインターリービング及びイントラフレームデインターリービングの具体的な内容は、前述した内容と同一である。
【０７１５】
図３９及び図４０に示すＢＩＣＭデコーディング（ＢＩＣＭ  ｄｅｃｏｄｉｎｇ）ブロックは、図３７及び図３８のＢＩＣＭチェーン（ＢＩＣＭ  ｃｈａｉｎ）ブロックの逆動作を行うことができる。
【０７１６】
図４０は、ハイブリッドタイムデインターリーバの構造の第２実施例を含むブロック図である。
【０７１７】
第２実施例に係るハイブリッドタイムデインターリーバは、上述した第２実施例に係るハイブリッドタイムインターリーバの逆動作に相応する動作を行うことができる。ハイブリッドタイムデインターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３９で説明した内容と同一であってもよい。
【０７１８】
ハイブリッドタイムデインターリーバ構造の第２実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。第２実施例に係るハイブリッドタイムデインターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この時、ＰＬＰ＿ＮＵＭ＝１の場合とＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションデインターリーバの構造及び動作が互いに異なってもよい。
【０７１９】
図４１は、本発明の一実施例に係るハイブリッド放送受信装置を示す図である。ハイブリッド放送システムは、地上波放送網及びインターネット網を連動して放送信号を送信することができる。ハイブリッド放送受信装置は、地上波放送網（ブロードキャスト）及びインターネット網（ブロードバンド）を介して放送信号を受信することができる。ハイブリッド放送受信装置は、フィジカルレイヤモジュール、フィジカルレイヤＩ／Ｆモジュール、サービス／コンテンツ取得コントローラ、インターネットアクセス制御モジュール、シグナリングデコーダ、サービスシグナリングマネジャー、サービスガイドマネジャー、アプリケーションシグナリングマネジャー、警報信号マネジャー、警報信号パーサー、ターゲッティング信号パーサー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネントシンクロナイザー、ターゲッティングプロセッサ、アプリケーションプロセッサ、Ａ／Ｖプロセッサ、デバイスマネジャー、データシェアリング及びコミュニケーションユニット、再分配モジュール、コンパニオンデバイス及び／又は外部モジュールを含むことができる。
【０７２０】
フィジカルレイヤモジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｍｏｄｕｌｅ（ｓ））は、地上波放送チャネルを介して放送関連信号を受信及び処理し、それを適切な形態に変換してフィジカルレイヤＩ／Ｆモジュールに伝達することができる。
【０７２１】
フィジカルレイヤＩ／Ｆモジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｉ／Ｆ  Ｍｏｄｕｌｅ（ｓ））は、フィジカルレイヤモジュールから取得した情報からＩＰデータグラムを取得することができる。また、フィジカルレイヤＩ／Ｆモジュールは、取得されたＩＰデータグラムなどを特定フレーム（例えば、ＲＳ  Ｆｒａｍｅ、ＧＳＥなど）に変換することができる。
【０７２２】
サービス／コンテンツ取得コントローラ（Ｓｅｒｖｉｃｅ／Ｃｏｎｔｅｎｔ  Ａｃｑｕｉｓｉｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）は、ｂｒｏａｄｃａｓｔ及び／又はｂｒｏａｄｂａｎｄチャネルを介したサービス、コンテンツ及びこれと関連したシグナリングデータ取得のための制御動作を行うことができる。
【０７２３】
インターネットアクセス制御モジュール（Ｉｎｔｅｒｎｅｔ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｍｏｄｕｌｅ（ｓ））は、Ｂｒｏａｄｂａｎｄチャネルを介してサービス、コンテンツなどを取得するための受信機動作を制御することができる。
【０７２４】
シグナリングデコーダ（Ｓｉｇｎａｌｉｎｇ  Ｄｅｃｏｄｅｒ）は、ｂｒｏａｄｃａｓｔチャネルなどを介して取得したシグナリング情報をデコーティングすることができる。
【０７２５】
サービスシグナリングマネジャー（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからサービススキャン及びサービス／コンテンツなどと関連したシグナリング情報を抽出、パーシング及び管理することができる。
【０７２６】
サービスガイドマネジャー（Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ  Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからａｎｎｏｕｎｃｅｍｅｎｔ情報を抽出し、ＳＧ（Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）ｄａｔａｂａｓｅ管理し、ｓｅｒｖｉｃｅ  ｇｕｉｄｅを提供することができる。
【０７２７】
アプリケーションシグナリングマネジャー（Ａｐｐ  Ｓｉｇｎａｌｉｎｇ  Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからアプリケーション取得などと関連したシグナリング情報を抽出、パーシング及び管理することができる。
【０７２８】
警報信号パーサー（Ａｌｅｒｔ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからａｌｅｒｔｉｎｇと関連したシグナリング情報を抽出、パーシング及び管理することができる。
【０７２９】
ターゲッティング信号パーサー（Ｔａｒｇｅｔｉｎｇ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからサービス／コンテンツ個人化或いはターゲッティングに関連したシグナリング情報を抽出、パーシング及び管理することができる。また、ターゲッティング信号パーサーは、パーシングされたシグナリング情報をターゲッティングプロセッサに伝達できる。
【０７３０】
ストリーミングメディアエンジン（Ｓｔｒｅａｍｉｎｇ  Ｍｅｄｉａ  Ｅｎｇｉｎｅ）は、ＩＰデータグラムなどからＡ／Ｖストリーミングのためのオーディオ／ビデオデータの抽出及びデコーティングを行うことができる。
【０７３１】
非実時間ファイルプロセッサ（Ｎｏｎ−ｒｅａｌ  ｔｉｍｅ  Ｆｉｌｅ  Ｐｒｏｃｅｓｓｏｒ）は、ＩＰデータグラムなどからＮＲＴデータ及びａｐｐｌｉｃａｔｉｏｎなどのファイル形態データわ抽出、デコーディング及び管理することができる。
【０７３２】
コンポーネントシンクロナイザー（Ｃｏｍｐｏｎｅｎｔ  Ｓｙｎｃｈｒｏｎｉｚｅｒ）は、ストリーミングオーディオ／ビデオデータ及びＮＲＴデータなどのコンテンツ及びサービスを同期化することができる。
【０７３３】
ターゲッティングプロセッサ（Ｔａｒｇｅｔｉｎｇ  Ｐｒｏｃｅｓｓｏｒ）は、ターゲッティング信号パーサーから受信したターゲッティングシグナリングデータに基づいてサービス／コンテンツの個人化関連演算を処理することができる。
【０７３４】
アプリケーションプロセッサ（Ａｐｐ  Ｐｒｏｃｅｓｓｏｒ）は、ａｐｐｌｉｃａｔｉｏｎ関連情報及びダウンロードされたａｐｐｌｉｃａｔｉｏｎ状態及びディスプレイパラメータを処理することができる。
【０７３５】
Ａ／Ｖプロセッサ（Ａ／Ｖ  Ｐｒｏｃｅｓｓｏｒ）は、デコーディングされたａｕｄｉｏ及びｖｉｄｅｏ ｄａｔａ、ａｐｐｌｉｃａｔｉｏｎデータなどに基づいてオーディオ／ビデオレンダリング関連動作を行うことができる。
【０７３６】
デバイスマネジャー（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｒ）は、外部装置との連結及びデータ交換動作を行うことができる。また、デバイスマネジャーは、連動可能な外部装置の追加／削除／更新などを含む、外部装置に対する管理動作を行うことができる。
【０７３７】
データシェアリング及びコミュニケーションユニット（Ｄａｔａ  Ｓｈａｒｉｎｇ  ＆  Ｃｏｍｍ．）は、ハイブリッド放送受信機と外部装置間のデータ伝送及び交換に関連した情報を処理することができる。ここで、伝送及び交換可能なデータは、シグナリング、Ａ／Ｖデータなどであってもよい。
【０７３８】
再分配モジュール（Ｒｅｄｉｓｔｒｉｂｕｔｉｏｎ  Ｍｏｄｕｌｅ（ｓ））は、放送受信機が地上波放送信号を直接受信できない場合、次世代放送サービス及びコンテンツに対する関連情報を取得することができる。また、再分配モジュールは、放送受信機が地上波放送信号を直接受信できない場合、次世代放送システムによる放送サービス及びコンテンツ取得を支援することができる。
【０７３９】
コンパニオンデバイス（Ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ（ｓ））は、本発明の放送受信機に接続して、オーディオ、ビデオ、又はシグナリング含むデータを共有することができる。コンパニオンデバイスは、放送受信機に接続した外部装置のことを指すことができる。
【０７４０】
外部モジュール（Ｅｘｔｅｒｎａｌ  Ｍａｎａｇｅｍｅｎｔ）は、放送サービス／コンテンツ提供のためのモジュールのことを指すことができ、例えば、次世代放送サービス／コンテンツサーバーであってもよい。外部モジュールは、放送受信機に接続した外部装置のことを指すことができる。
【０７４１】
図４２は、本発明の一実施例に係るハイブリッド放送受信機を示すブロック図である。
【０７４２】
ハイブリッド放送受信機は、次世代放送システムのＤＴＶサービスで地上波放送とブロードバンドとの連動を用いたハイブリッド放送サービスを受信することができる。ハイブリッド放送受信機は、地上波放送で伝送される放送オーディオ／ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ，Ａ／Ｖ）コンテンツを受信し、これと関連したｅｎｈａｎｃｅｍｅｎｔ  ｄａｔａ或いは放送Ａ／Ｖコンテンツの一部をブロードバンドわ介して実時間で受信することができる。本明細書では、放送オーディオ／ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ，Ａ／Ｖ）コンテンツをメディアコンテンツと呼ぶこともできる。
【０７４３】
ハイブリッド放送受信機は、物理層コントローラ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｃｏｎｔｒｏｌｌｅｒ）Ｄ５５０１０、チューナー（Ｔｕｎｅｒ）Ｄ５５０２０、物理的フレームパーサー（Ｐｈｙｓｉｃａｌ  Ｆｒａｍｅ  Ｐａｒｓｅｒ）Ｄ５５０３０、連結層パーサー（Ｌｉｎｋ  Ｌａｙｅｒ  Ｆｒａｍｅ  Ｐａｒｓｅｒ）Ｄ５５０４０、ＩＰ／ＵＤＰデータグラムフィルター（ＩＰ／ＵＤＰ  Ｄａｔａｇｒａｍ  Ｆｉｌｔｅｒ）Ｄ５５０５０、ＡＴＳＣ３．０デジタルテレビコントロールエンジン（ＡＴＳＣ３．０  ＤＴＶ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ）Ｄ５５０６０、ＡＬＣ／ＬＣＴ＋クライアント（ＡＬＣ／ＬＣＴ＋  Ｃｌｉｅｎｔ）Ｄ５５０７０、タイミング制御部（Ｔｉｍｉｎｇ  Ｃｏｎｔｒｏｌ）Ｄ５５０８０、シグナリングパーサー（Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）Ｄ５５０９０、ＤＡＳＨクライアント（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ  Ｃｌｉｅｎｔ，ＤＡＳＨ  Ｃｌｉｅｎｔ）Ｄ５５１００、ＨＴＴＰ接続クライアント（ＨＴＴＰ  Ａｃｃｅｓｓ  Ｃｌｉｅｎｔ）Ｄ５５１１０、ＩＳＯ ＢＭＦＦパーサー（ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ  Ｐａｒｓｅｒ，ＩＳＯ  ＢＭＦＦ  Ｐａｒｓｅｒ）Ｄ５５１２０及び／又はメディアデコーダ（Ｍｅｄｉａ  Ｄｅｃｏｄｅｒ）Ｄ５５１３０を含むことができる。
【０７４４】
物理層コントローラＤ５５０１０は、ハイブリッド放送受信機が受信しようとする地上波放送チャネルのラジオ周波数（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ、ＲＦ）情報などを用いて、チューナーＤ５５０２０、物理的フレームパーサーＤ５５０３０などの動作を制御することができる。
【０７４５】
チューナーＤ５５０２０は、地上波放送チャネルを介して放送関連信号を受信及び処理し、それを適切な形態に変換することができる。例えば、チューナーＤ５５０２０は、受信した地上波放送信号を物理的フレーム（Ｐｈｙｓｉｃａｌ  Ｆｒａｍｅ）に変換することができる。
【０７４６】
物理的フレームパーサーＤ５５０３０は、受信した物理的フレームをパーシングし、それに関連したプロセシングによって連結層フレーム（Ｌｉｎｋ  Ｌａｙｅｒ  Ｆｒａｍｅ）を取得することができる。
【０７４７】
連結層パーサーＤ５５０４０は、連結層フレームから連結層シグナリング（Ｌｉｎｋ  Ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）などを取得したり、ＩＰ／ＵＤＰデータグラムを取得するための関連演算を行うことができる。連結層パーサーＤ５５０４０は少なくとも一つのＩＰ／ＵＤＰデータグラムを出力することができる。
【０７４８】
ＩＰ／ＵＤＰデータグラムフィルターＤ５５０５０は、受信した少なくとも一つのＩＰ／ＵＤＰデータグラムから特定ＩＰ／ＵＤＰデータグラムをフィルタリングすることができる。すなわち、ＩＰ／ＵＤＰデータグラムフィルターＤ５５０５０は、連結層パーサーＤ５５０４０から出力された少なくとも一つのＩＰ／ＵＤＰデータグラムのうち、ＡＴＳＣ ３．０デジタルテレビコントロールエンジンＤ５５０６０によって選択されたＩＰ／ＵＤＰデータグラムを選択的にフィルタリングすることができる。ＩＰ／ＵＤＰデータグラムフィルターＤ５５０５０はＡＬＣ／ＬＣＴ＋などのアプリケーション層伝送プロトコルパケットを出力することができる。
【０７４９】
ＡＴＳＣ ３．０デジタルテレビコントロールエンジンＤ５５０６０は、各ハイブリッド放送受信機に含まれたモジュール間のインターフェースを担当することができる。また、ＡＴＳＣ ３．０デジタルテレビコントロールエンジンＤ５５０６０は、各モジュールに必要なパラメータなどを各モジュールに伝達し、これによって各モジュールの動作を制御することができる。本発明でＡＴＳＣ ３．０デジタルテレビコントロールエンジンＤ５５０６０は、メディアプレゼンテーションディスクリプション（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ，ＭＰＤ）及び／又はＭＰＤ ＵＲＬをＤＡＳＨクライアントＤ５５１００に伝達することができる。また、本発明でＡＴＳＣ ３．０デジタルテレビコントロールエンジンＤ５５０６０は、伝送モード（Ｄｅｌｉｖｅｒｙ  ｍｏｄｅ）及び／又は伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ，ＴＳＩ）を、ＡＬＣ／ＬＣＴ＋クライアントＤ５５０７０に伝達することができる。ここで、ＴＳＩは、ＭＰＤ又はＭＰＤ ＵＲＬ関連シグナリングなどのシグナリングメッセージを含む伝送パケットを伝送するセッション、例えば、アプリケーション層伝送プロトコルであるＡＬＣ／ＬＣＴ＋セッション又はＦＬＵＴＥセッションの識別子を示すことができる。また、伝送セッション識別子はＭＭＴのＡｓｓｅｔ ｉｄに対応し得る。
【０７５０】
ＡＬＣ／ＬＣＴ＋クライアントＤ５５０７０は、ＡＬＣ／ＬＣＴ＋などのアプリケーション層伝送プロトコルパケットを処理し、複数のパケットを収集及び処理して一つ以上のＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（ＩＳＯＢＭＦＦ ）オブジェクトを生成することができる。アプリケーション層伝送プロトコルパケットには、ＡＬＣ／ＬＣＴパケット、ＡＬＣ／ＬＣＴ＋パケット、ＲＯＵＴＥパケット、及び／又はＭＭＴＰパケットが含まれ得る。
【０７５１】
タイミング制御部Ｄ５５０８０は、システムタイム情報を含むパケットを処理し、これによってシステムクロックを制御することができる。
【０７５２】
シグナリングパーサーＤ５５０９０は、ＤＴＶ放送サービス関連シグナリングを取得及びパーシングし、パーシングされたシグナリングに基づいてチャネルマップなどを生成して管理することができる。本発明で、シグナリングパーサーは、シグナリング情報から拡張されたＭＰＤ又はＭＰＤ関連情報などをパーシングすることができる。
【０７５３】
ＤＡＳＨクライアントＤ５５１００は、実時間ストリーミング（Ｒｅａｌ−ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ）或いは適応的ストリーミング（Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ）に関連した演算を行うことができる。ＤＡＳＨクライアントＤ５５１００は、ＨＴＴＰ接続クライアントＤ５５１１０を通じてＨＴＴＰサーバーからＤＡＳＨコンテンツを受信することができる。ＤＡＳＨクライアントＤ５５１００は、受信したＤＡＳＨ Ｓｅｇｍｅｎｔなどを処理してＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔオブジェクトを出力することができる。本発明でＤＡＳＨクライアントＤ５５１００は、ＡＴＳＣ ３．０デジタルテレビコントロールエンジンＤ５５０６０に全体Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ＩＤ（Ｆｕｌｌｙ  ｑｕａｌｉｆｉｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ  ＩＤ）又はセグメントＵＲＬを伝達することができる。ここで、全体Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ＩＤは、例えば、ＭＰＤ ＵＲＬ、ｐｅｒｉｏｄ＠ｉｄ及びｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄを結合したＩＤを意味することができる。また、ＤＡＳＨクライアントＤ５５１００は、ＡＴＳＣ ３．０デジタルテレビコントロールエンジンＤ５５０６０からＭＰＤ又はＭＰＤ ＵＲＬを受信することができる。ＤＡＳＨクライアントＤ５５１００は、受信したＭＰＤ又はＭＰＤ ＵＲＬを用いて所望のメディアストリーム又はＤＡＳＨ ＳｅｇｍｅｎｔをＨＴＴＰサーバーから受信することができる。本明細書でＤＡＳＨクライアントＤ５５１００はプロセッサと呼ぶことができる。
【０７５４】
ＨＴＴＰ接続クライアントＤ５５１１０は、ＨＴＴＰサーバーに対して特定情報を要請し、ＨＴＴＰサーバーからこれに対する応答を受信して処理することができる。ここで、ＨＴＴＰサーバーは、ＨＴＴＰ接続クライアントから受信した要請を処理し、これに対する応答を提供することができる。
【０７５５】
ＩＳＯ ＢＭＦＦパーサーＤ５５１２０は、ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ  Ｆｏｒｍａｔオブジェクトからオーディオ／ビデオデータを抽出することができる。
【０７５６】
メディアデコーダＤ５５１３０は、受信したオーディオ及び／又はビデオデータをデコーディングし、デコーディングされたオーディオ／ビデオデータをプレゼンテーションするためのプロセシングを行うことができる。
【０７５７】
本発明のハイブリッド放送受信機が地上波放送網とブロードバンドとの連動を用いたハイブリッド放送サービスを提供するためには、ＭＰＤに対する拡張又は修正が要求される。前述した地上波放送システムは、拡張又は修正されたＭＰＤを送信することができ、ハイブリッド放送受信機は、拡張又は修正されたＭＰＤを用いて放送又はブロードバンドを介してコンテンツを受信することができる。すなわち、ハイブリッド放送受信機は、拡張又は修正されたＭＰＤは地上波放送を介して受信し、ＭＰＤに基づいて地上波放送又はブロードバンドを介してコンテンツを受信することができる。以下では、既存ＭＰＤと比較して、拡張又は修正されたＭＰＤにさらに含まれるべきエレメント及び属性（ａｔｔｒｉｂｕｔｅ）について記述する。以下で、拡張又は修正されたＭＰＤはＭＰＤと記述されてもよい。
【０７５８】
ＭＰＤは、ＡＴＳＣ ３．０サービスを表現するために拡張又は修正されてもよい。拡張又は修正されたＭＰＤは、ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ、Ｃｏｍｍｏｎ＠ｐｒｅｓｅｎｔａｂｌｅ、Ｃｏｍｍｏｎ．Ｔａｒｇｅｔｉｎｇ、Ｃｏｍｍｏｎ．ＴａｒｇｅｔＤｅｖｉｃｅ及び／又はＣｏｍｍｏｎ＠ａｓｓｏｃｉａｔｅｄＴｏをさらに含むことができる。
【０７５９】
ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅは、ＭＰＤに含まれたセグメントのプレゼンテーションタイムのアンカー、すなわち、基礎となる時間を示すことができる。以下で、ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅをＭＰＤの有効時間（ｅｆｆｅｃｔｉｖｅ  ｔｉｍｅ）として用いることができる。ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅは、ＭＰＤに含まれたセグメントのうち最も早い再生時点を示すことができる。
【０７６０】
ＭＰＤは、共通属性及び要素（ｃｏｍｍｏｎ  ａｔｔｒｉｂｕｔｅｓ  ａｎｄ  ｅｌｅｍｅｎｔｓ）をさらに含むことができる。共通属性及び要素は、ＭＰＤ内のＡｄａｐｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎなどに適用されてもよい。Ｃｏｍｍｏｎ＠ｐｒｅｓｅｎｔａｂｌｅは、ＭＰＤが記述しているメディアがプレゼンテーションが可能なコンポーネントであることを示すことができる。
【０７６１】
Ｃｏｍｍｏｎ．Ｔａｒｇｅｔｉｎｇは、ＭＰＤが記述しているメディアのターゲッティング特徴（ｔａｒｇｅｔｉｎｇ  ｐｒｏｐｅｒｔｉｅｓ）及び／又は個別化特徴（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ  ｐｒｏｐｅｒｔｉｅｓ）を示すことができる。
【０７６２】
Ｃｏｍｍｏｎ．ＴａｒｇｅｔＤｅｖｉｃｅは、ＭＰＤが記述しているメディアのターゲットデバイス又は複数のターゲットデバイスを示すことができる。
【０７６３】
Ｃｏｍｍｏｎ＠ａｓｓｏｃｉａｔｅｄＴｏは、ＭＰＤが記述しているメディアに関連したａｄａｐｔａｔｉｏｎＳｅｔ及び／又はｒｅｐｒｅｓｅｎｔａｔｉｏｎを示すことができる。
【０７６４】
また、ＭＰＤに含まれたＭＰＤ＠ｉｄ、Ｐｅｒｉｏｄ＠ｉｄ及びＡｄａｐｔａｔｉｏｎＳｅｔ＠ｉｄは、ＭＰＤが記述しているメディアコンテンツを特定するために要求されてもよい。すなわち、ＤＡＳＨクライアントは、ＭＰＤに基づいて、受信しようとするコンテンツをＭＰＤ＠ｉｄ、Ｐｅｒｉｏｄ＠ｉｄ及びＡｄａｐｔａｔｉｏｎＳｅｔ＠ｉｄで特定してＡＴＳＣ ３．０デジタルテレビコントロールエンジンに伝達することができる。また、ＡＴＳＣ ３．０デジタルテレビコントロールエンジンは、当該コンテンツを受信してＤＡＳＨクライアントに伝達することができる。
【０７６５】
図４３は、本発明の一実施例に係る次世代ハイブリッド放送システムのプロトコルスタックを示す。図示のように、ＩＰベースハイブリッド放送を支援する次世代放送送信システムは、放送サービスのオーディオ或いはビデオデータなどをＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（以下、ＩＳＯ ＢＭＦＦ）でエンカプセレーション（ｅｎｃａｐｓｕｌａｔｉｏｎ）することができる。ここで、エンカプセレーションは、ＤＡＳＨ Ｓｅｇｍｅｎｔ或いはＭＭＴのＭＰＵ（Ｍｅｄｉａ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）などの形態を用いることができる。また、次世代放送システムは、エンカプセレーションされたデータを、放送網とインターネット網に同一に或いは各伝送網の属性によって互いに異ならせて伝送することができる。また、次世代放送システムは、エンカプセレーションされたデータをブロードキャスト又はブロードバンドのうち少なくとも一つを用いて伝送することができる。ブロードキャストを利用する放送網の場合、放送システムはＩＳＯ ＢＭＦＦ形態でエンカプセレーションされたデータを、実時間オブジェクト伝送を支援するａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔプロトコルパケットを用いて伝送することができる。例えば、放送システムは、Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）又はＭＭＴＰの伝送パケット（ｔｒａｎｓｐｏｒｔ  ｐａｃｋｅｔ）などにエンカプセレーションすることができる。そして<放送システムは<エンカプセレーションされたデータをさらにＩＰ／ＵＤＰデータグラムとして生成した後、これを放送信号に乗せて伝送することができる。ブロードバンドを利用する場合、放送システムは、エンカプセレーションされたデータをＤＡＳＨなどのストリーミング技法などに基づいて受信側に伝達することができる。
【０７６６】
これに加えて、放送システムは、放送サービスのシグナリング情報を次のような方法で伝送することができる。ブロードキャストを利用する放送網の場合、放送システムは、シグナリングの属性などによって次世代放送伝送システム及び放送網のフィジカルレイヤ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）を介してシグナリング情報を伝送することができる。ここで、放送システムは、放送信号内に含まれた伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）の特定データパイプ（ｄａｔａ  ｐｉｐｅ；以下、ＤＰ）などを介してシグナリング情報を伝送することができる。ブロードキャストを介して伝送されるシグナリング形態は、ビットストリーム又はＩＰ／ＵＤＰデータグラムにエンカプセレーションされた形態であってもよい。ブロードバンドを利用する場合、放送システムは、受信機の要請に対する応答としてシグナリングデータをリターンして伝達することができる。
【０７６７】
これと加えて、放送システムは、放送サービスのＥＳＧ或いはＮＲＴコンテンツなどを次のような方法で伝送することができる。ブロードキャストを利用する放送網の場合、放送システムは、ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ ｔｒａｎｓｐｏｒｔプロトコルパケット、例えば、Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）、ＭＭＴＰのｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔなどにＥＳＧ或いはＮＲＴコンテンツをエンカプセレーションすることができる。そして、エンカプセレーションされたＥＳＧ或いはＮＲＴコンテンツをさらにＩＰ／ＵＤＰデータグラムとして生成した後、これを放送信号に乗せて伝送することができる。ブロードバンドを利用する場合、放送システムは、受信機の要請に対する応答としてＥＳＧ或いはＮＲＴコンテンツなどをリターンして伝達することができる。
【０７６８】
図４４は、本発明の一実施例に係る次世代放送伝送システムのフィジカルレイヤに伝達される伝送フレームの構造を示す。次世代放送システムは、ブロードキャストを用いて伝送フレームを伝送することができる。同図で、伝送フレームの先頭部に位置しているＰ１は、伝送信号検出（ｔｒａｎｓｐｏｒｔ  ｓｉｇｎａｌ  ｄｅｔｅｃｔｉｏｎ）のための情報が含まれたシンボルを意味することができる。Ｐ１は、チューニング情報（ｔｕｎｉｎｇ  ｉｎｆｏｒｍａｔｉｏｎ）を含むことができ、受信機は、Ｐ１シンボルに含まれたパラメータに基づいてＰ１の次に位置したＬ１パートをデコーティングすることができる。放送システムは、Ｌ１パートに、伝送フレーム構成及び各ＤＰ（ｄａｔａ  ｐｉｐｅ）の特性などに関する情報を含めることができる。すなわち、受信機は、Ｌ１パートをデコーティングして伝送フレーム構成及び各ＤＰ（ｄａｔａ  ｐｉｐｅ）の特性などに関する情報を得ることができる。また、受信機は、Ｃｏｍｍｏｎ ＤＰからＤＰ間の共有すべき情報を取得することができる。実施例によって、伝送フレームはｃｏｍｍｏｎ ＤＰを含まなくてもよい。
【０７６９】
伝送フレームでＡｕｄｉｏ、Ｖｉｄｅｏ、Ｄａｔａなどのコンポーネント（ｃｏｍｐｏｎｅｎｔ）は、ＤＰ１〜ｎで構成されたｉｎｔｅｒｌｅａｖｅｄ ＤＰ領域に含まれて送信される。ここで、それぞれのサービス（チャネル）を構成するコンポーネントがそれぞれどのＤＰで伝送されるかは、Ｌ１或いはｃｏｍｍｏｎ ＰＬＰなどを介してシグナリングすることができる。
【０７７０】
また、次世代放送システムは、伝送フレームに含まれたサービスに関する情報を速かに取得するための情報を伝送することができる。すなわち、次世代放送システムは、次世代放送受信機に、伝送フレームに含まれた放送サービス及びコンテンツ関連情報を速かに取得させることができる。これに加えて、当該フレーム内に一つ以上の放送局で生成したサービス／コンテンツが存在する場合、受信機にとって放送局によるサービス／コンテンツを効率的に認知するようにすることができる。すなわち、次世代放送システムは、伝送フレーム内に含まれたサービスに対するサービスリスト情報を伝送フレームに含めて伝送することができる。
【０７７１】
放送システムは、受信機が当該周波数内の放送サービス及びコンテンツスキャンを速かに行えるようにするために、別途のチャネル、例えば、Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ（ＦＩＣ）などが存在する場合、これを用いて放送サービスに関連した情報を伝送することができる。図４４の中段に示すように、放送システムは、伝送フレームに放送サービススキャン及び取得のための情報を含めて伝送することができる。ここで、放送サービスに対するスキャン及び取得に関する情報を含む領域をＦＩＣと呼ぶことができる。受信機は、ＦＩＣから、一つ以上の放送局で生成及び伝送される放送サービスに関する情報を取得でき、これを用いて、受信機上で利用可能な放送サービスに対するスキャンを容易且つ迅速に行うことができる。
【０７７２】
また、伝送フレームに含まれた特定ＤＰは、当該伝送フレーム内で伝送される放送サービス及びコンテンツに対するシグナリングを迅速で剛健に伝送できるＢａｓｅ ＤＰとして動作することができる。Ｐｈｙｓｉｃａｌ ｌａｙｅｒの伝送フレームの各ＤＰを介して伝送されるデータは、図４４の下段のように示すことができる。すなわち、Ｌｉｎｋ ｌａｙｅｒ ｓｉｇｎａｌｉｎｇ或いはＩＰデータグラムなどは、特定形態のＧｅｎｅｒｉｃ ｐａｃｋｅｔにエンカプセレーションされた後、ＤＰを介して伝送されてもよい。ここで、ＩＰデータグラムはシグナリングデータを含むことができる。ここで、Ｌｉｎｋ（ｌｏｗ） ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇは、ｆａｓｔ ｓｅｒｖｉｃｅ ｓｃａｎ／ａｃｑｕｉｓｉｔｉｏｎ、ＩＰ ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎのｃｏｎｔｅｘｔ ｉｎｆｏｒｍａｔｉｏｎ、ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔと関連したシグナリングなどを含むことができる。
【０７７３】
図４５は、本発明の一実施例に係るアプリケーション層伝送プロトコルの伝送パケットを示す図である。アプリケーション層伝送セッションは、ＩＰアドレス及びポート番号の組合せで構成することができる。アプリケーション層伝送プロトコルがＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）である場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションで構成されてもよい。例えば、一つのＬＣＴ伝送セッションを介して一つのメディアコンポーネント（例えば、ＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎなど）を伝達する場合、一つのアプリケーション伝送セッションを介して一つ以上のメディアコンポーネントをマルチプレクシング(ｍｕｌｔｉｐｌｅｘｉｎｇ)して伝送することができる。さらに、一つのＬＣＴ伝送セッションを介して一つ以上の伝送オブジェクト（Ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔ）を伝達することができ、各伝送オブジェクトは、伝送セッションを介して伝達されるＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎと関連したＤＡＳＨ ｓｅｇｍｅｎｔになり得る。
【０７７４】
例えば、アプリケーション層伝送プロトコルがＬＣＴベースである場合、次のように伝送パケットを構成することができる。伝送パケットは、ＬＣＴヘッダー、ＲＯＵＴＥヘッダー及びペイロードデータを含むことができ、伝送パケットに含まれた複数のフィールドは次のとおりである。
【０７７５】
ＬＣＴヘッダーは、次のようなフィールドを含むことができる。Ｖ（ｖｅｒｓｉｏｎ）フィールドは、当該伝送プロトコルパケットのバージョン情報を示すことができる。Ｃフィールドは、後述するＣｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎフィールドの長さと関連したフラグ（ｆｌａｇ）を示すことができる。ＰＳＩフィールドは、ｐｒｏｔｏｃｏｌ−ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎであって、当該プロトコルに特化された情報を示すことができる。Ｓフィールドは、ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ（ＴＳＩ）フィールドの長さと関連したフラグを示すことができる。Ｏフィールドは、ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）フィールドの長さと関連したフラグを示すことができる。Ｈフィールドは、ＴＳＩ、ＴＯＩフィールドの長さにｈａｌｆ−ｗｏｒｄ（１６ ｂｉｔｓ）が追加されるか否かを表現することができる。Ａ（Ｃｌｏｓｅ  Ｓｅｓｓｉｏｎ  ｆｌａｇ）フィールドは、セッションが終了した又は終了が迫ったことを表現することができる。Ｂ（Ｃｌｏｓｅ  Ｏｂｊｅｃｔ  ｆｌａｇ）フィールドは、伝送中のオブジェクトが終了した又は終了が迫ったことを表現することができる。Ｃｏｄｅ ｐｏｉｎｔフィールドは、当該パケットのペイロードをエンコーディング或いはデコーティングすることに関連した情報を示すことができる。例えば、ペイロードタイプなどがこれに該当し得る。Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎフィールドは、ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌと関連した情報を含むことができる。例えば、ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌと関連した情報は、Ｃｕｒｒｅｎｔ ｔｉｍｅ ｓｌｏｔ ｉｎｄｅｘ（ＣＴＳＩ）、ｃｈａｎｎｅｌ ｎｕｍｂｅｒ、又は当該チャネル内のｐａｃｋｅｔ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒなどを含むことができる。Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒフィールドは、伝送セッションの識別子を示すことができる。Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒフィールドは、伝送セッションを介して伝送されるオブジェクトの識別子を示すことができる。
【０７７６】
ＲＯＵＴＥ（ＡＬＣ）Ｈｅａｄｅｒは、Ｆｏｒｗａｒｄ Ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ ｓｃｈｅｍｅなどに関連したペイロード識別子などを含む、前のＬＣＴヘッダーの追加情報伝送を含むことができる。
【０７７７】
Ｐａｙｌｏａｄ ｄａｔａは、当該パケットのペイロードの実質的なデータ部分を示すことができる。
【０７７８】
図４６は、本発明の一実施例に係る、次世代放送システムがシグナリングデータを伝送する方法を示す。次世代放送システムのシグナリングデータは、図示のように伝送することができる。受信機における迅速なサービス／コンテンツスキャン及び取得を支援するために、次世代放送送信システムは、当該ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅによって伝達される放送サービスに対するシグナリングデータをＦａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ（以下、ＦＩＣ）などを介して伝達することができる。本明細書で、ＦＩＣは、サービスリストに関する情報を意味できる。仮に、別途のＦＩＣが存在しない場合リンクレイヤシンシグナリング（ｌｉｎｋ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）が伝達される経路を介して伝達されてもよい。すなわち、サービス及びサービス内のコンポーネント（オーディオ、ビデオなど）に関する情報などを含むシグナリング情報は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内の一つ以上のＤＰを介してＩＰ／ＵＤＰデータグラムにエンカプセレーションされて伝送されてもよい。実施例によって、サービス及びサービスコンポーネントに対するシグナリング情報は、アプリケーション層伝送パケット（例えば、ＲＯＵＴＥパケット又はＭＭＴＰパケットなど）にエンカプセレーションされて伝送されてもよい。
【０７７９】
図４６の上段は、上述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／取得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどに関する詳細な情報を含むシグナリングデータがＩＰデータグラムにエンカプセレーションされて特定ＤＰを介して伝達されている。本明細書で、サービスなどに関する詳細な情報を含むシグナリングデータを、サービスレイヤシグナリングと呼ぶことができる。
【０７８０】
図４６の中段は、上述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／取得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどに関する詳細な情報を含むシグナリングデータがＩＰデータグラムにエンカプセレーションされて特定ＤＰを介して伝達されている。また、サービスに含まれた特定コンポーネントなどに関する情報などを含むシグナリングデータの一部がアプリケーションレイヤ伝送プロトコル内の一つ以上の伝送セッションを介して伝達されてもよい。例えばシグナリングデータの一部はＲＯＵＴＥセッション内の一つ以上の伝送セッションを介して伝達されてもよい。
【０７８１】
図４６の下段は、上述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／取得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどに関する詳細な情報を含むシグナリングデータはＲＯＵＴＥセッション内の一つ以上の伝送セッションを介して伝達されている。
【０７８２】
図４７は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。本明細書は、次世代放送受信装置が放送サービスをスキャンして取得するためのシグナリング情報を提案する。次世代放送システムでは特定周波数内における一つ以上の放送局で生成した放送サービス及びコンテンツが伝送されてもよい。受信機は、当該周波数内に存在する放送局及び当該放送局のサービス／コンテンツを迅速で容易にスキャンするために、上述したシグナリング情報を利用することができる。これは、図示のようなｓｙｎｔａｘで表すことができ、ＸＭＬなどの他のフォーマットで表されてもよい。
【０７８３】
迅速なサービススキャン及び取得のためのシグナリング情報は、フィジカルレイヤ伝送チャネル（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）内の別途のチャネルであるＦＩＣを介して伝達することができる。また、上述したシグナリング情報は、Ｐｈｙｓｉｃａｌ  ｌａｙｅｒのデータパイプ間の共有可能な情報を伝達し得るＣｏｍｍｏｎ  ＤＰなどで伝達されてもよい。また、リンクレイヤのシグナリングが伝達される経路で伝達されてもよい。また、上述したシグナリング情報は、ＩＰデータグラムにエンカプセレーションされて特定ＤＰを介して伝達されてもよい。また、上述したシグナリング情報は、サービスシグナリングが伝達されるサービスシグナリングチャネル（ｓｅｒｖｉｃｅ  ｓｉｇｎａｌｉｎｇ  ｃｈａｎｎｅｌ）或いはアプリケーションレイヤ（ａｐｐｌｉｃａｔｉｏｎ  ｌａｙｅｒ）の伝送セッション（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）などを介して伝達されてもよい。
【０７８４】
迅速なサービススキャン及び取得のためのシグナリング情報（ＦＩＣ情報）は、次のようなフィールドのうち少なくとも一つを含むことができる。本明細書で、ＦＩＣ情報をサービス取得情報と呼ぶこともできる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ  ｏｆ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ  ｏｆ  ｏｖｅｒａｌｌ  ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ  ｄａｔａ  ｖｅｒｓｉｏｎ  ｏｆ  ｔｈｉｓ  ＦＩＣ  ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｂａｓｅ＿ＤＰ＿ＩＤフィールドは、当該パーティションのベースＤＰに対する識別子を示すことができる。ベースＤＰは、サービスシグナリングテーブルを含むことができる。サービスシグナリングテーブルは、当該パーティション内の全てのサービスに対するリストを含むことができる。すなわち、サービスシグナリングテーブルは、伝送されるサービスをリスティングすることができる。また、各サービスに対する基本属性を定義することができる。ベースＤＰは、当該パーティション内でロバストなＤＰであってもよく、当該パーティションに対する他のシグナリングテーブルを含むこともできる。ｂａｓｅ＿ＤＰ＿ｖｅｒｓｉｏｎフィールドは、当該ベースＤＰを介して伝送されるデータの変化を示すバージョン情報を示すことができる。例えば、ベースＤＰを介してサービスシグナリングなどが伝達される場合、サービスシグナリングの変化が発生すると、ｂａｓｅ＿ＤＰ＿ｖｅｒｓｉｏｎフィールドは１ずつ増加してもよい。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サー��スを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿Ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣ Ｍ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か、又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ  ｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。
【０７８５】
図４８は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッション（ａｐｐｌｉｃａｔｉｏｎ  ｌａｙｅｒ  ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）に関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現することができるが、実施例によってＸＭＬなど他のフォーマットで示してもよい。ＦＩＣ情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ  ｏｆ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ  ｏｆ  ｏｖｅｒａｌｌ  ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ  ｄａｔａ  ｖｅｒｓｉｏｎ  ｏｆ  ｔｈｉｓ  ＦＩＣ  ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅ ｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕ���ｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣ Ｍ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ  ｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）（例えば、ＲＯＵＴＥ又はＭＭＴＰ  ｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ���ィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、当該伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰ  ｓｅｓｓｉｏｎ）を介して伝送されるデータがサービスシグナリングを含んでいることを示すことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒ  ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。
【０７８６】
図４９は、本発明の一実施例に係るＦＩＣベースシグナリングを伝送する方法を示す。上述したＦＩＣベースシグナリングが伝達される実施例は、同図のとおりである。本明細書で、ＦＩＣベースシグナリングは、サービス取得情報又はサービス取得シグナリングと呼ぶことができる。図示のように、フィジカルレイヤシグナリングは、サービス取得情報に対するフィールドを含むことができる。サービス取得情報に対するフィールドは、サービス取得情報（ＦＩＣ）をパーシングするか否かを受信機に知らせることができる。受信機は、サービス取得情報をパーシングし、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報を介してサービスシグナリングのデータが変更されたか否かを確認することができる。サービスシグナリングデータが変更された場合、放送信号受信機は、ＬＳＩＤ＿ＤＰフィールドを用いて伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を確認することができる。放送受信機は、当該ＤＰ識別子が示すＤＰをパーシングして伝送セッションに対する細部情報を確認することができる。すなわち、次世代放送システムのシグナリング方法は、フィジカルレイヤシグナリングが、サービス取得情報をパーシングするか否かをシグナリングし、サービス取得情報が伝送セッションに対する細部情報の位置をシグナリングして、伝送セッションに対する細部情報を確認する順序を含むことができる。ここで、伝送セッションに対する細部情報は、ＭＰＤ伝送テーブル、アプリケーションシグナリングテーブル、伝送セッションディスクリプタ（ＬＳＩＤ）及び／又はコンポーネントマッピングテーブル（ＣＭＴ）を含むことができる。
【０７８７】
図５０は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。ＦＩＣ情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ  ｏｆ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ  ｏｆ  ｏｖｅｒａｌｌ  ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ  ｄａｔａ  ｖｅｒｓｉｏｎ  ｏｆ  ｔｈｉｓ  ＦＩＣ  ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅ  ｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣ Ｍ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ  ｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰ  ｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎ��ｌｉｎｇ＿ｆｌａｇ値が１である場合、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、関連したサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する度に当該フィールドは、１ずつ増加してもよい。受信機は、ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて当該サービスと関連したシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドは、サービスシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒ  ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。
【０７８８】
図５１は、本発明の他の実施例に係る、ＦＩＣベースシグナリングを伝送する方法を示す。上述したＦＩＣベースシグナリングが伝達される実施例は、同図のとおりである。本明細書で、ＦＩＣベースシグナリングは、サービス取得情報又はサービス取得シグナリングと呼ぶことができる。図示のように、フィジカルレイヤシグナリングは、サービス取得情報に対するフィールドを含むことができる。サービス取得情報に対するフィールドは、サービス取得情報（ＦＩＣ）をパーシングするか否かを受信機に知らせることができる。受信機は、サービス取得情報をパーシングし、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報を介してサービスシグナリングのデータが変更されたか否かを確認することができる。サービスシグナリングデータが変更された場合、放送信号受信機は、ＬＳＩＤ＿ＤＰフィールドを用いて、伝送セッションに関する詳細な情報を含んでいるＬＳＩＤ或いはＬＳＩＤ  Ｔａｂｌｅなどを、ＬＳＩＤ＿ＤＰフィールドから識別したＤＰを介して取得することができる。これに加えて、受信機は、ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ、ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｉｇｎａｌｉｎｇ＿ＤＰなどの情報を用いてシグナリングデータの変化などを認知し、ｓｉｇｎａｌｉｎｇ＿ＤＰから識別したＤＰを介してシグナリングデータを取得することができる。
【０７８９】
すなわち、次世代放送システムのシグナリング方法は、フィジカルレイヤシグナリングがサービス取得情報をパーシングするか否かをシグナリングし、サービス取得情報が伝送セッションに対する細部情報の位置をシグナリングして、伝送セッションに対する細部情報を確認する順序を含むことができる。ここで、伝送セッションに対する細部情報は、ＭＰＤ伝送テーブル、アプリケーションシグナリングテーブル、伝送セッションディスクリプタ（ＬＳＩＤ）及び／又はコンポーネントマッピングテーブル（ＣＭＴ）を含むことができ、伝送セッションに対する各細部情報は、互いに異なる例によって伝達されてもよい。
【０７９０】
図５２は、本発明の一実施例に係る、次世代放送システムのサービスシグナリングメッセージフォーマットを示す図である。本明細書でサービスシグナリングメッセージは、サービスなどに関する詳細な情報を含むシグナリングデータ又はサービスレイヤシグナリングと称することができる。サービスシグナリングメッセージは、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅを含む構造であってもよい。シグナリングメッセージは、ｂｉｎａｒｙ或いはＸＭＬフォーマットなどで表現されてもよい。これは、ＩＰデータグラム或いはアプリケーションレイヤ伝送パケット（例えば、ＲＯＵＴＥ或いはＭＭＴＰなど）のペイロードに含まれて伝送されてもよい。Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒのｓｙｎｔａｘは次のとおりであり、これは、ＸＭＬなどの他のフォーマットで表されてもよい。Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、次のフィールドを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは、シグナリングメッセージの識別子を示すことができる。例えば、シグナリングメッセージがｓｅｃｔｉｏｎ形態で表される場合、ｓｉｇｎａｌｉｎｇ  ｔａｂｌｅ  ｓｅｃｔｉｏｎのｉｄを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈフィールドは、含まれているシグナリングメッセージの長さを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、シグナリングメッセージに対する識別子の拡張情報を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドと共にシグナリングを識別する情報として用いることができる。例えば、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、シグナリングメッセージのプロトコルバージョンなどを含むことができる。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、シグナリングメッセージのバージョン情報を示すことができる。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、当該シグナリングメッセージが含む内容が変更する場合に変更されてもよい。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、含まれているシグナリングメッセージが現在可用か否かを示すことができる。このフィールドの値が「１」である場合、含まれている現在シグナリングメッセージが現在可用であることを示すことができる。このフィールドの値が「０」である場合、現在シグナリングメッセージが可用でなく、後に、同一のｓｉｇｎａｌｉｎｇ＿ｉｄ、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ、或いはｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒを含むシグナリングメッセージが可用であることを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒフィールドは、当該シグナリングメッセージがｆｒａｇｍｅｎｔａｔｉｏｎされたか否かを示すことができる。このフィールドの値が「１」である場合、当該メッセージがｆｒａｇｍｅｎｔａｔｉｏｎされたことを示し、このような場合、ｓｉｇｎａｌｉｎｇ＿ｍｅｓｓａｇｅ＿ｄａｔａ（）にシグナリングデータの一部が含まれていることを示すことができる。このフィールドの値が「０」の場合、ｓｉｇｎａｌｉｎｇ＿ｍｅｓｓａｇｅ＿ｄａｔａ（）に全体シグナリングデータが含まれていることを示すことができる。ｐａｙｌｏａｄ＿ｆｏｒｍａｔ＿ｉｎｄｉｃａｔｏｒフィールドは、現在シグナリングメッセージヘッダー部分にｐａｙｌｏａｄ＿ｆｏｒｍａｔ値を含んでいるか否かを示すことができる。このフィールドの値が「１」である場合、シグナリングメッセージヘッダー部分にｐａｙｌｏａｄ＿ｆｏｒｍａｔ値が含まれていることを示すことができる。ｅｘｐｉｒａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒフィールドは、現在シグナリングメッセージヘッダー部分にｅｘｐｉｒａｔｉｏｎ値を含んでいるか否かを示すことができる。このフィールドの値が「１」である場合、シグナリングメッセージヘッダー部分にｅｘｐｉｒａｔｉｏｎ値が含まれていることを示すことができる。ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは、一つのシグナリングメッセージが複数のｆｒａｇｍｅｎｔに分けられて伝送される場合、現在シグナリングメッセージのｆｒａｇｍｅｎｔナンバーを示すことができる。ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは、一つのシグナリングメッセージが複数のｆｒａｇｍｅｎｔに分けられて伝送される場合、当該シグナリングメッセージの最後のデータを含むｆｒａｇｍｅｎｔのナンバーを示すことができる。ｐａｙｌｏａｄ＿ｆｏｒｍａｔフィールドは、ペイロードに含まれるシグナリングメッセージデータのフォーマットを示すことができる。実施例として、ｂｉｎａｒｙ、ＸＭＬなどを示すことができる。ｅｘｐｉｒａｔｉｏｎフィールドは、ペイロードに含まれているシグナリングメッセージの有効時間を示すことができる。
【０７９１】
図５３は、本発明の一実施例に係る、次世代放送システムで用いるサービスシグナリングテーブルを示す。本発明で、次世代放送網で使用可能なサービスシグナリングテーブル／メッセージなどは次のとおりであり、下記のような情報などを含めてシグナリングすることができる。各テーブル／メッセージに含まれた情報は、異なるテーブルに分けられて個別的に伝送されてもよく、図示の実施例によって限定されない。また、実施例によって、異なるテーブルに属したシグナリング情報は一つのテーブルに併合されて伝送されてもよい。Ｓｅｒｖｉｃｅ  ｍａｐｐｉｎｇ  ｔａｂｌｅは、サービスの属性及びサービスと関連した情報を含むことができる。サービスの属性情報は、例えば、ＩＤ、名前、カテゴリーなどの情報を含むことができ、サービスと関連した情報は、サービスを取得し得る経路情報などを含むことができる。ＭＰＤ  Ｄｅｌｉｖｅｒｙ  ｔａｂｌｅは、サービス／コンテンツと関連したＤＡＳＨ  ＭＰＤを含んだり、ＤＡＳＨ  ＭＰＤを取得し得る経路情報などを含むことができる。Ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅは、サービス内コンポーネント情報及びコンポーネントと関連した情報を含むことができる。コンポーネント情報は、関連したＤＡＳＨ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ情報などを含むことができ、コンポーネントと関連した情報は、コンポーネントを取得し得る経路情報などを含むことができる。ＬＳＩＤ  ｔａｂｌｅは、サービス／コンポーネントなどを伝達する伝送セッション及び伝送パケットの構成などに関する情報を含むことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ  Ｄｅｌｉｖｅｒｙ  ｔａｂｌｅは、サービス内コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ対するＩｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ情報或いはこれを取得し得る経路などに関する情報を含むことができる。Ａｐｐｌｉｃａｔｉｏｎ  ｐａｒａｍｅｔｅｒ  ｔａｂｌｅは、放送サービスと関連したアプリケーションに対する細部情報及びこれを取得し得る経路などを含む、関連した情報を含むことができる。このようなシグナリングメッセージ／テーブルなどが放送網を介して伝送される場合、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）或いはＳＳＣ（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ）、或いはアプリケーションレイヤ伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰ  ｓｅｓｓｉｏｎ）などを介して伝送されてもよい。さらに、インターネット網（ブロードバンド）を介して伝送されてもよい。
【０７９２】
図５４は、本発明の一実施例に係る次世代放送システムで用いられるサービスマッピングテーブルを示す図である。後述する内容は、シグナリングメッセージヘッダーの後に位置したサービスシグナリングメッセージ部分に含めて伝送することができる。
【０７９３】
サービスマッピングテーブルは、サービスマッピングシグナリングに関する情報を含むことができ、ＸＭＬ形態又はｂｉｎａｒｙ形態などで表現され得る。サービスシグナリングの一つであるサービスマッピングテーブルは、サービス識別子（ｉｄ）、サービスタイプ、サービスネーム、チャネルナンバー、ＲＯＵＴＥセッション関連情報、ＭＰＤ関連情報、コンポーネントシグナリング位置情報を含むことができる。サービス識別子は、サービスを識別する情報を示すことができ、ｉｄ属性で表現され得る。サービスタイプ情報は、サービスのタイプを示す情報であって、ｓｅｒｖｉｃｅＴｙｐｅ属性で表現されてもよい。サービスネーム情報は、サービスの名前を示す情報であって、ｓｅｒｖｉｃｅＮａｍｅ属性で表現されてもよい。チャネルナンバー情報は、サービスと関連したチャネルナンバーを示す情報であって、ｃｈａｎｎｅｌＮｕｍｂｅｒ属性で表現されてもよい。
【０７９４】
ＲＯＵＴＥセッション関連情報は、ｓｏｕｒｃｅＩＰ属性、ｄｅｓｔｉｎａｔｉｏｎＩＰ属性、ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性を含むことができる。ｓｏｕｒｃｅＩＰ属性は、関連したデータを含むＩＰデータグラムのソースアドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＩＰ属性は、関連したデータを含むＩＰデータグラムの目的地アドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は、関連したデータを含むＩＰデータグラムの目的地ポートナンバーを示すことができる。
【０７９５】
また、ＲＯＵＴＥセッション関連情報は、伝送セッションに対する細部情報（ＬＳＩＤ）を含むことができ、例えば、各ＬＳＩＤ位置情報及び各ＬＳＩＤ位置情報のデリバリーモード情報を含むことができる。また、伝送セッションに対する細部情報（ＬＳＩＤ）は、ブートストラップ情報を含むことができる。ＬＳＩＤに含まれたブートストラップ情報は、デリバリーモードによるＬＳＩＤのブートストラップ情報を含むことができる。ブートストラップ情報に含まれた属性の詳細は後述する。
【０７９６】
ＭＰＤ関連情報は、ＭＰＤ又はＭＰＤシグナリングロケーションに関する情報を含むことができる。ＭＰＤに対する情報は、バージョン属性を含むことができ、ＭＰＤのバージョンを示すことができる。ＭＰＤシグナリングロケーション情報は、ＭＰＤ又はＭＰＤ ＵＲＬと関連したシグナリングを取得し得る位置を示すことができる。ＭＰＤシグナリングロケーションに含まれたデリバリーモード情報は、ＭＰＤロケーションシグナリングのデリバリーモードを示すことができる。ＭＰＤシグナリングロケーションに含まれたブートストラップインフォ情報は、デリバリーモードによるＭＰＤ又はＭＰＤ ＵＲＬのブートストラップ情報を含むことができる。
【０７９７】
コンポーネントシグナリングロケーション関連情報は、デリバリーモード属性を含むことができる。デリバリーモード属性は、当該コンポーネントシグナリングロケーション情報のデリバリーモードを示すことができる。ＭＰＤシグナリングロケーションに含まれたブートストラップインフォ情報は、デリバリーモードによる当該コンポーネントロケーションシグナリングのブートストラップ情報を含むことができる。
【０７９８】
ブートストラップ情報は、デリバリーモードによって次のような属性のうち少なくとも一つを含むことができる。
【０７９９】
ｓｏｕｒｃｅＩＰ属性は、関連したデータを含むＩＰデータグラムのソースアドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＩＰ属性は、関連したデータを含むＩＰデータグラムの目的地アドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は、関連したデータを含むＩＰデータグラムの目的地ポートナンバーを示すことができる。ｔｓｉ属性は、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔ  ｐａｃｋｅｔｓ）を伝達する伝送セッションに対する識別子を示すことができる。ＵＲＬ属性は、関連したデータを取得し得るＵＲＬを示すことができる。ｐａｃｋｅｔｉｄは、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔ  ｐａｃｋｅｔｓ）の識別子を示すことができる。
【０８００】
図５５は、本発明の一実施例に係る、次世代放送システムのサービスシグナリングテーブルを示す。次世代放送システムで受信機が放送サービス及びコンテンツを受信できるようするために放送サービスシグナリングを提供することができる。これは、シグナリングデータが同じ伝送セッション識別子（ＴＳＩ）を介して伝送される場合、受信機が関連シグナリングを取得できるようにする。サービスシグナリングテーブルは、図示のようにバイナリフォーマットで表現されてもよく、実施例によってＸＭＬなど他の形態で表現されてもよい。また、サービスシグナリングテーブルは、前述したシグナリングメッセージフォーマットでエンカプセレーションされてもよい。サービスシグナリングテーブルは、次のようなフィールドを含むことができる。ＳＳＴ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、サービスシグナリングテーブルのバージョンを示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ＳＳＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該サービスシグナリングテーブルのデータバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティション内に含まれた少なくとも一つ以上のサービスの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該サービスの識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスの名前を示すことができる。ＭＰＤ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、ブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＭＰＤを取得できるか否かを示すことができる。ＣＭＴ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、ブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ（ＣＭＴ）を利用できるか否かを示すことができる。ＡＳＬ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、ブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＡｐｐｌｉｃａｔｉｏｎ  Ｓｉｇｎａｌｉｎｇ  Ｔａｂｌｅ（ＡＳＴ）を利用できるか否かを示すことができる。ＤＰ＿ＩＤフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬをブロードキャストを介して伝達するＤＰの識別子を示すことができる。ＬＣＴ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルのＩＰアドレスを示すことができる。ＬＣＴ＿ＵＤＰ＿ｐｏｒｔフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルのＵＤＰポートを示すことができる。ＬＣＴ＿ＴＳＩフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルの伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ，ＴＳＩ）を示すことができる。ＭＰＤ＿ＴＯＩフィールドは、ＭＰＤがブロードキャストを介して伝達される場合、ＭＰＤの伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ）を示すことができる。ＣＭＴ  ＴＯＩフィールドは、ＣＭＴがブロードキャストを介して伝達される場合、ＣＭＴの伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ）を示すことができる。ＡＳＴ＿ＴＯＩフィールドは、ＡＳＴがブロードキャストを介して伝達される場合、ＡＳＴの伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ）を示すことができる。ＭＰＤ＿ＵＲＬフィールドは、ブロードバンドを介してＭＰＤを取得し得るＵＲＬ情報を示すことができる。ＣＭＴ＿ＵＲＬフィールドは、ブロードバンドを介してＣＭＴを取得し得るＵＲＬ情報を示すことができる。ＡＳＴ＿ＵＲＬフィールドは、ブロードバンドを介してＡＳＴを取得し得るＵＲＬ情報を示すことができる。
【０８０１】
図５６は、本発明の一実施例に係る、次世代放送システムで用いられるコンポーネントマッピングテーブルを示す図である。後述する内容は、シグナリングメッセージヘッダーの後に位置したサービスシグナリングメッセージ部分に含まれて伝送されてもよい。コンポーネントマッピングテーブルは、コンポーネントマッピングシグナリングに関する情報を含むことができ、ＸＭＬ形態又はｂｉｎａｒｙ形態などで表現されてもよい。サービスシグナリングの一つであるコンポーネントマッピングテーブルは、次のようなフィールドを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは、当該テーブルがｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅであることを示す識別子を含むことができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅ  ｓｙｎｔａｘなどのｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎフィールドは、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該コンポーネントと関連したサービスに対する識別子を示すことができる。Ｎｕｍ＿ｃｏｍｐｏｎｅｎｔフィールドは、当該サービスが含むコンポーネントの個数を示すことができる。Ｍｐｄ＿ｉｄフィールドは、コンポーネントと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。Ｐｅｒｉｏｄ＿ｉｄフィールドは、コンポーネントと関連したＤＡＳＨ  ｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ｉｄフィールドは、コンポーネントと関連したＤＡＳＨ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。Ｓｏｕｒｃｅ＿ＩＰフィールドは、当該コンポーネントデータを含むＩＰ／ＵＤＰデータグラムｓｏｕｒｃｅ  ＩＰアドレスを示すことができる。Ｄｅｓｔ＿ＩＰフィールドは、当該コンポーネントデータを含むＩＰ／ＵＤＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＩＰアドレスを示すことができる。ｐｏｒｔフィールドは、当該コンポーネントデータを含むＩＰ／ＵＤＰデータグラムＰｏｒｔナンバーを示すことができる。ｔｓｉフィールドは、当該コンポーネントデータを含むアプリケーションレイヤ伝送セッションの識別子を示すことができる。ＤＰ＿ｉｄフィールドは、当該コンポーネントデータを伝達するフィジカルレイヤデータパイプ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｄａｔａ  ｐｉｐｅ）の識別子を示すことができる。これらの情報を用いてＣＭＴは各サービスに関連したコンポーネントを定義し、当該コンポーネントを受信し得る位置又は経路を受信機に知らせることができる。
【０８０２】
図５７は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢｒｏａｄｃａｓｔＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  ＳｅｇｍｅｎｔのＢａｓｅ  ＵＲＬを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。
【０８０３】
ＢＢＣｏｍｐは、ｂｒｏａｄｂａｎｄ網を介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢＢＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  ＳｅｇｍｅｎｔのＢａｓｅ  ＵＲＬを示すことができる。
【０８０４】
ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＦｏｒｅｉｇｎＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  ＳｅｇｍｅｎｔのＢａｓｅ  ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅ  ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるｄａｔａ  ｐｉｐｅの識別子を示すことができる。上記のＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。図５７の下段に示すように、Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、前述した形態に従うことができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ或いはその一部を含むことができる。上記のような情報を用いてＣＭＴは各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。
【０８０５】
図５８は、本発明の一実施例に係る、次世代放送システムのコンポーネントマッピングテーブルのシンタックスを示す。次世代放送システムは、受信機が放送サービスのコンポーネントを取得できるようにコンポーネントマッピングテーブル（ＣＭＴ）をシグナリングすることができる。これは、ｂｉｎａｒｙ又はＸＭＬなど他の形態で表現されてもよく、また、前述したシグナリングメッセージフォーマットでエンカプセレーションされてもよい。コンポーネントマッピングテーブルは、次のようなフィールドを含むことができる。ＣＭＴ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｅ（ＣＭＴ）の構造（ｓｔｒｕｃｔｕｒｅ）のバージョンを示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該ＣＭＴが提供するコンポーネント位置と関連したサービスの識別子を示すことができる。ＣＭＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＣＭＴのデータバージョンを示すことができる。ｎｕｍ＿ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍｓフィールドは、当該サービスと関連した少なくとも一つのコンポーネントを含むブロードキャストストリームの個数を示すことができる。ＴＳＩＤフィールドは、当該ブロードキャストストリームの伝送セッション識別子を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、当該サービスと関連した少なくとも一つのコンポーネントを含むブロードキャストストリームのパーティション個数を示すことができる。ＣＭＴは、複数のパーティションを含むことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｎｕｍ＿ｄａｔａ＿ｐｉｐｅｓフィールドは、当該サービスと関連した少なくとも一つのコンポーネントを含むパーティション内のデータパイプの個数を示すことができる。ＤＰ＿ＩＤフィールドは、各データパイプの識別子を示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓフィールドは、各データパイプに含まれた伝送セッション（例えば、ＲＯＵＴＥセッション）の個数を示すことができる。各データパイプは、当該サービスと関連した少なくとも一つのコンポーネントを含むことができる。ＩＰ＿ａｄｄｒｅｓｓフィールドは、各伝送セッションのＩＰアドレスを示すことができる。ＵＤＰ＿ｐｏｒｔフィールドは、各伝送セッションのＵＤＰ  ｐｏｒｔを示すことができる。ｎｕｍ＿ＬＣＴ＿ｃｈａｎｎｅｌｓフィールドは、当該サービスと関連したコンポーネントを含む伝送セッション内のＬＣＴチャネルの個数を示すことができる。ＬＣＴ＿ＴＳＩフィールドは、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ，ＴＳＩ）を示すことができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤフィールドは、当該ＬＣＴチャネルによって運搬されるＲｅｐｒｅｓｅｎｔａｔｉｏｎの識別子を示すことができる。Ｉｎｔｅｒｎｅｔ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、当該Ｒｅｐｒｅｓｅｎｔａｔｉｏｎがインターネット又はブロードバンドを介しても受信され得るか否かを示す識別子であってもよい。ｎｕｍ＿ｉｎｔｅｒｎｅｔ＿ｏｎｌｙ＿ｒｅｐｔｎｓフィールドは、インターネット又はブロー��バンドのみを介して受信し得るＲｅｐｒｅｓｅｎｔａｔｉｏｎの個数を示すことができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤフィールドは、ｎｕｍ＿ｉｎｔｅｒｎｅｔ＿ｏｎｌｙ＿ｒｅｐｔｎｓのｌｏｏｐ内で、インターネット又はブロードバンドのみを介して受信し得るＲｅｐｒｅｓｅｎｔａｔｉｏｎの識別子を示すことができる。上記のような情報を用いてＣＭＴは、各サービスに関連したコンポーネントを定義し、当該コンポーネントを受信し得る位置又は経路を受信機に知らせることができる。
【０８０６】
図５９は、本発明の一実施例に係る、次世代放送システムで各サービスと関連したシグナリングをブロードバンド網を介して伝達する方法を示す。次世代放送システムは、サービスと関連したシグナリングをブロードバンド網などを介して受信機に伝達することができる。次世代放送システムは、ＵＲＬ  Ｓｉｇｎａｌｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎを用いてブロードバンド網などを介してシグナリングを受信機に伝達することができる。これは、ＸＭＬ又はｂｉｎａｒｙなど他の形態で表されてもよい。ＵＲＬ  Ｓｉｇｎａｌｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎは、次のような属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、シグナリングと関連したサービスの識別子を示すことができる。ｍｐｄＵＲＬ属性は、ブロードバンドＭＰＤのＵＲＬを示すことができる。ｃｓｔＵＲＬ属性は、ブロードバンドＣＭＴのＵＲＬを示すことができる。ＣＭＴは、放送サービス内コンポーネントデータ取得経路に関する情報を含むことができる。ａｓｔＵＲＬ属性は、ブロードバンドＡＳＴのＵＲＬを示すことができる。ＡＳＴは、放送サービスと関連したアプリケーションに関する情報を含むことができる。受信機は、ディスクリプションを受信し、各シグナリングに対するＵＲＬに基づいて当該シグナリングを受信することができる。上記のＵＲＬ  Ｓｉｇｎａｌｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。同図の下段に示すように、Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、上記で提案した形態にしたがうことができ、ヘッダーの後にＵＲＬ  Ｓｉｇｎａｌｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。
【０８０７】
図６０は、本発明の一実施例に係る、次世代放送システムでＭＰＤをシグナリングする方案を示す。次世代放送網で使用可能な放送サービスのＭＰＤに対するシグナリングメッセージは、同図の上段に示すように、Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ及び Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅで構成されてもよい。Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、前述した形態にしたがうことができ、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅ情報は、次のような情報を含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ情報は、当該シグナリングメッセージがＭＰＤ或いはＭＰＤを取得し得る経路情報を含むシグナリングメッセージであることを識別できる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、当該シグナリングメッセージのｓｙｎｔａｘなどのＭＰＤ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎ情報は、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄ情報は、当該シグナリング情報と関連したサービス識別子を示すことができる。Ｍｐｄ＿ｉｄ情報は、シグナリングメッセージと関連したＤＡＳＨ  ＭＰＤの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎ情報は、当該ＭＰＤの変化などを示すバージョン情報を示すことができる。Ｄｅｌｉｖｅｒｙ＿ｍｏｄｅ情報は、シグナリングメッセージが当該ＭＰＤを含んでいるか他の経路を通じて伝達されるかに関する情報を示すことができる。ＭＰＤ＿ｄａｔａ（）情報は、当該シグナリングメッセージがＭＰＤを含む場合、ＭＰＤデータ自体を含むことができる。ＭＰＤ＿ｐａｔｈ情報は、ＭＰＤを取得し得る経路に関する情報を含むことができる。例えば、経路としてＵＲＬなどを示すことができる。
【０８０８】
ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅ  ｄｅｓｃｒｉｐｔｉｏｎは、次のような情報を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、シグナリングと関連したサービスの識別子を示すことができる。ＭＰＤ＿ｉｄ属性は、ＭＰＤの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎは、ＭＰＤの変化情報を示し得るバージョン情報を示すことができる。ＭＰＤ＿ＵＲＬ属性は、ＭＰＤを取得し得るＵＲＬ情報を含むことができる。また、ＭＰＤエレメントは、ＭＰＤ情報を含むことができる。ＭＰＤ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。すなわち、Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、上記で提案した形態にしたがうことができ、その次にＭＰＤ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。
【０８０９】
図６１は、本発明の一実施例に係る、次世代放送システムのＭＰＤデリバリーテーブルのシンタックスを示す。シグナリングメッセージヘッダーの後にはＭＰＤデリバリーテーブルの情報又はその一部が含まれてもよく、ＭＰＤデリバリーテーブルの情報は次のようなフィールドを含むことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、関連した放送サービスの識別子を示すことができる。ＭＰＤ＿ｉｄ＿ｌｅｎｇｔｈフィールドは、後続するＭＰＤ＿ｉｄ＿ｂｙｔｅｓ（）長さを示すことができる。ＭＰＤ＿ｉｄ＿ｂｙｔｅｓフィールドは、シグナリングメッセージに含まれるＭＰＤファイルの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎフィールドは、当該ＭＰＤのデータの変化などのバージョン情報を示すことができる。ＭＰＤ＿ＵＲＬ＿ａｖａｉｌａｂｉｌｔｙフィールドは、当該シグナリングテーブル／メッセージ内にＭＰＤのＵＲＬ情報が存在するか否かを示すことができる。ＭＰＤ＿ｄａｔａ＿ａｖａｉｌａｂｉｌｔｙフィールドは、当該シグナリングテーブル／メッセージ内にＭＰＤ自体を含むか否かを示すことができる。当該値が「１」であれば、ＭＰＤ自体が当該シグナリングテーブル／メッセージに含まれることを示すことができる。ＭＰＤ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドは、後続するＭＰＤ＿ＵＲＬ＿ｂｙｔｅｓ（）長さを示すことができる。ＭＰＤ＿ＵＲＬ＿ｂｙｔｅｓフィールドは、シグナリングメッセージに含まれるＭＰＤ ＵＲＬを示すことができる。ＭＰＤ＿ｃｏｄｉｎｇフィールドは、当該シグナリングメッセージ内に含むＭＰＤファイルのエンコーディング方式を示すことができる。同図の下段に示すように、値によって、ＭＰＤファイルが異なる形態のエンコーディング方式でエンコーディングされたことを示すことができる。例えば、ＭＰＤ＿ｃｏｄｉｎｇフィールドの値が「０ｘ００」である場合、ＸＭＬで表現されるＭＰＤファイル自体を含んでいることを示すことができる。また、その値が「０ｘ０１」である場合、ｇｚｉｐで圧縮されたＭＰＤファイルが含まれていることを示すことができる。例えば、ｇｚｉｐで圧縮されているＭＰＤが複数のメッセージ／テーブルに分けられて伝送される場合、当該複数のＭＰＤ＿ｂｙｔｅｓ（）を連鎖（ｃｏｎｃａｔｅｎａｔｅ）した後、ｕｎｇｚｉｐすることができる。ＭＰＤ＿ｂｙｔｅ＿ｌｅｎｇｔｈフィールドは、後続するＭＰＤ＿ｂｙｔｅｓ（）長さを示すことができる。ＭＰＤ＿ｂｙｔｅｓフィールドは、ＭＰＤ＿ｃｏｄｉｎｇで明示されたエンコーディング方式によってシグナリングメッセージに含まれるＭＰＤファイルの実際データを含むことができる。次世代放送システムは、上述したフィールドを含むＭＰＤデリバリーテーブルを介して、受信機がサービスと関連したＭＰＤを受信又は取得することができるようにする。
【０８１０】
図６２は、本発明の一実施例に係る、次世代放送システムの伝送セッションインスタンスディスクリプションを示す。アプリケーションレイヤ伝送方法がＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）である場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションで構成されてもよい。一つ以上の伝送セッション（Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）に対する細部情報は、伝送セッションインスタンスディスクリプションを用いてシグナリングすることができる。伝送セッションインスタンスディスクリプタは、ＲＯＵＴＥの場合、ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）と呼ぶことができる。特に、伝送セッションインスタンスディスクリプションは、ＲＯＵＴＥセッションを構成する各ＬＣＴ伝送セッションによって何が伝達されるかを定義することができる。各伝送セッションは、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ，ＴＳＩ）によってユニークに識別されてもよい。伝送セッション識別子はＬＣＴヘッダーに含まれてもよい。伝送セッションインスタンスディスクリプションは、当該セッションを介して伝送される全ての伝送セッションを記述することができる。例えば、ＬＳＩＤは、ＲＯＵＴＥセッションによって運搬されるモードＬＣＴセッションを記述することができる。伝送セッションインスタンスディスクリプションは、伝送セッションと同じＲＯＵＴＥセッションで伝達されたり、又は異なるＲＯＵＴＥセッションやユニキャストを介して伝達されてもよい。
【０８１１】
同じＲＯＵＴＥセッションで伝達される場合、伝送セッションインスタンスディスクリプションは、指定された伝送セッション識別子（ＴＳＩ）０を有する伝送セッションで伝達されてもよい。伝送セッションインスタンスディスクリプションにおいて参照される他のオブジェクトも、ＴＳＩ＝０で伝達されてもよいが、伝送セッションインスタンスディスクリプションとは異なるＴＯＩ値を有することができる。又は、ＴＳＩ≠０の分離された伝送セッションを介して伝達されてもよい。伝送セッションインスタンスディスクリプションは、バージョンナンバー、有効（ｖａｌｉｄｉｔｙ）情報又は満了（ｅｘｐｉｒａｔｉｏｎ）情報のうち少なくとも一つを用いてアップデートされてもよい。伝送セッションインスタンスディスクリプションは、図示された形態の他、ｂｉｔｓｔｒｅａｍなどと表されてもよい。
【０８１２】
伝送セッションインスタンスディスクリプションは、ｖｅｒｓｉｏｎ属性、ｖａｌｉｄＦｒｏｍ属性、ｅｘｐｉｒａｔｉｏｎ属性を含むことができ、各伝送セッションに対してＴＳＩ属性及びＳｏｕｒｃｅＦｌｏｗ、ＲｅｐａｉｒＦｌｏｗ情報を含むことができる。ｖｅｒｓｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションのバージョン情報を示すことができ、その内容がアップデートされる度にバージョン情報は増加してもよい。最高のバージョンナンバーを有する伝送セッションインスタンスディスクリプションが最近の有効なバージョンであることを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、当該伝送セッションインスタンスディスクリプションがいつから有効であるかを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、実施例によって伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは、受信すると直ちに有効であることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションがいつ満了するかを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、実施例によって、伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは、継続して有効なものであることを示すことができる。仮に、ｅｘｐｉｒａｔｉｏｎ属性を有する伝送セッションインスタンスディスクリプションが受信されると、当該ｅｘｐｉｒａｔｉｏｎ属性に従うことができる。ＴＳＩ属性は、伝送セッション識別子を示すことができ、ＳｏｕｒｃｅＦｌｏｗエレメントは、当該ＴＳＩで伝送されるソースフローの情報を提供し、詳細内容は後述する。ＲｅｐａｉｒＦｌｏｗエレメントは、当該ＴＳＩで伝送されるリペアフローの情報を提供することができる。
【０８１３】
図６３は、本発明の一実施例に係る次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す。ソースフローエレメントは、ＥＦＤＴエレメント、ｉｄＲｅｆ属性、ｒｅａｌｔｉｍｅ属性、ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性、Ａｐｐｌｉｃａｔｉｏｎ  Ｉｄｅｎｄｔｉｆｉｅｒエレメント、ＰａｙｌｏａｄＦｏｒｍａｔエレメントを含むことができる。ＥＦＤＴエレメントは、ファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴは、ｅｘｔｅｎｄｅｄ  Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ（ＦＤＴ）  ｉｎｓｔａｎｃｅを示すことができ、詳細な内容は後述する。ｉｄＲｅｆ属性は、ＥＦＤＴの識別子を示すことができ、対応する伝送セッションによってＵＲＩと表現されてもよい。ｒｅａｌｔｉｍｅ属性は、当該ＬＣＴパケットが拡張ヘッダー（ｅｘｔｅｎｓｉｏｎ  ｈｅａｄｅｒ）を含むことを示すことができる。拡張ヘッダーは、デリバリーオブジェクトのプレゼンテーションタイムを示すタイムスタンプを含むことができる。ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性は、受信機に保存されるために必要なデータの最大量を定義することができる。Ａｐｐｌｉｃａｔｉｏｎ  Ｉｄｅｎｄｔｉｆｉｅｒエレメントは、当該伝送セッションによって運搬されるアプリケーションにマッピングされ得る付加情報を提供することができる。例えば、レンダリングのための伝送セッションを選択するためのＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎ  ＩＤ又はＤＡＳＨ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎのＡｄａｐｔａｔｉｏｎ  Ｓｅｔパラメータが付加情報として提供されてもよい。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ソースフローのオブジェクトを運搬するＲＯＵＴＥパケットのペイロードフォーマットを定義することができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ｃｏｄｅＰｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。ｃｏｄｅＰｏｉｎｔ属性は、当該ペイロードで用いられるコードポイントを定義することができる。これは、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は、当該デリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性は、フラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性は、オブジェクトのデリバリー順序を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性は、ｓｏｕｒｃｅ  ＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントは、ＦＥＣパラメータを定義することができる。これは、ＦＥＣ  ｅｎｃｏｄｉｎｇ  ｉｄ、ｉｎｓｔａｎｃｅ  ｉｄなどを含むことができる。
【０８１４】
図６４は、本発明の一実施例に係る次世代放送システムのＥＦＤＴを示す。ＥＦＤＴは、ファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴは、ｉｄＲｅｆ属性、バージョン属性、ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ属性、ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ属性、ＦｉｌｅＴｅｍｐｌａｔｅエレメントを含むことができる。ｉｄＲｅｆ属性は、ＥＦＤＴの識別子を示すことができる。バージョン属性は、ＥＦＤＴインスタンスディスクリプタのバージョンを示すことができる。この属性は、ＥＦＤＴがアップデートされる度に１ずつ増加してもよい。受信されたＥＦＤＴのうち最高のバージョンナンバーを有するＥＦＤＴが現在有効なバージョンであることを示すことができる。ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ属性は、オブジェクトと関連した最初パケットを送信した後、当該オブジェクトの最大有効時間（ｅｘｐｉｒｙ  ｔｉｍｅ）を示すことができる。ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ属性は、当該ＥＦＤＴによって記述されるオブジェクトの最大伝送サイズを示すことができる。ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ボディー部分のｆｉｌｅ  ＵＲＬ又はｆｉｌｅテンプレートを詳細化することができる。
【０８１５】
前述した伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）エレメントは、同図下段の伝送セッションインスタンスディスクリプタテーブル（ＬＳＩＤ  Ｔａｂｌｅ）によって伝送されてもよい。ＬＳＩＤテーブルは、前述したシグナリングメッセージによって伝達されてもよく、これは、シグナリングメッセージヘッダーとシグナリングメッセージデータ部分とに区別できる。シグナリングメッセージデータ部分は、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）又はその一部を含むことができる。シグナリングメッセージデータは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）テーブルを含むことができ、次のようなフィールドを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングテーブルであることを示す識別子情報を示すことができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングシンタックスなどのシグナリングのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎフィールドは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングデータの変化などを示すことができる。これに加えて、伝送セッションインスタンスディスクリプタテーブルは、前述した伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）エレメントの内容をさらに含むことができる。
【０８１６】
図６５は、本発明の一実施例に係る、次世代放送システムが用いるＩＳＤＴを伝送する方法を示す。次世代放送システムは、Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ（ＩＳＤＴ）を伝送することによって放送サービス内のコンポーネントと関連したＤＡＳＨ  ＲｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔに対するシグナリング情報を伝達することができる。放送サービス内コンポーネントと関連したＤＡＳＨ  ＲｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔに対するシグナリングメッセージは、ヘッダーとデータを含むことができる。Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、前述した形態にしたがうことができ、シグナリングメッセージデータは、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ  ｄｅｌｉｖｅｒｙ情報又はその一部を含むことができる。ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ  ｄｅｌｉｖｅｒｙ情報は、次の情報を含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ或いはその経路情報を含むシグナリングメッセージであることを識別することができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、当該シグナリングメッセージのｓｙｎｔａｘなどのｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅのインスタンスに対する識別子を示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄ情報は、当該コンポーネントと関連したサービスを識別することができる。Ｍｐｄ＿ｉｄ情報は、当該コンポーネントと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒｉｏｄ＿ｉｄ情報は、当該コンポーネントと関連したＤＡＳＨ  Ｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ｉｄ情報は、当該コンポーネントと関連したＤＡＳＨ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｖｅｒｓｉｏｎ情報は、当該ＭＰＤの変化などを示すバージョン情報であってもよい。Ｄｅｌｉｖｅｒｙ＿ｍｏｄｅ情報は、当該ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔを含んでいるか、他の経路を介して伝達されるかなどに関する情報を示すことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ  ＿ｄａｔａ（）情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔデータ自体を含むことができる。ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ  ｐａｔｈ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔに対するＵＲＬなどの、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔを取得し得る経路に関する情報を含むことができる。このようなＩＳＤＴを用いて、受信機は、コンポーネントと関連したＤＡＳＨ  ＲｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉ���ｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔに関する情報を受信することができる。
【０８１７】
図６６は、本発明の一実施例に係る次世代放送システムのシグナリングメッセージのデリバリー構造を示す。前述したシグナリングデータがアプリケーションレイヤ伝送、例えば、ＲＯＵＴＥをベースに伝送される場合、図示のように伝達されてもよい。すなわち、迅速なサービスのスキャンなどを支援するためにｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌなどを介して一部のシグナリングを伝送することができる。そして、シグナリングの一部は、特定伝送セッションを介して伝送されてもよく、またコンポーネントデータと混在して伝達されてもよい。
【０８１８】
迅速なサービスのスキャン及び取得を支援するためのシグナリング情報は、伝送セッションと別途のチャネルで受信されてもよい。ここで、別途のチャネルとは、別途のデータパイプ（ｄａｔａ  ｐｉｐｅ，ＤＰ）を意味できる。また、サービスに対する詳細情報は、別途の指定された伝送セッションを介して受信されてもよく、この時、当該伝送セッションはＴＳＩ＝０の値を有することができる。ここで、指定された伝送セッションを介して伝達される情報は、ＭＰＤデリバリーテーブル、アプリケーションシグナリングテーブル、伝送セッションインスタンスディスクリプションテーブル及び／又はコンポーネントマッピングテーブルを含むことができる。また、一部のシグナリング情報は、コンポーネントデータと共に伝送セッションで伝達されてもよく、例えば、ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ  ｄｅｌｉｖｅｒｙ  ｔａｂｌｅがコンポーネントデータと共に伝達されてもよい。
【０８１９】
同図の下段は、次世代放送網で放送サービスを取得する実施例を示す。受信機は、サービスが選択されると、ブロードキャストをチューニングし、速いサービススキャン及び取得のための情報を取得してパーシングすることができる。その後、速いサービススキャン及び取得のための情報から、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプション（例えば、ＴＳＩＤ、ＬＳＩＤ）の位置が決定されると、当該ディスクリプションを取得してパーシングすることができる。これと共に、受信機は、シグナリングを含む伝送セッションを確認して、このセッションからシグナリングテーブルを取得してパーシングでき、所望のコンポーネントを決定することができる。この過程を通じて所望のコンポーネントをプレゼンテーションすることができる。すなわち、放送サービスは、速いサービススキャン及び取得のための情報から伝送セッションに関する情報を取得し、伝送セッションに関する情報から所望のコンポーネントの位置を確認して当該コンポーネントを再生することによって、ユーザへの提供が可能である。
【０８２０】
図６７は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ  ｏｆ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ  ｏｆ  ｏｖｅｒａｌｌ  ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ  ｄａｔａ  ｖｅｒｓｉｏｎ  ｏｆ  ｔｈｉｓ  ＦＩＣ  ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティションの個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅ  ｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣ Ｍ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ  ｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰ  ｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッション��識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、関連したサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する度に当該フィールドは、１ずつ増加してもよい。受信機はｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて当該サービスと関連したシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドは、サービスシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｔｓｉフィールドは、サービスシグナリングを伝達する伝送セッションの識別子などを示すことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒ  ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。
【０８２１】
図６８は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ  ｏｆ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ  ｏｆ  ｏｖｅｒａｌｌ  ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのサービスの個数を示すことができる。各サービスは、複数のシグナリングテーブルを含むことができる。例えば、コンポーネントとそのセグメントに関する情報を含むＤＡＳＨ  ＭＰＤ、ブロードバンド及び他のブロードキャストストリームに含まれたコンポーネントに対する識別子を含むＣＭＴ、アプリケーションシグナリングテーブルであるＡＳＴ、及びＭＰＤ、ＣＭＴ、ＡＳＴのうち少なくとも一つのＵＲＬを含むＵＳＴ（ＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｔａｂｌｅ）を含むことができる。それらのシグナリングテーブルは、当該サービスのシグナリングチャネルに含まれてもよい。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅ  ｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。例えば、ＦＩＣ、ＭＰＤ、ＣＭＴ、ＡＳＴ又はＵＳＴに変化がある場合に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣ Ｍ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ  ｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓは、ブロードキャストストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッションの個数を示すことができる。例えば、伝送セッションはＲＯＵＴＥセッションであってもよい。次の情報は、各ＲＯＵＴＥセッションに対して設定されてもよい。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部���報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスのコンポーネントシグナリングを伝送するか否かを示すことができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、当該伝送セッションを介して伝送されるデータのうち、サービスシグナリング（例えば、ＭＰＤ（ＤＡＳＨ  Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）、ＣＭＴなど）を含んでいることを示すことができる。ここで、ＣＭＴは、Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅであり、ブロードバンドを介して伝達されるコンポーネントの識別子を含むことができ、また他のブロードキャストストリームに含まれたコンポーネントに関する情報も含むことができる。各サービスは、サービスシグナリングチャネルを含むことができ、サービスシグナリングチャネルは、ＭＰＤ、ＣＭＴ、ＡＳＴ及び／又はＵＳＴを含むことができる。サービスシグナリングチャネルは、サービスのための複数のルートセッションのうち一つのシグナリングチャネルであってもよく、存在するか否かをｃｏｍｐｏｎｅｎｔ  ｓｉｇｎａｌｉｎｇフラグで示すことができる。複数の伝送セッション（ＲＯＵＴＥ又はＭＭＴＰセッション）がシグナリング及びサービスのコンポーネントを伝送する場合、好ましくは、前述したサービスシグナリングテーブルは一つの伝送セッションによって伝達されてもよい。
【０８２２】
ＲＯＵＴＥ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒ  ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。
【０８２３】
実施例によって上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。
【０８２４】
図６９は、本発明の一実施例に係る、コンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢｒｏａｄｃａｓｔＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。
【０８２５】
ＢＢＣｏｍｐは、ブロードバンド網を介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢＢＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。
【０８２６】
ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＦｏｒｅｉｇｎＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅ  ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性及びｄａｔａｐｉｐｅＩＤ属性は、実施例によってオプショナルな属性であってもよく、ＣＭＴに選択的に含まれてもよい。上記のＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。下段に示すように、Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、前述した形態に従うことができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。上記のような情報を用いてＣＭＴは各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。
【０８２７】
図７０は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢｒｏａｄｃａｓｔＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。ｔｓｉ属性は、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。
【０８２８】
ＢＢＣｏｍｐは、ブロードバンド網を介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢＢＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。
【０８２９】
ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ，ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＦｏｒｅｉｇｎＣｏｍｐと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅ  ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性及びｄａｔａｐｉｐｅＩＤ属性は、実施例によってオプショナルな属性であってもよく、ＣＭＴに選択的に含まれてもよい。上記のＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。下段に示すように、Ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒは、前述した形態に従うことができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。上記のような情報を用いて、ＣＭＴは、各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。
【０８３０】
図７１及び図７２は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルは、ＤＡＳＨ関連識別子と共に伝送パラメータエレメント（ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒ  ｅｌｅｍｅｎｔ）及びペイロードフォーマットエレメント（ＰａｙｌｏａｄＦｏｒｍａｔ  ｅｌｅｍｅｎｔ）を含むことができる。
【０８３１】
コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。Ｃｏｍｐｏｎｅｎｔエレメントは、当該放送サービス内のコンポーネントを示すことができる。Ｃｏｍｐｏｎｅｎｔエレメントは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ属性、ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメント及び／又はＰａｙｌｏａｄＦｏｒｍａｔエレメントのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、コンポーネントと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。
【０８３２】
ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントは、当該コンポーネントが伝送される経路などに対する細部情報を含むことができる。ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントは、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ、ｔｓｉ、ｄａｔａｐｉｐｅＩＤ及び／又はＵＲＬのうち少なくとも一つを含むことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅ  ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるフィジカルレイヤデータパイプの識別子を示すことができる。ＵＲＬ属性は、インターネット網などを介して当該コンポーネントデータを取得し得るＵＲＬ情報を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性、ｄａｔａｐｉｐｅＩＤ属性及び／又はＵＲＬ属性は、実施例によってオプショナルな属性であってもよく、ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントに選択的に含まれてもよい。
【０８３３】
ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ｃｏｄｅＰｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。ｃｏｄｅＰｏｉｎｔ属性は、当該ペイロードで用いられるコードポイントを定義することができる。これは、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は、当該デリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性は、フラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性は、オブジェクトのデリバリー順序を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性は、ｓｏｕｒｃｅ  ＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントは、ＦＥＣパラメータを定義することができる。これは、ＦＥＣ  ｅｎｃｏｄｉｎｇ  ｉｄ、ｉｎｓｔａｎｃｅ  ｉｄなどを含むことができる。
【０８３４】
図７３は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、ｓｅｒｖｉｃｅ＿ｉｄ属性、ｍｐｄ＿ｉｄ属性、ｐｅｒ＿ｉｄ属性、ＢｒｏａｄｃａｓｔＣｏｍｐエレメント、ＢＢＣｏｍｐエレメント及びＦｏｒｅｉｇｎＣｏｍｐエレメントを含むことができる。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＣＭＴディスクリプションは、ｓｅｒｖｉｃｅ＿ｉｄ属性と同じレベルにｍｐｄＩＤ属性及びｐｅｒＩＤ属性を含むことができる。すなわち、ＢｒｏａｄｃａｓｔＣｏｍｐエレメント、ＢＢＣｏｍｐエレメント及びＦｏｒｅｉｇｎＣｏｍｐエレメントに共通的に適用されるｍｐｄＩＤ属性及びｐｅｒＩＤ属性を重複して記述せず、ｓｅｒｖｉｃｅ＿ｉｄ属性と同じレベルで記述することができる。ｍｐｄＩＤ属性は、当該サービスと関連したＤＡＳＨ  ＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。
【０８３５】
ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。ｔｓｉ属性は、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。
【０８３６】
ＢＢＣｏｍｐエレメントは、ブロードバンド網を介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐは、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬのうち少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。
【０８３７】
ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅ  ＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅ  ＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎ  ＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性、ｔｓｉ属性及びｄａｔａｐｉｐｅＩＤ属性は、実施例によってオプショナルな属性であってもよく、ＣＭＴに選択的に含まれてもよい。上記のＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。上記のような情報を用いて、ＣＭＴは、各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。
【０８３８】
図７４は、本発明の一実施例に係るＭＰＤの共通属性及びエレメントを示す図である。次世代放送システムは、ＤＡＳＨベースハイブリッド放送サービスを提供することができる。次世代放送システムは、ＤＡＳＨ  ＭＰＤ内のＲｅｐｒｅｓｅｎｔａｔｉｏｎなどと関連したセグメントが互いに異なるｄｉｓｔｒｉｂｕｔｉｏｎ経路を介して伝達されることを示すことができる。ＭＰＤの共通属性及びエレメント（Ｃｏｍｍｏｎ  ａｔｔｒｉｂｕｔｅｓ  ａｎｄ  ｅｌｅｍｅｎｔｓ）は、ａｄａｐｔａｔｉｏｎ  ｓｅｔ、ｒｅｐｒｅｓｅｎｔａｔｉｏｎ及びｓｕｂ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎエレメントに共通に存在してもよく、図示しているように、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置情報を含むことができる。次世代放送システムは、ＭＰＤの共通属性及びエレメントに含まれた関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置情報を用いて、ＤＡＳＨ  ｃｌｉｅｎｔに、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎ又はセグメントの位置を知らせることができる。ＭＰＤの共通属性及びエレメントは、次のような属性及びエレメントを含むことができる。＠ｐｒｏｆｉｌｅｓ属性は、プロファイル属性であり、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎのプロファイルを示すことができる。＠ｗｉｄｔｈ属性は、ディスプレイされるビデオメディアタイプの水平表示サイズ（ｈｏｒｉｚｏｎｔａｌ  ｖｉｓｕａｌ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｓｉｚｅ）を示すことができる。＠ｈｅｉｇｈｔ属性は、ディスプレイされるビデオメディアタイプの垂直表示サイズ（ｖｅｒｔｉｃａｌ  ｖｉｓｕａｌ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｓｉｚｅ）を示すことができる。＠ｓａｒ属性は、ビデオメディアコンポーネントタイプのｓａｍｐｌｅ  ａｓｐｅｃｔ  ｒａｔｉｏを示すことができる。＠ｆｒａｍｅＲａｔｅ属性は、ｒｅｐｒｅｓｅｎｔａｔｉｏｎの出力フレームレートを示すことができる。＠ａｕｄｉｏＳａｍｐｌｉｎｇＲａｔｅ属性は、オーディオメディアコンポーネントタイプのサンプリングレートを示すことができる。＠ｍｉｍｅＴｙｐｅ属性は、初期化セグメントの連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）のＭＩＭＥタイプを示すことができる。＠ｓｅｇｍｅｎｔＰｒｏｆｉｌｅｓ属性は、当該ｒｅｐｒｅｓｅｎｔａｔｉｏｎをプロセスするための必須なセグメントのプロファイルを示すことができる。＠ｃｏｄｅｃｓ属性は、当該ｒｅｐｒｅｓｅｎｔａｔｉｏｎ内で用いられるコーデックを示すことができる。＠ｍａｘｉｍｕｍＳＡＰＰｅｒｉｏｄ属性は、含まれたメディアストリームの最大ＳＡＰ（ｓｔｒｅａｍ  ａｃｃｅｓｓ  ｐｏｉｎｔ）インターバルを示すことができる。＠ｓｔａｒｔＷｉｔｈＳＡＰ属性は、ＳＡＰと共に開始する各メディアセグメントの数を示すことができる。＠ｍａｘＰｌａｙｏｕｔＲａｔｅ属性は、最大プレイアウトレートを示すことができる。＠ｃｏｄｉｎｇＤｅｐｅｎｄｅｎｃｙ属性は、デコーディングのために一つ又はそれ以上の他のアクセスユニットに依存する少なくとも一つのアクセスユニットが存在するか否かを示すことができる。＠ｓｃａｎＴｙｐｅ属性は、ビデオメディアコンポーネントタイプのｓｏｕｒｃｅ  ｍａｔｅｒｉａｌのスキャンタイプを示すことができる。Ｆ��ａｍｅＰａｃｋｉｎｇエレメントは、ビデオメディアコンポーネントタイプのフレーム−パッキング情報を示すことができる。ＡｕｄｉｏＣｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎエレメントは、オーディオメディアコンポーネントタイプのオーディオチャネル設定を示すことができる。ＣｏｎｔｅｎｔＰｒｏｔｅｃｔｉｏｎエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎに対して用いられたコンテンツ保護スキームに関する情報を示すことができる。ＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙエレメントは、プロセシングに必ず考慮されるエレメントに関する情報を示すことができる。ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙエレメントは、プロセシングを最適化するために用いられる付加情報を含むことができる。ＩｎｂａｎｄＥｖｅｎｔＳｔｒｅａｍエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎにインバンドイベントストリームが存在するか否かを示すことができる。Ｌｏｃａｔｉｏｎエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを取得し得る位置情報を含むことができる。Ｌｏｃａｔｉｏｎエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを運搬するブロードキャストストリーム又は物理チャネルデータパイプ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｄａｔａ  ｐｉｐｅｓ）に関する情報を含むことができる。ＤＡＳＨ  ｃｌｉｅｎｔ又は次世代放送受信装置は、Ｌｏｃａｔｉｏｎエレメントを用いて、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを取得することができる。すなわち、次世代放送システム受信装置は、前述したＣＭＴを用いなくとも、ＭＰＤのＣｏｍｍｏｎ  ａｔｔｒｉｂｕｔｅｓ  ａｎｄ  ｅｌｅｍｅｎｔｓに含まれた位置情報を用いて関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置に関する情報を取得し、それに基づいて、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを取得することができる。上述したｒｅｐｒｅｓｅｎｔａｔｉｏｎは、実施例によってコンポーネントとして説明されてもよい。
【０８３９】
また、他の実施例で、次世代放送システムは、関連したＲｅｐｒｅｓｅｎｔａｔｉｏｎなどの伝送経路に関する情報を、ＤＡＳＨ  ＭＰＤ内のＢａｓｅ  ＵＲＬ  ｅｌｅｍｅｎｔの＠ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ属性に割り当てることができる。次世代放送システムは、＠ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ属性を用いてＤＡＳＨ  ｃｌｉｅｎｔに、当該ｒｅｐｒｅｓｅｎｔａｔｉｏｎと関連したセグメントが伝達される経路に関する情報を知らせることができる。
【０８４０】
図７５は、本発明の一実施例に係る伝送セッションインスタンスディスクリプションを示す図である。アプリケーションレイヤ伝送方法がＲＯＵＴＥである場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションで構成されてもよい。一つ以上の伝送セッション（Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）に対する細部情報は、伝送セッションインスタンスディスクリプションを用いてシグナリングすることができる。伝送セッションインスタンスディスクリプタは、ＲＯＵＴＥの場合、ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）と呼ぶこともできる。特に、伝送セッションインスタンスディスクリプションは、ＲＯＵＴＥセッションを構成する各ＬＣＴ伝送セッションによって何が伝達されるかを定義することができる。各伝送セッションは、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ，ＴＳＩ）によってユニークに識別されてもよい。伝送セッション識別子はＬＣＴヘッダーに含まれてもよい。伝送セッションインスタンスディスクリプションは、当該セッションを介して伝送される全ての伝送セッションを記述することができる。例えば、ＬＳＩＤは、ＲＯＵＴＥセッションによって運搬されるモードＬＣＴセッションを記述することができる。伝送セッションインスタンスディスクリプションは、伝送セッションと同じＲＯＵＴＥセッションで伝達されたり、又は互いに異なるＲＯＵＴＥセッション又はユニキャストで伝達されてもよい。
【０８４１】
同じＲＯＵＴＥセッションで伝達される場合、伝送セッションインスタンスディスクリプションは、指定された伝送セッション識別子（ＴＳＩ）０を有する伝送セッションで伝達されてもよい。伝送セッションインスタンスディスクリプションで参照される他のオブジェクトもＴＳＩ＝０で伝達されてもよいが、伝送セッションインスタンスディスクリプションとは異なるＴＯＩ値を有することができる。又は、ＴＳＩ≠０の分離された伝送セッションで伝達されてもよい。伝送セッションインスタンスディスクリプションは、バージョンナンバー、有効（ｖａｌｉｄｉｔｙ）情報又は満了（ｅｘｐｉｒａｔｉｏｎ）情報のうち少なくとも一つを用いてアップデートされてもよい。伝送セッションインスタンスディスクリプションは、図示された形態以外にｂｉｔｓｔｒｅａｍなどと表現されてもよい。
【０８４２】
伝送セッションインスタンスディスクリプションは、ｖｅｒｓｉｏｎ属性、ｖａｌｉｄＦｒｏｍ属性、ｅｘｐｉｒａｔｉｏｎ属性を含むことができ、各伝送セッションに対してＴＳＩ属性、ＳｏｕｒｃｅＦｌｏｗエレメント、ＲｅｐａｉｒＦｌｏｗエレメント、ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメントを含むことができる。ｖｅｒｓｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションのバージョン情報を示すことができ、その内容がアップデートされる度にバージョン情報は増加してもよい。最高のバージョンナンバーを有する伝送セッションインスタンスディスクリプションが最近の有効なバージョンであることを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、当該伝送セッションインスタンスディスクリプションがいつから有効であるかを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、実施例によって伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは受信されると直ちに有効であることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションがいつ満了するかを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、実施例によって伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは継続して有効なものであることを示すことができる。仮に、ｅｘｐｉｒａｔｉｏｎ属性を有する伝送セッションインスタンスディスクリプションが受信されると、当該ｅｘｐｉｒａｔｉｏｎ属性に従うことができる。ＴＳＩ属性は、伝送セッション識別子を示すことができ、ＳｏｕｒｃｅＦｌｏｗエレメントは、当該ＴＳＩで伝送されるソースフローの情報を提供し、詳細内容は後述する。ＲｅｐａｉｒＦｌｏｗエレメントは、当該ＴＳＩで伝送されるリペアフローの情報を提供することができる。ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメントは、当該伝送セッションに対する付加的な属性情報を含むことができる。伝送セッションインスタンスディスクリプションは、ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメント内に伝送セッションに対する付加的な属性情報を含むことができ、例えば、付加情報は、伝送セッションに対するサービスシグナリング情報を含むことができる。
【０８４３】
図７６は、本発明の一実施例に係る、次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す。ソースフローエレメントは、ＥＦＤＴエレメント、ｉｄＲｅｆ属性、ｒｅａｌｔｉｍｅ属性、ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性、Ａｐｐｌｉｃａｔｉｏｎ  Ｉｄｅｎｄｔｉｆｉｅｒエレメント、ＰａｙｌｏａｄＦｏｒｍａｔエレメント及び／又はＳｏｕｒｃｅＦｌｏｗＰｒｏｐｅｒｔｙエレメントを含むことができる。ＥＦＤＴエレメントは、ファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴは、ｅｘｔｅｎｄｅｄ  Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ（ＦＤＴ）  ｉｎｓｔａｎｃｅを示すことができ、詳細な内容は後述する。ｉｄＲｅｆ属性は、ＥＦＤＴの識別子を示すことができ、対応する伝送セッションによってＵＲＩと表現されてもよい。ｒｅａｌｔｉｍｅ属性は、当該ＬＣＴパケットが拡張ヘッダー（ｅｘｔｅｎｓｉｏｎ  ｈｅａｄｅｒ）を含むことを示すことができる。拡張ヘッダーは、デリバリーオブジェクトのプレゼンテーションタイムを示すタイムスタンプを含むことができる。ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性は、受信機に保存されるために必要なデータの最大量を定義することができる。Ａｐｐｌｉｃａｔｉｏｎ  Ｉｄｅｎｄｔｉｆｉｅｒエレメントは、当該伝送セッションによって運搬されるアプリケーションにマッピングされ得る付加情報を提供することができる。例えば、レンダリングのための伝送セッションを選択するためのＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎ  ＩＤ又はＤＡＳＨ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎのＡｄａｐｔａｔｉｏｎ  Ｓｅｔパラメータが付加情報として提供されてもよい。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ソースフローのオブジェクトを運搬するＲＯＵＴＥパケットのペイロードフォーマットを定義することができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ｃｏｄｅＰｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。ｃｏｄｅＰｏｉｎｔ属性は、当該ペイロードで用いられるコードポイントを定義することができる。これは、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は、当該デリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性は、フラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性は、オブジェクトのデリバリー順序を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性は、ｓｏｕｒｃｅ  ＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントは、ＦＥＣパラメータを定義することができる。これは、ＦＥＣ  ｅｎｃｏｄｉｎｇ  ｉｄ、ｉｎｓｔａｎｃｅ  ｉｄなどを含むことができる。ＳｏｕｒｃｅＦｌｏｗＰｒｏｐｅｒｔｙエレメントは、当該ソースフローに対する属性情報を提供することができる。例えば、属性情報は、当該ソースフローデータを運搬するブ��ードキャストの位置情報を含むことができる。ここで、ブロードキャストの位置情報はブロードキャストストリーム内のデータパイプ又は（ＰＬＰｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｉｐｅ）に関する情報を含むことができる。
【０８４４】
図７７は、本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。図示のサービス取得情報は、前述したサービス取得情報にリンクレイヤシグナリングに関する情報をさらに含むことができる。リンクレイヤシグナリングに関する情報は、リンクレイヤシグナリングが存在するか否かを示すフラグ情報、リンクレイヤシグナリングデータのバージョン情報、及びリンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、システム取得情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。
【０８４５】
システム取得情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ  ｏｆ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ  ｏｆ  ｏｖｅｒａｌｌ  ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓ  ｄａｔａ  ｖｅｒｓｉｏｎ  ｏｆ  ｔｈｉｓ  ＦＩＣ  ｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅ  ｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣ Ｍ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フ��グと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ  ｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰ  ｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、��ービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、関連したサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する度に当該フィールドは、１ずつ増加してもよい。受信機は、ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて当該サービスと関連したシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドは、サービスシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｔｓｉフィールドは、サービスシグナリングを伝達する伝送セッションの識別子などを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇは、サービス取得情報がリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングを伝送するか否かを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎは、関連したリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングデータの変化を示すことができる。当該フィールドは、リンクレイヤシグナリングデータに変化が発生する度に１ずつ増加してもよい。これを用いて受信機はリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングの変化を感知することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｉｄは、Ｌ２レイヤで利用可能なリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒ  ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。
【０８４６】
図７８は、本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。また、サービス取得情報は、リンクレイヤシグナリングに関する情報をさらに含むことができる。図示のように、サービス取得情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなどの他のフォーマットで表現されてもよい。
【０８４７】
サービス取得情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（Ｖｅｒｓｉｏｎ  ｏｆ  ｓｔｒｕｃｔｕｒｅ  ｏｆ  ＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒ  ｏｆ  ｏｖｅｒａｌｌ  ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ）を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのサービスの個数を示すことができる。各サービスは、複数のシグナリングテーブルを含むことができる。例えば、コンポーネントとそのセグメントに関する情報を含むＤＡＳＨ  ＭＰＤ、ブロードバンド及び他のブロードキャストストリームに含まれたコンポーネントに対する識別子を含むＣＭＴ、アプリケーションシグナリングテーブルであるＡＳＴ及びＭＰＤ、ＣＭＴ、ＡＳＴのうち少なくとも一つのＵＲＬを含むＵＳＴ（ＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｔａｂｌｅ）を含むことができる。これらのシグナリングテーブルは、当該サービスのシグナリングチャネルに含まれてもよい。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅ  ｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。例えば、ＦＩＣ、ＭＰＤ、ＣＭＴ、ＡＳＴ又はＵＳＴに変化がある場合に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて、ＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣ Ｍ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ  ｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓは、ブロードキャストストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッションの個数を示すことができる。例えば、伝送セッションは、ＲＯＵＴＥセッションであってもよい。次の情報は、各ＲＯＵＴＥセッションに対して設定されてもよい。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスのコ���ポーネントシグナリングを伝送するか否かを示すことができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、当該伝送セッションを介して伝送されるデータのうちサービスシグナリング（例えば、ＭＰＤ（ＤＡＳＨ  Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）、ＣＭＴなど）を含んでいることを示すことができる。ここで、ＣＭＴは、Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅであり、ブロードバンドを介して伝達されるコンポーネントの識別子を含むことができ、また、他のブロードキャストストリームに含まれたコンポーネントに関する情報も含むことができる。各サービスは、サービスシグナリングチャネルを含むことができ、サービスシグナリングチャネルは、ＭＰＤ、ＣＭＴ、ＡＳＴ及び／又はＵＳＴを含むことができる。サービスシグナリングチャネルは、サービスのための複数のルートセッションのうち一つのシグナリングチャネルであってもよく、存在するか否かをコンポーネントシグナリングフラグで示すことができる。複数の伝送セッション（ＲＯＵＴＥ又はＭＭＴＰセッション）がシグナリング及びサービスのコンポーネントを伝送する場合、好ましくは、前述したサービスシグナリングテーブルは、一つの伝送セッションによって伝達することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇは、サービス取得情報がリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングを伝送するか否かを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎは、関連したリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングデータの変化を示すことができる。当該フィールドは、リンクレイヤシグナリングデータに変化が発生する度に１ずつ増加してもよい。これを用いて受信機はリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングの変化を感知することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｉｄは、Ｌ２レイヤで利用可能なリンクレイヤ（或いは、ｌｏｗ  ｌａｙｅｒ）シグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。
【０８４８】
ＲＯＵＴＥ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒ  ｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣ  ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。
【０８４９】
実施例によって、上述したサービス取得情報に含まれた各フィールドは、サービス取得情報以外の情報と共に放送信号に含まれて伝送されてもよい。
【０８５０】
図７９は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す。上段の図面は、本発明の次世代放送システムで用いるサービスレイヤシグナリングのフォーマットであり、サービスレイヤシグナリングは、図示しているような形態でエンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。次世代放送システムにおいて上記で提案したサービスシグナリングを用いる場合、下段の図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを用いて伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができる。言い換えると、当該フィールドは、物理層フレーム（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）が速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングしなければならないか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８５１】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。
【０８５２】
また、図示のように、伝送セッションインスタンスディスクリプタは、前述したエンカプセレーション形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、伝送セッションインスタンスディスクリプタを含むことができる。本発明で伝送セッションインスタンスディスクリプタはサービスレイヤシグナリングの一つとして含まれて伝達されてもよい。
【０８５３】
図８０は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す。次世代放送システムで上記で提案したサービスレイヤシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを介して伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８５４】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。
【０８５５】
また、図示のように、伝送セッションインスタンスディスクリプタは、前述したエンカプセレーション形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは伝送セッションインスタンスディスクリプタを含むことができる。本発明で伝送セッションインスタンスディスクリプタはサービスレイヤシグナリングの一つに含まれて伝達されてもよい。
【０８５６】
また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージはリンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋ  Ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。
【０８５７】
図８１は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す。次世代放送システムでサービス／コンポーネントシグナリングのために３ＧＰＰ  ｅＭＢＭＳシグナリングなどを用いる場合、図示のように伝達されてもよい。ここで、サービスレイヤシグナリングは、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌを含むことができ、伝送セッションインスタンスディスクリプションをさらに含むことができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを介して伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８５８】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌを含むことができる。
【０８５９】
また、図示のように、伝送セッションインスタンスディスクリプタは、前述したエンカプセレーション形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、伝送セッションインスタンスディスクリプタを含むことができる。本発明で伝送セッションインスタンスディスクリプタはサービスレイヤシグナリングの一つに含まれて伝達されてもよい。
【０８６０】
図８２は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す。次世代放送システムで３ＧＰＰ  ｅＭＢＭＳシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８６１】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によってＵｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌを含むことができる。
【０８６２】
また、図示のように、伝送セッションインスタンスディスクリプタは、前述したエンカプセレーション形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、伝送セッションインスタンスディスクリプタを含むことができる。本発明で伝送セッションインスタンスディスクリプタはサービスレイヤシグナリングの一つに含まれて伝達されてもよい。
【０８６３】
また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージはリンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋ  Ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。すなわち、次世代放送システムは、物理層フレームにリンクレイヤシグナリングが含まれたデータパイプ又はＰＬＰに対するシグナリング情報を含むことができる。
【０８６４】
図８３は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す。上段図面は、本発明の次世代放送システムで用いるサービスレイヤシグナリングのフォーマットであり、サービスレイヤシグナリングは図示のような形態でエンカプセレーションされてもよい。例えば、エンカプセレーションされたサービスレイヤシグナリングは、左上段に示すように、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、右上段に示すように、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８６５】
次世代放送システムで上記で提案したサービスシグナリングを用いる場合、下段図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８６６】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。前述したように、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄはサービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ１の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ２の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ３の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ  ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ  ｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇ  ｉｄ  ０ｘＦ１を有するサービスレイヤシグナリングを受信することができる。また、この時、バージョン情報を確認し、既に受信しているＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムはサービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。
【０８６７】
図８４は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。本発明の次世代放送システムで用いるサービスレイヤシグナリングは、エンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８６８】
次世代放送システムで上記で提案したサービスシグナリングを用いる場合、図示のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８６９】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。前述したように、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ１の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ２の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ３の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ  ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ  ｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇ  ｉｄ  ０ｘＦ１を有するサービスレイヤシグナリングを受信することができる。また、この時、バージョン情報を確認し、既に受信しているＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムは、サービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。
【０８７０】
また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、リンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋ  Ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。すなわち、次世代放送システムは、物理層フレームに、リンクレイヤシグナリングが含まれたデータパイプ又はＰＬＰに対するシグナリング情報を含むことができる。
【０８７１】
図８５は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す。本発明の次世代放送システムで用いるサービスレイヤシグナリングは、エンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８７２】
次世代放送システムで３ＧＰＰ  ｅＭＢＭＳシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムで上記で提案したサービスシグナリングを用いる場合、下段の図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを介して伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８７３】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によってＵｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌを含むことができる。前述したように、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ４の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ５の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＳｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌの内容に変更がある場合、変更されてもよい。また、ＭＰＤを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ６の値を有することができる。また、そのバージョン情報は０ｘ０２の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ  ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ  ｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇ  ｉｄ  ０ｘＦ４を有するサービスレイヤシグナリングを受信することができる。��た、この時、バージョン情報を確認し、既に受信しているＵｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムは、サービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。
【０８７４】
図８６は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。本発明の次世代放送システムで用いるサービスレイヤシグナリングは、エンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８７５】
次世代放送システムで３ＧＰＰ  ｅＭＢＭＳシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。
【０８７６】
図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌを含むことができる。前述したようにＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘはｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ４の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ５の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＳｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌの内容に変更がある場合、変更されてもよい。また、ＭＰＤを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇ  ｉｄとして０ｘＦ６の値を有することができる。また、そのバージョン情報は０ｘ０２の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ  ｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇ  ｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇ  ｉｄ  ０ｘＦ４を有するサービスレイヤシグナリングを受信することができる。また、この時、バージョン情報を確認し、既に受信しているＵｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムは、サービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。
【０８７７】
また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅを含むことができる。ここで、シグナリングメッセージは、リンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋ  Ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。すなわち、次世代放送システムは、物理層フレームに、リンクレイヤシグナリングが含まれたデータパイプ又はＰＬＰに対するシグナリング情報を含むことができる。
【０８７８】
図８７は、本発明の一実施例に係る、次世代放送システムのサービスレイヤシグナリングを伝送する方法を示す図である。サービスレイヤシグナリングは、前述したシグナリング又は３ＧＰＰ  ｅＭＢＭＳシグナリングを含むことができる。次世代放送システムの放送信号にＦａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌが存在しない場合、図示のように、迅速なサービススキャン及び取得を支援するためのシグナリングデータがｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｆｒａｍｅ内のｃｏｍｍｏｎ  ｄａｔａ  ｐｉｐｅ、ｄａｔａ  ｐｉｐｅ又はＰＬＰを介して伝送されてもよい。この場合、迅速なサービススキャン及び取得などと関連したシグナリングデータは、ｌｉｎｋ（或いは、ｌｏｗ）  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ形態でエンカプセレーションされて、他のｌｉｎｋ（或いは、ｌｏｗ）  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇなどと共に伝送されてもよい。すなわち、フレーム内のＰＬＰは、サービス取得情報を含むシグナリングデータを伝達することができる。さらに、これは、サービス／コンポーネントシグナリング或いはコンポーネントデータと同一の或いは別途のｄａｔａ  ｐｉｐｅ又はＰＬＰを介して伝送されてもよい。サービス／コンポーネントシグナリングは、上記で提案したシグナリング或いは３ＧＰＰ  ｅＭＢＭＳシグナリングなどを伝送することができる。当該シグナリングは、前述したように、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅを含むことができる。ここで、ＳＭＨは、実施例によってシグナリングフォーマットに含まれなくてもよい。ここで、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。
【０８７９】
下段の図面は、リンクレイヤシグナリングに含まれたサービス取得情報を用いてサービスレイヤシグナリングを取得する方法を示す図である。放送信号フレームのＰＬＰは、リンクレイヤシグナリングを含むことができる。リンクレイヤシグナリングは、前述した速いサービススキャン及び取得情報を含むことができる。速いサービススキャン及び取得情報は、サービス識別子及び当該サービスに対するサービスレイヤシグナリングが含まれたＰＬＰ識別子情報を含むことができる。当該ＰＬＰ識別子によって指示されるＰＬＰは、サービスレイヤシグナリングを含むことができる。サービスレイヤシグナリングは、上述したように、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅを含むことができる。サービスレイヤシグナリングのシグナリングメッセージは、伝送セッションインスタンスディスクリプション、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。次世代放送信号受信機は、サービスレイヤシグナリングをパーシングして所望のサービスを取得することができる。
【０８８０】
図８８は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。サービスレイヤシグナリングは、前述したシグナリング又は３ＧＰＰ  ｅＭＢＭＳシグナリングを含むことができる。放送信号フレームのＰＬＰは、リンクレイヤシグナリングを含むことができる。リンクレイヤシグナリングは、前述した速いサービススキャン及び取得情報を含むことができる。速いサービススキャン及び取得情報は、サービス識別子及び当該サービスに対するサービスレイヤシグナリングが含まれたＰＬＰ識別子情報を含むことができる。当該ＰＬＰ識別子によって指示されるＰＬＰは、サービスレイヤシグナリングを含むことができる。サービスレイヤシグナリングは、上述したように、Ｇｅｎｅｒｉｃ  ｐａｃｋｅｔ  ｈｅａｄｅｒ（ＧＰＨ）、ＩＰ  ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＩＰＨ）、ＵＤＰ  ｄａｔａｇｒａｍ  ｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）及びｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅを含むことができる。サービスレイヤシグナリングのシグナリングメッセージは、伝送セッションインスタンスディスクリプション、ＭＰＤ  ｄｅｌｉｖｅｒｙ  ｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎを含むことができる。次世代放送信号受信機は、サービスレイヤシグナリングをパーシングして所望のサービスを取得することができる。ここで、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇ  ｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇ  ｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。ｆｉｌｔｅｒｉｎｇ  ｉｎｄｅｘを用いてサービスレイヤシグナリングをフィルタリングする方法は、前述したとおりである。
【０８８１】
図８９は、本発明の他の実施例に係る、シグナリングメッセージ（ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ）のヘッダー（ｈｅａｄｅｒ）のシンタックス（ｓｙｎｔａｘ）を示す図である。
【０８８２】
本発明の他の実施例に係るシグナリングメッセージは、ＸＭＬ形態で表現されてもよい。このとき、ＸＭＬ形態のシグナリングメッセージに含まれるシグナリング情報は、前述した又は後述するようなシグナリング情報に該当し得る。
【０８８３】
本発明の他の実施例に係る、シグナリングメッセージのヘッダーは、ｓｉｇｎａｌｉｎｇ＿ｉｄ情報、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈ情報、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ情報、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ情報、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ情報、ｉｎｄｉｃａｔｏｒ＿ｆｌａｇｓ情報、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ情報、ｐａｙｌｏａｄ＿ｆｏｒｍａｔ＿ｉｎｄｉｃａｔｏｒ情報、ｅｘｐｉｒａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ情報、ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒ情報、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒ情報、ｐａｙｌｏａｄ＿ｆｏｒｍａｔ情報、ｖａｌｉｄｆｒｏｍ情報、及び／又はｅｘｐｉｒａｔｉｏｎ情報を含むことができる。
【０８８４】
本実施例に係るシグナリングメッセージのヘッダーに含まれるシグナリング情報のうち、前述したシグナリングメッセージのヘッダーに含まれるシグナリング情報と同一又は類似の名称を有するシグナリング情報に関する説明は、前述した説明に代える。
【０８８５】
ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報は、シグナリングメッセージのヘッダー部分にｖａｌｉｄｆｒｏｍ情報の値が含まれたか否かを示すことができる。例えば、ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報の値が「１」である場合、シグナリングメッセージのヘッダー部分にｖａｌｉｄｆｒｏｍ情報が含まれていることを示すことができる。
【０８８６】
ｖａｌｉｄｆｒｏｍ情報は、ペイロード（ｐａｙｌｏａｄ）に含まれているシグナリングメッセージの可用開始時点を示すことができる。受信機は、これを用いて、ペイロードに含まれているシグナリングの可用開始時点を認知でき、当該時点からペイロードに含まれたデータをシグナリング情報として用いることができる。
【０８８７】
ここで、ペイロードは、放送サービス又は放送コンテンツのデータ（放送サービスデータ）を含む放送信号内の領域を表すことができる。すなわち、一般に、シグナリング情報は、放送信号内で、放送サービスデータとは物理的或いは論理的に区分された領域で伝送される。しかし、本発明によれば、ペイロード領域に余裕領域が存在する場合、又はシグナリング情報の伝送のために割り当てられた領域のサイズよりも多い量のシグナリング情報を伝送しなければならない場合には、放送信号内のペイロード領域を介してシグナリング情報を伝送することができる。
【０８８８】
図９０は、本発明の一実施例に係る、ＤＡＳＨ  Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ（ＤＡＳＨ初期化セグメント）を処理するプロトコルスタック（Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）を示す図である。
【０８８９】
ＤＡＳＨ初期化セグメントは、前述した、Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅのような形態又はＸＭＬ形態で伝送することができる。
【０８９０】
初期化セグメント（ＤＡＳＨ初期化セグメント）は、複数のセグメントでエンカプセレーションされた（ｅｎｃａｐｓｕｌａｔｅｄ）メディアストリーム（又は放送信号）を表出するために必要なメタデータ（シグナリング情報）を含むセグメントである。ここで、セグメントは、ＨＴＴＰ−ＵＲＬと関連したデータのユニットである。セグメントは、放送サービス又は放送コンテンツのためのデータを含む。リプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）は、伝送フォーマット内で一つ以上のメディアストリームを含むデータユニットである。リプレゼンテーションは一つ以上のセグメントを含むことができる。
【０８９１】
ＤＡＳＨ初期化セグメントは、送信機又は受信機で示すプロトコルスタックによって処理されてもよい。ＤＡＳＨ初期化セグメントは、プロトコルスタック（Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）上で一つ以上の経路を介して伝送されてもよい。
【０８９２】
プロトコルスタックについて説明すると、シグナリング情報又は放送サービスデータは、複数の層（ｌａｙｅｒ）のプロトコルによって処理されることがわかる。図面中、「シグナリングチャネル（ｓｉｇｎａｌｉｎｇ  ｃｈａｎｎｅｌ）、ＤＰ（Ｄａｔａ  Ｐｉｐｅ）」は第１層に該当し、「ＦＩＣ、リンクレイヤフレーム（Ｌｉｎｋ  Ｌａｙｅｒ  Ｆｒａｍｅ）」は第２層に該当し、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）は第３層に該当することができ、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）は第４層に該当し、ＲＯＵＴＥは第５層に該当し得る。ここで、リンクレイヤフレームは、本明細書に説明されたリンクレイヤパケットを含むことができる。
【０８９３】
ＤＡＳＨ初期化セグメントが処理されるプロトコルスタックは、同図の（１）の経路のように、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）のようなシグナリングデータがＩＰ／ＵＤＰに直接乗せられた伝送される場合、上記で提案したＩｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅのような形態の情報として伝送されたり、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）自体がＩＰデータグラムなどの形態で、プロトコルスタックの処理を経て伝送されてもよい。前述したサービスシグナリング及び／又はコンポーネントシグナリングのための情報は、図示１）の経路で共に伝送されてもよい。
【０８９４】
本発明の一実施例によれば、ＤＡＳＨ初期化セグメントは、経路（２）のように、シグナリングデータを伝送するための特定セッション（ｓｅｓｓｉｏｎ）で、又は経路（３）のように、コンポーネントデータを伝送するセッションでメディアデータと共に伝送されてもよい。一例として、アプリケーション伝送プロトコル（ａｐｐｌｉｃａｔｉｏｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）としてはＲＯＵＴＥ（Ｒｅａｌ−ｔｉｍｅ  Ｏｂｊｅｃｔ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を用いることができる。ＲＯＵＴＥセッションは、シグナリング情報を伝送するためのセッション及び／又は放送メディアに対するデータを伝送するセッションを含むことができる。放送システムは、シグナリング情報を伝送するセッションはＴＳＩの値を一定の値に固定し、これによって、受信機は、当該ＴＳＩの値を有するセッションで伝送されるデータはシグナリング情報であることを識別することができる。
【０８９５】
図示された経路（２）及び／又は経路（３）のように、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）のようなシグナリング情報（データ）が伝送される場合、伝送ストリーム又は伝送オブジェクトなどで前述のシグナリングメッセージフォーマットのデータ、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）がどの部分に位置するかを識別する情報、及び／又はシグナリングメッセージフォーマットのデータや初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）を、共に伝送されるデータの中から区別するための情報が、伝送プロトコルパケット内部のフィールド、又は別途のシグナリング形態で提供されてもよい。
【０８９６】
図９１は、本発明の一実施例に係る、ＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションインスタンスディスクリプタ（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＬＳＩＤ）の一部を示す図である。
【０８９７】
本発明の一実施例に係る、ＬＣＴセッションインスタンスディスクリプタは、シグナリングメッセージフォーマットのデータ、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）が放送信号内でどの部分に位置するかを識別する情報、及び／又はシグナリングメッセージフォーマットのデータや初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）を、共に伝送されるデータの中から区別するための情報を提供することができる。
【０８９８】
ＬＣＴセッションインスタンスディスクリプタは、ＰａｙｌｏａｄＦｏｒｍａｔエレメントを含むことができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、＠ｃｏｄｅＰｏｉｎｔ情報、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報、＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報、＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報及び／又は＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報含むことができる。
【０８９９】
それぞれのエレメントは、図面に説明されたような情報を提供するために用いることができる。
【０９００】
本発明の一実施例によれば、放送受信機又は放送送信機は、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）が含まれるＲＯＵＴＥパケットを識別するために、ＬＳＩＤのＳｏｕｒｃｅＦｌｏｗエレメント内のＰａｙｌｏａｄＦｏｒｍａｔエレメントの＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報（又は、フィールド）を用いることができる。
【０９０１】
一実施例で（に）、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報値が「０」である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は、当該ＲＯＵＴＥパケットはシグナリングメッセージフォーマットを含んでいることを示すことができる。＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報の値が「０」の場合、このＰａｙｌｏａｄＦｏｒｍａｔエレメントに割り当てられた＠ｃｏｄｅＰｏｉｎｔ情報の値とＬＣＴパケットヘッダー内の同一値のｃｏｄｅ  ｐｏｉｎｔ（ＣＰ）を有するＲＯＵＴＥパケットは、前述したシグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｆｏｒｍａｔ）形態のデータを伝送していることを示すことができる。初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）は本シグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｆｏｒｍａｔ）に含まれて伝送されてもよく、サービスシグナリング、コンポーネントシグナリングなどの他のシグナリングデータも、同じ方法でシグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇ  ｍｅｓｓａｇｅ  ｆｏｒｍａｔ）に含まれてＲＯＵＴＥパケットを介して伝送されていることが識別されてもよい。
【０９０２】
＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報の値が「４」である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔフィールドは、当該ＲＯＵＴＥパケットは初期化セグメントを含むメタデータ（シグナリング情報）を含むことを示すことができる。＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔフィールドの値が「４」である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）を含むメタデータフォーマットがＲＯＵＴＥパケットを介して伝送されることを示したり、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）が直接ＲＯＵＴＥパケットを介して伝送されていることを示すことができる。
【０９０３】
本発明の一実施例によれば、放送システム（放送受信機及び／又は送信機）は、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報に新しい値（例えば、「５」以上の値）を割り当てて、サービスシグナリング（サービスレベルシグナリング情報）、及び／又はコンポーネントシグナリング（コンポーネントレベルシグナリング）などの他のシグナリングデータがＲＯＵＴＥパケットを介して直接伝送されることをシグナリングすることができる。
【０９０４】
本発明の他の実施例によれば、放送システムは、本実施例で説明された＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報を用いる方法の他にも、ＬＳＩＤ内の他のフィールド又は新しい追加フィールドを用いて、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）などのシグナリングデータが伝送されるＲＯＵＴＥパケットを識別することもできる。
【０９０５】
図９２は、本発明の一実施例に係る、サービスシグナリングメッセージをフィルタリング（ｆｉｌｔｅｒｉｎｇ）するための情報を提供するシグナリングオブジェクトディスクリプション（Ｓｉｇｎａｌｉｎｇ  Ｏｂｊｅｃｔ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＳＯＤ）を示す図である。
【０９０６】
本発明の一実施例に係るシグナリングオブジェクトディスクリプションは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ｄａｔａＶｅｒｓｉｏｎ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、Ｓｉｇｎａｌｉｎｇ  Ｏｂｊｅｃｔエレメント、＠ｔｏｉ情報、＠ｔｙｐｅ情報、＠ｖｅｒｓｉｏｎ情報、＠ｉｎｓｔａｎｃｅ  Ｉｄ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔ情報を含むことができる。
【０９０７】
＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、シグナリングオブジェクトディスクリプションのバージョンを示す。
【０９０８】
＠ｄａｔａＶｅｒｓｉｏｎ情報は、シグナリングオブジェクトディスクリプションのインスタンス（ｉｎｓｔａｎｃｅ）のバージョン（ｖｅｒｓｉｏｎ）を示す。シグナリングオブジェクトディスクリプション内に含まれた内容が変更される場合に、＠ｄａｔａＶｅｒｓｉｏｎが変更されてもよい。
【０９０９】
＠ｖａｌｉｄＦｒｏｍ情報は、シグナリングオブジェクトディスクリプションのインスタンスの可用開始時点を示すことができる。これを用いて、受信機は、シグナリングオブジェクトディスクリプションの可用開始時点を認知でき、当該時点から、シグナリングオブジェクトディスクリプションに含まれた情報を用いることができる。
【０９１０】
＠ｅｘｐｉｒａｔｉｏｎ情報は、シグナリングオブジェクトディスクリプションのインスタンスの可用完了時点を示すことができる。これを用いて、受信機は、シグナリングオブジェクトディスクリプションの可用完了時点を認知でき、これを用いてシグナリングオブジェクトディスクリプションの情報を管理することができる。
【０９１１】
Ｓｉｇｎａｌｉｎｇ  Ｏｂｊｅｃｔエレメントは、シグナリング情報を含むオブジェクトを示す。シグナリングオブジェクトディスクリプションでは一つ以上のシグナリングオブジェクトに対するシグナリング情報を含むことができる。
【０９１２】
＠ｔｏｉ情報は、シグナリングオブジェクトに割り当てられたＴＯＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ）を示す。＠ｔｏｉ情報は、シグナリングオブジェクトと関連したパケットを識別するために用いられてもよい。受信機は、＠ｔｏｉ情報をＬＣＴパケットのＴＯＩにマッピングし、それぞれのｏｂｊｅｃｔが伝送するシグナリングメッセージのｔｙｐｅ、及び／又はｖｅｒｓｉｏｎなどの下の情報を識別することができる。
【０９１３】
＠ｔｙｐｅ情報は、オブジェクトに含まれているシグナリングメッセージのタイプを識別する情報である。例えば、＠ｔｙｐｅ情報の値が０であれば、ＬＳＩＤ（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が１であれば、ＣＭＤ（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が２であれば、ＡＳＤ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｉｇｎａｌｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が３であれば、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が４であればＵＳＤ（ＵＲＬ  Ｓｉｇｎａｌｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が５であれば、ＩＳ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）が、オブジェクト内でシグナリングメッセージとして伝送されることを示すことができる。
【０９１４】
＠ｖｅｒｓｉｏｎ情報は、シグナリングメッセージのバージョン（ｖｅｒｓｉｏｎ）を示す情報である。受信機は、本フィールド値の変化から、シグナリングメッセージの変更を識別することができる。
【０９１５】
＠ｉｎｓｔａｎｃｅ  Ｉｄ情報は、シグナリングメッセージのインスタンスを識別する情報である。本情報は受信機によって、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）のように一つのサービス内に複数個存在し得るシグナリングメッセージのインスタンスを区別するために用いられてもよい。
【０９１６】
＠ｖａｌｉｄＦｒｏｍ情報は、オブジェクトに含まれているシグナリングメッセージの可用開始時点を示すことができる。これを用いて、受信機は、オブジェクトに含まれているシグナリングの可用開始時点を認知でき、当該時点から、オブジェクトに含まれているシグナリングを用いることができる。
【０９１７】
＠ｅｘｐｉｒａｔｉｏｎ情報は、オブジェクトに含まれているシグナリングメッセージの有効時間を示すことができる。これを用いて、受信機は、オブジェクトに含まれているシグナリングの可用完了時間を認知でき、これを用いてシグナリングメッセージを管理することができる。
【０９１８】
＠ｐａｙｌｏａｄＦｏｒｍａｔ情報は、オブジェクトに含まれるシグナリングメッセージデータのフォーマットを示すことができる。例えば、シグナリングメッセージは、ｂｉｎａｒｙ又はＸＭＬの形式で提供されてもよく、＠ｐａｙｌｏａｄＦｏｒｍａｔ情報はこの形式を示す。
【０９１９】
シグナリングメッセージがＲＯＵＴＥなどのＬＣＴベースプロトコルで伝送される場合、それぞれのシグナリングメッセージをオブジェクトとして設定して処理することができる。上記のプロトコルでオブジェクトは固有のＴＯＩで識別されればいいので、それぞれのＴＯＩにｖｅｒｓｉｏｎ、ｔｙｐｅなどのシグナリングメッセージ関連情報をマッピングすることによって、シグナリングメッセージをフィルタリングすることができる。前述したような、ＳＯＤ（Ｓｉｇｎａｌｉｎｇ  Ｏｂｊｅｃｔ  Ｄｅｓｃｒｉｐｔｉｏｎ）は一つの伝送セッションに該当するシグナリングオブジェクトのフィルタリング情報を提供する。シグナリングオブジェクトディスクリプションは、シグナリングを伝送するセッションの内部、又は外部手段を介して伝送されてもよい。内部でシグナリングオブジェクトディスクリプションが伝送される場合、受信機は、固有のＴＯＩ値（例えば、０又は０ｘＦＦＦＦなどの値）によってシグナリングオブジェクトディスクリプションを識別し、共に伝送される他のシグナリングメッセージのに先にシグナリングオブジェクトディスクリプションを解釈することができる。外部でシグナリングオブジェクトディスクリプションが伝送される場合、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）、ＳＬＴ（ｓｅｒｖｉｃｅ  ｌｉｓｔ  ｔａｂｌｅ）、別途のＩＰデータグラム、又は他のＲＯＵＴＥセッションなどの手段を介してシグナリングオブジェクトディスクリプションが伝送され、当該セッションで伝達される他のオブジェクトの先に伝送されることで、受信機ではシグナリングメッセージの情報をあらかじめ取得することができる。
【０９２０】
図９３は、本発明の一実施例に係る、シグナリングメッセージを含むオブジェクトを示す図である。
【０９２１】
シグナリングメッセージがＲＯＵＴＥなどのＬＣＴベースプロトコルで伝送される場合、それぞれのシグナリングメッセージをオブジェクトに設定して処理することができる。上記のプロトコルでオブジェクトは固有のＴＯＩで識別されてもよい。受信機では、それぞれのＴＯＩにｖｅｒｓｉｏｎ、及び／又はｔｙｐｅなどのシグナリングメッセージ関連情報をマッピングし、シグナリングメッセージをフィルタリングすることができる。互いに異なる内容物を含むオブジェクトには互いに異なるＴＯＩが与えられ、この場合、放送システムでは、全てのオブジェクトが固有に識別され得るので、既存のオブジェクト処理方法と互換性のある方法でシグナリングメッセージを処理することができる。
【０９２２】
同図は、ＴＯＩフィールドの一部を固定長さのシグナリングメッセージ関連情報記述のために用いる実施例を示している。本実施例では、３２ビットのＴＯＩフィールドが用いられており、それぞれ１６ビットのＴｙｐｅとＶｅｒｓｉｏｎフィールドを用いて、オブジェクトを介して送信されている前述したシグナリングデータのｔｙｐｅとｖｅｒｓｉｏｎを識別することができる。同様の方法で、前述したｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ情報、ｖａｌｉｄ  ｆｒｏｍ情報、ｅｘｐｉｒａｔｉｏｎ情報、及び／又はｐａｙｌｏａｄ  ｆｏｒｍａｔ情報の追加情報も、本実施例におけるＴｙｐｅ、Ｖｅｒｓｉｏｎ共に、ＴＯＩフィールドの一部を固定長さのフィールドに割り当てることによって当該情報を伝達することができる。
【０９２３】
本発明の一実施例に係る、オブジェクトは、ｖエレメント、ｃエレメント、ＰＳＩエレメント、Ｓエレメント、Ｏエレメント、Ｈエレメント、Ａエレメント、Ｂエレメント、ＨＤＲ＿ＬＥＮエレメント、Ｃｏｄｅｐｏｉｎｔエレメント、Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎエレメント、Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ（ＴＳＩ）エレメント、Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）エレメント、Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎｓエレメント、ＦＥＣ  ｐａｙｌｏａｄ  ＩＤエレメント、及び／又はＥｎｃｏｄｉｎｇ  Ｓｙｍｂｏｌｓエレメントを含むことができる。ここで、エレメントは、情報又はフィールドと呼ぶこともできる。
【０９２４】
ＰＳＩエレメントは、Ｘエレメント及び／又はＹエレメントを含むことができる。
【０９２５】
ＴＯＩエレメントは、Ｔｙｐｅエレメント及び／又はＶｅｒｓｉｏｎエレメントを含むことができる。
【０９２６】
ｖエレメントは、パケットのバージョンナンバーを示す。ｖエレメントは、ＡＬＣ／ＬＣＴのバージョンを示すことができる。ｖエレメントは、ボンオブジェクトを介してＡＬＣ／ＬＣＴ＋に従うパケットが伝送されることを示すことができる。
【０９２７】
ｃエレメントは、Ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ  ｆｌａｇに該当する。ｃエレメントは、Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントの長さを示すことができる。例えば、ｃエレメントは、ｃエレメントの値が０である場合、ＣＣＩの長さは３２ビット、ｃエレメントの値が１である場合、ＣＣＩの長さは６４ビット、ｃエレメントの値が２である場合、ＣＣＩの長さは９６ビット、ｃエレメントの値が３である場合、ＣＣＩの長さは１２８ビットであることを示すことができる。
【０９２８】
ＰＳＩエレメントは、Ｐｒｏｔｏｃｏｌ−Ｓｐｅｃｉｆｉｃ  Ｉｎｄｉｃａｔｉｏｎ（ＰＳＩ）に該当し得る。ＰＳＩエレメントは、ＡＬＣ／ＬＣＴ＋の上位プロトコルに対する特定目的の指示子として用いられてもよい。ＰＳＩエレメントは、現在パケットがｓｏｕｒｃｅ  ｐａｃｋｅｔに該当するかＦＥＣ  ｒｅｐａｉｒ  ｐａｃｋｅｔに該当するかを示すことができる。
【０９２９】
Ｘエレメントは、ｓｏｕｒｃｅ  ｐａｃｋｅｔを示す情報に該当し得る。Ｓｏｕｒｃｅとｒｅｐａｉｒ  ｄａｔａのために互いに異なるＦＥＣ  ｐａｙｌｏａｄ  ＩＤフォーマットが用いられる場合、このエレメントの値が「１」なら、ｓｏｕｒｃｅ  ｄａｔａのためのＦＥＣ  ｐａｙｌｏａｄ  ＩＤフォーマットであることを示し、このエレメントの値が「０」なら、ｒｅｐａｉｒ  ｄａｔａのためのＦＥＣ  ｐａｙｌｏａｄ  ＩＤフォーマットであることを示す。又は、このエレメントの値が送信機から「０」へセッティングされた場合、受信機はこのエレメント又はこのパケットを無視し、処理しなくてもよい。
【０９３０】
Ｓエレメントは、Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ  ｆｌａｇに該当し得る。Ｓエレメントは、Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒエレメントの長さを示す。
【０９３１】
Ｏエレメントは、Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ  ｆｌａｇに該当し得る。Ｏエレメントは、Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒエレメントの長さを示すことができる。オブジェクトは一つのファイルを意味でき、ＴＯＩは各オブジェクトの識別情報であり、ＴＯＩが０であるファイルは、ファイルと関連したシグナリング情報を含むことができる。
【０９３２】
Ｈエレメントは、Ｈａｌｆ−ｗｏｒｄ  ｆｌａｇに該当し得る。Ｈエレメントは、ＴＳＩ及びＴＯＩフィールドの長さにｈａｌｆ−ｗｏｒｄ（１６ビット）を追加するか否かを示す。
【０９３３】
Ａエレメントは、Ｃｌｏｓｅ  Ｓｅｓｓｉｏｎ  ｆｌａｇに該当し得る。Ａエレメントは、セッションが終了した又は終了が迫ったことを示すことができる。
【０９３４】
Ｂエレメントは、Ｃｌｏｓｅ  Ｏｂｊｅｃｔ  ｆｌａｇに該当し得る。Ｂエレメントは、伝送中であるオブジェクトが終了した又は終了が迫ったことを示すことができる。
【０９３５】
ＨＤＲ＿ＬＥＮエレメントは、パケットのヘッダーの長さを示す。
【０９３６】
Ｃｏｄｅｐｏｉｎｔエレメントは、このパケットによって伝送されるペイロード（ｐａｙｌｏａｄ）のタイプを示す。ペイロードのタイプによって、追加的なペイロードヘッダーがペイロードデータのプレフィックス（ｐｒｅｆｉｘ）に挿入されてもよい。
【０９３７】
Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントは、ｌａｙｅｒ  ｎｕｍｂｅｒｓ、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ｎｕｍｂｅｒｓ、ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒｓなどのＣｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ情報を含むことができる。Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントは、必要なＣｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ関連情報を含むことができる。
【０９３８】
Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ（ＴＳＩ）エレメントは、セッションの固有識別子である。ＴＳＩエレメントは、特定伝送者（ｓｅｎｄｅｒ）からの全てのセッション（ｓｅｓｓｉｏｎ）のうちいずれか一つのセッションを示す。ＴＳＩエレメントは、ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎを識別する役割を担う。ＴＳＩエレメントの値は一つのトラックのために用いられてもよい。
【０９３９】
Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）エレメントは、オブジェクトの固有識別子である。ＴＯＩエレメントは、セッション内で、どのオブジェクトにこのパケットが属するかを示す。ＴＯＩエレメントの値は、一つのＩＳＯ ＢＭＦＦ  ｏｂｊｅｃｔデータのために用いられてもよい。ＴＯＩエレメントは、ＩＳＯ ＢＭＦＦファイルのＩＤとｃｈｕｎｋのＩＤを含むことができる。ＴＯＩエレメントは、ＩＳＯ ＢＭＦＦファイルのＩＤとｃｈｕｎｋのＩＤとの組合せをその値として有することができる。
【０９４０】
Ｔｙｐｅエレメントは、ボンオブジェクトを介して伝送されるデータの種類を識別することができる。例えば、Ｔｙｐｅエレメントは、ボンオブジェクトを介して伝送されるデータがシグナリングメッセージであることを示すことができる。
【０９４１】
Ｖｅｒｓｉｏｎエレメントは、ボンオブジェクトを介して伝送されるデータのバージョンを識別する。例えば、Ｖｅｒｓｉｏｎエレメントは、Ｔｙｐｅオブジェクトを用いて識別されたデータの構造及び／又は内容に変更があるかを識別する情報を含むことができる。
【０９４２】
Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎｓエレメントは、追加的なヘッダー情報を含むことができる。
【０９４３】
ＦＥＣ  ｐａｙｌｏａｄ  ＩＤエレメントは、ＦＥＣ  Ｐａｙｌｏａｄ識別子である。ＦＥＣ  ｐａｙｌｏａｄ  ＩＤエレメントは、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｂｌｏｃｋ又はｅｎｃｏｄｉｎｇ  ｓｙｍｂｏｌの識別情報を含む。ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤは、ファイルがＦＥＣエンコーディングされた場合の識別子を示す。例えば、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤは、ＦＬＵＴＥプロトコルファイルがＦＥＣエンコーディングされた場合、放送局又は放送サーバーがこれを区別するために割り当てることができる。
【０９４４】
Ｅｎｃｏｄｉｎｇ  Ｓｙｍｂｏｌｓエレメントは、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｂｌｏｃｋ又はｅｎｃｏｄｉｎｇ  ｓｙｍｂｏｌのデータを含むことができる。
【０９４５】
図９４は、本発明の一実施例に係る、ＴＯＩ構成ディスクリプション（ＴＯＩ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＤ）を示す図である。
【０９４６】
前述したように、ＴＯＩフィールドの一部を可変長さのシグナリングメッセージ関連情報の記述のために用いることができる。可変長さのＴＯＩフィールド内で、シグナリングメッセージ関連情報の記述のためにはＴＯＩフィールドの構成情報が別途に伝送されてもよい。一実施例として、図示された表のようなＴＯＩ構成ディスクリプションがＴＯＩフィールドの構成に関する情報を提供するために、送信及び／又は受信されてもよい。本実施例では、ＴＣＤ（ＴＯＩ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、一つの伝送セッションに該当する伝送パケットのＴＯＩフィールド構成情報を提供する。ＴＣＤは、シグナリングを伝送するセッションの内部、及び／又は外部手段を介して伝送されてもよい。ＴＣＤが、シグナリングを伝送するセッションの内部で伝送される場合、固有のＴＯＩ値、一例として０又は０ｘＦＦＦＦなどの値で識別し、共に伝送される他のシグナリングメッセージに先立って解釈されてもよい。ＴＣＤがシグナリングを伝送するセッションの外部で伝送される場合、ＦＩＣ、別途のＩＰデータグラム及び／又は他のＲＯＵＴＥセッションなどの手段を介して伝送され、当該セッションで伝達されるオブジェクトに先立って伝送されて各パケットに含まれたＴＯＩフィールドの構成情報を受信機であらかじめ把握できるように処理することができる。＠ｔｙｐｅＢｉｔｓフィールド以下のフィールドは、ＴＯＩ内の各フィールド長さを示し、ＴＯＩ開始ビットから順にそれぞれの長さに該当するフィールド情報が記述されることを知らせる。
【０９４７】
本発明の一実施例に係るＴＣＤは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ｄａｔａＶｅｒｓｉｏｎ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、＠ｔｙｐｅＢｉｔｓ情報、＠ｖｅｒｓｉｏｎＢｉｔｓ情報、＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報、＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報、＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報を含むことができる。
【０９４８】
＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＴＣＤのバージョンを識別する。＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＴＣＤのプロトコル又は構造に変更がある場合、これを識別する。
【０９４９】
＠ｄａｔａＶｅｒｓｉｏｎ情報はＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）のバージョンを識別する。＠ｄａｔａＶｅｒｓｉｏｎ情報は、ＴＣＤに含まれる内容が変更される場合、これを識別する。
【０９５０】
＠ｖａｌｉｄＦｒｏｍ情報は、ＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）の可用開始時点を示すことができる。受信機は、＠ｖａｌｉｄＦｒｏｍ情報を用いてＴＣＤの可用開始時点を認知でき、当該時点からＴＣＤの情報を用いることができる。
【０９５１】
＠ｅｘｐｉｒａｔｉｏｎ情報は、ＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）の可用完了時点を示すことができる。受信機は、＠ｅｘｐｉｒａｔｉｏｎ情報を用いてＴＣＤの可用完了時点を認知でき、ＴＣＤの情報の使用を終了させることができる。受信機は、＠ｅｘｐｉｒａｔｉｏｎ情報を用いて、ＴＣＤ情報を管理することができる。
【０９５２】
＠ｔｙｐｅＢｉｔｓ情報は、ＴＯＩフィールド内ｔｙｐｅフィールドの長さを示す。＠ｔｙｐｅＢｉｔｓ情報は、ｔｙｐｅフィールドの長さをビットで表現することができる。
【０９５３】
＠ｖｅｒｓｉｏｎＢｉｔｓ情報は、ＴＯＩフィールド内ｖｅｒｓｉｏｎフィールドの長さを示す。＠ｖｅｒｓｉｏｎＢｉｔｓ情報は、ｖｅｒｓｉｏｎフィールドの長さをビットで表現することができる。
【０９５４】
＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報は、ＴＯＩフィールド内ｉｎｓｔａｎｃｅＩＤフィールドの長さをビット数で示すことができる。
【０９５５】
＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報は、ＴＯＩフィールド内ｖａｌｉｄＦｒｏｍフィールドの長さをビット数で示すことができる。
【０９５６】
＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報は、ＴＯＩフィールド内ｅｘｐｉｒａｔｉｏｎフィールドの長さをビット数で示すことができる。
【０９５７】
＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報は、ＴＯＩフィールド内ｐａｙｌｏａｄＦｏｒｍａｔフィールドの長さをビット数で示すことができる。
【０９５８】
図９５は、本発明の一実施例に係る、伝送パケットのペイロード（Ｐａｙｌｏａｄ）フォーマット（Ｆｏｒｍａｔ）エレメントを示す図である。
【０９５９】
本発明の一実施例によれば、伝送パケットのペイロードを介して、シグナリングメッセージを伝送することができる。そのために、伝送パケットは、図示のようなペイロードフォーマットエレメントを含むことができる。伝送パケットは、放送データを含むオブジェクトを伝送するパケットに該当する。本発明の伝送パケットは、当該パケットが処理されるプロトコルによって、その名称が変更されてもよい。例えば、ＲＯＵＴＥを介してパケットが処理されると、ＲＯＵＴＥパケットと呼ぶことができる。
【０９６０】
ペイロードフォーマットエレメントは、前述したようにＬＳＩＤに含まれてもよい。
【０９６１】
本発明の伝送パケットのペイロードフォーマットエレメントは、＠ｃｏｄｅＰｏｉｎｔ情報、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報、＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報、＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報、＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報及び／又はＴＣＩＤ（ＴＯＩ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）を含むことができる。
【０９６２】
＠ｃｏｄｅＰｏｉｎｔ情報は、このペイロードのために用いられるＣｏｄｅＰｏｉｎｔを定義する。本情報は、前述したＣＰエレメントと同じ役割を担当したり、同じ値を有することができる。
【０９６３】
＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は、データの伝送のためのオブジェクトのペイロードのフォーマットを識別する。例えば、本情報は、オブジェクトがシグナリングメッセージを伝送したり、ファイルを伝送したり、Ｅｎｔｉｔｙを伝送したり、Ｐａｃｋａｇｅを伝送したり、又は初期化セグメントを含むメタデータを伝送していることを示すことができる。
【０９６４】
＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報は、フラグメンテーション（Ｆｒａｇｍｅｎｔａｔｉｏｎ）のタイプを識別する。
【０９６５】
＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報は、オブジェクトの伝送順序を識別する。例えば、本情報は、現在ペイロードを介して伝送されるオブジェクトの順序を識別するために用いられてもよい。
【０９６６】
＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報は、ソースＦＥＣペイロードＩＤ（Ｓｏｕｒｃｅ  ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤ）のフォーマットを定義することができる。
【０９６７】
ＴＣＩＤは、ＴＯＩフィールドの一部を可変長さのシグナリングメッセージ関連情報の記述のために用いる場合、ＴＯＩフィールドの構成情報を含むことができる。
【０９６８】
図９６は、本発明の一実施例に係る、ＴＯＩ構成インスタンスディスクリプション（ＴＯＩ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ；ＴＣＩＤ）を示す図である。
【０９６９】
ＴＯＩフィールドの一部を可変長さのシグナリングメッセージ関連情報の記述のために使用し、一つの伝送セッション内でＴＯＩフィールドの構成が動的に変わってもよい。
【０９７０】
可変長さのＴＯＩフィールド内シグナリングメッセージ関連情報の記述のためにはＴＯＩフィールド構成情報が別途に伝送されてもよい、このようなＴＯＩフィールド構成情報は、図示された形態で伝送されてもよい。
【０９７１】
本実施例では、ＴＣＩＤは、一つのｃｏｄｅｐｏｉｎｔ値にマッピングされるパケットのグループに該当する伝送パケットのＴＯＩフィールド構成情報を提供する。ＴＣＩＤは、ＬＳＩＤのＳｏｕｒｃｅＦｌｏｗ内ＰａｙｌｏａｄＦｏｒｍａｔに含まれて伝送されてもよい。ＴＣＩＤの内部フィールドは、前述したＴＣＤにおけると同一であってもよく、ＰａｙｌｏａｄＦｏｒｍａｔに併せて含まれた＠ｃｏｄｅＰｏｉｎｔと同じ値のＣＰ値を有するパケットのＴＯＩ構成を示すことができる。ＴＯＩの構成方法は、前述したＴＣＤにおける方法と同一であってもよい。
【０９７２】
本発明の一実施例に係る、ＴＣＩＤは、＠ｔｙｐｅＢｉｔｓ情報、＠ｖｅｒｓｉｏｎＢｉｔｓ情報、＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報、＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報、＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報を含むことができる。本情報に関する説明は、同一名称を有する前述した情報に関する説明に代える。
【０９７３】
図９７は、本発明の一実施例に係る、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）のペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。
【０９７４】
本発明では、サービスをスキャンしたり、サービスの取得のための情報を含むシグナリングデータをＦＩＣと命名したが、その名称に限定されず、サービス層（又は、レベル）の下位層で、より効果的に放送サービスを取得するための情報を提供するシグナリングデータについて説明する。一例として、このようなシグナリングデータは、サービスリストテーブル、又はサービスリストエレメントなどの別の名称としてもよい。
【０９７５】
また、本発明では、説明の便宜のために、シグナリングデータの構造をｂｉｎａｒｙ形態のテーブルとしているが、当該テーブルに属する同一又は類似の情報は、ＸＭＬ形態で具現されてもよい。
【０９７６】
本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓ情報、ｐａｒｔｉｔｉｏｎ＿ｉｄ情報、ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ＩＤ情報、ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報、ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報、及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントを含むことができる。
【０９７７】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、ＦＩＣの構造のバージョンを識別する情報である。
【０９７８】
ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ情報は、放送ストリームを識別する情報である。全体放送ストリームを識別する情報に該当し得る。
【０９７９】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓ情報は、放送ストリーム内におけるパーティション（ｐａｒｔｉｔｉｏｎ）の個数を示す情報である。一つの放送ストリームは、一つ以上のパーティションに分けられてもよく、それぞれのパーティションは、一つの放送会社（又は、放送ソース）によって用いられる一つ以上のデータパイプ（ｄａｔａ  ｐｉｐｅ）を含むことができる。
【０９８０】
ｐａｒｔｉｔｉｏｎ＿ｉｄ情報は、パーティションを識別する情報である。
【０９８１】
ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、パーティションの構造のバージョンを識別する情報である。
【０９８２】
ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報は、パーティションを介して一つ以上のコンポーネントが伝送される放送サービスの個数を示す。
【０９８３】
ｓｅｒｖｉｃｅ＿ｉｄ情報は、サービス（又は、放送サービス）を識別する情報である。
【０９８４】
ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、ＦＩＣによってシグナリングされるサービスのためのサービスエントリー（ｅｎｔｒｙ）に変更がある場合、この変更を識別する情報である。又は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、サービスシグナリングチャネル（又は、サービスレベルシグナリング）に含まれる、サービスのためのシグナリングテーブルに変更がある場合、これを識別する情報である。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、当該変更がある度にその値を増加させ、変更があることを示すことができる。
【０９８５】
ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報は、サービスのためのチャネル番号を示す。
【０９８６】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、サービスのカテゴリーを示す。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスがＡ／Ｖサービス、オーディオサービス、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）、Ａｐｐ  ｂａｓｅｄ  ｓｅｒｖｉｃｅ及び／又はＣｏＤ（Ｃｏｎｔｅｎｔ  ｏｎ  Ｄｅｍａｎｄ）であることを示すことができる。
【０９８７】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報の長さを示す。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が存在しない場合、「０」の値を有することができる。
【０９８８】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報は、サービスのＳｈｏｒｔ  Ｎａｍｅを示す。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が示す各文字は、ＵＴＦ−８によってエンコーディングされてもよい。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が奇数のバイト長を有する場合、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報によって識別されるペアカウント当たりのバイトペアの最後の二番目のバイトは、０ｘ００値を有することができる。（Ｔｈｅ  ｓｈｏｒｔ  ｎａｍｅ  ｏｆ  ｔｈｅ  Ｓｅｒｖｉｃｅ，ｅａｃｈ  ｃｈａｒａｃｔｅｒ  ｏｆ  ｗｈｉｃｈ  ｓｈａｌｌ  ｂｅ  ｅｎｃｏｄｅｄ  ｐｅｒ  ＵＴＦ−８［］。Ｗｈｅｎ  ｔｈｅｒｅ  ｉｓ  ａｎ  ｏｄｄ  ｎｕｍｂｅｒ  ｏｆ  ｂｙｔｅｓ  ｉｎ  ｔｈｅ  ｓｈｏｒｔ  ｎａｍｅ，ｔｈｅ  ｓｅｃｏｎｄ  ｂｙｔｅ  ｏｆ  ｔｈｅ  ｌａｓｔ  ｏｆ  ｔｈｅ  ｂｙｔｅ  ｐａｉｒ  ｐｅｒ  ｔｈｅ  ｐａｉｒ  ｃｏｕｎｔ  ｉｎｄｉｃａｔｅｄ  ｂｙ  ｔｈｅ  ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ  ｆｉｅｌｄ  ｓｈａｌｌ  ｃｏｎｔａｉｎ０ｘ００。）
【０９８９】
ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、サービスの状態を示す。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスがａｃｔｉｖｅ、ｉｎａｃｔｉｖｅ、ｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ、及び／又はｓｈｏｗｎ状態であることを示すことができる。
【０９９０】
ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報は、放送サービス又は放送コンテンツの表出（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）が、現在パーティションだけで可能か、現在パーティションだけでは不可能であるが、現在パーティションが必要か、他のパーティションを必要とするか、他の放送ストリームを必要とするかを識別する。
【０９９１】
ｓｐ＿ｉｎｄｉｃａｔｏｒ情報は、サービス保護が適用されたかどうかを示す。ｓｐ＿ｉｎｄｉｃａｔｏｒ情報は、有意義な表出のために必要な、放送サービスの一つ以上のコンポーネントに対して、ｐｒｏｔｅｃｔｉｏｎがされたか否かを識別する。
【０９９２】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報は、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報及び／又はＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報が示すＩＰアドレスが、ＩＰｖ４アドレスか又はＩＰｖ６アドレスかを識別する。
【０９９３】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報は、サービスのためにＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報が存在するか否かを識別する情報である。
【０９９４】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報の値が「１」に設定された場合には存在するが、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報の値が「０」に設定された場合には存在しない。ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、サービスのためのシグナリング情報を伝送するＩＰデータグラム（又は、データユニット）のソースＩＰアドレスを示す。ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＩＰｖ６のアドレスが用いられる場合、１２８ビットを有することができる。
【０９９５】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、サービスのためのシグナリング情報を伝送するＩＰデータグラム（又は、データユニット）のデスティネーションＩＰアドレスを示す。ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＩＰｖ６のアドレスが用いられる場合、１２８ビットを有することができる。
【０９９６】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ情報は、サービスのためのシグナリング情報を伝送するＵＤＰ／ＩＰストリームのためのデスティネーションＵＤＰポート番号を示す。
【０９９７】
ＳＳＣ＿ＴＳＩ情報は、サービスのためのシグナリング情報（又は、シグナリングテーブル）を伝送するＬＣＴチャネルのＴＳＩ（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）を示す。
【０９９８】
ＳＳＣ＿ＤＰ＿ＩＤ情報は、サービスのためのシグナリング情報（又は、シグナリングテーブル）を含むデータパイプ（ＤＰ；Ｄａｔａ  Ｐｉｐｅ）を識別する情報である。シグナリング情報を伝送するデータパイプは、現在パーティション又は放送ストリーム内で最もロバスト（ｒｏｂｕｓｔ）なデータパイプに該当し得る。
【０９９９】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報は、パーティションのために定義されるパーティションレベルディスクリプタの個数を示す。
【１０００】
ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは、一つ以上のパーティションレベルディスクリプタを含む。パーティションレベルディスクリプタは、受信機でパーティションに接近したり、パーティションを取得したり、パーティションを利用するために必要な情報を含むことができる。
【１００１】
ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報は、ＦＩＣのために定義されるＦＩＣレベルディスクリプタの個数を示す。
【１００２】
ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは、一つ以上のＦＩＣレベルディスクリプタを含む。ＦＩＣレベルディスクリプタは、ＦＩＣのための追加のシグナリング情報を含むことができる。
【１００３】
図９８は、本発明の他の実施例に係る、ＦＩＣのペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。
【１００４】
本発明の他の実施例に係るＦＩＣのペイロードは、前述した実施例におけるＦＩＣのペイロードにＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報、ＳＳＣ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、及び／又はＳＳＣ＿ＵＲＬ＿ｄａｔａ情報をさらに含むことができる。
【１００５】
ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、サービスに関連するシグナリング情報（例えば、サービスシグナリングチャネル又はサービスレベルシグナリング）が伝達される経路を識別する情報である。ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、サービスレベルシグナリングのデータがブロードバンド（インターネット網）を介して伝送されるか否かを識別することができる。一例として、ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、その値が０ｘ０１を有するとき、放送網を介してサービスレベルシグナリングが伝送されることを示すことができる。ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、その値が０ｘ０２を有するとき、インターネット網を介してサービスレベルシグナリングが伝送されることを示すことができる。
【１００６】
ＳＳＣ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、ＳＳＣ＿ＵＲＬ＿ｄａｔａ情報の長さを示す。
【１００７】
ＳＳＣ＿ＵＲＬ＿ｄａｔａ情報は、サービスに関連するシグナリング情報を提供するサーバー又は位置のＵＲＬを示す。
【１００８】
本実施例で説明していない他の情報に関する説明は、前述した説明に代える。
【１００９】
図９９は、本発明の他の実施例に係る、サービスレベルシグナリングのシンタックス（ｓｙｎｔａｘ）を示す図である。
【１０１０】
受信機で、視聴者の所望する放送サービス及び／又は放送コンテンツを受信するために必要な情報を、サービスレベルシグナリングと命名することができる。サービスレベルシグナリングは、放送サービス及び放送サービスに含まれるコンポーネントに対する属性を説明する情報を含む。
【１０１１】
本発明の他の実施例に係る、サービスレベルシグナリングデータは、シグナリングメッセージヘッダー（ｈｅａｄｅｒ）及び／又はサービスシグナリングメッセージを含むことができる。
【１０１２】
本発明の他の実施例に係る、サービスレベルシグナリングデータは、＠ｓｅｒｖｉｃｅ＿ｉｄ情報、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、＠ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報、＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報、ＲＯＵＴＥ  Ｓｅｓｓｉｏｎエレメント、＠ｓｏｕｒｃｅＩＰＡｄｄｒ情報、＠ｄｅｓｔＩＰＡｄｄｒ情報、＠ｄｅｓｔＵＤＰＰｏｒｔ情報、＠ＬＳＩＤ＿ＤＰ情報、Ｔａｒｇｅｔｉｎｇエレメント、Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙエレメント、Ｒｉｇｈｔ  Ｉｓｓｕｅｒ  Ｓｅｒｖｉｃｅエレメント、Ｃｕｒｒｅｎｔ  Ｐｒｏｇｒａｍエレメント、Ｏｒｉｇｉｎａｌ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎエレメント、Ｃｏｎｔｅｎｔ  Ｌａｂｅｌｉｎｇエレメント、Ｇｅｎｒｅエレメント、Ｃａｐｔｉｏｎエレメント、及び／又はＰｒｏｔｅｃｔｉｏｎエレメントを含むことができる。
【１０１３】
＠ｓｅｒｖｉｃｅ＿ｉｄ情報は、放送サービスを識別する情報である。
【１０１４】
＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスのカテゴリーを識別する情報である。例えば、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスが、オーディオサービス、実時間放送サービス、非実時間放送サービス、ｌｉｎｅａｒ放送サービス、ａｐｐ−ｂａｓｅｄ放送サービス或いはサービスガイドであることを識別することができる。
【１０１５】
＠ｓｅｒｖｉｃｅ＿ｎａｍｅ情報は、放送サービスの名称を示す。
【１０１６】
＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報は、放送サービスを送信するチャネル番号を示す。このチャネル番号は、論理的／物理的チャネル番号に該当し得る。場合によって、このチャネル番号は、サービスレベルシグナリングのデータを伝送する論理的伝送経路又は伝送ユニットを識別する情報として用いられてもよい。
【１０１７】
＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスの状態を示す。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスがアクティブ（ａｃｔｉｖｅ）状態か、インアクティブ（ｉｎａｃｔｉｖｅ）状態かを識別する情報を含むことができる。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスがヒドン（ｈｉｄｄｅｎ）状態か否かを識別する情報を含むことができる。
【１０１８】
＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報は、放送サービスのためのデータ又はコンポーネントがどのように分配されて伝送されるかを示す情報である。
【１０１９】
＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報は、放送サービス又は放送サービスに含まれる少なくとも一つのコンポーネントに対してサービスプロテクション（ｐｒｏｔｅｃｔｉｏｎ）が適用されたか否かを識別する情報である。＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報は、放送サービスの有意義な表出のためのデータ単位又はコンポーネントにサービスプロテクションが適用されたか否かを識別する情報に該当し得る。
【１０２０】
ＲＯＵＴＥ  Ｓｅｓｓｉｏｎエレメントは、放送サービス又は放送サービスに含まれるコンポーネントを伝送するＲＯＵＴＥセッションに関する情報を含むエレメントである。
【１０２１】
＠ｓｏｕｒｃｅＩＰＡｄｄｒ情報は、ＲＯＵＴＥパケットを伝送するＩＰデータグラム（或いは、データユニット）のソース（ｓｏｕｒｃｅ）ＩＰアドレスを示す。
【１０２２】
＠ｄｅｓｔＩＰＡｄｄｒ情報は、ＲＯＵＴＥパケットを伝送するＩＰデータグラム（或いは、データユニット）のデスティネーション（ｄｅｓｔｉｎａｔｉｏｎ）ＩＰアドレスを示す。
【１０２３】
＠ｄｅｓｔＵＤＰＰｏｒｔ情報は、ＲＯＵＴＥパケットを伝送するＩＰデータグラム（或いは、データユニット）のデスティネーションポート（ｐｏｒｔ）番号を示す。
【１０２４】
＠ＬＳＩＤ＿ＤＰ情報は、ＲＯＵＴＥセッションと関連した伝送パラメータ及び／又はＲＯＵＴＥセッション内の下位セッションを説明する情報（例えば、ＬＳＩＤ）を伝達するデータパイプを識別する情報である。
【１０２５】
Ｔａｒｇｅｔｉｎｇエレメントは、個人化された放送サービス（ターゲッティング放送）の提供のための情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。
【１０２６】
Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙエレメントは、放送サービスに対する視聴等級に関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。Ｒｉｇｈｔ  Ｉｓｓｕｅｒ  Ｓｅｒｖｉｃｅエレメントは、放送サービスを適切に消費するための権限に関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。
【１０２７】
Ｃｕｒｒｅｎｔ  Ｐｒｏｇｒａｍエレメントは、現在放送プログラムに関する情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。
【１０２８】
Ｏｒｉｇｉｎａｌ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎエレメントは、現在放送サービスに関連した元来のサービスを識別することと関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。
【１０２９】
Ｃｏｎｔｅｎｔ  Ｌａｂｅｌｉｎｇエレメントは、コンテンツラベリング（ｃｏｎｔｅｎｔ  ｌａｂｅｌｉｎｇ）に関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。Ｇｅｎｒｅエレメントは、放送サービスのジャンルを区別するための情報を含む情報である。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。
【１０３０】
Ｃａｐｔｉｏｎエレメントは、放送サービスのｃｌｏｓｅｄ  ｃａｐｔｉｏｎ／ｓｕｂｔｉｔｌｅに関する情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。
【１０３１】
Ｐｒｏｔｅｃｔｉｏｎエレメントは、放送サービスに対するプロテクション（ｐｒｏｔｅｃｔｉｏｎ）関連情報を含むエレメントである。Ｐｒｏｔｅｃｔｉｏｎエレメントは、前述した＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報が、放送サービス又は放送コンポーネントに対してプロテクションが適用された場合、このプロテクションに関連した細部情報を提供することができる。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。
【１０３２】
図１００は、本発明の他の実施例に係る、コンポーネントマッピングディスクリプション（ｃｏｍｐｏｎｅｎｔ  ｍａｐｐｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ）を示す図である。
【１０３３】
本発明の他の実施例に係る、コンポーネントマッピングディスクリプションは、前述した実施例に係るコンポーネントマッピングディスクリプションに含まれる情報又はエレメントに加えて、＠ｐａｒｔｉｔｉｏｎＩＤ情報をさらに含むことができる。
【１０３４】
＠ｐａｒｔｉｔｉｏｎＩＤ情報は、放送ストリーム上で放送局を示すｐａｒｔｉｔｉｏｎを識別する情報である。＠ｐａｒｔｉｔｉｏｎＩＤ情報は、放送コンポーネントを伝送する送信元を識別する情報として用いられてもよい。
【１０３５】
コンポーネントマッピングディスクリプションに含まれる他の情報又はエレメントに関する説明は、同一名称を有する情報又はエレメントについて前述した説明に代える。
【１０３６】
図１０１は、本発明の他の実施例に係る、ＵＲＬシグナリングディスクリプション（ＵＲＬ  ｓｉｇｎａｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ）のシンタックス（ｓｙｎｔａｘ）を示す図である。
【１０３７】
前述したように、放送サービスを説明するシグナリング情報は、放送網だけでなく、ブロードバンド網を介して伝送されてもよい。放送サービスを説明するシグナリング情報がブロードバンド網を介して伝送される場合、受信機はＵＲＬシグナリングディスクリプションを介して、当該シグナリング情報を取得することができる。
【１０３８】
本発明の他の実施例に係る、ＵＲＬシグナリングディスクリプションは、＠ｓｅｒｖｉｃｅ＿ｉｄ情報、＠ｓｍｔＵＲＬ情報、＠ｍｐｄＵＲＬ情報、＠ｃｍｔＵＲＬ情報、＠ａｓｔＵＲＬ情報、＠ｇａｔＵＲＬ情報、及び／又は＠ｅａｔＵＲＬ情報を含むことができる。
【１０３９】
＠ｓｅｒｖｉｃｅ＿ｉｄ情報は、サービスを識別する情報である。
【１０４０】
＠ｓｍｔＵＲＬ情報は、ブロードバンドでＳＭＴ（Ｓｅｒｖｉｃｅ  Ｍａｐ  Ｔａｂｌｅ）が伝送される場合、ＳＭＴを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０４１】
＠ｍｐｄＵＲＬ情報は、ブロードバンドでＭＰＤが伝送される場合、ＭＰＤを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０４２】
＠ｃｍｔＵＲＬ情報は、ブロードバンドでＣＭＴ（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）が伝送される場合、ＣＭＴを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０４３】
＠ａｓｔＵＲＬ情報は、ブロードバンドでＡＳＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｉｇｎａｌｉｎｇ  Ｔａｌｂｅ）が伝送される場合、ＡＳＴを提供するサーバー又は位置のＵＲＬを示す情報である。
【１０４４】
＠ｇａｔＵＲＬ情報は、ブロードバンドでＧＡＴ（Ｇｕｉｄｅ  Ａｃｃｅｓｓ  Ｔａｂｌｅ）が伝送される場合、ＧＡＴを提供するサーバー又は位置のＵＲＬを示す情報である。ＧＡＴは、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）のブートストラップ（ｂｏｏｔｓｔｒａｐ）のための情報を含むシグナリングメッセージに該当し得る。すなわち、ＧＡＴは、受信機がＥＳＧに接近するために必要な情報を含むシグナリングメッセージに該当し得る。
【１０４５】
＠ｅａｔＵＲＬ情報は、ブロードバンドでＥＡＴ（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔ  Ｔａｂｌｅ）が伝送される場合、ＥＡＴを提供するサーバー又は位置のＵＲＬを示す情報である。ＥＡＴは、非常警報関連情報と非常警報メッセージを含むシグナリングメッセージに該当し得る。
【１０４６】
図１０２は、本発明の他の実施例に係る、ＳｏｕｒｃｅＦｌｏｗエレメントを示す図である。
【１０４７】
放送サービスのデータは、ＲＯＵＴＥセッションを介して、オブジェクト（Ｏｂｊｅｃｔ）単位で伝送されてもよい。それぞれのオブジェクトは個別的に復元されてもよい。一つのセッション内で、オブジェクトを伝送するためにｓｏｕｒｃｅプロトコルを定義することができ、ｓｏｕｒｃｅプロトコル内におけるｓｏｕｒｃｅ（ｏｂｊｅｃｔ）の伝達に関連した情報を含むＳｏｕｒｃｅＦｌｏｗエレメントを定義することができる。
【１０４８】
本発明の他の実施例に係るＳｏｕｒｃｅＦｌｏｗエレメントは、前述したＳｏｕｒｃｅＦｌｏｗエレメントに含まれる情報／属性／エレメントの他、＠ｌｏｃａｔｉｏｎ情報をさらに含むことができる。
【１０４９】
＠ｌｏｃａｔｉｏｎ情報は、ｓｏｕｒｃｅ  ｆｌｏｗのデータを伝送する位置又はデータユニットを示す情報である。＠ｌｏｃａｔｉｏｎ情報は、放送ストリーム内でデータパイプを識別し、受信機は。当該データパイプを介して、ｓｏｕｒｃｅ  ｆｌｏｗのデータが伝送されることが把握できる。
【１０５０】
ＳｏｕｒｃｅＦｌｏｗエレメントに含まれる他の情報／属性／エレメントに関する説明は、前述したＳｏｕｒｃｅＦｌｏｗエレメントに関する説明に代える。
【１０５１】
図１０３は、本発明の他の実施例に係る、シグナリング情報を放送網を介して取得する過程を示す図である。
【１０５２】
受信機は、ＦＩＣに含まれるサービスを識別する情報を用いて、受信機の所望の放送サービスと関連したサービスシグナリングチャネルのデータが伝送される位置に接近することができる。
【１０５３】
受信機は、ＦＩＣから、サービスシグナリングチャネルのデータを伝送するＩＰデータグラムソースＩＰアドレス、デスティネーションＩＰアドレス及び／又はＵＤＰポート番号に関する情報を取得する。
【１０５４】
受信機はＦＩＣから、サービスシグナリングチャネルのデータを含むデータパイプを識別する情報を取得する。受信機は、当該情報を用いて、サービスシグナリングチャネルのデータが伝送されるデータパイプに接近することができる。
【１０５５】
受信機は、ＦＩＣに含まれた、サービスシグナリングチャネルのデータを伝送するＬＣＴセッションを識別する情報を用いて、当該ＬＣＴセッションに接近することができる。又は、サービスシグナリングチャネルのデータを伝送するＬＣＴセッションは、特定ＴＳＩを有するＬＣＴセッションに固定されてもよく、この場合、受信機は別途の情報無しにも、サービスシグナリングチャネルのデータを得るために、特定ＴＳＩを有するＬＣＴセッションに接近することができる。受信機は、当該位置に接近して、サービスシグナリングチャネルのデータを取得することができる。
【１０５６】
受信機は、前述したＬＳＩＤを伝送するＬＣＴセッションに接近することができる。この場合、ＬＳＩＤを伝送するＬＣＴセッションのＴＳＩは固定されていていもよく、受信機は、当該ＴＳＩを有するＬＣＴセッションに接近し、ＬＳＩＤを取得することができる。受信機は、ＬＳＩＤの情報を用いて、放送サービスに含まれるコンポーネントを取得することができる。
【１０５７】
図１０４は、本発明の他の実施例に係る、シグナリング情報を放送網及びブロードバンド網を介して取得する過程を示す図である。
【１０５８】
受信機は、ＦＩＣに含まれるサービスを識別する情報を用いて、受信機の所望する放送サービスに関連したサービスシグナリングチャネルのデータが伝送される位置に接近することができる。
【１０５９】
受信機はＦＩＣから、サービスシグナリングチャネルのデータを伝送するＩＰデータグラムソースＩＰアドレス、デスティネーションＩＰアドレス及び／又はＵＤＰポート番号に関する情報を取得する。
【１０６０】
受信機はＦＩＣから、サービスシグナリングチャネルのデータを含むデータパイプを識別する情報を取得する。受信機は、当該情報を用いて、サービスシグナリングチャネルのデータが伝送されるデータパイプに接近することができる。
【１０６１】
受信機は、サービスシグナリングチャネルのデータに接近して、前述したＵＲＬシグナリングテーブル又はＵＲＬシグナリングディスクリプションを取得する。受信機は、ＵＲＬシグナリングテーブルに含まれる情報を用いて、サービスレベルシグナリングを提供するサーバー又は位置に接近し、ブロードバンド網を介してサービスレベルシグナリングを取得することができる。
【１０６２】
図１０５は、本発明の他の実施例に係る、シグナリング情報をブロードバンド網を介して取得する過程を示す図である。
【１０６３】
受信機は、ＦＩＣに含まれる、サービスシグナリングチャネルの伝送タイプを識別する情報が、サービスシグナリングチャネルのデータがブロードバンド網を介して伝送されることを示す場合、ＦＩＣ内でサービスシグナリングチャネルのデータを提供するサーバー又は位置に対するＵＲＬ情報を取得する。この場合、ＵＲＬ情報は、サービスシグナリングチャネルのデータ全体を提供する一つのサーバー又は位置に対するＵＲＬを示したり、サービスシグナリングチャネルに含まれ得るそれぞれのシグナリング構造（ＳＭＴ、ＭＰＤ、ＣＭＴなど）を提供するそれぞれのサーバー又は位置のＵＲＬを示すことができる。
【１０６４】
受信機は、当該ＵＲＬ情報が示すサーバー又は位置に接近し、ブロードバンド網でサービスシグナリングチャネルのデータを取得する。
【１０６５】
図１０６は、本発明の他の実施例に係る、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）を放送網を介して取得する過程を示す図である。
【１０６６】
受信機は、ＦＩＣに含まれるサービスのカテゴリーを識別する情報から、放送サービスがＥＳＧに該当することを認識し、当該サービスに対するサービスシグナリングチャネルのデータを伝送するデータパイプを識別する情報を取得することができる。
【１０６７】
受信機は、識別されたデータパイプに接近して、当該データパイプで伝送されるＥＳＧのデータを取得することができる。
【１０６８】
このような過程を用いて、ＥＳＧを放送サービスとして取扱うが、一般的な放送サービスに接近するために複雑なシグナリング構造を解釈しなくて済み、ＥＳＧの取得をより効率的に行うことができる。
【１０６９】
図１０７は、本発明の他の実施例に係る、放送サービスのビデオセグメント及びオーディオセグメントを放送網を介して取得する過程を示す図である。
【１０７０】
受信機は、サービスシグナリングチャネルのデータを取得し、サービスシグナリングチャネルのデータに含まれる、放送サービスのコンポーネントを説明する情報を含むシグナリング構造（例えば、ＣＭＴ）を取得する。
【１０７１】
当該シグナリング構造から、受信機は、放送サービスのビデオコンポーネントを伝送するデータパイプを識別する情報を取得し、当該情報を用いて、データパイプに接近する。受信機は、当該データパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を取得する。
【１０７２】
受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのビデオコンポーネントを伝送するＬＣＴセッションに接近して、ビデオコンポーネントを取得する。
【１０７３】
受信機は、放送サービスのオーディオコンポーネントを伝送するデータパイプを識別する情報を取得し、当該情報を用いて、データパイプに接近する。受信機は、当該データパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を取得する。
【１０７４】
受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのオーディオコンポーネントを伝送するＬＣＴセッションに接近して、オーディオコンポーネントを取得する。
【１０７５】
本発明によれば、前述したシグナリング構造を用いて、放送サービスに含まれるそれぞれのコンポーネントがそれぞれの伝送経路を介して伝送される場合にも、当該コンポーネントを効率的に探して取得できる効果がある。また、送信端では、余裕がある領域を介して、自由に放送サービスのコンポーネントを伝送することができ、したがって、より多い放送データを効率的に伝送できるという効果がある。
【１０７６】
図１０８は、本発明の他の実施例に係る、放送サービスのビデオセグメントは放送網を介して取得し、放送サービスのオーディオセグメントはブロードバンド網を介して取得する過程を示す図である。
【１０７７】
受信機は、サービスシグナリングチャネルのデータを取得し、サービスシグナリングチャネルのデータに含まれる、放送サービスのコンポーネントを説明する情報を含むシグナリング構造（例えば、ＣＭＴ）を取得する。
【１０７８】
当該シグナリング構造から、受信機は、放送サービスのビデオコンポーネントを伝送するデータパイプを識別する情報を取得し、当該情報を用いて、データパイプに接近する。受信機は、当該データパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を取得する。
【１０７９】
受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのビデオコンポーネントを伝送するＬＣＴセッションに接近して、ビデオコンポーネントを取得する。
【１０８０】
一方、受信機は、放送サービスのコンポーネントを説明する情報を含むシグナリング構造から、オーディオコンポーネントがブロードバンドで伝送されることを認識し、当該オーディオコンポーネントを伝送するサーバー又は位置のアドレスを取得する。又は、受信機は、ＭＰＤを用いて、当該オーディオコンポーネントのセグメントを提供するアドレスを取得し、当該アドレスから、オーディオコンポーネントのセグメントを取得する。
【１０８１】
前述したシグナリング構造を用いて、本発明によれば、異種網を介して、一つの放送サービスに属するコンポーネントがそれぞれ伝送される場合にも、当該放送サービスのためのコンポーネントに効率的に接近できるという効果がある。
【１０８２】
図１０９は、本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。
【１０８３】
本発明の一実施例は、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅの伝送及び／又はシグナリング方案を提供することができる。本発明の一実施例に係るｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅは、次世代放送システムで伝送されるコンテンツ及びサービスを受信機で同期化して消費できるようにする基準時間を提供することができる。
【１０８４】
本発明の一実施例に係るｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅは、連続的で周期的なｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値を含むことができる。ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅは、シグナリングメッセージ及び／又は独立したストリームの形態で伝送されてもよい。ここで、上述したシグナリングメッセージは、シグナリング情報と同一であってもよく、上述したシグナリングメッセージは、Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ（ＦＩＣ）、Ｓｅｒｖｉｃｅ  Ｍａｐ  Ｔａｂｌｅ（ＳＭＴ）などを含むことができる。ここで、上述したＦＩＣは、Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ（ＳＬＴ）と同一であってもよく、ＳＭＴは、Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＵＳＤ）と同一であってもよい。
【１０８５】
本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅが独立したストリームの形態で伝送される場合、受信機がｃｌｏｃｋ  ｒｅｆｅｒｎｃｅに接近するための情報を提供することができる。後述する、本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅがシグナリングメッセージを介して直接伝送される場合、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値を提供することができる。
【１０８６】
本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅは、フィジカルレイヤに含まれて伝送されてもよく、ｐｈｙｓｉｃａｌ  ｆｒａｍｅのｐｒｅａｍｂｌｅ及び／又はｂａｓｅ  ＰＬＰ部分に含まれて伝送されてもよい。ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅは、送信機と受信機の時間を同期化するために必要な情報であり、エラーを減らすために比較的剛健性の高いフィジカルレイヤに含まれてもよい。
【１０８７】
本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｂｉｎａｒｙ  ｆｏｒｍａｔ、ＸＭＬなどの様々な形式で表現されてもよい。本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、シグナリングメッセージ内の様々な位置に存在してもよい。ここで、上述したシグナリングメッセージは、ローレベルシグナリングメッセージ（ｌｏｗ  ｌｅｖｅｌ  ｓｉｇｎａｌｉｎｇ）、サービスレベルシグナリングメッセージ（ｓｅｒｖｉｃｅ  ｌｅｖｅｌ  ｓｉｇｎａｌｉｎｇ）を含むことができる。ここで、上述したローレベルシグナリングメッセージは、ＳＬＴ、ＲＲＴ（Ｒａｔｉｎｇ  Ｒｅｇｉｏｎ  Ｔａｂｌｅ）などを含むことができ、上述したサービスレベルシグナリングメッセージは、ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）などを含むことができる。ここで、上述したＳＬＴは、ＦＩＣ及び／又はＰＡＴと同一であってもよく、上述したＵＳＢＤ／ＵＳＤはＳＭＴと同一であってもよい。
【１０８８】
本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＴＳＩ＿ｆｌａｇフィールド、ＤＰ＿ＩＤ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＴＳＩ＿ｆｌａｇフィールド、ＤＰ＿ＩＤ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＴＳＩフィールド及び／又はＤＰ＿ＩＤフィールドを含むことができる。
【１０８９】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、固有値が割り当てられることによって当該ｄｅｓｃｒｉｐｔｏｒがｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒであることを識別することができる。
【１０９０】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、当該ｄｅｓｃｒｉｐｔｏｒの長さをバイト数で示すことができる。
【１０９１】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰ  ａｄｄｒｅｓｓの形式を示すことができる。このフィールドの値が０の場合にはＩＰｖ４を、１の場合にはＩＰｖ６アドレス形式が用いられることを示すことができる。
【１０９２】
ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、このディスクリプタがｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このディスクリプタはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むことができる。
【１０９３】
ＴＳＩ＿ｆｌａｇフィールドは、このディスクリプタがＴＳＩフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このディスクリプタはＴＳＩフィールドを含むことができる。
【１０９４】
ＤＰ＿ＩＤ＿ｆｌａｇフィールドは、このディスクリプタがＤＰ＿ＩＤフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このディスクリプタはＤＰ＿ＩＤフィールドを含むことができる。
【１０９５】
ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ここで、上述したｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅが独立したストリームとして伝送される場合にｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームを示すことができる。
【１０９６】
ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。
【１０９７】
ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。
【１０９８】
ＴＳＩフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＬＣＴ  ｓｅｓｓｉｏｎなどのｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒを示すことができる。
【１０９９】
ＤＰ＿ＩＤフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍが伝送されるデータパイプのｉｄｅｎｔｉｆｉｅｒを示すことができる。ここで、ｄａｔａ  ｐｉｐｅはｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｉｐｅと同一であってもよい。
【１１００】
図１１０は、本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。
【１１０１】
本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅがシグナリングメッセージを介して直接伝送される場合、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値を提供することができる。
【１１０２】
本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールド及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを含むことができる。
【１１０３】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、固有値が割り当てられることによって、当該ｄｅｓｃｒｉｐｔｏｒがｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒであることを識別することができる。
【１１０４】
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、当該ｄｅｓｃｒｉｐｔｏｒの長さをバイト数で示すことができる。
【１１０５】
ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドは、後続するｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドの形式を示すことができる。本発明の一実施例によれば、このフィールドの値が０の場合に３２ビットのＮＴＰ  ｔｉｍｅｓｔａｍｐ、１の場合に６４ビットのＮＴＰ  ｔｉｍｅｓｔａｍｐ、２の場合に８０ビットのＰＴＰ  ｔｉｍｅｓｔａｍｐが用いられてもよい。
【１１０６】
ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドによって定められたｔｉｍｅｓｔａｍｐ形式で表現されるｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅの値を示すことができる。本発明の一実施例によれば、このフィールドは、送信端の現在時間、このｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの生成時間などを示すことができる。本発明の一実施例によれば、このフィールドは、送信端と受信端とのｓｙｓｔｅｍ  ｃｌｏｃｋ同期化に用いられてもよい。
【１１０７】
図１１１は、本発明の一実施例に係るＦＩＣの構成を示す図である。
【１１０８】
本発明の一実施例によれば、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ  ｌｅｖｅｌ、ｐａｒｔｉｔｉｏｎ  ｌｅｖｅｌ及び／又はｓｅｒｖｉｃｅ  ｌｅｖｅｌで伝送されてもよい。
【１１０９】
本発明の一実施例によれば、一つのｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌで一つのｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、上述したｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌを介して伝送される全てのコンテンツ及びサービスがこのｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを介して同期化されてもよい。
【１１１０】
本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、前述したＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分に位置してもよい。すなわち、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ  ｌｅｖｅｌで伝送されてもよい。本発明の一実施例によれば、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅはストリーム形態で伝送され、受信機はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたｂｏｏｔｓｔｒａｐ情報を用いて、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅが伝送される当該ストリームに接近することができる。本発明の一実施例によれば、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ＦＩＣを介してｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値が直接伝送されてもよい。本発明の他の実施例によれば、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿  ｖａｌｕｅ＿  ｄｅｓｃｒｉｐｔｏｒに代えてｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値そのものが位置してもよい。
【１１１１】
本発明の他の実施例によれば、一つのｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌは複数のｐａｒｔｉｔｉｏｎに分けられてもよく、分けられた一つのｐａｒｔｉｔｉｏｎは一つのｂｒｏａｄｃａｓｔｅｒに割り当てられてもよい。本発明の一実施例によれば、一つのｐａｒｔｉｔｉｏｎで一つのｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、上述したｐａｒｔｉｔｉｏｎ内の全てのコンテンツ及びサービスがこのｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを介して同期化されてもよい。
【１１１２】
本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、前述したＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分に位置してもよい。すなわち、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｐａｒｔｉｔｉｏｎ  ｌｅｖｅｌで伝送されてもよい。本発明の一実施例によれば、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅはストリーム形態で伝送され、受信機は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたｂｏｏｔｓｔｒａｐ情報を用いて、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅが伝送される当該ストリームに接近することができる。本発明の一実施例によれば、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ＦＩＣを介してｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値が直接伝送されてもよい。本発明の他の実施例によれば、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿  ｖａｌｕｅ＿  ｄｅｓｃｒｉｐｔｏｒに代えてｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値そのものが位置してもよい。
【１１１３】
本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールド、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及び／又はＦＩＣ＿ｌｅｖｅｌ＿ディスクリプタを含むことができる。
【１１１４】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣのバージョンを示すことができる。
【１１１５】
ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドは、ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍを識別することができる。
【１１１６】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ内に含まれたｐａｒｔｉｔｉｏｎの個数を示すことができる。ここで、ｐａｒｔｉｔｉｏｎは放送局を示すことができる。
【１１１７】
ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、ｐａｒｔｉｔｉｏｎを識別することができる。
【１１１８】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｐａｒｔｉｔｉｏｎレベルに含まれるディスクリプタの個数を示すことができる。
【１１１９】
ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒは、ｐａｒｔｉｔｉｏｎレベルに含まれるディスクリプタを示すことができる。本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒがこのディスクリプタに含まれてもよい。
【１１２０】
ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌレベルに含まれるディスクリプタの個数を示すことができる。ここで、ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌレベルは、ＦＩＣ及び／又はｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍレベルと同一であってもよい。
【１１２１】
ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌレベルに含まれるディスクリプタを示すことができる。本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒがこのディスクリプタに含まれてもよい。
【１１２２】
図１１２は、本発明の他の実施例に係るＦＩＣの構成を示す図である。
【１１２３】
本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅがｐａｒｔｉｔｉｏｎ  ｌｅｖｅｌでストリーム形態で伝送される場合、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを一つのサービスに割り当て、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームに接近する情報をシグナリングすることができる。
【１１２４】
本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームは、ｐａｒｔｉｔｉｏｎを構成する一つのサービスで伝送されてもよい。本発明の一実施例によれば、サービスがｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームを伝送するか否かは、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドでシグナリングでき、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドにｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームのための特定値が割り当てられてもよい。本発明の一実施例によって、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドから、当該サービスがｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームを伝送するサービスであることが識別されると、後続するＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＳＣ＿ＴＳＩフィールド及び／又はＳＳＣ＿ＤＰ＿ＩＤフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームに接近するためのｂｏｏｔｓｔｒａｐ情報として活用されてもよい。
【１１２５】
本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールド、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＳＣ＿ＴＳＩフィールド及び／又はＳＳＣ＿ＤＰ＿ＩＤフィールドを含むことができる。
【１１２６】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣのバージョンを示すことができる。
【１１２７】
ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドは、ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍを識別することができる。
【１１２８】
ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ｂｒｏａｄｃａｓｔ  ｓｔｒｅａｍ内に含まれたｐａｒｔｉｔｉｏｎの個数を示すことができる。ここで、ｐａｒｔｉｔｉｏｎは放送局を示すことができる。
【１１２９】
ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、ｐａｒｔｉｔｉｏｎを識別することができる。
【１１３０】
ｓｅｒｖｉｃｅ＿ｉｄフィールドは、このサービスがｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームを含むサービスであることを識別することができる。
【１１３１】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、サービスのタイプを示すが、本発明の一実施例に係るサービスがｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームを伝送するサービスであることを識別するために用いられてもよい。
【１１３２】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰ  ａｄｄｒｅｓｓの形式を示すことができる。このフィールドの値が０である場合にＩＰｖ４、１である場合にＩＰｖ６アドレス形式が用いられることを示すことができる。
【１１３３】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、このサービスがｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このサービスはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むことができる。
【１１３４】
ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＩＰ  ｄａｔａｇｒａｍのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。ここで、上述したｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅが独立したストリームで伝送される場合に、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームを示すことができる。
【１１３５】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＩＰ  ｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。
【１１３６】
ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＩＰ  ｄａｔａｇｒａｍのＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。
【１１３７】
ＳＳＣ＿ＴＳＩフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍを含むＬＣＴ  ｓｅｓｓｉｏｎなどのｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒを示すことができる。
【１１３８】
ＳＳＣ＿ＤＰ＿ＩＤフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ  ｓｔｒｅａｍが伝送されるデータパイプのｉｄｅｎｔｉｆｉｅｒを示すことができる。ここで、ｄａｔａ  ｐｉｐｅはｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｉｐｅと同一であってもよい。
【１１３９】
図１１３は、本発明の一実施例に係るＳｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎの構成を示す図である。
【１１４０】
本発明の一実施例によれば、一つのサービスで一つのｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、サービス内の全てのコンテンツ及びストリームがこのｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを介して同期化されてもよい。
【１１４１】
本発明の一実施例は、一つのサービスに該当するｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅのブートストラップ情報を伝送することができる。ここで、ブートストラップ情報は、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームに接近するための情報を示すことができる。
【１１４２】
本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値のシーケンスは、別途のｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームとして構成されて、当該ストリームパケットのペイロードを介して伝送されたり、コンポーネントを伝送するストリームパケットのヘッダーに含まれて伝送されてもよい。
【１１４３】
本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値が、コンポーネントを伝送するストリームパケットのヘッダーに含まれて伝送される場合、ＬＣＴ  ｐａｃｋｅｔ  ｈｅａｄｅｒのＥＸＴ＿ＴＩＭＥ  ｅｘｔｅｎｓｉｏｎを用いてｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値を伝送することができる。
【１１４４】
本発明の一実施例によれば、一つのサービスを構成する内部のストリームを介してｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅが伝送される時、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームは、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドによって識別されてもよい。＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドは、ＲＯＵＴＥ  ｓｅｓｓｉｏｎを構成するＬＣＴ  ｓｅｓｓｉｏｎのうち、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するＬＣＴ  ｓｅｓｓｉｏｎのＴＳＩ情報を示すことができる。本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームのＩＰ  ａｄｄｒｅｓｓ及びＵＤＰ  ｐｏｒｔ情報は、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドの前に存在するＲＯＵＴＥ  Ｓｅｓｓｉｏｎ内部の他のフィールドによって識別されてもよい。本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームを伝送するＤＰに対する情報は、前述したＬＳＩＤ及びＣＭＴを介してシグナリングされてもよい。ここで、ＬＳＩＤは、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）と同一であってもよく、ＣＭＴは、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）と同一であってもよい。
【１１４５】
本発明の他の実施例は、Ｓｅｒｖｉｃｅ  ＤｅｓｃｒｉｐｉｏｎにＣｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ  Ｂｏｏｔｓｔｒａｐフィールドを含めることによって、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームに接近するための情報をシグナリングすることができる。本発明の一実施例に係る、Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ  Ｂｏｏｔｓｔｒａｐフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒのように、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰ  ａｄｄｒｅｓｓ、ＵＤＰ  ｐｏｒｔ、ＴＳＩ、ＤＰなどの情報を含むことができる。
【１１４６】
同図で示すＳｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎは、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールド及びＣｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ  Ｂｏｏｔｓｔｒａｐフィールドの両方を含んでいるが、本発明の一実施例によれば、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎは、上述した両フィールドのいずれか一つのみを含んでもよく、両フィールドのいずれか一つを用いてｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームに接近するための情報（ｂｏｏｔｓｔｒａｐ情報）をシグナリングすることもできる。
【１１４７】
本発明の一実施例に係るＳｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎは、ＵＳＢＤ／ＵＳＤと同一であってもよく、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎは、＠ｓｅｒｖｉｃｅ＿ｉｄフィールド、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、＠ｓｅｒｖｉｃｅ＿ｎａｍｅフィールド、＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールド、＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールド、＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールド、＠ＳＰ＿ｉｎｄｉｃａｔｏｒフィールド、ＲＯＵＴＥ  Ｓｅｓｓｉｏｎフィールド、＠ｓｏｕｒｃｅＩＰＡｄｄｒフィールド、＠ｄｅｓｔＩＰＡｄｄｒフィールド、＠ｄｅｓｔＵＤＰＰｏｒｔフィールド、＠ＬＳＩＤ＿ＤＰフィールド、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールド、Ｔａｒｇｅｔｉｎｇフィールド、Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙフィールド、Ｒｉｇｈｔ  Ｉｓｓｕｅｒ  Ｓｅｒｖｉｃｅフィールド、Ｃｕｒｒｅｎｔ  Ｐｒｏｇｒａｍフィールド、Ｏｒｉｇｉｎａｌ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、Ｃｏｎｔｅｎｔ  Ｌａｂｅｌｉｎｇフィールド、Ｇｅｎｒｅフィールド、Ｃａｐｔｉｏｎフィールド、Ｐｒｏｔｅｃｔｉｏｎフィールド及び／又はＣｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ  Ｂｏｏｔｓｔｒａｐフィールドを含むことができる。
【１１４８】
＠ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスを識別することができる。
【１１４９】
＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、サービスのタイプを示すことができる。
【１１５０】
＠ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、サービスの名前を示すことができる。
【１１５１】
＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、サービスのチャネルナンバーを示すことができる。
【１１５２】
＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、サービスのｓｔａｔｕｓを示すことができる。このフィールドは、当該サービスがａｃｔｉｖｅか又はｉｎａｃｔｉｖｅかを示すことができる。
【１１５３】
＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。
【１１５４】
＠ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは、当該サービスをなす一つ以上のコンポーネントがプロテクションされているか否かを示すことができる。すなわち、当該サービスがプロテクションされているか否かを示すことができる。
【１１５５】
ＲＯＵＴＥ  Ｓｅｓｓｉｏｎフィールドは、当該サービスが伝送されるＲＯＵＴＥ  Ｓｅｓｓｉｏｎに関する情報を示すことができる。
【１１５６】
＠ｓｏｕｒｃｅＩＰＡｄｄｒフィールドは、当該ＲＯＵＴＥ  Ｓｅｓｓｉｏｎのｓｏｕｒｃｅ  ＩＰアドレスを示すことができる。
【１１５７】
＠ｄｅｓｔＩＰＡｄｄｒフィールドは、当該ＲＯＵＴＥ  Ｓｅｓｓｉｏｎのｄｅｓｔｉｎａｔｉｏｎ  ＩＰアドレスを示すことができる。
【１１５８】
＠ｄｅｓｔＵＤＰＰｏｒｔフィールドは、当該ＲＯＵＴＥ  Ｓｅｓｓｉｏｎのｄｅｓｔｉｎａｔｉｏｎ  ＵＤＰポートナンバーを示すことができる。
【１１５９】
＠ＬＳＩＤ＿ＤＰフィールドは、当該ＲＯＵＴＥ  Ｓｅｓｓｉｏｎの伝送パラメータなどの情報を含むＬＳＩＤを伝達するｄａｔａ  ｐｉｐｅを識別することができる。本発明の一実施例によれば、このフィールドは、ＲＯＵＴＥ  Ｓｅｓｓｉｏｎを構成する一つ以上のＬＣＴ  ｓｅｓｓｉｏｎに関する情報を含むＬＳＩＤを識別することができる。
【１１６０】
＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドは、ＲＯＵＴＥ  ｓｅｓｓｉｏｎを構成するＬＣＴ  ｓｅｓｓｉｏｎのうち、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するＬＣＴ  ｓｅｓｓｉｏｎのＴＳＩ情報を示すことができる。
【１１６１】
Ｔａｒｇｅｔｉｎｇフィールドは、当該サービスに対するｔａｒｇｅｔｉｎｇパラメータを示すことができる。このフィールドに関する詳細な説明は、前述したとおりである。
【１１６２】
Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙフィールドは、当該サービス関連ｃｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ情報を示すことができる。本発明の一実施例によれば、このフィールドは、ｃｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ  ｒａｔｉｎｇ関連情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。
【１１６３】
Ｒｉｇｈｔ  Ｉｓｓｕｅｒ  Ｓｅｒｖｉｃｅフィールドは、当該サービス関連ｒｉｇｈｔ  ｉｓｓｕｅなどに関する情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。
【１１６４】
Ｃｕｒｒｅｎｔ  Ｐｒｏｇｒａｍフィールドは、現在プログラムなどに関する情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。
【１１６５】
Ｏｒｉｇｉｎａｌ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールドは、元のサービスを識別する情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。
【１１６６】
Ｃｏｎｔｅｎｔ  Ｌａｂｅｌｉｎｇフィールドは、ｃｏｎｔｅｎｔ  ｌａｂｅｌｉｎｇ関連情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。
【１１６７】
Ｇｅｎｒｅフィールドは、当該サービスのジャンル情報を含むことができる。
【１１６８】
Ｃａｐｔｉｏｎフィールドは、当該サービスのキャプション関連情報を含むことができる。
【１１６９】
Ｐｒｏｔｅｃｔｉｏｎフィールドは、当該サービスのｐｒｏｔｅｃｔｉｏｎ関連情報を含むことができる。
【１１７０】
Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ  Ｂｏｏｔｓｔｒａｐフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒのように、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰ  ａｄｄｒｅｓｓ、ＵＤＰ  ｐｏｒｔ、ＴＳＩ、ＤＰなどの情報を含むことができる。すなわち、このフィールドは、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅストリームに接近するための情報を含むことができる。
【１１７１】
図１１４は、本発明の一実施例に係るＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎの構成を示す図である。
【１１７２】
本発明の一実施例は、前述したＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎに＠ｃｌｏｃｋＲｅｆＦｌａｇフィールドを追加して、現在の放送ストリーム又は他の放送ストリームを介して伝送されるストリームのうち、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームを識別することができる。本発明の一実施例によれば、＠ｃｌｏｃｋＲｅｆＦｌａｇフィールドがフィールド値１を有する場合、当該コンポーネントがｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを含んで伝送することを示すことができる。
【１１７３】
本発明の一実施例によれば、一つのサービスを介して伝送されるコンポーネントのうち、＠ｃｌｏｃｋＲｅｆＦｌａｇフィールド値として１を有するコンポーネントの個数は、最大１個に制約し得る。
【１１７４】
本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームのＴＳＩ及びＤＰ情報は、先に登場するＢｒｏａｄｃａｓｔＣｏｍｐフィールドの下位フィールドによって識別することができ、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰ  ａｄｄｒｅｓｓとＵＤＰ  ｐｏｒｔ情報は、前述したＳｅｒｖｉｃｅ  ＤｅｓｃｒｉｐｔｉｏｎのＲＯＵＴＥ  Ｓｅｓｓｉｏｎフィールドの下位フィールド及びＬＳＩＤで提供される情報を用いて識別することができる。本発明の一実施例によれば、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅを伝送するストリームが他の放送ストリームを介して伝送される場合、ＦｏｒｉｇｎＣｏｍｐフィールドの下位フィールドを用いてそれを識別することができる。
【１１７５】
同図に示すフィールドに関する詳細な説明は、前述したとおりである。
【１１７６】
図１１５は、本発明の一実施例に係る放送信号送信方法を示す図である。
【１１７７】
本発明の一実施例に係る放送信号送信方法は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報をエンコーディングする段階（ＳＬ１２８０１０）、エンコーディングされた放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を含む放送信号を生成する段階（ＳＬ１２８０２０）、及び／又は放送信号を伝送する段階（ＳＬ１２８０３０）を有することができる。ここで、上述した放送サービスは、ＡＴＳＣ ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。
【１１７８】
本発明の他の実施例によれば、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報のうち少なくとも一つは、送信側と受信側との時間的同期化のための時間情報を含むことができる。ここで、上述した時間情報は、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒを表すことができる。これに関する詳細な説明は、図１１０、図１１１で前述した。
【１１７９】
本発明の他の実施例によれば、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報のうち少なくとも一つは、送信側と受信側との時間的同期化のための時間情報を伝送するストリームに接近するための接近情報を含むことができる。ここで、上述した接近情報は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたフィールドを表すことができる。これに関する詳細な説明は、図１０９、図１１１、図１１３で前述した。
【１１８０】
本発明の他の実施例によれば、時間情報は、送信側と受信側との時間的同期化に用いられる基準時間値及び／又は基準時間値のタイプを示す情報を含むことができる。ここで、上述した基準時間値は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを表すことができ、上述した基準時間値のタイプを示す情報は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドを表すことができる。これに関する詳細な説明は図１１０で前述した。
【１１８１】
本発明の他の実施例によれば、接近情報は、時間情報を伝送するストリームを含むＩＰデータグラム目的地ＩＰアドレス情報、時間情報を伝送するストリームを含むＩＰデータグラムＵＤＰポートナンバー、時間情報を伝送するストリームを含むセッションを識別する情報、及び／又は時間情報を伝送するストリームが伝送されるデータパイプを識別する情報を含むことができる。これに関する詳細な説明は図１０９で前述した。
【１１８２】
本発明の他の実施例によれば、第１シグナリング情報は、一つの放送ストリームで伝送される一つ以上のサービスに関する情報を含み、時間情報は、第１シグナリング情報のサービスレベルに含まれて一つのサービス内の全てのコンポーネントの同期化のために用いられてもよい。これに関する詳細な説明は、図１１２、図１１３、図１１４で前述した。
【１１８３】
本発明の他の実施例によれば、放送サービスは、送信側と受信側との時間的同期化のための時間情報を提供する放送サービスに該当し、第１シグナリング情報は、放送サービスに接近するための情報を含むことができる。これに関する詳細な説明は図１１２で前述した。
【１１８４】
図１１６は、本発明の一実施例に係る放送信号受信方法を示す図である。
【１１８５】
本発明の一実施例に係る放送信号受信方法は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報を含む放送信号を受信する段階（ＳＬ１２９０１０）、受信した放送信号から放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を抽出する段階（ＳＬ１２９０２０）、及び／又は抽出された放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報をデコーティングする段階（ＳＬ１２９０３０）を有することができる。ここで、上述した放送サービスは、ＡＴＳＣ ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。
【１１８６】
本発明の他の実施例によれば、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報のうち少なくとも一つは、送信側と受信側との時間的同期化のための時間情報を含むことができる。ここで、上述した時間情報は、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ、ｃｌｏｃｋ  ｒｅｆｅｒｅｎｃｅ値及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒを表すことができる。これに関する詳細な説明は、図１１０、図１１１で前述した。
【１１８７】
本発明の他の実施例によれば、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報のうち少なくとも一つは、送信側と受信側との時間的同期化のための時間情報を伝送するストリームに接近するための接近情報を含むことができる。ここで、上述した接近情報は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたフィールドを表すことができる。これに関する詳細な説明は、図１０９、図１１１、図１１３で前述した。
【１１８８】
本発明の他の実施例によれば、時間情報は、送信側と受信側との時間的同期化に用いられる基準時間値及び／又は基準時間値のタイプを示す情報を含むことができる。ここで、上述した基準時間値は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを表すことができ、上述した基準時間値のタイプを示す情報は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドを表すことができる。これに関する詳細な説明は、図１１０で前述した。
【１１８９】
本発明の他の実施例によれば、接近情報は、時間情報を伝送するストリームを含むＩＰデータグラム目的地ＩＰアドレス情報、時間情報を伝送するストリームを含むＩＰデータグラムＵＤＰポートナンバー、時間情報を伝送するストリームを含むセッションを識別する情報及び／又は時間情報を伝送するストリームが伝送されるデータパイプを識別する情報を含むことができる。これに関する詳細な説明は図１０９で前述した。
【１１９０】
本発明の他の実施例によれば、第１シグナリング情報は、一つの放送ストリームで伝送される一つ以上のサービスに関する情報を含み、時間情報は、第１シグナリング情報のサービスレベルに含まれて一つのサービス内の全てのコンポーネントの同期化のために用いられてもよい。これに関する詳細な説明は、図１１２、図１１３、図１１４で前述した。
【１１９１】
図１１７は、本発明の一実施例に係る放送信号送信装置の構成を示す図である。
【１１９２】
本発明の一実施例に係る放送信号送信装置（Ｌ１３００１０）は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報をエンコーディングするエンコーダ（Ｌ１３００２０）、エンコーディングされた放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を含む放送信号を生成する生成部（Ｌ１３００３０）、及び／又は放送信号を伝送する伝送部（Ｌ１３００４０）を含むことができる。ここで、上述した放送サービスは、ＡＴＳＣ ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。
【１１９３】
図１１８は、本発明の一実施例に係る放送信号受信装置の構成を示す図である。
【１１９４】
本発明の一実施例に係る放送信号受信装置（Ｌ１３１０１０）は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報を含む放送信号を受信する受信部（Ｌ１３１０２０）、受信した放送信号から、放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を抽出する抽出部（Ｌ１３１０３０）、及び／又は抽出された放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報をデコーティングするデコーダ（Ｌ１３１０４０）を含むことができる。ここで、上述した放送サービスはＡＴＳＣ ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。ここで、上述した放送サービスはＡＴＳＣ ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。
【１１９５】
図１１９は、本発明の一実施例に係る、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝達される場合において、そのサービスディスクリプション情報を示す図である。
【１１９６】
本発明はセッションディスクリプション情報が、伝送セッション外部経路を介して伝送される方法を提案する。ここで、セッションディスクリプション情報は、当該伝送セッションの伝送特性やプロトコル、パケット構造などの情報を含むことができる。実施例によって、セッションディスクリプション情報は、前述したＬＳＩＤに該当し得る。また、セッションディスクリプション情報は、前述したＳ−ＴＳＩＤのうち、複数個のＬＳエレメントに該当する情報であってもよい。この場合、ここでのサービスディスクリプション情報は、Ｓ−ＴＳＩＤに該当し得る。
【１１９７】
このセッションディスクリプション情報は、当該伝送セッションを介して伝達されたり、又は伝送セッション外部経路を介して受信機に伝達されてもよい。また、セッションディスクリプション情報は、他のシグナリングメッセージに含まれて伝送されたり、当該伝送セッションの内／外部に存在するサービスシグナリングチャネルなどの経路を介して伝送されてもよい。サービスシグナリングチャネルを介して伝送される場合、セッションディスクリプション情報は、他のシグナリングメッセージと併せて伝送されてもよい。
【１１９８】
まず、セッションディスクリプション情報が他のシグナリングメッセージに含まれて伝送される場合を説明する。
【１１９９】
セッションディスクリプション情報は、前述した他のシグナリングメッセージに含まれて伝送されてもよい。他のシグナリングメッセージとしてはＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤ、ＳＭＴ，ＣＭＴなどを挙げることができる。図示の実施例では、セッションディスクリプション情報がサービスディスクリプション情報に含まれている。ここで、サービスディスクリプション情報は、前述したＳＭＴ乃至Ｓ−ＴＳＩＤに該当し得る。
【１２００】
ここで、セッションディスクリプション情報は、サービスディスクリプション情報のＬＳＩＤエレメントに含まれてもよい。ここで、ＬＳＩＤエレメントは、サービスディスクリプション情報のＲＯＵＴＥ  ｓｅｓｓｉｏｎエレメントの下位エレメントであってもよい。セッションディスクリプション情報は、当該ＲＯＵＴＥ  ｓｅｓｓｉｏｎエレメントが示すＲＯＵＴＥセッション（伝送セッション）のセッション情報を含むことができる。当該ＲＯＵＴＥセッションを、ＲＯＵＴＥ  ｓｅｓｓｉｏｎエレメントの＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔ、などの情報によって示すことができる。このようにセッションディスクリプション情報がサービスディスクリプション情報に直接含まれて伝送される場合、セッションディスクリプション情報が記述する伝送セッションでは、セッションディスクリプション情報が伝達されなくてもよい。これは重複を避けるためである。
【１２０１】
サービスディスクリプション情報内部の各エレメントは、前述したとおりである。
【１２０２】
＠ｓｅｒｖｉｃｅ＿ｉｄは、当該サービスディスクリプション情報が記述するサービスの識別子を示すことができる。＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙは、当該サービスのカテゴリーを示すことができる。＠ｓｅｒｖｉｃｅ＿ｎａｍｅは、当該サービスの名前を示すことができる。＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒは、当該サービスと関連したチャネルナンバー情報を示すことができる。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓは、当該サービスの状態情報を示すことができる。＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎは、当該サービスのディストリビューション関連情報を示すことができる。＠ＳＰ＿ｉｎｄｉｃａｔｏｒは、当該サービスが保護（ｐｒｏｔｅｃｔｉｏｎ）されているかを示すことができる。ここで、当該サービスのサービスコンポーネントのうち少なくとも一つでも保護されていると、当該サービスが保護されていると示すこができる。
【１２０３】
ＲＯＵＴＥ  ｓｅｓｓｉｏｎエレメントは、当該サービス又はサービスコンポーネントが伝達されるＲＯＵＴＥ  ｓｅｓｓｉｏｎに関する情報を含むことができる。ＲＯＵＴＥ  ｓｅｓｓｉｏｎエレメントは、サービスディスクリプション情報内に複数個存在してもよい。＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔはそれぞれ、当該ＲＯＵＴＥパケットを伝送するＩＰデータグラムソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションＰｏｒｔナンバー情報を含むことができる。すなわち、この情報は、当該ＲＯＵＴＥセッションを示すことができる。
【１２０４】
＠ＬＳＩＤ＿ＤＰは、当該ＲＯＵＴＥセッションのセッションディスクリプション情報が伝達されるＤＰ（又は、ＰＬＰ）を識別することができる。ここで、当該ＲＯＵＴＥセッションは、ソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションＰｏｒｔナンバー情報によって識別されるＲＯＵＴＥセッションを意味できる。
【１２０５】
＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤは、セッションディスクリプション情報を伝達するセッションディスクリプションテーブルの識別子であり、当該ＲＯＵＴＥセッションのセッションディスクリプション情報を有するセッションディスクリプションテーブルを識別することができる。このフィールドは、セッションディスクリプション情報がセッションディスクリプションテーブルに含まれて伝達される場合に活用されてもよい。セッションディスクリプションテーブルは、サービスシグナリングチャネルを介して他のシグナリングメッセージと共に伝送されてもよい。
【１２０６】
＠ＬＳＩＤｕｒｌは、当該ＲＯＵＴＥセッションのセッションディスクリプション情報がブロードバンドで伝送される場合、その位置を識別するためのＵＲＬ情報を有することができる。このフィールドは、セッションディスクリプション情報がブロードバンドで伝送される場合に活用することができる。
【１２０７】
Ｔａｒｇｅｔｉｎｇは、当該サービスに対するターゲッティングパラメータを示すことができる。すなわち、当該サービスが受信機又はコンパニオンデバイスのためのサービスであるかを識別することができる。Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙは、当該サービス関連コンテンツアドバイザリー情報、すなわち、当該サービスのレーティングに関連した情報を含むことができる。Ｒｉｇｈｔ  Ｉｓｓｕｅｒ  Ｓｅｒｖｉｃｅは、当該サービスに関連した正当なイシュアー関連情報を含むことができる。Ｃｕｒｒｅｎｔ  Ｐｒｏｇｒａｍは、現在プログラムに関する情報を含むことができる。Ｏｒｉｇｉｎａｌ  Ｓｅｒｖｉｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎは、元のサービスに関する識別情報を含むことができる。Ｃｏｎｔｅｎｔ  Ｌａｂｅｌｉｎｇ情報は、当該サービスのコンテンツラベリング情報を含むことができる。Ｇｅｎｒｅは、当該サービスのジャンル情報を含むことができる。Ｃａｐｔｉｏｎは、当該サービスのキャプション関連情報を含むことができる。Ｐｒｏｔｅｃｔｉｏｎは、当該サービスのプロテクションに関連した情報を含むことができる。
【１２０８】
ここで、上記実施例に対して、伝送セッションがＲＯＵＴＥセッションである場合を挙げて説明したが、本発明がこれに限定されるわけではない。すなわち、ＭＭＴＰセッションなどの他の伝送セッションに対しても同じ方式で本実施例を適用することができる。
【１２０９】
図１２０は、本発明の一実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。
【１２１０】
前述したように、セッションディスクリプション情報は、サービスシグナリングチャネルなどの経路を介して伝送されてもよい。この場合、セッションディスクリプション情報は、他のシグナリングメッセージと併せて伝送されてもよい。サービスシグナリングチャネルは、実施例によって別途の伝送セッションを介して伝達されてもよく、ＲＯＵＴＥセッションなどの伝送セッション内部の一つのサブセッションによって伝達されてもよい。ここで、サブセッションは、ＬＣＴセッションに該当し得る。
【１２１１】
一つのサービスが複数個の伝送セッションに分けられて伝達される場合、複数個の伝送セッションに対するディスクリプション情報が必要となり得る。この場合、各伝送セッションに対するセッションディスクリプション情報がサービスシグナリングチャネルで伝送されてもよい。この時、それぞれの伝送セッションとセッションディスクリプションをマッピングする必要があり得る。このマッピングのために、前述した＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤ情報が活用されてもよい。この情報を用いて、サービスディスクリプション情報が示すＲＯＵＴＥセッションに対するセッションディスクリプション情報を取得することができる。これは、当該情報にマッピングされるセッションディスクリプションテーブルを識別することによって行うことができる。このようなマッピングは、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝送される場合には省略されてもよい。
【１２１２】
実施例によって、サービスシグナリングチャネルは、ＳＬＳが伝送されるＲＯＵＴＥセッション内のＬＣＴセッションを意味できる。このＬＣＴセッションは、前述したようにＴＳＩ＝０に特定されていてもよい。
【１２１３】
同図の実施例（ｔ２０１０）は、前述したシグナリングメッセージフォーマットを基本構造とし、セッションディスクリプション情報伝送のために拡張された構造を有するメッセージフォーマットであってもよい。セッションディスクリプション情報伝送のためにｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドをそれぞれＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎとＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤに分けて定義することができる。
【１２１４】
ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは、このセッションディスクリプションテーブルのバージョン又はプロトコルバージョンを示すことができる。ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤは、本テーブルが送信しているセッションディスクリプション情報の識別子であり、前述したサービスディスクリプション情報内の＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤと一致する値が用いられてもよい。これを用いて、ＲＯＵＴＥセッションとセッションディスクリプション情報間のマッピングを行うことができる。ＬＣＴ＿ｓｅｓｓｉｏｎ＿ｉｎｓｔａｎｃｅ＿ｄｅｓｃｒｉｐｔｉｏｎ（）には、セッションディスクリプション情報がバイナリ又はＸＭＬ形態で含まれてもよい。すなわち、セッションディスクリプション情報の実際データがここに含まれてもよい。その他、セッションディスクリプションテーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。
【１２１５】
同図の他の実施例（ｔ２０２０）は、セッションディスクリプション情報伝達のためのセッションディスクリプションテーブルの他の実施例である。本実施例は、ＭＰＥＧ−２ＴＳプライベートセクション（ｐｒｉｖａｔｅ  ｓｅｃｔｉｏｎ）ベースのフィールド構成を有することができる。ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤ、ＬＣＴ＿ｓｅｓｓｉｏｎ＿ｉｎｓｔａｎｃｅ＿ｄｅｓｃｒｉｐｔｉｏｎ（）の意味は、前述した実施例のそれと同一であってもよい。その他、セッションディスクリプションテーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。
【１２１６】
図１２１は、本発明の一実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。
【１２１７】
本実施例で、１つのサービスは２つのＲＯＵＴＥセッションを介して伝送されている。本実施例で、一番目のＲＯＵＴＥセッションのセッションディスクリプション情報は、当該ＲＯＵＴＥセッション（一番目のＲＯＵＴＥセッション）を介して伝送され、二番目のＲＯＵＴＥセッションのセッションディスクリプション情報は、二番目のＲＯＵＴＥセッションの外部経路であるサービスシグナリングチャネルを介して伝送されてもよい。ここで、サービスシグナリングチャネルは、一番目のＲＯＵＴＥセッション内部に位置してもよい。
【１２１８】
本実施例で、各シグナリングメッセージ及び／又はサービスコンポーネントデータの取得手順について説明する。
【１２１９】
まず、受信機は、ＦＩＣから、サービスシグナリングチャネルのブートストラップ情報を取得することができる。これを用いて、受信機は、サービスシグナリングチャネルに接近することができる。ＦＩＣのＩＰアドレス、ＵＤＰポート情報を用いて接近することができる。実施例によって、ＴＳＩ情報及び／又はＰＬＰ  ＩＤ情報がさらに必要であってもよい。これは、前述したＳＬＴを用いてＳＬＳに接近することに対応し得る。この場合、ＳＬＴはＦＩＣに対応し、ＳＬＳを伝達するＬＣＴセッションはサービスシグナリングチャネルに対応し、ＳＬＳはサービスシグナリングチャネル内の情報に対応し得る。本実施例で、ＦＩＣは、フィジカル信号フレームの別途のチャネルを介して伝達されているが、ＳＬＴの場合は、ＩＰ／ＵＤＰを介してエンカプセレーションされてＰＬＰで伝達されてもよい。
【１２２０】
その後、ブートストラップ情報を用いて接近したサービスシグナリングチャネルで、ＳＭＴの情報を取得することができる。ＳＭＴから、各ＲＯＵＴＥセッションに対するセッションディスクリプション情報を取得することができる。一番目のＲＯＵＴＥセッションに対するセッションディスクリプション情報は、＠ＬＳＩＤ＿ＤＰ情報を用いて取得することができる。＠ＬＳＩＤ＿ＤＰが示すＰＬＰに接近して一番目のＲＯＵＴＥセッションのセッションディスクリプション情報を取得することができる。二番目のＲＯＵＴＥセッションに対するセッションディスクリプション情報は、＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤ情報を用いて取得することができる。＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤが示すセッションディスクリプションテーブルが識別され、二番目のＲＯＵＴＥセッションのセッションディスクリプション情報を取得することができる。
【１２２１】
これは、前述した実施例で、ＳＬＳを伝達するＲＯＵＴＥセッションのＬＣＴセッションに接近して、ＳＬＳの情報を取得する過程に対応し得る。ＳＬＳ情報から、セッションディスクリプション情報、すなわち、各伝送セッションのいかなるサブセッション（ＬＣＴセッションなど）を介してサービスコンポーネントが伝達されているかに関する情報を取得することができる。実施例によって、ＳＬＳのＳ−ＴＳＩＤ内のＬＳエレメントに関する情報が、このセッションディスクリプション情報に該当し得る。この場合の実施例では、別途のセッションディスクリプションテーブルがなくてもよい。また、セッションディスクリプション情報は、ＳＬＳに含まれて伝達されるので、同じＰＬＰを介して伝達され、よって、セッションディスクリプション情報が伝達されるＰＬＰに対する別途のＰＬＰ  ＩＤ情報はなくてもよい。
【１２２２】
その後、ＣＭＴから、各サービスコンポーネントのＰＬＰ  ＩＤを取得することができる。既に取得したセッションディスクリプション情報を用いて、一番目／二番目のＲＯＵＴＥセッションの各ＴＳＩ情報を取得することができる。各ＴＳＩ情報は、当該サービスコンポーネントを伝達するＬＣＴセッションのＴＳＩ情報であってもよい。この情報を用い、各サービスコンポーネントを取得することができる。また、ＭＰＤから、各サービスコンポーネントのリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）ＩＤを取得することができる。
【１２２３】
これは、前述した実施例で、ＳＬＳ内の情報（ＴＳＩなど）を用いて各ＬＣＴセッションに接近して各サービスコンポーネントを取得する過程に対応し得る。この場合の実施例で、Ｓ−ＴＳＩＤは、ＰＬＰ  ＩＤ情報も含むことができるので、別途のＣＭＴはなくてもよい。Ｓ−ＴＳＩＤ内の各セッションディスクリプション情報を用いて、複数個のＲＯＵＴＥセッション内の複数個のＬＣＴセッションにそれぞれ接近することができる。収集されたサービスコンポーネントに対して、ＭＰＤからリプレゼンテーションＩＤを取得することができる。
【１２２４】
図１２２は、本発明の他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。
【１２２５】
本実施例で一つのサービスは２つのＲＯＵＴＥセッションを介して伝送されてもよい。本実施例で、一番目、二番目のＲＯＵＴＥセッションのセッションディスクリプション情報はいずれも、一番目のＲＯＵＴＥセッションを介して伝達されるサービスシグナリングチャネルで伝送されてもよい。
【１２２６】
本実施例で、各シグナリングメッセージ及び／又はサービスコンポーネントデータの取得手順は、前述した実施例と同様である。ただし、本実施例では、両ＲＯＵＴＥセッションに対するセッションディスクリプション情報がいずれもセッションディスクリプションテーブルを介して伝達される。したがって、＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤで識別される両セッションディスクリプションテーブルをまず取得した後、そのテーブル内のセッションディスクリプション情報を用いて、両ＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントに接近することができる。
【１２２７】
この実施例も同様、前述したＳＬＴ−ＳＬＳを用いた実施例に対応し得る。ＳＬＴを用いて、ＳＬＳを伝達するチャネル／経路に接近すると、ＳＬＳ内の情報を用いて、当該サービスのサービスコンポーネントを伝達する経路に接近することができる。この場合、サービスコンポーネントを伝達する経路は、複数個のＲＯＵＴＥセッションにわたって存在してもよく、複数個のＲＯＵＴＥセッション内の複数個のＬＣＴセッションによって各サービスコンポーネントが伝達されてもよい。
【１２２８】
図１２３は、本発明の更に他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。
【１２２９】
本実施例で一つのサービスは２つのＲＯＵＴＥセッションを介して伝送されてもよい。本実施例で、一番目、二番目のＲＯＵＴＥセッションのセッションディスクリプション情報はいずれも、一番目のＲＯＵＴＥセッションを介して伝達されるサービスシグナリングチャネルで伝送されてもよい。
【１２３０】
本実施例で、各シグナリングメッセージ及び／又はサービスコンポーネントデータの取得手順は、前述した実施例と同様である。ただし、本実施例では、サービスシグナリングチャネルが特定ＲＯＵＴＥセッションの一つのＬＣＴセッションを介して伝達されず、別途のＰＬＰ（ＤＰ）、ＩＰ、ＵＤＰで識別される別途のチャネルで伝達されてもよい。この場合、全てのＲＯＵＴＥセッションに対してそのセッションディスクリプション情報が外部経路を介して伝達されることとなるので、サービスシグナリングチャネルは、各セッションに対するセッションディスクリプションテーブルを有することができる。セッションディスクリプションテーブル内のセッションディスクリプション情報を用いて、両ＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントに接近することができる。
【１２３１】
この場合、サービスシグナリングチャネルが特定ＲＯＵＴＥセッションの一つのサブセッション（ＬＣＴセッションなど）を介して伝達されないことから、ＦＩＣ又はＳＬＴのブートストラッピング情報にはＴＳＩ情報が省かれてもよい。
【１２３２】
図１２４は、本発明の一実施例に係る、初期化情報伝達のために拡張されたシグナリングメッセージを示す図である。
【１２３３】
本発明は、前述した放送システムで、サービスのサービスコンポーネントと関連した初期化情報を伝達する方法を提案する。前述したように、各サービスのサービスコンポーネントは、ＤＡＳＨセグメントにフォーマットされてＤＡＳＨリプレゼンテーション形態で、ＬＣＴセッションを介して伝達されてもよい。このサービスコンポーネントのための初期化情報が必要となり得る。ここで、初期化情報は、ＤＡＳＨの初期化セグメント（ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ）に該当し得る。
【１２３４】
初期化情報は、伝送セッションの内／外部に存在するサービスシグナリングチャネルを介して伝送されたり、各ＬＣＴセッションでメディアデータと共に伝送されてもよい。ここで、メディアデータとは、メディアセグメントを意味することができる。
【１２３５】
第一に、初期化情報がサービスシグナリングチャネルを介して伝送される場合、初期化情報は、他のシグナリングメッセージと併せて伝送されてもよい。一つのサービスが複数個のコンポーネントで構成されて伝送される場合、複数個の初期化情報が一つのシグナリングチャネルに含まれて伝送されてもよい。このとき、それぞれの初期化情報と各メディアデータ（サービスコンポーネント）がマッピングされる必要があり得る。
【１２３６】
このマッピングのための識別子を定義することができ、これを＠ｉｓｄＩｎｓｔａｎｃｅＩＤと呼ぶこともできる。この情報は、初期化情報を含む初期化テーブルと各コンポーネントとをマッピングさせることができる。この初期化情報を用いて各サービスコンポーネントを初期化することができる。
【１２３７】
同図に示すコンポーネントマッピングディスクリプション（Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、前述したとおりであるが、＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報をさらに有するように拡張された。＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報は、放送網を介したコンポーネントを示すＢｒｏａｄｃａｓｔＣｏｍｐエレメントの下部に位置して、当該コンポーネントにマッピングされる初期化情報を有する初期化テーブルを識別することができる。その他、コンポーネントマッピングディスクリプション内部のフィールドは、前述したとおりである。実施例によって、ＳＬＴ又はＳＬＳを構成するシグナリング情報のうち一つが、コンポーネントマッピングディスクリプションに代えて、＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報をさらに有するように拡張されてもよい。
【１２３８】
第二に、初期化情報が各メディアデータ、すなわち、サービスコンポーネントと同じ経路を介して伝達されてもよい。すなわち、サービスコンポーネント（メディアセグメント）が伝達されるＬＣＴセッションを介して、当該コンポーネントに関連した初期化情報が共に伝達されてもよい。この時、当該データが一般的なメディアセグメントであるか又は初期化情報であるかは、伝送パケットのヘッダー情報を用いて区別することができる。このようなヘッダー情報としてはＴＯＩ値などを挙げることができる。
【１２３９】
図１２５は、本発明の一実施例に係る、初期化情報伝達のためのメッセージフォーマットを示す図である。
【１２４０】
ここで、初期化情報の伝達のためのメッセージフォーマットは、初期化テーブルのフォーマットを意味することができる。図示の実施例（ｔ７０１０）は、前述したシグナリングメッセージフォーマットを基本構造とし、初期化情報伝送のために拡張された構造を有するメッセージフォーマットであってもよい。初期化情報伝送のためにｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドをそれぞれＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎとＩＳＤＴ  ＿ｉｎｓｔａｎｃｅ＿ＩＤとに分けて定義することができる。
【１２４１】
ＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは、この初期化テーブルのバージョン又はプロトコルバージョンを示すことができる。ＩＳＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤは、このテーブルが送信している初期化情報の識別子であり、前述した拡張されたシグナリング情報内の＠ｉｓｄＩｎｓｔａｎｃｅＩＤと一致する値が用いられてもよい。これを用いて、各サービスコンポーネントと初期化テーブル間のマッピングを行うことができる。このＩＤは、サービスシグナリングチャネル内でユニークに与えられてもよい。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａには初期化情報がバイナリ又はＸＭＬ形態で含まれてもよい。すなわち、初期化情報の全体又は一部のデータがここに含まれてもよい。その他、初期化テーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。
【１２４２】
同図に示す他の実施例（ｔ７０２０）は、初期化情報の伝達のための初期化テーブルの他の実施例である。本実施例は、ＭＰＥＧ−２ＴＳプライベートセクション（ｐｒｉｖａｔｅ  ｓｅｃｔｉｏｎ）ベースのフィールド構成を有することができる。ＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａ）は、前述した実施例のそれと同一であってもよい。その他、初期化テーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。
【１２４３】
Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａ構造の一実施例が示されている（ｔ７０３０）。このエレメントには、当該初期化情報のＵＲＬ情報である＠ｕｒｌと、初期化情報の実際データ部分であるＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔＤａｔａフィールドが含まれてもよい。ＵＲＬは、ＭＰＤに記述された初期化情報（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ）のＵＲＬと同じ値を有することができる。このＵＲＬ情報は、個別の初期化情報とリプレゼンテーション間のマッピング情報として活用されてもよい。
【１２４４】
図１２６は、本発明の他の実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報の伝達のためのメッセージフォーマットを示す図である。
【１２４５】
前述したセッションディスクリプション情報伝送のためのセッションディスクリプションテーブルは、同図のような構造（ｔ８０１０）を有することもできる。ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは、前述したとおりであり、ＬＳＩＤ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａには、後述するＬＳＩＤ  Ｄｅｌｉｖｅｒｙ  Ｄｅｓｃｒｉｐｔｉｏｎの全体又は一部分に該当するデータがＸＭＬ又はバイナリ形態で含まれてもよい。ＬＳＩＤ  Ｄｅｌｉｖｅｒｙ  Ｄｅｓｃｒｉｐｔｉｏｎは、セッションディスクリプション情報伝達に関するディスクリプションであってもよい。その他、セッションディスクリプションテーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。
【１２４６】
ＬＳＩＤ  Ｄｅｌｉｖｅｒｙ  Ｄｅｓｃｒｉｐｔｉｏｎ構造の一実施例が示されている（ｔ８０２０）。ＬＳＩＤ  Ｄｅｌｉｖｅｒｙ  Ｄｅｓｃｒｉｐｔｉｏｎは、＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔ及び／又はＬＳＩＤを含むことができる。＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔはそれぞれ、当該セッションディスクリプション情報が記述するＲＯＵＴＥセッションのソースＩＰ、デスティネーションＩＰ、デスティネーションＵＤＰポートナンバー情報を含むことができる。ＬＳＩＤは、当該セッションディスクリプション情報を有することができる。
【１２４７】
図１２７は、本発明の一実施例に係る、サービスデータを処理する方法を示す図である。
【１２４８】
本発明の一実施例に係るサービスデータを処理する方法は、放送サービスのサービスコンポーネントを生成する段階、第１シグナリングデータ及び第２シグナリングデータを生成する段階、伝送パケットにエンカプセレーションする段階、放送ストリームとしてプロセシングする段階、及び／又は放送ストリームを伝送する段階を含むことができる。ここで、サービスデータを処理する方法は、送信側の動作を基準に記述している。
【１２４９】
まず、放送サービスのサービスコンポーネントが生成され得る（ｔ９０１０）。サービスは、一つ以上のサービスコンポーネントを含むことができる。また、第１シグナリングデータ及び／又は第２シグナリングデータが生成されてもよい（ｔ９０２０）。ここで、第１シグナリングデータは、前述したＳＬＴに該当し、第２シグナリングデータは、前述したＳＬＳに該当し得る。前述したように、第１シグナリングデータは、第２シグナリングデータのを位置を示すための情報を含み、第２シグナリングデータは、放送サービスをシグナリングすることができる。サービスコンポーネント、第１シグナリングデータ及び／又は第２シグナリングデータは、第１モジュールによって生成されてもよい。ここで、第１モジュールは、サービスプロバイダー側でサービスデータを生成するモジュールであってもよい。
【１２５０】
生成されたサービスサービスコンポーネントと第２シグナリングデータが伝送パケットにエンカプセレーションされてもよい（ｔ９０３０）。ここで、伝送パケットは、前述した伝送セッションで伝達されるパケットを意味できる。実施例によって、伝送パケットはＲＯＵＴＥパケット又はＭＭＴＰパケットであってもよい。この伝送パケットは、第１伝送セッション又は第２伝送セッションのサブセッションを介して伝送されてもよい。ここで、伝送セッションは、ＲＯＵＴＥセッション又はＭＭＴＰセッションであってもよい。サブセッションは、ＲＯＵＴＥセッションのＬＣＴセッションであるかか、ＭＭＴＰセッションのＭＭＴＰパケットフローを意味することができる。このエンカプセレーション過程は、各データがＲＯＵＴＥ／ＭＭＴＰパケットにエンカプセレーションされることを意味することができる。このエンカプセレーション過程は、第２モジュールによって行われてもよい。第２モジュールは、ＲＯＵＴＥ／ＭＭＴＰパケットへのエンカプセレーションを行うレイヤを担当するモジュールであってもよい。
【１２５１】
その後、第１シグナリングデータ及び／又は伝送パケットが放送ストリームとしてプロセシングされてもよい（ｔ９０４０）。この過程は、ＳＬＴ及びＲＯＵＴＥ／ＭＭＴＰパケットにエンカプセレーションされたデータがＩＰ／ＵＤＰにエンカプセレーションされることを意味できる。また、この過程は、このＩＰ／ＵＤＰで処理されたデータがフィジカルレイヤでフィジカルレイヤプロセシングを経る過程を意味できる。ＩＰ／ＵＤＰエンカプセレーションを経てフィジカルレイヤプロセシングする過程は、第３モジュールによって行われてもよい。第３モジュールは、ＩＰ／ＵＤＰエンカプセレーション及びフィジカルレイヤを担当するモジュールであってもよい。
【１２５２】
生成された放送ストリームは伝送されてもよい（ｔ９０５０）。これは、第４モジュールによって行われてもよい。第４モジュールは、放送ストリームを伝送する伝送モジュールなどに該当し得る。
【１２５３】
本発明の他の実施例に係るサービスデータを処理する方法において、第２サービスシグナリングデータは、第１伝送セッションの特定サブセッションを介して伝送されてもよい。これは、前述したＳＬＳがＲＯＵＴＥセッションの特定ＬＣＴセッション、すなわち、ＴＳＩ＝０を有するＬＣＴセッションを介して伝達されることに対応し得る。また、これは、ＳＬＳがサービスシグナリングチャネルを介して伝達されることに対応し得る。ＴＳＩ＝０で識別されるＳＬＳを運搬するサブセッション（ＬＣＴセッション）は、実施例によってサービスシグナリングチャネルと呼ぶこともできる。サービスコンポーネントは、第１伝送セッション又は第２伝送セッションのサブセッションを介して伝送されてもよい。サービスコンポーネントは、前述したように、ＲＯＵＴＥ／ＭＭＴＰセッションのサブセッション（ＬＣＴセッション又はＭＭＴＰパケットフロー）を介して伝達されてもよい。
【１２５４】
本発明の更に他の実施例に係るサービスデータを処理する方法において、第１シグナリングデータは、第２シグナリングデータが伝送される第１伝送セッションを示すための情報を含むことができる。これは、前述したＳＬＴが、ＳＬＳが伝送されるＲＯＵＴＥ／ＭＭＴＰセッションを示するためのブートストラップ情報を含むことに対応し得る。第２シグナリングデータは、放送サービスのサービスコンポーネントへの接近情報を含むことができる。ＳＬＳ、特に、Ｓ−ＴＳＩＤは、各サービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ情報を有することができる。また、ＳＬＳのうち、ＭＰＴメッセージは、各サービスコンポーネントが伝達されるＭＭＴＰパケットフローのパケットＩＤ情報を有することができる。
【１２５５】
本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、第１伝送セッションのサブセッションのうち、放送サービスのサービスコンポーネントを伝送するサブセッションを識別する情報をさらに含むことができる。これは、前述したＳＬＳが、ＳＬＳが伝送されるＲＯＵＴＥ／ＭＭＴＰセッションを介して伝達されるサービスコンポーネントの接近情報を有することに対応し得る。この場合、ＳＬＳは、ＴＳＩ情報又はパケットＩＤ情報だけでも、サービスコンポーネントを有するサブセッションを識別することができる。同じ伝送セッション内であるから、ＩＰアドレスなどの情報が別途に含まれなくてもよい。
【１２５６】
本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、放送サービスのサービスコンポーネントを伝送する第２伝送セッションを示すための情報をさらに含むことができる。サービスコンポーネントが、ＳＬＳが伝送される伝送セッションと他の伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のために、ＳＬＳは関連情報を有することができる。この情報は、ＩＰアドレス、ＵＤＰポートナンバーなどの形態であってもよい。
【１２５７】
本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、第２伝送セッションのサブセッションのうち、放送サービスのサービスコンポーネントを伝送するサブセッションを識別する情報をさらに含むことができる。前述したように、サービスコンポーネントが、ＳＬＳが伝送される伝送セッションと他の伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のために、ＳＬＳは、ＴＳＩ情報又はパケットＩＤ情報だけでも、サービスコンポーネントを有するサブセッションを識別することができる。
【１２５８】
本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、放送サービスのサービスコンポーネントを伝送するサブセッションが伝達されるフィジカルパス（ｐａｔｈ）を示す情報をさらに含むことができる。ここで、フィジカルパスは、ＰＬＰ又はＤＰを意味することができる。前述したように、サービスコンポーネントが、ＳＬＳが伝送される伝送セッションと他の伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のために、ＳＬＳは、当該コンポーネントが伝達されるＰＬＰ  ＩＤ情報を有することができる。
【１２５９】
本発明の更に他の実施例に係るサービスデータを処理する方法において、放送サービスのサービスコンポーネントを伝送するサブセッションは、サービスコンポーネントと関連した初期化情報を含む伝送パケットをさらに伝達することができる。これは、前述した初期化情報がメディアセグメントと共にＬＣＴセッションなどを介して伝達されることに該当し得る。初期化情報を含む伝送パケットは、伝送パケットのヘッダー情報を用いて識別されてもよい。前述したように、初期化情報は、パケットヘッダーのＴＯＩなどの情報を用いて識別されてもよい。
【１２６０】
本発明の一実施例に係るサービスデータを処理する方法を受信側で説明する。この方法は図示されていない。
【１２６１】
受信側にとって本発明の一実施例に係るサービスデータを処理する方法は、放送信号を受信し、放送信号をパーシングする段階、放送信号から第１シグナリングデータを取得し、これを用いて第２シグナリングデータを得る段階、第２シグナリングデータを用いて当該サービスのサービスコンポーネントを得る段階、及び／又は、当該サービスコンポーネントを用いてサービスを提供する段階を含むことができる。
【１２６２】
受信側でサービスデータを処理する方法は、送信側におけるモジュールに対応する受信側ハードウェアモジュール（例えば、受信モジュール、パーシングモジュール、再生モジュールなど）によって行うことができる。受信側でサービスデータを処理する方法は、前述した送信側におけるサービスデータを処理する方法の実施例に対応する実施例を有することができる。
【１２６３】
前述した段階は、実施例によって、省略されたり、類似／同一の動作を行う他の段階に代えてもよい。
【１２６４】
図１２８は、本発明の一実施例に係る、サービスデータを処理する装置を示す図である。
【１２６５】
本発明の一実施例に係るサービスデータを処理する装置は、前述した第１モジュール、第２モジュール、第３モジュール及び／又は第４モジュールを含むことができる。それぞれのブロック、モジュールは、前述したとおりである。
【１２６６】
本発明の一実施例に係るサービスデータを処理する装置及びその内部モジュール／ブロックは、前述した本発明のサービスデータを処理する方法の実施例を実行することができる。
【１２６７】
本発明の一実施例に係るサービスデータを処理する、受信側における装置を説明する。本発明の一実施例に係る受信側における装置は図示されていない。
【１２６８】
本発明の一実施例に係るサービスデータを処理する、受信側における装置は、前述した受信側ハードウェアモジュールを含むことができる。それぞれのブロック、モジュールは、前述したとおりである。
【１２６９】
本発明の一実施例に係るサービスデータを処理する受信側における装置は、前述した本発明のサービスデータを処理する方法の実施例を実行することができる。
【１２７０】
前述した装置内部のブロック／モジュールなどは、メモリに記憶された連続した実行過程を行うプロセッサであってもよく、実施例によって、装置内／外部に位置するハードウェアエレメントであってもよい。
【１２７１】
ｑ前述したモジュールは、実施例によって省略されたり、類似／同一の動作を行う他のモジュールに代えてもよい。
【１２７２】
図１２９は、本発明の一実施例に係るＥＳＧブートストラップ情報を示す図である。
【１２７３】
本発明の一実施例は、次世代放送網で使用可能なＥＳＧブートストラッピングディスクリプション（Ｂｏｏｔｓｔｒａｐｐｉｎｇ  Ｄｅｓｃｒｉｐｔｉｏｎ）のシグナリング方法を提供することができる。ＥＳＧブートストラッピングディスクリプションは、次のような情報を含み、当該情報は、シグナリング伝送ロケーションによって、バイナリフォーマット又はＸＭＬフォーマットの形態と定義されてもよい。
【１２７４】
Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＥＳＧ）データは、Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ  Ｄｅｌｉｖｅｒｙ  Ｕｎｉｔ（ＳＧＤＵ）及び／又はＳｅｒｖｉｃｅ  Ｇｕｉｄｅ  Ｄｅｌｉｖｅｒｙ  Ｄｅｓｃｒｉｐｔｏｒ（ＳＧＤＤ）を含むことができる。ＳＧＤＤは、ＳＧＤＵがどのデリバリー経路で伝送されるかに関する情報を含むことができる。ＳＧＤＵは、サービス及び／又はプログラムに関連した情報を含むことができる。例えば、ＳＧＤＵは、サービス情報、プログラム情報、チャネル番号、放送局情報、キャプション、放送等級、及び／又は詳細あらすじを含むことができる。サービス情報は、サービスの名前及び／又はサービスの識別子を含むことができる。プログラム情報は、プログラムの名前及び／又はプログラムの識別子、プログラム開始時間情報、及び／又はプログラム終了時間情報を含むことができる。ＳＧＤＵはフラグメント単位で構成され、フラグメントの種類は、サービスフラグメント、コンデンツフラグメント、及び／又はスケジュールフラグメントのうちで少なくとも一つを含むことができる。ＳＧＤＤ及びＳＧＤＵはいずれもＸＭＬファイルであってもよい。ＥＳＧは、Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＳＧ）及び／又はＥｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ（ＥＰＧ）と表現されてもよい。また、ＥＳＧ  ｄａｔａは簡略にＥＳＧと表現されてもよい。
【１２７５】
ＥＳＧブートストラッピングディスクリプションは、Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＥＳＧ）のブートストラッピングのための情報を含むことができる。ＥＳＧブートストラッピングディスクリプションは、ＥＳＧブートストラップ情報及び／又はＥＳＧのためのブートストラッピング情報と表現されてもよい。放送受信装置は、ＥＳＧブートストラッピングディスクリプション及び／又はＥＳＧブートストラップ情報に基づいてＥＳＧを受信、取得、及び／又は処理することができる。
【１２７６】
ＥＳＧブートストラッピングディスクリプションは、少なくとも一つのＳｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＳＧ）  Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔを含むことができる。
【１２７７】
ＳＧ  Ｐｒｏｖｉｄｅｒは、ＥＳＧと関連した情報を提供する提供者を示すことができる。ＳＧ  Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ｎａｍｅ  ａｔｔｒｉｂｕｔｅ及び／又は少なくとも一つのＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔを含むことができる。
【１２７８】
ｎａｍｅ  ａｔｔｒｉｂｕｔｅは、ＳＧ  Ｐｒｏｖｉｄｅｒの名前を示すことができる。
【１２７９】
Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは、少なくとも一つのブートストラップ情報を含むことができる。Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ、ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔ、ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔ、ｔｓｉ  ｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報であってもよい。
【１２８０】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが伝送されるタイプを示すことができる。具体的に、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるタイプを示すことができる。Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれたｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの個数は１つであってもよい。ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの属性値によって、Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは、以下に定義されたブートストラップ情報を選択的に含むことができる。参考として、「ＥＳＧブートストラッピングディスクリプションが伝送されるタイプ」は、「ＥＳＧ  ｄａｔａが伝送されるタイプ」と解釈されてもよい。具体的に、「ＥＳＧブートストラッピングディスクリプションが伝送されるタイプ」は「ＳＧＤＤが伝送されるタイプ」と解釈されてもよい。
【１２８１】
ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ、及び／又はＳＧ  ｄａｔａのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。例えば、ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧと関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰ  ｓｏｕｒｃｅ  ａｄｄｒｅｓｓを含むことができる。具体的に、ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＩＰ  ｓｏｕｒｃｅ  ａｄｄｒｅｓｓを示すことができる。
【１２８２】
ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ、及び／又はＳＧ  ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。例えば、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧと関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰ  ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓを含むことができる。具体的に、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＩＰ  ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓを示すことができる。
【１２８３】
ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ、及び／又はＳＧ  ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｒｔ番号を示すことができる。例えば、ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧと関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのポート番号を含むことができる。具体的に、ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｒｔ番号を示すことができる。
【１２８４】
ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、及び／又はｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａを伝送するＩＰパケットのヘッダーに記述された情報を意味する。
【１２８５】
ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ  Ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって、選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。具体的に、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送される伝送ストリーム識別子を示すことができる。
【１２８６】
ｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ  ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。例えば、パーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）は、放送会社を識別することができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって、選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。具体的に、ｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるパーティション識別子を示すことができる。
【１２８７】
ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧ  ｄａｔａがブロードキャストで伝送される場合、ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔは一つの値を含むことができる。具体的に、ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。
【１２８８】
外部周波数（Ｆｏｒｅｉｇｎ  ｆｒｅｑｕｅｎｃｙ）で伝送されるＥＳＧ  ｄａｔａの情報を知らせるために、Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは選択的に、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔ、及び／又はｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔを含むことができる。
【１２８９】
ｔｓｉ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧ  ｄａｔａがブロードキャストで伝送される場合、ｔｓｉ  ｅｌｅｍｅｎｔは、少なくとも一つの値を含むことができる。具体的に、ｔｓｉ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。
【１２９０】
ｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔは、ブロードバンドで伝送されるＥＳＧ  ｄａｔａに接近し得るＵＲＬを示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧ  ｄａｔａがブロードバンドで伝送される場合、ｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔは一つの値を含むことができる。具体的に、ｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＵＲＬを示すことができる。
【１２９１】
ＥＳＧ  ｄａｔａがブロードキャストで伝送されるか、それともブロードバンドで伝送されるかによって、Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔはｔｓｉ  ｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔは２つのうち少なくとも一つを含むことができる。
【１２９２】
放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。シグナリング情報は、ＥＳＧブートストラップ情報を含むことができる。放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。放送受信装置は、シグナリング情報に含まれたＥＳＧブートストラップ情報に基づいてＥＳＧデータを取得及び／又は処理することができる。
【１２９３】
図１３０は、本発明の一実施例に係るＥＳＧブートストラップ情報が伝送されるタイプを示す図である。
【１２９４】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅは、ＥＳＧ  ｄａｔａが伝送されるタイプを示すことができる。ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値は、固定された値ではなて、変更されてもよい。様々なタイプでＥＳＧ  ｄａｔａが伝送される場合、それぞれのｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅを有するＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔが複数個伝送されてもよい。
【１２９５】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値が「０ｘ０１」であれば、ＥＳＧ  ｄａｔａは、同一の周波数内でＡＴＳＣ ３．０ブロードキャストで伝送されてもよい。この場合、放送受信装置は、同一の周波数内でＥＳＧ  ｄａｔａを受信することができる。
【１２９６】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値が「０ｘ０２」であれば、ＥＳＧ  ｄａｔａは、他の周波数内でＡＴＳＣ ３．０ブロードキャストで伝送されてもよい。この場合、放送受信装置は、他の周波数内でＥＳＧ  ｄａｔａを受信することができる。
【１２９７】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値が「０ｘ０３」であれば、ＥＳＧ  ｄａｔａは、ＡＴＳＣ ３．０ブロードキャスト以外のＩＰブロードキャストで伝送されてもよい。この場合、放送受信装置は、ＩＰブロードキャストでＥＳＧ  ｄａｔａを受信することができる。
【１２９８】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値が「０ｘ０４」であれば、ＥＳＧ  ｄａｔａは、ブロードバンドで伝送されてもよい。この場合、放送受信装置は、ブロードバンドでＥＳＧ  ｄａｔａを受信することができる。
【１２９９】
図１３１は、本発明の第１実施例に係る、ＥＳＧブートストラップ情報のシグナリングを示す図である。
【１３００】
本発明の第１実施例は、次世代放送網でＥＳＧブートストラップ情報をＦＩＣのＥＳＧブートストラッピングディスクリプタ形態で伝送する方法を提供することができる。本発明の第１実施例では、ＥＳＧは放送サービスと定義されない。また、ＦＩＣは、Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ（ＳＬＴ）と呼ぶことができる。ＳＬＴは、基本的なサービスリストを樹立（ｂｕｉｌｄｉｎｇ）し、サービスレイヤシグナリング情報（ＳＬＳ）の発見をブートストラップするために用いられるシグナリング情報テーブルである。
【１３０１】
図面を参照すると、放送信号及び／又はアクチュアルストリームは、特定周波数の少なくとも一つの放送ストリームを含むことができる。例えば、アクチュアルストリーム（Ａｃｔｕａｌ  Ｓｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。
【１３０２】
それぞれの放送ストリームは、少なくとも一つのパーティションを含むことができる。それぞれのパーティションは、それぞれの放送会社に該当し得る。又は、それぞれのパーティションは、それぞれの放送会社で伝送する放送ストリームであってもよい。
【１３０３】
それぞれのパーティションは、少なくとも一つのＤＰ（又は、ＰＬＰ）及び／又はＦＩＣを含むことができる。例えば、第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰの識別子（ＤＰ  ＩＤ）は、「１」でもよい。第２ＤＰの識別子（ＤＰ  ＩＤ）は「２」であってもよい。第３ＤＰの識別子（ＤＰ  ＩＤ）は「３」であってもよい。
【１３０４】
一つのＤＰは一つのＲｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ（ＲＯＵＴＥ）セッションを含むことができる。また、複数のＤＰが一つのＲＯＵＴＥセッションを含むことができる。ＲＯＵＴＥセッションは少なくとも一つのサービス及び／又は少なくとも一つのコンポーネントを含むことができる。ＲＯＵＴＥセッションをＩＰ／ＵＤＰデータグラムと呼ぶこともできる。
【１３０５】
例えば、第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。すなわち、第１ＲＯＵＴＥセッションは第１ＤＰを介して送信される。第１ＲＯＵＴＥセッションは、第１ソースＩＰアドレス、第１デスティネーションＩＰアドレス、及び／又は第１ＵＤＰポート番号と特定されてもよい。第１ＲＯＵＴＥセッションは、第１サービス（Ａ／Ｖ  Ｓｅｒｖｉｃｅ）を含むことができる。
【１３０６】
第１ＲＯＵＴＥセッションは少なくとも一つの伝送セッション（又は、ＬＣＴセッション）を含むことができる。例えば、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。
【１３０７】
第１伝送セッション（ｔｓｉ−ｖ）はビデオコンポーネントを含むことができる。ビデオコンポーネントは、ビデオデータを含む少なくとも一つのビデオセグメントを含むことができる。第２伝送セッション（ｔｓｉ−ａ）は、オーディオコンポーネントを含むことができる。オーディオコンポーネントは、オーディオデータを含む少なくとも一つのオーディオセグメントを含むことができる。第３伝送セッション（ｔｓｉ−ｓ）はサービスシグナリングチャネルコンポーネントを含むことができる。サービスシグナリングチャネルコンポーネントは、Ｓｅｒｖｉｃｅ  Ｍａｐ  Ｔａｂｌｅ（ＳＭＴ）、Ｃｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ（ＣＭＴ）、Ｇｕｉｄｅ  Ａｃｃｅｓｓ  Ｔａｂｌｅ（ＧＡＴ）、及び／又はＤＡＳＨ  Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）のうち少なくとも一つを含むことができる。第４伝送セッション（ｔｓｉ−０）は、ＬＣＴ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）を含むことができる。ＬＳＩＤは、Ｓｅｒｖｉｃｅ−ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ（Ｓ−ＴＳＩＤ）と呼ぶことができる。Ｓ−ＴＳＩＤは、サービスの少なくとも一つのコンデンツコンポーネントを伝送する少なくとも一つの伝送セッションのための全体的なセッションディスクリプション情報を含むことができる。
【１３０８】
第２ＤＰ及び第３ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。すなわち、第２ＲＯＵＴＥセッションは、第２ＤＰ及び／又は第３ＤＰを介して送信される。第２ＲＯＵＴＥセッションは、第２ソースＩＰアドレス、第２デスティネーションＩＰアドレス、及び／又は第２ＵＤＰポート番号と特定されてもよい。
【１３０９】
第２ＲＯＵＴＥセッションは、少なくとも一つの伝送セッション（又は、ＬＣＴセッション）を含むことができる。例えば、第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−１０１）、及び／又は第７伝送セッション（ｔｓｉ−１０２）を含むことができる。伝送セッション（又は、ＬＣＴセッション）は、少なくとも一つの伝送オブジェクトを含むことができる。
【１３１０】
第５伝送セッション（ｔｓｉ−０）はＬＳＩＤを含むことができる。
【１３１１】
第６伝送セッション（ｔｓｉ−１０１）は、第１伝送オブジェクト（ｔｏｉ−０）及び／又は第２伝送オブジェクト（ｔｏｉ−１）を含むことができる。第１伝送オブジェクト（ｔｏｉ−０）は、ファイルデリバリーセッション内で伝送されるファイル及び／又はファイルの伝送と関連した属性を提供するＦｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ（ＦＤＴ）を含むことができる。又は、第１伝送オブジェクト（ｔｏｉ−０）は、ファイルデリバリーデータの細部内容を明示するＥＦＤＴを含むことができる。第２伝送オブジェクト（ｔｏｉ−１）は、Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ  Ｄｅｌｉｖｅｒｙ  Ｕｎｉｔ（ＳＧＤＵ）がどのデリバリー経路で伝送されるかに関する情報を記述するＳｅｒｖｉｃｅ  Ｇｕｉｄｅ  Ｄｅｌｉｖｅｒｙ  Ｄｅｓｃｒｉｐｔｏｒ（ＳＧＤＤ）を含むことができる。
【１３１２】
第７伝送セッション（ｔｏｉ−１０２）は、第３伝送オブジェクト（ｔｏｉ−０）、第４伝送オブジェクト（ｔｏｉ−１）、及び／又は第５伝送オブジェクト（ｔｏｉ−２）を含むことができる。第３伝送オブジェクト（ｔｏｉ−０）は、ＦＤＴ及び／又はＥＦＤＴを含むことができる。第４伝送オブジェクト（ｔｏｉ−１）は、ＳＧＤＵを含むことができる。第５伝送オブジェクト（ｔｏｉ−２）はＳＧＤＵを含むことができる。ＳＧＤＵはフラグメント単位で構成され、フラグメントの種類は、サービスフラグメント、コンデンツフラグメント、及び／又はスケジュールフラグメントのうち少なくとも一つを含むことができる。ＳＧＤＵはＥＳＧデータを含むことができる。ＳＧＤＤ及びＳＧＤＵはいずれもＸＭＬファイルであってもよい。
【１３１３】
放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３１４】
放送伝送装置は、ＦＩＣを含む放送信号を伝送することができる。
【１３１５】
ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ  ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。
【１３１６】
ＳＳＣブートストラップ情報（ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）は、ＳＭＴ及び／又はＣＭＴが伝送されるＳｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ（ＳＳＣ）と関連した情報を含むことができる。本発明の第１実施例では、ＥＳＧは別途の一つのサービスと定義されないことから、ＦＩＣはサービスループ（Ｓｅｒｖｉｃｅ  Ｌｏｏｐ）においてＳＳＣブートストラップ情報を含まなくてもよい。
【１３１７】
本発明の第１実施例に係るＦＩＣは、ＥＳＧブートストラップ情報をパーティションレベルのディスクリプタ形態で含むことができる。
【１３１８】
ＥＳＧブートストラップ情報は、前述したＥＳＧブートストラップ情報及び／又はＥＳＧブートストラップディスクリプションと同じ情報を含むことができる。例えば、ＥＳＧブートストラップ情報は、ｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔ及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔを含むことができる。
【１３１９】
ｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、プロバイダーの数を示すことができる。
【１３２０】
Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、提供者に関する情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。また、Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、前述したＳＧ  Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔを示すことができる。それぞれのＰｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ、ｔｓｉ  ａｔｔｒｉｂｕｔｅ、ＤＰ  ａｔｔｒｉｂｕｔｅ、及び／又はＵＲＬ  ａｒｒｔｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１３２１】
ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅは、ＥＳＧ  ｄａｔａが伝送されるタイプを示すことができる。ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅは、前述したｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅを示すことができる。
【１３２２】
ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅは、ＥＳＧ  ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ  Ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅは、前述したｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔを示すことができる。
【１３２３】
ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅは、ＥＳＧ  ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ  ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅは、前述したｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔを示すことができる。
【１３２４】
Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションを識別する情報を含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションブートストラップ情報は、ＲＯＵＴＥセッションの伝送経路情報を含むことができる。例えば、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ）ａｔｔｒｉｂｕｔｅ及び／又はｐｏｒｔ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ＩＰ（ｓｒｃ／ｄｅｓｔ）ａｔｔｒｉｂｕｔｅは、前述したｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ及びｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔを含むことができる。ｐｏｒｔ  ａｔｔｒｉｂｕｔｅは、前述したｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔを示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、及びｐｏｒｔ  ｅｌｅｍｅｎｔの組合せは、特定ＲＯＵＴＥセッションを識別することができる。
【１３２５】
ｔｓｉ  ａｔｔｒｉｂｕｔｅは、ＥＳＧ  ｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。例えば、ｔｓｉ  ａｔｔｒｉｂｕｔｅはＳＧＤＤが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。図面を参照すると、例えば、ｔｓｉ  ａｔｔｒｉｂｕｔｅの値は、「ｔｓｉ−１０１」であってもよい。
【１３２６】
ＤＰ  ａｔｔｒｉｂｕｔｅは、ＥＳＧ  ｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。ＤＰ  ａｔｔｒｉｂｕｔｅは、前述したｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔを示すことができる。例えば、ＤＰ  ａｔｔｒｉｂｕｔｅは、ＳＧＤＤが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。図面を参照すると、例えば、ＤＰ  ａｔｔｒｉｂｕｔｅの値は「２」であってもよい。
【１３２７】
ＵＲＬ  ａｒｒｔｉｂｕｔｅは、ブロードバンドで伝送されるＥＳＧ  ｄａｔａに接近し得るＵＲＬを示すことができる。ＵＲＬ  ａｒｒｔｉｂｕｔｅは、前述したｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔを示すことができる。
【１３２８】
本発明の第１実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。
【１３２９】
放送伝送装置は、ＬＳＩＤを含む放送信号を伝送することができる。
【１３３０】
例えば、第５伝送セッション（ｔｓｉ−０）に含まれたＬＳＩＤは、第６伝送セッションに関する情報を含む第６伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。
【１３３１】
それぞれの第６伝送セッションエレメント（ＴＳＩ−１０１）及び第７伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションが伝送されるＤＰを識別するＤＰ  ａｔｔｒｉｂｕｔｅ、伝送セッションに含まれるソースフローに関する情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアフローに関する情報を提供するＲｅｐａｉｒＦｌｏｗエレメントのうち少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するか否かを示すｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間伝送されることを示すことができる。また、例えば、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間伝送されることを示すことができる。
【１３３２】
放送受信装置は、ＳＧＤＤを用いて第７伝送セッションエレメント（ＴＳＩ−１０２）を取得することができるが、当該伝送セッションで伝送されるＳＧＤＵのＤＰ情報を得ることができない場合がある。したがって、本発明の第１実施例に係る放送伝送装置は、ＤＰ情報を含むＬＳＩＤを伝送することができる。
【１３３３】
放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３３４】
放送受信装置は、ＦＩＣを取得することができる。ＦＩＣは、ＩＰ／ＵＤＰパケットで伝送されてもよい。
【１３３５】
放送受信装置は、ＦＩＣに基づいてＥＳＧブートストラップ情報及び／又はＬＳＩＤを取得することができる。放送受信装置は、ＦＩＣのパーティションレベルディスクリプタに基づいてＥＳＧブートストラップ情報を取得することができる。ＥＳＧブートストラップ情報は、ＦＩＣでパーティションレベルディスクリプタの形態で含まれてもよい。本発明の第１実施例では、ＥＳＧを別途の一つのサービスと定義しないことからせ、ＦＩＣはサービスループ（Ｓｅｒｖｉｃｅ  Ｌｏｏｐ）でＳＳＣブートストラップ情報を含まなくてもよい。ＬＳＩＤは、それぞれの伝送セッション別に伝送Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むことができる。また、放送受信装置は、ＥＳＧブートストラップ情報に含まれたＲＯＵＴＥセッションブートストラップ情報に基づいてＬＳＩＤを取得することができる。この場合、ＬＳＩＤは、あらかじめ定められた伝送セッションを介して伝送されてもよく、放送受信装置は、ＲＯＵＴＥセッションブートストラップ情報及び／又はあらかじめ定められた伝送セッション情報に基づいてＬＳＩＤを取得することができる。又は、放送受信装置は、ＦＩＣに含まれた別途のＬＳＩＤ伝送経路情報に基づいてＬＳＩＤを取得することができる。
【１３３６】
放送受信装置は、ＥＳＧブートストラップ情報及び／又はＬＳＩＤに基づいてＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。
【１３３７】
本発明の第１実施例に係る放送伝送装置がＥＳＧ  Ａｎｎｏｕｎｃｅｍｅｎｔ  Ｃｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。
【１３３８】
また、本発明の第１実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ ３．０ Ｐｒｏｆｉｌｅを追加して、Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ  Ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。
【１３３９】
図１３２は本発明の第２実施例に係る、ＥＳＧブートストラップ情報のシグナリングを示す図である。
【１３４０】
本発明の第２実施例は、次世代放送網でＥＳＧブートストラッピング情報をＦＩＣのＥＳＧブートストラッピングディスクリプタ形態で伝送する方法を提供することができる。本発明の第２実施例では、ＥＳＧは一つの放送サービスと定義されてもよい。また、ＦＩＣのサービスループ（ｓｅｒｖｉｃｅ  ｌｏｏｐ）内でＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙ  ｅｌｅｍｅｎｔは、当該サービスがＥＳＧサービスであることを示すことができる。放送受信装置は、ＥＳＧブートストラップ情報をＦＩＣからＥＳＧブートストラッピングディスクリプタ形態で受信することができる。また、放送受信装置は、ＥＳＧブートストラップ情報を用いてＥＳＧを取得することができる。
【１３４１】
同図を参照すると、本発明の第２実施例に係るアクチュアルストリーム（Ａｃｔｕａｌ  Ｓｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは、第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、第１サービス（Ａ／Ｖ  Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。第２ＤＰ及び第３ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは、第２サービスを含むことができる。例えば、第２サービスは、ＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−１０１）、及び／又は第７伝送セッション（ｔｓｉ−１０２）を含むことができる。本発明の第２実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。同図に示したアクチュアルストリーム（Ａｃｔｕａｌ  Ｓｔｒｅａｍ）に関する内容は、前述したアクチュアルストリーム（Ａｃｔｕａｌ  Ｓｔｒｅａｍ）に関する内容を全て含むことができる。
【１３４２】
放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータは、ＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３４３】
放送伝送装置は、ＦＩＣを含む放送信号を伝送することができる。
【１３４４】
ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ  ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。ＳＳＣ  ＩＰ／Ｐｏｒｔエレメントは、ＳＳＣを伝送するｓｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ、及び／又はＵＤＰ  Ｐｏｒｔ  ｎｕｍｂｅｒを含むことができる。
【１３４５】
ＳＧＤＤが伝送される伝送セッションは、ＬＳＩＤが伝送される伝送セッションと異なってもよい。この場合、ＳＳＣブートストラップ情報（ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）は、ＥＳＧブートストラッピング情報に置き換えられてもよい。例えば、ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ ３．０  Ｂｒｏａｄｃａｓｔで伝送されるＥＳＧ  ｄａｔａを識別するＥＳＧブートストラップ情報であってもよい。この場合、ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣに関連した情報を含まなくてもよい。ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントがＥＳＧブートストラップ情報を含むという内容は、ＦＩＣのＳｅｍａｎｔｉｃｓに含まれてもよい。ＥＳＧブートストラップ情報は、ＥＳＧ  ｄａｔａ及び／又はＳＧＤＤが伝送される経路を識別する情報であってもよい。また、ＦＩＣは、ＳＳＣ及び／又はＬＳＩＤのブートストラップ情報及び／又は伝送経路に関する情報を別途にさらに含むことができる。また、ＳＳＣ及び／又はＬＳＩＤは、あらかじめ定義された特定の伝送セッションを介して伝送されてもよい。
【１３４６】
ＳＧＤＤが伝送される伝送セッションは、ＬＳＩＤが伝送される伝送セッションと同一であってもよい。すなわち、ＬＳＩＤはＳＧＤＤを含むことができる。この場合、ＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に該当し得る。すなわち、ＳＳＣブートストラップ情報及び／又はＥＳＧブートストラッピング情報は、ＳＳＣ、ＬＳＩＤ、ＥＳＧ  ｄａｔａ、及び／又はＳＧＤＤを識別することができる。例えば、ＳＳＣ  ＩＰ／Ｐｏｒｔエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧ  ｄａｔａ、及び／又はＳＧＤＤを伝送するＩＰ／Ｐｏｒｔを識別することができる。ＳＳＣ  ＤＰ＿ＩＤエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧ  ｄａｔａ、及び／又はＳＧＤＤを伝送するＤＰを識別することができる。ＴＳＩエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧ  ｄａｔａ、及び／又はＳＧＤＤを伝送する伝送セッションを識別することができる。ＳＳＣ  ＩＰ／Ｐｏｒｔエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧ  ｄａｔａ、及び／又はＳＧＤＤを伝送するｓｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ、及び／又はＵＤＰ  Ｐｏｒｔ  ｎｕｍｂｅｒを含むことができる。この場合にも、ＳＳＣ及び／又はＬＳＩＤは、あらかじめ定義された特定の伝送セッションを介して伝送されてもよい。
【１３４７】
また、ＦＩＣのパーティションレベルのディスクリプタは、追加的なＥＳＧブートストラップ情報をさらに含むことができる。例えば、パーティションレベルのディスクリプタに含まれるＥＳＧブートストラップ情報は、ｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔ及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔを含むことができる。例えば、Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、提供者に関する情報を含むことができる。また、Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔはｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅ、Ｓｅｒｖｉｃｅ  ＩＤ  ａｔｔｒｉｂｕｔｅ、及び／又はＵＲＬ  ａｒｒｔｉｂｕｔｅのうち少なくとも一つを含むことができる。Ｓｅｒｖｉｃｅ  ＩＤ  ａｔｔｒｉｂｕｔｅは、サービスを識別することができる。ＥＳＧブートストラップ情報に含まれるエレメント及び属性に関する内容は、前述した内容と同一である。
【１３４８】
本発明の第２実施例に係るＥＳＧは、一つのサービスと定義されてもよい。また、ＦＩＣサービスループ（Ｓｅｒｖｉｃｅ  Ｌｏｏｐ）内のＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報として活用されてもよい。
【１３４９】
これによって、ＦＩＣのサービスループ（Ｓｅｒｖｉｃｅ  ｌｏｏｐ）内のＳＳＣブートストラップ情報に対するｓｅｍａｎｔｉｃｓ定義時に別途の定義方案が必要であるが、ＦＩＣのサイズ増加を当該情報長さ分だけ減らすことができるという長所がある。ＳＳＣブートストラップ情報を用いて表現できないｎｅｔｗｏｒｋ  ｔｙｐｅで伝送されるＥＳＧブートストラップ情報は、パーティションレベル（ｐａｒｔｉｔｉｏｎ  ｌｅｖｅｌ）のディスクリプタで別途の情報を伝送するようにする。
【１３５０】
本発明の第２実施例に係るＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。
【１３５１】
放送伝送装置は、ＬＳＩＤを含む放送信号を伝送することができる。
【１３５２】
例えば、第５伝送セッション（ｔｓｉ−０）に含まれたＬＳＩＤは、第６伝送セッションに関する情報を含む第６伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。本発明の第２実施例に係るＬＳＩＤは、前述したＬＳＩＤに関する内容を全て含むことができる。
【１３５３】
放送受信装置は、ＳＧＤＤを用いて第７伝送セッションエレメント（ＴＳＩ−１０２）を取得することができるが、当該伝送セッションで伝送されるＳＧＤＵのＤＰ情報を得ることができない場合がある。したがって、本発明の第１実施例に係る放送伝送装置は、ＤＰ情報を含むＬＳＩＤを伝送することができる。
【１３５４】
放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。
【１３５５】
放送受信装置はＦＩＣを取得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されてもよい。
【１３５６】
放送受信装置は、ＦＩＣに基づいてＳＳＣブートストラップ情報及び／又はＥＳＧブートストラップ情報を取得することができる。ＦＩＣはＥＳＧブートストラップ情報を含むことができる。
【１３５７】
ＳＧＤＤが伝送される伝送セッションが、ＬＳＩＤが伝送される伝送セッションと異なる場合、ＦＩＣのＳＳＣブートストラップ情報（ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）は、ＥＳＧブートストラッピング情報に置き換えられてもよい。また、ＦＩＣは、ＳＳＣ及び／又はＬＳＩＤをブートストラップ及び／又は識別する別途の情報をさらに含むことができる。
【１３５８】
ＳＧＤＤが伝送される伝送セッションが、ＬＳＩＤが伝送される伝送セッションと同一である場合、ＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に該当し得る。すなわち、ＳＳＣブートストラップ情報及び／又はＥＳＧブートストラッピング情報は、ＳＳＣ、ＬＳＩＤ、ＥＳＧ  ｄａｔａ、及び／又はＳＧＤＤを識別することができる。以下では、ＳＧＤＤが伝送される伝送セッションが、ＬＳＩＤが伝送される伝送セッションと同一である場合を中心に説明する。
【１３５９】
また、ＦＩＣのパーティションレベルのディスクリプタは、追加的なＥＳＧブートストラップ情報をさらに含むことができる。ＬＳＩＤは、それぞれの伝送セッション別に伝送Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むことができる。
【１３６０】
放送受信装置はＦＩＣに基づいてＬＳＩＤを取得することができる。例えば、放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＬＳＩＤを取得することができる。
【１３６１】
また、放送受信装置は、ＦＩＣに基づいてＥＳＧブートストラップ情報を取得することができる。例えば、ＦＩＣのＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に該当し得る。
【１３６２】
放送受信装置は、ＥＳＧブートストラップ情報及び／又はＬＳＩＤに基づいてＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。
【１３６３】
本発明の第２実施例に係る放送伝送装置がＥＳＧ  Ａｎｎｏｕｎｃｅｍｅｎｔ  Ｃｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。
【１３６４】
また、本発明の第２実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ ３．０  Ｐｒｏｆｉｌｅを追加して、Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ  Ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。
【１３６５】
図１３３は、本発明の第３実施例に係るＥＳＧブートストラッピングディスクリプションのシグナリングを示す図である。
【１３６６】
本発明の第３実施例は、次世代放送網でＥＳＧブートストラップ情報をＳＭＴのＲＯＵＴＥセッションエレメントを用いて伝送する方法を提供することができる。ＥＳＧは、一つの別途のＳｅｒｖｉｃｅと定義されてもよい。ＦＩＣのサービスループ（Ｓｅｒｖｉｃｅ  Ｌｏｏｐ）でＳｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを示すことができる。ＳＳＣチャネルを介してＳＭＴとＣＭＴが伝送されてもよい。ただし、ＳＭＴ  ｓｅｍａｎｔｉｃｓ定義を変更して定義するようにしなければならない。
【１３６７】
同図を参照すると、本発明の第３実施例に係るアクチュアルストリーム（Ａｃｔｕａｌ  Ｓｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは、第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、第１サービス（Ａ／Ｖ  Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。同図に示した第１ＲＯＵＴＥセッションに関する内容は、前述したＲＯＵＴＥセッションに関する内容を全て含むことができる。
【１３６８】
第２ＤＰ、第３ＤＰ、及び第４ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。
【１３６９】
第５伝送セッション（ｔｓｉ−０）はＬＳＩＤを含むことができる。
【１３７０】
第６伝送セッション（ｔｓｉ−ｓｓｃ）は、ＳＭＴ及び／又はＣｏｍｐｏｎｅｎｔ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ（ＣＭＴ）を含むことができる。
【１３７１】
第７伝送セッション（ｔｓｉ−１０１）は、第１伝送オブジェクト（ｔｏｉ−０）及び／又は第２伝送オブジェクト（ｔｏｉ−１）を含むことができる。第１伝送オブジェクトは、ＦＤＴ及び／又はＥＦＤＴを含むことができる。第２伝送オブジェクト（ｔｏｉ−１）は、ＳＧＤＤを含むことができる。
【１３７２】
第８伝送セッション（ｔｏｉ−１０２）は、第３伝送オブジェクト（ｔｏｉ−０）、第４伝送オブジェクト（ｔｏｉ−１）、及び／又は第５伝送オブジェクト（ｔｏｉ−２）を含むことができる。第３伝送オブジェクト（ｔｏｉ−０）は、ＦＤＴ及び／又はＥＦＤＴを含むことができる。第４伝送オブジェクト（ｔｏｉ−１）はＳＧＤＵを含むことができる。第５伝送オブジェクト（ｔｏｉ−２）はＳＧＤＵを含むことができる。ＳＧＤＵはＥＳＧデータを含むことができる。
【１３７３】
放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１３７４】
放送伝送装置は、ＦＩＣを含む放送信号を伝送することができる。
【１３７５】
ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ  ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。
【１３７６】
ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣブートストラップ情報であってもよい。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ ３．０  Ｂｒｏａｄｃａｓｔで伝送されるＳＳＣブートストラッピング情報であってもよい。本発明の第３実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。
【１３７７】
本発明の第３実施例に係るＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。
【１３７８】
放送伝送装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含む放送信号を伝送することができる。
【１３７９】
ＳＭＴは、ｓｅｒｖｉｃｅＩＤ  ｅｌｅｍｅｎｔ、ｃａｔｅｇｏｒｙ  ｅｌｅｍｅｎｔ、ｎｕｍ＿ｏｆ  ＬＳＩＤ  ｅｌｅｍｅｎｔ、少なくとも一つのＬＳＩＤ  ｅｌｅｍｅｎｔ、ｎｕｍ＿ｏｆ  Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔ、及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。
【１３８０】
ｓｅｒｖｉｃｅＩＤ  ｅｌｅｍｅｎｔは、サービスを識別することができる。
【１３８１】
ｃａｔｅｇｏｒｙ  ｅｌｅｍｅｎｔは、サービスのカテゴリーを識別することができる。例えば、サービスのカテゴリーはＥＳＧサービスを含むことができる。
【１３８２】
ｎｕｍ＿ｏｆ  ＬＳＩＤ  ｅｌｅｍｅｎｔは、ＬＳＩＤの数を示すことができる。ＬＳＩＤ  ｅｌｅｍｅｎｔは、ＬＳＩＤに関連した情報を含むことができる。
【１３８３】
ＬＳＩＤ  ｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。例えば、ＬＳＩＤ  ｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ（又は、ａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ）、及び／又はＵＲＬ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔ  ｅｌｅｍｅｎｔ、ｔｓｉ  ｅｌｅｍｅｎｔ、及び／又はＤＰ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。ＬＳＩＤ  ｅｌｅｍｅｎｔに含まれるエレメント及び／又は属性に関する内容は、前述した内容と同一である。また、たとえｅｌｅｍｅｎｔとａｔｔｒｉｂｕｔｅとの違いはあっても、含まれる情報は同一であってもよい。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションブートストラップ情報は、ＬＳＩＤの伝送経路に関する情報を含むことができる。
【１３８４】
ｎｕｍ＿ｏｆ  Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧに関連した情報を提供する提供者の数を示すことができる。Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、提供者に関連した情報を含むことができる。
【１３８５】
Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。また、Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ（又は、ａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ）、及び／又はＵＲＬ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔ  ｅｌｅｍｅｎｔ、ｔｓｉ  ｅｌｅｍｅｎｔ、及び／又はＤＰ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔに含まれるエレメント及び／又は属性に関する内容は、前述した内容と同一である。また、たとえｅｌｅｍｅｎｔとａｔｔｒｉｂｕｔｅとの違いはあっても、含まれる情報は同一であってもよい。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ又はａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。ＥＳＧブートストラップ情報は、ＥＳＧ  ｄａｔａの伝送経路に関する情報を含むことができる。例えば、ＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ及びｐｏｒｔ  ｅｌｅｍｅｎｔが第２ＲＯＵＴＥセッションを示し、ｔｓｉ  ｅｌｅｍｅｎｔの値が第５伝送セッション（ｔｓｉ−１０１）を示し、ＤＰ  ｅｌｅｍｅｎｔの値が第２ＤＰ（ＤＰ  ＩＤ＝２）を示すことができる。
【１３８６】
第５伝送セッションに含まれたＬＳＩＤは、第６伝送セッションに関する情報を含む第６伝送セッションエレメント（図示せず）、第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）、及び／又は第８伝送セッションに関する情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、ＳｏｕｒｃｅＦｌｏｗエレメント、及び／又はＲｅｐａｉｒＦｌｏｗエレメントのうち少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間伝送されることを示すことができる。
【１３８７】
ＣＭＴは、サービス内のコンポーネントデータの取得経路及び／又は伝送経路に関する情報を含むことができる。また、ＣＭＴは、ブロードバンドで伝送されるコンポーネントに関する情報を含むことができる。また、ＣＭＴは、他のブロードキャストストリームに存在するコンポーネントに関する情報を含むことができる。ＣＭＴに関連した内容は、前述したＣＭＴに関連した内容を全て含むことができる。例えば、ＣＭＴは、ｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ及び／又はｃｏｍｐ  ｅｌｅｍｅｎｔを含むことができる。ｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅはサービスを識別することができる。ｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅは、当該コンポーネントと関連したサービスを識別する識別子である。ｃｏｍｐ  ｅｌｅｍｅｎｔは、当該サービス内のコンポーネントに関連した情報を含むことができる。例えば、ｃｏｍｐ  ｅｌｅｍｅｎｔは、同一の放送ストリームを介して伝送されるコンポーネントに関連した情報、ブロードバンド網で伝送されるコンポーネント、及び／又は他の放送ストリームを介して伝送されるコンポーネントのうち少なくとも一つを含むことができる。ｃｏｍｐ  ｅｌｅｍｅｎｔは、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングされるｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションを識別するｔｓｉ  ａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送されるＤＰを識別するＤＰ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。放送受信装置は、ＣＭＴに基づいてサービスのコンポーネントを取得することができる。
【１３８８】
放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータは、ＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１３８９】
放送受信装置はＦＩＣを取得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されてもよい。
【１３９０】
放送受信装置は、ＦＩＣに基づいてＳＳＣブートストラップ情報を取得することができる。ＳＳＣは、ＳＭＴ及び／又はＣＭＴを含むことができる。
【１３９１】
放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを取得することができる。ＳＭＴは、ＬＳＩＤエレメント及び／又はＰｏｒｖｉｄｅｒエレメントのうち少なくとも一つを含むことができる。ＬＳＩＤエレメントは、ＲＯＵＴＥセッションエレメントを含むことができる。ＬＳＩＤエレメントのＲＯＵＴＥセッションエレメントは、ＬＳＩＤ伝送経路情報を含むことができる。ＰｏｒｖｉｄｅｒエレメントのＲＯＵＴＥセッションエレメントは、ＥＳＧブートストラップ情報を含むことができる。
【１３９２】
Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙがＥＳＧサービスを示す場合、ＳＭＴはＥＳＧブートストラップ情報を含むことができる。例えば、Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙがＥＳＧサービスを示す場合、ＳＭＴに記述されたＬＳＩＤ伝送経路情報は、ＥＳＧブートストラップ情報に置き換えられてもよい。これに限定されず、ＳＭＴは、ＬＳＩＤ伝送経路情報及び／又はＥＳＧブートストラップ情報を全て含むことができる。
【１３９３】
放送受信装置は、ＳＭＴに基づいてＬＳＩＤ及び／又はＥＳＧブートストラップ情報を取得することができる。Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙがＥＳＧサービスを示す場合、ＳＭＴに記述されたＬＳＩＤ伝送経路情報は、ＥＳＧブートストラップ情報に置き換えられてもよい。また、具体的に、ＳＭＴに含まれたＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔ  ｅｌｅｍｅｎｔ、ｔｓｉ  ｅｌｅｍｅｎｔ、及び／又はＤＰ  ｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報であってもよい。これに限定されず、ＲＯＵＴＥセッションエレメントは、ＬＳＩＤ及び／又はＥＳＧブートストラップ情報を全て含むことができ、放送受信装置は、ＳＭＴに基づいてＬＳＩＤ伝送経路情報及び／又はＥＳＧブートストラップ情報を全て取得することができる。
【１３９４】
放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを取得することができる。
【１３９５】
放送受信装置は、ＣＭＴに基づいてコンポーネントマッチング情報を取得することができる。例えば、ＣＭＴは、ＣｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅ、ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又はＤＰ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１３９６】
放送受信装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つに基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＣＭＴのｔｓｉ  ａｔｔｒｉｂｕｔｅに基づいて、ＬＳＩＤで記述する伝送セッションを取得し、これにマッピングされるＤＰ情報を取得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉ  ａｔｔｒｉｂｕｔｅ及び／又はＤＰ  ａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを取得することができる。例えば、実際コンポーネントは、ＥＳＧサービスのためのコンポーネントであってもよい。
【１３９７】
具体的に、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報のうち少なくとも一つに基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを取得することができる。その後、放送受信装置は、ＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを取得することができる。
【１３９８】
ＥＳＧデータも一つのファイルと定義することができるために、放送受信装置は、ＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅに基づいて、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置は、ｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅに基づいて、ＥＳＧサービスのためのＥＳＧデータを取得することができる。この場合、ＥＳＧサービスは、ＥＳＧデータを含むファイルで提供されてもよい。
【１３９９】
本発明の第３実施例に係る放送伝送装置がＥＳＧ  Ａｎｎｏｕｎｃｅｍｅｎｔ  Ｃｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントは、ＤＰ  ａｔｔｒｉｂｕｔｅを含むことができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。
【１４００】
また、本発明の第３実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ ３．０ Ｐｒｏｆｉｌｅを追加して、Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ  Ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。
【１４０１】
図１３４は、本発明の第４実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。
【１４０２】
本発明の第４実施例は、次世代放送網でＥＳＧブートストラップ情報をＳＭＴのサービスレベルディスクリプタを用いて伝送する方法を提供することができる。ＥＳＧは一つの別途のサービスと定義され、ＦＩＣのサービスループ（Ｓｅｒｖｉｃｅ  Ｌｏｏｐ）でＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示し、ＳＳＣチャネルを介してＳＭＴとＣＭＴが伝送されてもよい。ＥＳＧサービスにマッピングされるＳＭＴは、ＥＳＧブートストラップディスクリプタを含むことができ、ＥＳＧブートストラップディスクリプタは、サービスレベルディスクリプタと定義されてもよい。
【１４０３】
同図を参照すると、本発明の第４実施例に係るアクチュアルストリーム（Ａｃｔｕａｌ  Ｓｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／Ｖ  Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。同図に示した第１ＲＯＵＴＥセッションに関する内容は、前述した第１ＲＯＵＴＥセッションに関する内容を全て含むことができる。
【１４０４】
第２ＤＰ、第３ＤＰ、及び第４ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。同図に示した第２ＲＯＵＴＥセッションに関する内容は、前述した第２ＲＯＵＴＥセッションに関する内容を全て含むことができる。
【１４０５】
放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１４０６】
放送伝送装置は、ＦＩＣを含む放送信号を伝送することができる。
【１４０７】
ＦＩＣは、前述したＦＩＣに関連した内容を全て含むことができる。例えば、ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ  ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。
【１４０８】
ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣブートストラップ情報であってもよい。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ ３．０  Ｂｒｏａｄｃａｓｔで伝送されるＳＳＣブートストラッピング情報であってもよい。本発明の第４実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。
【１４０９】
本発明の第４実施例に係るＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。
【１４１０】
放送伝送装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含む放送信号を伝送することができる。
【１４１１】
ＳＭＴは、前述したＳＭＴに関連した内容を全て含むことができる。例えば、ＳＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ、サービスのカテゴリーを示すｃａｔｅｇｏｒｙ  ａｔｔｒｉｂｕｔｅ、ＲＯＵＴＥセッションに関する情報を含む少なくとも一つのＲＯＵＴＥセッションエレメント、及び／又は少なくとも一つのサービスレベルディスクリプタを含むことができる。ＲＯＵＴＥセッションエレメントは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションエレメントは、ＬＳＩＤブートストラップ情報（又は、ＬＳＩＤ伝送経路情報）を含むことができる。ｃａｔｅｇｏｒｙ  ａｔｔｒｉｂｕｔｅは、ＥＳＧサービスを示すことができる。
【１４１２】
サービスレベルディスクリプタは、ＥＳＧブートストラップ情報を含むことができる。本発明の第４実施例に係るＳｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを示すと、ＳＭＴは、ＥＳＧブートストラップ情報を含むサービスレベルのディスクリプタを含むことができる。放送伝送装置は、サービスレベルのディスクリプタを用いてＥＳＧブートストラップ情報を伝送することができる。
【１４１３】
ＬＳＩＤは、前述したＬＳＩＤに関連した内容を全て含むことができる。例えば、ＬＳＩＤは、第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第８伝送セッションに関する情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションに含まれるソースフローに関する情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアフローに関する情報を提供するＲｅｐａｉｒＦｌｏｗエレメントのうち少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するか否かを示すｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間伝送されることを示すことができる。また、例えば、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間伝送されることを示すことができる。
【１４１４】
ＣＭＴは、前述したＣＭＴに関連した内容を全て含むことができる。例えば、ＣＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ及び／又は、当該サービス内のコンポーネントに関する情報を含むｃｏｍｐ  ｅｌｅｍｅｎｔを含むことができる。ｃｏｍｐ  ｅｌｅｍｅｎｔは、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングされるｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションを識別するｔｓｉ  ａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送されるＤＰを識別するＤＰ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１４１５】
放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１４１６】
放送受信装置はＦＩＣを取得することができる。ＦＩＣは、ＩＰ／ＵＤＰパケットを介して伝送されてもよい。例えば、Ｓｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。また、ＦＩＣは、サービスループ内にＳＳＣブートストラップ情報を含むことができる。ＳＳＣはＳＭＴ及び／又はＣＭＴを含むことができる。
【１４１７】
放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを取得することができる。ＳＭＴは、少なくとも一つのＲＯＵＴＥセッションエレメント及び／又は少なくとも一つのサービスレベルディスクリプタを含むことができる。
【１４１８】
放送受信装置は、ＳＭＴに含まれたＲＯＵＴＥセッションエレメントに基づいてＬＳＩＤを取得することができる。ＲＯＵＴＥセッションエレメントは、ＲＯＵＴＥセッションブートストラップ情報を含むことができ、ＲＯＵＴＥセッションブートストラップ情報は、ＬＳＩＤ伝送経路情報を含むことができる。
【１４１９】
また、放送受信装置は、ＳＭＴに含まれたサービスレベルディスクリプタからＥＳＧブートストラップ情報を取得することができる。Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを示すと、ＳＭＴは、ＥＳＧブートストラップ情報を含むサービスレベルのディスクリプタを含むことができる。
【１４２０】
放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを取得することができる。放送受信装置は、ＣＭＴに基づいてコンポーネントマッチング情報を取得することができる。例えば、ＣＭＴは、ＣｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅ、ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又はＤＰ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１４２１】
放送受信装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つに基づいて  ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＣＭＴのｔｓｉ  ａｔｔｒｉｂｕｔｅに基づいて、ＬＳＩＤで記述する伝送セッションを取得し、これにマッピングされるＤＰ情報を取得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉ  ａｔｔｒｉｂｕｔｅ及び／又はＤＰ  ａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを取得することができる。例えば、実際コンポーネントは、ＥＳＧサービスのためのコンポーネントであってもよい。
【１４２２】
具体的に、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報のうち少なくとも一つに基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを取得することができる。その後、放送受信装置はＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを取得することができる。
【１４２３】
ＥＳＧデータも一つのファイルと定義することができるので、放送受信装置は、ＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅに基づいて、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置は、ｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅに基づいて、ＥＳＧサービスのためのＥＳＧデータを取得することができる。この場合、ＥＳＧサービスは、ＥＳＧデータを含むファイルで提供されてもよい。
【１４２４】
本発明の第４実施例に係る放送伝送装置がＥＳＧ  Ａｎｎｏｕｎｃｅｍｅｎｔ  Ｃｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントは、ＤＰ  ａｔｔｒｉｂｕｔｅを含むことができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。
【１４２５】
また、本発明の第４実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ ３．０ Ｐｒｏｆｉｌｅを追加して、Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａ  Ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。
【１４２６】
図１３５は、本発明の第５実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。
【１４２７】
本発明の第５実施例は、次世代放送網でＥＳＧブートストラップ情報をＧｕｉｄｅ  Ａｃｃｅｓｓ  Ｔａｂｌｅ（ＧＡＴ）を用いて伝送する方法を提供することができる。ＥＳＧは一つの別途のサービスと定義され、ＦＩＣのサービスループでサービスＳｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙはＥＳＧサービスを示し、ＳＳＣチャネルを介してＳＭＴ、ＧＡＴ、及び／又はＣＭＴが伝送されてもよい。ＥＳＧサービスにマッピングされるＳＭＴは、ＬＳＩＤが伝送されるＲＯＵＴＥセッション情報を含むことができる。本発明の第５実施例では、ＥＳＧサービスに対するＳＳＣはＧＡＴを含み、ＧＡＴはＥＳＧブートストラップ情報を含むことができる。
【１４２８】
同図を参照すると、本発明の第５実施例に係るアクチュアルストリーム（Ａｃｔｕａｌ  Ｓｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／Ｖ  Ｓｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。同図に示した第１ＲＯＵＴＥセッションに関する内容は、前述した第１ＲＯＵＴＥセッションに関する内容を全て含むことができる。
【１４２９】
第２ＤＰ、第３ＤＰ、及び第４ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。同図に示した第２ＲＯＵＴＥセッションに関する内容は、前述した第２ＲＯＵＴＥセッションに関する内容を全て含むことができる。
【１４３０】
放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１４３１】
放送伝送装置は、ＦＩＣを含む放送信号を伝送することができる。
【１４３２】
ＦＩＣは、前述したＦＩＣに関連した内容を全て含むことができる。例えば、ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣ  ＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。
【１４３３】
ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣブートストラップ情報であってもよい。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣ  ＩＰ／Ｐｏｒｔエレメント、ＳＳＣ  ＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ ３．０  Ｂｒｏａｄｃａｓｔで伝送されるＳＳＣブートストラッピング情報であってもよい。本発明の第５実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。
【１４３４】
本発明の第５実施例に係るＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。また、Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを示すと、ＧＡＴが必須に伝送されてもよい。
【１４３５】
放送伝送装置は、ＳＭＴ、ＣＭＴ、ＧＡＴ、及び／又はＬＳＩＤのうち少なくとも一つを含む放送信号を伝送することができる。
【１４３６】
ＳＭＴは、前述したＳＭＴに関連した内容を全て含むことができる。例えば、ＳＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ、ＲＯＵＴＥセッションに関する情報を含む少なくとも一つのＲＯＵＴＥセッションエレメントを含むことができる。ＲＯＵＴＥセッションエレメントは、ＲＯＵＴＥセッションブートストラップ情報（又は、ＬＳＩＤブートストラップ情報、ＬＳＩＤ伝送経路情報）を含むことができる。
【１４３７】
ＧＡＴは、サービスと関連したサービスガイド（Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ，ＳＧ）データソースに関する情報を含むことができる。例えば、ＧＡＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ、サービスガイド提供者の数を示すｎｕｍ＿ｏｆ＿ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔ、及び／又はサービスガイド提供者に関する情報を含む少なくとも一つのＰｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔ（サービスガイド提供者エレメント）を含むことができる。
【１４３８】
Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。また、ＥＳＧブートストラップ情報は、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ、及び／又はＵＲＬ  ａｒｒｔｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１４３９】
ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラッピングディスクリプションが伝送されるタイプを示すことができる。ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅは、前述したｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅを示すことができる。
【１４４０】
ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラップ情報が外部周波数（Ｆｏｒｅｉｇｎ  Ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。ｔｓ＿ＩＤ  ａｔｔｒｉｂｕｔｅは、前述したｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔを示すことができる。
【１４４１】
ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラップ情報が外部周波数（Ｆｏｒｅｉｇｎ  ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。ｐａｒｔｉｔｉｏｎＩＤ  ａｔｔｒｉｂｕｔｅは、前述したｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔを示すことができる。
【１４４２】
Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションを識別する情報を含むことができる。例えば、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔはＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔ  ｅｌｅｍｅｎｔ、ａｎｎｏｕｎｃｅｍｅｎｔ＿ｔｓｉ  ｅｌｅｍｅｎｔ、ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。ＩＰ（ｓｒｃ／ｄｅｓｔ）ａｔｔｒｉｂｕｔｅは、前述したｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ及びｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔを含むことができる。ｐｏｒｔ  ａｔｔｒｉｂｕｔｅは、前述したｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔを示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、及びｐｏｒｔ  ｅｌｅｍｅｎｔの組合せは、特定ＲＯＵＴＥセッションを識別することができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ｔｓｉ  ｅｌｅｍｅｎｔは、ＥＳＧサービス及び／又はＥＳＧブートストラップ情報が伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰ  ｅｌｅｍｅｎｔは、ＥＳＧサービス及び／又はＥＳＧブートストラップ情報が伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰ  ｅｌｅｍｅｎｔは、前述したｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔを示すことができる。
【１４４３】
ＵＲＬ  ｅｌｅｍｅｎｔは、ブロードバンドで伝送されるＥＳＧブートストラップ情報及び／又はＥＳＧのためのシグナリング情報に接近し得るＵＲＬを示すことができる。ＵＲＬ  ｅｌｅｍｅｎｔは、前述したｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔを示すことができる。
【１４４４】
ＣＭＴは、前述したＣＭＴに関連した内容を全て含むことができる。例えば、ＣＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ及び／又は、当該サービス内のコンポーネントに関する情報を含むｃｏｍｐ  ｅｌｅｍｅｎｔを含むことができる。ｃｏｍｐ  ｅｌｅｍｅｎｔは、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングされるｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションを識別するｔｓｉ  ａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送されるＤＰを識別するＤＰ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１４４５】
ＬＳＩＤは、前述したＬＳＩＤに関連した内容を全て含むことができる。例えば、ＬＳＩＤは、第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第８伝送セッションに関する情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションに含まれるソースフローに関する情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアフローに関する情報を提供するＲｅｐａｉｒＦｌｏｗエレメントのうち少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するか否かを示すｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間伝送されることを示すことができる。また、例えば、ｒｅａｌｔｉｍｅ  ａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間伝送されることを示すことができる。
【１４４６】
放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。
【１４４７】
放送受信装置はＦＩＣを取得することができる。ＦＩＣは、ＩＰ／ＵＤＰパケットを介して伝送されてもよい。例えば、Ｓｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。また、ＦＩＣはサービスループ内にＳＳＣブートストラップ情報を含むことができる。また、Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを示すと、ＧＡＴが必須に伝送されてもよい。
【１４４８】
放送受信装置はＦＩＣに基づいてＳＳＣブートストラップ情報を取得することができる。ＳＳＣは、ＳＭＴ、ＣＭＴ、及び／又はＧＡＴを含むことができる。
【１４４９】
放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを取得することができる。放送受信装置は、ＳＭＴに含まれたＲＯＵＴＥセッションエレメントに基づいて、ＲＯＵＴＥブートストラップ情報（又は、ＬＳＩＤブートストラップ情報、ＬＳＩＤ伝送経路情報）を取得することができる。また、放送受信装置はＳＭＴに基づいてＬＳＩＤを取得することができる。具体的に、放送受信装置はＳＭＴのＲＯＵＴＥブートストラップ情報に基づいてＬＳＩＤを取得することができる。
【１４５０】
放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＧＡＴを取得することができる。また、放送受信装置は、ＧＡＴからＥＳＧブートストラップ情報を取得することができる。
【１４５１】
放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを取得することができる。また、放送受信装置はＣＭＴに基づいてコンポーネントマッチング情報を取得することができる。例えば、ＣＭＴは、ＣｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅ、ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又はＤＰ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１４５２】
放送受信装置は、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つに基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＣＭＴのｔｓｉ  ａｔｔｒｉｂｕｔｅに基づいて、ＬＳＩＤで記述する伝送セッションを取得し、これにマッピングされるＤＰ情報を取得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉ  ａｔｔｒｉｂｕｔｅ及び／又はＤＰ  ａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを取得することができる。例えば、実際コンポーネントはＥＳＧサービスのためのコンポーネントであってもよい。
【１４５３】
具体的に、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報のうち少なくとも一つに基づいて、ＥＳＧ  ｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを取得することができる。その後、放送受信装置はＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを取得することができる。
【１４５４】
ＥＳＧデータも一つのファイルと定義することができるので、放送受信装置は、ＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅに基づいて、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置は、ｃｏｎｔｅｎｔＬｉｎｋａｇｅ  ａｔｔｒｉｂｕｔｅに基づいてＥＳＧサービスのためのＥＳＧデータを取得することができる。この場合、ＥＳＧサービスは、ＥＳＧデータを含むファイルで提供されてもよい。
【１４５５】
本発明の第５実施例に係る放送伝送装置がＥＳＧ  Ａｎｎｏｕｎｃｅｍｅｎｔ  Ｃｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントは、ＤＰ  ａｔｔｒｉｂｕｔｅを含むことができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａ  Ｐｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。
【１４５６】
また、本発明の第５実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ ３．０ Ｐｒｏｆｉｌｅを追加して、Ｄａｔａ  Ｐｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置はＳＧＤＤを受信て、ＳＧＤＤのＤａｔａ  Ｐｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。
【１４５７】
図１３６は、本発明の第５実施例に係るＧＡＴを示す図である。
【１４５８】
次世代放送網で使用可能なシグナリング情報のフォーマットは次のとおりである。シグナリング情報は、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。シグナリングメッセージは、ｂｉｎａｒｙ或いはＸＭＬフォーマットなどで）表現されてもよい。また、シグナリングメッセージは、ＩＰデータグラム又はアプリケーションレイヤ伝送パケット（例えば、ＲＯＵＴＥ或いはＭＭＴなど）のペイロードに含まれて伝送されてもよい。例えば、シグナリングメッセージはＧＡＴを含むことができる。
【１４５９】
シグナリングメッセージヘッダーは、Ｓｉｇｎａｌｉｎｇ＿ｉｄ  ｅｌｅｍｅｎｔ及び／又はＳｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ  ｅｌｅｍｅｎｔは、シグナリングメッセージの識別子を示すことができる。例えば、Ｓｉｇｎａｌｉｎｇ＿ｉｄ  ｅｌｅｍｅｎｔはＧＡＴシグナリングメッセージを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔはサービスの識別子を示すことができる。例えば、Ｓｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔはＥＳＧサービスを示すことができる。一方、ＳＭＴには、Ｓｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔにマッピングされる識別子が存在してもよい。
【１４６０】
ＧＡＴは、少なくとも一つのサービスレベルのディスクリプタを含むことができる。例えば、ＧＡＴはＥＳＧブートストラッピングディスクリプションを含むことができる。
【１４６１】
ＥＳＧブートストラッピングディスクリプションは、Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＥＳＧ）のブートストラッピングのための情報を含むことができる。ＥＳＧブートストラッピングディスクリプションは、ＥＳＧブートストラップ情報及び／又はＥＳＧのためのブートストラッピング情報を含むことができる。放送受信装置は、ＥＳＧブートストラッピングディスクリプション及び／又はＥＳＧブートストラップ情報に基づいてＥＳＧを受信、取得、及び／又は処理することができる。
【１４６２】
ＥＳＧブートストラッピングディスクリプションは、少なくとも一つのＳｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＳＧ）  Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔを含むことができる。
【１４６３】
ＳＧ  Ｐｒｏｖｉｄｅｒは、ＥＳＧと関連した情報を提供する提供者を示すことができる。ＳＧ  Ｐｒｏｖｉｄｅｒ  ｅｌｅｍｅｎｔは、ｎａｍｅ  ａｔｔｒｉｂｕｔｅ及び／又は少なくとも一つのＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔを含むことができる。
【１４６４】
ｎａｍｅ  ａｔｔｒｉｂｕｔｅは、ＳＧ  Ｐｒｏｖｉｄｅｒの名前を示すことができる。
【１４６５】
Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは、少なくとも一つのブートストラッピング情報を含むことができる。Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ、ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ、ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔ、ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔ、ｔｓｉ  ｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔはＥＳＧブートストラップ情報であってもよい。
【１４６６】
ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが伝送されるタイプを示すことができる。
【１４６７】
ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ、及び／又はＳＧ  ｄａｔａのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。例えば、ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧに関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰ  ｓｏｕｒｃｅ  ａｄｄｒｅｓｓを含むことができる。
【１４６８】
ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ、及び／又はＳＧ  ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すことができる。例えば、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧに関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰ  ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓを含むことができる。
【１４６９】
ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａ、及び／又はＳＧ  ｄａｔａのｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｒｔ番号を示すことができる。例えば、ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧに関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのポート番号を含むことができる。
【１４７０】
ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ  Ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。
【１４７１】
ｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが外部周波数（Ｆｏｒｅｉｇｎ  ｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。例えば、パーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）は放送会社を識別することができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。
【１４７２】
ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧ  ｄａｔａがブロードキャストで伝送される場合、ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔは一つの値を含むことができる。
【１４７３】
ｔｓｉ  ｅｌｅｍｅｎｔは、ＥＳＧ  ｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧ  ｄａｔａがブロードキャストで伝送される場合、ｔｓｉ  ｅｌｅｍｅｎｔは少なくとも一つの値を含むことができる。
【１４７４】
ｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔは、ブロードバンドで伝送されるＥＳＧ  ｄａｔａに接近し得るＵＲＬを示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧ  ｄａｔａがブロードバンドで伝送される場合、ｄｏｗｎｌｏａｄＵＲＬ  ｅｌｅｍｅｎｔは一つの値を含むことができる。
【１４７５】
放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。サービスデータはＥＳＧサービスを含むことができる。シグナリング情報はＧＡＴを含み、ＧＡＴはサービスレベルディスクリプタにＥＳＧブートストラップ情報を含むことができる。放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。放送受信装置は、シグナリング情報に含まれたＥＳＧブートストラップ情報に基づいてＥＳＧサービスを取得及び／又は処理することができる。
【１４７６】
図１３７は、本発明の第１実施例乃至第５実施例の効果を示す図である。
【１４７７】
本発明の第１実施例の効果について説明する。
【１４７８】
ＦＩＣ  Ｐｕｒｐｏｓｅ（Ｆａｓｔ  ｃｈａｎｎｅｌ  ｓｃａｎ）と関連して、本発明の第１実施例ではＦａｓｔ  Ｓｃａｎとは関係ない情報が反復的に伝送されてもよい。例えば、ＦＩＣはパーティションレベルのディスクリプタにＥＳＧブートストラップ情報を含むことができる。したがって、本発明の第１実施例ではＥＳＧブートストラップ情報が反復的に伝送されてもよい。
【１４７９】
ＦＩＣ  ｓｉｚｅと関連して、本発明の第１実施例では、ＥＳＧがサービスと定義されないので、サービスループ（ｓｅｒｖｉｃｅ  ｌｏｏｐ）から除外されるサイズ分だけＦＩＣのサイズを節約することができる。例えば、サービスループでＳＳＣブートストラップ情報が除外されるサイズだけＦＩＣのサイズを節約することができる。また、ＥＳＧブートストラップ情報分だけＦＩＣのサイズを増加させることができる。
【１４８０】
ＦＩＣ  ｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第１実施例では、ＥＳＧがサービスと定義されないので、ＦＩＣ  ｓｅｍａｎｔｉｃｓ定義は明確である。例えば、サービスループにはＥＳＧブートストラップ情報が含まれず、パーティションレベルのディスクリプタにＥＳＧブートストラップ情報が含まれる。
【１４８１】
ＥＳＧブートストラップ情報取得時間と関連して、本発明の第１実施例ではＥＳＧブートストラップ情報が変更する度にＦＩＣも継続して変更される。したがって、本発明の第１実施例では、ＦＩＣに含まれたＥＳＧブートストラップ情報を速かに取得することができる。
【１４８２】
明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第１実施例ではＥＳＧがサービスと定義されないので、ＦＩＣ  ｓｅｍａｎｔｉｃｓ定義は明確である。
【１４８３】
ＬＳＩＤの拡張と関連して、本発明の第１実施例では、ＤＰ情報のマッピングのためにＬＳＩＤにＴＳＩとＤＰのマッピングに関する定義が必要である。
【１４８４】
一貫性と関連して、本発明の第１実施例では、ＦＩＣは一貫性を維持し、ＳＳＣは存在しなくてもよい。
【１４８５】
本発明の第２実施例の効果について説明する。
【１４８６】
ＦＩＣ  Ｐｕｒｐｏｓｅ（Ｆａｓｔ  ｃｈａｎｎｅｌ  ｓｃａｎ）と関連して、本発明の第２実施例では、Ｆａｓｔ  Ｓｃａｎとは関係ない情報が反復的に伝送されてもよい。例えば、ＦＩＣは、サービスループのＳＳＣブートストラップ情報がＥＳＧブートストラップ情報に置き換えられてもよい。又は、ＳＳＣブートストラップ情報がＥＳＧブートストラップ情報に該当してもよい。したがって、本発明の第２実施例ではＥＳＧブートストラップ情報が反復的に伝送されてもよい。
【１４８７】
ＦＩＣ  ｓｉｚｅと関連して、本発明の第２実施例では、ＦＩＣがＥＳＧブートストラップ情報のためにｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｒｔ  ｎｕｍｂｅｒ、ＴＳＩ情報、及び／又はＤＰ情報などを含む場合にはＦＩＣのサイズが増加しない。しかし、ＦＩＣがＥＳＧブートストラップ情報のために外部周波数（ｆｏｒｅｉｇｎ  ｆｒｅｑｕｅｎｃｙ）のブロードキャスト情報及びブロードバンド情報を含む場合にはＦＩＣのサイズが増加しうる。
【１４８８】
ＦＩＣ  ｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第２実施例では、Ｓｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙ別にＳＳＣの用途が変更されてもよい。例えば、Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙがＥＳＧサービスを示すと、ＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に置き換えられてもよい。又は、ＳＳＣブートストラップ情報がＥＳＧブートストラップ情報に該当してもよい。Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙがＥＳＧサービスを示すと、ＳＳＣブートストラップ情報は、本来の目的に用いられてもよい。
【１４８９】
ＥＳＧブートストラップ情報取得時間と関連して、本発明の第２実施例では、ＥＳＧブートストラップ情報が変更される度にＦＩＣも継続して変更される。したがって、本発明の第２実施例では、ＦＩＣに含まれたＥＳＧブートストラップ情報を速かに取得することができる。
【１４９０】
明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第２実施例では、Ｓｅｒｖｉｃｅ  ＣａｔｅｇｏｒｙによるＳＳＣブートストラップ情報の定義が変更されてもよい。また、本発明の第２実施例では、シグナリング情報はＳＭＴ及び／又はＣＭＴを含まなくてもよい。
【１４９１】
ＬＳＩＤの拡張と関連して、本発明の第２実施例では、ＤＰ情報のマッピングのために、ＬＳＩＤにＴＳＩとＤＰのマッピングに関する定義が必要である。
【１４９２】
一貫性と関連して、本発明の第２実施例では、サービスがＳｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙで分類されるにもかかわらず、シグナリング情報にＳＭＴ及び／又はＣＭＴが含まれなくてもよい。
【１４９３】
本発明の第３実施例の効果について説明する。
【１４９４】
ＦＩＣ  ｓｉｚｅと関連して、本発明の第３実施例では、ＥＳＧサービスのためのＦＩＣのサイズはＡ／ＶサービスのためのＦＩＣのサイズと同一であってもよい。
【１４９５】
ＦＩＣ  ｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第３実施例では、ＦＩＣはＳＳＣが伝送される情報を示すＳＳＣブートストラップ情報を含むことができる。
【１４９６】
ＥＳＧブートストラップ情報取得時間と関連して、本発明の第３実施例では、ＥＳＧブートストラップ情報はＦＩＣに含まれず、第１実施例及び第２実施例に比べはＥＳＧブートストラップ情報の取得が遅い。
【１４９７】
サービスシグナリング帯域幅（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｂａｎｄｗｉｄｔｈ）と関連して、本発明の第３実施例では、ＳＭＴを頻繁に伝送しなければならないという点を考慮すると、ＥＳＧブートストラップ情報をディスクリプタに含める場合、シグナリング帯域幅（Ｓｉｇｎａｌｉｎｇ  Ｂａｎｄｗｉｄｔｈ）側面で効率性はやや低下しうる。
【１４９８】
明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第３実施例では、ＳＭＴのＬＳＩＤ伝送情報に対する定義と提供者（Ｐｒｏｖｉｄｅｒ）に対する定義を区別しなければならない。
【１４９９】
ＬＳＩＤの拡張と関連して、本発明の第３実施例では、ＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要である。ＣＭＴは、ＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。
【１５００】
本発明の第４実施例の効果について説明する。
【１５０１】
ＦＩＣ  ｓｉｚｅと関連して、本発明の第４実施例では、ＥＳＧサービスのためのＦＩＣのサイズはＡ／ＶサービスのためのＦＩＣのサイズと同一であってもよい。
【１５０２】
ＦＩＣ  ｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第４実施例では、ＦＩＣはＳＳＣが伝送される情報を示すＳＳＣブートストラップ情報を含むことができる。
【１５０３】
ＥＳＧブートストラップ情報取得時間と関連して、本発明の第４実施例では、ＥＳＧブートストラップ情報はＦＩＣに含まれず、第１実施例及び第２実施例に比べてはＥＳＧブートストラップ情報の取得が遅い。ただし、本発明の第４実施例に係るＥＳＧブートストラップ情報取得時間は、本発明の第３実施例に係るＥＳＧブートストラップ情報取得時間とは同一であってもよい。
【１５０４】
サービスシグナリング帯域幅（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｂａｎｄｗｉｄｔｈ）と関連して、本発明の第４実施例では、ＳＭＴを頻繁に伝送しなければならないという点を考慮すると、ＥＳＧブートストラップ情報をディスクリプタに含める場合、シグナリング帯域幅（Ｓｉｇｎａｌｉｎｇ  Ｂａｎｄｗｉｄｔｈ）側面で効率性はやや低下しうる。
【１５０５】
明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第４実施例では、ＦＩＣはＳＳＣブートストラップ情報を含み、ＳＭＴはＥＳＧブートストラップ情報を含むので、明確なＳｅｍａｎｔｉｃｓ定義が可能である。
【１５０６】
ＬＳＩＤの拡張と関連して、本発明の第４実施例ではＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要である。ＣＭＴは、ＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。
【１５０７】
一貫性と関連して、本発明の第４実施例では、ＳＭＴのサービスレベルディスクリプタでＥＳＧブートストラップ情報が伝送される点が一貫しない。
【１５０８】
本発明の第５実施例の効果について説明する。
【１５０９】
ＦＩＣ  ｓｉｚｅと関連して、本発明の第５実施例では、ＥＳＧサービスのためのＦＩＣのサイズはＡ／ＶサービスのためのＦＩＣのサイズと同一であってもよい。
【１５１０】
ＦＩＣ  ｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第５実施例では、ＦＩＣはＳＳＣが伝送される情報を示すＳＳＣブートストラップ情報を含むことができる。
【１５１１】
ＥＳＧブートストラップ情報取得時間と関連して、本発明の第５実施例に係るＥＳＧブートストラップ情報取得時間は、本発明の第４実施例に係るＥＳＧブートストラップ情報取得時間よりは遅い。
【１５１２】
サービスシグナリング帯域幅（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｂａｎｄｗｉｄｔｈ）と関連して、本発明の第５実施例では、ＧＡＴをＳＭＴに比べて頻繁に伝送しないと、帯域幅（Ｂａｎｄｗｉｄｔｈ）を節約することができる。
【１５１３】
明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第５実施例では、ＦＩＣはＳＳＣブートストラップ情報を含み、ＳＭＴはＲＯＵＴＥブートストラップ情報（ＬＳＩＤ伝送経路情報）を含み、ＧＡＴはＥＳＧブートストラップ情報を含むので、明確なＳｅｍａｎｔｉｃｓ定義が可能である。
【１５１４】
ＬＳＩＤの拡張と関連して、本発明の第５実施例では、ＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要である。ＣＭＴは、ＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。
【１５１５】
図１３８は、本発明の一実施例に係る放送受信装置の流れを示す図である。
【１５１６】
本発明の一実施例に係る放送受信装置は、ブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部のうち少なくとも一つを含むことができる。本発明の一実施例に係るブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部は、前述した内容を全て含むことができる。
【１５１７】
例えば、ブロードキャストインターフェースは、放送網を介して放送信号を受信することができる。ブロードキャストインターフェースは、フィジカルレイヤモジュール、フィジカルレイヤＩＰフレームモジュールを含むことができる。又はブロードキャストインターフェースは、チューナー及びフィジカルフレームパーサーのうち少なくとも一つを含むことができる。
【１５１８】
例えば、ブロードバンドインターフェースは、インターネット網を介してデータを伝送及び／又は受信することができる。ブロードバンドインターフェースは、インターネット接近制御モジュールを含むことができる。
【１５１９】
例えば、制御部は、前述したシグナリングデコーダ、データベース、サービスシグナリングマネジャー、アラートシグナリングマネジャー、サービスガイドマネジャー、アプリケーションシグナリングマネジャー、ターゲッティングシグナリングマネジャー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネント同期化部、ターゲッティングプロセッサ、アプリケーションプロセッサ、アラーティングプロセッサ、Ａ／Ｖプロセッサ、再分配モジュール、サービス／コンテンツ取得制御部、及び／又はコンパニオンスクリーンインターフェースのうち少なくとも一つを含むことができる。コンパニオンスクリーンインターフェースは、データシェアリング部及び／又は装置管理者のうち少なくとも一つを含むことができる。本発明の一実施例に係る制御部に含まれる構成要素に関する内容は、前述した同一又は類似の名称を有する構成要素に関する内容を全て含むことができる。
【１５２０】
また、制御部は、前述したフィジカルレイヤ制御部、リンクレイヤフレームパーサー（又は、リンクレイヤフレームプロセッサ）、ＩＰ／ＵＤＰデータグラムフィルター、アプリケーションレイヤ伝送クライアント、タイミングコントロール、システムクロック、ＤＴＶコントロールエンジン、ユーザ入力受信部、シグナリングパーサー、チャネルマップデータベース、ＨＴＴＰアクセスクライアント、ＨＴＴＰアクセスキャッシュ、ＤＡＳＨクライアント、ＩＳＯ ＢＭＦＦパーサー、メディアデコーダ及びファイルデータベースのうち少なくとも一つを含むことができる。本発明の一実施例に係る制御部に含まれる構成要素に関する内容は、前述した同一又は類似の名称を有する構成要素に関する内容を全て含むことができる。
【１５２１】
放送受信装置は、ブロードキャストインターフェースを用いて、サービスデータ及びシグナリング情報を含む放送信号を受信することができる（ＣＳ１３８０１００）。
【１５２２】
シグナリング情報は、サービスの取得のための第１シグナリング情報を含むことができる。例えば、第１シグナリング情報は、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。
【１５２３】
また、シグナリング情報は、第１シグナリング情報のブートストラップ発見を提供する第２シグナリング情報を含むことができる。すなわち、シグナリング情報は、サービスのためのブートストラップ情報を含む第２シグナリング情報を含むことができる。例えば、第２シグナリング情報は、ＦＩＣを含むことができる。
【１５２４】
また、サービスデータは、ＥＳＧデータを含むことができる。
【１５２５】
また、シグナリング情報は、Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＥＳＧ）データのためのＥＳＧブートストラップ情報を含むことができる。
【１５２６】
その後、放送受信装置は、制御部を用いて、シグナリング情報に基づいてサービスデータを取得することができる（ＣＳ１３８０２００）。
【１５２７】
その後、放送受信装置は、制御部を用いて、サービスデータをデコーティングすることができる（ＣＳ１３８０３００）。
【１５２８】
例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータの伝送タイプを示すタイプ情報（又は、ｎｅｔｗｏｒｋ＿ｔｙｐｅ  ａｔｔｒｉｂｕｔｅ）を含むことができる。
【１５２９】
例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータのｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓを示すｓｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓ  ｅｌｅｍｅｎｔ（又は、ｓｏｕｒｃｅＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ）、ＥＳＧデータのｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓを示すｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  ａｄｄｒｅｓｓ  ｅｌｅｍｅｎｔ（又は、ｄｅｓｔＩＰＡｄｄｒ  ｅｌｅｍｅｎｔ）、ＥＳＧデータのｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ  ｎｕｍｂｅｒを示すｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ  ｎｕｍｂｅｒ  ｅｌｅｍｅｎｔ（又は、ｄｅｓｔＵＤＰＰｏｒｔ  ｅｌｅｍｅｎｔ）のうち少なくとも一つを含むことができる。
【１５３０】
例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータが伝送される周波数を識別するｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ  ｅｌｅｍｅｎｔ、上記周波数のパーティションを識別するｐａｒｔｉｔｉｏｎＩＤ  ｅｌｅｍｅｎｔ、ＥＳＧデータが伝送されるＰｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ（ＰＬＰ）を示すＰＬＰ  ＩＤ  ｅｌｅｍｅｎｔ（又は、ｄａｔａｐｉｐｅＩＤ  ｅｌｅｍｅｎｔ）、ＥＳＧデータが伝送される伝送セッションを示すＴＳＩ  ｅｌｅｍｅｎｔ（又は、ｔｓｉ  ｅｌｅｍｅｎｔ）、及び／又はブロードバンドを介して伝送されるＥＳＧデータの位置を示すＵＲＬ  ｅｌｅｍｅｎｔ（又は、ｄｏｗｎｌｏａｄＵＲＬ  ａｔｔｒｉｂｕｔｅ）のうち少なくとも一つを含むことができる。
【１５３１】
また、第２シグナリング情報は、ＥＳＧブートストラップ情報を含むことができる。また、第２シグナリング情報は、サービスのカテゴリーを示すカテゴリー情報（又は、Ｓｅｒｖｉｃｅ  Ｃａｔｅｇｏｒｙ  ｅｌｅｍｅｎｔ）を含むことができる。また、カテゴリー情報はＥＳＧサービスを示すことができる。
【１５３２】
また、第１シグナリング情報は、伝送セッションに関する情報を含む伝送セッションｅｌｅｍｅｎｔを含み、伝送セッションエレメントは、伝送セッションのためのＰｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ（ＰＬＰ）を示すＰＬＰ  ＩＤ  ｅｌｅｍｅｎｔ（又は、ＤＰ  ａｔｔｒｉｂｕｔｅ）を含むことができる。
【１５３３】
以上では放送受信装置について説明したが、本発明の一実施例によれば、放送受信装置との反対の機能を有する放送伝送装置を含むことができる。例えば、放送伝送装置は、制御部及び／又は伝送部を含むことができる。制御部は、前述したサービスデータ、及び／又は前述したシグナリング情報を生成することができる。また、伝送部は、サービスデータ及び／又はシグナリング情報を含む放送信号を伝送することができる。
【１５３４】
図１３９は、本発明の一実施例に係るチャネルマップ構成方法を示す図である。
【１５３５】
本発明の一実施例は、デバイス性能（ｄｅｖｉｃｅ  ｃａｐａｂｉｌｉｔｙ）によって差別化したチャネルマップを構成する方法を提供することができる。それぞれのサービスに必要なデバイス性能（ｄｅｖｉｃｅ  ｃａｐａｂｉｌｉｔｙ）の識別のために、本発明の一実施例に係るＦＩＣは、ＦＩＣループにｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅを含むことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、デバイス性能（ｄｅｖｉｃｅ  ｃａｐａｂｉｌｉｔｙ）を識別することができる。放送受信装置はＦＩＣを受信し、ＦＩＣのｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅに基づいて、デバイス性能（ｄｅｖｉｃｅ  ｃａｐａｂｉｌｉｔｙ）に符合する差別化したチャネルマップを構成（又は、生成）することができる。
【１５３６】
以は、図面を参照して本発明の一実施例に係る放送信号の構造を説明する。
【１５３７】
特定の周波数を有する放送信号は、シグナリング情報を含むことができる。例えば、シグナリング情報は、ＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣは、ＳＬＴと呼ぶことができる。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。
【１５３８】
特定の周波数を有する放送信号は、同一のコンデンツを含む高鮮明ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ，ＨＤ）サービス及び超高鮮明ビデオ（Ｕｌｔｒａ  Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ，ＵＨＤ）サービスを含むことができる。それぞれのサービスは、少なくとも一つのＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ ）セッションを介して伝送されてもよい。そのために、放送信号は少なくとも一つのＲＯＵＴＥセッションを含むことができる。それぞれのＲＯＵＴＥセッションは、サービスレイヤシグナリング情報及び少なくとも一つのコンポーネントを含むことができる。また、それぞれのＲＯＵＴＥセッションは、ｓｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ、及びｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ  ｎｕｍｂｅｒの組合せで識別されてもよい。また、それぞれのＲＯＵＴＥセッションは、少なくとも一つのＤＰ及び／又はＰＬＰを介して伝送されてもよい。また、それぞれのＲＯＵＴＥセッションは、少なくとも一つの伝送セッション（又は、ＬＣＴセッション）を含むことができる。それぞれの伝送セッションは、ＴＳＩで識別されてもよい。また、それぞれの伝送セッションは、シグナリング情報及び／又はコンデンツコンポーネントを含むことができる。例えば、伝送セッションに含まれるシグナリング情報は、サービスレイヤシグナリング情報（ＳＬＳ）を含むことができる。また、コンデンツコンポーネントは、ビデオコンポーネント及び／又はオーディオコンポーネントを含むことができる。
【１５３９】
放送信号は、第１ＲＯＵＴＥセッション及び第２ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、ＨＤサービスを含むことができる。第２ＲＯＵＴＥセッションは、ＵＨＤサービスのための付加情報を含むことができる。ＨＤサービスは第１ＲＯＵＴＥセッションを介して伝送されてもよい。ＵＨＤサービスは第１ＲＯＵＴＥセッション及び第２ＲＯＵＴＥセッションを介して伝送されてもよい。
【１５４０】
各サービスに対してそれぞれサービスレイヤシグナリング情報が存在してもよい。例えば、ＨＤサービスに対して、第１ＲＯＵＴＥセッションに、ＨＤサービスのためのサービスレイヤシグナリング情報が存在してもよい。また、ＵＨＤサービスに対して、第２ＲＯＵＴＥセッションに、ＵＨＤサービスのためのサービスレイヤシグナリング情報が存在してもよい。第１ＲＯＵＴＥセッションに存在するＨＤサービスのためのサービスレイヤシグナリング情報は、ＵＨＤサービスのためのサービスレイヤシグナリング情報として活用されてもよい。ここで、サービスレイヤシグナリング情報は、ＬＳＩＤ及びＳＳＣ（ＳＭＴ、ＭＤＰ、及び／又はＣＭＴ）のうち少なくとも一つを含むことができる。
【１５４１】
第１ＲＯＵＴＥセッションは、ｓｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓ（ｓｉｐ−ｈｄ）、ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ（ｉｐ−ｈｄ）、及びｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ  ｎｕｍｂｅｒ（ｕｄｐ−ｈｄ）の組合せで識別されてもよい。また、第１ＲＯＵＴＥセッションは、第１ＤＰ（ｄｐ−１）及び第２ＤＰ（ｄｐ−２）を介して伝送されてもよい。また、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−０）、第２伝送セッション（ｔｓｉ−ａ）、及び第３伝送セッション（ｔｓｉ−ｖ−ｂ）を含むことができる。第１伝送セッション（ｔｓｉ−０）は、ＬＳＩＤ及びシグナリングテーブルを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴのうち少なくとも一つを含むことができる。第２伝送セッション（ｔｓｉ−ａ）はオーディオコンポーネントを含むことができる。例えば、オーディオコンポーネントは少なくとも一つのオーディオセグメントを含むことができる。第３伝送セッション（ｔｓｉ−ｖ−ｂ）はベースビデオコンポーネントを含むことができる。例えば、ベースビデオコンポーネントは、少なくとも一つのベースビデオセグメントを含むことができる。例えば、ベースビデオコンポーネントは、ＨＤサービスを提供するためのビデオコンポーネントである。
【１５４２】
第２ＲＯＵＴＥセッションは、ｓｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓ（ｓｉｐ−ｕｈｄ）、ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ（ｉｐ−ｕｈｄ）、及びｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ  ｎｕｍｂｅｒ（ｕｄｐ−ｕｈｄ）の組合せで識別されてもよい。また、第２ＲＯＵＴＥセッションは、第３ＤＰ（ｄｐ−３）及び第４ＤＰ（ｄｐ−４）を介して伝送されてもよい。また、第２ＲＯＵＴＥセッションは、第４伝送セッション（ｔｓｉ−０）及び第５伝送セッション（ｔｓｉ−ｖ−ｅ）を含むことができる。第４伝送セッション（ｔｓｉ−０）は、ＬＳＩＤ及びシグナリングテーブルを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴのうち少なくとも一つを含むことができる。第５伝送セッション（ｔｓｉ−ｖ−ｅ）はエンハンスメントビデオコンポーネントを含むことができる。例えば、エンハンスメントビデオコンポーネントは、少なくとも一つのエンハンスメントビデオセグメントを含むことができる。例えば、エンハンスメントビデオコンポーネントは、ＵＨＤサービスを提供するためのビデオコンポーネント及び／又は付加情報である。
【１５４３】
以下ではＦＩＣについて説明する。
【１５４４】
ＦＩＣは、Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ（ＳＬＴ）と呼ぶことができる。ＳＬＴは、基本的なサービスリストを樹立（ｂｕｉｌｄｉｎｇ）し、サービスレイヤシグナリング情報（ＳＬＳ）のブートストラップ情報を提供するシグナリング情報テーブルである。
【１５４５】
ＦＩＣは、ｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１５４６】
ｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅは、サービスを識別する識別子である。
【１５４７】
ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、ＦＩＣに含まれてもよく、ＳＬＳに含まれてもよい。性能のカテゴリーは、Ｄｏｗｎｌｏａｄ  Ｐｒｏｔｏｃｏｌ、ＦＥＣ  Ａｌｇｏｒｉｔｈｍ、Ｗｒａｐｐｅｒ／Ａｒｃｈｉｖｅ  Ｆｏｒｍａｔ、Ｃｏｍｐｒｅｓｓｉｏｎ  Ａｌｇｏｒｉｔｈｍ、Ｍｅｄｉａ  Ｔｙｐｅ、及び／又はＩｎｔｅｒｎｅｔ  Ｌｉｎｋのうち少なくとも一つを含むことができる。
【１５４８】
例えば、Ｄｏｗｎｌｏａｄ  Ｐｒｏｔｏｃｏｌと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、ＦＬＵＴＥ  ｐｒｏｔｏｃｏｌ及び／又はＨＴＴＰのうち少なくとも一つを示すことができる。また、ＦＥＣ  Ａｌｇｏｒｉｔｈｍと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、Ｃｏｍｐａｃｔ  Ｎｏ−Ｃｏｄｅ  ＦＥＣ  ｓｃｈｅｍｅ及び／又はＲａｐｔｏｒ  ａｌｇｏｒｉｔｈｍのうち少なくとも一つを示すことができる。また、Ｗｒａｐｐｅｒ／Ａｒｃｈｉｖｅ  Ｆｏｒｍａｔと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、ＤＥＣＥ  ＣＦＦ  ｃｏｎｔａｉｎｅｒ  ｇｅｎｅｒａｌ  ｆｏｒｍａｔ、ＺＩＰ  ｆｏｒｍａｔ、ＤＥＣＥ  ＣＦＦ  ｃｏｎｔａｉｎｅｒ  ｆｏｒｍａｔ、ＤＥＣＥ  ＣＦＦ  ｃｏｎｔａｉｎｅｒ  ｆｏｒｍａｔ、ＤＥＣＥ  ＣＦＦ  ｃｏｎｔａｉｎｅｒ  ｆｏｒｍａｔ、ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ  ｆｏｒ  ＡＡＣ  ａｕｄｉｏ、ＡＴＳＣ  ｃｏｍｐｌｉａｎｔ  ＭＰＥＧ−２ｔｒａｎｓｐｏｒｔ  ｓｔｒｅａｍ、ＭＰ４ｃｏｎｓｔｒａｉｎｅｄ  ｃｏｎｔａｉｎｅｒ  ｆｏｒｍａｔ、及び／又はＷ３Ｃ  Ｗｅｂ  Ａｐｐｓ  Ｐａｃｋａｇｅのうち少なくとも一つを示すことができる。また、Ｃｏｍｐｒｅｓｓｉｏｎ  Ａｌｇｏｒｉｔｈｍと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、ＤＥＦＬＡＴＥ  ａｌｇｏｒｉｔｈｍを示すことができる。また、Ｍｅｄｉａ  Ｔｙｐｅと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、ＡＶＣ  ｓｔａｎｄａｒｄ  ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ、ＡＶＣ  ｈｉｇｈ  ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ、ＡＣ−３ａｕｄｉｏ、Ｅ−ＡＣ−３ａｕｄｉｏ、ＭＰ３ａｕｄｉｏ、Ｂｒｏｗｓｅｒ  Ｐｒｏｆｉｌｅ  Ａ（Ａ／１０５）、Ａｔｏｍ  ｐｅｒ  ＲＦＣ  ４２８７、ＡＶＣ  ｍｏｂｉｌｅ  ｖｉｄｅｏ、ＨＥ  ＡＡＣ  ｖ２  ｍｏｂｉｌｅ  ａｕｄｉｏ、ＨＥ  ＡＡＣ  ｖ２  ｌｅｖｅｌ  ４ａｕｄｉｏ、ＤＴＳ−ＨＤ  ａｕｄｉｏ、ＣＦＦ−ＴＴ、ＣＥＡ−７０８  ｃａｐｔｉｏｎｓ、ＨＥ  ＡＡＣ  ｖ２  ｗｉｔｈ  ＭＰＥＧ  Ｓｕｒｒｏｕｎｄ、ＨＥ  ＡＡＣ  ｖ２  Ｌｅｖｅｌ  ６  ａｕｄｉｏ、Ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ  ３Ｄ  ｖｉｄｅｏ（Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ）、Ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ  ３Ｄ  ｖｉｄｅｏ（Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ）、ＡＴＳＣ ３．０  ＨＥＶＣ  Ｖｉｄｅｏ１（ｅ．ｇ．ＨＤ  ｖｉｄｅｏ）、ＡＴＳＣ ３．０  ＨＥＶＣ  Ｖｉｄｅｏ２（ｅ．ｇ．ＵＨＤ  ｖｉｄｅｏ）、ＡＴＳＣ ３．０  ＳＨＶＣ  Ｖｉｄｅｏ  １、ＡＴＳＣ ３．０  ＨＤＲ  Ｖｉｄｅｏ  １、ＡＴＳＣ ３．０  Ｗｉｄｅ  Ｃｏｌｏｒ  Ｇａｍｕｔ  Ｖｉｄｅｏ  １、ＡＴＳＣ ３．０  Ｃｏｄｅｄ  Ａｕｄｉｏ  １（ｅ．ｇ．，５．１．  ｃｈａｎｎｅｌ  ｓｕｒｒｏｕｎｄ  ａｕｄｉｏ）、ＡＴＳＣ ３．０  Ｃｏｄｅｄ  Ａｕｄｉｏ２（ｅ．ｇ．Ｉｍｍｅｒｓｉｖｅ／３Ｄ  Ａｕｄｉｏ）、及び／又はＤｉａｌｏｇ  ｌｅｖｅｌ  ａｄｊｕｓｔｍｅｎｔのうち少なくとも一つを示すことができる。また、Ｉｎｔｅｒｎｅｔ  Ｌｉｎｋと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、ｄｏｗｎｗａｒｄ  ｒａｔｅ  ５６，０００ｂｐｓ  ｏｒ  ｂｅｔｔｅｒ、ｄｏｗｎｗａｒｄ  ｒａｔｅ  ５１２，０００ｂｐｓ  ｏｒ  ｂｅｔｔｅｒ、ｄｏｗｎｗａｒｄ  ｒａｔｅ  ２，０００，０００ｂｐｓ  ｏｒ  ｂｅｔｔｅｒ、及び／又はｄｏｗｎｗａｒｄ  ｒａｔｅ  １０，０００，０００ｂｐｓ  ｏｒ  ｂｅｔｔｅｒのうち少なくとも一つを示すことができる。
【１５４９】
ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｓｏｕｒｃｅ  ａｄｄｒｅｓｓを示すことができる。
【１５５０】
ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓを示すことができる。
【１５５１】
ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。
【１５５２】
ＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送する伝送セッションを識別する識別子である。ただし、ＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅは、固定した「０」の値を有することができる。ＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅが、固定した「０」の値を有すると、ＦＩＣはＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅを含まなくてもよい。
【１５５３】
ＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するデータパイプ（又は、フィジカルレイヤパイプ）の識別子を示すことができる。
【１５５４】
ＦＩＣは、ＨＤサービスのための第１サービスエレメント及びＵＨＤサービスのための第２サービスエレメントを含むことができる。
【１５５５】
第１サービスエレメントは、「ｓｉｄ−ｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、「０ｘ０１」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅ、「ｓｉｐ−ｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「ｕｄｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅ、「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又は「ｄｐ−１」の値を有するＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ここで、「ｓｉｄ−ｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅは、ＨＤサービスを示すことができる。「０ｘ０１」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、性能情報がＨＤサービスであることを示すことができる。「ｓｉｐ−ｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、及び「ｕｄｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅの組合せは、第１ＲＯＵＴＥセッションを示すことができる。「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅ及び「ｄｐ−１」の値を有するＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅは、ＨＤサービスのためのＳＬＳ（例えば、ＬＳＩＤ及びＳＳＣ）が伝送される経路を示すことができる。
【１５５６】
第２サービスエレメントは、「ｓｉｄ−ｕｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、「０ｘ０２」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅ、「ｓｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「ｕｄｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅ、「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又は「ｄｐ−３」の値を有するＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ここで、「ｓｉｄ−ｕｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅは、ＵＨＤサービスを示すことができる。「０ｘ０２」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、性能情報がＵＨＤサービスであることを示すことができる。「ｓｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「ｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、及び「ｕｄｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅの組合せは、第２ＲＯＵＴＥセッションを示すことができる。「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅ及び「ｄｐ−３」の値を有するＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅは、ＵＨＤサービスのためのＳＬＳ（例えば、ＬＳＩＤ及びＳＳＣ）が伝送される経路を示すことができる。
【１５５７】
以下、ＳＭＴについて説明する。
【１５５８】
ＳＭＴは、サービスの属性（ＩＤ、名前、カテゴリーなど）情報及びサービスを取得し得る経路情報を含むことができる。例えば、サービスを取得し得る経路情報は、サービスのためのＲＯＵＴＥセッションのブートストラップ情報及び／又はＳＬＳの伝送経路情報のうち少なくとも一つを含むことができる。
【１５５９】
ＳＭＴは、ＨＤサービスのための第１サービスマップ情報及びＵＤＨサービスのための第２サービスマップ情報を含むことができる。
【１５６０】
それぞれの第１サービスマップ情報及び第２サービスマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、サービスのためのＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む少なくとも一つのＲＯＵＴＥセッションエレメントを含むことができる。ＲＯＵＴＥセッションエレメントは、ｓｒｃＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅ、ｄｅｓｔＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅ、ｄｅｓｔＵＤＰＰｏｒｔ  ａｔｔｒｉｂｕｔｅ、及び／又はＬＳＩＤ＿ＤＰ  ａｔｔｒｉｂｕｔｅを含むことができる。ｓｒｃＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅ、ｄｅｓｔＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅ、及び／又はｄｅｓｔＵＤＰＰｏｒｔ  ａｔｔｒｉｂｕｔｅの組合せは、ＲＯＵＴＥセッションブートストラップ情報と呼ぶことができる。ＬＳＩＤ＿ＤＰ  ａｔｔｒｉｂｕｔｅは、ＳＬＳの伝送経路情報と呼ぶことができる。
【１５６１】
ｓｒｃＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｓｏｕｒｃｅ  ａｄｄｒｅｓｓを示すことができる。
【１５６２】
ｄｅｓｔＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓを示すことができる。
【１５６３】
ｄｅｓｔＵＤＰＰｏｒｔ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｐｏｒｔ  ｎｕｍｂｅｒを示すことができる。
【１５６４】
ＬＳＩＤ＿ＤＰ  ａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するデータパイプ（又は、フィジカルレイヤパイプ）の識別子を示すことができる。
【１５６５】
第１サービスマップ情報は、ＨＤサービスを識別するｓｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔ、及びＨＤサービスのための第１ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第１ＲＯＵＴＥセッションエレメントのうち少なくとも一つを含むことができる。例えば、ＨＤサービスのためのｓｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔの値は「ｓｉｄ−ｈｄ」であってもよい。また、ＨＤサービスのための第１ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｈｄ」であり、ｄｅｓｔＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｈｄ」であり、ｄｅｓｔＵＤＰＰｏｒｔ  ａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｈｄ」であってもよい。また、ＨＤサービスのための第１ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−１」であってもよい。
【１５６６】
第２サービスマップ情報は、ＵＨＤサービスを識別するｓｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔ、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第１ＲＯＵＴＥセッションエレメント、及びＵＨＤサービスのための第２ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第２ＲＯＵＴＥセッションエレメントのうち少なくとも一つを含むことができる。例えば、ＵＨＤサービスのためのｓｅｒｖｉｃｅ＿ｉｄ  ｅｌｅｍｅｎｔの値は「ｓｉｄ−ｕｈｄ」であってもよい。また、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｈｄ」であり、ｄｅｓｔＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｈｄ」であり、ｄｅｓｔＵＤＰＰｏｒｔ  ａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｈｄ」であってもよい。また、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−１」であってもよい。また、ＵＨＤサービスのための第２ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｕｈｄ」であり、ｄｅｓｔＩＰａｄｄｒ  ａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｕｈｄ」であり、ｄｅｓｔＵＤＰＰｏｒｔ  ａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｕｈｄ」であってもよい。また、ＵＨＤサービスのための第２ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−３」であってもよい。
【１５６７】
以下、ＭＤＰについて説明する。
【１５６８】
ＭＰＤは、リニア／ストリーミングサービスの個別的なメディアコンポーネントのためのリソース識別子を含むことができる。また、ＭＰＤは、メディアプレゼンテーション内で識別されたリソースのコンテクスト（ｃｏｎｔｅｘｔ）を含むことができる。例えば、リソース識別子は、サービスのためのコンポーネントと関連するリプレゼンテーションを識別する情報であってもよい。
【１５６９】
ＭＰＤは、メディアプレゼンテーションを構成する連続的な時間的区間に関する情報を含む少なくとも一つのピリオドエレメントを含むことができる。それぞれのピリオドエレメントは、ピリオドを識別するｐｅｒＩｄ  ａｔｔｒｉｂｕｔｅ、及びコンポーネントに関する情報を含む少なくとも一つのＲｅｐｒｅｓｅｎｔａｔｉｏｎ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。それぞれのＲｅｐｒｅｓｅｎｔａｔｉｏｎ  ｅｌｅｍｅｎｔは、サービスのためのコンポーネントに関連するリプレゼンテーションを識別するｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅを含むことができる。また、それぞれのＲｅｐｒｅｓｅｎｔａｔｉｏｎ  ｅｌｅｍｅｎｔは、デコーディング及び／又はプレゼンテーションプロセスで当該リプレゼンテーションが依存している少なくとも一つのコンプリメンタリリプレゼンテーション（ｃｏｍｐｌｅｍｅｎｔａｒｙ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を示すｄｅｐｅｎｄｅｎｃｙＩｄ  ａｔｔｒｉｂｕｔｅを含むことができる。
【１５７０】
例えば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ  ｅｌｅｍｅｎｔは、オーディオコンポーネントに関する情報を含む第１リプレゼンテーションエレメント、ＨＤサービスのためのベースビデオコンポーネントに関する情報を含む第２リプレゼンテーションエレメント、及び／又はＵＨＤサービスのためのエンハンスメントビデオコンポーネントに関する情報を含む第３リプレゼンテーションエレメントを含むことができる。第３リプレゼンテーションエレメントは、ＵＨＤサービスのために第２リプレゼンテーションに依存している。第１リプレゼンテーションエレメント内のｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であり、第２リプレゼンテーションエレメント内のｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であり、第３リプレゼンテーションエレメント内のｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であってもよい。また、第３リプレゼンテーションエレメントはｄｅｐｅｎｄｅｎｃｙＩｄ  ａｔｔｒｉｂｕｔｅを含むことができ、ｄｅｐｅｎｄｅｎｃｙＩｄ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」を示すことができる。
【１５７１】
以下、ＣＭＴについて説明する。
【１５７２】
ＣＭＴは、サービスのためのコンポーネントデータの伝送経路情報を含むことができる。例えば、伝送経路情報は、サービスのためのコンポーネントデータが伝送されるＤＰ（又は、ＰＬＰ）を識別する情報であってもよい。
【１５７３】
ＣＭＴは、ＨＤサービスのための第１コンポーネントマップ情報及びＵＤＨサービスのための第２コンポーネントマップ情報を含むことができる。
【１５７４】
それぞれの第１コンポーネントマップ情報及び第２コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ  ａｔｔｒｉｂｕｔｅ、及び／又はコンポーネントの伝送経路情報を含む少なくとも一つのＣｏｍｐ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、Ｃｏｍｐ  ｅｌｅｍｅｎｔは、サービスのためのコンポーネントと関連するリプレゼンテーションを識別するｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅ、及び／又はサービスのためのコンポーネントが伝送されるＤＰを示すｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅは、コンポーネントの伝送経路情報と呼ぶことができる。
【１５７５】
第１コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ  ａｔｔｒｉｂｕｔｅ、ＨＤサービスのためのオーディオコンポーネントの伝送経路情報を含む第１のＣｏｍｐ  ｅｌｅｍｅｎｔ、及び／又はＨＤサービスのためのベースビデオコンポーネントの伝送経路情報を含む第２のＣｏｍｐ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、ｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅの値は「ｓｉｄ−ｈｄ」であり、ｐｅｒＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｐｅｒ−１」であってもよい。また、ＨＤサービスのための第１のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。また、ＨＤサービスのための第２のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。
【１５７６】
第２コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ  ａｔｔｒｉｂｕｔｅ、ＵＨＤサービスのためのオーディオコンポーネントの伝送経路情報を含む第１のＣｏｍｐ  ｅｌｅｍｅｎｔ、ＵＨＤサービスのためのベースビデオコンポーネントの伝送経路情報を含む第２のＣｏｍｐ  ｅｌｅｍｅｎｔ、及び／又はＵＨＤサービスのためのエンハンスメントビデオコンポーネントの伝送経路情報を含む第３のＣｏｍｐ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、ｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅの値は「ｓｉｄ−ｕｈｄ」であり、ｐｅｒＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｐｅｒ−１」であってもよい。また、ＵＨＤサービスのための第１のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。また、ＵＨＤサービスのための第２のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。また、ＵＨＤサービスのための第３のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｄｐ−４」であってもよい。
【１５７７】
以下では、ＬＳＩＤについて説明する。
【１５７８】
ＬＳＩＤは、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶことができる。Ｓ−ＴＳＩＤは、サービスの少なくとも一つのコンデンツコンポーネントを伝送する少なくとも一つの伝送セッションのための全体的なセッションディスクリプション情報を含むことができる。例えば、ＬＳＩＤは、サービスのためのコンポーネントが伝送される伝送セッションを識別する情報を含むことができる。
【１５７９】
ＬＳＩＤは、ＨＤサービスのための第１ＬＳＩＤ及びＵＨＤサービスのための第２ＬＳＩＤを含むことができる。
【１５８０】
第１ＬＳＩＤは、第１ＲＯＵＴＥセッションに含まれてもよい。第１ＬＳＩＤは、コンポーネントを伝送する少なくとも一つのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔを含むことができる。それぞれのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔは、伝送セッションに含まれるソースフローに関する情報を提供するＳｏｕｒｃｅＦｌｏｗ  ｅｌｅｍｅｎｔを含むことができる。ＳｏｕｒｃｅＦｌｏｗ  ｅｌｅｍｅｎｔは、伝送セッションを介して伝送されるサービス（又は、アプリケーションサービス）にマッピングされる付加的な情報を含むＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ  ｅｌｅｍｅｎｔを含むことができる。例えば、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ  ｅｌｅｍｅｎｔは、ＤＡＳＨコンデンツのリプレゼンテーション識別子（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ  ＩＤ）及び／又はＤＡＳＨメディアリプレゼンテーションのアダプテーションセットパラメータ（Ａｄａｐｔａｔｉｏｎ  Ｓｅｔ  ｐａｒａｍｅｔｅｒｓ）を含むことができる。リプレゼンテーション識別子は、サービスのためのコンポーネントと関連する識別子であり、ｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅと呼ぶことができる。また、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ  ｅｌｅｍｅｎｔは、ＣｏｎｔｅｎｔＩｎｆｏ  ｅｌｅｍｅｎｔと呼ぶことができる。
【１５８１】
第１ＬＳＩＤは、オーディオコンポーネントを伝送する第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ及び／又はベースビデオコンポーネントを伝送する第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ内のｔｓｉ  ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ａ」であり、ｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であってもよい。また、第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ内のｔｓｉ  ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ｖ−ｂ」であり、ｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であってもよい。
【１５８２】
第２のＬＳＩＤは、エンハンスメントビデオコンポーネントを伝送する第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔを含むことができる。例えば、第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ内のｔｓｉの値は「ｔｓｉ−ｖ−ｅ」であり、ｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であってもよい。
【１５８３】
図面では、各ＲＯＵＴＥセッションはそれぞれ一つのＬＳＩＤ（伝送セッション情報）を含み、２つのＬＳＩＤが存在する。ただし、これに限定されない。例えば、各サービスはそれぞれ一つのＬＳＩＤ（伝送セッション情報）を含むことができる。この場合、一つのＬＳＩＤは、特定サービスのための少なくとも一つのＲＯＵＴＥセッションに含まれる少なくとも一つのコンポーネントを伝送する少なくとも一つの伝送セッションに関する情報を含むことができる。例えば、一つのＬＳＩＤは、ＵＨＤサービスのために第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ、第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ、及び／又は第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔを全て含むことができる。
【１５８４】
同図を参照すると、本発明の一実施例に係る一つの周波数は、同一のコンテンツを含む高鮮明ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ、ＨＤ）サービス及び超高鮮明ビデオ（Ｕｌｔｒａ  Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ、ＵＨＤ）サービスを含むことができる。
【１５８５】
例えば、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅの値が「０ｘ００」であれば、デバイス性能はデジタル標準ビデオ（Ｓｔａｎｄａｒｄ−Ｄｅｆｉｎｉｔｉｏｎ、ＳＤ）サービスを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅの値が「０ｘ０１」であれば、デバイス性能はＨＤサービスを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅの値が「０ｘ０２」であれば、デバイス性能はＵＨＤサービスを示すことができる。
【１５８６】
モバイルデバイスのようにＵＨＤサービスを再生できない装置は、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅに基づいて、チャネルマップの構成時に、ＵＨＤサービスに該当するチャネルを除いてチャネルマップを構成することができる。
【１５８７】
また、ＴＶのようなフィクスドデバイス（ｆｉｘｅｄ  ｄｅｖｉｃｅ）では、ＨＤサービス及びＵＨＤサービスを全て再生できるので、フィクスドデバイスは、ＨＤサービス及びＵＨＤサービスに該当するチャネルを全て含んでチャネルマップを構成することができる。
【１５８８】
図１４０は、本発明の一実施例に係るチャネルマップ構成方法を示す図である。
【１５８９】
本発明の一実施例は、次世代放送網で同一のコンデンツが複数のサービス形態で提供される時、これを識別するための方法を提供することができる。同一コンデンツがサービスされることを識別するために、本発明の一実施例に係るＦＩＣは、ＦＩＣ  ｌｏｏｐにｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅを含むことができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅは、サービスのチャネル番号を示すことができる。放送受信装置はＦＩＣを受信し、ＦＩＣのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅに基づいて、同一コンデンツを伝送するチャネル（又は、サービス）を除いてチャネルマップを構成することができる。
【１５９０】
特定の周波数を有する放送信号は、シグナリング情報を含むことができる。例えば、シグナリング情報は、ＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣは、ＳＬＴと呼ぶことができる。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。本発明の一実施例に係る放送信号の構造、ＦＩＣ、及び／又はＳＬＳは、前述した内容と同一であるか、又は前述した内容を全て含むことができる。
【１５９１】
本発明の一実施例に係るＦＩＣは、サービスエレメント内に、サービスのチャネル番号を示すｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅを含むことができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅは、サービスのメジャーチャネル番号を示すｍａｊｏｒＣｈａｎｎｅｌＮｏ  ａｔｔｒｉｂｕｔｅ、及び／又はサービスのマイナーチャネル番号を示すｍｉｎｏｒＣｈａｎｎｅｌＮｏ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１５９２】
ＦＩＣは、ＨＤサービスのための第１サービスエレメント及びＵＨＤサービスのための第２サービスエレメントを含むことができる。例えば、ＨＤサービス及びＵＨＤサービスは同一コンデンツを提供することができる。第１サービスエレメントは、「ｃｎｕｍ−ｘ」の値を有するｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅを含むことができる。第２サービスエレメントは、「ｃｎｕｍ−ｘ」の値を有するｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅを含むことができる。第１サービスエレメントのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅと第２サービスエレメントのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅはいずれも「ｃｎｕｍ−ｘ」の値を有することができる。
【１５９３】
同図を参照すると、本発明の一実施例に係る一つの周波数は、同一のコンテンツを含む高鮮明ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ、ＨＤ）サービス及び超高鮮明ビデオ（Ｕｌｔｒａ  Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ、ＵＨＤ）サービスを含むことができる。
【１５９４】
例えば、同一のコンデンツがＨＤサービス及び／又はＵＨＤサービスと共にそれぞれのサービス形態で伝送される時、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅは同一の値を有することができる。
【１５９５】
ＵＨＤ再生が可能な装置では、同一のコンデンツを伝送するＨＤチャネル（サービス）情報及び／又はＵＨＤチャネル（サービス）情報を重複的に構成せず、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅに基づいてＵＨＤチャネルだけを選択し、チャネルマップを構成することができる。
【１５９６】
図１４１は、本発明の一実施例に係るＦＩＣを示す図である。
【１５９７】
本発明の一実施例に係るＦＩＣに関連した内容は、前述したＦＩＣに関連した内容を全て含むことができる。また、本発明の一実施例では、ＦＩＣに含まれる情報をｆｉｅｌｄと表現したが、ＦＩＣはＸＭＬフォーマットであってもよい。また、ＦＩＣに含まれる情報をｆｉｅｌｄに代えてａｔｔｒｉｂｕｔｅと表現してもよい。
【１５９８】
本発明の一実施例に係るＦＩＣは、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ  ｆｉｅｌｄ、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄ、ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄ、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄのうち少なくとも一つを含むことができる。
【１５９９】
ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ  ｆｉｅｌｄは、Ｓｅｒｖｉｃｅ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＳＣＤ）が伝送されるか（又は、存在するか）否かを示すことができる。ＳＣＤは、ＦＩＣに含まれていない、より多様で多量の追加的なシグナリング情報を含むことができる。例えば、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ  ｆｉｅｌｄの値が「Ｔｒｕｅ」であれば、シグナリング情報は、ＳＣＤを含むことができる。
【１６００】
ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄは、ＳＣＤが伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す。
【１６０１】
ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄは、当該サービスのＳＳＣブートストラップ情報が伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す。
【１６０２】
ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄは、基本的な段階のシグナリング情報がＳＳＣで伝送されるか否かを示すことができる。例えば、サービスシグナリングで用いられるディスクリプションの種類又はテーブルの種類が異なる場合、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄは、基本的な段階のシグナリング情報がＳＳＣで伝送されるか否かを示すことができる。また、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄは、オーディオコンポーネント及び／又はビデオコンポーネントと関連した基本的な段階のシグナリング情報が別途のシグナリングチャネル及び／又はシグナリングテーブルを介して伝達されるか否かを示すことができる。
【１６０３】
ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ  ｆｉｅｌｄ及び／又はＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄは、フィジカルレイヤシグナリング情報に含まれてもよい。この場合、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ  ｆｉｅｌｄは、現在フレームにＳＣＤが存在するか否かを示すことができる。また、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄは、ＳＣＤが伝送されるデータパイプ（又は、ＰＬＰ）及び／又はフレームを示すことができる。
【１６０４】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述したＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ  ｆｉｅｌｄ、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄ、ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄ、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄのうち少なくとも一つを含むことができる。
【１６０５】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいてサービスを取得することができる。
【１６０６】
図１４２は、本発明の一実施例に係るＦＩＣを示す図である。
【１６０７】
本発明の一実施例に係るＦＩＣに関連した内容は、前述したＦＩＣに関連した内容を全て含むことができる。また、本発明の一実施例では、ＦＩＣに含まれる情報をｆｉｅｌｄと表現したが、ＦＩＣはＸＭＬフォーマットであってもよい。また、ＦＩＣに含まれる情報をｆｉｅｌｄに代えてａｔｔｒｉｂｕｔｅと表現してもよい。
【１６０８】
本発明の一実施例に係るＦＩＣは、Ｐｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄを含むことができる。
【１６０９】
Ｐｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄは、当該サービスを送信する提供者（又は、Ｐｒｏｖｉｄｅｒ）の固有な識別子を示す。例えば、Ｐｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄは、当該サービスがどの提供者から伝送されるかを示すことができる。
【１６１０】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述したＰｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄを含むことができる。
【１６１１】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいてサービスを取得し、当該サービスの提供者を識別することができる。
【１６１２】
図１４３は、本発明の一実施例に係るＦＩＣを示す図である。
【１６１３】
本発明の一実施例に係るＦＩＣに関連した内容は、前述したＦＩＣに関連した内容を全て含むことができる。また、本発明の一実施例では、ＦＩＣに含まれる情報をｆｉｅｌｄと表現したが、ＦＩＣはＸＭＬフォーマットであってもよい。また、ＦＩＣに含まれる情報をｆｉｅｌｄに代えてａｔｔｒｉｂｕｔｅと表現してもよい。
【１６１４】
本発明の一実施例に係るＦＩＣは、Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ  ｆｉｅｌｄを含むことができる。
【１６１５】
Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ  ｆｉｅｌｄは、当該サービスを送信する提供者（Ｐｒｏｖｉｄｅｒ）の属したグループの識別子を示すことができる。
【１６１６】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述したＰｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ  ｆｉｅｌｄを含むことができる。
【１６１７】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいてサービスを取得し、当該サービスの提供者のグループを識別することができる。
【１６１８】
例えば、放送受信装置は、Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ  ｆｉｅｌｄに基づいて、提供者グループ別に受信されるサービスを区別することができる。すなわち、放送受信装置は、Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄ  ｆｉｅｌｄとＳｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ  ｆｉｅｌｄがＥＳＧであるサービスとをマッピングし、ＥＳＧが、どの提供者が提供しているサービスに対するＧｕｉｄｅを含んでいるかを判断することができる。
【１６１９】
図１４４は、本発明の一実施例に係るＦＩＣを示す図である。
【１６２０】
本発明の一実施例に係るＦＩＣに関連した内容は、前述したＦＩＣに関連した内容を全て含むことができる。また、本発明の一実施例では、ＦＩＣに含まれる情報をｆｉｅｌｄと表現したが、ＦＩＣはＸＭＬフォーマットであってもよい。また、ＦＩＣに含まれる情報をｆｉｅｌｄに代えてａｔｔｒｉｂｕｔｅと表現してもよい。
【１６２１】
本発明の一実施例に係るＦＩＣは、Ｎｕｍ＿ｐｒｏｖｉｄｅｒｓ  ｆｉｅｌｄ及び／又は少なくとも一つの提供者ループを含むことができる。
【１６２２】
Ｎｕｍ＿ｐｒｏｖｉｄｅｒｓ  ｆｉｅｌｄは、当該周波数を用いる提供者（Ｐｒｏｖｉｄｅｒ又はＢｒｏａｄｃａｓｔｅｒ）の数を示すことができる。
【１６２３】
それぞれの提供者ループは、Ｐｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄ、少なくとも一つのサービスループ、Ｎｕｍ＿ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ  ｆｉｅｌｄ、及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ  ｆｉｅｌｄを含むことができる。
【１６２４】
Ｐｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄは、当該サービスを送信する提供者（又は、Ｐｒｏｖｉｄｅｒ）の固有な識別子を示す。例えば、Ｐｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄは、それぞれの提供者（ｐｒｏｖｉｄｅｒ又はｂｒｏａｄｃａｓｔｅｒ）に割り当てられる固有の識別子である。
【１６２５】
サービスループは、サービスと関連した属性を含むことができる。具体的な内容は、前述したとおりである。
【１６２６】
Ｎｕｍ＿ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ  ｆｉｅｌｄは、提供者（ｐｒｏｖｉｄｅｒ）別に伝送され得るディスクリプタの数を示すことができる。
【１６２７】
Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ  ｆｉｅｌｄは、提供者（ｐｒｏｖｉｄｅｒ）別に伝送されるディスクリプタを示すことができる。
【１６２８】
放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述した少なくとも一つのＰｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄを含むことができる。
【１６２９】
放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいて少なくとも一つのサービスを取得し、当該サービスの提供者を識別することができる。
【１６３０】
図１４５は、本発明の一実施例に係るＦＩＣを示す図である。
【１６３１】
本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ  ｆｉｅｌｄ、ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄ、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ  ｆｉｅｌｄ、ＳＣＤ＿ＤＰ＿ＩＤ  ｆｉｅｌｄ、Ｎｕｍ＿ｐｒｏｖｉｄｅｒｓ  ｆｉｅｌｄ、ｐｒｏｖｉｄｅｒ＿ｉｄ  ｆｉｅｌｄ、ｎｕｍ＿ｓｅｒｖｉｃｅｓ  ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｉｄ  ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ  ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ  ｆｉｅｌｄ、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ  ｆｉｅｌｄ、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ  ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ  ｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ  ｆｉｅｌｄ、ｓｐ＿ｉｎｄｉｃａｔｏｒ  ｆｉｅｌｄ、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ  ｆｉｅｌｄ、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ  ｆｉｅｌｄ、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ  ｆｉｅｌｄ、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ  ｆｉｅｌｄ、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ  ｆｉｅｌｄ、ＳＳＣ＿ＴＳＩ  ｆｉｅｌｄ、ＳＳＣ＿ＤＰ＿ＩＩＤ  ｆｉｅｌｄ、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄ、ｎｕｍ＿Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ  ｆｉｅｌｄ、Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）ｆｉｅｌｄ、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ  ｆｉｅｌｄ、及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）ｆｉｅｌｄのうち少なくとも一つを含むことができる。本発明の一実施例に係るＦＩＣに含まれる情報は、前述したＦＩＣに含まれる情報の内容を全て含むことができる。
【１６３２】
本発明の一実施例に係るＦＩＣは、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示す性能情報（又は、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄ）をさらに含むことができる。
【１６３３】
例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄは、当該サービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを示すことができる。例えば、ＵＤ／ＨＤ  ｓｃａｌａｂｌｅ  ｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄは、ＨＤを示す値を有することができる。
【１６３４】
放送受信装置はＦＩＣを受信し、ＦＩＣの性能情報（又は、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄ）に基づいて、デバイス性能（ｄｅｖｉｃｅ  ｃａｐａｂｉｌｉｔｙ）に符合する差別化されたチャネルマップを構成（又は、生成）することができる。また、放送受信装置は、ＦＩＣの性能情報（又は、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄ）に基づいてサービスのための少なくとも一つのコンポーネントを取得することができる。その後、放送受信装置は、サービスのための少なくとも一つのコンポーネントをデコーティングすることができる。
【１６３５】
図１４６は、本発明の一実施例に係るＦＩＣを示す図である。
【１６３６】
特定の周波数を有する放送信号はシグナリング情報を含むことができる。例えば、放送信号は「ＢＣＳｔｒｅａｍＩＤ１」で識別されてもよい。シグナリング情報は、ＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣは、ＳＬＴと呼ぶことができる。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。
【１６３７】
放送信号は、第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、少なくとも一つのサービスを含むことができる。例えば、サービスの識別子は、「ＳｒｖｃＩＤ１」の値を有することができる。サービスは、ＨＤサービス及び／又はＵＨＤサービスのための少なくとも一つのコンポーネントを含むことができる。ＨＤサービスのためのコンポーネントは、第１ＲＯＵＴＥセッションの特定伝送セッションを介して伝送されてもよい。ＵＨＤサービスのための付加情報は、第１ＲＯＵＴＥセッションの他の伝送セッションを介して伝送されてもよい。
【１６３８】
サービスに対してサービスレイヤシグナリング情報が存在してもよい。例えば、ＨＤサービス及び／又はＵＨＤサービスに対して、第１ＲＯＵＴＥセッションにＨＤサービス及び／又はＵＨＤサービスのためのサービスレイヤシグナリング情報が存在してもよい。ここで、サービスレイヤシグナリング情報は、ＬＳＩＤ及びＳＳＣ（ＳＭＴ、ＭＤＰ、及び／又はＣＭＴ）のうち少なくとも一つを含むことができる。
【１６３９】
第１ＲＯＵＴＥセッションは、ｓｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓ（ｓＩＰＡｄｒｓ１）、ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ  Ａｄｄｒｅｓｓ（ＩＰＡｄｒｓ１）、及びｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ  ｎｕｍｂｅｒ（Ｐｏｒｔ１）の組合せで識別されてもよい。また、第１ＲＯＵＴＥセッションは、第１ＤＰ（ＤＰ＿ＩＤ１）、第２ＤＰ（ＤＰ＿ＩＤ２）、及び／又は第３ＤＰ（ＤＰ＿ＩＤ３）を介して伝送されてもよい。また、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−０）、第２伝送セッション（ｔｓｉ−ｓ）、第３伝送セッション（ｔｓｉ−ａ）、第４伝送セッション（ｔｓｉ−ｖ）、及び／又は第５伝送セッション（ｔｓｉ−ｅｖ）を含むことができる。第１伝送セッション（ｔｓｉ−０）は、ＬＳＩＤ及び／又は少なくとも一つのＬＳＩＤフラグメントを含むことができる。第２伝送セッション（ｔｓｉ−ｓ）は、シグナリングテーブル及び／又は少なくとも一つのＳＳＣフラグメントを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴのうち少なくとも一つを含むことができる。第３伝送セッション（ｔｓｉ−ａ）は、オーディオコンポーネントを含むことができる。例えば、オーディオコンポーネントは少なくとも一つのオーディオセグメントを含むことができる。第４伝送セッション（ｔｓｉ−ｖ）は、ベースビデオコンポーネントを含むことができる。例えば、ベースビデオコンポーネントは少なくとも一つのベースビデオセグメントを含むことができる。例えば、ベースビデオコンポーネントは、ＨＤサービスを提供するためのビデオコンポーネントである。第５伝送セッション（ｔｓｉ−ｅｖ）は、エンハンスメントビデオコンポーネントを含むことができる。例えば、エンハンスメントビデオコンポーネントは少なくとも一つのエンハンスメントビデオセグメントを含むことができる。例えば、エンハンスメントビデオコンポーネントは、ＵＨＤサービスを提供するためのビデオコンポーネント及び／又は付加情報である。
【１６４０】
以下ではＦＩＣについて説明する。
【１６４１】
ＦＩＣは、Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ（ＳＬＴ）と呼ぶことができる。本発明の一実施例に係るＦＩＣに関連した内容は、前述したＦＩＣに関連した内容を全て含むことができる。
【１６４２】
ＦＩＣは、「ＢＣＳｔｒｅａｍＩＤ１」の値を有する識別子ｅｌｅｍｅｎｔ及び／又は第１サービスエレメントを含むことができる。
【１６４３】
第１サービスエレメントは、「ＳｒｖｃＩＤ１」の値を有するｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ、「ＨＤ」の値を有するｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔを含むことができる。ＳＳＣ＿Ｂｏｏｔｓｔｒａｐ  ｅｌｅｍｅｎｔは、「ｓＩＰＡｄｒｓ１」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「ＩＰＡｄｒｓ１」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、「Ｐｏｒｔ１」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅ、「ｔｓｉ−ｓ」の値を有するＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又は「ＤＰ＿ｉｄ１」の値を有するＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ここで、「ＨＤ」の値を有するｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは、サービスが支援する最小限の性能（Ｃａｐａｂｉｌｉｔｙ）コードが「ＨＤ」であることを示すことができる。すなわち、サービスが「ＨＤ」及び「ＵＨＤ」の両方を支援できる場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅは「ＨＤ」の値を有することができる。
【１６４４】
図１４７は、本発明の一実施例に係るＳＳＣを示す図である。
【１６４５】
以下では、ＳＭＴについて説明する。
【１６４６】
同図の（ａ）を参照すると、ＳＭＴは、サービスの属性（ＩＤ、名前、カテゴリーなど）情報及びサービスを取得し得る経路情報を含むことができる。本発明の一実施例に係るＳＭＴに関連した内容は、前述したＳＭＴに関連した内容を全て含むことができる。
【１６４７】
ＳＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤ  ａｔｔｒｉｂｕｔｅ、サービスの名前を識別するＳｅｒｖｉｃｅＮａｍｅ  ａｔｔｒｉｂｕｔｅ、サービスを支援するデバイスの性能を示すＣａｐａｂｉｌｉｔｙ  ａｔｔｒｉｂｕｔｅ、及び／又はサービスのためのＲＯＵＴＥセッションのブートストラップ情報を含むＲＯＵＴＥｓｅｓｓｉｏｎ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。
【１６４８】
例えば、Ｃａｐａｂｉｌｉｔｙ  ａｔｔｒｉｂｕｔｅは、「ＨＤ」及び「ＵＨＤ」の値を有することができる。すなわち、Ｃａｐａｂｉｌｉｔｙ  ａｔｔｒｉｂｕｔｅは、ＨＤ及びＵＨＤの両方を支援することを示すことができる。
【１６４９】
以下では、ＭＰＤについて説明する。
【１６５０】
ＭＰＤは、リニア／ストリーミングサービスの個別的なメディアコンポーネントのためのリソース識別子を含むことができる。本発明の一実施例に係るＭＰＤに関連した内容は、前述したＭＰＤに関連した内容を全て含むことができる。
【１６５１】
ＭＰＤは、ピリオドエレメント（Ｐｅｒｉｏｄ  ｅｌｅｍｅｎｔ）を含むことができる。Ｐｅｒｉｏｄ  ｅｌｅｍｅｎｔは、少なくとも一つのオーディオコンポーネントに関する情報を含む第１のＡｄａｐｔａｔｉｏｎＳｅｔ  ｅｌｅｍｅｎｔ、及び少なくとも一つのビデオコンポーネントに関する情報を含む第２のＡｄａｐｔａｔｉｏｎＳｅｔ  ｅｌｅｍｅｎｔを含むことができる。第１のＡｄａｐｔａｔｉｏｎＳｅｔ  ｅｌｅｍｅｎｔは、オーディオコンポーネントに関する情報を含む第１リプレゼンテーションエレメントを含むことができる。第２のＡｄａｐｔａｔｉｏｎＳｅｔ  ｅｌｅｍｅｎｔは、ベースビデオコンポーネントに関する情報を含む第２リプレゼンテーションエレメント、及びエンハンスメントビデオコンポーネントに関する情報を含む第３リプレゼンテーションエレメントを含むことができる。
【１６５２】
第１リプレゼンテーションエレメント内のｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ａ」であり、第２リプレゼンテーションエレメント内のｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｖ」であり、第３リプレゼンテーションエレメント内のｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｅｖ」であってもよい。また、第３リプレゼンテーションエレメントは、ｄｅｐｅｎｄｅｎｃｙＩｄ  ａｔｔｒｉｂｕｔｅを含むことができ、ｄｅｐｅｎｄｅｎｃｙＩｄ  ａｔｔｒｉｂｕｔｅの値は、「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｖ」を示すことができる。
【１６５３】
以下では、ＣＭＴについて説明する。
【１６５４】
ＣＭＴは、サービスのためのコンポーネントデータの伝送経路情報を含むことができる。本発明の一実施例に係るＣＭＴに関連した内容は、前述したＣＭＴに関連した内容を全て含むことができる。
【１６５５】
ＣＭＴは、第１サービスのための第１コンポーネントマップ情報を含むことができる。第１コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤ  ａｔｔｒｉｂｕｔｅ、第１サービスのためのオーディオコンポーネントの伝送経路情報を含む第１Ｃｏｍｐ  ｅｌｅｍｅｎｔ（又は、ＢＣＣｏｍｐｏｎｅｎｔ  ｅｌｅｍｅｎｔ）、第１サービスのためのベースビデオコンポーネントの伝送経路情報を含む第２Ｃｏｍｐ  ｅｌｅｍｅｎｔ（又は、ＢＣＣｏｍｐｏｎｅｎｔ（ＨＤ）  ｅｌｅｍｅｎｔ）、及び／又は第１サービスのためのエンハンスメントビデオコンポーネントの伝送経路情報を含む第３のＣｏｍｐ  ｅｌｅｍｅｎｔ（又は、ＢＣＣｏｍｐｏｎｅｎｔ（ＵＤ）  ｅｌｅｍｅｎｔ）のうち少なくとも一つを含むことができる。
【１６５６】
例えば、第１サービスのための第１のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ａ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ１」であってもよい。また、第１サービスのための第２のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｖ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ２」であってもよい。また、第１サービスのための第３のＣｏｍｐ  ｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｅｖ」であり、ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ３」であってもよい。
【１６５７】
以下では、ＬＳＩＤについて説明する。
【１６５８】
ＬＳＩＤは、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶことができる。本発明の一実施例に係るＬＳＩＤに関連した内容は、前述したＬＳＩＤに関連した内容を全て含むことができる。
【１６５９】
ＬＳＩＤは、第１ＲＯＵＴＥセッションに含まれてもよい。ＬＳＩＤは、オーディオコンポーネントを伝送する第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ、ベースビデオコンポーネントを伝送する第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ、及び／又はエンハンスメントビデオコンポーネントを伝送する第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ内のｔｓｉ  ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ａ」であり、ｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ａ」であってもよい。また、第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ内のｔｓｉ  ａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ｖ」であり、ｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｖ」であってもよい。また、第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ  ｅｌｅｍｅｎｔ内のｔｓｉ  ａｔｔｒｉｂｕｔｅの値の「ｔｓｉ−ｅｖ」であり、ｒｅｐｔｎＩＤ  ａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｅｖ」であってもよい。
【１６６０】
図１４８は、本発明の一実施例に係る放送伝送方法の流れを示す図である。
【１６６１】
本発明の一実施例に係る放送伝送装置は、制御部及び／又は伝送部を含むことができる。制御部は、前述したサービスデータ及び／又は、前述したシグナリング情報を生成することができる。また、伝送部は、サービスデータ及び／又はシグナリング情報を含む放送信号を伝送することができる。
【１６６２】
放送伝送装置は、制御部を用いて、同一のコンデンツを提供する少なくとも一つのサービスのためのサービスデータを生成及び／又はエンコーディングできる（ＣＳ１４８０１００）。
【１６６３】
例えば、サービスデータは、オーディオコンポーネント、ベースビデオコンポーネント、及び／又はエンハンスメントビデオコンポーネントを含むことができる。
【１６６４】
また、放送伝送装置は、制御部を用いて、サービスのためのシグナリング情報を生成及び／又はエンコーディングすることができる（ＣＳ１４８０２００）。
【１６６５】
例えば、シグナリング情報は、サービスの取得のための第１シグナリング情報（又は、ＳＬＳ）及び／又はサービスのためのブートストラップ情報を含む第２シグナリング情報（又は、ＦＩＣ）を含むことができる。第１シグナリング情報（又は、ＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。第２シグナリング情報（又は、ＦＩＣ）は、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示す性能情報（例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅ）をさらに含むことができる。例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄは、当該サービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを示すことができる。例えば、ＵＤ／ＨＤ  ｓｃａｌａｂｌｅ  ｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄは、ＨＤを示す値を有することができる。また、ＦＩＣは、同一のコンデンツを提供する少なくとも一つのサービスのチャネル番号を示すチャネル情報（又は、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅ）を含むことができる。また、シグナリング情報は、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するか否かを示すフラグ情報（ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄ）、及び／又は第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す識別子情報（ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄ）をさらに含むことができる。
【１６６６】
また、放送伝送装置は、制御部を用いて、サービスデータ及びシグナリング情報を含む放送信号を生成することができる。
【１６６７】
また、放送伝送装置は、伝送部を用いて、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる（ＣＳ１４８０３００）。
【１６６８】
図１４９は、本発明の一実施例に係る放送受信方法の流れを示す図である。
【１６６９】
本発明の一実施例に係る放送受信装置は、ブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部のうち少なくとも一つを含むことができる。本発明の一実施例に係るブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部は、前述した内容を全て含むことができる。
【１６７０】
例えば、ブロードキャストインターフェースは放送網で放送信号を受信することができる。ブロードキャストインターフェースは、フィジカルレイヤモジュール、フィジカルレイヤＩＰフレームモジュールを含むことができる。又は、ブロードキャストインターフェースは、チューナー及びフィジカルフレームパーサーのうち少なくとも一つを含むことができる。
【１６７１】
例えば、ブロードバンドインターフェースは、インターネット網を介してデータを伝送及び／又は受信することができる。ブロードバンドインターフェースはインターネット接近制御モジュールを含むことができる。
【１６７２】
例えば、制御部は、前述したシグナリングデコーダ、データベース、サービスシグナリングマネジャー、アラートシグナリングマネジャー、サービスガイドマネジャー、アプリケーションシグナリングマネジャー、ターゲッティングシグナリングマネジャー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネント同期化部、ターゲッティングプロセッサ、アプリケーションプロセッサ、アラーティングプロセッサ、Ａ／Ｖプロセッサ、再分配モジュール、サービス／コンテンツ取得制御部、及び／又はコンパニオンスクリーンインターフェースのうち少なくとも一つを含むことができる。コンパニオンスクリーンインターフェースは、データシェアリング部及び／又は装置管理者のうち少なくとも一つを含むことができる。本発明の一実施例に係る制御部に含まれる構成要素に関する内容は、前述した同一又は類似の名称を有する構成要素に関する内容を全て含むことができる。
【１６７３】
また、制御部は、前述したフィジカルレイヤ制御部、リンクレイヤフレームパーサー（又は、リンクレイヤフレームプロセッサ）、ＩＰ／ＵＤＰデータグラムフィルター、アプリケーションレイヤ伝送クライアント、タイミングコントロール、システムクロック、ＤＴＶコントロールエンジン、ユーザ入力受信部、シグナリングパーサー、チャネルマップデータベース、ＨＴＴＰアクセスクライアント、ＨＴＴＰアクセスキャッシュ、ＤＡＳＨクライアント、ＩＳＯ ＢＭＦＦパーサー、メディアデコーダ及びファイルデータベースのうち少なくとも一つを含むことができる。本発明の一実施例に係る制御部に含まれる構成要素に関する内容は、前述した同一又は類似の名称を有する構成要素に関する内容を全て含むことができる。
【１６７４】
放送受信装置は、ブロードキャストインターフェース及び／又はブロードバンドインターフェースを用いて、同一のコンデンツを提供する少なくとも一つのサービスのためのサービスデータ及びシグナリング情報を含む放送信号を受信することができる（ＣＳ１４９０１００）。
【１６７５】
サービスデータは、オーディオコンポーネント、ベースビデオコンポーネント、及び／又はエンハンスメントビデオコンポーネントを含むことができる。シグナリング情報は、サービスの取得のための第１シグナリング情報（又は、ＳＬＳ）、及び／又はサービスのためのブートストラップ情報を含む第２シグナリング情報（又は、ＦＩＣ）を含むことができる。第１シグナリング情報（又は、ＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。第２シグナリング情報（又は、ＦＩＣ）は、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示す性能情報（例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅ）をさらに含むことができる。例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄは、当該サービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを示すことができる。例えば、ＵＤ／ＨＤ  ｓｃａｌａｂｌｅ  ｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ  ｆｉｅｌｄは、ＨＤを示す値を有することができる。また、ＦＩＣは、同一のコンデンツを提供する少なくとも一つのサービスのチャネル番号を示すチャネル情報（又は、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ  ａｔｔｒｉｂｕｔｅ）を含むことができる。また、シグナリング情報は、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するか否かを示すフラグ情報（ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇ  ｆｉｅｌｄ）、及び／又は第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す識別子情報（ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄ  ｆｉｅｌｄ）をさらに含むことができる。
【１６７６】
例えば、ユーザが第１サービス（ＳｒｖｃＩＤ１）を選択した場合、放送受信装置はＦＩＣに基づいて、ｍｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｃｏｄｅ  ｆｉｅｌｄを取得することができる。また、放送受信装置はＦＩＣに基づいて、少なくとも一つのサービスに対するｍｉｎｉｍｕｍ  Ｃａｐａｂｉｌｉｔｙ  ｃｏｄｅ  ｆｉｅｌｄを取得することができる。本発明の一実施例に係る第１サービスは、ＵＤ／ＨＤの両方を支援できるサービスであってもよく、この場合、ｍｉｎｉｍｕｍ  Ｃａｐａｂｉｌｉｔｙ  ｃｏｄｅは、ＨＤを示すことができる。
【１６７７】
また、放送受信装置は、制御部を用いて、放送信号から第２シグナリング情報（又は、ＦＩＣ）を取得することができる。例えば、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するか否かを示すフラグ情報が「Ｔｒｕｅ」を示すと、放送受信装置はフラグ情報に基づいて、放送信号から第２シグナリング情報を取得することができる。
【１６７８】
また、放送受信装置は、制御部を用いて、第２シグナリング情報（又は、ＦＩＣ）からサービス属性及び／又は第１シグナリング情報（又は、サービスレイヤシグナリング情報、ＳＬＳ）のブートストラップ情報を取得することができる。例えば、第２シグナリング情報（又は、ＦＩＣ）は、ｓｅｒｖｉｃｅ＿ｉｄ  ａｔｔｒｉｂｕｔｅ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔ  ａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｔｓｉ  ａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿ＤＰ＿ｉｄ  ａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。
【１６７９】
また、放送受信装置は、制御部を用いて、シグナリング情報に基づいてサービスをフィルタリングすることができる（ＣＳ１４９０２００）。
【１６８０】
例えば、第２シグナリング情報（又は、ＦＩＣ）は、サービスのデコーディングのために要求される性能情報を含み、放送受信装置は、性能情報に基づいて、デコーディング及び／又はプレゼンテーションし得るサービスをフィルタリングすることができる。また、フィルタリングされたサービスは複数であり、取得された第１シグナリング情報は、全てのフィルタリングされたサービスの取得のための情報であってもよい。
【１６８１】
また、放送受信装置は、制御部を用いて、フィルタリングされたサービスのためのサービス属性及び／又はサービスレイヤシグナリング情報（ＳＬＳ）のブートストラップ情報をチャネルマップに一時的に保存することができる。
【１６８２】
また、放送受信装置は、制御部を用いて、第２シグナリング情報（又は、ＦＩＣ）に基づいて、フィルタリングされたサービスのための第１シグナリング情報（又は、ＳＬＳ）を取得することができる（ＣＳ１４９０３００）。
【１６８３】
例えば、放送受信装置は、第２シグナリング情報（又は、ＦＩＣ）から、フィルタリングされたサービスのための第１シグナリング情報（又は、ＳＬＳ）ブートストラップ情報を取得し、第１シグナリング情報（又は、ＳＬＳ）ブートストラップ情報に基づいて第１シグナリング情報（又は、ＳＬＳ）を取得することができる。例えば、第１シグナリング情報（又は、ＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。放送受信装置は、第１シグナリング情報（又は、ＳＬＳ）に基づいて、いずれのリプレゼンテーションが放送網を介して伝送されるかを決定することができる。
【１６８４】
また、放送受信装置は、制御部を用いて、フィルタリングされたサービスのための取得された第１シグナリング情報（又は、ＳＬＳ）に含まれた情報をチャネルマップに２次的に保存することができる（ＣＳ１４９０４００）。
【１６８５】
例えば、第１シグナリング情報（又は、ＳＬＳ）に含まれた情報は、サービスの属性（ＩＤ、名前、カテゴリーなど）、サービスを取得し得る経路情報、及び／又はサービスと関連した情報を含むことができる。サービスを取得し得る経路情報は、サービスのためのコンポーネントと関連するリプレゼンテーションを識別する情報（ｒｅｐｔｎＩｄ  ａｔｔｒｉｂｕｔｅ）、サービスのためのコンポーネントデータが伝送されるＤＰ（又は、ＰＬＰ）を識別する情報（ｄａｔａｐｉｐｅＩＤ  ａｔｔｒｉｂｕｔｅ）、及び／又はサービスのためのコンポーネントが伝送される伝送セッションを識別する情報（ｔｓｉ  ａｔｔｒｉｂｕｔｅ）のうち少なくとも一つを含むことができる。
【１６８６】
また、フィルタリングされたサービスが複数であれば、放送受信装置は、制御部を用いて、チャネル情報に基づいて複数のサービスの中から一つのサービスを選択することができる。
【１６８７】
また、放送受信装置は、制御部を用いて、チャネルマップに基づいてサービスデータを取得することができる。
【１６８８】
また、放送受信装置は、制御部を用いて、サービスデータをデコーディングすることができる。
【１６８９】
本発明の一実施例に係る放送受信装置がベースレイヤのベースビデオコンポーネントを受信及び／又は取得すると、放送受信装置は、ＨＤと関連したコンポーネントをデコーティングして出力することができる。
【１６９０】
また、放送受信装置がＵＨＤと関連したコンポーネントをデコーディング及び／又は出力するためには、ベースレイヤのベースビデオコンポーネント及びエンハンスメントレイヤのエンハンスメントビデオコンポーネントの両方をデコーディングしなければならない。
【１６９１】
仮に放送受信装置がＳＤまでしか支援できないと、放送受信装置は第１サービスを再生することができないはずである。
【１６９２】
仮に放送受信装置がＨＤを支援できる場合には、放送受信装置は、ＳＳＣに基づいて、より詳細なサービス関連情報を受信することができる。また、放送受信装置は、ＳＳＣから、サービスの全ての性能情報（ｃａｐａｂｉｌｉｔｙ）を取得することができる。また、放送受信装置は、ＭＰＤ内の情報（ｅ．ｇ．Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＠ｄｅｐｅｎｄｅｎｃｙＩｄ）を用いて、ｒｅｐｒｅｓｅｎｔａｔｉｏｎ間のｄｅｐｅｎｄｅｎｃｙ関係（すなわち、ｂａｓｅ／ｅｎｈａｎｃｅｄ  ｌａｙｅｒ）、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの解像度（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎのｗｉｄｔｈ／ｈｅｉｇｈｔ  ａｔｔｒｉｂｕｔｅ）などを認知することができる。また、本発明の一実施例に係るＳＭＴのｃａｐａｂｉｌｉｔｙは、ＨＤ／ＵＤの２つの性能情報（ｃａｐａｂｉｌｉｔｙ）を有することができる。仮に放送受信装置がＵＤを支援できない場合には、放送受信装置は、ＨＤに該当するコンポーネントを受信及び／又はデコーティングすることができる。
【１６９３】
仮に放送受信装置がＵＤを支援できる場合には、放送受信装置は、前述したシナリオを行った後、ＵＤに該当するコンポーネントを受信及び／又はデコーティングすることができる。
【１６９４】
図１５０は、本発明の一実施例に係る、受信機移動時における他の周波数へのハンドオーバー（ｈａｎｄｏｖｅｒ）状況を示す図である。
【１６９５】
特定サービスを受信している受信機が移動する場合、そのサービスをシームレス（ｓｅａｍｌｓｓ）に視聴するための他の周波数へのハンドオーバー動作が必要であろう。ここで、受信機が移動する場合は、様々な状況があり、特に、受信機がモバイルデバイスである場合に該当し得る。
【１６９６】
特定サービスを提供する送信機は地域別に複数個存在してもよい。受信機が、特定送信機がカバーする地域を離れて他の送信機がカバーする地域へ移動する場合には、シームレスハンドオーバーのための情報又は動作がさらに必要である。ここで、ＭＦＮ状況を仮定する。同じサービスが地域別に異なる周波数を介して送出される状況を仮定する。
【１６９７】
同図の実施例で、受信機は、送信機Ａ（Ｔｒａｎｓｍｉｔｔｅｒ  Ａ）のカバーする地域を離れて、送信機Ｂのカバーする地域へ移動することができる。この間に、受信機はサービスＸを視聴していると仮定する。ここで、送信機ＡはサービスＸを周波数１０で送出しており、送信機Ｂは、同じサービスＸを周波数２０で送出しているとする。サービスＸを持続して再生するために、受信機は、適切な周波数にチューニングするための情報を必要としてもよい。
【１６９８】
図１５１は、本発明の一実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。
【１６９９】
前述したように、シームレスハンドオーバーのために、受信機は適切な情報を必要としてもよい。このような情報は、実施例によって、前述したＬＬＳ（Ｌｉｎｋ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）、ＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）、ＳＳＣ（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ）又はそれぞれのＳＬＳ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）を介して伝達され得る。ここで、シームレスハンドオーバーのための情報をＣＩＤ（Ｃｅｌｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶことができる。
【１７００】
同図の実施例は、ＣＩＤがリンクレイヤシグナリングを介して伝達される場合を示している。
【１７０１】
同図の実施例で、ブロードキャストストリームを介してサービスデータが伝達されている。このブロードキャストストリームは、ブロードキャストストリームＩＤで識別することができる。ブロードキャストストリームは、特定大域幅の中央周波数値と定義されるＲＦチャネルのアブストラクション（ａｂｓｔｒａｃｔｉｏｎ）であり、地域（ａｒｅａ）と周波数（ｆｒｅｑｕｅｎｃｙ）情報で識別されてもよい。ブロードキャストストリームは複数個のＰＬＰを含むことができる。ＰＬＰは、ＤＰと呼ぶこともできる。本実施例では、ＢＳＩＤ＝１で識別されるブロードキャストストリームでサービスデータが伝達されている。
【１７０２】
前述した伝送セッション、ＲＯＵＴＥ／ＭＭＴＰセッションは、複数個のＰＬＰを介して伝送されてもよい（ＰＬＰ  ＩＤ＝１，２，３）。伝送セッション、例えば、ＲＯＵＴＥセッションはＩＰ、ＵＤＰ情報（ＩＰ  ａｄｄｒｅｓｓ  １，ＵＤＰ  ｐｏｒｔ  ｎｕｍｂｅｒ  １）によって識別されてもよく、複数個のＬＣＴセッションを含むことができる。各ＬＣＴセッションは、サービスデータであるオーディオ／ビデオセグメントを伝達することができる。前述したように、特定ＬＣＴセッション（例えば、ｔｓｉ＝０のＬＣＴセッション）を介してＳＬＳが伝達されてもよい。同図の実施例では、これをＳＣＳフラグメントと表現している（ｔｓｉ＝ｓ）。同図の実施例では、ＬＳＩＤが用いられ、これが他のＬＣＴセッションで伝達されると表現しているが、実施例によって、ＬＳＩＤは前述のＳ−ＴＳＩＤに代替してもよく、このＳ−ＴＳＩＤは、ＳＬＳに含まれて伝達されてもよい。また、ＦＩＣが用いられ、このＦＩＣがＰＬＰではなく別途のチャネルで伝達されると表現しているが、実施例によって、ＦＩＣをＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）及びＳＬＴに代替してもよく、このＬＬＳは、前述したように、知られた（ｗｅｌｌ  ｋｎｏｗｎ）ＩＰ／ＵＤＰを介して伝達されてもよい。
【１７０３】
本実施例で、ＣＩＤは、リンクレイヤシグナリングを介して伝達される（ｔ１５１０１０）。現在周波数で送出される全てのサービスに対して、隣接した送信機ではそれを他の周波数で送出している場合、これに関連した情報を一つのＣＩＤ内に取り集めることができる。
【１７０４】
この場合、リンクレイヤシグナリングがＣＩＤ情報を含むことができる。リンクレイヤシグナリングは、受信機が、ＳＬＴ、ＳＬＳなどの情報よりも先に取得できる情報であり、受信機でＣＩＤが早く取得されるようにすることができる。もちろん、隣接送信機が一部のサービスに対してのみ他の周波数で送出している場合にも、リンクレイヤシグナリングを介してＣＩＤが伝達されてもよい。この場合、ＣＩＤは、サービス別にハンドオーバー情報を有することができる。例えば、一つの周波数に５つのサービスが含まれて伝送される場合、そのうち２つのサービスに対してのみ隣接送信機が他の周波数で送出されていると、ＣＩＤは、その２つのサービスに対するハンドオーバー情報を提供することができる。残り３つのサービスに対してはハンドオーバー情報が必要でないので、ＣＩＤは、関連情報を含まないか、又はサービスを同一周波数で送出している送信機に関する情報を含むこともできる。
【１７０５】
シームレスハンドオーバーのための情報又はＣＩＤ情報に関する詳細な内容は後述する。
【１７０６】
図１５２は、本発明の他の実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。
【１７０７】
前述したように、シームレスハンドオーバーのための情報は、ＳＬＳに含まれて伝送されてもよい（ｔ１５２０１０）。ＳＬＳが含まれて伝送されるＬＣＴセッションをＳＳＣ（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ）と呼ぶこともできる。
【１７０８】
前述したように、ＳＬＳは、各サービス別に、そのサービスに対するシグナリングを行うことができる。ＳＬＳにＣＩＤ情報が含まれて伝送される場合、当該ＣＩＤは、そのＳＬＳがシグナリングするサービスに対するハンドオーバー情報を含むことができる。
【１７０９】
例えば、ＳＬＳがサービス＃１をシグナリングする場合、そのＳＬＳに含まれて伝送されるＣＩＤは、サービス＃１を、同一の又は他の周波数で伝送する他の隣接送信機に関する情報を含むことができる。したがって、移動している受信機は、当該ＣＩＤ情報を用いてサービス＃１をシームレスに再生することができる。
【１７１０】
ここで、ＣＩＤがＳＬＳに含まれて送信されるという意味は、実施例によって、ＳＬＳにＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどと共にＣＩＤが含まれるという意味であってもよい。また、実施例によって、ＳＬＳに含まれるＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどが拡張されてＣＩＤ情報を含むという意味であってもよい。また、実施例によって、ＣＩＤが、ＳＬＳに含まれるＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどに分散されて送信されるという意味であってもよい。また、実施例によって、ＳＬＳに該当する情報を用いて、受信機がＣＩＤに該当する情報を計算し得るという意味であってもよい。
【１７１１】
図示してはいないが、前述したように、ＣＩＤ情報は、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）、ＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）などを介して伝達されてもよい。ローレベルシグナリング又はＳＬＴを介して伝達される場合、前述したＳＬＴなどのための周知のＩＰ／ＵＤＰによってＣＩＤが伝達されてもよい。当該ＣＩＤは、ＳＬＴによって記述されるサービス又は当該ブロードキャストストリームで伝達されるサービスに対するハンドオーバー情報を含むことができる。
【１７１２】
図１５３は、本発明の一実施例に係るシームレスハンドオーバーのための情報を示す図である。
【１７１３】
前述したように、このハンドオーバーのための情報をＣＩＤと呼ぶこともできる。ＣＩＤは、隣接送信機で送出している同一サービスにハンドオーバーできるように、送信機の位置、信号強度などの情報を提供することができる。ＣＩＤは、実施例によって異なるように構成されてもよく、後述するホームセル送信機に関する情報とサービス別セルに関する情報のいずれか一方を有することもできる。ここで、ホームセル送信機とは、それぞれの複数個の放送サービスを伝送する現在周波数と同じ周波数を用いて、同一の複数個の放送サービスを送出している他の送信機を意味することができる。ここで、サービス別セルに関する情報とは、特定サービスを伝送する現在周波数と異なる周波数を用いて、その特定サービスを送出している他の隣接送信機に関する情報を意味することができる。
【１７１４】
ＣＩＤは、当該ＣＩＤに対する情報を示す部分、ホームセル送信機に関する情報を示す部分、及びサービス別に該当のサービスを伝達する隣接送信機に対する部分を含むことができる。実施例によって、いずれかの部分が省略／変更されてもよく、新しい情報が追加されてもよい。例えば、ホームセル送信機が存在しない場合、サービス別隣接送信機に関する情報だけが含まれてもよい。ホームセル送信機及び隣接送信機は０個以上が存在すればよい。
【１７１５】
ＣＩＤは、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄを含むことができる。
【１７１６】
＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎと＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎはそれぞれ、当該ＣＩＤのメジャー／マイナープロトコルバージョン情報を示すことができる。
【１７１７】
＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄは、ＣＩＤに該当するブロードキャストストリームの識別子であってもよい。ここで、ＣＩＤに該当するブロードキャストストリームは、当該ＣＩＤを送信しているブロードキャストストリームであってもよく、単純に当該ＣＩＤが記述している他のブロードキャストストリームであってもよい。
【１７１８】
ＣＩＤは、Ｈｏｍｅ＿ｃｅｌｌ＿ｔｒａｎｓｍｉｔｔｅｒｓエレメントを複数個含むことができる。これは、前述したホームセル送信機に関する情報に該当し得る。各Ｈｏｍｅ＿ｃｅｌｌ＿ｔｒａｎｓｍｉｔｔｅｒｓエレメントは、＠ｌａｔｔｉｔｕｄｅ、＠ｌｏｎｇｉｔｕｄｅ、＠ＡＥＲＰ、＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈ及び／又は＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓなどの情報を含むことができる。
【１７１９】
＠ｌａｔｔｉｔｕｄｅは、当該ホームセル送信機の緯度情報を示すことができる。ここで、緯度情報は、度（ｄｅｇｒｅｅ）の小数第２位（ｔｅｎ−ｔｈｏｕｓａｎｄｔｈｓ）までの正確度で示すことができる。緯度情報は、正数／負数の緯度値に対するコンベンショナルな用法として表記されてもよい。
【１７２０】
＠ｌｏｎｇｉｔｕｄｅは、当該ホームセル送信機の経度情報を示すことができる。ここで、経度情報は、度（ｄｅｇｒｅｅ）の小数第２位（ｔｅｎ−ｔｈｏｕｓａｎｄｔｈｓ）までの正確度で示すことができる。経度情報は、正数／負数の経度値に対するコンベンショナルな用法として表記されてもよい。
【１７２１】
＠ＡＥＲＰは、当該ホームセル送信機の有効なＲＦ電力の理論的測定値であり、ＡＥＲＰは、Ａｖｅｒａｇｅ  Ｅｆｆｅｃｔｉｖｅ  Ｒａｄｉａｔｅｄ  Ｐｏｗｅｒの略語である。ｄＢｋの単位で表現することができ、Ｒａｄｉａｔｉｏｎのアンテナ中心の高さ（ｈｅｉｇｈｔ）によって調整することができる。
【１７２２】
＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈは、アンテナの方位角（ａｚｉｍｕｔｈ）パターンの、最大Ｎｕｌｌ値のデプス（ｄｅｐｔｈ）を示すことができる。この値は、８ｄＢの倍数で表現することができ、次に低い倍数値に切り下げて（ｒｏｕｎｄ  ｄｏｗｎ）示すことができる。２４ｄＢよりも大きい値はいずれも２４ｄＢと切り下げてもよい。００値は、該当するデータがないことを示すことができる。
【１７２３】
＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓは、アンテナの方位角パターンが８ｄＢ又はピークＡＥＲＰよりも低い場合において、オーディナルディレクション（ｏｒｄｉｎａｌ  ｄｉｒｅｃｔｉｏｎｓ）を示すことができる。これは、当該ビットポジションのゼロによって指示することができる。ノーザン（ｎｏｒｔｈｅｎ）セクターは、ｍｓｂ値によって示すことができる。それぞれの連続するビットは時計回り方向に進行することができ、したがって、ＮＥ（Ｎｏｒｔｈ  Ｅａｓｔ）の場合、すぐ次のｍｓｂ値によって示すことができる。このような方式でＮＷ（Ｎｏｒｔｈ  Ｗｅｓｔ）まで進行することができる。ＮＷの場合、ｌｓｂ値によって示すことができる。このフィールドの値が１１１１ １１１１の場合、該当するデータがないことを意味できる。
【１７２４】
ＣＩＤは、複数個のＳｅｒｖｉｃｅエレメントをさらに含むことができる。ここで、Ｓｅｒｖｉｃｅエレメントは、前述したサービス別セル情報に該当し得る。このサービスエレメントは、それぞれのサービスに対して、そのサービスを他の周波数で送出している周辺の受信機に関する情報を含むことができる。サービス当たり０個以上の隣接送信機が存在すればよい。
【１７２５】
Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅ＿ｉｄ及び／又は＠ｇｌｏｂａｌＵｎｉｑｕｅＳｅｒｉｖｅＩｄを含むことができる。それぞれは、当該サービスのサービスＩＤ及びグローバルにユニークなサービスＩＤを示すことができる。
【１７２６】
Ｓｅｒｖｉｃｅエレメントは、Ｃｅｌｌエレメントをさらに含むことができる。それぞれのＣｅｌｌエレメントは、隣接した送信機に関する情報を含むことができる。
【１７２７】
それぞれのＣｅｌｌエレメントは、＠ｌａｔｔｉｔｕｄｅ、＠ｌｏｎｇｉｔｕｄｅ、＠ＡＥＲＰ、＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈ及び／又は＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓを含むことができる。それぞれのフィールドは、当該セル、すなわち、隣接送信機に対する緯度／経度情報、ＡＥＲＰ情報、相対的パターンデプス情報、ヌルポジション情報などを示すことができる。フィールドに関する詳細な説明は、前述したとおりであり、ただし、この場合、ホームセル送信機に関する情報ではなく、当該サービスを他の周波数で送出している隣接送信機に関する情報である点が異なる。
【１７２８】
それぞれのＣｅｌｌエレメントは、＠ｆｒｅｑｕｅｎｃｙ、＠ｐｒｅａｍｂｌｅ、＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ、＠ＤＰ＿ｉｄ、＠ｐｒｏｖｉｄｅｒ＿ｉｄ、＠ｓｅｒｖｉｃｅ＿ｉｄ情報をさらに含むことができる。
【１７２９】
＠ｆｒｅｑｕｅｎｃｙは、当該サービスを他の周波数で送出している隣接送信機において、当該サービスを送出している他の周波数に関する情報を示すことができる。正確には、当該サービスを送出している帯域幅の中央周波数（ｃｅｎｔｅｒ  ｆｒｅｑｕｅｎｃｙ）情報を示すことができる。
【１７３０】
＠ｐｒｅａｍｂｌｅは、当該サービスを送信する他の周波数に対するプリアンブルシンボルに関する情報を示すことができる。ここで、プリアンブルシンボルとは、信号フレームのブートストラップ情報、Ｌ１情報、プリアンブル情報又はＰ１情報などを表すことができる。
【１７３１】
＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄは、当該隣接送信機が当該サービスを送出しているブロードキャストストリームの識別子を示すことができる。
【１７３２】
＠ＤＰ＿ｉｄは、当該隣接送信機が当該サービスを送出しているＰＬＰ又はＤＰの識別子を示すことができる。ここで、実施例によって、このフィールドは、当該サービスのＳＬＴ情報が伝達されるＰＬＰのＩＤ情報を示すことができる。また、実施例によって、このフィールドは、当該サービスのＳＬＳ情報が伝達されるＰＬＰのＩＤ情報を示すことができる。また、実施例によって、このフィールドは、当該サービスのサービスデータが伝達されるＰＬＰの情報を示すことができる。実施例によって、このフィールドは、サービス別に複数個存在してもよい。
【１７３３】
＠ｐｒｏｖｉｄｅｒ＿ｉｄは、当該隣接送信機が送出しているサービスのサービスプロバイダー識別子情報を示すことができる。
【１７３４】
＠ｓｅｒｖｉｃｅ＿ｉｄは、当該隣接送信機が送出しているサービスのサービス識別子を示すことができる。ホームセル送信機が送出している同一サービスに対して同一のＩＤ値を有することもでき、異なるＩＤ値を有することもできる。同一のＩＤ値を有する場合、このフィールドの値は、Ｓｅｒｖｉｃｅ＠ｓｅｒｖｉｃｅ＿ｉｄフィールドと同じ値を有することができる。
【１７３５】
図１５４は、本発明の一実施例に係るローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【１７３６】
ローレベルシグナリング情報は、物理層とローレベルシグナリングが伝達される層の上位層とを連結させる役割を担うシグナリング情報を含むことができる。受信機は、ローレベルシグナリング情報を用いて、物理層で伝達された放送信号から、所望の放送サービス／コンテンツを効率的に見つけることができる。
【１７３７】
ローレベルシグナリング情報はＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）を含むことができる。ＦＩＣは、別の名称にしてもよく、一例として、ＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）と命名することもできる。
【１７３８】
本発明の一実施例では、各サービスのＭｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅを定義し、それに対するシグナリング情報をＦＩＣに追加して、受信機のサービススキャン（ｓｅｒｖｉｃｅ  ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ  ｒｅｎｄｅｒｉｎｇ）が効率的に行われるようにする方案を提案する。
【１７３９】
同図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７４０】
ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、ＦＩＣシグナリング構造のプロトコルのバージョンを識別する。
【１７４１】
Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報は、放送ストリームを識別する情報である。
【１７４２】
ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報は、Ｓｅｒｖｉｃｅ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＳＣＤ）が伝送されるか（又は、存在するか）否かを示すことができる。ＳＣＤは、サービスレベルシグナリング情報を含むことができる。
【１７４３】
ＤＰ＿ｉｄ情報は、ローレベルシグナリング情報及び／又はサービスレベルシグナリング情報を伝送するデータパイプ（又は、ＰＬＰ）を識別する情報である。
【１７４４】
ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは、ＦＩＣレベルのディスクリプタを含むことができる。
【１７４５】
ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報は、ＦＩＣによってスキャンし得る放送サービスの個数を示す。
【１７４６】
ｐｒｏｖｉｄｅｒ＿ｉｄ情報は、放送サービスを提供するプロバイダーを識別する情報である。
【１７４７】
ｓｅｒｖｉｃｅ＿ｉｄ情報は、放送サービスを識別する情報である。
【１７４８】
ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、サービスシグナリングチャネル（ＳＳＣ、又はサービスレベルシグナリング）のバージョンを示す情報である。
【１７４９】
ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報は、サービスのチャネル番号を示す。
【１７５０】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、サービスのカテゴリーを識別する。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスがＡ／Ｖサービス、オーディオサービス、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）サービス、及び／又はＮＲＴ（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ）サービスであるかを示すことができる。
【１７５１】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、サービスの短いサービス名を表す情報の長さを示す情報である。
【１７５２】
ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報は、サービスの短いサービス名を示す。
【１７５３】
ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、サービスの状態を示す。例えば、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、サービスが、ａｃｔｉｖｅ状態、ｉｎａｃｔｉｖｅ状態、ｓｈｏｗ状態及び／又はｈｉｄｄｅｎ状態であることを示すことができる。
【１７５４】
ｓｐ＿ｉｎｄｉｃａｔｏｒ情報は、サービスにサービス保護（ｓｅｒｖｉｃｅ  ｐｒｏｔｅｃｔｉｏｎ）が適用されたかどうかを示す情報である。
【１７５５】
ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報は、サービスと関連したＩＰパケットに用いられるＩＰバージョン情報を示す情報である。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報のｔｒｕｅ、ｆａｌｓｅ値によって、ＩＰｖ４又はＩＰｖ６であることを示すことができる。
【１７５６】
ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報は、サービスシグナリングチャネルのソース（ｓｏｕｒｃｅ）ＩＰアドレスを示す情報が存在するか否か識別する情報である。
【１７５７】
ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、サービスをレンダリングするために要求される、受信機の最小性能を示す情報である。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣによってシグナリングされる放送サービスをレンダリングするために受信機が揃えるべき最小限の性能を識別する。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、当該サービスの表出（ｐｒｅｓｅｎｔａｔｉｏｎ）に必須の最小性能プロファイル（ｍｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅ）を表現する。このプロファイル（ｐｒｏｆｉｌｅ）に対して、ＦＩＣのｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報と関連付けて、その値の範囲を定義することができる。
【１７５８】
ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報は、サービスシグナリングチャネルを伝送するソース（ｓｏｕｒｃｅ）のＩＰアドレスを示す情報である。
【１７５９】
ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報は、サービスシグナリングチャネルに対するデスティネーション（ｄｅｓｃｔｉｎａｔｉｏｎ）のＩＰアドレスを示す情報である。
【１７６０】
ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報は、サービスシグナリングチャネルに対するデスティネーション（ｄｅｓｃｔｉｎａｔｉｏｎ）のＵＤＰポート番号を示す情報である。
【１７６１】
ＳＳＣ＿ＴＳＩ情報は、サービスシグナリングチャネルのデータを伝送する伝送セッションを識別する情報である。
【１７６２】
ＳＳＣ＿ＤＰ＿ｉｄ情報は、サービスシグナリングチャネルのデータを伝送するデータパイプを識別する情報である。
【１７６３】
ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報は、放送サービスが基本であるか否かを識別する情報である。ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報は、サービスシグナリングを送るＲＯＵＴＥセッションと同じＲＯＵＴＥセッションでオーディオ、ビデオ或いはキャプションデータが併せて送られ、サービスシグナリングを送るデータパイプで全てのデータが併せて伝送されるかを識別する情報である。
【１７６４】
同図の（ｂ）を参照すると、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスがリニア（ｌｉｎｅａｒ）サービスである場合、サービスをレンダリングするために受信機に要求される最小性能が、ＨＤ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）処理性能か又はＵＨＤ（Ｕｌｔｒａ  Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）処理性能かなどが、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報によって識別されてもよい。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報が示すサービスのカテゴリーがリニア（ｌｉｎｅａｒ）サービスであり、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の値が「ｘ１」である場合、当該サービスは、少なくともＵＨＤをレンダリングできる装置（ｄｅｖｉｃｅ）だけが、ＦＩＣを用いた放送スキャンを介して、チャネルマップ（Ｃｈａｎｎｅｌ  Ｍａｐ）に当該サービスを追加するようにすることができる。これは、受信機が支援できないサービスを提供する場合、チャネルマップに当該サービスが含まれないようにすることで、ユーザにとって視聴不可能なサービスは選択しないようにし、チャネル選択時に効率性を図ることができる。
【１７６５】
ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスがアプリケーション（Ａｐｐ；Ａｐｐｌｉｃａｔｉｏｎ）サービスである場合、サービスを介してレンダリングするために受信機に要求される最小性能が、ブロードバンドを介してダウンロード可能な性能を備えるべきか、ブロードバンドを介さなくともダウンロード可能な性能を備えるべきが、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報によって識別されてもよい。
【１７６６】
図１５５は、本発明の一実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。
【１７６７】
同図の（ａ）を参照すると、受信機は、放送信号内の特定領域で伝送されるＦＩＣを取得することができる。
【１７６８】
受信機は、ＦＩＣ内のｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報をパーシングし、ｓｅｒｖｉｃｅ＿ｉｄ情報によって識別されるサービスがアプリケーションサービスであるかを識別することができる。
【１７６９】
受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報が有する値のＭＳＢ（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｔｎ  Ｂｉｔ）をチェックする。
【１７７０】
受信機はｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報のＭＳＢが「１」の場合、アプリケーションサービスに含まれるコンポーネントがブロードバンドで伝送されていないことと認識することができる。これは、アプリケーションサービスに含まれるコンポーネントが放送網で伝送されることを示す。したがって、放送網を介してコンポーネントをダウンロードできない受信機は、当該アプリケーションサービスをレンダリングできないということが認識できる。したがって、放送網を介してコンポーネントをダウンロードできる受信機のみが、チャネルマップに当該アプリケーションサービスを含め、放送網を介してコンポーネントをダウンロードできない受信機は、チャネルマップに当該アプリケーションサービスを含めなくてもよい。
【１７７１】
本発明の一実施例は、受信機で、ＦＩＣのｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を取得するだけでも、受信機で支援しないサービスをチャネルマップに登録しないようにすることによって、支援しないサービスに対する誤作動確率を減らすことができる。
【１７７２】
同図の（ｂ）を参照すると、ＵＳＤは、ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントを含むことができる。ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントは、それぞれのサービスをレンダリングするために受信機に要求される性能に関する情報を含むことができる。この例では、ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメント内の情報は、受信機がブロードバンド網を介さず、放送網を介して、特定サービスのコンポーネントを受信可能でなければならないことを示すことができる。
【１７７３】
図１５６は、本発明の他の実施例に係る、ローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【１７７４】
本発明の他の実施例では、各サービスのＭｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに追加して、受信機のサービススキャン（ｓｅｒｖｉｃｅ  ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ  ｒｅｎｄｅｒｉｎｇ）が効率的に行われるようにする方案を提案する。
【１７７５】
同図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７７６】
それぞれの情報又はエレメントに関する説明は、前述した説明に代える。
【１７７７】
本実施例では、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に１０ビットを割り当てることができる。この場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報が、将来追加される性能（ｃａｐａｂｉｌｉｔｙ）関連情報の拡張を支援することができる。
【１７７８】
同図の（ｂ）を参照すると、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の構造が示されている。
【１７７９】
例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスのカテゴリーがリニア（Ｌｉｎｅａｒ）サービスである場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられたビットのうち、４ビットは、ビデオを処理するために要求される性能を識別するビデオ性能プロファイル（Ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅ）と定義し、他の４ビットは、オーディオを処理するために要求される性能を識別するオーディオ性能プロファイルと定義することができる。
【１７８０】
例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスのカテゴリーがアプリケーション（Ａｐｐ；Ａｐｐｌｉｃａｔｉｏｎ）サービスである場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられたビットのうち、２ビットは、アプリケーションサービスをダウンロードするために用いられるプロトコル（Ｄｏｗｎｌｏａｄ  ｐｒｏｔｏｃｏｌ）と関連して受信機に要求される性能プロファイル（Ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅ）を示すものと定義されてもよい。
【１７８１】
図１５７は、本発明の他の実施例に係る、ローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【１７８２】
本発明の他の実施例では、各サービスのＭｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに追加して、受信機のサービススキャン（ｓｅｒｖｉｃｅ  ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ  ｒｅｎｄｅｒｉｎｇ）が効率的に行われるようにする方案を提案する。
【１７８３】
同図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７８４】
それぞれの情報又はエレメントに関する説明は、前述した説明に代える。
【１７８５】
ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣに含まれ得る最小性能情報の個数を示す。ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣで定義される最小性能プロファイル（ｍｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅ）の数を示す。最小性能プロファイルは、最大４個までＦＩＣに含まれてもよい。
【１７８６】
ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報は、ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の値がどのタイプのコンポーネントと関連しているかを示す情報である。
【１７８７】
ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、サービスの表出のために必須の、受信機の最小性能プロファイルを示す。ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、サービスをレンダリングするために受信機に要求される最小限の性能を識別する情報である。
【１７８８】
同図の（ｂ）を参照すると、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値によって、当該情報が示すコンポーネントが開示されている。例えば、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が「００」である場合、最小性能プロファイルの適用されるコンポーネントがビデオコンポーネントであることを示すことができ、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が「０１」の場合、最小性能プロファイルの適用されるコンポーネントがオーディオコンポーネントであることを示すことができ、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が「１０」の場合、最小性能プロファイルの適用されるコンポーネントがアプリケーション（Ａｐｐ，Ａｐｐｌｉｃａｔｉｏｎ）コンポーネントであることを示すことができる。
【１７８９】
図１５８は、本発明の他の実施例に係る、ローレベルシグナリング（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）情報を示す図である。
【１７９０】
本発明の他の実施例では、各サービスのＭｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに追加して、受信機のサービススキャン（ｓｅｒｖｉｃｅ  ｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅ  ｒｅｎｄｅｒｉｎｇ）が効率的に行われるようにする方案を提案する。
【１７９１】
同図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。
【１７９２】
それぞれの情報又はエレメントに関する説明は、前述した説明に代える。
【１７９３】
ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣが定義するチャネル（Ｃｈａｎｎｅｌ）の最小性能プロファイル（ｍｉｎｉｍｕｍ  ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅ）を示す。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報には８ビットを割り当てることができる。８ビットに含まれる各ビットの組合せによって、最小性能プロファイルがいかなるコンポーネントタイプの性能プロファイル（ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅ）に該当するかを定義することができる。
【１７９４】
同図の（ｂ）を参照すると、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられるビットの組合せ及びそれらが示す情報が示されている。
【１７９５】
８ビットの中、ＭＳＢの２ビットは、性能プロファイル（ｃａｐａｂｉｌｉｔｙ  ｐｒｏｆｉｌｅ）が適用されるコンポーネントのタイプを示す。例えば、２ビットの値が「００」の場合、最小性能プロファイルの適用されるコンポーネントがビデオコンポーネントであることを示すことができ、２ビットの値が「０１」の場合、最小性能プロファイルの適用されるコンポーネントがオーディオコンポーネントであることを示すことができ、２ビットの値が「１０」の場合、最小性能プロファイルの適用されるコンポーネントがアプリケーション（Ａｐｐ，Ａｐｐｌｉｃａｔｉｏｎ）コンポーネントであることを示すことができる。
【１７９６】
８ビットのうち、２ビットを割り当てて、ビデオコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が「００」の場合、ＨＤビデオチャネルが提供され、受信機はＨＤビデオを処理し得る能力が要求されることを示し、２ビットの値が「０１」の場合、ＵＨＤビデオチャネルが提供され、受信機はＵＨＤビデオを処理し得る能力が要求されることを示す。
【１７９７】
８ビットのうち、２ビットを割り当てて、オーディオコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が「００」の場合、既存放送システム（例えば、ＡＴＳＣ １．０放送システム）で適用される形態のオーディオコンポーネントが提供され、受信機は既存放送システムで提供される形態のオーディオコンポーネントを処理し得る能力が要求されることを示し、２ビットの値が「０１」の場合、次世代放送システム（例えば、ＡＴＳＣ ３．０放送システム）で適用される形態のオーディオコンポーネントが提供され、受信機は次世代放送システムで提供される形態のオーディオコンポーネントを処理し得る能力が要求されることを示す。
【１７９８】
８ビットのうち、２ビットを割り当てて、アプリケーションのコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が「００」の場合、アプリケーションのコンポーネントがブロードバンドで提供され、受信機は、当該コンポーネントを受信処理するために、ブロードバンドを介したダウンロードを処理し得る能力が要求されることを示し、２ビットの値が「０１」の場合、アプリケーションのコンポーネントがブロードバンドで提供されず、受信機は、当該コンポーネントを受信処理するために、ブロードバンド以外のネットワーク（例えば、放送網）を介したダウンロードを処理し得る能力が要求されることを示す。
【１７９９】
図１５９は、本発明の他の実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。
【１８００】
同図の（ａ）を参照すると、受信機は、放送信号内の特定領域で伝送されるＦＩＣを取得することができる。
【１８０１】
受信機は、ＦＩＣ内のｃｈａｎｎｅｌ＿ｃａｐａｃｉｔｙ＿ｐｒｏｆｉｌｅ情報（ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、及び／又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を含み得る。）を取得する。
【１８０２】
受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の一部ビット又はｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報を用いて、性能プロファイルが適用されるコンポーネントのタイプを識別することができる。
【１８０３】
受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の一部ビット又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を用いて、それぞれのコンポーネントタイプに適用される最小性能プロファイルを識別することができる。
【１８０４】
本発明によれば、受信機は、ＦＩＣレベルの情報を用いて、各チャネルを表出するために受信機に要求される性能がわかる。ＦＩＣに記述されるチャネルレベル（Ｃｈａｎｎｅｌ  Ｌｅｖｅｌ）の性能（ｃａｐａｂｉｌｉｔｙ）は、全チャネルに共通適用され得る、よく変わらない性能（ｃａｐａｂｉｌｉｔｙ）と記述されてもよい。
【１８０５】
同図の（ｂ）を参照すると、ＵＳＤに含まれ得るＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントが開示されている。ＵＳＤに含まれるＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントは、サービスレベルにおける性能と関連した情報（Ｓｅｒｖｉｃｅ  ｌｅｖｅｌ  ｃａｐａｂｉｌｉｔｙ）を含むことができる。受信機がサービスを取得する過程で、プログラム（又は、イベント）別性能（ｃａｐａｂｉｌｉｔｙ）は、サービスレベルシグナリングで記述されてもよく、このようなサービスレベル（Ｓｅｒｖｉｃｅ  ｌｅｖｅｌ）における性能（ｃａｐａｂｉｌｉｔｙ）と関連した情報は、ＦＩＣで記述される性能と関連した情報よりも優先順位を有することができる。ここで、性能と関連した情報は、前述したｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、及び／又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を含むことができる。
【１８０６】
図１６０は、本発明の一実施例に係る、放送信号を生成処理する方法を示すフローチャートである。
【１８０７】
送信機は、一つ以上の放送サービスのための放送データをエンコーディングする（ＪＳ１６００１０）。
【１８０８】
送信機は、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコーディングする（ＪＳ１６００２０）。
【１８０９】
送信機は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコーディングする（ＪＳ１６００３０）。
【１８１０】
送信機は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する（ＪＳ１６００４０）。
【１８１１】
本発明の一実施例によれば、第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングする上で要求される性能を識別する第１性能情報を含むことができる。
【１８１２】
図１６１は、本発明の一実施例に係る放送システムを示す図である。
【１８１３】
本発明の一実施例に係る放送システムは、放送送信機Ｊ１６１１００及び／又は放送受信機Ｊ１６１２００を含むことができる。
【１８１４】
放送送信機Ｊ１６１１００は、放送データエンコーダＪ１６１１１０、シグナリングエンコーダＪ１６１１２０、及び／又は放送信号生成器Ｊ１６１１３０を含むことができる。
【１８１５】
放送受信機Ｊ１６１２００は、放送信号受信部Ｊ１６１２１０、プロセッサＪ１６１２２０、及び／又はディスプレイ部Ｊ１６１２３０を含むことができる。
【１８１６】
放送データエンコーダＪ１６１１１０は、一つ以上の放送サービスのための放送データをエンコーディングする。
【１８１７】
シグナリングエンコーダＪ１６１１２０は、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び／又は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコーディングする。
【１８１８】
放送信号生成器Ｊ１６１１３０は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する。
【１８１９】
本発明の一実施例によれば、第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含むことができる。
【１８２０】
放送信号受信部Ｊ１６１２１０は、一つ以上の放送サービスのための放送データ、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報と一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報とを含む放送信号を受信する。第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含むことができる。
【１８２１】
プロセッサＪ１６１２２０は、第２レベルシグナリング情報及び第１レベルシグナリング情報を用いて、放送サービスを取得し、放送サービスを表出するように制御する。
【１８２２】
ディスプレイ部Ｊ１６１２３０は、放送サービス／コンテンツをディスプレイする。
【１８２３】
モジュール又はユニットは、メモリ（又は、記憶ユニット）に記憶された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサによって実行することができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実現されてもよい。このコードは、プロセッサが読み出し可能な記憶媒体に書き込まれ、よって、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサによって読み出されてもよい。
【１８２４】
説明の便宜のため、各図を区別して説明したが、各図に開示した実施例を組み合わせて新しい実施例として具現するように設計することも可能である。そして、通常の技術者の必要に応じて、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み出し可能な記録媒体を設計することも、本発明の権利範囲に属する。
【１８２５】
本発明に係る装置及び方法は、上述した実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。
【１８２６】
一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサが読み出し可能な記録媒体に、プロセッサが読み出し可能なコードとして具現することができる。プロセッサが読み出し可能な記録媒体は、プロセッサによって読み出されるデータが記憶されるいかなる種類の記録装置をも含む。プロセッサが読み出し可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み出し可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み出し可能なコードが記憶され、実行されてもよい。
【１８２７】
また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者にとって様々な変形実施が可能であることはもちろんであり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。
【１８２８】
そして、当該明細書では、物の発明及び方法の発明の両方が説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。
【１８２９】
本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。
【１８３０】
本明細書において、装置の発明も方法の発明も言及されており、装置及び方法の発明に関する説明は互いに補完して適用されてもよい。
【１８３１】
様々な実施例が、本発明を実施するための形態において説明されている。
【産業上の利用可能性】
【１８３２】
本発明は、一連の放送信号提供分野で利用される。
【１８３３】
本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。
【図１】
0006309622.tif 000044
【図２】
0006309622.tif 000045
【図３】
0006309622.tif 000046
【図４】
0006309622.tif 000047
【図５】
0006309622.tif 000048
【図６】
0006309622.tif 000049
【図７】
0006309622.tif 000050
【図８】
0006309622.tif 000051
【図９】
0006309622.tif 000052
【図１０】
0006309622.tif 000053
【図１１】
0006309622.tif 000054
【図１２】
0006309622.tif 000055
【図１３】
0006309622.tif 000056
【図１４】
0006309622.tif 000057
【図１５】
0006309622.tif 000058
【図１６】
0006309622.tif 000059
【図１７】
0006309622.tif 000060
【図１８】
0006309622.tif 000061
【図１９】
0006309622.tif 000062
【図２０】
0006309622.tif 000063
【図２１】
0006309622.tif 000064
【図２２】
0006309622.tif 000065
【図２３】
0006309622.tif 000066
【図２４】
0006309622.tif 000067
【図２５】
0006309622.tif 000068
【図２６】
0006309622.tif 000069
【図２７】
0006309622.tif 000070
【図２８】
0006309622.tif 000071
【図２９】
0006309622.tif 000072
【図３０】
0006309622.tif 000073
【図３１】
0006309622.tif 000074
【図３２（ａ）】
0006309622.tif 000075
【図３２（ｂ）】
0006309622.tif 000076
【図３２（ｃ）】
0006309622.tif 000077
【図３３】
0006309622.tif 000078
【図３４】
0006309622.tif 000079
【図３５】
0006309622.tif 000080
【図３６】
0006309622.tif 000081
【図３７】
0006309622.tif 000082
【図３８】
0006309622.tif 000083
【図３９】
0006309622.tif 000084
【図４０】
0006309622.tif 000085
【図４１】
0006309622.tif 000086
【図４２】
0006309622.tif 000087
【図４３】
0006309622.tif 000088
【図４４】
0006309622.tif 000089
【図４５】
0006309622.tif 000090
【図４６】
0006309622.tif 000091
【図４７】
0006309622.tif 000092
【図４８】
0006309622.tif 000093
【図４９】
0006309622.tif 000094
【図５０】
0006309622.tif 000095
【図５１】
0006309622.tif 000096
【図５２】
0006309622.tif 000097
【図５３】
0006309622.tif 000098
【図５４】
0006309622.tif 000099
【図５５】
0006309622.tif 000100
【図５６】
0006309622.tif 000101
【図５７】
0006309622.tif 000102
【図５８】
0006309622.tif 000103
【図５９】
0006309622.tif 000104
【図６０】
0006309622.tif 000105
【図６１】
0006309622.tif 000106
【図６２】
0006309622.tif 000107
【図６３】
0006309622.tif 000108
【図６４】
0006309622.tif 000109
【図６５】
0006309622.tif 000110
【図６６】
0006309622.tif 000111
【図６７】
0006309622.tif 000112
【図６８】
0006309622.tif 000113
【図６９】
0006309622.tif 000114
【図７０】
0006309622.tif 000115
【図７１】
0006309622.tif 000116
【図７２】
0006309622.tif 000117
【図７３】
0006309622.tif 000118
【図７４】
0006309622.tif 000119
【図７５】
0006309622.tif 000120
【図７６】
0006309622.tif 000121
【図７７】
0006309622.tif 000122
【図７８】
0006309622.tif 000123
【図７９】
0006309622.tif 000124
【図８０】
0006309622.tif 000125
【図８１】
0006309622.tif 000126
【図８２】
0006309622.tif 000127
【図８３】
0006309622.tif 000128
【図８４】
0006309622.tif 000129
【図８５】
0006309622.tif 000130
【図８６】
0006309622.tif 000131
【図８７】
0006309622.tif 000132
【図８８】
0006309622.tif 000133
【図８９】
0006309622.tif 000134
【図９０】
0006309622.tif 000135
【図９１】
0006309622.tif 000136
【図９２】
0006309622.tif 000137
【図９３】
0006309622.tif 000138
【図９４】
0006309622.tif 000139
【図９５】
0006309622.tif 000140
【図９６】
0006309622.tif 000141
【図９７】
0006309622.tif 000142
【図９８】
0006309622.tif 000143
【図９９】
0006309622.tif 000144
【図１００】
0006309622.tif 000145
【図１０１】
0006309622.tif 000146
【図１０２】
0006309622.tif 000147
【図１０３】
0006309622.tif 000148
【図１０４】
0006309622.tif 000149
【図１０５】
0006309622.tif 000150
【図１０６】
0006309622.tif 000151
【図１０７】
0006309622.tif 000152
【図１０８】
0006309622.tif 000153
【図１０９】
0006309622.tif 000154
【図１１０】
0006309622.tif 000155
【図１１１】
0006309622.tif 000156
【図１１２】
0006309622.tif 000157
【図１１３】
0006309622.tif 000158
【図１１４】
0006309622.tif 000159
【図１１５】
0006309622.tif 000160
【図１１６】
0006309622.tif 000161
【図１１７】
0006309622.tif 000162
【図１１８】
0006309622.tif 000163
【図１１９】
0006309622.tif 000164
【図１２０】
0006309622.tif 000165
【図１２１】
0006309622.tif 000166
【図１２２】
0006309622.tif 000167
【図１２３】
0006309622.tif 000168
【図１２４】
0006309622.tif 000169
【図１２５】
0006309622.tif 000170
【図１２６】
0006309622.tif 000171
【図１２７】
0006309622.tif 000172
【図１２８】
0006309622.tif 000173
【図１２９】
0006309622.tif 000174
【図１３０】
0006309622.tif 000175
【図１３１】
0006309622.tif 000176
【図１３２】
0006309622.tif 000177
【図１３３】
0006309622.tif 000178
【図１３４】
0006309622.tif 000179
【図１３５】
0006309622.tif 000180
【図１３６】
0006309622.tif 000181
【図１３７】
0006309622.tif 000182
【図１３８】
0006309622.tif 000183
【図１３９】
0006309622.tif 000184
【図１４０】
0006309622.tif 000185
【図１４１】
0006309622.tif 000186
【図１４２】
0006309622.tif 000187
【図１４３】
0006309622.tif 000188
【図１４４】
0006309622.tif 000189
【図１４５】
0006309622.tif 000190
【図１４６】
0006309622.tif 000191
【図１４７（ａ）】
0006309622.tif 000192
【図１４７（ｂ）】
0006309622.tif 000193
【図１４８】
0006309622.tif 000194
【図１４９】
0006309622.tif 000195
【図１５０】
0006309622.tif 000196
【図１５１】
0006309622.tif 000197
【図１５２】
0006309622.tif 000198
【図１５３】
0006309622.tif 000199
【図１５４（ａ）】
0006309622.tif 000200
【図１５４（ｂ）】
0006309622.tif 000201
【図１５５（ａ）】
0006309622.tif 000202
【図１５５（ｂ）】
0006309622.tif 000203
【図１５６（ａ）】
0006309622.tif 000204
【図１５６（ｂ）】
0006309622.tif 000205
【図１５７（ａ）】
0006309622.tif 000206
【図１５７（ｂ）】
0006309622.tif 000207
【図１５８（ａ）】
0006309622.tif 000208
【図１５８（ｂ）】
0006309622.tif 000209
【図１５９（ａ）】
0006309622.tif 000210
【図１５９（ｂ）】
0006309622.tif 000211
【図１６０】
0006309622.tif 000212
【図１６１】
0006309622.tif 000213