JP2017514331A - 放送受信装置、放送受信装置の動作方法、放送受信装置及び放送受信装置の動作方法 - Google Patents
放送受信装置、放送受信装置の動作方法、放送受信装置及び放送受信装置の動作方法 Download PDFInfo
- Publication number
- JP2017514331A JP2017514331A JP2016553455A JP2016553455A JP2017514331A JP 2017514331 A JP2017514331 A JP 2017514331A JP 2016553455 A JP2016553455 A JP 2016553455A JP 2016553455 A JP2016553455 A JP 2016553455A JP 2017514331 A JP2017514331 A JP 2017514331A
- Authority
- JP
- Japan
- Prior art keywords
- broadcast
- information
- disaster
- broadcast receiving
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 114
- 238000011017 operating method Methods 0.000 title description 5
- 230000005540 biological transmission Effects 0.000 claims abstract description 325
- 230000011664 signaling Effects 0.000 claims description 226
- 230000001960 triggered effect Effects 0.000 claims description 36
- 230000004913 activation Effects 0.000 claims description 5
- 230000009849 deactivation Effects 0.000 claims description 4
- 230000003213 activating effect Effects 0.000 claims description 2
- 210000004027 cell Anatomy 0.000 description 140
- 108091006146 Channels Proteins 0.000 description 111
- 101000596046 Homo sapiens Plastin-2 Proteins 0.000 description 76
- 102100035182 Plastin-2 Human genes 0.000 description 76
- 238000001514 detection method Methods 0.000 description 46
- 238000004891 communication Methods 0.000 description 45
- 230000006854 communication Effects 0.000 description 45
- 230000009471 action Effects 0.000 description 41
- 238000013507 mapping Methods 0.000 description 41
- 230000008859 change Effects 0.000 description 40
- 230000008569 process Effects 0.000 description 36
- 239000012092 media component Substances 0.000 description 32
- 101000596041 Homo sapiens Plastin-1 Proteins 0.000 description 29
- 102100035181 Plastin-1 Human genes 0.000 description 29
- 239000000284 extract Substances 0.000 description 29
- 230000006870 function Effects 0.000 description 27
- 238000003780 insertion Methods 0.000 description 22
- 230000037431 insertion Effects 0.000 description 22
- 238000012545 processing Methods 0.000 description 19
- 230000008685 targeting Effects 0.000 description 19
- 238000010586 diagram Methods 0.000 description 18
- 239000011159 matrix material Substances 0.000 description 15
- 239000004065 semiconductor Substances 0.000 description 15
- 230000006978 adaptation Effects 0.000 description 13
- 230000006835 compression Effects 0.000 description 9
- 238000007906 compression Methods 0.000 description 9
- 230000003068 static effect Effects 0.000 description 9
- 230000007175 bidirectional communication Effects 0.000 description 8
- 230000001174 ascending effect Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 7
- 230000009467 reduction Effects 0.000 description 7
- 230000002829 reductive effect Effects 0.000 description 7
- 239000000969 carrier Substances 0.000 description 6
- 230000036961 partial effect Effects 0.000 description 6
- 230000008054 signal transmission Effects 0.000 description 6
- 238000012217 deletion Methods 0.000 description 4
- 230000037430 deletion Effects 0.000 description 4
- 238000005562 fading Methods 0.000 description 4
- 230000005484 gravity Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 102100026808 Mitochondrial import inner membrane translocase subunit Tim8 A Human genes 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000001824 photoionisation detection Methods 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 238000001235 constant-final-state spectroscopy Methods 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000004904 shortening Methods 0.000 description 2
- 101100031652 Arabidopsis thaliana PTM gene Proteins 0.000 description 1
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 101000853064 Homo sapiens Mitochondrial import inner membrane translocase subunit Tim8 B Proteins 0.000 description 1
- 102100036655 Mitochondrial import inner membrane translocase subunit Tim8 B Human genes 0.000 description 1
- 101100481512 Mus musculus Timm8a1 gene Proteins 0.000 description 1
- 101100277345 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) DDP1 gene Proteins 0.000 description 1
- 101150064104 TIMM8A gene Proteins 0.000 description 1
- 102100021131 Zinc finger and BTB domain-containing protein 22 Human genes 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 210000003317 double-positive, alpha-beta immature T lymphocyte Anatomy 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000013213 extrapolation Methods 0.000 description 1
- 230000009474 immediate action Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000006798 recombination Effects 0.000 description 1
- 238000005215 recombination Methods 0.000 description 1
- 238000011946 reduction process Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
- G08B27/008—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations with transmission via TV or radio broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
- H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/323—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the physical layer [OSI layer 1]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
- H04L69/085—Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- Emergency Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Circuits Of Receivers In General (AREA)
- Mobile Radio Communication Systems (AREA)
- Alarm Systems (AREA)
Abstract
放送受信装置、放送受信装置の動作方法、放送伝送装置及び放送伝送装置の動作方法が開示される。本発明の一実施例に係る放送受信装置は、放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信する放送受信部及び前記伝送パケットをデコーディングして前記災難警報情報を獲得する制御部を含む。【選択図】図７７
Description
本発明は、放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法に関するものである。
放送システムにおいて、災難警報情報(Emergency Alert information)の伝送は、放送を視聴する使用者に緊急状況であることを知らせて即刻措置を取るようにする役割をする。特に、北米放送環境において、災難通知情報の伝達は、FEMA(Federal Emergency Management Agency)及びFCC(Federal Communications Commission)等で指定している。従って、次世代放送システムにも災難警報情報の伝送が支援されなければならない。
既存の放送システムの災難通知情報は、主にCAP(Common Alerting Protocol)メッセージの形態に構成されており、CAPは、メッセージ形態を表現する方法を提示しているが、これを伝送する方法は伝送プロトコルに依存する。従って、災難警報情報を伝達するためには、伝送システムの特性が反映されなければならず、CAPを利用した災難警報情報伝達方案及び伝送プロトコルが必要である。
本発明の一実施例は、災難警報情報を伝送するためのシグナリングシステムを構成し、これを伝送プロトコルに適用できるようにする放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
特に、本発明の一実施例は、災難警報情報を伝達できるシグナリングシステムを構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
特に、本発明の一実施例は、災難警報情報を伝達できるセクションテーブル(Section table)を構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
特に、本発明の一実施例は、災難警報情報を伝達できるパケットを構成して受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
特に、本発明の一実施例は、物理層内の特定物理層パイプを介して、災難警報情報を送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
特に、本発明の一実施例は、災難状況情報に基づいて感知周期を設定して送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することを目的とする。
本発明の一実施例に係る放送受信装置は、放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信する放送受信部及び前記伝送パケットをデコーディングして前記災難警報情報を獲得する制御部を含む。
特に、前記放送受信部は、前記災難警報情報のみを伝送するために指定された伝送経路である第１伝送経路を介して、災難警報情報を伝送するための伝送パケットを受信することができる。
特に、物理層は、前記第１伝送経路が前記物理層に含まれることを知らせる情報を含むことができる。
特に、前記放送受信部は、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する伝送経路である第２伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信することができる。
特に、前記放送受信部は、放送サービスをスキャンするための情報を他の層を経ずに物理層に直接伝送するための伝送経路である第３伝送経路に基づいて、前記災難警報情報を伝送するための伝送パケットを受信することができる。
特に、前記第３伝送経路に基づいて受信した伝送パケットは、前記災難警報情報を獲得するための経路情報を含み、前記放送受信部は、前記経路情報に基づいて前記第３伝送経路と異なる第４伝送経路を介して、前記災難警報情報を獲得するための伝送パケットを受信することができる。
特に、前記経路情報は、前記災難警報情報を伝送する物理層パイプを識別するための情報を含むことができる。
特に、前記制御部は、前記伝送パケットをデコーディングして前記災難警報情報に関連した放送サービス情報を獲得し、前記関連した放送サービス情報は、前記災難警報情報に関連したリアルタイムサービスを伝送する伝送経路情報及び前記災難警報情報に関連した非リアルタイムサービスを受信するためのアドレス情報のうち少なくとも一つである。
特に、前記制御部は、前記災難警報情報に基づいて、前記物理層を介して災難警報情報が伝送されるのか否かを感知する機能を活性化するための第１情報を獲得することができる。
特に、前記第１情報は、感知機能の活性化開始時間情報、感知機能の活性化持続時間情報及び感知機能の非活性化持続時間情報のうち少なくともいずれか一つを含むことができる。
特に、前記第１情報は、前記災難警報情報を伝送する放送伝送装置の位置に基づいて決定される。
特に、前記第１情報は、前記放送受信装置の位置と災難発生地域の間の距離に比例する感知機能の非活性化持続時間を有することができる。
特に、前記第１情報は、災難警報の優先順位を示す第２情報に基づいて決定され、前記第２情報は、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報を含むことができる。
また、本発明の一実施例に係る放送受信装置の動作方法は、放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信するステップ、前記伝送パケットをデコーディングするステップ及び前記デコーディングされた伝送パケットから災難警報情報を獲得するステップを含むことができる。
また、本発明の一実施例に係る放送伝送装置は、緊急状況を知らせるための災難警報情報を警報当局から収集し、前記収集した災難警報情報を伝送するための形態にエンコーディングする制御部及び放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記エンコーディングされた災難警報情報を伝送する伝送部を含むことができる。
また、本発明の一実施例に係る放送伝送装置の動作方法は、前記収集した災難警報情報を伝送するための形態にエンコーディングするステップ及び放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記エンコーディングされた災難警報情報を伝送するステップを含むことができる。
本発明の一実施例は、災難警報情報を伝送するためのシグナリングシステムを構成し、これを伝送プロトコルに適用できるようにする放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
特に、本発明の一実施例は、災難警報情報を伝達できるシグナリングシステムを構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
特に、本発明の一実施例は、災難警報情報を伝達できるセクションテーブル(Section table)を構成する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
特に、本発明の一実施例は、災難警報情報を伝達できるパケットを構成して受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
特に、本発明の一実施例は、物理層内の特定物理層パイプを介して、災難警報情報を送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
特に、本発明の一実施例は、災難状況情報に基づいて感知周期を設定して送受信する放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法を提供することができる。
以下、添付した図面を参照して本発明の実施例に対して、本発明が属する技術分野で通常の知識を有した者が容易に実施できるように詳しく説明する。なお、本発明は多様な異なる形態に具現することができ、ここで説明する実施例に限定されない。そして、図面において、本発明を明確に説明するために説明と関係のない部分は省略しており、明細書全体において類似する部分に対しては、類似する図面符号を付している。
また、ある部分がある構成要素を「含む」とした場合、これは特に限定する記載がない限り、他の構成要素を除くものではなく、他の構成要素をさらに含むことができることを意味する。
本発明の一実施例に係る放送伝送装置及びその方法は、地上波放送サービスのためのベースプロファイル、モバイル放送サービスのためのハンドヘルドプロファイル及び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)アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルは、所定場所に移動できるが、比較的停止した受信範疇に属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置または車両用に拡張することができるが、このような使用用途は、ベースプロファイル受信機動作では期待できない。
ベースプロファイルは、主にループトップ(roof-top)アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルは、所定場所に移動できるが、比較的停止した受信範疇に属する携帯用装置も含むことができる。ベースプロファイルの用途は、若干の改善された実行によってハンドヘルド装置または車両用に拡張することができるが、このような使用用途は、ベースプロファイル受信機動作では期待できない。
受信のターゲット信号対雑音比の範囲は、略１０〜２０dBであるが、これは既存の放送システム(例えば、ATSC A/５３)の１５dB信号対雑音比受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを用いるバッテリで駆動されるハンドヘルド装置におけるほど重要ではない。ベースプロファイルに対する重要なシステムパラメータが以下の表１に記載されている。
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリ電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は、歩行者または車両速度で移動することができる。受信機の複雑度だけでなく消費電力は、ハンドヘルドプロファイルの装置の具現のために大変重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０〜１０dBであるが、より低い室内受信を目的とした場合、０dBの以下に達するように設定することができる。
ハンドヘルドプロファイルは、バッテリ電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。当該装置は、歩行者または車両速度で移動することができる。受信機の複雑度だけでなく消費電力は、ハンドヘルドプロファイルの装置の具現のために大変重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は、略０〜１０dBであるが、より低い室内受信を目的とした場合、０dBの以下に達するように設定することができる。
低い信号対雑音比能力だけでなく、受信機移動性によって現れたドップラー効果に対する復原力は、ハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要なシステムパラメータが以下の表２に記載されている。
３．アドバンスドプロファイル
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルは、MIMO送信及び受信を用いることを要求し、UHDTVサービスはターゲット用途であり、このために当該プロファイルが特別に設計される。向上した能力は与えられた帯域幅でサービス数の増加、例えば、多数のSDTVまたはHDTVサービスを許容することにも用いられる。
アドバンスドプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。当該プロファイルは、MIMO送信及び受信を用いることを要求し、UHDTVサービスはターゲット用途であり、このために当該プロファイルが特別に設計される。向上した能力は与えられた帯域幅でサービス数の増加、例えば、多数のSDTVまたはHDTVサービスを許容することにも用いられる。
アドバンスドプロファイルのターゲット信号対雑音比の範囲は、略２０〜３０dBである。MIMO伝送は、初期には既存の楕円分極伝送装備(elliptically-polarized transmission equipment)を使用し、後で全出力交差分極伝送(full-power cross-polarized transmission)に拡張することができる。アドバンスドプロファイルに対する重要なシステムパラメータが以下の表３に記載されている。
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービス両方に対するプロファイルとして用いられる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために使用される。また、アドバンスドプロファイルは、MIMOを有するベースプロファイルに対するアドバンスドプロファイル及びMIMOを有するハンドヘルドプロファイルに対するアドバンスドプロファイルに区分することができる。そして、当該３つのプロファイルは、設計者の意図によって変更可能である。
次の用語及び定義は本発明に適用可能であり、設計によって変更可能である。
補助ストリーム：future extensionまたは放送局やネットワークオペレータによって要求されることで使用できるまだ定義されなていない変調及びコーディングデータを伝達するセルのシーケンス。
ベースデータパイプ(base data pipe)：サービスシグナリングデータを伝達するデータパイプ。
ベースバンドフレーム(またはBBFRAME)：１つのFECエンコーディング過程(BCH及びLDPCエンコーディング)に対する入力を形成するKbchビットの集合。
セル(cell)：OFDM伝送の１つのキャリアによって伝達される変調値。
コーディングブロック(coded block)：PLS１データのLDPCエンコーディングされたブロックまたはPLS２データのLDPCエンコーディングされたブロックのうちのうちの１つ。
データパイプ(data pipe)：１つまたは多数のサービスまたはサービスコンポーネントを伝達できるサービスデータまたは関連したメタデータを伝達する物理層(physical layer)におけるロジカルチャネル。
データパイプユニット(DPU、data pipe unit)：データセルをフレームにおけるデータパイプに割当できる基本ユニット。
データシンボル(data symbol)：プリアンブルシンボルではないフレームにおけるOFDMシンボル(フレームシグナリングシンボル及びフレームエッチ(edge)シンボルはデータシンボルに含まれる。)。
DP_ID：当該８ビットフィールドは、SYSTEM_IDによって識別されたシステム内でデータパイプを一意に識別する。
ダミーセル(dummy cell)：PLS(physical layer signalling)シグナリング、データパイプ、または補助ストリームのために使用されていない残っている容量を満たすために使用される擬似ランダム値を伝達するセル。
FAC(emergency alert channel、災難警報チャネル)：EAS情報データを伝達するフレームの一部。
フレーム(frame)：プリアンブルで始まりフレームエッチシンボルで終了する物理層(physical layer)タイムスロット。
frame repetition unit：スーパーフレーム(super-frame)で８回繰り返されるFEFを含む同一または異なるフィジカルプロファイルに属するフレームの集合。
FIC(fast information channel、高速情報チャネル)：サービスと当該ベースデータパイプとの間でのマッピング情報を伝達するフレームにおけるロジカルチャネル。
FECBLOCK：データパイプデータのLDPCエンコーディングされたビットの集合。
FFTサイズ：基本周期Tのサイクルで表現されたアクティブシンボル周期Tsと同一な特定モードに使用される名目上のFFTサイズ。
フレームシグナリングシンボル(frame signaling symbol)：PLSデータの一部を伝達する、FFTサイズ、ガードインターバル(guard interval)、及びスキャッタード(scattered)パイロットパターンの特定の組合せでフレームの始まりで使用されるより高いパイロット密度を有するOFDMシンボル。
フレームエッチシンボル(frame edge symbol)：FFTサイズ、ガードインターバル、及びスキャッタードパイロットパターンの特定の組合せでフレームの終わりで使用されるより高いパイロット密度を有するOFDMシンボル。
フレームグループ(frame-group)：スーパーフレームで同一フィジカルプロファイルタイプを有するすべてのフレームの集合。
FEF(future extension frame)：プリアンブルで始める、将来の拡張に使用できるスーパーフレーム内で物理層(physical layer)タイムスロット。
フューチャーキャスト(futurecast)UTBシステム：入力が１つ以上のMPEG２-TSまたはIP(Internet protocol)または一般ストリームであり、出力がRFシグナルである提案された物理層(physical layer)放送システム。
インプットストリーム(input stream、入力ストリーム)：システムによって最終ユーザに伝達されるサービスのアンサンブル(ensemble)のためのデータのストリーム。
ノーマル(normal)データシンボル：フレームシグナリングシンボル及びフレームエッチシンボルを除いたデータシンボル。
フィジカルプロファイル(PHY profile)：該当する受信機が具現すべきすべての構造のサブセット。
PLS：PLS１及びPLS２から構成された物理層(physical layer)シグナリングデータ。
PLS１：PLS２のデコーディングに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するFSS(frame signalling symbol)に伝達されるPLSデータの最初の集合。
NOTE：PLS１データはフレームグループのデュレーション(duration)の間一定である。
PLS２：データパイプ及びシステムに関するより詳細なPLSデータを伝達するFSSに伝送されるPLSデータの二番目の集合。
PLS２ダイナミックデータ(dynamic data)：フレームごとにダイナミックに変化するPLS２データ。
PLS２スタティックデータ(static data)：フレームグループのデュレーションの間スタティックのPLS２データ。
プリアンブルシグナリングデータ(preamble signaling data)：プリアンブルシンボルによって伝達され、システムの基本モードの確認に使用されるシグナリングデータ。
プリアンブルシンボル(preamble symbol)：基本PLSデータを伝達し、フレームの始まりに位置する固定長のパイロットシンボル。
NOTE：プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びFFTサイズを検出するために高速初期バンドスキャンに主に使用される。
将来使用(future use)のためにリザーブド(reserved)：現在の文書で定義されないが将来定義される。
スーパーフレーム(superframe)：８フレーム繰返し単位の集合。
タイムインターリービングブロック(time interleaving block、TI block)：タイムインターリーバメモリの１つの用途に該当する、タイムインターリービングが実行されるセルの集合。
タイムインターリービンググループ(time interleaving group、TI group)：整数、ダイナミックに変化するXFECBLOCKの数からなった、特定データパイプに対するダイナミック容量割当が実行される単位。
NOTE：タイムインターリービンググループは、１つのフレームに直接マッピングまたは多数のフレームにマッピングされる。タイムインターリービンググループは、１つ以上のタイムインターリービングブロックを含むことができる。
タイプ１データパイプ(Type１DP)：すべてのデータパイプがフレームにTDM(time division multiplexing)方式でマッピングされるフレームのデータパイプ。
タイプ２データパイプ(Type２DP)：すべてのデータパイプがフレームにFDM方式でマッピングされるフレームのデータパイプ。
XFECBLOCK：１つのLDPC FECBLOCKのすべてのビットを伝達するNcellsセルの集合。
図１は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック(Input Format block)１０００、BICM(bit interleaved coding & modulation)ブロック１０１０、フレームビルディングブロック(Frame building block)１０２０、OFDM(orthogonal frequency division multiplexing)生成ブロック(OFDM generation block)１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
IPストリーム/パケット及びMPEG２-TSは、主な入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらのデータ入力に加えて、管理情報が入力されて各入力ストリームに対する該当帯域幅のスケジューリング及び割当を制御する。１つまたは多数のTSストリーム、IPストリーム及び/または一般ストリーム入力が同時に許容される。
インプットフォーマットブロック１０００は、それぞれの入力ストリームを独立的なコーディング及び変調が適用される１つまたは多数のデータパイプにデマルチプレックスすることができる。データパイプは、堅固性(robustness)制御の基本単位であり、これはQoS(Quality of Service)に影響を及ぼす。１つまたは多数のサービスまたはサービスコンポーネントが１つのデータパイプによって伝達される。インプットフォーマットブロック１０００の詳しい動作は後述する。
データパイプは１つまたは多数のサービスまたは、サービスコンポーネントを伝達できるサービスデータまたは関連メタデータを伝達する物理層(physical layer)におけるロジカルチャネルである。
また、データパイプユニットは、１つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
インプットフォーマットブロック１０００で、パリティ(parity)データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値のコンステレーションシンボルにマッピングされる。当該シンボルは、当該データパイプに使用される特定インターリービング深さにかけてインターリービングされる。アドバンスドプロファイルにおいて、BICMブロック１０１０でMIMOエンコーディングが実行され、追加データ経路がMIMO伝送のために出力に追加される。BICMブロック１０１０の詳しい動作は後述する。
フレームビルディングブロック１０２０は、１つのフレーム内で入力データパイプのデータセルをOFDMシンボルにマッピングすることができる。マッピング後、周波数領域ダイバーシティーのために、特に周波数選択的フェーディングチャネルを防止するために、周波数インターリービングが利用される。フレームビルディングブロック１０２０の詳しい動作は後述する。
プリアンブルを各フレームの始まりに挿入した後、OFDM生成ブロック１０３０は、サイクリックプレフィックス(cyclic prefix)をガードインターバルとして有する既存のOFDM変調を適用することができる。アンテナスペースダイバーシティーのために、分散した(distributed)MISO方式が送信機にかけて適用される。また、PAPR(peak-to-average power ratio)方式が時間領域で実行される。柔軟なネットワーク方式のために、当該提案は多様なFFTサイズ、ガードインターバル長さ、当該パイロットパターンの集合を提供する。OFDM生成ブロック１０３０の詳しい動作は後述する。
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理層(physical layer)シグナリング情報を生成することができる。また、当該シグナリング情報は、関心のあるサービスが受信機側で適切に回復するように伝送される。シグナリング生成ブロック１０４０の詳しい動作は後述する。
図２、３、４は、本発明の実施例に係るインプットフォーマットブロック１０００を示す。各図面について説明する。
図２は、本発明の一実施例に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム(single input stream)であるときのインプットフォーマットブロックを示す。
図２に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
物理層(physical layer)への入力は、１つまたは多数のデータストリームからなることができる。それぞれのデータストリームは、１つのデータパイプによって伝達される。モードアダプテーション(mode adaptaion)モジュールは、入力されるデータストリームをBBF(baseband frame)のデータフィールドにスライスする。当該システムは、３種類の入力データストリーム、すなわちMPEG２-TS、IP、GS(generic stream)を支援する。MPEG２-TSは、最初のバイトが同期バイト(０x４７)の固定長(１８８バイト)のパケットを特徴とする。IPストリームは、IPパケットヘッダ内でシグナリングされる可変長IPデータグラムパケットから構成される。当該システムは、IPストリームに対してIPv４とIPv６の両方を支援する。GSは、カプセル化パケットヘッダ内でシグナリングされる可変長パケットまたは一定の長さパケットから構成される。
(a)は信号データパイプに対するモードアダプテーション(mode adaptaion)ブロック２０００及びストリームアダプテーション(stream adaptation)２０１０を示し、(b)はPLSデータを生成及び処理するためのPLS生成ブロック２０２０及びPLSスクランブラ２０３０を示す。各ブロックの動作について説明する。
入力ストリームスプリッタは、入力されたTS、IP、GSストリームを多数のサービスまたはサービスコンポーネント(オーディオ、ビデオなど)ストリームに分割する。モードアダプテーション(mode adaptaion)モジュール２０１０は、CRCエンコーダ、BB(baseband)フレームスライサー、及びBBフレームヘッダ挿入ブロックから構成される。
CRCエンコーダは、ユーザパケット(user packet、UP)レベルでのエラー検出のための３種類のCRCエンコーディング、すなわちCRC-８、CRC-１６、CRC-３２を提供する。算出されたCRCバイトは、UPした後に添付される。CRC-８はTSストリームに使用され、CRC-３２はIPストリームに使用される。GSストリームがCRCエンコーディングを提供しない場合、提案されたCRCエンコーディングが適用されなければならない。
BBフレームスライサーは、入力を内部ロジカルビットフォーマットにマッピングする。最初の受信ビットはMSBと定義する。BBフレームスライサーは、使用可能データフィールド容量と同じ数の入力ビットを割り当てる。BBFペイロードと同じ数の入力ビットを割り当てるために、UPストリームがBBFのデータフィールドに適合するようにスライスされる。
BBフレームヘッダ挿入ブロックは、２バイトの固定長BBFヘッダをBBフレームの前に挿入することができる。BBFヘッダは、STUFFI(１ビット)、SYNCD(１３ビット)、及びRFU(２ビット)から構成される。固定された２バイトBBFヘッダだけでなく、BBFは２バイトBBFヘッダの終わりに拡張フィールド(１または３バイト)を有することができる。
ストリームアダプテーション(stream adaptation)２０１０は、スタッフィング(stuffing)挿入ブロック及びBBスクランブラから構成される。スタッフィング挿入ブロックは、スタッフィングフィールドをBBフレームのペイロードに挿入することができる。ストリームアダプテーション(stream adaptation)に対する入力データがBBフレームを満たすことに十分である場合、STUFFIは０に設定され、BBFはスタッフィングフィールドを有しない。そうでない場合、STUFFIは１に設定され、スタッフィングフィールドはBBFヘッダ直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダ及び可変サイズのスタッフィングデータを含む。
BBスクランブラは、エネルギー分散のために完全なBBFをスクランブリングする。スクランブリングシーケンスはBBFと同期化される。スクランブリングシーケンスはフィードバックシフトレジスタによって生成される。
PLS生成ブロック２０２０は、PLSデータを生成することができる。PLSは、受信機でフィジカルレイヤ（物理層）(physical layer)データパイプに接続できる手段を提供する。PLSデータは、PLS１データ及びPLS２データから構成される。
PLS１データは、PLS２データのデコーディングに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームでFSSに伝達されるPLSデータの最初の集合である。PLS１データは、PLS２データの受信及びデコーディングに要求されるパラメータを含む基本送信パラメータを提供する。また、PLS１データは、フレームグループのデュレーションの間一定である。
PLS２データは、データパイプ及びシステムに関するより詳細なPLSデータを伝達するFSSに伝送されるPLSデータの二番目の集合である。PLS２は、受信機が所望するデータパイプのデコーディングに十分な情報を提供するパラメータを含む。PLS２シグナリングは、さらにPLS２スタティックデータ(PLS２-STATデータ)及びPLS２ダイナミックデータ(PLS２-DYNデータ)の二種類のパラメータから構成される。PLS２スタティックデータは、フレームグループのデュレーションの間スタティックのPLS２データであり、PLS２ダイナミックデータは、フレームごとにダイナミックに変化するPLS２データである。
PLSデータについての詳しい内容は後述する。
PLSスクランブラ２０３０は、エネルギー分散のために生成されたPLSデータをスクランブリングすることができる。
前述したブロックは、省略してもよく、類似または同一機能を有するブロックによって代替することもできる。
図３は、本発明の他の一実施例に係るインプットフォーマットブロックを示す。
図３に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施例に該当する。
図３は、入力信号がマルチインプットストリーム(multi input stream)に該当する場合、インプットフォーマットブロックのモードアダプテーション(mode adaptaion)ブロックを示す。
マルチインプットストリーム(multi input stream)を処理するためのインプットフォーマットブロックのモードアダプテーション(mode adaptaion)ブロックは、多数入力ストリームを独立的に処理することができる。
図３に示すように、マルチインプットストリーム(multi input stream)をそれぞれ処理するためのモードアダプテーション(mode adaptaion)ブロックは、インプットストリームスプリッタ(input stream splitter)３０００、インプットストリームシンクロナイザー(input stream synchronizer)３０１０、補償遅延(compensatin delay)ブロック３０２０、ヌルパケット削除ブロック(null packet deletion block)３０３０、ヘッダコンプレッションブロック(header compression block)３０４０、CRCエンコーダ(CRC encoder)３０５０、BBフレームスライサー(BB frame slicer)３０６０、及びBBヘッダ挿入ブロック(BB header insertion block)３０７０を含むことができる。モードアダプテーション(mode adaptaion)ブロックの各ブロックについて説明する。
CRCエンコーダ３０５０、BBフレームスライサー３０６０、及びBBヘッダ挿入ブロック３０７０の動作は、図２を参照して説明したCRCエンコーダ、BBフレームスライサー、及びBBヘッダ挿入ブロックの動作に該当するので、その説明は省略する。
インプットストリームスプリッタ３０００は、入力されたTS、IP、GSストリームを多数のサービスまたはサービスコンポーネント(オーディオ、ビデオなど)ストリームに分割する。
インプットストリームシンクロナイザー３０１０はISSYと呼ぶことができる。ISSYは、いかなる入力データフォーマットに対してもCBR(constant bit rate)及び一定のEnd-to-End伝送遅延を保障する適合な手段を提供することができる。ISSYは、TSを伝達する多数のデータパイプの場合に常に利用され、GSストリームを伝達する多数のデータパイプに選択的に利用される。
補償遅延(compensatin delay)ブロック３０２０は、受信機で追加メモリを必要とせず、TSパケット再結合メカニズムを許容するために、ISSY情報の挿入による分割されたTSパケットストリームを遅延させることができる。
ヌルパケット削除ブロック３０３０は、TS入力ストリームの場合のみに使用される。一部TS入力ストリームまたは分割されたTSストリームは、VBR(variable bit-rate)サービスをCBR TSストリームに収容するために存在する多数のヌルパケットを有することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ヌルパケットは確認され伝送されないようにすることができる。受信機で、除去されたヌルパケットは、伝送に挿入されたDNP(deleted null-packet、削除されたヌルパケット)カウンターを参照して、本来存在していた正確な場所に再挿入することができ、CBRが保障されタイムスタンプ(PCR)を更新する必要がなくなる。
ヘッダコンプレッションブロック３０４０は、TSまたはIP入力ストリームに対する伝送効率を増加させるために、パケットヘッダ圧縮を提供することができる。受信機は、ヘッダの特定部分に対するアプリオリ(a priori)情報を持つことがあるので、この既知の情報(known information)は送信機から削除することができる。
TSに対して、受信機は同期バイト構成(０x４７)及びパケット長さ(１８８バイト)に関するアプリオリ情報を有することができる。入力されたTSが１つのPIDのみを有するコンテンツを伝達すれば、すなわち、１つのサービスコンポーネント(ビデオ、オーディオなど)またはサービスサブコンポーネント(SVCベースレイヤ、SVCエンハンスメントレイヤ、MVCベースビュー、またはMVC依存ビュー)に対してのみ、TSパケットヘッダ圧縮がTSに(選択的に)適用されるようにすることができる。TSパケットヘッダ圧縮は、入力ストリームがIPストリームである場合選択的に使用される。
前記ブロックは、省略または類似または同一機能を有するブロックで代替することができる。
図４は、本発明の他の実施形態に係るインプットフォーマットブロックを示す。
図４に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
図４は、インプットシグナルが複数のインプットストリームに対応するとき、入力フォーマットモジュールのストリーム適応ブロックを示す。
図４に示すように、複数のインプットストリームをそれぞれ処理するためのモード適応ブロックは、スケジューラ４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンドシグナリング４０３０、BBフレームスクランブラ４０４０、PLS生産ブロック４０５０、及びPLSスクランブラ４０６０を含むことができる。説明はストリーム適応ブロックのそれぞれのブロックに対して提供される。
スタッフィングデータブロック４０２０、BBフレームスクランブラ４０４０、PLS生産ブロック４０５０及びPLSスクランブラ４０６０は、図２に図示されたスタッフィング挿入ブロック、BBスクランブラ、PLS生産ブロック及びPLSスクランブラに対応する。従って、それに関する説明は省略する。
スケジューラ４０００は、それぞれのDPのFECBLOCKの量から全体フレームをわたる全体的なセル割当を決定することができる。PLS、EAC及びFICのための割当を含んでスケジューラは、フレームのFSS内PLSセルまたはインバンドシグナリングに伝送されるPLS２-DYNデータの値を生産する。FECBLOCK、EAC及びFICに関する詳しい説明は後述する。
１フレーム遅延ブロック４０１０は、DP内に挿入されるインバンドシグナリング情報のための現在のフレームを介して伝送される次のフレームに対するスケジュールリング情報のような１つの伝送フレームによるインプットデータを遅延させることができる。
インバンドシグナリング４０３０は、フレームのDP内PLS２データの遅延されない部分に挿入される。
上述したブロックは、類似または同一機能を有するブロックによって省略または代替することができる。
図５は、本発明の一実施例に係るBICMブロックを示す。
図５に図示されたBICMブロックは、図１を参照して説明したBICMブロック１０１０の一実施例に該当する。
上述したように、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、UHDTVサービスなどを提供することができる。
QoSが本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するので、それぞれのサービスに該当するデータはそれぞれ異なる方式を介して処理されなければならない。従って、本発明の一実施例に係るBICMブロックは、SISO、MISO、MIMO方式をそれぞれのデータ経路に該当するデータパイプに独立的に適用することで、各データパイプを独立に処理することができる。結果的に、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、それぞれのデータパイプを介して伝送される各サービスまたはサービスコンポーネントに対するQoSを調節することができる。
(a)はベースプロファイル及びハンドヘルドプロファイルによって共有されるBICMブロックを示し、(b)はアドバンスドプロファイルのBICMブロックを示す。
ベースプロファイル及びハンドヘルドプロファイルによって共有されるBICMブロック及びアドバンスドプロファイルのBICMブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
ベースプロファイル及びハンドヘルドプロファイルに対するBICMブロック及びアドバンスドプロファイルに対するBICMブロックのそれぞれの処理ブロックについて説明する。
ベースプロファイル及びハンドヘルドプロファイルに対するBICMブロックの処理ブロック５０００は、データFECエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパ５０３０、SSD(signal space diversity)エンコーディングブロック５０４０、タイムインターリーバ５０５０を含むことができる。
データFECエンコーダ５０１０は、外部コーディング(BCH)及び内部コーディング(LDPC)を利用してFECBLOCK手順を生成するために、入力BBFにFECエンコーディングを実行する。外部コーディング(BCH)は、選択的なコーディング方法である。データFECエンコーダ５０１０の具体的な動作については後述する。
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながらデータFECエンコーダ５０１０の出力をインターリービングして、LDPCコード及び変調方式の組合せで最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作については後述する。
コンステレーションマッパ５０３０は、QPSK、QAM-１６、不均一QAM(NUQ-６４、NUQ-２５６、NUQ-１０２４)または不均一コンステレーション(NUC-１６、NUC-６４、NUC-２５６、NUC-１０２４)を利用して、ベース及びハンドヘルドプロファイルにおいてビットインターリーバ５０２０からのそれぞれのセルワードを変調したり、アドバンスドプロファイルにおいてセルワードデマルチプレクサ５０１０-１からのセルワードを変調して、パワーが正規化されたコンステレーションポイントelを提供することができる。当該コンステレーションマッピングは、データパイプに対してのみ適用される。NUQが任意の形態を有する反面、QAM-１６及びNUQは正四角形形状を有することが観察される。それぞれのコンステレーションが９０度の倍数だけ回転すれば、回転したコンステレーションは本来のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーが相互等しくなる。NUQ及びNUCはいずれも各コードレート(code rate)に対して特別に定義され、使用される特定の１つは、PLS２データに保管されたパラメータDP_MODによってシグナリングされる。
ＳＳＤエンコーディングブロック５０４０は、２次元、３次元、４次元でセルをフリーコーディングして、難しいフェーディング条件で受信堅固性（robustness）を増加させることができる。
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定することができる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
アドバンスドプロファイルに対するBICMブロックの処理ブロック５０００-１は、データFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、及びタイムインターリーバを含むことができる。
ただし、処理ブロック５０００-１は、セルワードデマルチプレクサ５０１０-１及びMIMOエンコーディングブロック５０２０-１をさらに含むという点で、処理ブロック５０００と区別される。
また、処理ブロック５０００-１におけるデータFECエンコーダ、ビットインターリーバ、コンステレーションマッパ、タイムインターリーバの動作は、前述したデータFECエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパ５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
セルワードデマルチプレクサ５０１０-１は、アドバンスドプロファイルのデータパイプがMIMO処理のために単一セルワードストリームをデュアルセルワードストリームに分離するために使用される。セルワードデマルチプレクサ５０１０-１の具体的な動作に関しては後述する。
MIMOエンコーディングブロック５０２０-１は、MIMOエンコーディング方式を利用してセルワードデマルチプレクサ５０１０-１の出力を処理することができる。MIMOエンコーディング方式は、放送信号送信のために最適化されている。MIMO技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特に、放送に対して、相互異なる信号電波特性による２つのアンテナの間の受信信号パワーの差またはチャネルの強いLOSコンポーネントは、MIMOから容量利得を得難くする。提案されたMIMOエンコーディング方式は、MIMO出力信号のうちの１つの位相ランダム化及び回転に基づくプリコーディングを利用してこの問題を克服する。
MIMOエンコーディングは、送信機及び受信機の両方において少なくとも２つのアンテナを必要とする２x２MIMOシステムのために意図されている。２つのMIMOエンコーディングモードは、本提案であるFR-SM(full-rate spatial multiplexing)及びFRFD-SM(full-rate full-diversity spatial multiplexing)で定義される。FR-SMエンコーディングは、受信機側での比較的小さい複雑度増加で容量増加を提供する反面、FRFD-SMエンコーディングは、受信機側での大きい複雑度増加で容量増加及び追加的なダイバーシティー利得を提供する。提案されたMIMOエンコーディング方式は、アンテナ極性配置を制限しない。
MIMO処理は、アドバンスドプロファイルフレームに要求されるが、これはアドバンスドプロファイルフレームにおけるすべてのデータパイプが、MIMOエンコーダによって処理されるということを意味する。MIMO処理は、データパイプレベルで適用される。コンステレーションマッパ出力ペア(pair)のNUQ(e１、i及びe２、i)は、MIMOエンコーダの入力に供給される。MIMOエンコーダ出力ペア(g１、i及びg２、i)は、それぞれの送信アンテナの同一キャリアk及びOFDMシンボルlによって伝送される。
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
図６は、本発明の他の実施例に係るBICMブロックを示す。
図６に図示されたBICMブロックは、図１を参照して説明したBICMブロック１０１０の一実施例に該当する。
図６は、PLS、EAC、及びFICを保護するためのBICMブロックを示す。EACは、EAS情報データを伝達するフレームの一部であり、FICは、サービスと該当するベースデータパイプの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。EAC及びFICに対する詳細な説明は後述する。
図６に示すように、PLS、EAC、及びFICを保護するためのBICMブロックは、PLS FECエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパ６０２０を含むことができる。
また、PLS FECエンコーダ６０００は、スクランブラ、BCHエンコーディング/ゼロ挿入ブロック、LDPCエンコーディングブロック、及びLDPCパリティパンクチャリング(puncturing)ブロックを含むことができる。BICMブロックの各ブロックについて説明する。
PLS FECエンコーダ６０００は、スクランブリングされたPLS１/２データ、EAC及びFICセクションをエンコーディングすることができる。
スクランブラは、BCHエンコーディング及びショートニング(shortening)及びパンクチャリングされたLDPCエンコーディング前にPLS１データ及びPLS２データをスクランブリングすることができる。
BCHエンコーディング/ゼロ挿入ブロックは、PLS保護のためのショートニングされたBCHコードを利用して、スクランブリングされたPLS１/２データに外部エンコーディングを行い、BCHエンコーディング後ゼロビットを挿入することができる。PLS１データに対してのみ、ゼロ挿入の出力ビットがLDPCエンコーディング前にパーミュテーション(permutation)される。
LDPCエンコーディングブロックは、LDPCコードを利用してBCHエンコーディング/ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、Cldpc及びパリティビットPldpcはそれぞれのゼロが挿入されたPLS情報ブロックIldpcから組織的にエンコーディングされ、その後に添付される。
PLS１及びPLS２に対するLDPCコードパラメータは、次の表４のようである。
LDPCパリティパンクチャリングブロックは、PLS１データ及びPLS２データに対してパンクチャリングを行うことができる。
ショートニングがPLS１データ保護に適用されると、一部LDPCパリティビットはLDPCエンコーディング後パンクチャリングされる。また、PLS２データ保護のために、PLS２のLDPCパリティビットがLDPCエンコーディング後パンクチャリングされる。これらパンクチャリングされたビットは伝送されない。
ビットインターリーバ６０１０は、それぞれのショートニング及びパンクチャリングされたPLS１データ及びPLS２データをインターリービングすることができる。
コンステレーションマッパ６０２０は、ビットインターリービングされたPLS１データ及びPLS２データをコンステレーションにマッピングすることができる。
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
図７は、本発明の一実施例に係るフレームビルディングブロック(frame building block)を示す。
図７に図示したフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施例に該当する。
図７に示すように、フレームビルディングブロックは遅延補償ブロック７０００、セルマッパ(cell mapper)７０１０、及び周波数インターリーバ(frequency interleaver)７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。
遅延補償ブロック７０００は、データパイプと該当するPLSデータの間のタイミングを調節して、送信機側でデータパイプと該当するPLSデータ間の同時性(co-time)を保障することができる。インプットフォーマットブロック及びBICMブロックによるデータパイプの遅延を対処することで、PLSデータはデータパイプだけ遅延される。BICMブロックの遅延は、主にタイムインターリーバ５０５０によるものである。インバンド(In-band)シグナリングデータは、次のタイムインターリービンググループの情報をシグナリングされるデータパイプより１つのフレーム先に伝達されるようにすることができる。遅延補償ブロックは、それに合わせてインバンド(In-band)シグナリングデータを遅延させる。
セルマッパ７０１０は、PLS、EAC、FIC、データパイプ、補助ストリーム、及びダミーセルをフレーム内でOFDMシンボルのアクティブ(active)キャリアにマッピングすることができる。セルマッパ７０１０の基本機能は、それぞれのデータパイプ、PLSセル、及びEAC/FICセルに対するタイムインターリービングによって生成されたデータセルを、存在すれば、１つのフレーム内でそれぞれのOFDMシンボルに該当するアクティブ(active)OFDMセルのアレイにマッピングするものである。(PSI(program specific information)/SIのような)サービスシグナリングデータは、個別的に収集されてデータパイプによって送信される。セルマッパは、フレーム構造の構成及びスケジューラーによって生成されたダイナミックインフォメーション(dynamic information)に応じて動作する。フレームに関する詳しい内容は後述する。
周波数インターリーバ７０２０は、セルマッパ７０１０から受信されたデータセルをランダムにインターリービングして、周波数ダイバーシティーを提供することができる。また、周波数インターリーバ７０２０は、単一フレームで最大のインターリービング利得を得るために、他のインターリービングシード(seed)順を利用して、２つの順次的なOFDMシンボルから構成されたOFDMシンボルペア(pair)で動作することができる。
前述したブロックは、省略または類似または同一機能を有するブロックで代替することができる。
図８は、本発明の一実施例に係るOFDM生成ブロックを示す。
図８に図示されたOFDM生成ブロックは、図１を参照して説明したOFDM生成ブロック１０３０の一実施例に該当する。
OFDM生成ブロックは、フレームビルディングブロックによって生成されたセルによってOFDMキャリアを変調して、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは順次ガードインターバルを挿入し、PAPR減少処理を適用して最終RF信号を生成する。
図８に示すように、OFDM生成ブロックは、パイロット及びリザーブドトーン挿入ブロック(pilot and reserved tone insertion block)８０００、２Ｄ-eSFN(single frequency network)エンコーディングブロック８０１０、IFFT(inverse fast Fourier transform)ブロック８０２０、PAPR減少ブロック８０３０、ガードインターバル挿入ブロック(guard interval insertion block)８０４０、プリアンブル挿入ブロック(preamble insertion block)８０５０、その他システム挿入ブロック８０６０、及びDACブロック８０７０を含むことができる。
パイロット及びリザーブドトーン挿入ブロック８０００は、パイロット及びリザーブドトーンを挿入することができる。
ＯＦＤＭシンボル内の多様なセルは受信機から先験的に知られた転送された値を有するパイロットとして知られた参照情報に変調される。パイロットセルの情報は、分散パイロット、連続パイロット、エッジパイロット、ＦＳＳ（frame signalling symbol）パイロット、及びＦＥＳ（frame edge symbol）パイロットで構成される。各パイロットは、パイロットタイプ及びパイロットパターンに従って特定増加パワーレベルで転送される。パイロット情報の値は与えられたシンボルで１つが各々の転送キャリアに対するものである一連の値に該当する参照シーケンスで誘導される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャンネル推定、転送モード識別のために使われることができ、また位相雑音を追跡するために使用できる。
参照シーケンスから取った参照情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除外した全てのシンボルにおける分散パイロットセルで転送される。連続パイロットは、フレームの全てのシンボルに挿入される。連続パイロットの数及び位置はＦＦＴサイズ及び分散パイロットパターンに全て依存する。エッジキャリアは、プリアンブルシンボルを除外した全てのシンボル内のエッジパイロットと同一である。エッジキャリアは、スペクトルのエッジまで周波数インターポレーション（interpolation：補間）を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。ＦＳＳパイロット及びＦＥＳパイロットはフレームのエッジまで時間インターポレーション（interpolation：補間）を許容するために挿入される。
本発明の一実施形態に係るシステムは非常に堅い転送モードをサポートするために分散ＭＩＳＯ方式が選択的に使われるＳＦＮをサポートする。２Ｄ−ｅＳＦＮは多数の送信アンテナを使用する分散ＭＩＳＯ方式であって、各アンテナはＳＦＮネットワークで各々異なる送信機に位置することができる。
２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために２Ｄ−ｅＳＦＮ処理を行って多数の送信機から転送された信号の位相を歪曲させることがある。したがって、長時間の間の低い平面フェーディングまたは深いフェーディングによるバースト誤りが軽減できる。
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（または、リザーブドトーン）に指定されないデータシンボルでの全てのセルは、周波数インターリーバからのデータセルのうちの１つを伝達する。セルはＯＦＤＭキャリアにマッピングされる。
ＰＡＰＲ減少ブロック８０３０は、時間領域で多様なＰＡＰＲ減少アルゴリズムを用いて入力信号にＰＡＰＲ減少を実行する。
ガードインターバル挿入ブロック８０４０はガードインターバルを挿入することができ、プリアンブル挿入ブロック８０５０は信号の前にプリアンブルを挿入することができる。プリアンブルの構造に対する詳細な内容は後述する。
その他システム挿入ブロック８０６０は、放送サービスを提供する二以上の相互異なる放送送信/受信システムのデータが同じRF信号帯域で同時に伝送されるように、時間領域で複数の放送送信/受信システムの信号をマルチプレックスすることができる。この場合、二以上の相互異なる放送送信/受信システムは、相互異なる放送サービスを提供するシステムをいう。相互異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味する。
ＤＡＣブロック８０７０は、入力されたディジタル信号をアナログ信号に変換して出力することができる。ＤＡＣブロック８０７０から出力された信号は物理層プロファイルによって多数の出力アンテナを介して転送できる。本発明の一実施形態に係る送信アンテナは垂直または水平極性を有することができる。
前述したブロックは設計によって省略されるか、類似または同一機能を有するブロックに取替できる。
図９は、本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応する。
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール(synchronization & demodulation module)９０００、フレーム解析モジュール(frame parsing module)９０１０、デマッピング及びデコーディングモジュール(demapping & decoding module)９０２０、出力プロセッサ(output processor)９０３０、及びシグナリングデコーディングモジュール(signaling decoding module)９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。
同期及び復調モジュール９０００は、m個の受信アンテナを介して入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置によって実行される手順の逆過程に該当する復調を実行することができる。
フレーム解析モジュール９０１０は、入力信号フレームを解析し、ユーザによって選択されたサービスが伝送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すると、フレーム解析モジュール９０１０は、インターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されるべき信号及びデータの位置が、シグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることで獲得され、放送信号送信装置によって生成されたスケジューリング情報が復元される。
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要に応じてビット領域データをデインターリービングすることができる。デマッピング及びデコーディングモジュール９０２０は、伝送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを介して伝送チャネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０は、シグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることで、デマッピング及びデコーディングのために必要な伝送パラメータを獲得することができる。
出力プロセッサ９０３０は、伝送効率を向上させるために、放送信号送信装置によって適用される多様な圧縮/信号処理手順の逆過程を実行することができる。この場合、出力プロセッサ９０３０は、シグナリングデコーディングモジュール９０４０から出力されたデータから必要な制御情報を獲得することができる。出力プロセッサ８３００の出力は、放送信号送信装置に入力される信号に該当し、例えばMPEG-TS、IPストリーム(v４またはv６)及びGSである。
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００によって復調された信号からPLS情報を獲得することができる。上述したように、フレーム解析モジュール９０１０、デマッピング及びデコーディングモジュール９２００、出力プロセッサ９３００は、シグナリングデコーディングモジュール９０４０から出力されたデータを利用してその機能を実行することができる。
図１０は、本発明の一実施例に係るフレーム構造を示す。
図１０は、フレームタイムの構成例及びスーパーフレームにおけるFRU(frame repetition unit、フレーム繰返し単位)を示す。(a)は、本発明の一実施例に係るスーパーフレームを示し、(b)は、本発明の一実施例に係るFRUを示し、(c)はFRUでの多様なフィジカルプロファイル(PHY profile)のフレームを示し、(d)はフレームの構造を示す。
スーパーフレームは、８個のFRUで構成することができる。FRUはフレームのTDMに対する基本マルチプレックス単位であり、スーパーフレームで８回繰り返される。
FRUで各フレームは、フィジカルプロファイル(ベース、ハンドヘルド、アドバンスドプロファイル)のうちの１つまたはFEFに属する。FRUでフレームの最大許容数は４であり、与えられたフィジカルプロファイルは、FRUで０回〜４回のいずれかの回数だけ出現できる(例えば、ベース、ベース、ハンドヘルド、アドバンスド)。フィジカルプロファイルの定義は、必要に応じてプリアンブルにおけるPHY_PROFILEのリザーブド値(reserved value)を利用して拡張可能である。
FEF部分は、含まれる場合FRUの終わりに挿入される。FEFがFRUに含まれる場合、FEFの最大数はスーパーフレームで８である。FEF部分が相互隣接することは推奨されない。
１つのフレームは、多数のOFDMシンボル及びプリアンブルにさらに分離される。(d)に示したように、フレームは、プリアンブル、１つ以上のFSS、ノーマルデータシンボル、FESを含む。
プリアンブルは、高速フューチャーキャストUTBシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルについての詳しい内容は後述する。
FSSの主な目的は、PLSデータを伝達することである。高速同期化及びチャネル推定のために、これに伴うPLSデータの高速デコーディングのために、FSSはノーマルデータシンボルより高密度なパイロットパターンを有する。FESはFSSと完全に同一なパイロットを有するが、これはFESの直前のシンボルに対して外挿(extrapolation)なしにFES内での周波数のみの補間(interpolation)及び時間的補間(temporal interpolation)を可能とする。
図１１は、本発明の一実施例に係るフレームのシグナリング階層構造(signaling hierarchy structure)を示す。
図１１は、シグナリング階層構造を示すが、これは３つの主な部分であるプリアンブルシグナリングデータ１１０００、PLS１データ１１０１０、及びPLS２データ１１０２０に分割される。フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。PLS１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むPLS２データに接続してデコーディングすることができるようにする。PLS２は、フレームごとに伝達され、２つの主な部分であるPLS２-STATデータとPLS２-DYNデータに分割される。PLS２データのスタティック及びダイナミック部分には、必要に応じてパディングがなされる。
図１２は、本発明の一実施例に係るプリアンブルシグナリングデータを示す。
プリアンブルシグナリングデータは、受信機がフレーム構造内でPLSデータに接続し、データパイプを追跡できるようにするために必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータについての詳しい内容は、次のようである。
PHY_PROFILE：当該３ビットフィールドは、現在のフレームのフィジカルプロファイルタイプを示す。相互異なるフィジカルプロファイルタイプのマッピングは、以下の表５に示す。
FFT_SIZE：当該２ビットフィールドは、以下の表６で説明するように、フレームグループ内で現在のフレームのFFTサイズを示す。
GI_FRACTION：当該３ビットフィールドは、以下の表７で説明するように、現在のスーパーフレームにおけるガードインターバルの一部(fraction)値を示す。
EAC_FLAG：当該１ビットフィールドは、EACが現在のフレームに提供されるか否かを示す。当該フィールドが１に設定されると、EASが現在のフレームに提供される。当該フィールドが０に設定されると、EASが現在のフレームに伝達されない。当該フィールドは、スーパーフレーム内でダイナミックに転換される。
PILOT_MODE：当該１ビットフィールドは、現在のフレームグループで現在のフレームに対してパイロットモードがモバイルモードであるかまたは固定モードであるかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが使用される。当該フィールドが１に設定されると、固定パイロットモードが使用される。
PAPR_FLAG：当該１ビットフィールドは、現在のフレームグループで現在のフレームに対してPAPR減少が使用されているのか否かを示す。当該フィールドが１に設定されると、トーン予約(tone reservation)がPAPR減少のために使用される。当該フィールドが０に設定されると、PAPR減少が使用されない。
FRU_CONFIGURE：当該３ビットフィールドは、現在のスーパーフレームで存在するFRUのフィジカルプロファイルタイプ構成を示す。現在のスーパーフレームですべてのプリアンブルにおける当該フィールドで、現在のスーパーフレームで伝達されるすべてのプロファイルタイプが識別される。当該３ビットフィールドは、以下の表８に示したように、それぞれのプロファイルに対して異なるように定義される。
RESERVED：当該７ビットフィールドは、将来使用のためにリザーブド(reserved)される。
図１３は、本発明の一実施例に係るPLS１データを示す。
PLS１データは、PLS２の受信及びデコーディングを可能とするために必要なパラメータを含んだ基本伝送パラメータを提供する。上述したように、PLS１データは、１つのフレームグループの全体デュレーションの間変化しない。PLS１データのシグナリングフィールドの具体的な定義は次のようである。
PREAMBLE_DATA：当該２０ビットフィールドは、EAC_FLAGを除いたプリアンブルシグナリングデータのコピーである。
NUM_FRAME_FRU：当該２ビットフィールドは、FRU当たりのフレーム数を示す。
PAYLOAD_TYPE：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。PAYLOAD_TYPEは、表９に示したようにシグナリングされる。
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コードについての詳しい内容は後述する。
PLS２_MOD：当該３ビットフィールドは、PLS２によって使用される変調タイプを示す。変調タイプは、表１１に従ってシグナリングされる。
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２に対して使用されない。
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：当該３ビットフィールドは、データパイプのタイプを示す。これは、以下の表１３に従ってシグナリングされる。
DP_GROUP_ID：当該８ビットフィールドは、現在のデータパイプが関連しているデータパイプグループを識別する。これは、受信機が同一DP_GROUP_IDを有するようになる特定サービスに関連しているサービスコンポーネントのデータパイプに接続するために使用される。
BASE_DP_ID：当該６ビットフィールドは、管理層で使用される(PSI/SIのような)サービスシグナリングデータを伝達するデータパイプを示す。BASE_DP_IDによって示すデータパイプは、サービスデータと一緒にサービスシグナリングデータを伝達するノーマルデータパイプであるか、サービスシグナリングデータのみを伝達する専用データパイプである。
DP_FEC_TYPE：当該２ビットフィールドは、関連したデータパイプによって使用されるFECタイプを示す。FECタイプは、以下の表１４に従ってシグナリングされる。
DP_COD：当該４ビットフィールドは、関連したデータパイプによって使用されるコードレート(code rate)を示す。コードレート(code rate)は、以下の表１５に従ってシグナリングされる。
DP_MOD：当該４ビットフィールドは、関連したデータパイプによって使用される変調を示す。変調は、以下の表１６に従ってシグナリングされる。
DP_SSD_FLAG：当該１ビットフィールドは、SSDモードが関連したデータパイプで使用されているのか否かを示す。当該フィールドの値が１に設定されると、SSDは使用される。当該フィールドの値が０に設定されると、SSDは使用されない。
次のフィールドは、PHY_PROFILEがアドバンスドプロファイルを示す０１０と同一であるときのみ現れる。
DP_MIMO：当該３ビットフィールドは、どのタイプのMIMOエンコーディング処理が関連したデータパイプに適用されるのかを示す。MIMOエンコーディング処理のタイプは、以下の表１７に従ってシグナリングされる。
DP_TI_TYPE：当該１ビットフィールドは、タイムインターリービングのタイプを示す。０の値は、１つのタイムインターリービンググループが１つのフレームに該当し、１つ以上のタイムインターリービングブロックを含むことを示す。１の値は、１つのタイムインターリービンググループが１つより多いフレームで伝達され、１つのタイムインターリービングブロックのみを含むことを示す。
DP_TI_LENGTH：当該２ビットフィールド(許容値は１、２、４、８のみ)の使用は、次のようなDP_TI_TYPEフィールド内で設定される値によって決定される。
DP_TI_TYPEの値が１に設定されると、当該フィールドは、それぞれのタイムインターリービンググループがマッピングされるフレームの数であるPIを示し、タイムインターリービンググループ当たり１つのタイムインターリービングブロックが存在する(NTI=１)。当該２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
DP_TI_TYPEの値が０に設定されると、当該フィールドはタイムインターリービンググループ当たりタイムインターリービングブロックの数であるNTIを示し、フレーム当たり１つのタイムインターリービンググループが存在する(PI=１)。当該２ビットフィールドで許容されるPIの値は、以下の表１８に定義される。
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は、以下の表１９に従ってシグナリングされる。
DP_INBAND_MODE：当該２ビットフィールドは、現在のデータパイプがインバンド(In-band)シグナリング情報を伝達するのか否かを示す。インバンド(In-band)シグナリングタイプは、以下の表２０に従ってシグナリングされる。
DP_PROTOCOL_TYPE：当該２ビットフィールドは、与えられたデータパイプによって伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは、入力ペイロードタイプが選択されると、以下の表２１に従ってシグナリングされる。
DP_CRC_MODE：当該２ビットフィールドは、CRCエンコーディングがインプットフォーマットブロックで使用されているのか否かを示す。CRCモードは、以下の表２２に従ってシグナリングされる。
DNP_MODE：当該２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるヌルパケット削除モードを示す。DNP_MODEは、以下の表２３に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、DNP_MODEは００の値に設定される。
ISSY_MODE：当該２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるISSYモードを示す。ISSY_MODEは、以下の表２４に従ってシグナリングされる。DP_PAYLOAD_TYPEがTS(「００」)ではない場合、ISSY_MODEは００の値に設定される。
HC_MODE_TS：当該２ビットフィールドは、DP_PAYLOAD_TYPEがTS(「００」)に設定される場合に関連したデータパイプによって使用されるTSヘッダ圧縮モードを示す。HC_MODE_TSは、以下の表２５に従ってシグナリングされる。
HC_MODE_IP：当該２ビットフィールドは、DP_PAYLOAD_TYPEがIP(「０１」)に設定される場合にIPヘッダ圧縮モードを示す。HC_MODE_IPは、以下の表２６に従ってシグナリングされる。
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サイズに応じて異なる長さを有する。
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セルの全体数を超過できない。
DDP１は、Type１DPによって占有されたOFDMセルの数である。DDP２はType２DPによって占有されたセルの数である。PLS、EAC、FICはすべてType１DPに応じて同じ方法でマッピングされるので、それらはすべて「Type１マッピングルール」を従って、Type１マッピングは常にType２マッピングに先行する。
図２１は、本発明の一実施例に係るDPマッピングを示す。
(a)はtype１DPマッピングのためのOFDMセルのアドレス指定を示し、(b)はType２DPのためのマッピングのためのOFDMセルのアドレス指定を示す。
Type１DP(０、…、DDP１１)マッピングのためのOFDMセルのアドレス指定は、type１DPのアクティブデータセルのために定義される。アドレス指定スキームは、アクティブデータセルによって割り当てられたType１DPのそれぞれのためのTlsからセルの順序を定義する。また、これはPLS２の動的部分内のDPの位置をシグナルするために使用される。
EAC及びFICなしに、アドレス０は最後のFSS内PLSを伝送する最後のセルを直ちに従うセルを参照する。もし、EACが伝送され、FICが対応するフレーム内にない場合、アドレス０はEACを伝送する最後のセルを直ちに従うセルを参照する。Type１DPのためのアドレス０は(a)に示されたように、２つの異なるケースを考慮して計算される。(a)を例えばPLS、EAC及びFICは全部伝送されると仮定される。EAC及びFICのうちの１つまたは両方ともが省略された場合に拡張が容易である。もしFICですべてのセルをマッピングした後FSS内に残っているセルがある場合、(a)の左側のように示すことができる。
Type２DP(０、…、DDP２１)マッピングのためのOFDMセルのアドレス指定は、Type２DPのアクティブデータセルのために定義される。アドレス指定スキームは、アクティブデータセルによって割り当てられたType２DPのそれぞれのためのTlsからセルの順序を定義する。また、これはPLS２の動的部分内のDPの位置をシグナルするために使用される。
(b)に示されたように３つの若干異なるケースが可能である。(b)の左側に示された最初ケースの場合、最後のFSS内のセルはType２マッピングに利用可能である。中間に示された二番目のケースの場合、FICは一般的なシンボルのセルに割り当てられるが、FICセルの数はCFSSより大きくない。(b)の右側に示された三番目のケースの場合、シンボルにマッピングされたFICセルの数がCFSSを超える点を除いて二番目のケースと同一である。
PLS、EAC及びFICがType１の例のように「type１マッピングルール」と同様であるので、Type２DPを先行するtype１DPのケースは拡張が容易である。
DPUは、フレーム内DPを割り当てるためのシグナリングユニットと一緒に定義される。セルマッパ７０１０は、DPのそれぞれのためのTIsによって生産されたセルをマッピングすることができる。タイムインターリーバ５０５０は、TI-ブロックのシリーズ及びセルのセットから構成されるXFECBLOCKの可変数を含むTI-ブロックそれぞれを出力する。XFECBLOCK内のセルの数NcellsはFECBLOCK大きさ、Nldpc、及び配置されたシンボル当たり伝送されたビットの数に従属する。
DPUは、PHYプロファイルに支持されるXFECBLOCK内のセル数のすべての可能な値の最大公約数として定義される。セル内のDPUの長さはLDPUで定義される。PHYプロファイルのそれぞれは、他のFECBLOCK大きさの結合及び配置されたPHYプロファイルに基づいて定義されるLDPU、シンボル当たりビットの他の数を支持する。
図２２は、本発明の一実施例に係るFEC構造を示す。
図２２は、ビットインターリービング前の本発明の一実施例に係るFEC構造を示す。上述したように、データFECエンコーダは、外部コーディング(BCH)及び内部コーディング(LDPC)を利用してFECBLOCK手順を生成するために、入力BBFにFECエンコーディングを実行することができる。図示されたFEC構造はFECBLOCKに該当する。また、FECBLOCK及びFEC構造はLDPCコードワードの長さに該当する同一値を有する。
図２２に示されたように、BCHエンコーディングがそれぞれのBBF(Kbchビット)に適用された後、LDPCエンコーディングがBCH-エンコーディングされたBBF(Kldpcビット=Nbchビット)に適用される。
Nldpcの値は、６４８００ビット(long FECBLOCK)または１６２００ビット(short FECBLOCK)である。
以下の表２８及び表２９は、long FECBLOCK及びshort FECBLOCKのそれぞれに対するFECエンコーディングパラメータを示す。
BCHエンコーディング及びLDPCエンコーディングの具体的な動作は次のようである。
１２-エラー訂正BCHコードがBBFの外部エンコーディングに使用される。short FECBLOCK及びlong FECBLOCKに対するBBF生成多項式は、すべての多項式を乗算することで得られる。
LDPCコードは、外部BCHエンコーディングの出力をエンコーディングするために使用される。完成されたBldpc(FECBLOCK)を生成するために、Pldpc(パリティビット)がそれぞれのIldpc(BCH-エンコーディングされたBBF)から組織的にエンコーディングされ、Ildpcに添付される。完成されたBldpc(FECBLOCK)は次の数式で表現される。
long FECBLOCK及びshort FECBLOCKに対するパラメータは、上記表２８及び２９にそれぞれ与えられる。
long FECBLOCKに対してNldpc-Kldpcパリティビットを計算する具体的な手順は次のようである。
１)パリティビット初期化
２)パリティチェックマトリックスのアドレスの最初の行で特定されたパリティビットアドレスで最初の情報ビットi０累算(accumulate)。パリティチェックマトリックスのアドレスの詳細な内容は後述する。例えば、比率１３/１５に対して、
３)次の３５９個の情報ビットis、s=１、２、…、３５９に対して、次の数式を利用してパリティビットアドレスでis累算(accumulate)。
ここで、xは最初のビットi０に該当するパリティビット累算器のアドレスを示し、Qldpcはパリティチェックマトリックスのアドレスで特定されたコードレート(code rate)依存定数である。前記例である比率１３/１５に対する、従って情報ビットi１に対するQldpc=２４に引き続き、次の動作が実行される。
４)３６１番目情報ビットi３６０に対して、パリティビット累算器のアドレスは、パリティチェックマトリックスのアドレスの二番目行に与えられる。同一方式で、次の３５９個の情報ビットis、s=３６１、３６２、…、７１９に対するパリティビット累算器のアドレスは、数式６を利用して得られる。ここで、xは情報ビットi３６０に該当するパリティビット累算器のアドレス、すなわちパリティチェックマトリックスの二番目行のエントリーを示す。
５)同一方式で、３６０個の新しい情報ビットのすべてのグループに対して、パリティチェックマトリックスのアドレスからの新しい行は、パリティビット累算器のアドレスを求めることに使用される。
すべての情報ビットが利用された後、最終パリティビットが次のように得られる。
６)i=１で始まり次の動作を順次実行
ここで、pi、i=０、１、...Nldpc-Kldpc-１の最終コンテンツは、パリティビットpiと同一である。
表３０を表３１に代替し、long FECBLOCKに対するパリティチェックマトリックスのアドレスをshort FECBLOCKに対するパリティチェックマトリックスのアドレスに代替することを除いて、short FECBLOCKに対する当該LDPCエンコーディング手順は、long FECBLOCKに対するt LDPCエンコーディング手順に従う。
図２３は、本発明の一実施例に係るビットインターリービングを示す。
LDPCエンコーダの出力は、グループ内インターリービング及びQCB(Quasi-Cyclic Block)によるパリティインターリービングから構成されるビット-インターリーブされる。
(a)はQCBインターリービングを示し、(b)はグループ内インターリービングを示す。
FECBLOCKはパリティインターリーブされる。パリティインターリービングの出力で、LDPCコードワードは１８０long FECBLOCK内の隣のQCブロック及びshort FECBLOCK内の４５隣のQCブロックから構成される。longまたはshort FECBLOCKのうちの１つのQCブロックのそれぞれは３６０ビットから構成される。パリティインターリーブされたLDPCコードワードはQCBインターリービングによってインターリーブされる。QCBインターリービングのユニットはQCブロックである。パリティインターリービングの出力に対するQCブロックは、FECBLOCKの長さに従うNcells=６４８００/ηmod or１６２００/ηmodで、図２３に図示されたQCBインターリービングによって変更される。QCBインターリービングパターンは、モジュレーションタイプの結合及びLDPCコード率のそれぞれに対して唯一である。
QCBインターリービング後、グループ内インターリービングは、以下の表３２に定義された順序(ηmod)及びモジュレーションタイプに応じて実行される。１つのグループ内QCブロックの数、NQCB_IGも定義される。
グループ内インターリービングプロセスは、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を含むことができる。タイムインターリービンググループが多数のタイムインターリービングブロックに分離されると、タイムインターリービンググループは、１つのフレームのみに直接マッピングされる。以下の表３２に示したように、タイムインターリービングには３種類のオプションがある(タイムインターリービングを省略する追加オプション除外)。
各々のデータパイプで、タイムインターリービングメモリは入力されたＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックから出力されたＸＦＥＣＢＬＯＣＫ）を格納する。入力されたＸＦＥＣＢＬＯＣＫは、
として定義されると仮定する。ここで、ｄｎ，ｓ、ｒ、ｑはｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｒ番目ＸＦＥＣＢＬＯＣＫのｑ番目セルであり、次のようなＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。
一般的に、タイムインターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファとしても作用する。これは、それぞれのデータパイプに対して２つのメモリバンクで達成される。最初のタイムインターリービングブロックは最初のバンクに記入される。最初のバンクで判読される間、二番目のタイムインターリービングブロックが二番目バンクに記入される。
タイムインターリービングは、ツイスト行列ブロックインターリーバである。n番目のタイムインターリービンググループのs番目のタイムインターリービングブロックに対して、列の数ＮｃがＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）と同一である反面、タイムインターリービングメモリの行の数Ｎｒはセルの数Ｎcellsと同一である(すなわち、Ｎｒ＝Ｎcells)。
図２６は、本発明の一実施例に係るツイスト行列ブロックインターリーバの基本動作を示す。
図２６(a)はタイムインターリーバで記入動作を示し、図２６(b)はタイムインターリーバで判読動作を示す。(a)に示したように、最初のXFECBLOCKはタイムインターリービングメモリの最初の列に列方向に記入され、二番目のXFECBLOCKは次の列に記入され、このような動作が続けられる。そしてインターリービングアレイで、セルが対角線方向に判読される。(b)に示したように、最初の行から(最も左側列を始めとしえ行に沿って右側に)最後の行まで対角線方向の判読が行われる間、Ｎｒ個のセルが判読される。具体的に、ｚｎ，ｓ，ｉ（ｉ＝０，．．．，ＮｒＮｃ）が順次判読されるタイムインターリービングメモリセル位置であると仮定する場合、このようなインターリービングアレイでの判読動作は、以下の式のように行インデックスＲｎ,s,i、列インデックスＣｎ,s,i 、関連したツイストパラメータＴｎ,s,iを算出することで実行される。
ここで、ＳshiftはＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく対角線方向の判読過程に対する共通シフト値であり、シフト値は、以下の数式のようにPLS２-STATから与えられたＮｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸによって決定される。
図２７は、本発明の他の一実施例に係るツイスト行列ブロックインターリーバの動作を示す。
さらに具体的に、図３７は、ＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５であるとき、仮想XFECBLOCKを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリにおいてインターリービングアレイを示す。
変数ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）＝ＮｒはＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸより小さいか同一である。従って、ＮｘＢＬＯＣＫ＿ＴＩ（ｎ，ｓ）に関係なく、受信機側で単一メモリディインターリービングを達成するために、ツイスト行列ブロックインターリーバ用インターリービングアレイは、仮想XFECBLOCKをタイムインターリービングメモリに挿入することで、Ｎｒ×Ｎｃ＝Ｎcells×Ｎ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸの大きさに設定され、判読過程は次の数式のようになされる。
タイムインターリービンググループの数は３に設定される。タイムインターリーバのオプションは、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データでシグナリングされて、
図２８は、本発明の一実施例に係るツイスト行列ブロックインターリーバの対角線方向の判読パターンを示す。
さらに具体的に、図２８はパラメータＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ＝７及びSshift=(７-１)/２=３を有するそれぞれのインターリービングアレイからの対角線方向の判読パターンを示す。このとき、上記擬似コードで示した判読過程で、
Viの値が省略され、Viの次の計算値が使用される。
図２９は、本発明の一実施例に係るそれぞれのインターリービングアレイからのインターリービングされたXFECBLOCKを示す。
図２９は、パラメータＮ'ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ＝７及びSshift=３を有するそれぞれのインターリービングアレイからインターリービングされたXFECBLOCKを示す。
図３０は、本発明の他の実施例に係る放送受信装置の構成を示す。
図３０の実施例で、放送受信装置１００は、放送受信部１１０、インターネットプロトコル(Internet Protocol、IP)通信部１３０及び制御部１５０を含む。
放送受信部１１０は、放送受信部１１０が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に、放送受信部１１０は多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。放送受信部１１０は、物理層モジュール１１９と物理層IPフレームモジュール１１７を含むことができる。物理層モジュール１１９は、放送網の放送チャネルを介して放送関連信号を受信して処理する。物理層IPフレームモジュール１１７は、物理層モジュール１１９から獲得したIPデータグラムなどのデータパケットを特定フレームに変換する。例えば、物理層モジュール１１９は、IPデータグラムなどをRS FraemまたはGSEなどに変換することができる。
IP通信部１３０は、IP通信部１３０が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的にIP通信部１３０は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。IP通信部１３０は、インターネット接近制御モジュール１３１を含むことができる。インターネット接近制御モジュール１３１は、インターネット通信網(broad band)を介してサービス、コンテンツ及びシグナリングデータのうち少なくともいずれか１つを獲得するための放送受信装置１００の動作を制御する。
制御部１５０は、制御部１５０が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に制御部１５０は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。制御部１５０は、シグナリングデコーダ１５１、サービスマップデータベース１６１、サービスシグナリングチャネルパーサー１６３、アプリケーションシグナリングパーサー１６６、警告シグナリングパーサー１６８、ターゲティングシグナリングパーサー１７０、ターゲティングプロセッサ１７３、A/Vプロセッサ１６１、警告プロセッサ１６２、アプリケーションプロセッサ１６９、スケジュールされたストリーミングデコーダ(scheduled streaming decoder)１８１、ファイルデコーダ１８２、ユーザ要求ストリーミングデコーダ１８３、ファイルデータベース１８４、コンポーネント同期化部１８５、サービス/コンテンツ獲得制御部１８７、再分配モジュール１８９、デバイスマネージャ１９３及びデータシェアリング部１９１のうち少なくともいずれか１つを含むことができる。
サービス/コンテンツ獲得制御部１８７は、放送網またはインターネット通信網を介して獲得したサービス、コンテンツ、サービスまたはコンテンツに関連したシグナリングデータ獲得のための受信機の動作を制御する。
シグナリングデコーダ１５１は、シグナリング情報をデコーディングする。
サービスシグナリングパーサー１６３は、サービスシグナリング情報を解析する。
サービスシグナリングパーサー１６３は、サービスシグナリング情報を解析する。
アプリケーションシグナリングパーサー１６６は、サービスに関するシグナリング情報を抽出して解析する。このとき、サービスに関連したシグナリング情報は、サービススキャンに関連したシグナリング情報を含むことができる。また、サービスに関連したシグルロリン情報は、サービスを介して提供されるコンテンツに関連したシグナリング情報を含むことができる。
警告シグナリングパーサー１６８は、警告に関するシグナリング情報を抽出して解析する。
ターゲティングシグナリングパーサー１７０は、サービスまたはコンテンツを個人化(personalization)するための情報またはターゲティング情報をシグナリングする情報を抽出して解析する。
ターゲティングプロセッサ１７３は、サービスまたはコンテンツを個人化するための情報を処理する。
警告プロセッサ１６２は、災難警報(emergency alert)に関するシグナリング情報を処理する。
アプリケーションプロセッサ１６９は、アプリケーション関連情報及びアプリケーションの実行を制御する。具体的には、アプリケーションプロセッサ１６９は、ダウンロードされたアプリケーションの状態及びディスプレイパラメータを処理する。
A/Vプロセッサ１６１は、デコーディングされたオーディオまたはビデオ、アプリケーションデータなどに基づいて、オーディオ/ビデオのレンダリング関連動作を処理する。
スケジュールされたストリーミングデコーダ１８１は、予め放送局などのコンテンツ提供業者が定めた日程とおりストリーミングされるコンテンツであるスケジュールされたストリーミングをデコーディングする。
ファイルデコーダ１８２は、ダウンロードされたファイルをデコードする。特にファイルデコーダ１８２はインターネット通信網を介してダウンロードされたファイルをデコードする。
ユーザ要求ストリーミングデコーダ１８３は、ユーザ要求によって提供されるコンテンツ(On Demand Content)をデコードする。
ファイルデータベース１８４は、ファイルを格納する。具体的にファイルデータベース１８４は、インターネット通信網を介してダウンロードしたファイルを格納することができる。
コンポーネント同期化部１８５は、コンテンツまたはサービスを同期化する。具体的にコンポーネント同期化部１８５は、スケジュールされたストリーミングデコーダ１８１、ファイルデコーダ１８２及びユーザ要求ストリーミングデコーダ１８３のうち少なくともいずれか１つが、デコーディングしたコンテンツを同期化することができる。
サービス/コンテンツ獲得制御部１８７は、サービス、コンテンツ、サービスまたはコンテンツに関するシグナリング情報のうち少なくともいずれか１つを獲得するための受信機の動作を制御する。
再分配モジュール１８９は、放送網を介してサービスまたはコンテンツを受信できない場合、サービス、コンテンツ、サービスに関連情報及びコンテンツ関連情報のうち少なくともいずれか１つの獲得を支援するための動作を行う。具体的に、外部の管理装置３００にサービス、コンテンツ、サービスに関連情報及びコンテンツ関連情報のうち少なくともいずれか１つを要求することができる。このとき、外部の管理装置３００は、コンテンツサーバーからなることができる。
デバイスマネージャ１９３は、連動可能な外部装置を管理する。具体的にデバイスマネージャ１９３は、外部装置の追加、削除及び更新のうち少なくともいずれか１つを行うことができる。また、外部装置は放送受信装置１００と連結及びデータ交換が可能である。
データシェアリング部１９１は、放送受信装置１００と外部装置の間のデータ伝送動作を行い、交換関連情報を処理する。具体的に、データシェアリング部１９１は、外部装置にA/Vデータまたはシグナリング情報を伝送することができる。また、データシェアリング部１９１は、外部装置にA/Vデータまたはシグナリング情報を受信することができる。
データシェアリング部１９１は、放送受信装置１００と外部装置の間のデータ伝送動作を行い、交換関連情報を処理する。具体的に、データシェアリング部１９１は、外部装置にA/Vデータまたはシグナリング情報を伝送することができる。また、データシェアリング部１９１は、外部装置にA/Vデータまたはシグナリング情報を受信することができる。
スマートフォンやタブレットなどの端末装置の使用が増加することによって、これらの端末装置と連動できる放送サービスが増えている。これにより、端末装置は、放送サービスと連動して動作するために、放送サービスに関する情報を示す放送サービスの属性を必要とする。但し、連動装置が放送サービスを直接受信しない場合が多い。このような場合、連動装置は、放送伝送装置を介して放送サービスの属性を獲得しなければならない。従って、放送サービスの属性を効率的に伝送することができる放送受信装置と放送受信装置の動作方法が必要である。これについて、図３１〜図４３に基づいて説明する。
図３１は、本発明の一実施例に係る連動装置と連動する放送サービスを提供する放送システムを示す。
本発明の一実施例に係る放送システムは、放送受信装置１００、連動(Companion)装置２００、放送伝送装置３００、コンテンツ/シグナリングサーバ４００及びACRサーバ５００を含む。
放送伝送装置３００は、放送サービスを伝送する放送サーバを示す。このとき、放送受信装置１００は、放送伝送装置３００から放送網(Broadcast channel)を介して放送サービスを受信する。また、放送受信装置１００は、放送網を介して放送伝送装置３００から放送サービスをシグナリングする情報を受信することができる。また、放送受信装置１００は、放送網を介して放送伝送装置３００からトリガ、トリガパラメータテーブル(Trigger Parameter Table、TPT)、トリガ宣言的オブジェクト(Trigger Declarative Object、TDO)のような放送サービスのための付加情報を受信することができる。
コンテンツ/シグナリングサーバ４００は、放送サービスに関するコンテンツを生成して管理する。このとき、放送受信装置１００は、通信網(Broadband channel)を介してコンテンツ/シグナリングサーバ４００から放送サービスに関する付加情報及び放送サービスのシグナリング情報のうち少なくともいずれか１つを受信することができる。
自動コンテンツ認識(Automatic Content Recognition、ACR)サーバ３００は、放送サービスに関するACR関連データを管理する。このとき、放送受信装置１００は、通信網(Broadband channel)を介してACRサーバ３００からトリガ(trigger)及び放送サービスに関するアプリケーションのうち少なくともいずれか１つを受信することができる。
連動装置２００は、ホームネットワークを介して放送受信装置１００と連動して放送サービスに関する付加機能を実行する。具体的に連動装置２００は、放送サービスに関するアプリケーション及びファイルのうち少なくともいずれか１つを獲得することができる。また、連動装置２００は、放送サービスに関するアプリケーション及びファイルを実行することができる。このとき、連動装置２００は、ホームネットワークの代わりに３GPPのような移動通信網やHTTPプロキシ(Proxy)サーバを利用することができる。また、具体的な実施例において放送サービスに関するアプリケーションやファイルが単方向ファイル伝送セッション(File Delivery over Unidirectional Transport、FLUTE)を介して伝送される場合、連動装置２００は、放送受信装置１００から放送サービスに関するアプリケーション及びファイルのうち少なくともいずれか１つを受信することができる。また、連動装置２００は、セカンドスクリーン装置(second screen device)といえる。また、連動装置２００は、スマートフォン、タブレット及びラップトップのうち少なくともいずれか１つを含むことができる。具体的に連動装置２００は、放送網を介した放送受信機能を持たずネットワークなどの通信機能を持つ端末装置であってもよい。また、連動装置２００は、１つまたは複数個が存在してもよい。連動装置２００は、連動装置２００の全体的な動作を制御する制御部と、外部装置との通信を行う通信部を含むことができる。制御部は、制御部が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に制御部は、多様な半導体部品が１つに集積されるシステムオンチップ(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。また、通信部は、通信部が行う複数の機能それぞれを行う１つまたは複数のプロセッサであり、１つまたは複数の回路及び１つまたは複数のハードウェアモジュールを含むことができる。具体的に通信部は、多様な半導体部品が１つに集積されるSOC(System On Chip、SOC)からなることができる。このとき、SOCは、グラフィック、オーディオ、ビデオ、モデムなど各種マルチメディア用部品とプロセッサとDRAMなど半導体が１つに統合された半導体からなることができる。
また、放送受信装置１００は、主装置(Primary Device)と呼ぶことができる。
また、具体的な実施例により、放送伝送装置３００、コンテンツ/シグナリングサーバ４００及びACRサーバ５００のうち少なくともいずれか２つが１つのサーバーに統合されて使用される。
前述したように、放送受信装置１００は、放送伝送装置３００から放送サービスのシグナリング情報を受信することができる。または放送受信装置１００は、コンテンツ/シグナリングサーバ４００から放送サービスのシグナリング情報を受信することができる。このとき、放送サービスのシグナリング情報は、放送サービスの属性を含むことができる。これについては、図３２に基づいて詳しく説明する。
図３２は、本発明の一実施例によりシグナリングされる放送サービスの属性を示す。
放送受信装置１００が受信する放送サービスのシグナリング情報は、放送サービスの属性を含むことができる。このとき、放送サービスの属性は、放送サービスを識別する放送サービス識別子、放送サービスの名称、放送サービスのチャネル番号、放送サービスに関する説明、放送サービスのジャンル、放送サービスを表すアイコン、放送サービスの主言語、放送サービスに関する使用報告情報、放送サービスを提供できる装置の情報を示すターゲティング属性、放送サービスの保護(protection)に関する属性、勧告グレード、放送サービスが含むメディアコンポーネントに関する情報のうち少なくともいずれか１つを含むことができる。ターゲティング属性は、サービスが提供される装置を示すものとして、主装置または連動装置２００のうち少なくともいずれか１つを示すことができる。放送サービスのチャネル番号は、メジャーチャネル番号とマイナーチャネル番号を含むことができる。メディアコンポーネントに関する情報は、メディアコンポーネントを識別する識別子、メディアコンポーネントの種類、メディアコンポーネントの名称、メディアコンポーネントの開始時間、メディアコンポーネントの再生時間(duration)、メディアコンポーネントがターゲティングするスクリーンを示す情報、メディアコンポーネントを受信することができるURL、メディアコンポーネントの勧告グレード及びメディアコンポーネントのジャンルのうち少なくともいずれか１つを含むことができる。このとき、メディアコンポーネントがターゲティングするスクリーンは、連動装置２００を示すことができる。
放送サービスの属性は、図３３のように、XML形式でシグナリングされてもよい。但し、放送サービスの属性のシグナリング形式は、これに限定されるものではなく、ビットストリームのように、別の形式でシグナリングされてもよい。
具体的に、放送サービスの属性をシグナリングする情報は、ServiceID、ServiceName、MajorChanNum、MinorChanNum、Description、Genre、Icon、Language、UsageReportingInfo、Targeting、ServiceProtection、AdvisoryRatingのうち少なくともいずれか１つをエレメント(element)として含むことができる。
ServiceIDは、サービスを識別する放送サービス識別子を示す。このとき、ServiceIDは、１つだけ存在してもよい。また、具体的な実施例においてServiceIDは、アンサインドショート(unsigned short)データタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ServiceIDに基づいて放送サービスを識別することができる。
ServiceNameは、放送サービスの名称を示す。ServiceNameは存在しないか、単数または複数個存在してもよい。具体的な実施例においてServiceNameは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ServiceNameに基づいて放送サービスの名称を表示することができる。
MajorChanNumとMinorChanNumは、放送サービスのチャネル番号のメジャー番号とマイナー番号をそれぞれ示す。具体的な実施例においてMajorChanNumとMinorChanNumは存在しないか、１つ存在してもよい。また、MajorChanNumとMinorChanNumは、０から１５の間の数字のうちいずれか１つの整数値を有することができる。MajorChanNumとMinorChanNumは、ユーザの放送サービスの選択を容易にするために使用される。具体的に、放送受信装置１００と連動装置２００は、MajorChanNumとMinorChanNumに基づいて放送サービスのチャネル番号を表示することができる。
Descriptionは、放送サービスに関する説明を示す。Descriptionは存在しないか、単数または複数個存在してもよい。Descriptionは、ストリングデータタイプを有することができる。ユーザは、Descriptionを介して放送サービスの内容を推測することができる。具体的に、放送受信装置１００と連動装置２００は、Descriptionに基づいて放送サービスに関する説明を表示することができる。
Genreは、放送サービスのジャンルを示す。Genreは存在しないか、単数または複数個存在してもよい。具体的な実施例においてGenreは、ストリングデータタイプを有することができる。ユーザは、Genreを介して放送サービスのジャンルがわかる。具体的に、放送受信装置１００と連動装置２００は、Genreに基づいて放送サービスのジャンルを表示することができる。
Iconは、放送サービスを表すアイコンを示す。Iconは存在しないか、単数または複数個存在してもよい。Iconは、ベース６４バイナリデータタイプ(Base ６４ Binary data type)を有することができる。ユーザは、放送サービスを代表するアイコンを介して放送サービスの内容を容易に把握することができる。具体的に、放送受信装置１００と連動装置２００は、Iconに基づいて放送サービスを表すアイコンを表示することができる。
Lagnguageは、放送サービスの主言語を示す。Lagugageは存在しないか、１つ存在してもよい。Lagnguageは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、Languageに基づいて放送サービスの主言語を表示することができる。
UsageReportingInfoは、放送サービスに関する使用報告情報を示す。UsageReportingInfoは存在しないか、単数または複数個存在してもよい。UsageReportingInfoは、ストリングデータタイプを有することができる。具体的にUsageReportingInfoは、使用情報報告のためのパラメータとして使用される。例えば、UsageReportingInfoは使用情報報告のためのURL及び報告周期のうち少なくともいずれか１つを含むことができる。このような使用情報報告を介して、放送サービスプロバイダは放送サービスの使用情報と放送サービスに関する課金情報を獲得することができる。具体的に、放送受信装置１００と連動装置２００は、UsageReportingInfoに基づいて放送サービスの使用情報を報告することができる。
Targetingは、放送サービスのターゲティング属性を示す。Targetingは存在しないか、単数または複数個存在してもよい。具体的にTargetingはストリングデータタイプを有することができる。具体的にTargetingは、当該放送サービスが放送受信装置１００のような主装置のためのものか連動装置２００のためのものかを示すことができる。具体的に、放送受信装置１００と連動装置２００は、Targetingに基づいて放送サービスの表示可否を決定することができる。
ServiceProtectionは、放送サービスの保護(protection)に関する属性を示す。ServiceProtectionは存在しないか、１つ存在してもよい。具体的にServiceProtectionは、ストリングデータタイプを有することができる。
AdvisoryRatingは、放送サービスの勧告グレードを示す。AdvisoryRatingは存在しないか、単数または複数個存在してもよい。AdvisoryRatingは、ストリングデータタイプを有することができる。放送受信装置１００と連動装置２００は、勧告グレードと個人化情報に基づいて放送サービスを遮断することができる。
ComponentItemは、放送サービスが含むメディアコンポーネントに関する情報を示す。具体的にComponentItemは、componentId、ComponentType、ComponentName、StartTime、Duration、TargetScreen、URL、ContentAdvisory及びGenreのうち少なくともいずれか１つを含むことができる。
ComponentIdは、当該メディアコンポーネントを識別する識別子を示す。具体的にComponentIdは、１つ存在してもよい。具体的にComponentIdは、アンサインドデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ComponentIdに基づいてメディアコンポーネントを識別することができる。
CmponentTypeは、当該メディアコンポーネントの種類を示す。具体的にCmponentTypeは、１つ存在してもよい。CmponentTypeは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、CmponentTypeに基づいてメディアコンポーネントの種類を表示することができる。
ComponentNameは、当該メディアコンポーネントの名称を示す。具体的にComponentNameは存在しないか、単数または複数個存在してもよい。ComponentNameは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ComponentNameに基づいてメディアコンポーネントの名称を表示することができる。
StartTimeは、当該メディアコンポーネントの開始時間を示す。具体的にStartTimeは存在しないか、１つ存在してもよい。具体的にStartTimeは、アンサインドショートデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、StartTimeに基づいてメディアコンポーネントの開始時間を判断することができる。
Durationは、当該メディアコンポーネントの再生長を示す。具体的にDurationは存在しないか、１つ存在してもよい。具体的にDurationは、アンサインドショートデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、Durationに基づいてメディアコンポーネントの再生長を判断することができる。
TargetScreenは、当該メディアコンポーネントがターゲティングするスクリーンを示す。具体的にTargetScreenは存在しないか、単数または複数個存在してもよい。具体的にTargetScreenは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、TargetScreenに基づいて当該メディアコンポーネントの再生が必要か否かを判断することができる。
URLは、メディアコンポーネントを受信するためのアドレスを示すことができる。具体的にURLは存在しないか、単数または複数個存在してもよい。具体的にURLは、URIデータタイプを有することができる。具体的にURLは、コンテンツ/シグナリングサーバ４００のアドレスを示すことができる。具体的に、放送受信装置１００と連動装置２００は、URLに基づいてメディアコンポーネントを受信することができる。
ContentAdvisoryは、当該メディアコンポーネントの勧告グレードを示す。ContentAdvisoryの値がAdvisoryRatingと衝突(conflict)する場合、ContentAdvisoryの値が優先することができる。具体的にContentAdvisoryは、単数または複数個存在してもよい。具体的にContentAdvisoryは、ストリングデータタイプを有することができる。具体的に、放送受信装置１００と連動装置２００は、ContentAdvisoryに基づいてメディアコンポーネントの再生可否を決定することができる。
Genreは、メディアコンポーネントのジャンルを示す。具体的にGenreは、単数または複数個存在してもよい。Genreは、ストリングデータタイプを有することができる。前述したサービスのジャンルを示すGenreと衝突する場合、メディアコンポーネントのジャンルを示すGenreが優先することができる。具体的に、放送受信装置１００と連動装置２００は、Genreに基づいてメディアコンポーネントのジャンルを表示することができる。
前述したように、放送受信装置１００と連動装置２００は、ホームネットワーク、３GPPのような移動通信網及びHTTPプロキシサーバのうち少なくともいずれか１つを介して放送受信装置２００と連動することができる。このとき、放送受信装置１００と連動装置２００との間の通信は様々な方式により行われる。具体的に、放送受信装置１００と連動装置１００との間の通信は、汎用プラグ及びプレイ(Universal Plug and Play、UPnP)方式により行われる。
UPnPは、コントロールポイント(Control Point、CP)とコントロールされる装置(Controlled Deivcies、CDs)に装置を区別する。コントロールポイントは、UPnPプロトコルを利用してコントロールされる装置を制御する。具体的な実施例においては、放送受信装置１００がコントロールされる装置のうちの１つに該当する。また、連動装置２００は、コントロールポイントに該当する。UPnPでは、ディスカバリー(discovery)、ディスクリプション(description)、コントロール(control)及びイベンティング(eventing)プロトコルを定義する。ディスカバリープロトコルは、コントロールポイントがコントロールされる装置を探すためのプロトコルである。ディスクリプションプロトコルは、コントロールポイントがコントロールされる装置の情報を獲得するためのプロトコルである。コントロールプロトコルは、コントロールポイントがコントロールされる装置に一定の動作を誘発(invoke)するためのものである。イベンティングプロトコルは、コントロールされる装置が非同期化された通知(notifications)をコントロールポイントに伝送(delivery)するためのものである。本発明の一実施例に係る放送受信装置１００と連動装置２００は、UPnPプロトコルのディスカバリー(discovery)、ディスクリプション(description)、コントロール(control)及びイベンティング(eventing)プロトコルのうち少なくともいずれか１つを使用して連動することができる。例えば、放送受信装置１００がディスカバリープロトコルを利用して連動装置２００を探すことができる。放送受信装置１００と連動装置２００の動作については、図３３〜図４３に基づいて詳しく説明する。
図３３は、本発明の一実施例によりシグナリングされる放送サービスの属性の状態を示す変数を示す。
放送受信装置１００は、連動装置に放送サービスの属性を示す１つの変数を利用して伝送することができる。放送サービスの属性を示す１つの変数は、現在の放送サービスの属性を含むことができる。具体的に、図３３の実施例のように、ServicePropertyという変数を介して伝送することができる。具体的な実施例においてServicePropertyは必須変数であり、ストリングデータタイプを有することができる。また、具体的な実施例においてServicePropertyは、関連アクションを有しなくてもよい。ServicePropertyに対する購読(subscription)を要求する場合、放送受信装置１００はServicePropertyを連動装置に伝送することができる。放送受信装置１００が放送サービスの属性を伝送する具体的な過程については、図３４に基づいて説明する。
図３４は、本発明の一実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２００１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。具体的に、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的に、放送受信装置１００と連動装置２００は、UPnPプロトコルを利用してペアリングセッションを生成することができる。具体的な実施例において、放送受信装置１００がUPnPのディスカバリープロトコルを利用して連動装置２００を探すことができる。例えば、放送受信装置１００がウェルノウン(well known)IPアドレスを介して、連動のための連動装置を探すというディスカバリーメッセージをマルチキャストすることができる。このとき、マルチキャストされたメッセージを受信した連動装置２００は、放送受信装置１００にディスクリプションを要求することができる。放送受信装置１００は、連動装置２００のディスクリプション要求に基づいて連動装置２００にディスクリプションを提供することができる。連動装置２００は、ディスクリプションに基づいて放送受信装置２００に接続することができる。他の具体的な実施例において、連動装置２００がUPnPのディスカバリープロトコルを利用して放送受信装置１００を探すことができる。例えば、連動装置２００は、ウェルノウン(well known)IPアドレスを介して、連動のための放送受信装置１００を探すというメッセージをマルチキャストすることができる。このとき、放送受信装置は、マルチキャストされたメッセージに基づいてディスカバリーメッセージで応答することができる。これにより、ディスカバリーメッセージを受信した連動装置２００は、放送受信装置１００にディスクリプションを要求することができる。放送受信装置１００は、連動装置２００のディスクリプション要求に基づいて、連動装置２００にディスクリプションを提供することができる。連動装置２００は、ディスクリプションに基づいて放送受信装置２００に接続することができる。
連動装置２００は、放送受信装置１００に放送サービスの属性通知を要求する(Ｓ２００３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的に連動装置２００は、UPnPプロトコルを利用して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的な実施例において連動装置２００は、イベンティングプロトコルに基づいて放送受信装置１００に放送サービスの属性に対するイベントの購読(subscription)を要求することができる。
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２００５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性を通知する(notify)(Ｓ２００７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性を通知する。具体的に、放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の状態を示す変数を介して放送サービスの属性を通知することができる。具体的な実施例において放送サービスの属性の状態を示す変数は、図３３のServicePropertyであってもよい。放送サービスの属性の状態を示す変数のデータ形式については、図３５に基づいて詳しく説明する。
図３５は、本発明の一実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性のデータ形式を示す。
放送サービスの属性のデータは、図３５のようにXML形式であってもよい。但し、放送サービスの属性のデータ形式はこれに限定されるものではない。図３５の実施例において放送サービスの属性のデータ形式は、図３２で説明した放送サービスの属性をすべて含む。従って、放送サービスの属性のうち一部だけが変更された場合でも放送受信装置１００は、放送サービスの属性全体を伝送しなければならず、連動装置２００は、放送サービスの属性全体を受信しなければならない。このような場合、放送受信装置１００と連動装置２００との間で交換されるデータ量が大きくなる。また、連動装置２００は、どの放送サービスの属性が変更されたかを再確認しなければならない。従って、放送受信装置１００が連動装置２００に放送サービスの属性を効率的にシグナリングする方法が必要である。これについては、図３６〜図３８に基づいて説明する。
図３６は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数、放送サービスの属性のためのアクション及びアクションの引数(argument)を示す。
本発明の他の実施例において放送サービスの属性を示す変数は、放送サービスの属性を含む変数、放送サービスの属性の名称を示す変数及び放送サービスの属性の変更可否を示す変数のうち少なくともいずれか１つを含むことができる。具体的に連動装置２００が放送サービスの特定属性を要求する場合、放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの属性を伝送することができる。具体的に、放送受信装置１００は、連動装置２００が要求した放送サービスの特定属性を伝送することができる。例えば、放送受信装置１００が放送サービスの属性の変更可否を示す変数を介して連動装置２００に放送サービスの属性の変更可否を通知することができる。このとき、連動装置２００は、必要な放送サービスの属性を、放送サービスの属性の名称を示す変数を介して放送サービスの属性を要求することができる。放送受信装置１００は、連動装置に放送サービスの属性を示す変数を介して放送サービスの属性を通知することができる。
具体的な実施例において放送サービスの属性を示す変数は、ServiceProperty、ServicePropertyName及びServicePropertyChangeFlagのうちいずれか１つを含むことができる。ServicePropertyは、放送サービスの属性を含む。具体的な実施例においてServicePropertyは必須変数であり、ストリングデータタイプを有することができる。ServicePropertyNameは、放送サービスの属性の名称を示す。ServicePropertyNameは必須変数であり、ストリングデータタイプを有することができる。ServicePropertyChangeFlagは、放送サービスの属性の変更可否を示す。具体的な実施例においてServicePropertyChangeFlagは必須変数であり、Boolean data typeを有することができる。また、連動装置２００がServicePropertyChangeFlagに対する購読(subscription)を要求する場合、放送受信装置１００は、ServicePropertyChangeFlagを連動装置に伝送することができる。
連動装置２００は、放送サービスの属性の名称を示す変数を介して放送サービスの属性を要求するために、GetServicePropertyというアクションを使用することができる。GetServicePropertyは必須アクションである。このとき、GetServicePropertyは入力のための引数として、ServiceProgpertyNameを有することができる。また、GetServicePropertyは出力のための引数として、ServicePropertyを有することができる。具体的な実施例において、連動装置２００が放送受信装置１００に獲得しようとする放送サービスの属性をSevicePropertyNameに設定してGetServicePropertyアクションを伝送する場合、連動装置２００は、ServicePropertyNameに該当する放送サービスの属性をServicePropertyで受信することができる。放送受信装置１００と連動装置２００の動作については、図３７に基づいて詳しく説明する。
図３７は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２０２１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３４の実施例と同一であってもよい。
連動装置２００は、放送受信装置１００に放送サービスの属性変更通知を要求する(Ｓ２０２３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性変更通知を要求することができる。具体的な連動装置２００の動作は、図３４の実施例と同一であってもよい。
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２０２５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更可否を通知する(notify)(Ｓ２０２７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更できるか否かを通知することができる。具体的に、放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性変更を通知することができる。具体的に、放送受信装置１００は、放送サービスの属性をシグナリングする情報のバージョンが以前に比べて変更されたかに基づいて、放送サービスの属性の変更可否を判断することができる。また、具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否を示す変数を介して放送サービスの属性の変更可否を通知することができる。具体的な実施例において放送サービスの属性の変更可否を示す変数は、図３３のServicePropertyChangedFlagであってもよい。このとき、放送サービスの属性の変更可否を示すデータ形式については、図３８に基づいて詳しく説明する。
図３８は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の変更可否のデータ形式を示す。
放送サービスの属性の変更可否のデータ形式は、XML形式であってもよい。但し、放送サービスの属性の変更可否のデータ形式はこれに限定されるものではない。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否のみを通知することができる。図３８の実施例にように、放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否をTRUE値またはFALSE値を有するBoolean変数で表示することができる。例えば、放送サービスの属性が変更された場合、放送受信装置１００は連動装置２００に放送サービスの属性の変更可否を示す変数がTRUE値を有するデータを伝送することができる。但し、このような実施例において連動装置２００は、放送サービスのどの属性が変更されたかわからず、放送サービスの属性のいずれかが変更されたことしかわからない。このため、連動装置２００は自身が必要としない放送サービスの属性が変更された場合でも放送サービスの属性を要求することになる。従って、このような実施例は、放送受信装置１００と連動装置２００の不必要な動作と不必要なデータ交換を誘発する可能性がある。これを解決するために放送受信装置１００は変更された放送サービスの属性を連動装置２００に通知する必要がある。これについては、図３９〜図４０に基づいて説明する。
図３９は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
放送サービスの属性が変更された場合、放送受信装置１００は、連動装置２００に変更された属性と放送サービスの属性の変更可否を共に通知することができる。このために、放送サービスの属性の変更可否を示す変数が変更されたサービスの属性を示す情報を含むことができる。このために、放送サービスの属性の変更可否を示す変数は、バイナリヘキサタイプ(binary hex type)を有することができる。従って、他の変数、アクション及びアクションの引数は同一であり、図３６の実施例において放送サービスの属性の変更可否を示す変数であるServicePropertyChangedFlagは、バイナリヘキサタイプ(binary hex type)からなることができる。ServicePropertyChangedFlagに対する購読(subscription)を要求する場合、放送受信装置１００は、ServicePropertyChangedFlagを連動装置に伝送することができる。放送受信装置１００が連動装置２００にシグナリングする放送サービスの属性の変更可否のデータ形式については、図４０に基づいて説明する。
図４０は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の変更可否のデータ形式を示す。
放送サービスの属性の変更可否のデータは、XML形式であってもよい。但し、放送サービスの属性の変更可否のデータ形式はこれに限定されるものではない。放送受信装置１００は、放送サービスの属性のそれぞれに対して特定のビットを割り当てて、放送サービスの属性が変更された場合、当該ビットを１に表示することができる。図４０の実施例において１６進数９００８０００４は、２進数１００１００００００００１００００００００００００１００である。このとき、最初の４桁のビットがそれぞれ放送サービスの主言語、ジャンル、勧告グレード及びターゲティング属性をそれぞれ示すといえる。この場合、連動装置２００は、放送サービスの主言語及びターゲティング属性が変更されたことがわかる。
図３７に戻って、本発明の他の実施例により放送受信装置１００が連動装置２００に放送サービスの属性をシグナリングすることを説明する。
連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求する(Ｓ２０２９)。放送サービスの特定属性は、放送サービスの属性をシグナリングする情報に含まれた放送サービスの属性のうちいずれか１つまたは複数の属性からなることができる。連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性を要求することができる。具体的に、放送受信装置１００が放送サービスの属性変更通知を伝送した場合、連動装置２００は放送受信装置１００に放送サービスの特定属性を要求することができる。このとき、放送サービスの特定属性は、連動装置２００が放送サービスに関する付加サービスを提供するために必要な放送サービスの属性であってもよい。また、図４１〜図４２のように、放送受信装置１００が放送サービスの属性のうち変更された部分をシグナリングした場合、連動装置１００は変更された放送サービスの属性の種類に基づいて放送サービスの特定属性を要求することができる。具体的に連動装置２００は、放送サービスの特定属性が変更された場合、放送サービスの特定属性を要求することができる。放送サービスの特定属性は、連動装置２００が放送サービスに関する付加サービスを提供するために必要な属性であってもよい。例えば、連動装置２００が放送サービスのターゲティング属性に基づいて放送サービスの再生可否を決定する場合、連動装置２００は放送サービスのターゲティング属性が変更された場合に放送サービスのターゲティング属性を要求することができる。
放送受信装置１００は、連動装置２００に放送サービスの特定属性を通知する(Ｓ２０３１)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの特定属性を通知することができる。具体的に、放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの特定属性を通知することができる。例えば、放送受信装置１００は、連動装置２００に連動装置２００が要求した放送サービスの特定属性を伝送することができる。
但し、このような実施例は、放送受信装置１００と連動装置２００との間の持続的な通信を必要とすることがある。特に、放送受信装置１００が複数の連動装置２００と連動する場合、持続的な通信は放送受信装置１００の動作の過負荷を誘発する可能性がある。連動装置１００が放送サービスの属性をコンテンツ/シグナリングサーバ４００から受信するようにする場合、このような問題を解決することができる。これについては、図４１〜図４２に基づいて説明する。
図４１は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数を示す。
放送サービスの属性が変更された場合、放送受信装置１００は連動装置２００に放送サービスの属性の変更可否と放送サービスの属性を受信することができるURLアドレスを共に通知することができる。このために、放送受信装置１００が連動装置２００にシグナリングする放送サービスの属性の状態を示す変数は、放送サービスの属性を受信することができるURLアドレスを示す情報を含むことができる。具体的な実施例においてシグナリングする放送サービスの属性の状態を示す変数は、放送サービスの属性を受信することができるURLアドレスを示すServicePropertyChangeFlagを含むことができる。具体的な実施例においてServicePropertyChangeFlagは選択変数であり、ストリングデータタイプを有することができる。具体的な放送受信装置１００と連動装置２００の動作については、図４２に基づいて説明する。
図４２は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２０４１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３７の実施例と同一であってもよい。
連動装置２００は、放送受信装置１００に放送サービスの属性変更通知を要求する(Ｓ２０４３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの属性通知を要求することができる。具体的な連動装置２００の動作は、図３７の実施例と同一であってもよい。
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２０４５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更可否及び放送サービスの属性を獲得できるURLを通知する(notify)(Ｓ２０４７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの属性の変更可否及び放送サービスの属性を獲得できるURLを通知することができる。具体的に、放送受信装置１００は、放送サービスの属性が以前に比べて変更されたかを判断することができる。具体的に、放送受信装置１００は、放送サービスの属性をシグナリングする情報のバージョンが以前に比べて変更されたかに基づいて放送サービスの属性の変更可否を判断することができる。また、放送サービスの属性が以前に比べて変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性変更及び放送サービスの属性を獲得できるURLを通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に放送サービスの属性の変更可否を示す変数を介して放送サービスの属性の変更可否を通知することができる。具体的な実施例において放送サービスの属性の変更可否を示す変数は、図４１のServicePropertyChangeFlagであってもよい。また、放送受信装置１００は、連動装置２００に放送サービスの属性を獲得できるURLを示す変数を介して放送サービスの属性の変更可否を通知することができる。具体的な実施例において放送サービスの属性を獲得できるURLを示す変数は、図４１のServicePropertyURLであってもよい。
連動装置２００は、放送サービスの属性を獲得できるURLに基づいて放送サービスの属性を獲得する(Ｓ２０４９)。具体的に連動装置２００は、制御部を介して放送サービスの属性を獲得できるURLに基づいて放送サービスの属性を獲得することができる。具体的に連動装置２００は、放送サービスの属性を獲得できるURLに基づいてコンテンツ/シグナリングサーバ４００から放送サービスの属性を獲得することができる。具体的に連動装置２００は、放送サービスの属性を獲得できるURLに基づいて放送サービスの属性をコンテンツ/シグナリングサーバに要求し、コンテンツ/シグナリングサーバ４００から放送サービスの属性を獲得することができる。これにより、放送受信装置１００と連動装置２００との間の通信から発生しうる放送通信装置１００の負荷を軽減することができる。但し、このような実施例において放送受信装置１００は、連動装置２００が必要としない放送サービスの属性が変更される場合でも放送サービスの属性変更を通知しなければならない。従って、放送受信装置１００は不必要な動作を行う問題がある。連動装置２００が放送受信装置１００に通知変更を要求するときに必要な放送サービスの属性を予め設定する場合、放送受信装置１００の不必要な動作を減らすことができる。これについては、図４３〜図４４に基づいて説明する。
図４３は、本発明の他の実施例により放送受信装置が連動装置にシグナリングする放送サービスの属性の状態を示す変数、放送サービスの属性のためのアクション及びアクションの引数(argument)を示す。
連動装置２００が放送受信装置１００に放送サービスの属性変更通知を要求するとともに通知を受けることを希望する放送サービスの属性を指定することができる。このために、連動装置２００は、通知を受けることを希望する放送サービスの属性を指定するアクションを含むことができる。このとき、アクションは、通知を受けることを希望する放送サービスの属性を示す変数を入力引数として有することができる。このようなアクションは、図４３の実施例のSetServicePropertyであってもよい。具体的な実施例においてSetServicePropertyは必須アクションであってもよい。また、SetServicePropertyは、放送サービスの属性の種類を示すServicePropertyNameを入力引数(argument)として有することができる。放送受信装置１００と連動装置２００の具体的な動作は、図４４に基づいて説明する。
図４４は、本発明の他の実施例により放送受信装置が連動装置に放送サービスの属性をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２０６１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図４２の実施例と同一であってもよい。
連動装置２００は、放送受信装置１００に放送サービスの特定属性変更通知を要求する(Ｓ２０６３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性変更通知を要求することができる。連動装置２００は、放送サービスに関する付加情報を提供するために必要な放送サービスの特定属性の変更通知のみを要求することができる。具体的な実施例において連動装置２００は、特定属性の変更通知のみを要求するためのアクションを介して放送サービスの特定属性変更通知を要求することができる。このとき、特定属性の変更通知のみを要求するためのアクションは、図４３で説明したSetServicePropertyであってもよい。連動装置２００が放送受信装置１００に放送サービスの特定属性変更通知を要求する動作は、次のような動作を含むことができる。連動装置２００は、放送受信装置１００にサービスの属性に関する変更通知購読(subscription)を要求することができる。放送受信装置１００は、サービスの属性に関する変更通知購読(subscription)要求を受諾する場合、連動装置２００に受諾メッセージと購読要求を識別する購読識別子(Subscription ID、SID)を共に伝送することができる。連動装置２００は、放送受信装置１００にSIDに基づいて放送サービスの特定属性の変更通知のみを要求することができる。具体的に、連動装置２００はSIDとと共に変更可否の通知を受けようとする放送サービスの特定属性を伝送することができる。また、連動装置２００は、放送受信装置１００に放送サービスの複数の特定属性の変更に対して通知を要求することができる。このとき、連動装置２００は、放送サービスの複数の特定属性をリスト形式で要求することができる。
放送受信装置１００は、放送サービスに基づいて放送サービスの属性をシグナリングする情報を受信する(Ｓ２０６５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から放送サービスの属性をシグナリングする情報を受信することができる。
放送受信装置１００は、放送サービスの特定属性の変更可否を確認する(Ｓ２０６７)。具体的に、放送受信装置１００は、制御部１５０を介して放送サービスの特定属性の変更可否を確認することができる。具体的に、放送受信装置１００は、放送サービスの特定属性が以前に比べて変更されたかを判断することができる。具体的に、放送受信装置１００は、放送サービスの特定属性の以前値と現在値を比較して、放送サービスの特定属性の変更可否を判断することができる。
放送サービスの特定属性が変更された場合、放送受信装置１００は、連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの特定属性の変更可否を通知する(notify)(Ｓ２０６９)。具体的に、放送サービスの特定属性が変更された場合、放送受信装置１００は制御部１５０を介して連動装置２００に放送サービスの属性をシグナリングする情報に基づいて放送サービスの特定属性の変更可否を通知するすることができる。
連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求する(Ｓ２０７１)。具体的に連動装置２００は、制御部を介して放送受信装置１００に放送サービスの特定属性を要求することができる。具体的に、放送受信装置１００が放送サービスの特定属性変更通知を伝送した場合、連動装置２００は、放送受信装置１００に放送サービスの特定属性を要求することができる。具体的な連動装置２００の動作は、図３７の実施例と同一であってもよい。
放送受信装置１００は、連動装置２００に放送サービスの特定属性を通知する(Ｓ２０７３)。放送受信装置１００は、制御部１５０を介して連動装置２００に放送サービスの特定属性を通知ことができる。具体的に、放送受信装置１００は、連動装置２００の要求に基づいて放送サービスの特定属性を通知することができる。例えば、放送受信装置１００は、連動装置２００に連動装置２００が要求した放送サービスの特定属性を伝送することができる。
また、連動装置２００は、放送受信装置１００から放送サービスの特定属性を獲得するものではなく、図４２で説明したように、放送サービスの属性を獲得できるURLを獲得し、放送サービスの属性を獲得できるURLに基づいて放送サービスの特定属性を獲得することができる。このような動作により、放送受信装置１００が不必要に連動装置２００に放送サービスの属性変更を通知する動作を減らすことができる。
放送受信装置１００は、自然災害、テロ、戦争など災害状況に対する災難警報を放送網を介して受信することができる。また、放送受信装置１００は、これをユーザに通知することができる。これにより、国の災害状況に対して人々が迅速かつ効率的に把握することができる。但し、ユーザが放送受信装置１００を注視し続ける状況でなければ、このような災難警報を把握できない状況になる可能性がある。ユーザが放送受信装置１００を注視し続ける状況でなくても、ユーザは携帯電話、タブレットなどの連動装置２００を常に所持している確立が高い。従って、放送受信装置１００が連動装置２００に災難警報を伝送し、連動装置２００が災難警報を表示することができれば、国の災害状況をユーザに迅速かつ効率的に通知することができる。これについては、図４５〜図５７に基づいて説明する。
図４５は、本発明の一実施例により災難警報が生成され、放送網を介して伝送される過程を示す。
放送サービスを介した災難警報を管理する警報システムは、災難警報を発令する権限がある政府当局(authorities)がIPWS(Integrated Public Alert＆Warning System)を介して緊急状況を入力するか、他のソースを介して共通警報プロトコル(Common Alerting Protocol、CAP)に基づくメッセージを受信する。警報システムは、CAPメッセージが現在の地域に該当するかを判断する。CAPメッセージが現在の地域に該当する場合、放送信号にCAPメッセージを挿入する。従って、CAPメッセージは、放送信号を介して伝送される。放送受信装置１００が放送信号を受信して災難警報をユーザに伝送する動作については、図４６に基づいて説明する。
図４６は、本発明の一実施例により放送受信装置が放送網を介してシグナリングされる災難警報を抽出して表示することを示す。
放送伝送装置２００は、放送信号に基づいて災難警報テーブル(Emergency Alter Table、EAT)を抽出し、EATからのCAPメッセージを抽出することができる。また、放送伝送装置２００は、災難警報に関する追加情報を、EATが含む非リアルタイムサービス識別子に基づいて獲得することができる。具体的に、放送受信装置２００は、EATが含むEAS_NRT_service_idフィールドに基づいて、災難警報に関する追加情報を獲得することができる。具体的に、放送受信装置２００は、EATに含まれた非リアルタイムサービス識別子に基づいて、非リアルタイムサービスをシグナリングするテーブルから災難警報に関する追加情報を伝送するFLUTEセッションに関する情報を獲得することができる。このとき、非リアルタイムサービスをシグナリングするテーブルは、サービスマップテーブル(Service Map Table、SMT)であってもよい。放送受信装置２００は、FLUTEセッションに関する情報に基づいて、当該FLUTEセッションから災難警報に関する追加情報を受信することができる。放送受信装置２００は、災難警報を受信して放送サービス及び放送サービスのプログラムに関する情報を表示するサービスガイドに表示することができる。具体的に、放送受信装置２００は、ガイドアクセステーブル(Guide Access Table、GAT)からサービス識別子を抽出し、サービス識別子に該当する情報を、非リアルタイムサービスをシグナリングするテーブルから抽出して受信することができる。具体的な実施例において放送受信装置２００は、GATから抽出したサービス識別子に該当するサービスのFLUTEセッションに関する情報を獲得することができる。以後、放送受信装置２００は、FLUTEセッションに関する情報に基づいて災難警報メッセージを受信し、災難警報メッセージをサービスガイドに表示することができる。具体的なCAPメッセージの形式は、図４７と同一であってもよい。
放送受信装置１００が連動装置２００に伝送する具体的な動作については、図４８〜図５７に基づいて説明する。
放送受信装置１００が連動装置２００に伝送する具体的な動作については、図４８〜図５７に基づいて説明する。
図４８は、本発明の一実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を示す。
本発明の一実施例において災難警報の状態を示す変数は、災難警報を含む災難警報メッセージに関する情報を示す変数及び災難警報メッセージをすべて含む災難警報に関する情報を示す変数のうち少なくともいずれか１つを含むことができる。具体的に、放送受信装置１００が災難警報を受信した場合、放送受信装置１００は、連動装置１００に災難警報メッセージに関する情報を通知することができる。災難警報メッセージに関する情報については、図４９を参照して説明する。
図４９は、本発明の一実施例により放送受信装置がシグナリングする災難警報メッセージに関する情報を示す。
災難警報メッセージに関する情報は、災難警報のバージョン、災難警報メッセージの形式(format)、災難警報メッセージを受信した日付及び災難警報メッセージを受信した時間のうち少なくともいずれか１つを含むことができる。具体的に、災難警報メッセージの形式を示すmessageType、災難警報メッセージを受信した日付と災難警報メッセージを受信した時間を示すdateTime及び災難警報メッセージのバージョンを示すversionのうち少なくともいずれか１つを含むことができる。具体的な実施例において、災難警報を含むメッセージに関する情報は、図４９のようにXML形式であってもよい。但し、災難警報を含むメッセージの形式がこれに限定されるものではない。
図４８に戻って、本発明の一実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を説明する。
さらに、連動装置２００は、災難警報メッセージをすべて含む災難警報に関する情報をアクションを介して要求することができる。このとき、放送受信装置１００は、連動装置１００に災難警報に関する情報を含む変数を介して、災難警報メッセージをすべて含む災難警報に関する情報をシグナリングすることができる。具体的な実施例において災難警報の状態を示す変数は、EmergencyAlertとEmergencyAlertPropertyのうちいずれか１つを含むことができる。EmergencyAlertは、災難警報を含むメッセージに関する情報を含む。具体的な実施例においてEmergencyAlertは必須変数であり、ストリングデータタイプを有することができる。放送受信装置１００は、EmergencyAlertをUPnPのイベンティングプロトコルを利用して伝送することができる。具体的な実施例において放送受信装置１００は、災難警報を受信する場合、EmergencyAlertPropertyは災難警報に関する情報を含む。EmergencyAlertPropertyは必須変数であり、ストリングデータタイプを有することができる。具体的な実施例において災難警報メッセージをすべて含む災難警報に関する情報を要求するアクションは、GetAllEmergencyAlertMessageであってもよい。具体的な実施例においてGetAllEmergencyAlertMessageは必須アクションであってもよい。また、GetAllEmergencyAlertMessageは、EmergencyAlertPropertyを出力引数として有することができる。
放送受信装置１００と連動装置２００の動作については、図５０に基づいて説明する。
図５０は、本発明の一実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１０１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図３４の実施例と同一であってもよい。
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１０３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的に連動装置２００は、UPnPプロトコルを利用して、放送受信装置１００に災難警報受信通知を要求することができる。具体的な実施例において連動装置２００は、イベンティングプロトコルに基づいて放送受信装置１００に災難警報受信通知に対するイベントの購読(subscription)を要求することができる。
放送受信装置１００は、放送伝送装置３００から災難警報を含むメッセージを受信する(Ｓ２１０５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報メッセージを受信することができる。
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知する(notify)(Ｓ２１０７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に災難警報メッセージに関する情報を示す変数を介して災難警報メッセージに関する情報を通知することができる。具体的な実施例において災難警報メッセージに関する情報を示す変数は、図４９のEmergencyAlertであってもよい。
連動装置２００は、放送受信装置１００に災難警報に関する情報を要求する(Ｓ２１０９)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報を要求することができる。具体的な実施例において連動装置２００は、災難警報を要求するアクションを介して災難警報を要求することができる。具体的な実施例において災難警報を要求するアクションは、図４９のGetEmergencyAlertMessageであってもよい。
放送受信装置１００は、連動装置２００に災難警報メッセージをすべて含む災難警報に関する情報を通知する(Ｓ２１１１)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージをすべて含む災難警報に関する情報を通知することができる。但し、このような場合、災難警報メッセージをすべて受信しなければならないので、放送受信装置１００と連動装置２００の動作に負荷として作用する可能性がある。従って、連動装置２００に災難警報メッセージを効率的に伝送する方法が必要である。
放送受信装置１００は、災難警報メッセージから連動装置２００に必要な情報を抽出して伝送することができる。具体的な実施例において放送受信装置１００は、災難警報メッセージから災難警報を識別する識別子、災難警報のカテゴリーを示す情報、災難警報に関する説明を示す情報、災難警報に該当する地域を示す情報、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを抽出することができる。具体的な実施例において放送受信装置１００は、災難警報メッセージから災難警報を識別するエレメントであるidentifier、災難警報のカテゴリーを示すエレメントであるcategory、災難警報に関する説明を示すエレメントであるdescription、災難警報に該当する地域を示すエレメントであるareaDesc、災難警報の緊急度を示すエレメントであるurgency、災難警報を誘発した災害の深刻性を示すエレメントであるseverity及び災難警報を誘発した災害の発生確率を示すエレメントであるcertainityのうち少なくともいずれか１つを抽出することができる。
連動装置２００は、災難警報の優先度(priority)を判断し、災難警報の優先度に基づいて動作することができる。災難警報の優先度を判断する方法については、図５１〜図５３に基づいて説明する。
図５１〜図５３は、本発明の一実施例により放送受信装置が災難警報の優先順位を判断する基準を示す。
連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のそれぞれの値に基づいて区分することができる。このとき、連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のうち最も高い優先度を有する値に基づいて災難警報の優先度を判断することができる。具体的な実施例において連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報が有する値に応じて、３つの緊急度に区分することができる。例えば、連動装置２００は、図５２の実施例のように、UrgencyエレメントがImmediateまたはExpectedに該当する場合に最も高い優先度、Futureに該当する場合に最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度、Pastに該当する場合に最も低い優先度、Unknownに該当する場合に初期値に該当する優先度を有すると判断することができる。このとき、初期値は、最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度であってもよい。また、連動装置２００は、図５２の実施例のように、SeverityエレメントがExtremeまたはSevereに該当する場合に最も高い優先度、Moderateに該当する場合に最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度、Minorに該当する場合に最も低い優先度、Unknownに該当する場合に初期値に該当する優先度を有すると判断することができる。このとき、初期値は、最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度であってもよい。また、連動装置２００は、図５２の実施例のように、CertaintyエレメントがVery likelyまたはlikelyに該当する場合に最も高い優先度、Possibleに該当する場合に最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度、Unlikelyに該当する場合に最も低い優先度、Unknownに該当する場合に初期値に該当する優先度を有すると判断することができる。このとき、初期値は、最も高い優先度より優先度が低く、最も低い優先度より優先度が高い中間優先度であってもよい。
他の実施例において連動装置２００は、災難警報の優先度を、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のそれぞれの値に基づいてポイントを与え、ポイントの合計に応じて災難警報の優先度を判断することができる。具体的な実施例において連動装置２００は、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報に同じ比重でポイントを与えることができる。例えば、連動装置２００は、図５３の実施例のように、UrgencyエレメントがImmediateに該当する場合に５、Expectedに該当する場合に４、Futureに該当する場合に３、Pastに該当する場合に２、Unknownに該当する場合に１のポイントを与えることができる。また、連動装置２００は、図５３の実施例のようにSeverityエレメントがExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に１のポイントを与えることができる。また、連動装置２００は、図５３の実施例のようにCertaintyエレメントがVery likelyに該当する場合に５、likelyに該当する場合に４、Possibleに該当する場合に３、Unlikelyに該当する場合に２、Unknownに該当する場合に１ポイントを与えることができる。このとき、連動装置２００は、ポイントの合計が１０以上１５以下である場合、災難警報が最も高い優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が５以上１０以下である場合、災難警報が最も高い優先度より低く、最も低い優先度より高い中間優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が０以上５以下である場合、災難警報が最も低い優先度を有すると決定することができる。
他の具体的な実施例において連動装置２００は、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報にそれぞれ異なる比重でポイントを与えることができる。例えば、連動装置２００は、図５４の実施例のようにUrgencyエレメントがImmediateに該当する場合に９、Expectedに該当する場合に８、Futureに該当する場合に７、Pastに該当する場合に５、Unknownに該当する場合に０のポイントを与えることができる。また、連動装置２００は、図５４の実施例のように、SeverityエレメントがExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に０のポイントを与えることができる。また、連動装置２００は、図５４の実施例のように、CertaintyエレメントがVery likelyに該当する場合に６、likelyに該当する場合に５、Possibleに該当する場合に４、Unlikelyに該当する場合に３、Unknownに該当する場合に０のポイントを与えることができる。このとき、連動装置２００は、ポイントの合計が１０以上１５以下である場合、災難警報が最も高い優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が５以上１０以下である場合、災難警報が最も高い優先度より低く、最も低い優先度より高い中間優先度を有すると決定することができる。また、連動装置２００は、ポイントの合計が０以上５以下である場合、災難警報が最も低い優先度を有すると決定することができる。
連動装置２００は、災難警報の優先度に基づいて災難警報を表示することができる。具体的な実施例において連動装置２００は、災難警報の優先度に基づいて、災難警報によるアラーム音、アラームの持続時間、アラームの回数及び災難警報の表示時間のうち少なくともいずれか１つを異なるようにすることができる。例えば、連動装置２００は、災難警報の優先度が高いほどアラーム音を大きくすることができる。また、連動装置２００は、災難警報の優先度が高いほどアラームを長い時間維持することができる。
図５０〜図５１に基づいて説明した本発明の一実施例によれば、放送受信装置１００は、連動装置２００に災難警報メッセージをすべて伝送しなければならない。しかし、連動装置２００は、災難警報メッセージのうちの一部情報のみを必要とすることがある。従って、放送受信装置２００は、災難警報メッセージのうち連動装置２００が必要とする一部情報のみを伝送する放送受信装置２００の動作方法が必要である。これについては、図５４〜図５５に基づいて詳しく説明する。
図５４は、本発明の他の実施例により放送受信装置がシグナリングする災難警報の状態を示す変数、災難警報のためのアクション及びアクションの引数(argument)を示す。
連動装置２００は、放送受信装置１００に災難警報に関する情報を要求するとともに獲得することを希望する災難警報の特定情報を指定することができる。災難警報の特定情報は、災難警報メッセージに含まれた複数の情報のうち１つまたは複数の情報からなることができる。このとき、放送受信装置１００は、連動装置２００に災難警報に関する特定情報を伝送することができる。このために、連動装置２００は、災難警報に関する特定情報を要求するアクションを利用することができる。このとき、アクションは、災難警報に関する特定情報を識別する変数を入力引数として有することができる。具体的な実施例において連動装置２００が獲得することを希望する災難警報の特定情報を示す変数は、EmergencyAlertFieldであってもよい。具体的な実施例においてEmergencyAlertFieldは必須変数であり、ストリングデータタイプを有することができる。災難警報に関する特定情報を要求するアクションは、GetEmergencyAlerMessageであってもよい。GetEmergencyAlerMessageは必須アクションであり、EmergencyAlertFieldを入力引数として有することができる。放送受信装置１００と連動装置２００の具体的な動作は、図５５に基づいて説明する。
図５５は、本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
図５５は、本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１２１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５０の実施例と同一であってもよい。
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１２３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５０の実施例と同一であってもよい。
放送受信装置１００は、放送サービスに基づいて災難警報を含む災難警報メッセージを受信する(Ｓ２１２５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報を含む災難警報メッセージを受信することができる。
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知する(notify)(Ｓ２１２７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報を通知することができる。また、具体的な実施例において放送受信装置１００は、連動装置２００に災難警報メッセージに関する情報を示す変数を介して災難警報メッセージ情報を通知することができる。具体的な実施例において放送受信装置１００は、連動装置２００に災難警報メッセージに関する情報を示す変数を介して災難警報メッセージに関する情報を通知することができる。具体的な実施例において災難警報メッセージを示す変数は、図４９のEmergencyAlertであってもよい。
連動装置２００は、放送受信装置１００に災難警報に関する特定情報を要求する(Ｓ２１２９)。連動装置２００は、制御部を介して放送受信装置１００に災難警報に関する特定情報を要求することができる。このとき、災難警報に関する特定情報は、連動装置２００が災難警報に関する付加機能を提供するために必要な災難警報に関する情報からなることができる。具体的な実施例において連動装置２００は、放送受信装置１００に災難警報メッセージから災難警報を識別する識別子、災難警報のカテゴリーを示す情報、災難警報に関する説明を示す情報、災難警報に該当する地域を示す情報、災難警報の緊急度を示す情報、災難警報を誘発した災害の深刻性を示す情報及び災難警報を誘発した災害の発生確率を示す情報のうち少なくともいずれか１つを要求することができる。例えば、連動装置２００は、放送受信装置１００に災難警報メッセージから災難警報を識別するエレメントであるidentifier、災難警報のカテゴリーを示すエレメントであるcategory、災難警報に関する説明を示すエレメントであるdescription、災難警報に該当する地域を示すエレメントであるareaDesc、災難警報の緊急度を示すエレメントであるurgency、災難警報を誘発した災害の深刻性を示すエレメントであるseverity及び災難警報を誘発した災害の発生確率を示すエレメントであるcertainityのうち少なくともいずれか１つを要求することができる。具体的な実施例において連動装置２００は、放送受信装置１００に図５４のGetEmergencyAlertMessageアクションとEmergencyAlertFieldを利用して、災難警報に関する特定情報を要求することができる。
放送受信装置１００は、災難警報メッセージに基づいて災難警報に関する特定情報を抽出する(Ｓ２１３１)。具体的に、放送受信装置１００は、制御部１５０を介して災難警報メッセージに基づいて災難警報に関する特定情報を抽出することができる。具体的に、放送受信装置１００は、制御部１５０を介して災難警報メッセージから災難警報に関する特定情報を抽出することができる。
放送受信装置１００は、連動装置２００に災難警報に関する特定属性を通知する(Ｓ２１３３)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報に関する特定属性を通知することができる。具体的に、放送受信装置１００は、連動装置２００の要求に基づいて災難警報に関する特定属性を通知することができる。
但し、放送受信装置１００が複数の連動装置２００と連動する場合、放送受信装置１００が、連動装置２００が必要とする災難警報に関する特定情報を直接伝送することは放送受信装置１００の動作に過負荷を誘発する可能性がある。従って、放送受信装置１００の負荷を軽減させることができる連動装置２００に対する災難警報シグナリング方法が必要である。これについては、図５６に基づいて説明する。
図５６は、本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１４１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５５の実施例と同一であってもよい。
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１４３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５５の実施例と同一であってもよい。
放送受信装置１００は、放送サービスに基づいて災難警報を含む災難警報メッセージを受信する(Ｓ２１４５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報を含む災難警報メッセージを受信することができる。
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関する情報を獲得できるURLを通知する(notify)(Ｓ２１４７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関する情報を獲得できるURLを通知することができる。
連動装置２００は、災難警報に関する情報を獲得できるURLに基づいて災難警報に関する情報を獲得する(Ｓ２１４９)。具体的に連動装置２００は、制御部を介して災難警報に関する情報を獲得できるURLに基づいて災難警報に関する情報を獲得することができる。具体的に連動装置２００は、災難警報に関する情報を獲得できるURLに基づいてコンテンツ/シグナリングサーバ４００から災難警報に関する情報を獲得することができる。具体的に連動装置２００は、災難警報に関する情報を獲得できるURLに基づいて災難警報に関する情報をコンテンツ/シグナリングサーバに要求し、コンテンツ/シグナリングサーバ４００から災難警報に関する情報を獲得することができる。これにより、放送受信装置１００と連動装置２００との間の通信から発生しうる放送通信装置１００の負荷を軽減することができる。
放送受信装置１００が連動装置２００に災難警報を表示できるユーザインターフェース(User Interface、UI)を伝送する場合、連動装置２００の災難警報を処理するための負荷を軽減することができる。これについては、図５７に基づいて説明する。
図５７は、本発明の他の実施例により放送受信装置が連動装置に災難警報をシグナリングする動作を示すラダーダイアグラムである。
放送受信装置１００と連動装置２００は、ペアリング(pairing)セッションを生成する(Ｓ２１６１)。具体的に、放送受信装置１００は、IP通信部１３０を介して連動装置２００とのペアリングセッションを生成することができる。具体的に連動装置２００は、通信部を介して放送受信装置１００とのペアリングセッションを生成することができる。前述したように、放送受信装置１００と連動装置２００は、双方向通信のためのペアリングセッションを生成することができる。具体的な放送受信装置１００と連動装置２００の動作は、図５６の実施例と同一であってもよい。
連動装置２００は、放送受信装置１００に災難警報受信通知を要求する(Ｓ２１６３)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報受信通知を要求することができる。具体的な連動装置２００の動作は、図５６の実施例と同一であってもよい。
放送受信装置１００は、放送サービスに基づいて災難警報を含む災難警報メッセージを受信する(Ｓ２１６５)。具体的に、放送受信装置１００は、放送受信部１１０を介して放送伝送装置３００から災難警報を含む災難警報メッセージを受信することができる。
放送受信装置１００は、連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関するUI情報を通知する(notify)(Ｓ２１６７)。具体的に、放送受信装置１００は、制御部１５０を介して連動装置２００に災難警報メッセージに基づいて災難警報メッセージに関する情報及び災難警報に関するUI情報を通知することができる。このとき、災難警報に関するUI情報は、災難警報に関するUIのリストを含むことができる。
連動装置２００は、放送受信装置１００に災難警報に関するUI情報に基づいて災難警報に関するUIを要求する(Ｓ２１６９)。具体的に連動装置２００は、制御部を介して放送受信装置１００に災難警報に関するUI情報に基づいて災難警報に関するUIを要求することができる。
放送受信装置１００は、連動装置２００の要求に基づいて連動装置２００に災難警報に関するUIを獲得できるURIを伝送する(Ｓ２１７１)。放送受信装置１００は、制御部１５０を介して連動装置２００の要求に基づいて連動装置２００に災難警報に関するUIを獲得できるURIを伝送することができる。
連動装置２００は、災難警報に関するUIを獲得できるURIに基づいて災難警報に関するUIを表示する(Ｓ２１７３)。連動装置２００は、制御部を介して災難警報に関するUIを獲得できるURIに基づいて災難警報に関するUIを表示することができる。具体的に連動装置２００は、災難警報に関するUIを獲得できるURIに基づいてUIを獲得することができる。このとき、連動装置２００は、外部のサーバから災難警報に関するUIを獲得することができる。例えば、連動装置２００は、災難警報に関するUIのための画像ファイル、HTMLファイル及びXMLファイルのうち少なくともいずれか１つを外部のサーバから受信することができる。このとき、外部のサーバは、コンテンツ/シグナリングサーバ４００であってもよい。他の具体的な実施例において連動装置２００は、災難警報に関するUIを予め格納し、格納したUIのうちURIに該当するUIを呼び出すことができる。また、連動装置２００は、このような動作により獲得した災難警報に関するUIを表示することができる。このような動作により、連動装置２００が災難警報を処理するので、発生する連動装置２００の負荷を軽減することができる。
図５８は、本発明の一実施例に係る放送サービスの伝送階層を示す。
放送伝送装置３００は、複数の層で構成された放送信号を介して放送サービスを伝送することができる。放送サービスを伝送するための複数の層のうち、物理的媒体(physical medium)を介してRAW放送信号を送受信するための伝送層を物理層(physical layer)ということができる。この時、物理的媒体は、銅線(Cooper)または光ファイバー(Optical fiber)からなることができる。放送伝送装置３００は、一つまたは複数の周波数上に一つ以上の物理層パイプ(Physical Layer Pipe、PLP)を介して、放送サービスと放送サービス関連データを伝送することができる。一つの周波数上に複数の物理層パイプが存在してもよい。この時、PLPは、物理層(physical layer)上で識別可能な一連の論理的データ伝達経路である。PLPは、データパイプ(data pipe)等他の用語で称されることがある。一つの放送サービスは、複数のコンポーネントを含むことができる。この時、複数のコンポーネントのそれぞれは、オーディオ、ビデオ及びデータコンポーネントのうちいずれか一つである。各放送局は、放送伝送装置３００を介してカプセル化(encapsulation)された放送サービスを一つまたは複数のPLPを介して伝送することができる。具体的に、放送局は、放送伝送装置３００を介して一つのサービスに含まれた複数のコンポーネントを複数のPLPで伝送することができる。または、放送局は、放送伝送装置３００を介して一つのサービスに含まれた複数のコンポーネントを一つのPLPで伝送することができる。例えば、図５８の実施例で、第１放送局(Broadcast #１)は、放送伝送装置３００を介してシグナリング情報を一つのPLP(PLP #０)を介して伝送することができる。また、図５８の実施例で、第１放送局(Broadcast #１)は、放送伝送装置３００を介して第１放送サービスに含まれた第１コンポーネント(Component １)及び第２コンポーネント(Component ２)を相互異なる第１PLP(PLP #１)と第２PLP(PLP #２)を介して伝送する。また、図５８の実施例で、第N放送局(Braoadcast #N)は、第１放送サービス(Service #１)に含まれた第１コンポーネント(Component １)及び第２コンポーネント(Component ２)を第N PLP(PLP #N)を介して伝送する。この時、リアルタイム放送サービスは、IP、UDP(User Datagram Protocol)及びリアルタイムコンテンツを伝送するためのプロトコル、例えばリアルタイム伝送プロトコル(Realtime Transport Protocol、RTP)のうちのいずれか一つにカプセル化できる。非リアルタイムコンテンツ及び非リアルタイムデータである場合にも、IP、UDP及びコンテンツ伝送プロトコル、例えばFLUTEのうちの少なくともいずれか一つのパケットにカプセル化できる。従って、放送伝送装置３００が伝送する物理層フレーム内には、一つ以上のコンポーネントを伝達する複数のPLPを含むことができる。従って、放送受信装置１００は、放送サービス連結情報を獲得する放送サービスをスキャンするために、複数のPLPを全部確認しなければならないこともある。従って、放送受信装置１００が放送サービススキャンを効率的にできるようにする放送伝送方法及び放送受信方法が必要である。
本発明の一実施例に係る放送システムでは、災難警報メッセージ(Emergency Alert Message)を送受信する放送伝送装置３００、放送伝送装置３００の動作方法、放送受信装置１００及び放送受信装置１００の動作方法を提案する。この時、災難警報メッセージは、放送視聴者に緊急状況を知らせるための災難警報情報を放送網を介して伝送可能な形態に変換したものをいう。また、獲得した災難警報に対する情報を基に、これを処理する放送受信装置１００及び放送受信装置１００の動作方法を提案する。災難警報情報の伝達は、通常政府が主導して運用しており、放送システムが適用される国家によって、細部的な構造は可変できる。従って、本発明の一実施例では、災難警報情報を放送網を介して伝送する方法において、共通して適用可能な災難警報メッセージの構成方法及びこれに対する送受信に対して提案する。
図５９は、本発明の一実施例に係る災難警報システムの全体構成を示すブロック図である。
図５９に示すように、本発明の一実施例に係る災難警報システム(Emergency Alert System)は、警報当局６００(Alert Authorities)、放送伝送装置３００(例えば、放送会社)、放送受信装置１００及び情報収集装置７００を含むことができる。
警報当局６００は、国家または当該地域の関係機関を含むことができる。警報当局６００は、災難警報情報の伝送が放送網を介して伝達されなければならない場合、災難警報を発生させ、これを情報収集装置７００(または機関)に伝達する。この時、情報収集装置７００は、IPAWSアグリゲータ(IPAWS aggregator、Integrated Public Alert Warning System)からなることができる。
情報収集装置７００は、放送網を介して伝達する災難警報情報をCAP(Common Alerting Protocol)ベースのメッセージに構成して放送伝送装置３００に伝達する。ここで、CAPは、非常事態を警告し、情報を交換するためのXMLファイルフォーマットである。CAPは、警告メッセージを複数の災難警報システムを介して同時に伝播することができる。以下、本発明の一実施例では、放送伝送装置３００にCAPメッセージが伝達された以後の過程を中心に説明する。
CAPメッセージが放送伝送装置３００に伝達されると、当該メッセージを処理する放送伝送装置３００は、関連したオーディオ/ビデオコンテンツ及び付加サービスをCAPメッセージと一緒に伝送する。具体的に、放送伝送装置３００は、関連オーディオ/ビデオコンテンツまたは付加サービスをCAPメッセージと一緒に放送信号に挿入して放送受信装置１００に伝送する。一実施例で、CAPメッセージを含む災難警報関連データは、それぞれの目的と形態に応じて他の経路を介して伝送できる。具体的な例として、他の経路は、シグナリングチャネル(Signaling Channel)、データパイプ(Data Pipe)及びブロードバンド(Broadband)のいずれか一つからなることができる。
放送受信装置１００は、放送伝送装置３００から災難警報関連データが含まれた放送信号を受信する。そして、放送受信装置１００は、災難警報シグナリングデコーダを介して受信された放送信号をデコーディングする。この時、災難警報シグナリングデコーダは、図３０のシグナリングデコーダ１５１からなることができる。
放送受信装置１００は、放送信号をデコーディングして獲得した情報に応じて、オーディオ/ビデオサービスを受信する。具体的に、放送受信装置１００は、放送信号からオーディオ/ビデオサービスを伝送する物理層パイプ(physical layer pipe)情報を獲得することができる。この時、物理層パイプは、物理層フレームに含まれたデータ単位である。そして、放送受信装置１００は、物理層パイプを介して、災難警報メッセージに関連したオーディオ/ビデオサービスデータを受信することができる。
また、放送受信装置１００は、放送信号をデコーディングして獲得した情報から災難警報に関連した非リアルタイムサービス情報を抽出することができる。具体的に、非リアルタイムサービス情報は、非リアルタイムサービスを獲得できるアドレス情報であってもよい。例えば、非リアルタイムサービスがブロードバンドを介して伝達され、アドレス情報は非リアルタイムサービスを獲得するためのURI情報であってもよい。
図６０は、本発明の一実施例に係る放送サービスを支援するためのプロトコルスタック(protocol stack)を示す。
本発明の一実施例に係る放送サービスは、視聴覚データ(Auido/Video、A/V)だけでなく、HTML５アプリケーション、双方向サービス、ACRサービス、セカンドスクリーン(second screen)サービス、個人化(personalization)サービスなどの付加サービスを提供することができる。
このような放送サービスは、地上波、ケーブル衛星などの放送信号である物理層(physical layer)を介して伝送できる。また、本発明の一実施例に係る放送サービスは、インターネット通信網(broadband)を介して伝送できる。
放送サービスが、地上波、ケーブル衛星などの放送信号である物理層(physical layer)を介して伝送される場合、放送受信装置１００は、カプセル化(encapsulation)されたMPEG-２伝送ストリーム(Transport Stream、TS)とカプセル化されたIPデータグラムを放送信号を復調(demodulation)して抽出することができる。放送受信装置１００は、IPデータグラムからUDP(User Datagram Protocol)データグラムを抽出することができる。放送受信装置１００は、UDPデータグラムからシグナリング情報を抽出することができる。この時、シグナリング情報はXML形態であってもよい。また、放送受信装置１００は、UDPデータグラムから非同期層コーディング/層コーディング伝送(Asynchronous Layered Coding/Layered Coding Transport、ALC/LCT)パケットを抽出することができる。放送受信装置１００は、ALC/LCTパケットから単方向ファイル伝送(File Delivery over Unidirectional Transport、FLUTE)パケットを抽出することができる。この時、FLUTEパケットは、リアルタイムオーディオ/ビデオ/字幕データ、非リアルタイム(Non-Real Time、NRT)データと電子サービスガイド(Electronic Service Guide、ESG)データを含むことができる。また、放送受信装置１００は、UDPデータグラムからリアルタイム伝送プロトコル(例えば、Real-time Transport Protocol、RTCP)パケット及びRTP制御プロトコル(RTP Control Protocol、RTCP)パケットを抽出することができる。放送受信装置１００は、RTP/RTCPパケットのようなリアルタイム伝送パケットからA/Vデータ及び付加データを抽出することができる。この時、NRTデータ、A/Vデータ及び付加データのうち少なくともいずれか一つは、 ISO BMFF(ISO Base Media File Formatの形態であってもよい。また、放送受信装置１００は、MPEG-２ TSパケットまたはIPパケットからNRTデータ、A/V、PSI/PSIPのようなシグナリング情報を抽出することができる。この時、シグナリング情報は、XMLまたはバイナリ形態であってもよい。
放送サービスがインターネット通信網(broadband)を介して伝送される場合、放送受信装置１００は、インターネット通信網からIPパケットを受信することができる。放送受信装置１００は、IPパケットからTCPパケットを抽出することができる。放送受信装置１００は、TCPパケットからHTTPパケットを抽出することができる。放送受信装置１００は、HTTPパケットからA/V、付加データ、シグナリング情報などを抽出することができる。この時、A/V及び付加データのうち少なくとも一つは、ISO BMFF形態であってもよい。また、シグナリング情報は、XML形態であってもよい。
本発明の一実施例で、放送伝送装置３００は、災難警報メッセージをプロトコルスタックに含まれたプロトコル層を介して伝送することができる。この場合、当該プロトコル層は、リンク層(Link Layer)であってもよい。一実施例で、放送伝送装置３００は、災難警報メッセージを伝送プロトコルに応じてテーブル形態にフォーマットすることができる。この時、プロトコルスタックに含まれたリンク層で災難警報メッセージがテーブル形態にフォーマットされる。また、災難警報メッセージは、リンク層及び物理層の動作をシグナリングする情報を含むことができる。
また、他の実施例では、放送伝送装置３００は、災難警報メッセージを伝送プロトコルに応じてパケット化することができる。具体的に、放送伝送装置３００は、災難警報メッセージを伝送パケットにカプセル化することができる。この場合、災難警報情報が放送受信装置１００に多数の階層を経てシグナリングされることを防止することができる。
災難警報メッセージは、伝送のために放送システムで伝送可能な形態に構成されなければならない。このために、一実施例で、災難警報メッセージを伝送するためのセクションテーブル(Section Table)が一般的に用いられる。また、他の実施例で、災難警報メッセージは、ディスクリプタ形態の構成で他のセクションテーブルの一部分に伝送されてもよい。また、他の実施例で、災難警報メッセージは、物理層のパケットに伝送されてもよい。具体的に、災難警報メッセージは、物理層パイプを介してパケットの形態に伝送できる。この場合、災難警報メッセージは、パケットに含まれたパケットペイロードに含まれて伝送できる。災難警報メッセージを含むパケットを識別するための情報は、パケットヘッダに含まれてもよい。また、災難警報メッセージを含むパケットを識別するための情報は、拡張されたヘッダに含まれてもよい。この時、拡張されたヘッダは、パケットヘッダに含まれた追加的なフィールドであってもよい。
図６１は、災難警報テーブル(EAT、Emergency Alert Table)のためのシンタックスを示す。この時、災難警報テーブルは、災難警報メッセージの一形態であってもよい。図６１に示すように、EAT情報は、EATが有するプロトコルのバージョン情報を含むことができる。具体的な実施例で、当該情報は、EAT_protocol_versionフィールドであってもよい。
また、EAT情報は、放送受信装置１００に自動でチャネルの転換を行うかどうかを知らせる情報を含むことができる。例えば、EAT情報は、放送受信装置１００に災難警報に関する詳しい情報を知らせるチャネルに自動で転換を行うかどうかを知らせる情報を含むことができる。具体的な実施例で、チャネル自動転換を行うかどうかを知らせる情報は、automatic_tuning_flagフィールドであってもよい。
また、EAT情報は、EATに含まれているメッセージに対する個数情報を含むことができる。具体的な実施例で、メッセージ個数情報は、num_EAS_messageフィールドであってもよい。
図６２は、災難警報メッセージのためのシンタックスを示す。本発明の一実施例に係る災難警報メッセージは、CAPメッセージを直接含むことができる。また、他の実施例で、災難警報メッセージは、CAPメッセージが伝達される経路の情報を含むことができる。
図６２に示すように、本発明の一実施例に係る災難警報メッセージは、災難警報メッセージ(EAS message)を区別するための識別子情報を含むことができる。具体的な実施例で、識別子情報は、EAS_message_idフィールドであってもよい。この場合、EAS_message_idフィールドは３２ビットであってもよい。
また、災難警報メッセージのためのシンタックスは、IPのバージョンを示す情報を含むことができる。この場合、バージョン情報は、EAS_IP_version_flagフィールドであってもよい。具体的な実施例で、EAS_IP_version_flagフィールドの値が０である場合、IPバージョンがIPv４であることを示す。また、他の実施例で、EAS_IP_version_flagフィールドの値が１である場合、IPバージョンがIPv６であることを示す。EAS_IP_version_flagフィールドは１ビットであってもよい。
また、災難警報メッセージは、EASメッセージの伝達形態を示す情報を含むことができる。この場合、EASメッセージ伝達形態を示す情報は、EAS_message_transfer_typeフィールドであってもよい。EAS_message_transfer_typeフィールドは３ビットであってもよい。
具体的な実施例で、EAS_message_transfer_typeフィールドは、EASメッセージの伝達形態が特定されていないことを示す。この場合、EAS_message_transfer_typeフィールドは、０００(2)の値を有することができる。
また、他の実施例で、EAS_message_transfer_typeフィールドは、EASメッセージの伝達形態が警報メッセージを含んでいない形態であることを示す。即ち、放送信号を介して伝送される災難警報テーブル(EAT)が警報メッセージなしに、オーディオ/ビデオコンテンツに対する情報のみを含むことを示す。この場合、EAS_message_transfer_typeフィールドは、００１(2)の値を有することができる。
また、他の実施例で、EAS_message_transfer_typeフィールドは、EASメッセージがEATに含まれて伝達されることを示す。この場合、EAS_message_transfer_typeフィールドは、０１０(2)の値を有することができる。
また、EAS_message_transfer_typeフィールドが０１０(2)の値を有する場合、EASメッセージを含むテーブルは、EASメッセージの長さを示すことができる。この場合、EASメッセージの長さを示す情報は、EAS_message_lengthフィールドであってもよい。EAS_message_lengthフィールドは１２ビットであってもよい。また、EAS_message_transfer_typeフィールドが０１０(2)の値を有する場合、EASメッセージを含むテーブルはEASメッセージに対する情報を追加的に含むことができる。
また、他の実施例で、EAS_message_transfer_typeフィールドは、EASメッセージがIPデータグラムの形態でデータパイプを介して伝送されることを示す。この場合、EAS_message_transfer_typeフィールドは、０１１(2)の値を有することができる。また、EAS_message_transfer_typeフィールドが０１１(2)の値を有する場合、災難警報メッセージを含むテーブルは、IPデータグラムを獲得できるIPアドレス情報、UDPポート情報及び伝送される物理層フレームの情報のうちいずれか一つを追加的に含むことができる。
また、災難警報メッセージは、EASメッセージのエンコーディングタイプを示す情報を含むことができる。この場合、EASメッセージのエンコーディングタイプの情報は、EAS_message_encoding_typeフィールドであってもよい。EAS_message_encoding_typeフィールドは３ビットであってもよい。
具体的な実施例で、EAS_message_encoding_typeフィールドは、EASメッセージのエンコーディングタイプが特定されていないことを示す。この場合、EAS_message_encoding_typeフィールドは、０００(2)の値を有することができる。
また、他の実施例で、EAS_message_encoding_typeフィールドは、EASメッセージがエンコーディングされていないことを示す。この場合、EAS_message_encoding_typeフィールドは、００１(2)の値を有することができる。
また、他の実施例で、EAS_message_encoding_typeフィールドは、EASメッセージがDEFLATEアルゴリズムによってエンコーディングされたことを示す。DEFLATEアルゴリズムは無損失圧縮データフォーマットである。この場合、EAS_message_encoding_typeフィールドは、０１０(2)の値を有することができる。
また、災難警報メッセージは受信されるEASメッセージに関連したNRT(Non-real time)コンテンツ及び付加データに対する情報が災難警報テーブルに含まれているのか否かを示すことができる。この場合、NRTコンテンツ及び付加データの存在の有無を示す情報は、EAS_NRT_flagフィールドであってもよい。EAS_NRT_flagフィールドは１ビットであってもよい。
具体的な実施例で、EAS_NRT_flagフィールドが０に設定された場合、受信されたEASメッセージに関連したNRTコンテンツ情報が災難警報テーブルに含まれていないことを示す。また、他の実施例で、EAS_NRT_flagフィールドが１に設定された場合、受信されたEASメッセージに関連したNRTコンテンツ情報がテーブルに含まれたことを示す。
図６３は、自動チャネル転換情報(Automatic Channel Tuning Information)のためのシンタックスを示す。自動チャネル転換情報は、災難警報メッセージと一緒に、関連オーディオ/ビデオコンテンツが同時に伝送される場合、関連オーディオ/ビデオコンテンツが伝送されるチャネルに自動転換させるための情報を含む。即ち、自動チャネル転換情報は、現在の放送受信装置１００に表示されているチャネルが災難警報メッセージを含むコンテンツを含んでいない場合、関連オーディオ/ビデオコンテンツが伝送されるチャネルに自動転換するための情報であってもよい。具体的な実施例で、図６１のautomatic_tuning_flagフィールドがイネーブルされる場合に、災難警報テーブルが自動チャネル転換情報を含むことができる。例えば、automatic_tuning_flagフィールドが１の値を有する場合、災難警報テーブルが自動チャネル転換情報含むことができる。
一実施例で、自動チャネル転換情報のためのテーブルは、転換されるべきチャネル番号に対する情報を示すことができる。具体的に、災難警報情報に関連したコンテンツを含むチャネルに対する情報を示すことができる。この場合、転換されるべきチャネル番号情報は、automatic_tuning_channel_numberフィールドであってもよい。具体的な実施例で、automatic_tuning_channel_numberフィールドは８ビットであってもよい。
また、他の実施例で、自動チャネル転換情報のためのテーブルは、災難警報メッセージに関連したコンテンツを受信するための経路情報を示すことができる。具体的に、自動チャネル転換情報のためのテーブルは、災難警報メッセージに関連したオーディオ/ビデオコンテンツが含まれた物理層フレームを識別するための情報を示すことができる。この場合、当該情報は、automatic_tuning_DP_idフィールドであってもよい。automatic_tuning_DP_idフィールドは８ビットであってもよい。
また、他の実施例で、自動チャネル転換情報のためのテーブルは、災難警報メッセージに関連したコンテンツの識別情報を示すことができる。具体的に、災難警報メッセージに関連したコンテンツのサービスID情報を示すことができる。この場合、当該情報は、automatic_tuning_service_idフィールドであってもよい。automatic_tuning_service_idフィールドは１６ビットであってもよい。
図６４は、NRTサービス情報のためのシンタックスを示す。ここで、NRTサービス情報は、災難警報メッセージに関連したNRTデータを獲得するための情報を含む。図６２のEAS_NRT_flagフィールドがイネーブルされる場合に、NRTサービス情報がEATに含まれてもよい。例えば、EAS_NRT_flagフィールドが１の値を有する場合、NRTサービス情報がEATに含まれてもよい。
NRTサービス情報は、災難警報メッセージに関連したNRTコンテンツ及びデータが放送受信装置１００に伝送される場合、当該NRTサービスに対する識別子情報を含む。この時、NRTサービスに対する識別子情報は、EAS_NRT_service_idフィールドであってもよい。EAS_NRT_service_idフィールドは１６ビットであってもよい。
図６５〜図６６は、災難警報メッセージを伝送するためのセクションテーブルに対する一実施例を示す。図６５に示されたセクションテーブルの構成のうちの一部フィールドは、放送システムとの互換のために、既存のATSC M/H標準で用いるフィールドをそのまま用いたり、災難警報メッセージを伝送するために一部フィールドを追加することもできる。また、追加された一部フィールドは、実際放送システムに適用する場合、最適化過程を経てフィールドが有するビット数及びフィールドの順番調整が可能である。
図６７〜図６８は、災難警報テーブルを物理層パイプを介してパケット形態で伝送することを示す。
一般的に、放送パケットは、当該パケットを介して伝送しようとするデータが挿入されたパケットペイロード及びパケットペイロードをシグナリングするための情報が挿入されたパケットヘッダで構成される。従って、本発明の一実施例により放送伝送装置は、伝送しようとする災難警報メッセージをパケットのペイロードに挿入し、災難警報メッセージをシグナリングするための情報をパケットのヘッダに挿入することができる。
図６７は、上述した災難警報テーブルの形態を変更せず、そのままパケットのペイロードで構成した一実施例を示す。図６７に示すように、パケットペイロードに災難警報テーブルがそのまま含まれ、追加的に災難警報テーブルのための識別子及び災難警報テーブルの長さ情報が含まれる。
また、パケットヘッダは、パケットのタイプを示す情報を含むことができる。一実施例で、パケットタイプ情報は、パケットのペイロードが災難警報をシグナリングするためのデータを含んでいることを示す。具体的な実施例で、パケットタイプを示す情報は１１０(2)であってもよい。
また、パケットヘッダは、パケットのペイロード含まれたシグナリングデータのタイプを示す情報を含むことができる。一実施例で、シグナリングデータタイプ情報は、当該シグナリングデータがセクションテーブル形態であることを示す。具体的な実施例で、シグナリングデータタイプ情報が００(2)の値を有する場合、シグナリングデータタイプ情報は、当該シグナリングデータがセクションテーブル形態であることを示す。
図６８は、パケットペイロードに災難警報メッセージがセクションテーブルの形態ではなく、個別情報に挿入される一実施例を示す。この時、セクションテーブルは、最終テーブルを構成するための中間形式を指す。具体的に、放送受信装置１００は、パケットを収集してセクションテーブルを構成することができ、放送受信装置１００は、セクションテーブルを再収集して最終テーブルを構成することができる。従って、図６８の実施例は、災難警報メッセージに含まれたそれぞれのフィールドを別途のパケットにパケット化することを示す。従って、放送受信装置１００は、一つ以上のパケットを収集してセクションテーブルを構成する必要なく、一つのパケットから完成された情報を獲得することができる。例えば、一つのパケットペイロードが、EATプロトコルバージョン情報のみを、または、自動チャネル転換情報のみを含んだ場合である。
この場合、パケットのタイプを示す情報は、パケットのペイロードが、災難警報をシグナリングするためのデータを含んでいることを示す。この場合、パケットのタイプを示す情報は、１１０(2)に設定されてもよい。また、シグナリングのタイプを示す情報は、パケットペイロードに含まれたデータが個別情報の形態であることを示す。この場合、シグナリングのタイプを示す情報は１０(2)に設定されてもよい。
また、図６７と異なり、パケットペイロードに含まれた災難警報のためのデータが異なることがあり、パケットヘッダはこれを識別するための情報を追加的に含むことができる。当該情報はInfo Typeフィールドであってもよい。
具体的な実施例で、Info Typeフィールドが０００(2)値を有する場合、パケットペイロードに含まれた災難警報のためのデータは、災難警報メッセージであってもよい。また、他の実施例で、Info Typeフィールドが００１(2)値を有する場合、パケットペイロードに含まれた災難警報のためのデータは、自動チャネル転換情報であってもよい。また、他の実施例で、Info Typeフィールドが０１０(2)値を有する場合、パケットペイロードに含まれた災難警報のためのデータは、NRTサービス情報であってもよい。
以下、図６９〜図７５は、災難警報テーブル(EAT、Emergency Alert Table)を伝送する多様な実施例を示す。具体的な実施例で、EATを伝送する物理層パイプ(PLP)は、実施例によって異なる。これに対して、図６９〜図７５を介して説明するようにする。本発明の一実施例により、放送伝送装置３００が災難警報情報を物理層パイプを介して伝達する場合、放送受信装置１００が物理層から直接災難警報情報を抽出することができる。結果的に、災難警報情報を放送受信装置１００が速かに獲得することができる。
図６９は、本発明の一実施例として、放送伝送装置３００が災難警報メッセージを指定された物理層パイプを介して伝送することを示す。指定された物理層パイプを介して伝送される災難警報メッセージは、EAT及び伝送パケットのうち少なくともいずれか一つである。
一実施例で、放送伝送装置３００は、災難警報メッセージを指定された物理層パイプ(dedicated physical layer pipe)を介して伝送することができる。この時、災難警報メッセージを伝送するために指定された物理層パイプを災難警報チャネル(EAC、Emergency Alert Channel)ということができる。即ち、災難警報チャネルは、災難警報メッセージのみを伝送するための専用物理層パイプであってもよい。ここで、物理層パイプとは、物理層フレームを介して伝送するデータの単位である。物理層は、一つ以上の物理層フレームを含むことができ、物理層フレームを介して物理層パイプが伝送される。以下、本実施例を図６９を参照してより詳しく説明する。
放送伝送装置３００は、警報当局６００等から収集した災難警報情報に基づいて災難警報テーブル(EAT)を生成する。ここで、放送伝送装置３００が受信した災難警報情報は、情報収集装置７００から受信したCAPメッセージであってもよい。
ここで、指定された物理層パイプは、上述したように、災難警報テーブルのみを伝送する災難警報チャネルであってもよい。放送伝送装置３００は、生成された災難警報テーブルを含んで放送信号を生成する。具体的に、放送信号は、災難警報テーブルを含む伝送パケットを含むことができる。そして、放送伝送装置３００は、災難警報チャネルが含まれた放送信号を伝送する。具体的に、放送伝送装置３００は、災難警報テーブルを含む伝送パケットのみのために指定された物理層パイプを介して放送信号を伝送することができる。
放送受信装置１００は、指定された物理層パイプを介して放送信号を受信する。上述したように、物理層パイプは、物理層内で災難警報情報のみを伝送するために指定された物理層パイプであってもよい。指定された物理層パイプは、災難警報チャネルであってもよい。放送受信装置１００は、指定された物理層パイプから災難警報テーブルを抽出することができる。また、放送受信装置１００は、物理層に災難警報チャネルが含まれているのか否かを示す情報を物理層から獲得することができる。この時、物理層に災難警報チャネルが含まれているのか否かを示す情報は、PHY signalingと称することができる。放送受信装置１００は、PHY signalingに基づいて災難警報情報を伝送するデータパイプを判断することができる。
放送受信装置１００は、災難警報テーブルを含む物理層パイプをデコーディングする。物理層パイプは、図３０に示されたシグナリングデコーダ１５１を介してデコーディングできる。この時、放送受信装置１００は、物理層パイプからCAPメッセージ、関連コンテンツ情報及び関連NRTサービス情報を獲得することができる。
放送受信装置１００は、獲得したCAPメッセージをパッシング(parsing)して災難警報情報を獲得することができる。具体的な実施例で、CAPパーサーがCAPメッセージをパッシングすることができる。CAPパーサーは、図３０に示された警報シグナリングパーサー１６８であってもよい。
この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００がEATを構成する過程で調整することができる。
放送受信装置１００は、獲得した関連コンテンツ情報に基づいてオーディオ/ビデオコンテンツを受信することができる。具体的に、獲得した関連コンテンツ情報は、オーディオ/ビデオコンテンツを伝送する物理層パイプを識別するための情報であってもよい。また、関連コンテンツ情報は、関連オーディオ/ビデオコンテンツを識別するための情報であってもよい。
放送受信装置１００は、関連コンテンツ情報に基づいて関連コンテンツを含む物理層パイプを識別する。そして、放送受信装置１００は、識別された物理層パイプをデコーディングして、オーディオ/ビデオコンテンツを獲得する。この時、関連コンテンツを伝送する物理層パイプは、災難警報情報を伝送する物理層パイプと区別される。また、放送受信装置１００は、獲得したNRTサービス情報に基づいて災難警報情報に関連したNRTサービスを獲得することができる。具体的に、放送受信装置１００は、NRTサービス情報からNRTサービスを獲得できるアドレス情報を獲得することができる。この時、放送受信装置１００は、NRTサービスをブロードバンドを介して受信することができる。
放送受信装置１００は、獲得した災難警報メッセージをオーディオ/ビデオコンテンツと一緒に提供する。もし、自動チャネル転換に対する情報が一緒に伝送される場合、放送受信装置１００は、チャネルを自動変更しながら災難警報メッセージを提供することができる。
図７０〜図７１は、本発明の一実施例として、放送伝送装置３００が災難警報テーブルをパケットにカプセル化して伝送することを示す。災難警報テーブルを含むパケットを災難警報パケットと称することができる。
一実施例で、放送信号の物理層に含まれた物理層パイプは、複数個存在してもよい。また、放送信号の物理層に含まれた複数の物理層パイプを介して伝送される複数の放送サービスに対する具体的な情報を伝送する別途の物理層パイプが存在してもよい。この時、放送サービス情報を伝送する別途の物理層パイプは、基本データパイプ(base data pipe)ということができる。具体的に、放送伝送装置３００は、基本データパイプを介して放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送することができる。ここで、シグナリング情報または共用データは、物理層を介して伝送される物理層パイプをシグナリングする情報または物理層パイプに共通して適用されるデータであってもよい。図７０は、一実施例として、放送伝送装置３００が災難警報テーブルを基本データパイプを介して伝送することを示す。
放送伝送装置３００は、警報当局６００等から収集した災難警報情報をカプセル化して、物理層を介して伝送するパケットを生成する。この時、災難警報情報がカプセル化されたパケットは、災難警報パケット(Emergency Alert Packet)ということができる。ここで、放送伝送装置３００が受信した災難警報情報は、情報収集装置７００から受信したCAPメッセージであってもよい。
一実施例で、災難警報パケットは、パケットヘッダ及びパケットペイロードを含むことができる。具体的な実施例で、パケットペイロードは、災難警報テーブル(EAT)をそのまま含むことができる。また、他の実施例で、パケットペイロードは、災難警報テーブル内の一部情報のみを含むこともできる。ここで、一部情報とは、災難警報テーブルにおける重要度が高い一部情報であってもよい。
また、パケットヘッダは、パケットペイロードに含まれたデータが災難警報情報であることを示す情報を含むことができる。また、パケットヘッダは、伝送パケットが災難警報情報を含んでいることを示す。具体的に、パケットヘッダは、一般的なパケットと異なるタイプの情報を含み、伝送パケットが災難警報情報を含んでいることを示す。即ち、パケットヘッダは、伝送パケットが災難警報パケットであることを示す。
放送伝送装置３００は、災難警報テーブルがカプセル化されたパケットを放送サービスに対するシグナリング情報または共用データを伝送する物理層パイプを介して伝送する。即ち、放送伝送装置３００は、災難警報パケットを基本データパイプを介して伝送する。この場合、基本データパイプは、物理層パイプの一形態として、他の物理層パイプ(またはデータパイプ)と区別される。
一方、基本データパイプを含む物理層は、物理層内基本データパイプが存在することをシグナリングする情報を伝送することができる。この時、基本データパイプの存在をシグナリングする情報は、PHY signalingといえる。放送受信装置１００は、PHY signalingに基づいて受信された放送信号の物理層に基本データパイプが存在することを確認することができる。そして、放送受信装置１００は、物理層パイプの一形態である基本データパイプを介して、災難警報情報を獲得することができる。この時、獲得した災難警報情報は、災難警報パケットの形態であってもよい。放送受信装置１００は、基本データパイプを介して放送信号を受信する。即ち、放送受信装置１００は、災難警報パケットを基本データパイプを介して受信する。
放送受信装置１００は、受信された放送信号から災難警報パケットが含まれた物理層パイプを抽出することができる。この時、災難警報パケットを含む物理層パイプは、基本データパイプであってもよい。そして、放送受信装置１００は、抽出された物理層パイプをデコーディングして災難警報情報獲得することができる。具体的に、物理層パイプに含まれた災難警報パケットをデコーディングして災難警報情報を獲得することができる。
この時、災難警報パケットは、災難警報テーブルが挿入されたパケットペイロード及びパケットペイロードをシグナリングするパケットヘッダを含むことができる。具体的な実施例で、放送受信装置１００は、パケットヘッダから当該パケットが災難警報情報を含んでいるのか否かを判断することができる。即ち、放送受信装置１００は、パケットヘッダから抽出した情報に基づいて、当該パケットが災難警報パケットであるのか否かを判断することができる。
また、放送受信装置１００は、パケットヘッダからパケットペイロードに含まれた災難警報情報の形態を判断することができる。例えば、パケットペイロードが全体災難警報テーブルを含んでいるのか否かを判断することができる。
放送受信装置１００は、パケットヘッダから獲得した情報に基づいて、パケットペイロードから災難警報情報を獲得する。ここで、獲得した災難警報情報は、災難警報テーブルまたはCAPメッセージであってもよく、関連コンテンツ情報またはNRTサービス情報であってもよい。
放送受信装置１００は、獲得したCAPメッセージをパッシングして災難警報情報を獲得することができる。この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００が、EATを構成する過程で重複する部分を省略することができる。以下、災難警報情報に基づいて関連サービスを獲得する過程は、上述した内容と同じであるので省略する。
図７１は、本発明の一実施例として、放送伝送装置３００が災難警報テーブルを一般物理層パイプ(Normal Physical Layer Pipe)を介して伝送することを示す。ここで、一般物理層パイプは、用途が指定されていない物理層パイプであってもよい。
本実施例は、図７０の実施例とは異なり、物理層に基本データパイプが含まれていない場合として、図７０と比較して差異点を中心に以下説明する。
本実施例で、放送伝送装置３００は、災難警報情報をカプセル化しながら、パケットヘッダを一般的なパケットヘッダと異なるように構成する。具体的に、放送伝送装置３００は、パケットヘッダに含まれたパケットタイプを示す値を異なるように設定することができる。例えば、一般的なパケットは当該値を０００(2)に、災難警報パケットは１１０(2)に値を設定して、それぞれのパケットを区別することができる。
一方、物理層パイプを含む物理層は、物理層内の物理層パイプをシグナリングする情報を伝送することができる。この時、物理層パイプをシグナリングする情報は、PHY signalingといえる。放送受信装置１００は、PHY signalingに基づいて受信された物理層に含まれた物理層パイプの情報を獲得することができる。図７１の実施例で、放送受信装置１００は、物理層に含まれた複数の物理層パイプを介して、災難警報を含むパケット及び放送コンテンツを含むパケットを受信することができる。また、放送受信装置１００は、災難警報を含むパケットから災難警報情報を獲得することができる。また、放送受信装置１００は、災難警報情報に基づいて災難警報に関連した放送コンテンツを伝送する他の物理層パイプを識別することができる。また、放送受信装置１００は、災難警報情報に基づいて災難警報に関連した非リアルタイムコンテンツを受信できる経路情報を獲得することができる。
図７２〜図７５は、本発明の一実施例として、放送伝送装置３００が災難警報情報を、物理層パイプの他の一形態を介して伝送することを示す。この場合、物理層パイプの他の一形態は、放送信号の物理層に含まれた放送サービスをスキャンするための物理層パイプであってもよい。具体的に、放送伝送装置３００は、物理層パイプを介して放送サービスをスキャンするためのサービスシグナリング情報を、他の層を経ずに放送信号の物理層に直接伝送することができる。この時、放送サービスをスキャンするための物理層パイプは、シグナリングチャネルといえる。放送受信装置１００は、シグナリングチャネルから放送ストリームの構成情報、簡略な放送サービス情報及びコンポーネント情報のうち少なくともいずれか一つを獲得することができる。具体的な実施例で、シグナリングチャネルは、FIC(Fast Information Channel)及びLLS(Low Layer Signaling)のいずれか一つからなることができる。
本発明の一実施例で、放送伝送装置３００は、シグナリングチャネルを介して、CAPメッセージをベースにする災難警報メッセージを伝送することができる。本実施例は、図７２〜図７３を参照してより詳しく説明する。
本発明の他の実施例で、放送伝送装置３００は、シグナリングチャネルを介して、災難警報を指示する最小限の情報のみを伝送し、実際の災難警報メッセージ(例えば、災難警報テーブル(EAT))は、シグナリングチャネルと区別される物理層パイプを介して伝送することができる。本実施例は、図７４〜図７５を参照してより詳しく説明する。
図７２は、シグナリングチャネルを介して、災難警報メッセージを直接伝送する内容を示す。
放送伝送装置３００は、警報当局６００等から収集した災難警報情報に基づいて災難警報テーブル(EAT)を生成する。ここで、放送伝送装置３００が受信した災難警報情報は、情報収集装置７００から受信したCAPメッセージであってもよい。
放送伝送装置３００は、生成された災難警報テーブルを含む放送信号を生成する。具体的に、災難警報テーブルは、放送信号の物理層パイプの一形態であるシグナリングチャネルを介して伝送できる。この時、シグナリングチャネルは、図６９の実施例で説明した指定されたシグナリングチャネルではなく、一般的なシグナリングチャネルを指すことができる。そして、放送伝送装置３００は、シグナリングチャネルを介して災難警報情報が含まれた放送信号を伝送する。
放送受信装置１００は、シグナリングチャネルを介して受信した放送信号から災難警報情報を獲得することができる。具体的に、獲得した災難警報情報は、災難警報テーブルであってもよい。具体的に、放送受信装置１００は、シグナリングチャネルをデコーディングする。この時、放送受信装置１００は、シグナリングチャネルからCAPメッセージ、関連コンテンツ情報及び関連NRTサービス情報を獲得することができる。
放送受信装置１００は、獲得したCAPメッセージをパッシングして災難警報情報を獲得することができる。この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００がEATを構成する過程で重複する部分を省略することができる。以下、災難警報情報に基づいて関連サービスを獲得する過程は、上述した内容と同じであるので省略する。
図７３は、図７２の実施例に係るシグナリングチャネルを介して伝送される災難警報メッセージのためのシンタックスを示す。具体的な実施例で、災難警報メッセージは、シグナリングチャネルを介して伝送されるテーブルの一部分であってもよい。また、図７３に示されたフィールドは、以降必要に応じて変更することができる。
災難警報メッセージのためのテーブルは、当該災難警報テーブル内に災難警報関連シグナリングが含まれているのか否かを示すことができる。具体的に、災難警報関連シグナリングが含まれているのか否かを示す情報は、Emergency_alert_flagフィールドであってもよい。
一実施例で、emergency_alert_flagフィールドが０の値を有する場合、災難警報テーブルが災難警報情報を含まないことを示す。また、emergency_alert_flagフィールドが１の値を有する場合、災難警報テーブルが災難警報情報を含むことを示す。
例えば、emergency_alert_flagフィールドがイネーブルされた場合、災難警報メッセージのためのテーブルは、災難警報メッセージに関連したフィールドを含むことができる。また、災難警報メッセージのためのテーブルは、自動チャネル転換に関連したフィールドも含むことができる。
図７４は、シグナリングチャネルを介して、災難警報情報の伝達経路のみを伝送する内容を示す。
放送伝送装置３００は、警報当局６００等から収集した災難警報情報を伝送可能な形態にシグナリングする。具体的に、放送伝送装置３００は、災難警報情報(例えば、CAPメッセージ及び関連データ)をテーブル、ディスクリプタまたはパケットに構成することができる。この時、放送伝送装置３００が別途の災難警報シグナリングのみのためのモジュールを含んでいない場合、一般的なシグナリングモジュールを介して、災難警報情報を伝送可能な形態にシグナリングすることができる。
放送伝送装置３００は、災難警報情報と一緒に、災難警報メッセージを伝送するのか否かに対する情報及び災難警報メッセージが伝送される経路に対する情報を、テーブルまたはテーブルを含む伝送パケットに挿入することができる。この時、災難警報メッセージを伝送するのか否か及び伝送経路に対する情報は、災難警報インジケータ(Emergency Alert Indicator)ということができる。テーブルまたはテーブルを含む伝送パケットに含まれたディスクリプタは、災難警報インジケータを含むことができる。また、テーブルは、災難警報インジケータを一つのフィールドとして含むことができる。災難警報インジケータが含む情報は、必要に応じて個別フィールドとして含まれてもよく、優先順位に応じて優先順位が高い情報のみ含んでもよい。ここで、優先順位は、災難警報メッセージの伝送にともなう重要度に応じて、それぞれの情報別に決定されてもよい。
放送伝送装置３００は、災難警報インジケータ及び関連データをシグナリングチャネルを介して伝送する。また、放送伝送装置３００は、災難警報に関連した情報をシグナリングチャネルではなく、物理層パイプを介して伝送することができる。この時、シグナリングチャネルではなく、物理層パイプは一般物理層パイプということができる。
また、放送伝送装置３００が伝送する災難警報関連データは、物理層パイプから災難警報情報を獲得するための経路情報であってもよい。具体的に、災難警報関連データは、災難警報情報を伝送する一般物理層パイプ(データパイプ)を識別するための情報であってもよい。
放送受信装置１００は、シグナリングチャネルを介して災難警報インジケータ及び関連データを受信する。また、物理層は、放送信号の物理層に災難警報情報を伝送するシグナリングチャネルが存在するのか否かを示す情報を含むことができる。この時、シグナリングチャネルの存在の有無を示す情報は、PHY signalingといえる。放送受信装置１００は、PHY signalingに基づいて物理層内シグナリングチャネルの存在の有無を確認し、シグナリングチャネルから災難警報インジケータ及び関連データを受信する。
放送受信装置１００は、災難警報シグナリングデコーダを介してシグナリングチャネルをデコーディングし、シグナリングチャネルから災難警報インジケータ及び関連データを獲得することができる。
放送受信装置１００は、シグナリングチャネルから獲得した災難警報インジケータ及び関連データに基づいて、災難警報メッセージの伝達経路情報を獲得する。具体的に、放送受信装置１００は、災難警報インジケータから災難警報メッセージが伝送される物理層パイプの情報を獲得することができる。具体的に、放送受信装置１００は、災難警報インジケータから災難警報メッセージを伝送する物理層パイプを識別する識別情報を獲得することができる。
放送受信装置１００は、災難警報インジケータに基づいて識別した物理層パイプを介して伝送されたパケットをデコーディングする。
具体的な実施例で、放送受信装置１００は、パケットヘッダに基づいて、当該パケットが災難警報情報を含んでいるのか否かを判断することができる。また、放送受信装置１００は、パケットヘッダからパケットペイロードに含まれた災難警報情報の形態を判断することができる。例えば、放送受信装置１００は、パケットペイロードが全体災難警報テーブルを含んでいるのか否かを判断することができる。
放送受信装置１００は、パケットヘッダから獲得した情報に基づいて、パケットペイロードから災難警報情報を獲得する。ここで、獲得した災難警報情報は、災難警報テーブルまたはCAPメッセージであってもよく、関連コンテンツ情報またはNRTサービス情報であってもよい。
放送受信装置１００は、獲得したCAPメッセージをパッシングして災難警報情報を獲得することができる。この場合、放送受信装置１００は、災難警報情報と一緒に、関連NRTサービス情報を獲得することができる。EAT及びCAPメッセージの間の重複する情報がある場合、放送伝送装置３００がEATを構成する過程で重複する部分を省略することができる。
放送受信装置１００は、獲得した関連コンテンツ情報に基づいてオーディオ/ビデオコンテンツを受信することができる。具体的に、獲得した関連コンテンツ情報は、オーディオ/ビデオコンテンツを伝送するデータパイプを識別するための情報であってもよく、関連オーディオ/ビデオコンテンツを識別するための情報であってもよい。放送受信装置１００は、関連コンテンツ情報に基づいてオーディオ/ビデオコンテンツを伝送するデータパイプを識別する。そして、放送受信装置１００は、識別されたデータパイプを介してオーディオ/ビデオコンテンツを獲得し、獲得したオーディオ/ビデオコンテンツのうち災難警報情報に関連するコンテンツを獲得することができる。この時、コンテンツを伝送する物理層パイプは、災難警報情報を伝送する物理層パイプと区別される。また、放送受信装置１００は、獲得したNRTサービス情報に基づいて災難警報情報に関連したNRTサービスを獲得することができる。具体的に、NRTサービス情報からNRTサービスを獲得できるアドレス情報を獲得することができる。この時、放送受信装置１００は、NRTサービスをブロードバンドを介して受信することができる。
放送受信装置１００は、獲得した災難警報メッセージをオーディオ/ビデオコンテンツと一緒に提供することができる。例えば、自動チャネル転換に対する情報が災難警報メッセージと一緒に伝送される場合、放送受信装置１００はチャネルを自動変更しながら災難警報メッセージを提供することができる。
図７５は、図７４の実施例に係るシグナリングチャネルを介して伝送される災難警報をシグナリングするためのシンタックスの例である。具体的な実施例で、災難警報メッセージは、シグナリングチャネルを介して伝送されるテーブルの一部分であってもよい。また、図７５に示されたフィールドは、以降必要に応じて変更することができる。
災難警報をシグナリングするためのテーブルは、当該災難警報テーブル内に災難警報関連データが含まれているのか否かを示すことができる。具体的に、災難警報関連データが含まれているのか否かを示す情報は、Emergency_alert_flagフィールドであってもよい。一実施例で、emergency_alert_flagフィールドが０の値を有する場合、現在のシグナリングチャネルまたはテーブルに災難警報のためのデータが含まれていないことを示す。また、emergency_alert_flagフィールドが１の値を有する場合、現在の災難警報テーブルに災難警報のためのデータが含まれていることを示す。
例えば、emergency_alert_flagフィールドがイネーブルされた場合、災難警報テーブルは、災難警報情報に関連したフィールドを含むことができる。また、災難警報テーブルは、自動チャネル転換に関連したフィールドも含むことができる。
災難警報をシグナリングするためのテーブルは、当該テーブルがシグナリングする災難警報メッセージを受信できる物理層パイプ情報を含むことができる。この場合、物理層パイプ情報は、EAS_DP_idフィールドであってもよい。具体的にEAS_DP_idフィールドは、災難警報メッセージを伝達する放送信号内のデータパイプを識別するための情報であってもよい。
図７６は、本発明の一実施例に係る放送伝送装置３００の動作方法を示すフローチャートである。
放送伝送装置３００は、警報当局６００から災難警報情報を受信する(Ｓ１０１)。ここで、警報当局６００は、災難管理当局、関係機関のうちいずれか一つである。また、放送伝送装置３００は、災難警報情報を情報収集装置７００を介して受信することもできる。この場合、放送伝送装置３００は、CAPメッセージに加工された災難警報情報を受信することができる。
放送伝送装置３００は、受信した災難警報情報に基づいて、災難警報情報を含むテーブルまたは災難警報テーブルを含む災難警報パケットを生成する(Ｓ１０３)。具体的に、放送伝送装置３００の制御部は、災難警報情報を伝送する物理層パイプに応じて災難警報テーブルまたは災難警報パケットを生成することができる。
一実施例で、制御部は、災難警報情報を指定された物理層パイプを介して伝送する場合、災難警報情報を含む災難警報テーブルを生成することができる。この場合、第１実施例で、災難警報テーブルは、災難警報情報を全部含むことができる。また、第２実施例で、災難警報テーブルは、災難警報情報の一部のみを含むことができる。ここで、災難警報情報の一部は、全体災難警報情報を伝送するための最小限の情報のみを含むことができる。
また、他の実施例で、放送伝送装置３００の制御部は、災難警報情報をパケット伝送するための物理層パイプを介して伝送する場合、災難警報情報をパケットにカプセル化することができる。災難警報情報がカプセル化されたパケットは、災難警報パケットと称することができる。一実施例で、放送伝送装置３００の制御部は、災難警報情報をパケットのペイロードにカプセル化することができる。また、他の実施例で、制御部は、災難警報テーブルをパケットのペイロードにカプセル化することができる。
また、放送伝送装置３００の制御部は、パケットペイロードのデータを識別するための情報をパケットのヘッダにカプセル化することができる。また、パケットのヘッダにカプセル化される情報は、当該パケットが災難警報情報を含んでいるパケットであることを知らせる情報であってもよい。
放送伝送装置３００の制御部は、生成された災難警報テーブルまたは災難警報パケットを物理層パイプに挿入する(Ｓ１０５)。具体的に制御部は、災難警報テーブルまたは災難警報パケットを物理層パイプに挿入する。この時、物理層は、物理層が災難警報情報を含んでいることを示す情報を含むことができる。
災難警報情報が物理層パイプに挿入されると、放送伝送装置３００は、物理層パイプを含む放送信号を伝送する(Ｓ１０７)。一実施例で、物理層パイプは、災難警報情報のみを伝送するために指定された物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送ストリームの構成情報、簡略な放送サービス情報及びコンポーネント情報のうち少なくともいずれか一つを含むサービスをスキャンするために必要な情報を伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、用途が指定されていない一般物理層パイプであってもよい。
図７７は、本発明の一実施例に係る放送受信装置１００の動作方法を示すフローチャートである。
放送受信装置１００は、物理層パイプを介して、災難警報情報を含む放送信号を放送受信部１１０を介して受信する(Ｓ２０１)。一実施例で、物理層パイプは、災難警報情報のみを伝送するために指定された物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、放送ストリームの構成情報、簡略な放送サービス情報及びコンポーネント情報及びコンポーネント情報のうち少なくともいずれか一つを伝送する物理層パイプであってもよい。また、他の実施例で、特定物理層パイプは、用途が指定されていない一般物理層パイプであってもよい。
放送受信装置１００の制御部１５０は、受信された放送信号から災難警報情報が含まれた伝送パケットを抽出する(Ｓ２０３)。一実施例で、伝送パケットは、災難警報テーブルを含むことができる。この場合、災難警報テーブルは、災難警報情報を獲得するための最小限の情報のみを含むこともできる。また、他の実施例で、伝送パケットは、災難警報パケットを含むことができる。放送受信装置１００の制御部１５０は、抽出した伝送パケットをデコーディングして災難警報情報を獲得する(Ｓ２０５)。即ち、制御部１５０は伝送パケットから災難警報情報を抽出する。具体的に、伝送パケットに含まれた災難警報テーブルまたは災難警報パケットをデコーディングして災難警報情報を獲得する。一実施例で、制御部１５０は、災難警報テーブルの特定情報または災難警報パケットのヘッダに基づいて伝送パケットをデコーディングすることができる。また、他の実施例で、放送受信装置１００は、災難警報テーブルをデコーディングして獲得した情報に基づいて伝送パケットをデコーディングすることができる。具体的に、災難警報テーブルから災難警報情報を伝送する物理層パイプを識別し、識別された物理層パイプを介して受信した伝送パケットをデコーディングすることができる。
放送受信装置１００の制御部１５０は、獲得した災難警報情報に関連サービス情報が含まれているのか否かを判断する(Ｓ２０７)。具体的に、制御部１５０は、災難警報情報に関連した関連コンテンツの情報が含まれているのか否かを判断する。ここで、関連コンテンツは、リアルタイムコンテンツ及び非リアルタイムコンテンツのうちいずれか一つである。
例えば、関連コンテンツが存在すると判断した場合、放送受信装置１００の制御部１５０は、獲得した関連コンテンツ情報がリアルタイムコンテンツであるのか否かを判断する(Ｓ２０９)。具体的に、災難警報情報に関連したコンテンツがリアルタイムコンテンツであるのか非リアルタイムコンテンツであるのかを判断する。ここで、リアルタイムコンテンツは、オーディオ/ビデオコンテンツであってもよい。リアルタイムコンテンツであるのか否かの判断は、災難警報テーブルの特定情報によって判断することができる。または、パケットヘッダに含まれた情報によって判断することができる。
関連コンテンツをリアルタイムコンテンツであると判断した場合、制御部１５０は、コンテンツを伝送する物理層パイプを介して関連コンテンツを獲得する(Ｓ２１１)。具体的に、災難警報情報が関連コンテンツを獲得できる経路情報を含むことができる。従って、制御部１５０は、当該情報に基づいて関連コンテンツを伝送する物理層パイプを識別してコンテンツを獲得することができる。
しかし、関連コンテンツを非リアルタイムコンテンツであると判断した場合、制御部１５０は、非リアルタイムコンテンツを獲得するための経路情報を抽出する(Ｓ２１５)。非リアルタイムコンテンツを獲得するための情報は、アドレス情報であってもよい。例えば、URI情報であってもよい。
放送受信装置１００は、抽出した経路情報に基づいて、IPコミュニケーションユニット１３０を介して非リアルタイムサービスを獲得する(Ｓ２１７)。具体的に、放送受信装置１００は、アドレス情報を利用してブロードバンドを介して非リアルタイムサービスを獲得する。
放送受信装置１００は、獲得した災難警報情報を関連サービスと一緒に提供する(Ｓ２１３)。具体的に、放送受信装置１００は、災難警報情報を関連サービスと一緒に出力する。この時、関連サービスは、リアルタイムサービス及び非リアルタイムサービスのうちのいずれか一つである。
上述したように、放送伝送装置３００は、災難警報情報を放送網を介して放送受信装置１００に伝送することができる。具体的な実施例で、放送受信装置１００は、モバイル放送受信装置であってもよい。また、モバイル放送受信装置は、独立的に放送信号を放送伝送装置３００から受信でき、上述したように放送伝送装置３００を経て受信する連動装置２００であってもよい。
この時、一般的に放送受信装置１００は、災難警報情報を含む放送信号を受信するためにウェイクアップ(wake up)状態とスリップ(sleep)状態を繰り返し、フレーム毎に放送信号を確認することができる。ここで、ウェイクアップ状態とは、物理層を介して伝送される放送信号が災難警報情報を含むのか否かを感知する放送受信装置１００の状態であってもよい。即ち、放送受信装置の災難警報情報感知機能が活性化状態であってもよい。逆に、スリップ状態は、放送信号から災難警報情報を感知しない放送受信装置１００の状態をいう。即ち、放送受信装置の災難警報情報感知機能が非活性化された状態であってもよい。
しかし、この場合、放送受信装置１００は、放送信号に災難警報情報がない場合にも、周期的にウェイクアップして不必要な電力及びリソース消耗が発生する可能性がある。これを補完するために、放送伝送装置３００が放送網を介して放送受信装置１００に災難警報情報を確認できる情報を一緒に伝送することができる。具体的に、放送伝送装置３００が放送受信装置１００に災難警報情報を感知(detection)できる時間情報を伝送することができる。ここで、時間情報は、連動装置がウェイクアップされる時間に対する情報であってもよい。従って、放送受信装置１００が一定時間の間ウェイクアップされて災難警報情報を感知した後、再びスリップ状態に戻ることができる。結果的に、放送受信装置１００が毎フレーム単位別にウェイクアップして災難警報情報を確認する必要がないので、不必要な電力及びリソース消耗を減らすことができる。
図７８は、放送伝送装置３００が放送受信装置１００に伝送する感知時間周期テーブルのためのシンタックスである。
図７８に示すように、感知周期テーブルは、感知開始時間情報を含むことができる。具体的に、感知開始時間情報は、災難警報情報の感知を始める開始時間情報であってもよい。即ち、感知開始時間情報は、放送受信装置１００がウェイクアップされる時間情報であってもよい。具体的な実施例で、感知開始時間情報は、ミリ秒単位で表現することができる。また、感知開始時間情報は、detection_start_timeフィールドであってもよい。detection_start_timeフィールドは３２ビットであってもよい。
また、感知周期テーブルは、感知持続時間情報を含むことができる。具体的に、感知周期テーブルは、放送受信装置１００の状態が災難警報情報を感知するためにウェイクアップされた場合、ウェイクアップ状態が維持される時間情報を含むことができる。具体的な実施例で、感知持続時間情報は、ミリ秒単位の１０進数で表現することができる。また、感知持続時間情報は、detection_durationフィールドであってもよい。detection_durationフィールドは３２ビットであってもよい。
また、感知周期テーブルは、スリップ持続時間情報を含むことができる。具体的に感知周期テーブルは、放送受信装置１００の状態が災難警報を感知しないスリップ状態に維持される時間情報を含むことができる。具体的な実施例で、スリップ持続時間情報は、detection_sleep_durationフィールドであってもよい。また、detection_sleep_durationフィールドは３２ビットであってもよい。
図７９は、感知周期情報に応じた放送受信装置１００の動作の実施例を示す。図７９に示すように、放送受信装置１００は、災難警報情報と一緒に伝達された感知周期情報に含まれた感知開始時間によってウェイクアップ状態となる。即ち、放送受信装置１００は、感知周期情報を受信した時間を基準時間として、感知開始時間情報に応じてウェイクアップ状態となることができる。この場合、感知開始時間情報は、感知周期情報を受信した時間を基準とした相対的な時間情報である。
放送受信装置１００は、ウェイクアップ状態で、感知持続時間情報に応じてウェイクアップ状態を維持する。この場合、感知持続時間情報は、感知開始時間情報を基準とした相対的な時間情報である。
そして、放送受信装置１００は、感知持続時間が経過するとスリップ状態に戻る。スリップ状態は、スリップ持続時間情報に応じて維持される。この場合、スリップ持続時間情報は、スリップ状態に変更された時点を基準とする相対的な時間であってもよい。
一方、本発明の実施例で、感知開始時間情報は、放送受信装置１００の最初のウェイクアップ時のみに用いられてもよい。以降は、感知持続時間情報及びスリップ持続時間情報に応じて、放送受信装置１００の状態が変更する。また、他の実施例で、連動装置は、追加的な感知周期情報が受信されない場合、既存の感知周期情報に応じて状態を変更することができる。この場合、放送受信装置１００の状態維持周期を変更するために、放送伝送装置３００は、新たな感知周期情報を放送受信装置１００に伝送することができる。
図８０は、感知周期情報が追加された災難警報テーブルのシンタックスを示す。
図８０に示すように、災難警報テーブル(EAT)は、当該テーブルに感知周期情報が含まれているのか否かを示すことができる。この時、感知周期情報が含まれているのか否かを示す情報は、detetion_interval_flagフィールドであってもよい。具体的な実施例で、detetion_interval_flagフィールドがイネーブルされる場合、当該テーブルが感知周期情報を含んでいることを示す。例えば、detetion_interval_flagフィールドが１の値を有する場合、detetion_interval_flagフィールドがイネーブルされることに設定することができる。
例えば、detetion_interval_flagフィールドがイネーブルされる場合、災難警報テーブルは、感知周期情報を含むことができる。反面、detetion_interval_flagフィールドがイネーブルされない場合(例えば、detetion_interval_flagフィールドが０の値を有する場合)、災難警報テーブルは、感知周期情報を含まなくてもよい。
図８１は、災難警報情報及び感知周期情報がシグナリングチャネルに含まれる場合に対する実施例を示す。具体的な実施例で、シグナリングチャネルは、FIC(Fast Information Channel)であってもよい。
図８０で説明したこと同様に、シグナリングチャネルは、感知周期情報が含まれているのか否かを示す情報を含むことができる。そして、当該情報に応じて感知周期情報を含むことができる。
一方、放送伝送装置３００が感知周期情報を任意に設定することができるが、災難状況情報に基づいて感知周期情報を設定することもできる。この時、放送伝送装置３００は、災難状況情報を獲得するために災難警報メッセージを利用することができる。ここで、災難警報メッセージは、CAP(Common Alerting Protocol)メッセージ形態で伝達されてもよい。
図８２は、災難状況情報を伝送するためのCAPメッセージの一例を示す。この場合、CAPメッセージはXML形態であってもよい。
図８３は、感知周期情報を設定するための災難状況情報の一例を示す。
本実施例は、災難状況情報のうち、特に地域情報に基づいて感知周期を設定する。具体的に、図８２に示すように、災難状況が発生した地域に該当する放送伝送装置３００は、感知周期を通常の状況より短く設定し、放送受信装置１００のウェイクアップ状態をより頻繁に維持させることができる。
図８３を例にすると、現在Ｂ地域が災難発生地域として、災難が発生しないＡ地域より頻繁に災難警報情報を放送受信装置１００に伝送する必要がある。従って、この場合、Ｂ地域の放送伝送装置は、Ａ地域の放送装置より相対的に感知時間情報及び状態維持時間を短く設定することができる。
本発明の実施例によれば、感知周期に応じて災難警報情報を感知してバッテリー消耗を減らすことはできるが、毎時間フレームを確認する方法に比べて、即刻災難警報情報を受信することに困難がある。従って、放送伝送装置３００が災難発生地域によって感知周期を異なるように設定して上述した問題点を克服することができる。
この時、放送伝送装置３００で感知周期設定のための災難地域の位置情報は、情報収集装置７００から受信するCAPメッセージから獲得することができる。具体的に、災難地域位置情報は、CAPメッセージの<area>情報を介して獲得することができる。
また、他の実施例で、放送受信装置１００が災難地域であるＢ地域からＡ地域に移動した場合、放送受信装置１００は、一般的な周期に応じて災難警報情報を感知することができる。具体的に、放送受信装置１００が位置を移動することで、災難警報情報を伝送する放送伝送装置が変わることになる。従って、使用者が災難地域に位置する時より、相対的に災難警報情報を即刻に伝達する必要性が減少するので、災難地域における感知周期より相対的に長い感知周期に戻ることができる。
また、他の実施例で、放送信号が複数受信される場合、放送受信装置１００は、さらに短い感知周期情報を有する放送信号に基づいて災難警報情報を感知することができる。具体的な実施例で、放送受信装置１００が２ミリ秒を感知周期とする放送信号と０.５ミリ秒を感知周期とする放送信号を両方とも受信した場合がありえる。この場合、放送受信装置１００は、さらに短い周期である０.５ミリ秒を感知周期とする感知周期情報に基づいて災難警報情報を獲得することができる。
図８４〜８６は、放送伝送装置３００が感知周期情報を災難警報の優先順位情報(Priority Information)に基づいて設定することを示す。
災難警報は、それぞれ同じレベルであるとは限らない。従って、全ての災難に対して同じレベルの感知周期を設定する場合、バッテリー及びリソース消耗減少の目的を達成することが困難となる。
本発明の一実施例によれば、災難警報の優先順位に対する情報を放送伝送装置３００が受信し、これに基づいて感知周期を設定することができる。ここで、災難警報の優先順位は、情報収集装置７００から受信することができる。具体的に、情報収集装置７００から受信できるCAPメッセージから災難警報の優先順位情報を獲得することができる。具体的な実施例で、放送伝送装置３００は、CAPメッセージに含まれた<urgency>、<severity>及び<certainty>のいずれか一つの情報を獲得することができる。放送伝送装置は、当該情報に基づいて感知周期を設定することができる。
本発明の実施例によれば、放送伝送装置３００は、CAPメッセージに含まれた災難警報情報のカテゴリー別に優先順位を判断することができる。具体的に、放送伝送装置３００は、各カテゴリー別に含まれた区間に応じて優先順位を判断することができる。ここで、カテゴリーとは、CAPメッセージに含まれた災難警報情報である。
放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報が有するそれぞれの等級に基づいて、優先順位を区分することができる。この時、放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報のうち最も高い優先順位を有する値に応じて災難警報の優先順位を判断することができる。
具体的な実施例で、放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報の等級によって、３つの緊急度に区分することができる。
例えば、放送受信装置１００は、図５２の実施例のように、Urgencyエレメントの等級がImmediateまたはExpectedに該当する場合最も高い優先順位、Futureに該当する場合最も高い優先順位より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位、Pastに該当する場合最も低い優先順位、Unknownに該当する場合初期値に該当する優先順位を有すると判断することができる。この時、初期値は、最も高い優先より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位である。
また、放送受信装置１００は、図５２の実施例のように、Severityエレメントの等級がExtremeまたはSevereに該当する場合最も高い優先順位、Moderateに該当する場合最も高い優先順位より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位、Minorに該当する場合最も低い優先順位、Unknownに該当する場合初期値に該当する優先順位を有すると判断することができる。この時、初期値は、最も高い優先より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位である。
また、放送受信装置１００は、図５２の実施例のように、Certaintyエレメントの等級がVery likelyまたはlikelyに該当する場合最も高い優先順位、Possibleに該当する場合最も高い優先順位より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位、Unlikelyに該当する場合最も低い優先順位、Unknownに該当する場合初期値に該当する優先順位を有すると判断することができる。この時、初期値は、最も高い優先より優先順位が低く最も低い優先順位より優先順位が高い中間優先順位である。
また、他の実施例で、放送受信装置１００は、災難警報の優先順位を、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報が有するそれぞれの等級に基づいてポイントを付与し、ポイントの合計に応じて災難警報の優先順位を判断することができる。
具体的な実施例で、放送受信装置１００は、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報に、同じ比重でポイントを付与することができる。例えば、放送受信装置１００は、図５３の実施例のように、Urgencyエレメントの等級がImmediateに該当する場合に５、Expectedに該当する場合に４、Futureに該当する場合に３、Pastに該当する場合に２、Unknownに該当する場合に１のポイントを付与することができる。
また、放送受信装置１００は、図５３の実施例のように、Severityエレメントの等級がExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に１のポイントを付与することができる。
また、放送受信装置１００は、図５３の実施例のように、Certaintyエレメントの等級がVery likelyに該当する場合に５、likelyに該当する場合に４、Possibleに該当する場合に３、Unlikelyに該当する場合に２、Unknownに該当する場合に１ポイントを付与することができる。この時、放送受信装置１００は、ポイントの合計が１０より大きいか、１５より小さいか同一である場合、災難警報が最も高い優先順位を有すると決定することができる。
また、放送受信装置１００は、ポイントの合計が５より大きいか、１０より小さいか同一である場合、災難警報が最も高い優先順位より低く最も低い優先順位より高い中間優先順位を有すると決定することができる。
また、放送受信装置１００は、ポイントの合計が０より大きいか、５より小さいか同一である場合、災難警報が最も低い優先順位を有すると決定することができる。
また、他の具体的な実施例で、放送受信装置１００は、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報に、それぞれ異なる比重でポイントを付与することができる。
例えば、放送受信装置１００は、図５４の実施例のように、Urgencyエレメントの等級がImmediateに該当する場合に９、Expectedに該当する場合に８、Futureに該当する場合に７、Pastに該当する場合に５、Unknownに該当する場合に０のポイントを付与することができる。
また、放送受信装置１００は、図５４の実施例のように、Severityエレメントの等級がExtremeに該当する場合に５、Severeに該当する場合に４、Moderateに該当する場合に３、Minorに該当する場合に２、Unknownに該当する場合に０のポイントを付与することができる。
また、放送受信装置１００は、図５４の実施例のように、Certaintyエレメントの等級がVery likelyに該当する場合に６、likelyに該当する場合に５、Possibleに該当する場合に４、Unlikelyに該当する場合に３、Unknownに該当する場合に０ポイントを付与することができる。この時、放送受信装置１００は、ポイントの合計が１０より大きいか、１５より小さいか同一である場合、災難警報が最も高い優先順位を有すると決定することができる。
また、放送受信装置１００は、ポイントの合計が５より大きいか、１０より小さいか同一である場合、災難警報が最も高い優先順位より低く最も低い優先順位より高い中間優先順位を有すると決定することができる。
また、放送受信装置１００は、ポイントの合計が０より大きいか、５より小さいか同一である場合、災難警報が最も低い優先順位を有すると決定することができる。
この時、放送伝送装置３００は、区分された優先順位に応じて感知周期を設定することができる。具体的に、最も高い優先順位である場合、感知周期を最も短く設定し、最も低い優先順位である場合、感知周期を最も長く設定することができる。最も低い優先順位より高い中間優先順位を有する災難警報の場合、最も短い感知周期より長い感知周期を設定することができる。
この時、最も短い感知周期及び最も長い感知周期は、放送伝送装置３００に既設定された値であってもよい。また、放送伝送装置３００は、それぞれの優先順位に対応する感知周期値を予め格納していてもよい。この時、放送伝送装置３００は、獲得した優先順位に対応する感知周期値を放送信号に設定することができる。
図８７は、本発明の一実施例に係る放送伝送装置３００の動作方法を示すフローチャートである。
放送伝送装置３００は、警報当局６００から災難警報情報を受信する(Ｓ３０１)。この場合、放送伝送装置３００は、情報収集装置７００を介して災難警報情報を受信することができる。具体的な実施例で、受信した災難警報情報は、CAPメッセージであってもよい。そして、CAPメッセージは、災難状況情報を含むことができる。
放送伝送装置３００の制御部は、受信した災難警報情報から災難状況情報を獲得する(Ｓ３０３)。具体的に、災難警報情報をパッシングして災難状況情報を獲得することができる。一例として、災難状況情報は、現在災難が発生した位置情報であってもよい。また、他の例として、災難状況情報は、発生災難の危急程度に関する情報であってもよい。
放送伝送装置３００の制御部は、獲得した災難状況情報に基づいて災難感知周期情報を設定する(Ｓ３０５)。具体的に、制御部は、災難状況に応じて放送受信装置１００のための災難感知周期を設定する。
一実施例で、放送伝送装置３００の制御部は、災難が発生した位置情報に応じて災難感知周期を設定することができる。例えば、当該放送伝送装置３００が位置した地域で災難が発生した場合、放送受信装置１００のための災難感知周期を通常の周期より短く設定することができる。
また、他の実施例で、放送伝送装置３００の制御部は、発生した災難の危急程度に関する情報に応じて災難感知周期を設定することができる。例えば、災難危急程度が高い優先順位であると判断される場合、災難感知周期を通常の周期より短く設定することができる。この時、優先順位は、複数の危急程度を示す情報に基づいて判断することができる。
放送伝送装置３００の伝送部は、設定された災難感知周期情報を含む放送信号を伝送する(Ｓ３０７)。一実施例で、放送伝送装置の制御部は、災難感知周期情報を災難警報テーブルに挿入して伝送することができる。また、他の実施例で、放送伝送装置３００の制御部は、災難感知周期情報をシグナリングチャネルに挿入して伝送することができる。また、他の実施例で、放送伝送装置３００の制御部は、災難感知周期情報をパケットに挿入して伝送することもできる。
図８８は、本発明の一実施例に係る放送受信装置１００の動作方法を示すフローチャートである。ここで、放送受信装置１００は、モバイル放送受信装置であってもよい。
放送受信装置１００の放送受信部１１０は、災難感知周期を含む放送信号を受信する(Ｓ４０１)。放送受信装置１００は、放送信号を地上波放送網及びブロードバンドのうちいずれか一つを介して受信することができる。
放送受信装置１００の制御部１５０は、放送信号から災難感知周期情報を獲得する(Ｓ４０３)。具体的に制御部１５０は、放送信号をデコーディングして災難感知周期情報を獲得することができる。この時、災難感知周期情報は、感知開始時間情報、感知持続時間情報及びスリップ持続時間情報のうちいずれか一つを含むことができる。一実施例で、災難感知周期情報は、ミリ秒単位の１０進数で表現することができ、特定基準値からの相対的な時間値を有することができる。
放送受信装置１００の制御部１５０は、災難周期感知情報に基づいて放送受信装置１００をウェイクアップ状態に変更する(Ｓ４０５)。ここで、ウェイクアップ状態は、放送受信装置１００が放送信号に災難警報情報が含まれているのか否かを感知できる状態である。即ち、制御部１５０の災難警報情報を感知するための機能が活性化されている状態である。逆に、スリップ状態は、制御部１５０の災難警報情報を感知するための機能が非活性化されている状態である。
具体的に、制御部１５０は、災難周期感知情報の感知開始時間情報に基づいて、放送受信装置１００をウェイクアップ状態に変更する。この時、制御部は、放送信号を受信した時間を基準に放送受信装置１００の状態を変更することができる。
放送受信装置１００の制御部１５０は、ウェイクアップ状態で災難警報情報を感知する(Ｓ４０７)。具体的に、制御部１５０は、放送信号に災難警報情報が含まれているのか否かを判断し、含まれている場合、災難警報情報を獲得する。
放送受信装置１００の制御部１５０は、ウェイクアップ状態で感知持続時間が経過したのか否かを判断する(Ｓ４０９)。具体的に制御部１５０は、災難周期感知情報に含まれた感知持続時間に基づいて経過したのか否かを判断する。この場合、制御部１５０は、放送受信装置１００がウェイクアップ状態となった時間を基準に感知持続時間が経過したのか否かを判断することができる。
もし制御部１５０がまだ感知持続時間が経過していないと判断した場合、災難警報情報の感知を継続する。
しかし、感知持続時間が経過したと判断された場合、制御部１５０は、放送受信装置１００をスリップ状態に変更する。ここで、スリップ状態は、放送受信装置１００が災難警報情報を感知しない状態である。制御部１５０は、スリップ状態を災難感知周期情報に含まれたスリップ持続時間情報に基づいて維持することができる。この場合、感知持続時間が終了した時間が、スリップ持続を維持するための基準時間であってもよい。
一方、制御部１５０は、新たな災難感知周期情報を受信する時まで、既存の周期を維持する。
以上、実施例に説明された特徴、構造、効果などは、本発明の少なくとも１つの実施例に含まれ、必ずしも１つの実施例のみに限定されるものではない。また、各実施例で例示された特徴、構造、効果などは、実施例が属する分野の通常の知識を有する者により他の実施例に対しても組合または変形して実施可能である。従って、このような組合と変形に係る内容は、本発明の範囲に含まれるものと解釈されるべきである。
以上、本発明を実施例を中心に説明したが、これは単なる例示であり、本発明を限定するものではない。本発明が属する分野の通常の知識を有した者であれば、本実施例の本質的な特性を逸脱しない範囲内で、以上に例示されていない変形と応用が可能である。例えば、実施例に具体的に提示された各構成要素は変形して実施することができ、そのような変形と応用にかかわる差異点は、添付された特許請求の範囲で規定する本発明の範囲に含まれると解釈されるべきである。
Claims (20)
- 緊急状況を知らせるための災難警報情報を提供する放送受信装置において、
放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信する放送受信部と、
前記伝送パケットをデコーディングして前記災難警報情報を獲得する制御部と、を含む、放送受信装置。 - 前記放送受信部は、前記災難警報情報のみを伝送するために指定された伝送経路である第１伝送経路を介して、災難警報情報を伝送するための伝送パケットを受信する、請求項１に記載の放送受信装置。
- 前記物理層は、前記第１伝送経路が前記物理層に含まれることを知らせる情報を含む、請求項２に記載の放送受信装置。
- 前記放送受信部は、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する伝送経路である第２伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信する、請求項１に記載の放送受信装置。
- 前記放送受信部は、放送サービスをスキャンするための情報を他の層を経ずに物理層に直接伝送するための伝送経路である第３伝送経路に基づいて、前記災難警報情報を伝送するための伝送パケットを受信する、請求項１に記載の放送受信装置。
- 前記第３伝送経路に基づいて受信した伝送パケットは、前記災難警報情報を獲得するための経路情報を含み、
前記放送受信部は、前記経路情報に基づいて前記第３伝送経路と異なる第４伝送経路を介して、前記災難警報情報を獲得するための伝送パケットを受信する、請求項５に記載の放送受信装置。 - 前記経路情報は、前記災難警報情報を伝送する伝送経路を識別するための情報を含む、請求項６に記載の放送受信装置。
- 前記制御部は、前記伝送パケットをデコーディングして前記災難警報情報に関連した放送サービス情報を獲得し、
前記関連した放送サービス情報は、前記災難警報情報に関連したリアルタイムサービスを伝送する伝送経路情報及び前記災難警報情報に関連した非リアルタイムサービスを受信するためのアドレス情報のうち少なくとも一つである、請求項１に記載の放送受信装置。 - 前記制御部は、前記災難警報情報に基づいて、前記物理層を介して災難警報情報が伝送されるのか否かを感知する機能を活性化するための第１情報を獲得する、請求項１に記載の放送受信装置。
- 前記第１情報は、感知機能の活性化開始時間情報、感知機能の活性化持続時間情報及び感知機能の非活性化持続時間情報のうち少なくともいずれか一つを含む、請求項９に記載の放送受信装置。
- 前記第１情報は、前記災難警報情報を伝送する放送伝送装置の位置に基づいて決定される、請求項９に記載の放送受信装置。
- 前記第１情報は、前記放送受信装置の位置と災難発生地域の間の距離に比例する感知機能の非活性化持続時間を有する、請求項１１に記載の放送受信装置。
- 前記第１情報は、災難警報の優先順位を示す第２情報に基づいて決定され、
前記第２情報は、災難警報の緊急度を示す情報、災難警報を誘発した災難の深刻性を示す情報及び災難警報を誘発した災難の発生確率を示す情報を含む、請求項１１に記載の放送受信装置。 - 緊急状況を知らせるための災難警報情報を提供する放送受信装置の動作方法において、
放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信するステップと、
前記伝送パケットをデコーディングするステップと、
前記デコーディングされた伝送パケットから災難警報情報を獲得するステップと、を含む、放送受信装置の動作方法。 - 前記伝送パケットを受信するステップは、前記災難警報情報のみを伝送するために指定された伝送経路である第１伝送経路を介して、災難警報情報を伝送するための伝送パケットを受信するステップを含む、請求項１４に記載の放送受信装置の動作方法。
- 前記伝送パケットを受信するステップは、放送サービスに対するシグナリング情報または複数の放送サービスに適用される共用データを伝送する伝送経路である第２伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信するステップを含む、請求項１４に記載の放送受信装置の動作方法。
- 前記伝送パケットを受信するステップは、放送サービスをスキャンするための情報を他の層を経ずに物理層に直接伝送するための伝送経路である第３伝送経路に基づいて、前記災難警報情報を伝送するための伝送パケットを受信するステップを含む、請求項１４に記載の放送受信装置の動作方法。
- 前記第３伝送経路に基づいて受信した伝送パケットは、前記災難警報情報を獲得するための経路情報を含み、
前記伝送パケットを受信するステップは、前記経路情報に基づいて前記第３伝送経路と異なる第４伝送経路を介して、前記災難警報情報を伝送するための伝送パケットを受信するステップを含む、請求項１７に記載の放送受信装置の動作方法。 - 緊急状況を知らせるための災難警報情報を警報当局から収集し、前記収集した災難警報情報を伝送するための形態にエンコーディングする制御部と、
放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記エンコーディングされた災難警報情報を伝送する伝送部を含む、放送伝送装置。 - 緊急状況を知らせるための災難警報情報を警報当局から収集するステップと、
前記収集した災難警報情報を伝送するための形態にエンコーディングするステップと、
放送信号を伝送するための複数の層のうちの一つであり、物理的媒体(physical medium)を介して放送信号を送受信するための物理層に含まれた伝送経路を介して、前記エンコーディングされた災難警報情報を伝送するステップと、を含む、放送伝送装置の動作方法。
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201461942596P | 2014-02-20 | 2014-02-20 | |
| US61/942,596 | 2014-02-20 | ||
| US201461947983P | 2014-03-04 | 2014-03-04 | |
| US61/947,983 | 2014-03-04 | ||
| US201461970341P | 2014-03-25 | 2014-03-25 | |
| US61/970,341 | 2014-03-25 | ||
| PCT/KR2015/001665 WO2015126181A2 (en) | 2014-02-20 | 2015-02-17 | Broadcast reception device and operating method thereof, and broadcast transmission device and operating method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2017514331A true JP2017514331A (ja) | 2017-06-01 |
| JP6321195B2 JP6321195B2 (ja) | 2018-05-09 |
Family
ID=53879199
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016553455A Active JP6321195B2 (ja) | 2014-02-20 | 2015-02-17 | 放送受信装置、放送受信装置の動作方法、放送受信装置及び放送受信装置の動作方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20170013093A1 (ja) |
| EP (1) | EP3108464A4 (ja) |
| JP (1) | JP6321195B2 (ja) |
| KR (1) | KR101870929B1 (ja) |
| CN (1) | CN107430803A (ja) |
| WO (1) | WO2015126181A2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| MX367329B (es) * | 2014-05-22 | 2019-08-15 | Sony Corp | Aparato de recepcion, metodo de recepcion, aparato de transmision y metodo de transmision. |
| CA2945611C (en) * | 2015-03-04 | 2023-05-09 | Sony Corporation | Reception apparatus, reception method, transmission apparatus, and transmission method |
| WO2017164270A1 (en) * | 2016-03-25 | 2017-09-28 | Sharp Kabushiki Kaisha | Systems and methods for signaling of information associated with audio content |
| US20180014171A1 (en) * | 2016-07-05 | 2018-01-11 | Qualcomm Incorporated | Management of emergency alert wake up bits |
| AU2017356366B2 (en) * | 2016-11-09 | 2020-04-09 | Sony Semiconductor Solutions Corporation | Reception device, reception method, transmission device, and transmission method |
| KR102218262B1 (ko) * | 2019-05-08 | 2021-02-22 | 주식회사 로와시스 | 방송 수신기가 없는 컴패니언 디바이스에서 방송신호 수신이 가능하도록 하는 atsc 지상파 수신용 홈 미디어 게이트웨이 |
| US11094314B2 (en) * | 2020-01-18 | 2021-08-17 | Interra Systems | System and method for detecting a simulated emergency alert signal (EAS) |
| WO2024092184A1 (en) * | 2022-10-27 | 2024-05-02 | Esōes Cosmetics Llc | Digital personal safety application |
| CN117792549B (zh) * | 2024-02-23 | 2024-05-14 | 杭州图南电子股份有限公司 | 应急广播终端的运行状态确定方法、装置、设备和介质 |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006319771A (ja) * | 2005-05-13 | 2006-11-24 | Nippon Hoso Kyokai <Nhk> | 伝送制御信号受信機及びそれを用いた地上デジタルテレビジョン放送受信機 |
| JP2007251298A (ja) * | 2006-03-14 | 2007-09-27 | Matsushita Electric Ind Co Ltd | デジタル放送再送信装置、デジタル放送受信機およびデジタル放送再送信システム |
| JP2008288709A (ja) * | 2007-05-15 | 2008-11-27 | Funai Electric Co Ltd | 表示装置 |
| JP2011239296A (ja) * | 2010-05-12 | 2011-11-24 | Sony Corp | 受信装置、報知制御方法、およびプログラム |
| US20130243116A1 (en) * | 2010-11-23 | 2013-09-19 | Lg Electronics Inc. | Broadcast signal transmitter/receiver, and broadcast signal transceiving method |
| JP2015061195A (ja) * | 2013-09-18 | 2015-03-30 | ソニー株式会社 | 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム |
| JP2015061240A (ja) * | 2013-09-19 | 2015-03-30 | ソニー株式会社 | 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム |
| JP2015080172A (ja) * | 2013-10-18 | 2015-04-23 | ソニー株式会社 | 受信装置及び受信方法、コンピューター・プログラム、並びに外部機器 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE60136393D1 (de) * | 2001-11-28 | 2008-12-11 | Fujitsu Ltd | Orthogonal-frequenzmultiplexübertragungsverfahren |
| KR101259118B1 (ko) * | 2007-02-23 | 2013-04-26 | 엘지전자 주식회사 | 방송 신호 송신 장치 및 방법 |
| US8138915B2 (en) * | 2007-11-15 | 2012-03-20 | Ibiquity Digital Corporation | Systems and methods for rendering alert information for digital radio broadcast, and active digital radio broadcast receiver |
| US8649309B2 (en) * | 2008-01-24 | 2014-02-11 | Samsung Electronics Co., Ltd. | Apparatus and method for creating data path for broadcasting service in cellular network |
| US20090303070A1 (en) * | 2008-06-10 | 2009-12-10 | Jie Zhang | Distributed Decision Making Area Earthquake Warning System |
| KR101556170B1 (ko) * | 2009-03-03 | 2015-09-30 | 엘지전자 주식회사 | 신호 송수신 장치 및 방법 |
| FI20096174A0 (fi) * | 2009-11-11 | 2009-11-11 | Ekahau Oy | Automaattisesti moodia vaihtava langaton signaalilähetin-vastaanotin sekä menetelmä |
| US9219556B2 (en) * | 2012-03-02 | 2015-12-22 | Lg Electronics Inc. | Method of providing an emergency alert service via a mobile broadcasting and apparatus therefor |
-
2015
- 2015-02-17 KR KR1020167021771A patent/KR101870929B1/ko active IP Right Grant
- 2015-02-17 EP EP15751916.6A patent/EP3108464A4/en not_active Withdrawn
- 2015-02-17 WO PCT/KR2015/001665 patent/WO2015126181A2/en active Application Filing
- 2015-02-17 CN CN201580009482.XA patent/CN107430803A/zh not_active Withdrawn
- 2015-02-17 US US15/120,411 patent/US20170013093A1/en not_active Abandoned
- 2015-02-17 JP JP2016553455A patent/JP6321195B2/ja active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006319771A (ja) * | 2005-05-13 | 2006-11-24 | Nippon Hoso Kyokai <Nhk> | 伝送制御信号受信機及びそれを用いた地上デジタルテレビジョン放送受信機 |
| JP2007251298A (ja) * | 2006-03-14 | 2007-09-27 | Matsushita Electric Ind Co Ltd | デジタル放送再送信装置、デジタル放送受信機およびデジタル放送再送信システム |
| JP2008288709A (ja) * | 2007-05-15 | 2008-11-27 | Funai Electric Co Ltd | 表示装置 |
| JP2011239296A (ja) * | 2010-05-12 | 2011-11-24 | Sony Corp | 受信装置、報知制御方法、およびプログラム |
| US20130243116A1 (en) * | 2010-11-23 | 2013-09-19 | Lg Electronics Inc. | Broadcast signal transmitter/receiver, and broadcast signal transceiving method |
| JP2015061195A (ja) * | 2013-09-18 | 2015-03-30 | ソニー株式会社 | 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム |
| JP2015061240A (ja) * | 2013-09-19 | 2015-03-30 | ソニー株式会社 | 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム |
| JP2015080172A (ja) * | 2013-10-18 | 2015-04-23 | ソニー株式会社 | 受信装置及び受信方法、コンピューター・プログラム、並びに外部機器 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6321195B2 (ja) | 2018-05-09 |
| KR20160107264A (ko) | 2016-09-13 |
| WO2015126181A2 (en) | 2015-08-27 |
| CN107430803A (zh) | 2017-12-01 |
| KR101870929B1 (ko) | 2018-06-25 |
| US20170013093A1 (en) | 2017-01-12 |
| WO2015126181A3 (en) | 2017-03-09 |
| EP3108464A4 (en) | 2018-05-02 |
| EP3108464A2 (en) | 2016-12-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11736923B2 (en) | Broadcast receiving device and operating method thereof | |
| JP6321195B2 (ja) | 放送受信装置、放送受信装置の動作方法、放送受信装置及び放送受信装置の動作方法 | |
| KR101779434B1 (ko) | 방송 송신 장치, 방송 송신 장치의 데이터 처리 방법, 방송 수신 장치 및 방송 수신 장치의 데이터 처리 방법 | |
| US11166083B2 (en) | Broadcast transmission device, broadcast reception device, operating method of broadcast transmission device, and operating method of broadcast reception device | |
| US9948416B2 (en) | Broadcast receiving device and operating method thereof | |
| JP6466951B2 (ja) | 一つ以上のネットワークを介して放送コンテンツを送受信する装置及び方法 | |
| KR101812186B1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
| JP2018207499A (ja) | 放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法 | |
| US20170055025A1 (en) | Broadcast transmission apparatus, broadcast reception apparatus, operation method of the broadcast transmission apparatus and operation method of the broadcast reception apparatus | |
| KR101844235B1 (ko) | 하나 이상의 네트워크를 통해 방송 컨텐츠를 송수신하는 장치 및 방법 | |
| KR101838206B1 (ko) | 방송 수신 장치 및 방송 수신 장치의 동작 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170920 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20171024 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180118 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180306 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180404 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6321195 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |