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

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

Info

Publication number
JPWO2016076137A1
JPWO2016076137A1 JP2016558978A JP2016558978A JPWO2016076137A1 JP WO2016076137 A1 JPWO2016076137 A1 JP WO2016076137A1 JP 2016558978 A JP2016558978 A JP 2016558978A JP 2016558978 A JP2016558978 A JP 2016558978A JP WO2016076137 A1 JPWO2016076137 A1 JP WO2016076137A1
Authority
JP
Japan
Prior art keywords
service
stream
information
metadata
scs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016558978A
Other languages
English (en)
Other versions
JP6643246B2 (ja
Inventor
淳 北原
淳 北原
北里　直久
直久 北里
山岸　靖明
靖明 山岸
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
Publication of JPWO2016076137A1 publication Critical patent/JPWO2016076137A1/ja
Application granted granted Critical
Publication of JP6643246B2 publication Critical patent/JP6643246B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport 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/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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the 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/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/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Systems (AREA)

Abstract

本技術は、多様なサービス形態に対応できるようにする受信装置、受信方法、送信装置、及び、送信方法に関する。受信装置は、IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを取得し、第１のメタデータに含まれるクラス情報に基づいて、複数の形態ごとに、サービスを構成するコンポーネントのストリームに接続して、コンポーネントの再生を制御する。本技術は、例えば、テレビ受像機等の固定受信機や、スマートフォン等のモバイル受信機等に適用することができる。

Description

本技術は、受信装置、受信方法、送信装置、及び、送信方法に関し、特に、多様なサービス形態に対応できるようにした受信装置、受信方法、送信装置、及び、送信方法に関する。
近年、各国では、デジタル放送のサービスが開始されている（例えば、特許文献１参照）。各国のデジタル放送の規格では、伝送方式としてMPEG2-TS（Moving Picture Experts Group phase 2 - Transport Stream）方式が採用されているが、今後は、通信の分野で用いられているIP（Internet Protocol）パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
特開２００８−２６３６１６号公報
ところで、IP伝送方式を用いて、ビデオやオーディオ、字幕等のコンポーネントを伝送する方式の候補の１つとして、ROUTE（Real-time Object Delivery over Unidirectional Transport）がある。ROUTEは、放送のライブサービス向けに、FLUTE（File Delivery over Unidirectional Transport）を拡張したものである。
しかしながら、サービス（例えば番組）を構成するコンポーネントをROUTEセッションで伝送する場合における技術方式が確立されておらず、多様なサービス形態に対応できるようにしたいという要請があった。
本技術はこのような状況に鑑みてなされたものであり、多様なサービス形態に対応することができるようにするものである。
本技術の第１の側面の受信装置は、IP（Internet Protocol）伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを取得する第１の取得部と、前記第１のメタデータに含まれる前記クラス情報に基づいて、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに接続して、前記コンポーネントの再生を制御する制御部とを備える受信装置である。
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の受信方法は、上述した本技術の第１の側面の受信装置に対応する受信方法である。
本技術の第１の側面の受信装置、及び、受信方法においては、IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータが取得され、前記第１のメタデータに含まれる前記クラス情報に基づいて、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに接続して、前記コンポーネントの再生が制御される。
本技術の第２の側面の送信装置は、IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを生成する生成部と、生成された前記第１のメタデータを送信する送信部とを備える送信装置である。
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。本技術の第２の側面の送信方法は、上述した本技術の第２の側面の送信装置に対応する送信方法である。
本技術の第２の側面の送信装置、及び、送信方法においては、IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータが生成され、生成された前記第１のメタデータが送信される。
本技術の第１の側面、及び、第２の側面によれば、多様なサービス形態に対応することができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
サービス提供システムの構成例を示す図である。 シグナリングデータの例を示す図である。 サービスタイプ別の受信するシグナリングデータを示す図である。 ベーシックサービスのシーケンス図である。 複数BBPストリームサービスのシーケンス図である。 ハイブリッドサービス１のシーケンス図である。 ハイブリッドサービス２のシーケンス図である。 レイヤコーディングサービス（エンハンスクラス）のシーケンス図である。 レイヤコーディングサービス（コアクラス）のシーケンス図である。 FICのシンタックスの例を示す図である。 SCDのシンタックスの例を示す図である。 本技術を適用した送信装置の一実施の形態の構成を示す図である。 本技術を適用した受信装置の一実施の形態の構成を示す図である。 図１３の制御部の機能的な構成例を示す図である。 本技術を適用したブロードバンドサーバの一実施の形態の構成を示す図である。 送信処理を説明するフローチャートである。 周波数スキャン処理を説明するフローチャートである。 LLS取得・記録処理を説明するフローチャートである。 選局前処理を説明するフローチャートである。 選局処理を説明するフローチャートである。 ハイブリッドに対応した選局処理を説明するフローチャートである。 コンピュータの構成例を示す図である。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．IP伝送方式によるデジタル放送の概要
３．運用例
（１）運用例１：ベーシックサービス
（２）運用例２：複数BBPストリームサービス
（３）運用例３：ハイブリッドサービス１
（４）運用例４：ハイブリッドサービス２
（５）運用例５：レイヤコーディングサービス（エンハンスクラス）
（６）運用例６：レイヤコーディングサービス（コアクラス）
４．シンタックスの例
５．システムを構成する各装置の構成
６．各装置で実行される処理の流れ
７．変形例
８．コンピュータの構成
＜１．システムの構成＞
（サービス提供システムの構成例）
図１において、サービス提供システム１は、番組等のサービスを提供するためのシステムである。サービス提供システム１は、送信装置１０、受信装置２０、及び、ブロードバンドサーバ３０から構成される。また、図１において、受信装置２０は、インターネット９０を介して、ブロードバンドサーバ３０と相互に接続されている。
送信装置１０は、例えば地上デジタルテレビ放送の所定の規格に対応した送信機であって、放送事業者により提供される。なお、本技術の実施の形態において、地上デジタルテレビ放送の規格としては、例えば、ATSC（Advanced Television Systems Committee standards）等の規格を採用することができる。
送信装置１０は、サービス（例えば番組）を構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、シグナリングデータとともに、デジタル放送の放送波によって送信する。
なお、シグナリングデータには、サービスに依存しない低レイヤのLLS（Low Layer Signaling）シグナリングデータと、サービス単位のSCS（Service Channel Signaling）シグナリングデータの２種類が存在するが、その詳細な内容については後述する。
また、ビデオやオーディオ等のコンポーネントと、SCSシグナリングデータは、ROUTEセッションにより伝送される。ROUTEは、放送のライブサービス向けに、FLUTEを拡張したものである。なお、ROUTEは、FLUTE +（FLUTE plus）やFLUTE enhancementなどと称される場合がある。
ここで、ROUTEセッションでは、送信するファイルなどを１つのオブジェクトとして、TOI（Transport Object Identifier）により管理する。また、複数のオブジェクトの集合を１つのセッションとして、TSI（Transport Session Identifier）により管理する。すなわち、ROUTEセッションにおいては、TSIとTOIの２つの識別情報によって特定のファイルを指定することが可能となる。
受信装置２０は、例えばATSC等の地上デジタルテレビ放送の所定の規格に対応した受信機であって、テレビ受像機やセットトップボックスなどの固定受信機、スマートフォンや携帯電話機、タブレット型コンピュータ、ノート型のパーソナルコンピュータ、自動車内で利用される端末などのモバイル受信機である。
受信装置２０は、送信装置１０から送信されるデジタル放送の放送波を受信して、当該デジタル放送の放送波で伝送されるシグナリングデータを取得する。受信装置２０は、シグナリングデータに基づいて、送信装置１０から送信されるデジタル放送の放送波で伝送されるサービス（を構成するコンポーネント）のストリームに接続して、そのストリームから得られる映像と音声を再生（出力）する。また、受信装置２０は、通信機能を有しており、インターネット９０を介して、ブロードバンドサーバ３０にアクセスすることができる。
ブロードバンドサーバ３０は、受信装置２０からの要求に応じて、サービス（例えば番組）を構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、インターネット９０を介してストリーミング配信する。また、ブロードバンドサーバ３０は、受信装置２０からの要求に応じて、シグナリングデータを、インターネット９０を介して配信する。
受信装置２０は、送信装置１０又はブロードバンドサーバ３０からのシグナリングデータに基づいて、ブロードバンドサーバ３０からインターネット９０を介してストリーミング配信されるサービス（を構成するコンポーネント）のストリームに接続して、そのストリームから得られる映像と音声を再生（出力）する。
なお、図１においては、送信装置１０からのデジタル放送の放送波が直接、受信装置２０により受信される構成を図示しているが、１又は複数の中継局（不図示）を介してデジタル放送の放送波が伝送されるようにしてもよい。また、受信装置２０は、モバイル受信機である場合、公衆無線LAN（Local Area Network）のアクセスポイントを介してインターネット９０に接続するか、あるいはLTE（Long Term Evolution）等のモバイル系のネットワーク（不図示）を介して、ブロードバンドサーバ３０に接続することになる。
また、受信装置２０は、通信機能を有していない場合や、通信機能を有しているがその通信機能が無効になっている場合がある。以下の説明では、必要に応じて、通信機能を有しており、かつ、その通信機能が有効になっている放送と通信のハイブリッド受信に対応した受信装置２０を、受信装置２０Ａと称し、通信機能を有していない場合や、通信機能を有しているがその通信機能が無効になっている場合などの放送のみ受信に対応した受信装置２０を、受信装置２０Ｂと称して区別する。
＜２．IP伝送方式によるデジタル放送の概要＞
各国のデジタル放送の規格では、伝送方式としてMPEG2-TS方式が採用されているが、今後は、通信の分野で用いられているIPパケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。特に、現在策定が進められている米国の次世代放送規格であるATSC3.0では、IP伝送方式を用いたデジタル放送の採用が見込まれている。
IP伝送方式によるデジタル放送の放送波においては、物理チャンネル（RF Channel）に対応した所定の周波数帯域で、１又は複数のBBP（Base Band Packet）ストリームが伝送される。また、各BBPストリームでは、LLS（Low Layer Signaling）や、１又は複数のサービスチャンネル（サービス）等のストリームが伝送される。LLSストリームでは、サービスに依存しない低レイヤのLLSシグナリングデータが伝送される。
サービスチャンネル（サービス）は、SCS（Service Channel Signaling）と、ビデオやオーディオ、字幕等の番組を構成するコンポーネント（Component）のストリームから構成される。SCSストリームでは、サービス単位のSCSシグナリングデータが伝送される。
なお、SCSシグナリングデータと、コンポーネントのデータは、ROUTEセッションにより伝送される。また、各サービスを構成する要素には、共通のIPアドレスが付与されており、このIPアドレスを用いて、サービスごとに、SCSシグナリングデータやコンポーネントのデータなどをパッケージ化することができる。
ここで、所定の周波数帯域からなる放送波（RF Channel）には、例えば放送事業者ごとに、ブロードキャストストリームID（Broadcast Stream ID）が割り当てられている。また、各放送波で伝送される１又は複数のBBPストリームには、BBPストリームID（BBP Stream ID）が割り当てられる。さらに、各BBPストリームで伝送される１又は複数のサービスには、サービスID（Service ID）が割り当てられる。
このように、IP伝送方式のID体系としては、MPEG2-TS方式で用いられているネットワークID（Network ID）と、トランスポートストリームID（Transport Stream ID）と、サービスID（Service ID）の組み合わせ（トリプレット（Triplet））に対応する構成が採用され、このトリプレットによって、ネットワーク内のBBPストリーム構成とサービス構成が示される。
このようなID体系を用いることで、現在広く普及しているMPEG2-TS方式との整合をとることができる。なお、IP伝送方式のID体系では、ブロードキャストストリームIDとBBPストリームIDが、MPEG2-TS方式におけるネットワークIDとトランスポートストリームIDに対応している。
なお、BBPストリームにおいては、LLSやサービスチャンネルのストリームのほかに、NTP（Network Time Protocol）やESG（Electronic Service Guide）サービスのストリームが伝送されるようにしてもよい。NTPは、時刻情報である。ESGサービスは、OMA（Open Mobile Alliance）によって規定されている電子サービスガイドである。
（シグナリングデータの例）
図２は、シグナリングデータの例を示す図である。
上述したように、シグナリングデータには、LLSストリームで伝送されるLLSシグナリングデータと、SCSストリームで伝送されるSCSシグナリングデータがある。
LLSシグナリングデータは、サービスに依存しない低レイヤのシグナリングデータであって、IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層（レイヤ）で伝送される。例えば、LLSシグナリングデータとしては、FIC（Fast Information Channel），SCD（Service Configuration Description），EAD（Emergency Alerting Description），RRD（Region Rating Description），DCD（Default Component Description）等のLLSメタデータが含まれる。
また、SCSシグナリングデータは、サービス単位のシグナリングデータであって、IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層（レイヤ）で伝送される。例えば、SCSシグナリングデータとしては、USBD（User Service Bundle Description），USD（User Service Description），SDP（Session Description Protocol），MPD（Media Presentation Description），IS（Initialization Segment），LSID（LCT Session Instance Description），ESGc（Electric Service Guide Current），SPD（Service Parameter Description）等のSCSメタデータが含まれる。なお、SCSシグナリングデータは、ROUTEセッションで伝送される。
FICは、MPEG2-TS方式に対応したID体系によって、ネットワーク内のBBPストリームやサービスの構成を示す情報などを含んでいる。また、詳細は後述するが、FICには、シグナリングスコープ情報（signaling scope all）、SCSショートカット情報（SCS_shortcut）、ハイブリッド情報（hybrid）、及び、クラス情報（class）が記述される。
なお、FICの詳細な構造は、図１０のFICのシンタックスを参照して後述する。また、ここでは、FICは、LLSストリームで伝送されるとして説明するが、LLSストリーム以外の、例えば物理層等の下位の階層（レイヤ）で伝送されるようにしてもよい。
SCDは、サービスの構成を示す情報などを含んでいる。なお、SCDの詳細な構造は、図１１のSCDのシンタックスを参照して後述する。EADは、緊急警報に関する緊急警報情報を含んでいる。RRDは、レーティングに関する情報を含んでいる。DCDは、SCSシグナリングデータに先行して取得される、最小限のサービスの選局を行うための情報である。
USBDは、MPD，SDP等のSCSメタデータを参照するための参照情報を含んでいる。USDは、サービスを構成するコンポーネントの配信経路を特定するための情報などを含んでいる。なお、USDは、USBDに含まれる場合がある。SDPは、サービス単位で伝送されるコンポーネントのストリームに接続するための情報である。SDPは、サービス単位のサービス属性、ストリームの構成情報や属性、フィルタ情報、ロケーション情報などを含んでいる。
MPDは、サービス単位で伝送されるコンポーネントのストリームの再生を管理するための情報である。MPDには、複数のコンポーネントが列挙されており、その取得先を示すセグメントURL（Uniform Resource Locator）などの情報を含んでいる。ISは、ROUTEセッションにおけるメディアセグメント（MS：Media Segment）に対するイニシャライゼーションセグメントである。
なお、USBD，USD，MPD，SDP，ISは、3GPP（Third Generation Partnership Project），MPEG（Moving Picture Expert Group），又はIETF（Internet Engineering Task Force）のいずれかによって規格化されたものを参照するものとする。
LSIDは、FLUTEのFDT（File Delivery Table）をリアルタイムサービス向けに拡張したものであって、ROUTEセッションごとに伝送されるコンポーネントのストリームの管理情報とされる。なお、LSIDは、他のSCSメタデータと異なるROUTEセッションで伝送するようにしてもよい。
ESGcは、ESGのカレント情報であって、現在放送中の番組についての情報を伝送するものである。なお、ESGは、OMA（Open Mobile Alliance）によって規格化されている。SPDは、サービスレベルのパラメータが定義される。
なお、LLSシグナリングデータのうち、FICはバイナリ形式のデータとされるが、それ以外のSCD等のLLSメタデータはテキスト形式のデータとされる。また、SCSシグナリングデータにおいて、全てのSCSメタデータは、テキスト形式のデータとされる。例えば、SCD等のLLSメタデータやSCSメタデータは、XML（Extensible Markup Language）等のマークアップ言語により記述することができる。
（FICの詳細な内容）
次に、FICに記述される、シグナリングスコープ情報、SCSショートカット情報、ハイブリッド情報、及び、クラス情報の詳細な内容について説明する。
（シグナリングスコープ情報）
シグナリングスコープ情報（signaling scope all）は、放送経由で配信されるSCSシグナリングデータの参照範囲を示す。例えば、シグナリングスコープ情報としては、放送経由で配信されるSCSシグナリングデータが、サービスを構成する全てのコンポーネントのストリームに関する情報（メタデータ）を記述する場合には、"TRUE"が指定される。
また、放送経由で配信されるSCSシグナリングデータが、サービスを構成するコンポーネントのストリームのうち、放送経由で配信されるコンポーネントのストリームに関する情報（メタデータ）のみを記述する場合には、"FALSE"が指定される。例えば、サービスを構成するコンポーネントのストリームを、放送経由と通信経由で配信（ハイブリッド配信）する場合であっても、放送経由で配信されるSCSシグナリングデータには、放送で配信されるコンポーネントのストリームに関する情報のみが記述されている場合には、シグナリングスコープ情報として"FALSE"が指定される。
（SCSショートカット情報）
SCSショートカット情報（SCS_shortcut）は、FICに記述されるサービスが、ベーシックサービスであるか、あるいはリッチサービスであるかを示す。例えば、SCSショートカット情報としては、ベーシックサービスの場合には"TRUE"が指定され、リッチサービスの場合には"FALSE"が指定される。
ここで、ベーシックサービス（Basic Service）とは、サービスを構成するコンポーネントのストリームが、MIMEタイプにより個別に識別可能なサービスである。また、リッチサービス（Rich Service）とは、ベーシックサービス以外のサービスである。例えば、リッチサービスとしては、ビデオ、オーディオ、及び、字幕のうち、いずれか１つのコンポーネントが、２以上のストリームから構成されるサービスが該当する。
受信装置２０は、SCSショートカット情報が、ベーシックサービスであることを示している場合、SCSシグナリングデータのうち、MPDとLSIDを取得することで、コンポーネントのストリームに接続して、レンダリング処理を開始することができる。この場合、送信装置１０は、全てのSCSシグナリングデータを送信する必要がない。したがって、サービスの提供を行う事業者（例えば放送事業者）からすれば、サービス運用の簡素化、放送帯域の有効活用などのメリットがある。
（ハイブリッド情報）
ハイブリッド情報（hybrid）は、FICに記述されるサービスを構成するコンポーネントのストリームが、放送経由でのみ配信（放送配信）されるか、あるいは放送経由と通信経由で配信（ハイブリッド配信）されるかを示す。例えば、ハイブリッド情報としては、ハイブリッド配信の場合には"TRUE"が指定され、放送配信の場合には"FALSE"が指定される。
（FICに記述される情報の関係）
これらのFICに記述される情報の関係をまとめると、図３に示すようになる。なお、詳細は図１０のシンタックスを参照して後述するが、FICにおいて、シグナリングスコープ情報は、signalingscopeallに記述され、SCSショートカット情報は、SCS_shortcutに記述され、ハイブリッド情報は、hybridに記述される。
図３において、シグナリングスコープ情報（signaling scope all）として、"FALSE"が指定された場合、放送経由で配信されるSCSシグナリングデータは、放送経由で配信されるコンポーネントのストリームに関する情報（メタデータ）のみを記述している。
この場合おいて、SCSショートカット情報（SCS_shortcut）として"TRUE"が指定され、かつ、ハイブリッド情報（hybrid）として"FALSE"が指定されたときを、「ケースＡ」とすれば、このケースＡでは、ベーシックサービスを構成するコンポーネントのストリームは、放送配信されることになる。そして、ケースＡの場合において、放送と通信のハイブリッド受信に対応した受信装置２０Ａと、放送のみ受信に対応した受信装置２０Ｂでは、LSIDとMPDを取得することで、放送経由で配信されるコンポーネントのストリームに接続して、レンダリング処理を開始することができる。
次に、SCSショートカット情報として"TRUE"が指定され、かつ、ハイブリッド情報として"TRUE"が指定されたときを、「ケースＢ」とすれば、このケースＢでは、ベーシックサービスを構成する放送経由で配信されるコンポーネントのストリームと、通信経由で配信される他のコンポーネントのストリームがハイブリッドサービスを構成して、ハイブリッド配信されることになる。そして、ケースＢの場合において、受信装置２０Ａは、レンダリング処理を開始するためには、全てのSCSシグナリングデータを取得する必要がある。
すなわち、ケースＢでは、ハイブリッド情報として"TRUE"が指定されており、ハイブリッドサービスを構成するコンポーネントのストリームは、放送経由と通信経由で配信（ハイブリッド配信）されるが、シグナリングスコープ情報として"FALSE"が指定されており、放送経由で配信されるSCSシグナリングデータは、放送経由で配信されるコンポーネントのストリームに関する情報のみを記述している。
したがって、受信装置２０Ａが、ハイブリッド配信に対応するためには、通信経由で配信されるコンポーネントのストリームに関する情報が記述されたSCSシグナリングデータを取得する必要がある。ここでは、受信装置２０Ａは、SCDのSCSブロードバンドロケーション情報（SignalingOverInternet要素のuri属性）を参照することで、インターネット９０を介してブロードバンドサーバ３０にアクセスし、通信経由で配信されるSCSシグナリングデータを取得する。
これにより、受信装置２０Ａでは、放送経由で配信されるSCSシグナリングデータと、通信経由で配信されるSCSシグナリングデータが取得され、レンダリング処理を開始するための全てのSCSシグナリングデータが揃うことになる。このように、レンダリング処理を開始するためのSCSシグナリングデータの一部を通信経由で配信することで、放送経由で配信されるSCSシグナリングデータのデータ量を削減することができるので、全てのSCSシグナリングデータを放送経由で配信する場合と比べて、放送帯域を削減することができる。
なお、ケースＢにおいて、受信装置２０Ｂは、ハイブリッド配信に対応していないため、通信経由で配信されるコンポーネントのストリームに関する情報が記述されたSCSシグナリングデータを取得する必要がない。したがって、受信装置２０Ｂでは、LSIDとMPDを取得することで、レンダリング処理を開始することができる。
次に、SCSショートカット情報として"FALSE"が指定され、かつ、ハイブリッド情報として"FALSE"が指定されたときを、「ケースＣ」とすれば、このケースＣでは、リッチサービスを構成するコンポーネントのストリームは、放送配信されることになる。そして、ケースＣの場合において、受信装置２０Ａと受信装置２０Ｂでは、全てのSCSシグナリングデータを取得することで、放送経由で配信されるコンポーネントのストリームに接続して、レンダリング処理を開始することができる。
次に、SCSショートカット情報として"FALSE"が指定され、かつ、ハイブリッド情報として"TRUE"が指定されたときを、「ケースＤ」とすれば、このケースＤでは、リッチサービスを構成するコンポーネントのストリームは、ハイブリッド配信されることになる。そして、ケースＤの場合において、受信装置２０Ａと受信装置２０Ｂは、レンダリング処理を開始するためには、全てのSCSシグナリングデータを取得する必要がある。
ただし、ケースＤの場合において、受信装置２０Ａは、ケースＢの場合と同様に、ハイブリッド配信されるコンポーネントのストリームのうち、通信経由で配信されるコンポーネントのストリームに関する情報が記述されたSCSシグナリングデータを取得する必要がある。受信装置２０Ａは、SCDのSCSブロードバンドロケーション情報（SignalingOverInternet要素のuri属性）を参照することで、ブロードバンドサーバ３０にアクセスし、通信経由で配信されるSCSシグナリングデータを取得する。
これにより、受信装置２０Ａでは、放送経由と通信経由で配信されるSCSシグナリングデータがそれぞれ取得され、レンダリング処理を開始するための全てのSCSシグナリングデータが揃うことになる。このように、レンダリング処理を開始するためのSCSシグナリングデータの一部を通信経由で配信して、放送経由で配信されるSCSシグナリングデータのデータ量を削減することで、結果として放送帯域を削減することができる。
一方、シグナリングスコープ情報として、"TRUE"が指定された場合、放送経由で配信されるSCSシグナリングデータは、サービスを構成する全てのコンポーネントのストリームに関する情報（メタデータ）を記述している。
この場合において、SCSショートカット情報として"TRUE"が指定され、かつ、ハイブリッド情報として"FALSE"が指定されたときを、「ケースＥ」とすれば、このケースＥでは、ベーシックサービスを構成するコンポーネントのストリームは、放送配信されることになる。そして、ケースＥの場合において、受信装置２０Ａと受信装置２０Ｂでは、LSIDとMPDを取得することで、放送経由で配信されるコンポーネントのストリームに接続して、レンダリング処理を開始することができる。
次に、SCSショートカット情報として"TRUE"が指定され、かつ、ハイブリッド情報として"TRUE"が指定されたときを、「ケースＦ」とすれば、このケースＦでは、ベーシックサービスを構成する放送経由で配信されるコンポーネントのストリームと、通信経由で配信される他のコンポーネントのストリームがハイブリッドサービスを構成して、ハイブリッド配信されることになる。そして、ケースＦの場合においては、ハイブリッドサービスを構成するコンポーネントのストリームがハイブリッド配信されているため、受信装置２０Ａは、レンダリング処理を開始するためには、全てのSCSシグナリングデータを取得する必要があるが、放送経由で配信されるSCSシグナリングデータに、ベーシックサービスを構成する全てのコンポーネントのストリームに関する情報が記述されているため、通信経由で配信されるSCSシグナリングデータを取得する必要はない。
なお、ケースＦにおいて、受信装置２０Ｂは、ハイブリッド配信に対応していないため、通信経由で配信されるコンポーネントのストリームに関する情報が記述されたSCSシグナリングデータを取得する必要がない。したがって、受信装置２０Ｂでは、LSIDとMPDを取得することで、レンダリング処理を開始することができる。
次に、SCSショートカット情報として"FALSE"が指定され、かつ、ハイブリッド情報として"FALSE"が指定されたときを、「ケースＧ」とすれば、このケースＧでは、リッチサービスを構成するコンポーネントのストリームは、放送配信されることになる。そして、ケースＧの場合において、受信装置２０Ａと受信装置２０Ｂでは、全てのSCSシグナリングデータを取得することで、放送経由で配信されるコンポーネントのストリームに接続して、レンダリング処理を開始することができる。
次に、SCSショートカット情報として"FALSE"が指定され、かつ、ハイブリッド情報として"TRUE"が指定されたときを、「ケースＨ」とすれば、このケースＨでは、リッチサービスを構成するコンポーネントのストリームは、ハイブリッド配信されることになる。そして、ケースＨの場合において、受信装置２０Ａと受信装置２０Ｂは、レンダリング処理を開始するためには、全てのSCSシグナリングデータを取得する必要がある。
ただし、ケースＨの場合においては、リッチサービスを構成するコンポーネントのストリームがハイブリッド配信されているため、受信装置２０Ａは、レンダリング処理を開始するためには、全てのSCSシグナリングデータを取得する必要があるが、放送経由で配信されるSCSシグナリングデータに、リッチサービスを構成する全てのコンポーネントのストリームに関する情報が記述されているため、ケースＦの場合と同様に、通信経由で配信されるSCSシグナリングデータを取得する必要はない。
以上のように、受信装置２０は、FICに記述された、シグナリングスコープ情報、SCSショートカット情報、及び、ハイブリッド情報を参照することで、放送経由又は通信経由で配信されるコンポーネントのストリームに効率よく接続して、所望のサービスを構成するビデオデータやオーディオデータ、字幕データなどを効率よく適切に、かつ容易に取得することができる。
また、サービスを構成するコンポーネントのストリームの配信形態（例えば放送配信やハイブリッド配信）に応じて、SCSシグナリングデータを、放送経由又は通信経由で効果的に配信することができるので、SCSシグナリングデータの配信（伝送）に用いられる放送帯域を可能な限り最小化することができる。
さらに、受信装置２０は、受信機能（性能）のタイプに応じて、放送と通信のハイブリッド受信に対応した受信装置２０Ａと、放送のみ受信に対応した受信装置２０Ｂに分類されるが、FICに記述されたシグナリングスコープ情報等によって、受信機能（性能）のタイプごとに、どのSCSシグナリングデータを取得すべきかを通知することができる。
（クラス情報）
また、FICには、クラス情報（class）が記述される。クラス情報は、１つのサービスを複数の異なるターゲットに対して、それぞれ異なるクラスのサービスを提供するために用いられる。例えば、同一のサービス（例えば番組）を、受信環境が不安定なモバイル受信機向けには、高ロバストネスの２Ｋ解像度（横2000×縦1000ピクセル程度の解像度）の映像と音声で配信する一方、受信環境が安定している固定受信機向けには、ロバストネス性能は低いが、４Ｋ解像度（横4000×縦2000ピクセル程度の解像度）の映像と高音質の音声で配信する場合が想定される。
この種のサービスの提供方法としては、例えば、ビデオストリームのレイヤードコーディングが知られている。レイヤードコーディングでは、ビデオストリームは２以上のレイヤに分割されており、各レイヤを結合することで、単一の高品質な映像を生成することが可能となる。例えば、ベースレイヤとして、低品質なビデオストリームを配信するとともに、エンハンスメントレイヤとして、ベースレイヤとしてのビデオストリームを強化するための付加情報（例えば、解像度、フレームレート、画質などを改善するための情報）を配信することができる。これにより、受信装置２０では、ベースレイヤに対応した低品質の映像（例えば２Ｋ解像度の映像）を再生するだけでなく、ベースレイヤとエンハンスメントレイヤを結合して得られる高品質の映像（例えば４Ｋ解像度の映像）を再生することもできる。
なお、以下の説明では、ベースレイヤを提供するためのクラス情報を、「コアクラス」と称し、エンハンスメントレイヤを提供するためのクラス情報を、「エンハンスクラス」と称して説明する。すなわち、クラス情報として、コアクラスとエンハンスクラスの２種類のクラス情報を提供することで、ビデオストリームのレイヤードコーディングが実現される。
なお、クラス情報の構成要素として、ビデオストリームに暗号が施されているかどうかを示す暗号化情報（sp_indicator）を設定することができる。この暗号化情報を用いることで、例えば、ベースレイヤのビデオストリーム（ベースストリーム）は暗号化せずに無料で提供し、エンハンスメントレイヤのビデオストリーム（エンハンスストリーム）は暗号化して有料で提供するなど、多様なサービス形態に対応することができる。また、クラス情報には、コアクラスやエンハンスクラス等のクラス情報ごとに、SCSシグナリングデータのストリームに接続するためのSCSブートストラップ情報が記述されている。
以上のように、FICに記述されるクラス情報を用いることで、１つのサービスを複数の異なるターゲットに対して、それぞれ異なるクラスのサービスを提供することが可能となる。例えば、ターゲットとしてのモバイル受信機向けには、高ロバストネスの２Ｋ解像度の映像と音声からなるサービスを提供することができる。また、例えば、ターゲットとしての固定受信機向けには、４Ｋ解像度の映像と高音質の音声からなるサービスを提供することができる。
＜３．運用例＞
（１）運用例１：ベーシックサービス
図４は、ベーシックサービスを提供するための運用例１を採用した場合の受信装置２０における具体的な処理の流れを説明するシーケンス図である。
図４において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、ベーシックサービス（例えば番組）を構成するコンポーネントとSCSシグナリングデータのストリームが、BBPストリームで伝送されている。ただし、ベーシックサービスを構成するコンポーネントとSCSシグナリングデータは、LCTパケット単位で、ROUTEセッションにより伝送されている。
図４において、受信装置２０は、ユーザ操作等によりサービス選局が行われた場合、NVRAMに記録されたFICを読み出して、FICのベーシックサービスのループから、選局対象のサービスのサービスIDに対応する選局情報を取得する（Ｓ１１）。なお、サービス選局（チャンネル選局）は、所望のサービス（チャンネル）を選択するための操作であって、例えば、メジャーチャンネル番号とマイナーチャンネル番号に対応したサービスIDを指定することで行われる。
なお、FICは、バイナリ形式からなり、初期スキャン処理時に取得されてNVRAMに記録されるほか、サービス選局時に、LLSストリームで伝送されているFICのバージョン情報が更新されている場合には、最新のバージョンのFICを取得して、NVRAMに記録することになる。また、FICには、サービスごとに、サービスステータス情報（service_status）が記述されているので、ベーシックサービスのサービスステータス情報を参照することで、ベーシックサービスが提供中であるかどうかを確認することができる。
受信装置２０は、FICのベーシックサービスのループから、SCSブートストラップ情報を読み出す。このSCSブートストラップ情報には、SCSシグナリングデータのストリームに接続するためのIPアドレス、ポート番号、及び、TSIが指定されている。これにより、受信装置２０は、IPアドレス、ポート番号、及び、TSIに従い、ROUTEセッションで伝送されているSCSシグナリングデータのストリームに接続することができる（Ｓ１２）。
また、図４のFICにおいて、シグナリングスコープ情報（signaling scope all）には、"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、ベーシックサービスを構成する全てのコンポーネントに関する情報を記述している。また、SCSショートカット情報（SCS_shortcut）には、"TRUE"が指定され、かつ、ハイブリッド情報（hybrid）には、"FALSE"が指定されているので、ベーシックサービスを構成するコンポーネントのストリームが、放送配信されていることを示している。
すなわち、図４のFICの記述内容は、図３のケースＥに相当し、LSIDとMPDを取得すれば、放送経由で配信されるコンポーネントのストリームに接続することができるので、受信装置２０は、SCSブートストラップ情報に基づいて、ROUTEセッションで伝送されているLSIDとMPDを取得（キャプチャ）する（Ｓ１３）。
ここで、図４に示すように、XML形式のMPDは、Period要素、AdaptationSet要素、及び、Representation要素が階層構造で記述されている。Period要素は、番組等のサービスの構成を記述する単位となる。また、AdaptationSet要素と、Representation要素は、ビデオやオーディオ、字幕などのそれぞれのストリームごとに利用され、それぞれのストリームの属性を記述できるようになっている。また、MPDでは、BaseURL属性によって、各ストリームのURL（セグメントURL）が指定される。
図４のMPDでは、ビデオストリームのURLとして、"http://sample.com/vi/rep-2kHD.mp4"が指定されている。また、オーディオストリームのURLとして、"http://sample.com/au/rep-256k.mp4"が指定されている。
また、図４に示すように、LSIDは、TransportSession要素、及び、SourceFlow要素が階層構造で記述されている。TransportSession要素には、LCTトランスポートのセッション情報として、TSI等が指定される。SourceFlow要素は、EFDT要素、ApplicationIdentifier要素、及び、PayloadFormat要素の上位要素となる。EFDT要素は、Extended FDTの略であって、拡張されたFDTに関する情報として、FileTemplate要素のTOI属性によりTOIが指定される。ApplicationIdentifier要素には、アプリケーションとマッピングするIDが指定される。PayloadFormat要素には、ソースフロー情報のペイロードフォーマットが指定される。
このように、図４のLSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。また、MPDとLSIDは、リプレゼンテーションIDにより関連付けられている。具体的には、図４の例では、ビデオストリームには、"1"であるリプレゼンテーションIDが割り当てられ、オーディオストリームには、"2"であるリプレゼンテーションIDが割り当てられているので、それらのリプレゼンテーションIDにより、MPDとLSIDが関連付けられることになる。そして、受信装置２０は、MPDに関連付けられたLSIDを参照することで、選局されたベーシックサービスを構成するビデオとオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIを特定する（Ｓ１４）。
受信装置２０は、ステップＳ１４の処理で特定されたIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオとオーディオのストリームに接続する（Ｓ１５）。これにより、受信装置２０は、ベーシックサービスを構成するビデオデータとオーディオデータを取得することができる（Ｓ１６）。なお、ビデオデータとオーディオデータは、ROUTEセッションで伝送されるので、LCTヘッダが付加されたLCTパケットに格納されたセグメントデータ（メディアセグメント）を抽出することで、それらのデータが取得されることになる。
そして、受信装置２０においては、再生処理部（DASH player）によって、レンダリング処理が行われることで、選局されたベーシックサービスに対応した番組の映像と音声が再生される（Ｓ１７）。
以上のように、運用例１では、ベーシックサービスの選局時において、FICには、シグナリングスコープ情報として"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、ベーシックサービスを構成する全てのコンポーネントに関する情報を記述していることになる。また、SCSショートカット情報には、"TRUE"が指定され、かつ、ハイブリッド情報には、"FALSE"が指定されているので、ベーシックサービスを構成するコンポーネントのストリームが、放送配信されていることになる。
受信装置２０は、FICを参照することで、これらの情報を、SCSシグナリングデータの取得前に認識して、例えば、全てのSCSシグナリングデータを参照することなく、MPDとLSIDを用いて、ベーシックサービスを構成するコンポーネントのストリームに接続することができる。その結果、受信装置２０は、ベーシックサービスを構成するビデオデータとオーディオデータを効率よく適切に、かつ容易に取得できる。
（２）運用例２：複数BBPストリームサービス（ロバスト音声）
図５は、複数BBPストリームサービスを提供するための運用例２を採用した場合の受信装置２０における具体的な処理の流れを説明するシーケンス図である。
図５において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波を伝送している。この放送波では、複数BBPストリームサービス（例えば番組）を構成するコンポーネントとSCSシグナリングデータのストリームが、複数のBBPストリームで伝送されている。
ただし、ビデオストリームと、オーディオ及びSCSシグナリングデータのストリームとは、異なるロバスト性からなるBBPストリームで伝送されている。すなわち、オーディオ及びSCSシグナリングデータのストリームは、ビデオストリームを伝送するBBPストリーム（BBP(M)）と比べて、より高いロバスト性を有するBBPストリーム（BBP(H)）で伝送されている。また、複数BBPストリームサービスを構成するコンポーネントとSCSシグナリングデータは、ROUTEセッションで伝送されている。
図５において、受信装置２０は、ユーザ操作等によりサービス選局が行われた場合、NVRAMに記録されたFICを読み出して、FICの複数BBPストリームサービスのループから、選局対象のサービスのサービスIDに対応する選局情報を取得する（Ｓ２１）。ここでは、受信装置２０は、FICの複数BBPストリームサービスのループから、SCSブートストラップ情報を読み出す。
図５のFICにおいて、シグナリングスコープ情報（signaling scope all）には、"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、複数BBPストリームサービスを構成する全てのコンポーネントに関する情報を記述している。また、SCSショートカット情報（SCS_shortcut）には、"FALSE"が指定され、かつ、ハイブリッド情報（hybrid）には、"FALSE"が指定されているので、リッチサービス（複数BBPストリームサービス）を構成するコンポーネントのストリームが、放送配信されていることを示している。
すなわち、図５のFICの記述内容は、図３のケースＧに相当し、リッチサービス（複数BBPストリームサービス）の場合には、全てのSCSシグナリングデータ（例えば、USBD，USD，SDP，MPD，LSID）を取得する必要がある。そのため、受信装置２０は、SCSブートストラップ情報に基づいて、ROUTEセッションで伝送されているSCSシグナリングデータのストリームに接続し（Ｓ２２）、全てのSCSシグナリングデータを取得（キャプチャ）する（Ｓ２３）。
ここで、図５に示すように、USBDを参照することで、USD，MPD，SDPが取得される。そして、MPDにおいては、AdaptationSet要素内のRepresentation要素に列挙されたコンポーネントの中から、レンダリング処理の対象となるコンポーネントが選択される。図５のMPDでは、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリームと、"http://sample.com/au/rep-256k.mp4"であるURLのオーディオストリームが選択される。
受信装置２０は、MPDのコンポーネントのストリームのURLと、USDのdeliveryMethod要素に記述されたURLとのマッチングを行うことで、コンポーネントの配信経路が、放送経由又は通信経由のいずれかになるかを特定する（Ｓ２４）。ここでは、MPDにおける、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリームと、"http://sample.com/au/rep-256k.mp4"であるURLのオーディオストリームは、USDのdeliveryMethod要素のbroadcastAppService要素に記述されているので、それらのコンポーネントのストリームは、放送経由で配信されていることが特定される。
また、MPDとLSIDとはリプレゼンテーションIDにより関連付けられているので、受信装置２０は、MPDに関連付けられたLSIDを参照することで、選局された複数BBPストリームサービスを構成するビデオとオーディオのストリームに接続するためのTSIを取得する（Ｓ２５−１）。
ここで、図５に示すように、テキスト形式のSDPは、セッション記述部とメディア記述部の２つの部分から構成される。セッション記述部には、プロトコルのバージョン（protocol version(v)）、SDP記述文書の生成者の情報（origin(o)）、セッションの名称（session name(s)）、セッションの有効時刻（timing(t)）、及び、ネットワークアドレスの情報（connection data(c)）等が記述される。
また、メディア記述部には、メディアアナウスメント情報（media announcements(m)）等が記述される。メディアアナウスメント情報には、メディア種別、ポート番号、プロトコル、フォーマット等の情報が指定される。また、メディア記述部では、"a="により属性種別を指定することで、SDPの機能を拡張することができる。
図５のSDPでは、１つ目のメディア記述部によりビデオストリームに関する情報が記述され、２つ目のメディア記述部によりオーディオストリームに関する情報が記述される。すなわち、ビデオストリームは、ROUTEセッションにおいて、"tsi-v"であるTSIにより伝送されている。また、ビデオストリームには、BBPストリームIDとして"middle"、ブロードキャストストリームIDとして"10"が指定されている。一方、オーディオストリームは、ROUTEセッションにおいて、"tsi-a"であるTSIにより伝送されている。また、オーディオストリームには、BBPストリームIDとして"high"、ブロードキャストストリームIDとして"10"が指定されている。
LSIDとSDPは、TSIにより関連付けられているので、受信装置２０は、LSIDのセッション情報としてのTSIと、SDPのメディア記述部のTSIとのマッチングを行うことで、選局された複数BBPストリームサービスを構成するビデオとオーディオストリームに接続するためのBBPストリームID（とブロードキャストストリームID）を特定する（Ｓ２５−２）。
ここでは、LSIDとSDPにおける"tsi-v"であるTSIが関連付けられているので、複数BBPストリームサービスを構成するビデオストリームは、"middle"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。また、LSIDとSDPにおける"tsi-a"であるTSIが関連付けられているので、複数BBPストリームサービスを構成するオーディオストリームは、"high"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。
受信装置２０は、"middle"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオストリームに接続する（Ｓ２６）。また、受信装置２０は、"high"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているオーディオストリームに接続する（Ｓ２６）。
これにより、受信装置２０は、複数BBPストリームサービスを構成するビデオデータとオーディオデータを取得することができる（Ｓ２７）。そして、受信装置２０においては、再生処理部（DASH player）によって、レンダリング処理が行われることで、選局された複数BBPストリームサービスに対応した番組の映像と音声（ロバスト音声）が再生される（Ｓ２８）。
以上のように、運用例２では、複数BBPストリームサービスの選局時において、FICには、シグナリングスコープ情報として"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、複数BBPストリームサービスを構成する全てのコンポーネントに関する情報を記述していることになる。また、SCSショートカット情報には、"FALSE"が指定され、かつ、ハイブリッド情報には、"FALSE"が指定されているので、複数BBPストリームサービスを構成するコンポーネントのストリームが、放送配信されていることになる。
受信装置２０は、FICを参照することで、これらの情報を、SCSシグナリングデータの取得前に認識して、全てのSCSシグナリングデータを参照して、異なるロバスト性からなるBBPストリームで伝送されている、複数BBPストリームサービスを構成するビデオとオーディオのストリームに接続することができる。その結果、受信装置２０は、複数BBPストリームサービスを構成するビデオデータとオーディオデータを効率よく適切に、かつ容易に取得できる。
（３）運用例３：ハイブリッドサービス１
図６は、ハイブリッドサービス１を提供するための運用例３を採用した場合の受信装置２０における具体的な処理の流れを説明するシーケンス図である。
図６において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波を伝送している。この放送波では、ハイブリッドサービス１（例えば番組）を構成するコンポーネントとSCSシグナリングデータのストリームが、BBPストリームで伝送されている。
ただし、ビデオ及びオーディオ１のストリームと、SCSシグナリングデータのストリームとは、異なるロバスト性からなるBBPストリームで伝送されている。すなわち、SCSシグナリングデータのストリームは、ビデオ及びオーディオ１のストリームを伝送するBBPストリーム（BBP(M)）と比べて、より高いロバスト性を有するBBPストリーム（BBP(H)）で伝送されている。また、ハイブリッドサービス１を構成するコンポーネントとSCSシグナリングデータは、ROUTEセッションで伝送されている。
また、図６において、ブロードバンドサーバ３０は、インターネット９０を介して、オーディオ２のストリームを配信している。なお、放送経由で配信されるオーディオ１のストリームと、通信経由で配信されるオーディオ２のストリームは、そのビットレートが異なっている（すなわち、オーディオ２のほうが高音質である）。
図６において、受信装置２０は、ユーザ操作等によりサービス選局が行われた場合、NVRAMに記録されたFICを読み出して、FICのハイブリッドサービス１のループから、選局対象のサービスのサービスIDに対応する選局情報を取得する（Ｓ３１）。ここでは、受信装置２０は、FICのハイブリッドサービス１のループから、SCSブートストラップ情報を読み出す。
図６のFICにおいて、シグナリングスコープ情報（signaling scope all）には、"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、ハイブリッドサービス１を構成する全てのコンポーネントに関する情報を記述している。また、SCSショートカット情報（SCS_shortcut）には、"FALSE"が指定され、かつ、ハイブリッド情報（hybrid）には、"TRUE"が指定されているので、リッチサービス（ハイブリッドサービス１）を構成するコンポーネントのストリームが、ハイブリッド配信されていることを示している。なお、シグナリングスコープ情報として"TRUE"が指定されているため、SCDを参照する必要はない。
すなわち、図６のFICの記述内容は、図３のケースＨに相当し、リッチサービス（ハイブリッドサービス１）の場合には、全てのSCSシグナリングデータ（例えば、USBD，USD，SDP，MPD，LSID）を取得する必要がある。そのため、受信装置２０は、SCSブートストラップ情報に基づいて、ROUTEセッションで伝送されているSCSシグナリングデータのストリームに接続し（Ｓ３２）、全てのSCSシグナリングデータを取得（キャプチャ）する（Ｓ３３）。
ここで、図６に示すように、USBDを参照することで、USD，MPD，SDPが取得される。そして、MPDにおいては、AdaptationSet要素内のRepresentation要素に列挙されたコンポーネントのストリームの中から、レンダリング処理の対象となるコンポーネントのストリームが選択される。図６のMPDでは、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリームと、"http://sample.com/au/rep-512k.mp4"であるURLのオーディオストリームが選択される。
受信装置２０は、MPDのコンポーネントのストリームのURLと、USDのdeliveryMethod要素に記述されたURLとのマッチングを行うことで、コンポーネントの配信経路が、放送経由又は通信経由のいずれかになるかを特定する（Ｓ３４）。
ここでは、MPDにおける、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリームは、USDのdeliveryMethod要素のbroadcastAppService要素に記述されているので、放送経由で配信されることが特定される。また、MPDにおける、"http://sample.com/au/rep-512k.mp4"であるURLのオーディオストリームは、USDのdeliveryMethod要素のunicastAppService要素に記述されているので、通信経由で配信されることが特定される。
また、MPDとLSIDとはリプレゼンテーションIDにより関連付けられているので、受信装置２０は、MPDに関連付けられたLSIDを参照することで、選局されたハイブリッドサービス１を構成するビデオとオーディオのストリームに接続するためのセッション情報（TSI）を取得する（Ｓ３５−１）。さらに、LSIDとSDPとは、TSIにより関連付けられているので、受信装置２０は、LSIDのセッション情報としてのTSIと、SDPのメディア記述部のTSIとのマッチングを行うことで、ハイブリッドサービス１を構成するビデオとオーディオのストリームに接続するためのBBPストリームID（とブロードキャストストリームID）を特定する（Ｓ３５−２）。なお、図示はしていないが、SCSシグナリングデータが伝送される周波数と別の周波数帯域で提供されるコンポーネントのストリームを指定する場合には、ブロードキャストストリームIDもSDPにより特定することになる。
ここでは、LSIDとSDPにおける"tsi-v"であるTSIが関連付けられているので、ハイブリッドサービス１を構成するビデオストリームは、"middle"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。また、LSIDとSDPにおける"tsi-a"であるTSIが関連付けられているので、ハイブリッドサービス１を構成するオーディオストリームは、"middle"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。
受信装置２０は、"middle"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオストリームに接続する（Ｓ３６−１）。また、受信装置２０は、MPDのオーディオストリームのURL（"http://sample.com/au/rep-512k.mp4"）に従い、インターネット９０を介してブロードバンドサーバ３０にアクセスし、オーディオ２のストリームに接続する（Ｓ３６−２）。
これにより、受信装置２０は、ハイブリッドサービス１を構成するビデオデータとオーディオデータを取得することができる。そして、受信装置２０においては、再生処理部（DASH player）によって、レンダリング処理が行われることで、選局されたハイブリッドサービス１に対応した番組の映像と音声が再生される。
以上のように、運用例３では、ハイブリッドサービス１の選局時において、FICには、シグナリングスコープ情報として"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、ハイブリッドサービス１を構成する全てのコンポーネントに関する情報を記述していることになる。また、SCSショートカット情報には、"FALSE"が指定され、かつ、ハイブリッド情報には、"TRUE"が指定されているので、ハイブリッドサービス１を構成するコンポーネントのストリームが、ハイブリッド配信されていることになる。
受信装置２０は、FICを参照することで、これらの情報を、SCSシグナリングデータの取得前に認識して、放送経由で取得される全てのSCSシグナリングデータを参照して、放送経由で配信されるビデオストリームと、通信経由で配信されるオーディオ２のストリームに接続することができる。その結果、受信装置２０は、ハイブリッドサービス１を構成するビデオデータとオーディオデータを効率よく適切に、かつ容易に取得できる。
（４）運用例４：ハイブリッドサービス２
図７は、ハイブリッドサービス２を提供するための運用例４を採用した場合の受信装置２０における具体的な処理の流れを説明するシーケンス図である。
図７において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波を伝送している。この放送波では、ハイブリッドサービス２（例えば番組）を構成するコンポーネントとSCSシグナリングデータのストリームが、BBPストリームで伝送されている。
ただし、ビデオ及びオーディオ１のストリームと、SCSシグナリングデータのストリームとは、異なるロバスト性からなるBBPストリームで伝送されている。すなわち、SCSシグナリングデータのストリームは、ビデオ及びオーディオ１のストリームを伝送するBBPストリーム（BBP(M)）と比べて、より高いロバスト性を有するBBPストリーム（BBP(H)）で伝送されている。また、ハイブリッドサービス２を構成するコンポーネントとSCSシグナリングデータは、ROUTEセッションで伝送されている。
また、図７において、ブロードバンドサーバ３０は、インターネット９０を介して、オーディオ２とSCSシグナリングデータのストリームを配信している。なお、通信経由で配信されるオーディオ２のストリームは、放送経由で配信されるオーディオ１のストリームよりも高音質とされる。
図７において、受信装置２０は、ユーザ操作等によりサービス選局が行われた場合、NVRAMに記録されたFICを読み出して、FICのハイブリッドサービス２のループから、選局対象のサービスのサービスIDに対応する選局情報を取得する（Ｓ４１）。ここでは、受信装置２０は、FICのハイブリッドサービス２のループから、SCSブートストラップ情報を読み出す。
図７のFICにおいて、シグナリングスコープ情報（signaling scope all）には、"FALSE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、ハイブリッドサービス２を構成するコンポーネントのストリームのうち、放送経由で配信されるコンポーネントのストリームに関する情報のみを記述している。また、SCSショートカット情報（SCS_shortcut）には、"FALSE"が指定され、かつ、ハイブリッド情報（hybrid）には、"TRUE"が指定されているので、リッチサービス（ハイブリッドサービス２）を構成するコンポーネントのストリームが、ハイブリッド配信されていることを示している。
すなわち、図７のFICの記述内容は、図３のケースＤに相当し、リッチサービス（ハイブリッドサービス２）の場合には、全てのSCSシグナリングデータ（例えば、USBD，USD，SDP，MPD，LSID）を取得する必要がある。そのため、受信装置２０は、SCDのSCSブロードバンドロケーション情報（SignalingOverInternet要素のuri属性）を参照することで、インターネット９０を介してブロードバンドサーバ３０にアクセスし、SCSシグナリングデータを通信経由で取得する（Ｓ４２−１，Ｓ４２−２）。
なお、ここでは、説明の簡略化のため、通信経由で配信されるSCSシグナリングデータについてのみ説明したが、実際には、FICのハイブリッドサービス２のループに配置されたSCSブートストラップ情報に従い、放送経由で配信されるSCSシグナリングデータを取得することで、レンダリング処理を開始するための全てのSCSシグナリングデータが揃うことになる。ただし、放送経由で配信されるSCSシグナリングデータを利用せずに、通信経由で配信されるSCSシグナリングデータのみで、レンダリング処理を開始するための全てのSCSシグナリングデータが揃うようにしてもよい。
ここで、図７に示すように、USBDを参照することで、USD，MPD，SDPが取得される。そして、MPDにおいては、AdaptationSet要素内のRepresentation要素に列挙されたコンポーネントのストリームの中から、レンダリング処理の対象となるコンポーネントのストリームが選択される。図７のMPDでは、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリームと、"http://sample.com/au/rep-512k.mp4"であるURLのオーディオストリームが選択される。
受信装置２０は、MPDのコンポーネントのストリームのURLと、USDのdeliveryMethod要素に記述されたURLとのマッチングを行うことで、コンポーネントの配信経路が、放送経由又は通信経由のいずれかになるかを特定する（Ｓ４４）。
ここでは、MPDにおける、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリームは、USDのdeliveryMethod要素のbroadcastAppService要素に記述されているので、放送経由で配信されることが特定される。また、MPDにおける、"http://sample.com/au/rep-512k.mp4"であるURLのオーディオストリームは、USDのdeliveryMethod要素のunicastAppService要素に記述されているので、通信経由で配信されることが特定される。
また、MPDとLSIDとはリプレゼンテーションIDにより関連付けられているので、受信装置２０は、MPDと関連付けられたLSIDを参照することで、選局されたハイブリッドサービス２を構成するビデオとオーディオのストリームに接続するためのセッション情報（TSI）を取得する（Ｓ４５−１）。さらに、LSIDとSDPとは、TSIにより関連付けられているので、受信装置２０は、LSIDのセッション情報としてのTSIと、SDPのメディア記述部のTSIとのマッチングを行うことで、ハイブリッドサービス２を構成するビデオとオーディオのストリームに接続するためのBBPストリームID（とブロードキャストストリームID）を特定する（Ｓ４５−２）。
ここでは、LSIDとSDPにおける"tsi-v"であるTSIが関連付けられているので、ハイブリッドサービス２を構成するビデオストリームは、"middle"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。また、LSIDとSDPにおける"tsi-a"であるTSIが関連付けられているので、ハイブリッドサービス２を構成するオーディオストリームは、"middle"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。
受信装置２０は、"middle"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオストリームに接続する（Ｓ４６−１）。また、受信装置２０は、MPDのオーディオストリームのURL（"http://sample.com/au/rep-512k.mp4"）に従い、インターネット９０を介してブロードバンドサーバ３０にアクセスし、オーディオ２のストリームに接続する（Ｓ４６−２）。
これにより、受信装置２０は、ハイブリッドサービス２を構成するビデオデータとオーディオデータを取得することができる。そして、受信装置２０においては、再生処理部（DASH player）によって、レンダリング処理が行われることで、選局されたハイブリッドサービス２に対応した番組の映像と音声が再生される。
以上のように、運用例４では、ハイブリッドサービス２の選局時において、FICには、シグナリングスコープ情報として"FALSE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、ハイブリッドサービス２を構成する全てのコンポーネントのストリームのうち、放送経由で配信されるコンポーネントのストリームに関する情報のみを記述していることになる。また、SCSショートカット情報には、"FALSE"が指定され、かつ、ハイブリッド情報には、"TRUE"が指定されているので、ハイブリッドサービス２を構成するコンポーネントのストリームが、ハイブリッド配信されていることになる。
受信装置２０は、FICを参照することで、これらの情報を、SCSシグナリングデータの取得前に認識して、放送経由及び通信経由で取得される全てのSCSシグナリングデータを参照して、放送経由で配信されるビデオストリームと、通信経由で配信されるオーディオ２のストリームに接続することができる。その結果、受信装置２０は、ハイブリッドサービス２を構成するビデオデータとオーディオデータを効率よく適切に、かつ容易に取得できる。
（５）運用例５：レイヤコーディングサービス（エンハンスクラス）
図８は、レイヤコーディングサービスを提供するための運用例５を採用した場合の受信装置２０における具体的な処理の流れを説明するシーケンス図である。ただし、運用例５では、レイヤコーディングサービスとして、エンハンスクラスのサービス（例えば４Ｋ解像度の映像と高音質の音声からなる番組）が提供される場合を説明する。
図８において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波を伝送している。この放送波では、レイヤコーディングサービスを構成するコンポーネントとSCSシグナリングデータのストリームが、ROUTEセッションで伝送されている。
ここで、レイヤコーディングサービスでは、ベースレイヤとしてのビデオ（Video-base）のストリーム（以下、「ベースストリーム」という）と、エンハンスメントレイヤとしてのビデオ（Video-enh）のストリーム（以下、「エンハンスストリーム」という）が伝送されている。これらのビデオストリームには、依存関係があり、例えば、低品質の映像（例えば２Ｋ解像度の映像）を再生する場合には、ベースストリームのみが必要となるが、高品質の映像（例えば４Ｋ解像度の映像）を再生する場合には、ベースストリームとエンハンスストリームの両方が必要とされる。
また、オーディオストリームとしては、高ロバストネスのオーディオ（Audio-ro）のストリーム（以下、「高ロバスト音声ストリーム」という）と、高音質のオーディオ（Audio-hq）のストリーム（以下、「高音質ストリーム」という）が伝送されている。なお、これらのオーディオストリームには、依存関係はなく、いずれか一方の音声が再生される。さらに、SCSシグナリングデータとしては、ベースレイヤ用のSCSシグナリングデータ（SCS(b)）と、エンハンスメントレイヤ用のSCSシグナリングデータ（SCS(e)）と、LSIDが伝送されている。
ここで、LSIDは、同一のサービス内では共通とされている。すなわち、ベースストリームとエンハンスストリームとは、同一のレイヤコーディングサービスとして提供されるため、同一のサービスIDであって、同一のROUTEセッションで伝送することが可能となるので、その場合には、共通のLSIDを用いることができる。
なお、高ロバスト音声ストリーム、SCSシグナリングデータ（SCS(b)，SCS(e)）のストリーム、及び、LSIDのストリームは、より高いロバスト性（高レベルのロバスト性）を有するBBPストリーム（BBP(H)）で伝送されている。また、エンハンスストリームと、高音質ストリームは、より低いロバスト性（低レベルのロバスト性）を有するBBPストリーム（BBP(L)）で伝送されている。さらに、ベースストリームは、高レベルと低レベルの間のロバスト性（中間レベルのロバスト性）を有するBBPストリーム（BBP(M)）で伝送されている。
すなわち、高ロバスト音声ストリームやSCSシグナリングデータのストリームは、確実に伝送する必要があるため、より高いロバスト性を有するBBPストリーム（BBP(H)）で伝送する一方、エンハンスストリームや高音質ストリームは、ロバスト性よりも高品質を優先するため、より低いロバスト性を有するBBPストリーム（BBP(L)）で伝送している。
図８において、受信装置２０は、ユーザ操作等によりサービス選局が行われた場合、NVRAMに記録されたFICを読み出して、FICのレイヤコーディングサービスのループから、選局対象のサービスのサービスIDに対応する選局情報を取得する（Ｓ５１）。
ここで、図８のFICにおいては、クラス情報（class）として、コアクラスとエンハンスクラスが記述されているが、エンハンスクラスが選択された場合を示している。すなわち、FICのエンハンスクラスのループには、そのクラスIDとして"enhance"が指定されており、当該クラス情報が、エンハンスメントレイヤ（とベースレイヤ）を提供するためのエンハンスクラスであることを示している。
受信装置２０は、FICのエンハンスクラスのループからSCSブートストラップ情報を読み出す。このSCSブートストラップ情報には、エンハンスメントレイヤ用のSCSシグナリングデータ（SCS(e)）のストリームに接続するためのIPアドレス、ポート番号、及び、TSIが指定されている。また、FICのレイヤコーディングサービスのループには、BBPストリームIDが指定されている。これにより、受信装置２０は、BBPストリームID、IPアドレス、ポート番号、及び、TSIに従い、ROUTEセッションで伝送されているエンハンスメントレイヤ用のSCSシグナリングデータ（SCS(e)）のストリームに接続することができる（Ｓ５２）。
また、FICにおいては、シグナリングスコープ情報（signaling scope all）には、"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、レイヤコーディングサービスを構成する全てのコンポーネントに関する情報を記述している。また、SCSショートカット情報（SCS_shortcut）には、"FALSE"が指定され、かつ、ハイブリッド情報（hybrid）には、"FALSE"が指定されているので、レイヤコーディングサービス（リッチサービス）を構成するコンポーネントのストリームが、放送配信されていることを示している。なお、シグナリングスコープ情報として"TRUE"が指定されているため、SCDを参照する必要はない。
すなわち、図８のFICの記述内容は、図３のケースＧに相当し、レイヤコーディングサービス（リッチサービス）の場合には、全てのSCSシグナリングデータ（例えば、USBD，USD，SDP，MPD，LSID）を取得する必要がある。そのため、受信装置２０は、エンハンスクラスのSCSブートストラップ情報に基づいて、ROUTEセッションで伝送されているエンハンスメントレイヤ用のSCSシグナリングデータ（SCS(e)）を取得（キャプチャ）する（Ｓ５３）。
ここで、図８に示すように、USBDを参照することで、USD，SDP，MPDが取得される。そして、MPDにおいては、AdaptationSet要素内のRepresentation要素に列挙されたコンポーネントの中から、レンダリング処理の対象となるコンポーネントが選択される。図８のMPDでは、ビデオストリームとして、"http://sample.com/vi/rep-4kUHD.mp4"であるURLのビデオストリーム（エンハンスストリーム）と、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリーム（ベースストリーム）が記述されている。
そして、"1"であるリプレゼンテーションIDのエンハンスストリームには、dependencyId属性によりディペンデンシIDとして"3"が指定されており、これは、"3"であるリプレゼンテーションIDのベースストリームと依存関係にあることを示している。すなわち、これらの依存関係にある"http://sample.com/vi/rep-4kUHD.mp4"であるURLのエンハンスストリームと、"http://sample.com/vi/rep-2kHD.mp4"であるURLのベースストリームは、USDのdeliveryMethod要素のbroadcastAppService要素に記述されているので、それらのストリームは共に、放送経由で配信されていることが特定される（Ｓ５４）。
また、図８のMPDでは、オーディオストリームとして、"http://sample.com/au/rep-256k.mp4"であるURLのオーディオストリーム（高音質ストリーム）と、"http://sample.com/au/rep-128k.mp4"であるURLのオーディオストリーム（高ロバスト音声ストリーム）が記述されている。なお、"2"であるリプレゼンテーションIDの高音質ストリームと、"4"であるリプレゼンテーションIDの高ロバスト音声ストリームには、ディペンデンシIDが指定されていないので、それらのストリームには依存関係はない。
そして、"http://sample.com/au/rep-256k.mp4"であるURLの高音質ストリームと、"http://sample.com/au/rep-128k.mp4"であるURLの高ロバスト音声ストリームは、USDのdeliveryMethod要素のbroadcastAppService要素に記述されているので、それらのストリームは共に、放送経由で配信されていることが特定される（Ｓ５４）。
ここで、LSIDは、レイヤコーディングサービス内では共通とされている。また、LSIDのストリームに接続するためのIPアドレスとポート番号は、SCSシグナリングデータ（SCS(e)）と同様とされるので、FICのエンハンスクラスのループに配置されるSCSブートストラップ情報から取得される。また、LSIDのTOIは、"0"で固定されているので、受信装置２０は、BBPストリームID、IPアドレス、ポート番号、及び、TSIに従い、ROUTEセッションで伝送されているLSIDのストリームに接続することで、LSIDを取得することができる（Ｓ５５）。
そして、MPDとLSIDとはリプレゼンテーションIDにより関連付けられているので、受信装置２０は、MPDに関連付けられたLSIDを参照することで、レイヤコーディングサービスを構成するエンハンスストリーム、ベースストリーム、及び、高音質ストリーム又は高ロバスト音声ストリームに接続するためのセッション情報（TSI）を取得する（Ｓ５６−１）。さらに、LSIDとSDPとは、TSIにより関連付けられているので、受信装置２０は、LSIDのセッション情報としてのTSIと、SDPのメディア記述部のTSIとのマッチングを行うことで、レイヤコーディングサービスを構成するエンハンスストリーム、ベースストリーム、及び、高音質ストリーム又は高ロバスト音声ストリームに接続するためのBBPストリームID（とブロードキャストストリームID）を特定する（Ｓ５６−２）。なお、図示はしていないが、SCSシグナリングデータが伝送される周波数と別の周波数帯域で提供されるコンポーネントのストリームを指定する場合には、ブロードキャストストリームIDもSDPにより特定することになる。
ここでは、LSIDとSDPにおける"tsi-ev"であるTSIが関連付けられているので、レイヤコーディングサービスを構成するエンハンスストリームは、"low"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。また、LSIDとSDPにおける"tsi-bv"であるTSIが関連付けられているので、レイヤコーディングサービスを構成するベースストリームは、"middle"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。
また、高音質ストリームが選択された場合、LSIDとSDPにおける"tsi-a-hq"であるTSIが関連付けられているので、レイヤコーディングサービスを構成する高音質ストリームは、"low"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。一方、高ロバスト音声ストリームが選択された場合、LSIDとSDPにおける"tsi-a-ro"であるTSIが関連付けられているので、レイヤコーディングサービスを構成する高ロバスト音声ストリームは、"high"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。
受信装置２０は、"low"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているエンハンスストリームに接続する（Ｓ５７）。また、"middle"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているベースストリームに接続する（Ｓ５７）。
これにより、受信装置２０は、レイヤコーディングサービスにより提供される映像を再生するためのビデオデータなどを取得することができる。すなわち、例えば、ベースストリームにより、２Ｋ解像度の映像を再生可能なビデオデータが伝送され、エンハンスメントストリームにより、２Ｋ解像度の映像を強化して４Ｋ解像度の映像にするための付加情報が伝送されている場合、受信装置２０は、再生処理部（DASH player）によって、レンダリング処理を行い、ベースレイヤとエンハンスメントレイヤを結合することで、４Ｋ解像度の映像を再生することができる。
また、受信装置２０は、"low"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されている高音質ストリームに接続する（Ｓ５７）。これにより、受信装置２０は、例えば４Ｋ解像度の映像に対応した高音質の音声を再生することができる。なお、高音質の音声の代わりに、高ロバストな音声を再生する場合には、"high"であるBBPストリームIDのBBPストリームで伝送される高ロバスト音声ストリームに接続することになる。
なお、図８の運用例５では、ベースストリームとエンハンスストリームが、放送経由で配信される場合を説明したが、ベースストリームとエンハンスストリームのうちの少なくとも一方が通信経由で配信されるようにしてもよい。その場合には、受信装置２０は、MPDのベースストリームのURL（"http://sample.com/vi/rep-2kHD.mp4"）又はエンハンスストリームのURL（"http://sample.com/vi/rep-4kUHD.mp4"）に従い、インターネット９０を介してブロードバンドサーバ３０にアクセスし、ベースストリーム又はエンハンスストリームに接続することになる。同様に、高音質ストリーム又は高ロバスト音声ストリームの少なくとも一方が通信経由で配信されるようにしてもよい。
以上のように、運用例５では、FICに記述されるクラス情報を用いることで、１つのレイヤコーディングサービスを、複数の異なるターゲット（例えば、モバイル受信機や固定受信機）に対して、それぞれ異なるクラス（例えば、コアクラスやエンハンスクラス）を提供することができるので、多様なサービス形態に対応することができる。例えば、ターゲットとしての固定受信機向けには、４Ｋ解像度の映像と高音質の音声からなるサービスを提供することができる。
また、運用例５では、レイヤコーディングサービスの選局時において、FICには、シグナリングスコープ情報として"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、レイヤコーディングサービスを構成する全てのコンポーネントに関する情報を記述していることになる。また、SCSショートカット情報には、"FALSE"が指定され、かつ、ハイブリッド情報には、"FALSE"が指定されているので、レイヤコーディングサービスを構成するコンポーネントのストリームが、放送配信されていることになる。
受信装置２０は、FICを参照することで、これらの情報を、SCSシグナリングデータの取得前に認識して、放送経由で取得される全てのSCSシグナリングデータを参照して、放送経由で配信されるビデオとオーディオのストリームに接続することができる。その結果、受信装置２０は、レイヤコーディングサービスを構成するビデオデータとオーディオデータを効率よく適切に、かつ容易に取得できる。
（６）運用例６：レイヤコーディングサービス（コアクラス）
図９は、レイヤコーディングサービスを提供するための運用例６を採用した場合の受信装置２０における具体的な処理の流れを説明するシーケンス図である。ただし、運用例６では、レイヤコーディングサービスとして、コアクラスクラスのサービス（例えば２Ｋ解像度の映像と高ロバストな音声からなる番組）が提供される場合を説明する。
図９において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波を伝送している。この放送波では、図８と同様に、高ロバスト音声ストリーム、SCSシグナリングデータ（SCS(b)，SCS(e)）のストリーム、LSIDのストリームは、高レベルのロバスト性を有するBBPストリーム（BBP(H)）で伝送されている。また、エンハンスストリームと、高音質ストリームは、低レベルのロバスト性を有するBBPストリーム（BBP(L)）で伝送されている。さらに、ベースストリームは、中間レベルのロバスト性を有するBBPストリーム（BBP(M)）で伝送されている。
図９において、受信装置２０は、ユーザ操作等によりサービス選局が行われた場合、NVRAMに記録されたFICを読み出して、レイヤコーディングサービスのループから、選局対象のサービスのサービスIDに対応する選局情報を取得する（Ｓ６１）。
ここで、図９のFICにおいては、クラス情報（class）として、コアクラスとエンハンスクラスが記述されているが、コアクラスが選択された場合を示している。すなわち、FICのコアクラスのループには、そのクラスIDとして"core"が指定されており、当該クラス情報が、ベースレイヤを提供するためのコアクラスであることを示している。
受信装置２０は、FICのコアクラスのループからSCSブートストラップ情報を読み出す。このSCSブートストラップ情報には、ベースレイヤ用のSCSシグナリングデータ（SCS(b)）のストリームに接続するためのIPアドレス、ポート番号、及び、TSIが指定されている。また、FICのレイヤコーディングサービスのループには、BBPストリームIDが指定されている。これにより、受信装置２０は、BBPストリームID、IPアドレス、ポート番号、及び、TSIに従い、ROUTEセッションで伝送されているベースレイヤ用のSCSシグナリングデータ（SCS(b)）のストリームに接続することができる（Ｓ６２）。
また、FICにおいては、シグナリングスコープ情報（signaling scope all）には、"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、レイヤコーディングサービスを構成する全てのコンポーネントに関する情報を記述している。また、SCSショートカット情報（SCS_shortcut）には、"FALSE"が指定され、かつ、ハイブリッド情報（hybrid）には、"FALSE"が指定されているので、レイヤコーディングサービス（リッチサービス）を構成するコンポーネントのストリームが、放送配信されていることを示している。なお、シグナリングスコープ情報として"TRUE"が指定されているため、SCDを参照する必要はない。
すなわち、図９のFICの記述内容は、図３のケースＧに相当し、レイヤコーディングサービス（リッチサービス）の場合には、全てのSCSシグナリングデータ（例えば、USBD，USD，SDP，MPD，LSID）を取得する必要がある。そのため、受信装置２０は、コアクラスのSCSブートストラップ情報に基づいて、ROUTEセッションで伝送されているベースレイヤ用のSCSシグナリングデータ（SCS(b)）を取得（キャプチャ）する（Ｓ６３）。
ここで、図９に示すように、USBDを参照することで、USD，SDP，MPDが取得される。そして、MPDにおいては、AdaptationSet要素内のRepresentation要素に列挙されたコンポーネントの中から、レンダリング処理の対象となるコンポーネントが選択される。図９のMPDでは、"http://sample.com/vi/rep-2kHD.mp4"であるURLのビデオストリーム（ベースストリーム）と、"http://sample.com/au/rep-128k.mp4"であるURLのオーディオストリーム（高ロバスト音声ストリーム）が記述されている。
すなわち、図９のMPDでは、図８のMPDと比べて、エンハンスストリームとベースストリームのうち、ベースストリームのみが記述されており、当然ながら、ディペンデンシIDにより依存関係も指定されていない。また、図９のMPDでは、図８のMPDと比べて、高音質ストリームと高ロバスト音声ストリームのうち、高ロバスト音声ストリームのみが記述されている。
そして、"http://sample.com/vi/rep-2kHD.mp4"であるURLのベースストリームと、"http://sample.com/au/rep-128k.mp4"であるURLの高ロバスト音声ストリームは、USDのdeliveryMethod要素のbroadcastAppService要素に記述されているので、それらのストリームは共に、放送経由で配信されていることが特定される（Ｓ６４）。
ここで、LSIDは、レイヤコーディングサービス内では共通とされている。また、LSIDのストリームに接続するためのIPアドレスとポート番号は、SCSシグナリングデータ（SCS(b)）と同様とされるので、FICのコアクラスのループに配置されるSCSブートストラップ情報から取得される。また、LSIDのTOIは、"0"で固定されているので、受信装置２０は、BBPストリームID、IPアドレス、ポート番号、及び、TSIに従い、ROUTEセッションで伝送されているLSIDのストリームに接続することで、LSIDを取得する（Ｓ６５）。
そして、MPDとLSIDとはリプレゼンテーションIDにより関連付けられているので、受信装置２０は、MPDに関連付けられたLSIDを参照することで、レイヤコーディングサービスを構成する要素のうち、ベースストリーム、及び、高ロバスト音声ストリームに接続するためのセッション情報（TSI）を取得する（Ｓ６６−１）。なお、LSIDには、エンハンスストリームと、高音質ストリームに接続するためのセッション情報（TSI）が記述されているが、ここでは、それらのセッション情報は必要ないので、無視することになる。
また、LSIDとSDPとは、TSIにより関連付けられているので、受信装置２０は、LSIDのセッション情報としてのTSIと、SDPのメディア記述部のTSIとのマッチングを行うことで、レイヤコーディングサービスを構成する要素のうち、ベースストリーム、及び、高ロバスト音声ストリームに接続するためのBBPストリームID（とブロードキャストストリームID）を特定する（Ｓ６６−２）。
ここでは、LSIDとSDPにおける"tsi-bv"であるTSIが関連付けられているので、レイヤコーディングサービスを構成するベースストリームは、"middle"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。また、LSIDとSDPにおける"tsi-a-ro"であるTSIが関連付けられているので、レイヤコーディングサービスを構成する高ロバスト音声ストリームは、"high"であるBBPストリームIDのBBPストリームで伝送されていることが特定される。
受信装置２０は、"middle"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているベースストリームに接続する（Ｓ６７）。また、受信装置２０は、"high"であるBBPストリームID、IPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されている高ロバスト音声ストリームに接続する（Ｓ６７）。
これにより、受信装置２０は、レイヤコーディングサービスを構成するビデオデータとオーディオデータを取得することができる。そして、受信装置２０においては、再生処理部（DASH player）によって、レンダリング処理が行われることで、ベースレイヤによる２Ｋ解像度の映像とその映像に対応した高ロバストな音声を再生することができる。
なお、図９の運用例６では、ベースストリームと高ロバスト音声ストリームが、放送経由で配信される場合を説明したが、ベースストリームと高ロバスト音声ストリームのうちの少なくとも一方が通信経由で配信されるようにしてもよい。
以上のように、運用例６では、FICに記述されるクラス情報を用いることで、１つのレイヤコーディングサービスを、複数の異なるターゲット（例えば、モバイル受信機や固定受信機）に対して、それぞれ異なるクラス（例えば、コアクラスやエンハンスクラス）を提供することができるので、多様なサービス形態に対応することができる。例えば、ターゲットとしてのモバイル受信機向けには、２Ｋ解像度の映像と高ロバストな音声からなるサービスを提供することができる。
また、運用例６では、レイヤコーディングサービスの選局時において、FICには、シグナリングスコープ情報として"TRUE"が指定されているので、放送経由で配信されるSCSシグナリングデータが、レイヤコーディングサービスを構成する全てのコンポーネントに関する情報を記述していることになる。また、SCSショートカット情報には、"FALSE"が指定され、かつ、ハイブリッド情報には、"FALSE"が指定されているので、レイヤコーディングサービスを構成するコンポーネントのストリームが、放送配信されていることになる。
受信装置２０は、FICを参照することで、これらの情報を、SCSシグナリングデータの取得前に認識して、放送経由で取得される全てのSCSシグナリングデータを参照して、放送経由で配信されるビデオとオーディオのストリームに接続することができる。その結果、受信装置２０は、レイヤコーディングサービスを構成するビデオデータとオーディオデータを効率よく適切に、かつ容易に取得できる。
＜４．シンタックスの例＞
（FICのシンタックス）
図１０は、バイナリ形式のFICのシンタックスの例を示す図である。なお、図１０において、新たに規定された要素は、太字で表されている。
8ビットのFIC_protocol_versionには、FICプロトコルのバージョン情報が指定される。16ビットのBroadcast_stream_idには、ブロードキャストストリームIDが指定される。
1ビットのSCD_exist_flagは、SCDがLLSストリームに存在することを示すSCDフラグである。7ビットのリザーブド領域の次には、SCDフラグが、LLSストリームに、SCDが存在することを示している場合、8ビットのBbpstream_idとして、LLSストリームが伝送されているBBPストリームのBBPストリームIDが指定される。
FIC_level_descriptor()は、FICレベルの記述子である。
8ビットのnum_servicesには、サービスの個数が指定される。このサービスの個数に応じて、サービスループが繰り返される。サービスループには、以下の内容が指定される。
8ビットのbbpstream_idには、BBPストリームIDが指定される。16ビットのprovider_idには、プロバイダIDが指定される。16ビットのservice_idには、サービスIDが指定される。
8ビットのservice_data_versionには、サービスのデータのバージョン情報が指定される。5ビットのservice_categoryには、サービスのカテゴリが指定される。例えば、カテゴリとしては、ビデオやオーディオ、ESG等が指定される。
3ビットのshort_service_name_lengthには、ショートサービス名の長さが指定される。16*mビットのshort_service_nameには、ショートサービス名が指定される。3ビットのservice_statusには、サービスが提供中であるかなどを示すサービスステータス情報が指定される。1ビットのIP_version_flagには、IPパケットのバージョンを示すフラグが指定される。
1ビットのsignalingscopeallには、シグナリングスコープ情報が指定される。シグナリングスコープ情報は、放送経由で配信されるSCSシグナリングデータの参照範囲を示す。
3ビットのnum_of_classには、クラスの個数が指定される。このクラスの個数に応じて、クラスループが繰り返される。クラスループには、クラス情報を記述するために、以下の内容が指定される。
4ビットのclass_idには、クラスIDが指定される。このクラスIDには、例えば、"core"や"enhance"等が指定される。1ビットのsp_indicatorには、サービスの保護を示す暗号化情報が指定される。例えば、暗号化情報として、ビデオストリームに暗号が施されているかどうかが指定される。
SCS_src_IP_addr_flagには、IPパケットの送信元（source）のIPアドレスを示すフラグが指定される。2ビットのリザーブド領域の次には、SCS_src_IP_addr_flagが、IPアドレスが存在していることを示している場合、32ビット又は128ビットのSCS_dst_IP_addrとして、送信元（source）のIPアドレスが指定される。
32ビット又は128ビットのSCS_dst_IP_addrには、宛先（destination）のIPアドレスが指定される。16ビットのSCS_dst_portには、ポート番号が指定される。16ビットのSCS_TSIには、TSIが指定される。これらのSCSシグナリングデータを取得するためのIPアドレス、ポート番号、及び、TSIにより、SCSブートストラップ情報が形成される。
1ビットのSCS_shortcutには、SCSショートカット情報が指定される。SCSショートカット情報は、FICに記述されるサービスが、ベーシックサービスであるか、あるいはリッチサービスであるかを示す。1ビットのhybridには、ハイブリッド情報が指定される。ハイブリッド情報は、FICに記述されるサービスを構成するコンポーネントのストリームが、放送経由でのみ配信（放送配信）されるか、あるいは放送経由と通信経由で配信（ハイブリッド配信）されるかを示す。hybridの次には、6ビットのリザーブド領域が設けられている。
なお、図１０を参照して説明したFICのシンタックスは一例であって、他のシンタックスを採用してもよい。
（SCDのシンタックス）
図１１は、XML形式のSCDのシンタックスの例を示す図である。なお、図１１において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
図１１に示すように、ルート要素としてのSCD要素は、majorProtocolVersion属性、minorProtocolVersion属性、broadcaststreamId属性、name属性、Tuning_RF要素、及び、Service要素の上位要素となる。
majorProtocolVersion属性と、minorProtocolVersion属性には、プロトコルのバージョン情報が指定される。broadcaststreamId属性には、物理チャンネル単位の放送局のブロードキャストストリームIDが指定される。name属性には、物理チャンネル単位の放送局の名称が指定される。
Tuning_RF要素には、選局に関する情報が指定される。Tuning_RF要素は、frequency属性、及び、preamble属性の上位要素となる。frequency属性には、所定の帯域を選局するときの周波数が指定される。preamble属性には、物理層の制御情報が指定される。
Service要素には、１又は複数のサービスに関する情報が指定される。Service要素は、serviceId属性、globalUniqueServiceId属性、longName属性、及び、SignalingOverInternet要素の上位要素となる。
serviceId属性には、サービスIDが指定される。複数のサービスに関する情報を配置する場合には、このサービスIDにより識別する。globalUniqueServiceId属性には、グローバルユニークサービスIDが指定される。例えば、グローバルユニークサービスIDによって、ESG選局されたサービスと、USBDとを紐付けることができる。longName属性には、サービスIDにより識別されるサービスの名称が指定される。
SignalingOverInternet要素には、SCSブロードバンドロケーション情報が指定される。このSCSブロードバンドロケーション情報によって、通信経由で配信されるSCSシグナリングデータに関する情報が指定される。SignalingOverInternet要素は、uri属性の上位要素とされる。uri属性には、SCSシグナリングデータの取得先を示すURI（Uniform Resource Identifier）が指定される。
なお、図１１において、出現数（Cardinality）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..n"が指定された場合には、その要素又は属性は１以上指定され、"0..n"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
また、図１１を参照して説明したSCDのシンタックスは一例であって、他のシンタックスを採用してもよい。
＜５．システムを構成する各装置の構成＞
次に、図１２乃至図１５を参照して、図１のサービス提供システム１を構成する、送信装置１０、受信装置２０、及び、ブロードバンドサーバ３０の詳細な構成について説明する。
（送信装置の構成例）
図１２は、本技術を適用した送信装置の一実施の形態の構成を示す図である。
図１２に示すように、送信装置１０は、シグナリング生成部１１１、シグナリング処理部１１２、ビデオデータ取得部１１３、ビデオエンコーダ１１４、オーディオデータ取得部１１５、オーディオエンコーダ１１６、Mux１１７、及び、送信部１１８から構成される。
シグナリング生成部１１１は、外部のサーバや内蔵するストレージ等から、シグナリングデータを生成するための素データを取得する。シグナリング生成部１１１は、シグナリングデータの素データを用いて、シグナリングデータを生成し、シグナリング処理部１１２に供給する。
シグナリング処理部１１２は、シグナリング生成部１１１から供給されるシグナリングデータを処理して、Mux１１７に供給する。ここでは、シグナリングデータとして、FICやSCD等のLLSメタデータからなるLLSシグナリングデータと、USBDやLSID等のSSCメタデータからなるSSCシグナリングデータが生成される。
ビデオデータ取得部１１３は、外部のサーバや内蔵するストレージ、ビデオカメラ等から提供されるビデオデータを取得し、ビデオエンコーダ１１４に供給する。ビデオエンコーダ１１４は、ビデオデータ取得部１１３から供給されるビデオデータを、MPEG（Moving Picture Experts Group）等の符号化方式に準拠して符号化し、Mux１１７に供給する。
オーディオデータ取得部１１５は、外部のサーバや内蔵するストレージ、マイクロフォン等から提供されるオーディオデータを取得し、オーディオエンコーダ１１６に供給する。オーディオエンコーダ１１６は、オーディオデータ取得部１１５から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、Mux１１７に供給する。
Mux１１７は、シグナリング処理部１１２からのシグナリングデータのストリームと、ビデオエンコーダ１１４からのビデオストリームと、オーディオエンコーダ１１６からのオーディオストリームを多重化してBBPストリームを生成し、送信部１１８に供給する。送信部１１８は、Mux１１７から供給されるBBPストリームを、IP伝送方式を用いたデジタル放送の放送波（デジタル放送信号）として、アンテナ１１９を介して送信する。
（受信装置の構成例）
図１３は、本技術を適用した受信装置の一実施の形態の構成を示す図である。
図１３に示すように、受信装置２０は、チューナ２１２、Demux２１３、制御部２１４、NVRAM２１５、入力部２１６、通信部２１７、Demux２１８、ビデオデコーダ２１９、ビデオ出力部２２０、ディスプレイ２２１、オーディオデコーダ２２２、オーディオ出力部２２３、及び、スピーカ２２４から構成される。
チューナ２１２は、制御部２１４からの制御に従い、アンテナ２１１を介して受信したIP伝送方式を用いたデジタル放送の放送波（デジタル放送信号）から、ユーザによるサービス選局操作に応じたデジタル放送信号を抽出して復調し、その結果得られるBBPストリームを、Demux２１３に供給する。
Demux２１３は、制御部２１４からの制御に従い、チューナ２１２から供給されるBBPストリームを、ビデオやオーディオ、シグナリングデータに分離する。Demux２１３は、ビデオデータをビデオデコーダ２１９に、オーディオデータをオーディオデコーダ２２２に、シグナリングデータを制御部２１４にそれぞれ供給する。
制御部２１４は、受信装置２０の各部の動作を制御する。また、制御部２１４は、Demux２１３又は通信部２１７から供給されるシグナリングデータに基づいて、放送経由又は通信経由で伝送されるコンポーネントのストリームに接続して、当該コンポーネントの再生を制御するために、各部の動作を制御する。なお、制御部２１４の詳細な構成については、図１４を参照して後述する。
NVRAM２１５は、不揮発性メモリであって、制御部２１４からの制御に従い、各種のデータを記憶する。入力部２１６は、ユーザの操作に応じて、操作信号を制御部２１４に供給する。
通信部２１７は、制御部２１４からの制御に従い、インターネット９０を介してブロードバンドサーバ３０に接続し、コンポーネントのストリームの配信を要求する。通信部２１７は、インターネット９０を介してブロードバンドサーバ３０からストリーミング配信されるコンポーネントのストリームを受信して、Demux２１８に供給する。また、通信部２１７は、制御部２１４からの制御に従い、インターネット９０を介してブロードバンドサーバ３０から、SSCシグナリングデータ等のデータを受信し、制御部２１４に供給する。
Demux２１８は、制御部２１４からの制御に従い、通信部２１７から供給されるコンポーネントのストリームを、ビデオデータと、オーディオデータに分離し、ビデオデータをビデオデコーダ２１９に、オーディオデータをオーディオデコーダ２２２に供給する。
ビデオデコーダ２１９には、Demux２１３又はDemux２１８からビデオデータが供給される。ビデオデコーダ２１９は、制御部２１４からの制御に従い、ビデオデータを、MPEG等の復号方式に準拠して復号し、ビデオ出力部２２０に供給する。ビデオ出力部２２０は、ビデオデコーダ２１９から供給されるビデオデータを、ディスプレイ２２１に出力する。これにより、ディスプレイ２２１には、例えば番組の映像が表示される。
オーディオデコーダ２２２には、Demux２１３又はDemux２１８からオーディオデータが供給される。オーディオデコーダ２２２は、制御部２１４からの制御に従い、オーディオデータを、MPEG等の復号方式に準拠して復号し、オーディオ出力部２２３に供給する。オーディオ出力部２２３は、オーディオデコーダ２２２から供給されるオーディオデータを、スピーカ２２４に出力する。これにより、スピーカ２２４からは、例えば番組の映像に対応する音声が出力される。
なお、図１３においては、受信装置２０がセットトップボックス等である場合には、ディスプレイ２２１やスピーカ２２４を有しない構成とすることができる。また、受信装置２０は、通信部２１７等の通信機能を有しない構成とすることもできる。さらに、受信装置２０においては、ビデオデコーダ２１９、ビデオ出力部２２０、オーディオデコーダ２２２、及び、オーディオ出力部２２３と、それらを制御する制御部２１４によって、上述した再生処理部（DASH player）が構成される。
（制御部の機能的構成例）
図１４は、図１３の制御部２１４における、初期スキャン処理、選局処理、フィルタリング処理、及び、通信処理の制御を行う部分の機能的構成例を示す図である。
図１４において、制御部２１４は、選局制御部２５１、フィルタリング制御部２５２、シグナリング取得部２５３、シグナリング解析部２５４、通信制御部２５５、及び、パケットヘッダ監視部２５６から構成される。また、シグナリング取得部２５３は、LLSシグナリング取得部２７１及びSCSシグナリング取得部２７２から構成される。
選局制御部２５１は、チューナ２１２により実行される選局処理を制御する。フィルタリング制御部２５２は、Demux２１３により実行されるフィルタリング処理を制御する。
初期スキャン処理時においては、選局制御部２５１がチューナ２１２を制御し、フィルタリング制御部２５２がDemux２１３を制御することで、LLSシグナリング取得部２７１によって、LLSストリームで伝送されるLLSシグナリングデータが取得され、シグナリング解析部２５４に供給される。シグナリング解析部２５４は、LLSシグナリング取得部２７１からのLLSシグナリングデータ（FICやSCD等のLLSメタデータ）を解析して得られる選局情報を、NVRAM２１５に記録する。
選局制御部２５１は、ユーザによりサービス選局操作が行われた場合、入力部２１６からの操作信号に応じて、NVRAM２１５に記録された選局情報（FICやSCD）を取得する。選局制御部２５１は、取得された選局情報に基づいて、チューナ２１２により実行される選局処理を制御する。また、選局制御部２５１は、選局情報（FIC）に含まれるSCSブートストラップ情報を、フィルタリング制御部２５２に供給する。
フィルタリング制御部２５２は、選局制御部２５１から供給されるSCSブートストラップ情報に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。これにより、Demux２１３では、選局対象のサービスを構成するSCSストリームに接続され、当該ストリームがROUTEセッションで伝送されている場合、LCTパケットからSCSシグナリングデータが抽出される。SCSシグナリング取得部２７２は、SCSシグナリングデータ（USBD，USD，SDP，MPD，LSID等のSCSメタデータ）を取得して、シグナリング解析部２５４に供給する。
シグナリング解析部２５４は、SCSシグナリング取得部２７２から供給されるSCSシグナリングデータ（USBD，USD，SDP，MPD，LSID等のSCSメタデータ）を解析し、その解析結果を、フィルタリング制御部２５２又は通信制御部２５５に供給する。すなわち、シグナリング解析部２５４は、選局対象のサービスを構成するコンポーネントのストリームの配信経路が放送経由となる場合には、それらのコンポーネントのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIを特定し、フィルタリング制御部２５２に供給する。また、シグナリング解析部２５４は、選局対象のサービスを構成するコンポーネントのストリームの配信経路が通信経由となる場合には、それらの取得先の情報（例えばURL）を、通信制御部２５５に供給する。
フィルタリング制御部２５２は、シグナリング解析部２５４から供給されるIPアドレス、ポート番号、TSI、及び、TOIに基づいて、Demux２１３により実行されるフィルタリング処理を制御する。これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出される。そして、その結果得られるビデオデータは、ビデオデコーダ２１９に供給され、オーディオデータは、オーディオデコーダ２２２に供給される。
通信制御部２５５は、シグナリング解析部２５４から供給される取得先の情報（例えばURL）に基づいて、通信部２１７により実行される通信処理を制御する。これにより、通信部２１７では、ブロードバンドサーバ３０からインターネット９０を介してストリーミング配信されるコンポーネントのストリームが受信され、Demux２１８に供給される。そして、Demux２１８により、通信部２１７から供給されるストリームから得られるビデオデータがビデオデコーダ２１９に、オーディオデータがオーディオデコーダ２２２にそれぞれ供給される。なお、ブロードバンドサーバ３０からSCSシグナリングデータが配信された場合には、通信部２１７からのSCSシグナリングデータは、SCSシグナリング取得部２７２に供給される。
パケットヘッダ監視部２５６は、Demux２１３においてBBPストリームにより伝送されるパケットを監視して、監視対象のパケットのヘッダを解析する。パケットヘッダ監視部２５６は、パケットのヘッダの解析結果に従い、フィルタリング制御部２５２を制御して、特定の条件を満たしたパケットから得られるLLSメタデータやSCSメタデータが、シグナリング取得部２５３により取得されるようにする。なお、このフィルタリング処理では、例えば、圧縮情報（Compression Scheme）、タイプ情報（Fragment Type）、拡張タイプ情報（Type Extension）、及び、バージョン情報の少なくとも１つの情報を特定の条件として、フィルタリングが行われる。
（ブロードバンドサーバの構成例）
図１５は、本技術を適用したブロードバンドサーバの一実施の形態の構成を示す図である。
図１５に示すように、ブロードバンドサーバ３０は、シグナリング生成部３１１、シグナリング処理部３１２、ビデオデータ取得部３１３、ビデオエンコーダ３１４、オーディオデータ取得部３１５、オーディオエンコーダ３１６、データ保持部３１７、通信部３１８、及び、制御部３１９から構成される。
シグナリング生成部３１１は、外部のサーバや内蔵するストレージ等から、SCSシグナリングデータを生成するための素データを取得する。シグナリング生成部３１１は、SCSシグナリングデータの素データを用いて、SCSシグナリングデータを生成し、シグナリング処理部３１２に供給する。
シグナリング処理部３１２は、シグナリング生成部３１１から供給されるSCSシグナリングデータを処理して、データ保持部３１７に保持させる。ここでは、SCSシグナリングデータとして、USBDやLSID等のSCSメタデータが生成される。
ビデオデータ取得部３１３は、外部のサーバや内蔵するストレージ、ビデオカメラ等から提供されるビデオデータを取得し、ビデオエンコーダ３１４に供給する。ビデオエンコーダ３１４は、ビデオデータ取得部３１３から供給されるビデオデータを、MPEG等の符号化方式に準拠して符号化し、データ保持部３１７に保持させる。
オーディオデータ取得部３１５は、外部のサーバや内蔵するストレージ、マイクロフォン等から提供されるオーディオデータを取得し、オーディオエンコーダ３１６に供給する。オーディオエンコーダ３１６は、オーディオデータ取得部３１５から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、データ保持部３１７に保持させる。
データ保持部３１７は、制御部３１９からの制御に従い、シグナリング処理部３１２からのSCSシグナリングデータ、ビデオエンコーダ３１４からのビデオデータ、及び、オーディオエンコーダ３１６からのオーディオデータを保持する。
通信部３１８は、制御部３１９からの制御に従い、インターネット９０を介して受信装置２０と通信を行う。通信部３１８は、受信装置２０からの要求に応じて、データ保持部３１７に保持されている、SCSシグナリングデータ、ビデオデータ、又は、オーディオデータを読み出して、インターネット９０を介して、その要求元の受信装置２０に送信する。
＜６．各装置で実行される処理の流れ＞
次に、図１６乃至図２１のフローチャートを参照して、図１のサービス提供システム１を構成する各装置で実行される具体的な処理の流れについて説明する。
（送信処理）
まず、図１６のフローチャートを参照して、送信装置１０により実行される送信処理の流れについて説明する。
ステップＳ１１１において、シグナリング生成部１１１は、シグナリングデータの素データを用いて、シグナリングデータを生成し、シグナリング処理部１１２に供給する。ステップＳ１１２において、シグナリング処理部１１２は、シグナリング生成部１１１から供給されるシグナリングデータを処理し、Mux１１７に供給する。
ここでは、シグナリングデータとして、FICやSCD等のLLSメタデータと、USBDやLSID等のSCSメタデータが生成される。ただし、シグナリングデータは、外部のサーバが生成するようにしてもよい。その場合には、シグナリング生成部１１１は、外部のサーバから供給されるシグナリングデータをそのまま、シグナリング処理部１１２に供給する。
ステップＳ１１３において、ビデオデータ取得部１１３は、外部のサーバ等から、コンポーネントとしてのビデオデータを取得し、ビデオエンコーダ１１４に供給する。また、ステップＳ１１３において、オーディオデータ取得部１１５は、外部のサーバ等から、コンポーネントとしてのオーディオデータを取得し、オーディオエンコーダ１１６に供給する。
ステップＳ１１４において、ビデオエンコーダ１１４は、ビデオデータ取得部１１３から供給されるコンポーネントとしてのビデオデータを、MPEG等の符号化方式に準拠して符号化し、Mux１１７に供給する。また、ステップＳ１１４において、オーディオエンコーダ１１６は、オーディオデータ取得部１１５から供給されるコンポーネントとしてのオーディオデータを、MPEG等の符号化方式に準拠して符号化し、Mux１１７に供給する。
ステップＳ１１５において、Mux１１７は、シグナリング処理部１１２からのシグナリングデータと、ビデオエンコーダ１１４からのビデオストリームと、オーディオエンコーダ１１６からのオーディオストリームを多重化してBBPストリームを生成し、送信部１１８に供給する。
ステップＳ１１６において、送信部１１８は、Mux１１７から供給されるBBPストリームをデジタル放送信号として、アンテナ１１９を介して送信する。ステップＳ１１６の処理が終了すると、図１６の送信処理は終了する。
なお、図１６の送信処理において、ビデオやオーディオ等のコンポーネントのストリームを、ROUTEセッションで伝送する場合には、各コンポーネントのファイルを、ISO BMFFの規定に準じたセグメントごとに分割し、それにより得られるセグメントデータをLCTパケットに格納して伝送することになる。
さらに、デジタル放送信号において、LLSシグナリングデータ（FICやSCD等のLLSメタデータ）を格納したLLSパケットのLLSヘッダ、あるいは、SCSシグナリングデータ（USBDやLSID等のメタデータ）を格納したLCTパケットのLCTヘッダには、圧縮情報（Compression Scheme）、タイプ情報（Fragment Type）、拡張タイプ情報（Type Extension）、及び、バージョン情報などのフィルタリング情報を配置することができる。
以上、送信処理の流れについて説明した。
（周波数スキャン処理）
次に、図１７のフローチャートを参照して、受信装置２０により実行される周波数スキャン処理の流れについて説明する。
ステップＳ２１１においては、制御部２１４によって、入力部２１６からの操作信号等が監視され、周波数スキャン処理イベントが発生するまで、待機する。そして、ステップＳ２１２において、周波数スキャン処理イベントが発生したと判定された場合、処理は、ステップＳ２１３に進められる。
ステップＳ２１３において、チューナ２１２は、選局制御部２５１からの制御に従い、周波数スキャン処理を行う。ステップＳ２１４においては、ステップＳ２１３の周波数スキャン処理によって、周波数スキャンが成功したかどうかが判定される。
ステップＳ２１４において、周波数スキャンが失敗したと判定された場合、処理は、ステップＳ２１３の処理に戻り、再度、周波数スキャン処理が行われる。一方、ステップＳ２１４において、周波数スキャン処理に成功したと判定された場合、処理は、ステップＳ２１５に進められる。
ステップＳ２１５において、Demux２１３は、フィルタリング制御部２５２からの制御に従い、チューナ２１２から供給されるBBPストリームを取得して解析する。ステップＳ２１６においては、FICが伝送されているかどうかが判定される。
ステップＳ２１６において、FICが伝送されていると判定された場合、処理はステップＳ２１７に進められる。ステップＳ２１７においては、FICが取得され、NVRAM２１５に記録される。なお、ステップＳ２１６において、FICが伝送されていないと判定された場合、ステップＳ２１７の処理はスキップされ、処理は、ステップＳ２１８に進められる。
ステップＳ２１８においては、ステップＳ２１５の解析結果に従い、BBPストリームからIPパケットが抽出されたかどうかが判定される。
ステップＳ２１８において、IPパケットが抽出されたと判定された場合、処理はステップＳ２１９に進められる。ステップＳ２１９において、Demux２１３は、抽出されたIPパケットを破棄する。一方、ステップＳ２１８において、IPパケット以外のパケットが抽出されたと判定された場合、処理は、ステップＳ２２０に進められる。
ステップＳ２２０においては、ステップＳ２１５の解析結果に従い、BBPストリームからLLSパケットが抽出されたかどうかが判定される。
ステップＳ２２０において、LLSパケット以外のパケットが抽出されたと判定された場合、処理は、ステップＳ２１９に進められる。ステップＳ２１９において、Demux２１３は、抽出されたLLSパケット以外のパケットを破棄する。一方、ステップＳ２２０において、LLSパケットが抽出されたと判定された場合、処理は、ステップＳ２２１に進められる。
ステップＳ２２１において、Demux２１３、及び、制御部２１４は、LLS取得・記録処理を実行する。このLLS取得・記録処理では、LLSパケットに付加されたLLSヘッダのフィルタリング情報に基づいて、フィルタリング処理が行われ、当該フィルタリング処理により取得されたLLSシグナリングデータ（SCD等のLLSメタデータ）が、選局情報としてNVRAM２１５に記録される。なお、LLS取得・記録処理の詳細な内容は、図１８のフローチャートを参照して後述する。
ステップＳ２１９、又は、ステップＳ２２１の処理が終了すると、処理は、ステップＳ２２２に進められる。ステップＳ２２２においては、全周波数帯域のスキャンが完了したかどうかが判定される。
ステップＳ２２２において、全周波数帯域のスキャンが未完了であると判定された場合、処理は、ステップＳ２１３の処理に戻り、ステップＳ２１３以降の処理が繰り返される。これにより、各周波数帯域のスキャン処理が行われ、選局情報が記録される。そして、ステップＳ２２２において、全周波数帯域のスキャンが完了したと判定された場合、図１７の周波数スキャン処理は終了される。
以上、周波数スキャン処理の流れについて説明した。
（LLS取得・記録処理）
次に、図１８のフローチャートを参照して、図１７のステップＳ２２１の処理に対応するLLS取得・記録処理の詳細な内容について説明する。
ステップＳ２３１において、パケットヘッダ監視部２５６は、Demux２１３においてBBPストリームにより伝送されるLLSパケットを常に監視して、監視対象のLLSパケットのLLSヘッダを解析する。
ステップＳ２３２において、パケットヘッダ監視部２５６は、ステップＳ２３１の解析結果に従い、シグナリングデータ（LLSメタデータ）のタイプが一致するかどうかを判定する。すなわち、LLSパケットのLLSヘッダには、タイプ情報（Fragment Type）が配置されているので、パケットヘッダ監視部２５６は、例えば、Type="000000"であるタイプ情報が配置されたLLSヘッダが付加されたLLSパケットが抽出されたかどうかを判定する。
なお、LLSヘッダのタイプ情報（Fragment Type）には、LLSメタデータの種別に応じた値が指定される。例えば、SCDには"000000"、EADには"000001"、RRDには"000010"、DCDには"000011"がそれぞれ指定される。
ステップＳ２３２において、シグナリングデータ（LLSメタデータ）のタイプが異なると判定された場合、処理は、ステップＳ２３３に進められる。ステップＳ２３３において、Demux２１３は、抽出されたLLSパケットを破棄する。一方、ステップＳ２３２において、シグナリングデータ（LLSメタデータ）のタイプが一致すると判定された場合、処理は、ステップＳ２３４に進められる。
ステップＳ２３４において、パケットヘッダ監視部２５６は、ステップＳ２３１の解析結果に従い、対象のLLSシグナリングデータ（LLSメタデータ）が新規取得であるかどうかを判定する。すなわち、LLSパケットのLLSヘッダには、バージョン情報が配置されているので、パケットヘッダ監視部２５６は、最新のバージョンとなるバージョン情報が配置されたLLSヘッダが付加されたLLSパケットが抽出されたかどうかを判定する。
ステップＳ２３４において、対象のLLSシグナリングデータ（LLSメタデータ）が取得済みであると判定された場合、処理は、ステップＳ２３３に進められる。ステップＳ２３３において、Demux２１３は、抽出されたLLSパケットを破棄する。一方、ステップＳ２３４において、対象のLLSシグナリングデータ（LLSメタデータ）が新規取得であると判定された場合、処理は、ステップＳ２３５に進められる。
ステップＳ２３５においては、パケットヘッダ監視部２５６は、ステップＳ２３１の解析結果に従い、拡張フィルタ情報（Filter_Extension）の処理を行う。すなわち、LLSパケットのLLSヘッダには、拡張タイプ情報が配置されているので、この拡張フィルタ情報の処理では、例えば、対象の地域や緊急度など、あらかじめ定められた特定の条件を満たした拡張フィルタ情報が配置されたLLSヘッダが付加されたLLSパケットが抽出されたかどうかが判定される。
なお、フィルタリング制御部２５２は、パケットヘッダ監視部２５６からの制御に従い、Demux２１３を制御して、監視対象のLLSパケットのフィルタリング処理を行っており、監視対象のLLSパケットのうち、特定の条件を満たしたLLSパケットから得られるLLSシグナリングデータが、LLSシグナリング取得部２７１により取得される。
ステップＳ２３６において、シグナリング解析部２５４は、LLSシグナリング取得部２７１により取得されたLLSシグナリングデータ（SCD等のLLSメタデータ）を、NVRAM２１５に記録する。これにより、NVRAM２１５には、LLSシグナリングデータ（SCD等のLLSメタデータ）から得られる選局情報が記録されることになる。ステップＳ２３３、又は、ステップＳ２３６の処理が終了すると、処理は、図１７のステップＳ２２１の処理に戻り、それ以降の処理が実行される。
以上、LLS取得・記録処理の流れについて説明した。
（選局前処理）
次に、図１９のフローチャートを参照して、受信装置２０により実行される選局前処理の流れについて説明する。
ステップＳ２５１においては、選局制御部２５１によって、入力部２１６からの操作信号等が監視され、サービス選局イベントが発生するまで、待機する。そして、ステップＳ２５２において、サービス選局イベントが発生したと判定された場合、処理は、ステップＳ２５３に進められる。
ステップＳ２５３において、選局制御部２５１は、選局されたサービスに対応するサービスID（チャンネル番号）を取得する。また、ステップＳ２５４において、選局制御部２５１は、NVRAM２１５を参照して、選局情報（FIC）が記録され、取得済みであるかどうかを判定する。
ステップＳ２５４において、選局情報が取得済みであると判定された場合、処理は、ステップＳ２５５に進められる。ステップＳ２５５において、選局制御部２５１は、NVRAM２１５に記録された選局情報（FICやSCD）を読み出して取得する。
一方、ステップＳ２５４において、選局情報が取得済みではないと判定された場合、処理は、ステップＳ２５６に進められる。ステップＳ２５６においては、Demux２１３、及び、制御部２１４によって、LLSストリームから、FICが取得される。これにより、制御部２１４においては、選局情報（FICやSCD）が取得されることになる（Ｓ２５５）。なお、FICは、LLSストリームではなく、例えば物理層等の下位の階層（レイヤ）で伝送される場合があり、その場合にはそこから取得される。
ステップＳ２５７においては、チューナ２１２、Demux２１３、及び、制御部２１４等によって、ステップＳ２５５の処理で取得された選局情報（FICやSCD）に基づいた選局処理が行われる。なお、選局処理の詳細な内容は、図２０及び図２１のフローチャートを参照して後述する。
以上、選局前処理の流れについて説明した。
（選局処理）
次に、図２０のフローチャートを参照して、図１９のステップＳ２５７の処理に対応する選局処理の詳細な内容を説明する。
ステップＳ２７１において、シグナリング解析部２５４は、NVRAM２１５に記録されたFICを読み出して、FICに記述されたクラス情報を解析する。ここでは、ターゲットとしての受信装置２０（例えば、モバイル受信機や固定受信機）が、例えばエンハンスクラスやコアクラス等のどのクラスに属しているかが判定される。そして、この判定結果に基づいて、後続の処理が実行される。
ステップＳ２７２において、制御部２１４は、受信装置２０が通信機能を有しているかどうかと、通信機能を有している場合にはその機能が有効になっているかどうかを確認することで、受信装置２０が放送のみを受信可能であるかどうかを判定する。ステップＳ２７２において、例えば、仮に、受信装置２０Ｂが、通信部２１７等の通信機能を有しておらず、放送のみ受信可能であると判定された場合、処理は、ステップＳ２７３に進められる。
ステップＳ２７３において、シグナリング解析部２５４は、NVRAM２１５に記録された選局情報（FIC）を参照して、SCSショートカット情報（SCS_shortcut）に、"TRUE"が指定されているかどうかを判定する。
ステップＳ２７３において、SCSショートカット情報（SCS_shortcut）に、"TRUE"が指定されていると判定された場合、処理は、ステップＳ２７４に進められる。ステップＳ２７４において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているMPDとLSIDを取得する。ステップＳ２７４の処理で取得されたMPDとLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ２７５において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。
これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。また、ステップＳ２７６においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップＳ２７５の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得（キャプチャ）される。
そして、例えば、ステップＳ２７５の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図１９のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ２８１）。
このように、FICのSCSショートカット情報（SCS_shortcut）として"TRUE"が指定されている場合、全てのSCSメタデータを参照することなく、MPDとLSIDを用いて、所望のコンポーネントを取得することができる。
一方、ステップＳ２７３において、SCSショートカット情報（SCS_shortcut）に、"FALSE"が指定されていると判定された場合、処理は、ステップＳ２７７に進められる。ステップＳ２７７において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているUSBD，USD，MPD，SDP等のSCSシグナリングデータを取得する。ステップＳ２７７の処理で取得されたSDPは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ２７８において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップＳ２７８の処理で取得されたLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ２７９において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。
これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。また、ステップＳ２８０においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップＳ２７９の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得（キャプチャ）される。
そして、例えば、ステップＳ２７９の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図１９のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ２８１）。
このように、FICのSCSショートカット情報（SCS_shortcut）として"FALSE"が指定されている場合、MPDとLSIDに記述された内容のみではコンポーネントの取得先を特定することができないため、MPDとLSIDのほか、USBD，USD，SDP等の他のSCSメタデータを参照して、所望のコンポーネントを取得することになる。ステップＳ２８１の処理が終了すると、処理は、図１９のステップＳ２５７の処理に戻り、それ以降の処理が実行される。
なお、ステップＳ２７２において、受信装置２０（受信装置２０Ａ）が、放送と通信のハイブリッド受信に対応していると判定された場合、処理は、ステップＳ２８２に進められる。ステップＳ２８２においては、放送と通信のハイブリッドに対応した選局処理が行われる。なお、ハイブリッドに対応した選局処理の詳細な内容は、図２１のフローチャートを参照して後述する。
以上、選局処理の流れについて説明した。
（ハイブリッドに対応した選局処理）
次に、図２１のフローチャートを参照して、図２０のステップＳ２８２の処理に対応する、ハイブリッドに対応した選局処理の詳細な内容を説明する。
ステップＳ２９１において、シグナリング解析部２５４は、NVRAM２１５に記録された選局情報（FIC）を参照して、ハイブリッド情報（hybrid）に、"TRUE"が指定されているかどうかを判定する。
ステップＳ２９１において、ハイブリッド情報（hybrid）に、"TRUE"が指定されていないと判定された場合、処理は、図２０のステップＳ２７３に進められ、それ以降の処理が実行される。すなわち、この場合、コンポーネントのストリームが放送のみで配信されることを意味するので、ハイブリッド受信に対応した受信装置２０Ａであっても、通信機能を使用せずに、放送のみ受信可能な受信装置２０Ｂと同様の処理が行われる。
また、ステップＳ２９１において、ハイブリッド情報（hybrid）に、"TRUE"が指定されていると判定された場合、処理は、ステップＳ２９２に進められる。ステップＳ２９２においては、受信装置２０が通信機能を有効にして、ハイブリッド受信を可能な設定となっているかどうかが判定される。
ステップＳ２９２において、受信装置２０がハイブリッド受信を可能な設定となっていないと判定された場合、処理は、図２０のステップＳ２７３に進められ、それ以降の処理が実行される。すなわち、この場合には、ハイブリッドに対応した受信装置２０Ａであっても、通信機能を使用せずに、放送のみ受信可能な受信装置２０Ｂと同様の処理が行われる。
また、ステップＳ２９２において、受信装置２０がハイブリッド受信を可能な設定となっていると判定された場合、処理は、ステップＳ２９３に進められる。ステップＳ２９３において、シグナリング解析部２５４は、NVRAM２１５に記録された選局情報（FIC）を参照して、シグナリングスコープ情報（signaling scope all）に、"TRUE"が指定されているかどうかを判定する。
ステップＳ２９３において、シグナリングスコープ情報（signaling scope all）に、"TRUE"が指定されていると判定された場合、処理は、ステップＳ２９４に進められる。ステップＳ２９４において、フィルタリング制御部２５２は、SCSブートストラップ情報に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているUSBD，USD，MPD，SDP等のSCSシグナリングデータを取得する。
なお、SCSブートストラップ情報は、エンハンスクラスやコアクラスなどのクラス情報ごとに設定されるので、図２０のステップＳ２７１の処理で判定されたクラス情報に応じたSCSシグナリングデータが取得されることになる。
一方、ステップＳ２９３において、シグナリングスコープ情報（signaling scope all）に、"FALSE"が指定されていると判定された場合、処理は、ステップＳ２９５に進められる。ステップＳ２９５において、シグナリング解析部２５４は、NVRAM２１５に記録された選局情報（SCD）を参照して、SCDに、SCSブロードバンドロケーション情報（SignalingOverInternet要素のuri属性）が存在するかどうかを判定する。
ステップＳ２９５において、SCDに、SCSブロードバンドロケーション情報（SignalingOverInternet要素のuri属性）が存在すると判定された場合、処理は、ステップＳ２９６に進められる。ステップＳ２９６において、通信制御部２５５は、シグナリング解析部２５４からの解析結果（SignalingOverInternet要素のuri属性）に従い、通信部２１７を制御して、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、USBD，USD，MPD，SDP等のSCSシグナリングデータを取得する。
なお、ステップＳ２９５において、SCSブロードバンドロケーション情報（SignalingOverInternet要素のuri属性）が存在しないと判定された場合、処理は、ステップＳ２９４に進められ、放送経由でSCSシグナリングデータが取得される。
ステップＳ２９４又はステップＳ２９６の処理が終了すると、処理は、ステップＳ２９７に進められる。ステップＳ２９７において、シグナリング解析部２５４は、ステップＳ２９４又はステップＳ２９６の処理で取得されたMPDを解析して、AdaptationSet要素内のRepresentation要素に列挙されたコンポーネントの中から、レンダリング処理の対象となるコンポーネント（視聴するコンポーネント）を決定する。
ステップＳ２９８において、シグナリング解析部２５４は、ステップＳ２９４又はステップＳ２９６の処理で取得されたUSDとMPDを解析して、MPDのセグメントURLが、USDのdeliveryMethod要素のbroadcastAppService要素又はunicastAppService要素に記述されているかどうかにより、取得するコンポーネントのストリームの配信経路が、放送経由であるか、あるいは通信経由であるかどうかを判定する。
ステップＳ２９８において、コンポーネントの配信経路が放送経由であると判定された場合、処理は、ステップＳ２９９に進められる。なお、この場合、ステップＳ２９４又はステップＳ２９６の処理で取得されたSCSシグナリングデータは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
そして、ステップＳ２９９において、シグナリング取得部２５３は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップＳ２９９の処理で取得されたLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ３００において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。
一方、ステップＳ２９８において、コンポーネントの配信経路が通信経由であると判定された場合、処理は、ステップＳ３０１に進められる。ステップＳ３０１において、シグナリング解析部２５４は、ステップＳ２９４又はステップＳ２９６の処理で取得されたMPDを解析して、その解析の結果得られるメディアセグメント情報（セグメントURL）を、通信制御部２５５に供給する。これにより、通信制御部２５５は、シグナリング解析部２５４からのメディアセグメント情報（セグメントURL）を取得する。
そして、ステップＳ３００において、通信制御部２５５は、シグナリング解析部２５４からのメディアセグメント情報（セグメントURL）に従い、通信部２１７を制御して、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、選局されたサービスを構成するコンポーネントを取得（キャプチャ）する。
ステップＳ３００の処理が終了すると、処理は、ステップＳ３０２に進められる。ステップＳ３０２においては、取得する全てのコンポーネントがキャプチャされたかどうかが判定される。ステップＳ３０２において、全てのコンポーネントがキャプチャされていないと判定された場合、処理は、ステップＳ２９８に戻り、それ以降の処理が繰り返される。
すなわち、ステップＳ２９８乃至Ｓ３０２の処理が繰り返されることで、放送経由又は通信経由でコンポーネントが取得され、ステップＳ３０２において、全てのコンポーネントがキャプチャされたと判定された場合、処理は、ステップＳ３０３に進められる。ステップＳ３０３においては、例えば、ステップＳ３００の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図１９のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ３０３）。
ステップＳ３０３の処理が終了すると、処理は、図２０のステップＳ２８２の処理に戻り、それ以降の処理が実行される。
以上、ハイブリッドに対応した選局処理の流れについて説明した。
＜７．変形例＞
上述した説明では、現在策定が進められている米国の次世代放送規格であるATSC3.0において、IP伝送方式を用いたデジタル放送の採用が見込まれているため、地上デジタルテレビ放送の規格として、米国等が採用する方式であるATSCを説明したが、日本等が採用する方式であるISDB（Integrated Services Digital Broadcasting）や、欧州の各国等が採用する方式であるDVB（Digital Video Broadcasting）などに適用するようにしてもよい。また、地上デジタルテレビ放送に限らず、衛星デジタルテレビ放送やデジタル有線テレビ放送などで採用するようにしてもよい。
また、上述した説明では、シグナリングデータの名称として、Descriptionの略である「D」を用いたが、Tableの略である「T」が用いられる場合がある。例えば、SCD（Service Configuration Description）は、SCT（Service Configuration Table）と記述される場合がある。また、例えば、SPD（Service Parameter Description）は、SPT（Service Parameter Table）と記述される場合がある。ただし、これらの名称の違いは、「Description」と「Table」との形式的な違いであって、各シグナリングデータの実質的な内容が異なるものではない。
さらに、上述した説明では、シグナリングデータが、バイナリ形式やテキスト形式により記述された場合における、その要素や属性について説明したが、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。例えば、FIC等に規定されるブロードキャストストリームID（Broadcast Stream ID）は、ネットワークID（Network ID）やRFアロケーションID（RF Alloc ID）、RFチャンネルID（RF Channel ID）などと称するようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
＜８．コンピュータの構成＞
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ９００において、CPU（Central Processing Unit）９０１，ROM（Read Only Memory）９０２，RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記憶されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
（１）
IP（Internet Protocol）伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを取得する第１の取得部と、
前記第１のメタデータに含まれる前記クラス情報に基づいて、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに接続して、前記コンポーネントの再生を制御する制御部と
を備える受信装置。
（２）
前記クラス情報は、複数の形態ごとに、前記コンポーネントのストリームに関する情報を含む第２のメタデータを取得するためのブートストラップ情報を含み、
前記ブートストラップ情報に基づいて、前記第２のメタデータを取得する第２の取得部をさらに備え、
前記制御部は、前記第２のメタデータに基づいて、前記コンポーネントのストリームに接続する
（１）に記載の受信装置。
（３）
前記サービスは、レイヤードコーディングを提供するサービスであって、
前記クラス情報は、ベースレイヤを提供するための情報と、エンハンスメントレイヤを提供するための情報を含んでいる
（２）に記載の受信装置。
（４）
前記第１のメタデータは、放送経由で配信される前記第２のメタデータのみで、前記サービスを構成するコンポーネントを取得できるかどうかを示すシグナリングスコープ情報を含み、
前記第２の取得部は、前記シグナリングスコープ情報に基づいて、前記第２のメタデータを取得する
（２）又は（３）に記載の受信装置。
（５）
前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームがMIMEタイプにより個別に識別可能なベーシックサービスであるか、あるいは前記ベーシックサービス以外のサービスであるかを示すショートカット情報を含み、
前記第２の取得部は、前記ショートカット情報に基づいて、前記第２のメタデータを取得する
（２）乃至（４）のいずれか一項に記載の受信装置。
（６）
前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームが、放送経由のみで配信されるか、あるいは放送経由と通信経由で配信されるかを示すハイブリッド情報を含み、
前記第２の取得部は、前記ハイブリッド情報に基づいて、前記第２のメタデータを取得する
（２）乃至（５）のいずれか一項に記載の受信装置。
（７）
前記サービスを構成するコンポーネントのストリームは、放送経由又は通信経由で配信され、
前記第２のメタデータは、放送経由又は通信経由で配信される
（２）乃至（６）のいずれか一項に記載の受信装置。
（８）
前記第１のメタデータは、バイナリ形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第１のシグナリングデータであり、
前記第２のメタデータは、テキスト形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第２のシグナリングデータである
（２）乃至（６）のいずれか一項に記載の受信装置。
（９）
前記サービスを構成するコンポーネントと、前記第２のシグナリングデータのストリームは、FLUTE（File Delivery over Unidirectional Transport）を拡張したROUTE（Real-time Object Delivery over Unidirectional Transport）セッションで伝送される
（８）に記載の受信装置。
（１０）
受信装置の受信方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを取得し、
前記第１のメタデータに含まれる前記クラス情報に基づいて、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに接続して、前記コンポーネントの再生を制御する
ステップを含む受信方法。
（１１）
IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを生成する生成部と、
生成された前記第１のメタデータを送信する送信部と
を備える送信装置。
（１２）
前記クラス情報は、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに関する情報を含む第２のメタデータを取得するためのブートストラップ情報を含む
（１１）に記載の送信装置。
（１３）
前記サービスは、レイヤードコーディングを提供するサービスであって、
前記クラス情報は、ベースレイヤを提供するための情報と、エンハンスメントレイヤを提供するための情報を含んでいる
（１２）に記載の送信装置。
（１４）
前記第１のメタデータは、放送経由で配信される前記第２のメタデータのみで、前記サービスを構成するコンポーネントを取得できるかどうかを示すシグナリングスコープ情報を含む
（１２）又は（１３）に記載の送信装置。
（１５）
前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームがMIMEタイプにより個別に識別可能なベーシックサービスであるか、あるいは前記ベーシックサービス以外のサービスであるかを示すショートカット情報を含む
（１２）乃至（１４）のいずれか一項に記載の送信装置。
（１６）
前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームが、放送経由のみで配信されるか、あるいは放送経由と通信経由で配信されるかを示すハイブリッド情報を含む
（１２）乃至（１５）のいずれか一項に記載の送信装置。
（１７）
前記サービスを構成するコンポーネントのストリームは、放送経由又は通信経由で配信され、
前記第２のメタデータは、放送経由又は通信経由で配信される
（１２）乃至（１６）のいずれか一項に記載の送信装置。
（１８）
前記第１のメタデータは、バイナリ形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第１のシグナリングデータであり、
前記第２のメタデータは、テキスト形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第２のシグナリングデータである
（１２）乃至（１６）のいずれか一項に記載の送信装置。
（１９）
前記サービスを構成するコンポーネントと、前記第２のシグナリングデータのストリームは、FLUTEを拡張したROUTEセッションで伝送される
（１８）に記載の送信装置。
（２０）
送信装置の送信方法において、
前記送信装置が、
IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを生成し、
生成された前記第１のメタデータを送信する
ステップを含む送信方法。
１ サービス提供システム， １０ 送信装置， ２０ 受信装置， ３０ ブロードバンドサーバ， ９０ インターネット， １１１ シグナリング生成部， １１３ ビデオデータ取得部， １１５ オーディオデータ取得部， １１８ 送信部， ２１２ チューナ， ２１４ 制御部， ２１７ 通信部， ２５１ 選局制御部， ２５２ フィルタリング制御部， ２５３ シグナリング取得部， ２５４ シグナリング解析部， ２５５ 通信制御部， ２５６ パケットヘッダ監視部， ２７１ LLSシグナリング取得部， ２７２ SCSシグナリング取得部， ３１１ シグナリング生成部， ３１３ ビデオデータ取得部， ３１５ オーディオデータ取得部， ３１８ 通信部， ９００ コンピュータ， ９０１ CPU

Claims (20)

  1. IP（Internet Protocol）伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを取得する第１の取得部と、
    前記第１のメタデータに含まれる前記クラス情報に基づいて、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに接続して、前記コンポーネントの再生を制御する制御部と
    を備える受信装置。
  2. 前記クラス情報は、複数の形態ごとに、前記コンポーネントのストリームに関する情報を含む第２のメタデータを取得するためのブートストラップ情報を含み、
    前記ブートストラップ情報に基づいて、前記第２のメタデータを取得する第２の取得部をさらに備え、
    前記制御部は、前記第２のメタデータに基づいて、前記コンポーネントのストリームに接続する
    請求項１に記載の受信装置。
  3. 前記サービスは、レイヤードコーディングを提供するサービスであって、
    前記クラス情報は、ベースレイヤを提供するための情報と、エンハンスメントレイヤを提供するための情報を含んでいる
    請求項２に記載の受信装置。
  4. 前記第１のメタデータは、放送経由で配信される前記第２のメタデータのみで、前記サービスを構成するコンポーネントを取得できるかどうかを示すシグナリングスコープ情報を含み、
    前記第２の取得部は、前記シグナリングスコープ情報に基づいて、前記第２のメタデータを取得する
    請求項２に記載の受信装置。
  5. 前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームがMIMEタイプにより個別に識別可能なベーシックサービスであるか、あるいは前記ベーシックサービス以外のサービスであるかを示すショートカット情報を含み、
    前記第２の取得部は、前記ショートカット情報に基づいて、前記第２のメタデータを取得する
    請求項２に記載の受信装置。
  6. 前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームが、放送経由のみで配信されるか、あるいは放送経由と通信経由で配信されるかを示すハイブリッド情報を含み、
    前記第２の取得部は、前記ハイブリッド情報に基づいて、前記第２のメタデータを取得する
    請求項２に記載の受信装置。
  7. 前記サービスを構成するコンポーネントのストリームは、放送経由又は通信経由で配信され、
    前記第２のメタデータは、放送経由又は通信経由で配信される
    請求項２に記載の受信装置。
  8. 前記第１のメタデータは、バイナリ形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第１のシグナリングデータであり、
    前記第２のメタデータは、テキスト形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第２のシグナリングデータである
    請求項２に記載の受信装置。
  9. 前記サービスを構成するコンポーネントと、前記第２のシグナリングデータのストリームは、FLUTE（File Delivery over Unidirectional Transport）を拡張したROUTE（Real-time Object Delivery over Unidirectional Transport）セッションで伝送される
    請求項８に記載の受信装置。
  10. 受信装置の受信方法において、
    前記受信装置が、
    IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを取得し、
    前記第１のメタデータに含まれる前記クラス情報に基づいて、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに接続して、前記コンポーネントの再生を制御する
    ステップを含む受信方法。
  11. IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを生成する生成部と、
    生成された前記第１のメタデータを送信する送信部と
    を備える送信装置。
  12. 前記クラス情報は、複数の形態ごとに、前記サービスを構成するコンポーネントのストリームに関する情報を含む第２のメタデータを取得するためのブートストラップ情報を含む
    請求項１１に記載の送信装置。
  13. 前記サービスは、レイヤードコーディングを提供するサービスであって、
    前記クラス情報は、ベースレイヤを提供するための情報と、エンハンスメントレイヤを提供するための情報を含んでいる
    請求項１２に記載の送信装置。
  14. 前記第１のメタデータは、放送経由で配信される前記第２のメタデータのみで、前記サービスを構成するコンポーネントを取得できるかどうかを示すシグナリングスコープ情報を含む
    請求項１２に記載の送信装置。
  15. 前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームがMIMEタイプにより個別に識別可能なベーシックサービスであるか、あるいは前記ベーシックサービス以外のサービスであるかを示すショートカット情報を含む
    請求項１２に記載の送信装置。
  16. 前記第１のメタデータは、前記サービスを構成するコンポーネントのストリームが、放送経由のみで配信されるか、あるいは放送経由と通信経由で配信されるかを示すハイブリッド情報を含む
    請求項１２に記載の送信装置。
  17. 前記サービスを構成するコンポーネントのストリームは、放送経由又は通信経由で配信され、
    前記第２のメタデータは、放送経由又は通信経由で配信される
    請求項１２に記載の送信装置。
  18. 前記第１のメタデータは、バイナリ形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第１のシグナリングデータであり、
    前記第２のメタデータは、テキスト形式のデータであって、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第２のシグナリングデータである
    請求項１２に記載の送信装置。
  19. 前記サービスを構成するコンポーネントと、前記第２のシグナリングデータのストリームは、FLUTEを拡張したROUTEセッションで伝送される
    請求項１８に記載の送信装置。
  20. 送信装置の送信方法において、
    前記送信装置が、
    IP伝送方式を用いたデジタル放送の放送波で伝送される、IPアドレスで識別されるサービスを複数の形態で提供するためのクラス情報を含む第１のメタデータを生成し、
    生成された前記第１のメタデータを送信する
    ステップを含む送信方法。
JP2016558978A 2014-11-13 2015-10-30 受信装置、受信方法、送信装置、及び、送信方法 Expired - Fee Related JP6643246B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014231107 2014-11-13
JP2014231107 2014-11-13
PCT/JP2015/080663 WO2016076137A1 (ja) 2014-11-13 2015-10-30 受信装置、受信方法、送信装置、及び、送信方法

Publications (2)

Publication Number Publication Date
JPWO2016076137A1 true JPWO2016076137A1 (ja) 2017-08-24
JP6643246B2 JP6643246B2 (ja) 2020-02-12

Family

ID=55954229

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016558978A Expired - Fee Related JP6643246B2 (ja) 2014-11-13 2015-10-30 受信装置、受信方法、送信装置、及び、送信方法

Country Status (8)

Country Link
US (1) US11343549B2 (ja)
EP (1) EP3220653B1 (ja)
JP (1) JP6643246B2 (ja)
KR (2) KR101760445B1 (ja)
CN (1) CN105900440B (ja)
CA (1) CA2936328C (ja)
MX (2) MX2016008872A (ja)
WO (1) WO2016076137A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010021526A2 (en) * 2008-08-22 2010-02-25 Lg Electronics Inc. A method for processing additional information related to an announced service or content in an nrt service and a broadcast receiver
EP3220649A4 (en) * 2014-11-13 2018-06-20 LG Electronics Inc. Broadcasting signal transmission device, broadcasting signal reception device, broadcasting signal transmission method, and broadcasting signal reception method
US10389460B2 (en) * 2014-12-08 2019-08-20 Lg Electronics Inc. Broadcasting signal transmission apparatus, broadcasting signal receiving apparatus, broadcasting signal transmission method and broadcasting signal receiving method
WO2016093537A1 (ko) 2014-12-10 2016-06-16 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10667004B2 (en) * 2014-12-22 2020-05-26 Lg Electronics Inc. Broadcasting signal reception device, and broadcasting signal reception method based on pull mode
US10721505B2 (en) * 2015-01-21 2020-07-21 Lg Electronic Inc. Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
CN109313632B (zh) * 2016-04-22 2022-04-29 维迪阁传媒公司 一种用于增强网络环境中数据处理的系统和方法
TWI670975B (zh) * 2016-11-04 2019-09-01 日商夏普股份有限公司 用於傳訊一使用者服務配套描述之方法及用於演現一視訊服務之裝置
US11570509B2 (en) * 2020-01-06 2023-01-31 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
US11683355B2 (en) 2021-01-05 2023-06-20 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
CN113132386B (zh) * 2021-04-20 2023-07-25 中国科学院上海高等研究院 多协议兼容的引导传输发送、接收方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012077353A1 (ja) * 2010-12-10 2012-06-14 パナソニック株式会社 送信装置、受信装置、送信方法及び受信方法
EP2618563A2 (en) * 2010-09-14 2013-07-24 LG Electronics Inc. Apparatus for transmitting broadcasting signal, apparatus for receiving broadcasting signal, and method for transmitting/receiving broadcasting signal through apparatus for transmitting/receiving broadcasting signal
WO2014042028A1 (ja) * 2012-09-13 2014-03-20 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
US20140219266A1 (en) * 2007-06-29 2014-08-07 Lg Electronics Inc. Digital broadcasting system and method of processing data
WO2016111176A1 (ja) * 2015-01-07 2016-07-14 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
WO2016129407A1 (ja) * 2015-02-10 2016-08-18 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6282713B1 (en) 1998-12-21 2001-08-28 Sony Corporation Method and apparatus for providing on-demand electronic advertising
US20030009769A1 (en) * 2001-06-25 2003-01-09 Debra Hensgen Trusted application level resource advisor
GB2408433A (en) * 2003-11-18 2005-05-25 Nokia Corp Datacasting service components sequentially within a burst
US8818344B2 (en) * 2006-11-14 2014-08-26 Microsoft Corporation Secured communication via location awareness
DK2139142T3 (da) 2007-09-28 2013-06-03 Lg Electronics Inc Apparat til at sende og modtage et signal og fremgangsmåde til at sende og modtage et signal
WO2009051687A2 (en) 2007-10-15 2009-04-23 Thomson Licensing Apparatus and method for encoding and decoding signals
JP5045535B2 (ja) 2008-04-28 2012-10-10 ソニー株式会社 受信装置及び受信方法
US8537746B2 (en) * 2008-06-09 2013-09-17 Lg Electronics Inc. Method for mapping signaling information to announcement information and broadcast receiver
US9516375B2 (en) * 2008-12-02 2016-12-06 Orckit Ip, Llc Edge optimized transrating system
JP5541488B2 (ja) 2009-02-09 2014-07-09 ソニー株式会社 コンテンツ受信装置および方法
KR101652808B1 (ko) 2009-03-19 2016-09-01 엘지전자 주식회사 송/수신 시스템 및 데이터 처리 방법
CA2781827C (en) * 2009-11-25 2016-05-24 Lg Electronics Inc. Method of processing epg metadata in network device and network device for controlling the same
KR101690831B1 (ko) * 2011-01-19 2016-12-28 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
EP2667622B1 (en) * 2011-01-19 2019-05-01 Samsung Electronics Co., Ltd Apparatus and method for configuring a control message in a broadcast system
US9326045B2 (en) * 2011-04-20 2016-04-26 Lg Electronics Inc. Transmission method for broadcast service, reception method therefor, and reception apparatus therefor
WO2013032221A1 (ko) * 2011-08-31 2013-03-07 엘지전자 주식회사 디지털 방송 신호 처리 방법 및 장치
CN104541511A (zh) 2012-08-10 2015-04-22 Lg电子株式会社 信号收发装置和信号收发方法
US9432431B2 (en) * 2014-03-18 2016-08-30 Accenture Global Servicse Limited Manifest re-assembler for a streaming video channel
CA2947833C (en) * 2014-05-21 2018-11-20 Lg Electronics Inc. Broadcast signal transmitting/receiving method and device

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140219266A1 (en) * 2007-06-29 2014-08-07 Lg Electronics Inc. Digital broadcasting system and method of processing data
EP2618563A2 (en) * 2010-09-14 2013-07-24 LG Electronics Inc. Apparatus for transmitting broadcasting signal, apparatus for receiving broadcasting signal, and method for transmitting/receiving broadcasting signal through apparatus for transmitting/receiving broadcasting signal
WO2012077353A1 (ja) * 2010-12-10 2012-06-14 パナソニック株式会社 送信装置、受信装置、送信方法及び受信方法
WO2014042028A1 (ja) * 2012-09-13 2014-03-20 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
WO2016111176A1 (ja) * 2015-01-07 2016-07-14 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
WO2016129407A1 (ja) * 2015-02-10 2016-08-18 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Service Multiplex and TransportSubsystem Characteristics", ATSC MOBILE DTV STANDARD A/153, vol. Part 3, JPN6019049448, 29 October 2013 (2013-10-29), US, pages 14 - 34, ISSN: 0004175209 *

Also Published As

Publication number Publication date
KR20170008717A (ko) 2017-01-24
CA2936328A1 (en) 2016-05-19
KR101760445B1 (ko) 2017-07-21
JP6643246B2 (ja) 2020-02-12
US20160330490A1 (en) 2016-11-10
KR20170086133A (ko) 2017-07-25
CA2936328C (en) 2021-08-17
EP3220653A1 (en) 2017-09-20
WO2016076137A1 (ja) 2016-05-19
KR102332387B1 (ko) 2021-11-30
CN105900440B (zh) 2020-05-29
EP3220653A4 (en) 2018-04-04
MX2016008872A (es) 2016-10-11
EP3220653B1 (en) 2019-12-04
CN105900440A (zh) 2016-08-24
MX2019015454A (es) 2020-02-12
US11343549B2 (en) 2022-05-24

Similar Documents

Publication Publication Date Title
JP6643246B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
US11374993B2 (en) Reception device, reception method, transmission device, and transmission method
KR102484513B1 (ko) 수신 장치, 수신 방법, 송신 장치, 및, 송신 방법
JP6617712B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
KR101722364B1 (ko) 송신 장치 및 수신 장치
JP6598031B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
WO2015198872A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181004

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20191217

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200106

R150 Certificate of patent or registration of utility model

Ref document number: 6643246

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees