(57)【特許請求の範囲】
【請求項１】
放送サービスのための放送データをエンコードするステップと、
前記放送サービスの発見及び取得に関する情報を提供する第１シグナリング情報を生成するステップと、
前記放送サービスの速い取得に関する情報を有する第２シグナリング情報を生成するステップであって、
前記第２シグナリング情報は、前記放送サービスを識別する第１サービス識別子と前記第１シグナリング情報を伝達する伝送セッションを示すブートストラップ情報とを有するステップと、
固定サイズを有する第１物理層シグナリング情報と可変サイズを有する第２物理層シグナリング情報とを有する物理層シグナリング情報をエンコードするステップであって、
前記第１物理層シグナリング情報は、前記第２物理層シグナリング情報の保護に関する前方誤り訂正（ＦＥＣ）タイプを示す情報と前記第２物理層シグナリング情報のサイズを示す情報とを有し、
前記第２物理層シグナリング情報は、前記放送データをデコードするのに必要な情報と前記第２シグナリング情報に関する情報とを有するステップと、
前記エンコードされた放送データ、前記生成された第１シグナリング情報、前記生成された第２シグナリング情報及び前記エンコードされた物理層シグナリング情報を有する放送信号を生成するステップと、を有し、
前記第１シグナリング情報は、第２サービス識別子を有するユーザサービス記述（User Service Description；ＵＳＤ）情報を有し、前記第２サービス識別子は、前記第１サービス識別子と同じ値を有することによって前記第２シグナリング情報における前記放送サービスに関するサービスエントリを参照し、
前記ＵＳＤ情報は、前記放送サービスに関する技術的情報の詳細を記述し、
前記第１シグナリング情報は、メディアプレゼンテーション記述（Media Presentation Description；ＭＰＤ）情報及び伝送セッションインスタンス記述（transport session instance description）情報をさらに有し、
前記伝送セッションインスタンス記述情報は、前記放送サービスの第１コンポーネントを伝達する第１ＬＣＴチャネルを識別する第１伝送セッション識別子（Transport Session Identifier；ＴＳＩ）値を有する、放送信号生成処理方法。
【請求項２】
前記ＵＳＤ情報は、第３サービス識別子をさらに有し、
前記第３サービス識別子は、電子サービスガイド（Electronic Service Guide；ＥＳＧ）データとリンクするのに使用される、請求項１に記載の放送信号生成処理方法。
【請求項３】
前記第１シグナリング情報は、受信機が前記放送サービスに有される放送コンテンツを示す（present）のに必要な能力を特定する能力情報をさらに有する、請求項１に記載の放送信号生成処理方法。
【請求項４】
前記ＵＳＤ情報は、基本的パターン情報をさらに有し、
前記基本的パターン情報は、前記ＭＰＤ情報におけるリソース識別子とマッチさせて識別するのに使用される文字パターンを有する、請求項１に記載の放送信号生成処理方法。
【請求項５】
前記伝送セッションインスタンス記述情報は、前記放送サービスの第２コンポーネントを伝達する第２ＬＣＴチャネルを識別する第２ＴＳＩ値をさらに有し、
前記第２コンポーネントは、前記第１コンポーネントと異なるプレゼンテーション能力を有する、請求項１に記載の放送信号生成処理方法。
【請求項６】
放送サービスのための放送データと、前記放送サービスの発見及び取得に関する情報を提供する第１シグナリング情報と、前記放送サービスを識別する第１サービス識別子と前記第１シグナリング情報を伝達する伝送セッションを示すブートストラップ情報とを有する第２シグナリング情報と、物理層シグナリング情報と、を有する放送信号を受信するよう構成された放送信号受信部と、
前記放送信号に有される前記物理層シグナリング情報をデコードし、前記放送信号に有される前記第２シグナリング情報をデコードし、前記放送信号に有される前記第１シグナリング情報をデコードし、前記放送信号に有される前記放送データをデコードするよう構成されたプロセッサと、を有し、
前記第２シグナリング情報は、前記放送サービスの速い取得に関する情報を有し、
前記第１シグナリング情報は、第２サービス識別子を有するユーザサービス記述（User Service Description；ＵＳＤ）情報を有し、前記第２サービス識別子は、前記第１サービス識別子と同じ値を有することによって前記第２シグナリング情報における前記放送サービスに関するサービスエントリを参照し、
前記ＵＳＤ情報は、前記放送サービスに関する技術的情報の詳細を記述し、
前記第１シグナリング情報は、メディアプレゼンテーション記述（Media Presentation Description；ＭＰＤ）情報及び伝送セッションインスタンス記述（transport session instance description）情報をさらに有し、
前記伝送セッションインスタンス記述情報は、前記放送サービスの第１コンポーネントを伝達する第１ＬＣＴチャネルを識別する第１伝送セッション識別子（Transport Session Identifier；ＴＳＩ）値を有し、
前記物理層シグナリング情報は、固定サイズを有する第１物理層シグナリング情報と可変サイズを有する第２物理層シグナリング情報とを有し、
前記第１物理層シグナリング情報は、前記第２物理層シグナリング情報の保護に関する前方誤り訂正（ＦＥＣ）タイプを示す情報と前記第２物理層シグナリング情報のサイズを示す情報とを有し、
前記第２物理層シグナリング情報は、前記放送データをデコードするのに必要な情報と前記第２シグナリング情報に関する情報とを有する、受信装置における放送信号受信機。
【請求項７】
前記ＵＳＤ情報は、第３サービス識別子をさらに有し、
前記第３サービス識別子は、電子サービスガイド（Electronic Service Guide；ＥＳＧ）データとリンクするのに使用される、請求項６に記載の放送信号受信機。
【請求項８】
前記第１シグナリング情報は、受信機が前記放送サービスに有される放送コンテンツを示す（present）のに必要な能力を特定する能力情報をさらに有する、請求項６に記載の放送信号受信機。
【請求項９】
前記ＵＳＤ情報は、基本的パターン情報をさらに有し、
前記基本的パターン情報は、前記ＭＰＤ情報におけるリソース識別子とマッチさせて識別するのに使用される文字パターンを有する、請求項６に記載の放送信号受信機。
【請求項１０】
前記伝送セッションインスタンス記述情報は、前記放送サービスの第２コンポーネントを伝達する第２ＬＣＴチャネルを識別する第２ＴＳＩ値をさらに有し、
前記第２コンポーネントは、前記第１コンポーネントと異なるプレゼンテーション能力を有する、請求項６に記載の放送信号受信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関する。
【背景技術】
【０００２】
アナログ放送信号送信が終了することにより、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてより多量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータの他、様々な種類の付加データもさらに含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
すなわち、デジタル放送システムは、ＨＤ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ  ｃｈａｎｎｅｌ、多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかしながら、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークの堅固性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させなければならない。
【課題を解決するための手段】
【０００４】
上述した技術的課題を解決するための本発明の一実施例に係る放送信号生成処理方法は、一つ以上の放送サービスのための放送データをエンコードするステップと、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコードするステップと、前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードするステップと、前記放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成するステップとを含み、前記第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送され、前記第２レベルシグナリング情報は、前記第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）を識別するＰＬＰ  ＩＤ情報を含む。
【０００５】
好ましくは、前記第１シグナリング情報は、放送サービスに対するサービス層属性を記述するＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）情報、前記放送サービスに含まれるコンポーネントを取得するための情報を提供する伝送セッション記述情報、及び前記放送サービスをストリーム（ｓｔｒｅａｍｉｎｇ）するために必要な情報を提供するＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）情報を含むことを特徴とする。
【０００６】
好ましくは、前記ＵＳＤ情報は、前記ＭＰＤ情報が提供される位置を識別するＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を示すＭＰＤ  ＵＲＩ情報を含むことを特徴とする。
【０００７】
好ましくは、前記ＵＳＤ情報は、前記伝送セッション記述情報が提供される位置を識別するＵＲＩを示すＵＲＩ情報をさらに含むことを特徴とする。
【０００８】
好ましくは、前記伝送セッション記述情報は、前記コンポーネントを伝送するＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションを識別するＴＳＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）情報を含むことを特徴とする。
【０００９】
好ましくは、前記ＵＳＤ情報は、前記放送サービスを識別するサービス識別情報、及び前記放送サービスに含まれる放送コンテンツの表出のために要求される受信機の能力（ｃａｐａｂｉｌｉｔｙ）を識別する能力情報をさらに含むことを特徴とする。
【００１０】
好ましくは、前記ＵＳＤ情報は、前記放送コンテンツが伝送される方法に関する情報を含むｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントをさらに含むことを特徴とする。
【００１１】
上述した技術的課題を解決するための本発明の一実施例に係る放送信号受信機は、一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報を含む放送信号を受信する放送信号受信部であって、前記第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送され、前記第２レベルシグナリング情報は、前記第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）を識別するＰＬＰ  ＩＤ情報を含む、放送信号受信部と、前記放送信号内の既に定められた位置で前記第２レベルシグナリング情報を抽出し、前記第２レベルシグナリング情報に含まれるＩＰ住所情報及びＰＬＰ  ＩＤ情報を用いて前記第１レベルシグナリング情報を抽出し、前記第１レベルシグナリング情報を用いて前記放送サービスを取得し、前記放送サービスを表出するように制御するプロセッサとを含む。
【００１２】
好ましくは、前記第１シグナリング情報は、放送サービスに対するサービス層属性を記述するＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）情報、前記放送サービスに含まれるコンポーネントを取得するための情報を提供する伝送セッション記述情報、及び前記放送サービスをストリームするために必要な情報を提供するＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）情報を含むことを特徴とする。
【００１３】
好ましくは、前記ＵＳＤ情報は、前記ＭＰＤ情報が提供される位置を識別するＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を示すＭＰＤ  ＵＲＩ情報を含むことを特徴とする。
【００１４】
好ましくは、前記ＵＳＤ情報は、前記伝送セッション記述情報が提供される位置を識別するＵＲＩを示すＵＲＩ情報をさらに含むことを特徴とする。
【００１５】
好ましくは、前記伝送セッション記述情報は、前記コンポーネントを伝送するＬＣＴ（Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）セッションを識別するＴＳＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）情報を含むことを特徴とする。
【００１６】
好ましくは、前記ＵＳＤ情報は、前記放送サービスを識別するサービス識別情報、及び前記放送サービスに含まれる放送コンテンツの表出のために要求される受信機の能力を識別する能力情報をさらに含むことを特徴とする。
【００１７】
好ましくは、前記ＵＳＤ情報は、前記放送コンテンツが伝送される方法に関する情報を含むｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントをさらに含むことを特徴とする。
【００１８】
好ましくは、前記プロセッサは、前記第１レベルシグナリング情報内の前記ＵＳＤ情報をパースし、前記パースされたＵＳＤ情報内の前記ＵＲＩ情報が示す位置で前記伝送セッション記述情報をパースし、前記パースされた伝送セッション記述情報内の前記ＴＳＩ情報を用いて前記コンポーネントを取得し、前記パースされたＵＳＤ情報内の前記ＭＰＤ  ＵＲＩ情報を用いて前記ＭＰＤ情報をパースし、前記パースされたＭＰＤ内の情報を用いて前記コンポーネントを表出し、前記放送サービスを処理することを特徴とする。
【発明の効果】
【００１９】
本発明は、サービス特性に応じてデータを処理し、各サービス又はサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を制御することによって様々な放送サービスを提供することができる。
【００２０】
本発明は、同じＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）信号帯域幅で様々な放送サービスを伝送することによって伝送柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成することができる。
【００２１】
本発明によれば、モバイル受信装置を使用したり、室内環境にいても、誤り無しでデジタル放送信号を受信することができる放送信号送信及び受信方法並びに装置を提供することができる。
【００２２】
本発明は、地上波放送網とインターネット網とを使用する次世代ハイブリッド放送を支援する環境で次世代放送サービスを効果的に支援することができる。
【図面の簡単な説明】
【００２３】
本発明のさらなる理解のために含まれ、本出願に含まれ、その一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に本発明の実施例を示す。
【図１】本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ  ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示した図である。
【図２】本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）の関係を示した図である。
【図３】本発明の一実施例に係るＳＬＴを示した図である。
【図４】本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリ過程を示した図である。
【図５】本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。
【図６】本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。
【図７】本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。
【図８】本発明の一実施例に係るリンク層プロトコルアーキテクチャを示した図である。
【図９】本発明の一実施例に係るリンク層パケットのベースヘッダーの構造を示した図である。
【図１０】本発明の一実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。
【図１１】本発明の他の実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。
【図１２】本発明の一実施例に係る、ＭＰＥＧ−２  ＴＳパケットのためのリンク層パケットのヘッダー構造、及びそのカプセル化過程を示した図である。
【図１３】本発明の一実施例に係るＩＰヘッダー圧縮において、適応モードの実施例を示した図である（送信側）。
【図１４】本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）及びＲＯＨＣ−Ｕ記述テーブルを示した図である。
【図１５】本発明の一実施例に係る送信機側のリンク層の構造を示した図である。
【図１６】本発明の一実施例に係る受信機側のリンク層の構造を示した図である。
【図１７】本発明の一実施例に係る、リンク層を介したシグナリング伝送構造を示した図である（送／受信側）。
【図１８】本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置の構造を示す図である。
【図１９】本発明の一実施例に係るＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。
【図２０】本発明の他の一実施例に係るＢＩＣＭブロックを示す図である。
【図２１】本発明の一実施例に係るＰＬＳのビットインターリービング過程を示す図である。
【図２２】本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す図である。
【図２３】本発明の一実施例に係るフレームのシグナリング層の構造を示す図である。
【図２４】本発明の一実施例に係るＰＬＳ１データを示す図である。
【図２５】本発明の一実施例に係るＰＬＳ２データを示す図である。
【図２６】本発明の他の一実施例に係るＰＬＳ２データを示す図である。
【図２７】本発明の一実施例に係るフレームの論理構造を示す図である。
【図２８】本発明の一実施例に係るＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）マッピングを示す図である。
【図２９】本発明の一実施例に係る時間インターリービングを示す図である。
【図３０】本発明の一実施例に係る、ツイストされた行−列ブロックインターリーバの基本動作を示す図である。
【図３１】本発明の他の一実施例に係る、ツイストされた行−列ブロックインターリーバの動作を示す図である。
【図３２】本発明の一実施例に係る、各ＦＦＴモードによるメイン−ＰＲＢＳ生成器とサブ−ＰＲＢＳ生成器で構成されたインターリービング住所生成器のブロックダイアグラムを示す図である。
【図３３】本発明の一実施例に係る、全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。
【図３４】本発明の一実施例に係る、周波数インターリービングのためのインターリービング住所及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。
【図３５】本発明の一実施例に係る、時間インターリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す図である。
【図３６】ＰＬＰの個数によって適用するインターリービングタイプを表で示す図である。
【図３７】上述したハイブリッド時間インターリーバ構造の第１実施例を含むブロック図である。
【図３８】上述したハイブリッド時間インターリーバ構造の第２実施例を含むブロック図である。
【図３９】ハイブリッド時間デインターリーバの構造の第１実施例を含むブロック図である。
【図４０】ハイブリッド時間デインターリーバの構造の第２実施例を含むブロック図である。
【図４１】本発明の一実施例に係る次世代放送システムにおいて、放送サービスに接近するためのシグナリング体系を示した図である。
【図４２】本発明の一実施例に係る第１シグナリング方法と第２シグナリング方法を比較する表を示す図である。
【図４３】本発明の一実施例に係る放送システムで使用されるシグナリング方法を示した図である。
【図４４】本発明の一実施例に係る第４シグナリング方法によるシグナリング構造を示した図である。
【図４５】本発明の一実施例に係る第３シグナリング方法によるシグナリング構造を示した図である。
【図４６】本発明の一実施例に係る第３シグナリング方法によるシグナリング構造を具体的に示した図である。
【図４７】本発明の一実施例に係る第３シグナリング方法と第４シグナリング方法を比較した図表を示した図である。
【図４８】本発明の一実施例に係る、ｅＭＢＭＳ放送とブロードバンドを介してサービスが提供される過程を示した図である。
【図４９】本発明の一実施例に係る、ＡＴＳＣ放送とブロードバンドを介してサービスが提供される過程を示した図である。
【図５０】本発明の一実施例に係る、ＡＴＳＣ放送、ｅＭＢＭＳ放送及びブロードバンドを介してサービスが提供される過程を示した図である。
【図５１】本発明の一実施例に係るシグナリング体系を用いて、受信機が放送サービスを取得する過程を示した図である。
【図５２】本発明の一実施例に係るシグナリング体系を用いて、受信機が放送網とブロードバンドを介して提供される放送サービスを取得する過程を示した図である。
【図５３】本発明の一実施例に係るシグナリング体系を用いて、レイヤードコーディング（ｌａｙｅｒｄ  ｃｏｄｉｎｇ）が放送サービスに適用された場合、受信機が放送サービスを取得する過程を示した図である。
【図５４】本発明の一実施例に係るシグナリング体系を用いて、放送サービス／コンテンツの一つの要素に対して複数のコンポーネントが提供される場合、受信機が放送サービスを取得する過程を示した図である。
【図５５】本発明の一実施例に係るサービスマップテーブル（Ｓｅｒｖｉｃｅ  Ｍａｐ  Ｔａｂｌｅ；ＳＭＴ）を示した図である。
【図５６】本発明の一実施例に係るＡＴＳＣ  ＵＳＤを示した図である。
【図５７】本発明の他の実施例によるａｔｓｃ  ＵＳＤを示した図である。
【図５８】本発明の一実施例に係る放送信号を生成処理する方法を示したフローチャートである。
【図５９】本発明の一実施例に係る放送システムを示した図である。
【発明を実施するための形態】
【００２４】
本発明の好適な実施例について具体的に説明し、その例は添付の図面に示す。添付の図面を参照する下記の詳細な説明は、本発明の具現可能な実施例のみを示すものではなく、本発明の好適な実施例を説明するものである。下記の詳細な説明は、本発明に対する徹底した理解を提供するために細部事項を含む。しかし、本発明がこのような細部事項無しでも実行可能であることは当業者にとって明らかである。
【００２５】
本発明で使われる大部分の用語は、当該分野で広く使われる一般的な用語から選択されるが、一部の用語は出願人によって任意に選択されたものもあり、その意味は必要によって該当の説明部分で詳細に説明する。したがって、本発明は、用語の単純な名称や意味ではなく、用語が意図する意味に基づいて理解されなければならない。
【００２６】
本発明は、次世代放送サービスに対する放送信号の送信及び受信装置及び方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含むことができる。
【００２７】
図１は、本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒ  ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）を示した図である。
【００２８】
放送網を介したサービスデリバリ（ｂｒｏａｄｃａｓｔ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）において、２つの方法があり得る。
【００２９】
第一の方法は、ＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）に基づいて、ＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔｓ）をＭＭＴＰ（ＭＭＴ  ｐｒｏｔｏｃｏｌ）を用いて伝送することである。第二の方法は、ＭＰＥＧ  ＤＡＳＨに基づいて、ＤＡＳＨセグメントをＲＯＵＴＥ（Ｒｅａｌ  ｔｉｍｅ  Ｏｂｊｅｃｔ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を用いて伝送することである。
【００３０】
ＮＲＴメディア、ＥＰＧデータ、及び他のファイルを含む非時間コンテンツは、ＲＯＵＴＥで伝達される。シグナルは、ＭＭＴＰ及び／又はＲＯＵＴＥを介して伝達できる一方、ブートストラップシグナリング情報はＳＬＴ（ｓｅｒｖｉｃｅ  ｌｉｓｔ  ｔａｂｌｅ）によって提供される。
【００３１】
ハイブリッドサービスデリバリ（ｈｙｂｒｉｄ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）においては、ＨＴＴＰ／ＴＣＰ／ＩＰ上のＭＰＥＧ  ＤＡＳＨがブロードバンド側で用いられる。ＩＳＯ  ＢＭＦＦ（ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）のメディアファイルは、デリバリ、ブロードキャスト及びブロードバンドデリバリに対するメディアカプセル化及び同期化フォーマットとして使用される。ここで、ハイブリッドサービスデリバリとは、１つ又はそれ以上のプログラムエレメントがブロードバンド経路（ｐａｔｈ）を介して伝達される場合のことをいえる。
【００３２】
サービスは、３つの機能層を用いて伝達される。これらは、物理層、デリバリ層、サービス管理層である。物理層は、シグナル、サービス公知、ＩＰパケットストリームがブロードキャスト物理層及び／又はブロードバンド物理層で伝送されるメカニズムを提供する。デリバリ層は、オブジェクト及びオブジェクトフロー伝送機能を提供する。これは、ブロードキャスト物理層のＵＤＰ／ＩＰマルチキャストで動作するＭＭＴＰ又はＲＯＵＴＥプロトコルによって可能であり、ブロードバンド物理層のＴＣＰ／ＩＰユニキャストでＨＴＴＰプロトコルによって可能である。サービス管理層は、下位であるデリバリ及び物理層によって実行されるリニアＴＶ又はＨＴＭＬ５応用サービスのような全てのサービスを可能にする。
【００３３】
本図において、放送（ｂｒｏａｄｃａｓｔ）側のプロトコルスタック部分は、ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分とに分けられる。
【００３４】
ＳＬＴは、ＵＤＰ、ＩＰ層を経てカプセル化されてもよい。ここで、ＳＬＴについては後述する。ＭＭＴＰは、ＭＭＴで定義されるＭＰＵフォーマットでフォーマットされたデータ、及びＭＭＴＰによるシグナリング情報を伝送することができる。これらのデータは、ＵＤＰ、ＩＰ層を経てカプセル化されてもよい。ＲＯＵＴＥは、ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、そして、ＮＲＴなどのノンタイムド（ｎｏｎ  ｔｉｍｅｄ）データを伝送することができる。これらのデータも、ＵＤＰ、ＩＰ層を経てカプセル化されてもよい。実施例によって、ＵＤＰ、ＩＰ層によるプロセシングは一部又は全部省略されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であり得る。
【００３５】
ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分は、ＵＤＰ、ＩＰ層で処理された後、データリンク層（Ｄａｔａ  Ｌｉｎｋ  Ｌａｙｅｒ）で再びカプセル化されてもよい。リンク層については後述する。リンク層で処理された放送データは、物理層でエンコーディング／インターリービングなどの過程を経て放送信号としてマルチキャストされてもよい。
【００３６】
本図において、ブロードバンド（ｂｒｏａｄｂａｎｄ）側のプロトコルスタック部分は、前述したように、ＨＴＴＰを介して伝送されてもよい。ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、ＮＲＴなどの情報がＨＴＴＰを介して伝送されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であってもよい。このデータは、ＴＣＰ、ＩＰ層を経てプロセスされた後、リンク層でカプセル化されてもよい。実施例によって、ＴＣＰ、ＩＰ、リンク層の一部又は全部は省略されてもよい。この後、処理されたブロードバンドデータは、物理層で伝送のための処理を経てブロードバンドにユニキャストされてもよい。
【００３７】
サービスは、全体的にユーザに見せるメディアコンポーネントのコレクションであってもよく、コンポーネントは、種々のメディアタイプのものであってもよく、サービスは、連続的又は間欠的であってもよく、サービスは、リアルタイム又は非リアルタイムであってもよく、リアルタイムサービスはＴＶプログラムのシーケンスで構成されてもよい。
【００３８】
図２は、本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）の関係を示した図である。
【００３９】
サービスシグナリングは、サービスディスカバリ及び記述情報を提供し、２つの機能コンポーネントを含む。これらは、ＳＬＴを介したブートストラップシグナリングとＳＬＳである。これらは、ユーザサービスを発見し、取得するのに必要な情報を示す。ＳＬＴは、受信機が、基本サービスリストを作成し、各サービスに対するＳＬＳの発見をブートストラップできるようにする。
【００４０】
ＳＬＴは、基本サービス情報の非常に速い取得を可能にする。ＳＬＳは、受信機が、サービスとそのコンテンツコンポーネントを発見し、これに接続できるようにする。ＳＬＴとＳＬＳの具体的な内容については後述する。
【００４１】
前述したように、ＳＬＴは、ＵＤＰ／ＩＰを介して伝送され得る。このとき、実施例によって、この伝送において最もロバストな（ｒｏｂｕｓｔ）方法を通じて、ＳＬＴに該当するデータが伝達されてもよい。
【００４２】
ＳＬＴは、ＲＯＵＴＥプロトコルによって伝達されるＳＬＳに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＲＯＵＴＥプロトコルによるＳＬＳにブートストラップすることができる。このＳＬＳは、前述したプロトコルスタックにおいてＲＯＵＴＥの上位層に位置するシグナリング情報であって、ＲＯＵＴＥ／ＵＤＰ／ＩＰを介して伝達され得る。このＳＬＳは、ＲＯＵＴＥセッションに含まれるＬＣＴセッションのうち１つを介して伝達され得る。このＳＬＳを用いて、所望のサービスに該当するサービスコンポーネントに接近することができる。
【００４３】
また、ＳＬＴは、ＭＭＴＰによって伝達されるＭＭＴシグナリングコンポーネントに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＭＭＴＰによるＳＬＳにブートストラップすることができる。このＳＬＳは、ＭＭＴで定義するＭＭＴＰシグナリングメッセージ（Ｓｉｇｎａｌｉｎｇ  Ｍｅｓｓａｇｅ）によって伝達され得る。このＳＬＳを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。前述したように、本発明では、ＮＲＴサービスコンポーネントは、ＲＯＵＴＥプロトコルを介して伝達され、ＭＭＴＰによるＳＬＳは、これに接近するための情報も含むことができる。ブロードバンドデリバリにおいて、ＳＬＳはＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰで伝達される。
【００４４】
図３は、本発明の一実施例に係るＳＬＴを示した図である。
【００４５】
まず、サービスマネジメント、デリバリ、物理層の各論理的エンティティ間の関係について説明する。
【００４６】
サービスは、２つの基本タイプのうち１つとしてシグナルされ得る。第一のタイプは、アプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオ又はオーディオのみのサービスである。第二のタイプは、プレゼンテーション及び構成が、サービスの取得によって実行されるダウンロードアプリケーションによって制御されるサービスである。後者は、アプリベースのサービスと呼ぶこともできる。
【００４７】
サービスのコンテンツコンポーネントを伝達するＭＭＴＰセッション及び／又はＲＯＵＴＥ／ＬＣＴセッションの存在と関連する規則は、次の通りである。
【００４８】
アプリベースのエンハンスメントがないリニアサービスのブロードキャストデリバリのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、又は（２）１つ以上のＭＭＴＰセッションのうち１つ（両方ともではない）によって伝達され得る。
【００４９】
アプリベースのエンハンスメントがあるリニアサービスのブロードキャストデリバリのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、及び（２）０個以上のＭＭＴＰセッションによって伝達され得る。
【００５０】
特定の実施例において、同一のサービスでストリーミングメディアコンポーネントに対するＭＭＴＰ及びＲＯＵＴＥの両者の使用が許容されないことがある。
【００５１】
アプリベースのサービスのブロードキャストデリバリのために、サービスのコンテンツコンポーネントは１つ以上のＲＯＵＴＥ／ＬＣＴセッションによって伝達され得る。
【００５２】
それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリにおいて、ＬＣＴセッションは、オーディオ、ビデオ、又はクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアは、ＤＡＳＨセグメントとしてフォーマットされる。
【００５３】
それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージ又は全体又は一部のコンテンツコンポーネントを伝達する、１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ、又はＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。
【００５４】
ＮＲＴユーザサービス又はシステムメタデータのデリバリのために、ＬＣＴセッションは、ファイルベースのコンテンツアイテムを伝達する。これらのコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、又はサービスシグナリングやＥＳＧフラグメントのようなメタデータで構成され得る。サービスシグナリングやＥＳＧフラグメントのようなシステムメタデータのデリバリも、ＭＭＴＰのシグナリングメッセージモードを通じて行われてもよい。
【００５５】
ブロードキャストストリームは、特定の帯域内に集中したキャリア周波数の観点で定義されたＲＦチャネルの概念である。それは、［地理的領域、周波数］ペアによって識別される。ＰＬＰ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｉｐｅ）は、ＲＦチャネルの一部に該当する。各ＰＬＰは、特定のモジュレーション及びコーディングパラメータを有する。それは、属しているブロードキャストストリーム内で唯一のＰＬＰＩＤ（ＰＬＰ  ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ここで、ＰＬＰはＤＰ（ｄａｔａ  ｐｉｐｅ）と呼ぶこともできる。
【００５６】
各サービスは、２つの形態のサービス識別子によって識別される。一方は、ＳＬＴで使用され、ブロードキャスト領域内でのみ唯一のコンパクト形態であり、他方は、ＳＬＳ及びＥＳＧで使用される全世界的に唯一の形態である。ＲＯＵＴＥセッションは、ソースＩＰ住所、目的地ＩＰ住所、目的地ポート番号によって識別される。ＬＣＴセッション（それが伝達するサービスコンポーネントと関連する）は、ペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＬＣＴセッションに共通した属性及び個別ＬＣＴセッションに唯一の特定の属性は、サービス層シグナリングの一部であるＳ−ＴＳＩＤ（ｓｅｒｖｉｃｅ−ｂａｓｅｄ  ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｎｓｔａｎｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれるＲＯＵＴＥシグナリング構造で与えられる。各ＬＣＴセッションは、１つのＰＬＰを介して伝達される。実施例によって、１つのＬＣＴセッションが複数個のＰＬＰを介して伝達されてもよい。ＲＯＵＴＥセッションの互いに異なるＬＣＴセッションは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＲＯＵＴＥセッションは、複数個のＰＬＰを介して伝達されてもよい。Ｓ−ＴＳＩＤに記述された属性は、各ＬＣＴセッションに対するＴＳＩ値及びＰＬＰＩＤ、デリバリオブジェクト／ファイルに対するディスクリプタ、アプリケーション層ＦＥＣパラメータを含む。
【００５７】
ＭＭＴＰセッションは、目的地ＩＰ住所及び目的地ポート番号によって識別される。ＭＭＴＰパケットフロー（それが伝達するサービスコンポーネントと関連する）は、ペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ＿ｉｄによって識別される。各ＭＭＴＰパケットフローに共通した属性及びＭＭＴＰパケットフローの特定の属性がＳＬＴに与えられる。各ＭＭＴＰセッションに対する属性は、ＭＭＴＰセッション内で伝達され得るＭＭＴシグナリングメッセージによって与えらえる。ＭＭＴＰセッションの互いに異なるＭＭＴＰパケットフローは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＭＭＴＰセッションは、複数個のＰＬＰを介して伝達されてもよい。ＭＭＴシグナリングメッセージに記述された属性は、各ＭＭＴＰパケットフローに対してｐａｃｋｅｔ＿ｉｄ値及びＰＬＰＩＤを含む。ここで、ＭＭＴシグナリングメッセージは、ＭＭＴで定義された形態であるか、又は後述する実施例によって変形が行われた形態であってもよい。
【００５８】
以下、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【００５９】
この機能に専用であるよく知られている住所／ポートを有するＩＰパケットのペイロードに伝達されるシグナリング情報は、ＬＬＳと呼ばれる。このＩＰ住所及びポート番号は、実施例によって異なって設定されてもよい。一実施例において、ＬＬＳは、住所が２２４．０．２３．６０であり、目的地ポートが４９３７／ｕｄｐであるＩＰパケットに伝達され得る。ＬＬＳは、前述したプロトコルスタック上で、「ＳＬＴ」で表現された部分に位置し得る。ただし、実施例によって、ＬＬＳは、ＵＤＰ／ＩＰ層のプロセシングを経ずに、信号フレーム上の別途の物理チャネル（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）を介して伝送されてもよい。
【００６０】
ＬＬＳデータを伝達するＵＤＰ／ＩＰパケットは、ＬＬＳテーブルという形態でフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの開始であり得る。全てのＬＬＳテーブルの最大の長さは、物理層から伝達され得る最も大きいＩＰパケットによって６５，５０７バイトに制限される。
【００６１】
ＬＬＳテーブルは、ＬＬＳテーブルのタイプを識別するＬＬＳテーブルＩＤフィールド、及びＬＬＳテーブルのバージョンを識別するＬＬＳテーブルバージョンフィールドを含むことができる。ＬＬＳテーブルＩＤフィールドが示す値に応じて、ＬＬＳテーブルは、前述したＳＬＴを含むか、又はＲＲＴ（Ｒａｔｉｎｇ  Ｒｅｇｉｏｎ  Ｔａｂｌｅ）を含むことができる。ＲＲＴは、コンテンツ勧告レーティング（Ｃｏｎｔｅｎｔ  Ａｄｖｉｓｏｒｙ  Ｒａｔｉｎｇ）に関する情報を有することができる。
【００６２】
以下、ＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）について説明する。ＬＬＳは、受信機によるサービス取得のブートストラッピング及び速いチャネルスキャンを支援するシグナリング情報であり、ＳＬＴは、基本サービスリスティングを構築し、ＳＬＳのブートストラップディスカバリを提供するために使用されるシグナリング情報のテーブルであり得る。
【００６３】
ＳＬＴの機能は、ＭＰＥＧ−２システムでのＰＡＴ（ｐｒｏｇｒａｍ  ａｓｓｏｃｉａｔｉｏｎ  ｔａｂｌｅ）及びＡＴＳＣシステムで発見されるＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）とほぼ同一である。初めてブロードキャストエミッションを経験する受信機にとって、これは、開始される地点である。ＳＬＴは、受信機が、チャネル名、チャネル番号などでそれが受信できる全てのサービスのリストを構築できるようにする、速いチャネルスキャンを支援する。また、ＳＬＴは、受信機が各サービスに対してＳＬＳを発見できるようにするブートストラップ情報を提供する。ＲＯＵＴＥ／ＤＡＳＨで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＬＣＴセッションの目的地ＩＰ住所及び目的地ポートを含む。ＭＭＴ／ＭＰＵで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＭＭＴＰセッションの目的地ＩＰ住所及び目的地ポートを含む。
【００６４】
ＳＬＴは、ブロードキャストストリームで各サービスに関する次の情報を含むことによって、サービス取得及び速いチャネルスキャンを支援する。第一に、ＳＬＴは、視聴者にとって有意義であり、上／下の選択又はチャネル番号を介した初期サービス選択を支援できるサービスリストのプレゼンテーションを許容するのに必要な情報を含むことができる。第二に、ＳＬＴは、各リストされたサービスに対してＳＬＳの位置を見つけるのに必要な情報を含むことができる。すなわち、ＳＬＴは、ＳＬＳを伝達する位置（ｌｏｃａｔｉｏｎ）に対するアクセス情報を含むことができる。
【００６５】
図示された本発明の一実施例に係るＳＬＴは、ＳＬＴルートエレメント（ｒｏｏｔ  ｅｌｅｍｅｎｔ）を有するＸＭＬドキュメントの形態で表現された。実施例によって、ＳＬＴは、バイナリフォーマット又はＸＭＬドキュメントの形態で表現することができる。
【００６６】
図示されたＳＬＴのＳＬＴルートエレメントは、＠ｂｓｉｄ、＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ、＠ｌａｎｇｕａｇｅ、＠ｃａｐａｂｉｌｉｔｉｅｓ、ＩｎｅｔＳｉｇＬｏｃ及び／又はＳｅｒｖｉｃｅを含むことができる。実施例によって、ＳＬＴルートエレメントは、＠ｐｒｏｖｉｄｅｒＩｄをさらに含むこともできる。実施例によって、ＳＬＴルートエレメントは、＠ｌａｎｇｕａｇｅを含まなくてもよい。
【００６７】
Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ、＠ｐｒｏｔｅｃｔｅｄ、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ、＠ｈｉｄｄｅｎ、＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅ、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ、＠ｓｌｓＰｌｐＩｄ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ、＠ｃａｐａｂｉｌｉｔｉｅｓ及び／又はＩｎｅｔＳｉｇＬｏｃを含むことができる。
【００６８】
実施例によって、ＳＬＴの属性又はエレメントは追加／変更／削除されてもよい。ＳＬＴに含まれる各エレメントも、追加的に別途の属性又はエレメントを有することができ、本実施例に係る属性又はエレメントの一部が省略されてもよい。ここで、＠表記されたフィールドは属性（ａｔｔｒｉｂｕｔｅ）に該当し、＠表記されていないフィールドはエレメント（ｅｌｅｍｅｎｔ）に該当し得る。
【００６９】
＠ｂｓｉｄは、全ブロードキャストストリームの識別子である。ＢＳＩＤの値は、地域的レベルで唯一であり得る。
【００７０】
＠ｐｒｏｖｉｄｅｒＩｄは、このブロードキャストストリームの一部又は全体を使用する放送会社のインデックスである。これは選択的な属性である。それが存在しないということは、このブロードキャストストリームが一つの放送会社によって使用されていることを意味する。＠ｐｒｏｖｉｄｅｒＩｄは図示していない。
【００７１】
＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ＳＬＴセクションのバージョン番号であり得る。ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ｓｌｔ内で伝達される情報に変化が生じると１ずつ増分し得る。それが最大値に到達すると、０にシフトされる。
【００７２】
＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒは、ＳＬＴの当該セクションの番号であって、１からカウントすることができる。すなわち、当該ＳＬＴセクションのセクション番号に該当し得る。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
【００７３】
＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは、当該セクションが一部であるＳＬＴのセクション（即ち、最大のｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒを有するセクション）の総番号であり得る。ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒとｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは共にフラグメントで伝送される場合、ＳＬＴの一部の「ＮのＭ部分」を示すと見ることができる。すなわち、ＳＬＴを伝送するにおいて、分割（ｆｒａｇｍｅｎｔａｔｉｏｎ）を通じた伝送を支援できる。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。フィールドが使用されない場合は、ＳＬＴが分割されて伝送されない場合であり得る。
【００７４】
＠ｌａｎｇｕａｇｅは、当該ｓｌｔの場合に含まれるサービスの主言語を示すことができる。実施例によって、このフィールド値は、ＩＳＯで定義される３−キャラクタ言語コード（ｔｈｒｅｅ  ｃｈａｒａｃｔｅｒ  ｌａｎｇｕａｇｅ  ｃｏｄｅ）の形態であってもよい。本フィールドは省略されてもよい。
【００７５】
＠ｃａｐａｂｉｌｉｔｉｅｓは、当該ｓｌｔの場合において全てのサービスに対する内容をデコードし、有意義に示すために要求される能力を示すことができる。
【００７６】
ＩｎｅｔＳｉｇＬｏｃは、どこでブロードバンドを介して外部サーバーから全ての要求されるタイプのデータを取得できるかを受信機に知らせるＵＲＬを提供することができる。このエレメントは、＠ｕｒｌＴｙｐｅを下位フィールドとしてさらに含むこともできる。この＠ｕｒｌＴｙｐｅフィールドの値に応じて、ＩｎｅｔＳｉｇＬｏｃが提供するＵＲＬのタイプを指示することができる。実施例によって、＠ｕｒｌＴｙｐｅフィールド値が０である場合、ＩｎｅｔＳｉｇＬｏｃはシグナリングサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールド値が１である場合、ＩｎｅｔＳｉｇＬｏｃはＥＳＧサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールドが、それ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【００７７】
Ｓｅｒｖｉｃｅフィールドは、各サービスに関する情報を有するエレメントであって、サービスエントリに該当し得る。ＳＬＴが指示するサービスの数（Ｎ）だけＳｅｒｖｉｃｅエレメントフィールドが存在し得る。以下、Ｓｅｒｖｉｃｅフィールドの下位属性／エレメントについて説明する。
【００７８】
＠ｓｅｒｖｉｃｅＩｄは、当該ブロードキャスト領域の範囲内で当該サービスを唯一に識別する整数であり得る。実施例によって、＠ｓｅｒｖｉｃｅＩｄのスコープ（ｓｃｏｐｅ）は変更されてもよい。＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは、前記ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤを有するＳＬＴサービス情報のシーケンス番号を示す整数であり得る。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ値は、各サービスに対して０から始まることができ、当該Ｓｅｒｖｉｃｅエレメントにおいてある属性が変化するたびに１ずつ増分することができる。ＳｅｒｖｉｃｅＩＤの特定の値を有する以前のサービスエレメントに比べていかなる属性値も変化しない場合、ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは増分しないはずである。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒフィールドは、最大値に到達した後、０にシフトされる。
【００７９】
＠ｐｒｏｔｅｃｔｅｄは、フラグ情報であって、当該サービスの有意義な再生のための１つ又はそれ以上のコンポーネントが保護された（ｐｒｏｔｅｃｔｅｄ）状態であるかを示すことができる。「１」（真）に設定されると、有意義なプレゼンテーションに必要な１つ以上のコンポーネントが保護される。「０」（偽）に設定されると、当該フラグは、サービスの有意義なプレゼンテーションに必要なコンポーネントが何にも保護されないことを示す。デフォルト値は偽である。
【００８０】
＠ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの「主」チャネル番号を示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。
【００８１】
＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの「副」チャネル番号を示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。
【００８２】
＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙは、当該サービスのカテゴリを示すことができる。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２、３である場合、それぞれ当該サービスは、リニアＡ／Ｖサービス（Ｌｉｎｅａｒ  Ａ／Ｖ  ｓｅｒｖｉｃｅ）、リニアオーディオサービス（Ｌｉｎｅａｒ  ａｕｄｉｏ  ｏｎｌｙ  ｓｅｒｖｉｃｅ）、アプリベースのサービス（ａｐｐ−ｂａｓｅｄ  ｓｅｒｖｉｃｅ）に該当し得る。本フィールドの値が０である場合、定義されていないカテゴリのサービスであり得、本フィールドの値が０、１、２、３以外の他の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅは、サービスのショートストリングネームであり得る。
【００８３】
＠ｈｉｄｄｅｎは、存在し、「真」に設定される場合、ブール値であり得、これは、サービスがテストや独占使用のためのものであり、通常のＴＶ受信機によっては選択されないことを示す。存在しない場合、デフォルト値は「偽」である。
【００８４】
＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅは、当該サービスによって使用されるＳＬＳのプロトコルのタイプを示す属性であり得る。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２である場合、それぞれ、当該サービスが使用するＳＬＳのプロトコルはＲＯＵＴＥ、ＭＭＴＰであり得る。本フィールドの値が０又はそれ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。本フィールドは、＠ｓｌｓＰｒｏｔｏｃｏｌと呼ぶこともできる。
【００８５】
ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ及びその下位属性／エレメントは、放送シグナリングと関連する情報を提供することができる。ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、ペアレントサービスエレメントのチャイルドエレメントであるＩｎｅｔＳｉｇＬｏｃが存在し得、その属性であるｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ  ０ｘ００（ＵＲＬ  ｔｏ  ｓｉｇｎａｌｉｎｇ  ｓｅｒｖｅｒ）を含む。この場合、属性であるｕｒｌは、ｓｅｒｖｉｃｅ＿ｉｄがペアレントサービスエレメントに対するｓｅｒｖｉｃｅｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ＿ｉｄ＞を支援する。
【００８６】
又は、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、エレメントＩｎｅｔＳｉｇＬｏｃはｓｌｔルートエレメントのチャイルドエレメントとして存在し得、ＩｎｅｔＳｉｇＬｏｃエレメントの属性ｕｒｌＴｙｐｅはＵＲＬ＿ｔｙｐｅ  ０ｘ００（ＵＲＬ  ｔｏ  ｓｉｇｎａｌｉｎｇ  ｓｅｒｖｅｒ）を含む。この場合、ＵＲＬ＿ｔｙｐｅ  ０ｘ００に対する属性ｕｒｌは、ｓｅｒｖｉｃｅ＿ｉｄがペアレントサービスエレメントのｓｅｒｖｉｃｅＩｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ＿ｉｄ＞を支援する。
【００８７】
＠ｓｌｓＰｌｐＩｄは、当該サービスに対してＳＬＳを伝達するＰＬＰのＰＬＰ  ＩＤを示す整数を表現するストリングであり得る。
【００８８】
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４目的地住所を含むストリングであり得る。
【００８９】
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対してＳＬＳデータを伝達するパケットのポート番号を含むストリングであり得る。前述したように、目的地ＩＰ／ＵＤＰ情報によってＳＬＳブートストラッピングを行うことができる。
【００９０】
＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソース住所を含むストリングであり得る。
【００９１】
＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの主バージョン番号であり得る。デフォルト値は１である。
【００９２】
＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの副バージョン番号であり得る。デフォルト値は０である。
【００９３】
＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの主言語を示す３文字言語コードであり得る。本フィールド値の形式は、実施例によって変更されてもよい。
【００９４】
＠ｂｒｏａｄｂａｎｄａｃｃｅｓｓＲｅｑｕｉｒｅｄは、受信機がサービスの有意義なプレゼンテーションを行うためにブロードバンドアクセスが必要であることを示すブール値であり得る。本フィールドの値がＴｒｕｅである場合、受信機は、有意義なサービス再生のためにブロードバンドにアクセスしなければならず、これは、サービスのハイブリッドデリバリのケースに該当し得る。
【００９５】
＠ｃａｐａｂｉｌｉｔｉｅｓは、前記ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤであって、サービスに対する内容をデコードし、有意義に示すために要求される能力を示すことができる。
【００９６】
ＩｎｅｔＳｉｇＬｏｃは、使用可能な場合、ブロードバンドを介してシグナリングや公知の情報に接続するためのＵＲＬを提供することができる。そのデータタイプは、ＵＲＬがどこにアクセスするかを示す＠ｕｒｌＴｙｐｅ属性を追加する全てのＵＲＬデータタイプの拡張であり得る。本フィールドの＠ｕｒｌＴｙｐｅフィールドが意味することは、前述したＩｎｅｔＳｉｇＬｏｃの＠ｕｒｌＴｙｐｅフィールドが意味することと同一であり得る。属性ＵＲＬ＿ｔｙｐｅ  ０ｘ００のＩｎｅｔＳｉｇＬｏｃエレメントがＳＬＴのエレメントとして存在する場合、それは、シグナリングメタデータに対してＨＴＴＰ要求を行うために使用され得る。このＨＴＴＰ  ＰＯＳＴメッセージボディーにはサービスタームが含まれてもよい。ＩｎｅｔＳｉｇＬｏｃエレメントがセクションレベルで現れる場合、サービスタームは、要求されたシグナリングメタデータオブジェクトが適用されるサービスを示すために使用される。サービスタームが存在しない場合、当該セクションの全てのサービスに対するシグナリングメタデータオブジェクトが要求される。ＩｎｅｔＳｉｇＬｏｃがサービスレベルで現れる場合、所望のサービスを指定するために必要なサービスタームがない。属性ＵＲＬ＿ｔｙｐｅ  ０ｘ０１のＩｎｅｔＳｉｇＬｏｃエレメントが提供されると、それは、ブロードバンドを介してＥＳＧデータを検索するのに使用することができる。当該エレメントがサービスエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該サービスに対してデータを検索するのに使用することができる。当該エレメントがＳＬＴエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該セクションで全てのサービスに対するＥＳＧデータを検索するのに使用することができる。
【００９７】
ＳＬＴの他の実施例において、ＳＬＴの＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ及び／又は＠ｌａｎｇｕａｇｅフィールドは省略されてもよい。
【００９８】
また、前述したＩｎｅｔＳｉｇＬｏｃフィールドは、＠ｓｌｔＩｎｅｔＳｉｇＵｒｉ及び／又は＠ｓｌｔＩｎｅｔＥｓｇＵｒｉフィールドに代替されてもよい。２つのフィールドは、それぞれシグナリングサーバーのＵＲＩ、ＥＳＧサーバーのＵＲＩ情報を含むことができる。ＳＬＴの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールド及びＳｅｒｖｉｃｅの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールドは、いずれも、前記のような方法で代替されてもよい。
【００９９】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、１は、当該フィールドが必須のフィールドであり、０..１は、当該フィールドがオプショナルフィールドであることを意味し得る。
【０１００】
図４は、本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリ過程を示した図である。
【０１０１】
以下、サービス層シグナリング（ＳＬＳ、Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【０１０２】
ＳＬＳは、サービス及びそのコンテンツコンポーネントを発見し、取得するための情報を提供するシグナリングであり得る。
【０１０３】
ＲＯＵＴＥ／ＤＡＳＨについて、各サービスに対するＳＬＳは、コンポーネントのリスト、どこでそれらを取得できるのか、サービスの有意義なプレゼンテーションのために要求される受信機の能力のようなサービスの特性を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、ＳＬＳは、ＵＳＢＤ（ｕｓｅｒ  ｓｅｒｖｉｃｅ  ｂｕｎｄｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ、ＤＡＳＨ  ＭＰＤ（ｍｅｄｉａ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｓｃｒｉｐｔｉｏｎ）を含む。ここで、ＵＳＢＤ又はＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、ＳＬＳ  ＸＭＬフラグメントのうちの１つであって、サービスの具体的な技術的情報を記述するシグナリングハブとしての役割を果たすことができる。このＵＳＢＤ／ＵＳＤは、３ＧＰＰ  ＭＢＭＳで定義されたことよりもさらに拡張されてもよい。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。
【０１０４】
サービスシグナリングは、サービス自体の基本属性、特に、サービスを取得するために必要な属性に焦点を置く。視聴者のためのサービス及びプログラミングの特徴は、サービスの公知又はＥＳＧデータとして現れる。
【０１０５】
各サービスに対して別個のサービスシグナリングを有する場合、受信機は、ブロードキャストストリーム内で伝達される全ＳＬＳをパースすることなく所望のサービスに対する適切なＳＬＳを取得すればよい。
【０１０６】
サービスシグナリングの選択的なブロードバンドデリバリに対して、ＳＬＴは、前述したように、サービスシグナリングファイルが取得され得るＨＴＴＰ  ＵＲＬを含むことができる。
【０１０７】
ＬＬＳは、ＳＬＳ取得をブートストラップするのに使用され、その後、ＳＬＳは、ＲＯＵＴＥセッション又はＭＭＴＰセッションで伝達されるサービスコンポーネントを取得するのに使用される。記述された図面は、次のシグナリングシーケンスを示す。受信機は、前述したＳＬＴを取得し始める。ＲＯＵＴＥセッションで伝達されるｓｅｒｖｉｃｅ＿ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃１）、ソースＩＰ住所（ｓＩＰ１）、目的地ＩＰ住所（ｄＩＰ１）、及び目的地ポート番号（ｄＰｏｒｔ１）のようなＳＬＳブートストラッピング情報を提供する。ＭＭＴＰセッションで伝達されるｓｅｒｖｉｃｅ＿ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃２）、目的地ＩＰ住所（ｄＩＰ２）、及び目的地ポート番号（ｄＰｏｒｔ２）のようなＳＬＳブートストラッピング情報を提供する。
【０１０８】
ＲＯＵＴＥを用いたストリーミングサービスデリバリに対して、受信機は、ＰＬＰ及びＩＰ／ＵＤＰ／ＬＣＴセッションで伝達されるＳＬＳフラグメントを取得することができる。反面、ＭＭＴＰを用いたストリーミングサービスデリバリに対して、受信機は、ＰＬＰ及びＭＭＴＰセッションで伝達されるＳＬＳフラグメントを取得することができる。ＲＯＵＴＥを用いたサービスデリバリに対して、これらＳＬＳフラグメントは、ＵＳＢＤ／ＵＳＤフラグメント、Ｓ−ＴＳＩＤフラグメント、ＭＰＤフラグメントを含む。それらは一つのサービスと関連がある。ＵＳＢＤ／ＵＳＤフラグメントは、サービス層の特性を記述し、Ｓ−ＴＳＩＤフラグメントに対するＵＲＩリファレンス及びＭＰＤフラグメントに対するＵＲＩリファレンスを提供する。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれ参照することができる。ＭＭＴＰを用いたサービスデリバリに対して、ＵＳＢＤは、ＭＭＴシグナリングのＭＭＴメッセージを参照し、そのＭＰテーブルは、サービスに属するアセット（ａｓｓｅｔ）のための位置情報及びパッケージＩＤの識別を提供する。ここで、Ａｓｓｅｔとは、マルチメディアデータエンティティであって、一つのユニークなＩＤに連合され、一つのマルチメディアプレゼンテーションを生成するのに使用されるデータエンティティを意味し得る。Ａｓｓｅｔは、一つのサービスを構成するサービスコンポーネントに該当し得る。ＭＰＴメッセージは、ＭＭＴのＭＰテーブルを有するメッセージであり、ここで、ＭＰテーブルは、ＭＭＴ  Ａｓｓｅｔとコンテンツに関する情報を有する、ＭＭＴパッケージテーブル（ＭＭＴ  Ｐａｃｋａｇｅ  Ｔａｂｌｅ）であり得る。具体的な内容は、ＭＭＴで定義された通りである。ここで、メディアプレゼンテーションとは、メディアコンテンツのバウンド／アンバウンドされたプレゼンテーションを成立させるデータのコレクションであり得る。
【０１０９】
Ｓ−ＴＳＩＤフラグメントは、一つのサービスと関連するコンポーネント取得情報と、当該サービスのコンポーネントに該当するＴＳＩ及びＭＰＤで発見されるＤＡＳＨ表現との間のマッピングを提供する。Ｓ−ＴＳＩＤは、ＴＳＩ及び関連するＤＡＳＨ表現識別子の形態のコンポーネント取得情報、及びＤＡＳＨ表現と関連するＤＡＳＨセグメントを伝達するＰＬＰＩＤを提供することができる。ＰＬＰＩＤ及びＴＳＩ値によって、受信機は、サービスからオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディアセグメントのバッファリングを開始した後、適切なデコーディング過程を適用する。
【０１１０】
ＭＭＴＰセッションで伝達されるＵＳＢＤリスティングサービスコンポーネントに対して、記述された図面の「Ｓｅｒｖｉｃｅ＃２」に示したように、受信機は、ＳＬＳを完了するためにマッチされるＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄを有するＭＰＴメッセージを取得する。ＭＰＴメッセージは、各コンポーネントに対する取得情報及びサービスを含むサービスコンポーネントの完全なリストを提供する。コンポーネント取得情報は、ＭＭＴＰセッション情報、当該セッションを伝達するＰＬＰＩＤ、当該セッション内のｐａｃｋｅｔ＿ｉｄを含む。
【０１１１】
実施例によって、例えば、ＲＯＵＴＥの場合、２つ以上のＳ−ＴＳＩＤフラグメントが使用されてもよい。それぞれのフラグメントは、各サービスのコンテンツを伝達するＬＣＴセッションに対するアクセス情報を提供することができる。
【０１１２】
ＲＯＵＴＥの場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ、又はこれらを伝達するＬＣＴセッションをサービスシグナリングチャネルと呼ぶこともできる。ＭＭＴＰの場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、又はこれらを伝達するパケットフローをサービスシグナリングチャネルと呼ぶこともできる。
【０１１３】
図示された実施例とは異なり、一つのＲＯＵＴＥ又はＭＭＴＰセッションは複数個のＰＬＰを介して伝達され得る。すなわち、一つのサービスは一つ以上のＰＬＰを介して伝達されてもよい。前述したように、一つのＬＣＴセッションは一つのＰＬＰを介して伝達され得る。図示されたものとは異なり、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＲＯＵＴＥセッションを介して伝達されてもよい。また、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＭＭＴＰセッションを介して伝達されてもよい。実施例によって、一つのサービスを構成するコンポーネントが、ＲＯＵＴＥセッションとＭＭＴＰセッションとに分けられて伝達されてもよい。図示してはいないが、一つのサービスを構成するコンポーネントが、ブロードバンドを介して伝達（ハイブリッドデリバリ）される場合もあり得る。
【０１１４】
図５は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。
【０１１５】
以下、ＲＯＵＴＥに基づいたデリバリにおいて、サービス層シグナリングについて説明する。
【０１１６】
ＳＬＳは、サービス及びそのコンテンツコンポーネントの発見及び接近を可能にするために、受信機に、具体的な技術的な情報を提供する。それは、専用ＬＣＴセッションで伝達されるＸＭＬコードされたメタデータフラグメントの集合を含むことができる。当該ＬＣＴセッションは、前述したように、ＳＬＴに含まれたブートストラップ情報を用いて取得することができる。ＳＬＳは、サービスレベル毎に定義され、それは、コンテンツコンポーネントのリスト、どのようにそれらを取得するのか、サービスの有意義なプレゼンテーションを行うために要求される受信機の能力のようなサービスのアクセス情報及び特徴を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、リニアサービスデリバリのために、ＳＬＳは、ＵＳＢＤ、Ｓ−ＴＳＩＤ及びＤＡＳＨ  ＭＰＤのようなメタデータフラグメントで構成される。ＳＬＳフラグメントは、ＴＳＩ＝０である専用のＬＣＴ伝送セッションで伝達され得る。実施例によって、ＳＬＳフラグメントが伝達される特定のＬＣＴセッション（ｄｅｄｉｃａｔｅｄ  ＬＣＴ  ｓｅｓｓｉｏｎ）のＴＳＩは、異なる値を有してもよい。実施例によって、ＳＬＳフラグメントが伝達されるＬＣＴセッションが、ＳＬＴ又は他の方法によってシグナルされてもよい。
【０１１７】
ＲＯＵＴＥ／ＤＡＳＨ  ＳＬＳは、ＵＳＢＤ及びＳ−ＴＳＩＤメタデータフラグメントを含むことができる。これらのサービスシグナリングフラグメントは、リニア及びアプリケーションに基づいたサービスに適用され得る。ＵＳＢＤフラグメントは、サービス識別、装置能力情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳフラグメントに対するリファレンス、受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＳ−ＴＳＩＤフラグメントは、サービスのメディアコンテンツコンポーネントが伝達される１つ以上のＲＯＵＴＥ／ＬＣＴセッションに対する伝送セッション記述、及び当該ＬＣＴセッションで伝達されるデリバリオブジェクトの記述を提供する。ＵＳＢＤ及びＳ−ＴＳＩＤは後述する。
【０１１８】
ＲＯＵＴＥに基づいたデリバリにおけるストリーミングコンテンツシグナリング（Ｓｔｒｅａｍｉｎｇ  Ｃｏｎｔｅｎｔ  Ｓｉｇｎａｌｉｎｇ）において、ＳＬＳのストリーミングコンテンツシグナリングコンポーネントはＭＰＤフラグメントに該当する。ＭＰＤは、主にストリーミングコンテンツとしてのＤＡＳＨセグメントのデリバリのためのリニアサービスと関連する。ＭＰＤは、セグメントＵＲＬの形態のリニア／ストリーミングサービスの個別メディアコンポーネントに対するソース識別子、及びメディアプレゼンテーション内の識別されたリソースのコンテキストを提供する。ＭＰＤについての具体的な内容は後述する。
【０１１９】
ＲＯＵＴＥに基づいたデリバリにおけるアプリベースのエンハンスメントシグナリングにおいて、アプリベースのエンハンスメントシグナリングは、アプリケーションロジックファイル、局部的にキャッシュされたメディアファイル、ネットワークコンテンツアイテム、又は公知のストリームのようなアプリベースのエンハンスメントコンポーネントのデリバリに属する。アプリケーションはまた、可能な場合、ブロードバンドコネクション上で局部的にキャッシュされたデータを検索することができる。
【０１２０】
以下、本図に示されたＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
【０１２１】
トップレベル又はエントリポイントＳＬＳフラグメントはＵＳＢＤフラグメントである。図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
【０１２２】
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、一つのサービスに対するインスタンスであり得る。
【０１２３】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓ、＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉ、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄを含むことができる。
【０１２４】
＠ｓｅｒｖｉｃｅＩｄは、ＢＳＩＤの範囲内で唯一のサービスを識別する全世界的に唯一のＵＲＩであり得る。当該パラメータは、ＥＳＧデータ（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）とリンクするのに使用することができる。
【０１２５】
＠ａｔｓｃ：ｓｅｒｖｉｃｅｄは、ＬＬＳ（ＳＬＴ）において該当するサービスエントリに対するリファレンスである。当該属性の値は、当該エントリに割り当てられたｓｅｒｖｉｃｅＩｄの値と同一である。
【０１２６】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓは、当該サービスの状態を特定することができる。その値は、当該サービスが活性化されているか、又は非活性化されているかを示す。「１」（真）に設定されると、サービスが活性化されていることを示す。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。
【０１２７】
＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉは、ブロードキャスト上で選択的に、また、ブロードバンド上で伝達されるサービスのコンテンツコンポーネントに対する記述を含むＭＰＤフラグメントを参照することができる。
【０１２８】
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤフラグメントを参照することができる。
【０１２９】
ｎａｍｅは、ｌａｎｇ属性によって与えられるサービスのネームを示すことができる。ｎａｍｅエレメントは、サービスネームの言語を示すｌａｎｇ属性を含むことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
【０１３０】
ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの利用可能な言語を示すことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。
【０１３１】
ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、受信機が当該サービスのコンテンツの有意義なプレゼンテーションを生成できるように要求される能力を特定することができる。実施例によって、本フィールドは、予め定義された能力グループを特定してもよい。ここで、能力グループは、有意義なプレゼンテーションのための能力属性値のグループであり得る。本フィールドは、実施例によって省略されてもよい。
【０１３２】
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄは、アクセスのブロードキャスト及び（選択的に）ブロードバンドモード上でサービスのコンテンツに属する情報に関連するトランスポートのコンテナであり得る。当該サービスに含まれるデータにおいて、そのデータをＮ個とすれば、そのそれぞれのデータに対するデリバリ方法が、このエレメントによって記述され得る。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及びｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。それぞれの下位エレメントは、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。
【０１３３】
ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する当該メディアコンポーネントを含む、多重化又は非多重化された形態のブロードキャスト上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、放送網を介して伝達されるＤＡＳＨリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
【０１３４】
ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する構成メディアコンテンツコンポーネントを含む、多重化又は非多重化された形態のブロードバンド上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、ブロードバンドを介して伝達されるＤＡＳＨリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。
【０１３５】
ｂａｓｅＰａｔｔｅｒｎは、含まれた期間にペアレントリプレゼンテーションのメディアセグメントを要求するためにＤＡＳＨクライアントによって使用されるセグメントＵＲＬの全ての部分に対してマッチされるように受信機によって使用される文字パターンであり得る。マッチは、当該要求されたメディアセグメントがブロードキャストトランスポート上で伝達されることを暗示する。それぞれのｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントとｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで表現されるＤＡＳＨリプレゼンテーションを受信できるＵＲＬ住所において、そのＵＲＬの一部分などは特定のパターンを有することができ、そのパターンが本フィールドによって記述され得る。この情報を通じて、一定の部分のデータに対する区分が可能である。提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０１３６】
図６は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。
【０１３７】
以下、本図に示されたＳ−ＴＳＩＤの具体的な内容について説明する。
【０１３８】
Ｓ−ＴＳＩＤは、サービスのコンテンツコンポーネントを伝達する伝送セッションに対する全体的なセッション記述情報を提供するＳＬＳ  ＸＭＬフラグメントであり得る。Ｓ−ＴＳＩＤは、サービスのメディアコンテンツコンポーネントが伝達される構成ＬＣＴセッション、及び０個以上のＲＯＵＴＥセッションに対する全体的な伝送セッション記述情報を含む、ＳＬＳメタデータフラグメントである。Ｓ−ＴＳＩＤはまた、ＬＣＴセッションで伝達されるコンテンツコンポーネント及びペイロードフォーマットに対する追加情報だけでなく、サービスのＬＣＴセッションで伝達されるデリバリオブジェクト又はオブジェクトフローに対するファイルメタデータを含む。
【０１３９】
Ｓ−ＴＳＩＤフラグメントの各インスタンスは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントの＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ属性によってＵＳＢＤフラグメントで参照される。図示された本発明の一実施例に係るＳ−ＴＳＩＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、Ｓ−ＴＳＩＤは、バイナリフォーマット又はＸＭＬドキュメントの形態で表現されてもよい。
【０１４０】
図示されたＳ−ＴＳＩＤは、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ及び／又はＲＳを含むことができる。
【０１４１】
＠ｓｅｒｖｉｃｅＩＤは、ＵＳＤでサービスエレメントに該当するリファレンスであり得る。当該属性の値は、ｓｅｒｖｉｃｅ＿ｉｄの当該値を有するサービスを参照することができる。
【０１４２】
ＲＳエレメントは、当該サービスデータを伝達するＲＯＵＴＥセッションに関する情報を有することができる。複数個のＲＯＵＴＥセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは１個〜Ｎ個の個数を有することができる。
【０１４３】
ＲＳエレメントは、＠ｂｓｉｄ、＠ｓＩｐＡｄｄｒ、＠ｄＩｐＡｄｄｒ、＠ｄｐｏｒｔ、＠ＰＬＰＩＤ及び／又はＬＳを含むことができる。
【０１４４】
＠ｂｓｉｄは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのコンテンツコンポーネントが伝達されるブロードキャストストリームの識別子であり得る。当該属性が存在しない場合、デフォルトブロードキャストストリームのＰＬＰが当該サービスに対するＳＬＳフラグメントを伝達することであり得る。その値は、ＳＬＴでｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄと同一であり得る。
【０１４５】
＠ｓＩｐＡｄｄｒは、ソースＩＰ住所を示すことができる。ここで、ソースＩＰ住所は、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのソースＩＰ住所であり得る。前述したように、一つのサービスのサービスコンポーネントは、複数個のＲＯＵＴＥセッションを介して伝達されてもよい。そのため、当該Ｓ−ＴＳＩＤが伝達されるＲＯＵＴＥセッションではない他のＲＯＵＴＥセッションでそのサービスコンポーネントが伝送されてもよい。したがって、ＲＯＵＴＥセッションのソースＩＰ住所を指示するために本フィールドが使用され得る。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのソースＩＰ住所であり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのソースＩＰ住所値であり得る。この場合、本フィールドはＭ、すなわち、必須のフィールドであり得る。
【０１４６】
＠ｄＩｐＡｄｄｒは、目的地ＩＰ住所を示すことができる。ここで、目的地ＩＰ住所は、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ＩＰ住所であり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ＩＰ住所を指示してもよい。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションの目的地ＩＰ住所であり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションの目的地ＩＰ住所値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。
【０１４７】
＠ｄｐｏｒｔは、目的地ポートを示すことができる。ここで、目的地ポートは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ポートであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ポートを指示することができる。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションの目的地ポート番号であり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションの目的地ポート番号値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。
【０１４８】
＠ＰＬＰＩＤは、ＲＳで表現されるＲＯＵＴＥセッションのためのＰＬＰのＩＤであり得る。デフォルト値は、現在のＳ−ＴＳＩＤが含まれたＬＣＴセッションのＰＬＰのＩＤであり得る。実施例によって、本フィールドは、当該ＲＯＵＴＥセッションでＳ−ＴＳＩＤが伝達されるＬＣＴセッションのためのＰＬＰのＩＤ値を有してもよく、当該ＲＯＵＴＥセッションのための全てのＰＬＰのＩＤ値を有してもよい。
【０１４９】
ＬＳエレメントは、当該サービスデータを伝達するＬＣＴセッションに関する情報を有することができる。複数個のＬＣＴセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは、１個〜Ｎ個の個数を有することができる。
【０１５０】
ＬＳエレメントは、＠ｔｓｉ、＠ＰＬＰＩＤ、＠ｂｗ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅ、ＳｒｃＦｌｏｗ及び／又はＲｐｒＦｌｏｗを含むことができる。
【０１５１】
＠ｔｓｉは、当該サービスのサービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ値を指示することができる。
【０１５２】
＠ＰＬＰＩＤは、当該ＬＣＴセッションのためのＰＬＰのＩＤ情報を有することができる。この値は、基本ＲＯＵＴＥセッション値を上書きしてもよい。
【０１５３】
＠ｂｗは、最大の帯域値を指示することができる。＠ｓｔａｒｔＴｉｍｅは当該ＬＣＴセッションのスタートタイム（Ｓｔａｒｔ  ｔｉｍｅ）を指示することができる。＠ｅｎｄＴｉｍｅは、当該ＬＣＴセッションのエンドタイム（Ｅｎｄ  ｔｉｍｅ）を指示することができる。ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローに対して記述することができる。ＲｐｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアフローに対して記述することができる。
【０１５４】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須フィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０１５５】
以下、ＲＯＵＴＥ／ＤＡＳＨのためのＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
【０１５６】
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＤＡＳＨメディアプレゼンテーションの公式化された記述を含むＳＬＳメタデータフラグメントである（例えば、ある期間の間の一つのＴＶプログラム又は連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、メディアプレゼンテーション内で識別されたリソースに対するコンテキスト及びセグメントに対するソース識別子を提供する。ＭＰＤフラグメントのデータ構造及びセマンティクスは、ＭＰＥＧ  ＤＡＳＨによって定義されたＭＰＤに従うことができる。
【０１５７】
ＭＰＤで伝達される１つ以上のＤＡＳＨリプレゼンテーションは、ブロードキャスト上で伝達され得る。ＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達される追加リプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、トンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
【０１５８】
図７は、本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。
【０１５９】
リニアサービスのためのＭＭＴ  ＳＬＳは、ＵＳＢＤフラグメント及びＭＰテーブルを含む。ＭＰテーブルは、前述した通りである。ＵＳＢＤフラグメントは、サービス識別、装置能力情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ情報に対するリファレンス、及び受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＭＰＵコンポーネントに対するＭＰテーブルは、サービスのメディアコンテンツコンポーネントが伝達されるＭＭＴＰセッションに対する伝送セッション記述、及びＭＭＴＰセッションで伝達されるアセットの記述を提供する。
【０１６０】
ＭＰＵコンポーネントに対するＳＬＳのストリーミングコンテンツシグナリングコンポーネントは、ＭＭＴで定義されたＭＰテーブルに該当する。ＭＰテーブルは、各アセットが単一のサービスコンポーネントに該当するＭＭＴアセットのリスト、及び当該コンポーネントに対する位置情報の記述を提供する。
【０１６１】
ＵＳＢＤフラグメントは、ＲＯＵＴＥプロトコル及びブロードバンドによってそれぞれ伝達されるサービスコンポーネントに対して、前述したようなＳ−ＴＳＩＤ及びＭＰＤに対するリファレンスも含むことができる。実施例によって、ＭＭＴを通じたデリバリにおいて、ＲＯＵＴＥプロトコルを介して伝達されるサービスコンポーネントはＮＲＴなどのデータであるので、この場合において、ＭＰＤは用いられなくてもよい。また、ＭＭＴを通じたデリバリにおいて、ブロードバンドを介して伝達されるサービスコンポーネントはどのＬＣＴセッションを介して伝達されるかに対する情報が必要でないので、Ｓ−ＴＳＩＤは用いられなくてもよい。ここで、ＭＭＴパッケージは、ＭＭＴを用いて伝達される、メディアデータの論理的コレクションであり得る。ここで、ＭＭＴＰパケットは、ＭＭＴを用いて伝達されるメディアデータのフォーマットされたユニットを意味し得る。ＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）は、独立してデコーディング可能なタイムド／ノン−タイムドデータのジェネリックコンテナを意味し得る。ここで、ＭＰＵでのデータはメディアコーデックアグノスティックである。
【０１６２】
以下、本図に示されたＵＳＢＤ／ＵＳＤの具体的な内容について説明する。
【０１６３】
図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。
【０１６４】
図示された本発明の一実施例に係るＵＳＢＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、ＵＳＢＤは、バイナリフォーマット又はＸＭＬドキュメントの形態で表現されてもよい。
【０１６５】
図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであり得る。
【０１６６】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ、ａｔｓｃ：Ｃｈａｎｎｅｌ、ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔ及び／又はａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏを含むことができる。
【０１６７】
ここで、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、前述したものと同一であり得る。ｎａｍｅフィールドの下のｌａｎｇフィールドも、前述したものと同一であり得る。ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、実施例によって省略されてもよい。
【０１６８】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、実施例によってａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントをさらに含むことができる。このエレメントはオプショナルエレメントであり得る。ａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇは、コンテンツ諮問順位を特定することができる。本フィールドは図示していない。
【０１６９】
ａｔｓｃ：Ｃｈａｎｎｅｌは、サービスのチャネルに対する情報を有することができる。ａｔｓｃ：Ｃｈａｎｎｅｌエレメントは、＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎ及び／又はａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎを含むことができる。＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、実施例によって省略されてもよい。
【０１７０】
＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの主チャネル番号を示す属性である。
【０１７１】
＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの副チャネル番号を示す属性である。
【０１７２】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、サービスで使用される主要言語を示す属性である。
【０１７３】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅは、サービスの主要ジャンルを示す属性である。
【０１７４】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎは、当該サービスを表現するために使用されるアイコンに対するＵＲＬを示す属性である。
【０１７５】
ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、サービス記述を含み、これは多重言語であってもよい。ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ及び／又は＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇを含むことができる。
【０１７６】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔは、サービスの記述を示す属性である。
【０１７７】
＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇは、前記ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性の言語を示す属性である。
【０１７８】
ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、ＭＰＵの形態で伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄ及び／又は＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄを含むことができる。
【０１７９】
＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに対するＭＭＴパッケージを参照することができる。
【０１８０】
＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに合わせて＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄによって参照された後に使用されるＭＭＴパッケージを参照することができる。
【０１８１】
ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、ＲＯＵＴＥを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、＠ｓＴＳＩＤＰｌｐＩｄ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを含むことができる。
【０１８２】
＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤフラグメントを参照することができる。このフィールドは、前述したＲＯＵＴＥのためのＵＳＢＤでのＳ−ＴＳＩＤを参照するためのＵＲＩと同一であり得る。前述したように、ＭＭＴＰによるサービスデリバリにおいても、ＮＲＴなどを介して伝達されるサービスコンポーネントはＲＯＵＴＥによって伝達され得る。そのためのＳ−ＴＳＩＤを参照するために、本フィールドが使用され得る。
【０１８３】
＠ｓＴＳＩＤＰｌｐＩｄは、当該サービスに対するＳ−ＴＳＩＤを伝達するＰＬＰのＰＬＰ  ＩＤを示す整数を表現するストリングであり得る。（デフォルト：現在のＰＬＰ）
【０１８４】
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４目的地住所を含むストリングであり得る。（デフォルト：現在のＭＭＴＰセッションのソースＩＰ住所）
【０１８５】
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのポート番号を含むストリングであり得る。
【０１８６】
＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソース住所を含むストリングであり得る。
【０１８７】
＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの主バージョン番号を示すことができる。デフォルト値は１である。
【０１８８】
＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの副バージョン番号を示すことができる。デフォルト値は０である。
【０１８９】
ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、ブロードバンドを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。すなわち、ハイブリッドデリバリを想定したフィールドであり得る。ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉをさらに含むことができる。
【０１９０】
＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉは、ブロードバンドで伝達されるサービスのコンテンツコンポーネントに対する記述を含むＭＰＤフラグメントに対するリファレンスであり得る。
【０１９１】
ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、サービスのアベイラブルな（ａｖａｉｌａｂｌｅ）コンポーネントに対する情報を有することができる。それぞれのコンポーネントに対する、タイプ、ロール、名などの情報を有することができる。各コンポーネント（Ｎ個）の数だけ本フィールドが存在することができる。ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄ及び／又は＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅを含むことができる。
【０１９２】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅは、当該コンポーネントのタイプを示す属性である。０の値はオーディオコンポーネントを示す。１の値はビデオコンポーネントを示す。２の値はクローズドキャプションコンポーネントを示す。３の値はアプリケーションコンポーネントを示す。４〜７の値は残す。本フィールド値の意味は、実施例によって異なって設定されてもよい。
【０１９３】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅは、当該コンポーネントの役割及び種類を示す属性である。
【０１９４】
オーディオに対して（前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が０と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｃｏｍｐｌｅｔｅ  ｍａｉｎ、１＝音楽及び効果（Ｍｕｓｉｃ  ａｎｄ  Ｅｆｆｅｃｔｓ）、２＝対話（Ｄｉａｌｏｇ）、３＝解説（Ｃｏｍｍｅｎｔａｒｙ）、４＝視覚障害（Ｖｉｓｕａｌｌｙ  Ｉｍｐａｉｒｅｄ）、５＝聴覚障害（Ｈｅａｒｉｎｇ  Ｉｍｐａｉｒｅｄ）、６＝ボイスオーバー（Ｖｏｉｃｅ−Ｏｖｅｒ）、７−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝未知（ｕｎｋｎｏｗｎ）。
【０１９５】
オーディオに対して（前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が１と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝プライマリビデオ（Ｐｒｉｍａｒｙ  ｖｉｄｅｏ）、１＝代替カメラビュー（Ａｌｔｅｒｎａｔｉｖｅ  ｃａｍｅｒａ  ｖｉｅｗ）、２＝他の代替ビデオコンポーネント（Ｏｔｈｅｒ  ａｌｔｅｒｎａｔｉｖｅ  ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）、３＝手話挿入（Ｓｉｇｎ  ｌａｎｇｕａｇｅ  ｉｎｓｅｔ）、４＝フォローサブジェクトビデオ（Ｆｏｌｌｏｗ  ｓｕｂｊｅｃｔ  ｖｉｄｅｏ）、５＝３Ｄビデオの左側ビュー（３Ｄ  ｖｉｄｅｏ  ｌｅｆｔ  ｖｉｅｗ）、６＝３Ｄビデオの右側ビュー（３Ｄ  ｖｉｄｅｏ  ｒｉｇｈｔ  ｖｉｅｗ）、７＝３Ｄビデオの深さ情報（３Ｄ  ｖｉｄｅｏ  ｄｅｐｔｈ  ｉｎｆｏｒｍａｔｉｏｎ）、８＝ビデオアレイの部分（Ｐａｒｔ ｏｆ ｖｉｄｅｏ ａｒｒａｙ） ＜ｘ，ｙ＞ ｏｆ ＜ｎ，ｍ＞、９＝フォローサブジェクトメタデータ（Ｆｏｌｌｏｗ−Ｓｕｂｊｅｃｔ  ｍｅｔａｄａｔａ）、１０−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１９６】
クローズドキャプションコンポーネントに対して（前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が２と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝正常（Ｎｏｒｍａｌ）、１＝イージーリーダー（Ｅａｓｙ  ｒｅａｄｅｒ）、２−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。
【０１９７】
前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性の値が３と７との間であれば、ｃｏｍｐｏｎｅｎｔＲｏｌｅ２５５と同一であり得る。本フィールド値の意味は、実施例によって異なって設定されてもよい。
【０１９８】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇは、当該コンポーネントが保護されるか（例えば、暗号化されるか）を示す属性である。当該フラグが１の値に設定されると、当該コンポーネントは保護される（例えば、暗号化される）。当該フラグが０の値に設定されると、当該コンポーネントは保護されない（例えば、暗号化されない）。存在しない場合、ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性の値は０と同一であると推論される。本フィールド値の意味は、実施例によって異なって設定されてもよい。
【０１９９】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄは、当該コンポーネントの識別子を示す属性である。当該属性の値は、当該コンポーネントに該当するＭＰテーブルにおいてａｓｓｅｔ＿ｉｄと同一であり得る。
【０２００】
＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅは、当該コンポーネントの人が読み取り可能な名を示す属性である。
【０２０１】
提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。
【０２０２】
以下、ＭＭＴのためのＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）について説明する。
【０２０３】
ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＳＬＳメタデータフラグメントである（例えば、一つのＴＶプログラム、又はある期間の間の連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、セグメントに対するリソース識別子、及びメディアプレゼンテーション内で識別されたリソースに対するコンテキストを提供する。ＭＰＤのデータ構造及びセマンティクスは、ＭＰＥＧ  ＤＡＳＨによって定義されたＭＰＤに従うことができる。
【０２０４】
本発明の実施例において、ＭＭＴＰセッションによって伝達されるＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達されるリプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、山の下やトンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。
【０２０５】
以下、ＭＭＴのためのＭＭＴシグナリングメッセージについて説明する。
【０２０６】
ＭＭＴＰセッションがストリーミングサービスを伝達するために使用される場合、ＭＭＴによって定義されたＭＭＴシグナリングメッセージは、ＭＭＴによって定義されたシグナリングメッセージモードに応じてＭＭＴＰパケットによって伝達される。アセットを伝達するＭＭＴＰパケットと同一のｐａｃｋｅｔ＿ｉｄ値に設定され得る、アセットに特定のＭＭＴシグナリングメッセージを伝達するＭＭＴＰパケットを除いて、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄフィールドの値は「００」に設定される。各サービスに対する適切なパケットを参照する識別子は、前述したように、ＵＳＢＤフラグメントによってシグナルされる。マッチするＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄを有するＭＰＴメッセージは、ＳＬＴでシグナルされるＭＭＴＰセッション上で伝達され得る。各ＭＭＴＰセッションは、そのセッションに特定のＭＭＴシグナリングメッセージ、又はＭＭＴＰセッションによって伝達される各アセットを伝達する。
【０２０７】
すなわち、ＳＬＴで特定のサービスに対するＳＬＳを有するパケットのＩＰ目的地住所／ポート番号などを特定して、ＭＭＴＰセッションのＵＳＢＤに接近することができる。前述したように、ＳＬＳを運搬するＭＭＴＰパケットのパケットＩＤは、００などの特定の値として指定できる。ＵＳＢＤの前述したパッケージＩＤ情報を用いて、マッチされるパッケージＩＤを有するＭＰＴメッセージに接近することができる。ＭＰＴメッセージは、後述するように、各サービスコンポーネント／アセットに接近するために使用することができる。
【０２０８】
次のＭＭＴＰメッセージは、ＳＬＴでシグナルされるＭＭＴＰセッションによって伝達され得る。
【０２０９】
ＭＰＴメッセージ：このメッセージは、全てのアセットのリスト及びＭＭＴによって定義されたようなそれらの位置情報を含む、ＭＰテーブルを伝達する。アセットがＭＰテーブルを伝達する現ＰＬＰと異なるＰＬＰによって伝達されると、当該アセットを伝達するＰＬＰの識別子は、ＰＬＰ識別子ディスクリプタを使用したＭＰテーブルで提供され得る。ＰＬＰ識別子ディスクリプタについては後述する。
【０２１０】
ＭＭＴ  ＡＴＳＣ３（ＭＡ３） ｍｅｓｓａｇｅ  ｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）：このメッセージは、前述したように、ＳＬＳを含むサービスに特定のシステムメタデータを伝達する。ｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）については後述する。
【０２１１】
次のＭＭＴＰメッセージは、必要であれば、ＳＬＴでシグナルされたＭＭＴＰセッションによって伝達されてもよい。
【０２１２】
ＭＰＩメッセージ：このメッセージは、プレゼンテーション情報の全てのドキュメント又は一部のドキュメントを含む、ＭＰＩテーブルを伝達する。ＭＰＩテーブルと関連するＭＰテーブルは、このメッセージによって伝達され得る。
【０２１３】
ＣＲＩ（ｃｌｏｃｋ  ｒｅｌａｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）メッセージ：このメッセージは、ＮＴＰタイムスタンプとＭＰＥＧ−２  ＳＴＣとの間のマッピングのためのクロック関連情報を含むＣＲＩテーブルを伝達する。実施例によって、ＣＲＩメッセージは当該ＭＭＴＰセッションを介して伝達されなくてもよい。
【０２１４】
次のＭＭＴＰメッセージは、ストリーミングコンテンツを伝達する各ＭＭＴＰセッションによって伝達され得る。
【０２１５】
仮想的な受信機バッファモデルメッセージ：このメッセージは、バッファを管理するために受信機によって要求される情報を伝達する。
【０２１６】
仮想的な受信機バッファモデル除去メッセージ：このメッセージは、ＭＭＴデカプセル化バッファを管理するために受信機によって要求される情報を伝達する。
【０２１７】
以下、ＭＭＴシグナリングメッセージのうち１つであるｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）について説明する。ＭＭＴシグナリングメッセージであるｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）は、前述した本発明によって、サービスに特定の情報を伝達するために定義される。本シグナリングメッセージは、ＭＭＴシグナリングメッセージの基本的なフィールドであるメッセージＩＤ、バージョン及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。本シグナリングメッセージのペイロードには、サービスＩＤ情報、コンテンツタイプ、コンテンツバージョン、コンテンツ圧縮情報及び／又はＵＲＩ情報が含まれてもよい。コンテンツタイプ情報は、本シグナリングメッセージのペイロードに含まれるデータのタイプを示すことができる。コンテンツバージョン情報は、ペイロードに含まれるデータのバージョンを、コンテンツ圧縮情報は、当該データに適用された圧縮タイプを示すことができる。ＵＲＩ情報は、本メッセージによって伝達されるコンテンツと関連するＵＲＩ情報を有することができる。
【０２１８】
以下、ＰＬＰ識別子ディスクリプタについて説明する。
【０２１９】
ＰＬＰ識別子ディスクリプタは、前述したＭＰテーブルのディスクリプタのうち１つとして使用できるディスクリプタである。ＰＬＰ識別子ディスクリプタは、アセットを伝達するＰＬＰに関する情報を提供する。アセットが、ＭＰテーブルを伝達する現在のＰＬＰと異なるＰＬＰによって伝達されると、ＰＬＰ識別子ディスクリプタは、そのアセットを伝達するＰＬＰを識別するために、関連するＭＰテーブルでアセットディスクリプタとして使用され得る。ＰＬＰ識別子ディスクリプタは、ＰＬＰ  ＩＤ情報以外にＢＳＩＤ情報をさらに含むこともできる。ＢＳＩＤは、このディスクリプタによって記述されるＡｓｓｅｔのためのＭＭＴＰパケットを伝達するブロードキャストストリームのＩＤであり得る。
【０２２０】
図８は、本発明の一実施例に係るリンク層プロトコルアーキテクチャを示した図である。
【０２２１】
以下、リンク層（Ｌｉｎｋ  Ｌａｙｅｒ）について説明する。
【０２２２】
リンク層は、物理層とネットワーク層との間の層であり、送信側では、ネットワーク層から物理層にデータを伝送し、受信側では、物理層からネットワーク層にデータを伝送する。リンク層の目的は、物理層による処理のために全ての入力パケットタイプを一つのフォーマットで要約すること、まだ定義されていない入力タイプに対する柔軟性、及び将来の拡張可能性を保障することである。また、リンク層内で処理すれば、例えば、入力パケットのヘッダーにある不必要な情報を圧縮するのにオプションを提供することによって、入力データを効率的に伝送できるように保障する。カプセル化、圧縮などの動作はリンク層プロトコルと呼ばれ、当該プロトコルを用いて生成されたパケットはリンク層パケットと呼ばれる。リンク層は、パケットカプセル化（ｐａｃｋｅｔ  ｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッド削減（Ｏｖｅｒｈｅａｄ  Ｒｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（Ｓｉｇｎａｌｉｎｇ  Ｔｒａｎｓｍｉｓｓｉｏｎ）などの機能を行うことができる。
【０２２３】
以下、パケットカプセル化について説明する。リンク層プロトコルは、ＩＰパケット及びＭＰＥＧ−２  ＴＳのようなものを含む全てのタイプのパケットのカプセル化を可能にする。リンク層プロトコルを用いて、物理層は、ネットワーク層プロトコルタイプと独立して一つのパケットフォーマットのみを処理すればよい（ここで、ネットワーク層パケットの一種としてＭＰＥＧ−２  ＴＳパケットを考慮）。各ネットワーク層パケット又は入力パケットは、ジェネリックリンク層パケットのペイロードに変形する。追加的に、入力パケットのサイズが特に小さいか又は大きい場合、物理層リソースを効率的に用いるために、連鎖及び分割を行うことができる。
【０２２４】
前述したように、パケットカプセル化過程で分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワーク層パケットが大きすぎるため、物理層で容易に処理できない場合、ネットワーク層パケットは２つ以上のセグメントに分けられる。リンク層パケットヘッダーは、送信側で分割を行い、受信側で再結合を行うために、プロトコルフィールドを含む。ネットワーク層パケットが分割される場合、各セグメントは、ネットワーク層パケットでの元の位置と同一の順序でリンク層パケットにカプセル化されてもよい。また、ネットワーク層パケットのセグメントを含む各リンク層パケットは、結果的に物理層に伝送されてもよい。
【０２２５】
前述したように、パケットカプセル化過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）も活用することができる。リンク層パケットのペイロードが多数のネットワーク層パケットを含む程度にネットワーク層パケットが十分に小さい場合、リンク層パケットヘッダーは、連鎖を行うためにプロトコルフィールドを含む。連鎖は、多数の小さい大きさのネットワーク層パケットを一つのペイロードに結合したものである。ネットワーク層パケットが連鎖すれば、各ネットワーク層パケットは、元の入力順序と同一の順序でリンク層パケットのペイロードに連鎖することができる。また、リンク層パケットのペイロードを構成する各パケットは、パケットのセグメントではない全体のパケットであり得る。
【０２２６】
以下、オーバーヘッド削減について説明する。リンク層プロトコルの使用により、物理層上でデータの伝送に対するオーバーヘッドを大きく減少させることができる。本発明に係るリンク層プロトコルは、ＩＰオーバーヘッド削減及び／又はＭＰＥＧ−２  ＴＳオーバーヘッド削減を提供することができる。ＩＰオーバーヘッド削減において、ＩＰパケットは、固定されたヘッダーフォーマットを有しているが、通信環境で必要な一部の情報はブロードキャスト環境で不要なことがある。リンク層プロトコルは、ＩＰパケットのヘッダーを圧縮することによってブロードキャストオーバーヘッドを削減するメカニズムを提供する。ＭＰＥＧ−２  ＴＳオーバーヘッド削減において、リンク層プロトコルは、シンクバイト除去、ヌルパケット削除及び／又は共通ヘッダー除去（圧縮）を提供する。まず、シンクバイト除去は、ＴＳパケット当たり１バイトのオーバーヘッド削減を提供し、次に、ヌルパケット削除メカニズムは、受信機で再挿入できる方式で１８８バイトのヌルＴＳパケットを除去する。最後に、共通ヘッダー除去メカニズムが提供される。
【０２２７】
シグナリング伝送に対して、リンク層プロトコルは、シグナリングパケットのための特定のフォーマットが、リンク層シグナリングを伝送するために提供され得る。これについては後述する。
【０２２８】
図示された本発明の一実施例に係るリンク層プロトコルアーキテクチャにおいて、リンク層プロトコルは、入力パケットとして、ＩＰｖ４、ＭＰＥＧ−２  ＴＳなどのような入力ネットワーク層パケットを取る。将来の拡張は、他のパケットタイプとリンク層で入力され得るプロトコルを示す。リンク層プロトコルは、物理層で特定のチャネルに対するマッピングに関する情報を含む全てのリンク層シグナリングに対するシグナリング及びフォーマットを特定する。図面は、ＡＬＰがどのように様々なヘッダー圧縮及び削除アルゴリズムを介して伝送効率を向上させるためにメカニズムを含むかを示す。また、リンク層プロトコルは、基本的に入力パケットをカプセル化することができる。
【０２２９】
図９は、本発明の一実施例に係るリンク層パケットのベースヘッダー構造を示した図である。以下、ヘッダーの構造について説明する。
【０２３０】
リンク層パケットは、データペイロードが後続するヘッダーを含むことができる。リンク層パケットのヘッダーは、ベースヘッダーを含むことができ、ベースヘッダーのコントロールフィールドに応じて追加ヘッダーを含むことができる。オプショナルヘッダーの存在は、追加ヘッダーのフラグフィールドから指示される。実施例によって、追加ヘッダー、オプショナルヘッダーの存在を示すフィールドはベースヘッダーに位置してもよい。
【０２３１】
以下、ベースヘッダーの構造について説明する。リンク層パケットカプセル化に対するベースヘッダーは階層構造を有する。ベースヘッダーは、２バイトの長さを有することができ、リンク層パケットヘッダーの最小長さである。
【０２３２】
図示された本発明の一実施例に係るベースヘッダーは、Ｐａｃｋｅｔ＿Ｔｙｐｅフィールド、ＰＣフィールド及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。実施例によって、ベースヘッダーは、ＨＭフィールド又はＳ／Ｃフィールドをさらに含むことができる。
【０２３３】
Ｐａｃｋｅｔ＿Ｔｙｐｅフィールドは、リンク層パケットへのカプセル化の前の入力データのパケットタイプ又は元のプロトコルを示す、３ビットのフィールドである。ＩＰｖ４パケット、圧縮されたＩＰパケット（ｃｏｍｐｒｅｓｓｅｄ  ＩＰ  ｐａｃｋｅｔ）、リンク層シグナリングパケット、及びその他のタイプのパケットが、このようなベースヘッダーの構造を有し、カプセル化されてもよい。ただし、実施例によって、ＭＰＥＧ−２  ＴＳパケットは、これとは異なる特別な構造を有し、カプセル化されてもよい。Ｐａｃｋｅｔ＿Ｔｙｐｅの値が「０００」、「００１」、「１００」又は「１１１」であると、ＡＬＰパケットの元のデータタイプは、ＩＰｖ４パケット、圧縮ＩＰパケット、リンク層シグナリング又は拡張パケットのうち１つである。ＭＰＥＧ−２  ＴＳパケットがカプセル化されると、Ｐａｃｋｅｔ＿Ｔｙｐｅの値は「０１０」であり得る。他のＰａｃｋｅｔ＿Ｔｙｐｅフィールドの値は、将来の使用のために残すことができる（ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ）。
【０２３４】
Ｐａｙｌｏａｄ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＰＣ）フィールドは、ペイロードの構成を示す１ビットのフィールドであり得る。０の値は、リンク層パケットが一つの全体の入力パケットを伝達し、次のフィールドがＨｅａｄｅｒ＿Ｍｏｄｅであることを示すことができる。１の値は、リンク層パケットが１つ以上の入力パケット（連鎖）や大きい入力パケット（分割）の一部を伝達し、次のフィールドがＳｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎであることを示すことができる。
【０２３５】
Ｈｅａｄｅｒ＿Ｍｏｄｅ（ＨＭ）フィールドは、０に設定される場合、追加ヘッダーがないことを示し、リンク層パケットのペイロードの長さが２０４８バイトよりも小さいことを示す、１ビットのフィールドであり得る。この数値は、実施例によって変更されてもよい。１の値は、下記に定義された１つのパケットのための追加ヘッダーが長さフィールドの次に存在することを示すことができる。この場合、ペイロードの長さは、２０４７バイトよりも大きく、及び／又はオプショナルフィーチャが使用され得る（サブストリーム識別、ヘッダー拡張など）。この数値は、実施例によって変更されてもよい。本フィールドは、リンク層パケットのＰａｙｌｏａｄ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドが０の値を有するときのみ存在し得る。
【０２３６】
Ｓｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）フィールドは、０に設定された場合、ペイロードが入力パケットのセグメントを伝達し、下記に定義されるセグメントのための追加ヘッダーが長さフィールドの次に存在することを示す、１ビットのフィールドであり得る。１の値は、ペイロードが１つよりも多い完全な入力パケットを伝達し、下記に定義された連鎖のための追加ヘッダーが長さフィールドの次に存在することを示すことができる。本フィールドは、ＡＬＰパケットのＰａｙｌｏａｄ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドの値が１であるときのみ存在し得る。
【０２３７】
長さフィールドは、リンク層パケットによって伝達されるペイロードのバイト単位の長さの１１  ＬＳＢｓ（ｌｅａｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔｓ）を示す、１１ビットのフィールドであり得る。次の追加ヘッダーにＬｅｎｇｔｈ＿ＭＳＢフィールドがあれば、長さフィールドは、Ｌｅｎｇｔｈ＿ＭＳＢフィールドに連鎖し、ペイロードの実際の全長を提供するためにＬＳＢとなる。長さフィールドのビット数は、１１ビット以外に他のビットに変更されてもよい。
【０２３８】
したがって、次のパケット構造のタイプが可能である。すなわち、追加ヘッダーがない１つのパケット、追加ヘッダーがある１つのパケット、分割されたパケット、連鎖したパケットが可能である。実施例によって、各追加ヘッダーとオプショナルヘッダー、後述するシグナリング情報のための追加ヘッダーとタイプ拡張のための追加ヘッダーによる組み合わせで、さらに多くのパケット構成が可能である。
【０２３９】
図１０は、本発明の一実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。
【０２４０】
追加ヘッダー（ａｄｄｉｔｉｏｎａｌ  ｈｅａｄｅｒ）は様々なタイプがあり得る。以下、シングルパケットのための追加ヘッダーについて説明する。
【０２４１】
１つのパケットに対する当該追加ヘッダーは、Ｈｅａｄｅｒ＿Ｍｏｄｅ（ＨＭ）＝「１」である場合に存在し得る。リンク層パケットのペイロードの長さが２０４７バイトよりも大きいか、又はオプションフィールドが使用される場合、Ｈｅａｄｅｒ＿Ｍｏｄｅ（ＨＭ）は１に設定され得る。１つのパケットの追加ヘッダー（ｔｓｉｂ１００１０）は図面に示す。
【０２４２】
Ｌｅｎｇｔｈ＿ＭＳＢフィールドは、現在のリンク層パケットにおいてバイト単位の全ペイロードの長さのＭＳＢｓ（ｍｏｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔｓ）を示すことができる、５ビットのフィールドであり得、全ペイロードの長さを得るために、１１  ＬＳＢを含む長さフィールドに連鎖する。したがって、シグナルできるペイロードの最大長さは６５５３５バイトである。長さフィールドのビット数は、１１ビット以外の他のビットに変更されてもよい。また、Ｌｅｎｇｔｈ＿ＭＳＢフィールドも、ビット数が変更されてもよく、これによって、最大に表現可能なペイロードの長さも変更されてもよい。実施例によって、各長さフィールドは、ペイロードではなく全リンク層パケットの長さを示してもよい。
【０２４３】
ＳＩＦ（Ｓｕｂ−ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒ  Ｆｌａｇ）フィールドは、ＨＥＦ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｆｌａｇ）フィールドの後にＳＩＤ（ｓｕｂ−ｓｔｒｅａｍ  ＩＤ）が存在するか否かを示すことができる、１ビットのフィールドであり得る。リンク層パケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンク層パケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。ＳＩＤについての詳細は後述する。
【０２４４】
ＨＥＦフィールドは、１に設定される場合、将来の拡張のために追加ヘッダーが存在することを示すことができる、１ビットのフィールドであり得る。０の値は、この拡張フィールダーが存在しないことを示すことができる。
【０２４５】
以下、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
【０２４６】
Ｓｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「０」である場合、追加ヘッダー（ｔｓｉｂ１００２０）が存在し得る。Ｓｅｇｍｅｎｔ＿Ｓｅｑｕｅｎｃｅ＿Ｎｕｍｂｅｒは、リンク層パケットによって伝達される当該セグメントの順序を示すことができる、５ビットの符号なし整数であり得る。入力パケットの最初のセグメントを伝達するリンク層パケットに対して、当該フィールドの値は０ｘ０に設定され得る。当該フィールドは、分割される入力パケットに属する各追加セグメント毎に１ずつ増分し得る。
【０２４７】
ＬＳＩ（Ｌａｓｔ＿Ｓｅｇｍｅｎｔ＿Ｉｎｄｉｃａｔｏｒ）は、１に設定される場合、当該ペイロードにあるセグメントが入力パケットの最後のものであることを示すことができる、１ビットのフィールドであり得る。０の値は、それが最後のセグメントではないことを示すことができる。
【０２４８】
ＳＩＦ（Ｓｕｂ−ｓｔｒｅａｍ  Ｉｄｅｎｔｉｆｉｅｒ  Ｆｌａｇ）は、ＳＩＤがＨＥＦフィールドの後に存在するか否かを示すことができる、１ビットのフィールドであり得る。リンク層パケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンク層パケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。
【０２４９】
ＨＥＦフィールドは、１に設定される場合、リンク層ヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、オプショナルヘッダー拡張が存在しないことを示すことができる。
【０２５０】
実施例によって、各分割されたセグメントが同一の入力パケットから生成されたことを示すパケットＩＤフィールドが追加されてもよい。このフィールドは、分割されたセグメントが順に伝送されれば必要でないので、省略されてもよい。
【０２５１】
以下、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。
【０２５２】
Ｓｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「１」である場合、追加ヘッダー（ｔｓｉｂ１００３０）が存在し得る。
【０２５３】
Ｌｅｎｇｔｈ＿ＭＳＢは、当該リンク層パケットにおいてバイト単位のペイロードの長さのＭＳＢビットを示すことができる、４ビットのフィールドであり得る。当該ペイロードの最大長さは、連鎖のために３２７６７バイトとなる。前述したものと同様に、詳細な数値は変更されてもよい。
【０２５４】
Ｃｏｕｎｔフィールドは、リンク層パケットに含まれたパケットの数を示すことができるフィールドであり得る。リンク層パケットに含まれたパケットの数に該当する２は、当該フィールドに設定され得る。したがって、リンク層パケットにおいて連鎖したパケットの最大値は９である。Ｃｏｕｎｔフィールドがその個数を指示する方法は、実施例毎に異なり得る。すなわち、１から８までの個数が指示されてもよい。
【０２５５】
ＨＥＦフィールドは、１に設定される場合、リンク層ヘッダーの将来の拡張のための追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、拡張ヘッダーが存在しないことを示すことができる。
【０２５６】
Ｃｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈは、各パケットのバイト単位の長さを示すことができる１２ビットのフィールドであり得る。Ｃｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドは、最後のコンポーネントパケットを除いて、ペイロードに存在するパケットと同一の順序で含まれる。長さフィールドの数は、（Ｃｏｕｎｔ＋１）によって示すことができる。実施例によって、Ｃｏｕｎｔフィールドの値と同一の数の長さフィールドが存在してもよい。リンク層ヘッダーが奇数のＣｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈで構成される場合、４個のスタッフィングビットが最後のＣｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドに後続することができる。これらのビットは０に設定され得る。実施例によって、最後の連鎖した入力パケットの長さを示すＣｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドは存在しないこともある。この場合、最後の連鎖した入力パケットの長さは、全ペイロードの長さから、各Ｃｏｍｐｏｎｅｎｔ＿ｌｅｎｇｔｈフィールドが示す値の和を引いた長さで指示することができる。
【０２５７】
以下、オプショナルヘッダーについて説明する。
【０２５８】
前述したように、オプショナルヘッダーは、追加ヘッダーの後ろに追加されてもよい。オプショナルヘッダーフィールドは、ＳＩＤ及び／又はヘッダー拡張を含むことができる。ＳＩＤは、リンク層レベルで特定のパケットストリームをフィルタするのに使用される。ＳＩＤの一例は、多数のサービスを伝達するリンク層ストリームにおいてサービス識別子の役割を果たす。適用可能な場合、サービスと、サービスに該当するＳＩＤ値との間のマッピング情報はＳＬＴで提供され得る。ヘッダー拡張は、将来の使用のための拡張フィールドを含む。受信機は、自身が理解できない全てのヘッダー拡張を無視し得る。
【０２５９】
ＳＩＤは、リンク層パケットに対するサブストリーム識別子を示すことができる８ビットのフィールドであり得る。オプショナルヘッダー拡張があれば、ＳＩＤは、追加ヘッダーとオプショナルヘッダー拡張との間に存在する。
【０２６０】
Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）は、下記に定義されたフィールドを含むことができる。
【０２６１】
Ｅｘｔｅｎｓｉｏｎ＿Ｔｙｐｅは、Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）のタイプを示すことができる８ビットのフィールドであり得る。
【０２６２】
Ｅｘｔｅｎｓｉｏｎ＿Ｌｅｎｇｔｈは、Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）の次のバイトから最後のバイトまでカウントされるＨｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ（）のバイトの長さを示すことができる、８ビットのフィールドであり得る。
【０２６３】
Ｅｘｔｅｎｓｉｏｎ＿Ｂｙｔｅは、Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）の値を示すバイトであり得る。
【０２６４】
図１１は、本発明の他の実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。
【０２６５】
以下、シグナリング情報のための追加ヘッダーについて説明する。
【０２６６】
リンク層シグナリングがどのようにリンク層パケットに含まれるかは、次の通りである。シグナリングパケットは、ベースヘッダーのＰａｃｋｅｔ＿Ｔｙｐｅフィールドが１００と同一であるときに識別される。
【０２６７】
図（ｔｓｉｂ１１０１０）は、シグナリング情報のための追加ヘッダーを含むリンク層パケットの構造を示す。リンク層ヘッダーだけでなく、リンク層パケットは、シグナリング情報のための追加ヘッダー及び実際のシグナリングデータ自体の２つの追加部分で構成され得る。リンク層シグナリングパケットの全長はリンク層パケットヘッダーに示す。
【０２６８】
シグナリング情報のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって、一部のフィールドは省略されてもよい。
【０２６９】
Ｓｉｇｎａｌｉｎｇ＿Ｔｙｐｅは、シグナリングのタイプを示すことができる８ビットのフィールドであり得る。
【０２７０】
Ｓｉｇｎａｌｉｎｇ＿Ｔｙｐｅ＿Ｅｘｔｅｎｓｉｏｎは、シグナリングの属性を示すことができる１６ビットのフィールドであり得る。当該フィールドの詳細はシグナリングの仕様で定義され得る。
【０２７１】
Ｓｉｇｎａｌｉｎｇ＿Ｖｅｒｓｉｏｎは、シグナリングのバージョンを示すことができる８ビットのフィールドであり得る。
【０２７２】
Ｓｉｇｎａｌｉｎｇ＿Ｆｏｒｍａｔは、シグナリングデータのデータフォーマットを示すことができる２ビットのフィールドであり得る。ここで、シグナリングフォーマットとは、バイナリ、ＸＭＬなどのデータフォーマットを意味し得る。
【０２７３】
Ｓｉｇｎａｌｉｎｇ＿Ｅｎｃｏｄｉｎｇは、エンコーディング／圧縮フォーマットを特定することができる２ビットのフィールドであり得る。本フィールドは、圧縮が行われなかったか、どのような特定の圧縮が行われたかを示すことができる。
【０２７４】
以下、パケットタイプの拡張のための追加ヘッダーについて説明する。
【０２７５】
将来にリンク層によって伝達されるパケットタイプ及び追加プロトコルの無制限に近い数を許容するメカニズムを提供するために、追加ヘッダーが定義される。前述したように、ベースヘッダーでＰａｃｋｅｔ＿ｔｙｐｅが１１１である場合、パケットタイプの拡張が使用され得る。図（ｔｓｉｂ１１０２０）は、タイプの拡張のための追加ヘッダーを含むリンク層パケットの構造を示す。
【０２７６】
タイプの拡張のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって、一部のフィールドは省略されてもよい。
【０２７７】
ｅｘｔｅｎｄｅｄ＿ｔｙｐｅは、ペイロードとしてリンク層パケットにカプセル化される入力のプロトコルやパケットタイプを示すことができる、１６ビットのフィールドであり得る。当該フィールドは、Ｐａｃｋｅｔ＿Ｔｙｐｅフィールドによって既に定義された全てのプロトコルやパケットタイプに対して使用することができない。
【０２７８】
図１２は、本発明の一実施例に係る、ＭＰＥＧ−２  ＴＳパケットのためのリンク層パケットのヘッダーの構造、及びそのカプセル化の過程を示した図である。
【０２７９】
以下、入力パケットとしてＭＰＥＧ−２  ＴＳパケットが入力されたとき、リンク層パケットのフォーマットについて説明する。
【０２８０】
この場合、ベースヘッダーのＰａｃｋｅｔ＿Ｔｙｐｅフィールドは０１０と同一である。各リンク層パケット内で多数のＴＳパケットがカプセル化されてもよい。ＴＳパケットの数は、ＮＵＭＴＳフィールドを介してシグナルされてもよい。この場合、前述したように、特別なリンク層パケットヘッダーフォーマットが使用されてもよい。
【０２８１】
リンク層は、伝送効率を向上させるために、ＭＰＥＧ−２  ＴＳのためのオーバーヘッド削減メカニズムを提供する。各ＴＳパケットのシンクバイト（０ｘ４７）は削除され得る。ヌルパケット及び類似のＴＳヘッダーを削除するオプションも提供される。
【０２８２】
不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（ＰＩＤ＝０ｘ１ＦＦＦ）を除去することができる。削除されたヌルパケットは、ＤＮＰフィールドを用いて受信機側で復旧することができる。ＤＮＰフィールドは、削除されたヌルパケットのカウントを示す。ＤＮＰフィールドを用いたヌルパケット削除メカニズムは、後述する。
【０２８３】
伝送効率をさらに向上させるために、ＭＰＥＧ−２  ＴＳパケットの類似のヘッダーを除去することができる。２つ以上の順次的なＴＳパケットがＣＣ（ｃｏｎｔｉｎｕｉｔｙ  ｃｏｕｎｔｅｒ）フィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。ＨＤＭフィールドは、ヘッダーが削除されたか否かを示すことができる。共通ＴＳヘッダー削除の詳細な過程は後述する。
【０２８４】
３つのオーバーヘッド削減メカニズムが全て行われる場合、オーバーヘッド削減は、シンク除去、ヌルパケット削除、共通ヘッダー削除の順に行うことができる。実施例によって、各メカニズムが行われる順序は変更されてもよい。また、実施例によって一部のメカニズムは省略されてもよい。
【０２８５】
ＭＰＥＧ−２  ＴＳパケットカプセル化を使用する場合のリンク層パケットヘッダーの全体的な構造が図（ｔｓｉｂ１２０１０）に示されている。
【０２８６】
以下、図示された各フィールドについて説明する。Ｐａｃｋｅｔ＿Ｔｙｐｅは、前述したように、入力パケットのプロトコルタイプを示すことができる３ビットのフィールドであり得る。ＭＰＥＧ−２  ＴＳパケットカプセル化のために、当該フィールドは、常に０１０に設定され得る。
【０２８７】
ＮＵＭＴＳ（Ｎｕｍｂｅｒ  ｏｆ  ＴＳ  ｐａｃｋｅｔｓ）は、当該リンク層パケットのペイロードでＴＳパケットの数を示すことができる４ビットのフィールドであり得る。最大１６個のＴＳパケットが一つのリンク層パケットで支援され得る。ＮＵＭＴＳ＝０の値は、１６個のＴＳパケットがリンク層パケットのペイロードによって伝達されることを示すことができる。ＮＵＭＴＳの他の全ての値に対して、同じ数のＴＳパケットが認識される。例えば、ＮＵＭＴＳ＝０００１は、一つのＴＳパケットが伝達されることを意味する。
【０２８８】
ＡＨＦ（ａｄｄｉｔｉｏｎａｌ  ｈｅａｄｅｒ  ｆｌａｇ）は、追加ヘッダーが存在するか否かを示すことができるフィールドであり得る。０の値は、追加ヘッダーが存在しないことを示す。１の値は、１バイト長の追加ヘッダーがベースヘッダーの次に存在することを示す。ヌルＴＳパケットが削除されるか、又はＴＳヘッダー圧縮が適用されれば、当該フィールドは１に設定され得る。ＴＳパケットカプセル化のための追加ヘッダーは、次の２つのフィールドで構成され、当該リンク層パケットでのＡＨＦの値が１に設定される場合にのみ存在する。
【０２８９】
ＨＤＭ（ｈｅａｄｅｒ  ｄｅｌｅｔｉｏｎ  ｍｏｄｅ）は、ＴＳヘッダー削除を当該リンク層パケットに適用できるか否かを示す１ビットのフィールドであり得る。１の値は、ＴＳヘッダー削除を適用できることを示す。０の値は、ＴＳヘッダー削除の方法が当該リンク層パケットに適用されないことを示す。
【０２９０】
ＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ  ｐａｃｋｅｔｓ）は、当該リンク層パケットの前に削除されたヌルＴＳパケットの数を示す７ビットのフィールドであり得る。最大１２８個のヌルＴＳパケットが削除され得る。ＨＤＭ＝０である場合、ＤＮＰ＝０の値は、１２８個のヌルパケットが削除されることを示すことができる。ＨＤＭ＝１である場合、ＤＮＰ＝０の値は、ヌルパケットが削除されないことを示すことができる。ＤＮＰの他の全ての値に対して、同じ数のヌルパケットが認識される。例えば、ＤＮＰ＝５は、５個のヌルパケットが削除されることを意味する。
【０２９１】
前述した各フィールドのビット数は変更可能であり、変更されたビット数に応じて、当該フィールドが指示する値の最小／最大値は変更され得る。これは、設計者の意図によって変更されてもよい。
【０２９２】
以下、シンクバイト削除（ＳＹＮＣ  ｂｙｔｅ  ｒｅｍｏｖａｌ）について説明する。
【０２９３】
ＴＳパケットをリンク層パケットのペイロードにカプセル化する場合、各ＴＳパケットの開始からシンクバイト（０ｘ４７）が削除され得る。したがって、リンク層パケットのペイロードにカプセル化されたＭＰＥＧ２−ＴＳパケットの長さは（元の１８８バイトの代わりに）、常に１８７バイトである。
【０２９４】
以下、ヌルパケット削除（Ｎｕｌｌ  Ｐａｃｋｅｔ  Ｄｅｌｅｔｉｏｎ）について説明する。
【０２９５】
伝送ストリーム規則は、送信機のマルチプレクサの出力及び受信機のデマルチプレクサの入力でのビットレートが時間に対して一定であり、終端間の遅延も一定であることを要求する。一部の伝送ストリーム入力信号に対して、ヌルパケットは、一定のビットレートストリームに可変的なビットレートサービスを収容するために存在することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（即ち、ＰＩＤ＝０ｘ１ＦＦＦであるＴＳパケット）が除去され得る。この処理は、除去されたヌルパケットが受信機で元の正確な位置に再び挿入され得る方式で実行されるので、一定のビットレートを保障し、ＰＣＲタイムスタンプ更新を行う必要がなくなる。
【０２９６】
リンク層パケットの生成の前に、ＤＮＰと呼ばれるカウンターは、まず、０にリセットされた後に、現在のリンク層パケットのペイロードにカプセル化される最初のヌルＴＳパケットではない、パケットに先行する各削除されたヌルパケットに対して増分され得る。その後、連続した有用なＴＳパケットのグループが現在のリンク層パケットのペイロードにカプセル化され、そのヘッダーでの各フィールドの値が決定され得る。生成されたリンク層パケットが物理層に注入された後、ＤＮＰは０にリセットされる。ＤＮＰが最高の許容値に到達する場合、次のパケットもヌルパケットであれば、当該ヌルパケットは有用なパケットに維持され、次のリンク層パケットのペイロードにカプセル化される。各リンク層パケットは、そのペイロードに少なくとも１つの有用なＴＳパケットを含むことができる。
【０２９７】
以下、ＴＳパケットヘッダー削除（ＴＳ  Ｐａｃｋｅｔ  Ｈｅａｄｅｒ  Ｄｅｌｅｔｉｏｎ）について説明する。ＴＳパケットヘッダー削除は、ＴＳパケットヘッダー圧縮と呼ぶこともできる。
【０２９８】
２つ以上の順次的なＴＳパケットがＣＣフィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。重複したＭＰＥＧ−２  ＴＳパケットが２つ以上の順次的なＴＳパケットに含まれると、ヘッダーの削除は送信機側で適用することができない。ＨＤＭフィールドは、ヘッダーが削除されるか否かを示すことができる。ＴＳヘッダーが削除される場合、ＨＤＭは１に設定され得る。受信機側で、最初のパケットヘッダーを用いて、削除されたパケットヘッダーが復旧され、ＣＣが最初のヘッダーから順に増加することによって復旧される。
【０２９９】
図示された実施例（ｔｓｉｂ１２０２０）は、ＴＳパケットの入力ストリームがリンク層パケットにカプセル化される過程の一実施例である。まず、ＳＹＮＣバイト（０ｘ４７）を有するＴＳパケットからなるＴＳストリームが入力され得る。まず、ＳＹＮＣバイトの削除過程を通じてシンクバイトを削除することができる。この実施例において、ヌルパケット削除は行われないと仮定する。
【０３００】
ここで、図示された８個のＴＳパケットのパケットヘッダーにおいて、ＣＣ（Ｃｏｕｎｔｉｎｕｉｔｙ  Ｃｏｕｎｔｅｒ）フィールド値を除いた他の値が全て同一であると仮定する。この場合、ＴＳパケット削除／圧縮を行うことができる。ＣＣ＝１である最初のＴＳパケットのヘッダーのみを残し、残りの７個のＴＳパケットのヘッダーを削除する。処理されたＴＳパケットは、リンク層パケットのペイロードにカプセル化されてもよい。
【０３０１】
完成されたリンク層パケットを見ると、Ｐａｃｋｅｔ＿Ｔｙｐｅフィールドは、ＴＳパケットが入力された場合であるので０１０の値を有することができる。ＮＵＭＴＳフィールドは、カプセル化されたＴＳパケットの個数を示すことができる。ＡＨＦフィールドは、パケットヘッダーの削除が行われたので１に設定され、追加ヘッダーの存在を知らせることができる。ＨＤＭフィールドは、ヘッダーの削除が行われたので１に設定され得る。ＤＮＰは、ヌルパケットの削除が行われなかったので、０に設定され得る。
【０３０２】
図１３は、本発明の一実施例に係るＩＰヘッダー圧縮において、適応モードの実施例を示した図である（送信側）。
【０３０３】
以下、ＩＰヘッダー圧縮（ＩＰ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。
【０３０４】
リンク層において、ＩＰヘッダー圧縮／圧縮解除スキームが提供され得る。ＩＰヘッダー圧縮は、ヘッダーコンプレッサ／デコンプレッサ及び適応モジュールの２つの部分を含むことができる。ヘッダー圧縮スキームはＲｏＨＣに基づくことができる。また、放送用途に適応機能が追加される。
【０３０５】
送信機側で、ＲｏＨＣコンプレッサは、各パケットに対してヘッダーの大きさを減少させる。その後、適応モジュールは、コンテキスト情報を抽出し、各パケットストリームからシグナリング情報を生成する。受信機側で、適応モジュールは、受信されたパケットストリームと関連するシグナリング情報をパースし、コンテキスト情報を受信されたパケットストリームに付加する。ＲｏＨＣデコンプレッサは、パケットヘッダーを復旧することによって元のＩＰパケットを再構成する。
【０３０６】
ヘッダー圧縮スキームは、前述したように、ＲＯＨＣをベースとすることができる。特に、本システムでは、ＲＯＨＣのＵモード（ｕｎｉ  ｄｉｒｃｔｉｏｎａｌ  ｍｏｄｅ）でＲＯＨＣフレームワークが動作することができる。また、本システムにおいて、０ｘ０００２のプロファイル識別子で識別されるＲＯＨＣ  ＵＤＰヘッダー圧縮プロファイルが使用され得る。
【０３０７】
以下、適応（Ａｄａｐｔａｔｉｏｎ）について説明する。
【０３０８】
単方向リンクを介した伝送の場合、受信機がコンテキストの情報を有していないと、デコンプレッサは、完全なコンテキストを受信する時まで、受信されたパケットヘッダーを復旧することができない。これは、チャネル変更遅延及びターンオン遅延（ｔｕｒｎ−ｏｎ  ｄｅｌａｙ）を招くことがある。このような理由で、コンプレッサとデコンプレッサとの間の構成パラメータ及びコンテキスト情報は、常にパケットフローと共に伝送され得る。
【０３０９】
適応機能は、構成パラメータ及びコンテキスト情報の帯域外伝送を提供する。帯域外伝送は、リンク層シグナリングを通じて行うことができる。したがって、適応機能は、コンテキスト情報の損失による圧縮解除誤り及びチャネル変更遅延を減少させるために用いられる。
【０３１０】
以下、コンテキスト情報（Ｃｏｎｔｅｘｔ  Ｉｎｆｏｒｍａｔｉｏｎ）の抽出について説明する。
【０３１１】
コンテキスト情報の抽出は、適応モードに応じて様々な方法で行うことができる。本発明では、以下の３つの実施例について説明する。本発明の範囲は、後述する適応モードの実施例に限定されない。ここで、適応モードは、コンテキスト抽出モードと呼ぶこともできる。
【０３１２】
適応モード１（図示せず）は、基本的なＲＯＨＣパケットストリームに対していかなる追加的な動作も加えられていないモードであり得る。すなわち、このモードで適応モジュールは、バッファとして動作することができる。したがって、このモードでは、リンク層シグナリングにコンテキスト情報が含まれていない。
【０３１３】
適応モード２（ｔｓｉｂ１３０１０）において、適応モジュールは、ＲｏＨＣパケットフローからＩＲパケットを検出し、コンテキスト情報（静的チェーン）を抽出することができる。コンテキスト情報を抽出した後、各ＩＲパケットは、ＩＲ−ＤＹＮパケットに転換され得る。転換されたＩＲ−ＤＹＮパケットは、元のパケットの代わりに、ＩＲパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
【０３１４】
適応モード３（ｔｓｉｂ１３０２０）において、適応モジュールは、ＲｏＨＣパケットフローからＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテキスト情報を抽出することができる。静的チェーン及び動的チェーンはＩＲパケットから抽出することができ、動的チェーンはＩＲ−ＤＹＮパケットから抽出することができる。コンテキスト情報を抽出した後、それぞれのＩＲ及びＩＲ−ＤＹＮパケットは圧縮されたパケットに転換され得る。圧縮されたパケットのフォーマットは、ＩＲ又はＩＲ−ＤＹＮパケットの次のパケットと同一であり得る。転換された圧縮パケットは、元のパケットの代わりに、ＩＲ又はＩＲ−ＤＹＮパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。
【０３１５】
シグナリング（コンテキスト）情報は、伝送構造に基づいてカプセル化され得る。例えば、コンテキスト情報は、リンク層シグナリングにカプセル化され得る。この場合、パケットタイプ値は１００に設定され得る。
【０３１６】
前述した適応モード２、３に対して、コンテキスト情報に対するリンク層パケットは、１００のパケットタイプ（Ｐａｃｋｅｔ Ｔｙｐｅ）フィールド値を有することができる。また、圧縮されたＩＰパケットに対するリンク層パケットは、００１のパケットタイプフィールド値を有することができる。これは、それぞれシグナリング情報、圧縮されたＩＰパケットがリンク層パケットに含まれていることを示すもので、前述した通りである。
【０３１７】
以下、抽出されたコンテキスト情報を伝送する方法について説明する。
【０３１８】
抽出されたコンテキスト情報は、特定の物理データ経路を介してシグナリングデータと共に、ＲｏＨＣパケットフローと別途に伝送され得る。コンテキストの伝送は、物理層経路の構成に依存する。コンテキスト情報は、シグナリングデータパイプを介して他のリンク層シグナリングと共に伝送され得る。
【０３１９】
すなわち、コンテキスト情報を有するリンク層パケットは、他のリンク層シグナリング情報を有するリンク層パケットと共にシグナリングＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ＿Ｔｙｐｅ＝１００）。コンテキスト情報が抽出された圧縮ＩＰパケットは、一般的なＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ＿Ｔｙｐｅ＝００１）。ここで、実施例によって、シグナリングＰＬＰは、Ｌ１シグナリング経路（ｐａｔｈ）を意味してもよい。また、実施例によって、シグナリングＰＬＰは、一般的なＰＬＰと区分されず、シグナリング情報が伝送される特定の一般ＰＬＰを意味してもよい。
【０３２０】
受信側では、パケットストリームを受信するに先立ち、受信機がシグナリング情報を得る必要がある。受信機が、シグナリング情報を取得するために最初のＰＬＰをデコードすると、コンテキストシグナリングも受信することができる。シグナリングの取得が行われた後、パケットストリームを受信するためのＰＬＰが選択され得る。すなわち、受信機は、まず、イニシャルＰＬＰを選択して、コンテキスト情報を含めてシグナリング情報を得ることができる。ここで、イニシャルＰＬＰは、前述したシグナリングＰＬＰであり得る。その後、受信機は、パケットストリームを得るためのＰＬＰを選択することができる。これを通じて、コンテキスト情報は、パケットストリームの受信に先立って取得できる。
【０３２１】
パケットストリームを得るためのＰＬＰが選択された後、適応モジュールは、受信されたパケットフローからＩＲ−ＤＹＮパケットを検出することができる。その後、適応モジュールは、シグナリングデータにおいてコンテキスト情報から静的チェーンをパースする。これは、ＩＲパケットを受信することと類似している。同一のコンテキスト識別子に対して、ＩＲ−ＤＹＮパケットはＩＲパケットに復旧され得る。復旧されたＲｏＨＣパケットフローはＲｏＨＣデコンプレッサに送られる。その後、圧縮解除が開始され得る。
【０３２２】
図１４は、本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）及びＲＯＨＣ−Ｕ記述テーブルを示した図である。
【０３２３】
以下、リンク層シグナリングについて説明する。
【０３２４】
主に、リンク層シグナリングはＩＰレベル下で動作する。受信機側で、リンク層シグナリングは、ＳＬＴ及びＳＬＳのようなＩＰレベルシグナリングよりも先に取得され得る。したがって、リンク層シグナリングはセッション設定の前に取得できる。
【０３２５】
リンク層シグナリングに対して、入力経路に応じて、インターナルリンク層シグナリング及びエクスターナルリンク層シグナリングの２種類のシグナリングが存在することができる。インターナルリンク層シグナリングは、送信機側でリンク層で生成される。また、リンク層は、外部のモジュール又はプロトコルからシグナリングを取る。このような種類のシグナリング情報はエクスターナルリンク層シグナリングであると見なされる。一部のシグナリングがＩＰレベルシグナリングに先立って取得される必要があれば、外部のシグナリングは、リンク層パケットのフォーマットで伝送される。
【０３２６】
リンク層シグナリングは、前述したように、リンク層パケットにカプセル化され得る。リンク層パケットは、バイナリ及びＸＭＬを含んだ全てのフォーマットのリンク層シグナリングを伝達することができる。同一のシグナリング情報がリンク層シグナリングに対して異なるフォーマットで伝送され得る。
【０３２７】
インターナルリンク層シグナリングには、リンクマッピングのためのシグナリング情報が含まれてもよい。ＬＭＴは、ＰＬＰに伝達される上位層セッションのリストを提供する。ＬＭＴはまた、リンク層で上位層セッションを伝達するリンク層パケットを処理するための追加情報を提供する。
【０３２８】
本発明に係るＬＭＴの一実施例（ｔｓｉｂ１４０１０）が図示された。
【０３２９】
ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットの符号なし整数フィールドであり得る。ＬＭＴに対するｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値は０ｘ０１に設定され得る。
【０３３０】
ＰＬＰ＿ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
【０３３１】
ｎｕｍ＿ｓｅｓｓｉｏｎは、前記ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションの個数を提供する８ビットの符号なし整数フィールドであり得る。ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値が０ｘ０１であれば、当該フィールドは、ＰＬＰでＵＤＰ／ＩＰセッションの個数を示すことができる。
【０３３２】
ｓｒｃ＿ＩＰ＿ａｄｄは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションのソースＩＰ住所を含む３２ビットの符号なし整数フィールドであり得る。
【０３３３】
ｄｓｔ＿ＩＰ＿ａｄｄは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションの目的地ＩＰ住所を含む３２ビットの符号なし整数フィールドであり得る。
【０３３４】
ｓｒｃ＿ＵＤＰ＿ｐｏｒｔは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションのソースＵＤＰポート番号を示す１６ビットの符号なし整数フィールドであり得る。
【０３３５】
ｄｓｔ＿ＵＤＰ＿ｐｏｒｔは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションの目的地ＵＤＰポート番号を示す１６ビットの符号なし整数フィールドであり得る。
【０３３６】
ＳＩＤ＿ｆｌａｇは、前記４個のフィールドＳｒｃ＿ＩＰ＿ａｄｄ、Ｄｓｔ＿ＩＰ＿ａｄｄ、Ｓｒｃ＿ＵＤＰ＿Ｐｏｒｔ、Ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔによって識別される上位層セッションを伝達するリンク層パケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位層セッションを伝達するリンク層パケットがそのオプショナルヘッダーにＳＩＤフィールドを有さない。当該フィールドの値が１に設定されると、上位層セッションを伝達するリンク層パケットがそのオプショナルヘッダーにＳＩＤフィールドを有することができ、ＳＩＤフィールドの値が、当該テーブルで次のＳＩＤフィールドと同一であり得る。
【０３３７】
ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇは、ヘッダー圧縮が、前記４個のフィールドＳｒｃ＿ＩＰ＿ａｄｄ、Ｄｓｔ＿ＩＰ＿ａｄｄ、Ｓｒｃ＿ＵＤＰ＿Ｐｏｒｔ、Ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔによって識別される上位層セッションを伝達するリンク層パケットに適用されるか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位層セッションを伝達するリンク層パケットは、そのベースヘッダーにＰａｃｋｅｔ＿Ｔｙｐｅフィールドの０ｘ００の値を有することができる。当該フィールドの値が１に設定されると、上位層セッションを伝達するリンク層パケットは、そのベースヘッダーにＰａｃｋｅｔ＿Ｔｙｐｅフィールドの０ｘ０１の値を有することができ、Ｃｏｎｔｅｘｔ＿ＩＤフィールドが存在することができる。
【０３３８】
ＳＩＤは、前記４個のフィールドＳｒｃ＿ＩＰ＿ａｄｄ、Ｄｓｔ＿ＩＰ＿ａｄｄ、Ｓｒｃ＿ＵＤＰ＿Ｐｏｒｔ、Ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔによって識別される上位層セッションを伝達するリンク層パケットに対するサブストリーム識別子を示す８ビットの符号なし整数フィールドであり得る。当該フィールドは、ＳＩＤ＿ｆｌａｇの値が１と同一であるときに存在することができる。
【０３３９】
ｃｏｎｔｅｘｔ＿ｉｄは、ＲＯＨＣ−Ｕ記述テーブルに提供されたＣＩＤ（ｃｏｎｔｅｘｔ  ｉｄ）に対するリファレンスを提供する８ビットのフィールドであり得る。当該フィールドは、ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇの値が１と同一であるときに存在することができる。
【０３４０】
本発明に係るＲＯＨＣ−Ｕ記述テーブルの一実施例（ｔｓｉｂ１４０２０）が図示された。前述したように、ＲＯＨＣ−Ｕ適応モジュールは、ヘッダー圧縮に関連する情報を生成することができる。
【０３４１】
ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットのフィールドであり得る。ＲＯＨＣ−Ｕ記述テーブルに対するｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値は「０ｘ０２」に設定され得る。
【０３４２】
ＰＬＰ＿ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。
【０３４３】
ｃｏｎｔｅｘｔ＿ｉｄは、圧縮されたＩＰストリームのＣＩＤを示す８ビットのフィールドであり得る。当該システムにおいて、８ビットのＣＩＤは、大きいＣＩＤのために使用することができる。
【０３４４】
ｃｏｎｔｅｘｔ＿ｐｒｏｆｉｌｅは、ストリームを圧縮するために使用されるプロトコルの範囲を示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
【０３４５】
ａｄａｐｔａｔｉｏｎ＿ｍｏｄｅは、当該ＰＬＰで適応モジュールのモードを示す２ビットのフィールドであり得る。適応モードについては前述した。
【０３４６】
ｃｏｎｔｅｘｔ＿ｃｏｎｆｉｇは、コンテキスト情報の組み合わせを示す２ビットのフィールドであり得る。当該テーブルにコンテキスト情報が存在しなければ、当該フィールドは「０ｘ０」に設定され得る。当該テーブルにｓｔａｔｉｃ＿ｃｈａｉｎ（）又はｄｙｎａｍｉｃ＿ｃｈａｉｎ（）バイトが含まれれば、当該フィールドは「０ｘ０１」又は「０ｘ０２」に設定され得る。当該テーブルにｓｔａｔｉｃ＿ｃｈａｉｎ（）及びｄｙｎａｍｉｃ＿ｃｈａｉｎ（）バイトが全て含まれれば、当該フィールドは「０ｘ０３」に設定され得る。
【０３４７】
ｃｏｎｔｅｘｔ＿ｌｅｎｇｔｈは、静的チェーンバイトシーケンスの長さを示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。
【０３４８】
ｓｔａｔｉｃ＿ｃｈａｉｎ＿ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサを初期化するために使用される静的情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
【０３４９】
ｄｙｎａｍｉｃ＿ｃｈａｉｎ＿ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサを初期化するために使用される動的情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。
【０３５０】
ｓｔａｔｉｃ＿ｃｈａｉｎ＿ｂｙｔｅは、ＩＲパケットのサブヘッダー情報として定義することができる。ｄｙｎａｍｉｃ＿ｃｈａｉｎ＿ｂｙｔｅは、ＩＲパケット及びＩＲ−ＤＹＮパケットのサブヘッダー情報として定義することができる。
【０３５１】
図１５は、本発明の一実施例に係る送信機側のリンク層の構造を示した図である。
【０３５２】
本実施例は、ＩＰパケットを処理することを仮定した実施例である。送信機側のリンク層は、機能的な観点から、大きく、シグナリング情報を処理するリンク層シグナリング部分、オーバーヘッド削減部分、及び／又はカプセル化部分を含むことができる。また、送信機側のリンク層は、リンク層全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンク層の入出力部分などを含むことができる。
【０３５３】
まず、上位層のシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）がリンク層に伝達され得る。また、ＩＰ層（ｔｓｉｂ１５１１０）から、ＩＰパケットを含むＩＰストリームがリンク層に伝達され得る。
【０３５４】
スケジューラ（ｔｓｉｂ１５０２０）は、前述したように、リンク層に含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）は、スケジューラ（ｔｓｉｂ１５０２０）によってフィルタリング又は活用されてもよい。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）のうち、受信機で必要な情報はリンク層シグナリング部分に伝達されてもよい。また、シグナリング情報のうちリンク層の動作に必要な情報は、オーバーヘッド削減コントローラ（ｔｓｉｂ１５１２０）又はカプセル化コントローラ（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３５５】
リンク層シグナリング部分は、物理層でシグナリングとして伝送される情報を収集し、これを、伝送に適した形態に変換／構成する役割を果たすことができる。リンク層シグナリング部分は、シグナリングマネジャー（ｔｓｉｂ１５０３０）、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）、及び／又はチャネルのためのバッファ（ｔｓｉｂ１５０５０）を含むことができる。
【０３５６】
シグナリングマネジャー（ｔｓｉｂ１５０３０）は、スケジューラ（ｔｓｉｂ１５０２０）から伝達されたシグナリング情報、及び／又はオーバーヘッド削減部分から伝達されたシグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を受信することができる。シグナリングマネジャー（ｔｓｉｂ１５０３０）は、伝達されたデータに対して、各シグナリング情報が伝送される経路を決定することができる。各シグナリング情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって決定された経路で伝達されてもよい。前述したように、ＦＩＣ、ＥＡＳなどの区分されたチャネルで伝送されるシグナリング情報はシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に伝達され、その他のシグナリング情報はカプセル化バッファ（ｔｓｉｂ１５０７０）に伝達されてもよい。
【０３５７】
シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、別途に区分されたチャネルを介してシグナリング情報を伝送できるように、関連するシグナリング情報を各区分されたチャネルに合う形態でフォーマットする役割を果たすことができる。前述したように、物理層には、物理的／論理的に区分された別途のチャネルがあり得る。これらの区分されたチャネルは、ＦＩＣシグナリング情報や、ＥＡＳ関連情報を伝送するのに使用することができる。ＦＩＣ又はＥＡＳ関連情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって分類されてシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に入力されてもよい。シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、各情報を、それぞれの別途のチャネルに合わせてフォーマットすることができる。ＦＩＣ、ＥＡＳ以外にも、物理層が特定のシグナリング情報を別途の区分されたチャネルを介して伝送するものと設計された場合には、その特定のシグナリング情報のためのシグナリングフォーマッタを追加することができる。このような方式を通じて、リンク層が、様々な物理層に対して互換可能となり得る。
【０３５８】
チャネルのためのバッファ（ｔｓｉｂ１５０５０）は、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）から伝達されたシグナリング情報を、指定された別途のチャネル（ｔｓｉｂ１５０６０）に伝達する役割を果たすことができる。別途のチャネルの数、内容は、実施例によって変更されてもよい。
【０３５９】
前述したように、シグナリングマネジャー（ｔｓｉｂ１５０３０）は、特定のチャネルに伝達されないシグナリング情報をカプセル化バッファ（ｔｓｉｂ１５０７０）に伝達することができる。カプセル化バッファ（ｔｓｉｂ１５０７０）は、特定のチャネルに伝達されないシグナリング情報を受信するバッファの役割を果たすことができる。
【０３６０】
シグナリング情報のためのカプセル化（ｔｓｉｂ１５０８０）は、特定のチャネルに伝達されないシグナリング情報に対してカプセル化を行うことができる。伝送バッファ（ｔｓｉｂ１５０９０）は、カプセル化されたシグナリング情報を、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）に伝達するバッファの役割を果たすことができる。ここで、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）は、前述したＰＬＳ領域を意味し得る。
【０３６１】
オーバーヘッド削減部分は、リンク層に伝達されるパケットのオーバーヘッドを除去し、効率的な伝送を可能にすることができる。オーバーヘッド削減部分は、リンク層に入力されるＩＰストリームの数だけ構成することができる。
【０３６２】
オーバーヘッド削減バッファ（ｔｓｉｂ１５１３０）は、上位層から伝達されたＩＰパケットの入力を受ける役割を果たすことができる。伝達されたＩＰパケットは、オーバーヘッド削減バッファ（ｔｓｉｂ１５１３０）を介してオーバーヘッド削減部分に入力されてもよい。
【０３６３】
オーバーヘッド削減コントローラ（ｔｓｉｂ１５１２０）は、オーバーヘッド削減バッファ（ｔｓｉｂ１５１３０）に入力されるパケットストリームに対してオーバーヘッド削減を行うか否かを決定することができる。オーバーヘッド削減コントローラ（ｔｓｉｂ１５１２０）は、パケットストリーム別にオーバーヘッド削減を行うか否かを決定することができる。パケットストリームにオーバーヘッド削減が行われる場合、ＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）にパケットが伝達され、オーバーヘッド削減が行われ得る。パケットストリームにオーバーヘッド削減が行われない場合、カプセル化部分にパケットが伝達され、オーバーヘッド削減なしにカプセル化が行われ得る。パケットにオーバーヘッド削減を行うか否かは、リンク層に伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってカプセル化コントローラ（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３６４】
ＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）は、パケットストリームに対してオーバーヘッド削減を行うことができる。ＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）は、パケットのヘッダーを圧縮する動作を行うことができる。オーバーヘッド削減には様々な方法を使用することができる。前述した、本発明が提案した方法によってオーバーヘッド削減を行うことができる。本実施例は、ＩＰストリームを仮定しており、ＲｏＨＣコンプレッサと表現したが、実施例によって名称は変更されてもよく、動作も、ＩＰストリームの圧縮に限定されず、全ての種類のパケットのオーバーヘッド削減がＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）によって行われてもよい。
【０３６５】
パケットストリーム構成ブロック（ｔｓｉｂ１５１５０）は、ヘッダーが圧縮されたＩＰパケットのうち、シグナリング領域に伝送される情報とパケットストリームに伝送される情報を分離することができる。パケットストリームに伝送される情報とは、ＤＰ領域に伝送される情報を意味し得る。シグナリング領域に伝送される情報は、シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１５１６０）に伝達されてもよい。パケットストリームに伝送される情報はカプセル化部分に伝送されてもよい。
【０３６６】
シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１５１６０）は、シグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を収集し、これをシグナリングマネジャーに伝達することができる。これは、シグナリング及び／又はコンテキスト情報をシグナリング領域に伝送するためである。
【０３６７】
カプセル化部分は、パケットを物理層に伝達するのに適した形態でカプセル化する動作を行うことができる。カプセル化部分は、ＩＰストリームの数だけ構成することができる。
【０３６８】
カプセル化バッファ（ｔｓｉｂ１５１７０）は、カプセル化のためにパケットストリームを受信する役割を果たすことができる。オーバーヘッド削減が行われた場合、オーバーヘッド削減されたパケットを受信し、オーバーヘッド削減が行われていない場合、入力されたＩＰパケットをそのまま受信することができる。
【０３６９】
カプセル化コントローラ（ｔｓｉｂ１５１８０）は、入力されたパケットストリームに対してカプセル化を行うか否かを決定することができる。カプセル化が行われる場合、パケットストリームは分割／連鎖（ｔｓｉｂ１５１９０）に伝達されてもよい。カプセル化が行われない場合、パケットストリームは伝送バッファ（ｔｓｉｂ１５２３０）に伝達されてもよい。パケットをカプセル化するか否かは、リンク層に伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってカプセル化コントローラ（ｔｓｉｂ１５１８０）に伝達されてもよい。
【０３７０】
分割／連鎖ブロック（ｔｓｉｂ１５１９０）では、パケットに対して、前述した分割又は連鎖作業を行うことができる。すなわち、入力されたＩＰパケットが、リンク層の出力であるリンク層パケットよりも長い場合、一つのＩＰパケットを分割して多数個のセグメントに分けて複数個のリンク層パケットペイロードを作ることができる。また、入力されたＩＰパケットが、リンク層の出力であるリンク層パケットよりも短い場合、複数個のＩＰパケットをつなげて一つのリンク層パケットペイロードを作ることができる。
【０３７１】
パケット構成テーブル（ｔｓｉｂ１５２００）は、分割及び／又は連鎖されたリンク層パケットの構成情報を有することができる。パケット構成テーブル（ｔｓｉｂ１５２００）の情報は、送信機と受信機が同じ情報を有することができる。パケット構成テーブル（ｔｓｉｂ１５２００）の情報が送信機と受信機で参照されてもよい。パケット構成テーブル（ｔｓｉｂ１５２００）の情報のインデックス値が当該リンク層パケットのヘッダーに含まれてもよい。
【０３７２】
リンク層ヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、カプセル化過程で発生するヘッダー情報を収集することができる。また、リンク層ヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、パケット構成テーブル（ｔｓｉｂ１５２００）が有する情報を収集することができる。リンク層ヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、リンク層パケットのヘッダーの構造に応じてヘッダー情報を構成することができる。
【０３７３】
ヘッダーアタッチメントブロック（ｔｓｉｂ１５２２０）は、分割及び／又は連鎖されたリンク層パケットのペイロードにヘッダーを追加することができる。伝送バッファ（ｔｓｉｂ１５２３０）は、リンク層パケットを物理層のＤＰ（ｔｓｉｂ１５２４０）に伝達するためのバッファの役割を果たすことができる。
【０３７４】
各ブロック乃至モジュール及び部分（ｐａｒｔ）は、リンク層において一つのモジュール／プロトコルとして構成されてもよく、複数個のモジュール／プロトコルとして構成されてもよい。
【０３７５】
図１６は、本発明の一実施例に係る受信機側のリンク層の構造を示した図である。
【０３７６】
本実施例は、ＩＰパケットを処理することを仮定した実施例である。受信機側のリンク層は、機能的な観点から、大きく、シグナリング情報を処理するリンク層シグナリング部分、オーバーヘッドプロセシング部分、及び／又はデカプセル化部分を含むことができる。また、受信機側のリンク層は、リンク層全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンク層の入出力部分などを含むことができる。
【０３７７】
まず、物理層を介して伝送された各情報がリンク層に伝達され得る。リンク層は、各情報を処理して、送信側で処理する前の元の状態に戻した後、上位層に伝達することができる。この実施例において、上位層はＩＰ層であってもよい。
【０３７８】
物理層で区分された特定のチャネル（ｔｓｉｂ１６０３０）を介して伝達された情報がリンク層シグナリング部分に伝達され得る。リンク層シグナリング部分は、物理層から受信されたシグナリング情報を判別し、リンク層の各部分に、判別されたシグナリング情報を伝達する役割を果たすことができる。
【０３７９】
チャネルのためのバッファ（ｔｓｉｂ１６０４０）は、特定のチャネルを介して伝送されたシグナリング情報を受信するバッファの役割を果たすことができる。前述したように、物理層に物理的／論理的に区分された別途のチャネルが存在する場合、そのチャネルを介して伝送されたシグナリング情報を受信することができる。別途のチャネルから受信した情報が分割された状態である場合、完全な形態の情報になるまで、分割された情報を格納することができる。
【０３８０】
シグナリングデコーダ／パーサ（ｔｓｉｂ１６０５０）は、特定のチャネルを介して受信されたシグナリング情報のフォーマットを確認し、リンク層で活用される情報を抽出することができる。特定のチャネルを介したシグナリング情報がエンコードされている場合にはデコーディングを行うことができる。また、実施例によって、当該シグナリング情報の無欠性などを確認してもよい。
【０３８１】
シグナリングマネジャー（ｔｓｉｂ１６０６０）は、多数の経路を介して受信されたシグナリング情報を統合することができる。後述するシグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して受信されたシグナリング情報もシグナリングマネジャー（ｔｓｉｂ１６０６０）で統合することができる。シグナリングマネジャー（ｔｓｉｂ１６０６０）は、リンク層内の各部分に必要なシグナリング情報を伝達することができる。例えば、オーバーヘッドプロセシング部分に、パケットのリカバリのためのコンテキスト情報などを伝達することができる。また、スケジューラ（ｔｓｉｂ１６０２０）に、制御のためのシグナリング情報を伝達することができる。
【０３８２】
シグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して、別途の特別なチャネルで受信されていない一般的なシグナリング情報が受信されてもよい。ここで、シグナリングのためのＤＰとは、ＰＬＳ又はＬ１などを意味し得る。ここで、ＤＰは、ＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）と呼ぶこともできる。受信バッファ（ｔｓｉｂ１６０８０）は、シグナリングのためのＤＰから伝送されたシグナリング情報を受信するバッファの役割を果たすことができる。シグナリング情報のデカプセル化ブロック（ｔｓｉｂ１６０９０）では、受信されたシグナリング情報をデカプセル化することができる。デカプセル化されたシグナリング情報は、デカプセル化バッファ（ｔｓｉｂ１６１００）を経てシグナリングマネジャー（ｔｓｉｂ１６０６０）に伝達されてもよい。前述したように、シグナリングマネジャー（ｔｓｉｂ１６０６０）は、シグナリング情報を組み合わせてリンク層内の必要な部分に伝達することができる。
【０３８３】
スケジューラ（ｔｓｉｂ１６０２０）は、リンク層に含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。スケジューラ（ｔｓｉｂ１６０２０）は、受信機情報（ｔｓｉｂ１６０１０）及び／又はシグナリングマネジャー（ｔｓｉｂ１６０６０）から伝達された情報を用いて、リンク層の各部分を制御することができる。また、スケジューラ（ｔｓｉｂ１６０２０）は、各部分の動作モードなどを決定することができる。ここで、受信機情報（ｔｓｉｂ１６０１０）は、受信機が予め格納していた情報を意味し得る。スケジューラ（ｔｓｉｂ１６０２０）は、チャネル切り替えなどのようにユーザが変更する情報も用いて、制御に活用することができる。
【０３８４】
デカプセル化部分は、物理層のＤＰ（ｔｓｉｂ１６１１０）から受信されたパケットをフィルタし、当該パケットのタイプに応じてパケットを分離する役割を果たすことができる。デカプセル化部分は、物理層で同時にデコードできるＤＰの数だけ構成することができる。
【０３８５】
デカプセル化バッファ（ｔｓｉｂ１６１１０）は、デカプセル化のために物理層からパケットストリームを受信するバッファの役割を果たすことができる。デカプセル化コントローラ（ｔｓｉｂ１６１３０）は、入力されたパケットストリームに対してデカプセル化を行うか否かを決定することができる。デカプセル化が行われる場合、パケットストリームはリンク層ヘッダーパーサ（ｔｓｉｂ１６１４０）に伝達されてもよい。デカプセル化が行われない場合、パケットストリームは出力バッファ（ｔｓｉｂ１６２２０）に伝達されてもよい。デカプセル化を行うか否かを決定するにおいて、スケジューラ（ｔｓｉｂ１６０２０）から伝達されたシグナリング情報を活用することができる。
【０３８６】
リンク層ヘッダーパーサ（ｔｓｉｂ１６１４０）は、伝達されたリンク層パケットのヘッダーを確認することができる。ヘッダーを確認することによって、リンク層パケットのペイロードに含まれているＩＰパケットの構成を確認することができる。例えば、ＩＰパケットは、分割されているか、又は連鎖されていてもよい。
【０３８７】
パケット構成テーブル（ｔｓｉｂ１６１５０）は、分割及び／又は連鎖で構成されるリンク層パケットのペイロード情報を含むことができる。パケット構成テーブル（ｔｓｉｂ１６１５０）の情報は、送信機と受信機が同じ情報を有することができる。パケット構成テーブル（ｔｓｉｂ１６１５０）の情報が送信機と受信機で参照されてもよい。リンク層パケットに含まれたインデックス情報に基づいて、再結合（ｒｅａｓｓｅｍｂｌｙ）に必要な値を見つけることができる。
【０３８８】
再結合ブロック（ｒｅａｓｓｅｍｂｌｙ）（ｔｓｉｂ１６１６０）は、分割及び／又は連鎖で構成されたリンク層パケットのペイロードを元のＩＰストリームのパケットとして構成することができる。セグメントを一つに集めて一つのＩＰパケットとして再構成したり、連鎖されたパケットを分離して複数個のＩＰパケットストリームとして再構成したりすることができる。再結合されたＩＰパケットは、オーバーヘッドプロセシング部分に伝達されてもよい。
【０３８９】
オーバーヘッドプロセシング部分は、送信機で行われたオーバーヘッド削減の逆過程として、オーバーヘッド削減されたパケットを元のパケットに戻す動作を行うことができる。この動作をオーバーヘッドプロセシングと呼ぶことができる。オーバーヘッドプロセシング部分は、物理層で同時にデコードできるＤＰの数だけ構成することができる。
【０３９０】
パケットリカバリバッファ（ｔｓｉｂ１６１７０）は、オーバーヘッドプロセシングを行うためにデカプセル化されたＲｏＨＣパケット乃至ＩＰパケットを受信するバッファの役割を果たすことができる。
【０３９１】
オーバーヘッドコントローラ（ｔｓｉｂ１６１８０）は、デカプセル化されたパケットに対してパケットリカバリ及び／又は圧縮解除を行うか否かを決定することができる。パケットリカバリ及び／又は圧縮解除が行われる場合、パケットストリームリカバリブロック（ｔｓｉｂ１６１９０）にパケットが伝達されてもよい。パケットリカバリ及び／又は圧縮解除が行われない場合、パケットは出力バッファ（ｔｓｉｂ１６２２０）に伝達されてもよい。パケットリカバリ及び／又は圧縮解除を行うか否かは、スケジューラ（ｔｓｉｂ１６０２０）によって伝達されたシグナリング情報に基づいて決定されてもよい。
【０３９２】
パケットストリームリカバリブロック（ｔｓｉｂ１６１９０）は、送信機で分離されたパケットストリームと、パケットストリームのコンテキスト情報とを統合する動作を行うことができる。これは、ＲｏＨＣデコンプレッサ（ｔｓｉｂ１６２１０）で処理可能なように、パケットストリームを復旧する過程であり得る。この過程で、シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１６２００）からシグナリング情報及び／又はコンテキスト情報を受信することができる。シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１６２００）は、送信機から伝達されたシグナリング情報を判別し、当該コンテキストＩＤに合うストリームにマップできるようにパケットストリームリカバリブロック（ｔｓｉｂ１６１９０）にシグナリング情報を伝達することができる。
【０３９３】
ＲｏＨＣデコンプレッサ（ｔｓｉｂ１６２１０）は、パケットストリームのパケットのヘッダーを復旧することができる。パケットストリームのパケットは、ヘッダーが復旧されることによって元のＩＰパケットの形態に復旧され得る。すなわち、ＲｏＨＣデコンプレッサ（ｔｓｉｂ１６２１０）はオーバーヘッドプロセシングを行うことができる。
【０３９４】
出力バッファ（ｔｓｉｂ１６２２０）は、ＩＰ層（ｔｓｉｂ１６２３０）に出力ストリームを伝達するに先立ち、バッファの役割を果たすことができる。
【０３９５】
本発明が提案する送信機と受信機のリンク層は、前述したようなブロック乃至モジュールを含むことができる。これを通じて、リンク層が上位層と下位レイヤに関係なく独立して動作することができ、オーバーヘッド削減を効率的に行うことができ、上／下位層などによって支援可能な機能の確定／追加／除去が容易となり得る。
【０３９６】
図１７は、本発明の一実施例に係る、リンク層を介したシグナリング伝送構造を示した図である（送／受信側）。
【０３９７】
本発明では、一つの周波数バンド内に複数個のサービスプロバイダ（放送会社）がサービスを提供することができる。また、サービスプロバイダは、複数個のサービスを伝送することができ、一つのサービスは１つ以上のコンポーネントを含むことができる。ユーザは、サービス単位でコンテンツを受信することを考慮することができる。
【０３９８】
本発明は、ＩＰハイブリッド放送を支援するために、複数個のセッションベースの伝送プロトコルが使用されることを仮定する。各プロトコルの伝送構造に基づいて、そのシグナリング経路（ｐａｔｈ）で伝達されるシグナリング情報を決定することができる。各プロトコルは、実施例によって様々な名称が付与されてもよい。
【０３９９】
図示された送信側のデータ構造（ｔｓｉｂ１７０１０）において、サービスプロバイダ（Ｂｒｏａｄｃａｓｔｅｒｓ）は複数個のサービス（Ｓｅｒｖｉｃｅ  ＃１，＃２，…）を提供することができる。一般に、サービスに対するシグナリングは、一般的な伝送セッションを介して伝送することができるが（Ｓｉｇｎａｌｉｎｇ  Ｃ）、実施例によって、特定のセッション（ｄｅｄｉｃａｔｅｄ  ｓｅｓｓｉｏｎ）を介して伝送してもよい（Ｓｉｇｎａｌｉｎｇ  Ｂ）。
【０４００】
サービスデータ及びサービスシグナリング情報は、伝送プロトコルに従ってカプセル化することができる。実施例によってＩＰ／ＵＤＰが使用されてもよい。実施例によってＩＰ／ＵＤＰ層でのシグナリング（Ｓｉｇｎａｌｉｎｇ  Ａ）が追加されてもよい。このシグナリングは省略できる。
【０４０１】
ＩＰ／ＵＤＰで処理されたデータはリンク層に入力されてもよい。リンク層では、前述したように、オーバーヘッド削減及び／又はカプセル化過程を行うことができる。ここで、リンク層シグナリングが追加されてもよい。リンク層シグナリングにはシステムパラメータなどが含まれてもよい。リンク層シグナリングについては前述した。
【０４０２】
このような処理を経たサービスデータ及びシグナリング情報は、物理層でＰＬＰを介して処理されてもよい。ここで、ＰＬＰはＤＰと呼ぶこともできる。図示された実施例では、ベースＤＰ／ＰＬＰが使用される場合を想定しているが、実施例によってベースＤＰ／ＰＬＰなしに一般的なＤＰ／ＰＬＰのみで伝送が行われてもよい。
【０４０３】
図示された実施例では、ＦＩＣ、ＥＡＣなどの特定のチャネル（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）が使用されている。ＦＩＣを介して伝達されるシグナリングをＦＩＴ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）、ＥＡＣを介して伝達されるシグナリングをＥＡＴ（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔ  Ｔａｂｌｅ）と呼ぶことができる。ＦＩＴは、前述したＳＬＴと同一であってもよい。このような特定のチャネルは、実施例によって使用されなくてもよい。特定のチャネル（Ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）が構成されていない場合、ＦＩＴとＥＡＴは、一般的なリンク層シグナリング伝送方法によって伝送されるか、又は他のサービスデータのようにＩＰ／ＵＤＰを経てＰＬＰに伝送されてもよい。
【０４０４】
実施例によって、システムパラメータには、送信機関連パラメータ、サービスプロバイダ関連パラメータなどが含まれてもよい。リンク層シグナリングには、ＩＰヘッダー圧縮関連コンテキスト情報、及び／又は当該コンテキストが適用されるデータに対する識別情報が含まれてもよい。上位層のシグナリングには、ＩＰ住所、ＵＤＰ番号、サービス／コンポーネント情報、緊急警報（Ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ）関連情報、サービスシグナリングに対するＩＰ／ＵＤＰ住所、セッションＩＤなどが含まれてもよい。詳細な実施例については前述した。
【０４０５】
図示された受信側のデータ構造（ｔｓｉｂ１７０２０）において、受信機は、全てのＰＬＰをデコードすることなく、シグナリング情報を活用して当該サービスに対するＰＬＰのみをデコードすることができる。
【０４０６】
まず、ユーザが、受信しようとするサービスを選択又は変更すると、受信機は、当該周波数にチューニングをし、当該チャネルと関連してＤＢなどに格納している受信機情報を読み込むことができる。受信機のＤＢなどに格納されている情報は、最初のチャネルスキャンの際にＳＬＴを読み込んで構成されてもよい。
【０４０７】
ＳＬＴを受信し、当該チャネルの情報を受信した後、既存に格納されていたＤＢを更新し、ユーザが選択したサービスの伝送経路及びコンポーネント情報を取得したり、このような情報を取得するために必要なシグナリングが伝送される経路に対する情報を取得したりする。ＳＬＴのバージョン情報などを用いて、当該情報の変更がないと判断される場合には、デコーディング又はパーシング手順を省略することができる。
【０４０８】
受信機は、当該放送ストリームにおいて、ＰＬＰの物理シグナリングをパースし、当該ＰＬＰ内にＳＬＴ情報があるかどうかを把握することができる（図示せず）。これは、物理シグナリングの特定のフィールドを介して指示されてもよい。ＳＬＴ情報に接近することによって、特定のサービスのサービス層シグナリングが伝送される位置に接近することができる。このサービス層シグナリングは、ＩＰ／ＵＤＰにカプセル化されて伝送セッションを介して伝達されてもよい。このサービス層シグナリングを用いて、当該サービスを構成するコンポーネントに対する情報を取得することができる。詳細なＳＬＴ−ＳＬＳの構造は、前述した通りである。
【０４０９】
すなわち、ＳＬＴを用いて、現在のチャネルに伝送されている多数のパケットストリーム及びＰＬＰのうち、当該サービスの受信に必要な上位層シグナリング情報（サービスシグナリング情報）を受信するための伝送経路情報を取得することができる。この伝送経路情報には、ＩＰ住所、ＵＤＰポート番号、セッションＩＤ、ＰＬＰ  ＩＤなどが含まれてもよい。ここで、実施例によって、ＩＰ／ＵＤＰ住所は、ＩＡＮＡ又はシステムで予め指定されている値を使用してもよい。このような情報は、ＤＢ及び共有メモリ接近などの方法で取得されてもよい。
【０４１０】
リンク層シグナリングとサービスデータが同一のＰＬＰを介して伝送されるか、又は一つのＰＬＰのみが運用されている場合、ＰＬＰを介して伝達されるサービスデータは、リンク層シグナリングがデコードされる間、臨時にバッファなどの装置に格納されてもよい。
【０４１１】
受信しようとするサービスに対するサービスシグナリング情報を用いて、当該サービスが実際に伝送される経路の情報を取得することができる。また、受信するＰＬＰに対するオーバーヘッド削減などの情報を用いて、受信されるパケットストリームに対してデカプセル化及びヘッダーリカバリを行うことができる。
【０４１２】
図示された実施例（ｔｓｉｂ１７０２０）では、ＦＩＣ、ＥＡＣが使用され、ベースＤＰ／ＰＬＰの概念が想定された。前述したように、ＦＩＣ、ＥＡＣ、ベースＤＰ／ＰＬＰの概念は活用されなくてもよい。
【０４１３】
以下では、説明の便宜のためにＭＩＳＯ又はＭＩＭＯ方式は２つのアンテナを使用するが、本発明は、２つ以上のアンテナを使用するシステムに適用されてもよい。本発明は、特定用途に要求される能力を達成しながら、受信機の複雑度を最小化するために最適化された物理プロファイル（又は、システム）を提案する。本発明の一実施例に係る物理プロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）は、該当する受信機が具現しなければならない全ての構造のサブセットであり、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。システム発展のために、ヒューチャープロファイルは、ＦＥＦ（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を介して、単一ＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクスされてもよい。本発明の一実施例に係るベースプロファイル及びハンドヘルドプロファイルは、ＭＩＭＯが適用されないプロファイルを意味し、アドバンスドプロファイルは、ＭＩＭＯが適用されるプロファイルを意味する。ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別できる。そして、本発明のプロファイルは、設計者の意図によって変更されてもよい。
【０４１４】
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。
【０４１５】
補助ストリーム：ヒューチャー拡張（ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ、将来の拡張）のために又は放送社やネットワーク運営者の要求によって用い得るまだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
【０４１６】
ベースデータパイプ（ｂａｓｅ  ｄａｔａ  ｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ
【０４１７】
ベースバンドフレーム（又は、ＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
【０４１８】
セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値
【０４１９】
コーディングブロック（ｃｏｄｅｄ  ｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコードされたブロック又はＰＬＳ２データのＬＤＰＣエンコードされたブロックのうちの一つ
【０４２０】
データパイプ（ｄａｔａ  ｐｉｐｅ）：１つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連したメタデータを伝達する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）における論理チャネル
【０４２１】
データパイプユニット（ＤＰＵ，ｄａｔａ  ｐｉｐｅ  ｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット
【０４２２】
データシンボル（ｄａｔａ  ｓｙｍｂｏｌ）：プリアンブルシンボルでないフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）
【０４２３】
ＤＰ＿ＩＤ：当該８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されたシステム内でデータパイプを唯一に識別する。
【０４２４】
ダミーセル（ｄｕｍｍｙ  ｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために使用されずに残っている容量を満たすために用いられる擬似ランダム値を伝達するセル
【０４２５】
ＥＡＣ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部
【０４２６】
フレーム（ｆｒａｍｅ）：プリアンブルから始まってフレームエッジシンボルで終了する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【０４２７】
フレーム反復単位（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む、同一の又は異なる物理プロファイルに属するフレームの集合
【０４２８】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ、高速情報チャネル）：サービスと当該ベースデータパイプとの間におけるマッピング情報を伝達するフレームでの論理チャネル
【０４２９】
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコードされたビットの集合
【０４３０】
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同じ特定モードに用いられる名目上のＦＦＴサイズ
【０４３１】
フレームシグナリングシンボル（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、保護区間（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定組合せにおいてフレームの先頭で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【０４３２】
フレームエッジシンボル（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）：ＦＦＴサイズ、保護区間、及びスキャッタパイロットパターンの特定組合せにおいてフレームの末尾で用いられるより高いパイロット密度を有するＯＦＤＭシンボル
【０４３３】
フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームにおいて同じ物理プロファイルタイプを有する全てのフレームの集合
【０４３４】
ヒューチャー拡張フレーム（ｆｕｔｕｒｅ  ｅｘｔｅｎｔｉｏｎ  ｆｒａｍｅ、将来の拡張フレーム）：プリアンブルで始まる、将来の拡張に用いられ得るスーパーフレーム内での物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）タイムスロット
【０４３５】
ヒューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである提案された物理層放送システム
【０４３６】
入力ストリーム（ｉｎｐｕｔ  ｓｔｒｅａｍ）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム
【０４３７】
正常（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除くデータシンボル
【０４３８】
物理プロファイル（ＰＨＹ  ｐｒｏｆｉｌｅ）：該当する受信機が具現すべき全ての構造のサブセット
【０４３９】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理層シグナリングデータ
【０４４０】
ＰＬＳ１：ＰＬＳ２をデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｌｉｎｇ  ｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合
【０４４１】
ＮＯＴＥ：ＰＬＳ１データはフレームグループのデューレーション（ｄｕｒａｔｉｏｎ）において一定である。
【０４４２】
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳで伝送されるＰＬＳデータの二番目の集合
【０４４３】
ＰＬＳ２動的（ｄｙｎａｍｉｃ）データ：フレームごとに動的に変化するＰＬＳ２データ
【０４４４】
ＰＬＳ２静的（ｓｔａｔｉｃ）データ：フレームグループのデューレーションにおいて静的であるＰＬＳ２データ
【０４４５】
プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅ  ｓｉｇｎａｌｉｎｇ  ｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ
【０４４６】
プリアンブルシンボル（ｐｒｅａｍｂｌｅ  ｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達し、フレームの先頭に位置する固定された長さのパイロットシンボル
【０４４７】
プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に用いられる。
【０４４８】
将来の使用（ｆｕｔｕｒｅ  ｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書では定義されないが、将来に定義可能である。
【０４４９】
スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合
【０４５０】
時間インターリービングブロック（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｂｌｏｃｋ、ＴＩ  ｂｌｏｃｋ）：時間インターリーバメモリーの一つの用途に該当する、時間インターリービングが実行されるセルの集合
【０４５１】
時間インターリービンググループ（ｔｉｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ  ｇｒｏｕｐ，ＴＩ  ｇｒｏｕｐ）：整数、動的に変化するＸＦＥＣＢＬＯＣＫの数で構成された、特定データパイプに対する動的容量割り当てが実行される単位
【０４５２】
ＮＯＴＥ：時間インターリービンググループは一つのフレームに直接マップされてもよく、複数のフレームにマップされてもよい。時間インターリービンググループは、一つ以上の時間インターリービングブロックを含むことができる。
【０４５３】
タイプ１データパイプ（Ｔｙｐｅ  １  ＤＰ）：全てのデータパイプがフレームにＴＤＭ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマップされるフレームのデータパイプ
【０４５４】
タイプ２データパイプ（Ｔｙｐｅ  ２  ＤＰ）：全てのデータパイプがフレームにＦＤＭ方式でマップされるフレームのデータパイプ
【０４５５】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ  ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮcellsセルの集合
【０４５６】
図１８は、本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置の構造を示す。
【０４５７】
本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置は、入力フォーマットブロック（Ｉｎｐｕｔ  Ｆｏｒｍａｔ  ｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック（ＯＦＤＭ  ｇｅｎｅｒａｔｉｏｎ  ｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【０４５８】
本発明の一実施例に係る入力データは、ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳを主要な入力フォーマットとすることができ、他のストリームタイプは一般ストリームとして扱う。これらのデータ入力に加えて、管理情報が入力され、各入力ストリームに対する当該帯域幅のスケジューリング及び割り当てを制御する。また本発明では、一つ又は複数のＴＳストリーム、ＩＰストリーム及び／又は一般ストリーム入力が同時に許容される。
【０４５９】
入力フォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される一つ又は複数のデータパイプにデマチルプレクスすることができる。データパイプは堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に影響を及ぼす。一つ又は複数のサービス又はサービスコンポーネントを一つのデータパイプによって伝達することができる。データパイプは、一つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連メタデータを伝達する物理層における論理チャネルである。
【０４６０】
また、データパイプユニットは、一つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【０４６１】
物理層への入力は、一つ又は複数のデータストリームで構成されてもよい。それぞれのデータストリームは、一つのデータパイプによって伝達される。入力フォーマットブロック１０００は、一つ又はそれ以上の物理的経路（ｐｈｙｓｉｃａｌ  ｐａｔｈ又はＤＰ）を介して入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄ  ｆｒａｍｅ）に変換することができる。この場合、入力フォーマットブロック１０００は、入力データ（ＴＳ又はＩＰ入力ストリーム）に対して伝送効率を増加させるためにヌルパケット削除（ｎｕｌｌ  ｐａｃｋｅｔ  ｄｅｌｅｔｉｏｎ）又はヘッダー圧縮（ｈｅａｄｅｒ  ｃｏｍｐｒｅｓｓｉｏｎ）を行うことができる。受信機は、ヘッダーの特定部分に対する先験的な（ａ  ｐｒｉｏｒｉ）情報を有することができることから、この知られた情報（ｋｎｏｗｎ  ｉｎｆｏｒｍａｔｉｏｎ）は送信機で削除されてもよい。ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームの場合にのみ利用可能である。
【０４６２】
ＢＩＣＭブロック１０１０で、パリティ（ｐａｒｉｔｙ）データは誤り訂正のために追加され、エンコードされたビットストリームは複素数値星状シンボルにマップされる。当該シンボルは当該データパイプに用いられる特定インターリービング深さにわたってインターリーブされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。
【０４６３】
フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマップし、周波数領域ダイバーシティのために、特に、周波数選択的フェーディングチャネルを防止するために周波数インターリービングを行うことができる。フレームビルディングブロックは、遅延補償（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ）ブロック、セルマッパー（ｃｅｌｌ  ｍａｐｐｅｒ）及び周波数インターリーバ（ｆｒｅｑｕｅｎｃｙ  ｉｎｔｅｒｌｅａｖｅｒ）を含むことができる。
【０４６４】
遅延補償（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ）ブロックは、データパイプと該当するＰＬＳデータとの間のタイミングを調節して、送信機側でデータパイプと該当するＰＬＳデータとの間の同時性（ｃｏ−ｔｉｍｅ）を保障することができる。入力フォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことにより、ＰＬＳデータはデータパイプの分だけ遅れる。ＢＩＣＭブロックの遅延は主に時間インターリーバに起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次の時間インターリービンググループの情報を、シグナルされるデータパイプよりも１フレーム先立って伝達されるようにすることができる。遅延補償（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ）ブロックは、それに合わせてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。
【０４６５】
セルマッパーは、ＰＬＳ、データパイプ、補助ストリーム、及びダミーセルなどを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップすることができる。セルマッパーの基本機能は、それぞれのデータパイプ、ＰＬＳセルに対する時間インターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマップすることである。（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集されてデータパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成された動的情報（ｄｙｎａｍｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）に応じて動作する。周波数インターリーバは、セルマッパーから受信されたデータセルをランダムにインターリーブして周波数ダイバーシティを提供することができる。また、周波数インターリーバは、単一フレームで最大のインターリービング利得を得るために、異なるインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（ｐａｉｒ、対）で動作することができる。
【０４６６】
ＯＦＤＭ生成ブロック１０３０は、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは順次に保護区間を挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
【０４６７】
具体的には、プリアンブルを各フレームの先頭に挿入した後、ＯＦＤＭ生成ブロック１０３０は、サイクリックプレフィックス（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）を保護区間として有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシティのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、本発明は、様々なＦＦＴサイズ、保護区間長さ、当該パイロットパターンの集合を提供する。
【０４６８】
また、本発明は、放送サービスを提供する２つ以上の異なる放送送信／受信システムのデータが同じＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクスすることができる。この場合、２つ以上の異なる放送送信／受信システムは、それぞれ異なる放送サービスを提供するシステムのことをいう。それぞれ異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。
【０４６９】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように伝送される。本発明の一実施例に係るシグナリング情報は、ＰＬＳデータを含むことができる。ＰＬＳは、受信機で物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）データパイプに接続し得る手段を提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。
【０４７０】
ＰＬＳ１データは、ＰＬＳ２データをデコードするために必要なパラメータの他、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームにおいてＦＳＳで伝達される、ＰＬＳデータの一番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするために要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグループのデューレーションにおいて一定である。
【０４７１】
ＰＬＳ２データは、データパイプ及びシステムに関するより一層詳細なＰＬＳデータを伝達するＦＳＳで伝送される、ＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコードするのに十分な情報を提供するパラメータを含む。さらに、ＰＬＳ２シグナリングは、ＰＬＳ２静的（ｓｔａｔｉｃ）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２動的（ｄｙｎａｍｉｃ）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータで構成される。ＰＬＳ２静的（ｓｔａｔｉｃ）データは、フレームグループのデューレーションの間に静的（ｓｔａｔｉｃ）であるＰＬＳ２データであり、ＰＬＳ２動的（ｄｙｎａｍｉｃ）データは、フレームごとに動的（ｄｙｎａｍｉｃ）に変化するＰＬＳ２データである。ＰＬＳデータに関する詳細な内容は後述する。
【０４７２】
前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックによって代替されてもよい。
【０４７３】
図１９は、本発明の一実施例に係るＢＩＣＭブロックを示す。
【０４７４】
図１９に示すＢＩＣＭブロックは、図１８を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０４７５】
前述したように、本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０４７６】
ＱｏＳが、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータは、それぞれ異なる方式で処理されなければならない。したがって、本発明の一実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することによって、各データパイプを独立して処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプを介して伝送される各サービス又はサービスコンポーネントに対するＱｏＳを調節することができる。
【０４７７】
（ａ）は、ＭＩＭＯが適用されないプロファイル（又は、システム）に適用されるＢＩＣＭブロックを示し、（ｂ）は、ＭＩＭＯが適用されるプロファイル（又は、システム）のＢＩＣＭブロックを示す。
【０４７８】
ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０４７９】
ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックのそれぞれの処理ブロックについて説明する。
【０４８０】
ＭＩＭＯが適用されないＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、星状マッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、時間インターリーバ５０５０を含むことができる。
【０４８１】
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は、選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作については後述する。
【０４８２】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながら、データＦＥＣエンコーダ５０１０の出力をインターリーブして、ＬＤＰＣコード及び変調方式の組合せによって最適化した能力を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
【０４８３】
星状マッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４，ＮＵＱ−２５６，ＮＵＱ−１０２４）又は不均一星状（ＮＵＣ−１６，ＮＵＣ−６４，ＮＵＣ−２５６，ＮＵＣ−１０２４）を用いて、ベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調して、電力の正規化された星状ポイントｅlを提供することができる。当該星状マッピングは、データパイプに対してのみ適用される。ＮＵＱは任意の形態を有するが、ＱＡＭ−１６及びＮＵＱは正方形の形状を有することが観察される。それぞれの星状が９０°の倍数だけ回転すると、回転された星状は、元来のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均電力が互いに同一になる。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ  ｒａｔｅ）に対して特別に定義され、用いられるいずれか一つは、ＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによってシグナルされる。
【０４８４】
時間インターリーバ５０５０は、データパイプレベルで動作することができる。時間インターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定されてもよい。時間インターリーバ５０５０の具体的な動作に関しては後述する。
【０４８５】
ＭＩＭＯが適用されるＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、星状マッパー、及び時間インターリーバを含むことができる。
【０４８６】
ただし、処理ブロック５０００−１は、セルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で、ＭＩＭＯの適用されないＢＩＣＭの処理ブロック５０００と区別される。
【０４８７】
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、星状マッパー、時間インターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、星状マッパー５０３０、時間インターリーバ５０５０の動作に該当するので、その説明は省略する。
【０４８８】
セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。
【０４８９】
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いて、セルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号送信のために最適化されている。ＭＩＭＯ技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に、放送に対して、異なる信号電波特性による２つのアンテナ間の受信信号電力差又はチャネルの強いＬＯＳコンポーネントは、ＭＩＭＯから容量利得を得ることを難しくさせる。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの一つの位相ランダム化及び回転ベースのプリコーディングを用いてこの問題を克服する。
【０４９０】
ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２×２ＭＩＭＯシステムのために意図される。本発明のＭＩＭＯエンコーディングモードは、ＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）と定義できる。ＦＲ−ＳＭエンコーディングは、受信機側における比較的小さい複雑度の増加で容量増加を提供することができる。また、本発明のＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。
【０４９１】
ＭＩＭＯ処理は、データパイプレベルで適用される。星状マッパー出力のペア（ｐａｉｒ、対）であるＮＵＱ（ｅ1,i及びｅ2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（ｐａｉｒ、対）（ｇ１，ｉ及びｇ２，ｉ）は、それぞれの送信アンテナの同じキャリアｋ及びＯＦＤＭシンボルｌによって伝送される。
【０４９２】
前述したブロックは、省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０４９３】
図２０は、本発明の他の実施例に係るＢＩＣＭブロックを示す。
【０４９４】
図２０に示す、ＢＩＣＭブロックは、図１８を参照して説明したＢＩＣＭブロック１０１０の一実施例に該当する。
【０４９５】
図２０は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおける論理チャネルである。ＥＡＣ及びＦＩＣに関する詳細な説明は後述する。
【０４９６】
図２０を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ  ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及び星状マッパー６０２０を含むことができる。
【０４９７】
また、ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブラ、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックについて説明する。
【０４９８】
ＰＬＳ  ＦＥＣエンコーダ６０００は、スクランブルされたＰＬＳ１／２データ、ＥＡＣ及びＦＩＣセクションをエンコードすることができる。
【０４９９】
スクランブラは、ＢＣＨエンコーディング及び短縮（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャリングが行われたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。
【０５００】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のための短縮されたＢＣＨコードを用いて、スクランブルされたＰＬＳ  １／２データに外部エンコーディングを行い、ＢＣＨエンコーディング後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディング前にパーミュテート（ｐｅｒｍｕｔａｔｉｏｎ）することができる。
【０５０１】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコーディングをすることができる。完全なコーディングブロックを生成するために、Ｃldpc及びパリティビットＰldpcは、それぞれのゼロが挿入されたＰＬＳ情報ブロックＩldpcから組織的にエンコードされ、その後に付加される。
【０５０２】
【数１】
0006449897.tif 000002
【０５０３】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０５０４】
短縮がＰＬＳ１データ保護に適用されると、一部のＬＤＰＣパリティビットは、ＬＤＰＣエンコーディング後にパンクチャされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディング後にパンクチャされる。これらのパンクチャされたビットは伝送されない。
【０５０５】
ビットインターリーバ６０１０は、それぞれの短縮及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブすることができる。
【０５０６】
星状マッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データを星状にマップすることができる。
【０５０７】
前述したブロックは、省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。
【０５０８】
図２１は、本発明の一実施例に係るＰＬＳのビットインターリービング過程を示す図である。
【０５０９】
それぞれの短縮及びパンクチャされたＰＬＳ１及びＰＬＳ２コーディングブロックは、図２１に示すように、１ビットずつインターリーブされる。追加パリティビットの各ブロックは、同じブロックインターリービング構造でインターリーブされるが、別途にインターリーブされる。
【０５１０】
ＢＰＳＫの場合、実数及び虚数の部分でＦＥＣコーディングビットを複製するために、ビットインターリービングのための２つのブランチが存在する。それぞれのコーディングブロックは、上位ブランチにまず書き込まれる。ビットは、サイクリックシフト値フロアー（ＮFEC／２）でモジュロＮFEC加算を適用することによって、下位ブランチにマッチされる。ここで、ＮFECは、短縮及びパンクチャリング後のそれぞれのＬＤＰＣコーディングブロックの長さである。
【０５１１】
ＱＳＰＫ、ＱＡＭ−１６、ＮＵＱ−６４のような他の変調の場合、ＦＥＣコーディングビットは列方向に順次にインターリーバに書き込まれる。ここで、列の数は変調次数と同一である。
【０５１２】
読み出し動作で、一つの星状シンボルに対するビットは順次に行方向に読み出され、ビットデマルチプレクサブロックに入力される。これらの動作は列の最後まで続く。
【０５１３】
それぞれのビットインターリービンググループは、星状マッピング前にグループで１ビットずつデマチルプレクスされる。変調次数によって、２つのマッピング規則がある。ＢＰＳＫ及びＱＰＳＫの場合、一つのシンボルにおいてビットの信頼度は同一である。したがって、ビットインターリービングブロックから読み出されたビットグループは、いかなる動作無しでＱＡＭシンボルにマッチされる。
【０５１４】
ＱＡＭシンボルにマップされたＱＡＭ−１６及びＮＵＱ−６４の場合、動作の規則が図２１（ａ）に説明されている。図２１（ａ）に示すように、ｉは、ビットインターリービングにおいて列インデックスに該当するビットグループインデックスである。
【０５１５】
図２１は、ＱＡＭ−１６に対するビットデマチルプレクシング規則を示す。この動作は、全てのビットグループがビットインターリービングブロックから読み出されるまで続く。
【０５１６】
図２２は、本発明の一実施例に係る、次世代放送サービスに対する放送信号受信装置の構造を示す。
【０５１７】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１８を参照して説明した、次世代放送サービスに対する放送信号送信装置に対応し得る。
【０５１８】
本発明の一実施例に係る、次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ＆  ｄｅｍｏｄｕｌａｔｉｏｎ  ｍｏｄｕｌｅ）９０００、フレームパーシングモジュール（ｆｒａｍｅ  ｐａｒｓｉｎｇ  ｍｏｄｕｌｅ）９０１０、デマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ  ＆  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０２０、出力プロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）９０３０、及びシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇ  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
【０５１９】
同期及び復調モジュール９０００は、ｍ個の受信アンテナから入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆過程に該当する復調を実行することができる。
【０５２０】
フレームパーシングモジュール９０１０は、入力信号フレームをパースし、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行していると、フレームパーシングモジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるへき信号及びデータの位置を、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることで取得し、放送信号送信装置によって生成されたスケジューリング情報を復元することができる。
【０５２１】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によって、ビット領域データをデインターリーブすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングによって伝送チャネルで発生した誤りを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコードすることによって、デマッピング及びデコーディングのために必要な伝送パラメータを取得することができる。
【０５２２】
出力プロセッサ９０３０は、伝送効率を向上させるために放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆過程を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を取得することができる。出力プロセッサ９０３０の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４又はｖ６）及びＧＳであってもよい。
【０５２３】
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０５２４】
本発明の一実施例に係るフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、正常データシンボル、及びＦＥＳを含む。
【０５２５】
プリアンブルは、高速ヒューチャーキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルに関する詳細な内容は後述する。
【０５２６】
ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、それによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、正常データシンボルよりも高密度のパイロットパターンを有する。ＦＥＳは、ＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳの直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しに、ＦＥＳ内における周波数だけの補間（ｉｎｔｅｒｐｏｌａｔｉｏｎ）及び時間的補間（ｔｅｍｐｏｒａｌ  ｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。
【０５２７】
図２３は、本発明の一実施例に係る、フレームのシグナリング階層構造（ｓｉｇｎａｌｉｎｇ  ｈｉｅｒａｒｃｈｙ  ｓｔｒｕｃｔｕｒｅ）を示す。
【０５２８】
図２３は、シグナリング階層構造を示しているが、これは、３つの主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコードできるようにする。ＰＬＳ２は、毎フレームごとに伝達され、２つの主要部分である、ＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データの静的（ｓｔａｔｉｃ）及び動的（ｄｙｎａｍｉｃ）部分には、必要時にパディングが続く。
【０５２９】
本発明の一実施例に係るプリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳細な内容は、次のとおりである。
【０５３０】
ＦＦＴ＿ＳＩＺＥ：当該２ビットフィールドは、下記の表１で説明しているとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。
【０５３１】
【表１】
0006449897.tif 000003
【０５３２】
ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表２で説明しているとおり、現スーパーフレームにおける保護区間の一部（ｆｒａｃｔｉｏｎ）の値を示す。
【０５３３】
【表２】
0006449897.tif 000004
【０５３４】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームに提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームに提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドは、スーパーフレーム内で動的（ｄｙｎａｍｉｃ）に切り替えることができる。
【０５３５】
ＰＩＬＯＴ＿ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードか又は固定モードかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。
【０５３６】
ＰＡＰＲ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅ  ｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。
【０５３７】
ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来の使用のためにリザーブされる。
【０５３８】
図２４は、本発明の一実施例に係るＰＬＳ１データを示す。
【０５３９】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含む基本伝送パラメータを提供する。前述したように、ＰＬＳ１データは、一つのフレームグループの全体のデューレーションにおいて変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は、次のとおりである。
【０５４０】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：当該２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧを除いたプリアンブルシグナリングデータのコピーである。
【０５４１】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：当該２ビットフィールドは、ＦＲＵ当たりのフレームの数を示す。
【０５４２】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表３に示すようにシグナルされる。
【０５４３】
【表３】
0006449897.tif 000005
【０５４４】
ＮＵＭ＿ＦＳＳ：当該２ビットフィールドは、現フレームでＦＳＳの数を示す。
【０５４５】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０５４６】
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は互換不可能な変化を表す。デフォルト値は、００００である。当該標準で記述されたバージョンに対して、値が００００に設定される。
【０５４７】
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは、副バージョン情報を示す。副バージョンフィールドにおける変化は互換可能である。
【０５４８】
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワークで地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジは、ヒューチャーキャストＵＴＢシステム当たりに用いられる周波数の数によって一つ以上の周波数で構成され得る。ＣＥＬＬ＿ＩＤの値が知られていないか、特定されていないと、当該フィールドは０に設定される。
【０５４９】
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。
【０５５０】
ＳＹＳＴＥＭ＿ＩＤ：当該１６ビットフィールドは、ＡＴＳＣネットワーク内でヒューチャーキャストＵＴＢシステムを唯一に識別する。ヒューチャーキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。ヒューチャーキャストＵＴＢシステムは、存在するなら、ＦＥＦ及び一つ以上の物理プロファイルを伝達する。同じヒューチャーキャストＵＴＢシステムは、互いに異なる入力ストリームを伝達し、異なる地理的領域で異なるＲＦを用いることができるので、ローカルサービスの挿入を許容する。フレーム構造及びスケジューリングは、一つの場所で制御され、ヒューチャーキャストＵＴＢシステム内で全ての伝送に対して同一である。一つ以上のヒューチャーキャストＵＴＢシステムはいずれも同じ物理構造及び構成を有するという同一ＳＹＳＴＥＭ＿ＩＤの意味を有することができる。
【０５５１】
次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個の物理プロファイル（ＦＥＦを含む）がシグナルされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４よりも小さいと、使用されないフィールドはゼロで埋められる。
【０５５２】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレーム（ｉはループ（ｌｏｏｐ）インデックス）の物理プロファイルタイプを示す。当該フィールドは、表８に示したものと同じシグナリングフォーマットを用いる。
【０５５３】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：当該２ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを使用すると、フレームデューレーションの正確な値が得られる。
【０５５４】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの保護区間の一部の値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７によってシグナルされる。
【０５５５】
ＲＥＳＥＲＶＥＤ：当該４ビットフィールドは将来の使用のためにリザーブされる。
【０５５６】
次のフィールドは、ＰＬＳ２データをデコードするためのパラメータを提供する。
【０５５７】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表４によってシグナルされる。ＬＤＰＣコードに関する詳細な内容は後述する。
【０５５８】
【表４】
0006449897.tif 000006
【０５５９】
ＰＬＳ２＿ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは、表５によってシグナルされる。
【０５６０】
【表５】
0006449897.tif 000007
【０５６１】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、現フレームグループで伝達されるＰＬＳ２に対する全てのコーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_partial_blockを示す。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５６２】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５６３】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５６４】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０５６５】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、現フレームグループの毎フレームごとに伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_partial_blockを示す。反復が使用されない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５６６】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられるＦＥＣタイプを示す。ＦＥＣタイプは表１０によってシグナルされる。
【０５６７】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：当該３ビットフィールドは、次のフレームグループの毎フレームで伝達されるＰＬＳ２に用いられる変調タイプを示す。変調タイプは、表１１によってシグナルされる。
【０５６８】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：当該１ビットフラグは、ＰＬＳ２反復モードが次のフレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＰＬＳ２反復モードは活性化される。当該フィールドの値が０に設定されると、ＰＬＳ２反復モードは非活性化される。
【０５６９】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２反復が用いられる場合、次のフレームグループの毎フレームごとに伝達されるＰＬＳ２に対する全体のコーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣtotal_full_blockを示す。次のフレームグループで反復が使用されない場合、当該フィールドの値は０と同一である。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５７０】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０５７１】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：当該１４ビットフィールドは、次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。当該値は、現フレームグループにおいて一定である。
【０５７２】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全体のデューレーションにおいて一定である。下記の表６は、当該フィールドの値を提供する。当該フィールドの値が００に設定されると、現フレームグループで追加パリティがＰＬＳ２に対して使用されない。
【０５７３】
【表６】
0006449897.tif 000008
【０５７４】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、ＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５７５】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：当該２ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。当該値は、現フレームグループの全体のデューレーションにおいて一定である。表１２は、当該フィールドの値を定義する。
【０５７６】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：当該１５ビットフィールドは、次のフレームグループの毎フレームごとにＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数に特定される）を示す。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５７７】
ＲＥＳＥＲＶＥＤ：当該３２ビットフィールドは、将来の使用のためにリザーブされる。
【０５７８】
ＣＲＣ＿３２：全体のＰＬＳ１シグナリングに適用される３２ビット誤り検出コード
【０５７９】
図２５は、本発明の一実施例に係るＰＬＳ２データを示す。
【０５８０】
図２５は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
【０５８１】
以下、ＰＬＳ２−ＳＴＡＴデータのフィールドについて具体的に説明する。
【０５８２】
ＦＩＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＦＩＣが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームで提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５８３】
ＡＵＸ＿ＦＬＡＧ：当該１ビットフィールドは、補助ストリームが現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、補助ストリームは現フレームで提供される。当該フィールドの値が０に設定されると、補助フレームは現フレームで伝達されない。当該値は、現フレームグループの全体のデューレーションにおいて一定である。
【０５８４】
ＮＵＭ＿ＤＰ：当該６ビットフィールドは、現フレーム内で伝達されるデータパイプの数を示す。当該フィールドの値は１〜６４であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
【０５８５】
ＤＰ＿ＩＤ：当該６ビットフィールドは、物理プロファイル内で唯一に識別する。
【０５８６】
ＤＰ＿ＴＹＰＥ：当該３ビットフィールドは、データパイプのタイプを示す。これは、下記の表７によってシグナルされる。
【０５８７】
【表７】
0006449897.tif 000009
【０５８８】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：当該８ビットフィールドは、現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同じＤＰ＿ＧＲＯＵＰ＿ＩＤを有するようになる特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために用いることができる。
【０５８９】
ＢＡＳＥ＿ＤＰ＿ＩＤ：当該６ビットフィールドは、管理層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤが示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達する正常データパイプであるか、サービスシグナリングデータのみを伝達する専用データパイプであってもよい。
【０５９０】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表８によってシグナルされる。
【０５９１】
【表８】
0006449897.tif 000010
【０５９２】
ＤＰ＿ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅ  ｒａｔｅ）を示す。コードレート（ｃｏｄｅ  ｒａｔｅ）は、下記の表９によってシグナルされる。
【０５９３】
【表９】
0006449897.tif 000011
【０５９４】
ＤＰ＿ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は、下記の表１０によってシグナルされる。
【０５９５】
【表１０】
0006449897.tif 000012
【０５９６】
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：当該１ビットフィールドは、ＳＳＤモードが関連したデータパイプで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＳＳＤは使用される。当該フィールドの値が０に設定されると、ＳＳＤは使用されない。
【０５９７】
次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ現れる。
【０５９８】
ＤＰ＿ＭＩＭＯ：当該３ビットフィールドは、いかなるタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、下記の表１１によってシグナルされる。
【０５９９】
【表１１】
0006449897.tif 000013
【０６００】
ＤＰ＿ＴＩ＿ＴＹＰＥ：当該１ビットフィールドは、時間インターリービングのタイプを示す。０の値は、一つの時間インターリービンググループが一つのフレームに該当し、一つ以上の時間インターリービングブロックを含むことを示す。１の値は、一つの時間インターリービンググループが一つよりも多いフレームで伝達され、一つの時間インターリービングブロックのみを含むことを示す。
【０６０１】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：当該２ビットフィールド（許容された値は、１、２、４、８のみである）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値によって決定される。
【０６０２】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれの時間インターリービンググループがマップされるフレームの数であるＰIを示し、時間インターリービンググループ当たりに１つの時間インターリービングブロックが存在する（ＮTI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１２に定義される。
【０６０３】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されると、当該フィールドは、時間インターリービンググループ当たりに時間インターリービングブロックの数ＮTIを示し、フレーム当たりに一つの時間インターリービンググループが存在する（ＰI＝１）。当該２ビットフィールドで許容されるＰIの値は、下記の表１２に定義される。
【０６０４】
【表１２】
0006449897.tif 000014
【０６０５】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩＪＵＭＰ）を示し、許容された値は、１、２、４、８（該当する２ビットフィールドはそれぞれ、００、０１、１０、１１）である。フレームグループの全てのフレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１、５、９、１３などのフレームに現れると、当該フィールドの値は４に設定される。全てのフレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。
【０６０６】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：当該１ビットフィールドは、時間インターリーバ５０５０の可用性を決定する。データパイプに対して時間インターリービングが使用されないと、当該フィールド値は１に設定される。反面、時間インターリービングが使用されると、当該フィールド値は０に設定される。
【０６０７】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：当該５ビットフィールドは、現データパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は、０〜３１である。
【０６０８】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：当該１０ビットフィールドは、当該データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。当該フィールドの値は、ＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同じ範囲を有する。
【０６０９】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、下記の表１３によってシグナルされる。
【０６１０】
【表１３】
0006449897.tif 000015
【０６１１】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは、下記の表１４によってシグナルされる。
【０６１２】
【表１４】
0006449897.tif 000016
【０６１３】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、下記の表１５によってシグナルされる。
【０６１４】
【表１５】
0006449897.tif 000017
【０６１５】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングが入力フォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表１６によってシグナルされる。
【０６１６】
【表１６】
0006449897.tif 000018
【０６１７】
ＤＮＰ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、下記の表１７によってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
【０６１８】
【表１７】
0006449897.tif 000019
【０６１９】
ＩＳＳＹ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、下記の表１８によってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
【０６２０】
【表１８】
0006449897.tif 000020
【０６２１】
ＨＣ＿ＭＯＤＥ＿ＴＳ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、下記の表１９によってシグナルされる。
【０６２２】
【表１９】
0006449897.tif 000021
【０６２３】
ＨＣ＿ＭＯＤＥ＿ＩＰ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（「０１」）に設定される場合にＩＰヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、下記の表２０によってシグナルされる。
【０６２４】
【表２０】
0006449897.tif 000022
【０６２５】
ＰＩＤ：当該１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１又は１０に設定される場合にＴＳヘッダー圧縮のためのＰＩＤの数を示す。
【０６２６】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６２７】
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０６２８】
ＦＩＣ＿ＶＥＲＳＩＯＮ：当該８ビットフィールドは、ＦＩＣのバージョン番号を示す。
【０６２９】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１３ビットフィールドは、ＦＩＣの長さをバイト単位で示す。
【０６３０】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６３１】
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同一である場合にのみ現れる。
【０６３２】
ＮＵＭ＿ＡＵＸ：当該４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが使用されないことを示す。
【０６３３】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６３４】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：当該４ビットは、現補助ストリームのタイプを示すための将来の使用のためにリザーブされる。
【０６３５】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：当該２８ビットフィールドは、補助ストリームをシグナルするための将来の使用のためにリザーブされる。
【０６３６】
図２６は、本発明の他の実施例に係るＰＬＳ２データを示す。
【０６３７】
図２６は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は、一つのフレームグループのデューレーションにおいて変化可能である一方、フィールドのサイズは一定である。
【０６３８】
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は次のとおりである。
【０６３９】
ＦＲＡＭＥ＿ＩＮＤＥＸ：当該５ビットフィールドは、スーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
【０６４０】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値によって示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、１の値は、次のスーパーフレームに変化があることを示す。
【０６４１】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：当該４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、当該フィールド内でシグナルされる値によって示す。当該フィールドの値が００００に設定されると、これは、いかなる予定された変化も予測されないことを意味する。例えば、０００１の値は、次のスーパーフレームに変化があることを示す。
【０６４２】
ＲＥＳＥＲＶＥＤ：当該１６ビットフィールドは、将来の使用のためにリザーブされる。
【０６４３】
次のフィールドは、現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰにおけるループ（ｌｏｏｐ）に現れる。
【０６４４】
ＤＰ＿ＩＤ：当該６ビットフィールドは、物理プロファイル内でデータパイプを唯一に示す。
【０６４５】
ＤＰ＿ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初の開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、下記の表２１に示すとおり、物理プロファイル及びＦＦＴサイズによって異なる長さを有する。
【０６４６】
【表２１】
0006449897.tif 000023
【０６４７】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：当該１０ビットフィールドは、現データパイプに対する現時間インターリービンググループでのＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は、０〜１０２３である。
【０６４８】
ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。
【０６４９】
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
【０６５０】
ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームでのＥＡＣの存在を示す。当該ビットは、プリアンブルでＥＡＣ＿ＦＬＡＧと同一の値である。
【０６５１】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：当該８ビットフィールドは、自動活性化指示のバージョン番号を示す。
【０６５２】
ＥＡＣ＿ＦＬＡＧフィールドが１と同一であれば、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０と同一であれば、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
【０６５３】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：当該１２ビットフィールドは、ＥＡＣの長さをバイトで示す。
【０６５４】
ＥＡＣ＿ＣＯＵＮＴＥＲ：当該１２ビットフィールドは、ＥＡＣが到達するフレーム前のフレームの数を示す。
【０６５５】
次のフィールドは、ＡＵＸ＿ＦＬＡＧフィールドが１と同一である場合にのみ現れる。
【０６５６】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：当該４８ビットフィールドは、補助ストリームをシグナルするための将来の使用のためにリザーブされる。当該フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０６５７】
ＣＲＣ＿３２：全体のＰＬＳ２に適用される３２ビット誤り検出コード
【０６５８】
図２７は、本発明の一実施例に係るフレームの論理（ｌｏｇｉｃａｌ）構造を示す。
【０６５９】
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルは、フレームにおいてＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳ１及びＰＬＳ２は最初に、一つ以上のＦＳＳにマップされる。続いて、ＥＡＣが存在すると、ＥＡＣセルは直後のＰＬＳフィールドにマップされる。次に、ＦＩＣが存在すると、ＦＩＣセルがマップされる。データパイプは、ＰＬＳの次にマップされたり、ＥＡＣ又はＦＩＣが存在する場合、ＥＡＣ又はＦＩＣの後にマップされる。タイプ１データパイプが最初にマップされ、タイプ２データパイプがその次にマップされる。データパイプのタイプの具体的な内容は後述する。一部の場合、データパイプは、ＥＡＳに対する一部の特殊データ又はサービスシグナリングデータを伝達することができる。補助ストリーム又はストリームは、存在するなら、データパイプの次にマップされ、そこには順にダミーセルが続く。前述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順序で全て一緒にマップすると、フレームでセル容量を正確に満たす。
【０６６０】
図２８は、本発明の一実施例に係るＰＬＳマッピングを示す。
【０６６１】
ＰＬＳセルはＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳの占めるセルの数によって、一つ以上のシンボルがＦＳＳと指定され、ＦＳＳの数ＮFSSは、ＰＬＳ１におけるＮＵＭ＿ＦＳＳによってシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳにおいて重大な事項であるが、ＦＳＳは、高いパイロット密度を有しているので、高速同期化、及びＦＳＳ内における周波数のみの補間（ｉｎｔｅｒｐｏｌｏａｔｉｏｎ）を可能にする。
【０６６２】
ＰＬＳセルは、図示しているように、下方に向いて、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳ１セルは最初に、一番目のＦＳＳの一番目のセルから始まって、セルインデックスの昇順でマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、最初のＦＳＳの最後のセルインデックスまで下方に続けてマップされる。必要なＰＬＳセルの総数が、一つのＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアの数を超えると、マッピングは、次のＦＳＳに進み、最初のＦＳＳと全く同じ方式で続いて行われる。
【０６６３】
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、又は両方が現フレームに存在すると、ＥＡＣ及びＦＩＣは、ＰＬＳと正常データパイプとの間に配置される。
【０６６４】
以下では、本発明の一実施例に係るＦＥＣ構造及びエンコーディングについて説明する。前述したように、データＦＥＣエンコーダは、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示のＦＥＣ構造はＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに該当する同一値を有する。
【０６６５】
上述したとおり、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋbchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコーディングされたＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０６６６】
Ｎldpcの値は６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
【０６６７】
下記の表２２及び表２３は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。
【０６６８】
【表２２】
0006449897.tif 000024
【０６６９】
【表２３】
0006449897.tif 000025
【０６７０】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次のとおりである。
【０６７１】
１２−誤り訂正ＢＣＨコードがＢＢＦの外部エンコーディングに用いられる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は、全ての多項式を掛けることによって得られる。
【０６７２】
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコードするために用いられる。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）がそれぞれのＩldpc（ＢＣＨ−エンコードされたＢＢＦ）から組織的にエンコードされ、Ｉldpcに付加される。完成されたＢldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。
【０６７３】
【数２】
0006449897.tif 000026
【０６７４】
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２２及び表２３にそれぞれ与えられる。
【０６７５】
ロングＦＥＣＢＬＯＣＫに対してＮldpc−Ｋldpcパリティビットを計算する具体的な手順は、次のとおりである。
【０６７６】
１）パリティビット初期化
【０６７７】
【数３】
0006449897.tif 000027
【０６７８】
２）パリティチェックマトリクスの住所の一番目の行で特定されたパリティビット住所において一番目の情報ビットｉ0を累算（ａｃｃｕｍｕｌａｔｅ）する。パリティチェックマトリクスの住所の詳細な内容は後述する。例えば、比率１３／１５に対して、
【０６７９】
【数４】
0006449897.tif 000028
【０６８０】
３）次の３５９個の情報ビットｉs、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビット住所でｉsを累算（ａｃｃｕｍｕｌａｔｅ）する。
【０６８１】
【数５】
0006449897.tif 000029
【０６８２】
ここで、ｘは、一番目のビットｉ0に該当するパリティビット累算器の住所を表し、Ｑldpcは、パリティチェックマトリクスの住所で特定されたコードレート（ｃｏｄｅ  ｒａｔｅ）依存定数である。上記例である、比率１３／１５に対する、したがって情報ビットｉ1に対するＱldpc＝２４に続いて、次の動作が実行される。
【０６８３】
【数６】
0006449897.tif 000030
【０６８４】
４）３６１番目の情報ビットｉ360に対して、パリティビット累算器の住所は、パリティチェックマトリクスの住所の二番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉs、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器の住所は、式６から得られる。ここで、ｘは、情報ビットｉ360に該当するパリティビット累算器の住所、すなわち、パリティチェックマトリクスの二番目の行のエントリを表す。
【０６８５】
５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティチェックマトリクスの住所からの新しい行は、パリティビット累算器の住所を求めるのに用いられる。
【０６８６】
全ての情報ビットが利用された後、最終パリティビットが次のように得られる。
【０６８７】
６）ｉ＝１から始まって次の動作を順次に実行する。
【０６８８】
【数７】
0006449897.tif 000031
【０６８９】
ここで、ｐi、ｉ＝０，１，．．．Ｎldpc−Ｋldpc−１の最終コンテンツは、パリティビットｐiと同一である。
【０６９０】
【表２４】
0006449897.tif 000032
【０６９１】
表２４を表２５に代え、且つロングＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスの住所を、ショートＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスの住所に代える以外は、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔＬＤＰＣエンコーディング手順に従う。
【０６９２】
【表２５】
0006449897.tif 000033
【０６９３】
図２９は、本発明の一実施例に係る時間インターリービングを示す。
【０６９４】
（ａ）乃至（ｃ）は、時間インターリービングモードの例を示す。
【０６９５】
時間インターリーバは、データパイプレベルで動作する。時間インターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定されてもよい。
【０６９６】
ＰＬＳ２−ＳＴＡＴデータの一部に現れる次のパラメータは時間インターリービングを構成する。
【０６９７】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０又は１）：時間インターリービングモードを示す。０は、時間インターリービンググループ当たりに複数の時間インターリービングブロック（一つ以上の時間インターリービングブロック）を有するモードを示す。この場合、一つの時間インターリービンググループは一つのフレームに（フレーム間インターリービング無しで）直接マップされる。１は、時間インターリービンググループ当たりに一つの時間インターリービングブロックのみを有するモードを示す。この場合、時間インターリービングブロックは、一つ以上のフレームにわたって拡散される（フレーム間インターリービング）。
【０６９８】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝「０」であれば、当該パラメータは、時間インターリービンググループ当たりに時間インターリービングブロックの数ＮTIである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝「１」である場合、当該パラメータは、一つの時間インターリービンググループから拡散されるフレームの数ＰIである。
【０６９９】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：時間インターリービンググループ当たりにＸＦＥＣＢＬＯＣＫの最大数を示す。
【０７００】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１，２，４，８）：与えられた物理プロファイルの同じデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩJUMPを示す。
【０７０１】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０又は１）：時間インターリービングがデータフレームに利用されないと、当該パラメータは１に設定される。時間インターリービングが利用されると、０に設定される。
【０７０２】
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫは、データグループの一つの時間インターリービンググループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
【０７０３】
時間インターリービングがデータフレームに利用されないと、次の時間インターリービンググループ、時間インターリービング動作、時間インターリービングモードは考慮されない。しかし、スケジューラからの動的（ｄｙｎａｍｉｃ）構成情報のための遅延補償（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ）ブロックは相変らず必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、時間インターリービンググループにグループ化される。すなわち、それぞれの時間インターリービンググループは、整数個のＸＦＥＣＢＬＯＣＫの集合であり、動的（ｄｙｎａｍｉｃ）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎの時間インターリービンググループに存在するＸＦＥＣＢＬＯＣＫの数はＮxBLOCK_Group（ｎ）と表し、ＰＬＳ２−ＤＹＮデータにおいてＤＰ＿ＮＵＭ＿ＢＬＯＣＫでシグナルされる。この時、ＮxBLOCK_Group（ｎ）は、最小値０から、最大の値が１０２３である最大値ＮxBLOCK_Group_MAX（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化してもよい。
【０７０４】
それぞれの時間インターリービンググループは、一つのフレームに直接マップされたり、ＰI個のフレームにわたって拡散される。また、それぞれの時間インターリービンググループは、一つ以上（ＮTI個）の時間インターリービングブロックに分離される。ここで、それぞれの時間インターリービングブロックは、時間インターリーバメモリーの一つの使用に該当する。時間インターリービンググループ内の時間インターリービングブロックは、若干の異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。時間インターリービンググループが複数の時間インターリービングブロックに分離されると、時間インターリービンググループは一つのフレームにのみ直接マップされる。下記の表２６に示すように、時間インターリービングには３つのオプションがある（時間インターリービングを省略する追加オプションは除く）。
【０７０５】
【表２６】
0006449897.tif 000034
【０７０６】
一般に、時間インターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファとしても働くことができる。これは、それぞれのデータパイプに対して２個のメモリバンクによって達成される。一番目の時間インターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み出される間に、二番目の時間インターリービングブロックが二番目のバンクに書き込まれる。
【０７０７】
時間インターリービングは、ツイストされた行−列ブロックインターリーバである。ｎ番目の時間インターリービンググループのｓ番目の時間インターリービングブロックに対して、列の数ＮcがＮxBLOCK_TI（ｎ，ｓ）と同一であるが、 時間インターリービングメモリの行の数Ｎrは、セルの数Ｎcellsと同一である（すなわち、Ｎr＝Ｎcells）。
【０７０８】
図３０は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
【０７０９】
図３０（ａ）は、時間インターリーバにおける書き込み動作を示し、図３０（ｂ）は、時間インターリーバにおける読み出し動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫは、時間インターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作がつながる。そして、インターリービングアレイで、セルが対角線方向に読み出される。（ｂ）に示すように、一番目の行から（最も左側列から始まって行に沿って右に）最後の行まで対角線方向読み出しが進行される間に、Ｎr個のセルが読み出される。具体的には、ｚｎ，ｓ，ｉ（i＝０,...，ＮｒＮｃ）が順次に読み出される時間インターリービングメモリセル位置であると仮定すれば、このようなインターリービングアレイでの読み出し動作は、下記の式のように、行インデックスＲｎ，ｓ，ｉ、列インデックスＣｎ，ｓ，ｉ、関連したツイストパラメータＴｎ，ｓ，ｉを算出することによって実行される。
【０７１０】
【数８】
0006449897.tif 000035
【０７１１】
ここで、Ｓｓｈｉｆｔは、ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく対角線方向読み出し過程に対する共通シフト値であり、シフト値は下記の式のようにＰＬＳ２−ＳＴＡＴで与えられたＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸによって決定される。
【０７１２】
【数９】
0006449897.tif 000036
【０７１３】
結果的に、読み出されるセル位置は、座標ｚｎ，ｓ，ｉ＝ＮｒＣｎ，ｓ，ｉ+Ｒｎ，ｓ，ｉによって算出される。
【０７１４】
図３１は、本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す。
【０７１５】
より具体的に、図３１は、ＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５であるとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれの時間インターリービンググループに対する時間インターリービングメモリでのインターリービングアレイを示す。
【０７１６】
変数ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）＝Ｎｒは、Ｎ’ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸより小さい又は等しいだろう。したがって、ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく受信機側で単一メモリデインターリービングを達成するために、ツイストされた行−列ブロックインターリーバ用インターリービングアレイは仮想ＸＦＥＣＢＬＯＣＫを時間インターリービングメモリに挿入することによって、Ｎｒ×Ｎｃ＝Ｎｃｅｌｌｓ×Ｎ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸのサイズに設定され、読み出し過程は次の式のようになされる。
【０７１７】
【数１０】
0006449897.tif 000037
【０７１８】
時間インターリービンググループの数は３に設定される。時間インターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝「０」、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝「１」、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝「１」、すなわち、ＮＴＩ＝１、ＩＪＵＭＰ＝１、ＰＩ＝１によってＰＬＳ２−ＳＴＡＴデータでシグナルされる。それぞれＮｃｅｌｌｓ＝３０であるＸＦＥＣＢＬＯＣＫの時間インターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナルされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナルされ、これは
【数１１】
0006449897.tif 000038
につながる。
【０７１９】
一つのＯＦＤＭシンボルに該当するデータ上で動作する周波数インターリーバの目的は、フレームビルダーから受信されたデータセルを無作為にインターリーブすることによって周波数ダイバーシティを提供することである。一つのフレームで最大インターリービング利得を得るために、２つの順次的なＯＦＤＭシンボルからなる全てのＯＦＤＭシンボルペアに対して異なるインターリービングシーケンスが用いられる。
【０７２０】
したがって、本発明の一実施例に係る周波数インターリーバは、シンボルペアに対応するデータに適用するためのインターリービング住所を生成するためのインターリービング住所生成器を含むことができる。
【０７２１】
図３２は、本発明の一実施例に係る各ＦＦＴモードによるメイン−ＰＲＢＳ生成器及びサブ−ＰＲＢＳ生成器で構成されたインターリービング住所生成器のブロックダイアグラムを示す図である。
【０７２２】
（ａ）は、８Ｋ  ＦＦＴモードに対するインターリービング住所生成器のブロックダイアグラムを示し、（ｂ）は、１６Ｋ  ＦＦＴモードに対するインターリービング住所生成器のブロックダイアグラムを示し、（ｃ）は、３２Ｋ  ＦＦＴモードに対するインターリービング住所生成器のブロックダイアグラムを示す。
【０７２３】
【数１２】
0006449897.tif 000039
【０７２４】
【数１３】
0006449897.tif 000040
【０７２５】
図３３は、本発明の一実施例に係る全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。
【０７２６】
（ａ）は、メイン−ＰＲＢＳを示し、（ｂ）は、各ＦＦＴモードのためのパラメータＮｍａｘを示す。
【０７２７】
図３４は、本発明の一実施例に係る周波数インターリービングのためのインターリービング住所及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。
【０７２８】
（ａ）は、サブ−ＰＲＢＳ生成器を示し、（ｂ）は、周波数インターリービングのためのインターリービング住所を示す。本発明の一実施例に係るサイクリックシフト値は、シンボルオフセットと呼ぶことができる。
【０７２９】
図３５は、本発明の一実施例に係る時間インターリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す。
【０７３０】
図３５は、２つのＴＩグループに対する書き込み（ｗｒｉｔｉｎｇ）動作を示す。
【０７３１】
図面の左側に示すブロックは、ＴＩメモリ住所アレイ（ｍｅｍｏｒｙ  ａｄｄｒｅｓｓ  ａｒｒａｙ）を示し、図面の右側に示すブロックは、連続した２つのＴＩグループに対してそれぞれ仮想（ｖｉｒｔｕａｌ）ＦＥＣブロックがＴＩグループの最も前にそれぞれ２個及び１個が挿入された場合の書き込み（ｗｒｉｔｉｎｇ）動作を示す。
【０７３２】
以下、ＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）モードによってコンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（Ｂｌｏｃｋ  Ｉｎｔｅｒｌｅａｖｅｒ，ＢＩ）を選択的に使用したり、両方とも使用する時間インターリーバの構造及び時間インターリービング方法を説明する。本発明の一実施例に係るＰＬＰは、上述したＤＰと同じ概念で使われる物理経路（ｐｈｙｓｉｃａｌ  ｐａｔｈ）であり、呼称は設計者の意図によって変更可能である。
【０７３３】
本発明の一実施例に係るＰＬＰモードは、放送信号送信機又は放送信号送信装置で処理するＰＬＰの個数によって、シングルＰＬＰ（ｓｉｎｇｌｅ  ＰＬＰ）モード又はマルチプルＰＬＰ（ｍｕｌｔｉｐｌｅ  ＰＬＰ）モードを含むことができる。シングルＰＬＰモードは、放送信号送信装置で処理するＰＬＰの個数が一つである場合を意味する。シングルＰＬＰモードはシングルＰＬＰと呼ぶこともできる。
【０７３４】
マルチプルＰＬＰモードは、放送信号送信装置で処理するＰＬＰの個数が一つ以上である場合であり、マルチプルＰＬＰモードは、マルチプルＰＬＰと呼ぶこともできる。
【０７３５】
本発明ではＰＬＰモードによって異なる時間インターリービング方法を適用する時間インターリービングをハイブリッド時間インターリービング（Ｈｙｂｒｉｄ  Ｔｉｍｅ  Ｉｎｔｅｒｌｅａｖｉｎｇ）と呼ぶことができる。本発明の一実施例に係るハイブリッド時間インターリービングは、マルチプルＰＬＰモードの場合、各ＰＬＰ別に（或いは、ＰＬＰレベルで）適用される。
【０７３６】
図３６は、ＰＬＰの個数によって適用するインターリービングタイプを表で示す図である。
【０７３７】
本発明の一実施例に係る時間インターリーバは、ＰＬＰ＿ＮＵＭの値に基づいてインターリービングタイプ（Ｉｎｔｅｒｌｅａｖｉｎｇ  ｔｙｐｅ）が決定されてもよい。ＰＬＰ＿ＮＵＭは、ＰＬＰモードを示すシグナリングフィールド（ｓｉｇｎａｌｉｎｇ  ｆｉｅｌｄ）である。ＰＬＰ＿ＮＵＭの値が１である場合、ＰＬＰモードはシングルＰＬＰである。本発明の一実施例に係るシングルＰＬＰには、コンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）のみが適用されてもよい。
【０７３８】
ＰＬＰ＿ＮＵＭの値が１よりも大きい場合、ＰＬＰモードは、マルチプルＰＬＰである。本発明の一実施例に係るマルチプルＰＬＰには、コンボリューションインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  Ｉｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（Ｂｌｏｃｋ  Ｉｎｔｅｒｌｅａｖｅｒ，ＢＩ）が適用されてもよい。この場合、コンボリューションインターリーバはインターフレームインターリービング（Ｉｎｔｅｒ  ｆｒａｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックインターリーバはイントラフレームインターリービング（Ｉｎｔｒａ  ｆｒａｍｅ  ｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。
【０７３９】
図３７は、上述したハイブリッド時間インターリーバ構造の第１実施例を含むブロック図である。
【０７４０】
第１実施例に係るハイブリッド時間インターリーバは、ブロックインターリーバ（ＢＩ）とコンボリューションインターリーバ（ＣＩ）を含むことができる。本発明の時間インターリーバは、ＢＩＣＭチェーン（ＢＩＣＭ  ｃｈａｉｎ）ブロックとフレームビルダー（Ｆｒａｍｅ  Ｂｕｉｌｄｅｒ）との間に位置し得る。
【０７４１】
図３７及び図３８に示すＢＩＣＭチェーンブロックは、図１９に示すＢＩＣＭブロックの処理ブロック５０００のうち時間インターリーバ５０５０以外のブロックを含むことができる。図３７及び図３８に示すフレームビルダーは、図１８のフレームビルディング１０２０ブロックと同じ役割を担うことができる。
【０７４２】
上述したとおり、ハイブリッド時間インターリーバ構造の第１実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１である場合、ブロックインターリーバは適用されず（ブロックインターリーバオフ（ｏｆｆ））、コンボリューションインターリーバだけ適用される。ＰＬＰ＿ＮＵＭ＞１の場合、ブロックインターリーバとコンボリューションインターリーバが全て適用（ブロックインターリーバオン（ｏｎ））されてもよい。ＰＬＰ＿ＮＵＭ＞１の場合、適用されるコンボリューションインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１の場合に適用されるコンボリューションインターリーバの構造及び動作と同一又は類似してもよい。
【０７４３】
図３８は、上述したハイブリッド時間インターリーバ構造の第２実施例を含むブロック図である。
【０７４４】
ハイブリッド時間インターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３７で説明した内容と同一である。ハイブリッド時間インターリーバ構造の第２実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定され得る。第２実施例に係るハイブリッド時間インターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この時、ＰＬＰ＿ＮＵＭ＝１の場合とＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションインターリーバの構造及び動作が互いに異なってもよい。
【０７４５】
図３９は、ハイブリッド時間デインターリーバの構造の第１実施例を含むブロック図である。
【０７４６】
第１実施例に係るハイブリッド時間デインターリーバは、上述した第１実施例に係るハイブリッド時間インターリーバの逆動作に相応する動作を行うことができる。したがって、図３９の第１実施例に係るハイブリッド時間デインターリーバは、コンボリューションデインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ  ｄｅｉｎｔｅｒｌｅａｖｅｒ，ＣＤＩ）とブロックデインターリーバ（Ｂｌｏｃｋ  ｄｅｉｎｔｅｒｌｅａｖｅｒ，ＢＤＩ）を含むことができる。
【０７４７】
ＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションデインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１の場合に適用されるコンボリューションデインターリーバの構造及び動作と同一又は類似してもよい。
【０７４８】
ハイブリッド時間デインターリーバ構造の第１実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１の場合、ブロックデインターリーバは適用されず（ブロックデインターリーバオフ（ｏｆｆ））、コンボリューションデインターリーバだけ適用される。
【０７４９】
ハイブリッド時間デインターリーバのコンボリューションデインターリーバは、インターフレームデインターリービング（Ｉｎｔｅｒ  ｆｒａｍｅ  ｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックデインターリーバは、イントラフレームデインターリービング（Ｉｎｔｒａ  ｆｒａｍｅ  ｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。インターフレームデインターリービング及びイントラフレームデインターリービングの具体的な内容は、前述した内容と同一である。
【０７５０】
図３９及び図４０に示すＢＩＣＭデコーディング（ＢＩＣＭ  ｄｅｃｏｄｉｎｇ）ブロックは、図３７及び図３８のＢＩＣＭチェーン（ＢＩＣＭ  ｃｈａｉｎ）ブロックの逆動作を行うことができる。
【０７５１】
図４０は、ハイブリッド時間デインターリーバの構造の第２実施例を含むブロック図である。
【０７５２】
第２実施例に係るハイブリッド時間デインターリーバは、上述した第２実施例に係るハイブリッド時間インターリーバの逆動作に相応する動作を行うことができる。ハイブリッド時間デインターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３９で説明した内容と同一であってもよい。
【０７５３】
ハイブリッド時間デインターリーバ構造の第２実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。第２実施例に係るハイブリッド時間デインターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この時、ＰＬＰ＿ＮＵＭ＝１の場合とＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションデインターリーバの構造及び動作が互いに異なってもよい。
【０７５４】
図４１は、本発明の一実施例に係る、次世代放送システムにおいて放送サービスに接近するためのシグナリング体系を示した図である。
【０７５５】
放送システムでは、上述したようなＦＩＣを定義することができる。ＦＩＣは、放送サービスをスキャンしたり、放送サービスに対するリストを生成するのに必要な情報を含むことができる。ＦＩＣは、下位層シグナリング（Ｌｏｗ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ；ＬＬＳ）に含ませることができ、ＬＬＳは、物理層のデータがサービス層まで処理される過程で、物理層とその上位層とを連結するのに必要なシグナリング情報を含むことができる。
【０７５６】
ＦＩＣは、サービス層のシグナリング情報（サービス層シグナリング；Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ；ＳＬＳ)を伝送するデータパイプ（ＤＰ）を識別する情報を含むことができる。サービス層シグナリングは、サービスシグナリングチャネル（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ；ＳＳＣ）という名称で使用することもできる。
【０７５７】
物理層で放送データが処理され、物理層パラメータが取得されると、物理層パラメータを用いて、放送受信機はＦＩＣに接近することができる。放送受信機は、ＦＩＣの情報を用いてＳＳＣに接近することができる。放送受信機はＳＳＣに接近し、放送サービス及び／又は放送コンテンツを取得して視聴者に表出することができる。
【０７５８】
本発明の第１シグナリング方法によれば、ＳＳＣは、サービスマップテーブル（Ｓｅｒｖｉｅ  Ｍａｐ  Ｔａｂｌｅ；ＳＭＴ）及び／又はＣＭＴ（Ｃｏｎｔｅｎｔ  Ｍａｐ  Ｔａｂｌｅ）を含むことができる。ＳＭＴは、放送サービスを説明する情報を提供するシグナリング構造である。放送受信機は、ＳＭＴの情報を用いて、放送サービスを取得するのに必要な情報を取得することができる。ＣＭＴは、放送サービスに含まれる放送コンテンツを説明する情報を提供するシグナリング構造である。放送受信機は、ＣＭＴを用いて放送コンテンツを取得するのに必要な情報を取得することができる。
【０７５９】
第１シグナリング方法によれば、放送受信機がＳＳＣに接近し、ＳＭＴを優先的に取得することができる。放送受信機は、ＳＭＴで、放送サービスに含まれるデータを伝送するＲＯＵＴＥセッションに接近するための情報及び／又はＲＯＵＴＥセッションを説明する情報を含むＬＳＩＤ（ＬＣＴ  Ｓｅｓｓｉｏｎ  ＩＤ；ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｉｏｎ）に接近するための情報を取得することができる。
【０７６０】
一方、放送受信機は、ＳＭＴのｓｅｒｖｉｃｅ＿ＩＤによって識別される放送サービスに含まれる放送コンテンツに対する情報を取得するためにＣＭＴに接近することができる。ＳＭＴからＣＭＴへの連結はｓｅｒｖｉｃｅ＿ＩＤによって行うことができる。ＣＭＴは、ＣＭＴが説明する一つ以上の放送コンテンツが属する放送サービスを識別するｓｅｒｖｉｃｅ＿ＩＤ情報を含むことができる。ＣＭＴは、放送コンテンツに含まれるリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を識別する情報（例えば、ＲｅｐＩＤ）を含むことができる。リプレゼンテーションは、放送コンテンツを構成するコンポーネント（例えば、オーディオコンポーネント、ビデオコンポーネント、データコンポーネントなど）のためのデータを伝送する単位と定義することができる。放送受信機は、ＣＭＴで取得したＲｅｐＩＤを用いて、放送コンテンツに含まれる各要素を説明する情報を含むＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｔｉｏｎ）に接近し、該当要素を取得し、放送コンテンツを再生することができる。放送受信機は、放送コンテンツに含まれるデータを取得するために、ＤＰ＿ｉｄ（データパイプを識別する情報）及び／又はＴＳＩ（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）情報を用いて、該当データを伝送する伝送セッションに接近することができる。
【０７６１】
本発明の第２シグナリング方法によれば、ＳＳＣは、ＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）及び／又はＳＤＰ（Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を含むことができる。ＵＳＤは、放送サービスを識別する情報、放送サービスを処理するために要求される受信機の能力を示す情報、放送サービスに接近するために参照される他のシグナリング情報に接近するための情報及び／又は受信機が放送サービスに含まれるコンポーネントの伝送モードを判断できるようにする情報を含むことができる。ＳＤＰは、ＵＳＤによって参照することができる。ＳＤＰは、一つ又はそれ以上の伝送セッションを説明する情報及び／又はＬＣＴセッションによって伝送されるデリバリオブジェクトに対する説明情報を含むことができる。放送サービスに含まれるメディアコンテンツのコンポーネントは、伝送セッションを通じて伝送できるが、ＳＤＰは、このような伝送セッションに接近するための情報を提供する。
【０７６２】
第２シグナリング方法によれば、受信機はＵＳＤに接近し、ＭＰＤ及び／又はＳＤＰに接近する情報を取得し、ＭＰＤ及び／又はＳＤＰを取得する。受信機は、ＳＤＰの情報を用いて、放送サービスのデータを伝送する伝送セッションに接近することができる。受信機は、この過程でＳＤＰに含まれるＤＰ＿ｉｄ及び／又はＴＳＩを用いて、必要なデータを伝送する伝送セッションに接近することができる。受信機は、放送サービスに含まれる放送コンテンツを表出するのに必要な情報をＭＰＤで取得することができる。
【０７６３】
図４２は、本発明の一実施例に係る、第１シグナリング方法と第２シグナリング方法とを比較する表を示す図である。
【０７６４】
本発明が提案する放送システム内でのシグナリング体系は上述した通りであるが、細部的な構造は第１シグナリング方法と第２シグナリング方法との間で差があり得る。
【０７６５】
例えば、ＭＰＤとＬＳＩＤは、第１シグナリング方法と第２シグナリング方法のいずれにおいても使用することができる。
【０７６６】
一方、放送サービスを説明する情報を含むシグナリング構造は、第１シグナリング方法ではＳＭＴ形態と定義できるが、第２シグナリング方法ではＵＳＤ形態と定義することができる。
【０７６７】
また、放送サービスに含まれるデータを伝送する伝送セッション（例えば、ＲＯＵＴＥセッション）に対する情報は、第１シグナリング方法ではＳＭＴに関連情報が含まれ得るが、第２シグナリング方法ではＳＤＰに該当の情報が含まれ得る。
【０７６８】
ＬＣＴセッションに関する情報は、第１シグナリング方法と第２シグナリング方法のいずれにおいても、ＬＳＩＤを使用して伝送することができる。
【０７６９】
放送コンテンツに含まれる各コンポーネントに関する情報は、第１シグナリング方法ではＣＭＴ形態のシグナリング構造を使用できるが、第２シグナリング方法ではＳＤＰ及び／又はＵＳＤ形態のシグナリング構造を使用することができる。具体的には、ＤＰを識別するＤＰ＿ｉｄ及び／又は伝送セッションを識別するＴＳＩ情報は、第１シグナリング方法ではＣＭＴに含まれ得るが、第２シグナリング方法ではＳＤＰに含まれ得る。一方、コンポーネントがブロードバンド（Ｂｒｏａｄｂａｎｄ；ＢＢ）又はブロードキャスト（Ｂｒｏａｄｃａｓｔ；ＢＣ）を介して伝送できるが、コンポーネントの伝送経路と関連する情報は、第１シグナリング方法ではＣＭＴに含まれ得るが、第２シグナリング方法ではＵＳＤに含まれ得る。
【０７７０】
第１シグナリング方法と第２シグナリング方法との間の主要な相違点は、放送サービス、放送コンテンツ、及び／又はコンポーネントに対する情報を伝送する位置での差にある。
【０７７１】
図４３は、本発明の一実施例に係る、放送システムで使用されるシグナリング方法を示した図である。
【０７７２】
本発明の一実施例によれば、次世代放送システムのために、３ＧＰＰで定義されたｅＭＢＭＳ（Ｅｖｏｌｖｅｄ−Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  ＆  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ)のシグナリング構造の一部を使用することができる。ｅＭＢＭＳは、移動放送網を介して放送サービスを提供するために制定された標準であって、ＯＦＤＭ及び／又はＬＴＥ通信ベースで放送サービスを提供することを目標とする。
【０７７３】
本発明で使用されるＦＩＣは、サービス層の下位層で定義されるローレベルシグナリング（Ｌｏｗ  ｌｅｖｅｌ  ｓｉｇｎａｌｉｎｇ）であって、サービスのための最小限の情報を含む。ＵＳＤは、３ＧＰＰ  ＭＢＭＳで定義されるＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）に該当し得る。ｅＭＢＭＳ  ＭＰＤは、ｅＭＢＭＳを介して伝達されるコンポーネントのためのＤＡＳＨの構造に従うＭＰＤである。ＡｐｐＳｖｃ  ＭＰＤは、３ＧＰＰ放送及び／又はユニキャスト（ｕｎｉｃａｓｔ）コンポーネントのためのＤＡＳＨの構造に従うＭＰＤである。３ＧＰＰ  ＳＤＰは、ｅＭＢＭＳ  ＦＬＵＴＥセッションのためのＩＥＴＦ  ＳＤＰに該当し得る。フル（Ｆｕｌｌ）ＭＰＤは、各サービス（ＡＴＳＣサービス及び／又は３ＧＰＰサービス）の全てのコンポーネントのためのＤＡＳＨ構造に従うＭＰＤに該当し得る。ＡＴＳＣ  ＳＤＰは、ＲＯＵＴＥセッションのためのＩＥＴＦ  ＳＤＰに該当し得る。ＬＳＩＤは、ＬＣＴ識別子ディスクリプション（ＬＣＴ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｉｏｎ）であって、ＲＯＵＴＥセッション内のＬＣＴストリームに対する情報を含むことができる。
【０７７４】
図面に示した（１）を参照すれば、ｅＭＢＭＳで定義されたＵＳＤを拡張し、放送システムで放送サービスをシグナルするのに使用することができる。
【０７７５】
すなわち、既存のｅＭＢＭＳで使用されたアプリケーションサービスをシグナルするためのＭＰＤ（ＡｐｐＳｖｃ  ＭＰＤ）、ｅＭＢＭＳをシグナルするためのＭＰＤ（ｅＭＢＭＳ  ＭＰＤ）、及び／又は３ＤＰＰサービスをシグナルするためのＳＤＰはｅＭＢＭＳの規格に合わせて使用し、放送システムのために拡張されたシグナリング構造（ＡＴＳＣ  Ｅｘｔｅｎｓｉｏｎ）をＵＳＤに追加することができる。例えば、放送システムで放送サービスをシグナルするための放送システムＳＤＰ（ＡＴＳＣ  ＳＤＰ）を定義し、放送システムＳＤＰの情報を通じて、放送受信機がＲＯＵＴＥセッション及び／又はＬＳＩＤに接近できるようにシグナリング構造を定義することができる。一方、拡張されたシグナリング構造は、ＭＰＥＧ−ＤＡＳＨで定義されるＭＰＤの全体を含むこともできる。
【０７７６】
図面に示した（２）を参照すれば、ｅＭＢＭＳのＵＳＤを拡張することなく、放送システムのためのシグナリング構造を新しく定義してシグナリング体系に含ませることができる。
【０７７７】
図面に示した（２−１）を参照すれば、放送システムのためのＵＳＤ（ＡＴＳＣ＿ＵＳＤ）を定義し、放送受信機は、放送システムのためのＵＳＤに含まれた情報を用いて、ＡＴＳＣ  ＳＤＰ及び／又はフルＭＰＤに接近することができる。放送受信機は、ＡＴＳＣ  ＳＤＰに含まれたＲＯＵＴＥセッションに対する情報を用いてＲＯＵＴＥセッションに接近したり、ＬＳＩＤを取得することができる。
【０７７８】
図面に示した（２−２）を参照すれば、放送システムのためのＳＭＴ（ＬＧＥ  ＳＭＴ）を定義し、放送受信機は、放送システムのためのＳＭＴに含まれた情報を用いてＲＯＵＴＥセッションに接近したり、ＬＳＩＤを取得することができる。一方、ＣＭＴ及び／又はフルＭＰＤ情報もさらに定義され、これらに含まれた情報とＳＭＴに含まれた情報を用いて、放送受信機は、放送サービス、放送コンテンツ、及び／又はコンポーネントに接近することができる。
【０７７９】
本発明の一実施例によれば、３ＧＰＰ  ｅＭＢＭＳで定義されたシグナリング方法を修正したり、特定シグナリング構造を追加して放送システムに適用することができる。この場合、既存に存在していたシグナリング構造を用いるので、新しい放送システムでもシグナリング構造の混乱を起こさないという効果がある。また、３ＧＰＰ  ｅＭＢＭＳと次世代放送システムが類似する構造のシグナリング体系を共有するので、両者に従う放送サービスは共存し得るという効果がある。
【０７８０】
放送システムでは、フルＭＰＤとＡＴＳＣ  ＳＤＰを使用し、ｅＭＢＭＳ  ＭＰＤ、ＡｐｐＳｖｃ  ＭＰＤ及び／又は３ＧＰＰ  ＭＰＤは使用しない場合がある。このようなシグナリング構造において、放送システムで提供される放送サービスのための全てのコンポーネントを説明したり、その位置を定義することができる。
【０７８１】
一方、既存の３ＧＰＰでは、ｅＭＢＭＳ  ＭＰＤ、ＡｐｐＳｖｃ  ＭＰＤ及び／又は３ＧＰＰ  ＳＤＰを使用し、フルＭＰＤ又はＡＴＳＣ  ＳＤＰは使用しない場合がある。このようなシグナリング構造は、３ＧＰＰで提供される３ＧＰＰサービスのための全てのコンポーネントを説明したり、その位置を定義することができる。
【０７８２】
一方、放送システムと３ＧＰＰサービスとが結合されたハイブリッド形態のサービスを考慮することもできる。ハイブリッドサービスのためのシステムでは、フルＭＰＤ、ＡＴＳＣ  ＳＤＰ、ｅＭＢＭＳ  ＭＰＤ、ＡｐｐＳｖｃ  ＭＰＤ及び／又は３ＧＰＰ  ＭＰＤを使用することができる。このようなシグナリング構造は、ハイブリッドサービスのためのシステムで提供されるサービスのための全てのコンポーネントを説明したり、その位置を定義することができる。
【０７８３】
本発明で定義されるサービスは、０又はそれ以上のＲＯＵＴＥセッションで構成することができる。ＲＯＵＴＥセッションは、複数の周波数でスパン（ｓｐａｎ）しないように定義することができる。
【０７８４】
図４４は、本発明の一実施例に係る、第４シグナリング方法によるシグナリング構造を示した図である。
【０７８５】
シグナリング構造は、受信機がシグナリング情報を用いて、受信機が望むサービス／コンテンツを取得するための一連の過程で説明することができる。
【０７８６】
受信機は、ＦＩＣを取得し、放送サービスをスキャンする情報を取得したり、放送サービスのためのシグナリング情報が伝送されるＳＳＣの位置情報又はＳＳＣをブートストラップ（ｂｏｏｔｓｔｒａｐｉｎｇ）するための情報を取得する。受信機は、ＳＳＣに対する位置情報又はブートストラッピング情報を用いてＳＳＣに接近し、ＳＳＣに含まれるＵＳＤ及び／又はＳＰＤに接近する。ＵＳＤは、ＡｐｐＳｖｃ  ＭＰＤ又はｅＭＢＭＳ  ＭＰＤを含むことができ、３ＧＰＰ  ＳＤＰを含むことができる。３ＧＰＰ  ＳＤＰは、受信機が特定ＲＯＵＴＥセッションに接近するのに必要な情報を含むことができる。受信機は、３ＧＰＰ  ＳＤＰ内の情報を用いてＲＯＵＴＥセッションに接近し、該当セッションでＬＳＩＤを取得することができる。受信機は、ＬＳＩＤ内の情報を用いて、受信機が望むサービス／コンテンツに対するデータ／コンポーネントを伝送するＬＣＴセッション／ストリームに接近することができる。
【０７８７】
図４５は、本発明の一実施例に係る、第３シグナリング方法によるシグナリング構造を示した図である。
【０７８８】
シグナリング構造は、受信機がシグナリング情報を用いて、受信機が望むサービス／コンテンツを取得するための一連の過程で説明することができる。
【０７８９】
受信機は、ＦＩＣを取得し、放送サービスをスキャンする情報を取得したり、放送サービスのためのシグナリング情報が伝送されるＳＳＣの位置情報又はＳＳＣをブートストラップするための情報を取得する。受信機は、ＳＳＣに対する位置情報又はブートストラッピング情報を用いてＳＳＣに接近し、ＳＳＣに含まれるＵＳＤに接近する。ＵＳＤは、ＡｐｐＳｖｃ  ＭＰＤ又はｅＭＢＭＳ  ＭＰＤを含むことができ、３ＧＰＰ  ＳＤＰ、フルＭＰＤ、及び／又はＡＴＳＣ  ＳＤＰを含むことができる。ＡｐｐＳｖｃ  ＭＰＤ、ｅＭＢＭＳ  ＭＰＤ及び／又は３ＧＰＰ  ＭＰＤは、３ＧＰＰ  ｅＭＢＭＳを用いるサービスのためのシグナリングとして使用することができる。フルＭＰＤ、ＡＴＳＣ  ＳＤＰ、ＲＯＵＴＥセッション情報及び／又はＬＳＩＤは、ＡＴＳＣシステム（放送システム；ＡＴＳＣ  ３．０システム）を通じて提供されるサービスのためのシグナリングとして使用することができる。受信機は、ＡＴＳＣ  ＳＤＰ内の情報を用いてＲＯＵＴＥセッションに接近し、該当セッションでＬＳＩＤを取得することができる。受信機は、ＬＳＩＤ内の情報を用いて、受信機が望むサービス／コンテンツに対するデータ／コンポーネントを伝送するＬＣＴセッション／ストリームに接近することができる。
【０７９０】
受信機は、放送サービスの属性情報を取得したり、放送サービスの属性を決定するためにＵＳＤを使用することができる。受信機は、ＲＯＵＴＥセッションの位置を探すためにＳＤＰを使用し、放送サービス／コンテンツのコンポーネントを選択するためにＭＰＤを使用することができる。受信機は、選択されたコンポーネントが伝送される位置を探すためにＬＳＩＤを使用することができる。
【０７９１】
図４６は、本発明の一実施例に係る、第３シグナリング方法によるシグナリング構造を具体的に示した図である。
【０７９２】
ＦＩＣは、放送サービスを識別するサービス識別子情報（ｓｅｒｖｉｃｅ＿ｉｄ）を含むことができる。受信機が特定放送サービスを取得しようとする場合、ＦＩＣ内の情報を通じて、該当放送サービスに対する情報を伝送するＳＳＣに接近する。受信機は、ＳＳＣ内で伝送されるＡＴＳＣ  ＵＳＤ情報を取得する。
【０７９３】
ＡＴＳＣ  ＵＳＤは、＠ａｐｐＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ｍｐｄＵＲＩ情報、＠ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｓｅｒｖｉｃｅＩｄ情報、ＤｅｌｉｖｅｒｙＭｅｔｈｏｄ情報、ｂａｓｅＰａｔｔｅｒｎ情報、ＤＰ＿ＩＤ情報、ａｔｓｃＳｄｐＵｒｉ情報、及び／又はｆｕｌｌＭｐｄＵｒｉ情報を含むことができる。
【０７９４】
一つ又はそれ以上のコンポーネントが放送サービスのために存在することができ、これらを伝送するデータパイプの位置をＡＴＳＣ  ＵＳＤを介して識別することができる。
【０７９５】
ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｓｅｒｖｉｃｅＩｄ情報、ＤｅｌｉｖｅｒｙＭｅｔｈｏｄ情報、ｂａｓｅＰａｔｔｅｒｎ情報、ＤＰ＿ＩＤ情報、ａｔｓｃＳｄｐＵｒｉ情報、及び／又はｆｕｌｌＭｐｄＵｒｉ情報は、放送システムのためのシグナリングのために、３ＧＰＰ  ＵＳＤで拡張された情報に該当し得る。
【０７９６】
受信機は、＠ａｐｐＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報が示すＵＲＩを通じて、ＡｐｐＳｖｃＭＰＤが提供される位置に接近することができる。＠ａｐｐＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、ＡｐｐＳｅｒｖｉｃｅエレメント内で定義され、特定アプリケーションサービスのためのＭＰＤが提供される位置を識別する。
【０７９７】
受信機は、ｍｐｄＵＲＩ情報が示すＵＲＩを通じて、ｅＭＢＭＳ  ＭＰＤが提供される位置に接近することができる。ｍｐｄＵＲＩ情報は、ｍｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎエレメント内で定義され、ｅＭＢＭＳ  ＭＰＤが提供される位置を識別する。
【０７９８】
受信機は、＠ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報が示すＵＲＩを通じて、３ＧＰＰ  ＳＤＰが提供される位置に接近することができる。
【０７９９】
受信機は、ＦＩＣ内のｓｅｒｖｉｃｅ＿ｉｄの値と、ＡＴＳＣ  ＵＳＤ内の放送サービスを識別するａｔｓｃＳｅｒｖｉｃｅＩｄ情報の値とが一致することを確認し、受信機が接近しようとする放送サービスに対する情報を識別することができる。
【０８００】
受信機は、放送サービスと３サービスで共通的に使用されるサービスを識別するｓｅｒｖｉｃｅＩｄ情報を用いて、放送サービスと３ＧＰＰサービスで共通的に使用されるサービスに接近することができる。例えば、受信機は、ｓｅｒｖｉｃｅＩｄとＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）で使用されるｇｌｏｂａｌＳｅｒｖｉｃｅＩＤとを連関させ、ＥＳＧを取得することができる。
【０８０１】
受信機は、ＤｅｌｉｖｅｒｙＭｅｔｈｏｄ情報が示す放送サービスを伝送する方法によって、該当放送サービスに接近することができる。
【０８０２】
ｂａｓｅＰａｔｔｅｒｎ情報は、伝送モードによって、特定サービスが伝送される方法内でサービスの位置を識別するのに使用される基本的なパターンを示すことができる。
【０８０３】
ＤＰ＿ＩＤ情報は、放送サービスのコンポーネントを伝送するデータパイプを識別する。
【０８０４】
ａｔｓｃＳｄｐＵｒｉ情報は、ＡＴＳＣＳＤＰが伝送される位置を示すＵＲＩを識別する。
【０８０５】
ｆｕｌｌＭｐｄＵｒｉ情報は、フルＭＰＤが伝送される位置を示すＵＲＩを識別する。
【０８０６】
受信機は、ａｔｓｃＳｄｐＵｒｉ情報を用いてＡＴＳＣ  ＳＤＰを取得し、ＡＴＳＣ  ＳＤＰ内の情報を用いてＲＯＵＴＥセッションに接近したり、ＲＯＵＴＥセッションを通じて伝送されるＬＳＩＤに接近し、放送サービスを構成するコンポーネント（ビデオコンポーネント及び／又はオーディオコンポーネント）を取得することができる。
【０８０７】
受信機は、ｆｕｌｌＭｐｄＵｒｉ情報を用いてフルＭＰＤを取得し、フルＭＰＤで各コンポーネントを表出するための情報を取得することができる。例えば、オーディオ／ビデオコンポーネントに含まれる各セグメントを整列するための情報、各コンポーネント間の同期のための情報などをフルＭＰＤに含ませることができる。
【０８０８】
フルＭＰＤは、放送を介して提供されるアプリケーションサービス、ユニキャストアプリケーションサービス及び／又は次世代放送用アプリケーションサービスを表出するための情報を含むことができる。
【０８０９】
図４７は、本発明の一実施例に係る、第３シグナリング方法と第４シグナリング方法とを比較した図表を示した図である。
【０８１０】
ＳＤＰ内で記述されるＲＯＵＴＥセッションの個数は、第３シグナリング方法によれば１個に該当するが、第４シグナリング方法によれば複数個になり得る。
【０８１１】
受信機が放送サービスに含まれるデータを取得するために使用するシグナリング構造は、第３シグナリング方法によればＵＳＤ、ＭＰＤ、ＬＳＩＤになり、第４シグナリング方法によればＳＰＤ、ＭＰＤ、ＬＳＩＤになる。第３シグナリング方法において、ＵＳＤ内のａｔｓｃＳｅｒｖｉｃｅＩｄは、ＦＩＣ内のＳｅｒｖｉｃｅ＿ｉｄとのマッピングのために使用することができる。すなわち、受信機は、ＦＩＣのｓｅｒｖｉｃｅ＿ｉｄの値と同一の値を有するａｔｓｃＳｅｒｖｉｃｅＩｄ情報を探し、該当のａｔｓｃＳｅｒｖｉｃｅＩｄ情報のために提供される下位情報を用いて、ＦＩＣのｓｅｒｖｉｃｅ＿Ｉｄによって識別される放送サービスに接近することができる。一方、ＵＳＤに含まれるｓｅｒｖｉｃｅＩｄは、放送サービスのために提供されるＥＳＧに受信機が接近するのに使用される。すなわち、受信機は、ＵＳＤ内のｓｅｒｖｉｃｅＩｄと同一の値を有する＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤによって提供されるＥＳＧに接近し、該当放送サービスに対するＥＳＧを取得することができる。
【０８１２】
第３シグナリング方法において、フルＭＰＤは放送サービス（ＡＴＳＣ３．０）のために使用し、ｅＭＢＭＳ  ＭＰＤはｅＭＢＭＳのために使用し、ＡｐｐＳｖｃ  ＭＰＤはアプリケーションサービスのために使用することができる。一方、第４シグナリング方法において、ｅＭＢＭＳ  ＭＰＤはｅＭＢＭＳのために使用し、ＡｐｐＳｖｃ  ＭＰＤはアプリケーションサービスのために使用できるが、フルＭＰＤは使用しない場合がある。
【０８１３】
第３シグナリング方法において、ＳＰＤは、放送サービスと関連するデータが伝送されるソースＩＰ住所（Ｓｏｕｒｃｅ  ＩＰ  ａｄｄｒｅｓｓ）に関する情報を提供する。
【０８１４】
第３シグナリング方法では、放送サービスと関連するデータを伝送するデータパイプは、ＵＳＤ又はＬＳＩＤに含まれるＤＰ＿ｉｄ情報を通じて識別できるが、第４シグナリング方法ではＳＤＰに含まれるＤＰ＿ｉｄを通じて識別することができる。
【０８１５】
図４８は、本発明の一実施例に係る、ｅＭＢＭＳ放送とブロードバンドを介してサービスが提供される過程を示した図である。
【０８１６】
ｅＭＢＭＳ放送を介して、ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントを受信機に伝達することができる。ブロードバンドを介して、第２オーディオサービス／コンポーネント（例えば、オーディオサービスと異なる言語で提供されるオーディオサービス／コンポーネント）を受信機に伝達することができる。
【０８１７】
上記のシナリオにおいて、受信機は、ＵＳＤに含まれるｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるｅＭＢＭＳ  ＭＰＤ及び／又は３ＧＰＰ  ＳＤＰを用いて、ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントに接近することができる。受信機は、ＵＳＤに含まれるｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるＡｐｐＳｖｃ  ＭＰＤを用いて第２オーディオサービス／コンポーネントに接近することができる。
【０８１８】
受信機は、ＵＳＤ内のｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ１情報を通じてＵＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ１）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ２情報を通じてＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ２）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ３情報を通じてオーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ３）を取得することができる。受信機は、ＵＳＤ内のｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ４情報を通じて、第２オーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ４）を取得することができる。
【０８１９】
受信機は、ｅＭＢＭＳ  ＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ１、ｂａｓｅＰａｔｔｅｒｎ２及びｂａｓｅＰａｔｔｅｒｎ３を組み合わせ、ＵＨＤビデオサービス／コンポーネント、ＨＤビデオサービス／コンポーネント及び／又はオーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。
【０８２０】
受信機は、ＡｐｐＳｖｃＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ４とを組み合わせ、第２オーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。
【０８２１】
図４９は、本発明の一実施例に係る、ＡＴＳＣ放送とブロードバンドを介してサービスが提供される過程を示した図である。
【０８２２】
ＡＴＳＣ放送を介して、ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントを受信機に伝達することができる。ブロードバンドを介して、第２オーディオサービス／コンポーネント（例えば、オーディオサービスと異なる言語で提供されるオーディオサービス／コンポーネント）を受信機に伝達することができる。ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントは、特定データパイプを介して伝送することができる。
【０８２３】
上記のシナリオにおいて、受信機は、ＵＳＤに含まれるａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡＴＳＣ  ＡＤＰを用いてＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントに接近することができる。受信機は、ＵＳＤに含まれるｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡｐｐＳｖｃ  ＭＰＤを用いて第２オーディオサービス／コンポーネントに接近することができる。
【０８２４】
受信機は、ＵＳＤ内のａｔｓｃＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ１情報を通じてＵＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ１）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ２情報を通じてＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ２）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ３情報を通じてオーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ３）を取得することができる。受信機は、ＵＳＤ内のｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ４情報を通じて、第２オーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ４）を取得することができる。
【０８２５】
受信機は、フルＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ１、ｂａｓｅＰａｔｔｅｒｎ２、ｂａｓｅＰａｔｔｅｒｎ３及びｂａｓｅＰａｔｔｅｒｎ４とを組み合わせ、ＵＨＤビデオサービス／コンポーネント、ＨＤビデオサービス／コンポーネント、オーディオサービス／コンポーネント及び／又は第２オーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。
【０８２６】
受信機は、ＡｐｐＳｖｃ  ＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ４とを組み合わせ、第２オーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。
【０８２７】
図５０は、本発明の一実施例に係る、ＡＴＳＣ放送、ｅＭＢＭＳ放送及びブロードバンドを介してサービスが提供される過程を示した図である。
【０８２８】
ｅＭＢＭＳ放送を介して、ＵＨＤビデオサービス／コンポーネントを受信機に伝達することができる。ＡＴＳＣ放送を介して、ＨＤビデオ及び／又はオーディオサービス／コンポーネントを受信機に伝達することができる。ブロードバンドを介して、第２オーディオサービス／コンポーネント（例えば、オーディオサービスと異なる言語で提供されるオーディオサービス／コンポーネント）を受信機に伝達することができる。ＨＤビデオ及び／又はオーディオサービス／コンポーネントは特定データパイプを介して伝送することができる。
【０８２９】
受信機は、ＵＳＤに含まれるｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるｅＭＢＭＳ  ＭＰＤ及び／又は３ＧＰＰ  ＳＤＰを用いてＵＨＤビデオサービス／コンポーネントに接近することができる。
【０８３０】
受信機は、ＵＳＤに含まれるａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡＴＳＣ  ＡＤＰを用いてＨＤビデオ及び／又はオーディオサービス／コンポーネントに接近することができる。受信機は、ＵＳＤに含まれるｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡｐｐＳｖｃ  ＭＰＤを用いて第２オーディオサービス／コンポーネントに接近することができる。
【０８３１】
受信機は、ＵＳＤ内のｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ１情報を通じてＵＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ１）を取得することができ、ＵＳＤ内のａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ２情報を通じてＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ２）を取得することができ、ＵＳＤ内のａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ３情報を通じてオーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ３）を取得することができる。受信機は、ＵＳＤ内のｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ４情報を通じて、第２オーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ４）を取得することができる。
【０８３２】
受信機は、フルＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ１、ｂａｓｅＰａｔｔｅｒｎ２、ｂａｓｅＰａｔｔｅｒｎ３及びｂａｓｅＰａｔｔｅｒｎ４とを組み合わせ、ＵＨＤビデオサービス／コンポーネント、ＨＤビデオサービス／コンポーネント、オーディオサービス／コンポーネント及び／又は第２オーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。
【０８３３】
受信機は、ＡｐｐＳｖｃ  ＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ４とを組み合わせ、第２オーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。
【０８３４】
受信機は、ｅＭＢＭＳ  ＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ１とを組み合わせ、ＵＨＤビデオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。
【０８３５】
図５１は、本発明の一実施例に係るシグナリング体系を用いて、受信機が放送サービスを取得する過程を示した図である。
【０８３６】
受信機は、放送ストリーム（Ｂｒｏａｄｃａｓｔ  Ｓｔｒｅａｍ；ｂｓ−１）を受信する。受信した放送ストリームはＦＩＣ及び／又はデータパイプ（ｄｐ−１）を含む。データパイプは、一つ又はそれ以上のＩＰ住所（ｉｐ−１／ｓｉｐ−１)及び／又はＵＤＰ番号（ｕｄｐ−１）を通じて伝送することができる。データパイプは一つ以上のＬＣＴセッションを含むことができる。それぞれのＬＣＴセッションは、一つのコンポーネントを伝送することができる。コンポーネントは、一つ以上のセグメントを含むことができ、各セグメントはＬＣＴセッションを通じて伝送される。すなわち、データパイプは、シグナリング情報を含むシグナリングフラグメントを伝送する伝送セッション、オーディオコンポーネントのためのオーディオセグメントを伝送する伝送セッション及び／又はビデオコンポーネントのためのビデオセグメントを伝送する伝送セッションを含むことができる。
【０８３７】
受信機は、放送ストリームの特定位置（特定ＩＰ住所及び／又はＵＤＰ番号を通じて伝送されるデータ）でＦＩＣを取得することができる。
【０８３８】
ＦＩＣは、ｓｅｒｖｉｃｅ＿ｉｄ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿ｐｏｒｔ情報、ＳＳＣ＿ｔｓｉ情報及び／又はＳＳＣ＿ＤＰ＿ｉｄ情報を含むことができる。
【０８３９】
ｓｅｒｖｉｃｅ＿ｉｄ情報は、放送サービスを識別する情報である。
【０８４０】
ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＳＳＣが伝送されるソース（Ｓｏｕｒｅｃｅ）ＩＰ住所を示す情報である。ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ｓｅｒｖｉｃｅ＿ｉｄによって識別された放送サービスのためのＳＳＣが伝送される位置を識別する情報に該当する。
【０８４１】
ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＳＳＣが伝送される目的地（Ｄｅｓｔｉｎａｔｉｏｎ）ＩＰ住所を示す情報である。ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ｓｅｒｖｉｃｅ＿ｉｄによって識別された放送サービスのためのＳＳＣが伝送される位置を識別する情報に該当する。
【０８４２】
ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿ｐｏｒｔ情報は、ＳＳＣが伝送される目的地（Ｄｅｓｔｉｎａｔｉｏｎ）ＵＤＰ番号を示す情報である。ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿ｐｏｒｔ情報は、ｓｅｒｖｉｃｅ＿ｉｄによって識別された放送サービスのためのＳＳＣが伝送される位置を識別する情報に該当する。
【０８４３】
ＳＳＣ＿ｔｓｉ情報は、ＳＳＣを伝送する伝送セッション（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ）を識別する情報である。ＳＳＣは、固定された、特定ｔｓｉの値を有する伝送セッションを通じて伝送することができる。例えば、ｔｓｉの値が「０」である伝送セッションは、ＳＳＣを伝送する伝送セッションに固定することができる。
【０８４４】
ＳＳＣ＿ＤＰ＿ｉｄ情報は、ＳＳＣを伝送するデータパイプを識別する情報である。
【０８４５】
受信機は、ＦＩＣに含まれた上述した一つ以上の情報を用いて、シグナリングフラグメントを伝送する伝送セッションに接近し、放送サービスを記述する情報（ＳＳＣ）を取得することができる。
【０８４６】
受信機は、ＳＳＣでＡＴＳＣ  ＵＳＤを取得し、ＡＴＳＣ  ＵＳＤに含まれた情報を用いて、受信機が望む放送サービスに対するフルＭＰＤを提供する位置を探すことができる。受信機は、該当位置でＭＰＤを取得する。受信機は、ＭＰＤに含まれた情報を用いて、放送サービス／コンテンツに含まれる各コンポーネントを伝送する位置を探すことができ、該当位置でそれぞれのコンポーネントを取得する。
【０８４７】
上述した過程で、ＡＴＳＣ  ＵＳＤは、＠ａｔｓｃＳｅｒｖｃｉｅＩｄによって識別される放送サービスに含まれる各コンポーネントを取得するのに使用される基本住所に該当するｂａｓｅＰａｔｔｅｒｎ情報を含むことができる。ＭＰＤは、該当のｂａｓｅＰａｔｔｅｒｎ情報を基本ＵＲＬ（ＢａｓｅＵＲＬ）として使用することができる。
【０８４８】
受信機は、ＭＰＤに含まれるＢａｓｅＵＲＬ情報と、コンポーネントに該当するデータユニットである、リプリゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を識別する情報を取得する。すなわち、受信機は、放送サービスを構成するそれぞれのコンポーネントに該当するリプレゼンテーションを識別するリプレゼンテーション情報を取得することができる。受信機は、ＬＳＩＤに含まれた情報を用いて、リプレゼンテーション情報によって識別されるリプレゼンテーションを伝送する伝送セッションに接近することができる。受信機は、該当の伝送セッションで、それぞれのコンポーネント又はセグメントを取得することができる。
【０８４９】
図５２は、本発明の一実施例に係るシグナリング体系を用いて、受信機が放送網とブロードバンドを介して提供される放送サービスを取得する過程を示した図である。
【０８５０】
受信機が放送ストリームで、ＦＩＣを通じてＳＳＣに接近する過程は上述した通りである。
【０８５１】
本実施例では、上述した実施例に加えて、受信機が第２オーディオコンポーネントをさらに取得する過程を含むことができる。第２オーディオコンポーネントは、ブロードバンド網を介して提供することができる。
【０８５２】
ＡＴＳＣ  ＵＳＤは、ブロードバンドで伝送される第２オーディオコンポーネントが存在することを示す情報及び／又は第２オーディオコンポーネントが伝送される位置の基本住所を示す情報を含むことができる。
【０８５３】
ＭＰＤは、第２オーディオコンポーネントに含まれるセグメントが提供される住所を示すセグメント住所情報（ｓｅｇｍｅｎｔ  ＵＲＬｓ）を含むことができ、受信機は、セグメント住所情報が示す位置で、第２オーディオコンポーネントに含まれるセグメントを取得することができる。第２オーディオコンポーネントのセグメントが提供される住所は、第２オーディオコンポーネントが伝送される位置の基本住所を示す情報とセグメント住所情報との組合せで識別することができる。
【０８５４】
ＳＳＣはＳＤＰをさらに含むことができ、ＡＴＳＣ  ＵＳＤは、ＳＤＰが提供される位置を識別する情報（＠ａｔｓｃＳｄｐＵｒｉ）を含むことができる。
【０８５５】
受信機は、ＳＤＰに含まれるｒｏｕｔｅ−ｔｓｉ情報を用いてＬＳＩＤに接近することができる。ｒｏｕｔｅ−ｔｓｉ情報は、ＬＳＩＤを伝送する伝送セッションを識別する情報に該当し得る。
【０８５６】
図５３は、本発明の一実施例に係るシグナリング体系を用いて、レイヤードコーディング（ｌａｙｅｒｄ  ｃｏｄｉｎｇ）が放送サービスに適用された場合、受信機が放送サービスを取得する過程を示した図である。
【０８５７】
受信機が放送ストリームで、ＦＩＣを通じてＳＳＣに接近する過程は上述した通りである。
【０８５８】
レイヤードコーディングが適用されると、放送サービスに含まれる一つ以上のコンポーネントは、基本形態のコンポーネント及びエンハンスド（ｅｎｈａｎｃｅｄ）形態のコンポーネントを含むことができる。例えば、同一の放送サービス／コンテンツのために、ＨＤ画質のビデオを提供するコンポーネントを基本形態のコンポーネントとして提供し、該当のビデオをＵＨＤ画質にレンダリングするのに必要なデータを提供するコンポーネントをエンハンスド形態のコンポーネントとして提供することができる。
【０８５９】
受信機は、ＳＳＣでＡＴＳＣ  ＵＳＤを取得し、ＡＴＳＣ  ＵＳＤに含まれた情報を用いて、受信機が望む放送サービスに対するフルＭＰＤを提供する位置を探すことができる。受信機は、該当位置でＭＰＤを取得する。受信機は、ＭＰＤに含まれた情報を用いて、放送サービス／コンテンツに含まれるコンポーネントを伝送する位置を探すことができ、該当位置において、それぞれのコンポーネントを取得する。ＭＰＤは、一つのコンポーネントに対して、二つ以上のリプリゼンテーションが存在することを示すことができ、それぞれのリプレゼンテーションを識別する情報を含むことができる。二つ以上のリプリゼンテーションは、基本形態のコンポーネントとエンハンスド（ｅｎｈａｎｃｅｄ）形態のコンポーネントに該当し得る。
【０８６０】
上述した過程で、ＡＴＳＣ  ＵＳＤは＠ａｔｓｃＳｅｒｖｃｉｅＩｄによって識別される放送サービスに含まれるコンポーネントを取得するのに使用される基本住所に該当するｂａｓｅＰａｔｔｅｒｎ情報を含むことができる。ＭＰＤは、該当のｂａｓｅＰａｔｔｅｒｎ情報を基本ＵＲＬ（ＢａｓｅＵＲＬ）として使用することができる。
【０８６１】
受信機は、ＭＰＤに含まれるＢａｓｅＵＲＬ情報と、コンポーネントに該当するデータユニットである、リプリゼンテーションを識別する情報を取得する。すなわち、受信機は、放送サービスを構成するそれぞれのコンポーネントに該当するリプレゼンテーションを識別するリプレゼンテーション情報を取得することができる。受信機は、ＬＳＩＤに含まれた情報を用いて、リプレゼンテーション情報によって識別されるリプレゼンテーションを伝送する伝送セッションに接近することができる。受信機は、該当の伝送セッションにおいて、それぞれのコンポーネント又はセグメントを取得することができる。
【０８６２】
ＳＳＣはＳＤＰをさらに含むことができ、ＡＴＳＣ  ＵＳＤは、ＳＤＰが提供される位置を識別する情報（＠ａｔｓｃＳｄｐＵｒｉ）を含むことができる。
【０８６３】
受信機は、ＳＤＰに含まれるｒｏｕｔｅ−ｔｓｉ情報を用いてＬＳＩＤに接近することができる。ｒｏｕｔｅ−ｔｓｉ情報は、ＬＳＩＤを伝送する伝送セッションを識別する情報に該当し得る。
【０８６４】
図５４は、本発明の一実施例に係るシグナリング体系を用いて、放送サービス／コンテンツの一つの要素に対して複数のコンポーネントが提供される場合、受信機が放送サービスを取得する過程を示した図である。
【０８６５】
受信機が放送ストリームで、ＦＩＣを通じてＳＳＣに接近する過程は上述した通りである。
【０８６６】
放送サービス／コンテンツの要素（オーディオ又はビデオなど）に対して一つ以上のコンポーネントを提供することができる。同一の要素に対して一つ以上のコンポーネントが存在する場合、それぞれのコンポーネントは異なる品質や異なる属性を有するデータを含むことができる。例えば、ビデオ要素に対して２個のコンポーネントを提供することができ、そのうち一つのコンポーネントはＨＤ画質のビデオデータを含み、他の一つのコンポーネントはＵＨＤ画質のビデオデータを含むことができる。これらのコンポーネントは、放送システムで同時に提供することができ、視聴者（受信機）の選択によって、視聴者はＨＤ画質又はＵＨＤ画質のビデオを選択的に視聴することができる。
【０８６７】
受信機は、ＳＳＣでＡＴＳＣ  ＵＳＤを取得し、ＡＴＳＣ  ＵＳＤに含まれた情報を用いて、受信機が望む放送サービスに対するフルＭＰＤを提供する位置を探すことができる。受信機は、該当の位置でＭＰＤを取得する。受信機は、ＭＰＤに含まれた情報を用いて、放送サービス／コンテンツに含まれる各コンポーネントを伝送する位置を探すことができ、該当の位置で、それぞれのコンポーネントを取得する。ＭＰＤは、放送サービス／コンテンツの一つの要素に対して、二つ以上のリプリゼンテーションが存在することを示すことができ、それぞれのリプレゼンテーションを識別する情報を含むことができる。
【０８６８】
上述した過程で、ＡＴＳＣ  ＵＳＤは、＠ａｔｓｃＳｅｒｖｃｉｅＩｄによって識別される放送サービスに含まれる各コンポーネントを取得するのに使用される基本住所に該当するｂａｓｅＰａｔｔｅｒｎ情報を含むことができる。ＭＰＤは、該当のｂａｓｅＰａｔｔｅｒｎ情報を基本ＵＲＬ（ＢａｓｅＵＲＬ）として使用することができる。
【０８６９】
受信機は、ＭＰＤに含まれるＢａｓｅＵＲＬ情報と、コンポーネントに該当するデータユニットである、リプリゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を識別する情報を取得する。すなわち、受信機は、放送サービスを構成するそれぞれのコンポーネントに該当するリプレゼンテーションを識別するリプレゼンテーション情報を取得することができる。受信機は、ＬＳＩＤに含まれた情報を用いて、リプレゼンテーション情報によって識別されるリプレゼンテーションを伝送する伝送セッションに接近することができる。受信機は、該当の伝送セッションで、それぞれのコンポーネント又はセグメントを取得することができる。
【０８７０】
ＳＳＣはＳＤＰをさらに含むことができ、ＡＴＳＣ  ＵＳＤは、ＳＤＰが提供される位置を識別する情報（＠ａｔｓｃＳｄｐＵｒｉ）を含むことができる。
【０８７１】
受信機は、ＳＤＰに含まれるｒｏｕｔｅ−ｔｓｉ情報を用いてＬＳＩＤに接近することができる。ｒｏｕｔｅ−ｔｓｉ情報は、ＬＳＩＤを伝送する伝送セッションを識別する情報に該当し得る。
【０８７２】
図５５は、本発明の一実施例に係る、サービスマップテーブル（Ｓｅｒｖｉｃｅ  Ｍａｐ  Ｔａｂｌｅ；ＳＭＴ）を示した図である。
【０８７３】
本発明で提示するＳＭＴは、放送サービスに対する属性情報を提供するシグナリング構造である。ＳＭＴは、サービスレベルシグナリング（又は、ＳＳＣ）に含ませることができる。シグナリング方法によって、ＳＭＴで説明される情報はＵＳＤに含ませることもできる。すなわち、ＳＭＴはＵＳＤと類似する役割をすることもできる。
【０８７４】
本発明の一実施例に係るＳＭＴは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩｄ情報、＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ情報、ｆｕｌｌＭｐｄＵｒｉエレメント、Ｃａｐａｂｉｌｉｔｉｅｓエレメント、ＴａｒｇｅｔｉｎｇＰｒｏｐｅｒｔｉｅｓエレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメント、ＰｒｏｇｒａｍＴｉｔｌｅエレメント、ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｃｏｍｐｏｎｅｎｔエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報、ａｔｓｃＳｄｐＵＲＩエレメント、ａｔｓｃＵｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、及び／又はｂａｓｅＰａｔｔｅｒｎエレメントを含むことができる。
【０８７５】
＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＳＭＴのプロトコルのバージョンを示す。
【０８７６】
＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報は、サービスエントリに対するレファレンスである。該当の属性の値は、該当のエントリに割り当てられたｓｅｒｖｉｃｅＩｄの値と同一であり得る。＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報は、放送サービスを識別する情報に該当し得る。
【０８７７】
＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩｄ情報は、放送サービスを識別する、全世界的に唯一のＵＲＩであり得る。該当のパラメータは、ＥＳＧデータ（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）と関連させるのに使用することができる。
【０８７８】
＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ情報は、サービスの利用可能な言語を示すことができる。言語は、ＸＭＬデータタイプによって特定することができる。
【０８７９】
ｆｕｌｌＭｐｄＵｒｉエレメントは、ブロードキャスト上で選択的に、また、ブロードバンド上で伝達されるサービスのコンテンツコンポーネントに対する記述を含むＭＰＤ分割を参照することができる。ｆｕｌｌＭｐｄＵｒｉエレメントは、フルＭＰＤが提供される位置のＵＲＩを示すことができる。ｆｕｌｌＭｐｄＵｒｉエレメントはフルＭＰＤを含むこともできる。
【０８８０】
Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、受信機が該当サービスのコンテンツの有意義なプレゼンテーションを生成できるように要求される能力を特定することができる。実施例によって、本フィールドは、既に定義された能力グループを特定することもできる。ここで、能力グループは、有意義なプレゼンテーションのための能力属性値のグループであり得る。本フィールドは実施例によって省略可能である。
【０８８１】
ＴａｒｇｅｔｉｎｇＰｒｏｐｅｒｔｉｅｓエレメントは、視聴ターゲッティングのためのデータ及び／又は情報を含むことができる。視聴ターゲッティングは、特定視聴者に特定放送サービス／コンテンツを提供しようとする方式である。
【０８８２】
ｃｏｎｔｅｎｔａｄｖｉｓｏｒｙｒａｔｉｎｇエレメントは、視聴制限と関連したデータ及び／又は情報を含むことができる。
【０８８３】
ＰｒｏｇｒａｍＴｉｔｌｅエレメントは、放送サービス／コンテンツのプログラム題目を示す情報である。
【０８８４】
ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、放送網を介して伝送されるアプリケーションサービスと関連するデータ及び／又は情報を含むことができる。ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、所属したメディアプレゼンテーションの全ての期間にわたってサービスに属する該当のメディアコンポーネントを含む多重化又は非多重化された形態のブロードキャスト上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、放送網を介して伝達されるＤＡＳＨリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味することができる。ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、ｃｏｍｐｏｎｅｎｔエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報及び／又はａｔｓｃＳｄｐＵＲＩエレメントを含むことができる。
【０８８５】
ｃｏｍｐｏｎｅｎｔエレメントは、放送網を介して伝送されるアプリケーションに含まれるコンポーネントに関する情報を含む。ｃｏｍｐｏｎｅｎｔエレメントは、放送網を介して伝送されるアプリケーションを識別する情報を含むことができる。
【０８８６】
ｂａｓｅＰａｔｔｅｒｎエレメントは、含まれた期間にペアレントリプレゼンテーションのメディア分割を要求するためにＤＡＳＨクライアントによって使用される分割ＵＲＬの全ての部分に対してマッチされるように受信機によって使用される文字パターンであり得る。マッチは、該当の要求されたメディア分割がブロードキャストトランスポート上で伝達されることを暗示する。それぞれのａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントとａｔｓｃＵｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで表現されるＤＡＳＨリプレゼンテーションの伝達を受けることができるＵＲＬ住所において、そのＵＲＬの一部分などは特定のパターンを有することができるが、そのパターンを本フィールドによって記述することができる。この情報を通じて、一定部分のデータに対する区分が可能になる。提示されたデフォルト値は、実施例によって変更可能である。図示した使用（ｕｓｅ）列は、各フィールドに関するものであって、Ｍは必須フィールド、Ｏはオプショナルフィールド、ＯＤはデフォルト値を有するオプショナルフィールド、ＣＭは条件付きの必須のフィールドを意味することができる。０…１〜０…Ｎは、該当フィールドの可能個数を意味することができる。
【０８８７】
＠ＤＰ＿ＩＤ情報は、アプリケーションを含むデータパイプを識別する情報である。
【０８８８】
＠ＢｒｏａｄｃａｓｔＩＤ情報は、アプリケーションを提供する放送網又は放送社を識別する情報である。
【０８８９】
＠ＩＰＡｄｄｒｅｓｓ情報は、アプリケーションに含まれるデータが伝送される位置のＩＰ住所を示す情報である。
【０８９０】
＠ＵＤＰＰｏｒｔ情報は、アプリケーションに含まれるデータが伝送される位置のＵＤＰ番号を示す情報である。
【０８９１】
＠ＴＳＩ情報は、アプリケーションに含まれるデータを伝送する伝送セッションを識別する情報である。
【０８９２】
ａｔｓｃＳｄｐＵＲＩエレメントＡＴＳＣ  ＳＤＰが提供される位置を示すＵＲＩを識別する情報を含むことができる。
【０８９３】
ａｔｓｃＵｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、所属したメディアプレゼンテーションの全ての期間にわたってサービスに属する構成メディアコンテンツコンポーネントを含む多重化又は非多重化された形態のブロードバンド上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、ブロードバンドを介して伝達されるＤＡＳＨリプレゼンテーションを意味することができる。
【０８９４】
図５６は、本発明の一実施例に係るＡＴＳＣ  ＵＳＤを示した図である。
【０８９５】
本発明の一実施例に係るＵＳＤは、バンドル（ｂｕｎｄｌｅ）形態で、一つ以上のＵＳＤに含まれる情報を含むことができる。これをＡＴＳＣ  ＢＤ（Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｏｒ）(又はＵＳＢＤ）と命名することができる。
【０８９６】
ａｔｓｃＢＤエレメントは、ａｔｓｃＵＳＤエレメントを含むことができる。
【０８９７】
ａｔｓｃＵＳＤエレメントは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｆｕｌｌＭｐｄＵｒｉエレメント、ＣａｐａｂｉｌｉｔｉｅｓＤｅｓｃｒｉｐｔｉｏｎエレメント、ＴａｒｇｅｔｉｎｇＤｅｓｃｒｉｐｔｉｏｎエレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＤｅｓｃｒｉｐｔｉｏｎエレメント、ＰｒｏｇｒａｍＴｉｔｌｅエレメント、ｎａｍｅエレメント、＠ｌａｎｇ情報、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｆｅａｔｕｒｅエレメント、ｒｅｑｕｉｒｅｄＣａｐａｂｉｌｉｔｉｅｓエレメント、ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメント、ｒ７：ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、ｒ８：ａｌｔｅｒｎａｔｉｖｅＡｃｃｅｓｓＤｅｌｉｖｅｒｙエレメント、ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメント、ｔｉｍｅＳｈｉｆｔｉｎｇＢｕｆｆｅｒエレメント、ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｓｅｒｖｉｃｅＡｒｅａエレメント、ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＳｔｒｅａｍＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報、ａｔｓｃＳｄｐＵＲＩエレメント、ａｃｃｅｓｓＧｒｏｕｐＩｄ情報、ａｓｓｏｃｉａｔｅｄＰｒｏｃｅｄｕｒｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ｐｒｏｔｅｃｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、及び／又はａｃｃｅｓｓＰｏｉｎｔＮａｍｅ情報を含むことができる。
【０８９８】
＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＵＳＤのプロトコルのバージョンを示す情報である。
【０８９９】
＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報は、放送サービスを識別する情報である。
【０９００】
ｆｕｌｌＭｐｄＵｒｉエレメントは、フルＭＰＤが提供される位置のＵＲＩを示す情報である。
【０９０１】
ＣａｐａｂｉｌｉｔｉｅｓＤｅｓｃｒｉｐｔｉｏｎエレメントは、放送サービス／コンテンツを有意義に表出するために、受信機に要求される能力（ｃａｐａｂｉｌｉｔｙ）を識別する情報を含むことができる。
【０９０２】
ＴａｒｇｅｔｉｎｇＤｅｓｃｒｉｐｔｉｏｎエレメントは、視聴ターゲッティングのためのデータ及び／又は情報を含むことができる。
【０９０３】
ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＤｅｓｃｒｉｐｔｉｏｎエレメントは、視聴制限のためのデータ及び／又は情報を含むことができる。
【０９０４】
ＰｒｏｇｒａｍＴｉｔｌｅエレメントは、放送プログラムの題目を示す情報を含むことができる。
【０９０５】
ｎａｍｅエレメントは、＠ｌａｎｇ情報によって与えられるサービスのネームを示すことができる。ｎａｍｅエレメントは、サービスネームの言語を示す＠ｌａｎｇ情報を含むことができる。言語はＸＭＬデータタイプによって特定することができる。
【０９０６】
ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、放送サービスが提供される言語を識別する情報を含む。
【０９０７】
ｒｅｑｕｉｒｅｄＣａｐａｂｉｌｉｔｉｅｓエレメントは、特定サービスのために要求される受信機の能力を示す情報を含むことができる。
【０９０８】
ｆｅａｔｕｒｅエレメントは、放送サービスに含まれる特定サービスを識別する情報を含むことができる。
【０９０９】
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、放送サービスが伝達される方法に関するデータ及び／又は情報を含むことができる。
【０９１０】
ｒ７：ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメントは、ブロードバンドで伝送される放送サービスに接近するためのＵＲＩ情報を含むことができる。
【０９１１】
ｂａｓｅＰａｔｔｅｒｎエレメントは、上述したような基本ＵＲＩ情報を含むことができる。
【０９１２】
ｒ８：ａｌｔｅｒｎａｔｉｖｅＡｃｃｅｓｓＤｅｌｉｖｅｒｙエレメントは、放送サービスを伝送する代替方法に関するデータ及び／又は情報を含む。
【０９１３】
ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメントは、代替方法によって伝送される放送サービスがブロードバンドを介して伝送される場合、放送サービスが提供される位置のＵＲＩを示す情報を含む。
【０９１４】
ｔｉｍｅＳｈｉｆｔｉｎｇＢｕｆｆｅｒエレメントは、タイムシフティングのためのバッファに関するデータ及び／又は情報を含む。
【０９１５】
ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、放送網を介して伝送されるアプリケーションサービスに対するデータ及び／又は情報を含む。
【０９１６】
ｓｅｒｖｉｃｅＡｒｅａエレメントは、アプリケーションサービスが提供される領域又はアプリケーションサービスのタイプを識別する情報を含むことができる。
【０９１７】
ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、ブロードバンドを介して伝送されるアプリケーションサービスに関するデータ及び／又は情報を含むことができる。
【０９１８】
ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントに対する説明は、上述した説明の通りである。
【０９１９】
ｂａｓｅＰａｔｔｅｒｎエレメントに対する説明は、上述した説明の通りである。
【０９２０】
＠ＤＰ＿ＩＤ情報に対する説明は、上述した説明の通りである。
【０９２１】
＠ＢｒｏａｄｃａｓｔＳｔｒｅａｍＩＤ情報は、アプリケーションサービスを伝送する放送ストリーム（又は放送局）を識別する情報である。
【０９２２】
＠ＩＰＡｄｄｒｅｓｓ情報は、アプリケーションサービスが提供される位置のＩＰ住所を示す情報である。
【０９２３】
＠ＵＤＰＰｏｒｔ情報に対する説明は、上述した説明の通りである。
【０９２４】
＠ＴＳＩ情報に対する説明は、上述した説明の通りである。
【０９２５】
ａｔｓｃＳｄｐＵＲＩエレメントに対する説明は、上述した説明の通りである。
【０９２６】
ａｃｃｅｓｓＧｒｏｕｐＩｄ情報は、アクセスグループ（ａｃｃｅｓｓ  ｇｒｏｕｐ）を識別する情報である。アクセスグループは、アクセスネットワークのリストを定義する。
【０９２７】
ａｓｓｏｃｉａｔｅｄＰｒｏｃｅｄｕｒｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、関連するプロシージャ記述（ａｓｓｏｃｉａｔｅｄ  Ｐｒｏｃｅｄｕｒｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）が提供される位置のＵＲＩを示す情報である。
【０９２８】
ｐｒｏｔｅｃｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、保護記述（ｐｒｏｔｅｃｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）が提供される位置のＵＲＩを示す情報である。
【０９２９】
ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、セッション記述（ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）が提供される位置のＵＲＩを示す情報である。
【０９３０】
ａｃｃｅｓｓＰｏｉｎｔＮａｍｅ情報は、アクセスポイントのネームを示す情報である。
【０９３１】
図５７は、本発明の他の実施例に係る、ａｔｓｃ  ＵＳＤを示した図である。
【０９３２】
本発明の他の実施例に係る、放送サービスに接近するための最小限の情報がａｔｓｃ  ＵＳＤに含まれるようにａｔｓｃ  ＵＳＤを定義することができる。
【０９３３】
本発明の他の実施例に係るａｔｓｃ  ＵＳＤは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｆｕｌｌＭｐｄＵｒｉエレメント、ＣａｐａｂｉｌｉｔｉｅｓＤｅｓｃｒｉｐｔｉｏｎ（ＣａｐａｂｉｌｉｔｉｅｓＰｒｏｐｅｒｔｉｅｓ）エレメント、ＴａｒｇｅｔｉｎｇＤｅｓｃｒｉｐｔｉｏｎ（ＴａｒｇｅｔｉｎｇＰｒｏｐｅｒｔｉｅｓ）エレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＤｅｓｃｒｉｐｔｉｏｎ（ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇｓ）エレメント、ＰｒｏｇｒａｍＴｉｔｌｅエレメント、ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメント、ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＳｔｒｅａｍＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報、ａｔｓｃＳｄｐＵＲＩエレメント、ｓｅｒｖｉｃｅＩｄ情報及び／又はｓｖ：ｓｃｈｅｍＶｅｒｓｉｏｎエレメントを含むことができる。
【０９３４】
本発明の他の実施例に係る、ａｔｓｃ  ＵＳＤに含まれ得るエレメント及び／又は情報に対する説明は、上述した説明の通りである。
【０９３５】
図５８は、本発明の一実施例に係る放送信号を生成処理する方法を示したフローチャートである。
【０９３６】
放送送信機は、一つ以上の放送サービスのための放送データをエンコードする（ＪＳ５８０１０）。
【０９３７】
放送送信機は、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコードする（ＪＳ５８０２０）。
【０９３８】
放送送信機は、前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードする（ＪＳ５８０３０）。
【０９３９】
放送送信機は、前記放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する（ＪＳ５８０４０）。
【０９４０】
第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送することができる。
【０９４１】
第２レベルシグナリング情報は、第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）を識別するＰＬＰ  ＩＤ情報を含むことができる。
【０９４２】
図５９は、本発明の一実施例に係る放送システムを示した図である。
【０９４３】
本発明の一実施例に係る放送システムは、放送送信機Ｊ５９１００及び／又は放送受信機Ｊ５９２００を含むことができる。
【０９４４】
放送送信機Ｊ５９１００は、放送データエンコーダＪ５９１１０、シグナリングエンコーダＪ５９１２０及び／又は放送信号生成器Ｊ５９１３０を含むことができる。
【０９４５】
放送受信機Ｊ５９２００は、放送信号受信部Ｊ５９２１０、プロセッサＪ５９２２０及び／又はディスプレイ部Ｊ５９２３０を含むことができる。
【０９４６】
放送データエンコーダＪ５９１１０は、一つ以上の放送サービスのための放送データをエンコードする。
【０９４７】
シグナリングエンコーダーＪ５９１２０は、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報及び／又は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードする。
【０９４８】
放送信号生成器Ｊ５９１３０は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する。
【０９４９】
放送信号受信部Ｊ５９２１０は、一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報を含む放送信号を受信する。ここで、前記第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送され、前記第２レベルシグナリング情報は、前記第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）を識別するＰＬＰ  ＩＤ情報を含むことができる。
【０９５０】
プロセッサＪ５９２２０は、放送信号内の既に定められた位置で前記第２レベルシグナリング情報を抽出し、前記第２レベルシグナリング情報に含まれるＩＰ住所情報及びＰＬＰ  ＩＤ情報を用いて前記第１レベルシグナリング情報を抽出し、前記第１レベルシグナリング情報を用いて前記放送サービスを取得し、前記放送サービスを表出するように制御する。
【０９５１】
ディスプレイ部Ｊ５９２３０は、放送サービスをディスプレイする。
【０９５２】
モジュール又はユニットは、メモリ（又は、記憶ユニット）に記憶された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサによって実行することができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実現されてもよい。このコードは、プロセッサが読み出し可能な記憶媒体に書き込まれ、よって、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサによって読み出されてもよい。
【０９５３】
説明の便宜のため、各図を区別して説明したが、各図に開示した実施例を組み合わせて新しい実施例として具現するように設計することも可能である。そして、通常の技術者の必要に応じて、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み出し可能な記録媒体を設計することも、本発明の権利範囲に属する。
【０９５４】
本発明に係る装置及び方法は、上述した実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。
【０９５５】
一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサが読み出し可能な記録媒体に、プロセッサが読み出し可能なコードとして具現することができる。プロセッサが読み出し可能な記録媒体は、プロセッサによって読み出されるデータが記憶されるいかなる種類の記録装置をも含む。プロセッサが読み出し可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み出し可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み出し可能なコードが記憶され、実行されてもよい。
【０９５６】
また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者にとって様々な変形実施が可能であることはもちろんであり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。
【０９５７】
そして、当該明細書では、物の発明及び方法の発明の両方が説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。
【０９５８】
本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。
【０９５９】
本明細書において、装置の発明も方法の発明も言及されており、装置及び方法の発明に関する説明は互いに補完して適用されてもよい。
【実施例】
【０９６０】
様々な実施例が、本発明を実施するための形態において説明されている。
【産業上の利用可能性】
【０９６１】
本発明は、一連の放送信号提供分野で利用される。
【０９６２】
本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。
【図１】
0006449897.tif 000041
【図２】
0006449897.tif 000042
【図３】
0006449897.tif 000043
【図４】
0006449897.tif 000044
【図５】
0006449897.tif 000045
【図６】
0006449897.tif 000046
【図７】
0006449897.tif 000047
【図８】
0006449897.tif 000048
【図９】
0006449897.tif 000049
【図１０】
0006449897.tif 000050
【図１１】
0006449897.tif 000051
【図１２】
0006449897.tif 000052
【図１３】
0006449897.tif 000053
【図１４】
0006449897.tif 000054
【図１５】
0006449897.tif 000055
【図１６】
0006449897.tif 000056
【図１７】
0006449897.tif 000057
【図１８】
0006449897.tif 000058
【図１９】
0006449897.tif 000059
【図２０】
0006449897.tif 000060
【図２１】
0006449897.tif 000061
【図２２】
0006449897.tif 000062
【図２３】
0006449897.tif 000063
【図２４】
0006449897.tif 000064
【図２５】
0006449897.tif 000065
【図２６】
0006449897.tif 000066
【図２７】
0006449897.tif 000067
【図２８】
0006449897.tif 000068
【図２９】
0006449897.tif 000069
【図３０】
0006449897.tif 000070
【図３１】
0006449897.tif 000071
【図３２】
0006449897.tif 000072
【図３３】
0006449897.tif 000073
【図３４】
0006449897.tif 000074
【図３５】
0006449897.tif 000075
【図３６】
0006449897.tif 000076
【図３７】
0006449897.tif 000077
【図３８】
0006449897.tif 000078
【図３９】
0006449897.tif 000079
【図４０】
0006449897.tif 000080
【図４１】
0006449897.tif 000081
【図４２】
0006449897.tif 000082
【図４３】
0006449897.tif 000083
【図４４】
0006449897.tif 000084
【図４５】
0006449897.tif 000085
【図４６】
0006449897.tif 000086
【図４７】
0006449897.tif 000087
【図４８】
0006449897.tif 000088
【図４９】
0006449897.tif 000089
【図５０】
0006449897.tif 000090
【図５１】
0006449897.tif 000091
【図５２】
0006449897.tif 000092
【図５３】
0006449897.tif 000093
【図５４】
0006449897.tif 000094
【図５５】
0006449897.tif 000095
【図５６】
0006449897.tif 000096
【図５７】
0006449897.tif 000097
【図５８】
0006449897.tif 000098
【図５９】
0006449897.tif 000099