JP2017518662A - 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 - Google Patents

Abstract

【課題】放送受信装置に関する。【解決手段】本発明の一実施例に係る放送受信装置は、放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信する受信部と、受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出し、抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得する制御部とを有する。【選択図】図６６

Description

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

最近のデジタル放送は、地上波放送網でＡ／Ｖを受信し、インターネット網でＡ／Ｖ及び向上した（Ｅｎｈａｎｃｅｍｅｎｔ）データを受信することを可能にするハイブリッド放送を支援するためのサービス及びコンテンツ伝送同期化方案が要求されている。

特に、将来、ＤＴＶサービスで活用される有力なアプリケーションの一つとして、既存の地上波放送網とインターネット網とを連動させるハイブリッド放送サービスがある。ハイブリッド放送サービスは、地上波放送網を介して伝送される放送コンテンツと関連付けられる向上したデータ、或いは放送コンテンツの一部をインターネット網を介して実時間で伝送し、ユーザが様々なコンテンツを経験できるようにする。したがって、放送コンテンツを地上波放送網及びインターネット網の両方を介して送信し受信する放送送信装置及び放送受信装置が必要である。

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

本発明の一実施例に係る放送送信装置は、放送サービスの提供のための情報をサービスシグナリングメッセージに挿入し、前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化する制御部と、前記伝送プロトコルパケットを伝送する発信部とを備えることができる。

ここで、前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含むことができる。

ここで、前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含むことができる。

ここで、前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー（ｐｏｒｔ ｎｕｍｂｅｒ）情報、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）情報、及び関連したパケット識別子（ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）情報のうち少なくとも一つを含むことができる。

ここで、前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含むことができる。

ここで、前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含むことができる。

ここで、前記放送サービスを提供するための情報は、伝送セッションに関する情報を含むことができる。

ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含むことができる。

ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含むことができる。

本発明の一実施例に係る放送受信装置は、放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信する受信部と、前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出し、抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得する制御部とを備えることができる。

ここで、前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含むことができる。

ここで、前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含むことができる。

ここで、前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー（ｐｏｒｔ ｎｕｍｂｅｒ）情報、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）情報、及び関連したパケット識別子（ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）情報のうち少なくとも一つを含むことができる。

ここで、前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含むことができる。

ここで、前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含むことができる。

ここで、前記放送サービスを提供するための情報は、伝送セッションに関する情報を含むことができる。

ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含むことができる。

ここで、前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含むことができる。

本発明の一実施例に係る放送送信方法は、放送サービスの提供のための情報をサービスシグナリングメッセージに挿入するステップと、前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化するステップと、前記伝送プロトコルパケットを伝送するステップとを有することができる。

本発明の一実施例に係る放送受信方法は、放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信するステップと、前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出するステップと、

前記抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得するステップとを有することができる。

本発明の実施例によれば、放送システムの伝送効率を上げることができる。

本発明の実施例によれば、ハイブリッド放送サービスを提供することができる。

本発明の実施例によれば、放送受信装置がブロードバンドでメディアストリームを受信することができる。

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

本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す図である。 本発明の一実施例に係るインプットフォーマット（Ｉｎｐｕｔ ｆｏｒｍａｔｔｉｎｇ；入力フォーマット）ブロックを示す図である。 本発明の他の実施例に係るインプットフォーマット（入力フォーマット）ブロックを示す図である。 本発明の一実施例に係るＢＩＣＭ（ｂｉｔ ｉｎｔｅｒｌｅａｖｅｄ ｃｏｄｉｎｇ ＆ ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。 本発明の他の実施例に係るＢＩＣＭブロックを示す図である。 本発明の一実施例に係るフレームビルディング（Ｆｒａｍｅ Ｂｕｉｌｄｉｎｇ；フレーム生成）ブロックを示す図である。 本発明の一実施例に係るＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）ジェネレーション（ｇｅｎｅｒａｔｉｏｎ；生成）ブロックを示す図である。 本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す図である。 本発明の一実施例に係るフレーム構造を示す図である。 本発明の一実施例に係るフレームのシグナリング階層構造を示す図である。 本発明の一実施例に係るプリアンブルシグナリングデータを示す図である。 本発明の一実施例に係るＰＬＳ１データを示す図である。 本発明の一実施例に係るＰＬＳ２データを示す図である。 本発明の他の実施例に係るＰＬＳ２データを示す図である。 本発明の一実施例に係るフレームのロジカル（ｌｏｇｉｃａｌ；論理）構造を示す図である。 本発明の一実施例に係るＰＬＳ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｓｉｇｎａｌｌｉｎｇ）マッピングを示す図である。 本発明の一実施例に係るＥＡＣ（ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔ ｃｈａｎｎｅｌ）マッピングを示す図である。 本発明の一実施例に係るＦＩＣ（ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎ ｃｈａｎｎｅｌ）マッピングを示す図である。 本発明の一実施例に係るＦＥＣ（ｆｏｒｗａｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ）構造を示す図である。 本発明の一実施例に係るタイムインターリービングを示す図である。 本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す図である。 本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す図である。 本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す図である。 本発明の一実施例に係る各インターリービングアレイ（ａｒｒａｙ）からインターリービングされたＸＦＥＣＢＬＯＣＫを示す図である。 本発明の一実施例に係る放送サービスを支援するためのプロトコルスタック（ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）を示す図である。 本発明の一実施例に係る放送サービスの伝送層を示す図である。 本発明の一実施例に係るＩＰネットワークを介したメディアコンテンツ送受信システムの構成を示す図である。 本発明の一実施例に係るＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）の構造を示す図である。 本発明の一実施例に係る放送受信装置の構成を示す図である。 本発明の他の実施例に係る放送受信装置の構成を示す図である。 本発明の他の実施例に係る放送受信装置の構成を示す図である。 本発明の更に他の実施例に係る放送受信装置の構成を示す図である。 本発明の一実施例に係る放送伝送フレームを示す図である。 本発明の他の実施例に係る放送伝送フレームを示す図である。 本発明の一実施例に係る伝送パケットの構成を示す図である。 本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。 本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。 本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示す図である。 本発明の一実施例に係るサービスシグナリングメッセージにおいてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが示す値が意味する内容を示す図である。 本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。 本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。 本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。 本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。 本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。 本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。 本発明の一実施例においてｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド値による、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す図である。 図３８乃至図４６の実施例においてタイムベース及びサービスシグナリングメッセージを取得する手順を示す図である。 本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示す図である。 本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示す図である。 図４９で説明した各伝送モードが有する値による意味を示す図である。 次世代放送システムにおいて放送サービスのコンポーネントデータ取得経路をシグナルするシグナリングメッセージの構成を示す図である。 本発明の一実施例に係るａｐｐ＿ｄｅｌｅｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す図である。 本発明の他の実施例に係るａｐｐ＿ｄｅｌｅｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す図である。 放送サービスを構成する一つ以上のコンポーネントデータを取得できる経路情報を含むコンポーネントロケーションシグナリングを示す図である。 図５４のコンポーネントロケーションシグナリングの構成を示す図である。 本発明の一実施例において次世代放送システムで放送サービスのシグナリングが含む他の情報を示す図である。 本発明の一実施例に係る次世代放送システムのサービスシグナリングが含む伝送モードを示す図である。 本発明の一実施例に係る次世代放送システムのサービスシグナリングが含むブートストラップに関する情報を示す図である。 オブジェクトフローに対するシグナリングが含む他の情報を示す図である。 本発明の一実施例においてファイル書式（Ｆｉｌｅ Ｔｅｍｐｌａｔｅ）を表現するための情報の組合せを示す図である。 本発明の一実施例に係るサービスシグナリングが含むオブジェクトフローを示す図である。 本発明の一実施例において次世代放送システムで放送サービスのシグナリングが含む他の情報を示す図である。 本発明の一実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す図である。 本発明の他の実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す図である。 本発明の一実施例に係る放送受信装置の動作手順を示すフローチャートである。 本発明の一実施例に係る放送伝送装置の動作手順を示すフローチャートである。

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

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

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

以下では、説明の便宜のために、ＭＩＳＯ又はＭＩＭＯ方式が２つのアンテナを用いるとするが、本発明は、２つ以上のアンテナを用いるシステムに適用されてもよい。本発明は、特定の用途に要求される性能を達成しながら、受信機の複雑度を最小化するために、最適化された３つのフィジカルプロファイル（ＰＨＹ ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が具現しなければならない全ての構造のサブセットである。

３つのフィジカルプロファイルは、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。後でフィジカルプロファイルがさらに定義されてもよい。システムの発展のために、ヒューチャプロファイルは、ＦＥＦ（ｆｕｔｕｒｅ ｅｘｔｅｎｓｉｏｎ ｆｒａｍｅ）を通じて単一ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクスされてもよい。各フィジカルプロファイルに関する詳細な内容は後述する。

１．ベースプロファイル
ベースプロファイルは主にループトップ（ｒｏｏｆ−ｔｏｐ）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動してもよいが、比較的停止した受信範ちゅうに属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置又は車両用に拡張されてもよいが、このような使用用途はベースプロファイル受信機動作では期待されない。

受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは、既存放送システム（例えば、ＡＴＳＣ Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用する、バッテリーで駆動するハンドヘルド装置におけるよりは重要でない。ベースプロファイルに対する重要システムパラメータが、下記の表１に記載されている。

２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は歩行者又は車両の速度で移動することができる。受信機複雑度も消費電力も、共にハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ未満となるように設定されてもよい。

低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが下記の表２に記載されている。

３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルはＭＩＭＯ送信及び受信を用いることを要求し、ＵＨＤＴＶサービスはターゲット用途であり、そのために、当該プロファイルが特別に設計される。向上した能力は、与えられた帯域幅でサービス数の増加、例えば、複数のＳＤＴＶ又はＨＤＴＶサービスを許容するために用いることができる。

アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０乃至３０ｄＢである。ＭＩＭＯ伝送は、初期には既存の楕円分極伝送装備を使用し、将来には全出力交差分極伝送へと拡張されてもよい。アドバンスドプロファイルに対する重要システムパラメータが下記の表３に記載されている。

この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いられてもよい。すなわち、ベースプロファイルを、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別することができる。そして、該当の３つのプロファイルは設計者の意図によって変更されてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データパイプは、１つ又は複数のサービス又はサービスコンポーネントを伝達できるサービスデータ又は関連メタデータを伝達する物理層におけるロジカルチャネルである。

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

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

フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマップすることができる。マッピング後、周波数領域ダイバーシチのために、特に、周波数選択的フェージングチャネルを防止するために周波数インターリービングが用いられる。フレームビルディングブロック１０２０の詳細な動作は後述する。

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

シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の詳細な動作は後述する。

図２、図３、図４は、本発明の実施例に係るインプットフォーマットブロック１０００を示す。各図について説明する。

図２は、本発明の一実施例に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（ｓｉｎｇｌｅ ｉｎｐｕｔ ｓｔｒｅａｍ）であるときのインプットフォーマットブロックを示す。

図２に示すインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。

物理層への入力は、１つ又は複数のデータストリームで構成される。それぞれのデータストリームは一つのデータパイプによって伝達される。モードアダプテーション（ｍｏｄｅ ａｄａｐｔａｉｏｎ；モード適応）モジュールは、入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄ ｆｒａｍｅ）のデータフィールドにスライスする。当該システムは３種類の入力データストリーム、すなわち、ＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（ｇｅｎｅｒｉｃ ｓｔｒｅａｍ）を支援する。ＭＰＥＧ２−ＴＳは、最初のバイトが同期バイト（０ｘ４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームは、ＩＰパケットヘッダー内でシグナルされる可変長ＩＰデータグラムパケットで構成される。当該システムは、ＩＰストリームに対してＩＰｖ４、ＩＰｖ６の両方を支援する。ＧＳは、カプセル化パケットヘッダー内でシグナルされる可変長のパケット又は一定の長さのパケットで構成されてもよい。

（ａ）は、信号データパイプに対するモードアダプテーション（モード適応）ブロック２０００、及びストリームアダプテーション（ｓｔｒｅａｍ ａｄａｐｔａｔｉｏｎ；ストリーム適応）２０１０を示し、（ｂ）は、ＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０、及びＰＬＳスクランブラ２０３０を示す。各ブロックの動作について説明する。

入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（ｂａｓｅｂａｎｄ）フレームスライサ、及びＢＢフレームヘッダー挿入ブロックで構成される。

ＣＲＣエンコーダは、ユーザパケット（ｕｓｅｒ ｐａｃｋｅｔ；ＵＰ）レベルでの誤り検出のための３種類のＣＲＣエンコーディング、すなわち、ＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトは、ＵＰ後に付加される。ＣＲＣ−８はＴＳストリームに用いられ、ＣＲＣ−３２はＩＰストリームに用いられる。ＧＳストリームがＣＲＣエンコーディングを提供しない場合には、提案されたＣＲＣエンコーディングが適用されなければならない。

ＢＢフレームスライサは、入力を内部ロジカルビットフォーマットにマップする。最初の受信ビットはＭＳＢと定義する。ＢＢフレームスライサは、可用データフィールド容量と同数の入力ビットを割り当てる。ＢＢＦペイロードと同数の入力ビットを割り当てるために、ＵＰストリームがＢＢＦのデータフィールドに見合うようにスライスされる。

ＢＢフレームヘッダー挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダーを、ＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダーだけでなく、ＢＢＦは、２バイトＢＢＦヘッダーの終わりに拡張フィールド（１又は３バイト）を有することができる。

ストリームアダプテーション（ストリーム適応）２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラで構成される。スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（ストリーム適応）に対する入力データがＢＢフレームを満たすのに十分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。そうでないと、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。

ＢＢスクランブラは、エネルギー分散のために完全なＢＢＦをスクランブルする。スクランブリングシーケンスはＢＢＦと同期化される。スクランブリングシーケンスはフィードバックシフトレジスターによって生成される。

ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機でフィジカルレイヤ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）データパイプに接続できる手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。

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

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

ＰＬＳデータに関する詳細な内容は後述する。

ＰＬＳスクランブラ２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブルすることができる。

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

図３は、本発明の他の実施例に係るインプットフォーマットブロックを示す。

図３に示すインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。

図３は、入力信号がマルチインプットストリーム（ｍｕｌｔｉ ｉｎｐｕｔ ｓｔｒｅａｍ；複数の入力ストリーム）に該当する場合、インプットフォーマットブロックのモードアダプテーション（モード適応）ブロックを示す。

マルチインプットストリーム（複数の入力ストリーム）を処理するためのインプットフォーマットブロックのモードアダプテーション（モード適応）ブロックは、複数の入力ストリームを独立して処理することができる。

図３を参照すると、マルチインプットストリーム（複数の入力ストリーム）をそれぞれ処理するためのモードアダプテーション（モード適応）ブロックは、インプットストリームスプリッタ（ｉｎｐｕｔ ｓｔｒｅａｍ ｓｐｌｉｔｔｅｒ）３０００、インプットストリームシンクロナイザ（ｉｎｐｕｔ ｓｔｒｅａｍ ｓｙｎｃｈｒｏｎｉｚｅｒ）３０１０、コンペンセーティングディレイ（ｃｏｍｐｅｎｓａｔｉｎｇ ｄｅｌａｙ；補償遅延）ブロック３０２０、ヌルパケット削除ブロック（ｎｕｌｌ ｐａｃｋｅｔ ｄｅｌｅｔｉｏｎ ｂｌｏｃｋ）３０３０、ヘッダーコンプレションブロック（ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ ｂｌｏｃｋ）３０４０、ＣＲＣエンコーダ（ＣＲＣ ｅｎｃｏｄｅｒ）３０５０、ＢＢフレームスライサ（ＢＢ ｆｒａｍｅ ｓｌｉｃｅｒ）３０６０、及びＢＢヘッダー挿入ブロック（ＢＢ ｈｅａｄｅｒ ｉｎｓｅｒｔｉｏｎ ｂｌｏｃｋ）３０７０を含むことができる。モードアダプテーション（モード適応）ブロックの各ブロックについて説明する。

ＣＲＣエンコーダ３０５０、ＢＢフレームスライサ３０６０、及びＢＢヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサ、及びＢＢヘッダー挿入ブロックの動作に該当するので、その説明は省略する。

インプットストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービス又はサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。

インプットストリームシンクロナイザ３０１０は、ＩＳＳＹと呼ぶことができる。ＩＳＳＹは、いかなる入力データフォーマットに対しても、ＣＢＲ（ｃｏｎｓｔａｎｔ ｂｉｔ ｒａｔｅ）及び一定の終端間伝送（ｅｎｄ−ｔｏ−ｅｎｄ ｔｒａｎｓｍｉｓｓｉｏｎ）遅延を保障するに適した手段を提供することができる。ＩＳＳＹは、ＴＳを伝達する複数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する複数のデータパイプに選択的に用いられる。

コンペンセーティングディレイ（補償遅延）ブロック３０２０は、受信機でさらにメモリを必要とせずにＴＳパケット再結合メカニズムを許容するために、ＩＳＳＹ情報の挿入に続く分割されたＴＳパケットストリームを遅延させることができる。

ヌルパケット削除ブロック３０３０は、ＴＳインプットストリームの場合にのみ用いられる。一部のＴＳインプットストリーム又は分割されたＴＳストリームは、ＶＢＲ（ｖａｒｉａｂｌｅ ｂｉｔ−ｒａｔｅ）サービスをＣＢＲ ＴＳストリームに収容するために、存在する多数のヌルパケットを有することができる。この場合、不要な伝送オーバーヘッドを避けるために、ヌルパケットは確認されて伝送されなくてもよい。受信機で、除去されたヌルパケットは、伝送に挿入されたＤＮＰ（ｄｅｌｅｔｅｄ ｎｕｌｌ−ｐａｃｋｅｔ；削除されたヌルパケット）カウンタを参照して元の正確な場所に再挿入可能であるため、ＣＢＲが保障され、タイムスタンプ（ＰＣＲ）更新が不要になる。

ヘッダーコンプレションブロック３０４０は、ＴＳ又はＩＰインプットストリームに対する伝送効率を増加させるために、パケットヘッダーコンプレションを提供することができる。受信機は、ヘッダーの特定部分に対する先験的な（ａ ｐｒｉｏｒｉ）情報を有することができるため、この知られた情報（ｋｎｏｗｎ ｉｎｆｏｒｍａｔｉｏｎ）は送信機で削除されてもよい。

ＴＳに対して、受信機は同期バイト構成（０ｘ４７）及びパケット長（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが一つのＰＩＤだけを有するコンデンツを伝達すると、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）又はサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣエンハンスメントレイヤ、ＭＶＣベースビュー、又はＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダーコンプレションがＴＳに（選択的に）適用されてもよい。ＴＳパケットヘッダーコンプレションは、インプットストリームがＩＰストリームである場合に選択的に用いられる。上記のブロックは省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。

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

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

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

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

（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。

ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロック及びアドバンスドプロファイルのＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。

ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスドプロファイルに対するＢＩＣＭブロックの各処理ブロックについて説明する。

ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌ ｓｐａｃｅ ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。

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

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

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

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

アドバンスドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。

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

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

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

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

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

ＭＩＭＯ処理はアドバンスドプロファイルフレームに要求されるが、これは、アドバンスドプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダによって処理されるということを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ；対）であるＮＵＱ（ｅ_1,i及びｅ_2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（対）（ｇ_1,i及びｇ_2,i）は、それぞれの送信アンテナの同一キャリアｋ及びＯＦＤＭシンボルｌによって送信される。

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

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

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

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

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

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

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

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

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

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

ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の表４のとおりである。

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

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

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

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

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

図６は、本発明の一実施例に係るフレームビルディングブロック（ｆｒａｍｅ ｂｕｉｌｄｉｎｇ ｂｌｏｃｋ）を示す。

図６に示すフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施例に該当する。

図６を参照すると、フレームビルディングブロックは、ディレイコンペセーション（ｄｅｌａｙ ｃｏｍｐｅｎｓａｔｉｏｎ；遅延補償）ブロック７０００、セルマッパー（ｃｅｌｌ ｍａｐｐｅｒ）７０１０、及びフリークエンシインターリーバ（ｆｒｅｑｕｅｎｃｙ ｉｎｔｅｒｌｅａｖｅｒ）７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。

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

セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップすることができる。セルマッパー７０１０の基本機能は、それぞれのデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマップすることである。（ＰＳＩ（ｐｒｏｇｒａｍ ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集され、データパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成されたダイナミックインフォメーション（ｄｙｎａｍｉｃ ｉｎｆｏｒｍａｔｉｏｎ；動的情報）によって動作する。フレームに関する詳細な内容は後述する。

フリークエンシインターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリーブして周波数ダイバーシチを提供することができる。また、フリークエンシインターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（対）で動作することができる。

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

図７は、本発明の一実施例に係るＯＦＤＭジェネレーションブロックを示す。

図７に示すＯＦＤＭジェネレーションブロックは、図１を参照して説明したＯＦＤＭジェネレーションブロック１０３０の一実施例に該当する。

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

図７を参照すると、ＯＦＤＭジェネレーションブロックは、パイロット及びリザーブドトーン挿入ブロック（ｐｉｌｏｔ ａｎｄ ｒｅｖｓｅｒｖｅｄ ｔｏｎｅ ｉｎｓｅｒｔｉｏｎ ｂｌｏｃｋ）８０００、２Ｄ−ｅＳＦＮ（ｓｉｎｇｌｅ ｆｒｅｑｕｅｎｃｙ ｎｅｔｗｏｒｋ）エンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅ ｆａｓｔ Ｆｏｕｒｉｅｒ ｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、ガードインターバル挿入ブロック（ｇｕａｒｄ ｉｎｔｅｒｖａｌ ｉｎｓｅｒｔｉｏｎ ｂｌｏｃｋ）８０４０、プリアンブル挿入ブロック（ｐｒｅａｍｂｌｅ ｉｎｓｅｒｔｉｏｎ ｂｌｏｃｋ）８０５０、その他システム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。

システム挿入ブロック８０６０は、放送サービスを提供する２つ以上の別個の放送送信／受信システムのデータが同一のＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクスすることができる。ここで、２つ以上の別個の放送送信／受信システムとは、別個の放送サービスを提供するシステムのことをいう。別個の放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。

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

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

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

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

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

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

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

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

図９は、本発明の一実施例に係るフレーム構造を示す。

図９は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（ｆｒａｍｅ ｒｅｐｅｔｉｔｉｏｎ ｕｎｉｔ；フレーム反復単位）を示す。（ａ）は、本発明の一実施例に係るスーパーフレームを示し、（ｂ）は、本発明の一実施例に係るＦＲＵを示し、（ｃ）は、ＦＲＵにおける様々なフィジカルプロファイル（ＰＨＹ ｐｒｏｆｉｌｅ）のフレームを示し、（ｄ）は、フレームの構造を示す。

スーパーフレームは８個のＦＲＵを含むことができる。ＦＲＵは、フレームのＴＤＭに対する基本マルチプレクシング単位であり、スーパーフレームで８回反復される。

ＦＲＵにおいて各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスドプロファイル）のいずれか一つ又はＦＥＦに属する。ＦＲＵにおいてフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、ＦＲＵにおいて０回乃至４回の回数を有することができる（例えば、ベース、ベース、ハンドヘルド、アドバンスド）。フィジカルプロファイル定義は、必要時には、プリアンブルにおけるＰＨＹ＿ＰＲＯＦＩＬＥのリザーブド値を用いて拡張されてもよい。

ＦＥＦ部分は、含まれるなら、ＦＲＵの終わりに挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームにおいて８である。ＦＥＦ部分が互いに隣接することは推奨されない。

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

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

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

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

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

図１１は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。

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

ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、現フレームのフィジカルプロファイルタイプを示す。各フィジカルプロファイルタイプのマッピングは、下記の表５のように与えられる。

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

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

ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームで提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームで提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドはスーパーフレーム内でダイナミック（動的）に転換されてもよい。

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

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

ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：当該３ビットフィールドは、現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全プリアンブルにおける当該フィールドにおいて、現スーパーフレームで伝達される全プロファイルタイプが識別される。当該３ビットフィールドは、下記の表８に示すように、それぞれのプロファイルに対して別々に定義される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＰＬＳ２−ＳＴＡＴデータのフィールドに対して次に具体的に説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１４は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は一つのフレームグループのデューレーションで変化してもよいが、フィールドのサイズは一定である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＰＬＳセルは、図１６の例に示すように、下向き方式でＦＳＳのアクティブキャリアにマップされる。ＰＬＳ１セルははじめには、最初のＦＳＳの最初のセルからセルインデックスの昇順でマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、マッピングは、最初のＦＳＳの最後のセルインデックスまで下向き方式で続く。必要なＰＬＳセルの全数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは次のＦＳＳに進行され、最初のＦＳＳと全く同じ方式で続けて行われる。

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

図１７は、本発明の一実施例に係るＥＡＣマッピングを示す。

ＥＡＣは、ＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳ支援は提供されるが、ＥＡＣ自体は全てのフレームに存在してもよく、存在しなくてもよい。ＥＡＣが存在すると、ＥＡＣは、ＰＬＳ２セルの直後にマップされる。ＰＬＳセルを除けば、ＦＩＣ、データパイプ、補助ストリーム又はダミーセルのいずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手順はＰＬＳと全く同一である。

ＥＡＣセルは、図１７の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは、少ないシンボルを占めることができる。

ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＥＡＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、ＥＡＣマッピングは次のシンボルに進行され、ＦＳＳと全く同じ方式で続けて行われる。この場合、ＥＡＣのマッピングがなされる次のシンボルは、ノーマルデータシンボルであり、これは、ＦＳＳに比べてより多いアクティブキャリアを有する。

ＥＡＣマッピングが完了した後、存在するなら、ＦＩＣが次に伝達される。ＦＩＣが伝送されないと（ＰＬＳ２フィールドでシグナリングによって）、データパイプがＥＡＣの最後のセルの直後に続く。

図１８は、本発明の一実施例に係るＦＩＣマッピングを示す。

（ａ）は、ＥＡＣ無しのＦＩＣセルのマッピングの例を示し、（ｂ）は、ＥＡＣと共にＦＩＣセルのマッピングの例を示す。

ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にするために層間情報（ｃｒｏｓｓ−ｌａｙｅｒ ｉｎｆｏｒｍａｔｉｏｎ）を伝達する専用チャネルである。当該情報は主に、データパイプ間のチャネルバインディング（ｃｈａｎｎｅｌ ｂｉｎｄｉｎｇ）情報及び各放送会社のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコードし、放送会社ＩＤ、サービス数、ＢＡＳＥ＿ＤＰ＿ＩＤのような情報を取得することができる。高速サービスの取得のために、ＦＩＣだけでなくベースデータパイプもＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコードすることができる。ベースデータパイプが伝達するコンデンツを除いて、ベースデータパイプは、ノーマルデータパイプと全く同じ方式でエンコードされてフレームにマップされる。したがって、ベースデータパイプに関する追加説明は不要である。ＦＩＣデータが生成されて管理階層で消費される。ＦＩＣデータのコンデンツは、管理階層の仕様に説明されたとおりである。

ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（静的）である部分でＦＩＣ＿ＦＬＡＧパラメータによってシグナルされる。ＦＩＣが用いられると、ＦＩＣ＿ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドは、ＰＬＳ２のスタティック（静的）である部分で定義される。当該フィールドでシグナルされるものはＦＩＣ＿ＶＥＲＳＩＯＮであり、ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ．ＦＩＣは、ＰＬＳ２と同じ変調、コーディング、タイムインターリービングパラメータを用いる。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣのような同一のシグナリングパラメータを共有する。ＦＩＣデータは、存在するなら、ＰＬＳ２の後にマップされるか、ＥＡＣが存在すると、ＥＡＣの直後にマップされる。ノーマルデータパイプ、補助ストリーム、又はダミーセルのいずれもＦＩＣの前に位置しない。ＦＩＣセルをマップする方法は、ＥＡＣと全く同一であり、これはさらにＰＬＳと同一である。

ＰＬＳの後にＥＡＣが存在しない場合、ＦＩＣセルは、（ａ）の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順でマップされる。ＦＩＣデータサイズによって、（ｂ）に示すように、ＦＩＣセルは数個のシンボルに対してマップされる。

ＦＩＣセルは、ＰＬＳ２の最後のセルの直後に続き、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向き方式で続けて行われる。必要なＦＩＣセルの全数が最後のＦＳＳの残っているアクティブキャリアの数を超えると、マッピングは次のシンボルに進行され、これはＦＳＳと全く同じ方式で続けて行われる。この場合、ＦＩＣがマップされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳに比べてより多いアクティブキャリアを有する。

ＥＡＳメッセージが現フレームで伝送されると、ＥＡＣはＦＩＣよりも先にマップされ、（ｂ）に示すように、ＥＡＣの次のセルから、ＦＩＣセルはインデックスの昇順でマップされる。

ＦＩＣマッピングが完了した後、一つ以上のデータパイプがマップされ、その後、存在するなら、補助ストリーム、ダミーセルが続く。

図１９は、本発明の一実施例に係るＦＥＣ構造を示す。

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

図１９に示すように、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋ_bchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコードされたＢＢＦ（Ｋ_ldpcビット＝Ｎ_bchビット）に適用される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表３０を表３１に代え、ロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリクスのアドレスに代えることを除けば、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔ ＬＤＰＣエンコーディング手順にしたがう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図２１（ａ）は、タイムインターリーバで書き込み動作を示し、図２１（ｂ）は、タイムインターリーバで読み取り動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫはタイムインターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作が続けて行われる。そして、インターリービングアレイで、セルが対角線方向に読み取られる。

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

によって算出される。

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

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

につながる。

図２３は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの対角線方向読み取りパターンを示す。

図２４は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたＸＦＥＣＢＬＯＣＫを示す。

図２４は、パラメータ

及びＳ_shift＝３を有するそれぞれのインターリービングアレイからインターリーブされたＸＦＥＣＢＬＯＣＫを示す。

図２５は、本発明の一実施例に係る放送サービスを支援するためのプロトコルスタック（ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）を示す図である。

本発明の一実施例に係る放送サービスは、視聴覚データ（Ａｕｉｄｏ／Ｖｉｄｅｏ；Ａ／Ｖ）の他、ＨＴＭＬ５アプリケーション、両方向サービス、ＡＣＲサービス、セカンドスクリーン（ｓｅｃｏｎｄ ｓｃｒｅｅｎ）サービス、個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）サービスなどの付加サービスも提供することができる。

このような放送サービスは、地上波、ケーブル衛星などの放送信号である物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）を介して伝送することができる。また、本発明の一実施例に係る放送サービスは、インターネット通信網（ｂｒｏａｄｂａｎｄ）を介して伝送することができる。

放送サービスが地上波、ケーブル衛星などの放送信号である物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）で伝送される場合、放送受信装置は、カプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）されたＭＰＥＧ−２伝送ストリーム（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ；ＴＳ）及びカプセル化されたＩＰデータグラムを、放送信号を復調して抽出することができる。放送受信装置は、ＩＰデータグラムからユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ；ＵＤＰ）データグラムを抽出することができる。放送受信装置は、ＵＤＰデータグラムからシグナリング情報を抽出することができる。このとき、シグナリング情報はＸＭＬ形態であってもよい。また、放送受信装置は、ＵＤＰデータグラムから非同期階層化コーディング／階層化コーディング伝送（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ／ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ；ＡＬＣ／ＬＣＴ）パケットを抽出することができる。放送受信装置は、ＡＬＣ／ＬＣＴパケットから単方向ファイル伝送（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ；ＦＬＵＴＥ）パケットを抽出することができる。このとき、ＦＬＵＴＥパケットは、実時間オーディオ／ビデオ／字幕データ、非実時間（Ｎｏｎ−Ｒｅａｌ Ｔｉｍｅ；ＮＲＴ）データ、及び電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｄｉｅ；ＥＳＧ）データを含むことができる。また、放送受信装置は、ＵＤＰデータグラムから実時間伝送プロトコル（例えば、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ；ＲＴＣＰ）パケット及びＲＴＰ制御プロトコル（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ；ＲＴＣＰ）パケットを抽出することができる。放送受信装置は、ＲＴＰ／ＲＴＣＰパケットのような実時間情報パケットからＡ／Ｖデータ及び付加データを抽出することができる。このとき、ＮＲＴデータ、Ａ／Ｖデータ及び付加データのうち少なくとも一つは、ＩＳＯベースメディアファイルフォーマット（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ；ＩＳＯＢＭＦＦ）の形態であってもよい。また、放送受信装置は、ＭＰＥＧ−２ＴＳパケット又はＩＰパケットからＮＲＴデータ、Ａ／Ｖ、ＰＳＩ／ＰＳＩＰのようなシグナリング情報を抽出することができる。このとき、シグナリング情報は、ＸＭＬ又はバイナリ形態であってもよい。

放送サービスがインターネット通信網（ｂｒｏａｄｂａｎｄ）で伝送される場合、放送受信装置はインターネット通信網からＩＰパケットを受信することができる。放送受信装置はＩＰパケットからＴＣＰパケットを抽出することができる。放送受信装置はＴＣＰパケットからＨＴＴＰパケットを抽出することができる。放送受信装置はＨＴＴＰパケットからＡ／Ｖ、付加データ、シグナリング情報などを抽出することができる。このとき、Ａ／Ｖ及び付加データのうち少なくとも一つは、ＩＳＯＢＭＦＦ形態であってもよい。また、シグナリング情報はＸＭＬ形態であってもよい。

図２６は、本発明の一実施例に係るＩＰネットワークを介したメディアコンテンツ送受信システムの構成を示す図である。

本発明の一実施例に係るＩＰネットワークを介したメディアコンテンツの送受信は、実際メディアコンテンツを含む伝送パケットの送受信とメディアコンテンツ再生情報の送受信とに区別される。放送受信装置１００は、メディアコンテンツ再生情報を受信し、メディアコンテンツを含む伝送パケットを受信する。このとき、メディアコンテンツ再生情報は、メディアコンテンツの再生のために必要な情報を示す。メディアコンテンツ再生情報は、メディアコンテンツの再生のために必要な空間的情報（ｓｐａｔｉａｌ ｉｎｆｏｒｍａｔｉｏｎ）及び時間的情報（ｔｅｍｐｏｒａｌ ｉｎｆｏｒｍａｔｉｏｎ）のうち少なくとも一つを含むことができる。放送受信装置１００は、メディアコンテンツ再生情報に基づいてメディアコンテンツを再生する。

具体的な実施例で、ＭＭＴ標準に基づいてメディアコンテンツをＩＰネットワークを介して送受信することができる。このとき、コンテンツサーバー５０は、メディアコンテンツ再生情報を含む再生情報（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ；ＰＩ）ドキュメントを伝送する。また、コンテンツサーバー５０は、放送受信装置１００の要求に基づいて、メディアコンテンツを含むＭＭＴプロトコル（ＭＭＴＰ）パケットを伝送する。放送受信装置１００は、ＰＩドキュメントを受信する。放送受信装置１００は、メディアコンテンツを含む伝送パケットを受信する。放送受信装置１００は、メディアコンテンツを含む伝送パケットからメディアコンテンツを抽出する。放送受信装置１００は、ＰＩドキュメントに基づいてメディアコンテンツを再生する。

他の具体的な実施例で、図２６の実施例のように、ＭＰＥＧ−ＤＡＳＨ標準によってメディアコンテンツがＩＰネットワークを介して送受信されてもよい。図２６で、コンテンツサーバー５０は、メディアコンテンツ再生情報を含むメディア再生デスクリプション（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｏｎ；ＭＰＤ）を伝送する。ただし、具体的な実施例によっては、ＭＰＤをコンテンツサーバー５０ではなく他の外部のサーバーが伝送してもよい。また、コンテンツサーバー５０は、放送受信装置１００の要求に基づいて、メディアコンテンツを含むセグメント（ｓｅｇｍｅｎｔ）を伝送する。放送受信装置１００は、ＭＰＤを受信する。放送受信装置１００は、ＭＰＤに基づいてメディアコンテンツをコンテンツサーバーに要求する。放送受信装置１００は、要求に基づいてメディアコンテンツを含む伝送パケットを受信する。放送受信装置１００はＭＰＤに基づいてメディアコンテンツを再生する。そのために、放送受信装置１００は、制御部１１０にＤＡＳＨクライアント（ｃｌｉｅｎｔ）を含むことができる。ＤＡＳＨクライアントは、ＭＰＤをパース（ｐａｒｓｅ）するＭＰＤパーサー、セグメントをパースするセグメントパーサー、ＩＰ送受信部１３０を介して、ＨＴＴＰ要求メッセージを伝送し、ＨＴＴＰ応答メッセージを受信するＨＴＴＰクライアント、メディアを再生するメディアエンジン（ｅｎｇｉｎｅ）を含むことができる。

図２７は、本発明の一実施例に係るＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）の構造を示す図である。ＭＰＤは、ピリオド（Ｐｅｒｉｏｄ）エレメント、アダプテーションセット（Ａｄａｐｔａｔｉｏｎ Ｓｅｔ）エレメント、及びリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）エレメントを含むことができる。

ピリオドエレメントは、ピリオドに関する情報を含む。ＭＰＤは、複数のピリオドに関する情報を含むことができる。ピリオドは、メディアコンテンツ再生（ｐｒｅｓｅｎｔａｔｉｏｎ）の連続した時間区間を表す。

アダプテーションセットエレメントは、アダプテーションセットに関する情報を含む。ＭＰＤは、複数のアダプテーションセットに関する情報を含むことができる。アダプテーションセットは、相互切り替え可能な１つ又はそれ以上のメディアコンテンツコンポーネントを含むメディアコンポーネントの集合である。アダプテーションセットは、１つ又はそれ以上のリプレゼンテーションを含むことができる。各アダプテーションセットは、それぞれ異なる言語のオーディオを含んでもよく、それぞれ異なる言語の字幕を含んでもよい。

リプレゼンテーションエレメントは、リプレゼンテーションに関する情報を含む。ＭＰＤは、複数のリプレゼンテーションに関する情報を含むことができる。リプレゼンテーションは、１つ又はそれ以上のメディアコンポーネントの構造化した集合であり、同一メディアコンテンツコンポーネントに対して別個にエンコードされた複数のリプレゼンテーションが存在してもよい。一方、ビットストリームスイッチング（ｂｉｔｓｔｒｅａｍ ｓｗｉｔｃｈｉｎｇ）が可能な場合、放送受信装置１００は、メディアコンテンツ再生の途中にアップデートされた情報に基づいて、受信されるリプレゼンテーションを他のリプレゼンテーションに切り替えることもできる。特に、放送受信装置１００は、帯域幅の環境によって、受信されるリプレゼンテーションを他のリプレゼンテーションに切り替えることができる。リプレゼンテーションは複数のセグメントに分割される。

セグメントは、メディアコンテンツデータの単位である。リプレゼンテーションは、ＨＴＴＰ１．１（ＲＦＣ２６１６）で定義されたＨＴＴＰ ＧＥＴ又はＨＴＴＰ ｐａｒｔｉａｌ ＧＥＴ ｍｅｔｈｏｄを用いたメディアコンテンツ受信機３０の要求に応じて、セグメント又はセグメントの一部分で伝送されてもよい。

また、セグメントは、複数のサブセグメントで構成することができる。サブセグメントは、セグメントレベルでインデックス可能な最小の単位（ｕｎｉｔ）を意味することができる。セグメントは、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）、メディアセグメント（Ｍｅｄｉａ Ｓｅｇｍｅｎｔ）、インデックスセグメント（Ｉｎｄｅｘ Ｓｅｇｍｅｎｔ）、ビットストリームスイッチングセグメント（Ｂｉｔｓｔｒｅａｍ Ｓｗｉｔｃｈｉｎｇ Ｓｅｇｍｅｎｔ）などを含むことができる。

図２８は、本発明の一実施例に係る放送サービスの伝送層を示す図である。

放送伝送装置３００は、複数の層から構成された放送信号で放送サービスを伝送することができる。放送サービスを伝送するための複数の層のうち、物理的媒体（ｐｈｙｓｉｃａｌ ｍｅｄｉｕｍ）を介して原始的な（ｒａｗ）放送信号を送受信するための伝送層を物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）ということができる。放送伝送装置３００は、１つ又は複数の周波数上で１つ以上の物理層パイプ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ；ＰＬＰ）を介して放送サービス及び放送サービス関連データを伝送することができる。一つの周波数上に複数の物理層パイプが存在してもよく、このとき、ＰＬＰは、物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）上で識別可能な一連の論理的データ伝達経路である。ＰＬＰは、データパイプ（ｄａｔａ ｐｉｐｅ）などの他の用語に代えてもよい。一つの放送サービスは複数のコンポーネントを含むことができる。このとき、複数のコンポーネントはそれぞれ、オーディオ、ビデオ及びデータコンポーネントのいずれか一つであってもよい。各放送局は、放送伝送装置３００を介してカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された放送サービスを１つ又は複数のＰＬＰで伝送することができる。具体的に、放送局は、放送伝送装置３００を介して、一つのサービスに含まれた複数のコンポーネントを複数のＰＬＰで伝送することができる。又は、放送局は、放送伝送装置３００を介して、一つのサービスに含まれた複数のコンポーネントを一つのＰＬＰで伝送することができる。例えば、図２８の実施例で、第１の放送局Ｂｒｏａｄｃａｓｔ ＃１は、放送伝送装置３００を介して、シグナリング情報を一つのＰＬＰ（ＰＬＰ ＃０）で伝送することができる。また、図２８の実施例で第１の放送局Ｂｒｏａｄｃａｓｔ ＃１は、放送伝送装置３００を介して、第１の放送サービスに含まれた第１のコンポーネントＣｏｍｐｏｎｅｎｔ１及び第２のコンポーネントＣｏｍｐｏｎｅｎｔ２をそれぞれ他の第１のＰＬＰ（ＰＬＰ ＃１）及び第２のＰＬＰ（ＰＬＰ ＃２）で伝送する。また、図２８の実施例で第Ｎの放送局Ｂｒａｏａｄｃａｓｔ ＃Ｎは、第１の放送サービスＳｅｒｖｉｃｅ ＃１に含まれた第１のコンポーネントＣｏｍｐｏｎｅｎｔ１及び第２のコンポーネントＣｏｍｐｏｎｅｎｔ２を第ＮのＰＬＰ（ＰＬＰ ＃Ｎ）で伝送する。このとき、実時間放送サービスは、ＩＰ、ユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ；ＵＤＰ）及び実時間コンテンツ伝送のためのプロトコル、例えば、実時間伝送プロトコル（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ；ＲＴＰ）のうちいずれか一つにカプセル化することができる。非実時間コンテンツ及び非実時間データである場合にも、ＩＰ、ＵＤＰ及びコンテンツ伝送プロトコル、例えば、ＦＬＵＴＥのうち少なくとも一つのパケットにカプセル化することができる。したがって、放送伝送装置３００が送信する物理層フレーム内には、１つ以上のコンポーネントを伝達する複数のＰＬＰを含むことができる。したがって、放送受信装置１００は、放送サービス連結情報を取得する放送サービススキャンを行うために複数のＰＬＰを全て確認しなければならない。そこで、放送受信装置１００が放送サービススキャンを効率的に行うようにする放送伝送方法及び放送受信方法が必要である。

図２９は、本発明の一実施例に係る放送受信装置の構成を示す図である。

図２９の実施例で放送受信装置１００は、受信部１２０及び制御部１５０を含む。受信部１２０は、放送受信部１１０及びインターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ；ＩＰ）通信部１３０を含む。

放送受信部１１０は、チャネル同期化部（Ｃｈａｎｎｅｌ Ｓｙｎｃｈｒｏｎｉｚｅｒ）１１１、チャネルイコライザ（ｃｈａｎｎｅｌ ｅｑｕａｌｉｚｅｒ）１１３及びチャネルデコーダ（ｃｈａｎｎｅｌ ｄｅｃｏｄｅｒ）１１５を含む。

チャネル同期化部１１０は、放送信号を受信できる基底帯域（ｂａｓｅｂａｎｄ）でデコーディングが可能なようにシンボル周波数とタイミングを同期化する。

チャネルイコライザ１１３は、同期化された放送信号の歪みを補償する。具体的に、チャネルイコライザ１１３は、マルチパス（ｍｕｌｔｉｐａｔｈ）、ドップラー効果などによる、同期化された放送信号の歪みを補償する。

チャネルデコーダ１１５は、歪みが補償された放送信号をデコードする。具体的に、チャネルデコーダ１１５は、歪みが補償された放送信号から伝送フレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）を抽出する。このとき、チャネルデコーダ１１５は、順方向誤り訂正（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ；ＦＥＣ）を行うことができる。

ＩＰ通信部１３０は、インターネット網でデータを受信して伝送する。

制御部１５０は、シグナリングデコーダ１５１、伝送パケットインターフェース１５３、広帯域パケットインターフェース１５５、基底帯域動作制御部１５７、共通プロトコルスタック（Ｃｏｍｍｏｎ Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）１５９、サービスマップデータベース１６１、サービスシグナリングチャネルプロセシングバッファー及びパーサー１６３、Ａ／Ｖプロセッサ１６５、放送サービスガイドプロセッサ１６７、アプリケーションプロセッサ１６９、及びサービスガイドデータベース１７１を含む。

シグナリングデコーダ１５１は、放送信号のシグナリング情報をデコードする。

伝送パケットインターフェース１５３は、放送信号から伝送パケットを抽出する。このとき、伝送パケットインターフェース１５３は、抽出した伝送パケットからシグナリング情報又はＩＰデータグラムなどのデータを抽出することができる。

広帯域パケットインターフェース１５５は、インターネット網から受信したデータからＩＰパケットを抽出する。このとき、広帯域パケットインターフェース１５５は、ＩＰパケットからシグナリングデータ又はＩＰデータックラムを抽出することができる。

基底帯域動作制御部１５７は、基底帯域から放送情報受信情報を受信することに関連した動作を制御する。

共通プロトコルスタック１５９は、伝送パケットからオーディオ又はビデオを抽出する。

Ａ／Ｖプロセッサ１６５は、オーディオ又はビデオを処理する。

サービスシグナリングチャネルプロセシングバッファー及びパーサー１６３は、放送サービスをシグナルするシグナリング情報をパースしてバッファリングする。具体的に、サービスシグナリングチャネルプロセシングバッファー及びパーサー１６３は、ＩＰデータグラムから放送サービスをシグナルするシグナリング情報をパースしてバッファリングすることができる。

サービスマップデータベース１６５は、放送サービスに関する情報を含む放送サービスリストを保存する。

サービスガイドプロセッサ１６７は、地上波放送サービスのプログラムを案内する地上波放送サービスガイドデータを処理する。

アプリケーションプロセッサ１６９は、放送信号からアプリケーション関連情報を抽出して処理する。

サービスガイドデータベース１７１は、放送サービスのプログラム情報を保存する。

図３０及び図３１は、本発明の他の実施例に係る放送受信装置の構成を示す図である。

図３０及び図３１の実施例で、放送受信装置１００は、放送受信部１１０、インターネットプロトコル通信部１３０及び制御部１５０を含む。

放送受信部１１０は、チューナー１１４、物理フレームパーサー（Ｐｈｙｓｉｃａｌ Ｆｒａｍｅ Ｐａｒｓｅｒ）１１６、及び物理層コントローラ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｃｏｎｔｒｏｌｌｅｒ）１１８を含むことができる。

チューナー１１４は、放送チャネルを介して放送信号を受信し、物理フレームを抽出する。物理フレームは、物理層上の伝送単位である。物理フレームパーサー１１６は、受信された物理フレームをパースしてリンク層フレーム（Ｌｉｎｋ Ｌａｙｅｒ Ｆｒａｍｅ）を取得する。

物理層コントローラ１１８は、チューナー１１４及び物理フレームパーサー１１６の動作を制御する。一実施例で、物理層コントローラ１１８は、放送チャネルのＲＦ情報を用いてチューナー１１４を制御することができる。具体的に、物理層コントローラ１１８が周波数情報をチューナー１１４に伝送すると、チューナー１１４は、受信した周波数情報に該当する物理フレームを放送信号から取得することができる。

他の実施例で、物理層コントローラ１１８は、物理層パイプの識別子を用いて物理層パーサー１１６の動作を制御することができる。具体的に、物理層コントローラ１１８は、物理層パイプを構成する複数の物理層パイプの中から特定の物理層パイプを識別するための識別子情報を物理フレームパーサー１１６に伝送する。物理フレームパーサー１１６は、受信した識別子情報に基づいて物理層パイプを識別し、識別した物理層パイプからリンク層フレームを取得することができる。

制御部１５０は、リンク層フレームパーサー（Ｌｉｎｋ Ｌａｙｅｒ Ｆｒａｍｅ Ｐａｒｓｅｒ）１６４、ＩＰ／ＵＤＰデータグラムフィルタ（ＩＰ／ＵＤＰ Ｄａｔａｇｒａｍ Ｆｉｌｔｅｒ）１７１、ＤＴＶコントロールエンジン１７４、ＡＬＣ／ＬＣＴ＋クライアント１７２、タイミングコントロール１７５、ＤＡＳＨクライアント１９２、ＩＳＯＢＭＦＦパーサー１９４及びメディアデコーダ１９５を含む。

リンク層フレームパーサー１６４は、リンク層フレームからデータを抽出する。具体的に、リンク層フレームパーサー１６４は、リンク層フレームからリンク層シグナリングを取得することができる。また、リンク層フレームパーサー１６４は、リンク層フレームからＩＰ／ＵＤＰデータグラムを取得することができる。

ＩＰ／ＵＤＰデータグラムフィルタ（Ｄａｔａｇｒａｍ Ｆｉｌｔｅｒ）１７１は、リンク層フレームパーサー１６４から受信したＩＰ／ＵＤＰデータグラムから特定ＩＰ／ＵＤＰデータグラムをフィルタリングする。

ＡＬＣ／ＬＣＴ＋クライアント１７２は、アプリケーション層伝送パケットを処理する。アプリケーション層伝送パケットは、ＡＬＣ／ＬＣＴ＋パケットを含むことができる。具体的に、ＡＬＣ／ＬＣＴ＋クライアント１７２は、複数のアプリケーション層伝送パケットを収集して、１つ以上のＩＳＯＢＭＦＦメディアファイルフォーマットオブジェクトを生成することができる。

タイミングコントロール１７５は、システムタイム情報を含むパケットを処理する。そして、タイミングコントロール１７５は、処理した結果に基づいてシステムクロックを制御する。

ＤＡＳＨクライアント１９２は、実時間ストリーミング又は適応型メディアストリーミングを処理する。具体的に、ＤＡＳＨクライアント１９２は、ＨＴＴＰに基づく適応型メディアストリーミングを処理してＤＡＳＨセグメントを取得することができる。このとき、ＤＡＳＨセグメントは、ＩＳＯＢＭＦＦオブジェクトの形態であってもよい。

ＩＳＯＢＭＦＦパーサー１９４は、ＤＡＳＨクライアント１９２から受信したＩＳＯＢＭＦＦオブジェクトからオーディオ／ビデオデータを抽出する。このとき、ＩＳＯＢＭＦＦパーサー１９４は、オーディオ／ビデオデータをアクセスユニット（Ａｃｃｅｓｓ Ｕｎｉｔ）単位で抽出することができる。また、ＩＳＯＢＭＦＦ１９４は、ＩＳＯＢＭＦＦオブジェクトからオーディオ／ビデオのためのタイミング情報を取得することができる。

メディアデコーダ１９５は、受信されたオーディオ及びビデオデータをデコードする。また、メディアデコーダ１９５は、デコードした結果をメディア出力端で再生（ｐｒｅｓｅｎｔａｔｉｏｎ）する。

ＤＴＶコントロールエンジン１７４は、各モジュール間のインターフェースを担当する。具体的に、ＤＴＶコントロールエンジン１７４は、各モジュールの動作のために必要なパラメータを伝達して各モジュールの動作を制御することができる。

インターネットプロトコル通信部１３０は、ＨＴＴＰアクセスクライアント１３５を含むことができる。ＨＴＴＰアクセスクライアント１３５は、ＨＴＴＰサーバーと要求を送／受信したり、要求に対する応答を送／受信することができる。

図３２は、本発明の更に他の実施例に係る放送受信装置の構成を示す図である。

図３２の実施例で、放送受信装置１００は、放送受信部１１０、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ；ＩＰ）通信部１３０及び制御部１５０を含む。

放送受信部１１０は、放送受信部１１０が行う複数の機能をそれぞれ行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、放送受信部１１０は、複数の半導体部品が一つに集積されるシステムオンチップ（Ｓｙｓｔｅｍ Ｏｎ Ｃｈｉｐ；ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサと、ＤＲＡＭなどの半導体が一つに統合された半導体であってもよい。放送受信部１１０は、物理層モジュール１１９、物理層ＩＰフレームモジュール１１７を含むことができる。物理層モジュール１１９は、放送網の放送チャネルを介して放送関連信号を受信して処理する。物理層ＩＰフレームモジュール１１７は、物理層モジュール１１９から取得したＩＰデータグラムなどのデータパケットを特定フレームに変換する。例えば、物理層モジュール１１９は、ＩＰデータグラムなどをＲＳフレーム又はＧＳＥなどに変換することができる。

ＩＰ通信部１３０は、ＩＰ通信部１３０が行う複数の機能をそれぞれ行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的にＩＰ通信部１３０は、複数の半導体部品が一つに集積されるシステムオンチップ（Ｓｙｓｔｅｍ Ｏｎ Ｃｈｉｐ；ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサと、ＤＲＡＭなどの半導体が一つに統合された半導体であってもよい。ＩＰ通信部１３０は、インターネット接近制御モジュール１３１を含むことができる。インターネット接近制御モジュール１３１は、インターネット通信網（ｂｒｏａｄｂａｎｄ）を介してサービス、コンテンツ及びシグナリングデータのうち少なくとも一つを取得するための放送受信装置１００の動作を制御する。

制御部１５０は、制御部１５０が行う複数の機能をそれぞれ行う１つ又は複数のプロセッサ、１つ又は複数の回路、及び１つ又は複数のハードウェアモジュールを含むことができる。具体的に、制御部１５０は、複数の半導体部品が一つに集積されるシステムオンチップ（Ｓｙｓｔｅｍ Ｏｎ Ｃｈｉｐ；ＳＯＣ）であってもよい。このとき、ＳＯＣは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品と、プロセッサと、ＤＲＡＭなどの半導体が一つに統合された半導体であってもよい。制御部１５０は、シグナリングデコーダ１５１、サービスマップデータベース１６１、サービスシグナリングチャネルパーサー１６３、アプリケーションシグナリングパーサー１６６、アラートシグナリングパーサー１６８、ターゲッティングシグナリングパーサー１７０、ターゲッティングプロセッサ１７３、Ａ／Ｖプロセッサ１６１、アラーティング（Ａｌｅｒｔｉｎｇ）プロセッサ１６２、アプリケーションプロセッサ１６９、スケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２、ユーザ要求ストリーミングデコーダ１８３、ファイルデータベース１８４、コンポーネント同期化部１８５、サービス／コンテンツ取得制御部１８７、再分配モジュール１８９、装置管理者１９３、及びデータシェアリング部１９１のうち少なくとも一つを含むことができる。

サービス／コンテンツ取得制御部１８７は、放送網又はインターネット通信網を介して取得したサービス、コンテンツ、サービス又はコンテンツと関連したシグナリングデータの取得のための受信機の動作を制御する。

シグナリングデコーダ１５１は、シグナリング情報をデコードする。

サービスシグナリングパーサー１６３は、サービスシグナリング情報をパースする。

アプリケーションシグナリングパーサー１６６は、サービスに関連したシグナリング情報を抽出してパースする。このとき、サービスに関連したシグナリング情報は、サービススキャンに関連したシグナリング情報であってもよい。また、サービスに関連したシグナリング情報は、サービスで提供されるコンテンツに関連したシグナリング情報であってもよい。

アラートシグナリングパーサー１６８は、アラーティングに関連したシグナリング情報を抽出してパースする。

ターゲッティングシグナリングパーサー１７０は、サービス又はコンテンツを個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）するための情報、又はターゲッティング情報をシグナルする情報を抽出してパースする。

ターゲッティングプロセッサ１７３は、サービス又はコンテンツを個人化するための情報を処理する。

アラーティングプロセッサ１６２は、アラーティングに関連したシグナリング情報を処理する。

アプリケーションプロセッサ１６９は、アプリケーション関連情報及びアプリケーションの実行を制御する。具体的に、アプリケーションプロセッサ１６９は、ダウンロードされたアプリケーションの状態及びディスプレイパラメータを処理する。

Ａ／Ｖプロセッサ１６１は、デコードされたオーディオ又はビデオ、アプリケーションデータなどに基づいてオーディオ／ビデオのレンダリング関連動作を処理する。

スケジュールドストリーミングデコーダ１８１は、あらかじめ放送会社などのコンテンツプロバイダが定めた日程とおりにストリーミングされるコンテンツであるスケジュールドストリーミングをデコードする。

ファイルデコーダ１８２は、ダウンロードされたファイルをデコードする。特に、ファイルデコーダ１８２は、インターネット通信網でダウンロードされたファイルをデコードする。

ユーザ要求ストリーミングデコーダ１８３は、ユーザ要求によって提供されるコンテンツ（Ｏｎ Ｄｅｍａｎｄ Ｃｏｎｔｅｎｔ）をデコードする。

ファイルデータベース１８４は、ファイルを保存する。具体的に、ファイルデータベース１８４は、インターネット通信網でダウンロードしたファイルを保存することができる。

コンポーネント同期化部１８５は、コンテンツ又はサービスを同期化する。具体的に、コンポーネント同期化部１８５は、スケジュールドストリーミングデコーダ１８１、ファイルデコーダ１８２、及びユーザ要求ストリーミングデコーダ１８３のうち少なくとも一つから取得したコンテンツに対する再生時間の同期化を行う。

サービス／コンテンツ取得制御部１８７は、サービス、コンテンツ、サービス又はコンテンツに関連したシグナリング情報のうち少なくとも一つを取得するための受信機の動作を制御する。

再分配モジュール１８９は、放送網を介してサービス又はコンテンツを受信できない場合、サービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうち少なくとも一つの取得を支援するための動作を行う。具体的に、外部の管理装置３００にサービス、コンテンツ、サービス関連情報及びコンテンツ関連情報のうち少なくとも一つを要求することができる。このとき、外部の管理装置３００はコンテンツサーバーであってもよい。

装置管理者１９３は、連動可能な外部装置を管理する。具体的に、装置管理者１９３は、外部装置の追加、削除及び更新の少なくとも一つを行うことができる。また、外部装置は、放送受信装置１００と連結及びデータ交換が可能であってもよい。

データシェアリング部１９１は、放送受信装置１００と外部装置の間のデータ伝送動作を行い、交換関連情報を処理する。具体的に、データシェアリング部１９１は外部装置にＡ／Ｖデータ又はシグナリング情報を伝送することができる。また、データシェアリング部１９１は外部装置からＡ／Ｖデータ又はシグナリング情報を受信することができる。

図３３は、本発明の一実施例に係る放送伝送フレームを示す図である。

図３３の実施例で、放送伝送フレームは、Ｐ１パート、Ｌ１パート、共通ＰＬＰ（Ｃｏｍｍｏｎ ＰＬＰ）パート、インターリーブドＰＬＰ（Ｓｃｈｅｄｕｌｅｄ ＆ Ｉｎｔｅｒｌｅａｖｅｄ ＰＬＰ’ｓ）パート、及び補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）パートを含む。

図３３の実施例で、放送伝送装置は、伝送シグナル探知（ｔｒａｎｓｐｏｒｔ ｓｉｇｎａｌ ｄｅｔｅｃｔｉｏｎ）のための情報を放送伝送フレーム（ｔｒａｎｓｐｏｒｔ ｆｒａｍｅ）のＰ１パートで伝送する。また、放送伝送装置は、放送信号チューニングのためのチューニング情報をＰ１パートで伝送することができる。

図３３の実施例で、放送伝送装置は、放送伝送フレームの構成及び各ＰＬＰの特性をＬ１パートで伝送する。このとき、放送受信装置１００は、Ｐ１に基づいてＬ１パートをデコードし、放送伝送フレームの構成及び各ＰＬＰの特性を取得することができる。

図３３の実施例で、放送伝送装置は、ＰＬＰ間に共通して適用される情報をＣｏｍｍｏｎ ＰＬＰパートで伝送することができる。具体的な実施例によって、放送伝送フレームはＣｏｍｍｏｎ ＰＬＰパートを含まなくてもよい。

図３３の実施例で、放送伝送装置は、放送サービスに含まれた複数のコンポーネントをインターリーブド（ｉｎｔｅｒｌｅａｖｅｄ）ＰＬＰパートで伝送する。このとき、インターリーブドＰＬＰパートは、複数のＰＬＰを含む。

図３３の実施例で、放送伝送装置は、各放送サービスを構成するコンポーネントがそれぞれどのＰＬＰで伝送されるかを、Ｌ１パート又はＣｏｍｍｏｎ ＰＬＰパートでシグナルすることができる。ただし、放送受信装置１００が放送サービススキャンなどのために具体的な放送サービス情報を取得するには、インターリーブドＰＬＰパートの複数のＰＬＰを全てデコードする必要がある。

図３３の実施例とは違い、放送伝送装置は、放送伝送フレームで伝送される放送サービスと、放送サービスに含まれたコンポーネントに関する情報を含む別途のパートを含む放送伝送フレームを伝送することができる。このとき、放送受信装置１００は、別途のパートを介して迅速に放送サービス及び放送サービスに含まれたコンポーネントに関する情報を取得することができる。これについては、図３２を参照して説明する。

図３４は、本発明の他の実施例に係る放送伝送フレームを示す図である。

図３４の実施例で、放送伝送フレームは、Ｐ１パート、Ｌ１パート、高速情報チャネル（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ；ＦＩＣ）パート、インターリーブドＰＬＰ（Ｓｃｈｅｄｕｌｅｄ ＆ Ｉｎｔｅｒｌｅａｖｅｄ ＰＬＰ’ｓ）パート、及び補助データ（Ａｕｘｉｌｉａｒｙ ｄａｔａ）パートを含む。

ＦＩＣパート以外のパートは、図３３の実施例と同一である。

放送伝送装置は、高速情報（ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎ）をＦＩＣパートで伝送する。高速情報は、伝送フレームで伝送される放送ストリームの構成情報（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）、簡略な放送サービス情報、及び当該サービス／コンポーネントに関連したサービスシグナリングを含むことができる。放送受信装置１００は、ＦＩＣパートに基づいて放送サービスをスキャンすることができる。具体的に、放送受信装置１００は、ＦＩＣパートから放送サービスに関する情報を抽出することができる。

図３５は、本発明の一実施例に係る伝送パケットの構成を示す図である。図３５に示す伝送パケットは、信頼できるデータ伝送を支援する伝送プロトコルを利用することができる。具体的な実施例で、信頼できるデータ伝送プロトコルは、非同期階層化コーディング（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ（ＡＬＣ））であってもよい。他の実施例で、信頼できるデータ伝送プロトコルは、階層化コーディング伝送（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ（ＬＣＴ））であってもよい。

本発明の一実施例に係るパケットヘッダーは、パケットのバージョン情報を含むことができる。具体的に、当該伝送プロトコルを利用する伝送パケットのバージョン情報を含むことができる。具体的な実施例で、上述した情報はＶフィールドであってもよい。また、Ｖフィールドは４ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、混雑制御（Ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ）のための情報の長さに関連した情報を含むことができる。具体的に、混雑制御のための情報の長さと、混雑制御のための情報の長さの基本単位に乗じる関連した倍数情報を含むことができる。

具体的な実施例で、上述した情報はＣフィールドであってもよい。一実施例で、Ｃフィールドは０ｘ００に設定でき、この場合、混雑制御のための情報の長さが３２ビットであることを示す。他の実施例で、Ｃフィールドは０ｘ０１に設定でき、この場合、混雑制御のための情報の長さは６４ビットであってもよい。他の実施例で、Ｃフィールドは０ｘ０２に設定でき、この場合、混雑制御のための情報の長さは９６ビットであってもよい。他の実施例で、Ｃフィールドは０ｘ０３に設定でき、この場合、混雑制御のための情報の長さは１２８ビットであってもよい。Ｃフィールドは２ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、プロトコルに特化された情報を含むことができる。具体的な実施例で、上述した情報は、ＰＳＩフィールドであってもよい。また、ＰＳＩフィールドは２ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、伝送セッションの識別情報を示すフィールドの長さに関連した情報を含むことができる。具体的に、伝送セッションの識別情報を示すフィールドの倍数情報を含むことができる。上述した情報はＳフィールドであってもよい。Ｓフィールドは１ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、伝送オブジェクトの識別情報を示すフィールドの長さに関連した情報を含むことができる。具体的に、伝送オブジェクトの識別情報を示すフィールドの基本長に乗じる倍数情報を含むことができる。上述した情報はＯフィールドであってもよい。Ｏフィールドは２ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、伝送セッションの識別情報を示すフィールドの長さに関連した追加の情報を含むことができる。そして、パケットヘッダーは、伝送オブジェクトの識別情報を示すフィールドの長さに関連した追加の情報を含むことができる。追加の情報は、ハーフ−ワード（ｈａｌｆ−ｗｏｒｄ）が追加されるか否かを示す情報であってもよい。伝送パケットの識別情報を示すフィールド及び伝送オブジェクトの識別情報を示すフィールドは存在する必要があるため、ＳフィールドとＨフィールド、又はＯフィールドとＨフィールドが同時に０（Ｚｅｒｏ）を示すことはできない。

また、本発明の一実施例に係るパケットヘッダーは、セッションが終了したか、終了が差し迫っていることを示す情報を含むことができる。この情報はＡフィールドであってもよい。具体的な実施例で、Ａフィールドが、セッションが終了したこと又は終了に差し迫っていることを示す場合には、１に設定することができる。したがって、通常の場合、Ａフィールドは０に設定することができる。放送伝送装置がＡフィールドを１に設定する場合、セッションで最後のパケットが伝送されていることを示すことができる。Ａフィールドが１に設定された場合、放送伝送装置は、当該パケットに続く全パケットの伝送が終了するまでＡフィールドを１に保持しなければならない。また、放送受信装置は、Ａフィールドが１に設定された場合、放送伝送装置がセッションでパケット伝送をまもなく中断することを認識することができる。言い換えると、放送受信装置は、Ａフィールドが１に設定された場合、セッションでそれ以上パケットを伝送しないことと認識できる。一実施例で、Ａフィールドは１ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、オブジェクトの伝送が終了したか、終了が差し迫っていることを示す情報を含むことができる。上述した情報はＢフィールドであってもよい。具体的な実施例で、放送伝送装置は、オブジェクトの伝送終了が差し迫っている場合、Ｂフィールドを１に設定できる。したがって、通常の場合、Ｂフィールドは０に設定することができる。伝送オブジェクトを識別する情報が伝送パケットに存在しない場合、Ｂフィールドは１に設定されてもよい。そして、アウト−オブ−バンド（ｏｕｔ−ｏｆ−ｂａｎｄ）情報によって識別されたセッション内のオブジェクト伝送終了が差し迫っていることを示すことができる。また、Ｂフィールドは、オブジェクトのための最後のパケットが伝送される場合、１に設定されてもよい。また、Ｂフィールドは、オブジェクトのための最後の数秒のパケットが伝送される場合、１に設定されてもよい。放送伝送装置は、特定オブジェクトのためのパケットのＢフィールドが１に設定された場合、当該パケットに続くパケットの伝送が終了するまでＢフィールドを１に設定しなければならない。放送受信装置１００は、Ｂフィールドが１に設定されていると、放送伝送装置がオブジェクトのためのパケットの伝送を中断するはずであることが認識できる。言い換えると、放送受信装置１００は、１に設定されたＢフィールドから、セッションでそれ以上オブジェクトを伝送しないことと認識できる。一実施例で、Ｂフィールドは１ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、ヘッダーの全長を示す情報を含むことができる。この情報はＨＤＲ＿ＬＥＮフィールドであってもよい。ＨＤＲ＿ＬＥＮフィールドは、３２の倍数ビットであってもよい。具体的な実施例で、ＨＤＲ＿ＬＥＮフィールドが５に設定された場合、パケットヘッダーの全長は３２の５倍数である１６０ビットであってもよい。また、ＨＤＲ＿ＬＥＮフィールドは８ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、当該パケットに含まれたペイロードのエンコーディング又はデコーディングに関連した情報を含むことができる。この情報はＣｏｄｅｐｏｉｎｔフィールドであってもよい。一実施例で、Ｃｏｄｅｐｏｉｎｔフィールドは８ビットであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、混雑制御のための情報を含むことができる。この情報はＣｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ（以下、ＣＣＩ）フィールドであってもよい。具体的な実施例で、ＣＣＩフィールドは、Ｃｕｒｒｅｎｔ ｔｉｍｅ ｓｌｏｔ ｉｎｄｅｘ（ＣＴＳＩ）フィールド、ｃｈａｎｎｅｌ ｎｕｍｂｅｒフィールド及びｐａｃｋｅｔ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒフィールドのうち少なくとも一つを含むことができる。

また、本発明の一実施例に係るパケットヘッダーは、伝送セッションの識別のための情報を含むことができる。上述した情報は、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＳＩ））であってもよい。また、ＴＳＩ情報を含むパケットヘッダー内フィールドはＴＳＩフィールドであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、伝送セッションで伝送されるオブジェクトの識別のための情報を含むことができる。この情報は、伝送オブジェクト識別子（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ（以下、ＴＯＩ））であってもよい。また、ＴＯＩ情報を含むパケットヘッダー内フィールドはＴＯＩフィールドであってもよい。

また、本発明の一実施例に係るパケットヘッダーは、追加の情報を伝送するための情報を含むことができる。この情報は、Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎフィールドであってもよい。一実施例で、追加の情報は、伝送オブジェクトの再生に関連した時間情報であってもよい。他の実施例で、追加の情報は、伝送オブジェクトのデコーディングに関連した時間情報であってもよい。

また、本発明の一実施例に係る伝送パケットは、ペイロード識別情報を含むことができる。一実施例で、識別情報は、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）スキームに関連したペイロード識別情報であってもよい。ここで、ＦＥＣは、ＲＦＣ５１０９に定義されているペイロードフォーマットの一類型である。ＦＥＣは、ＲＴＰ又はＳＲＴＰで用いられてもよい。この情報は、ＦＥＣ Ｐａｙｌｏａｄ ＩＤフィールドであってもよい。

一実施例で、ＦＥＣ Ｐａｙｌｏａｄ ＩＤフィールドは、オブジェクトのソースブロックを識別するための情報を含むことができる。この情報は、Ｓｏｕｒｃｅ ｂｌｏｃｋ ｎｕｍｂｅｒフィールドであってもよい。例えば、Ｓｏｕｒｃｅ ｂｌｏｃｋ ｎｕｍｂｅｒフィールドがＮに設定されると、オブジェクト内ソースブロックは０からＮ−１までナンバリングされてもよい。

他の実施例で、ＦＥＣ Ｐａｙｌｏａｄ ＩＤフィールドは、特定エンコーディングシンボルを識別するための情報を含むことができる。この情報は、Ｅｎｃｏｄｉｎｇ ｓｙｍｂｏｌ ＩＤフィールドであってもよい。

また、本発明の一実施例で、伝送パケットはペイロード内データを含むことができる。このデータを含んでいるフィールドは、Ｅｎｃｏｄｉｎｇ ｓｙｍｂｏｌ（ｓ）フィールドであってもよい。一実施例で、放送受信装置１００は、Ｅｎｃｏｄｉｎｇ ｓｙｍｂｏｌ（ｓ）フィールドを抽出してオブジェクトを再構成することができる。具体的に、パケットペイロードで伝送されるソースブロックからＥｎｃｏｄｉｎｇ ｓｙｍｂｏｌ（ｓ）フィールド内データが生成されてもよい。

図３６は、本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。具体的に、図３６は、本発明の一実施例に係るサービスシグナリングメッセージヘッダーのシンタクスを示すことができる。本発明の一実施例に係るサービスシグナリングメッセージは、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。このとき、シグナリングメッセージは、バイナリ又はＸＭＬフォーマットで表現することができる。また、サービスシグナリングメッセージは伝送プロトコルパケットのペイロードに含まれてもよい。

図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージを識別する識別子情報を含むことができる。例えば、シグナリングメッセージはセクションの形態であってもよい。この場合、シグナリングメッセージの識別子情報は、シグナリングテーブルセクションの識別子（ＩＤ）を示すことができる。シグナリングメッセージの識別子情報を示すフィールドは、ｓｉｎｇｎａｌｉｎｇ＿ｉｄであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは８ビットであってもよい。

また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの長さを示す長さ情報を含むことができる。シグナリングメッセージの長さ情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈフィールドは１２ビットであってもよい。

また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの識別子を拡張する識別子拡張情報を含むことができる。このとき、識別子拡張情報は、シグナリング識別子情報と共にシグナリングを識別する情報であってもよい。シグナリングメッセージの識別子拡張情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎであってもよい。

このとき、識別子拡張情報は、シグナリングメッセージのプロトコルバージョン情報を含むことができる。シグナリングメッセージのプロトコルバージョン情報を示すフィールドは、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎであってもよい。具体的な実施例で、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは８ビットであってもよい。

また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのバージョン情報を含むことができる。シグナリングメッセージのバージョン情報は、シグナリングメッセージが含む内容が変更される度に変更されてもよい。シグナリングメッセージのバージョン情報を示すフィールドは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは５ビットであってもよい。

また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージが現在利用可能なか否かを示す情報を含むことができる。シグナリングメッセージが利用可能か否かを示すフィールドは、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒであってもよい。具体的な例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが１である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、シグナリングメッセージが利用可能であることを示すことができる。他の例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが０である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドはシグナリングメッセージが利用不可であり、その後、同じシグナリング識別子情報、シグナリング識別子拡張情報又はフラグメントナンバー情報を含む他のシグナリングメッセージが利用可能であることを示すことができる。

また、図３６の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのフラグメント（Ｆｒａｇｍｅｎｔ）ナンバー情報を含むことができる。一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送されてもよい。したがって、受信機が分けられた複数のフラグメントを識別するための情報は、フラグメントナンバー情報であってもよい。フラグメントナンバー情報を示すフィールドは、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドであってもよい。具体的な実施例で、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。

また、図３６の実施例に係るシグナリングメッセージヘッダーは、一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送される場合、最後のフラグメントのナンバー情報を含むことができる。例えば、最後のフラグメントナンバーに関する情報が３を示す場合、シグナリングメッセージが３個に分けられて伝送されることを示すことができる。また、３を示すフラグメントナンバーを含むフラグメントがシグナリングメッセージの最後のデータを含むことを示すことができる。最後のフラグメントのナンバー情報を示すフィールドは、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。

図３７は、本発明の一実施例に係るサービスシグナリングメッセージの構成を示す図である。具体的に、図３７は、本発明の一実施例に係るサービスシグナリングメッセージヘッダーのシンタクスを示すことができる。本発明の一実施例に係るサービスシグナリングメッセージは、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。このとき、シグナリングメッセージはバイナリ又はＸＭＬフォーマットで表現することができる。また、サービスシグナリングメッセージは、伝送プロトコルパケットのペイロードに含まれてもよい。

図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージを識別する識別子情報を含むことができる。例えば、シグナリングメッセージがセクションの形態であってもよい。この場合、シグナリングメッセージの識別子情報は、シグナリングテーブルセクションの識別子（ＩＤ）を示すことができる。シグナリングメッセージの識別子情報を示すフィールドは、ｓｉｎｇｎａｌｉｎｇ＿ｉｄであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは８ビットであってもよい。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの長さを示す長さ情報を含むことができる。シグナリングメッセージの長さ情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｌｅｎｇｔｈフィールドは１２ビットであってもよい。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージの識別子を拡張する識別子拡張情報を含むことができる。このとき、識別子拡張情報は、シグナリング識別子情報と共にシグナリングを識別する情報であってもよい。シグナリングメッセージの識別子拡張情報を示すフィールドは、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎであってもよい。

このとき、識別子拡張情報は、シグナリングメッセージのプロトコルバージョン情報を含むことができる。シグナリングメッセージのプロトコルバージョン情報を示すフィールドは、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎであってもよい。具体的な実施例で、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは８ビットであってもよい。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのバージョン情報を含むことができる。シグナリングメッセージのバージョン情報は、シグナリングメッセージが含む内容が変更される度に変更されてもよい。シグナリングメッセージのバージョン情報を示すフィールドは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは５ビットであってもよい。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージが現在利用可能なか否かを示す情報を含むことができる。シグナリングメッセージが利用可能か否かを示すフィールドは、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒであってもよい。具体的な例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが１である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、シグナリングメッセージが利用可能であることを示すことができる。他の例として、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドが０である場合、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、シグナリングメッセージが利用不可であり、その後、同じシグナリング識別子情報、シグナリング識別子拡張情報又はフラグメントナンバー情報を含む他のシグナリングメッセージが利用可能であることを示すことができる。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、ペイロードに含まれるシグナリングメッセージのフォーマット情報を含むことができる。上述したように、シグナリングメッセージは、バイナリ又はＸＭＬフォーマットで表現することができる。また、シグナリングメッセージは、他のフォーマットで表現されてもよい。したがって、フォーマット情報は、ペイロードに含まれたシグナリングメッセージがいかなるフォーマットで作成されたかを示すことができ、その例として、ｂｉｎａｒｙ、ＸＭＬなどを挙げることができる。フォーマット情報を示すフィールドは、ｐａｙｌｏａｄ＿ｆｏｒｍａｔフィールドであってもよい。具体的な実施例で、ｐａｙｌｏａｄ＿ｆｏｒｍａｔフィールドは２ビットであってもよい。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、ペイロードに含まれたシグナリングメッセージの有効時間情報を含むことができる。シグナリングメッセージの有効時間情報は、シグナリングメッセージがいつの時間まで有効であるかを示す情報を含むことができ、このフィールドで定義された時間の後には、当該シグナリングメッセージがそれ以上有効でなくてもよい。有効時間情報を示すフィールドは、ｅｘｐｉｒａｔｉｏｎフィールドであってもよい。具体的な実施例で、ｅｘｐｉｒａｔｉｏｎフィールドは３２ビットであってもよい。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、シグナリングメッセージのフラグメント（Ｆｒａｇｍｅｎｔ）ナンバー情報を含むことができる。一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送されてもよい。したがって、受信機が分けられた複数のフラグメントを識別するための情報は、フラグメントナンバー情報であってもよい。フラグメントナンバー情報を示すフィールドは、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドであってもよい。具体的な実施例で、ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。

また、図３７の実施例に係るシグナリングメッセージヘッダーは、一つのシグナリングメッセージが複数個のフラグメントに分けられて伝送される場合、最後のフラグメントのナンバー情報を含むことができる。例えば、最後のフラグメントナンバーに関する情報が３を示す場合、シグナリングメッセージが３個に分けられて伝送されることを示すことができる。また、３を示すフラグメントナンバーを含むフラグメントがシグナリングメッセージの最後のデータを含むことを示すことができる。最後のフラグメントのナンバー情報を示すフィールドは、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒであってもよい。具体的な実施例で、ｌａｓｔ＿ｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒフィールドは８ビットであってもよい。

図３８は、本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示している。一実施例に係る放送サービスシグナリングメッセージは、放送受信装置１００が次世代放送システムで放送サービス及びコンテンツのうち少なくとも一つを受信できるようにするための放送サービスシグナリング方法である。

図３８の実施例に係る放送サービスシグナリング方法は、図３６に示すシグナリングメッセージ構成に基づいてもよい。図３８の実施例に係る放送サービスシグナリングメッセージは、サービスシグナリングチャネルで伝送することができる。このとき、サービスシグナリングチャネルは、放送サービススキャンのためのサービスシグナリング情報を他の層を経由しないで直接伝送するための物理層パイプの一形態を意味することができる。具体的な実施例で、サービスシグナリングチャネルは、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）、ＬＬＳ（Ｌｏｗ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）及びアプリケーション層伝送セッションの少なくとも一つを意味することができる。また、図３８の実施例に係る放送サービスシグナリングメッセージは、ＸＭＬの形態であってもよい。

図３８の実施例に係るサービスシグナリングメッセージは、含んでいるサービスの個数情報を含むことができる。具体的に一つのサービスシグナリングメッセージは複数のサービスを含むことができ、含んでいるサービスの数を示す情報を含むことができる。サービスの個数情報は、ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドであってもよい。具体的な実施例で、ｎｕｍ＿ｓｅｒｖｉｃｅｓフィールドは８ビットであってもよい。

また、図３８の実施例に係るサービスシグナリングメッセージは、サービスに対する識別子情報を含むことができる。識別子情報は、ｓｅｒｖｉｃｅ＿ｉｄフィールドであってもよい。具体的な実施例で、ｓｅｒｖｉｃｅ＿ｉｄフィールドは１６ビットであってもよい。

また、図３８の実施例に係るサービスシグナリングメッセージは、サービスのタイプ情報を含むことができる。サービスタイプ情報は、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドであってもよい。具体的な実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ００値を有する場合、シグナリングメッセージが示すサービスタイプはスケジュールドオーディオサービス（ｓｃｈｅｄｕｌｅｄ ａｕｄｉｏ ｓｅｒｖｉｃｅ）であってもよい。

他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０１値を有する場合、シグナリングメッセージが示すサービスタイプは、スケジュールドオーディオ／ビデオサービス（ｓｃｈｅｄｕｌｅｄ ａｕｄｉｏ／ｖｉｄｅｏ ｓｅｒｖｉｃｅ）であってもよい。このとき、スケジュールドオーディオ／ビデオサービスは、あらかじめ定められたスケジュールによって放送されるオーディオ／ビデオサービスであってもよい。

他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０２値を有する場合、シグナリングメッセージが示すサービスタイプは、オン−デマンドサービス（ｏｎ−ｄｅｍａｎｄ ｓｅｒｖｉｃｅ）であってもよい。このとき、オン−デマンドサービスは、ユーザの要求によって再生されるオーディオ／ビデオサービスであってもよい。また、オン−デマンドサービスは、スケジュールドオーディオ／ビデオサービスと反対のサービスであってもよい。

他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０３値を有する場合、シグナリングメッセージが示すサービスタイプは、アプリベースのサービス（ａｐｐ−ｂａｓｅｄ ｓｅｒｖｉｃｅ）であってもよい。このとき、アプリベースのサービスは、実時間放送サービスでなく非実時間サービスであり、アプリケーションによって提供されるサービスであってもよい。アプリベースのサービスは、実時間放送サービスに関連したサービス及び実時間放送サービスに関連していないサービスのうち少なくとも一つを含むことができる。放送受信装置１００は、アプリケーションをダウンロードしてアプリベースのサービスを提供することができる。

他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０４値を有する場合、シグナリングメッセージが示すサービスタイプは、権利発給者サービス（ｒｉｇｈｔ ｉｓｓｕｅｒ ｓｅｒｖｉｃｅ）であってもよい。このとき、権利発給者サービスは、サービス提供を受ける権利が発給された者にのみ提供されるサービスであってもよい。

他の実施例で、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドが０ｘ０５値を有する場合、シグナリングメッセージが示すサービスタイプは、サービスガイドサービス（ｓｅｒｖｉｃｅ ｇｕｉｄｅ ｓｅｒｖｉｃｅ）であってもよい。このとき、サービスガイドサービスは、提供されるサービスの情報を提供するサービスであってもよい。例えば、提供されるサービスの情報は、放送スケジュールであってもよい。

また、図３８の実施例に係るサービスシグナリングメッセージは、サービス名情報を含むことができる。サービス名情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドであってもよい。

また、図３８の実施例に係るサービスシグナリングメッセージは、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドの長さ情報を含むことができる。ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅフィールドの長さ情報は、ｓｈｏｒｔ＿ｓｅｒｖｉｃｅ＿ｎａｍｅ＿ｌｅｎｇｔｈフィールドであってもよい。

また、図３８の実施例に係るサービスシグナリングメッセージは、シグナルするサービスに関連した放送サービスチャネルナンバー情報を含むことができる。関連した放送サービスチャネルナンバー情報は、ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドであってもよい。

また、図３８の実施例に係るサービスシグナリングメッセージは、以下に説明する各伝送モードによって、放送受信装置がタイムベース（ｔｉｍｅｂａｓｅ）又はシグナリングメッセージを取得するために必要なデータを含むことができる。タイムベース又はシグナリングメッセージを取得するためのデータは、ｂｏｏｔｓｔｒａｐ（）フィールドであってもよい。

上述した伝送モードは、タイムベース伝送モード及びシグナリング伝送モードの少なくとも一つであってもよい。タイムベース伝送モードは、放送サービスで使用するタイムラインに対するメタデータを含むタイムベースに対する伝送モードであってもよい。タイムラインは、メディアコンテンツのための一連の時間情報である。具体的に、タイムラインは、メディアコンテンツ再生の基準となる一連の基準時間であってもよい。タイムベース伝送モードに関する情報は、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

また、シグナリング伝送モードは、放送サービスで使用するシグナリングメッセージを伝送するモードであってもよい。シグナリング伝送モードに関する情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

図３９は、本発明の一実施例に係るサービスシグナリングメッセージでｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが示す値が意味する内容を示している。

タイムベース伝送モードは、放送受信装置１００が放送サービスのタイムベースを同一の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ００の値を有する場合、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送受信装置が放送サービスのタイムベースを同一の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。

また、シグナリング伝送モードは、放送受信装置１００が放送サービスに用いるシグナリングメッセージを、同一の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。他の実施例によれば、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ００の値を有する場合、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送受信装置が放送サービスに用いるシグナリングメッセージを同一の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。同一の放送ストリームとは、放送受信装置が現在サービスシグナリングメッセージを受信した放送ストリームと同じ放送ストリームを意味することができる。また、ＩＰデータグラムは、放送サービス又はコンテンツを構成するコンポーネントをインターネットプロトコルによってカプセル化した一伝送単位を意味することができる。この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図示のシンタクスに従えばよい。図示のシンタクスは、ＸＭＬの形態で表現されてもよい。

図４０は、本発明の一実施例でｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ００値を有する場合、ｂｏｏｔｓｔｒａｐ（）フィールドのシンタクスを示す。

実施例で、ブートストラップ（ｂｏｏｔｓｔｒａｐ）データは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのＩＰアドレス形式に関する情報を含むことができる。ＩＰアドレス形式に関する情報は、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドであってもよい。ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ４であることを示すことができる。一実施例で、ＩＰアドレス形式に関する情報が０である場合、ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ４であることを示すことができる。ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ６であることを示すことができる。他の実施例で、ＩＰアドレス形式に関する情報が１である場合、ＩＰアドレス形式に関する情報は、ＩＰデータグラムのＩＰアドレス形式がＩＰｖ６であることを示すことができる。

実施例で、ブートストラップ（ｂｏｏｔｓｔｒａｐ）データは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムがソースＩＰアドレスを含むか否かを示す情報を含むことができる。このとき、ソースＩＰアドレスは、ＩＰデータグラムの送信元（ｓｏｕｒｃｅ）アドレスであってもよい。ＩＰデータグラムがソースＩＰアドレスを含むか否かを示す情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１である場合、ＩＰデータグラムがソースＩＰアドレスを含むことを示すことができる。

実施例で、ブートストラップデータはタイムベース又はシグナリングメッセージを含むＩＰデータグラムが送信先（ｄｅｓｔｉｎａｔｉｏｎ）ＩＰアドレスを含むか否かを示す情報を含むことができる。このとき、送信先ＩＰアドレスは、ＩＰデータグラムの送信先アドレスであってもよい。ＩＰデータグラムが送信先ＩＰアドレスを含むか否かを示す情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドが１である場合、ＩＰデータグラムが送信先ＩＰアドレスを含むことを示すことができる。

実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのソースＩＰアドレス情報を含むことができる。ソースＩＰアドレス情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。

図３９に係る実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムの送信先ＩＰアドレス情報を含むことができる。送信先ＩＰアドレス情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。

実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのフローポートの個数情報を含むことができる。このとき、ポート（ｐｏｒｔ）は、ＩＰデータグラムのフローを受信するための通路であってもよい。ＩＰデータグラムのＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）ポートの個数を示す情報は、ｐｏｒｔ＿ｎｕｍ＿ｃｏｕｎｔフィールドであってもよい。

実施例で、ブートストラップデータは、タイムベース又はシグナリングメッセージを含むＩＰデータグラムのＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）ポート番号を示す情報を含むことができる。ユーザデータグラムプロトコル（ＵＤＰ）は、インターネットで情報を授受するとき、交換する形式ではなく片方から一方的に送る方式の通信プロトコルである。

再び図３９を参照する。

タイムベース伝送モードは、放送受信装置１００が放送サービスのタイムベースを別の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０１の値を有する場合、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送サービスのタイムベースを別の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。別の放送ストリームは、現在サービスシグナリングメッセージを受信した放送ストリームと異なる放送ストリームを意味することができる。

また、シグナリング伝送モードは、放送受信装置１００が放送サービスに用いるシグナリングメッセージを、別の放送ストリーム内のＩＰデータグラムを通じて取得するモードを含むことができる。他の実施例によれば、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０１の値を有する場合、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドは、放送サービスに用いるシグナリングメッセージを別の放送ストリーム内のＩＰデータグラムを通じて取得できることを示すことができる。この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４１に示すシンタクスを従えばよい。図４１に示すシンタクスはＸＭＬの形態で表現されてもよい。

図４１の実施例に係るブートストラップデータは、シグナリングメッセージを伝送する放送局の識別子情報を含むことができる。具体的に、ブートストラップデータは、特定の周波数又は伝送フレームでシグナリングメッセージを伝送する特定の放送局固有の識別子情報を含むことができる。放送局の識別子情報は、ｂｒｏａｄｃａｓｔｉｎｇ＿ｉｄフィールドであってもよい。また、放送局の識別子情報は、放送サービスを送信する伝送ストリームの識別子情報であってもよい。

再び図３９を参照する。

タイムベース伝送モードは、放送受信装置１００が同一の放送ストリーム内のセッションベースフローを通じてタイムベースを取得するモードを含むことができる。

図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０２の値を有する場合、放送サービスのタイムベースを同一の放送ストリーム内のセッションベースフローを通じて取得できることを示すことができる。これに加えて、シグナリング伝送モードは、放送受信装置１００が同一の放送ストリーム内のセッションベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０２の値を有する場合、放送サービスに用いるシグナリングメッセージを同一の放送ストリーム内のアプリケーション層伝送セッションベースフローを通じて取得できることを示すことができる。このとき、アプリケーション層伝送セッションベースフローは、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）／ＬＣＴ（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）セッション及びＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）セッションのいずれか一つであってもよい。

この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４２に示すシンタクスに従えばよい。図４２に示すシンタクスは、ＸＭＬの形態で表現されてもよい。

図４２の実施例に係るブートストラップデータは、タイムベース又はシグナリングメッセージを含むアプリケーション層伝送パケットを伝送するアプリケーション層伝送セッションの識別子（ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）情報を含むことができる。このとき、伝送パケットを伝送するセッションは、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションのいずれか一つであってもよい。アプリケーション層伝送セッションの識別子情報は、ｔｓｉフィールドであってもよい。

再び図３９を参照する。

タイムベース伝送モードは、放送受信装置１００が別の放送ストリーム内のセッションベースフローを通じてタイムベースを取得するモードを含むことができる。図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０３の値を有する場合、放送サービスのタイムベースを別の放送ストリーム内のセッションベースフローを通じて取得できることを示すことができる。これに加えて、シグナリング伝送モードは、放送受信装置１００が同一の放送ストリーム内のセッションベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０３の値を有する場合、放送サービスに用いるシグナリングメッセージを別の放送ストリーム内のアプリケーション層伝送セッションベースフローを通じて取得できることを示すことができる。このとき、アプリケーション層伝送セッションベースフローは、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）／ＬＣＴ（Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ Ｔｒａｎｓｐｏｒｔ）セッション及びＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）セッションの少なくとも一つであってもよい。

この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４３に示すシンタクスに従えばよい。図４３に示すシンタクスは、ＸＭＬの形態で表現されてもよい。

図４３の実施例に係るブートストラップデータは、シグナリングメッセージを伝送する放送局の識別子情報を含むことができる。具体的に、ブートストラップデータは、特定の周波数又は伝送フレームでシグナリングメッセージを伝送する特定の放送局固有の識別子情報を含むことができる。放送局の識別子情報は、ｂｒｏａｄｃａｓｔｉｎｇ＿ｉｄフィールドであってもよい。また、放送局の識別子情報は、放送サービスの伝送ストリームの識別子情報であってもよい。

再び図３９を参照する。

タイムベース伝送モードは、放送受信装置１００が同一の放送ストリーム内のパケットベースフローを通じてタイムベースを取得するモードを含むことができる。図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０４の値を有する場合、放送サービスのタイムベースを同一の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＰＥＧメディア伝送（ＭＰＥＧ Ｍｅｄｉａ Ｔａｎｓｐｏｒｔ；ＭＭＴ）パケットフローであってもよい。

これに加えて、シグナリング伝送モードは、放送受信装置１００が同一の放送ストリーム内のパケットベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０４の値を有する場合、放送サービスに用いるシグナリングメッセージを同一の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＭＴパケットフローであってもよい。

この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４４に示すシンタクスに従えばよい。図４４に示すシンタクスは、ＸＭＬの形態で表現されてもよい。

図４４の実施例に係るブートストラップデータは、タイムベース又はシグナリングメッセージを伝送する伝送パケットの識別子情報を含むことができる。伝送パケットの識別子情報は、ｐａｃｋｅｔ＿ｉｄフィールドであってもよい。伝送パケットの識別子情報は、ＭＰＥＧ−２伝送ストリームの識別子情報であってもよい。

再び図３９を参照する。

タイムベース伝送モードは、放送受信装置１００が別の放送ストリーム内のパケットベースフローを通じてタイムベースを取得するモードを含むことができる。

図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０５の値を有する場合、放送サービスのタイムベースを別の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＰＥＧメディア伝送パケットフローであってもよい。

これに加えて、シグナリング伝送モードは、放送受信装置１００が別の放送ストリーム内のパケットベースフローを通じてシグナリングメッセージを取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０５の値を有する場合、放送サービスに用いるシグナリングメッセージを別の放送ストリーム内のパケットベースフローを通じて取得できることを示すことができる。このとき、パケットベースフローは、ＭＭＴパケットフローであってもよい。

この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４５に示すシンタクスに従えばよい。図４５に示すシンタクスは、ＸＭＬの形態で表現されてもよい。

図４５の実施例に係るブートストラップデータは、シグナリングメッセージを伝送する放送局の識別子情報を含むことができる。具体的に、ブートストラップデータは、特定の周波数又は伝送フレームでシグナリングメッセージを伝送する特定の放送局固有の識別子情報を含むことができる。放送局の識別子情報はｂｒｏａｄｃａｓｔｉｎｇ＿ｉｄフィールドであってもよい。また、放送局の識別子情報は、放送サービスの伝送ストリームの識別子情報であってもよい。

また、図４５の実施例に係るブートストラップデータは、タイムベース又はシグナリングメッセージを伝送する伝送パケットの識別子情報を含むことができる。伝送パケットの識別子情報はｐａｃｋｅｔ＿ｉｄフィールドであってもよい。伝送パケットの識別子情報はＭＰＥＧ−２伝送ストリームの識別子情報であってもよい。

再び図３９を参照する。

タイムベース伝送モードは、放送受信装置１００がタイムベースをＵＲＬを通じて取得するモードを含むことができる。

図３９の他の実施例によれば、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０６の値を有する場合、放送サービスのタイムベースをＵＲＬを通じて取得できることを示すことができる。これに加えて、シグナリング伝送モードは、放送受信装置１００がシグナリングメッセージをＵＲＬを通じて取得するモードを含むことができる。ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが０ｘ０６の値を有する場合、放送サービスに用いるシグナリングメッセージを受信可能なアドレスを識別する識別子を用いて取得できることを示すことができる。このとき、放送サービスに用いるシグナリングメッセージを受信可能なアドレスを識別する識別子は、ＵＲＬであってもよい。

この場合、タイムベース及びシグナリングメッセージに対するｂｏｏｔｓｔｒａｐ（）フィールドは、図４６に示すシンタクスに従えばよい。図４６に示すシンタクスは、ＸＭＬの形態で表現されてもよい。

図４６の実施例に係るブートストラップデータは、放送サービスのタイムベース又はシグナリングメッセージをダウンロード可能なＵＲＬに関する長さ情報を含むことができる。ＵＲＬの長さ情報は、ＵＲＬ＿ｌｅｎｇｔｈフィールドであってもよい。

また、図４６の実施例に係るブートストラップデータは、放送サービスのタイムベース又はシグナリングメッセージをダウンロード可能なＵＲＬの実際データを含むことができる。ＵＲＬの実際データは、ＵＲＬ＿ｃｈａｒフィールドであってもよい。

図４７は、図３８乃至図４６の実施例でタイムベース及びサービスシグナリングメッセージを取得する手順を示す。

図４７に示すように、本発明の一実施例に係る放送受信装置１００は、パケットベース伝送プロトコルによってタイムベースを取得することができる。具体的に、放送受信装置１００は、サービスシグナリングメッセージを用いてＩＰ／ＵＤＰフローを通じてタイムベースを取得することができる。また、本発明の一実施例に係る放送受信装置１００は、セッションベース伝送プロトコルによってサービス関連シグナリングメッセージを取得することができる。具体的に、放送受信装置１００は、ＡＬＣ／ＬＣＴ伝送セッションでサービス関連シグナリングメッセージを取得することができる。

図４８は、本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示している。一実施例に係る放送サービスシグナリングメッセージは、放送受信装置が次世代放送システムで放送サービス及びコンテンツを受信できるようにするためのサービスシグナリング方法である。実施例に係る放送サービスシグナリング方法は、前述したシグナリングメッセージ構成に基づいてもよい。実施例に係る放送サービスシグナリングメッセージは、サービスシグナリングチャネルで伝送されてもよい。このとき、サービスシグナリングチャネルは、放送サービススキャンのためのサービスシグナリング情報を他の層を経由しないで直接伝送するための物理層パイプの一形態を意味することができる。

具体的な実施例で、シグナリングチャネルは、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）、ＬＬＳ（Ｌｏｗ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）、及びアプリケーション伝送セッションの少なくとも一つであってもよい。また、実施例に係る放送サービスシグナリングメッセージは、ＸＭＬの形態で表現されてもよい。

図４８の実施例に係るサービスシグナリングメッセージは、タイムベースを取得するために必要な情報をサービスシグナリングメッセージが含んでいるか否かを示す情報を含むことができる。このとき、タイムベースは、放送サービスに使用するタイムラインに対するメタデータを含むことができる。タイムラインは、メディアコンテンツのための一連の時間情報である。タイムベース取得のための情報を含んでいるか否かを示す情報は、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、サービスシグナリングメッセージがタイムベース伝送のための情報を含んでいることを示すことができる。

図４８の実施例に係るサービスシグナリングメッセージは、以下に説明する各伝送モードによって、放送受信装置がタイムベース（ｔｉｍｅｂａｓｅ）又はシグナリングメッセージを取得するために必要なデータを含むことができる。タイムベース又はシグナリングメッセージを取得するためのデータは、ｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）フィールドであってもよい。

上述した伝送モードは、タイムベース伝送モード及びシグナリング伝送モードの少なくとも一つであってもよい。タイムベース伝送モードは、放送サービスで使用するタイムラインに対するメタデータを含むタイムベースに対する伝送モードであってもよい。タイムベース伝送モードに関する情報は、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

また、シグナリング伝送モードは、放送サービスで使用するシグナリングメッセージを伝送するモードであってもよい。シグナリング伝送モードに関する情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

また、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドによるｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）フィールドの意味は、上述した内容のとおりである。

図４９は、本発明の一実施例に係る次世代放送システムで放送サービスシグナリングメッセージの構成を示している。一実施例に係る放送サービスシグナリングメッセージは、放送受信装置が次世代放送システムで放送サービス及びコンテンツを受信するできるようにするためのサービスシグナリング方法である。実施例に係る放送サービスシグナリング方法は、前述したシグナリングメッセージ構成に基づいてもよい。実施例に係る放送サービスシグナリングメッセージは、サービスシグナリングチャネルで伝送されてもよい。このとき、サービスシグナリングチャネルは、放送サービススキャンのためのサービスシグナリング情報を他の層を経由しないで直接伝送するための物理層パイプ形態であってもよい。具体的な実施例で、シグナリングチャネルは、ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）、ＬＬＳ（Ｌｏｗ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）、及びアプリケーション層伝送セッションの少なくとも一つであってもよい。また、図４８の実施例に係る放送サービスシグナリングメッセージは、ＸＭＬの形態で表現されてもよい。

実施例に係るサービスシグナリングメッセージは、タイムベースを取得するために必要な情報をサービスシグナリングメッセージが含んでいるか否かを示すことができる。このとき、タイムベースは、放送サービスに使用するタイムラインに対するメタデータを含むことができる。タイムラインは、メディアコンテンツのための一連の時間情報である。タイムベース取得のための情報を含んでいるか否かを示す情報は、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｔｉｍｅｌｉｎｅ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、サービスシグナリングメッセージがタイムベース伝送のための情報を含んでいることを示すことができる。

また、実施例に係るサービスシグナリングメッセージは、シグナリングメッセージを取得するために必要な情報をサービスシグナリングメッセージが含んでいるか否かを示すことができる。このとき、シグナリングメッセージは、放送サービスで使用するＭＰＤ（ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄａｔａ）又はＭＰＤ ＵＲＬに関連したシグナリングメッセージであってもよい。シグナリングメッセージの取得のための情報を含んでいるか否かを示す情報は、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、サービスシグナリングメッセージがＭＰＤ又はＭＰＤ ＵＲＬ関連シグナリングメッセージ伝送関連情報を含んでいることを示すことができる。ＨＴＴＰに基づく適応型メディアストリーミングをＤＡＳＨ（Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）と呼ぶことができる。そして、適応型メディアストリーミングで放送サービス及びコンテンツを構成するセグメントを放送受信装置が取得するための詳細情報を、ＭＰＤと呼ぶことができる。ＭＰＤはＸＭＬ形態で表現されてもよい。ＭＰＤ ＵＲＬ関連シグナリングメッセージは、ＭＰＤを取得できるアドレス情報を含むことができる。

また、実施例に係るサービスシグナリングメッセージは、コンポーネントデータに対する取得経路情報をサービスシグナリングメッセージが含んでいるか否かを示すことができる。このとき、コンポーネントは、放送サービスを提供するためのコンテンツデータに対する一単位であってもよい。コンポーネントデータに対する取得経路情報を含んでいるか否かを示す情報は、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドは、サービスシグナリングメッセージがコンポーネントデータに対する取得経路情報を含んでいることを示すことができる。

また、実施例に係るサービスシグナリングメッセージは、アプリケーション関連シグナリングメッセージを取得するために必要な情報を含んでいるか否かを示すことができる。アプリケーション関連シグナリングメッセージを取得するために必要な情報を含んでいるか否かを示す情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドは、サービスシグナリングメッセージがコンポーネントデータに対する取得経路情報を含んでいることを示すことができる。

また、実施例に係るサービスシグナリングメッセージは、シグナリングメッセージ伝送関連情報を含んでいるか否かを示すことができる。シグナリングメッセージ伝送関連情報を含んでいるか否かを示す情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドが１の値を有する場合、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｆｌａｇフィールドは、サービスシグナリングメッセージがシグナリングメッセージ伝送関連情報を含んでいることを示すことができる。そして、サービスシグナリングメッセージが上述したＭＰＤ関連シグナリング、コンポーネント取得経路情報及びアプリケーション関連シグナリング情報を含んでいない場合、放送受信装置は、シグナリングメッセージ伝送経路を通じてＭＰＤ関連シグナリング、コンポーネント取得経路情報及びアプリケーション関連シグナリング情報を取得することができる。

実施例に係るサービスシグナリングメッセージは、放送サービスで使用するタイムベースを送信するモードを示すことができる。タイムベースを送信するモードに関する情報は、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

実施例に係るサービスシグナリングメッセージは、放送サービスで使用するＭＰＤ又はＭＰＤ ＵＲＬ関連シグナリングメッセージを伝送するモードを示すことができる。ＭＰＤ又はＭＰＤ ＵＲＬ関連シグナリングメッセージを伝送するモードに関する情報は、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

実施例に係るサービスシグナリングメッセージは、放送サービスで使用するコンポーネントデータの取得経路を含むコンポーネントロケーションシグナリングメッセージを伝送するモードを示すことができる。コンポーネントデータの取得経路を含むコンポーネントロケーションシグナリングメッセージを伝送するモードに関する情報は、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

実施例に係るサービスシグナリングメッセージは、放送サービスで使用するアプリケーション関連シグナリングメッセージを伝送するモードを示すことができる。アプリケーション関連シグナリングメッセージを伝送するモードに関する情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

実施例に係るサービスシグナリングメッセージは、放送サービスで使用するサービス関連シグナリングメッセージを伝送するモードを示すことができる。サービス関連シグナリングメッセージを伝送するモードに関する情報は、ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドであってもよい。

上述したｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールド及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅフィールドが有する値による意味を説明する。

図５０は、前述したそれぞれの伝送モードが有する値による意味を示す。Ｘ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅは、ｔｉｍｅｂａｓｅ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ、ＭＰＤ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ、ｃｏｍｐｏｎｅｎｔ＿ｌｏｃａｔｉｏｎ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅ及びｓｉｇｎａｌｉｎｇ＿ｔｒａｎｓｐｏｒｔ＿ｍｏｄｅを含むことができる。それぞれの伝送モードが有する値の具体的な意味は、前述したとおりである。

図４９の実施例に係るサービスシグナリングメッセージは、図５０のそれぞれのモードが有する値によって、放送受信装置がタイムベース又はシグナリングメッセージを取得するために必要な情報を含むことができる。タイムベース又はシグナリングメッセージの取得に必要な情報は、ｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）フィールドであってもよい。具体的に、ｂｏｏｔｓｔｒａｐ＿ｄａｔａ（）に含まれた情報は、上述したとおりである。

図５１は、次世代放送システムで放送サービスのコンポーネントデータ取得経路をシグナルするシグナリングメッセージの構成を示している。次世代放送システムで１つの放送サービスは、１つ以上のコンポーネントで構成することができる。実施例に係るシグナリングメッセージに基づいて、放送受信装置は、放送ストリームでコンポーネントデータ及び関連アプリケーションの取得経路に関する情報を取得することができる。このとき、実施例に係るシグナリングメッセージは、ＸＭＬの形態で表現することもできる。

実施例に係るシグナリングメッセージは、シグナリングメッセージがコンポーネントロケーションをシグナルするメッセージであることを識別するための情報を含むことができる。シグナリングメッセージがコンポーネントロケーションをシグナルするメッセージであることを識別するための情報は、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドであってもよい。具体的な実施例で、ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドは８ビットであってもよい。

また、実施例に係るシグナリングメッセージは、シグナリングメッセージがコンポーネントロケーションをシグナルするメッセージであることを識別する拡張情報を含むことができる。このとき、拡張情報は、コンポーネントロケーションをシグナルするメッセージのプロトコルバージョンを含むことができる。拡張情報は、ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドであってもよい。

また、図５０の実施例に係るシグナリングメッセージは、コンポーネントロケーションをシグナルするメッセージのバージョン情報を含むことができる。このとき、バージョン情報は、コンポーネントロケーションをシグナルするメッセージの内容が変更されたことを示すことができる。バージョン情報は、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、関連した放送サービスの識別子情報を含むことができる。このとき、関連放送サービスの識別子情報は、ｓｅｒｖｉｃｅ＿ｉｄフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、放送サービスに関連したコンポーネントの個数を含むことができる。このとき、関連したコンポーネントの個数情報は、ｎｕｍ＿ｃｏｍｐｏｎｅｎｔフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、各コンポーネントの識別子を含むことができる。例えば、コンポーネント識別子は、ＭＰＥＧ ＤＡＳＨのＭＰＤ＠ｉｄ、ｐｅｒｉｏｄ＠ｉｄ及びｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄを組み合わせて構成することができる。このとき、各コンポーネントの識別子情報は、ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールドの長さを含むことができる。このとき、ｃｏｍｐｏｎｅｎｔ＿ｉｄフィールドの長さ情報は、ｃｏｍｐｏｎｅｎｔ＿ｉｄ＿ｌｅｎｇｔｈフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを取得可能な周波数を示す周波数情報を含むことができる。コンポーネントデータは、ＤＡＳＨセグメントを含むことができる。このとき、コンポーネントデータを取得可能な周波数情報は、ｆｒｅｑｕｅｎｃｙ＿ｎｕｍｂｅｒフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、放送局固有の識別子を含むことができる。放送局は、特定の周波数又は伝送される伝送フレームでコンポーネントデータを伝送することができる。このとき、放送局固有の識別子情報は、ｂｒｏａｄｃａｓｔ＿ｉｄフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを送信する物理層パイプの識別子を含むことができる。このとき、コンポーネントデータを送信する物理層パイプの識別子情報は、ｄａｔａｐｉｐｅ＿ｉｄフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムのＩＰアドレス形式を含むことができる。このとき、ＩＰデータグラムのＩＰアドレス形式情報は、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドであってもよい。具体的な実施例で、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド値が０である場合、ＩＰｖ４形式を示し、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドが１である場合、ＩＰｖ６形式を示すことができる。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムがソースＩＰアドレスを含むか否かに関する情報を含むことができる。ＩＰデータグラムがソースＩＰアドレスを含むか否かに関する情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、ＩＰデータグラムがソースＩＰアドレスを含むことを示す。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報を含むことができる。ＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、ＩＰデータグラムが送信先ＩＰアドレスを含むことを示す。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムのソースＩＰアドレス情報を含むことができる。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、シグナリングメッセージはソースＩＰアドレス情報を含むことができる。ソースＩＰアドレス情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムの送信先ＩＰアドレス情報を含むことができる。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、シグナリングメッセージは送信先ＩＰアドレス情報を含むことができる。送信先ＩＰアドレス情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含むＩＰデータグラムのＵＤＰポート番号情報を含むことができる。ＵＤＰポート番号情報は、ＵＤＰ＿ｐｏｒｔ＿ｎｕｍフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含む伝送パケットを伝送するアプリケーション層伝送セッションの識別子（ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）情報を含むことができる。伝送パケットを伝送するセッションは、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションの少なくとも一つであってもよい。セッションの識別子情報は、ｔｓｉフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、コンポーネントデータを含む伝送パケットの識別子情報を含むことができる。伝送パケットの識別子情報は、ｐａｃｋｅｔ＿ｉｄフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、放送サービスに関連したアプリケーションシグナリングメッセージの個数を含むことができる。このとき、放送サービスは、ｓｅｒｖｉｃｅ＿ｉｄフィールドによって識別された放送サービスであってもよい。アプリケーションシグナリングメッセージの個数情報は、ｎｕｍ＿ａｐｐ＿ｓｉｇｎａｌｉｎｇフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、アプリケーションシグナリングメッセージの識別子情報を含むことができる。アプリケーションシグナリングメッセージの識別子情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドの長さ情報を含むことができる。ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄフィールドの長さ情報は、ａｐｐ＿ｓｉｇｎａｌｉｎｇ＿ｉｄ＿ｌｅｎｇｔｈフィールドであってもよい。

また、実施例に係るシグナリングメッセージは、アプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータを含むことができる。アプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションの取得のための経路情報は、ａｐｐ＿ｄｅｌｉｖｅｒｙ＿ｉｎｆｏ（）フィールドであってもよい。

図５２は、本発明の一実施例に係るａｐｐ＿ｄｅｌｉｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す。

実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータが別の放送ストリームで伝送されるか否かに関する情報を含むことができる。アプリケーション又は関連したデータが別の放送ストリームで伝送されるか否かに関する情報は、ｂｒｏａｄｃａｓｔｉｎｇ＿ｆｌａｇフィールドであってもよい。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムのＩＰアドレス形式を含むことができる。ＩＰデータグラムのＩＰアドレス形式の情報は、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドであってもよい。一実施例で、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドが０である場合、アプリケーション又は関連したデータを含むＩＰデータグラムはＩＰｖ４形式を用いることを示し、ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドが１である場合、アプリケーション又は関連したデータを含むＩＰデータグラムはＩＰｖ６形式を用いることを示すことができる。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムがソースＩＰアドレスを含むか否かを示すことができる。このとき、関連したデータは、アプリケーションの実行に必要なデータであってもよい。

アプリケーション又は関連したデータを含むＩＰデータグラムがソースＩＰアドレスを含むか否かに関する情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１である場合、ＩＰデータグラムがソースＩＰアドレスを含んでいることを示すことができる。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報を含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムが送信先ＩＰアドレスを含むか否かに関する情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドであってもよい。一実施例で、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１である場合、ＩＰデータグラムが送信先ＩＰアドレスを含んでいることを示すことができる。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、特定の周波数又は伝送される伝送フレームでアプリケーション又は関連したデータを送信する放送局固有の識別子を含むことができる。

言い換えると、アプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、放送サービス伝送ストリームの識別子を含むことができる。特定の周波数又は伝送される伝送フレームでアプリケーション又は関連したデータを送信する放送局固有の識別子情報は、ｂｒｏａｄｃａｓｔ＿ｉｄフィールドであってもよい。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、アプリケーション又は関連したデータを含むＩＰデータグラムのソースＩＰアドレスを含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムのソースＩＰアドレス情報は、ｓｏｕｒｃｅ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓ＿ｆｌａｇフィールドが１の値を有する場合、アプリケーション又は関連したデータを含むＩＰデータグラムの送信先ＩＰアドレスを含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムの送信先ＩＰアドレス情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＰ＿ａｄｄｒｅｓｓフィールドであってもよい。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムフローのポートの個数を含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムフローのポートの個数情報は、ｐｏｒｔ＿ｎｕｍ＿ｃｏｕｎｔフィールドであってもよい。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを含むＩＰデータグラムＵＤＰポート番号を含むことができる。アプリケーション又は関連したデータを含むＩＰデータグラムＵＤＰポート番号情報は、ｄｅｓｔｉｎａｔｉｏｎ＿ＵＤＰ＿ｐｏｒｔ＿ｎｕｍｂｅｒフィールドであってもよい。

また、実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを送信する伝送セッションの識別子を含むことができる。アプリケーション又は関連したデータを送信する伝送セッションは、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションのいずれか一つであってもよい。アプリケーション又は関連したデータを送信する伝送セッションの識別子情報は、ｔｓｉフィールドであってもよい。

図５３は、本発明の他の実施例に係るａｐｐ＿ｄｅｌｉｖｅｒｙ＿ｉｎｆｏ（）フィールドのシンタクスを示す。

実施例に係るアプリケーションシグナリングメッセージの識別子に関連したシグナリングメッセージに含まれたアプリケーションのデータを取得できる経路に関するデータは、アプリケーション又は関連したデータを送信する伝送パケットの識別子を示すことができる。アプリケーション又は関連したデータを送信する伝送パケットは、パケットベース伝送フローに基づくプロトコルに従えばよ い。例えば、パケットベース伝送フローは、ＭＰＥＧメディア伝送プロトコル（ＭＰＥＧ Ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）を含むことができる。アプリケーション又は関連したデータを送信する伝送パケットの識別子情報は、ｐａｃｋｅｔ＿ｉｄフィールドであってもよい。

図５４は、放送サービスを構成する１つ以上のコンポーネントデータを取得できる経路情報を含むコンポーネントロケーションシグナリングを示す。具体的に、図５４は、放送サービスを構成する１つ以上のコンポーネントがＭＰＥＧ ＤＡＳＨのセグメントで表現される場合、ＤＡＳＨセグメントを含むコンポーネントデータを取得できる経路情報を示す。

図５５は、図５４のコンポーネントロケーションシグナリングの構成を示す図である。

実施例に係るコンポーネントロケーションシグナリングは、放送サービスに関連したＭＰＥＧ ＤＡＳＨ ＭＰＤの識別子情報を含むことができる。ＭＰＥＧ ＤＡＳＨ ＭＰＤの識別子情報は、ｍｐｄｉｐフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ｍｐｄｉｐフィールドが示すＭＰＥＧ ＤＡＳＨ ＭＰＤ内の周期（ｐｅｒｉｏｄ）属性（ａｔｔｒｉｂｕｔｅｓ）の識別子を含むことができる。ＭＰＥＧ ＤＡＳＨ ＭＰＤ内の周期（ｐｅｒｉｏｄ）属性の識別子情報は、ｐｅｒｉｏｄｉｄフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ｐｅｒｉｏｄｉｄフィールドが示す周期内の再生（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）属性の識別子を含むことができる。周期内の再生（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）属性の識別子情報は、ＲｅｐｔｎＩＤフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ＲｅｐｔｎＩＤフィールドが示す周期内の再生属性に含まれたＤＡＳＨセグメントを取得できる周波数ナンバーを含むことができる。ＤＡＳＨセグメントを取得できる周波数ナンバーは、ＲＦチャネルナンバーであってもよい。ＤＡＳＨセグメントを取得できる周波数ナンバー情報は、ＲＦＣｈａｎフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、特定の周波数又は伝送される伝送フレームでＤＡＳＨセグメントを送信する放送局固有の識別子を含むことができる。ＤＡＳＨセグメントを送信する放送局固有の識別子情報は、Ｂｒｏａｄｃａｓｔｉｎｇｉｄフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを伝達する物理層パイプの識別子を含むことができる。物理層パイプは、物理層で伝送されるデータパイプであってもよい。ＤＡＳＨセグメントを伝達する物理層パイプの識別子情報は、ＤａｔａＰｉｐｅＩｄフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含むＩＰデータグラムの送信先ＩＰアドレスを含むことができる。ＤＡＳＨセグメントを含むＩＰデータグラムの送信先ＩＰアドレス情報は、ＩＰＡｄｄフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含むＩＰデータグラムのＵＤＰポート番号を含むことができる。ＤＡＳＨセグメントを含むＩＰデータグラムのＵＤＰポート番号情報は、ＵＤＰＰｏｒｔフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含む伝送パケットを伝送するセッションの識別子（ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）を含むことができる。伝送パケットを伝送するセッションの識別子は、ＡＬＣ／ＬＣＴセッション及びＦＬＵＴＥセッションの少なくとも一つであってもよい。伝送パケットを伝送するセッションの識別子情報は、ＴＳＩフィールドであってもよい。

また、実施例に係るコンポーネントロケーションシグナリングは、ＤＡＳＨセグメントを含む伝送パケットの識別子を含むことができる。伝送パケットの識別子情報は、ＰａｃｋｅｔＩｄフィールドであってもよい。

図５６は、本発明の一実施例において次世代放送システムで放送サービスのサービスに対するシグナリングが含む他の情報を示している。サービスに対するシグナリングは、サービス識別子（ｉｄ）、サービスタイプ、サービスネーム、チャネルナンバー、タイムベースロケーション、デリバリモード、ブートストラップインフォ、ＭＰＤ、ＭＰＤシグナリングロケーション、コンポーネントシグナリングロケーション、アプリシグナリングロケーション、及び／又はオブジェクトフローに関する情報を含むことができる。

サービス識別子は、サービスを識別する情報を示すことができ、ｉｄ属性で表現されてもよい。

サービスタイプ情報は、サービスのタイプを示す情報であって、ｓｅｒｖｉｃｅＴｙｐｅ属性で表現されてもよい。

サービスネーム情報は、サービス名を示す情報であって、ｓｅｒｖｉｃｅＮａｍｅ属性で表現されてもよい。

チャネルナンバー情報は、サービスに関連したチャネルナンバーを示す情報であって、ｃｈａｎｎｅｌＮｕｍｂｅｒ属性で表現されてもよい。

タイムベースロケーション情報は、タイムベースを取得できる位置を示す情報であって、ＴｉｍｅｂａｓｅＬｏｃａｔｉｏｎエレメントで表現されてもよい。ここで、タイムベースは、サービスに含まれたコンポーネントを同期化するためのタイムラインを設定するためのメタデータを示す情報を意味することができる

タイムベースロケーション情報に含まれたデリバリモード情報は、タイムベースの伝送モードを示すことができる。

タイムベースロケーション情報に含まれたブートストラップインフォ情報は、上記デリバリモードによるタイムベースのブートストラップ情報を含むことができる。

ＭＰＤは、サービスに関連したＭＰＤを示すことができる。

ＭＰＤシグナリングロケーション情報は、ＭＰＤ又はＭＰＤ ＵＲＬに関連したシグナリングを取得できる位置を示すことができる。

ＭＰＤシグナリングロケーションに含まれたデリバリモード情報は、ＭＰＤロケーションシグナリングの伝送モードを示すことができる。

ＭＰＤシグナリングロケーションに含まれたブートストラップインフォ情報は、上記伝送モードによるＭＰＤ又はＭＰＤ ＵＲＬのブートストラップ情報を含むことができる。

コンポーネントシグナリングロケーション情報は、サービスに関連したコンポーネントロケーションシグナリング情報を示すことができる。

コンポーネントシグナリングロケーション情報に含まれたデリバリモード情報は、コンポーネントロケーションシグナリングの伝送モードを示すことができる。

コンポーネントシグナリングロケーション情報に含まれたブートストラップインフォ情報は、上記伝送モードによるコンポーネントロケーションシグナリングのブートストラップ情報を含むことができる。

アプリシグナリングロケーション情報は、アプリケーションシグナリングを取得できる位置を示すことができる。

アプリシグナリングロケーション情報に含まれたデリバリモード情報は、アプリケーションシグナリングの伝送モードを示すことができる。

アプリシグナリングロケーション情報に含まれたブートストラップインフォ情報は、上記伝送モードによるアプリケーションシグナリングのブートストラップ情報を含むことができる。

オブジェクトフロー情報は、サービスのコンポーネントを送信する関連オブジェクトフローに関する情報を含むことができる。

図５７は、本発明の一実施例に係る次世代放送システムのサービスシグナリングが含む伝送モードを示す図である。

上述したように、伝送モード（ｄｅｌｉｖｅｒｙＭｏｄｅ）を、各ロケーションエレメント中に属性として含めることができる。伝送モードは、その値によって下記のように区別することができる。

伝送モードの値が０ｘ００である場合、ＩＰｖ４／ＩＰｖ６フローがサービスシグナリングメッセージを受信した放送ストリームと同じ放送網（ｂｒｏａｄｃａｓｔ）又はセルラーネットワークを介して伝送されることを示すことができる。

伝送モードの値が０ｘ０１である場合、ＩＰｖ４／ＩＰｖ６フローが別の放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。

伝送モードの値が０ｘ０２である場合、セッションに基づく（ｓｅｓｓｉｏｎ−ｂａｓｅｄ）フローが同じ放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここで、セッションに基づくフローとは、実施例によってＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを意味することができる。

伝送モードの値が０ｘ０３である場合、セッションに基づく（ｓｅｓｓｉｏｎ−ｂａｓｅｄ）フローが別の放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここで、セッションに基づくフローとは、実施例によってＡＬＣ／ＬＣＴ、ＦＬＵＴＥセッションを意味することができる。

伝送モードの値が０ｘ０４である場合、パケットに基づくフローが同じ放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここでパケットに基づくフローとは、実施例によって、ＭＭＴパケットベース伝送を意味することができる。

伝送モードの値が０ｘ０５である場合、パケットに基づくフローが別の放送網（ｂｒｏａｄｃａｓｔ）を介して伝送されることを示すことができる。ここでパケットに基づくフローとは、実施例によって、ＭＭＴパケットベース伝送を意味することができる。

伝送モードの値が０ｘ０６である場合、ＵＲＬによって位置が指定されることを示すことができる。

伝送モードの値が０ｘ０７〜０ｘＦＦである場合は、未定の値であり、他の伝送モードを示すために用いることができる。

以上のように、上述したタイムベースロケーション、ＭＰＤシグナリングロケーション、コンポーネントシグナリングロケーション、及びアプリシグナリングロケーションエレメントに含まれた情報は、上記伝送モードによって、サービスシグナリングと同じ又は別の経路を通じて伝送されてもよい。

図５８は、本発明の一実施例に係る次世代放送システムのサービスシグナリングが含むブートストラップに関する情報を示している。ブートストラップに関する情報は、以下、ＢｏｏｔｓｔｒａｐＩｎｆｏ ｅｌｅｍｅｎｔと表現することができる。

上述したシグナリングメッセージでいうＢｏｏｔｓｔｒａｐＩｎｆｏ ｅｌｅｍｅｎｔは、受信機がタイムベース（ｔｉｍｅ ｂａｓｅ）情報、ＭＰＤ又はＭＰＤ ＵＲＬ情報、コンポーネントシグナリング（ｃｏｍｐｏｎｅｎｔ ｓｉｇｎａｌｉｎｇ）情報、アプリシグナリング（ａｐｐｌｉｃａｔｉｏｎ ｓｉｇｎａｌｉｎｇ）情報などを取得できるようにする情報を含むことができる。すなわち、上述したように、ブートストラップインフォ（ＢｏｏｔｓｔｒａｐＩｎｆｏ）を各ロケーションエレメント中に含めることができる。したがって、ＢｏｏｔｓｔｒａｐＩｎｆｏエレメントは、ＩＰアドレス、ポート（ｐｏｒｔ）ナンバー、伝送セッション識別子（Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）、及び／又は関連したパケット識別子（ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）などの情報を含むことができる。

詳しくは、ブートストラップインフォエレメントは、ＲＦｃｈａｎｎｅｌ、ｂｒｏａｄｃａｓｔＩＤ、ｄａｔａｐｉｐｅＩＤ（ＰＬＰＩＤ）、ｓｏｕｒｃｅＩＰ、ｄｅｓｔｉｎａｔｉｏｎＩＰ、ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ、ｔｓｉ、ＵＲＬ及び／又はｐａｃｋｅｔｉｄなどの属性を含むことができる。ブートストラップインフォエレメントに含まれる情報は、ブートストラップインフォエレメントの属したロケーションエレメントに含まれた伝送モードによって変更されてもよい。

ＲＦｃｈａｎｎｅｌ属性は、放送ストリームを伝達する無線周波数チャネルに関する情報を含むことができる。

ｂｒｏａｄｃａｓｔＩＤ属性は、放送ストリームを送信する放送会社に対する識別情報を示すことができる。

ｄａｔａｐｉｐｅＩＤ（ＰＬＰＩＤ）属性は、ＩＰデータグラムを伝達する物理層データパイプ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｄａｔａ ｐｉｐｅ）の識別子を示すことができる。ｄａｔａｐｉｐｅＩＤは、ＰＬＰＩＤと表示することができ、ＰＬＰＩＤは、物理層パイプ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｉｐｅ）の識別子を示すことができる。

ｓｏｕｒｃｅＩＰ属性は、関連したデータを含むＩＰデータグラムのソースアドレスを示すことができる。

ｄｅｓｔｉｎａｔｉｏｎＩＰ属性は、関連したデータを含むＩＰデータグラムの送信先アドレスを示すことができる。

ｄｅｓｔｉｎａｔｉｏｎＰｏｒｔ属性は、関連したデータを含むＩＰデータグラムの送信先ポートナンバーを示すことができる。

ｔｓｉ属性は、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔｓ）を伝達する伝送セッションの識別子を示すことができる。

ＵＲＬ属性は、関連したデータを取得できるＵＲＬを示すことができる。

ｐａｃｋｅｔｉｄは、関連したデータを含む伝送パケット（ｔｒａｎｓｐｏｒｔ ｐａｃｋｅｔｓ）の識別子を示すことができる。

以下、図５９では、図５６に示す放送サービスに対するシグナリングが含む情報のうち、ｏｂｊｅｃｔＦｌｏｗエレメントについて説明する。

図５９には、オブジェクトフローに対するシグナリングが含む情報を示す。各オブジェクトフローは、サービスを構成する１つ以上のコンポーネントを送信するフローであってもよい。したがって、１つのサービスは１つ以上のオブジェクトフローに関する情報を含むことができる。

オブジェクトフローは、ｉｄ、ｏｂｊｅｃｔＦｏｒｍａｔ、ｃｏｎｔｅｎｔＴｙｐｅ及び／又はｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇ属性を含むことができる。また、オブジェクトフローは、Ｆｉｌｅエレメントを含むことができ、Ｆｉｌｅエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ及び／又はＴＯＩ属性を含むことができる。また、オブジェクトフローは、ＦｉｌｅＴｅｍｐｌａｔｅエレメントを含むことができ、ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅ、ｓｔａｒｔＴＯＩ、ｅｎｄＴＯＩ及び／又はｓｃａｌｅ属性を含むことができる。また、オブジェクトフローは、ＯｂｊｅｃｔＧｒｏｕｐエレメントを含むことができ、ＯｂｊｅｃｔＧｒｏｕｐエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ、ｓｔａｒｔＴＯＩ及び／又はｅｎｄＴＯＩ属性を含むことができる。また、オブジェクトフローは、上述したＢｏｏｔｓｔｒａｐＩｎｆｏエレメントを含むことができる。

ｉｄは、オブジェクトフローの識別子を示すことができる。ＤＡＳＨセグメントが当該オブジェクトフローで伝送される場合、ｉｄは、ＭＰＤ識別子、ｐｅｒｉｏｄ識別子及びＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子の結合と同一であってもよい。

ｏｂｊｅｃｔＦｏｒｍａｔは、上述したように、オブジェクトフローに含まれたオブジェクトのフォーマットを示すことができる。

ｃｏｎｔｅｎｔＴｙｐｅは、オブジェクトフローのためのメディアコンテンツコンポーネントタイプを示すことができる。

ｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇは、オブジェクトフローで伝達されるオブジェクトのエンコーディング方式を示すことができる。

Ｆｉｌｅエレメントは、Ｆｉｌｅに関する情報を含むことができる。

ＦｉｌｅエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、ファイルを取得できる位置を示すことができる。オブジェクトフローでＤＡＳＨセグメントが伝達される場合、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎはＤＡＳＨセグメントＵＲＬと同一であってもよい。

ＦｉｌｅエレメントのＴＯＩ属性は、ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒであって、伝送オブジェクトの識別子を示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ファイル書式に関する情報を含むことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅは、ファイルを取得できる位置を生成するために用いられる書式を示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｔａｒｔＴＯＩは、オブジェクトフローで伝達される最初のＴＯＩを示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｅｎｄＴＯＩは、オブジェクトフローで伝達される最後のＴＯＩを示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｃａｌｅ属性は、オブジェクトフロー内のＴＯＩ値間のスケールに関する情報を示すことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントは、オブジェクトフローで伝達される伝送オブジェクトのグループに関する情報を含むことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、オブジェクトグループに関連したコンテンツの位置を示すことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントのｓｔａｒｔＴＯＩは、オブジェクトグループで伝達される最初のＴＯＩを示すことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントのｅｎｄＴＯＩは、オブジェクトグループで伝達される最後のＴＯＩを示すことができる。

ＢｏｏｔｓｔｒａｐＩｎｆｏエレメントは、オブジェクトフローのブートストラップ情報を含むことができる。

図５９の実施例に係るオブジェクトフローに対するシグナリングが含む情報のうち、ｏｂｊｅｃｔＦｏｒｍａｔ属性は、オブジェクトフロー上で伝達されるオブジェクトが含むペイロードの形態に関する情報を含むことができる。第１の実施例でオブジェクトフロー上におけるオブジェクトフォーマット属性は、フローに含まれたペイロードが非実時間を支援するための一般ファイルを含むことを示すことができる。第１の実施例に係るオブジェクトフォーマットはｇｅｎｅｒｉｃ ｆｉｌｅであってもよい。

第２の実施例でオブジェクトフロー上におけるオブジェクトフォーマット属性は、フローに含まれたペイロードが実時間ストリーミングを支援するためのデータファイルを含むことを示すことができる。例えば、第２の実施例のオブジェクトフォーマット属性は、ＩＳＯＢＭＦＦ形態のＤＡＳＨセグメントを示すことができる。第３の実施例でオブジェクトフロー上におけるオブジェクトフォーマット属性は、フローに含まれたペイロードが実時間ストリーミングを支援するためにＨＴＴＰエンティティ（ｅｎｔｉｔｙ）形態で表現されたデータファイルを含むことを示すことができる。ＨＴＴＰエンティティは、ＨＴＴＰによるコンテンツを伝送する一個体であってもよい。

以下、図６０では、図５９に示したオブジェクトフローに対するシグナリングが含む情報のうち、ファイル書式（Ｆｉｌｅ Ｔｅｍｐｌａｔｅ）エレメントについて説明する。

図６０には、本発明の一実施例でファイル書式（Ｆｉｌｅ Ｔｅｍｐｌａｔｅ）を表現するための情報の組合せを示す。ファイル書式は、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ及びｓｅｇｍｅｎｔ ｎｕｍｂｅｒを組み合わせて表現することができる。例えば、ＤＡＳＨセグメントが伝送される場合、図６０に示すように、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ及びｓｅｇｍｅｎｔ ｎｕｍｂｅｒを組み合わせて、各ファイルに対するコンテンツロケーションの情報を動的に生成することができる。結果的に、放送受信装置は、動的に生成されたコンテンツロケーション情報によって、特定コンポーネントを含む伝送パケットのフローを効果的に取得することができる。

図６１には、本発明の一実施例に係るサービスシグナリングが含むオブジェクトフローを示す。

オブジェクトフローは、図５９で説明したオブジェクトフォーマット属性に加えてデフォルト属性（＠ｉｓＤｅｆａｕｌｔ）を含むことができる。すなわち、オブジェクトフローは、ｉｄ、ｏｂｊｅｃｔＦｏｒｍａｔ、ｃｏｎｔｅｎｔＴｙｐｅ、ｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇ及び／又はｉｓＤｅｆａｕｌｔ属性を含むことができる。また、オブジェクトフローは、Ｆｉｌｅエレメントを含むことができ、Ｆｉｌｅエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ及び／又はＴＯＩ属性を含むことができる。また、オブジェクトフローは、ＦｉｌｅＴｅｍｐｌａｔｅエレメントを含むことができ、ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅ、ｓｔａｒｔＴＯＩ、ｅｎｄＴＯＩ及び／又はｓｃａｌｅ属性を含むことができる。また、オブジェクトフローは、ＯｂｊｅｃｔＧｒｏｕｐエレメントを含むことができ、ＯｂｊｅｃｔＧｒｏｕｐエレメントは、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ、ｓｔａｒｔＴＯＩ及び／又はｅｎｄＴＯＩ属性を含むことができる。また、オブジェクトフローは、上述したＢｏｏｔｓｔｒａｐＩｎｆｏエレメントを含むことができる。

ｉｄは、オブジェクトフローの識別子を示すことができる。ＤＡＳＨセグメントが当該オブジェクトフローで伝送される場合、ｉｄは、ＭＰＤ識別子、ｐｅｒｉｏｄ識別子及びＤＡＳＨ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ識別子の結合と同一であってもよい。

ｏｂｊｅｃｔＦｏｒｍａｔは、上述したように、オブジェクトフローに含まれたオブジェクトのフォーマットを示すことができる。

ｃｏｎｔｅｎｔＴｙｐｅは、オブジェクトフローのためのメディアコンテンツコンポーネントタイプを示すことができる。

ｃｏｎｔｅｎｔＥｎｃｏｄｉｎｇは、オブジェクトフローで伝達されるオブジェクトのエンコーディング方式を示すことができる。

ｉｓＤｅｆａｕｌｔは、オブジェクトフロー上で伝達されるオブジェクトが含むペイロードがデフォルトとして使われるコンポーネントデータを含むか否かを示すことができる。例えば、受信機がＤＡＳＨ ＭＰＤなどの付加的なシグナリング情報の受信及び処理無しで当該オブジェクトフローで伝達されるコンポーネントデータを基本的に受信及び再生するか否かを示すことができる。

Ｆｉｌｅエレメントは、Ｆｉｌｅに関する情報を含むことができる。

ＦｉｌｅエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、ファイルを取得できる位置を示すことができる。オブジェクトフローでＤＡＳＨセグメントが伝達される場合、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、ＤＡＳＨセグメントＵＲＬと同一であってもよい。

ＦｉｌｅエレメントのＴＯＩ属性は、ｔｒａｎｓｐｏｒｔ ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒであって、伝送オブジェクトの識別子を示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントは、ファイル書式に関する情報を含むことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｃｏｎｔｅｎｔＬｏｃＴｅｐｌａｔｅは、ファイルを取得できる位置を生成するために用いられる書式を示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｔａｒｔＴＯＩは、オブジェクトフローで伝達される最初のＴＯＩを示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｅｎｄＴＯＩは、オブジェクトフローで伝達される最後のＴＯＩを示すことができる。

ＦｉｌｅＴｅｍｐｌａｔｅエレメントのｓｃａｌｅ属性は、オブジェクトフロー内のＴＯＩ値間のスケールに関する情報を示すことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントは、オブジェクトフローで伝達される伝送オブジェクトのグループに関する情報を含むことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントのｃｏｎｔｅｎｔＬｏｃａｔｉｏｎは、オブジェクトグループに関連したコンテンツの位置を示すことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントのｓｔａｒｔＴＯＩは、オブジェクトグループで伝達される最初のＴＯＩを示すことができる。

ＯｂｊｅｃｔＧｒｏｕｐエレメントのｅｎｄＴＯＩは、オブジェクトグループで伝達される最後のＴＯＩを示すことができる。

ＢｏｏｔｓｔｒａｐＩｎｆｏエレメントは、オブジェクトフローのブートストラップ情報を含むことができる。

図６２には、本発明の一実施例において次世代放送システムで放送サービスのシグナリングが含む他の情報を示す。既存のＦＬＵＴＥクライアントの場合、ＦＤＴ（Ｆｉｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｔａｂｌｅ）を受信した後、放送受信装置がＦＤＴによるファイルを受信することができた。しかし、この方案は、実時間放送サービスによってファイルを伝送及び受信するには不都合がある。言い換えると、ＦＬＵＴＥプロトコルは単方向伝送プロトコルであって、実時間放送サービスには向いていない。このため、本発明の一実施例は、サービスシグナリングがＦＤＴ情報を含むことができる。

具体的に、図６２に示すように、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠ｉｄ属性（ｅｌｅｍｅｎｔ）を含むことができる。＠ｉｄ属性は、ＦＤＴインスタンスの特定識別子を示すことができる。したがって、放送受信装置は、＠ｉｄ属性からＦＤＴインスタンスを識別し、ＦＤＴインスタンスを動的に生成することができる。また、放送受信装置は、生成したＦＤＴインスタンスによってファイル形態で表現された実時間ストリーミングデータを受信及び処理することができる。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｅｘｐｉｒｅｓ属性を含むことができる。＠Ｅｘｐｒｉｅｓ属性は、ＦＤＴＩｎｓｔａｎｃｅの満了時間に関する情報を含むことができる。したがって、放送受信装置１００は、＠Ｅｘｐｒｉｅｓ属性によって、満了したＦＤＴＩｎｔａｎｃｅを廃棄することができる。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｍｐｌｅｔｅ属性を含むことができる。一実施例で、＠Ｃｏｍｐｌｅｔｅ属性がｔｒｕｅ値を有する場合、＠Ｃｏｍｐｌｅｔｅ属性は、同じセッション内で提供される将来のＦＤＴＩｎｓｔａｎｃｅが新しいデータを含んでいないことを示すことができる。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ属性は、有効なＵＲＩを割り当てることができる。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠ＴＯＩ属性を含むことができる。＠ＴＯＩ属性は、有効なＴＯＩ値が必ず割り当てられる必要がある。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ属性は、ファイルコンテンツの実際長さ情報であってもよい。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｔｒａｎｓｆｅｒ−Ｌｅｎｇｔｈ属性を含むことができる。＠Ｔｒａｎｓｆｅｒ−Ｌｅｎｇｔｈ属性は、ファイルコンテンツの伝送長さ情報であってもよい。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇ属性は、ファイルコンテンツのエンコーディング情報であってもよい。

また、本発明の一実施例に係るＦＤＴＩｎｓｔａｎｓｃｅエレメントは、＠Ｃｏｎｔｅｎｔ−Ｔｙｐｅ属性を含むことができる。＠Ｃｏｎｔｅｎｔ−Ｔｙｐｅ属性は、ファイルコンテンツのタイプ情報であってもよい。

図６３は、本発明の一実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す。ＬＣＴベースのプロトコルを用いて実時間又は非実時間コンテンツを伝送する場合、ＴＳＩＤのような、セッションレベルの伝送セッション情報記述のためのシグナリング情報を用いることができる。ＴＳＩＤは、伝送コンテンツと同じ帯域内（ｉｎ−ｂａｎｄ）或いは異なる経路を用いる帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）などの様々な方法及び経路でシグナリングメッセージの一部で伝送することができる。

ＴＳＩＤは、ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｎｓｔａｎｃｅ ｄｅｓｃｒｉｐｔｏｒの略語であり、伝送セッションに関する詳細情報を含むデスクリプタを示すことができる。

ＴＳＩＤは、各伝送セッションに対して、ｔｓｉ属性、ＳｏｕｒｃｅＦｌｏｗで伝送されるＰａｙｌｏａｄＦｏｒａｍｔエレメント、及び／又はＲｅｐａｉｒＦｌｏｗを含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ｃｏｄｅＰｏｉｎｔ、ｐｒｏｔｏｃｏｌ、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ、ｒｅａｌｔｉｍｅ、ｉｓｏｂｍｆｆ及び／又はｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅ属性を含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ＥＦＩＤ及び／又はＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒエレメントを含むことができる。

ｔｓｉは、伝送セッション識別子を示すことができる。

ｃｏｄｅＰｏｉｎｔは、ペイロードに対して定義されたコードポイント値を示すことができる。この値は、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。

ｐｒｏｔｏｃｏｌは、現在ｐａｙｌｏａｄの伝送プロトコルを示す。すなわち、ｐｒｏｔｏｃｏｌは、ペイロードレベルで各ペイロードに対する伝送プロトコルを定義することができる。ＬＣＴベースの伝送プロトコルには様々なものが存在してもよく、それぞれに整数値を割り当ててその種類を識別することができる。一例として、０の場合はＡＬＣを、１の場合はＲＯＵＴＥを識別することができる。また、その他のプロトコル及び将来定義される新しいプロトコルに対しても、同様の方法の識別方法を適用することができる。また、上記の実施例では、＠ｃｏｄｅｐｏｉｎｔに割り当てられた値と一致するｃｏｄｅｐｏｉｎｔ値を有するＬＣＴパケット単位で別個の＠ｐｒｏｔｏｃｏｌ値を割り当てることができ、よって、一つの伝送セッション内で様々なプロトコルを用いたコンテンツの伝送が可能である。

ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔは、伝送オブジェクトのペイロードフォーマットを示すことができる。

ｒｅａｌｔｉｍｅは、ＬＣＴパケットが実時間サービスのためのコンポーネントデータを含んでいるかを示すことができる。実時間サービスのためのコンポーネントデータを含んでいる場合、当該伝送オブジェクトのプレゼンテーションタイムを表現するＮＴＰタイムスタンプ（ＮＴＰ ｔｉｍｅｓｔａｍｐｓ）を含む拡張ヘッダーを含むか否かを示すことができる。

ｉｓｏｂｍｆｆは、伝送オブジェクトがＩＳＯＢＭＦＦボックスのシーケンスであるか、ＭＰＤによって参照されたＤＡＳＨオブジェクトであるか、又はＭＭＴのＭＰＵモードによってフラグメントされたＩＳＯＢＭＦＦボックスのシーケンスであるかを示すことができる。

ｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅは、ルートパケット（ｒｏｕｔｅ ｐａｃｋｅｔ）ヘッダーのサイズを示すことができる。

ＥＦＩＤは、ファイル伝送データに関する詳細情報を含むことができる。

ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、伝送セッションで伝達されるアプリケーションにマップ可能な付加情報を提供することができる。例えばＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤを示すことができる。

図６４は、本発明の他の実施例に係るセッションレベルの伝送セッション情報のためのシグナリング情報を示す。ＬＣＴベースのプロトコルを用いて実時間又は非実時間コンテンツを伝送する場合、ＴＳＩＤのような、セッションレベルの伝送セッション情報記述のためのシグナリング情報を用いることができる。ＴＳＩＤは、伝送コンテンツと同じ帯域内（ｉｎ−ｂａｎｄ）或いは異なる経路を用いる帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）などの様々な方法及び経路でシグナリングメッセージの一部で伝送することができる。

一つの伝送セッション内で伝送されるパケットのプロトコルがいずれも同一である場合、ＴＳＩＤは、次のような構造で示すことができる。すなわち、ｐｒｏｔｏｃｏｌ属性はＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎレベルに存在でき、ｔｓｉ属性のＴＳＩ値を有するセッションの全パケットが、ｐｒｏｔｏｃｏｌ属性に割り当てられた値に該当するプロトコルで伝送されることを示すことができる。

ＴＳＩＤは、各伝送セッションに対して、ｔｓｉ属性、ＳｏｕｒｃｅＦｌｏｗのｐｒｏｔｏｃｏｌ属性、ＰａｙｌｏａｄＦｏｒａｍｔエレメント、及び／又はＲｅｐａｉｒＦｌｏｗを含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ｃｏｄｅＰｏｉｎｔ、ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔ、ｒｅａｌｔｉｍｅ、ｉｓｏｂｍｆｆ及び／又はｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅ属性を含むことができる。また、ＰａｙｌｏａｄＦｏｒａｍｔエレメントは、ＥＦＩＤ及び／又はＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒエレメントを含むことができる。

ｔｓｉは、伝送セッション識別子を示すことができる。

ｐｒｏｔｏｃｏｌは、現在ｐａｙｌｏａｄの伝送プロトコルを示す。ＬＣＴベースの伝送プロトコルには様々なものが存在してもよく、それぞれに整数値を割り当ててその種類を識別することができる。一例として、０の場合はＡＬＣ、１の場合はＲＯＵＴＥを識別することができる。また、その他のプロトコル及び将来定義される新しいプロトコルに対しても、同様の方法の識別方法を適用することができる。また、上記の実施例では、一つの伝送セッション内に含まれた全パケットに対して、同一のプロトコルを用いたコンテンツの伝送が可能である。

ｃｏｄｅＰｏｉｎｔは、ペイロードに対して定義されたコードポイント値を示すことができる。この値は、ＬＣＴヘッダーのＣＰフィールドの値を示すことができる。

ｄｅｌｉｖｅｒｙＯｂｊｅｃｔＦｏｒｍａｔは、伝送オブジェクトのペイロードフォーマットを示すことができる。

ｒｅａｌｔｉｍｅは、ＬＣＴパケットが伝送オブジェクトのプレゼンテーションタイムを表現するＮＴＰタイムスタンプ（ＮＴＰ ｔｉｍｅｓｔａｍｐｓ）を含む拡張ヘッダーを含むか否かを示すことができる。

ｉｓｏｂｍｆｆは、伝送オブジェクトがＩＳＯＢＭＦＦボックスのシーケンスであるか、ＭＰＤによって参照されたＤＡＳＨオブジェクトであるか、又はＭＭＴのＭＰＵモードによってフラグメントされたＩＳＯＢＭＦＦボックスのシーケンスであるかを示すことができる。

ｐａｃｋｅｔｈｅａｄｅｒｓｉｚｅは、ルートパケットヘッダーのサイズを示すことができる。

ＥＦＩＤは、ファイル伝送データに関する詳細情報を含むことができる。

ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、伝送セッションで伝達されるアプリケーションにマップ可能な付加情報を提供することができる。例えば、ＤＡＳＨコンテンツのＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤを示すことができる。

図６５は、本発明の一実施例に係る放送受信装置の動作手順を示すフローチャートである。

放送受信装置の受信部は、サービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信する（Ｓ１０１）。受信部は、インターネットプロトコル通信部及び放送受信部を含むことができる。サービスシグナリングメッセージは、放送サービス及びメディアコンテンツのうち少なくとも一つをシグナルするための情報であってもよい。一実施例で、伝送プロトコルはインターネットプロトコル（ＩＰ）であってもよい。また、一実施例で、サービスシグナリングメッセージは、バイナリフォーマット及びＸＭＬフォーマットの少なくとも一つで表現されてもよい。伝送プロトコルパケットは、シグナリングメッセージヘッダー及びシグナリングメッセージを含むことができる。

放送受信装置の制御部は、受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出する（Ｓ１０３）。具体的に、伝送プロトコルパケットをパースしてサービスシグナリングメッセージを抽出することができる。制御部は、階層化された伝送プロトコルパケットからインターネットプロトコルデータグラムを取得することができる。取得したインターネットプロトコルデータグラムは、サービスシグナリングメッセージを含むことができる。

放送受信装置の制御部は、サービスシグナリングメッセージから放送サービスの提供のための情報を取得する（Ｓ１０５）。放送サービスの提供のための情報は、サービスシグナリングメッセージの一部であってもよい。

一実施例で、放送サービスを提供するための情報は、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのためのサービス情報であってもよい。

他の実施例で、放送サービスを提供するための情報は、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のためのサービス情報であってもよい。適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報はＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）であってもよい。

他の実施例で、放送サービスを提供するための情報は、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のためのサービス情報であってもよい。コンポーネントデータは、放送サービス又はコンテンツを構成する個体であってもよい。このとき、コンポーネントデータの取得経路情報は、コンポーネントデータを伝達する物理層パイプの識別情報であってもよい。階層化された伝送プロトコルパケットは、物理層で伝達される物理層パイプを含むことができる。物理層パイプは複数個存在してもよい。したがって、複数の物理層パイプの中から、取得しようとするコンポーネントデータを含む物理層パイプを識別する必要がある。

他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するアプリケーションのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、アプリケーションのためのシグナリングメッセージのためのサービス情報は、アプリケーションを送信する放送局の識別子情報、アプリケーションを含むインターネットプロトコルデータグラムのソースＩＰアドレス、アプリケーションを含むインターネットプロトコルデータグラムの送信先ＩＰアドレス、上記アプリケーションを含むインターネットプロトコルデータグラムのユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ；ＵＤＰ）のポート番号、上記アプリケーションを送信する伝送セッションの識別子情報、及び上記アプリケーションを送信するパケットの識別子情報の少なくとも一つであってもよい。

他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するサービスのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、サービスは一つのコンテンツであってもよい。

他の実施例で、放送サービスを提供するための情報は、放送サービスのコンポーネントを伝達するフローのためのサービス情報であってもよい。

図６６は、本発明の一実施例に係る放送送信装置の動作手順を示すフローチャートである。

放送伝送装置の制御部は、放送サービスの提供のための情報をサービスシグナリングメッセージに挿入する（Ｓ２０１）。一実施例で、放送伝送装置の制御部は、放送サービスの提供のための情報をＸＭＬ形態でサービスシグナリングメッセージに挿入することができる。他の実施例で、放送伝送装置の制御部は、放送サービスの提供のための情報をバイナリ形態でサービスシグナリングメッセージに挿入することができる。

放送伝送装置の制御部は、放送サービスの提供のための情報が挿入されたサービスシグナリングメッセージを伝送プロトコルパケットにパケット化（ｐａｃｋｅｔｉｚｉｎｇ）する（Ｓ２０３）。このとき、伝送プロトコルは、セッションベース伝送プロトコル（ＡＬＣ／ＬＣＴ、ＦＬＵＴＥ）及びパケットベース伝送プロトコル（ＭＰＥＧ−２ＴＳ、ＭＭＴ）のいずれか一つであってもよい。

放送伝送装置の発信部は、サービスシグナリングメッセージがパケット化された伝送プロトコルパケットを特定の伝送モードで放送受信装置に伝送する（Ｓ２０５）。

一実施例で、放送サービスを提供するための情報は、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのためのサービス情報であってもよい。

他の実施例で、放送サービスを提供するための情報は、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のためのサービス情報であってもよい。適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報は、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）であってもよい。

他の実施例で、放送サービスを提供するための情報は、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のためのサービス情報であってもよい。コンポーネントデータは、放送サービス又はコンテンツを構成する個体であってもよい。このとき、コンポーネントデータの取得経路情報は、コンポーネントデータを伝達する物理層パイプの識別情報であってもよい。階層化された伝送プロトコルパケットは、物理層で伝達される物理層パイプを含むことができる。物理層パイプは複数個存在してもよい。したがって、複数の物理層パイプの中から、取得しようとするコンポーネントデータを含む物理層パイプを識別する必要がある。

他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するアプリケーションのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、アプリケーションのためのシグナリングメッセージのためのサービス情報は、アプリケーションを送信する放送局の識別子情報、アプリケーションを含むインターネットプロトコルデータグラムのソースＩＰアドレス、アプリケーションを含むインターネットプロトコルデータグラムの送信先ＩＰアドレス、上記アプリケーションを含むインターネットプロトコルデータグラムのユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ；ＵＤＰ）のポート番号、上記アプリケーションを送信する伝送セッションの識別子情報、及び上記アプリケーションを送信するパケットの識別子情報の少なくとも一つであってもよい。

他の実施例で、放送サービスを提供するための情報は、放送サービスで使用するサービスのためのシグナリングメッセージのためのサービス情報であってもよい。このとき、サービスは一つのコンテンツであってもよい。

他の実施例で、放送サービスを提供するための情報は、放送サービスのコンポーネントを伝達するフローのためのサービス情報であってもよい。

本発明の一実施例は、地上波放送網とインターネット網との連動ベースの次世代ハイブリッド放送を支援する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。

特に、本発明の一実施例は、次世代放送システムにおけるサービスシグナリングメッセージのペイロードフォーマットを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。

特に、本発明の一実施例は、次世代放送システムで放送サービスシグナリングを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。

特に、本発明の一実施例は、次世代放送システムで放送サービスのコンポーネント取得経路に対するシグナリングを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。

特に、本発明の一実施例は、次世代放送システムで放送サービスのコンポーネントの伝送フローに対するシグナリングを利用する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供する。

以上実施例に説明した特徴、構造、効果などは本発明の少なくとも一つの実施例に含まれるものであり、必ずしも一つの実施例に限定されるものではない。なお、各実施例で例示した特徴、構造、効果などは、実施例の属する分野における通常の知識を有する者にとって他の実施例に対して組合せ又は変形して実施することも可能である。したがって、それらの組合せ又は変形に関する内容も、本発明の範囲に含まれるものとして解釈しなければならない。

以上、実施例を中心に説明してきたが、これは単なる例示であり、本発明を限定するものではない。したがって、本発明の属する分野における通常の知識を有する者にとって本実施例の本質的な特性を逸脱しない範囲で、以上に例示していない様々な変形及び応用が可能であることは明らかである。例えば、実施例に具体的に示した各構成要素を変形して実施することも可能であろう。そして、このような変形と応用に関係する差異点は、添付する特許請求の範囲で規定する本発明の範囲に含まれるものとして解釈すべきであろう。

Claims (20)

1. 放送サービスの提供のための情報をサービスシグナリングメッセージに挿入し、前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化する制御部と、
   前記伝送プロトコルパケットを伝送する発信部と、
   を備える、放送送信装置。
2. 前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含む、請求項１に記載の放送送信装置。
3. 前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含む、請求項２に記載の放送送信装置。
4. 前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー情報、伝送セッション識別子情報、及び関連したパケット識別子情報のうち少なくとも一つを含む、請求項３に記載の放送送信装置。
5. 前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含む、請求項２に記載の放送送信装置。
6. 前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含む、請求項５に記載の放送送信装置。
7. 前記放送サービスを提供するための情報は、伝送セッションに関する情報を含む、請求項１に記載の放送送信装置。
8. 前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含む、請求項７に記載の放送送信装置。
9. 前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含む、請求項７に記載の放送送信装置。
10. 放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信する受信部と、
    前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出し、抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得する制御部と、
    を備える、放送受信装置。
11. 前記放送サービスを提供するための情報は、放送サービスで使用する、コンテンツのための一連の時間情報であるタイムラインに対するメタデータを含むタイムベースのための第１のサービス情報、適応型メディアストリーミングにおいてコンテンツを構成するセグメントの取得のための詳細情報のための第２のサービス情報、放送サービスにおいてコンテンツを構成するコンポーネントデータの取得経路のための第３のサービス情報、放送サービスで使用するアプリケーションのためのシグナリングメッセージのための第４のサービス情報、及び前記放送サービスを構成する前記コンポーネントデータを含むフローのための第５のサービス情報のうち少なくとも一つを含む、請求項１０に記載の放送受信装置。
12. 前記第１のサービス情報、前記第２のサービス情報、前記第３のサービス情報、及び前記第４のサービス情報のうち少なくとも一つは、伝送モードに関する情報及びブートストラップ情報を含む、請求項１１に記載の放送受信装置。
13. 前記ブートストラップ情報は、前記伝送モードに関する情報に基づいて、各サービス情報を取得可能な情報であるＩＰアドレス情報、ポートナンバー情報、伝送セッション識別子情報、及び関連したパケット識別子情報のうち少なくとも一つを含む、請求項１２に記載の放送受信装置。
14. 前記第５のサービス情報は、前記フローに含まれた少なくとも一つのオブジェクトのフォーマットに関する情報を含む、請求項１１に記載の放送受信装置。
15. 前記第５のサービス情報は、前記少なくとも一つのオブジェクトが含むペイロードがデフォルトとして用いられるコンポーネントデータを含むか否かを示す情報を含む、請求項１４に記載の放送受信装置。
16. 前記放送サービスを提供するための情報は、伝送セッションに関する情報を含む、請求項１０に記載の放送受信装置。
17. 前記伝送セッションに関する情報は、少なくとも一つのペイロードに関する情報、及び各ペイロードが伝送されるプロトコルに関する情報を含む、請求項１６に記載の放送受信装置。
18. 前記伝送セッションに関する情報は、少なくとも一つのペイロードを含み、前記伝送セッションに含まれたペイロードが伝送されるプロトコルに関する情報を伝送セッションレベルで含む、請求項１６に記載の放送受信装置。
19. 放送サービスの提供のための情報をサービスシグナリングメッセージに挿入するステップと、
    前記サービスシグナリングメッセージを伝送プロトコルパケットにパケット化するステップと、
    前記伝送プロトコルパケットを伝送するステップと、
    を有する、放送送信方法。
20. 放送サービスをシグナルするためのサービスシグナリングメッセージが含まれた伝送プロトコルパケットを受信するステップと、
    前記受信した伝送プロトコルパケットからサービスシグナリングメッセージを抽出するステップと、
    前記抽出したサービスシグナリングメッセージから放送サービスを提供するための情報を取得するステップと、
    を有する、放送受信方法。

Images