(57)【要約】  連動装置と連動する放送サービスを受信する放送受信装置は、前記連動装置とのペアリングセッションを形成するＩＰ通信部と、前記放送サービスに基づいて、災害状況に対して警報する緊急警報を含む緊急警報メッセージを受信する放送通信部と、前記連動装置に前記緊急警報メッセージに関する情報を伝送する制御部と、を含む。【選択図】図５０
2017511989.tif 000002
【特許請求の範囲】
【請求項１】
連動装置と連動する放送サービスを受信する放送受信装置において、
前記連動装置とのペアリングセッションを形成するＩＰ通信部と、
前記放送サービスに基づいて、災害状況に対して警報する緊急警報を含む緊急警報メッセージを受信する放送通信部と、
前記連動装置に前記緊急警報メッセージに関する情報を伝送する制御部と、
を含む、放送受信装置。
【請求項２】
前記制御部は、
前記連動装置に前記緊急警報に関するユーザインターフェース（User Interface、UI）情報を伝送する、請求項１に記載の放送受信装置。
【請求項３】
前記ＵＩに関する情報は、
前記緊急警報に関するＵＩリストを含む、請求項２に記載の放送受信装置。
【請求項４】
前記制御部は、
前記連動装置に前記緊急警報に関する情報を獲得できるＵＲＬを伝送する、請求項１に記載の放送受信装置。
【請求項５】
前記制御部は、
前記連動装置に前記緊急警報に関する複数の情報のうち前記連動装置が指定した情報を前記緊急警報メッセージから抽出して伝送する、請求項１に記載の放送受信装置。
【請求項６】
前記緊急警報メッセージは、
前記緊急警報を識別する識別子、前記緊急警報のカテゴリーを示す情報、前記緊急警報に関する説明を示す情報、前記緊急警報に該当する地域を示す情報、前記緊急警報の緊急度を示す情報、前記緊急警報を誘発した災害の深刻性を示す情報及び前記緊急警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを含む、請求項１に記載の放送受信装置。
【請求項７】
前記放送通信部は、
前記放送サービスの属性をシグナリングする情報を受信し、
前記制御部は、
前記放送サービスの属性をシグナリングする情報に基づいて前記放送サービスの属性が変更されたか否かを連動装置に通知する、請求項１に記載の放送受信装置。
【請求項８】
前記制御部は、
前記放送サービスの複数の属性のうち前記連動装置が指定した属性に基づいて前記放送サービスの属性が変更されたか否かを連動装置に通知する、請求項７に記載の放送受信装置。
【請求項９】
前記制御部は、
前記連動装置に前記放送サービスの属性を獲得できるＵＲＬを伝送する、請求項７に記載の放送受信装置。
【請求項１０】
前記制御部は、
前記放送サービスの属性をシグナリングする情報から前記放送サービスの複数の属性のうち前記連動装置が指定した属性を抽出して、前記連動装置に前記放送サービスの複数の属性のうち前記連動装置が指定した属性を伝送する、請求項７に記載の放送受信装置。
【請求項１１】
前記放送サービスの属性は、
放送サービスを提供できる装置の情報を示すターゲティング属性を含む、請求項７に記載の放送受信装置。
【請求項１２】
連動装置と連動する放送サービスを受信する放送受信装置の動作方法において、
前記連動装置とのペアリングセッションを形成するステップと、
前記放送サービスに基づいて、災害状況に対して警報する緊急警報を含む緊急警報メッセージを受信するステップと、
前記連動装置に前記緊急警報メッセージに関する情報を伝送するステップと、
を含む、動作方法。
【請求項１３】
前記連動装置に前記緊急警報に関するユーザインターフェース（User Interface、UI）情報を伝送するステップをさらに含む、請求項１２に記載の動作方法。
【請求項１４】
前記ＵＩに関する情報は、
前記緊急警報に関するＵＩリストを含む、請求項１３に記載の動作方法。
【請求項１５】
前記連動装置に前記緊急警報に関する情報を獲得できるＵＲＬを伝送するステップをさらに含む、請求項１２に記載の動作方法。
【請求項１６】
前記連動装置に前記緊急警報に関する複数の情報のうち前記連動装置が指定した情報を前記緊急警報メッセージから抽出して伝送するステップをさらに含む、請求項１２に記載の動作方法。
【請求項１７】
前記緊急警報メッセージは、
前記緊急警報を識別する識別子、前記緊急警報のカテゴリーを示す情報、前記緊急警報に関する説明を示す情報、前記緊急警報に該当する地域を示す情報、前記緊急警報の緊急度を示す情報、前記緊急警報を誘発した災害の深刻性を示す情報及び前記緊急警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを含む、請求項１２に記載の動作方法。
【請求項１８】
前記放送サービスの属性をシグナリングする情報を受信するステップと、
前記放送サービスの属性をシグナリングする情報に基づいて前記放送サービスの属性が変更されたか否かを連動装置に通知するステップをさらに含む、請求項１２に記載の動作方法。
【請求項１９】
前記放送サービスの属性が変更されたか否かを連動装置に通知するステップは、
前記放送サービスの複数の属性のうち前記連動装置が指定した属性に基づいて前記放送サービスの属性が変更されたか否かを連動装置に通知するステップを含む、請求項１８に記載の動作方法。
【請求項２０】
前記連動装置に前記放送サービスの属性を獲得できるＵＲＬを伝送するステップをさらに含む、請求項１８に記載の動作方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送受信装置及び放送受信装置の動作方法に関する。
【背景技術】
【０００２】
デジタル放送環境及び通信環境の発展に伴い、既存の放送網だけではなく、通信網（broadband）を利用するハイブリッド放送が注目を集めている。また、このようなハイブリッド放送は、スマートフォンやタブレットなどの端末装置と連動するアプリケーションや放送サービスを提供している。スマートフォンやタブレットなどの端末装置の使用が増加することによってスマートフォンやタブレットなどの端末装置と効率的に連動できる放送サービスを提供する必要がある。
【０００３】
特に、放送サービスの属性や放送を介して伝送される緊急警報などの情報をスマートフォンやタブレットなどの端末装置に効率的に提供できる放送サービスが必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の一実施例は、端末装置と効率的に連動できる放送サービスを提供する放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【０００５】
特に、本発明の一実施例は、端末装置に情報を効率的に伝送するようにする放送サービスを提供する放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一実施例に係る連動装置と連動する放送サービスを受信する放送受信装置は、前記連動装置とのペアリングセッションを形成するＩＰ通信部と、前記放送サービスに基づいて、災害状況に対して警報する緊急警報を含む緊急警報メッセージを受信する放送通信部と、前記連動装置に前記緊急警報メッセージに関する情報を伝送する制御部と、を含む。
【０００７】
前記制御部は、前記連動装置に前記緊急警報に関するユーザインターフェース（User Interface、UI）情報を伝送することができる。
【０００８】
前記UIに関する情報は、前記緊急警報に関するUIリストを含むことができる。
【０００９】
前記制御部は、前記連動装置に前記緊急警報に関する情報を獲得できるURLを伝送することができる。
【００１０】
前記制御部は、前記連動装置に前記緊急警報に関する複数の情報のうち前記連動装置が指定した情報を前記緊急警報メッセージから抽出して伝送することができる。
【００１１】
前記緊急警報メッセージは、前記緊急警報を識別する識別子、前記緊急警報のカテゴリーを示す情報、前記緊急警報に関する説明を示す情報、前記緊急警報に該当する地域を示す情報、前記緊急警報の緊急度を示す情報、前記緊急警報を誘発した災害の深刻性を示す情報及び前記緊急警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを含むことができる。
【００１２】
前記放送通信部は、前記放送サービスの属性をシグナリングする情報を受信し、前記制御部は、前記放送サービスの属性をシグナリングする情報に基づいて前記放送サービスの属性変更可否を連動装置に通知することができる。
【００１３】
前記制御部は、前記放送サービスの複数の属性のうち前記連動装置が指定した属性に基づいて前記放送サービスの属性変更可否を連動装置に通知することができる。
【００１４】
前記制御部は、前記連動装置に前記放送サービスの属性を獲得できるURLを伝送することができる。
【００１５】
前記制御部は、前記放送サービスの属性をシグナリングする情報から前記放送サービスの複数の属性のうち前記連動装置が指定した属性を抽出して、前記連動装置に前記放送サービスの複数の属性のうち前記連動装置が指定した属性を伝送することができる。
【００１６】
前記放送サービスの属性は、放送サービスを提供できる装置の情報を示すターゲティング属性を含むことができる。
【００１７】
本発明の一実施例に係る連動装置と連動する放送サービスを受信する放送受信装置の動作方法は、前記連動装置とのペアリングセッションを形成するステップと、前記放送サービスに基づいて、災害状況に対して警報する緊急警報を含む緊急警報メッセージを受信するステップと、前記連動装置に前記緊急警報メッセージに関する情報を伝送するステップと、を含む。
【発明の効果】
【００１８】
本発明の一実施例は、端末装置と効率的に連動できる放送サービスを提供する放送受信装置及び放送受信装置の動作方法を提供する。
【００１９】
特に、本発明の一実施例は、端末装置に情報を効率的に伝送するようにする放送サービスを提供する放送受信装置及び放送受信装置の動作方法を提供する。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【図２】本発明の一実施例に係る入力フォーマット(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）を示す。
【図５５】本発明の他の実施例により放送受信装置が連動装置に緊急警報をシグナリングする動作を示すラダーダイアグラムである。
【図５６】本発明の他の実施例により放送受信装置が連動装置に緊急警報をシグナリングする動作を示すラダーダイアグラムである。
【図５７】本発明の他の実施例により放送受信装置が連動装置に緊急警報をシグナリングする動作を示すラダーダイアグラムである。
【発明を実施するための形態】
【００２１】
以下、添付した図面を参照して本発明の実施例に対して、本発明が属する技術分野で通常の知識を有した者が容易に実施できるように詳しく説明する。なお、本発明は多様な異なる形態に具現することができ、ここで説明する実施例に限定されない。そして、図面において、本発明を明確に説明するために説明と関係のない部分は省略しており、明細書全体において類似する部分に対しては、類似する図面符号を付している。
【００２２】
また、ある部分がある構成要素を「含む」とした場合、これは特に限定する記載がない限り、他の構成要素を除くものではなく、他の構成要素をさらに含むことができることを意味する。
【００２３】
本発明の一実施例に係る放送伝送装置及びその方法は、地上波放送サービスのためのベースプロファイル、モバイル放送サービスのためのハンドヘルドプロファイル及び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信号対雑音比受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを用いるバッテリで駆動されるハンドヘルド装置におけるほど重要ではない。ベースプロファイルに対する重要なシステムパラメータが以下の表１に記載されている。
【００３１】
【表１】
2017511989.tif 000003
【００３２】
２．ハンドヘルドプロファイル
【００３３】
ハンドヘルドプロファイルは、バッテリ電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。該当装置は、歩行者または車両速度で移動することができる。受信機の複雑度だけでなく消費電力は、ハンドヘルドプロファイルの装置の具現のために大変重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０〜１０dBであるが、より低い室内受信を目的とした場合、０dBの以下に達するように設定することができる。
【００３４】
低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要なシステムパラメータが以下の表２に記載されている。
【００３５】
【表２】
2017511989.tif 000004
【００３６】
３．アドバンスドプロファイル
【００３７】
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。該当プロファイルは、MIMO送信及び受信を用いることを要求し、UHDTVサービスはターゲット用途であり、このために該当プロファイルが特別に設計される。向上した能力は与えられた帯域幅でサービス数の増加、例えば、多数のSDTVまたはHDTVサービスを許容することにも用いられる。
【００３８】
アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０〜３０dBである。MIMO伝送は、初期には既存の楕円分極伝送装備(elliptically-polarized transmission equipment)を使用し、後で全出力交差分極伝送(full-power cross-polarized transmission)に拡張することができる。アドバンスドプロファイルに対する重要なシステムパラメータが以下の表３に記載されている。
【００３９】
【表３】
2017511989.tif 000005
【００４０】
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービス両方に対するプロファイルとして用いられる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために使用される。また、アドバンスドプロファイルは、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)におけるロジカルチャネルである。
【００８８】
また、データパイプユニットは、１つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【００８９】
BICMブロック１０１０で、パリティ(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ストリームである場合選択的に使用される。
【０１２３】
前記ブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１２４】
図４は、インプットシグナルが複数のインプットストリームに対応するとき、入力フォーマットモジュールのストリーム適応ブロックを示す。
【０１２５】
図4に示す入力書式設定ブロックは、図1を参照して説明したブロック1000を入力フォーマットの一実施形態に相当します。
【０１２６】
図４は、インプットシグナルが複数のインプットストリームに対応するとき、入力フォーマットモジュールのストリーム適応ブロックを示す。
【０１２７】
図４に示すように、複数のインプットストリームをそれぞれ処理するためのモード適応ブロックは、スケジューラ４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンドシグナリング４０３０、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-１０２４)を利用して、ベース及びハンドヘルドプロファイルにおいてビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルにおいてセルワードデマルチプレクサ５０１０-１からのセルワードを変調して、パワーが正規化されたコンステレーションポイントｅｌを提供することができる。該当コンステレーションマッピングは、データパイプに対してのみ適用される。NUQが任意の形態を有する反面、QAM-１６及びNUQは正四角形形状を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転すれば、回転したコンステレーションは本来のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーが相互等しくなる。NUQ及びNUCはいずれも各コードレート(code rate)に対して特別に定義され、使用される特定の１つは、PLS２データに保管されたパラメータDP_MODによってシグナリングされる。
【０１４４】
SSDの符号化ブロック5040は、困難なフェージング条件の下で受信ロバスト性を高めるために、2つの（2D）のコードセル三（3D）、4（4D）の寸法を事前にすることができます。
【０１４５】
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定することができる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０１４６】
アドバンスドプロファイルに対する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から組織的にエンコーディングされ、その後に添付される。
【０１６２】
【数１】
2017511989.tif 000006
【０１６３】
PLS１及びPLS２に対するLDPCコードパラメータは、次の表４のようである。
【０１６４】
【表４】
2017511989.tif 000007
【０１６５】
LDPCパリティパンクチャリングブロックは、PLS１データ及びPLS２データに対してパンクチャリングを行うことができる。
【０１６６】
ショートニングがPLS１データ保護に適用されると、一部LDPCパリティビットはLDPCエンコーディング後パンクチャリングされる。また、PLS２データ保護のために、PLS２のLDPCパリティビットがLDPCエンコーディング後パンクチャリングされる。これらパンクチャリングされたビットは伝送されない。
【０１６７】
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャリングされたPLS１データ及びPLS２データをインターリービングすることができる。
【０１６８】
コンステレーションマッパ６０２０は、ビットインターリービングされたPLS１データ及びPLS２データをコンステレーションにマッピングすることができる。
【０１６９】
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
【０１７０】
図７は、本発明の一実施例に係るフレームビルディングブロック(frame building block)を示す。
【０１７１】
図７に図示したフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施例に該当する。
【０１７２】
図７に示すように、フレームビルディングブロックは遅延補償ブロック７０００、セルマッパ(cell mapper)７０１０、及び周波数インターリーバ(frequency interleaver)７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。
【０１７３】
遅延補償ブロック７０００は、データパイプと該当するPLSデータの間のタイミングを調節して、送信機側でデータパイプと該当するPLSデータ間の同時性(co-time)を保障することができる。インプットフォーマットブロック及び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ブロック８０７０を含むことができる。
【０１８１】
パイロットと予約トーン挿入ブロック8000は、パイロットや予約済みのトーンを挿入することができます。
【０１８２】
OFDMシンボル内の種々のセルが送信値が受信機において事前に知られているパイロットとして既知の基準情報で変調されます。パイロット・セルの情報は、分散パイロット、継続的なパイロット、エッジパイロット、FSS（フレームシグナリングシンボル）のパイロットとPES（フレームエッジシンボル）のパイロットから構成されています。各パイロットは、パイロット型パイロットパターンに応じて特定の昇圧電力レベルで送信されます。パイロット情報の値は、値の系列、任意の所与のシンボルを各送信キャリアのための1つである参照配列に由来します。パイロットは、フレーム同期、周波数同期、時間同期、チャネル推定、および送信モードの識別に使用することができ、また、位相雑音を追跡するために使用することができます。
【０１８３】
参照配列から取られた参照情報は、フレームのプリアンブル、PSS及びPESを除くすべてのシンボルに散乱パイロット・セルで送信されます。継続的なパイロットは、フレームのすべてのシンボルに挿入されます。継続的なパイロットの数及び位置は、PPTの大きさと散乱パイロットパターンの両方に依存します。エッジキャリアは、プリアンブルシンボルを除くすべてのシンボルのエッジパイロットです。これらは、スペクトルの端までの周波数補間を可能にするために挿入されています。PSSパイロットはPSS（複数可）に挿入され、PESパイロットは、PESに挿入されています。これらは、フレームのエッジまでの時間補間アップを可能にするために挿入されています。
【０１８４】
本発明の実施形態に係るシステムは、分散MISO方式は、必要に応じて、非常に強固な伝送モードをサポートするために使用されるSPNのネットワークをサポートします。2D-ESPNは、SPNネットワーク内の異なる送信機サイトに位置して、それぞれが複数のXのアンテナを使用する分散MISO方式です。
【０１８５】
2D-ESPNの符号化ブロック8010は、SPNの設定時間と周波数ダイバーシティの両方を作成するために、複数の送信機から送信された信号の位相を歪めるために2D-ESPN処理を処理することができます。したがって、低いフラットフェージングや長い時間のために、深いフェージングバーストエラーを軽減することができます。
【０１８６】
IPPTブロック8020は、OPDM変調方式を用いた2D-ESPNの符号化ブロック8010の出力を調節することができます。パイロット（または予約トーンなど）として指定されていないデータ・シンボルの任意のセルは、周波数インターリーバからのデータセルの1つ運びます。セルは、キャリアをOPDMにマップされます。
【０１８７】
PAPR低減ブロック8030は、時間領域内の様々なPのAPR低減アルゴリズムを使用して入力信号のPのAPR低減を行うことができます。
【０１８８】
ガードインターバル挿入ブロック8040は、ガードインターバルを挿入することができますし、プリアンブル挿入ブロック8050は、信号の前にプリアンブルを挿入することができます。プリアンブルの構造の詳細については後述します。他のシステムの挿入ブロック8060は、放送サービスを提供する二つ以上の異なるブロードキャスト送信/受信システムのデータが同時に同じRP信号帯域幅で送信することができ、時間領域におけるブロードキャスト送信/受信システムの複数の信号を多重化することができます。この場合、2つ以上の異なるブロードキャスト送信/受信システムは、異なるブロードキャストサービスを提供するシステムを指します。異なるブロードキャストサービスは、それぞれの放送サービスに関連するデータは、異なるフレームを介して送信することができる等の地上波放送サービス、モバイル放送サービスを意味することができます。
【０１８９】
DACブロック8070は、アナログ信号と出力アナログ信号に入力されたデジタル信号に変換することができます。DACブロック7800から出力された信号は、物理レイヤ・プロファイルに応じて複数の出力アンテナを介して送信されることができます。本発明の実施形態に係る送信アンテナは、垂直または水平の極性を有することができます。
【０１９０】
上記ブロックは省略又は設計に応じて、類似または同一の機能を有するブロックに置き換えることができます。
【０１９１】
図９は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
【０１９２】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応する。
【０１９３】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール(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：該当３ビットフィールドは、現在のフレームのフィジカルプロファイルタイプを示す。相互異なるフィジカルプロファイルタイプのマッピングは、以下の表５に示す。
【０２１２】
【表５】
2017511989.tif 000008
【０２１３】
FFT_SIZE：該当２ビットフィールドは、以下の表６で説明するように、フレームグループ内で現在のフレームのFFTサイズを示す。
【０２１４】
【表６】
2017511989.tif 000009
【０２１５】
GI_FRACTION：該当３ビットフィールドは、以下の表７で説明するように、現在のスーパーフレームにおけるガードインターバルの一部(fraction)値を示す。
【０２１６】
【表７】
2017511989.tif 000010
【０２１７】
EAC_FLAG：該当１ビットフィールドは、EACが現在のフレームに提供されるのか否かを示す。該当フィールドが１に設定されると、EASが現在のフレームに提供される。該当フィールドが０に設定されると、EASが現在のフレームに伝達されない。該当フィールドは、スーパーフレーム内でダイナミックに転換される。
【０２１８】
PILOT_MODE：該当１ビットフィールドは、現在のフレームグループで現在のフレームに対してパイロットモードがモバイルモードであるのかまたは固定モードであるのかを示す。該当フィールドが０に設定されると、モバイルパイロットモードが使用される。該当フィールドが１に設定されると、固定パイロットモードが使用される。
【０２１９】
PAPR_FLAG：該当１ビットフィールドは、現在のフレームグループで現在のフレームに対してPAPR減少が使用されているのか否かを示す。該当フィールドが１に設定されると、トーン予約(tone reservation)がPAPR減少のために使用される。該当フィールドが０に設定されると、PAPR減少が使用されない。
【０２２０】
FRU_CONFIGURE：該当３ビットフィールドは、現在のスーパーフレームで存在するFRUのフィジカルプロファイルタイプ構成を示す。現在のスーパーフレームですべてのプリアンブルにおける該当フィールドで、現在のスーパーフレームで伝達されるすべてのプロファイルタイプが識別される。該当３ビットフィールドは、以下の表８に示したように、それぞれのプロファイルに対して異なるように定義される。
【０２２１】
【表８】
2017511989.tif 000011
【０２２２】
RESERVED：該当７ビットフィールドは、将来使用のためにリザーブド(reserved)される。
【０２２３】
図１３は、本発明の一実施例に係るPLS１データを示す。
【０２２４】
PLS１データは、PLS２の受信及びデコーディングを可能とするために必要なパラメータを含んだ基本伝送パラメータを提供する。上述したように、PLS１データは、１つのフレームグループの全体デュレーションの間変化しない。PLS１データのシグナリングフィールドの具体的な定義は次のようである。
【０２２５】
PREAMBLE_DATA：該当２０ビットフィールドは、EAC_FLAGを除いたプリアンブルシグナリングデータのコピーである。
【０２２６】
NUM_FRAME_FRU：該当２ビットフィールドは、FRU当たりのフレーム数を示す。
【０２２７】
PAYLOAD_TYPE：該当３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。PAYLOAD_TYPEは、表９に示したようにシグナリングされる。
【０２２８】
【表９】
2017511989.tif 000012
【０２２９】
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コードについての詳しい内容は後述する。
【０２４３】
【表１０】
2017511989.tif 000013
【０２４４】
PLS２_MOD：該当３ビットフィールドは、PLS２によって使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
【０２４５】
【表１１】
2017511989.tif 000014
【０２４６】
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２に対して使用されない。
【０２５８】
【表１２】
2017511989.tif 000015
【０２５９】
PLS２_AP_SIZE_CELL：該当１５ビットフィールドは、PLS２の追加パリティビットのサイズ(QAMセルの数として特定される)を示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６０】
PLS２_NEXT_AP_MODE：該当２ビットフィールドは、次のフレームグループのフレームごとにPLS２シグナリングに対して追加パリティが提供されるのか否かを示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。表１２は、該当フィールドの値を定義する。
【０２６１】
PLS２_NEXT_AP_SIZE_CELL：該当１５ビットフィールドは、次のフレームグループのフレームごとにPLS２の追加パリティビットのサイズ(QAMセルの数として特定される)を示す。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６２】
RESERVED：該当３２ビットフィールドは、将来使用のためにリザーブド(reserved)される。
【０２６３】
CRC_３２：全体PLS１シグナリングに適用される３２ビットエラー検出コード。
【０２６４】
図１４は、本発明の一実施例に係るPLS２データを示す。
【０２６５】
図１４は、PLS２データのPLS２-STATデータを示す。PLS２-STATデータは、フレームグループ内で同一である反面、PLS２-DYNデータは、現在のフレームに対して特定の情報を提供する。
【０２６６】
PLS２-STATデータのフィールドについて次に具体的に説明する。
【０２６７】
FIC_FLAG：該当１ビットフィールドは、FICが現在のフレームグループで使用されているか否かを示す。該当フィールドの値が１に設定されると、FICは現在のフレームで提供される。該当フィールドの値が０に設定されると、FICは現在のフレームに伝達されない。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６８】
AUX_FLAG：該当１ビットフィールドは、補助ストリームが現在のフレームグループで使用されているのか否かを示す。該当フィールドの値が１に設定されると、補助ストリームは現在のフレームで提供される。該当フィールドの値が０に設定されると、補助フレームは現在のフレームに伝達されない。該当値は、現在のフレームグループの全体デュレーションの間一定である。
【０２６９】
NUM_DP：該当６ビットフィールドは、現在のフレーム内で伝達されるデータパイプの数を示す。該当フィールドの値は１から６４の間であり、データパイプの数はNUM_DP+１である。
【０２７０】
DP_ID：該当６ビットフィールドは、フィジカルプロファイル内で一意に識別する。
【０２７１】
DP_TYPE：該当３ビットフィールドは、データパイプのタイプを示す。これは、以下の表１３に従ってシグナリングされる。
【０２７２】
【表１３】
2017511989.tif 000016
【０２７３】
DP_GROUP_ID：該当８ビットフィールドは、現在のデータパイプが関連しているデータパイプグループを識別する。これは、受信機が同一DP_GROUP_IDを有するようになる特定サービスと関連しているサービスコンポーネントのデータパイプに接続するために使用される。
【０２７４】
BASE_DP_ID：該当６ビットフィールドは、管理階層で使用される(PSI/SIのような)サービスシグナリングデータを伝達するデータパイプを示す。BASE_DP_IDによって示すデータパイプは、サービスデータと一緒にサービスシグナリングデータを伝達するノーマルデータパイプであるか、サービスシグナリングデータだけを伝達する専用データパイプである。
【０２７５】
DP_FEC_TYPE：該当２ビットフィールドは、関連したデータパイプによって使用されるFECタイプを示す。FECタイプは、以下の表１４に従ってシグナリングされる。
【０２７６】
【表１４】
2017511989.tif 000017
【０２７７】
DP_COD：該当４ビットフィールドは、関連したデータパイプによって使用されるコードレート(code rate)を示す。コードレート(code rate)は、以下の表１５に従ってシグナリングされる。
【０２７８】
【表１５】
2017511989.tif 000018
【０２７９】
DP_MOD：該当４ビットフィールドは、関連したデータパイプによって使用される変調を示す。変調は、以下の表１６に従ってシグナリングされる。
【０２８０】
【表１６】
2017511989.tif 000019
【０２８１】
DP_SSD_FLAG：該当１ビットフィールドは、SSDモードが関連したデータパイプで使用されているか否かを示す。該当フィールドの値が１に設定されると、SSDは使用される。該当フィールドの値が０に設定されると、SSDは使用されない。
【０２８２】
次のフィールドは、PHY_PROFILEがアドバンスドプロファイルを示す０１０と同一であるときのみ現れる。
【０２８３】
DP_MIMO：該当３ビットフィールドは、どのタイプのMIMOエンコーディング処理が関連したデータパイプに適用されるのかを示す。MIMOエンコーディング処理のタイプは、以下の表１７に従ってシグナリングされる。
【０２８４】
【表１７】
2017511989.tif 000020
【０２８５】
DP_TI_TYPE：該当１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、１つのタイムインターリービンググループが１つのフレームに該当し、１つ以上のタイムインターリービングブロックを含むことを示す。１の値は、１つのタイムインターリービンググループが１つより多いフレームで伝達され、１つのタイムインターリービングブロックのみを含むことを示す。
【０２８６】
DP_TI_LENGTH：該当２ビットフィールド(許容値は１、２、４、８のみ)の使用は、次のようなDP_TI_TYPEフィールド内で設定される値によって決定される。
【０２８７】
DP_TI_TYPEの値が１に設定されると、該当フィールドは、それぞれのタイムインターリービンググループがマッピングされるフレームの数であるPIを示し、タイムインターリービンググループ当たり１つのタイムインターリービングブロックが存在する(NTI=１)。該当２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
【０２８８】
DP_TI_TYPEの値が０に設定されると、該当フィールドはタイムインターリービンググループ当たりタイムインターリービングブロックの数であるNTIを示し、フレーム当たり１つのタイムインターリービンググループが存在する(PI=１)。該当２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
【０２８９】
【表１８】
2017511989.tif 000021
【０２９０】
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は、以下の表１９に従ってシグナリングされる。
【０２９５】
【表１９】
2017511989.tif 000022
【０２９６】
DP_INBAND_MODE：該当２ビットフィールドは、現在のデータパイプがインバンド(In-band)シグナリング情報を伝達するのか否かを示す。インバンド(In-band)シグナリングタイプは、以下の表２０に従ってシグナリングされる。
【０２９７】
【表２０】
2017511989.tif 000023
【０２９８】
DP_PROTOCOL_TYPE：該当２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、以下の表２１に従ってシグナリングされる。
【０２９９】
【表２１】
2017511989.tif 000024
【０３００】
DP_CRC_MODE：該当２ビットフィールドは、CRCエンコーディングがインプットフォーマットブロックで使用されているのか否かを示す。CRCモードは、以下の表２２に従ってシグナリングされる。
【０３０１】
【表２２】
2017511989.tif 000025
【０３０２】
DNP_MODE：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるヌルパケット削除モードを示す。DNP_MODEは、以下の表２３に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、DNP_MODEは００の値に設定される。
【０３０３】
【表２３】
2017511989.tif 000026
【０３０４】
ISSY_MODE：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるISSYモードを示す。ISSY_MODEは、以下の表２４に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、ISSY_MODEは００の値に設定される。
【０３０５】
【表２４】
2017511989.tif 000027
【０３０６】
HC_MODE_TS：該当２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるTSヘッダ圧縮モードを示す。HC_MODE_TSは、以下の表２５に従ってシグナリングされる。
【０３０７】
【表２５】
2017511989.tif 000028
【０３０８】
HC_MODE_IP：該当２ビットフィールドは、DP_PAYLOAD_TYPEがIP(「０１」)に設定される場合にIPヘッダ圧縮モードを示す。HC_MODE_IPは、以下の表２６に従ってシグナリングされる。
【０３０９】
【表２６】
2017511989.tif 000029
【０３１０】
PID：該当１３ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定され、HC_MODE_TSが０１または１０に設定される場合にTSヘッダ圧縮のためのPID数を示す。
【０３１１】
RESERVED：該当８ビットフィールドは、将来使用のためにリザーブ(reserved)される。
【０３１２】
次のフィールドは、FIC_FLAGが１と同一であるときのみ現れる。
【０３１３】
FIC_VERSION：該当８ビットフィールドは、FICのバージョンナンバーを示す。
【０３１４】
FIC_LENGTH_BYTE：該当１３ビットフィールドは、FICの長さをバイト単位で示す。
【０３１５】
RESERVED：該当８ビットフィールドは、将来使用のためにリザーブ(reserved)される。
【０３１６】
次のフィールドは、AUX_FLAGが１と同一であるときのみ現れる。
【０３１７】
NUM_AUX：該当４ビットフィールドは、補助ストリームの数を示す。ゼロは補助ストリームが使用されないことを示す。
【０３１８】
AUX_CONFIG_RFU：該当８ビットフィールドは、将来使用のためにリザーブ(reserved)される。
【０３１９】
AUX_STREAM_TYPE：該当４ビットは、現在の補助ストリームのタイプを示すための将来使用のためにリザーブ(reserved)される。
【０３２０】
AUX_PRIVATE_CONFIG：該当２８ビットフィールドは、補助ストリームをシグナリングするための将来使用のためにリザーブ(reserved)される。
【０３２１】
図１５は、本発明の他の一実施例に係るPLS２データを示す。
【０３２２】
図１５は、PLS２データのPLS２-DYNを示す。PLS２-DYNデータの値は、１つのフレームグループのデュレーションの間変化できる反面、フィールドのサイズは一定である。
【０３２３】
PLS２-DYNデータのフィールドの具体的な内容は、次のようである。
【０３２４】
FRAME_INDEX：該当５ビットフィールドは、スーパーフレーム内で現在のフレームのフレームインデックスを示す。スーパーフレームの最初のフレームのインデックスは０に設定される。
【０３２５】
PLS_CHANGE_COUNTER：該当４ビットフィールドは、構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、該当フィールド内でシグナリングされる値によって示す。該当フィールドの値が００００に設定されると、これはいかなる予定された変化も予測されないことを意味する。例えば、１の値は次のスーパーフレームに変化があることを示す。
【０３２６】
FIC_CHANGE_COUNTER：該当４ビットフィールドは、構成(すなわち、FICのコンテンツ)が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは、該当フィールド内でシグナリングされる値によって示す。該当フィールドの値が００００に設定されると、これはいかなる予定された変化も予測されないことを意味する。例えば、０００１の値は次のスーパーフレームに変化があることを示す。
【０３２７】
RESERVED：該当１６ビットフィールドは、将来使用のためにリザーブド(reserved)される。
【０３２８】
次のフィールドは、現在のフレームで伝達されるデータパイプに関連したパラメータを説明するNUM_DPにおけるループ(loop)に現れる。
【０３２９】
DP_ID：該当６ビットフィールドは、フィジカルプロファイル内でデータパイプを一意に示す。
【０３３０】
DP_START：該当１５ビット(または１３ビット)フィールドは、DPUアドレッシング(addressing)技法を使用してデータパイプの最初の開始位置を示す。DP_STARTフィールドは、以下の表２７に示したように、フィジカルプロファイル及びFFTサイズに応じて異なる長さを有する。
【０３３１】
【表２７】
2017511989.tif 000030
【０３３２】
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セルの全体数を超過できない。
【０３７０】
【数２】
2017511989.tif 000031
【０３７１】
DDP１は、Type１DPによって占有されたOFDMセルの数である。DDP２はType２DPによって占有されたセルの数である。PLS、EAC、FICはすべてType１DPに応じて同じ方法でマッピングされるので、それらはすべて「Type１マッピングルール」を従って、Type１マッピングは常にType２マッピングに先行する。
【０３７２】
図２１は、本発明の一実施例に係るDPマッピングを示す。
【０３７３】
(a)はtype１DPマッピングのためのOFDMセルのアドレス指定を示し、(b)はType２DPのためのマッピングのためのOFDMセルのアドレス指定を示す。
【０３７４】
Type１DP(０、…、DDP１１)マッピングのためのOFDMセルのアドレス指定は、type１DPのアクティブデータセルのために定義される。アドレス指定スキームは、アクティブデータセルによって割り当てられたType１DPのそれぞれのためのTlsからセルの順序を定義する。また、これはPLS２の動的部分内のDPの位置をシグナルするために使用される。
【０３７５】
EAC及びFICなしに、アドレス０は最後の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にセルを割り当てるための基本単位です。
【０３８０】
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エンコーディングパラメータを示す。
【０３８６】
【表２８】
2017511989.tif 000032
【０３８７】
【表２９】
2017511989.tif 000033
【０３８８】
BCHエンコーディング及びLDPCエンコーディングの具体的な動作は次のようである。
【０３８９】
１２-エラー訂正BCHコードがBBFの外部エンコーディングに使用される。short FECBLOCK及びlong FECBLOCKに対するBBF生成多項式は、すべての多項式を乗算することで得られる。
【０３９０】
LDPCコードは、外部BCHエンコーディングの出力をエンコーディングするために使用される。完成されたBldpc(FECBLOCK)を生成するために、Pldpc(パリティビット)がそれぞれのIldpc(BCH-エンコーディングされたBBF)から組織的にエンコーディングされ、Ildpcに添付される。完成されたBldpc(FECBLOCK)は次の数式で表現される。
【０３９１】
【数３】
2017511989.tif 000034
【０３９２】
long FECBLOCK及びshort FECBLOCKに対するパラメータは、上記表２８及び２９にそれぞれ与えられる。
【０３９３】
long FECBLOCKに対してNldpc-Kldpcパリティビットを計算する具体的な手順は次のようである。
【０３９４】
１）パリティビット初期化
【０３９５】
【数４】
2017511989.tif 000035
【０３９６】
２）パリティチェックマトリックスのアドレスの最初の行で特定されたパリティビットアドレスで最初の情報ビットi０累算(accumulate)。パリティチェックマトリックスのアドレスの詳細な内容は後述する。例えば、比率１３/１５に対して、
【０３９７】
【数５】
2017511989.tif 000036
【０３９８】
３）次の３５９個の情報ビットis、s=１、２、…、３５９に対して、次の数式を利用してパリティビットアドレスでis累算(accumulate)。
【０３９９】
〔数式６〕
【数６】
2017511989.tif 000037
【０４００】
ここで、xは最初のビットi０に該当するパリティビット累算器のアドレスを示し、Qldpcはパリティチェックマトリックスのアドレスで特定されたコードレート(code rate)依存定数である。前記例である比率１３/１５に対する、従って情報ビットi１に対するQldpc=２４に引き続き、次の動作が実行される。
【０４０１】
【数７】
2017511989.tif 000038
【０４０２】
４）３６１番目情報ビットi３６０に対して、パリティビット累算器のアドレスは、パリティチェックマトリックスのアドレスの二番目行に与えられる。同一方式で、次の３５９個の情報ビットis、s=３６１、３６２、…、７１９に対するパリティビット累算器のアドレスは、数式６を利用して得られる。ここで、xは情報ビットi３６０に該当するパリティビット累算器のアドレス、すなわちパリティチェックマトリックスの二番目行のエントリーを示す。
【０４０３】
５）同一方式で、３６０個の新しい情報ビットのすべてのグループに対して、パリティチェックマトリックスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めることに使用される。
【０４０４】
すべての情報ビットが利用された後、最終パリティビットが次のように得られる。
【０４０５】
６）i=１で始まり次の動作を順次実行
【０４０６】
【数８】
2017511989.tif 000039
【０４０７】
ここで、pi、i=０、１、...Nldpc-Kldpc-１の最終コンテンツは、パリティビットpiと同一である。
【０４０８】
【表３０】
2017511989.tif 000040
【０４０９】
表３０を表３１に代替し、long FECBLOCKに対するパリティチェックマトリックスのアドレスをshort FECBLOCKに対するパリティチェックマトリックスのアドレスに代替することを除いて、short FECBLOCKに対する該当LDPCエンコーディング手順は、long FECBLOCKに対するt LDPCエンコーディング手順に従う。
【０４１０】
【表３１】
2017511989.tif 000041
【０４１１】
図２３は、本発明の一実施例に係るビットインターリービングを示す。
【０４１２】
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インターリービング後、グループ内インターリービングは、以下の表３２に定義された順序（ηｍｏｄ）及びモジュレーションタイプに応じて実行される。１つのグループ内QCブロックの数、NQCB_IGも定義される。
【０４１６】
【表３２】
2017511989.tif 000042
【０４１７】
グループ内インターリービングプロセスは、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を含むことができる。タイムインターリービンググループが多数のタイムインターリービングブロックに分離されると、タイムインターリービンググループは、１つのフレームのみに直接マッピングされる。以下の表３２に示したように、タイムインターリービングには３種類のオプションがある(タイムインターリービングを省略する追加オプション除外)。
【０４３４】
【表３３】
2017511989.tif 000043
【０４３５】
各DPでは、TIメモリは、（SSD/ MIMO符号化ブロックから出力XFECBLOCKs）入力XFECBLOCKsを格納します。入力XFECBLOCKsは次のように定義されているものとします。
【０４３６】
【数９】
2017511989.tif 000044
【０４３７】
ｄｎ，ｓ，ｒ，ｑ は、n番目のTIグループのs番目のTIブロック内r番目XFECBLOCKのq番目のセルであり、SSDの出力とMIMOエンコーディングは、次のように表現される。
【０４３８】
【数１０】
2017511989.tif 000045
【０４３９】
また、時間インターリーバからXFCEブロックとして定義される出力を仮定
【０４４０】
【数１１】
2017511989.tif 000046
【０４４１】
【数１２】
2017511989.tif 000047
【０４４２】
一般的に、タイムインターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファとしても作用する。これは、それぞれのデータパイプに対して２つのメモリバンクで達成される。最初のタイムインターリービングブロックは最初のバンクに記入される。最初のバンクで判読される間、二番目のタイムインターリービングブロックが二番目バンクに記入される。
【０４４３】
タイムインターリービングは、ツイスト行列ブロックインターリーバである。n番目のタイムインターリービンググループのs番目のタイムインターリービングブロックに対して、列の数ＮｃがＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）と同一である反面、タイムインターリービングメモリの行の数Ｎｒはセルの数Ｎｃｅｌｌｓと同一である(すなわち、Ｎｒ＝Ｎｃｅｌｌｓ)。
【０４４４】
図２６は、本発明の一実施例に係るツイスト行列ブロックインターリーバの基本動作を示す。
【０４４５】
図２６(a)はタイムインターリーバで記入動作を示し、図２６(b)はタイムインターリーバで判読動作を示す。(a)に示したように、最初のXFECBLOCKはタイムインターリービングメモリの最初の列に列方向に記入され、二番目のXFECBLOCKは次の列に記入され、このような動作が続けられる。そしてインターリービングアレイで、セルが対角線方向に判読される。(b)に示したように、最初の行から(最も左側列を始めとしえ行に沿って右側に)最後の行まで対角線方向の判読が行われる間、Ｎｒ個のセルが判読される。具体的に、ｚｎ，ｓ，ｉ（ｉ＝０，...，ＮｒＮｃ）が順次判読されるタイムインターリービングメモリセル位置であると仮定する場合、このようなインターリービングアレイでの判読動作は、以下の式のように行インデックスＲｎ，ｓ，ｉ、列インデックスＣｎ，ｓ，ｉ、関連したツイストパラメータＴｎ，ｓ，ｉを算出することで実行される。
【０４４６】
〔式９〕
【数１３】
2017511989.tif 000048
【０４４７】
ここで、ＳｓｈｉｆｔはＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく対角線方向の判読過程に対する共通シフト値であり、シフト値は、以下の数式のようにPLS2-STATから与えられたＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸによって決定される。
【０４４８】
〔数式１０〕
【数１４】
2017511989.tif 000049
【０４４９】
図２７は、本発明の他の一実施例に係るツイスト行列ブロックインターリーバの動作を示す。
【０４５０】
さらに具体的に、図３７は、ＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５であるとき、仮想XFECBLOCKを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリにおいてインターリービングアレイを示す。
【０４５１】
変数ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）＝ＮｒはＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸより小さいか同一である。従って、ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく、受信機側で単一メモリディインターリービングを達成するために、ツイスト行列ブロックインターリーバ用インターリービングアレイは、仮想XFECBLOCKをタイムインターリービングメモリに挿入することで、Ｎｒ×Ｎｃ＝Ｎcells×ＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸの大きさに設定され、判読過程は次の数式のようになされる。
【０４５２】
〔数式１１〕
【数１５】
2017511989.tif 000050
【０４５３】
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、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データでシグナリングされて、これは
【数１６】
2017511989.tif 000051
【０４５４】
図２８は、本発明の一実施例に係るツイスト行列ブロックインターリーバの対角線方向の判読パターンを示す。
【０４５５】
さらに具体的に、図２８はパラメータＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ＝７及びSshift=(７-１)/２=３を有するそれぞれのインターリービングアレイからの対角線方向の判読パターンを示す。このとき、上記擬似コードで示した判読過程で、
【数１７】
2017511989.tif 000052
【０４５６】
図２９は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされた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）及び放送サービスに関するアプリケーションのうち少なくともいずれか１つを受信することができる。
【０４８８】
連動装置２００は、ホームネットワークを介して放送受信装置１００と連動して放送サービスに関する付加機能を実行する。具体的に連動装置２００は、放送サービスに関するアプリケーション及びファイルのうち少なくともいずれか１つを獲得することができる。また、連動装置２００は、放送サービスに関するアプリケーション及びファイルを実行することができる。このとき、連動装置２００は、ホームネットワークの代わりに3GPPのような移動通信網や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 64 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に基づいてメディアコンポーネントを識別することができる。
【０５０９】
ComponentTypeは、該当メディアコンポーネントの種類を示す。具体的にComponentTypeは、１つ存在してもよい。ComponentTypeは、ストリングデータタイプを有することができる。具体的に放送受信装置１００と連動装置２００は、ComponentTypeに基づいてメディアコンポーネントの種類を表示することができる。
【０５１０】
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に基づいてメディアコンポーネントのジャンルを表示することができる。
【０５１７】
前述したように、放送受信装置１００と連動装置２００は、ホームネットワーク、3GPPのような移動通信網及び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）セッションを生成する（S2001）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。具体的に放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的に放送受信装置１００と連動装置２００は、UPnPプロトコルを利用してペアリングセッションを生成することができる。具体的な実施例において、放送受信装置１００がUPnPのディスカバリープロトコルを利用して連動装置２００を探すことができる。例えば、放送受信装置１００が周知の（well known）IPアドレスを介して、連動のための連動装置を探すというディスカバリーメッセージをマルチキャストすることができる。このとき、マルチキャストされたメッセージを受信した連動装置２００は、放送受信装置１００にディスクリプションを要求することができる。放送受信装置１００は、連動装置２００のディスクリプション要求に基づいて連動装置２００にディスクリプションを提供することができる。連動装置２００は、ディスクリプションに基づいて放送受信装置２００に接続することができる。他の具体的な実施例において、連動装置２００がUPnPのディスカバリープロトコルを利用して放送受信装置１００を探すことができる。例えば、連動装置２００は、周知の（well known）IPアドレスを介して、連動のための放送受信装置１００を探すというメッセージをマルチキャストすることができる。このとき、放送受信装置は、マルチキャストされたメッセージに基づいてディスカバリーメッセージで応答することができる。これにより、ディスカバリーメッセージを受信した連動装置２００は、放送受信装置１００にディスクリプションを要求することができる。放送受信装置１００は、連動装置２００のディスクリプション要求に基づいて、連動装置２００にディスクリプションを提供することができる。連動装置２００は、ディスクリプションに基づいて放送受信装置２００に接続することができる。
【０５２３】
連動装置２００は、放送受信装置１００に放送サービスの属性通知を要求する（S2003）。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的に連動装置２００は、UPnPプロトコルを利用して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的な実施例において連動装置２００は、イベンティングプロトコルに基づいて放送受信装置１００に放送サービスの属性に対するイベントの購読（subscription）を要求することができる。
【０５２４】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する（S2005）。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５２５】
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性を通知する（notify）（S2007）。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性を通知する。具体的に放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の状態を示す変数を介して放送サービスの属性を通知することができる。具体的な実施例において放送サービスの属性の状態を示す変数は、図３３の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）セッションを生成する（S2021）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３４の実施例と同一であってもよい。
【０５３４】
連動装置２００は、放送受信装置１００に放送サービスの属性変更通知を要求する（S2023）。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性変更通知を要求することができる。具体的な連動装置２００の動作は、図３４の実施例と同一であってもよい。
【０５３５】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する（S2025）。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５３６】
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性が変更されたか否かを通知する(notify)(S2027)。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性変更可否を通知することができる。具体的に放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性変更を通知することができる。具体的に放送受信装置１００は、放送サービスの属性をシグナリングする情報のバージョンが以前に比べて変更されたかに基づいて、放送サービスの属性変更可否を判断することができる。また、具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性が変更されたか否かを示す変数を介して放送サービスの属性が変更されたか否かを通知することができる。具体的な実施例において放送サービスの属性が変更されたか否かを示す変数は、図３３のServicePropertyChangedFlagであってもよい。このとき、放送サービスの属性が変更されたか否かを示すデータ形式については、図３８に基づいて詳しく説明する。
【０５３７】
図３８は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性が変更されたか否かのデータ形式を示す。
【０５３８】
放送サービスの属性が変更されたか否かのデータ形式は、XML形式であってもよい。但し、放送サービスの属性が変更されたか否かのデータ形式はこれに限定されるものではない。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性が変更されたか否かのみを通知することができる。図３８の実施例にように、放送受信装置１００は、連動装置２００に放送サービスの属性が変更されたか否かをTRUE値またはFALSE値を有するBoolean変数で表示することができる。例えば、放送サービスの属性が変更された場合、放送受信装置１００は連動装置２００に放送サービスの属性が変更されたか否かを示す変数がTRUE値を有するデータを伝送することができる。但し、このような実施例において連動装置２００は、放送サービスのどの属性が変更されたかわからず、放送サービスの属性のいずれかが変更されたことしかわからない。このため、連動装置２００は自身が必要としない放送サービスの属性が変更された場合でも放送サービスの属性を要求することになる。従って、このような実施例は、放送受信装置１００と連動装置２００の不必要な動作と不必要なデータ交換を誘発する可能性がある。これを解決するために放送受信装置１００は変更された放送サービスの属性を連動装置２００に通知する必要がある。これについては、図３９〜図４０に基づいて説明する。
【０５３９】
図３９は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
【０５４０】
放送サービスの属性が変更された場合、放送受信装置１００は、連動装置２００に変更された属性と放送サービスの属性が変更されたか否かを共に通知することができる。このために、放送サービスの属性が変更されたか否かを示す変数が変更されたサービスの属性を示す情報を含むことができる。このために、放送サービスの属性が変更されたか否かを示す変数は、バイナリヘキサタイプ（binary hex type）を有することができる。従って、他の変数、アクション及びアクションの引数は同一であり、図３６の実施例において放送サービスの属性が変更されたか否かを示す変数であるServicePropertyChangedFlagは、バイナリヘキサタイプ（binary hex type）からなることができる。ServicePropertyChangedFlagに対する購読（subscription）を要求する場合、放送受信装置１００は、ServicePropertyChangedFlagを連動装置に伝送することができる。放送受信装置１００が連動装置２００にシグナリングする放送サービスの属性が変更されたか否かのデータ形式については、図４０に基づいて説明する。
【０５４１】
図４０は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性が変更されたか否かのデータ形式を示す。
【０５４２】
放送サービスの属性が変更されたか否かのデータは、XML形式であってもよい。但し、放送サービスの属性が変更されたか否かのデータ形式はこれに限定されるものではない。放送受信装置１００は、放送サービスの属性のそれぞれに対して特定のビットを割り当てて、放送サービスの属性が変更された場合、該当ビットを１に表示することができる。図４０の実施例において１６進数90080004は、２進数1001000000001000000000000100である。このとき、最初の４桁のビットがそれぞれ放送サービスの主言語、ジャンル、勧告グレード及びターゲティング属性をそれぞれ示すといえる。この場合、連動装置２００は、放送サービスの主言語及びターゲティング属性が変更されたことがわかる。
【０５４３】
図３７に戻って、本発明の他の実施例により放送受信装置１００が連動装置２００に放送サービスの属性をシグナリングすることを説明する。
【０５４４】
連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求する(S2029)。放送サービスの特定属性は、放送サービスの属性をシグナリングする情報に含まれた放送サービスの属性のうちいずれか１つまたは複数の属性からなることができる。連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性を要求することができる。具体的に、放送受信装置１００が放送サービスの属性変更通知を伝送した場合、連動装置２００は放送受信装置１００に放送サービスの特定属性を要求することができる。このとき、放送サービスの特定属性は、連動装置２００が放送サービスに関する付加サービスを提供するために必要な放送サービスの属性であってもよい。また、図４１〜図４２のように、放送受信装置１００が放送サービスの属性のうち変更された部分をシグナリングした場合、連動装置１００は変更された放送サービスの属性の種類に基づいて放送サービスの特定属性を要求することができる。具体的に連動装置２００は、放送サービスの特定属性が変更された場合、放送サービスの特定属性を要求することができる。放送サービスの特定属性は、連動装置２００が放送サービスに関する付加サービスを提供するために必要な属性であってもよい。例えば、連動装置２００が放送サービスのターゲティング属性に基づいて放送サービスの再生可能か否かを決定する場合、連動装置２００は放送サービスのターゲティング属性が変更された場合に放送サービスのターゲティング属性を要求することができる。
【０５４５】
放送受信装置１００は、連動装置２００に放送サービスの特定属性を通知する（S2031）。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの特定属性を通知することができる。具体的に放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの特定属性を通知することができる。例えば、放送受信装置１００は、連動装置２００に連動装置２００が要求した放送サービスの特定属性を伝送することができる。
【０５４６】
但し、このような実施例は、放送受信装置１００と連動装置２００との間の持続的な通信を必要とすることがある。特に、放送受信装置１００が複数の連動装置２００と連動する場合、持続的な通信は放送受信装置１００の動作の過負荷を誘発する可能性がある。連動装置１００が放送サービスの属性をコンテンツ/シグナリングサーバ４００から受信するようにする場合、このような問題を解決することができる。これについては、図４１〜図４２に基づいて説明する。
【０５４７】
図４１は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
【０５４８】
放送サービスの属性が変更された場合、放送受信装置１００は連動装置２００に放送サービスの属性が変更されたか否かと放送サービスの属性を受信することができるURLアドレスを共に通知することができる。このために、放送受信装置１００が連動装置２００にシグナリングする放送サービスの属性の状態を示す変数は、放送サービスの属性を受信することができるURLアドレスを示す情報を含むことができる。具体的な実施例においてシグナリングする放送サービスの属性の状態を示す変数は、放送サービスの属性を受信することができるURLアドレスを示すServicePropertyChangeFlagを含むことができる。具体的な実施例においてServicePropertyChangeFlagは選択変数であり、ストリングデータタイプを有することができる。具体的な放送受信装置１００と連動装置２００の動作については、図４２に基づいて説明する。
【０５４９】
図４２は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【０５５０】
放送受信装置１００と連動装置２００は、ペアリング（pairing）セッションを生成する（S2041）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３７の実施例と同一であってもよい。
【０５５１】
連動装置２００は、放送受信装置１００に放送サービスの属性変更通知を要求する（S2043）。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的な連動装置２００の動作は、図３７の実施例と同一であってもよい。
【０５５２】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する（S2045）。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５５３】
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性が変更されたか否か及び放送サービスの属性を獲得できるURLを通知する（notify）（S2047）。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性が変更されたか否か及び放送サービスの属性を獲得できるURLを通知することができる。具体的に放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。具体的に放送受信装置１００は、放送サービスの属性をシグナリングする情報のバージョンが以前に比べて変更されたかに基づいて放送サービスの属性が変更されたか否かを判断することができる。また、放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性変更及び放送サービスの属性を獲得できるURLを通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性が変更されたか否かを示す変数を介して放送サービスの属性が変更されたか否かを通知することができる。具体的な実施例において放送サービスの属性が変更されたか否かを示す変数は、図４１のServicePropertyChangeFlagであってもよい。また、放送受信装置１００は、連動装置２００に放送サービスの属性を獲得できるURLを示す変数を介して放送サービスの属性が変更されたか否かを通知することができる。具体的な実施例において放送サービスの属性を獲得できるURLを示す変数は、図４１のServicePropertyURLであってもよい。
【０５５４】
連動装置２００は、放送サービスの属性を獲得できるURLに基づいて放送サービスの属性を獲得する（S2049）。具体的に連動装置２００は、制御部を介して放送サービスの属性を獲得できるURLに基づいて放送サービスの属性を獲得することができる。具体的に連動装置２００は、放送サービスの属性を獲得できるURLに基づいてコンテンツ/シグナリングサーバ４００から放送サービスの属性を獲得することができる。具体的に連動装置２００は、放送サービスの属性を獲得できるURLに基づいて放送サービスの属性をコンテンツ/シグナリングサーバに要求し、コンテンツ/シグナリングサーバ４００から放送サービスの属性を獲得することができる。これにより、放送受信装置１００と連動装置２００との間の通信から発生しうる放送通信装置１００の負荷を軽減することができる。但し、このような実施例において放送受信装置１００は、連動装置２００が必要としない放送サービスの属性が変更される場合でも放送サービスの属性変更を通知しなければならない。従って、放送受信装置１００は不必要な動作を行う問題がある。連動装置２００が放送受信装置１００に通知変更を要求するときに必要な放送サービスの属性を予め設定する場合、放送受信装置１００の不必要な動作を減らすことができる。これについては、図４３〜図４４に基づいて説明する。
【０５５５】
図４３は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数、放送サービスの属性のためのアクション及びアクションの引数（argument）を示す。
【０５５６】
連動装置２００が放送受信装置１００に放送サービスの属性変更通知を要求するとともに通知を受けることを希望する放送サービスの属性を指定することができる。このために、連動装置２００は、通知を受けることを希望する放送サービスの属性を指定するアクションを含むことができる。このとき、アクションは、通知を受けることを希望する放送サービスの属性を示す変数を入力引数として有することができる。このようなアクションは、図４３の実施例のSetServicePropertyであってもよい。具体的な実施例においてSetServicePropertyは必須アクションであってもよい。また、SetServicePropertyは、放送サービスの属性の種類を示すServicePropertyNameを入力引数（argument）として有することができる。放送受信装置１００と連動装置２００の具体的な動作は、図４４に基づいて説明する。
【０５５７】
図４４は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
【０５５８】
放送受信装置１００と連動装置２００は、ペアリング（pairing）セッションを生成する（S2061）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図４２の実施例と同一であってもよい。
【０５５９】
連動装置２００は、放送受信装置１００に放送サービスの特定属性変更通知を要求する（S2063）。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性変更通知を要求することができる。連動装置２００は、放送サービスに関する付加情報を提供するために必要な放送サービスの特定属性の変更通知のみを要求することができる。具体的な実施例において連動装置２００は、特定属性の変更通知のみを要求するためのアクションを介して放送サービスの特定属性変更通知を要求することができる。このとき、特定属性の変更通知のみを要求するためのアクションは、図４３で説明したSetServicePropertyであってもよい。連動装置２００が放送受信装置１００に放送サービスの特定属性変更通知を要求する動作は、次のような動作を含むことができる。連動装置２００は、放送受信装置１００にサービスの属性に関する変更通知購読（subscription）を要求することができる。放送受信装置１００は、サービスの属性に関する変更通知購読（subscription）要求を受諾する場合、連動装置２００に受諾メッセージと購読要求を識別する購読識別子（Subscription ID、SID）を共に伝送することができる。連動装置２００は、放送受信装置１００にSIDに基づいて放送サービスの特定属性の変更通知のみを要求することができる。具体的に、連動装置２００はSIDとと共に変更可否の通知を受けようとする放送サービスの特定属性を伝送することができる。また、連動装置２００は、放送受信装置１００に放送サービスの複数の特定属性の変更に対して通知を要求することができる。このとき、連動装置２００は、放送サービスの複数の特定属性をリスト形式で要求することができる。
【０５６０】
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する（S2065）。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
【０５６１】
放送受信装置１００は、放送サービスの特定属性が変更されたか否かを確認する（S2067）。具体的に放送受信装置１００は、制御部１５０を介して放送サービスの特定属性が変更されたか否かを確認することができる。具体的に放送受信装置１００は、放送サービスの特定属性が以前に比べて変更されたかを判断することができる。具体的に放送受信装置１００は、放送サービスの特定属性の以前値と現在値を比較して、放送サービスの特定属性が変更されたか否かを判断することができる。
【０５６２】
放送サービスの特定属性が変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの特定属性が変更されたか否かを通知する（notify）（S2069）。具体的に放送サービスの特定属性が変更された場合、放送受信装置１００は制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの特定属性が変更されたか否かを通知するすることができる。
【０５６３】
連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求する（S2071）。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性を要求することができる。具体的に放送受信装置１００が放送サービスの特定属性変更通知を伝送した場合、連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求することができる。具体的な連動装置２００の動作は、図３７の実施例と同一であってもよい。
【０５６４】
放送受信装置１００は、連動装置２００に放送サービスの特定属性を通知する（S2073）。放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの特定属性を通知ことができる。具体的に放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの特定属性を通知することができる。例えば、放送受信装置１００は、連動装置２００に連動装置２００が要求した放送サービスの特定属性を伝送することができる。
【０５６５】
また、連動装置２００は、放送受信装置１００から放送サービスの特定属性を獲得するものではなく、図４２で説明したように、放送サービスの属性を獲得できる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）セッションを生成する（S2101）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３４の実施例と同一であってもよい。
【０５８１】
連動装置２００は、放送受信装置１００に緊急警報受信通知を要求する（S2103）。具体的に連動装置２００は、制御部を介して放送受信装置１００に緊急警報受信通知を要求することができる。具体的に連動装置２００は、UPnPプロトコルを利用して、放送受信装置１００に緊急警報受信通知を要求することができる。具体的な実施例において連動装置２００は、イベンティングプロトコルに基づいて放送受信装置１００に緊急警報受信通知に対するイベントの購読（subscription）を要求することができる。
【０５８２】
放送受信装置１００は、放送伝送装置３００から緊急警報を含むメッセージを受信する（S2105）。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から緊急警報メッセージを受信することができる。
【０５８３】
放送受信装置１００は、連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報を通知する(notify)(S2107)。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に緊急警報メッセージに関する情報を示す変数を介して緊急警報メッセージに関する情報を通知することができる。具体的な実施例において緊急警報メッセージに関する情報を示す変数は、図４９のEmergencyAlertであってもよい。
【０５８４】
連動装置２００は、放送受信装置１００に緊急警報に関する情報を要求する(S2109)。具体的に連動装置２００は、制御部を介して放送受信装置１００に緊急警報を要求することができる。具体的な実施例において連動装置２００は、緊急警報を要求するアクションを介して緊急警報を要求することができる。具体的な実施例において緊急警報を要求するアクションは、図４９のGetEmergencyAlertMessageであってもよい。
【０５８５】
放送受信装置１００は、連動装置２００に緊急警報メッセージをすべて含む緊急警報に関する情報を通知する（S2111）。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に緊急警報メッセージをすべて含む緊急警報に関する情報を通知することができる。但し、このような場合、緊急警報メッセージをすべて受信しなければならないので、放送受信装置１００と連動装置２００の動作に負荷として作用する可能性がある。従って、連動装置２００に緊急警報メッセージを効率的に伝送する方法が必要である。
【０５８６】
放送受信装置１００は、緊急警報メッセージから連動装置２００に必要な情報を抽出して伝送することができる。具体的な実施例において放送受信装置１００は、緊急警報メッセージから緊急警報を識別する識別子、緊急警報のカテゴリーを示す情報、緊急警報に関する説明を示す情報、緊急警報に該当する地域を示す情報、緊急警報の緊急度を示す情報、緊急警報を誘発した災害の深刻性を示す情報及び緊急警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを抽出することができる。具体的な実施例において放送受信装置１００は、緊急警報メッセージから緊急警報を識別するエレメントである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）セッションを生成する（S2121）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５０の実施例と同一であってもよい。
【０５９８】
連動装置２００は、放送受信装置１００に緊急警報受信通知を要求する（S2123）。具体的に連動装置２００は、制御部を介して放送受信装置１００に緊急警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５０の実施例と同一であってもよい。
【０５９９】
放送受信装置１００は、放送サービスに基づいて緊急警報を含む緊急警報メッセージを受信する(S2125)。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から緊急警報を含む緊急警報メッセージを受信することができる。
【０６００】
放送受信装置１００は、連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報を通知する(notify)(S2127)。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報を通知することができる。また、具体的な実施例において放送受信装置１００は、連動装置２００に緊急警報メッセージに関する情報を示す変数を介して緊急警報メッセージ情報を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に緊急警報メッセージに関する情報を示す変数を介して緊急警報メッセージに関する情報を通知することができる。具体的な実施例において緊急警報メッセージを示す変数は、図４９のEmergencyAlertであってもよい。
【０６０１】
連動装置２００は、放送受信装置１００に緊急警報に関する特定情報を要求する（S2129）。連動装置２００は、制御部を介して放送受信装置１００に緊急警報に関する特定情報を要求することができる。このとき、緊急警報に関する特定情報は、連動装置２００が緊急警報に関する付加機能を提供するために必要な緊急警報に関する情報からなることができる。具体的な実施例において連動装置２００は、放送受信装置１００に緊急警報メッセージから緊急警報を識別する識別子、緊急警報のカテゴリーを示す情報、緊急警報に関する説明を示す情報、緊急警報に該当する地域を示す情報、緊急警報の緊急度を示す情報、緊急警報を誘発した災害の深刻性を示す情報及び緊急警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを要求することができる。例えば、連動装置２００は、放送受信装置１００に緊急警報メッセージから緊急警報を識別するエレメントであるidentifier、緊急警報のカテゴリーを示すエレメントであるcategory、緊急警報に関する説明を示すエレメントであるdescription、緊急警報に該当する地域を示すエレメントであるareaDesc、緊急警報の緊急度を示すエレメントであるurgency、緊急警報を誘発した災害の深刻性を示すエレメントであるseverity及び緊急警報を誘発した災害の発生確率を示すエレメントであるcertainityのうち少なくともいずれか１つを要求することができる。具体的な実施例において連動装置２００は、放送受信装置１００に図５４のGetEmergencyAlertMessageアクションとEmergencyAlertFieldを利用して、緊急警報に関する特定情報を要求することができる。
【０６０２】
放送受信装置１００は、緊急警報メッセージに基づいて緊急警報に関する特定情報を抽出する(S2131)。具体的に放送受信装置１００は、制御部１５０を介して緊急警報メッセージに基づいて緊急警報に関する特定情報を抽出することができる。具体的に放送受信装置１００は、制御部１５０を介して緊急警報メッセージから緊急警報に関する特定情報を抽出することができる。
【０６０３】
放送受信装置１００は、連動装置２００に緊急警報に関する特定属性を通知する(S2133)。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に緊急警報に関する特定属性を通知することができる。具体的に放送受信装置１００は、連動装置２００の要求に基づいて緊急警報に関する特定属性を通知することができる。
【０６０４】
但し、放送受信装置１００が複数の連動装置２００と連動する場合、放送受信装置１００が、連動装置２００が必要とする緊急警報に関する特定情報を直接伝送することは放送受信装置１００の動作に過負荷を誘発する可能性がある。従って、放送受信装置１００の負荷を軽減させることができる連動装置２００に対する緊急警報シグナリング方法が必要である。これについては、図５６に基づいて説明する。
【０６０５】
図５６は、本発明の他の実施例により放送受信装置が連動装置に緊急警報をシグナリングする動作を示すラダーダイアグラムである。
【０６０６】
放送受信装置１００と連動装置２００は、ペアリング（pairing）セッションを生成する（S2141）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５５の実施例と同一であってもよい。
【０６０７】
連動装置２００は、放送受信装置１００に緊急警報受信通知を要求する（S2143）。具体的に連動装置２００は、制御部を介して放送受信装置１００に緊急警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５５の実施例と同一であってもよい。
【０６０８】
放送受信装置１００は、放送サービスに基づいて緊急警報を含む緊急警報メッセージを受信する(S2145)。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から緊急警報を含む緊急警報メッセージを受信することができる。
【０６０９】
放送受信装置１００は、連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報及び緊急警報に関する情報を獲得できるURLを通知する（notify）（S2147）。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報及び緊急警報に関する情報を獲得できるURLを通知することができる。
【０６１０】
連動装置２００は、緊急警報に関する情報を獲得できるURLに基づいて緊急警報に関する情報を獲得する（S2149）。具体的に連動装置２００は、制御部を介して緊急警報に関する情報を獲得できるURLに基づいて緊急警報に関する情報を獲得することができる。具体的に連動装置２００は、緊急警報に関する情報を獲得できるURLに基づいてコンテンツ/シグナリングサーバ４００から緊急警報に関する情報を獲得することができる。具体的に連動装置２００は、緊急警報に関する情報を獲得できるURLに基づいて緊急警報に関する情報をコンテンツ/シグナリングサーバに要求し、コンテンツ/シグナリングサーバ４００から緊急警報に関する情報を獲得することができる。これにより、放送受信装置１００と連動装置２００との間の通信から発生しうる放送通信装置１００の負荷を軽減することができる。
【０６１１】
放送受信装置１００が連動装置２００に緊急警報を表示できるユーザインターフェース（User Interface、UI）を伝送する場合、連動装置２００の緊急警報を処理するための負荷を軽減することができる。これについては、図５７に基づいて説明する。
【０６１２】
図５７は、本発明の他の実施例により放送受信装置が連動装置に緊急警報をシグナリングする動作を示すラダーダイアグラムである。
【０６１３】
放送受信装置１００と連動装置２００は、ペアリング（pairing）セッションを生成する（S2161）。具体的に放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５６の実施例と同一であってもよい。
【０６１４】
連動装置２００は、放送受信装置１００に緊急警報受信通知を要求する(S2163)。具体的に連動装置２００は、制御部を介して放送受信装置１００に緊急警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５６の実施例と同一であってもよい。
【０６１５】
放送受信装置１００は、放送サービスに基づいて緊急警報を含む緊急警報メッセージを受信する(S2165)。具体的に放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から緊急警報を含む緊急警報メッセージを受信することができる。
【０６１６】
放送受信装置１００は、連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報及び緊急警報に関するUI情報を通知する（notify）（S2167）。具体的に放送受信装置１００は、制御部１５０を介して連動装置２００に緊急警報メッセージに基づいて緊急警報メッセージに関する情報及び緊急警報に関するUI情報を通知することができる。このとき、緊急警報に関するUI情報は、緊急警報に関するUIのリストを含むことができる。
【０６１７】
連動装置２００は、放送受信装置１００に緊急警報に関するUI情報に基づいて緊急警報に関するUIを要求する(S2169)。具体的に連動装置２００は、制御部を介して放送受信装置１００に緊急警報に関するUI情報に基づいて緊急警報に関するUIを要求することができる。
【０６１８】
放送受信装置１００は、連動装置２００の要求に基づいて連動装置２００に緊急警報に関するUIを獲得できるURIを伝送する（S2171）。放送受信装置１００は、制御部１５０を介して連動装置２００の要求に基づいて連動装置２００に緊急警報に関するUIを獲得できるURIを伝送することができる。
【０６１９】
連動装置２００は、緊急警報に関するUIを獲得できるURIに基づいて緊急警報に関するUIを表示する（S2173）。連動装置２００は、制御部を介して緊急警報に関するUIを獲得できるURIに基づいて緊急警報に関するUIを表示することができる。具体的に連動装置２００は、緊急警報に関するUIを獲得できるURIに基づいてUIを獲得することができる。このとき、連動装置２００は、外部のサーバから緊急警報に関するUIを獲得することができる。例えば、連動装置２００は、緊急警報に関するUIのための画像ファイル、HTMLファイル及びXMLファイルのうち少なくともいずれか１つを外部のサーバから受信することができる。このとき、外部のサーバは、コンテンツ/シグナリングサーバ４００であってもよい。他の具体的な実施例において連動装置２００は、緊急警報に関するUIを予め格納し、格納したUIのうちURIに該当するUIを呼び出すことができる。また、連動装置２００は、このような動作により獲得した緊急警報に関するUIを表示することができる。このような動作により、連動装置２００が緊急警報を処理するので、発生する連動装置２００の負荷を軽減することができる。
【０６２０】
以上、実施例に説明された特徴、構造、効果などは、本発明の少なくとも１つの実施例に含まれ、必ずしも１つの実施例のみに限定されるものではない。ひいては、各実施例で例示された特徴、構造、効果などは、実施例が属する分野の通常の知識を有する者により他の実施例に対しても組合または変形されて実施可能である。従って、このような組合と変形に係る内容は本発明の範囲に含まれるものと解釈されるべきである。
【０６２１】
以上、本発明を実施例を中心に説明したが、これは単なる例示であり、本発明を限定するものではなく、本発明が属する分野の通常の知識を有した者であれば、本実施例の本質的な特性を逸脱しない範囲内で、以上に例示されていない変形と応用が可能である。例えば、実施例に具体的に提示された各構成要素は変形して実施することができ、そのような変形と応用に係る差異点は、添付された特許請求の範囲で規定する本発明の範囲に含まれると解釈されるべきである。
【図１】
2017511989.tif 000053
【図２】
2017511989.tif 000054
【図３】
2017511989.tif 000055
【図４】
2017511989.tif 000056
【図５（ａ）】
2017511989.tif 000057
【図５（ｂ）】
2017511989.tif 000058
【図６】
2017511989.tif 000059
【図７】
2017511989.tif 000060
【図８】
2017511989.tif 000061
【図９】
2017511989.tif 000062
【図１０】
2017511989.tif 000063
【図１１】
2017511989.tif 000064
【図１２】
2017511989.tif 000065
【図１３】
2017511989.tif 000066
【図１４】
2017511989.tif 000067
【図１５】
2017511989.tif 000068
【図１６】
2017511989.tif 000069
【図１７】
2017511989.tif 000070
【図１８】
2017511989.tif 000071
【図１９（ａ）】
2017511989.tif 000072
【図１９（ｂ）】
2017511989.tif 000073
【図２０（ａ）】
2017511989.tif 000074
【図２０（ｂ）】
2017511989.tif 000075
【図２１（ａ）】
2017511989.tif 000076
【図２１（ｂ）】
2017511989.tif 000077
【図２２】
2017511989.tif 000078
【図２３】
2017511989.tif 000079
【図２４（ａ）】
2017511989.tif 000080
【図２４（ｂ）】
2017511989.tif 000081
【図２５（ａ）】
2017511989.tif 000082
【図２５（ｂ）】
2017511989.tif 000083
【図２５（ｃ）】
2017511989.tif 000084
【図２６】
2017511989.tif 000085
【図２７】
2017511989.tif 000086
【図２８】
2017511989.tif 000087
【図２９】
2017511989.tif 000088
【図３０】
2017511989.tif 000089
【図３１】
2017511989.tif 000090
【図３２】
2017511989.tif 000091
【図３３】
2017511989.tif 000092
【図３４】
2017511989.tif 000093
【図３５】
2017511989.tif 000094
【図３６（ａ）】
2017511989.tif 000095
【図３６（ｂ）】
2017511989.tif 000096
【図３６（ｃ）】
2017511989.tif 000097
【図３７】
2017511989.tif 000098
【図３８】
2017511989.tif 000099
【図３９】
2017511989.tif 000100
【図４０】
2017511989.tif 000101
【図４１】
2017511989.tif 000102
【図４２】
2017511989.tif 000103
【図４３（ａ）】
2017511989.tif 000104
【図４３（ｂ）】
2017511989.tif 000105
【図４３（ｃ）】
2017511989.tif 000106
【図４３（ｄ）】
2017511989.tif 000107
【図４４】
2017511989.tif 000108
【図４５】
2017511989.tif 000109
【図４６】
2017511989.tif 000110
【図４７】
2017511989.tif 000111
【図４８（ａ）】
2017511989.tif 000112
【図４８（ｂ）】
2017511989.tif 000113
【図４８（ｃ）】
2017511989.tif 000114
【図４９】
2017511989.tif 000115
【図５０】
2017511989.tif 000116
【図５１】
2017511989.tif 000117
【図５２】
2017511989.tif 000118
【図５３】
2017511989.tif 000119
【図５４（ａ）】
2017511989.tif 000120
【図５４（ｂ）】
2017511989.tif 000121
【図５４（ｃ）】
2017511989.tif 000122
【図５５】
2017511989.tif 000123
【図５６】
2017511989.tif 000124
【図５７】
2017511989.tif 000125
【手続補正書】
【提出日】平成28年7月1日(2016.7.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
連動装置（ＣＤ）と連動する放送サービスを受信する主装置（ＰＤ）において、
前記連動装置からディスカバリ要求を受信し、前記連動装置にディスカバリ応答を送信し、前記連動装置からディスクリプション要求を受信し、前記連動装置にディスクリプション応答を送信するように構成されるＩＰ通信部であって、前記ディスクリプション応答は前記主装置と前記連動装置を接続するために利用される、ＩＰ通信部と、
災害状況に対して警報する緊急警報を含む緊急警報メッセージ（ＥＡＭ）を受信するように構成された放送通信部と、
前記連動装置から前記緊急警報メッセージを受信し、前記連動装置に前記緊急警報メッセージを送信するように構成された制御部と、
を含み、
前記送信された緊急警報メッセージは前記連想装置によりレンダリングするために利用される、主装置。
【請求項２】
前記送信した緊急警報メッセージは、前記緊急警報をサポートする追加データを取得するためのＵＲＬを含む、請求項１に記載の主装置。
【請求項３】
前記制御部は、
前記緊急警報に関する複数の情報の中で前記連動装置が指定した情報を前記緊急警報メッセージから抽出し、前記連動装置に前記抽出した情報を送信する、請求項１に記載の主装置。
【請求項４】
前記緊急警報メッセージは、
前記緊急警報を識別する識別子、前記緊急警報のカテゴリーを示す情報、前記緊急警報に関する説明を示す情報、前記緊急警報に該当する地域を示す情報、前記緊急警報の緊急度を示す情報、前記緊急警報を誘発した災害の深刻性を示す情報及び前記緊急警報を誘発した災害の発生確率を示す情報のうち少なくとも１つを含む、請求項１に記載の主装置。
【請求項５】
前記放送通信部は、
サービスプロバイダから前記放送サービスについて情報を受信し、
前記制御部は、
前記放送サービスについての情報を連動装置に送信する、請求項１に記載の主装置。
【請求項６】
前記制御部は、
前記連動装置に前記放送サービスを取得するためのＵＲＬを送信する、請求項５に記載の主装置。
【請求項７】
前記制御部は、
前記放送サービスについての情報から前記放送サービスの複数のエレメントのうち前記連動装置が指定した要素の要求を受信し、前記連動装置に前記放送サービスの複数のエレメントのうち前記連動装置が指定したエレメントを送信する、請求項５に記載の主装置。
【請求項８】
前記放送サービスについての情報は、
放送サービスを提供する装置の情報を示すターゲティングエレメントを含む、請求項５に記載の主装置。
【請求項９】
連動装置（ＣＤ）と連動する放送サービスを受信する主装置（ＰＤ）の動作方法であって、
前記連動装置からディスカバリ要求を受信するステップと、
ディスカバリ応答を前記連動装置に送信するステップと、
前記連動装置からディスクリプション要求を受信するステップと、
ディスクリプション応答を送信するステップであって、前記ディスクリプション応答は前記主装置と前記連動装置の接続に利用される、ステップと、
災害状況を警報する緊急警報を含む緊急警報メッセージ（ＥＡＭ）を受信するステップと、
前記連動装置から前記緊急警報メッセージ要求を受信するステップと、
前記連動装置に前記緊急警報メッセージを送信するステップと、
を含み、
前記送信した緊急警報メッセージは前記連動装置によりレンダリングに利用される、動作方法。
【請求項１０】
前記送信された緊急警報メッセージは前記緊急警報を支援する追加データを取得するためのＵＲＬを含む、請求項９に記載の動作方法。
【請求項１１】
前記緊急警報に関する複数の情報のうち前記連動装置が指定した情報を前記緊急警報メッセージから抽出し、前記抽出した情報を前記連動装置に送信するステップをさらに含む、請求項９に記載の動作方法。
【請求項１２】
前記緊急警報メッセージは、
前記緊急警報を識別する識別子、前記緊急警報のカテゴリーを示す情報、前記緊急警報に関する説明を示す情報、前記緊急警報に該当する地域を示す情報、前記緊急警報の緊急度を示す情報、前記緊急警報を誘発した災害の深刻性を示す情報及び前記緊急警報を誘発した災害の発生確率を示す情報のうち少なくとも１つを含む、請求項９に記載の動作方法。
【請求項１３】
前記放送サービスについての情報を受信するステップと、
前記放送サービスについての情報を送信するステップを含む、請求項９に記載の動作方法。
【請求項１４】
前記連動装置に前記放送サービスを取得するためのＵＲＬを送信するステップをさらに含む、請求項１３に記載の動作方法。
【請求項１５】
前記放送サービスについての情報から前記放送サービスの複数のエレメントの中の前記連動装置が示すエレメントのための要求を受信し、
前記放送サービスの複数のエレメントの中の前記連動装置が示す前記エレメントを前記連動装置へ送信するステップを更に含む、請求項１３に記載の動作方法。
【国際調査報告】
2017511989.tif 000126
2017511989.tif 000127
2017511989.tif 000128