JP2015104055A - 受信装置、受信方法、送信装置、及び、送信方法 - Google Patents

受信装置、受信方法、送信装置、及び、送信方法 Download PDF

Info

Publication number
JP2015104055A
JP2015104055A JP2013244950A JP2013244950A JP2015104055A JP 2015104055 A JP2015104055 A JP 2015104055A JP 2013244950 A JP2013244950 A JP 2013244950A JP 2013244950 A JP2013244950 A JP 2013244950A JP 2015104055 A JP2015104055 A JP 2015104055A
Authority
JP
Japan
Prior art keywords
information
service
control signal
emergency
receiving device
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.)
Pending
Application number
JP2013244950A
Other languages
English (en)
Inventor
北里　直久
Naohisa Kitazato
直久 北里
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2013244950A priority Critical patent/JP2015104055A/ja
Priority to KR1020167012920A priority patent/KR102187082B1/ko
Priority to US14/917,209 priority patent/US10264328B2/en
Priority to PCT/JP2014/005823 priority patent/WO2015079658A1/en
Priority to KR1020207034443A priority patent/KR102330695B1/ko
Priority to MX2016006599A priority patent/MX364030B/es
Priority to EP14809536.7A priority patent/EP3075169B1/en
Priority to CA2931053A priority patent/CA2931053C/en
Priority to RU2016119632A priority patent/RU2661928C2/ru
Publication of JP2015104055A publication Critical patent/JP2015104055A/ja
Priority to US16/286,144 priority patent/US10623827B2/en
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/488—Data services, e.g. news ticker
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/814—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts comprising emergency warnings

Abstract

【課題】より高度な緊急告知サービスを提供することができるようにする。【解決手段】緊急告知制御部は、IP伝送方式を用いたデジタル放送の放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御することで、IP伝送方式を用いたデジタル放送において、より高度な緊急告知サービスを提供することができる。本技術は、例えば、送信機と受信機からなる放送システムに適用することができる。【選択図】図２２

Description

本技術は、受信装置、受信方法、送信装置、及び、送信方法に関し、特に、より高度な緊急告知サービスを提供することができるようにした受信装置、受信方法、送信装置、及び、送信方法に関する。
現在、各国のデジタル放送の規格では、伝送形式として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

Claims (20)

  1. IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波を受信する受信部と、
    前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御する制御部と
    を備える受信装置。
  2. 前記制御部は、映像及び音声の少なくとも１つによって、緊急情報を告知する
    請求項１に記載の受信装置。
  3. 前記制御信号は、緊急告知用のアプリケーションに関する情報を含み、
    前記制御部は、前記制御信号に基づいて、前記アプリケーションを取得して、AVコンテンツと連動して実行させる
    請求項２に記載の受信装置。
  4. 前記制御信号は、前記アプリケーションの識別情報を含み、
    前記制御部は、前記アプリケーションの識別情報と、前記アプリケーションを制御するためのアプリケーション制御信号に基づいて、前記アプリケーションを取得する
    請求項３に記載の受信装置。
  5. 前記制御信号は、緊急告知用のコンポーネントに関する情報を含み、
    前記制御部は、前記制御信号に基づいて、映像及び音声の少なくとも１つの前記コンポーネントを取得して、AVコンテンツの映像及び音声の少なくとも１つを切り替える
    請求項２に記載の受信装置。
  6. 前記コンポーネントは、複数のサービスで共有されている
    請求項５に記載の受信装置。
  7. 前記制御信号は、あらかじめ設定された所定のフィルタ条件に応じてフィルタリングされる
    請求項２に記載の受信装置。
  8. 前記制御信号は、その緊急度に応じてフィルタリングされる
    請求項７に記載の受信装置。
  9. 前記制御信号は、その対象地域に応じてフィルタリングされる
    請求項７に記載の受信装置。
  10. 前記制御信号は、所定のエリア単位でフィルタリングされる
    請求項７に記載の受信装置。
  11. 前記制御信号は、その種類に応じてフィルタリングされる
    請求項７に記載の受信装置。
  12. 前記放送波は、強制緊急起動信号を伝送可能であり、
    前記受信装置がスリープ状態の場合に、前記強制緊急起動信号が検知されたとき、前記受信装置の電源をオンする
    請求項１に記載の受信装置。
  13. 前記制御信号は、XML形式で伝送される
    請求項１に記載の受信装置。
  14. 前記制御信号は、セクション形式で伝送される
    請求項１に記載の受信装置。
  15. 前記制御信号は、IP伝送方式におけるプロトコルの階層のうち、IP層よりも下位の階層である第１の階層で用いられる
    請求項１に記載の受信装置。
  16. 前記放送波は、前記第１の階層で用いられる選局情報用の制御信号を伝送しており、
    前記選局情報用の制御信号は、ネットワークの識別情報、ストリームの識別情報、及び、サービスの識別情報を少なくとも含んでいる
    請求項１５に記載の受信装置。
  17. 前記放送波は、IP層よりも上位の階層である第２の階層で用いられる、特定のサービスを構成するコンポーネントに関する情報を少なくとも含む制御信号を伝送している
    請求項１６に記載の受信装置。
  18. 受信装置の受信方法において、
    前記受信装置が、
    IP伝送方式を用いたデジタル放送の放送波を受信し、
    前記放送波により伝送される緊急告知用の制御信号に基づいて、緊急告知サービスに対応する各部の動作を制御する
    ステップを含む受信方法。
  19. 緊急告知用の制御信号を取得する取得部と、
    前記制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する送信部と
    を備える送信装置。
  20. 送信装置の送信方法において、
    前記送信装置が、
    緊急告知用の制御信号を取得し、
    前記制御信号を、IP伝送方式を用いたデジタル放送の放送波で送信する
    ステップを含む送信方法。
JP2013244950A 2013-11-27 2013-11-27 受信装置、受信方法、送信装置、及び、送信方法 Pending JP2015104055A (ja)

Priority Applications (10)

Application Number Priority Date Filing Date Title
JP2013244950A JP2015104055A (ja) 2013-11-27 2013-11-27 受信装置、受信方法、送信装置、及び、送信方法
MX2016006599A MX364030B (es) 2013-11-27 2014-11-19 Dispositivo de recepcion, metodo de recepcion, dispositivo de transmision, y metodo de transmision.
US14/917,209 US10264328B2 (en) 2013-11-27 2014-11-19 Receiving device, receiving method, transmitting device, and transmitting method
PCT/JP2014/005823 WO2015079658A1 (en) 2013-11-27 2014-11-19 Receiving device, receiving method, transmitting device, and transmitting method
KR1020207034443A KR102330695B1 (ko) 2013-11-27 2014-11-19 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
KR1020167012920A KR102187082B1 (ko) 2013-11-27 2014-11-19 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
EP14809536.7A EP3075169B1 (en) 2013-11-27 2014-11-19 Receiving device, receiving method, transmitting device, and transmitting method
CA2931053A CA2931053C (en) 2013-11-27 2014-11-19 Receiving device, receiving method, transmitting device, and transmitting method
RU2016119632A RU2661928C2 (ru) 2013-11-27 2014-11-19 Принимающее устройство, способ приема, передающее устройство и способ передачи
US16/286,144 US10623827B2 (en) 2013-11-27 2019-02-26 Receiving device, receiving method, transmitting device, and transmitting method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013244950A JP2015104055A (ja) 2013-11-27 2013-11-27 受信装置、受信方法、送信装置、及び、送信方法

Publications (1)

Publication Number Publication Date
JP2015104055A true JP2015104055A (ja) 2015-06-04

Family

ID=52016122

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013244950A Pending JP2015104055A (ja) 2013-11-27 2013-11-27 受信装置、受信方法、送信装置、及び、送信方法

Country Status (8)

Country Link
US (2) US10264328B2 (ja)
EP (1) EP3075169B1 (ja)
JP (1) JP2015104055A (ja)
KR (2) KR102187082B1 (ja)
CA (1) CA2931053C (ja)
MX (1) MX364030B (ja)
RU (1) RU2661928C2 (ja)
WO (1) WO2015079658A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017047397A1 (ja) * 2015-09-14 2017-03-23 ソニー株式会社 受信装置、送信装置、及び、データ処理方法
WO2018003541A1 (ja) * 2016-06-30 2018-01-04 ソニーセミコンダクタソリューションズ株式会社 送信装置、送信方法、受信装置、及び、受信方法
KR20180044903A (ko) 2015-09-01 2018-05-03 소니 주식회사 수신 장치, 송신 장치 및 데이터 처리 방법
JP2018207236A (ja) * 2017-05-31 2018-12-27 東芝インフラシステムズ株式会社 同報通信システム、情報提供装置および信号送信方法
JP2020071713A (ja) * 2018-10-31 2020-05-07 ヤフー株式会社 情報処理装置、情報処理方法および情報処理プログラム
JP2022103260A (ja) * 2021-02-03 2022-07-07 マクセル株式会社 放送受信装置

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
HUE050160T2 (hu) * 2012-10-17 2020-12-28 Sony Corp Adatfeldolgozó berendezés, adatfeldolgozó eljárás és program
JP2015073245A (ja) * 2013-10-04 2015-04-16 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
EP3065409A4 (en) * 2013-10-30 2017-08-09 Sony Corporation Transmission device, transmission method, reception device, and reception method
WO2016076623A1 (ko) * 2014-11-12 2016-05-19 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016114559A1 (ko) * 2015-01-12 2016-07-21 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN106105240B (zh) * 2015-01-21 2019-11-08 Lg电子株式会社 发送广播信号的装置以及发送广播信号的方法
KR102425988B1 (ko) * 2015-04-01 2022-07-29 삼성전자주식회사 방송 시스템에서의 비상 통보 메시지를 처리하는 장치 및 방법
US10498792B2 (en) * 2015-05-17 2019-12-03 Lg Electronics Inc. Apparatus and method for transmitting or receiving broadcast signal
CN107852526B (zh) 2015-08-19 2021-01-22 夏普株式会社 用于处理数据流的方法和接收机
GB201618274D0 (en) * 2016-10-28 2016-12-14 Sony Corp A decoder, encoder, computer program and method
US10904299B2 (en) * 2017-06-08 2021-01-26 Avaya Inc. Alternative network address type (ANAT) encoding and media interworking
JP2019135806A (ja) * 2018-02-05 2019-08-15 ソニーセミコンダクタソリューションズ株式会社 復調回路、処理回路、処理方法、および処理装置
CN111866603B (zh) * 2020-07-21 2022-04-26 广州市保伦电子有限公司 一种基于srs的视频文件生产方法、后台服务器和系统
CN111970526B (zh) * 2020-08-18 2022-04-26 广州华多网络科技有限公司 界面通知消息处理方法、装置、设备及存储介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5818440A (en) * 1997-04-15 1998-10-06 Time Warner Entertainment Co. L.P. Automatic execution of application on interactive television
US7233781B2 (en) * 2001-10-10 2007-06-19 Ochoa Optics Llc System and method for emergency notification content delivery
US8489063B2 (en) * 2001-10-24 2013-07-16 Sipco, Llc Systems and methods for providing emergency messages to a mobile device
US20060005219A1 (en) * 2004-07-02 2006-01-05 Garry Owens Standby television warning system
KR20060134739A (ko) * 2005-06-23 2006-12-28 삼성전자주식회사 디지털 방송 시스템의 메시지 처리 방법 및 그 장치
KR100698312B1 (ko) * 2005-07-27 2007-03-22 엘지전자 주식회사 영상기기 및 그의 부가정보 표시방법
US7592912B2 (en) * 2005-12-09 2009-09-22 Time Warner Cable Inc. Emergency alert data delivery apparatus and methods
JP2010268226A (ja) * 2009-05-14 2010-11-25 Toshiba Corp 放送受信装置
US8949885B2 (en) * 2010-07-30 2015-02-03 Echostar Technologies L.L.C. Systems, methods and apparatus for transmitting weather information in a television distribution network
US8745655B2 (en) * 2010-12-16 2014-06-03 Verizon Patent And Licensing Inc. Emergency alerts during playback of video streams on portable devices
JP5783402B2 (ja) 2011-01-25 2015-09-24 ソニー株式会社 受信装置、受信方法、供給装置、供給方法、プログラム、および放送システム
JP5979646B2 (ja) * 2011-05-19 2016-08-24 日本放送協会 受信機
KR101947554B1 (ko) 2012-03-02 2019-02-13 엘지전자 주식회사 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
US8863172B2 (en) * 2012-03-17 2014-10-14 Time Warner Cable Enterprises Llc Emergency alert system methods and apparatus
JP5941356B2 (ja) 2012-07-02 2016-06-29 日本放送協会 放送通信連携受信装置、アプリケーション認証プログラム及び放送通信連携システム
RU130110U1 (ru) 2012-12-18 2013-07-10 Общество с ограниченной ответственностью "Научно-Технический Центр ПРОТЕЙ" Система обработки информации о чрезвычайных ситуациях
JP2015061195A (ja) * 2013-09-18 2015-03-30 ソニー株式会社 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム
US9936054B2 (en) * 2015-01-29 2018-04-03 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180044903A (ko) 2015-09-01 2018-05-03 소니 주식회사 수신 장치, 송신 장치 및 데이터 처리 방법
US11330344B2 (en) 2015-09-01 2022-05-10 Saturn Licensing Llc Receiving apparatus, transmitting apparatus, and data processing method
JPWO2017047397A1 (ja) * 2015-09-14 2018-07-05 ソニー株式会社 受信装置、送信装置、及び、データ処理方法
US10594419B2 (en) 2015-09-14 2020-03-17 Sony Corporation Receiving apparatus, transmitting apparatus, and data processing method
WO2017047397A1 (ja) * 2015-09-14 2017-03-23 ソニー株式会社 受信装置、送信装置、及び、データ処理方法
US11184095B2 (en) 2015-09-14 2021-11-23 Saturn Licensing Llc Receiving apparatus, transmitting apparatus, and data processing method
KR20180053647A (ko) 2015-09-14 2018-05-23 소니 주식회사 수신 장치, 송신 장치, 및 데이터 처리 방법
US10812872B2 (en) 2016-06-30 2020-10-20 Sony Semiconductor Solutions Corporation Transmitting device, transmitting method, receiving device, and receiving method for providing emergency alert information
JPWO2018003541A1 (ja) * 2016-06-30 2019-04-18 ソニーセミコンダクタソリューションズ株式会社 送信装置、送信方法、受信装置、及び、受信方法
JP2021170791A (ja) * 2016-06-30 2021-10-28 ソニーセミコンダクタソリューションズ株式会社 受信装置
WO2018003541A1 (ja) * 2016-06-30 2018-01-04 ソニーセミコンダクタソリューションズ株式会社 送信装置、送信方法、受信装置、及び、受信方法
JP7085677B2 (ja) 2016-06-30 2022-06-16 ソニーセミコンダクタソリューションズ株式会社 受信装置
JP2022113754A (ja) * 2016-06-30 2022-08-04 ソニーセミコンダクタソリューションズ株式会社 送信装置及び送信方法
JP7423690B2 (ja) 2016-06-30 2024-01-29 ソニーセミコンダクタソリューションズ株式会社 送信装置及び送信方法
JP2018207236A (ja) * 2017-05-31 2018-12-27 東芝インフラシステムズ株式会社 同報通信システム、情報提供装置および信号送信方法
JP2020071713A (ja) * 2018-10-31 2020-05-07 ヤフー株式会社 情報処理装置、情報処理方法および情報処理プログラム
JP2022103260A (ja) * 2021-02-03 2022-07-07 マクセル株式会社 放送受信装置

Also Published As

Publication number Publication date
KR20160089363A (ko) 2016-07-27
US20190200095A1 (en) 2019-06-27
KR102187082B1 (ko) 2020-12-04
WO2015079658A1 (en) 2015-06-04
CA2931053A1 (en) 2015-06-04
KR20200138423A (ko) 2020-12-09
KR102330695B1 (ko) 2021-12-01
MX2016006599A (es) 2016-08-05
MX364030B (es) 2019-04-11
EP3075169B1 (en) 2022-01-05
RU2016119632A3 (ja) 2018-03-01
CA2931053C (en) 2021-09-21
EP3075169A1 (en) 2016-10-05
US20160198241A1 (en) 2016-07-07
US10623827B2 (en) 2020-04-14
RU2016119632A (ru) 2017-11-23
RU2661928C2 (ru) 2018-07-23
US10264328B2 (en) 2019-04-16

Similar Documents

Publication Publication Date Title
KR102187082B1 (ko) 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
US10305949B2 (en) Reception device, reception method, transmission device, and transmission method
CA2844195C (en) Method of receiving broadcasting signal and apparatus for receiving broadcasting signal
TWI648991B (zh) 接收裝置、接收方法、傳輸裝置及傳輸方法
US11343549B2 (en) Reception apparatus, reception method, transmission apparatus, and transmission method
JP6617712B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
JP6654044B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2017065021A1 (ja) 受信装置、送信装置、及び、データ処理方法
JP2016208161A (ja) 送信装置、送信方法、受信装置、及び、受信方法
WO2017047397A1 (ja) 受信装置、送信装置、及び、データ処理方法
JP6598031B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
JP7134867B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2015115253A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2023013123A1 (ja) 再送出装置、再送出方法、受信装置、及び受信方法
WO2015178221A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2016181806A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法
WO2016031591A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2015107930A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法