(57)【要約】【課題】より高度な緊急告知サービスを提供することができるようにする。【解決手段】緊急告知制御部は、IP伝送方式を用いたデジタル放送の放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御することで、IP伝送方式を用いたデジタル放送において、より高度な緊急告知サービスを提供することができる。本技術は、例えば、送信機と受信機からなる放送システムに適用することができる。【選択図】図２２
2015104055.tif 000002
【特許請求の範囲】
【請求項１】
IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波を受信する受信部と、
前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御する制御部と
を備える受信装置。
【請求項２】
前記制御部は、映像及び音声の少なくとも１つによって、緊急情報を告知する
請求項１に記載の受信装置。
【請求項３】
前記制御信号は、緊急告知用のアプリケーションに関する情報を含み、
前記制御部は、前記制御信号に基づいて、前記アプリケーションを取得して、AVコンテンツと連動して実行させる
請求項２に記載の受信装置。
【請求項４】
前記制御信号は、前記アプリケーションの識別情報を含み、
前記制御部は、前記アプリケーションの識別情報と、前記アプリケーションを制御するためのアプリケーション制御信号に基づいて、前記アプリケーションを取得する
請求項３に記載の受信装置。
【請求項５】
前記制御信号は、緊急告知用のコンポーネントに関する情報を含み、
前記制御部は、前記制御信号に基づいて、映像及び音声の少なくとも１つの前記コンポーネントを取得して、AVコンテンツの映像及び音声の少なくとも１つを切り替える
請求項２に記載の受信装置。
【請求項６】
前記コンポーネントは、複数のサービスで共有されている
請求項５に記載の受信装置。
【請求項７】
前記制御信号は、あらかじめ設定された所定のフィルタ条件に応じてフィルタリングされる
請求項２に記載の受信装置。
【請求項８】
前記制御信号は、その緊急度に応じてフィルタリングされる
請求項７に記載の受信装置。
【請求項９】
前記制御信号は、その対象地域に応じてフィルタリングされる
請求項７に記載の受信装置。
【請求項１０】
前記制御信号は、所定のエリア単位でフィルタリングされる
請求項７に記載の受信装置。
【請求項１１】
前記制御信号は、その種類に応じてフィルタリングされる
請求項７に記載の受信装置。
【請求項１２】
前記放送波は、強制緊急起動信号を伝送可能であり、
前記受信装置がスリープ状態の場合に、前記強制緊急起動信号が検知されたとき、前記受信装置の電源をオンする
請求項１に記載の受信装置。
【請求項１３】
前記制御信号は、XML形式で伝送される
請求項１に記載の受信装置。
【請求項１４】
前記制御信号は、セクション形式で伝送される
請求項１に記載の受信装置。
【請求項１５】
前記制御信号は、IP伝送方式におけるプロトコルの階層のうち、IP層よりも下位の階層である第１の階層で用いられる
請求項１に記載の受信装置。
【請求項１６】
前記放送波は、前記第１の階層で用いられる選局情報用の制御信号を伝送しており、
前記選局情報用の制御信号は、ネットワークの識別情報、ストリームの識別情報、及び、サービスの識別情報を少なくとも含んでいる
請求項１５に記載の受信装置。
【請求項１７】
前記放送波は、IP層よりも上位の階層である第２の階層で用いられる、特定のサービスを構成するコンポーネントに関する情報を少なくとも含む制御信号を伝送している
請求項１６に記載の受信装置。
【請求項１８】
受信装置の受信方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波を受信し、
前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御する
ステップを含む受信方法。
【請求項１９】
緊急告知用の制御信号を取得する取得部と、
前記制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する送信部と
を備える送信装置。
【請求項２０】
送信装置の送信方法において、
前記送信装置が、
緊急告知用の制御信号を取得し、
前記制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する
ステップを含む送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、受信方法、送信装置、及び、送信方法に関し、特に、より高度な緊急告知サービスを提供することができるようにした受信装置、受信方法、送信装置、及び、送信方法に関する。
【背景技術】
【０００２】
現在、各国のデジタル放送の規格では、伝送形式としてMPEG2-TS（Moving Picture Experts Group phase 2 - Transport Stream）方式が採用されている（例えば、特許文献１参照）。今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
【０００３】
また、日本ではデジタル放送の規格において、緊急時用の制御信号と緊急放送サービスについて規定されている。当該規格では、テレビジョン受像機等の受信機が、電源がオフされた状態でも、上記の制御信号によって電源をオンした上で、緊急放送サービスを自動選局できるように規定されている。
【０００４】
一方、米国では、EAS(Emergency Alerting System)と呼ばれる緊急告知のシステムが整備されており、大統領からの最優先事項からローカルな告知事項まで、様々なレベルの緊急情報を、様々なメディアにより告知できるようになっている。ここで、緊急告知メッセージのフォーマットとしては、XML(Extensible Markup Language)形式のCAP(Common Alerting Protocol)方式が利用されている。
【０００５】
このようなEASの末端のメディアとして、放送も位置付けられており、テレビジョン受像機等の固定受信機向けのデジタル放送において、特に日本のような制御信号は運用されていないが、映像に重畳した字幕として表示される。一方で携帯受信機向けの放送規格であるATSC M/H(Advanced Television Systems Committee - Mobile/Handheld)では、緊急告知用の制御信号と、上記のCAP情報をそのまま放送波で伝送する方式が規定されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−１５６７１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、次世代放送システムとしてIP伝送方式を導入することで、様々な運用形態を利用できるようになって、様々なサービスを提供できるようになることが想定されているが、緊急告知サービスを提供するための技術方式は確立されていない。
【０００８】
本技術はこのような状況に鑑みてなされたものであり、IP伝送方式を導入したデジタル放送において、より高度な緊急告知サービスを提供することができるようにするものである。
【課題を解決するための手段】
【０００９】
本技術の第１の側面の受信装置は、IP伝送方式を用いたデジタル放送の放送波を受信する受信部と、前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御する制御部とを備える。
【００１０】
前記制御部は、映像及び音声の少なくとも１つによって、緊急情報を告知することができる。
【００１１】
前記制御信号は、緊急告知用のアプリケーションに関する情報を含み、前記制御部は、前記制御信号に基づいて、前記アプリケーションを取得して、AVコンテンツと連動して実行させることができる。
【００１２】
前記制御信号は、前記アプリケーションの識別情報を含み、前記制御部は、前記アプリケーションの識別情報と、前記アプリケーションを制御するためのアプリケーション制御信号に基づいて、前記アプリケーションを取得することができる。
【００１３】
前記制御信号は、緊急告知用のコンポーネントに関する情報を含み、前記制御部は、前記制御信号に基づいて、映像及び音声の少なくとも１つの前記コンポーネントを取得して、AVコンテンツの映像及び音声の少なくとも１つを切り替えることができる。
【００１４】
前記コンポーネントは、複数のサービスで共有されているようにすることができる。
【００１５】
前記制御信号は、あらかじめ設定された所定のフィルタ条件に応じてフィルタリングされるようにすることができる。
【００１６】
前記制御信号は、その緊急度に応じてフィルタリングされるようにすることができる。
【００１７】
前記制御信号は、その対象地域に応じてフィルタリングされるようにすることができる。
【００１８】
前記制御信号は、所定のエリア単位でフィルタリングされるようにすることができる。
【００１９】
前記制御信号は、その種類に応じてフィルタリングされるようにすることができる。
【００２０】
前記放送波は、強制緊急起動信号を伝送可能であり、前記受信装置がスリープ状態の場合に、前記強制緊急起動信号が検知されたとき、前記受信装置の電源をオンすることができる。
【００２１】
前記制御信号は、XML形式で伝送されるようにすることができる。
【００２２】
前記制御信号は、セクション形式で伝送されるようにすることができる。
【００２３】
前記制御信号は、IP伝送方式におけるプロトコルの階層のうち、IP層よりも下位の階層である第１の階層で用いられるようにすることができる。
【００２４】
前記放送波は、前記第１の階層で用いられる選局情報用の制御信号を伝送しており、前記選局情報用の制御信号は、ネットワークの識別情報、ストリームの識別情報、及び、サービスの識別情報を少なくとも含んでいるようにすることができる。
【００２５】
前記放送波は、IP層よりも上位の階層である第２の階層で用いられる、特定のサービスを構成するコンポーネントに関する情報を少なくとも含む制御信号を伝送しているようにすることができる。
【００２６】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。
【００２７】
本技術の第１の側面の受信方法は、上述した本技術の第１の側面の受信装置に対応する受信方法である。
【００２８】
本技術の第１の側面の受信装置及び受信方法においては、IP伝送方式を用いたデジタル放送の放送波が受信され、前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作が制御される。
【００２９】
本技術の第２の側面の送信装置は、緊急告知用の制御信号を取得する取得部と、前記制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する送信部とを備える。
【００３０】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。
【００３１】
本技術の第２の側面の送信方法は、上述した本技術の第２の側面の送信装置に対応する送信方法である。
【００３２】
本技術の第２の側面の送信装置及び送信方法においては、緊急告知用の制御信号が取得され、前記制御信号が、IP伝送方式を用いたデジタル放送の放送波で送信される。
【発明の効果】
【００３３】
本技術の第１の側面及び第２の側面によれば、より高度な緊急告知サービスを提供することができる。
【００３４】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００３５】
【図１】セクション形式のIP伝送方式におけるプロトコルスタックを示す図である。
【図２】セクション形式のIP伝送方式におけるID体系を示す図である。
【図３】セクション形式のIP伝送方式における放送波の構成を示す図である。
【図４】セクション形式のIP伝送方式における放送波の他の構成を示す図である。
【図５】セクション形式のIP伝送方式におけるLLSの構成を示す図である。
【図６】セクション形式のIP伝送方式におけるSCSの構成を示す図である。
【図７】物理層における強制緊急起動フラグを説明するための図である。
【図８】セクション形式のIP伝送方式における基本的なシグナリング系統を説明するための図である。
【図９】NITのシンタックスを示す図である。
【図１０】NITのループ内に配置される記述子の例を示す図である。
【図１１】AMTのシンタックスを示す図である。
【図１２】SATのシンタックスを示す図である。
【図１３】EATのシンタックスを示す図である。
【図１４】EATの構成情報を示す図である。
【図１５】CAP情報の概要を示す図である。
【図１６】CAP情報を示す図である。
【図１７】CAP情報の記述例を示す図である。
【図１８】SMTのシンタックスを示す図である。
【図１９】SMTのループ内に配置される記述子の例を示す図である。
【図２０】本技術を適用した放送システムの一実施の形態の構成を示す図である。
【図２１】本技術を適用した送信装置の一実施の形態の構成を示す図である。
【図２２】本技術を適用した受信装置の一実施の形態の構成を示す図である。
【図２３】セクション形式のIP伝送方式におけるDemuxによる各パケットのフィルタリング処理の詳細を示す図である。
【図２４】EA_categoryのフォーマットの例を示す図である。
【図２５】EA_categoryの構成情報を示す図である。
【図２６】スリープ状態時のNRTポータルサービス伝送処理を説明する図である。
【図２７】起動状態時のNRTポータルサービス伝送処理を説明する図である。
【図２８】スリープ状態時のEASメッセージ伝送処理を説明する図である。
【図２９】起動状態時のEASメッセージ伝送処理を説明する図である。
【図３０】スリープ状態時のアプリケーション伝送処理を説明する図である。
【図３１】起動状態時のアプリケーション伝送処理を説明する図である。
【図３２】シェアドコンポーネントサービス伝送処理を説明する図である。
【図３３】シェアドコンポーネントサービスの例を示す図である。
【図３４】送信処理を説明するフローチャートである。
【図３５】受信処理を説明するフローチャートである。
【図３６】緊急告知処理を説明するフローチャートである。
【図３７】NRTポータルサービス伝送処理を説明するフローチャートである。
【図３８】EASメッセージ伝送処理を説明するフローチャートである。
【図３９】アプリケーション伝送処理を説明するフローチャートである。
【図４０】シェアドコンポーネントサービス伝送処理を説明するフローチャートである。
【図４１】XML形式のIP伝送方式におけるプロトコルスタックを示す図である。
【図４２】XML形式のIP伝送方式におけるID体系を示す図である。
【図４３】XML形式のIP伝送方式における放送波の構成を示す図である。
【図４４】XML形式のIP伝送方式におけるLLSの構成を示す図である。
【図４５】XML形式のIP伝送方式におけるSCSの構成を示す図である。
【図４６】XML形式のIP伝送方式における基本的なシグナリング系統を説明するための図である。
【図４７】SGDUの構造を説明するための図である。
【図４８】SCTのシンタックスを示す図である。
【図４９】SATのシンタックスを示す図である。
【図５０】EATのシンタックスを示す図である。
【図５１】RRTのシンタックスを示す図である。
【図５２】SDPの記述例を示す図である。
【図５３】本技術を適用した受信装置の一実施の形態の構成を示す図である。
【図５４】XML形式のIP伝送方式におけるDemuxによる各パケットのフィルタリング処理の詳細を示す図である。
【図５５】スリープ状態時のNRTポータルサービス伝送処理を説明する図である。
【図５６】起動状態時のNRTポータルサービス伝送処理を説明する図である。
【図５７】スリープ状態時のEAメッセージ伝送処理を説明する図である。
【図５８】起動状態時のEAメッセージ伝送処理を説明する図である。
【図５９】スリープ状態時のアプリケーション伝送処理を説明する図である。
【図６０】起動状態時のアプリケーション伝送処理を説明する図である。
【図６１】シェアドコンポーネントサービス伝送処理を説明する図である。
【図６２】緊急告知処理を説明するフローチャートである。
【図６３】NRTポータルサービス伝送処理を説明するフローチャートである。
【図６４】EAメッセージ伝送処理を説明するフローチャートである。
【図６５】アプリケーション伝送処理を説明するフローチャートである。
【図６６】シェアドコンポーネントサービス伝送処理を説明するフローチャートである。
【図６７】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００３６】
以下、図面を参照しながら本技術の実施の形態について説明する。ただし、以下の順序にしたがって説明するものとする。
【００３７】
１．セクション形式のIP伝送方式によるデジタル放送
（１）セクション形式のIP伝送方式の概要
（２）シグナリング情報
（２−１）LLS(NIT，AMT，SAT，EAT)の詳細構造
（２−２）SCS(SMT)の詳細構造
（３）放送システムの構成
（４）具体的な運用例
（４−１）NRTポータルサービス伝送
（４−２）EASメッセージ伝送
（４−３）アプリケーション伝送
（４−４）シェアドコンポーネントサービス伝送
（５）各装置で実行される具体的な処理の内容
２．XML形式のIP伝送方式によるデジタル放送
（１）XML形式のIP伝送方式の概要
（２）シグナリング情報
（２−１）LLS(SCT，SAT，EAT，RRT)の詳細構造
（２−２）SCS(SDP)の詳細構造
（３）放送システムの構成
（４）具体的な運用例
（４−１）NRTポータルサービス伝送
（４−２）EASメッセージ伝送
（４−３）アプリケーション伝送
（４−４）シェアドコンポーネントサービス伝送
（５）各装置で実行される具体的な処理の内容
【００３８】
＜１．セクション形式のIP伝送方式によるデジタル放送＞
【００３９】
本技術を適用したIP伝送方式のデジタル放送においては、セクション形式と、XML形式のいずれかの方式を採用することができる。ここで、セクション形式のIP伝送方式は、シグナリング情報をセクション形式(Section Format)により伝送する方式である。一方、XML形式のIP伝送方式は、シグナリング情報をXML形式(Extensible Markup Language Format)により伝送する方式である。以下の説明では、まず、セクション形式のIP伝送方式の説明を行い、その後に、XML形式のIP伝送方式の説明を行うものとする。
【００４０】
＜（１）セクション形式のIP伝送方式の概要＞
【００４１】
（セクション形式のIP伝送方式におけるプロトコルスタック）
図１は、セクション形式のIP伝送方式によるデジタル放送のプロトコルスタックを示す図である。
【００４２】
図１に示すように、最も下位の階層は、物理層(Physical Layer)とされ、サービス（チャンネル）のために割り当てられた放送波の周波数帯域がこれに対応する。物理層に隣接する上位の階層は、GSE層とされる。GSE(Generic Stream Encapsulation)層は、下位に隣接する物理層と上位に隣接するIP層との対応付けを行うためのものである。なお、GSEは、DVB(Digital Video Broadcasting)の規格として採用されている。
【００４３】
IP層は、TCP/IPのプロトコルスタックにおけるIP(Internet Protocol)と同じものであり、IPアドレスによりIPパケットが特定される。IP層に隣接する上位階層はUDP層とされ、さらにその上位の階層は、RTP(Real-time Transport Protocol)，FLUTE(File Delivery over Unidirectional Transport)/ALC(Asynchronous Layered Coding Protocol)とされる。すなわち、IP伝送方式のデジタル放送においては、UDP(User Datagram Protocol)のポート番号が指定されたパケットが送信され、例えばRTPセッションやFLUTEセッションが確立されるようになされている。なお、FLUTEの詳細は、RFC3926として規定されている。
【００４４】
FLUTE/ALCに隣接する上位階層は、fMP4(Fragmented MP4)とされ、さらに、RTP，fMP4に隣接する上位階層は、AV(Audio Video)，SubTitle，RealTimeEventとされる。ビデオデータ(Video)は、例えばHEVC(High Efficiency Video Coding)等の符号化方式により符号化されている。また、オーディオデータ(Audio)は、例えばAAC(Advanced Audio Coding)等の符号化方式により符号化されている。すなわち、ビデオデータやオーディオデータを、同期型のストリーム形式で伝送する場合には、RTPセッションが利用され、ビデオデータやオーディオデータを、非同期型のファイル形式で伝送する場合には、FLUTEセッションが利用される。
【００４５】
また、FLUTE/ALCの上位階層には、Interactive，Meta，etc.とされる。例えば、テレビ番組に連動して実行されるアプリケーションのファイルを送る場合に、このFLUTEセッションが利用される。
【００４６】
図１のプロトコルスタックの右側には、シグナリング情報として、LLS，MLS，HLSが規定されている。LLS(Low Layer Signaling)は、低レイヤのシグナリングであって、GSE層の上位階層となる。例えば、LLSには、MPEG2-TS方式で用いられているnetwork_id，transport_stream_id，service_idの組み合わせ（以下、「トリプレット(Triplet)」という）と、セクション形式を採用することができる。
【００４７】
この場合には、LLSとして、トリプレットにより放送ネットワーク内のトランスポートストリーム構成とサービス構成を示しているNIT(Network Information Table)を伝送することができる。また詳細は後述するが、LLSとして、NITとともにAMT(Address Map Table)を伝送することで、受信機側では、例えばサービス（チャンネル）を選局するための選局情報を得ることができる。
【００４８】
また、LLSとして、SAT(Service Association Table)、EAT(Emergency Alert Table)、RRT(Region Rating Table)を伝送することができる。SATは、特定のサービスがオンエア中（放送中）であるかどうかを示す情報を含んでいる。EATは、緊急告知に関する情報を含んでいる。RRTは、番組の分類に関する地域情報に関する情報を含んでいる。
【００４９】
また、MLS(Middle Layer Signaling)は、中間レイヤのシグナリングであって、UDP層の上位階層となる。MLSを設けることで、迅速な選局処理が可能となる。例えば、MLSとしては、サービス単位で、サービス関連情報やコンポーネント情報を伝送するためのSCS(Service Channel Signaling)を採用することができる。SCSとしては、例えば、SMT(Service Map Table)やAIT(Application Information Table)等がセクション形式で伝送される。SMTは、サービス単位のサービス属性、コンポーネントの構成情報、コンポーネント属性、コンポーネントのフィルタ情報などを含んでいる。AITは、AVコンテンツと連動して実行されるアプリケーションの制御情報である。
【００５０】
HLS(High Layers Signaling)は、高レイヤのシグナリング(又はアナウンスメント)であって、FLUTE/ALCの上位階層となる。例えば、HLSとして、FLUTEセッションにより、ESG(Electronic Service Guide：電子サービスガイド)のファイルを伝送することができる。ESGは、例えば、番組タイトルや開始時刻などの情報を含んでいる。
【００５１】
（セクション形式のIP伝送方式におけるID体系）
図２は、放送波の信号と、セクション形式のIP伝送方式のID体系との関係を示す図である。
【００５２】
図２に示すように、6MHzの周波数帯域を有する放送波（放送ネットワーク(Network)）には、network_idが割り当てられている。各放送波には、transport_stream_idにより識別される、１又は複数のGSEストリーム(GSE Stream)が含まれている。GSEストリームは、GSEヘッダとペイロードからなる複数のGSEパケットにより構成される。
【００５３】
各GSEストリームには、service_idにより識別される複数のサービス(Service)が含まれている。各サービスは、複数のコンポーネント(Component)から構成されている。各コンポーネントは、例えば、ビデオデータやオーディオデータ等の番組を構成する情報である。
【００５４】
このように、セクション形式のIP伝送方式のID体系として、MPEG2-TS方式と同様にトリプレットを採用して、network_id，transport_stream_id，service_idの組み合わせを用いることで、現在広く普及しているMPEG2-TS方式との整合をとることができるため、例えば、MPEG2-TS方式からIP伝送方式への移行時のサイマルキャストに容易に対応することが可能となる。
【００５５】
なお、service_idに対応する識別情報として、メジャーチャンネル番号とマイナーチャンネル番号を用いた運用を行っている場合には、16ビットのservice_idのうち、上位の8ビットを、メジャーチャンネル番号の8ビットに、下位の8ビットを、マイナーチャンネル番号の8ビットにそれぞれ割り当てることで、そのような運用にも対応することができる。
【００５６】
（セクション形式のIP伝送方式の放送波の構成）
図３は、セクション形式のIP伝送方式のデジタル放送の放送波の構成を示す図である。
【００５７】
図３に示すように、6MHzの周波数帯域を有する放送波(図中の「Network」)から、１又は複数のトランスポートストリーム(Transport Stream)と、LLSを取得することができる。また、各トランスポートストリームから、NTP(Network Time Protocol)、複数のサービスチャンネル(Service Channel)、電子サービスガイド(ESG Service)を取得することができる。NTPは、時刻情報であって、複数のサービスチャンネルで共通のものとなる。
【００５８】
各サービスチャンネルには、ビデオデータやオーディオデータ等のコンポーネント(Component)と、SMTやAIT等のSCSが含まれる。また、各サービスチャンネルには、固定のIPアドレスが付与されており、このIPアドレスを用いて、サービスチャンネルごとに、コンポーネントや制御信号などをパッケージ化することができる。
【００５９】
なお、図３において、トランスポートストリーム(Transport Stream)は、図２のGSEストリーム(GSE Stream)に相当するものであって、以下の説明で、トランスポートストリームと記述した場合には、GSEストリームを意味するものとする。また、コンポーネント(Component)は、図２のコンポーネント(Component)に対応しているが、サービスチャンネル(Service Channel)は、図２のサービス(Service)に相当するものである。
【００６０】
また、図４に示すように、LLSは、Basebandストリーム（GSEストリーム）上で伝送されるようにしてもよい。この場合において、NTP、サービスチャンネル(Service Channel)、電子サービスガイド(ESG Service)は、UDP/IPのプロトコルに従って伝送されることになる。なお、以下、セクション形式のIP伝送方式によるデジタル放送の説明においては、図４の構成を採用した場合について説明するものとする。
【００６１】
（LLSの構成）
図５は、セクション形式のIP伝送方式におけるLLSの構成を示す図である。
【００６２】
図５に示すように、GSEパケットは、GSEヘッダとペイロードから構成される。GSE層の上位階層がIP層となる場合には、ペイロードの部分がIPパケットとなる。LLSは、GSE層の上位階層となるが、セクション形式で伝送されるため、GSEヘッダの次に配置される。LLSとしては、例えば、NIT，AMT，SAT，EAT，RRTを配置することができる。
【００６３】
なお、GSEヘッダには、2ビットのタイプ情報が含まれており、そのタイプ情報によって、GSEパケットがIPパケットであるか、LLSであるかを区別することができる。
【００６４】
（MLSの構成）
図６は、セクション形式のIP伝送方式におけるMLSの構成を示す図である。
【００６５】
図６に示すように、例えば、ビデオデータやオーディオデータを、同期型のストリーム形式で伝送する場合には、RTPセッションが利用されるため、GSE，IP，UDP，RTPの各ヘッダがペイロードに付加されている。また、fMP4やESG等のファイルデータを、非同期型のファイル形式で伝送する場合には、FLUTEセッションが利用されるため、GSE，IP，UDP，LCTの各ヘッダがペイロードに付加されている。さらに、NTPは、UDP層の上位階層となるため、GSE，IP，UDPの各ヘッダの次に配置される。
【００６６】
MLSは、UDP層の上位階層となるが、セクション形式で伝送されるため、GSE，IP，UDPの各ヘッダの次に配置される。MLS(SCS)としては、例えば、SMTやAITを配置することができる。
【００６７】
（強制緊急起動フラグ）
図７は、物理層における強制緊急起動フラグを説明するための図である。
【００６８】
強制緊急起動フラグは、メイン電源がオフ状態（スリープ状態）になっている受信機を強制的に起動させるためのWake-up信号であって、上述した図１のプロトコルスタックの物理層において伝送されるものである。すなわち、強制緊急起動フラグは、高信頼性、かつ、低遅延で、サービスチャンネル等とは独立して伝送されるものである。
【００６９】
具体的には、図７に示すように、強制緊急起動フラグは、放送波を復調して得られるストリームにおいて、データ構造を示すためのプリアンブル信号の拡張用の領域に、1ビットで設定する。スリープ状態の受信機は、強制緊急起動フラグがオンとなっている場合には、電源をオンした上で、EATに応じた緊急告知処理を行うことになる。
【００７０】
なお、強制緊急起動フラグを、プリアンブル信号に含めるのは一例であって、他の信号に含めるようにしてもよい。また、強制緊急起動フラグは、全ての緊急情報を告知する場合に伝送する必要はなく、例えば、緊急度の高い緊急情報を告知する場合にのみ伝送するようにすることができる。
【００７１】
（基本的なシグナリング系統）
図８は、セクション形式のIP伝送方式における基本的なシグナリング系統を説明するための図である。
【００７２】
図８に示すように、LLSには、NIT，AMT，SAT，EAT，RRTが用いられる。NITとAMTは、例えば、伝送周期が1秒とされ、初期スキャンにおいて取得される。また、SATは、例えば、伝送周期が100ミリ秒とされ、サービスの選局時に取得される。
【００７３】
NITは、トリプレットにより放送ネットワーク内のトランスポートストリーム構成とサービス構成を示している。NITには、network_idとトランスポートストリームループが配置され、トランスポートストリームループ内にはさらに、サービスループが配置される。
【００７４】
AMTは、各サービスのIPアドレスを示している。また、SATは、オンエア中のサービスを示している。NITと、AMT，SATとは、service_idにより紐付けられており、例えば、NITとAMTを結合することで、選局情報が得られる。また、SATによって、特定のサービスがオンエア中であるかどうかを判定することができる。
【００７５】
EATは、緊急告知サービスを提供するための制御信号であって、ストリームごとに伝送される。受信機は、EATが伝送されている場合には、当該EATに応じた緊急告知処理を行う必要がある。RRTは、番組の分類に関する地域情報に関する情報を含んでいる。
【００７６】
また、図８に示すように、MLS(SCS)には、SMTが用いられる。SMTは、例えば伝送周期が100ミリ秒とされる。SMTは、各サービスのサービス単位のサービス属性、コンポーネントの構成情報、コンポーネント属性、コンポーネントのフィルタ情報を示しており、サービスごとに用意される。すなわち、例えば、AMTのIPアドレスと、SMTのポート番号を用いたフィルタリング処理を行うことで、特定のサービスのコンポーネント群を取得することができる。
【００７７】
さらに、図８に示すように、HLSとして、ESGがFLUTEセッションにより伝送される。ESGは、Access，Service，Content，Schedule，PurchaseItemなどから構成される電子サービスガイドである。そして、AMTのIPアドレスとSMTのポート番号に加えて、NITのESG_bootstrap情報に含まれるTSI(Transport Session Identifier)を用いることで、FLUTEセッションからESGを取得することができる。
【００７８】
＜（２）シグナリング情報＞
＜（２−１）LLS(NIT，AMT，SAT，EAT)の詳細構造＞
【００７９】
（NITのシンタックス）
図９は、NITのシンタックスを示す図である。
【００８０】
table_idは、テーブル識別を示す。section_syntax_indicatorは、1ビットのフィールドで、固定の値が指定される。section_lengthは、セクション長を示す。
【００８１】
network_idは、ネットワーク識別を示し、NITが示す分配システムを他の分配システムと区別して識別するラベルの役割をする。
【００８２】
version_numberは、バージョン番号を示す。current_next_indicatorは、カレントネクスト指示を示す。section_numberは、セクション番号を示す。last_section_numberは、最終セクション番号を示す。
【００８３】
network_descriptors_lengthは、ネットワーク記述子長を示す。transport_stream_loop_lengthは、トランスポートストリームループ長を示す。
【００８４】
transport_stream_idは、トランスポートストリーム識別を示す。original_network_idは、オリジナルネットワーク識別を示す。transport_descriptors_lengthは、トランスポート記述子長を示す。
【００８５】
図１０は、図９のNITのループ内に配置される記述子の例を示す図である。
【００８６】
図１０に示すように、NITのネットワークループ内には、Name_descriptorが必要に応じて配置される。また、NITのトランスポートストリームループ内には、Service_list_decriptor，ATSC3_delivery_system_descriptor，Transport_stream_protocol_descriptorが必ず配置され、Name_descriptor，ESG_bootstrap_descriptorが必要に応じて配置される。
【００８７】
図１０において、Name_descriptorは、文字符号により名称を提供する。また、Service_list_decriptorは、サービス識別とサービス形式種別によるサービスのリストを提供する。また、ATSC3_delivery_system_descriptorは、選局処理を行うための物理的な情報を提供する。
【００８８】
また、図１０において、Transport_stream_protocol_descriptorは、トランスポートストリームのプロトコルのタイプを提供する。また、ESG_bootstrap_descriptorは、FLUTEセッションにより伝送されるESGを取得するための情報を提供する。例えば、ESG_bootstrap_descriptorには、送信元（source）と宛先（destination）のIPアドレスを示すsource_IP_address，destination_IP_addressや、UDPのポート番号を示すUDP_port_num、FLUTEセッションにおけるTSIを示すTSIなどが記述される。
【００８９】
（AMTのデータ構造）
図１１は、AMTのシンタックスを示す図である。
【００９０】
table_idは、テーブル識別を示す。section_syntax_indicatorは、1ビットのフィールドで、固定の値が指定される。section_lengthは、セクション長を示す。
【００９１】
transport_stream_idは、トランスポートストリーム識別を示す。version_numberは、バージョン番号を示す。current_next_indicatorは、カレントネクスト指示を示す。section_numberは、セクション番号を示す。last_section_numberは、最終セクション番号を示す。number_of_servicesサービスの数を示す。
【００９２】
service_idは、サービス識別を示す。IP_version_flagは、IPバージョンのフラグを示す。例えば、IP_version_flagとして、"0"が指定された場合にIPv4を表し、"1"が指定された場合にIPv6を表すものとすることができる。
【００９３】
source_IP_address_for_v4，destination_IP_address_for_v4は、送信元（source）と宛先（destination）のバージョン4のIPアドレスを示す。また、source_IP_address_for_v6，destination_IP_address_for_v6は、送信元（source）と宛先（destination）のバージョン6のIPアドレスを示す。
【００９４】
なお、AMTにおいて、service_id="0xFFFF"が指定された場合には、サービスではなく、NTPパケットのIPアドレスを示すものとする。
【００９５】
（SATのシンタックス）
図１２は、SATのシンタックスを示す図である。
【００９６】
table_idは、テーブル識別を示す。section_syntax_indicatorは、1ビットのフィールドで、固定の値が指定される。section_lengthは、セクション長を示す。
【００９７】
transport_stream_idは、トランスポートストリーム識別を示す。version_numberは、バージョン番号を示す。current_next_indicatorは、カレントネクスト指示を示す。section_numberは、セクション番号を示す。last_section_numberは、最終セクション番号を示す。
【００９８】
service_idは、サービス識別を示す。ここに、オンエア中のサービスのservice_idが指定される。
【００９９】
（EATのシンタックス）
図１３は、EATのシンタックスを示す図である。ただし、図１４には、EATの構成情報が示されており、図１３の説明では、図１４の構成情報を適宜参照しながら説明する。
【０１００】
table_idは、テーブル識別を示す。section_syntax_indicatorは、1ビットのフィールドで、固定の値が指定される。section_lengthは、セクション長を示す。
【０１０１】
EA_categoryは、緊急警報(Emergency Alert)のカテゴリコードを示す。このコードは、フィルタリング目的に使用される。なお、このフィルタリング処理により、各ユーザが欲する緊急情報のみが告知されるようにすることができる。EA_categoryを用いたフィルタリング処理の詳細については、図２３乃至図２５を参照して後述する。
【０１０２】
version_numberは、バージョン番号を示す。current_next_indicatorは、カレントネクスト指示を示す。section_numberは、セクション番号を示す。last_section_numberは、最終セクション番号を示す。
【０１０３】
automatic_tuning_flagは、自動選局フラグを示す。この自動選局フラグは、強制緊急起動フラグがオンとなったときに、選局すべきサービスを指定するか否かを示している。自動選局フラグがオンとなる場合には、当該テーブル内のトリプレットにより指定されたサービスが自動で選局される。
【０１０４】
num_EAS_messagesは、当該テーブル内に含まれるEASメッセージの数を示す。
【０１０５】
network_id，transport_stream_id，service_idは、automatic_tuning_flag=1の場合に、選局すべきサービスを示す。すなわち、automatic_tuning_flag=1の場合、強制緊急起動フラグがオンとなったときに、このトリプレットにより指定されたサービスが自動で選局されることになる。
【０１０６】
EAS_message_idは、EASメッセージ識別を示す。EAS_priorityは、EASメッセージが複数ある場合のEASメッセージの優先度を示す。EAS_enforcement_flagは、対象のEASメッセージが、強制緊急起動フラグがオンになったときに、表示すべきEASメッセージかどうかを示す。
【０１０７】
ただし、EAS_enforcement_flagを用いずに、その内容をEAS_priorityに含めてもよい。例えば、EAS_priorityの8ビットで表される数値のうち、所定の数値以上であれば、強制緊急起動フラグがオンになったときに、表示すべきEASメッセージであるとしてもよい。
【０１０８】
EAS_IP_version_flagは、ストリームのIPバージョンのフラグを示す。例えば、EAS_IP_version_flagとして、"0"が指定された場合にIPv4を表し、"1"が指定された場合にIPv6を表すものとすることができる。ただし、このEAS_IP_version_flagは、後述のEAS_message_transfer_typeとして、"3"が指定された場合のIP_addressを対象とするものである。
【０１０９】
EAS_message_transfer_typeは、EASメッセージの伝送方式のタイプを示す。このタイプには、1〜5を指定することができる。
【０１１０】
EAS_message_transfer_typeとして、"1"が指定された場合、伝送方式が「NRTポータルサービス伝送」であることを示す。NRT(Non Real Time)ポータルサービス伝送は、FLUTEセッションにより伝送されるNRTポータル情報によって、緊急情報を伝送する方式である。なお、NRTポータル情報のサービス（チャンネル）は、HTML(Hyper Text Markup Language)形式のNRTポータル情報のみを常に送っている、いわばデータ放送のサービス（チャンネル）であるといえる。
【０１１１】
EAS_message_transfer_typeとして、"2"が指定された場合、伝送方式が「EASメッセージ伝送」であることを示す。EASメッセージ伝送は、EATのEASメッセージにCAP情報（緊急情報）を含めて伝送する方式である。また、EAS_message_transfer_typeとして、"3"が指定された場合、伝送方式が「ストリーム伝送」であることを示す。ストリーム伝送は、EAS以外のストリームによりCAP情報（緊急情報）を伝送する方式である。
【０１１２】
EAS_message_transfer_typeとして、"4"が指定された場合、伝送方式が「アプリケーション伝送」であることを示す。アプリケーション伝送は、テレビ番組に連動して実行されるアプリケーションを、緊急告知用のアプリケーションとして伝送する方式である。
【０１１３】
EAS_message_transfer_typeとして、"5"が指定された場合、伝送方式が「シェアドコンポーネントサービス伝送」であることを示す。シェアドコンポーネントサービス伝送は、指定された別のシェアドコンポーネントサービスで、緊急情報を伝送する方式である。
【０１１４】
EAS_message_encoding_typeは、EASメッセージのエンコーディング方式を示す。
【０１１５】
EAS_message_transfer_typeとして、"2"が指定された場合、EAS_message_lengthとEAS_message_bytes()が配置される。EAS_message_lengthは、EASメッセージ長を示す。EAS_message_bytes()は、EASメッセージのバイト数を示す。
【０１１６】
EAS_message_transfer_typeとして、"3"が指定された場合、IP_addressとUDP_port_numが配置される。IP_addressは、IPアドレスを示す。UDP_port_numは、ポート番号を示す。
【０１１７】
EAS_message_transfer_typeとして、"4"が指定された場合、EAS_application_identifierが配置される。EAS_application_identifierは、アプリケーション識別を示す。
【０１１８】
EAS_message_transfer_typeとして、"5"が指定された場合、EAS_shared_service_typeとEAS_shared_service_idが配置される。
【０１１９】
EAS_shared_service_typeは、EASメッセージを、シェアドコンポーネントサービスで伝送する場合の信号構成のタイプを示す。例えば、EAS_shared_service_typeとして、"1"が指定された場合、オーディオデータのみであることを表し、"2"が指定された場合、ビデオデータのみであることを表し、"3"が指定された場合、ビデオデータとオーディオデータの両方であることを表すものとすることができる。
【０１２０】
EAS_shared_service_idは、オーディオデータ、ビデオデータ、あるいはビデオデータとオーディオデータの両方を伝送する場合のservice_idを示す。
【０１２１】
EAS_NRT_service_idは、NRTポータル情報を伝送しているサービスのservice_idを示す。例えば、EAS_message_transfer_typeとして、"1"が指定されたとき、このservice_idにより指定されるサービスが選局され、NRTポータル情報（緊急情報）が取得される。また、例えば、EAS_message_transfer_typeとして、"2"や"3"が指定された場合に、詳細情報を表示する操作がなされたとき、このservice_idにより指定されるサービスが選局され、NRTポータル情報（詳細情報）が取得される。なお、NRTポータル情報を伝送しているサービスが存在しない場合には、固定のservice_id、すなわち、例えば、EAS_NRT_service_id="ffff"が指定されるようにすればよい。
【０１２２】
ここで、図１５乃至図１７を参照して、EATのEAS_message_transfer_typeとして、"2"又は"3"が指定された場合に伝送されるCAP情報の詳細について説明する。
【０１２３】
図１５に示すように、EASシステムにおいては、通常時、放送局内の送信機からのテレビ番組等の放送コンテンツ(AV contents)が、アンテナを介して放送信号として送信される。受信機は、送信機からの放送信号を、アンテナを介して受信し、テレビ番組等の放送コンテンツを視聴可能にする。
【０１２４】
一方、緊急時において、EASシステムでは、緊急情報としてのCAP情報が、放送局内のサーバに提供される。放送局内の送信機は、サーバからのCAP情報と、テレビ番組等の放送コンテンツとを多重化して、アンテナを介して、放送信号として送信する。受信機は、送信機からの放送信号を受信し、テレビ番組に、字幕などのCAP情報（図中の「Alert Message」）を重畳表示する。これにより、緊急時において、ユーザは、CAP情報を確認することができる。
【０１２５】
図１６は、CAP情報の構造を示している。図１６に示すように、CAP情報は、alert属性，info属性，resource属性，area属性などから構成される。また、図１７には、XML形式のCAP情報の記述例を示している。このようなCAP情報が、EAS_message_transfer_typeとして、"2"又は"3"が指定された場合に伝送されることになる。
【０１２６】
＜（２−２）SCS(SMT)の詳細構造＞
【０１２７】
（SMTのシンタックス）
図１８は、SMTのシンタックスを示す図である。
【０１２８】
table_idは、テーブル識別を示す。section_syntax_indicatorは、1ビットのフィールドで、固定の値が指定される。section_lengthは、セクション長を示す。
【０１２９】
service_idは、サービス識別を示す。version_numberは、バージョン番号を示す。current_next_indicatorは、カレントネクスト指示を示す。section_numberは、セクション番号を示す。last_section_numberは、最終セクション番号を示す。service_categoryは、サービスのカテゴリを示す。
【０１３０】
service_descriptor_lengthは、サービス記述子長を示す。base_UDP_port_numberは、RTPのポート番号を示す。なお、RTCP(RTP Control Protocol)のポート番号は、例えば、RTPのポート番号の値の次の値となる。component_info_lengthは、コンポーネント情報長を示す。
【０１３１】
図１９は、図１８のSMTのループ内に配置される記述子の例を示す図である。
【０１３２】
図１９に示すように、SMTのサービスループ内には、Name_descriptor，Protocol_version_descriptor，NRT_service_descriptor，Capabilities_descriptor，Icon_descriptor，ISO-639 language_descriptor，Receiver_targeting_descriptor，Adjunct_service_descriptor，Genre_descriptorが必要に応じて配置される。また、SMTのコンポーネントループ内には、コンポーネントごとに必要な情報を提供するためのComponent_descriptorが必ず配置される。
【０１３３】
＜（３）放送システムの構成＞
【０１３４】
（放送システムの構成例）
図２０は、本技術を適用した放送システムの一実施の形態の構成を示す図である。
【０１３５】
図２０に示すように、放送システム１は、送信装置１０、受信装置２０、アプリケーションサーバ５０、配信サーバ６０、及び、ウェブサーバ７０から構成される。受信装置２０と、アプリケーションサーバ５０、配信サーバ６０、及び、ウェブサーバ７０とは、インターネット９０を介して相互に接続されている。
【０１３６】
送信装置１０は、通常時において、テレビ番組等の放送コンテンツを、IP伝送方式を用いたデジタル放送の放送波によって送信する。また、送信装置１０は、緊急時において、緊急告知用の制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する。
【０１３７】
受信装置２０は、通常時において、送信装置１０から送信された放送信号を受信して、放送コンテンツの映像と音声を取得する。受信装置２０は、放送コンテンツの映像をディスプレイに表示するとともに、その映像に同期した音声をスピーカから出力する。
【０１３８】
また、受信装置２０は、緊急時において、送信装置１０から送信された放送信号を受信して、緊急告知用の制御信号を取得する。受信装置２０は、緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御して、緊急情報を告知する。ただし、緊急情報やその詳細情報は、送信装置１０から、IP伝送方式を用いたデジタル放送の放送波によって送信することができる。また、緊急情報や詳細情報は、映像及び音声の少なくとも１つによって告知される。
【０１３９】
なお、受信装置２０は、ディスプレイやスピーカを含んで単体として構成されるようにしてもよいし、テレビジョン受像機やビデオレコーダ等に内蔵されるようにしてもよい。
【０１４０】
アプリケーションサーバ５０は、放送コンテンツに連動して実行される緊急告知用のアプリケーションを管理している。アプリケーションサーバ５０は、受信装置２０からの要求に応じて、インターネット９０を介して、緊急告知用のアプリケーションを提供する。受信装置２０は、アプリケーションサーバ５０からの緊急告知用のアプリケーションを、放送コンテンツに連動して実行させる。
【０１４１】
配信サーバ６０は、放送済の放送番組や公開済みの映画などの通信コンテンツを、インターネット９０を介して、VOD(Video On Demand)により提供する。受信装置２０は、インターネット９０を介して配信サーバ６０から配信される通信コンテンツを受信する。受信装置２０は、通信コンテンツの映像をディスプレイに表示するとともに、その映像に同期した音声をスピーカから出力する。
【０１４２】
ウェブサーバ７０は、例えば、緊急情報やその詳細情報を、HTML形式のファイルとして管理している。ウェブサーバ７０は、受信装置２０からの要求に応じて、インターネット９０を介して、緊急情報や詳細情報を提供する。受信装置２０は、ウェブサーバ７０からの緊急情報や詳細情報を、ディスプレイに表示する。
【０１４３】
放送システム１は、以上のように構成される。
【０１４４】
（送信装置の構成例）
図２１は、本技術を適用した送信装置の一実施の形態の構成を示す図である。
【０１４５】
図２１に示すように、送信装置１０は、ビデオデータ取得部１１１、ビデオエンコーダ１１２、オーディオデータ取得部１１３、オーディオエンコーダ１１４、字幕データ取得部１１５、字幕エンコーダ１１６、制御信号取得部１１７、制御信号処理部１１８、ファイルデータ取得部１１９、ファイル処理部１２０、Mux１２１、及び、送信部１２２から構成される。
【０１４６】
ビデオデータ取得部１１１は、内蔵するストレージや外部のサーバ、カメラ等から、ビデオデータを取得し、ビデオエンコーダ１１２に供給する。ビデオエンコーダ１１２は、ビデオデータ取得部１１１から供給されるビデオデータを、MPEG等の符号化方式に準拠して符号化し、Mux１２１に供給する。
【０１４７】
オーディオデータ取得部１１３は、内蔵するストレージや外部のサーバ、マイクロフォン等からオーディオデータを取得し、オーディオエンコーダ１１４に供給する。オーディオエンコーダ１１４は、オーディオデータ取得部１１３から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、Mux１２１に供給する。
【０１４８】
字幕データ取得部１１５は、内蔵するストレージや外部のサーバ等から字幕データを取得し、字幕エンコーダ１１６に供給する。字幕エンコーダ１１６は、字幕データ取得部１１５から供給される字幕データを、所定の符号化方式に準拠して符号化し、Mux１２１に供給する。
【０１４９】
制御信号取得部１１７は、内蔵するストレージや外部のサーバ等から、LLSやSCS等の制御信号を取得し、制御信号処理部１１８に供給する。制御信号処理部１１８は、制御信号取得部１１７から供給される制御信号に対して、所定の信号処理を施し、Mux１２１に供給する。
【０１５０】
ファイルデータ取得部１１９は、非同期型のファイル形式のデータを伝送する場合には、内蔵するストレージや外部のサーバ等から、例えばNRTコンテンツやアプリケーション等のファイルデータを取得し、ファイル処理部１２０に供給する。ファイル処理部１２０は、ファイルデータ取得部１１９から供給されるファイルデータに対して、所定のファイル処理を施し、Mux１２１に供給する。例えば、ファイル処理部１２０は、ファイルデータ取得部１１９により取得されたファイルデータを、FLUTEセッションにより伝送するためのファイル処理を行う。
【０１５１】
Mux１２１は、ビデオエンコーダ１１２からのビデオデータ、オーディオエンコーダ１１４からのオーディオデータ、字幕エンコーダ１１６からの字幕データ、制御信号処理部１１８からの制御信号、及び、ファイル処理部１２０からのファイルデータを多重化してIP伝送方式のストリームを生成し、送信部１２２に供給する。
【０１５２】
送信部１２２は、Mux１２１から供給されるIP伝送方式のストリームを放送信号として、アンテナ１２３を介して送信する。
【０１５３】
（受信装置の構成例）
図２２は、本技術を適用した受信装置の一実施の形態の構成を示す図である。
【０１５４】
図２２に示すように、受信装置２０は、チューナ２１２、Demux２１３、クロック発生器２１４、ビデオデコーダ２１５、ビデオ出力部２１６、オーディオデコーダ２１７、オーディオ出力部２１８、字幕デコーダ２１９、FLUTE処理部２２０、ストレージ２２１、制御信号処理部２２２、NVRAM２２３、緊急告知制御部２２４、通信I/F２２５、ブラウザ２２６、及び、ストリーミング処理部２２７から構成される。
【０１５５】
チューナ２１２は、アンテナ２１１により受信された放送信号から、選局が指示されたサービスの放送信号を抽出して復調し、その結果得られるIP伝送方式のストリームを、Demux２１３に供給する。
【０１５６】
Demux２１３は、チューナ２１２から供給されるIP伝送方式のストリームを、ビデオデータ、オーディオデータ、字幕データ、及び、制御信号などに分離して、後段のブロックに出力する。具体的には、Demux２１３は、GSEフィルタ２５１、IPフィルタ２５２、UDPフィルタ２５３、及び、セクションフィルタバンク２５４から構成される。GSEフィルタ２５１は、GSEヘッダに基づいて、フィルタリング処理を行い、LLSをセクションフィルタバンク２５４に供給する。
【０１５７】
IPフィルタ２５２は、IPヘッダに基づいて、フィルタリング処理を行う。また、UDPフィルタ２５３は、UDPヘッダに基づいて、フィルタリング処理を行う。IPフィルタ２５２乃至UDPフィルタ２５３によるフィルタリング処理によって、NTPはクロック発生部２１４に供給され、SCSはセクションフィルタバンク２５４に供給される。さらに、ビデオデータ、オーディオデータ、字幕データは、ビデオデコーダ２１５、オーディオデコーダ２１７、字幕デコーダ２１９にそれぞれ供給される。また、各種のファイルデータは、FLUTE処理部２２０に供給される。
【０１５８】
セクションフィルタバンク２５４は、セクションヘッダに基づいて、フィルタリング処理を行い、LLSとSCSを適宜、制御信号処理部２２２に供給する。また、セクションフィルタバンク２５４は、LLSとして伝送されるセクション形式のEATを取得して、緊急告知制御部２２４に供給する。
【０１５９】
なお、IPフィルタ２５２は、１又は複数のIPアドレスによるフィルタリング処理を行い、コンポーネント(Audio/Video)、制御信号(SCS)、時刻情報(NTP)、電子サービスガイド(ESG)などの情報を、サービス単位で抽出することができる。
【０１６０】
クロック発生器２１４は、Demux２１３から供給されるNTPに基づいて、クロック信号を生成し、ビデオデコーダ２１５、オーディオデコーダ２１７、及び、字幕デコーダ２１９に供給する。
【０１６１】
ビデオデコーダ２１５は、クロック発生器２１４から供給されるクロック信号に基づいて、Demux２１３から供給されるビデオデータを、ビデオエンコーダ１１２（図２１）に対応する復号方式で復号して、ビデオ出力部２１６に供給する。ビデオ出力部２１６は、ビデオデコーダ２１５から供給されるビデオデータを、後段のディスプレイ（不図示）に出力する。これにより、ディスプレイには、例えば、テレビ番組の映像などが表示される。
【０１６２】
オーディオデコーダ２１７は、クロック発生器２１４から供給されるクロック信号に基づいて、Demux２１３から供給されるオーディオデータを、オーディオエンコーダ１１４（図２１）に対応する復号方式で復号して、オーディオ出力部２１８に供給する。オーディオ出力部２１８は、オーディオデコーダ２１７から供給されるオーディオデータを、後段のスピーカ（不図示）に供給する。これにより、スピーカからは、例えば、テレビ番組の映像に対応する音声が出力される。
【０１６３】
字幕デコーダ２１９は、クロック発生器２１４から供給されるクロック信号に基づいて、Demux２１３から供給される字幕データを、字幕エンコーダ１１６（図２１）に対応する復号方式で復号して、ビデオ出力部２１６に供給する。ビデオ出力部２１６は、字幕デコーダ２１９から字幕データが供給された場合、その字幕データを、ビデオデコーダ２１５からのビデオデータに合成し、後段のディスプレイ（不図示）に供給する。これにより、ディスプレイには、テレビ番組の映像とともに、その映像に対応した字幕が表示される。
【０１６４】
FLUTE処理部２２０は、制御信号処理部２２２からの制御に従い、Demux２１３から供給される各種のファイルデータから、ESG、緊急告知用のアプリケーション、NRTコンテンツなどを復元する。例えば、FLUTE処理部２２０は、復元したESG又はNRTコンテンツを、ストレージ２２１に記録する。また、例えば、FLUTE処理部２２０は、復元した緊急告知用のアプリケーションを、ブラウザ２２６に供給する。
【０１６５】
ストレージ２２１は、HDD(Hard Disk Drive)などの大容量の記録装置である。ストレージ２２１は、FLUTE処理部２２０などから供給される各種のデータを記録する。
【０１６６】
制御信号処理部２２２は、セクションフィルタバンク２５４から供給される制御信号(LLS，SCS)に基づいて、各部の動作を制御する。NVRAM２２３は、不揮発性メモリであって、制御信号処理部２２２からの制御に従い、各種のデータを記録する。
【０１６７】
緊急告知制御部２２４は、セクションフィルタバンク２５４から供給されるEATに基づいて、緊急告知サービスに対応する各部の動作を制御する。例えば、緊急告知制御部２２４は、EATのEAS_message_transfer_typeに応じて、受信装置２０の各部を制御して、緊急情報をディスプレイに表示させる。また、緊急告知制御部２２４は、チューナ２１２を常に監視しており、放送信号から強制緊急起動フラグのオンを検知した場合であって、受信装置２０がスリープ状態であるとき、受信装置２０の電源をオンする。
【０１６８】
通信I/F２２５は、インターネット９０を介してアプリケーションサーバ５０から緊急告知用のアプリケーションを受信し、ブラウザ２２６に供給する。また、通信I/F２２５は、インターネット９０を介してウェブサーバ７０から緊急情報又は詳細情報を受信し、ブラウザ２２６に供給する。
【０１６９】
ブラウザ２２６には、FLUTE処理部２２０から緊急告知用のアプリケーション、又は、通信I/F２２５から緊急告知用のアプリケーション、緊急情報若しくは詳細情報が供給される。ブラウザ２２６は、緊急告知用のアプリケーション、緊急情報、又は、詳細情報に応じたビデオデータを生成して、ビデオ出力部２１６に供給する。これにより、ディスプレイには、緊急告知用のアプリケーション、緊急情報、又は、詳細情報の映像が表示される。
【０１７０】
また、通信I/F２２５は、インターネット９０を介して配信サーバ６０から配信される通信コンテンツのデータを受信し、ストリーミング処理部２２７に供給する。ストリーミング処理部２２７は、通信I/F２２５から供給されるデータに対し、ストリーミング再生を行うために必要な各種の処理を施して、その結果得られるビデオデータをビデオ出力部２１６に供給し、オーディオデータをオーディオ出力部２１８に供給する。これにより、ディスプレイには、通信コンテンツの映像が表示され、その映像に同期した音声が、スピーカから出力される。
【０１７１】
なお、図２２の受信装置２０において、例えば、チューナ２１２、Demux２１３、クロック発生器２１４、ビデオデコーダ２１５、ビデオ出力部２１６、オーディオデコーダ２１７、オーディオ出力部２１８、字幕デコーダ２１９、ストレージ２２１、NVRAM２２３、及び、通信I/F２２５は、ハードウェアとして構成される。一方、受信装置２０において、例えば、FLUTE処理部２２０、制御信号処理部２２２、緊急告知制御部２２４、ブラウザ２２６、及び、ストリーミング処理部２２７は、CPU（図６７のCPU９０１）が実行するプログラムにより実現される。
【０１７２】
また、図２２の受信装置２０の構成では、ストレージ２２１は内蔵されているとして説明したが、外付けのストレージを用いるようにしてもよい。
【０１７３】
（フィルタリング処理の詳細）
次に、図２３を参照して、Demux２１３（図２２）による各パケットのフィルタリング処理の詳細について説明する。
【０１７４】
図２３に示すように、Demux２１３には、各種のヘッダ情報と、ペイロードとして、LLS、NTP、MLS(SCS)、各種のファイルデータ、又は、ビデオデータやオーディオデータを含んでいる各パケットが入力される。
【０１７５】
GSEヘッダには、IP又はSignalingを示すタイプ情報が含まれている。GSEフィルタ２５１は、GSEヘッダに含まれるタイプ情報に基づいて、フィルタリング処理を行う。図２３の例では、LLSのパケットのタイプ情報のみがSignalingとなり、他のパケットはIPとなるので、LLSのパケットのみがセクションフィルタバンク２５４に供給される。
【０１７６】
また、IPヘッダには、IPアドレス(IP Address)が含まれる。IPフィルタ２５２は、IPヘッダに含まれるIPアドレスに基づいて、フィルタリング処理を行う。図２３の例では、IPヘッダが付加されたパケットのうち、NTPのパケットのIPアドレスのみ異なるが、他のパケットのIPアドレスは同一のアドレスとなる。
【０１７７】
さらに、UDPヘッダには、ポート番号(Port Number)が含まれる。UDPフィルタ２５３は、UDPヘッダに含まれるポート番号に基づいて、フィルタリング処理を行う。図２３の例では、UDPヘッダが付加された各パケットのポート番号は異なっている。また、FLUTEセッションを利用して伝送されるパケットには、LCTヘッダが付加され、RTPセッションを利用して伝送されるパケットには、RTPヘッダが付加されている。
【０１７８】
そして、IPフィルタ２５２とUDPフィルタ２５３によって、IPアドレスとポート番号を用いたフィルタリング処理が行われることで、LCTヘッダが付加されていないNTPのパケットは、クロック発生器２１４に出力される。また、RTPヘッダが付加されたビデオデータとオーディオデータのパケットは、ビデオデコーダ２１５とオーディオデコーダ２１７にそれぞれ出力される。また、各種のファイルデータのパケットは、FLUTE処理部２２０に出力される。
【０１７９】
セクションフィルタバンク２５４には、LLSのパケットとMLS(SCS)のパケットが供給される。セクションフィルタバンク２５４は、それらのパケットに付加されたセクションヘッダに基づいて、フィルタリング処理を行う。ただし、セクションフィルタバンク２５４においては、フィルタ条件を満たしたパケットだけが、セクションフィルタバンク２５４内のバッファメモリに保持され、これはCPU（図６７のCPU９０１）からソフトウェアで間欠的に吸い上げられることになる。
【０１８０】
例えば、セクションフィルタバンク２５４は、EATのtable_idとEA_categoryのAND条件を用いたフィルタリング処理を行うことで、各ユーザが欲する緊急情報のみが選択的に告知されるようにすることができる。
【０１８１】
ここで、図２４及び図２５を参照して、図２３のセクションフィルタバンク２５４によって行われる、EA_categoryを用いたフィルタリング処理の詳細な内容について説明する。
【０１８２】
図２４に示すように、16ビットのEA_categoryのうち、上位2ビットはEA_priority，次の2ビットはEA_scope，さらに次の8ビットはArea_code，下位4ビットはCategory_codeを表している。
【０１８３】
図２５に示すように、EA_priorityは、緊急情報の緊急度を示す。EA_priorityには、0〜3の値が指定され、その値が大きくなるほど緊急度が高いことを意味する。例えば、"0"が「通常」で、"3"が「緊急度最大」であることを示す。
【０１８４】
EA_scopeは、緊急情報の対象地域を示す。EA_scopeには、0〜3の値が指定される。例えば、"0"が「当該地域のみ」、"1"が「他地域」、"2"が「広域」、"3"が「グローバル」をそれぞれ意味している。
【０１８５】
Area_codeは、所定の地域コードを示す。Area_codeには、放送局のサービスエリア内でさらに細かいエリアを指定する場合に、所定のエリア単位でコードを指定する。例えば、郡単位などで、コードが指定される。
【０１８６】
Category_codeは、緊急情報の種類を示す。例えば、"0"が「災害情報」、"1"が「交通情報」、"2"が「天候情報」、"3"が「通学バス」をそれぞれ意味している。
【０１８７】
例えば、ユーザはあらかじめ、EA_categoryによるフィルタ条件を受信装置２０に設定しておくことで、受信装置２０では、そのフィルタ条件に応じて、EAT単位でフィルタリングされた緊急情報のみが告知されることになる。具体的には、ある地域にとっては重要な緊急情報となるが、他の地域にとっては重要でない緊急情報となる場合があるので、EA_scopeやArea_codeにより、緊急情報に対する地域を限定することができる。また、例えば、Category_codeとして、"0"〜"2"を指定した場合には、災害情報、交通情報、及び、天候情報の緊急情報のみが告知され、通学バスの緊急情報は告知されないことになる。
【０１８８】
なお、図２３において、同一のサービスチャンネルとなる、MLS(SCS)、各種のファイルデータ、ビデオデータやオーディオデータのパケットは、同一のIPアドレスが付与されているので、IPフィルタ２５２は、それらのパケットを、NTPのパケットとともに出力することで、IPアドレスを用い、それらの制御信号やデータをパッケージ化することができる。
【０１８９】
＜（４）具体的な運用例＞
【０１９０】
次に、セクション形式のIP伝送方式のデジタル放送に対応した放送システム１の具体的な運用例について説明する。ただし、受信装置２０は、最初に起動する場合などに初期スキャン処理を実行して、NITとAMTからなる選局情報を取得し、NVRAM２２３等に保持しているものとする。
【０１９１】
＜（４−１）NRTポータルサービス伝送＞
まず、図２６及び図２７を参照して、スリープ状態又は起動状態の受信装置２０におけるNRTポータルサービス伝送について説明する。
【０１９２】
（スリープ状態時のNRTポータルサービス伝送処理）
図２６は、スリープ状態の受信装置２０におけるNRTポータルサービス伝送処理を説明する図である。
【０１９３】
図２６に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SMT）がセクション形式で伝送されている。
【０１９４】
図２６において、受信装置２０は、スリープ状態となっている（Ｓ１０１）。ここで、スリープ状態の受信装置２０は、常時、プリアンブル信号に含まれる強制緊急起動フラグを監視しており（Ｓ１０２）、緊急度の高い緊急情報を伝送する場合には、強制緊急起動フラグがオンされることになる。受信装置２０は、強制緊急起動フラグのオンを検知した場合、電源をオンして起動する（Ｓ１０３，Ｓ１０４）。
【０１９５】
また、受信装置２０は、デフォルトに設定されたBSで伝送されているLLSから、セクション形式のEATを取得する（Ｓ１０５，Ｓ１０６）。図２６に示すように、このEATには、EAS_message_transfer_type = "1"が指定されているため、緊急情報は、NRTポータルサービスのNRTポータル情報として伝送されている。したがって、受信装置２０は、EATのEAS_NRT_service_idと選局情報を用い、選局処理を行うことで、SMTを取得する（Ｓ１０７）。
【０１９６】
受信装置２０は、SMTに従い、FLUTEセッションにより伝送されているNRTポータル情報を取得して、そこから得られる緊急情報をディスプレイに表示する（Ｓ１０８，Ｓ１０９）。なお、このNRTポータル情報は、HTML形式のファイルデータであって、ブラウザ２２６によって表示されることになる。
【０１９７】
以上のように、図２６のNRTポータルサービス伝送処理においては、緊急時に、スリープ状態の受信装置２０が起動される。そして、受信装置２０は、LLSにより伝送されているセクション形式のEATを取得して、当該EATに応じて、NRTポータル情報を取得する。これにより、ディスプレイは、Ｄ１１−１の状態（黒画面）から強制的に、Ｄ１１−２の状態（「大雨警報」を表示した画面）となって、NRTポータル情報として伝送された緊急情報の画面が表示されることになる。その結果、テレビ番組を試聴していなかったユーザであっても、強制的に表示された緊急情報の画面を確認して、大雨警報が発動されたことを知ることができる。
【０１９８】
（起動状態時のNRTポータルサービス伝送処理）
図２７は、起動状態の受信装置２０におけるNRTポータルサービス伝送処理を説明する図である。
【０１９９】
図２７に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SMT）がセクション形式で伝送されている。
【０２００】
図２７において、受信装置２０は、上述した図２６の運用例と異なり、起動中であって、テレビ番組を表示している（Ｓ１２１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しているが、プリアンブル信号に含まれる強制緊急起動フラグのオンを検知した場合には、デフォルトのBSから、最新のEATを取得する（Ｓ１２２乃至Ｓ１２５）。図２７に示すように、このセクション形式のEATには、EAS_message_transfer_type = "1"が指定されているため、緊急情報は、NRTポータルサービスのNRTポータル情報として伝送されている。したがって、受信装置２０は、EATのEAS_NRT_service_idと選局情報を用い、選局処理を行うことで、SMTを取得する（Ｓ１２６）。
【０２０１】
受信装置２０は、SMTに従い、FLUTEセッションにより伝送されているNRTポータル情報を取得して、そこから得られる緊急情報をディスプレイに表示する（Ｓ１２７，Ｓ１２８）。
【０２０２】
以上のように、図２７のNRTポータルサービス伝送処理においては、テレビ番組を表示中の受信装置２０は、強制緊急起動フラグのオンを検知した場合、LLSにより伝送されているセクション形式のEATを取得して、当該EATに応じて、NRTポータル情報を取得する。これにより、ディスプレイは、Ｄ１２−１の状態（テレビ番組を表示した画面）から強制的に、Ｄ１２−２の状態（「大雨警報」を表示した画面）となって、NRTポータル情報として伝送された緊急情報の画面が表示されることになる。
【０２０３】
ただし、図２７の例では、緊急情報の画面に強制的に切り替える例を示したが、例えば、EATのEA_categoryのEA_priorityの示す緊急度が高い場合には、強制的に画面を切り替えるが、緊急度が低い場合には、緊急情報が有ること示すメッセージをテレビ番組に重畳して表示して、そのメッセージが選択された場合にのみ、緊急情報を表示させるようにしてもよい。その結果、テレビ番組を試聴しているユーザは、緊急情報の緊急度に応じて緊急情報の画面を確認して、大雨警報が発動されたことを知ることができる。
【０２０４】
＜（４−２）EASメッセージ伝送＞
次に、図２８及び図２９を参照して、EASメッセージ伝送について説明する。
【０２０５】
（スリープ状態時のEASメッセージ伝送処理）
図２８は、スリープ状態の受信装置２０におけるEASメッセージ伝送処理を説明する図である。
【０２０６】
図２８に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SMT）がセクション形式で伝送されている。
【０２０７】
図２８において、受信装置２０は、スリープ状態となっている（Ｓ１４１）。ここで、スリープ状態の受信装置２０は、常時、プリアンブル信号に含まれる強制緊急起動フラグを監視しており（Ｓ１４２）、強制緊急起動フラグのオンを検知した場合、電源をオンして起動する（Ｓ１４３，Ｓ１４４）。
【０２０８】
また、受信装置２０は、デフォルトに設定されたBSで伝送されているLLSから、セクション形式のEATを取得する（Ｓ１４５，Ｓ１４６）。図２８に示すように、このEATには、EAS_message_transfer_type = "2"が指定されているため、緊急情報は、EATに含まれるCAP情報として伝送されている。また、図２８のEATでは、automatic_tuning_flag = "1"が指定されているため、受信装置２０は、強制緊急起動フラグがオンとなったとき、トリプレット(network_id，transport_stream_id，service_id)により指定されるサービスを選局する選局処理を行い、SMTを取得する（Ｓ１４７）。
【０２０９】
受信装置２０は、SMTに従い、RTPセッションにより伝送されているビデオデータとオーディオデータを取得し（Ｓ１４８）、そのテレビ番組に、EATのCAP情報を重畳して、ディスプレイに表示する（Ｓ１４９）。
【０２１０】
以上のように、図２８のEASメッセージ伝送においては、緊急時に、スリープ状態の受信装置２０が起動される。そして、受信装置２０は、LLSにより伝送されているセクション形式のEATを取得して、当該EATに応じて、CAP情報と、テレビ番組のコンポーネントを取得する。これにより、ディスプレイは、Ｄ１３−１の状態（黒画面）から強制的に、Ｄ１３−２の状態（テレビ番組に字幕（CAP情報）を重畳した画面）となって、CAP情報として伝送された緊急情報の画面が表示されることになる。その結果、テレビ番組を試聴していなかったユーザであっても、強制的にテレビ番組に重畳表示された字幕を確認して、大雨警報が発動されたことを知ることができる。
【０２１１】
（起動状態時のEASメッセージ伝送処理）
図２９は、起動状態の受信装置２０におけるEASメッセージ伝送処理を説明する図である。
【０２１２】
図２９に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SMT）がセクション形式で伝送されている。
【０２１３】
図２９において、受信装置２０は、上述した図２８の運用例と異なり、起動中であって、テレビ番組を表示している（Ｓ１６１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しており、EATの更新を検出した場合には、そのEATを取得する（Ｓ１６２，Ｓ１６３）。図２９に示すように、このセクション形式のEATには、EAS_message_transfer_type = "2"が指定されているため、緊急情報は、EATに含まれるCAP情報として伝送されている。したがって、受信装置２０は、表示中のテレビ番組にEATのCAP情報を重畳して、ディスプレイに表示する（Ｓ１６４）。これにより、ユーザは、テレビ番組に重畳表示された字幕を確認して、大雨警報が発動されたことを知ることができる。
【０２１４】
ただし、この字幕の内容は、大雨警報が発動されたことのみを示すものであって、その詳細な情報を示すものではない。そのため、ユーザによるリモートコントローラの操作などにより、詳細情報の表示が指示された場合（Ｓ１６５）、緊急情報の追加情報として、大雨警報の詳細情報が表示されるようにする（Ｓ１６６乃至Ｓ１６８）。
【０２１５】
具体的には、受信装置２０は、EATのEAS_NRT_service_idと選局情報を用い、選局処理を行うことで、SMTを取得する（Ｓ１６６）。受信装置２０は、SMTに従い、FLUTEセッションにより伝送されているNRTポータル情報を取得して、そこから得られる緊急情報の詳細情報をディスプレイに表示する（Ｓ１６７，Ｓ１６８）。
【０２１６】
以上のように、図２９のEASメッセージ伝送においては、テレビ番組を表示中の受信装置２０は、EATの更新を検出した場合、LLSにより伝送されているセクション形式のEATを取得して、当該EATに応じて、CAP情報と、テレビ番組のコンポーネントを取得する。これにより、ディスプレイは、Ｄ１４−１の状態（テレビ番組を表示した画面）から、Ｄ１４−２の状態（テレビ番組に字幕（CAP情報）を重畳した画面）となって、CAP情報として伝送された緊急情報の字幕が画面に表示されることになる。その結果、テレビ番組を試聴しているユーザは、テレビ番組に重畳表示された字幕を確認して、大雨警報が発動されたことを知ることができる。
【０２１７】
また、テレビ番組に重畳表示された字幕を確認したユーザは、さらに深い天候に関する情報を知りたい場合には、所定の操作を行うことで、NRTポータル情報として伝送された緊急情報の詳細情報の画面（Ｄ１４−３の状態）が表示されることになる。その結果、ユーザは、字幕では表現しきれない情報を含む詳細情報を確認して、大雨警報に関するより深い情報を得ることができる。
【０２１８】
なお、図２９の例では、詳細情報はNRTポータル情報として、FLUTEセッションにより伝送されるとして説明したが、例えば、インターネット９０に接続されたウェブサーバ７０により提供されるようにしてもよい。
【０２１９】
＜（４−３）アプリケーション伝送＞
次に、図３０及び図３１を参照して、アプリケーション伝送について説明する。
【０２２０】
（スリープ状態時のアプリケーション伝送処理）
図３０は、スリープ状態の受信装置２０におけるアプリケーション伝送処理を説明する図である。
【０２２１】
図３０に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。さらに、LLS（EAT）やSCS（SMT，AIT）がセクション形式で伝送されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。
【０２２２】
図３０において、受信装置２０は、スリープ状態となっている（Ｓ１８１）。ここで、スリープ状態の受信装置２０は、常時、プリアンブル信号に含まれる強制緊急起動フラグを監視しており（Ｓ１８２）、強制緊急起動フラグのオンを検知した場合、電源をオンして起動する（Ｓ１８３，Ｓ１８４）。
【０２２３】
また、受信装置２０は、デフォルトに設定されたBSで伝送されているLLSから、セクション形式のEATを取得する（Ｓ１８５，Ｓ１８６）。図３０に示すように、このEATには、EAS_message_transfer_type = "4"が指定されているため、緊急情報は、緊急告知用のアプリケーションとして伝送されている。また、図３０のEATでは、automatic_tuning_flag = "1"が指定されているため、受信装置２０は、強制緊急起動フラグがオンとなったとき、トリプレットにより指定されるサービスを選局する選局処理を行い、SMTとAITを取得する（Ｓ１８７）。
【０２２４】
受信装置２０は、SMTに従い、RTPセッションにより伝送されているビデオデータとオーディオデータを取得する（Ｓ１８８）。また、受信装置２０は、AITを参照して、EATのEAS_application_identifierに対応するアプリケーションの取得先のURLを取得し、インターネット９０を介してアプリケーションサーバ５０にアクセスし、緊急告知用のアプリケーションを取得する（Ｓ１８９）。
【０２２５】
そして、受信装置２０は、取得したビデオデータとオーディオデータに応じたテレビ番組に、アプリケーションサーバ５０から取得した緊急告知用のアプリケーションを重畳して、ディスプレイに表示する（Ｓ１９０，Ｓ１９１）。
【０２２６】
以上のように、図３０のアプリケーション伝送処理においては、緊急時に、スリープ状態の受信装置２０が起動される。そして、受信装置２０は、LLSにより伝送されているセクション形式のEATを取得して、当該EATに応じて、テレビ番組のコンポーネントと、緊急告知用のアプリケーションを取得する。これにより、ディスプレイは、Ｄ１５−１の状態（黒画面）から強制的に、Ｄ１５−２の状態（テレビ番組に緊急告知用のアプリケーションを重畳した画面）となって、緊急告知用のアプリケーションとして伝送された緊急情報の画面が表示されることになる。その結果、テレビ番組を試聴していなかったユーザであっても、強制的にテレビ番組に重畳表示された緊急告知用のアプリケーションを確認して、大雨警報が発動されたことを知ることができる。
【０２２７】
なお、図３０のＤ１５−２の状態では、緊急告知用のアプリケーションは、テレビ番組に対して、Ｌ字表示されているが、例えば、アプリケーションをオーバーレイ表示されるようにするなど、他の表示形態を採用してもよい。また、緊急告知用のアプリケーションは、FLUTEセッションにより伝送するようにしてもよい。
【０２２８】
また、図３０の例では、アプリケーションの制御情報として、AITを説明したが、AITの代わりに、トリガ情報を用いるようにしてもよい。トリガ情報は、アプリケーションの動作を制御するためのコマンドを含む制御情報であって、例えば、ビデオデータやオーディオデータ内に配置することで、送信される。
【０２２９】
（起動状態時のアプリケーション伝送処理）
図３１は、起動状態の受信装置２０におけるアプリケーション伝送処理を説明する図である。
【０２３０】
図３１に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。さらに、LLS（EAT）やSCS（SMT，AIT）がセクション形式で伝送されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。
【０２３１】
図３１において、受信装置２０は、上述した図３０の運用例と異なり、起動中であって、テレビ番組を表示している（Ｓ２０１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しており、EATの更新を検出した場合には、そのEATを取得する（Ｓ２０２，Ｓ２０３）。図３１に示すように、このセクション形式のEATには、EAS_message_transfer_type = "4"が指定されているため、緊急情報は、緊急告知用のアプリケーションとして伝送されている。また、図３１のEATでは、automatic_tuning_flag = "1"が指定されているため、受信装置２０は、強制緊急起動フラグがオンとなったとき、トリプレットにより指定されるサービスを選局する選局処理を行い、AITを取得する（Ｓ２０４）。
【０２３２】
受信装置２０は、AITを参照して、EATのEAS_application_identifierに対応するアプリケーションの取得先のURLを取得し、インターネット９０を介してアプリケーションサーバ５０にアクセスし、緊急告知用のアプリケーションを取得する（Ｓ２０６）。そして、受信装置２０は、表示中のテレビ番組に、アプリケーションサーバ５０から取得した緊急告知用のアプリケーションを重畳して、ディスプレイに表示する（Ｓ２０５，Ｓ２０７，Ｓ２０８）。
【０２３３】
以上のように、図３１のアプリケーション伝送処理においては、テレビ番組を表示中の受信装置２０は、EATの更新を検出した場合、LLSにより伝送されているセクション形式のEATを取得して、当該EATに応じて、緊急告知用のアプリケーションを取得する。これにより、ディスプレイは、Ｄ１６−１の状態（テレビ番組を表示した画面）から、Ｄ１６−２の状態（テレビ番組に緊急告知用のアプリケーションを重畳した画面）となって、アプリケーションとして伝送された緊急情報の画面が表示されることになる。その結果、テレビ番組を試聴しているユーザは、テレビ番組にＬ字型に重畳表示された緊急告知用のアプリケーションを確認して、大雨警報が発動されたことを知ることができる。
【０２３４】
なお、緊急告知用のアプリケーションを起動する際に、他のアプリケーションが起動中である場合には、その起動中の他のアプリケーションを終了させてから、緊急告知用のアプリケーションを起動させることになる。
【０２３５】
＜（４−４）シェアドコンポーネントサービス伝送＞
次に、図３２及び図３３を参照して、シェアドコンポーネントサービス伝送について説明する。
【０２３６】
（起動状態時のシェアドコンポーネントサービス伝送処理）
図３２は、シェアドコンポーネントサービス伝送処理を説明する図である。
【０２３７】
図３２に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、緊急告知用の共有のオーディオデータが、RTPセッションにより伝送されている。さらに、LLS（EAT）やSCS（SMT）がセクション形式で伝送されている。
【０２３８】
図３２において、受信装置２０は、起動中であって、テレビ番組を表示している（Ｓ２２１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しており、EATの更新を検出した場合には、そのEATを取得する（Ｓ２２２，Ｓ２２３）。図３２に示すように、このセクション形式のEATには、EAS_message_transfer_type = "5"が指定されているため、緊急情報は、シェアドコンポーネントサービスにより伝送されている。
【０２３９】
すなわち、図３２のEATでは、EAS_shared_service_typeとして、"Audio"が指定されているため、緊急情報が緊急告知用の共有のオーディオデータとして提供されているので、受信装置２０は、EATのEAS_shared_service_idと選局情報を用い、選局処理を行うことで、SMTを取得する（Ｓ２４４）。そして、受信装置２０は、SMTに従い、RTPセッションにより伝送されている緊急告知用の共有のオーディオデータを取得して、テレビ番組を表示中に、緊急情報の共有の音声を出力する（Ｓ２２５，Ｓ２２６）。ここでは、例えば、テレビ番組を表示中に、音声のみが切り替わって、「大雨警報」などの音声が、副音声として出力される。
【０２４０】
以上のように、図３２のアプリケーション伝送処理においては、テレビ番組を表示中の受信装置２０は、EATの更新を検出した場合、LLSにより伝送されているセクション形式のEATを取得して、当該EATに応じて、緊急告知用の共有のオーディオデータを取得する。これにより、ディスプレイは、Ｄ１７−１の状態からＤ１７−２の状態になっても、テレビ番組を表示し続けているが、音声のみ切り替わって、「大雨警報」などの音声が緊急情報として出力されることになる。その結果、テレビ番組を試聴しているユーザは、テレビ番組を継続して視聴し続けながら、緊急情報の音声を確認して、大雨警報が発動されたことを知ることができる。
【０２４１】
図３３は、シェアドコンポーネントサービスの例を示す図である。
【０２４２】
図３３に示すように、TVサービス１とTVサービス２は、異なるサービスであるが、緊急時に告知される緊急告知用のオーディオデータは、同一のオーディオデータとなるので、共通のシェアドコンポーネントサービスにより提供することができる。
【０２４３】
具体的には、TVサービス１において、緊急時には、音声が、TVサービス１のオーディオデータから、共通のシェアドコンポーネントサービスのオーディオデータに切り替えられる。これにより、TVサービス１のテレビ番組を表示中に、シェアドコンポーネントサービスのオーディオデータによる緊急情報が音声として出力される。そして、緊急情報の音声の出力が終了すると、TVサービス１においては、シェアドコンポーネントサービスのオーディオデータから、TVサービス１のオーディオデータに戻されることになる。
【０２４４】
同様に、TVサービス２において、緊急時には、音声が、TVサービス２のオーディオデータから、共通のシェアドコンポーネントサービスのオーディオデータに切り替えられる。これにより、TVサービス２のテレビ番組を表示中に、シェアドコンポーネントサービスのオーディオデータによる緊急情報が音声として出力される。そして、緊急情報の音声の出力が終了すると、TVサービス２においては、シェアドコンポーネントサービスのオーディオデータから、TVサービス２のオーディオデータに戻されることになる。
【０２４５】
なお、図３３の例では、シェアドサービスとして伝送される共有のコンポーネントとして、１つのオーディオデータを一例に説明したが、オーディオデータに限らず、例えばビデオデータや字幕データなど、複数のサービス間で共有可能なコンポーネントであれば、他のコンポーネントあってもよい。また、シェアドサービスとして伝送される共有のコンポーネントとして、複数の共有のコンポーネントを伝送するようにしてもよい。
【０２４６】
＜（５）各装置で実行される具体的な処理の内容＞
【０２４７】
次に、図３４乃至図４０を参照して、図２０の放送システム１を構成する各装置で実行される具体的な処理の内容について説明する。
【０２４８】
（送信処理）
まず、図３４のフローチャートを参照して、図２０の送信装置１０により実行される送信処理について説明する。
【０２４９】
ステップＳ３０１において、ビデオデータ取得部１１１は、ビデオデータを取得し、ビデオエンコーダ１１２に供給する。ステップＳ３０２において、ビデオエンコーダ１１２は、ビデオデータ取得部１１１から供給されるビデオデータを符号化し、Mux１２１に供給する。
【０２５０】
ステップＳ３０３において、オーディオデータ取得部１１３は、オーディオデータを取得し、オーディオエンコーダ１１４に供給する。ステップＳ３０４において、オーディオエンコーダ１１４は、オーディオデータ取得部１１３から供給されるオーディオデータを符号化し、Mux１２１に供給する。
【０２５１】
ステップＳ３０５において、字幕データ取得部１１５は、字幕データを取得し、字幕エンコーダ１１６に供給する。ステップＳ３０６において、字幕エンコーダ１１６は、字幕データ取得部１１５から供給される字幕データを符号化し、Mux１２１に供給する。
【０２５２】
ステップＳ３０７において、制御信号取得部１１７は、SCSやLLS等の制御信号を取得し、制御信号処理部１１８に供給する。ステップＳ３０８において、制御信号処理部１１８は、制御信号取得部１１７から供給される制御信号に対し、所定の信号処理を施し、Mux１２１に供給する。
【０２５３】
ステップＳ３０９において、ファイルデータ取得部１１９は、非同期型のファイル形式のデータを伝送する場合には、例えばNRTコンテンツやアプリケーション等のファイルデータを取得し、ファイル処理部１２０に供給する。ステップＳ３１０において、ファイル処理部１２０は、ファイルデータ取得部１１９から供給されるファイルデータに対して、所定のファイル処理を施し、Mux１２１に供給する。
【０２５４】
ステップＳ３１１において、Mux１２１は、ビデオエンコーダ１１２からのビデオデータ、オーディオエンコーダ１１４からのオーディオデータ、字幕エンコーダ１１６からの字幕データ、制御信号処理部１１８からの制御信号、及び、ファイル処理部１２０からのファイルデータを多重化してIP伝送方式のストリームを生成し、送信部１２２に供給する。
【０２５５】
ステップＳ３１２において、送信部１２２は、Mux１２１から供給されるストリームを放送信号として、アンテナ１２３を介して送信する。ステップＳ３１２の処理が終了すると、送信処理は終了する。
【０２５６】
以上、送信処理について説明した。
【０２５７】
（受信処理）
次に、図３５のフローチャートを参照して、図２０の受信装置２０により実行される受信処理について説明する。この受信処理は、受信装置２０が起動され、ユーザによるリモートコントローラの操作により、所望のチャンネルが選局されたときなどに実行される。
【０２５８】
ステップＳ３２１において、チューナ２１２は、アンテナ２１１を介して放送信号を受信して、復調する。ステップＳ３２２において、Demux２１３は、チューナ２１２により復調されたIP伝送方式のストリームを、制御信号、ビデオデータ、オーディオデータ、字幕データなどに分離する。
【０２５９】
ステップＳ３２３において、制御信号処理部２２２は、Demux２１３により分離された制御信号を取得する。制御信号処理部２２２は、この制御信号に基づいて、各部の動作を制御する。
【０２６０】
ステップＳ３２４において、ビデオデコーダ２１５は、Demux２１３により分離されたビデオデータを復号し、ビデオ出力部２１６に供給する。ステップＳ３２５において、ビデオ出力部２１６は、ビデオデコーダ２１５から供給されるビデオデータを出力して、ディスプレイに映像を表示する。
【０２６１】
ステップＳ３２６において、オーディオデコーダ２１７は、Demux２１３により分離されたオーディオデータを復号し、オーディオ出力部２１８に供給する。ステップＳ３２７において、オーディオ出力部２１８は、オーディオデコーダ２１７から供給されるオーディオデータを出力して、スピーカから音声を出力する。
【０２６２】
ステップＳ３２８において、字幕デコーダ２１９は、Demux２１３により字幕データが分離された場合、その字幕データを復号し、ビデオ出力部２１６に供給する。ステップＳ３２９において、ビデオ出力部２１６は、字幕デコーダ２１９から供給される字幕データを出力して、ディスプレイに表示された映像に、字幕を重畳表示する。ステップＳ３２９の処理が終了すると、受信処理は終了する。
【０２６３】
以上、受信処理について説明した。
【０２６４】
（緊急告知処理）
次に、図３６のフローチャートを参照して、図２０の受信装置２０により実行される緊急告知処理について説明する。この緊急告知処理は、受信装置２０がスリープ状態又は起動状態などにある場合に、例えば大雨警報などの緊急情報を告知するときに実行される。
【０２６５】
ステップＳ３４１においては、受信装置２０がスリープ状態であるかどうかが判定される。ステップＳ３４１において、受信装置２０がスリープ状態であると判定された場合、処理は、ステップＳ３４２に進められる。
【０２６６】
ステップＳ３４２において、緊急告知制御部２２４は、チューナ２１２を監視することで、プリアンブル信号に含まれる強制緊急起動フラグのオンを検知したかどうかを判定する。ステップＳ３４２において、強制緊急起動フラグのオンを検知したと判定された場合、処理は、ステップＳ３４３に進められ、受信装置２０の電源がオンされる。受信装置２０の電源がオンされると、処理は、ステップＳ３４４に進められる。
【０２６７】
また、ステップＳ３４２において、強制緊急起動フラグのオンを検知していないと判定された場合、処理は、ステップＳ３４１に戻り、上述した処理が繰り返される。すなわち、スリープ状態の受信装置２０は、強制緊急起動フラグがオンされるのを待って、電源がオンされることになる。また、ステップＳ３４１において、受信装置２０がスリープ状態ではない、すなわち、受信装置２０が起動状態で、テレビ番組を表示している場合、ステップＳ３４２乃至Ｓ３４３はスキップされ、処理は、ステップＳ３４４に進められる。
【０２６８】
ステップＳ３４４において、緊急告知制御部２２４は、LLSにより伝送されているセクション形式のEATを取得する。このEATを取得するタイミングとしては、例えば、スリープ状態の受信装置２０の電源がオンされた直後や強制緊急起動フラグのオンを検知したとき、EATが更新されたときなどが想定される。
【０２６９】
ステップＳ３４５において、緊急告知制御部２２４は、ステップＳ３４４の処理で取得したセクション形式のEATのEAS_message_transfer_typeをチェックする。
【０２７０】
ステップＳ３４６において、緊急告知制御部２２４は、ステップＳ３４５のチェック処理で、EAS_message_transfer_type = "1"となったかどうかが判定する。ステップＳ３４６において、EAS_message_transfer_type = "1"であると判定された場合、処理は、ステップＳ３４７に進められる。
【０２７１】
ステップＳ３４７において、緊急告知制御部２２４は、NRTポータルサービス伝送処理を実行する。このNRTポータルサービス伝送処理は、上述した図２６及び図２７の運用例に対応するものであって、その詳細な処理の内容は、図３７のフローチャートを参照して後述する。
【０２７２】
また、ステップＳ３４６において、EAS_message_transfer_type = "1"ではないと判定された場合、処理は、ステップＳ３４８に進められる。ステップＳ３４８において、緊急告知制御部２２４は、ステップＳ３４５のチェック処理で、EAS_message_transfer_type = "2"となったかどうかを判定する。ステップＳ３４８において、EAS_message_transfer_type = "2"であると判定された場合、処理は、ステップＳ３４９に進められる。
【０２７３】
ステップＳ３４９において、緊急告知制御部２２４は、EASメッセージ伝送処理を実行する。このEASメッセージ伝送処理は、上述した図２８及び図２９の運用例に対応するものであって、その詳細な処理の内容は、図３８のフローチャートを参照して後述する。
【０２７４】
また、ステップＳ３４８において、EAS_message_transfer_type = "2"ではないと判定された場合、処理は、ステップＳ３５０に進められる。ステップＳ３５０において、緊急告知制御部２２４は、ステップＳ３４５のチェック処理で、EAS_message_transfer_type = "4"となったかどうかを判定する。ステップＳ３５０において、EAS_message_transfer_type = "4"であると判定された場合、処理は、ステップＳ３５１に進められる。
【０２７５】
ステップＳ３５１において、緊急告知制御部２２４は、アプリケーション伝送処理を実行する。このアプリケーション伝送処理は、上述した図３０及び図３１の運用例に対応するものであって、その詳細な処理の内容は、図３９のフローチャートを参照して後述する。
【０２７６】
また、ステップＳ３５０において、EAS_message_transfer_type = "4"ではないと判定された場合、処理は、ステップＳ３５２に進められる。ステップＳ３５２において、緊急告知制御部２２４は、ステップＳ３４５のチェック処理で、EAS_message_transfer_type = "5"となったかどうかを判定する。ステップＳ３５２において、EAS_message_transfer_type = "5"であると判定された場合、処理は、ステップＳ３５３に進められる。
【０２７７】
ステップＳ３５３において、緊急告知制御部２２４は、シェアドコンポーネントサービス伝送処理を実行する。このシェアドコンポーネントサービス伝送処理は、上述した図３２の運用例に対応するものであって、その詳細な処理の内容は、図４０のフローチャートを参照して後述する。
【０２７８】
また、ステップＳ３５２において、EAS_message_transfer_type = "5"ではないと判定された場合、処理は、ステップＳ３５４に進められる。ステップＳ３５４において、緊急告知制御部２２４は、EAS_message_transfer_typeに対応するその他の処理を実行する。例えば、EAS_message_transfer_type = "3"となる場合には、ストリーム伝送処理が実行されることになる。
【０２７９】
ステップＳ３４７，Ｓ３４９，Ｓ３５１，Ｓ３５３，Ｓ３５４のいずれかの処理が終了すると、緊急告知処理は終了する。
【０２８０】
以上、緊急告知処理について説明した。
【０２８１】
（NRTポータルサービス伝送処理）
次に、図３７のフローチャートを参照して、図３６のステップＳ３４７に対応するNRTポータルサービス伝送処理について説明する。
【０２８２】
ステップＳ３６１において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、SMTを取得する。
【０２８３】
ステップＳ３６２において、FLUTE処理部２２０は、緊急告知制御部２２４からの制御に従い、制御信号処理部２２２からのSMTに基づいて、FLUTEセッションにより伝送されるNRTポータル情報（緊急情報）を取得する。
【０２８４】
ステップＳ３６３において、ブラウザ２２６は、緊急告知制御部２２４からの制御に従い、FLUTE処理部２２０からのNRTポータル情報（緊急情報）を、ビデオ出力部２１６を介してディスプレイに表示する。これにより、ディスプレイには、例えば大雨警報等の緊急情報が表示されることになる。
【０２８５】
ステップＳ３６３の処理が終了すると、処理は、図３６のステップＳ３４７に戻り、それ以降の処理が実行される。
【０２８６】
以上、NRTポータルサービス伝送処理について説明した。
【０２８７】
（EASメッセージ伝送処理）
次に、図３８のフローチャートを参照して、図３６のステップＳ３４９に対応するEASメッセージ伝送処理について説明する。ただし、受信装置２０がスリープ状態である場合には、電源がオンされるが、EATのautomatic_tuning_flagとして、"1"が指定されているため、トリプレットにより指定されるサービスを選局する選局処理が行われているものとする。
【０２８８】
ステップＳ３８１において、緊急告知制御部２２４は、EATに含まれるCAP情報をテレビ番組に重畳して、ビデオ出力部２１６を介してディスプレイに表示する。これにより、例えば大雨警報等の字幕（緊急情報）がテレビ番組に重畳表示される。
【０２８９】
ステップＳ３８２においては、ユーザによるリモートコントローラの操作などにより、詳細情報の表示が指示されたかどうかが判定される。ステップＳ３８２において、詳細情報の表示が指示されたと判定された場合、処理は、ステップＳ３８３に進められる。
【０２９０】
ステップＳ３８３において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、SMTを取得する。
【０２９１】
ステップＳ３８４において、FLUTE処理部２２０は、緊急告知制御部２２４からの制御に従い、制御信号処理部２２２からのSMTに基づいて、FLUTEセッションにより伝送されるNRTポータル情報（詳細情報）を取得する。
【０２９２】
ステップＳ３８５において、ブラウザ２２６は、緊急告知制御部２２４からの制御に従い、FLUTE処理部２２０からのNRTポータル情報（詳細情報）を、ビデオ出力部２１６を介してディスプレイに表示する。これにより、ディスプレイには、緊急情報の追加情報として、例えば大雨警報等の詳細情報が表示されることになる。
【０２９３】
また、ステップＳ３８２において、詳細情報の表示が指示されていないと判定された場合、ステップＳ３８３乃至Ｓ３８５の処理はスキップされる。そして、ステップＳ３８５の処理が終了すると、処理は、図３６のステップＳ３４９に戻り、それ以降の処理が実行される。
【０２９４】
以上、EASメッセージ伝送処理について説明した。
【０２９５】
（アプリケーション伝送処理）
次に、図３９のフローチャートを参照して、図３６のステップＳ３５１に対応するアプリケーション伝送処理について説明する。ただし、受信装置２０がスリープ状態である場合には、電源がオンされるが、EATのautomatic_tuning_flagとして、"1"が指定されているため、トリプレットにより指定されるサービスを選局する選局処理が行われているものとする。
【０２９６】
ステップＳ４０１において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、AITを取得する。また、緊急告知制御部２２４は、AITを参照して、EATのEAS_application_identifierに対応する緊急告知用のアプリケーションの取得先のURLを取得する。
【０２９７】
ステップＳ４０２において、通信I/F２２５は、緊急告知制御部２２４からの制御に従い、緊急告知用のアプリケーションの取得先のURLに基づいて、インターネット９０を介してアプリケーションサーバ５０にアクセスし、緊急告知用のアプリケーションを取得する。
【０２９８】
ステップＳ４０３において、ブラウザ２２６は、緊急告知制御部２２４からの制御に従い、通信I/F２２５からの緊急告知用のアプリケーションをテレビ番組に重畳して、ビデオ出力部２１６を介してディスプレイに表示する。これにより、例えば大雨警報等の緊急情報が、テレビ番組に対してＬ字表示されることになる。
【０２９９】
ステップＳ４０３の処理が終了すると、処理は、図３６のステップＳ３５１に戻り、それ以降の処理が実行される。
【０３００】
以上、アプリケーション伝送処理について説明した。
【０３０１】
（シェアドコンポーネントサービス伝送処理）
次に、図４０のフローチャートを参照して、図３６のステップＳ３５３に対応するシェアドコンポーネントサービス伝送処理について説明する。ただし、ここでは、EATのEAS_shared_service_typeとして、"Audio"が指定され、緊急情報が、緊急告知用の共有のオーディオデータとして提供されているものとする。
【０３０２】
ステップＳ４２１において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、SMTを取得する。
【０３０３】
ステップＳ４２２において、オーディオデコーダ２１７は、緊急告知制御部２２４からの制御に従い、SMTに基づいて、Demux２１３からの緊急告知用の共有のオーディオデータを取得する。また、オーディオデコーダ２１７は、緊急告知制御部２２４からの制御に従い、緊急告知用の共有のオーディオデータを復号し、オーディオ出力部２１８に供給する。
【０３０４】
ステップＳ４２３において、オーディオ出力部２１８は、緊急告知制御部２２４からの制御に従い、テレビ番組の音声を、緊急告知用の共有のオーディオデータをに切り替えて、スピーカから緊急情報の音声を出力する。これにより、例えば、テレビ番組の表示中に、音声のみが切り替わって、「大雨警報」などの音声が出力される。
【０３０５】
ステップＳ４２３の処理が終了すると、処理は、図３６のステップＳ３５３に戻り、それ以降の処理が実行される。
【０３０６】
以上、シェアドコンポーネントサービス伝送処理について説明した。
【０３０７】
＜２．XML形式のIP伝送方式によるデジタル放送＞
【０３０８】
次に、XML形式のIP伝送方式について説明する。
【０３０９】
（XML形式のIP伝送方式におけるプロトコルスタック）
図４１は、XML形式のIP伝送方式のデジタル放送のプロトコルスタックを示す図である。
【０３１０】
図４１に示すように、最も下位の階層は、物理層とされ、サービス（チャンネル）のために割り当てられた放送波の周波数帯域がこれに対応する。物理層に隣接する上位の階層は、BBPストリーム(Base Band Packet Stream)を挟んでIP層とされる。BBPストリームは、IP伝送方式における各種のデータを格納したパケットを含むストリームである。
【０３１１】
IP層は、TCP/IPのプロトコルスタックにおけるIPと同じものであり、IPアドレスによりIPパケットが特定される。IP層に隣接する上位階層はUDP層とされ、さらにその上位の階層は、RTP，FLUTE/ALSとされる。すなわち、IP伝送方式のデジタル放送においては、UDPのポート番号が指定されたパケットが送信され、例えばRTPセッションやFLUTEセッションが確立されるようになされている。
【０３１２】
FLUTE/ALSに隣接する上位階層は、fMP4(Fragmented MP4)とされ、さらに、RTP，fMP4に隣接する上位階層は、ビデオデータ(Video)、オーディオデータ(Audio)、字幕データ(Closed Caption)等とされる。すなわち、ビデオデータやオーディオデータを、同期型のストリーム形式で伝送する場合には、RTPセッションが利用され、ビデオデータやオーディオデータを、非同期型のファイル形式で伝送する場合には、FLUTEセッションが利用される。
【０３１３】
また、FLUTE/ALSの上位階層は、NRTコンテンツ(NRT Content)，ESG，SCSとされ、NRTコンテンツ，ESG，SCSは、FLUTEセッションにより伝送される。NRTコンテンツは、NRT(Non-RealTime)放送で伝送されるコンテンツであって、受信機のストレージに一旦蓄積された後で、再生が行われる。なお、NRTコンテンツは、コンテンツの一例であって、他のコンテンツのファイルがFLUTEセッションにより伝送されるようにしてもよい。ESG(Electronic Service Guide)は、電子サービスガイドであって、例えば、番組タイトルや開始時刻などの情報が含まれる。
【０３１４】
SCS(Service Channel Signaling)は、サービス単位のシグナリング情報であって、FLUTEセッションにより伝送される。例えば、SCSとしては、SDP(Session Description Protocol)やAIT(Application Information Table)などが伝送される。SDPは、サービス単位のサービス属性、コンポーネントの構成情報、コンポーネント属性、コンポーネントのフィルタ情報、コンポーネントのロケーション情報などを含んでいる。AITは、テレビ番組に連動して実行されるアプリケーションの制御情報である。なお、サービス(Service)とコンポーネント(Component)との関係については、図４２を参照して後述する。
【０３１５】
LLS(Low Layer Signaling)は、低レイヤのシグナリング情報であって、BBPストリーム上で伝送される。例えば、LLSとしては、SCT(Service Configuration Table)やSAT(Service Association Table)，EAT(Emergency Alert Table)，RRT(Region Rating Table)などのサービス構成情報(Service Configuration Information)が伝送される。
【０３１６】
SCTは、MPEG2-TS方式で用いられているnetwork_id，transport_stream_id，service_idの組み合わせであるトリプレット(Triplet)を採用し、このトリプレットによって、放送ネットワーク内のBBPストリーム構成とサービス構成が示される。また、SCTには、サービス単位の属性・設定情報としてのIPアドレス等の情報や、ESGやSCSにアクセスするためのbootstrap情報、さらには、サービス（チャンネル）を選局するための選局情報などが含まれる。
【０３１７】
SATは、BBPストリームごとのオンエア中のサービスを示す。SATによって、特定のサービスがオンエア中（放送中）であるかどうかを判定することができる。EATは、BBPストリームごとに、緊急告知用のサービスを付加するための制御信号である。RRTは、番組の分類に関する地域情報テーブルを示す。
【０３１８】
（XML形式のIP伝送方式におけるID体系）
図４２は、放送波の信号とXML形式のIP伝送方式のID体系との関係を示す図である。
【０３１９】
図４２に示すように、6MHzの周波数帯域を有する放送波（放送ネットワーク(Network)）には、network_idが割り当てられている。各放送波には、BBP_stream_idにより識別される、１又は複数のBBPストリームが含まれている。BBPストリームは、BBPヘッダとペイロードからなる複数のBBPパケットにより構成される。
【０３２０】
各BBPストリームには、service_idにより識別される複数のサービス(Service)が含まれている。各サービスは、１又は複数のコンポーネント(Component)から構成されている。各コンポーネントは、例えば、ビデオデータやオーディオデータ等の番組を構成する情報である。
【０３２１】
このように、XML形式のIP伝送方式のID体系として、MPEG2-TS方式と同様にトリプレットを採用して、network_id，BBP_stream_id，service_idの組み合わせを用いることで、現在広く普及しているMPEG2-TS方式との整合をとることができるため、例えば、MPEG2-TS方式からIP伝送方式への移行時のサイマルキャストに容易に対応することが可能となる。
【０３２２】
（XML形式のIP伝送方式の放送波の構成）
図４３は、XML形式のIP伝送方式のデジタル放送の放送波の構成を示す図である。
【０３２３】
図４３に示すように、6MHzの周波数帯域を有する放送波(図中の「Network」)から、１又は複数のBBPストリームを取得することができる。また、各BBPストリームから、NTP(Network Time Protocol)、複数のサービスチャンネル(Service Channel)、電子サービスガイド(ESG Service)、及び、LLSを取得することができる。ただし、NTP，サービスチャンネル，電子サービスガイドは、UDP/IPのプロトコルに従って伝送されるが、LLSは、BBPストリーム上で伝送される。また、NTPは、時刻情報であって、複数のサービスチャンネルで共通のものとなる。
【０３２４】
各サービスチャンネルには、ビデオデータやオーディオデータ等のコンポーネント(Component)と、SDPやAIT等のSCSが含まれる。また、各サービスチャンネルには、共通のIPアドレスが付与されており、このIPアドレスを用いて、サービスチャンネルごとに、コンポーネントや制御信号などをパッケージ化することができる。
【０３２５】
なお、図４３において、BBPストリーム(BBP Stream)とコンポーネント(Component)は、図４２に対応しているが、サービスチャンネル(Service Channel)は、図４２のサービス(Service)に相当するものである。
【０３２６】
（LLSの構成）
図４４は、XML形式のIP伝送方式におけるLLSの構成を示す図である。
【０３２７】
図４４に示すように、BBPパケットは、BBPヘッダとペイロードから構成される。BBPストリームによりIPパケットを伝送する場合には、ペイロードの部分がIPパケットとなる。
【０３２８】
また、BBPストリームによりLLSを伝送する場合には、BBPヘッダの次にLLSが配置される。LLSとしては、例えば、XML形式で記述されたSCTやSAT等が配置されるが、そのデータの一部のXMLフラグメント(XML fragment)をLLS本体として、SGDUヘッダが付加される。これにより、SCTやSATは、SGDUコンテナ(Service Guide Delivery Unit Container)により伝送されることになる。なお、SGDUは、OMA(Open Mobile Alliance)の規格として採用されている。
【０３２９】
なお、BBPヘッダには、2ビットのタイプ情報が含まれており、そのタイプ情報によって、BBPパケットがIPパケットであるか、LLSであるかを区別することができる。
【０３３０】
（SCSの構成）
図４５は、XML形式のIP伝送方式におけるにおけるSCSの構成を示す図である。
【０３３１】
図４５に示すように、例えば、ビデオデータやオーディオデータを、同期型のストリーム形式で伝送する場合には、RTPセッションが利用されるため、BBP，IP，UDP，RTPの各ヘッダがペイロードに付加される。また、fMP4やESG，NRTコンテンツ等のファイルデータを、非同期型のファイル形式で伝送する場合には、FLUTEセッションが利用されるため、BBP，IP，UDP，LCTの各ヘッダがペイロードに付加される。さらに、NTPは、UDP層の上位階層となるため、BBP，IP，UDPの各ヘッダの次に配置される。
【０３３２】
SCSは、FLUTEセッションを利用して伝送されるため、BBP，IP，UDP，LCTの各ヘッダの次に配置される。SCSとしては、例えば、テキスト形式で記述されるSDP等が配置されるが、そのデータの一部のSDPフラグメント(SDP fragment)をSCS本体として、SGDUヘッダが付加される。これにより、SDPは、SGDUコンテナにより伝送されることになる。なお、SCS本体として配置されるのは、SDPフラグメントに限らず、例えばXML形式で記述されたAITのXMLフラグメント(XML fragment)を配置して、SGDUコンテナにより伝送されるようにしてもよい。
【０３３３】
（基本的なシグナリング系統）
図４６は、XML形式のIP伝送方式における基本的なシグナリング系統を説明するための図である。
【０３３４】
図４６に示すように、LLSには、SCT，SAT，EAT，RRTが用いられる。SCTは、例えば、伝送周期が1秒とされ、初期スキャンにより取得されるか、あるいはインターネット９０上の専用のサーバ（不図示）から取得される。また、SATは、例えば、伝送周期が100ミリ秒とされ、サービスの選局時に取得される。
【０３３５】
SCTは、トリプレットにより放送ネットワーク内のトランスポートストリーム(BBPストリーム)構成とサービス構成を示している。SCTには、network_idのほか、BBP_stream_idにより識別されるトランスポートストリームループが配置される。また、トランスポートストリームループ内には、ESG_bootstrap情報のほか、service_idにより識別されるサービスループが配置される。サービスループ内にはさらに、各サービスのIPアドレスやSCS_bootstrap情報が配置される。また、図示はしていないが、SCTには、物理層(Physical Layer)に関する情報等も含まれており、選局情報として用いられる。
【０３３６】
SATは、オンエア中のサービスを示している。SCTとSATは、service_idにより紐付けられており、特定のサービスがオンエア中であるかどうかを判定することができる。また、EATは、緊急告知サービスを提供するための制御信号であって、ストリームごとに伝送される。受信機は、EATが伝送されている場合には、当該EATに応じた緊急告知処理を行う必要がある。RRTは、番組の分類に関する地域情報テーブルを示している。
【０３３７】
また、図４６に示すように、SCSには、USDとSDPが用いられる。SDPは、例えば伝送周期が100ミリ秒とされる。USD(User Service Description)は、SDPを取得するための情報である。SDPは、各サービスのサービス単位のサービス属性、コンポーネントの構成情報、コンポーネント属性、コンポーネントのフィルタ情報、コンポーネントのロケーション情報を示しており、サービスごとに用意される。
【０３３８】
図４６の例では、SDPは、FLUTEセッションにより伝送されているので、サービスのIPアドレスと、SCS_bootstrap情報に含まれるSDPを伝送するポート番号とTSI(Transport Session Identifier)を用いることで、FLUTEセッションからSDPを取得することができる。そして、SDPには、コンポーネントを取得するための情報が記述されているので、それらの情報に基づいて、コンポーネントにアクセスすることで、例えばビデオデータやオーディオデータがサービス単位で取得されることになる。
【０３３９】
さらに、図４６の例では、ESGが、FLUTEセッションにより伝送されている。ESGは、Access，Service，Content，Schedule，PurchaseItemなどから構成される電子サービスガイドである。そして、SCTのESG_bootstrap情報に含まれるESGを伝送するIPアドレス、ポート番号、TSI(Transport Session Identifier)を用いることで、FLUTEセッションからESGを取得することができる。
【０３４０】
また、ESGのAccessテーブルには、SDPのURL(Uniform Resource Locator)情報が記述されている。そして、SDPはFLUTEセッションにより伝送されているため、そのURLを解決することが可能であるので、ESGのURL情報から特定のSDP(USD)を指定することができる。この場合、LLSを介することなく、ESGとSDPが紐付けられることになるので、例えば、特定のアーキテクチャに対応した機器では、LLSがなくても動作することが可能となる。
【０３４１】
なお、上述したように、LLS(SCT，SAT，EAT，RRT)と、SCS(USD，SDP)は、SGDUコンテナにより伝送されるが、ESGもSGDUコンテナにより伝送されているため、それらの伝送方式を統一させることができる。
【０３４２】
（SGDUの構造）
図４７は、SGDUの構造を説明するための図である。
【０３４３】
図４７に示すように、SGDU(Service Guide Delivery Unit)は、ヘッダ情報(Unit_Header)とペイロード(Unit_Payload)から構成される。また、SGDUでは必要に応じて、拡張情報(extension_data)が配置される。
【０３４４】
ヘッダ情報には、fragmentTransportIDとfragmentVersionが配置される。fragmentTransportIDは、フラグメント識別を示す。例えば、fragmentTransportIDにより、SCTやSDPなどが識別される。また、fragmentVersionは、フラグメントのバージョン番号を示す。
【０３４５】
ペイロードには、XMLフラグメント(XML fragment)及びSDPフラグメント(SDP fragment)の少なくとも一方の実データが配置される。すなわち、ヘッダ情報のn_o_service_guide_fragmentsにより指定された数に応じた１又は複数のフラグメントのデータがペイロードに配置されることになる。ここでは、例えば、XMLフラグメントとSDPフラグメントの両方のフラグメントが配置されるようにするなど、ペイロードに配置される複数のフラグメントの組み合わせは任意である。また、ヘッダ情報のoffsetによって、複数配置されたフラグメントのうち、任意のフラグメントの位置を示すことができる。
【０３４６】
ただし、XMLフラグメントを配置する場合には、そのフラグメントのタイプを示すfragmentTypeが実データとともに配置される。また、SDPフラグメントを配置する場合には、そのフラグメントを識別するfragmentIDが実データとともに配置される。
【０３４７】
また、拡張情報を配置する場合には、拡張情報のタイプを示すextension_typeが拡張データ(extension_data)とともに配置される。また、ヘッダ情報に、extension_offsetを指定することで、拡張情報の位置を示すことができる。
【０３４８】
ここでは、例えば、extension_typeとして、"2"(filter_extension)が指定された場合に、extension_dataには、EATのフィルタ条件として、16ビットのdemux_filter_paramを配置できるものとする。すなわち、demux_filter_paramに、上述した図２４のEA_categoryに相当する情報を配置することで、EA_categoryを用いたフィルタリング処理を行い、各ユーザが欲する緊急情報のみが告知されるようにすることができる。
【０３４９】
＜（２）シグナリング情報＞
＜（２−１）LLS(SCT，SAT，EAT，RRT)の詳細構造＞
【０３５０】
（SCTのシンタックス）
図４８は、SCTのシンタックスを示す図である。なお、図４８において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【０３５１】
図４８に示すように、sct要素は、networkId属性、name属性、及び、BBPStream要素を含む。networkId属性には、物理チャンネル単位の放送局のネットワークの識別子(network_id)が指定される。name属性には、物理チャンネル単位の放送局の名称が指定される。
【０３５２】
BBPStream要素は、sct要素の子要素であって、BBPストリームに関する情報が指定される。BBPStream要素は、BBPStreamId属性、payloadType属性、name属性、ESGBootstrap要素、及び、Service要素を含む。
【０３５３】
BBPStreamId属性は、BBPストリームの識別子(BBP_stream_id)が指定される。BBPストリームを複数配置する場合には、BBPStreamId属性により識別する。payloadType属性には、BBPストリームのペイロードタイプが指定される。このペイロードタイプとしては、例えば、"ipv4"，"ipv6"，"ts"などが指定される。name属性には、BBPストリームの名称が指定される。
【０３５４】
ESGBootstrap要素は、BBPStream要素の子要素であって、ESGへのアクセス情報が指定される。ESGBootstrap要素は、sourceIPAddress属性、destinationIPAddress属性、portNum属性、及び、tsi属性を含む。
【０３５５】
sourceIPAddress属性とdestinationIPAddress属性には、ESGを伝送する送信元（source）と宛先（destination）のIPアドレスが指定される。portNum属性は、ESGを伝送するポート番号が指定される。tsi属性には、ESGを伝送するFLUTEセッションにおけるTSIが指定される。
【０３５６】
Service要素は、BBPStream要素の子要素であって、サービスに関する情報が指定される。Service要素は、serviceId属性、serviceType属性、及び、SCSBootstrap要素を含む。
【０３５７】
serviceId属性は、サービスの識別子(service_id)が指定される。サービスを複数配置する場合には、serviceId属性により識別する。serviceType属性には、サービスのタイプ情報が指定される。このタイプ情報としては、例えば、"tv"，"audio"，"data"，"nrt"，"esg"，"adjunct-nrt"，"adjunct-shared"などが指定される。
【０３５８】
SCSBootstrap要素は、Service要素の子要素であって、サービスチャンネルへのアクセス情報が指定される。SCSBootstrap要素は、sourceIPAddress属性、destinationIPAddress属性、portNum属性、及び、tsi属性を含む。
【０３５９】
sourceIPAddress属性とdestinationIPAddress属性には、サービスを伝送する送信元（source）と宛先（destination）のIPアドレスが指定される。portNum属性には、SCSを伝送するポート番号が指定される。tsi属性には、SCSを伝送するFLUTEセッションにおけるTSIが指定される。
【０３６０】
なお、図４８を参照して説明したSCTのシンタックスは一例であって、他のシンタックスを採用することもできる。また、SCTは、例えばXML等のマークアップ言語により記述される。
【０３６１】
（SATのシンタックス）
図４９は、SATのシンタックスを示す図である。なお、図４９において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【０３６２】
図４９に示すように、sat要素は、service要素を含む。また、service要素は、service_id属性を含む。service_id属性には、オンエア中のサービスの識別子が指定される。オンエア中のサービスが複数存在する場合には、それらのサービスに対応したservice_idが複数配置される。
【０３６３】
（EATのシンタックス）
図５０は、EATのシンタックスを示す図である。なお、図５０において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【０３６４】
図５０に示すように、Eat要素は、AutomaticTuningService要素、及び、EAMessage要素を含む。AutomaticTuningService要素は、Eat要素の子要素であって、Wake-up時の自動選局サービスを指定するためのものである。AutomaticTuningService要素は、networkId属性、bbpStreamId属性、及び、serviceId属性を含む。
【０３６５】
networkId属性は、自動選局サービスのネットワーク識別子(network_id)が指定される。bbpStreamId属性は、自動選局サービスのBBPストリーム識別子(BBP_stream_id)が指定される。serviceId属性は、自動選局サービスのサービス識別子(service_id)が指定される。すなわち、AutomaticTuningService要素が出現した場合、それらの属性が示すトリプレットにより指定されるサービスが選局される。ただし、このトリプレットのうち、networkId属性とbbpStreamId属性は必須ではなく、例えば、EATと同一のBBPストリームを指定するのであれば、serviceId属性のみを指定すればよいことになる。
【０３６６】
EAMessage要素は、Eat要素の子要素であって、緊急告知情報（緊急情報）のメッセージが指定される。EAMessage要素は、eaMessageId属性、eaPriority属性、EAMessageData要素、EAApplication要素、EAService要素、及び、EAWww要素を含む。
【０３６７】
eaMessageId属性は、緊急告知情報（緊急情報）の識別子が指定される。eaPriority属性は、緊急告知情報（緊急情報）の優先度が指定される。EAMessageData要素は、EAMessage要素の子要素であって、緊急告知情報（緊急情報）の字幕情報が指定される。
【０３６８】
EAApplication要素は、EAMessage要素の子要素であって、緊急告知用のアプリケーションに関する情報が指定される。EAApplication要素は、applicationId属性を含む。applicationId属性は、アプリケーション識別子が指定される。
【０３６９】
EAService要素は、EAMessage要素の子要素であって、緊急告知用のNRTサービスに関する情報が指定される。EAService要素は、serviceId属性、及び、serviceType属性が指定される。serviceId属性は、サービス識別子(service_id)が指定される。serviceType属性は、サービスタイプ情報が指定される。このサービスタイプ情報としては、"nrt"，"adjunct_shared"が指定される。
【０３７０】
EAWww要素は、EAMessage要素の子要素であって、緊急情報サイトに関する情報が指定される。EAWww要素は、uri属性を含む。uri属性は、緊急情報サイトのURLが指定される。例えば、uri属性として、ウェブサーバ７０のURLを指定することができる。
【０３７１】
なお、図５０を参照して説明したEATのシンタックスは一例であって、他のシンタックスを採用することもできる。また、EATは、例えばXML等のマークアップ言語により記述される。
【０３７２】
（RRTのシンタックス）
図５１は、RRTのシンタックスを示す図である。なお、図５１において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【０３７３】
図５１に示すように、rrt要素は、rating_region属性、name属性、及び、dimension要素を含む。rating_region属性には、レーティングリージョンが指定される。name属性には、レーティングリージョンの名称が指定される。
【０３７４】
dimension要素は、rrt要素の子要素であって、name属性、graduated_scale属性、及び、rating_value要素を含む。また、rating_value要素は、abbrev_rating_value属性、及び、rating_valueを含む。これらの要素や属性により、番組の分類に関する地域情報が示される。
【０３７５】
＜（２−２）SCS(SDP)の詳細構造＞
【０３７６】
（SDPの記述例）
SDPの記述文書は、セッション記述部とメディア記述部の２つの部分から構成される。セッション記述部には、プロトコルバージョン、インスタンス生成者情報、コネクションデータなどが記述される。また、メディア記述部には、複数のメディア情報を記述することができる。
【０３７７】
図５２は、SDPの記述例を示している。
【０３７８】
図５２において、"v"は、プロトコルバージョンを示す。この値としては、"0"又はサービスの運用で決める値が指定される。
【０３７９】
"o"は、インスタンス生成者情報を示す。この値としては、生成者名、SDPインスタンスのID、バージョン、送信（ホスト）のタイプ、IPアドレスタイプ、及び、IPアドレスが指定される。例えば、送信（ホスト）のタイプには、"IN"（インターネット）、"BC"（放送）、又は"HB"（ハイブリッド）が指定される。また、IPアドレスタイプには、"IP4"(IPv4)又は"IP6"(IPv6)が指定される。
【０３８０】
"s"は、セッション名を示す。この値としては、セッション名がテキストで記述される。
【０３８１】
"c"は、コネクションデータを示す。この値としては、セッションのネットワークタイプ、IPアドレスタイプ、及び、IPアドレスが指定される。例えば、セッションのネットワークタイプには、"IN"（インターネット）、"BC"（放送）、又は"HB"（ハイブリッド）が指定される。また、IPアドレスタイプには、"IP4"(IPv4)又は"IP6"(IPv6)が指定される。
【０３８２】
"a"には、serviceとadjunct_serviceを指定することができる。serviceには、自サービスの識別子(service_id)が指定される。また、adjunct_serviceには、シェアドサービスの識別子(Adjunct_service_id)が指定される。なお、serviceとadjunct_serviceは、必ずしも指定する必要はない。
【０３８３】
"m"は、メディア情報を示す。この値としては、メディアタイプ、メディアを送信するポート番号、メディアを送信するプロトコル、フォーマットなどが指定される。例えば、メディアタイプとしては、ビデオ(Video)やオーディオ(Audio)が指定される。また、メディアを送信するプロトコルとしては、FLUTE/UDPやRTP/AVPなどが指定される。また、フォーマットとしては、プロトコルごとに必要があれば付加情報が記述される。また、"a="で始まる行は、対応するメディアの属性を示している。
【０３８４】
図５２の記述例では、RTPセッションで伝送されるビデオデータとオーディオデータが１ストリームずつから成立するサービスの場合を示している。
【０３８５】
すなわち、"m=video"の行によって、RTPセッションで伝送されるビデオデータのポート番号が、8000であることを示している。そして、その次の行の"a=rtpmap"によって、ペイロードタイプと符号化種別がマッピングされており、ビデオデータは、H.264により符号化されていることになる。また、ビデオデータにおいて、RTPタイムスタンプのタイムスケールは、90000となる。
【０３８６】
また、"m=audio"の行によって、RTPセッションで伝送されるオーディオデータのポート番号が、7000であることを示している。
【０３８７】
＜（３）放送システムの構成＞
【０３８８】
次に、本技術を適用した放送システムの構成について説明するが、XML形式のIP伝送方式における放送システムの構成では、上述したセクション形式のIP伝送方式における放送システムの構成と比べて、受信装置２０の構成が異なるため、ここでは、受信装置２０の構成について説明する。
【０３８９】
（受信装置の構成例）
図５３は、本技術を適用した受信装置の一実施の形態の構成を示す図である。
【０３９０】
図５３の受信装置２０は、図２２の受信装置２０と比べて、Demux２１３の構成が異なっている。すなわち、図５３のDemux２１３は、BBPフィルタ２５５、IPフィルタ２５２、UDPフィルタ２５３、LCTフィルタ２５６、及び、SGDUフィルタバンク２５７から構成される。BBPフィルタ２５５は、BBPヘッダに基づいて、フィルタリング処理を行い、LLSをSGDUフィルタバンク２５７に供給する。
【０３９１】
IPフィルタ２５２は、IPヘッダに基づいて、フィルタリング処理を行う。また、UDPフィルタ２５３は、UDPヘッダに基づいて、フィルタリング処理を行う。LCTフィルタ２５６は、LCTヘッダに基づいて、フィルタリング処理を行う。IPフィルタ２５２、UDPフィルタ２５３、及び、LCTフィルタ２５６によるフィルタリング処理によって、NTPはクロック発生部２１４に供給され、SCSはSGDUフィルタバンク２５７に供給される。さらに、ビデオデータ、オーディオデータ、字幕データは、ビデオデコーダ２１５、オーディオデコーダ２１７、字幕デコーダ２１９にそれぞれ供給される。また、各種のファイルデータは、FLUTE処理部２２０に供給される。
【０３９２】
SGDUフィルタバンク２５７は、SGDUヘッダに基づいて、フィルタリング処理を行い、LLSとSCSを適宜、制御信号処理部２２２又はFLUTE処理部２２０に供給する。また、SGDUフィルタバンク２５７は、LLSとして伝送されるXML形式のEATを取得して、緊急告知制御部２２４に供給する。
【０３９３】
FLUTE処理部２２０は、Demux２１３から供給される各種のファイルデータから、ESG、緊急告知用のアプリケーション、NRTコンテンツなどを復元する。例えば、FLUTE処理部２２０は、復元したESG又はNRTコンテンツを、ストレージ２２１に記録する。また、例えば、FLUTE処理部２２０は、復元した緊急告知用のアプリケーションを、ブラウザ２２６に供給する。さらに、FLUTE処理部２２０は、Demux２１３から供給されるSCSを制御信号処理部２２２に供給する。ただし、SCSは、FLUTE処理部２２０を介さずに直接、Demux２１３から制御信号処理部２２２に供給するようにしてもよい。
【０３９４】
制御信号処理部２２２は、Demux２１３又はFLUTE処理部２２０から供給される制御信号(LLS，SCS)に基づいて、各部の動作を制御する。
【０３９５】
緊急告知制御部２２４は、SGDUフィルタバンク２５７から供給されるEATに基づいて、緊急告知サービスに対応する各部の動作を制御する。例えば、緊急告知制御部２２４は、EATの解析処理の結果に応じて、受信装置２０の各部を制御して、緊急情報をディスプレイに表示させる。また、緊急告知制御部２２４は、チューナ２１２を常に監視しており、放送信号から強制緊急起動フラグのオンを検知した場合であって、受信装置２０がスリープ状態であるとき、受信装置２０の電源をオンする。
【０３９６】
図５３の受信装置２０において、上述したブロック以外の構成は、図２２の受信装置２０の構成と同様であるため、その説明は省略する。
【０３９７】
（フィルタリング処理の詳細）
次に、図５４を参照して、Demux２１３（図５３）による各パケットのフィルタリング処理の詳細について説明する。
【０３９８】
図５４に示すように、Demux２１３には、各種のヘッダ情報と、ペイロードとして、LLS、NTP、SCS、各種のファイルデータ、又はビデオデータやオーディオデータを含んでいる各パケットが入力される。
【０３９９】
BBPヘッダには、IP又はSignalingを示すタイプ情報が含まれている。BBPフィルタ２５５は、BBPヘッダに含まれるタイプ情報に基づいて、フィルタリング処理を行う。図５４の例では、LLSのパケットのタイプ情報のみがSignalingとなり、他のパケットはIPとなるので、LLSのパケットのみがSGDUフィルタバンク２５７に供給される。
【０４００】
また、IPヘッダには、IPアドレス(IP Address)が含まれる。IPフィルタ２５２は、IPヘッダに含まれるIPアドレスに基づいて、フィルタリング処理を行う。図５４の例では、IPヘッダが付加されたパケットのうち、NTPのパケットのIPアドレスのみ異なるが、他のパケットのIPアドレスは同一のアドレスとなる。
【０４０１】
さらに、UDPヘッダには、ポート番号(Port Number)が含まれる。UDPフィルタ２５３は、UDPヘッダに含まれるポート番号に基づいて、フィルタリング処理を行う。図５４の例では、UDPヘッダが付加された各パケットのポート番号は異なっている。また、FLUTEセッションを利用して伝送されるパケットには、LCTヘッダが付加され、RTPセッションを利用して伝送されるパケットには、RTPヘッダが付加されている。
【０４０２】
そして、IPフィルタ２５２とUDPフィルタ２５３によって、IPアドレスとポート番号を用いたフィルタリング処理が行われることで、LCTヘッダが付加されていないNTPのパケットは、クロック発生器２１４に出力される。また、RTPヘッダが付加されたビデオデータとオーディオデータのパケットは、ビデオデコーダ２１５とオーディオデコーダ２１７にそれぞれ出力される。
【０４０３】
また、LCTヘッダには、TSI(Transport Session Identifier)とTOI(Transport Object Identifier)が含まれる。FLUTEセッションにおいては、これらの識別情報を用いて、特定のファイルを指定することになる。LCTフィルタ２５６は、LCTヘッダに含まれるTSIとTOIに基づいて、フィルタリング処理を行う。図５４の例では、LCTフィルタ２５６は、SCS(SDP等)を特定するTSIとTOIが指定された場合、SCS(SDP等)のパケットをSGDUフィルタバンク２５７に供給する。また、LCTフィルタ２５６は、LCTヘッダに含まれるTSIとTOIに応じて、各種のファイルデータのパケットを、FLUTE処理部２２０に出力する。
【０４０４】
SGDUフィルタバンク２５７には、LLSのパケットとSCSのパケットが供給される。SGDUフィルタバンク２５７は、それらのパケットに付加されたSGDUヘッダや拡張情報に基づいて、フィルタリング処理を行う。ただし、SGDUフィルタバンク２５７においては、フィルタ条件を満たしたパケットだけが、SGDUフィルタバンク２５７セクションフィルタバンク２５４内のバッファメモリに保持され、これはCPU（図６７のCPU９０１）からソフトウェアで間欠的に吸い上げられることになる。
【０４０５】
例えば、SGDUヘッダには、バージョン情報（図４７のfragmentVersion）が記述されているので、SGDUフィルタバンク２５７は、バージョンが変化した場合にのみ、SDPのパケットを通すようにすることができる。また、拡張情報(図４７のextension_data)のdemux_filter_paramには、上述した図２４のEA_categoryに相当する情報が配置されているので、SGDUフィルタバンク２５７は、このEA_categoryを用い、フィルタリング処理を行うことで、各ユーザが欲する緊急情報のみが選択的に告知されるようにすることができる。
【０４０６】
例えば、上述した図２４及び図２５に示したように、EA_categoryには、緊急情報の緊急度を示すEA_priority、緊急情報の対象地域を示すEA_scope、所定の地域コードを示すArea_code、及び、緊急情報の種類を示すCategory_codeが配置される。そして、ユーザはあらかじめ、EA_categoryによるフィルタ条件を受信装置２０に設定しておくことで、受信装置２０では、そのフィルタ条件に応じて、EAT単位でフィルタリングされた緊急情報のみが告知されることになる。
【０４０７】
なお、図５４において、同一のサービスチャンネルとなる、MLS(SCS)、各種のファイルデータ、ビデオデータやオーディオデータのパケットは、同一のIPアドレスが付与されているので、IPフィルタ２５２は、それらのパケットを、NTPのパケットとともに出力することで、IPアドレスを用い、それらの制御信号やデータをパッケージ化することができる。
【０４０８】
＜（４）具体的な運用例＞
【０４０９】
次に、XML形式のIP伝送方式のデジタル放送に対応した放送システム１の具体的な運用例について説明する。ただし、受信装置２０は、最初に起動する場合などに初期スキャン処理を実行して、SCT（選局情報）を取得し、NVRAM２２３等に保持しているものとする。
【０４１０】
＜（４−１）NRTポータルサービス伝送＞
まず、図５５及び図５６を参照して、NRTポータルサービス伝送について説明する。
【０４１１】
（スリープ状態時のNRTポータルサービス伝送処理）
図５５は、スリープ状態の受信装置２０におけるNRTポータルサービス伝送処理を説明する図である。
【０４１２】
図５５に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SDP）がXML形式で伝送されている。
【０４１３】
図５５において、受信装置２０は、スリープ状態となっている（Ｓ５０１）。ここで、スリープ状態の受信装置２０は、常時、プリアンブル信号に含まれる強制緊急起動フラグを監視しており（Ｓ５０２）、緊急度の高い緊急情報を伝送する場合には、強制緊急起動フラグがオンされることになる。受信装置２０は、強制緊急起動フラグのオンを検知した場合、電源をオンして起動する（Ｓ５０３，Ｓ５０４）。
【０４１４】
また、受信装置２０は、デフォルトに設定されたBSで伝送されているLLSから、XML形式のEATを取得する（Ｓ５０５，Ｓ５０６）。図５５に示すように、このEATには、EAMessage要素のうち、EAService要素が出現し、さらに、serviceType属性として、"nrt"が指定されているため、緊急情報は、NRTポータルサービスのNRTポータル情報として伝送されている。したがって、受信装置２０は、EATのEAService要素のserviceId属性の値と選局情報を用い、選局処理を行うことで、FLUTEセッションにより伝送されているSDPを取得する（Ｓ５０７）。
【０４１５】
受信装置２０は、SDPに従い、FLUTEセッションにより伝送されているNRTポータル情報を取得して、そこから得られる緊急情報をディスプレイに表示する（Ｓ５０８，Ｓ５０９）。なお、このNRTポータル情報は、HTML形式のファイルデータであって、ブラウザ２２６によって表示されることになる。
【０４１６】
以上のように、図５５のNRTポータルサービス伝送処理においては、緊急時に、スリープ状態の受信装置２０が起動される。そして、受信装置２０は、LLSにより伝送されているXML形式のEATを取得して、当該EATに応じて、NRTポータル情報を取得する。これにより、ディスプレイは、Ｄ２１−１の状態（黒画面）から強制的に、Ｄ２１−２の状態（「大雨警報」を表示した画面）となって、NRTポータル情報として伝送された緊急情報の画面が表示されることになる。その結果、テレビ番組を試聴していなかったユーザであっても、強制的に表示された緊急情報の画面を確認して、大雨警報が発動されたことを知ることができる。
【０４１７】
（起動状態時のNRTポータルサービス伝送処理）
図５６は、起動状態の受信装置２０におけるNRTポータルサービス伝送処理を説明する図である。
【０４１８】
図５６に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SDP）がXML形式で伝送されている。
【０４１９】
図５６において、受信装置２０は、上述した図５５の運用例と異なり、起動中であって、テレビ番組を表示している（Ｓ５２１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しているが、プリアンブル信号に含まれる強制緊急起動フラグのオンを検知した場合には、デフォルトのBSから、最新のEATを取得する（Ｓ５２２乃至Ｓ５２５）。
【０４２０】
図５６に示すように、このXML形式のEATには、EAMessage要素のうち、EAService要素が出現し、さらに、serviceType属性として、"nrt"が指定されているため、緊急情報は、NRTポータルサービスのNRTポータル情報として伝送されている。したがって、受信装置２０は、EATのEAService要素のserviceId属性の値と選局情報を用い、選局処理を行うことで、FLUTEセッションにより伝送されているSDPを取得する（Ｓ５２６）。
【０４２１】
受信装置２０は、SDPに従い、FLUTEセッションにより伝送されているNRTポータル情報を取得して、そこから得られる緊急情報をディスプレイに表示する（Ｓ５２７，Ｓ５２８）。
【０４２２】
以上のように、図５６のNRTポータルサービス伝送処理においては、テレビ番組を表示中の受信装置２０は、強制緊急起動フラグのオンを検知した場合、LLSにより伝送されているXML形式のEATを取得して、当該EATに応じて、NRTポータル情報を取得する。これにより、ディスプレイは、Ｄ２２−１の状態（テレビ番組を表示した画面）から強制的に、Ｄ２２−２の状態（「大雨警報」を表示した画面）となって、NRTポータル情報として伝送された緊急情報の画面が表示されることになる。
【０４２３】
ただし、図５６の例では、緊急情報の画面に強制的に切り替える例を示したが、例えば、SGDUの拡張情報として指定されるEA_categoryのEA_priorityの示す緊急度が高い場合には、強制的に画面を切り替えるが、緊急度が低い場合には、緊急情報が有ること示すメッセージをテレビ番組に重畳して表示して、そのメッセージが選択された場合にのみ、緊急情報を表示させるようにしてもよい。その結果、テレビ番組を試聴しているユーザは、緊急情報の緊急度に応じて緊急情報の画面を確認して、大雨警報が発動されたことを知ることができる。
【０４２４】
＜（４−２）EAメッセージ伝送＞
次に、図５７及び図５８を参照して、EAメッセージ伝送について説明する。なお、このEAメッセージ伝送は、上述したEASメッセージ伝送に相当するものである。
【０４２５】
（スリープ状態時のEAメッセージ伝送処理）
図５７は、スリープ状態の受信装置２０におけるEAメッセージ伝送処理を説明する図である。
【０４２６】
図５７に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SDP）がXML形式で伝送されている。
【０４２７】
図５７において、受信装置２０は、スリープ状態となっている（Ｓ５４１）。ここで、スリープ状態の受信装置２０は、常時、プリアンブル信号に含まれる強制緊急起動フラグを監視しており（Ｓ５４２）、強制緊急起動フラグのオンを検知した場合、電源をオンして起動する（Ｓ５４３，Ｓ５４４）。
【０４２８】
また、受信装置２０は、デフォルトに設定されたBSで伝送されているLLSから、XML形式のEATを取得する（Ｓ５４５，Ｓ５４６）。図５７に示すように、このEATには、EAMessage要素のうち、EAMessageData要素が出現しているため、緊急情報は、EAメッセージとして伝送されている。したがって、受信装置２０は、EATのAutomaticTuningService要素のnetworkId属性、bbpStreamId属性、及び、serviceId属性の値と選局情報を用い、選局処理を行うことで、FLUTEセッションにより伝送されているSDPを取得する（Ｓ５４７）。
【０４２９】
受信装置２０は、SDPに従い、RTPセッションにより伝送されているビデオデータとオーディオデータを取得し（Ｓ５４８）、そのテレビ番組に、EATのEAMessage要素のメッセージ内容（図中のEATの「大雨警報が出ています・・・」）を重畳して、ディスプレイに表示する（Ｓ５４９）。
【０４３０】
以上のように、図５７のEAメッセージ伝送においては、緊急時に、スリープ状態の受信装置２０が起動される。そして、受信装置２０は、LLSにより伝送されているXML形式のEATを取得して、当該EATに応じて、メッセージと、テレビ番組のコンポーネントを取得する。これにより、ディスプレイは、Ｄ２３−１の状態（黒画面）から強制的に、Ｄ２３−２の状態（テレビ番組に字幕（メッセージ）を重畳した画面）となって、メッセージとして伝送された緊急情報の字幕が表示されることになる。その結果、テレビ番組を試聴していなかったユーザであっても、強制的にテレビ番組に重畳表示された字幕を確認して、大雨警報が発動されたことを知ることができる。
【０４３１】
（起動状態時のEAメッセージ伝送処理）
図５８は、起動状態の受信装置２０におけるEAメッセージ伝送処理を説明する図である。
【０４３２】
図５８に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。さらに、LLS（EAT）やSCS（SDP）がXML形式で伝送されている。
【０４３３】
図５８において、受信装置２０は、上述した図５７の運用例と異なり、起動中であって、テレビ番組を表示している（Ｓ５６１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しており、EATの更新を検出した場合には、そのEATを取得する（Ｓ５６２，Ｓ５６３）。図５８に示すように、このXML形式のEATには、EAMessage要素のうち、EAMessageData要素が出現しているため、緊急情報は、EAメッセージとして伝送されている。したがって、受信装置２０は、表示中のテレビ番組に、EATのEAMessage要素のメッセージ内容（図中のEATの「大雨警報が出ています・・・」）を重畳して、ディスプレイに表示する（Ｓ５６４）。これにより、ユーザは、テレビ番組に重畳表示された字幕を確認して、大雨警報が発動されたことを知ることができる。
【０４３４】
ただし、この字幕の内容は、大雨警報が発動されたことを示すものであって、その詳細な情報を示すものではない。そのため、ユーザによるリモートコントローラの操作などにより、詳細情報の表示が指示された場合（Ｓ５６５）、緊急情報の追加情報として、大雨警報の詳細情報が表示されるようにする（Ｓ５６６乃至Ｓ５６８）。
【０４３５】
具体的には、図５８のXML形式のEATには、EAMessage要素のうち、EAService要素が出現し、さらに、serviceType属性として、"nrt"が指定されているため、詳細情報は、NRTポータルサービスのNRTポータル情報として伝送されている。したがって、受信装置２０は、EATのEAService要素のserviceId属性の値と選局情報を用い、選局処理を行うことで、FLUTEセッションにより伝送されているSDPを取得する（Ｓ５６６）。そして、受信装置２０は、SDPに従い、FLUTEセッションにより伝送されているNRTポータル情報を取得して、そこから得られる緊急情報の詳細情報をディスプレイに表示する（Ｓ５６７，Ｓ５６８）。
【０４３６】
以上のように、図５８のEAメッセージ伝送においては、テレビ番組を表示中の受信装置２０は、EATの更新を検出した場合、LLSにより伝送されているXML形式のEATを取得して、当該EATに応じて、メッセージと、テレビ番組のコンポーネントを取得する。これにより、ディスプレイは、Ｄ２４−１の状態（テレビ番組を表示した画面）から、Ｄ２４−２の状態（テレビ番組に字幕（メッセージ）を重畳した画面）となって、メッセージとして伝送された緊急情報の字幕が画面に表示されることになる。その結果、テレビ番組を試聴しているユーザは、強制的にテレビ番組に重畳表示された字幕を確認して、大雨警報が発動されたことを知ることができる。
【０４３７】
また、テレビ番組に重畳表示された字幕を確認したユーザは、さらに深い天候に関する情報を知りたい場合には、所定の操作を行うことで、NRTポータル情報として伝送された緊急情報の詳細情報の画面（Ｄ２４−３の状態）が表示されることになる。その結果、ユーザは、字幕では表現しきれない情報を含む詳細情報を確認して、大雨警報に関するより深い情報を得ることができる。
【０４３８】
なお、図５８の例では、詳細情報はNRTポータル情報として、FLUTEセッションにより伝送されるとして説明したが、例えば、インターネット９０に接続されたウェブサーバ７０により提供されるようにしてもよい。
【０４３９】
＜（４−３）アプリケーション伝送＞
次に、図５９及び図６０を参照して、アプリケーション伝送について説明する。
【０４４０】
（スリープ状態時のアプリケーション伝送処理）
図５９は、スリープ状態の受信装置２０におけるアプリケーション伝送処理を説明する図である。
【０４４１】
図５９に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。さらに、LLS（EAT）やSCS（SDP，AIT）がXML形式で伝送されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。
【０４４２】
図５９において、受信装置２０は、スリープ状態となっている（Ｓ５８１）。ここで、スリープ状態の受信装置２０は、常時、プリアンブル信号に含まれる強制緊急起動フラグを監視しており（Ｓ５８２）、強制緊急起動フラグのオンを検知した場合、電源をオンして起動する（Ｓ５８３，Ｓ５８４）。
【０４４３】
また、受信装置２０は、デフォルトに設定されたBSで伝送されているLLSから、XML形式のEATを取得する（Ｓ５８５，Ｓ５８６）。図５９に示すように、このEATには、EAMessage要素のうち、EAApplication要素が出現しているため、緊急情報は、緊急告知用のアプリケーションとして伝送されている。したがって、受信装置２０は、EATのAutomaticTuningService要素のnetworkId属性、bbpStreamId属性、及び、serviceId属性の値と選局情報を用い、選局処理を行うことで、FLUTEセッションにより伝送されているSDPとAITを取得する（Ｓ５８７）。
【０４４４】
受信装置２０は、SDPに従い、RTPセッションにより伝送されているビデオデータとオーディオデータを取得する（Ｓ５８８）。また、受信装置２０は、AITを参照して、EATのEAApplication要素のapplicationId属性の値に対応するアプリケーションの取得先のURLを取得し、インターネット９０を介してアプリケーションサーバ５０にアクセスし、緊急告知用のアプリケーションを取得する（Ｓ５８９）。
【０４４５】
そして、受信装置２０は、取得したビデオデータとオーディオデータに応じたテレビ番組に、アプリケーションサーバ５０から取得した緊急告知用のアプリケーションを重畳して、ディスプレイに表示する（Ｓ５９０，Ｓ５９１）。
【０４４６】
以上のように、図５９のアプリケーション伝送処理においては、緊急時に、スリープ状態の受信装置２０が起動される。そして、受信装置２０は、LLSにより伝送されているXML形式のEATを取得して、当該EATに応じて、テレビ番組のコンポーネントと、緊急告知用のアプリケーションを取得する。これにより、ディスプレイは、Ｄ２５−１の状態（黒画面）から強制的に、Ｄ２５−２の状態（テレビ番組に緊急告知用のアプリケーションを重畳した画面）となって、緊急告知用のアプリケーションとして伝送された緊急情報の画面が表示されることになる。その結果、テレビ番組を試聴していなかったユーザであっても、強制的にテレビ番組に重畳表示された緊急告知用のアプリケーションを確認して、大雨警報が発動されたことを知ることができる。
【０４４７】
（起動状態時のアプリケーション伝送処理）
図６０は、起動状態の受信装置２０におけるアプリケーション伝送処理を説明する図である。
【０４４８】
図６０に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。さらに、LLS（EAT）やSCS（SDP，AIT）がXML形式で伝送されている。また、NRTポータルサービス用の緊急情報（図中の「NRT」）がFLUTEセッションで伝送されている。
【０４４９】
図６０において、受信装置２０は、上述した図５９の運用例と異なり、起動中であって、テレビ番組を表示している（Ｓ６０１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しており、EATの更新を検出した場合には、そのEATを取得する（Ｓ６０２，Ｓ６０３）。図６０に示すように、このXML形式のEATには、EAMessage要素のうち、EAApplication要素が出現しているため、緊急情報は、緊急告知用のアプリケーションとして伝送されている。したがって、受信装置２０は、EATのAutomaticTuningService要素のnetworkId属性、bbpStreamId属性、及び、serviceId属性の値と選局情報を用い、選局処理を行うことで、FLUTEセッションにより伝送されているAITを取得する（Ｓ６０４）。
【０４５０】
受信装置２０は、AITを参照して、EATのEAApplication要素のapplicationId属性の値に対応するアプリケーションの取得先のURLを取得し、インターネット９０を介してアプリケーションサーバ５０にアクセスし、緊急告知用のアプリケーションを取得する（Ｓ６０６）。そして、受信装置２０は、表示中のテレビ番組に、アプリケーションサーバ５０から取得した緊急告知用のアプリケーションを重畳して、ディスプレイに表示する（Ｓ６０５，Ｓ６０７，Ｓ６０８）。
【０４５１】
以上のように、図６０のアプリケーション伝送処理においては、テレビ番組を表示中の受信装置２０は、EATの更新を検出した場合、LLSにより伝送されているXML形式のEATを取得して、当該EATに応じて、緊急告知用のアプリケーションを取得する。これにより、ディスプレイは、Ｄ２６−１の状態（テレビ番組を表示した画面）から強制的に、Ｄ２６−２の状態（テレビ番組に緊急告知用のアプリケーションを重畳した画面）となって、アプリケーションとして伝送された緊急情報の画面が表示されることになる。その結果、テレビ番組を試聴しているユーザは、テレビ番組にＬ字型に重畳表示されたアプリケーションを確認して、大雨警報が発動されたことを知ることができる。
【０４５２】
なお、緊急告知用のアプリケーションを起動する際に、他のアプリケーションが起動中である場合には、その起動中の他のアプリケーションを終了させてから、緊急告知用のアプリケーションを起動させることになる。
【０４５３】
＜（４−４）シェアドコンポーネントサービス伝送＞
次に、図６１を参照して、シェアドコンポーネントサービス伝送について説明する。
【０４５４】
（起動状態時のシェアドコンポーネントサービス伝送処理）
図６１は、シェアドコンポーネントサービス伝送処理を説明する図である。
【０４５５】
図６１に示すように、送信装置１０からのIP伝送方式を用いたデジタル放送の放送波では、テレビ番組（図中の「TV」）のビデオデータとオーディオデータを同期型のストリーム形式で伝送しているため、RTPセッションが利用されている。また、緊急告知用の共有のオーディオデータが、RTPセッションにより伝送されている。さらに、LLS（EAT）やSCS（SDP）がXML形式で伝送されている。
【０４５６】
図６１において、受信装置２０は、起動中であって、テレビ番組を表示している（Ｓ６２１）。ここで、起動状態の受信装置２０は、常時、LLSにより伝送されているEATを監視しており、EATの更新を検出した場合には、そのEATを取得する（Ｓ６２２，Ｓ６２３）。図６１に示すように、このXML形式のEATには、EAMessage要素のうち、EAService要素が出現し、さらに、serviceType属性として、"adjunct_shared"が指定されているため、緊急情報は、シェアドコンポーネントサービスにより伝送されている。
【０４５７】
すなわち、図６１の運用例では、緊急情報が緊急告知用の共有のオーディオデータとして提供されているので、受信装置２０は、EATのEAService要素のserviceId属性の値と選局情報を用い、選局処理を行うことで、FLUTEセッションにより伝送されているSDPを取得する（Ｓ６２４）。受信装置２０は、SDPに従い、RTPセッションにより伝送されている緊急告知用の共有のオーディオデータを取得して、テレビ番組を表示中に、緊急情報の共有の音声を出力する（Ｓ６２５，Ｓ６２６）。ここでは、例えば、テレビ番組を表示中に、音声のみが切り替わって、「大雨警報」などの音声が、副音声として出力される。
【０４５８】
以上のように、図６１のアプリケーション伝送処理においては、テレビ番組を表示中の受信装置２０は、EATの更新を検出した場合、LLSにより伝送されているXML形式のEATを取得して、当該EATに応じて、緊急告知用の共有のオーディオデータを取得する。これにより、ディスプレイは、Ｄ２７−１の状態からＤ２７−２の状態になっても、テレビ番組を表示し続けているが、音声のみ切り替わって、「大雨警報」などの音声が緊急情報として出力されることになる。その結果、テレビ番組を試聴しているユーザは、テレビ番組を継続して視聴し続けながら、緊急情報の音声を確認して、大雨警報が発動されたことを知ることができる。
【０４５９】
なお、シェアドコンポーネントサービスの詳細な内容については、上述した図３３により説明しており、繰り返しになるのでその説明は省略する。
【０４６０】
＜（５）各装置で実行される具体的な処理の内容＞
【０４６１】
次に、図６２乃至図６６を参照して、図２０の放送システム１を構成する各装置で実行される具体的な処理の内容について説明する。ただし、送信装置１０により実行される送信処理と、受信装置２０により実行される受信処理は、上述した図３４の送信処理と、図３５の受信処理と同様であるため、その説明は省略する。
【０４６２】
（緊急告知処理）
図６２のフローチャートを参照して、図５３の受信装置２０により実行される緊急告知処理について説明する。この緊急告知処理は、受信装置２０がスリープ状態又は起動状態などにある場合に、例えば大雨警報などの緊急情報を告知するときに実行される。
【０４６３】
ステップＳ７０１乃至Ｓ７０３においては、図３６のステップＳ３４１乃至Ｓ３４３と同様に、スリープ状態の受信装置２０は、強制緊急起動フラグのオンを検知したとき、電源がオンされる。
【０４６４】
ステップＳ７０４において、緊急告知制御部２２４は、LLSにより伝送されているXML形式のEATを取得する。このEATを取得するタイミングとしては、例えば、スリープ状態の受信装置２０の電源がオンされた直後や強制緊急起動フラグのオンを検知したとき、EATが更新されたときなどが想定される。
【０４６５】
ステップＳ７０５において、緊急告知制御部２２４は、ステップＳ７０４の処理で取得したXML形式のEATを解析する。
【０４６６】
ステップＳ７０６において、緊急告知制御部２２４は、ステップＳ７０５の解析処理の結果に基づいて、EATにEAService要素が出現し、さらに、そのserviceType属性として、"nrt"が指定されているかどうかを判定する。ステップＳ７０６において、当該要素の出現要件を満たしていると判定された場合、処理は、ステップＳ７０７に進められる。
【０４６７】
ステップＳ７０７において、緊急告知制御部２２４は、NRTポータルサービス伝送処理を実行する。このNRTポータルサービス伝送処理は、上述した図５５及び図５６の運用例に対応するものであって、その詳細な処理の内容は、図６３のフローチャートを参照して後述する。
【０４６８】
また、ステップＳ７０６において、当該要素の出現要件を満たしていないと判定された場合、処理は、ステップＳ７０８に進められる。ステップＳ７０８において、緊急告知制御部２２４は、ステップＳ７０５の解析処理の結果に基づいて、EATにEAMessageData要素が出現しているかどうかを判定する。ステップＳ７０８において、当該要素の出現要件を満たしていると判定された場合、処理は、ステップＳ７０９に進められる。
【０４６９】
ステップＳ７０９において、緊急告知制御部２２４は、EAメッセージ伝送処理を実行する。このEAメッセージ伝送処理は、上述した図５７及び図５８の運用例に対応するものであって、その詳細な処理の内容は、図６４のフローチャートを参照して後述する。
【０４７０】
また、ステップＳ７０８において、当該要素の出現要件を満たしていないと判定された場合、処理は、ステップＳ７１０に進められる。ステップＳ７１０において、緊急告知制御部２２４は、ステップＳ７０５の解析処理の結果に基づいて、EATにEAApplication要素が出現しているかどうかを判定する。ステップＳ７１０において、当該要素の出現要件を満たしていると判定された場合、処理は、ステップＳ７１１に進められる。
【０４７１】
ステップＳ７１１において、緊急告知制御部２２４は、アプリケーション伝送処理を実行する。このアプリケーション伝送処理は、上述した図５９及び図６０の運用例に対応するものであって、その詳細な処理の内容は、図６５のフローチャートを参照して後述する。
【０４７２】
また、ステップＳ７１０において、当該要素の出現要件を満たしていないと判定された場合、処理は、ステップＳ７１２に進められる。ステップＳ７１２において、緊急告知制御部２２４は、ステップＳ７０５の解析処理の結果に基づいて、EATにEAService要素が出現し、さらに、そのserviceType属性として、"adjunct_shared"が指定されているかどうかを判定する。ステップＳ７１２において、当該要素の出現要件を満たしていると判定された場合、処理は、ステップＳ７１３に進められる。
【０４７３】
ステップＳ７１３において、緊急告知制御部２２４は、シェアドコンポーネントサービス伝送処理を実行する。このシェアドコンポーネントサービス伝送処理は、上述した図６１の運用例に対応するものであって、その詳細な処理の内容は、図６６のフローチャートを参照して後述する。
【０４７４】
また、ステップＳ７１２において、当該要素の出現要件を満たしていないと判定された場合、処理は、ステップＳ７１４に進められる。ステップＳ７１４においては、ステップＳ７０５の解析処理の結果に応じて、例えば、ストリーム伝送処理などが実行されることになる。
【０４７５】
ステップＳ７０７，Ｓ７０９，Ｓ７１１，Ｓ７１３，Ｓ７１４のいずれかの処理が終了すると、緊急告知処理は終了する。
【０４７６】
以上、緊急告知処理について説明した。
【０４７７】
（NRTポータルサービス伝送処理）
次に、図６３のフローチャートを参照して、図６２のステップＳ７０７に対応するNRTポータルサービス伝送処理について説明する。
【０４７８】
ステップＳ７２１において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、SDPを取得する。
【０４７９】
ステップＳ７２２において、FLUTE処理部２２０は、緊急告知制御部２２４からの制御に従い、制御信号処理部２２２からのSDPに基づいて、FLUTEセッションにより伝送されるNRTポータル情報（緊急情報）を取得する。
【０４８０】
ステップＳ７２３において、ブラウザ２２６は、緊急告知制御部２２４からの制御に従い、FLUTE処理部２２０からのNRTポータル情報（緊急情報）を、ビデオ出力部２１６を介してディスプレイに表示する。これにより、ディスプレイには、例えば大雨警報等の緊急情報が表示されることになる。
【０４８１】
ステップＳ７２３の処理が終了すると、処理は、図６２のステップＳ７０７に戻り、それ以降の処理が実行される。
【０４８２】
以上、NRTポータルサービス伝送処理について説明した。
【０４８３】
（EAメッセージ伝送処理）
次に、図６４のフローチャートを参照して、図６２のステップＳ７０９に対応するEAメッセージ伝送処理について説明する。ただし、受信装置２０がスリープ状態である場合には、電源がオンされるが、EATのAutomaticTuningService要素のトリプレットにより指定されるサービスを選局する選局処理が行われているものとする。
【０４８４】
ステップＳ７４１において、緊急告知制御部２２４は、EATに含まれるEAメッセージをテレビ番組に重畳して、ビデオ出力部２１６を介してディスプレイに表示する。これにより、例えば大雨警報等の字幕（緊急情報）がテレビ番組に重畳表示される。
【０４８５】
ステップＳ７４２においては、ユーザによるリモートコントローラの操作などにより、詳細情報の表示が指示されたかどうかが判定される。ステップＳ７４２において、詳細情報の表示が指示されたと判定された場合、処理は、ステップＳ７４３に進められる。
【０４８６】
ステップＳ７４３において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、SDPを取得する。
【０４８７】
ステップＳ７４４において、FLUTE処理部２２０は、緊急告知制御部２２４からの制御に従い、制御信号処理部２２２からのSDPに基づいて、FLUTEセッションにより伝送されるNRTポータル情報（詳細情報）を取得する。
【０４８８】
ステップＳ７４５において、ブラウザ２２６は、緊急告知制御部２２４からの制御に従い、FLUTE処理部２２０からのNRTポータル情報（詳細情報）を、ビデオ出力部２１６を介してディスプレイに表示する。これにより、ディスプレイには、緊急情報の追加情報として、例えば大雨警報等の詳細情報が表示されることになる。
【０４８９】
また、ステップＳ７４２において、詳細情報の表示が指示されていないと判定された場合、ステップＳ７４３乃至Ｓ７４５の処理はスキップされる。そして、ステップＳ７４５の処理が終了すると、処理は、図６２のステップＳ７０９に戻り、それ以降の処理が実行される。
【０４９０】
以上、EAメッセージ伝送処理について説明した。
【０４９１】
（アプリケーション伝送処理）
次に、図６５のフローチャートを参照して、図６２のステップＳ７１１に対応するアプリケーション伝送処理について説明する。ただし、受信装置２０がスリープ状態である場合には、電源がオンされるが、EATのAutomaticTuningService要素のトリプレットにより指定されるサービスを選局する選局処理が行われているものとする。
【０４９２】
ステップＳ７６１において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、AITを取得する。また、緊急告知制御部２２４は、AITを参照して、EATのEAApplication要素のapplicationId属性の値に対応する緊急告知用のアプリケーションの取得先のURLを取得する。
【０４９３】
ステップＳ７６２において、通信I/F２２５は、緊急告知制御部２２４からの制御に従い、緊急告知用のアプリケーションの取得先のURLに基づいて、インターネット９０を介してアプリケーションサーバ５０にアクセスし、緊急告知用のアプリケーションを取得する。
【０４９４】
ステップＳ７６３において、ブラウザ２２６は、緊急告知制御部２２４からの制御に従い、通信I/F２２５からの緊急告知用のアプリケーションをテレビ番組に重畳して、ビデオ出力部２１６を介してディスプレイに表示する。これにより、例えば大雨警報等の緊急情報が、テレビ番組に対してＬ字表示されることになる。
【０４９５】
ステップＳ７６３の処理が終了すると、処理は、図６２のステップＳ７１１に戻り、それ以降の処理が実行される。
【０４９６】
以上、アプリケーション伝送処理について説明した。
【０４９７】
（シェアドコンポーネントサービス伝送処理）
次に、図６６のフローチャートを参照して、図６２のステップＳ７１３に対応するシェアドコンポーネントサービス伝送処理について説明する。ただし、ここでは、緊急情報が、緊急警告用の共有のオーディオデータとして提供されているものとする。
【０４９８】
ステップＳ７８１において、制御信号処理部２２２は、緊急告知制御部２２４からの制御に従い、EATに基づいて、SDPを取得する。
【０４９９】
ステップＳ７８２において、オーディオデコーダ２１７は、緊急告知制御部２２４からの制御に従い、SDPに基づいて、Demux２１３からの緊急告知用の共有のオーディオデータを取得する。また、オーディオデコーダ２１７は、緊急告知制御部２２４からの制御に従い、緊急告知用の共有のオーディオデータを復号し、オーディオ出力部２１８に供給する。
【０５００】
ステップＳ７８３において、オーディオ出力部２１８は、緊急告知制御部２２４からの制御に従い、テレビ番組の音声を、緊急告知用の共有のオーディオデータをに切り替えて、スピーカから緊急情報の音声を出力する。これにより、例えば、テレビ番組の表示中に、音声のみが切り替わって、「大雨警報」などの音声が出力される。
【０５０１】
ステップＳ７８３の処理が終了すると、処理は、図６２のステップＳ７１４に戻り、それ以降の処理が実行される。
【０５０２】
以上、シェアドコンポーネントサービス伝送処理について説明した。
【０５０３】
＜本技術を適用したコンピュータの説明＞
【０５０４】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０５０５】
図６７は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０５０６】
コンピュータ９００において、CPU（Central Processing Unit）９０１，ROM（Read Only Memory）９０２，RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及びドライブ９１０が接続されている。
【０５０７】
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
【０５０８】
以上のように構成されるコンピュータ９００では、CPU９０１が、例えば、記録部９０８に記録されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
【０５０９】
コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０５１０】
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
【０５１１】
なお、コンピュータ９００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０５１２】
ここで、本明細書において、コンピュータ９００に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。
【０５１３】
また、プログラムは、１のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。
【０５１４】
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０５１５】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０５１６】
また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０５１７】
なお、本技術は、以下のような構成をとることができる。
【０５１８】
（１）
IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波を受信する受信部と、
前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御する制御部と
を備える受信装置。
（２）
前記制御部は、映像及び音声の少なくとも１つによって、緊急情報を告知する
（１）に記載の受信装置。
（３）
前記制御信号は、緊急告知用のアプリケーションに関する情報を含み、
前記制御部は、前記制御信号に基づいて、前記アプリケーションを取得して、AVコンテンツと連動して実行させる
（２）に記載の受信装置。
（４）
前記制御信号は、前記アプリケーションの識別情報を含み、
前記制御部は、前記アプリケーションの識別情報と、前記アプリケーションを制御するためのアプリケーション制御信号に基づいて、前記アプリケーションを取得する
（３）に記載の受信装置。
（５）
前記制御信号は、緊急告知用のコンポーネントに関する情報を含み、
前記制御部は、前記制御信号に基づいて、映像及び音声の少なくとも１つの前記コンポーネントを取得して、AVコンテンツの映像及び音声の少なくとも１つを切り替える
（２）に記載の受信装置。
（６）
前記コンポーネントは、複数のサービスで共有されている
（５）に記載の受信装置。
（７）
前記制御信号は、あらかじめ設定された所定のフィルタ条件に応じてフィルタリングされる
（２）に記載の受信装置。
（８）
前記制御信号は、その緊急度に応じてフィルタリングされる
（７）に記載の受信装置。
（９）
前記制御信号は、その対象地域に応じてフィルタリングされる
（７）又は（８）に記載の受信装置。
（１０）
前記制御信号は、所定のエリア単位でフィルタリングされる
（７）乃至（９）のいずれか一項に記載の受信装置。
（１１）
前記制御信号は、その種類に応じてフィルタリングされる
（７）乃至（１０）のいずれか一項に記載の受信装置。
（１２）
前記放送波は、強制緊急起動信号を伝送可能であり、
前記受信装置がスリープ状態の場合に、前記強制緊急起動信号が検知されたとき、前記受信装置の電源をオンする
（１）乃至（１１）のいずれか一項に記載の受信装置。
（１３）
前記制御信号は、XML形式で伝送される
（１）乃至（１２）のいずれか一項に記載の受信装置。
（１４）
前記制御信号は、セクション形式で伝送される
（１）乃至（１２）のいずれか一項に記載の受信装置。
（１５）
前記制御信号は、IP伝送方式におけるプロトコルの階層のうち、IP層よりも下位の階層である第１の階層で用いられる
（１）乃至（１４）のいずれか一項に記載の受信装置。
（１６）
前記放送波は、前記第１の階層で用いられる選局情報用の制御信号を伝送しており、
前記選局情報用の制御信号は、ネットワークの識別情報、ストリームの識別情報、及び、サービスの識別情報を少なくとも含んでいる
（１５）に記載の受信装置。
（１７）
前記放送波は、IP層よりも上位の階層である第２の階層で用いられる、特定のサービスを構成するコンポーネントに関する情報を少なくとも含む制御信号を伝送している
（１６）に記載の受信装置。
（１８）
受信装置の受信方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波を受信し、
前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御する
ステップを含む受信方法。
（１９）
緊急告知用の制御信号を取得する取得部と、
前記制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する送信部と
を備える送信装置。
（２０）
送信装置の送信方法において、
前記送信装置が、
緊急告知用の制御信号を取得し、
前記制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する
ステップを含む送信方法。
【符号の説明】
【０５１９】
１  放送システム，  １０  送信装置，  ２０  受信装置，  １１１  ビデオデータ取得部，  １１３  オーディオデータ取得部，  １１７  制御信号取得部，  １１９  ファイルデータ取得部，  １２１  Mux，  １２２  送信部，  ２１２  チューナ，  ２１３  Demux，  ２１４  クロック発生器，  ２１５  ビデオデコーダ，  ２１６  ビデオ出力部，  ２１７  オーディオデコーダ，  ２１８  オーディオ出力部，  ２１９  字幕デコーダ，  ２２０  FLUTE処理部，  ２２１  ストレージ，  ２２２  制御信号処理部，  ２２３  NVRAM，  ２２４  緊急告知制御部，  ２２５  通信I/F，  ２２６  ブラウザ，  ２５１  GSEフィルタ，  ２５２  IPフィルタ，  ２５３  UDPフィルタ，  ２５４  セクションフィルタバンク，  ２５５  BBPフィルタ，  ２５６  LCTフィルタ，  ２５７  SGDUフィルタバンク，  ９００  コンピュータ，  ９０１  CPU
【図１】
2015104055.tif 000003
【図２】
2015104055.tif 000004
【図３】
2015104055.tif 000005
【図４】
2015104055.tif 000006
【図５】
2015104055.tif 000007
【図６】
2015104055.tif 000008
【図７】
2015104055.tif 000009
【図８】
2015104055.tif 000010
【図９】
2015104055.tif 000011
【図１０】
2015104055.tif 000012
【図１１】
2015104055.tif 000013
【図１２】
2015104055.tif 000014
【図１３】
2015104055.tif 000015
【図１４】
2015104055.tif 000016
【図１５】
2015104055.tif 000017
【図１６】
2015104055.tif 000018
【図１７】
2015104055.tif 000019
【図１８】
2015104055.tif 000020
【図１９】
2015104055.tif 000021
【図２０】
2015104055.tif 000022
【図２１】
2015104055.tif 000023
【図２２】
2015104055.tif 000024
【図２３】
2015104055.tif 000025
【図２４】
2015104055.tif 000026
【図２５】
2015104055.tif 000027
【図２６】
2015104055.tif 000028
【図２７】
2015104055.tif 000029
【図２８】
2015104055.tif 000030
【図２９】
2015104055.tif 000031
【図３０】
2015104055.tif 000032
【図３１】
2015104055.tif 000033
【図３２】
2015104055.tif 000034
【図３３】
2015104055.tif 000035
【図３４】
2015104055.tif 000036
【図３５】
2015104055.tif 000037
【図３６】
2015104055.tif 000038
【図３７】
2015104055.tif 000039
【図３８】
2015104055.tif 000040
【図３９】
2015104055.tif 000041
【図４０】
2015104055.tif 000042
【図４１】
2015104055.tif 000043
【図４２】
2015104055.tif 000044
【図４３】
2015104055.tif 000045
【図４４】
2015104055.tif 000046
【図４５】
2015104055.tif 000047
【図４６】
2015104055.tif 000048
【図４７】
2015104055.tif 000049
【図４８】
2015104055.tif 000050
【図４９】
2015104055.tif 000051
【図５０】
2015104055.tif 000052
【図５１】
2015104055.tif 000053
【図５２】
2015104055.tif 000054
【図５３】
2015104055.tif 000055
【図５４】
2015104055.tif 000056
【図５５】
2015104055.tif 000057
【図５６】
2015104055.tif 000058
【図５７】
2015104055.tif 000059
【図５８】
2015104055.tif 000060
【図５９】
2015104055.tif 000061
【図６０】
2015104055.tif 000062
【図６１】
2015104055.tif 000063
【図６２】
2015104055.tif 000064
【図６３】
2015104055.tif 000065
【図６４】
2015104055.tif 000066
【図６５】
2015104055.tif 000067
【図６６】
2015104055.tif 000068
【図６７】
2015104055.tif 000069