JP6309622B2

JP6309622B2 - 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Info

Publication number: JP6309622B2
Application number: JP2016525530A
Authority: JP
Inventors: ミンソンカク; キョンソムン; チャンウォンリ; ウソクコ; ソンリョンホン
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2014-11-20
Filing date: 2015-11-20
Publication date: 2018-04-11
Anticipated expiration: 2035-11-20
Also published as: CA3126649A1; CN105830459B; US20200235850A1; CA3074965C; US10205556B2; JP2017510091A; EP3223519A4; US20210143938A1; US20190097755A1; EP3223519B1; CA3074965A1; EP3223519A1; CA3126649C; US20170180077A1; CN105830459A; US10938511B2; US10659191B2; KR20160073371A; KR101814401B1; WO2016080803A1

Description

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

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

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

前述した技術的課題を解決するための本発明の一実施例に係る放送信号生成処理方法は、一つ以上の放送サービスのための放送データをエンコーディングするステップと、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコーディングするステップと、前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコーディングするステップと、前記放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成するステップとを有し、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含む。

好適には、前記一つ以上の放送コンテンツのそれぞれは、一つ以上のコンポーネントを含み、前記第１性能情報は、前記性能情報が適用される、コンポーネントのタイプをさらに識別することを特徴とする。

好適には、前記一つ以上の放送サービスは、アプリケーションサービスを含み、前記第１性能情報は、前記アプリケーションサービスに含まれるコンポーネントをダウンロードするために用いられるダウンロードプロトコルをさらに識別することを特徴とする。

好適には、前記第１シグナリング情報は、放送サービスに対するサービス層属性を記述するＵＳＤ（ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ）情報を含み、前記ＵＳＤ情報は、前記放送サービスの放送コンテンツを表出するために要求される性能を識別する第２性能情報を含むことを特徴とする。

好適には、前記第１性能情報が示す情報と前記第２性能情報が示す情報とが異なる場合、前記第２性能情報に優先順位を与えることを特徴とする。

好適には、前記第２レベルシグナリング情報は、前記第１レベルシグナリング情報を伝送するＰＬＰ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ）を識別するＰＬＰ識別情報をさらに含むことを特徴とする。

好適には、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスが、リニア（ｌｉｎｅａｒ）サービス、アプリケーションサービス又はＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）サービスに該当するかを識別するサービスカテゴリー情報をさらに含むことを特徴とする。

前述した技術的課題を解決するための本発明の一実施例に係る、放送受信機は、一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報を含む放送信号を受信する放送信号受信部であって、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含む、放送信号受信部と、前記第２レベルシグナリング情報及び前記第１レベルシグナリング情報を用いて、前記放送サービスを取得し、前記放送サービスを表出するように制御するプロセッサとを備える。

好適には、前記第２レベルシグナリング情報は、前記一つ以上の放送サービスが、リニア（ｌｉｎｅａｒ）サービス、アプリケーションサービス、又はＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）サービスに該当するかを識別するサービスカテゴリー情報をさらに含むことを特徴とする。

好適には、前記プロセッサは、前記第１性能情報が示す受信機に要求される性能が、前記放送信号受信機によって支援される性能である場合にのみ、前記第１性能情報と関連した放送サービスをチャネルマップに含ませて、前記チャネルマップを生成することを特徴とする。

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

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

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

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

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

本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒｐｒｏｔｏｃｏｌｓｔａｃｋ）を示した図である。本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅｌａｙｅｒｓｉｇｎａｌｉｎｇ）の関係を示した図である。本発明の一実施例に係るＳＬＴを示した図である。本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリー過程を示した図である。本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。本発明の一実施例に係るリンクレイヤプロトコルアーキテクチャーを示した図である。本発明の一実施例に係るリンクレイヤパケットのベースヘッダーの構造を示した図である。本発明の一実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。本発明の他の実施例に係るリンクレイヤパケットの追加ヘッダーの構造を示した図である。本発明の一実施例に係る、ＭＰＥＧ−２ＴＳパケットのためのリンクレイヤパケットのヘッダー構造、及びそのエンカプセレーション過程を示した図である。本発明の一実施例に係るＩＰヘッダー圧縮において、アダプテーションモードの実施例を示した図である（送信側）。本発明の一実施例に係るＬＭＴ（ＬｉｎｋＭａｐｐｉｎｇＴａｂｌｅ）及びＲＯＨＣ−Ｕディスクリプションテーブルを示した図である。本発明の一実施例に係る送信機側のリンクレイヤの構造を示した図である。本発明の一実施例に係る受信機側のリンクレイヤの構造を示した図である。本発明の一実施例に係る、リンクレイヤを介したシグナリング伝送構造を示した図である（送／受信側）。本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置の構造を示す図である。本発明の一実施例に係るＢＩＣＭ（ｂｉｔｉｎｔｅｒｌｅａｖｅｄｃｏｄｉｎｇ＆ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。本発明の他の実施例に係るＢＩＣＭブロックを示す図である。本発明の一実施例に係るＰＬＳのビットインターリービング過程を示す図である。本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す図である。本発明の一実施例に係るフレームのシグナリング階層構造を示す図である。本発明の一実施例に係るＰＬＳ１データを示す図である。本発明の一実施例に係るＰＬＳ２データを示す図である。本発明の他の実施例に係るＰＬＳ２データを示す図である。本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ、論理）構造を示す図である。本発明の一実施例に係るＰＬＳ（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｌｉｎｇ）マッピングを示す図である。本発明の一実施例に係るタイムインターリービングを示す図である。本発明の一実施例に係る、ツイストされた行−列ブロックインターリーバの基本動作を示す図である。本発明の他の実施例に係る、ツイストされた行−列ブロックインターリーバの動作を示す図である。本発明の一実施例に係る、各ＦＦＴモードによるメイン−ＰＲＢＳジェネレーターとサブ−ＰＲＢＳジェネレーターで構成されたインターリービングアドレスジェネレーターのブロックダイアグラムを示す図である。本発明の一実施例に係る、全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。本発明の一実施例に係る、フリケンシーインターリービングのためのインターリービングアドレス及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。本発明の一実施例に係る、タイムインターリーバの書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す図である。ＰＬＰ個数によって適用するインターリービングタイプを表で示す図である。上述したハイブリッドタイムインターリーバ構造の第１実施例を含むブロック図である。上述したハイブリッドタイムインターリーバ構造の第２実施例を含むブロック図である。ハイブリッドタイムデインターリーバの構造の第１実施例を含むブロック図である。ハイブリッドタイムデインターリーバの構造の第２実施例を含むブロック図である。本発明の一実施例に係るハイブリッド放送受信装置を示す図である。本発明の一実施例に係るハイブリッド放送受信機を示すブロック図である。本発明の一実施例に係る次世代ハイブリッド放送システムのプロトコルスタックを示す図である。本発明の一実施例に係る次世代放送伝送システムのフィジカルレイヤに伝達される伝送フレームの構造を示す図である。本発明の一実施例に係る、アプリケーション層伝送プロトコルの伝送パケットを示す図である。本発明の一実施例に係る、次世代放送システムがシグナリングデータを伝送する方法を示す図である。本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。本発明の一実施例に係る、ＦＩＣベースシグナリングを伝送する方法を示す図である。本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。本発明の他の実施例に係る、ＦＩＣベースシグナリングを伝送する方法を示す図である。本発明の一実施例に係る次世代放送システムのサービスシグナリングメッセージフォーマットを示す図である。本発明の一実施例に係る、次世代放送システムで用いるサービスシグナリングテーブルを示す図である。本発明の一実施例に係る、次世代放送システムで用いられるサービスマッピングテーブルを示す図である。本発明の一実施例に係る、次世代放送システムのサービスシグナリングテーブルを示す図である。本発明の一実施例に係る、次世代放送システムで用いられるコンポーネントマッピングテーブルを示す図である。本発明の一実施例に係る、コンポーネントマッピングテーブルディスクリプションを示す図である。本発明の一実施例に係る、次世代放送システムのコンポーネントマッピングテーブルのシンタックスを示す図である。本発明の一実施例に係る、次世代放送システムにおいて各サービスと関連したシグナリングをブロードバンド網を介して伝達する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてＭＰＤをシグナリングする方案を示す図である。本発明の一実施例に係る、次世代放送システムのＭＰＤデリバリーテーブルのシンタックスを示す図である。本発明の一実施例に係る、次世代放送システムの伝送セッションインスタンスディスクリプションを示す図である。本発明の一実施例に係る次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す図である。本発明の一実施例に係る次世代放送システムのＥＦＤＴを示す図である。本発明の一実施例に係る、次世代放送システムが用いるＩＳＤＴを伝送する方法を示す図である。本発明の一実施例に係る、次世代放送システムのシグナリングメッセージのデリバリー構造を示す図である。本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す図である。本発明の一実施例に係るＭＰＤの共通属性及びエレメントを示す図である。本発明の一実施例に係る伝送セッションインスタンスディスクリプションを示す図である。本発明の一実施例に係る次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す図である。本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。本発明の一実施例に係る、次世代放送システムのサービスレイヤシグナリングを伝送する方法を示す図である。本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。本発明の他の実施例に係る、シグナリングメッセージ（ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ）のヘッダー（ｈｅａｄｅｒ）のシンタックス（ｓｙｎｔａｘ）を示す図である。本発明の一実施例に係る、ＤＡＳＨ初期化セグメント（ＤＡＳＨＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）を処理するプロトコルスタック（ＰｒｏｔｏｃｏｌＳｔａｃｋ）を示す図である。本発明の一実施例に係る、ＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）セッションインスタンスディスクリプタ（ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ；ＬＳＩＤ）の一部を示す図である。本発明の一実施例に係る、サービスシグナリングメッセージをフィルタリング（ｆｉｌｔｅｒｉｎｇ）するための情報を提供するシグナリングオブジェクトディスクリプション（ＳｉｇｎａｌｉｎｇＯｂｊｅｃｔＤｅｓｃｒｉｐｔｉｏｎ；ＳＯＤ）を示す図である。本発明の一実施例に係る、シグナリングメッセージを含むオブジェクトを示す図である。本発明の一実施例に係る、ＴＯＩ構成ディスクリプション（ＴＯＩＣｏｎｆｉｇｕｒａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ；ＴＣＤ）を示す図である。本発明の一実施例に係る、伝送パケットのペイロード（Ｐａｙｌｏａｄ）フォーマット（Ｆｏｒｍａｔ）エレメントを示す図である。本発明の一実施例に係る、ＴＯＩ構成インスタンスディスクリプション（ＴＯＩＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ；ＴＣＩＤ）を示す図である。本発明の一実施例に係る、ＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）のペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。本発明の他の実施例に係る、ＦＩＣのペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。本発明の他の実施例に係る、サービスレベルシグナリングのシンタックス（ｓｙｎｔａｘ）を示す図である。本発明の他の実施例に係る、コンポーネントマッピングディスクリプション（ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ）を示す図である。本発明の他の実施例に係る、ＵＲＬシグナリングディスクリプション（ＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎ）のシンタックス（ｓｙｎｔａｘ）を示す図である。本発明の他の実施例に係る、ＳｏｕｒｃｅＦｌｏｗエレメントを示す図である。本発明の他の実施例に係る、シグナリング情報を放送網を介して取得する過程を示す図である。本発明の他の実施例に係る、シグナリング情報を放送網及びブロードバンド網を介して取得する過程を示す図である。本発明の他の実施例に係る、シグナリング情報をブロードバンド網を介して取得する過程を示す図である。本発明の他の実施例に係る、ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）を放送網を介して取得する過程を示す図である。本発明の他の実施例に係る、放送サービスのビデオセグメント及びオーディオセグメントを放送網を介して取得する過程を示す図である。本発明の他の実施例に係る、放送サービスのビデオセグメントは放送網を介して取得し、放送サービスのオーディオセグメントはブロードバンド網を介して取得する過程を示す図である。本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。本発明の一実施例に係るＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）の構成を示す図である。本発明の他の実施例に係るＦＩＣの構成を示す図である。本発明の一実施例に係るＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎの構成を示す図である。本発明の一実施例に係るＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎの構成を示す図である。本発明の一実施例に係る放送信号送信方法を示す図である。本発明の一実施例に係る放送信号受信方法を示す図である。本発明の一実施例に係る放送信号送信装置の構成を示す図である。本発明の一実施例に係る放送信号受信装置の構成を示す図である。本発明の一実施例に係る、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝達される場合において、そのサービスディスクリプション情報を示す図である。本発明の一実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。本発明の一実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。本発明の他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。本発明の更に他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。本発明の一実施例に係る、初期化情報伝達のために拡張されたシグナリングメッセージを示す図である。本発明の一実施例に係る、初期化情報伝達のためのメッセージフォーマットを示す図である。本発明の他の実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。本発明の一実施例に係る、サービスデータを処理する方法を示す図である。本発明の一実施例に係る、サービスデータを処理する装置を示す図である。本発明の一実施例に係るＥＳＧブートストラップ情報を示す図である。本発明の一実施例に係る、ＥＳＧブートストラップ情報が伝送されるタイプを示す図である。本発明の第１実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。本発明の第２実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。本発明の第３実施例に係るＥＳＧブートストラッピングディスクリプションのシグナリングを示す図である。本発明の第４実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。本発明の第５実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。本発明の第５実施例に係るＧＡＴを示す図である。本発明の第１実施例乃至第５実施例の効果を示す図である。本発明の一実施例に係る放送受信装置の流れを示す図である。本発明の一実施例に係るチャネルマップ構成方法を示す図である。本発明の一実施例に係るチャネルマップ構成方法を示す図である。本発明の一実施例に係るＦＩＣを示す図である。本発明の一実施例に係るＦＩＣを示す図である。本発明の一実施例に係るＦＩＣを示す図である。本発明の一実施例に係るＦＩＣを示す図である。本発明の一実施例に係るＦＩＣを示す図である。本発明の一実施例に係るＦＩＣを示す図である。本発明の一実施例に係るＳＳＣを示す図である。本発明の一実施例に係る放送伝送方法の流れを示す図である。本発明の一実施例に係る放送受信方法の流れを示す図である。本発明の一実施例に係る、受信機移動時における他の周波数へのハンドオーバー（ｈａｎｄｏｖｅｒ）状況を示す図である。本発明の一実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。本発明の他の実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。本発明の一実施例に係る、シームレスハンドオーバーのための情報を示す図である。本発明の一実施例に係るローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。本発明の一実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。本発明の他の実施例に係る、ローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。本発明の他の実施例に係る、ローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。本発明の他の実施例に係る、ローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。本発明の他の実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。本発明の一実施例に係る、放送信号を生成処理する方法を示すフローチャートである。本発明の一実施例に係る放送システムを示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔは、サービスのディスクリプションを示す属性である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下、アダプテーション（Ａｄａｐｔａｔｉｏｎ）について説明する。

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

アダプテーション機能は、コンフィギュレーションパラメータ及びコンテキスト情報の帯域外伝送を提供する。帯域外伝送は、リンクレイヤシグナリングを通じて行うことができる。したがって、アダプテーション機能は、コンテキスト情報の損失によるデコンプレッションエラー及びチャンネル変更遅延を減少させるために用いられる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ｄｓｔ_ＩＰ_ａｄｄは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのデスティネーションＩＰアドレスを含む３２ビットの符号なし整数フィールドであり得る。

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

ｄｓｔ_ＵＤＰ_ｐｏｒｔは、ＰＬＰ_ＩＤフィールドによって識別されるＰＬＰに伝達される上位レイヤセッションのデスティネーションＵＤＰポートナンバーを示す１６ビットの符号なし整数フィールドであり得る。

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

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

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

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

本発明に係るＲＯＨＣ−Ｕディスクリプションテーブルの一実施例（ｔｓｉｂ１４０２０）が図示された。前述したように、ＲＯＨＣ−Ｕアダプテーションモジュールは、ヘッダーコンプレッションに関連する情報を生成することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エンカプセレーション部分は、パケットをフィジカルレイヤに伝達するのに適した形態でエンキャプシュレートする動作を行うことができる。エンカプセレーション部分は、ＩＰストリームの数だけ構成することができる。

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

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

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

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

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

ヘッダーアタッチメントブロック（ｔｓｉｂ１５２２０）は、セグメンテーション及び／又はコンカチネーションされたリンクレイヤパケットのペイロードにヘッダーを追加することができる。トランスミッションバッファー（ｔｓｉｂ１５２３０）は、リンクレイヤパケットをフィジカルレイヤのＤＰ（ｔｓｉｂ１５２４０）に伝達するためのバッファーの役割を果たすことができる。

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

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

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

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

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

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

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

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

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

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

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

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

リンクレイヤヘッダーパーサ（ｔｓｉｂ１６１４０）は、伝達されたリンクレイヤパケットのヘッダーを確認することができる。ヘッダーを確認することによって、リンクレイヤパケットのペイロードに含まれているＩＰパケットの構成を確認することができる。例えば、ＩＰパケットは、セグメンテーションされているか、またはコンカチネーションされていてもよい。

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

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

オーバーヘッドプロセシング部分は、送信機で行われたオーバーヘッドリダクションの逆過程として、オーバーヘッドリダクションされたパケットを元のパケットに戻す動作を行うことができる。この動作をオーバーヘッドプロセシングと呼ぶことができる。オーバーヘッドプロセシング部分は、フィジカルレイヤで同時にデコーディングできるＤＰの数だけ構成することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フレームレペティションユニット（ｆｒａｍｅｒｅｐｅｔｉｔｉｏｎｕｎｉｔ、フレーム反復単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む、同一の又は異なるフィジカルプロファイルに属するフレームの集合

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図３０（ａ）は、タイムインターリーバにおける書き込み動作を示し、図３０（ｂ）は、タイムインターリーバにおける読み出し動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫは、タイムインターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作がつながる。そして、インターリービングアレイで、セルが対角線方向に読み出される。（ｂ）に示すように、一番目の行から（最も左側列から始まって行に沿って右に）最後の行まで対角線方向読み出しが進行される間に、Ｎ_r個のセルが読み出される。

結果的に、読み出されるセル位置は、座標

によって算出される。

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

より具体的に、図３１は、

のとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリでインターリービングアレイを示す。

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

につながる。

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

したがって、本発明の一実施例に係るフリケンシーインターリーバは、シンボルペアに対応するデータに適用するためのインターリービングアドレスを生成するためのインターリービングアドレスジェネレーターを含むことができる。

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

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

ＯＦＤＭシンボルペアに対するインターリービング過程は、一つのインターリービングシーケンスを利用し、次のように説明される。

このとき、ｘ_m,l,pは、ｍ番目のフレームでｌ番目のＯＦＤＭシンボルのｐ番目のセルであり、Ｎ_dataは、データセルの個数である：フレームシグナリングシンボルに対してＮ_data＝Ｃ_FSSであり、ノーマルデータに対してＮ_data＝Ｃ_dataであり、フレームエッジシンボルに対してＮ_data＝Ｃ_FESである。

このとき、Ｈ_l（ｐ）は、ＰＲＢＳジェネレーターによって生成されたインターリービングアドレスである。

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

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

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

（ａ）は、サブ−ＰＲＢＳジェネレーターを示し、（ｂ）は、フリケンシーインターリービングのためのインターリービングアドレスを示す。本発明の一実施例に係るサイクリックシフト値は、シンボルオフセットと呼ぶことができる。

図３５は、本発明の一実施例に係るタイムインターリーバの書き込み（ｗｒｉｔｉｎｇ）オペレーションを示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４１は、本発明の一実施例に係るハイブリッド放送受信装置を示す図である。ハイブリッド放送システムは、地上波放送網及びインターネット網を連動して放送信号を送信することができる。ハイブリッド放送受信装置は、地上波放送網（ブロードキャスト）及びインターネット網（ブロードバンド）を介して放送信号を受信することができる。ハイブリッド放送受信装置は、フィジカルレイヤモジュール、フィジカルレイヤＩ／Ｆモジュール、サービス／コンテンツ取得コントローラ、インターネットアクセス制御モジュール、シグナリングデコーダ、サービスシグナリングマネジャー、サービスガイドマネジャー、アプリケーションシグナリングマネジャー、警報信号マネジャー、警報信号パーサー、ターゲッティング信号パーサー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネントシンクロナイザー、ターゲッティングプロセッサ、アプリケーションプロセッサ、Ａ／Ｖプロセッサ、デバイスマネジャー、データシェアリング及びコミュニケーションユニット、再分配モジュール、コンパニオンデバイス及び／又は外部モジュールを含むことができる。

フィジカルレイヤモジュール（ＰｈｙｓｉｃａｌＬａｙｅｒＭｏｄｕｌｅ（ｓ））は、地上波放送チャネルを介して放送関連信号を受信及び処理し、それを適切な形態に変換してフィジカルレイヤＩ／Ｆモジュールに伝達することができる。

フィジカルレイヤＩ／Ｆモジュール（ＰｈｙｓｉｃａｌＬａｙｅｒＩ／ＦＭｏｄｕｌｅ（ｓ））は、フィジカルレイヤモジュールから取得した情報からＩＰデータグラムを取得することができる。また、フィジカルレイヤＩ／Ｆモジュールは、取得されたＩＰデータグラムなどを特定フレーム（例えば、ＲＳＦｒａｍｅ、ＧＳＥなど）に変換することができる。

サービス／コンテンツ取得コントローラ（Ｓｅｒｖｉｃｅ／ＣｏｎｔｅｎｔＡｃｑｕｉｓｉｔｉｏｎＣｏｎｔｒｏｌｌｅｒ）は、ｂｒｏａｄｃａｓｔ及び／又はｂｒｏａｄｂａｎｄチャネルを介したサービス、コンテンツ及びこれと関連したシグナリングデータ取得のための制御動作を行うことができる。

インターネットアクセス制御モジュール（ＩｎｔｅｒｎｅｔＡｃｃｅｓｓＣｏｎｔｒｏｌＭｏｄｕｌｅ（ｓ））は、Ｂｒｏａｄｂａｎｄチャネルを介してサービス、コンテンツなどを取得するための受信機動作を制御することができる。

シグナリングデコーダ（ＳｉｇｎａｌｉｎｇＤｅｃｏｄｅｒ）は、ｂｒｏａｄｃａｓｔチャネルなどを介して取得したシグナリング情報をデコーティングすることができる。

サービスシグナリングマネジャー（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＭａｎａｇｅｒ）は、ＩＰデータグラムなどからサービススキャン及びサービス／コンテンツなどと関連したシグナリング情報を抽出、パーシング及び管理することができる。

サービスガイドマネジャー（ＳｅｒｖｉｃｅＧｕｉｄｅＭａｎａｇｅｒ）は、ＩＰデータグラムなどからａｎｎｏｕｎｃｅｍｅｎｔ情報を抽出し、ＳＧ（ＳｅｒｖｉｃｅＧｕｉｄｅ）ｄａｔａｂａｓｅ管理し、ｓｅｒｖｉｃｅｇｕｉｄｅを提供することができる。

アプリケーションシグナリングマネジャー（ＡｐｐＳｉｇｎａｌｉｎｇＭａｎａｇｅｒ）は、ＩＰデータグラムなどからアプリケーション取得などと関連したシグナリング情報を抽出、パーシング及び管理することができる。

警報信号パーサー（ＡｌｅｒｔＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）は、ＩＰデータグラムなどからａｌｅｒｔｉｎｇと関連したシグナリング情報を抽出、パーシング及び管理することができる。

ターゲッティング信号パーサー（ＴａｒｇｅｔｉｎｇＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）は、ＩＰデータグラムなどからサービス／コンテンツ個人化或いはターゲッティングに関連したシグナリング情報を抽出、パーシング及び管理することができる。また、ターゲッティング信号パーサーは、パーシングされたシグナリング情報をターゲッティングプロセッサに伝達できる。

ストリーミングメディアエンジン（ＳｔｒｅａｍｉｎｇＭｅｄｉａＥｎｇｉｎｅ）は、ＩＰデータグラムなどからＡ／Ｖストリーミングのためのオーディオ／ビデオデータの抽出及びデコーティングを行うことができる。

非実時間ファイルプロセッサ（Ｎｏｎ−ｒｅａｌｔｉｍｅＦｉｌｅＰｒｏｃｅｓｓｏｒ）は、ＩＰデータグラムなどからＮＲＴデータ及びａｐｐｌｉｃａｔｉｏｎなどのファイル形態データわ抽出、デコーディング及び管理することができる。

コンポーネントシンクロナイザー（ＣｏｍｐｏｎｅｎｔＳｙｎｃｈｒｏｎｉｚｅｒ）は、ストリーミングオーディオ／ビデオデータ及びＮＲＴデータなどのコンテンツ及びサービスを同期化することができる。

ターゲッティングプロセッサ（ＴａｒｇｅｔｉｎｇＰｒｏｃｅｓｓｏｒ）は、ターゲッティング信号パーサーから受信したターゲッティングシグナリングデータに基づいてサービス／コンテンツの個人化関連演算を処理することができる。

アプリケーションプロセッサ（ＡｐｐＰｒｏｃｅｓｓｏｒ）は、ａｐｐｌｉｃａｔｉｏｎ関連情報及びダウンロードされたａｐｐｌｉｃａｔｉｏｎ状態及びディスプレイパラメータを処理することができる。

Ａ／Ｖプロセッサ（Ａ／ＶＰｒｏｃｅｓｓｏｒ）は、デコーディングされたａｕｄｉｏ及びｖｉｄｅｏｄａｔａ、ａｐｐｌｉｃａｔｉｏｎデータなどに基づいてオーディオ／ビデオレンダリング関連動作を行うことができる。

デバイスマネジャー（ＤｅｖｉｃｅＭａｎａｇｅｒ）は、外部装置との連結及びデータ交換動作を行うことができる。また、デバイスマネジャーは、連動可能な外部装置の追加／削除／更新などを含む、外部装置に対する管理動作を行うことができる。

データシェアリング及びコミュニケーションユニット（ＤａｔａＳｈａｒｉｎｇ＆Ｃｏｍｍ．）は、ハイブリッド放送受信機と外部装置間のデータ伝送及び交換に関連した情報を処理することができる。ここで、伝送及び交換可能なデータは、シグナリング、Ａ／Ｖデータなどであってもよい。

再分配モジュール（ＲｅｄｉｓｔｒｉｂｕｔｉｏｎＭｏｄｕｌｅ（ｓ））は、放送受信機が地上波放送信号を直接受信できない場合、次世代放送サービス及びコンテンツに対する関連情報を取得することができる。また、再分配モジュールは、放送受信機が地上波放送信号を直接受信できない場合、次世代放送システムによる放送サービス及びコンテンツ取得を支援することができる。

コンパニオンデバイス（Ｃｏｍｐａｎｉｏｎｄｅｖｉｃｅ（ｓ））は、本発明の放送受信機に接続して、オーディオ、ビデオ、又はシグナリング含むデータを共有することができる。コンパニオンデバイスは、放送受信機に接続した外部装置のことを指すことができる。

外部モジュール（ＥｘｔｅｒｎａｌＭａｎａｇｅｍｅｎｔ）は、放送サービス／コンテンツ提供のためのモジュールのことを指すことができ、例えば、次世代放送サービス／コンテンツサーバーであってもよい。外部モジュールは、放送受信機に接続した外部装置のことを指すことができる。

図４２は、本発明の一実施例に係るハイブリッド放送受信機を示すブロック図である。

ハイブリッド放送受信機は、次世代放送システムのＤＴＶサービスで地上波放送とブロードバンドとの連動を用いたハイブリッド放送サービスを受信することができる。ハイブリッド放送受信機は、地上波放送で伝送される放送オーディオ／ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ，Ａ／Ｖ）コンテンツを受信し、これと関連したｅｎｈａｎｃｅｍｅｎｔｄａｔａ或いは放送Ａ／Ｖコンテンツの一部をブロードバンドわ介して実時間で受信することができる。本明細書では、放送オーディオ／ビデオ（Ａｕｄｉｏ／Ｖｉｄｅｏ，Ａ／Ｖ）コンテンツをメディアコンテンツと呼ぶこともできる。

ハイブリッド放送受信機は、物理層コントローラ（ＰｈｙｓｉｃａｌＬａｙｅｒＣｏｎｔｒｏｌｌｅｒ）Ｄ５５０１０、チューナー（Ｔｕｎｅｒ）Ｄ５５０２０、物理的フレームパーサー（ＰｈｙｓｉｃａｌＦｒａｍｅＰａｒｓｅｒ）Ｄ５５０３０、連結層パーサー（ＬｉｎｋＬａｙｅｒＦｒａｍｅＰａｒｓｅｒ）Ｄ５５０４０、ＩＰ／ＵＤＰデータグラムフィルター（ＩＰ／ＵＤＰＤａｔａｇｒａｍＦｉｌｔｅｒ）Ｄ５５０５０、ＡＴＳＣ３．０デジタルテレビコントロールエンジン（ＡＴＳＣ３．０ＤＴＶＣｏｎｔｒｏｌＥｎｇｉｎｅ）Ｄ５５０６０、ＡＬＣ／ＬＣＴ＋クライアント（ＡＬＣ／ＬＣＴ＋Ｃｌｉｅｎｔ）Ｄ５５０７０、タイミング制御部（ＴｉｍｉｎｇＣｏｎｔｒｏｌ）Ｄ５５０８０、シグナリングパーサー（ＳｉｇｎａｌｉｎｇＰａｒｓｅｒ）Ｄ５５０９０、ＤＡＳＨクライアント（ＤｙｎａｍｉｃＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰＣｌｉｅｎｔ，ＤＡＳＨＣｌｉｅｎｔ）Ｄ５５１００、ＨＴＴＰ接続クライアント（ＨＴＴＰＡｃｃｅｓｓＣｌｉｅｎｔ）Ｄ５５１１０、ＩＳＯＢＭＦＦパーサー（ＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔＰａｒｓｅｒ，ＩＳＯＢＭＦＦＰａｒｓｅｒ）Ｄ５５１２０及び／又はメディアデコーダ（ＭｅｄｉａＤｅｃｏｄｅｒ）Ｄ５５１３０を含むことができる。

物理層コントローラＤ５５０１０は、ハイブリッド放送受信機が受信しようとする地上波放送チャネルのラジオ周波数（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ、ＲＦ）情報などを用いて、チューナーＤ５５０２０、物理的フレームパーサーＤ５５０３０などの動作を制御することができる。

チューナーＤ５５０２０は、地上波放送チャネルを介して放送関連信号を受信及び処理し、それを適切な形態に変換することができる。例えば、チューナーＤ５５０２０は、受信した地上波放送信号を物理的フレーム（ＰｈｙｓｉｃａｌＦｒａｍｅ）に変換することができる。

物理的フレームパーサーＤ５５０３０は、受信した物理的フレームをパーシングし、それに関連したプロセシングによって連結層フレーム（ＬｉｎｋＬａｙｅｒＦｒａｍｅ）を取得することができる。

連結層パーサーＤ５５０４０は、連結層フレームから連結層シグナリング（ＬｉｎｋＬａｙｅｒｓｉｇｎａｌｉｎｇ）などを取得したり、ＩＰ／ＵＤＰデータグラムを取得するための関連演算を行うことができる。連結層パーサーＤ５５０４０は少なくとも一つのＩＰ／ＵＤＰデータグラムを出力することができる。

ＩＰ／ＵＤＰデータグラムフィルターＤ５５０５０は、受信した少なくとも一つのＩＰ／ＵＤＰデータグラムから特定ＩＰ／ＵＤＰデータグラムをフィルタリングすることができる。すなわち、ＩＰ／ＵＤＰデータグラムフィルターＤ５５０５０は、連結層パーサーＤ５５０４０から出力された少なくとも一つのＩＰ／ＵＤＰデータグラムのうち、ＡＴＳＣ３．０デジタルテレビコントロールエンジンＤ５５０６０によって選択されたＩＰ／ＵＤＰデータグラムを選択的にフィルタリングすることができる。ＩＰ／ＵＤＰデータグラムフィルターＤ５５０５０はＡＬＣ／ＬＣＴ＋などのアプリケーション層伝送プロトコルパケットを出力することができる。

ＡＴＳＣ３．０デジタルテレビコントロールエンジンＤ５５０６０は、各ハイブリッド放送受信機に含まれたモジュール間のインターフェースを担当することができる。また、ＡＴＳＣ３．０デジタルテレビコントロールエンジンＤ５５０６０は、各モジュールに必要なパラメータなどを各モジュールに伝達し、これによって各モジュールの動作を制御することができる。本発明でＡＴＳＣ３．０デジタルテレビコントロールエンジンＤ５５０６０は、メディアプレゼンテーションディスクリプション（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ，ＭＰＤ）及び／又はＭＰＤＵＲＬをＤＡＳＨクライアントＤ５５１００に伝達することができる。また、本発明でＡＴＳＣ３．０デジタルテレビコントロールエンジンＤ５５０６０は、伝送モード（Ｄｅｌｉｖｅｒｙｍｏｄｅ）及び／又は伝送セッション識別子（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ，ＴＳＩ）を、ＡＬＣ／ＬＣＴ＋クライアントＤ５５０７０に伝達することができる。ここで、ＴＳＩは、ＭＰＤ又はＭＰＤＵＲＬ関連シグナリングなどのシグナリングメッセージを含む伝送パケットを伝送するセッション、例えば、アプリケーション層伝送プロトコルであるＡＬＣ／ＬＣＴ＋セッション又はＦＬＵＴＥセッションの識別子を示すことができる。また、伝送セッション識別子はＭＭＴのＡｓｓｅｔｉｄに対応し得る。

ＡＬＣ／ＬＣＴ＋クライアントＤ５５０７０は、ＡＬＣ／ＬＣＴ＋などのアプリケーション層伝送プロトコルパケットを処理し、複数のパケットを収集及び処理して一つ以上のＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔ（ＩＳＯＢＭＦＦ）オブジェクトを生成することができる。アプリケーション層伝送プロトコルパケットには、ＡＬＣ／ＬＣＴパケット、ＡＬＣ／ＬＣＴ＋パケット、ＲＯＵＴＥパケット、及び／又はＭＭＴＰパケットが含まれ得る。

タイミング制御部Ｄ５５０８０は、システムタイム情報を含むパケットを処理し、これによってシステムクロックを制御することができる。

シグナリングパーサーＤ５５０９０は、ＤＴＶ放送サービス関連シグナリングを取得及びパーシングし、パーシングされたシグナリングに基づいてチャネルマップなどを生成して管理することができる。本発明で、シグナリングパーサーは、シグナリング情報から拡張されたＭＰＤ又はＭＰＤ関連情報などをパーシングすることができる。

ＤＡＳＨクライアントＤ５５１００は、実時間ストリーミング（Ｒｅａｌ−ｔｉｍｅＳｔｒｅａｍｉｎｇ）或いは適応的ストリーミング（ＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇ）に関連した演算を行うことができる。ＤＡＳＨクライアントＤ５５１００は、ＨＴＴＰ接続クライアントＤ５５１１０を通じてＨＴＴＰサーバーからＤＡＳＨコンテンツを受信することができる。ＤＡＳＨクライアントＤ５５１００は、受信したＤＡＳＨＳｅｇｍｅｎｔなどを処理してＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔオブジェクトを出力することができる。本発明でＤＡＳＨクライアントＤ５５１００は、ＡＴＳＣ３．０デジタルテレビコントロールエンジンＤ５５０６０に全体ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ（ＦｕｌｌｙｑｕａｌｉｆｉｅｄＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ）又はセグメントＵＲＬを伝達することができる。ここで、全体ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤは、例えば、ＭＰＤＵＲＬ、ｐｅｒｉｏｄ＠ｉｄ及びｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄを結合したＩＤを意味することができる。また、ＤＡＳＨクライアントＤ５５１００は、ＡＴＳＣ３．０デジタルテレビコントロールエンジンＤ５５０６０からＭＰＤ又はＭＰＤＵＲＬを受信することができる。ＤＡＳＨクライアントＤ５５１００は、受信したＭＰＤ又はＭＰＤＵＲＬを用いて所望のメディアストリーム又はＤＡＳＨＳｅｇｍｅｎｔをＨＴＴＰサーバーから受信することができる。本明細書でＤＡＳＨクライアントＤ５５１００はプロセッサと呼ぶことができる。

ＨＴＴＰ接続クライアントＤ５５１１０は、ＨＴＴＰサーバーに対して特定情報を要請し、ＨＴＴＰサーバーからこれに対する応答を受信して処理することができる。ここで、ＨＴＴＰサーバーは、ＨＴＴＰ接続クライアントから受信した要請を処理し、これに対する応答を提供することができる。

ＩＳＯＢＭＦＦパーサーＤ５５１２０は、ＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔオブジェクトからオーディオ／ビデオデータを抽出することができる。

メディアデコーダＤ５５１３０は、受信したオーディオ及び／又はビデオデータをデコーディングし、デコーディングされたオーディオ／ビデオデータをプレゼンテーションするためのプロセシングを行うことができる。

本発明のハイブリッド放送受信機が地上波放送網とブロードバンドとの連動を用いたハイブリッド放送サービスを提供するためには、ＭＰＤに対する拡張又は修正が要求される。前述した地上波放送システムは、拡張又は修正されたＭＰＤを送信することができ、ハイブリッド放送受信機は、拡張又は修正されたＭＰＤを用いて放送又はブロードバンドを介してコンテンツを受信することができる。すなわち、ハイブリッド放送受信機は、拡張又は修正されたＭＰＤは地上波放送を介して受信し、ＭＰＤに基づいて地上波放送又はブロードバンドを介してコンテンツを受信することができる。以下では、既存ＭＰＤと比較して、拡張又は修正されたＭＰＤにさらに含まれるべきエレメント及び属性（ａｔｔｒｉｂｕｔｅ）について記述する。以下で、拡張又は修正されたＭＰＤはＭＰＤと記述されてもよい。

ＭＰＤは、ＡＴＳＣ３．０サービスを表現するために拡張又は修正されてもよい。拡張又は修正されたＭＰＤは、ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ、Ｃｏｍｍｏｎ＠ｐｒｅｓｅｎｔａｂｌｅ、Ｃｏｍｍｏｎ．Ｔａｒｇｅｔｉｎｇ、Ｃｏｍｍｏｎ．ＴａｒｇｅｔＤｅｖｉｃｅ及び／又はＣｏｍｍｏｎ＠ａｓｓｏｃｉａｔｅｄＴｏをさらに含むことができる。

ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅは、ＭＰＤに含まれたセグメントのプレゼンテーションタイムのアンカー、すなわち、基礎となる時間を示すことができる。以下で、ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅをＭＰＤの有効時間（ｅｆｆｅｃｔｉｖｅｔｉｍｅ）として用いることができる。ＭＰＤ＠ａｎｃｈｏｒＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅは、ＭＰＤに含まれたセグメントのうち最も早い再生時点を示すことができる。

ＭＰＤは、共通属性及び要素（ｃｏｍｍｏｎａｔｔｒｉｂｕｔｅｓａｎｄｅｌｅｍｅｎｔｓ）をさらに含むことができる。共通属性及び要素は、ＭＰＤ内のＡｄａｐｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎなどに適用されてもよい。Ｃｏｍｍｏｎ＠ｐｒｅｓｅｎｔａｂｌｅは、ＭＰＤが記述しているメディアがプレゼンテーションが可能なコンポーネントであることを示すことができる。

Ｃｏｍｍｏｎ．Ｔａｒｇｅｔｉｎｇは、ＭＰＤが記述しているメディアのターゲッティング特徴（ｔａｒｇｅｔｉｎｇｐｒｏｐｅｒｔｉｅｓ）及び／又は個別化特徴（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎｐｒｏｐｅｒｔｉｅｓ）を示すことができる。

Ｃｏｍｍｏｎ．ＴａｒｇｅｔＤｅｖｉｃｅは、ＭＰＤが記述しているメディアのターゲットデバイス又は複数のターゲットデバイスを示すことができる。

Ｃｏｍｍｏｎ＠ａｓｓｏｃｉａｔｅｄＴｏは、ＭＰＤが記述しているメディアに関連したａｄａｐｔａｔｉｏｎＳｅｔ及び／又はｒｅｐｒｅｓｅｎｔａｔｉｏｎを示すことができる。

また、ＭＰＤに含まれたＭＰＤ＠ｉｄ、Ｐｅｒｉｏｄ＠ｉｄ及びＡｄａｐｔａｔｉｏｎＳｅｔ＠ｉｄは、ＭＰＤが記述しているメディアコンテンツを特定するために要求されてもよい。すなわち、ＤＡＳＨクライアントは、ＭＰＤに基づいて、受信しようとするコンテンツをＭＰＤ＠ｉｄ、Ｐｅｒｉｏｄ＠ｉｄ及びＡｄａｐｔａｔｉｏｎＳｅｔ＠ｉｄで特定してＡＴＳＣ３．０デジタルテレビコントロールエンジンに伝達することができる。また、ＡＴＳＣ３．０デジタルテレビコントロールエンジンは、当該コンテンツを受信してＤＡＳＨクライアントに伝達することができる。

図４３は、本発明の一実施例に係る次世代ハイブリッド放送システムのプロトコルスタックを示す。図示のように、ＩＰベースハイブリッド放送を支援する次世代放送送信システムは、放送サービスのオーディオ或いはビデオデータなどをＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔ（以下、ＩＳＯＢＭＦＦ）でエンカプセレーション（ｅｎｃａｐｓｕｌａｔｉｏｎ）することができる。ここで、エンカプセレーションは、ＤＡＳＨＳｅｇｍｅｎｔ或いはＭＭＴのＭＰＵ（Ｍｅｄｉａｐｒｏｃｅｓｓｉｎｇｕｎｉｔ）などの形態を用いることができる。また、次世代放送システムは、エンカプセレーションされたデータを、放送網とインターネット網に同一に或いは各伝送網の属性によって互いに異ならせて伝送することができる。また、次世代放送システムは、エンカプセレーションされたデータをブロードキャスト又はブロードバンドのうち少なくとも一つを用いて伝送することができる。ブロードキャストを利用する放送網の場合、放送システムはＩＳＯＢＭＦＦ形態でエンカプセレーションされたデータを、実時間オブジェクト伝送を支援するａｐｐｌｉｃａｔｉｏｎｌａｙｅｒｔｒａｎｓｐｏｒｔプロトコルパケットを用いて伝送することができる。例えば、放送システムは、Ｒｅａｌ−ＴｉｍｅＯｂｊｅｃｔＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）又はＭＭＴＰの伝送パケット（ｔｒａｎｓｐｏｒｔｐａｃｋｅｔ）などにエンカプセレーションすることができる。そして<放送システムは<エンカプセレーションされたデータをさらにＩＰ／ＵＤＰデータグラムとして生成した後、これを放送信号に乗せて伝送することができる。ブロードバンドを利用する場合、放送システムは、エンカプセレーションされたデータをＤＡＳＨなどのストリーミング技法などに基づいて受信側に伝達することができる。

これに加えて、放送システムは、放送サービスのシグナリング情報を次のような方法で伝送することができる。ブロードキャストを利用する放送網の場合、放送システムは、シグナリングの属性などによって次世代放送伝送システム及び放送網のフィジカルレイヤ（ｐｈｙｓｉｃａｌｌａｙｅｒ）を介してシグナリング情報を伝送することができる。ここで、放送システムは、放送信号内に含まれた伝送フレーム（ｔｒａｎｓｐｏｒｔｆｒａｍｅ）の特定データパイプ（ｄａｔａｐｉｐｅ；以下、ＤＰ）などを介してシグナリング情報を伝送することができる。ブロードキャストを介して伝送されるシグナリング形態は、ビットストリーム又はＩＰ／ＵＤＰデータグラムにエンカプセレーションされた形態であってもよい。ブロードバンドを利用する場合、放送システムは、受信機の要請に対する応答としてシグナリングデータをリターンして伝達することができる。

これと加えて、放送システムは、放送サービスのＥＳＧ或いはＮＲＴコンテンツなどを次のような方法で伝送することができる。ブロードキャストを利用する放送網の場合、放送システムは、ａｐｐｌｉｃａｔｉｏｎｌａｙｅｒｔｒａｎｓｐｏｒｔプロトコルパケット、例えば、Ｒｅａｌ−ＴｉｍｅＯｂｊｅｃｔＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ（以下、ＲＯＵＴＥ）、ＭＭＴＰのｔｒａｎｓｐｏｒｔｐａｃｋｅｔなどにＥＳＧ或いはＮＲＴコンテンツをエンカプセレーションすることができる。そして、エンカプセレーションされたＥＳＧ或いはＮＲＴコンテンツをさらにＩＰ／ＵＤＰデータグラムとして生成した後、これを放送信号に乗せて伝送することができる。ブロードバンドを利用する場合、放送システムは、受信機の要請に対する応答としてＥＳＧ或いはＮＲＴコンテンツなどをリターンして伝達することができる。

図４４は、本発明の一実施例に係る次世代放送伝送システムのフィジカルレイヤに伝達される伝送フレームの構造を示す。次世代放送システムは、ブロードキャストを用いて伝送フレームを伝送することができる。同図で、伝送フレームの先頭部に位置しているＰ１は、伝送信号検出（ｔｒａｎｓｐｏｒｔｓｉｇｎａｌｄｅｔｅｃｔｉｏｎ）のための情報が含まれたシンボルを意味することができる。Ｐ１は、チューニング情報（ｔｕｎｉｎｇｉｎｆｏｒｍａｔｉｏｎ）を含むことができ、受信機は、Ｐ１シンボルに含まれたパラメータに基づいてＰ１の次に位置したＬ１パートをデコーティングすることができる。放送システムは、Ｌ１パートに、伝送フレーム構成及び各ＤＰ（ｄａｔａｐｉｐｅ）の特性などに関する情報を含めることができる。すなわち、受信機は、Ｌ１パートをデコーティングして伝送フレーム構成及び各ＤＰ（ｄａｔａｐｉｐｅ）の特性などに関する情報を得ることができる。また、受信機は、ＣｏｍｍｏｎＤＰからＤＰ間の共有すべき情報を取得することができる。実施例によって、伝送フレームはｃｏｍｍｏｎＤＰを含まなくてもよい。

伝送フレームでＡｕｄｉｏ、Ｖｉｄｅｏ、Ｄａｔａなどのコンポーネント（ｃｏｍｐｏｎｅｎｔ）は、ＤＰ１〜ｎで構成されたｉｎｔｅｒｌｅａｖｅｄＤＰ領域に含まれて送信される。ここで、それぞれのサービス（チャネル）を構成するコンポーネントがそれぞれどのＤＰで伝送されるかは、Ｌ１或いはｃｏｍｍｏｎＰＬＰなどを介してシグナリングすることができる。

また、次世代放送システムは、伝送フレームに含まれたサービスに関する情報を速かに取得するための情報を伝送することができる。すなわち、次世代放送システムは、次世代放送受信機に、伝送フレームに含まれた放送サービス及びコンテンツ関連情報を速かに取得させることができる。これに加えて、当該フレーム内に一つ以上の放送局で生成したサービス／コンテンツが存在する場合、受信機にとって放送局によるサービス／コンテンツを効率的に認知するようにすることができる。すなわち、次世代放送システムは、伝送フレーム内に含まれたサービスに対するサービスリスト情報を伝送フレームに含めて伝送することができる。

放送システムは、受信機が当該周波数内の放送サービス及びコンテンツスキャンを速かに行えるようにするために、別途のチャネル、例えば、ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ（ＦＩＣ）などが存在する場合、これを用いて放送サービスに関連した情報を伝送することができる。図４４の中段に示すように、放送システムは、伝送フレームに放送サービススキャン及び取得のための情報を含めて伝送することができる。ここで、放送サービスに対するスキャン及び取得に関する情報を含む領域をＦＩＣと呼ぶことができる。受信機は、ＦＩＣから、一つ以上の放送局で生成及び伝送される放送サービスに関する情報を取得でき、これを用いて、受信機上で利用可能な放送サービスに対するスキャンを容易且つ迅速に行うことができる。

また、伝送フレームに含まれた特定ＤＰは、当該伝送フレーム内で伝送される放送サービス及びコンテンツに対するシグナリングを迅速で剛健に伝送できるＢａｓｅＤＰとして動作することができる。Ｐｈｙｓｉｃａｌｌａｙｅｒの伝送フレームの各ＤＰを介して伝送されるデータは、図４４の下段のように示すことができる。すなわち、Ｌｉｎｋｌａｙｅｒｓｉｇｎａｌｉｎｇ或いはＩＰデータグラムなどは、特定形態のＧｅｎｅｒｉｃｐａｃｋｅｔにエンカプセレーションされた後、ＤＰを介して伝送されてもよい。ここで、ＩＰデータグラムはシグナリングデータを含むことができる。ここで、Ｌｉｎｋ（ｌｏｗ）ｌａｙｅｒｓｉｇｎａｌｉｎｇは、ｆａｓｔｓｅｒｖｉｃｅｓｃａｎ／ａｃｑｕｉｓｉｔｉｏｎ、ＩＰｈｅａｄｅｒｃｏｍｐｒｅｓｓｉｏｎのｃｏｎｔｅｘｔｉｎｆｏｒｍａｔｉｏｎ、ｅｍｅｒｇｅｎｃｙａｌｅｒｔと関連したシグナリングなどを含むことができる。

図４５は、本発明の一実施例に係るアプリケーション層伝送プロトコルの伝送パケットを示す図である。アプリケーション層伝送セッションは、ＩＰアドレス及びポート番号の組合せで構成することができる。アプリケーション層伝送プロトコルがＲＯＵＴＥ（Ｒｅａｌ−ＴｉｍｅＯｂｊｅｃｔＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）である場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）セッションで構成されてもよい。例えば、一つのＬＣＴ伝送セッションを介して一つのメディアコンポーネント（例えば、ＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎなど）を伝達する場合、一つのアプリケーション伝送セッションを介して一つ以上のメディアコンポーネントをマルチプレクシング(ｍｕｌｔｉｐｌｅｘｉｎｇ)して伝送することができる。さらに、一つのＬＣＴ伝送セッションを介して一つ以上の伝送オブジェクト（Ｔｒａｎｓｐｏｒｔｏｂｊｅｃｔ）を伝達することができ、各伝送オブジェクトは、伝送セッションを介して伝達されるＤＡＳＨｒｅｐｒｅｓｅｎｔａｔｉｏｎと関連したＤＡＳＨｓｅｇｍｅｎｔになり得る。

例えば、アプリケーション層伝送プロトコルがＬＣＴベースである場合、次のように伝送パケットを構成することができる。伝送パケットは、ＬＣＴヘッダー、ＲＯＵＴＥヘッダー及びペイロードデータを含むことができ、伝送パケットに含まれた複数のフィールドは次のとおりである。

ＬＣＴヘッダーは、次のようなフィールドを含むことができる。Ｖ（ｖｅｒｓｉｏｎ）フィールドは、当該伝送プロトコルパケットのバージョン情報を示すことができる。Ｃフィールドは、後述するＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎフィールドの長さと関連したフラグ（ｆｌａｇ）を示すことができる。ＰＳＩフィールドは、ｐｒｏｔｏｃｏｌ−ｓｐｅｃｉｆｉｃｉｎｆｏｒｍａｔｉｏｎであって、当該プロトコルに特化された情報を示すことができる。Ｓフィールドは、ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｉｄｅｎｔｉｆｉｅｒ（ＴＳＩ）フィールドの長さと関連したフラグを示すことができる。Ｏフィールドは、ｔｒａｎｓｐｏｒｔｏｂｊｅｃｔｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）フィールドの長さと関連したフラグを示すことができる。Ｈフィールドは、ＴＳＩ、ＴＯＩフィールドの長さにｈａｌｆ−ｗｏｒｄ（１６ｂｉｔｓ）が追加されるか否かを表現することができる。Ａ（ＣｌｏｓｅＳｅｓｓｉｏｎｆｌａｇ）フィールドは、セッションが終了した又は終了が迫ったことを表現することができる。Ｂ（ＣｌｏｓｅＯｂｊｅｃｔｆｌａｇ）フィールドは、伝送中のオブジェクトが終了した又は終了が迫ったことを表現することができる。Ｃｏｄｅｐｏｉｎｔフィールドは、当該パケットのペイロードをエンコーディング或いはデコーティングすることに関連した情報を示すことができる。例えば、ペイロードタイプなどがこれに該当し得る。ＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎフィールドは、ｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌと関連した情報を含むことができる。例えば、ｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌと関連した情報は、Ｃｕｒｒｅｎｔｔｉｍｅｓｌｏｔｉｎｄｅｘ（ＣＴＳＩ）、ｃｈａｎｎｅｌｎｕｍｂｅｒ、又は当該チャネル内のｐａｃｋｅｔｓｅｑｕｅｎｃｅｎｕｍｂｅｒなどを含むことができる。ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒフィールドは、伝送セッションの識別子を示すことができる。ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒフィールドは、伝送セッションを介して伝送されるオブジェクトの識別子を示すことができる。

ＲＯＵＴＥ（ＡＬＣ）Ｈｅａｄｅｒは、ＦｏｒｗａｒｄＥｒｒｏｒｃｏｒｒｅｃｔｉｏｎｓｃｈｅｍｅなどに関連したペイロード識別子などを含む、前のＬＣＴヘッダーの追加情報伝送を含むことができる。

Ｐａｙｌｏａｄｄａｔａは、当該パケットのペイロードの実質的なデータ部分を示すことができる。

図４６は、本発明の一実施例に係る、次世代放送システムがシグナリングデータを伝送する方法を示す。次世代放送システムのシグナリングデータは、図示のように伝送することができる。受信機における迅速なサービス／コンテンツスキャン及び取得を支援するために、次世代放送送信システムは、当該ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅによって伝達される放送サービスに対するシグナリングデータをＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ（以下、ＦＩＣ）などを介して伝達することができる。本明細書で、ＦＩＣは、サービスリストに関する情報を意味できる。仮に、別途のＦＩＣが存在しない場合リンクレイヤシンシグナリング（ｌｉｎｋｌａｙｅｒｓｉｇｎａｌｉｎｇ）が伝達される経路を介して伝達されてもよい。すなわち、サービス及びサービス内のコンポーネント（オーディオ、ビデオなど）に関する情報などを含むシグナリング情報は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内の一つ以上のＤＰを介してＩＰ／ＵＤＰデータグラムにエンカプセレーションされて伝送されてもよい。実施例によって、サービス及びサービスコンポーネントに対するシグナリング情報は、アプリケーション層伝送パケット（例えば、ＲＯＵＴＥパケット又はＭＭＴＰパケットなど）にエンカプセレーションされて伝送されてもよい。

図４６の上段は、上述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／取得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどに関する詳細な情報を含むシグナリングデータがＩＰデータグラムにエンカプセレーションされて特定ＤＰを介して伝達されている。本明細書で、サービスなどに関する詳細な情報を含むシグナリングデータを、サービスレイヤシグナリングと呼ぶことができる。

図４６の中段は、上述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／取得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどに関する詳細な情報を含むシグナリングデータがＩＰデータグラムにエンカプセレーションされて特定ＤＰを介して伝達されている。また、サービスに含まれた特定コンポーネントなどに関する情報などを含むシグナリングデータの一部がアプリケーションレイヤ伝送プロトコル内の一つ以上の伝送セッションを介して伝達されてもよい。例えばシグナリングデータの一部はＲＯＵＴＥセッション内の一つ以上の伝送セッションを介して伝達されてもよい。

図４６の下段は、上述したシグナリングデータがＦＩＣ及び一つ以上のＤＰを介して伝達される場合の実施例を示す。これは、迅速なサービススキャン／取得を支援するためのシグナリングデータがＦＩＣを介して伝達され、サービスなどに関する詳細な情報を含むシグナリングデータはＲＯＵＴＥセッション内の一つ以上の伝送セッションを介して伝達されている。

図４７は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。本明細書は、次世代放送受信装置が放送サービスをスキャンして取得するためのシグナリング情報を提案する。次世代放送システムでは特定周波数内における一つ以上の放送局で生成した放送サービス及びコンテンツが伝送されてもよい。受信機は、当該周波数内に存在する放送局及び当該放送局のサービス／コンテンツを迅速で容易にスキャンするために、上述したシグナリング情報を利用することができる。これは、図示のようなｓｙｎｔａｘで表すことができ、ＸＭＬなどの他のフォーマットで表されてもよい。

迅速なサービススキャン及び取得のためのシグナリング情報は、フィジカルレイヤ伝送チャネル（ｐｈｙｓｉｃａｌｌａｙｅｒｔｒａｎｓｐｏｒｔｆｒａｍｅ）内の別途のチャネルであるＦＩＣを介して伝達することができる。また、上述したシグナリング情報は、Ｐｈｙｓｉｃａｌｌａｙｅｒのデータパイプ間の共有可能な情報を伝達し得るＣｏｍｍｏｎＤＰなどで伝達されてもよい。また、リンクレイヤのシグナリングが伝達される経路で伝達されてもよい。また、上述したシグナリング情報は、ＩＰデータグラムにエンカプセレーションされて特定ＤＰを介して伝達されてもよい。また、上述したシグナリング情報は、サービスシグナリングが伝達されるサービスシグナリングチャネル（ｓｅｒｖｉｃｅｓｉｇｎａｌｉｎｇｃｈａｎｎｅｌ）或いはアプリケーションレイヤ（ａｐｐｌｉｃａｔｉｏｎｌａｙｅｒ）の伝送セッション（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）などを介して伝達されてもよい。

迅速なサービススキャン及び取得のためのシグナリング情報（ＦＩＣ情報）は、次のようなフィールドのうち少なくとも一つを含むことができる。本明細書で、ＦＩＣ情報をサービス取得情報と呼ぶこともできる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（ＶｅｒｓｉｏｎｏｆｓｔｒｕｃｔｕｒｅｏｆＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒｏｆｏｖｅｒａｌｌｂｒｏａｄｃａｓｔｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓｄａｔａｖｅｒｓｉｏｎｏｆｔｈｉｓＦＩＣｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｂａｓｅ＿ＤＰ＿ＩＤフィールドは、当該パーティションのベースＤＰに対する識別子を示すことができる。ベースＤＰは、サービスシグナリングテーブルを含むことができる。サービスシグナリングテーブルは、当該パーティション内の全てのサービスに対するリストを含むことができる。すなわち、サービスシグナリングテーブルは、伝送されるサービスをリスティングすることができる。また、各サービスに対する基本属性を定義することができる。ベースＤＰは、当該パーティション内でロバストなＤＰであってもよく、当該パーティションに対する他のシグナリングテーブルを含むこともできる。ｂａｓｅ＿ＤＰ＿ｖｅｒｓｉｏｎフィールドは、当該ベースＤＰを介して伝送されるデータの変化を示すバージョン情報を示すことができる。例えば、ベースＤＰを介してサービスシグナリングなどが伝達される場合、サービスシグナリングの変化が発生すると、ｂａｓｅ＿ＤＰ＿ｖｅｒｓｉｏｎフィールドは１ずつ増加してもよい。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿Ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か、又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。

図４８は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッション（ａｐｐｌｉｃａｔｉｏｎｌａｙｅｒｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）に関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現することができるが、実施例によってＸＭＬなど他のフォーマットで示してもよい。ＦＩＣ情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（ＶｅｒｓｉｏｎｏｆｓｔｒｕｃｔｕｒｅｏｆＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒｏｆｏｖｅｒａｌｌｂｒｏａｄｃａｓｔｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓｄａｔａｖｅｒｓｉｏｎｏｆｔｈｉｓＦＩＣｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）（例えば、ＲＯＵＴＥ又はＭＭＴＰｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、当該伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰｓｅｓｓｉｏｎ）を介して伝送されるデータがサービスシグナリングを含んでいることを示すことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。

図４９は、本発明の一実施例に係るＦＩＣベースシグナリングを伝送する方法を示す。上述したＦＩＣベースシグナリングが伝達される実施例は、同図のとおりである。本明細書で、ＦＩＣベースシグナリングは、サービス取得情報又はサービス取得シグナリングと呼ぶことができる。図示のように、フィジカルレイヤシグナリングは、サービス取得情報に対するフィールドを含むことができる。サービス取得情報に対するフィールドは、サービス取得情報（ＦＩＣ）をパーシングするか否かを受信機に知らせることができる。受信機は、サービス取得情報をパーシングし、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報を介してサービスシグナリングのデータが変更されたか否かを確認することができる。サービスシグナリングデータが変更された場合、放送信号受信機は、ＬＳＩＤ＿ＤＰフィールドを用いて伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を確認することができる。放送受信機は、当該ＤＰ識別子が示すＤＰをパーシングして伝送セッションに対する細部情報を確認することができる。すなわち、次世代放送システムのシグナリング方法は、フィジカルレイヤシグナリングが、サービス取得情報をパーシングするか否かをシグナリングし、サービス取得情報が伝送セッションに対する細部情報の位置をシグナリングして、伝送セッションに対する細部情報を確認する順序を含むことができる。ここで、伝送セッションに対する細部情報は、ＭＰＤ伝送テーブル、アプリケーションシグナリングテーブル、伝送セッションディスクリプタ（ＬＳＩＤ）及び／又はコンポーネントマッピングテーブル（ＣＭＴ）を含むことができる。

図５０は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。ＦＩＣ情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（ＶｅｒｓｉｏｎｏｆｓｔｒｕｃｔｕｒｅｏｆＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒｏｆｏｖｅｒａｌｌｂｒｏａｄｃａｓｔｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓｄａｔａｖｅｒｓｉｏｎｏｆｔｈｉｓＦＩＣｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、関連したサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する度に当該フィールドは、１ずつ増加してもよい。受信機は、ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて当該サービスと関連したシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドは、サービスシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタはｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。

図５１は、本発明の他の実施例に係る、ＦＩＣベースシグナリングを伝送する方法を示す。上述したＦＩＣベースシグナリングが伝達される実施例は、同図のとおりである。本明細書で、ＦＩＣベースシグナリングは、サービス取得情報又はサービス取得シグナリングと呼ぶことができる。図示のように、フィジカルレイヤシグナリングは、サービス取得情報に対するフィールドを含むことができる。サービス取得情報に対するフィールドは、サービス取得情報（ＦＩＣ）をパーシングするか否かを受信機に知らせることができる。受信機は、サービス取得情報をパーシングし、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報を介してサービスシグナリングのデータが変更されたか否かを確認することができる。サービスシグナリングデータが変更された場合、放送信号受信機は、ＬＳＩＤ＿ＤＰフィールドを用いて、伝送セッションに関する詳細な情報を含んでいるＬＳＩＤ或いはＬＳＩＤＴａｂｌｅなどを、ＬＳＩＤ＿ＤＰフィールドから識別したＤＰを介して取得することができる。これに加えて、受信機は、ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ、ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｉｇｎａｌｉｎｇ＿ＤＰなどの情報を用いてシグナリングデータの変化などを認知し、ｓｉｇｎａｌｉｎｇ＿ＤＰから識別したＤＰを介してシグナリングデータを取得することができる。

すなわち、次世代放送システムのシグナリング方法は、フィジカルレイヤシグナリングがサービス取得情報をパーシングするか否かをシグナリングし、サービス取得情報が伝送セッションに対する細部情報の位置をシグナリングして、伝送セッションに対する細部情報を確認する順序を含むことができる。ここで、伝送セッションに対する細部情報は、ＭＰＤ伝送テーブル、アプリケーションシグナリングテーブル、伝送セッションディスクリプタ（ＬＳＩＤ）及び／又はコンポーネントマッピングテーブル（ＣＭＴ）を含むことができ、伝送セッションに対する各細部情報は、互いに異なる例によって伝達されてもよい。

図５２は、本発明の一実施例に係る、次世代放送システムのサービスシグナリングメッセージフォーマットを示す図である。本明細書でサービスシグナリングメッセージは、サービスなどに関する詳細な情報を含むシグナリングデータ又はサービスレイヤシグナリングと称することができる。サービスシグナリングメッセージは、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅを含む構造であってもよい。シグナリングメッセージは、ｂｉｎａｒｙ或いはＸＭＬフォーマットなどで表現されてもよい。これは、ＩＰデータグラム或いはアプリケーションレイヤ伝送パケット（例えば、ＲＯＵＴＥ或いはＭＭＴＰなど）のペイロードに含まれて伝送されてもよい。Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒのｓｙｎｔａｘは次のとおりであり、これは、ＸＭＬなどの他のフォーマットで表されてもよい。Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、次のフィールドを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは、シグナリングメッセージの識別子を示すことができる。例えば、シグナリングメッセージがｓｅｃｔｉｏｎ形態で表される場合、ｓｉｇｎａｌｉｎｇｔａｂｌｅｓｅｃｔｉｏｎのｉｄを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈフィールドは、含まれているシグナリングメッセージの長さを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、シグナリングメッセージに対する識別子の拡張情報を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドと共にシグナリングを識別する情報として用いることができる。例えば、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、シグナリングメッセージのプロトコルバージョンなどを含むことができる。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、シグナリングメッセージのバージョン情報を示すことができる。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、当該シグナリングメッセージが含む内容が変更する場合に変更されてもよい。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、含まれているシグナリングメッセージが現在可用か否かを示すことができる。このフィールドの値が「１」である場合、含まれている現在シグナリングメッセージが現在可用であることを示すことができる。このフィールドの値が「０」である場合、現在シグナリングメッセージが可用でなく、後に、同一のｓｉｇｎａｌｉｎｇ＿ｉｄ、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ、或いはｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒを含むシグナリングメッセージが可用であることを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒフィールドは、当該シグナリングメッセージがｆｒａｇｍｅｎｔａｔｉｏｎされたか否かを示すことができる。このフィールドの値が「１」である場合、当該メッセージがｆｒａｇｍｅｎｔａｔｉｏｎされたことを示し、このような場合、ｓｉｇｎａｌｉｎｇ＿ｍｅｓｓａｇｅ＿ｄａｔａ（）にシグナリングデータの一部が含まれていることを示すことができる。このフィールドの値が「０」の場合、ｓｉｇｎａｌｉｎｇ＿ｍｅｓｓａｇｅ＿ｄａｔａ（）に全体シグナリングデータが含まれていることを示すことができる。ｐａｙｌｏａｄ＿ｆｏｒｍａｔ＿ｉｎｄｉｃａｔｏｒフィールドは、現在シグナリングメッセージヘッダー部分にｐａｙｌｏａｄ＿ｆｏｒｍａｔ値を含んでいるか否かを示すことができる。このフィールドの値が「１」である場合、シグナリングメッセージヘッダー部分にｐａｙｌｏａｄ＿ｆｏｒｍａｔ値が含まれていることを示すことができる。ｅｘｐｉｒａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒフィールドは、現在シグナリングメッセージヘッダー部分にｅｘｐｉｒａｔｉｏｎ値を含んでいるか否かを示すことができる。このフィールドの値が「１」である場合、シグナリングメッセージヘッダー部分にｅｘｐｉｒａｔｉｏｎ値が含まれていることを示すことができる。ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは、一つのシグナリングメッセージが複数のｆｒａｇｍｅｎｔに分けられて伝送される場合、現在シグナリングメッセージのｆｒａｇｍｅｎｔナンバーを示すことができる。ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは、一つのシグナリングメッセージが複数のｆｒａｇｍｅｎｔに分けられて伝送される場合、当該シグナリングメッセージの最後のデータを含むｆｒａｇｍｅｎｔのナンバーを示すことができる。ｐａｙｌｏａｄ＿ｆｏｒｍａｔフィールドは、ペイロードに含まれるシグナリングメッセージデータのフォーマットを示すことができる。実施例として、ｂｉｎａｒｙ、ＸＭＬなどを示すことができる。ｅｘｐｉｒａｔｉｏｎフィールドは、ペイロードに含まれているシグナリングメッセージの有効時間を示すことができる。

図５３は、本発明の一実施例に係る、次世代放送システムで用いるサービスシグナリングテーブルを示す。本発明で、次世代放送網で使用可能なサービスシグナリングテーブル／メッセージなどは次のとおりであり、下記のような情報などを含めてシグナリングすることができる。各テーブル／メッセージに含まれた情報は、異なるテーブルに分けられて個別的に伝送されてもよく、図示の実施例によって限定されない。また、実施例によって、異なるテーブルに属したシグナリング情報は一つのテーブルに併合されて伝送されてもよい。Ｓｅｒｖｉｃｅｍａｐｐｉｎｇｔａｂｌｅは、サービスの属性及びサービスと関連した情報を含むことができる。サービスの属性情報は、例えば、ＩＤ、名前、カテゴリーなどの情報を含むことができ、サービスと関連した情報は、サービスを取得し得る経路情報などを含むことができる。ＭＰＤＤｅｌｉｖｅｒｙｔａｂｌｅは、サービス／コンテンツと関連したＤＡＳＨＭＰＤを含んだり、ＤＡＳＨＭＰＤを取得し得る経路情報などを含むことができる。Ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅは、サービス内コンポーネント情報及びコンポーネントと関連した情報を含むことができる。コンポーネント情報は、関連したＤＡＳＨｒｅｐｒｅｓｅｎｔａｔｉｏｎ情報などを含むことができ、コンポーネントと関連した情報は、コンポーネントを取得し得る経路情報などを含むことができる。ＬＳＩＤｔａｂｌｅは、サービス／コンポーネントなどを伝達する伝送セッション及び伝送パケットの構成などに関する情報を含むことができる。ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔＤｅｌｉｖｅｒｙｔａｂｌｅは、サービス内コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ対するＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ情報或いはこれを取得し得る経路などに関する情報を含むことができる。Ａｐｐｌｉｃａｔｉｏｎｐａｒａｍｅｔｅｒｔａｂｌｅは、放送サービスと関連したアプリケーションに対する細部情報及びこれを取得し得る経路などを含む、関連した情報を含むことができる。このようなシグナリングメッセージ／テーブルなどが放送網を介して伝送される場合、ＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）或いはＳＳＣ（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌ）、或いはアプリケーションレイヤ伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰｓｅｓｓｉｏｎ）などを介して伝送されてもよい。さらに、インターネット網（ブロードバンド）を介して伝送されてもよい。

図５４は、本発明の一実施例に係る次世代放送システムで用いられるサービスマッピングテーブルを示す図である。後述する内容は、シグナリングメッセージヘッダーの後に位置したサービスシグナリングメッセージ部分に含めて伝送することができる。

サービスマッピングテーブルは、サービスマッピングシグナリングに関する情報を含むことができ、ＸＭＬ形態又はｂｉｎａｒｙ形態などで表現され得る。サービスシグナリングの一つであるサービスマッピングテーブルは、サービス識別子（ｉｄ）、サービスタイプ、サービスネーム、チャネルナンバー、ＲＯＵＴＥセッション関連情報、ＭＰＤ関連情報、コンポーネントシグナリング位置情報を含むことができる。サービス識別子は、サービスを識別する情報を示すことができ、ｉｄ属性で表現され得る。サービスタイプ情報は、サービスのタイプを示す情報であって、ｓｅｒｖｉｃｅＴｙｐｅ属性で表現されてもよい。サービスネーム情報は、サービスの名前を示す情報であって、ｓｅｒｖｉｃｅＮａｍｅ属性で表現されてもよい。チャネルナンバー情報は、サービスと関連したチャネルナンバーを示す情報であって、ｃｈａｎｎｅｌＮｕｍｂｅｒ属性で表現されてもよい。

ＲＯＵＴＥセッション関連情報は、ｓｏｕｒｃｅＩＰ属性、ｄｅｓｔｉｎａｔｉｏｎＩＰ属性、ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性を含むことができる。ｓｏｕｒｃｅＩＰ属性は、関連したデータを含むＩＰデータグラムのソースアドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＩＰ属性は、関連したデータを含むＩＰデータグラムの目的地アドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は、関連したデータを含むＩＰデータグラムの目的地ポートナンバーを示すことができる。

また、ＲＯＵＴＥセッション関連情報は、伝送セッションに対する細部情報（ＬＳＩＤ）を含むことができ、例えば、各ＬＳＩＤ位置情報及び各ＬＳＩＤ位置情報のデリバリーモード情報を含むことができる。また、伝送セッションに対する細部情報（ＬＳＩＤ）は、ブートストラップ情報を含むことができる。ＬＳＩＤに含まれたブートストラップ情報は、デリバリーモードによるＬＳＩＤのブートストラップ情報を含むことができる。ブートストラップ情報に含まれた属性の詳細は後述する。

ＭＰＤ関連情報は、ＭＰＤ又はＭＰＤシグナリングロケーションに関する情報を含むことができる。ＭＰＤに対する情報は、バージョン属性を含むことができ、ＭＰＤのバージョンを示すことができる。ＭＰＤシグナリングロケーション情報は、ＭＰＤ又はＭＰＤＵＲＬと関連したシグナリングを取得し得る位置を示すことができる。ＭＰＤシグナリングロケーションに含まれたデリバリーモード情報は、ＭＰＤロケーションシグナリングのデリバリーモードを示すことができる。ＭＰＤシグナリングロケーションに含まれたブートストラップインフォ情報は、デリバリーモードによるＭＰＤ又はＭＰＤＵＲＬのブートストラップ情報を含むことができる。

コンポーネントシグナリングロケーション関連情報は、デリバリーモード属性を含むことができる。デリバリーモード属性は、当該コンポーネントシグナリングロケーション情報のデリバリーモードを示すことができる。ＭＰＤシグナリングロケーションに含まれたブートストラップインフォ情報は、デリバリーモードによる当該コンポーネントロケーションシグナリングのブートストラップ情報を含むことができる。

ブートストラップ情報は、デリバリーモードによって次のような属性のうち少なくとも一つを含むことができる。

ｓｏｕｒｃｅＩＰ属性は、関連したデータを含むＩＰデータグラムのソースアドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＩＰ属性は、関連したデータを含むＩＰデータグラムの目的地アドレスを示すことができる。ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は、関連したデータを含むＩＰデータグラムの目的地ポートナンバーを示すことができる。ｔｓｉ属性は、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔｐａｃｋｅｔｓ）を伝達する伝送セッションに対する識別子を示すことができる。ＵＲＬ属性は、関連したデータを取得し得るＵＲＬを示すことができる。ｐａｃｋｅｔｉｄは、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔｐａｃｋｅｔｓ）の識別子を示すことができる。

図５５は、本発明の一実施例に係る、次世代放送システムのサービスシグナリングテーブルを示す。次世代放送システムで受信機が放送サービス及びコンテンツを受信できるようするために放送サービスシグナリングを提供することができる。これは、シグナリングデータが同じ伝送セッション識別子（ＴＳＩ）を介して伝送される場合、受信機が関連シグナリングを取得できるようにする。サービスシグナリングテーブルは、図示のようにバイナリフォーマットで表現されてもよく、実施例によってＸＭＬなど他の形態で表現されてもよい。また、サービスシグナリングテーブルは、前述したシグナリングメッセージフォーマットでエンカプセレーションされてもよい。サービスシグナリングテーブルは、次のようなフィールドを含むことができる。ＳＳＴ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、サービスシグナリングテーブルのバージョンを示すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ＳＳＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該サービスシグナリングテーブルのデータバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティション内に含まれた少なくとも一つ以上のサービスの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該サービスの識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスの名前を示すことができる。ＭＰＤ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、ブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＭＰＤを取得できるか否かを示すことができる。ＣＭＴ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、ブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅ（ＣＭＴ）を利用できるか否かを示すことができる。ＡＳＬ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、ブロードキャスト、セルラーネットワーク及び／又はｗｉｆｉ／イーサネットを介してＡｐｐｌｉｃａｔｉｏｎＳｉｇｎａｌｉｎｇＴａｂｌｅ（ＡＳＴ）を利用できるか否かを示すことができる。ＤＰ＿ＩＤフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬをブロードキャストを介して伝達するＤＰの識別子を示すことができる。ＬＣＴ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルのＩＰアドレスを示すことができる。ＬＣＴ＿ＵＤＰ＿ｐｏｒｔフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルのＵＤＰポートを示すことができる。ＬＣＴ＿ＴＳＩフィールドは、ＭＰＤ、ＣＭＴ及び／又はＡＳＬを伝達するＬＣＴチャネルの伝送セッション識別子（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ，ＴＳＩ）を示すことができる。ＭＰＤ＿ＴＯＩフィールドは、ＭＰＤがブロードキャストを介して伝達される場合、ＭＰＤの伝送オブジェクト識別子（ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ）を示すことができる。ＣＭＴＴＯＩフィールドは、ＣＭＴがブロードキャストを介して伝達される場合、ＣＭＴの伝送オブジェクト識別子（ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ）を示すことができる。ＡＳＴ＿ＴＯＩフィールドは、ＡＳＴがブロードキャストを介して伝達される場合、ＡＳＴの伝送オブジェクト識別子（ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ）を示すことができる。ＭＰＤ＿ＵＲＬフィールドは、ブロードバンドを介してＭＰＤを取得し得るＵＲＬ情報を示すことができる。ＣＭＴ＿ＵＲＬフィールドは、ブロードバンドを介してＣＭＴを取得し得るＵＲＬ情報を示すことができる。ＡＳＴ＿ＵＲＬフィールドは、ブロードバンドを介してＡＳＴを取得し得るＵＲＬ情報を示すことができる。

図５６は、本発明の一実施例に係る、次世代放送システムで用いられるコンポーネントマッピングテーブルを示す図である。後述する内容は、シグナリングメッセージヘッダーの後に位置したサービスシグナリングメッセージ部分に含まれて伝送されてもよい。コンポーネントマッピングテーブルは、コンポーネントマッピングシグナリングに関する情報を含むことができ、ＸＭＬ形態又はｂｉｎａｒｙ形態などで表現されてもよい。サービスシグナリングの一つであるコンポーネントマッピングテーブルは、次のようなフィールドを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは、当該テーブルがｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅであることを示す識別子を含むことができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅｓｙｎｔａｘなどのｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎフィールドは、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該コンポーネントと関連したサービスに対する識別子を示すことができる。Ｎｕｍ＿ｃｏｍｐｏｎｅｎｔフィールドは、当該サービスが含むコンポーネントの個数を示すことができる。Ｍｐｄ＿ｉｄフィールドは、コンポーネントと関連したＤＡＳＨＭＰＤ識別子を示すことができる。Ｐｅｒｉｏｄ＿ｉｄフィールドは、コンポーネントと関連したＤＡＳＨｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ｉｄフィールドは、コンポーネントと関連したＤＡＳＨｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。Ｓｏｕｒｃｅ＿ＩＰフィールドは、当該コンポーネントデータを含むＩＰ／ＵＤＰデータグラムｓｏｕｒｃｅＩＰアドレスを示すことができる。Ｄｅｓｔ＿ＩＰフィールドは、当該コンポーネントデータを含むＩＰ／ＵＤＰデータグラムｄｅｓｔｉｎａｔｉｏｎＩＰアドレスを示すことができる。ｐｏｒｔフィールドは、当該コンポーネントデータを含むＩＰ／ＵＤＰデータグラムＰｏｒｔナンバーを示すことができる。ｔｓｉフィールドは、当該コンポーネントデータを含むアプリケーションレイヤ伝送セッションの識別子を示すことができる。ＤＰ＿ｉｄフィールドは、当該コンポーネントデータを伝達するフィジカルレイヤデータパイプ（ｐｈｙｓｉｃａｌｌａｙｅｒｄａｔａｐｉｐｅ）の識別子を示すことができる。これらの情報を用いてＣＭＴは各サービスに関連したコンポーネントを定義し、当該コンポーネントを受信し得る位置又は経路を受信機に知らせることができる。

図５７は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢｒｏａｄｃａｓｔＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＳｅｇｍｅｎｔのＢａｓｅＵＲＬを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。

ＢＢＣｏｍｐは、ｂｒｏａｄｂａｎｄ網を介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢＢＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＳｅｇｍｅｎｔのＢａｓｅＵＲＬを示すことができる。

ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＦｏｒｅｉｇｎＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＳｅｇｍｅｎｔのＢａｓｅＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるｄａｔａｐｉｐｅの識別子を示すことができる。上記のＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。図５７の下段に示すように、Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、前述した形態に従うことができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ或いはその一部を含むことができる。上記のような情報を用いてＣＭＴは各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。

図５８は、本発明の一実施例に係る、次世代放送システムのコンポーネントマッピングテーブルのシンタックスを示す。次世代放送システムは、受信機が放送サービスのコンポーネントを取得できるようにコンポーネントマッピングテーブル（ＣＭＴ）をシグナリングすることができる。これは、ｂｉｎａｒｙ又はＸＭＬなど他の形態で表現されてもよく、また、前述したシグナリングメッセージフォーマットでエンカプセレーションされてもよい。コンポーネントマッピングテーブルは、次のようなフィールドを含むことができる。ＣＭＴ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｅ（ＣＭＴ）の構造（ｓｔｒｕｃｔｕｒｅ）のバージョンを示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該ＣＭＴが提供するコンポーネント位置と関連したサービスの識別子を示すことができる。ＣＭＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＣＭＴのデータバージョンを示すことができる。ｎｕｍ＿ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍｓフィールドは、当該サービスと関連した少なくとも一つのコンポーネントを含むブロードキャストストリームの個数を示すことができる。ＴＳＩＤフィールドは、当該ブロードキャストストリームの伝送セッション識別子を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、当該サービスと関連した少なくとも一つのコンポーネントを含むブロードキャストストリームのパーティション個数を示すことができる。ＣＭＴは、複数のパーティションを含むことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｎｕｍ＿ｄａｔａ＿ｐｉｐｅｓフィールドは、当該サービスと関連した少なくとも一つのコンポーネントを含むパーティション内のデータパイプの個数を示すことができる。ＤＰ＿ＩＤフィールドは、各データパイプの識別子を示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓフィールドは、各データパイプに含まれた伝送セッション（例えば、ＲＯＵＴＥセッション）の個数を示すことができる。各データパイプは、当該サービスと関連した少なくとも一つのコンポーネントを含むことができる。ＩＰ＿ａｄｄｒｅｓｓフィールドは、各伝送セッションのＩＰアドレスを示すことができる。ＵＤＰ＿ｐｏｒｔフィールドは、各伝送セッションのＵＤＰｐｏｒｔを示すことができる。ｎｕｍ＿ＬＣＴ＿ｃｈａｎｎｅｌｓフィールドは、当該サービスと関連したコンポーネントを含む伝送セッション内のＬＣＴチャネルの個数を示すことができる。ＬＣＴ＿ＴＳＩフィールドは、伝送セッション識別子（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ，ＴＳＩ）を示すことができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤフィールドは、当該ＬＣＴチャネルによって運搬されるＲｅｐｒｅｓｅｎｔａｔｉｏｎの識別子を示すことができる。Ｉｎｔｅｒｎｅｔ＿ａｖａｉｌａｂｉｌｉｔｙフィールドは、当該Ｒｅｐｒｅｓｅｎｔａｔｉｏｎがインターネット又はブロードバンドを介しても受信され得るか否かを示す識別子であってもよい。ｎｕｍ＿ｉｎｔｅｒｎｅｔ＿ｏｎｌｙ＿ｒｅｐｔｎｓフィールドは、インターネット又はブロードバンドのみを介して受信し得るＲｅｐｒｅｓｅｎｔａｔｉｏｎの個数を示すことができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤフィールドは、ｎｕｍ＿ｉｎｔｅｒｎｅｔ＿ｏｎｌｙ＿ｒｅｐｔｎｓのｌｏｏｐ内で、インターネット又はブロードバンドのみを介して受信し得るＲｅｐｒｅｓｅｎｔａｔｉｏｎの識別子を示すことができる。上記のような情報を用いてＣＭＴは、各サービスに関連したコンポーネントを定義し、当該コンポーネントを受信し得る位置又は経路を受信機に知らせることができる。

図５９は、本発明の一実施例に係る、次世代放送システムで各サービスと関連したシグナリングをブロードバンド網を介して伝達する方法を示す。次世代放送システムは、サービスと関連したシグナリングをブロードバンド網などを介して受信機に伝達することができる。次世代放送システムは、ＵＲＬＳｉｇｎａｌｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎを用いてブロードバンド網などを介してシグナリングを受信機に伝達することができる。これは、ＸＭＬ又はｂｉｎａｒｙなど他の形態で表されてもよい。ＵＲＬＳｉｇｎａｌｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎは、次のような属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、シグナリングと関連したサービスの識別子を示すことができる。ｍｐｄＵＲＬ属性は、ブロードバンドＭＰＤのＵＲＬを示すことができる。ｃｓｔＵＲＬ属性は、ブロードバンドＣＭＴのＵＲＬを示すことができる。ＣＭＴは、放送サービス内コンポーネントデータ取得経路に関する情報を含むことができる。ａｓｔＵＲＬ属性は、ブロードバンドＡＳＴのＵＲＬを示すことができる。ＡＳＴは、放送サービスと関連したアプリケーションに関する情報を含むことができる。受信機は、ディスクリプションを受信し、各シグナリングに対するＵＲＬに基づいて当該シグナリングを受信することができる。上記のＵＲＬＳｉｇｎａｌｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。同図の下段に示すように、Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、上記で提案した形態にしたがうことができ、ヘッダーの後にＵＲＬＳｉｇｎａｌｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。

図６０は、本発明の一実施例に係る、次世代放送システムでＭＰＤをシグナリングする方案を示す。次世代放送網で使用可能な放送サービスのＭＰＤに対するシグナリングメッセージは、同図の上段に示すように、Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ及びＳｉｇｎａｌｉｎｇｍｅｓｓａｇｅで構成されてもよい。Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、前述した形態にしたがうことができ、ＭＰＤｄｅｌｉｖｅｒｙｔａｂｌｅ情報は、次のような情報を含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ情報は、当該シグナリングメッセージがＭＰＤ或いはＭＰＤを取得し得る経路情報を含むシグナリングメッセージであることを識別できる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、当該シグナリングメッセージのｓｙｎｔａｘなどのＭＰＤｄｅｌｉｖｅｒｙｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎ情報は、ＭＰＤｄｅｌｉｖｅｒｙｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄ情報は、当該シグナリング情報と関連したサービス識別子を示すことができる。Ｍｐｄ＿ｉｄ情報は、シグナリングメッセージと関連したＤＡＳＨＭＰＤの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎ情報は、当該ＭＰＤの変化などを示すバージョン情報を示すことができる。Ｄｅｌｉｖｅｒｙ＿ｍｏｄｅ情報は、シグナリングメッセージが当該ＭＰＤを含んでいるか他の経路を通じて伝達されるかに関する情報を示すことができる。ＭＰＤ＿ｄａｔａ（）情報は、当該シグナリングメッセージがＭＰＤを含む場合、ＭＰＤデータ自体を含むことができる。ＭＰＤ＿ｐａｔｈ情報は、ＭＰＤを取得し得る経路に関する情報を含むことができる。例えば、経路としてＵＲＬなどを示すことができる。

ＭＰＤｄｅｌｉｖｅｒｙｔａｂｌｅｄｅｓｃｒｉｐｔｉｏｎは、次のような情報を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、シグナリングと関連したサービスの識別子を示すことができる。ＭＰＤ＿ｉｄ属性は、ＭＰＤの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎは、ＭＰＤの変化情報を示し得るバージョン情報を示すことができる。ＭＰＤ＿ＵＲＬ属性は、ＭＰＤを取得し得るＵＲＬ情報を含むことができる。また、ＭＰＤエレメントは、ＭＰＤ情報を含むことができる。ＭＰＤＤｅｌｉｖｅｒｙＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。すなわち、Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、上記で提案した形態にしたがうことができ、その次にＭＰＤＤｅｌｉｖｅｒｙＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。

図６１は、本発明の一実施例に係る、次世代放送システムのＭＰＤデリバリーテーブルのシンタックスを示す。シグナリングメッセージヘッダーの後にはＭＰＤデリバリーテーブルの情報又はその一部が含まれてもよく、ＭＰＤデリバリーテーブルの情報は次のようなフィールドを含むことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、関連した放送サービスの識別子を示すことができる。ＭＰＤ＿ｉｄ＿ｌｅｎｇｔｈフィールドは、後続するＭＰＤ＿ｉｄ＿ｂｙｔｅｓ（）長さを示すことができる。ＭＰＤ＿ｉｄ＿ｂｙｔｅｓフィールドは、シグナリングメッセージに含まれるＭＰＤファイルの識別子を示すことができる。ＭＰＤ＿ｖｅｒｓｉｏｎフィールドは、当該ＭＰＤのデータの変化などのバージョン情報を示すことができる。ＭＰＤ＿ＵＲＬ＿ａｖａｉｌａｂｉｌｔｙフィールドは、当該シグナリングテーブル／メッセージ内にＭＰＤのＵＲＬ情報が存在するか否かを示すことができる。ＭＰＤ＿ｄａｔａ＿ａｖａｉｌａｂｉｌｔｙフィールドは、当該シグナリングテーブル／メッセージ内にＭＰＤ自体を含むか否かを示すことができる。当該値が「１」であれば、ＭＰＤ自体が当該シグナリングテーブル／メッセージに含まれることを示すことができる。ＭＰＤ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドは、後続するＭＰＤ＿ＵＲＬ＿ｂｙｔｅｓ（）長さを示すことができる。ＭＰＤ＿ＵＲＬ＿ｂｙｔｅｓフィールドは、シグナリングメッセージに含まれるＭＰＤＵＲＬを示すことができる。ＭＰＤ＿ｃｏｄｉｎｇフィールドは、当該シグナリングメッセージ内に含むＭＰＤファイルのエンコーディング方式を示すことができる。同図の下段に示すように、値によって、ＭＰＤファイルが異なる形態のエンコーディング方式でエンコーディングされたことを示すことができる。例えば、ＭＰＤ＿ｃｏｄｉｎｇフィールドの値が「０ｘ００」である場合、ＸＭＬで表現されるＭＰＤファイル自体を含んでいることを示すことができる。また、その値が「０ｘ０１」である場合、ｇｚｉｐで圧縮されたＭＰＤファイルが含まれていることを示すことができる。例えば、ｇｚｉｐで圧縮されているＭＰＤが複数のメッセージ／テーブルに分けられて伝送される場合、当該複数のＭＰＤ＿ｂｙｔｅｓ（）を連鎖（ｃｏｎｃａｔｅｎａｔｅ）した後、ｕｎｇｚｉｐすることができる。ＭＰＤ＿ｂｙｔｅ＿ｌｅｎｇｔｈフィールドは、後続するＭＰＤ＿ｂｙｔｅｓ（）長さを示すことができる。ＭＰＤ＿ｂｙｔｅｓフィールドは、ＭＰＤ＿ｃｏｄｉｎｇで明示されたエンコーディング方式によってシグナリングメッセージに含まれるＭＰＤファイルの実際データを含むことができる。次世代放送システムは、上述したフィールドを含むＭＰＤデリバリーテーブルを介して、受信機がサービスと関連したＭＰＤを受信又は取得することができるようにする。

図６２は、本発明の一実施例に係る、次世代放送システムの伝送セッションインスタンスディスクリプションを示す。アプリケーションレイヤ伝送方法がＲＯＵＴＥ（Ｒｅａｌ−ＴｉｍｅＯｂｊｅｃｔＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）である場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）セッションで構成されてもよい。一つ以上の伝送セッション（Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）に対する細部情報は、伝送セッションインスタンスディスクリプションを用いてシグナリングすることができる。伝送セッションインスタンスディスクリプタは、ＲＯＵＴＥの場合、ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）と呼ぶことができる。特に、伝送セッションインスタンスディスクリプションは、ＲＯＵＴＥセッションを構成する各ＬＣＴ伝送セッションによって何が伝達されるかを定義することができる。各伝送セッションは、伝送セッション識別子（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ，ＴＳＩ）によってユニークに識別されてもよい。伝送セッション識別子はＬＣＴヘッダーに含まれてもよい。伝送セッションインスタンスディスクリプションは、当該セッションを介して伝送される全ての伝送セッションを記述することができる。例えば、ＬＳＩＤは、ＲＯＵＴＥセッションによって運搬されるモードＬＣＴセッションを記述することができる。伝送セッションインスタンスディスクリプションは、伝送セッションと同じＲＯＵＴＥセッションで伝達されたり、又は異なるＲＯＵＴＥセッションやユニキャストを介して伝達されてもよい。

同じＲＯＵＴＥセッションで伝達される場合、伝送セッションインスタンスディスクリプションは、指定された伝送セッション識別子（ＴＳＩ）０を有する伝送セッションで伝達されてもよい。伝送セッションインスタンスディスクリプションにおいて参照される他のオブジェクトも、ＴＳＩ＝０で伝達されてもよいが、伝送セッションインスタンスディスクリプションとは異なるＴＯＩ値を有することができる。又は、ＴＳＩ≠０の分離された伝送セッションを介して伝達されてもよい。伝送セッションインスタンスディスクリプションは、バージョンナンバー、有効（ｖａｌｉｄｉｔｙ）情報又は満了（ｅｘｐｉｒａｔｉｏｎ）情報のうち少なくとも一つを用いてアップデートされてもよい。伝送セッションインスタンスディスクリプションは、図示された形態の他、ｂｉｔｓｔｒｅａｍなどと表されてもよい。

伝送セッションインスタンスディスクリプションは、ｖｅｒｓｉｏｎ属性、ｖａｌｉｄＦｒｏｍ属性、ｅｘｐｉｒａｔｉｏｎ属性を含むことができ、各伝送セッションに対してＴＳＩ属性及びＳｏｕｒｃｅＦｌｏｗ、ＲｅｐａｉｒＦｌｏｗ情報を含むことができる。ｖｅｒｓｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションのバージョン情報を示すことができ、その内容がアップデートされる度にバージョン情報は増加してもよい。最高のバージョンナンバーを有する伝送セッションインスタンスディスクリプションが最近の有効なバージョンであることを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、当該伝送セッションインスタンスディスクリプションがいつから有効であるかを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、実施例によって伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは、受信すると直ちに有効であることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションがいつ満了するかを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、実施例によって、伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは、継続して有効なものであることを示すことができる。仮に、ｅｘｐｉｒａｔｉｏｎ属性を有する伝送セッションインスタンスディスクリプションが受信されると、当該ｅｘｐｉｒａｔｉｏｎ属性に従うことができる。ＴＳＩ属性は、伝送セッション識別子を示すことができ、ＳｏｕｒｃｅＦｌｏｗエレメントは、当該ＴＳＩで伝送されるソースフローの情報を提供し、詳細内容は後述する。ＲｅｐａｉｒＦｌｏｗエレメントは、当該ＴＳＩで伝送されるリペアフローの情報を提供することができる。

図６３は、本発明の一実施例に係る次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す。ソースフローエレメントは、ＥＦＤＴエレメント、ｉｄＲｅｆ属性、ｒｅａｌｔｉｍｅ属性、ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｄｔｉｆｉｅｒエレメント、ＰａｙｌｏａｄＦｏｒｍａｔエレメントを含むことができる。ＥＦＤＴエレメントは、ファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴは、ｅｘｔｅｎｄｅｄＦｉｌｅＤｅｌｉｖｅｒｙＴａｂｌｅ（ＦＤＴ）ｉｎｓｔａｎｃｅを示すことができ、詳細な内容は後述する。ｉｄＲｅｆ属性は、ＥＦＤＴの識別子を示すことができ、対応する伝送セッションによってＵＲＩと表現されてもよい。ｒｅａｌｔｉｍｅ属性は、当該ＬＣＴパケットが拡張ヘッダー（ｅｘｔｅｎｓｉｏｎｈｅａｄｅｒ）を含むことを示すことができる。拡張ヘッダーは、デリバリーオブジェクトのプレゼンテーションタイムを示すタイムスタンプを含むことができる。ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性は、受信機に保存されるために必要なデータの最大量を定義することができる。ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｄｔｉｆｉｅｒエレメントは、当該伝送セッションによって運搬されるアプリケーションにマッピングされ得る付加情報を提供することができる。例えば、レンダリングのための伝送セッションを選択するためのＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ又はＤＡＳＨｒｅｐｒｅｓｅｎｔａｔｉｏｎのＡｄａｐｔａｔｉｏｎＳｅｔパラメータが付加情報として提供されてもよい。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ソースフローのオブジェクトを運搬するＲＯＵＴＥパケットのペイロードフォーマットを定義することができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ｃｏｄｅＰｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。ｃｏｄｅＰｏｉｎｔ属性は、当該ペイロードで用いられるコードポイントを定義することができる。これは、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は、当該デリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性は、フラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性は、オブジェクトのデリバリー順序を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性は、ｓｏｕｒｃｅＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントは、ＦＥＣパラメータを定義することができる。これは、ＦＥＣｅｎｃｏｄｉｎｇｉｄ、ｉｎｓｔａｎｃｅｉｄなどを含むことができる。

図６４は、本発明の一実施例に係る次世代放送システムのＥＦＤＴを示す。ＥＦＤＴは、ファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴは、ｉｄＲｅｆ属性、バージョン属性、ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ属性、ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ属性、ＦｉｌｅＴｅｍｐｌａｔｅエレメントを含むことができる。ｉｄＲｅｆ属性は、ＥＦＤＴの識別子を示すことができる。バージョン属性は、ＥＦＤＴインスタンスディスクリプタのバージョンを示すことができる。この属性は、ＥＦＤＴがアップデートされる度に１ずつ増加してもよい。受信されたＥＦＤＴのうち最高のバージョンナンバーを有するＥＦＤＴが現在有効なバージョンであることを示すことができる。ｍａｘＥｘｐｉｒｅｓＤｅｌｔａ属性は、オブジェクトと関連した最初パケットを送信した後、当該オブジェクトの最大有効時間（ｅｘｐｉｒｙｔｉｍｅ）を示すことができる。ｍａｘＴｒａｎｓｐｏｒｔＳｉｚｅ属性は、当該ＥＦＤＴによって記述されるオブジェクトの最大伝送サイズを示すことができる。ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ボディー部分のｆｉｌｅＵＲＬ又はｆｉｌｅテンプレートを詳細化することができる。

前述した伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）エレメントは、同図下段の伝送セッションインスタンスディスクリプタテーブル（ＬＳＩＤＴａｂｌｅ）によって伝送されてもよい。ＬＳＩＤテーブルは、前述したシグナリングメッセージによって伝達されてもよく、これは、シグナリングメッセージヘッダーとシグナリングメッセージデータ部分とに区別できる。シグナリングメッセージデータ部分は、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）又はその一部を含むことができる。シグナリングメッセージデータは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）テーブルを含むことができ、次のようなフィールドを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングテーブルであることを示す識別子情報を示すことができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングシンタックスなどのシグナリングのプロトコルバージョンを示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎフィールドは、伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）を含むシグナリングデータの変化などを示すことができる。これに加えて、伝送セッションインスタンスディスクリプタテーブルは、前述した伝送セッションインスタンスディスクリプタ（ＬＳＩＤ）エレメントの内容をさらに含むことができる。

図６５は、本発明の一実施例に係る、次世代放送システムが用いるＩＳＤＴを伝送する方法を示す。次世代放送システムは、ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔＤｅｌｉｖｅｒｙＴａｂｌｅ（ＩＳＤＴ）を伝送することによって放送サービス内のコンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔに対するシグナリング情報を伝達することができる。放送サービス内コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔに対するシグナリングメッセージは、ヘッダーとデータを含むことができる。Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、前述した形態にしたがうことができ、シグナリングメッセージデータは、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔｄｅｌｉｖｅｒｙ情報又はその一部を含むことができる。ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔｄｅｌｉｖｅｒｙ情報は、次の情報を含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔ或いはその経路情報を含むシグナリングメッセージであることを識別することができる。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、当該シグナリングメッセージのｓｙｎｔａｘなどのｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔｄｅｌｉｖｅｒｙｔａｂｌｅのプロトコルバージョンを示すことができる。Ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔｄｅｌｉｖｅｒｙｔａｂｌｅのインスタンスに対する識別子を示すことができる。Ｓｉｇｎａｌｉｎｇ＿ｖｅｒｓｉｏｎ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔｄｅｌｉｖｅｒｙｔａｂｌｅのシグナリングデータの変化などを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄ情報は、当該コンポーネントと関連したサービスを識別することができる。Ｍｐｄ＿ｉｄ情報は、当該コンポーネントと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒｉｏｄ＿ｉｄ情報は、当該コンポーネントと関連したＤＡＳＨＰｅｒｉｏｄ識別子を示すことができる。ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ｉｄ情報は、当該コンポーネントと関連したＤＡＳＨｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｖｅｒｓｉｏｎ情報は、当該ＭＰＤの変化などを示すバージョン情報であってもよい。Ｄｅｌｉｖｅｒｙ＿ｍｏｄｅ情報は、当該ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔを含んでいるか、他の経路を介して伝達されるかなどに関する情報を示すことができる。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａ（）情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔデータ自体を含むことができる。ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔｐａｔｈ情報は、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔに対するＵＲＬなどの、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔを取得し得る経路に関する情報を含むことができる。このようなＩＳＤＴを用いて、受信機は、コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔに関する情報を受信することができる。

図６６は、本発明の一実施例に係る次世代放送システムのシグナリングメッセージのデリバリー構造を示す。前述したシグナリングデータがアプリケーションレイヤ伝送、例えば、ＲＯＵＴＥをベースに伝送される場合、図示のように伝達されてもよい。すなわち、迅速なサービスのスキャンなどを支援するためにｆａｓｔｉｎｆｏｒｍａｔｉｏｎｃｈａｎｎｅｌなどを介して一部のシグナリングを伝送することができる。そして、シグナリングの一部は、特定伝送セッションを介して伝送されてもよく、またコンポーネントデータと混在して伝達されてもよい。

迅速なサービスのスキャン及び取得を支援するためのシグナリング情報は、伝送セッションと別途のチャネルで受信されてもよい。ここで、別途のチャネルとは、別途のデータパイプ（ｄａｔａｐｉｐｅ，ＤＰ）を意味できる。また、サービスに対する詳細情報は、別途の指定された伝送セッションを介して受信されてもよく、この時、当該伝送セッションはＴＳＩ＝０の値を有することができる。ここで、指定された伝送セッションを介して伝達される情報は、ＭＰＤデリバリーテーブル、アプリケーションシグナリングテーブル、伝送セッションインスタンスディスクリプションテーブル及び／又はコンポーネントマッピングテーブルを含むことができる。また、一部のシグナリング情報は、コンポーネントデータと共に伝送セッションで伝達されてもよく、例えば、ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔｄｅｌｉｖｅｒｙｔａｂｌｅがコンポーネントデータと共に伝達されてもよい。

同図の下段は、次世代放送網で放送サービスを取得する実施例を示す。受信機は、サービスが選択されると、ブロードキャストをチューニングし、速いサービススキャン及び取得のための情報を取得してパーシングすることができる。その後、速いサービススキャン及び取得のための情報から、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプション（例えば、ＴＳＩＤ、ＬＳＩＤ）の位置が決定されると、当該ディスクリプションを取得してパーシングすることができる。これと共に、受信機は、シグナリングを含む伝送セッションを確認して、このセッションからシグナリングテーブルを取得してパーシングでき、所望のコンポーネントを決定することができる。この過程を通じて所望のコンポーネントをプレゼンテーションすることができる。すなわち、放送サービスは、速いサービススキャン及び取得のための情報から伝送セッションに関する情報を取得し、伝送セッションに関する情報から所望のコンポーネントの位置を確認して当該コンポーネントを再生することによって、ユーザへの提供が可能である。

図６７は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（ＶｅｒｓｉｏｎｏｆｓｔｒｕｃｔｕｒｅｏｆＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒｏｆｏｖｅｒａｌｌｂｒｏａｄｃａｓｔｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓｄａｔａｖｅｒｓｉｏｎｏｆｔｈｉｓＦＩＣｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティションの個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、関連したサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する度に当該フィールドは、１ずつ増加してもよい。受信機はｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて当該サービスと関連したシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドは、サービスシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｔｓｉフィールドは、サービスシグナリングを伝達する伝送セッションの識別子などを示すことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。

図６８は、本発明の一実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、ＦＩＣ情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。ＦＩＣ情報は次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（ＶｅｒｓｉｏｎｏｆｓｔｒｕｃｔｕｒｅｏｆＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒｏｆｏｖｅｒａｌｌｂｒｏａｄｃａｓｔｓｔｒｅａｍ）を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのサービスの個数を示すことができる。各サービスは、複数のシグナリングテーブルを含むことができる。例えば、コンポーネントとそのセグメントに関する情報を含むＤＡＳＨＭＰＤ、ブロードバンド及び他のブロードキャストストリームに含まれたコンポーネントに対する識別子を含むＣＭＴ、アプリケーションシグナリングテーブルであるＡＳＴ、及びＭＰＤ、ＣＭＴ、ＡＳＴのうち少なくとも一つのＵＲＬを含むＵＳＴ（ＵＲＬｓｉｇｎａｌｉｎｇｔａｂｌｅ）を含むことができる。それらのシグナリングテーブルは、当該サービスのシグナリングチャネルに含まれてもよい。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。例えば、ＦＩＣ、ＭＰＤ、ＣＭＴ、ＡＳＴ又はＵＳＴに変化がある場合に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓは、ブロードキャストストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッションの個数を示すことができる。例えば、伝送セッションはＲＯＵＴＥセッションであってもよい。次の情報は、各ＲＯＵＴＥセッションに対して設定されてもよい。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスのコンポーネントシグナリングを伝送するか否かを示すことができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、当該伝送セッションを介して伝送されるデータのうち、サービスシグナリング（例えば、ＭＰＤ（ＤＡＳＨＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）、ＣＭＴなど）を含んでいることを示すことができる。ここで、ＣＭＴは、ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅであり、ブロードバンドを介して伝達されるコンポーネントの識別子を含むことができ、また他のブロードキャストストリームに含まれたコンポーネントに関する情報も含むことができる。各サービスは、サービスシグナリングチャネルを含むことができ、サービスシグナリングチャネルは、ＭＰＤ、ＣＭＴ、ＡＳＴ及び／又はＵＳＴを含むことができる。サービスシグナリングチャネルは、サービスのための複数のルートセッションのうち一つのシグナリングチャネルであってもよく、存在するか否かをｃｏｍｐｏｎｅｎｔｓｉｇｎａｌｉｎｇフラグで示すことができる。複数の伝送セッション（ＲＯＵＴＥ又はＭＭＴＰセッション）がシグナリング及びサービスのコンポーネントを伝送する場合、好ましくは、前述したサービスシグナリングテーブルは一つの伝送セッションによって伝達されてもよい。

ＲＯＵＴＥｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。

実施例によって上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。

図６９は、本発明の一実施例に係る、コンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢｒｏａｄｃａｓｔＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。

ＢＢＣｏｍｐは、ブロードバンド網を介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢＢＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。

ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＦｏｒｅｉｇｎＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性及びｄａｔａｐｉｐｅＩＤ属性は、実施例によってオプショナルな属性であってもよく、ＣＭＴに選択的に含まれてもよい。上記のＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。下段に示すように、Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、前述した形態に従うことができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。上記のような情報を用いてＣＭＴは各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。

図７０は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＢｒｏａｄｃａｓｔＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。ｔｓｉ属性は、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。

ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ，ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、ＦｏｒｅｉｇｎＣｏｍｐと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性及びｄａｔａｐｉｐｅＩＤ属性は、実施例によってオプショナルな属性であってもよく、ＣＭＴに選択的に含まれてもよい。上記のＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。下段に示すように、Ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒは、前述した形態に従うことができ、サービスメッセージ部分にｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ或いはその一部が含まれてもよい。上記のような情報を用いて、ＣＭＴは、各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。

図７１及び図７２は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルは、ＤＡＳＨ関連識別子と共に伝送パラメータエレメント（ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒｅｌｅｍｅｎｔ）及びペイロードフォーマットエレメント（ＰａｙｌｏａｄＦｏｒｍａｔｅｌｅｍｅｎｔ）を含むことができる。

コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。Ｃｏｍｐｏｎｅｎｔエレメントは、当該放送サービス内のコンポーネントを示すことができる。Ｃｏｍｐｏｎｅｎｔエレメントは、ｍｐｄＩＤ、ｐｅｒＩＤ、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ属性、ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメント及び／又はＰａｙｌｏａｄＦｏｒｍａｔエレメントのうち少なくとも一つを含むことができる。ｍｐｄＩＤ属性は、コンポーネントと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。

ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントは、当該コンポーネントが伝送される経路などに対する細部情報を含むことができる。ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントは、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ、ｔｓｉ、ｄａｔａｐｉｐｅＩＤ及び／又はＵＲＬのうち少なくとも一つを含むことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるフィジカルレイヤデータパイプの識別子を示すことができる。ＵＲＬ属性は、インターネット網などを介して当該コンポーネントデータを取得し得るＵＲＬ情報を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性、ｄａｔａｐｉｐｅＩＤ属性及び／又はＵＲＬ属性は、実施例によってオプショナルな属性であってもよく、ＤｅｌｉｖｅｒｙＰａｒａｍｅｔｅｒエレメントに選択的に含まれてもよい。

ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ｃｏｄｅＰｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。ｃｏｄｅＰｏｉｎｔ属性は、当該ペイロードで用いられるコードポイントを定義することができる。これは、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は、当該デリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性は、フラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性は、オブジェクトのデリバリー順序を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性は、ｓｏｕｒｃｅＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントは、ＦＥＣパラメータを定義することができる。これは、ＦＥＣｅｎｃｏｄｉｎｇｉｄ、ｉｎｓｔａｎｃｅｉｄなどを含むことができる。

図７３は、本発明の一実施例に係るコンポーネントマッピングテーブルディスクリプションを示す。コンポーネントマッピングテーブルディスクリプション（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅＤｅｓｃｒｉｐｔｉｏｎ）は、次世代放送システムで放送サービスに含まれたコンポーネントの伝送経路に関する情報をシグナリングすることができる。これは、ＸＭＬフォーマット又はｂｉｎａｒｙ形態のｂｉｔｓｔｒｅａｍなどと表現されてもよい。コンポーネントマッピングテーブルディスクリプションは、ｓｅｒｖｉｃｅ＿ｉｄ属性、ｍｐｄ＿ｉｄ属性、ｐｅｒ＿ｉｄ属性、ＢｒｏａｄｃａｓｔＣｏｍｐエレメント、ＢＢＣｏｍｐエレメント及びＦｏｒｅｉｇｎＣｏｍｐエレメントを含むことができる。コンポーネントマッピングテーブルディスクリプションは、次のようなエレメント及び属性を含むことができる。ｓｅｒｖｉｃｅ＿ｉｄ属性は、コンポーネントと関連したサービスの識別子を示すことができる。ＣＭＴディスクリプションは、ｓｅｒｖｉｃｅ＿ｉｄ属性と同じレベルにｍｐｄＩＤ属性及びｐｅｒＩＤ属性を含むことができる。すなわち、ＢｒｏａｄｃａｓｔＣｏｍｐエレメント、ＢＢＣｏｍｐエレメント及びＦｏｒｅｉｇｎＣｏｍｐエレメントに共通的に適用されるｍｐｄＩＤ属性及びｐｅｒＩＤ属性を重複して記述せず、ｓｅｒｖｉｃｅ＿ｉｄ属性と同じレベルで記述することができる。ｍｐｄＩＤ属性は、当該サービスと関連したＤＡＳＨＭＰＤ識別子を示すことができる。ｐｅｒＩＤ属性は、当該ＭＰＤ内の関連したｐｅｒｉｏｄ識別子を示すことができる。

ＢｒｏａｄｃａｓｔＣｏｍｐは、同じ放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＢｒｏａｄｃａｓｔＣｏｍｐは、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。ｔｓｉ属性は、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。

ＢＢＣｏｍｐエレメントは、ブロードバンド網を介して伝送される一つ以上のコンポーネントを示すことができる。ＢＢＣｏｍｐは、ｒｅｐｔｎＩＤ及び／又はｂａｓｅＵＲＬのうち少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。

ＦｏｒｅｉｇｎＣｏｍｐは、他の放送ストリームを介して伝送される一つ以上のコンポーネントを示すことができる。ＦｏｒｅｉｇｎＣｏｍｐは、ｒｅｐｔｎＩＤ、ｂａｓｅＵＲＬ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ、ｓｏｕｒｃｅＩＰＡｄｄｒ、ｄｅｓｔＩＰＡｄｄｒ、ｄｅｓｔＵＤＰＰｏｒｔ、ｔｓｉ及び／又はｄａｔａｐｉｐｅＩＤのうち少なくとも一つを含むことができる。ｒｅｐｔｎＩＤ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎ識別子を示すことができる。ｂａｓｅＵＲＬ属性は、当該コンポーネントと関連したＤＡＳＨＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成するセグメントのＢａｓｅＵＲＬを示すことができる。ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤ属性は、当該コンポーネントデータを含む放送ストリームの識別子を示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｓｏｕｒｃｅＩＰアドレスを示すことができる。ｄｅｓｔＩＰＡｄｄｒ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＩＰアドレスを示すことができる。ｄｅｓｔＵＤＰＰｏｒｔ属性は、当該コンポーネントデータを含むＩＰデータグラムｄｅｓｔｉｎａｔｉｏｎＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ｔｓｉ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションの識別子を示すことができる。ｄａｔａｐｉｐｅＩＤ属性は、当該放送ストリーム内で当該コンポーネントデータが伝送されるデータパイプの識別子を示すことができる。上述したｓｏｕｒｃｅＩＰＡｄｄｒ属性、ｄｅｓｔＩＰＡｄｄｒ属性、ｄｅｓｔＵＤＰＰｏｒｔ属性、ｔｓｉ属性及びｄａｔａｐｉｐｅＩＤ属性は、実施例によってオプショナルな属性であってもよく、ＣＭＴに選択的に含まれてもよい。上記のＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎは、一つのＸＭＬファイル或いは上記で提案したシグナリングメッセージフォーマットでエンカプセレーションされて伝送されてもよい。上記のような情報を用いて、ＣＭＴは、各サービスに関連したコンポーネントを定義し、当該コンポーネントに関連した情報を受信し得る位置又は経路を受信機に知らせることができる。

図７４は、本発明の一実施例に係るＭＰＤの共通属性及びエレメントを示す図である。次世代放送システムは、ＤＡＳＨベースハイブリッド放送サービスを提供することができる。次世代放送システムは、ＤＡＳＨＭＰＤ内のＲｅｐｒｅｓｅｎｔａｔｉｏｎなどと関連したセグメントが互いに異なるｄｉｓｔｒｉｂｕｔｉｏｎ経路を介して伝達されることを示すことができる。ＭＰＤの共通属性及びエレメント（Ｃｏｍｍｏｎａｔｔｒｉｂｕｔｅｓａｎｄｅｌｅｍｅｎｔｓ）は、ａｄａｐｔａｔｉｏｎｓｅｔ、ｒｅｐｒｅｓｅｎｔａｔｉｏｎ及びｓｕｂ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎエレメントに共通に存在してもよく、図示しているように、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置情報を含むことができる。次世代放送システムは、ＭＰＤの共通属性及びエレメントに含まれた関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置情報を用いて、ＤＡＳＨｃｌｉｅｎｔに、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎ又はセグメントの位置を知らせることができる。ＭＰＤの共通属性及びエレメントは、次のような属性及びエレメントを含むことができる。＠ｐｒｏｆｉｌｅｓ属性は、プロファイル属性であり、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎのプロファイルを示すことができる。＠ｗｉｄｔｈ属性は、ディスプレイされるビデオメディアタイプの水平表示サイズ（ｈｏｒｉｚｏｎｔａｌｖｉｓｕａｌｐｒｅｓｅｎｔａｔｉｏｎｓｉｚｅ）を示すことができる。＠ｈｅｉｇｈｔ属性は、ディスプレイされるビデオメディアタイプの垂直表示サイズ（ｖｅｒｔｉｃａｌｖｉｓｕａｌｐｒｅｓｅｎｔａｔｉｏｎｓｉｚｅ）を示すことができる。＠ｓａｒ属性は、ビデオメディアコンポーネントタイプのｓａｍｐｌｅａｓｐｅｃｔｒａｔｉｏを示すことができる。＠ｆｒａｍｅＲａｔｅ属性は、ｒｅｐｒｅｓｅｎｔａｔｉｏｎの出力フレームレートを示すことができる。＠ａｕｄｉｏＳａｍｐｌｉｎｇＲａｔｅ属性は、オーディオメディアコンポーネントタイプのサンプリングレートを示すことができる。＠ｍｉｍｅＴｙｐｅ属性は、初期化セグメントの連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）のＭＩＭＥタイプを示すことができる。＠ｓｅｇｍｅｎｔＰｒｏｆｉｌｅｓ属性は、当該ｒｅｐｒｅｓｅｎｔａｔｉｏｎをプロセスするための必須なセグメントのプロファイルを示すことができる。＠ｃｏｄｅｃｓ属性は、当該ｒｅｐｒｅｓｅｎｔａｔｉｏｎ内で用いられるコーデックを示すことができる。＠ｍａｘｉｍｕｍＳＡＰＰｅｒｉｏｄ属性は、含まれたメディアストリームの最大ＳＡＰ（ｓｔｒｅａｍａｃｃｅｓｓｐｏｉｎｔ）インターバルを示すことができる。＠ｓｔａｒｔＷｉｔｈＳＡＰ属性は、ＳＡＰと共に開始する各メディアセグメントの数を示すことができる。＠ｍａｘＰｌａｙｏｕｔＲａｔｅ属性は、最大プレイアウトレートを示すことができる。＠ｃｏｄｉｎｇＤｅｐｅｎｄｅｎｃｙ属性は、デコーディングのために一つ又はそれ以上の他のアクセスユニットに依存する少なくとも一つのアクセスユニットが存在するか否かを示すことができる。＠ｓｃａｎＴｙｐｅ属性は、ビデオメディアコンポーネントタイプのｓｏｕｒｃｅｍａｔｅｒｉａｌのスキャンタイプを示すことができる。ＦｒａｍｅＰａｃｋｉｎｇエレメントは、ビデオメディアコンポーネントタイプのフレーム−パッキング情報を示すことができる。ＡｕｄｉｏＣｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎエレメントは、オーディオメディアコンポーネントタイプのオーディオチャネル設定を示すことができる。ＣｏｎｔｅｎｔＰｒｏｔｅｃｔｉｏｎエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎに対して用いられたコンテンツ保護スキームに関する情報を示すことができる。ＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙエレメントは、プロセシングに必ず考慮されるエレメントに関する情報を示すことができる。ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙエレメントは、プロセシングを最適化するために用いられる付加情報を含むことができる。ＩｎｂａｎｄＥｖｅｎｔＳｔｒｅａｍエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎにインバンドイベントストリームが存在するか否かを示すことができる。Ｌｏｃａｔｉｏｎエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを取得し得る位置情報を含むことができる。Ｌｏｃａｔｉｏｎエレメントは、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを運搬するブロードキャストストリーム又は物理チャネルデータパイプ（ｐｈｙｓｉｃａｌｌａｙｅｒｄａｔａｐｉｐｅｓ）に関する情報を含むことができる。ＤＡＳＨｃｌｉｅｎｔ又は次世代放送受信装置は、Ｌｏｃａｔｉｏｎエレメントを用いて、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを取得することができる。すなわち、次世代放送システム受信装置は、前述したＣＭＴを用いなくとも、ＭＰＤのＣｏｍｍｏｎａｔｔｒｉｂｕｔｅｓａｎｄｅｌｅｍｅｎｔｓに含まれた位置情報を用いて関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎの位置に関する情報を取得し、それに基づいて、関連したｒｅｐｒｅｓｅｎｔａｔｉｏｎを取得することができる。上述したｒｅｐｒｅｓｅｎｔａｔｉｏｎは、実施例によってコンポーネントとして説明されてもよい。

また、他の実施例で、次世代放送システムは、関連したＲｅｐｒｅｓｅｎｔａｔｉｏｎなどの伝送経路に関する情報を、ＤＡＳＨＭＰＤ内のＢａｓｅＵＲＬｅｌｅｍｅｎｔの＠ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ属性に割り当てることができる。次世代放送システムは、＠ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ属性を用いてＤＡＳＨｃｌｉｅｎｔに、当該ｒｅｐｒｅｓｅｎｔａｔｉｏｎと関連したセグメントが伝達される経路に関する情報を知らせることができる。

図７５は、本発明の一実施例に係る伝送セッションインスタンスディスクリプションを示す図である。アプリケーションレイヤ伝送方法がＲＯＵＴＥである場合、ＲＯＵＴＥセッションが一つ以上のＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）セッションで構成されてもよい。一つ以上の伝送セッション（Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）に対する細部情報は、伝送セッションインスタンスディスクリプションを用いてシグナリングすることができる。伝送セッションインスタンスディスクリプタは、ＲＯＵＴＥの場合、ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）と呼ぶこともできる。特に、伝送セッションインスタンスディスクリプションは、ＲＯＵＴＥセッションを構成する各ＬＣＴ伝送セッションによって何が伝達されるかを定義することができる。各伝送セッションは、伝送セッション識別子（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ，ＴＳＩ）によってユニークに識別されてもよい。伝送セッション識別子はＬＣＴヘッダーに含まれてもよい。伝送セッションインスタンスディスクリプションは、当該セッションを介して伝送される全ての伝送セッションを記述することができる。例えば、ＬＳＩＤは、ＲＯＵＴＥセッションによって運搬されるモードＬＣＴセッションを記述することができる。伝送セッションインスタンスディスクリプションは、伝送セッションと同じＲＯＵＴＥセッションで伝達されたり、又は互いに異なるＲＯＵＴＥセッション又はユニキャストで伝達されてもよい。

同じＲＯＵＴＥセッションで伝達される場合、伝送セッションインスタンスディスクリプションは、指定された伝送セッション識別子（ＴＳＩ）０を有する伝送セッションで伝達されてもよい。伝送セッションインスタンスディスクリプションで参照される他のオブジェクトもＴＳＩ＝０で伝達されてもよいが、伝送セッションインスタンスディスクリプションとは異なるＴＯＩ値を有することができる。又は、ＴＳＩ≠０の分離された伝送セッションで伝達されてもよい。伝送セッションインスタンスディスクリプションは、バージョンナンバー、有効（ｖａｌｉｄｉｔｙ）情報又は満了（ｅｘｐｉｒａｔｉｏｎ）情報のうち少なくとも一つを用いてアップデートされてもよい。伝送セッションインスタンスディスクリプションは、図示された形態以外にｂｉｔｓｔｒｅａｍなどと表現されてもよい。

伝送セッションインスタンスディスクリプションは、ｖｅｒｓｉｏｎ属性、ｖａｌｉｄＦｒｏｍ属性、ｅｘｐｉｒａｔｉｏｎ属性を含むことができ、各伝送セッションに対してＴＳＩ属性、ＳｏｕｒｃｅＦｌｏｗエレメント、ＲｅｐａｉｒＦｌｏｗエレメント、ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメントを含むことができる。ｖｅｒｓｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションのバージョン情報を示すことができ、その内容がアップデートされる度にバージョン情報は増加してもよい。最高のバージョンナンバーを有する伝送セッションインスタンスディスクリプションが最近の有効なバージョンであることを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、当該伝送セッションインスタンスディスクリプションがいつから有効であるかを示すことができる。ｖａｌｉｄＦｒｏｍ属性は、実施例によって伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは受信されると直ちに有効であることを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、当該伝送セッションインスタンスディスクリプションがいつ満了するかを示すことができる。ｅｘｐｉｒａｔｉｏｎ属性は、実施例によって伝送セッションインスタンスディスクリプションに含まれなくてもよく、この場合、当該伝送セッションインスタンスディスクリプションは継続して有効なものであることを示すことができる。仮に、ｅｘｐｉｒａｔｉｏｎ属性を有する伝送セッションインスタンスディスクリプションが受信されると、当該ｅｘｐｉｒａｔｉｏｎ属性に従うことができる。ＴＳＩ属性は、伝送セッション識別子を示すことができ、ＳｏｕｒｃｅＦｌｏｗエレメントは、当該ＴＳＩで伝送されるソースフローの情報を提供し、詳細内容は後述する。ＲｅｐａｉｒＦｌｏｗエレメントは、当該ＴＳＩで伝送されるリペアフローの情報を提供することができる。ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメントは、当該伝送セッションに対する付加的な属性情報を含むことができる。伝送セッションインスタンスディスクリプションは、ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＰｒｏｐｅｒｔｙエレメント内に伝送セッションに対する付加的な属性情報を含むことができ、例えば、付加情報は、伝送セッションに対するサービスシグナリング情報を含むことができる。

図７６は、本発明の一実施例に係る、次世代放送システムのソースフロー（ＳｏｕｒｃｅＦｌｏｗ）エレメントを示す。ソースフローエレメントは、ＥＦＤＴエレメント、ｉｄＲｅｆ属性、ｒｅａｌｔｉｍｅ属性、ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｄｔｉｆｉｅｒエレメント、ＰａｙｌｏａｄＦｏｒｍａｔエレメント及び／又はＳｏｕｒｃｅＦｌｏｗＰｒｏｐｅｒｔｙエレメントを含むことができる。ＥＦＤＴエレメントは、ファイルデリバリーデータの詳細情報を含むことができる。ＥＦＤＴは、ｅｘｔｅｎｄｅｄＦｉｌｅＤｅｌｉｖｅｒｙＴａｂｌｅ（ＦＤＴ）ｉｎｓｔａｎｃｅを示すことができ、詳細な内容は後述する。ｉｄＲｅｆ属性は、ＥＦＤＴの識別子を示すことができ、対応する伝送セッションによってＵＲＩと表現されてもよい。ｒｅａｌｔｉｍｅ属性は、当該ＬＣＴパケットが拡張ヘッダー（ｅｘｔｅｎｓｉｏｎｈｅａｄｅｒ）を含むことを示すことができる。拡張ヘッダーは、デリバリーオブジェクトのプレゼンテーションタイムを示すタイムスタンプを含むことができる。ｍｉｎＢｕｆｆｅｒＳｉｚｅ属性は、受信機に保存されるために必要なデータの最大量を定義することができる。ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｄｔｉｆｉｅｒエレメントは、当該伝送セッションによって運搬されるアプリケーションにマッピングされ得る付加情報を提供することができる。例えば、レンダリングのための伝送セッションを選択するためのＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ又はＤＡＳＨｒｅｐｒｅｓｅｎｔａｔｉｏｎのＡｄａｐｔａｔｉｏｎＳｅｔパラメータが付加情報として提供されてもよい。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ソースフローのオブジェクトを運搬するＲＯＵＴＥパケットのペイロードフォーマットを定義することができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、ｃｏｄｅＰｏｉｎｔ属性、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性、ｆｒａｇｍｅｎｔａｔｉｏｎ属性、ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性、ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性及び／又はＦＥＣＰａｒａｍｅｔｅｒｓエレメントを含むことができる。ｃｏｄｅＰｏｉｎｔ属性は、当該ペイロードで用いられるコードポイントを定義することができる。これは、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ属性は、当該デリバリーオブジェクトのペイロードフォーマットを示すことができる。ｆｒａｇｍｅｎｔａｔｉｏｎ属性は、フラグメンテーションのタイプを定義することができる。ｄｅｌｉｖｅｒｙＯｒｄｅｒ属性は、オブジェクトのデリバリー順序を示すことができる。ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ属性は、ｓｏｕｒｃｅＦＥＣペイロード識別子のフォーマットを定義することができる。ＦＥＣＰａｒａｍｅｔｅｒｓエレメントは、ＦＥＣパラメータを定義することができる。これは、ＦＥＣｅｎｃｏｄｉｎｇｉｄ、ｉｎｓｔａｎｃｅｉｄなどを含むことができる。ＳｏｕｒｃｅＦｌｏｗＰｒｏｐｅｒｔｙエレメントは、当該ソースフローに対する属性情報を提供することができる。例えば、属性情報は、当該ソースフローデータを運搬するブロードキャストの位置情報を含むことができる。ここで、ブロードキャストの位置情報はブロードキャストストリーム内のデータパイプ又は（ＰＬＰｐｈｙｓｉｃａｌｌａｙｅｒｐｉｐｅ）に関する情報を含むことができる。

図７７は、本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。図示のサービス取得情報は、前述したサービス取得情報にリンクレイヤシグナリングに関する情報をさらに含むことができる。リンクレイヤシグナリングに関する情報は、リンクレイヤシグナリングが存在するか否かを示すフラグ情報、リンクレイヤシグナリングデータのバージョン情報、及びリンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。図示のように、システム取得情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなど他のフォーマットで表現されてもよい。

システム取得情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（ＶｅｒｓｉｏｎｏｆｓｔｒｕｃｔｕｒｅｏｆＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒｏｆｏｖｅｒａｌｌｂｒｏａｄｃａｓｔｓｔｒｅａｍ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、当該ＦＩＣ情報のデータバージョン（ｉｎｄｉｃａｔｅｓｄａｔａｖｅｒｓｉｏｎｏｆｔｈｉｓＦＩＣｉｎｓｔａｎｃｅ）を示すことができる。ＦＩＣ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣの内容に変更がある場合に増加してもよい。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのコンポーネントの個数を示すことができる。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いてＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒを含むか否かを示すことができる。当該フィールド値が１である場合、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒが存在することを示すことができる。ｎｕｍ＿ｔｒａｎｓｐｏｒｔ＿ｓｅｓｓｉｏｎフィールドは、放送ストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッション（例えば、ＲＯＵＴＥ又はＭＭＴＰｓｅｓｓｉｏｎ）の個数を示すことができる。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、前述したｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ値が１である場合、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスシグナリングを伝送するか否かを示すことができる。ｓｅｒｖｉｃｅ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、サービスシグナリングを含むＤＰが存在することを示すことができる。ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、関連したサービスシグナリングデータの変化を示すことができる。サービスシグナリングデータに変化が発生する度に当該フィールドは、１ずつ増加してもよい。受信機は、ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて当該サービスと関連したシグナリングの変化を感知することができる。ｓｉｇｎａｌｉｎｇ＿ＤＰフィールドは、サービスシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ｓｉｇｎａｌｉｎｇ＿ｔｓｉフィールドは、サービスシグナリングを伝達する伝送セッションの識別子などを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇは、サービス取得情報がリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングを伝送するか否かを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎは、関連したリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングデータの変化を示すことができる。当該フィールドは、リンクレイヤシグナリングデータに変化が発生する度に１ずつ増加してもよい。これを用いて受信機はリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングの変化を感知することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｉｄは、Ｌ２レイヤで利用可能なリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。各ディスクリプタは拡張が可能であり、各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドを含むことができる。各ディスクリプタは、ｎｕｍ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが示す値に対応する個数のｄｅｓｃｒｉｐｔｏｒｌｏｏｐを含むことができる。Ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、伝送セッションレベルのディスクリプタを含むことができる。ｓｅｒｖｉｃｅｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｓｅｒｖｉｃｅレベルのディスクリプタを含むことができる。Ｐａｒｔｉｔｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、パーティションレベルのディスクリプタを含むことができ、一つのパーティションは、一つの放送会社などによって用いられる放送ストリームの一部を表すことができる。ＦＩＣｓｅｓｓｉｏｎｄｅｓｃｒｉｐｔｏｒｓフィールドは、ＦＩＣレベルのディスクリプタを含むことができる。実施例によって、上述したＦＩＣに含まれた各フィールドは、ＦＩＣ外の他のテーブルに含まれて放送信号と共に伝送されてもよい。

図７８は、本発明の他の実施例に係る、次世代放送システムが受信機の迅速な放送サービススキャンのために伝送するシグナリングデータを示す。迅速な放送サービススキャン及びサービス／コンポーネント取得を支援するためのＦＩＣ情報（サービス取得情報）は、サービス及びコンポーネントデータを伝達するアプリケーションレイヤ伝送セッションに関する情報を含むことができる。また、サービス取得情報は、リンクレイヤシグナリングに関する情報をさらに含むことができる。図示のように、サービス取得情報は、バイナリフォーマットで表現されてもよいが、実施例によってＸＭＬなどの他のフォーマットで表現されてもよい。

サービス取得情報は、次のようなフィールドを含むことができる。ＦＩＣ＿ｐｏｒｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、シグナリング情報のプロトコルバージョン（ＶｅｒｓｉｏｎｏｆｓｔｒｕｃｔｕｒｅｏｆＦＩＣ）を示すことができる。ＴＳＩＤフィールドは、放送ストリームの識別子（Ｉｄｅｎｔｉｆｉｅｒｏｆｏｖｅｒａｌｌｂｒｏａｄｃａｓｔｓｔｒｅａｍ）を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ブロードキャストストリームのパーティション個数を示すことができる。ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドが用いられるべく、各ブロードキャストストリームは一つ又はそれ以上のパーティションに分けられて伝送され得ることを仮定する。各パーティションは、一つのブロードキャスターによる複数のＤＰを含むことができる。各パーティションは、一つのブロードキャスターによって用いられたブロードキャストストリームの部分を表すことができる。ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、当該パーティションの識別子を示すことができる。ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、上述したパーティション構造のバージョンを示すことができる。ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは、当該パーティションに属する少なくとも一つのサービスの個数を示すことができる。各サービスは、複数のシグナリングテーブルを含むことができる。例えば、コンポーネントとそのセグメントに関する情報を含むＤＡＳＨＭＰＤ、ブロードバンド及び他のブロードキャストストリームに含まれたコンポーネントに対する識別子を含むＣＭＴ、アプリケーションシグナリングテーブルであるＡＳＴ及びＭＰＤ、ＣＭＴ、ＡＳＴのうち少なくとも一つのＵＲＬを含むＵＳＴ（ＵＲＬｓｉｇｎａｌｉｎｇｔａｂｌｅ）を含むことができる。これらのシグナリングテーブルは、当該サービスのシグナリングチャネルに含まれてもよい。ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスに対する識別子を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣ内のｓｅｒｖｉｃｅｌｏｏｐデータの変化或いは当該サービスと関連したサービスシグナリングデータの変化を示すことができる。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、含まれたサービスデータに変化が発生する度に１ずつ増加してもよい。例えば、ＦＩＣ、ＭＰＤ、ＣＭＴ、ＡＳＴ又はＵＳＴに変化がある場合に１ずつ増加してもよい。受信機は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドを用いて、ＦＩＣのサービスループのデータ変化或いは当該サービスと関連したシグナリングの変化を感知することができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、当該サービスと関連したチャネルナンバーを示すことができる。ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、当該サービスのカテゴリーを示すことができ、例えば、Ａ／Ｖ、ａｕｄｉｏ、ＥＳＧ、ＣｏＤなどを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドは、当該サービスを表す名前に対する長さを示すことができる。ｓｅｒｖｉｃｅ＿ｓｈｏｒｔ＿ｎａｍｅフィールドは、当該サービスを表す名前を示すことができる。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、当該サービスの状態を示すことができ、その値によってａｃｔｉｖｅ又はｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ又はｓｈｏｗｎ属性を示すことができる。ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、ＡＴＳＣＭ／Ｈ文書の「ｍｕｌｔｉ−ｅｎｓｅｍｂｌｅ」フラグと類似な属性を有することができる。例えば、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。ｓｐ＿ｉｎｄｉｃａｔｏｒフィールドは、サービス保護フラグ（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎｆｌａｇ）であり、プレゼンテーションのために必要な一つ又はそれ以上のコンポーネントが保護されるか否かを示すことができる。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰアドレス形式を示すことができる。当該フィールド値が０である場合にＩＰｖ４形式を、１である場合にＩＰｖ６アドレス形式を用いることを示すことができる。ｎｕｍ＿ＲＯＵＴＥ＿ｓｅｓｓｉｏｎｓは、ブロードキャストストリーム内で当該サービスのコンポーネントデータを伝送する伝送セッションの個数を示すことができる。例えば、伝送セッションは、ＲＯＵＴＥセッションであってもよい。次の情報は、各ＲＯＵＴＥセッションに対して設定されてもよい。ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＩＰ＿ａｄｄｒフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。ｄｅｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該サービスのコンポーネントデータを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。ＬＳＩＤ＿ＤＰフィールドは、伝送セッションに対する細部情報を含むシグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。ここで、伝送セッションに対する細部情報を含むシグナリングは、例えば、ＲＯＵＴＥの場合、各ＲＯＵＴＥセッションの細部ＬＣＴ伝送セッションに関する情報を含むＬＣＴｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎなどであってもよい。ＬＳＩＤ＿ｔｓｉフィールドは、伝送セッションに対する細部情報を含むシグナリングである伝送セッションインスタンスディスクリプションが伝送される伝送セッションの識別子を示すことができる。ここで、セッションインスタンスディスクリプションは、ＬＣＴ伝送セッションの場合、ＬＳＩＤであってもよい。また、伝送セッションインスタンスディスクリプションが伝送される伝送セッションを介して当該サービスと関連したサービスシグナリングが伝達されてもよい。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇフィールドは、伝送セッションがサービスのコンポーネントシグナリングを伝送するか否かを示すことができる。ｃｏｍｐｏｎｅｎｔ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇ値が１である場合、当該伝送セッションを介して伝送されるデータのうちサービスシグナリング（例えば、ＭＰＤ（ＤＡＳＨＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）、ＣＭＴなど）を含んでいることを示すことができる。ここで、ＣＭＴは、ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅであり、ブロードバンドを介して伝達されるコンポーネントの識別子を含むことができ、また、他のブロードキャストストリームに含まれたコンポーネントに関する情報も含むことができる。各サービスは、サービスシグナリングチャネルを含むことができ、サービスシグナリングチャネルは、ＭＰＤ、ＣＭＴ、ＡＳＴ及び／又はＵＳＴを含むことができる。サービスシグナリングチャネルは、サービスのための複数のルートセッションのうち一つのシグナリングチャネルであってもよく、存在するか否かをコンポーネントシグナリングフラグで示すことができる。複数の伝送セッション（ＲＯＵＴＥ又はＭＭＴＰセッション）がシグナリング及びサービスのコンポーネントを伝送する場合、好ましくは、前述したサービスシグナリングテーブルは、一つの伝送セッションによって伝達することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｆｌａｇは、サービス取得情報がリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングを伝送するか否かを示すことができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｄａｔａ＿ｖｅｒｓｉｏｎは、関連したリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングデータの変化を示すことができる。当該フィールドは、リンクレイヤシグナリングデータに変化が発生する度に１ずつ増加してもよい。これを用いて受信機はリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングの変化を感知することができる。ｌｉｎｋ＿ｌａｙｅｒ＿ｓｉｇｎａｌｉｎｇ＿ｉｄは、Ｌ２レイヤで利用可能なリンクレイヤ（或いは、ｌｏｗｌａｙｅｒ）シグナリングを伝達するフィジカルレイヤのデータパイプ識別子を示すことができる。

実施例によって、上述したサービス取得情報に含まれた各フィールドは、サービス取得情報以外の情報と共に放送信号に含まれて伝送されてもよい。

図７９は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す。上段の図面は、本発明の次世代放送システムで用いるサービスレイヤシグナリングのフォーマットであり、サービスレイヤシグナリングは、図示しているような形態でエンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。次世代放送システムにおいて上記で提案したサービスシグナリングを用いる場合、下段の図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを用いて伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができる。言い換えると、当該フィールドは、物理層フレーム（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）が速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングしなければならないか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むことができる。

また、図示のように、伝送セッションインスタンスディスクリプタは、前述したエンカプセレーション形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、伝送セッションインスタンスディスクリプタを含むことができる。本発明で伝送セッションインスタンスディスクリプタはサービスレイヤシグナリングの一つとして含まれて伝達されてもよい。

図８０は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す。次世代放送システムで上記で提案したサービスレイヤシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを介して伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

また、図示のように、伝送セッションインスタンスディスクリプタは、前述したエンカプセレーション形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは伝送セッションインスタンスディスクリプタを含むことができる。本発明で伝送セッションインスタンスディスクリプタはサービスレイヤシグナリングの一つに含まれて伝達されてもよい。

また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージはリンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋＬａｙｅｒｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗｌａｙｅｒｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。

図８１は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを取得する方法を示す。次世代放送システムでサービス／コンポーネントシグナリングのために３ＧＰＰｅＭＢＭＳシグナリングなどを用いる場合、図示のように伝達されてもよい。ここで、サービスレイヤシグナリングは、ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌを含むことができ、伝送セッションインスタンスディスクリプションをさらに含むことができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを介して伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌを含むことができる。

また、図示のように、伝送セッションインスタンスディスクリプタは、前述したエンカプセレーション形態を有することができる。すなわち、伝送セッションインスタンスディスクリプタのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、伝送セッションインスタンスディスクリプタを含むことができる。本発明で伝送セッションインスタンスディスクリプタはサービスレイヤシグナリングの一つに含まれて伝達されてもよい。

図８２は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを取得する方法を示す。次世代放送システムで３ＧＰＰｅＭＢＭＳシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によってＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌを含むことができる。

また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージはリンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋＬａｙｅｒｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗｌａｙｅｒｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。すなわち、次世代放送システムは、物理層フレームにリンクレイヤシグナリングが含まれたデータパイプ又はＰＬＰに対するシグナリング情報を含むことができる。

図８３は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す。上段図面は、本発明の次世代放送システムで用いるサービスレイヤシグナリングのフォーマットであり、サービスレイヤシグナリングは図示のような形態でエンカプセレーションされてもよい。例えば、エンカプセレーションされたサービスレイヤシグナリングは、左上段に示すように、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、右上段に示すように、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘはｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。

次世代放送システムで上記で提案したサービスシグナリングを用いる場合、下段図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むことができる。前述したように、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘはｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄはサービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ１の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ２の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ３の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇｉｄ０ｘＦ１を有するサービスレイヤシグナリングを受信することができる。また、この時、バージョン情報を確認し、既に受信しているＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムはサービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。

図８４は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。本発明の次世代放送システムで用いるサービスレイヤシグナリングは、エンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。

次世代放送システムで上記で提案したサービスシグナリングを用いる場合、図示のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むことができる。前述したように、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ１の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ２の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ３の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇｉｄ０ｘＦ１を有するサービスレイヤシグナリングを受信することができる。また、この時、バージョン情報を確認し、既に受信しているＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムは、サービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。

また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、リンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋＬａｙｅｒｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗｌａｙｅｒｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。すなわち、次世代放送システムは、物理層フレームに、リンクレイヤシグナリングが含まれたデータパイプ又はＰＬＰに対するシグナリング情報を含むことができる。

図８５は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す。本発明の次世代放送システムで用いるサービスレイヤシグナリングは、エンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。

次世代放送システムで３ＧＰＰｅＭＢＭＳシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムで上記で提案したサービスシグナリングを用いる場合、下段の図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを介して伝送することができる。放送信号フレームは、物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びシグナリングメッセージを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によってＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌを含むことができる。前述したように、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ４の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ５の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌの内容に変更がある場合、変更されてもよい。また、ＭＰＤを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ６の値を有することができる。また、そのバージョン情報は０ｘ０２の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇｉｄ０ｘＦ４を有するサービスレイヤシグナリングを受信することができる。また、この時、バージョン情報を確認し、既に受信しているＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムは、サービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。

図８６は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリング及びリンクレイヤシグナリングを伝送する方法を示す図である。本発明の次世代放送システムで用いるサービスレイヤシグナリングは、エンカプセレーションすることができる。例えば、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することができる。又は、エンカプセレーションされたサービスレイヤシグナリングは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ組合せで構成することもできる。また、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。

次世代放送システムで３ＧＰＰｅＭＢＭＳシグナリングを用いる場合、図面のように伝達することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅを介して伝送することができる。放送信号フレームは物理層シグナリング（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｉｎｇ）を含むことができる。物理層シグナリングの情報は、速いサービス取得情報に対するフィールドを含むことができる。当該フィールドは、速いサービス取得情報のバージョン情報を含むことができ、言い換えると、当該フィールドは、物理層フレームが速いサービス取得情報を含むか否か、又は速いサービス取得情報をパーシングすべきか否かを示すことができる。受信機は、物理層シグナリングの当該フィールドを用いて速いサービス取得情報を取得することができる。次世代放送システムの放送信号は、ｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内に速いサービス取得情報を含むことができる。速いサービス取得情報は、サービス識別子を含むことができ、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、サービスレイヤシグナリング又は伝送セッションインスタンスディスクリプタのうち少なくとも一つが伝達されるＰＬＰを識別し、そこに含まれたサービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタを取得することができる。図示のように、サービスレイヤシグナリング情報又は伝送セッションインスタンスディスクリプタは、当該ＰＬＰ内の０番目の伝送セッションによって伝達することができる。すなわち、サービスレイヤシグナリングは、サービス取得情報に含まれたＰＬＰ識別子が示すＰＬＰ内のｔｓｉ＝０に該当する伝送セッションによって伝達されてもよい。言い換えると、サービスレイヤシグナリングが伝達される伝送セッションは、その識別子が０に固定されてもよい。

図示のように、サービスレイヤシグナリングは、前述したエンカプセレーション形態を有することができる。すなわち、サービスレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅを含むことができる。ここで、シグナリングメッセージは、サービスレイヤシグナリングが伝達するメッセージの種類によって、ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎ（ＵＳＢＤ）、ＭＰＤ、ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌを含むことができる。前述したようにＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘはｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。例えば、ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ４の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎの内容に変更がある場合、変更されてもよい。また、ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ５の値を有することができる。また、そのバージョン情報は０ｘ０１の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌの内容に変更がある場合、変更されてもよい。また、ＭＰＤを含むサービスレイヤシグナリングは、ｓｉｇｎａｌｉｎｇｉｄとして０ｘＦ６の値を有することができる。また、そのバージョン情報は０ｘ０２の値を有することができ、バージョン情報は、当該サービスレイヤシグナリングのシグナリングメッセージであるＭＰＤの内容に変更がある場合、変更されてもよい。これによって、受信機は、サービスレイヤシグナリングのａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌｈｅａｄｅｒに含まれたフィルタリング情報であるｓｉｇｎａｌｉｎｇｉｄ及びｖｅｒｓｉｏｎ情報を用いて、所望のサービスレイヤシグナリングをフィルタリングすることができる。例えば、ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎを受信しようとする場合、ｓｉｇｎａｌｉｎｇｉｄ０ｘＦ４を有するサービスレイヤシグナリングを受信することができる。また、この時、バージョン情報を確認し、既に受信しているＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎに比べてアップデートされた場合にのみ、当該サービスレイヤシグナリングをパーシングすることができる。これによって、受信機は、サービスレイヤシグナリングに対する不要なパーシング動作を減らすことができ、プロセシングオーバーヘッドを減少させることができる。上述したように、次世代放送システムは、サービスレイヤシグナリングの伝送プロトコルのヘッダーにシグナリングＩＤとバージョン情報を含めることによって、受信端が所望する情報をフィルタリングできるように支援することができる。

また、速いサービス取得情報は、リンクレイヤシグナリングが伝達されるデータパイプ又はＰＬＰに対する情報を含むことができる。すなわち、受信機は、速いサービス取得情報に含まれたデータパイプ又はＰＬＰ識別子情報を用いて、リンクレイヤシグナリングが伝達されるＰＬＰを識別し、そこに含まれたリンクレイヤシグナリングを取得することができる。図示のように、伝送リンクレイヤシグナリングのフォーマットは、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅを含むことができる。ここで、シグナリングメッセージは、リンクレイヤシグナリングに関する情報を含むことができる。受信機は、データパイプなどを介してＬｉｎｋＬａｙｅｒｓｉｇｎａｌｉｎｇ（或いは、ｌｏｗｌａｙｅｒｓｉｇｎａｌｉｎｇ）を取得することができ、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌを介してｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｔａｂｌｅなどのようなサービス／コンポーネントシグナリングを取得することができる。すなわち、次世代放送システムは、物理層フレームに、リンクレイヤシグナリングが含まれたデータパイプ又はＰＬＰに対するシグナリング情報を含むことができる。

図８７は、本発明の一実施例に係る、次世代放送システムのサービスレイヤシグナリングを伝送する方法を示す図である。サービスレイヤシグナリングは、前述したシグナリング又は３ＧＰＰｅＭＢＭＳシグナリングを含むことができる。次世代放送システムの放送信号にＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌが存在しない場合、図示のように、迅速なサービススキャン及び取得を支援するためのシグナリングデータがｐｈｙｓｉｃａｌｌａｙｅｒｆｒａｍｅ内のｃｏｍｍｏｎｄａｔａｐｉｐｅ、ｄａｔａｐｉｐｅ又はＰＬＰを介して伝送されてもよい。この場合、迅速なサービススキャン及び取得などと関連したシグナリングデータは、ｌｉｎｋ（或いは、ｌｏｗ）ｌａｙｅｒｓｉｇｎａｌｉｎｇ形態でエンカプセレーションされて、他のｌｉｎｋ（或いは、ｌｏｗ）ｌａｙｅｒｓｉｇｎａｌｉｎｇなどと共に伝送されてもよい。すなわち、フレーム内のＰＬＰは、サービス取得情報を含むシグナリングデータを伝達することができる。さらに、これは、サービス／コンポーネントシグナリング或いはコンポーネントデータと同一の或いは別途のｄａｔａｐｉｐｅ又はＰＬＰを介して伝送されてもよい。サービス／コンポーネントシグナリングは、上記で提案したシグナリング或いは３ＧＰＰｅＭＢＭＳシグナリングなどを伝送することができる。当該シグナリングは、前述したように、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅを含むことができる。ここで、ＳＭＨは、実施例によってシグナリングフォーマットに含まれなくてもよい。ここで、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。

下段の図面は、リンクレイヤシグナリングに含まれたサービス取得情報を用いてサービスレイヤシグナリングを取得する方法を示す図である。放送信号フレームのＰＬＰは、リンクレイヤシグナリングを含むことができる。リンクレイヤシグナリングは、前述した速いサービススキャン及び取得情報を含むことができる。速いサービススキャン及び取得情報は、サービス識別子及び当該サービスに対するサービスレイヤシグナリングが含まれたＰＬＰ識別子情報を含むことができる。当該ＰＬＰ識別子によって指示されるＰＬＰは、サービスレイヤシグナリングを含むことができる。サービスレイヤシグナリングは、上述したように、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）、ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｈｅａｄｅｒ（ＳＭＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅを含むことができる。サービスレイヤシグナリングのシグナリングメッセージは、伝送セッションインスタンスディスクリプション、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むことができる。次世代放送信号受信機は、サービスレイヤシグナリングをパーシングして所望のサービスを取得することができる。

図８８は、本発明の一実施例に係る、次世代放送システムにおいてサービスレイヤシグナリングを伝達する方法を示す図である。サービスレイヤシグナリングは、前述したシグナリング又は３ＧＰＰｅＭＢＭＳシグナリングを含むことができる。放送信号フレームのＰＬＰは、リンクレイヤシグナリングを含むことができる。リンクレイヤシグナリングは、前述した速いサービススキャン及び取得情報を含むことができる。速いサービススキャン及び取得情報は、サービス識別子及び当該サービスに対するサービスレイヤシグナリングが含まれたＰＬＰ識別子情報を含むことができる。当該ＰＬＰ識別子によって指示されるＰＬＰは、サービスレイヤシグナリングを含むことができる。サービスレイヤシグナリングは、上述したように、Ｇｅｎｅｒｉｃｐａｃｋｅｔｈｅａｄｅｒ（ＧＰＨ）、ＩＰｐａｃｋｅｔＨｅａｄｅｒ（ＩＰＨ）、ＵＤＰｄａｔａｇｒａｍｈｅａｄｅｒ（ＵＤＰＨ）、ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ（例えば、ＲＯＵＴＥ又はＭＭＴＰなど）ｈｅａｄｅｒ（ＡＴＰＨ）及びｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅを含むことができる。サービスレイヤシグナリングのシグナリングメッセージは、伝送セッションインスタンスディスクリプション、ＭＰＤｄｅｌｉｖｅｒｙｄｅｓｃｒｉｐｔｉｏｎ、ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ又はＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎを含むことができる。次世代放送信号受信機は、サービスレイヤシグナリングをパーシングして所望のサービスを取得することができる。ここで、ＡＴＰＨは、サービスレイヤシグナリングに対するｆｉｌｔｅｒｉｎｇｉｎｄｅｘを含むことができる。ここで、ｆｉｌｔｅｒｉｎｇｉｎｄｅｘは、ｓｉｇｎａｌｉｎｇｉｄ、ｖｅｒｓｉｏｎなどを含むことができる。ｓｉｇｎａｌｉｎｇｉｄは、サービスレイヤシグナリングに対する識別子情報を含むことができ、ｖｅｒｓｉｏｎは、サービスレイヤシグナリングに含まれた情報のｖｅｒｓｉｏｎを示すことができる。ｆｉｌｔｅｒｉｎｇｉｎｄｅｘを用いてサービスレイヤシグナリングをフィルタリングする方法は、前述したとおりである。

図８９は、本発明の他の実施例に係る、シグナリングメッセージ（ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅ）のヘッダー（ｈｅａｄｅｒ）のシンタックス（ｓｙｎｔａｘ）を示す図である。

本発明の他の実施例に係るシグナリングメッセージは、ＸＭＬ形態で表現されてもよい。このとき、ＸＭＬ形態のシグナリングメッセージに含まれるシグナリング情報は、前述した又は後述するようなシグナリング情報に該当し得る。

本発明の他の実施例に係る、シグナリングメッセージのヘッダーは、ｓｉｇｎａｌｉｎｇ＿ｉｄ情報、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈ情報、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ情報、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ情報、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ情報、ｉｎｄｉｃａｔｏｒ＿ｆｌａｇｓ情報、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ情報、ｐａｙｌｏａｄ＿ｆｏｒｍａｔ＿ｉｎｄｉｃａｔｏｒ情報、ｅｘｐｉｒａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ情報、ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒ情報、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒ情報、ｐａｙｌｏａｄ＿ｆｏｒｍａｔ情報、ｖａｌｉｄｆｒｏｍ情報、及び／又はｅｘｐｉｒａｔｉｏｎ情報を含むことができる。

本実施例に係るシグナリングメッセージのヘッダーに含まれるシグナリング情報のうち、前述したシグナリングメッセージのヘッダーに含まれるシグナリング情報と同一又は類似の名称を有するシグナリング情報に関する説明は、前述した説明に代える。

ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報は、シグナリングメッセージのヘッダー部分にｖａｌｉｄｆｒｏｍ情報の値が含まれたか否かを示すことができる。例えば、ｖａｌｉｄｆｒｏｍ＿ｉｎｄｉｃａｔｏｒ情報の値が「１」である場合、シグナリングメッセージのヘッダー部分にｖａｌｉｄｆｒｏｍ情報が含まれていることを示すことができる。

ｖａｌｉｄｆｒｏｍ情報は、ペイロード（ｐａｙｌｏａｄ）に含まれているシグナリングメッセージの可用開始時点を示すことができる。受信機は、これを用いて、ペイロードに含まれているシグナリングの可用開始時点を認知でき、当該時点からペイロードに含まれたデータをシグナリング情報として用いることができる。

ここで、ペイロードは、放送サービス又は放送コンテンツのデータ（放送サービスデータ）を含む放送信号内の領域を表すことができる。すなわち、一般に、シグナリング情報は、放送信号内で、放送サービスデータとは物理的或いは論理的に区分された領域で伝送される。しかし、本発明によれば、ペイロード領域に余裕領域が存在する場合、又はシグナリング情報の伝送のために割り当てられた領域のサイズよりも多い量のシグナリング情報を伝送しなければならない場合には、放送信号内のペイロード領域を介してシグナリング情報を伝送することができる。

図９０は、本発明の一実施例に係る、ＤＡＳＨＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ（ＤＡＳＨ初期化セグメント）を処理するプロトコルスタック（ＰｒｏｔｏｃｏｌＳｔａｃｋ）を示す図である。

ＤＡＳＨ初期化セグメントは、前述した、ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔＤｅｌｉｖｅｒｙＴａｂｌｅのような形態又はＸＭＬ形態で伝送することができる。

初期化セグメント（ＤＡＳＨ初期化セグメント）は、複数のセグメントでエンカプセレーションされた（ｅｎｃａｐｓｕｌａｔｅｄ）メディアストリーム（又は放送信号）を表出するために必要なメタデータ（シグナリング情報）を含むセグメントである。ここで、セグメントは、ＨＴＴＰ−ＵＲＬと関連したデータのユニットである。セグメントは、放送サービス又は放送コンテンツのためのデータを含む。リプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）は、伝送フォーマット内で一つ以上のメディアストリームを含むデータユニットである。リプレゼンテーションは一つ以上のセグメントを含むことができる。

ＤＡＳＨ初期化セグメントは、送信機又は受信機で示すプロトコルスタックによって処理されてもよい。ＤＡＳＨ初期化セグメントは、プロトコルスタック（ＰｒｏｔｏｃｏｌＳｔａｃｋ）上で一つ以上の経路を介して伝送されてもよい。

プロトコルスタックについて説明すると、シグナリング情報又は放送サービスデータは、複数の層（ｌａｙｅｒ）のプロトコルによって処理されることがわかる。図面中、「シグナリングチャネル（ｓｉｇｎａｌｉｎｇｃｈａｎｎｅｌ）、ＤＰ（ＤａｔａＰｉｐｅ）」は第１層に該当し、「ＦＩＣ、リンクレイヤフレーム（ＬｉｎｋＬａｙｅｒＦｒａｍｅ）」は第２層に該当し、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）は第３層に該当することができ、ＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）は第４層に該当し、ＲＯＵＴＥは第５層に該当し得る。ここで、リンクレイヤフレームは、本明細書に説明されたリンクレイヤパケットを含むことができる。

ＤＡＳＨ初期化セグメントが処理されるプロトコルスタックは、同図の（１）の経路のように、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）のようなシグナリングデータがＩＰ／ＵＤＰに直接乗せられた伝送される場合、上記で提案したＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔＤｅｌｉｖｅｒｙＴａｂｌｅのような形態の情報として伝送されたり、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）自体がＩＰデータグラムなどの形態で、プロトコルスタックの処理を経て伝送されてもよい。前述したサービスシグナリング及び／又はコンポーネントシグナリングのための情報は、図示１）の経路で共に伝送されてもよい。

本発明の一実施例によれば、ＤＡＳＨ初期化セグメントは、経路（２）のように、シグナリングデータを伝送するための特定セッション（ｓｅｓｓｉｏｎ）で、又は経路（３）のように、コンポーネントデータを伝送するセッションでメディアデータと共に伝送されてもよい。一例として、アプリケーション伝送プロトコル（ａｐｐｌｉｃａｔｉｏｎｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ）としてはＲＯＵＴＥ（Ｒｅａｌ−ｔｉｍｅＯｂｊｅｃｔｄｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）を用いることができる。ＲＯＵＴＥセッションは、シグナリング情報を伝送するためのセッション及び／又は放送メディアに対するデータを伝送するセッションを含むことができる。放送システムは、シグナリング情報を伝送するセッションはＴＳＩの値を一定の値に固定し、これによって、受信機は、当該ＴＳＩの値を有するセッションで伝送されるデータはシグナリング情報であることを識別することができる。

図示された経路（２）及び／又は経路（３）のように、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）のようなシグナリング情報（データ）が伝送される場合、伝送ストリーム又は伝送オブジェクトなどで前述のシグナリングメッセージフォーマットのデータ、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）がどの部分に位置するかを識別する情報、及び／又はシグナリングメッセージフォーマットのデータや初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）を、共に伝送されるデータの中から区別するための情報が、伝送プロトコルパケット内部のフィールド、又は別途のシグナリング形態で提供されてもよい。

図９１は、本発明の一実施例に係る、ＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）セッションインスタンスディスクリプタ（ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ；ＬＳＩＤ）の一部を示す図である。

本発明の一実施例に係る、ＬＣＴセッションインスタンスディスクリプタは、シグナリングメッセージフォーマットのデータ、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）が放送信号内でどの部分に位置するかを識別する情報、及び／又はシグナリングメッセージフォーマットのデータや初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）を、共に伝送されるデータの中から区別するための情報を提供することができる。

ＬＣＴセッションインスタンスディスクリプタは、ＰａｙｌｏａｄＦｏｒｍａｔエレメントを含むことができる。ＰａｙｌｏａｄＦｏｒｍａｔエレメントは、＠ｃｏｄｅＰｏｉｎｔ情報、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報、＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報、＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報及び／又は＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報含むことができる。

それぞれのエレメントは、図面に説明されたような情報を提供するために用いることができる。

本発明の一実施例によれば、放送受信機又は放送送信機は、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）が含まれるＲＯＵＴＥパケットを識別するために、ＬＳＩＤのＳｏｕｒｃｅＦｌｏｗエレメント内のＰａｙｌｏａｄＦｏｒｍａｔエレメントの＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報（又は、フィールド）を用いることができる。

一実施例で（に）、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報値が「０」である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は、当該ＲＯＵＴＥパケットはシグナリングメッセージフォーマットを含んでいることを示すことができる。＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報の値が「０」の場合、このＰａｙｌｏａｄＦｏｒｍａｔエレメントに割り当てられた＠ｃｏｄｅＰｏｉｎｔ情報の値とＬＣＴパケットヘッダー内の同一値のｃｏｄｅｐｏｉｎｔ（ＣＰ）を有するＲＯＵＴＥパケットは、前述したシグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｆｏｒｍａｔ）形態のデータを伝送していることを示すことができる。初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）は本シグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｆｏｒｍａｔ）に含まれて伝送されてもよく、サービスシグナリング、コンポーネントシグナリングなどの他のシグナリングデータも、同じ方法でシグナリングメッセージフォーマット（ｓｉｇｎａｌｉｎｇｍｅｓｓａｇｅｆｏｒｍａｔ）に含まれてＲＯＵＴＥパケットを介して伝送されていることが識別されてもよい。

＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報の値が「４」である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔフィールドは、当該ＲＯＵＴＥパケットは初期化セグメントを含むメタデータ（シグナリング情報）を含むことを示すことができる。＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔフィールドの値が「４」である場合、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）を含むメタデータフォーマットがＲＯＵＴＥパケットを介して伝送されることを示したり、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）が直接ＲＯＵＴＥパケットを介して伝送されていることを示すことができる。

本発明の一実施例によれば、放送システム（放送受信機及び／又は送信機）は、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報に新しい値（例えば、「５」以上の値）を割り当てて、サービスシグナリング（サービスレベルシグナリング情報）、及び／又はコンポーネントシグナリング（コンポーネントレベルシグナリング）などの他のシグナリングデータがＲＯＵＴＥパケットを介して直接伝送されることをシグナリングすることができる。

本発明の他の実施例によれば、放送システムは、本実施例で説明された＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報を用いる方法の他にも、ＬＳＩＤ内の他のフィールド又は新しい追加フィールドを用いて、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）などのシグナリングデータが伝送されるＲＯＵＴＥパケットを識別することもできる。

図９２は、本発明の一実施例に係る、サービスシグナリングメッセージをフィルタリング（ｆｉｌｔｅｒｉｎｇ）するための情報を提供するシグナリングオブジェクトディスクリプション（ＳｉｇｎａｌｉｎｇＯｂｊｅｃｔＤｅｓｃｒｉｐｔｉｏｎ；ＳＯＤ）を示す図である。

本発明の一実施例に係るシグナリングオブジェクトディスクリプションは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ｄａｔａＶｅｒｓｉｏｎ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、ＳｉｇｎａｌｉｎｇＯｂｊｅｃｔエレメント、＠ｔｏｉ情報、＠ｔｙｐｅ情報、＠ｖｅｒｓｉｏｎ情報、＠ｉｎｓｔａｎｃｅＩｄ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔ情報を含むことができる。

＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、シグナリングオブジェクトディスクリプションのバージョンを示す。

＠ｄａｔａＶｅｒｓｉｏｎ情報は、シグナリングオブジェクトディスクリプションのインスタンス（ｉｎｓｔａｎｃｅ）のバージョン（ｖｅｒｓｉｏｎ）を示す。シグナリングオブジェクトディスクリプション内に含まれた内容が変更される場合に、＠ｄａｔａＶｅｒｓｉｏｎが変更されてもよい。

＠ｖａｌｉｄＦｒｏｍ情報は、シグナリングオブジェクトディスクリプションのインスタンスの可用開始時点を示すことができる。これを用いて、受信機は、シグナリングオブジェクトディスクリプションの可用開始時点を認知でき、当該時点から、シグナリングオブジェクトディスクリプションに含まれた情報を用いることができる。

＠ｅｘｐｉｒａｔｉｏｎ情報は、シグナリングオブジェクトディスクリプションのインスタンスの可用完了時点を示すことができる。これを用いて、受信機は、シグナリングオブジェクトディスクリプションの可用完了時点を認知でき、これを用いてシグナリングオブジェクトディスクリプションの情報を管理することができる。

ＳｉｇｎａｌｉｎｇＯｂｊｅｃｔエレメントは、シグナリング情報を含むオブジェクトを示す。シグナリングオブジェクトディスクリプションでは一つ以上のシグナリングオブジェクトに対するシグナリング情報を含むことができる。

＠ｔｏｉ情報は、シグナリングオブジェクトに割り当てられたＴＯＩ（ＴｒａｎｓｍｉｓｓｉｏｎＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ）を示す。＠ｔｏｉ情報は、シグナリングオブジェクトと関連したパケットを識別するために用いられてもよい。受信機は、＠ｔｏｉ情報をＬＣＴパケットのＴＯＩにマッピングし、それぞれのｏｂｊｅｃｔが伝送するシグナリングメッセージのｔｙｐｅ、及び／又はｖｅｒｓｉｏｎなどの下の情報を識別することができる。

＠ｔｙｐｅ情報は、オブジェクトに含まれているシグナリングメッセージのタイプを識別する情報である。例えば、＠ｔｙｐｅ情報の値が０であれば、ＬＳＩＤ（ＬＣＴＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が１であれば、ＣＭＤ（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が２であれば、ＡＳＤ（ＡｐｐｌｉｃａｔｉｏｎＳｉｇｎａｌｉｎｇＤｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が３であれば、ＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が４であればＵＳＤ（ＵＲＬＳｉｇｎａｌｉｎｇＤｅｓｃｒｉｐｔｉｏｎ）、＠ｔｙｐｅ情報の値が５であれば、ＩＳ（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）が、オブジェクト内でシグナリングメッセージとして伝送されることを示すことができる。

＠ｖｅｒｓｉｏｎ情報は、シグナリングメッセージのバージョン（ｖｅｒｓｉｏｎ）を示す情報である。受信機は、本フィールド値の変化から、シグナリングメッセージの変更を識別することができる。

＠ｉｎｓｔａｎｃｅＩｄ情報は、シグナリングメッセージのインスタンスを識別する情報である。本情報は受信機によって、初期化セグメント（ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ）のように一つのサービス内に複数個存在し得るシグナリングメッセージのインスタンスを区別するために用いられてもよい。

＠ｖａｌｉｄＦｒｏｍ情報は、オブジェクトに含まれているシグナリングメッセージの可用開始時点を示すことができる。これを用いて、受信機は、オブジェクトに含まれているシグナリングの可用開始時点を認知でき、当該時点から、オブジェクトに含まれているシグナリングを用いることができる。

＠ｅｘｐｉｒａｔｉｏｎ情報は、オブジェクトに含まれているシグナリングメッセージの有効時間を示すことができる。これを用いて、受信機は、オブジェクトに含まれているシグナリングの可用完了時間を認知でき、これを用いてシグナリングメッセージを管理することができる。

＠ｐａｙｌｏａｄＦｏｒｍａｔ情報は、オブジェクトに含まれるシグナリングメッセージデータのフォーマットを示すことができる。例えば、シグナリングメッセージは、ｂｉｎａｒｙ又はＸＭＬの形式で提供されてもよく、＠ｐａｙｌｏａｄＦｏｒｍａｔ情報はこの形式を示す。

シグナリングメッセージがＲＯＵＴＥなどのＬＣＴベースプロトコルで伝送される場合、それぞれのシグナリングメッセージをオブジェクトとして設定して処理することができる。上記のプロトコルでオブジェクトは固有のＴＯＩで識別されればいいので、それぞれのＴＯＩにｖｅｒｓｉｏｎ、ｔｙｐｅなどのシグナリングメッセージ関連情報をマッピングすることによって、シグナリングメッセージをフィルタリングすることができる。前述したような、ＳＯＤ（ＳｉｇｎａｌｉｎｇＯｂｊｅｃｔＤｅｓｃｒｉｐｔｉｏｎ）は一つの伝送セッションに該当するシグナリングオブジェクトのフィルタリング情報を提供する。シグナリングオブジェクトディスクリプションは、シグナリングを伝送するセッションの内部、又は外部手段を介して伝送されてもよい。内部でシグナリングオブジェクトディスクリプションが伝送される場合、受信機は、固有のＴＯＩ値（例えば、０又は０ｘＦＦＦＦなどの値）によってシグナリングオブジェクトディスクリプションを識別し、共に伝送される他のシグナリングメッセージのに先にシグナリングオブジェクトディスクリプションを解釈することができる。外部でシグナリングオブジェクトディスクリプションが伝送される場合、ＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）、ＳＬＴ（ｓｅｒｖｉｃｅｌｉｓｔｔａｂｌｅ）、別途のＩＰデータグラム、又は他のＲＯＵＴＥセッションなどの手段を介してシグナリングオブジェクトディスクリプションが伝送され、当該セッションで伝達される他のオブジェクトの先に伝送されることで、受信機ではシグナリングメッセージの情報をあらかじめ取得することができる。

図９３は、本発明の一実施例に係る、シグナリングメッセージを含むオブジェクトを示す図である。

シグナリングメッセージがＲＯＵＴＥなどのＬＣＴベースプロトコルで伝送される場合、それぞれのシグナリングメッセージをオブジェクトに設定して処理することができる。上記のプロトコルでオブジェクトは固有のＴＯＩで識別されてもよい。受信機では、それぞれのＴＯＩにｖｅｒｓｉｏｎ、及び／又はｔｙｐｅなどのシグナリングメッセージ関連情報をマッピングし、シグナリングメッセージをフィルタリングすることができる。互いに異なる内容物を含むオブジェクトには互いに異なるＴＯＩが与えられ、この場合、放送システムでは、全てのオブジェクトが固有に識別され得るので、既存のオブジェクト処理方法と互換性のある方法でシグナリングメッセージを処理することができる。

同図は、ＴＯＩフィールドの一部を固定長さのシグナリングメッセージ関連情報記述のために用いる実施例を示している。本実施例では、３２ビットのＴＯＩフィールドが用いられており、それぞれ１６ビットのＴｙｐｅとＶｅｒｓｉｏｎフィールドを用いて、オブジェクトを介して送信されている前述したシグナリングデータのｔｙｐｅとｖｅｒｓｉｏｎを識別することができる。同様の方法で、前述したｓｅｑｕｅｎｃｅｎｕｍｂｅｒ情報、ｖａｌｉｄｆｒｏｍ情報、ｅｘｐｉｒａｔｉｏｎ情報、及び／又はｐａｙｌｏａｄｆｏｒｍａｔ情報の追加情報も、本実施例におけるＴｙｐｅ、Ｖｅｒｓｉｏｎ共に、ＴＯＩフィールドの一部を固定長さのフィールドに割り当てることによって当該情報を伝達することができる。

本発明の一実施例に係る、オブジェクトは、ｖエレメント、ｃエレメント、ＰＳＩエレメント、Ｓエレメント、Ｏエレメント、Ｈエレメント、Ａエレメント、Ｂエレメント、ＨＤＲ＿ＬＥＮエレメント、Ｃｏｄｅｐｏｉｎｔエレメント、ＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎエレメント、ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ（ＴＳＩ）エレメント、ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ（ＴＯＩ）エレメント、ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎｓエレメント、ＦＥＣｐａｙｌｏａｄＩＤエレメント、及び／又はＥｎｃｏｄｉｎｇＳｙｍｂｏｌｓエレメントを含むことができる。ここで、エレメントは、情報又はフィールドと呼ぶこともできる。

ＰＳＩエレメントは、Ｘエレメント及び／又はＹエレメントを含むことができる。

ＴＯＩエレメントは、Ｔｙｐｅエレメント及び／又はＶｅｒｓｉｏｎエレメントを含むことができる。

ｖエレメントは、パケットのバージョンナンバーを示す。ｖエレメントは、ＡＬＣ／ＬＣＴのバージョンを示すことができる。ｖエレメントは、ボンオブジェクトを介してＡＬＣ／ＬＣＴ＋に従うパケットが伝送されることを示すことができる。

ｃエレメントは、Ｃｏｎｇｅｓｔｉｏｎｃｏｎｔｒｏｌｆｌａｇに該当する。ｃエレメントは、ＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントの長さを示すことができる。例えば、ｃエレメントは、ｃエレメントの値が０である場合、ＣＣＩの長さは３２ビット、ｃエレメントの値が１である場合、ＣＣＩの長さは６４ビット、ｃエレメントの値が２である場合、ＣＣＩの長さは９６ビット、ｃエレメントの値が３である場合、ＣＣＩの長さは１２８ビットであることを示すことができる。

ＰＳＩエレメントは、Ｐｒｏｔｏｃｏｌ−ＳｐｅｃｉｆｉｃＩｎｄｉｃａｔｉｏｎ（ＰＳＩ）に該当し得る。ＰＳＩエレメントは、ＡＬＣ／ＬＣＴ＋の上位プロトコルに対する特定目的の指示子として用いられてもよい。ＰＳＩエレメントは、現在パケットがｓｏｕｒｃｅｐａｃｋｅｔに該当するかＦＥＣｒｅｐａｉｒｐａｃｋｅｔに該当するかを示すことができる。

Ｘエレメントは、ｓｏｕｒｃｅｐａｃｋｅｔを示す情報に該当し得る。Ｓｏｕｒｃｅとｒｅｐａｉｒｄａｔａのために互いに異なるＦＥＣｐａｙｌｏａｄＩＤフォーマットが用いられる場合、このエレメントの値が「１」なら、ｓｏｕｒｃｅｄａｔａのためのＦＥＣｐａｙｌｏａｄＩＤフォーマットであることを示し、このエレメントの値が「０」なら、ｒｅｐａｉｒｄａｔａのためのＦＥＣｐａｙｌｏａｄＩＤフォーマットであることを示す。又は、このエレメントの値が送信機から「０」へセッティングされた場合、受信機はこのエレメント又はこのパケットを無視し、処理しなくてもよい。

Ｓエレメントは、ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒｆｌａｇに該当し得る。Ｓエレメントは、ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒエレメントの長さを示す。

Ｏエレメントは、ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒｆｌａｇに該当し得る。Ｏエレメントは、ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒエレメントの長さを示すことができる。オブジェクトは一つのファイルを意味でき、ＴＯＩは各オブジェクトの識別情報であり、ＴＯＩが０であるファイルは、ファイルと関連したシグナリング情報を含むことができる。

Ｈエレメントは、Ｈａｌｆ−ｗｏｒｄｆｌａｇに該当し得る。Ｈエレメントは、ＴＳＩ及びＴＯＩフィールドの長さにｈａｌｆ−ｗｏｒｄ（１６ビット）を追加するか否かを示す。

Ａエレメントは、ＣｌｏｓｅＳｅｓｓｉｏｎｆｌａｇに該当し得る。Ａエレメントは、セッションが終了した又は終了が迫ったことを示すことができる。

Ｂエレメントは、ＣｌｏｓｅＯｂｊｅｃｔｆｌａｇに該当し得る。Ｂエレメントは、伝送中であるオブジェクトが終了した又は終了が迫ったことを示すことができる。

ＨＤＲ＿ＬＥＮエレメントは、パケットのヘッダーの長さを示す。

Ｃｏｄｅｐｏｉｎｔエレメントは、このパケットによって伝送されるペイロード（ｐａｙｌｏａｄ）のタイプを示す。ペイロードのタイプによって、追加的なペイロードヘッダーがペイロードデータのプレフィックス（ｐｒｅｆｉｘ）に挿入されてもよい。

ＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントは、ｌａｙｅｒｎｕｍｂｅｒｓ、ｌｏｇｉｃａｌｃｈａｎｎｅｌｎｕｍｂｅｒｓ、ｓｅｑｕｅｎｃｅｎｕｍｂｅｒｓなどのＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌ情報を含むことができる。ＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ（ＣＣＩ）エレメントは、必要なＣｏｎｇｅｓｔｉｏｎＣｏｎｔｒｏｌ関連情報を含むことができる。

ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ（ＴＳＩ）エレメントは、セッションの固有識別子である。ＴＳＩエレメントは、特定伝送者（ｓｅｎｄｅｒ）からの全てのセッション（ｓｅｓｓｉｏｎ）のうちいずれか一つのセッションを示す。ＴＳＩエレメントは、ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎを識別する役割を担う。ＴＳＩエレメントの値は一つのトラックのために用いられてもよい。

ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ（ＴＯＩ）エレメントは、オブジェクトの固有識別子である。ＴＯＩエレメントは、セッション内で、どのオブジェクトにこのパケットが属するかを示す。ＴＯＩエレメントの値は、一つのＩＳＯＢＭＦＦｏｂｊｅｃｔデータのために用いられてもよい。ＴＯＩエレメントは、ＩＳＯＢＭＦＦファイルのＩＤとｃｈｕｎｋのＩＤを含むことができる。ＴＯＩエレメントは、ＩＳＯＢＭＦＦファイルのＩＤとｃｈｕｎｋのＩＤとの組合せをその値として有することができる。

Ｔｙｐｅエレメントは、ボンオブジェクトを介して伝送されるデータの種類を識別することができる。例えば、Ｔｙｐｅエレメントは、ボンオブジェクトを介して伝送されるデータがシグナリングメッセージであることを示すことができる。

Ｖｅｒｓｉｏｎエレメントは、ボンオブジェクトを介して伝送されるデータのバージョンを識別する。例えば、Ｖｅｒｓｉｏｎエレメントは、Ｔｙｐｅオブジェクトを用いて識別されたデータの構造及び／又は内容に変更があるかを識別する情報を含むことができる。

ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎｓエレメントは、追加的なヘッダー情報を含むことができる。

ＦＥＣｐａｙｌｏａｄＩＤエレメントは、ＦＥＣＰａｙｌｏａｄ識別子である。ＦＥＣｐａｙｌｏａｄＩＤエレメントは、ＴｒａｎｓｍｉｓｓｉｏｎＢｌｏｃｋ又はｅｎｃｏｄｉｎｇｓｙｍｂｏｌの識別情報を含む。ＦＥＣＰａｙｌｏａｄＩＤは、ファイルがＦＥＣエンコーディングされた場合の識別子を示す。例えば、ＦＥＣＰａｙｌｏａｄＩＤは、ＦＬＵＴＥプロトコルファイルがＦＥＣエンコーディングされた場合、放送局又は放送サーバーがこれを区別するために割り当てることができる。

ＥｎｃｏｄｉｎｇＳｙｍｂｏｌｓエレメントは、ＴｒａｎｓｍｉｓｓｉｏｎＢｌｏｃｋ又はｅｎｃｏｄｉｎｇｓｙｍｂｏｌのデータを含むことができる。

図９４は、本発明の一実施例に係る、ＴＯＩ構成ディスクリプション（ＴＯＩＣｏｎｆｉｇｕｒａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ；ＴＣＤ）を示す図である。

前述したように、ＴＯＩフィールドの一部を可変長さのシグナリングメッセージ関連情報の記述のために用いることができる。可変長さのＴＯＩフィールド内で、シグナリングメッセージ関連情報の記述のためにはＴＯＩフィールドの構成情報が別途に伝送されてもよい。一実施例として、図示された表のようなＴＯＩ構成ディスクリプションがＴＯＩフィールドの構成に関する情報を提供するために、送信及び／又は受信されてもよい。本実施例では、ＴＣＤ（ＴＯＩＣｏｎｆｉｇｕｒａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）は、一つの伝送セッションに該当する伝送パケットのＴＯＩフィールド構成情報を提供する。ＴＣＤは、シグナリングを伝送するセッションの内部、及び／又は外部手段を介して伝送されてもよい。ＴＣＤが、シグナリングを伝送するセッションの内部で伝送される場合、固有のＴＯＩ値、一例として０又は０ｘＦＦＦＦなどの値で識別し、共に伝送される他のシグナリングメッセージに先立って解釈されてもよい。ＴＣＤがシグナリングを伝送するセッションの外部で伝送される場合、ＦＩＣ、別途のＩＰデータグラム及び／又は他のＲＯＵＴＥセッションなどの手段を介して伝送され、当該セッションで伝達されるオブジェクトに先立って伝送されて各パケットに含まれたＴＯＩフィールドの構成情報を受信機であらかじめ把握できるように処理することができる。＠ｔｙｐｅＢｉｔｓフィールド以下のフィールドは、ＴＯＩ内の各フィールド長さを示し、ＴＯＩ開始ビットから順にそれぞれの長さに該当するフィールド情報が記述されることを知らせる。

本発明の一実施例に係るＴＣＤは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ｄａｔａＶｅｒｓｉｏｎ情報、＠ｖａｌｉｄＦｒｏｍ情報、＠ｅｘｐｉｒａｔｉｏｎ情報、＠ｔｙｐｅＢｉｔｓ情報、＠ｖｅｒｓｉｏｎＢｉｔｓ情報、＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報、＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報、＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報を含むことができる。

＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＴＣＤのバージョンを識別する。＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＴＣＤのプロトコル又は構造に変更がある場合、これを識別する。

＠ｄａｔａＶｅｒｓｉｏｎ情報はＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）のバージョンを識別する。＠ｄａｔａＶｅｒｓｉｏｎ情報は、ＴＣＤに含まれる内容が変更される場合、これを識別する。

＠ｖａｌｉｄＦｒｏｍ情報は、ＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）の可用開始時点を示すことができる。受信機は、＠ｖａｌｉｄＦｒｏｍ情報を用いてＴＣＤの可用開始時点を認知でき、当該時点からＴＣＤの情報を用いることができる。

＠ｅｘｐｉｒａｔｉｏｎ情報は、ＴＣＤのインスタンス（Ｉｎｓｔａｎｃｅ）の可用完了時点を示すことができる。受信機は、＠ｅｘｐｉｒａｔｉｏｎ情報を用いてＴＣＤの可用完了時点を認知でき、ＴＣＤの情報の使用を終了させることができる。受信機は、＠ｅｘｐｉｒａｔｉｏｎ情報を用いて、ＴＣＤ情報を管理することができる。

＠ｔｙｐｅＢｉｔｓ情報は、ＴＯＩフィールド内ｔｙｐｅフィールドの長さを示す。＠ｔｙｐｅＢｉｔｓ情報は、ｔｙｐｅフィールドの長さをビットで表現することができる。

＠ｖｅｒｓｉｏｎＢｉｔｓ情報は、ＴＯＩフィールド内ｖｅｒｓｉｏｎフィールドの長さを示す。＠ｖｅｒｓｉｏｎＢｉｔｓ情報は、ｖｅｒｓｉｏｎフィールドの長さをビットで表現することができる。

＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報は、ＴＯＩフィールド内ｉｎｓｔａｎｃｅＩＤフィールドの長さをビット数で示すことができる。

＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報は、ＴＯＩフィールド内ｖａｌｉｄＦｒｏｍフィールドの長さをビット数で示すことができる。

＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報は、ＴＯＩフィールド内ｅｘｐｉｒａｔｉｏｎフィールドの長さをビット数で示すことができる。

＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報は、ＴＯＩフィールド内ｐａｙｌｏａｄＦｏｒｍａｔフィールドの長さをビット数で示すことができる。

図９５は、本発明の一実施例に係る、伝送パケットのペイロード（Ｐａｙｌｏａｄ）フォーマット（Ｆｏｒｍａｔ）エレメントを示す図である。

本発明の一実施例によれば、伝送パケットのペイロードを介して、シグナリングメッセージを伝送することができる。そのために、伝送パケットは、図示のようなペイロードフォーマットエレメントを含むことができる。伝送パケットは、放送データを含むオブジェクトを伝送するパケットに該当する。本発明の伝送パケットは、当該パケットが処理されるプロトコルによって、その名称が変更されてもよい。例えば、ＲＯＵＴＥを介してパケットが処理されると、ＲＯＵＴＥパケットと呼ぶことができる。

ペイロードフォーマットエレメントは、前述したようにＬＳＩＤに含まれてもよい。

本発明の伝送パケットのペイロードフォーマットエレメントは、＠ｃｏｄｅＰｏｉｎｔ情報、＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報、＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報、＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報、＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報及び／又はＴＣＩＤ（ＴＯＩＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）を含むことができる。

＠ｃｏｄｅＰｏｉｎｔ情報は、このペイロードのために用いられるＣｏｄｅＰｏｉｎｔを定義する。本情報は、前述したＣＰエレメントと同じ役割を担当したり、同じ値を有することができる。

＠ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ情報は、データの伝送のためのオブジェクトのペイロードのフォーマットを識別する。例えば、本情報は、オブジェクトがシグナリングメッセージを伝送したり、ファイルを伝送したり、Ｅｎｔｉｔｙを伝送したり、Ｐａｃｋａｇｅを伝送したり、又は初期化セグメントを含むメタデータを伝送していることを示すことができる。

＠ｆｒａｇｍｅｎｔａｔｉｏｎ情報は、フラグメンテーション（Ｆｒａｇｍｅｎｔａｔｉｏｎ）のタイプを識別する。

＠ｄｅｌｉｖｅｒｙＯｒｄｅｒ情報は、オブジェクトの伝送順序を識別する。例えば、本情報は、現在ペイロードを介して伝送されるオブジェクトの順序を識別するために用いられてもよい。

＠ｓｏｕｒｃｅＦｅｃＰａｙｌｏａｄＩＤ情報は、ソースＦＥＣペイロードＩＤ（ＳｏｕｒｃｅＦＥＣＰａｙｌｏａｄＩＤ）のフォーマットを定義することができる。

ＴＣＩＤは、ＴＯＩフィールドの一部を可変長さのシグナリングメッセージ関連情報の記述のために用いる場合、ＴＯＩフィールドの構成情報を含むことができる。

図９６は、本発明の一実施例に係る、ＴＯＩ構成インスタンスディスクリプション（ＴＯＩＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ；ＴＣＩＤ）を示す図である。

ＴＯＩフィールドの一部を可変長さのシグナリングメッセージ関連情報の記述のために使用し、一つの伝送セッション内でＴＯＩフィールドの構成が動的に変わってもよい。

可変長さのＴＯＩフィールド内シグナリングメッセージ関連情報の記述のためにはＴＯＩフィールド構成情報が別途に伝送されてもよい、このようなＴＯＩフィールド構成情報は、図示された形態で伝送されてもよい。

本実施例では、ＴＣＩＤは、一つのｃｏｄｅｐｏｉｎｔ値にマッピングされるパケットのグループに該当する伝送パケットのＴＯＩフィールド構成情報を提供する。ＴＣＩＤは、ＬＳＩＤのＳｏｕｒｃｅＦｌｏｗ内ＰａｙｌｏａｄＦｏｒｍａｔに含まれて伝送されてもよい。ＴＣＩＤの内部フィールドは、前述したＴＣＤにおけると同一であってもよく、ＰａｙｌｏａｄＦｏｒｍａｔに併せて含まれた＠ｃｏｄｅＰｏｉｎｔと同じ値のＣＰ値を有するパケットのＴＯＩ構成を示すことができる。ＴＯＩの構成方法は、前述したＴＣＤにおける方法と同一であってもよい。

本発明の一実施例に係る、ＴＣＩＤは、＠ｔｙｐｅＢｉｔｓ情報、＠ｖｅｒｓｉｏｎＢｉｔｓ情報、＠ｉｎｓｔａｎｃｅＩｄＢｉｔｓ情報、＠ｖａｌｉｄＦｒｏｍＢｉｔｓ情報、＠ｅｘｐｉｒａｔｉｏｎＢｉｔｓ情報、及び／又は＠ｐａｙｌｏａｄＦｏｒｍａｔＢｉｔｓ情報を含むことができる。本情報に関する説明は、同一名称を有する前述した情報に関する説明に代える。

図９７は、本発明の一実施例に係る、ＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）のペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。

本発明では、サービスをスキャンしたり、サービスの取得のための情報を含むシグナリングデータをＦＩＣと命名したが、その名称に限定されず、サービス層（又は、レベル）の下位層で、より効果的に放送サービスを取得するための情報を提供するシグナリングデータについて説明する。一例として、このようなシグナリングデータは、サービスリストテーブル、又はサービスリストエレメントなどの別の名称としてもよい。

また、本発明では、説明の便宜のために、シグナリングデータの構造をｂｉｎａｒｙ形態のテーブルとしているが、当該テーブルに属する同一又は類似の情報は、ＸＭＬ形態で具現されてもよい。

本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓ情報、ｐａｒｔｉｔｉｏｎ＿ｉｄ情報、ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ＩＤ情報、ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報、ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報、及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントを含むことができる。

ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、ＦＩＣの構造のバージョンを識別する情報である。

ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ情報は、放送ストリームを識別する情報である。全体放送ストリームを識別する情報に該当し得る。

ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓ情報は、放送ストリーム内におけるパーティション（ｐａｒｔｉｔｉｏｎ）の個数を示す情報である。一つの放送ストリームは、一つ以上のパーティションに分けられてもよく、それぞれのパーティションは、一つの放送会社（又は、放送ソース）によって用いられる一つ以上のデータパイプ（ｄａｔａｐｉｐｅ）を含むことができる。

ｐａｒｔｉｔｉｏｎ＿ｉｄ情報は、パーティションを識別する情報である。

ｐａｒｔｉｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、パーティションの構造のバージョンを識別する情報である。

ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報は、パーティションを介して一つ以上のコンポーネントが伝送される放送サービスの個数を示す。

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

ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、ＦＩＣによってシグナリングされるサービスのためのサービスエントリー（ｅｎｔｒｙ）に変更がある場合、この変更を識別する情報である。又は、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、サービスシグナリングチャネル（又は、サービスレベルシグナリング）に含まれる、サービスのためのシグナリングテーブルに変更がある場合、これを識別する情報である。ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、当該変更がある度にその値を増加させ、変更があることを示すことができる。

ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報は、サービスのためのチャネル番号を示す。

ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、サービスのカテゴリーを示す。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスがＡ／Ｖサービス、オーディオサービス、ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）、Ａｐｐｂａｓｅｄｓｅｒｖｉｃｅ及び／又はＣｏＤ（ＣｏｎｔｅｎｔｏｎＤｅｍａｎｄ）であることを示すことができる。

ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報の長さを示す。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が存在しない場合、「０」の値を有することができる。

ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報は、サービスのＳｈｏｒｔＮａｍｅを示す。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が示す各文字は、ＵＴＦ−８によってエンコーディングされてもよい。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報が奇数のバイト長を有する場合、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報によって識別されるペアカウント当たりのバイトペアの最後の二番目のバイトは、０ｘ００値を有することができる。（ＴｈｅｓｈｏｒｔｎａｍｅｏｆｔｈｅＳｅｒｖｉｃｅ，ｅａｃｈｃｈａｒａｃｔｅｒｏｆｗｈｉｃｈｓｈａｌｌｂｅｅｎｃｏｄｅｄｐｅｒＵＴＦ−８［］。Ｗｈｅｎｔｈｅｒｅｉｓａｎｏｄｄｎｕｍｂｅｒｏｆｂｙｔｅｓｉｎｔｈｅｓｈｏｒｔｎａｍｅ，ｔｈｅｓｅｃｏｎｄｂｙｔｅｏｆｔｈｅｌａｓｔｏｆｔｈｅｂｙｔｅｐａｉｒｐｅｒｔｈｅｐａｉｒｃｏｕｎｔｉｎｄｉｃａｔｅｄｂｙｔｈｅｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈｆｉｅｌｄｓｈａｌｌｃｏｎｔａｉｎ０ｘ００。）

ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、サービスの状態を示す。ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスがａｃｔｉｖｅ、ｉｎａｃｔｉｖｅ、ｓｕｓｐｅｎｄｅｄ、ｈｉｄｄｅｎ、及び／又はｓｈｏｗｎ状態であることを示すことができる。

ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報は、放送サービス又は放送コンテンツの表出（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）が、現在パーティションだけで可能か、現在パーティションだけでは不可能であるが、現在パーティションが必要か、他のパーティションを必要とするか、他の放送ストリームを必要とするかを識別する。

ｓｐ＿ｉｎｄｉｃａｔｏｒ情報は、サービス保護が適用されたかどうかを示す。ｓｐ＿ｉｎｄｉｃａｔｏｒ情報は、有意義な表出のために必要な、放送サービスの一つ以上のコンポーネントに対して、ｐｒｏｔｅｃｔｉｏｎがされたか否かを識別する。

ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報は、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報及び／又はＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報が示すＩＰアドレスが、ＩＰｖ４アドレスか又はＩＰｖ６アドレスかを識別する。

ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報は、サービスのためにＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報が存在するか否かを識別する情報である。

ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報の値が「１」に設定された場合には存在するが、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇ情報の値が「０」に設定された場合には存在しない。ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、サービスのためのシグナリング情報を伝送するＩＰデータグラム（又は、データユニット）のソースＩＰアドレスを示す。ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＩＰｖ６のアドレスが用いられる場合、１２８ビットを有することができる。

ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、サービスのためのシグナリング情報を伝送するＩＰデータグラム（又は、データユニット）のデスティネーションＩＰアドレスを示す。ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＩＰｖ６のアドレスが用いられる場合、１２８ビットを有することができる。

ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ情報は、サービスのためのシグナリング情報を伝送するＵＤＰ／ＩＰストリームのためのデスティネーションＵＤＰポート番号を示す。

ＳＳＣ＿ＴＳＩ情報は、サービスのためのシグナリング情報（又は、シグナリングテーブル）を伝送するＬＣＴチャネルのＴＳＩ（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ）を示す。

ＳＳＣ＿ＤＰ＿ＩＤ情報は、サービスのためのシグナリング情報（又は、シグナリングテーブル）を含むデータパイプ（ＤＰ；ＤａｔａＰｉｐｅ）を識別する情報である。シグナリング情報を伝送するデータパイプは、現在パーティション又は放送ストリーム内で最もロバスト（ｒｏｂｕｓｔ）なデータパイプに該当し得る。

ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報は、パーティションのために定義されるパーティションレベルディスクリプタの個数を示す。

ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは、一つ以上のパーティションレベルディスクリプタを含む。パーティションレベルディスクリプタは、受信機でパーティションに接近したり、パーティションを取得したり、パーティションを利用するために必要な情報を含むことができる。

ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓ情報は、ＦＩＣのために定義されるＦＩＣレベルディスクリプタの個数を示す。

ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは、一つ以上のＦＩＣレベルディスクリプタを含む。ＦＩＣレベルディスクリプタは、ＦＩＣのための追加のシグナリング情報を含むことができる。

図９８は、本発明の他の実施例に係る、ＦＩＣのペイロードのシンタックス（ｓｙｎｔａｘ）を示す図である。

本発明の他の実施例に係るＦＩＣのペイロードは、前述した実施例におけるＦＩＣのペイロードにＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報、ＳＳＣ＿ＵＲＬ＿ｌｅｎｇｔｈ情報、及び／又はＳＳＣ＿ＵＲＬ＿ｄａｔａ情報をさらに含むことができる。

ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、サービスに関連するシグナリング情報（例えば、サービスシグナリングチャネル又はサービスレベルシグナリング）が伝達される経路を識別する情報である。ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、サービスレベルシグナリングのデータがブロードバンド（インターネット網）を介して伝送されるか否かを識別することができる。一例として、ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、その値が０ｘ０１を有するとき、放送網を介してサービスレベルシグナリングが伝送されることを示すことができる。ＳＳＣ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅ情報は、その値が０ｘ０２を有するとき、インターネット網を介してサービスレベルシグナリングが伝送されることを示すことができる。

ＳＳＣ＿ＵＲＬ＿ｌｅｎｇｔｈ情報は、ＳＳＣ＿ＵＲＬ＿ｄａｔａ情報の長さを示す。

ＳＳＣ＿ＵＲＬ＿ｄａｔａ情報は、サービスに関連するシグナリング情報を提供するサーバー又は位置のＵＲＬを示す。

本実施例で説明していない他の情報に関する説明は、前述した説明に代える。

図９９は、本発明の他の実施例に係る、サービスレベルシグナリングのシンタックス（ｓｙｎｔａｘ）を示す図である。

受信機で、視聴者の所望する放送サービス及び／又は放送コンテンツを受信するために必要な情報を、サービスレベルシグナリングと命名することができる。サービスレベルシグナリングは、放送サービス及び放送サービスに含まれるコンポーネントに対する属性を説明する情報を含む。

本発明の他の実施例に係る、サービスレベルシグナリングデータは、シグナリングメッセージヘッダー（ｈｅａｄｅｒ）及び／又はサービスシグナリングメッセージを含むことができる。

本発明の他の実施例に係る、サービスレベルシグナリングデータは、＠ｓｅｒｖｉｃｅ＿ｉｄ情報、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、＠ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報、＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報、ＲＯＵＴＥＳｅｓｓｉｏｎエレメント、＠ｓｏｕｒｃｅＩＰＡｄｄｒ情報、＠ｄｅｓｔＩＰＡｄｄｒ情報、＠ｄｅｓｔＵＤＰＰｏｒｔ情報、＠ＬＳＩＤ＿ＤＰ情報、Ｔａｒｇｅｔｉｎｇエレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙエレメント、ＲｉｇｈｔＩｓｓｕｅｒＳｅｒｖｉｃｅエレメント、ＣｕｒｒｅｎｔＰｒｏｇｒａｍエレメント、ＯｒｉｇｉｎａｌＳｅｒｖｉｃｅＩｄｅｎｔｉｆｉｃａｔｉｏｎエレメント、ＣｏｎｔｅｎｔＬａｂｅｌｉｎｇエレメント、Ｇｅｎｒｅエレメント、Ｃａｐｔｉｏｎエレメント、及び／又はＰｒｏｔｅｃｔｉｏｎエレメントを含むことができる。

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

＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスのカテゴリーを識別する情報である。例えば、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスが、オーディオサービス、実時間放送サービス、非実時間放送サービス、ｌｉｎｅａｒ放送サービス、ａｐｐ−ｂａｓｅｄ放送サービス或いはサービスガイドであることを識別することができる。

＠ｓｅｒｖｉｃｅ＿ｎａｍｅ情報は、放送サービスの名称を示す。

＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報は、放送サービスを送信するチャネル番号を示す。このチャネル番号は、論理的／物理的チャネル番号に該当し得る。場合によって、このチャネル番号は、サービスレベルシグナリングのデータを伝送する論理的伝送経路又は伝送ユニットを識別する情報として用いられてもよい。

＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスの状態を示す。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスがアクティブ（ａｃｔｉｖｅ）状態か、インアクティブ（ｉｎａｃｔｉｖｅ）状態かを識別する情報を含むことができる。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、放送サービスがヒドン（ｈｉｄｄｅｎ）状態か否かを識別する情報を含むことができる。

＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎ情報は、放送サービスのためのデータ又はコンポーネントがどのように分配されて伝送されるかを示す情報である。

＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報は、放送サービス又は放送サービスに含まれる少なくとも一つのコンポーネントに対してサービスプロテクション（ｐｒｏｔｅｃｔｉｏｎ）が適用されたか否かを識別する情報である。＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報は、放送サービスの有意義な表出のためのデータ単位又はコンポーネントにサービスプロテクションが適用されたか否かを識別する情報に該当し得る。

ＲＯＵＴＥＳｅｓｓｉｏｎエレメントは、放送サービス又は放送サービスに含まれるコンポーネントを伝送するＲＯＵＴＥセッションに関する情報を含むエレメントである。

＠ｓｏｕｒｃｅＩＰＡｄｄｒ情報は、ＲＯＵＴＥパケットを伝送するＩＰデータグラム（或いは、データユニット）のソース（ｓｏｕｒｃｅ）ＩＰアドレスを示す。

＠ｄｅｓｔＩＰＡｄｄｒ情報は、ＲＯＵＴＥパケットを伝送するＩＰデータグラム（或いは、データユニット）のデスティネーション（ｄｅｓｔｉｎａｔｉｏｎ）ＩＰアドレスを示す。

＠ｄｅｓｔＵＤＰＰｏｒｔ情報は、ＲＯＵＴＥパケットを伝送するＩＰデータグラム（或いは、データユニット）のデスティネーションポート（ｐｏｒｔ）番号を示す。

＠ＬＳＩＤ＿ＤＰ情報は、ＲＯＵＴＥセッションと関連した伝送パラメータ及び／又はＲＯＵＴＥセッション内の下位セッションを説明する情報（例えば、ＬＳＩＤ）を伝達するデータパイプを識別する情報である。

Ｔａｒｇｅｔｉｎｇエレメントは、個人化された放送サービス（ターゲッティング放送）の提供のための情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。

ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙエレメントは、放送サービスに対する視聴等級に関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。ＲｉｇｈｔＩｓｓｕｅｒＳｅｒｖｉｃｅエレメントは、放送サービスを適切に消費するための権限に関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。

ＣｕｒｒｅｎｔＰｒｏｇｒａｍエレメントは、現在放送プログラムに関する情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。

ＯｒｉｇｉｎａｌＳｅｒｖｉｃｅＩｄｅｎｔｉｆｉｃａｔｉｏｎエレメントは、現在放送サービスに関連した元来のサービスを識別することと関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。

ＣｏｎｔｅｎｔＬａｂｅｌｉｎｇエレメントは、コンテンツラベリング（ｃｏｎｔｅｎｔｌａｂｅｌｉｎｇ）に関連した情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。Ｇｅｎｒｅエレメントは、放送サービスのジャンルを区別するための情報を含む情報である。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。

Ｃａｐｔｉｏｎエレメントは、放送サービスのｃｌｏｓｅｄｃａｐｔｉｏｎ／ｓｕｂｔｉｔｌｅに関する情報を含むエレメントである。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。

Ｐｒｏｔｅｃｔｉｏｎエレメントは、放送サービスに対するプロテクション（ｐｒｏｔｅｃｔｉｏｎ）関連情報を含むエレメントである。Ｐｒｏｔｅｃｔｉｏｎエレメントは、前述した＠ＳＰ＿ｉｎｄｉｃａｔｏｒ情報が、放送サービス又は放送コンポーネントに対してプロテクションが適用された場合、このプロテクションに関連した細部情報を提供することができる。このエレメントは、別途のシグナリング構造でサービスレベルシグナリングに含まれてもよい。この場合、当該サービスレベルシグナリングに対するリンク情報を含むことができる。

図１００は、本発明の他の実施例に係る、コンポーネントマッピングディスクリプション（ｃｏｍｐｏｎｅｎｔｍａｐｐｉｎｇｄｅｓｃｒｉｐｔｉｏｎ）を示す図である。

本発明の他の実施例に係る、コンポーネントマッピングディスクリプションは、前述した実施例に係るコンポーネントマッピングディスクリプションに含まれる情報又はエレメントに加えて、＠ｐａｒｔｉｔｉｏｎＩＤ情報をさらに含むことができる。

＠ｐａｒｔｉｔｉｏｎＩＤ情報は、放送ストリーム上で放送局を示すｐａｒｔｉｔｉｏｎを識別する情報である。＠ｐａｒｔｉｔｉｏｎＩＤ情報は、放送コンポーネントを伝送する送信元を識別する情報として用いられてもよい。

コンポーネントマッピングディスクリプションに含まれる他の情報又はエレメントに関する説明は、同一名称を有する情報又はエレメントについて前述した説明に代える。

図１０１は、本発明の他の実施例に係る、ＵＲＬシグナリングディスクリプション（ＵＲＬｓｉｇｎａｌｉｎｇｄｅｓｃｒｉｐｔｉｏｎ）のシンタックス（ｓｙｎｔａｘ）を示す図である。

前述したように、放送サービスを説明するシグナリング情報は、放送網だけでなく、ブロードバンド網を介して伝送されてもよい。放送サービスを説明するシグナリング情報がブロードバンド網を介して伝送される場合、受信機はＵＲＬシグナリングディスクリプションを介して、当該シグナリング情報を取得することができる。

本発明の他の実施例に係る、ＵＲＬシグナリングディスクリプションは、＠ｓｅｒｖｉｃｅ＿ｉｄ情報、＠ｓｍｔＵＲＬ情報、＠ｍｐｄＵＲＬ情報、＠ｃｍｔＵＲＬ情報、＠ａｓｔＵＲＬ情報、＠ｇａｔＵＲＬ情報、及び／又は＠ｅａｔＵＲＬ情報を含むことができる。

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

＠ｓｍｔＵＲＬ情報は、ブロードバンドでＳＭＴ（ＳｅｒｖｉｃｅＭａｐＴａｂｌｅ）が伝送される場合、ＳＭＴを提供するサーバー又は位置のＵＲＬを示す情報である。

＠ｍｐｄＵＲＬ情報は、ブロードバンドでＭＰＤが伝送される場合、ＭＰＤを提供するサーバー又は位置のＵＲＬを示す情報である。

＠ｃｍｔＵＲＬ情報は、ブロードバンドでＣＭＴ（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅ）が伝送される場合、ＣＭＴを提供するサーバー又は位置のＵＲＬを示す情報である。

＠ａｓｔＵＲＬ情報は、ブロードバンドでＡＳＴ（ＡｐｐｌｉｃａｔｉｏｎＳｉｇｎａｌｉｎｇＴａｌｂｅ）が伝送される場合、ＡＳＴを提供するサーバー又は位置のＵＲＬを示す情報である。

＠ｇａｔＵＲＬ情報は、ブロードバンドでＧＡＴ（ＧｕｉｄｅＡｃｃｅｓｓＴａｂｌｅ）が伝送される場合、ＧＡＴを提供するサーバー又は位置のＵＲＬを示す情報である。ＧＡＴは、ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）のブートストラップ（ｂｏｏｔｓｔｒａｐ）のための情報を含むシグナリングメッセージに該当し得る。すなわち、ＧＡＴは、受信機がＥＳＧに接近するために必要な情報を含むシグナリングメッセージに該当し得る。

＠ｅａｔＵＲＬ情報は、ブロードバンドでＥＡＴ（ＥｍｅｒｇｅｎｃｙＡｌｅｒｔＴａｂｌｅ）が伝送される場合、ＥＡＴを提供するサーバー又は位置のＵＲＬを示す情報である。ＥＡＴは、非常警報関連情報と非常警報メッセージを含むシグナリングメッセージに該当し得る。

図１０２は、本発明の他の実施例に係る、ＳｏｕｒｃｅＦｌｏｗエレメントを示す図である。

放送サービスのデータは、ＲＯＵＴＥセッションを介して、オブジェクト（Ｏｂｊｅｃｔ）単位で伝送されてもよい。それぞれのオブジェクトは個別的に復元されてもよい。一つのセッション内で、オブジェクトを伝送するためにｓｏｕｒｃｅプロトコルを定義することができ、ｓｏｕｒｃｅプロトコル内におけるｓｏｕｒｃｅ（ｏｂｊｅｃｔ）の伝達に関連した情報を含むＳｏｕｒｃｅＦｌｏｗエレメントを定義することができる。

本発明の他の実施例に係るＳｏｕｒｃｅＦｌｏｗエレメントは、前述したＳｏｕｒｃｅＦｌｏｗエレメントに含まれる情報／属性／エレメントの他、＠ｌｏｃａｔｉｏｎ情報をさらに含むことができる。

＠ｌｏｃａｔｉｏｎ情報は、ｓｏｕｒｃｅｆｌｏｗのデータを伝送する位置又はデータユニットを示す情報である。＠ｌｏｃａｔｉｏｎ情報は、放送ストリーム内でデータパイプを識別し、受信機は。当該データパイプを介して、ｓｏｕｒｃｅｆｌｏｗのデータが伝送されることが把握できる。

ＳｏｕｒｃｅＦｌｏｗエレメントに含まれる他の情報／属性／エレメントに関する説明は、前述したＳｏｕｒｃｅＦｌｏｗエレメントに関する説明に代える。

図１０３は、本発明の他の実施例に係る、シグナリング情報を放送網を介して取得する過程を示す図である。

受信機は、ＦＩＣに含まれるサービスを識別する情報を用いて、受信機の所望の放送サービスと関連したサービスシグナリングチャネルのデータが伝送される位置に接近することができる。

受信機は、ＦＩＣから、サービスシグナリングチャネルのデータを伝送するＩＰデータグラムソースＩＰアドレス、デスティネーションＩＰアドレス及び／又はＵＤＰポート番号に関する情報を取得する。

受信機はＦＩＣから、サービスシグナリングチャネルのデータを含むデータパイプを識別する情報を取得する。受信機は、当該情報を用いて、サービスシグナリングチャネルのデータが伝送されるデータパイプに接近することができる。

受信機は、ＦＩＣに含まれた、サービスシグナリングチャネルのデータを伝送するＬＣＴセッションを識別する情報を用いて、当該ＬＣＴセッションに接近することができる。又は、サービスシグナリングチャネルのデータを伝送するＬＣＴセッションは、特定ＴＳＩを有するＬＣＴセッションに固定されてもよく、この場合、受信機は別途の情報無しにも、サービスシグナリングチャネルのデータを得るために、特定ＴＳＩを有するＬＣＴセッションに接近することができる。受信機は、当該位置に接近して、サービスシグナリングチャネルのデータを取得することができる。

受信機は、前述したＬＳＩＤを伝送するＬＣＴセッションに接近することができる。この場合、ＬＳＩＤを伝送するＬＣＴセッションのＴＳＩは固定されていていもよく、受信機は、当該ＴＳＩを有するＬＣＴセッションに接近し、ＬＳＩＤを取得することができる。受信機は、ＬＳＩＤの情報を用いて、放送サービスに含まれるコンポーネントを取得することができる。

図１０４は、本発明の他の実施例に係る、シグナリング情報を放送網及びブロードバンド網を介して取得する過程を示す図である。

受信機は、ＦＩＣに含まれるサービスを識別する情報を用いて、受信機の所望する放送サービスに関連したサービスシグナリングチャネルのデータが伝送される位置に接近することができる。

受信機はＦＩＣから、サービスシグナリングチャネルのデータを伝送するＩＰデータグラムソースＩＰアドレス、デスティネーションＩＰアドレス及び／又はＵＤＰポート番号に関する情報を取得する。

受信機は、サービスシグナリングチャネルのデータに接近して、前述したＵＲＬシグナリングテーブル又はＵＲＬシグナリングディスクリプションを取得する。受信機は、ＵＲＬシグナリングテーブルに含まれる情報を用いて、サービスレベルシグナリングを提供するサーバー又は位置に接近し、ブロードバンド網を介してサービスレベルシグナリングを取得することができる。

図１０５は、本発明の他の実施例に係る、シグナリング情報をブロードバンド網を介して取得する過程を示す図である。

受信機は、ＦＩＣに含まれる、サービスシグナリングチャネルの伝送タイプを識別する情報が、サービスシグナリングチャネルのデータがブロードバンド網を介して伝送されることを示す場合、ＦＩＣ内でサービスシグナリングチャネルのデータを提供するサーバー又は位置に対するＵＲＬ情報を取得する。この場合、ＵＲＬ情報は、サービスシグナリングチャネルのデータ全体を提供する一つのサーバー又は位置に対するＵＲＬを示したり、サービスシグナリングチャネルに含まれ得るそれぞれのシグナリング構造（ＳＭＴ、ＭＰＤ、ＣＭＴなど）を提供するそれぞれのサーバー又は位置のＵＲＬを示すことができる。

受信機は、当該ＵＲＬ情報が示すサーバー又は位置に接近し、ブロードバンド網でサービスシグナリングチャネルのデータを取得する。

図１０６は、本発明の他の実施例に係る、ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）を放送網を介して取得する過程を示す図である。

受信機は、ＦＩＣに含まれるサービスのカテゴリーを識別する情報から、放送サービスがＥＳＧに該当することを認識し、当該サービスに対するサービスシグナリングチャネルのデータを伝送するデータパイプを識別する情報を取得することができる。

受信機は、識別されたデータパイプに接近して、当該データパイプで伝送されるＥＳＧのデータを取得することができる。

このような過程を用いて、ＥＳＧを放送サービスとして取扱うが、一般的な放送サービスに接近するために複雑なシグナリング構造を解釈しなくて済み、ＥＳＧの取得をより効率的に行うことができる。

図１０７は、本発明の他の実施例に係る、放送サービスのビデオセグメント及びオーディオセグメントを放送網を介して取得する過程を示す図である。

受信機は、サービスシグナリングチャネルのデータを取得し、サービスシグナリングチャネルのデータに含まれる、放送サービスのコンポーネントを説明する情報を含むシグナリング構造（例えば、ＣＭＴ）を取得する。

当該シグナリング構造から、受信機は、放送サービスのビデオコンポーネントを伝送するデータパイプを識別する情報を取得し、当該情報を用いて、データパイプに接近する。受信機は、当該データパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を取得する。

受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのビデオコンポーネントを伝送するＬＣＴセッションに接近して、ビデオコンポーネントを取得する。

受信機は、放送サービスのオーディオコンポーネントを伝送するデータパイプを識別する情報を取得し、当該情報を用いて、データパイプに接近する。受信機は、当該データパイプを伝送するＲＯＵＴＥセッション内のＬＣＴセッションを説明するシグナリング構造（例えば、ＬＳＩＤ）を取得する。

受信機は、ＬＣＴセッションを説明するシグナリング構造から、放送サービスのオーディオコンポーネントを伝送するＬＣＴセッションに接近して、オーディオコンポーネントを取得する。

本発明によれば、前述したシグナリング構造を用いて、放送サービスに含まれるそれぞれのコンポーネントがそれぞれの伝送経路を介して伝送される場合にも、当該コンポーネントを効率的に探して取得できる効果がある。また、送信端では、余裕がある領域を介して、自由に放送サービスのコンポーネントを伝送することができ、したがって、より多い放送データを効率的に伝送できるという効果がある。

図１０８は、本発明の他の実施例に係る、放送サービスのビデオセグメントは放送網を介して取得し、放送サービスのオーディオセグメントはブロードバンド網を介して取得する過程を示す図である。

一方、受信機は、放送サービスのコンポーネントを説明する情報を含むシグナリング構造から、オーディオコンポーネントがブロードバンドで伝送されることを認識し、当該オーディオコンポーネントを伝送するサーバー又は位置のアドレスを取得する。又は、受信機は、ＭＰＤを用いて、当該オーディオコンポーネントのセグメントを提供するアドレスを取得し、当該アドレスから、オーディオコンポーネントのセグメントを取得する。

前述したシグナリング構造を用いて、本発明によれば、異種網を介して、一つの放送サービスに属するコンポーネントがそれぞれ伝送される場合にも、当該放送サービスのためのコンポーネントに効率的に接近できるという効果がある。

図１０９は、本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。

本発明の一実施例は、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅの伝送及び／又はシグナリング方案を提供することができる。本発明の一実施例に係るｃｌｏｃｋｒｅｆｅｒｅｎｃｅは、次世代放送システムで伝送されるコンテンツ及びサービスを受信機で同期化して消費できるようにする基準時間を提供することができる。

本発明の一実施例に係るｃｌｏｃｋｒｅｆｅｒｅｎｃｅは、連続的で周期的なｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値を含むことができる。ｃｌｏｃｋｒｅｆｅｒｅｎｃｅは、シグナリングメッセージ及び／又は独立したストリームの形態で伝送されてもよい。ここで、上述したシグナリングメッセージは、シグナリング情報と同一であってもよく、上述したシグナリングメッセージは、ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ（ＦＩＣ）、ＳｅｒｖｉｃｅＭａｐＴａｂｌｅ（ＳＭＴ）などを含むことができる。ここで、上述したＦＩＣは、ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ（ＳＬＴ）と同一であってもよく、ＳＭＴは、ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ（ＵＳＤ）と同一であってもよい。

本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅが独立したストリームの形態で伝送される場合、受信機がｃｌｏｃｋｒｅｆｅｒｎｃｅに接近するための情報を提供することができる。後述する、本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅがシグナリングメッセージを介して直接伝送される場合、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値を提供することができる。

本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅは、フィジカルレイヤに含まれて伝送されてもよく、ｐｈｙｓｉｃａｌｆｒａｍｅのｐｒｅａｍｂｌｅ及び／又はｂａｓｅＰＬＰ部分に含まれて伝送されてもよい。ｃｌｏｃｋｒｅｆｅｒｅｎｃｅは、送信機と受信機の時間を同期化するために必要な情報であり、エラーを減らすために比較的剛健性の高いフィジカルレイヤに含まれてもよい。

本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｂｉｎａｒｙｆｏｒｍａｔ、ＸＭＬなどの様々な形式で表現されてもよい。本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、シグナリングメッセージ内の様々な位置に存在してもよい。ここで、上述したシグナリングメッセージは、ローレベルシグナリングメッセージ（ｌｏｗｌｅｖｅｌｓｉｇｎａｌｉｎｇ）、サービスレベルシグナリングメッセージ（ｓｅｒｖｉｃｅｌｅｖｅｌｓｉｇｎａｌｉｎｇ）を含むことができる。ここで、上述したローレベルシグナリングメッセージは、ＳＬＴ、ＲＲＴ（ＲａｔｉｎｇＲｅｇｉｏｎＴａｂｌｅ）などを含むことができ、上述したサービスレベルシグナリングメッセージは、ＵＳＢＤ／ＵＳＤ（ＵｓｅｒＳｅｒｖｉｃｅＢｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎ／ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）、ＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）などを含むことができる。ここで、上述したＳＬＴは、ＦＩＣ及び／又はＰＡＴと同一であってもよく、上述したＵＳＢＤ／ＵＳＤはＳＭＴと同一であってもよい。

本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＴＳＩ＿ｆｌａｇフィールド、ＤＰ＿ＩＤ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＴＳＩ＿ｆｌａｇフィールド、ＤＰ＿ＩＤ＿ｆｌａｇフィールド、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＴＳＩフィールド及び／又はＤＰ＿ＩＤフィールドを含むことができる。

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、固有値が割り当てられることによって当該ｄｅｓｃｒｉｐｔｏｒがｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒであることを識別することができる。

ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、当該ｄｅｓｃｒｉｐｔｏｒの長さをバイト数で示すことができる。

ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰａｄｄｒｅｓｓの形式を示すことができる。このフィールドの値が０の場合にはＩＰｖ４を、１の場合にはＩＰｖ６アドレス形式が用いられることを示すことができる。

ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、このディスクリプタがｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このディスクリプタはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むことができる。

ＴＳＩ＿ｆｌａｇフィールドは、このディスクリプタがＴＳＩフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このディスクリプタはＴＳＩフィールドを含むことができる。

ＤＰ＿ＩＤ＿ｆｌａｇフィールドは、このディスクリプタがＤＰ＿ＩＤフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このディスクリプタはＤＰ＿ＩＤフィールドを含むことができる。

ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ここで、上述したｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅが独立したストリームとして伝送される場合にｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームを示すことができる。

ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。

ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。

ＴＳＩフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＬＣＴｓｅｓｓｉｏｎなどのｓｅｓｓｉｏｎｉｄｅｎｔｉｆｉｅｒを示すことができる。

ＤＰ＿ＩＤフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍが伝送されるデータパイプのｉｄｅｎｔｉｆｉｅｒを示すことができる。ここで、ｄａｔａｐｉｐｅはｐｈｙｓｉｃａｌｌａｙｅｒｐｉｐｅと同一であってもよい。

図１１０は、本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの構成を示す図である。

本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅがシグナリングメッセージを介して直接伝送される場合、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値を提供することができる。

本発明の一実施例に係るｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールド及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを含むことができる。

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、固有値が割り当てられることによって、当該ｄｅｓｃｒｉｐｔｏｒがｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒであることを識別することができる。

ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドは、後続するｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドの形式を示すことができる。本発明の一実施例によれば、このフィールドの値が０の場合に３２ビットのＮＴＰｔｉｍｅｓｔａｍｐ、１の場合に６４ビットのＮＴＰｔｉｍｅｓｔａｍｐ、２の場合に８０ビットのＰＴＰｔｉｍｅｓｔａｍｐが用いられてもよい。

ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドによって定められたｔｉｍｅｓｔａｍｐ形式で表現されるｃｌｏｃｋｒｅｆｅｒｅｎｃｅの値を示すことができる。本発明の一実施例によれば、このフィールドは、送信端の現在時間、このｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒの生成時間などを示すことができる。本発明の一実施例によれば、このフィールドは、送信端と受信端とのｓｙｓｔｅｍｃｌｏｃｋ同期化に用いられてもよい。

図１１１は、本発明の一実施例に係るＦＩＣの構成を示す図である。

本発明の一実施例によれば、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌｌｅｖｅｌ、ｐａｒｔｉｔｉｏｎｌｅｖｅｌ及び／又はｓｅｒｖｉｃｅｌｅｖｅｌで伝送されてもよい。

本発明の一実施例によれば、一つのｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌで一つのｃｌｏｃｋｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、上述したｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌを介して伝送される全てのコンテンツ及びサービスがこのｃｌｏｃｋｒｅｆｅｒｅｎｃｅを介して同期化されてもよい。

本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、前述したＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分に位置してもよい。すなわち、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌｌｅｖｅｌで伝送されてもよい。本発明の一実施例によれば、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅはストリーム形態で伝送され、受信機はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたｂｏｏｔｓｔｒａｐ情報を用いて、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅが伝送される当該ストリームに接近することができる。本発明の一実施例によれば、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ＦＩＣを介してｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値が直接伝送されてもよい。本発明の他の実施例によれば、ＦＩＣのＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒに代えてｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値そのものが位置してもよい。

本発明の他の実施例によれば、一つのｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌは複数のｐａｒｔｉｔｉｏｎに分けられてもよく、分けられた一つのｐａｒｔｉｔｉｏｎは一つのｂｒｏａｄｃａｓｔｅｒに割り当てられてもよい。本発明の一実施例によれば、一つのｐａｒｔｉｔｉｏｎで一つのｃｌｏｃｋｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、上述したｐａｒｔｉｔｉｏｎ内の全てのコンテンツ及びサービスがこのｃｌｏｃｋｒｅｆｅｒｅｎｃｅを介して同期化されてもよい。

本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、前述したＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分に位置してもよい。すなわち、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒは、ｐａｒｔｉｔｉｏｎｌｅｖｅｌで伝送されてもよい。本発明の一実施例によれば、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅはストリーム形態で伝送され、受信機は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたｂｏｏｔｓｔｒａｐ情報を用いて、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅが伝送される当該ストリームに接近することができる。本発明の一実施例によれば、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒが位置する場合、ＦＩＣを介してｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値が直接伝送されてもよい。本発明の他の実施例によれば、ＦＩＣのｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ部分にｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒに代えてｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値そのものが位置してもよい。

本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールド、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールド及び／又はＦＩＣ＿ｌｅｖｅｌ＿ディスクリプタを含むことができる。

ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ＦＩＣのバージョンを示すことができる。

ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドは、ｂｒｏａｄｃａｓｔｓｔｒｅａｍを識別することができる。

ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールドは、ｂｒｏａｄｃａｓｔｓｔｒｅａｍ内に含まれたｐａｒｔｉｔｉｏｎの個数を示すことができる。ここで、ｐａｒｔｉｔｉｏｎは放送局を示すことができる。

ｐａｒｔｉｔｉｏｎ＿ｉｄフィールドは、ｐａｒｔｉｔｉｏｎを識別することができる。

ｎｕｍ＿ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｐａｒｔｉｔｉｏｎレベルに含まれるディスクリプタの個数を示すことができる。

ｐａｒｔｉｔｉｏｎ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒは、ｐａｒｔｉｔｉｏｎレベルに含まれるディスクリプタを示すことができる。本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒがこのディスクリプタに含まれてもよい。

ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドは、ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌレベルに含まれるディスクリプタの個数を示すことができる。ここで、ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌレベルは、ＦＩＣ及び／又はｂｒｏａｄｃａｓｔｓｔｒｅａｍレベルと同一であってもよい。

ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒは、ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌレベルに含まれるディスクリプタを示すことができる。本発明の一実施例によれば、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒがこのディスクリプタに含まれてもよい。

図１１２は、本発明の他の実施例に係るＦＩＣの構成を示す図である。

本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅがｐａｒｔｉｔｉｏｎｌｅｖｅｌでストリーム形態で伝送される場合、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを一つのサービスに割り当て、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームに接近する情報をシグナリングすることができる。

本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームは、ｐａｒｔｉｔｉｏｎを構成する一つのサービスで伝送されてもよい。本発明の一実施例によれば、サービスがｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームを伝送するか否かは、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドでシグナリングでき、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドにｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームのための特定値が割り当てられてもよい。本発明の一実施例によって、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドから、当該サービスがｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームを伝送するサービスであることが識別されると、後続するＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＳＣ＿ＴＳＩフィールド及び／又はＳＳＣ＿ＤＰ＿ＩＤフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームに接近するためのｂｏｏｔｓｔｒａｐ情報として活用されてもよい。

本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールド、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールド、ｎｕｍ＿ｐａｒｔｉｔｉｏｎｓフィールド、ｐａｒｔｉｔｉｏｎ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールド、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールド、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＳＣ＿ＴＳＩフィールド及び／又はＳＳＣ＿ＤＰ＿ＩＤフィールドを含むことができる。

ｓｅｒｖｉｃｅ＿ｉｄフィールドは、このサービスがｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームを含むサービスであることを識別することができる。

ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、サービスのタイプを示すが、本発明の一実施例に係るサービスがｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームを伝送するサービスであることを識別するために用いられてもよい。

ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、後続するＩＰａｄｄｒｅｓｓの形式を示すことができる。このフィールドの値が０である場合にＩＰｖ４、１である場合にＩＰｖ６アドレス形式が用いられることを示すことができる。

ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドは、このサービスがｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むか否かを示すことができる。このフィールドの値が１である場合、このサービスはｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドを含むことができる。

ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＩＰｄａｔａｇｒａｍのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。ここで、上述したｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅが独立したストリームで伝送される場合に、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームを示すことができる。

ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＩＰｄａｔａｇｒａｍのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。

ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＩＰｄａｔａｇｒａｍのＵＤＰｐｏｒｔｎｕｍｂｅｒを示すことができる。

ＳＳＣ＿ＴＳＩフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍを含むＬＣＴｓｅｓｓｉｏｎなどのｓｅｓｓｉｏｎｉｄｅｎｔｉｆｉｅｒを示すことができる。

ＳＳＣ＿ＤＰ＿ＩＤフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅｓｔｒｅａｍが伝送されるデータパイプのｉｄｅｎｔｉｆｉｅｒを示すことができる。ここで、ｄａｔａｐｉｐｅはｐｈｙｓｉｃａｌｌａｙｅｒｐｉｐｅと同一であってもよい。

図１１３は、本発明の一実施例に係るＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎの構成を示す図である。

本発明の一実施例によれば、一つのサービスで一つのｃｌｏｃｋｒｅｆｅｒｅｎｃｅのシーケンスが伝送される場合、サービス内の全てのコンテンツ及びストリームがこのｃｌｏｃｋｒｅｆｅｒｅｎｃｅを介して同期化されてもよい。

本発明の一実施例は、一つのサービスに該当するｃｌｏｃｋｒｅｆｅｒｅｎｃｅのブートストラップ情報を伝送することができる。ここで、ブートストラップ情報は、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームに接近するための情報を示すことができる。

本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値のシーケンスは、別途のｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームとして構成されて、当該ストリームパケットのペイロードを介して伝送されたり、コンポーネントを伝送するストリームパケットのヘッダーに含まれて伝送されてもよい。

本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値が、コンポーネントを伝送するストリームパケットのヘッダーに含まれて伝送される場合、ＬＣＴｐａｃｋｅｔｈｅａｄｅｒのＥＸＴ＿ＴＩＭＥｅｘｔｅｎｓｉｏｎを用いてｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値を伝送することができる。

本発明の一実施例によれば、一つのサービスを構成する内部のストリームを介してｃｌｏｃｋｒｅｆｅｒｅｎｃｅが伝送される時、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームは、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドによって識別されてもよい。＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドは、ＲＯＵＴＥｓｅｓｓｉｏｎを構成するＬＣＴｓｅｓｓｉｏｎのうち、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するＬＣＴｓｅｓｓｉｏｎのＴＳＩ情報を示すことができる。本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームのＩＰａｄｄｒｅｓｓ及びＵＤＰｐｏｒｔ情報は、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドの前に存在するＲＯＵＴＥＳｅｓｓｉｏｎ内部の他のフィールドによって識別されてもよい。本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームを伝送するＤＰに対する情報は、前述したＬＳＩＤ及びＣＭＴを介してシグナリングされてもよい。ここで、ＬＳＩＤは、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）と同一であってもよく、ＣＭＴは、ＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）と同一であってもよい。

本発明の他の実施例は、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｉｏｎにＣｌｏｃｋＲｅｆｅｒｅｎｃｅＢｏｏｔｓｔｒａｐフィールドを含めることによって、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームに接近するための情報をシグナリングすることができる。本発明の一実施例に係る、ＣｌｏｃｋＲｅｆｅｒｅｎｃｅＢｏｏｔｓｔｒａｐフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒのように、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰａｄｄｒｅｓｓ、ＵＤＰｐｏｒｔ、ＴＳＩ、ＤＰなどの情報を含むことができる。

同図で示すＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールド及びＣｌｏｃｋＲｅｆｅｒｅｎｃｅＢｏｏｔｓｔｒａｐフィールドの両方を含んでいるが、本発明の一実施例によれば、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、上述した両フィールドのいずれか一つのみを含んでもよく、両フィールドのいずれか一つを用いてｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームに接近するための情報（ｂｏｏｔｓｔｒａｐ情報）をシグナリングすることもできる。

本発明の一実施例に係るＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、ＵＳＢＤ／ＵＳＤと同一であってもよく、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、＠ｓｅｒｖｉｃｅ＿ｉｄフィールド、＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールド、＠ｓｅｒｖｉｃｅ＿ｎａｍｅフィールド、＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールド、＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールド、＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールド、＠ＳＰ＿ｉｎｄｉｃａｔｏｒフィールド、ＲＯＵＴＥＳｅｓｓｉｏｎフィールド、＠ｓｏｕｒｃｅＩＰＡｄｄｒフィールド、＠ｄｅｓｔＩＰＡｄｄｒフィールド、＠ｄｅｓｔＵＤＰＰｏｒｔフィールド、＠ＬＳＩＤ＿ＤＰフィールド、＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールド、Ｔａｒｇｅｔｉｎｇフィールド、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙフィールド、ＲｉｇｈｔＩｓｓｕｅｒＳｅｒｖｉｃｅフィールド、ＣｕｒｒｅｎｔＰｒｏｇｒａｍフィールド、ＯｒｉｇｉｎａｌＳｅｒｖｉｃｅＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、ＣｏｎｔｅｎｔＬａｂｅｌｉｎｇフィールド、Ｇｅｎｒｅフィールド、Ｃａｐｔｉｏｎフィールド、Ｐｒｏｔｅｃｔｉｏｎフィールド及び／又はＣｌｏｃｋＲｅｆｅｒｅｎｃｅＢｏｏｔｓｔｒａｐフィールドを含むことができる。

＠ｓｅｒｖｉｃｅ＿ｉｄフィールドは、サービスを識別することができる。

＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙフィールドは、サービスのタイプを示すことができる。

＠ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドは、サービスの名前を示すことができる。

＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、サービスのチャネルナンバーを示すことができる。

＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓフィールドは、サービスのｓｔａｔｕｓを示すことができる。このフィールドは、当該サービスがａｃｔｉｖｅか又はｉｎａｃｔｉｖｅかを示すことができる。

＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎフィールドは、当該サービスが当該パーティションに全て含まれているか、当該パーティションに部分的に含まれているが、当該パーティションだけでプレゼンテーションが可能か、プレゼンテーションするために別のパーティションが必要か又はプレゼンテーションするために別の放送ストリームが要求されるかなどに関する情報を示すことができる。

＠ＳＰ＿ｉｎｄｉｃａｔｏｒフィールドは、当該サービスをなす一つ以上のコンポーネントがプロテクションされているか否かを示すことができる。すなわち、当該サービスがプロテクションされているか否かを示すことができる。

ＲＯＵＴＥＳｅｓｓｉｏｎフィールドは、当該サービスが伝送されるＲＯＵＴＥＳｅｓｓｉｏｎに関する情報を示すことができる。

＠ｓｏｕｒｃｅＩＰＡｄｄｒフィールドは、当該ＲＯＵＴＥＳｅｓｓｉｏｎのｓｏｕｒｃｅＩＰアドレスを示すことができる。

＠ｄｅｓｔＩＰＡｄｄｒフィールドは、当該ＲＯＵＴＥＳｅｓｓｉｏｎのｄｅｓｔｉｎａｔｉｏｎＩＰアドレスを示すことができる。

＠ｄｅｓｔＵＤＰＰｏｒｔフィールドは、当該ＲＯＵＴＥＳｅｓｓｉｏｎのｄｅｓｔｉｎａｔｉｏｎＵＤＰポートナンバーを示すことができる。

＠ＬＳＩＤ＿ＤＰフィールドは、当該ＲＯＵＴＥＳｅｓｓｉｏｎの伝送パラメータなどの情報を含むＬＳＩＤを伝達するｄａｔａｐｉｐｅを識別することができる。本発明の一実施例によれば、このフィールドは、ＲＯＵＴＥＳｅｓｓｉｏｎを構成する一つ以上のＬＣＴｓｅｓｓｉｏｎに関する情報を含むＬＳＩＤを識別することができる。

＠ＣｌｏｃｋＲｅｆ＿ＴＳＩフィールドは、ＲＯＵＴＥｓｅｓｓｉｏｎを構成するＬＣＴｓｅｓｓｉｏｎのうち、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するＬＣＴｓｅｓｓｉｏｎのＴＳＩ情報を示すことができる。

Ｔａｒｇｅｔｉｎｇフィールドは、当該サービスに対するｔａｒｇｅｔｉｎｇパラメータを示すことができる。このフィールドに関する詳細な説明は、前述したとおりである。

ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙフィールドは、当該サービス関連ｃｏｎｔｅｎｔａｄｖｉｓｏｒｙ情報を示すことができる。本発明の一実施例によれば、このフィールドは、ｃｏｎｔｅｎｔａｄｖｉｓｏｒｙｒａｔｉｎｇ関連情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。

ＲｉｇｈｔＩｓｓｕｅｒＳｅｒｖｉｃｅフィールドは、当該サービス関連ｒｉｇｈｔｉｓｓｕｅなどに関する情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。

ＣｕｒｒｅｎｔＰｒｏｇｒａｍフィールドは、現在プログラムなどに関する情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。

ＯｒｉｇｉｎａｌＳｅｒｖｉｃｅＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドは、元のサービスを識別する情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。

ＣｏｎｔｅｎｔＬａｂｅｌｉｎｇフィールドは、ｃｏｎｔｅｎｔｌａｂｅｌｉｎｇ関連情報を含むことができる。このフィールドに関する詳細な説明は、前述したとおりである。

Ｇｅｎｒｅフィールドは、当該サービスのジャンル情報を含むことができる。

Ｃａｐｔｉｏｎフィールドは、当該サービスのキャプション関連情報を含むことができる。

Ｐｒｏｔｅｃｔｉｏｎフィールドは、当該サービスのｐｒｏｔｅｃｔｉｏｎ関連情報を含むことができる。

ＣｌｏｃｋＲｅｆｅｒｅｎｃｅＢｏｏｔｓｔｒａｐフィールドは、前述したｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒのように、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰａｄｄｒｅｓｓ、ＵＤＰｐｏｒｔ、ＴＳＩ、ＤＰなどの情報を含むことができる。すなわち、このフィールドは、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅストリームに接近するための情報を含むことができる。

図１１４は、本発明の一実施例に係るＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎの構成を示す図である。

本発明の一実施例は、前述したＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎに＠ｃｌｏｃｋＲｅｆＦｌａｇフィールドを追加して、現在の放送ストリーム又は他の放送ストリームを介して伝送されるストリームのうち、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームを識別することができる。本発明の一実施例によれば、＠ｃｌｏｃｋＲｅｆＦｌａｇフィールドがフィールド値１を有する場合、当該コンポーネントがｃｌｏｃｋｒｅｆｅｒｅｎｃｅを含んで伝送することを示すことができる。

本発明の一実施例によれば、一つのサービスを介して伝送されるコンポーネントのうち、＠ｃｌｏｃｋＲｅｆＦｌａｇフィールド値として１を有するコンポーネントの個数は、最大１個に制約し得る。

本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームのＴＳＩ及びＤＰ情報は、先に登場するＢｒｏａｄｃａｓｔＣｏｍｐフィールドの下位フィールドによって識別することができ、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームのＩＰａｄｄｒｅｓｓとＵＤＰｐｏｒｔ情報は、前述したＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎのＲＯＵＴＥＳｅｓｓｉｏｎフィールドの下位フィールド及びＬＳＩＤで提供される情報を用いて識別することができる。本発明の一実施例によれば、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅを伝送するストリームが他の放送ストリームを介して伝送される場合、ＦｏｒｉｇｎＣｏｍｐフィールドの下位フィールドを用いてそれを識別することができる。

同図に示すフィールドに関する詳細な説明は、前述したとおりである。

図１１５は、本発明の一実施例に係る放送信号送信方法を示す図である。

本発明の一実施例に係る放送信号送信方法は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報をエンコーディングする段階（ＳＬ１２８０１０）、エンコーディングされた放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を含む放送信号を生成する段階（ＳＬ１２８０２０）、及び／又は放送信号を伝送する段階（ＳＬ１２８０３０）を有することができる。ここで、上述した放送サービスは、ＡＴＳＣ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。

本発明の他の実施例によれば、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報のうち少なくとも一つは、送信側と受信側との時間的同期化のための時間情報を含むことができる。ここで、上述した時間情報は、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅ、ｃｌｏｃｋｒｅｆｅｒｅｎｃｅ値及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｄｅｓｃｒｉｐｔｏｒを表すことができる。これに関する詳細な説明は、図１１０、図１１１で前述した。

本発明の他の実施例によれば、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報のうち少なくとも一つは、送信側と受信側との時間的同期化のための時間情報を伝送するストリームに接近するための接近情報を含むことができる。ここで、上述した接近情報は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｂｏｏｔｓｔｒａｐ＿ｄｅｓｃｒｉｐｔｏｒに含まれたフィールドを表すことができる。これに関する詳細な説明は、図１０９、図１１１、図１１３で前述した。

本発明の他の実施例によれば、時間情報は、送信側と受信側との時間的同期化に用いられる基準時間値及び／又は基準時間値のタイプを示す情報を含むことができる。ここで、上述した基準時間値は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを表すことができ、上述した基準時間値のタイプを示す情報は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドを表すことができる。これに関する詳細な説明は図１１０で前述した。

本発明の他の実施例によれば、接近情報は、時間情報を伝送するストリームを含むＩＰデータグラム目的地ＩＰアドレス情報、時間情報を伝送するストリームを含むＩＰデータグラムＵＤＰポートナンバー、時間情報を伝送するストリームを含むセッションを識別する情報、及び／又は時間情報を伝送するストリームが伝送されるデータパイプを識別する情報を含むことができる。これに関する詳細な説明は図１０９で前述した。

本発明の他の実施例によれば、第１シグナリング情報は、一つの放送ストリームで伝送される一つ以上のサービスに関する情報を含み、時間情報は、第１シグナリング情報のサービスレベルに含まれて一つのサービス内の全てのコンポーネントの同期化のために用いられてもよい。これに関する詳細な説明は、図１１２、図１１３、図１１４で前述した。

本発明の他の実施例によれば、放送サービスは、送信側と受信側との時間的同期化のための時間情報を提供する放送サービスに該当し、第１シグナリング情報は、放送サービスに接近するための情報を含むことができる。これに関する詳細な説明は図１１２で前述した。

図１１６は、本発明の一実施例に係る放送信号受信方法を示す図である。

本発明の一実施例に係る放送信号受信方法は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報を含む放送信号を受信する段階（ＳＬ１２９０１０）、受信した放送信号から放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を抽出する段階（ＳＬ１２９０２０）、及び／又は抽出された放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報をデコーティングする段階（ＳＬ１２９０３０）を有することができる。ここで、上述した放送サービスは、ＡＴＳＣ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。

本発明の他の実施例によれば、時間情報は、送信側と受信側との時間的同期化に用いられる基準時間値及び／又は基準時間値のタイプを示す情報を含むことができる。ここで、上述した基準時間値は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅフィールドを表すことができ、上述した基準時間値のタイプを示す情報は、ｃｌｏｃｋ＿ｒｅｆｅｒｅｎｃｅ＿ｖａｌｕｅ＿ｖｅｒｓｉｏｎフィールドを表すことができる。これに関する詳細な説明は、図１１０で前述した。

本発明の他の実施例によれば、接近情報は、時間情報を伝送するストリームを含むＩＰデータグラム目的地ＩＰアドレス情報、時間情報を伝送するストリームを含むＩＰデータグラムＵＤＰポートナンバー、時間情報を伝送するストリームを含むセッションを識別する情報及び／又は時間情報を伝送するストリームが伝送されるデータパイプを識別する情報を含むことができる。これに関する詳細な説明は図１０９で前述した。

図１１７は、本発明の一実施例に係る放送信号送信装置の構成を示す図である。

本発明の一実施例に係る放送信号送信装置（Ｌ１３００１０）は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報をエンコーディングするエンコーダ（Ｌ１３００２０）、エンコーディングされた放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を含む放送信号を生成する生成部（Ｌ１３００３０）、及び／又は放送信号を伝送する伝送部（Ｌ１３００４０）を含むことができる。ここで、上述した放送サービスは、ＡＴＳＣ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。

図１１８は、本発明の一実施例に係る放送信号受信装置の構成を示す図である。

本発明の一実施例に係る放送信号受信装置（Ｌ１３１０１０）は、放送サービス、放送サービスの速い取得のための第１シグナリング情報、放送サービスの発見のための第２シグナリング情報、及び放送サービス及び放送サービスが含むコンポーネントが伝送されるセッションのための第３シグナリング情報を含む放送信号を受信する受信部（Ｌ１３１０２０）、受信した放送信号から、放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報を抽出する抽出部（Ｌ１３１０３０）、及び／又は抽出された放送サービス、第１シグナリング情報、第２シグナリング情報及び第３シグナリング情報をデコーティングするデコーダ（Ｌ１３１０４０）を含むことができる。ここで、上述した放送サービスはＡＴＳＣ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。ここで、上述した放送サービスはＡＴＳＣ３．０サービスを表すことができる。上述した第１シグナリング情報は、前述したＦＩＣ及び／又はＳＬＴを表すことができる。上述した第２シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ及び／又はＵＳＤ／ＵＳＢＤを表すことができる。上述した第３シグナリング情報は、前述したＳＭＴ、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ、ＬＳＩＤ及び／又はＳ−ＴＳＩＤを表すことができる。

図１１９は、本発明の一実施例に係る、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝達される場合において、そのサービスディスクリプション情報を示す図である。

本発明はセッションディスクリプション情報が、伝送セッション外部経路を介して伝送される方法を提案する。ここで、セッションディスクリプション情報は、当該伝送セッションの伝送特性やプロトコル、パケット構造などの情報を含むことができる。実施例によって、セッションディスクリプション情報は、前述したＬＳＩＤに該当し得る。また、セッションディスクリプション情報は、前述したＳ−ＴＳＩＤのうち、複数個のＬＳエレメントに該当する情報であってもよい。この場合、ここでのサービスディスクリプション情報は、Ｓ−ＴＳＩＤに該当し得る。

このセッションディスクリプション情報は、当該伝送セッションを介して伝達されたり、又は伝送セッション外部経路を介して受信機に伝達されてもよい。また、セッションディスクリプション情報は、他のシグナリングメッセージに含まれて伝送されたり、当該伝送セッションの内／外部に存在するサービスシグナリングチャネルなどの経路を介して伝送されてもよい。サービスシグナリングチャネルを介して伝送される場合、セッションディスクリプション情報は、他のシグナリングメッセージと併せて伝送されてもよい。

まず、セッションディスクリプション情報が他のシグナリングメッセージに含まれて伝送される場合を説明する。

セッションディスクリプション情報は、前述した他のシグナリングメッセージに含まれて伝送されてもよい。他のシグナリングメッセージとしてはＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤ、ＳＭＴ，ＣＭＴなどを挙げることができる。図示の実施例では、セッションディスクリプション情報がサービスディスクリプション情報に含まれている。ここで、サービスディスクリプション情報は、前述したＳＭＴ乃至Ｓ−ＴＳＩＤに該当し得る。

ここで、セッションディスクリプション情報は、サービスディスクリプション情報のＬＳＩＤエレメントに含まれてもよい。ここで、ＬＳＩＤエレメントは、サービスディスクリプション情報のＲＯＵＴＥｓｅｓｓｉｏｎエレメントの下位エレメントであってもよい。セッションディスクリプション情報は、当該ＲＯＵＴＥｓｅｓｓｉｏｎエレメントが示すＲＯＵＴＥセッション（伝送セッション）のセッション情報を含むことができる。当該ＲＯＵＴＥセッションを、ＲＯＵＴＥｓｅｓｓｉｏｎエレメントの＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔ、などの情報によって示すことができる。このようにセッションディスクリプション情報がサービスディスクリプション情報に直接含まれて伝送される場合、セッションディスクリプション情報が記述する伝送セッションでは、セッションディスクリプション情報が伝達されなくてもよい。これは重複を避けるためである。

サービスディスクリプション情報内部の各エレメントは、前述したとおりである。

＠ｓｅｒｖｉｃｅ＿ｉｄは、当該サービスディスクリプション情報が記述するサービスの識別子を示すことができる。＠ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙは、当該サービスのカテゴリーを示すことができる。＠ｓｅｒｖｉｃｅ＿ｎａｍｅは、当該サービスの名前を示すことができる。＠ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒは、当該サービスと関連したチャネルナンバー情報を示すことができる。＠ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓは、当該サービスの状態情報を示すことができる。＠ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎは、当該サービスのディストリビューション関連情報を示すことができる。＠ＳＰ＿ｉｎｄｉｃａｔｏｒは、当該サービスが保護（ｐｒｏｔｅｃｔｉｏｎ）されているかを示すことができる。ここで、当該サービスのサービスコンポーネントのうち少なくとも一つでも保護されていると、当該サービスが保護されていると示すこができる。

ＲＯＵＴＥｓｅｓｓｉｏｎエレメントは、当該サービス又はサービスコンポーネントが伝達されるＲＯＵＴＥｓｅｓｓｉｏｎに関する情報を含むことができる。ＲＯＵＴＥｓｅｓｓｉｏｎエレメントは、サービスディスクリプション情報内に複数個存在してもよい。＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔはそれぞれ、当該ＲＯＵＴＥパケットを伝送するＩＰデータグラムソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションＰｏｒｔナンバー情報を含むことができる。すなわち、この情報は、当該ＲＯＵＴＥセッションを示すことができる。

＠ＬＳＩＤ＿ＤＰは、当該ＲＯＵＴＥセッションのセッションディスクリプション情報が伝達されるＤＰ（又は、ＰＬＰ）を識別することができる。ここで、当該ＲＯＵＴＥセッションは、ソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションＰｏｒｔナンバー情報によって識別されるＲＯＵＴＥセッションを意味できる。

＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤは、セッションディスクリプション情報を伝達するセッションディスクリプションテーブルの識別子であり、当該ＲＯＵＴＥセッションのセッションディスクリプション情報を有するセッションディスクリプションテーブルを識別することができる。このフィールドは、セッションディスクリプション情報がセッションディスクリプションテーブルに含まれて伝達される場合に活用されてもよい。セッションディスクリプションテーブルは、サービスシグナリングチャネルを介して他のシグナリングメッセージと共に伝送されてもよい。

＠ＬＳＩＤｕｒｌは、当該ＲＯＵＴＥセッションのセッションディスクリプション情報がブロードバンドで伝送される場合、その位置を識別するためのＵＲＬ情報を有することができる。このフィールドは、セッションディスクリプション情報がブロードバンドで伝送される場合に活用することができる。

Ｔａｒｇｅｔｉｎｇは、当該サービスに対するターゲッティングパラメータを示すことができる。すなわち、当該サービスが受信機又はコンパニオンデバイスのためのサービスであるかを識別することができる。ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙは、当該サービス関連コンテンツアドバイザリー情報、すなわち、当該サービスのレーティングに関連した情報を含むことができる。ＲｉｇｈｔＩｓｓｕｅｒＳｅｒｖｉｃｅは、当該サービスに関連した正当なイシュアー関連情報を含むことができる。ＣｕｒｒｅｎｔＰｒｏｇｒａｍは、現在プログラムに関する情報を含むことができる。ＯｒｉｇｉｎａｌＳｅｒｖｉｃｅＩｄｅｎｔｉｆｉｃａｔｉｏｎは、元のサービスに関する識別情報を含むことができる。ＣｏｎｔｅｎｔＬａｂｅｌｉｎｇ情報は、当該サービスのコンテンツラベリング情報を含むことができる。Ｇｅｎｒｅは、当該サービスのジャンル情報を含むことができる。Ｃａｐｔｉｏｎは、当該サービスのキャプション関連情報を含むことができる。Ｐｒｏｔｅｃｔｉｏｎは、当該サービスのプロテクションに関連した情報を含むことができる。

ここで、上記実施例に対して、伝送セッションがＲＯＵＴＥセッションである場合を挙げて説明したが、本発明がこれに限定されるわけではない。すなわち、ＭＭＴＰセッションなどの他の伝送セッションに対しても同じ方式で本実施例を適用することができる。

図１２０は、本発明の一実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報伝達のためのメッセージフォーマットを示す図である。

前述したように、セッションディスクリプション情報は、サービスシグナリングチャネルなどの経路を介して伝送されてもよい。この場合、セッションディスクリプション情報は、他のシグナリングメッセージと併せて伝送されてもよい。サービスシグナリングチャネルは、実施例によって別途の伝送セッションを介して伝達されてもよく、ＲＯＵＴＥセッションなどの伝送セッション内部の一つのサブセッションによって伝達されてもよい。ここで、サブセッションは、ＬＣＴセッションに該当し得る。

一つのサービスが複数個の伝送セッションに分けられて伝達される場合、複数個の伝送セッションに対するディスクリプション情報が必要となり得る。この場合、各伝送セッションに対するセッションディスクリプション情報がサービスシグナリングチャネルで伝送されてもよい。この時、それぞれの伝送セッションとセッションディスクリプションをマッピングする必要があり得る。このマッピングのために、前述した＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤ情報が活用されてもよい。この情報を用いて、サービスディスクリプション情報が示すＲＯＵＴＥセッションに対するセッションディスクリプション情報を取得することができる。これは、当該情報にマッピングされるセッションディスクリプションテーブルを識別することによって行うことができる。このようなマッピングは、セッションディスクリプション情報がサービスディスクリプション情報に含まれて伝送される場合には省略されてもよい。

実施例によって、サービスシグナリングチャネルは、ＳＬＳが伝送されるＲＯＵＴＥセッション内のＬＣＴセッションを意味できる。このＬＣＴセッションは、前述したようにＴＳＩ＝０に特定されていてもよい。

同図の実施例（ｔ２０１０）は、前述したシグナリングメッセージフォーマットを基本構造とし、セッションディスクリプション情報伝送のために拡張された構造を有するメッセージフォーマットであってもよい。セッションディスクリプション情報伝送のためにｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドをそれぞれＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎとＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤに分けて定義することができる。

ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは、このセッションディスクリプションテーブルのバージョン又はプロトコルバージョンを示すことができる。ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤは、本テーブルが送信しているセッションディスクリプション情報の識別子であり、前述したサービスディスクリプション情報内の＠ＬＳＩＤＩｎｓｔａｎｃｅＩＤと一致する値が用いられてもよい。これを用いて、ＲＯＵＴＥセッションとセッションディスクリプション情報間のマッピングを行うことができる。ＬＣＴ＿ｓｅｓｓｉｏｎ＿ｉｎｓｔａｎｃｅ＿ｄｅｓｃｒｉｐｔｉｏｎ（）には、セッションディスクリプション情報がバイナリ又はＸＭＬ形態で含まれてもよい。すなわち、セッションディスクリプション情報の実際データがここに含まれてもよい。その他、セッションディスクリプションテーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。

同図の他の実施例（ｔ２０２０）は、セッションディスクリプション情報伝達のためのセッションディスクリプションテーブルの他の実施例である。本実施例は、ＭＰＥＧ−２ＴＳプライベートセクション（ｐｒｉｖａｔｅｓｅｃｔｉｏｎ）ベースのフィールド構成を有することができる。ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤ、ＬＣＴ＿ｓｅｓｓｉｏｎ＿ｉｎｓｔａｎｃｅ＿ｄｅｓｃｒｉｐｔｉｏｎ（）の意味は、前述した実施例のそれと同一であってもよい。その他、セッションディスクリプションテーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。

図１２１は、本発明の一実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。

本実施例で、１つのサービスは２つのＲＯＵＴＥセッションを介して伝送されている。本実施例で、一番目のＲＯＵＴＥセッションのセッションディスクリプション情報は、当該ＲＯＵＴＥセッション（一番目のＲＯＵＴＥセッション）を介して伝送され、二番目のＲＯＵＴＥセッションのセッションディスクリプション情報は、二番目のＲＯＵＴＥセッションの外部経路であるサービスシグナリングチャネルを介して伝送されてもよい。ここで、サービスシグナリングチャネルは、一番目のＲＯＵＴＥセッション内部に位置してもよい。

本実施例で、各シグナリングメッセージ及び／又はサービスコンポーネントデータの取得手順について説明する。

まず、受信機は、ＦＩＣから、サービスシグナリングチャネルのブートストラップ情報を取得することができる。これを用いて、受信機は、サービスシグナリングチャネルに接近することができる。ＦＩＣのＩＰアドレス、ＵＤＰポート情報を用いて接近することができる。実施例によって、ＴＳＩ情報及び／又はＰＬＰＩＤ情報がさらに必要であってもよい。これは、前述したＳＬＴを用いてＳＬＳに接近することに対応し得る。この場合、ＳＬＴはＦＩＣに対応し、ＳＬＳを伝達するＬＣＴセッションはサービスシグナリングチャネルに対応し、ＳＬＳはサービスシグナリングチャネル内の情報に対応し得る。本実施例で、ＦＩＣは、フィジカル信号フレームの別途のチャネルを介して伝達されているが、ＳＬＴの場合は、ＩＰ／ＵＤＰを介してエンカプセレーションされてＰＬＰで伝達されてもよい。

その後、ブートストラップ情報を用いて接近したサービスシグナリングチャネルで、ＳＭＴの情報を取得することができる。ＳＭＴから、各ＲＯＵＴＥセッションに対するセッションディスクリプション情報を取得することができる。一番目のＲＯＵＴＥセッションに対するセッションディスクリプション情報は、＠ＬＳＩＤ＿ＤＰ情報を用いて取得することができる。＠ＬＳＩＤ＿ＤＰが示すＰＬＰに接近して一番目のＲＯＵＴＥセッションのセッションディスクリプション情報を取得することができる。二番目のＲＯＵＴＥセッションに対するセッションディスクリプション情報は、＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤ情報を用いて取得することができる。＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤが示すセッションディスクリプションテーブルが識別され、二番目のＲＯＵＴＥセッションのセッションディスクリプション情報を取得することができる。

これは、前述した実施例で、ＳＬＳを伝達するＲＯＵＴＥセッションのＬＣＴセッションに接近して、ＳＬＳの情報を取得する過程に対応し得る。ＳＬＳ情報から、セッションディスクリプション情報、すなわち、各伝送セッションのいかなるサブセッション（ＬＣＴセッションなど）を介してサービスコンポーネントが伝達されているかに関する情報を取得することができる。実施例によって、ＳＬＳのＳ−ＴＳＩＤ内のＬＳエレメントに関する情報が、このセッションディスクリプション情報に該当し得る。この場合の実施例では、別途のセッションディスクリプションテーブルがなくてもよい。また、セッションディスクリプション情報は、ＳＬＳに含まれて伝達されるので、同じＰＬＰを介して伝達され、よって、セッションディスクリプション情報が伝達されるＰＬＰに対する別途のＰＬＰＩＤ情報はなくてもよい。

その後、ＣＭＴから、各サービスコンポーネントのＰＬＰＩＤを取得することができる。既に取得したセッションディスクリプション情報を用いて、一番目／二番目のＲＯＵＴＥセッションの各ＴＳＩ情報を取得することができる。各ＴＳＩ情報は、当該サービスコンポーネントを伝達するＬＣＴセッションのＴＳＩ情報であってもよい。この情報を用い、各サービスコンポーネントを取得することができる。また、ＭＰＤから、各サービスコンポーネントのリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）ＩＤを取得することができる。

これは、前述した実施例で、ＳＬＳ内の情報（ＴＳＩなど）を用いて各ＬＣＴセッションに接近して各サービスコンポーネントを取得する過程に対応し得る。この場合の実施例で、Ｓ−ＴＳＩＤは、ＰＬＰＩＤ情報も含むことができるので、別途のＣＭＴはなくてもよい。Ｓ−ＴＳＩＤ内の各セッションディスクリプション情報を用いて、複数個のＲＯＵＴＥセッション内の複数個のＬＣＴセッションにそれぞれ接近することができる。収集されたサービスコンポーネントに対して、ＭＰＤからリプレゼンテーションＩＤを取得することができる。

図１２２は、本発明の他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。

本実施例で一つのサービスは２つのＲＯＵＴＥセッションを介して伝送されてもよい。本実施例で、一番目、二番目のＲＯＵＴＥセッションのセッションディスクリプション情報はいずれも、一番目のＲＯＵＴＥセッションを介して伝達されるサービスシグナリングチャネルで伝送されてもよい。

本実施例で、各シグナリングメッセージ及び／又はサービスコンポーネントデータの取得手順は、前述した実施例と同様である。ただし、本実施例では、両ＲＯＵＴＥセッションに対するセッションディスクリプション情報がいずれもセッションディスクリプションテーブルを介して伝達される。したがって、＠ＬＳＩＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤで識別される両セッションディスクリプションテーブルをまず取得した後、そのテーブル内のセッションディスクリプション情報を用いて、両ＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントに接近することができる。

この実施例も同様、前述したＳＬＴ−ＳＬＳを用いた実施例に対応し得る。ＳＬＴを用いて、ＳＬＳを伝達するチャネル／経路に接近すると、ＳＬＳ内の情報を用いて、当該サービスのサービスコンポーネントを伝達する経路に接近することができる。この場合、サービスコンポーネントを伝達する経路は、複数個のＲＯＵＴＥセッションにわたって存在してもよく、複数個のＲＯＵＴＥセッション内の複数個のＬＣＴセッションによって各サービスコンポーネントが伝達されてもよい。

図１２３は、本発明の更に他の実施例に係る、セッション外部経路を介したセッションディスクリプション情報伝送方法を示す図である。

本実施例で、各シグナリングメッセージ及び／又はサービスコンポーネントデータの取得手順は、前述した実施例と同様である。ただし、本実施例では、サービスシグナリングチャネルが特定ＲＯＵＴＥセッションの一つのＬＣＴセッションを介して伝達されず、別途のＰＬＰ（ＤＰ）、ＩＰ、ＵＤＰで識別される別途のチャネルで伝達されてもよい。この場合、全てのＲＯＵＴＥセッションに対してそのセッションディスクリプション情報が外部経路を介して伝達されることとなるので、サービスシグナリングチャネルは、各セッションに対するセッションディスクリプションテーブルを有することができる。セッションディスクリプションテーブル内のセッションディスクリプション情報を用いて、両ＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントに接近することができる。

この場合、サービスシグナリングチャネルが特定ＲＯＵＴＥセッションの一つのサブセッション（ＬＣＴセッションなど）を介して伝達されないことから、ＦＩＣ又はＳＬＴのブートストラッピング情報にはＴＳＩ情報が省かれてもよい。

図１２４は、本発明の一実施例に係る、初期化情報伝達のために拡張されたシグナリングメッセージを示す図である。

本発明は、前述した放送システムで、サービスのサービスコンポーネントと関連した初期化情報を伝達する方法を提案する。前述したように、各サービスのサービスコンポーネントは、ＤＡＳＨセグメントにフォーマットされてＤＡＳＨリプレゼンテーション形態で、ＬＣＴセッションを介して伝達されてもよい。このサービスコンポーネントのための初期化情報が必要となり得る。ここで、初期化情報は、ＤＡＳＨの初期化セグメント（ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔ）に該当し得る。

初期化情報は、伝送セッションの内／外部に存在するサービスシグナリングチャネルを介して伝送されたり、各ＬＣＴセッションでメディアデータと共に伝送されてもよい。ここで、メディアデータとは、メディアセグメントを意味することができる。

第一に、初期化情報がサービスシグナリングチャネルを介して伝送される場合、初期化情報は、他のシグナリングメッセージと併せて伝送されてもよい。一つのサービスが複数個のコンポーネントで構成されて伝送される場合、複数個の初期化情報が一つのシグナリングチャネルに含まれて伝送されてもよい。このとき、それぞれの初期化情報と各メディアデータ（サービスコンポーネント）がマッピングされる必要があり得る。

このマッピングのための識別子を定義することができ、これを＠ｉｓｄＩｎｓｔａｎｃｅＩＤと呼ぶこともできる。この情報は、初期化情報を含む初期化テーブルと各コンポーネントとをマッピングさせることができる。この初期化情報を用いて各サービスコンポーネントを初期化することができる。

同図に示すコンポーネントマッピングディスクリプション（ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎ）は、前述したとおりであるが、＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報をさらに有するように拡張された。＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報は、放送網を介したコンポーネントを示すＢｒｏａｄｃａｓｔＣｏｍｐエレメントの下部に位置して、当該コンポーネントにマッピングされる初期化情報を有する初期化テーブルを識別することができる。その他、コンポーネントマッピングディスクリプション内部のフィールドは、前述したとおりである。実施例によって、ＳＬＴ又はＳＬＳを構成するシグナリング情報のうち一つが、コンポーネントマッピングディスクリプションに代えて、＠ｉｓｄＩｎｓｔａｎｃｅＩＤ情報をさらに有するように拡張されてもよい。

第二に、初期化情報が各メディアデータ、すなわち、サービスコンポーネントと同じ経路を介して伝達されてもよい。すなわち、サービスコンポーネント（メディアセグメント）が伝達されるＬＣＴセッションを介して、当該コンポーネントに関連した初期化情報が共に伝達されてもよい。この時、当該データが一般的なメディアセグメントであるか又は初期化情報であるかは、伝送パケットのヘッダー情報を用いて区別することができる。このようなヘッダー情報としてはＴＯＩ値などを挙げることができる。

図１２５は、本発明の一実施例に係る、初期化情報伝達のためのメッセージフォーマットを示す図である。

ここで、初期化情報の伝達のためのメッセージフォーマットは、初期化テーブルのフォーマットを意味することができる。図示の実施例（ｔ７０１０）は、前述したシグナリングメッセージフォーマットを基本構造とし、初期化情報伝送のために拡張された構造を有するメッセージフォーマットであってもよい。初期化情報伝送のためにｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドをそれぞれＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎとＩＳＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤとに分けて定義することができる。

ＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは、この初期化テーブルのバージョン又はプロトコルバージョンを示すことができる。ＩＳＤＴ＿ｉｎｓｔａｎｃｅ＿ＩＤは、このテーブルが送信している初期化情報の識別子であり、前述した拡張されたシグナリング情報内の＠ｉｓｄＩｎｓｔａｎｃｅＩＤと一致する値が用いられてもよい。これを用いて、各サービスコンポーネントと初期化テーブル間のマッピングを行うことができる。このＩＤは、サービスシグナリングチャネル内でユニークに与えられてもよい。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａには初期化情報がバイナリ又はＸＭＬ形態で含まれてもよい。すなわち、初期化情報の全体又は一部のデータがここに含まれてもよい。その他、初期化テーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。

同図に示す他の実施例（ｔ７０２０）は、初期化情報の伝達のための初期化テーブルの他の実施例である。本実施例は、ＭＰＥＧ−２ＴＳプライベートセクション（ｐｒｉｖａｔｅｓｅｃｔｉｏｎ）ベースのフィールド構成を有することができる。ＩＳＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄａｔａ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａ）は、前述した実施例のそれと同一であってもよい。その他、初期化テーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。

Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｇｍｅｎｔ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａ構造の一実施例が示されている（ｔ７０３０）。このエレメントには、当該初期化情報のＵＲＬ情報である＠ｕｒｌと、初期化情報の実際データ部分であるＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔＤａｔａフィールドが含まれてもよい。ＵＲＬは、ＭＰＤに記述された初期化情報（Ｉｎｉｔｉａｌｉｚａｔｉｏｎｓｅｇｍｅｎｔ）のＵＲＬと同じ値を有することができる。このＵＲＬ情報は、個別の初期化情報とリプレゼンテーション間のマッピング情報として活用されてもよい。

図１２６は、本発明の他の実施例に係る、セッションディスクリプション情報がサービスシグナリングチャネルなどを介して伝達される場合において、セッションディスクリプション情報の伝達のためのメッセージフォーマットを示す図である。

前述したセッションディスクリプション情報伝送のためのセッションディスクリプションテーブルは、同図のような構造（ｔ８０１０）を有することもできる。ＬＳＩＤＴ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは、前述したとおりであり、ＬＳＩＤ＿ｄｅｌｉｖｅｒｙ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｄａｔａには、後述するＬＳＩＤＤｅｌｉｖｅｒｙＤｅｓｃｒｉｐｔｉｏｎの全体又は一部分に該当するデータがＸＭＬ又はバイナリ形態で含まれてもよい。ＬＳＩＤＤｅｌｉｖｅｒｙＤｅｓｃｒｉｐｔｉｏｎは、セッションディスクリプション情報伝達に関するディスクリプションであってもよい。その他、セッションディスクリプションテーブル内の情報は、前述したシグナリングメッセージフォーマットで説明したとおりにすればよい。

ＬＳＩＤＤｅｌｉｖｅｒｙＤｅｓｃｒｉｐｔｉｏｎ構造の一実施例が示されている（ｔ８０２０）。ＬＳＩＤＤｅｌｉｖｅｒｙＤｅｓｃｒｉｐｔｉｏｎは、＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔ及び／又はＬＳＩＤを含むことができる。＠ｓｏｕｒｃｅＩＰＡｄｄｒ、＠ｄｅｓｔＩＰＡｄｄｒ、＠ｄｅｓｔＵＤＰＰｏｒｔはそれぞれ、当該セッションディスクリプション情報が記述するＲＯＵＴＥセッションのソースＩＰ、デスティネーションＩＰ、デスティネーションＵＤＰポートナンバー情報を含むことができる。ＬＳＩＤは、当該セッションディスクリプション情報を有することができる。

図１２７は、本発明の一実施例に係る、サービスデータを処理する方法を示す図である。

本発明の一実施例に係るサービスデータを処理する方法は、放送サービスのサービスコンポーネントを生成する段階、第１シグナリングデータ及び第２シグナリングデータを生成する段階、伝送パケットにエンカプセレーションする段階、放送ストリームとしてプロセシングする段階、及び／又は放送ストリームを伝送する段階を含むことができる。ここで、サービスデータを処理する方法は、送信側の動作を基準に記述している。

まず、放送サービスのサービスコンポーネントが生成され得る（ｔ９０１０）。サービスは、一つ以上のサービスコンポーネントを含むことができる。また、第１シグナリングデータ及び／又は第２シグナリングデータが生成されてもよい（ｔ９０２０）。ここで、第１シグナリングデータは、前述したＳＬＴに該当し、第２シグナリングデータは、前述したＳＬＳに該当し得る。前述したように、第１シグナリングデータは、第２シグナリングデータのを位置を示すための情報を含み、第２シグナリングデータは、放送サービスをシグナリングすることができる。サービスコンポーネント、第１シグナリングデータ及び／又は第２シグナリングデータは、第１モジュールによって生成されてもよい。ここで、第１モジュールは、サービスプロバイダー側でサービスデータを生成するモジュールであってもよい。

生成されたサービスサービスコンポーネントと第２シグナリングデータが伝送パケットにエンカプセレーションされてもよい（ｔ９０３０）。ここで、伝送パケットは、前述した伝送セッションで伝達されるパケットを意味できる。実施例によって、伝送パケットはＲＯＵＴＥパケット又はＭＭＴＰパケットであってもよい。この伝送パケットは、第１伝送セッション又は第２伝送セッションのサブセッションを介して伝送されてもよい。ここで、伝送セッションは、ＲＯＵＴＥセッション又はＭＭＴＰセッションであってもよい。サブセッションは、ＲＯＵＴＥセッションのＬＣＴセッションであるかか、ＭＭＴＰセッションのＭＭＴＰパケットフローを意味することができる。このエンカプセレーション過程は、各データがＲＯＵＴＥ／ＭＭＴＰパケットにエンカプセレーションされることを意味することができる。このエンカプセレーション過程は、第２モジュールによって行われてもよい。第２モジュールは、ＲＯＵＴＥ／ＭＭＴＰパケットへのエンカプセレーションを行うレイヤを担当するモジュールであってもよい。

その後、第１シグナリングデータ及び／又は伝送パケットが放送ストリームとしてプロセシングされてもよい（ｔ９０４０）。この過程は、ＳＬＴ及びＲＯＵＴＥ／ＭＭＴＰパケットにエンカプセレーションされたデータがＩＰ／ＵＤＰにエンカプセレーションされることを意味できる。また、この過程は、このＩＰ／ＵＤＰで処理されたデータがフィジカルレイヤでフィジカルレイヤプロセシングを経る過程を意味できる。ＩＰ／ＵＤＰエンカプセレーションを経てフィジカルレイヤプロセシングする過程は、第３モジュールによって行われてもよい。第３モジュールは、ＩＰ／ＵＤＰエンカプセレーション及びフィジカルレイヤを担当するモジュールであってもよい。

生成された放送ストリームは伝送されてもよい（ｔ９０５０）。これは、第４モジュールによって行われてもよい。第４モジュールは、放送ストリームを伝送する伝送モジュールなどに該当し得る。

本発明の他の実施例に係るサービスデータを処理する方法において、第２サービスシグナリングデータは、第１伝送セッションの特定サブセッションを介して伝送されてもよい。これは、前述したＳＬＳがＲＯＵＴＥセッションの特定ＬＣＴセッション、すなわち、ＴＳＩ＝０を有するＬＣＴセッションを介して伝達されることに対応し得る。また、これは、ＳＬＳがサービスシグナリングチャネルを介して伝達されることに対応し得る。ＴＳＩ＝０で識別されるＳＬＳを運搬するサブセッション（ＬＣＴセッション）は、実施例によってサービスシグナリングチャネルと呼ぶこともできる。サービスコンポーネントは、第１伝送セッション又は第２伝送セッションのサブセッションを介して伝送されてもよい。サービスコンポーネントは、前述したように、ＲＯＵＴＥ／ＭＭＴＰセッションのサブセッション（ＬＣＴセッション又はＭＭＴＰパケットフロー）を介して伝達されてもよい。

本発明の更に他の実施例に係るサービスデータを処理する方法において、第１シグナリングデータは、第２シグナリングデータが伝送される第１伝送セッションを示すための情報を含むことができる。これは、前述したＳＬＴが、ＳＬＳが伝送されるＲＯＵＴＥ／ＭＭＴＰセッションを示するためのブートストラップ情報を含むことに対応し得る。第２シグナリングデータは、放送サービスのサービスコンポーネントへの接近情報を含むことができる。ＳＬＳ、特に、Ｓ−ＴＳＩＤは、各サービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ情報を有することができる。また、ＳＬＳのうち、ＭＰＴメッセージは、各サービスコンポーネントが伝達されるＭＭＴＰパケットフローのパケットＩＤ情報を有することができる。

本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、第１伝送セッションのサブセッションのうち、放送サービスのサービスコンポーネントを伝送するサブセッションを識別する情報をさらに含むことができる。これは、前述したＳＬＳが、ＳＬＳが伝送されるＲＯＵＴＥ／ＭＭＴＰセッションを介して伝達されるサービスコンポーネントの接近情報を有することに対応し得る。この場合、ＳＬＳは、ＴＳＩ情報又はパケットＩＤ情報だけでも、サービスコンポーネントを有するサブセッションを識別することができる。同じ伝送セッション内であるから、ＩＰアドレスなどの情報が別途に含まれなくてもよい。

本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、放送サービスのサービスコンポーネントを伝送する第２伝送セッションを示すための情報をさらに含むことができる。サービスコンポーネントが、ＳＬＳが伝送される伝送セッションと他の伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のために、ＳＬＳは関連情報を有することができる。この情報は、ＩＰアドレス、ＵＤＰポートナンバーなどの形態であってもよい。

本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、第２伝送セッションのサブセッションのうち、放送サービスのサービスコンポーネントを伝送するサブセッションを識別する情報をさらに含むことができる。前述したように、サービスコンポーネントが、ＳＬＳが伝送される伝送セッションと他の伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のために、ＳＬＳは、ＴＳＩ情報又はパケットＩＤ情報だけでも、サービスコンポーネントを有するサブセッションを識別することができる。

本発明の更に他の実施例に係るサービスデータを処理する方法において、第２シグナリングデータは、放送サービスのサービスコンポーネントを伝送するサブセッションが伝達されるフィジカルパス（ｐａｔｈ）を示す情報をさらに含むことができる。ここで、フィジカルパスは、ＰＬＰ又はＤＰを意味することができる。前述したように、サービスコンポーネントが、ＳＬＳが伝送される伝送セッションと他の伝送セッション（第２伝送セッション）を介して伝達される場合、そのサービスコンポーネントへの接近のために、ＳＬＳは、当該コンポーネントが伝達されるＰＬＰＩＤ情報を有することができる。

本発明の更に他の実施例に係るサービスデータを処理する方法において、放送サービスのサービスコンポーネントを伝送するサブセッションは、サービスコンポーネントと関連した初期化情報を含む伝送パケットをさらに伝達することができる。これは、前述した初期化情報がメディアセグメントと共にＬＣＴセッションなどを介して伝達されることに該当し得る。初期化情報を含む伝送パケットは、伝送パケットのヘッダー情報を用いて識別されてもよい。前述したように、初期化情報は、パケットヘッダーのＴＯＩなどの情報を用いて識別されてもよい。

本発明の一実施例に係るサービスデータを処理する方法を受信側で説明する。この方法は図示されていない。

受信側にとって本発明の一実施例に係るサービスデータを処理する方法は、放送信号を受信し、放送信号をパーシングする段階、放送信号から第１シグナリングデータを取得し、これを用いて第２シグナリングデータを得る段階、第２シグナリングデータを用いて当該サービスのサービスコンポーネントを得る段階、及び／又は、当該サービスコンポーネントを用いてサービスを提供する段階を含むことができる。

受信側でサービスデータを処理する方法は、送信側におけるモジュールに対応する受信側ハードウェアモジュール（例えば、受信モジュール、パーシングモジュール、再生モジュールなど）によって行うことができる。受信側でサービスデータを処理する方法は、前述した送信側におけるサービスデータを処理する方法の実施例に対応する実施例を有することができる。

前述した段階は、実施例によって、省略されたり、類似／同一の動作を行う他の段階に代えてもよい。

図１２８は、本発明の一実施例に係る、サービスデータを処理する装置を示す図である。

本発明の一実施例に係るサービスデータを処理する装置は、前述した第１モジュール、第２モジュール、第３モジュール及び／又は第４モジュールを含むことができる。それぞれのブロック、モジュールは、前述したとおりである。

本発明の一実施例に係るサービスデータを処理する装置及びその内部モジュール／ブロックは、前述した本発明のサービスデータを処理する方法の実施例を実行することができる。

本発明の一実施例に係るサービスデータを処理する、受信側における装置を説明する。本発明の一実施例に係る受信側における装置は図示されていない。

本発明の一実施例に係るサービスデータを処理する、受信側における装置は、前述した受信側ハードウェアモジュールを含むことができる。それぞれのブロック、モジュールは、前述したとおりである。

本発明の一実施例に係るサービスデータを処理する受信側における装置は、前述した本発明のサービスデータを処理する方法の実施例を実行することができる。

前述した装置内部のブロック／モジュールなどは、メモリに記憶された連続した実行過程を行うプロセッサであってもよく、実施例によって、装置内／外部に位置するハードウェアエレメントであってもよい。

ｑ前述したモジュールは、実施例によって省略されたり、類似／同一の動作を行う他のモジュールに代えてもよい。

図１２９は、本発明の一実施例に係るＥＳＧブートストラップ情報を示す図である。

本発明の一実施例は、次世代放送網で使用可能なＥＳＧブートストラッピングディスクリプション（ＢｏｏｔｓｔｒａｐｐｉｎｇＤｅｓｃｒｉｐｔｉｏｎ）のシグナリング方法を提供することができる。ＥＳＧブートストラッピングディスクリプションは、次のような情報を含み、当該情報は、シグナリング伝送ロケーションによって、バイナリフォーマット又はＸＭＬフォーマットの形態と定義されてもよい。

ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ（ＥＳＧ）データは、ＳｅｒｖｉｃｅＧｕｉｄｅＤｅｌｉｖｅｒｙＵｎｉｔ（ＳＧＤＵ）及び／又はＳｅｒｖｉｃｅＧｕｉｄｅＤｅｌｉｖｅｒｙＤｅｓｃｒｉｐｔｏｒ（ＳＧＤＤ）を含むことができる。ＳＧＤＤは、ＳＧＤＵがどのデリバリー経路で伝送されるかに関する情報を含むことができる。ＳＧＤＵは、サービス及び／又はプログラムに関連した情報を含むことができる。例えば、ＳＧＤＵは、サービス情報、プログラム情報、チャネル番号、放送局情報、キャプション、放送等級、及び／又は詳細あらすじを含むことができる。サービス情報は、サービスの名前及び／又はサービスの識別子を含むことができる。プログラム情報は、プログラムの名前及び／又はプログラムの識別子、プログラム開始時間情報、及び／又はプログラム終了時間情報を含むことができる。ＳＧＤＵはフラグメント単位で構成され、フラグメントの種類は、サービスフラグメント、コンデンツフラグメント、及び／又はスケジュールフラグメントのうちで少なくとも一つを含むことができる。ＳＧＤＤ及びＳＧＤＵはいずれもＸＭＬファイルであってもよい。ＥＳＧは、ＳｅｒｖｉｃｅＧｕｉｄｅ（ＳＧ）及び／又はＥｌｅｃｔｒｏｎｉｃＰｒｏｇｒａｍＧｕｉｄｅ（ＥＰＧ）と表現されてもよい。また、ＥＳＧｄａｔａは簡略にＥＳＧと表現されてもよい。

ＥＳＧブートストラッピングディスクリプションは、ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ（ＥＳＧ）のブートストラッピングのための情報を含むことができる。ＥＳＧブートストラッピングディスクリプションは、ＥＳＧブートストラップ情報及び／又はＥＳＧのためのブートストラッピング情報と表現されてもよい。放送受信装置は、ＥＳＧブートストラッピングディスクリプション及び／又はＥＳＧブートストラップ情報に基づいてＥＳＧを受信、取得、及び／又は処理することができる。

ＥＳＧブートストラッピングディスクリプションは、少なくとも一つのＳｅｒｖｉｃｅＧｕｉｄｅ（ＳＧ）Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔを含むことができる。

ＳＧＰｒｏｖｉｄｅｒは、ＥＳＧと関連した情報を提供する提供者を示すことができる。ＳＧＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ｎａｍｅａｔｔｒｉｂｕｔｅ及び／又は少なくとも一つのＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔを含むことができる。

ｎａｍｅａｔｔｒｉｂｕｔｅは、ＳＧＰｒｏｖｉｄｅｒの名前を示すことができる。

Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは、少なくとも一つのブートストラップ情報を含むことができる。Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ、ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔ、ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔ、ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔ、ｔｓｉｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報であってもよい。

ｎｅｔｗｏｒｋ＿ｔｙｐｅｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが伝送されるタイプを示すことができる。具体的に、ｎｅｔｗｏｒｋ＿ｔｙｐｅｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるタイプを示すことができる。Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれたｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの個数は１つであってもよい。ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの属性値によって、Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは、以下に定義されたブートストラップ情報を選択的に含むことができる。参考として、「ＥＳＧブートストラッピングディスクリプションが伝送されるタイプ」は、「ＥＳＧｄａｔａが伝送されるタイプ」と解釈されてもよい。具体的に、「ＥＳＧブートストラッピングディスクリプションが伝送されるタイプ」は「ＳＧＤＤが伝送されるタイプ」と解釈されてもよい。

ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ、及び／又はＳＧｄａｔａのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。例えば、ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧと関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰｓｏｕｒｃｅａｄｄｒｅｓｓを含むことができる。具体的に、ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＩＰｓｏｕｒｃｅａｄｄｒｅｓｓを示すことができる。

ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ、及び／又はＳＧｄａｔａのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。例えば、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧと関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓを含むことができる。具体的に、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＩＰｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓを示すことができる。

ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ、及び／又はＳＧｄａｔａのｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ番号を示すことができる。例えば、ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧと関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのポート番号を含むことができる。具体的に、ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ番号を示すことができる。

ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔ、及び／又はｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔは、ＥＳＧｄａｔａを伝送するＩＰパケットのヘッダーに記述された情報を意味する。

ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが外部周波数（ＦｏｒｅｉｇｎＦｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって、選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。具体的に、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔは、ＳＧＤＤが伝送される伝送ストリーム識別子を示すことができる。

ｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが外部周波数（Ｆｏｒｅｉｇｎｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。例えば、パーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）は、放送会社を識別することができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって、選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。具体的に、ｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるパーティション識別子を示すことができる。

ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧｄａｔａがブロードキャストで伝送される場合、ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔは一つの値を含むことができる。具体的に、ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。

外部周波数（Ｆｏｒｅｉｇｎｆｒｅｑｕｅｎｃｙ）で伝送されるＥＳＧｄａｔａの情報を知らせるために、Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは選択的に、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔ、及び／又はｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔを含むことができる。

ｔｓｉｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧｄａｔａがブロードキャストで伝送される場合、ｔｓｉｅｌｅｍｅｎｔは、少なくとも一つの値を含むことができる。具体的に、ｔｓｉｅｌｅｍｅｎｔは、ＳＧＤＤが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。

ｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔは、ブロードバンドで伝送されるＥＳＧｄａｔａに接近し得るＵＲＬを示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧｄａｔａがブロードバンドで伝送される場合、ｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔは一つの値を含むことができる。具体的に、ｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔは、ＳＧＤＤが伝送されるＵＲＬを示すことができる。

ＥＳＧｄａｔａがブロードキャストで伝送されるか、それともブロードバンドで伝送されるかによって、Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔはｔｓｉｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔは２つのうち少なくとも一つを含むことができる。

放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。シグナリング情報は、ＥＳＧブートストラップ情報を含むことができる。放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。放送受信装置は、シグナリング情報に含まれたＥＳＧブートストラップ情報に基づいてＥＳＧデータを取得及び／又は処理することができる。

図１３０は、本発明の一実施例に係るＥＳＧブートストラップ情報が伝送されるタイプを示す図である。

ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅは、ＥＳＧｄａｔａが伝送されるタイプを示すことができる。ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値は、固定された値ではなて、変更されてもよい。様々なタイプでＥＳＧｄａｔａが伝送される場合、それぞれのｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅを有するＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔが複数個伝送されてもよい。

ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値が「０ｘ０１」であれば、ＥＳＧｄａｔａは、同一の周波数内でＡＴＳＣ３．０ブロードキャストで伝送されてもよい。この場合、放送受信装置は、同一の周波数内でＥＳＧｄａｔａを受信することができる。

ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値が「０ｘ０２」であれば、ＥＳＧｄａｔａは、他の周波数内でＡＴＳＣ３．０ブロードキャストで伝送されてもよい。この場合、放送受信装置は、他の周波数内でＥＳＧｄａｔａを受信することができる。

ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値が「０ｘ０３」であれば、ＥＳＧｄａｔａは、ＡＴＳＣ３．０ブロードキャスト以外のＩＰブロードキャストで伝送されてもよい。この場合、放送受信装置は、ＩＰブロードキャストでＥＳＧｄａｔａを受信することができる。

ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値が「０ｘ０４」であれば、ＥＳＧｄａｔａは、ブロードバンドで伝送されてもよい。この場合、放送受信装置は、ブロードバンドでＥＳＧｄａｔａを受信することができる。

図１３１は、本発明の第１実施例に係る、ＥＳＧブートストラップ情報のシグナリングを示す図である。

本発明の第１実施例は、次世代放送網でＥＳＧブートストラップ情報をＦＩＣのＥＳＧブートストラッピングディスクリプタ形態で伝送する方法を提供することができる。本発明の第１実施例では、ＥＳＧは放送サービスと定義されない。また、ＦＩＣは、ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ（ＳＬＴ）と呼ぶことができる。ＳＬＴは、基本的なサービスリストを樹立（ｂｕｉｌｄｉｎｇ）し、サービスレイヤシグナリング情報（ＳＬＳ）の発見をブートストラップするために用いられるシグナリング情報テーブルである。

図面を参照すると、放送信号及び／又はアクチュアルストリームは、特定周波数の少なくとも一つの放送ストリームを含むことができる。例えば、アクチュアルストリーム（ＡｃｔｕａｌＳｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。

それぞれの放送ストリームは、少なくとも一つのパーティションを含むことができる。それぞれのパーティションは、それぞれの放送会社に該当し得る。又は、それぞれのパーティションは、それぞれの放送会社で伝送する放送ストリームであってもよい。

それぞれのパーティションは、少なくとも一つのＤＰ（又は、ＰＬＰ）及び／又はＦＩＣを含むことができる。例えば、第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰの識別子（ＤＰＩＤ）は、「１」でもよい。第２ＤＰの識別子（ＤＰＩＤ）は「２」であってもよい。第３ＤＰの識別子（ＤＰＩＤ）は「３」であってもよい。

一つのＤＰは一つのＲｅａｌ−ＴｉｍｅＯｂｊｅｃｔＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ（ＲＯＵＴＥ）セッションを含むことができる。また、複数のＤＰが一つのＲＯＵＴＥセッションを含むことができる。ＲＯＵＴＥセッションは少なくとも一つのサービス及び／又は少なくとも一つのコンポーネントを含むことができる。ＲＯＵＴＥセッションをＩＰ／ＵＤＰデータグラムと呼ぶこともできる。

例えば、第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。すなわち、第１ＲＯＵＴＥセッションは第１ＤＰを介して送信される。第１ＲＯＵＴＥセッションは、第１ソースＩＰアドレス、第１デスティネーションＩＰアドレス、及び／又は第１ＵＤＰポート番号と特定されてもよい。第１ＲＯＵＴＥセッションは、第１サービス（Ａ／ＶＳｅｒｖｉｃｅ）を含むことができる。

第１ＲＯＵＴＥセッションは少なくとも一つの伝送セッション（又は、ＬＣＴセッション）を含むことができる。例えば、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。

第１伝送セッション（ｔｓｉ−ｖ）はビデオコンポーネントを含むことができる。ビデオコンポーネントは、ビデオデータを含む少なくとも一つのビデオセグメントを含むことができる。第２伝送セッション（ｔｓｉ−ａ）は、オーディオコンポーネントを含むことができる。オーディオコンポーネントは、オーディオデータを含む少なくとも一つのオーディオセグメントを含むことができる。第３伝送セッション（ｔｓｉ−ｓ）はサービスシグナリングチャネルコンポーネントを含むことができる。サービスシグナリングチャネルコンポーネントは、ＳｅｒｖｉｃｅＭａｐＴａｂｌｅ（ＳＭＴ）、ＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅ（ＣＭＴ）、ＧｕｉｄｅＡｃｃｅｓｓＴａｂｌｅ（ＧＡＴ）、及び／又はＤＡＳＨＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）のうち少なくとも一つを含むことができる。第４伝送セッション（ｔｓｉ−０）は、ＬＣＴｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎ（ＬＳＩＤ）を含むことができる。ＬＳＩＤは、Ｓｅｒｖｉｃｅ−ｂａｓｅｄＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ（Ｓ−ＴＳＩＤ）と呼ぶことができる。Ｓ−ＴＳＩＤは、サービスの少なくとも一つのコンデンツコンポーネントを伝送する少なくとも一つの伝送セッションのための全体的なセッションディスクリプション情報を含むことができる。

第２ＤＰ及び第３ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。すなわち、第２ＲＯＵＴＥセッションは、第２ＤＰ及び／又は第３ＤＰを介して送信される。第２ＲＯＵＴＥセッションは、第２ソースＩＰアドレス、第２デスティネーションＩＰアドレス、及び／又は第２ＵＤＰポート番号と特定されてもよい。

第２ＲＯＵＴＥセッションは、少なくとも一つの伝送セッション（又は、ＬＣＴセッション）を含むことができる。例えば、第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−１０１）、及び／又は第７伝送セッション（ｔｓｉ−１０２）を含むことができる。伝送セッション（又は、ＬＣＴセッション）は、少なくとも一つの伝送オブジェクトを含むことができる。

第５伝送セッション（ｔｓｉ−０）はＬＳＩＤを含むことができる。

第６伝送セッション（ｔｓｉ−１０１）は、第１伝送オブジェクト（ｔｏｉ−０）及び／又は第２伝送オブジェクト（ｔｏｉ−１）を含むことができる。第１伝送オブジェクト（ｔｏｉ−０）は、ファイルデリバリーセッション内で伝送されるファイル及び／又はファイルの伝送と関連した属性を提供するＦｉｌｅＤｅｌｉｖｅｒｙＴａｂｌｅ（ＦＤＴ）を含むことができる。又は、第１伝送オブジェクト（ｔｏｉ−０）は、ファイルデリバリーデータの細部内容を明示するＥＦＤＴを含むことができる。第２伝送オブジェクト（ｔｏｉ−１）は、ＳｅｒｖｉｃｅＧｕｉｄｅＤｅｌｉｖｅｒｙＵｎｉｔ（ＳＧＤＵ）がどのデリバリー経路で伝送されるかに関する情報を記述するＳｅｒｖｉｃｅＧｕｉｄｅＤｅｌｉｖｅｒｙＤｅｓｃｒｉｐｔｏｒ（ＳＧＤＤ）を含むことができる。

第７伝送セッション（ｔｏｉ−１０２）は、第３伝送オブジェクト（ｔｏｉ−０）、第４伝送オブジェクト（ｔｏｉ−１）、及び／又は第５伝送オブジェクト（ｔｏｉ−２）を含むことができる。第３伝送オブジェクト（ｔｏｉ−０）は、ＦＤＴ及び／又はＥＦＤＴを含むことができる。第４伝送オブジェクト（ｔｏｉ−１）は、ＳＧＤＵを含むことができる。第５伝送オブジェクト（ｔｏｉ−２）はＳＧＤＵを含むことができる。ＳＧＤＵはフラグメント単位で構成され、フラグメントの種類は、サービスフラグメント、コンデンツフラグメント、及び／又はスケジュールフラグメントのうち少なくとも一つを含むことができる。ＳＧＤＵはＥＳＧデータを含むことができる。ＳＧＤＤ及びＳＧＤＵはいずれもＸＭＬファイルであってもよい。

放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。

放送伝送装置は、ＦＩＣを含む放送信号を伝送することができる。

ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。

ＳＳＣブートストラップ情報（ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）は、ＳＭＴ及び／又はＣＭＴが伝送されるＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌ（ＳＳＣ）と関連した情報を含むことができる。本発明の第１実施例では、ＥＳＧは別途の一つのサービスと定義されないことから、ＦＩＣはサービスループ（ＳｅｒｖｉｃｅＬｏｏｐ）においてＳＳＣブートストラップ情報を含まなくてもよい。

本発明の第１実施例に係るＦＩＣは、ＥＳＧブートストラップ情報をパーティションレベルのディスクリプタ形態で含むことができる。

ＥＳＧブートストラップ情報は、前述したＥＳＧブートストラップ情報及び／又はＥＳＧブートストラップディスクリプションと同じ情報を含むことができる。例えば、ＥＳＧブートストラップ情報は、ｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔ及び／又は少なくとも一つのＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔを含むことができる。

ｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、プロバイダーの数を示すことができる。

Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、提供者に関する情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。また、Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、前述したＳＧＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔを示すことができる。それぞれのＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔ、ｔｓｉａｔｔｒｉｂｕｔｅ、ＤＰａｔｔｒｉｂｕｔｅ、及び／又はＵＲＬａｒｒｔｉｂｕｔｅのうち少なくとも一つを含むことができる。

ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅは、ＥＳＧｄａｔａが伝送されるタイプを示すことができる。ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅは、前述したｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅを示すことができる。

ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅは、ＥＳＧｄａｔａが外部周波数（ＦｏｒｅｉｇｎＦｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅは、前述したｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔを示すことができる。

ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅは、ＥＳＧｄａｔａが外部周波数（Ｆｏｒｅｉｇｎｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅは、前述したｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔを示すことができる。

Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションを識別する情報を含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションブートストラップ情報は、ＲＯＵＴＥセッションの伝送経路情報を含むことができる。例えば、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ）ａｔｔｒｉｂｕｔｅ及び／又はｐｏｒｔａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ＩＰ（ｓｒｃ／ｄｅｓｔ）ａｔｔｒｉｂｕｔｅは、前述したｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ及びｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔを含むことができる。ｐｏｒｔａｔｔｒｉｂｕｔｅは、前述したｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔを示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔ、及びｐｏｒｔｅｌｅｍｅｎｔの組合せは、特定ＲＯＵＴＥセッションを識別することができる。

ｔｓｉａｔｔｒｉｂｕｔｅは、ＥＳＧｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。例えば、ｔｓｉａｔｔｒｉｂｕｔｅはＳＧＤＤが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。図面を参照すると、例えば、ｔｓｉａｔｔｒｉｂｕｔｅの値は、「ｔｓｉ−１０１」であってもよい。

ＤＰａｔｔｒｉｂｕｔｅは、ＥＳＧｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。ＤＰａｔｔｒｉｂｕｔｅは、前述したｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔを示すことができる。例えば、ＤＰａｔｔｒｉｂｕｔｅは、ＳＧＤＤが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。図面を参照すると、例えば、ＤＰａｔｔｒｉｂｕｔｅの値は「２」であってもよい。

ＵＲＬａｒｒｔｉｂｕｔｅは、ブロードバンドで伝送されるＥＳＧｄａｔａに接近し得るＵＲＬを示すことができる。ＵＲＬａｒｒｔｉｂｕｔｅは、前述したｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔを示すことができる。

本発明の第１実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。

放送伝送装置は、ＬＳＩＤを含む放送信号を伝送することができる。

例えば、第５伝送セッション（ｔｓｉ−０）に含まれたＬＳＩＤは、第６伝送セッションに関する情報を含む第６伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。

それぞれの第６伝送セッションエレメント（ＴＳＩ−１０１）及び第７伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションが伝送されるＤＰを識別するＤＰａｔｔｒｉｂｕｔｅ、伝送セッションに含まれるソースフローに関する情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアフローに関する情報を提供するＲｅｐａｉｒＦｌｏｗエレメントのうち少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するか否かを示すｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間伝送されることを示すことができる。また、例えば、ｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間伝送されることを示すことができる。

放送受信装置は、ＳＧＤＤを用いて第７伝送セッションエレメント（ＴＳＩ−１０２）を取得することができるが、当該伝送セッションで伝送されるＳＧＤＵのＤＰ情報を得ることができない場合がある。したがって、本発明の第１実施例に係る放送伝送装置は、ＤＰ情報を含むＬＳＩＤを伝送することができる。

放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。

放送受信装置は、ＦＩＣを取得することができる。ＦＩＣは、ＩＰ／ＵＤＰパケットで伝送されてもよい。

放送受信装置は、ＦＩＣに基づいてＥＳＧブートストラップ情報及び／又はＬＳＩＤを取得することができる。放送受信装置は、ＦＩＣのパーティションレベルディスクリプタに基づいてＥＳＧブートストラップ情報を取得することができる。ＥＳＧブートストラップ情報は、ＦＩＣでパーティションレベルディスクリプタの形態で含まれてもよい。本発明の第１実施例では、ＥＳＧを別途の一つのサービスと定義しないことからせ、ＦＩＣはサービスループ（ＳｅｒｖｉｃｅＬｏｏｐ）でＳＳＣブートストラップ情報を含まなくてもよい。ＬＳＩＤは、それぞれの伝送セッション別に伝送ＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むことができる。また、放送受信装置は、ＥＳＧブートストラップ情報に含まれたＲＯＵＴＥセッションブートストラップ情報に基づいてＬＳＩＤを取得することができる。この場合、ＬＳＩＤは、あらかじめ定められた伝送セッションを介して伝送されてもよく、放送受信装置は、ＲＯＵＴＥセッションブートストラップ情報及び／又はあらかじめ定められた伝送セッション情報に基づいてＬＳＩＤを取得することができる。又は、放送受信装置は、ＦＩＣに含まれた別途のＬＳＩＤ伝送経路情報に基づいてＬＳＩＤを取得することができる。

放送受信装置は、ＥＳＧブートストラップ情報及び／又はＬＳＩＤに基づいてＥＳＧｄａｔａ及び／又はＥＳＧサービスを取得することができる。

本発明の第１実施例に係る放送伝送装置がＥＳＧＡｎｎｏｕｎｃｅｍｅｎｔＣｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送ＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。

また、本発明の第１実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０Ｐｒｏｆｉｌｅを追加して、ＤａｔａＰｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａＰｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。

図１３２は本発明の第２実施例に係る、ＥＳＧブートストラップ情報のシグナリングを示す図である。

本発明の第２実施例は、次世代放送網でＥＳＧブートストラッピング情報をＦＩＣのＥＳＧブートストラッピングディスクリプタ形態で伝送する方法を提供することができる。本発明の第２実施例では、ＥＳＧは一つの放送サービスと定義されてもよい。また、ＦＩＣのサービスループ（ｓｅｒｖｉｃｅｌｏｏｐ）内でＳｅｒｖｉｃｅＣａｔｅｇｏｒｙｅｌｅｍｅｎｔは、当該サービスがＥＳＧサービスであることを示すことができる。放送受信装置は、ＥＳＧブートストラップ情報をＦＩＣからＥＳＧブートストラッピングディスクリプタ形態で受信することができる。また、放送受信装置は、ＥＳＧブートストラップ情報を用いてＥＳＧを取得することができる。

同図を参照すると、本発明の第２実施例に係るアクチュアルストリーム（ＡｃｔｕａｌＳｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは、第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、第１サービス（Ａ／ＶＳｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。第２ＤＰ及び第３ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは、第２サービスを含むことができる。例えば、第２サービスは、ＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−１０１）、及び／又は第７伝送セッション（ｔｓｉ−１０２）を含むことができる。本発明の第２実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。同図に示したアクチュアルストリーム（ＡｃｔｕａｌＳｔｒｅａｍ）に関する内容は、前述したアクチュアルストリーム（ＡｃｔｕａｌＳｔｒｅａｍ）に関する内容を全て含むことができる。

放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータは、ＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。

ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。ＳＳＣＩＰ／Ｐｏｒｔエレメントは、ＳＳＣを伝送するｓｏｕｒｃｅＩＰＡｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ、及び／又はＵＤＰＰｏｒｔｎｕｍｂｅｒを含むことができる。

ＳＧＤＤが伝送される伝送セッションは、ＬＳＩＤが伝送される伝送セッションと異なってもよい。この場合、ＳＳＣブートストラップ情報（ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）は、ＥＳＧブートストラッピング情報に置き換えられてもよい。例えば、ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ３．０Ｂｒｏａｄｃａｓｔで伝送されるＥＳＧｄａｔａを識別するＥＳＧブートストラップ情報であってもよい。この場合、ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣに関連した情報を含まなくてもよい。ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントがＥＳＧブートストラップ情報を含むという内容は、ＦＩＣのＳｅｍａｎｔｉｃｓに含まれてもよい。ＥＳＧブートストラップ情報は、ＥＳＧｄａｔａ及び／又はＳＧＤＤが伝送される経路を識別する情報であってもよい。また、ＦＩＣは、ＳＳＣ及び／又はＬＳＩＤのブートストラップ情報及び／又は伝送経路に関する情報を別途にさらに含むことができる。また、ＳＳＣ及び／又はＬＳＩＤは、あらかじめ定義された特定の伝送セッションを介して伝送されてもよい。

ＳＧＤＤが伝送される伝送セッションは、ＬＳＩＤが伝送される伝送セッションと同一であってもよい。すなわち、ＬＳＩＤはＳＧＤＤを含むことができる。この場合、ＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に該当し得る。すなわち、ＳＳＣブートストラップ情報及び／又はＥＳＧブートストラッピング情報は、ＳＳＣ、ＬＳＩＤ、ＥＳＧｄａｔａ、及び／又はＳＧＤＤを識別することができる。例えば、ＳＳＣＩＰ／Ｐｏｒｔエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧｄａｔａ、及び／又はＳＧＤＤを伝送するＩＰ／Ｐｏｒｔを識別することができる。ＳＳＣＤＰ＿ＩＤエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧｄａｔａ、及び／又はＳＧＤＤを伝送するＤＰを識別することができる。ＴＳＩエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧｄａｔａ、及び／又はＳＧＤＤを伝送する伝送セッションを識別することができる。ＳＳＣＩＰ／Ｐｏｒｔエレメントは、ＳＳＣ、ＬＳＩＤ、ＥＳＧｄａｔａ、及び／又はＳＧＤＤを伝送するｓｏｕｒｃｅＩＰＡｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ、及び／又はＵＤＰＰｏｒｔｎｕｍｂｅｒを含むことができる。この場合にも、ＳＳＣ及び／又はＬＳＩＤは、あらかじめ定義された特定の伝送セッションを介して伝送されてもよい。

また、ＦＩＣのパーティションレベルのディスクリプタは、追加的なＥＳＧブートストラップ情報をさらに含むことができる。例えば、パーティションレベルのディスクリプタに含まれるＥＳＧブートストラップ情報は、ｎｕｍ＿ｏｆ＿Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔ及び／又は少なくとも一つのＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔを含むことができる。例えば、Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、提供者に関する情報を含むことができる。また、Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔはｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅ、ＳｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ、及び／又はＵＲＬａｒｒｔｉｂｕｔｅのうち少なくとも一つを含むことができる。ＳｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅは、サービスを識別することができる。ＥＳＧブートストラップ情報に含まれるエレメント及び属性に関する内容は、前述した内容と同一である。

本発明の第２実施例に係るＥＳＧは、一つのサービスと定義されてもよい。また、ＦＩＣサービスループ（ＳｅｒｖｉｃｅＬｏｏｐ）内のＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報として活用されてもよい。

これによって、ＦＩＣのサービスループ（Ｓｅｒｖｉｃｅｌｏｏｐ）内のＳＳＣブートストラップ情報に対するｓｅｍａｎｔｉｃｓ定義時に別途の定義方案が必要であるが、ＦＩＣのサイズ増加を当該情報長さ分だけ減らすことができるという長所がある。ＳＳＣブートストラップ情報を用いて表現できないｎｅｔｗｏｒｋｔｙｐｅで伝送されるＥＳＧブートストラップ情報は、パーティションレベル（ｐａｒｔｉｔｉｏｎｌｅｖｅｌ）のディスクリプタで別途の情報を伝送するようにする。

本発明の第２実施例に係るＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。

例えば、第５伝送セッション（ｔｓｉ−０）に含まれたＬＳＩＤは、第６伝送セッションに関する情報を含む第６伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。本発明の第２実施例に係るＬＳＩＤは、前述したＬＳＩＤに関する内容を全て含むことができる。

放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ及び／又はＬＳＩＤを含むことができる。

放送受信装置はＦＩＣを取得することができる。ＦＩＣはＩＰ／ＵＤＰパケットを介して伝送されてもよい。

放送受信装置は、ＦＩＣに基づいてＳＳＣブートストラップ情報及び／又はＥＳＧブートストラップ情報を取得することができる。ＦＩＣはＥＳＧブートストラップ情報を含むことができる。

ＳＧＤＤが伝送される伝送セッションが、ＬＳＩＤが伝送される伝送セッションと異なる場合、ＦＩＣのＳＳＣブートストラップ情報（ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメント）は、ＥＳＧブートストラッピング情報に置き換えられてもよい。また、ＦＩＣは、ＳＳＣ及び／又はＬＳＩＤをブートストラップ及び／又は識別する別途の情報をさらに含むことができる。

ＳＧＤＤが伝送される伝送セッションが、ＬＳＩＤが伝送される伝送セッションと同一である場合、ＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に該当し得る。すなわち、ＳＳＣブートストラップ情報及び／又はＥＳＧブートストラッピング情報は、ＳＳＣ、ＬＳＩＤ、ＥＳＧｄａｔａ、及び／又はＳＧＤＤを識別することができる。以下では、ＳＧＤＤが伝送される伝送セッションが、ＬＳＩＤが伝送される伝送セッションと同一である場合を中心に説明する。

また、ＦＩＣのパーティションレベルのディスクリプタは、追加的なＥＳＧブートストラップ情報をさらに含むことができる。ＬＳＩＤは、それぞれの伝送セッション別に伝送ＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むことができる。

放送受信装置はＦＩＣに基づいてＬＳＩＤを取得することができる。例えば、放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＬＳＩＤを取得することができる。

また、放送受信装置は、ＦＩＣに基づいてＥＳＧブートストラップ情報を取得することができる。例えば、ＦＩＣのＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に該当し得る。

本発明の第２実施例に係る放送伝送装置がＥＳＧＡｎｎｏｕｎｃｅｍｅｎｔＣｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送ＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。

また、本発明の第２実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０Ｐｒｏｆｉｌｅを追加して、ＤａｔａＰｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａＰｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。

図１３３は、本発明の第３実施例に係るＥＳＧブートストラッピングディスクリプションのシグナリングを示す図である。

本発明の第３実施例は、次世代放送網でＥＳＧブートストラップ情報をＳＭＴのＲＯＵＴＥセッションエレメントを用いて伝送する方法を提供することができる。ＥＳＧは、一つの別途のＳｅｒｖｉｃｅと定義されてもよい。ＦＩＣのサービスループ（ＳｅｒｖｉｃｅＬｏｏｐ）でＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを示すことができる。ＳＳＣチャネルを介してＳＭＴとＣＭＴが伝送されてもよい。ただし、ＳＭＴｓｅｍａｎｔｉｃｓ定義を変更して定義するようにしなければならない。

同図を参照すると、本発明の第３実施例に係るアクチュアルストリーム（ＡｃｔｕａｌＳｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは、第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、第１サービス（Ａ／ＶＳｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。同図に示した第１ＲＯＵＴＥセッションに関する内容は、前述したＲＯＵＴＥセッションに関する内容を全て含むことができる。

第２ＤＰ、第３ＤＰ、及び第４ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。

第６伝送セッション（ｔｓｉ−ｓｓｃ）は、ＳＭＴ及び／又はＣｏｍｐｏｎｅｎｔＭａｐｐｉｎｇＴａｂｌｅ（ＣＭＴ）を含むことができる。

第７伝送セッション（ｔｓｉ−１０１）は、第１伝送オブジェクト（ｔｏｉ−０）及び／又は第２伝送オブジェクト（ｔｏｉ−１）を含むことができる。第１伝送オブジェクトは、ＦＤＴ及び／又はＥＦＤＴを含むことができる。第２伝送オブジェクト（ｔｏｉ−１）は、ＳＧＤＤを含むことができる。

第８伝送セッション（ｔｏｉ−１０２）は、第３伝送オブジェクト（ｔｏｉ−０）、第４伝送オブジェクト（ｔｏｉ−１）、及び／又は第５伝送オブジェクト（ｔｏｉ−２）を含むことができる。第３伝送オブジェクト（ｔｏｉ−０）は、ＦＤＴ及び／又はＥＦＤＴを含むことができる。第４伝送オブジェクト（ｔｏｉ−１）はＳＧＤＵを含むことができる。第５伝送オブジェクト（ｔｏｉ−２）はＳＧＤＵを含むことができる。ＳＧＤＵはＥＳＧデータを含むことができる。

放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。

ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣブートストラップ情報であってもよい。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ３．０Ｂｒｏａｄｃａｓｔで伝送されるＳＳＣブートストラッピング情報であってもよい。本発明の第３実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。

本発明の第３実施例に係るＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。

放送伝送装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含む放送信号を伝送することができる。

ＳＭＴは、ｓｅｒｖｉｃｅＩＤｅｌｅｍｅｎｔ、ｃａｔｅｇｏｒｙｅｌｅｍｅｎｔ、ｎｕｍ＿ｏｆＬＳＩＤｅｌｅｍｅｎｔ、少なくとも一つのＬＳＩＤｅｌｅｍｅｎｔ、ｎｕｍ＿ｏｆＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔ、及び／又は少なくとも一つのＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。

ｓｅｒｖｉｃｅＩＤｅｌｅｍｅｎｔは、サービスを識別することができる。

ｃａｔｅｇｏｒｙｅｌｅｍｅｎｔは、サービスのカテゴリーを識別することができる。例えば、サービスのカテゴリーはＥＳＧサービスを含むことができる。

ｎｕｍ＿ｏｆＬＳＩＤｅｌｅｍｅｎｔは、ＬＳＩＤの数を示すことができる。ＬＳＩＤｅｌｅｍｅｎｔは、ＬＳＩＤに関連した情報を含むことができる。

ＬＳＩＤｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。例えば、ＬＳＩＤｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔ（又は、ａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔ）、及び／又はＵＲＬｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔｅｌｅｍｅｎｔ、ｔｓｉｅｌｅｍｅｎｔ、及び／又はＤＰｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。ＬＳＩＤｅｌｅｍｅｎｔに含まれるエレメント及び／又は属性に関する内容は、前述した内容と同一である。また、たとえｅｌｅｍｅｎｔとａｔｔｒｉｂｕｔｅとの違いはあっても、含まれる情報は同一であってもよい。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションブートストラップ情報は、ＬＳＩＤの伝送経路に関する情報を含むことができる。

ｎｕｍ＿ｏｆＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧに関連した情報を提供する提供者の数を示すことができる。Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、提供者に関連した情報を含むことができる。

Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。また、Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔ（又は、ａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔ）、及び／又はＵＲＬｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔｅｌｅｍｅｎｔ、ｔｓｉｅｌｅｍｅｎｔ、及び／又はＤＰｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔに含まれるエレメント及び／又は属性に関する内容は、前述した内容と同一である。また、たとえｅｌｅｍｅｎｔとａｔｔｒｉｂｕｔｅとの違いはあっても、含まれる情報は同一であってもよい。Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔ又はａｎｎｏｕｎｃｅｍｅｎｔ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。ＥＳＧブートストラップ情報は、ＥＳＧｄａｔａの伝送経路に関する情報を含むことができる。例えば、ＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ及びｐｏｒｔｅｌｅｍｅｎｔが第２ＲＯＵＴＥセッションを示し、ｔｓｉｅｌｅｍｅｎｔの値が第５伝送セッション（ｔｓｉ−１０１）を示し、ＤＰｅｌｅｍｅｎｔの値が第２ＤＰ（ＤＰＩＤ＝２）を示すことができる。

第５伝送セッションに含まれたＬＳＩＤは、第６伝送セッションに関する情報を含む第６伝送セッションエレメント（図示せず）、第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）、及び／又は第８伝送セッションに関する情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、ＳｏｕｒｃｅＦｌｏｗエレメント、及び／又はＲｅｐａｉｒＦｌｏｗエレメントのうち少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間伝送されることを示すことができる。

ＣＭＴは、サービス内のコンポーネントデータの取得経路及び／又は伝送経路に関する情報を含むことができる。また、ＣＭＴは、ブロードバンドで伝送されるコンポーネントに関する情報を含むことができる。また、ＣＭＴは、他のブロードキャストストリームに存在するコンポーネントに関する情報を含むことができる。ＣＭＴに関連した内容は、前述したＣＭＴに関連した内容を全て含むことができる。例えば、ＣＭＴは、ｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ及び／又はｃｏｍｐｅｌｅｍｅｎｔを含むことができる。ｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅはサービスを識別することができる。ｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅは、当該コンポーネントと関連したサービスを識別する識別子である。ｃｏｍｐｅｌｅｍｅｎｔは、当該サービス内のコンポーネントに関連した情報を含むことができる。例えば、ｃｏｍｐｅｌｅｍｅｎｔは、同一の放送ストリームを介して伝送されるコンポーネントに関連した情報、ブロードバンド網で伝送されるコンポーネント、及び／又は他の放送ストリームを介して伝送されるコンポーネントのうち少なくとも一つを含むことができる。ｃｏｍｐｅｌｅｍｅｎｔは、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングされるｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションを識別するｔｓｉａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送されるＤＰを識別するＤＰａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。放送受信装置は、ＣＭＴに基づいてサービスのコンポーネントを取得することができる。

放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータは、ＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。

放送受信装置は、ＦＩＣに基づいてＳＳＣブートストラップ情報を取得することができる。ＳＳＣは、ＳＭＴ及び／又はＣＭＴを含むことができる。

放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを取得することができる。ＳＭＴは、ＬＳＩＤエレメント及び／又はＰｏｒｖｉｄｅｒエレメントのうち少なくとも一つを含むことができる。ＬＳＩＤエレメントは、ＲＯＵＴＥセッションエレメントを含むことができる。ＬＳＩＤエレメントのＲＯＵＴＥセッションエレメントは、ＬＳＩＤ伝送経路情報を含むことができる。ＰｏｒｖｉｄｅｒエレメントのＲＯＵＴＥセッションエレメントは、ＥＳＧブートストラップ情報を含むことができる。

ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙがＥＳＧサービスを示す場合、ＳＭＴはＥＳＧブートストラップ情報を含むことができる。例えば、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙがＥＳＧサービスを示す場合、ＳＭＴに記述されたＬＳＩＤ伝送経路情報は、ＥＳＧブートストラップ情報に置き換えられてもよい。これに限定されず、ＳＭＴは、ＬＳＩＤ伝送経路情報及び／又はＥＳＧブートストラップ情報を全て含むことができる。

放送受信装置は、ＳＭＴに基づいてＬＳＩＤ及び／又はＥＳＧブートストラップ情報を取得することができる。ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙがＥＳＧサービスを示す場合、ＳＭＴに記述されたＬＳＩＤ伝送経路情報は、ＥＳＧブートストラップ情報に置き換えられてもよい。また、具体的に、ＳＭＴに含まれたＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔｅｌｅｍｅｎｔ、ｔｓｉｅｌｅｍｅｎｔ、及び／又はＤＰｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報であってもよい。これに限定されず、ＲＯＵＴＥセッションエレメントは、ＬＳＩＤ及び／又はＥＳＧブートストラップ情報を全て含むことができ、放送受信装置は、ＳＭＴに基づいてＬＳＩＤ伝送経路情報及び／又はＥＳＧブートストラップ情報を全て取得することができる。

放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを取得することができる。

放送受信装置は、ＣＭＴに基づいてコンポーネントマッチング情報を取得することができる。例えば、ＣＭＴは、ＣｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅ、ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又はＤＰａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。

放送受信装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つに基づいて、ＥＳＧｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいて、ＥＳＧｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＣＭＴのｔｓｉａｔｔｒｉｂｕｔｅに基づいて、ＬＳＩＤで記述する伝送セッションを取得し、これにマッピングされるＤＰ情報を取得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉａｔｔｒｉｂｕｔｅ及び／又はＤＰａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを取得することができる。例えば、実際コンポーネントは、ＥＳＧサービスのためのコンポーネントであってもよい。

具体的に、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報のうち少なくとも一つに基づいて、ＥＳＧｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを取得することができる。その後、放送受信装置は、ＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを取得することができる。

ＥＳＧデータも一つのファイルと定義することができるために、放送受信装置は、ＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅに基づいて、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置は、ｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅに基づいて、ＥＳＧサービスのためのＥＳＧデータを取得することができる。この場合、ＥＳＧサービスは、ＥＳＧデータを含むファイルで提供されてもよい。

本発明の第３実施例に係る放送伝送装置がＥＳＧＡｎｎｏｕｎｃｅｍｅｎｔＣｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送ＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントは、ＤＰａｔｔｒｉｂｕｔｅを含むことができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。

また、本発明の第３実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０Ｐｒｏｆｉｌｅを追加して、ＤａｔａＰｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａＰｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。

図１３４は、本発明の第４実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。

本発明の第４実施例は、次世代放送網でＥＳＧブートストラップ情報をＳＭＴのサービスレベルディスクリプタを用いて伝送する方法を提供することができる。ＥＳＧは一つの別途のサービスと定義され、ＦＩＣのサービスループ（ＳｅｒｖｉｃｅＬｏｏｐ）でＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示し、ＳＳＣチャネルを介してＳＭＴとＣＭＴが伝送されてもよい。ＥＳＧサービスにマッピングされるＳＭＴは、ＥＳＧブートストラップディスクリプタを含むことができ、ＥＳＧブートストラップディスクリプタは、サービスレベルディスクリプタと定義されてもよい。

同図を参照すると、本発明の第４実施例に係るアクチュアルストリーム（ＡｃｔｕａｌＳｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／ＶＳｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。同図に示した第１ＲＯＵＴＥセッションに関する内容は、前述した第１ＲＯＵＴＥセッションに関する内容を全て含むことができる。

第２ＤＰ、第３ＤＰ、及び第４ＤＰは、第２ＲＯＵＴＥセッションを含むことができる。第２ＲＯＵＴＥセッションは第２サービスを含むことができる。例えば、第２サービスはＥＳＧサービスを含むことができる。第２ＲＯＵＴＥセッションは、第５伝送セッション（ｔｓｉ−０）、第６伝送セッション（ｔｓｉ−ｓｓｃ）、第７伝送セッション（ｔｓｉ−１０１）、及び／又は第８伝送セッション（ｔｓｉ−１０２）を含むことができる。同図に示した第２ＲＯＵＴＥセッションに関する内容は、前述した第２ＲＯＵＴＥセッションに関する内容を全て含むことができる。

ＦＩＣは、前述したＦＩＣに関連した内容を全て含むことができる。例えば、ＦＩＣは、パーティションを識別する少なくとも一つのＰａｒｔｉｔｉｏｎＩＤエレメント、サービスを識別するＳｅｒｖｉｃｅＩＤエレメント、サービスのカテゴリーを示すＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメント、ＳＳＣを伝送するＩＰ／Ｐｏｒｔを識別するＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣを伝送するＤＰを識別するＳＳＣＤＰ＿ＩＤエレメント、ＳＳＣを伝送する伝送セッションを識別するＴＳＩエレメント、及び／又はパーティションレベルのディスクリプタを含むことができる。

ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣブートストラップ情報であってもよい。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ３．０Ｂｒｏａｄｃａｓｔで伝送されるＳＳＣブートストラッピング情報であってもよい。本発明の第４実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。

本発明の第４実施例に係るＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。

ＳＭＴは、前述したＳＭＴに関連した内容を全て含むことができる。例えば、ＳＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ、サービスのカテゴリーを示すｃａｔｅｇｏｒｙａｔｔｒｉｂｕｔｅ、ＲＯＵＴＥセッションに関する情報を含む少なくとも一つのＲＯＵＴＥセッションエレメント、及び／又は少なくとも一つのサービスレベルディスクリプタを含むことができる。ＲＯＵＴＥセッションエレメントは、ＲＯＵＴＥセッションブートストラップ情報を含むことができる。ＲＯＵＴＥセッションエレメントは、ＬＳＩＤブートストラップ情報（又は、ＬＳＩＤ伝送経路情報）を含むことができる。ｃａｔｅｇｏｒｙａｔｔｒｉｂｕｔｅは、ＥＳＧサービスを示すことができる。

サービスレベルディスクリプタは、ＥＳＧブートストラップ情報を含むことができる。本発明の第４実施例に係るＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを示すと、ＳＭＴは、ＥＳＧブートストラップ情報を含むサービスレベルのディスクリプタを含むことができる。放送伝送装置は、サービスレベルのディスクリプタを用いてＥＳＧブートストラップ情報を伝送することができる。

ＬＳＩＤは、前述したＬＳＩＤに関連した内容を全て含むことができる。例えば、ＬＳＩＤは、第７伝送セッションに関する情報を含む第７伝送セッションエレメント（ＴＳＩ−１０１）及び／又は第８伝送セッションに関する情報を含む第８伝送セッションエレメント（ＴＳＩ−１０２）を含むことができる。それぞれの第７伝送セッションエレメント（ＴＳＩ−１０１）及び第８伝送セッションエレメント（ＴＳＩ−１０２）は、伝送セッションに含まれるソースフローに関する情報を提供するＳｏｕｒｃｅＦｌｏｗエレメント、及び／又は伝送セッションに含まれるリペアフローに関する情報を提供するＲｅｐａｉｒＦｌｏｗエレメントのうち少なくとも一つを含むことができる。ＳｏｕｒｃｅＦｌｏｗエレメントは、ＳｏｕｒｃｅＦｌｏｗエレメントがストリーミングメディアデータを伝送するか否かを示すｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅを含むことができる。例えば、ｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅが「ｔｒｕｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが実時間伝送されることを示すことができる。また、例えば、ｒｅａｌｔｉｍｅａｔｔｒｉｂｕｔｅが「ｆａｌｓｅ」であれば、ＳｏｕｒｃｅＦｌｏｗエレメントが非実時間伝送されることを示すことができる。

ＣＭＴは、前述したＣＭＴに関連した内容を全て含むことができる。例えば、ＣＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ及び／又は、当該サービス内のコンポーネントに関する情報を含むｃｏｍｐｅｌｅｍｅｎｔを含むことができる。ｃｏｍｐｅｌｅｍｅｎｔは、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングされるｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送される伝送セッションを識別するｔｓｉａｔｔｒｉｂｕｔｅ、放送ストリーム内で当該コンポーネントデータが伝送されるＤＰを識別するＤＰａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。

放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。

放送受信装置はＦＩＣを取得することができる。ＦＩＣは、ＩＰ／ＵＤＰパケットを介して伝送されてもよい。例えば、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。また、ＦＩＣは、サービスループ内にＳＳＣブートストラップ情報を含むことができる。ＳＳＣはＳＭＴ及び／又はＣＭＴを含むことができる。

放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを取得することができる。ＳＭＴは、少なくとも一つのＲＯＵＴＥセッションエレメント及び／又は少なくとも一つのサービスレベルディスクリプタを含むことができる。

放送受信装置は、ＳＭＴに含まれたＲＯＵＴＥセッションエレメントに基づいてＬＳＩＤを取得することができる。ＲＯＵＴＥセッションエレメントは、ＲＯＵＴＥセッションブートストラップ情報を含むことができ、ＲＯＵＴＥセッションブートストラップ情報は、ＬＳＩＤ伝送経路情報を含むことができる。

また、放送受信装置は、ＳＭＴに含まれたサービスレベルディスクリプタからＥＳＧブートストラップ情報を取得することができる。ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを示すと、ＳＭＴは、ＥＳＧブートストラップ情報を含むサービスレベルのディスクリプタを含むことができる。

放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを取得することができる。放送受信装置は、ＣＭＴに基づいてコンポーネントマッチング情報を取得することができる。例えば、ＣＭＴは、ＣｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅ、ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又はＤＰａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。

放送受信装置は、ＳＭＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つに基づいてＥＳＧｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいて、ＥＳＧｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＣＭＴのｔｓｉａｔｔｒｉｂｕｔｅに基づいて、ＬＳＩＤで記述する伝送セッションを取得し、これにマッピングされるＤＰ情報を取得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉａｔｔｒｉｂｕｔｅ及び／又はＤＰａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを取得することができる。例えば、実際コンポーネントは、ＥＳＧサービスのためのコンポーネントであってもよい。

具体的に、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報のうち少なくとも一つに基づいて、ＥＳＧｄａｔａ及び／又はＥＳＧサービスのためのＳＧＤＤを取得することができる。その後、放送受信装置はＳＳＤＤに基づいてＥＳＧサービスのためのＳＧＤＵを取得することができる。

ＥＳＧデータも一つのファイルと定義することができるので、放送受信装置は、ＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅに基づいて、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置は、ｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅに基づいて、ＥＳＧサービスのためのＥＳＧデータを取得することができる。この場合、ＥＳＧサービスは、ＥＳＧデータを含むファイルで提供されてもよい。

本発明の第４実施例に係る放送伝送装置がＥＳＧＡｎｎｏｕｎｃｅｍｅｎｔＣｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送ＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントは、ＤＰａｔｔｒｉｂｕｔｅを含むことができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。

また、本発明の第４実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０Ｐｒｏｆｉｌｅを追加して、ＤａｔａＰｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置は、ＳＧＤＤを受信し、ＳＧＤＤのＤａｔａＰｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。

図１３５は、本発明の第５実施例に係るＥＳＧブートストラップ情報のシグナリングを示す図である。

本発明の第５実施例は、次世代放送網でＥＳＧブートストラップ情報をＧｕｉｄｅＡｃｃｅｓｓＴａｂｌｅ（ＧＡＴ）を用いて伝送する方法を提供することができる。ＥＳＧは一つの別途のサービスと定義され、ＦＩＣのサービスループでサービスＳｅｒｖｉｃｅＣａｔｅｇｏｒｙはＥＳＧサービスを示し、ＳＳＣチャネルを介してＳＭＴ、ＧＡＴ、及び／又はＣＭＴが伝送されてもよい。ＥＳＧサービスにマッピングされるＳＭＴは、ＬＳＩＤが伝送されるＲＯＵＴＥセッション情報を含むことができる。本発明の第５実施例では、ＥＳＧサービスに対するＳＳＣはＧＡＴを含み、ＧＡＴはＥＳＧブートストラップ情報を含むことができる。

同図を参照すると、本発明の第５実施例に係るアクチュアルストリーム（ＡｃｔｕａｌＳｔｒｅａｍ）は、「Ｆｒｑｎｃｙ−ｚ」の周波数を有する放送ストリームを含むことができる。本発明の一実施例に係る放送ストリームは、第１パーティション（Ａ）を含むことができる。第１パーティション（Ａ）は、第１ＤＰ、第２ＤＰ、第３ＤＰ、第４ＤＰ、及び／又はＦＩＣを含むことができる。第１ＤＰは第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは第１サービス（Ａ／ＶＳｅｒｖｉｃｅ）を含むことができる。第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−ｖ）、第２伝送セッション（ｔｓｉ−ａ）、第３伝送セッション（ｔｓｉ−ｓ）、及び／又は第４伝送セッション（ｔｓｉ−０）を含むことができる。同図に示した第１ＲＯＵＴＥセッションに関する内容は、前述した第１ＲＯＵＴＥセッションに関する内容を全て含むことができる。

放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。

ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、ＳＳＣブートストラップ情報であってもよい。ＳＳＣブートストラッピング情報は、ＳＭＴ及び／又はＣＭＴが伝送されるＳＳＣの伝送経路情報を含むことができる。例えば、ＳＳＣＩＰ／Ｐｏｒｔエレメント、ＳＳＣＤＰ＿ＩＤエレメント、及び／又はＴＳＩエレメントは、同一の周波数内でＡＴＳＣ３．０Ｂｒｏａｄｃａｓｔで伝送されるＳＳＣブートストラッピング情報であってもよい。本発明の第５実施例に係るＦＩＣは、ＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。

本発明の第５実施例に係るＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。また、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントはＥＳＧサービスを示すと、ＧＡＴが必須に伝送されてもよい。

放送伝送装置は、ＳＭＴ、ＣＭＴ、ＧＡＴ、及び／又はＬＳＩＤのうち少なくとも一つを含む放送信号を伝送することができる。

ＳＭＴは、前述したＳＭＴに関連した内容を全て含むことができる。例えば、ＳＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ、ＲＯＵＴＥセッションに関する情報を含む少なくとも一つのＲＯＵＴＥセッションエレメントを含むことができる。ＲＯＵＴＥセッションエレメントは、ＲＯＵＴＥセッションブートストラップ情報（又は、ＬＳＩＤブートストラップ情報、ＬＳＩＤ伝送経路情報）を含むことができる。

ＧＡＴは、サービスと関連したサービスガイド（ＳｅｒｖｉｃｅＧｕｉｄｅ，ＳＧ）データソースに関する情報を含むことができる。例えば、ＧＡＴは、サービスを識別するｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ、サービスガイド提供者の数を示すｎｕｍ＿ｏｆ＿ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔ、及び／又はサービスガイド提供者に関する情報を含む少なくとも一つのＰｒｏｖｉｄｅｒｅｌｅｍｅｎｔ（サービスガイド提供者エレメント）を含むことができる。

Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧブートストラップ情報を含むことができる。例えば、Ｐｒｏｖｉｄｅｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ及び／又はＥＳＧと関連した情報を提供する提供者に関する情報を含むことができる。また、ＥＳＧブートストラップ情報は、ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ、ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅ、ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅ、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔ、及び／又はＵＲＬａｒｒｔｉｂｕｔｅのうち少なくとも一つを含むことができる。

ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラッピングディスクリプションが伝送されるタイプを示すことができる。ｂｏｏｔｓｔｒａｐ＿ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅは、前述したｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅを示すことができる。

ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラップ情報が外部周波数（ＦｏｒｅｉｇｎＦｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。ｔｓ＿ＩＤａｔｔｒｉｂｕｔｅは、前述したｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔを示すことができる。

ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅは、ＥＳＧブートストラップ情報が外部周波数（Ｆｏｒｅｉｇｎｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。ｐａｒｔｉｔｉｏｎＩＤａｔｔｒｉｂｕｔｅは、前述したｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔを示すことができる。

Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔは、ＲＯＵＴＥセッションを識別する情報を含むことができる。例えば、Ｒｏｕｔｅ＿ｓｅｓｓｉｏｎｅｌｅｍｅｎｔはＩＰ（ｓｒｃ／ｄｅｓｔ）ｅｌｅｍｅｎｔ、ｐｏｒｔｅｌｅｍｅｎｔ、ａｎｎｏｕｎｃｅｍｅｎｔ＿ｔｓｉｅｌｅｍｅｎｔ、ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。ＩＰ（ｓｒｃ／ｄｅｓｔ）ａｔｔｒｉｂｕｔｅは、前述したｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ及びｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔを含むことができる。ｐｏｒｔａｔｔｒｉｂｕｔｅは、前述したｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔを示すことができる。ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔ、及びｐｏｒｔｅｌｅｍｅｎｔの組合せは、特定ＲＯＵＴＥセッションを識別することができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ｔｓｉｅｌｅｍｅｎｔは、ＥＳＧサービス及び／又はＥＳＧブートストラップ情報が伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰｅｌｅｍｅｎｔは、ＥＳＧサービス及び／又はＥＳＧブートストラップ情報が伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。ａｎｎｏｕｎｃｅｍｅｎｔ＿ＤＰｅｌｅｍｅｎｔは、前述したｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔを示すことができる。

ＵＲＬｅｌｅｍｅｎｔは、ブロードバンドで伝送されるＥＳＧブートストラップ情報及び／又はＥＳＧのためのシグナリング情報に接近し得るＵＲＬを示すことができる。ＵＲＬｅｌｅｍｅｎｔは、前述したｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔを示すことができる。

放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。例えば、サービスデータはＥＳＧデータを含むことができる。シグナリング情報は、ＦＩＣ、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤを含むことができる。

放送受信装置はＦＩＣを取得することができる。ＦＩＣは、ＩＰ／ＵＤＰパケットを介して伝送されてもよい。例えば、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントは、ＥＳＧサービスを示すことができる。また、ＦＩＣはサービスループ内にＳＳＣブートストラップ情報を含むことができる。また、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙエレメントがＥＳＧサービスを示すと、ＧＡＴが必須に伝送されてもよい。

放送受信装置はＦＩＣに基づいてＳＳＣブートストラップ情報を取得することができる。ＳＳＣは、ＳＭＴ、ＣＭＴ、及び／又はＧＡＴを含むことができる。

放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＳＭＴを取得することができる。放送受信装置は、ＳＭＴに含まれたＲＯＵＴＥセッションエレメントに基づいて、ＲＯＵＴＥブートストラップ情報（又は、ＬＳＩＤブートストラップ情報、ＬＳＩＤ伝送経路情報）を取得することができる。また、放送受信装置はＳＭＴに基づいてＬＳＩＤを取得することができる。具体的に、放送受信装置はＳＭＴのＲＯＵＴＥブートストラップ情報に基づいてＬＳＩＤを取得することができる。

放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＧＡＴを取得することができる。また、放送受信装置は、ＧＡＴからＥＳＧブートストラップ情報を取得することができる。

放送受信装置は、ＦＩＣに含まれたＳＳＣブートストラップ情報に基づいてＣＭＴを取得することができる。また、放送受信装置はＣＭＴに基づいてコンポーネントマッチング情報を取得することができる。例えば、ＣＭＴは、ＣｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅ、ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又はＤＰａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。

放送受信装置は、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つに基づいて、ＥＳＧｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＬＳＩＤ、ＥＳＧブートストラップ情報、及び／又はＣＭＴのコンポーネントマッチング情報に基づいて、ＥＳＧｄａｔａ及び／又はＥＳＧサービスを取得することができる。例えば、放送受信装置は、ＣＭＴのｔｓｉａｔｔｒｉｂｕｔｅに基づいて、ＬＳＩＤで記述する伝送セッションを取得し、これにマッピングされるＤＰ情報を取得することができる。すなわち、放送受信装置は、ＣＭＴのｔｓｉａｔｔｒｉｂｕｔｅ及び／又はＤＰａｔｔｒｉｂｕｔｅに基づいて実際コンポーネントを取得することができる。例えば、実際コンポーネントはＥＳＧサービスのためのコンポーネントであってもよい。

ＥＳＧデータも一つのファイルと定義することができるので、放送受信装置は、ＣＭＴに含まれたｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅに基づいて、ＦＬＵＴＥのＦＤＴに定義されているｃｏｎｔｅｎｔＬｉｎｋａｇｅとマッピングすることができる。すなわち、放送受信装置は、ｃｏｎｔｅｎｔＬｉｎｋａｇｅａｔｔｒｉｂｕｔｅに基づいてＥＳＧサービスのためのＥＳＧデータを取得することができる。この場合、ＥＳＧサービスは、ＥＳＧデータを含むファイルで提供されてもよい。

本発明の第５実施例に係る放送伝送装置がＥＳＧＡｎｎｏｕｎｃｅｍｅｎｔＣｈａｎｎｅｌ情報を取得してＥＳＧデータを伝送（又は、ｄｅｌｉｖｅｒｙ）するためには、放送伝送装置は、ＬＳＩＤでそれぞれの伝送セッション別に伝送ＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を追加することができる。すなわち、ＬＳＩＤのそれぞれの伝送セッションエレメントは、ＤＰａｔｔｒｉｂｕｔｅを含むことができる。その結果、放送伝送装置はＳＧＤＵを伝送することができる。放送受信装置は、それぞれの伝送セッション別にＤａｔａＰｉｐｅｌｉｎｅ情報（又は、ＰＬＰ識別子）を含むＬＳＩＤを受信し、ＬＳＩＤに基づいてＳＧＤＵを取得することができる。

また、本発明の第５実施例に係る放送伝送装置は、ＳＧＤＤのシンタックス（Ｓｙｎｔａｘ）にＡＴＳＣ３．０Ｐｒｏｆｉｌｅを追加して、ＤａｔａＰｉｐｅｌｉｎｅ情報を追加することができる。この場合、放送受信装置はＳＧＤＤを受信て、ＳＧＤＤのＤａｔａＰｉｐｅｌｉｎｅ情報に基づいてＳＧＤＵを取得することができる。

図１３６は、本発明の第５実施例に係るＧＡＴを示す図である。

次世代放送網で使用可能なシグナリング情報のフォーマットは次のとおりである。シグナリング情報は、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。シグナリングメッセージは、ｂｉｎａｒｙ或いはＸＭＬフォーマットなどで）表現されてもよい。また、シグナリングメッセージは、ＩＰデータグラム又はアプリケーションレイヤ伝送パケット（例えば、ＲＯＵＴＥ或いはＭＭＴなど）のペイロードに含まれて伝送されてもよい。例えば、シグナリングメッセージはＧＡＴを含むことができる。

シグナリングメッセージヘッダーは、Ｓｉｇｎａｌｉｎｇ＿ｉｄｅｌｅｍｅｎｔ及び／又はＳｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。Ｓｉｇｎａｌｉｎｇ＿ｉｄｅｌｅｍｅｎｔは、シグナリングメッセージの識別子を示すことができる。例えば、Ｓｉｇｎａｌｉｎｇ＿ｉｄｅｌｅｍｅｎｔはＧＡＴシグナリングメッセージを示すことができる。Ｓｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔはサービスの識別子を示すことができる。例えば、Ｓｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔはＥＳＧサービスを示すことができる。一方、ＳＭＴには、Ｓｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔにマッピングされる識別子が存在してもよい。

ＧＡＴは、少なくとも一つのサービスレベルのディスクリプタを含むことができる。例えば、ＧＡＴはＥＳＧブートストラッピングディスクリプションを含むことができる。

ＥＳＧブートストラッピングディスクリプションは、ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ（ＥＳＧ）のブートストラッピングのための情報を含むことができる。ＥＳＧブートストラッピングディスクリプションは、ＥＳＧブートストラップ情報及び／又はＥＳＧのためのブートストラッピング情報を含むことができる。放送受信装置は、ＥＳＧブートストラッピングディスクリプション及び／又はＥＳＧブートストラップ情報に基づいてＥＳＧを受信、取得、及び／又は処理することができる。

Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは、少なくとも一つのブートストラッピング情報を含むことができる。Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ、ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔ、ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔ、ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔ、ｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔ、ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔ、ｔｓｉｅｌｅｍｅｎｔ、及び／又はｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、ＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔはＥＳＧブートストラップ情報であってもよい。

ｎｅｔｗｏｒｋ＿ｔｙｐｅｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが伝送されるタイプを示すことができる。

ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ、及び／又はＳＧｄａｔａのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すことができる。例えば、ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧに関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰｓｏｕｒｃｅａｄｄｒｅｓｓを含むことができる。

ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ、及び／又はＳＧｄａｔａのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すことができる。例えば、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧに関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのＩＰｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓを含むことができる。

ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔは、ＥＳＧｄａｔａ、及び／又はＳＧｄａｔａのｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ番号を示すことができる。例えば、ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔは、サービス及び／又はＥＳＧに関連した情報のためのサービスレイヤシグナリング情報を伝送するパケットのポート番号を含むことができる。

ｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが外部周波数（ＦｏｒｅｉｇｎＦｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）の伝送ストリーム識別子（ｔｒａｎｓｐｏｒｔｓｔｒｅａｍＩＤ）を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。

ｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが外部周波数（Ｆｏｒｅｉｇｎｆｒｅｑｕｅｎｃｙ）で伝送される場合、当該周波数（ｆｒｅｑｕｅｎｃｙ）のパーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）を示すことができる。例えば、パーティション識別子（ｐａｔｒｉｔｉｏｎＩＤ）は放送会社を識別することができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。

ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが伝送されるＰＬＰ及び／又はＤＰを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧｄａｔａがブロードキャストで伝送される場合、ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔは一つの値を含むことができる。

ｔｓｉｅｌｅｍｅｎｔは、ＥＳＧｄａｔａが伝送される伝送セッション及び／又はＬＣＴセッションを識別する識別子を示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧｄａｔａがブロードキャストで伝送される場合、ｔｓｉｅｌｅｍｅｎｔは少なくとも一つの値を含むことができる。

ｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔは、ブロードバンドで伝送されるＥＳＧｄａｔａに接近し得るＵＲＬを示すことができる。この値は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅの値によって選択的にＢｏｏｔｓｔｒａｐｅｌｅｍｅｎｔに含まれてもよい。例えば、ＥＳＧｄａｔａがブロードバンドで伝送される場合、ｄｏｗｎｌｏａｄＵＲＬｅｌｅｍｅｎｔは一つの値を含むことができる。

放送伝送装置は、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる。サービスデータはＥＳＧサービスを含むことができる。シグナリング情報はＧＡＴを含み、ＧＡＴはサービスレベルディスクリプタにＥＳＧブートストラップ情報を含むことができる。放送受信装置は、サービスデータ及びシグナリング情報を含む放送信号を受信することができる。放送受信装置は、シグナリング情報に含まれたＥＳＧブートストラップ情報に基づいてＥＳＧサービスを取得及び／又は処理することができる。

図１３７は、本発明の第１実施例乃至第５実施例の効果を示す図である。

本発明の第１実施例の効果について説明する。

ＦＩＣＰｕｒｐｏｓｅ（Ｆａｓｔｃｈａｎｎｅｌｓｃａｎ）と関連して、本発明の第１実施例ではＦａｓｔＳｃａｎとは関係ない情報が反復的に伝送されてもよい。例えば、ＦＩＣはパーティションレベルのディスクリプタにＥＳＧブートストラップ情報を含むことができる。したがって、本発明の第１実施例ではＥＳＧブートストラップ情報が反復的に伝送されてもよい。

ＦＩＣｓｉｚｅと関連して、本発明の第１実施例では、ＥＳＧがサービスと定義されないので、サービスループ（ｓｅｒｖｉｃｅｌｏｏｐ）から除外されるサイズ分だけＦＩＣのサイズを節約することができる。例えば、サービスループでＳＳＣブートストラップ情報が除外されるサイズだけＦＩＣのサイズを節約することができる。また、ＥＳＧブートストラップ情報分だけＦＩＣのサイズを増加させることができる。

ＦＩＣｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第１実施例では、ＥＳＧがサービスと定義されないので、ＦＩＣｓｅｍａｎｔｉｃｓ定義は明確である。例えば、サービスループにはＥＳＧブートストラップ情報が含まれず、パーティションレベルのディスクリプタにＥＳＧブートストラップ情報が含まれる。

ＥＳＧブートストラップ情報取得時間と関連して、本発明の第１実施例ではＥＳＧブートストラップ情報が変更する度にＦＩＣも継続して変更される。したがって、本発明の第１実施例では、ＦＩＣに含まれたＥＳＧブートストラップ情報を速かに取得することができる。

明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第１実施例ではＥＳＧがサービスと定義されないので、ＦＩＣｓｅｍａｎｔｉｃｓ定義は明確である。

ＬＳＩＤの拡張と関連して、本発明の第１実施例では、ＤＰ情報のマッピングのためにＬＳＩＤにＴＳＩとＤＰのマッピングに関する定義が必要である。

一貫性と関連して、本発明の第１実施例では、ＦＩＣは一貫性を維持し、ＳＳＣは存在しなくてもよい。

本発明の第２実施例の効果について説明する。

ＦＩＣＰｕｒｐｏｓｅ（Ｆａｓｔｃｈａｎｎｅｌｓｃａｎ）と関連して、本発明の第２実施例では、ＦａｓｔＳｃａｎとは関係ない情報が反復的に伝送されてもよい。例えば、ＦＩＣは、サービスループのＳＳＣブートストラップ情報がＥＳＧブートストラップ情報に置き換えられてもよい。又は、ＳＳＣブートストラップ情報がＥＳＧブートストラップ情報に該当してもよい。したがって、本発明の第２実施例ではＥＳＧブートストラップ情報が反復的に伝送されてもよい。

ＦＩＣｓｉｚｅと関連して、本発明の第２実施例では、ＦＩＣがＥＳＧブートストラップ情報のためにｓｏｕｒｃｅＩＰａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔｎｕｍｂｅｒ、ＴＳＩ情報、及び／又はＤＰ情報などを含む場合にはＦＩＣのサイズが増加しない。しかし、ＦＩＣがＥＳＧブートストラップ情報のために外部周波数（ｆｏｒｅｉｇｎｆｒｅｑｕｅｎｃｙ）のブロードキャスト情報及びブロードバンド情報を含む場合にはＦＩＣのサイズが増加しうる。

ＦＩＣｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第２実施例では、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ別にＳＳＣの用途が変更されてもよい。例えば、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙがＥＳＧサービスを示すと、ＳＳＣブートストラップ情報は、ＥＳＧブートストラップ情報に置き換えられてもよい。又は、ＳＳＣブートストラップ情報がＥＳＧブートストラップ情報に該当してもよい。ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙがＥＳＧサービスを示すと、ＳＳＣブートストラップ情報は、本来の目的に用いられてもよい。

ＥＳＧブートストラップ情報取得時間と関連して、本発明の第２実施例では、ＥＳＧブートストラップ情報が変更される度にＦＩＣも継続して変更される。したがって、本発明の第２実施例では、ＦＩＣに含まれたＥＳＧブートストラップ情報を速かに取得することができる。

明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第２実施例では、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙによるＳＳＣブートストラップ情報の定義が変更されてもよい。また、本発明の第２実施例では、シグナリング情報はＳＭＴ及び／又はＣＭＴを含まなくてもよい。

ＬＳＩＤの拡張と関連して、本発明の第２実施例では、ＤＰ情報のマッピングのために、ＬＳＩＤにＴＳＩとＤＰのマッピングに関する定義が必要である。

一貫性と関連して、本発明の第２実施例では、サービスがＳｅｒｖｉｃｅＣａｔｅｇｏｒｙで分類されるにもかかわらず、シグナリング情報にＳＭＴ及び／又はＣＭＴが含まれなくてもよい。

本発明の第３実施例の効果について説明する。

ＦＩＣｓｉｚｅと関連して、本発明の第３実施例では、ＥＳＧサービスのためのＦＩＣのサイズはＡ／ＶサービスのためのＦＩＣのサイズと同一であってもよい。

ＦＩＣｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第３実施例では、ＦＩＣはＳＳＣが伝送される情報を示すＳＳＣブートストラップ情報を含むことができる。

ＥＳＧブートストラップ情報取得時間と関連して、本発明の第３実施例では、ＥＳＧブートストラップ情報はＦＩＣに含まれず、第１実施例及び第２実施例に比べはＥＳＧブートストラップ情報の取得が遅い。

サービスシグナリング帯域幅（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＢａｎｄｗｉｄｔｈ）と関連して、本発明の第３実施例では、ＳＭＴを頻繁に伝送しなければならないという点を考慮すると、ＥＳＧブートストラップ情報をディスクリプタに含める場合、シグナリング帯域幅（ＳｉｇｎａｌｉｎｇＢａｎｄｗｉｄｔｈ）側面で効率性はやや低下しうる。

明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第３実施例では、ＳＭＴのＬＳＩＤ伝送情報に対する定義と提供者（Ｐｒｏｖｉｄｅｒ）に対する定義を区別しなければならない。

ＬＳＩＤの拡張と関連して、本発明の第３実施例では、ＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要である。ＣＭＴは、ＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。

本発明の第４実施例の効果について説明する。

ＦＩＣｓｉｚｅと関連して、本発明の第４実施例では、ＥＳＧサービスのためのＦＩＣのサイズはＡ／ＶサービスのためのＦＩＣのサイズと同一であってもよい。

ＦＩＣｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第４実施例では、ＦＩＣはＳＳＣが伝送される情報を示すＳＳＣブートストラップ情報を含むことができる。

ＥＳＧブートストラップ情報取得時間と関連して、本発明の第４実施例では、ＥＳＧブートストラップ情報はＦＩＣに含まれず、第１実施例及び第２実施例に比べてはＥＳＧブートストラップ情報の取得が遅い。ただし、本発明の第４実施例に係るＥＳＧブートストラップ情報取得時間は、本発明の第３実施例に係るＥＳＧブートストラップ情報取得時間とは同一であってもよい。

サービスシグナリング帯域幅（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＢａｎｄｗｉｄｔｈ）と関連して、本発明の第４実施例では、ＳＭＴを頻繁に伝送しなければならないという点を考慮すると、ＥＳＧブートストラップ情報をディスクリプタに含める場合、シグナリング帯域幅（ＳｉｇｎａｌｉｎｇＢａｎｄｗｉｄｔｈ）側面で効率性はやや低下しうる。

明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第４実施例では、ＦＩＣはＳＳＣブートストラップ情報を含み、ＳＭＴはＥＳＧブートストラップ情報を含むので、明確なＳｅｍａｎｔｉｃｓ定義が可能である。

ＬＳＩＤの拡張と関連して、本発明の第４実施例ではＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要である。ＣＭＴは、ＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。

一貫性と関連して、本発明の第４実施例では、ＳＭＴのサービスレベルディスクリプタでＥＳＧブートストラップ情報が伝送される点が一貫しない。

本発明の第５実施例の効果について説明する。

ＦＩＣｓｉｚｅと関連して、本発明の第５実施例では、ＥＳＧサービスのためのＦＩＣのサイズはＡ／ＶサービスのためのＦＩＣのサイズと同一であってもよい。

ＦＩＣｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第５実施例では、ＦＩＣはＳＳＣが伝送される情報を示すＳＳＣブートストラップ情報を含むことができる。

ＥＳＧブートストラップ情報取得時間と関連して、本発明の第５実施例に係るＥＳＧブートストラップ情報取得時間は、本発明の第４実施例に係るＥＳＧブートストラップ情報取得時間よりは遅い。

サービスシグナリング帯域幅（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＢａｎｄｗｉｄｔｈ）と関連して、本発明の第５実施例では、ＧＡＴをＳＭＴに比べて頻繁に伝送しないと、帯域幅（Ｂａｎｄｗｉｄｔｈ）を節約することができる。

明確なｓｅｍａｎｔｉｃｓ定義と関連して、本発明の第５実施例では、ＦＩＣはＳＳＣブートストラップ情報を含み、ＳＭＴはＲＯＵＴＥブートストラップ情報（ＬＳＩＤ伝送経路情報）を含み、ＧＡＴはＥＳＧブートストラップ情報を含むので、明確なＳｅｍａｎｔｉｃｓ定義が可能である。

ＬＳＩＤの拡張と関連して、本発明の第５実施例では、ＬＳＩＤの拡張が必須ではないが、ＣＭＴの拡張が必要である。ＣＭＴは、ＴＳＩによるＤＰの構成情報及び／又はＣｏｎｔｅｎｔＬｉｎｋａｇｅによるＤＰの構成情報を含むことができる。

図１３８は、本発明の一実施例に係る放送受信装置の流れを示す図である。

本発明の一実施例に係る放送受信装置は、ブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部のうち少なくとも一つを含むことができる。本発明の一実施例に係るブロードキャストインターフェース、ブロードバンドインターフェース、及び／又は制御部は、前述した内容を全て含むことができる。

例えば、ブロードキャストインターフェースは、放送網を介して放送信号を受信することができる。ブロードキャストインターフェースは、フィジカルレイヤモジュール、フィジカルレイヤＩＰフレームモジュールを含むことができる。又はブロードキャストインターフェースは、チューナー及びフィジカルフレームパーサーのうち少なくとも一つを含むことができる。

例えば、ブロードバンドインターフェースは、インターネット網を介してデータを伝送及び／又は受信することができる。ブロードバンドインターフェースは、インターネット接近制御モジュールを含むことができる。

例えば、制御部は、前述したシグナリングデコーダ、データベース、サービスシグナリングマネジャー、アラートシグナリングマネジャー、サービスガイドマネジャー、アプリケーションシグナリングマネジャー、ターゲッティングシグナリングマネジャー、ストリーミングメディアエンジン、非実時間ファイルプロセッサ、コンポーネント同期化部、ターゲッティングプロセッサ、アプリケーションプロセッサ、アラーティングプロセッサ、Ａ／Ｖプロセッサ、再分配モジュール、サービス／コンテンツ取得制御部、及び／又はコンパニオンスクリーンインターフェースのうち少なくとも一つを含むことができる。コンパニオンスクリーンインターフェースは、データシェアリング部及び／又は装置管理者のうち少なくとも一つを含むことができる。本発明の一実施例に係る制御部に含まれる構成要素に関する内容は、前述した同一又は類似の名称を有する構成要素に関する内容を全て含むことができる。

また、制御部は、前述したフィジカルレイヤ制御部、リンクレイヤフレームパーサー（又は、リンクレイヤフレームプロセッサ）、ＩＰ／ＵＤＰデータグラムフィルター、アプリケーションレイヤ伝送クライアント、タイミングコントロール、システムクロック、ＤＴＶコントロールエンジン、ユーザ入力受信部、シグナリングパーサー、チャネルマップデータベース、ＨＴＴＰアクセスクライアント、ＨＴＴＰアクセスキャッシュ、ＤＡＳＨクライアント、ＩＳＯＢＭＦＦパーサー、メディアデコーダ及びファイルデータベースのうち少なくとも一つを含むことができる。本発明の一実施例に係る制御部に含まれる構成要素に関する内容は、前述した同一又は類似の名称を有する構成要素に関する内容を全て含むことができる。

放送受信装置は、ブロードキャストインターフェースを用いて、サービスデータ及びシグナリング情報を含む放送信号を受信することができる（ＣＳ１３８０１００）。

シグナリング情報は、サービスの取得のための第１シグナリング情報を含むことができる。例えば、第１シグナリング情報は、ＳＭＴ、ＧＡＴ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。

また、シグナリング情報は、第１シグナリング情報のブートストラップ発見を提供する第２シグナリング情報を含むことができる。すなわち、シグナリング情報は、サービスのためのブートストラップ情報を含む第２シグナリング情報を含むことができる。例えば、第２シグナリング情報は、ＦＩＣを含むことができる。

また、サービスデータは、ＥＳＧデータを含むことができる。

また、シグナリング情報は、ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ（ＥＳＧ）データのためのＥＳＧブートストラップ情報を含むことができる。

その後、放送受信装置は、制御部を用いて、シグナリング情報に基づいてサービスデータを取得することができる（ＣＳ１３８０２００）。

その後、放送受信装置は、制御部を用いて、サービスデータをデコーティングすることができる（ＣＳ１３８０３００）。

例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータの伝送タイプを示すタイプ情報（又は、ｎｅｔｗｏｒｋ＿ｔｙｐｅａｔｔｒｉｂｕｔｅ）を含むことができる。

例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータのｓｏｕｒｃｅＩＰａｄｄｒｅｓｓを示すｓｏｕｒｃｅＩＰＡｄｄｒｅｓｓｅｌｅｍｅｎｔ（又は、ｓｏｕｒｃｅＩＰＡｄｄｒｅｌｅｍｅｎｔ）、ＥＳＧデータのｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓを示すｄｅｓｔｉｎａｔｉｏｎＩＰａｄｄｒｅｓｓｅｌｅｍｅｎｔ（又は、ｄｅｓｔＩＰＡｄｄｒｅｌｅｍｅｎｔ）、ＥＳＧデータのｄｅｓｔｉｎａｔｉｏｎｐｏｒｔｎｕｍｂｅｒを示すｄｅｓｔｉｎａｔｉｏｎｐｏｒｔｎｕｍｂｅｒｅｌｅｍｅｎｔ（又は、ｄｅｓｔＵＤＰＰｏｒｔｅｌｅｍｅｎｔ）のうち少なくとも一つを含むことができる。

例えば、ＥＳＧブートストラップ情報は、ＥＳＧデータが伝送される周波数を識別するｔｒａｎｓｐｏｒｔＳｔｒｅａｍＩＤｅｌｅｍｅｎｔ、上記周波数のパーティションを識別するｐａｒｔｉｔｉｏｎＩＤｅｌｅｍｅｎｔ、ＥＳＧデータが伝送されるＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ（ＰＬＰ）を示すＰＬＰＩＤｅｌｅｍｅｎｔ（又は、ｄａｔａｐｉｐｅＩＤｅｌｅｍｅｎｔ）、ＥＳＧデータが伝送される伝送セッションを示すＴＳＩｅｌｅｍｅｎｔ（又は、ｔｓｉｅｌｅｍｅｎｔ）、及び／又はブロードバンドを介して伝送されるＥＳＧデータの位置を示すＵＲＬｅｌｅｍｅｎｔ（又は、ｄｏｗｎｌｏａｄＵＲＬａｔｔｒｉｂｕｔｅ）のうち少なくとも一つを含むことができる。

また、第２シグナリング情報は、ＥＳＧブートストラップ情報を含むことができる。また、第２シグナリング情報は、サービスのカテゴリーを示すカテゴリー情報（又は、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙｅｌｅｍｅｎｔ）を含むことができる。また、カテゴリー情報はＥＳＧサービスを示すことができる。

また、第１シグナリング情報は、伝送セッションに関する情報を含む伝送セッションｅｌｅｍｅｎｔを含み、伝送セッションエレメントは、伝送セッションのためのＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ（ＰＬＰ）を示すＰＬＰＩＤｅｌｅｍｅｎｔ（又は、ＤＰａｔｔｒｉｂｕｔｅ）を含むことができる。

以上では放送受信装置について説明したが、本発明の一実施例によれば、放送受信装置との反対の機能を有する放送伝送装置を含むことができる。例えば、放送伝送装置は、制御部及び／又は伝送部を含むことができる。制御部は、前述したサービスデータ、及び／又は前述したシグナリング情報を生成することができる。また、伝送部は、サービスデータ及び／又はシグナリング情報を含む放送信号を伝送することができる。

図１３９は、本発明の一実施例に係るチャネルマップ構成方法を示す図である。

本発明の一実施例は、デバイス性能（ｄｅｖｉｃｅｃａｐａｂｉｌｉｔｙ）によって差別化したチャネルマップを構成する方法を提供することができる。それぞれのサービスに必要なデバイス性能（ｄｅｖｉｃｅｃａｐａｂｉｌｉｔｙ）の識別のために、本発明の一実施例に係るＦＩＣは、ＦＩＣループにｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅを含むことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、デバイス性能（ｄｅｖｉｃｅｃａｐａｂｉｌｉｔｙ）を識別することができる。放送受信装置はＦＩＣを受信し、ＦＩＣのｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅに基づいて、デバイス性能（ｄｅｖｉｃｅｃａｐａｂｉｌｉｔｙ）に符合する差別化したチャネルマップを構成（又は、生成）することができる。

以は、図面を参照して本発明の一実施例に係る放送信号の構造を説明する。

特定の周波数を有する放送信号は、シグナリング情報を含むことができる。例えば、シグナリング情報は、ＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣは、ＳＬＴと呼ぶことができる。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。

特定の周波数を有する放送信号は、同一のコンデンツを含む高鮮明ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎｖｉｄｅｏ，ＨＤ）サービス及び超高鮮明ビデオ（ＵｌｔｒａＨｉｇｈＤｅｆｉｎｉｔｉｏｎｖｉｄｅｏ，ＵＨＤ）サービスを含むことができる。それぞれのサービスは、少なくとも一つのＲＯＵＴＥ（Ｒｅａｌ−ＴｉｍｅＯｂｊｅｃｔＤｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）セッションを介して伝送されてもよい。そのために、放送信号は少なくとも一つのＲＯＵＴＥセッションを含むことができる。それぞれのＲＯＵＴＥセッションは、サービスレイヤシグナリング情報及び少なくとも一つのコンポーネントを含むことができる。また、それぞれのＲＯＵＴＥセッションは、ｓｏｕｒｃｅＩＰＡｄｄｒｅｓｓ、ｄｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ、及びｄｅｓｔｉｎａｔｉｏｎｐｏｒｔｎｕｍｂｅｒの組合せで識別されてもよい。また、それぞれのＲＯＵＴＥセッションは、少なくとも一つのＤＰ及び／又はＰＬＰを介して伝送されてもよい。また、それぞれのＲＯＵＴＥセッションは、少なくとも一つの伝送セッション（又は、ＬＣＴセッション）を含むことができる。それぞれの伝送セッションは、ＴＳＩで識別されてもよい。また、それぞれの伝送セッションは、シグナリング情報及び／又はコンデンツコンポーネントを含むことができる。例えば、伝送セッションに含まれるシグナリング情報は、サービスレイヤシグナリング情報（ＳＬＳ）を含むことができる。また、コンデンツコンポーネントは、ビデオコンポーネント及び／又はオーディオコンポーネントを含むことができる。

放送信号は、第１ＲＯＵＴＥセッション及び第２ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、ＨＤサービスを含むことができる。第２ＲＯＵＴＥセッションは、ＵＨＤサービスのための付加情報を含むことができる。ＨＤサービスは第１ＲＯＵＴＥセッションを介して伝送されてもよい。ＵＨＤサービスは第１ＲＯＵＴＥセッション及び第２ＲＯＵＴＥセッションを介して伝送されてもよい。

各サービスに対してそれぞれサービスレイヤシグナリング情報が存在してもよい。例えば、ＨＤサービスに対して、第１ＲＯＵＴＥセッションに、ＨＤサービスのためのサービスレイヤシグナリング情報が存在してもよい。また、ＵＨＤサービスに対して、第２ＲＯＵＴＥセッションに、ＵＨＤサービスのためのサービスレイヤシグナリング情報が存在してもよい。第１ＲＯＵＴＥセッションに存在するＨＤサービスのためのサービスレイヤシグナリング情報は、ＵＨＤサービスのためのサービスレイヤシグナリング情報として活用されてもよい。ここで、サービスレイヤシグナリング情報は、ＬＳＩＤ及びＳＳＣ（ＳＭＴ、ＭＤＰ、及び／又はＣＭＴ）のうち少なくとも一つを含むことができる。

第１ＲＯＵＴＥセッションは、ｓｏｕｒｃｅＩＰＡｄｄｒｅｓｓ（ｓｉｐ−ｈｄ）、ｄｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ（ｉｐ−ｈｄ）、及びｄｅｓｔｉｎａｔｉｏｎｐｏｒｔｎｕｍｂｅｒ（ｕｄｐ−ｈｄ）の組合せで識別されてもよい。また、第１ＲＯＵＴＥセッションは、第１ＤＰ（ｄｐ−１）及び第２ＤＰ（ｄｐ−２）を介して伝送されてもよい。また、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−０）、第２伝送セッション（ｔｓｉ−ａ）、及び第３伝送セッション（ｔｓｉ−ｖ−ｂ）を含むことができる。第１伝送セッション（ｔｓｉ−０）は、ＬＳＩＤ及びシグナリングテーブルを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴのうち少なくとも一つを含むことができる。第２伝送セッション（ｔｓｉ−ａ）はオーディオコンポーネントを含むことができる。例えば、オーディオコンポーネントは少なくとも一つのオーディオセグメントを含むことができる。第３伝送セッション（ｔｓｉ−ｖ−ｂ）はベースビデオコンポーネントを含むことができる。例えば、ベースビデオコンポーネントは、少なくとも一つのベースビデオセグメントを含むことができる。例えば、ベースビデオコンポーネントは、ＨＤサービスを提供するためのビデオコンポーネントである。

第２ＲＯＵＴＥセッションは、ｓｏｕｒｃｅＩＰＡｄｄｒｅｓｓ（ｓｉｐ−ｕｈｄ）、ｄｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ（ｉｐ−ｕｈｄ）、及びｄｅｓｔｉｎａｔｉｏｎｐｏｒｔｎｕｍｂｅｒ（ｕｄｐ−ｕｈｄ）の組合せで識別されてもよい。また、第２ＲＯＵＴＥセッションは、第３ＤＰ（ｄｐ−３）及び第４ＤＰ（ｄｐ−４）を介して伝送されてもよい。また、第２ＲＯＵＴＥセッションは、第４伝送セッション（ｔｓｉ−０）及び第５伝送セッション（ｔｓｉ−ｖ−ｅ）を含むことができる。第４伝送セッション（ｔｓｉ−０）は、ＬＳＩＤ及びシグナリングテーブルを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴのうち少なくとも一つを含むことができる。第５伝送セッション（ｔｓｉ−ｖ−ｅ）はエンハンスメントビデオコンポーネントを含むことができる。例えば、エンハンスメントビデオコンポーネントは、少なくとも一つのエンハンスメントビデオセグメントを含むことができる。例えば、エンハンスメントビデオコンポーネントは、ＵＨＤサービスを提供するためのビデオコンポーネント及び／又は付加情報である。

以下ではＦＩＣについて説明する。

ＦＩＣは、ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ（ＳＬＴ）と呼ぶことができる。ＳＬＴは、基本的なサービスリストを樹立（ｂｕｉｌｄｉｎｇ）し、サービスレイヤシグナリング情報（ＳＬＳ）のブートストラップ情報を提供するシグナリング情報テーブルである。

ＦＩＣは、ｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。

ｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅは、サービスを識別する識別子である。

ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、ＦＩＣに含まれてもよく、ＳＬＳに含まれてもよい。性能のカテゴリーは、ＤｏｗｎｌｏａｄＰｒｏｔｏｃｏｌ、ＦＥＣＡｌｇｏｒｉｔｈｍ、Ｗｒａｐｐｅｒ／ＡｒｃｈｉｖｅＦｏｒｍａｔ、ＣｏｍｐｒｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍ、ＭｅｄｉａＴｙｐｅ、及び／又はＩｎｔｅｒｎｅｔＬｉｎｋのうち少なくとも一つを含むことができる。

例えば、ＤｏｗｎｌｏａｄＰｒｏｔｏｃｏｌと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、ＦＬＵＴＥｐｒｏｔｏｃｏｌ及び／又はＨＴＴＰのうち少なくとも一つを示すことができる。また、ＦＥＣＡｌｇｏｒｉｔｈｍと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、ＣｏｍｐａｃｔＮｏ−ＣｏｄｅＦＥＣｓｃｈｅｍｅ及び／又はＲａｐｔｏｒａｌｇｏｒｉｔｈｍのうち少なくとも一つを示すことができる。また、Ｗｒａｐｐｅｒ／ＡｒｃｈｉｖｅＦｏｒｍａｔと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、ＤＥＣＥＣＦＦｃｏｎｔａｉｎｅｒｇｅｎｅｒａｌｆｏｒｍａｔ、ＺＩＰｆｏｒｍａｔ、ＤＥＣＥＣＦＦｃｏｎｔａｉｎｅｒｆｏｒｍａｔ、ＤＥＣＥＣＦＦｃｏｎｔａｉｎｅｒｆｏｒｍａｔ、ＤＥＣＥＣＦＦｃｏｎｔａｉｎｅｒｆｏｒｍａｔ、ＩＳＯＢａｓｅＭｅｄｉａＦｉｌｅＦｏｒｍａｔｆｏｒＡＡＣａｕｄｉｏ、ＡＴＳＣｃｏｍｐｌｉａｎｔＭＰＥＧ−２ｔｒａｎｓｐｏｒｔｓｔｒｅａｍ、ＭＰ４ｃｏｎｓｔｒａｉｎｅｄｃｏｎｔａｉｎｅｒｆｏｒｍａｔ、及び／又はＷ３ＣＷｅｂＡｐｐｓＰａｃｋａｇｅのうち少なくとも一つを示すことができる。また、ＣｏｍｐｒｅｓｓｉｏｎＡｌｇｏｒｉｔｈｍと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、ＤＥＦＬＡＴＥａｌｇｏｒｉｔｈｍを示すことができる。また、ＭｅｄｉａＴｙｐｅと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、ＡＶＣｓｔａｎｄａｒｄｄｅｆｉｎｉｔｉｏｎｖｉｄｅｏ、ＡＶＣｈｉｇｈｄｅｆｉｎｉｔｉｏｎｖｉｄｅｏ、ＡＣ−３ａｕｄｉｏ、Ｅ−ＡＣ−３ａｕｄｉｏ、ＭＰ３ａｕｄｉｏ、ＢｒｏｗｓｅｒＰｒｏｆｉｌｅＡ（Ａ／１０５）、ＡｔｏｍｐｅｒＲＦＣ４２８７、ＡＶＣｍｏｂｉｌｅｖｉｄｅｏ、ＨＥＡＡＣｖ２ｍｏｂｉｌｅａｕｄｉｏ、ＨＥＡＡＣｖ２ｌｅｖｅｌ４ａｕｄｉｏ、ＤＴＳ−ＨＤａｕｄｉｏ、ＣＦＦ−ＴＴ、ＣＥＡ−７０８ｃａｐｔｉｏｎｓ、ＨＥＡＡＣｖ２ｗｉｔｈＭＰＥＧＳｕｒｒｏｕｎｄ、ＨＥＡＡＣｖ２Ｌｅｖｅｌ６ａｕｄｉｏ、Ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ３Ｄｖｉｄｅｏ（Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ）、Ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ３Ｄｖｉｄｅｏ（Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ）、ＡＴＳＣ３．０ＨＥＶＣＶｉｄｅｏ１（ｅ．ｇ．ＨＤｖｉｄｅｏ）、ＡＴＳＣ３．０ＨＥＶＣＶｉｄｅｏ２（ｅ．ｇ．ＵＨＤｖｉｄｅｏ）、ＡＴＳＣ３．０ＳＨＶＣＶｉｄｅｏ１、ＡＴＳＣ３．０ＨＤＲＶｉｄｅｏ１、ＡＴＳＣ３．０ＷｉｄｅＣｏｌｏｒＧａｍｕｔＶｉｄｅｏ１、ＡＴＳＣ３．０ＣｏｄｅｄＡｕｄｉｏ１（ｅ．ｇ．，５．１．ｃｈａｎｎｅｌｓｕｒｒｏｕｎｄａｕｄｉｏ）、ＡＴＳＣ３．０ＣｏｄｅｄＡｕｄｉｏ２（ｅ．ｇ．Ｉｍｍｅｒｓｉｖｅ／３ＤＡｕｄｉｏ）、及び／又はＤｉａｌｏｇｌｅｖｅｌａｄｊｕｓｔｍｅｎｔのうち少なくとも一つを示すことができる。また、ＩｎｔｅｒｎｅｔＬｉｎｋと関連して、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、ｄｏｗｎｗａｒｄｒａｔｅ５６，０００ｂｐｓｏｒｂｅｔｔｅｒ、ｄｏｗｎｗａｒｄｒａｔｅ５１２，０００ｂｐｓｏｒｂｅｔｔｅｒ、ｄｏｗｎｗａｒｄｒａｔｅ２，０００，０００ｂｐｓｏｒｂｅｔｔｅｒ、及び／又はｄｏｗｎｗａｒｄｒａｔｅ１０，０００，０００ｂｐｓｏｒｂｅｔｔｅｒのうち少なくとも一つを示すことができる。

ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｓｏｕｒｃｅａｄｄｒｅｓｓを示すことができる。

ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓを示すことができる。

ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｐｏｒｔｎｕｍｂｅｒを示すことができる。

ＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送する伝送セッションを識別する識別子である。ただし、ＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅは、固定した「０」の値を有することができる。ＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅが、固定した「０」の値を有すると、ＦＩＣはＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅを含まなくてもよい。

ＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するデータパイプ（又は、フィジカルレイヤパイプ）の識別子を示すことができる。

ＦＩＣは、ＨＤサービスのための第１サービスエレメント及びＵＨＤサービスのための第２サービスエレメントを含むことができる。

第１サービスエレメントは、「ｓｉｄ−ｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、「０ｘ０１」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅ、「ｓｉｐ−ｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「ｉｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「ｕｄｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅ、「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又は「ｄｐ−１」の値を有するＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ここで、「ｓｉｄ−ｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅは、ＨＤサービスを示すことができる。「０ｘ０１」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、性能情報がＨＤサービスであることを示すことができる。「ｓｉｐ−ｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「ｉｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、及び「ｕｄｐ−ｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅの組合せは、第１ＲＯＵＴＥセッションを示すことができる。「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅ及び「ｄｐ−１」の値を有するＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅは、ＨＤサービスのためのＳＬＳ（例えば、ＬＳＩＤ及びＳＳＣ）が伝送される経路を示すことができる。

第２サービスエレメントは、「ｓｉｄ−ｕｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、「０ｘ０２」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅ、「ｓｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「ｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「ｕｄｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅ、「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又は「ｄｐ−３」の値を有するＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ここで、「ｓｉｄ−ｕｈｄ」の値を有するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅは、ＵＨＤサービスを示すことができる。「０ｘ０２」の値を有するｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、性能情報がＵＨＤサービスであることを示すことができる。「ｓｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「ｉｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、及び「ｕｄｐ−ｕｈｄ」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅの組合せは、第２ＲＯＵＴＥセッションを示すことができる。「ｔｓｉ−０」の値を有するＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅ及び「ｄｐ−３」の値を有するＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅは、ＵＨＤサービスのためのＳＬＳ（例えば、ＬＳＩＤ及びＳＳＣ）が伝送される経路を示すことができる。

以下、ＳＭＴについて説明する。

ＳＭＴは、サービスの属性（ＩＤ、名前、カテゴリーなど）情報及びサービスを取得し得る経路情報を含むことができる。例えば、サービスを取得し得る経路情報は、サービスのためのＲＯＵＴＥセッションのブートストラップ情報及び／又はＳＬＳの伝送経路情報のうち少なくとも一つを含むことができる。

ＳＭＴは、ＨＤサービスのための第１サービスマップ情報及びＵＤＨサービスのための第２サービスマップ情報を含むことができる。

それぞれの第１サービスマップ情報及び第２サービスマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、サービスのためのＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む少なくとも一つのＲＯＵＴＥセッションエレメントを含むことができる。ＲＯＵＴＥセッションエレメントは、ｓｒｃＩＰａｄｄｒａｔｔｒｉｂｕｔｅ、ｄｅｓｔＩＰａｄｄｒａｔｔｒｉｂｕｔｅ、ｄｅｓｔＵＤＰＰｏｒｔａｔｔｒｉｂｕｔｅ、及び／又はＬＳＩＤ＿ＤＰａｔｔｒｉｂｕｔｅを含むことができる。ｓｒｃＩＰａｄｄｒａｔｔｒｉｂｕｔｅ、ｄｅｓｔＩＰａｄｄｒａｔｔｒｉｂｕｔｅ、及び／又はｄｅｓｔＵＤＰＰｏｒｔａｔｔｒｉｂｕｔｅの組合せは、ＲＯＵＴＥセッションブートストラップ情報と呼ぶことができる。ＬＳＩＤ＿ＤＰａｔｔｒｉｂｕｔｅは、ＳＬＳの伝送経路情報と呼ぶことができる。

ｓｒｃＩＰａｄｄｒａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｓｏｕｒｃｅａｄｄｒｅｓｓを示すことができる。

ｄｅｓｔＩＰａｄｄｒａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓを示すことができる。

ｄｅｓｔＵＤＰＰｏｒｔａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するパケットのｐｏｒｔｎｕｍｂｅｒを示すことができる。

ＬＳＩＤ＿ＤＰａｔｔｒｉｂｕｔｅは、サービスのためのＳＬＳを伝送するデータパイプ（又は、フィジカルレイヤパイプ）の識別子を示すことができる。

第１サービスマップ情報は、ＨＤサービスを識別するｓｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔ、及びＨＤサービスのための第１ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第１ＲＯＵＴＥセッションエレメントのうち少なくとも一つを含むことができる。例えば、ＨＤサービスのためのｓｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔの値は「ｓｉｄ−ｈｄ」であってもよい。また、ＨＤサービスのための第１ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｈｄ」であり、ｄｅｓｔＩＰａｄｄｒａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｈｄ」であり、ｄｅｓｔＵＤＰＰｏｒｔａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｈｄ」であってもよい。また、ＨＤサービスのための第１ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰａｔｔｒｉｂｕｔｅの値は「ｄｐ−１」であってもよい。

第２サービスマップ情報は、ＵＨＤサービスを識別するｓｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔ、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第１ＲＯＵＴＥセッションエレメント、及びＵＨＤサービスのための第２ＲＯＵＴＥセッションのブートストラップ情報及びＳＬＳの伝送経路情報を含む第２ＲＯＵＴＥセッションエレメントのうち少なくとも一つを含むことができる。例えば、ＵＨＤサービスのためのｓｅｒｖｉｃｅ＿ｉｄｅｌｅｍｅｎｔの値は「ｓｉｄ−ｕｈｄ」であってもよい。また、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｈｄ」であり、ｄｅｓｔＩＰａｄｄｒａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｈｄ」であり、ｄｅｓｔＵＤＰＰｏｒｔａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｈｄ」であってもよい。また、ＵＨＤサービスのための第１ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰａｔｔｒｉｂｕｔｅの値は「ｄｐ−１」であってもよい。また、ＵＨＤサービスのための第２ＲＯＵＴＥセッションのｓｒｃＩＰａｄｄｒａｔｔｒｉｂｕｔｅの値は「ｓｉｐ−ｕｈｄ」であり、ｄｅｓｔＩＰａｄｄｒａｔｔｒｉｂｕｔｅの値は「ｉｐ−ｕｈｄ」であり、ｄｅｓｔＵＤＰＰｏｒｔａｔｔｒｉｂｕｔｅの値は「ｕｄｐ−ｕｈｄ」であってもよい。また、ＵＨＤサービスのための第２ＲＯＵＴＥセッションのＬＳＩＤ＿ＤＰａｔｔｒｉｂｕｔｅの値は「ｄｐ−３」であってもよい。

以下、ＭＤＰについて説明する。

ＭＰＤは、リニア／ストリーミングサービスの個別的なメディアコンポーネントのためのリソース識別子を含むことができる。また、ＭＰＤは、メディアプレゼンテーション内で識別されたリソースのコンテクスト（ｃｏｎｔｅｘｔ）を含むことができる。例えば、リソース識別子は、サービスのためのコンポーネントと関連するリプレゼンテーションを識別する情報であってもよい。

ＭＰＤは、メディアプレゼンテーションを構成する連続的な時間的区間に関する情報を含む少なくとも一つのピリオドエレメントを含むことができる。それぞれのピリオドエレメントは、ピリオドを識別するｐｅｒＩｄａｔｔｒｉｂｕｔｅ、及びコンポーネントに関する情報を含む少なくとも一つのＲｅｐｒｅｓｅｎｔａｔｉｏｎｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。それぞれのＲｅｐｒｅｓｅｎｔａｔｉｏｎｅｌｅｍｅｎｔは、サービスのためのコンポーネントに関連するリプレゼンテーションを識別するｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅを含むことができる。また、それぞれのＲｅｐｒｅｓｅｎｔａｔｉｏｎｅｌｅｍｅｎｔは、デコーディング及び／又はプレゼンテーションプロセスで当該リプレゼンテーションが依存している少なくとも一つのコンプリメンタリリプレゼンテーション（ｃｏｍｐｌｅｍｅｎｔａｒｙＲｅｐｒｅｓｅｎｔａｔｉｏｎ）を示すｄｅｐｅｎｄｅｎｃｙＩｄａｔｔｒｉｂｕｔｅを含むことができる。

例えば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｅｌｅｍｅｎｔは、オーディオコンポーネントに関する情報を含む第１リプレゼンテーションエレメント、ＨＤサービスのためのベースビデオコンポーネントに関する情報を含む第２リプレゼンテーションエレメント、及び／又はＵＨＤサービスのためのエンハンスメントビデオコンポーネントに関する情報を含む第３リプレゼンテーションエレメントを含むことができる。第３リプレゼンテーションエレメントは、ＵＨＤサービスのために第２リプレゼンテーションに依存している。第１リプレゼンテーションエレメント内のｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であり、第２リプレゼンテーションエレメント内のｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であり、第３リプレゼンテーションエレメント内のｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であってもよい。また、第３リプレゼンテーションエレメントはｄｅｐｅｎｄｅｎｃｙＩｄａｔｔｒｉｂｕｔｅを含むことができ、ｄｅｐｅｎｄｅｎｃｙＩｄａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」を示すことができる。

以下、ＣＭＴについて説明する。

ＣＭＴは、サービスのためのコンポーネントデータの伝送経路情報を含むことができる。例えば、伝送経路情報は、サービスのためのコンポーネントデータが伝送されるＤＰ（又は、ＰＬＰ）を識別する情報であってもよい。

ＣＭＴは、ＨＤサービスのための第１コンポーネントマップ情報及びＵＤＨサービスのための第２コンポーネントマップ情報を含むことができる。

それぞれの第１コンポーネントマップ情報及び第２コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤａｔｔｒｉｂｕｔｅ、及び／又はコンポーネントの伝送経路情報を含む少なくとも一つのＣｏｍｐｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、Ｃｏｍｐｅｌｅｍｅｎｔは、サービスのためのコンポーネントと関連するリプレゼンテーションを識別するｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅ、及び／又はサービスのためのコンポーネントが伝送されるＤＰを示すｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅは、コンポーネントの伝送経路情報と呼ぶことができる。

第１コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤａｔｔｒｉｂｕｔｅ、ＨＤサービスのためのオーディオコンポーネントの伝送経路情報を含む第１のＣｏｍｐｅｌｅｍｅｎｔ、及び／又はＨＤサービスのためのベースビデオコンポーネントの伝送経路情報を含む第２のＣｏｍｐｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、ｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅの値は「ｓｉｄ−ｈｄ」であり、ｐｅｒＩＤａｔｔｒｉｂｕｔｅの値は「ｐｅｒ−１」であってもよい。また、ＨＤサービスのための第１のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。また、ＨＤサービスのための第２のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。

第２コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤａｔｔｒｉｂｕｔｅ、ＵＨＤサービスのためのオーディオコンポーネントの伝送経路情報を含む第１のＣｏｍｐｅｌｅｍｅｎｔ、ＵＨＤサービスのためのベースビデオコンポーネントの伝送経路情報を含む第２のＣｏｍｐｅｌｅｍｅｎｔ、及び／又はＵＨＤサービスのためのエンハンスメントビデオコンポーネントの伝送経路情報を含む第３のＣｏｍｐｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、ｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅの値は「ｓｉｄ−ｕｈｄ」であり、ｐｅｒＩＤａｔｔｒｉｂｕｔｅの値は「ｐｅｒ−１」であってもよい。また、ＵＨＤサービスのための第１のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。また、ＵＨＤサービスのための第２のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ｄｐ−２」であってもよい。また、ＵＨＤサービスのための第３のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ｄｐ−４」であってもよい。

以下では、ＬＳＩＤについて説明する。

ＬＳＩＤは、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）と呼ぶことができる。Ｓ−ＴＳＩＤは、サービスの少なくとも一つのコンデンツコンポーネントを伝送する少なくとも一つの伝送セッションのための全体的なセッションディスクリプション情報を含むことができる。例えば、ＬＳＩＤは、サービスのためのコンポーネントが伝送される伝送セッションを識別する情報を含むことができる。

ＬＳＩＤは、ＨＤサービスのための第１ＬＳＩＤ及びＵＨＤサービスのための第２ＬＳＩＤを含むことができる。

第１ＬＳＩＤは、第１ＲＯＵＴＥセッションに含まれてもよい。第１ＬＳＩＤは、コンポーネントを伝送する少なくとも一つのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔを含むことができる。それぞれのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔは、伝送セッションに含まれるソースフローに関する情報を提供するＳｏｕｒｃｅＦｌｏｗｅｌｅｍｅｎｔを含むことができる。ＳｏｕｒｃｅＦｌｏｗｅｌｅｍｅｎｔは、伝送セッションを介して伝送されるサービス（又は、アプリケーションサービス）にマッピングされる付加的な情報を含むＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒｅｌｅｍｅｎｔを含むことができる。例えば、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒｅｌｅｍｅｎｔは、ＤＡＳＨコンデンツのリプレゼンテーション識別子（ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ）及び／又はＤＡＳＨメディアリプレゼンテーションのアダプテーションセットパラメータ（ＡｄａｐｔａｔｉｏｎＳｅｔｐａｒａｍｅｔｅｒｓ）を含むことができる。リプレゼンテーション識別子は、サービスのためのコンポーネントと関連する識別子であり、ｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅと呼ぶことができる。また、ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒｅｌｅｍｅｎｔは、ＣｏｎｔｅｎｔＩｎｆｏｅｌｅｍｅｎｔと呼ぶことができる。

第１ＬＳＩＤは、オーディオコンポーネントを伝送する第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ及び／又はベースビデオコンポーネントを伝送する第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ内のｔｓｉａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ａ」であり、ｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ａ」であってもよい。また、第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ内のｔｓｉａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ｖ−ｂ」であり、ｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｂ」であってもよい。

第２のＬＳＩＤは、エンハンスメントビデオコンポーネントを伝送する第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔを含むことができる。例えば、第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ内のｔｓｉの値は「ｔｓｉ−ｖ−ｅ」であり、ｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ｃｏｍ−ｖ−ｅ」であってもよい。

図面では、各ＲＯＵＴＥセッションはそれぞれ一つのＬＳＩＤ（伝送セッション情報）を含み、２つのＬＳＩＤが存在する。ただし、これに限定されない。例えば、各サービスはそれぞれ一つのＬＳＩＤ（伝送セッション情報）を含むことができる。この場合、一つのＬＳＩＤは、特定サービスのための少なくとも一つのＲＯＵＴＥセッションに含まれる少なくとも一つのコンポーネントを伝送する少なくとも一つの伝送セッションに関する情報を含むことができる。例えば、一つのＬＳＩＤは、ＵＨＤサービスのために第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ、第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ、及び／又は第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔを全て含むことができる。

同図を参照すると、本発明の一実施例に係る一つの周波数は、同一のコンテンツを含む高鮮明ビデオ（Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎｖｉｄｅｏ、ＨＤ）サービス及び超高鮮明ビデオ（ＵｌｔｒａＨｉｇｈＤｅｆｉｎｉｔｉｏｎｖｉｄｅｏ、ＵＨＤ）サービスを含むことができる。

例えば、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅの値が「０ｘ００」であれば、デバイス性能はデジタル標準ビデオ（Ｓｔａｎｄａｒｄ−Ｄｅｆｉｎｉｔｉｏｎ、ＳＤ）サービスを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅの値が「０ｘ０１」であれば、デバイス性能はＨＤサービスを示すことができる。ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅの値が「０ｘ０２」であれば、デバイス性能はＵＨＤサービスを示すことができる。

モバイルデバイスのようにＵＨＤサービスを再生できない装置は、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅに基づいて、チャネルマップの構成時に、ＵＨＤサービスに該当するチャネルを除いてチャネルマップを構成することができる。

また、ＴＶのようなフィクスドデバイス（ｆｉｘｅｄｄｅｖｉｃｅ）では、ＨＤサービス及びＵＨＤサービスを全て再生できるので、フィクスドデバイスは、ＨＤサービス及びＵＨＤサービスに該当するチャネルを全て含んでチャネルマップを構成することができる。

図１４０は、本発明の一実施例に係るチャネルマップ構成方法を示す図である。

本発明の一実施例は、次世代放送網で同一のコンデンツが複数のサービス形態で提供される時、これを識別するための方法を提供することができる。同一コンデンツがサービスされることを識別するために、本発明の一実施例に係るＦＩＣは、ＦＩＣｌｏｏｐにｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅを含むことができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅは、サービスのチャネル番号を示すことができる。放送受信装置はＦＩＣを受信し、ＦＩＣのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅに基づいて、同一コンデンツを伝送するチャネル（又は、サービス）を除いてチャネルマップを構成することができる。

特定の周波数を有する放送信号は、シグナリング情報を含むことができる。例えば、シグナリング情報は、ＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣは、ＳＬＴと呼ぶことができる。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。本発明の一実施例に係る放送信号の構造、ＦＩＣ、及び／又はＳＬＳは、前述した内容と同一であるか、又は前述した内容を全て含むことができる。

本発明の一実施例に係るＦＩＣは、サービスエレメント内に、サービスのチャネル番号を示すｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅを含むことができる。ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅは、サービスのメジャーチャネル番号を示すｍａｊｏｒＣｈａｎｎｅｌＮｏａｔｔｒｉｂｕｔｅ、及び／又はサービスのマイナーチャネル番号を示すｍｉｎｏｒＣｈａｎｎｅｌＮｏａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。

ＦＩＣは、ＨＤサービスのための第１サービスエレメント及びＵＨＤサービスのための第２サービスエレメントを含むことができる。例えば、ＨＤサービス及びＵＨＤサービスは同一コンデンツを提供することができる。第１サービスエレメントは、「ｃｎｕｍ−ｘ」の値を有するｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅを含むことができる。第２サービスエレメントは、「ｃｎｕｍ−ｘ」の値を有するｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅを含むことができる。第１サービスエレメントのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅと第２サービスエレメントのｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅはいずれも「ｃｎｕｍ−ｘ」の値を有することができる。

例えば、同一のコンデンツがＨＤサービス及び／又はＵＨＤサービスと共にそれぞれのサービス形態で伝送される時、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅは同一の値を有することができる。

ＵＨＤ再生が可能な装置では、同一のコンデンツを伝送するＨＤチャネル（サービス）情報及び／又はＵＨＤチャネル（サービス）情報を重複的に構成せず、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅに基づいてＵＨＤチャネルだけを選択し、チャネルマップを構成することができる。

図１４１は、本発明の一実施例に係るＦＩＣを示す図である。

本発明の一実施例に係るＦＩＣに関連した内容は、前述したＦＩＣに関連した内容を全て含むことができる。また、本発明の一実施例では、ＦＩＣに含まれる情報をｆｉｅｌｄと表現したが、ＦＩＣはＸＭＬフォーマットであってもよい。また、ＦＩＣに含まれる情報をｆｉｅｌｄに代えてａｔｔｒｉｂｕｔｅと表現してもよい。

本発明の一実施例に係るＦＩＣは、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇｆｉｅｌｄ、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄ、ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄ、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄのうち少なくとも一つを含むことができる。

ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇｆｉｅｌｄは、ＳｅｒｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ（ＳＣＤ）が伝送されるか（又は、存在するか）否かを示すことができる。ＳＣＤは、ＦＩＣに含まれていない、より多様で多量の追加的なシグナリング情報を含むことができる。例えば、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇｆｉｅｌｄの値が「Ｔｒｕｅ」であれば、シグナリング情報は、ＳＣＤを含むことができる。

ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄは、ＳＣＤが伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す。

ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄは、当該サービスのＳＳＣブートストラップ情報が伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す。

ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄは、基本的な段階のシグナリング情報がＳＳＣで伝送されるか否かを示すことができる。例えば、サービスシグナリングで用いられるディスクリプションの種類又はテーブルの種類が異なる場合、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄは、基本的な段階のシグナリング情報がＳＳＣで伝送されるか否かを示すことができる。また、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄは、オーディオコンポーネント及び／又はビデオコンポーネントと関連した基本的な段階のシグナリング情報が別途のシグナリングチャネル及び／又はシグナリングテーブルを介して伝達されるか否かを示すことができる。

ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇｆｉｅｌｄ及び／又はＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄは、フィジカルレイヤシグナリング情報に含まれてもよい。この場合、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇｆｉｅｌｄは、現在フレームにＳＣＤが存在するか否かを示すことができる。また、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄは、ＳＣＤが伝送されるデータパイプ（又は、ＰＬＰ）及び／又はフレームを示すことができる。

放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述したＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇｆｉｅｌｄ、ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄ、ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄ、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄのうち少なくとも一つを含むことができる。

放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいてサービスを取得することができる。

図１４２は、本発明の一実施例に係るＦＩＣを示す図である。

本発明の一実施例に係るＦＩＣは、Ｐｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄを含むことができる。

Ｐｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄは、当該サービスを送信する提供者（又は、Ｐｒｏｖｉｄｅｒ）の固有な識別子を示す。例えば、Ｐｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄは、当該サービスがどの提供者から伝送されるかを示すことができる。

放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述したＰｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄを含むことができる。

放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいてサービスを取得し、当該サービスの提供者を識別することができる。

図１４３は、本発明の一実施例に係るＦＩＣを示す図である。

本発明の一実施例に係るＦＩＣは、Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄｆｉｅｌｄを含むことができる。

Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄｆｉｅｌｄは、当該サービスを送信する提供者（Ｐｒｏｖｉｄｅｒ）の属したグループの識別子を示すことができる。

放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述したＰｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄｆｉｅｌｄを含むことができる。

放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいてサービスを取得し、当該サービスの提供者のグループを識別することができる。

例えば、放送受信装置は、Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄｆｉｅｌｄに基づいて、提供者グループ別に受信されるサービスを区別することができる。すなわち、放送受信装置は、Ｐｒｏｖｉｄｅｒ＿Ｇｒｏｕｐ＿ｉｄｆｉｅｌｄとＳｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙｆｉｅｌｄがＥＳＧであるサービスとをマッピングし、ＥＳＧが、どの提供者が提供しているサービスに対するＧｕｉｄｅを含んでいるかを判断することができる。

図１４４は、本発明の一実施例に係るＦＩＣを示す図である。

本発明の一実施例に係るＦＩＣは、Ｎｕｍ＿ｐｒｏｖｉｄｅｒｓｆｉｅｌｄ及び／又は少なくとも一つの提供者ループを含むことができる。

Ｎｕｍ＿ｐｒｏｖｉｄｅｒｓｆｉｅｌｄは、当該周波数を用いる提供者（Ｐｒｏｖｉｄｅｒ又はＢｒｏａｄｃａｓｔｅｒ）の数を示すことができる。

それぞれの提供者ループは、Ｐｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄ、少なくとも一つのサービスループ、Ｎｕｍ＿ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｆｉｅｌｄ、及び／又は少なくとも一つのＰｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｆｉｅｌｄを含むことができる。

Ｐｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄは、当該サービスを送信する提供者（又は、Ｐｒｏｖｉｄｅｒ）の固有な識別子を示す。例えば、Ｐｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄは、それぞれの提供者（ｐｒｏｖｉｄｅｒ又はｂｒｏａｄｃａｓｔｅｒ）に割り当てられる固有の識別子である。

サービスループは、サービスと関連した属性を含むことができる。具体的な内容は、前述したとおりである。

Ｎｕｍ＿ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｆｉｅｌｄは、提供者（ｐｒｏｖｉｄｅｒ）別に伝送され得るディスクリプタの数を示すことができる。

Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｆｉｅｌｄは、提供者（ｐｒｏｖｉｄｅｒ）別に伝送されるディスクリプタを示すことができる。

放送伝送装置は、制御部を用いて、シグナリング情報を生成することができる。例えば、シグナリング情報は、前述した少なくとも一つのＰｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄを含むことができる。

放送受信装置は、制御部を用いて、シグナリング情報に含まれたＦＩＣ及び／又はＳＣＤを取得することができる。その後、放送受信装置は、ＦＩＣ及び／又はＳＣＤに基づいて少なくとも一つのサービスを取得し、当該サービスの提供者を識別することができる。

図１４５は、本発明の一実施例に係るＦＩＣを示す図である。

本発明の一実施例に係るＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎｆｉｅｌｄ、ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄｆｉｅｌｄ、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇｆｉｅｌｄ、ＳＣＤ＿ＤＰ＿ＩＤｆｉｅｌｄ、Ｎｕｍ＿ｐｒｏｖｉｄｅｒｓｆｉｅｌｄ、ｐｒｏｖｉｄｅｒ＿ｉｄｆｉｅｌｄ、ｎｕｍ＿ｓｅｒｖｉｃｅｓｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｉｄｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙｆｉｅｌｄ、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈｆｉｅｌｄ、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓｆｉｅｌｄ、ｓｅｒｖｉｃｅ＿ｄｉｓｔｒｉｂｕｔｉｏｎｆｉｅｌｄ、ｓｐ＿ｉｎｄｉｃａｔｏｒｆｉｅｌｄ、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇｆｉｅｌｄ、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇｆｉｅｌｄ、ＳＳＣ＿ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓｆｉｅｌｄ、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓｆｉｅｌｄ、ＳＳＣ＿ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔｆｉｅｌｄ、ＳＳＣ＿ＴＳＩｆｉｅｌｄ、ＳＳＣ＿ＤＰ＿ＩＩＤｆｉｅｌｄ、ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄ、ｎｕｍ＿Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓｆｉｅｌｄ、Ｐｒｏｖｉｄｅｒ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）ｆｉｅｌｄ、ｎｕｍ＿ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒｓｆｉｅｌｄ、及び／又はＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）ｆｉｅｌｄのうち少なくとも一つを含むことができる。本発明の一実施例に係るＦＩＣに含まれる情報は、前述したＦＩＣに含まれる情報の内容を全て含むことができる。

本発明の一実施例に係るＦＩＣは、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示す性能情報（又は、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄ）をさらに含むことができる。

例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄは、当該サービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを示すことができる。例えば、ＵＤ／ＨＤｓｃａｌａｂｌｅｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄは、ＨＤを示す値を有することができる。

放送受信装置はＦＩＣを受信し、ＦＩＣの性能情報（又は、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄ）に基づいて、デバイス性能（ｄｅｖｉｃｅｃａｐａｂｉｌｉｔｙ）に符合する差別化されたチャネルマップを構成（又は、生成）することができる。また、放送受信装置は、ＦＩＣの性能情報（又は、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄ）に基づいてサービスのための少なくとも一つのコンポーネントを取得することができる。その後、放送受信装置は、サービスのための少なくとも一つのコンポーネントをデコーティングすることができる。

図１４６は、本発明の一実施例に係るＦＩＣを示す図である。

特定の周波数を有する放送信号はシグナリング情報を含むことができる。例えば、放送信号は「ＢＣＳｔｒｅａｍＩＤ１」で識別されてもよい。シグナリング情報は、ＦＩＣ及び／又はＳＬＳを含むことができる。ＦＩＣは、ＳＬＴと呼ぶことができる。ＦＩＣはＩＰ／ＵＤＰパケットに含まれて伝送されてもよい。

放送信号は、第１ＲＯＵＴＥセッションを含むことができる。第１ＲＯＵＴＥセッションは、少なくとも一つのサービスを含むことができる。例えば、サービスの識別子は、「ＳｒｖｃＩＤ１」の値を有することができる。サービスは、ＨＤサービス及び／又はＵＨＤサービスのための少なくとも一つのコンポーネントを含むことができる。ＨＤサービスのためのコンポーネントは、第１ＲＯＵＴＥセッションの特定伝送セッションを介して伝送されてもよい。ＵＨＤサービスのための付加情報は、第１ＲＯＵＴＥセッションの他の伝送セッションを介して伝送されてもよい。

サービスに対してサービスレイヤシグナリング情報が存在してもよい。例えば、ＨＤサービス及び／又はＵＨＤサービスに対して、第１ＲＯＵＴＥセッションにＨＤサービス及び／又はＵＨＤサービスのためのサービスレイヤシグナリング情報が存在してもよい。ここで、サービスレイヤシグナリング情報は、ＬＳＩＤ及びＳＳＣ（ＳＭＴ、ＭＤＰ、及び／又はＣＭＴ）のうち少なくとも一つを含むことができる。

第１ＲＯＵＴＥセッションは、ｓｏｕｒｃｅＩＰＡｄｄｒｅｓｓ（ｓＩＰＡｄｒｓ１）、ｄｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ（ＩＰＡｄｒｓ１）、及びｄｅｓｔｉｎａｔｉｏｎｐｏｒｔｎｕｍｂｅｒ（Ｐｏｒｔ１）の組合せで識別されてもよい。また、第１ＲＯＵＴＥセッションは、第１ＤＰ（ＤＰ＿ＩＤ１）、第２ＤＰ（ＤＰ＿ＩＤ２）、及び／又は第３ＤＰ（ＤＰ＿ＩＤ３）を介して伝送されてもよい。また、第１ＲＯＵＴＥセッションは、第１伝送セッション（ｔｓｉ−０）、第２伝送セッション（ｔｓｉ−ｓ）、第３伝送セッション（ｔｓｉ−ａ）、第４伝送セッション（ｔｓｉ−ｖ）、及び／又は第５伝送セッション（ｔｓｉ−ｅｖ）を含むことができる。第１伝送セッション（ｔｓｉ−０）は、ＬＳＩＤ及び／又は少なくとも一つのＬＳＩＤフラグメントを含むことができる。第２伝送セッション（ｔｓｉ−ｓ）は、シグナリングテーブル及び／又は少なくとも一つのＳＳＣフラグメントを含むことができる。例えば、シグナリングテーブルはＳＳＣを示すことができる。また、ＳＳＣは、ＳＭＴ、ＭＰＤ、及び／又はＣＭＴのうち少なくとも一つを含むことができる。第３伝送セッション（ｔｓｉ−ａ）は、オーディオコンポーネントを含むことができる。例えば、オーディオコンポーネントは少なくとも一つのオーディオセグメントを含むことができる。第４伝送セッション（ｔｓｉ−ｖ）は、ベースビデオコンポーネントを含むことができる。例えば、ベースビデオコンポーネントは少なくとも一つのベースビデオセグメントを含むことができる。例えば、ベースビデオコンポーネントは、ＨＤサービスを提供するためのビデオコンポーネントである。第５伝送セッション（ｔｓｉ−ｅｖ）は、エンハンスメントビデオコンポーネントを含むことができる。例えば、エンハンスメントビデオコンポーネントは少なくとも一つのエンハンスメントビデオセグメントを含むことができる。例えば、エンハンスメントビデオコンポーネントは、ＵＨＤサービスを提供するためのビデオコンポーネント及び／又は付加情報である。

以下ではＦＩＣについて説明する。

ＦＩＣは、ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ（ＳＬＴ）と呼ぶことができる。本発明の一実施例に係るＦＩＣに関連した内容は、前述したＦＩＣに関連した内容を全て含むことができる。

ＦＩＣは、「ＢＣＳｔｒｅａｍＩＤ１」の値を有する識別子ｅｌｅｍｅｎｔ及び／又は第１サービスエレメントを含むことができる。

第１サービスエレメントは、「ＳｒｖｃＩＤ１」の値を有するｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ、「ＨＤ」の値を有するｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔを含むことができる。ＳＳＣ＿Ｂｏｏｔｓｔｒａｐｅｌｅｍｅｎｔは、「ｓＩＰＡｄｒｓ１」の値を有するＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「ＩＰＡｄｒｓ１」の値を有するＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、「Ｐｏｒｔ１」の値を有するＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅ、「ｔｓｉ−ｓ」の値を有するＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又は「ＤＰ＿ｉｄ１」の値を有するＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。ここで、「ＨＤ」の値を有するｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは、サービスが支援する最小限の性能（Ｃａｐａｂｉｌｉｔｙ）コードが「ＨＤ」であることを示すことができる。すなわち、サービスが「ＨＤ」及び「ＵＨＤ」の両方を支援できる場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅａｔｔｒｉｂｕｔｅは「ＨＤ」の値を有することができる。

図１４７は、本発明の一実施例に係るＳＳＣを示す図である。

以下では、ＳＭＴについて説明する。

同図の（ａ）を参照すると、ＳＭＴは、サービスの属性（ＩＤ、名前、カテゴリーなど）情報及びサービスを取得し得る経路情報を含むことができる。本発明の一実施例に係るＳＭＴに関連した内容は、前述したＳＭＴに関連した内容を全て含むことができる。

ＳＭＴは、サービスを識別するｓｅｒｖｉｃｅＩＤａｔｔｒｉｂｕｔｅ、サービスの名前を識別するＳｅｒｖｉｃｅＮａｍｅａｔｔｒｉｂｕｔｅ、サービスを支援するデバイスの性能を示すＣａｐａｂｉｌｉｔｙａｔｔｒｉｂｕｔｅ、及び／又はサービスのためのＲＯＵＴＥセッションのブートストラップ情報を含むＲＯＵＴＥｓｅｓｓｉｏｎｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。

例えば、Ｃａｐａｂｉｌｉｔｙａｔｔｒｉｂｕｔｅは、「ＨＤ」及び「ＵＨＤ」の値を有することができる。すなわち、Ｃａｐａｂｉｌｉｔｙａｔｔｒｉｂｕｔｅは、ＨＤ及びＵＨＤの両方を支援することを示すことができる。

以下では、ＭＰＤについて説明する。

ＭＰＤは、リニア／ストリーミングサービスの個別的なメディアコンポーネントのためのリソース識別子を含むことができる。本発明の一実施例に係るＭＰＤに関連した内容は、前述したＭＰＤに関連した内容を全て含むことができる。

ＭＰＤは、ピリオドエレメント（Ｐｅｒｉｏｄｅｌｅｍｅｎｔ）を含むことができる。Ｐｅｒｉｏｄｅｌｅｍｅｎｔは、少なくとも一つのオーディオコンポーネントに関する情報を含む第１のＡｄａｐｔａｔｉｏｎＳｅｔｅｌｅｍｅｎｔ、及び少なくとも一つのビデオコンポーネントに関する情報を含む第２のＡｄａｐｔａｔｉｏｎＳｅｔｅｌｅｍｅｎｔを含むことができる。第１のＡｄａｐｔａｔｉｏｎＳｅｔｅｌｅｍｅｎｔは、オーディオコンポーネントに関する情報を含む第１リプレゼンテーションエレメントを含むことができる。第２のＡｄａｐｔａｔｉｏｎＳｅｔｅｌｅｍｅｎｔは、ベースビデオコンポーネントに関する情報を含む第２リプレゼンテーションエレメント、及びエンハンスメントビデオコンポーネントに関する情報を含む第３リプレゼンテーションエレメントを含むことができる。

第１リプレゼンテーションエレメント内のｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ａ」であり、第２リプレゼンテーションエレメント内のｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｖ」であり、第３リプレゼンテーションエレメント内のｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｅｖ」であってもよい。また、第３リプレゼンテーションエレメントは、ｄｅｐｅｎｄｅｎｃｙＩｄａｔｔｒｉｂｕｔｅを含むことができ、ｄｅｐｅｎｄｅｎｃｙＩｄａｔｔｒｉｂｕｔｅの値は、「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｉｄ−ｖ」を示すことができる。

以下では、ＣＭＴについて説明する。

ＣＭＴは、サービスのためのコンポーネントデータの伝送経路情報を含むことができる。本発明の一実施例に係るＣＭＴに関連した内容は、前述したＣＭＴに関連した内容を全て含むことができる。

ＣＭＴは、第１サービスのための第１コンポーネントマップ情報を含むことができる。第１コンポーネントマップ情報は、サービスを識別するｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、ピリオドを識別するｐｅｒＩＤａｔｔｒｉｂｕｔｅ、第１サービスのためのオーディオコンポーネントの伝送経路情報を含む第１Ｃｏｍｐｅｌｅｍｅｎｔ（又は、ＢＣＣｏｍｐｏｎｅｎｔｅｌｅｍｅｎｔ）、第１サービスのためのベースビデオコンポーネントの伝送経路情報を含む第２Ｃｏｍｐｅｌｅｍｅｎｔ（又は、ＢＣＣｏｍｐｏｎｅｎｔ（ＨＤ）ｅｌｅｍｅｎｔ）、及び／又は第１サービスのためのエンハンスメントビデオコンポーネントの伝送経路情報を含む第３のＣｏｍｐｅｌｅｍｅｎｔ（又は、ＢＣＣｏｍｐｏｎｅｎｔ（ＵＤ）ｅｌｅｍｅｎｔ）のうち少なくとも一つを含むことができる。

例えば、第１サービスのための第１のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ａ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ１」であってもよい。また、第１サービスのための第２のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｖ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ２」であってもよい。また、第１サービスのための第３のＣｏｍｐｅｌｅｍｅｎｔ内のｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｅｖ」であり、ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅの値は「ＤＰ＿ＩＤ３」であってもよい。

以下では、ＬＳＩＤについて説明する。

ＬＳＩＤは、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｉｏｎ）と呼ぶことができる。本発明の一実施例に係るＬＳＩＤに関連した内容は、前述したＬＳＩＤに関連した内容を全て含むことができる。

ＬＳＩＤは、第１ＲＯＵＴＥセッションに含まれてもよい。ＬＳＩＤは、オーディオコンポーネントを伝送する第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ、ベースビデオコンポーネントを伝送する第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ、及び／又はエンハンスメントビデオコンポーネントを伝送する第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔのうち少なくとも一つを含むことができる。例えば、第１のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ内のｔｓｉａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ａ」であり、ｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ａ」であってもよい。また、第２のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ内のｔｓｉａｔｔｒｉｂｕｔｅの値は「ｔｓｉ−ｖ」であり、ｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｖ」であってもよい。また、第３のＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎｅｌｅｍｅｎｔ内のｔｓｉａｔｔｒｉｂｕｔｅの値の「ｔｓｉ−ｅｖ」であり、ｒｅｐｔｎＩＤａｔｔｒｉｂｕｔｅの値は「ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ−ｅｖ」であってもよい。

図１４８は、本発明の一実施例に係る放送伝送方法の流れを示す図である。

本発明の一実施例に係る放送伝送装置は、制御部及び／又は伝送部を含むことができる。制御部は、前述したサービスデータ及び／又は、前述したシグナリング情報を生成することができる。また、伝送部は、サービスデータ及び／又はシグナリング情報を含む放送信号を伝送することができる。

放送伝送装置は、制御部を用いて、同一のコンデンツを提供する少なくとも一つのサービスのためのサービスデータを生成及び／又はエンコーディングできる（ＣＳ１４８０１００）。

例えば、サービスデータは、オーディオコンポーネント、ベースビデオコンポーネント、及び／又はエンハンスメントビデオコンポーネントを含むことができる。

また、放送伝送装置は、制御部を用いて、サービスのためのシグナリング情報を生成及び／又はエンコーディングすることができる（ＣＳ１４８０２００）。

例えば、シグナリング情報は、サービスの取得のための第１シグナリング情報（又は、ＳＬＳ）及び／又はサービスのためのブートストラップ情報を含む第２シグナリング情報（又は、ＦＩＣ）を含むことができる。第１シグナリング情報（又は、ＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。第２シグナリング情報（又は、ＦＩＣ）は、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示す性能情報（例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅ）をさらに含むことができる。例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄは、当該サービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを示すことができる。例えば、ＵＤ／ＨＤｓｃａｌａｂｌｅｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄは、ＨＤを示す値を有することができる。また、ＦＩＣは、同一のコンデンツを提供する少なくとも一つのサービスのチャネル番号を示すチャネル情報（又は、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅ）を含むことができる。また、シグナリング情報は、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するか否かを示すフラグ情報（ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄ）、及び／又は第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す識別子情報（ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄ）をさらに含むことができる。

また、放送伝送装置は、制御部を用いて、サービスデータ及びシグナリング情報を含む放送信号を生成することができる。

また、放送伝送装置は、伝送部を用いて、サービスデータ及びシグナリング情報を含む放送信号を伝送することができる（ＣＳ１４８０３００）。

図１４９は、本発明の一実施例に係る放送受信方法の流れを示す図である。

例えば、ブロードキャストインターフェースは放送網で放送信号を受信することができる。ブロードキャストインターフェースは、フィジカルレイヤモジュール、フィジカルレイヤＩＰフレームモジュールを含むことができる。又は、ブロードキャストインターフェースは、チューナー及びフィジカルフレームパーサーのうち少なくとも一つを含むことができる。

例えば、ブロードバンドインターフェースは、インターネット網を介してデータを伝送及び／又は受信することができる。ブロードバンドインターフェースはインターネット接近制御モジュールを含むことができる。

放送受信装置は、ブロードキャストインターフェース及び／又はブロードバンドインターフェースを用いて、同一のコンデンツを提供する少なくとも一つのサービスのためのサービスデータ及びシグナリング情報を含む放送信号を受信することができる（ＣＳ１４９０１００）。

サービスデータは、オーディオコンポーネント、ベースビデオコンポーネント、及び／又はエンハンスメントビデオコンポーネントを含むことができる。シグナリング情報は、サービスの取得のための第１シグナリング情報（又は、ＳＬＳ）、及び／又はサービスのためのブートストラップ情報を含む第２シグナリング情報（又は、ＦＩＣ）を含むことができる。第１シグナリング情報（又は、ＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。第２シグナリング情報（又は、ＦＩＣ）は、サービスのためのコンデンツのデコーディング及び／又は有意義な再生のために要求されるデバイスの性能及び／又は性能グループを示す性能情報（例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅ）をさらに含むことができる。例えば、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄは、当該サービスが支援する最小限の性能（ｃａｐａｂｉｌｉｔｙ）コードを示すことができる。例えば、ＵＤ／ＨＤｓｃａｌａｂｌｅｃｏｄｉｎｇが可能なサービスの場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｆｉｅｌｄは、ＨＤを示す値を有することができる。また、ＦＩＣは、同一のコンデンツを提供する少なくとも一つのサービスのチャネル番号を示すチャネル情報（又は、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒａｔｔｒｉｂｕｔｅ）を含むことができる。また、シグナリング情報は、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するか否かを示すフラグ情報（ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ＿ｆｌａｇｆｉｅｌｄ）、及び／又は第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が伝送されるデータパイプ（又は、ＰＬＰ）の識別子を示す識別子情報（ＳＣＤ＿Ｂｂｐｓｔｒｅａｍ＿ｉｄｆｉｅｌｄ）をさらに含むことができる。

例えば、ユーザが第１サービス（ＳｒｖｃＩＤ１）を選択した場合、放送受信装置はＦＩＣに基づいて、ｍｉｎｉｍｕｍｃａｐａｂｉｌｉｔｙｃｏｄｅｆｉｅｌｄを取得することができる。また、放送受信装置はＦＩＣに基づいて、少なくとも一つのサービスに対するｍｉｎｉｍｕｍＣａｐａｂｉｌｉｔｙｃｏｄｅｆｉｅｌｄを取得することができる。本発明の一実施例に係る第１サービスは、ＵＤ／ＨＤの両方を支援できるサービスであってもよく、この場合、ｍｉｎｉｍｕｍＣａｐａｂｉｌｉｔｙｃｏｄｅは、ＨＤを示すことができる。

また、放送受信装置は、制御部を用いて、放送信号から第２シグナリング情報（又は、ＦＩＣ）を取得することができる。例えば、第２シグナリング情報（ＦＩＣ及び／又はＳＣＤ）が存在するか否かを示すフラグ情報が「Ｔｒｕｅ」を示すと、放送受信装置はフラグ情報に基づいて、放送信号から第２シグナリング情報を取得することができる。

また、放送受信装置は、制御部を用いて、第２シグナリング情報（又は、ＦＩＣ）からサービス属性及び／又は第１シグナリング情報（又は、サービスレイヤシグナリング情報、ＳＬＳ）のブートストラップ情報を取得することができる。例えば、第２シグナリング情報（又は、ＦＩＣ）は、ｓｅｒｖｉｃｅ＿ｉｄａｔｔｒｉｂｕｔｅ、ｄｅｖｉｃｅ＿ｃａｐａ＿ｃｏｄｅａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔａｔｔｒｉｂｕｔｅ、ＳＳＣ＿ｔｓｉａｔｔｒｉｂｕｔｅ、及び／又はＳＳＣ＿ＤＰ＿ｉｄａｔｔｒｉｂｕｔｅのうち少なくとも一つを含むことができる。

また、放送受信装置は、制御部を用いて、シグナリング情報に基づいてサービスをフィルタリングすることができる（ＣＳ１４９０２００）。

例えば、第２シグナリング情報（又は、ＦＩＣ）は、サービスのデコーディングのために要求される性能情報を含み、放送受信装置は、性能情報に基づいて、デコーディング及び／又はプレゼンテーションし得るサービスをフィルタリングすることができる。また、フィルタリングされたサービスは複数であり、取得された第１シグナリング情報は、全てのフィルタリングされたサービスの取得のための情報であってもよい。

また、放送受信装置は、制御部を用いて、フィルタリングされたサービスのためのサービス属性及び／又はサービスレイヤシグナリング情報（ＳＬＳ）のブートストラップ情報をチャネルマップに一時的に保存することができる。

また、放送受信装置は、制御部を用いて、第２シグナリング情報（又は、ＦＩＣ）に基づいて、フィルタリングされたサービスのための第１シグナリング情報（又は、ＳＬＳ）を取得することができる（ＣＳ１４９０３００）。

例えば、放送受信装置は、第２シグナリング情報（又は、ＦＩＣ）から、フィルタリングされたサービスのための第１シグナリング情報（又は、ＳＬＳ）ブートストラップ情報を取得し、第１シグナリング情報（又は、ＳＬＳ）ブートストラップ情報に基づいて第１シグナリング情報（又は、ＳＬＳ）を取得することができる。例えば、第１シグナリング情報（又は、ＳＬＳ）は、ＳＭＴ、ＭＰＤ、ＣＭＴ、及び／又はＬＳＩＤのうち少なくとも一つを含むことができる。放送受信装置は、第１シグナリング情報（又は、ＳＬＳ）に基づいて、いずれのリプレゼンテーションが放送網を介して伝送されるかを決定することができる。

また、放送受信装置は、制御部を用いて、フィルタリングされたサービスのための取得された第１シグナリング情報（又は、ＳＬＳ）に含まれた情報をチャネルマップに２次的に保存することができる（ＣＳ１４９０４００）。

例えば、第１シグナリング情報（又は、ＳＬＳ）に含まれた情報は、サービスの属性（ＩＤ、名前、カテゴリーなど）、サービスを取得し得る経路情報、及び／又はサービスと関連した情報を含むことができる。サービスを取得し得る経路情報は、サービスのためのコンポーネントと関連するリプレゼンテーションを識別する情報（ｒｅｐｔｎＩｄａｔｔｒｉｂｕｔｅ）、サービスのためのコンポーネントデータが伝送されるＤＰ（又は、ＰＬＰ）を識別する情報（ｄａｔａｐｉｐｅＩＤａｔｔｒｉｂｕｔｅ）、及び／又はサービスのためのコンポーネントが伝送される伝送セッションを識別する情報（ｔｓｉａｔｔｒｉｂｕｔｅ）のうち少なくとも一つを含むことができる。

また、フィルタリングされたサービスが複数であれば、放送受信装置は、制御部を用いて、チャネル情報に基づいて複数のサービスの中から一つのサービスを選択することができる。

また、放送受信装置は、制御部を用いて、チャネルマップに基づいてサービスデータを取得することができる。

また、放送受信装置は、制御部を用いて、サービスデータをデコーディングすることができる。

本発明の一実施例に係る放送受信装置がベースレイヤのベースビデオコンポーネントを受信及び／又は取得すると、放送受信装置は、ＨＤと関連したコンポーネントをデコーティングして出力することができる。

また、放送受信装置がＵＨＤと関連したコンポーネントをデコーディング及び／又は出力するためには、ベースレイヤのベースビデオコンポーネント及びエンハンスメントレイヤのエンハンスメントビデオコンポーネントの両方をデコーディングしなければならない。

仮に放送受信装置がＳＤまでしか支援できないと、放送受信装置は第１サービスを再生することができないはずである。

仮に放送受信装置がＨＤを支援できる場合には、放送受信装置は、ＳＳＣに基づいて、より詳細なサービス関連情報を受信することができる。また、放送受信装置は、ＳＳＣから、サービスの全ての性能情報（ｃａｐａｂｉｌｉｔｙ）を取得することができる。また、放送受信装置は、ＭＰＤ内の情報（ｅ．ｇ．Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＠ｄｅｐｅｎｄｅｎｃｙＩｄ）を用いて、ｒｅｐｒｅｓｅｎｔａｔｉｏｎ間のｄｅｐｅｎｄｅｎｃｙ関係（すなわち、ｂａｓｅ／ｅｎｈａｎｃｅｄｌａｙｅｒ）、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの解像度（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎのｗｉｄｔｈ／ｈｅｉｇｈｔａｔｔｒｉｂｕｔｅ）などを認知することができる。また、本発明の一実施例に係るＳＭＴのｃａｐａｂｉｌｉｔｙは、ＨＤ／ＵＤの２つの性能情報（ｃａｐａｂｉｌｉｔｙ）を有することができる。仮に放送受信装置がＵＤを支援できない場合には、放送受信装置は、ＨＤに該当するコンポーネントを受信及び／又はデコーティングすることができる。

仮に放送受信装置がＵＤを支援できる場合には、放送受信装置は、前述したシナリオを行った後、ＵＤに該当するコンポーネントを受信及び／又はデコーティングすることができる。

図１５０は、本発明の一実施例に係る、受信機移動時における他の周波数へのハンドオーバー（ｈａｎｄｏｖｅｒ）状況を示す図である。

特定サービスを受信している受信機が移動する場合、そのサービスをシームレス（ｓｅａｍｌｓｓ）に視聴するための他の周波数へのハンドオーバー動作が必要であろう。ここで、受信機が移動する場合は、様々な状況があり、特に、受信機がモバイルデバイスである場合に該当し得る。

特定サービスを提供する送信機は地域別に複数個存在してもよい。受信機が、特定送信機がカバーする地域を離れて他の送信機がカバーする地域へ移動する場合には、シームレスハンドオーバーのための情報又は動作がさらに必要である。ここで、ＭＦＮ状況を仮定する。同じサービスが地域別に異なる周波数を介して送出される状況を仮定する。

同図の実施例で、受信機は、送信機Ａ（ＴｒａｎｓｍｉｔｔｅｒＡ）のカバーする地域を離れて、送信機Ｂのカバーする地域へ移動することができる。この間に、受信機はサービスＸを視聴していると仮定する。ここで、送信機ＡはサービスＸを周波数１０で送出しており、送信機Ｂは、同じサービスＸを周波数２０で送出しているとする。サービスＸを持続して再生するために、受信機は、適切な周波数にチューニングするための情報を必要としてもよい。

図１５１は、本発明の一実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。

前述したように、シームレスハンドオーバーのために、受信機は適切な情報を必要としてもよい。このような情報は、実施例によって、前述したＬＬＳ（ＬｉｎｋＬａｙｅｒＳｉｇｎａｌｉｎｇ）、ＬＬＳ（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）、ＳＬＴ（ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ）、ＳＳＣ（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌ）又はそれぞれのＳＬＳ（ＳｅｒｖｉｃｅＬｅｖｅｌＳｉｇｎａｌｉｎｇ）を介して伝達され得る。ここで、シームレスハンドオーバーのための情報をＣＩＤ（ＣｅｌｌＩｎｆｏｒｍａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）と呼ぶことができる。

同図の実施例は、ＣＩＤがリンクレイヤシグナリングを介して伝達される場合を示している。

同図の実施例で、ブロードキャストストリームを介してサービスデータが伝達されている。このブロードキャストストリームは、ブロードキャストストリームＩＤで識別することができる。ブロードキャストストリームは、特定大域幅の中央周波数値と定義されるＲＦチャネルのアブストラクション（ａｂｓｔｒａｃｔｉｏｎ）であり、地域（ａｒｅａ）と周波数（ｆｒｅｑｕｅｎｃｙ）情報で識別されてもよい。ブロードキャストストリームは複数個のＰＬＰを含むことができる。ＰＬＰは、ＤＰと呼ぶこともできる。本実施例では、ＢＳＩＤ＝１で識別されるブロードキャストストリームでサービスデータが伝達されている。

前述した伝送セッション、ＲＯＵＴＥ／ＭＭＴＰセッションは、複数個のＰＬＰを介して伝送されてもよい（ＰＬＰＩＤ＝１，２，３）。伝送セッション、例えば、ＲＯＵＴＥセッションはＩＰ、ＵＤＰ情報（ＩＰａｄｄｒｅｓｓ１，ＵＤＰｐｏｒｔｎｕｍｂｅｒ１）によって識別されてもよく、複数個のＬＣＴセッションを含むことができる。各ＬＣＴセッションは、サービスデータであるオーディオ／ビデオセグメントを伝達することができる。前述したように、特定ＬＣＴセッション（例えば、ｔｓｉ＝０のＬＣＴセッション）を介してＳＬＳが伝達されてもよい。同図の実施例では、これをＳＣＳフラグメントと表現している（ｔｓｉ＝ｓ）。同図の実施例では、ＬＳＩＤが用いられ、これが他のＬＣＴセッションで伝達されると表現しているが、実施例によって、ＬＳＩＤは前述のＳ−ＴＳＩＤに代替してもよく、このＳ−ＴＳＩＤは、ＳＬＳに含まれて伝達されてもよい。また、ＦＩＣが用いられ、このＦＩＣがＰＬＰではなく別途のチャネルで伝達されると表現しているが、実施例によって、ＦＩＣをＬＬＳ（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）及びＳＬＴに代替してもよく、このＬＬＳは、前述したように、知られた（ｗｅｌｌｋｎｏｗｎ）ＩＰ／ＵＤＰを介して伝達されてもよい。

本実施例で、ＣＩＤは、リンクレイヤシグナリングを介して伝達される（ｔ１５１０１０）。現在周波数で送出される全てのサービスに対して、隣接した送信機ではそれを他の周波数で送出している場合、これに関連した情報を一つのＣＩＤ内に取り集めることができる。

この場合、リンクレイヤシグナリングがＣＩＤ情報を含むことができる。リンクレイヤシグナリングは、受信機が、ＳＬＴ、ＳＬＳなどの情報よりも先に取得できる情報であり、受信機でＣＩＤが早く取得されるようにすることができる。もちろん、隣接送信機が一部のサービスに対してのみ他の周波数で送出している場合にも、リンクレイヤシグナリングを介してＣＩＤが伝達されてもよい。この場合、ＣＩＤは、サービス別にハンドオーバー情報を有することができる。例えば、一つの周波数に５つのサービスが含まれて伝送される場合、そのうち２つのサービスに対してのみ隣接送信機が他の周波数で送出されていると、ＣＩＤは、その２つのサービスに対するハンドオーバー情報を提供することができる。残り３つのサービスに対してはハンドオーバー情報が必要でないので、ＣＩＤは、関連情報を含まないか、又はサービスを同一周波数で送出している送信機に関する情報を含むこともできる。

シームレスハンドオーバーのための情報又はＣＩＤ情報に関する詳細な内容は後述する。

図１５２は、本発明の他の実施例に係る、シームレスハンドオーバーのための情報伝達方案を示す図である。

前述したように、シームレスハンドオーバーのための情報は、ＳＬＳに含まれて伝送されてもよい（ｔ１５２０１０）。ＳＬＳが含まれて伝送されるＬＣＴセッションをＳＳＣ（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌ）と呼ぶこともできる。

前述したように、ＳＬＳは、各サービス別に、そのサービスに対するシグナリングを行うことができる。ＳＬＳにＣＩＤ情報が含まれて伝送される場合、当該ＣＩＤは、そのＳＬＳがシグナリングするサービスに対するハンドオーバー情報を含むことができる。

例えば、ＳＬＳがサービス＃１をシグナリングする場合、そのＳＬＳに含まれて伝送されるＣＩＤは、サービス＃１を、同一の又は他の周波数で伝送する他の隣接送信機に関する情報を含むことができる。したがって、移動している受信機は、当該ＣＩＤ情報を用いてサービス＃１をシームレスに再生することができる。

ここで、ＣＩＤがＳＬＳに含まれて送信されるという意味は、実施例によって、ＳＬＳにＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどと共にＣＩＤが含まれるという意味であってもよい。また、実施例によって、ＳＬＳに含まれるＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどが拡張されてＣＩＤ情報を含むという意味であってもよい。また、実施例によって、ＣＩＤが、ＳＬＳに含まれるＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなどに分散されて送信されるという意味であってもよい。また、実施例によって、ＳＬＳに該当する情報を用いて、受信機がＣＩＤに該当する情報を計算し得るという意味であってもよい。

図示してはいないが、前述したように、ＣＩＤ情報は、ＬＬＳ（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）、ＳＬＴ（ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ）などを介して伝達されてもよい。ローレベルシグナリング又はＳＬＴを介して伝達される場合、前述したＳＬＴなどのための周知のＩＰ／ＵＤＰによってＣＩＤが伝達されてもよい。当該ＣＩＤは、ＳＬＴによって記述されるサービス又は当該ブロードキャストストリームで伝達されるサービスに対するハンドオーバー情報を含むことができる。

図１５３は、本発明の一実施例に係るシームレスハンドオーバーのための情報を示す図である。

前述したように、このハンドオーバーのための情報をＣＩＤと呼ぶこともできる。ＣＩＤは、隣接送信機で送出している同一サービスにハンドオーバーできるように、送信機の位置、信号強度などの情報を提供することができる。ＣＩＤは、実施例によって異なるように構成されてもよく、後述するホームセル送信機に関する情報とサービス別セルに関する情報のいずれか一方を有することもできる。ここで、ホームセル送信機とは、それぞれの複数個の放送サービスを伝送する現在周波数と同じ周波数を用いて、同一の複数個の放送サービスを送出している他の送信機を意味することができる。ここで、サービス別セルに関する情報とは、特定サービスを伝送する現在周波数と異なる周波数を用いて、その特定サービスを送出している他の隣接送信機に関する情報を意味することができる。

ＣＩＤは、当該ＣＩＤに対する情報を示す部分、ホームセル送信機に関する情報を示す部分、及びサービス別に該当のサービスを伝達する隣接送信機に対する部分を含むことができる。実施例によって、いずれかの部分が省略／変更されてもよく、新しい情報が追加されてもよい。例えば、ホームセル送信機が存在しない場合、サービス別隣接送信機に関する情報だけが含まれてもよい。ホームセル送信機及び隣接送信機は０個以上が存在すればよい。

ＣＩＤは、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄを含むことができる。

＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎと＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎはそれぞれ、当該ＣＩＤのメジャー／マイナープロトコルバージョン情報を示すことができる。

＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄは、ＣＩＤに該当するブロードキャストストリームの識別子であってもよい。ここで、ＣＩＤに該当するブロードキャストストリームは、当該ＣＩＤを送信しているブロードキャストストリームであってもよく、単純に当該ＣＩＤが記述している他のブロードキャストストリームであってもよい。

ＣＩＤは、Ｈｏｍｅ＿ｃｅｌｌ＿ｔｒａｎｓｍｉｔｔｅｒｓエレメントを複数個含むことができる。これは、前述したホームセル送信機に関する情報に該当し得る。各Ｈｏｍｅ＿ｃｅｌｌ＿ｔｒａｎｓｍｉｔｔｅｒｓエレメントは、＠ｌａｔｔｉｔｕｄｅ、＠ｌｏｎｇｉｔｕｄｅ、＠ＡＥＲＰ、＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈ及び／又は＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓなどの情報を含むことができる。

＠ｌａｔｔｉｔｕｄｅは、当該ホームセル送信機の緯度情報を示すことができる。ここで、緯度情報は、度（ｄｅｇｒｅｅ）の小数第２位（ｔｅｎ−ｔｈｏｕｓａｎｄｔｈｓ）までの正確度で示すことができる。緯度情報は、正数／負数の緯度値に対するコンベンショナルな用法として表記されてもよい。

＠ｌｏｎｇｉｔｕｄｅは、当該ホームセル送信機の経度情報を示すことができる。ここで、経度情報は、度（ｄｅｇｒｅｅ）の小数第２位（ｔｅｎ−ｔｈｏｕｓａｎｄｔｈｓ）までの正確度で示すことができる。経度情報は、正数／負数の経度値に対するコンベンショナルな用法として表記されてもよい。

＠ＡＥＲＰは、当該ホームセル送信機の有効なＲＦ電力の理論的測定値であり、ＡＥＲＰは、ＡｖｅｒａｇｅＥｆｆｅｃｔｉｖｅＲａｄｉａｔｅｄＰｏｗｅｒの略語である。ｄＢｋの単位で表現することができ、Ｒａｄｉａｔｉｏｎのアンテナ中心の高さ（ｈｅｉｇｈｔ）によって調整することができる。

＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈは、アンテナの方位角（ａｚｉｍｕｔｈ）パターンの、最大Ｎｕｌｌ値のデプス（ｄｅｐｔｈ）を示すことができる。この値は、８ｄＢの倍数で表現することができ、次に低い倍数値に切り下げて（ｒｏｕｎｄｄｏｗｎ）示すことができる。２４ｄＢよりも大きい値はいずれも２４ｄＢと切り下げてもよい。００値は、該当するデータがないことを示すことができる。

＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓは、アンテナの方位角パターンが８ｄＢ又はピークＡＥＲＰよりも低い場合において、オーディナルディレクション（ｏｒｄｉｎａｌｄｉｒｅｃｔｉｏｎｓ）を示すことができる。これは、当該ビットポジションのゼロによって指示することができる。ノーザン（ｎｏｒｔｈｅｎ）セクターは、ｍｓｂ値によって示すことができる。それぞれの連続するビットは時計回り方向に進行することができ、したがって、ＮＥ（ＮｏｒｔｈＥａｓｔ）の場合、すぐ次のｍｓｂ値によって示すことができる。このような方式でＮＷ（ＮｏｒｔｈＷｅｓｔ）まで進行することができる。ＮＷの場合、ｌｓｂ値によって示すことができる。このフィールドの値が１１１１１１１１の場合、該当するデータがないことを意味できる。

ＣＩＤは、複数個のＳｅｒｖｉｃｅエレメントをさらに含むことができる。ここで、Ｓｅｒｖｉｃｅエレメントは、前述したサービス別セル情報に該当し得る。このサービスエレメントは、それぞれのサービスに対して、そのサービスを他の周波数で送出している周辺の受信機に関する情報を含むことができる。サービス当たり０個以上の隣接送信機が存在すればよい。

Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅ＿ｉｄ及び／又は＠ｇｌｏｂａｌＵｎｉｑｕｅＳｅｒｉｖｅＩｄを含むことができる。それぞれは、当該サービスのサービスＩＤ及びグローバルにユニークなサービスＩＤを示すことができる。

Ｓｅｒｖｉｃｅエレメントは、Ｃｅｌｌエレメントをさらに含むことができる。それぞれのＣｅｌｌエレメントは、隣接した送信機に関する情報を含むことができる。

それぞれのＣｅｌｌエレメントは、＠ｌａｔｔｉｔｕｄｅ、＠ｌｏｎｇｉｔｕｄｅ、＠ＡＥＲＰ、＠ｒｅｌａｔｉｖｅ＿ｐａｔｔｅｒｎ＿ｄｅｐｔｈ及び／又は＠ｎｕｌｌ＿ｐｏｓｉｔｉｏｎｓを含むことができる。それぞれのフィールドは、当該セル、すなわち、隣接送信機に対する緯度／経度情報、ＡＥＲＰ情報、相対的パターンデプス情報、ヌルポジション情報などを示すことができる。フィールドに関する詳細な説明は、前述したとおりであり、ただし、この場合、ホームセル送信機に関する情報ではなく、当該サービスを他の周波数で送出している隣接送信機に関する情報である点が異なる。

それぞれのＣｅｌｌエレメントは、＠ｆｒｅｑｕｅｎｃｙ、＠ｐｒｅａｍｂｌｅ、＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ、＠ＤＰ＿ｉｄ、＠ｐｒｏｖｉｄｅｒ＿ｉｄ、＠ｓｅｒｖｉｃｅ＿ｉｄ情報をさらに含むことができる。

＠ｆｒｅｑｕｅｎｃｙは、当該サービスを他の周波数で送出している隣接送信機において、当該サービスを送出している他の周波数に関する情報を示すことができる。正確には、当該サービスを送出している帯域幅の中央周波数（ｃｅｎｔｅｒｆｒｅｑｕｅｎｃｙ）情報を示すことができる。

＠ｐｒｅａｍｂｌｅは、当該サービスを送信する他の周波数に対するプリアンブルシンボルに関する情報を示すことができる。ここで、プリアンブルシンボルとは、信号フレームのブートストラップ情報、Ｌ１情報、プリアンブル情報又はＰ１情報などを表すことができる。

＠ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄは、当該隣接送信機が当該サービスを送出しているブロードキャストストリームの識別子を示すことができる。

＠ＤＰ＿ｉｄは、当該隣接送信機が当該サービスを送出しているＰＬＰ又はＤＰの識別子を示すことができる。ここで、実施例によって、このフィールドは、当該サービスのＳＬＴ情報が伝達されるＰＬＰのＩＤ情報を示すことができる。また、実施例によって、このフィールドは、当該サービスのＳＬＳ情報が伝達されるＰＬＰのＩＤ情報を示すことができる。また、実施例によって、このフィールドは、当該サービスのサービスデータが伝達されるＰＬＰの情報を示すことができる。実施例によって、このフィールドは、サービス別に複数個存在してもよい。

＠ｐｒｏｖｉｄｅｒ＿ｉｄは、当該隣接送信機が送出しているサービスのサービスプロバイダー識別子情報を示すことができる。

＠ｓｅｒｖｉｃｅ＿ｉｄは、当該隣接送信機が送出しているサービスのサービス識別子を示すことができる。ホームセル送信機が送出している同一サービスに対して同一のＩＤ値を有することもでき、異なるＩＤ値を有することもできる。同一のＩＤ値を有する場合、このフィールドの値は、Ｓｅｒｖｉｃｅ＠ｓｅｒｖｉｃｅ＿ｉｄフィールドと同じ値を有することができる。

図１５４は、本発明の一実施例に係るローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。

ローレベルシグナリング情報は、物理層とローレベルシグナリングが伝達される層の上位層とを連結させる役割を担うシグナリング情報を含むことができる。受信機は、ローレベルシグナリング情報を用いて、物理層で伝達された放送信号から、所望の放送サービス／コンテンツを効率的に見つけることができる。

ローレベルシグナリング情報はＦＩＣ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＣｈａｎｎｅｌ）を含むことができる。ＦＩＣは、別の名称にしてもよく、一例として、ＳＬＴ（ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ）と命名することもできる。

本発明の一実施例では、各サービスのＭｉｎｉｍｕｍｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅを定義し、それに対するシグナリング情報をＦＩＣに追加して、受信機のサービススキャン（ｓｅｒｖｉｃｅｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅｒｅｎｄｅｒｉｎｇ）が効率的に行われるようにする方案を提案する。

同図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。

ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報は、ＦＩＣシグナリング構造のプロトコルのバージョンを識別する。

Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報は、放送ストリームを識別する情報である。

ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報は、ＳｅｒｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ（ＳＣＤ）が伝送されるか（又は、存在するか）否かを示すことができる。ＳＣＤは、サービスレベルシグナリング情報を含むことができる。

ＤＰ＿ｉｄ情報は、ローレベルシグナリング情報及び／又はサービスレベルシグナリング情報を伝送するデータパイプ（又は、ＰＬＰ）を識別する情報である。

ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメントは、ＦＩＣレベルのディスクリプタを含むことができる。

ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報は、ＦＩＣによってスキャンし得る放送サービスの個数を示す。

ｐｒｏｖｉｄｅｒ＿ｉｄ情報は、放送サービスを提供するプロバイダーを識別する情報である。

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

ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報は、サービスシグナリングチャネル（ＳＳＣ、又はサービスレベルシグナリング）のバージョンを示す情報である。

ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報は、サービスのチャネル番号を示す。

ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、サービスのカテゴリーを識別する。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報は、放送サービスがＡ／Ｖサービス、オーディオサービス、ＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）サービス、及び／又はＮＲＴ（ＮｏｎＲｅａｌＴｉｍｅ）サービスであるかを示すことができる。

ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報は、サービスの短いサービス名を表す情報の長さを示す情報である。

ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報は、サービスの短いサービス名を示す。

ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、サービスの状態を示す。例えば、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報は、サービスが、ａｃｔｉｖｅ状態、ｉｎａｃｔｉｖｅ状態、ｓｈｏｗ状態及び／又はｈｉｄｄｅｎ状態であることを示すことができる。

ｓｐ＿ｉｎｄｉｃａｔｏｒ情報は、サービスにサービス保護（ｓｅｒｖｉｃｅｐｒｏｔｅｃｔｉｏｎ）が適用されたかどうかを示す情報である。

ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報は、サービスと関連したＩＰパケットに用いられるＩＰバージョン情報を示す情報である。ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報のｔｒｕｅ、ｆａｌｓｅ値によって、ＩＰｖ４又はＩＰｖ６であることを示すことができる。

ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報は、サービスシグナリングチャネルのソース（ｓｏｕｒｃｅ）ＩＰアドレスを示す情報が存在するか否か識別する情報である。

ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、サービスをレンダリングするために要求される、受信機の最小性能を示す情報である。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣによってシグナリングされる放送サービスをレンダリングするために受信機が揃えるべき最小限の性能を識別する。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、当該サービスの表出（ｐｒｅｓｅｎｔａｔｉｏｎ）に必須の最小性能プロファイル（ｍｉｎｉｍｕｍｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅ）を表現する。このプロファイル（ｐｒｏｆｉｌｅ）に対して、ＦＩＣのｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報と関連付けて、その値の範囲を定義することができる。

ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報は、サービスシグナリングチャネルを伝送するソース（ｓｏｕｒｃｅ）のＩＰアドレスを示す情報である。

ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報は、サービスシグナリングチャネルに対するデスティネーション（ｄｅｓｃｔｉｎａｔｉｏｎ）のＩＰアドレスを示す情報である。

ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報は、サービスシグナリングチャネルに対するデスティネーション（ｄｅｓｃｔｉｎａｔｉｏｎ）のＵＤＰポート番号を示す情報である。

ＳＳＣ＿ＴＳＩ情報は、サービスシグナリングチャネルのデータを伝送する伝送セッションを識別する情報である。

ＳＳＣ＿ＤＰ＿ｉｄ情報は、サービスシグナリングチャネルのデータを伝送するデータパイプを識別する情報である。

ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報は、放送サービスが基本であるか否かを識別する情報である。ＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報は、サービスシグナリングを送るＲＯＵＴＥセッションと同じＲＯＵＴＥセッションでオーディオ、ビデオ或いはキャプションデータが併せて送られ、サービスシグナリングを送るデータパイプで全てのデータが併せて伝送されるかを識別する情報である。

同図の（ｂ）を参照すると、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスがリニア（ｌｉｎｅａｒ）サービスである場合、サービスをレンダリングするために受信機に要求される最小性能が、ＨＤ（ＨｉｇｈＤｅｆｉｎｉｔｉｏｎ）処理性能か又はＵＨＤ（ＵｌｔｒａＨｉｇｈＤｅｆｉｎｉｔｉｏｎ）処理性能かなどが、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報によって識別されてもよい。例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報が示すサービスのカテゴリーがリニア（ｌｉｎｅａｒ）サービスであり、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の値が「ｘ１」である場合、当該サービスは、少なくともＵＨＤをレンダリングできる装置（ｄｅｖｉｃｅ）だけが、ＦＩＣを用いた放送スキャンを介して、チャネルマップ（ＣｈａｎｎｅｌＭａｐ）に当該サービスを追加するようにすることができる。これは、受信機が支援できないサービスを提供する場合、チャネルマップに当該サービスが含まれないようにすることで、ユーザにとって視聴不可能なサービスは選択しないようにし、チャネル選択時に効率性を図ることができる。

ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスがアプリケーション（Ａｐｐ；Ａｐｐｌｉｃａｔｉｏｎ）サービスである場合、サービスを介してレンダリングするために受信機に要求される最小性能が、ブロードバンドを介してダウンロード可能な性能を備えるべきか、ブロードバンドを介さなくともダウンロード可能な性能を備えるべきが、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報によって識別されてもよい。

図１５５は、本発明の一実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。

同図の（ａ）を参照すると、受信機は、放送信号内の特定領域で伝送されるＦＩＣを取得することができる。

受信機は、ＦＩＣ内のｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報をパーシングし、ｓｅｒｖｉｃｅ＿ｉｄ情報によって識別されるサービスがアプリケーションサービスであるかを識別することができる。

受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報が有する値のＭＳＢ（ＭｏｓｔＳｉｇｎｉｆｉｃａｔｎＢｉｔ）をチェックする。

受信機はｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報のＭＳＢが「１」の場合、アプリケーションサービスに含まれるコンポーネントがブロードバンドで伝送されていないことと認識することができる。これは、アプリケーションサービスに含まれるコンポーネントが放送網で伝送されることを示す。したがって、放送網を介してコンポーネントをダウンロードできない受信機は、当該アプリケーションサービスをレンダリングできないということが認識できる。したがって、放送網を介してコンポーネントをダウンロードできる受信機のみが、チャネルマップに当該アプリケーションサービスを含め、放送網を介してコンポーネントをダウンロードできない受信機は、チャネルマップに当該アプリケーションサービスを含めなくてもよい。

本発明の一実施例は、受信機で、ＦＩＣのｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を取得するだけでも、受信機で支援しないサービスをチャネルマップに登録しないようにすることによって、支援しないサービスに対する誤作動確率を減らすことができる。

同図の（ｂ）を参照すると、ＵＳＤは、ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントを含むことができる。ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントは、それぞれのサービスをレンダリングするために受信機に要求される性能に関する情報を含むことができる。この例では、ＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメント内の情報は、受信機がブロードバンド網を介さず、放送網を介して、特定サービスのコンポーネントを受信可能でなければならないことを示すことができる。

図１５６は、本発明の他の実施例に係る、ローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。

本発明の他の実施例では、各サービスのＭｉｎｉｍｕｍｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅを定義し、これに対するシグナリング情報をＦＩＣに追加して、受信機のサービススキャン（ｓｅｒｖｉｃｅｓｃａｎ）及び／又はサービスレンダリング（ｓｅｒｖｉｃｅｒｅｎｄｅｒｉｎｇ）が効率的に行われるようにする方案を提案する。

それぞれの情報又はエレメントに関する説明は、前述した説明に代える。

本実施例では、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に１０ビットを割り当てることができる。この場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報が、将来追加される性能（ｃａｐａｂｉｌｉｔｙ）関連情報の拡張を支援することができる。

同図の（ｂ）を参照すると、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の構造が示されている。

例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスのカテゴリーがリニア（Ｌｉｎｅａｒ）サービスである場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられたビットのうち、４ビットは、ビデオを処理するために要求される性能を識別するビデオ性能プロファイル（Ｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅ）と定義し、他の４ビットは、オーディオを処理するために要求される性能を識別するオーディオ性能プロファイルと定義することができる。

例えば、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報によって識別されるサービスのカテゴリーがアプリケーション（Ａｐｐ；Ａｐｐｌｉｃａｔｉｏｎ）サービスである場合、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられたビットのうち、２ビットは、アプリケーションサービスをダウンロードするために用いられるプロトコル（Ｄｏｗｎｌｏａｄｐｒｏｔｏｃｏｌ）と関連して受信機に要求される性能プロファイル（Ｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅ）を示すものと定義されてもよい。

図１５７は、本発明の他の実施例に係る、ローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。

同図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。

ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣに含まれ得る最小性能情報の個数を示す。ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣで定義される最小性能プロファイル（ｍｉｎｉｍｕｍｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅ）の数を示す。最小性能プロファイルは、最大４個までＦＩＣに含まれてもよい。

ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報は、ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の値がどのタイプのコンポーネントと関連しているかを示す情報である。

ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、サービスの表出のために必須の、受信機の最小性能プロファイルを示す。ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、サービスをレンダリングするために受信機に要求される最小限の性能を識別する情報である。

同図の（ｂ）を参照すると、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値によって、当該情報が示すコンポーネントが開示されている。例えば、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が「００」である場合、最小性能プロファイルの適用されるコンポーネントがビデオコンポーネントであることを示すことができ、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が「０１」の場合、最小性能プロファイルの適用されるコンポーネントがオーディオコンポーネントであることを示すことができ、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報の値が「１０」の場合、最小性能プロファイルの適用されるコンポーネントがアプリケーション（Ａｐｐ，Ａｐｐｌｉｃａｔｉｏｎ）コンポーネントであることを示すことができる。

図１５８は、本発明の他の実施例に係る、ローレベルシグナリング（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）情報を示す図である。

同図の（ａ）を参照すると、ＦＩＣは、ＦＩＣ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ情報、Ｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄ情報、ＳＣＤ＿ｅｘｉｓｔ＿ｆｌａｇ情報、ＤＰ＿ｉｄ情報、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ＦＩＣ＿ｌｅｖｅｌ＿ｄｅｓｃｒｉｐｔｏｒ（）エレメント、ｎｕｍ＿ｓｅｒｖｉｃｅｓ情報、ｐｒｏｖｉｄｅｒ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｉｄ情報、ｓｅｒｖｉｃｅ＿ｄａｔａ＿ｖｅｒｓｉｏｎ情報、ｓｅｒｖｉｃｅ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ情報、ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ情報、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ情報、ｓｅｒｖｉｃｅ＿ｓｔａｔｕｓ情報、ｓｐ＿ｉｎｄｉｃａｔｏｒ情報、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ＿ｆｌａｇ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒ情報、ＳＳＣ＿ｄｓｔ＿ｐｏｒｔ情報、ＳＳＣ＿ＴＳＩ情報、ＳＳＣ＿ＤＰ＿ｉｄ情報、及び／又はＳＳＣ＿ｂａｓｉｃｓｅｒｖｉｃｅ情報を含むことができる。

ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報は、ＦＩＣが定義するチャネル（Ｃｈａｎｎｅｌ）の最小性能プロファイル（ｍｉｎｉｍｕｍｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅ）を示す。ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報には８ビットを割り当てることができる。８ビットに含まれる各ビットの組合せによって、最小性能プロファイルがいかなるコンポーネントタイプの性能プロファイル（ｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅ）に該当するかを定義することができる。

同図の（ｂ）を参照すると、ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報に割り当てられるビットの組合せ及びそれらが示す情報が示されている。

８ビットの中、ＭＳＢの２ビットは、性能プロファイル（ｃａｐａｂｉｌｉｔｙｐｒｏｆｉｌｅ）が適用されるコンポーネントのタイプを示す。例えば、２ビットの値が「００」の場合、最小性能プロファイルの適用されるコンポーネントがビデオコンポーネントであることを示すことができ、２ビットの値が「０１」の場合、最小性能プロファイルの適用されるコンポーネントがオーディオコンポーネントであることを示すことができ、２ビットの値が「１０」の場合、最小性能プロファイルの適用されるコンポーネントがアプリケーション（Ａｐｐ，Ａｐｐｌｉｃａｔｉｏｎ）コンポーネントであることを示すことができる。

８ビットのうち、２ビットを割り当てて、ビデオコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が「００」の場合、ＨＤビデオチャネルが提供され、受信機はＨＤビデオを処理し得る能力が要求されることを示し、２ビットの値が「０１」の場合、ＵＨＤビデオチャネルが提供され、受信機はＵＨＤビデオを処理し得る能力が要求されることを示す。

８ビットのうち、２ビットを割り当てて、オーディオコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が「００」の場合、既存放送システム（例えば、ＡＴＳＣ１．０放送システム）で適用される形態のオーディオコンポーネントが提供され、受信機は既存放送システムで提供される形態のオーディオコンポーネントを処理し得る能力が要求されることを示し、２ビットの値が「０１」の場合、次世代放送システム（例えば、ＡＴＳＣ３．０放送システム）で適用される形態のオーディオコンポーネントが提供され、受信機は次世代放送システムで提供される形態のオーディオコンポーネントを処理し得る能力が要求されることを示す。

８ビットのうち、２ビットを割り当てて、アプリケーションのコンポーネントに適用される最小性能プロファイルを識別することができる。例えば、２ビットの値が「００」の場合、アプリケーションのコンポーネントがブロードバンドで提供され、受信機は、当該コンポーネントを受信処理するために、ブロードバンドを介したダウンロードを処理し得る能力が要求されることを示し、２ビットの値が「０１」の場合、アプリケーションのコンポーネントがブロードバンドで提供されず、受信機は、当該コンポーネントを受信処理するために、ブロードバンド以外のネットワーク（例えば、放送網）を介したダウンロードを処理し得る能力が要求されることを示す。

図１５９は、本発明の他の実施例に係る、ＦＩＣを用いて、受信機でサービスを表出する過程を示す図である。

受信機は、ＦＩＣ内のｃｈａｎｎｅｌ＿ｃａｐａｃｉｔｙ＿ｐｒｏｆｉｌｅ情報（ｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、及び／又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を含み得る。）を取得する。

受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の一部ビット又はｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報を用いて、性能プロファイルが適用されるコンポーネントのタイプを識別することができる。

受信機は、ＦＩＣ内のｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報の一部ビット又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を用いて、それぞれのコンポーネントタイプに適用される最小性能プロファイルを識別することができる。

本発明によれば、受信機は、ＦＩＣレベルの情報を用いて、各チャネルを表出するために受信機に要求される性能がわかる。ＦＩＣに記述されるチャネルレベル（ＣｈａｎｎｅｌＬｅｖｅｌ）の性能（ｃａｐａｂｉｌｉｔｙ）は、全チャネルに共通適用され得る、よく変わらない性能（ｃａｐａｂｉｌｉｔｙ）と記述されてもよい。

同図の（ｂ）を参照すると、ＵＳＤに含まれ得るＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントが開示されている。ＵＳＤに含まれるＣａｐａｂｉｌｉｔｙＤｅｓｃｒｉｐｔｉｏｎエレメントは、サービスレベルにおける性能と関連した情報（Ｓｅｒｖｉｃｅｌｅｖｅｌｃａｐａｂｉｌｉｔｙ）を含むことができる。受信機がサービスを取得する過程で、プログラム（又は、イベント）別性能（ｃａｐａｂｉｌｉｔｙ）は、サービスレベルシグナリングで記述されてもよく、このようなサービスレベル（Ｓｅｒｖｉｃｅｌｅｖｅｌ）における性能（ｃａｐａｂｉｌｉｔｙ）と関連した情報は、ＦＩＣで記述される性能と関連した情報よりも優先順位を有することができる。ここで、性能と関連した情報は、前述したｍｉｎ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報、ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ情報、及び／又はｃａｐａｂｉｌｉｔｙ＿ｐｒｏｆｉｌｅ情報を含むことができる。

図１６０は、本発明の一実施例に係る、放送信号を生成処理する方法を示すフローチャートである。

送信機は、一つ以上の放送サービスのための放送データをエンコーディングする（ＪＳ１６００１０）。

送信機は、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコーディングする（ＪＳ１６００２０）。

送信機は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコーディングする（ＪＳ１６００３０）。

送信機は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する（ＪＳ１６００４０）。

本発明の一実施例によれば、第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングする上で要求される性能を識別する第１性能情報を含むことができる。

図１６１は、本発明の一実施例に係る放送システムを示す図である。

本発明の一実施例に係る放送システムは、放送送信機Ｊ１６１１００及び／又は放送受信機Ｊ１６１２００を含むことができる。

放送送信機Ｊ１６１１００は、放送データエンコーダＪ１６１１１０、シグナリングエンコーダＪ１６１１２０、及び／又は放送信号生成器Ｊ１６１１３０を含むことができる。

放送受信機Ｊ１６１２００は、放送信号受信部Ｊ１６１２１０、プロセッサＪ１６１２２０、及び／又はディスプレイ部Ｊ１６１２３０を含むことができる。

放送データエンコーダＪ１６１１１０は、一つ以上の放送サービスのための放送データをエンコーディングする。

シグナリングエンコーダＪ１６１１２０は、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び／又は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコーディングする。

放送信号生成器Ｊ１６１１３０は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する。

本発明の一実施例によれば、第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含むことができる。

放送信号受信部Ｊ１６１２１０は、一つ以上の放送サービスのための放送データ、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報と一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報とを含む放送信号を受信する。第２レベルシグナリング情報は、一つ以上の放送サービスのための一つ以上の放送コンテンツをデコーティングするために要求される性能を識別する第１性能情報を含むことができる。

プロセッサＪ１６１２２０は、第２レベルシグナリング情報及び第１レベルシグナリング情報を用いて、放送サービスを取得し、放送サービスを表出するように制御する。

ディスプレイ部Ｊ１６１２３０は、放送サービス／コンテンツをディスプレイする。

モジュール又はユニットは、メモリ（又は、記憶ユニット）に記憶された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサによって実行することができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実現されてもよい。このコードは、プロセッサが読み出し可能な記憶媒体に書き込まれ、よって、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサによって読み出されてもよい。

説明の便宜のため、各図を区別して説明したが、各図に開示した実施例を組み合わせて新しい実施例として具現するように設計することも可能である。そして、通常の技術者の必要に応じて、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み出し可能な記録媒体を設計することも、本発明の権利範囲に属する。

本発明に係る装置及び方法は、上述した実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。

一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサが読み出し可能な記録媒体に、プロセッサが読み出し可能なコードとして具現することができる。プロセッサが読み出し可能な記録媒体は、プロセッサによって読み出されるデータが記憶されるいかなる種類の記録装置をも含む。プロセッサが読み出し可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み出し可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み出し可能なコードが記憶され、実行されてもよい。

また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者にとって様々な変形実施が可能であることはもちろんであり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。

そして、当該明細書では、物の発明及び方法の発明の両方が説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。

本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。

本明細書において、装置の発明も方法の発明も言及されており、装置及び方法の発明に関する説明は互いに補完して適用されてもよい。

様々な実施例が、本発明を実施するための形態において説明されている。

本発明は、一連の放送信号提供分野で利用される。

Claims

放送信号を生成し、処理する方法であって、
一つ以上の放送サービスのための放送データを生成するステップと、
前記一つ以上の放送サービスの属性を説明する情報を含むサービスレイヤシグナリング情報を生成するステップと、
前記一つ以上の放送サービスを迅速にスキャンするための基本情報を含むサービスリストシグナリング情報を生成するステップと、
前記放送データ、前記サービスレイヤシグナリング情報、及び前記サービスリストシグナリング情報を含む放送信号を生成するステップと、
を有し、
前記サービスリストシグナリング情報は、前記サービスリストシグナリング情報内に記述される全ての放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第１性能情報を含み、
前記サービスリストシグナリング情報は、前記一つ以上の放送サービスの一つの放送サービスを識別するサービス識別情報を更に含み、
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された前記放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第２性能情報を更に含む、放送信号生成処理方法。
前記サービスレイヤシグナリング情報は、サービスレイヤ特性を記述するＵＳＤを含む、請求項１に記載の放送信号生成処理方法。
前記サービスリストシグナリング情報は、前記サービスレイヤシグナリング情報を伝送するＰＬＰを識別するＰＬＰ識別情報をさらに含む、請求項１に記載の放送信号生成処理方法。
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された放送サービスが、リニアサービス、アプリケーションサービス又はＥＳＧサービスに該当するか否かを識別するサービスカテゴリー情報をさらに含む、請求項３に記載の放送信号生成処理方法。
一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスの属性を説明する情報を含むサービスレイヤシグナリング情報、及び前記一つ以上の放送サービスを迅速にスキャンするための基本情報を含むサービスリストシグナリング情報を含む放送信号を受信する放送信号受信部であって、前記サービスリストシグナリング情報は、前記サービスリストシグナリング情報内に記述される全ての放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第１性能情報を含む、放送信号受信部と、
前記サービスリストシグナリング情報及び前記サービスレイヤシグナリング情報を用いて、前記一つ以上の放送サービスを提供するための制御機能を実行するプロセッサと、
を備え、
前記サービスリストシグナリング情報は、前記一つ以上の放送サービスの一つの放送サービスを識別するサービス識別情報を更に含み、
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された前記放送サービスに対する内容をデコーディングし、提供するために必要な性能を識別する第２性能情報を更に含む、放送信号受信機。
前記サービスレイヤシグナリング情報は、サービスレイヤ特性を記述するＵＳＤを含む、請求項５に記載の放送信号受信機。
前記サービスリストシグナリング情報は、前記サービスレイヤシグナリング情報を伝送するＰＬＰを識別するＰＬＰ識別情報をさらに含む、請求項５に記載の放送信号受信機。
前記サービスリストシグナリング情報は、前記サービス識別情報により識別された放送サービスが、リニアサービス、アプリケーションサービス又はＥＳＧサービスに該当するか否かを識別するサービスカテゴリー情報をさらに含む、請求項７に記載の放送信号受信機。