(57)【特許請求の範囲】
【請求項１】
緊急状況を知らせるための災難警報情報を提供する放送受信装置において、
物理層フレームを含む放送信号を受信するように構成された放送受信部であって、前記物理層フレームは、物理層シグナリングデータと、放送サービスをシグナリングするためのシグナリングデータを伝達するための第１の物理層パイプと、前記放送サービスのサービスデータを伝達するための第２の物理層パイプと、前記第１の物理層パイプのための情報を含む物理層シグナリングデータを含む、放送受信部と、
前記第１の物理層パイプのための情報を利用して前記第１の物理層パイプから前記災難警報情報を獲得するように構成された制御部と、を含む、放送受信装置。
【請求項２】
前記災難警報情報は、少なくとも一つの警報メッセージを含み、前記警報メッセージを識別する識別情報を含む、請求項１に記載の放送受信装置。
【請求項３】
前記災難警報情報は、災難警報に関連したメディアサービスのための情報を更に含む、請求項２に記載の放送受信装置。
【請求項４】
前記制御部は、前記災難警報に関する前記メディアサービスのための情報を利用して、前記第２の物理層パイプ又はブロードバンドネットワークを介して前記メディアサービスのサービスデータを獲得するようにさらに構成される、請求項３に記載の放送受信装置。
【請求項５】
前記災難警報に関連したメディアサービスのための情報は、前記メディアサービスを識別するサービス識別情報又は前記メディアサービスのサービスデータを伝達する物理層パイプを識別する物理層パイプ識別情報の少なくとも一つを含む、請求項４に記載の放送受信装置。
【請求項６】
前記災難警報に関連したメディアサービスのための情報は、前記ブロードバンドネットワークを介して前記メディアサービスのサービスデータを獲得するためのＵＲＬ情報を含む、請求項４に記載の放送受信装置。
【請求項７】
前記第１の物理層パイプのための情報は、前記第１の物理層パイプを識別する物理層パイプ識別情報を含む、請求項１に記載の放送受信装置。
【請求項８】
前記第１の物理層パイプは、基本物理層パイプであり、前記第２の物理層パイプはノーマル物理層パイプである、請求項１に記載の放送受信装置。
【請求項９】
緊急状況を知らせるための災難警報情報を提供する放送受信装置の動作方法において、
物理層フレームを含む放送信号を受信するステップであって、前記物理層フレームは、物理層シグナリングデータと、放送サービスをシグナリングするためのシグナリングデータを伝達するための第１の物理層パイプと、前記放送サービスのサービスデータを伝達するための第２の物理層パイプと、前記第１の物理層パイプのための情報を含む物理層シグナリングデータを含む、ステップと、
前記第１の物理層パイプのための情報を利用して前記第１の物理層パイプから災難警報情報を獲得するステップと、を含む、放送受信装置の動作方法。
【請求項１０】
緊急状況を知らせるための災難警報情報を生成するように構成された制御部と、
前記災難警報情報を含む放送信号を伝送する伝送部を含み、
前記放送信号は、物理層フレームを含み、
前記物理層フレームは、物理層シグナリングデータと、放送サービスをシグナリングするためのシグナリングデータを伝達するための第１の物理層パイプと、前記放送サービスのサービスデータを伝達するための第２の物理層パイプと、前記第１の物理層パイプのための情報を含む物理層シグナリングデータを含み、
前記災難警報情報は前記第１の物理層パイプを介して伝送される、放送伝送装置。
【請求項１１】
緊急状況を知らせるための災難警報情報を伝送するための放送伝送装置の動作方法であって、
緊急状況を知らせるための災難警報情報を生成するステップと、
前記災難警報情報を含む放送信号を伝送するステップと、を含み、
前記放送信号は、物理層フレームを含み、
前記物理層フレームは、物理層シグナリングデータと、放送サービスをシグナリングするためのシグナリングデータを伝達するための第１の物理層パイプと、前記放送サービスのサービスデータを伝達するための第２の物理層パイプと、前記第１の物理層パイプのための情報を含む物理層シグナリングデータを含み、
前記災難警報情報は前記第１の物理層パイプを介して伝送される、放送伝送装置の動作方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法に関するものである。
【背景技術】
【０００２】
放送システムにおいて、災難警報情報(Emergency Alert information)の伝送は、放送を視聴する使用者に緊急状況であることを知らせて即刻措置を取るようにする役割をする。特に、北米放送環境において、災難通知情報の伝達は、FEMA(Federal Emergency Management Agency)及びFCC(Federal Communications Commission)等で指定している。従って、次世代放送システムにも災難警報情報の伝送が支援されなければならない。
【０００３】
既存の放送システムの災難通知情報は、主にCAP(Common Alerting Protocol)メッセージの形態に構成されており、CAPは、メッセージ形態を表現する方法を提示しているが、これを伝送する方法は伝送プロトコルに依存する。従って、災難警報情報を伝達するためには、伝送システムの特性が反映されなければならず、CAPを利用した災難警報情報伝達方案及び伝送プロトコルが必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の一実施例は、災難警報情報を伝送するためのシグナリングシステムを構成し、これを伝送プロトコルに適用できるようにする放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００５】
特に、本発明の一実施例は、災難警報情報を伝達できるシグナリングシステムを構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００６】
特に、本発明の一実施例は、災難警報情報を伝達できるセクションテーブル(Section table)を構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００７】
特に、本発明の一実施例は、災難警報情報を伝達できるパケットを構成して受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００８】
特に、本発明の一実施例は、物理層内の特定物理層パイプを介して、災難警報情報を送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００９】
特に、本発明の一実施例は、災難状況情報に基づいて感知周期を設定して送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一実施例に係る放送受信装置は、放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信する放送受信部及び前記伝送パケットをデコーディングして前記災難警報情報を獲得する制御部を含む。
【００１１】
特に、前記放送受信部は、前記災難警報情報のみを伝送するために指定された伝送経路である第１伝送経路を介して、災難警報情報を伝送するための伝送パケットを受信することができる。
【００１２】
特に、物理層は、前記第１伝送経路が前記物理層に含まれることを知らせる情報を含むことができる。
【００１３】
特に、前記放送受信部は、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する伝送経路である第２伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信することができる。
【００１４】
特に、前記放送受信部は、放送サービスをスキャンするための情報を他の層を経ずに物理層に直接伝送するための伝送経路である第３伝送経路に基づいて、前記災難警報情報を伝送するための伝送パケットを受信することができる。
【００１５】
特に、前記第３伝送経路に基づいて受信した伝送パケットは、前記災難警報情報を獲得するための経路情報を含み、前記放送受信部は、前記経路情報に基づいて前記第３伝送経路と異なる第４伝送経路を介して、前記災難警報情報を獲得するための伝送パケットを受信することができる。
【００１６】
特に、前記経路情報は、前記災難警報情報を伝送する物理層パイプを識別するための情報を含むことができる。
【００１７】
特に、前記制御部は、前記伝送パケットをデコーディングして前記災難警報情報に関連した放送サービス情報を獲得し、前記関連した放送サービス情報は、前記災難警報情報に関連したリアルタイムサービスを伝送する伝送経路情報及び前記災難警報情報に関連した非リアルタイムサービスを受信するためのアドレス情報のうち少なくとも一つである。
【００１８】
特に、前記制御部は、前記災難警報情報に基づいて、前記物理層を介して災難警報情報が伝送されるのか否かを感知する機能を活性化するための第１情報を獲得することができる。
【００１９】
特に、前記第１情報は、感知機能の活性化開始時間情報、感知機能の活性化持続時間情報及び感知機能の非活性化持続時間情報のうち少なくともいずれか一つを含むことができる。
【００２０】
特に、前記第１情報は、前記災難警報情報を伝送する放送伝送装置の位置に基づいて決定される。
【００２１】
特に、前記第１情報は、前記放送受信装置の位置と災難発生地域の間の距離に比例する感知機能の非活性化持続時間を有することができる。
【００２２】
特に、前記第１情報は、災難警報の優先順位を示す第２情報に基づいて決定され、前記第２情報は、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報を含むことができる。
【００２３】
また、本発明の一実施例に係る放送受信装置の動作方法は、放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信するステップ、前記伝送パケットをデコーディングするステップ及び前記デコーディングされた伝送パケットから災難警報情報を獲得するステップを含むことができる。
【００２４】
また、本発明の一実施例に係る放送伝送装置は、緊急状況を知らせるための災難警報情報を警報当局から収集し、前記収集した災難警報情報を伝送するための形態にエンコーディングする制御部及び放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記エンコーディングされた災難警報情報を伝送する伝送部を含むことができる。
【００２５】
また、本発明の一実施例に係る放送伝送装置の動作方法は、前記収集した災難警報情報を伝送するための形態にエンコーディングするステップ及び放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記エンコーディングされた災難警報情報を伝送するステップを含むことができる。
【発明の効果】
【００２６】
本発明の一実施例は、災難警報情報を伝送するためのシグナリングシステムを構成し、これを伝送プロトコルに適用できるようにする放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
【００２７】
特に、本発明の一実施例は、災難警報情報を伝達できるシグナリングシステムを構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
【００２８】
特に、本発明の一実施例は、災難警報情報を伝達できるセクションテーブル(Section table)を構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
【００２９】
特に、本発明の一実施例は、災難警報情報を伝達できるパケットを構成して受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
【００３０】
特に、本発明の一実施例は、物理層内の特定物理層パイプを介して、災難警報情報を送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
【００３１】
特に、本発明の一実施例は、災難状況情報に基づいて感知周期を設定して送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
【図面の簡単な説明】
【００３２】
【図１】本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【図２】本発明の一実施例に係る入力フォーマット(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 signalling)マッピングを示す。
【図１８】本発明の一実施例に係るEAC(emergency alert channel)マッピングを示す。
【図１９】本発明の一実施例に係るFIC(fast information channel)マッピングを示す。
【図２０】本発明の一実施例に係るDPのタイプを示す。
【図２１】本発明の一実施例に係るDPマッピングを示す。
【図２２】本発明の一実施例に係るFEC(forward error correction)構造を示す。
【図２３】本発明の一実施例に係るビットインターリービングを示す。
【図２４】本発明の一実施例に係るセル-ワードデマルチプレックス(cell-word demultiplexing)を示す。
【図２５】本発明の一実施例に係るタイムインターリービングを示す。
【図２６】本発明の一実施例に係るツイスト行列ブロックインターリーバ(twisted row-column block interleaver)の基本動作を示す。
【図２７】本発明の他の一実施例に係るツイスト行列ブロックインターリーバの動作を示す。
【図２８】本発明の一実施例に係るツイスト行列ブロックインターリーバの対角線方向のリーディングパターンを示す。
【図２９】本発明の一実施例に係る各インターリービングアレイ(array)からインターリービングされたXFECBLOCKを示す。
【図３０】本発明の一実施例に係る放送受信装置の構成を示す。
【図３１】本発明の一実施例に係る連動装置と連動する放送サービスを提供する放送システムを示す。
【図３２】本発明の一実施例によりシグナリングされる放送サービスの属性を示す。
【図３３】本発明の一実施例によりシグナリングされる放送サービスの属性の状態を示す変数を示す。
【図３４】本発明の一実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【図３５】本発明の一実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性のデータ形式を示す。
【図３６】本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数、放送サービスの属性のためのアクション及びアクションの引数(argument)を示す。
【図３７】本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【図３８】本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の変更可否のデータ形式を示す。
【図３９】本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
【図４０】本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の変更できるか否かのデータ形式を示す。
【図４１】本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
【図４２】本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【図４３】本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数、放送サービスの属性のためのアクション及びアクションの引数(argument)を示す。
【図４４】本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【図４５】本発明の一実施例により災難警報が生成され、放送網を介して伝送される過程を示す。
【図４６】本発明の一実施例により放送受信装置が放送網を介してシグナリングされる災難警報を抽出して表示することを示す。
【図４７】本発明の一実施例に係る災難警報メッセージの形式を示す。
【図４８】本発明の一実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を示す。
【図４９】本発明の一実施例により放送受信装置がシグナリングする災難警報を含むメッセージに関する情報を示す。
【図５０】本発明の一実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【図５１】本発明の一実施例により放送受信装置が災難警報の優先順位を判断する基準を示す。
【図５２】本発明の他の実施例により放送受信装置が災難警報の優先順位を判断する基準を示す。
【図５３】本発明の他の実施例により放送受信装置が災難警報の優先順位を判断する基準を示す。
【図５４】本発明の他の実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を示す。
【図５５】本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【図５６】本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【図５７】本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【図５８】本発明の一実施例に係る放送サービスの伝送層を示す。
【図５９】本発明の一実施例に係る災難警報システムの全体構成を示すブロック図である。
【図６０】本発明の一実施例に係る放送サービスを支援するためのプロトコルスタック(protocol stack)を示す。
【図６１】災難警報テーブル(EAT、Emergency Alert Table)情報のシンタックスを示す。
【図６２】災難警報メッセージのためのシンタックスを示す。
【図６３】自動チャネル転換情報(Automatic Channel Tuning Information)のためのシンタックスを示す。
【図６４】NRTサービス情報のためのシンタックスを示す。
【図６５】災難警報メッセージを伝送するためのセクションテーブルに対する一実施例を示す。
【図６６】災難警報メッセージを伝送するためのセクションテーブルに対する一実施例を示す。
【図６７】上述した災難警報テーブルの形態を変更せず、そのままパケットのペイロードで構成した一実施例を示す。
【図６８】パケットペイロードに災難警報メッセージがセクションテーブルの形態ではなく、個別情報に挿入される一実施例を示す。
【図６９】本発明の一実施例として、放送伝送装置３００が災難警報テーブルを指定された物理層パイプを介して伝送することを示す。
【図７０】本発明の一実施例として、放送伝送装置３００が災難警報テーブルをパケットにカプセル化して伝送することを示す。
【図７１】本発明の一実施例として、放送伝送装置３００が災難警報テーブルをパケットにカプセル化して伝送することを示す。
【図７２】シグナリングチャネルを介して、災難警報メッセージを直接伝送する内容を示す。
【図７３】図７２の実施例に係るシグナリングチャネルを介して伝送される災難警報メッセージのためのシンタックスを示す。
【図７４】シグナリングチャネルを介して、災難警報情報の伝達経路のみを伝送する内容を示す。
【図７５】図７４の実施例に係るシグナリングチャネルを介して伝送される災難警報をシグナリングするためのシンタックスの例である。
【図７６】本発明の一実施例に係る放送伝送装置動作方法を示すフローチャートである。
【図７７】本発明の一実施例に係る放送受信装置の動作方法を示すフローチャートである。
【図７８】放送伝送装置が放送受信装置に伝送する感知時間周期情報のためのシンタックスである。
【図７９】感知周期情報に応じた放送受信装置の動作の実施例を示す。
【図８０】感知周期情報が追加された災難警報テーブルのシンタックスを示す。
【図８１】災難警報情報及び感知周期情報がシグナリングチャネルに含まれる場合に対する実施例を示す。
【図８２】災難状況情報を伝送するための、CAPメッセージの一例を示す。
【図８３】放送伝送装置が感知周期情報を設定するための災難状況情報の一例を示す。
【図８４】放送伝送装置が感知周期情報を災難状況の優先順位情報(Priority Information)に基づいて設定することを示す。
【図８５】放送伝送装置が感知周期情報を災難状況の優先順位情報(Priority Information)に基づいて設定することを示す。
【図８６】放送伝送装置が感知周期情報を災難状況の優先順位情報(Priority Information)に基づいて設定することを示す。
【図８７】本発明の一実施例に係る放送伝送装置の動作方法を示すフローチャートである。
【図８８】本発明の一実施例に係る放送受信装置の動作方法を示すフローチャートである。
【発明を実施するための形態】
【００３３】
以下、添付した図面を参照して本発明の実施例に対して、本発明が属する技術分野で通常の知識を有した者が容易に実施できるように詳しく説明する。なお、本発明は多様な異なる形態に具現することができ、ここで説明する実施例に限定されない。そして、図面において、本発明を明確に説明するために説明と関係のない部分は省略しており、明細書全体において類似する部分に対しては、類似する図面符号を付している。
【００３４】
また、ある部分がある構成要素を「含む」とした場合、これは特に限定する記載がない限り、他の構成要素を除くものではなく、他の構成要素をさらに含むことができることを意味する。
【００３５】
本発明の一実施例に係る放送伝送装置及びその方法は、地上波放送サービスのためのベースプロファイル、モバイル放送サービスのためのハンドヘルドプロファイル及びUHDTVサービスのためのアドバンスドプロファイルに区分することができる。この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービス両方のためのプロファイルとして用いられる。このとき、ベースプロファイルは、モバイルプロファイルを含むプロファイルのコンセプトとして定義することができる。これは、設計者の意図によって変更可能である。
【００３６】
本発明は、一実施例によって非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)プロファイル)を定義することができる。フィジカルプロファイルは、該当する受信機が具現すべきすべての構造のサブセットである。
【００３９】
３つのフィジカルプロファイルは、ほとんどの機能ブロックを共有するが、特定ブロック及び/またはパラメータにおいては若干異なる。後でフィジカルプロファイルを追加定義することができる。システム発展のために、フューチャープロファイルは、FEF(future extension frame)を介して単一RF(radio frequency)チャネルに存在するプロファイルとマルチプレックスされる。各フィジカルプロファイルに対する詳しい内容は後述する。
【００４０】
１．ベースプロファイル
ベースプロファイルは、主にループトップ(roof-top)アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルは、所定場所に移動できるが、比較的停止した受信範疇に属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置または車両用に拡張することができるが、このような使用用途は、ベースプロファイル受信機動作では期待できない。
【００４１】
受信のターゲット信号対雑音比の範囲は、略１０〜２０dBであるが、これは既存の放送システム(例えば、ATSC A/５３)の１５dB信号対雑音比受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを用いるバッテリで駆動されるハンドヘルド装置におけるほど重要ではない。ベースプロファイルに対する重要なシステムパラメータが以下の表１に記載されている。
【００４２】
【表１】
0006321195.tif 000002
【００４３】
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリ電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は、歩行者または車両速度で移動することができる。受信機の複雑度だけでなく消費電力は、ハンドヘルドプロファイルの装置の具現のために大変重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０〜１０dBであるが、より低い室内受信を目的とした場合、０dBの以下に達するように設定することができる。
【００４４】
低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要なシステムパラメータが以下の表２に記載されている。
【００４５】
【表２】
0006321195.tif 000003
【００４６】
３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルは、MIMO送信及び受信を用いることを要求し、UHDTVサービスはターゲット用途であり、このために当該プロファイルが特別に設計される。向上した能力は与えられた帯域幅でサービス数の増加、例えば、多数のSDTVまたはHDTVサービスを許容することにも用いられる。
【００４７】
アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０〜３０dBである。MIMO伝送は、初期には既存の楕円分極伝送装備(elliptically-polarized transmission equipment)を使用し、後で全出力交差分極伝送(full-power cross-polarized transmission)に拡張することができる。アドバンスドプロファイルに対する重要なシステムパラメータが以下の表３に記載されている。
【００４８】
【表３】
0006321195.tif 000004
【００４９】
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービス両方に対するプロファイルとして用いられる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために使用される。また、アドバンスドプロファイルは、MIMOを有するベースプロファイルに対するアドバンスドプロファイル及びMIMOを有するハンドヘルドプロファイルに対するアドバンスドプロファイルに区分することができる。そして、当該３つのプロファイルは、設計者の意図によって変更可能である。
【００５０】
次の用語及び定義は本発明に適用可能であり、設計によって変更可能である。
【００５１】
補助ストリーム：future extensionまたは放送局やネットワークオペレータによって要求されることで使用できるまだ定義されなていない変調及びコーディングデータを伝達するセルのシーケンス。
【００５２】
ベースデータパイプ(base data pipe)：サービスシグナリングデータを伝達するデータパイプ。
【００５３】
ベースバンドフレーム(またはBBFRAME)：１つのFECエンコーディング過程(BCH及びLDPCエンコーディング)に対する入力を形成するKbchビットの集合。
【００５４】
セル(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 signalling)シグナリング、データパイプ、または補助ストリームのために使用されていない残っている容量を満たすために使用される擬似ランダム値を伝達するセル。
【００６１】
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シグナルである提案された物理層(physical layer)放送システム。
【００７２】
インプットストリーム(input stream、入力ストリーム)：システムによって最終ユーザに伝達されるサービスのアンサンブル(ensemble)のためのデータのストリーム。
【００７３】
ノーマル(normal)データシンボル：フレームシグナリングシンボル及びフレームエッチシンボルを除いたデータシンボル。
【００７４】
フィジカルプロファイル(PHY profile)：該当する受信機が具現すべきすべての構造のサブセット。
【００７５】
PLS：PLS１及びPLS２から構成された物理層(physical layer)シグナリングデータ。
【００７６】
PLS１：PLS２のデコーディングに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するFSS(frame signalling symbol)に伝達されるPLSデータの最初の集合。
【００７７】
NOTE：PLS１データはフレームグループのデュレーション(duration)の間一定である。
【００７８】
PLS２：データパイプ及びシステムに関するより詳細なPLSデータを伝達するFSSに伝送されるPLSデータの二番目の集合。
【００７９】
PLS２ダイナミックデータ(dynamic data)：フレームごとにダイナミックに変化するPLS２データ。
【００８０】
PLS２スタティックデータ(static data)：フレームグループのデュレーションの間スタティックのPLS２データ。
【００８１】
プリアンブルシグナリングデータ(preamble signaling data)：プリアンブルシンボルによって伝達され、システムの基本モードの確認に使用されるシグナリングデータ。
【００８２】
プリアンブルシンボル(preamble symbol)：基本PLSデータを伝達し、フレームの始まりに位置する固定長のパイロットシンボル。
【００８３】
NOTE：プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びFFTサイズを検出するために高速初期バンドスキャンに主に使用される。
【００８４】
将来使用(future use)のためにリザーブド(reserved)：現在の文書で定義されないが将来定義される。
【００８５】
スーパーフレーム(superframe)：８フレーム繰返し単位の集合。
【００８６】
タイムインターリービングブロック(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は、主な入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらのデータ入力に加えて、管理情報が入力されて各入力ストリームに対する該当帯域幅のスケジューリング及び割当を制御する。１つまたは多数のTSストリーム、IPストリーム及び/または一般ストリーム入力が同時に許容される。
【００９５】
インプットフォーマットブロック１０００は、それぞれの入力ストリームを独立的なコーディング及び変調が適用される１つまたは多数のデータパイプにデマルチプレックスすることができる。データパイプは、堅固性(robustness)制御の基本単位であり、これはQoS(Quality of Service)に影響を及ぼす。１つまたは多数のサービスまたはサービスコンポーネントが１つのデータパイプによって伝達される。インプットフォーマットブロック１０００の詳しい動作は後述する。
【００９６】
データパイプは１つまたは多数のサービスまたは、サービスコンポーネントを伝達できるサービスデータまたは関連メタデータを伝達する物理層(physical layer)におけるロジカルチャネルである。
【００９７】
また、データパイプユニットは、１つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【００９８】
インプットフォーマットブロック１０００で、パリティ(parity)データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値のコンステレーションシンボルにマッピングされる。当該シンボルは、当該データパイプに使用される特定インターリービング深さにかけてインターリービングされる。アドバンスドプロファイルにおいて、BICMブロック１０１０でMIMOエンコーディングが実行され、追加データ経路がMIMO伝送のために出力に追加される。BICMブロック１０１０の詳しい動作は後述する。
【００９９】
フレームビルディングブロック１０２０は、１つのフレーム内で入力データパイプのデータセルをOFDMシンボルにマッピングすることができる。マッピング後、周波数領域ダイバーシティーのために、特に周波数選択的フェーディングチャネルを防止するために、周波数インターリービングが利用される。フレームビルディングブロック１０２０の詳しい動作は後述する。
【０１００】
プリアンブルを各フレームの始まりに挿入した後、OFDM生成ブロック１０３０は、サイクリックプレフィックス(cyclic prefix)をガードインターバルとして有する既存のOFDM変調を適用することができる。アンテナスペースダイバーシティーのために、分散した(distributed)MISO方式が送信機にかけて適用される。また、PAPR(peak-to-average power ratio)方式が時間領域で実行される。柔軟なネットワーク方式のために、当該提案は多様なFFTサイズ、ガードインターバル長さ、当該パイロットパターンの集合を提供する。OFDM生成ブロック１０３０の詳しい動作は後述する。
【０１０１】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理層(physical layer)シグナリング情報を生成することができる。また、当該シグナリング情報は、関心のあるサービスが受信機側で適切に回復するように伝送される。シグナリング生成ブロック１０４０の詳しい動作は後述する。
【０１０２】
図２、３、４は、本発明の実施例に係るインプットフォーマットブロック１０００を示す。各図面について説明する。
【０１０３】
図２は、本発明の一実施例に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム(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スクランブラは、エネルギー分散のために完全なBBFをスクランブリングする。スクランブリングシーケンスはBBFと同期化される。スクランブリングシーケンスはフィードバックシフトレジスタによって生成される。
【０１１３】
PLS生成ブロック２０２０は、PLSデータを生成することができる。PLSは、受信機でフィジカルレイヤ（物理層）(physical layer)データパイプに接続できる手段を提供する。PLSデータは、PLS１データ及びPLS２データから構成される。
【０１１４】
PLS１データは、PLS２データのデコーディングに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームでFSSに伝達される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)３０１０、補償遅延(compensatin 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ストリームを伝達する多数のデータパイプに選択的に利用される。
【０１２７】
補償遅延(compensatin delay)ブロック３０２０は、受信機で追加メモリを必要とせず、TSパケット再結合メカニズムを許容するために、ISSY情報の挿入による分割されたTSパケットストリームを遅延させることができる。
【０１２８】
ヌルパケット削除ブロック３０３０は、TS入力ストリームの場合のみに使用される。一部TS入力ストリームまたは分割されたTSストリームは、VBR(variable bit-rate)サービスをCBR TSストリームに収容するために存在する多数のヌルパケットを有することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ヌルパケットは確認され伝送されないようにすることができる。受信機で、除去されたヌルパケットは、伝送に挿入されたDNP(deleted null-packet、削除されたヌルパケット)カウンターを参照して、本来存在していた正確な場所に再挿入することができ、CBRが保障されタイムスタンプ(PCR)を更新する必要がなくなる。
【０１２９】
ヘッダコンプレッションブロック３０４０は、TSまたはIP入力ストリームに対する伝送効率を増加させるために、パケットヘッダ圧縮を提供することができる。受信機は、ヘッダの特定部分に対するアプリオリ(a priori)情報を持つことがあるので、この既知の情報(known information)は送信機から削除することができる。
【０１３０】
TSに対して、受信機は同期バイト構成(０x４７)及びパケット長さ(１８８バイト)に関するアプリオリ情報を有することができる。入力されたTSが１つのPIDのみを有するコンテンツを伝達すれば、すなわち、１つのサービスコンポーネント(ビデオ、オーディオなど)またはサービスサブコンポーネント(SVCベースレイヤ、SVCエンハンスメントレイヤ、MVCベースビュー、またはMVC依存ビュー)に対してのみ、TSパケットヘッダ圧縮がTSに(選択的に)適用されるようにすることができる。TSパケットヘッダ圧縮は、入力ストリームがIPストリームである場合選択的に使用される。
【０１３１】
前記ブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１３２】
図４は、本発明の他の実施形態に係るインプットフォーマットブロックを示す。
【０１３３】
図４に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
【０１３４】
図４は、インプットシグナルが複数のインプットストリームに対応するとき、入力フォーマットモジュールのストリーム適応ブロックを示す。
【０１３５】
図４に示すように、複数のインプットストリームをそれぞれ処理するためのモード適応ブロックは、スケジューラ４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンドシグナリング４０３０、BBフレームスクランブラ４０４０、PLS生産ブロック４０５０、及びPLSスクランブラ４０６０を含むことができる。説明はストリーム適応ブロックのそれぞれのブロックに対して提供される。
【０１３６】
スタッフィングデータブロック４０２０、BBフレームスクランブラ４０４０、PLS生産ブロック４０５０及びPLSスクランブラ４０６０は、図２に図示されたスタッフィング挿入ブロック、BBスクランブラ、PLS生産ブロック及びPLSスクランブラに対応する。従って、それに関する説明は省略する。
【０１３７】
スケジューラ４０００は、それぞれのDPのFECBLOCKの量から全体フレームをわたる全体的なセル割当を決定することができる。PLS、EAC及びFICのための割当を含んでスケジューラは、フレームのFSS内PLSセルまたはインバンドシグナリングに伝送されるPLS２-DYNデータの値を生産する。FECBLOCK、EAC及びFICに関する詳しい説明は後述する。
【０１３８】
１フレーム遅延ブロック４０１０は、DP内に挿入されるインバンドシグナリング情報のための現在のフレームを介して伝送される次のフレームに対するスケジュールリング情報のような１つの伝送フレームによるインプットデータを遅延させることができる。
【０１３９】
インバンドシグナリング４０３０は、フレームの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)は、選択的なコーディング方法である。データFECエンコーダ５０１０の具体的な動作については後述する。
【０１５０】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながらデータFECエンコーダ５０１０の出力をインターリービングして、LDPCコード及び変調方式の組合せで最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
【０１５１】
コンステレーションマッパ５０３０は、QPSK、QAM-１６、不均一QAM(NUQ-６４、NUQ-２５６、NUQ-１０２４)または不均一コンステレーション(NUC-１６、NUC-６４、NUC-２５６、NUC-１０２４)を利用して、ベース及びハンドヘルドプロファイルにおいてビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルにおいてセルワードデマルチプレクサ５０１０-１からのセルワードを変調して、パワーが正規化されたコンステレーションポイントelを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。NUQが任意の形態を有する反面、QAM-１６及びNUQは正四角形形状を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転すれば、回転したコンステレーションは本来のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーが相互等しくなる。NUQ及びNUCはいずれも各コードレート(code rate)に対して特別に定義され、使用される特定の１つは、PLS２データに保管されたパラメータDP_MODによってシグナリングされる。
【０１５２】
ＳＳＤエンコーディングブロック５０４０は、２次元、３次元、４次元でセルをフリーコーディングして、難しいフェーディング条件で受信堅固性（robustness）を増加させることができる。
【０１５３】
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定することができる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０１５４】
アドバンスドプロファイルに対するBICMブロックの処理ブロック５０００-１は、データFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、及びタイムインターリーバを含むことができる。
【０１５５】
ただし、処理ブロック５０００-１は、セルワードデマルチプレクサ５０１０-１及びMIMOエンコーディングブロック５０２０-１をさらに含むという点で、処理ブロック５０００と区別される。
【０１５６】
また、処理ブロック５０００-１におけるデータFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、タイムインターリーバの動作は、前述したデータFECエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパ５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
【０１５７】
セルワードデマルチプレクサ５０１０-１は、アドバンスドプロファイルのデータパイプがMIMO処理のために単一セルワードストリームをデュアルセルワードストリームに分離するために使用される。セルワードデマルチプレクサ５０１０-１の具体的な動作に関しては後述する。
【０１５８】
MIMOエンコーディングブロック５０２０-１は、MIMOエンコーディング方式を利用してセルワードデマルチプレクサ５０１０-１の出力を処理することができる。MIMOエンコーディング方式は、放送信号送信のために最適化されている。MIMO技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に、放送に対して、相互異なる信号電波特性による２つのアンテナの間の受信信号パワーの差またはチャネルの強いLOSコンポーネントは、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エンコーディング方式は、アンテナ極性配置を制限しない。
【０１６０】
MIMO処理は、アドバンスドプロファイルフレームに要求されるが、これはアドバンスドプロファイルフレームにおけるすべてのデータパイプが、MIMOエンコーダによって処理されるということを意味する。MIMO処理は、データパイプレベルで適用される。コンステレーションマッパ出力ペア(pair)のNUQ(e１、i及びe２、i)は、MIMOエンコーダの入力に供給される。MIMOエンコーダ出力ペア(g１、i及びg２、i)は、それぞれの送信アンテナの同一キャリアk及びOFDMシンボルlによって伝送される。
【０１６１】
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１６２】
図６は、本発明の他の実施例に係るBICMブロックを示す。
【０１６３】
図６に図示されたBICMブロックは、図１を参照して説明したBICMブロック１０１０の一実施例に該当する。
【０１６４】
図６は、PLS、EAC、及びFICを保護するための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から組織的にエンコーディングされ、その後に添付される。
【０１７１】
【数１】
0006321195.tif 000005
【０１７２】
PLS１及びPLS２に対するLDPCコードパラメータは、次の表４のようである。
【０１７３】
【表４】
0006321195.tif 000006
【０１７４】
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)を保障することができる。インプットフォーマットブロック及びBICMブロックによるデータパイプの遅延を対処することで、PLSデータはデータパイプだけ遅延される。BICMブロックの遅延は、主にタイムインターリーバ５０５０によるものである。インバンド(In-band)シグナリングデータは、次のタイムインターリービンググループの情報をシグナリングされるデータパイプより１つのフレーム先に伝達されるようにすることができる。遅延補償ブロックは、それに合わせてインバンド(In-band)シグナリングデータを遅延させる。
【０１８３】
セルマッパ７０１０は、PLS、EAC、FIC、データパイプ、補助ストリーム、及びダミーセルをフレーム内でOFDMシンボルのアクティブ(active)キャリアにマッピングすることができる。セルマッパ７０１０の基本機能は、それぞれのデータパイプ、PLSセル、及びEAC/FICセルに対するタイムインターリービングによって生成されたデータセルを、存在すれば、１つのフレーム内でそれぞれのOFDMシンボルに該当するアクティブ(active)OFDMセルのアレイにマッピングするものである。(PSI(program specific information)/SIのような)サービスシグナリングデータは、個別的に収集されてデータパイプによって送信される。セルマッパは、フレーム構造の構成及びスケジューラーによって生成されたダイナミックインフォメーション(dynamic information)に応じて動作する。フレームに関する詳しい内容は後述する。
【０１８４】
周波数インターリーバ７０２０は、セルマッパ７０１０から受信されたデータセルをランダムにインターリービングして、周波数ダイバーシティーを提供することができる。また、周波数インターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード(seed)順を利用して、２つの順次的なOFDMシンボルから構成されたOFDMシンボルペア(pair)で動作することができる。
【０１８５】
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１８６】
図８は、本発明の一実施例に係るOFDM生成ブロックを示す。
【０１８７】
図８に図示されたOFDM生成ブロックは、図１を参照して説明したOFDM生成ブロック１０３０の一実施例に該当する。
【０１８８】
OFDM生成ブロックは、フレームビルディングブロックによって生成されたセルによってOFDMキャリアを変調して、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは順次ガードインターバルを挿入し、PAPR減少処理を適用して最終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ブロック８０７０を含むことができる。
【０１９０】
パイロット及びリザーブドトーン挿入ブロック８０００は、パイロット及びリザーブドトーンを挿入することができる。
【０１９１】
ＯＦＤＭシンボル内の多様なセルは受信機から先験的に知られた転送された値を有するパイロットとして知られた参照情報に変調される。パイロットセルの情報は、分散パイロット、連続パイロット、エッジパイロット、ＦＳＳ（frame signalling symbol）パイロット、及びＦＥＳ（frame edge symbol）パイロットで構成される。各パイロットは、パイロットタイプ及びパイロットパターンに従って特定増加パワーレベルで転送される。パイロット情報の値は与えられたシンボルで１つが各々の転送キャリアに対するものである一連の値に該当する参照シーケンスで誘導される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャンネル推定、転送モード識別のために使われることができ、また位相雑音を追跡するために使用できる。
【０１９２】
参照シーケンスから取った参照情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除外した全てのシンボルにおける分散パイロットセルで転送される。連続パイロットは、フレームの全てのシンボルに挿入される。連続パイロットの数及び位置はＦＦＴサイズ及び分散パイロットパターンに全て依存する。エッジキャリアは、プリアンブルシンボルを除外した全てのシンボル内のエッジパイロットと同一である。エッジキャリアは、スペクトルのエッジまで周波数インターポレーション（interpolation：補間）を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。ＦＳＳパイロット及びＦＥＳパイロットはフレームのエッジまで時間インターポレーション（interpolation：補間）を許容するために挿入される。
【０１９３】
本発明の一実施形態に係るシステムは非常に堅い転送モードをサポートするために分散ＭＩＳＯ方式が選択的に使われるＳＦＮをサポートする。２Ｄ−ｅＳＦＮは多数の送信アンテナを使用する分散ＭＩＳＯ方式であって、各アンテナはＳＦＮネットワークで各々異なる送信機に位置することができる。
【０１９４】
２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために２Ｄ−ｅＳＦＮ処理を行って多数の送信機から転送された信号の位相を歪曲させることがある。したがって、長時間の間の低い平面フェーディングまたは深いフェーディングによるバースト誤りが軽減できる。
【０１９５】
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（または、リザーブドトーン）に指定されないデータシンボルでの全てのセルは、周波数インターリーバからのデータセルのうちの１つを伝達する。セルはＯＦＤＭキャリアにマッピングされる。
【０１９６】
ＰＡＰＲ減少ブロック８０３０は、時間領域で多様なＰＡＰＲ減少アルゴリズムを用いて入力信号にＰＡＰＲ減少を実行する。
【０１９７】
ガードインターバル挿入ブロック８０４０はガードインターバルを挿入することができ、プリアンブル挿入ブロック８０５０は信号の前にプリアンブルを挿入することができる。プリアンブルの構造に対する詳細な内容は後述する。
【０１９８】
その他システム挿入ブロック８０６０は、放送サービスを提供する二以上の相互異なる放送送信/受信システムのデータが同じRF信号帯域で同時に伝送されるように、時間領域で複数の放送送信/受信システムの信号をマルチプレックスすることができる。この場合、二以上の相互異なる放送送信/受信システムは、相互異なる放送サービスを提供するシステムをいう。相互異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味する。
【０１９９】
ＤＡＣブロック８０７０は、入力されたディジタル信号をアナログ信号に変換して出力することができる。ＤＡＣブロック８０７０から出力された信号は物理層プロファイルによって多数の出力アンテナを介して転送できる。本発明の一実施形態に係る送信アンテナは垂直または水平極性を有することができる。
【０２００】
前述したブロックは設計によって省略されるか、類似または同一機能を有するブロックに取替できる。
【０２０１】
図９は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
【０２０２】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応する。
【０２０３】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール(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に対する基本マルチプレックス単位であり、スーパーフレームで８回繰り返される。
【０２１２】
FRUで各フレームは、フィジカルプロファイル(ベース、ハンドヘルド、アドバンスドプロファイル)のうちの１つまたはFEFに属する。FRUでフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、FRUで０回〜４回のいずれかの回数だけ出現できる(例えば、ベース、ベース、ハンドヘルド、アドバンスド)。フィジカルプロファイルの定義は、必要に応じてプリアンブルにおけるPHY_PROFILEのリザーブド値(reserved value)を利用して拡張可能である。
【０２１３】
FEF部分は、含まれる場合FRUの終わりに挿入される。FEFがFRUに含まれる場合、FEFの最大数はスーパーフレームで８である。FEF部分が相互隣接することは推奨されない。
【０２１４】
１つのフレームは、多数のOFDMシンボル及びプリアンブルにさらに分離される。(d)に示したように、フレームは、プリアンブル、１つ以上のFSS、ノーマルデータシンボル、FESを含む。
【０２１５】
プリアンブルは、高速フューチャーキャストUTBシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルについての詳しい内容は後述する。
【０２１６】
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：当該３ビットフィールドは、現在のフレームのフィジカルプロファイルタイプを示す。相互異なるフィジカルプロファイルタイプのマッピングは、以下の表５に示す。
【０２２２】
【表５】
0006321195.tif 000007
【０２２３】
FFT_SIZE：当該２ビットフィールドは、以下の表６で説明するように、フレームグループ内で現在のフレームのFFTサイズを示す。
【０２２４】
【表６】
0006321195.tif 000008
【０２２５】
GI_FRACTION：当該３ビットフィールドは、以下の表７で説明するように、現在のスーパーフレームにおけるガードインターバルの一部(fraction)値を示す。
【０２２６】
【表７】
0006321195.tif 000009
【０２２７】
EAC_FLAG：当該１ビットフィールドは、EACが現在のフレームに提供されるか否かを示す。当該フィールドが１に設定されると、EASが現在のフレームに提供される。当該フィールドが０に設定されると、EASが現在のフレームに伝達されない。当該フィールドは、スーパーフレーム内でダイナミックに転換される。
【０２２８】
PILOT_MODE：当該１ビットフィールドは、現在のフレームグループで現在のフレームに対してパイロットモードがモバイルモードであるかまたは固定モードであるかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが使用される。当該フィールドが１に設定されると、固定パイロットモードが使用される。
【０２２９】
PAPR_FLAG：当該１ビットフィールドは、現在のフレームグループで現在のフレームに対してPAPR減少が使用されているのか否かを示す。当該フィールドが１に設定されると、トーン予約(tone reservation)がPAPR減少のために使用される。当該フィールドが０に設定されると、PAPR減少が使用されない。
【０２３０】
FRU_CONFIGURE：当該３ビットフィールドは、現在のスーパーフレームで存在するFRUのフィジカルプロファイルタイプ構成を示す。現在のスーパーフレームですべてのプリアンブルにおける当該フィールドで、現在のスーパーフレームで伝達されるすべてのプロファイルタイプが識別される。当該３ビットフィールドは、以下の表８に示したように、それぞれのプロファイルに対して異なるように定義される。
【０２３１】
【表８】
0006321195.tif 000010
【０２３２】
RESERVED：当該７ビットフィールドは、将来使用のためにリザーブド(reserved)される。
【０２３３】
図１３は、本発明の一実施例に係るPLS１データを示す。
【０２３４】
PLS１データは、PLS２の受信及びデコーディングを可能とするために必要なパラメータを含んだ基本伝送パラメータを提供する。上述したように、PLS１データは、１つのフレームグループの全体デュレーションの間変化しない。PLS１データのシグナリングフィールドの具体的な定義は次のようである。
【０２３５】
PREAMBLE_DATA：当該２０ビットフィールドは、EAC_FLAGを除いたプリアンブルシグナリングデータのコピーである。
【０２３６】
NUM_FRAME_FRU：当該２ビットフィールドは、FRU当たりのフレーム数を示す。
【０２３７】
PAYLOAD_TYPE：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。PAYLOAD_TYPEは、表９に示したようにシグナリングされる。
【０２３８】
【表９】
0006321195.tif 000011
【０２３９】
NUM_FSS：当該２ビットフィールドは、現在のフレームでFSSの数を示す。
【０２４０】
SYSTEM_VERSION：当該８ビットフィールドは、伝送される信号フォーマットのバージョンを示す。SYSTEM_VERSIONは主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０２４１】
主バージョン：SYSTEM_VERSIONフィールドのMSBである４ビットは、主バージョン情報を示す。主バージョンフィールドにおける変化は互換が不可能な変化を示す。デフォルト値は００００である。当該標準で叙述されたバージョンに対して、値が００００に設定される。
【０２４２】
副バージョン：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：当該３ビットフィールドは、関連した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コードについての詳しい内容は後述する。
【０２５３】
【表１０】
0006321195.tif 000012
【０２５４】
PLS２_MOD：当該３ビットフィールドは、PLS２によって使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２５５】
【表１１】
0006321195.tif 000013
【０２５６】
PLS２_SIZE_CELL：当該１５ビットフィールドは、現在のフレームグループで伝達されるPLS２に対するすべてのコーディングブロックのサイズ(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２に対する部分コーディングブロックのサイズ(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２に対して使用されない。
【０２６８】
【表１２】
0006321195.tif 000014
【０２６９】
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：当該６ビットフィールドは、フィジカルプロファイル内で一意に識別する。
【０２８１】
DP_TYPE：当該３ビットフィールドは、データパイプのタイプを示す。これは、以下の表１３に従ってシグナリングされる。
【０２８２】
【表１３】
0006321195.tif 000015
【０２８３】
DP_GROUP_ID：当該８ビットフィールドは、現在のデータパイプが関連しているデータパイプグループを識別する。これは、受信機が同一DP_GROUP_IDを有するようになる特定サービスに関連しているサービスコンポーネントのデータパイプに接続するために使用される。
【０２８４】
BASE_DP_ID：当該６ビットフィールドは、管理層で使用される(PSI/SIのような)サービスシグナリングデータを伝達するデータパイプを示す。BASE_DP_IDによって示すデータパイプは、サービスデータと一緒にサービスシグナリングデータを伝達するノーマルデータパイプであるか、サービスシグナリングデータのみを伝達する専用データパイプである。
【０２８５】
DP_FEC_TYPE：当該２ビットフィールドは、関連したデータパイプによって使用されるFECタイプを示す。FECタイプは、以下の表１４に従ってシグナリングされる。
【０２８６】
【表１４】
0006321195.tif 000016
【０２８７】
DP_COD：当該４ビットフィールドは、関連したデータパイプによって使用されるコードレート(code rate)を示す。コードレート(code rate)は、以下の表１５に従ってシグナリングされる。
【０２８８】
【表１５】
0006321195.tif 000017
【０２８９】
DP_MOD：当該４ビットフィールドは、関連したデータパイプによって使用される変調を示す。変調は、以下の表１６に従ってシグナリングされる。
【０２９０】
【表１６】
0006321195.tif 000018
【０２９１】
DP_SSD_FLAG：当該１ビットフィールドは、SSDモードが関連したデータパイプで使用されているのか否かを示す。当該フィールドの値が１に設定されると、SSDは使用される。当該フィールドの値が０に設定されると、SSDは使用されない。
【０２９２】
次のフィールドは、PHY_PROFILEがアドバンスドプロファイルを示す０１０と同一であるときのみ現れる。
【０２９３】
DP_MIMO：当該３ビットフィールドは、どのタイプのMIMOエンコーディング処理が関連したデータパイプに適用されるのかを示す。MIMOエンコーディング処理のタイプは、以下の表１７に従ってシグナリングされる。
【０２９４】
【表１７】
0006321195.tif 000019
【０２９５】
DP_TI_TYPE：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、１つのタイムインターリービンググループが１つのフレームに該当し、１つ以上のタイムインターリービングブロックを含むことを示す。１の値は、１つのタイムインターリービンググループが１つより多いフレームで伝達され、１つのタイムインターリービングブロックのみを含むことを示す。
【０２９６】
DP_TI_LENGTH：当該２ビットフィールド(許容値は１、２、４、８のみ)の使用は、次のようなDP_TI_TYPEフィールド内で設定される値によって決定される。
【０２９７】
DP_TI_TYPEの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマッピングされるフレームの数であるPIを示し、タイムインターリービンググループ当たり１つのタイムインターリービングブロックが存在する(NTI=１)。当該２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
【０２９８】
DP_TI_TYPEの値が０に設定されると、当該フィールドはタイムインターリービンググループ当たりタイムインターリービングブロックの数であるNTIを示し、フレーム当たり１つのタイムインターリービンググループが存在する(PI=１)。当該２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
【０２９９】
【表１８】
0006321195.tif 000020
【０３００】
DP_FRAME_INTERVAL：当該２ビットフィールドは、関連したデータパイプに対するフレームグループ内でフレーム間隔(IJUMP)を示し、許容値は１、２、４、８(該当する２ビットフィールドは、それぞれ００、０１、１０、１１)である。フレームグループのすべてのフレームに現れないデータパイプに対して、当該フィールドの値は、順次的なフレーム間の間隔と同一である。例えば、データパイプが１、５、９、１３等のフレームに現れると、当該フィールドの値は４に設定される。すべてのフレームに現れるデータパイプに対して、当該フィールドの値は１に設定される。
【０３０１】
DP_TI_BYPASS：当該１ビットフィールドは、タイムインターリーバ５０５０の可溶性を決定する。データパイプに対してタイムインターリービングが使用されないと、当該フィールド値は１に設定される。反面、タイムインターリービングが使用されると、当該フィールド値は０に設定される。
【０３０２】
DP_FIRST_FRAME_IDX：当該５ビットフィールドは、現在のデータパイプが発生するスーパーフレームの最初のフレームのインデックスを示す。DP_FIRST_FRAME_IDXの値は０から３１の間である。
【０３０３】
DP_NUM_BLOCK_MAX：当該１０ビットフィールドは、当該データパイプに対するDP_NUM_BLOCKSの最大値を示す。当該フィールドの値は、DP_NUM_BLOCKSと同一範囲を有する。
【０３０４】
DP_PAYLOAD_TYPE：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードデータのタイプを示す。DP_PAYLOAD_TYPEは、以下の表１９に従ってシグナリングされる。
【０３０５】
【表１９】
0006321195.tif 000021
【０３０６】
DP_INBAND_MODE：当該２ビットフィールドは、現在のデータパイプがインバンド(In-band)シグナリング情報を伝達するのか否かを示す。インバンド(In-band)シグナリングタイプは、以下の表２０に従ってシグナリングされる。
【０３０７】
【表２０】
0006321195.tif 000022
【０３０８】
DP_PROTOCOL_TYPE：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、以下の表２１に従ってシグナリングされる。
【０３０９】
【表２１】
0006321195.tif 000023
【０３１０】
DP_CRC_MODE：当該２ビットフィールドは、CRCエンコーディングがインプットフォーマットブロックで使用されているのか否かを示す。CRCモードは、以下の表２２に従ってシグナリングされる。
【０３１１】
【表２２】
0006321195.tif 000024
【０３１２】
DNP_MODE：当該２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるヌルパケット削除モードを示す。DNP_MODEは、以下の表２３に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、DNP_MODEは００の値に設定される。
【０３１３】
【表２３】
0006321195.tif 000025
【０３１４】
ISSY_MODE：当該２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるISSYモードを示す。ISSY_MODEは、以下の表２４に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、ISSY_MODEは００の値に設定される。
【０３１５】
【表２４】
0006321195.tif 000026
【０３１６】
HC_MODE_TS：当該２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるTSヘッダ圧縮モードを示す。HC_MODE_TSは、以下の表２５に従ってシグナリングされる。
【０３１７】
【表２５】
0006321195.tif 000027
【０３１８】
HC_MODE_IP：当該２ビットフィールドは、DP_PAYLOAD_TYPEがIP(「０１」)に設定される場合にIPヘッダ圧縮モードを示す。HC_MODE_IPは、以下の表２６に従ってシグナリングされる。
【０３１９】
【表２６】
0006321195.tif 000028
【０３２０】
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)に現れる。
【０３３９】
DP_ID：当該６ビットフィールドは、フィジカルプロファイル内でデータパイプを一意に示す。
【０３４０】
DP_START：当該１５ビット(または１３ビット)フィールドは、DPUアドレッシング(addressing)技法を使用してデータパイプの最初の開始位置を示す。DP_STARTフィールドは、以下の表２７に示したように、フィジカルプロファイル及びFFTサイズに応じて異なる長さを有する。
【０３４１】
【表２７】
0006321195.tif 000029
【０３４２】
DP_NUM_BLOCK：当該１０ビットフィールドは、現在のデータパイプに対する現在のタイムインターリービンググループでFECブロックの数を示す。DP_NUM_BLOCKの値は０から１０２３の間にある。
【０３４３】
RESERVED：当該８ビットフィールドは、将来使用のためにリザーブド(reserved)される。
【０３４４】
次のフィールドは、EACに関連したFICパラメータを示す。
【０３４５】
EAC_FLAG：当該１ビットフィールドは、現在のフレームでEACの存在を示す。当該ビットは、プリアンブルでEAC_FLAGと同一値である。
【０３４６】
EAS_WAKE_UP_VERSION_NUM：当該８ビットフィールドは、自動活性化指示のバージョンナンバーを示す。
【０３４７】
EAC_FLAGフィールドが１と同一であれば、次の１２ビットがEAC_LENGTH_BYTEフィールドに割り当てられる。EAC_FLAGフィールドが０と同一であれば、次の１２ビットがEAC_COUNTERに割り当てられる。
【０３４８】
EAC_LENGTH_BYTE：当該１２ビットフィールドは、EACの長さをバイトで示す。
【０３４９】
EAC_COUNTER：当該１２ビットフィールドは、EACが到達するフレームの前のフレームの数を示す。
【０３５０】
次のフィールドは、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フィールドにマッピングされる。次にFICが存在する場合FICセルがマッピングされる。データパイプは、PLS次にマッピングされるか、EACまたはFICが存在する場合、EACまたはFIC以後にマッピングされる。タイプ１データパイプがまずマッピングされ、タイプ２データパイプが次にマッピングされる。データパイプのタイプの具体的な内容は後述する。一部の場合、データパイプはEASに対する一部特殊データまたはサービスシグナリングデータを伝達することができる。補助ストリームまたはストリームは、存在する場合データパイプを次にマッピングし、ここには順次ダミーセルが後を追う。前述した順序、すなわち、PLS、EAC、FIC、データパイプ、補助ストリーム、及びダミーセルの順序で全部一緒にマッピングすると、フレームでセル容量を正確に満たす。
【０３５５】
図１７は、本発明の一実施例に係るPLSマッピングを示す。
【０３５６】
PLSセルは、FSSのアクティブ(active)キャリアにマッピングされる。PLSが占めるセルの数に応じて、１つ以上のシンボルがFSSと指定され、FSSの数NFSSは、PLS１でのNUM_FSSによってシグナリングされる。FSSは、PLSセルを伝達する特殊なシンボルである。警告性及び遅延時間(latency)は、PLSで重大な事案であるから、FSSは高いパイロット密度を有しており、高速同期化及びFSS内での周波数のみのインターポールレーション(interpoloation、補間)を可能とする。
【０３５７】
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セルは少ないシンボルを占めることができる。
【０３６２】
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はマッピング方法によって２つのタイプのうちの１つでカテゴリー化される。
【０３７５】
Type１DP：DPはTDMによってマッピングされる。
【０３７６】
Type２DP：DPはFDMによってマッピングされる。
【０３７７】
PLSの静的なパート内のDP_TYPEフィールドによってDPのタイプが指示される。図２０は、Type１DP及びType２DPのマッピング順序を示す。Type１DPはまずセルインデックスの昇順にマッピングされ、最後のセルインデックスに到達すれば、シンボルインデックスは１つ増加する。次のシンボルで、DPはp=０から始めてセルインデックスの昇順にマッピングが続けられる。１つのフレームで多数のDPが一緒にマッピングされ、Type１DPのそれぞれは、DPのTDMマルチプレックスに似て時間に応じてグルーピングされる。
【０３７８】
Type２DPはまずシンボルインデックスの昇順にマッピングされ、フレームの最後のOFDMシンボルに到達した後、セルインデックスは１つ増加し、シンボルインデックスは最初に利用可能なシンボルに戻り、シンボルインデックスを増加させる。１つのフレーム内で多数のDPをマッピングした後、Type２DPのそれぞれはDPのFMDマルチプレックスに似て周波数に応じてグルーピングされる。
【０３７９】
Type１DP及びType２DPは、１つの制限が必要となると、１つのフレームに共存することができる。Type１DPは常にType２DPに先行する。Type１及びType２を伝送するOFDMセルの全体数は、DPの伝送のためのOFDMセルの全体数を超過できない。
【０３８０】
【数２】
0006321195.tif 000030
【０３８１】
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なしに、アドレス０は最後のFSS内PLSを伝送する最後のセルを直ちに従うセルを参照する。もし、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を割り当てるためのシグナリングユニットと一緒に定義される。セルマッパ７０１０は、DPのそれぞれのためのTIsによって生産されたセルをマッピングすることができる。タイムインターリーバ５０５０は、TI-ブロックのシリーズ及びセルのセットから構成されるXFECBLOCKの可変数を含むTI-ブロックそれぞれを出力する。XFECBLOCK内のセルの数NcellsはFECBLOCK大きさ、Nldpc、及び配置されたシンボル当たり伝送されたビットの数に従属する。
【０３９０】
DPUは、PHYプロファイルに支持されるXFECBLOCK内のセル数のすべての可能な値の最大公約数として定義される。セル内のDPUの長さはLDPUで定義される。PHYプロファイルのそれぞれは、他のFECBLOCK大きさの結合及び配置されたPHYプロファイルに基づいて定義されるLDPU、シンボル当たりビットの他の数を支持する。
【０３９１】
図２２は、本発明の一実施例に係る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エンコーディングパラメータを示す。
【０３９６】
【表２８】
0006321195.tif 000031
【０３９７】
【表２９】
0006321195.tif 000032
【０３９８】
BCHエンコーディング及びLDPCエンコーディングの具体的な動作は次のようである。
【０３９９】
１２-エラー訂正BCHコードがBBFの外部エンコーディングに使用される。short FECBLOCK及びlong FECBLOCKに対するBBF生成多項式は、すべての多項式を乗算することで得られる。
【０４００】
LDPCコードは、外部BCHエンコーディングの出力をエンコーディングするために使用される。完成されたBldpc(FECBLOCK)を生成するために、Pldpc(パリティビット)がそれぞれのIldpc(BCH-エンコーディングされたBBF)から組織的にエンコーディングされ、Ildpcに添付される。完成されたBldpc(FECBLOCK)は次の数式で表現される。
【０４０１】
【数３】
0006321195.tif 000033
【０４０２】
long FECBLOCK及びshort FECBLOCKに対するパラメータは、上記表２８及び２９にそれぞれ与えられる。
【０４０３】
long FECBLOCKに対してNldpc-Kldpcパリティビットを計算する具体的な手順は次のようである。
【０４０４】
１)パリティビット初期化
【０４０５】
【数４】
0006321195.tif 000034
【０４０６】
２)パリティチェックマトリックスのアドレスの最初の行で特定されたパリティビットアドレスで最初の情報ビットi０累算(accumulate)。パリティチェックマトリックスのアドレスの詳細な内容は後述する。例えば、比率１３/１５に対して、
【０４０７】
【数５】
0006321195.tif 000035
【０４０８】
３)次の３５９個の情報ビットis、s=１、２、…、３５９に対して、次の数式を利用してパリティビットアドレスでis累算(accumulate)。
【０４０９】
【数６】
0006321195.tif 000036
【０４１０】
ここで、xは最初のビットi０に該当するパリティビット累算器のアドレスを示し、Qldpcはパリティチェックマトリックスのアドレスで特定されたコードレート(code rate)依存定数である。前記例である比率１３/１５に対する、従って情報ビットi１に対するQldpc=２４に引き続き、次の動作が実行される。
【０４１１】
【数７】
0006321195.tif 000037
【０４１２】
４)３６１番目情報ビットi３６０に対して、パリティビット累算器のアドレスは、パリティチェックマトリックスのアドレスの二番目行に与えられる。同一方式で、次の３５９個の情報ビットis、s=３６１、３６２、…、７１９に対するパリティビット累算器のアドレスは、数式６を利用して得られる。ここで、xは情報ビットi３６０に該当するパリティビット累算器のアドレス、すなわちパリティチェックマトリックスの二番目行のエントリーを示す。
【０４１３】
５)同一方式で、３６０個の新しい情報ビットのすべてのグループに対して、パリティチェックマトリックスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めることに使用される。
【０４１４】
すべての情報ビットが利用された後、最終パリティビットが次のように得られる。
【０４１５】
６)i=１で始まり次の動作を順次実行
【０４１６】
【数８】
0006321195.tif 000038
【０４１７】
ここで、pi、i=０、１、...Nldpc-Kldpc-１の最終コンテンツは、パリティビットpiと同一である。
【０４１８】
【表３０】
0006321195.tif 000039
【０４１９】
表３０を表３１に代替し、long FECBLOCKに対するパリティチェックマトリックスのアドレスをshort FECBLOCKに対するパリティチェックマトリックスのアドレスに代替することを除いて、short FECBLOCKに対する当該LDPCエンコーディング手順は、long FECBLOCKに対するt LDPCエンコーディング手順に従う。
【０４２０】
【表３１】
0006321195.tif 000040
【０４２１】
図２３は、本発明の一実施例に係るビットインターリービングを示す。
【０４２２】
LDPCエンコーダの出力は、グループ内インターリービング及びQCB(Quasi-Cyclic Block)によるパリティインターリービングから構成されるビット-インターリーブされる。
【０４２３】
(a)はQCBインターリービングを示し、(b)はグループ内インターリービングを示す。
【０４２４】
FECBLOCKはパリティインターリーブされる。パリティインターリービングの出力で、LDPCコードワードは１８０long FECBLOCK内の隣のQCブロック及びshort FECBLOCK内の４５隣のQCブロックから構成される。longまたはshort FECBLOCKのうちの１つのQCブロックのそれぞれは３６０ビットから構成される。パリティインターリーブされたLDPCコードワードはQCBインターリービングによってインターリーブされる。QCBインターリービングのユニットはQCブロックである。パリティインターリービングの出力に対するQCブロックは、FECBLOCKの長さに従うNcells=６４８００/ηmod or１６２００/ηmodで、図２３に図示されたQCBインターリービングによって変更される。QCBインターリービングパターンは、モジュレーションタイプの結合及びLDPCコード率のそれぞれに対して唯一である。
【０４２５】
QCBインターリービング後、グループ内インターリービングは、以下の表３２に定義された順序(ηmod)及びモジュレーションタイプに応じて実行される。１つのグループ内QCブロックの数、NQCB_IGも定義される。
【０４２６】
【表３２】
0006321195.tif 000041
【０４２７】
グループ内インターリービングプロセスは、QCBインターリービング出力のQCブロックNQCB_IGと一緒に実行される。グループ内インターリービングは、３６０列及びNQCB_IG行を使用したグループ内のビットを読み出しまたは書き込みするプロセスを有する。書き込み動作で、QCBインターリービング出力からビットは行方向に書き込まれる。読み出し動作が実行されると、それぞれの行からmビットを列方向に読み出すことが実行される。MはNUCの１及びNUQの２と同一である。
【０４２８】
図２４は、本発明の一実施例に係るセル-ワードデマルチプレックスを示す。
【０４２９】
(a)は８及び１２bpcu MIMOに対するセル-ワードデマルチプレックスを示し、(b)は１０bpcu MIMOのためのセル-ワードデマルチプレックスを示す。
【０４３０】
それぞれのビットインターリービング出力のそれぞれのセルワード(c０、l、c１、l、…、cnmod-１、l)は、１つのXFECBLOCKのためのセル-ワードデマルチプレックス処理を説明した(a)に示されたように、(d１、０、m、d１、１、m…、d１、Nmod-１、m)及び(d２、０、m、d２、１、m…、d２、Nmod-１、m)でデマルチプレックスされる。
【０４３１】
MIMOエンコーディングのためのNUQの他のタイプを利用する１０bpcu MIMOケースのために、NUQ-１０２４のためのビットインターリーバが再使用される。ビットインターリーバ出力のそれぞれのセルワード(c０、l、c１、l、…、c９、l)は、(b)に示されたように(d１、０、m、d１、１、m…、d１、３、m)及び(d２、０、m、d２、１、m…、d２、５、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を含むことができる。タイムインターリービンググループが多数のタイムインターリービングブロックに分離されると、タイムインターリービンググループは、１つのフレームのみに直接マッピングされる。以下の表３２に示したように、タイムインターリービングには３種類のオプションがある(タイムインターリービングを省略する追加オプション除外)。
【０４４４】
【表３３】
0006321195.tif 000042
【０４４５】
各々のデータパイプで、タイムインターリービングメモリは入力されたＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックから出力されたＸＦＥＣＢＬＯＣＫ）を格納する。入力されたＸＦＥＣＢＬＯＣＫは、
【数９】
0006321195.tif 000043
として定義されると仮定する。ここで、ｄｎ，ｓ、ｒ、ｑはｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｒ番目ＸＦＥＣＢＬＯＣＫのｑ番目セルであり、次のようなＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。
【０４４６】
【数１０】
0006321195.tif 000044
【０４４７】
一般的に、タイムインターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファとしても作用する。これは、それぞれのデータパイプに対して２つのメモリバンクで達成される。最初のタイムインターリービングブロックは最初のバンクに記入される。最初のバンクで判読される間、二番目のタイムインターリービングブロックが二番目バンクに記入される。
【０４４８】
タイムインターリービングは、ツイスト行列ブロックインターリーバである。n番目のタイムインターリービンググループのs番目のタイムインターリービングブロックに対して、列の数ＮｃがＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）と同一である反面、タイムインターリービングメモリの行の数Ｎｒはセルの数Ｎcellsと同一である(すなわち、Ｎｒ＝Ｎcells)。
【０４４９】
図２６は、本発明の一実施例に係るツイスト行列ブロックインターリーバの基本動作を示す。
【０４５０】
図２６(a)はタイムインターリーバで記入動作を示し、図２６(b)はタイムインターリーバで判読動作を示す。(a)に示したように、最初のXFECBLOCKはタイムインターリービングメモリの最初の列に列方向に記入され、二番目のXFECBLOCKは次の列に記入され、このような動作が続けられる。そしてインターリービングアレイで、セルが対角線方向に判読される。(b)に示したように、最初の行から(最も左側列を始めとしえ行に沿って右側に)最後の行まで対角線方向の判読が行われる間、Ｎｒ個のセルが判読される。具体的に、ｚｎ，ｓ，ｉ（ｉ＝０，．．．，ＮｒＮｃ）が順次判読されるタイムインターリービングメモリセル位置であると仮定する場合、このようなインターリービングアレイでの判読動作は、以下の式のように行インデックスＲｎ,s,i、列インデックスＣｎ,s,i 、関連したツイストパラメータＴｎ,s,iを算出することで実行される。
【０４５１】
【数１１】
0006321195.tif 000045
【０４５２】
ここで、ＳshiftはＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく対角線方向の判読過程に対する共通シフト値であり、シフト値は、以下の数式のようにPLS２-STATから与えられたＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸによって決定される。
【０４５３】
【数１２】
0006321195.tif 000046
結果的に、判読されるセルの位置は座標ｚｎ,s,i＝ＮｒＣｎ，ｓ，ｉ+Ｒｎ，ｓ，ｉによって計算される。
【０４５４】
図２７は、本発明の他の一実施例に係るツイスト行列ブロックインターリーバの動作を示す。
【０４５５】
さらに具体的に、図３７は、ＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５であるとき、仮想XFECBLOCKを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリにおいてインターリービングアレイを示す。
【０４５６】
変数ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）＝ＮｒはＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸより小さいか同一である。従って、ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく、受信機側で単一メモリディインターリービングを達成するために、ツイスト行列ブロックインターリーバ用インターリービングアレイは、仮想XFECBLOCKをタイムインターリービングメモリに挿入することで、Ｎｒ×Ｎｃ＝Ｎcells×Ｎ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸの大きさに設定され、判読過程は次の数式のようになされる。
【０４５７】
【数１３】
0006321195.tif 000047
【０４５８】
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、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データでシグナリングされて、
【数１４】
0006321195.tif 000048
【０４５９】
図２８は、本発明の一実施例に係るツイスト行列ブロックインターリーバの対角線方向の判読パターンを示す。
【０４６０】
さらに具体的に、図２８はパラメータＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ＝７及びSshift=(７-１)/２=３を有するそれぞれのインターリービングアレイからの対角線方向の判読パターンを示す。このとき、上記擬似コードで示した判読過程で、
【数１５】
0006321195.tif 000049
Viの値が省略され、Viの次の計算値が使用される。
【０４６１】
図２９は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたXFECBLOCKを示す。
【０４６２】
図２９は、パラメータＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ＝７及びSshift=３を有するそれぞれのインターリービングアレイからインターリービングされたXFECBLOCKを示す。
【０４６３】
図３０は、本発明の他の実施例に係る放送受信装置の構成を示す。
【０４６４】
図３０の実施例で、放送受信装置１００は、放送受信部１１０、インターネットプロトコル(Internet Protocol、IP)通信部１３０及び制御部１５０を含む。
【０４６５】
放送受信部１１０は、放送受信部１１０が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に、放送受信部１１０は多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。放送受信部１１０は、物理層モジュール１１９と物理層IPフレームモジュール１１７を含むことができる。物理層モジュール１１９は、放送網の放送チャネルを介して放送関連信号を受信して処理する。物理層IPフレームモジュール１１７は、物理層モジュール１１９から獲得したIPデータグラムなどのデータパケットを特定フレームに変換する。例えば、物理層モジュール１１９は、IPデータグラムなどをRS FraemまたはGSEなどに変換することができる。
【０４６６】
IP通信部１３０は、IP通信部１３０が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的にIP通信部１３０は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。IP通信部１３０は、インターネット接近制御モジュール１３１を含むことができる。インターネット接近制御モジュール１３１は、インターネット通信網(broad band)を介してサービス、コンテンツ及びシグナリングデータのうち少なくともいずれか１つを獲得するための放送受信装置１００の動作を制御する。
【０４６７】
制御部１５０は、制御部１５０が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に制御部１５０は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。制御部１５０は、シグナリングデコーダ１５１、サービスマップデータベース１６１、サービスシグナリングチャネルパーサー１６３、アプリケーションシグナリングパーサー１６６、警告シグナリングパーサー１６８、ターゲティングシグナリングパーサー１７０、ターゲティングプロセッサ１７３、A/Vプロセッサ１６１、警告プロセッサ１６２、アプリケーションプロセッサ１６９、スケジュールされたストリーミングデコーダ(scheduled streaming decoder)１８１、ファイルデコーダ１８２、ユーザ要求ストリーミングデコーダ１８３、ファイルデータベース１８４、コンポーネント同期化部１８５、サービス/コンテンツ獲得制御部１８７、再分配モジュール１８９、デバイスマネージャ１９３及びデータシェアリング部１９１のうち少なくともいずれか１つを含むことができる。
【０４６８】
サービス/コンテンツ獲得制御部１８７は、放送網またはインターネット通信網を介して獲得したサービス、コンテンツ、サービスまたはコンテンツに関連したシグナリングデータ獲得のための受信機の動作を制御する。
【０４６９】
シグナリングデコーダ１５１は、シグナリング情報をデコーディングする。
サービスシグナリングパーサー１６３は、サービスシグナリング情報を解析する。
【０４７０】
アプリケーションシグナリングパーサー１６６は、サービスに関するシグナリング情報を抽出して解析する。このとき、サービスに関連したシグナリング情報は、サービススキャンに関連したシグナリング情報を含むことができる。また、サービスに関連したシグルロリン情報は、サービスを介して提供されるコンテンツに関連したシグナリング情報を含むことができる。
【０４７１】
警告シグナリングパーサー１６８は、警告に関するシグナリング情報を抽出して解析する。
【０４７２】
ターゲティングシグナリングパーサー１７０は、サービスまたはコンテンツを個人化(personalization)するための情報またはターゲティング情報をシグナリングする情報を抽出して解析する。
【０４７３】
ターゲティングプロセッサ１７３は、サービスまたはコンテンツを個人化するための情報を処理する。
【０４７４】
警告プロセッサ１６２は、災難警報(emergency alert)に関するシグナリング情報を処理する。
【０４７５】
アプリケーションプロセッサ１６９は、アプリケーション関連情報及びアプリケーションの実行を制御する。具体的には、アプリケーションプロセッサ１６９は、ダウンロードされたアプリケーションの状態及びディスプレイパラメータを処理する。
【０４７６】
A/Vプロセッサ１６１は、デコーディングされたオーディオまたはビデオ、アプリケーションデータなどに基づいて、オーディオ/ビデオのレンダリング関連動作を処理する。
【０４７７】
スケジュールされたストリーミングデコーダ１８１は、予め放送局などのコンテンツ提供業者が定めた日程とおりストリーミングされるコンテンツであるスケジュールされたストリーミングをデコーディングする。
【０４７８】
ファイルデコーダ１８２は、ダウンロードされたファイルをデコードする。特にファイルデコーダ１８２はインターネット通信網を介してダウンロードされたファイルをデコードする。
【０４７９】
ユーザ要求ストリーミングデコーダ１８３は、ユーザ要求によって提供されるコンテンツ(On Demand Content)をデコードする。
【０４８０】
ファイルデータベース１８４は、ファイルを格納する。具体的にファイルデータベース１８４は、インターネット通信網を介してダウンロードしたファイルを格納することができる。
【０４８１】
コンポーネント同期化部１８５は、コンテンツまたはサービスを同期化する。具体的にコンポーネント同期化部１８５は、スケジュールされたストリーミングデコーダ１８１、ファイルデコーダ１８２及びユーザ要求ストリーミングデコーダ１８３のうち少なくともいずれか１つが、デコーディングしたコンテンツを同期化することができる。
【０４８２】
サービス/コンテンツ獲得制御部１８７は、サービス、コンテンツ、サービスまたはコンテンツに関するシグナリング情報のうち少なくともいずれか１つを獲得するための受信機の動作を制御する。
【０４８３】
再分配モジュール１８９は、放送網を介してサービスまたはコンテンツを受信できない場合、サービス、コンテンツ、サービスに関連情報及びコンテンツ関連情報のうち少なくともいずれか１つの獲得を支援するための動作を行う。具体的に、外部の管理装置３００にサービス、コンテンツ、サービスに関連情報及びコンテンツ関連情報のうち少なくともいずれか１つを要求することができる。このとき、外部の管理装置３００は、コンテンツサーバーからなることができる。
【０４８４】
デバイスマネージャ１９３は、連動可能な外部装置を管理する。具体的にデバイスマネージャ１９３は、外部装置の追加、削除及び更新のうち少なくともいずれか１つを行うことができる。また、外部装置は放送受信装置１００と連結及びデータ交換が可能である。
データシェアリング部１９１は、放送受信装置１００と外部装置の間のデータ伝送動作を行い、交換関連情報を処理する。具体的に、データシェアリング部１９１は、外部装置にA/Vデータまたはシグナリング情報を伝送することができる。また、データシェアリング部１９１は、外部装置にA/Vデータまたはシグナリング情報を受信することができる。
【０４８５】
スマートフォンやタブレットなどの端末装置の使用が増加することによって、これらの端末装置と連動できる放送サービスが増えている。これにより、端末装置は、放送サービスと連動して動作するために、放送サービスに関する情報を示す放送サービスの属性を必要とする。但し、連動装置が放送サービスを直接受信しない場合が多い。このような場合、連動装置は、放送伝送装置を介して放送サービスの属性を獲得しなければならない。従って、放送サービスの属性を効率的に伝送することができる放送受信装置と放送受信装置の動作方法が必要である。これについて、図３１〜図４３に基づいて説明する。
【０４８６】
図３１は、本発明の一実施例に係る連動装置と連動する放送サービスを提供する放送システムを示す。
【０４８７】
本発明の一実施例に係る放送システムは、放送受信装置１００、連動(Companion)装置２００、放送伝送装置３００、コンテンツ/シグナリングサーバ４００及びACRサーバ５００を含む。
【０４８８】
放送伝送装置３００は、放送サービスを伝送する放送サーバを示す。このとき、放送受信装置１００は、放送伝送装置３００から放送網(Broadcast channel)を介して放送サービスを受信する。また、放送受信装置１００は、放送網を介して放送伝送装置３００から放送サービスをシグナリングする情報を受信することができる。また、放送受信装置１００は、放送網を介して放送伝送装置３００からトリガ、トリガパラメータテーブル(Trigger Parameter Table、TPT)、トリガ宣言的オブジェクト(Trigger Declarative Object、TDO)のような放送サービスのための付加情報を受信することができる。
【０４８９】
コンテンツ/シグナリングサーバ４００は、放送サービスに関するコンテンツを生成して管理する。このとき、放送受信装置１００は、通信網(Broadband channel)を介してコンテンツ/シグナリングサーバ４００から放送サービスに関する付加情報及び放送サービスのシグナリング情報のうち少なくともいずれか１つを受信することができる。
【０４９０】
自動コンテンツ認識(Automatic Content Recognition、ACR)サーバ３００は、放送サービスに関するACR関連データを管理する。このとき、放送受信装置１００は、通信網(Broadband channel)を介してACRサーバ３００からトリガ(trigger)及び放送サービスに関するアプリケーションのうち少なくともいずれか１つを受信することができる。
【０４９１】
連動装置２００は、ホームネットワークを介して放送受信装置１００と連動して放送サービスに関する付加機能を実行する。具体的に連動装置２００は、放送サービスに関するアプリケーション及びファイルのうち少なくともいずれか１つを獲得することができる。また、連動装置２００は、放送サービスに関するアプリケーション及びファイルを実行することができる。このとき、連動装置２００は、ホームネットワークの代わりに３GPPのような移動通信網やHTTPプロキシ(Proxy)サーバを利用することができる。また、具体的な実施例において放送サービスに関するアプリケーションやファイルが単方向ファイル伝送セッション(File Delivery over Unidirectional Transport、FLUTE)を介して伝送される場合、連動装置２００は、放送受信装置１００から放送サービスに関するアプリケーション及びファイルのうち少なくともいずれか１つを受信することができる。また、連動装置２００は、セカンドスクリーン装置(second screen device)といえる。また、連動装置２００は、スマートフォン、タブレット及びラップトップのうち少なくともいずれか１つを含むことができる。具体的に連動装置２００は、放送網を介した放送受信機能を持たずネットワークなどの通信機能を持つ端末装置であってもよい。また、連動装置２００は、１つまたは複数個が存在してもよい。連動装置２００は、連動装置２００の全体的な動作を制御する制御部と、外部装置との通信を行う通信部を含むことができる。制御部は、制御部が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に制御部は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。また、通信部は、通信部が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に通信部は、多様な半導体部品が１つに集積されるSOC(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。
【０４９２】
また、放送受信装置１００は、主装置(Primary Device)と呼ぶことができる。
【０４９３】
また、具体的な実施例により、放送伝送装置３００、コンテンツ/シグナリングサーバ４００及びACRサーバ５００のうち少なくともいずれか２つが１つのサーバーに統合されて使用される。
【０４９４】
前述したように、放送受信装置１００は、放送伝送装置３００から放送サービスのシグナリング情報を受信することができる。または放送受信装置１００は、コンテンツ/シグナリングサーバ４００から放送サービスのシグナリング情報を受信することができる。このとき、放送サービスのシグナリング情報は、放送サービスの属性を含むことができる。これについては、図３２に基づいて詳しく説明する。
【０４９５】
図３２は、本発明の一実施例によりシグナリングされる放送サービスの属性を示す。
【０４９６】
放送受信装置１００が受信する放送サービスのシグナリング情報は、放送サービスの属性を含むことができる。このとき、放送サービスの属性は、放送サービスを識別する放送サービス識別子、放送サービスの名称、放送サービスのチャネル番号、放送サービスに関する説明、放送サービスのジャンル、放送サービスを表すアイコン、放送サービスの主言語、放送サービスに関する使用報告情報、放送サービスを提供できる装置の情報を示すターゲティング属性、放送サービスの保護(protection)に関する属性、勧告グレード、放送サービスが含むメディアコンポーネントに関する情報のうち少なくともいずれか１つを含むことができる。ターゲティング属性は、サービスが提供される装置を示すものとして、主装置または連動装置２００のうち少なくともいずれか１つを示すことができる。放送サービスのチャネル番号は、メジャーチャネル番号とマイナーチャネル番号を含むことができる。メディアコンポーネントに関する情報は、メディアコンポーネントを識別する識別子、メディアコンポーネントの種類、メディアコンポーネントの名称、メディアコンポーネントの開始時間、メディアコンポーネントの再生時間(duration)、メディアコンポーネントがターゲティングするスクリーンを示す情報、メディアコンポーネントを受信することができるURL、メディアコンポーネントの勧告グレード及びメディアコンポーネントのジャンルのうち少なくともいずれか１つを含むことができる。このとき、メディアコンポーネントがターゲティングするスクリーンは、連動装置２００を示すことができる。
【０４９７】
放送サービスの属性は、図３３のように、XML形式でシグナリングされてもよい。但し、放送サービスの属性のシグナリング形式は、これに限定されるものではなく、ビットストリームのように、別の形式でシグナリングされてもよい。
【０４９８】
具体的に、放送サービスの属性をシグナリングする情報は、ServiceID、ServiceName、MajorChanNum、MinorChanNum、Description、Genre、Icon、Language、UsageReportingInfo、Targeting、ServiceProtection、AdvisoryRatingのうち少なくともいずれか１つをエレメント(element)として含むことができる。
【０４９９】
ServiceIDは、サービスを識別する放送サービス識別子を示す。このとき、ServiceIDは、１つだけ存在してもよい。また、具体的な実施例においてServiceIDは、アンサインドショート(unsigned short)データタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ServiceIDに基づいて放送サービスを識別することができる。
【０５００】
ServiceNameは、放送サービスの名称を示す。ServiceNameは存在しないか、単数または複数個存在してもよい。具体的な実施例においてServiceNameは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ServiceNameに基づいて放送サービスの名称を表示することができる。
【０５０１】
MajorChanNumとMinorChanNumは、放送サービスのチャネル番号のメジャー番号とマイナー番号をそれぞれ示す。具体的な実施例においてMajorChanNumとMinorChanNumは存在しないか、１つ存在してもよい。また、MajorChanNumとMinorChanNumは、０から１５の間の数字のうちいずれか１つの整数値を有することができる。MajorChanNumとMinorChanNumは、ユーザの放送サービスの選択を容易にするために使用される。具体的に、放送受信装置１００と連動装置２００は、MajorChanNumとMinorChanNumに基づいて放送サービスのチャネル番号を表示することができる。
【０５０２】
Descriptionは、放送サービスに関する説明を示す。Descriptionは存在しないか、単数または複数個存在してもよい。Descriptionは、ストリングデータタイプを有することができる。ユーザは、Descriptionを介して放送サービスの内容を推測することができる。具体的に、放送受信装置１００と連動装置２００は、Descriptionに基づいて放送サービスに関する説明を表示することができる。
【０５０３】
Genreは、放送サービスのジャンルを示す。Genreは存在しないか、単数または複数個存在してもよい。具体的な実施例においてGenreは、ストリングデータタイプを有することができる。ユーザは、Genreを介して放送サービスのジャンルがわかる。具体的に、放送受信装置１００と連動装置２００は、Genreに基づいて放送サービスのジャンルを表示することができる。
【０５０４】
Iconは、放送サービスを表すアイコンを示す。Iconは存在しないか、単数または複数個存在してもよい。Iconは、ベース６４バイナリデータタイプ(Base ６４ Binary data type)を有することができる。ユーザは、放送サービスを代表するアイコンを介して放送サービスの内容を容易に把握することができる。具体的に、放送受信装置１００と連動装置２００は、Iconに基づいて放送サービスを表すアイコンを表示することができる。
【０５０５】
Lagnguageは、放送サービスの主言語を示す。Lagugageは存在しないか、１つ存在してもよい。Lagnguageは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、Languageに基づいて放送サービスの主言語を表示することができる。
【０５０６】
UsageReportingInfoは、放送サービスに関する使用報告情報を示す。UsageReportingInfoは存在しないか、単数または複数個存在してもよい。UsageReportingInfoは、ストリングデータタイプを有することができる。具体的にUsageReportingInfoは、使用情報報告のためのパラメータとして使用される。例えば、UsageReportingInfoは使用情報報告のためのURL及び報告周期のうち少なくともいずれか１つを含むことができる。このような使用情報報告を介して、放送サービスプロバイダは放送サービスの使用情報と放送サービスに関する課金情報を獲得することができる。具体的に、放送受信装置１００と連動装置２００は、UsageReportingInfoに基づいて放送サービスの使用情報を報告することができる。
【０５０７】
Targetingは、放送サービスのターゲティング属性を示す。Targetingは存在しないか、単数または複数個存在してもよい。具体的にTargetingはストリングデータタイプを有することができる。具体的にTargetingは、当該放送サービスが放送受信装置１００のような主装置のためのものか連動装置２００のためのものかを示すことができる。具体的に、放送受信装置１００と連動装置２００は、Targetingに基づいて放送サービスの表示可否を決定することができる。
【０５０８】
ServiceProtectionは、放送サービスの保護(protection)に関する属性を示す。ServiceProtectionは存在しないか、１つ存在してもよい。具体的にServiceProtectionは、ストリングデータタイプを有することができる。
【０５０９】
AdvisoryRatingは、放送サービスの勧告グレードを示す。AdvisoryRatingは存在しないか、単数または複数個存在してもよい。AdvisoryRatingは、ストリングデータタイプを有することができる。放送受信装置１００と連動装置２００は、勧告グレードと個人化情報に基づいて放送サービスを遮断することができる。
【０５１０】
ComponentItemは、放送サービスが含むメディアコンポーネントに関する情報を示す。具体的にComponentItemは、componentId、ComponentType、ComponentName、StartTime、Duration、TargetScreen、URL、ContentAdvisory及びGenreのうち少なくともいずれか１つを含むことができる。
【０５１１】
ComponentIdは、当該メディアコンポーネントを識別する識別子を示す。具体的にComponentIdは、１つ存在してもよい。具体的にComponentIdは、アンサインドデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ComponentIdに基づいてメディアコンポーネントを識別することができる。
【０５１２】
CmponentTypeは、当該メディアコンポーネントの種類を示す。具体的にCmponentTypeは、１つ存在してもよい。CmponentTypeは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、CmponentTypeに基づいてメディアコンポーネントの種類を表示することができる。
【０５１３】
ComponentNameは、当該メディアコンポーネントの名称を示す。具体的にComponentNameは存在しないか、単数または複数個存在してもよい。ComponentNameは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ComponentNameに基づいてメディアコンポーネントの名称を表示することができる。
【０５１４】
StartTimeは、当該メディアコンポーネントの開始時間を示す。具体的にStartTimeは存在しないか、１つ存在してもよい。具体的にStartTimeは、アンサインドショートデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、StartTimeに基づいてメディアコンポーネントの開始時間を判断することができる。
【０５１５】
Durationは、当該メディアコンポーネントの再生長を示す。具体的にDurationは存在しないか、１つ存在してもよい。具体的にDurationは、アンサインドショートデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、Durationに基づいてメディアコンポーネントの再生長を判断することができる。
【０５１６】
TargetScreenは、当該メディアコンポーネントがターゲティングするスクリーンを示す。具体的にTargetScreenは存在しないか、単数または複数個存在してもよい。具体的にTargetScreenは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、TargetScreenに基づいて当該メディアコンポーネントの再生が必要か否かを判断することができる。
【０５１７】
URLは、メディアコンポーネントを受信するためのアドレスを示すことができる。具体的にURLは存在しないか、単数または複数個存在してもよい。具体的にURLは、URIデータタイプを有することができる。具体的にURLは、コンテンツ/シグナリングサーバ４００のアドレスを示すことができる。具体的に、放送受信装置１００と連動装置２００は、URLに基づいてメディアコンポーネントを受信することができる。
【０５１８】
ContentAdvisoryは、当該メディアコンポーネントの勧告グレードを示す。ContentAdvisoryの値がAdvisoryRatingと衝突(conflict)する場合、ContentAdvisoryの値が優先することができる。具体的にContentAdvisoryは、単数または複数個存在してもよい。具体的にContentAdvisoryは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ContentAdvisoryに基づいてメディアコンポーネントの再生可否を決定することができる。
【０５１９】
Genreは、メディアコンポーネントのジャンルを示す。具体的にGenreは、単数または複数個存在してもよい。Genreは、ストリングデータタイプを有することができる。前述したサービスのジャンルを示すGenreと衝突する場合、メディアコンポーネントのジャンルを示すGenreが優先することができる。具体的に、放送受信装置１００と連動装置２００は、Genreに基づいてメディアコンポーネントのジャンルを表示することができる。
【０５２０】
前述したように、放送受信装置１００と連動装置２００は、ホームネットワーク、３GPPのような移動通信網及びHTTPプロキシサーバのうち少なくともいずれか１つを介して放送受信装置２００と連動することができる。このとき、放送受信装置１００と連動装置２００との間の通信は様々な方式により行われる。具体的に、放送受信装置１００と連動装置１００との間の通信は、汎用プラグ及びプレイ(Universal Plug and Play、UPnP)方式により行われる。
【０５２１】
UPnPは、コントロールポイント(Control Point、CP)とコントロールされる装置(Controlled Deivcies、CDs)に装置を区別する。コントロールポイントは、UPnPプロトコルを利用してコントロールされる装置を制御する。具体的な実施例においては、放送受信装置１００がコントロールされる装置のうちの１つに該当する。また、連動装置２００は、コントロールポイントに該当する。UPnPでは、ディスカバリー(discovery)、ディスクリプション(description)、コントロール(control)及びイベンティング(eventing)プロトコルを定義する。ディスカバリープロトコルは、コントロールポイントがコントロールされる装置を探すためのプロトコルである。ディスクリプションプロトコルは、コントロールポイントがコントロールされる装置の情報を獲得するためのプロトコルである。コントロールプロトコルは、コントロールポイントがコントロールされる装置に一定の動作を誘発(invoke)するためのものである。イベンティングプロトコルは、コントロールされる装置が非同期化された通知(notifications)をコントロールポイントに伝送(delivery)するためのものである。本発明の一実施例に係る放送受信装置１００と連動装置２００は、UPnPプロトコルのディスカバリー(discovery)、ディスクリプション(description)、コントロール(control)及びイベンティング(eventing)プロトコルのうち少なくともいずれか１つを使用して連動することができる。例えば、放送受信装置１００がディスカバリープロトコルを利用して連動装置２００を探すことができる。放送受信装置１００と連動装置２００の動作については、図３３〜図４３に基づいて詳しく説明する。
【０５２２】
図３３は、本発明の一実施例によりシグナリングされる放送サービスの属性の状態を示す変数を示す。
【０５２３】
放送受信装置１００は、連動装置に放送サービスの属性を示す１つの変数を利用して伝送することができる。放送サービスの属性を示す１つの変数は、現在の放送サービスの属性を含むことができる。具体的に、図３３の実施例のように、ServicePropertyという変数を介して伝送することができる。具体的な実施例においてServicePropertyは必須変数であり、ストリングデータタイプを有することができる。また、具体的な実施例においてServicePropertyは、関連アクションを有しなくてもよい。ServicePropertyに対する購読(subscription)を要求する場合、放送受信装置１００はServicePropertyを連動装置に伝送することができる。放送受信装置１００が放送サービスの属性を伝送する具体的な過程については、図３４に基づいて説明する。
【０５２４】
図３４は、本発明の一実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【０５２５】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２００１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。具体的に、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的に、放送受信装置１００と連動装置２００は、UPnPプロトコルを利用してペアリングセッションを生成することができる。具体的な実施例において、放送受信装置１００がUPnPのディスカバリープロトコルを利用して連動装置２００を探すことができる。例えば、放送受信装置１００がウェルノウン(well known)IPアドレスを介して、連動のための連動装置を探すというディスカバリーメッセージをマルチキャストすることができる。このとき、マルチキャストされたメッセージを受信した連動装置２００は、放送受信装置１００にディスクリプションを要求することができる。放送受信装置１００は、連動装置２００のディスクリプション要求に基づいて連動装置２００にディスクリプションを提供することができる。連動装置２００は、ディスクリプションに基づいて放送受信装置２００に接続することができる。他の具体的な実施例において、連動装置２００がUPnPのディスカバリープロトコルを利用して放送受信装置１００を探すことができる。例えば、連動装置２００は、ウェルノウン(well known)IPアドレスを介して、連動のための放送受信装置１００を探すというメッセージをマルチキャストすることができる。このとき、放送受信装置は、マルチキャストされたメッセージに基づいてディスカバリーメッセージで応答することができる。これにより、ディスカバリーメッセージを受信した連動装置２００は、放送受信装置１００にディスクリプションを要求することができる。放送受信装置１００は、連動装置２００のディスクリプション要求に基づいて、連動装置２００にディスクリプションを提供することができる。連動装置２００は、ディスクリプションに基づいて放送受信装置２００に接続することができる。
【０５２６】
連動装置２００は、放送受信装置１００に放送サービスの属性通知を要求する(Ｓ２００３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的に連動装置２００は、UPnPプロトコルを利用して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的な実施例において連動装置２００は、イベンティングプロトコルに基づいて放送受信装置１００に放送サービスの属性に対するイベントの購読(subscription)を要求することができる。
【０５２７】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２００５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５２８】
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性を通知する(notify)(Ｓ２００７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性を通知する。具体的に、放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の状態を示す変数を介して放送サービスの属性を通知することができる。具体的な実施例において放送サービスの属性の状態を示す変数は、図３３のServicePropertyであってもよい。放送サービスの属性の状態を示す変数のデータ形式については、図３５に基づいて詳しく説明する。
【０５２９】
図３５は、本発明の一実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性のデータ形式を示す。
【０５３０】
放送サービスの属性のデータは、図３５のようにXML形式であってもよい。但し、放送サービスの属性のデータ形式はこれに限定されるものではない。図３５の実施例において放送サービスの属性のデータ形式は、図３２で説明した放送サービスの属性をすべて含む。従って、放送サービスの属性のうち一部だけが変更された場合でも放送受信装置１００は、放送サービスの属性全体を伝送しなければならず、連動装置２００は、放送サービスの属性全体を受信しなければならない。このような場合、放送受信装置１００と連動装置２００との間で交換されるデータ量が大きくなる。また、連動装置２００は、どの放送サービスの属性が変更されたかを再確認しなければならない。従って、放送受信装置１００が連動装置２００に放送サービスの属性を効率的にシグナリングする方法が必要である。これについては、図３６〜図３８に基づいて説明する。
【０５３１】
図３６は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数、放送サービスの属性のためのアクション及びアクションの引数(argument)を示す。
【０５３２】
本発明の他の実施例において放送サービスの属性を示す変数は、放送サービスの属性を含む変数、放送サービスの属性の名称を示す変数及び放送サービスの属性の変更可否を示す変数のうち少なくともいずれか１つを含むことができる。具体的に連動装置２００が放送サービスの特定属性を要求する場合、放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの属性を伝送することができる。具体的に、放送受信装置１００は、連動装置２００が要求した放送サービスの特定属性を伝送することができる。例えば、放送受信装置１００が放送サービスの属性の変更可否を示す変数を介して連動装置２００に放送サービスの属性の変更可否を通知することができる。このとき、連動装置２００は、必要な放送サービスの属性を、放送サービスの属性の名称を示す変数を介して放送サービスの属性を要求することができる。放送受信装置１００は、連動装置に放送サービスの属性を示す変数を介して放送サービスの属性を通知することができる。
【０５３３】
具体的な実施例において放送サービスの属性を示す変数は、ServiceProperty、ServicePropertyName及びServicePropertyChangeFlagのうちいずれか１つを含むことができる。ServicePropertyは、放送サービスの属性を含む。具体的な実施例においてServicePropertyは必須変数であり、ストリングデータタイプを有することができる。ServicePropertyNameは、放送サービスの属性の名称を示す。ServicePropertyNameは必須変数であり、ストリングデータタイプを有することができる。ServicePropertyChangeFlagは、放送サービスの属性の変更可否を示す。具体的な実施例においてServicePropertyChangeFlagは必須変数であり、Boolean data typeを有することができる。また、連動装置２００がServicePropertyChangeFlagに対する購読(subscription)を要求する場合、放送受信装置１００は、ServicePropertyChangeFlagを連動装置に伝送することができる。
【０５３４】
連動装置２００は、放送サービスの属性の名称を示す変数を介して放送サービスの属性を要求するために、GetServicePropertyというアクションを使用することができる。GetServicePropertyは必須アクションである。このとき、GetServicePropertyは入力のための引数として、ServiceProgpertyNameを有することができる。また、GetServicePropertyは出力のための引数として、ServicePropertyを有することができる。具体的な実施例において、連動装置２００が放送受信装置１００に獲得しようとする放送サービスの属性をSevicePropertyNameに設定してGetServicePropertyアクションを伝送する場合、連動装置２００は、ServicePropertyNameに該当する放送サービスの属性をServicePropertyで受信することができる。放送受信装置１００と連動装置２００の動作については、図３７に基づいて詳しく説明する。
【０５３５】
図３７は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【０５３６】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２０２１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３４の実施例と同一であってもよい。
【０５３７】
連動装置２００は、放送受信装置１００に放送サービスの属性変更通知を要求する(Ｓ２０２３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性変更通知を要求することができる。具体的な連動装置２００の動作は、図３４の実施例と同一であってもよい。
【０５３８】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２０２５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５３９】
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更可否を通知する(notify)(Ｓ２０２７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更できるか否かを通知することができる。具体的に、放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性変更を通知することができる。具体的に、放送受信装置１００は、放送サービスの属性をシグナリングする情報のバージョンが以前に比べて変更されたかに基づいて、放送サービスの属性の変更可否を判断することができる。また、具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否を示す変数を介して放送サービスの属性の変更可否を通知することができる。具体的な実施例において放送サービスの属性の変更可否を示す変数は、図３３のServicePropertyChangedFlagであってもよい。このとき、放送サービスの属性の変更可否を示すデータ形式については、図３８に基づいて詳しく説明する。
【０５４０】
図３８は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の変更可否のデータ形式を示す。
【０５４１】
放送サービスの属性の変更可否のデータ形式は、XML形式であってもよい。但し、放送サービスの属性の変更可否のデータ形式はこれに限定されるものではない。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否のみを通知することができる。図３８の実施例にように、放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否をTRUE値またはFALSE値を有するBoolean変数で表示することができる。例えば、放送サービスの属性が変更された場合、放送受信装置１００は連動装置２００に放送サービスの属性の変更可否を示す変数がTRUE値を有するデータを伝送することができる。但し、このような実施例において連動装置２００は、放送サービスのどの属性が変更されたかわからず、放送サービスの属性のいずれかが変更されたことしかわからない。このため、連動装置２００は自身が必要としない放送サービスの属性が変更された場合でも放送サービスの属性を要求することになる。従って、このような実施例は、放送受信装置１００と連動装置２００の不必要な動作と不必要なデータ交換を誘発する可能性がある。これを解決するために放送受信装置１００は変更された放送サービスの属性を連動装置２００に通知する必要がある。これについては、図３９〜図４０に基づいて説明する。
【０５４２】
図３９は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
【０５４３】
放送サービスの属性が変更された場合、放送受信装置１００は、連動装置２００に変更された属性と放送サービスの属性の変更可否を共に通知することができる。このために、放送サービスの属性の変更可否を示す変数が変更されたサービスの属性を示す情報を含むことができる。このために、放送サービスの属性の変更可否を示す変数は、バイナリヘキサタイプ(binary hex type)を有することができる。従って、他の変数、アクション及びアクションの引数は同一であり、図３６の実施例において放送サービスの属性の変更可否を示す変数であるServicePropertyChangedFlagは、バイナリヘキサタイプ(binary hex type)からなることができる。ServicePropertyChangedFlagに対する購読(subscription)を要求する場合、放送受信装置１００は、ServicePropertyChangedFlagを連動装置に伝送することができる。放送受信装置１００が連動装置２００にシグナリングする放送サービスの属性の変更可否のデータ形式については、図４０に基づいて説明する。
【０５４４】
図４０は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の変更可否のデータ形式を示す。
【０５４５】
放送サービスの属性の変更可否のデータは、XML形式であってもよい。但し、放送サービスの属性の変更可否のデータ形式はこれに限定されるものではない。放送受信装置１００は、放送サービスの属性のそれぞれに対して特定のビットを割り当てて、放送サービスの属性が変更された場合、当該ビットを１に表示することができる。図４０の実施例において１６進数９００８０００４は、２進数１００１００００００００１００００００００００００１００である。このとき、最初の４桁のビットがそれぞれ放送サービスの主言語、ジャンル、勧告グレード及びターゲティング属性をそれぞれ示すといえる。この場合、連動装置２００は、放送サービスの主言語及びターゲティング属性が変更されたことがわかる。
【０５４６】
図３７に戻って、本発明の他の実施例により放送受信装置１００が連動装置２００に放送サービスの属性をシグナリングすることを説明する。
【０５４７】
連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求する(Ｓ２０２９)。放送サービスの特定属性は、放送サービスの属性をシグナリングする情報に含まれた放送サービスの属性のうちいずれか１つまたは複数の属性からなることができる。連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性を要求することができる。具体的に、放送受信装置１００が放送サービスの属性変更通知を伝送した場合、連動装置２００は放送受信装置１００に放送サービスの特定属性を要求することができる。このとき、放送サービスの特定属性は、連動装置２００が放送サービスに関する付加サービスを提供するために必要な放送サービスの属性であってもよい。また、図４１〜図４２のように、放送受信装置１００が放送サービスの属性のうち変更された部分をシグナリングした場合、連動装置１００は変更された放送サービスの属性の種類に基づいて放送サービスの特定属性を要求することができる。具体的に連動装置２００は、放送サービスの特定属性が変更された場合、放送サービスの特定属性を要求することができる。放送サービスの特定属性は、連動装置２００が放送サービスに関する付加サービスを提供するために必要な属性であってもよい。例えば、連動装置２００が放送サービスのターゲティング属性に基づいて放送サービスの再生可否を決定する場合、連動装置２００は放送サービスのターゲティング属性が変更された場合に放送サービスのターゲティング属性を要求することができる。
【０５４８】
放送受信装置１００は、連動装置２００に放送サービスの特定属性を通知する(Ｓ２０３１)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの特定属性を通知することができる。具体的に、放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの特定属性を通知することができる。例えば、放送受信装置１００は、連動装置２００に連動装置２００が要求した放送サービスの特定属性を伝送することができる。
【０５４９】
但し、このような実施例は、放送受信装置１００と連動装置２００との間の持続的な通信を必要とすることがある。特に、放送受信装置１００が複数の連動装置２００と連動する場合、持続的な通信は放送受信装置１００の動作の過負荷を誘発する可能性がある。連動装置１００が放送サービスの属性をコンテンツ/シグナリングサーバ４００から受信するようにする場合、このような問題を解決することができる。これについては、図４１〜図４２に基づいて説明する。
【０５５０】
図４１は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
【０５５１】
放送サービスの属性が変更された場合、放送受信装置１００は連動装置２００に放送サービスの属性の変更可否と放送サービスの属性を受信することができるURLアドレスを共に通知することができる。このために、放送受信装置１００が連動装置２００にシグナリングする放送サービスの属性の状態を示す変数は、放送サービスの属性を受信することができるURLアドレスを示す情報を含むことができる。具体的な実施例においてシグナリングする放送サービスの属性の状態を示す変数は、放送サービスの属性を受信することができるURLアドレスを示すServicePropertyChangeFlagを含むことができる。具体的な実施例においてServicePropertyChangeFlagは選択変数であり、ストリングデータタイプを有することができる。具体的な放送受信装置１００と連動装置２００の動作については、図４２に基づいて説明する。
【０５５２】
図４２は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【０５５３】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２０４１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３７の実施例と同一であってもよい。
【０５５４】
連動装置２００は、放送受信装置１００に放送サービスの属性変更通知を要求する(Ｓ２０４３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的な連動装置２００の動作は、図３７の実施例と同一であってもよい。
【０５５５】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２０４５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５５６】
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更可否及び放送サービスの属性を獲得できるURLを通知する(notify)(Ｓ２０４７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更可否及び放送サービスの属性を獲得できるURLを通知することができる。具体的に、放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。具体的に、放送受信装置１００は、放送サービスの属性をシグナリングする情報のバージョンが以前に比べて変更されたかに基づいて放送サービスの属性の変更可否を判断することができる。また、放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性変更及び放送サービスの属性を獲得できるURLを通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否を示す変数を介して放送サービスの属性の変更可否を通知することができる。具体的な実施例において放送サービスの属性の変更可否を示す変数は、図４１のServicePropertyChangeFlagであってもよい。また、放送受信装置１００は、連動装置２００に放送サービスの属性を獲得できるURLを示す変数を介して放送サービスの属性の変更可否を通知することができる。具体的な実施例において放送サービスの属性を獲得できるURLを示す変数は、図４１のServicePropertyURLであってもよい。
【０５５７】
連動装置２００は、放送サービスの属性を獲得できるURLに基づいて放送サービスの属性を獲得する(Ｓ２０４９)。具体的に連動装置２００は、制御部を介して放送サービスの属性を獲得できるURLに基づいて放送サービスの属性を獲得することができる。具体的に連動装置２００は、放送サービスの属性を獲得できるURLに基づいてコンテンツ/シグナリングサーバ４００から放送サービスの属性を獲得することができる。具体的に連動装置２００は、放送サービスの属性を獲得できるURLに基づいて放送サービスの属性をコンテンツ/シグナリングサーバに要求し、コンテンツ/シグナリングサーバ４００から放送サービスの属性を獲得することができる。これにより、放送受信装置１００と連動装置２００との間の通信から発生しうる放送通信装置１００の負荷を軽減することができる。但し、このような実施例において放送受信装置１００は、連動装置２００が必要としない放送サービスの属性が変更される場合でも放送サービスの属性変更を通知しなければならない。従って、放送受信装置１００は不必要な動作を行う問題がある。連動装置２００が放送受信装置１００に通知変更を要求するときに必要な放送サービスの属性を予め設定する場合、放送受信装置１００の不必要な動作を減らすことができる。これについては、図４３〜図４４に基づいて説明する。
【０５５８】
図４３は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数、放送サービスの属性のためのアクション及びアクションの引数(argument)を示す。
【０５５９】
連動装置２００が放送受信装置１００に放送サービスの属性変更通知を要求するとともに通知を受けることを希望する放送サービスの属性を指定することができる。このために、連動装置２００は、通知を受けることを希望する放送サービスの属性を指定するアクションを含むことができる。このとき、アクションは、通知を受けることを希望する放送サービスの属性を示す変数を入力引数として有することができる。このようなアクションは、図４３の実施例のSetServicePropertyであってもよい。具体的な実施例においてSetServicePropertyは必須アクションであってもよい。また、SetServicePropertyは、放送サービスの属性の種類を示すServicePropertyNameを入力引数(argument)として有することができる。放送受信装置１００と連動装置２００の具体的な動作は、図４４に基づいて説明する。
【０５６０】
図４４は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【０５６１】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２０６１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図４２の実施例と同一であってもよい。
【０５６２】
連動装置２００は、放送受信装置１００に放送サービスの特定属性変更通知を要求する(Ｓ２０６３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性変更通知を要求することができる。連動装置２００は、放送サービスに関する付加情報を提供するために必要な放送サービスの特定属性の変更通知のみを要求することができる。具体的な実施例において連動装置２００は、特定属性の変更通知のみを要求するためのアクションを介して放送サービスの特定属性変更通知を要求することができる。このとき、特定属性の変更通知のみを要求するためのアクションは、図４３で説明したSetServicePropertyであってもよい。連動装置２００が放送受信装置１００に放送サービスの特定属性変更通知を要求する動作は、次のような動作を含むことができる。連動装置２００は、放送受信装置１００にサービスの属性に関する変更通知購読(subscription)を要求することができる。放送受信装置１００は、サービスの属性に関する変更通知購読(subscription)要求を受諾する場合、連動装置２００に受諾メッセージと購読要求を識別する購読識別子(Subscription ID、SID)を共に伝送することができる。連動装置２００は、放送受信装置１００にSIDに基づいて放送サービスの特定属性の変更通知のみを要求することができる。具体的に、連動装置２００はSIDとと共に変更可否の通知を受けようとする放送サービスの特定属性を伝送することができる。また、連動装置２００は、放送受信装置１００に放送サービスの複数の特定属性の変更に対して通知を要求することができる。このとき、連動装置２００は、放送サービスの複数の特定属性をリスト形式で要求することができる。
【０５６３】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２０６５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５６４】
放送受信装置１００は、放送サービスの特定属性の変更可否を確認する(Ｓ２０６７)。具体的に、放送受信装置１００は、制御部１５０を介して放送サービスの特定属性の変更可否を確認することができる。具体的に、放送受信装置１００は、放送サービスの特定属性が以前に比べて変更されたかを判断することができる。具体的に、放送受信装置１００は、放送サービスの特定属性の以前値と現在値を比較して、放送サービスの特定属性の変更可否を判断することができる。
【０５６５】
放送サービスの特定属性が変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの特定属性の変更可否を通知する(notify)(Ｓ２０６９)。具体的に、放送サービスの特定属性が変更された場合、放送受信装置１００は制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの特定属性の変更可否を通知するすることができる。
【０５６６】
連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求する(Ｓ２０７１)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性を要求することができる。具体的に、放送受信装置１００が放送サービスの特定属性変更通知を伝送した場合、連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求することができる。具体的な連動装置２００の動作は、図３７の実施例と同一であってもよい。
【０５６７】
放送受信装置１００は、連動装置２００に放送サービスの特定属性を通知する(Ｓ２０７３)。放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの特定属性を通知ことができる。具体的に、放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの特定属性を通知することができる。例えば、放送受信装置１００は、連動装置２００に連動装置２００が要求した放送サービスの特定属性を伝送することができる。
【０５６８】
また、連動装置２００は、放送受信装置１００から放送サービスの特定属性を獲得するものではなく、図４２で説明したように、放送サービスの属性を獲得できるURLを獲得し、放送サービスの属性を獲得できるURLに基づいて放送サービスの特定属性を獲得することができる。このような動作により、放送受信装置１００が不必要に連動装置２００に放送サービスの属性変更を通知する動作を減らすことができる。
【０５６９】
放送受信装置１００は、自然災害、テロ、戦争など災害状況に対する災難警報を放送網を介して受信することができる。また、放送受信装置１００は、これをユーザに通知することができる。これにより、国の災害状況に対して人々が迅速かつ効率的に把握することができる。但し、ユーザが放送受信装置１００を注視し続ける状況でなければ、このような災難警報を把握できない状況になる可能性がある。ユーザが放送受信装置１００を注視し続ける状況でなくても、ユーザは携帯電話、タブレットなどの連動装置２００を常に所持している確立が高い。従って、放送受信装置１００が連動装置２００に災難警報を伝送し、連動装置２００が災難警報を表示することができれば、国の災害状況をユーザに迅速かつ効率的に通知することができる。これについては、図４５〜図５７に基づいて説明する。
【０５７０】
図４５は、本発明の一実施例により災難警報が生成され、放送網を介して伝送される過程を示す。
【０５７１】
放送サービスを介した災難警報を管理する警報システムは、災難警報を発令する権限がある政府当局(authorities)がIPWS(Integrated Public Alert＆Warning System)を介して緊急状況を入力するか、他のソースを介して共通警報プロトコル(Common Alerting Protocol、CAP)に基づくメッセージを受信する。警報システムは、CAPメッセージが現在の地域に該当するかを判断する。CAPメッセージが現在の地域に該当する場合、放送信号にCAPメッセージを挿入する。従って、CAPメッセージは、放送信号を介して伝送される。放送受信装置１００が放送信号を受信して災難警報をユーザに伝送する動作については、図４６に基づいて説明する。
【０５７２】
図４６は、本発明の一実施例により放送受信装置が放送網を介してシグナリングされる災難警報を抽出して表示することを示す。
【０５７３】
放送伝送装置２００は、放送信号に基づいて災難警報テーブル(Emergency Alter Table、EAT)を抽出し、EATからのCAPメッセージを抽出することができる。また、放送伝送装置２００は、災難警報に関する追加情報を、EATが含む非リアルタイムサービス識別子に基づいて獲得することができる。具体的に、放送受信装置２００は、EATが含むEAS_NRT_service_idフィールドに基づいて、災難警報に関する追加情報を獲得することができる。具体的に、放送受信装置２００は、EATに含まれた非リアルタイムサービス識別子に基づいて、非リアルタイムサービスをシグナリングするテーブルから災難警報に関する追加情報を伝送するFLUTEセッションに関する情報を獲得することができる。このとき、非リアルタイムサービスをシグナリングするテーブルは、サービスマップテーブル(Service Map Table、SMT)であってもよい。放送受信装置２００は、FLUTEセッションに関する情報に基づいて、当該FLUTEセッションから災難警報に関する追加情報を受信することができる。放送受信装置２００は、災難警報を受信して放送サービス及び放送サービスのプログラムに関する情報を表示するサービスガイドに表示することができる。具体的に、放送受信装置２００は、ガイドアクセステーブル(Guide Access Table、GAT)からサービス識別子を抽出し、サービス識別子に該当する情報を、非リアルタイムサービスをシグナリングするテーブルから抽出して受信することができる。具体的な実施例において放送受信装置２００は、GATから抽出したサービス識別子に該当するサービスのFLUTEセッションに関する情報を獲得することができる。以後、放送受信装置２００は、FLUTEセッションに関する情報に基づいて災難警報メッセージを受信し、災難警報メッセージをサービスガイドに表示することができる。具体的なCAPメッセージの形式は、図４７と同一であってもよい。
放送受信装置１００が連動装置２００に伝送する具体的な動作については、図４８〜図５７に基づいて説明する。
【０５７４】
図４８は、本発明の一実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を示す。
【０５７５】
本発明の一実施例において災難警報の状態を示す変数は、災難警報を含む災難警報メッセージに関する情報を示す変数及び災難警報メッセージをすべて含む災難警報に関する情報を示す変数のうち少なくともいずれか１つを含むことができる。具体的に、放送受信装置１００が災難警報を受信した場合、放送受信装置１００は、連動装置１００に災難警報メッセージに関する情報を通知することができる。災難警報メッセージに関する情報については、図４９を参照して説明する。
【０５７６】
図４９は、本発明の一実施例により放送受信装置がシグナリングする災難警報メッセージに関する情報を示す。
【０５７７】
災難警報メッセージに関する情報は、災難警報のバージョン、災難警報メッセージの形式(format)、災難警報メッセージを受信した日付及び災難警報メッセージを受信した時間のうち少なくともいずれか１つを含むことができる。具体的に、災難警報メッセージの形式を示すmessageType、災難警報メッセージを受信した日付と災難警報メッセージを受信した時間を示すdateTime及び災難警報メッセージのバージョンを示すversionのうち少なくともいずれか１つを含むことができる。具体的な実施例において、災難警報を含むメッセージに関する情報は、図４９のようにXML形式であってもよい。但し、災難警報を含むメッセージの形式がこれに限定されるものではない。
【０５７８】
図４８に戻って、本発明の一実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を説明する。
【０５７９】
さらに、連動装置２００は、災難警報メッセージをすべて含む災難警報に関する情報をアクションを介して要求することができる。このとき、放送受信装置１００は、連動装置１００に災難警報に関する情報を含む変数を介して、災難警報メッセージをすべて含む災難警報に関する情報をシグナリングすることができる。具体的な実施例において災難警報の状態を示す変数は、EmergencyAlertとEmergencyAlertPropertyのうちいずれか１つを含むことができる。EmergencyAlertは、災難警報を含むメッセージに関する情報を含む。具体的な実施例においてEmergencyAlertは必須変数であり、ストリングデータタイプを有することができる。放送受信装置１００は、EmergencyAlertをUPnPのイベンティングプロトコルを利用して伝送することができる。具体的な実施例において放送受信装置１００は、災難警報を受信する場合、EmergencyAlertPropertyは災難警報に関する情報を含む。EmergencyAlertPropertyは必須変数であり、ストリングデータタイプを有することができる。具体的な実施例において災難警報メッセージをすべて含む災難警報に関する情報を要求するアクションは、GetAllEmergencyAlertMessageであってもよい。具体的な実施例においてGetAllEmergencyAlertMessageは必須アクションであってもよい。また、GetAllEmergencyAlertMessageは、EmergencyAlertPropertyを出力引数として有することができる。
【０５８０】
放送受信装置１００と連動装置２００の動作については、図５０に基づいて説明する。
【０５８１】
図５０は、本発明の一実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【０５８２】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１０１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３４の実施例と同一であってもよい。
【０５８３】
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１０３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的に連動装置２００は、UPnPプロトコルを利用して、放送受信装置１００に災難警報受信通知を要求することができる。具体的な実施例において連動装置２００は、イベンティングプロトコルに基づいて放送受信装置１００に災難警報受信通知に対するイベントの購読(subscription)を要求することができる。
【０５８４】
放送受信装置１００は、放送伝送装置３００から災難警報を含むメッセージを受信する(Ｓ２１０５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報メッセージを受信することができる。
【０５８５】
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知する(notify)(Ｓ２１０７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に災難警報メッセージに関する情報を示す変数を介して災難警報メッセージに関する情報を通知することができる。具体的な実施例において災難警報メッセージに関する情報を示す変数は、図４９のEmergencyAlertであってもよい。
【０５８６】
連動装置２００は、放送受信装置１００に災難警報に関する情報を要求する(Ｓ２１０９)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報を要求することができる。具体的な実施例において連動装置２００は、災難警報を要求するアクションを介して災難警報を要求することができる。具体的な実施例において災難警報を要求するアクションは、図４９のGetEmergencyAlertMessageであってもよい。
【０５８７】
放送受信装置１００は、連動装置２００に災難警報メッセージをすべて含む災難警報に関する情報を通知する(Ｓ２１１１)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージをすべて含む災難警報に関する情報を通知することができる。但し、このような場合、災難警報メッセージをすべて受信しなければならないので、放送受信装置１００と連動装置２００の動作に負荷として作用する可能性がある。従って、連動装置２００に災難警報メッセージを効率的に伝送する方法が必要である。
【０５８８】
放送受信装置１００は、災難警報メッセージから連動装置２００に必要な情報を抽出して伝送することができる。具体的な実施例において放送受信装置１００は、災難警報メッセージから災難警報を識別する識別子、災難警報のカテゴリーを示す情報、災難警報に関する説明を示す情報、災難警報に該当する地域を示す情報、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを抽出することができる。具体的な実施例において放送受信装置１００は、災難警報メッセージから災難警報を識別するエレメントであるidentifier、災難警報のカテゴリーを示すエレメントであるcategory、災難警報に関する説明を示すエレメントであるdescription、災難警報に該当する地域を示すエレメントであるareaDesc、災難警報の緊急度を示すエレメントであるurgency、災難警報を誘発した災害の深刻性を示すエレメントであるseverity及び災難警報を誘発した災害の発生確率を示すエレメントであるcertainityのうち少なくともいずれか１つを抽出することができる。
【０５８９】
連動装置２００は、災難警報の優先度(priority)を判断し、災難警報の優先度に基づいて動作することができる。災難警報の優先度を判断する方法については、図５１〜図５３に基づいて説明する。
【０５９０】
図５１〜図５３は、本発明の一実施例により放送受信装置が災難警報の優先順位を判断する基準を示す。
【０５９１】
連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のそれぞれの値に基づいて区分することができる。このとき、連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のうち最も高い優先度を有する値に基づいて災難警報の優先度を判断することができる。具体的な実施例において連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報が有する値に応じて、３つの緊急度に区分することができる。例えば、連動装置２００は、図５２の実施例のように、UrgencyエレメントがImmediateまたはExpectedに該当する場合に最も高い優先度、Futureに該当する場合に最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度、Pastに該当する場合に最も低い優先度、Unknownに該当する場合に初期値に該当する優先度を有すると判断することができる。このとき、初期値は、最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度であってもよい。また、連動装置２００は、図５２の実施例のように、SeverityエレメントがExtremeまたはSevereに該当する場合に最も高い優先度、Moderateに該当する場合に最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度、Minorに該当する場合に最も低い優先度、Unknownに該当する場合に初期値に該当する優先度を有すると判断することができる。このとき、初期値は、最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度であってもよい。また、連動装置２００は、図５２の実施例のように、CertaintyエレメントがVery likelyまたはlikelyに該当する場合に最も高い優先度、Possibleに該当する場合に最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度、Unlikelyに該当する場合に最も低い優先度、Unknownに該当する場合に初期値に該当する優先度を有すると判断することができる。このとき、初期値は、最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度であってもよい。
【０５９２】
他の実施例において連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のそれぞれの値に基づいてポイントを与え、ポイントの合計に応じて災難警報の優先度を判断することができる。具体的な実施例において連動装置２００は、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報に同じ比重でポイントを与えることができる。例えば、連動装置２００は、図５３の実施例のように、UrgencyエレメントがImmediateに該当する場合に５、Expectedに該当する場合に４、Futureに該当する場合に３、Pastに該当する場合に２、Unknownに該当する場合に１のポイントを与えることができる。また、連動装置２００は、図５３の実施例のようにSeverityエレメントがExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に１のポイントを与えることができる。また、連動装置２００は、図５３の実施例のようにCertaintyエレメントがVery likelyに該当する場合に５、likelyに該当する場合に４、Possibleに該当する場合に３、Unlikelyに該当する場合に２、Unknownに該当する場合に１ポイントを与えることができる。このとき、連動装置２００は、ポイントの合計が１０以上１５以下である場合、災難警報が最も高い優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が５以上１０以下である場合、災難警報が最も高い優先度より低く、最も低い優先度より高い中間優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が０以上５以下である場合、災難警報が最も低い優先度を有すると決定することができる。
【０５９３】
他の具体的な実施例において連動装置２００は、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報にそれぞれ異なる比重でポイントを与えることができる。例えば、連動装置２００は、図５４の実施例のようにUrgencyエレメントがImmediateに該当する場合に９、Expectedに該当する場合に８、Futureに該当する場合に７、Pastに該当する場合に５、Unknownに該当する場合に０のポイントを与えることができる。また、連動装置２００は、図５４の実施例のように、SeverityエレメントがExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に０のポイントを与えることができる。また、連動装置２００は、図５４の実施例のように、CertaintyエレメントがVery likelyに該当する場合に６、likelyに該当する場合に５、Possibleに該当する場合に４、Unlikelyに該当する場合に３、Unknownに該当する場合に０のポイントを与えることができる。このとき、連動装置２００は、ポイントの合計が１０以上１５以下である場合、災難警報が最も高い優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が５以上１０以下である場合、災難警報が最も高い優先度より低く、最も低い優先度より高い中間優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が０以上５以下である場合、災難警報が最も低い優先度を有すると決定することができる。
【０５９４】
連動装置２００は、災難警報の優先度に基づいて災難警報を表示することができる。具体的な実施例において連動装置２００は、災難警報の優先度に基づいて、災難警報によるアラーム音、アラームの持続時間、アラームの回数及び災難警報の表示時間のうち少なくともいずれか１つを異なるようにすることができる。例えば、連動装置２００は、災難警報の優先度が高いほどアラーム音を大きくすることができる。また、連動装置２００は、災難警報の優先度が高いほどアラームを長い時間維持することができる。
【０５９５】
図５０〜図５１に基づいて説明した本発明の一実施例によれば、放送受信装置１００は、連動装置２００に災難警報メッセージをすべて伝送しなければならない。しかし、連動装置２００は、災難警報メッセージのうちの一部情報のみを必要とすることがある。従って、放送受信装置２００は、災難警報メッセージのうち連動装置２００が必要とする一部情報のみを伝送する放送受信装置２００の動作方法が必要である。これについては、図５４〜図５５に基づいて詳しく説明する。
【０５９６】
図５４は、本発明の他の実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を示す。
【０５９７】
連動装置２００は、放送受信装置１００に災難警報に関する情報を要求するとともに獲得することを希望する災難警報の特定情報を指定することができる。災難警報の特定情報は、災難警報メッセージに含まれた複数の情報のうち１つまたは複数の情報からなることができる。このとき、放送受信装置１００は、連動装置２００に災難警報に関する特定情報を伝送することができる。このために、連動装置２００は、災難警報に関する特定情報を要求するアクションを利用することができる。このとき、アクションは、災難警報に関する特定情報を識別する変数を入力引数として有することができる。具体的な実施例において連動装置２００が獲得することを希望する災難警報の特定情報を示す変数は、EmergencyAlertFieldであってもよい。具体的な実施例においてEmergencyAlertFieldは必須変数であり、ストリングデータタイプを有することができる。災難警報に関する特定情報を要求するアクションは、GetEmergencyAlerMessageであってもよい。GetEmergencyAlerMessageは必須アクションであり、EmergencyAlertFieldを入力引数として有することができる。放送受信装置１００と連動装置２００の具体的な動作は、図５５に基づいて説明する。
図５５は、本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【０５９８】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１２１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５０の実施例と同一であってもよい。
【０５９９】
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１２３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５０の実施例と同一であってもよい。
【０６００】
放送受信装置１００は、放送サービスに基づいて災難警報を含む災難警報メッセージを受信する(Ｓ２１２５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報を含む災難警報メッセージを受信することができる。
【０６０１】
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知する(notify)(Ｓ２１２７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知することができる。また、具体的な実施例において放送受信装置１００は、連動装置２００に災難警報メッセージに関する情報を示す変数を介して災難警報メッセージ情報を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に災難警報メッセージに関する情報を示す変数を介して災難警報メッセージに関する情報を通知することができる。具体的な実施例において災難警報メッセージを示す変数は、図４９のEmergencyAlertであってもよい。
【０６０２】
連動装置２００は、放送受信装置１００に災難警報に関する特定情報を要求する(Ｓ２１２９)。連動装置２００は、制御部を介して放送受信装置１００に災難警報に関する特定情報を要求することができる。このとき、災難警報に関する特定情報は、連動装置２００が災難警報に関する付加機能を提供するために必要な災難警報に関する情報からなることができる。具体的な実施例において連動装置２００は、放送受信装置１００に災難警報メッセージから災難警報を識別する識別子、災難警報のカテゴリーを示す情報、災難警報に関する説明を示す情報、災難警報に該当する地域を示す情報、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを要求することができる。例えば、連動装置２００は、放送受信装置１００に災難警報メッセージから災難警報を識別するエレメントであるidentifier、災難警報のカテゴリーを示すエレメントであるcategory、災難警報に関する説明を示すエレメントであるdescription、災難警報に該当する地域を示すエレメントであるareaDesc、災難警報の緊急度を示すエレメントであるurgency、災難警報を誘発した災害の深刻性を示すエレメントであるseverity及び災難警報を誘発した災害の発生確率を示すエレメントであるcertainityのうち少なくともいずれか１つを要求することができる。具体的な実施例において連動装置２００は、放送受信装置１００に図５４のGetEmergencyAlertMessageアクションとEmergencyAlertFieldを利用して、災難警報に関する特定情報を要求することができる。
【０６０３】
放送受信装置１００は、災難警報メッセージに基づいて災難警報に関する特定情報を抽出する(Ｓ２１３１)。具体的に、放送受信装置１００は、制御部１５０を介して災難警報メッセージに基づいて災難警報に関する特定情報を抽出することができる。具体的に、放送受信装置１００は、制御部１５０を介して災難警報メッセージから災難警報に関する特定情報を抽出することができる。
【０６０４】
放送受信装置１００は、連動装置２００に災難警報に関する特定属性を通知する(Ｓ２１３３)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報に関する特定属性を通知することができる。具体的に、放送受信装置１００は、連動装置２００の要求に基づいて災難警報に関する特定属性を通知することができる。
【０６０５】
但し、放送受信装置１００が複数の連動装置２００と連動する場合、放送受信装置１００が、連動装置２００が必要とする災難警報に関する特定情報を直接伝送することは放送受信装置１００の動作に過負荷を誘発する可能性がある。従って、放送受信装置１００の負荷を軽減させることができる連動装置２００に対する災難警報シグナリング方法が必要である。これについては、図５６に基づいて説明する。
【０６０６】
図５６は、本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【０６０７】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１４１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５５の実施例と同一であってもよい。
【０６０８】
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１４３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５５の実施例と同一であってもよい。
【０６０９】
放送受信装置１００は、放送サービスに基づいて災難警報を含む災難警報メッセージを受信する(Ｓ２１４５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報を含む災難警報メッセージを受信することができる。
【０６１０】
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関する情報を獲得できるURLを通知する(notify)(Ｓ２１４７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関する情報を獲得できるURLを通知することができる。
【０６１１】
連動装置２００は、災難警報に関する情報を獲得できるURLに基づいて災難警報に関する情報を獲得する(Ｓ２１４９)。具体的に連動装置２００は、制御部を介して災難警報に関する情報を獲得できるURLに基づいて災難警報に関する情報を獲得することができる。具体的に連動装置２００は、災難警報に関する情報を獲得できるURLに基づいてコンテンツ/シグナリングサーバ４００から災難警報に関する情報を獲得することができる。具体的に連動装置２００は、災難警報に関する情報を獲得できるURLに基づいて災難警報に関する情報をコンテンツ/シグナリングサーバに要求し、コンテンツ/シグナリングサーバ４００から災難警報に関する情報を獲得することができる。これにより、放送受信装置１００と連動装置２００との間の通信から発生しうる放送通信装置１００の負荷を軽減することができる。
【０６１２】
放送受信装置１００が連動装置２００に災難警報を表示できるユーザインターフェース(User Interface、UI)を伝送する場合、連動装置２００の災難警報を処理するための負荷を軽減することができる。これについては、図５７に基づいて説明する。
【０６１３】
図５７は、本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
【０６１４】
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１６１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５６の実施例と同一であってもよい。
【０６１５】
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１６３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５６の実施例と同一であってもよい。
【０６１６】
放送受信装置１００は、放送サービスに基づいて災難警報を含む災難警報メッセージを受信する(Ｓ２１６５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報を含む災難警報メッセージを受信することができる。
【０６１７】
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関するUI情報を通知する(notify)(Ｓ２１６７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関するUI情報を通知することができる。このとき、災難警報に関するUI情報は、災難警報に関するUIのリストを含むことができる。
【０６１８】
連動装置２００は、放送受信装置１００に災難警報に関するUI情報に基づいて災難警報に関するUIを要求する(Ｓ２１６９)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報に関するUI情報に基づいて災難警報に関するUIを要求することができる。
【０６１９】
放送受信装置１００は、連動装置２００の要求に基づいて連動装置２００に災難警報に関するUIを獲得できるURIを伝送する(Ｓ２１７１)。放送受信装置１００は、制御部１５０を介して連動装置２００の要求に基づいて連動装置２００に災難警報に関するUIを獲得できるURIを伝送することができる。
【０６２０】
連動装置２００は、災難警報に関するUIを獲得できるURIに基づいて災難警報に関するUIを表示する(Ｓ２１７３)。連動装置２００は、制御部を介して災難警報に関するUIを獲得できるURIに基づいて災難警報に関するUIを表示することができる。具体的に連動装置２００は、災難警報に関するUIを獲得できるURIに基づいてUIを獲得することができる。このとき、連動装置２００は、外部のサーバから災難警報に関するUIを獲得することができる。例えば、連動装置２００は、災難警報に関するUIのための画像ファイル、HTMLファイル及びXMLファイルのうち少なくともいずれか１つを外部のサーバから受信することができる。このとき、外部のサーバは、コンテンツ/シグナリングサーバ４００であってもよい。他の具体的な実施例において連動装置２００は、災難警報に関するUIを予め格納し、格納したUIのうちURIに該当するUIを呼び出すことができる。また、連動装置２００は、このような動作により獲得した災難警報に関するUIを表示することができる。このような動作により、連動装置２００が災難警報を処理するので、発生する連動装置２００の負荷を軽減することができる。
【０６２１】
図５８は、本発明の一実施例に係る放送サービスの伝送階層を示す。
【０６２２】
放送伝送装置３００は、複数の層で構成された放送信号を介して放送サービスを伝送することができる。放送サービスを伝送するための複数の層のうち、物理的媒体(physical medium)を介してRAW放送信号を送受信するための伝送層を物理層(physical layer)ということができる。この時、物理的媒体は、銅線(Cooper)または光ファイバー(Optical fiber)からなることができる。放送伝送装置３００は、一つまたは複数の周波数上に一つ以上の物理層パイプ(Physical Layer Pipe、PLP)を介して、放送サービスと放送サービス関連データを伝送することができる。一つの周波数上に複数の物理層パイプが存在してもよい。この時、PLPは、物理層(physical layer)上で識別可能な一連の論理的データ伝達経路である。PLPは、データパイプ(data pipe)等他の用語で称されることがある。一つの放送サービスは、複数のコンポーネントを含むことができる。この時、複数のコンポーネントのそれぞれは、オーディオ、ビデオ及びデータコンポーネントのうちいずれか一つである。各放送局は、放送伝送装置３００を介してカプセル化(encapsulation)された放送サービスを一つまたは複数のPLPを介して伝送することができる。具体的に、放送局は、放送伝送装置３００を介して一つのサービスに含まれた複数のコンポーネントを複数のPLPで伝送することができる。または、放送局は、放送伝送装置３００を介して一つのサービスに含まれた複数のコンポーネントを一つのPLPで伝送することができる。例えば、図５８の実施例で、第１放送局(Broadcast #１)は、放送伝送装置３００を介してシグナリング情報を一つのPLP(PLP #０)を介して伝送することができる。また、図５８の実施例で、第１放送局(Broadcast #１)は、放送伝送装置３００を介して第１放送サービスに含まれた第１コンポーネント(Component １)及び第２コンポーネント(Component ２)を相互異なる第１PLP(PLP #１)と第２PLP(PLP #２)を介して伝送する。また、図５８の実施例で、第N放送局(Braoadcast #N)は、第１放送サービス(Service #１)に含まれた第１コンポーネント(Component １)及び第２コンポーネント(Component ２)を第N PLP(PLP #N)を介して伝送する。この時、リアルタイム放送サービスは、IP、UDP(User Datagram Protocol)及びリアルタイムコンテンツを伝送するためのプロトコル、例えばリアルタイム伝送プロトコル(Realtime Transport Protocol、RTP)のうちのいずれか一つにカプセル化できる。非リアルタイムコンテンツ及び非リアルタイムデータである場合にも、IP、UDP及びコンテンツ伝送プロトコル、例えばFLUTEのうちの少なくともいずれか一つのパケットにカプセル化できる。従って、放送伝送装置３００が伝送する物理層フレーム内には、一つ以上のコンポーネントを伝達する複数のPLPを含むことができる。従って、放送受信装置１００は、放送サービス連結情報を獲得する放送サービスをスキャンするために、複数のPLPを全部確認しなければならないこともある。従って、放送受信装置１００が放送サービススキャンを効率的にできるようにする放送伝送方法及び放送受信方法が必要である。
【０６２３】
本発明の一実施例に係る放送システムでは、災難警報メッセージ(Emergency Alert Message)を送受信する放送伝送装置３００、放送伝送装置３００の動作方法、放送受信装置１００及び放送受信装置１００の動作方法を提案する。この時、災難警報メッセージは、放送視聴者に緊急状況を知らせるための災難警報情報を放送網を介して伝送可能な形態に変換したものをいう。また、獲得した災難警報に対する情報を基に、これを処理する放送受信装置１００及び放送受信装置１００の動作方法を提案する。災難警報情報の伝達は、通常政府が主導して運用しており、放送システムが適用される国家によって、細部的な構造は可変できる。従って、本発明の一実施例では、災難警報情報を放送網を介して伝送する方法において、共通して適用可能な災難警報メッセージの構成方法及びこれに対する送受信に対して提案する。
【０６２４】
図５９は、本発明の一実施例に係る災難警報システムの全体構成を示すブロック図である。
【０６２５】
図５９に示すように、本発明の一実施例に係る災難警報システム(Emergency Alert System)は、警報当局６００(Alert Authorities)、放送伝送装置３００(例えば、放送会社)、放送受信装置１００及び情報収集装置７００を含むことができる。
【０６２６】
警報当局６００は、国家または当該地域の関係機関を含むことができる。警報当局６００は、災難警報情報の伝送が放送網を介して伝達されなければならない場合、災難警報を発生させ、これを情報収集装置７００(または機関)に伝達する。この時、情報収集装置７００は、IPAWSアグリゲータ(IPAWS aggregator、Integrated Public Alert Warning System)からなることができる。
【０６２７】
情報収集装置７００は、放送網を介して伝達する災難警報情報をCAP(Common Alerting Protocol)ベースのメッセージに構成して放送伝送装置３００に伝達する。ここで、CAPは、非常事態を警告し、情報を交換するためのXMLファイルフォーマットである。CAPは、警告メッセージを複数の災難警報システムを介して同時に伝播することができる。以下、本発明の一実施例では、放送伝送装置３００にCAPメッセージが伝達された以後の過程を中心に説明する。
【０６２８】
CAPメッセージが放送伝送装置３００に伝達されると、当該メッセージを処理する放送伝送装置３００は、関連したオーディオ/ビデオコンテンツ及び付加サービスをCAPメッセージと一緒に伝送する。具体的に、放送伝送装置３００は、関連オーディオ/ビデオコンテンツまたは付加サービスをCAPメッセージと一緒に放送信号に挿入して放送受信装置１００に伝送する。一実施例で、CAPメッセージを含む災難警報関連データは、それぞれの目的と形態に応じて他の経路を介して伝送できる。具体的な例として、他の経路は、シグナリングチャネル(Signaling Channel)、データパイプ(Data Pipe)及びブロードバンド(Broadband)のいずれか一つからなることができる。
【０６２９】
放送受信装置１００は、放送伝送装置３００から災難警報関連データが含まれた放送信号を受信する。そして、放送受信装置１００は、災難警報シグナリングデコーダを介して受信された放送信号をデコーディングする。この時、災難警報シグナリングデコーダは、図３０のシグナリングデコーダ１５１からなることができる。
【０６３０】
放送受信装置１００は、放送信号をデコーディングして獲得した情報に応じて、オーディオ/ビデオサービスを受信する。具体的に、放送受信装置１００は、放送信号からオーディオ/ビデオサービスを伝送する物理層パイプ(physical layer pipe)情報を獲得することができる。この時、物理層パイプは、物理層フレームに含まれたデータ単位である。そして、放送受信装置１００は、物理層パイプを介して、災難警報メッセージに関連したオーディオ/ビデオサービスデータを受信することができる。
【０６３１】
また、放送受信装置１００は、放送信号をデコーディングして獲得した情報から災難警報に関連した非リアルタイムサービス情報を抽出することができる。具体的に、非リアルタイムサービス情報は、非リアルタイムサービスを獲得できるアドレス情報であってもよい。例えば、非リアルタイムサービスがブロードバンドを介して伝達され、アドレス情報は非リアルタイムサービスを獲得するためのURI情報であってもよい。
【０６３２】
図６０は、本発明の一実施例に係る放送サービスを支援するためのプロトコルスタック(protocol stack)を示す。
【０６３３】
本発明の一実施例に係る放送サービスは、視聴覚データ(Auido/Video、A/V)だけでなく、HTML５アプリケーション、双方向サービス、ACRサービス、セカンドスクリーン(second screen)サービス、個人化(personalization)サービスなどの付加サービスを提供することができる。
【０６３４】
このような放送サービスは、地上波、ケーブル衛星などの放送信号である物理層(physical layer)を介して伝送できる。また、本発明の一実施例に係る放送サービスは、インターネット通信網(broadband)を介して伝送できる。
【０６３５】
放送サービスが、地上波、ケーブル衛星などの放送信号である物理層(physical layer)を介して伝送される場合、放送受信装置１００は、カプセル化(encapsulation)されたMPEG-２伝送ストリーム(Transport Stream、TS)とカプセル化されたIPデータグラムを放送信号を復調(demodulation)して抽出することができる。放送受信装置１００は、IPデータグラムからUDP(User Datagram Protocol)データグラムを抽出することができる。放送受信装置１００は、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 BMFF(ISO Base Media File Formatの形態であってもよい。また、放送受信装置１００は、MPEG-２ TSパケットまたはIPパケットからNRTデータ、A/V、PSI/PSIPのようなシグナリング情報を抽出することができる。この時、シグナリング情報は、XMLまたはバイナリ形態であってもよい。
【０６３６】
放送サービスがインターネット通信網(broadband)を介して伝送される場合、放送受信装置１００は、インターネット通信網からIPパケットを受信することができる。放送受信装置１００は、IPパケットからTCPパケットを抽出することができる。放送受信装置１００は、TCPパケットからHTTPパケットを抽出することができる。放送受信装置１００は、HTTPパケットからA/V、付加データ、シグナリング情報などを抽出することができる。この時、A/V及び付加データのうち少なくとも一つは、ISO BMFF形態であってもよい。また、シグナリング情報は、XML形態であってもよい。
【０６３７】
本発明の一実施例で、放送伝送装置３００は、災難警報メッセージをプロトコルスタックに含まれたプロトコル層を介して伝送することができる。この場合、当該プロトコル層は、リンク層(Link Layer)であってもよい。一実施例で、放送伝送装置３００は、災難警報メッセージを伝送プロトコルに応じてテーブル形態にフォーマットすることができる。この時、プロトコルスタックに含まれたリンク層で災難警報メッセージがテーブル形態にフォーマットされる。また、災難警報メッセージは、リンク層及び物理層の動作をシグナリングする情報を含むことができる。
【０６３８】
また、他の実施例では、放送伝送装置３００は、災難警報メッセージを伝送プロトコルに応じてパケット化することができる。具体的に、放送伝送装置３００は、災難警報メッセージを伝送パケットにカプセル化することができる。この場合、災難警報情報が放送受信装置１００に多数の階層を経てシグナリングされることを防止することができる。
【０６３９】
災難警報メッセージは、伝送のために放送システムで伝送可能な形態に構成されなければならない。このために、一実施例で、災難警報メッセージを伝送するためのセクションテーブル(Section Table)が一般的に用いられる。また、他の実施例で、災難警報メッセージは、ディスクリプタ形態の構成で他のセクションテーブルの一部分に伝送されてもよい。また、他の実施例で、災難警報メッセージは、物理層のパケットに伝送されてもよい。具体的に、災難警報メッセージは、物理層パイプを介してパケットの形態に伝送できる。この場合、災難警報メッセージは、パケットに含まれたパケットペイロードに含まれて伝送できる。災難警報メッセージを含むパケットを識別するための情報は、パケットヘッダに含まれてもよい。また、災難警報メッセージを含むパケットを識別するための情報は、拡張されたヘッダに含まれてもよい。この時、拡張されたヘッダは、パケットヘッダに含まれた追加的なフィールドであってもよい。
【０６４０】
図６１は、災難警報テーブル(EAT、Emergency Alert Table)のためのシンタックスを示す。この時、災難警報テーブルは、災難警報メッセージの一形態であってもよい。図６１に示すように、EAT情報は、EATが有するプロトコルのバージョン情報を含むことができる。具体的な実施例で、当該情報は、EAT_protocol_versionフィールドであってもよい。
【０６４１】
また、EAT情報は、放送受信装置１００に自動でチャネルの転換を行うかどうかを知らせる情報を含むことができる。例えば、EAT情報は、放送受信装置１００に災難警報に関する詳しい情報を知らせるチャネルに自動で転換を行うかどうかを知らせる情報を含むことができる。具体的な実施例で、チャネル自動転換を行うかどうかを知らせる情報は、automatic_tuning_flagフィールドであってもよい。
【０６４２】
また、EAT情報は、EATに含まれているメッセージに対する個数情報を含むことができる。具体的な実施例で、メッセージ個数情報は、num_EAS_messageフィールドであってもよい。
【０６４３】
図６２は、災難警報メッセージのためのシンタックスを示す。本発明の一実施例に係る災難警報メッセージは、CAPメッセージを直接含むことができる。また、他の実施例で、災難警報メッセージは、CAPメッセージが伝達される経路の情報を含むことができる。
【０６４４】
図６２に示すように、本発明の一実施例に係る災難警報メッセージは、災難警報メッセージ(EAS message)を区別するための識別子情報を含むことができる。具体的な実施例で、識別子情報は、EAS_message_idフィールドであってもよい。この場合、EAS_message_idフィールドは３２ビットであってもよい。
【０６４５】
また、災難警報メッセージのためのシンタックスは、IPのバージョンを示す情報を含むことができる。この場合、バージョン情報は、EAS_IP_version_flagフィールドであってもよい。具体的な実施例で、EAS_IP_version_flagフィールドの値が０である場合、IPバージョンがIPv４であることを示す。また、他の実施例で、EAS_IP_version_flagフィールドの値が１である場合、IPバージョンがIPv６であることを示す。EAS_IP_version_flagフィールドは１ビットであってもよい。
【０６４６】
また、災難警報メッセージは、EASメッセージの伝達形態を示す情報を含むことができる。この場合、EASメッセージ伝達形態を示す情報は、EAS_message_transfer_typeフィールドであってもよい。EAS_message_transfer_typeフィールドは３ビットであってもよい。
【０６４７】
具体的な実施例で、EAS_message_transfer_typeフィールドは、EASメッセージの伝達形態が特定されていないことを示す。この場合、EAS_message_transfer_typeフィールドは、０００(2)の値を有することができる。
【０６４８】
また、他の実施例で、EAS_message_transfer_typeフィールドは、EASメッセージの伝達形態が警報メッセージを含んでいない形態であることを示す。即ち、放送信号を介して伝送される災難警報テーブル(EAT)が警報メッセージなしに、オーディオ/ビデオコンテンツに対する情報のみを含むことを示す。この場合、EAS_message_transfer_typeフィールドは、００１(2)の値を有することができる。
【０６４９】
また、他の実施例で、EAS_message_transfer_typeフィールドは、EASメッセージがEATに含まれて伝達されることを示す。この場合、EAS_message_transfer_typeフィールドは、０１０(2)の値を有することができる。
【０６５０】
また、EAS_message_transfer_typeフィールドが０１０(2)の値を有する場合、EASメッセージを含むテーブルは、EASメッセージの長さを示すことができる。この場合、EASメッセージの長さを示す情報は、EAS_message_lengthフィールドであってもよい。EAS_message_lengthフィールドは１２ビットであってもよい。また、EAS_message_transfer_typeフィールドが０１０(2)の値を有する場合、EASメッセージを含むテーブルはEASメッセージに対する情報を追加的に含むことができる。
【０６５１】
また、他の実施例で、EAS_message_transfer_typeフィールドは、EASメッセージがIPデータグラムの形態でデータパイプを介して伝送されることを示す。この場合、EAS_message_transfer_typeフィールドは、０１１(2)の値を有することができる。また、EAS_message_transfer_typeフィールドが０１１(2)の値を有する場合、災難警報メッセージを含むテーブルは、IPデータグラムを獲得できるIPアドレス情報、UDPポート情報及び伝送される物理層フレームの情報のうちいずれか一つを追加的に含むことができる。
【０６５２】
また、災難警報メッセージは、EASメッセージのエンコーディングタイプを示す情報を含むことができる。この場合、EASメッセージのエンコーディングタイプの情報は、EAS_message_encoding_typeフィールドであってもよい。EAS_message_encoding_typeフィールドは３ビットであってもよい。
【０６５３】
具体的な実施例で、EAS_message_encoding_typeフィールドは、EASメッセージのエンコーディングタイプが特定されていないことを示す。この場合、EAS_message_encoding_typeフィールドは、０００(2)の値を有することができる。
【０６５４】
また、他の実施例で、EAS_message_encoding_typeフィールドは、EASメッセージがエンコーディングされていないことを示す。この場合、EAS_message_encoding_typeフィールドは、００１(2)の値を有することができる。
【０６５５】
また、他の実施例で、EAS_message_encoding_typeフィールドは、EASメッセージがDEFLATEアルゴリズムによってエンコーディングされたことを示す。DEFLATEアルゴリズムは無損失圧縮データフォーマットである。この場合、EAS_message_encoding_typeフィールドは、０１０(2)の値を有することができる。
【０６５６】
また、災難警報メッセージは受信されるEASメッセージに関連したNRT(Non-real time)コンテンツ及び付加データに対する情報が災難警報テーブルに含まれているのか否かを示すことができる。この場合、NRTコンテンツ及び付加データの存在の有無を示す情報は、EAS_NRT_flagフィールドであってもよい。EAS_NRT_flagフィールドは１ビットであってもよい。
【０６５７】
具体的な実施例で、EAS_NRT_flagフィールドが０に設定された場合、受信されたEASメッセージに関連したNRTコンテンツ情報が災難警報テーブルに含まれていないことを示す。また、他の実施例で、EAS_NRT_flagフィールドが１に設定された場合、受信されたEASメッセージに関連したNRTコンテンツ情報がテーブルに含まれたことを示す。
【０６５８】
図６３は、自動チャネル転換情報(Automatic Channel Tuning Information)のためのシンタックスを示す。自動チャネル転換情報は、災難警報メッセージと一緒に、関連オーディオ/ビデオコンテンツが同時に伝送される場合、関連オーディオ/ビデオコンテンツが伝送されるチャネルに自動転換させるための情報を含む。即ち、自動チャネル転換情報は、現在の放送受信装置１００に表示されているチャネルが災難警報メッセージを含むコンテンツを含んでいない場合、関連オーディオ/ビデオコンテンツが伝送されるチャネルに自動転換するための情報であってもよい。具体的な実施例で、図６１のautomatic_tuning_flagフィールドがイネーブルされる場合に、災難警報テーブルが自動チャネル転換情報を含むことができる。例えば、automatic_tuning_flagフィールドが１の値を有する場合、災難警報テーブルが自動チャネル転換情報含むことができる。
【０６５９】
一実施例で、自動チャネル転換情報のためのテーブルは、転換されるべきチャネル番号に対する情報を示すことができる。具体的に、災難警報情報に関連したコンテンツを含むチャネルに対する情報を示すことができる。この場合、転換されるべきチャネル番号情報は、automatic_tuning_channel_numberフィールドであってもよい。具体的な実施例で、automatic_tuning_channel_numberフィールドは８ビットであってもよい。
【０６６０】
また、他の実施例で、自動チャネル転換情報のためのテーブルは、災難警報メッセージに関連したコンテンツを受信するための経路情報を示すことができる。具体的に、自動チャネル転換情報のためのテーブルは、災難警報メッセージに関連したオーディオ/ビデオコンテンツが含まれた物理層フレームを識別するための情報を示すことができる。この場合、当該情報は、automatic_tuning_DP_idフィールドであってもよい。automatic_tuning_DP_idフィールドは８ビットであってもよい。
【０６６１】
また、他の実施例で、自動チャネル転換情報のためのテーブルは、災難警報メッセージに関連したコンテンツの識別情報を示すことができる。具体的に、災難警報メッセージに関連したコンテンツのサービスID情報を示すことができる。この場合、当該情報は、automatic_tuning_service_idフィールドであってもよい。automatic_tuning_service_idフィールドは１６ビットであってもよい。
【０６６２】
図６４は、NRTサービス情報のためのシンタックスを示す。ここで、NRTサービス情報は、災難警報メッセージに関連したNRTデータを獲得するための情報を含む。図６２のEAS_NRT_flagフィールドがイネーブルされる場合に、NRTサービス情報がEATに含まれてもよい。例えば、EAS_NRT_flagフィールドが１の値を有する場合、NRTサービス情報がEATに含まれてもよい。
【０６６３】
NRTサービス情報は、災難警報メッセージに関連したNRTコンテンツ及びデータが放送受信装置１００に伝送される場合、当該NRTサービスに対する識別子情報を含む。この時、NRTサービスに対する識別子情報は、EAS_NRT_service_idフィールドであってもよい。EAS_NRT_service_idフィールドは１６ビットであってもよい。
【０６６４】
図６５〜図６６は、災難警報メッセージを伝送するためのセクションテーブルに対する一実施例を示す。図６５に示されたセクションテーブルの構成のうちの一部フィールドは、放送システムとの互換のために、既存のATSC M/H標準で用いるフィールドをそのまま用いたり、災難警報メッセージを伝送するために一部フィールドを追加することもできる。また、追加された一部フィールドは、実際放送システムに適用する場合、最適化過程を経てフィールドが有するビット数及びフィールドの順番調整が可能である。
【０６６５】
図６７〜図６８は、災難警報テーブルを物理層パイプを介してパケット形態で伝送することを示す。
【０６６６】
一般的に、放送パケットは、当該パケットを介して伝送しようとするデータが挿入されたパケットペイロード及びパケットペイロードをシグナリングするための情報が挿入されたパケットヘッダで構成される。従って、本発明の一実施例により放送伝送装置は、伝送しようとする災難警報メッセージをパケットのペイロードに挿入し、災難警報メッセージをシグナリングするための情報をパケットのヘッダに挿入することができる。
【０６６７】
図６７は、上述した災難警報テーブルの形態を変更せず、そのままパケットのペイロードで構成した一実施例を示す。図６７に示すように、パケットペイロードに災難警報テーブルがそのまま含まれ、追加的に災難警報テーブルのための識別子及び災難警報テーブルの長さ情報が含まれる。
【０６６８】
また、パケットヘッダは、パケットのタイプを示す情報を含むことができる。一実施例で、パケットタイプ情報は、パケットのペイロードが災難警報をシグナリングするためのデータを含んでいることを示す。具体的な実施例で、パケットタイプを示す情報は１１０(2)であってもよい。
【０６６９】
また、パケットヘッダは、パケットのペイロード含まれたシグナリングデータのタイプを示す情報を含むことができる。一実施例で、シグナリングデータタイプ情報は、当該シグナリングデータがセクションテーブル形態であることを示す。具体的な実施例で、シグナリングデータタイプ情報が００(2)の値を有する場合、シグナリングデータタイプ情報は、当該シグナリングデータがセクションテーブル形態であることを示す。
【０６７０】
図６８は、パケットペイロードに災難警報メッセージがセクションテーブルの形態ではなく、個別情報に挿入される一実施例を示す。この時、セクションテーブルは、最終テーブルを構成するための中間形式を指す。具体的に、放送受信装置１００は、パケットを収集してセクションテーブルを構成することができ、放送受信装置１００は、セクションテーブルを再収集して最終テーブルを構成することができる。従って、図６８の実施例は、災難警報メッセージに含まれたそれぞれのフィールドを別途のパケットにパケット化することを示す。従って、放送受信装置１００は、一つ以上のパケットを収集してセクションテーブルを構成する必要なく、一つのパケットから完成された情報を獲得することができる。例えば、一つのパケットペイロードが、EATプロトコルバージョン情報のみを、または、自動チャネル転換情報のみを含んだ場合である。
【０６７１】
この場合、パケットのタイプを示す情報は、パケットのペイロードが、災難警報をシグナリングするためのデータを含んでいることを示す。この場合、パケットのタイプを示す情報は、１１０(2)に設定されてもよい。また、シグナリングのタイプを示す情報は、パケットペイロードに含まれたデータが個別情報の形態であることを示す。この場合、シグナリングのタイプを示す情報は１０(2)に設定されてもよい。
【０６７２】
また、図６７と異なり、パケットペイロードに含まれた災難警報のためのデータが異なることがあり、パケットヘッダはこれを識別するための情報を追加的に含むことができる。当該情報はInfo Typeフィールドであってもよい。
【０６７３】
具体的な実施例で、Info Typeフィールドが０００(2)値を有する場合、パケットペイロードに含まれた災難警報のためのデータは、災難警報メッセージであってもよい。また、他の実施例で、Info Typeフィールドが００１(2)値を有する場合、パケットペイロードに含まれた災難警報のためのデータは、自動チャネル転換情報であってもよい。また、他の実施例で、Info Typeフィールドが０１０(2)値を有する場合、パケットペイロードに含まれた災難警報のためのデータは、NRTサービス情報であってもよい。
【０６７４】
以下、図６９〜図７５は、災難警報テーブル(EAT、Emergency Alert Table)を伝送する多様な実施例を示す。具体的な実施例で、EATを伝送する物理層パイプ(PLP)は、実施例によって異なる。これに対して、図６９〜図７５を介して説明するようにする。本発明の一実施例により、放送伝送装置３００が災難警報情報を物理層パイプを介して伝達する場合、放送受信装置１００が物理層から直接災難警報情報を抽出することができる。結果的に、災難警報情報を放送受信装置１００が速かに獲得することができる。
【０６７５】
図６９は、本発明の一実施例として、放送伝送装置３００が災難警報メッセージを指定された物理層パイプを介して伝送することを示す。指定された物理層パイプを介して伝送される災難警報メッセージは、EAT及び伝送パケットのうち少なくともいずれか一つである。
【０６７６】
一実施例で、放送伝送装置３００は、災難警報メッセージを指定された物理層パイプ(dedicated physical layer pipe)を介して伝送することができる。この時、災難警報メッセージを伝送するために指定された物理層パイプを災難警報チャネル(EAC、Emergency Alert Channel)ということができる。即ち、災難警報チャネルは、災難警報メッセージのみを伝送するための専用物理層パイプであってもよい。ここで、物理層パイプとは、物理層フレームを介して伝送するデータの単位である。物理層は、一つ以上の物理層フレームを含むことができ、物理層フレームを介して物理層パイプが伝送される。以下、本実施例を図６９を参照してより詳しく説明する。
【０６７７】
放送伝送装置３００は、警報当局６００等から収集した災難警報情報に基づいて災難警報テーブル(EAT)を生成する。ここで、放送伝送装置３００が受信した災難警報情報は、情報収集装置７００から受信したCAPメッセージであってもよい。
【０６７８】
ここで、指定された物理層パイプは、上述したように、災難警報テーブルのみを伝送する災難警報チャネルであってもよい。放送伝送装置３００は、生成された災難警報テーブルを含んで放送信号を生成する。具体的に、放送信号は、災難警報テーブルを含む伝送パケットを含むことができる。そして、放送伝送装置３００は、災難警報チャネルが含まれた放送信号を伝送する。具体的に、放送伝送装置３００は、災難警報テーブルを含む伝送パケットのみのために指定された物理層パイプを介して放送信号を伝送することができる。
【０６７９】
放送受信装置１００は、指定された物理層パイプを介して放送信号を受信する。上述したように、物理層パイプは、物理層内で災難警報情報のみを伝送するために指定された物理層パイプであってもよい。指定された物理層パイプは、災難警報チャネルであってもよい。放送受信装置１００は、指定された物理層パイプから災難警報テーブルを抽出することができる。また、放送受信装置１００は、物理層に災難警報チャネルが含まれているのか否かを示す情報を物理層から獲得することができる。この時、物理層に災難警報チャネルが含まれているのか否かを示す情報は、PHY signalingと称することができる。放送受信装置１００は、PHY signalingに基づいて災難警報情報を伝送するデータパイプを判断することができる。
【０６８０】
放送受信装置１００は、災難警報テーブルを含む物理層パイプをデコーディングする。物理層パイプは、図３０に示されたシグナリングデコーダ１５１を介してデコーディングできる。この時、放送受信装置１００は、物理層パイプからCAPメッセージ、関連コンテンツ情報及び関連NRTサービス情報を獲得することができる。
【０６８１】
放送受信装置１００は、獲得したCAPメッセージをパッシング(parsing)して災難警報情報を獲得することができる。具体的な実施例で、CAPパーサーがCAPメッセージをパッシングすることができる。CAPパーサーは、図３０に示された警報シグナリングパーサー１６８であってもよい。
【０６８２】
この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００がEATを構成する過程で調整することができる。
【０６８３】
放送受信装置１００は、獲得した関連コンテンツ情報に基づいてオーディオ/ビデオコンテンツを受信することができる。具体的に、獲得した関連コンテンツ情報は、オーディオ/ビデオコンテンツを伝送する物理層パイプを識別するための情報であってもよい。また、関連コンテンツ情報は、関連オーディオ/ビデオコンテンツを識別するための情報であってもよい。
【０６８４】
放送受信装置１００は、関連コンテンツ情報に基づいて関連コンテンツを含む物理層パイプを識別する。そして、放送受信装置１００は、識別された物理層パイプをデコーディングして、オーディオ/ビデオコンテンツを獲得する。この時、関連コンテンツを伝送する物理層パイプは、災難警報情報を伝送する物理層パイプと区別される。また、放送受信装置１００は、獲得したNRTサービス情報に基づいて災難警報情報に関連したNRTサービスを獲得することができる。具体的に、放送受信装置１００は、NRTサービス情報からNRTサービスを獲得できるアドレス情報を獲得することができる。この時、放送受信装置１００は、NRTサービスをブロードバンドを介して受信することができる。
【０６８５】
放送受信装置１００は、獲得した災難警報メッセージをオーディオ/ビデオコンテンツと一緒に提供する。もし、自動チャネル転換に対する情報が一緒に伝送される場合、放送受信装置１００は、チャネルを自動変更しながら災難警報メッセージを提供することができる。
【０６８６】
図７０〜図７１は、本発明の一実施例として、放送伝送装置３００が災難警報テーブルをパケットにカプセル化して伝送することを示す。災難警報テーブルを含むパケットを災難警報パケットと称することができる。
【０６８７】
一実施例で、放送信号の物理層に含まれた物理層パイプは、複数個存在してもよい。また、放送信号の物理層に含まれた複数の物理層パイプを介して伝送される複数の放送サービスに対する具体的な情報を伝送する別途の物理層パイプが存在してもよい。この時、放送サービス情報を伝送する別途の物理層パイプは、基本データパイプ(base data pipe)ということができる。具体的に、放送伝送装置３００は、基本データパイプを介して放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送することができる。ここで、シグナリング情報または共用データは、物理層を介して伝送される物理層パイプをシグナリングする情報または物理層パイプに共通して適用されるデータであってもよい。図７０は、一実施例として、放送伝送装置３００が災難警報テーブルを基本データパイプを介して伝送することを示す。
【０６８８】
放送伝送装置３００は、警報当局６００等から収集した災難警報情報をカプセル化して、物理層を介して伝送するパケットを生成する。この時、災難警報情報がカプセル化されたパケットは、災難警報パケット(Emergency Alert Packet)ということができる。ここで、放送伝送装置３００が受信した災難警報情報は、情報収集装置７００から受信したCAPメッセージであってもよい。
【０６８９】
一実施例で、災難警報パケットは、パケットヘッダ及びパケットペイロードを含むことができる。具体的な実施例で、パケットペイロードは、災難警報テーブル(EAT)をそのまま含むことができる。また、他の実施例で、パケットペイロードは、災難警報テーブル内の一部情報のみを含むこともできる。ここで、一部情報とは、災難警報テーブルにおける重要度が高い一部情報であってもよい。
【０６９０】
また、パケットヘッダは、パケットペイロードに含まれたデータが災難警報情報であることを示す情報を含むことができる。また、パケットヘッダは、伝送パケットが災難警報情報を含んでいることを示す。具体的に、パケットヘッダは、一般的なパケットと異なるタイプの情報を含み、伝送パケットが災難警報情報を含んでいることを示す。即ち、パケットヘッダは、伝送パケットが災難警報パケットであることを示す。
【０６９１】
放送伝送装置３００は、災難警報テーブルがカプセル化されたパケットを放送サービスに対するシグナリング情報または共用データを伝送する物理層パイプを介して伝送する。即ち、放送伝送装置３００は、災難警報パケットを基本データパイプを介して伝送する。この場合、基本データパイプは、物理層パイプの一形態として、他の物理層パイプ(またはデータパイプ)と区別される。
【０６９２】
一方、基本データパイプを含む物理層は、物理層内基本データパイプが存在することをシグナリングする情報を伝送することができる。この時、基本データパイプの存在をシグナリングする情報は、PHY signalingといえる。放送受信装置１００は、PHY signalingに基づいて受信された放送信号の物理層に基本データパイプが存在することを確認することができる。そして、放送受信装置１００は、物理層パイプの一形態である基本データパイプを介して、災難警報情報を獲得することができる。この時、獲得した災難警報情報は、災難警報パケットの形態であってもよい。放送受信装置１００は、基本データパイプを介して放送信号を受信する。即ち、放送受信装置１００は、災難警報パケットを基本データパイプを介して受信する。
【０６９３】
放送受信装置１００は、受信された放送信号から災難警報パケットが含まれた物理層パイプを抽出することができる。この時、災難警報パケットを含む物理層パイプは、基本データパイプであってもよい。そして、放送受信装置１００は、抽出された物理層パイプをデコーディングして災難警報情報獲得することができる。具体的に、物理層パイプに含まれた災難警報パケットをデコーディングして災難警報情報を獲得することができる。
【０６９４】
この時、災難警報パケットは、災難警報テーブルが挿入されたパケットペイロード及びパケットペイロードをシグナリングするパケットヘッダを含むことができる。具体的な実施例で、放送受信装置１００は、パケットヘッダから当該パケットが災難警報情報を含んでいるのか否かを判断することができる。即ち、放送受信装置１００は、パケットヘッダから抽出した情報に基づいて、当該パケットが災難警報パケットであるのか否かを判断することができる。
【０６９５】
また、放送受信装置１００は、パケットヘッダからパケットペイロードに含まれた災難警報情報の形態を判断することができる。例えば、パケットペイロードが全体災難警報テーブルを含んでいるのか否かを判断することができる。
【０６９６】
放送受信装置１００は、パケットヘッダから獲得した情報に基づいて、パケットペイロードから災難警報情報を獲得する。ここで、獲得した災難警報情報は、災難警報テーブルまたはCAPメッセージであってもよく、関連コンテンツ情報またはNRTサービス情報であってもよい。
【０６９７】
放送受信装置１００は、獲得したCAPメッセージをパッシングして災難警報情報を獲得することができる。この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００が、EATを構成する過程で重複する部分を省略することができる。以下、災難警報情報に基づいて関連サービスを獲得する過程は、上述した内容と同じであるので省略する。
【０６９８】
図７１は、本発明の一実施例として、放送伝送装置３００が災難警報テーブルを一般物理層パイプ(Normal Physical Layer Pipe)を介して伝送することを示す。ここで、一般物理層パイプは、用途が指定されていない物理層パイプであってもよい。
【０６９９】
本実施例は、図７０の実施例とは異なり、物理層に基本データパイプが含まれていない場合として、図７０と比較して差異点を中心に以下説明する。
【０７００】
本実施例で、放送伝送装置３００は、災難警報情報をカプセル化しながら、パケットヘッダを一般的なパケットヘッダと異なるように構成する。具体的に、放送伝送装置３００は、パケットヘッダに含まれたパケットタイプを示す値を異なるように設定することができる。例えば、一般的なパケットは当該値を０００(2)に、災難警報パケットは１１０(2)に値を設定して、それぞれのパケットを区別することができる。
【０７０１】
一方、物理層パイプを含む物理層は、物理層内の物理層パイプをシグナリングする情報を伝送することができる。この時、物理層パイプをシグナリングする情報は、PHY signalingといえる。放送受信装置１００は、PHY signalingに基づいて受信された物理層に含まれた物理層パイプの情報を獲得することができる。図７１の実施例で、放送受信装置１００は、物理層に含まれた複数の物理層パイプを介して、災難警報を含むパケット及び放送コンテンツを含むパケットを受信することができる。また、放送受信装置１００は、災難警報を含むパケットから災難警報情報を獲得することができる。また、放送受信装置１００は、災難警報情報に基づいて災難警報に関連した放送コンテンツを伝送する他の物理層パイプを識別することができる。また、放送受信装置１００は、災難警報情報に基づいて災難警報に関連した非リアルタイムコンテンツを受信できる経路情報を獲得することができる。
【０７０２】
図７２〜図７５は、本発明の一実施例として、放送伝送装置３００が災難警報情報を、物理層パイプの他の一形態を介して伝送することを示す。この場合、物理層パイプの他の一形態は、放送信号の物理層に含まれた放送サービスをスキャンするための物理層パイプであってもよい。具体的に、放送伝送装置３００は、物理層パイプを介して放送サービスをスキャンするためのサービスシグナリング情報を、他の層を経ずに放送信号の物理層に直接伝送することができる。この時、放送サービスをスキャンするための物理層パイプは、シグナリングチャネルといえる。放送受信装置１００は、シグナリングチャネルから放送ストリームの構成情報、簡略な放送サービス情報及びコンポーネント情報のうち少なくともいずれか一つを獲得することができる。具体的な実施例で、シグナリングチャネルは、FIC(Fast Information Channel)及びLLS(Low Layer Signaling)のいずれか一つからなることができる。
【０７０３】
本発明の一実施例で、放送伝送装置３００は、シグナリングチャネルを介して、CAPメッセージをベースにする災難警報メッセージを伝送することができる。本実施例は、図７２〜図７３を参照してより詳しく説明する。
【０７０４】
本発明の他の実施例で、放送伝送装置３００は、シグナリングチャネルを介して、災難警報を指示する最小限の情報のみを伝送し、実際の災難警報メッセージ(例えば、災難警報テーブル(EAT))は、シグナリングチャネルと区別される物理層パイプを介して伝送することができる。本実施例は、図７４〜図７５を参照してより詳しく説明する。
【０７０５】
図７２は、シグナリングチャネルを介して、災難警報メッセージを直接伝送する内容を示す。
【０７０６】
放送伝送装置３００は、警報当局６００等から収集した災難警報情報に基づいて災難警報テーブル(EAT)を生成する。ここで、放送伝送装置３００が受信した災難警報情報は、情報収集装置７００から受信したCAPメッセージであってもよい。
【０７０７】
放送伝送装置３００は、生成された災難警報テーブルを含む放送信号を生成する。具体的に、災難警報テーブルは、放送信号の物理層パイプの一形態であるシグナリングチャネルを介して伝送できる。この時、シグナリングチャネルは、図６９の実施例で説明した指定されたシグナリングチャネルではなく、一般的なシグナリングチャネルを指すことができる。そして、放送伝送装置３００は、シグナリングチャネルを介して災難警報情報が含まれた放送信号を伝送する。
【０７０８】
放送受信装置１００は、シグナリングチャネルを介して受信した放送信号から災難警報情報を獲得することができる。具体的に、獲得した災難警報情報は、災難警報テーブルであってもよい。具体的に、放送受信装置１００は、シグナリングチャネルをデコーディングする。この時、放送受信装置１００は、シグナリングチャネルからCAPメッセージ、関連コンテンツ情報及び関連NRTサービス情報を獲得することができる。
【０７０９】
放送受信装置１００は、獲得したCAPメッセージをパッシングして災難警報情報を獲得することができる。この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００がEATを構成する過程で重複する部分を省略することができる。以下、災難警報情報に基づいて関連サービスを獲得する過程は、上述した内容と同じであるので省略する。
【０７１０】
図７３は、図７２の実施例に係るシグナリングチャネルを介して伝送される災難警報メッセージのためのシンタックスを示す。具体的な実施例で、災難警報メッセージは、シグナリングチャネルを介して伝送されるテーブルの一部分であってもよい。また、図７３に示されたフィールドは、以降必要に応じて変更することができる。
【０７１１】
災難警報メッセージのためのテーブルは、当該災難警報テーブル内に災難警報関連シグナリングが含まれているのか否かを示すことができる。具体的に、災難警報関連シグナリングが含まれているのか否かを示す情報は、Emergency_alert_flagフィールドであってもよい。
【０７１２】
一実施例で、emergency_alert_flagフィールドが０の値を有する場合、災難警報テーブルが災難警報情報を含まないことを示す。また、emergency_alert_flagフィールドが１の値を有する場合、災難警報テーブルが災難警報情報を含むことを示す。
【０７１３】
例えば、emergency_alert_flagフィールドがイネーブルされた場合、災難警報メッセージのためのテーブルは、災難警報メッセージに関連したフィールドを含むことができる。また、災難警報メッセージのためのテーブルは、自動チャネル転換に関連したフィールドも含むことができる。
【０７１４】
図７４は、シグナリングチャネルを介して、災難警報情報の伝達経路のみを伝送する内容を示す。
【０７１５】
放送伝送装置３００は、警報当局６００等から収集した災難警報情報を伝送可能な形態にシグナリングする。具体的に、放送伝送装置３００は、災難警報情報(例えば、CAPメッセージ及び関連データ)をテーブル、ディスクリプタまたはパケットに構成することができる。この時、放送伝送装置３００が別途の災難警報シグナリングのみのためのモジュールを含んでいない場合、一般的なシグナリングモジュールを介して、災難警報情報を伝送可能な形態にシグナリングすることができる。
【０７１６】
放送伝送装置３００は、災難警報情報と一緒に、災難警報メッセージを伝送するのか否かに対する情報及び災難警報メッセージが伝送される経路に対する情報を、テーブルまたはテーブルを含む伝送パケットに挿入することができる。この時、災難警報メッセージを伝送するのか否か及び伝送経路に対する情報は、災難警報インジケータ(Emergency Alert Indicator)ということができる。テーブルまたはテーブルを含む伝送パケットに含まれたディスクリプタは、災難警報インジケータを含むことができる。また、テーブルは、災難警報インジケータを一つのフィールドとして含むことができる。災難警報インジケータが含む情報は、必要に応じて個別フィールドとして含まれてもよく、優先順位に応じて優先順位が高い情報のみ含んでもよい。ここで、優先順位は、災難警報メッセージの伝送にともなう重要度に応じて、それぞれの情報別に決定されてもよい。
【０７１７】
放送伝送装置３００は、災難警報インジケータ及び関連データをシグナリングチャネルを介して伝送する。また、放送伝送装置３００は、災難警報に関連した情報をシグナリングチャネルではなく、物理層パイプを介して伝送することができる。この時、シグナリングチャネルではなく、物理層パイプは一般物理層パイプということができる。
【０７１８】
また、放送伝送装置３００が伝送する災難警報関連データは、物理層パイプから災難警報情報を獲得するための経路情報であってもよい。具体的に、災難警報関連データは、災難警報情報を伝送する一般物理層パイプ(データパイプ)を識別するための情報であってもよい。
【０７１９】
放送受信装置１００は、シグナリングチャネルを介して災難警報インジケータ及び関連データを受信する。また、物理層は、放送信号の物理層に災難警報情報を伝送するシグナリングチャネルが存在するのか否かを示す情報を含むことができる。この時、シグナリングチャネルの存在の有無を示す情報は、PHY signalingといえる。放送受信装置１００は、PHY signalingに基づいて物理層内シグナリングチャネルの存在の有無を確認し、シグナリングチャネルから災難警報インジケータ及び関連データを受信する。
【０７２０】
放送受信装置１００は、災難警報シグナリングデコーダを介してシグナリングチャネルをデコーディングし、シグナリングチャネルから災難警報インジケータ及び関連データを獲得することができる。
【０７２１】
放送受信装置１００は、シグナリングチャネルから獲得した災難警報インジケータ及び関連データに基づいて、災難警報メッセージの伝達経路情報を獲得する。具体的に、放送受信装置１００は、災難警報インジケータから災難警報メッセージが伝送される物理層パイプの情報を獲得することができる。具体的に、放送受信装置１００は、災難警報インジケータから災難警報メッセージを伝送する物理層パイプを識別する識別情報を獲得することができる。
【０７２２】
放送受信装置１００は、災難警報インジケータに基づいて識別した物理層パイプを介して伝送されたパケットをデコーディングする。
【０７２３】
具体的な実施例で、放送受信装置１００は、パケットヘッダに基づいて、当該パケットが災難警報情報を含んでいるのか否かを判断することができる。また、放送受信装置１００は、パケットヘッダからパケットペイロードに含まれた災難警報情報の形態を判断することができる。例えば、放送受信装置１００は、パケットペイロードが全体災難警報テーブルを含んでいるのか否かを判断することができる。
【０７２４】
放送受信装置１００は、パケットヘッダから獲得した情報に基づいて、パケットペイロードから災難警報情報を獲得する。ここで、獲得した災難警報情報は、災難警報テーブルまたはCAPメッセージであってもよく、関連コンテンツ情報またはNRTサービス情報であってもよい。
【０７２５】
放送受信装置１００は、獲得したCAPメッセージをパッシングして災難警報情報を獲得することができる。この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００がEATを構成する過程で重複する部分を省略することができる。
【０７２６】
放送受信装置１００は、獲得した関連コンテンツ情報に基づいてオーディオ/ビデオコンテンツを受信することができる。具体的に、獲得した関連コンテンツ情報は、オーディオ/ビデオコンテンツを伝送するデータパイプを識別するための情報であってもよく、関連オーディオ/ビデオコンテンツを識別するための情報であってもよい。放送受信装置１００は、関連コンテンツ情報に基づいてオーディオ/ビデオコンテンツを伝送するデータパイプを識別する。そして、放送受信装置１００は、識別されたデータパイプを介してオーディオ/ビデオコンテンツを獲得し、獲得したオーディオ/ビデオコンテンツのうち災難警報情報に関連するコンテンツを獲得することができる。この時、コンテンツを伝送する物理層パイプは、災難警報情報を伝送する物理層パイプと区別される。また、放送受信装置１００は、獲得したNRTサービス情報に基づいて災難警報情報に関連したNRTサービスを獲得することができる。具体的に、NRTサービス情報からNRTサービスを獲得できるアドレス情報を獲得することができる。この時、放送受信装置１００は、NRTサービスをブロードバンドを介して受信することができる。
【０７２７】
放送受信装置１００は、獲得した災難警報メッセージをオーディオ/ビデオコンテンツと一緒に提供することができる。例えば、自動チャネル転換に対する情報が災難警報メッセージと一緒に伝送される場合、放送受信装置１００はチャネルを自動変更しながら災難警報メッセージを提供することができる。
【０７２８】
図７５は、図７４の実施例に係るシグナリングチャネルを介して伝送される災難警報をシグナリングするためのシンタックスの例である。具体的な実施例で、災難警報メッセージは、シグナリングチャネルを介して伝送されるテーブルの一部分であってもよい。また、図７５に示されたフィールドは、以降必要に応じて変更することができる。
【０７２９】
災難警報をシグナリングするためのテーブルは、当該災難警報テーブル内に災難警報関連データが含まれているのか否かを示すことができる。具体的に、災難警報関連データが含まれているのか否かを示す情報は、Emergency_alert_flagフィールドであってもよい。一実施例で、emergency_alert_flagフィールドが０の値を有する場合、現在のシグナリングチャネルまたはテーブルに災難警報のためのデータが含まれていないことを示す。また、emergency_alert_flagフィールドが１の値を有する場合、現在の災難警報テーブルに災難警報のためのデータが含まれていることを示す。
【０７３０】
例えば、emergency_alert_flagフィールドがイネーブルされた場合、災難警報テーブルは、災難警報情報に関連したフィールドを含むことができる。また、災難警報テーブルは、自動チャネル転換に関連したフィールドも含むことができる。
【０７３１】
災難警報をシグナリングするためのテーブルは、当該テーブルがシグナリングする災難警報メッセージを受信できる物理層パイプ情報を含むことができる。この場合、物理層パイプ情報は、EAS_DP_idフィールドであってもよい。具体的にEAS_DP_idフィールドは、災難警報メッセージを伝達する放送信号内のデータパイプを識別するための情報であってもよい。
【０７３２】
図７６は、本発明の一実施例に係る放送伝送装置３００の動作方法を示すフローチャートである。
【０７３３】
放送伝送装置３００は、警報当局６００から災難警報情報を受信する(Ｓ１０１)。ここで、警報当局６００は、災難管理当局、関係機関のうちいずれか一つである。また、放送伝送装置３００は、災難警報情報を情報収集装置７００を介して受信することもできる。この場合、放送伝送装置３００は、CAPメッセージに加工された災難警報情報を受信することができる。
【０７３４】
放送伝送装置３００は、受信した災難警報情報に基づいて、災難警報情報を含むテーブルまたは災難警報テーブルを含む災難警報パケットを生成する(Ｓ１０３)。具体的に、放送伝送装置３００の制御部は、災難警報情報を伝送する物理層パイプに応じて災難警報テーブルまたは災難警報パケットを生成することができる。
【０７３５】
一実施例で、制御部は、災難警報情報を指定された物理層パイプを介して伝送する場合、災難警報情報を含む災難警報テーブルを生成することができる。この場合、第１実施例で、災難警報テーブルは、災難警報情報を全部含むことができる。また、第２実施例で、災難警報テーブルは、災難警報情報の一部のみを含むことができる。ここで、災難警報情報の一部は、全体災難警報情報を伝送するための最小限の情報のみを含むことができる。
【０７３６】
また、他の実施例で、放送伝送装置３００の制御部は、災難警報情報をパケット伝送するための物理層パイプを介して伝送する場合、災難警報情報をパケットにカプセル化することができる。災難警報情報がカプセル化されたパケットは、災難警報パケットと称することができる。一実施例で、放送伝送装置３００の制御部は、災難警報情報をパケットのペイロードにカプセル化することができる。また、他の実施例で、制御部は、災難警報テーブルをパケットのペイロードにカプセル化することができる。
【０７３７】
また、放送伝送装置３００の制御部は、パケットペイロードのデータを識別するための情報をパケットのヘッダにカプセル化することができる。また、パケットのヘッダにカプセル化される情報は、当該パケットが災難警報情報を含んでいるパケットであることを知らせる情報であってもよい。
【０７３８】
放送伝送装置３００の制御部は、生成された災難警報テーブルまたは災難警報パケットを物理層パイプに挿入する(Ｓ１０５)。具体的に制御部は、災難警報テーブルまたは災難警報パケットを物理層パイプに挿入する。この時、物理層は、物理層が災難警報情報を含んでいることを示す情報を含むことができる。
【０７３９】
災難警報情報が物理層パイプに挿入されると、放送伝送装置３００は、物理層パイプを含む放送信号を伝送する(Ｓ１０７)。一実施例で、物理層パイプは、災難警報情報のみを伝送するために指定された物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送ストリームの構成情報、簡略な放送サービス情報及びコンポーネント情報のうち少なくともいずれか一つを含むサービスをスキャンするために必要な情報を伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、用途が指定されていない一般物理層パイプであってもよい。
【０７４０】
図７７は、本発明の一実施例に係る放送受信装置１００の動作方法を示すフローチャートである。
【０７４１】
放送受信装置１００は、物理層パイプを介して、災難警報情報を含む放送信号を放送受信部１１０を介して受信する(Ｓ２０１)。一実施例で、物理層パイプは、災難警報情報のみを伝送するために指定された物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送ストリームの構成情報、簡略な放送サービス情報及びコンポーネント情報及びコンポーネント情報のうち少なくともいずれか一つを伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、用途が指定されていない一般物理層パイプであってもよい。
【０７４２】
放送受信装置１００の制御部１５０は、受信された放送信号から災難警報情報が含まれた伝送パケットを抽出する(Ｓ２０３)。一実施例で、伝送パケットは、災難警報テーブルを含むことができる。この場合、災難警報テーブルは、災難警報情報を獲得するための最小限の情報のみを含むこともできる。また、他の実施例で、伝送パケットは、災難警報パケットを含むことができる。放送受信装置１００の制御部１５０は、抽出した伝送パケットをデコーディングして災難警報情報を獲得する(Ｓ２０５)。即ち、制御部１５０は伝送パケットから災難警報情報を抽出する。具体的に、伝送パケットに含まれた災難警報テーブルまたは災難警報パケットをデコーディングして災難警報情報を獲得する。一実施例で、制御部１５０は、災難警報テーブルの特定情報または災難警報パケットのヘッダに基づいて伝送パケットをデコーディングすることができる。また、他の実施例で、放送受信装置１００は、災難警報テーブルをデコーディングして獲得した情報に基づいて伝送パケットをデコーディングすることができる。具体的に、災難警報テーブルから災難警報情報を伝送する物理層パイプを識別し、識別された物理層パイプを介して受信した伝送パケットをデコーディングすることができる。
【０７４３】
放送受信装置１００の制御部１５０は、獲得した災難警報情報に関連サービス情報が含まれているのか否かを判断する(Ｓ２０７)。具体的に、制御部１５０は、災難警報情報に関連した関連コンテンツの情報が含まれているのか否かを判断する。ここで、関連コンテンツは、リアルタイムコンテンツ及び非リアルタイムコンテンツのうちいずれか一つである。
【０７４４】
例えば、関連コンテンツが存在すると判断した場合、放送受信装置１００の制御部１５０は、獲得した関連コンテンツ情報がリアルタイムコンテンツであるのか否かを判断する(Ｓ２０９)。具体的に、災難警報情報に関連したコンテンツがリアルタイムコンテンツであるのか非リアルタイムコンテンツであるのかを判断する。ここで、リアルタイムコンテンツは、オーディオ/ビデオコンテンツであってもよい。リアルタイムコンテンツであるのか否かの判断は、災難警報テーブルの特定情報によって判断することができる。または、パケットヘッダに含まれた情報によって判断することができる。
【０７４５】
関連コンテンツをリアルタイムコンテンツであると判断した場合、制御部１５０は、コンテンツを伝送する物理層パイプを介して関連コンテンツを獲得する(Ｓ２１１)。具体的に、災難警報情報が関連コンテンツを獲得できる経路情報を含むことができる。従って、制御部１５０は、当該情報に基づいて関連コンテンツを伝送する物理層パイプを識別してコンテンツを獲得することができる。
【０７４６】
しかし、関連コンテンツを非リアルタイムコンテンツであると判断した場合、制御部１５０は、非リアルタイムコンテンツを獲得するための経路情報を抽出する(Ｓ２１５)。非リアルタイムコンテンツを獲得するための情報は、アドレス情報であってもよい。例えば、URI情報であってもよい。
【０７４７】
放送受信装置１００は、抽出した経路情報に基づいて、IPコミュニケーションユニット１３０を介して非リアルタイムサービスを獲得する(Ｓ２１７)。具体的に、放送受信装置１００は、アドレス情報を利用してブロードバンドを介して非リアルタイムサービスを獲得する。
【０７４８】
放送受信装置１００は、獲得した災難警報情報を関連サービスと一緒に提供する(Ｓ２１３)。具体的に、放送受信装置１００は、災難警報情報を関連サービスと一緒に出力する。この時、関連サービスは、リアルタイムサービス及び非リアルタイムサービスのうちのいずれか一つである。
【０７４９】
上述したように、放送伝送装置３００は、災難警報情報を放送網を介して放送受信装置１００に伝送することができる。具体的な実施例で、放送受信装置１００は、モバイル放送受信装置であってもよい。また、モバイル放送受信装置は、独立的に放送信号を放送伝送装置３００から受信でき、上述したように放送伝送装置３００を経て受信する連動装置２００であってもよい。
【０７５０】
この時、一般的に放送受信装置１００は、災難警報情報を含む放送信号を受信するためにウェイクアップ(wake up)状態とスリップ(sleep)状態を繰り返し、フレーム毎に放送信号を確認することができる。ここで、ウェイクアップ状態とは、物理層を介して伝送される放送信号が災難警報情報を含むのか否かを感知する放送受信装置１００の状態であってもよい。即ち、放送受信装置の災難警報情報感知機能が活性化状態であってもよい。逆に、スリップ状態は、放送信号から災難警報情報を感知しない放送受信装置１００の状態をいう。即ち、放送受信装置の災難警報情報感知機能が非活性化された状態であってもよい。
【０７５１】
しかし、この場合、放送受信装置１００は、放送信号に災難警報情報がない場合にも、周期的にウェイクアップして不必要な電力及びリソース消耗が発生する可能性がある。これを補完するために、放送伝送装置３００が放送網を介して放送受信装置１００に災難警報情報を確認できる情報を一緒に伝送することができる。具体的に、放送伝送装置３００が放送受信装置１００に災難警報情報を感知(detection)できる時間情報を伝送することができる。ここで、時間情報は、連動装置がウェイクアップされる時間に対する情報であってもよい。従って、放送受信装置１００が一定時間の間ウェイクアップされて災難警報情報を感知した後、再びスリップ状態に戻ることができる。結果的に、放送受信装置１００が毎フレーム単位別にウェイクアップして災難警報情報を確認する必要がないので、不必要な電力及びリソース消耗を減らすことができる。
【０７５２】
図７８は、放送伝送装置３００が放送受信装置１００に伝送する感知時間周期テーブルのためのシンタックスである。
【０７５３】
図７８に示すように、感知周期テーブルは、感知開始時間情報を含むことができる。具体的に、感知開始時間情報は、災難警報情報の感知を始める開始時間情報であってもよい。即ち、感知開始時間情報は、放送受信装置１００がウェイクアップされる時間情報であってもよい。具体的な実施例で、感知開始時間情報は、ミリ秒単位で表現することができる。また、感知開始時間情報は、detection_start_timeフィールドであってもよい。detection_start_timeフィールドは３２ビットであってもよい。
【０７５４】
また、感知周期テーブルは、感知持続時間情報を含むことができる。具体的に、感知周期テーブルは、放送受信装置１００の状態が災難警報情報を感知するためにウェイクアップされた場合、ウェイクアップ状態が維持される時間情報を含むことができる。具体的な実施例で、感知持続時間情報は、ミリ秒単位の１０進数で表現することができる。また、感知持続時間情報は、detection_durationフィールドであってもよい。detection_durationフィールドは３２ビットであってもよい。
【０７５５】
また、感知周期テーブルは、スリップ持続時間情報を含むことができる。具体的に感知周期テーブルは、放送受信装置１００の状態が災難警報を感知しないスリップ状態に維持される時間情報を含むことができる。具体的な実施例で、スリップ持続時間情報は、detection_sleep_durationフィールドであってもよい。また、detection_sleep_durationフィールドは３２ビットであってもよい。
【０７５６】
図７９は、感知周期情報に応じた放送受信装置１００の動作の実施例を示す。図７９に示すように、放送受信装置１００は、災難警報情報と一緒に伝達された感知周期情報に含まれた感知開始時間によってウェイクアップ状態となる。即ち、放送受信装置１００は、感知周期情報を受信した時間を基準時間として、感知開始時間情報に応じてウェイクアップ状態となることができる。この場合、感知開始時間情報は、感知周期情報を受信した時間を基準とした相対的な時間情報である。
【０７５７】
放送受信装置１００は、ウェイクアップ状態で、感知持続時間情報に応じてウェイクアップ状態を維持する。この場合、感知持続時間情報は、感知開始時間情報を基準とした相対的な時間情報である。
【０７５８】
そして、放送受信装置１００は、感知持続時間が経過するとスリップ状態に戻る。スリップ状態は、スリップ持続時間情報に応じて維持される。この場合、スリップ持続時間情報は、スリップ状態に変更された時点を基準とする相対的な時間であってもよい。
【０７５９】
一方、本発明の実施例で、感知開始時間情報は、放送受信装置１００の最初のウェイクアップ時のみに用いられてもよい。以降は、感知持続時間情報及びスリップ持続時間情報に応じて、放送受信装置１００の状態が変更する。また、他の実施例で、連動装置は、追加的な感知周期情報が受信されない場合、既存の感知周期情報に応じて状態を変更することができる。この場合、放送受信装置１００の状態維持周期を変更するために、放送伝送装置３００は、新たな感知周期情報を放送受信装置１００に伝送することができる。
【０７６０】
図８０は、感知周期情報が追加された災難警報テーブルのシンタックスを示す。
【０７６１】
図８０に示すように、災難警報テーブル(EAT)は、当該テーブルに感知周期情報が含まれているのか否かを示すことができる。この時、感知周期情報が含まれているのか否かを示す情報は、detetion_interval_flagフィールドであってもよい。具体的な実施例で、detetion_interval_flagフィールドがイネーブルされる場合、当該テーブルが感知周期情報を含んでいることを示す。例えば、detetion_interval_flagフィールドが１の値を有する場合、detetion_interval_flagフィールドがイネーブルされることに設定することができる。
【０７６２】
例えば、detetion_interval_flagフィールドがイネーブルされる場合、災難警報テーブルは、感知周期情報を含むことができる。反面、detetion_interval_flagフィールドがイネーブルされない場合(例えば、detetion_interval_flagフィールドが０の値を有する場合)、災難警報テーブルは、感知周期情報を含まなくてもよい。
【０７６３】
図８１は、災難警報情報及び感知周期情報がシグナリングチャネルに含まれる場合に対する実施例を示す。具体的な実施例で、シグナリングチャネルは、FIC(Fast Information Channel)であってもよい。
【０７６４】
図８０で説明したこと同様に、シグナリングチャネルは、感知周期情報が含まれているのか否かを示す情報を含むことができる。そして、当該情報に応じて感知周期情報を含むことができる。
【０７６５】
一方、放送伝送装置３００が感知周期情報を任意に設定することができるが、災難状況情報に基づいて感知周期情報を設定することもできる。この時、放送伝送装置３００は、災難状況情報を獲得するために災難警報メッセージを利用することができる。ここで、災難警報メッセージは、CAP(Common Alerting Protocol)メッセージ形態で伝達されてもよい。
【０７６６】
図８２は、災難状況情報を伝送するためのCAPメッセージの一例を示す。この場合、CAPメッセージはXML形態であってもよい。
【０７６７】
図８３は、感知周期情報を設定するための災難状況情報の一例を示す。
【０７６８】
本実施例は、災難状況情報のうち、特に地域情報に基づいて感知周期を設定する。具体的に、図８２に示すように、災難状況が発生した地域に該当する放送伝送装置３００は、感知周期を通常の状況より短く設定し、放送受信装置１００のウェイクアップ状態をより頻繁に維持させることができる。
【０７６９】
図８３を例にすると、現在Ｂ地域が災難発生地域として、災難が発生しないＡ地域より頻繁に災難警報情報を放送受信装置１００に伝送する必要がある。従って、この場合、Ｂ地域の放送伝送装置は、Ａ地域の放送装置より相対的に感知時間情報及び状態維持時間を短く設定することができる。
【０７７０】
本発明の実施例によれば、感知周期に応じて災難警報情報を感知してバッテリー消耗を減らすことはできるが、毎時間フレームを確認する方法に比べて、即刻災難警報情報を受信することに困難がある。従って、放送伝送装置３００が災難発生地域によって感知周期を異なるように設定して上述した問題点を克服することができる。
【０７７１】
この時、放送伝送装置３００で感知周期設定のための災難地域の位置情報は、情報収集装置７００から受信するCAPメッセージから獲得することができる。具体的に、災難地域位置情報は、CAPメッセージの<area>情報を介して獲得することができる。
【０７７２】
また、他の実施例で、放送受信装置１００が災難地域であるＢ地域からＡ地域に移動した場合、放送受信装置１００は、一般的な周期に応じて災難警報情報を感知することができる。具体的に、放送受信装置１００が位置を移動することで、災難警報情報を伝送する放送伝送装置が変わることになる。従って、使用者が災難地域に位置する時より、相対的に災難警報情報を即刻に伝達する必要性が減少するので、災難地域における感知周期より相対的に長い感知周期に戻ることができる。
【０７７３】
また、他の実施例で、放送信号が複数受信される場合、放送受信装置１００は、さらに短い感知周期情報を有する放送信号に基づいて災難警報情報を感知することができる。具体的な実施例で、放送受信装置１００が２ミリ秒を感知周期とする放送信号と０.５ミリ秒を感知周期とする放送信号を両方とも受信した場合がありえる。この場合、放送受信装置１００は、さらに短い周期である０.５ミリ秒を感知周期とする感知周期情報に基づいて災難警報情報を獲得することができる。
【０７７４】
図８４〜８６は、放送伝送装置３００が感知周期情報を災難警報の優先順位情報(Priority Information)に基づいて設定することを示す。
【０７７５】
災難警報は、それぞれ同じレベルであるとは限らない。従って、全ての災難に対して同じレベルの感知周期を設定する場合、バッテリー及びリソース消耗減少の目的を達成することが困難となる。
【０７７６】
本発明の一実施例によれば、災難警報の優先順位に対する情報を放送伝送装置３００が受信し、これに基づいて感知周期を設定することができる。ここで、災難警報の優先順位は、情報収集装置７００から受信することができる。具体的に、情報収集装置７００から受信できるCAPメッセージから災難警報の優先順位情報を獲得することができる。具体的な実施例で、放送伝送装置３００は、CAPメッセージに含まれた<urgency>、<severity>及び<certainty>のいずれか一つの情報を獲得することができる。放送伝送装置は、当該情報に基づいて感知周期を設定することができる。
【０７７７】
本発明の実施例によれば、放送伝送装置３００は、CAPメッセージに含まれた災難警報情報のカテゴリー別に優先順位を判断することができる。具体的に、放送伝送装置３００は、各カテゴリー別に含まれた区間に応じて優先順位を判断することができる。ここで、カテゴリーとは、CAPメッセージに含まれた災難警報情報である。
【０７７８】
放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報が有するそれぞれの等級に基づいて、優先順位を区分することができる。この時、放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報のうち最も高い優先順位を有する値に応じて災難警報の優先順位を判断することができる。
【０７７９】
具体的な実施例で、放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報の等級によって、３つの緊急度に区分することができる。
【０７８０】
例えば、放送受信装置１００は、図５２の実施例のように、Urgencyエレメントの等級がImmediateまたはExpectedに該当する場合最も高い優先順位、Futureに該当する場合最も高い優先順位より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位、Pastに該当する場合最も低い優先順位、Unknownに該当する場合初期値に該当する優先順位を有すると判断することができる。この時、初期値は、最も高い優先より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位である。
【０７８１】
また、放送受信装置１００は、図５２の実施例のように、Severityエレメントの等級がExtremeまたはSevereに該当する場合最も高い優先順位、Moderateに該当する場合最も高い優先順位より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位、Minorに該当する場合最も低い優先順位、Unknownに該当する場合初期値に該当する優先順位を有すると判断することができる。この時、初期値は、最も高い優先より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位である。
【０７８２】
また、放送受信装置１００は、図５２の実施例のように、Certaintyエレメントの等級がVery likelyまたはlikelyに該当する場合最も高い優先順位、Possibleに該当する場合最も高い優先順位より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位、Unlikelyに該当する場合最も低い優先順位、Unknownに該当する場合初期値に該当する優先順位を有すると判断することができる。この時、初期値は、最も高い優先より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位である。
【０７８３】
また、他の実施例で、放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報が有するそれぞれの等級に基づいてポイントを付与し、ポイントの合計に応じて災難警報の優先順位を判断することができる。
【０７８４】
具体的な実施例で、放送受信装置１００は、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報に、同じ比重でポイントを付与することができる。例えば、放送受信装置１００は、図５３の実施例のように、Urgencyエレメントの等級がImmediateに該当する場合に５、Expectedに該当する場合に４、Futureに該当する場合に３、Pastに該当する場合に２、Unknownに該当する場合に１のポイントを付与することができる。
【０７８５】
また、放送受信装置１００は、図５３の実施例のように、Severityエレメントの等級がExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に１のポイントを付与することができる。
【０７８６】
また、放送受信装置１００は、図５３の実施例のように、Certaintyエレメントの等級がVery likelyに該当する場合に５、likelyに該当する場合に４、Possibleに該当する場合に３、Unlikelyに該当する場合に２、Unknownに該当する場合に１ポイントを付与することができる。この時、放送受信装置１００は、ポイントの合計が１０より大きいか、１５より小さいか同一である場合、災難警報が最も高い優先順位を有すると決定することができる。
【０７８７】
また、放送受信装置１００は、ポイントの合計が５より大きいか、１０より小さいか同一である場合、災難警報が最も高い優先順位より低く最も低い優先順位より高い中間優先順位を有すると決定することができる。
【０７８８】
また、放送受信装置１００は、ポイントの合計が０より大きいか、５より小さいか同一である場合、災難警報が最も低い優先順位を有すると決定することができる。
【０７８９】
また、他の具体的な実施例で、放送受信装置１００は、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報に、それぞれ異なる比重でポイントを付与することができる。
【０７９０】
例えば、放送受信装置１００は、図５４の実施例のように、Urgencyエレメントの等級がImmediateに該当する場合に９、Expectedに該当する場合に８、Futureに該当する場合に７、Pastに該当する場合に５、Unknownに該当する場合に０のポイントを付与することができる。
【０７９１】
また、放送受信装置１００は、図５４の実施例のように、Severityエレメントの等級がExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に０のポイントを付与することができる。
【０７９２】
また、放送受信装置１００は、図５４の実施例のように、Certaintyエレメントの等級がVery likelyに該当する場合に６、likelyに該当する場合に５、Possibleに該当する場合に４、Unlikelyに該当する場合に３、Unknownに該当する場合に０ポイントを付与することができる。この時、放送受信装置１００は、ポイントの合計が１０より大きいか、１５より小さいか同一である場合、災難警報が最も高い優先順位を有すると決定することができる。
【０７９３】
また、放送受信装置１００は、ポイントの合計が５より大きいか、１０より小さいか同一である場合、災難警報が最も高い優先順位より低く最も低い優先順位より高い中間優先順位を有すると決定することができる。
【０７９４】
また、放送受信装置１００は、ポイントの合計が０より大きいか、５より小さいか同一である場合、災難警報が最も低い優先順位を有すると決定することができる。
【０７９５】
この時、放送伝送装置３００は、区分された優先順位に応じて感知周期を設定することができる。具体的に、最も高い優先順位である場合、感知周期を最も短く設定し、最も低い優先順位である場合、感知周期を最も長く設定することができる。最も低い優先順位より高い中間優先順位を有する災難警報の場合、最も短い感知周期より長い感知周期を設定することができる。
【０７９６】
この時、最も短い感知周期及び最も長い感知周期は、放送伝送装置３００に既設定された値であってもよい。また、放送伝送装置３００は、それぞれの優先順位に対応する感知周期値を予め格納していてもよい。この時、放送伝送装置３００は、獲得した優先順位に対応する感知周期値を放送信号に設定することができる。
【０７９７】
図８７は、本発明の一実施例に係る放送伝送装置３００の動作方法を示すフローチャートである。
【０７９８】
放送伝送装置３００は、警報当局６００から災難警報情報を受信する(Ｓ３０１)。この場合、放送伝送装置３００は、情報収集装置７００を介して災難警報情報を受信することができる。具体的な実施例で、受信した災難警報情報は、CAPメッセージであってもよい。そして、CAPメッセージは、災難状況情報を含むことができる。
【０７９９】
放送伝送装置３００の制御部は、受信した災難警報情報から災難状況情報を獲得する(Ｓ３０３)。具体的に、災難警報情報をパッシングして災難状況情報を獲得することができる。一例として、災難状況情報は、現在災難が発生した位置情報であってもよい。また、他の例として、災難状況情報は、発生災難の危急程度に関する情報であってもよい。
【０８００】
放送伝送装置３００の制御部は、獲得した災難状況情報に基づいて災難感知周期情報を設定する(Ｓ３０５)。具体的に、制御部は、災難状況に応じて放送受信装置１００のための災難感知周期を設定する。
【０８０１】
一実施例で、放送伝送装置３００の制御部は、災難が発生した位置情報に応じて災難感知周期を設定することができる。例えば、当該放送伝送装置３００が位置した地域で災難が発生した場合、放送受信装置１００のための災難感知周期を通常の周期より短く設定することができる。
【０８０２】
また、他の実施例で、放送伝送装置３００の制御部は、発生した災難の危急程度に関する情報に応じて災難感知周期を設定することができる。例えば、災難危急程度が高い優先順位であると判断される場合、災難感知周期を通常の周期より短く設定することができる。この時、優先順位は、複数の危急程度を示す情報に基づいて判断することができる。
【０８０３】
放送伝送装置３００の伝送部は、設定された災難感知周期情報を含む放送信号を伝送する(Ｓ３０７)。一実施例で、放送伝送装置の制御部は、災難感知周期情報を災難警報テーブルに挿入して伝送することができる。また、他の実施例で、放送伝送装置３００の制御部は、災難感知周期情報をシグナリングチャネルに挿入して伝送することができる。また、他の実施例で、放送伝送装置３００の制御部は、災難感知周期情報をパケットに挿入して伝送することもできる。
【０８０４】
図８８は、本発明の一実施例に係る放送受信装置１００の動作方法を示すフローチャートである。ここで、放送受信装置１００は、モバイル放送受信装置であってもよい。
【０８０５】
放送受信装置１００の放送受信部１１０は、災難感知周期を含む放送信号を受信する(Ｓ４０１)。放送受信装置１００は、放送信号を地上波放送網及びブロードバンドのうちいずれか一つを介して受信することができる。
【０８０６】
放送受信装置１００の制御部１５０は、放送信号から災難感知周期情報を獲得する(Ｓ４０３)。具体的に制御部１５０は、放送信号をデコーディングして災難感知周期情報を獲得することができる。この時、災難感知周期情報は、感知開始時間情報、感知持続時間情報及びスリップ持続時間情報のうちいずれか一つを含むことができる。一実施例で、災難感知周期情報は、ミリ秒単位の１０進数で表現することができ、特定基準値からの相対的な時間値を有することができる。
【０８０７】
放送受信装置１００の制御部１５０は、災難周期感知情報に基づいて放送受信装置１００をウェイクアップ状態に変更する(Ｓ４０５)。ここで、ウェイクアップ状態は、放送受信装置１００が放送信号に災難警報情報が含まれているのか否かを感知できる状態である。即ち、制御部１５０の災難警報情報を感知するための機能が活性化されている状態である。逆に、スリップ状態は、制御部１５０の災難警報情報を感知するための機能が非活性化されている状態である。
【０８０８】
具体的に、制御部１５０は、災難周期感知情報の感知開始時間情報に基づいて、放送受信装置１００をウェイクアップ状態に変更する。この時、制御部は、放送信号を受信した時間を基準に放送受信装置１００の状態を変更することができる。
【０８０９】
放送受信装置１００の制御部１５０は、ウェイクアップ状態で災難警報情報を感知する(Ｓ４０７)。具体的に、制御部１５０は、放送信号に災難警報情報が含まれているのか否かを判断し、含まれている場合、災難警報情報を獲得する。
【０８１０】
放送受信装置１００の制御部１５０は、ウェイクアップ状態で感知持続時間が経過したのか否かを判断する(Ｓ４０９)。具体的に制御部１５０は、災難周期感知情報に含まれた感知持続時間に基づいて経過したのか否かを判断する。この場合、制御部１５０は、放送受信装置１００がウェイクアップ状態となった時間を基準に感知持続時間が経過したのか否かを判断することができる。
【０８１１】
もし制御部１５０がまだ感知持続時間が経過していないと判断した場合、災難警報情報の感知を継続する。
【０８１２】
しかし、感知持続時間が経過したと判断された場合、制御部１５０は、放送受信装置１００をスリップ状態に変更する。ここで、スリップ状態は、放送受信装置１００が災難警報情報を感知しない状態である。制御部１５０は、スリップ状態を災難感知周期情報に含まれたスリップ持続時間情報に基づいて維持することができる。この場合、感知持続時間が終了した時間が、スリップ持続を維持するための基準時間であってもよい。
【０８１３】
一方、制御部１５０は、新たな災難感知周期情報を受信する時まで、既存の周期を維持する。
【０８１４】
以上、実施例に説明された特徴、構造、効果などは、本発明の少なくとも１つの実施例に含まれ、必ずしも１つの実施例のみに限定されるものではない。また、各実施例で例示された特徴、構造、効果などは、実施例が属する分野の通常の知識を有する者により他の実施例に対しても組合または変形して実施可能である。従って、このような組合と変形に係る内容は、本発明の範囲に含まれるものと解釈されるべきである。
【０８１５】
以上、本発明を実施例を中心に説明したが、これは単なる例示であり、本発明を限定するものではない。本発明が属する分野の通常の知識を有した者であれば、本実施例の本質的な特性を逸脱しない範囲内で、以上に例示されていない変形と応用が可能である。例えば、実施例に具体的に提示された各構成要素は変形して実施することができ、そのような変形と応用にかかわる差異点は、添付された特許請求の範囲で規定する本発明の範囲に含まれると解釈されるべきである。
【図１】
0006321195.tif 000050
【図２】
0006321195.tif 000051
【図３】
0006321195.tif 000052
【図４】
0006321195.tif 000053
【図５（ａ）】
0006321195.tif 000054
【図５（ｂ）】
0006321195.tif 000055
【図６（ａ）】
0006321195.tif 000056
【図６（ｂ）】
0006321195.tif 000057
【図７】
0006321195.tif 000058
【図８】
0006321195.tif 000059
【図９】
0006321195.tif 000060
【図１０】
0006321195.tif 000061
【図１１】
0006321195.tif 000062
【図１２】
0006321195.tif 000063
【図１３】
0006321195.tif 000064
【図１４】
0006321195.tif 000065
【図１５】
0006321195.tif 000066
【図１６】
0006321195.tif 000067
【図１７】
0006321195.tif 000068
【図１８】
0006321195.tif 000069
【図１９（ａ）】
0006321195.tif 000070
【図１９（ｂ）】
0006321195.tif 000071
【図２０（ａ）】
0006321195.tif 000072
【図２０（ｂ）】
0006321195.tif 000073
【図２１（ａ）】
0006321195.tif 000074
【図２１（ｂ）】
0006321195.tif 000075
【図２２】
0006321195.tif 000076
【図２３】
0006321195.tif 000077
【図２４（ａ）】
0006321195.tif 000078
【図２４（ｂ）】
0006321195.tif 000079
【図２５（ａ）】
0006321195.tif 000080
【図２５（ｂ）】
0006321195.tif 000081
【図２５（ｃ）】
0006321195.tif 000082
【図２６】
0006321195.tif 000083
【図２７】
0006321195.tif 000084
【図２８】
0006321195.tif 000085
【図２９】
0006321195.tif 000086
【図３０】
0006321195.tif 000087
【図３１】
0006321195.tif 000088
【図３２】
0006321195.tif 000089
【図３３】
0006321195.tif 000090
【図３４】
0006321195.tif 000091
【図３５】
0006321195.tif 000092
【図３６（ａ）】
0006321195.tif 000093
【図３６（ｂ）】
0006321195.tif 000094
【図３６（ｃ）】
0006321195.tif 000095
【図３７】
0006321195.tif 000096
【図３８】
0006321195.tif 000097
【図３９】
0006321195.tif 000098
【図４０】
0006321195.tif 000099
【図４１】
0006321195.tif 000100
【図４２】
0006321195.tif 000101
【図４３（ａ）】
0006321195.tif 000102
【図４３（ｂ）】
0006321195.tif 000103
【図４３（ｃ）】
0006321195.tif 000104
【図４３（ｄ）】
0006321195.tif 000105
【図４４】
0006321195.tif 000106
【図４５】
0006321195.tif 000107
【図４６】
0006321195.tif 000108
【図４７】
0006321195.tif 000109
【図４８（ａ）】
0006321195.tif 000110
【図４８（ｂ）】
0006321195.tif 000111
【図４８（ｃ）】
0006321195.tif 000112
【図４９】
0006321195.tif 000113
【図５０】
0006321195.tif 000114
【図５１】
0006321195.tif 000115
【図５２】
0006321195.tif 000116
【図５３】
0006321195.tif 000117
【図５４（ａ）】
0006321195.tif 000118
【図５４（ｂ）】
0006321195.tif 000119
【図５４（ｃ）】
0006321195.tif 000120
【図５５】
0006321195.tif 000121
【図５６】
0006321195.tif 000122
【図５７】
0006321195.tif 000123
【図５８】
0006321195.tif 000124
【図５９】
0006321195.tif 000125
【図６０】
0006321195.tif 000126
【図６１】
0006321195.tif 000127
【図６２】
0006321195.tif 000128
【図６３】
0006321195.tif 000129
【図６４】
0006321195.tif 000130
【図６５】
0006321195.tif 000131
【図６６】
0006321195.tif 000132
【図６７】
0006321195.tif 000133
【図６８】
0006321195.tif 000134
【図６９】
0006321195.tif 000135
【図７０】
0006321195.tif 000136
【図７１】
0006321195.tif 000137
【図７２】
0006321195.tif 000138
【図７３】
0006321195.tif 000139
【図７４】
0006321195.tif 000140
【図７５】
0006321195.tif 000141
【図７６】
0006321195.tif 000142
【図７７】
0006321195.tif 000143
【図７８】
0006321195.tif 000144
【図７９】
0006321195.tif 000145
【図８０】
0006321195.tif 000146
【図８１】
0006321195.tif 000147
【図８２】
0006321195.tif 000148
【図８３】
0006321195.tif 000149
【図８４】
0006321195.tif 000150
【図８５】
0006321195.tif 000151
【図８６】
0006321195.tif 000152
【図８７】
0006321195.tif 000153
【図８８】
0006321195.tif 000154