(57)【特許請求の範囲】
【請求項１】
放送サービスの提供のための情報をサービスシグナリングメッセージに挿入し、前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化する制御部と、
前記伝送プロトコルパケットを伝送する発信部と、
を備える、放送送信装置。
【請求項２】
前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含む、請求項１に記載の放送送信装置。
【請求項３】
前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含む、請求項２に記載の放送送信装置。
【請求項４】
前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー情報、伝送セッション識別子情報、及び関連したパケット識別子情報のうち少なくとも一つを含む、請求項３に記載の放送送信装置。
【請求項５】
前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含む、請求項２に記載の放送送信装置。
【請求項６】
前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含む、請求項５に記載の放送送信装置。
【請求項７】
前記放送サービスを提供するための情報は、伝送セッションに関する情報を含む、請求項１に記載の放送送信装置。
【請求項８】
前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含む、請求項７に記載の放送送信装置。
【請求項９】
前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含む、請求項７に記載の放送送信装置。
【請求項１０】
放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信する受信部と、
前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出し、抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得する制御部と、
を備える、放送受信装置。
【請求項１１】
前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含む、請求項１０に記載の放送受信装置。
【請求項１２】
前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含む、請求項１１に記載の放送受信装置。
【請求項１３】
前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー情報、伝送セッション識別子情報、及び関連したパケット識別子情報のうち少なくとも一つを含む、請求項１２に記載の放送受信装置。
【請求項１４】
前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含む、請求項１１に記載の放送受信装置。
【請求項１５】
前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含む、請求項１４に記載の放送受信装置。
【請求項１６】
前記放送サービスを提供するための情報は、伝送セッションに関する情報を含む、請求項１０に記載の放送受信装置。
【請求項１７】
前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含む、請求項１６に記載の放送受信装置。
【請求項１８】
前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含む、請求項１６に記載の放送受信装置。
【請求項１９】
放送サービスの提供のための情報をサービスシグナリングメッセージに挿入するステップと、
前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化するステップと、
前記伝送プロトコルパケットを伝送するステップと、
を有する、放送送信方法。
【請求項２０】
放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信するステップと、
前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出するステップと、
前記抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得するステップと、
を有する、放送受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関する。
【背景技術】
【０００２】
最近のデジタル放送は、地上波放送網でＡ／Ｖを受信し、インターネット網でＡ／Ｖ及び向上した（Ｅｎｈａｎｃｅｍｅｎｔ）データを受信することを可能にするハイブリッド放送を支援するためのサービス及びコンテンツ伝送同期化方案が要求されている。
【０００３】
特に、将来、ＤＴＶサービスで活用される有力なアプリケーションの一つとして、既存の地上波放送網とインターネット網とを連動させるハイブリッド放送サービスがある。ハイブリッド放送サービスは、地上波放送網を介して伝送される放送コンテンツと関連付けられる向上したデータ、或いは放送コンテンツの一部をインターネット網を介して実時間で伝送し、ユーザが様々なコンテンツを経験できるようにする。したがって、放送コンテンツを地上波放送網及びインターネット網の両方を介して送信し受信する放送送信装置及び放送受信装置が必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
すなわち、デジタル放送システムは、ＨＤ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ  ｃｈａｎｎｅｌ；多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークの堅固性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させる必要がある。また、様々な経路でデジタル放送信号を受信するためのシグナリング情報を受信する必要がある。
【課題を解決するための手段】
【０００５】
本発明の一実施例に係る放送送信装置は、放送サービスの提供のための情報をサービスシグナリングメッセージに挿入し、前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化する制御部と、前記伝送プロトコルパケットを伝送する発信部とを備えることができる。
【０００６】
ここで、前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含むことができる。
【０００７】
ここで、前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含むことができる。
【０００８】
ここで、前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー（ｐｏｒｔ  ｎｕｍｂｅｒ）情報、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）情報、及び関連したパケット識別子（ｐａｃｋｅｔ  Ｉｄｅｎｔｉｆｉｅｒ）情報のうち少なくとも一つを含むことができる。
【０００９】
ここで、前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含むことができる。
【００１０】
ここで、前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含むことができる。
【００１１】
ここで、前記放送サービスを提供するための情報は、伝送セッションに関する情報を含むことができる。
【００１２】
ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含むことができる。
【００１３】
ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含むことができる。
【００１４】
本発明の一実施例に係る放送受信装置は、放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信する受信部と、前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出し、抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得する制御部とを備えることができる。
【００１５】
ここで、前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含むことができる。
【００１６】
ここで、前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含むことができる。
【００１７】
ここで、前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー（ｐｏｒｔ  ｎｕｍｂｅｒ）情報、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）情報、及び関連したパケット識別子（ｐａｃｋｅｔ  Ｉｄｅｎｔｉｆｉｅｒ）情報のうち少なくとも一つを含むことができる。
【００１８】
ここで、前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含むことができる。
【００１９】
ここで、前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含むことができる。
【００２０】
ここで、前記放送サービスを提供するための情報は、伝送セッションに関する情報を含むことができる。
【００２１】
ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含むことができる。
【００２２】
ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含むことができる。
【００２３】
本発明の一実施例に係る放送送信方法は、放送サービスの提供のための情報をサービスシグナリングメッセージに挿入するステップと、前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化するステップと、前記伝送プロトコルパケットを伝送するステップとを有することができる。
【００２４】
本発明の一実施例に係る放送受信方法は、放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信するステップと、前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出するステップと、
【００２５】
前記抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得するステップとを有することができる。
【発明の効果】
【００２６】
本発明の実施例によれば、放送システムの伝送効率を上げることができる。
【００２７】
本発明の実施例によれば、ハイブリッド放送サービスを提供することができる。
【００２８】
本発明の実施例によれば、放送受信装置がブロードバンドでメディアストリームを受信することができる。
【図面の簡単な説明】
【００２９】
本発明の更なる理解を助けるために含まれ、且つ本出願に含まれてその一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に本発明の実施例を示す。
【００３０】
【図１】本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す図である。
【図２】本発明の一実施例に係るインプットフォーマット（Ｉｎｐｕｔ  ｆｏｒｍａｔｔｉｎｇ；入力フォーマット）ブロックを示す図である。
【図３】本発明の他の実施例に係るインプットフォーマット（入力フォーマット）ブロックを示す図である。
【図４】本発明の一実施例に係るＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。
【図５】本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【図６】本発明の一実施例に係るフレームビルディング（Ｆｒａｍｅ  Ｂｕｉｌｄｉｎｇ；フレーム生成）ブロックを示す図である。
【図７】本発明の一実施例に係るＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）ジェネレーション（ｇｅｎｅｒａｔｉｏｎ；生成）ブロックを示す図である。
【図８】本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す図である。
【図９】本発明の一実施例に係るフレーム構造を示す図である。
【図１０】本発明の一実施例に係るフレームのシグナリング階層構造を示す図である。
【図１１】本発明の一実施例に係るプリアンブルシグナリングデータを示す図である。
【図１２】本発明の一実施例に係るＰＬＳ１データを示す図である。
【図１３】本発明の一実施例に係るＰＬＳ２データを示す図である。
【図１４】本発明の他の実施例に係るＰＬＳ２データを示す図である。
【図１５】本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ；論理）構造を示す図である。
【図１６】本発明の一実施例に係るＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）マッピングを示す図である。
【図１７】本発明の一実施例に係るＥＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ）マッピングを示す図である。
【図１８】本発明の一実施例に係るＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）マッピングを示す図である。
【図１９】本発明の一実施例に係るＦＥＣ（ｆｏｒｗａｒｄ  ｅｒｒｏｒ  ｃｏｒｒｅｃｔｉｏｎ）構造を示す図である。
【図２０】本発明の一実施例に係るタイムインターリービングを示す図である。
【図２１】本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す図である。
【図２２】本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す図である。
【図２３】本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す図である。
【図２４】本発明の一実施例に係る各インターリービングアレイ（ａｒｒａｙ）からインターリービングされたＸＦＥＣＢＬＯＣＫを示す図である。
【図２５】本発明の一実施例に係る放送サービスを支援するためのプロトコルスタック（ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示す図である。
【図２６】本発明の一実施例に係る放送サービスの伝送層を示す図である。
【図２７】本発明の一実施例に係るＩＰネットワークを介したメディアコンテンツ送受信システムの構成を示す図である。
【図２８】本発明の一実施例に係るＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）の構造を示す図である。
【図２９】本発明の一実施例に係る放送受信装置の構成を示す図である。
【図３０】本発明の他の実施例に係る放送受信装置の構成を示す図である。
【図３１】本発明の他の実施例に係る放送受信装置の構成を示す図である。
【図３２】本発明の更に他の実施例に係る放送受信装置の構成を示す図である。
【図３３】本発明の一実施例に係る放送伝送フレームを示す図である。
【図３４】本発明の他の実施例に係る放送伝送フレームを示す図である。
【図３５】本発明の一実施例に係る伝送パケットの構成を示す図である。
【図３６】本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。
【図３７】本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。
【図３８】本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示す図である。
【図３９】本発明の一実施例に係るサービスシグナリングメッセージにおいてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが示す値が意味する内容を示す図である。
【図４０】本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。
【図４１】本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。
【図４２】本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。
【図４３】本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。
【図４４】本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。
【図４５】本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。
【図４６】本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。
【図４７】図３８乃至図４６の実施例においてタイムベース及びサービスシグナリングメッセージを取得する手順を示す図である。
【図４８】本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示す図である。
【図４９】本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示す図である。
【図５０】図４９で説明した各伝送モードが有する値による意味を示す図である。
【図５１】次世代放送システムにおいて放送サービスのコンポーネントデータ取得経路をシグナルするシグナリングメッセージの構成を示す図である。
【図５２】本発明の一実施例に係るａｐｐ＿ｄｅｌｅｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す図である。
【図５３】本発明の他の実施例に係るａｐｐ＿ｄｅｌｅｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す図である。
【図５４】放送サービスを構成する一つ以上のコンポーネントデータを取得できる経路情報を含むコンポーネントロケーションシグナリングを示す図である。
【図５５】図５４のコンポーネントロケーションシグナリングの構成を示す図である。
【図５６】本発明の一実施例において次世代放送システムで放送サービスのシグナリングが含む他の情報を示す図である。
【図５７】本発明の一実施例に係る次世代放送システムのサービスシグナリングが含む伝送モードを示す図である。
【図５８】本発明の一実施例に係る次世代放送システムのサービスシグナリングが含むブートストラップに関する情報を示す図である。
【図５９】オブジェクトフローに対するシグナリングが含む他の情報を示す図である。
【図６０】本発明の一実施例においてファイル書式（Ｆｉｌｅ  Ｔｅｍｐｌａｔｅ）を表現するための情報の組合せを示す図である。
【図６１】本発明の一実施例に係るサービスシグナリングが含むオブジェクトフローを示す図である。
【図６２】本発明の一実施例において次世代放送システムで放送サービスのシグナリングが含む他の情報を示す図である。
【図６３】本発明の一実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す図である。
【図６４】本発明の他の実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す図である。
【図６５】本発明の一実施例に係る放送受信装置の動作手順を示すフローチャートである。
【図６６】本発明の一実施例に係る放送伝送装置の動作手順を示すフローチャートである。
【発明を実施するための形態】
【００３１】
本発明の好適な実施例について具体的に説明し、その例を添付の図面に図示する。添付の図面を参照している下記の詳細な説明は、本発明の実施例によって具現可能な実施例を限定するものではなく、本発明の好適な実施例を説明するためのものである。下記の詳細な説明は、本発明に関する徹底した理解を提供するために細部事項を含む。ただし、当業者にとってこのような細部事項無しにも本発明を実行できるということは明らかである。
【００３２】
本発明では、当該分野で広く使われている一般的な用語を選択するが、一部の用語は出願人によって任意に選択されてもよく、その意味は必要時に、該当する部分で詳しく説明するものとする。したがって、本発明は、用語の単純な名称又は意味ではなく、意図する用語の意味に基づいて理解されなければならない。
【００３３】
本発明は、次世代放送サービスに対する放送信号送信及び受信装置並びに方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含むことができる。
【００３４】
以下では、説明の便宜のために、ＭＩＳＯ又はＭＩＭＯ方式が２つのアンテナを用いるとするが、本発明は、２つ以上のアンテナを用いるシステムに適用されてもよい。本発明は、特定の用途に要求される性能を達成しながら、受信機の複雑度を最小化するために、最適化された３つのフィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が具現しなければならない全ての構造のサブセットである。
【００３５】
３つのフィジカルプロファイルは、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。後でフィジカルプロファイルがさらに定義されてもよい。システムの発展のために、ヒューチャプロファイルは、ＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を通じて単一ＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクスされてもよい。各フィジカルプロファイルに関する詳細な内容は後述する。
【００３６】
１．ベースプロファイル
ベースプロファイルは主にループトップ（ｒｏｏｆ−ｔｏｐ）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動してもよいが、比較的停止した受信範ちゅうに属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置又は車両用に拡張されてもよいが、このような使用用途はベースプロファイル受信機動作では期待されない。
【００３７】
受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは、既存放送システム（例えば、ＡＴＳＣ  Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用する、バッテリーで駆動するハンドヘルド装置におけるよりは重要でない。ベースプロファイルに対する重要システムパラメータが、下記の表１に記載されている。
【表１】
0006291081.tif 000002
【００３８】
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は歩行者又は車両の速度で移動することができる。受信機複雑度も消費電力も、共にハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ未満となるように設定されてもよい。
【００３９】
低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが下記の表２に記載されている。
【表２】
0006291081.tif 000003
【００４０】
３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルはＭＩＭＯ送信及び受信を用いることを要求し、ＵＨＤＴＶサービスはターゲット用途であり、そのために、当該プロファイルが特別に設計される。向上した能力は、与えられた帯域幅でサービス数の増加、例えば、複数のＳＤＴＶ又はＨＤＴＶサービスを許容するために用いることができる。
【００４１】
アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０乃至３０ｄＢである。ＭＩＭＯ伝送は、初期には既存の楕円分極伝送装備を使用し、将来には全出力交差分極伝送へと拡張されてもよい。アドバンスドプロファイルに対する重要システムパラメータが下記の表３に記載されている。
【表３】
0006291081.tif 000004
【００４２】
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いられてもよい。すなわち、ベースプロファイルを、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別することができる。そして、該当の３つのプロファイルは設計者の意図によって変更されてもよい。
【００４３】
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。
【００４４】
補助ストリーム：ヒューチャエクステンション（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ、将来拡張）又は放送会社やネットワーク運営者によって要求されることによって用いられ得る、まだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
【００４５】
ベースデータパイプ（ｂａｓｅ  ｄａｔａ  ｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ
【００４６】
ベースバンドフレーム（又は、ＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
【００４７】
セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値
【００４８】
コーディングブロック（ｃｏｄｅｄ  ｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコードされたブロック又はＰＬＳ２データのＬＤＰＣエンコードされたブロックの一つ
【００４９】
データパイプ（ｄａｔａ  ｐｉｐｅ）：１つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連したメタデータを伝達する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）におけるロジカルチャネル
【００５０】
データパイプユニット（ＤＰＵ，ｄａｔａ  ｐｉｐｅ  ｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット
【００５１】
データシンボル（ｄａｔａ  ｓｙｍｂｏｌ）：プリアンブルシンボル以外のフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）
【００５２】
ＤＰ＿ＩＤ：当該８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内でデータパイプを唯一に識別する。
【００５３】
ダミーセル（ｄｕｍｍｙ  ｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために用いられないで残っている容量を満たすために用いられる擬似ランダム値を伝達するセル
【００５４】
ＦＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部
【００５５】
フレーム（ｆｒａｍｅ）：プリアンブルによって始まってフレームエッジシンボルによって終了される物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【００５６】
フレームレピティションユニット（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ；フレーム反復単位）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む同一又は別個のフィジカルプロファイルに属するフレームの集合
【００５７】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ；高速情報チャネル）：サービスと該当のベースデータパイプとのマッピング情報を伝達するフレームにおいてロジカルチャネル
【００５８】
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコードされたビットの集合
【００５９】
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同一である特定モードに用いられる名目上のＦＦＴサイズ
【００６０】
フレームシグナリングシンボル（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、ガードインターバル（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定組合せにおいてフレームの開始で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【００６１】
フレームエッジシンボル（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）：ＦＦＴサイズ、ガードインターバル、及びスキャッタパイロットパターンの特定組合せにおいてフレームの終わりで用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【００６２】
フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームで同じフィジカルプロファイルタイプを有する全フレームの集合
【００６３】
ヒューチャエクステンションフレーム（ｆｕｔｕｒｅ  ｅｘｔｅｎｔｉｏｎ  ｆｒａｍｅ；将来拡張フレーム）：プリアンブルによって始まる、将来拡張に用いられ得るスーパーフレームにおける物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【００６４】
ヒューチャキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである、提案された物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）放送システム
【００６５】
インプットストリーム（ｉｎｐｕｔ  ｓｔｒｅａｍ；入力ストリーム）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
【００６６】
ノーマル（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボル以外のデータシンボル
【００６７】
フィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）：該当する受信機が具現すべき全ての構造のサブセット
【００６８】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
【００６９】
ＰＬＳ１：ＰＬＳ２をデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｌｉｎｇ  ｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合
【００７０】
ＮＯＴＥ：ＰＬＳ１データがフレームグループのデューレーション（ｄｕｒａｔｉｏｎ）において一定である。
【００７１】
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合
【００７２】
ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ；動的）データ：フレームごとにダイナミック（動的）に変化するＰＬＳ２データ
【００７３】
ＰＬＳ２スタティック（ｓｔａｔｉｃ；静的）データ：フレームグループのデューレーションでスタティック（静的）であるＰＬＳ２データ
【００７４】
プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅ  ｓｉｇｎａｌｉｎｇ  ｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ
【００７５】
プリアンブルシンボル（ｐｒｅａｍｂｌｅ  ｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達し、フレームの先頭に位置する固定された長さのパイロットシンボル
【００７６】
ＮＯＴＥ：プリアンブルシンボルがシステム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に用いられる。
【００７７】
将来使用（ｆｕｔｕｒｅ  ｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書で定義されないが、将来に定義されてもよい。
【００７８】
スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合
【００７９】
タイムインターリービングブロック（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｂｌｏｃｋ；ＴＩ  ｂｌｏｃｋ）：タイムインターリーバメモリの一つの用途に該当する、タイムインターリービングが実行されるセルの集合
【００８０】
タイムインターリービンググループ（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｇｒｏｕｐ；ＴＩ  ｇｒｏｕｐ）：整数、ダイナミック（動的）に変化するＸＦＥＣＢＬＯＣＫの数からなる、特定データパイプに対するダイナミック（動的）容量割り当てが実行される単位
【００８１】
ＮＯＴＥ：タイムインターリービンググループが一つのフレームに直接マップされたり、複数のフレームにマップされてもよい。タイムインターリービンググループは一つ以上のタイムインターリービングブロックを含むことができる。
【００８２】
タイプ１データパイプ（Ｔｙｐｅ１ＤＰ）：全データパイプがフレームにＴＤＭ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマップされるフレームのデータパイプ
【００８３】
タイプ２データパイプ（Ｔｙｐｅ２ＤＰ）：全データパイプがフレームにＦＤＭ方式でマップされるフレームのデータパイプ
【００８４】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ  ＦＥＣＢＬＯＣＫの全ビットを伝達するＮｃｅｌｌｓセルの集合
【００８５】
図１は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【００８６】
本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Ｉｎｐｕｔ  Ｆｏｒｍａｔ  ｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）ジェネレーションブロック（ＯＦＤＭ  ｇｅｎｅｒａｔｉｏｎ  ｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【００８７】
ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳは、主要入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。それらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する該当の帯域幅のスケジューリング及び割り当てを制御する。１つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリーム入力が同時に許容される。
【００８８】
インプットフォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される１つ又は複数のデータパイプにデマルチプレクスすることができる。データパイプは、堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に影響を及ぼす。１つ又は複数のサービス又はサービスコンポーネントが一つのデータパイプによって伝達されてもよい。インプットフォーマットブロック１０００の詳細な動作は後述する。
【００８９】
データパイプは、１つ又は複数のサービス又はサービスコンポーネントを伝達できるサービスデータ又は関連メタデータを伝達する物理層におけるロジカルチャネルである。
【００９０】
また、データパイプユニットは、一つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【００９１】
インプットフォーマットブロック１０００で、パリティ（ｐａｒｉｔｙ）データは誤り訂正のために追加され、エンコードされたビットストリームは複素数値コンステレーションシンボルにマップされる。当該シンボルは該当のデータパイプに用いられる特定インターリービング深さにわたってインターリーブされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。ＢＩＣＭブロック１０１０の詳細な動作は後述する。
【００９２】
フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマップすることができる。マッピング後、周波数領域ダイバーシチのために、特に、周波数選択的フェージングチャネルを防止するために周波数インターリービングが用いられる。フレームビルディングブロック１０２０の詳細な動作は後述する。
【００９３】
プリアンブルを各フレームの先頭に挿入した後、ＯＦＤＭジェネレーションブロック１０３０は、サイクリックプレフィクス（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）をガードインターバルとして有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシチのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、当該提案は様々なＦＦＴサイズ、ガードインターバルの長さ、該当のパイロットパターンの集合を提供する。ＯＦＤＭジェネレーションブロック１０３０の詳細な動作は後述する。
【００９４】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の詳細な動作は後述する。
【００９５】
図２、図３、図４は、本発明の実施例に係るインプットフォーマットブロック１０００を示す。各図について説明する。
【００９６】
図２は、本発明の一実施例に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（ｓｉｎｇｌｅ  ｉｎｐｕｔ  ｓｔｒｅａｍ）であるときのインプットフォーマットブロックを示す。
【００９７】
図２に示すインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
【００９８】
物理層への入力は、１つ又は複数のデータストリームで構成される。それぞれのデータストリームは一つのデータパイプによって伝達される。モードアダプテーション（ｍｏｄｅ  ａｄａｐｔａｉｏｎ；モード適応）モジュールは、入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄ  ｆｒａｍｅ）のデータフィールドにスライスする。当該システムは３種類の入力データストリーム、すなわち、ＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（ｇｅｎｅｒｉｃ  ｓｔｒｅａｍ）を支援する。ＭＰＥＧ２−ＴＳは、最初のバイトが同期バイト（０ｘ４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームは、ＩＰパケットヘッダー内でシグナルされる可変長ＩＰデータグラムパケットで構成される。当該システムは、ＩＰストリームに対してＩＰｖ４、ＩＰｖ６の両方を支援する。ＧＳは、カプセル化パケットヘッダー内でシグナルされる可変長のパケット又は一定の長さのパケットで構成されてもよい。
【００９９】
（ａ）は、信号データパイプに対するモードアダプテーション（モード適応）ブロック２０００、及びストリームアダプテーション（ｓｔｒｅａｍ  ａｄａｐｔａｔｉｏｎ；ストリーム適応）２０１０を示し、（ｂ）は、ＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０、及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。
【０１００】
入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ、及びＢＢフレームヘッダー挿入ブロックで構成される。
【０１０１】
ＣＲＣエンコーダは、ユーザパケット（ｕｓｅｒ  ｐａｃｋｅｔ；ＵＰ）レベルでの誤り検出のための３種類のＣＲＣエンコーディング、すなわち、ＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトは、ＵＰ後に付加される。ＣＲＣ−８はＴＳストリームに用いられ、ＣＲＣ−３２はＩＰストリームに用いられる。ＧＳストリームがＣＲＣエンコーディングを提供しない場合には、提案されたＣＲＣエンコーディングが適用されなければならない。
【０１０２】
ＢＢフレームスライサは、入力を内部ロジカルビットフォーマットにマップする。最初の受信ビットはＭＳＢと定義する。ＢＢフレームスライサは、可用データフィールド容量と同数の入力ビットを割り当てる。ＢＢＦペイロードと同数の入力ビットを割り当てるために、ＵＰストリームがＢＢＦのデータフィールドに見合うようにスライスされる。
【０１０３】
ＢＢフレームヘッダー挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダーを、ＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダーだけでなく、ＢＢＦは、２バイトＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。
【０１０４】
ストリームアダプテーション（ストリーム適応）２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（ストリーム適応）に対する入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。
【０１０５】
ＢＢスクランブラは、エネルギー分散のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同期化される。スクランブリングシーケンスはフィードバックシフトレジスターによって生成される。
【０１０６】
ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機でフィジカルレイヤ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）データパイプに接続できる手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。
【０１０７】
ＰＬＳ１データは、ＰＬＳ２データをデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームでＦＳＳで伝達されるＰＬＳデータの一番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデューレーションにおいて一定である。
【０１０８】
ＰＬＳ２データは、データパイプ及びシステムに関するさらに詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコードする上で十分な情報を提供するパラメータを含む。ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータでさらに構成される。ＰＬＳ２スタティック（静的）データは、フレームグループのデューレーションでスタティック（静的）であるＰＬＳ２データであり、ＰＬＳ２ダイナミック（動的）データは、フレームごとにダイナミック（動的）に変化するＰＬＳ２データである。
【０１０９】
ＰＬＳデータに関する詳細な内容は後述する。
【０１１０】
ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。
【０１１１】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１１２】
図３は、本発明の他の実施例に係るインプットフォーマットブロックを示す。
【０１１３】
図３に示すインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
【０１１４】
図３は、入力信号がマルチインプットストリーム（ｍｕｌｔｉ  ｉｎｐｕｔ  ｓｔｒｅａｍ；複数の入力ストリーム）に該当する場合、インプットフォーマットブロックのモードアダプテーション（モード適応）ブロックを示す。
【０１１５】
マルチインプットストリーム（複数の入力ストリーム）を処理するためのインプットフォーマットブロックのモードアダプテーション（モード適応）ブロックは、複数の入力ストリームを独立して処理することができる。
【０１１６】
図３を参照すると、マルチインプットストリーム（複数の入力ストリーム）をそれぞれ処理するためのモードアダプテーション（モード適応）ブロックは、インプットストリームスプリッタ（ｉｎｐｕｔ  ｓｔｒｅａｍ  ｓｐｌｉｔｔｅｒ）３０００、インプットストリームシンクロナイザ（ｉｎｐｕｔ  ｓｔｒｅａｍ  ｓｙｎｃｈｒｏｎｉｚｅｒ）３０１０、コンペンセーティングディレイ（ｃｏｍｐｅｎｓａｔｉｎｇ  ｄｅｌａｙ；補償遅延）ブロック３０２０、ヌルパケット削除ブロック（ｎｕｌｌ  ｐａｃｋｅｔ  ｄｅｌｅｔｉｏｎ  ｂｌｏｃｋ）３０３０、ヘッダーコンプレションブロック（ｈｅａｄｅｒ  ｃｏｍｐｒｅｓｓｉｏｎ  ｂｌｏｃｋ）３０４０、ＣＲＣエンコーダ（ＣＲＣ  ｅｎｃｏｄｅｒ）３０５０、ＢＢフレームスライサ（ＢＢ  ｆｒａｍｅ  ｓｌｉｃｅｒ）３０６０、及びＢＢヘッダー挿入ブロック（ＢＢ  ｈｅａｄｅｒ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）３０７０を含むことができる。モードアダプテーション（モード適応）ブロックの各ブロックについて説明する。
【０１１７】
ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ、及びＢＢヘッダー挿入ブロックの動作に該当するので、その説明は省略する。
【０１１８】
インプットストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。
【０１１９】
インプットストリームシンクロナイザ３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、いかなる入力データフォーマットに対しても、ＣＢＲ（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ）及び一定の終端間伝送（ｅｎｄ−ｔｏ−ｅｎｄ  ｔｒａｎｓｍｉｓｓｉｏｎ）遅延を保障するに適した手段を提供することができる。ＩＳＳＹは、ＴＳを伝達する複数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する複数のデータパイプに選択的に用いられる。
【０１２０】
コンペンセーティングディレイ（補償遅延）ブロック３０２０は、受信機でさらにメモリを必要とせずにＴＳパケット再結合メカニズムを許容するために、ＩＳＳＹ情報の挿入に続く分割されたＴＳパケットストリームを遅延させることができる。
【０１２１】
ヌルパケット削除ブロック３０３０は、ＴＳインプットストリームの場合にのみ用いられる。一部のＴＳインプットストリーム又は分割されたＴＳストリームは、ＶＢＲ（ｖａｒｉａｂｌｅ  ｂｉｔ−ｒａｔｅ）サービスをＣＢＲ  ＴＳストリームに収容するために、存在する多数のヌルパケットを有することができる。この場合、不要な伝送オーバーヘッドを避けるために、ヌルパケットは確認されて伝送されなくてもよい。受信機で、除去されたヌルパケットは、伝送に挿入されたＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ−ｐａｃｋｅｔ；削除されたヌルパケット）カウンタを参照して元の正確な場所に再挿入可能であるため、ＣＢＲが保障され、タイムスタンプ（ＰＣＲ）更新が不要になる。
【０１２２】
ヘッダーコンプレションブロック３０４０は、ＴＳ又はＩＰインプットストリームに対する伝送効率を増加させるために、パケットヘッダーコンプレションを提供することができる。受信機は、ヘッダーの特定部分に対する先験的な（ａ  ｐｒｉｏｒｉ）情報を有することができるため、この知られた情報（ｋｎｏｗｎ  ｉｎｆｏｒｍａｔｉｏｎ）は送信機で削除されてもよい。
【０１２３】
ＴＳに対して、受信機は同期バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが一つのＰＩＤだけを有するコンデンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣエンハンスメントレイヤ、ＭＶＣベースビュー、又はＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダーコンプレションがＴＳに（選択的に）適用されてもよい。ＴＳパケットヘッダーコンプレションは、インプットストリームがＩＰストリームである場合に選択的に用いられる。上記のブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１２４】
図４は本発明の一実施例に係るＢＩＣＭブロックを示す。
【０１２５】
図４に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭ ブロック１０１０の一実施例に該当する。
【０１２６】
前述したように、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０１２７】
ＱｏＳが本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータは別個の方式で処理されなければならない。したがって、本発明の一実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することによって、各データパイプを独立して処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプで伝送される各サービス又はサービスコンポーネントに対するＱｏＳを調節することができる。
【０１２８】
（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。
【０１２９】
ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロック及びアドバンスドプロファイルのＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０１３０】
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスドプロファイルに対するＢＩＣＭブロックの各処理ブロックについて説明する。
【０１３１】
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
【０１３２】
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作については後述する。
【０１３３】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながら、データＦＥＣエンコーダ５０１０の出力をインターリーブし、ＬＤＰＣコード及び変調方式の組合せによって最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
【０１３４】
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からの各セルワードを変調したり、アドバンスドプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調し、パワーの正規化されたコンステレーションポイントｅlを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱが任意の形態を有するのに対し、ＱＡＭ−１６及びＮＵＱは正方形を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転されると、回転されたコンステレーションは元のものと正確に重なる。回転対称特性によって失敗及び虚数コンポーネントの容量及び平均パワーが互いに同一となる。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ  ｒａｔｅ）に対して特別に定義され、用いられる特定の一つは、ＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによってシグナルされる。
【０１３５】
タイムインターリーバ５０５０はデータパイプレベルで動作することができる。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０１３６】
アドバンスドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。
【０１３７】
ただし、処理ブロック５０００−１は、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で処理ブロック５０００と区別される。
【０１３８】
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
【０１３９】
セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。セルワードデマルチプレクサ５０１０−１の具体的な動作に関しては後述する。
【０１４０】
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号の送信のために最適化されている。ＭＩＭＯ技術は容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に放送に対して、別個の信号伝搬特性による両アンテナ間の受信信号パワー差又はチャネルの強いＬＯＳコンポーネントは、ＭＩＭＯから容量利得を得ることを困難にさせる。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの位相ランダム化及び回転ベースプリコーディングを用いてこの問題を克服する。
【０１４１】
ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２ｘ２ＭＩＭＯシステムのために意図される。２つのＭＩＭＯエンコーディングモードは、本提案であるＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｆｕｌｌ−ｄｉｖｅｒｓｉｔｙ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）で定義される。ＦＲ−ＳＭエンコーディングは、受信機側での比較的小さい複雑度増加から容量増加を提供するが、ＦＲＦＤ−ＳＭエンコーディングは、受信機側での大きい複雑度増加から容量増加及び追加的なダイバーシチ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。
【０１４２】
ＭＩＭＯ処理はアドバンスドプロファイルフレームに要求されるが、これは、アドバンスドプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダによって処理されるということを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ；対）であるＮＵＱ（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（対）（ｇ1,i及びｇ2,i）は、それぞれの送信アンテナの同一キャリアｋ及びＯＦＤＭシンボルｌによって送信される。
【０１４３】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１４４】
図５は、本発明の他の実施例に係るＢＩＣＭブロックを示す。
【０１４５】
図５に示すＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０１４６】
図５は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。ＥＡＣ及びＦＩＣに関する詳細な説明は後述する。
【０１４７】
図５を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ  ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。
【０１４８】
また、ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて説明する。
【０１４９】
ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。
【０１５０】
スクランブラは、ＢＣＨエンコーディング及びショートニング（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。
【０１５１】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いて、スクランブルされたＰＬＳ１／２データに外部エンコーディングを行い、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディングの前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）することができる。
【０１５２】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコードすることができる。完全なコーディングブロックを生成するために、Ｃldpc及びパリティビットＰldpcは、それぞれのゼロが挿入されたＰＬＳ情報ブロックＩldpcから組織的にエンコードされ、その後に付加される。
【数１】
0006291081.tif 000005
【０１５３】
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４のとおりである。
【表４】
0006291081.tif 000006
【０１５４】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０１５５】
ショートニングがＰＬＳ１データ保護に適用されると、一部のＬＤＰＣパリティビットはＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャされる。それらのパンクチャされたビットは伝送されない。
【０１５６】
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブすることができる。
【０１５７】
コンステレーションマッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマップすることができる。
【０１５８】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１５９】
図６は、本発明の一実施例に係るフレームビルディングブロック（ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）を示す。
【０１６０】
図６に示すフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施例に該当する。
【０１６１】
図６を参照すると、フレームビルディングブロックは、ディレイコンペセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ；遅延補償）ブロック７０００、セルマッパー（ｃｅｌｌ  ｍａｐｐｅｒ）７０１０、及びフリークエンシインターリーバ（ｆｒｅｑｕｅｎｃｙ  ｉｎｔｅｒｌｅａｖｅｒ）７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。
【０１６２】
ディレイコンペセーション（遅延補償）ブロック７０００は、データパイプと該当するＰＬＳデータとの間のタイミングを調節し、送信機側でデータパイプと該当するＰＬＳデータ間の同時性（ｃｏ−ｔｉｍｅ）を保障することができる。インプットフォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことによって、ＰＬＳデータはデータパイプだけ遅延される。ＢＩＣＭブロックの遅延は主にタイムインターリーバ５０５０に起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次のタイムインターリービンググループの情報を、シグナルされるデータパイプよりも１フレーム先に伝達されるようにすることができる。ディレイコンペセーション（遅延補償）ブロックは、それに応じてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。
【０１６３】
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップすることができる。セルマッパー７０１０の基本機能は、それぞれのデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマップすることである。（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集され、データパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成されたダイナミックインフォメーション（ｄｙｎａｍｉｃ  ｉｎｆｏｒｍａｔｉｏｎ；動的情報）によって動作する。フレームに関する詳細な内容は後述する。
【０１６４】
フリークエンシインターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリーブして周波数ダイバーシチを提供することができる。また、フリークエンシインターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（対）で動作することができる。
【０１６５】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０１６６】
図７は、本発明の一実施例に係るＯＦＤＭジェネレーションブロックを示す。
【０１６７】
図７に示すＯＦＤＭジェネレーションブロックは、図１を参照して説明したＯＦＤＭジェネレーションブロック１０３０の一実施例に該当する。
【０１６８】
ＯＦＤＭジェネレーションブロックは、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは、順次にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
【０１６９】
図７を参照すると、ＯＦＤＭジェネレーションブロックは、パイロット及びリザーブドトーン挿入ブロック（ｐｉｌｏｔ  ａｎｄ  ｒｅｖｓｅｒｖｅｄ  ｔｏｎｅ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）８０００、２Ｄ−ｅＳＦＮ（ｓｉｎｇｌｅ  ｆｒｅｑｕｅｎｃｙ  ｎｅｔｗｏｒｋ）エンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅ  ｆａｓｔ  Ｆｏｕｒｉｅｒ  ｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、ガードインターバル挿入ブロック（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）８０４０、プリアンブル挿入ブロック（ｐｒｅａｍｂｌｅ  ｉｎｓｅｒｔｉｏｎ  ｂｌｏｃｋ）８０５０、その他システム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。
【０１７０】
システム挿入ブロック８０６０は、放送サービスを提供する２つ以上の別個の放送送信／受信システムのデータが同一のＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクスすることができる。ここで、２つ以上の別個の放送送信／受信システムとは、別個の放送サービスを提供するシステムのことをいう。別個の放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。
【０１７１】
図８は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
【０１７２】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応し得る。
【０１７３】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ＆  ｄｅｍｏｄｕｌａｔｉｏｎ  ｍｏｄｕｌｅ）９０００、フレームパーシングモジュール（ｆｒａｍｅ  ｐａｒｓｉｎｇ  ｍｏｄｕｌｅ）９０１０、デマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ  ＆  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０２０、出力プロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）９０３０、及びシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇ  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
【０１７４】
同期及び復調モジュール９０００は、ｍ個の受信アンテナを通じて入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆手順に該当する復調を実行することができる。
【０１７５】
フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すると、フレームパーシングモジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるべき信号及びデータの位置がシグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって取得され、放送信号送信装置によって生成されたスケジューリング情報を復元することができる。
【０１７６】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によって、それらのビット領域データをデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを通じて伝送チャネルで発生した誤りを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。
【０１７７】
出力プロセッサ９０３０は、伝送効率を向上させるために、放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆手順を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータで必要な制御情報を取得することができる。出力プロセッサ９０３０の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及びＧＳであってもよい。
【０１７８】
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０１７９】
図９は、本発明の一実施例に係るフレーム構造を示す。
【０１８０】
図９は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ；フレーム反復単位）を示す。（ａ）は、本発明の一実施例に係るスーパーフレームを示し、（ｂ）は、本発明の一実施例に係るＦＲＵを示し、（ｃ）は、ＦＲＵにおける様々なフィジカルプロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）のフレームを示し、（ｄ）は、フレームの構造を示す。
【０１８１】
スーパーフレームは８個のＦＲＵを含むことができる。ＦＲＵは、フレームのＴＤＭに対する基本マルチプレクシング単位であり、スーパーフレームで８回反復される。
【０１８２】
ＦＲＵにおいて各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスドプロファイル）のいずれか一つ又はＦＥＦに属する。ＦＲＵにおいてフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、ＦＲＵにおいて０回乃至４回の回数を有することができる（例えば、ベース、ベース、ハンドヘルド、アドバンスド）。フィジカルプロファイル定義は、必要時には、プリアンブルにおけるＰＨＹ＿ＰＲＯＦＩＬＥのリザーブド値を用いて拡張されてもよい。
【０１８３】
ＦＥＦ部分は、含まれるなら、ＦＲＵの終わりに挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームにおいて８である。ＦＥＦ部分が互いに隣接することは推奨されない。
【０１８４】
一つのフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、ノーマルデータシンボル、ＦＥＳを含む。
【０１８５】
プリアンブルは、高速ヒューチャキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルに関する詳細な内容は後述する。
【０１８６】
ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、これによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルに比べてより高密度のパイロットパターンを有する。ＦＥＳはＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳ直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しで、ＦＥＳ内における周波数だけのインターポレーション（補間）及び時間的補間（ｔｅｍｐｏｒａｌ  ｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。
【０１８７】
図１０は、本発明の一実施例に係るフレームのシグナリング階層構造（ｓｉｇｎａｌｉｎｇ  ｈｉｅｒａｒｃｈｙ  ｓｔｒｕｃｔｕｒｅ）を示す。
【０１８８】
図１０は、シグナリング階層構造を示すが、これは、３個の主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーディング可能にさせる。ＰＬＳ２は毎フレームごとに伝達され、２つの主要部分であるＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データのスタティック（静的）及びダイナミック（動的）部分には必要時にパディングが続く。
【０１８９】
図１１は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。
【０１９０】
プリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳細な内容は、次のとおりである。
【０１９１】
ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、現フレームのフィジカルプロファイルタイプを示す。各フィジカルプロファイルタイプのマッピングは、下記の表５のように与えられる。
【表５】
0006291081.tif 000007
【０１９２】
ＦＦＴ＿ＳＩＺＥ：当該２ビットフィールドは、下記の表６で説明したとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。
【表６】
0006291081.tif 000008
【０１９３】
ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表７で説明したとおり、現スーパーフレームにおけるガードインターバルの一部（ｆｒａｃｔｉｏｎ）値を示す。
【表７】
0006291081.tif 000009
【０１９４】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームで提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームで提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドはスーパーフレーム内でダイナミック（動的）に転換されてもよい。
【０１９５】
ＰＩＬＯＴ＿ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードなのか又は固定モードなのかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。
【０１９６】
ＰＡＰＲ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅ  ｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。
【０１９７】
ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：当該３ビットフィールドは、現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全プリアンブルにおける当該フィールドにおいて、現スーパーフレームで伝達される全プロファイルタイプが識別される。当該３ビットフィールドは、下記の表８に示すように、それぞれのプロファイルに対して別々に定義される。
【表８】
0006291081.tif 000010
【０１９８】
ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０１９９】
図１２は、本発明の一実施例に係るＰＬＳ１データを示す。
【０２００】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含む基本伝送パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全デューレーションで変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は次のとおりである。
【０２０１】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：当該２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧ以外のプリアンブルシグナリングデータのコピーである。
【０２０２】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：当該２ビットフィールドは、ＦＲＵ当たりのフレーム数を示す。
【０２０３】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表９に示すようにシグナルされる。
【表９】
0006291081.tif 000011
【０２０４】
ＮＵＭ＿ＦＳＳ：当該２ビットフィールドは、現フレームでＦＳＳの数を示す。
【０２０５】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０２０６】
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は、互換が不可能な変化を示す。デフォルト値は００００である。当該標準で述べているバージョンに対して、値が００００に設定される。
【０２０７】
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は、互換が可能である。
【０２０８】
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワークで地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジは、ヒューチャキャストＵＴＢシステム当たりに用いられる周波数の数によって一つ以上の周波数で構成されてもよい。ＣＥＬＬ＿ＩＤの値が知られないか又は特定されないと、当該フィールドは０に設定される。
【０２０９】
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。
【０２１０】
ＳＹＳＴＥＭ＿ＩＤ：該当１６ビットフィールドは、ＡＴＳＣネットワーク内でヒューチャキャストＵＴＢシステムを唯一に識別する。ヒューチャキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。ヒューチャキャストＵＴＢシステムは、存在するなら、ＦＥＦ及び一つ以上のフィジカルプロファイルを伝達する。同じヒューチャキャストＵＴＢシステムは、別個の入力ストリームを伝達し、別個の地理的領域で別個のＲＦを用いることができ、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは一つの場所で制御され、ヒューチャキャストＵＴＢシステム内で全ての伝送に対して同一である。一つ以上のヒューチャキャストＵＴＢシステムはいずれも同一のフィジカル構造及び構成を有するという同一のＳＹＳＴＥＭ＿ＩＤ意味を有することができる。
【０２１１】
次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦを含む）がシグナルされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４よりも小さいと、用いられないフィールドはゼロで埋められる。
【０２１２】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレーム（ｉはループ（ｌｏｏｐ）インデックス）のフィジカルプロファイルタイプを示す。当該フィールドは表８に示すものと同じシグナリングフォーマットを用いる。
【０２１３】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：当該２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを用いると、フレームデューレーションの正確な値が得られる。
【０２１４】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームのガードインターバルの一部の値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７に従ってシグナルされる。
【０２１５】
ＲＥＳＥＲＶＥＤ：当該４ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２１６】
次のフィールドは、ＰＬＳ２データをデコードするためのパラメータを提供する。
【０２１７】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表１０に従ってシグナルされる。ＬＤＰＣコードに関する詳細な内容は後述する。
【表１０】
0006291081.tif 000012
【０２１８】
ＰＬＳ２＿ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
【表１１】
0006291081.tif 000013
【０２１９】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_partial_blockを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２２０】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２２１】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２２２】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０２２３】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、現フレームグループの毎フレームごとに伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_partial_blockを示す。反復が用いられない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２２４】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられるＦＥＣタイプを示す。ＦＥＣタイプは表１０に従ってシグナルされる。
【０２２５】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：当該３ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられる変調タイプを示す。変調タイプは表１１に従ってシグナルされる。
【０２２６】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが次のフレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０２２７】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、次のフレームグループの毎フレームごとに伝達されるＰＬＳ２に対する全コーディングブロックのサイズ（ＱＡＭセルの数に特定される。）であるＣtotal_full_blockを示す。次のフレームグループで反復が用いられない場合、当該フィールドの値は０と同一である。当該値は現フレームグループの全デューレーションにおいて一定である。
【０２２８】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０２２９】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０２３０】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。下記の表１２は当該フィールドの値を提供する。当該フィールドの値が００に設定されると、現フレームグループで追加パリティがＰＬＳ２に対して用いられない。
【表１２】
0006291081.tif 000014
【０２３１】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２３２】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全デューレーションにおいて一定である。表１２は、当該フィールドの値を定義する。
【０２３３】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２３４】
ＲＥＳＥＲＶＥＤ：該当３２ビットフィールドは将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２３５】
ＣＲＣ＿３２：全ＰＬＳ１シグナリングに適用される３２ビット誤り検出コード
【０２３６】
図１３は、本発明の一実施例に係るＰＬＳ２データを示す。
【０２３７】
図１３は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
【０２３８】
ＰＬＳ２−ＳＴＡＴデータのフィールドに対して次に具体的に説明する。
【０２３９】
ＦＩＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＦＩＣが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームで提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２４０】
ＡＵＸ＿ＦＬＡＧ：当該１ビットフィールドは、補助ストリームが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、補助ストリームは現フレームで提供される。当該フィールドの値が０に設定されると、補助フレームは現フレームで伝達されない。当該値は、現フレームグループの全デューレーションにおいて一定である。
【０２４１】
ＮＵＭ＿ＤＰ：該当６ビットフィールドは、現フレーム内で伝達されるデータパイプの数を示す。当該フィールドの値は１〜６４であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
【０２４２】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でＤＰを唯一に識別する。
【０２４３】
ＤＰ＿ＴＹＰＥ：当該３ビットフィールドはデータパイプのタイプを示す。これは、下記の表１３に従ってシグナルされる。
【表１３】
0006291081.tif 000015
【０２４４】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：当該８ビットフィールドは、現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同じＤＰ＿ＧＲＯＵＰ＿ＩＤを有する特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために用いられてもよい。
【０２４５】
ＢＡＳＥ＿ＤＰ＿ＩＤ：当該６ビットフィールドは、管理階層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤで示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであってもよく、サービスシグナリングデータだけを伝達する専用データパイプであってもよい。
【０２４６】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表１４に従ってシグナルされる。
【表１４】
0006291081.tif 000016
【０２４７】
ＤＰ＿ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅ  ｒａｔｅ）を示す。コードレート（ｃｏｄｅ  ｒａｔｅ）は、下記の表１５に従ってシグナルされる。
【表１５】
0006291081.tif 000017
【０２４８】
ＤＰ＿ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は、下記の表１６に従ってシグナルされる。
【表１６】
0006291081.tif 000018
【０２４９】
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：当該１ビットフィールドは、ＳＳＤモードが関連したデータパイプで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＳＳＤが用いられる。当該フィールドの値が０に設定されると、ＳＳＤは用いられない。
【０２５０】
次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ表される。
【０２５１】
ＤＰ＿ＭＩＭＯ：当該３ビットフィールドは、どのタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、下記の表１７に従ってシグナルされる。
【表１７】
0006291081.tif 000019
【０２５２】
ＤＰ＿ＴＩ＿ＴＹＰＥ：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、一つのタイムインターリービンググループが一つのフレームに該当し、一つ以上のタイムインターリービングブロックを含むことを示す。１の値は、一つのタイムインターリービンググループが一つよりも多いフレームで伝達され、一つのタイムインターリービングブロックのみを含むことを示す。
【０２５３】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：当該２ビットフィールド（許容された値は、１、２、４、８のみである。）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値によって決定される。
【０２５４】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマップされるフレームの数であるＰIを示し、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックが存在する（ＮTI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１８に定義される。
【０２５５】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されると、当該フィールドは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数ＮTIを示し、フレーム当たりに一つのタイムインターリービンググループが存在する（ＰI＝１）。当該２ビットフィールドで許容されるＰIの値は、下記の表１８に定義される。
【表１８】
0006291081.tif 000020
【０２５６】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩJUMP）を示し、許容された値は１，２，４，８（該当する２ビットフィールドはそれぞれ００，０１，１０，１１）である。フレームグループの全フレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１，５，９，１３などのフレームで現れると、当該フィールドの値は４に設定される。全フレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。
【０２５７】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：当該１ビットフィールドは、タイムインターリーバ５０５０の可用性を決定する。データパイプに対してタイムインターリービングが用いられないと、当該フィールド値は１に設定される。一方、タイムインターリービングが用いられると、当該フィールド値は０に設定される。
【０２５８】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：当該５ビットフィールドは、現データパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は、０〜３１である。
【０２５９】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：当該１０ビットフィールドは、当該データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。当該フィールドの値はＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同じ範囲を有する。
【０２６０】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、下記の表１９に従ってシグナルされる。
【表１９】
0006291081.tif 000021
【０２６１】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは、下記の表２０に従ってシグナルされる。
【表２０】
0006291081.tif 000022
【０２６２】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、下記の表２１に従ってシグナルされる。
【表２１】
0006291081.tif 000023
【０２６３】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングがインプットフォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表２２に従ってシグナルされる。
【表２２】
0006291081.tif 000024
【０２６４】
ＤＮＰ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、下記の表２３に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
【表２３】
0006291081.tif 000025
【０２６５】
ＩＳＳＹ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、下記の表２４に従ってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
【表２４】
0006291081.tif 000026
【０２６６】
ＨＣ＿ＭＯＤＥ＿ＴＳ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、下記の表２５に従ってシグナルされる。
【表２５】
0006291081.tif 000027
【０２６７】
ＨＣ＿ＭＯＤＥ＿ＩＰ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（‘０１’）に設定される場合に、ＩＰヘッダーコンプレションモードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、下記の表２６に従ってシグナルされる。
【表２６】
0006291081.tif 000028
【０２６８】
ＰＩＤ：当該１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１又は１０に設定される場合に、ＴＳヘッダー圧縮のためのＰＩＤ数を示す。
【０２６９】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２７０】
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０２７１】
ＦＩＣ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、ＦＩＣのバージョンナンバーを示す。
【０２７２】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１３ビットフィールドは、ＦＩＣの長さをバイト単位で示す。
【０２７３】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２７４】
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０２７５】
ＮＵＭ＿ＡＵＸ：当該４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが用いられないことを示す。
【０２７６】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：当該８ビットフィールドは将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２７７】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：当該４ビットは、現補助ストリームのタイプを示すための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２７８】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：該当２８ビットフィールドは、補助ストリームをシグナルするための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２７９】
図１４は、本発明の他の実施例に係るＰＬＳ２データを示す。
【０２８０】
図１４は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は一つのフレームグループのデューレーションで変化してもよいが、フィールドのサイズは一定である。
【０２８１】
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は、次のとおりである。
【０２８２】
ＦＲＡＭＥ＿ＩＮＤＥＸ：当該５ビットフィールドは、スーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
【０２８３】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、１の値は、次のスーパーフレームに変化があることを示す。
【０２８４】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値で示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、０００１の値は、次のスーパーフレームに変化があるということを示す。
【０２８５】
ＲＥＳＥＲＶＥＤ：当該１６ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２８６】
次のフィールドは、現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰにおけるループ（ｌｏｏｐ）に現れる。
【０２８７】
ＤＰ＿ＩＤ：当該６ビットフィールドは、フィジカルプロファイル内でデータパイプを唯一に示す。
【０２８８】
ＤＰ＿ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初の開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、下記の表２７に示すように、フィジカルプロファイル及びＦＦＴサイズによって別個の長さを有する。
【表２７】
0006291081.tif 000029
【０２８９】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：当該１０ビットフィールドは、現データパイプに対する現タイムインターリービンググループでＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は、０〜１０２３である。
【０２９０】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。
【０２９１】
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
【０２９２】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームでＥＡＣの存在を示す。該当ビットはプリアンブルでＥＡＣ＿ＦＬＡＧと同じ値である。
【０２９３】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：当該８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。
【０２９４】
ＥＡＣ＿ＦＬＡＧフィールドが１に等しいと、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０に等しいと、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
【０２９５】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１２ビットフィールドは、ＥＡＣの長さをバイトで示す。
【０２９６】
ＥＡＣ＿ＣＯＵＮＴＥＲ：当該１２ビットフィールドは、ＥＡＣが到達するフレーム以前のフレームの数を示す。
【０２９７】
次のフィールドは、ＡＵＸ＿ＦＬＡＧフィールドが１と同一である場合にのみ現れる。
【０２９８】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：当該４８ビットフィールドは、補助ストリームをシグナルするための将来使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）される。当該フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０２９９】
ＣＲＣ＿３２：全ＰＬＳ２に適用される３２ビット誤り検出コード。
【０３００】
図１５は、本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ）構造を示す。
【０３０１】
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームでＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳ１及びＰＬＳ２は、初めには一つ以上のＦＳＳにマップされる。その後、ＥＡＣが存在すると、ＥＡＣセルは直後のＰＬＳフィールドにマップされる。次にＦＩＣが存在すると、ＦＩＣセルがマップされる。データパイプはＰＬＳの次にマップされるか、或いは、ＥＡＣ又はＦＩＣが存在すると、ＥＡＣ又はＦＩＣの後にマップされる。タイプ１データパイプが最初にマップされ、その次にタイプ２データパイプがマップされる。データパイプのタイプの具体的な内容は後述する。一部の場合に、データパイプは、ＥＡＳに対する一部の特殊データ又はサービスシグナリングデータを伝達することができる。補助ストリーム又はストリームは、存在するなら、データパイプの次にマップされ、ここには順にダミーセルが続く。前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順で全て共にマップすると、フレームでセル容量を正確に満たす。
【０３０２】
図１６は、本発明の一実施例に係るＰＬＳマッピングを示す。
【０３０３】
ＰＬＳセルは、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳが占めるセルの数によって、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数ＮFSSは、ＰＬＳ１におけるＮＵＭ＿ＦＳＳでシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳで重大な事案であるため、ＦＳＳは高いパイロット密度を有し、高速同期化及びＦＳＳ内における周波数のみのインターポレーション（補間）を可能にする。
【０３０４】
ＰＬＳセルは、図１６の例に示すように、下向き方式でＦＳＳのアクティブキャリアにマップされる。ＰＬＳ１セルははじめには、最初のＦＳＳの最初のセルからセルインデックスの昇順でマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、マッピングは、最初のＦＳＳの最後のセルインデックスまで下向き方式で続く。必要なＰＬＳセルの全数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは次のＦＳＳに進行され、最初のＦＳＳと全く同じ方式で続けて行われる。
【０３０５】
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、ＥＡＣ及びＦＩＣは、ＰＬＳとノーマルデータパイプとの間に配置される。
【０３０６】
図１７は、本発明の一実施例に係るＥＡＣマッピングを示す。
【０３０７】
ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳ支援は提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。ＥＡＣが存在すると、ＥＡＣは、ＰＬＳ２セルの直後にマップされる。ＰＬＳセルを除けば、ＦＩＣ、データパイプ、補助ストリーム又はダミーセルのいずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手順はＰＬＳと全く同一である。
【０３０８】
ＥＡＣセルは、図１７の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは、少ないシンボルを占めることができる。
【０３０９】
ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＥＡＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、ＥＡＣマッピングは次のシンボルに進行され、ＦＳＳと全く同じ方式で続けて行われる。この場合、ＥＡＣのマッピングがなされる次のシンボルは、ノーマルデータシンボルであり、これは、ＦＳＳに比べてより多いアクティブキャリアを有する。
【０３１０】
ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。ＦＩＣが伝送されないと（ＰＬＳ２フィールドでシグナリングによって）、データパイプがＥＡＣの最後のセルの直後に続く。
【０３１１】
図１８は、本発明の一実施例に係るＦＩＣマッピングを示す。
【０３１２】
（ａ）は、ＥＡＣ無しのＦＩＣセルのマッピングの例を示し、（ｂ）は、ＥＡＣと共にＦＩＣセルのマッピングの例を示す。
【０３１３】
ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にするために層間情報（ｃｒｏｓｓ−ｌａｙｅｒ  ｉｎｆｏｒｍａｔｉｏｎ）を伝達する専用チャネルである。当該情報は主に、データパイプ間のチャネルバインディング（ｃｈａｎｎｅｌ  ｂｉｎｄｉｎｇ）情報及び各放送会社のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコードし、放送会社ＩＤ、サービス数、ＢＡＳＥ＿ＤＰ＿ＩＤのような情報を取得することができる。高速サービスの取得のために、ＦＩＣだけでなくベースデータパイプもＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコードすることができる。ベースデータパイプが伝達するコンデンツを除いて、ベースデータパイプは、ノーマルデータパイプと全く同じ方式でエンコードされてフレームにマップされる。したがって、ベースデータパイプに関する追加説明は不要である。ＦＩＣデータが生成されて管理階層で消費される。ＦＩＣデータのコンデンツは、管理階層の仕様に説明されたとおりである。
【０３１４】
ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（静的）である部分でＦＩＣ＿ＦＬＡＧパラメータによってシグナルされる。ＦＩＣが用いられると、ＦＩＣ＿ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドは、ＰＬＳ２のスタティック（静的）である部分で定義される。当該フィールドでシグナルされるものはＦＩＣ＿ＶＥＲＳＩＯＮであり、ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ．ＦＩＣは、ＰＬＳ２と同じ変調、コーディング、タイムインターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣのような同一のシグナリングパラメータを共有する。ＦＩＣデータは、存在するなら、ＰＬＳ２の後にマップされるか、ＥＡＣが存在すると、ＥＡＣの直後にマップされる。ノーマルデータパイプ、補助ストリーム、又はダミーセルのいずれもＦＩＣの前に位置しない。ＦＩＣセルをマップする方法は、ＥＡＣと全く同一であり、これはさらにＰＬＳと同一である。
【０３１５】
ＰＬＳの後にＥＡＣが存在しない場合、ＦＩＣセルは、（ａ）の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＦＩＣデータサイズによって、（ｂ）に示すように、ＦＩＣセルは数個のシンボルに対してマップされる。
【０３１６】
ＦＩＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＦＩＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、マッピングは次のシンボルに進行され、これはＦＳＳと全く同じ方式で続けて行われる。この場合、ＦＩＣがマップされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳに比べてより多いアクティブキャリアを有する。
【０３１７】
ＥＡＳメッセージが現フレームで伝送されると、ＥＡＣはＦＩＣよりも先にマップされ、（ｂ）に示すように、ＥＡＣの次のセルから、ＦＩＣセルはインデックスの昇順でマップされる。
【０３１８】
ＦＩＣマッピングが完了した後、一つ以上のデータパイプがマップされ、その後、存在するなら、補助ストリーム、ダミーセルが続く。
【０３１９】
図１９は、本発明の一実施例に係るＦＥＣ構造を示す。
【０３２０】
図１９は、ビットインターリービング前の本発明の一実施例に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示されたＦＥＣ構造は、ＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに該当する同一の値を有する。
【０３２１】
図１９に示すように、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋbchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコードされたＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０３２２】
Ｎldpcの値は、６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
【０３２３】
下記の表２８及び表２９は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。
【表２８】
0006291081.tif 000030
【表２９】
0006291081.tif 000031
【０３２４】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次のとおりである。
【０３２５】
１２−誤り訂正ＢＣＨコードがＢＢＦの外部エンコーディングに用いられる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は、全ての多項式を乗算することによって得られる。
【０３２６】
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコードするために用いられる。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）がそれぞれのＩldpc（ＢＣＨ−エンコードされたＢＢＦ）から組織的にエンコードされ、Ｉldpcに付加される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。
【数２】
0006291081.tif 000032
【０３２７】
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２８及び表２９にそれぞれ与えられる。
【０３２８】
ロングＦＥＣＢＬＯＣＫに対してＮldpc−Ｋldpcパリティビットを計算する具体的な手順は次のとおりである。
【０３２９】
１）パリティビット初期化
【数３】
0006291081.tif 000033
【０３３０】
２）パリティーチェックマトリクスのアドレスの一番目の行で特定されたパリティビットアドレスで一番目の情報ビットｉ0を累算する（ａｃｃｕｍｕｌａｔｅ）。パリティーチェックマトリクスのアドレスの詳細な内容は後述する。例えば、比率１３／１５に対して、
【数４】
0006291081.tif 000034
【０３３１】
３）次の３５９個の情報ビットｉs、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビットアドレスでｉsを累算する。
【数５】
0006291081.tif 000035
【０３３２】
ここで、ｘは、最初のビットｉ0に該当するパリティビット累算器のアドレスを示し、Ｑldpcは、パリティーチェックマトリクスのアドレスで特定されたコードレート（ｃｏｄｅ  ｒａｔｅ）依存定数である。上記の例である、比率１３／１５に対する、したがって情報ビットｉ1に対するＱldpc＝２４に続いて、次の動作が実行される。
【数６】
0006291081.tif 000036
【０３３３】
４）３６１番目の情報ビットｉ360に対して、パリティビット累算器のアドレスは、パリティーチェックマトリクスのアドレスの２番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉs、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器のアドレスは、式６を用いて得られる。ここで、ｘは情報ビットｉ360に該当するパリティビット累算器のアドレス、すなわち、パリティーチェックマトリクスの２番目の行のエントリを示す。
【０３３４】
５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティーチェックマトリクスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めるために用いられる。
【０３３５】
全情報ビットが利用された後、最終パリティビットが次のように得られる。
【０３３６】
６）ｉ＝１から始まって次の動作を順次に実行する
【数７】
0006291081.tif 000037
【０３３７】
ここで、ｐi、ｉ＝０，１，．．．Ｎldpc−Ｋldpc−１の最終コンデンツは、パリティビットｐiと同一である。
【表３０】
0006291081.tif 000038
【０３３８】
表３０を表３１に代え、ロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスに代えることを除けば、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔ  ＬＤＰＣエンコーディング手順にしたがう。
【表３１】
0006291081.tif 000039
【０３３９】
図２０は、本発明の一実施例に係るタイムインターリービングを示す。
【０３４０】
（ａ）乃至（ｃ）は、タイムインターリービングモードの例を示す。
【０３４１】
タイムインターリーバは、データパイプレベルで動作する。タイムインターリービングのパラメータはそれぞれのデータパイプに対して別々に設定されてもよい。
【０３４２】
ＰＬＳ２−ＳＴＡＴデータの一部に現れる次のパラメータは、タイムインターリービングを構成する。
【０３４３】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０又は１）：タイムインターリービングモードを示す。０は、タイムインターリービンググループ当たりに複数のタイムインターリービングブロック（一つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、一つのタイムインターリービンググループは一つのフレームに（フレーム間インターリービング無しで）直接マップされる。１は、タイムインターリービンググループ当たりに一つのタイムインターリービングブロックだけを有するモードを示す。この場合、タイムインターリービングブロックは、一つ以上のフレームにわたって拡散される（フレーム間インターリービング）。
【０３４４】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’であれば、当該パラメータは、タイムインターリービンググループ当たりのタイムインターリービングブロックの数ＮTIである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘１’である場合、当該パラメータは、一つのタイムインターリービンググループから拡散されるフレームの数ＰIである。
【０３４５】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりのＸＦＥＣＢＬＯＣＫの最大数を示す。
【０３４６】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１，２，４，８）：与えられたフィジカルプロファイルの同一のデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩJUMPを示す。
【０３４７】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０又は１）：タイムインターリービングがデータフレームに用いられないと、当該パラメータは１に設定される。タイムインターリービングが用いられると、０に設定される。
【０３４８】
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫは、データグループの一つのタイムインターリービンググループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
【０３４９】
タイムインターリービングがデータフレームに用いられないと、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかし、スケジューラからのダイナミック（動的）構成情報のためのディレイコンペセーション（遅延補償）ブロックは依然として必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、タイムインターリービンググループにグルーピングされる。すなわち、それぞれのタイムインターリービンググループは整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（動的）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎのタイムインターリービンググループにあるＸＦＥＣＢＬＯＣＫの数は、ＮxBLOCK_Group（ｎ）で示し、ＰＬＳ２−ＤＹＮデータでＤＰ＿ＮＵＭ＿ＢＬＯＣＫとしてシグナルされる。このとき、ＮxBLOCK_Group（ｎ）は、最小値０から、最大の値が１０２３である最大値ＮxBLOCK_Group_MAX（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化してもよい。
【０３５０】
それぞれのタイムインターリービンググループは、一つのフレームに直接マップされたり、ＰI個のフレームにわたって拡散される。また、それぞれのタイムインターリービンググループは、一つ以上（ＮTI個）のタイムインターリービングブロックに分離される。ここでそれぞれのタイムインターリービングブロックは、タイムインターリーバメモリの一つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは、やや異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービンググループに分離されると、タイムインターリービンググループは一つのフレームにのみ直接マップされる。下記の表３２に示すように、タイムインターリービングには３つのオプションがある（タイムインターリービングを省略する追加オプションを除く）。
【表３２】
0006291081.tif 000040
【０３５１】
一般に、タイムインターリーバは、フレーム生成手順の前にデータパイプデータに対するバッファとしても働くはずである。これは、それぞれのデータパイプに対して２個のメモリバンクによって達成される。最初のタイムインターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み取られる間に、２番目のタイムインターリービングブロックが２番目のバンクに書き込まれる。
【０３５２】
【数８】
0006291081.tif 000041
【０３５３】
図２１は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
【０３５４】
図２１（ａ）は、タイムインターリーバで書き込み動作を示し、図２１（ｂ）は、タイムインターリーバで読み取り動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫはタイムインターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作が続けて行われる。そして、インターリービングアレイで、セルが対角線方向に読み取られる。
【数９】
0006291081.tif 000042
【０３５５】
【数１０】
0006291081.tif 000043
【０３５６】
結果的に、読み取られるセル位置は、座標
【数１１】
0006291081.tif 000044
によって算出される。
【０３５７】
図２２は、本発明の他の実施例に係る、ツイストされた行−列ブロックインターリーバの動作を示す。
【０３５８】
【数１２】
0006291081.tif 000045
【０３５９】
【数１３】
0006291081.tif 000046
【０３６０】
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、ＮTI＝１、ＩJUMP＝１、ＰI＝１によってＰＬＳ２−ＳＴＡＴデータでシグナルされる。それぞれＮcells＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナルされる。ＸＦＥＣＢＬＯＣＫの最大数はＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナルされ、これは
【数１４】
0006291081.tif 000047
につながる。
【０３６１】
図２３は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す。
【０３６２】
【数１５】
0006291081.tif 000048
【０３６３】
図２４は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
【０３６４】
図２４は、パラメータ
【数１６】
0006291081.tif 000049
及びＳshift＝３を有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。
【０３６５】
図２５は、本発明の一実施例に係る放送サービスを支援するためのプロトコルスタック（ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示す図である。
【０３６６】
本発明の一実施例に係る放送サービスは、視聴覚データ（Ａｕｉｄｏ／Ｖｉｄｅｏ；Ａ／Ｖ）の他、ＨＴＭＬ５アプリケーション、両方向サービス、ＡＣＲサービス、セカンドスクリーン（ｓｅｃｏｎｄ  ｓｃｒｅｅｎ）サービス、個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）サービスなどの付加サービスも提供することができる。
【０３６７】
このような放送サービスは、地上波、ケーブル衛星などの放送信号である物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）を介して伝送することができる。また、本発明の一実施例に係る放送サービスは、インターネット通信網（ｂｒｏａｄｂａｎｄ）を介して伝送することができる。
【０３６８】
放送サービスが地上波、ケーブル衛星などの放送信号である物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）で伝送される場合、放送受信装置は、カプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）されたＭＰＥＧ−２伝送ストリーム（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ；ＴＳ）及びカプセル化されたＩＰデータグラムを、放送信号を復調して抽出することができる。放送受信装置は、ＩＰデータグラムからユーザデータグラムプロトコル（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ；ＵＤＰ）データグラムを抽出することができる。放送受信装置は、ＵＤＰデータグラムからシグナリング情報を抽出することができる。このとき、シグナリング情報はＸＭＬ形態であってもよい。また、放送受信装置は、ＵＤＰデータグラムから非同期階層化コーディング／階層化コーディング伝送（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ／  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ；ＡＬＣ／ＬＣＴ）パケットを抽出することができる。放送受信装置は、ＡＬＣ／ＬＣＴパケットから単方向ファイル伝送（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ；ＦＬＵＴＥ）パケットを抽出することができる。このとき、ＦＬＵＴＥパケットは、実時間オーディオ／ビデオ／字幕データ、非実時間（Ｎｏｎ−Ｒｅａｌ  Ｔｉｍｅ；ＮＲＴ）データ、及び電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｄｉｅ；ＥＳＧ）データを含むことができる。また、放送受信装置は、ＵＤＰデータグラムから実時間伝送プロトコル（例えば、Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ；ＲＴＣＰ）パケット及びＲＴＰ制御プロトコル（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ；ＲＴＣＰ）パケットを抽出することができる。放送受信装置は、ＲＴＰ／ＲＴＣＰパケットのような実時間情報パケットからＡ／Ｖデータ及び付加データを抽出することができる。このとき、ＮＲＴデータ、Ａ／Ｖデータ及び付加データのうち少なくとも一つは、ＩＳＯベースメディアファイルフォーマット（ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ；ＩＳＯＢＭＦＦ）の形態であってもよい。また、放送受信装置は、ＭＰＥＧ−２ＴＳパケット又はＩＰパケットからＮＲＴデータ、Ａ／Ｖ、ＰＳＩ／ＰＳＩＰのようなシグナリング情報を抽出することができる。このとき、シグナリング情報は、ＸＭＬ又はバイナリ形態であってもよい。
【０３６９】
放送サービスがインターネット通信網（ｂｒｏａｄｂａｎｄ）で伝送される場合、放送受信装置はインターネット通信網からＩＰパケットを受信することができる。放送受信装置はＩＰパケットからＴＣＰパケットを抽出することができる。放送受信装置はＴＣＰパケットからＨＴＴＰパケットを抽出することができる。放送受信装置はＨＴＴＰパケットからＡ／Ｖ、付加データ、シグナリング情報などを抽出することができる。このとき、Ａ／Ｖ及び付加データのうち少なくとも一つは、ＩＳＯＢＭＦＦ形態であってもよい。また、シグナリング情報はＸＭＬ形態であってもよい。
【０３７０】
図２６は、本発明の一実施例に係るＩＰネットワークを介したメディアコンテンツ送受信システムの構成を示す図である。
【０３７１】
本発明の一実施例に係るＩＰネットワークを介したメディアコンテンツの送受信は、実際メディアコンテンツを含む伝送パケットの送受信とメディアコンテンツ再生情報の送受信とに区別される。放送受信装置１００は、メディアコンテンツ再生情報を受信し、メディアコンテンツを含む伝送パケットを受信する。このとき、メディアコンテンツ再生情報は、メディアコンテンツの再生のために必要な情報を示す。メディアコンテンツ再生情報は、メディアコンテンツの再生のために必要な空間的情報（ｓｐａｔｉａｌ  ｉｎｆｏｒｍａｔｉｏｎ）及び時間的情報（ｔｅｍｐｏｒａｌ  ｉｎｆｏｒｍａｔｉｏｎ）のうち少なくとも一つを含むことができる。放送受信装置１００は、メディアコンテンツ再生情報に基づいてメディアコンテンツを再生する。
【０３７２】
具体的な実施例で、ＭＭＴ標準に基づいてメディアコンテンツをＩＰネットワークを介して送受信することができる。このとき、コンテンツサーバー５０は、メディアコンテンツ再生情報を含む再生情報（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ；ＰＩ）ドキュメントを伝送する。また、コンテンツサーバー５０は、放送受信装置１００の要求に基づいて、メディアコンテンツを含むＭＭＴプロトコル（ＭＭＴＰ）パケットを伝送する。放送受信装置１００は、ＰＩドキュメントを受信する。放送受信装置１００は、メディアコンテンツを含む伝送パケットを受信する。放送受信装置１００は、メディアコンテンツを含む伝送パケットからメディアコンテンツを抽出する。放送受信装置１００は、ＰＩドキュメントに基づいてメディアコンテンツを再生する。
【０３７３】
他の具体的な実施例で、図２６の実施例のように、ＭＰＥＧ−ＤＡＳＨ標準によってメディアコンテンツがＩＰネットワークを介して送受信されてもよい。図２６で、コンテンツサーバー５０は、メディアコンテンツ再生情報を含むメディア再生デスクリプション（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｏｎ；ＭＰＤ）を伝送する。ただし、具体的な実施例によっては、ＭＰＤをコンテンツサーバー５０ではなく他の外部のサーバーが伝送してもよい。また、コンテンツサーバー５０は、放送受信装置１００の要求に基づいて、メディアコンテンツを含むセグメント（ｓｅｇｍｅｎｔ）を伝送する。放送受信装置１００は、ＭＰＤを受信する。放送受信装置１００は、ＭＰＤに基づいてメディアコンテンツをコンテンツサーバーに要求する。放送受信装置１００は、要求に基づいてメディアコンテンツを含む伝送パケットを受信する。放送受信装置１００はＭＰＤに基づいてメディアコンテンツを再生する。そのために、放送受信装置１００は、制御部１１０にＤＡＳＨクライアント（ｃｌｉｅｎｔ）を含むことができる。ＤＡＳＨクライアントは、ＭＰＤをパース（ｐａｒｓｅ）するＭＰＤパーサー、セグメントをパースするセグメントパーサー、ＩＰ送受信部１３０を介して、ＨＴＴＰ要求メッセージを伝送し、ＨＴＴＰ応答メッセージを受信するＨＴＴＰクライアント、メディアを再生するメディアエンジン（ｅｎｇｉｎｅ）を含むことができる。
【０３７４】
図２７は、本発明の一実施例に係るＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）の構造を示す図である。ＭＰＤは、ピリオド（Ｐｅｒｉｏｄ）エレメント、アダプテーションセット（Ａｄａｐｔａｔｉｏｎ  Ｓｅｔ）エレメント、及びリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）エレメントを含むことができる。
【０３７５】
ピリオドエレメントは、ピリオドに関する情報を含む。ＭＰＤは、複数のピリオドに関する情報を含むことができる。ピリオドは、メディアコンテンツ再生（ｐｒｅｓｅｎｔａｔｉｏｎ）の連続した時間区間を表す。
【０３７６】
アダプテーションセットエレメントは、アダプテーションセットに関する情報を含む。ＭＰＤは、複数のアダプテーションセットに関する情報を含むことができる。アダプテーションセットは、相互切り替え可能な１つ又はそれ以上のメディアコンテンツコンポーネントを含むメディアコンポーネントの集合である。アダプテーションセットは、１つ又はそれ以上のリプレゼンテーションを含むことができる。各アダプテーションセットは、それぞれ異なる言語のオーディオを含んでもよく、それぞれ異なる言語の字幕を含んでもよい。
【０３７７】
リプレゼンテーションエレメントは、リプレゼンテーションに関する情報を含む。ＭＰＤは、複数のリプレゼンテーションに関する情報を含むことができる。リプレゼンテーションは、１つ又はそれ以上のメディアコンポーネントの構造化した集合であり、同一メディアコンテンツコンポーネントに対して別個にエンコードされた複数のリプレゼンテーションが存在してもよい。一方、ビットストリームスイッチング（ｂｉｔｓｔｒｅａｍ  ｓｗｉｔｃｈｉｎｇ）が可能な場合、放送受信装置１００は、メディアコンテンツ再生の途中にアップデートされた情報に基づいて、受信されるリプレゼンテーションを他のリプレゼンテーションに切り替えることもできる。特に、放送受信装置１００は、帯域幅の環境によって、受信されるリプレゼンテーションを他のリプレゼンテーションに切り替えることができる。リプレゼンテーションは複数のセグメントに分割される。
【０３７８】
セグメントは、メディアコンテンツデータの単位である。リプレゼンテーションは、ＨＴＴＰ１．１（ＲＦＣ２６１６）で定義されたＨＴＴＰ  ＧＥＴ又はＨＴＴＰ  ｐａｒｔｉａｌ  ＧＥＴ  ｍｅｔｈｏｄを用いたメディアコンテンツ受信機３０の要求に応じて、セグメント又はセグメントの一部分で伝送されてもよい。
【０３７９】
また、セグメントは、複数のサブセグメントで構成することができる。サブセグメントは、セグメントレベルでインデックス可能な最小の単位（ｕｎｉｔ）を意味することができる。セグメントは、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）、メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）、インデックスセグメント（Ｉｎｄｅｘ  Ｓｅｇｍｅｎｔ）、ビットストリームスイッチングセグメント（Ｂｉｔｓｔｒｅａｍ  Ｓｗｉｔｃｈｉｎｇ  Ｓｅｇｍｅｎｔ）などを含むことができる。
【０３８０】
図２８は、本発明の一実施例に係る放送サービスの伝送層を示す図である。
【０３８１】
放送伝送装置３００は、複数の層から構成された放送信号で放送サービスを伝送することができる。放送サービスを伝送するための複数の層のうち、物理的媒体（ｐｈｙｓｉｃａｌ  ｍｅｄｉｕｍ）を介して原始的な（ｒａｗ）放送信号を送受信するための伝送層を物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）ということができる。放送伝送装置３００は、１つ又は複数の周波数上で１つ以上の物理層パイプ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ；ＰＬＰ）を介して放送サービス及び放送サービス関連データを伝送することができる。一つの周波数上に複数の物理層パイプが存在してもよく、このとき、ＰＬＰは、物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）上で識別可能な一連の論理的データ伝達経路である。ＰＬＰは、データパイプ（ｄａｔａ  ｐｉｐｅ）などの他の用語に代えてもよい。一つの放送サービスは複数のコンポーネントを含むことができる。このとき、複数のコンポーネントはそれぞれ、オーディオ、ビデオ及びデータコンポーネントのいずれか一つであってもよい。各放送局は、放送伝送装置３００を介してカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された放送サービスを１つ又は複数のＰＬＰで伝送することができる。具体的に、放送局は、放送伝送装置３００を介して、一つのサービスに含まれた複数のコンポーネントを複数のＰＬＰで伝送することができる。又は、放送局は、放送伝送装置３００を介して、一つのサービスに含まれた複数のコンポーネントを一つのＰＬＰで伝送することができる。例えば、図２８の実施例で、第１の放送局Ｂｒｏａｄｃａｓｔ  ＃１は、放送伝送装置３００を介して、シグナリング情報を一つのＰＬＰ（ＰＬＰ  ＃０）で伝送することができる。また、図２８の実施例で第１の放送局Ｂｒｏａｄｃａｓｔ  ＃１は、放送伝送装置３００を介して、第１の放送サービスに含まれた第１のコンポーネントＣｏｍｐｏｎｅｎｔ１及び第２のコンポーネントＣｏｍｐｏｎｅｎｔ２をそれぞれ他の第１のＰＬＰ（ＰＬＰ  ＃１）及び第２のＰＬＰ（ＰＬＰ  ＃２）で伝送する。また、図２８の実施例で第Ｎの放送局Ｂｒａｏａｄｃａｓｔ  ＃Ｎは、第１の放送サービスＳｅｒｖｉｃｅ  ＃１に含まれた第１のコンポーネントＣｏｍｐｏｎｅｎｔ１及び第２のコンポーネントＣｏｍｐｏｎｅｎｔ２を第ＮのＰＬＰ（ＰＬＰ  ＃Ｎ）で伝送する。このとき、実時間放送サービスは、ＩＰ、ユーザデータグラムプロトコル（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ；ＵＤＰ）及び実時間コンテンツ伝送のためのプロトコル、例えば、実時間伝送プロトコル（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ；ＲＴＰ）のうちいずれか一つにカプセル化することができる。非実時間コンテンツ及び非実時間データである場合にも、ＩＰ、ＵＤＰ及びコンテンツ伝送プロトコル、例えば、ＦＬＵＴＥのうち少なくとも一つのパケットにカプセル化することができる。したがって、放送伝送装置３００が送信する物理層フレーム内には、１つ以上のコンポーネントを伝達する複数のＰＬＰを含むことができる。したがって、放送受信装置１００は、放送サービス連結情報を取得する放送サービススキャンを行うために複数のＰＬＰを全て確認しなければならない。そこで、放送受信装置１００が放送サービススキャンを効率的に行うようにする放送伝送方法及び放送受信方法が必要である。
【０３８２】
図２９は、本発明の一実施例に係る放送受信装置の構成を示す図である。
【０３８３】
図２９の実施例で放送受信装置１００は、受信部１２０及び制御部１５０を含む。受信部１２０は、放送受信部１１０及びインターネットプロトコル（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ；ＩＰ）通信部１３０を含む。
【０３８４】
放送受信部１１０は、チャネル同期化部（Ｃｈａｎｎｅｌ  Ｓｙｎｃｈｒｏｎｉｚｅｒ）１１１、チャネルイコライザ（ｃｈａｎｎｅｌ  ｅｑｕａｌｉｚｅｒ）１１３及びチャネルデコーダ（ｃｈａｎｎｅｌ  ｄｅｃｏｄｅｒ）１１５を含む。
【０３８５】
チャネル同期化部１１０は、放送信号を受信できる基底帯域（ｂａｓｅｂａｎｄ）でデコーディングが可能なようにシンボル周波数とタイミングを同期化する。
【０３８６】
チャネルイコライザ１１３は、同期化された放送信号の歪みを補償する。具体的に、チャネルイコライザ１１３は、マルチパス（ｍｕｌｔｉｐａｔｈ）、ドップラー効果などによる、同期化された放送信号の歪みを補償する。
【０３８７】
チャネルデコーダ１１５は、歪みが補償された放送信号をデコードする。具体的に、チャネルデコーダ１１５は、歪みが補償された放送信号から伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）を抽出する。このとき、チャネルデコーダ１１５は、順方向誤り訂正（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ；ＦＥＣ）を行うことができる。
【０３８８】
ＩＰ通信部１３０は、インターネット網でデータを受信して伝送する。
【０３８９】
制御部１５０は、シグナリングデコーダ１５１、伝送パケットインターフェース１５３、広帯域パケットインターフェース１５５、基底帯域動作制御部１５７、共通プロトコルスタック（Ｃｏｍｍｏｎ  Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）１５９、サービスマップデータベース１６１、サービスシグナリングチャネルプロセシングバッファー及びパーサー１６３、Ａ／Ｖプロセッサ１６５、放送サービスガイドプロセッサ１６７、アプリケーションプロセッサ１６９、及びサービスガイドデータベース１７１を含む。
【０３９０】
シグナリングデコーダ１５１は、放送信号のシグナリング情報をデコードする。
【０３９１】
伝送パケットインターフェース１５３は、放送信号から伝送パケットを抽出する。このとき、伝送パケットインターフェース１５３は、抽出した伝送パケットからシグナリング情報又はＩＰデータグラムなどのデータを抽出することができる。
【０３９２】
広帯域パケットインターフェース１５５は、インターネット網から受信したデータからＩＰパケットを抽出する。このとき、広帯域パケットインターフェース１５５は、ＩＰパケットからシグナリングデータ又はＩＰデータックラムを抽出することができる。
【０３９３】
基底帯域動作制御部１５７は、基底帯域から放送情報受信情報を受信することに関連した動作を制御する。
【０３９４】
共通プロトコルスタック１５９は、伝送パケットからオーディオ又はビデオを抽出する。
【０３９５】
Ａ／Ｖプロセッサ１６５は、オーディオ又はビデオを処理する。
【０３９６】
サービスシグナリングチャネルプロセシングバッファー及びパーサー１６３は、放送サービスをシグナルするシグナリング情報をパースしてバッファリングする。具体的に、サービスシグナリングチャネルプロセシングバッファー及びパーサー１６３は、ＩＰデータグラムから放送サービスをシグナルするシグナリング情報をパースしてバッファリングすることができる。
【０３９７】
サービスマップデータベース１６５は、放送サービスに関する情報を含む放送サービスリストを保存する。
【０３９８】
サービスガイドプロセッサ１６７は、地上波放送サービスのプログラムを案内する地上波放送サービスガイドデータを処理する。
【０３９９】
アプリケーションプロセッサ１６９は、放送信号からアプリケーション関連情報を抽出して処理する。
【０４００】
サービスガイドデータベース１７１は、放送サービスのプログラム情報を保存する。
【０４０１】
図３０及び図３１は、本発明の他の実施例に係る放送受信装置の構成を示す図である。
【０４０２】
図３０及び図３１の実施例で、放送受信装置１００は、放送受信部１１０、インターネットプロトコル通信部１３０及び制御部１５０を含む。
【０４０３】
放送受信部１１０は、チューナー１１４、物理フレームパーサー（Ｐｈｙｓｉｃａｌ  Ｆｒａｍｅ  Ｐａｒｓｅｒ）１１６、及び物理層コントローラ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｃｏｎｔｒｏｌｌｅｒ）１１８を含むことができる。
【０４０４】
チューナー１１４は、放送チャネルを介して放送信号を受信し、物理フレームを抽出する。物理フレームは、物理層上の伝送単位である。物理フレームパーサー１１６は、受信された物理フレームをパースしてリンク層フレーム（Ｌｉｎｋ  Ｌａｙｅｒ  Ｆｒａｍｅ）を取得する。
【０４０５】
物理層コントローラ１１８は、チューナー１１４及び物理フレームパーサー１１６の動作を制御する。一実施例で、物理層コントローラ１１８は、放送チャネルのＲＦ情報を用いてチューナー１１４を制御することができる。具体的に、物理層コントローラ１１８が周波数情報をチューナー１１４に伝送すると、チューナー１１４は、受信した周波数情報に該当する物理フレームを放送信号から取得することができる。
【０４０６】
他の実施例で、物理層コントローラ１１８は、物理層パイプの識別子を用いて物理層パーサー１１６の動作を制御することができる。具体的に、物理層コントローラ１１８は、物理層パイプを構成する複数の物理層パイプの中から特定の物理層パイプを識別するための識別子情報を物理フレームパーサー１１６に伝送する。物理フレームパーサー１１６は、受信した識別子情報に基づいて物理層パイプを識別し、識別した物理層パイプからリンク層フレームを取得することができる。
【０４０７】
制御部１５０は、リンク層フレームパーサー（Ｌｉｎｋ  Ｌａｙｅｒ  Ｆｒａｍｅ  Ｐａｒｓｅｒ）１６４、ＩＰ／ＵＤＰデータグラムフィルタ（ＩＰ／ＵＤＰ  Ｄａｔａｇｒａｍ  Ｆｉｌｔｅｒ）１７１、ＤＴＶコントロールエンジン１７４、ＡＬＣ／ＬＣＴ＋クライアント１７２、タイミングコントロール１７５、ＤＡＳＨクライアント１９２、ＩＳＯＢＭＦＦパーサー１９４及びメディアデコーダ１９５を含む。
【０４０８】
リンク層フレームパーサー１６４は、リンク層フレームからデータを抽出する。具体的に、リンク層フレームパーサー１６４は、リンク層フレームからリンク層シグナリングを取得することができる。また、リンク層フレームパーサー１６４は、リンク層フレームからＩＰ／ＵＤＰデータグラムを取得することができる。
【０４０９】
ＩＰ／ＵＤＰデータグラムフィルタ（Ｄａｔａｇｒａｍ  Ｆｉｌｔｅｒ）１７１は、リンク層フレームパーサー１６４から受信したＩＰ／ＵＤＰデータグラムから特定ＩＰ／ＵＤＰデータグラムをフィルタリングする。
【０４１０】
ＡＬＣ／ＬＣＴ＋クライアント１７２は、アプリケーション層伝送パケットを処理する。アプリケーション層伝送パケットは、ＡＬＣ／ＬＣＴ＋パケットを含むことができる。具体的に、ＡＬＣ／ＬＣＴ＋クライアント１７２は、複数のアプリケーション層伝送パケットを収集して、１つ以上のＩＳＯＢＭＦＦメディアファイルフォーマットオブジェクトを生成することができる。
【０４１１】
タイミングコントロール１７５は、システムタイム情報を含むパケットを処理する。そして、タイミングコントロール１７５は、処理した結果に基づいてシステムクロックを制御する。
【０４１２】
ＤＡＳＨクライアント１９２は、実時間ストリーミング又は適応型メディアストリーミングを処理する。具体的に、ＤＡＳＨクライアント１９２は、ＨＴＴＰに基づく適応型メディアストリーミングを処理してＤＡＳＨセグメントを取得することができる。このとき、ＤＡＳＨセグメントは、ＩＳＯＢＭＦＦオブジェクトの形態であってもよい。
【０４１３】
ＩＳＯＢＭＦＦパーサー１９４は、ＤＡＳＨクライアント１９２から受信したＩＳＯＢＭＦＦオブジェクトからオーディオ／ビデオデータを抽出する。このとき、ＩＳＯＢＭＦＦパーサー１９４は、オーディオ／ビデオデータをアクセスユニット（Ａｃｃｅｓｓ  Ｕｎｉｔ）単位で抽出することができる。また、ＩＳＯＢＭＦＦ１９４は、ＩＳＯＢＭＦＦオブジェクトからオーディオ／ビデオのためのタイミング情報を取得することができる。
【０４１４】
メディアデコーダ１９５は、受信されたオーディオ及びビデオデータをデコードする。また、メディアデコーダ１９５は、デコードした結果をメディア出力端で再生（ｐｒｅｓｅｎｔａｔｉｏｎ）する。
【０４１５】
ＤＴＶコントロールエンジン１７４は、各モジュール間のインターフェースを担当する。具体的に、ＤＴＶコントロールエンジン１７４は、各モジュールの動作のために必要なパラメータを伝達して各モジュールの動作を制御することができる。
【０４１６】
インターネットプロトコル通信部１３０は、ＨＴＴＰアクセスクライアント１３５を含むことができる。ＨＴＴＰアクセスクライアント１３５は、ＨＴＴＰサーバーと要求を送／受信したり、要求に対する応答を送／受信することができる。
【０４１７】
図３２は、本発明の更に他の実施例に係る放送受信装置の構成を示す図である。
【０４１８】
図３２の実施例で、放送受信装置１００は、放送受信部１１０、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ；ＩＰ）通信部１３０及び制御部１５０を含む。
【０４１９】
放送受信部１１０は、放送受信部１１０が行う複数の機能をそれぞれ行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、放送受信部１１０は、複数の半導体部品が一つに集積されるシステムオンチップ（Ｓｙｓｔｅｍ  Ｏｎ  Ｃｈｉｐ；ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサと、ＤＲＡＭなどの半導体が一つに統合された半導体であってもよい。放送受信部１１０は、物理層モジュール１１９、物理層ＩＰフレームモジュール１１７を含むことができる。物理層モジュール１１９は、放送網の放送チャネルを介して放送関連信号を受信して処理する。物理層ＩＰフレームモジュール１１７は、物理層モジュール１１９から取得したＩＰデータグラムなどのデータパケットを特定フレームに変換する。例えば、物理層モジュール１１９は、ＩＰデータグラムなどをＲＳフレーム又はＧＳＥなどに変換することができる。
【０４２０】
ＩＰ通信部１３０は、ＩＰ通信部１３０が行う複数の機能をそれぞれ行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的にＩＰ通信部１３０は、複数の半導体部品が一つに集積されるシステムオンチップ（Ｓｙｓｔｅｍ  Ｏｎ  Ｃｈｉｐ；ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサと、ＤＲＡＭなどの半導体が一つに統合された半導体であってもよい。ＩＰ通信部１３０は、インターネット接近制御モジュール１３１を含むことができる。インターネット接近制御モジュール１３１は、インターネット通信網（ｂｒｏａｄｂａｎｄ）を介してサービス、コンテンツ及びシグナリングデータのうち少なくとも一つを取得するための放送受信装置１００の動作を制御する。
【０４２１】
制御部１５０は、制御部１５０が行う複数の機能をそれぞれ行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、制御部１５０は、複数の半導体部品が一つに集積されるシステムオンチップ（Ｓｙｓｔｅｍ  Ｏｎ  Ｃｈｉｐ；ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサと、ＤＲＡＭなどの半導体が一つに統合された半導体であってもよい。制御部１５０は、シグナリングデコーダ１５１、サービスマップデータベース１６１、サービスシグナリングチャネルパーサー１６３、アプリケーションシグナリングパーサー１６６、アラートシグナリングパーサー１６８、ターゲッティングシグナリングパーサー１７０、ターゲッティングプロセッサ１７３、Ａ／Ｖプロセッサ１６１、アラーティング（Ａｌｅｒｔｉｎｇ）プロセッサ１６２、アプリケーションプロセッサ１６９、スケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２、ユーザ要求ストリーミングデコーダ１８３、ファイルデータベース１８４、コンポーネント同期化部１８５、サービス／コンテンツ取得制御部１８７、再分配モジュール１８９、装置管理者１９３、及びデータシェアリング部１９１のうち少なくとも一つを含むことができる。
【０４２２】
サービス／コンテンツ取得制御部１８７は、放送網又はインターネット通信網を介して取得したサービス、コンテンツ、サービス又はコンテンツと関連したシグナリングデータの取得のための受信機の動作を制御する。
【０４２３】
シグナリングデコーダ１５１は、シグナリング情報をデコードする。
【０４２４】
サービスシグナリングパーサー１６３は、サービスシグナリング情報をパースする。
【０４２５】
アプリケーションシグナリングパーサー１６６は、サービスに関連したシグナリング情報を抽出してパースする。このとき、サービスに関連したシグナリング情報は、サービススキャンに関連したシグナリング情報であってもよい。また、サービスに関連したシグナリング情報は、サービスで提供されるコンテンツに関連したシグナリング情報であってもよい。
【０４２６】
アラートシグナリングパーサー１６８は、アラーティングに関連したシグナリング情報を抽出してパースする。
【０４２７】
ターゲッティングシグナリングパーサー１７０は、サービス又はコンテンツを個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）するための情報、又はターゲッティング情報をシグナルする情報を抽出してパースする。
【０４２８】
ターゲッティングプロセッサ１７３は、サービス又はコンテンツを個人化するための情報を処理する。
【０４２９】
アラーティングプロセッサ１６２は、アラーティングに関連したシグナリング情報を処理する。
【０４３０】
アプリケーションプロセッサ１６９は、アプリケーション関連情報及びアプリケーションの実行を制御する。具体的に、アプリケーションプロセッサ１６９は、ダウンロードされたアプリケーションの状態及びディスプレイパラメータを処理する。
【０４３１】
Ａ／Ｖプロセッサ１６１は、デコードされたオーディオ又はビデオ、アプリケーションデータなどに基づいてオーディオ／ビデオのレンダリング関連動作を処理する。
【０４３２】
スケジュールドストリーミングデコーダ１８１は、あらかじめ放送会社などのコンテンツプロバイダが定めた日程とおりにストリーミングされるコンテンツであるスケジュールドストリーミングをデコードする。
【０４３３】
ファイルデコーダ１８２は、ダウンロードされたファイルをデコードする。特に、ファイルデコーダ１８２は、インターネット通信網でダウンロードされたファイルをデコードする。
【０４３４】
ユーザ要求ストリーミングデコーダ１８３は、ユーザ要求によって提供されるコンテンツ（Ｏｎ  Ｄｅｍａｎｄ  Ｃｏｎｔｅｎｔ）をデコードする。
【０４３５】
ファイルデータベース１８４は、ファイルを保存する。具体的に、ファイルデータベース１８４は、インターネット通信網でダウンロードしたファイルを保存することができる。
【０４３６】
コンポーネント同期化部１８５は、コンテンツ又はサービスを同期化する。具体的に、コンポーネント同期化部１８５は、スケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２、及びユーザ要求ストリーミングデコーダ１８３のうち少なくとも一つから取得したコンテンツに対する再生時間の同期化を行う。
【０４３７】
サービス／コンテンツ取得制御部１８７は、サービス、コンテンツ、サービス又はコンテンツに関連したシグナリング情報のうち少なくとも一つを取得するための受信機の動作を制御する。
【０４３８】
再分配モジュール１８９は、放送網を介してサービス又はコンテンツを受信できない場合、サービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうち少なくとも一つの取得を支援するための動作を行う。具体的に、外部の管理装置３００にサービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうち少なくとも一つを要求することができる。このとき、外部の管理装置３００はコンテンツサーバーであってもよい。
【０４３９】
装置管理者１９３は、連動可能な外部装置を管理する。具体的に、装置管理者１９３は、外部装置の追加、削除及び更新の少なくとも一つを行うことができる。また、外部装置は、放送受信装置１００と連結及びデータ交換が可能であってもよい。
【０４４０】
データシェアリング部１９１は、放送受信装置１００と外部装置の間のデータ伝送動作を行い、交換関連情報を処理する。具体的に、データシェアリング部１９１は外部装置にＡ／Ｖデータ又はシグナリング情報を伝送することができる。また、データシェアリング部１９１は外部装置からＡ／Ｖデータ又はシグナリング情報を受信することができる。
【０４４１】
図３３は、本発明の一実施例に係る放送伝送フレームを示す図である。
【０４４２】
図３３の実施例で、放送伝送フレームは、Ｐ１パート、Ｌ１パート、共通ＰＬＰ（Ｃｏｍｍｏｎ  ＰＬＰ）パート、インターリーブドＰＬＰ（Ｓｃｈｅｄｕｌｅｄ  ＆  Ｉｎｔｅｒｌｅａｖｅｄ  ＰＬＰ’ｓ）パート、及び補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）パートを含む。
【０４４３】
図３３の実施例で、放送伝送装置は、伝送シグナル探知（ｔｒａｎｓｐｏｒｔ  ｓｉｇｎａｌ  ｄｅｔｅｃｔｉｏｎ）のための情報を放送伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）のＰ１パートで伝送する。また、放送伝送装置は、放送信号チューニングのためのチューニング情報をＰ１パートで伝送することができる。
【０４４４】
図３３の実施例で、放送伝送装置は、放送伝送フレームの構成及び各ＰＬＰの特性をＬ１パートで伝送する。このとき、放送受信装置１００は、Ｐ１に基づいてＬ１パートをデコードし、放送伝送フレームの構成及び各ＰＬＰの特性を取得することができる。
【０４４５】
図３３の実施例で、放送伝送装置は、ＰＬＰ間に共通して適用される情報をＣｏｍｍｏｎ  ＰＬＰパートで伝送することができる。具体的な実施例によって、放送伝送フレームはＣｏｍｍｏｎ  ＰＬＰパートを含まなくてもよい。
【０４４６】
図３３の実施例で、放送伝送装置は、放送サービスに含まれた複数のコンポーネントをインターリーブド（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰパートで伝送する。このとき、インターリーブドＰＬＰパートは、複数のＰＬＰを含む。
【０４４７】
図３３の実施例で、放送伝送装置は、各放送サービスを構成するコンポーネントがそれぞれどのＰＬＰで伝送されるかを、Ｌ１パート又はＣｏｍｍｏｎ  ＰＬＰパートでシグナルすることができる。ただし、放送受信装置１００が放送サービススキャンなどのために具体的な放送サービス情報を取得するには、インターリーブドＰＬＰパートの複数のＰＬＰを全てデコードする必要がある。
【０４４８】
図３３の実施例とは違い、放送伝送装置は、放送伝送フレームで伝送される放送サービスと、放送サービスに含まれたコンポーネントに関する情報を含む別途のパートを含む放送伝送フレームを伝送することができる。このとき、放送受信装置１００は、別途のパートを介して迅速に放送サービス及び放送サービスに含まれたコンポーネントに関する情報を取得することができる。これについては、図３２を参照して説明する。
【０４４９】
図３４は、本発明の他の実施例に係る放送伝送フレームを示す図である。
【０４５０】
図３４の実施例で、放送伝送フレームは、Ｐ１パート、Ｌ１パート、高速情報チャネル（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ；ＦＩＣ）パート、インターリーブドＰＬＰ（Ｓｃｈｅｄｕｌｅｄ  ＆  Ｉｎｔｅｒｌｅａｖｅｄ  ＰＬＰ’ｓ）パート、及び補助データ（Ａｕｘｉｌｉａｒｙ  ｄａｔａ）パートを含む。
【０４５１】
ＦＩＣパート以外のパートは、図３３の実施例と同一である。
【０４５２】
放送伝送装置は、高速情報（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ）をＦＩＣパートで伝送する。高速情報は、伝送フレームで伝送される放送ストリームの構成情報（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）、簡略な放送サービス情報、及び当該サービス／コンポーネントに関連したサービスシグナリングを含むことができる。放送受信装置１００は、ＦＩＣパートに基づいて放送サービスをスキャンすることができる。具体的に、放送受信装置１００は、ＦＩＣパートから放送サービスに関する情報を抽出することができる。
【０４５３】
図３５は、本発明の一実施例に係る伝送パケットの構成を示す図である。図３５に示す伝送パケットは、信頼できるデータ伝送を支援する伝送プロトコルを利用することができる。具体的な実施例で、信頼できるデータ伝送プロトコルは、非同期階層化コーディング（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ（ＡＬＣ））であってもよい。他の実施例で、信頼できるデータ伝送プロトコルは、階層化コーディング伝送（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ（ＬＣＴ））であってもよい。
【０４５４】
本発明の一実施例に係るパケットヘッダーは、パケットのバージョン情報を含むことができる。具体的に、当該伝送プロトコルを利用する伝送パケットのバージョン情報を含むことができる。具体的な実施例で、上述した情報はＶフィールドであってもよい。また、Ｖフィールドは４ビットであってもよい。
【０４５５】
また、本発明の一実施例に係るパケットヘッダーは、混雑制御（Ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ）のための情報の長さに関連した情報を含むことができる。具体的に、混雑制御のための情報の長さと、混雑制御のための情報の長さの基本単位に乗じる関連した倍数情報を含むことができる。
【０４５６】
具体的な実施例で、上述した情報はＣフィールドであってもよい。一実施例で、Ｃフィールドは０ｘ００に設定でき、この場合、混雑制御のための情報の長さが３２ビットであることを示す。他の実施例で、Ｃフィールドは０ｘ０１に設定でき、この場合、混雑制御のための情報の長さは６４ビットであってもよい。他の実施例で、Ｃフィールドは０ｘ０２に設定でき、この場合、混雑制御のための情報の長さは９６ビットであってもよい。他の実施例で、Ｃフィールドは０ｘ０３に設定でき、この場合、混雑制御のための情報の長さは１２８ビットであってもよい。Ｃフィールドは２ビットであってもよい。
【０４５７】
また、本発明の一実施例に係るパケットヘッダーは、プロトコルに特化された情報を含むことができる。具体的な実施例で、上述した情報は、ＰＳＩフィールドであってもよい。また、ＰＳＩフィールドは２ビットであってもよい。
【０４５８】
また、本発明の一実施例に係るパケットヘッダーは、伝送セッションの識別情報を示すフィールドの長さに関連した情報を含むことができる。具体的に、伝送セッションの識別情報を示すフィールドの倍数情報を含むことができる。上述した情報はＳフィールドであってもよい。Ｓフィールドは１ビットであってもよい。
【０４５９】
また、本発明の一実施例に係るパケットヘッダーは、伝送オブジェクトの識別情報を示すフィールドの長さに関連した情報を含むことができる。具体的に、伝送オブジェクトの識別情報を示すフィールドの基本長に乗じる倍数情報を含むことができる。上述した情報はＯフィールドであってもよい。Ｏフィールドは２ビットであってもよい。
【０４６０】
また、本発明の一実施例に係るパケットヘッダーは、伝送セッションの識別情報を示すフィールドの長さに関連した追加の情報を含むことができる。そして、パケットヘッダーは、伝送オブジェクトの識別情報を示すフィールドの長さに関連した追加の情報を含むことができる。追加の情報は、ハーフ−ワード（ｈａｌｆ−ｗｏｒｄ）が追加されるか否かを示す情報であってもよい。伝送パケットの識別情報を示すフィールド及び伝送オブジェクトの識別情報を示すフィールドは存在する必要があるため、ＳフィールドとＨフィールド、又はＯフィールドとＨフィールドが同時に０（Ｚｅｒｏ）を示すことはできない。
【０４６１】
また、本発明の一実施例に係るパケットヘッダーは、セッションが終了したか、終了が差し迫っていることを示す情報を含むことができる。この情報はＡフィールドであってもよい。具体的な実施例で、Ａフィールドが、セッションが終了したこと又は終了に差し迫っていることを示す場合には、１に設定することができる。したがって、通常の場合、Ａフィールドは０に設定することができる。放送伝送装置がＡフィールドを１に設定する場合、セッションで最後のパケットが伝送されていることを示すことができる。Ａフィールドが１に設定された場合、放送伝送装置は、当該パケットに続く全パケットの伝送が終了するまでＡフィールドを１に保持しなければならない。また、放送受信装置は、Ａフィールドが１に設定された場合、放送伝送装置がセッションでパケット伝送をまもなく中断することを認識することができる。言い換えると、放送受信装置は、Ａフィールドが１に設定された場合、セッションでそれ以上パケットを伝送しないことと認識できる。一実施例で、Ａフィールドは１ビットであってもよい。
【０４６２】
また、本発明の一実施例に係るパケットヘッダーは、オブジェクトの伝送が終了したか、終了が差し迫っていることを示す情報を含むことができる。上述した情報はＢフィールドであってもよい。具体的な実施例で、放送伝送装置は、オブジェクトの伝送終了が差し迫っている場合、Ｂフィールドを１に設定できる。したがって、通常の場合、Ｂフィールドは０に設定することができる。伝送オブジェクトを識別する情報が伝送パケットに存在しない場合、Ｂフィールドは１に設定されてもよい。そして、アウト−オブ−バンド（ｏｕｔ−ｏｆ−ｂａｎｄ）情報によって識別されたセッション内のオブジェクト伝送終了が差し迫っていることを示すことができる。また、Ｂフィールドは、オブジェクトのための最後のパケットが伝送される場合、１に設定されてもよい。また、Ｂフィールドは、オブジェクトのための最後の数秒のパケットが伝送される場合、１に設定されてもよい。放送伝送装置は、特定オブジェクトのためのパケットのＢフィールドが１に設定された場合、当該パケットに続くパケットの伝送が終了するまでＢフィールドを１に設定しなければならない。放送受信装置１００は、Ｂフィールドが１に設定されていると、放送伝送装置がオブジェクトのためのパケットの伝送を中断するはずであることが認識できる。言い換えると、放送受信装置１００は、１に設定されたＢフィールドから、セッションでそれ以上オブジェクトを伝送しないことと認識できる。一実施例で、Ｂフィールドは１ビットであってもよい。
【０４６３】
また、本発明の一実施例に係るパケットヘッダーは、ヘッダーの全長を示す情報を含むことができる。この情報はＨＤＲ＿ＬＥＮフィールドであってもよい。ＨＤＲ＿ＬＥＮフィールドは、３２の倍数ビットであってもよい。具体的な実施例で、ＨＤＲ＿ＬＥＮフィールドが５に設定された場合、パケットヘッダーの全長は３２の５倍数である１６０ビットであってもよい。また、ＨＤＲ＿ＬＥＮフィールドは８ビットであってもよい。
【０４６４】
また、本発明の一実施例に係るパケットヘッダーは、当該パケットに含まれたペイロードのエンコーディング又はデコーディングに関連した情報を含むことができる。この情報はＣｏｄｅｐｏｉｎｔフィールドであってもよい。一実施例で、Ｃｏｄｅｐｏｉｎｔフィールドは８ビットであってもよい。
【０４６５】
また、本発明の一実施例に係るパケットヘッダーは、混雑制御のための情報を含むことができる。この情報はＣｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ（以下、ＣＣＩ）フィールドであってもよい。具体的な実施例で、ＣＣＩフィールドは、Ｃｕｒｒｅｎｔ  ｔｉｍｅ  ｓｌｏｔ  ｉｎｄｅｘ（ＣＴＳＩ）フィールド、ｃｈａｎｎｅｌ  ｎｕｍｂｅｒフィールド及びｐａｃｋｅｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒフィールドのうち少なくとも一つを含むことができる。
【０４６６】
また、本発明の一実施例に係るパケットヘッダーは、伝送セッションの識別のための情報を含むことができる。上述した情報は、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＳＩ））であってもよい。また、ＴＳＩ情報を含むパケットヘッダー内フィールドはＴＳＩフィールドであってもよい。
【０４６７】
また、本発明の一実施例に係るパケットヘッダーは、伝送セッションで伝送されるオブジェクトの識別のための情報を含むことができる。この情報は、伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＯＩ））であってもよい。また、ＴＯＩ情報を含むパケットヘッダー内フィールドはＴＯＩフィールドであってもよい。
【０４６８】
また、本発明の一実施例に係るパケットヘッダーは、追加の情報を伝送するための情報を含むことができる。この情報は、Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎフィールドであってもよい。一実施例で、追加の情報は、伝送オブジェクトの再生に関連した時間情報であってもよい。他の実施例で、追加の情報は、伝送オブジェクトのデコーディングに関連した時間情報であってもよい。
【０４６９】
また、本発明の一実施例に係る伝送パケットは、ペイロード識別情報を含むことができる。一実施例で、識別情報は、ＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）スキームに関連したペイロード識別情報であってもよい。ここで、ＦＥＣは、ＲＦＣ５１０９に定義されているペイロードフォーマットの一類型である。ＦＥＣは、ＲＴＰ又はＳＲＴＰで用いられてもよい。この情報は、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドであってもよい。
【０４７０】
一実施例で、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドは、オブジェクトのソースブロックを識別するための情報を含むことができる。この情報は、Ｓｏｕｒｃｅ  ｂｌｏｃｋ  ｎｕｍｂｅｒフィールドであってもよい。例えば、Ｓｏｕｒｃｅ  ｂｌｏｃｋ  ｎｕｍｂｅｒフィールドがＮに設定されると、オブジェクト内ソースブロックは０からＮ−１までナンバリングされてもよい。
【０４７１】
他の実施例で、ＦＥＣ  Ｐａｙｌｏａｄ  ＩＤフィールドは、特定エンコーディングシンボルを識別するための情報を含むことができる。この情報は、Ｅｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ  ＩＤフィールドであってもよい。
【０４７２】
また、本発明の一実施例で、伝送パケットはペイロード内データを含むことができる。このデータを含んでいるフィールドは、Ｅｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールドであってもよい。一実施例で、放送受信装置１００は、Ｅｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールドを抽出してオブジェクトを再構成することができる。具体的に、パケットペイロードで伝送されるソースブロックからＥｎｃｏｄｉｎｇ  ｓｙｍｂｏｌ（ｓ）フィールド内データが生成されてもよい。
【０４７３】
図３６は、本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。具体的に、図３６は、本発明の一実施例に係るサービスシグナリングメッセージヘッダーのシンタクスを示すことができる。本発明の一実施例に係るサービスシグナリングメッセージは、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。このとき、シグナリングメッセージは、バイナリ又はＸＭＬフォーマットで表現することができる。また、サービスシグナリングメッセージは伝送プロトコルパケットのペイロードに含まれてもよい。
【０４７４】
図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージを識別する識別子情報を含むことができる。例えば、シグナリングメッセージはセクションの形態であってもよい。この場合、シグナリングメッセージの識別子情報は、シグナリングテーブルセクションの識別子（ＩＤ）を示すことができる。シグナリングメッセージの識別子情報を示すフィールドは、ｓｉｎｇｎａｌｉｎｇ＿ｉｄであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは８ビットであってもよい。
【０４７５】
また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの長さを示す長さ情報を含むことができる。シグナリングメッセージの長さ情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈフィールドは１２ビットであってもよい。
【０４７６】
また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの識別子を拡張する識別子拡張情報を含むことができる。このとき、識別子拡張情報は、シグナリング識別子情報と共にシグナリングを識別する情報であってもよい。シグナリングメッセージの識別子拡張情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎであってもよい。
【０４７７】
このとき、識別子拡張情報は、シグナリングメッセージのプロトコルバージョン情報を含むことができる。シグナリングメッセージのプロトコルバージョン情報を示すフィールドは、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎであってもよい。具体的な実施例で、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは８ビットであってもよい。
【０４７８】
また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのバージョン情報を含むことができる。シグナリングメッセージのバージョン情報は、シグナリングメッセージが含む内容が変更される度に変更されてもよい。シグナリングメッセージのバージョン情報を示すフィールドは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは５ビットであってもよい。
【０４７９】
また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージが現在利用可能なか否かを示す情報を含むことができる。シグナリングメッセージが利用可能か否かを示すフィールドは、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒであってもよい。具体的な例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが１である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、シグナリングメッセージが利用可能であることを示すことができる。他の例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが０である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドはシグナリングメッセージが利用不可であり、その後、同じシグナリング識別子情報、シグナリング識別子拡張情報又はフラグメントナンバー情報を含む他のシグナリングメッセージが利用可能であることを示すことができる。
【０４８０】
また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのフラグメント（Ｆｒａｇｍｅｎｔ）ナンバー情報を含むことができる。一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送されてもよい。したがって、受信機が分けられた複数のフラグメントを識別するための情報は、フラグメントナンバー情報であってもよい。フラグメントナンバー情報を示すフィールドは、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドであってもよい。具体的な実施例で、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。
【０４８１】
また、図３６の実施例に係るシグナリングメッセージヘッダーは、一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送される場合、最後のフラグメントのナンバー情報を含むことができる。例えば、最後のフラグメントナンバーに関する情報が３を示す場合、シグナリングメッセージが３個に分けられて伝送されることを示すことができる。また、３を示すフラグメントナンバーを含むフラグメントがシグナリングメッセージの最後のデータを含むことを示すことができる。最後のフラグメントのナンバー情報を示すフィールドは、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。
【０４８２】
図３７は、本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。具体的に、図３７は、本発明の一実施例に係るサービスシグナリングメッセージヘッダーのシンタクスを示すことができる。本発明の一実施例に係るサービスシグナリングメッセージは、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。このとき、シグナリングメッセージはバイナリ又はＸＭＬフォーマットで表現することができる。また、サービスシグナリングメッセージは、伝送プロトコルパケットのペイロードに含まれてもよい。
【０４８３】
図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージを識別する識別子情報を含むことができる。例えば、シグナリングメッセージがセクションの形態であってもよい。この場合、シグナリングメッセージの識別子情報は、シグナリングテーブルセクションの識別子（ＩＤ）を示すことができる。シグナリングメッセージの識別子情報を示すフィールドは、ｓｉｎｇｎａｌｉｎｇ＿ｉｄであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは８ビットであってもよい。
【０４８４】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの長さを示す長さ情報を含むことができる。シグナリングメッセージの長さ情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈフィールドは１２ビットであってもよい。
【０４８５】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの識別子を拡張する識別子拡張情報を含むことができる。このとき、識別子拡張情報は、シグナリング識別子情報と共にシグナリングを識別する情報であってもよい。シグナリングメッセージの識別子拡張情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎであってもよい。
【０４８６】
このとき、識別子拡張情報は、シグナリングメッセージのプロトコルバージョン情報を含むことができる。シグナリングメッセージのプロトコルバージョン情報を示すフィールドは、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎであってもよい。具体的な実施例で、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは８ビットであってもよい。
【０４８７】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのバージョン情報を含むことができる。シグナリングメッセージのバージョン情報は、シグナリングメッセージが含む内容が変更される度に変更されてもよい。シグナリングメッセージのバージョン情報を示すフィールドは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは５ビットであってもよい。
【０４８８】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージが現在利用可能なか否かを示す情報を含むことができる。シグナリングメッセージが利用可能か否かを示すフィールドは、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒであってもよい。具体的な例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが１である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、シグナリングメッセージが利用可能であることを示すことができる。他の例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが０である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、シグナリングメッセージが利用不可であり、その後、同じシグナリング識別子情報、シグナリング識別子拡張情報又はフラグメントナンバー情報を含む他のシグナリングメッセージが利用可能であることを示すことができる。
【０４８９】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、ペイロードに含まれるシグナリングメッセージのフォーマット情報を含むことができる。上述したように、シグナリングメッセージは、バイナリ又はＸＭＬフォーマットで表現することができる。また、シグナリングメッセージは、他のフォーマットで表現されてもよい。したがって、フォーマット情報は、ペイロードに含まれたシグナリングメッセージがいかなるフォーマットで作成されたかを示すことができ、その例として、ｂｉｎａｒｙ、ＸＭＬなどを挙げることができる。フォーマット情報を示すフィールドは、ｐａｙｌｏａｄ＿ｆｏｒｍａｔフィールドであってもよい。具体的な実施例で、ｐａｙｌｏａｄ＿ｆｏｒｍａｔフィールドは２ビットであってもよい。
【０４９０】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、ペイロードに含まれたシグナリングメッセージの有効時間情報を含むことができる。シグナリングメッセージの有効時間情報は、シグナリングメッセージがいつの時間まで有効であるかを示す情報を含むことができ、このフィールドで定義された時間の後には、当該シグナリングメッセージがそれ以上有効でなくてもよい。有効時間情報を示すフィールドは、ｅｘｐｉｒａｔｉｏｎフィールドであってもよい。具体的な実施例で、ｅｘｐｉｒａｔｉｏｎフィールドは３２ビットであってもよい。
【０４９１】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのフラグメント（Ｆｒａｇｍｅｎｔ）ナンバー情報を含むことができる。一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送されてもよい。したがって、受信機が分けられた複数のフラグメントを識別するための情報は、フラグメントナンバー情報であってもよい。フラグメントナンバー情報を示すフィールドは、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドであってもよい。具体的な実施例で、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。
【０４９２】
また、図３７の実施例に係るシグナリングメッセージヘッダーは、一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送される場合、最後のフラグメントのナンバー情報を含むことができる。例えば、最後のフラグメントナンバーに関する情報が３を示す場合、シグナリングメッセージが３個に分けられて伝送されることを示すことができる。また、３を示すフラグメントナンバーを含むフラグメントがシグナリングメッセージの最後のデータを含むことを示すことができる。最後のフラグメントのナンバー情報を示すフィールドは、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。
【０４９３】
図３８は、本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示している。一実施例に係る放送サービスシグナリングメッセージは、放送受信装置１００が次世代放送システムで放送サービス及びコンテンツのうち少なくとも一つを受信できるようにするための放送サービスシグナリング方法である。
【０４９４】
図３８の実施例に係る放送サービスシグナリング方法は、図３６に示すシグナリングメッセージ構成に基づいてもよい。図３８の実施例に係る放送サービスシグナリングメッセージは、サービスシグナリングチャネルで伝送することができる。このとき、サービスシグナリングチャネルは、放送サービススキャンのためのサービスシグナリング情報を他の層を経由しないで直接伝送するための物理層パイプの一形態を意味することができる。具体的な実施例で、サービスシグナリングチャネルは、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）、ＬＬＳ（Ｌｏｗ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）及びアプリケーション層伝送セッションの少なくとも一つを意味することができる。また、図３８の実施例に係る放送サービスシグナリングメッセージは、ＸＭＬの形態であってもよい。
【０４９５】
図３８の実施例に係るサービスシグナリングメッセージは、含んでいるサービスの個数情報を含むことができる。具体的に一つのサービスシグナリングメッセージは複数のサービスを含むことができ、含んでいるサービスの数を示す情報を含むことができる。サービスの個数情報は、ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドであってもよい。具体的な実施例で、ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは８ビットであってもよい。
【０４９６】
また、図３８の実施例に係るサービスシグナリングメッセージは、サービスに対する識別子情報を含むことができる。識別子情報は、ｓｅｒｖｉｃｅ＿ｉｄフィールドであってもよい。具体的な実施例で、ｓｅｒｖｉｃｅ＿ｉｄフィールドは１６ビットであってもよい。
【０４９７】
また、図３８の実施例に係るサービスシグナリングメッセージは、サービスのタイプ情報を含むことができる。サービスタイプ情報は、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドであってもよい。具体的な実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ００値を有する場合、シグナリングメッセージが示すサービスタイプはスケジュールドオーディオサービス（ｓｃｈｅｄｕｌｅｄ  ａｕｄｉｏ  ｓｅｒｖｉｃｅ）であってもよい。
【０４９８】
他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０１値を有する場合、シグナリングメッセージが示すサービスタイプは、スケジュールドオーディオ／ビデオサービス（ｓｃｈｅｄｕｌｅｄ  ａｕｄｉｏ／ｖｉｄｅｏ  ｓｅｒｖｉｃｅ）であってもよい。このとき、スケジュールドオーディオ／ビデオサービスは、あらかじめ定められたスケジュールによって放送されるオーディオ／ビデオサービスであってもよい。
【０４９９】
他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０２値を有する場合、シグナリングメッセージが示すサービスタイプは、オン−デマンドサービス（ｏｎ−ｄｅｍａｎｄ  ｓｅｒｖｉｃｅ）であってもよい。このとき、オン−デマンドサービスは、ユーザの要求によって再生されるオーディオ／ビデオサービスであってもよい。また、オン−デマンドサービスは、スケジュールドオーディオ／ビデオサービスと反対のサービスであってもよい。
【０５００】
他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０３値を有する場合、シグナリングメッセージが示すサービスタイプは、アプリベースのサービス（ａｐｐ−ｂａｓｅｄ  ｓｅｒｖｉｃｅ）であってもよい。このとき、アプリベースのサービスは、実時間放送サービスでなく非実時間サービスであり、アプリケーションによって提供されるサービスであってもよい。アプリベースのサービスは、実時間放送サービスに関連したサービス及び実時間放送サービスに関連していないサービスのうち少なくとも一つを含むことができる。放送受信装置１００は、アプリケーションをダウンロードしてアプリベースのサービスを提供することができる。
【０５０１】
他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０４値を有する場合、シグナリングメッセージが示すサービスタイプは、権利発給者サービス（ｒｉｇｈｔ  ｉｓｓｕｅｒ  ｓｅｒｖｉｃｅ）であってもよい。このとき、権利発給者サービスは、サービス提供を受ける権利が発給された者にのみ提供されるサービスであってもよい。
【０５０２】
他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０５値を有する場合、シグナリングメッセージが示すサービスタイプは、サービスガイドサービス（ｓｅｒｖｉｃｅ  ｇｕｉｄｅ  ｓｅｒｖｉｃｅ）であってもよい。このとき、サービスガイドサービスは、提供されるサービスの情報を提供するサービスであってもよい。例えば、提供されるサービスの情報は、放送スケジュールであってもよい。
【０５０３】
また、図３８の実施例に係るサービスシグナリングメッセージは、サービス名情報を含むことができる。サービス名情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドであってもよい。
【０５０４】
また、図３８の実施例に係るサービスシグナリングメッセージは、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドの長さ情報を含むことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドの長さ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドであってもよい。
【０５０５】
また、図３８の実施例に係るサービスシグナリングメッセージは、シグナルするサービスに関連した放送サービスチャネルナンバー情報を含むことができる。関連した放送サービスチャネルナンバー情報は、ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドであってもよい。
【０５０６】
また、図３８の実施例に係るサービスシグナリングメッセージは、以下に説明する各伝送モードによって、放送受信装置がタイムベース（ｔｉｍｅｂａｓｅ）又はシグナリングメッセージを取得するために必要なデータを含むことができる。タイムベース又はシグナリングメッセージを取得するためのデータは、ｂｏｏｔｓｔｒａｐ（）フィールドであってもよい。
【０５０７】
上述した伝送モードは、タイムベース伝送モード及びシグナリング伝送モードの少なくとも一つであってもよい。タイムベース伝送モードは、放送サービスで使用するタイムラインに対するメタデータを含むタイムベースに対する伝送モードであってもよい。タイムラインは、メディアコンテンツのための一連の時間情報である。具体的に、タイムラインは、メディアコンテンツ再生の基準となる一連の基準時間であってもよい。タイムベース伝送モードに関する情報は、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５０８】
また、シグナリング伝送モードは、放送サービスで使用するシグナリングメッセージを伝送するモードであってもよい。シグナリング伝送モードに関する情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５０９】
図３９は、本発明の一実施例に係るサービスシグナリングメッセージでｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが示す値が意味する内容を示している。
【０５１０】
タイムベース伝送モードは、放送受信装置１００が放送サービスのタイムベースを同一の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ００の値を有する場合、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送受信装置が放送サービスのタイムベースを同一の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。
【０５１１】
また、シグナリング伝送モードは、放送受信装置１００が放送サービスに用いるシグナリングメッセージを、同一の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。他の実施例によれば、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ００の値を有する場合、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送受信装置が放送サービスに用いるシグナリングメッセージを同一の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。同一の放送ストリームとは、放送受信装置が現在サービスシグナリングメッセージを受信した放送ストリームと同じ放送ストリームを意味することができる。また、ＩＰデータグラムは、放送サービス又はコンテンツを構成するコンポーネントをインターネットプロトコルによってカプセル化した一伝送単位を意味することができる。この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図示のシンタクスに従えばよい。図示のシンタクスは、ＸＭＬの形態で表現されてもよい。
【０５１２】
図４０は、本発明の一実施例でｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ００値を有する場合、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す。
【０５１３】
実施例で、ブートストラップ（ｂｏｏｔｓｔｒａｐ）データは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのＩＰアドレス形式に関する情報を含むことができる。ＩＰアドレス形式に関する情報は、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドであってもよい。ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ４であることを示すことができる。一実施例で、ＩＰアドレス形式に関する情報が０である場合、ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ４であることを示すことができる。ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ６であることを示すことができる。他の実施例で、ＩＰアドレス形式に関する情報が１である場合、ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ６であることを示すことができる。
【０５１４】
実施例で、ブートストラップ（ｂｏｏｔｓｔｒａｐ）データは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムがソースＩＰアドレスを含むか否かを示す情報を含むことができる。このとき、ソースＩＰアドレスは、ＩＰデータグラムの送信元（ｓｏｕｒｃｅ）アドレスであってもよい。ＩＰデータグラムがソースＩＰアドレスを含むか否かを示す情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１である場合、ＩＰデータグラムがソースＩＰアドレスを含むことを示すことができる。
【０５１５】
実施例で、ブートストラップデータはタイムベース又はシグナリングメッセージを含むＩＰデータグラムが送信先（ｄｅｓｔｉｎａｔｉｏｎ）ＩＰアドレスを含むか否かを示す情報を含むことができる。このとき、送信先ＩＰアドレスは、ＩＰデータグラムの送信先アドレスであってもよい。ＩＰデータグラムが送信先ＩＰアドレスを含むか否かを示す情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドが１である場合、ＩＰデータグラムが送信先ＩＰアドレスを含むことを示すことができる。
【０５１６】
実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのソースＩＰアドレス情報を含むことができる。ソースＩＰアドレス情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。
【０５１７】
図３９に係る実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムの送信先ＩＰアドレス情報を含むことができる。送信先ＩＰアドレス情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。
【０５１８】
実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのフローポートの個数情報を含むことができる。このとき、ポート（ｐｏｒｔ）は、ＩＰデータグラムのフローを受信するための通路であってもよい。ＩＰデータグラムのＵＤＰ（ｕｓｅｒ  ｄａｔａｇｒａｍ  ｐｒｏｔｏｃｏｌ）ポートの個数を示す情報は、ｐｏｒｔ＿ｎｕｍ＿ｃｏｕｎｔフィールドであってもよい。
【０５１９】
実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのＵＤＰ（ｕｓｅｒ  ｄａｔａｇｒａｍ  ｐｒｏｔｏｃｏｌ）ポート番号を示す情報を含むことができる。ユーザデータグラムプロトコル（ＵＤＰ）は、インターネットで情報を授受するとき、交換する形式ではなく片方から一方的に送る方式の通信プロトコルである。
【０５２０】
再び図３９を参照する。
【０５２１】
タイムベース伝送モードは、放送受信装置１００が放送サービスのタイムベースを別の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０１の値を有する場合、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送サービスのタイムベースを別の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。別の放送ストリームは、現在サービスシグナリングメッセージを受信した放送ストリームと異なる放送ストリームを意味することができる。
【０５２２】
また、シグナリング伝送モードは、放送受信装置１００が放送サービスに用いるシグナリングメッセージを、別の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。他の実施例によれば、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０１の値を有する場合、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送サービスに用いるシグナリングメッセージを別の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４１に示すシンタクスを従えばよい。図４１に示すシンタクスはＸＭＬの形態で表現されてもよい。
【０５２３】
図４１の実施例に係るブートストラップデータは、シグナリングメッセージを伝送する放送局の識別子情報を含むことができる。具体的に、ブートストラップデータは、特定の周波数又は伝送フレームでシグナリングメッセージを伝送する特定の放送局固有の識別子情報を含むことができる。放送局の識別子情報は、ｂｒｏａｄｃａｓｔｉｎｇ＿ｉｄフィールドであってもよい。また、放送局の識別子情報は、放送サービスを送信する伝送ストリームの識別子情報であってもよい。
【０５２４】
再び図３９を参照する。
【０５２５】
タイムベース伝送モードは、放送受信装置１００が同一の放送ストリーム内のセッションベースフローを通じてタイムベースを取得するモードを含むことができる。
【０５２６】
図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０２の値を有する場合、放送サービスのタイムベースを同一の放送ストリーム内のセッションベースフローを通じて取得できることを示すことができる。これに加えて、シグナリング伝送モードは、放送受信装置１００が同一の放送ストリーム内のセッションベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０２の値を有する場合、放送サービスに用いるシグナリングメッセージを同一の放送ストリーム内のアプリケーション層伝送セッションベースフローを通じて取得できることを示すことができる。このとき、アプリケーション層伝送セッションベースフローは、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ）／ＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッション及びＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）セッションのいずれか一つであってもよい。
【０５２７】
この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４２に示すシンタクスに従えばよい。図４２に示すシンタクスは、ＸＭＬの形態で表現されてもよい。
【０５２８】
図４２の実施例に係るブートストラップデータは、タイムベース又はシグナリングメッセージを含むアプリケーション層伝送パケットを伝送するアプリケーション層伝送セッションの識別子（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）情報を含むことができる。このとき、伝送パケットを伝送するセッションは、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションのいずれか一つであってもよい。アプリケーション層伝送セッションの識別子情報は、ｔｓｉフィールドであってもよい。
【０５２９】
再び図３９を参照する。
【０５３０】
タイムベース伝送モードは、放送受信装置１００が別の放送ストリーム内のセッションベースフローを通じてタイムベースを取得するモードを含むことができる。図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０３の値を有する場合、放送サービスのタイムベースを別の放送ストリーム内のセッションベースフローを通じて取得できることを示すことができる。これに加えて、シグナリング伝送モードは、放送受信装置１００が同一の放送ストリーム内のセッションベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０３の値を有する場合、放送サービスに用いるシグナリングメッセージを別の放送ストリーム内のアプリケーション層伝送セッションベースフローを通じて取得できることを示すことができる。このとき、アプリケーション層伝送セッションベースフローは、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ）／ＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッション及びＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）セッションの少なくとも一つであってもよい。
【０５３１】
この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４３に示すシンタクスに従えばよい。図４３に示すシンタクスは、ＸＭＬの形態で表現されてもよい。
【０５３２】
図４３の実施例に係るブートストラップデータは、シグナリングメッセージを伝送する放送局の識別子情報を含むことができる。具体的に、ブートストラップデータは、特定の周波数又は伝送フレームでシグナリングメッセージを伝送する特定の放送局固有の識別子情報を含むことができる。放送局の識別子情報は、ｂｒｏａｄｃａｓｔｉｎｇ＿ｉｄフィールドであってもよい。また、放送局の識別子情報は、放送サービスの伝送ストリームの識別子情報であってもよい。
【０５３３】
再び図３９を参照する。
【０５３４】
タイムベース伝送モードは、放送受信装置１００が同一の放送ストリーム内のパケットベースフローを通じてタイムベースを取得するモードを含むことができる。図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０４の値を有する場合、放送サービスのタイムベースを同一の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＰＥＧメディア伝送（ＭＰＥＧ  Ｍｅｄｉａ  Ｔａｎｓｐｏｒｔ；ＭＭＴ）パケットフローであってもよい。
【０５３５】
これに加えて、シグナリング伝送モードは、放送受信装置１００が同一の放送ストリーム内のパケットベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０４の値を有する場合、放送サービスに用いるシグナリングメッセージを同一の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＭＴパケットフローであってもよい。
【０５３６】
この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４４に示すシンタクスに従えばよい。図４４に示すシンタクスは、ＸＭＬの形態で表現されてもよい。
【０５３７】
図４４の実施例に係るブートストラップデータは、タイムベース又はシグナリングメッセージを伝送する伝送パケットの識別子情報を含むことができる。伝送パケットの識別子情報は、ｐａｃｋｅｔ＿ｉｄフィールドであってもよい。伝送パケットの識別子情報は、ＭＰＥＧ−２伝送ストリームの識別子情報であってもよい。
【０５３８】
再び図３９を参照する。
【０５３９】
タイムベース伝送モードは、放送受信装置１００が別の放送ストリーム内のパケットベースフローを通じてタイムベースを取得するモードを含むことができる。
【０５４０】
図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０５の値を有する場合、放送サービスのタイムベースを別の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＰＥＧメディア伝送パケットフローであってもよい。
【０５４１】
これに加えて、シグナリング伝送モードは、放送受信装置１００が別の放送ストリーム内のパケットベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０５の値を有する場合、放送サービスに用いるシグナリングメッセージを別の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＭＴパケットフローであってもよい。
【０５４２】
この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４５に示すシンタクスに従えばよい。図４５に示すシンタクスは、ＸＭＬの形態で表現されてもよい。
【０５４３】
図４５の実施例に係るブートストラップデータは、シグナリングメッセージを伝送する放送局の識別子情報を含むことができる。具体的に、ブートストラップデータは、特定の周波数又は伝送フレームでシグナリングメッセージを伝送する特定の放送局固有の識別子情報を含むことができる。放送局の識別子情報はｂｒｏａｄｃａｓｔｉｎｇ＿ｉｄフィールドであってもよい。また、放送局の識別子情報は、放送サービスの伝送ストリームの識別子情報であってもよい。
【０５４４】
また、図４５の実施例に係るブートストラップデータは、タイムベース又はシグナリングメッセージを伝送する伝送パケットの識別子情報を含むことができる。伝送パケットの識別子情報はｐａｃｋｅｔ＿ｉｄフィールドであってもよい。伝送パケットの識別子情報はＭＰＥＧ−２伝送ストリームの識別子情報であってもよい。
【０５４５】
再び図３９を参照する。
【０５４６】
タイムベース伝送モードは、放送受信装置１００がタイムベースをＵＲＬを通じて取得するモードを含むことができる。
【０５４７】
図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０６の値を有する場合、放送サービスのタイムベースをＵＲＬを通じて取得できることを示すことができる。これに加えて、シグナリング伝送モードは、放送受信装置１００がシグナリングメッセージをＵＲＬを通じて取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０６の値を有する場合、放送サービスに用いるシグナリングメッセージを受信可能なアドレスを識別する識別子を用いて取得できることを示すことができる。このとき、放送サービスに用いるシグナリングメッセージを受信可能なアドレスを識別する識別子は、ＵＲＬであってもよい。
【０５４８】
この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４６に示すシンタクスに従えばよい。図４６に示すシンタクスは、ＸＭＬの形態で表現されてもよい。
【０５４９】
図４６の実施例に係るブートストラップデータは、放送サービスのタイムベース又はシグナリングメッセージをダウンロード可能なＵＲＬに関する長さ情報を含むことができる。ＵＲＬの長さ情報は、ＵＲＬ＿ｌｅｎｇｔｈフィールドであってもよい。
【０５５０】
また、図４６の実施例に係るブートストラップデータは、放送サービスのタイムベース又はシグナリングメッセージをダウンロード可能なＵＲＬの実際データを含むことができる。ＵＲＬの実際データは、ＵＲＬ＿ｃｈａｒフィールドであってもよい。
【０５５１】
図４７は、図３８乃至図４６の実施例でタイムベース及びサービスシグナリングメッセージを取得する手順を示す。
【０５５２】
図４７に示すように、本発明の一実施例に係る放送受信装置１００は、パケットベース伝送プロトコルによってタイムベースを取得することができる。具体的に、放送受信装置１００は、サービスシグナリングメッセージを用いてＩＰ／ＵＤＰフローを通じてタイムベースを取得することができる。また、本発明の一実施例に係る放送受信装置１００は、セッションベース伝送プロトコルによってサービス関連シグナリングメッセージを取得することができる。具体的に、放送受信装置１００は、ＡＬＣ／ＬＣＴ伝送セッションでサービス関連シグナリングメッセージを取得することができる。
【０５５３】
図４８は、本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示している。一実施例に係る放送サービスシグナリングメッセージは、放送受信装置が次世代放送システムで放送サービス及びコンテンツを受信できるようにするためのサービスシグナリング方法である。実施例に係る放送サービスシグナリング方法は、前述したシグナリングメッセージ構成に基づいてもよい。実施例に係る放送サービスシグナリングメッセージは、サービスシグナリングチャネルで伝送されてもよい。このとき、サービスシグナリングチャネルは、放送サービススキャンのためのサービスシグナリング情報を他の層を経由しないで直接伝送するための物理層パイプの一形態を意味することができる。
【０５５４】
具体的な実施例で、シグナリングチャネルは、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）、ＬＬＳ（Ｌｏｗ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）、及びアプリケーション伝送セッションの少なくとも一つであってもよい。また、実施例に係る放送サービスシグナリングメッセージは、ＸＭＬの形態で表現されてもよい。
【０５５５】
図４８の実施例に係るサービスシグナリングメッセージは、タイムベースを取得するために必要な情報をサービスシグナリングメッセージが含んでいるか否かを示す情報を含むことができる。このとき、タイムベースは、放送サービスに使用するタイムラインに対するメタデータを含むことができる。タイムラインは、メディアコンテンツのための一連の時間情報である。タイムベース取得のための情報を含んでいるか否かを示す情報は、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、サービスシグナリングメッセージがタイムベース伝送のための情報を含んでいることを示すことができる。
【０５５６】
図４８の実施例に係るサービスシグナリングメッセージは、以下に説明する各伝送モードによって、放送受信装置がタイムベース（ｔｉｍｅｂａｓｅ）又はシグナリングメッセージを取得するために必要なデータを含むことができる。タイムベース又はシグナリングメッセージを取得するためのデータは、ｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）フィールドであってもよい。
【０５５７】
上述した伝送モードは、タイムベース伝送モード及びシグナリング伝送モードの少なくとも一つであってもよい。タイムベース伝送モードは、放送サービスで使用するタイムラインに対するメタデータを含むタイムベースに対する伝送モードであってもよい。タイムベース伝送モードに関する情報は、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５５８】
また、シグナリング伝送モードは、放送サービスで使用するシグナリングメッセージを伝送するモードであってもよい。シグナリング伝送モードに関する情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５５９】
また、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドによるｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）フィールドの意味は、上述した内容のとおりである。
【０５６０】
図４９は、本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示している。一実施例に係る放送サービスシグナリングメッセージは、放送受信装置が次世代放送システムで放送サービス及びコンテンツを受信するできるようにするためのサービスシグナリング方法である。実施例に係る放送サービスシグナリング方法は、前述したシグナリングメッセージ構成に基づいてもよい。実施例に係る放送サービスシグナリングメッセージは、サービスシグナリングチャネルで伝送されてもよい。このとき、サービスシグナリングチャネルは、放送サービススキャンのためのサービスシグナリング情報を他の層を経由しないで直接伝送するための物理層パイプ形態であってもよい。具体的な実施例で、シグナリングチャネルは、ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）、ＬＬＳ（Ｌｏｗ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）、及びアプリケーション層伝送セッションの少なくとも一つであってもよい。また、図４８の実施例に係る放送サービスシグナリングメッセージは、ＸＭＬの形態で表現されてもよい。
【０５６１】
実施例に係るサービスシグナリングメッセージは、タイムベースを取得するために必要な情報をサービスシグナリングメッセージが含んでいるか否かを示すことができる。このとき、タイムベースは、放送サービスに使用するタイムラインに対するメタデータを含むことができる。タイムラインは、メディアコンテンツのための一連の時間情報である。タイムベース取得のための情報を含んでいるか否かを示す情報は、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、サービスシグナリングメッセージがタイムベース伝送のための情報を含んでいることを示すことができる。
【０５６２】
また、実施例に係るサービスシグナリングメッセージは、シグナリングメッセージを取得するために必要な情報をサービスシグナリングメッセージが含んでいるか否かを示すことができる。このとき、シグナリングメッセージは、放送サービスで使用するＭＰＤ（ｍｅｄｉａ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄａｔａ）又はＭＰＤ  ＵＲＬに関連したシグナリングメッセージであってもよい。シグナリングメッセージの取得のための情報を含んでいるか否かを示す情報は、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、サービスシグナリングメッセージがＭＰＤ又はＭＰＤ  ＵＲＬ関連シグナリングメッセージ伝送関連情報を含んでいることを示すことができる。ＨＴＴＰに基づく適応型メディアストリーミングをＤＡＳＨ（Ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）と呼ぶことができる。そして、適応型メディアストリーミングで放送サービス及びコンテンツを構成するセグメントを放送受信装置が取得するための詳細情報を、ＭＰＤと呼ぶことができる。ＭＰＤはＸＭＬ形態で表現されてもよい。ＭＰＤ  ＵＲＬ関連シグナリングメッセージは、ＭＰＤを取得できるアドレス情報を含むことができる。
【０５６３】
また、実施例に係るサービスシグナリングメッセージは、コンポーネントデータに対する取得経路情報をサービスシグナリングメッセージが含んでいるか否かを示すことができる。このとき、コンポーネントは、放送サービスを提供するためのコンテンツデータに対する一単位であってもよい。コンポーネントデータに対する取得経路情報を含んでいるか否かを示す情報は、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドは、サービスシグナリングメッセージがコンポーネントデータに対する取得経路情報を含んでいることを示すことができる。
【０５６４】
また、実施例に係るサービスシグナリングメッセージは、アプリケーション関連シグナリングメッセージを取得するために必要な情報を含んでいるか否かを示すことができる。アプリケーション関連シグナリングメッセージを取得するために必要な情報を含んでいるか否かを示す情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドは、サービスシグナリングメッセージがコンポーネントデータに対する取得経路情報を含んでいることを示すことができる。
【０５６５】
また、実施例に係るサービスシグナリングメッセージは、シグナリングメッセージ伝送関連情報を含んでいるか否かを示すことができる。シグナリングメッセージ伝送関連情報を含んでいるか否かを示す情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドは、サービスシグナリングメッセージがシグナリングメッセージ伝送関連情報を含んでいることを示すことができる。そして、サービスシグナリングメッセージが上述したＭＰＤ関連シグナリング、コンポーネント取得経路情報及びアプリケーション関連シグナリング情報を含んでいない場合、放送受信装置は、シグナリングメッセージ伝送経路を通じてＭＰＤ関連シグナリング、コンポーネント取得経路情報及びアプリケーション関連シグナリング情報を取得することができる。
【０５６６】
実施例に係るサービスシグナリングメッセージは、放送サービスで使用するタイムベースを送信するモードを示すことができる。タイムベースを送信するモードに関する情報は、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５６７】
実施例に係るサービスシグナリングメッセージは、放送サービスで使用するＭＰＤ又はＭＰＤ  ＵＲＬ関連シグナリングメッセージを伝送するモードを示すことができる。ＭＰＤ又はＭＰＤ  ＵＲＬ関連シグナリングメッセージを伝送するモードに関する情報は、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５６８】
実施例に係るサービスシグナリングメッセージは、放送サービスで使用するコンポーネントデータの取得経路を含むコンポーネントロケーションシグナリングメッセージを伝送するモードを示すことができる。コンポーネントデータの取得経路を含むコンポーネントロケーションシグナリングメッセージを伝送するモードに関する情報は、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５６９】
実施例に係るサービスシグナリングメッセージは、放送サービスで使用するアプリケーション関連シグナリングメッセージを伝送するモードを示すことができる。アプリケーション関連シグナリングメッセージを伝送するモードに関する情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５７０】
実施例に係るサービスシグナリングメッセージは、放送サービスで使用するサービス関連シグナリングメッセージを伝送するモードを示すことができる。サービス関連シグナリングメッセージを伝送するモードに関する情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。
【０５７１】
上述したｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが有する値による意味を説明する。
【０５７２】
図５０は、前述したそれぞれの伝送モードが有する値による意味を示す。Ｘ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅは、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅを含むことができる。それぞれの伝送モードが有する値の具体的な意味は、前述したとおりである。
【０５７３】
図４９の実施例に係るサービスシグナリングメッセージは、図５０のそれぞれのモードが有する値によって、放送受信装置がタイムベース又はシグナリングメッセージを取得するために必要な情報を含むことができる。タイムベース又はシグナリングメッセージの取得に必要な情報は、ｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）フィールドであってもよい。具体的に、ｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）に含まれた情報は、上述したとおりである。
【０５７４】
図５１は、次世代放送システムで放送サービスのコンポーネントデータ取得経路をシグナルするシグナリングメッセージの構成を示している。次世代放送システムで１つの放送サービスは、１つ以上のコンポーネントで構成することができる。実施例に係るシグナリングメッセージに基づいて、放送受信装置は、放送ストリームでコンポーネントデータ及び関連アプリケーションの取得経路に関する情報を取得することができる。このとき、実施例に係るシグナリングメッセージは、ＸＭＬの形態で表現することもできる。
【０５７５】
実施例に係るシグナリングメッセージは、シグナリングメッセージがコンポーネントロケーションをシグナルするメッセージであることを識別するための情報を含むことができる。シグナリングメッセージがコンポーネントロケーションをシグナルするメッセージであることを識別するための情報は、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは８ビットであってもよい。
【０５７６】
また、実施例に係るシグナリングメッセージは、シグナリングメッセージがコンポーネントロケーションをシグナルするメッセージであることを識別する拡張情報を含むことができる。このとき、拡張情報は、コンポーネントロケーションをシグナルするメッセージのプロトコルバージョンを含むことができる。拡張情報は、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドであってもよい。
【０５７７】
また、図５０の実施例に係るシグナリングメッセージは、コンポーネントロケーションをシグナルするメッセージのバージョン情報を含むことができる。このとき、バージョン情報は、コンポーネントロケーションをシグナルするメッセージの内容が変更されたことを示すことができる。バージョン情報は、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドであってもよい。
【０５７８】
また、実施例に係るシグナリングメッセージは、関連した放送サービスの識別子情報を含むことができる。このとき、関連放送サービスの識別子情報は、ｓｅｒｖｉｃｅ＿ｉｄフィールドであってもよい。
【０５７９】
また、実施例に係るシグナリングメッセージは、放送サービスに関連したコンポーネントの個数を含むことができる。このとき、関連したコンポーネントの個数情報は、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔフィールドであってもよい。
【０５８０】
また、実施例に係るシグナリングメッセージは、各コンポーネントの識別子を含むことができる。例えば、コンポーネント識別子は、ＭＰＥＧ  ＤＡＳＨのＭＰＤ＠ｉｄ、ｐｅｒｉｏｄ＠ｉｄ及びｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄを組み合わせて構成することができる。このとき、各コンポーネントの識別子情報は、ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールドであってもよい。
【０５８１】
また、実施例に係るシグナリングメッセージは、ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールドの長さを含むことができる。このとき、ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールドの長さ情報は、ｃｏｍｐｏｎｅｎｔ＿ｉｄ＿ｌｅｎｇｔｈフィールドであってもよい。
【０５８２】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを取得可能な周波数を示す周波数情報を含むことができる。コンポーネントデータは、ＤＡＳＨセグメントを含むことができる。このとき、コンポーネントデータを取得可能な周波数情報は、ｆｒｅｑｕｅｎｃｙ＿ｎｕｍｂｅｒフィールドであってもよい。
【０５８３】
また、実施例に係るシグナリングメッセージは、放送局固有の識別子を含むことができる。放送局は、特定の周波数又は伝送される伝送フレームでコンポーネントデータを伝送することができる。このとき、放送局固有の識別子情報は、ｂｒｏａｄｃａｓｔ＿ｉｄフィールドであってもよい。
【０５８４】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを送信する物理層パイプの識別子を含むことができる。このとき、コンポーネントデータを送信する物理層パイプの識別子情報は、ｄａｔａｐｉｐｅ＿ｉｄフィールドであってもよい。
【０５８５】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムのＩＰアドレス形式を含むことができる。このとき、ＩＰデータグラムのＩＰアドレス形式情報は、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドであってもよい。具体的な実施例で、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド値が０である場合、ＩＰｖ４形式を示し、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドが１である場合、ＩＰｖ６形式を示すことができる。
【０５８６】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムがソースＩＰアドレスを含むか否かに関する情報を含むことができる。ＩＰデータグラムがソースＩＰアドレスを含むか否かに関する情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、ＩＰデータグラムがソースＩＰアドレスを含むことを示す。
【０５８７】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報を含むことができる。ＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、ＩＰデータグラムが送信先ＩＰアドレスを含むことを示す。
【０５８８】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムのソースＩＰアドレス情報を含むことができる。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、シグナリングメッセージはソースＩＰアドレス情報を含むことができる。ソースＩＰアドレス情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。
【０５８９】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムの送信先ＩＰアドレス情報を含むことができる。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、シグナリングメッセージは送信先ＩＰアドレス情報を含むことができる。送信先ＩＰアドレス情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。
【０５９０】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムのＵＤＰポート番号情報を含むことができる。ＵＤＰポート番号情報は、ＵＤＰ＿ｐｏｒｔ＿ｎｕｍフィールドであってもよい。
【０５９１】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含む伝送パケットを伝送するアプリケーション層伝送セッションの識別子（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）情報を含むことができる。伝送パケットを伝送するセッションは、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションの少なくとも一つであってもよい。セッションの識別子情報は、ｔｓｉフィールドであってもよい。
【０５９２】
また、実施例に係るシグナリングメッセージは、コンポーネントデータを含む伝送パケットの識別子情報を含むことができる。伝送パケットの識別子情報は、ｐａｃｋｅｔ＿ｉｄフィールドであってもよい。
【０５９３】
また、実施例に係るシグナリングメッセージは、放送サービスに関連したアプリケーションシグナリングメッセージの個数を含むことができる。このとき、放送サービスは、ｓｅｒｖｉｃｅ＿ｉｄフィールドによって識別された放送サービスであってもよい。アプリケーションシグナリングメッセージの個数情報は、ｎｕｍ＿ａｐｐ＿ｓｉｇｎａｌｉｎｇフィールドであってもよい。
【０５９４】
また、実施例に係るシグナリングメッセージは、アプリケーションシグナリングメッセージの識別子情報を含むことができる。アプリケーションシグナリングメッセージの識別子情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドであってもよい。
【０５９５】
また、実施例に係るシグナリングメッセージは、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドの長さ情報を含むことができる。ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドの長さ情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｌｅｎｇｔｈフィールドであってもよい。
【０５９６】
また、実施例に係るシグナリングメッセージは、アプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータを含むことができる。アプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションの取得のための経路情報は、ａｐｐ＿ｄｅｌｉｖｅｒｙ＿ｉｎｆｏ（）フィールドであってもよい。
【０５９７】
図５２は、本発明の一実施例に係るａｐｐ＿ｄｅｌｉｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す。
【０５９８】
実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータが別の放送ストリームで伝送されるか否かに関する情報を含むことができる。アプリケーション又は関連したデータが別の放送ストリームで伝送されるか否かに関する情報は、ｂｒｏａｄｃａｓｔｉｎｇ＿ｆｌａｇフィールドであってもよい。
【０５９９】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムのＩＰアドレス形式を含むことができる。ＩＰデータグラムのＩＰアドレス形式の情報は、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドであってもよい。一実施例で、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドが０である場合、アプリケーション又は関連したデータを含むＩＰデータグラムはＩＰｖ４形式を用いることを示し、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドが１である場合、アプリケーション又は関連したデータを含むＩＰデータグラムはＩＰｖ６形式を用いることを示すことができる。
【０６００】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムがソースＩＰアドレスを含むか否かを示すことができる。このとき、関連したデータは、アプリケーションの実行に必要なデータであってもよい。
【０６０１】
アプリケーション又は関連したデータを含むＩＰデータグラムがソースＩＰアドレスを含むか否かに関する情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１である場合、ＩＰデータグラムがソースＩＰアドレスを含んでいることを示すことができる。
【０６０２】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報を含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１である場合、ＩＰデータグラムが送信先ＩＰアドレスを含んでいることを示すことができる。
【０６０３】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、特定の周波数又は伝送される伝送フレームでアプリケーション又は関連したデータを送信する放送局固有の識別子を含むことができる。
【０６０４】
言い換えると、アプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、放送サービス伝送ストリームの識別子を含むことができる。特定の周波数又は伝送される伝送フレームでアプリケーション又は関連したデータを送信する放送局固有の識別子情報は、ｂｒｏａｄｃａｓｔ＿ｉｄフィールドであってもよい。
【０６０５】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、アプリケーション又は関連したデータを含むＩＰデータグラムのソースＩＰアドレスを含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムのソースＩＰアドレス情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。
【０６０６】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、アプリケーション又は関連したデータを含むＩＰデータグラムの送信先ＩＰアドレスを含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムの送信先ＩＰアドレス情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。
【０６０７】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムフローのポートの個数を含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムフローのポートの個数情報は、ｐｏｒｔ＿ｎｕｍ＿ｃｏｕｎｔフィールドであってもよい。
【０６０８】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムＵＤＰポート番号を含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムＵＤＰポート番号情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ＿ｎｕｍｂｅｒフィールドであってもよい。
【０６０９】
また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを送信する伝送セッションの識別子を含むことができる。アプリケーション又は関連したデータを送信する伝送セッションは、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションのいずれか一つであってもよい。アプリケーション又は関連したデータを送信する伝送セッションの識別子情報は、ｔｓｉフィールドであってもよい。
【０６１０】
図５３は、本発明の他の実施例に係るａｐｐ＿ｄｅｌｉｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す。
【０６１１】
実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを送信する伝送パケットの識別子を示すことができる。アプリケーション又は関連したデータを送信する伝送パケットは、パケットベース伝送フローに基づくプロトコルに従えばよ  い。例えば、パケットベース伝送フローは、ＭＰＥＧメディア伝送プロトコル（ＭＰＥＧ  Ｍｅｄｉａ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）を含むことができる。アプリケーション又は関連したデータを送信する伝送パケットの識別子情報は、ｐａｃｋｅｔ＿ｉｄフィールドであってもよい。
【０６１２】
図５４は、放送サービスを構成する１つ以上のコンポーネントデータを取得できる経路情報を含むコンポーネントロケーションシグナリングを示す。具体的に、図５４は、放送サービスを構成する１つ以上のコンポーネントがＭＰＥＧ  ＤＡＳＨのセグメントで表現される場合、ＤＡＳＨセグメントを含むコンポーネントデータを取得できる経路情報を示す。
【０６１３】
図５５は、図５４のコンポーネントロケーションシグナリングの構成を示す図である。
【０６１４】
実施例に係るコンポーネントロケーションシグナリングは、放送サービスに関連したＭＰＥＧ  ＤＡＳＨ  ＭＰＤの識別子情報を含むことができる。ＭＰＥＧ  ＤＡＳＨ  ＭＰＤの識別子情報は、ｍｐｄｉｐフィールドであってもよい。
【０６１５】
また、実施例に係るコンポーネントロケーションシグナリングは、ｍｐｄｉｐフィールドが示すＭＰＥＧ  ＤＡＳＨ  ＭＰＤ内の周期（ｐｅｒｉｏｄ）属性（ａｔｔｒｉｂｕｔｅｓ）の識別子を含むことができる。ＭＰＥＧ  ＤＡＳＨ  ＭＰＤ内の周期（ｐｅｒｉｏｄ）属性の識別子情報は、ｐｅｒｉｏｄｉｄフィールドであってもよい。
【０６１６】
また、実施例に係るコンポーネントロケーションシグナリングは、ｐｅｒｉｏｄｉｄフィールドが示す周期内の再生（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）属性の識別子を含むことができる。周期内の再生（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）属性の識別子情報は、ＲｅｐｔｎＩＤフィールドであってもよい。
【０６１７】
また、実施例に係るコンポーネントロケーションシグナリングは、ＲｅｐｔｎＩＤフィールドが示す周期内の再生属性に含まれたＤＡＳＨセグメントを取得できる周波数ナンバーを含むことができる。ＤＡＳＨセグメントを取得できる周波数ナンバーは、ＲＦチャネルナンバーであってもよい。ＤＡＳＨセグメントを取得できる周波数ナンバー情報は、ＲＦＣｈａｎフィールドであってもよい。
【０６１８】
また、実施例に係るコンポーネントロケーションシグナリングは、特定の周波数又は伝送される伝送フレームでＤＡＳＨセグメントを送信する放送局固有の識別子を含むことができる。ＤＡＳＨセグメントを送信する放送局固有の識別子情報は、Ｂｒｏａｄｃａｓｔｉｎｇｉｄフィールドであってもよい。
【０６１９】
また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを伝達する物理層パイプの識別子を含むことができる。物理層パイプは、物理層で伝送されるデータパイプであってもよい。ＤＡＳＨセグメントを伝達する物理層パイプの識別子情報は、ＤａｔａＰｉｐｅＩｄフィールドであってもよい。
【０６２０】
また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含むＩＰデータグラムの送信先ＩＰアドレスを含むことができる。ＤＡＳＨセグメントを含むＩＰデータグラムの送信先ＩＰアドレス情報は、ＩＰＡｄｄフィールドであってもよい。
【０６２１】
また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含むＩＰデータグラムのＵＤＰポート番号を含むことができる。ＤＡＳＨセグメントを含むＩＰデータグラムのＵＤＰポート番号情報は、ＵＤＰＰｏｒｔフィールドであってもよい。
【０６２２】
また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含む伝送パケットを伝送するセッションの識別子（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）を含むことができる。伝送パケットを伝送するセッションの識別子は、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションの少なくとも一つであってもよい。伝送パケットを伝送するセッションの識別子情報は、ＴＳＩフィールドであってもよい。
【０６２３】
また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含む伝送パケットの識別子を含むことができる。伝送パケットの識別子情報は、ＰａｃｋｅｔＩｄフィールドであってもよい。
【０６２４】
図５６は、本発明の一実施例において次世代放送システムで放送サービスのサービスに対するシグナリングが含む他の情報を示している。サービスに対するシグナリングは、サービス識別子（ｉｄ）、サービスタイプ、サービスネーム、チャネルナンバー、タイムベースロケーション、デリバリモード、ブートストラップインフォ、ＭＰＤ、ＭＰＤシグナリングロケーション、コンポーネントシグナリングロケーション、アプリシグナリングロケーション、及び／又はオブジェクトフローに関する情報を含むことができる。
【０６２５】
サービス識別子は、サービスを識別する情報を示すことができ、ｉｄ属性で表現されてもよい。
【０６２６】
サービスタイプ情報は、サービスのタイプを示す情報であって、ｓｅｒｖｉｃｅＴｙｐｅ属性で表現されてもよい。
【０６２７】
サービスネーム情報は、サービス名を示す情報であって、ｓｅｒｖｉｃｅＮａｍｅ属性で表現されてもよい。
【０６２８】
チャネルナンバー情報は、サービスに関連したチャネルナンバーを示す情報であって、ｃｈａｎｎｅｌＮｕｍｂｅｒ属性で表現されてもよい。
【０６２９】
タイムベースロケーション情報は、タイムベースを取得できる位置を示す情報であって、ＴｉｍｅｂａｓｅＬｏｃａｔｉｏｎエレメントで表現されてもよい。ここで、タイムベースは、サービスに含まれたコンポーネントを同期化するためのタイムラインを設定するためのメタデータを示す情報を意味することができる
【０６３０】
タイムベースロケーション情報に含まれたデリバリモード情報は、タイムベースの伝送モードを示すことができる。
【０６３１】
タイムベースロケーション情報に含まれたブートストラップインフォ情報は、上記デリバリモードによるタイムベースのブートストラップ情報を含むことができる。
【０６３２】
ＭＰＤは、サービスに関連したＭＰＤを示すことができる。
【０６３３】
ＭＰＤシグナリングロケーション情報は、ＭＰＤ又はＭＰＤ  ＵＲＬに関連したシグナリングを取得できる位置を示すことができる。
【０６３４】
ＭＰＤシグナリングロケーションに含まれたデリバリモード情報は、ＭＰＤロケーションシグナリングの伝送モードを示すことができる。
【０６３５】
ＭＰＤシグナリングロケーションに含まれたブートストラップインフォ情報は、上記伝送モードによるＭＰＤ又はＭＰＤ  ＵＲＬのブートストラップ情報を含むことができる。
【０６３６】
コンポーネントシグナリングロケーション情報は、サービスに関連したコンポーネントロケーションシグナリング情報を示すことができる。
【０６３７】
コンポーネントシグナリングロケーション情報に含まれたデリバリモード情報は、コンポーネントロケーションシグナリングの伝送モードを示すことができる。
【０６３８】
コンポーネントシグナリングロケーション情報に含まれたブートストラップインフォ情報は、上記伝送モードによるコンポーネントロケーションシグナリングのブートストラップ情報を含むことができる。
【０６３９】
アプリシグナリングロケーション情報は、アプリケーションシグナリングを取得できる位置を示すことができる。
【０６４０】
アプリシグナリングロケーション情報に含まれたデリバリモード情報は、アプリケーションシグナリングの伝送モードを示すことができる。
【０６４１】
アプリシグナリングロケーション情報に含まれたブートストラップインフォ情報は、上記伝送モードによるアプリケーションシグナリングのブートストラップ情報を含むことができる。
【０６４２】
オブジェクトフロー情報は、サービスのコンポーネントを送信する関連オブジェクトフローに関する情報を含むことができる。
【０６４３】
図５７は、本発明の一実施例に係る次世代放送システムのサービスシグナリングが含む伝送モードを示す図である。
【０６４４】
上述したように、伝送モード（ｄｅｌｉｖｅｒｙＭｏｄｅ）を、各ロケーションエレメント中に属性として含めることができる。伝送モードは、その値によって下記のように区別することができる。
【０６４５】
伝送モードの値が０ｘ００である場合、ＩＰｖ４／ＩＰｖ６フローがサービスシグナリングメッセージを受信した放送ストリームと同じ放送網（ｂｒｏａｄｃａｓｔ）又はセルラーネットワークを介して伝送されることを示すことができる。
【０６４６】
伝送モードの値が０ｘ０１である場合、ＩＰｖ４／ＩＰｖ６フローが別の放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。
【０６４７】
伝送モードの値が０ｘ０２である場合、セッションに基づく（ｓｅｓｓｉｏｎ−ｂａｓｅｄ）フローが同じ放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここで、セッションに基づくフローとは、実施例によってＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを意味することができる。
【０６４８】
伝送モードの値が０ｘ０３である場合、セッションに基づく（ｓｅｓｓｉｏｎ−ｂａｓｅｄ）フローが別の放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここで、セッションに基づくフローとは、実施例によってＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを意味することができる。
【０６４９】
伝送モードの値が０ｘ０４である場合、パケットに基づくフローが同じ放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここでパケットに基づくフローとは、実施例によって、ＭＭＴパケットベース伝送を意味することができる。
【０６５０】
伝送モードの値が０ｘ０５である場合、パケットに基づくフローが別の放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここでパケットに基づくフローとは、実施例によって、ＭＭＴパケットベース伝送を意味することができる。
【０６５１】
伝送モードの値が０ｘ０６である場合、ＵＲＬによって位置が指定されることを示すことができる。
【０６５２】
伝送モードの値が０ｘ０７〜０ｘＦＦである場合は、未定の値であり、他の伝送モードを示すために用いることができる。
【０６５３】
以上のように、上述したタイムベースロケーション、ＭＰＤシグナリングロケーション、コンポーネントシグナリングロケーション、及びアプリシグナリングロケーションエレメントに含まれた情報は、上記伝送モードによって、サービスシグナリングと同じ又は別の経路を通じて伝送されてもよい。
【０６５４】
図５８は、本発明の一実施例に係る次世代放送システムのサービスシグナリングが含むブートストラップに関する情報を示している。ブートストラップに関する情報は、以下、ＢｏｏｔｓｔｒａｐＩｎｆｏ  ｅｌｅｍｅｎｔと表現することができる。
【０６５５】
上述したシグナリングメッセージでいうＢｏｏｔｓｔｒａｐＩｎｆｏ  ｅｌｅｍｅｎｔは、受信機がタイムベース（ｔｉｍｅ  ｂａｓｅ）情報、ＭＰＤ又はＭＰＤ  ＵＲＬ情報、コンポーネントシグナリング（ｃｏｍｐｏｎｅｎｔ  ｓｉｇｎａｌｉｎｇ）情報、アプリシグナリング（ａｐｐｌｉｃａｔｉｏｎ  ｓｉｇｎａｌｉｎｇ）情報などを取得できるようにする情報を含むことができる。すなわち、上述したように、ブートストラップインフォ（ＢｏｏｔｓｔｒａｐＩｎｆｏ）を各ロケーションエレメント中に含めることができる。したがって、ＢｏｏｔｓｔｒａｐＩｎｆｏエレメントは、ＩＰアドレス、ポート（ｐｏｒｔ）ナンバー、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）、及び／又は関連したパケット識別子（ｐａｃｋｅｔ  Ｉｄｅｎｔｉｆｉｅｒ）などの情報を含むことができる。
【０６５６】
詳しくは、ブートストラップインフォエレメントは、ＲＦｃｈａｎｎｅｌ、ｂｒｏａｄｃａｓｔＩＤ、ｄａｔａｐｉｐｅＩＤ（ＰＬＰＩＤ）、ｓｏｕｒｃｅＩＰ、ｄｅｓｔｉｎａｔｉｏｎＩＰ、ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ、ｔｓｉ、ＵＲＬ及び／又はｐａｃｋｅｔｉｄなどの属性を含むことができる。ブートストラップインフォエレメントに含まれる情報は、ブートストラップインフォエレメントの属したロケーションエレメントに含まれた伝送モードによって変更されてもよい。
【０６５７】
ＲＦｃｈａｎｎｅｌ属性は、放送ストリームを伝達する無線周波数チャネルに関する情報を含むことができる。
【０６５８】
ｂｒｏａｄｃａｓｔＩＤ属性は、放送ストリームを送信する放送会社に対する識別情報を示すことができる。
【０６５９】
ｄａｔａｐｉｐｅＩＤ（ＰＬＰＩＤ）属性は、ＩＰデータグラムを伝達する物理層データパイプ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｄａｔａ  ｐｉｐｅ）の識別子を示すことができる。ｄａｔａｐｉｐｅＩＤは、ＰＬＰＩＤと表示することができ、ＰＬＰＩＤは、物理層パイプ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｉｐｅ）の識別子を示すことができる。
【０６６０】
ｓｏｕｒｃｅＩＰ属性は、関連したデータを含むＩＰデータグラムのソースアドレスを示すことができる。
【０６６１】
ｄｅｓｔｉｎａｔｉｏｎＩＰ属性は、関連したデータを含むＩＰデータグラムの送信先アドレスを示すことができる。
【０６６２】
ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は、関連したデータを含むＩＰデータグラムの送信先ポートナンバーを示すことができる。
【０６６３】
ｔｓｉ属性は、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔ  ｐａｃｋｅｔｓ）を伝達する伝送セッションの識別子を示すことができる。
【０６６４】
ＵＲＬ属性は、関連したデータを取得できるＵＲＬを示すことができる。
【０６６５】
ｐａｃｋｅｔｉｄは、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔ  ｐａｃｋｅｔｓ）の識別子を示すことができる。
【０６６６】
以下、図５９では、図５６に示す放送サービスに対するシグナリングが含む情報のうち、ｏｂｊｅｃｔＦｌｏｗエレメントについて説明する。
【０６６７】
図５９には、オブジェクトフローに対するシグナリングが含む情報を示す。各オブジェクトフローは、サービスを構成する１つ以上のコンポーネントを送信するフローであってもよい。したがって、１つのサービスは１つ以上のオブジェクトフローに関する情報を含むことができる。
【０６６８】
オブジェクトフローは、ｉｄ、ｏｂｊｅｃｔＦｏｒｍａｔ、ｃｏｎｔｅｎｔＴｙｐｅ及び／又はｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇ属性を含むことができる。また、オブジェクトフローは、Ｆｉｌｅエレメントを含むことができ、Ｆｉｌｅエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ及び／又はＴＯＩ属性を含むことができる。また、オブジェクトフローは、ＦｉｌｅＴｅｍｐｌａｔｅエレメントを含むことができ、ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅ、ｓｔａｒｔＴＯＩ、ｅｎｄＴＯＩ及び／又はｓｃａｌｅ属性を含むことができる。また、オブジェクトフローは、ＯｂｊｅｃｔＧｒｏｕｐエレメントを含むことができ、ＯｂｊｅｃｔＧｒｏｕｐエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ、ｓｔａｒｔＴＯＩ及び／又はｅｎｄＴＯＩ属性を含むことができる。また、オブジェクトフローは、上述したＢｏｏｔｓｔｒａｐＩｎｆｏエレメントを含むことができる。
【０６６９】
ｉｄは、オブジェクトフローの識別子を示すことができる。ＤＡＳＨセグメントが当該オブジェクトフローで伝送される場合、ｉｄは、ＭＰＤ識別子、ｐｅｒｉｏｄ識別子及びＤＡＳＨ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子の結合と同一であってもよい。
【０６７０】
ｏｂｊｅｃｔＦｏｒｍａｔは、上述したように、オブジェクトフローに含まれたオブジェクトのフォーマットを示すことができる。
【０６７１】
ｃｏｎｔｅｎｔＴｙｐｅは、オブジェクトフローのためのメディアコンテンツコンポーネントタイプを示すことができる。
【０６７２】
ｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇは、オブジェクトフローで伝達されるオブジェクトのエンコーディング方式を示すことができる。
【０６７３】
Ｆｉｌｅエレメントは、Ｆｉｌｅに関する情報を含むことができる。
【０６７４】
ＦｉｌｅエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、ファイルを取得できる位置を示すことができる。オブジェクトフローでＤＡＳＨセグメントが伝達される場合、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎはＤＡＳＨセグメントＵＲＬと同一であってもよい。
【０６７５】
ＦｉｌｅエレメントのＴＯＩ属性は、ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔ  ｉｄｅｎｔｉｆｉｅｒであって、伝送オブジェクトの識別子を示すことができる。
【０６７６】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ファイル書式に関する情報を含むことができる。
【０６７７】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅは、ファイルを取得できる位置を生成するために用いられる書式を示すことができる。
【０６７８】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｔａｒｔＴＯＩは、オブジェクトフローで伝達される最初のＴＯＩを示すことができる。
【０６７９】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｅｎｄＴＯＩは、オブジェクトフローで伝達される最後のＴＯＩを示すことができる。
【０６８０】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｃａｌｅ属性は、オブジェクトフロー内のＴＯＩ値間のスケールに関する情報を示すことができる。
【０６８１】
ＯｂｊｅｃｔＧｒｏｕｐエレメントは、オブジェクトフローで伝達される伝送オブジェクトのグループに関する情報を含むことができる。
【０６８２】
ＯｂｊｅｃｔＧｒｏｕｐエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、オブジェクトグループに関連したコンテンツの位置を示すことができる。
【０６８３】
ＯｂｊｅｃｔＧｒｏｕｐエレメントのｓｔａｒｔＴＯＩは、オブジェクトグループで伝達される最初のＴＯＩを示すことができる。
【０６８４】
ＯｂｊｅｃｔＧｒｏｕｐエレメントのｅｎｄＴＯＩは、オブジェクトグループで伝達される最後のＴＯＩを示すことができる。
【０６８５】
ＢｏｏｔｓｔｒａｐＩｎｆｏエレメントは、オブジェクトフローのブートストラップ情報を含むことができる。
【０６８６】
図５９の実施例に係るオブジェクトフローに対するシグナリングが含む情報のうち、ｏｂｊｅｃｔＦｏｒｍａｔ属性は、オブジェクトフロー上で伝達されるオブジェクトが含むペイロードの形態に関する情報を含むことができる。第１の実施例でオブジェクトフロー上におけるオブジェクトフォーマット属性は、フローに含まれたペイロードが非実時間を支援するための一般ファイルを含むことを示すことができる。第１の実施例に係るオブジェクトフォーマットはｇｅｎｅｒｉｃ  ｆｉｌｅであってもよい。
【０６８７】
第２の実施例でオブジェクトフロー上におけるオブジェクトフォーマット属性は、フローに含まれたペイロードが実時間ストリーミングを支援するためのデータファイルを含むことを示すことができる。例えば、第２の実施例のオブジェクトフォーマット属性は、ＩＳＯＢＭＦＦ形態のＤＡＳＨセグメントを示すことができる。第３の実施例でオブジェクトフロー上におけるオブジェクトフォーマット属性は、フローに含まれたペイロードが実時間ストリーミングを支援するためにＨＴＴＰエンティティ（ｅｎｔｉｔｙ）形態で表現されたデータファイルを含むことを示すことができる。ＨＴＴＰエンティティは、ＨＴＴＰによるコンテンツを伝送する一個体であってもよい。
【０６８８】
以下、図６０では、図５９に示したオブジェクトフローに対するシグナリングが含む情報のうち、ファイル書式（Ｆｉｌｅ  Ｔｅｍｐｌａｔｅ）エレメントについて説明する。
【０６８９】
図６０には、本発明の一実施例でファイル書式（Ｆｉｌｅ  Ｔｅｍｐｌａｔｅ）を表現するための情報の組合せを示す。ファイル書式は、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ及びｓｅｇｍｅｎｔ  ｎｕｍｂｅｒを組み合わせて表現することができる。例えば、ＤＡＳＨセグメントが伝送される場合、図６０に示すように、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ及びｓｅｇｍｅｎｔ  ｎｕｍｂｅｒを組み合わせて、各ファイルに対するコンテンツロケーションの情報を動的に生成することができる。結果的に、放送受信装置は、動的に生成されたコンテンツロケーション情報によって、特定コンポーネントを含む伝送パケットのフローを効果的に取得することができる。
【０６９０】
図６１には、本発明の一実施例に係るサービスシグナリングが含むオブジェクトフローを示す。
【０６９１】
オブジェクトフローは、図５９で説明したオブジェクトフォーマット属性に加えてデフォルト属性（＠ｉｓＤｅｆａｕｌｔ）を含むことができる。すなわち、オブジェクトフローは、ｉｄ、ｏｂｊｅｃｔＦｏｒｍａｔ、ｃｏｎｔｅｎｔＴｙｐｅ、ｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇ及び／又はｉｓＤｅｆａｕｌｔ属性を含むことができる。また、オブジェクトフローは、Ｆｉｌｅエレメントを含むことができ、Ｆｉｌｅエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ及び／又はＴＯＩ属性を含むことができる。また、オブジェクトフローは、ＦｉｌｅＴｅｍｐｌａｔｅエレメントを含むことができ、ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅ、ｓｔａｒｔＴＯＩ、ｅｎｄＴＯＩ及び／又はｓｃａｌｅ属性を含むことができる。また、オブジェクトフローは、ＯｂｊｅｃｔＧｒｏｕｐエレメントを含むことができ、ＯｂｊｅｃｔＧｒｏｕｐエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ、ｓｔａｒｔＴＯＩ及び／又はｅｎｄＴＯＩ属性を含むことができる。また、オブジェクトフローは、上述したＢｏｏｔｓｔｒａｐＩｎｆｏエレメントを含むことができる。
【０６９２】
ｉｄは、オブジェクトフローの識別子を示すことができる。ＤＡＳＨセグメントが当該オブジェクトフローで伝送される場合、ｉｄは、ＭＰＤ識別子、ｐｅｒｉｏｄ識別子及びＤＡＳＨ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子の結合と同一であってもよい。
【０６９３】
ｏｂｊｅｃｔＦｏｒｍａｔは、上述したように、オブジェクトフローに含まれたオブジェクトのフォーマットを示すことができる。
【０６９４】
ｃｏｎｔｅｎｔＴｙｐｅは、オブジェクトフローのためのメディアコンテンツコンポーネントタイプを示すことができる。
【０６９５】
ｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇは、オブジェクトフローで伝達されるオブジェクトのエンコーディング方式を示すことができる。
【０６９６】
ｉｓＤｅｆａｕｌｔは、オブジェクトフロー上で伝達されるオブジェクトが含むペイロードがデフォルトとして使われるコンポーネントデータを含むか否かを示すことができる。例えば、受信機がＤＡＳＨ  ＭＰＤなどの付加的なシグナリング情報の受信及び処理無しで当該オブジェクトフローで伝達されるコンポーネントデータを基本的に受信及び再生するか否かを示すことができる。
【０６９７】
Ｆｉｌｅエレメントは、Ｆｉｌｅに関する情報を含むことができる。
【０６９８】
ＦｉｌｅエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、ファイルを取得できる位置を示すことができる。オブジェクトフローでＤＡＳＨセグメントが伝達される場合、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、ＤＡＳＨセグメントＵＲＬと同一であってもよい。
【０６９９】
ＦｉｌｅエレメントのＴＯＩ属性は、ｔｒａｎｓｐｏｒｔ  ｏｂｊｅｃｔ  ｉｄｅｎｔｉｆｉｅｒであって、伝送オブジェクトの識別子を示すことができる。
【０７００】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ファイル書式に関する情報を含むことができる。
【０７０１】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅは、ファイルを取得できる位置を生成するために用いられる書式を示すことができる。
【０７０２】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｔａｒｔＴＯＩは、オブジェクトフローで伝達される最初のＴＯＩを示すことができる。
【０７０３】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｅｎｄＴＯＩは、オブジェクトフローで伝達される最後のＴＯＩを示すことができる。
【０７０４】
ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｃａｌｅ属性は、オブジェクトフロー内のＴＯＩ値間のスケールに関する情報を示すことができる。
【０７０５】
ＯｂｊｅｃｔＧｒｏｕｐエレメントは、オブジェクトフローで伝達される伝送オブジェクトのグループに関する情報を含むことができる。
【０７０６】
ＯｂｊｅｃｔＧｒｏｕｐエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、オブジェクトグループに関連したコンテンツの位置を示すことができる。
【０７０７】
ＯｂｊｅｃｔＧｒｏｕｐエレメントのｓｔａｒｔＴＯＩは、オブジェクトグループで伝達される最初のＴＯＩを示すことができる。
【０７０８】
ＯｂｊｅｃｔＧｒｏｕｐエレメントのｅｎｄＴＯＩは、オブジェクトグループで伝達される最後のＴＯＩを示すことができる。
【０７０９】
ＢｏｏｔｓｔｒａｐＩｎｆｏエレメントは、オブジェクトフローのブートストラップ情報を含むことができる。
【０７１０】
図６２には、本発明の一実施例において次世代放送システムで放送サービスのシグナリングが含む他の情報を示す。既存のＦＬＵＴＥクライアントの場合、ＦＤＴ（Ｆｉｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｔａｂｌｅ）を受信した後、放送受信装置がＦＤＴによるファイルを受信することができた。しかし、この方案は、実時間放送サービスによってファイルを伝送及び受信するには不都合がある。言い換えると、ＦＬＵＴＥプロトコルは単方向伝送プロトコルであって、実時間放送サービスには向いていない。このため、本発明の一実施例は、サービスシグナリングがＦＤＴ情報を含むことができる。
【０７１１】
具体的に、図６２に示すように、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠ｉｄ属性（ｅｌｅｍｅｎｔ）を含むことができる。＠ｉｄ属性は、ＦＤＴインスタンスの特定識別子を示すことができる。したがって、放送受信装置は、＠ｉｄ属性からＦＤＴインスタンスを識別し、ＦＤＴインスタンスを動的に生成することができる。また、放送受信装置は、生成したＦＤＴインスタンスによってファイル形態で表現された実時間ストリーミングデータを受信及び処理することができる。
【０７１２】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｅｘｐｉｒｅｓ属性を含むことができる。＠Ｅｘｐｒｉｅｓ属性は、ＦＤＴＩｎｓｔａｎｃｅの満了時間に関する情報を含むことができる。したがって、放送受信装置１００は、＠Ｅｘｐｒｉｅｓ属性によって、満了したＦＤＴＩｎｔａｎｃｅを廃棄することができる。
【０７１３】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｍｐｌｅｔｅ属性を含むことができる。一実施例で、＠Ｃｏｍｐｌｅｔｅ属性がｔｒｕｅ値を有する場合、＠Ｃｏｍｐｌｅｔｅ属性は、同じセッション内で提供される将来のＦＤＴＩｎｓｔａｎｃｅが新しいデータを含んでいないことを示すことができる。
【０７１４】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ属性は、有効なＵＲＩを割り当てることができる。
【０７１５】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠ＴＯＩ属性を含むことができる。＠ＴＯＩ属性は、有効なＴＯＩ値が必ず割り当てられる必要がある。
【０７１６】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ属性は、ファイルコンテンツの実際長さ情報であってもよい。
【０７１７】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｔｒａｎｓｆｅｒ−Ｌｅｎｇｔｈ属性を含むことができる。＠Ｔｒａｎｓｆｅｒ−Ｌｅｎｇｔｈ属性は、ファイルコンテンツの伝送長さ情報であってもよい。
【０７１８】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇ属性は、ファイルコンテンツのエンコーディング情報であってもよい。
【０７１９】
また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｔｙｐｅ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｔｙｐｅ属性は、ファイルコンテンツのタイプ情報であってもよい。
【０７２０】
図６３は、本発明の一実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す。ＬＣＴベースのプロトコルを用いて実時間又は非実時間コンテンツを伝送する場合、ＴＳＩＤのような、セッションレベルの伝送セッション情報記述のためのシグナリング情報を用いることができる。ＴＳＩＤは、伝送コンテンツと同じ帯域内（ｉｎ−ｂａｎｄ）或いは異なる経路を用いる帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）などの様々な方法及び経路でシグナリングメッセージの一部で伝送することができる。
【０７２１】
ＴＳＩＤは、ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｏｒの略語であり、伝送セッションに関する詳細情報を含むデスクリプタを示すことができる。
【０７２２】
ＴＳＩＤは、各伝送セッションに対して、ｔｓｉ属性、ＳｏｕｒｃｅＦｌｏｗで伝送されるＰａｙｌｏａｄＦｏｒａｍｔエレメント、及び／又はＲｅｐａｉｒＦｌｏｗを含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ｃｏｄｅＰｏｉｎｔ、ｐｒｏｔｏｃｏｌ、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ、ｒｅａｌｔｉｍｅ、ｉｓｏｂｍｆｆ及び／又はｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅ属性を含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ＥＦＩＤ及び／又はＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒエレメントを含むことができる。
【０７２３】
ｔｓｉは、伝送セッション識別子を示すことができる。
【０７２４】
ｃｏｄｅＰｏｉｎｔは、ペイロードに対して定義されたコードポイント値を示すことができる。この値は、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。
【０７２５】
ｐｒｏｔｏｃｏｌは、現在ｐａｙｌｏａｄの伝送プロトコルを示す。すなわち、ｐｒｏｔｏｃｏｌは、ペイロードレベルで各ペイロードに対する伝送プロトコルを定義することができる。ＬＣＴベースの伝送プロトコルには様々なものが存在してもよく、それぞれに整数値を割り当ててその種類を識別することができる。一例として、０の場合はＡＬＣを、１の場合はＲＯＵＴＥを識別することができる。また、その他のプロトコル及び将来定義される新しいプロトコルに対しても、同様の方法の識別方法を適用することができる。また、上記の実施例では、＠ｃｏｄｅｐｏｉｎｔに割り当てられた値と一致するｃｏｄｅｐｏｉｎｔ値を有するＬＣＴパケット単位で別個の＠ｐｒｏｔｏｃｏｌ値を割り当てることができ、よって、一つの伝送セッション内で様々なプロトコルを用いたコンテンツの伝送が可能である。
【０７２６】
ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔは、伝送オブジェクトのペイロードフォーマットを示すことができる。
【０７２７】
ｒｅａｌｔｉｍｅは、ＬＣＴパケットが実時間サービスのためのコンポーネントデータを含んでいるかを示すことができる。実時間サービスのためのコンポーネントデータを含んでいる場合、当該伝送オブジェクトのプレゼンテーションタイムを表現するＮＴＰタイムスタンプ（ＮＴＰ  ｔｉｍｅｓｔａｍｐｓ）を含む拡張ヘッダーを含むか否かを示すことができる。
【０７２８】
ｉｓｏｂｍｆｆは、伝送オブジェクトがＩＳＯＢＭＦＦボックスのシーケンスであるか、ＭＰＤによって参照されたＤＡＳＨオブジェクトであるか、又はＭＭＴのＭＰＵモードによってフラグメントされたＩＳＯＢＭＦＦボックスのシーケンスであるかを示すことができる。
【０７２９】
ｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅは、ルートパケット（ｒｏｕｔｅ  ｐａｃｋｅｔ）ヘッダーのサイズを示すことができる。
【０７３０】
ＥＦＩＤは、ファイル伝送データに関する詳細情報を含むことができる。
【０７３１】
ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、伝送セッションで伝達されるアプリケーションにマップ可能な付加情報を提供することができる。例えばＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤを示すことができる。
【０７３２】
図６４は、本発明の他の実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す。ＬＣＴベースのプロトコルを用いて実時間又は非実時間コンテンツを伝送する場合、ＴＳＩＤのような、セッションレベルの伝送セッション情報記述のためのシグナリング情報を用いることができる。ＴＳＩＤは、伝送コンテンツと同じ帯域内（ｉｎ−ｂａｎｄ）或いは異なる経路を用いる帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）などの様々な方法及び経路でシグナリングメッセージの一部で伝送することができる。
【０７３３】
一つの伝送セッション内で伝送されるパケットのプロトコルがいずれも同一である場合、ＴＳＩＤは、次のような構造で示すことができる。すなわち、ｐｒｏｔｏｃｏｌ属性はＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎレベルに存在でき、ｔｓｉ属性のＴＳＩ値を有するセッションの全パケットが、ｐｒｏｔｏｃｏｌ属性に割り当てられた値に該当するプロトコルで伝送されることを示すことができる。
【０７３４】
ＴＳＩＤは、各伝送セッションに対して、ｔｓｉ属性、ＳｏｕｒｃｅＦｌｏｗのｐｒｏｔｏｃｏｌ属性、ＰａｙｌｏａｄＦｏｒａｍｔエレメント、及び／又はＲｅｐａｉｒＦｌｏｗを含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ｃｏｄｅＰｏｉｎｔ、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ、ｒｅａｌｔｉｍｅ、ｉｓｏｂｍｆｆ及び／又はｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅ属性を含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ＥＦＩＤ及び／又はＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒエレメントを含むことができる。
【０７３５】
ｔｓｉは、伝送セッション識別子を示すことができる。
【０７３６】
ｐｒｏｔｏｃｏｌは、現在ｐａｙｌｏａｄの伝送プロトコルを示す。ＬＣＴベースの伝送プロトコルには様々なものが存在してもよく、それぞれに整数値を割り当ててその種類を識別することができる。一例として、０の場合はＡＬＣ、１の場合はＲＯＵＴＥを識別することができる。また、その他のプロトコル及び将来定義される新しいプロトコルに対しても、同様の方法の識別方法を適用することができる。また、上記の実施例では、一つの伝送セッション内に含まれた全パケットに対して、同一のプロトコルを用いたコンテンツの伝送が可能である。
【０７３７】
ｃｏｄｅＰｏｉｎｔは、ペイロードに対して定義されたコードポイント値を示すことができる。この値は、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。
【０７３８】
ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔは、伝送オブジェクトのペイロードフォーマットを示すことができる。
【０７３９】
ｒｅａｌｔｉｍｅは、ＬＣＴパケットが伝送オブジェクトのプレゼンテーションタイムを表現するＮＴＰタイムスタンプ（ＮＴＰ  ｔｉｍｅｓｔａｍｐｓ）を含む拡張ヘッダーを含むか否かを示すことができる。
【０７４０】
ｉｓｏｂｍｆｆは、伝送オブジェクトがＩＳＯＢＭＦＦボックスのシーケンスであるか、ＭＰＤによって参照されたＤＡＳＨオブジェクトであるか、又はＭＭＴのＭＰＵモードによってフラグメントされたＩＳＯＢＭＦＦボックスのシーケンスであるかを示すことができる。
【０７４１】
ｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅは、ルートパケットヘッダーのサイズを示すことができる。
【０７４２】
ＥＦＩＤは、ファイル伝送データに関する詳細情報を含むことができる。
【０７４３】
ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、伝送セッションで伝達されるアプリケーションにマップ可能な付加情報を提供することができる。例えば、ＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤを示すことができる。
【０７４４】
図６５は、本発明の一実施例に係る放送受信装置の動作手順を示すフローチャートである。
【０７４５】
放送受信装置の受信部は、サービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信する（Ｓ１０１）。受信部は、インターネットプロトコル通信部及び放送受信部を含むことができる。サービスシグナリングメッセージは、放送サービス及びメディアコンテンツのうち少なくとも一つをシグナルするための情報であってもよい。一実施例で、伝送プロトコルはインターネットプロトコル（ＩＰ）であってもよい。また、一実施例で、サービスシグナリングメッセージは、バイナリフォーマット及びＸＭＬフォーマットの少なくとも一つで表現されてもよい。伝送プロトコルパケットは、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。
【０７４６】
放送受信装置の制御部は、受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出する（Ｓ１０３）。具体的に、伝送プロトコルパケットをパースしてサービスシグナリングメッセージを抽出することができる。制御部は、階層化された伝送プロトコルパケットからインターネットプロトコルデータグラムを取得することができる。取得したインターネットプロトコルデータグラムは、サービスシグナリングメッセージを含むことができる。
【０７４７】
放送受信装置の制御部は、サービスシグナリングメッセージから放送サービスの提供のための情報を取得する（Ｓ１０５）。放送サービスの提供のための情報は、サービスシグナリングメッセージの一部であってもよい。
【０７４８】
一実施例で、放送サービスを提供するための情報は、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのためのサービス情報であってもよい。
【０７４９】
他の実施例で、放送サービスを提供するための情報は、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のためのサービス情報であってもよい。適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報はＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）であってもよい。
【０７５０】
他の実施例で、放送サービスを提供するための情報は、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のためのサービス情報であってもよい。コンポーネントデータは、放送サービス又はコンテンツを構成する個体であってもよい。このとき、コンポーネントデータの取得経路情報は、コンポーネントデータを伝達する物理層パイプの識別情報であってもよい。階層化された伝送プロトコルパケットは、物理層で伝達される物理層パイプを含むことができる。物理層パイプは複数個存在してもよい。したがって、複数の物理層パイプの中から、取得しようとするコンポーネントデータを含む物理層パイプを識別する必要がある。
【０７５１】
他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するアプリケーションのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、アプリケーションのためのシグナリングメッセージのためのサービス情報は、アプリケーションを送信する放送局の識別子情報、アプリケーションを含むインターネットプロトコルデータグラムのソースＩＰアドレス、アプリケーションを含むインターネットプロトコルデータグラムの送信先ＩＰアドレス、上記アプリケーションを含むインターネットプロトコルデータグラムのユーザデータグラムプロトコル（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ；ＵＤＰ）のポート番号、上記アプリケーションを送信する伝送セッションの識別子情報、及び上記アプリケーションを送信するパケットの識別子情報の少なくとも一つであってもよい。
【０７５２】
他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するサービスのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、サービスは一つのコンテンツであってもよい。
【０７５３】
他の実施例で、放送サービスを提供するための情報は、放送サービスのコンポーネントを伝達するフローのためのサービス情報であってもよい。
【０７５４】
図６６は、本発明の一実施例に係る放送送信装置の動作手順を示すフローチャートである。
【０７５５】
放送伝送装置の制御部は、放送サービスの提供のための情報をサービスシグナリングメッセージに挿入する（Ｓ２０１）。一実施例で、放送伝送装置の制御部は、放送サービスの提供のための情報をＸＭＬ形態でサービスシグナリングメッセージに挿入することができる。他の実施例で、放送伝送装置の制御部は、放送サービスの提供のための情報をバイナリ形態でサービスシグナリングメッセージに挿入することができる。
【０７５６】
放送伝送装置の制御部は、放送サービスの提供のための情報が挿入されたサービスシグナリングメッセージを伝送プロトコルパケットにパケット化（ｐａｃｋｅｔｉｚｉｎｇ）する（Ｓ２０３）。このとき、伝送プロトコルは、セッションベース伝送プロトコル（ＡＬＣ／ＬＣＴ、ＦＬＵＴＥ）及びパケットベース伝送プロトコル（ＭＰＥＧ−２ＴＳ、ＭＭＴ）のいずれか一つであってもよい。
【０７５７】
放送伝送装置の発信部は、サービスシグナリングメッセージがパケット化された伝送プロトコルパケットを特定の伝送モードで放送受信装置に伝送する（Ｓ２０５）。
【０７５８】
一実施例で、放送サービスを提供するための情報は、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのためのサービス情報であってもよい。
【０７５９】
他の実施例で、放送サービスを提供するための情報は、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のためのサービス情報であってもよい。適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報は、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）であってもよい。
【０７６０】
他の実施例で、放送サービスを提供するための情報は、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のためのサービス情報であってもよい。コンポーネントデータは、放送サービス又はコンテンツを構成する個体であってもよい。このとき、コンポーネントデータの取得経路情報は、コンポーネントデータを伝達する物理層パイプの識別情報であってもよい。階層化された伝送プロトコルパケットは、物理層で伝達される物理層パイプを含むことができる。物理層パイプは複数個存在してもよい。したがって、複数の物理層パイプの中から、取得しようとするコンポーネントデータを含む物理層パイプを識別する必要がある。
【０７６１】
他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するアプリケーションのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、アプリケーションのためのシグナリングメッセージのためのサービス情報は、アプリケーションを送信する放送局の識別子情報、アプリケーションを含むインターネットプロトコルデータグラムのソースＩＰアドレス、アプリケーションを含むインターネットプロトコルデータグラムの送信先ＩＰアドレス、上記アプリケーションを含むインターネットプロトコルデータグラムのユーザデータグラムプロトコル（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ；ＵＤＰ）のポート番号、上記アプリケーションを送信する伝送セッションの識別子情報、及び上記アプリケーションを送信するパケットの識別子情報の少なくとも一つであってもよい。
【０７６２】
他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するサービスのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、サービスは一つのコンテンツであってもよい。
【０７６３】
他の実施例で、放送サービスを提供するための情報は、放送サービスのコンポーネントを伝達するフローのためのサービス情報であってもよい。
【０７６４】
本発明の一実施例は、地上波放送網とインターネット網との連動ベースの次世代ハイブリッド放送を支援する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【０７６５】
特に、本発明の一実施例は、次世代放送システムにおけるサービスシグナリングメッセージのペイロードフォーマットを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【０７６６】
特に、本発明の一実施例は、次世代放送システムで放送サービスシグナリングを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【０７６７】
特に、本発明の一実施例は、次世代放送システムで放送サービスのコンポーネント取得経路に対するシグナリングを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【０７６８】
特に、本発明の一実施例は、次世代放送システムで放送サービスのコンポーネントの伝送フローに対するシグナリングを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。
【０７６９】
以上実施例に説明した特徴、構造、効果などは本発明の少なくとも一つの実施例に含まれるものであり、必ずしも一つの実施例に限定されるものではない。なお、各実施例で例示した特徴、構造、効果などは、実施例の属する分野における通常の知識を有する者にとって他の実施例に対して組合せ又は変形して実施することも可能である。したがって、それらの組合せ又は変形に関する内容も、本発明の範囲に含まれるものとして解釈しなければならない。
【０７７０】
以上、実施例を中心に説明してきたが、これは単なる例示であり、本発明を限定するものではない。したがって、本発明の属する分野における通常の知識を有する者にとって本実施例の本質的な特性を逸脱しない範囲で、以上に例示していない様々な変形及び応用が可能であることは明らかである。例えば、実施例に具体的に示した各構成要素を変形して実施することも可能であろう。そして、このような変形と応用に関係する差異点は、添付する特許請求の範囲で規定する本発明の範囲に含まれるものとして解釈すべきであろう。
【図１】
0006291081.tif 000050
【図２】
0006291081.tif 000051
【図３】
0006291081.tif 000052
【図４】
0006291081.tif 000053
【図５】
0006291081.tif 000054
【図６】
0006291081.tif 000055
【図７】
0006291081.tif 000056
【図８】
0006291081.tif 000057
【図９】
0006291081.tif 000058
【図１０】
0006291081.tif 000059
【図１１】
0006291081.tif 000060
【図１２】
0006291081.tif 000061
【図１３】
0006291081.tif 000062
【図１４】
0006291081.tif 000063
【図１５】
0006291081.tif 000064
【図１６】
0006291081.tif 000065
【図１７】
0006291081.tif 000066
【図１８】
0006291081.tif 000067
【図１９】
0006291081.tif 000068
【図２０】
0006291081.tif 000069
【図２１】
0006291081.tif 000070
【図２２】
0006291081.tif 000071
【図２３】
0006291081.tif 000072
【図２４】
0006291081.tif 000073
【図２５】
0006291081.tif 000074
【図２６】
0006291081.tif 000075
【図２７】
0006291081.tif 000076
【図２８】
0006291081.tif 000077
【図２９】
0006291081.tif 000078
【図３０】
0006291081.tif 000079
【図３１】
0006291081.tif 000080
【図３２】
0006291081.tif 000081
【図３３】
0006291081.tif 000082
【図３４】
0006291081.tif 000083
【図３５】
0006291081.tif 000084
【図３６】
0006291081.tif 000085
【図３７】
0006291081.tif 000086
【図３８】
0006291081.tif 000087
【図３９】
0006291081.tif 000088
【図４０】
0006291081.tif 000089
【図４１】
0006291081.tif 000090
【図４２】
0006291081.tif 000091
【図４３】
0006291081.tif 000092
【図４４】
0006291081.tif 000093
【図４５】
0006291081.tif 000094
【図４６】
0006291081.tif 000095
【図４７】
0006291081.tif 000096
【図４８】
0006291081.tif 000097
【図４９】
0006291081.tif 000098
【図５０】
0006291081.tif 000099
【図５１】
0006291081.tif 000100
【図５２】
0006291081.tif 000101
【図５３】
0006291081.tif 000102
【図５４】
0006291081.tif 000103
【図５５】
0006291081.tif 000104
【図５６】
0006291081.tif 000105
【図５７】
0006291081.tif 000106
【図５８】
0006291081.tif 000107
【図５９】
0006291081.tif 000108
【図６０】
0006291081.tif 000109
【図６１】
0006291081.tif 000110
【図６２】
0006291081.tif 000111
【図６３】
0006291081.tif 000112
【図６４】
0006291081.tif 000113
【図６５】
0006291081.tif 000114
【図６６】
0006291081.tif 000115