(57)【要約】【課題】放送サービスのコンテンツを時間帯別に効率的に区別し、時間帯別に区別されたコンテンツに関する情報を効率的に伝送・受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置および放送受信装置の動作方法を実現する。【解決手段】放送受信装置が開示される。放送受信装置は、放送信号を受信する放送受信部と、放送信号に基づいて、放送信号に有されたプログラムの主なコンテンツであるショーの属性をシグナリングするショーの情報を獲得する制御部とを有する。【選択図】図１０６
2017508326.tif 000002
【特許請求の範囲】
【請求項１】
放送信号を受信する放送受信部と、
前記放送信号に基づいて、放送信号に有されたプログラムの主なコンテンツであるショーの属性をシグナリングするショーの情報を獲得する制御部と、を有する、放送受信装置。
【請求項２】
前記ショーの情報は、ショーの長さ、ショーを説明するテキスト、ショーに関連したセグメントの個数およびショーに関連したセグメントをシグナリングするセグメント情報ブロックのうち少なくともいずれか１つを有し、
前記セグメントは、前記プログラムを構成する時間的区間である、請求項１に記載の放送受信装置。
【請求項３】
前記プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間セグメントとに区分され、
前記制御部は、前記中間セグメントを前記放送受信装置のユーザの特性に基づいてターゲティングされたコンテンツを再生する、請求項２に記載の放送受信装置。
【請求項４】
前記プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間セグメントとに区分され、
前記制御部は、前記中間セグメントを前記放送受信装置の特性に基づいてターゲティングされたコンテンツを再生する、請求項２に記載の放送受信装置。
【請求項５】
前記セグメント情報ブロックは、セグメント識別子、セグメントの開始時間を示す情報およびセグメントの長さを示す情報のうち少なくともいずれか１つを有する、請求項２に記載の放送受信装置。
【請求項６】
前記セグメントの開始時間は、前記セグメントが有されたプログラムの開始を基準とした相対時間である、請求項５に記載の放送受信装置。
【請求項７】
前記制御部は、前記ショーの情報に基づいて前記プログラムの情報を表示するサービスガイドを表示する、請求項１に記載の放送受信装置。
【請求項８】
前記制御部は、同一のショーを有する複数のセグメントを表示する、請求項７に記載の放送受信装置。
【請求項９】
前記制御部は、前記サービスガイドにプログラムに関連したアプリケーションを表示する、請求項７に記載の放送受信装置。
【請求項１０】
前記制御部は、ユーザの入力に基づいて、前記アプリケーションをお気に入りリストに追加するか、または、前記アプリケーションをダウンロードする請求項９に記載の放送受信装置。
【請求項１１】
放送受信装置の動作方法において、
放送信号を受信するステップと、
前記放送信号に基づいて、放送信号に有されたプログラムの主なコンテンツであるショーの属性をシグナリングするショーの情報を獲得するステップと、を有する動作方法。
【請求項１２】
前記ショーの情報は、
ショーの長さ、ショーを説明するテキスト、ショーに関連したセグメントの個数およびショーに関連したセグメントをシグナリングするセグメント情報ブロックのうち少なくともいずれか１つを有し、
前記セグメントは、前記プログラムを構成する時間的区間である、請求項１１に記載の動作方法。
【請求項１３】
前記プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間セグメントとに区分され、
前記中間セグメントを前記放送受信装置のユーザの特性に基づいてターゲティングされたコンテンツを再生するステップをさらに有する、請求項１２に記載の動作方法。
【請求項１４】
前記プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間セグメントとに区分され、
前記中間セグメントを前記放送受信装置の特性に基づいてターゲティングされたコンテンツを再生するステップをさらに有する、請求項１２に記載の動作方法。
【請求項１５】
前記セグメント情報ブロックは、セグメント識別子、セグメントの開始時間を示す情報およびセグメントの長さを示す情報のうち少なくともいずれか１つを有する、請求項１２に記載の動作方法。
【請求項１６】
前記セグメントの開始時間は、前記セグメントが有されたプログラムの開始を基準とした相対時間である、請求項１５に記載の動作方法。
【請求項１７】
前記ショーの情報に基づいて前記プログラムの情報を表示するサービスガイドを表示するステップをさらに有する、請求項１１に記載の動作方法。
【請求項１８】
前記ショーの情報に基づいて前記プログラムの情報を表示するサービスガイドを表示するステップは、
同一のショーを有する複数のセグメントを表示するステップを有する、請求項１７に記載の動作方法。
【請求項１９】
前記サービスガイドにプログラムに関連したアプリケーションを表示するステップをさらに有する、請求項１７に記載の動作方法。
【請求項２０】
放送サービスが有するプログラムの主なコンテンツであるショーの属性を獲得し、前記ショーの属性に基づいて前記ショーの属性をシグナリングするショーの情報を生成する制御部と、
前記ショーの情報を有する放送信号を伝送する伝送部と、を有する、放送伝送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送伝送装置、放送伝送装置の動作方法、放送受信装置および放送受信装置の動作方法に関するものである。
【背景技術】
【０００２】
デジタル放送は、アナログ放送と違い、１つの放送サービスが複数のメディアコンポーネントを含むことができる。これによって、ユーザは、１つの放送サービスに関する複数のメディアを選択して視聴することができる。例えば、１つの映画に対する英語、中国語、日本語のダビング音声のいずれかを選択して視聴することができる。また、ユーザは、１つのドラマに対して、英語、中国語、日本語字幕のうちいずれか１つを選択して視聴することができる。
【０００３】
また、最近、通信環境に応じて異なる品質のメディアコンポーネントを伝送する適応型ストリーミングサービス（adaptive streaming service）が脚光を浴びている。これによって、ユーザは通信環境に応じて同一コンテンツを含む多様な品質のメディアコンポーネントのうちいずれか１つを選択して視聴できるようになった。
【０００４】
また、１つの画面で複数のメディアコンポーネントを同時に表示するマルチビュー(multi view)サービスが提供されている。これによって、ユーザは、複数の映像またはデータ放送を１つの画面で視聴できるようになった。例えば、ユーザは、野球試合を見ながら他の球場の試合を別途のPIP(Picture In Picture)画面を介して視聴することができる。
【０００５】
このように、複数のメディアコンポーネントを含む放送サービスが多様化され、増加することに伴い、メディアコンポーネントを効率的に（効率良く）伝送・受信する放送伝送装置および放送受信装置が必要になった。
【０００６】
また、ユーザの特性に応じて、それに合わせたコンテンツを伝達する（deliver）必要がある。例えば、同じ放送サービスを視聴するユーザに、それぞれユーザの特性が反映された広告を個別に伝達できれば、広告の効果を最大にすることができる。ただし、放送サービスを単純にプログラムで区別（区分）する（distinguish）場合、このような視聴者に合わせた広告の提供が難しい。特に、プログラムの中間（途中）で（during the middle of a program）伝送される中間広告の視聴者に合わせた広告の提供が難しい。従って、放送サービスのコンテンツを時間帯別に効率的に区別し、時間帯別に区別されたコンテンツに関する情報を効率的に伝送（送信）・受信する放送伝送装置と放送受信装置が必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明の一実施例は、放送サービスのコンテンツを時間帯別に効率的に区別し、時間帯別に区別されたコンテンツに関する情報を効率的に伝送・受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置および放送受信装置の動作方法を提供することを目的とする。
【０００８】
特に、本発明の一実施例は、放送サービスのコンテンツを時間帯別に効率的に区別し、時間帯別に区別されたコンテンツに関する情報を効率的に伝送・受信する伝送装置、放送伝送装置の動作方法、放送受信装置および放送受信装置の動作方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一実施例に係る放送受信装置は、放送信号を受信する放送受信部と、放送信号に基づいて、放送信号に有されたプログラムの主な（プライマリ）コンテンツ（primary content）であるショー（show）の属性をシグナリング（通知する）（signals）するショーの情報を獲得する制御部と、を有する。
【００１０】
このとき、ショーの情報は、ショーの長さ、ショーを説明するテキスト、ショーに関連したセグメントの個数およびショーに関連したセグメントをシグナリングするセグメント情報ブロックのうち少なくともいずれか１つを有し、セグメントは、プログラムを構成する時間的区間（temporal section）である。
【００１１】
このとき、プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間（隙間）セグメント（interstitial segment）とに区分され（divided into）、制御部は、中間セグメントを放送受信装置のユーザの特性に基づいてターゲティング（ターゲットと）された（対象となる）（targeted）コンテンツを再生することができる。
【００１２】
また、プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間セグメントとに区分され、制御部は、中間セグメントを放送受信装置の特性に基づいてターゲティングされたコンテンツを再生することができる。
【００１３】
また、セグメント情報ブロックは、セグメント識別子、セグメントの開始時間を示す情報およびセグメントの長さを示す情報のうち少なくともいずれか１つを有することができる。
【００１４】
このとき、セグメントの開始時間は、セグメントが有されたプログラムの開始を基準とした相対時間である。
【００１５】
また、制御部は、ショーの情報に基づいてプログラムの情報を表示するサービスガイドを表示することができる。
【００１６】
また、制御部は、同一ショーを有する複数のセグメントを表示することができる。
【００１７】
また、制御部は、サービスガイドにプログラムに関連したアプリケーションを表示することができる。
【００１８】
このとき、制御部は、ユーザの入力に基づいて、アプリケーションをお気に入りリストに追加するか、または、アプリケーションをダウンロードすることができる。
【００１９】
本発明の一実施例に係る放送受信装置の動作方法は、放送信号を受信するステップと、放送信号に基づいて、放送信号に有されたプログラムの主な（プライマリ）コンテンツ（primary content）であるショーの属性をシグナリングする（通知する）（signals）ショーの情報を獲得するステップと、を有することができる。
【００２０】
このとき、ショーの情報は、ショーの長さ、ショーを説明するテキスト、ショーに関連したセグメントの個数およびショーに関連したセグメントをシグナリングするセグメント情報ブロックのうち少なくともいずれか１つを有し、セグメントは、プログラムを構成する時間的区間（temporal section）である。
【００２１】
このとき、プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間セグメントとに区分され、制御部は、中間セグメントを放送受信装置のユーザの特性に基づいてターゲティングされたコンテンツを再生することができる。
【００２２】
また、プログラムは、ショーを有するショーセグメントとショー以外の他のコンテンツを有する中間セグメントとに区分され、制御部は、中間セグメントを放送受信装置の特性に基づいてターゲティングされたコンテンツを再生することができる。
【００２３】
また、セグメント情報ブロックは、セグメント識別子、セグメントの開始時間を示す情報およびセグメントの長さを示す情報のうち少なくともいずれか１つを有することができる。
【００２４】
このとき、セグメントの開始時間は、セグメントが有されたプログラムの開始を基準とした相対時間である。
【００２５】
また、動作方法は、ショーの情報に基づいてプログラムの情報を表示するサービスガイドを表示するステップをさらに有することができる。
【００２６】
また、ショーの情報に基づいてプログラムの情報を表示するサービスガイドを表示するステップは、同一ショーを有する複数のセグメントを表示するステップをさらに有することができる。
【００２７】
また、動作方法は、サービスガイドにプログラムに関連したアプリケーションを表示するステップをさらに有することができる。
【００２８】
本発明の一実施例に係る放送伝送装置は、放送サービスが有するプログラムの主な（プライマリ）コンテンツ（primary content）であるショー（show）の属性を獲得し、ショーの属性に基づいてショーの属性をシグナリングする（通知する）（signals）ショーの情報を生成する制御部と、ショーの情報を有する放送信号を伝送する伝送部と、を有する。
【発明の効果】
【００２９】
本発明の一実施例は、放送サービスのコンテンツを時間帯別に効率的に区別し、時間帯別に区別されたコンテンツに関する情報を効率的に伝送・受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置および放送受信装置の動作方法を提供することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施例に係る次世代放送サービスに関する放送信号送信装置の構造を示す図である。
【図２】本発明の一実施例に係る入力フォーマット(Input formatting)モジュールを示す図である。
【図３】本発明の他の一実施例に係る入力フォーマット(Input formatting)ブロックを示す図である。
【図４】本発明の他の一実施例に係る入力フォーマット(Input formatting)ブロックを示す図である。
【図５】本発明の一実施例に係るBICM(bit interleaved coding & modulation)ブロックを示す図である。
【図６】本発明の他の一実施例に係るBICMブロックを示す図である。
【図７】本発明の一実施例に係るフレーム構築（ビルディング）(Frame Building、フレーム生成)ブロックを示す図である。
【図８】本発明の一実施例に係るOFDM(orthogonal frequency division multiplexing)生成(generation)ブロックを示す図である。
【図９】本発明の一実施例に係る次世代放送サービスに関する放送信号受信装置の構造を示す図である。
【図１０】本発明の一実施例に係るフレーム構造を示す図である。
【図１１】本発明の一実施例に係るフレームのシグナリング階層構造を示す図である。
【図１２】本発明の一実施例に係るプリアンブルシグナリングデータを示す図である。
【図１３】本発明の一実施例に係るPLS１データを示す図である。
【図１４】本発明の一実施例に係るPLS２データを示す図である。
【図１５】本発明の他の一実施例に係るPLS２データを示す図である。
【図１６】本発明の一実施例に係るフレームの論理(logical)構造を示す図である。
【図１７】本発明の一実施例に係るPLS(Physical Layer Signaling)マッピング（マップ）を示す図である。
【図１８】本発明の一実施例に係るEAC(Emergency Alert Channel)マッピングを示す図である。
【図１９】本発明の一実施例に係るFIC(Fast Information Channel)マッピングを示す図である。
【図２０】本発明の一実施例に係るDPのタイプを示す図である。
【図２１】本発明の一実施例に係るDPマッピングを示す図である。
【図２２】本発明の一実施例に係るFEC(Forward Error Correction)構造を示す図である。
【図２３】本発明の一実施例に係るビットインターリーブ（インターリービング）を示す図である。
【図２４】本発明の一実施例に係るセル-ワードデマルチプレックス（逆多重化）(cell-word demultiplexing)を示す図である。
【図２５】本発明の一実施例に係るタイムインターリーブを示す図である。
【図２６】本発明の一実施例に係るツイスト行列ブロックインターリーバ(twisted row-column block interleaver)の基本動作を示す図である。
【図２７】本発明の他の一実施例に係るツイスト行列ブロックインターリーバの動作を示す図である。
【図２８】本発明の一実施例に係るツイスト行列ブロックインターリーバの対角線方向の読み出し（リーディング）（reading）パターンを示す図である。
【図２９】本発明の一実施例に係る各インターリーブアレイ(array)からインターリーブされたXFECBLOCKを示す図である。
【図３０】本発明の一実施例に係る放送サービスをサポート（支援）する（support）ためのプロトコルスタック(protocol stack)を示す図である。
【図３１】本発明の一実施例に係る放送伝送フレームを示す図である。
【図３２】本発明の他の実施例に係る放送伝送フレームを示す図である。
【図３３】本発明の一実施例に係る放送サービスを伝送する伝送パケット（transport packet）の構造を示す図である。
【図３４】本発明の一実施例に係る放送サービスを伝送する伝送パケットが含むnetwork_protocolフィールドが持つ値を示す図である。
【図３５】本発明の一実施例に係る放送受信装置の構成を示す図である。
【図３６】本発明の他の実施例に係る放送受信装置の構成を示す図である。
【図３７】本発明の一実施例に係る放送サービスシグナリングテーブルおよび放送サービス伝送経路シグナリング情報が、放送サービスおよび放送サービス伝送経路をシグナリングすることを示す図である。
【図３８】本発明の一実施例に係る放送サービスシグナリングテーブルを示す図である。
【図３９】本発明の一実施例に係る放送サービスシグナリングテーブルが含むservice_categoryフィールドが持つ値を示す図である。
【図４０】本発明の他の実施例に係る放送サービスシグナリングテーブルを示す図である。
【図４１】本発明の一実施例に係るストリーム識別記述子を示す図である。
【図４２】本発明の一実施例に係る放送伝送装置が放送サービスシグナリングテーブルを伝送する動作を示す図である。
【図４３】本発明の一実施例に係る放送受信装置が放送サービスシグナリングテーブルを受信する動作を示す図である。
【図４４】本発明の一実施例に係る放送サービス伝送経路シグナリング情報を示す図である。
【図４５】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が含むdelivery_network_typeフィールドが持つ値を示す図である。
【図４６】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、IPストリームを介した放送サービスの伝送をシグナリングすることを示す図である。
【図４７】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、他の（another）放送局(broadcaster)のIPストリームを介した放送サービスの伝送をシグナリングすることを示す図である。
【図４８】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、FLUTEセッションを介した放送サービスの伝送をシグナリングすることを示す図である。
【図４９】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、他の放送局(broadcaster)のFLUTEプロトコルを介した放送サービスの伝送をシグナリングすることを示す図である。
【図５０】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、MPEG-２TSストリームを介した放送サービスの伝送をシグナリングすることを示す図である。
【図５１】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、他の放送局(broadcaster)のパケットベースのストリームを介した放送サービスの伝送をシグナリングすることを示す図である。
【図５２】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、IPベースの放送ネットワークで伝送されるパケットベースのストリームを介した放送サービスの伝送をシグナリングすることを示す図である。
【図５３】本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、URLを介して放送サービスをシグナリングすることを示す図である。
【図５４】本発明の一実施例に係る放送伝送装置が、放送サービス伝送経路シグナリング情報を伝送することを示す図である。
【図５５】本発明の一実施例に係る放送受信装置が、放送サービス伝送経路に基づいて放送サービスを受信することを示す図である。
【図５６】本発明の一実施例に係るメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報を示す図である。
【図５７】本発明の一実施例に係るメディアコンポーネントシグナリング情報が含むcomponent_typeフィールドの値を示す図である。
【図５８】本発明の他の実施例に係るメディアコンポーネントシグナリング情報が含むcomponent_dataシンタックスを示す図である。
【図５９】本発明の一実施例に係るメディアコンポーネントの種類および役割（ロール）（role）を示す図である。
【図６０】本発明の一実施例に係るコンプレックス（複合）（complex）コンポーネントの構成を示す図である。
【図６１】本発明の一実施例に係るコンプレックスビデオ（complex video）コンポーネントを示す図である。
【図６２】本発明の一実施例に係るコンプレックスオーディオ（complex audio）コンポーネントを示す図である。
【図６３】本発明の他の実施例に係るメディアコンポーネントの種類および役割を示す図である。
【図６４】本発明の一実施例に係るコンプレックスビデオコンポーネントの構成を示す図である。
【図６５】本発明の他の実施例に係るコンプレックスビデオコンポーネントを示す図である。
【図６６】本発明の他の実施例に係るコンプレックスビデオコンポーネントを示す図である。
【図６７】本発明の一実施例に係るオーディオサービスのメディアコンポーネントの構成を示す図である。
【図６８】本発明の一実施例に係るオーディオおよびビデオの両方を含む放送サービスの構成を示す図である。
【図６９】本発明の一実施例に係るユーザ要求（request）コンテンツサービスの構成を示す図である。
【図７０】本発明の一実施例に係るスタンドアローンNRTデータサービスの構成を示す図である。
【図７１】本発明の一実施例に係るメディアコンポーネント情報を示す図である。
【図７２】本発明の他の実施例に係るメディアコンポーネントシグナリング情報が含むcomponent_dataフィールドの値を示す図である。
【図７３】本発明の一実施例に係るコンプレックスコンポーネント情報を示す図である。
【図７４】本発明の一実施例に係るコンプレックスコンポーネント情報を含む記述子を示す図である。
【図７５】本発明の一実施例に係る関連コンポーネントリスト情報を示す図である。
【図７６】本発明の一実施例に係るNRT情報テーブルを示す図である。
【図７７】本発明の一実施例に係るNRT情報ブロックを示す図である。
【図７８】本発明の一実施例に係るNRTサービス記述子を示す図である。
【図７９】本発明の一実施例に係るグラフィックアイコン情報を示す図である。
【図８０】本発明の一実施例に係るグラフィックアイコン情報のicon_transport_modeが持つ値を示す図である。
【図８１】本発明の一実施例に係るグラフィックアイコン情報のcoordinate_systemフィールドが持つ値を示す図である。
【図８２】本発明の一実施例に係るメディアコンポーネントリスト情報を示す図である。
【図８３】本発明の一実施例に係る放送サービスシグナリングテーブルでメディアコンポーネントまたは放送サービスをURIを介してマッピングすることを示す図である。
【図８４】放送サービスまたはメディアコンポーネントのターゲティング基準（対象とする基準）（targeting criterion）をシグナリングするターゲティング基準情報を示す図である。
【図８５】放送サービスまたはメディアコンポーネントを説明するテキスト情報を示す図である。
【図８６】放送サービス、プログラムまたはショーセグメントのタイトル情報を示す図である。
【図８７】放送サービス、プログラムまたはショーセグメントのジャンル情報を示す図である。
【図８８】放送サービス、メディアコンポーネントまたはコンテンツアイテムに係るターゲットデバイスをシグナリングするターゲットデバイス情報を示す図である。
【図８９】放送サービスが複数のセグメントに区分されることを示す図である。
【図９０】本発明の一実施例に係るショーの情報を示す図である。
【図９１】本発明の一実施例に係るショーの情報ブロックを示す図である。
【図９２】本発明の一実施例に係るセグメント情報ブロックを示す図である。
【図９３】本発明の一実施例に係る放送伝送装置が、ショーの情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を伝送することを示す図である。
【図９４】本発明の一実施例に係る放送受信装置が、ショーの情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を受信することを示す図である。
【図９５】本発明の一実施例に係るプログラム情報を示す図である。
【図９６】本発明の一実施例に係るプログラム情報ブロックを示す図である。
【図９７】本発明の他の実施例に係るプログラム情報ブロックを示す図である。
【図９８】本発明の他の実施例に係るプログラム情報ブロックを示す図である。
【図９９】本発明の他の実施例に係るプログラム情報ブロックを示す図である。
【図１００】本発明の他の実施例に係るプログラム情報ブロックを示す図である。
【図１０１】本発明の一実施例に係るセグメント情報を示す図である。
【図１０２】本発明の一実施例に係るセグメント情報ブロックを示す図である。
【図１０３】本発明の一実施例に係るターゲティングセグメントセット情報を示す図である。
【図１０４】本発明の一実施例に係る放送伝送装置が、プログラム情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を伝送することを示す図である。
【図１０５】本発明の一実施例に係る放送受信装置が、プログラム情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を受信することを示す図である。
【図１０６】本発明の一実施例に係る放送サービスの種類に応じた下位属性との継承（相続）関係（inheritance relationship with a sub-property）を示す図である。
【図１０７】本発明の一実施例に係る連続コンポーネントと連続コンポーネントの下位属性を有するコンポーネントとの継承関係を示す図である。
【図１０８】本発明の一実施例に係るpresentableコンポーネントとpresentableコンポーネントの下位属性を有するコンポーネントとの継承関係を示す図である。
【図１０９】本発明の一実施例に係るサービスとサービスに含まれたプログラム、プログラムに含まれたセグメントの関係を示す図である。
【図１１０】presentableオーディオコンポーネントの階層構造を示す図である。
【図１１１】放送受信装置が自動起動（実行）（auto-launch）アプリケーションベースのサービスを放送サービスガイドを介して表示し、これをお気に入りとして格納またはダウンロードする動作を図示する（見せる）（illustrating）フローチャートである。
【発明を実施するための形態】
【００３１】
以下、添付した図面を参照して本発明の実施例に関して、本発明が属する技術分野で通常の知識を有した者が容易に実施できるように詳しく説明する。なお、本発明は多様な異なる形態で具現することができ、ここで説明する実施例に限定されない。そして、図面において、本発明を明確に説明するために説明と関係のない部分は省略しており、明細書全体において類似する部分に対しては、類似する図面符号を付している。
【００３２】
また、ある部分がある構成要素を「含む」とした場合、これは特に限定する記載がない限り、他の構成要素を除くものではなく、他の構成要素をさらに含むことができることを意味する。
【００３３】
本発明の一実施例に係る放送（ブロードキャスト）伝送装置およびその方法は、地上波放送サービスのためのベースプロファイル、モバイル放送サービスのためのハンドヘルドプロファイルおよびUHDTVサービスのためのアドバンスドプロファイルに分類（区分）する（categorized）ことができる。この場合、ベースプロファイルは、地上波放送サービスおよびモバイル放送サービスの両方のためのプロファイルとして用いられる。このとき、ベースプロファイルは、モバイルプロファイルを含むプロファイルのコンセプトとして定義することができる。これは、設計者の意図によって変更可能である。
【００３４】
本発明は、一実施例によって非MIMO(non-Multiple Input Multiple Output)またはMIMO方式を介して、次世代放送サービスに関する放送信号を処理することができる。本発明の一実施例に係る非MIMO方式は、MISO(Multiple Input Single Output)方式、SISO(Single Input Single Output)方式などを含むことができる。
【００３５】
以下では、説明の便宜上、MISOまたはMIMO方式は２つのアンテナを用いるが、本発明は２つ以上のアンテナを用いるシステムに適用可能である。本発明は、特定用途において要求される性能を達成するとともに受信器の複雑さを最小化するために、最適化された３つの物理（フィジカル）プロファイル(PHY profile)(ベース(base)、ハンドヘルド(handheld)、アドバンスド(advanced)プロファイル)を定義することができる。物理プロファイルは、該当する（対応する）（corresponding）受信器が具現すべきすべての構造のサブセットである。
【００３６】
３つの物理プロファイルは、ほとんどの機能ブロックを共有するが、特定ブロックおよび/またはパラメータにおいては若干異なる。後で物理プロファイルを追加して定義することができる。システムの発展のために、フューチャプロファイルは、FEF(future extension frame)を介して単一RF(radio frequency)チャネルに存在するプロファイルとマルチプレックス（多重化）される。各物理プロファイルに関する詳しい内容は後述する。
【００３７】
１．ベースプロファイル
ベースプロファイルは、主にルーフトップ（屋上）(roof-top)アンテナと接続（連結）される（connected）固定された受信装置の主要な用途（main use）を示す。ベースプロファイルは、所定の場所に移動できるが、相対的固定受信のカテゴリ（範疇）（relatively stationary reception category）に属する携帯装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行（実装）によってハンドヘルド装置または車両用に拡張することができるが、このような使用の用途は、ベースプロファイル受信器の動作では期待できない。
【００３８】
受信のターゲット信号対雑音比の範囲は、略１０〜２０dBであるが、これは既存の放送システム(例えば、ATSC A/５３)の１５dB信号対雑音比受信能力を含む。受信器の複雑さおよび消費電力は、ハンドヘルドプロファイルを用いるバッテリで駆動されるハンドヘルド装置におけるほど重要ではない。ベースプロファイルに対する重要なシステムパラメータが以下の表１に記載されている。
【００３９】
【表１】
2017508326.tif 000003
【００４０】
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリ電源で駆動されるハンドヘルドおよび車両用装置における使用のために設計される。該当装置は、歩行者または車両の速度で移動することができる。受信器の複雑さだけでなく、消費電力は、ハンドヘルドプロファイルの装置の具現のために大変重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０〜１０dBであるが、より低い室内受信を目的とした場合、０dB以下に（below 0dB）達するように設定することができる。
【００４１】
低い信号対雑音比能力だけでなく、受信器の移動性によって現れたドップラ効果に対する復原力（resilience）は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに関する重要なシステムパラメータが以下の表２に記載されている。
【００４２】
【表２】
2017508326.tif 000004
【００４３】
３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行の複雑さに対する代価としてより高いチャネル能力を提供する。該当プロファイルは、MIMO送信および受信を用いることを要求し、UHDTVサービスはターゲット用途（target use）であり、このために該当プロファイルが特別に設計される。向上した能力は、与えられた帯域幅でサービス数の増加、例えば、複数のSDTVまたはHDTVサービスを許容（可能に）する（allow）ことにも用いられる。
【００４４】
アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０〜３０dBである。MIMO伝送は、初期には既存の楕円分極（偏波）伝送装備(elliptically-polarized transmission equipment)を使用し、後で全出力交差分極伝送(full-power cross-polarized transmission)に拡張することができる。アドバンスドプロファイルに対する重要なシステムパラメータが以下の表３に記載されている。
【００４５】
【表３】
2017508326.tif 000005
【００４６】
この場合、ベースプロファイルは、地上波放送サービスおよびモバイル放送サービスの両方に対するプロファイルとして用いられる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために使用される。また、アドバンスドプロファイルは、MIMOを有するベースプロファイルに対するアドバンスドプロファイルおよびMIMOを有するハンドヘルドプロファイルに対するアドバンスドプロファイルに分類することができる。そして、これらの（該当）３つのプロファイルは、設計者の意図によって変更可能である。
【００４７】
次の用語および定義は本発明に適用可能であり、設計によって変更可能である。
【００４８】
補助ストリーム：future extensionまたは放送会社やネットワークオペレータによって要求されることにより使用できるまだ定義されていない変調およびコーディングデータを伝達するセルのシーケンス。
【００４９】
ベースデータパイプ(base data pipe)：サービスシグナリングデータを伝達するデータパイプ。
【００５０】
ベースバンドフレーム(またはBBFRAME)：１つのFECエンコーディング処理（過程）（process）(BCHおよびLDPCエンコーディング)に対する入力を形成するKbchビットのセット（集合）（set）
【００５１】
セル(cell)：OFDM伝送の１つのキャリアによって伝達される変調値。
【００５２】
コーディングブロック(coded block)：PLS１データのLDPCエンコーディングされたブロックまたはPLS２データのLDPCエンコーディングされたブロックのうちの１つ。
【００５３】
データパイプ(data pipe)：１つまたは複数のサービスまたはサービスコンポーネントを伝達できるサービスデータまたは関連したメタデータを伝達する物理層(physical layer)における論理（ロジカル）チャネル。
【００５４】
データパイプユニット(DPU、data pipe unit)：データセルをフレームにおけるデータパイプに割当できる基本単位（ユニット）。
【００５５】
データシンボル(data symbol)：プリアンブルシンボルではないフレームにおけるOFDMシンボル(フレームシグナリングシンボルおよびフレームエッジ(edge)シンボルはデータシンボルに含まれる。)。
【００５６】
DP_ID：該当８ビットフィールドは、SYSTEM_IDによって識別されたシステム内でデータパイプを一意に識別する。
【００５７】
ダミーセル(dummy cell)：PLS(Physical Layer Signaling)シグナリング、データパイプ、または補助ストリームのために使用されていない残っている容量を満たすために使用される擬似ランダム値を伝達するセル。
【００５８】
FAC(emergency alert channel、緊急警報チャネル)：EAS情報データを伝達するフレームの一部。
【００５９】
フレーム(frame)：プリアンブルで始まりフレームエッジシンボルで終了する物理層(physical layer)タイムスロット。
【００６０】
frame repetition unit：スーパーフレーム(super-frame)で８回繰り返されるFEFを含む同一または異なる物理プロファイルに属するフレームのセット。
【００６１】
FIC(fast information channel、高速情報チャネル)：サービスと該当ベースデータパイプとの間でのマッピング情報を伝達するフレームにおける論理チャネル。
【００６２】
FECBLOCK：データパイプデータのLDPCエンコーディングされたビットのセット。
【００６３】
FFTサイズ：基本周期Tのサイクルで表現されたアクティブシンボル周期Tsと同一の、特定モードに使用される名目上のFFTサイズ。
【００６４】
フレームシグナリングシンボル(frame signaling symbol)：PLSデータの一部を伝達する、FFTサイズ、ガードインターバル(guard interval)、およびスキャッタード(scattered)パイロットパターンの特定の組合せで、フレームの始まりで使用されるより高いパイロット密度を有するOFDMシンボル。
【００６５】
フレームエッジシンボル(frame edge symbol)：FFTサイズ、ガードインターバル、およびスキャッタードパイロットパターンの特定の組合せでフレームの終わりで使用されるより高いパイロット密度を有するOFDMシンボル。
【００６６】
フレームグループ(frame-group)：スーパーフレームにおいて同一物理プロファイルタイプを有するすべてのフレームのセット。
【００６７】
FEF(future extension frame)：プリアンブルで始まり、将来の拡張に使用できるスーパーフレーム内の物理層(physical layer)タイムスロット。
【００６８】
フューチャキャスト(futurecast)UTBシステム：入力が１つまたは複数のMPEG２-TSもしくはIP(Internet Protocol)または一般ストリームであり、出力がRFシグナル（信号）（signal）である提案された物理層(physical layer)放送システム。
【００６９】
入力ストリーム(input stream、インプットストリーム)：システムによってエンドユーザ（end users）に伝達されるサービスのアンサンブル（集合体）(ensemble)のためのデータストリーム。
【００７０】
ノーマル(normal)データシンボル：フレームシグナリングシンボルおよびフレームエッジシンボルを除いたデータシンボル。
【００７１】
物理プロファイル(PHY profile)：該当する受信器が具現すべきすべての構造のサブセット。
【００７２】
PLS：PLS１およびPLS２から構成された物理層(physical layer)シグナリングデータ
【００７３】
PLS１：PLS２のデコーディングに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するFSS(frame signaling symbol)に伝達されるPLSデータの一番目の（first）セット。
【００７４】
NOTE：PLS１データは、フレームグループのデュレーション(duration)の間一定である。
【００７５】
PLS２：データパイプおよびシステムに関するより詳細なPLSデータを伝達するFSSで伝送されるPLSデータの二番目のセット。
【００７６】
PLS２ダイナミック（動的）データ(dynamic data)：フレームごとにダイナミックに変化する（変わる）（change）PLS２データ。
【００７７】
PLS２スタティック（静的）データ(static data)：フレームグループのデュレーションの間スタティックである（remains static）（変わらない）PLS２データ。
【００７８】
プリアンブルシグナリングデータ(preamble signaling data)：プリアンブルシンボルによって伝達され、システムの基本モードの確認に使用されるシグナリングデータ。
【００７９】
プリアンブルシンボル(preamble symbol)：基本PLSデータを伝達し、フレームの始まりに位置する固定長のパイロットシンボル。
【００８０】
NOTE：プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、およびFFTサイズを検出するために高速初期バンドスキャン（fast initial band scan）に主に使用される。
【００８１】
将来使用するためにリザーブされる(reserved for future use)：現在の文書（present document）で定義されないが将来定義される。
【００８２】
スーパーフレーム(superframe)：８フレーム繰返し単位（ユニット）のセット（set of eight frame repetition units）。
【００８３】
タイムインターリーブブロック(time interleaving block、TI block)：タイムインターリーバメモリの１つの用途に該当する、タイムインターリーブが実行されるセルのセット。
【００８４】
タイムインターリーブグループ(time interleaving group、TI group)：整数であり、ダイナミックに変化するXFECBLOCKの数からなり、特定データパイプに対するダイナミック容量割当が実行される単位。
【００８５】
NOTE：タイムインターリーブグループは、１つのフレームに直接マッピングまたは複数のフレームにマッピングされる。タイムインターリーブグループは、１つまたは複数のタイムインターリーブブロックを含むことができる。
【００８６】
タイプ１データパイプ(Type１DP)：すべてのデータパイプがフレームにTDM(time division multiplexing)方式でマッピングされるフレームのデータパイプ。
【００８７】
タイプ２データパイプ(Type２DP)：すべてのデータパイプがフレームにFDM方式でマッピングされるフレームのデータパイプ。
【００８８】
XFECBLOCK：１つのLDPC FECBLOCKのすべてのビットを伝達するNcellsセルのセット。
【００８９】
図１は、本発明の一実施例に係る次世代放送サービスに関する放送信号送信装置の構造を示す。
【００９０】
本発明の一実施例に係る次世代放送サービスに関する放送信号送信装置は、入力フォーマットブロック(Input Format block)１０００、BICM(Bit Interleaved Coding & Modulation)ブロック１０１０、フレーム構築ブロック(Frame Building block)１０２０、OFDM(Orthogonal Frequency Division Multiplexing)生成ブロック(OFDM generation block)１０３０、およびシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作に関して説明する。
【００９１】
IPストリーム/パケットおよびMPEG２-TSは、主な（メイン）（main）入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらのデータ入力に加えて、管理情報が入力されて各入力ストリームに対する該当帯域幅のスケジューリングおよび割当を制御する。１つまたは複数のTSストリーム、IPストリームおよび/または一般ストリーム入力が同時に許容される（可能である）（allowed）。
【００９２】
入力フォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディングおよび変調が適用される１つまたは複数のデータパイプにデマルチプレックスすることができる。データパイプは、ロバスト（堅固）性(robustness)制御の基本単位であり、これはQoS(Quality of Service)に影響を及ぼす。１つまたは複数のサービスまたはサービスコンポーネントが、１つのデータパイプによって伝達される。入力フォーマットブロック１０００の詳しい動作は後述する。
【００９３】
データパイプは１つまたは複数のサービスまたはサービスコンポーネントを伝達できるサービスデータまたは関連メタデータを伝達する物理層(physical layer)における論理チャネルである。
【００９４】
また、データパイプユニットは、１つのフレームにおいてデータセルをデータパイプに割り当てるための基本単位（ユニット）である。
【００９５】
入力フォーマットブロック１０００において、パリティ(parity)データがエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値のコンステレーション（配置）シンボル（complex-value constellation symbols）にマッピングされる。該当シンボルは、該当データパイプに使用される特定のインターリーブの深さにわたって（across a specific interleaving depth）インターリーブされる。アドバンスドプロファイルにおいて、BICMブロック１０１０でMIMOエンコーディングが実行され、追加データ経路がMIMO伝送のために出力に追加される。BICMブロック１０１０の詳しい動作は後述する。
【００９６】
フレーム構築ブロック１０２０は、１つのフレーム内で入力データパイプのデータセルをOFDMシンボルにマッピングすることができる。マッピング後、周波数領域ダイバーシチのために、特に周波数選択フェージングチャネル（frequency-selective fading channels）を防止するために、周波数インターリーブが利用される。フレーム構築ブロック１０２０の詳しい動作は後述する。
【００９７】
プリアンブルを各フレームの始まりに挿入した後、OFDM生成ブロック１０３０は、サイクリックプレフィックス(cyclic prefix)をガードインターバルとして有する既存のOFDM変調を適用することができる。アンテナの空間（スペース）ダイバーシチのために、分散した(distributed)MISO方式が各送信器にわたって適用される。また、PAPR(Peak-to-Average Power Ratio)方式が時間領域で実行される。フレキシブル（柔軟）なネットワーク方式のために、該当提案は、多様なFFTサイズ、ガードインターバルの長さ、該当パイロットパターンのセットを提供する。OFDM生成ブロック１０３０の詳しい動作は後述する。
【００９８】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理層(physical layer)シグナリング情報を生成することができる。また、該当シグナリング情報は、対象の（関心のある）（of interest）サービスが受信器側で適切に回復（復元）するように伝送される。シグナリング生成ブロック１０４０の詳しい動作は後述する。
【００９９】
図２、３、４は、本発明の実施例に係る入力フォーマットブロック１０００を示す。各図面に関して説明する。
【０１００】
図２は、本発明の一実施例に係る入力フォーマットブロックを示す。図２は、入力信号が単一入力ストリーム(single input stream)である場合の入力フォーマットブロックを示す。
【０１０１】
図２に図示された入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。
【０１０２】
物理層(physical layer)への入力は、１つまたは複数のデータストリームからなることができる。それぞれのデータストリームは、１つのデータパイプによって伝達される。モードアダプテーション（適応）(mode adaptaion)モジュールは、入力されるデータストリームをBBF(baseband frame)のデータフィールドにスライスする。該当システムは、３種類の入力データストリーム、すなわちMPEG２-TS、IP、GS(generic stream)をサポートする。MPEG２-TSは、最初のバイトが同期バイト(０x４７)である固定長(１８８バイト)のパケットを特徴とする。IPストリームは、IPパケットヘッダ内でシグナリングされる可変長IPデータグラムパケットから構成される。該当システムは、IPストリームに対してIPv４およびIPv６の両方をサポートする。GSは、カプセル化パケットヘッダ内でシグナリングされる可変長パケットまたは一定の長さのパケットから構成される。
【０１０３】
(a)は信号データパイプに対するモードアダプテーション(mode adaptaion)ブロック２０００およびストリームアダプテーション(stream adaptation)２０１０を示し、(b)はPLSデータを生成および処理するためのPLS生成ブロック２０２０およびPLSスクランブラ２０３０を示す。各ブロックの動作に関して説明する。
【０１０４】
入力ストリームスプリッタは、入力されたTS、IP、GSストリームを複数のサービスまたはサービスコンポーネント(オーディオ、ビデオなど)ストリームに分割する。モードアダプテーション(mode adaptaion)モジュール２０１０は、CRCエンコーダ、BB(baseband)フレームスライサ、およびBBフレームヘッダ挿入ブロックから構成される。
【０１０５】
CRCエンコーダは、ユーザパケット(user packet、UP)レベルでのエラー検出のための３種類のCRCエンコーディング、すなわちCRC-８、CRC-１６、CRC-３２を提供する。算出されたCRCバイトは、UPした後に添付される。CRC-８はTSストリームに使用され、CRC-３２はIPストリームに使用される。GSストリームがCRCエンコーディングを提供しない場合、提案されたCRCエンコーディングが適用されなければならない。
【０１０６】
BBフレームスライサは、入力を内部論理ビットフォーマットにマッピングする。最初の受信ビットはMSBとして定義する。BBフレームスライサは、使用可能データフィールドの容量と同じ数の入力ビットを割り当てる。BBFペイロードと同じ数の入力ビットを割り当てるために、UPストリームがBBFのデータフィールドに適合するようにスライスされる。
【０１０７】
BBフレームヘッダ挿入ブロックは、２バイトの固定長BBFヘッダをBBフレームの前に挿入することができる。BBFヘッダは、STUFFI(１ビット)、SYNCD(１３ビット)、およびRFU(２ビット)から構成される。固定された２バイトBBFヘッダだけでなく、BBFは２バイトBBFヘッダの終わりに拡張フィールド(１または３バイト)を有することができる。
【０１０８】
ストリームアダプテーション(stream adaptation)２０１０は、スタッフィング(stuffing)挿入ブロックおよびBBスクランブラから構成される。
【０１０９】
スタッフィング挿入ブロックは、スタッフィングフィールドをBBフレームのペイロードに挿入することができる。ストリームアダプテーション(stream adaptation)に対する入力データがBBフレームを満たすのに十分である場合、STUFFIは０に設定され、BBFはスタッフィングフィールドを有しない。そうでない場合、STUFFIは１に設定され、スタッフィングフィールドはBBFヘッダの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダおよび可変サイズのスタッフィングデータを含む。
【０１１０】
BBスクランブラは、エネルギ分散のために完全な（完成した）（complete）BBFをスクランブルする。スクランブルシーケンスはBBFと同期化される。スクランブルシーケンスはフィードバックシフトレジスタによって生成される。
【０１１１】
PLS生成ブロック２０２０は、PLSデータを生成することができる。PLSは、受信器に物理レイヤ(physical layer)データパイプに接続できる手段を提供する。PLSデータは、PLS１データおよびPLS２データから構成される。
【０１１２】
PLS１データは、PLS２データのデコーディングに必要なパラメータだけでなく、システムに関する基本情報を伝達する、固定されたサイズ、コーディング、変調を有するフレームにおけるFSSシンボルで（in the FSS symbols）伝達されるPLSデータの一番目のセットである。PLS１データは、PLS２データの受信およびデコーディングに要求されるパラメータを含む基本送信パラメータを提供する。また、PLS１データは、フレームグループのデュレーションの間一定である。
【０１１３】
PLS２データは、データパイプおよびシステムに関するより詳細なPLSデータを伝達するFSSシンボルで伝送されるPLSデータの二番目のセットである。PLS２は、受信器が所望するデータパイプのデコーディングに十分な情報を提供するパラメータを含む。PLS２シグナリングは、さらにPLS２スタティックデータ(PLS２-STATデータ)およびPLS２ダイナミックデータ(PLS２-DYNデータ)の二種類のパラメータから構成される。PLS２スタティックデータは、フレームグループのデュレーションの間スタティックであるPLS２データであり、PLS２ダイナミックデータは、フレームごとにダイナミックに変化するPLS２データである。
【０１１４】
PLSデータに関する詳しい内容は後述する。
【０１１５】
PLSスクランブラ２０３０は、エネルギ分散のために生成されたPLSデータをスクランブルすることができる。
【０１１６】
前述したブロックは、省略してもよく、類似または同一機能を有するブロックによって代替することもできる。
【０１１７】
図３は、本発明の他の一実施例に係る入力フォーマットブロックを示す。
【０１１８】
図３に図示された入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施例に該当する。
【０１１９】
図３は、入力信号がマルチ入力ストリーム(multi input stream)に該当する場合、入力フォーマットブロックのモードアダプテーション(mode adaptaion)ブロックを示す。
【０１２０】
マルチ入力ストリーム(multi input stream)を処理するための入力フォーマットブロックのモードアダプテーション(mode adaptaion)ブロックは、複数の入力ストリームを独立して処理することができる。
【０１２１】
図３に示すように、マルチ入力ストリーム(multi input stream)をそれぞれ処理するためのモードアダプテーション(mode adaptaion)ブロックは、入力ストリームスプリッタ(input stream splitter)３０００、入力ストリームシンクロナイザ(input stream synchronizer)３０１０、補償遅延(compensation delay)ブロック３０２０、ヌル（無効）パケット削除ブロック(null packet deletion block)３０３０、ヘッダコンプレッション（圧縮）ブロック(header compression block)３０４０、CRCエンコーダ(CRC encoder)３０５０、BBフレームスライサ(BB frame slicer)３０６０、およびBBヘッダ挿入ブロック(BB header insertion block)３０７０を含むことができる。モードアダプテーション(mode adaptaion)ブロックの各ブロックに関して説明する。
【０１２２】
CRCエンコーダ３０５０、BBフレームスライサ３０６０、およびBBヘッダ挿入ブロック３０７０の動作は、図２を参照して説明したCRCエンコーダ、BBフレームスライサ、およびBBヘッダ挿入ブロックの動作に該当するので、その説明は省略する。
【０１２３】
入力ストリームスプリッタ３０００は、入力されたTS、IP、GSストリームを複数のサービスまたはサービスコンポーネント(オーディオ、ビデオなど)ストリームに分割する。
【０１２４】
入力ストリームシンクロナイザ３０１０はISSYと呼ぶことができる。ISSYは、いかなる入力データフォーマットに対してもCBR(constant bit rate)および一定のEnd-to-End伝送遅延を保障するのに適合した手段を提供することができる。ISSYは、TSを伝達する複数のデータパイプの場合に常に利用され、GSストリームを伝達する複数のデータパイプにオプションとして（選択的に）（optionally）利用される。
【０１２５】
補償遅延(compensating delay)ブロック３０２０は、受信器で追加メモリを必要とせず、TSパケット再結合メカニズムを許容するために、ISSY情報の挿入により分割されたTSパケットストリームを遅延させることができる。
【０１２６】
ヌルパケット削除ブロック３０３０は、TS入力ストリームの場合のみに使用される。一部のTS入力ストリームまたは分割されたTSストリームは、VBR(variable bit-rate)サービスをCBR TSストリームに収容するために存在する複数のヌルパケットを有することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ヌルパケットは識別（確認）され（identified）伝送されないようにすることができる。受信器で、除去されたヌルパケットは、伝送に挿入されたDNP(deleted null-packet、削除されたヌルパケット)カウンタを参照して、本来存在していた正確な場所に再挿入することができ、CBRが保障されタイムスタンプ(PCR)を更新する必要がなくなる。
【０１２７】
ヘッダコンプレッションブロック３０４０は、TSまたはIP入力ストリームに対する伝送効率を増加させるために、パケットヘッダ圧縮を提供することができる。受信器は、ヘッダの特定部分に関するアプリオリ（演繹的）(a priori)情報を持つことがあるので、この既知の情報(known information)は送信器から削除することができる。
【０１２８】
TSに対して、受信器は同期バイト（sync-byte）構成(０x４７)およびパケット長さ(１８８バイト)に関するアプリオリ情報を有することができる。入力されたTSが１つのPIDのみを有するコンテンツを伝達する場合、すなわち、１つのサービスコンポーネント(ビデオ、オーディオなど)またはサービスサブコンポーネント(SVCベースレイヤ、SVCエンハンスメントレイヤ、MVCベースビュー、またはMVC依存ビュー)に対してのみ、TSパケットヘッダ圧縮がTSに(オプションとして)適用されるようにすることができる。TSパケットヘッダ圧縮は、入力ストリームがIPストリームである場合オプションとして使用される。
【０１２９】
上記ブロックは、省略するか、または類似もしくは同一機能を有するブロックで代替することができる。
【０１３０】
図４は、本発明の他の一実施例に係る入力フォーマット（入力書式設定）(Input formatting)ブロックを示す。
【０１３１】
図４に図示された入力フォーマットブロックは、図１を参照して説明した入力フォーマットブロック１０００の一実施形態に対応する。
【０１３２】
図４は、入力シグナルが複数の入力ストリームに対応する場合、入力フォーマットモジュールのストリーム適応ブロックを示す。
【０１３３】
図４に示すように、複数の入力ストリームをそれぞれ処理するためのモード適応ブロックは、スケジューラ４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンドシグナリング４０３０、BBフレームスクランブラ４０４０、PLS生成（生産）（generation）ブロック４０５０、およびPLSスクランブラ４０６０を含むことができる。説明は、ストリーム適応ブロックのそれぞれのブロックに対して提供される。
【０１３４】
スタッフィングデータブロック４０２０、BBフレームスクランブラ４０４０、PLS生成ブロック４０５０およびPLSスクランブラ４０６０は、図２に図示されたスタッフィング挿入ブロック、BBスクランブラ、PLS生成ブロックおよびPLSスクランブラに対応する。従って、それに関する説明は省略する。
【０１３５】
スケジューラ４０００は、それぞれのDPのFECBLOCKの量からフレーム全体にわたる全体的なセル割当（overall cell allocation across the entire frame）を決定することができる。PLS、EACおよびFICのための割当を含んで、スケジューラは、フレームのFSS内PLSセルまたはインバンドシグナリングとして伝送されるPLS２-DYNデータの値を生成する。FECBLOCK、EACおよびFICに関する詳しい説明は後述する。
【０１３６】
１フレーム遅延ブロック４０１０は、入力データを１伝送フレーム遅延させることによって、次のフレームに関するスケジュールリング情報を、DP内に挿入されるインバンドシグナリング情報のための現在のフレームを介して伝送することができる（The 1-Frame delay block 4010 can delay the input data by one transmission frame such that scheduling information about the next frame can be transmitted through the current frame for in-band signaling information to be inserted into the DPs）。
【０１３７】
インバンドシグナリング４０３０は、フレームのDP内PLS２データの遅延されない部分に挿入される。
【０１３８】
上述したブロックは、類似または同一機能を有するブロックによって省略または代替することができる。
【０１３９】
図５は、本発明の一実施例に係るBICMブロックを示す。
【０１４０】
図５に図示されたBICMブロックは、図１を参照して説明したBICMブロック１０１０の一実施例に該当する。
【０１４１】
上述したように、本発明の一実施例に係る次世代放送サービスに関する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、UHDTVサービスなどを提供することができる。
【０１４２】
QoSが、本発明の一実施例に係る次世代放送サービスに関する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当（対応）するデータは、それぞれ異なる方式を介して処理されなければならない。従って、本発明の一実施例に係るBICMブロックは、SISO、MISO、MIMO方式をそれぞれのデータ経路に該当するデータパイプに独立して適用することにより、各データパイプを独立して処理することができる。結果として、本発明の一実施例に係る次世代放送サービスに関する放送信号送信装置は、それぞれのデータパイプを介して伝送される各サービスまたはサービスコンポーネントに関するQoSを調節することができる。
【０１４３】
(a)はベースプロファイルおよびハンドヘルドプロファイルによって共有されるBICMブロックを示し、(b)はアドバンスドプロファイルのBICMブロックを示す。
【０１４４】
ベースプロファイルおよびハンドヘルドプロファイルによって共有されるBICMブロックおよびアドバンスドプロファイルのBICMブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０１４５】
ベースプロファイルおよびハンドヘルドプロファイルに対するBICMブロックおよびアドバンスドプロファイルに対するBICMブロックのそれぞれの処理ブロックに関して説明する。
【０１４６】
ベースプロファイルおよびハンドヘルドプロファイルに対するBICMブロックの処理ブロック５０００は、データFECエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパ５０３０、SSD(signal space diversity)エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
【０１４７】
データFECエンコーダ５０１０は、外部コーディング(BCH)および内部コーディング(LDPC)を利用してFECBLOCK手順を生成するために、入力BBFに対してFECエンコーディングを実行することができる。外部コーディング(BCH)は、オプションの（選択的な）optional）コーディング方法である。データFECエンコーダ５０１０の具体的な動作に関しては後述する。
【０１４８】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながらデータFECエンコーダ５０１０の出力をインターリーブして、LDPCコードおよび変調方式の組合せで最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作に関しては後述する。
【０１４９】
コンステレーションマッパ５０３０は、QPSK、QAM-１６、不均一QAM(NUQ-６４、NUQ-２５６、NUQ-１０２４)または不均一コンステレーション(NUC-１６、NUC-６４、NUC-２５６、NUC-１０２４)を利用して、ベースおよびハンドヘルドプロファイルにおいてビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルにおいてセルワードデマルチプレクサ５０１０-１からのセルワードを変調して、パワーが正規化されたコンステレーションポイントelを提供することができる。該当コンステレーションマッピングは、データパイプに対してのみ適用される。NUCが任意の形態を有する反面、QAM-１６およびNUQは正四角形形状を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転すれば、回転したコンステレーションは本来のものと正確に重なる。回転対称特性（"rotation-sense" symmetric property）によって実数および虚数コンポーネントの容量および平均パワーが相互に等しくなる。NUQおよびNUCはいずれも各コードレート(code rate)に対して特別に定義され、使用される特定の１つは、PLS２データに保管されたパラメータDP_MODによってシグナリングされる。
【０１５０】
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリーブのパラメータは、それぞれのデータパイプに対して異なるように設定することができる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０１５１】
アドバンスドプロファイルに対するBICMブロックの処理ブロック５０００-１は、データFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、およびタイムインターリーバを含むことができる。ただし、処理ブロック５０００-１は、セルワードデマルチプレクサ５０１０-１およびMIMOエンコーディングブロック５０２０-１をさらに含むという点で、処理ブロック５０００と区別される。
【０１５２】
また、処理ブロック５０００-１におけるデータFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、タイムインターリーバの動作は、前述したデータFECエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパ５０３０、タイムインターリーバ５０５０の動作に対応（該当）する（correspond to）ので、その説明は省略する。
【０１５３】
セルワードデマルチプレクサ５０１０-１は、アドバンスドプロファイルのデータパイプがMIMO処理のために単一セルワードストリームをデュアルセルワードストリームに分離するために使用される。セルワードデマルチプレクサ５０１０-１の具体的な動作に関しては後述する。
【０１５４】
MIMOエンコーディングブロック５０２０-１は、MIMOエンコーディング方式を利用してセルワードデマルチプレクサ５０１０-１の出力を処理することができる。MIMOエンコーディング方式は、放送信号送信のために最適化されている。MIMO技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に、放送に関して、相互に異なる信号伝播（電波）特性による２つのアンテナ間の受信信号パワーの差またはチャネルの強いLOSコンポーネントにより、MIMOから容量利得が得難くなる（the strong LOS component of the channel or a difference in the received signal power between two antennas caused by different signal propagation characteristics makes it difficult to get capacity gain from MIMO）。提案されたMIMOエンコーディング方式は、MIMO出力信号のうちの１つの位相ランダム化および回転に基づくプリコーディングを利用してこの問題を克服する。
【０１５５】
MIMOエンコーディングは、送信器および受信器の両方において少なくとも２つのアンテナを必要とする２x２MIMOシステムのために意図されている。２つのMIMOエンコーディングモードは、本提案であるFR-SM(Full-Rate Spatial Multiplexing)およびFRFD-SM(Full-Rate Full-Diversity Spatial Multiplexing)で定義される。FR-SMエンコーディングは、受信器側での比較的小さい複雑さの増加で容量増加を提供する反面、FRFD-SMエンコーディングは、受信器側での大きい複雑さの増加で容量増加および追加のダイバーシチ利得を提供する。提案されたMIMOエンコーディング方式は、アンテナ極性配置（antenna polarity configuration）を制限しない。
【０１５６】
MIMO処理は、アドバンスドプロファイルフレームに対して要求されるが、これはアドバンスドプロファイルフレームにおけるすべてのデータパイプが、MIMOエンコーダによって処理されるということを意味する。MIMO処理は、データパイプレベルで適用される。コンステレーションマッパ出力ペア(pair)のNUQ(e１、iおよびe２、i)は、MIMOエンコーダの入力に供給される。MIMOエンコーダ出力ペア (g１、iおよびg２、i)は、それぞれの送信アンテナの同一キャリアkおよびOFDMシンボルlによって伝送される。
【０１５７】
前述したブロックは、省略するか、または、類似もしくは同一機能を有するブロックで代替することができる。
【０１５８】
図６は、本発明の他の実施例に係るBICMブロックを示す。
【０１５９】
図６に図示されたBICMブロックは、図１を参照して説明したBICMブロック１０１０の一実施例に該当する。
【０１６０】
図６は、PLS、EAC、およびFICを保護（protection）するためのBICMブロックを示す。EACは、EAS情報データを伝達するフレームの一部であり、FICは、サービスと該当するベースデータパイプとの間でマッピング情報を伝達する、フレームにおける論理チャネルである。EACおよびFICに関する詳細な説明は後述する。
【０１６１】
図６に示すように、PLS、EAC、およびFICを保護するためのBICMブロックは、PLS FECエンコーダ６０００、ビットインターリーバ６０１０、およびコンステレーションマッパ６０２０を含むことができる。
【０１６２】
また、PLS FECエンコーダ６０００は、スクランブラ、BCHエンコーディング/ゼロ挿入ブロック、LDPCエンコーディングブロック、およびLDPCパリティパンクチャリング(puncturing)ブロックを含むことができる。BICMブロックの各ブロックに関して説明する。
【０１６３】
PLS FECエンコーダ６０００は、スクランブルされたPLS１/２データ、EACおよびFICセクションをエンコーディングすることができる。
【０１６４】
スクランブラは、BCHエンコーディングとショートニング（短縮）(shortening)およびパンクチャリングされるLDPCエンコーディングとの前に、PLS１データおよびPLS２データをスクランブルすることができる。
【０１６５】
BCHエンコーディング/ゼロ挿入ブロックは、PLS保護のためのショートニングされたBCHコードを利用して、スクランブルされたPLS１/２データに外部エンコーディングを行い、BCHエンコーディング後にゼロビットを挿入することができる。PLS１データに対してのみ、ゼロ挿入の出力ビットがLDPCエンコーディング前にパーミュテーション(permutation)される（並べ替えられる、順序を入れ替えられる）。
【０１６６】
LDPCエンコーディングブロックは、LDPCコードを利用してBCHエンコーディング/ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、CldpcおよびパリティビットPldpcは、それぞれのゼロが挿入されたPLS情報ブロックIldpcからシステム的に（システマティックに）（組織的に）（systematically）エンコーディングされ、その後に添付される。
【０１６７】
【数１】
2017508326.tif 000006
【０１６８】
PLS１およびPLS２に対するLDPCコードパラメータは、次の表４のとおりである。
【０１６９】
【表４】
2017508326.tif 000007
【０１７０】
LDPCパリティパンクチャリングブロックは、PLS１データおよびPLS２データに対してパンクチャリングを行うことができる。
【０１７１】
ショートニングがPLS１データ保護に適用される場合、一部のLDPCパリティビットはLDPCエンコーディング後にパンクチャリングされる。また、PLS２データ保護のために、PLS２のLDPCパリティビットがLDPCエンコーディング後にパンクチャリングされる。これらのパンクチャリングされたビットは伝送されない。
【０１７２】
ビットインターリーバ６０１０は、それぞれのショートニングおよびパンクチャリングされたPLS１データおよびPLS２データをインターリーブすることができる。
【０１７３】
コンステレーションマッパ６０２０は、ビットインターリーブされたPLS１データおよびPLS２データをコンステレーションにマッピングすることができる。
【０１７４】
前述したブロックは、省略または類似もしくは同一機能を有するブロックで代替することができる。
【０１７５】
図７は、本発明の一実施例に係るフレーム構築ブロック(frame building block)を示す。
【０１７６】
図７に図示したフレーム構築ブロックは、図１を参照して説明したフレーム構築ブロック１０２０の一実施例に該当（対応）する。
【０１７７】
図７に示すように、フレーム構築ブロックは、遅延補償ブロック７０００、セルマッパ(cell mapper)７０１０、および周波数インターリーバ(frequency interleaver)７０２０を含むことができる。フレーム構築ブロックの各ブロックに関して説明する。
【０１７８】
遅延補償ブロック７０００は、データパイプと対応（該当）するPLSデータとの間のタイミングを調節して、送信器側でデータパイプと対応するPLSデータとの間の同時性(co-time)を保証（保障）する（ensure）ことができる。入力フォーマットブロックおよびBICMブロックによるデータパイプの遅延に対処することにより、PLSデータはデータパイプだけ遅延される。BICMブロックの遅延は、主にタイムインターリーバ５０５０によるものである。インバンド(In-band)シグナリングデータは、次のタイムインターリーブグループの情報を伝達することによって、シグナリングされるデータパイプより１フレーム先に伝達されるようにすることができる。遅延補償ブロックは、それに合わせてインバンド(In-band)シグナリングデータを遅延させる。
【０１７９】
セルマッパ７０１０は、PLS、EAC、FIC、データパイプ、補助ストリーム、およびダミーセル（dummy cell）を、フレーム内でOFDMシンボルのアクティブ(active)キャリアにマッピングすることができる。セルマッパ７０１０の基本機能は、それぞれのデータパイプ、PLSセル、およびEAC/FICセルに対するタイムインターリーブによって生成されたデータセルを、存在すれば、１つのフレーム内のそれぞれのOFDMシンボルに該当（対応）するアクティブ(active)OFDMセルのアレイ（配列）にマッピングするものである。(PSI(program specific information)/SIのような)サービスシグナリングデータは、個別に収集されてデータパイプによって送信される。セルマッパは、フレーム構造の構成およびスケジューラによって生成されたダイナミックインフォメーション（動的情報）(dynamic information)に応じて動作する。フレームに関する詳しい内容は後述する。
【０１８０】
周波数インターリーバ７０２０は、セルマッパ７０１０から受信されたデータセルをランダムにインターリーブして、周波数ダイバーシチを提供することができる。また、周波数インターリーバ７０２０は、単一フレームで最大のインターリーブ利得を得るために、他のインターリーブシード(seed)順（interleaving-seed order）を利用して２つの連続する（sequential）OFDMシンボルから構成されたOFDMシンボルペア(pair)で動作することができる。
【０１８１】
前述したブロックは、省略するか、または、類似もしくは同一機能を有するブロックで代替することができる。
【０１８２】
図８は、本発明の一実施例に係るOFDM生成ブロックを示す。
【０１８３】
図８に図示されたOFDM生成ブロックは、図１を参照して説明したOFDM生成ブロック１０３０の一実施例に対応（該当）する。
【０１８４】
OFDM生成ブロックは、フレーム構築ブロックによって生成されたセルによってOFDMキャリアを変調して、パイロットを挿入し、伝送のための時間領域信号を生成する。また、該当ブロックは順次ガードインターバル（guard intervals）を挿入し、PAPR減少（リダクション）（reduction）処理を適用して最終（final）RF信号を生成する。
【０１８５】
図８に示すように、OFDM生成ブロックは、パイロットおよびリザーブド（予約）トーン挿入ブロック(pilot and reserved tone insertion block)８０００、２Ｄ-eSFN(Single Frequency Network)エンコーディングブロック８０１０、IFFT(Inverse Fast Fourier Transform)ブロック８０２０、PAPR減少ブロック８０３０、ガードインターバル挿入ブロック(guard interval insertion block)８０４０、プリアンブル挿入ブロック(preamble insertion block)８０５０、その他のシステム挿入ブロック８０６０、およびDACブロック８０７０を含むことができる。フレーム構築ブロックのそれぞれのブロックについて説明する。
【０１８６】
パイロットおよびリザーブド（予約）トーン挿入ブロック8000は、パイロットやリザーブド（予約済みの）トーンを挿入することができる。
【０１８７】
OFDMシンボル内の様々なセルは、受信器において事前に知られている送信された値を有するパイロットとして既知の参照情報（によって変調される（Various cells within the OFDM symbol are modulated with reference information, known as pilots, which have transmitted values known a priori in the receiver）。パイロットセルの情報は、スキャッタード（分散）パイロット（scattered pilots）、連続パイロット（continual pilots）、エッジパイロット、FSS（Frame Signaling Symbol）（フレームシグナリングシンボル）パイロットおよびFES（Frame Edge Symbol）（フレームエッジシンボル）パイロットから構成される。各パイロットは、パイロットのタイプおよびパイロットのパターンに応じて特定のブーストパワー（昇圧電力）レベル（boosted power level）で送信される。パイロット情報の値は、任意の所与のシンボル上で送信される各キャリアに対して1つ、値の配列である参照シーケンスから導出される（The value of the pilot information is derived from a reference sequence, which is a series of values, one for each transmitted carrier on any given symbol）。パイロットは、フレーム同期、周波数同期、時間同期、チャネル推定、および送信モードの識別に使用することができ、また、位相雑音（ノイズ）（phase noise）を追跡するために使用することができる。
【０１８８】
参照シーケンスから取り出された参照情報は、フレームのプリアンブル、FSSおよびFESを除くすべてのシンボルにおいてスキャッタードパイロットセルで送信される。連続パイロットは、フレームのすべてのシンボルに挿入される。連続パイロットの数および位置は、FFTの大きさおよびスキャッタードパイロットのパターンの両方に依存する。エッジキャリア（carriers）は、プリアンブルシンボルを除くすべてのシンボルのエッジパイロットである。これらは、スペクトルの端までの周波数補間を可能にするために挿入されている。FSSパイロットはFSS（複数可）に挿入され、FESパイロットは、FESに挿入されている。これらは、フレームのエッジまでの時間補間アップを可能にするために挿入されている。
【０１８９】
本発明の実施形態に係るシステムは、分散MISO方式が必要に応じて（オプションとして）非常にロバストな伝送モードをサポートするために使用されるSFNネットワークをサポートする。2D-eSFNは、それぞれがSFNネットワーク内の異なる送信器サイトに位置する複数のTX（送信）アンテナを使用する分散MISO方式である（The 2D-eSFN is a distributed MISO scheme that uses multiple TX antennas, each of which is located in the different transmitter site in the SFN network）。
【０１９０】
2D-eSFNの符号化ブロック8010は、SFNの設定時間および周波数ダイバーシチの両方を作成するために、複数の送信器から送信された信号の位相を歪めるために2D-eSFN処理を処理することができる。したがって、長時間の低いフラットフェージングや深いフェージングによるバーストエラーを軽減することができる（burst errors due to low flat fading or deep-fading for a long time can be mitigated）。
【０１９１】
IFFTブロック8020は、OPDM変調方式を用いた2D-eSFNの符号化ブロック8010の出力を調節することができる。データシンボルにおいてパイロット（またはリザーブドトーンなど）として指定されていない任意のセルは、周波数インターリーバからのデータセルの1つを搬送する。セルは、OFDMキャリアにマッピングされる。（The IFFT block 8020 can modulate the output from the 2D-eSFN encoding block 8010 using OFDM modulation scheme. Any cell in the data symbols which has not been designated as a pilot (or as a reserved tone) carries one of the data cells from the frequency interleaver. The cells are mapped to OFDM carriers.）
【０１９２】
PAPR低減（リダクション）（reduction）ブロック8030は、時間領域内において様々なPAPR低減アルゴリズムを使用して入力信号のPAPR低減を行うことができる。
【０１９３】
ガードインターバル挿入ブロック8040は、ガードインターバルを挿入することができ、プリアンブル挿入ブロック8050は、信号の前にプリアンブルを挿入することができる。プリアンブルの構造の詳細については後述する。他のシステム挿入ブロック８０６０は、放送サービスを提供する二以上の相互に異なる放送送信/受信システムのデータが同じRF信号帯域で同時に伝送されるように、時間領域において複数の放送送信/受信システムの信号をマルチプレックスすることができる。この場合、二以上の相互に異なる放送送信/受信システムは、相互に異なる放送サービスを提供するシステムをいう。相互に異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することになる。それぞれの放送サービスに関連するデータは、異なるフレームを介して送信することができる。
【０１９４】
DACブロック8070は、入力されたデジタル信号をアナログ信号に変換し、アナログ信号を出力することができる（The DAC block 8070 can convert an input digital signal into an analog signal and output the analog signal）。DACブロック7800から出力された信号は、物理層プロファイルに応じて複数の出力アンテナを介して送信されることができる。本発明の実施形態に係る送信アンテナは、垂直または水平の極性（vertical or horizontal polarity）を有することができる。
【０１９５】
上記ブロックは、省略したり、または設計に応じて、類似もしくは同一の機能を有するブロックに置き換えることができる。
【０１９６】
図９は、本発明の一実施例に係る次世代放送サービスに関する放送信号受信装置の構造を示す。
【０１９７】
本発明の一実施例に係る次世代放送サービスに関する放送信号受信装置は、図１を参照して説明した次世代放送サービスに関する放送信号送信装置に対応する。
【０１９８】
本発明の一実施例に係る次世代放送サービスに関する放送信号受信装置は、同期および復調モジュール(synchronization & demodulation module)９０００、フレーム解析モジュール(frame parsing module)９０１０、デマッピングおよびデコーディングモジュール(demapping & decoding module)９０２０、出力プロセッサ(output processor)９０３０、およびシグナリングデコーディングモジュール(signaling decoding module)９０４０を含むことができる。放送信号受信装置の各モジュールの動作に関して説明する。
【０１９９】
同期および復調モジュール９０００は、m個の受信アンテナを介して入力信号を受信し、放送信号受信装置に対応（該当）するシステムに対して信号検出および同期化を実行し、放送信号送信装置によって実行される手順の逆処理の手順に対応する復調を実行することができる。
【０２００】
フレーム解析モジュール９０１０は、入力信号フレームを解析し、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリーブを実行する場合、フレーム解析モジュール９０１０は、インターリーブの逆の手順に対応するデインターリーブを実行することができる。この場合、抽出されるべき信号およびデータの位置が、シグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることにより獲得され、放送信号送信装置によって生成されたスケジューリング情報が復元される。
【０２０１】
デマッピングおよびデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要に応じてビット領域データをデインターリーブすることができる。デマッピングおよびデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを介して伝送チャネルで発生したエラーを訂正することができる。この場合、デマッピングおよびデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることにより、デマッピングおよびデコーディングのために必要な伝送パラメータを獲得することができる。
【０２０２】
出力プロセッサ９０３０は、伝送効率を向上させるために、放送信号送信装置によって適用される多様な圧縮/信号処理手順の逆の手順を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を獲得することができる。出力プロセッサ８３００の出力は、放送信号送信装置に入力される信号に対応し、例えば、MPEG-TS、IPストリーム(v４またはv６)およびGSである。
【０２０３】
シグナリングデコーディングモジュール９０４０は、同期および復調モジュール９０００によって復調された信号からPLS情報を獲得することができる。上述したように、フレーム解析モジュール９０１０、デマッピングおよびデコーディングモジュール９２００、出力プロセッサ９３００は、シグナリングデコーディングモジュール９０４０から出力されたデータを利用してその機能を実行することができる。
【０２０４】
図１０は、本発明の一実施例に係るフレーム構造を示す。
【０２０５】
図１０は、フレームタイムの構成例およびスーパーフレームにおけるFRU(Frame Repetition Unit、フレーム繰返し単位)を示す。(a)は、本発明の一実施例に係るスーパーフレームを示し、(b)は、本発明の一実施例に係るFRUを示し、(c)はFRUでの多様な物理プロファイル(PHY profile)のフレームを示し、(d)はフレームの構造を示す。
【０２０６】
スーパーフレームは８個のFRUで構成することができる。FRUはフレームのTDMに対する基本マルチプレックス単位（basic multiplexing unit）であり、スーパーフレームで８回繰り返される。
【０２０７】
FRUにおける各フレームは、物理プロファイル(ベース、ハンドヘルド、アドバンスドプロファイル)のうちの１つまたはFEFに属する。FRUでフレームの最大許容数（maximum allowed number）は４であり、与えられた物理プロファイルは、FRUで０回〜４回のいずれかの回数だけ出現できる(例えば、ベース、ベース、ハンドヘルド、アドバンスド)。物理プロファイルの定義は、必要に応じてプリアンブルにおけるPHY_PROFILEのリザーブド値(reserved value)を利用して拡張可能である。
【０２０８】
FEF部分（パート）は、含まれる場合FRUの終わりに挿入される。FEFがFRUに含まれる場合、FEFの最大数はスーパーフレームにおいて８である。FEF部分が相互に隣接することは推奨されない。
【０２０９】
１つのフレームは、複数のOFDMシンボルおよびプリアンブルにさらに分離される。(d)に示したように、フレームは、プリアンブル、１つまたは複数のFSS、ノーマルデータシンボル、FESを含む。
【０２１０】
プリアンブルは、高速フューチャキャストUTBシステム（Futurecast UTB system）信号の検出を可能にし、信号の効率的な送信および受信のための基本伝送パラメータセットを提供する特別なシンボルである。プリアンブルに関する詳しい内容は後述する。
【０２１１】
FSSの主な目的は、PLSデータを伝達することである。高速同期およびチャネル推定のために、これに伴うPLSデータの高速デコーディングのために、FSSは、ノーマルデータシンボルより高密度なパイロットパターンを有する。FESはFSSと完全に同一なパイロットを有するが、これはFESの直前のシンボルに対して外挿(extrapolation)なしでFES内での周波数のみの補間(interpolation)および時間的補間(temporal interpolation)を可能とする。
【０２１２】
図１１は、本発明の一実施例に係るフレームのシグナリング階層構造(signaling hierarchy structure)を示す。
【０２１３】
図１１は、シグナリング階層構造を示すが、これは３つの主な部分であるプリアンブルシグナリングデータ１１０００、PLS１データ１１０１０、およびPLS２データ１１０２０に分割される。各フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータおよび伝送タイプを示すことである。PLS１は、受信器が対象のデータパイプに接続するためのパラメータを含むPLS２データに接続してデコーディングすることができるようにする。PLS２は、各フレームごとに伝達され、２つの主な部分であるPLS２-STATデータとPLS２-DYNデータとに分割される。PLS２データのスタティックおよびダイナミック部分には、必要に応じてパディングがなされる。
【０２１４】
図１２は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。
【０２１５】
プリアンブルシグナリングデータは、受信器がフレーム構造内でPLSデータに接続しデータパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータに関する詳しい内容は、次のとおりである。
【０２１６】
PHY_PROFILE：該当３ビットフィールドは、現在のフレームの物理プロファイルタイプを示す。相互に異なる物理プロファイルタイプのマッピングは、以下の表５に示す。
【０２１７】
【表５】
2017508326.tif 000008
【０２１８】
FFT_SIZE：該当２ビットフィールドは、以下の表６で説明するように、フレームグループ内における現在のフレームのFFTサイズを示す。
【０２１９】
【表６】
2017508326.tif 000009
【０２２０】
GI_FRACTION：該当３ビットフィールドは、以下の表７で説明するように、現在のスーパーフレームにおけるガードインターバルの分数(fraction)値を示す。
【０２２１】
【表７】
2017508326.tif 000010
【０２２２】
EAC_FLAG：該当１ビットフィールドは、EACが現在のフレームに提供されるか否かを示す。該当フィールドが１に設定される場合、EASが現在のフレームに提供される。該当フィールドが０に設定される場合、EASが現在のフレームに伝達されない。該当フィールドは、スーパーフレーム内でダイナミックに切り換えられる（switched）。
【０２２３】
PILOT_MODE：該当１ビットフィールドは、現在のフレームグループにおける現在のフレームに対してパイロットモードがモバイルモードであるかまたは固定モードであるかを示す。該当フィールドが０に設定される場合、モバイルパイロットモードが使用される。該当フィールドが１に設定される場合、固定パイロットモードが使用される。
【０２２４】
PAPR_FLAG：該当１ビットフィールドは、現在のフレームグループにおける現在のフレームに対してPAPR減少が使用されているか否かを示す。該当フィールドが１に設定される場合、トーン予約(tone reservation)がPAPR減少のために使用される。該当フィールドが０に設定される場合、PAPR減少が使用されない。
【０２２５】
FRU_CONFIGURE：該当３ビットフィールドは、現在のスーパーフレームに存在するFRUの物理プロファイルタイプ構成を示す。現在のスーパーフレーム内のすべてのプリアンブルにおける該当フィールドで、現在のスーパーフレームで伝達されるすべてのプロファイルタイプが識別される。該当３ビットフィールドは、以下の表８に示したように、それぞれのプロファイルに対して異なるように定義される。
【０２２６】
【表８】
2017508326.tif 000011
【０２２７】
RESERVED：該当７ビットフィールドは、将来の使用のためにリザーブ（予約）(reserved)される。
【０２２８】
図１３は、本発明の一実施例に係るPLS１データを示す。
【０２２９】
PLS１データは、PLS２の受信およびデコーディングを可能にするために必要なパラメータを含んだ基本伝送パラメータを提供する。上述したように、PLS１データは、１つのフレームグループの全デュレーション（entire duration）の間変化しない。PLS１データのシグナリングフィールドの具体的な定義は次のとおりである。
【０２３０】
PREAMBLE_DATA：該当２０ビットフィールドは、EAC_FLAGを除いたプリアンブルシグナリングデータのコピーである。
【０２３１】
NUM_FRAME_FRU：該当２ビットフィールドは、FRU当たりのフレーム数を示す。
【０２３２】
PAYLOAD_TYPE：該当３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。PAYLOAD_TYPEは、表９に示したようにシグナリングされる。
【０２３３】
【表９】
2017508326.tif 000012
【０２３４】
NUM_FSS：該当２ビットフィールドは、現在のフレームにおけるFSSの数を示す。
【０２３５】
SYSTEM_VERSION：該当８ビットフィールドは伝送される信号フォーマットのバージョンを示す。SYSTEM_VERSIONは主（メジャー）バージョン（major version）および副（マイナ）バージョン（minor version）の２つの４ビットフィールドに分離される。
【０２３６】
主バージョン：SYSTEM_VERSIONフィールドのMSBである４ビットは主バージョン情報を示す。主バージョンフィールドにおける変化（change）は、後方互換が不可能な変化（non-backward-compatible change）を示す。デフォルト値は００００である。該当標準で説明されたバージョンに対して、値が００００に設定される。
【０２３７】
副バージョン：SYSTEM_VERSIONフィールドのLSBである４ビットは副バージョン情報を示す。副バージョンフィールドにおける変化は後方互換が可能である。
【０２３８】
CELL_ID：これは、ATSCネットワークで地理的セルを一意に識別する１６ビットフィールドである。ATSCセルカバレッジは、フューチャキャストUTBシステムごとに使用される周波数に応じて１つまたは複数の周波数から構成される。CELL_IDの値が知られていないか特定されない場合、該当フィールドは０に設定される。
【０２３９】
NETWORK_ID：これは、現在のATSCネットワークを一意に識別する１６ビットフィールドである。
【０２４０】
SYSTEM_ID：該当１６ビットフィールドは、ATSCネットワーク内でフューチャキャストUTBシステムを一意に識別する。フューチャキャストUTBシステムは、入力が１つまたは複数の入力ストリーム(TS、IP、GS)であり、出力がRF信号である地上波放送システムである。フューチャキャストUTBシステムは、存在する場合FEFおよび１つもしくは複数の物理プロファイルを伝達する。同一フューチャキャストUTBシステムは、相互に異なる入力ストリームを伝達し、相互に異なる地理的領域で相互に異なるRFを使用でき、ローカルサービスの挿入を許容する。フレーム構造およびスケジューリングは１つの場所で制御され、フューチャキャストUTBシステム内ですべての伝送に対して同一であり、１つまたは複数のフューチャキャストUTBシステムは、全て同一の物理構造および構成を有する同一SYSTEM_IDの意味を持つことができる。
【０２４１】
次のループ(loop)は、各フレームタイプの長さおよびFRU構成を示すFRU_PHY_PROFILE、FRU_FRAME_LENGTH、FRU_GI_FRACTION、RESERVEDから構成される。ループ(loop)のサイズは、FRU内で４つの物理プロファイル(FEF含む)がシグナリングされるように固定される。NUM_FRAME_FRUが４より小さい場合、使用されないフィールドはゼロで満たされる。
【０２４２】
FRU_PHY_PROFILE：該当３ビットフィールドは、関連付けられた（関連した）（associated）FRUの(i+１)番目のフレーム(iはループ(loop)インデックス)の物理プロファイルタイプを示す。該当フィールドは、表８に示したものと同一のシグナリングフォーマットを用いる。
【０２４３】
FRU_FRAME_LENGTH：該当２ビットフィールドは、関連付けられたFRUの(i+１)番目のフレームの長さを示す。FRU_GI_FRACTIONと一緒にFRU_FRAME_LENGTHを使用する場合、フレームデュレーションの正確な値が得られる。
【０２４４】
FRU_GI_FRACTION：該当３ビットフィールドは、関連付けられたFRUの(i+１)番目のフレームのガードインターバルの分数値を示す。FRU_GI_FRACTIONは、表７に従ってシグナリングされる。
【０２４５】
RESERVED：該当４ビットフィールドは、将来の使用のためにリザーブ(reserved)される。
【０２４６】
次のフィールドは、PLS２データをデコーディングするためのパラメータを提供する。
【０２４７】
PLS２_FEC_TYPE：該当２ビットフィールドは、PLS２の保護に使用されるFECタイプを示す。FECタイプは、表１０に従ってシグナリングされる。LDPCコードに関する詳しい内容は後述する。
【０２４８】
【表１０】
2017508326.tif 000013
【０２４９】
PLS２_MOD：該当３ビットフィールドは、PLS２に使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２５０】
【表１１】
2017508326.tif 000014
【０２５１】
PLS２_SIZE_CELL：該当１５ビットフィールドは、現在のフレームグループで伝達されるPLS２に関するすべてのコーディングブロックのコレクション（collection）のサイズ(QAMセルの数として特定される)のCtotal_partial_blockを示す。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２５２】
PLS２_STAT_SIZE_BIT：該当１４ビットフィールドは、現在のフレームグループに関するPLS２-STATのサイズをビット数で示す。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２５３】
PLS２_DYN_SIZE_BIT：該当１４ビットフィールドは、現在のフレームグループに関するPLS２-DYNのサイズをビット数で示す。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２５４】
PLS２_REP_FLAG：該当１ビットフラッグは、PLS２繰返しモードが現在のフレームグループで使用されている否かを示す。該当フィールドの値が１に設定される場合、PLS２繰返しモードは活性化される。該当フィールドの値が０に設定される場合、PLS２繰返しモードは非活性化される。
【０２５５】
PLS２_REP_SIZE_CELL：該当１５ビットフィールドは、PLS２繰返しが使用される場合、現在のフレームグループの各フレームごとに伝達されるPLS２に対する部分的（partial）コーディングブロックのサイズ(QAMセルの数として特定される)のCtotal_partial_blockを示す。繰返しが使用されない場合、該当フィールドの値は０と同一である。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２５６】
PLS２_NEXT_FEC_TYPE：該当２ビットフィールドは、次のフレームグループの各フレームで伝達されるPLS２に使用されるFECタイプを示す。FECタイプは、表１０に従ってシグナリングされる。
【０２５７】
PLS２_NEXT_MOD：該当３ビットフィールドは、次のフレームグループの各フレームで伝達されるPLS２に使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２５８】
PLS２_NEXT_REP_FLAG：該当１ビットフラッグは、PLS２繰返しモードが次のフレームグループで使用されているか否かを示す。該当フィールドの値が１に設定される場合、PLS２繰返しモードは活性化される。該当フィールドの値が０に設定される場合、PLS２繰返しモードは非活性化される。
【０２５９】
PLS２_NEXT_REP_SIZE_CELL：該当１５ビットフィールドは、PLS２繰返しが使用される場合、次のフレームグループの各フレームごとに伝達されるPLS２に対する全コーディングブロックのコレクションのサイズ(QAMセルの数として特定される)のCtotal_full_blockを示す。次のフレームグループで繰返しが使用されない場合、該当フィールドの値は０と同一である。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２６０】
PLS２_NEXT_REP_STAT_SIZE_BIT：該当１４ビットフィールドは、次のフレームグループに関するPLS２-STATのサイズをビット数で示す。該当値は、現在のフレームグループにおいて一定である。
【０２６１】
PLS２_NEXT_REP_DYN_SIZE_BIT：該当１４ビットフィールドは、次のフレームグループに関するPLS２-DYNのサイズをビット数で示す。該当値は、現在のフレームグループにおいて一定である。
【０２６２】
PLS２_AP_MODE：該当２ビットフィールドは、現在のフレームグループでPLS２に対して追加パリティが提供されるか否かを示す。該当値は、現在のフレームグループの全デュレーションの間一定である。以下の表１２は該当フィールドの値を提供する。該当フィールドの値が００に設定される場合、現在のフレームグループで追加パリティがPLS２に対して使用されない。
【０２６３】
【表１２】
2017508326.tif 000015
【０２６４】
PLS２_AP_SIZE_CELL：該当１５ビットフィールドは、PLS２の追加パリティビットのサイズ(QAMセルの数として特定される)を示す。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２６５】
PLS２_NEXT_AP_MODE：該当２ビットフィールドは、次のフレームグループの各フレームごとにPLS２シグナリングに対して追加パリティが提供されるか否かを示す。該当値は、現在のフレームグループの全デュレーションの間一定である。表１２は、該当フィールドの値を定義する。
【０２６６】
PLS２_NEXT_AP_SIZE_CELL：該当１５ビットフィールドは、次のフレームグループの各フレームごとにPLS２の追加パリティビットのサイズ(QAMセルの数として特定される)を示す。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２６７】
RESERVED：該当３２ビットフィールドは、将来の使用のためにリザーブ(reserved)される。
【０２６８】
CRC_３２：PLS１シグナリング全体に適用される３２ビットエラー検出コード。
【０２６９】
図１４は、本発明の一実施例に係るPLS２データを示す。
【０２７０】
図１４は、PLS２データのPLS２-STATデータを示す。PLS２-STATデータはフレームグループ内で同一である反面、PLS２-DYNデータは現在のフレームに対して特定の情報を提供する。
【０２７１】
PLS２-STATデータのフィールドに関して次に具体的に説明する。
【０２７２】
FIC_FLAG：該当１ビットフィールドは、FICが現在のフレームグループで使用されているか否かを示す。該当フィールドの値が１に設定される場合、FICは現在のフレームで提供される。該当フィールドの値が０に設定される場合、FICは現在のフレームで伝達されない。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２７３】
AUX_FLAG：該当１ビットフィールドは、補助ストリームが現在のフレームグループで使用されているか否かを示す。該当フィールドの値が１に設定される場合、補助ストリームは現在のフレームで提供される。該当フィールドの値が０に設定される場合、補助フレームは現在のフレームで伝達されない。該当値は、現在のフレームグループの全デュレーションの間一定である。
【０２７４】
NUM_DP：該当６ビットフィールドは、現在のフレーム内で伝達されるデータパイプの数を示す。該当フィールドの値は１から６４の間であり、データパイプの数はNUM_DP+１である。
【０２７５】
DP_ID：該当６ビットフィールドは、ＤＰを物理プロファイル内で一意に（uniquely）識別する。
【０２７６】
DP_TYPE：該当３ビットフィールドは、データパイプのタイプを示す。これは、以下の表１３に従ってシグナリングされる。
【０２７７】
【表１３】
2017508326.tif 000016
【０２７８】
DP_GROUP_ID：該当８ビットフィールドは、現在のデータパイプが関連付けられたデータパイプグループを識別する。これは受信器が同一のDP_GROUP_IDを有するようになる特定サービスと関連付けられているサービスコンポーネントのデータパイプに接続するために使用される。
【０２７９】
BASE_DP_ID：該当６ビットフィールドは、管理層で使用される(PSI/SIのような)サービスシグナリングデータを伝達するデータパイプを示す。BASE_DP_IDによって示すデータパイプは、サービスデータと一緒にサービスシグナリングデータを伝達するノーマルデータパイプであるか、サービスシグナリングデータだけを伝達する専用データパイプである。
【０２８０】
DP_FEC_TYPE：該当２ビットフィールドは、関連付けられたデータパイプによって使用されるFECタイプを示す。FECタイプは、以下の表１４に従ってシグナリングされる。
【０２８１】
【表１４】
2017508326.tif 000017
【０２８２】
DP_COD：該当４ビットフィールドは、関連付けられたデータパイプによって使用されるコードレート(code rate)を示す。コードレート(code rate)は、以下の表１５に従ってシグナリングされる。
【０２８３】
【表１５】
2017508326.tif 000018
【０２８４】
DP_MOD：該当４ビットフィールドは、関連付けられたデータパイプによって使用される変調を示す。変調は、以下の表１６に従ってシグナリングされる。
【０２８５】
【表１６】
2017508326.tif 000019
【０２８６】
DP_SSD_FLAG：該当１ビットフィールドは、SSDモードが関連付けられたデータパイプで使用されているか否かを示す。該当フィールドの値が１に設定される場合、SSDは使用される。該当フィールドの値が０に設定される場合、SSDは使用されない。
【０２８７】
次のフィールドは、PHY_PROFILEがアドバンスドプロファイルを示す０１０と同一である場合のみ現れる。
【０２８８】
DP_MIMO：該当３ビットフィールドは、どんなタイプのMIMOエンコーディング処理が関連付けられたデータパイプに適用されるかを示す。MIMOエンコーディング処理のタイプは、以下の表１７に従ってシグナリングされる。
【０２８９】
【表１７】
2017508326.tif 000020
【０２９０】
DP_TI_TYPE：該当１ビットフィールドは、タイムインターリーブのタイプを示す。０の値は、１つのタイムインターリーブグループが１つのフレームに対応し、１つまたは複数のタイムインターリーブブロックを含むことを示す。１の値は、１つのタイムインターリーブグループが１つより多いフレームで伝達され、１つのタイムインターリーブブロックのみを含むことを示す。
【０２９１】
DP_TI_LENGTH：該当２ビットフィールド(許容（使用可能な）値（allowed values）は１、２、４、８のみ)の使用は、次のようなDP_TI_TYPEフィールド内で設定される値によって決定される。
【０２９２】
DP_TI_TYPEの値が１に設定される場合、該当フィールドは、それぞれのタイムインターリーブグループがマッピングされるフレームの数であるPIを示し、タイムインターリーブグループ当たり１つのタイムインターリーブブロックが存在する(NTI=１)。該当２ビットフィールドで許容される（使用可能な）PIの値（allowedPIvalues）は、以下の表１８で定義される。
【０２９３】
DP_TI_TYPEの値が０に設定される場合、該当フィールドはタイムインターリーブグループ当たりタイムインターリーブブロックの数であるNTIを示し、フレーム当たり１つのタイムインターリーブグループが存在する(PI=１)。該当２ビットフィールドで許容されるPIの値は、以下の表１８で定義される。
【０２９４】
【表１８】
2017508326.tif 000021
【０２９５】
DP_FRAME_INTERVAL：該当２ビットフィールドは、関連付けられたデータパイプに関するフレームグループ内におけるフレーム間隔(IJUMP)を示し、許容値は１、２、４、８(該当する２ビットフィールドは、それぞれ００、０１、１０、１１)である。フレームグループのすべてのフレームに現れないデータパイプに関して、該当フィールドの値は、連続する（successive）フレーム間の間隔と同一である。例えば、データパイプが１、５、９、１３等のフレームに現れる場合、該当フィールドの値は４に設定される。すべてのフレームに現れるデータパイプに関して、該当フィールドの値は１に設定される。
【０２９６】
DP_TI_BYPASS：該当１ビットフィールドは、タイムインターリーバ５０５０の使用可能性（availability）を決定する。データパイプに対してタイムインターリーブが使用されない場合、該当フィールド値は１に設定される。反面、タイムインターリーブが使用される場合、該当フィールド値は０に設定される。
【０２９７】
DP_FIRST_FRAME_IDX：該当５ビットフィールドは、現在のデータパイプが発生するスーパーフレームの１番目のフレームのインデックスを示す。DP_FIRST_FRAME_IDXの値は０から３１の間である。
【０２９８】
DP_NUM_BLOCK_MAX：該当１０ビットフィールドは、該当データパイプに対するDP_NUM_BLOCKSの最大値を示す。該当フィールドの値は、DP_NUM_BLOCKSと同一の範囲を有する。
【０２９９】
DP_PAYLOAD_TYPE：該当２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。DP_PAYLOAD_TYPEは、以下の表１９に従ってシグナリングされる。
【０３００】
【表１９】
2017508326.tif 000022
【０３０１】
DP_INBAND_MODE：該当２ビットフィールドは、現在のデータパイプがインバンド(In-band)シグナリング情報を伝達するか否かを示す。インバンド(In-band)シグナリングタイプは、以下の表２０に従ってシグナリングされる。
【０３０２】
【表２０】
2017508326.tif 000023
【０３０３】
DP_PROTOCOL_TYPE：該当２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択される場合、以下の表２１に従ってシグナリングされる。
【０３０４】
【表２１】
2017508326.tif 000024
【０３０５】
DP_CRC_MODE：該当２ビットフィールドは、CRCエンコーディングが入力フォーマットブロックで使用されているか否かを示す。CRCモードは、以下の表２２に従ってシグナリングされる。
【０３０６】
【表２２】
2017508326.tif 000025
【０３０７】
DNP_MODE：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連付けられたデータパイプによって使用されるヌルパケット削除モードを示す。DNP_MODEは、以下の表２３に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、DNP_MODEは００の値に設定される。
【０３０８】
【表２３】
2017508326.tif 000026
【０３０９】
ISSY_MODE：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連付けられたデータパイプによって使用されるISSYモードを示す。ISSY_MODEは、以下の表２４に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、ISSY_MODEは００の値に設定される。
【０３１０】
【表２４】
2017508326.tif 000027
【０３１１】
HC_MODE_TS：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連付けられたデータパイプによって使用されるTSヘッダ圧縮モードを示す。HC_MODE_TSは、以下の表２５に従ってシグナリングされる。
【０３１２】
【表２５】
2017508326.tif 000028
【０３１３】
HC_MODE_IP：該当２ビットフィールドは、DP_PAYLOAD_TYPEがIP(「０１」)に設定される場合にIPヘッダ圧縮モードを示す。HC_MODE_IPは、以下の表２６に従ってシグナリングされる。
【０３１４】
【表２６】
2017508326.tif 000029
【０３１５】
PID：該当１３ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定され、HC_MODE_TSが０１または１０に設定される場合にTSヘッダ圧縮のためのPID数を示す。
【０３１６】
RESERVED：該当８ビットフィールドは、将来の使用のためにリザーブ(reserved)される。
【０３１７】
次のフィールドは、FIC_FLAGが１と同一である場合のみ現れる。
【０３１８】
FIC_VERSION：該当８ビットフィールドは、FICのバージョンナンバ（版数）を示す。
【０３１９】
FIC_LENGTH_BYTE：該当１３ビットフィールドは、FICの長さをバイト単位で示す。
【０３２０】
RESERVED：該当８ビットフィールドは、将来の使用のためにリザーブ(reserved)される。
【０３２１】
次のフィールドは、AUX_FLAGが１と同一である場合のみ現れる。
【０３２２】
NUM_AUX：該当４ビットフィールドは、補助ストリームの数を示す。ゼロは補助ストリームが使用されないことを示す。
【０３２３】
AUX_CONFIG_RFU：該当８ビットフィールドは、将来の使用のためにリザーブ(reserved)される。
【０３２４】
AUX_STREAM_TYPE：該当４ビットは現補助ストリームのタイプを示すのに将来使用するためにリザーブ(reserved)される。
【０３２５】
AUX_PRIVATE_CONFIG：該当２８ビットフィールドは、補助ストリームをシグナリングするのに将来使用するためにリザーブ(reserved)される。
【０３２６】
図１５は、本発明の他の一実施例に係るPLS２データを示す。
【０３２７】
図１５は、PLS２データのPLS２-DYNを示す。PLS２-DYNデータの値は、１つのフレームグループのデュレーションの間変化できる反面、フィールドのサイズは一定である。
【０３２８】
PLS２-DYNデータのフィールドの具体的な内容は、次のとおりである。
【０３２９】
FRAME_INDEX：該当５ビットフィールドは、スーパーフレーム内における現在のフレームのフレームインデックスを示す。スーパーフレームの１番目のフレームのインデックスは０に設定される。
【０３３０】
PLS_CHANGE_COUNTER：該当４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、該当フィールド内でシグナリングされる値によって示す。該当フィールドの値が００００に設定される場合、これはいかなる予定された変化も予測されないことを意味する。例えば、１の値は次のスーパーフレームで変化があることを示す。
【０３３１】
FIC_CHANGE_COUNTER：該当４ビットフィールドは、構成(すなわち、FICのコンテンツ)が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、該当フィールド内でシグナリングされる値によって示す。該当フィールドの値が００００に設定される場合、これはいかなる予定された変化も予測されないことを意味する。例えば、０００１の値は次のスーパーフレームに変化があることを示す。
【０３３２】
RESERVED：該当１６ビットフィールドは、将来の使用のためにリザーブ(reserved)される。
【０３３３】
次のフィールドは、現在のフレームで伝達されるデータパイプに関連したパラメータを説明するNUM_DPにわたるループ(loop)内に現れる（appear in the loop over NUM_DP）。
【０３３４】
DP_ID：該当６ビットフィールドは、物理プロファイル内でデータパイプを一意に示す。
【０３３５】
DP_START：該当１５ビット(または１３ビット)フィールドは、DPUアドレッシング(addressing)技法を使用してデータパイプの最初の開始位置を示す。DP_STARTフィールドは、以下の表２７に示したように、物理プロファイルおよびFFTサイズに応じて異なる長さを有する。
【０３３６】
【表２７】
2017508326.tif 000030
【０３３７】
DP_NUM_BLOCK：該当１０ビットフィールドは、現在のデータパイプに関する現在のタイムインターリーブグループにおけるFECブロックの数を示す。DP_NUM_BLOCKの値は０から１０２３までの間にある。
【０３３８】
RESERVED：該当８ビットフィールドは、将来の使用のためにリザーブ(reserved)される。
【０３３９】
次のフィールドは、EACに関連したFICパラメータを示す。
【０３４０】
EAC_FLAG：該当１ビットフィールドは、現在のフレームにおけるEACの存在を示す。該当ビットは、プリアンブルにおけるEAC_FLAGと同一の値である。
【０３４１】
EAS_WAKE_UP_VERSION_NUM：該当８ビットフィールドは、自動ウェークアップ（活性化）（wake-up）指示のバージョンナンバを示す。
【０３４２】
EAC_FLAGフィールドが１と同一である場合、次の１２ビットがEAC_LENGTH_BYTEフィールドに割り当てられる。EAC_FLAGフィールドが０と同一である場合、次の１２ビットがEAC_COUNTERに割り当てられる。
【０３４３】
EAC_LENGTH_BYTE：該当１２ビットフィールドは、EACの長さをバイトで示す。
【０３４４】
EAC_COUNTER：該当１２ビットフィールドは、EACが到着（到達）（arrive）するフレームの前のフレームの数を示す。
【０３４５】
次のフィールドは、AUX_FLAGフィールドが１と同一である場合のみ現れる。
【０３４６】
AUX_PRIVATE_DYN：該当４８ビットフィールドは、補助ストリームをシグナリングするのに将来使用するためにリザーブ(reserved)される。該当フィールドの意味は、設定可能なPLS２-STATにおいてAUX_STREAM_TYPEの値に依存する。
【０３４７】
CRC_３２：PLS２全体に適用される３２ビットエラー検出コード。
【０３４８】
図１６は、本発明の一実施例に係るフレームの論理(logical)構造を示す。
【０３４９】
上述したように、PLS、EAC、FIC、データパイプ、補助ストリーム、ダミーセルは、フレームにおいてOFDMシンボルのアクティブ(active)キャリアにマッピングされる。PLS１およびPLS２は、まず、１つまたは複数のFSSにマッピングされる。その後、EACが存在する場合、EACセルはPLSフィールドの直後に（immediately following the PLS field）マッピングされる。次に、FICが存在する場合、FICセルがマッピングされる。データパイプは、PLSの次にマッピングされるか、EACまたはFICが存在する場合、EACまたはFICの後にマッピングされる。タイプ１データパイプがまずマッピングされ、タイプ２データパイプが次にマッピングされる。データパイプのタイプの具体的な内容は後述する。ある場合において（一部の場合）（In some case）、データパイプはEASに関する一部のスペシャル（特殊）データ（some special data）またはサービスシグナリングデータを伝達することができる。補助ストリームまたはストリームは、存在する場合、データパイプの次にマッピングし（follow the DPs）、続いて（順次）（in turn）ダミーセルが後に続く（followed by dummy cells）。前述した順序、すなわち、PLS、EAC、FIC、データパイプ、補助ストリーム、およびダミーセルの順序で全部一緒にマッピングする場合、フレームにおけるセル容量を正確に満たす。
【０３５０】
図１７は、本発明の一実施例に係るPLSマッピングを示す。
【０３５１】
PLSセルは、FSSのアクティブ(active)キャリアにマッピングされる。PLSが占めるセルの数に応じて、１つまたは複数のシンボルがFSSとして指定され、FSSの数NFSSは、PLS１でのNUM_FSSによってシグナリングされる。FSSは、PLSセルを伝達するスペシャル（特殊な）（special）シンボルである。ロバスト（警告）性（robustness）および遅延時間(latency)は、PLSで重大な問題（事案）（issue）であるから、FSSは高いパイロット密度を有しており、高速同期化およびFSS内での周波数のみのインターポレーション(interpolation、補間)を可能とする。
【０３５２】
PLSセルは、図１７の例に示したようにトップダウン方式でFSSのアクティブ(active)キャリアにマッピングされる。PLS１セルは、まず最初のFSSの最初のセルからセルインデックスの昇順にマッピングされる。PLS２セルは、PLS１の最後のセルの直後に続き（を追い）、マッピングは最初のFSSの最後のセルインデックスまで下方向に続く。必要なPLSセルの合計数が１つのFSSのアクティブ(active)キャリアの数を超える場合、マッピングは次のFSSに進み（進行し）、最初のFSSと完全に同一の方式で続けられる。
【０３５３】
PLSマッピングが完了した後、データパイプが次に伝達される。EAC、FICまたは両方とも現在のフレームに存在すれば、EACおよびFICは、PLSとノーマルデータパイプとの間に配置される。
【０３５４】
図１８は、本発明の一実施例に係るEACマッピングを示す。
【０３５５】
EACは、EASメッセージを伝達する専用チャネルであり、EASに関するデータパイプに接続される。EASサポートは提供されるが、EAC自体はすべてのフレームに存在してもよく、存在しなくてもよい。EACが存在する場合、EACはPLS２セルの直後にマッピングされる。PLSセルを除いて、FIC、データパイプ、補助ストリームまたはダミーセルのいずれもEACの前に位置しない。EACセルのマッピング手順はPLSと完全に同一である。
【０３５６】
EACセルは、図１８の例で示したように、PLS２の次のセルからセルインデックスの昇順にマッピングされる。EASメッセージの大きさに応じて、図１８に示したようにEACセルは少しの（a few）シンボルを占めることができる。
【０３５７】
EACセルは、PLS２の最後のセルの直後に続き、マッピングは最後のFSSの最後のセルインデックスまで下方向に続く。必要なEACセルの合計数が最後のFSSの残っているアクティブ(active)キャリアの数を超える場合、EACマッピングは次のシンボルに進み、FSSと完全に同一の方式で続けられる。この場合、EACのマッピングがなされる次のシンボルは、ノーマルデータシンボルであり、これはFSSより多いアクティブ(active)キャリアを有する。
【０３５８】
EACマッピングが完了した後、存在する場合FICが次に伝達される。FICが伝送されない場合(PLS２フィールドでシグナリングとして)、データパイプがEACの最後のセルの直後に続く。
【０３５９】
図１９は、本発明の一実施例に係るFICマッピングを示す。
【０３６０】
(a)はEACを伴わないFICセルのマッピングの例を示し、(b)はEACを伴うFICセルのマッピングの例を示す。
【０３６１】
FICは、高速サービス獲得およびチャネルスキャンを可能とするために、層間情報(cross-layer information)を伝達する専用チャネルである。該当情報は、主にデータパイプ間のチャネルバインディング(channel binding)情報および各放送会社のサービスを含む。高速スキャンのために、受信器は、FICをデコーディングし、放送会社ID、サービス数、BASE_DP_IDなどの情報を獲得することができる。高速サービス獲得のために、FICだけでなくベースデータパイプもBASE_DP_IDを利用してデコーディングすることができる。ベースデータパイプが伝送するコンテンツを除いて、ベースデータパイプはノーマルデータパイプと正確に同一の方式でエンコーディングされ、フレームにマッピングされる。従って、ベースデータパイプに関する追加の説明が不必要である。FICデータが生成されて管理層で消費される。FICデータのコンテンツは、管理層の仕様で説明されたとおりである。
【０３６２】
FICデータはオプション（選択的）であり、FICの使用は、PLS２のスタティックな（静的）部分でFIC_FLAGパラメータによってシグナリングされる。FICが使用される場合、FIC_FLAGは１に設定され、FICに対するシグナリングフィールドはPLS２のスタティックな部分で定義される。該当フィールドでシグナリングされるのはFIC_VERSIONであり、FIC_LENGTH_BYTE FICはPLS２と同じ変調、コーディング、タイムインターリーブパラメータを用いる。FICは、PLS２_MODおよびPLS２_FECなどの同じシグナリングパラメータを共有する。FICデータは、存在する場合PLS２の後にマッピングされ、EACが存在する場合EACの直後にマッピングされる。ノーマルデータパイプ、補助ストリーム、またはダミーセルのいずれもFICの前に位置しない。FICセルをマッピングする方法はEACと完全に同一であり、これはまたPLSと同一である。
【０３６３】
PLS後のEACが存在しない場合、FICセルは(a)の例に示したように、PLS２の次のセルからセルインデックスの昇順にマッピングされる。FICデータサイズに応じて、(b)に示したように、FICセルは数個のシンボルに対してマッピングされる。
【０３６４】
FICセルは、PLS２の最後のセルの直後に続き、マッピングは最後のFSSの最後のセルインデックスまで下方向に続く。必要なFICセルの合計数が最後のFSSの残っているアクティブ(active)キャリアの数を超える場合、残りのFICセルのマッピングは次のシンボルに進み、これはFSSと完全に同一の方式で続けられる。この場合、FICがマッピングされる次のシンボルはノーマルデータシンボルであり、これはFSSより多いアクティブ(active)キャリアを有する。
【０３６５】
EASメッセージが現在のフレームで伝送される場合、EACはFICより先にマッピングされ、(b)に示したようにEACの次のセルから、FICセルは、セルインデックスの昇順にマッピングされる。
【０３６６】
FICマッピングが完了した後、１つまたは複数のデータパイプがマッピングされ、以後存在する場合補助ストリーム、ダミーセルが後に続く。
【０３６７】
図２０は、本発明の一実施例に係るDPのタイプを示す。
【０３６８】
(a)はtype１DPを示し、(b)はType２DPを示す。
【０３６９】
前のチャネル、すなわち、PLS、EAC、およびFICがマッピングされ、DPのセルがマッピングされる。DPはマッピング方法によって２つのタイプのうちの１つでカテゴリ化（分類）される（categorized）。
【０３７０】
Type１DP：DPはTDMによってマッピングされる。
【０３７１】
Type２DP：DPはFDMによってマッピングされる。
【０３７２】
PLSの静的なパート（部分）内のDP_TYPEフィールドによってDPのタイプが指示される。図２０は、Type１DPおよびType２DPのマッピングの順序を示す。Type１DPは、まずセルインデックスの昇順にマッピングされ、最後のセルインデックスに到達（reach）すれば、シンボルインデックスは１つ増加する。次のシンボルで、DPは、p=０から始めてセルインデックスの昇順にマッピングが続けられる。１つのフレームで複数のDPが一緒にマッピングされ、Type１DPのそれぞれは、DPのTDMマルチプレックスと同様に時間に応じてグループ化される（grouped）。
【０３７３】
Type２DPは、まずシンボルインデックスの昇順にマッピングされ、フレームの最後のOFDMシンボルに到達した後、セルインデックスは１つ増加し、シンボルインデックスは最初に利用可能なシンボルに戻り、シンボルインデックスを増加させる。１つのフレーム内で複数のDPをマッピングした後、Type２DPのそれぞれは、DPのFMDマルチプレックスと同様に周波数に応じてグループ化される。
【０３７４】
Type１DPおよびType２DPは、１つの制限で必要となる場合、１つのフレームで存することができる。Type１DPは常にType２DPに先行する。Type１およびType２を伝送するOFDMセルの合計数（total number）は、DPの伝送のためのOFDMセルの合計数を超過できない。
【０３７５】
【数２】
2017508326.tif 000031
【０３７６】
ここで、DDP１は、Type１DPによって占有されたOFDMセルの数である。DDP２は、Type２DPによって占有されたセルの数である。PLS、EAC、FICは全てType１DPに応じて同じ方法でマッピングされるので、それらは全て「Type１マッピングルール」に従い、Type１マッピングは常にType２マッピングに先行する。
【０３７７】
図２１は、本発明の一実施例に係るDPマッピングを示す。
【０３７８】
(a)はtype１DPマッピングのためのOFDMセルのアドレス指定を示し、(b)はType２DPのためのマッピングのためのOFDMセルのアドレス指定を示す。
【０３７９】
Type１DP(０、…、DDP１１)マッピングのためのOFDMセルのアドレス指定は、type１DPのアクティブデータセルのために定義される。アドレス指定スキームは、アクティブデータセルによって割当てられたType１DPのそれぞれのためのTlsからセルの順序を定義する。また、これはPLS２の動的部分（パート）内のDPの位置をシグナリングするために使用される。
【０３８０】
EACおよびFICがない場合（Without EAC and FIC）、アドレス０は、最後のFSS内のPLSを伝送する最後のセルに直ちに続くセル（the cell immediately following the last cell carrying PLS in the last FSS）を参照する。EACが伝送され、FICが対応するフレーム内にない場合、アドレス０はEACを伝送する最後のセルに直ちに続くセルを参照する。Type１DPのためのアドレス０は(a)に示されたように、２つの異なるケースを考慮して計算される。(a)の実施例では、PLS、EACおよびFICは全部伝送されると仮定される。EACおよびFICのうちの１つまたは両方ともが省略された場合に拡張が容易である。もしFICですべてのセルをマッピングした後FSS内に残っているセルがある場合、(a)の左側のように示すことができる。
【０３８１】
Type２DP(０、…、DDP２１)マッピングのためのOFDMセルのアドレス指定は、Type２DPのアクティブデータセルのために定義される。アドレス指定スキームは、アクティブデータセルによって割当てられたType２DPのそれぞれのためのTlsからセルの順序を定義する。また、これはPLS２の動的部分内のDPの位置をシグナリングするために使用される。
【０３８２】
(b)に示されたように３つの若干異なるケースが可能である。(b)の左側に示された１番目ケースの場合、最後のFSS内のセルはType２マッピングに利用可能である。中間に示された２番目のケースの場合、FICは一般的なシンボルのセルに割り当てられるが、FICセルの数はCFSSより大きくない。(b)の右側に示された３番目のケースの場合、シンボルにマッピングされたFICセルの数がCFSSを超える点を除いて２番目のケースと同一である。
【０３８３】
PLS、EACおよびFICがType１の例のように「type１マッピングルール」と同様であるので、Type２DPに先行するtype１DPのケースは拡張が容易である。
【０３８４】
DPUは、フレーム内DPにデータセルを割り当てるための基本単位（basic unit）である。
【０３８５】
DPUは、フレーム内にDPを配置するためのシグナリング単位（ユニット）として定義される。セルマッパ７０１０は、DPのそれぞれのためのTIsによって生成されたセルをマッピングすることができる。タイムインターリーバ５０５０は、一連のTI-ブロックを出力し、それぞれのTI-ブロックは、セルセットから構成される様々な数のXFECBLOCKを含む（A Time interleaver 5050 outputs a series of TI-blocks and each TI-block comprises a variable number of XFECBLOCKs which is in turn composed of a set of cells）。XFECBLOCK内のセルの数Ncellsは、FECBLOCKの大きさ、Nldpc、および配置された（コンステレーション）シンボル（constellation symbol）ごとに伝送されたビットの数に依存（従属）する（dependent on）。DPUは、所与のPHYプロファイルでサポート（支持）されるXFECBLOCK内のセル数のすべての可能な値の最大公約数として定義される。セル内のDPUの長さはLDPUで定義される。PHYプロファイルのそれぞれは、FECBLOCK大きさと配置されたシンボル当たりの異なるビット数との異なる組み合わせをサポートするので、LDPUは、PHYプロファイルに基づいて定義される（Since each PHY profile supports different combinations of FECBLOCK size and a different number of bits per constellation symbol, LDPU is defined on a PHY profile basis）。
【０３８６】
図２２は、本発明の一実施例に係るFEC構造を示す。
【０３８７】
図２２は、ビットインターリーブの前の本発明の一実施例に係るFEC構造を示す。上述したように、データFECエンコーダは、外部コーディング(BCH)および内部コーディング(LDPC)を利用してFECBLOCK手順を生成するために、入力BBFに対してFECエンコーディングを実行することができる。図示されたFEC構造はFECBLOCKに該当する。また、FECBLOCKおよびFEC構造は、LDPCコードワードの長さに対応する同一の値を有する。
【０３８８】
図２２に示されたように、BCHエンコーディングがそれぞれのBBF(Kbchビット)に適用された後、LDPCエンコーディングがBCH-エンコーディングされたBBF(Kldpcビット=Nbchビット)に適用される。
【０３８９】
Nldpcの値は、６４８００ビット(long FECBLOCK)または１６２００ビット(short FECBLOCK)である。
【０３９０】
以下の表２８および表２９は、long FECBLOCKおよびshort FECBLOCKのそれぞれに対するFECエンコーディングパラメータを示す。
【０３９１】
【表２８】
2017508326.tif 000032
【０３９２】
【表２９】
2017508326.tif 000033
【０３９３】
BCHエンコーディングおよびLDPCエンコーディングの具体的な動作は次のとおりである。
【０３９４】
１２-エラー訂正BCHコードがBBFの外部エンコーディングに使用される。short FECBLOCKおよびlong FECBLOCKに対するBBF生成多項式は、すべての多項式を乗算することにより得られる。
【０３９５】
LDPCコードは、外部BCHエンコーディングの出力をエンコーディングするために使用される。完成されたBldpc(FECBLOCK)を生成するために、Pldpc(パリティビット)がそれぞれのIldpc(BCH-エンコーディングされたBBF)からシステム的にエンコーディングされ、Ildpcに添付される。完成されたBldpc(FECBLOCK)は次の数式で表現される。
【０３９６】
【数３】
2017508326.tif 000034
【０３９７】
long FECBLOCKおよびshort FECBLOCKに対するパラメータは、上記表２８および２９でそれぞれ与えられる。
【０３９８】
long FECBLOCKに対してNldpc-Kldpcパリティビットを計算する具体的な手順は次のとおりである。
【０３９９】
１）パリティビット初期化
【０４００】
【数４】
2017508326.tif 000035
【０４０１】
２）パリティチェックマトリックスのアドレスの１番目の行で特定されたパリティビットアドレスにおける１番目の情報ビットi0の累算（累積）(accumulate)。パリティチェックマトリックスのアドレスの詳細な内容は後述する。例えば、比率１３/１５に対して、
【０４０２】
【数５】
2017508326.tif 000036
【０４０３】
３）次の３５９個の情報ビットis、s=１、２、…、３５９に対して、次の数式を利用してパリティビットアドレスにおけるisを累算(accumulate)。
【０４０４】
【数６】
2017508326.tif 000037
【０４０５】
ここで、xは１番目のビットi0に対応するパリティビット累算器のアドレスを示し、Qldpcはパリティチェックマトリックスのアドレスで特定されたコードレート(code rate)依存定数である。上記例である比率１３/１５に対する、従って情報ビットi1に対するQldpc=２４に引き続き、次の動作が実行される。
【０４０６】
【数７】
2017508326.tif 000038
【０４０７】
４）３６１番目の情報ビットi360に対して、パリティビット累算器のアドレスは、パリティチェックマトリックスのアドレスの二番目の行で与えられる。同一の方式で、次の３５９個の情報ビットis、s=３６１、３６２、…、７１９に対するパリティビット累算器のアドレスは、数式６を利用して得られる。ここで、xは情報ビットi360に対応するパリティビット累算器のアドレス、すなわちパリティチェックマトリックスの二番目行のエントリを示す。
【０４０８】
５）同様の方式で、３６０個の新しい情報ビットのすべてのグループに対して、パリティチェックマトリックスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めるのに使用される。
【０４０９】
すべての情報ビットが利用された後、最終パリティビットが次のように得られる。
【０４１０】
６）i=１で始まり次の動作を順次実行
【０４１１】
【数８】
2017508326.tif 000039
【０４１２】
ここで、pi、i=０、１、...、Nldpc-Kldpc-１の最終コンテンツは、パリティビットpiと同一である。
【０４１３】
【表３０】
2017508326.tif 000040
【０４１４】
表３０を表３１に置き換え（代替し）、long FECBLOCKに対するパリティチェックマトリックスのアドレスをshort FECBLOCKに対するパリティチェックマトリックスのアドレスに置き換える（代替する）ことを除いて、short FECBLOCKに対する該当LDPCエンコーディング手順は、long FECBLOCKに対するt LDPCエンコーディング手順に従う。
【０４１５】
【表３１】
2017508326.tif 000041
【０４１６】
図２３は、本発明の一実施例に係るビットインターリーブを示す。
【０４１７】
LDPCエンコーダの出力には、グループ内インターリーブとQCB(Quasi-Cyclic Block)によるパリティインターリーブ（final parity bits）とから構成されるビット-インターリーブが行われる。
【０４１８】
(a)はQCBインターリーブを示し、(b)はグループ内インターリーブを示す。
【０４１９】
【数９】
2017508326.tif 000042
【０４２０】
【数１０】
2017508326.tif 000043
【０４２１】
【表３２】
2017508326.tif 000044
【０４２２】
グループ内インターリーブプロセスは、QCBインターリーブ出力のQCブロックNQCB_IGを使用して実行される（performed withNQCB_IGQC blocks of the QCB interleaving output）。グループ内インターリーブは、３６０列およびNQCB_IG個の行を使用したグループ内のビットを読み出しまたは書き込みするプロセスを有する。書き込み動作において（In the write operation）、QCBインターリーブ出力からのビットは行方向に（row-wise）書き込まれる。読み出し（リーディング）（reading）動作が実行される場合、それぞれの行からのmビットを列方向に（column-wise）読み出すことが実行される。MはNUCの１およびNUQの２と同一である。
【０４２３】
図２４は、本発明の一実施例に係るセル-ワードデマルチプレックスを示す。
【０４２４】
(a)は８および１２bpcu MIMOに関するセル-ワードデマルチプレックスを示し、(b)は１０bpcu MIMOのためのセル-ワードデマルチプレックスを示す。
【０４２５】
それぞれのビットインターリーブ出力のそれぞれのセルワード(c0,l、c1,l、…、cnmod-1,l)は、１つのXFECBLOCKのためのセル-ワードデマルチプレックス処理を説明した(a)に示されたように、(d1,0,m、d1,1,m…、d1,nmod-1,m)および(d2,0,m、d2,1,m…、d2,nmod-1,m)でデマルチプレックスされる。
【０４２６】
MIMOエンコーディングのためのNUQの他のタイプを利用する１０bpcu MIMOのケースのために、NUQ-１０２４のためのビットインターリーバが再使用される。ビットインターリーバ出力のそれぞれのセルワード(c0,l、c1,l、…、c9,l)は、(b)に示されたように(d1,0,m、d1,1,m…、d1,3,m)および(d2,0,m、d2,1,m…、d2,5,m)にデマルチプレックスされる。
【０４２７】
図２５は、本発明の一実施例に係るタイムインターリーブを示す。
【０４２８】
(a)〜(c)は、タイムインターリーブモードの例を示す。
【０４２９】
タイムインターリーバは、データパイプレベルで動作する。タイムインターリーブのパラメータは、それぞれのデータパイプに対して異なるように設定することができる。
【０４３０】
PLS２-STATデータの一部に現れる次のパラメータは、タイムインターリーブを構成する。
【０４３１】
DP_TI_TYPE(許容値：０または１)：タイムインターリーブモードを示す。０はタイムインターリーブグループ当たり複数のタイムインターリーブブロック(１つまたは複数のタイムインターリーブブロック)を有するモードを示す。この場合、１つのタイムインターリーブグループは、１つのフレームに(フレーム間インターリーブを行わずに)直接マッピングされる。１はタイムインターリーブグループ当たり１つのタイムインターリーブブロックのみを有するモードを示す。この場合、タイムインターリーブブロックは、１つまたは複数のフレームにわたって拡散される(フレーム間インターリーブ)。
【０４３２】
DP_TI_LENGTH：DP_TI_TYPE=「０」である場合、該当パラメータはタイムインターリーブグループ当たりのタイムインターリーブブロックの数NTIである。DP_TI_TYPE=「１」である場合、該当パラメータは１つのタイムインターリーブグループから拡散されるフレームの数PIである。
【０４３３】
DP_NUM_BLOCK_MAX(許容値：０〜１０２３)：タイムインターリーブグループ当たりのXFECBLOCKの最大数を示す。
【０４３４】
DP_FRAME_INTERVAL(許容値：１、２、４、８)：与えられた物理プロファイルの同じデータパイプを伝達する２つの連続するフレーム間のフレームの数IJUMPを示す。
【０４３５】
DP_TI_BYPASS(許容値：０または１)：タイムインターリーブがデータフレームのために利用されない場合、該当パラメータは１に設定される。タイムインターリーブが利用される場合、０に設定される。
【０４３６】
さらに、PLS２-DYNデータからのパラメータDP_NUM_BLOCKは、データグループの１つのタイムインターリーブグループによって伝達されるXFECBLOCKの数を示す。
【０４３７】
タイムインターリーブがデータフレームのために利用されない場合、次のタイムインターリーブグループ、タイムインターリーブ動作、タイムインターリーブモードは考慮されない。なお、スケジューラからのダイナミック構成情報のための遅延補償ブロックは依然（相変らず）必要である。それぞれのデータパイプで、SSD/MIMOエンコーディングから受信したXFECBLOCKは、タイムインターリーブグループでグループ化される。すなわち、それぞれのタイムインターリーブグループは、整数個のXFECBLOCKのセットであり、ダイナミックに変化する数のXFECBLOCKを含むことができる。インデックスnのタイムインターリーブグループ内のXFECBLOCKの数は、NxBLOCK_Group(n)で示され、PLS２-DYNデータにおけるDP_NUM_BLOCKとしてシグナリングされる。このとき、NxBLOCK_Group(n)は、最小値０から最大値が１０２３である最大値NxBLOCK_Group_MAX(DP_NUM_BLOCK_MAXに該当)まで変化することができる。
【０４３８】
それぞれのタイムインターリーブグループは、１つのフレームに直接マッピングまたはPI個のフレームにわたって拡散される。また、それぞれのタイムインターリーブグループは、１つまたは複数(NTI個)のタイムインターリーブブロックに分離する。ここで、それぞれのタイムインターリーブブロックは、タイムインターリーバメモリの１つの使用に対応する。タイムインターリーブグループ内のタイムインターリーブブロックは、若干異なる数のXFECBLOCKを含むことができる。タイムインターリーブグループが複数のタイムインターリーブブロックに分離される場合、タイムインターリーブグループは、１つのフレームのみに直接マッピングされる。以下の表３２に示したように、タイムインターリーブには３種類のオプションがある(タイムインターリーブを省略する追加オプションは除外)。
【０４３９】
【表３３】
2017508326.tif 000045
【０４４０】
各DPでは、TIメモリは、入力XFECBLOCKs（SSD/MIMO符号化ブロックからの出力XFECBLOCKs）を格納する（the TI memory stores the input XFECBLOCKs (output XFECBLOCKs from the SSD/MIMO encoding block）。入力XFECBLOCKsは、次のように定義されているものとする。
【０４４１】
【数１１】
2017508326.tif 000046
【０４４２】
【数１２】
2017508326.tif 000047
【０４４３】
【数１３】
2017508326.tif 000048
【０４４４】
また、時間インターリーバからの出力XFECBLOCKsブロックは、次のように定義されると仮定する（In addition, assume that output XFECBLOCKs from the time interleaver are defined as）。
【０４４５】
【数１４】
2017508326.tif 000049
【０４４６】
【数１５】
2017508326.tif 000050
【０４４７】
一般的に、タイムインターリーバは、フレーム生成処理以前のデータパイプデータに関するバッファにも作用する。これは、それぞれのデータパイプに関する２つのメモリバンクで達成される。一番目のタイムインターリーブブロックは一番目のバンクに書き込まれる（記入される）（written）。一番目のバンクで読み出されている（判読される）（read）間、二番目のタイムインターリーブブロックが二番目のバンクに書き込まれる。
【０４４８】
【数１６】
2017508326.tif 000051
【０４４９】
図２６は、本発明の一実施例に係るツイスト行列ブロックインターリーバの基本動作を示す。
【０４５０】
【数１７】
2017508326.tif 000052
【０４５１】
【数１８】
2017508326.tif 000053
【０４５２】
【数１９】
2017508326.tif 000054
【０４５３】
【数２０】
2017508326.tif 000055
【０４５４】
【数２１】
2017508326.tif 000056
【０４５５】
図２７は、本発明の他の一実施例に係るツイスト行列ブロックインターリーバの動作を示す。
【０４５６】
【数２２】
2017508326.tif 000057
【０４５７】
【数２３】
2017508326.tif 000058
【０４５８】
【数２４】
2017508326.tif 000059
【０４５９】
タイムインターリーブグループの数は３に設定される。タイムインターリーバのオプションは、DP_TI_TYPE=「０」、DP_FRAME_INTERVAL=「１」、DP_TI_LENGTH=「１」、すなわちNTI=１、IJUMP=１、PI=１によってPLS２-STATデータでシグナリングされる。それぞれNcells=３０であるXFECBLOCKのタイムインターリーブグループ当たりの数は、それぞれのNxBLOCK_TI(０、０)=３、NxBLOCK_TI(１、０)=６、NxBLOCK_TI(２、０)=５によってPLS２-DYNデータでシグナリングされる。XFECBLOCKの最大数はNxBLOCK_Group_MAXによってPLS２-STATデータでシグナリングされて、これは
【数２５】
2017508326.tif 000060
【０４６０】
図２８は、本発明の一実施例に係るツイスト行列ブロックインターリーバの対角線方向の読み出しパターンを示す。
【０４６１】
【数２６】
2017508326.tif 000061
【０４６２】
図２９は、本発明の一実施例に係るそれぞれのインターリーブアレイからのインターリーブされたXFECBLOCKを示す。
【０４６３】
【数２７】
2017508326.tif 000062
【０４６４】
図３０は、本発明の一実施例に係る放送サービスをサポートするためのプロトコルスタック(protocol stack)を示す。
【０４６５】
本発明の一実施例に係る放送サービスは、視聴覚（オーディオ／ビデオ）データ(Audio/Video、A/V)だけでなく、HTML５アプリケーション、双方向サービス、ACRサービス、セカンドスクリーン(second screen)サービス、個人化（カスタマイズ）(personalization)サービスなどの付加サービスを提供することができる。
【０４６６】
このような放送サービスは、地上波、ケーブル衛星などの放送信号である物理層(physical layer)を介して伝送される。また、本発明の一実施例に係る放送サービスは、インターネット通信網(broadband)を介して伝送される。
【０４６７】
放送サービスが地上波、ケーブル衛星などの放送信号である物理層(physical layer)を介して伝送される場合、放送受信装置は カプセル化(encapsulation)されたMPEG-２伝送ストリーム(Transport Stream、TS)とカプセル化されたIPデータグラムを、放送信号を復調(demodulation)して抽出することができる。放送受信装置は、IPデータグラムからユーザデータグラムプロトコル(User Datagram Protocol、UDP)データグラムを抽出することができる。放送受信装置は、UDPデータグラムからシグナリング情報を抽出することができる。このとき、シグナリング情報は、XML形態（フォーマット）を有することができる。また、放送受信装置は、UDPデータグラムから非同期階層コーディング/階層コーディング伝送(Asynchronous Layered Coding/ Layered Coding Transport、ALC/LCT)パケットを抽出することができる。放送受信装置は、ALC/LCTパケットから単方向ファイル伝送(File Delivery over Unidirectional Transport、FLUTE)パケットを抽出することができる。このとき、FLUTEパケットは非リアルタイム(Non-Real Time、NRT)データと電子サービスガイド(Electronic Service Guide、ESG)データとを含むことができる。また、放送受信装置は、UDPデータグラムからリアルタイム伝送プロトコル(Real-time Transport Protocol、RTCP)パケットおよびRTP制御プロトコル(RTP Control Protocol、RTCP)パケットを抽出することができる。放送受信装置は、RTP/RTCPパケットなどのリアルタイム伝送パケットからA/Vデータおよび付加データを抽出することができる。このとき、NRTデータ、A/Vデータおよび付加データのうち少なくともいずれか１つはISOベースの（ISOに基づく）メディアファイルフォーマット(ISO Base Media File Format、ISO BMFF)の形態を有することができる。また、放送受信装置は、MPEG-２TSパケットあるいはIPデータグラムからNRTデータ、A/V、PSI/PSIPなどのシグナリング情報を抽出することができる。
【０４６８】
放送サービスがインターネット通信網(broadband)を介して伝送される場合、放送受信装置は、インターネット通信網からIPパケットを受信することができる。放送受信装置は、IPパケットからTCPパケットを抽出することができる。放送受信装置は、TCPパケットからHTTPパケットを抽出することができる。放送受信装置は、HTTPパケットからA/V、付加データ、シグナリング情報などを抽出することができる。このとき、A/Vおよび付加データのうち少なくともいずれか１つはISO BMFF形態を有することができる。また、シグナリング情報は、XML形態を有することができる。
【０４６９】
具体的な放送サービスを伝送する伝送フレームおよび伝送パケットに関しては、図３１〜図３４を参照して説明する。
【０４７０】
図３１は、本発明の一実施例に係る放送伝送フレームを示す。
【０４７１】
図３１の実施例で、放送伝送フレームは、P１パート、L１パート、共通PLP(Common PLP)パート、インターリーブPLP(Scheduled & Interleaved PLP」s)パートおよび補助データ(Auxiliary data)パートを含む。
【０４７２】
図３１の実施例で、放送伝送装置は、放送伝送フレーム(transport frame)のP１パートを介して伝送シグナル検出（探知）(transport signal detection)のための情報を伝送する。また、放送伝送装置は、P１パートを介して放送信号チューニングのためのチューニング情報を伝送することができる。
【０４７３】
図３１の実施例で、放送伝送装置は、L１パートを介して放送伝送フレームの構成およびそれぞれのPLPの特性を伝送する。このとき、放送受信装置１００は、P１に基づいてL１パートをデコーディングして、放送伝送フレームの構成およびそれぞれPLPの特性を獲得することができる。
【０４７４】
図３１の実施例で、放送伝送装置は、Common PLPパートを介してPLP間で共通に適用される情報を伝送することができる。具体的な実施例によって、放送伝送フレームはCommon PLPパートを含まなくてもよい。
【０４７５】
図３１の実施例で、放送伝送装置は、放送サービスに含まれた複数のコンポーネントをインターリーブ(interleaved)PLPパートを介して伝送する。このとき、インターリーブPLPパートは複数のPLPを含む。
【０４７６】
図３１の実施例で、放送伝送装置は、それぞれの放送サービスを構成するコンポーネントがそれぞれどのPLPで伝送されるかを、L１パートまたはCommon PLPパートを介してシグナリングすることができる。ただし、放送受信装置１００が放送サービススキャンなどのために具体的な放送サービス情報を獲得するためには、インターリーブPLPパートの複数のPLPを全部デコーディングしなければならない。
【０４７７】
図３１の実施例とは違い、放送伝送装置は、放送伝送フレームを介して伝送される放送サービスと、放送サービスに含まれたコンポーネントに関する情報を含む付加パート（additional part）と、を含む放送伝送フレームを伝送することができる。このとき、放送受信装置１００は、付加パートを介して迅速に放送サービスと放送サービスに含まれたコンポーネントとに関する情報を獲得することができる。これに関しては、図３２を参照して説明する。
【０４７８】
図３２は、本発明の他の実施例に係る放送伝送フレームを示す。
【０４７９】
図３２の実施例において、放送伝送フレームは、P１パート、L１パート、高速情報チャネル(Fast Information Channel、FIC)パート、インターリーブPLP(Scheduled & Interleaved PLP」s)パートおよび補助データ(Auxiliary data)パートを含む。
【０４８０】
FICパートを除いた他のパートは、図３１の実施例と同一である。
【０４８１】
放送伝送装置は、FICパートを介して高速情報(fast information)を伝送する。高速情報は、伝送フレームを介して伝送される放送ストリームの構成情報(configuration information)、簡略な放送サービス情報およびコンポーネント情報を含むことができる。放送受信装置１００は、FICパートに基づいて放送サービスをスキャンすることができる。具体的には、放送受信装置１００は、FICパートから放送サービスに関する情報を抽出することができる。
【０４８２】
図３３は、本発明の一実施例に係る放送サービスを伝送する伝送パケットの構造を示す。
【０４８３】
図３３の実施例において、放送サービスを伝送する伝送パケットは、Network Protocolフィールド、Error Indicatorフィールド、Stuffing Indicatorフィールド、Pointer fieldフィールド、Stuffing bytesフィールドおよびペイロード(payload)データを含む。
【０４８４】
Network Protocolフィールドは、ネットワークプロトコルがどんなタイプであるかを示す。具体的な実施例において、Network Protocolフィールドの値は、IPv４プロトコルであるかまたはフレームパケットタイプであるかを示すことができる。具体的には、図３４の実施例のように、Network Protocolフィールドの値が０００である場合、IPv４プロトコルを示すことができる。また、具体的には、図３４の実施例のように、Network Protocolフィールドの値が１１１である場合、frame_packet_typeプロトコルを示すことができる。このとき、framed_packet_typeは、例えばATSC A/１５３によって定義されたプロトコルである。具体的には、framed_packet_typeは長さに関する情報を示すフィールドを含まないネットワークパケットプロトコルを示すことができる。具体的な実施例において、Network Protocolフィールドは、例えば３ビットフィールドである。
【０４８５】
Error Indicatorフィールドは、該当伝送パケットにエラーが検出されたか否かを表示する。具体的には、Error Indicatorフィールドの値が０である場合、該当パケットでエラーが検出されないことを示し、Error Indicatorフィールドの値が１である場合、該当パケットでエラーが検出されたことを示すことができる。具体的な実施例において、Error Indicatorフィールドは、例えば１ビットフィールドである。
【０４８６】
Stuffing Indicatorフィールドは、該当伝送パケットにスタッフィングバイト(stuffing bytes)が含まれているか否かを表示する。このとき、スタッフィングバイトは、固定されたパケットの長さを維持するためにペイロードに含まれるデータを示す。具体的な実施例において、Stuffing Indicatorフィールドの値が１である場合、伝送パケットがスタッフィングバイトを含み、Stuffing Indicatorフィールドの値が０である場合、伝送パケットスタッフィングバイトを含まないことを示すことができる。具体的な実施例において、Stuffing Indicatorフィールドは、例えば１ビットフィールドである。
【０４８７】
Pointer fieldフィールドは、該当伝送パケットのペイロードの部分で新しいネットワークパケットの開始点を表示する。具体的な実施例において、Pointer fieldの値が０x７FFである場合、新しいネットワークパケットの開始点がないことを示すことができる。また、具体的な実施例において、Pointer fieldの値が０x７FFではない場合、伝送パケットヘッダの最後の部分から新しいネットワークパケットの開始点までのオフセット(offset)値を示すことができる。具体的な実施例において、Pointer fieldフィールドは、例えば１１ビットフィールドである。
【０４８８】
Stuffing_Bytesフィールドは、固定されたパケットの長さを維持するためにヘッダとペイロードデータとの間を満たすスタッフィングバイトを示す。
【０４８９】
このような放送サービスを受信するための放送受信装置の構成に対しては、図３４を参照して説明する。
【０４９０】
図３５は、本発明の一実施例に係る放送受信装置の構成を示す。
【０４９１】
図３５の実施例において、放送受信装置１００は、放送受信部１１０、インターネットプロトコル(Internet Protocol、IP)通信部１３０および制御部１５０を含む。
【０４９２】
放送受信部１１０は、チャネル同期化（同期）部(Channel Synchronizer)１１１、チャネルイコライザー(channel equalizer)１１３およびチャネルデコーダ(channel decoder)１１５を含む。
【０４９３】
チャネル同期化部１１１は、放送信号を受信できるベースバンド(baseband)でデコーディングが可能なようにシンボル周波数とタイミングを同期化する。
【０４９４】
チャネルイコライザー１１３は、同期化された放送信号の歪みを補償（補正）する（correct）。具体的には、チャネルイコライザー１１３は、マルチパス(multipath)、ドップラ効果などによる同期化された放送信号の歪みを補償する。
【０４９５】
チャネルデコーダ１１５は、歪みが補償された放送信号をデコーディングする。具体的には、チャネルデコーダ１１５は、歪みが補償された放送信号から伝送フレーム(transport frame)を抽出する。このとき、チャネルデコーダ１１５は、FEC(Forward Error Correction)を行うことができる。
【０４９６】
IP通信部１３０は、インターネット網を介してデータを受信して伝送する。
【０４９７】
制御部１５０は、シグナリングデコーダ１５１、伝送パケットインターフェース１５３、ブロードバンドパケットインターフェース１５５、ベースバンド動作制御部１５７、共通プロトコルスタック(Common Protocol Stack)１５９、サービスマップデータベース１６１、サービスシグナリングチャネルプロセッシングバッファ(buffer)およびパーサ(parser)１６３、A/Vプロセッサ１６５、放送サービスガイドプロセッサ１６７、アプリケーションプロセッサ１６９並びにサービスガイドデータベース１７１を含む。
【０４９８】
シグナリングデコーダ１５１は、放送信号のシグナリング情報をデコーディングする。
【０４９９】
伝送パケットインターフェース１５３は、放送信号から伝送パケットを抽出する。このとき、伝送パケットインターフェース１５３は、抽出した伝送パケットからシグナリング情報またはIPデータグラムなどのデータを抽出することができる。
【０５００】
ブロードバンドパケットインターフェース１５５は、インターネット網から受信したデータからIPパケットを抽出する。このとき、ブロードバンドパケットインターフェース１５５は、IPパケットからシグナリングデータまたはIPデータグラムを抽出することができる。
【０５０１】
ベースバンド動作制御部１５７は、ベースバンドから放送情報受信情報を受信することに関連した動作を制御する。
【０５０２】
共通プロトコルスタック１５９は、伝送パケットからオーディオまたはビデオを抽出する。
【０５０３】
A/Vプロセッサ５４７は、オーディオまたはビデオを処理する。
【０５０４】
サービスシグナリングチャネルプロセッシングバッファ(buffer)およびパーサ(parser)１６３は、放送サービスをシグナリングするシグナリング情報を解析（パージング）してバッファリングする。具体的には、サービスシグナリングチャネルプロセッシングバッファおよびパーサ１６３は、IPデータグラムから放送サービスをシグナリングするシグナリング情報を解析してバッファリングすることができる。
【０５０５】
サービスマップデータベース１６５は、放送サービスに関する情報を含む放送サービスリストを格納する。
【０５０６】
サービスガイドプロセッサ１６７は、地上波放送サービスのプログラムを案内する地上波放送サービスガイドデータを処理する。
【０５０７】
アプリケーションプロセッサ１６９は、放送信号からアプリケーション関連情報を抽出して処理する。
【０５０８】
サービスガイドデータベース１７１は、放送サービスのプログラム情報を格納する。
【０５０９】
図３６は、本発明の他の実施例に係る放送受信装置の構成を示す。
【０５１０】
図３６の実施例で、放送受信装置１００は、放送受信部１１０、インターネットプロトコル(Internet Protocol、IP)通信部１３０および制御部１５０を含む。
【０５１１】
放送受信部１１０は、放送受信部１１０が行う複数の機能のそれぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路および１つまたは複数のハードウェアモジュールを含むことができる。具体的には、放送受信部１１０は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品とプロセッサおよびDRAMなどの半導体が１つに統合された半導体とからなることができる。放送受信部１１０は、物理層モジュール１１９と物理層IPフレームモジュール１１７とを含むことができる。物理層モジュール１１９は、放送網の放送チャネルを介して放送関連信号を受信して処理する。物理層IPフレームモジュール１１７は、物理層モジュール１１９から獲得したIPデータグラムなどのデータパケットを特定フレームに変換する。例えば、物理層モジュール１１９は、IPデータグラムなどをRS FrameまたはGSEなどに変換することができる。
【０５１２】
IP通信部１３０は、IP通信部１３０が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路および１つまたは複数のハードウェアモジュールを含むことができる。具体的には、IP通信部１３０は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品とプロセッサおよびDRAMなどの半導体が１つに統合された半導体とからなることができる。IP通信部１３０はインターネットアクセス（接近）（access）制御モジュール１３１を含むことができる。インターネットアクセス制御モジュール１３１は、インターネット通信網(broad band)を介してサービス、コンテンツおよびシグナリングデータのうち少なくともいずれか１つを獲得するための放送受信装置１００の動作を制御する。
【０５１３】
制御部１５０は、制御部１５０が行う複数の機能のそれぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路および１つまたは複数のハードウェアモジュールを含むことができる。具体的には、制御部１５０は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品とプロセッサおよびDRAMなどの半導体が１つに統合された半導体とからなることができる。制御部１５０は、シグナリングデコーダ１５１、サービスマップデータベース１６１、サービスシグナリングチャネルパーサ１６３、アプリケーションシグナリングパーサ１６６、警告シグナリングパーサ１６８、ターゲティングシグナリングパーサ１７０、ターゲティングプロセッサ１７３、A/Vプロセッサ１６１、警告プロセッサ１６２、アプリケーションプロセッサ１６９、スケジュールされたストリーミングデコーダ(scheduled streaming decoder)１８１、ファイルデコーダ１８２、ユーザ要求ストリーミングデコーダ１８３、ファイルデータベース１８４、コンポーネント同期化部１８５、サービス/コンテンツ獲得制御部１８７、再分配モジュール１８９、デバイスマネージャ１９３およびデータシェアリング部１９１のうち少なくともいずれか１つを含むことができる。
【０５１４】
サービス/コンテンツ獲得制御部１８７は、放送網またはインターネット通信網を介して獲得したサービス、コンテンツ、サービスまたはコンテンツに関連したシグナリングデータを獲得するための受信器の動作を制御する。
【０５１５】
シグナリングデコーダ１５１は、シグナリング情報をデコーディングする。
【０５１６】
サービスシグナリングパーサ１６３は、サービスシグナリング情報を解析する。
【０５１７】
アプリケーションシグナリングパーサ１６６は、サービスに関連したシグナリング情報を抽出して解析する。このとき、サービスに関連したシグナリング情報は、サービススキャンに関連したシグナリング情報を含むことができる。また、サービスに関連したシグナリング情報は、サービスを介して提供されるコンテンツに関連したシグナリング情報を含むことができる。
【０５１８】
警告シグナリングパーサ１６８は、警告に関連したシグナリング情報を抽出して解析する。
【０５１９】
ターゲティングシグナリングパーサ１７０は、サービスまたはコンテンツを個人化(personalization)するための情報またはターゲティング情報をシグナリングする情報を抽出して解析する。
【０５２０】
ターゲティングプロセッサ１７３は、サービスまたはコンテンツを個人化するための情報を処理する。
【０５２１】
警告プロセッサ１６２は、警告に関連したシグナリング情報を処理する。
【０５２２】
アプリケーションプロセッサ１６９は、アプリケーション関連情報およびアプリケーションの実行を制御する。具体的には、アプリケーションプロセッサ１６９は、ダウンロードされたアプリケーションの状態およびディスプレイパラメータを処理する。
【０５２３】
A/Vプロセッサ１６１は、デコーディングされたオーディオまたはビデオ、アプリケーションデータなどに基づいて、オーディオ/ビデオのレンダリング関連動作を処理する。
【０５２４】
スケジュールされたストリーミングデコーダ１８１は、あらかじめ放送会社などのコンテンツ提供業者が定めた日程どおりストリーミングされるコンテンツであるスケジュールされたストリーミングをデコーディングする。
【０５２５】
ファイルデコーダ１８２はダウンロードされたファイルをデコードする。特に、ファイルデコーダ１８２は、インターネット通信網を介してダウンロードされたファイルをデコードする。
【０５２６】
ユーザ要求ストリーミングデコーダ１８３は、ユーザ要求によって提供されるコンテンツ(例えば、On Demand Content（オンデマンドコンテンツ）)をデコードする。
【０５２７】
ファイルデータベース１８４はファイルを格納する。具体的には、ファイルデータベース１８４は、インターネット通信網を介してダウンロードしたファイルを格納することができる。
【０５２８】
コンポーネント同期化部１８５は、コンテンツまたはサービスを同期化する。具体的には、コンポーネント同期化部１８５は、スケジュールされたストリーミングデコーダ１８１、ファイルデコーダ１８２およびユーザ要求ストリーミングデコーダ１８３のうち少なくともいずれか１つがデコーディングしたコンテンツを同期化することができる。
【０５２９】
サービス/コンテンツ獲得制御部１８７は、サービス、コンテンツ、サービスまたはコンテンツに関連したシグナリング情報のうち少なくともいずれか１つを獲得するための受信器の動作を制御する。
【０５３０】
再分配モジュール１８９は、放送網を介してサービスまたはコンテンツを受信できない場合、サービス、コンテンツ、サービス関連情報（service related information）およびコンテンツ関連情報のうち少なくともいずれか１つの獲得をサポートするための動作を行う。具体的には、外部の管理装置３００にサービス、コンテンツ、サービス関連情報およびコンテンツ関連情報のうち少なくともいずれか１つを要求することができる。このとき、外部の管理装置３００は、コンテンツサーバーからなることができる。
【０５３１】
デバイスマネージャ１９３は、連動可能な外部装置を管理する。具体的には、デバイスマネージャ１９３は、外部装置の追加、削除および更新のうち少なくともいずれか１つを行うことができる。また、外部装置は、放送受信装置１００との接続およびデータ交換が可能である。
【０５３２】
データシェアリング部１９１は、放送受信装置１００と外部装置との間のデータ伝送動作を行い、交換関連情報を処理する。具体的には、データシェアリング部１９１は、外部装置にA/Vデータまたはシグナリング情報を伝送することができる。また、データシェアリング部１９１は、外部装置からA/Vデータまたはシグナリング情報を受信することができる。
【０５３３】
図３７は、本発明の一実施例に係る放送サービスシグナリングテーブルおよび放送サービス伝送経路シグナリング情報が、放送サービスおよび放送サービス伝送経路をシグナリングすることを示す。
【０５３４】
放送サービスシグナリングテーブルは、放送サービス情報をシグナリングすることができる。具体的には、放送サービスが含むメディアコンポーネントをシグナリングすることができる。また、放送サービスシグナリングテーブルは、放送サービスと放送サービスが含むメディアコンポーネントの伝送経路とをシグナリングすることができる。このために放送サービスシグナリングテーブルは、放送サービス伝送経路シグナリング情報を含むことができる。図３７の実施例において、放送サービスシグナリングテーブルは、複数の放送サービスに関する情報を含む。このとき、放送サービスシグナリングテーブルは、複数の放送サービスのそれぞれに含まれた複数のメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報を含む。特に、放送サービスシグナリングテーブルは、複数のメディアコンポーネントの伝送経路をシグナリングする放送サービス伝送経路シグナリング情報を含む。例えば、放送サービスシグナリングテーブルを介して、放送受信装置１００は、サービス(Service０)に含まれるビデオ(Video０)が物理層パイプ(PLP０)を介して伝送されることがわかる。また、放送サービスシグナリングテーブルを介して、放送受信装置１００は、サービス(ServiceN)に含まれるオーディオ(Audio１)がインターネット網を介して伝送されることがわかる。このとき、物理層パイプ(Physical Layer Pipe、PLP)は、物理層(physical layer)において識別可能な一連の論理データ伝達経路である。PLPはデータパイプ(data pipe)等他の用語で称してもよい。
【０５３５】
図３８〜図４３を参照して、放送サービスシグナリングテーブルに関して具体的に説明する。
【０５３６】
図３８は、本発明の一実施例に係る放送サービスシグナリングテーブルを示す。
【０５３７】
放送サービスシグナリングテーブルは、放送サービスを識別する情報、放送サービスの現在の状態を示す情報、放送サービス名（のネーム）、放送サービスのチャンネル番号（チャネルナンバ）、放送サービスに対する保護アルゴリズムの適用の有無を示す情報、放送サービスのカテゴリ情報および放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報のうち少なくともいずれか１つを含むことができる。放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのメディアコンポーネントが該当放送サービスに必須であるか否かを示す情報を含むことができる。また、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのコンポーネントに関連した情報を含むことができる。
【０５３８】
具体的には、図３８の実施例のように、放送サービスシグナリングテーブルは、table_idフィールド、section_syntax_indicatorフィールド、private_indicatorフィールド、section_lengthフィールド、table_id_extensionフィールド、version_numberフィールド、current_next_indicatorフィールド、section_numberフィールド、last_section_numberrフィールド、num_servicesフィールド、service_idフィールド、service_statusフィールド、SP_indicatorフィールド、short_service_name_lengthフィールド、short_service_nameフィールド、channel_numberフィールド、service_categoryフィールド、num_componentsフィールド、essential_component_indicatorフィールド、num_component_level_descriptorフィールド、component_level_descriptorフィールド、num_service_level_descriptorsフィールド、およびservice_level_descriptorフィールドのうち少なくともいずれか１つを含むことができる。
【０５３９】
table_idフィールドは、放送サービスシグナリング情報テーブルの識別子を示す。このとき、table_idフィールドの値は、ATSC A/６５で定義されたreserved id値のうちの１つである。具体的な実施例において、table_idフィールドは、例えば、８ビットフィールドである。
【０５４０】
section_syntax_indicatorフィールドは、放送サービスシグナリング情報テーブルのＭＰＥＧ-２TS標準のlong形式のprivate section tableであるか否かを示す。具体的な実施例において、Section_syntax_indicatorフィールドは、例えば１ビットフィールドである。
【０５４１】
private_indicatorフィールドは、現在のテーブルがprivate sectionに該当するか否かを示す。具体的な実施例において、Private_indicatorフィールドは、例えば１ビットフィールドである。
【０５４２】
section_lengthフィールドは、section_lengthフィールド以後に含まれたsectionの長さを示す。具体的な実施例において、Section_lengthフィールドは、例えば１２ビットフィールドである。
【０５４３】
table_id_extensionフィールドは、table_idフィールドと組み合わせ（結合し）て（in combination with）放送サービスシグナリング情報テーブルを識別する値を示す。特に、table_idフィールドは、サービスシグナリング情報テーブルのプロトコルバージョンを示すSMT_protocol_versionフィールドを含むことができる。具体的な実施例において、SMT_protocol_versionフィールドは、例えば８ビットフィールドである。
【０５４４】
version_numberフィールドは、サービスシグナリングテーブルのバージョンを示す。放送受信装置１００は、vserion_numberフィールドの値に基づいてサービスシグナリング情報テーブルの情報を利用するか否かを決定することができる。具体的には、version_numberフィールドの値が以前に受信したサービスシグナリングテーブルのバージョンと同一である場合、サービスシグナリングテーブルの情報を利用しなくてもよい。具体的な実施例において、version_numberフィールドは、例えば５ビットフィールドである。
【０５４５】
current_next_indicatorフィールドは、放送サービスシグナリングテーブルの情報が現在使用可能であるか否かを示す。具体的には、current_next_indicatorフィールドの値が１である場合、放送サービスシグナリングテーブルの情報が使用可能であること示すことができる。また、current_next_indicatorフィールドの値が１である場合、放送サービスシグナリングテーブルの情報を次に使用できることを示すことができる。具体的な実施例において、current_next_indicatorフィールドは、例えば１ビットフィールドである。
【０５４６】
section_numberフィールドは、現在のセクションの番号を示す。具体的な実施例において、Section_numberフィールドは、例えば８ビットフィールドである。
【０５４７】
last_section_numberフィールドは、最後のセクションの番号を示す。放送サービスシグナリングテーブルの大きさが大きい場合、複数のセクションに分けて伝送することができる。このとき、放送受信装置１００は、section_numberフィールドおよびlast_section_numberフィールドに基づいて放送サービスシグナリングテーブルに必要なすべてのセクションの受信をするかしないかを判断する。具体的な実施例において、last_section_numberフィールドは、例えば８ビットフィールドである。
【０５４８】
service_idフィールドは、放送サービスを識別する識別子を示す。具体的な実施例において、Service_idフィールドは、例えば１６ビットフィールドである。
【０５４９】
service_statusフィールドは、放送サービスの現在の状態を示す。具体的には、放送サービスが現在利用可能であるか否かを示すことができる。具体的な実施例において、Service_statusフィールドの値が１である場合、放送サービスが現在利用可能であることを示すことができる。具体的な実施例において、放送受信装置１００は、service_statusフィールドの値に基づいて該当放送サービスを放送サービスリストおよび放送サービスガイドに表示するか否かを決定することができる。例えば、放送受信装置１００は、該当放送サービスが使用不可能である場合、該当放送サービスを放送サービスリストおよび放送サービスガイドに表示しなくてもよい。また、他の具体的な実施例において、放送受信装置１００は、service_statusフィールドの値に基づいて該当放送サービスに関するアクセスを制限することができる。例えば、該当放送サービスが使用不可能である場合、放送受信装置１００は、該当放送サービスに関するチャンネル（チャネル）アップ/ダウンキーを介したアクセスを制限することができる。具体的な実施例において、Service_statusフィールドは、例えば２ビットフィールドである。
【０５５０】
SP_indicatorフィールドは、該当放送サービス内の１つまたは複数のコンポーネントがサービスプロテクション(protection)が適用されたか否かを示すことができる。例えばSP_indicatorの値が１である場合、該当放送サービス内の１つまたは複数のコンポーネントにサービスプロテクションが適用されたことを示すことができる。具体的な実施例において、SP_indicatorフィールドは、例えば１ビットフィールドである。
【０５５１】
short_service_name_lengthフィールドは、short_service_nmaeフィールドの大きさを示す。
【０５５２】
short_service_nameフィールドは、放送サービスの名前を示す。具体的には、short_service_nemaフィールドは、放送サービスの名前を要約して表示することができる。
【０５５３】
channel_numberフィールドは、該当放送サービスの仮想チャンネル番号（チャネルナンバ）を表示する。
【０５５４】
service_categoryフィールドは、放送サービスのカテゴリを示す。具体的には、service_categoryフィールドは、TV（オーディオ／ビデオ）サービス、ラジオ（オーディオのみの）サービス、放送サービスガイド、RIサービスおよび緊急警告(Emergency Alerting)のいずれか１つを示すことができる。例えば、図３９の実施例のように、service_categoryフィールドの値が０x０１である場合TVサービスを示し、service_categoryフィールドの値が０x０２である場合ラジオサービスを示し、service_categoryフィールドの値が０x０３である場合RIサービスを示し、service_categoryフィールドの値が０x０８である場合、サービスガイドを示し、service_categoryフィールドの値が０x０９である場合、緊急警報を示すことができる。具体的な実施例において、Service_categoryフィールドは、例えば６ビットフィールドである。
【０５５５】
num_componentsフィールドは、該当放送サービスが含むメディアコンポーネントの個数を示す。具体的な実施例において、num_componentフィールドは、例えば５ビットフィールドである。
【０５５６】
essential_component_indicatorフィールドは、該当メディアコンポーネントが該当放送サービス再生(presentation)のために必要な必須メディアコンポーネントであるか否かを示す。具体的な実施例において、essential_component_indicatorフィールドは、例えば１ビットフィールドである。
【０５５７】
num_component_level_descriptorフィールドは、component_level_descrptorフィールドの個数を示す。具体的な実施例において、num_component_level_descriptorフィールドは、例えば４ビットフィールドである。
【０５５８】
component_level_descriptorフィールドは、該当コンポーネントに関する付加的な属性を含む。
【０５５９】
num_service_level_descriptorsフィールドは、service_level_descriptorフィールドの個数を示す。具体的な実施例において、num_service_level_descriptorsフィールドは、例えば４ビットフィールドである。
【０５６０】
service_level_descriptorフィールドは、該当サービスに関する付加的な属性を含む。
【０５６１】
サービスシグナリングテーブルは、アンサンブルに関する情報をさらに含むことができる。アンサンブルは、１つまたは複数のサービスが同じFEC(Forward Error Correction)が適用されて伝送される場合、１つまたは複数のサービスのセットを示す。これに関しては、図４９を参照して具体的に説明する。
【０５６２】
図４０は、本発明の他の実施例に係る放送サービスシグナリングテーブルを示す。
【０５６３】
具体的には、図４０の実施例のように、放送サービスシグナリングテーブルは、num_ensemble_level_descriptorsフィールドおよびensemble_level_descriptorフィールドをさらに含むことができる。
【０５６４】
num_ensemble_level_descriptorsフィールドは、ensemble_level_descriptorフィールドの個数を示す。具体的な実施例において、num_ensemble_level_descriptorsフィールドは、例えば４ビットフィールドである。
【０５６５】
ensemble_level_descriptorフィールドは、該当アンサンブルに関する付加的な属性を含む。
【０５６６】
また、サービスシグナリングテーブルは、メディアコンポーネントを識別するためにメディアコンポーネントを識別するストリーム識別子情報をさらに含むことができる。これに関しては、図４１を参照して具体的に説明する。
【０５６７】
図４１は、本発明の他の一実施例に係るストリーム識別記述子を示す。
【０５６８】
ストリーム識別子情報は、descriptor_tagフィールド、descriptor_lengthフィールドおよびcomponent_tagフィールドのうち少なくともいずれか１つを含むことができる。
【０５６９】
descriptor_tagフィールドは、該当descriptorがストリーム識別子情報を含むdescirptorであることを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０５７０】
descriptor_lengthフィールドは、該当フィールド以後のストリーム識別子情報の長さを示す。具体的な実施例において、descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０５７１】
component_tagフィールドは、メディアコンポーネントを識別するメディアコンポーネント識別子を示す。このとき、メディアコンポーネント識別子は、該当シグナリング情報テーブル上で他のメディアコンポーネントのメディアコンポーネント識別子と異なる一意な（唯一の）(unique)値を有することができる。具体的な実施例において、component_tagフィールドは、例えば８ビットフィールドである。
【０５７２】
放送サービスシグナリングテーブルを伝送・受信する動作に関しては、図４２〜図４６を参照して説明する。
【０５７３】
以上では、放送サービステーブルをビットストリーム形式で説明したが、具体的な実施例によって、放送サービステーブルはXML形式を有することができる。
【０５７４】
図４２は、本発明の一実施例に係る放送伝送装置が放送サービスシグナリングテーブルを伝送する動作を示す。
【０５７５】
本発明の一実施例に係る放送伝送装置は、放送信号を伝送する伝送部および放送伝送装置の動作を制御する制御部を含むことができる。伝送部は、伝送部が行う複数の機能のそれぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路および１つまたは複数のハードウェアモジュールを含むことができる。具体的には、伝送部は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品とプロセッサおよびDRAMなどの半導体が１つに統合された半導体とからなることができる。制御部は、制御部が行う複数の機能のそれぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路および１つまたは複数のハードウェアモジュールを含むことができる。具体的には、制御部は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなどの各種マルチメディア用部品とプロセッサおよびDRAMなどの半導体が１つに統合された半導体とからなることができる。
【０５７６】
放送伝送装置は、制御部を介して放送サービス情報を獲得する(S１０１)。このとき、放送サービス情報は、放送サービスを説明する情報である。具体的には、放送サービス情報は、放送サービスを識別する情報、放送サービスの現在の状態を示す情報、放送サービス名、放送サービスのチャンネル番号、放送サービスに対する保護アルゴリズム適用の有無を示す情報、放送サービスのカテゴリ情報および放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報のうち少なくともいずれか１つを含むことができる。放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのメディアコンポーネントが該当放送サービスに必須であるか否かを示す情報を含むことができる。また、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのコンポーネントに関連した情報を含むことができる。
【０５７７】
放送伝送装置は、制御部を介して放送サービス情報に基づいて放送サービスシグナリングテーブルを生成する(S１０３)。このとき、放送サービスシグナリングテーブルは、前述した放送サービス情報を含むことができる。
【０５７８】
放送伝送装置は、伝送部を介してサービスシグナリングテーブルを含む放送信号を伝送する(S１０５)。
【０５７９】
図４３は、本発明の一実施例に係る放送受信装置が放送サービスシグナリングテーブルを受信する動作を示す。
【０５８０】
放送受信装置１００は、放送受信部１１０を介して放送信号を受信する(S３０１)。
【０５８１】
放送受信装置１００は、制御部１５０を介して放送信号に基づいて放送サービスシグナリングテーブルを獲得する(S３０３)。具体的には、放送受信装置１００は、放送信号から放送サービスシグナリングテーブルを獲得することができる。このとき、放送サービスシグナリングテーブルは、上述したように放送サービスを識別する情報、放送サービスの現在の状態を示す情報、放送サービス名、放送サービスのチャンネル番号、放送サービスに対する保護アルゴリズム適用の有無を示す情報、放送サービスのカテゴリ情報および放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報のうち少なくともいずれか１つを含むことができる。放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのメディアコンポーネントが該当放送サービスに必須であるか否かを示す情報を含むことができる。また、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのコンポーネントに関連した情報を含むことができる。ただし、具体的な実施例によっては、放送受信装置１００は、放送サービスシグナリングテーブルをインターネット網を介して獲得することができる。
【０５８２】
放送受信装置１００は、制御部１５０を介して放送サービスシグナリングテーブルに基づいて放送サービス情報を獲得する(S３０５)。このとき、放送サービス情報は、上述したように放送サービスを識別する情報、放送サービスの現在の状態を示す情報、放送サービス名、放送サービスのチャンネル番号、放送サービスに対する保護アルゴリズム適用の有無を示す情報、放送サービスのカテゴリ情報および放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報のうち少なくともいずれか１つを含むことができる。放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのメディアコンポーネントが該当放送サービスに必須であるか否かを示す情報を含むことができる。また、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報は、それぞれのコンポーネントに関連した情報を含むことができる。
【０５８３】
放送受信装置１００は、制御部１５０を介して放送サービス情報に基づいて放送サービスに関する情報を格納する放送サービスリストを生成する(S３０７)。このとき、放送サービスリストは、放送受信装置１００が獲得した放送サービス情報を含むことができる。具体的な実施例において、放送受信装置１００は、放送サービス情報または放送サービスリストに基づいて放送サービスを受信することができる。
【０５８４】
図４４は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報を示す。
【０５８５】
放送サービス伝送経路シグナリング情報は、放送サービスを伝送するネットワークの形態を示す情報と放送伝送形態に応じた具体的な伝送情報とを含むことができる。放送サービスを伝送するネットワークの種類は、放送サービスが同一の放送局(broadcaster)が伝送するIPストリームを介して伝送するネットワーク、放送サービスが異なる（他の）（different）放送局が伝送するIPストリームを介して伝送するネットワーク、放送サービスが同一の放送局のFLUTEセッションを介して伝送するネットワーク、放送サービスが異なる放送局のFLUTEセッションを介して伝送するネットワーク、放送サービスが異なる放送局のMPEG-２TSを介して伝送するネットワーク、放送サービスが異なる放送局のパケットベースのストリームを介して伝送するネットワーク、放送サービスがIPベースの放送ネットワークで伝送されるパケットベースのストリームを介して伝送するネットワークおよびユニフォームリソースロケータ（Uniform Resource Locator；URL）を介して放送サービスを獲得できるネットワークのうちのいずれか１つを含むことができる。
【０５８６】
具体的な実施例において、図４４のように、放送サービス伝送経路シグナリング情報は、descriptor_tagフィールド、description_lengthフィールド、delivery_network_typeフィールドおよびdata_pathフィールドを含むことができる。
【０５８７】
descriptor_tagフィールドは、該当descriptorが伝送経路シグナリング情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０５８８】
descriptior_lengthフィールドは、該当フィールド以後の放送サービス伝送経路シグナリング情報の長さを示す。具体的な実施例において、descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０５８９】
delivery_network_typeフィールドは、放送サービスを伝送する伝送ネットワークの種類を示す。具体的な実施例において、delivery_network_typeフィールドの値は、放送サービスを同一の放送局(broadcaster)が伝送するIPストリームを介して伝送するネットワーク、放送サービスを異なる放送局が伝送するIPストリームを介して伝送するネットワーク、放送サービスを同一の放送局のFLUTEセッションを介して伝送するネットワーク、放送サービスを異なる放送局のFLUTEセッションを介して伝送するネットワーク、放送サービスを異なる放送局のMPEG-２TSを介して伝送するネットワーク、放送サービスを異なる放送局のパケットベースのストリームを介して伝送するネットワーク、放送サービスをIPベースの放送ネットワークで伝送されるパケットベースのストリームを介して伝送するネットワークおよびURLを介して放送サービスを獲得できるネットワークのうちのいずれか１つを示すことができる。例えば、図４５の実施例のように、delivery_network_typeフィールドの値が０x００である場合、delivery_network_typeフィールドは、放送サービスを同一の放送局(broadcaster)が伝送するIPストリームを介して伝送するネットワークを示すことができる。また、delivery_network_typeフィールドの値が０x０１である場合、delivery_network_typeフィールドは、放送サービスを異なる放送局が伝送するIPストリームを介して伝送するネットワークを示すことができる。また、delivery_network_typeフィールドの値が０x０２である場合、delivery_network_typeフィールドは、放送サービスを同一の放送局のFLUTEセッションを介して伝送するネットワークを示すことができる。また、delivery_network_typeフィールドの値が０x０３である場合、delivery_network_typeフィールドは、放送サービスを異なる放送局のFLUTEセッションを介して伝送するネットワークを示すことができる。また、delivery_network_typeフィールドの値が０x０４である場合、delivery_network_typeフィールドは、放送サービスを異なる放送局のMPEG-２TSを介して伝送するネットワークを示すことができる。また、delivery_network_typeフィールドの値が０x０５である場合、放送サービスを異なる放送局のパケットベースのストリームを介して伝送するネットワークを示すことができる。また、delivery_network_typeフィールドの値が０x０６である場合、delivery_network_typeフィールドは、放送サービスをIPベースの放送ネットワークで伝送されるパケットベースのストリームを介して伝送するネットワークを示すことができる。また、delivery_network_typeフィールドの値が０x０７である場合、delivery_network_typeフィールドはURLを介して放送サービスを獲得できるネットワークを示すことができる。
【０５９０】
data_pathフィールドは、放送サービスを伝送する伝送ネットワークの種類に応じた具体的な伝送情報を含む。data_pathフィールドに関しては、図４６〜図５４を参照して説明する。
【０５９１】
図４６は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、IPストリームを介した放送サービスの伝送をシグナリングすることを示す。
【０５９２】
放送サービスを伝送するネットワークが、放送サービスを同一の放送局(broadcaster)が伝送するIPストリームを介して伝送するネットワークである場合、放送サービス伝送経路シグナリング情報は、IPバージョンを示す情報、ソース(source)IPアドレスを含むか否かを示す情報、ソース（送信元）IPアドレス、デスティネーション（送信先）(destination)IPアドレスを含むか否かを示す情報、デスティネーションIPアドレス、放送サービスを伝送するIPデータグラムフロー(flow)のUDPポートの個数を示す情報およびUDPポートナンバ（番号）情報のうち少なくともいずれか１つを含むことができる。
【０５９３】
具体的な実施例において、放送サービス伝送経路シグナリング情報は、図４６の実施例のように、IP_versioni_flagフィールド、source_IP_address_flagフィールド、destination_IP_address_flagフィールド、source_IP_addressフィールド、port_num_countフィールド、およびdestination_UDP_port_numberフィールドのうち少なくともいずれか１つを含むことができる。
【０５９４】
IP_versioni_flagフィールドは、放送サービスを含むIPデータグラムのIPアドレス形式を示す。具体的には、IP_version_flagフィールドの値が１である場合、IP_version_flagフィールドは、放送サービスを含むIPデータグラムがIPv４形式であることを示し、IP_version_flagフィールドの値が０である場合、IP_version_flagフィールドは、放送サービスを含むIPデータグラムがIPv６形式であることを示すことができる。具体的な実施例において、IP_versioni_flagフィールドは、例えば１ビットフィールドである。
【０５９５】
source_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがソースIPアドレスを含むか否かを示す。具体的には、source_IP_address_flagフィールドの値が１である場合、source_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがソースIPアドレスを含むことを示し、source_IP_address_flagフィールドの値が０である場合、source_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがソースIPアドレスを含まないことを示すことができる。具体的な実施例において、Source_IP_address_flagフィールドは、例えば１ビットフィールドである。
【０５９６】
destination_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがデスティネーションIPアドレスを含むか否かを示す。具体的には、destination _IP_address_flagフィールドの値が１である場合、destination_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがデスティネーションIPアドレスを含むことを示し、destination_IP_address_flagフィールドの値が０である場合、destination_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがデスティネーションIPアドレスを含まないことを示すことができる。具体的な実施例において、destination _IP_address_flagフィールドは、例えば１ビットフィールドである。
【０５９７】
source_IP_addressフィールドは、放送サービスを含むIPデータグラムのソースIPアドレスを示す。具体的な実施例において、Source_IP_addressフィールドは、例えばIPバージョンによって３２ビットまたは１２８ビットフィールドである。
【０５９８】
destination_IP_addressフィールドは、放送サービスを含むIPデータグラムのデスティネーションIPアドレスを示す。具体的な実施例において、destination_IP_addressフィールドは、例えばIPバージョンによって３２ビットまたは１２８ビットフィールドである。
【０５９９】
port_num_countフィールドは、放送サービスを含むIPデータグラムフローのポートの個数を示すことができる。具体的な実施例において、Port_num_countフィールドは、例えば８ビットフィールドである。
【０６００】
destination_UDP_port_numberフィールドは、放送サービスを含むIPデータグラムのUDPポート番号を示す。具体的な実施例において、destination_UDP_port_numberフィールドは、例えば１６ビットフィールドである。
【０６０１】
図４７は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、異なる放送局(broadcaster)のIPストリームを介した放送サービスの伝送をシグナリングすることを示す。
【０６０２】
放送サービスを伝送するネットワークが、放送サービスを異なる放送局が伝送するIPストリームを介して伝送するネットワークである場合、放送サービスを同一の放送局(broadcaster)が伝送するIPストリームを介して伝送するネットワークとは違い、放送サービス伝送経路シグナリング情報は、IPデータグラムを伝送する伝送ストリームを識別する識別子をさらに含むことができる。
【０６０３】
具体的な実施例において、図４７の実施例のように、放送サービス伝送経路シグナリング情報は、transport_stream_idフィールドを含むことができる。
【０６０４】
transport_stream_idフィールドは、放送サービスを含むIPデータグラムを伝送する伝送ストリームを識別する。具体的な実施例において、transport_stream_idフィールドは、例えば１６ビットフィールドである。
【０６０５】
図４８は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、FLUTEセッションを介した放送サービスの伝送をシグナリングすることを示す。
【０６０６】
放送サービスを伝送するネットワークが、放送サービスを同一の放送局のFLUTEセッションを介して伝送するネットワークの場合、放送サービス伝送経路シグナリング情報は、IPバージョンを示す情報、ソース(source)IPアドレスを含むか否かを示す情報、ソースIPアドレス、デスティネーションIPアドレス、UDPポートナンバ情報および放送サービスを含むFLUTEパケットを伝送するFLUTEセッションを識別する伝送セッション識別子(Transport Session Identifier)のうち少なくともいずれか１つを含むことができる。
【０６０７】
具体的な実施例において、放送サービス伝送経路シグナリング情報は、図４８の実施例のように、IP_versioni_flagフィールド、source_IP_address_flagフィールド、source_IP_addressフィールド、destination_UDP_port_numberフィールドおよびflute_tsiフィールドのうち少なくともいずれか１つを含むことができる。
【０６０８】
IP_versioni_flagフィールドは、放送サービスを含むFLUTEパケットを伝送するIPデータグラムのIPアドレス形式を示す。具体的には、IP_version_flagフィールドの値が１である場合、IP_version_flagフィールドは、放送サービスを含むIPデータグラムがIPv４形式であることを示し、IP_version_flagフィールドの値が０である場合、IP_version_flagフィールドは、放送サービスを含むIPデータグラムがIPv６形式であることを示すことができる。具体的な実施例において、IP_versioni_flagフィールドは、例えば１ビットフィールドである。
【０６０９】
source_IP_address_flagフィールドは、放送サービスを含むFLUTEパケットを伝送するIPデータグラムがソースIPアドレスを含むか否かを示す。具体的には、source_IP_address_flagフィールドの値が１である場合、source_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがソースIPアドレスを含むことを示し、source_IP_address_flagフィールドの値が０である場合、source_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがソースIPアドレスを含まないことを示すことができる。具体的な実施例において、Source_IP_address_flagフィールドは、例えば１ビットフィールドである。
【０６１０】
source_IP_addressフィールドは、放送サービスを含むFLUTEパケットを伝送するIPデータグラムのソースIPアドレスを示す。具体的な実施例において、Source_IP_addressフィールドは、例えばIPバージョンによって３２ビットまたは１２８ビットフィールドである。
【０６１１】
destination_IP_addressフィールドは、放送サービス含むFLUTEパケットを伝送するIPデータグラムのデスティネーションIPアドレスを示す。具体的な実施例において、destination_IP_addressフィールドは、例えばIPバージョンによって３２ビットまたは１２８ビットフィールドである。
【０６１２】
destination_UDP_port_numberフィールドは、放送サービスを含むFLUTEパケットを伝送するIPデータグラムのUDPポート番号を示す。具体的な実施例において、destination_UDP_port_numberフィールドは、例えば１６ビットフィールドである。
【０６１３】
flute_tsiフィールドは、放送サービスを含むFLUTEパケットを伝送するFLUTEセッションを識別する伝送セッション識別子(Transport Session Identifier)を示す。
【０６１４】
図４９は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、異なる放送局(broadcaster)のFLUTEプロトコルを介した放送サービスの伝送をシグナリングすることを示す。
【０６１５】
放送サービスを伝送するネットワークが、放送サービスを異なる放送局のFLUTEセッションを介して伝送するネットワークである場合、放送サービスを同一の放送局のFLUTEセッションを介して伝送するネットワークとは違い、放送サービス伝送経路シグナリング情報は、放送サービスを含むFLUTEパケットを伝送する伝送ストリームを識別する識別子をさらに含むことができる。
【０６１６】
具体的な実施例において、図４９の実施例のように、放送サービス伝送経路シグナリング情報は、transport_stream_idフィールドを含むことができる。
【０６１７】
transport_stream_idフィールドは、放送サービスを含むFLUTEパケットを伝送する伝送ストリームを識別する。具体的な実施例において、transport_stream_idフィールドは、例えば１６ビットフィールドである。
【０６１８】
図５０は、本発明の放送サービス伝送経路シグナリング情報が、MPEG-２TSストリームを介した放送サービスの伝送をシグナリングすることを示す。
【０６１９】
放送サービスを伝送するネットワークが、放送サービスを異なる放送局のMPEG-２TSを介して伝送するネットワークである場合、放送サービスを含むMPEG-２TSを伝送する伝送ストリームを識別する識別子および放送サービスを含むMPEG２-TSパケットの識別子を含むことができる。
【０６２０】
具体的な実施例において、図５０のように放送サービス伝送経路シグナリング情報は、transptort_stream_idフィールドおよびpidフィールドのうち少なくともいずれか１つを含むことができる。
【０６２１】
transptort_stream_idフィールドは、MPEG-２TSを伝送する伝送ストリームを識別する識別子を示す。具体的な実施例において、transptort_stream_idフィールドは、例えば１６ビットフィールドである。
【０６２２】
pidフィールドは、放送サービスを含むMPEG２-TSパケットの識別子を示す。具体的な実施例において、Pidフィールドは、例えば１３ビットフィールドである。
【０６２３】
図５１は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、異なる放送局(broadcaster)のパケットベースのストリームを介した放送サービスの伝送をシグナリングすることを示す。
【０６２４】
放送サービスを伝送するネットワークが、放送サービスを異なる放送局のパケットベースのストリームを介して伝送するネットワークである場合、放送サービス伝送経路シグナリング情報は、放送サービスを含むパケットベースのストリームを識別する識別子および放送サービスを含むパケットの識別子を含むことができる。
【０６２５】
具体的な実施例において、図５１のように放送サービス伝送経路シグナリング情報は、transptort_stream_idフィールドおよびpacket_idフィールドのうち少なくともいずれか１つを含むことができる。
【０６２６】
transport_stream_idフィールドは、放送サービスを含むパケットベースのストリームを識別する識別子を示す。具体的な実施例において、transptort_stream_idフィールドは、例えば１６ビットフィールドである。
【０６２７】
packet_idフィールドは、放送サービスを含むパケットの識別子を示す。具体的な実施例において、Packet_idフィールドは、例えば１６ビットフィールドである。
【０６２８】
図５２は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、IPベースの放送ネットワークで伝送されるパケットベースのストリームを介した放送サービスの伝送をシグナリングすることを示す。
【０６２９】
放送サービスを伝送するネットワークが、放送サービスをIPベースの放送ネットワークで伝送されるパケットベースのストリームを介して伝送するネットワークである場合、放送サービス伝送経路シグナリング情報は、IPバージョンを示す情報、ソース(source)IPアドレスを含むか否かを示す情報、ソースIPアドレス、デスティネーションIPアドレス、UDPポートナンバ情報および放送サービスを含むパケットを識別する識別子のうち少なくともいずれか１つを含むことができる。
【０６３０】
具体的な実施例において、放送サービス伝送経路シグナリング情報は、図５２の実施例のように、IP_versioni_flagフィールド、source_IP_address_flagフィールド、source_IP_addressフィールド、destination_UDP_port_numberフィールドおよびpacket_idフィールドのうち少なくともいずれか１つを含むことができる。
【０６３１】
IP_versioni_flagフィールドは、放送サービスを含むパケットを伝送するIPデータグラムのIPアドレス形式を示す。具体的には、IP_version_flagフィールドの値が１である場合、IP_version_flagフィールドは、放送サービスを含むIPデータグラムがIPv４形式であることを示し、IP_version_flagフィールドの値が０である場合、IP_version_flagフィールドは、放送サービスを含むIPデータグラムがIPv６形式であることを示すことができる。具体的な実施例において、IP_versioni_flagフィールドは、例えば１ビットフィールドである。
【０６３２】
source_IP_address_flagフィールドは、放送サービスを含むパケットを伝送するIPデータグラムが、ソースIPアドレスを含むか否かを示す。具体的には、source_IP_address_flagフィールドの値が１である場合、source_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがソースIPアドレスを含むことを示し、source_IP_address_flagフィールドの値が０である場合、source_IP_address_flagフィールドは、放送サービスを含むIPデータグラムがソースIPアドレスを含まないことを示すことができる。具体的な実施例において、Source_IP_address_flagフィールドは、例えば１ビットフィールドである。
【０６３３】
source_IP_addressフィールドは、放送サービスを含むパケットを伝送するIPデータグラムのソースIPアドレスを示す。具体的な実施例において、Source_IP_addressフィールドは、例えばIPバージョンによって３２ビットまたは１２８ビットフィールドである。
【０６３４】
destination_IP_addressフィールドは、放送サービスを含むパケットを伝送するIPデータグラムのデスティネーションIPアドレスを示す。具体的な実施例において、destination_IP_addressフィールドは、例えばIPバージョンによって３２ビットまたは１２８ビットフィールドである。
【０６３５】
destination_UDP_port_numberフィールドは、放送サービスを含むパケットを伝送するIPデータグラムのUDPポート番号を示す。具体的な実施例において、destination_UDP_port_numberフィールドは、例えば１６ビットフィールドである。
【０６３６】
packet_idフィールドは、放送サービスを含むパケットを識別する識別子を示す。具体的な実施例において、Packet_idフィールドは１６ビットフィールドを示すことができる。
【０６３７】
図５３は、本発明の一実施例に係る放送サービス伝送経路シグナリング情報が、URLを介して放送サービスをシグナリングすることを示す。
【０６３８】
放送サービスを伝送するネットワークがURLを介して放送サービスを獲得できるネットワークである場合、放送サービス伝送経路シグナリング情報は、放送サービスを受信できるURLの長さを示す情報および放送サービスを受信できるURLのうち少なくともいずれか１つを含むことができる。
【０６３９】
具体的な実施例において、図５３のように、放送サービス伝送経路シグナリング情報は、URL_lenthフィールドおよびURI_charフィールドのうち少なくともいずれか１つを含むことができる。
【０６４０】
URL_lenghフィールドは、放送サービスを受信できるURLの長さを示す。具体的な実施例において、URL_lengthフィールドは、例えば８ビットフィールドである。
【０６４１】
URL_charフィールドは、放送サービスを受信できるURLを示す。具体的な実施例において、URL_charフィールドは、例えば８ビットフィールドである。
【０６４２】
図５４は、本発明の一実施例に係る放送伝送装置が放送サービス伝送経路シグナリング情報を伝送することを示す。
【０６４３】
放送伝送装置は、制御部を介して放送サービスの伝送経路を獲得する(S５０１)。
【０６４４】
放送伝送装置は、制御部を介して放送サービス伝送経路シグナリング情報を生成する(S５０３)。放送伝送装置は、図４３〜図５２を参照して説明した放送サービス伝送経路シグナリング情報を生成することができる。
【０６４５】
放送伝送装置は、伝送部を介して放送サービス伝送経路シグナリング情報を含む放送信号を伝送する(S５０５)。
【０６４６】
図５５は、本発明の一実施例に係る放送伝送装置が放送サービス伝送経路シグナリング情報を伝送することを示す。
【０６４７】
放送受信装置１００は、放送受信部１１０を介して放送信号を受信する(S７０１)。
【０６４８】
放送受信装置１００は、制御部１５０を介して放送信号に基づいて放送サービス伝送経路シグナリング情報を獲得する(S７０３)。
【０６４９】
放送受信装置１００は、制御部１５０を介して放送サービス伝送経路シグナリング情報に基づいて放送サービスを受信する(S７０５)。具体的には、放送受信装置１００は、制御部１５０を介して放送サービス伝送経路シグナリング情報に基づいて放送サービスのメディアコンポーネントを受信することができる。図４５〜図５４を参照して上述したように、放送受信装置１００は、放送サービスが同一の放送局(broadcaster)が伝送するIPストリームを介して伝送するネットワーク、放送サービスが異なる放送局が伝送するIPストリームを介して伝送するネットワーク、放送サービスが同一の放送局のFLUTEセッションを介して伝送するネットワーク、放送サービスが異なる放送局のFLUTEセッションを介して伝送するネットワーク、放送サービスが異なる放送局のMPEG-２TSを介して伝送するネットワーク、放送サービスが異なる放送局のパケットベースのストリームを介して伝送するネットワーク、放送サービスがIPベースの放送ネットワークで伝送されるパケットベースのストリームを介して伝送するネットワークおよびURLを介して放送サービスを獲得できるネットワークのうち少なくともいずれか１つを介して放送サービスを受信することができる。特に、具体的な実施例において、放送受信装置１００は、放送サービスの複数のメディアコンポーネントを複数のネットワークを介して受信することができる。例えば、放送受信装置１００は、放送受信部１１０を介して放送サービスのビデオコンポーネントは、パケットベースのストリームを介して受信し、IP通信部１３０を介して放送サービスのオーディオコンポーネントは、IPベースの放送ネットワークを介して受信することができる。
【０６５０】
上述したように、放送サービスシグナリングテーブルは、メディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報を含むことができる。特に、ISOベースのメディアファイルフォーマット(ISO Base Media File Format、ISO BMFF)形態で放送サービスを伝送する場合、メディアコンポーネントシグナリング情報を含むことができる。これに関しては、図５６〜図５９を参照して具体的に説明する。
【０６５１】
図５６は、本発明の一実施例に係るメディアコンポーネントをシグナリングするメディアコンポーネントシグナリング情報を示す。
【０６５２】
メディアコンポーネントシグナリング情報は、メディアコンポーネントのエンコーディングの種類を示す情報、メディアコンポーネントの暗号化(encryption)の有無を示す情報、暗号化されたメディアコンポーネントを解読(decrypt)できるキー(key)を含むSTKMストリームの個数を示す情報、暗号化されたメディアコンポーネントを解読できるキーを含むSTKMストリームを識別する識別子、メディアコンポーネントの伝送パラメータの長さ、メディアコンポーネントの伝送パラメータおよびコンポーネントのエンコーディングの種類に応じたエンコーディングパラメータを含むことができる。このとき、伝送パラメータは、バッファモデルおよび最大伝送単位(Maximum Transmission Unit、MTU)の大きさのうち少なくともいずれか１つを含むことができる。
【０６５３】
具体的な実施例において、メディアコンポーネントシグナリング情報は、図５６の実施例のように、descriptor_tagフィールド、descriptor_lengthフィールド、component_typeフィールド、component_encryption_flagフィールド、num_STKM_streamsフィールド、STKM_stream_idフィールド、transport_parameter_text_lengthフィールド、transport_parameter_textフィールドおよびcomponent_dataフィールドのうち少なくともいずれか１つを含むことができる。
【０６５４】
descriptor_tagフィールドは、該当descriptorがメディアコンポーネントシグナリング情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０６５５】
descriptor_lengthフィールドは、該当フィールド以後の放送サービス伝送経路シグナリング情報の長さを示す。具体的な実施例において、descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０６５６】
component_typeフィールドは、該当コンポーネントのエンコーディングの種類を示す。具体的な実施例において、図５７の実施例のように、component_typeフィールドが持つ値は、H.２６４/AVC、SVC enhancement層ストリームコンポーネント、HE AAC v２オーディオストリームコンポーネント、FLUTEファイル伝送セッション、STKMストリームコンポーネント、LTKMストリームコンポーネント、OMA-RME DIMSストリームコンポーネント、NTPタイムベースストリームコンポーネントのうちいずれか１つを示すことができる。メディアコンポーネントがISO BMFFを介して伝送される場合、放送受信装置１００は、メディアコンポーネントを受信するための適切な動作を準備しなければならない。従って、メディアコンポーネントがISO BMFFを介して伝送されることをシグナリングする必要がある。具体的には、図５７の実施例のように、component_typeフィールドは、放送サービスのメディアコンポーネントがISO BMFFで伝送されることを示すことができる。具体的には、component_typeフィールドが持つ値が３５である場合、component_typeフィールドは、メディアコンポーネントがH.２６４/AVCコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が３６である場合、component_typeフィールドは、メディアコンポーネントがSVC enhancement層ストリームコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が３７である場合、component_typeフィールドは、メディアコンポーネントがHE AAC v２オーディオストリームコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が３８である場合、component_typeフィールドは、メディアコンポーネントが、FLUTEファイル伝送セッションによって伝送されるメディアコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が３９である場合、component_typeフィールドは、メディアコンポーネントが、STKMストリームコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が４０である場合、component_typeフィールドは、メディアコンポーネントがLTKMストリームコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が４１である場合、component_typeフィールドは、メディアコンポーネントがOMA-RME DIMSストリームコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が４２である場合、component_typeフィールドは、メディアコンポーネントがNTPタイムベースストリームコンポーネントであることを示すことができる。具体的には、component_typeフィールドが持つ値が４３である場合、component_typeフィールドは、メディアコンポーネントがISO BMFFで伝送されることを示すことができる。具体的な実施例において、component_typeフィールドは、例えば７ビットフィールドである。
【０６５７】
component_encryption_flagフィールドは、メディアコンポーネントが暗号化されたか否かを示すフィールドである。具体的な実施例において、component_encryption_flagフィールドは、例えば１ビットフィールドである。
【０６５８】
num_STKM_streamsフィールドは、暗号化されたメディアコンポーネントを解読(decrypt)できるキー(key)を含むSTKMストリームの個数を示す。具体的な実施例において、num_STKM_streamsフィールドは、例えば８ビットフィールドである。
【０６５９】
STKM_stream_idフィールドは、暗号化されたメディアコンポーネントを解読(decrypt)できるキー(key)を含むSTKMストリームを識別する識別子を示す。具体的な実施例において、STKM_stream_idフィールドは、例えば８ビットフィールドである。
【０６６０】
transport_parameter_text_lengthフィールドは、transport_parameter_textフィールドの長さを示す。具体的な実施例において、transport_parameter_text_lengthフィールドは、例えば８ビットフィールドである。
【０６６１】
transport_parameter_textフィールドは、メディアコンポーネントの伝送パラメータを示す。このとき、伝送パラメータは、バッファモデルおよび最大伝送単位（最大転送単位）(Maximum Transmission Unit、MTU)の大きさのうち少なくともいずれか１つを含むことができる。
【０６６２】
component_dataフィールドは、コンポーネントのエンコーディングパラメータを示す。エンコーディングパラメータが含むパラメータは、コンポーネントのエンコーディングの種類によって変わる（vary）。具体的には、エンコーディングパラメータが含むパラメータは、component_typeフィールドの値によって変わる。
【０６６３】
メディアコンポーネントがISO BMFFを介して伝送される場合、component_dataフィールドは、ISO BMFFのバージョン情報およびプロファイル情報のうち少なくともいずれか１つを含むことができる。
【０６６４】
具体的には、図５９の実施例のように、versionフィールドおよびprofileフィールドのうち少なくともいずれか１つを含むことができる。
【０６６５】
versionフィールドは、ISO BMFFのバージョン情報を示す。具体的な実施例において、versionフィールドは、例えば８ビットフィールドである。
【０６６６】
profileフィールドは、ISO BMFFのプロファイル情報を示す。具体的な実施例において、Profileフィールドは、例えば８ビットフィールドである。
【０６６７】
前述したメディアコンポーネントは、その内容に関係なく全て同一に扱われてシグナリングされた。ただし、最近、通信環境に応じて異なる品質のメディアコンポーネントを伝送する適応型ストリーミングサービスが脚光を浴びている。これによって、ユーザは、通信環境に応じて、同一のコンテンツを含む多様な品質のメディアコンポーネントのうちいずれか１つを選択して視聴できるようになった。また、１つの画面で複数のメディアコンポーネントを同時に表示するマルチビュー(multi view)サービスが提供されている。これによって、ユーザは、複数の映像またはデータ放送を１つの画面で視聴できるようになった。例えば、ユーザは野球の試合を見ながら他の球場の試合を追加のPIP(Picture In Picture)画面を介して視聴することができる。このように複数のメディアコンポーネントを含む放送サービスが多様化され、増加するのに伴い、放送伝送装置および放送受信装置１００は、コンポーネントの種類を細分化して処理し、各メディアコンポーネント間の関係を体系的に定義する必要がある。これに対しては、図５９〜図１１０を参照して説明する。
【０６６８】
図５９は、本発明の一実施例に係るメディアコンポーネントの種類および役割を示す。
【０６６９】
メディアコンポーネントは、コンテンツコンポーネント、シンプルオーディオコンポーネント、シンプルビデオコンポーネント、連続(continuous)コンポーネント、基礎(elementary)コンポーネント、コンポジット(composite)コンポーネント、コンポジットオーディオコンポーネント、コンポジットビデオコンポーネント、適応型(adaptive)コンポーネント、適応型オーディオコンポーネント、適応型ビデオコンポーネントおよびコンプレックスコンポーネントに分けることができる。適応型コンポーネントはPickOneコンポーネントで表現することができる。
【０６７０】
コンテンツコンポーネントは、一種類のメディアとメディアに関連したメタデータとを含むコンポーネントである。具体的には、コンテンツコンポーネントは、ビデオトラック、オーディオトラック、字幕、ビデオenhanced layer、ウェブページ、双方向アプリケーションのうちいずれか１つを含むことができる。
【０６７１】
シンプルオーディオコンポーネントは、オーディオを含むコンポーネントである。具体的には、シンプルオーディオコンポーネントは、特定のエンコーディングパラメータによってエンコーディングされた１つの音声シーケンスのエンコーディングである。
【０６７２】
シンプルビデオコンポーネントは、ビデオを含むコンポーネントである。具体的には、シンプルビデオコンポーネントは、特定のエンコーディングパラメータによってエンコーディングされた１つの映像シーケンスのエンコーディングである。
【０６７３】
連続(continuous)コンポーネントは、連続したストリーム上で再生されるコンポーネントである。
【０６７４】
基礎(elementary)コンポーネントは、１つのエンコーディングのみを含む連続コンポーネントである。基礎コンポーネントは、オーディオコンポーネントを含むことができる。具体的には、基礎コンポーネントは、音声シーケンスに対する１つのエンコーディングである。また、基礎コンポーネントは、ビデオコンポーネントを含むことができる。具体的には、映像シーケンスに対する１つのエンコーディングである。基礎コンポーネントは、１つの字幕トラックからなることができる。
【０６７５】
コンポジット(composite)コンポーネントは、１つの場面(scene)を再生するために必要な複数の連続コンポーネントのセットである。具体的には、コンポジット(composite)コンポーネントは、同一のメディア形態(type)を有し、同じ場面(scene)を示し、再生のためには一定の組合せで一緒に再生しなければならない連続コンポーネントのセットである。従って、コンポジットコンポーネントは、複数のメディアコンポーネントが組み合わ(combine)されて１つの場面を示す複数のメディアコンポーネントのセットである。具体的には、コンポジットコンポーネントは、１つの完全なオーディオのために必要な音楽、対話（dialog）および特殊効果を含むことができる。また、コンポジットコンポーネントは、３Ｄ映像を再生するために必要な３Ｄ映像の右側映像と３Ｄ映像の左側映像とを含むことができる。
【０６７６】
コンポジットオーディオコンポーネントは、音声シーケンスを再生するために必要なオーディオコンポーネントのセットである。具体的には、コンポジットオーディオコンポーネントは、ミックスされるオーディオコンポーネントのセットを含むことができる。
【０６７７】
コンポジットビデオコンポーネントは、映像シーケンスを再生するために必要なビデオコンポーネントのセットである。具体的には、コンポジットビデオコンポーネントは、３Ｄビデオ再生のために組み合わせる３Ｄコンポーネントのセットを含むことができる。また、コンポジットビデオコンポーネントは、１つまたは複数のenhancedエンコーディングを伴うベースビデオエンコーディングである。
【０６７８】
適応型(adaptive)コンポーネントは、いずれか１つの場面を示す相互に代替可能な複数の連続コンポーネントのセットである。上述したように適応型コンポーネントは、PickOneと称することができ、これは多様な代替可能な複数の連続コンポーネントのうちいずれか１つを選択して再生する可能性があることを示す。具体的には、適応型コンポーネントは、同一のメディア形態(type)であり、同じ場面(scene)を示し、再生のためにいずれか１つが選択される複数の連続コンポーネントのセットである。具体的には、適応型コンポーネントは同一のコンテンツを相互に異なる品質でエンコーディングした複数のメディアコンポーネントのセットを含むことができる。例えば、適応型コンポーネントは、同一の音声シーケンスを異なるビットレート(bitrate)でエンコーディングしたオーディオコンポーネントのセットを含むことができる。また、適応型コンポーネントは、同一の映像シーケンスを異なるビットレートでエンコーディングしたビデオコンポーネントのセットを含むことができる。また、適応型コンポーネントは、同一の対話に対する一般的な（通常の）字幕トラックおよび大きな文字の（読みやすい）(easy reader)字幕を含むことができる。
【０６７９】
適応型オーディオコンポーネントは、音声シーケンスを再生するためにいずれか１つが選択されるオーディオコンポーネントのセットである。具体的には、適応型オーディオコンポーネントは、同一のサウンドシーケンスを相互に異なるビットレートでエンコーディングしたオーディオコンポーネントのセットを含むことができる。
【０６８０】
適応型ビデオコンポーネントは、映像シーケンスを再生するためにいずれか１つが選択されるビデオコンポーネントのセットである。具体的には、適応型ビデオコンポーネントは、同一のビデオシーケンスを相互に異なるエンコーディングパラメータでエンコーディングしたビデオコンポーネントのセットを含むことができる。
【０６８１】
コンプレックスコンポーネントは、コンポジットコンポーネントまたは適応型コンポーネントのうちいずれか１つを示す。コンプレックスコンポーネントに対しては、図６０〜図６２を参照して具体的に説明する。
【０６８２】
図６０は、本発明の一実施例に係るコンプレックスコンポーネントの構成を示す。
【０６８３】
コンプレックスコンポーネントが基礎コンポーネントのみを含む必要はない。具体的な実施例において、コンプレックスコンポーネントは、コンプレックスコンポーネントを含むことができる。従って、コンプレックスコンポーネントが含む１つの基礎コンポーネントのみでは、放送サービスの再生が不可能な場合もある。また、コンプレックスコンポーネントは、コンポジットコンポーネントまたは適応型コンポーネントを含むことができる。具体的には、図６０の実施例のように、コンポジットコンポーネントは、１つまたは複数の基礎コンポーネントを含むことができる。また、コンポジットコンポーネントは、１つまたは複数のコンプレックスコンポーネントを含むことができる。また、コンポジットコンポーネントは基礎コンポーネントおよびコンプレックスコンポーネントを両方とも含むことができる。１つの適応型コンポーネントは、１つまたは複数の基礎コンポーネントを含むことができる。
【０６８４】
放送サービスのコンポーネントをトップレベル(top-level)コンポーネントという用語を使用して説明することができる。トップレベルオーディオコンポーネントは、固有な（一意の）（unique）音声シーケンスを示す。トップレベルビデオコンポーネントは、固有な映像シーケンスを示す。具体的な実施例において、このようなトップレベルコンポーネントは、基礎コンポーネントを含むことができる。また、他の具体的な実施例において、トップレベルコンポーネントは、コンポジットコンポーネントを含むことができる。
【０６８５】
例えば、図６１の実施例のように、トップレベルビデオコンポーネントは、３Ｄ映像の左側映像であるコンポーネントと右側映像であるコンポーネントとを含むコンポジットコンポーネントを含むことができる。このとき、３Ｄ映像の左側映像コンポーネントは相互に異なるビットレートでエンコーディングされた複数の基礎コンポーネントを含む適応型コンポーネントを含むことができる。また、３Ｄ映像の右側映像コンポーネントも相互に異なるビットレートでエンコーディングされた複数の基礎コンポーネントを含む適応型コンポーネントを含むことができる。
【０６８６】
また、他の具体的な実施例において、図６２の実施例のように、トップレベルオーディオコンポーネントは、完全なメインオーディオを含む適応型コンポーネントと、音楽、対話および効果トラックがミックスされたコンポジットコンポーネントと、を含む適応型コンポーネントを含むことができる（the top-level audio component may be an adaptive component including an adaptive component including a complete main audio and a composite component having mixed music, dialogs, and special effects）。このとき、完全なメインオーディオを含む適応型コンポーネントは、相互に異なるビットレートでエンコーディングされた複数の基礎コンポーネントを含むことができる。また、音楽、対話および効果トラックがミックスされたコンポジットコンポーネントは、音楽を含む適応型コンポーネント、対話を含む適応型コンポーネントおよび効果音を含む適応型コンポーネントを含むことができる。また、音楽を含む適応型コンポーネントは、相互に異なるビットレートでエンコーディングされた複数の基礎コンポーネントを含むことができる。
【０６８７】
このようにメディアコンポーネントを区別することによって、複数のメディアコンポーネントの関係を単純化することができる。例えば、それぞれのビデオプログラムが１つのコンプレックスビデオコンポーネントを含むと特定すれば、それぞれのオーディオ基礎コンポーネントまたはビデオ基礎コンポーネントとの関係を特定する必要がない。
【０６８８】
１つのメディアに対する複数のコンプレックスコンポーネントモデルが存在し得る。例えば、複数のビットレートでエンコーディングされた３Ｄコンポーネントは、左側映像に対するサブメディアコンポーネントと右側映像に対するサブメディアコンポーネントを含むコンポジットコンポーネントでモデル化され、それぞれのサブメディアコンポーネントは相互に異なるビットレートでエンコーディングされた複数のコンポーネントを含む適応型コンポーネントでモデル化される。または同じ３Ｄコンポーネントが相互に異なるビットレートでエンコーディングされた複数のサブメディアコンポーネントを含む適応型コンポーネントでモデル化され、それぞれのサブメディアコンポーネントは、左側映像および右側映像を含むコンポジットコンポーネントでモデル化される。左側映像および右側映像が含む相互に異なるビットレートを有する複数のサブメディアコンポーネントの個数は異なる。
【０６８９】
図６３は、本発明の一実施例に係るコンプレックスビデオコンポーネントの構成を示す。
【０６９０】
図６３の実施例は、図５９の実施例おける具体的な表現を修正したものとして、図３１の実施例と同様に適用することができる。特に、連続コンポーネント、基礎コンポーネント、コムポジットコンポーネントおよびコンプレックスコンポーネントに関する定義と役割は同一である。図５９の適応型コンポーネントに関しては、適応型コンポーネントの代わりに上述したようにPickOneコンポーネントとして表現する。図６３の実施例におけるPickOneコンポーネントの定義および役割は、図５９の実施例における適応型コンポーネントの定義および役割と同一である。従って、コンポジットコンポーネントは、複数の連続コンポーネントを組み合わせて１つのコンテンツを再生することを示す。また、PickOneコンポーネントは、複数の選択可能なメディアコンポーネントのうちいずれか１つを選択して再生すべきコンポーネントを示す。ただし、図６３の実施例では、図５９の実施例とは違い、presentable（再生可能）コンポーネントを定義する。presentableコンポーネントは、放送受信装置１００で実質的に（実質上）（substantially）再生する連続コンポーネントを示す。具体的には、presentableコンポーネントは、基礎コンポーネントを含むことができる。また、presentableコンポーネントは、コンプレックスコンポーネントを含むことができる。具体的な実施例において、メディアコンポーネントは、それ自体がpresentableコンポーネントでありながら、コンプレックスコンポーネントの下位メディアコンポーネントとしてコンプレックスコンポーネントに含まれてもよい。例えば、サービスは基礎２Ｄビデオコンポーネントおよびコンプレックス３Ｄコンポーネントを含むことができる。このとき、２Ｄビデオコンポーネントは、３Ｄビデオコンポーネントがなくとも２Ｄ映像で再生可能なpresentableコンポーネントである。また、２Ｄビデオコンポーネントは、３Ｄ映像の１つのビュー(view)として、他の３Ｄビデオコンポーネントと一緒に３Ｄ映像で再生可能である。
【０６９１】
また、他の具体的な実施例において、Presentableオーディオコンポーネントは、メインコンポーネントと音楽、対話および音響効果などを含むPickOneコンポーネントとを含むことができる。このとき、メインコンポーネントおよび音楽コンポーネントは、相互に異なるビット率(bitrate)でエンコーディングされた複数の基礎コンポーネントを含むPickOneコンポーネントを含むことができる。また、対話および音響効果などを示すメディアコンポーネントは、基礎コンポーネントを含むことができる。
【０６９２】
図６４は、本発明の一実施例に係るコンプレックスビデオコンポーネントの構成を示す。
【０６９３】
presentableコンポーネントは、コンポジットコンポーネントを含むことができる。図６４の実施例のように、スケーラブル（可変的）(scalable)ビデオエンコーディングは、コンポジットコンポーネントとして複数のメディアコンポーネントを含むことができる。スケーラブルビデオエンコーディングは、基礎コンポーネントであるベース層(layer)コンポーネント、第１エンハンスメント層コンポーネントおよび第２エンハンスメント層コンポーネントを含むことができる。このとき、ベース層コンポーネントは、第１エンハンスメント層コンポーネントおよび第２エンハンスメント層コンポーネントがなくとも再生可能なpresentableコンポーネントである。また、ベース層コンポーネントは、第１エンハンスメント層コンポーネントおよび第２エンハンスメント層コンポーネントのうち少なくともいずれか１つと一緒に高い品質の映像で再生される。このとき、第１エンハンスメント層コンポーネントおよび第２エンハンスメント層コンポーネントは、ベース層コンポーネントがなくては再生が不可能なメディアコンポーネントであり、ベース層コンポーネントと一緒に再生する目的を有するので、presentableコンポーネントであるといえない。このとき、放送受信装置１００は、放送受信装置１００の仕様に基づいてベース層コンポーネントと第１エンハンスメントコンポーネントおよび第２エンハンスメントとを組み合わせて映像を再生することができる。具体的には、放送受信装置１００の仕様が低い場合、放送受信装置１００は、ベース層コンポーネントを利用して、比較的低い品質の映像を再生することができる。または、放送受信装置１００の仕様が比較的高い場合、放送受信装置１００は、ベース層コンポーネントと第１エンハンスメント層コンポーネントとを組み合わせて、比較的高い品質の映像を再生することができる。または、放送受信装置１００の仕様が非常に高い場合、放送受信装置１００は、ベース層コンポーネントと第１エンハンスメント層コンポーネントおよび第２エンハンスメント層コンポーネントとを組み合わせて、非常に高い品質の映像を再生することができる。
【０６９４】
図６５は、本発明の他の実施例に係るコンプレックスビデオコンポーネントを示す。
【０６９５】
presentableコンポーネントは、PickOneコンポーネントを含むことができる。図６５の実施例のように、PickOneビデオコンポーネントは、２Ｄエンコーディングとサイドバイサイド(side-by-side)形態の３Ｄエンコーディングとを含むことができる。このとき、３Ｄエンコーディングは左側映像(left view)と右側映像(right view)とに分けられ、左側映像および右側映像は一般的な映像幅の半分であり、左側映像と右側映像とがサイドバイサイド形態で併置されて１つの画面(picture)を生成するようにエンコーディングされたものを含むことができる。放送受信装置１００は、放送受信装置１００の仕様によって２Ｄエンコーディングおよび３Ｄエンコーディングのうちいずれか１つを選択して再生することができる。具体的には、放送受信装置１００が３Ｄ映像の再生をサポートしない場合、放送受信装置１００は２Ｄエンコーディングを選択して再生することができる。また、放送受信装置１００が３Ｄ映像の再生をサポートする場合、放送受信装置１００は３Ｄエンコーディングを選択して再生することができる。
【０６９６】
このようにそれぞれのサービスは、サービスが含むpresentableコンポーネントを介して説明(describe)することができる。また、presentableコンポーネントがコンプレックスコンポーネントである場合、コンプレックスコンポーネントが含むコンポーネントを介して説明(describe)することができる。具体的な実施例において、それぞれのpresentableオーディオコンポーネントは特定場面の音声を示すことができ、それぞれのpresentableビデオコンポーネントは、特定時点(angle)で撮影した特定場面の画面(picture)を示すことができる。簡単な組み合わせの場合、presentableコンポーネントは基礎コンポーネントを含むことができる。前述したように、それぞれのpresentableコンポーネントは、コンプレックスコンポーネントを含むことができる。これに関しては、図６６を参照して説明する。
【０６９７】
図６６は、本発明の他の実施例に係るコンプレックスビデオコンポーネントを示す。
【０６９８】
presentableコンポーネントは、コンポジットコンポーネントであり、コンポジットコンポーネントが含むコンポーネントは、PickOneコンポーネントを含むことができる。図６６の実施例において、presentableビデオコンポーネントは、３Ｄ映像の左側映像であるビデオコンポーネントと右側映像であるビデオコンポーネントとを含む。左側映像であるビデオコンポーネントと右側映像であるビデオコンポーネントとは、PickOneコンポーネントである。従って、左側映像であるビデオコンポーネントと右側映像であるビデオコンポーネントとは、相互に異なる比率でエンコーディングされた複数の基礎コンポーネントを含む。
【０６９９】
このように、図６３の実施例のようにメディアコンポーネントの種類と役割を定義する場合、サービスが含むメディアコンポーネントの関係および構造を効率的かつ簡単に説明することができる。従って、放送伝送装置は、これを利用して効率的かつ簡単にサービスをシグナリングでき、放送受信装置１００は、これを利用して効率的かつ簡単にサービスをシグナリングする情報を獲得することができる。
【０７００】
図６７〜図７０を参照して、多様な放送サービスモデルの形態を説明する。
【０７０１】
図６７は、本発明の一実施例に係るオーディオサービスのメディアコンポーネントの構成を示す。
【０７０２】
オーディオサービスは、１つまたは複数のオーディオコンポーネントを含むことができる。また、オーディオサービスは字幕コンポーネントを含むことができる。また、オーディオコンポーネントは付加サービスデータ(Adjunct data service)を含むことができる。このとき、付加サービスは非リアルタイムサービス(Non-Real-Time service、NRT service)を含むことができる。また、具体的な実施例において、オーディオサービスは、決まった日程(schedule)に応じて連続したストリームを介して伝送される。具体的な実施例において、オーディオサービスはラジオサービスと称することができる。
【０７０３】
図６８は、本発明の一実施例に係るオーディオおよびビデオを両方とも含む放送サービスの構成を示す。
【０７０４】
オーディオおよびビデオを両方とも含む放送サービスは、１つまたは複数の主ビデオコンポーネントを含むことができる。このとき、オーディオおよびビデオを両方とも含む放送サービスは、補助ビデオコンポーネントをさらに含むことができる。このとき、オーディオおよびビデオを両方とも含む放送サービスは、オーディオコンポーネントを含むことができる。また、オーディオおよびビデオを両方とも含む放送サービスは、字幕コンポーネントを含むことができる。また、オーディオおよびビデオを両方とも含む放送サービスは、付加サービスデータコンポーネントを含むことができる。具体的な実施例において、オーディオおよびビデオを両方とも含むサービスはTVサービスと称することができる。
【０７０５】
図６９は、本発明の一実施例に係るユーザ要求（リクエスト）コンテンツサービスの構成を示す。
【０７０６】
ユーザ要求コンテンツ(Contents On Demand（オンデマンドコンテンツ）、CoD)サービスは、ユーザインターフェースを提供するアプリケーションを含むことができる。また、ユーザ要求コンテンツサービスは、ユーザの要求により提供されるコンテンツアイテムを含むことができる。また、ユーザ要求コンテンツサービスは、コンテンツアイテムのカタログを含むことができる。このとき、カタログはアプリケーションに内蔵される。
【０７０７】
図７０は、本発明の一実施例に係るスタンドアローンNRTデータサービスの構成を示す。
【０７０８】
スタンドアローン(standalone)NRTデータサービスは、サービスを構成する１つまたは複数のコンテンツアイテムを含むことができる。具体的な実施例において、スタンドアローンNRTデータサービスは、アプリ(App)サービスと称することができる。
【０７０９】
複数の放送サービスは、メディアコンポーネントを共有することができる。具体的には、前述したオーディオサービス、オーディオおよびビデオを両方とも含む放送サービス並びにスタンドアローンNRTデータサービスが含むそれぞれのメディアコンポーネントは、１つまたは複数の他のコンポーネントと関連する。このとき、１つまたは複数の他のコンポーネントは、同じベースコンテンツを表す他の方式によってエンコーディングされたサービスに含まれてもよい。
【０７１０】
また、放送サービスは、サービス識別子、サービス形態、サービスに関する説明、サービスの名前、チャンネル番号、グラフィックアイコン、サービスに含まれたメディアコンポーネントのリスト、放送サービスの保護(protection)に関する属性、ターゲティング(targeting)/個人化(personalization)に関する属性、視聴推奨等級（コンテンツ推奨等級）(contents advisory rating)、サービスの言語、サービスに関連した付加NRTデータサービスのリスト（目録）(list)および放送サービスユーザ報告に関する属性のうち少なくともいずれか１つを属性として含むことができる。このとき、サービスの名前は複数の言語で表示することができる。また、グラフィックアイコンは、サービスを示すために使用される。また、サービスの言語は、サービスに使用される主(primary)言語を示すことができる。また、サービス形態は、予定された日程に応じて伝送されるスケジュールされた(scheduled)オーディオサービス、予定された日程に応じて伝送されるスケジュールされたオーディオおよびビデオを含むサービス、ユーザの要求により伝送されるユーザ要求サービスおよびスクリプト(scripted)NRTデータサービスのうち少なくともいずれか１つを含むことができる。また、チャンネル番号は、具体的には、主（メジャー）チャンネル番号および副（マイナ）チャンネル番号を含むことができる。また、チャンネル番号は、バーチャルチャンネル番号で表示することができる。また、複数の放送サービスは、同じグラフィックアイコンを用いることができる。また、サービス識別子は、放送サービスが放送される放送地域で固有（一意の）値を有することができる。また、サービス識別子は、ローカル(local)識別子およびリージョナル(regional)識別子である、２つのカテゴリの識別子が使用される。ローカル識別子は１つの放送領域(area)のみで放送されるサービスに使用される。従って、相互に異なる複数の放送領域で放送される複数の放送サービスは、同じローカル識別子を有することができる。リージョナル識別子は、複数の放送領域(area)で同じ放送サービスが使用可能な場合、放送サービスの識別のために使用される。
【０７１１】
このような放送サービスの属性をシグナリングするために、前述した放送サービスシグナリングテーブルが使用される。
【０７１２】
それぞれの連続コンポーネントは複数の属性を有することができる。このとき、複数の属性は複数の種類に分けることができる。具体的な実施例において、連続(continuous)コンポーネントが有する複数の属性を基本(Basic)連続コンポーネント属性、基礎(Elementary)コンポーネント属性、コンプレックスコンポーネント属性およびpresentableコンポーネント属性に分けることができる。
【０７１３】
基本(Basic)連続コンポーネント属性は、すべての連続コンポーネントに適用される。基本連続コンポーネント属性は、一意のコンテンツ識別子、コンテンツ構造およびコンテンツの種類のうち少なくともいずれか１つを含むことができる。このとき、コンテンツ構造は、基本、コンポジットおよびPickOneのいずれか１つを示すことができる。また、コンテンツの種類は、オーディオ、ビデオおよび字幕のうちいずれか１つを示すことができる。
【０７１４】
基礎(Elementary)コンポーネント属性は基礎コンポーネントに適用される。基礎コンポーネント属性は、コンポーネントエンコーディングの基本的特徴を含むことができる。例えば、基礎コンポーネント属性はビデオ解像度を含むことができる。また、基礎コンポーネント属性はオーディオのチャンネル数を含むことができる。
【０７１５】
コンプレックスコンポーネント属性はコンプレックスコンポーネントに適用される。コンプレックスコンポーネントの属性は、コンプレックスコンポーネントが含むメディアコンポーネントとメディアコンポーネントの役割とのうち少なくともいずれか１つを含むことができる。具体的には、メディアコンポーネントの役割は、オーディオコンポーネントが対話トラックであることを示すことができる。また、メディアコンポーネントの役割は、ビデオコンポーネントが３Ｄ映像の左側映像であることを示すことができる。
【０７１６】
それぞれのサービスは、１つまたは複数のメディアコンポーネントを含むことができる。また、それぞれのメディアコンポーネントは、メディアコンポーネントを識別するコンポーネント識別子、コンポーネントの形態、コンポーネントに関する説明、ターゲティング/個人化属性、サービス保護属性、ターゲットデバイス、視聴推奨等級および関連したコンポーネント情報のうち少なくともいずれか１つを属性(property)として有することができる。このとき、コンポーネント識別子の値は、放送サービスのコンポーネント間で共有できる。ターゲットデバイスは、主（プライマリ）(primary)デバイスおよび連動（コンパニオン）(companion)デバイスのうちいずれか１つを示すことができる。また、サービスシグナリングテーブルは、このようなメディアコンポーネントの属性をシグナリングするメディアコンポーネント情報を含むことができる。具体的には、サービスシグナリングテーブルは、メディアコンポーネント情報をコンポーネントレベル情報として含むことができる。これに関しては、図６８を参照して説明する。
【０７１７】
図７１は、本発明の一実施例に係るメディアコンポーネント情報を示す。
【０７１８】
メディアコンポーネント情報は、メディアコンポーネントの形態を示す情報、ターゲットデバイスに関する情報を含んでいるか否かを示す情報、ターゲットデバイスを示すターゲットデバイス情報、メディアコンポーネントを説明するテキスト情報、メディアコンポーネントの形態に応じたコンポーネントエンコーディングパラメータおよびメディアコンポーネントが含むコンプレックスコンポーネントである場合、コンプレックスコンポーネントに関する情報を含むことができる。
【０７１９】
メディアコンポーネント情報は、descriptor_tagフィールド、descriptor_lengthフィールド、component_typeフィールド、target_device_flagフィールド、target_deviceフィールド、text_lengthフィールドtext_charフィールド、component_data_typeフィールド、component_dataフィールドおよびcomplex_component_dataフィールドを含むことができる。
【０７２０】
descriptor_tagフィールドは、メディアコンポーネント情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０７２１】
descriptor_lengthフィールドは、descriptor_lengthフィールド以後の長さを示す。具体的な実施例において、descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０７２２】
component_typeフィールドは、メディアコンポーネントの形態を示す。具体的な実施例において、component_typeフィールドの値は、前述した基礎コンポーネント、コンポジットコンポーネントおよび適応型コンポーネントのうちいずれか１つを示すことができる。具体的には、component_typeフィールドの値が０x００である場合、該当メディアコンポーネントが基礎コンポーネントを示し、component_typeフィールドの値が０x０１である場合、該当メディアコンポーネントがコンポジットコンポーネントを示し、component_typeフィールドの値が０x０２である場合、該当メディアコンポーネントが適応型コンポーネントであることを示すことができる。具体的な実施例において、component_typeフィールドは、例えば４ビットフィールドである。
【０７２３】
target_device_flagフィールドは、target_deviceフィールドを含むか否かを示す。具体的な実施例において、target_device_flagフィールドは、例えば１ビットフィールドである。
【０７２４】
target_deviceフィールドは、該当コンポーネントが実行されるターゲットデバイスを示す。具体的な実施例において、target_deviceフィールドが持つ値は、該当コンポーネントが主(primary)デバイスのみで実行できるか、連動(companion)デバイスで実行できるかまたは主デバイスおよび連動デバイスの両方で実行できるかを示すことができる。具体的には、target_deviceフィールドの値が０x０１である場合、主デバイスのみで実行されることを示し、target_deviceフィールドの値が０x０２である場合、連動デバイスのみで実行されることを示し、target_deviceフィールドの値が０x０３である場合、主デバイスおよび連動デバイスの両方で実行されることを示すことができる、具体的な実施例において、target_deviceフィールドは、例えば３ビットフィールドである。
【０７２５】
text_lengthフィールドは、text_charフィールドの長さを示す。具体的な実施例において、text_lengthフィールドは、例えば８ビットフィールドである。
【０７２６】
text_charフィールドは、メディアコンポーネントを説明するテキストである。
【０７２７】
component_data_typeフィールドは、該当コンポーネントのエンコーディングの種類を示す。具体的には、図７２の実施例のような値を有することができる。具体的には、component_data_typeフィールドが持つ値が３５である場合、component_data_typeフィールドは、メディアコンポーネントがH.２６４/AVCコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が３６である場合、component_data_typeフィールドは、メディアコンポーネントがSVC enhancement層ストリームコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が３７である場合、component_data_typeフィールドは、メディアコンポーネントがHE AAC v２オーディオストリームコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が３８である場合、component_data_typeフィールドは、メディアコンポーネントがFLUTEファイル伝送セッションによって伝送されるメディアコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が３９である場合、component_data_typeフィールドは、メディアコンポーネントがSTKMストリームコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が４０である場合、component_data_typeフィールドは、メディアコンポーネントがLTKMストリームコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が４１である場合、component_data_typeフィールドは、メディアコンポーネントがOMA-RME DIMSストリームコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が４２である場合、component_data_typeフィールドは、メディアコンポーネントがNTPタイムベースストリームコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が７０である場合、component_typeフィールドは、メディアコンポーネントがHEVCビデオストリームコンポーネントであることを示すことができる。具体的には、component_data_typeフィールドが持つ値が７１である場合、component_typeフィールドは、メディアコンポーネントがISO BMFFで伝送されることを示すことができる。具体的な実施例において、component_typeフィールドは、例えば８ビットフィールドである。
【０７２８】
component_dataフィールドは、コンポーネントのエンコーディングパラメータを示す。エンコーディングパラメータが含むパラメータは、コンポーネントのエンコーディングの種類によって変わる。具体的には、エンコーディングパラメータが含むパラメータはcomponent_typeフィールドの値によって変わる。
【０７２９】
complex_component_dataフィールドは、メディアコンポーネントの形態がコンプレックス形態である場合、例えばコンポジットコンポーネントまたは適応型コンポーネントである場合、コンプレックスコンポーネントに関する情報を示す。これに関しては、図７３〜図７４を介して詳しく説明する。また、コンポーネント情報をビットストリーム形態を参照して説明したが、コンポーネント情報は、XMLファイル形式などの他の形式を含むことができる。
【０７３０】
図７３は、本発明の一実施例に係るコンプレックスコンポーネント情報を示す。
【０７３１】
コンプレックスコンポーネント情報は、コンポーネントのセット形態を示す情報、ターゲットデバイスに関する情報を含んでいるか否かを示す情報、ターゲットデバイスを示すターゲットデバイス情報、該当コンプレックスコンポーネントが含むサブメディアコンポーネントの個数、該当コンプレックスコンポーネントがコンポジットコンポーネントである場合、サブメディアコンポーネントが含むメディアの形態およびサブメディアメディアコンポーネントの役割を示す情報のうち少なくともいずれか１つを含むことができる。
【０７３２】
具体的には、コンプレックスコンポーネント情報は、図７３のようにaggretation_typeフィールド、num_sub_componentフィールド、sub_component_idフィールド、general_mdeida_typeフィールドおよびsub_component_roleフィールドのうち少なくともいずれか１つを含むことができる。
【０７３３】
aggretation_typeフィールドは、該当コンポーネントが属するセットの形態を示す。具体的には、aggretation_typeフィールドの値は、コンポジットコンポーネントであるかまたは適応型コンポーネントであるかのいずれか１つを示すことができる。具体的な実施例において、aggretation_typeフィールドは、例えば３ビットフィールドである。
【０７３４】
target_device_flagフィールドは、target_deviceフィールドを含むか否かを示す。具体的な実施例において、target_device_flagフィールドは、例えば１ビットフィールドである。
【０７３５】
target_deviceフィールドは、該当コンポーネントが実行されるターゲットデバイスを示す。具体的な実施例において、target_deviceフィールドが持つ値は該当コンポーネントが主(primary)デバイスのみで実行できるか、連動(companion)デバイスで実行できるかまたは主デバイスおよび連動デバイスの両方で実行できるかを示すことができる。具体的には、target_deviceフィールドの値が０x０１である場合、主デバイスのみで実行されることを示し、target_deviceフィールドの値が０x０２である場合、連動デバイスのみで実行されることを示し、target_deviceフィールドの値が０x０３である場合、主デバイスおよび連動デバイスの両方で実行されることを示すことができる、具体的な実施例において、target_deviceフィールドは、例えば３ビットフィールドである。
【０７３６】
num_sub_componentフィールドは、該当コンプレックスコンポーネントが含むサブメディアコンポーネントの個数を示す。具体的な実施例において、num_sub_componentフィールドは、例えば８ビットフィールドである。
【０７３７】
sub_component_idフィールドは、サブメディアコンポーネントを識別するサブメディアコンポーネント識別子を示す。具体的な実施例において、sub_component_idフィールドは、例えば８ビットフィールドである。
【０７３８】
general_mdeida_typeフィールドは、該当コンプレックスコンポーネントがコンポジットコンポーネントである場合、サブメディアコンポーネントが含むメディアの形態を示す。具体的には、general_mdeida_typeフィールドの値は、ビデオ、オーディオ、テキスト（text）、アプリケーションおよびメッセージのうちいずれか１つを示すことができる。具体的には、general_media_typeフィールドの値が０x００である場合、サブメディアコンポーネントが含むメディアがビデオであることを示し、general_media_typeフィールドの値が０x０１である場合、サブメディアコンポーネントが含むメディアがオーディオであることを示し、general_media_typeフィールドの値が０x０２である場合、サブメディアコンポーネントが含むメディアがテキストであることを示し、general_media_typeフィールドの値が０x０３である場合、サブメディアコンポーネントが含むメディアがアプリケーションであることを示し、general_media_typeフィールドの値が０x０４である場合、サブメディアコンポーネントが含むメディアがメッセージであることを示すことができる。具体的な実施例において、general_media_typeフィールドは、例えば４ビットフィールドである。
【０７３９】
sub_component_roleフィールドは、それぞれのサブメディアコンポーネントの役割を示す。具体的には、sub_component_roleフィールドの値は、サブメディアコンポーネントがスケーラブルビデオエンコーディング(scalable video encoding)のためのエンハンスメント層(enhancement layer)であることを示すことができる。また、他の具体的な実施例において、sub_component_roleフィールドの値は、サブメディアコンポーネントが３Ｄ映像の右側映像、左側映像および深さ情報のうちいずれか１つであることを示すことができる。また、他の具体的な実施例において、sub_component_roleフィールドの値は、サブメディアコンポーネントが複数の領域に分割された画面の特定位置のビデオであることを示すことができる。サブメディアコンポーネントが含むメディアの形態によって、sub_compoent_roleが示す情報は変わる。具体的な実施例において、sub_component_roleフィールドは、例えば８ビットフィールドである。
【０７４０】
このようなコンプレックスコンポーネント情報は、図７４の実施例のように、コンプレックスコンポーネント記述子内に含まれてもよい。また、コンプレックスコンポーネント情報をビットストリーム形態を参照して説明したが、コンプレックスコンポーネント情報は、XMLファイル形式などの他の形式を含むことができる。
【０７４１】
上述したように、メディアコンポーネントは、予め定められた一定の相互（関連）関係（predetermined relationship to each other）を有することができる。例えば、１つの字幕コンポーネントは、１つまたは複数のオーディオコンポーネントと関連する。このようなメディアコンポーネント間の関係をシグナリングするためにサービスシグナリングテーブルは、関連コンポーネントリスト情報を含むことができる。具体的には、サービスシグナリングテーブルは、関連コンポーネントリスト情報をコンポーネントレベル情報として含むことができる。図７５を参照して、関連コンポーネントリスト情報に関して具体的に説明する。
【０７４２】
図７５は、本発明の一実施例に係る関連コンポーネントリスト情報を示す。
【０７４３】
関連コンポーネントリスト情報は、メディアコンポーネントを識別するコンポーネント識別子、メディアコンポーネント形態を示す情報、メディアコンポーネントのエンコーディング形態を示す情報、メディアコンポーネントが含むメディアの形態を示す情報のうち少なくともいずれか１つを含むことができる。
【０７４４】
具体的には、図７５の実施例のように、関連コンポーネントリスト情報は、descriptor_tagフィールド、descriptor_lengthフィールド、num_associated_componentフィールド、component_idフィールド、component_typeフィールド、component_data_typeフィールドおよびgeneral_media_typeeフィールドのうち少なくともいずれか１つを含むことができる。
【０７４５】
descriptor_tagフィールドは、関連コンポーネントリスト情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０７４６】
descriptor_lengthフィールドは、descriptor_lengthフィールド以後の長さを示す。具体的な実施例において、descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０７４７】
num_associated_componentフィールドは、該当メディアコンポーネントに関連したメディアコンポーネントの個数を示す。具体的な実施例において、num_associated_componentフィールドは、例えば８ビットフィールドである。
【０７４８】
component_idフィールドは、関連したメディアコンポーネントを識別するコンポーネント識別子を示す。具体的な実施例において、component_idフィールドは、例えば８ビットフィールドである。
【０７４９】
component_typeフィールドは、メディアコンポーネントの形態を示す。具体的な実施例において、component_typeフィールドの値は、前述した基礎コンポーネント、コンポジットコンポーネントおよび適応型コンポーネントのうちいずれか１つを示すことができる。具体的には、component_typeフィールドの値が０x００である場合、関連したメディアコンポーネントが基礎コンポーネントであることを示し、component_typeフィールドの値が０x０１である場合、関連したメディアコンポーネントがコンポジットコンポーネントであることを示し、component_typeフィールドの値が０x０２である場合、関連したメディアコンポーネントが適応型コンポーネントであることを示すことができる。具体的な実施例において、component_typeフィールドは、例えば４ビットフィールドである。
【０７５０】
component_data_typeフィールドは、該当コンポーネントのエンコーディングの種類を示す。具体的には、図７２の実施例のような値を有することができる。具体的な実施例において、component_typeフィールドは、例えば８ビットフィールドである。
【０７５１】
general_mdeida_typeフィールドは、関連したメディアコンポーネントが含むメディアの形態を示す。具体的には、general_mdeida_typeフィールドの値は、ビデオ、オーディオ、テキスト、アプリケーションおよびメッセージのうちいずれか１つを示すことができる。具体的には、general_media_typeフィールドの値が０x００である場合、関連したメディアコンポーネントが含むメディアがビデオであることを示し、general_media_typeフィールドの値が０x０１である場合、関連したメディアコンポーネントが含むメディアがオーディオであることを示し、general_media_typeフィールドの値が０x０２である場合、関連したメディアコンポーネントが含むメディアがテキストであることを示し、general_media_typeフィールドの値が０x０３である場合、関連したメディアコンポーネントが含むメディアがアプリケーションであることを示し、general_media_typeフィールドの値が０x０４である場合、関連したメディアコンポーネントが含むメディアがメッセージであることを示すことができる。具体的な実施例において、general_media_typeフィールドは、例えば８ビットフィールドである。
【０７５２】
オーディオコンポーネントは、メディアコンポーネントを識別するコンポーネント識別子、コンポーネントの形態、コンポーネントに関する説明、ターゲティング/個人化属性、サービス保護属性、ターゲットデバイスおよび関連したコンポーネント情報のうち少なくともいずれか１つを属性(property)として有することができる。このとき、コンポーネント識別子の値は、放送サービスのコンポーネント間で共有できる。ターゲットデバイスは、主(primary)デバイス、連動(companion)デバイス並びに主デバイスおよび連動デバイスを両方とも含むもののいずれか１つを示すことができる。
【０７５３】
オーディオコンポーネントが基礎コンポーネントである場合、コーデック、チャネルの個数、ビットレート、圧縮パラメータなどを含むエンコーディング形式に対する属性を含むことができる。また、オーディオコンポーネントが基礎コンポーネントである場合、オーディオコンポーネントは、オーディオの言語情報を属性として含むことができる。オーディオコンポーネントのモード(mode)を属性として含むことができる。このとき、オーディオコンポーネントのモードは、完全なメインオーディオ、音楽、対話、効果音、視覚障害者のためのオーディオ、聴覚障害者のためのオーディオ、コメント（コメンタリ）(commentary)およびナレーション（解説）(voice over)のいずれか１つを含むことができる。
【０７５４】
オーディオコンポーネントがコンプレックスコンポーネントである場合、オーディオコンポーネントは、アグリゲーション（集約）の形態（タイプ）(type of aggregation)を示す情報、含まれるメディアコンポーネントのリスト、コンポジットコンポーネントである場合、含まれるコンポーネントの役割のうち少なくとも１つを属性として有することができる。セットの形態は、コンポジットおよび適応型コンポーネント、すなわちPickOneのいずれか１つを含むことができる。
【０７５５】
オーディオコンポーネントがトップレベルコンポーネントである場合、オーディオコンポーネントは、視聴推奨等級および関連した字幕コンポーネントに関する情報のうち少なくともいずれか１つを属性として有することができる。
【０７５６】
オーディオコンポーネントがpresentableコンポーネントである場合、ターゲティング/個人化、コンテンツ推奨等級、コンテンツ/サービス保護、ターゲットスクリーンおよび関連字幕コンポーネントのうち少なくともいずれか１つを属性として有することができる。このとき、ターゲットスクリーン属性は、主(primary)スクリーン、連動(companion)スクリーンおよび主スクリーンにその一部として挿入される(inset（インセット）)スクリーン（a screen partially inserted into the primary screen）(例えば、Picture In Picture、PIP)のいずれか１つを示すことができる。
【０７５７】
字幕コンポーネントは、コンポーネント識別子、コンポーネントの形態、ターゲティング/個人化属性、サービス保護属性、ターゲットデバイスおよび字幕コンポーネントに関連したオーディオコンポーネント識別子のうち少なくともいずれか１つを属性(property)として有することができる。このとき、コンポーネント識別子の値は、放送サービスのコンポーネント間で共有できる。ターゲットデバイスは、主(primary)デバイス、連動(companion)デバイス並びに主デバイスおよび連動デバイスを両方とも含むもののいずれか１つを示すことができる。
【０７５８】
字幕コンポーネントが基礎コンポーネントである場合、字幕コンポーネントは字幕コンポーネントの言語の種類および字幕コンポーネントの形態を属性として有することができる。具体的には、字幕コンポーネントの形態は、一般的な字幕または大きな文字の（読みやすい）(Easy-reader)字幕のうちいずれか１つを含むことができる。
【０７５９】
字幕コンポーネントが適応型コンポーネントである場合、字幕コンポーネントは、字幕コンポーネントが含むメディアコンポーネントのリストを属性として有することができる。
【０７６０】
字幕コンポーネントがトップレベルコンポーネントである場合、字幕コンポーネントは、推奨視聴等級を属性として有することができる。
【０７６１】
字幕コンポーネントがpresentableコンポーネントである場合、字幕コンポーネントは、ターゲティング/個人化、コンテンツ推奨等級、コンテンツ/サービス保護およびターゲットスクリーンのうち少なくともいずれか１つを属性として有することができる。このとき、ターゲットスクリーン属性は、主(primary)スクリーン、連動(companion)スクリーンおよび主スクリーンにその一部として挿入される(inset)スクリーン(例えば、Picture In Picture、PIP)のいずれか１つを示すことができる。
【０７６２】
ビデオコンポーネントは、メディアコンポーネントを識別するコンポーネント識別子、コンポーネントの形態、ターゲティング/個人化属性、サービス保護属性、ビデオコンポーネントの役割(role)、ターゲットスクリーンおよびビデオコンポーネントに関連したNRTデータサービスのうち少なくともいずれか１つを属性(property)として有することができる。このとき、コンポーネント識別子の値は、放送サービスのコンポーネント間で共有できる。ビデオコンポーネントの役割は、代替視点画面(alternative camera view)、代替ビデオコンポーネント、手話（受話）画面（sign language screen）、フォローサブジェクトビデオ(follow subject video)のいずれか１つを含むことができる。ターゲットスクリーンは、主(primary)デバイス、連動(companion)デバイス、主デバイスおよび連動デバイスを両方とも含むものまたはPIP(Picture In Picture)画面のうちいずれか１つを示すことができる。ビデオコンポーネントに関連したNRTデータサービスを含まない場合、すべての付加NRTデータサービスがビデオコンポーネントと接続されたことを示すことができる。
【０７６３】
ビデオコンポーネントが基礎コンポーネントである場合、ビデオコンポーネントは、コーデック、圧縮パラメータなどを含むエンコーディングフォーマット、縦横ピクセル値を含む解像度、画面比率(Aspect Ratio)、インターレースであるかプログレッシブであるかを示すことができる走査方式、フレームレート(frame rate)および静止画像モードであるか否かのうち少なくともいずれか１つを属性として有することができる。また、ビデオコンポーネントは、エンコーディングパラメータを属性として含むことができる。このとき、具体的なエンコーディングパラメータの種類は、ビデオコンポーネントのコーデックによって変わる。
【０７６４】
ビデオコンポーネントがコンプレックスコンポーネントである場合、ビデオコンポーネントは、アグリゲーション(aggregation)の形態、コンプレックスコンポーネントが含むメディアコンポーネントリストのうち少なくともいずれか１つを属性として有することができる。
【０７６５】
ビデオコンポーネントがコンプレックスコンポーネントのうちのコンポジットコンポーネントである場合、ビデオコンポーネントは、コンポジットコンポーネントが含むそれぞれのメディアコンポーネントの役割を属性として有することができる。このとき、メディアコンポーネントの役割は、スケーラブルビデオエンコーディング(scalable video encoding)のためのエンハンスメント層(enhancement layer)であることを示すことができる。また、他の具体的な実施例において、メディアコンポーネントの役割は、メディアコンポーネントが３Ｄ映像の右側映像、左側映像および深さ情報のうちいずれか１つであることを示すことができる。また、他の具体的な実施例において、メディアコンポーネントの役割は、メディアコンポーネントが複数の領域に分割された画面の特定位置のビデオであることを示すことができる。また、他の具体的な実施例において、メディアコンポーネントの役割は、特定被写体(subject)に追従して見られる画面（screen displayed according to a specific subject）であるフォローサブジェクト(Follow-Subject)メタデータを含むことができる。このようなフォローサブジェクトメタデータは、被写体の名前、被写体の位置および被写体の大きさのうち少なくともいずれか１つを含むことができる。フォローサブジェクト機能がストリームのフレーム単位のメタデータによってサポートされる場合、フォローサブジェクトメタデータは、被写体がフォーカス（結像）される（focused）メインビデオコンポーネントの領域を示すことができる。
【０７６６】
ビデオコンポーネントがコンプレックスコンポーネントのうちでもトップレベルコンポーネントである場合、ビデオコンポーネントは、推奨視聴等級および関連するオーディオコンポーネントのうち少なくともいずれか１つを属性として有することができる。
【０７６７】
ビデオコンポーネントがpresentableコンポーネントである場合、ビデオコンポーネントは、ターゲティング/個人化、コンテンツ推奨等級、コンテンツ/サービス保護、ターゲットスクリーン、関連オーディオpresentableコンポーネントおよび関連字幕presentableコンポーネントのうち少なくともいずれか１つを属性として有することができる。このとき、ターゲットスクリーン属性は、主(primary)スクリーン、連動(companion)スクリーンおよび主スクリーンにその一部として挿入される(inset)スクリーン(例えば、Picture In Picture、PIP)のいずれか１つを示すことができる。
【０７６８】
NRTデータサービスは、他のサービスに依存（従属）しない（not depending on）スタンドアローン(stand-alone)サービスからなることができる。また、NRTデータサービスは、他のサービスに依存する（従属的な）（depending on）付加(adjunct)NRTデータサービスからなることができる。このとき、付加NRTデータサービスは、ラジオサービスの一部(part)になることができる。また、付加NRTデータサービスは、TVサービスの一部になることができる。NRTデータサービスは、すべてのサービスに共通する属性、例えばサービス識別子を有することができる。また、NRTデータサービスは、NRTサービスと共通の属性を有することができる。
【０７６９】
データサービスは、サービスの言語、消費モデル(consumption mode)、必須の装置仕様（性能）(essential capabilities)のリスト、必須ではない装置仕様のリスト、ターゲットデバイスおよびデータサービスで使用可能なコンテンツアイテムのうち少なくともいずれか１つを属性として有することができる。
【０７７０】
消費モデルは、プッシュ(Push)、ポータル(Portal)、プッシュスクリプト(Scripted)、ポータルスクリプト、Triggered（トリガ）およびセグメントデリバリ(Segment Delivery)のうち少なくともいずれか１つを示すことができる。
【０７７１】
プッシュは、NRTデータサービスが要求に基づいたサービスを提供する。放送受信装置１００は、ユーザにサービスに関連したNRTデータサービスを自動アップデート（更新）するか否かに関する選択権を提供する。具体的には、放送受信装置１００は、ユーザからサービスに関連したNRTデータサービスの自動アップデートに関する入力を受信する。ユーザからサービスに関連したNRTデータサービスを自動アップデートするという入力を受信した場合、放送受信装置１００は、ユーザが使用可能なようにサービスに関連したコンテンツと最新バージョンの自動アップデートファイルとをキャッシュ(cache)する。ユーザからプッシュサービスに関する入力を受信した場合、放送受信装置１００は、あらかじめロードされている（準備された）(pre-loaded)コンテンツを表示する。
【０７７２】
ポータルは、ユーザがウェブブラウザを介してNRTデータサービスに接続するのに類似した経験を提供する。このとき、NRTデータサービスに使用されるファイルは、テキスト/グラフィックレンダリングをサポートしなければならない。
【０７７３】
プッシュスクリプトはプッシュと似ている。ただし、プッシュスクリプトは、サービスに対して特定放送会社のユーザインターフェースを提供する宣言型（宣伝的）オブジェクト(Declarative Object)を提供するという点に差がある。
【０７７４】
ポータルスクリプトはポータルと似ている。ただし、ポータルスクリプトは、サービスに対し特定放送会社のユーザインターフェースを提供する宣言型オブジェクト(Declarative Object)を提供するという点に差がある。
【０７７５】
Triggered（トリガ型）は、双方向付加NRTデータサービスで使用できる消費モデルである。典型的なTriggeredの使用例は、ユーザのユーザ経験を向上させるためにA/V仮想チャネルに対する付加NRTデータサービスが同期化された宣言型オブジェクトを伝達(deliver)することである。
【０７７６】
セグメントデリバリは、プログラムのターゲティングされた（対象となる）コンテンツの挿入（the insertion of a targeted content of a program）をサポートするためのセグメントおよびアプリケーションの伝達（デリバリ）を提供する。セグメントは、プログラムを複数の時間区間に区分したものである。ターゲティングセグメントは、ユーザの特性または放送受信装置１００等の特性に基づいたコンテンツを特定セグメントとして提供するものである。具体的には、放送受信装置１００は、ユーザの特性または放送受信装置１００等の特性に基づいたコンテンツを中間セグメントで再生することができる。具体的には、セグメントデリバリ消費モデルは、ユーザにこれを表示せずに(behind scene)、サービスのラジオプログラムまたはテレビ番組の中間に、ターゲティングコンテンツを挿入するのに使用される（a segment delivery consumption model is not displayed to a user (for example, behind scene) and is used to insert a targeting content into the middle of a radio program or a TV program）。例えば、サービスのラジオプログラムまたはテレビ番組の中間に、放送受信装置１００がユーザの特性に基づいたターゲティング広告を表示する（displays）。このようなNRTデータサービスは、ユーザの選択によって提供されるものではない。このようなNRTデータサービスは、挿入されたターゲティングアプリケーション、挿入されるためにターゲティングされたセグメントの収集(collection)およびアプリケーションによって開かれ(open)、消費される他のファイルのうち少なくともいずれか１つをコンテンツアイテムとして伝達することができる（Such NRT data service may be opened by an inserted targeting application, a collection of segments targeted for insertion, and an application and may deliver at least one of consumed other files as a content item）。このとき、挿入されたターゲティングアプリケーションは、どんなセグメントにどの時間で挿入されるかを選択することができる。また、ターゲティングアプリケーションは、放送受信装置１００にこのような挿入を知らせることができる。また、ターゲティングアプリケーションは報告機能を行うことができる。また、アプリケーションによって開かれ消費される他のファイルは、該当アプリケーションによってのみ解釈(interpret)されるように暗号化することができる。
【０７７７】
放送受信装置１００は、セグメントデリバリのために次のような動作を行うことができる。放送受信装置１００は、ユーザが付加NRTデータサービスを含むラジオサービスまたはTVサービスを選択するたびに繰り返してアプリケーションをダウンロードしないように、アプリケーションをあらかじめダウンロードしてキャッシュすることができる。また、放送受信装置１００は、ターゲティングされたセグメントをあらかじめダウンロードし満了日(expiration date)までキャッシュすることができる。これによって、放送受信装置１００は、ユーザに即座にターゲティングされたセグメントを提供することができる。また、放送受信装置１００は、アプリケーションを実行することができる。また、放送受信装置１００は、アプリケーションが特定セグメントを挿入することを知らせる場合、特定セグメントを挿入することができる。
【０７７８】
ターゲットデバイスは、主デバイス、連動デバイス並びに主デバイスおよび連動デバイスの両方とものいずれか１つを示すことができる。
【０７７９】
データサービスのコンテンツアイテムは、コンテンツアイテム識別子、コンテンツアイテムの名前、コンテンツアイテムが含むファイルセット(set)、コンテンツアイテムのアップデートがモニタリングされるべきであるか否かを示す表示（a display for representing whether the update of a content item is to be monitored）、ダウンロード可能時間を示すダウン可能ウインドウ(available window)、コンテンツアイテムが廃棄(discard)される時間を示す満了日(expiration date)、コンテンツアイテムの大きさ、コンテンツアイテムの再生の長さ（playback length）、ターゲティング/個人化属性、サービス/コンテンツ保護およびコンテンツ推奨等級(Content advisory rating)のうち少なくともいずれか１つを属性として有することができる。
【０７８０】
また、それぞれの付加NRTデータサービスは、ターゲットスクリーンを属性として有することができる。このとき、ターゲットスクリーンは、主(primary)デバイス、連動(companion)デバイス並びに主デバイスおよび連動デバイスを両方とも含むもののいずれか１つを示すことができる。
【０７８１】
このようなNRTデータ属性は、NRT情報テーブルを介してシグナリングされる。これに関しては、図７６を参照して説明する。
【０７８２】
図７６は、本発明の一実施例に係るNRT情報テーブルを示す。
【０７８３】
本発明の一実施例に係るNRT情報テーブルは、NRTサービスの識別子およびNRT情報ブロックを含むことができる。
【０７８４】
具体的な実施例において、NRT情報テーブルは、図７６の実施例のように、table_idフィールド、section_syntax_indicatorフィールド、private_indicatorフィールド、section_lengthフィールド、table_id_extensionフィールド、version_numberフィールド、current_next_indicatorフィールド、section_numberフィールド、last_section_numberrフィールド、service_idフィールドおよびNRT_information_blockフィールドのうち少なくともいずれか１つを含むことができる。
【０７８５】
table_idフィールドは、NRT情報テーブルの識別子を示す。このとき、table_idフィールドの値は、ATSC A/６５で定義されたreserved id値のうちの１つである。具体的な実施例において、table_idフィールドは、例えば８ビットフィールドである。
【０７８６】
section_syntax_indicatorフィールドは、NRT情報テーブルがＭＰＥＧ-２TS標準のlong形式のprivate section tableであるか否かを示す。具体的な実施例において、Section_syntax_indicatorフィールドは、例えば１ビットフィールドである。
【０７８７】
private_indicatorフィールドは、現在のテーブルがprivate sectionに対応するか否かを示す。具体的な実施例において、Private_indicatorフィールドは、例えば１ビットフィールドである。
【０７８８】
section_lengthフィールドは、section_lengthフィールド以後に含まれたsectionの長さを示す。具体的な実施例において、Section_lengthフィールドは、例えば１２ビットフィールドである。
【０７８９】
table_id_extensionフィールドは、table_idフィールドと組み合わせてNRT情報テーブルを識別する値を示す。特に、table_idフィールドは、NRT情報テーブルのプロトコルバージョンを示すprotocol_versionフィールドを含むことができる。具体的な実施例において、Protocol_versionフィールドは、例えば８ビットフィールドである。また、table_id_extensionフィールドは、NRT情報テーブルが伝送されるサブネットを識別するsubnet_idフィールドを含むことができる。具体的な実施例において、Subnet_idフィールドは、例えば８ビットフィールドである。
【０７９０】
version_numberフィールドは、NRT情報テーブルのバージョンを示す。放送受信装置１００は、vserion_numberフィールドの値に基づいてNRT情報テーブルの情報を利用するか否かを決定することができる。具体的には、version_numberフィールドの値が以前に受信したサービスシグナリングテーブルのバージョンと同一である場合、NRT情報テーブルの情報を利用しなくてもよい。具体的な実施例において、version_numberフィールドは、例えば５ビットフィールドである。
【０７９１】
current_next_indicatorフィールドは、NRT情報テーブルの情報が現在使用可能であるか否かを示す。具体的には、current_next_indicatorフィールドの値が１である場合、NRT情報テーブルの情報が使用可能であること示すことができる。また、current_next_indicatorフィールドの値が１である場合、NRT情報テーブルの情報を次に使用できることを示すことができる。具体的な実施例において、current_next_indicatorフィールドは、例えば１ビットフィールドである。
【０７９２】
section_numberフィールドは、現在のセクションの番号を示す。具体的な実施例において、section_numberフィールドは、例えば８ビットフィールドである。
【０７９３】
last_section_numberフィールドは、最後のセクションの番号を示す。NRT情報テーブルの大きさが大きい場合、複数のセクションに分けて伝送することができる。このとき、放送受信装置１００は、section_numberフィールドおよびlast_section_numberフィールドに基づいてNRT情報テーブルに必要なすべてのセクションが受信されたか否か（whether all sections necessary for an NRT information table are received）を判断する。具体的な実施例において、last_section_numberフィールドは、例えば８ビットフィールドである。
【０７９４】
service_idフィールドは、NRTサービスを識別する識別子を示す。具体的な実施例において、Service_idフィールドは、例えば１６ビットフィールドである。
【０７９５】
NRT_information_blockフィールドは、NRT情報ブロックを示す。これに関しては、図７７を参照して具体的に説明する。
【０７９６】
図７７は、本発明の一実施例に係るNRT情報ブロックを示す。
【０７９７】
NRT情報ブロックがシグナリングする時間区間（タイムスパン）(time span)の開始時間を示す情報、NRT情報ブロックがシグナリングする時間区間(time span)の長さを示す情報、NRT情報ブロックがシグナリングするコンテンツアイテムの個数、該当コンテンツアイテムを識別するコンテンツ識別情報、該当コンテンツアイテムが周期的にアップデートされるか否かを示す情報、コンテンツ保護(protection)が該当コンテンツアイテムが含むファイルに適用されたか否かを示す情報、該当コンテンツアイテムが、サービスが選択されると実行されるマスタコンテンツアイテムであるか否かを示す情報、NRT情報ブロックが該当コンテンツの再生時間の長さを含むか否かを示す情報、該当コンテンツの再生時間の長さ、NRT情報ブロックが該当コンテンツの再生遅延時間を含むか否かを示す情報、該当コンテンツの再生遅延時間、NRT情報ブロックが該当コンテンツアイテムの満了(expiration)時間を含むか否かを示す情報、コンテンツアイテムの満了時間、NRT情報ブロックが該当コンテンツアイテムの大きさ(size)を含むか否かを示す情報、該当コンテンツアイテムの大きさ、NRT情報ブロックがNRTサービスのターゲットデバイスに関する情報を含むか否かを示す情報、NRTサービスのターゲットデバイスに関する情報、該当コンテンツアイテムを放送網を介して受信できるか否かを示す情報、該当コンテンツアイテムをインターネット網を介して受信できるか否かを示す情報、該当コンテンツアイテムの名前および該当コンテンツに対する具体的な情報を含む記述子のうち少なくともいずれか１つを含むことができる。
【０７９８】
具体的には、NRT情報ブロックは、図７８の実施形態のように、time_span_startフィールド、time_span_lengthフィールド、num_content_items_in_sectionフィールド、content_id、updates_availableフィールド、content_security_conditions_indicatorフィールド、master_itemフィールド、playback_length_includedフィールド、palybace_Delay_includedフィールド、expiration_includedフィールド、content_size_includedフィールド、available_in_broadcastフィールド、target_includedフィールド、playback_length_in secondsフィールド、playback_delayフィールド、expirationフィールド、content_sizeフィールド、targetフィールド、content_name_textフィールドおよびcontent_descriptorフィールドのうち少なくともいずれか１つを含むことができる。
【０７９９】
具体的には、NRT情報ブロックは、図７８の実施形態のように、time_span_startフィールド、time_span_lengthフィールド、num_content_items_in_sectionフィールド、content_id、updates_availableフィールド、content_security_conditions_indicatorフィールド、master_itemフィールド、playback_length_includedフィールド、palyback_Delay_includedフィールド、expiration_includedフィールド、content_size_includedフィールド、available_in_internetフィールド、available_in_broadcastフィールド、target_includedフィールド、playback_length_in secondsフィールド、playback_delayフィールド、expirationフィールド、content_sizeフィールド、targetフィールド、content_name_lengthフィールド、content_name_textフィールドおよびcontent_descriptorフィールドのうち少なくともいずれか１つを含むことができる。
【０８００】
time_span_startフィールドは、NRT情報ブロックがシグナリングする時間区間(time span)の開始時間を示す。具体的な実施例において、time_span_startは、例えば３２ビットフィールドである。
【０８０１】
time_span_lengthフィールドは、NRT情報ブロックがシグナリングする時間区間(time span)の長さを示す。具体的な実施例において、time_span_lengthフィールドは、例えば１６ビットフィールドである。
【０８０２】
NRT_content_items_in_sectionフィールドは、NRT情報ブロックがシグナリングするコンテンツアイテムの個数を示す。具体的な実施例において、NRT_content_items_in_sectionフィールドは、例えば８ビットフィールドである。
【０８０３】
content_idフィールドは、該当コンテンツアイテムを識別する情報を示す。具体的な実施例において、例えば３２ビットフィールドである。
【０８０４】
updates_availableフィールドは、該当コンテンツアイテムがアップデートされるか否かを示す。具体的な実施例において、updates_availableフィールドは、例えば１ビットフィールドである。
【０８０５】
content_security_conditions_indicatorフィールドは、該当コンテンツアイテムが含むファイルのうち少なくとも１つにコンテンツ保護が適用されたか否かを示す。具体的な実施例において、content_security_conditions_indicatorフィールドは、例えば１ビットフィールドである。
【０８０６】
master_itemフィールドは、該当コンテンツアイテムがマスタコンテンツアイテムであるか否かを示す。具体的には、master_itemフィールドは、該当コンテンツアイテムが、該当NRTサービスが選択されると実行されなければならないコンテンツアイテムであるか否かを示す。具体的な実施例において、master_itemフィールドは、例えば１ビットフィールドである。
【０８０７】
playback_length_includedフィールドは、NRT情報ブロックが該当コンテンツアイテムの再生時間の長さを含むか否かを示す。具体的な実施例において、Playback_length_includedフィールドは、例えば１ビットフィールドである。
【０８０８】
palyback_Delay_includedフィールドは、NRT情報ブロックが該当コンテンツアイテムの遅延再生時間情報を含むか否かを示す。具体的な実施例において、palyback_Delay_includedフィールドは、例えば１ビットフィールドである。
【０８０９】
expiration_includedフィールドは、NRT情報ブロックが該当コンテンツアイテムの満了時間を含むか否かを示す。具体的な実施例において、expiration_includedフィールドは、例えば１ビットフィールドである。
【０８１０】
content_size_includedフィールドは、NRT情報ブロックが該当コンテンツアイテムの大きさを含むか否かを示す。具体的な実施例において、content_size_includedフィールドは、例えば１ビットフィールドである。
【０８１１】
available_in_broadcastフィールドは、該当コンテンツアイテムが放送網を介して獲得できるか否かを示す。具体的な実施例において、available_in_broadcastフィールドは、例えば１ビットフィールドである。
【０８１２】
available_in_internetフィールドは、該当コンテンツアイテムがインターネット網を介して獲得できるか否かを示す。具体的な実施例において、available_in_internetフィールドは、例えば１ビットフィールドである。
【０８１３】
target_includedフィールドは、NRT情報ブロックがターゲットデバイスに関する情報を含んでいるか否かを示す。具体的な実施例において、target_includedフィールドは、例えば１ビットフィールドである。
【０８１４】
playback_length_in secondsフィールドは、該当コンテンツアイテムの再生時間の長さを示す。具体的な実施例において、秒単位の長さを示すことができる。また、具体的な実施例において、Playback_length_in secondsフィールドは、例えば２４ビットフィールドである。
【０８１５】
playback_delayフィールドは、該当コンテンツアイテムの再生遅延時間を示す。具体的な実施例において、Playback_delayフィールドは、例えば２４ビットフィールドである。
【０８１６】
expirationフィールドは、該当コンテンツアイテムの満了時間を示す。具体的な実施例において、expirationフィールドは、例えば３２ビットフィールドである。
【０８１７】
content_sizeフィールドは、該当コンテンツアイテムの大きさを示す。具体的な実施例において、content_sizeフィールドは、例えば４０ビットフィールドである。
【０８１８】
targetフィールドは、該当コンテンツアイテムのターゲットデバイス情報を示す。具体的な実施例において、targetフィールドの値が０x０１である場合、ターゲットデバイスが主(primary)デバイスだけであることを示すことができる。また、targetフィールドの値が０x０２である場合、ターゲットデバイスが１つまたは複数の連動(companion)デバイスであることを示すことができる。また、targetフィールドの値が０x０３である場合、ターゲットデバイスが主デバイスおよび１つまたは複数の連動(companion)デバイスの両方であることを示すことができる。
【０８１９】
content_name_lengthフィールドは、content_name_textフィールドの長さを示す。具体的な実施例において、content_name_lengthフィールドは、例えば８ビットフィールドである。
【０８２０】
content_name_textフィールドは、コンテンツアイテムの名前を示す。
【０８２１】
content_descriptorフィールドは、コンテンツアイテムに関する具体的な情報を含む１つまたは複数のNRTサービス記述子を示す。これに関しては、図７８を参照して具体的に説明する。図７８は、本発明の一実施例に係るNRTサービス記述子を示す。
【０８２２】
NRTサービス記述子は、NRTサービスの消費モデルを示す情報、NRTサービスの自動アップデートの有無を示す情報、NRTサービスのために必要な最小格納空間を示す情報を含むか否かを示す情報、コンテンツアイテムのデフォルトの（基本）(default)大きさを示す情報を含むか否かを示す情報、ターゲットデバイスの情報、NRTサービスのために必要な最小格納空間を示す情報およびコンテンツアイテムのデフォルトの大きさを示す情報のうち少なくともいずれか１つを含むことができる。
【０８２３】
具体的な実施例において、NRTサービス記述子は、consumption_modelフィールド、auto-updateフィールド、stoargage_reservation_presentフィールド、decault_content_size_presentフィールド、target_includeフィールド、storage_reservationフィールドおよびdefault_content_sizeフィールドのうち少なくともいずれか１つを含むことができる。
【０８２４】
counsumption_modelフィールドは、NRTサービスの消費モデルを示す。具体的な実施例において、counsumption_modelフィールドの値が０x００である場合、プッシュNRTサービスの消費モデルがプッシュであることを示す。また、counsumption_modelフィールドの値が０x０１である場合、NRTサービスの消費モデルがポータルであることを示す。また、counsumption_modelフィールドの値が０x０２である場合、NRTサービスの消費モデルがスクリプトプッシュであることを示す。counsumption_modelフィールドの値が０x０３である場合、NRTサービスの消費モデルがスクリプトポータルであることを示す。counsumption_modelフィールドの値が０x０４である場合、NRTサービスの消費モデルがTriggeredであることを示す。counsumption_modelフィールドの値が０x０５である場合、NRTサービスの消費モデルがセグメントデリバリであることを示す。具体的な実施例において、counsumption_modelフィールドは、例えば６ビットフィールドである。
【０８２５】
auto-updateフィールドは、自動アップデートサービスが提供されることを示す。具体的な実施例において、auto-updateフィールドは、例えば１ビットフィールドである。
【０８２６】
stoargage_reservation_presentフィールドは、NRTサービスを実行するために必要な最小格納空間の大きさを示す情報を含むか否かを示す。具体的な実施例において、stoargage_reservation_presentフィールドは、例えば１ビットフィールドである。
【０８２７】
decault_content_size_presentフィールドは、コンテンツアイテムのデフォルトの大きさを示す情報を含むか否かを示す。具体的な実施例において、decault_content_size_presentフィールドは、１ビットフィールドである。
【０８２８】
target_includeフィールドは、ターゲットデバイスに関する情報を含むか否かを示す。具体的な実施例において、target_includeフィールドは、例えば１ビットフィールドである。
【０８２９】
storage_reservationフィールドは、NRTサービスを実行するために必要な最小格納空間の大きさを示す。具体的な実施例において、storage_reservationフィールドは、例えば２４ビットフィールドである。
【０８３０】
default_content_sizeフィールドは、コンテンツアイテムのデフォルトの大きさを示す。具体的な実施例において、default_content_sizeフィールドは、例えば４０ビットフィールドである。
【０８３１】
前述したNRT情報ブロックおよびNRTサービス記述子は、ビットストリーム形式で説明した。ただし、NRT情報ブロックおよびNRTサービス記述子は、ビットストリーム形式に限定されず、他の形式を含むことができる。例えば、NRT情報ブロックおよびNRTサービス記述子は、XMLファイル形式を有することができる。
【０８３２】
また、放送サービス、プログラムおよびプログラムを構成する複数の時間区間のうちプログラムの本編（主なコンテンツ）（primary content）の内容を含むショーセグメント(show segment)のグラフィックアイコンをシグナリングするために、放送サービスシグナリングテーブル、プログラム情報およびセグメント情報は、グラフィックアイコン情報を含むことができる。特に、放送サービスシグナリングテーブルは、グラフィックアイコン情報をサービスレベル情報として含むことができる。また、プログラム情報は、グラフィックアイコン情報をプログラムレベル情報として含むことができる。また、セグメント情報は、グラフィックアイコン情報をセグメントレベル情報として含むことができる。
【０８３３】
図７９は、本発明の一実施例に係るグラフィックアイコン情報を示す。
【０８３４】
グラフィックアイコン情報は、アイコン識別子、アイコン伝送方法を示すアイコン伝送モード、アイコンの位置が特定されているか否かを示す情報、アイコン位置の基準となる座標を示す座標系(coordinate system)情報、アイコンの水平座標を示す水平座標情報、アイコンの垂直座標を示す垂直座標情報、アイコンのイメージ形態を示す情報、アイコンイメージが格納された位置を示すURL情報およびアイコンデータ自体のうち少なくともいずれか１つを含むことができる。
【０８３５】
具体的には、図７９の実施例のように、descriptor_tagフィールド、descriptor_lengthフィールド、descriptor_numberフィールド、last_decirptor_numberフィールド、icon_idフィールド、icon_transport_modeフィールド、position_flagフィールド、coordinate_systemフィールド、icon_horizontal_originフィールド、icon_vertical_originフィールド、icon_type_lengthフィールド、icon_type_charsフィールド、icon_data_lengthフィールド、icon_data_byteフィールド、url_lengthフィールド、urlフィールドおよびicon_content_linkageフィールドのうち少なくともいずれか１つを含むことができる。
【０８３６】
descriptor_tagフィールドは、アイコン情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０８３７】
descriptor_lengthフィールドは、このフィールド以後のアイコン情報の長さを示す。具体的な実施例において、decroptor_lengthは、例えば８ビットフィールドである。
【０８３８】
descriptor_numberフィールドは、アイコン情報が複数の記述子に分かれて伝送される場合、現在の記述子の順序を示す。具体的な実施例において、初めて伝送される記述子である場合、descriptor_numberフィールドの値は０x００である。具体的な実施例において、descriptor_numberフィールドの値は１ずつ増加することができる。具体的な実施例において、descriptor_numberフィールドは、例えば４ビットフィールドである。
【０８３９】
last_decirptor_numberフィールドは、最後のdescriptorの番号を示す。具体的な実施例において、last_decirptor_numberフィールドは、例えば４ビットフィールドである。
【０８４０】
icon_idフィールドは、アイコンを識別するアイコン識別子を示す。具体的な実施例において、icon_idフィールドは、例えば８ビットフィールドである。
【０８４１】
icon_transport_modeフィールドは、アイコンの伝送方法を示す。具体的には、icon_transport_modeの値は、アイコンイメージがグラフィックアイコン情報自体を介して伝送される場合、アイコンイメージがURLを介してリンクされる場合、およびアイコンイメージがFLUTEセッションを介して伝送される場合のうちいずれか１つを示すことができる。具体的な実施例において、図８０の実施例のように、icon_transport_modeの値が０x００である場合、アイコンイメージがグラフィックアイコン情報自体を介して伝送されることを示し、icon_transport_modeの値が０x０１である場合、アイコンイメージがURLを介してリンクされることを示し、icon_transport_modeの値が０x０２である場合、アイコンイメージがFLUTEセッションを介して伝送されることを示すことができる。具体的な実施例において、icon_transport_modeフィールドは、例えば２ビットフィールドである。
【０８４２】
position_flagフィールドは、アイコンの位置が特定されているか否かを示す。具体的な実施例において、position_flagフィールドは、例えば１ビットフィールドである。
【０８４３】
coordinate_systemフィールドは、アイコン位置の基準となる座標を示す。具体的には、coordinate_systemフィールドの値は、座標系が７２０x５７６座標から構成された場合、座標系が１２８０x７２０座標から構成された場合、座標系が１９２０x１０８０座標から構成された場合、座標系が３８４０x２１６０座標から構成された場合、および座標系が７６８０x４３２０座標から構成された場合のうちいずれか１つを示すことができる。具体的な実施例において、図８１の実施例のように、coordinate_systemフィールドの値が０x００である場合、座標系が７２０x５７６座標から構成されたことを示し、０x０１である場合、座標系が１２８０x７２０座標から構成されたことを示し、０x０２である場合、座標系が１９２０x１０８０座標から構成されたことを示し、０x０３である場合、座標系が３８４０x２１６０座標から構成されたことを示し、０x０４である場合、座標系が７６８０x４３２０座標から構成されたことを示すことができる。具体的な実施例において、coordinate_systemフィールドは、例えば３ビットフィールドである。
【０８４４】
icon_horizontal_originフィールドは、アイコンの水平座標を示す。具体的には、左の列から右の列への方向に座標の値が増加することができる。具体的な実施例において、icon_horizontal_originフィールドは、例えば１３ビットフィールドである。
【０８４５】
icon_vertical_originフィールドは、アイコンの垂直座標を示す。具体的には、上の行から下の行への方向に座標の値が増加することができる。具体的な実施例において、icon_vertical_originフィールドは、例えば１３ビットフィールドである。
【０８４６】
icon_type_lengthフィールドは、icon_typeフィールドの長さを示す。具体的な実施例において、icon_type_lengthフィールドは、例えば８ビットフィールドである。
【０８４７】
icon_type_charsフィールドは、アイコンのイメージ形態を示す。具体的には、icon_type_charsフィールドの値は、RFC ２０４５で定義されたMIME(Multipurpose Internet Mail Extensions)イメージの形態を有することができる。
【０８４８】
icon_data_lengthフィールドは、アイコンイメージがグラフィックアイコン情報を介して伝送される場合、icon_data_byteフィールドの長さを示す。具体的な実施例において、icon_data_lengthフィールドは、例えば８ビットフィールドである。
【０８４９】
icon_data_byteフィールドは、グラフィックアイコン情報が伝送するアイコンイメージのデータを示す。
【０８５０】
url_lengthフィールドは、アイコンイメージがURLを介してリンクされる場合、urlフィールドの長さを示す。url_lengthフィールドは、例えば８ビットフィールドである。
【０８５１】
urlフィールドは、アイコンをリンクするURLを示す。
【０８５２】
icon_content_linkageフィールドは、アイコンイメージがFLUTEセッションを介して伝送される場合、アイコンイメージを伝送するFLUTE FDTコンテンツリンケージ（リンク）(contents linkage)を示す。
【０８５３】
グラフィックアイコン情報がビットストリーム形態である実施例を介してグラフィックアイコン情報を説明したが、グラフィックアイコン情報は、XMLファイル形式などの他の形式を含むことができる。
【０８５４】
また、上述したように、放送サービスは、１つまたは複数のメディアコンポーネントを含むことができる。サービスシグナリングテーブルが、放送サービスが含むメディアコンポーネントをシグナリングするメディアコンポーネントリスト情報を含むことができる。特に、放送サービスシグナリングテーブルは、メディアコンポーネントリスト情報をサービスレベル情報として含むことができる。
【０８５５】
これに関しては、図８２を参照して具体的に説明する。
【０８５６】
図８２は、本発明の一実施例に係るメディアコンポーネントリスト情報を示す。
【０８５７】
メディアコンポーネントリスト情報は、コンポーネントを識別するコンポーネント識別子、メディアコンポーネントの形態を示すコンポーネント形態情報およびメディアコンポーネントが含むメディアの形態を示すメディア形態情報のうち少なくともいずれか１つを含むことができる。
【０８５８】
具体的な実施例において、図８２の実施例のように、メディアコンポーネントリスト情報は、descriptor_tagフィールド、descriptor_lengthフィールド、num_componentフィールド、component_idフィールド、component_typeフィールドおよびgeneral_media_typeフィールドを含むことができる。
【０８５９】
descriptor_tagフィールドは、コンポーネントリスト情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０８６０】
descriptor_lengthフィールドは、descriptor_lengthフィールド以後の長さを示す。具体的な実施例において、descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０８６１】
num_componentフィールドは、該当放送サービスに含まれたメディアコンポーネントの個数を示す。具体的な実施例において、メディアコンポーネントリスト情報は、例えば８ビットフィールドである。
【０８６２】
component_idフィールドは、該当メディアコンポーネントを識別する識別子を示す。具体的な実施例において、component_idフィールドは、例えば８ビットフィールドである。
【０８６３】
component_typeフィールドは、メディアコンポーネントの形態を示す。具体的な実施例において、component_typeフィールドの値は、前述した基礎コンポーネント、コンポジットコンポーネントおよび適応型コンポーネントのうちいずれか１つを示すことができる。具体的には、component_typeフィールドの値が０x００である場合、該当メディアコンポーネントが基礎コンポーネントであることを示し、component_typeフィールドの値が０x０１である場合、該当メディアコンポーネントがコンポジットコンポーネントであることを示し、component_typeフィールドの値が０x０２である場合、該当メディアコンポーネントが適応型コンポーネントであることを示すことができる。具体的な実施例において、component_typeフィールドは、例えば４ビットフィールドである。
【０８６４】
general_media_typeフィールドは、メディアコンポーネントが含むメディアの形態を示す。general_media_typeフィールドの値は、ビデオ、オーディオ、テキスト、アプリケーションおよびメッセージのうちいずれか１つを示すことができる。具体的には、general_media_typeフィールドの値が０x００である場合、メディアコンポーネントが含むメディアがビデオであることを示し、general_media_typeフィールドの値が０x０１である場合、メディアコンポーネントが含むメディアがオーディオであることを示し、general_media_typeフィールドの値が０x０２である場合、メディアコンポーネントが含むメディアがテキストであることを示し、general_media_typeフィールドの値が０x０３である場合、メディアコンポーネントが含むメディアがアプリケーションであることを示し、general_media_typeフィールドの値が０x０４である場合、メディアコンポーネントが含むメディアがメッセージであることを示すことができる。具体的な実施例において、general_media_typeフィールドは、例えば４ビットフィールドである。
【０８６５】
コンポーネントリスト情報がビットストリーム形態である実施例を参照して説明したが、コンポーネントリスト情報は、XMLファイル形式などの他の形式を含むことができる。
【０８６６】
具体的な実施例において、１つのメディアコンポーネントは、同じ放送ストリームの複数の放送サービスで共有(share)することができる。また、相互に異なる放送ストリームに含まれた複数の放送サービスが、１つのメディアコンポーネントを共有することができる。これによって、１つのメディアコンポーネントを複数の放送サービスが効率的に共有できる方法が必要である。このために、放送伝送装置は、それぞれのメディアコンポーネントまたは放送サービスがURI(unique resource identifier)と接続(associate)されるようにすることができる。
【０８６７】
これに関しては、図８３を介して詳しく説明する。
【０８６８】
図８３は、本発明の一実施例に係る放送サービスシグナリングテーブルにおいて、メディアコンポーネントまたは放送サービスがURIを介してマッピングされる場合を示す（Fig. 83 is a view when a media component or a broadcast service is mapped through URI in a broadcast service signaling table according to an embodiment of the present invention）。放送サービスシグナリング（テーブル）において、放送サービスまたはメディアコンポーネントをURIを介してシグナリングすることができる。このとき、放送サービスまたはメディアコンポーネントをURIを介してシグナリングする情報をURIリンケージ(linkage)情報ということができる。URIリンケージ情報は、URI、または放送会社または地域別に独立して規定できるプライベートデータのうち少なくともいずれか１つを含むことができる。
【０８６９】
具体的な実施例において、図７５の実施例のように、descriptor_tagフィールド、descriptor_lengthフィールド、uri_lengthフィールド、uri_charフィールドおよびprivate_data_byteフィールドのうち少なくともいずれか１つを含むことができる。
【０８７０】
descriptor_tagフィールドは、URIリンケージ情報を含むことを示す。具体的な実施例において、URIリンケージ情報は、例えば８ビットフィールドである。
【０８７１】
descriptor_lengthフィールドは、descriptor_lengthフィールド以後のURIリンケージ情報の長さを示す。具体的な実施例において、descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０８７２】
uri_lengthフィールドは、uri_charフィールドの長さを示す。具体的な実施例において、uri_lengthフィールドは、例えば８ビットフィールドである。
【０８７３】
uri_charフィールドは、URI文字列のそれぞれの文字を示す。具体的な実施例において、uri_charフィールドは、例えば８ビットフィールドである。
【０８７４】
private_data_byteフィールドは、放送会社または地域別に独立して規定できるプライベートデータを示す。具体的な実施例において、private_data_byteフィールドは、例えば８ビットフィールドである。
【０８７５】
放送受信装置１００は、URIリンケージ情報のURIを介してメディアコンポーネントまたは放送サービスを識別することができる。URIリンケージ情報のURIがメディアコンポーネントを識別する場合、放送サービスシグナリングテーブルは、URIリンケージ情報をコンポーネントレベル情報として含むことができる。URIリンケージ情報のURIが放送サービスを識別する場合、放送サービスシグナリングテーブルは、URIリンケージ情報をサービスレベル情報として含むことができる。
【０８７６】
図８３の実施例ではビットストリームを参照して説明したが、URIリンク情報の形式はこれに限定されるものではない。特にURIリンク情報は、XMLファイル形式を有することができる。
【０８７７】
放送伝送装置は、特定条件を有するユーザをターゲティングする(targeting)（対象とする）放送サービスまたはメディアコンポーネントを伝送することができる。また、放送受信装置１００は、放送受信装置１００のユーザの情報を伝送し、放送受信装置１００のユーザに合う放送サービスまたはメディアコンポーネントを受信することができる。例えば、放送受信装置１００は、放送受信装置１００が位置する地域情報を伝送し、該当地域のための放送サービスを受信することができる。このためには、放送サービスまたはメディアコンポーネントがターゲティングするターゲティング基準と個人化属性に関する情報をシグナリングする方法が必要である。これに対しては、図８４を参照して説明する。
【０８７８】
図８４は、放送サービスまたはメディアコンポーネントのターゲティング基準をシグナリングするターゲティング基準情報を示す。
【０８７９】
放送サービスシグナリングテーブルは、放送サービスまたはメディアコンポーネントのターゲティング基準をシグナリングするターゲティング基準情報を含むことができる。
【０８８０】
ターゲティング基準情報は、ターゲティング基準を識別するターゲティング識別子情報、ターゲティングの形態を示すターゲティング形態情報、具体的なターゲティング基準を示すターゲティング基準値情報のうち少なくともいずれか１つを含むことができる。
【０８８１】
具体的な実施例において、図８４の実施例のように、ターゲティング基準情報は、descriptor_tagフィールド、descriptor_lengthフィールド、num_targeting_criteriaフィールド、criterion_id_lengthフィールド、crerion_idフィールド、criterion_type_codeフィールド、num_criterion_valuesフィールド、criterion_value_lengthフィールドおよびcriterion_valueフィールドのうち少なくともいずれか１つを含むことができる。
【０８８２】
descriptor_tagフィールドは、ターゲティング基準情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【０８８３】
descriptor_lengthフィールドは、descriptor_tagフィールド以後のターゲティング基準情報の長さを示す。descriptor_lengthフィールドは、例えば８ビットフィールドである。
【０８８４】
num_targeting_criteriaフィールドは、ターゲティング基準情報の個数を示す。具体的な実施例において、放送サービスまたはメディアコンポーネントが有するターゲティング基準は複数でもよい。具体的な実施例において、num_targeting_criteriaフィールドは、例えば８ビットフィールドである。
【０８８５】
criterion_id_lengthフィールドは、crerion_idフィールドの長さを示す。具体的な実施例において、criterion_id_lengthフィールドは、例えば８ビットフィールドである。
【０８８６】
crerion_idフィールドは、ターゲティング基準を識別するターゲティング基準識別子を示す。具体的な実施例において、crerion_idフィールドは、例えば８ビットフィールドである。
【０８８７】
criterion_type_codeフィールドは、ターゲティング基準の形態を示す。具体的な実施例において、criterion_type_codeフィールドは、例えば３ビットフィールドである。
【０８８８】
num_criterion_valuesフィールドは、ターゲティング基準値の個数を示す。具体的な実施例において、放送サービスまたはメディアコンポーネントは、ターゲティング基準形態に対応する複数のターゲティング基準値を有することができる。具体的な実施例において、num_criterion_valuesフィールドは、例えば５ビットフィールドである。
【０８８９】
criterion_value_lengthフィールドは、criterion_valueフィールドの長さを示す。具体的な実施例において、criterion_value_lengthフィールドは、例えば８ビットフィールドである。
【０８９０】
criterion_valueフィールドは、ターゲティング基準値を示す。
【０８９１】
具体的な実施例において、ターゲティング基準情報がメディアコンポーネントのターゲティング基準をシグナリングする場合、放送サービスシグナリングテーブルはターゲティング基準情報をコンポーネントレベル情報として含むことができる。具体的な実施例において、ターゲティング基準情報が放送サービスのターゲティング基準をシグナリングする場合、放送サービスシグナリングテーブルはターゲティング基準情報をサービスレベル情報として含むことができる。
【０８９２】
図８４の実施例では、ビットストリーム形式を参照して説明したが、ターゲティング基準情報はビットストリーム形式に制限されない。特にターゲティング基準情報は、XMLファイル形式を有することができる。
【０８９３】
放送サービスシグナリングテーブルは、それぞれの放送サービスまたはメディアコンポーネントを説明するテキスト情報を含むことができる。これは図８５を参照して具体的に説明する。
【０８９４】
図８５は、放送サービスまたはメディアコンポーネントを説明するテキスト情報を示す。
【０８９５】
具体的には、テキスト情報は、テキスト言語の種類を示す情報、テキスト情報を識別する識別子、および放送サービスまたはメディアコンポーネントを含むテキストを説明するテキスト情報のうち少なくともいずれか１つを含むことができる。
【０８９６】
具体的な実施例において、図８５の実施例のように、descriptor_numberフィールド、last_descriptor_numberフィールド、description_idフィールド、language_codeフィールド、text_lengthフィールドおよびtext_charフィールドのうち少なくともいずれか１つを含むことができる。
【０８９７】
descriptor_numberフィールドは、記述子の順序を示す。１つの記述子がテキスト情報を全て含むことができない場合、複数の記述子がテキスト情報を分けて含むことができる。このとき、descriptor_numberフィールドは、複数の記述子のうちの該当記述子の番号を示す。具体的な実施例において、descriptor_numberフィールドは、例えば４ビットフィールドである。
【０８９８】
last_descriptor_numberフィールドは、テキスト情報を含む最後の記述子の番号を示す。具体的な実施例において、last_descriptor_numberフィールドは、例えば４ビットフィールドである。
【０８９９】
description_idフィールドは、テキスト情報を識別する識別子を示す。具体的には、放送受信装置１００は、特定放送サービスまたはメディアコンポーネントに関するテキスト情報を、description_idフィールドの値に基づいて他のメディアコンポーネントまたは放送サービスに関するテキスト情報から識別することができる。具体的な実施例において、description_idフィールドは、例えば８ビットフィールドである。
【０９００】
language_codeフィールドは、テキスト情報に使用された言語を示す。具体的な実施例において、language_codeフィールドは、例えば２４ビットフィールドである。
【０９０１】
text_lengthフィールドは、text_charフィールドの長さを示す。具体的な実施例において、text_lengthフィールドは、例えば８ビットフィールドである。
【０９０２】
text_charフィールドは、テキスト情報の文字を示す。具体的な実施例において、text_charフィールドは、例えば８ビットフィールドである。
【０９０３】
具体的な実施例において、テキスト情報がメディアコンポーネントを説明するテキストをシグナリングする場合、放送サービスシグナリングテーブルは、テキスト情報をコンポーネントレベル情報として含むことができる。具体的な実施例において、テキスト情報が放送サービスを説明するテキスト情報をシグナリングする場合、放送サービスシグナリングテーブルは、テキスト情報をサービスレベル情報として含むことができる。
【０９０４】
図８５の実施例では、ビットストリーム形式を参照して説明したが、テキスト情報の形式はビットストリーム形式に制限されない。特にテキスト情報は、XMLファイル形式を有することができる。
【０９０５】
また、放送サービス、プログラムまたはプログラムを構成する複数の時間区間のうちプログラムの本編の内容を含むショーセグメント(show segment)のタイトルをシグナリングするために、放送サービスシグナリングテーブル、プログラム情報またはセグメント情報は、タイトル情報を含むことができる。特に、放送サービスシグナリングテーブルは、タイトル情報をサービスレベル情報として含むことができる。また、プログラム情報は、タイトル情報をプログラムレベル情報として含むことができる。また、セグメント情報は、タイトル情報をセグメントレベル情報として含むことができる。特に、タイトル情報は、複数の言語をサポートするために複数の言語で表示されたタイトルを含むことができる。
【０９０６】
図８６は、放送サービス、プログラムまたはショーセグメントのタイトル情報を示す。
【０９０７】
タイトル情報は、タイトルの言語数を示す情報、タイトルの言語を示す情報、タイトルの長さを示す情報およびタイトルが含む字のうち少なくともいずれか１つを含むことができる。
【０９０８】
具体的には、タイトル情報は、図８６の実施例のように、Num_titleフィールド、language_codeフィールド、title_lengthフィールドおよびtext_charフィールドのうち少なくともいずれか１つを含むことができる。
【０９０９】
num_titleフィールドは、タイトルの個数を示す。具体的には、タイトル情報は、複数の言語によって表示される放送サービス、プログラムまたはショーセグメントのタイトルを含むことができる。従って、num_titleフィールドは、タイトルを表示する言語の数を示すことができる。具体的な実施例において、num_tilteフィールドは、例えば８ビットフィールドである。
【０９１０】
language_codeフィールドは、タイトルを表示する言語の種類を示す。具体的な実施例において、language_codeフィールドは、例えば２４ビットフィールドである。
【０９１１】
title_lengthフィールドは、タイトルの字数を示す。具体的な実施例において、title_lengthフィールドは、例えば８ビットフィールドである。
【０９１２】
text_charフィールドは、タイトルが含む字を示す。具体的な実施例において、text_charフィールドは、例えば８ビットまたは１６ビットフィールドである。
【０９１３】
ビットストリーム形式を介してタイトル情報を説明したが、タイトル情報はビットストリーム形式に制限されず、他の形式を含むことができる。具体的な実施例において、タイトル情報は、XMLファイル形式を有することができる。
【０９１４】
また、放送サービス、プログラムまたはプログラムを構成する複数の時間区間のうちプログラムの本編の内容を含むショーセグメント(show segment)のジャンルをシグナリングするために、放送サービスシグナリングテーブル、プログラム情報またはセグメント情報は、ジャンル情報を含むことができる。特に、放送サービスシグナリングテーブルは、ジャンル情報をサービスレベル情報として含むことができる。また、プログラム情報は、ジャンル情報をプログラムレベル情報として含むことができる。また、セグメント情報は、ジャンル情報をセグメントレベル情報として含むことができる。これに関しては、図８７を参照して具体的に説明する。
【０９１５】
図８７は、放送サービス、プログラムまたはショーセグメントのジャンル情報を示す。
【０９１６】
ジャンル情報は、ジャンルの個数を示す情報と、放送サービス、プログラムまたはショーセグメントのジャンルを示す情報と、を含むことができる。
【０９１７】
具体的には、ジャンル情報は、図８７の実施例のように、Num_genreフィールドおよびgenre_valueのうち少なくともいずれか１つを含むことができる。
【０９１８】
num_genreフィールドは、ジャンルの個数を示す。具体的な実施例において、num_genreフィールドは、例えば８ビットフィールドであり、１つの放送サービス、プログラムおよびショーセグメントであっても複数のジャンルに対応することができる。従って、ジャンル情報は、１つの放送サービス、プログラムおよびショーセグメントに対して複数のジャンル情報を含むことができる。このため、ジャンル情報はnum_genreフィールドを含むことができる。
【０９１９】
genre_valueフィールドは、放送サービス、プログラムまたはショーセグメントのジャンルを示す。具体的な実施例において、genre_valueフィールドは、例えば８ビットフィールドである。
【０９２０】
ビットストリーム形式を介してジャンル情報を説明したが、ジャンル情報はビットストリーム形式に制限されず、他の形式を含むことができる。具体的な実施例において、ジャンル情報は、XMLファイル形式を有することができる。
【０９２１】
また、放送サービス、メディアコンポーネントまたはコンテンツアイテムは、特定デバイスのためのものであってもよい。具体的には、放送サービス、メディアコンポーネントまたはコンテンツアイテムは、主デバイスのみを対象とするものであってもよい。あるいは、放送サービス、メディアコンポーネントまたはコンテンツアイテムは、複数の連動デバイスのためのものであってもよい。これによって、放送サービス、メディアコンポーネントまたはコンテンツアイテムに係るターゲットデバイスをシグナリングするために、放送サービスシグナリングテーブル、プログラムテーブル、またはNRT情報テーブルは、ターゲットデバイス情報を含むことができる。これに関しては、図８８を参照して説明する。
【０９２２】
図８８は、放送サービス、メディアコンポーネントまたはコンテンツアイテムに係るターゲットデバイスをシグナリングするターゲットデバイス情報を示す。
【０９２３】
ターゲットデバイス情報は、放送サービス、メディアコンポーネントまたはコンテンツアイテムのターゲットデバイスを示す情報を含むことができる。
【０９２４】
具体的な実施例において、ターゲットデバイス情報は、図８８のように、target_deviceフィールドを含むことができる。target_dgviceフィールドは、放送サービス、メディアコンポーネントまたはコンテンツアイテムのターゲットデバイスを示す。具体的な実施例において、target_deviceフィールドは、例えば８ビットフィールドである。
【０９２５】
ビットストリーム形式によってターゲットデバイス情報を説明したが、ターゲットデバイス情報は、ビットストリーム形式に制限されず、他の形式を含むことができる。具体的な実施例において、ターゲットデバイス情報は、XMLファイル形式を有することができる。
【０９２６】
以上では放送サービスと放送サービスに含まれるメディアコンポーネントとに関して説明した。図８９〜図９３を参照して、プログラムおよびセグメントに関して説明する。
【０９２７】
図８９は、放送サービスが複数のセグメントに区分されることを示す。
【０９２８】
放送サービスは、あらかじめ予定された開始時間と再生の長さを有する視覚的区間(temporal segment)のプログラムを含むことができる。具体的には、ラジオサービスは、ラジオプログラム、またはオーディオプログラムを含む。また、TVサービスは、テレビ番組を含むことができる。また、ユーザ要求コンテンツサービスは、ユーザ要求プログラムを含むことができる。また、スタンドアローンNRTデータサービスは、データプログラムを含むことができる。
【０９２９】
このようなプログラムは、放送サービス時間に応じて区分することができる。また、ラジオサービスが放送される時間は、ラジオプログラムのプログラム長さ(duration)の合計と同一である。TVサービスが放送される時間は、テレビ番組長さ(duration)の合計と同一である。ただし、ユーザ要求コンテンツサービスのプログラム長さ(duration)は、特定コンテンツが再生される時間でなく、ユーザ要求コンテンツサービスが可能な時間を示すだけである。従って、個別的なコンテンツの再生時間は、ユーザによって左右される。ただし、コンテンツアイテム(contents item)が提供される間開始時間と長さは、プログラムによって制限される。従って、ユーザ要求コンテンツサービスを介して提供されるコンテンツアイテムは、カタログに含まれてもよい。このとき、カタログは、サービスが可能なようにユーザインターフェースを提供するアプリケーションであってもよい。
【０９３０】
プログラムは、関連したプログラムの主なコンテンツを示すショーを含むことができる。プログラムの属性であると考えられる多くの部分は、実質的にショーの属性であるとみなすことができる。例えば、プログラム属性に含まれたプログラムを説明するテキスト、俳優またはジャンルなどは、ショーの属性に関するものである。プログラム属性のうちショーの属性ではない他の属性は、プログラム自体の属性である。例えば、プログラムを含むサービスの識別子またはプログラムの開始時間は、プログラム自体の属性である。同一のショーを含むプログラムでもプログラム自体の属性は異なる場合がある。
【０９３１】
ショーは、ショーを識別する識別子情報、ショーの長さ、ショーのテキストのタイトル、ショーを説明するテキスト、ジャンル、グラフィックアイコン、ショーに関連したセグメントのリスト、推奨視聴等級、ターゲティング/個人化属性およびコンテンツ/サービス保護属性のうち少なくともいずれか１つを含むことができる。このようなショーの属性は、ショーの情報を介してシグナリングされる。このとき、ショーに関連したセグメントのリストは、ショーを含むセグメントのリストを含むことができる。これに関しては、図６１を参照して説明する。
【０９３２】
図９０は、本発明の一実施例に係るショーの情報を示す。
【０９３３】
ショーの情報は、ショーを識別する識別情報およびショーに関する具体的な情報を含むショーの情報ブロックを含むことができる。
【０９３４】
具体的には、ショーの情報は、図９０の実施例のように、table_idフィールド、section_syntax_indicatorフィールド、private_indicatorフィールド、section_lengthフィールド、table_id_extentsionフィールド、version_numberフィールド、current_next_indicatorフィールド、section_numberフィールド、last_section_numberフィールド、show_idフィールド、show_infoamtion_blockを含むことができる。
【０９３５】
table_idフィールドは、ショーの情報を含むことを示す。具体的な実施例において、table_idフィールドは、例えば８ビットフィールドである。
【０９３６】
section_syntax_indicatorフィールドは、ショーの情報がMPEG-２TS標準のlong形式のprivate section tableであるか否かを示す。具体的な実施例において、section_syntax_indicatorフィールドは、例えば１ビットフィールドである。
【０９３７】
private_indicatorフィールドは、現在のテーブルがprivate sectionに該当するか否かを示す。具体的な実施例において、private_indicatorフィールドは、例えば１ビットフィールドである。
【０９３８】
section_lengthフィールドは、section_lengthフィールド以後に含まれたsectionの長さを示す。具体的な実施例において、section_lengthフィールドは、例えば１２ビットフィールドである。
【０９３９】
table_id_extensionフィールドは、table_idフィールドと組み合わせてショーの情報を識別する値を示す。具体的には、protocol_versionフィールドおよびsubnet_idフィールドのうち少なくともいずれか１つを含むことができる。protocol_versionフィールドは、プログラム情報のプロトコルバージョンを示す。具体的には、protocol_versionフィールドは、上位４ビットは主（メジャー）バージョンナンバを示し、下位４ビットは副（マイナ）バージョンナンバを示す８ビットフィールドである。subnet_idフィールドは、プログラム情報が放送ストリームを介して伝送される場合、ショーの情報を伝送するIPサブネット(subnet)を識別するサブネット識別子を示すことができる。また、他の具体的な実施例において、subnet_idフィールドの値は０である。インターネット網を介してプログラム情報が伝送される場合、subnet_idフィールドは、放送ストリームを介して伝送されるプログラム情報のsubnet_idフィールドと同一の値を有する。具体的な実施例において、subnet_idフィールドは、例えば８ビットフィールドである。
【０９４０】
version_numberフィールドは、ショーの情報のバージョンを示す。放送受信装置１００は、vserion_numberフィールドの値に基づいてショーの情報を利用するか否かを決定することができる。具体的には、version_numberフィールドの値が以前に受信したサービスショーの情報のバージョンと同一である場合、ショーの情報を利用しなくてもよい。具体的な実施例において、version_numberフィールドは、例えば５ビットフィールドである。
【０９４１】
current_next_indicatorフィールドは、ショーの情報が現在使用可能であるか否かを示す。具体的には、current_next_indicatorフィールドの値が１である場合、ショーの情報が使用可能であること示すことができる。また、current_next_indicatorフィールドの値が１である場合、ショーの情報を次に使用できることを示すことができる。具体的な実施例において、current_next_indicatorフィールドは、例えば１ビットフィールドである。
【０９４２】
section_numberフィールドは、現在のセクションの番号を示す。具体的な実施例において、section_numberフィールドは、例えば８ビットフィールドである。
【０９４３】
last_section_numberフィールドは、最後のセクションの番号を示す。ショーの情報テーブルの大きさが大きい場合、複数のセクションに分けて伝送することができる。このとき、放送受信装置１００は、section_numberフィールドおよびlast_section_numberフィールドに基づいて、ショーの情報に関して必要なすべてのセクションが受信されたか否かを判断する（the broadcast receiving device 100 determines whether all sections necessary for show information are received on the basis of the section_number field and the last_section_number field）。具体的な実施例において、last_section_numberフィールドは、例えば８ビットフィールドである。
【０９４４】
show_idフィールドは、ショーの情報がシグナリングするショーを識別するショー識別子を示す。具体的な実施例において、show_idフィールドは、例えば１６ビットフィールドである。
【０９４５】
show_information_blockフィールドは、ショーの属性に関する情報を含むショー情報ブロックを示す。これに関しては、図９１を参照して具体的に説明する。
【０９４６】
図９１は、本発明の一実施例に係るショーの情報ブロックを示す。
【０９４７】
ショーの情報ブロックは、ショーの長さ、ショーを説明するテキスト、ショーに関連したセグメントの個数、ショーに関連したセグメントをシグナリングするセグメント情報ブロックおよびショーの属性に関する具体的な情報を含む記述子のうち少なくともいずれか１つを含むことができる。このとき、ショーに関連したセグメントは、ショーを含むセグメントからなることができる。
【０９４８】
具体的には、ショーの情報ブロックは、図９１の実施例のように、time_span_lengthフィールド、title_text_lengthフィールド、title_text()フィールド、num_segmentフィールド、segment_information_block()フィールド、num_show_descriptorsフィールドおよびdescriptorsフィールドのうち少なくともいずれか１つを含むことができる。
【０９４９】
time_span_lengthフィールドは、ショーの長さを示す。ショーは、複数のセグメントに含まれてもよい。このとき、複数のセグメントの開始時間は相互に異なるもののショーの長さは同一である。他のプログラムに含まれてもショーセグメントのコンテンツは同一であるからである。具体的な実施例において、time_span_lengthフィールドは、例えば１６ビットフィールドである。
【０９５０】
title_text_lengthフィールドは、title_text()、num_segmentフィールド、segment_information_block()フィールド、num_show_descriptorsフィールドおよびdescriptorsフィールドを含んでもよい。
【０９５１】
図９２は、本発明の一実施例に係るセグメント情報ブロックを示す。
【０９５２】
セグメント情報ブロックは、セグメントを識別するセグメント識別子、セグメントの開始時間を示す情報、セグメントの長さを示す情報およびセグメントに関する具体的な情報を含む記述子のうち少なくともいずれか１つを含むことができる。具体的な実施例において、セグメント識別子は、セグメントを含むプログラムを識別するプログラム識別子およびドメインネームに基づいたものを含むことができる。具体的には、セグメント識別子は、セグメントを含むプログラムを識別するプログラム識別子とドメインネームとの組み合わせからなることができる。具体的には、セグメントの開始時間は、セグメントを含むプログラムの開始を基準とした相対時間である。
【０９５３】
具体的な実施例において、セグメント情報ブロックは、図９２の実施例のように、segment_idフィールド、start_timeフィールド、time_span_lengthフィールド、num_segment_descriptorsフィールドおよびdescriptorフィールドのうち少なくともいずれか１つを含むことができる。
【０９５４】
segment_idフィールドは、セグメントを識別するセグメント識別子を示す。具体的な実施例において、segment_idフィールドは、例えば１６ビットフィールドである。
【０９５５】
start_timeフィールドは、セグメントの開始時間を示す。同一のショーを含むセグメントであっても各セグメント別に開始時間が異なる場合がある。従って、セグメント情報は、それぞれのセグメントに対する開始時間を示す情報を含むことができる。具体的な実施例において、start_timeフィールドは、例えば３２ビットフィールドである。
【０９５６】
time_span_lengthフィールドは、セグメントの長さを示す。具体的な実施例において、time_span_lengthフィールドは、例えば１６ビットフィールドである。
【０９５７】
num_segment_descriptorsフィールドは、セグメント情報ブロックが含む記述子の数を示す。具体的な実施例において、num_segment_descriptorsフィールドは、例えば８ビットフィールドである。
【０９５８】
descriptorフィールドは、セグメントに関する具体的な情報を含む。
【０９５９】
これまで、ショーの情報、ショーの情報ブロックおよびセグメント情報ブロックをビットストリーム形式を参照して説明したが、ショーの情報、ショーの情報ブロックおよびセグメント情報はビットストリーム形式に制限されず、他の形式を含むことができる。具体的には、ショーの情報、ショーの情報ブロックおよびセグメント情報は、XMLファイル形式を有することができる。
【０９６０】
図９３は、本発明の一実施例に係る放送伝送装置が、ショーの情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を伝送することを示す。
【０９６１】
放送伝送装置は、制御部を介して放送サービスが含むショーの属性を獲得する(S７３１)。ショーの属性は、上述したようにショーを識別する識別子情報、ショーの長さ、ショーのテキストのタイトル、ショーを説明するテキスト、ジャンル、グラフィックアイコン、ショーに関連したセグメントのリスト、推奨視聴等級、ターゲティング/個人化属性およびコンテンツ/サービス保護属性のうち少なくともいずれか１つを含むことができる。このようなショーの属性は、ショーの情報を介してシグナリングされる。このとき、ショーに関連したセグメントのリストは、ショーを含むセグメントのリストを含むことができる。
【０９６２】
放送伝送装置は、制御部を介してショーの属性に基づいてプログラムをシグナリングするプログラム情報を生成する(S７３３)。ショーの情報は、図９０〜図９１を参照して説明したショーの情報およびショーの情報ブロックのうち少なくともいずれか１つを含むことができる。
【０９６３】
放送伝送装置は、制御部を介してショーに関連したセグメントの属性を獲得する(S７３５)。セグメントの属性は、セグメントを識別する固有な（一意の）識別子、該当セグメントの時間区間の間再生するメディアコンポーネントのリスト、セグメントの開始時間と長さ、セグメントの種類(type)、ターゲティング/個人化属性および視聴推奨等級のうち少なくともいずれか１つを含むことができる。
【０９６４】
放送伝送装置は、制御部を介してセグメントの属性に基づいてセグメント情報ブロックを生成する(S７３７)。セグメント情報ブロックは、前述した図９２のセグメント情報ブロックからなることができる。
【０９６５】
放送伝送装置は、伝送部を介してセグメント情報ブロックおよびプログラム情報のうち少なくともいずれか１つを含む放送信号を伝送する(S７３９)。
【０９６６】
図９４は、本発明の一実施例に係る放送受信装置が、ショーの情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を受信することを示す。
【０９６７】
放送受信装置１００は、放送受信部１１０を介して放送信号を受信する(S７５１)。
【０９６８】
放送受信装置１００は、制御部１５０を介して放送信号に基づいてプログラム情報を獲得する(S７５３)。具体的には、放送受信装置１００は、放送信号からショーの情報を獲得することができる。このとき、ショーの情報は、図９０〜図９１を参照して説明したショーの情報およびショーの情報ブロックのうち少なくともいずれか１つを含むことができる。
【０９６９】
放送受信装置１００は、制御部１５０を介してショーの情報に基づいてショーの属性を獲得する(S７５５)。ショーの属性は、上述したようにショーを識別する識別子情報、ショーの長さ、ショーのテキストのタイトル、ショーを説明するテキスト、ジャンル、グラフィックアイコン、ショーに関連したセグメントのリスト、推奨視聴等級、ターゲティング/個人化属性およびコンテンツ/サービス保護属性のうち少なくともいずれか１つを含むことができる。このようなショーの属性は、ショーの情報を介してシグナリングされる。このとき、ショーに関連したセグメントのリストは、ショーを含むセグメントのリストを含むことができる。
【０９７０】
放送受信装置１００は、制御部１５０を介して放送信号に基づいてショーに関連したセグメントの情報ブロックを獲得する(S７５７)。具体的には、放送受信装置１００は、ショーの情報ブロックからショーに関連したセグメント情報ブロックを獲得することができる。セグメント情報ブロックは、前述した図９２のセグメント情報ブロックを含むことができる。
【０９７１】
放送受信装置１００は、制御部１５０を介してセグメント情報ブロックに基づいてセグメントの属性を獲得する(S７５９)。セグメント情報ブロックは、前述した図９２のセグメント情報ブロックからなることができる。
【０９７２】
放送受信装置１００は、ショーの属性およびショーに関連したセグメント属性のうち少なくともいずれか１つに基づいてショーの属性を表示するサービスガイドを生成する(S７６１)。具体的な実施例において、サービスガイドは、ショーの属性とショーに関連したセグメントとを一緒に表示することができる。例えば、サービスガイドは同一のショーを含む複数のセグメントの属性を一緒に表示することができる。このとき、セグメントの属性は、セグメントの開始時間およびセグメントを含むプログラムの属性のうち少なくともいずれか１つを含むことができる。このとき、プログラムの属性は、プログラムの開始時間、プログラムが属したサービスの情報のうち少なくともいずれか１つを含むことができる。
【０９７３】
ラジオプログラム、テレビ番組およびデータプログラムは、固有な（一意の）識別子、プログラムに含まれたメディアコンポーネントのリスト、プログラムの開始時間および長さ、関連したショーを識別するショー識別子、タイトルおよびプログラムを説明するテキスト、プログラムのジャンル、グラフィックアイコン、視聴推奨等級、ターゲティング/個人化属性、コンテンツ保護属性、関連したデータサービスのリストおよび関連したセグメントのリストのうち少なくともいずれか１つを含むことができる。オーディオプログラム、テレビ番組およびデータプログラムが含む属性は、プログラム情報を介してシグナリングされる。これに関しては、図９５〜図１００を参照して説明する。
【０９７４】
図９５は、本発明の一実施例に係るプログラム情報を示す。
【０９７５】
プログラム情報は、図９５の実施例のように、table_idフィールド、section_syntax_indicatorフィールド、private_indicatorフィールド、section_lengthフィールド、table_id_extentsionフィールド、version_numberフィールド、current_next_indicatorフィールド、section_numberフィールド、last_section_numberフィールド、service_idフィールドおよびprogram_information_blockフィールドのうち少なくともいずれか１つを含むことができる。
【０９７６】
table_idフィールドは、プログラム情報を含むことを示す。具体的な実施例において、table_idフィールドは、例えば８ビットフィールドである。
【０９７７】
section_syntax_indicatorフィールドは、プログラム情報がMPEG-２TS標準のlong形式のprivate section tableであるか否かを示す。具体的な実施例において、section_syntax_indicatorフィールドは、例えば１ビットフィールドである。
【０９７８】
private_indicatorフィールドは、現在のテーブルがprivate sectionに該当するか否かを示す。具体的な実施例において、private_indicatorフィールドは、例えば１ビットフィールドである。
【０９７９】
section_lengthフィールドは、section_lengthフィールド以後に含まれたsectionの長さを示す。具体的な実施例において、section_lengthフィールドは、例えば１２ビットフィールドである。
【０９８０】
table_id_extensionフィールドは、table_idフィールドと組み合わせてプログラム情報を識別する値を示す。具体的には、protocol_versionフィールドおよびsubnet_idフィールドのうち少なくともいずれか１つを含むことができる。protocol_versionフィールドは、プログラム情報のプロトコルバージョンを示す。具体的には、protocol_versionフィールドは、上位４ビットは主バージョンナンバを示し、下位４ビットは副バージョンナンバを示す８ビットフィールドである。subnet_idフィールドは、プログラム情報が放送ストリームを介して伝送される場合、プログラム情報を伝送するIPサブネット(subnet)を識別するサブネット識別子を示すことができる。また、他の具体的な実施例において、subnet_idフィールドの値は０である。インターネット網を介してプログラム情報が伝送される場合、subnet_idフィールドは、放送ストリームを介して伝送されるプログラム情報のsubnet_idフィールドと同一の値を有する。具体的な実施例において、subnet_idフィールドは、例えば８ビットフィールドである。
【０９８１】
version_numberフィールドは、プログラム情報のバージョンを示す。放送受信装置１００は、vserion_numberフィールドの値に基づいてプログラム情報を利用するか否かを決定することができる。具体的には、version_numberフィールドの値が以前に受信したサービスプログラム情報のバージョンと同一である場合、プログラム情報を利用しなくてもよい。具体的な実施例において、version_numberフィールドは、例えば５ビットフィールドである。
【０９８２】
current_next_indicatorフィールドは、プログラム情報が現在使用可能であるか否かを示す。具体的には、current_next_indicatorフィールドの値が１である場合、プログラム情報が使用可能であること示すことができる。また、current_next_indicatorフィールドの値が１である場合、プログラム情報を次に使用できることを示すことができる。具体的な実施例において、current_next_indicatorフィールドは、例えば１ビットフィールドである。
【０９８３】
section_numberフィールドは、現在のセクションの番号を示す。具体的な実施例において、section_numberフィールドは、例えば８ビットフィールドである。
【０９８４】
last_section_numberフィールドは、最後のセクションの番号を示す。プログラム情報テーブルの大きさが大きい場合、複数のセクションに分けて伝送することができる。このとき、放送受信装置１００は、section_numberフィールドおよびlast_section_numberフィールドに基づいてプログラム情報に必要なすべてのセクションが受信されたか否か（whether all sections necessary for program information are received）を判断する。具体的な実施例において、last_section_numberフィールドは、例えば８ビットフィールドである。
【０９８５】
service_idフィールドは、プログラム情報に関連した放送サービスを識別するサービス識別子を示す。具体的には、service_idフィールドは、プログラム情報でシグナリングするプログラムを含む放送サービスを識別するサービス識別子を示すことができる。具体的な実施例において、service_idフィールドは、例えば８ビットフィールドである。
【０９８６】
program_information_blockフィールドは、プログラムの属性に関する情報含むプログラム情報ブロックを示す。これに関しては、図９６を参照して具体的に説明する。
【０９８７】
図９６は、本発明の一実施例に係るプログラム情報ブロックを示す。
【０９８８】
プログラム情報ブロックは、プログラム情報ブロックがシグナリングするプログラムの個数、シグナリングするプログラムを識別するプログラム識別子、プログラムの開始時間、プログラムの長さ、プログラムを説明するテキストおよびプログラムの属性をシグナリングする記述子を含むことができる。
【０９８９】
具体的な実施例において、図９６の実施例のようにプログラム情報ブロックは、num_programフィールド、program_idフィールド、time_span_startフィールド、time_span_lengthフィールド、title_text_lengthフィールド、title_textフィールド、num_program_descriptorsフィールドおよびdescriptorフィールドのうち少なくともいずれか１つを含むことができる。
【０９９０】
num_programフィールドは、プログラム情報ブロックがシグナリングするプログラムの個数を示す。具体的な実施例において、num_programフィールドは、例えば８ビットフィールドである。
【０９９１】
program_idフィールドは、該当プログラムを識別するプログラム識別子を示す。具体的な実施例において、program_idフィールドは、例えば８ビットフィールドである。
【０９９２】
time_span_startフィールドは、該当プログラムの開始時間を示す。具体的には、time_span_startフィールドは、１９８０年１月６日０時から経過したUTC時間を秒単位で示すことができる。具体的な実施例において、time_span_startフィールドは、例えば３２ビットフィールドである。
【０９９３】
time_span_lengthフィールドは、該当プログラムの長さを示す。具体的には、time_span_startフィールド値を基準として該当プログラムが放送される時間の長さを分単位で示すことができる。time_span_lengthフィールドの値が一度決まれば以後は変わらない。具体的な実施例において、time_span_lengthフィールドは、例えば１６ビットフィールドである。
【０９９４】
title_text_lengthフィールドは、title_textフィールドの長さを示す。具体的な実施例において、title_textフィールドは、例えば８ビットフィールドである。
【０９９５】
title_textフィールドは、該当プログラムのタイトルが含むそれぞれの文字を示す。具体的な実施例において、各文字はUTF-８エンコーディング形式を有することができる。また、具体的な実施例において、title_textフィールドは、例えば８ビットフィールドである。
【０９９６】
num_program_descriptorsフィールドは、プログラム情報ブロックが含む記述子の個数を示す。具体的な実施例において、num_program_descriptorsフィールドは、例えば８ビットフィールドである。
【０９９７】
descriptorフィールドは、プログラムの属性と関連した情報を含む記述子を示す。例えばdescriptorフィールドが持つ記述子は、メディアコンポーネントリストに関する情報を含むことができる。また、descriptorフィールドが持つ記述子は、推奨視聴等級に関する情報を含むことができる。また、descriptorフィールドが持つ記述子は、ターゲティング属性に関する情報を含むことができる。また、descriptorフィールドが持つ記述子は、プログラムを説明するテキストに関する情報を含むことができる。従って、descriptorフィールドは、component_list_descriiptor、targeting_descriptorおよびtext_descriptorのうち少なくともいずれか１つを含むことができる。ただし、図９６の実施例のようなプログラム情報ブロックは、プログラムに関連したショーをシグナリングできない。具体的には、図９６の実施例のようなプログラム情報ブロックは、プログラムが含むショーをシグナリングできない。これを解決するための方法に関しては、図９７を参照して説明する。
【０９９８】
図９７は、本発明の他の実施例に係るプログラム情報ブロックを示す。
【０９９９】
本発明の他の実施例に係るプログラム情報ブロックは、プログラム情報ブロックがシグナリングするプログラムに関連したショーに関する情報を含むか否かを示す情報およびプログラム情報ブロックがシグナリングするプログラムに関連したショーを識別するショー識別子のうち少なくともいずれか１つをさらに含むことができる。
【１０００】
具体的な実施例において、プログラム情報ブロックは図９７のように、associated_show_flagフィールドおよびshow_idフィールドのうち少なくともいずれか１つを含むことができる。
【１００１】
associated_show_flagフィールドは、プログラム情報ブロックがシグナリングするプログラムに関連したショーに関する情報を含むか否かを示す。具体的な実施例において、関連したショーが存在する場合、放送受信装置１００は、ショーの情報を受信することができる。従って、associated_show_flagが１である場合、放送受信装置１００は、ショーの情報を受信することができる。このとき、ショーの情報は、図９０および図９１で説明したショーの情報またはショーの情報ブロックからなることができる。具体的な実施例において、associated_show_flagフィールドは、例えば１ビットフィールドである。
【１００２】
show_idフィールドは、プログラム情報ブロックがシグナリングするプログラムに関連したショーを識別するショー識別子を示す。具体的な実施例において、Show_idフィールドは、例えば１６ビットフィールドである。
【１００３】
ただし、図９７のようなプログラム情報ブロックは、プログラムが含むメディアコンポーネントの属性をコンポーネントレベル情報を介してシグナリングできない。従って、多様な属性を有する複数のメディアコンポーネントを効率的にシグナリングできない問題がある。これを解決するための方法に関しては、図９８を参照して説明する。
【１００４】
図９８は、本発明の他の実施例に係るプログラム情報ブロックを示す。
【１００５】
プログラム情報ブロックは、該当プログラムが含むメディアコンポーネントの個数、該当メディアコンポーネントを識別するコンポーネント識別子、該当メディアコンポーネントが該当プログラムを再生するために必要な必須メディアコンポーネントであるか否かを示す情報およびメディアコンポーネントの付加的な属性を含むコンポーネント記述子を含むことができる。
【１００６】
具体的な実施例において、図９８の実施例のようにプログラム情報ブロックは、num_componentフィールド、component_idフィールド、essential_conponent_indicatorフィールド、num_component_descritporsフィールドおよびcomponent_descriptorフィールドのうち少なくともいずれか１つを含むことができる。
【１００７】
num_componentフィールドは、該当プログラムが含むメディアコンポーネントの個数を示す。具体的な実施例において、num_componentフィールドは、例えば８ビットフィールドである。
【１００８】
component_idフィールドは、該当メディアコンポーネントを識別するコンポーネント識別子を示す。具体的な実施例において、component_idフィールドは、例えば８ビットフィールドである。
【１００９】
essential_component_indicatorフィールドは、該当メディアコンポーネントが該当放送サービスの再生(presentation)のために必要な必須メディアコンポーネントであるか否かを示す。具体的な実施例において、essential_component_indicatorフィールドは、例えば１ビットフィールドである。
【１０１０】
num_component_descritporsフィールドは、component_descriptorフィールドの個数を示す。具体的な実施例において、num_component_descritporsフィールドは、例えば８ビットフィールドである。
【１０１１】
component_descriptorフィールドは、該当コンポーネントに関する付加的な属性を含むコンポーネント記述子を示す。
【１０１２】
ただし、このような場合、プログラムが含むセグメントに関する情報が分からない問題がある。これを解決するための方法を図９９〜図１００を参照して説明する。
【１０１３】
図９９および図１００は、本発明の他の実施例に係るプログラム情報ブロックを示す。
【１０１４】
本発明の他の実施例に係るプログラム情報ブロックは、プログラム情報ブロックがシグナリングするプログラムが含むセグメントの情報を含むことができる。具体的には、プログラム情報ブロックは、プログラム情報ブロックがシグナリングするプログラムが含むセグメントの数とセグメントの具体的な属性とを含むセグメント情報ブロックを含むことができる。
【１０１５】
プログラム情報ブロックは、具体的には、図９９および図１００のように、num_segmentフィールドおよびsegment_information_blockフィールドのうち少なくともいずれか１つを含むことができる。
【１０１６】
num_segmentフィールドは、プログラム情報ブロックがシグナリングするプログラムが含むセグメントの数を示す。具体的な実施例において、num_segmentフィールドは、例えば８ビットフィールドである。
【１０１７】
segment_infoamtion_blockフィールドは、図９２の実施例を参照して説明したセグメント情報ブロックまたは図１０１〜図１０２を参照して説明するセグメント情報ブロックを含むことができる。
【１０１８】
図９９の実施例では、プログラム情報ブロックがシグナリングするプログラムに関連したショーの情報が分からない。図７１の実施例では、図６８の実施例のように、プログラム情報ブロックがシグナリングするプログラムに関連したショーの情報を含んでいる。
【１０１９】
図９４〜図１００を参照して、プログラム情報およびプログラム情報ブロックに関してビットストリーム形態で説明したが、プログラム情報およびプログラム情報ブロックの形式は、ビットストリーム形式に制限されない。特にプログラム情報およびプログラム情報ブロックは、XMLファイル形式を有することができる。
【１０２０】
上述したように、放送サービスは複数のプログラムを含むことができる。このとき、プログラムは、複数のセグメントを含むことができる。セグメント(segment)は、プログラムを構成する時間区間である。セグメントは、プログラムの主なコンテンツ（本編）であるショー(show)を放送するショーセグメントと、プログラムの本編（主なコンテンツ）間に本編と関連のない内容を放送する中間(interstitial)セグメントと、を含むことができる（A segment may include a show segment broadcasting the primary content of a show and an interstitial segment broadcasting a content not relating to the primary content of the program between the primary contents of the program）。このとき、中間セグメントは、広告(ads)または公共（公益）広告(public service announcement)を含むことができる。ラジオサービスまたはTVサービスのショーセグメントおよび中間セグメントは、あらかじめ予定された(scheduled)開始時間および長さ(duration)を有することができる。
【１０２１】
セグメントは、セグメントを識別する固有な（一意の）識別子、該当セグメントの時間区間の間再生するメディアコンポーネントのリスト、セグメントの開始時間および長さ、セグメントの種類(type)、ターゲティング/個人化属性並びに視聴推奨等級のうち少なくともいずれか１つを属性として有することができる。セグメントの種類は、上述したように、ショーセグメントまたは中間セグメントのうちいずれか１つを含むことができる。このとき、セグメントの開始時間は、ショーの開始時間を基準とした相対時間を示すことができる。例えば、セグメントの開始時間は、ショー開始時間から１０分前などのように、ショーの開始時間を基準として指定されてもよい。anchoredセグメント(anchored segment)は、特定のプログラムと関連して開始時間が特定されたセグメントを示す。一方、unanchoredセグメント(unanchored segment)は、特定のプログラムと関連せず、開始時間が特定されていないセグメントを示す。例えば、放送受信装置１００が、ターゲティングされた(targeted)広告セグメントを受信したが、該当広告セグメントは、多様なプログラム/サービスなどで重複して使用されることがあるので、該当セグメントに対する開始時間を明示的に決めていない場合、ターゲティングされた広告は、unanchoredセグメントであるということができる。このようなセグメントを効率的にシグナリングする必要がある。セグメントをシグナリングすることに関しては、図１０１〜図１０５を参照して説明する。
【１０２２】
図１０１は、本発明の一実施例に係るセグメント情報を示す。
【１０２３】
セグメント情報は、具体的なセグメント属性を含むセグメントブロックを含むことができる。
【１０２４】
具体的な実施例において、図１０１の実施例のようにセグメント情報は、table_idフィールド、section_syntax_indicatorフィールド、private_indicatorフィールド、section_lengthフィールド、table_id_extentsionフィールド、version_numberフィールド、current_next_indicatorフィールド、section_numberフィールド、last_section_numberフィールドおよびsegment_information_blockフィールドのうち少なくともいずれか１つを含むことができる。
【１０２５】
table_idフィールドは、セグメント情報を含むことを示す。具体的な実施例において、table_idフィールドは、例えば８ビットフィールドである。
【１０２６】
section_syntax_indicatorフィールドは、放送サービスセグメント情報がMPEG-２TS標準のlong形式のprivate section tableであるか否かを示す。具体的な実施例において、Section_syntax_indicatorフィールドは、例えば１ビットフィールドである。
【１０２７】
private_indicatorフィールドは、現在のテーブルがprivate sectionに該当するか否かを示す。具体的な実施例において、Private_indicatorフィールドは、例えば１ビットフィールドである。
【１０２８】
section_lengthフィールドは、section_lengthフィールド以後に含まれたsectionの長さを示す。具体的な実施例において、Section_lengthフィールドは、例えば１２ビットフィールドである。
【１０２９】
table_id_extensionフィールドは、table_idフィールドと組み合わせてセグメント情報を識別する値を示す。具体的には、protocol_versionフィールドおよびsubnet_idフィールドのうち少なくともいずれか１つを含むことができる。protocol_versionフィールドは、セグメント情報のプロトコルバージョンを示す。具体的には、protocol_versionフィールドは、上位４ビットは主バージョンナンバを示し、下位４ビットは副バージョンナンバを示す８ビットフィールドである。subnet_idフィールドは、セグメント情報が放送ストリームを介して伝送される場合、セグメント情報を伝送するIPサブネット(subnet)を識別するサブネット識別子を示すことができる。また、他の具体的な実施例において、subnet_idフィールドの値は０である。インターネット網を介してセグメント情報が伝送される場合、subnet_idフィールドは、放送ストリームを介して伝送されるセグメント情報のsubnet_idフィールドと同一の値を有する。具体的な実施例において、subnet_idフィールドは、例えば８ビットフィールドである。
【１０３０】
version_numberフィールドは、セグメント情報のバージョンを示す。放送受信装置１００は、vserion_numberフィールドの値に基づいてセグメント情報を利用するか否かを決定することができる。具体的には、version_numberフィールドの値が以前に受信したサービスセグメント情報のバージョンと同一である場合、セグメント情報を利用しなくてもよい。具体的な実施例において、version_numberフィールドは、例えば５ビットフィールドである。
【１０３１】
current_next_indicatorフィールドは、セグメント情報が現在使用可能であるか否かを示す。具体的には、current_next_indicatorフィールドの値が１である場合、セグメント情報が使用可能であること示すことができる。また、current_next_indicatorフィールドの値が１である場合、セグメント情報を次に使用できることを示すことができる。具体的な実施例において、current_next_indicatorフィールドは、例えば１ビットフィールドである。
【１０３２】
section_numberフィールドは、現在のセクションの番号を示す。具体的な実施例において、section_numberフィールドは、例えば８ビットフィールドである。
【１０３３】
last_section_numberフィールドは、最後のセクションの番号を示す。セグメント情報テーブルの大きさが大きい場合、複数のセクションに分けて伝送することができる。このとき、放送受信装置１００は、section_numberフィールドおよびlast_section_numberフィールドに基づいてセグメント情報に必要なすべてのセクションが受信されたか否かを判断する。具体的な実施例において、last_section_numberフィールドは、例えば８ビットフィールドである。
【１０３４】
service_idフィールドは、セグメント情報に関連した放送サービスを識別するサービス識別子を示す。具体的には、service_idフィールドは、セグメント情報でシグナリングするセグメントを含む放送サービスを識別するサービス識別子を示すことができる。具体的な実施例において、service_idフィールドは、例えば８ビットフィールドである。
【１０３５】
program_information_blockフィールドは、セグメントの属性に関する情報を含むセグメント情報ブロックを示す。これに関しては、図１０２を参照して具体的に説明する。
【１０３６】
図１０２は、本発明の一実施例に係るセグメント情報ブロックを示す。
【１０３７】
セグメント情報が含むセグメント情報ブロックは、シグナリングするセグメントを識別するセグメント識別子、セグメントの種類(type)、セグメントに関連したプログラムがあるか否かを示す情報、セグメントの開始時間および長さが特定されているか否かを示す情報、セグメントに関連したプログラムを識別するプログラム識別子、セグメントの開始時間、セグメントが含むメディアコンポーネントの個数、該当メディアコンポーネントを識別するメディアコンポーネント識別子、該当メディアコンポーネントに関する属性を含む記述子の個数、該当メディアコンポーネントに関する属性を含む記述子、該当セグメントに関する属性を含む記述子の個数および該当セグメントに関する属性を含む記述子のうち少なくともいずれか１つを含むことができる。
【１０３８】
具体的な実施例において、セグメント情報は、図１０２の実施例のように、segment_idフィールド、segment_typeフィールド、associated_program_flagフィールド、time_includedフィールド、progmam_idフィールド、time_span_startフィールド、time_span_lengthフィールド、num_componentフィールド、component_idフィールド、num_component_descirtorsフィールド、component_descritporsフィールド、num_descritporフィールドおよびdescriptorフィールドのうち少なくともいずれか１つを含むことができる。
【１０３９】
segment_idフィールドは、該当セグメントを識別するセグメント識別子を示す。具体的な実施例において、Segment_idフィールドは、例えば８ビットフィールドである。
【１０４０】
segment_typeフィールドは、該当セグメントの種類を示す。具体的には、ショーセグメントまたは中間セグメントであるかを示すことができる。具体的な実施例において、Segment_typeフィールドの値が０x０２である場合、ショーセグメントを示し、segment_typeフィールドの値が０x０３から０x０７の間の値である場合、中間セグメントを示すことができる。具体的な実施例において、Segment_typeフィールドは、例えば３ビットフィールドである。
【１０４１】
associated_program_flagフィールドは、該当セグメントに関連したプログラムが存在するか否かを示す。具体的には、associated_program_flagフィールドの値が１である場合、該当セグメントに関連したプログラムがあることを示し、associated_program_flagフィールドの値が０である場合、該当セグメントに関連したプログラムがないことを示すことができる。具体的な実施例において、associated_program_flagフィールドは、例えば１ビットフィールドである。
【１０４２】
time_includedフィールドは、該当セグメントの開始時間および長さが特定されたか否かを示す。具体的には、time_includedフィールドの値が１である場合、該当セグメントの開始時間および長さが特定されたことを示し、time_includedフィールドの値が０である場合、該当セグメントの開始時間および長さが特定されていないことを示すことができる。具体的な実施例において、time_includedフィールドは、例えば１ビットフィールドである。
【１０４３】
progmam_idフィールドは、該当セグメントが関連したプログラムを識別するプログラム識別子を示す。具体的な実施例において、progmam_idフィールドは、例えば１６ビットフィールドである。
【１０４４】
time_span_startフィールドは、該当セグメントの開始時間を示す。具体的には、time_span_startフィールドは、１９８０年１月６日０時から経過したUTC時間を秒単位で示すことができる。具体的な実施例において、time_span_startフィールドは、例えば３２ビットフィールドである。
【１０４５】
time_span_lengthフィールドは、該当セグメントの長さを示す。具体的には、time_span_startフィールド値を基準として該当セグメントが放送される時間の長さを分単位で示すことができる。time_span_lengthフィールドの値が一度決まれば以後は変わらない。具体的な実施例において、time_span_lengthフィールドは、例えば１６ビットフィールドである。
【１０４６】
num_componentフィールドは、該当セグメントが含むメディアコンポーネントの個数を示す。具体的な実施例において、num_componentフィールドは、例えば８ビットフィールドである。
【１０４７】
component_idフィールドは、該当メディアコンポーネントを識別するコンポーネント識別子を示す。具体的な実施例において、component_idフィールドは、例えば８ビットフィールドである。
【１０４８】
num_component_descritporsフィールドは、component_descriptorフィールドの個数を示す。具体的な実施例において、num_component_descritporsフィールドは、例えば８ビットフィールドである。
【１０４９】
component_descriptorフィールドは、該当コンポーネントに関する付加的な属性を含むコンポーネント記述子を示す。
【１０５０】
num_descritporフィールドは、descriptorフィールドの個数を示す。具体的な実施例において、num_descritporフィールドは、例えば８ビットフィールドである。
【１０５１】
descriptorフィールドは、セグメントの付加的な属性を含む記述子を示す。例えば記述子は、推奨視聴等級およびターゲティング属性のうち少なくともいずれか１つを含むことができる。従って、descriptorフィールドは、例えばtargeting_descirptorである。
【１０５２】
プログラムを複数のセグメントに区分すれば、同じプログラムを視聴する視聴者であっても、それぞれの視聴者の特性に応じて異なるセグメントを提供することができる。特に、本編セグメントではない中間セグメントに、それぞれの視聴者特性に応じたセグメントを提供することができる。これによって、放送会社は、同じ内容の本編放送を提供しながらもそれぞれの視聴者たちの特性に応じたターゲット広告を視聴者たちに提供することができる。このためには、それぞれのセグメントのターゲティング情報および属性をシグナリングするターゲティングセグメントセットを提供する必要がある。これに関しては、図１０３を参照して説明する。
【１０５３】
図１０３は、本発明の一実施例に係るターゲティングセグメントセット(set)情報を示す。
【１０５４】
ターゲティングセグメントセットは、複数のセグメントに関するターゲティング情報をシグナリングすることができる。特に、ターゲティングセグメントセット情報は、同じ長さ(duration)を有する複数のセグメントに関するターゲティング情報をシグナリングすることができる。具体的な実施例において、ターゲティングセグメントセット情報は、同じプログラムに関連した複数のセグメントに関するターゲティング情報をシグナリングすることができる。また、他の具体的な実施例において、ターゲティングセグメント情報は、同じ開始時間を有する複数のセグメントに関するターゲティング情報をシグナリングすることができる。
【１０５５】
ターゲティングセグメントセット情報は、該当セグメントの開始時間、セグメントの長さ、ターゲティングセグメントセットが含むセグメントの個数、該当セグメントを識別するセグメント識別子、ターゲティングセグメントセット情報が含むターゲティング基準の個数、ターゲティング基準を識別するターゲティング識別子情報、ターゲティングの形態を示すターゲティング形態情報、具体的なターゲティング基準を示すターゲティング基準値情報のうち少なくともいずれか１つを含むことができる。
【１０５６】
具体的な実施例において、ターゲティングセグメントセット情報は、図１０３の実施例のように、descriptor_tagフィールド、descritpro_lengthフィールド、time_span_startフィールド、time_span_lengthフィールド、num_segmentフィールド、segment_idフィールド、num_targeting_criteriaフィールド、criterion_id_lengthフィールド、crerion_idフィールド、criterion_type_codeフィールド、num_criterion_valuesフィールド、criterion_value_lengthフィールドおよびcriterion_valueフィールドのうち少なくともいずれか１つを含むことができる。
【１０５７】
descriptor_tagフィールドは、ターゲティングセグメントセット情報を含むことを示す。具体的な実施例において、descriptor_tagフィールドは、例えば８ビットフィールドである。
【１０５８】
descriptor_lengthフィールドは、descriptor_tagフィールド以後のターゲティングセグメント情報の長さを示す。descriptor_lengthフィールドは、例えば８ビットフィールドである。
【１０５９】
time_span_startフィールドは、該当セグメントの開始時間を示す。具体的には、time_span_startフィールドは、１９８０年１月６日０時から経過したUTC時間を秒単位で示すことができる。具体的な実施例において、time_span_startフィールドは、例えば３２ビットフィールドである。
【１０６０】
time_span_lengthフィールドは、該当セグメントの長さを示す。具体的には、time_span_startフィールド値を基準として、該当セグメントが放送される時間の長さを分単位で示すことができる。time_span_lengthフィールドの値が一度決まれば以後は変わらない。具体的な実施例において、time_span_lengthフィールドは、例えば１６ビットフィールドである。
【１０６１】
num_segmentsフィールドは、ターゲティングセグメントセット情報がシグナリングするセグメントの個数を示す。具体的な実施例において、num_segmentsフィールドは、例えば８ビットフィールドである。
【１０６２】
num_targeting_criteriaフィールドは、ターゲティングセグメントセット情報の個数を示す。具体的な実施例において、放送サービスまたはメディアコンポーネントが有するターゲティング基準は、複数でもよい。具体的な実施例において、num_targeting_criteriaフィールドは、例えば８ビットフィールドである。
【１０６３】
criterion_id_lengthフィールドはcrerion_idフィールドの長さを示す。具体的な実施例において、criterion_id_lengthフィールドは、例えば８ビットフィールドである。
【１０６４】
crerion_idフィールドは、ターゲティング基準を識別するターゲティング基準識別子を示す。具体的な実施例において、crerion_idフィールドは、例えば８ビットフィールドである。
【１０６５】
criterion_type_codeフィールドは、ターゲティング基準の形態を示す。具体的な実施例において、criterion_type_codeフィールドは、例えば３ビットフィールドである。
【１０６６】
num_criterion_valuesフィールドは、ターゲティング基準値の個数を示す。具体的な実施例において、セグメントは、ターゲティング基準形態に該当する複数のターゲティング基準値を有することができる。具体的な実施例において、num_criterion_valuesフィールドは、例えば５ビットフィールドである。
【１０６７】
criterion_value_lengthフィールドは、criterion_valueフィールドの長さを示す。具体的な実施例において、criterion_value_lengthフィールドは、例えば８ビットフィールドである。
【１０６８】
criterion_valueフィールドは、ターゲティング基準値を示す。
【１０６９】
放送受信状況または放送受信装置１００の仕様などによって、特定セグメントの受信が不可能な場合、放送受信装置１００は、ターゲティングセグメントセット情報に基づいて他のセグメントを受信または再生することができる。例えば、放送受信装置１００が３Ｄ映像の再生をサポートしない場合、放送受信装置１００は、３Ｄ映像を含む１つのセグメントの代わりにターゲティングセグメントセットに基づいて２Ｄ映像を含むセグメントを受信または再生することができる。また、他の具体的な実施例において、放送受信装置１００は、ターゲティングセグメントセット情報に基づいてユーザに適合したコンテンツのみを選択的に（selectively）受信または再生することができる。例えば、視聴者が青少年である場合、放送受信装置１００は、成人対象映画の予告篇の代わりに青少年対象映画の予告篇を受信または再生することができる。
【１０７０】
図１０１〜図１０５を参照して、セグメント情報、セグメント情報ブロック、セグメントターゲティングセット情報がビットストリーム形式である場合を説明した。ただし、セグメント情報、セグメント情報ブロック、セグメントターゲティングセット情報の形式は、ビットストリーム形式に制限されない。特に、セグメント情報、セグメント情報ブロック、セグメントターゲティングセット情報は、XMLファイル形式を有することができる。また、具体的な実施例において、前述したプログラム情報は、セグメント情報、セグメント情報ブロックおよびセグメントターゲティングセット情報を含むことができる。
【１０７１】
プログラムの属性およびセグメントの属性を伝送・受信する放送伝送装置および放送受信装置１００の動作に関しては、図１０４〜図１０５を参照して説明する。
【１０７２】
図１０４は、本発明の一実施例に係る放送伝送装置がプログラム情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を伝送することを示す。
【１０７３】
放送伝送装置は、制御部を介して放送サービスが含むプログラムの属性を獲得する(S８０１)。プログラムの属性は、上述したように、固有な（一意の）識別子、プログラムに含まれたメディアコンポーネントのリスト、プログラムの開始時間および長さ、タイトルおよびプログラムを説明するテキスト、グラフィックアイコン、視聴推奨等級、ターゲティング/個人化属性並びにコンテンツ保護属性のうち少なくともいずれか１つを含むことができる。
【１０７４】
放送伝送装置は、制御部を介してプログラムの属性に基づいてプログラムをシグナリングするプログラム情報を生成する(S８０３)。プログラム情報は、図１０４〜図１０５を参照して説明したプログラム情報とプログラム情報ブロックのうち少なくともいずれか１つを含むことができる。
【１０７５】
放送伝送装置は、制御部を介してプログラムが含むセグメントの属性を獲得する(S８０５)。セグメントの属性は、上述したように、セグメントを識別する固有な（一意の）識別子、該当セグメントの時間区間の間再生するメディアコンポーネントのリスト、セグメントの開始時間および長さ、セグメントの種類(type)、ターゲティング/個人化属性および視聴推奨等級のうち少なくともいずれか１つを含むことができる。
【１０７６】
放送伝送装置は、制御部を介してセグメントの属性に基づいてセグメント情報を生成する(S８０７)。セグメント情報は、前述した図１０１〜図１０５のセグメント情報、セグメント情報ブロック、セグメントターゲティングセット情報のうち少なくとも１つを含むことができる。
【１０７７】
放送伝送装置は、伝送部を介してセグメント情報およびプログラム情報のうち少なくともいずれか１つを含む放送信号を伝送する(S８０９)。
【１０７８】
図１０５は、本発明の一実施例に係る放送受信装置がプログラム情報およびセグメント情報のうち少なくともいずれか１つを含む放送信号を受信することを示す。
【１０７９】
放送受信装置１００は、放送受信部１１０を介して放送信号を受信する(S９０１)。
【１０８０】
放送受信装置１００は、制御部１５０を介して放送信号に基づいてプログラム情報を獲得する(S９０３)。具体的には、放送受信装置１００は、放送信号からプログラム情報を獲得することができる。このとき、プログラム情報は、図１０７〜図１０８を参照して説明したプログラム情報およびプログラム情報ブロックのうち少なくともいずれか１つを含むことができる。
【１０８１】
放送受信装置１００は、制御部１５０を介してプログラム情報に基づいてプログラムの属性を獲得する(S９０５)。プログラムの属性は、上述したように、固有な（一意の）識別子、プログラムに含まれたメディアコンポーネントのリスト、プログラムの開始時間および長さ、タイトルおよびプログラムを説明するテキスト、グラフィックアイコン、視聴推奨等級、ターゲティング/個人化属性並びにコンテンツ保護属性のうち少なくともいずれか１つを含むことができる。
【１０８２】
放送受信装置１００は、制御部１５０を介して放送信号に基づいてセグメント情報を獲得する(S９０７)。具体的には、放送受信装置１００は、放送信号からセグメント情報を獲得することができる。セグメント情報は、前述した図１１１〜図１１４のセグメント情報、セグメント情報ブロック、セグメントターゲティングセット情報のうち少なくとも１つを含むことができる。
【１０８３】
放送受信装置１００は、制御部１５０を介してセグメント情報に基づいてセグメントの属性を獲得する(S９０９)。セグメント情報は、前述した図１１１〜図１１３のセグメント情報、セグメント情報ブロック、セグメントターゲティングセット情報のうち少なくとも１つを含むことができる。
【１０８４】
放送受信装置１００は、プログラムの属性およびセグメント属性のうち少なくともいずれか１つに基づいてプログラムの属性を表示するサービスガイドを生成する(S９１１)。具体的な実施例において、サービスガイドは、プログラムが含むセグメントの属性も一緒に表示することができる。具体的には、サービスガイドは、プログラムが含むショーセグメントの属性を一緒に表示することができる。例えば、サービスガイドは、プログラム属性の他に、プログラムが含むショーセグメントの開始時間および長さと同一のショーセグメントを含む他のプログラム情報とを一緒に表示することができる（a service guide may display the start time and length of a show segment in a program and another program information including the same show segment in addition to a program property）。
【１０８５】
上述したように、本発明の一実施例に係る放送サービスは、ますます複雑かつ多様化する放送サービスの形態を効果的にシグナリングするために、メディアコンポーネントの属性を細分化し、放送サービスの時間区間を示すプログラムをセグメントに再細分化した。これを図１０６〜図１１０を介して詳しく説明する。
【１０８６】
図１０６は、本発明の一実施例に係る放送サービスの種類に応じた下位属性との継承関係を示す。
【１０８７】
本発明の一実施例に係る放送サービスは、一種のクラス、クラス間の継承関係(inheritance relationship)、クラス間の包含関係(containment relationship)およびクラス間の他の関連性(association)を含むオブジェクトモデルとして説明することができる。
【１０８８】
連続コンポーネントクラスは、連続コンポーネントを示す。連続コンポーネントクラスは、コンポーネントを識別するコンポーネント識別子(componentID)を属性として含むことができる。
【１０８９】
オーディオコンポーネントクラスは、コンテンツの種類(type)がオーディオである連続コンポーネントを示す。オーディオコンポーネントクラスは、「連続コンポーネントクラスとの下位クラス関係(Sub-class relationship with Continuous Compeonet class」を関係として含むことができる。
【１０９０】
ビデオコンポーネントクラスは、コンテンツの種類がビデオである連続コンポーネントを示す。ビデオコンポーネントクラスは、「連続コンポーネントクラスとの下位クラス関係(Sub-class relationship with Continuous Compeonet class」を関係として含むことができる。
【１０９１】
字幕(closed caption)コンポーネントクラスは、コンテンツの種類が字幕である連続コンポーネントを示す。字幕コンポーネントクラスは、「連続コンポーネントクラスとの下位クラス関係(Sub-class relationship with Continuous Compeonet class」を関係として含むことができる。
【１０９２】
基礎(elementary)オーディオコンポーネントクラスは、コンテンツ形態がオーディオである基礎コンポーネントを示す。基礎オーディオコンポーネントクラスは、コーデック、オーディオチャネルの数、エンコーディングビットレート、他のエンコーディングパラメータ、オーディオコンポーネントの言語およびモードのうち少なくともいずれか１つを含むことができる。具体的には、他のエンコーディングパラメータは、コーデックによって決められる。また、モードは、該当オーディオのモード(mode)を示し、「完全なメイン(complete main)」、「音楽」、「対話(dialog)」、「効果音(effects)」、「視聴覚障害者のためのオーディオ(visual impaired)」、「聴覚障害者のためのオーディオ(hearing impaired)」および「コメント」のうち少なくともいずれか１つであることを示すことができる。オーディオコンポーネントクラスは、「オーディオコンポーネントクラスとの下位クラス関係(Sub-class relationship with Continuous Compeonet class」を関係として含むことができる。
【１０９３】
基礎ビデオコンポーネントクラスは、コンテンツ形態がビデオである基礎コンポーネント示す。基礎ビデオコンポーネントクラスは、「コーデック」、「解像度(resolution)」、「画面比率(aspect ratio)」、「スキャン方式」、「フレームレート」、「静止画像モード」および「他のエンコーディングパラメータ」のうち少なくともいずれか１つを含むことができる。解像度は、横x縦のピクセル単位で示すことができる。また、スキャン方式は、インターレースおよびプログレッシブのうちいずれか１つを含むことができる。また、他のエンコーディングパラメータは、コーデックによって決定することができる。基礎ビデオコンポーネントクラスは、「ビデオコンポーネントクラスとの下位クラス関係(Sub-class relationship with Continuous Compeonet class」を関係として含むことができる。
【１０９４】
基礎字幕クラスは、コンテンツ形態が字幕である基礎コンポーネントを示す。基礎字幕クラスは、「コーデック」、「言語」および「種類」のうち少なくともいずれか１つを含むことができる。このとき、コーデックは、字幕テキストの形式を示すことができる。言語は、字幕を構成する言語を示す。種類は一般的な字幕と低視力者のための大きな文字の字幕(easy-reader)とのいずれか１つを含むことができる。基礎字幕コンポーネントクラスは、「字幕コンポーネントクラスとの下位クラス関係(Sub-class relationship with Continuous Compeonet class」を関係として含むことができる。
【１０９５】
コンプレックスコンポーネントクラスは、コンプレックスコンポーネントを示す。
【１０９６】
コンポジットオーディオコンポーネントクラスは、コンテンツの種類がオーディオであるコンポジットコンポーネントを示す。コンポジットオーディオコンポーネントクラスは、関係(relationship)として「Contains Audio」および「オーディオコンポーネントクラスとの下位クラス関係(Sub-class relationship with Audio Component Class)」のうち少なくともいずれか１つを含むことができる。このとき、「Contains Audio」は、コンポジットオーディオクラスが含むオーディオコンポーネントクラスを示す。このとき、「Contains Audio」に含まれるオブジェクト（個体）(object)は、全部１つの音響シーン(sound scene)を示すように制限される。
【１０９７】
コンポジットビデオコンポーネントクラスは、コンテンツの種類がビデオであるコンポジットコンポーネントを示す。コンポジットビデオコンポーネントクラスは、関係(relationship)として「ContainsVideo」および「ビデオコンポーネントクラスとの下位クラス関係(Sub-class relationship with Video Component Class)」のうち少なくともいずれか１つを含むことができる。このとき、ContainsVideoは、コンポジットビデオコンポーネントクラスのビデオコンポーネントクラスとの下位クラス関係(sub-class relationship)を示す。このとき、ContainsVideoに含まれるオブジェクトは、全部１つの映像シーン(video scene)を示すように制限される。また、ContainsVideo関係の属性は、「役割(role)」を含むことができる。このとき、役割は、スケーラブルビデオのenhanced層を示すことができる。また、役割は、３Ｄ映像の左側映像または右側映像を示すことができる。また、役割（ロール）は、３Ｄ映像の深さ(depth)情報を示すことができる。また、役割は、複数の画面に分割されるビデオ行列(array)の一部(part)を示すことができる。この場合、ロールは、nxmの行列がある場合、左側からx番目のy列に該当することを示すことができる。また、ロールは、フォローサブジェクトメタデータ(Follow-subject metadata)を示すことができる。
【１０９８】
PickOneコンポーネントクラスは、PickOneコンポーネントを示す。PickOneコンポーネントは、関係として「contains」および「連続コンポーネントクラスとの下位クラス関係(Sub-class relationship with Continuous Component Class)」のうち少なくともいずれか１つを含むことができる。このとき、「contains」は、PickOneコンポーネントクラスの連続コンポーネントクラスとの関係を示す。このとき、「contains」に含まれるコンポーネントは、全て同一のコンテンツの種類であり、全部同じ映像シーンまたはオーディオシーンを示すように制限される。
【１０９９】
presentableコンポーネントクラスは、presentableコンポーネントを示す。presentableコンポーネントクラスは、ターゲティング/個人化属性、推奨コンテンツ等級(content advisory rating)、コンテンツ/サービス保護属性およびターゲットデバイスのうち少なくともいずれか１つを属性として含むことができる。このとき、ターゲットデバイスは、主(primary)スクリーン、連動(companion)スクリーンおよび主スクリーンにその一部として挿入される(inset)スクリーンのうちいずれか１つを含むことができる。
【１１００】
presentableビデオコンポーネントクラスは、presentableビデオコンポーネントを示す。presentableビデオコンポーネントクラスは、「Associated Audio」、「Associated CC」および「ビデオコンポーネントクラスとの下位クラス関係(Sub-class relationship with Audio Component Class)」のうち少なくともいずれか１つを関係として含むことができる。「Associated Audio」は、presentableビデオコンポーネントと一緒に再生することに適合したpresentableオーディオコンポーネントを示すことができる。
【１１０１】
presentableオーディオコンポーネントクラスは、presentableオーディオコンポーネントを示す。presentableオーディオコンポーネントクラスは、オーディオコンポーネントクラスとの下位クラス関係(Sub-class relationship with Audio Component Class)を関係として含むことができる。
【１１０２】
presentable字幕コンポーネントクラスは、presentable字幕コンポーネントを示す。presentable字幕コンポーネントクラスは、字幕コンポーネントクラスとの下位クラス関係(Sub-class relationship with Audio Component Class)を関係として含むことができる。
【１１０３】
データアイテムコンポーネントクラスは、NRTデータサービスのコンテンツアイテムを示す。データアイテムコンポーネントクラスは、コンテンツアイテムを識別するコンテンツアイテム識別子(ContentItemID)、コンテンツアイテムの名前(ContentItemName)、コンテンツアイテムのアップデートがモニタリングされるべきであるか否かを示す表示（display for representing whether the update of a content item is to be monitored）(Updateable)、ダウンロード可能時間を示すダウンロード可能ウインドウ（a download available window representing a download available time）(Avaiblewindow)、コンテンツアイテムが廃棄(discard)される時間を示す満了日(Expiration)、コンテンツアイテムの大きさ(ContentItemSize)、コンテンツアイテムの再生の長さ(PlaybackLength)、ターゲティング/個人化属性(TargetInfo)、コンテンツアイテムの保護属性(ProtectionInfo)およびコンテンツアイテムのコンテンツ推奨等級(ContentAdvRating)のうち少なくともいずれか１つを属性として含むことができる。
【１１０４】
サービスクラスは、サービスを示す。サービスクラスは、サービス識別子(ServiceId)、サービスの名前(ServiceName)、チャネル番号(ChanNum)、サービスに関する説明(Description)、サービスを示すグラフィックアイコン(Icon)、サービスに含まれたメディアコンポーネントのリスト、放送サービス保護に関する属性(Content/service protection properties for the service)、ターゲティング/個人化に関する属性(targeting properties for the service)、視聴推奨等級(contentAdvRating)、サービスの言語(Language)および放送サービスユーザ報告(UsageReportInfo)に関する属性のうち少なくともいずれか１つを属性として含むことができる。このとき、チャネル番号は、主番号(MajorChanNum)と副番号(MinorChanNum)とに分けることができる。
【１１０５】
ラジオサービスクラスは、決まった時間に放送される(scheduled)ラジオサービスを示す。ラジオサービスクラスは、「presentableビデオコンポーネントクラスとの包含関係(Containment Relationship with Presentable Video Component Class)」、「presentable字幕コンポーネントクラスとの包含関係(Containment Relationship with Presentable CC Component Class)」、「NRTデータクラスとの付加（アジャンクト）関係(Adjunct relationship with NRT Data Service Class)」のうち少なくともいずれか１つを関係として含むことができる。
【１１０６】
TVサービスクラスは、決まった時間に放送される(scheduled)TVサービスを示す。TVサービスクラスは、「presentableビデオコンポーネントクラスとの包含関係(Containment Relationship with Presentable Video Component Class)」、「presentableオーディオコンポーネントクラスとの包含関係(Containment Relationship with Presentable Audio Component Class)」、「presentable字幕コンポーネントクラスとの包含関係(Containment Relationship with Presentable CC Component Class)」、「NRTデータクラスとの付加関係(Adjunct relationship with NRT Data Service Class)」のうち少なくともいずれか１つを関係として含むことができる。「presentableビデオコンポーネントクラスとの包含関係」は、ビデオコンポーネントの役割を属性として含む。具体的には、ビデオコンポーネントの役割は、主ビデオ（primary video）、代替視点画面(Alternative camera view)、他の代替ビデオコンポーネント、手話画面、フォローサブジェクトビデオ(Follow Subject Video)/メタデータのいずれか１つを示すことができる。特に、フォローサブジェクトビデオ/メタデータは、フォローするオブジェクト(subject that follows)の名前を含むことができる。このようなフォローサブジェクトビデオは、ビデオストリームを含むことができる。またはフォローサブジェクトビデオは、ビデオストリームのオブジェクト(subject)の拡大(zoom-in)のための各フレームの四角形であってもよい。
【１１０７】
ユーザ要求(OnDemand)サービスクラスは、ユーザ要求コンテンツサービスを示す。ユーザ要求サービスクラスは、「ユーザ要求UIアプリクラスとの包含(Containment relationship with OnDemand UI App Class)」、「使用要求オファリングクラスとの包含関係(Containment relationship with OnDemand Offering Class)」および「ユーザ要求カタログクラスとの包含関係(containment relationship with OnDemand Catalog class)」を関係として含むことができる。「ユーザ要求UIアプリクラスとの包含関係(Containment relationship with OnDemand UI App Class)」は、ユーザ要求サービスに関するユーザインターフェース提供のためのものである。具体的な実施例において、ユーザ要求サービスのユーザインターフェースは、複数の言語で提供される。ユーザ要求オファリングは、ユーザ要求によって提供されるサービスの商品を示すことができる。使用要求オファリングクラスとの包含関係(Containment relationship with OnDemand Offering Class)」は、ユーザ要求サービスで提供されるコンテンツアイテムに対するものである。「ユーザ要求カタログクラスとの包含関係(containment relationship with OnDemand Catalog class)」は、ユーザ要求サービスのユーザ要求オファリングカタログのためのものである（for an OnDemand offering catalog of an OnDemand service）。具体的な実施例において、ユーザ要求オファリングカタログは、複数の言語で提供される。
【１１０８】
NRTデータサービスクラスは、NRTデータサービスを示す。NRTデータサービスクラスは、「消費モデル(Consumption Mode)」、「必須機器性能(Essential capabilities)」、「非必須機器性能(Non-essential capabilities)」、「ターゲットデバイス(Target Device)」および「データアイテムコンポーネントクラスとの包含関係を含む関係」のうち少なくともいずれか１つを属性として含むことができる。「必須機器性能(Essential capabilities)」は、放送受信装置１００がサービスを受信するために必要な性能を示す。「非必須機器性能(Non-essential capabilities)」は、放送受信装置１００がサービスの選択事項（service's selection item）を受信するために必要な性能を示す。「ターゲットデバイス(Target Device)」は、主デバイスまたは連動デバイスのうちいずれか１つを示すことができる。
【１１０９】
プログラムクラスは、プログラムを示す。プログラムクラスは、プログラムを識別するプログラム識別子(ProgamIdentifier)、プログラムの開始時間(StartTime)、プログラムの長さ(ProgramDuration)、プログラムのタイトル(TextualTitle)、プログラムを説明するテキスト(TextualTitle)、プログラムのジャンル(Genre)、プログラムを示すグラフィックアイコン(GraphhicalIcon)、視聴推奨等級(ContentAdvisoryRating)、ターゲティング/個人化属性(Targeting/personalization properties)およびプログラムのコンテンツ/サービス保護を示すコンテンツ/サービス保護属性(Content/Service protection properties)のうち少なくともいずれか１つを属性として含むことができる。プログラムの開始時間は、プログラムが始まる日付および時間を含むことができる。プログラムの長さは、プログラムが始まる時間から終了する時間までの長さである。プログラムのタイトルは、複数の言語で表示される。また、プログラムのタイトルがない場合、映像表示装置１００は、プログラムのタイトルに関連したショーのタイトルを表示することができる。また、プログラムのジャンルがない場合、映像表示装置１００は、プログラムのジャンルに関連したショーのジャンルを表示することができる。また、グラフィックアイコンは、複数のサイズで表示することができる。プログラムのグラフィックアイコンがない場合、映像表示装置１００は、関連したショーのグラフィックアイコンをプログラムのアイコンとして表示することができる。視聴推奨等級は、地域別に異なってもよく、視聴推奨等級は、地域別に異なる複数の視聴推奨等級の値を含むことができる。また、プログラム（プロックレム）の視聴推奨等級が存在しない場合、放送受信装置１００は、プログラムに関連したショーの視聴推奨等級を視聴推奨等級として表示することができる。ターゲティング/個人化属性が存在しない場合、放送受信装置１００は、関連したショーのターゲティング/個人化属性を表示することができる。コンテンツ/サービス保護属性が存在しない場合、放送受信装置１００は、関連したショーのコンテンツ/サービス保護属性を表示することができる。ラジオプログラムクラスは、ラジオプログラムを示す。ラジオプログラムクラスは、「presentableオーディオコンポーネントクラスとの包含関係(Containment relationship with Presentable Audio Component class)」、「presentable字幕コンポーネントクラスとの包含関係(Containment relationship with Presentable CC Component class)」、「NRTデータサービスクラスとの付加関係(Adjunct relationship with NRT Data Service class)」および「ラジオセグメントクラスとの包含関係(Containment relationship with Radio Segment Class)」のうち少なくともいずれか１つを関係として含むことができる。また、ラジオプログラムクラスは、ラジオセグメントの開始時間を属性として含むことができる。このとき、ラジオセグメントの開始時間は、プログラムの開始時間を基準とした相対時間である。
【１１１０】
テレビ番組クラスは、テレビ番組を示すことができる。presentableビデオコンポーネントクラスは、「presentableビデオコンポーネントクラスとの包含関係(Containment relationship with Presentable Video Component Class)」を関係として含むことができる。「presentableビデオコンポーネントクラスとの包含関係」は、ビデオコンポーネントの役割(role)、presentableオーディオコンポーネントクラスとの包含関係、presentable字幕コンポーネントクラスとの包含関係、NRTデータサービスクラスとの付加関係、TVショークラスとの関係およびTVセグメントクラスとの包含関係のうち少なくともいずれか１つを属性として含むことができる。ビデオコンポーネントとして役割は、主(primary)ビデオ、代替視点画面、他の代替ビデオコンポーネント、手話(Sign language)画面(inset)、フォローオするブジェクトの名前を含むフォローサブジェクトビデオのうちいずれか１つを示すことができる。フォローサブジェクトビデオは、フォローサブジェクトに分離されたビデオコンポーネントによってサポート可能である。TVセグメントクラスとの包含関係は、セグメント開始時間(RelativeSegmentStartTime)を含むことができる。このとき、セグメント開始時間は、プログラムの開始を基準とした相対時間である。
【１１１１】
ショークラスはショーを示す。このとき、ショーは上述したように、プログラムの主な(primary)コンテンツを示すことができる。特に、ショーは視聴者の観点で主なコンテンツを示すことができる。ショークラスは、「ショー識別子(ShowIdentifier)」、「ショーの長さ(ShowDuration)」、ショーに対する「テキスト説明(TextualDescription)」、ショーの「ジャンル(Genre)」、ショーを示す「グラフィックアイコン(GraphicalIcon)」、「コンテンツ推奨等級(ContentAdvisoryRating)」、「ターゲティング/個人化属性(Targeting/personalization properties」および「コンテンツ/サービス保護属性(Content/Service protection properties)」のうち少なくともいずれか１つを属性として含むことができる。
【１１１２】
TVショークラスは、テレビ番組の主コンテンツを示す。TVショークラスは、「TVショーセグメントクラスとの包含関係(Containment relationship with TV Show Segment class)」を関係として含むことができる。
【１１１３】
セグメントクラスは、セグメントを示すことができる。セグメントクラスは、セグメントを識別する「セグメント識別子(SegmentId)」、セグメントの「長さ(Duration)」、「ターゲティング/個人化属性(Targeting/personalization properties)」および「コンテンツ推奨等級(Content advisory rating)」のうち少なくともいずれか１つを含むことができる。
【１１１４】
ラジオセグメントクラスは、ラジオプログラムのセグメントを示す。
【１１１５】
TVセグメントクラスは、テレビ番組のセグメントを示す。
【１１１６】
ラジオショーセグメントクラスは、ラジオショーのセグメントを示す。ラジオショーセグメントクラスは、「ショーセグメントの開始時間(ShowSegmentRelativeStartTime)」を属性として含むことができる。具体的には、ショーセグメントの開始時間は、ラジオプログラムを基準とした相対時間である。
【１１１７】
TVショーセグメントクラスは、テレビ番組メインコンテンツを含むショーセグメントを示す。TVショーセグメントクラスは、「ショーセグメントの開始時間(ShowSegmentRelativeStartTime)」を属性として含むことができる。具体的には、ショーセグメントの開始時間は、テレビ番組を基準とした相対時間である。
【１１１８】
ラジオ中間（隙間）セグメントクラス(Radio Interstitial Segment)は、ラジオプログラムのショーセグメントではないセグメントを示す。
【１１１９】
TV中間セグメントクラス(TV Interstitial Segment)は、テレビ番組のショーセグメントではないセグメントを示す。
【１１２０】
ユーザ要求UIアプリクラス(OnDemand UI App class)は、ユーザ要求サービスのためのユーザインターフェースを提供するアプリケーションを示す。
【１１２１】
ユーザ要求オファリングクラス(OnDemand Offering class)は、ユーザ要求サービスのオファリング（提供、オファー）を示す。
【１１２２】
ユーザ要求カタログクラス(OnDemand Catalog class)は、ユーザ要求サービスのオファリングに関する説明を示す。このとき、オファリングはユーザ要求によって提供されるサービス商品を示すことができる。ユーザ要求カタログクラスは、「ユーザ要求オファリングクラスとの関係」を関係として含むことができる。
【１１２３】
図１０６では、前述した他の種類のサービス、それぞれのサービスに含まれる他の種類のコンポーネント、および各サービス間の付加サービス関係を示す。ラジオサービスは、１つまたは複数のpresentableオーディオコンポーネントを含む。また、ラジオコンポーネントは、１つまたは複数の字幕コンポーネントを含むことができる。また、ラジオコンポーネントは、１つまたは複数の付加NRTデータサービスを含むことができる。TVサービスは、１つまたは複数のpresentableビデオコンポーネントを含む。また、TVサービスは、１つまたは複数のpresentableオーディオコンポーネントを含むことができる。また、TVサービスは、１つまたは複数のpresentable字幕コンポーネントを含むことができる。また、TVサービスは、１つまたは複数の付加NRTデータサービスを含むことができる。NRTデータサービスは、１つまたは複数のpresentableデータアイテムコンポーネントを含む。また、NRTデータサービスは、スタンドアローンデータサービスからなることができる。また、NRTデータサービスは、ラジオサービスまたはTVサービスサービスの付加データサービスからなることができる。また、NRTデータサービスは、ユーザ要求サービスのプログラムまたは他のNRTデータサービスを介して伝送されるプログラムの付加サービスからなることができる。ユーザ要求サービスは、１つまたは複数のユーザ要求オファリングを含む。また、ユーザ要求サービスは、オファリングを説明する１つまたは複数のカタログを含むことができる。また、ユーザ要求サービスは、サービスのユーザインターフェースを提供するUIアプリサービスからなることができる。このとき、ユーザインターフェースは、サービス提供者によってカスタマイズされる。また、ユーザインターフェースは、ユーザによってカスタマイズされる。
【１１２４】
図１０７は、本発明の一実施例に係る連続コンポーネントと連続コンポーネントの下位属性を有するコンポーネントとの継承関係を示す。
【１１２５】
図１０７の実施例のように、連続コンポーネントは、基礎コンポーネントまたはコンプレックスコンポーネントを含むことができる。基礎コンポーネントは、基礎ビデオコンポーネント、基礎オーディオコンポーネントまたは基礎字幕コンポーネントを含むことができる。コンプレックスコンポーネントは、PickOneコンポーネントまたはコンポジットコンポーネントを含むことができる。コンポーネント間の「関係」を定義する目的は、コンポジットオーディオとコンポジットビデオとを区別することが重要であるからである。これは、コンポジットビデオコンポーネントの場合、コンポジットコンポーネントの構成(member)コンポーネントの役割(role)に応じて別途に表示しなければならないからである。したがって、コンプレックスコンポーネントは、コンポジットオーディオコンポーネントまたはコンポジットビデオコンポーネントの役割の属性を示す複数の「関係」を含むことができる。
【１１２６】
図１０８は、本発明の一実施例に係るpresentableコンポーネントとpresentableコンポーネントの下位属性を有するコンポーネントとの継承関係を示す。
【１１２７】
presentableコンポーネントは上述したように、presentableビデオコンポーネント、presentableオーディオコンポーネントおよびpresentable字幕コンポーネントのうちいずれか１つを含むことができる。TVサービスのpresentableビデオコンポーネントは、１つまたは複数の関連したpresentableオーディオコンポーネントを有することができる。また、TVサービスのpresentableビデオコンポーネントは、１つまたは複数の関連したpresentable字幕コンポーネントを有することができる。このとき、関連したpresentableオーディオコンポーネントとpresentable字幕コンポーネントとは、presentableビデオコンポーネントと一緒に再生可能であることを意味する。TVサービスは、ビデオコンポーネントを含むサービスであるので、TVサービスのpresentableオーディオコンポーネントとpresentable字幕コンポーネントは、presentableビデオコンポーネントと関連する必要がある。
【１１２８】
図１０９は、本発明の一実施例に係るサービスとサービスに含まれたプログラムとプログラムに含まれたセグメントとの関係を示す。
【１１２９】
ラジオサービスは、１つまたは複数のラジオプログラムを含むことができる。ラジオプログラムは、１つまたは複数のラジオサービスに含まれてもよい。ラジオプログラムは、NRTデータサービスコンテンツアイテムまたはユーザ要求サービスのオファリングからなることができる。ラジオプログラムは、１つまたは複数のラジオセグメントを含むことができる。このとき、ラジオセグメントは、ラジオ中間セグメントからなることができる。ラジオセグメントは、１つまたは複数のラジオプログラムに含まれてもよい。それぞれのラジオセグメントは、ラジオショーセグメントまたはラジオ中間(interstitial)セグメントからなることができる。ラジオプログラムは、１つの「ラジオショー」からなることができる。このとき、「ラジオショー」は、サービス提供者によって中間(interstitial)コンテンツと見なされないものである。ラジオショーは、１つまたは複数のラジオショーセグメントを含むことができる。このようなラジオサービス、ラジオプログラム、ラジオセグメント、ラジオショーの関係は、TVサービス、テレビ番組、TVセグメント、TVショーの関係と類似するように適用することができる。
【１１３０】
図１１０は、presentableオーディオコンポーネントの階層構造を示す。
【１１３１】
連続コンポーネントは、３つのレベルの階層構造(three level hierarchies)に分けることができる。最上位レベル(top level)はPickOneコンポーネントであり、中間レベル(middle level)はコンポジットコンポーネントを含み、最下位レベル(bottom level)はPickOneコンポーネントを含むことができる。すべての連続コンポーネントは、このような３つのレベルを含むことができる。ただし、連続コンポーネントは、下位レベルを含まない簡単な基礎コンポーネントであってもよい。具体的な実施例において、図１１０のようにpresentableオーディオコンポーネントは、PickOneコンポーネントを含むことができる。このとき、PickOneコンポーネントは完全なメインオーディオ(complete main audio)のコンポーネントと、完全なメイン音楽とミックス可能な音楽、対話および効果音を含むコンポーネントと、を含むことができる。このとき、完全なメインオーディオであるコンポーネントは、相互に異なるビットレートでエンコーディングされた代替可能な複数の基礎(elementary)コンポーネントを含むPickOneコンポーネントを含むことができる。完全なメイン音楽とミックス可能な音楽、対話および効果音を含むコンポーネントは、音楽、対話および効果音がそれぞれ１つのコンポーネントであるコンポジットコンポーネントを含むことができる。このとき、対話を含むコンポーネントおよび効果音を含むコンポーネントは、基礎コンポーネントを含むことができる。音楽コンポーネントは、相互に異なるビットレートでエンコーディングされた代替可能な複数の基礎(elementary)コンポーネントを含むPickOneコンポーネントを含むことができる。
【１１３２】
従来の放送網を介した放送は、１つの放送が連続して放送される線形的(linear)なサービスであった。従来の放送網を介した放送がハイブリッド放送に変わることにより、従来のリニアサービスとアプリベースのサービス(App-based Service)とに放送サービスを分けることができる。
【１１３３】
リニアサービスは、決まったスケジュールに応じて連続コンポーネントが再生(presented)されるサービスである。このとき、リニアサービスは、放送局で決めた時間に基づいたものを含むことができる。また、リニアサービスは、放送サービスと同期化されるようにtriggeredアプリケーションを含むことができる。
【１１３４】
具体的には、リニアサービスは、１つまたは複数のビデオコンポーネントを含むことができる。
【１１３５】
また、リニアサービスは、１つまたは複数のオーディオコンポーネントを含むことができる。また、リニアサービスは、１つまたは複数の字幕コンポーネントを含むことができる。
【１１３６】
また、リニアサービスは、コンポーネントおよび付加サービスのうち少なくともいずれか１つとの同期化の基準となるタイムベースコンポーネント(time base component)を含むことができる。
【１１３７】
また、リニアサービスは、１つまたは複数のTriggeredアプリベース付加サービスをコンポーネント(triggered、app based enhancements)として含むことができる。それぞれの付加サービスは、１つまたは複数のアプリケーションを含むことができる。このとき、アプリケーションは、実行（アクティベーション）通知(activation notification)と同期化されて実行されてもよい。アプリベース付加サービスコンポーネントは、一連の実行通知を含むことができる。また、アプリベース付加サービスコンポーネントは、１つまたは複数のコンテンツアイテムを含むことができる。
【１１３８】
また、リニアサービスは、１つまたは複数の自動起動アプリケーションベースの付加サービス(auto-launch app-based enhancements)をコンポーネントとして含むことができる。それぞれの付加サービスは、サービスが選択されると、自動起動されるアプリケーションを含むことができる。自動起動アプリケーションベースの付加サービスは、自動起動されるアプリケーションをコンポーネントとして含む。また、１つまたは複数のコンテンツアイテムをコンポーネントとして含むことができる。
【１１３９】
リニアサービスは、自動起動アプリケーションベースの付加サービスとTriggeredアプリベース付加サービスとを同時にコンポーネントとして含むことができる。具体的な実施例において、自動起動ベースアプリ付加サービスは、ターゲット広告として挿入され（inserted as a target advertisement）、Triggeredアプリベース付加サービスは、ユーザに双方向視聴経験(interactive viewing experience)を提供することができる。
【１１４０】
アプリベースサービスは、サービスが選択されると、指定されたアプリケーションが実行される。このとき、サービスは、自動起動されるアプリケーションを属性として含むことができる。また、アプリベースサービスは、１つまたは複数のコンテンツアイテムを属性として含むことができる。
【１１４１】
サービスのコンポーネントは、相互に異なる複数のコンポーネント間で共有することができる。また、アプリベースサービスのアプリケーションは、ユーザ要求コンテンツの再生を開始(initiate)することができる。
【１１４２】
リニアサービスに関して、プログラムおよびセグメントを再び説明する。プログラムは、リニアサービスの時間的区間(temporal section)である。このとき、プログラムは、予定された(scheduled)開始時間および長さ(duration)を有する。また、プログラムは、１つのプログラム単位で消費されるようにするために、放送局によって決められたものであってもよい。
【１１４３】
また、プログラムは、コンテンツアイテムやリニアサービスのプログラムと同じ構造を有するユーザ要求コンテンツを称することができる。このとき、ユーザ要求コンテンツは、リニアサービスのプログラムと違い、予定された開始時間を有しない。また、放送局によって決められたタイムベースを含まない。
【１１４４】
それぞれのプログラムは「ショー」と関連する。このとき、ショーは、プログラムの主(primary)コンテンツを含む。上述したように、プログラムの多くの属性は、ショーの属性である。例えば、プログラムが含むプログラムを説明するテキスト、俳優および公開日(release date)などの属性はショーの属性である。ショーの属性以外のプログラム属性は、プログラム自体の属性である。プログラム自体の属性は、同一のショーを含むプログラムでも相互に異なる場合がある。例えば、プログラムが含む開始時間およびプログラムが含まれたサービスは、プログラムごとに異なる場合がある。
【１１４５】
プログラムは、ショーを含む１つまたは複数の時間区間を含む。また、プログラムは、中間(interstitial)コンテンツを含む１つまたは複数の時間区間を含むことができる。このような時間区間をセグメントという。具体的には、ショーセグメント、中間セグメントに分けることができる。
【１１４６】
セグメントは、プログラムの一部として決められた開始時間および長さを有することができる。このようなセグメントをanchoredセグメントという。また、プログラムに動的に挿入されることがあるNon-anchoredセグメントが存在する。具体的には、Non-anchoredセグメントは、挿入される特定プログラムまたは挿入される特定時間が決められていないセグメントである。例えば、挿入されるプログラムおよび時間が決められておらず、放送受信装置１００が受信するターゲティング広告もNon-anchoredセグメントであるというできる。
【１１４７】
放送受信装置１００は、制御部１５０を介してプログラムに関連したアプリケーションをサービスガイドを介して表示することができる。また、放送受信装置１００は、プログラムに関連したアプリケーションをユーザ入力に基づいて、お気に入り(favorite)リストに追加またはダウンロードすることができる。具体的には、放送受信装置１００は、自動起動アプリケーションベースのサービスがパッケージアプリ(packaged app)と一緒に提供される場合、放送プログラムを表示するサービスガイドを介して表示することができる。これに関しては、図１１１を参照して説明する。
【１１４８】
図１１１は、放送受信装置が自動起動アプリケーションベースのサービスを放送サービスガイドを介して表示し、これをお気に入りとして格納またはダウンロードする動作を図示するフローチャートである。
【１１４９】
放送受信装置１００は、放送受信部１１０を介して放送信号を受信する(S９５１)。
【１１５０】
放送受信装置１００は、制御部１５０を介して放送信号に基づいて自動起動アプリケーションベースのサービスの情報を獲得する(S９５３)。具体的な実施例において、放送受信装置１００は、放送信号から自動起動アプリケーションベースのサービス情報を獲得することができる。例えば、放送受信装置１００は、前述したサービス情報またはプログラム情報から自動起動アプリケーションベースのサービス情報を獲得することができる。
【１１５１】
放送受信装置１００は、制御部１５０を介して自動起動アプリケーションベースのサービス情報に基づいてサービスガイドを表示する(S９５５)。具体的な実施例において、放送受信装置１００は、プログラム情報と一緒に自動起動アプリケーションベースのサービスに関する情報を表示することができる。特に、放送受信装置１００は、自動起動アプリケーションベースのサービスに関連したプログラムの情報と自動起動アプリケーションベースのサービスに関する情報とを一緒に表示することができる。
【１１５２】
放送受信装置１００は、制御部１５０を介して自動起動アプリケーションベースのサービスの表示に関するユーザ入力を受信する(S９５７)。具体的には、放送受信装置１００は、自動起動アプリケーションベースのサービスを選択するユーザ入力を受信することができる。具体的には、放送受信装置１００は、自動起動アプリケーションをお気に入り(favorite)として格納することに関するユーザ入力を受信することができる。また、他の具体的な実施例において、放送受信装置１００は、自動起動アプリケーションをダウンロードすることに関するユーザ入力を受信することができる。
【１１５３】
放送受信装置１００は、制御部１５０を介してユーザ入力に基づいて自動起動アプリケーションをお気に入りとして格納またはダウンロードする(S９５９)。具体的には、放送受信装置１００は、選択された自動起動アプリケーションベースのサービスの自動起動アプリケーションをお気に入りに格納またはダウンロードする。
【１１５４】
放送受信装置１００は、制御部１５０を介してお気に入りに格納された自動起動アプリケーションまたはダウンロードした自動起動アプリケーションを表示する(S９６１)。具体的には、放送受信装置１００は、お気に入りに格納された自動起動アプリケーションまたはダウンロードした自動起動アプリケーションを表示することができる。具体的な実施例において、放送受信装置１００は、お気に入りに格納された自動起動アプリケーションまたはダウンロードした自動起動アプリケーションを表すアイコンを介して表示することができる。また、放送受信装置１００は、お気に入りに格納された自動起動アプリケーションまたはダウンロードした自動起動アプリケーションに関するユーザ入力を受信して、自動起動アプリケーションをダウンロードしたり実行することができる。これによって、放送受信装置１００は、放送サービスガイドが、スマートフォンのアプリケーションストアと同様な役割をすることができる。
【１１５５】
これまで実施例に説明された特徴、構造、効果などは本発明の少なくとも一つの実施例に含まれ、必ずしも一つの実施例にのみ限定されることはない。また、各実施例で例示された特徴、構造、効果などは実施例の属する技術分野の通常の知識を有する者によって他の実施例に対しても組み合わせられるか変形されて実施可能なものである。よって、このような組み合わせおよび変形に関する内容は本発明の範囲に含まれると解析すべきである。
【１１５６】
以上、本発明を実施例を中心に説明したが、これは単なる例示であり、本発明を限定するものではない。本発明が属する分野の通常の知識を有した者であれば、本実施例の本質的な特性を逸脱しない範囲内で、以上に例示されていない変形および応用が可能である。例えば、実施例に具体的に提示された各構成要素は変形して実施することができ、そのような変形および応用にかかわる差異点は、添付された特許請求の範囲で規定する本発明の範囲に含まれると解釈されるべきである。
【図１】
2017508326.tif 000063
【図２】
2017508326.tif 000064
【図３】
2017508326.tif 000065
【図４】
2017508326.tif 000066
【図５（ａ）】
2017508326.tif 000067
【図５（ｂ）】
2017508326.tif 000068
【図６】
2017508326.tif 000069
【図７】
2017508326.tif 000070
【図８】
2017508326.tif 000071
【図９】
2017508326.tif 000072
【図１０】
2017508326.tif 000073
【図１１】
2017508326.tif 000074
【図１２】
2017508326.tif 000075
【図１３】
2017508326.tif 000076
【図１４】
2017508326.tif 000077
【図１５】
2017508326.tif 000078
【図１６】
2017508326.tif 000079
【図１７】
2017508326.tif 000080
【図１８】
2017508326.tif 000081
【図１９（ａ）】
2017508326.tif 000082
【図１９（ｂ）】
2017508326.tif 000083
【図２０（ａ）】
2017508326.tif 000084
【図２０（ｂ）】
2017508326.tif 000085
【図２１（ａ）】
2017508326.tif 000086
【図２１（ｂ）】
2017508326.tif 000087
【図２２】
2017508326.tif 000088
【図２３】
2017508326.tif 000089
【図２４（ａ）】
2017508326.tif 000090
【図２４（ｂ）】
2017508326.tif 000091
【図２５（ａ）】
2017508326.tif 000092
【図２５（ｂ）】
2017508326.tif 000093
【図２５（ｃ）】
2017508326.tif 000094
【図２６】
2017508326.tif 000095
【図２７】
2017508326.tif 000096
【図２８】
2017508326.tif 000097
【図２９】
2017508326.tif 000098
【図３０】
2017508326.tif 000099
【図３１】
2017508326.tif 000100
【図３２】
2017508326.tif 000101
【図３３】
2017508326.tif 000102
【図３４】
2017508326.tif 000103
【図３５】
2017508326.tif 000104
【図３６】
2017508326.tif 000105
【図３７】
2017508326.tif 000106
【図３８】
2017508326.tif 000107
【図３９】
2017508326.tif 000108
【図４０】
2017508326.tif 000109
【図４１】
2017508326.tif 000110
【図４２】
2017508326.tif 000111
【図４３】
2017508326.tif 000112
【図４４】
2017508326.tif 000113
【図４５】
2017508326.tif 000114
【図４６】
2017508326.tif 000115
【図４７】
2017508326.tif 000116
【図４８】
2017508326.tif 000117
【図４９】
2017508326.tif 000118
【図５０】
2017508326.tif 000119
【図５１】
2017508326.tif 000120
【図５２】
2017508326.tif 000121
【図５３】
2017508326.tif 000122
【図５４】
2017508326.tif 000123
【図５５】
2017508326.tif 000124
【図５６】
2017508326.tif 000125
【図５７】
2017508326.tif 000126
【図５８】
2017508326.tif 000127
【図５９】
2017508326.tif 000128
【図６０】
2017508326.tif 000129
【図６１】
2017508326.tif 000130
【図６２】
2017508326.tif 000131
【図６３】
2017508326.tif 000132
【図６４】
2017508326.tif 000133
【図６５】
2017508326.tif 000134
【図６６】
2017508326.tif 000135
【図６７】
2017508326.tif 000136
【図６８】
2017508326.tif 000137
【図６９】
2017508326.tif 000138
【図７０】
2017508326.tif 000139
【図７１】
2017508326.tif 000140
【図７２】
2017508326.tif 000141
【図７３】
2017508326.tif 000142
【図７４】
2017508326.tif 000143
【図７５】
2017508326.tif 000144
【図７６】
2017508326.tif 000145
【図７７】
2017508326.tif 000146
【図７８】
2017508326.tif 000147
【図７９】
2017508326.tif 000148
【図８０】
2017508326.tif 000149
【図８１】
2017508326.tif 000150
【図８２】
2017508326.tif 000151
【図８３】
2017508326.tif 000152
【図８４】
2017508326.tif 000153
【図８５】
2017508326.tif 000154
【図８６】
2017508326.tif 000155
【図８７】
2017508326.tif 000156
【図８８】
2017508326.tif 000157
【図８９】
2017508326.tif 000158
【図９０】
2017508326.tif 000159
【図９１】
2017508326.tif 000160
【図９２】
2017508326.tif 000161
【図９３】
2017508326.tif 000162
【図９４】
2017508326.tif 000163
【図９５】
2017508326.tif 000164
【図９６】
2017508326.tif 000165
【図９７】
2017508326.tif 000166
【図９８】
2017508326.tif 000167
【図９９】
2017508326.tif 000168
【図１００】
2017508326.tif 000169
【図１０１】
2017508326.tif 000170
【図１０２】
2017508326.tif 000171
【図１０３】
2017508326.tif 000172
【図１０４】
2017508326.tif 000173
【図１０５】
2017508326.tif 000174
【図１０６】
2017508326.tif 000175
【図１０７】
2017508326.tif 000176
【図１０８】
2017508326.tif 000177
【図１０９】
2017508326.tif 000178
【図１１０】
2017508326.tif 000179
【図１１１】
2017508326.tif 000180
【手続補正書】
【提出日】平成28年6月20日(2016.6.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
放送送信装置の動作方法であって、
サービスおよびサービスシグナリングデータを有する放送データを処理するステップと、
前記処理した放送データを有する物理層フレームを生成するステップと、
前記物理層フレームを放送受信装置に送信するステップと、を有し、
前記サービスシグナリングデータは、
オーディオ／ビデオサービス、オーディオのみのサービス、アプリケーションサービス、サービスガイドおよび緊急警告サービスのうちの１つである前記サービスのカテゴリに関する第１の情報と、
セッションベースのプロトコルおよびパケットベースのプロトコルのうちの１つである前記サービスのためのプロトコルに関する第２の情報と、を有する、方法。
【請求項２】
前記サービスシグナリングデータは、
オーディオコンポーネント、ビデオコンポーネントおよびテキストのうちの１つである前記サービスに有されるコンポーネントのタイプに関する第３の情報を有する、請求項１に記載の方法。
【請求項３】
前記サービスシグナリングデータは、
前記第３の情報による前記コンポーネントの役割に関する第４の情報を有する、請求項２に記載の方法。
【請求項４】
前記第３の情報が前記オーディオコンポーネントタイプを示す場合、前記第４の情報によって示される前記役割は、完全なメイン、音楽、効果音、対話、コメント、視覚障害者、聴覚障害者およびナレーションのうちの１つである、請求項３に記載の方法。
【請求項５】
前記第３の情報が前記ビデオコンポーネントタイプを示す場合、前記第４の情報によって示される前記役割は、主なビデオである、請求項３に記載の方法。
【請求項６】
前記第３の情報が前記テキストタイプを示す場合、前記第４の情報によって示される前記役割は、通常および大きな文字のうちの１つである、請求項３に記載の方法。
【請求項７】
前記サービスシグナリングデータは、
前記サービスを表すのに使用されるアイコンのためのユニフォームリソースロケータ（ＵＲＬ）に関する第５の情報を有する、請求項１に記載の方法。
【請求項８】
前記サービスシグナリングデータは、
前記サービスのジャンルに関する第６の情報を有する、請求項１に記載の方法。
【請求項９】
サービスおよびサービスシグナリングデータを有する放送データを処理し、
前記処理した放送データを有する物理層フレームを生成する、制御部と、
前記物理層フレームを放送受信装置に送信する伝送部と、を有し、
前記サービスシグナリングデータは、
オーディオ／ビデオサービス、オーディオのみのサービス、アプリケーションサービス、サービスガイドおよび緊急警告サービスのうちの１つである前記サービスのカテゴリに関する第１の情報と、
セッションベースのプロトコルおよびパケットベースのプロトコルのうちの１つである前記サービスのためのプロトコルに関する第２の情報と、を有する、放送送信装置。
【請求項１０】
前記サービスシグナリングデータは、
オーディオコンポーネント、ビデオコンポーネントおよびテキストのうちの１つである前記サービスに有されるコンポーネントのタイプに関する第３の情報を有する、請求項９に記載の装置。
【請求項１１】
前記サービスシグナリングデータは、
前記第３の情報による前記コンポーネントの役割に関する第４の情報を有する、請求項１０に記載の装置。
【請求項１２】
前記第３の情報が前記オーディオコンポーネントタイプを示す場合、前記第４の情報によって示される前記役割は、完全なメイン、音楽、効果音、対話、コメント、視覚障害者、聴覚障害者およびナレーションのうちの１つである、請求項１１に記載の装置。
【請求項１３】
前記第３の情報が前記ビデオコンポーネントタイプを示す場合、前記第４の情報によって示される前記役割は、主なビデオである、請求項１１に記載の装置。
【請求項１４】
前記第３の情報が前記テキストタイプを示す場合、前記第４の情報によって示される前記役割は、通常および大きな文字のうちの１つである、請求項１１に記載の装置。
【請求項１５】
前記サービスシグナリングデータは、
前記サービスを表すのに使用されるアイコンのためのユニフォームリソースロケータ（ＵＲＬ）に関する第５の情報と、
前記サービスのジャンルに関する第６の情報と、を有する、請求項９に記載の装置。
【国際調査報告】
2017508326.tif 000181
2017508326.tif 000182