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

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

Info

Publication number
JPWO2016056412A1
JPWO2016056412A1 JP2016553048A JP2016553048A JPWO2016056412A1 JP WO2016056412 A1 JPWO2016056412 A1 JP WO2016056412A1 JP 2016553048 A JP2016553048 A JP 2016553048A JP 2016553048 A JP2016553048 A JP 2016553048A JP WO2016056412 A1 JPWO2016056412 A1 JP WO2016056412A1
Authority
JP
Japan
Prior art keywords
service
metadata
component
stream
attribute
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
JP2016553048A
Other languages
English (en)
Other versions
JP6610553B2 (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 JPWO2016056412A1 publication Critical patent/JPWO2016056412A1/ja
Application granted granted Critical
Publication of JP6610553B2 publication Critical patent/JP6610553B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/26—Arrangements for switching distribution systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/42—Arrangements for resource management
    • H04H20/423—Transmitter side
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/68—Systems specially adapted for using specific information, e.g. geographical or meteorological information
    • H04H60/73—Systems specially adapted for using specific information, e.g. geographical or meteorological information using meta-information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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
    • H04H—BROADCAST COMMUNICATION
    • H04H2201/00—Aspects of broadcast communication
    • H04H2201/40—Aspects of broadcast communication characterised in that additional data relating to the broadcast data are available via a different channel than the broadcast channel

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本技術は、サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得できるようにする受信装置、受信方法、送信装置、及び、送信方法に関する。受信装置は、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伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータが生成され、生成された前記第２のメタデータが送信される。
本技術の第１の側面、及び、第２の側面によれば、サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得できる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
固定受信機が用いられる場合のサービス提供システムの構成例を示す図である。 モバイル受信機が用いられる場合のサービス提供システムの構成例を示す図である。 シグナリングデータの例を示す図である。 SCDのSCBootstrap要素のLSIDBaseService属性とhybrid属性の組み合わせの例を示す図である。 運用例１のシステムパイプモデルを示す図である。 運用例１のシーケンス図である。 運用例２−１のシステムパイプモデルを示す図である。 運用例２−１のシーケンス図である。 運用例２−２のシステムパイプモデルを示す図である。 運用例２−２のシーケンス図である。 運用例３のシステムパイプモデルを示す図である。 運用例３のシーケンス図である。 運用例４のシステムパイプモデルを示す図である。 運用例４のシーケンス図である。 運用例５−１のシステムパイプモデルを示す図である。 運用例５−１のシーケンス図である。 運用例５−２のシステムパイプモデルを示す図である。 本技術を適用した送信装置の一実施の形態の構成を示す図である。 本技術を適用した受信装置の一実施の形態の構成を示す図である。 図１９の制御部の機能的な構成例を示す図である。 本技術を適用したブロードバンドサーバの一実施の形態の構成を示す図である。 送信処理の流れを説明するフローチャートである。 初期スキャン処理の流れを説明するフローチャートである。 LLS取得・記録処理の流れを説明するフローチャートである。 選局前処理の流れを説明するフローチャートである。 選局処理の詳細な内容を説明するフローチャートである。 ハイブリッドに対応した選局処理の詳細な内容を説明するフローチャートである。 LLSパケットの構造を示す図である。 LLSヘッダのLLSインデックスの例を示す図である。 SCDのシンタックスを示す図である。 EADのシンタックスを示す図である。 EADによる緊急警報情報の表示例を示す図である。 RRDのシンタックスを示す図である。 DCDのシンタックスの例を示す図である。 LCTパケットの構造を示す図である。 LCTヘッダのSCSインデックスの例を示す図である。 LSIDのシンタックスの例を示す図である。 SourceFlow要素のシンタックスの例を示す図である。 EFDT要素のシンタックスの例を示す図である。 RepairFlow要素のシンタックスの例を示す図である。 ProtectedObject要素のシンタックスの例を示す図である。 SPDのシンタックスの例を示す図である。 HybridSignalLocationDescription要素のシンタックスの例を示す図である。 ContentAdvisoryDescription要素のシンタックスの例を示す図である。 NRTServiceDescription要素のシンタックスの例を示す図である。 ProtocolVersionDescription要素のシンタックスの例を示す図である。 CapabilityDescription要素のシンタックスの例を示す図である。 IconDescription要素のシンタックスの例を示す図である。 ISO-639 Language Description要素のシンタックスの例を示す図である。 ReceiverTargetingDescription要素のシンタックスの例を示す図である。 コンピュータの構成例を示す図である。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．運用例
（１）運用例１：放送基本サービス選局（固定受信機、ダイレクト選局）
（２）運用例２−１：ハイブリッドサービス選局１（固定受信機、ダイレクト選局）
（３）運用例２−２：ハイブリッドサービス選局２（固定受信機、ダイレクト選局）
（４）運用例３：放送基本サービス選局（モバイル受信機、ESG選局）
（５）運用例４：放送基本サービス選局（固定受信機、ESG選局）
（６）運用例５−１：ロバストサービス選局１（固定受信機、ダイレクト選局）
（７）運用例５−２：ロバストサービス選局２（固定受信機、ダイレクト選局）
３．システムを構成する各装置の構成
４．各装置で実行される処理の流れ
５．シンタックスの例
（１）LLSシグナリングデータ
（２）SCSシグナリングデータ
６．変形例
７．コンピュータの構成
＜１．システムの構成＞
（固定受信機が用いられる場合のサービス提供システムの構成例）
図１は、固定受信機が用いられる場合のサービス提供システムの構成例を示す図である。
図１において、サービス提供システム１は、固定受信機としての受信装置２０Ａに対して、サービスの提供を行うシステムである。サービス提供システム１は、送信装置１０、受信装置２０Ａ、ブロードバンドサーバ３０、及び、インターネットサーバ４０から構成される。また、受信装置２０Ａは、インターネット９０を介して、ブロードバンドサーバ３０及びインターネットサーバ４０と相互に接続されている。
送信装置１０は、例えば地上デジタルテレビ放送の所定の規格に対応した送信機であって、放送事業者により提供されて放送局に設置される。なお、本技術の実施の形態の地上デジタルテレビ放送の規格としては、例えば、ATSC（Advanced Television Systems Committee standards）等の規格を採用することができる。
送信装置１０は、サービス（例えば番組）を構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、シグナリングデータとともに、IP（Internet Protocol）伝送方式を用いたデジタル放送の放送波によって送信する。
なお、シグナリングデータには、サービスに依存しないLLS（Low Layer Signaling）シグナリングデータと、サービス単位のSCS（Service Channel Signaling）シグナリングデータの２種類が存在するが、その詳細な内容については後述する。
また、ビデオやオーディオ等のコンポーネントと、SCSシグナリングデータは、ROUTEセッションにより伝送される。ROUTEは、放送のライブサービス向けに、FLUTE（RFC6276,5775,5651）を拡張したものである。なお、ROUTEは、FLUTE +（FLUTE plus）やFLUTE enhancementなどと称される場合がある。
ROUTEセッションでは、送信するファイルなどを１つのオブジェクトとして、TOI（Transport Object Identifier）により管理する。また、複数のオブジェクトの集合を１つのセッションとして、TSI（Transport Session Identifier）により管理する。すなわち、ROUTEセッションにおいては、TSIとTOIの２つの識別情報によって特定のファイルを指定することが可能となる。
受信装置２０Ａは、例えば地上デジタルテレビ放送の所定の規格に対応したテレビ受像機やセットトップボックスなどの固定受信機であって、例えば各ユーザの家庭に設置される。また、受信装置２０Ａは、通信機能を有しており、インターネット９０を介して、ブロードバンドサーバ３０又はインターネットサーバ４０にアクセスすることができる。ただし、受信装置２０Ａは必ずしも、通信機能を有している必要はない。
受信装置２０Ａは、送信装置１０から送信されるデジタル放送の放送波を受信して、当該デジタル放送の放送波で伝送されるシグナリングデータを取得する。受信装置２０Ａは、取得されたシグナリングデータに基づいて、送信装置１０から送信されるデジタル放送の放送波で伝送されるサービス（を構成するコンポーネント）のストリームに接続して、そのストリームから得られる映像と音声を再生（出力）する。
ブロードバンドサーバ３０は、受信装置２０Ａからの要求に応じて、サービス（例えば番組）を構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、インターネット９０を介してストリーミング配信する。また、ブロードバンドサーバ３０は、受信装置２０Ａからの要求に応じて、シグナリングデータを、インターネット９０を介して配信する。
受信装置２０Ａは、送信装置１０又はブロードバンドサーバ３０からのシグナリングデータに基づいて、ブロードバンドサーバ３０からインターネット９０を介してストリーミング配信されるサービス（を構成するコンポーネント）のストリームに接続して、そのストリームから得られる映像と音声を再生（出力）する。
インターネットサーバ４０は、受信装置２０Ａからの要求に応じて、各種の情報を配信するサーバである。例えば、インターネットサーバ４０は、緊急警報に関する緊急警報情報を配信するようにすることができる。この場合、受信装置２０Ａは、インターネットサーバ４０にインターネット９０を介してアクセスすることで、インターネットサーバ４０から緊急警報情報を取得して表示することができる。
（モバイル受信機が用いられる場合のサービス提供システムの構成例）
図２は、モバイル受信機が用いられる場合のサービス提供システムの構成例を示す図である。
図２において、サービス提供システム２は、モバイル受信機としての受信装置２０Ｂが放送エリアを移動した場合でも、継続的にサービスを提供可能なシステムである。サービス提供システム２は、図１のサービス提供システム１と比べて、受信装置２０Ａの代わりに、受信装置２０Ｂが設けられ、さらに、中継局５０とアクセスポイント６０が設けられている。
送信装置１０から送信されるデジタル放送の放送波は、中継局５０を介して、当該中継局５０の放送エリア内の受信装置２０Ｂにより受信される。また、アクセスポイント６０は、公衆無線LAN（Local Area Network）のアクセスポイントであって、アクセスポイント６０の通信エリア内の受信装置２０Ｂは、アクセスポイント６０を介してインターネット９０に接続することが可能である。
受信装置２０Ｂは、例えば、スマートフォンや携帯電話機、タブレット型コンピュータ、パーソナルコンピュータ、自動車内で利用される端末などのモバイル受信機であって、例えば地上デジタルテレビ放送の所定の規格に対応している。
受信装置２０Ｂは、アクセスポイント６０を介してインターネット９０に接続し、ブロードバンドサーバ３０から、シグナリングデータを取得する。また、受信装置２０Ｂは、送信装置１０から送信されるデジタル放送の放送波を、中継局５０を介して受信して、当該デジタル放送の放送波で伝送されるシグナリングデータを取得する。
受信装置２０Ｂは、送信装置１０又はブロードバンドサーバ３０から取得したシグナリングデータに基づいて、送信装置１０又はブロードバンドサーバ３０から伝送される、サービス（を構成するコンポーネント）のストリームに接続して、そのストリームから得られる映像と音声を再生（出力）する。
なお、図２においては、説明の都合上、１つの送信装置１０と、１つの中継局５０が設置された構成を示したが、実際には、１以上の送信装置１０と、複数の中継局５０が設置され、複数の中継局５０による複数の放送エリアを、モバイル受信機としての受信装置２０Ｂが移動することになる。また、受信装置２０Ｂは、アクセスポイント６０を介さずに、例えばLTE（Long Term Evolution）等のモバイル系のネットワークを介して、ブロードバンドサーバ３０に接続するようにしてもよい。
サービス提供システム１、２は、以上のように構成される。なお、以下の説明では、受信装置２０Ａと、受信装置２０Ｂを特に区別する必要がない場合には、単に、受信装置２０と称して説明する。
（シグナリングデータの例）
図３は、シグナリングデータの例を示す図である。
シグナリングデータには、LLS（Low Layer Signaling）ストリームで伝送されるLLSシグナリングデータと、SCS（Service Channel Signaling）ストリームで伝送されるSCSシグナリングデータがある。
LLSシグナリングデータは、サービスに依存しない低レイヤのシグナリングデータであって、IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される。例えば、LLSシグナリングデータとしては、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セッションで伝送される。
SCDは、MPEG2-TS方式に対応したID体系によって、ネットワーク内のBBPストリーム構成とサービス構成を示している。また、SCDには、ESGストリームに接続するためのESGブートストラップ情報や、SCSストリームに接続するためのSCブートストラップ情報、SCSシグナリングデータを通信経由で取得するためのSCSブロードバンドロケーション情報などが記述されている。
SCブートストラップ情報には、SCSシグナリングデータを取得するためのIPアドレス、ポート番号、及び、TSIのほか、基本サービスフラグとハイブリッドフラグが指定されている。基本サービスフラグは、LSIDのみで、サービスを構成するコンポーネントを取得できるかどうかを示すフラグである。ハイブリッドフラグは、ブロードバンドサーバ３０から配信されるコンポーネントのストリームがあるかどうかを示すフラグである。
ここで、図４には、基本サービスフラグとハイブリッドフラグの組み合わせの例を示している。なお、SCDにおいて、SCブートストラップ情報は、SCBootstrap要素により指定される。また、図中の「@」は、属性を表しており、基本サービスフラグとハイブリッドフラグは、SCBootstrap要素のLSIDBaseService属性とhybrid属性により指定される。なお、SCBootstrap要素の詳細な内容は、図３０のSCDのシンタックスを参照して後述する。
図４において、基本サービスフラグとハイブリッドフラグには、１ビットのフラグとして、"TRUE"又は"FALSE"が指定される。すなわち、図４においては、基本サービスフラグとして"TRUE"が指定された場合、ハイブリッドフラグを利用することができない（図中の"N/A"）が、ハイブリッドフラグとして"FALSE"が指定されるようにしてもよい。また、基本サービスフラグとして"FALSE"が指定された場合、ハイブリッドフラグには、"FALSE"又は"TRUE"を指定することができる。
具体的には、基本サービスフラグとして"TRUE"が指定された場合、サービスを構成するコンポーネントのストリームは、単一のROUTEセッションにより伝送されることになる。また、サービスを構成するコンポーネントとSCSのストリームは、同一のROUTEセッションにより伝送される。そのため、IPアドレスとポート番号は、SCブートストラップ情報により解決し、ROUTEセッション内の情報は、LSIDにより解決することになる。
また、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"FALSE"が指定された場合、サービスを構成するコンポーネントのストリームは、単一又は複数のROUTEセッションにより伝送されることになる。
ここでは、単一のROUTEセッションで、複数のビデオ、複数のオーディオ、又は複数の字幕など、同一のMIMEタイプのストリームを伝送することが想定されている。あるいは、複数のROUTEセッションで、基本のビデオ及びオーディオと、ロバストオーディオが伝送されることが想定される。また、LSIDは、同一のMIMEタイプの区別がつかないため、複数のROUTEセッションを記述しないので、USBD（USD），MPD，SPDを用いることになる。なお、この場合、ハイブリッドフラグに、"FALSE"が指定されているため、サービスを構成するコンポーネントの中に、通信経由で取得されるコンポーネントが存在しないことになる。
また、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定された場合、サービスを構成するコンポーネントのストリームは、単一又は複数のROUTEセッション、あるいは通信経由で伝送されることになる。
ここでは、単一のROUTEセッションで、複数のビデオ、複数のオーディオ、又は複数の字幕など、同一のMIMEタイプのストリームを伝送することが想定されている。あるいは、複数のROUTEセッションで、基本のビデオ及びオーディオと、ロバストオーディオが伝送されることが想定される。また、この場合、ハイブリッドフラグに、"TRUE"が指定されているため、例えばセカンダリオーディオ等の通信経由で取得されるコンポーネントのストリームを用いることになる。なお、LSIDは、同一のMIMEタイプの区別がつかないため、USBD（USD），MPD，SPDを用いることになる。
なお、SCSブロードバンドロケーション情報には、SCSシグナリングデータの取得先を示すロケーション情報のほか、基本サービスフラグとハイブリッドフラグが指定されるが、これらのフラグの意味は、図４のSCブートストラップ情報に指定されるフラグと同様とされる。また、詳細については、図３０を参照して後述するが、SCDにおいて、SCSブロードバンドロケーション情報は、SignalingOverInternet要素により指定され、基本サービスフラグとハイブリッドフラグは、SignalingOverInternet要素のLSIDBaseService属性とhybrid属性により指定される。
このように、基本サービスフラグとハイブリッドフラグは、SCBootstrap要素とSignalingOverInternet要素に設定できる。そして、SCBootstrap要素で指定される基本サービスフラグとハイブリッドフラグは、SCBootstrap要素により指定される、放送ストリームに流れるSCSの属性を示している。また、SignalingOverInternet要素に指定される基本サービスフラグとハイブリッドフラグは、SignalingOverInternet要素により指定される、インターネット９０上のブロードバンドサーバ３０から取得されるSCSの属性を示している。なお、SCBootstrap要素とSignalingOverInternet要素において、LSIDBaseService属性とhybrid属性を合わせた１つの属性を定義して、その属性に、同様の機能を持たせるようにしてもよい。
図３の説明に戻り、EADは、緊急警報に関する緊急警報情報を含んでいる。RRDは、レーティングに関する情報を含んでいる。DCDは、SCSシグナリングデータに先行して取得される、最小限のサービスの選局を行うための情報である。USBDは、MPD，SDP等のSCSメタデータを参照するための参照情報を含んでいる。なお、USBDは、USDと称される場合がある。SDPは、サービス単位のサービス属性、ストリームの構成情報や属性、フィルタ情報、ロケーション情報などを含んでいる。
MPDは、サービス単位で伝送されるコンポーネントのストリームの再生を管理するための情報であって、セグメントURL（Uniform Resource Locator）などの情報を含んでいる。ISは、ROUTEセッションにおけるメディアセグメント（MS：Media Segment）に対するイニシャライゼーションセグメントである。
なお、USBD，USD，MPD，SPD，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は、サービスレベルのパラメータが定義される。
なお、SCD等のLLSメタデータと、USBDやLSID等のSCSメタデータは、例えば、XML（Extensible Markup Language）等のマークアップ言語により記述することができる。
＜２．運用例＞
（１）運用例１：放送基本サービス選局（固定受信機、ダイレクト選局）
運用例１は、固定受信機としての受信装置２０Ａ（図１）において、サービスを構成するコンポーネントが放送のみで提供されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
（システムパイプモデル）
図５は、運用例１のシステムパイプモデルを示す図である。
図５において、所定の周波数帯域からなる放送波に対応した物理チャンネル（RF Channel）においては、１つのBBP（Base Band Packet）ストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル（Service Channel）、ESGサービス、及び、NTP（Network Time Protocol）のストリームが伝送されている。
LLSは、サービスに依存しない低レイヤのLLSシグナリングデータを伝送する。LLSシグナリングデータには、例えば、SCD等のLLSメタデータが含まれる。
サービスチャンネル（以下、「サービス」ともいう）は、SCSと、ビデオやオーディオ、字幕等のコンポーネント（Component）から構成される。なお、各サービス（例えば番組）を構成する要素には、共通のIPアドレスが付与されており、このIPアドレスを用いて、サービスごとに、コンポーネントやSCSシグナリングデータなどをパッケージ化することができる。
SCSは、サービス単位のSCSシグナリングデータを伝送する。SCSシグナリングデータには、例えば、USBDやLSID等のSCSメタデータが含まれる。なお、サービスは、UDP/IP（User Datagram Protocol/Internet Protocol）のプロトコルに従って伝送される。ESGサービス（以下、「ESG」ともいう）は、電子サービスガイド（電子番組表）である。NTPは、時刻情報である。
なお、所定の周波数帯域を有する放送波（RF Channel）には、例えば放送事業者ごとに、RFアロケーションID（RF Allocation 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体系では、RFアロケーションIDとBBPストリームIDが、MPEG2-TS方式におけるネットワークIDとトランスポートストリームIDに対応している。
以上のような構成からなる放送波が、送信装置１０から送信され、固定受信機である受信装置２０Ａにより受信される。受信装置２０Ａにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される（Ｓ１１）。なお、SCDには、物理パラメータとしての周波数やトリプレットのほか、SCSシグナリングデータを取得するためのSCブートストラップ情報が記述されている。
また、受信装置２０Ａにおいて、ユーザによりサービスが選局（ダイレクト選局）された場合には、当該サービスのSCブートストラップ情報に従い、SCSシグナリングデータが取得される（Ｓ１２）。
ここで、SCDのSCブートストラップ情報には、基本サービスフラグ（LSIDBaseService）として"TRUE"が指定され、かつハイブリッドフラグ（hybrid）として"FALSE"が指定されているので、受信装置２０Ａは、LSIDのみを参照すれば、ダイレクト選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる（Ｓ１３）。
したがって、受信装置２０Ａは、LSIDを参照して、MIMEタイプに対応したビデオとオーディオのTSIとTOIを用い、ダイレクト選局されたサービスを構成するビデオとオーディオのストリームに接続することができる（Ｓ１４）。なお、ここでは、ハイブリッドフラグ（hybrid）として"FALSE"が指定されているので、サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在しないことになる。
なお、図５においては、放送経由で伝送されるSCSシグナリングデータとして、LSIDを図示して、LSIDのみを参照して、ビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD（図中の点線で示している）やその他のSCSメタデータが参照されるようにしてもよい。また、LSIDに字幕の情報を追加することで、ビデオやオーディオだけでなく、字幕のストリームに接続されるようにしてもよい。
また、図５においては、LSIDを、他のSCSメタデータとともに、同一のROUTEセッションで伝送する場合を例示しているが、LSIDは、他のSCSメタデータと異なるROUTEセッションで伝送するようにしてもよい。なお、ROUTEセッションにおいて、LSIDのTSIの値は、"0"とされる。
（シーケンス図）
次に、図６を参照して、運用例１を採用した場合の受信装置２０Ａにおける具体的な処理の流れを説明する。なお、図６において、図中の上側は、送信装置１０から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置２０Ａにおける処理の流れを表している。また、図６において、時間の方向は、図中の左側から右側の方向とされる。
図６において、放送局に設置された送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、サービス（例えば番組）を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム（BBP Stream）により伝送されている。ただし、サービスを構成するコンポーネント及びSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
図６に示すように、各家庭等に設置された固定受信機としての受信装置２０Ａにおいては、初期スキャン処理等によって、LLSストリームで伝送されているSCDが取得され、NVRAM（Non Volatile RAM）に記録される（Ｓ２１）。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCSシグナリングデータを取得するためのIPアドレス、ポート番号、及び、TSIが指定されたSCブートストラップ情報が記述されている。
また、サービスIDで識別されるサービスごとのSCブートストラップ情報には、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"TRUE"が指定され、かつハイブリッドフラグには、"FALSE"が指定されているので、LSIDに記述された内容のみでコンポーネントの取得先を特定することができ、さらに、コンポーネントが通信経由では配信されていないことを表している。すなわち、この場合、対象のサービスを構成するコンポーネントのストリームは、単一のROUTEセッションで伝送されていることになる。
受信装置２０Ａは、例えばユーザによりサービス（例えば番組）の選局操作（ダイレクト選局）が行われた場合、NVRAMからSCD（選局情報）を読み出して、当該サービスのSCブートストラップ情報に従い、送信装置１０からの放送波で伝送されているSCSストリームに接続する（Ｓ２２）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる（Ｓ２３）。
ここでは、SCDの基本サービスフラグによって、LSIDに記述された内容のみでコンポーネントの取得先を特定できることがわかっているので、SCSシグナリングデータとして、LSIDのみを取得すればよいことになる。ただし、受信装置２０Ａは、必要に応じてSPD等の他のSCSメタデータを取得するようにしてもよい。なお、SCSシグナリングデータは、ROUTEセッションで伝送されているので、LCTヘッダが付加されたLCTパケットに格納されたデータを解析することで、LSID（のファイル）が取得される。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するビデオとオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置２０Ａは、これらのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオとオーディオのストリームに接続する（Ｓ２４）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているビデオデータとオーディオデータを取得することができる（Ｓ２５）。
なお、ビデオデータとオーディオデータは、ROUTEセッションで伝送されているので、LCTヘッダが付加されたLCTパケットに格納されたセグメントデータ（メディアセグメント）を抽出することで、それらのデータが取得されることになる。
そして、受信装置２０Ａでは、放送経由で取得されたビデオデータとオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ダイレクト選局されたサービスに対応した番組の映像と音声が再生される。なお、映像と音声の同期再生には、LCTヘッダの拡張領域によって伝送されるNTPのタイムスタンプを用いることができる。また、LCTヘッダの拡張領域に、NTPタイムスタンプが伝送されていない場合には、別の手段として、SCSストリームで伝送されているMPDを取得して、MPDの基準時刻と、DASHセグメントのmoofボックスに格納されるピクチャ単位のデコード時刻と、表示時刻情報から、デコード時刻及び表示時刻を算出するようにすればよい。
以上のように、運用例１では、固定受信機としての受信装置２０Ａにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報には、基本サービスフラグとして"TRUE"が指定され、かつハイブリッドフラグとして"FALSE"が指定されているため、ダイレクト選局されたサービスを構成するコンポーネントのストリームは、単一のROUTEセッションで伝送されていることになる。また、LSIDのみを参照すれば、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
すなわち、受信装置２０Ａは、全てのSCSメタデータを参照することなく、LSIDのみを用いて、所望のコンポーネントを取得することができるので、サービスを構成するコンポーネントがROUTEセッションで伝送されている場合に、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。
（２）運用例２−１：ハイブリッドサービス選局１（固定受信機、ダイレクト選局）
運用例２−１は、固定受信機としての受信装置２０Ａ（図１）において、サービスを構成するコンポーネントが放送と通信のハイブリッドで提供されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
（システムパイプモデル）
図７は、運用例２−１のシステムパイプモデルを示す図である。
図７の運用例２−１においては、図５の運用例１と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル（RF Channel）において、１つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル（サービス）、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、プライマリビデオ（Primary Video）及びプライマリオーディオ（Primary Audio）のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置１０から送信され、固定受信機である受信装置２０Ａにより受信される。
また、運用例２−１においては、ブロードバンドサーバ３０により、インターネット９０を介してセカンダリオーディオ（Secondary Audio）がストリーミング配信されている。受信装置２０Ａは、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、セカンダリオーディオデータを取得することができる。
すなわち、受信装置２０Ａにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される（Ｓ３１）。なお、SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が記述されている。
ここで、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、受信装置２０Ａは、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできない。また、当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在することになる。
受信装置２０Ａにおいて、ユーザによりサービスが選局（ダイレクト選局）された場合には、当該サービスのSCブートストラップ情報に従い、SCSストリームに接続されることで、USBD，MPD，SDP等のSCSメタデータが取得される（Ｓ３２）。
また、受信装置２０Ａは、ステップＳ３２の処理で取得されたUSBDを参照して、MPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、ダイレクト選局されたサービスを構成するセカンダリオーディオのストリームに接続することができる（Ｓ３３，Ｓ３４）。
また、受信装置２０Ａは、USBDを参照して、SDPに従い、放送波で伝送されているSCSストリームに接続することで、LSIDを取得する（Ｓ３５，Ｓ３６）。そして、受信装置２０Ａは、ステップＳ３６の処理で取得されたLSIDを参照して、MIMEタイプに対応したプライマリビデオとプライマリオーディオのTSIとTOIを用い、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続することができる（Ｓ３７）。
なお、図７においては、放送経由で伝送されるSCSシグナリングデータとして、LSID，USBD，MPD，SDPを図示して、それらのSCSメタデータを参照して、放送と通信経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD（図中の点線で示している）やその他のSCSメタデータが参照されるようにしてもよい。
（シーケンス図）
次に、図８を参照して、運用例２−１を採用した場合の受信装置２０Ａにおける具体的な処理の流れを説明する。なお、図８において、図中の上側は、送信装置１０とブロードバンドサーバ３０から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置２０Ａにおける処理の流れを表している。また、図８において、時間の方向は、図中の左側から右側の方向とされる。
図８において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、サービス（例えば番組）を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム（BBP Stream）により伝送されている。ただし、サービスを構成するコンポーネントとしてのプライマリビデオデータ及びプライマリオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
また、図８において、ブロードバンドサーバ３０は、インターネット９０を介してセカンダリオーディオデータをストリーミング配信している。
図８に示すように、固定受信機としての受信装置２０Ａにおいては、初期スキャン処理等によって、LLSストリームで伝送されているSCDが取得され、NVRAMに記録される（Ｓ４１）。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が、サービスごとに記述されている。
SCブートストラップ情報には、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"TRUE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの一部が通信経由でも配信されていることを表している。すなわち、この場合、対象のサービスを構成するコンポーネントは、単一のROUTEセッションで伝送されているが、コンポーネント（オーディオ）の一部は、通信経由で配信されていることになる。
受信装置２０Ａは、例えばユーザによりサービスの選局操作（ダイレクト選局）が行われた場合、NVRAMからSCDを読み出して、当該サービスのSCブートストラップ情報に従い、送信装置１０からの放送波で伝送されているSCSストリームに接続する（Ｓ４２）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる（Ｓ４３）。
なお、SCSシグナリングデータは、ROUTEセッションで伝送されているので、LCTパケットに格納されたデータを解析することで、USBD，MPD，SDP等のSCSメタデータ（のファイル）が取得される。例えば、USBDにはSCSメタデータの参照情報が記述されているので、この参照情報を用い、MPDやSDP等のSCSメタデータを取得することになるが、それらのSCSメタデータは、同一のSCSストリームで伝送されるので、そこから一括して取得するようにしてもよい。
受信装置２０Ａは、ステップＳ４３の処理で取得されたMPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット９０を介してブロードバンドサーバ３０にアクセスする（Ｓ４４）。これにより、受信装置２０Ａは、ブロードバンドサーバ３０からストリーミング配信される、ダイレクト選局されたサービスを構成するセカンダリオーディオデータを取得することができる（Ｓ４５）。
また、受信装置２０Ａは、ステップＳ４３の処理で取得されたSDPに従い、送信装置１０からの放送波で伝送されているSCSストリームに接続する（Ｓ４６）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているLSIDやSPDを取得することができる（Ｓ４７）。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。ただし、ここでは、プライマリオーディオ（例えば第１言語）の代わりに、セカンダリオーディオ（例えば第２言語）が再生されるので、プライマリビデオのコンポーネントに関する情報のみが用いられる。
受信装置２０Ａは、プライマリビデオのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているプライマリビデオのストリームに接続する（Ｓ４８）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているプライマリビデオデータを取得することができる（Ｓ４９）。
そして、受信装置２０Ａは、放送経由で取得されたプライマリビデオデータと、通信経由で取得されたセカンダリオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ダイレクト選局されたサービスに対応した番組の映像と音声が再生される。
なお、ここでは、通信経由で取得されたセカンダリオーディオ（例えば第２言語）が再生される例を説明したが、例えば、ユーザにより所定の操作された場合や、受信装置２０Ａが通信機能を有していない場合などに、放送経由で取得されるプライマリオーディオ（例えば第１言語）が再生されるようにしてもよい。
以上のように、運用例２−１では、固定受信機としての受信装置２０Ａにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、対象のサービスを構成するコンポーネントは、単一又は複数のROUTEセッションで伝送されるとともに、コンポーネント（オーディオ）の一部は、通信経由で配信されていることになる。また、LSIDのほか、MPD等の他のSCSメタデータを参照することで、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
例えば、受信装置２０Ａは、SCブートストラップ情報の基本サービスフラグとハイブリッドフラグを参照することで、サービスを構成するコンポーネントがROUTEセッションでのみ伝送されているかどうかや、LSIDのみでロケーションを解決できるかどうかなどを、SCSシグナリングデータを取得するよりも先に認識することができるので、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。
（３）運用例２−２：ハイブリッドサービス選局２（固定受信機、ダイレクト選局）
運用例２−２は、固定受信機としての受信装置２０Ａ（図１）において、サービスを構成するコンポーネントが放送と通信のハイブリッドで提供されている場合に、当該サービスがダイレクト選局されたときの他の運用例を表している。
（システムパイプモデル）
図９は、運用例２−２のシステムパイプモデルを示す図である。
図９の運用例２−２においては、図５の運用例１と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル（RF Channel）において、１つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル（サービス）、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、プライマリビデオ（Primary Video）及びプライマリオーディオ（Primary Audio）のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置１０から送信され、固定受信機である受信装置２０Ａにより受信される。
また、運用例２−２においては、運用例２−１と同様に、ブロードバンドサーバ３０によって、インターネット９０を介してセカンダリオーディオ（Secondary Audio）がストリーミング配信されるとともに、SCSシグナリングデータが配信されている。受信装置２０Ａは、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、セカンダリオーディオデータやSCSシグナリングデータを取得することができる。
すなわち、受信装置２０Ａにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される（Ｓ５１）。なお、SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報と、SCSブロードバンドロケーション情報が記述されている。
ここで、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできず、さらに当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在することになる。
また、SCDのSCSブロードバンドロケーション情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできず、さらに当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在することになる。
受信装置２０Ａにおいて、ユーザによりサービスが選局（ダイレクト選局）された場合には、当該サービスのSCSブロードバンドロケーション情報に指定されるURI（Uniform Resource Identifier）に従い、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、USBD，MPD，SDP等のSCSメタデータが取得される（Ｓ５２，Ｓ５３）。
そして、受信装置２０Ａは、ステップＳ５３の処理で取得されたUSBDを参照して、MPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、ダイレクト選局されたサービスを構成するセカンダリオーディオのストリームに接続することができる（Ｓ５４）。
また、受信装置２０Ａは、USBDを参照して、SDPに従い、放送波で伝送されているSCSストリームに接続することで、LSIDを取得する（Ｓ５５，Ｓ５６）。そして、受信装置２０Ａは、ステップＳ５６の処理で取得されたLSIDを参照して、MIMEタイプに対応したプライマリビデオとプライマリオーディオのTSIとTOIを用い、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続することができる（Ｓ５７）。
なお、図９においては、放送又は通信経由で伝送されるSCSシグナリングデータとして、LSID，USBD，MPD，SDPを図示して、それらのSCSメタデータを参照して、放送と通信経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD（図中の点線で示している）やその他のSCSメタデータが参照されるようにしてもよい。
（シーケンス図）
次に、図１０を参照して、運用例２−２を採用した場合の受信装置２０Ａにおける具体的な処理の流れを説明する。なお、図１０において、図中の上側は、送信装置１０とブロードバンドサーバ３０から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置２０Ａにおける処理の流れを表している。また、図１０において、時間の方向は、図中の左側から右側の方向とされる。
図１０において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、サービス（例えば番組）を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム（BBP Stream）により伝送されている。ただし、サービスを構成するコンポーネントとしてのプライマリビデオデータ及びプライマリオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
また、図１０において、ブロードバンドサーバ３０は、インターネット９０を介してセカンダリオーディオデータ及びSCSシグナリングデータを配信している。
図１０に示すように、固定受信機としての受信装置２０Ａにおいては、初期スキャン処理等によって、LLSストリームで伝送されているSCDが取得され、NVRAMに記録される（Ｓ６１）。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報と、SCSブロードバンドロケーション情報が、サービスごとに記述されている。
SCブートストラップ情報には、IPアドレスやポート番号等のほかに、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"TRUE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの一部が通信経由でも配信されていることを表している。すなわち、この場合、対象のサービスを構成するコンポーネントは、単一のROUTEセッションで伝送されているが、コンポーネント（オーディオ）の一部は、通信経由で配信されていることになる。
また、SCSブロードバンドロケーション情報には、SCSシグナリングデータの取得先を示すURIのほかに、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"TRUE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの一部が通信経由でも配信されていることを表している。
受信装置２０Ａは、例えばユーザによりサービスの選局操作（ダイレクト選局）が行われた場合、NVRAMからSCDを読み出して、当該サービスのSCSブロードバンドロケーション情報のURIに従い、インターネット９０を介してブロードバンドサーバ３０にアクセスする（Ｓ６２）。これにより、受信装置２０Ａは、通信経由でSCSシグナリングデータを取得することができる（Ｓ６３）。ここでは、SCSシグナリングデータとして、USBD，MPD，SDP等のSCSメタデータ（のファイル）が取得される。
そして、受信装置２０Ａは、ステップＳ６３の処理で取得されたMPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット９０を介してブロードバンドサーバ３０にアクセスする（Ｓ６４）。これにより、受信装置２０Ａは、ブロードバンドサーバ３０からストリーミング配信される、ダイレクト選局されたサービスを構成するセカンダリオーディオデータを取得することができる（Ｓ６５）。
また、受信装置２０Ａは、ステップＳ６３の処理で取得されたSDPに従い、送信装置１０からの放送波で伝送されているSCSストリームに接続する（Ｓ６６）。これにより、受信装置２０Ａでは、ROUTEセッションで伝送されているLSIDやSPDを取得することができる（Ｓ６７）。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。ただし、ここでは、プライマリオーディオ（例えば第１言語）の代わりに、セカンダリオーディオ（例えば第２言語）が再生されるので、プライマリビデオのコンポーネントに関する情報のみが用いられる。
受信装置２０Ａは、プライマリビデオのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているプライマリビデオのストリームに接続する（Ｓ６８）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているプライマリビデオデータを取得することができる（Ｓ６９）。
そして、受信装置２０Ａは、放送経由で取得されたプライマリビデオデータと、通信経由で取得されたセカンダリオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、選局されたサービスに対応した番組の映像と音声が再生される。
以上のように、運用例２−２では、固定受信機としての受信装置２０Ａにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報又はSCSブロードバンドロケーション情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、対象のサービスを構成するコンポーネントは、単一又は複数のROUTEセッションで伝送されるとともに、コンポーネント（オーディオ）の一部は、通信経由で配信されていることになる。また、LSIDのほか、MPD等の他のSCSメタデータを参照することで、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
例えば、受信装置２０Ａは、SCブートストラップ情報又はSCSブロードバンドロケーション情報の基本サービスフラグとハイブリッドフラグを参照することで、サービスを構成するコンポーネントがROUTEセッションでのみ伝送されているかどうかや、LSIDのみでロケーションを解決できるかどうかなどを、SCSシグナリングデータを取得するよりも先に認識することができるので、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。また、運用例２−２では、SCSシグナリングデータが、放送経由のみならず、通信経由でも取得されるので、放送波で伝送されるSCSシグナリングデータのデータ量を少なくして、その利用帯域を少なくすることができる。
なお、運用例２−２の変形例として、SCブートストラップ情報において、基本サービスフラグに"TRUE"、ハイブリッドフラグに"FALSE"がそれぞれ指定され、SCSブロードバンドロケーション情報において、ハイブリッドフラグに"TRUE"が指定されるようにすることで、放送経由で伝送されるSCSシグナリングデータとして、放送経由で伝送されるプライマリビデオデータとプライマリオーディオデータのみを受信するためのSCSシグナリングデータが伝送されていることを示すようにすることができる。また、この場合、SCSブロードバンドロケーション情報のハイブリッドフラグが"TRUE"であることから、通信経由で伝送されているSCSシグナリングデータとして、放送経由で伝送されるプライマリビデオデータとプライマリオーディオデータ、及び、通信経由で伝送されるセカンダリオーディオデータを受信するためのSCSシグナリングデータが伝送されていることを示すことになる。
（４）運用例３：放送基本サービス選局（モバイル受信機、ESG選局）
運用例３は、モバイル受信機としての受信装置２０Ｂ（図２）において、サービスを構成するコンポーネントが放送（と通信）で提供されている場合に、当該サービスがESG選局されたときの運用例を表している。
（システムパイプモデル）
図１１は、運用例３のシステムパイプモデルを示す図である。
図１１の運用例３においては、図５の運用例１と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル（RF Channel）において、１つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル（サービス）、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、プライマリビデオ（Primary Video）及びプライマリオーディオ（Primary Audio）のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置１０から送信され、モバイル受信機である受信装置２０Ｂにより受信される。
また、運用例３においては、ブロードバンドサーバ３０によって、インターネット９０を介してSCSシグナリングデータとESGデータが配信されている。受信装置２０Ｂは、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、SCSシグナリングデータやESGデータを取得することができる。
すなわち、受信装置２０Ｂにおいては、ユーザにより所定の操作（例えば電子番組表の取得指示）が行われた場合、あらかじめ取得済みのESGデータの取得先のURLに従い、ブロードバンドサーバ３０にアクセスすることで、ESGデータが取得される（Ｓ７１）。また、受信装置２０Ｂにおいて、ユーザが、ESGデータに対応した電子番組表を利用して、サービスの選局（ESG選局）を行った場合、ESGデータに基づいて、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、USBD，MPD，SDP等のSCSメタデータが取得される（Ｓ７２，Ｓ７３）。
そして、受信装置２０Ｂは、ステップＳ７３の処理で取得されたUSBDを参照して、SDPに従い、放送波で伝送されているSCSストリームに接続することで、LSIDを取得する（Ｓ７４，Ｓ７５）。そして、受信装置２０Ｂは、ステップＳ７５の処理で取得されたLSIDを参照して、MIMEタイプに対応したプライマリビデオとプライマリオーディオのTSIとTOIを用い、ESG選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続することができる（Ｓ７６）。
なお、図１１においては、放送又は通信経由で伝送されるSCSシグナリングデータとして、LSID，USBD，MPD，SDPを図示して、それらのSCSメタデータを参照して、放送経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD（図中の点線で示している）やその他のSCSメタデータが参照されるようにしてもよい。
また、図１１において、受信装置２０Ｂでは、ESGデータに対応した電子番組表を利用して、サービスの選局（ESG選局）が行われたが、ブロードバンドサーバ３０から配信されるサービス視聴用のアプリケーションを介してESGデータを取得して、サービスの選局が行われるようにしてもよい。さらに、図１１においては、放送波で伝送されるプライマリビデオとプライマリオーディオのストリームに接続される場合を例示したが、USBDから参照されるMPDを用いることで、ブロードバンドサーバ３０から配信されるセカンダリオーディオのストリームに接続されるようにしてもよい。
（シーケンス図）
次に、図１２を参照して、運用例３を採用した場合の受信装置２０Ｂにおける具体的な処理の流れを説明する。なお、図１２において、図中の上側は、送信装置１０とブロードバンドサーバ３０から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置２０Ｂにおける処理の流れを表している。また、図１２において、時間の方向は、図中の左側から右側の方向とされる。
図１２において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、サービス（例えば番組）を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム（BBP Stream）により伝送されている。ただし、サービスを構成するコンポーネントとしてのプライマリビデオデータ及びプライマリオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
また、図１２において、ブロードバンドサーバ３０は、インターネット９０を介して、ESGデータとSCSシグナリングデータを配信している。なお、ブロードバンドサーバ３０は、セカンダリオーディオデータを配信するようにしてもよい。
図１２に示すように、モバイル受信機としての受信装置２０Ｂにおいては、アプリケーション（APP）が起動されており、例えば当該アプリケーションにて電子番組表を表示する場合には、インターネット９０を介してブロードバンドサーバ３０にアクセスし、ESGデータを取得する（Ｓ８１）。これにより、受信装置２０Ｂにおいては、アプリケーションによって、通信経由で取得されたESGデータに応じた電子番組表が表示される。
ここで、例えばユーザにより電子番組表に基づいたサービスの選局操作（ESG選局）が行われた場合、受信装置２０Ｂは、ESGデータに基づいて、インターネット９０を介してブロードバンドサーバ３０にアクセスする（Ｓ８２）。これにより、受信装置２０Ｂは、通信経由でSCSシグナリングデータを取得することができる（Ｓ８３）。ここでは、ESGデータを用いることで、USBD，MPD，SDP等のSCSメタデータを取得することになる。
また、受信装置２０Ｂは、ステップＳ８３の処理で取得されたSDPに従い、送信装置１０からの放送波で伝送されているSCSストリームに接続する（Ｓ８４）。これにより、受信装置２０Ｂでは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる（Ｓ８５）。ここでは、SCSシグナリングデータとして、LSIDやSPD等のSCSメタデータが取得される。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ESG選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置２０Ｂは、これらのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているプライマリビデオとプライマリオーディオのストリームに接続する（Ｓ８６）。これにより、受信装置２０Ｂは、ROUTEセッションで伝送されているプライマリビデオデータとプライマリオーディオデータを取得することができる（Ｓ８７）。
そして、受信装置２０Ｂでは、放送経由で取得されたプライマリビデオデータとセカンダリオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ESG選局されたサービスに対応した番組の映像と音声が再生される。なお、映像と音声の同期再生には、LCTヘッダの拡張領域によって伝送されるNTPのタイムスタンプを用いることができる。また、LCTヘッダの拡張領域に、NTPタイムスタンプが伝送されていない場合には、別の手段として、SCSストリームで伝送されているMPDを取得して、MPDの基準時刻と、DASHセグメントのmoofボックスに格納されるピクチャ単位のデコード時刻と、表示時刻情報から、デコード時刻及び表示時刻を算出するようにすればよい。
なお、図１２の例では、プライマリビデオデータとセカンダリオーディオデータが両方とも放送経由で取得される場合を説明したが、プライマリオーディオの代わりに、セカンダリオーディオを通信経由で取得する場合には、ステップＳ８３の処理で取得されたMPDのセグメントURLに従い、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、セカンダリオーディオデータを取得することができる。
以上のように、運用例３では、モバイル受信機としての受信装置２０Ｂにおいて、サービスがESG選局された場合について説明した。
（５）運用例４：放送基本サービス選局（固定受信機、ESG選局）
運用例４は、固定受信機としての受信装置２０Ａ（図１）において、サービスを構成するコンポーネントが放送のみで提供されている場合に、当該サービスがESG選局されたときの運用例を表している。
（システムパイプモデル）
図１３は、運用例４のシステムパイプモデルを示す図である。
図１３の運用例４においては、図５の運用例１と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル（RF Channel）において、１つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル（サービス）、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、ビデオ、オーディオ、及び、字幕のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置１０から送信され、固定受信機である受信装置２０Ａにより受信される。
すなわち、受信装置２０Ａにおいては、ユーザにより所定の操作が行われた場合、NVRAMから読み出されるSCDのESGブートストラップ情報に従い、ESGストリームで伝送されているESGデータが取得される（Ｓ９１）。
受信装置２０Ａにおいて、ユーザがESGデータに対応した電子番組表を利用して、サービスの選局（ESG選局）を行った場合、ESG選局されたサービスに応じて、SCSストリームからUSBDが取得される（Ｓ９２）。なお、ESG選局されたサービスは、SCDのグローバルユニークサービスID（GUSI）によって、USBDと紐付けられている。また、USBDの参照情報により、MPDやSDP等のSCSメタデータが取得される。
また、受信装置２０Ａは、USBDを参照して、SDPに従い、SCSストリームに接続することで、LSIDを取得する（Ｓ９３，Ｓ９４）。そして、受信装置２０Ａは、ステップＳ９４の処理で取得されたLSIDを参照して、MIMEタイプに対応したビデオとオーディオのTSIとTOIを用い、ESG選局されたサービスを構成するビデオとオーディオのストリームに接続することができる（Ｓ９５）。
なお、図１３においては、放送経由で伝送されるSCSシグナリングデータとして、LSID，USBD，MPD，SDPを図示して、それらのSCSメタデータを参照して、放送経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD（図中の点線で示している）やその他のSCSメタデータが参照されるようにしてもよい。
（シーケンス図）
次に、図１４を参照して、運用例４を採用した場合の受信装置２０Ａの具体的な処理の流れを説明する。なお、図１４において、図中の上側は、送信装置１０から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置２０Ａにおける処理の流れを表している。また、図１４において、時間の方向は、図中の左側から右側の方向とされる。
図１４において、放送局の送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、サービス（例えば番組）を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム（BBP Stream）により伝送されている。ただし、サービスを構成するコンポーネントとしてのビデオデータ及びオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
図１４に示すように、固定受信機としての受信装置２０Ａにおいては、初期スキャン処理等によって、LLSで伝送されているSCDが取得され、NVRAMに記録されている。SCDには、物理パラメータとしての周波数やトリプレットのほか、ESGブートストラップ情報が記述されている。
受信装置２０Ａは、例えばユーザにより電子番組表の表示が指示された場合、NVRAMから読み出されるSCDのESGブートストラップ情報に従い、送信装置１０からの放送波で伝送されているESGストリームに接続する（Ｓ１０１）。これにより、受信装置２０Ａは、ESGストリームで伝送されているESGデータを取得することができる（Ｓ１０２）。
例えばユーザにより電子番組表に基づいたサービスの選局操作（ESG選局）が行われた場合、受信装置２０Ａは、ESG選局されたサービスに応じたSCSストリームに接続する（Ｓ１０３）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる（Ｓ１０４）。ここで、ESG選局されたサービスと、USBDは、SCDのグローバルユニークサービスIDにより紐付けられているが、USBDにはSCSメタデータの参照情報が記述されているので、この参照情報を用いて、MPDやSDP等のSCSメタデータを取得することになる。
また、受信装置２０Ａは、ステップＳ１０４の処理で取得されたSDPに従い、送信装置１０からの放送波で伝送されているSCSストリームに接続する（Ｓ１０５）。これにより、受信装置２０Ａでは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる（Ｓ１０６）。ここでは、SCSシグナリングデータとして、LSIDやSPD等のSCSメタデータが取得される。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ESG選局されたサービスを構成するビデオとオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置２０Ａは、これらのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオとオーディオのストリームに接続する（Ｓ１０７）。これにより、受信装置２０Ａは、ROUTEセッションで伝送されているビデオデータとオーディオデータを取得することができる（Ｓ１０８）。
そして、受信装置２０Ａは、放送経由で取得されたビデオデータとオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ESG選局されたサービスに対応した番組の映像と音声が再生される。なお、映像と音声の同期再生には、LCTヘッダの拡張領域によって伝送されるNTPのタイムスタンプを用いることができる。また、LCTヘッダの拡張領域に、NTPタイムスタンプが伝送されていない場合には、別の手段として、SCSストリームで伝送されているMPDを取得して、MPDの基準時刻と、DASHセグメントのmoofボックスに格納されるピクチャ単位のデコード時刻と、表示時刻情報から、デコード時刻及び表示時刻を算出するようにすればよい。
以上のように、運用例４では、固定受信機としての受信装置２０Ａにおいて、サービスがESG選局された場合について説明した。
（６）運用例５−１：ロバストサービス選局１（固定受信機、ダイレクト選局）
運用例５−１は、固定受信機としての受信装置２０Ａ（図１）において、サービスを構成するコンポーネントが複数のROUTEセッションで伝送されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
（システムパイプモデル）
図１５は、運用例５−１のシステムパイプモデルを示す図である。
図１５の運用例５−１の放送波の構成は、図５の運用例１の放送波と同様の構成からなるが、所定の周波数帯域からなる放送波に対応した物理チャンネル（RF Channel）において、２つのBBPストリームが伝送されている。
ここでは、一方のBBPストリーム（BBPストリームID="y"）では、LLS、サービスチャンネル（サービス）、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、ビデオ及びオーディオのコンポーネントから構成される。他方のBBPストリーム（BBPストリームID="ro"）では、LSIDと、２つのロバストオーディオ（Robust Audio1，Robust Audio2）のストリームが伝送されている。
このように、運用例５−１では、基本のビデオとオーディオのストリームほかに、品質は落ちるが高ロバストネスなロバストオーディオのストリームが伝送されている。また、ロバストオーディオとしては、強度のレベルの異なるロバストオーディオ１とロバストオーディオ２の２つのストリームが伝送されている。
以上のような構成からなる放送波が、送信装置１０から送信され、固定受信機である受信装置２０Ａにより受信される。
すなわち、受信装置２０Ａにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される（Ｓ１１１）。ここで、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"FALSE"が指定されているので、受信装置２０Ａは、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできない。また、当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在しないことになる。
受信装置２０Ａにおいて、ユーザによりサービスが選局（ダイレクト選局）された場合には、当該サービスのSCブートストラップ情報に従い、一方のBBPストリーム（BBPストリームID="y"）で伝送されるSCSストリームに接続されることで、USBD，MPD，SDP等のSCSメタデータが取得される（Ｓ１１２，Ｓ１１３）。
また、受信装置２０Ａは、USBDを参照して、SDPに従い、他方のBBPストリーム（BBPストリームID="ro"）で伝送されているSCSストリームに接続することで、LSIDを取得する（Ｓ１１４，Ｓ１１５）。そして、受信装置２０Ａは、ステップＳ１１５の処理で取得されたLSIDを参照して、MIMEタイプに対応したロバストオーディオ１とロバストオーディオ２のTSIとTOIを用い、ダイレクト選局されたサービスを構成するロバストオーディオ１又はロバストオーディオ２のストリームに接続することができる（Ｓ１１６）。例えば、視聴環境が悪い場合において、基本のビデオとオーディオが視聴できないときには、ロバストオーディオの音声のみを再生するといった運用を行うことができる。
なお、図１５においては、放送経由で伝送されるSCSシグナリングデータとして、LSID，USBD，MPD，SDPを図示して、それらのSCSメタデータを参照して、放送経由で伝送されるロバストオーディオのストリームに接続する場合を説明したが、必要に応じてSPDやLSID（図中の点線で示している）、その他のSCSメタデータが参照されるようにしてもよい。
（シーケンス図）
次に、図１６を参照して、運用例５−１を採用した場合の受信装置２０Ａにおける具体的な処理の流れを説明する。なお、図１６において、図中の上側は、送信装置１０から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置２０Ａにおける処理の流れを表している。また、図１６において、時間の方向は、図中の左側から右側の方向とされる。
図１６において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、一方のBBPストリーム（以下、「BBPストリーム１」という）で、サービス（例えば番組）を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが伝送されている。また、他方のBBPストリーム（以下、「BBPストリーム２」という）で、ロバストオーディオと、LSIDのストリームが伝送されている。
ただし、BBPストリーム１において、ビデオ、オーディオ、及び、SCSシグナリングデータのストリームを伝送するROUTEセッションと、BBPストリーム２において、２つのロバストオーディオ、及び、LSIDを伝送するROUTEセッションとは、異なるROUTEセッションとされる。ここでは、前者を、「ROUTEセッション１」と称し、後者を、「ROUTEセッション２」と称して区別するようにする。
図１６に示すように、固定受信機としての受信装置２０Ａにおいては、初期スキャン処理等によって、BBPストリーム１のLLSストリームで伝送されているSCDが取得され、NVRAMに記録される（Ｓ１２１）。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が、サービスごとに記述されている。
SCブートストラップ情報には、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"FALSE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの全てが放送経由で配信されていることを表している。
受信装置２０Ａは、例えばユーザによりサービスの選局操作（ダイレクト選局）が行われた場合、NVRAMからSCDを読み出して、当該サービスのSCブートストラップ情報に従い、送信装置１０からの放送波で伝送されているBBPストリーム１のSCSストリームに接続する（Ｓ１２２）。これにより、受信装置２０Ａは、ROUTEセッション１で伝送されているSCSシグナリングデータを取得することができる（Ｓ１２３）。ここでは、USBDにはSCSメタデータの参照情報が記述されているので、この参照情報を用いてMPDやSDPが取得される。
また、受信装置２０Ａは、ステップＳ１２３の処理で取得されたSDPに従い、送信装置１０からの放送波で伝送されているBBPストリーム２のLSIDストリームに接続する（Ｓ１２４）。これにより、受信装置２０Ａでは、ROUTEセッション２で伝送されているLSIDを取得することができる（Ｓ１２５）。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するビデオとロバストオーディオ１のストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置２０Ａは、ビデオのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッション１で伝送されているビデオのストリームに接続する（Ｓ１２６）。これにより、受信装置２０Ａは、ROUTEセッション１で伝送されているビデオデータを取得することができる（Ｓ１２７）。
また、受信装置２０Ａは、ロバストオーディオ１のIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッション２で伝送されているロバストオーディオ１のストリームに接続する（Ｓ１２８）。これにより、受信装置２０Ａは、ROUTEセッション２で伝送されているロバストオーディオデータを取得することができる（Ｓ１２９）。
そして、受信装置２０Ａは、ROUTEセッション１から取得されたビデオデータと、ROUTEセッション２から取得されたロバストオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、選局されたサービスに対応した番組の映像と音声が再生される。
以上のように、運用例５−１では、固定受信機としての受信装置２０Ａにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"FALSE"が指定されているので、対象のサービスを構成するコンポーネントは、単一又は複数のROUTEセッションで伝送され、コンポーネントの全てが、放送経由で配信されていることになる。また、LSIDのほか、SDP等の他のSCSメタデータを参照することで、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
例えば、受信装置２０Ａは、SCブートストラップ情報の基本サービスフラグとハイブリッドフラグを参照することで、サービスを構成するコンポーネントがROUTEセッションでのみ伝送されているかどうかや、LSIDのみでロケーションを解決できるかどうかなどを、SCSシグナリングデータを取得するよりも先に認識することができるので、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。
（７）運用例５−２：ロバストサービス選局２（固定受信機、ダイレクト選局）
運用例５−２は、固定受信機としての受信装置２０Ａ（図１）において、サービスを構成するコンポーネントとSCSシグナリングデータが、複数のROUTEセッションで伝送されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
（システムパイプモデル）
図１７は、運用例５−２のシステムパイプモデルを示す図である。
図１７の運用例５−２の放送波の構成は、図１５の運用例５−１の放送波と同様の構成からなり、所定の周波数帯域からなる放送波に対応した物理チャンネル（RF Channel）において、２つのBBPストリームが伝送されているが、サービスチャンネルが、２つのBBPストリームにまたがっている点が異なっている。
ここでは、一方のBBPストリーム（BBPストリームID="X"）では、ESGサービス、NTP、LLS、及び、サービスチャンネル（サービス）の一部のストリームが伝送され、他方のBBPストリーム（BBPストリームID="ro"）では、LSID、２つのロバストオーディオ、サービスチャンネル（サービス）の一部のストリームが伝送されている。
すなわち、ROUTEセッションとBBPストリームとは独立しており、１つのROUTEセッションを構成する要素が、同一のBBPストリームで伝送される必要はないので、例えば、ビデオやオーディオ等のコンポーネントと、SCSシグナリングデータとが、異なるBBPストリームで伝送されるようにしてもよい。例えば、図１７においては、ビデオとオーディオのコンポーネントが、一方のBBPストリーム（BBPストリームID="X"）で伝送され、SCSシグナリングデータが、他方のBBPストリーム（BBPストリームID="ro"）で伝送されている。
この場合、他方のBBPストリーム（BBPストリームID="ro"）は、ロバストオーディオを伝送するための高ロバストなパイプとなるので、ビデオとオーディオのデータは高品位を保ちながら、SCSシグナリングデータをより確実に伝送することが可能となる。
例えば、視聴環境が悪い場合において、基本のビデオとオーディオが視聴できないときには、ロバストオーディオの音声のみを再生するといった運用が想定されるが、SCSシグナリングデータが取得できないと、ロバストオーディオの音声を再生することができない。そのため、SCSシグナリングデータを、高ロバストなパイプで伝送することで、そのような視聴環境でもSCSシグナリングデータを取得できるようにして、確実に、ロバストオーディオの再生が行われるようにしている。
以上のような構成からなる放送波が、送信装置１０から送信され、固定受信機である受信装置２０Ａにより受信される。
なお、受信装置２０Ａにおいては、ステップＳ１３１乃至Ｓ１３６の処理が実行され、ダイレクト選局されたサービスを構成するロバストオーディオ１又はロバストオーディオ２に接続されることになるが、その処理の流れは、図１５のステップＳ１１１乃至Ｓ１１６の処理と同様であるので、ここではその説明は省略するものとする。
＜３．システムを構成する各装置の構成＞
次に、図１８乃至図２１を参照して、図１のサービス提供システム１又は図２のサービス提供システム２を構成する各装置の詳細な構成として、送信装置１０、受信装置２０、及び、ブロードバンドサーバ３０の構成について説明する。
（送信装置の構成例）
図１８は、本技術を適用した送信装置の一実施の形態の構成を示す図である。
図１８に示すように、送信装置１０は、シグナリング生成部１１１、シグナリング処理部１１２、ビデオデータ取得部１１３、ビデオエンコーダ１１４、オーディオデータ取得部１１５、オーディオエンコーダ１１６、字幕データ取得部１１７、字幕エンコーダ１１８、ESG生成部１１９、ESG処理部１２０、Mux１２１、及び、送信部１２２から構成される。
シグナリング生成部１１１は、外部のサーバや内蔵するストレージ等から、シグナリングデータを生成するための元データを取得する。シグナリング生成部１１１は、シグナリングデータの元データを用いて、シグナリングデータを生成し、シグナリング処理部１１２に供給する。
シグナリング処理部１１２は、シグナリング生成部１１１から供給されるシグナリングデータを処理して、Mux１２１に供給する。ここでは、シグナリングデータとして、SCD等のLLSメタデータからなるLLSシグナリングデータと、USBDやLSID等のSCSメタデータからなるSCSシグナリングデータが生成される。
ビデオデータ取得部１１３は、外部のサーバや内蔵するストレージ、ビデオカメラ等から提供されるビデオデータを取得し、ビデオエンコーダ１１４に供給する。ビデオエンコーダ１１４は、ビデオデータ取得部１１３から供給されるビデオデータを、MPEG（Moving Picture Experts Group）等の符号化方式に準拠して符号化し、Mux１２１に供給する。
オーディオデータ取得部１１５は、外部のサーバや内蔵するストレージ、マイクロフォン等から提供されるオーディオデータを取得し、オーディオエンコーダ１１６に供給する。オーディオエンコーダ１１６は、オーディオデータ取得部１１５から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、Mux１２１に供給する。
字幕データ取得部１１７は、外部のサーバや内蔵するストレージ等から提供される字幕データを取得し、字幕エンコーダ１１８に供給する。字幕エンコーダ１１８は、字幕データ取得部１１７から供給される字幕データを、MPEG等の符号化方式に準拠して符号化し、Mux１２１に供給する。
ESG生成部１１９は、外部のサーバや内蔵するストレージ等から、ESGデータを生成するための元データを取得する。ESG生成部１１９は、ESGデータの元データを用いて、ESGデータを生成し、ESG処理部１２０に供給する。ESG処理部１２０は、ESG生成部１１９から供給されるESGデータを処理して、Mux１２１に供給する。
Mux１２１は、シグナリング処理部１１２からのシグナリングデータのストリームと、ビデオエンコーダ１１４からのビデオのストリームと、オーディオエンコーダ１１６からのオーディオのストリームと、字幕エンコーダ１１８からの字幕のストリームと、ESG処理部１２０からのESGデータのストリームを多重化してBBPストリームを生成し、送信部１２２に供給する。送信部１２２は、Mux１２１から供給されるBBPストリームを、IP伝送方式を用いたデジタル放送の放送波（デジタル放送信号）として、アンテナ１２３を介して送信する。
なお、ビデオやオーディオ等のコンポーネントと、SCSシグナリングデータのストリームは、ROUTEセッションで伝送される。また、ビデオやオーディオ等のコンポーネントのストリームを、ROUTEセッションで伝送する場合には、各コンポーネントのファイルを、ISO BMFFの規定に準じたセグメントごとに分割し、それにより得られるセグメントデータをLCTパケットに格納して伝送することになる。
また、デジタル放送信号において、LLSストリームにより伝送されるLLSシグナリングデータ（例えばSCD等のLLSメタデータ）を格納したLLSパケットのLLSヘッダ、あるいは、SCSストリームにより伝送されるSCSシグナリングデータ（例えばUSBDやLSID等のSCSメタデータ）を格納したLCTパケットのLCTヘッダには、フィルタリング情報を配置することができる。このフィルタリング情報としては、圧縮情報（Compression Scheme）、タイプ情報（Fragment Type）、拡張タイプ情報（Type Extension）、又は、バージョン情報などが配置される。
ここで、圧縮情報には、対象のシグナリングデータの圧縮の有無を示す情報が指定される。タイプ情報には、対象のシグナリングデータのタイプを示す情報が指定される。拡張タイプ情報には、シグナリングデータのタイプごとに設定される拡張されたフィルタリング情報が任意に設定される。バージョン情報には、対象のシグナリングデータのバージョンを示す情報が指定される。これにより、受信装置２０では、LLSヘッダ又はLCTヘッダのフィルタリング情報を用い、LLSパケット又はLCTパケットのフィルタリング処理を行うことで、対象のシグナリングデータを取得することができる。
（受信装置の構成例）
図１９は、本技術を適用した受信装置の一実施の形態の構成を示す図である。
図１９に示すように、受信装置２０は、チューナ２１２、Demux２１３、制御部２１４、NVRAM２１５、入力部２１６、通信部２１７、Demux２１８、ビデオデコーダ２１９、ビデオ出力部２２０、ディスプレイ２２１、オーディオデコーダ２２２、オーディオ出力部２２３、スピーカ２２４、及び、字幕デコーダ２２５から構成される。
チューナ２１２は、制御部２１４からの制御に従い、アンテナ２１１を介して受信したIP伝送方式を用いたデジタル放送の放送波（デジタル放送信号）から、ユーザの選局操作に応じたデジタル放送信号を抽出して復調し、その結果得られるBBPストリームを、Demux２１３に供給する。
Demux２１３は、制御部２１４からの制御に従い、チューナ２１２から供給されるBBPストリームを、ビデオやオーディオ、字幕のストリームと、シグナリングデータに分離する。Demux２１３は、ビデオデータをビデオデコーダ２１９に、オーディオデータをオーディオデコーダ２２２に、字幕データを字幕デコーダ２２５に、シグナリングデータを制御部２１４にそれぞれ供給する。
制御部２１４は、受信装置２０の各部の動作を制御する。また、制御部２１４は、Demux２１３又は通信部２１７から供給されるシグナリングデータに基づいて、放送経由又は通信経由で伝送されるコンポーネントのストリームに接続して、当該コンポーネントの再生を制御するために、各部の動作を制御する。なお、制御部２１４の詳細な構成については、図２０を参照して後述する。
NVRAM２１５は、不揮発性メモリであって、制御部２１４からの制御に従い、各種のデータを記録する。入力部２１６は、ユーザの操作に応じて、操作信号を制御部２１４に供給する。
通信部２１７は、制御部２１４からの制御に従い、インターネット９０を介してブロードバンドサーバ３０に接続し、コンポーネントのストリームの配信を要求する。通信部２１７は、インターネット９０を介してブロードバンドサーバ３０からストリーミング配信されるコンポーネントのストリームを受信して、Demux２１８に供給する。また、通信部２１７は、制御部２１４からの制御に従い、インターネット９０を介してブロードバンドサーバ３０から、SCSシグナリングデータ又はESGデータを受信し、制御部２１４に供給する。
Demux２１８は、制御部２１４からの制御に従い、通信部２１７から供給されるコンポーネントのストリームを、ビデオデータと、オーディオデータと、字幕データに分離し、ビデオデータをビデオデコーダ２１９に、オーディオデータをオーディオデコーダ２２２に、字幕データを字幕デコーダ２２５に供給する。
ビデオデコーダ２１９には、Demux２１３又はDemux２１８からビデオデータが供給される。ビデオデコーダ２１９は、制御部２１４からの制御に従い、ビデオデータを、MPEG等の復号方式に準拠して復号し、ビデオ出力部２２０に供給する。ビデオ出力部２２０は、ビデオデコーダ２１９から供給されるビデオデータを、ディスプレイ２２１に出力する。これにより、ディスプレイ２２１には、例えば番組の映像が表示される。
オーディオデコーダ２２２には、Demux２１３又はDemux２１８からオーディオデータが供給される。オーディオデコーダ２２２は、制御部２１４からの制御に従い、オーディオデータを、MPEG等の復号方式に準拠して復号し、オーディオ出力部２２３に供給する。オーディオ出力部２２３は、オーディオデコーダ２２２から供給されるオーディオデータを、スピーカ２２４に出力する。これにより、スピーカ２２４からは、例えば番組の映像に対応する音声が出力される。
字幕デコーダ２２５には、Demux２１３又はDemux２１８から字幕データが供給される。字幕デコーダ２２５は、制御部２１４からの制御に従い、字幕データを、MPEG等の復号方式に準拠して復号し、ビデオ出力部２２０に供給する。ビデオ出力部２２０は、字幕デコーダ２２５から供給される字幕データを、ビデオデコーダ２１９から供給されるビデオデータと合成して、ディスプレイ２２１に出力する。これにより、ディスプレイ２２１には、例えば番組の映像に重畳された字幕が表示される。
なお、Demux２１３は、BBPストリームからESGデータが分離された場合には、ESGデータを、制御部２１４に供給する。制御部２１４は、Demux２１３又は通信部２１７から供給されるESGデータを、ビデオ出力部２２０に供給することで、ディスプレイ２２１には、電子番組表が表示される。また、受信装置２０は、通信部２１７等の通信機能を有しない構成とすることもできる。また、受信装置２０がセットトップボックス等である場合には、ディスプレイ２２１やスピーカ２２４を有しない構成とすることができる。
（制御部の機能的構成例）
図２０は、図１９の制御部２１４における、初期スキャン処理、選局処理、フィルタリング処理、及び、通信処理の制御を行う部分の機能的構成例を示す図である。
図２０において、制御部２１４は、選局制御部２５１、フィルタリング制御部２５２、シグナリング取得部２５３、シグナリング解析部２５４、通信制御部２５５、及び、パケットヘッダ監視部２５６から構成される。また、シグナリング取得部２５３は、LLSシグナリング取得部２７１及びSCSシグナリング取得部２７２から構成される。
選局制御部２５１は、チューナ２１２により実行される選局処理を制御する。フィルタリング制御部２５２は、Demux２１３により実行されるフィルタリング処理を制御する。
初期スキャン処理時においては、選局制御部２５１がチューナ２１２を制御し、フィルタリング制御部２５２がDemux２１３を制御することで、LLSシグナリング取得部２７１によって、LLSストリームで伝送されるLLSシグナリングデータが取得され、シグナリング解析部２５４に供給される。シグナリング解析部２５４は、LLSシグナリング取得部２７１からのLLSシグナリングデータ（SCD等のLLSメタデータ）を解析して得られる選局情報を、NVRAM２１５に記録する。
選局制御部２５１は、ユーザにより選局操作が行われた場合、入力部２１６からの操作信号に応じて、NVRAM２１５に記録された選局情報（SCD）を取得する。選局制御部２５１は、取得された選局情報に基づいて、チューナ２１２により実行される選局処理を制御する。また、選局制御部２５１は、選局情報（SCD）に含まれるSCブートストラップ情報を、フィルタリング制御部２５２に供給する。
フィルタリング制御部２５２は、選局制御部２５１から供給されるSCブートストラップ情報に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。これにより、Demux２１３では、選局対象のサービスを構成するSCSストリームに接続され、当該ストリームがROUTEセッションで伝送されている場合、LCTパケットからSCSシグナリングデータが抽出される。SCSシグナリング取得部２７２は、SCSシグナリングデータ（USBD，SDP，MPD，LSID等のSCSメタデータ）を取得して、シグナリング解析部２５４に供給する。
シグナリング解析部２５４は、SCSシグナリング取得部２７２から供給されるSCSシグナリングデータ（USBD，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）、及び、バージョン情報の少なくとも１つの情報を特定の条件として、フィルタリングが行われる。
（ブロードバンドサーバの構成例）
図２１は、本技術を適用したブロードバンドサーバの一実施の形態の構成を示す図である。
図２１に示すように、ブロードバンドサーバ３０は、シグナリング生成部３１１、シグナリング処理部３１２、ビデオデータ取得部３１３、ビデオエンコーダ３１４、オーディオデータ取得部３１５、オーディオエンコーダ３１６、字幕データ取得部３１７、字幕エンコーダ３１８、ESG生成部３１９、ESG処理部３２０、データ保持部３２１、通信部３２２、及び、制御部３２３から構成される。
シグナリング生成部３１１は、外部のサーバや内蔵するストレージ等から、SCSシグナリングデータを生成するための元データを取得する。シグナリング生成部３１１は、SCSシグナリングデータの元データを用いて、SCSシグナリングデータを生成し、シグナリング処理部３１２に供給する。
シグナリング処理部３１２は、シグナリング生成部３１１から供給されるSCSシグナリングデータを処理して、データ保持部３２１に保持させる。ここでは、SCSシグナリングデータとして、USBDやLSID等のSCSメタデータが生成される。
ビデオデータ取得部３１３は、外部のサーバや内蔵するストレージ、ビデオカメラ等から提供されるビデオデータを取得し、ビデオエンコーダ３１４に供給する。ビデオエンコーダ３１４は、ビデオデータ取得部３１３から供給されるビデオデータを、MPEG等の符号化方式に準拠して符号化し、データ保持部３２１に保持させる。
オーディオデータ取得部３１５は、外部のサーバや内蔵するストレージ、マイクロフォン等から提供されるオーディオデータを取得し、オーディオエンコーダ３１６に供給する。オーディオエンコーダ３１６は、オーディオデータ取得部３１５から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、データ保持部３２１に保持させる。
字幕データ取得部３１７は、外部のサーバや内蔵するストレージ等から提供される字幕データを取得し、字幕エンコーダ３１８に供給する。字幕エンコーダ３１８は、字幕データ取得部３１７から供給される字幕データを、MPEG等の符号化方式に準拠して符号化し、データ保持部３２１に保持させる。
ESG生成部３１９は、外部のサーバや内蔵するストレージ等から、ESGデータを生成するための元データを取得する。ESG生成部３１９は、ESGデータの元データを用いて、ESGデータを生成し、ESG処理部３２０に供給する。ESG処理部３２０は、ESG生成部３１９から供給されるESGデータを処理して、データ保持部３２１に保持させる。
データ保持部３２１は、制御部３２３からの制御に従い、シグナリング処理部３１２からのSCSシグナリングデータ、ビデオエンコーダ３１４からのビデオデータ、オーディオエンコーダ３１６からのオーディオデータ、字幕エンコーダ３１８からの字幕データ、及び、ESG処理部３２０からのESGデータを保持する。
通信部３２２は、制御部３２３からの制御に従い、インターネット９０を介して受信装置２０と通信を行う。通信部３２２は、受信装置２０からの要求に応じて、データ保持部３２１に保持されている、SCSシグナリングデータ、ビデオデータ、オーディオデータ、字幕データ、又はESGデータを読み出して、インターネット９０を介して、その要求元の受信装置２０に送信する。
＜４．各装置で実行される処理の流れ＞
次に、図２２乃至図２７のフローチャートを参照して、図１のサービス提供システム１又は図２のサービス提供システム２を構成する各装置で実行される具体的な処理の流れについて説明する。
（送信処理）
まず、図２２のフローチャートを参照して、送信装置１０により実行される送信処理の流れについて説明する。
ステップＳ１５１において、シグナリング生成部１１１は、シグナリングデータの元データを用いて、シグナリングデータを生成し、シグナリング処理部１１２に供給する。ステップＳ１５２において、シグナリング処理部１１２は、シグナリング生成部１１１から供給されるシグナリングデータを処理し、Mux１２１に供給する。
ここでは、シグナリングデータとして、SCD等のLLSメタデータと、USBDやLSID等のSCSメタデータが生成される。ただし、シグナリングデータは、外部のサーバが生成するようにしてもよい。その場合には、シグナリング生成部１１１は、外部のサーバから供給されるシグナリングデータをそのまま、シグナリング処理部１１２に供給する。
ステップＳ１５３において、ビデオデータ取得部１１３、オーディオデータ取得部１１５、及び、字幕データ取得部１１７は、外部のサーバ等から、コンポーネントとしてのビデオデータ、オーディオデータ、及び、字幕データを取得し、ビデオエンコーダ１１４、オーディオエンコーダ１１６、及び、字幕エンコーダ１１８に供給する。
ステップＳ１５４において、ビデオエンコーダ１１４、オーディオエンコーダ１１６、及び、字幕エンコーダ１１８は、ビデオデータ取得部１１３、オーディオデータ取得部１１５、及び、字幕データ取得部１１７から供給される、コンポーネントとしてのビデオデータ、オーディオデータ、及び、字幕データを、MPEG等の符号化方式に準拠して符号化し、Mux１２１に供給する。
ステップＳ１５５において、Mux１２１は、シグナリング処理部１１２からのシグナリングデータと、ビデオエンコーダ１１４からのビデオのストリームと、オーディオエンコーダ１１６からのオーディオのストリームと、字幕エンコーダ１１８からの字幕のストリームを多重化してBBPストリームを生成し、送信部１２２に供給する。
ステップＳ１５６において、送信部１２２は、Mux１２１から供給されるBBPストリームをデジタル放送信号として、アンテナ１２３を介して送信する。ステップＳ１１６の処理が終了すると、図２２の送信処理は終了する。
なお、図２２の送信処理において、ビデオやオーディオ、字幕等のコンポーネントのストリームを、ROUTEセッションで伝送する場合には、各コンポーネントのファイルを、ISO BMFFの規定に準じたセグメントごとに分割し、それにより得られるセグメントデータをLCTパケットに格納して伝送することになる。
さらに、デジタル放送信号において、LLSシグナリングデータ（SCD等のLLSメタデータ）を格納したLLSパケットのLLSヘッダ、あるいは、SCSシグナリングデータ（USBDやLSID等のメタデータ）を格納したLCTパケットのLCTヘッダには、圧縮情報（Compression Scheme）、タイプ情報（Fragment Type）、拡張タイプ情報（Type Extension）、及び、バージョン情報などのフィルタリング情報を配置することができる。
以上、送信処理の流れについて説明した。
（初期スキャン処理）
次に、図２３のフローチャートを参照して、受信装置２０により実行される初期スキャン処理の流れについて説明する。
ステップＳ２１１においては、制御部２１４によって、入力部２１６からの操作信号等が監視され、初期スキャンイベントが発生するまで、待機する。そして、ステップＳ２１２において、初期スキャンイベントが発生したと判定された場合、処理は、ステップＳ２１３に進められる。
ステップＳ２１３において、チューナ２１２は、選局制御部２５１からの制御に従い、周波数スキャン処理を行う。ステップＳ２１４においては、ステップＳ２１３の周波数スキャン処理によって、周波数スキャンが成功したかどうかが判定される。
ステップＳ２１４において、周波数スキャンが失敗したと判定された場合、処理は、ステップＳ２１３の処理に戻り、再度、周波数スキャン処理が行われる。一方、ステップＳ２１４において、周波数スキャン処理に成功したと判定された場合、処理は、ステップＳ２１５に進められる。
ステップＳ２１５において、Demux２１３は、フィルタリング制御部２５２からの制御に従い、チューナ２１２から供給されるBBPストリームを取得して解析する。ステップＳ２１６においては、ステップＳ２１５の解析結果に従い、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２１５を参照して、選局情報（SCD）が記録され、取得済みであるかどうかを判定する。
ステップＳ２５４において、選局情報が取得済みであると判定された場合、処理は、ステップＳ２５５に進められる。ステップＳ２５５において、選局制御部２５１は、NVRAM２１５に記録された選局情報（SCD）を読み出して取得する。
一方、ステップＳ２５４において、選局情報が取得済みではないと判定された場合、処理は、ステップＳ２５６に進められる。ステップＳ２５６においては、Demux２１３、及び、制御部２１４によって、図２４のLLS取得・記録処理と同様の処理が行われ、LLSストリームから、LLSシグナリングデータ（SCD等のLLSメタデータ）が取得される。これにより、制御部２１４においては、選局情報（SCD）が取得されることになる（Ｓ２５５）。
ステップＳ２５７においては、チューナ２１２、Demux２１３、及び、制御部２１４等によって、ステップＳ２５５の処理で取得された選局情報に基づいた選局処理が行われる。なお、選局処理の詳細な内容は、図２６及び図２７のフローチャートを参照して後述する。
以上、選局前処理の流れについて説明した。
（選局処理）
次に、図２６のフローチャートを参照して、図２５のステップＳ２５７の処理に対応する選局処理の詳細な内容を説明する。
ステップＳ２７１において、制御部２１４は、受信装置２０が通信機能を有しているかどうかを確認することで、受信装置２０が放送のみを受信可能であるかどうかを判定する。ステップＳ２７１において、例えば、仮に、受信装置２０が、通信部２１７等の通信機能を有しておらず、放送のみを受信可能であると判定された場合、処理は、ステップＳ２７２に進められる。
ステップＳ２７２において、シグナリング解析部２５４は、NVRAM２１５に記録された選局情報（SCD）を参照して、選局されたサービスのSCブートストラップ情報の基本サービスフラグ（LSIDBaseService要素）に、"TRUE"が指定されているかどうかを判定する。
ステップＳ２７２において、基本サービスフラグ（LSIDBaseService要素）に、"TRUE"が指定されていると判定された場合、処理は、ステップＳ２７３に進められる。ステップＳ２７３において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップＳ２７３の処理で取得されたLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ２７４において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。
これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。また、ステップＳ２７５においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップＳ２７４の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得（キャプチャ）される。
そして、例えば、ステップＳ２７４の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図２５のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ２８０）。
このように、SCブートストラップ情報の基本サービスフラグ（LSIDBaseService要素）として"TRUE"が指定されている場合、全てのSCSメタデータを参照することなく、LSIDのみを用いて、所望のコンポーネントを取得することができる。
一方、ステップＳ２７２において、基本サービスフラグ（LSIDBaseService要素）に、"FALSE"が指定されていると判定された場合、処理は、ステップＳ２７６に進められる。ステップＳ２７６において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているUSBD，MPD，SDP等のSCSシグナリングデータを取得する。ステップＳ２７６の処理で取得されたSDPは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ２７７において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップＳ２７７の処理で取得されたLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ２７８において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。
これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。また、ステップＳ２７９においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップＳ２７８の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得（キャプチャ）される。
そして、例えば、ステップＳ２７９の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図２５のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ２８０）。
このように、SCブートストラップ情報の基本サービスフラグ（LSIDBaseService要素）として"FALSE"が指定されている場合、LSIDに記述された内容のみではコンポーネントの取得先を特定することができないため、LSIDのほか、USBD，MPD，SDP等の他のSCSメタデータを参照して、所望のコンポーネントを取得することになる。ステップＳ２８０の処理が終了すると、処理は、図２５のステップＳ２５７の処理に戻り、それ以降の処理が実行される。
なお、ステップＳ２７１において、受信装置２０が、放送と通信のハイブリッドに対応していると判定された場合、処理は、ステップＳ２８１に進められる。ステップＳ２８１においては、放送と通信のハイブリッドに対応した選局処理が行われる。なお、ハイブリッドに対応した選局処理の詳細な内容は、図２７のフローチャートを参照して後述する。
以上、選局処理の流れについて説明した。
（ハイブリッドに対応した選局処理）
次に、図２７のフローチャートを参照して、図２６のステップＳ２８１の処理に対応する、ハイブリッドに対応した選局処理の詳細な内容を説明する。
ステップＳ２９１において、シグナリング解析部２５４は、NVRAM２１５に記録された選局情報（SCD）を参照して、選局されたサービスに、SCSブロードバンドロケーション情報（SignalingOverInternet要素）が記述されているかどうかを判定する。
ステップＳ２９１において、選局されたサービスに、SCSブロードバンドロケーション情報（SignalingOverInternet要素）が記述されていないと判定された場合、処理は、図２６のステップＳ２７２の処理に進められ、それ以降の処理が実行される。すなわち、この場合、SCSシグナリングデータが放送のみで提供されることを意味するので、SCブートストラップ情報を用いてSCSシグナリングデータが取得されることになる。
また、ステップＳ２９１において、選局されたサービスに、SCSブロードバンドロケーション情報（SignalingOverInternet要素）が記述されていると判定された場合、処理は、ステップＳ２９２に進められる。ステップＳ２９２において、シグナリング解析部２５４は、SCSブロードバンドロケーション情報（SignalingOverInternet要素）の基本サービスフラグ（LSIDBaseService要素）に、"TRUE"が指定されているかどうかを判定する。
ステップＳ２９２において、基本サービスフラグ（LSIDBaseService要素）に、"TRUE"が指定されていると判定された場合、処理は、ステップＳ２９３に進められる。ステップＳ２９３において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップＳ２９３の処理で取得されたLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ２９４において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。
これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。また、ステップＳ２９５においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップＳ２９４の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得（キャプチャ）される。
そして、例えば、ステップＳ２９４の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図２５のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ３０４）。
一方、ステップＳ２９２において、基本サービスフラグ（LSIDBaseService要素）に、"FALSE"が指定されていると判定された場合、処理は、ステップＳ２９６に進められる。ステップＳ２９６において、通信制御部２５５は、シグナリング解析部２５４からの解析結果（SignalingOverInternet要素のuri属性）に従い、通信部２１７を制御して、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、USBD，MPD，SDP等のSCSシグナリングデータを取得する。
ステップＳ２９７において、シグナリング解析部２５４は、SCSブロードバンドロケーション情報（SignalingOverInternet要素）のハイブリッドフラグ（hybrid属性）に、"TRUE"が指定されているかどうかを判定する。
ステップＳ２９７において、ハイブリッドフラグ（hybrid属性）に、"FALSE"が指定されていると判定された場合、処理は、ステップＳ２９８に進められる。なお、この場合、ステップＳ２９６の処理で取得されたSDPは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
そして、ステップＳ２９８において、SCSシグナリング取得部２７２は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップＳ２９８の処理で取得されたLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。ステップＳ２９８の処理が終了すると、処理は、ステップＳ２９４に進められる。
ステップＳ２９４において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。
これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。また、ステップＳ２９５においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップＳ２９４の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得（キャプチャ）される。
そして、例えば、ステップＳ２９４の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図２５のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ３０４）。
また、ステップＳ２９７において、ハイブリッドフラグ（hybrid属性）に、"TRUE"が指定されていると判定された場合、処理は、ステップＳ２９９に進められる。ステップＳ２９９において、シグナリング解析部２５４は、例えば、ステップＳ２９６の処理で取得されたUSBDやMPDを解析することで、取得するコンポーネントの配信経路が、放送経由であるか、あるいは通信経路であるかを判定する。
ステップＳ２９９において、コンポーネントの配信経路が放送経由であると判定された場合、処理は、ステップＳ３００に進められる。なお、この場合、ステップＳ２９６の処理で取得されたSDPは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
そして、ステップＳ３００において、シグナリング取得部２５３は、Demux２１３により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップＳ３００の処理で取得されたLSIDは、シグナリング解析部２５４により解析され、その解析結果が、フィルタリング制御部２５２に供給される。
ステップＳ３０１において、フィルタリング制御部２５２は、シグナリング解析部２５４から供給される解析結果（IPアドレス、ポート番号、TSI、及び、TOI）に基づいて、Demux２１３により実行されるフィルタリング処理を制御する。これにより、Demux２１３では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得（キャプチャ）される。
一方、ステップＳ２９９において、コンポーネントの配信経路が通信経由であると判定された場合、処理は、ステップＳ３０２に進められる。ステップＳ３０２において、シグナリング解析部２５４は、ステップＳ２９６の処理で取得されたMPDを解析して、その解析の結果得られるメディアセグメント情報（セグメントURL）を、通信制御部２５５に供給する。これにより、通信制御部２５５は、シグナリング解析部２５４からのメディアセグメント情報（セグメントURL）を取得する。
そして、ステップＳ３０１において、通信制御部２５５は、シグナリング解析部２５４からのメディアセグメント情報（セグメントURL）に従い、通信部２１７を制御して、インターネット９０を介してブロードバンドサーバ３０にアクセスすることで、選局されたサービスを構成するコンポーネントを取得（キャプチャ）する。
ステップＳ３０１の処理が終了すると、処理は、ステップＳ３０３に進められる。ステップＳ３０３においては、取得する全てのコンポーネントがキャプチャされたかどうかが判定される。ステップＳ３０３において、全てのコンポーネントがキャプチャされていないと判定された場合、処理は、ステップＳ２９９に戻り、それ以降の処理が繰り返される。
すなわち、ステップＳ２９９乃至Ｓ３０３の処理が繰り返されることで、放送経由又は通信経由でコンポーネントが取得され、ステップＳ３０３において、全てのコンポーネントがキャプチャされたと判定された場合、処理は、ステップＳ３０４に進められる。ステップＳ３０４においては、例えば、ステップＳ３００又はＳ３０２の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図２５のステップＳ２５２の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される（Ｓ３０４）。
ステップＳ３０４の処理が終了すると、処理は、図２６のステップＳ２８１の処理に戻り、それ以降の処理が実行される。
以上、ハイブリッドに対応した選局処理の流れについて説明した。
＜５．シンタックスの例＞
（１）LLSシグナリングデータ
（LLSパケットの構造）
図２８は、LLSパケットの構造を示す図である。
図２８に示すように、BBPパケットは、BBPヘッダとペイロードから構成される。BBPストリームによりIPパケットを伝送する場合には、ペイロードの部分がIPパケットとなる。BBPストリームによりLLSシグナリングデータを伝送する場合には、BBPヘッダの次にLLSシグナリングデータが配置される。LLSシグナリングデータとしては、例えば、XML形式で記述されたSCD等のLLSメタデータが配置される。
BBPヘッダには、2ビットのタイプ情報が含まれており、そのタイプ情報によって、BBPパケットがIPパケットであるか、LLSであるかを区別することができる。また、LLSヘッダは、LLSインデックスとオブジェクトバージョン情報（バージョン情報）から構成される。
図２９は、LLSヘッダのLLSインデックスの例を示す図である。
LLSインデックスは、圧縮情報（Compression Scheme）、タイプ情報（Fragment Type）、拡張タイプ情報（Type Extension）が配置される。圧縮情報には、対象のLLSシグナリングデータの圧縮の有無を示す情報が指定される。例えば、"0000"が指定された場合には、非圧縮であることを示し、"0001"が指定された場合には、zip形式で圧縮されていることを示している。
タイプ情報（Fragment Type）には、LLSシグナリングデータのタイプを示す情報が指定される。例えば、SCDには"000000"、EADには"000001"、RRDには"000010"、DCDには"000011"がそれぞれ指定される。拡張タイプ情報には、タイプごとに拡張パラメータを指定することができる。
（SCDのシンタックス）
図３０は、XML形式のSCDのシンタックスを示す図である。なお、図３０において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシンタックスでも同様とされる。
図３０に示すように、ルート要素としてのSCD要素は、majorProtocolversion属性、minorProtocolversion属性、RFAllocationId属性、name属性、Tuning_RF要素、及び、BBPStream要素の上位要素となる。
majorProtocolversion属性と、minorProtocolversion属性には、プロトコルのバージョン情報が指定される。RFAllocationId属性には、物理チャンネル単位の放送局のRFアロケーションIDが指定される。name属性には、物理チャンネル単位の放送局の名称が指定される。
Tuning_RF要素は、選局に関する情報が指定される。Tuning_RF要素は、frequency属性、及び、Preamble属性の上位要素となる。frequency属性には、所定の帯域を選局するときの周波数が指定される。Preamble属性には、物理層の制御情報が指定される。
BBPStream要素には、１又は複数のBBPストリームに関する情報が指定される。BBPStream要素は、bbpStreamId属性、payloadType属性、name属性、ESGBootstrap要素、ClockReferenceInformation要素、及び、Service要素の上位要素となる。
bbpStreamId属性には、BBPストリームIDが指定される。BBPストリームを複数配置する場合には、このBBPストリームIDにより識別する。payloadType属性には、BBPストリームのペイロードタイプが指定される。このペイロードタイプとしては、例えば、"ipv4"，"ipv6"などが指定される。"ipv4"は、IPv4（Internet Protocol version 4）であることを示す。"ipv6"は、IPv6（Internet Protocol Version 6）であることを示す。name属性には、BBPストリームの名称が指定される。
ESGBootstrap要素には、ESGブートストラップ情報が指定される。このESGブートストラップ情報によってESGへアクセスすることが可能となる。ESGBootstrap要素は、ESGProvider要素の上位要素となる。ESGProvider要素には、ESGのプロバイダごとに、ESGに関する情報が指定される。ESGProvider要素は、providerName属性、ESGBroadcastLocation要素、及び、ESGBroadbandLocation要素の上位要素となる。
providerName属性には、ESGのプロバイダの名称が指定される。ESGBroadcastLocation要素は、ESGが放送により伝送される場合に、RFAllocationId属性、BBPStreamId属性、及び、ESGServiceId属性により指定されるRFアロケーションID、BBPストリームID、及び、サービスID（トリプレット）によって、ESGサービスを指定する。ESGBroadbandLocation要素は、ESGが通信経由で伝送される場合に、ESGUri属性により、そのESGのファイルにアクセスするためのURIを指定する。
ClockReferenceInformation要素には、時刻情報（例えばNTP）に関する情報が指定される。ClockReferenceInformation要素は、sourceIPAddress属性、destinationIPAddress属性、及び、portNum属性の上位要素となる。sourceIPAddress属性とdestinationIPAddress属性には、時刻情報を伝送する送信元（source）と宛先（destination）のIPアドレスが指定される。portNum属性には、時刻情報を伝送するポート番号が指定される。
Service要素には、１又は複数のサービスに関する情報が指定される。Service要素は、serviceId属性、globalUniqueServiceId属性、serviceType属性、hidden属性、hiddenGuide属性、shortName属性、longName属性、accesControl属性、SourceOrigin要素、SCBootstrap要素、SignalingOverInternet要素、及び、AssociationService要素の上位要素となる。
serviceId属性には、サービスIDが指定される。サービスを複数配置する場合には、このサービスIDにより識別する。globalUniqueServiceId属性には、グローバルユニークサービスIDが指定される。例えば、グローバルユニークサービスIDによって、ESG選局されたサービスと、USBDとを紐付けることができる。
serviceType属性には、サービスのタイプ情報が指定される。このタイプ情報としては、例えば、"continued"，"scripted"が指定される。"continued"は、ビデオやオーディオのサービス、"scripted"は、NRTサービスをそれぞれ示している。
hidden属性とhiddenGuide属性には、サービスIDにより識別されるサービスが、隠されたサービスであるかどうかが指定される。例えば、これらの属性値として"on"が指定された場合、当該サービスは非表示とされる。また、これらの属性値として"off"が指定された場合、当該サービスは表示される。例えば、hidden属性として"on"が指定された場合、当該サービスは、リモートコントローラの操作により選局できないようになる。また、例えば、hiddenGuide属性として"on"が指定された場合、当該サービスは、ESGには表示されないことになる。
shortName属性とlongName属性には、サービスIDにより識別されるサービスの名称が指定される。ただし、shortName属性では、例えば７文字以内でサービスの名称の名称を指定しなければならない。accesControl属性には、サービスIDにより識別されるサービスが暗号化されているかどうかが指定される。例えば、accesControl属性として"on"が指定された場合には、当該サービスが暗号化されていることを示し、"off"が指定された場合には、当該サービスが暗号化されていないことを示している。
SourceOrigin要素には、サービスを識別するための情報が指定される。SourceOrigin要素は、country属性、originalRFAllocationId属性、bbpStreamId属性、及び、serviceId属性の上位要素となる。country属性には、国コードが指定される。originalRFAllocationId属性には、オリジナルRFアロケーションIDが指定される。オリジナルRFアロケーションIDは、放送ネットワークを識別するためのIDであって、当該サービスの再送信を行う場合でも、同一の値が用いられる。bbpStreamId属性には、BBPストリームIDが指定される。serviceId属性には、サービスIDが指定される。すなわち、国コード、オリジナルRFアロケーションID、BBPストリームID、及び、サービスIDによって、各サービスに対して、固有のIDを割り当てることができる。
SCBootstrap要素には、SCブートストラップ情報が指定される。このSCブートストラップ情報によって、サービスチャンネルへアクセスすることが可能となって、SCSシグナリングデータを取得することができる。SCBootstrap要素は、LSIDBaseService属性、hybrid属性、sourceIPAddress属性、destinationIPAddress属性、portNum属性、及び、tsi属性の上位要素となる。
LSIDBaseService属性には、上述した基本サービスフラグに相当するものであって、LSIDのみで、サービスを構成するコンポーネントのストリームを取得できるかどうかが指定される。また、hybrid属性には、上述したハイブリッドフラグに相当するものであって、通信経由で配信されるコンポーネントのストリームがあるかどうかが指定される。
sourceIPAddress属性とdestinationIPAddress属性には、サービスを伝送する送信元（source）と宛先（destination）のIPアドレスが指定される。portNum属性には、SCSを伝送するポート番号が指定される。tsi属性には、SCSを伝送するROUTEセッションにおけるTSIが指定される。
SignalingOverInternet要素には、SCSブロードバンドロケーション情報が指定される。このSCSブロードバンドロケーション情報によって、通信経由で伝送されるSCSシグナリングデータに関する情報が指定される。SignalingOverInternet要素は、LSIDBaseService属性、hybrid属性、及び、uri属性の上位要素となる。
LSIDBaseService属性には、上述した基本サービスフラグに相当するものであって、LSIDのみで、サービスを構成するコンポーネントのストリームを取得できるかどうかが指定される。また、hybrid属性には、上述したハイブリッドフラグに相当するものであって、通信経由で配信されるコンポーネントのストリームがあるかどうかが指定される。uri属性には、SCSシグナリングデータの取得先を示すURIが指定される。
AssociationService要素には、関連従属サービスに関する情報が指定される。AssociationService要素は、RFAllocationId属性、bbpStreamId属性、及び、serviceId属性の上位要素となる。RFAllocationId属性、bbpStreamId属性、及び、serviceId属性により指定されるRFアロケーションID、BBPストリームID、及び、サービスID（トリプレット）によって、関連従属サービスを指定する。
なお、出現数(Cardinality)であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..n"が指定された場合には、その要素又は属性は１以上指定され、"0..n"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。これらの出現数の意味は、後述する他のシンタックスでも同様とされる。
（EADのシンタックス）
図３１は、XML形式のEADのシンタックスを示す図である。
図３１に示すように、ルート要素としてのEAD要素は、AutomaticTuningService要素、及び、EAMessage要素の上位要素となる。AutomaticTuningService要素は、Wake-up時の自動選局サービスを指定するためのものである。AutomaticTuningService要素は、RFAllocationId属性、bbpStreamId属性、及び、serviceId属性の上位要素となる。
RFAllocationId属性は、自動選局サービスのネットワークIDが指定される。BBPStreamId属性は、自動選局サービスのBBPストリームIDが指定される。serviceId属性は、自動選局サービスのサービスIDが指定される。すなわち、AutomaticTuningService要素が出現した場合、それらの属性が示すトリプレットにより指定されるサービスが選局される。ただし、このトリプレットのうち、RFAllocationId属性とBBPStreamId属性は必須ではなく、例えば、EADと同一のBBPストリームを指定するのであれば、serviceId属性のみを指定すればよいことになる。
EAMessage要素は、緊急警報情報（緊急情報）のメッセージが指定される。EAMessage要素は、eaMessageId属性、eaPriority属性、EAMessageData要素、EAApplication要素、EAService要素、及び、EAWww要素の上位要素となる。
eaMessageId属性は、緊急警報情報（緊急情報）のIDが指定される。eaPriority属性は、緊急警報情報（緊急情報）の優先度が指定される。EAMessageData要素は、緊急警報情報（緊急情報）の字幕情報が指定される。
EAApplication要素は、緊急警報用のアプリケーションに関する情報が指定される。EAApplication要素は、applicationId属性の上位要素となる。applicationId属性は、アプリケーションIDが指定される。
EAService要素は、緊急警報用のNRTサービスに関する情報が指定される。EAService要素は、serviceId属性、及び、serviceType属性の上位要素となる。serviceId属性は、サービスIDが指定される。serviceType属性は、サービスタイプ情報が指定される。このサービスタイプ情報としては、例えば"nrt"が指定される。"nrt"は、NRTサービスであることを示す。
EAWww要素は、緊急情報サイトに関する情報が指定される。EAWww要素は、uri属性の上位要素となる。uri属性には、緊急情報サイトのURIが指定される。
（緊急警報情報の表示例）
図３２は、EADによる緊急警報情報の表示例を示す図である。なお、図３２において、図中の上側は、送信装置１０とインターネットサーバ４０から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置２０Ａにおける処理の流れを表している。また、図３２において、時間の方向は、図中の左側から右側の方向とされる。
図３２において、送信装置１０は、IP伝送方式を用いたデジタル放送の放送波（RF Channel）を伝送している。この放送波では、一方のBBPストリーム（以下、「BBPストリーム１」という）で、サービス（例えば番組）を構成するコンポーネント及びSCSシグナリングデータ、並びにLLSシグナリングデータが伝送されている。また、他方のBBPストリーム（以下、「BBPストリーム２」という）で、２つのロバストオーディオと、SCSのストリームが伝送されている。
また、インターネットサーバ４０は、緊急情報サイトを提供しており、インターネット９０を介して緊急警報詳細情報を配信している。
図３２に示すように、固定受信機としての受信装置２０Ａにおいては、初期スキャン処理等によって、BBPストリーム１のLLSストリームで伝送されているSCDが取得され、NVRAMに記録される（Ｓ４１１）。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が、サービスごとに記述されている。
受信装置２０Ａにおいては、ユーザによりサービスが選局された場合（Ｓ４１２）、当該サービスのSCブートストラップ情報がNVRAMから読み出され、SCブートストラップ情報に従い、送信装置１０からの放送波で伝送されているBBPストリーム１のSCSストリームに接続される（Ｓ４１３）。これにより、受信装置２０Ａは、ROUTEセッション１で伝送されているSCSシグナリングデータを取得することができる（Ｓ４１４）。
受信装置２０Ａは、ステップＳ４１４の処理で取得されたSCSシグナリングデータに従い、送信装置１０からの放送波で伝送されているBBPストリーム１のビデオとオーディオのストリームに接続する（Ｓ４１５）。これにより、受信装置２０Ａは、ROUTEセッション１で伝送されているビデオデータとオーディオデータを取得することができる（Ｓ４１６）。そして、受信装置２０Ａでは、ROUTEセッション１から取得されたビデオデータとオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、選局されたサービスに対応した番組の映像と音声が再生される（Ｓ４１７）。
その後、受信装置２０Ａにおいて、BBPストリーム１のLLSストリームで伝送されているEADが取得された場合（Ｓ４１８）、再生中の番組の映像には、EAD（のEAMessage要素のEAMessageData要素）に対応した緊急警報情報（の字幕情報）が重畳表示される（Ｓ４１９）。
また、受信装置２０Ａは、ユーザによって、緊急警報詳細情報の表示が指示された場合（Ｓ４２０）、EAD（のEAMessage要素のEAWww要素のuri属性）に指定された緊急情報サイトのURIに従い、インターネット９０を介してインターネットサーバ４０にアクセスし（Ｓ４２１）、緊急警報詳細情報を取得する（Ｓ４２２）。これにより、受信装置２０Ａにおいては、緊急情報サイトから取得された緊急警報詳細情報が表示されることになる（Ｓ４２３）。
（RRDのシンタックス）
図３３は、XML形式のRRDのシンタックスを示す図である。
図３３に示すように、ルート要素としてのRRD要素は、RatingRegionName要素、RatingRegion要素、TableVersion要素、及び、Dimension要素の上位要素となる。RatingRegionName要素には、レーティングリージョンの名称が指定される。RatingRegion要素は、レーティングリージョンのコードが指定される。このコードとしては、例えば、"us"，"canada"，"mexico"などが指定される。TableVersion要素には、RRDのバージョン情報が指定される。
Dimension要素は、RatingDimensionName要素、RatingDimension要素、GraduatedScale要素、及び、DimensionValue要素の上位要素となる。RatingDimensionName要素は、レーティングディメンションの名称が指定される。RatingDimension要素は、レーティングディメンションのコードが指定される。GraduatedScale要素は、スケールが指定される。
DimensionValue要素には、ディメンションの値が指定される。DimensionValue要素は、RatingValueText要素、AbbrevValueText要素、RatingValue要素、及び、RatingTag要素の上位要素となる。これらの属性により、例えば、年齢制限の区分けの仕方などのレーティング情報が指定される。
（DCDのシンタックス）
図３４は、XML形式のDCDのシンタックスの例を示す図である。
図３４において、ルート要素としてのDCD要素は、Service要素の上位要素となる。Service要素は、serviceID属性、serviceStatus属性、video要素、及び、audio要素の上位要素となる。serviceID属性には、サービスIDが指定される。serviceStatus属性には、サービスIDにより識別されるサービスのステータスに関する情報が指定される。
video要素には、最小限のサービスとしてのビデオのストリームに接続するための情報が指定される。video要素は、mime_type属性、port_number属性、及び、TSI属性の上位要素となる。mime_type属性には、MIMEタイプが指定される。port_number属性には、ポート番号が指定される。TSI属性には、TSIが指定される。
audio要素には、最小限のサービスとしてのオーディオのストリームに接続するための情報が指定される。audio要素は、mime_type属性、port_number属性、及び、TSI属性の上位要素となる。mime_type属性には、MIMEタイプが指定される。port_number属性には、ポート番号が指定される。TSI属性には、TSIが指定される。
なお、図３０乃至図３４を参照して説明したSCD，EAD，RRD，DCDの各シンタックスは一例であって、他のシンタックスを採用することができる。
（２）SCSシグナリングデータ
（LCTパケットの構造）
図３５は、LCTパケットの構造を示す図である。
図３５に示すように、BBPストリームによりLCTパケットを伝送する場合、BBP，IP，UDP，LCTの各ヘッダがペイロードに付加される。ROUTEセッションによりSCSシグナリングデータを伝送する場合には、LCTヘッダの次に配置されるペイロードに、SCSシグナリングデータが配置される。SCSシグナリングデータとしては、例えば、XML形式のUSBDやLSID等のSCSメタデータが配置される。
LCTヘッダは、SCSインデックス（Signaling Index）とオブジェクトバージョン情報（バージョン情報）から構成される。
図３６は、LCTヘッダのSCSインデックスの例を示す図である。
SCSインデックス（Signaling Index）は、圧縮情報（Compression Scheme）、タイプ情報（Fragment Type）、拡張タイプ情報（Type Extension）が配置される。圧縮情報には、対象のSCSシグナリングデータの圧縮の有無を示す情報が指定される。例えば、"0000"が指定された場合には、非圧縮であることを示し、"0001"が指定された場合には、zip形式で圧縮されていることを示している。
タイプ情報（Fragment Type）には、SCSシグナリングデータのタイプを示す情報が指定される。例えば、SCSバンドルには"000000"、USBDには"000001"、SDPには"000010"、SPDには"000011"がそれぞれ指定される。拡張タイプ情報には、タイプごとに拡張パラメータを指定することができる。
（LSIDのシンタックス）
図３７は、XML形式のLSIDのシンタックスの例を示す図である。
図３７に示すように、ルート要素としてのLSID要素は、version属性、validFrom属性、expiration属性、及び、TransportSession要素の上位要素となる。version属性には、LSIDのバージョン情報が指定される。validFrom属性には、LSIDの失効期間の開始日時が指定される。expiration属性には、LSIDの失効日時が指定される。
TransportSession要素には、LCTトランスポートのセッション情報が指定される。TransportSession要素は、tsi属性、SourceFlow要素、及び、RepairFlow要素の上位要素となる。tsi属性には、TSIが指定される。SourceFlow要素には、ソースフロー情報が指定される。なお、SourceFlow要素の詳細な構成は、図３８を参照して後述する。RepairFlow要素には、リペアフロー情報が指定される。なお、RepairFlow要素の詳細な構成は、図４０を参照して後述する。
（SourceFlow要素のシンタックス）
図３８は、図３７のSourceFlow要素のシンタックスの例を示す図である。
SourceFlow要素には、ソースフロー情報が指定される。図３８に示すように、ルート要素としてのSourceFlow要素は、EFDT要素、idRef属性、realtime属性、minBufferSize属性、ApplicationIdentifier要素、及び、PayloadFormat要素の上位要素となる。
EFDT要素は、Extended FDTの略であって、拡張されたFDTに関する情報が指定される。なお、EFDT要素の詳細な構成は、図３９を参照して後述する。idRef属性には、EFDT IDが指定される。
realtime属性には、"TRUE"又は"FALSE"が指定され、"TRUE"が指定された場合には、LCT拡張ヘッダに、NTPタイムスタンプを含むことになる。なお、realtime属性のデフォルト値は、"FALSE"とされる。minBufferSize属性には、受信装置２０が必要とする最小バッファサイズが指定される。ApplicationIdentifier要素には、アプリケーションとマッピングするIDが指定される。
PayloadFormat要素には、ソースフロー情報のペイロードフォーマットが指定される。PayloadFormat要素は、codePoint属性、deliveryObjectFormat属性、fragmentation属性、deliveryOrder属性、sourceFECPayloadID属性、及び、FECParameters要素の上位要素とされる。
codePoint属性には、コードポイント値が指定される。なお、コードポイント値のデフォルト値は、"0"とされる。deliveryObjectFormat属性には、ペイロードフォーマットが指定される。fragmentation属性には、フラグメンテーションに関する情報が指定される。deliveryOrder属性には、デリバリオーダに関する情報が指定される。sourceFECPayloadID属性には、ソースFECのペイロードIDが指定される。FECParameters要素には、FECパラメータが指定される。
（EFDT要素のシンタックス）
図３９は、図３８のEFDT要素のシンタックスの例を示す図である。
EFDT要素には、拡張されたFDTに関する情報が指定される。図３９に示すように、ルート要素としてのEFDT要素は、route:idRef属性、route:version属性、route:maxExpiresDelta属性、route:maxTransportSize属性、及び、FileTemplate要素の上位要素となる。
route:idRef属性には、EFDT IDが指定される。route:version属性には、EFDTのバージョン情報が指定される。route:maxExpiresDelta属性には、オブジェクトの伝送後、失効するまでの時間が指定される。route:maxTransportSize属性には、最大転送サイズが指定される。FileTemplate要素には、ファイルテンプレートに関する情報が指定される。
（RepairFlow要素のシンタックス）
図４０は、図３７のRepairFlow要素のシンタックスの例を示す図である。
RepairFlow要素には、リペアフロー情報が指定される。図４０に示すように、ルート要素としてのRepairFlow要素は、FECパラメータが指定されるFECParameters要素の上位要素となる。また、FECParameters要素は、fecEncodingId属性、maximumDelay属性、overhead属性、minBufferSize属性、FECOTI要素、及び、ProtectedObject要素の上位要素となる。
fecEncodingId属性には、FECスキームのIDが指定される。maximumDelay属性には、ソースフロー情報とリペアフロー情報の最大遅延時間が指定される。overhead属性には、オーバーヘッド値が指定される。minBufferSize属性には、受信装置２０が必要とする最小バッファサイズが指定される。FECOTI要素には、FECオブジェクトのトランスミッション情報が指定される。ProtectedObject要素には、保護するソースフロー情報に関する情報が指定される。なお、ProtectedObject要素の詳細な構成は、図４１を参照して後述する。
（ProtectedObject要素のシンタックス）
図４１は、図４０のProtectedObject要素のシンタックスの例を示す図である。
ProtectedObject要素には、保護するソースフロー情報に関する情報が指定される。図４１に示すように、ルート要素としてのProtectedObject要素は、sessionDescription属性、tsi属性、sourceTOI属性、及び、fecTransportObjectSize属性の上位要素となる。
sessionDescription属性は、ソースフロー情報のセッション情報が指定される。tsi属性には、ソースフロー情報のTSIが指定される。sourceTOI属性には、リペアフロー情報のTOIと一致するデリバリオブジェクトのTOIが指定される。fecTransportObjectSize属性には、FECトランスポートオブジェクトのデフォルトサイズが指定される。
（SPDのシンタックス）
図４２は、XML形式のSPDのシンタックスの例を示す図である。
図４２に示すように、ルート要素としてのSPD要素は、serviceId属性、spIndicator属性、AlternativeService要素、HybridSignalLocationDescription要素、ContentAdvisoryDescription要素、及び、NRTServiceDescription要素の上位要素となる。
serviceId属性には、サービスIDが指定される。spIndicator属性には、サービスIDにより識別されるサービスごとに、暗号化されているかどうかが指定される。spIndicator属性として"on"が指定された場合には、当該サービスが暗号化されていることを示し、"off"が指定された場合には、当該サービスが暗号化されていないことを示している。
AlternativeService要素には、オルタナティブサービスに関する情報が指定される。AlternativeService要素は、globalUniqueServiceId属性の上位要素となる。globalUniqueServiceId属性には、グローバルユニークサービスIDが指定される。
HybridSignalLocationDescription要素には、通信経由で伝送されるシグナリングデータに関する情報が指定される。なお、HybridSignalLocationDescription要素の詳細な構成は、図４３を参照して後述する。
ContentAdvisoryDescription要素には、レーティングリージョンに関する情報が指定される。なお、ContentAdvisoryDescription要素の詳細な構成は、図４４を参照して後述する。
NRTServiceDescription要素には、NRTサービスに関する情報が指定される。なお、NRTServiceDescription要素の詳細な構成は、図４５を参照して後述する。
（HybridSignalLocationDescription要素のシンタックス）
図４３は、図４２のHybridSignalLocationDescription要素のシンタックスの例を示す図である。
HybridSignalLocationDescription要素には、通信経由で伝送されるシグナリングデータに関する情報が指定される。図４３に示すように、ルート要素としてのHybridSignalLocationDescription要素は、version属性、url属性、及び、hybrid属性の上位要素となる。
version属性には、シグナリングデータのバージョン情報が指定される。url属性には、シグナリングデータの取得先を示すURLが指定される。hybrid属性には、ハイブリッドサービスに対応したシグナリングデータであるかどうかを示す情報が指定される。例えば、hybrid属性として"TRUE"が指定された場合、ハイブリッドサービスに対応していることを表している。また、例えば、hybrid属性として"FALSE"が指定された場合、放送基本サービスに対応していることを表している。
（Content Advisory Description要素のシンタックス）
図４４は、図４２のContentAdvisoryDescription要素のシンタックスの例を示す図である。
ContentAdvisoryDescription要素には、レーティングリージョンに関する情報が指定される。図４４に示すように、ルート要素としてのContent Advisory Description要素は、version属性、及び、RatingRegion要素の上位要素となる。version属性には、RRDのバージョン情報が指定される。
RatingRegion要素は、ratingRegionId属性、及び、RatingDimension要素の上位要素となる。ratingRegionId属性には、レーティングリージョンIDが指定される。RatingDimension要素は、dimensionIndex属性、ratingValue属性、及び、ratingTag属性の上位要素となる。これらの属性により、年齢制限の区分けの仕方などのレーティング情報が指定される。
（NRTServiceDescription要素のシンタックス）
図４５は、図４２のNRTServiceDescription要素のシンタックスの例を示す図である。
NRTServiceDescription要素には、NRTサービスに関する情報が指定される。図４５に示すように、ルート要素としてのNRTServiceDescription要素は、ConsumptionModel属性、autoUpdate属性、storageReservarion属性、defaultContentSize属性、ProtocolVersionDescription要素、CapabilityDescription要素、IconDescription要素、ISO639LanguageDescription要素、及び、ReceiverTargetingDescription要素の上位要素となる。
ConsumptionModel属性には、NRTサービスの伝送モードが指定される。この伝送モードとしては、例えば、"B&D"，"push"，"portal"，"triggered"が指定される。"B&D"は、Browse and Downloadの略で、ユーザにより選択されたNRTコンテンツのファイルデータをダウンロードするモードである。"push"は、契約したNRTサービスをプッシュ型で提供するモードである。"portal"は、HTML形式のファイルなどを伝送して直ちに表示するモードである。"triggered"は、アプリケーションを提供するモードである。
autoUpdate属性には、NRTサービスが自動更新されるかどうかが指定される。autoUpdate属性として"on"が指定された場合には、当該NRTサービスが自動更新されることを示し、"off"が指定された場合には、当該NRTサービスが自動更新されないことを示している。storageReservarion属性には、必要とされるストレージの容量が指定される。defaultContentSize属性には、NRTコンテンツ１つ当たりのサイズが指定される。
ProtocolVersionDescription要素には、データのサービスがどのようなサービスであるかを示すための情報が指定される。CapabilityDescription要素には、NRTサービスの提供を受ける受信装置２０に要求される機能（キャパビリティ）に関する情報が指定される。
IconDescription要素には、NRTサービスで用いられるアイコンの取得先を示す情報が指定される。ISO639LanguageDescription要素には、NRTサービスの言語コードが指定される。ReceiverTargetingDescription要素には、NRTサービスのターゲット情報が指定される。
（ProtocolVersionDescription要素のシンタックス）
図４６は、図４５のProtocolVersionDescription要素のシンタックスの例を示す図である。
Protocol Version Description要素には、データのサービスがどのようなサービスであるかを示すための情報が指定される。図４６に示すように、ルート要素としてのProtocol Version Description要素は、protocolIdentifier属性、majorProtocolVersion属性、及び、minorProtocolVersion属性の上位要素となる。
protocolIdentifier属性には、データのサービスのフォーマットのタイプ情報が指定される。このタイプ情報としては、例えば、"A/90"，"NRT"が指定される。"A/90"は、汎用のデータを伝送する方式であることを示す。また、"NRT"は、NRT(Non-RealTime)により伝送する方式であることを示す。
majorProtocolVersion属性とminorProtocolVersion属性には、データのサービスのバージョンが指定される。majorProtocolVersion属性には、メジャーバージョン、minorProtocolVersion属性には、マイナーバージョンがそれぞれ指定される。
（CapabilityDescription要素のシンタックス）
図４７は、図４５のCapabilityDescription要素のシンタックスの例を示す図である。
Capability Description要素には、NRTサービスの提供を受ける受信装置２０に要求される機能（キャパビリティ）に関する情報が指定される。図４７に示すように、ルート要素としてのCapability Description要素は、IndivisualCapabilityCodes要素、IndivisualCapabilityString要素、及び、CapabilityOrSets要素の上位要素となる。
IndivisualCapabilityCodes要素は、essentialIndicator属性、capabilityCode属性、及び、formatIdentifier属性の上位要素となる。essentialIndicator属性には、キャパビリティが必須であるかどうかを示す情報が指定される。capabilityCode属性には、あらかじめ定められたキャパビリティのコードが指定される。すなわち、essentialIndicator属性とcapabilityCode属性により、キャパビリティのコードにより指定されるキャパビリティが必須であるかどうかが指定される。formatIdentifier属性には、キャパビリティのコードを任意に指定する場合に、評価すべき機能(キャパビリティ)が指定される。
IndivisualCapabilityString要素は、essentialIndicator属性、capabilityCategoryCode属性、及び、capabilityString属性の上位要素となる。essentialIndicator属性には、キャパビリティが必須であるかどうかを示す情報が指定される。capabilityCategoryCode属性には、キャパビリティのカテゴリごとのコードが指定される。すなわち、essentialIndicator属性とcapabilityCategoryCode属性により、キャパビリティのカテゴリごとのコードにより指定されるキャパビリティが必須であるかどうかが指定される。capabilityString属性には、キャパビリティのカテゴリごとに、評価すべき機能(キャパビリティ)が指定される。
CapabilityOrSets要素は、上述したIndivisualCapabilityCodes要素によるキャパビリティのコードごとの評価と、IndivisualCapabilityString要素によるキャパビリティのカテゴリのコードごとの評価を、OR条件で指定する場合に指定される。したがって、CapabilityOrSets要素は、essentialIndicator属性、CapabilityCodesInSets要素、及び、CapabilityStringsInSets要素の上位要素となるが、essentialIndicator属性は、上述したessentialIndicator属性に対応している。
また、CapabilityCodesInSets要素におけるcapabilityCode属性と、formatIdentifier属性は、上述したIndivisualCapabilityCodes要素におけるcapabilityCode属性と、formatIdentifier属性に対応している。さらに、CapabilityStringsInSets要素におけるcapabilityCategoryCode属性と、capabilityString属性は、上述したIndivisualCapabilityString要素におけるcapabilityCategoryCode属性と、capabilityString属性に対応している。
（IconDescription要素のシンタックス）
図４８は、図４５のIconDescription要素のシンタックスの例を示す図である。
IconDescription要素には、NRTサービスで用いられるアイコンの取得先を示す情報が指定される。図４８に示すように、ルート要素としてのIconDescription要素は、content_linkage属性の上位要素となる。content_linkage属性には、アイコンの取得先を示すURLが指定される。
（ISO-639LanguageDescription要素のシンタックス）
図４９は、図４５のISO-639LanguageDescription要素のシンタックスの例を示す図である。
ISO639LanguageDescription要素は、NRTサービスの言語コードが指定される。図４９に示すように、ルート要素としてのISO639LanguageDescription要素は、languageCode属性の上位要素となる。languageCode属性には、ISO 639で規定された言語コードが指定される。
（ReceiverTargetingDescription要素のシンタックス）
図５０は、図４５のReceiverTargetingDescription要素のシンタックスの例を示す図である。
ReceiverTargetingDescription要素には、NRTサービスのターゲット情報が指定される。図５０に示すように、ルート要素としてのReceiverTargetingDescription要素は、TargetEntry要素の上位要素となる。TargetEntry要素は、geoLocation属性、postalCode属性、及び、demographic category属性の上位要素となる。
geoLocation属性には、NRTサービスのターゲットとなる地理的な位置が指定される。postalCode属性には、NRTサービスのターゲットとなる地域の郵便番号が指定される。demographic category属性は、NRTサービスのターゲットとなるユーザのカテゴリが指定される。このカテゴリとしては、例えば、"males"，"females"，"Ages 12-17"が指定される。"males"は、NRTサービスのターゲットが男性であることを示す。"females"は、NRTサービスのターゲットが女性であることを示す。"Ages 12-17"は、NRTサービスのターゲットが12歳から17歳であることを示す。
なお、図３７乃至図５０を参照して説明したLSID，SPD，及び、SPDのDescription要素の各シンタックスは一例であって、他のシンタックスを採用することができる。
＜６．変形例＞
上述した説明では、現在策定が進められている米国の次世代放送規格である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」との形式的な違いであって、各シグナリングデータの実質的な内容が異なるものではない。
さらに、上述した説明では、シグナリングデータがXML等のマークアップ言語により記述される場合における、その要素や属性について説明したが、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。例えば、SCD等に規定されるRFアロケーションID（RF Allocation ID）は、ネットワークID（Network ID）やRFチャンネルID（RF Channel ID）などと称するようにしてもよい。また、例えば、SCDのSCBootstrap要素のLSIDBaseService属性は、LSIDBasicService属性などと記述するようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
＜７．コンピュータの構成＞
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図５１は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ９００において、CPU（Central Processing Unit）９０１，ROM（Read Only Memory）９０２，RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記憶されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
（１）
IP（Internet Protocol）伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを取得する第１の取得部と、
前記第２のメタデータに基づいて、前記第１のメタデータを取得する第２の取得部と、
前記第１のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する制御部と
を備える受信装置。
（２）
前記制御部は、前記第１のフラグが、前記第１のメタデータのみで前記サービスを構成するコンポーネントが取得できることを示しており、かつ前記第２のフラグが、前記通信経由で伝送されるコンポーネントのストリームがないことを示している場合、前記第１のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
（１）に記載の受信装置。
（３）
前記第２の取得部は、前記第２のフラグが、前記通信経由で伝送されるコンポーネントのストリームがあることを示している場合、前記通信経由で伝送されるコンポーネントのストリームの再生を管理するための第３のメタデータを取得し、
前記制御部は、前記第１のメタデータ及び前記第３のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームと、前記通信経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
（１）に記載の受信装置。
（４）
前記第１のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第１のシグナリングデータであり、
前記第２のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第２のシグナリングデータである
（１）乃至（３）のいずれかに記載の受信装置。
（５）
前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータのストリームは、FLUTE（File Delivery over Unidirectional Transport）を拡張したROUTE（Real-time Object Delivery over Unidirectional Transport）セッションで伝送される
（４）に記載の受信装置。
（６）
前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータとは、異なるBBP（Base Band Packet）ストリームで伝送される
（５）に記載の受信装置。
（７）
前記第２の取得部は、放送経由又は通信経由で伝送される前記第１のシグナリングデータを取得する
（４）乃至（６）のいずれかに記載の受信装置。
（８）
前記コンポーネントは、ビデオ、オーディオ、又は字幕であり、
前記サービスは、番組である
（１）乃至（７）のいずれかに記載の受信装置。
（９）
前記第１のメタデータは、LSID（LCT Session Instance Description）であり、
前記第２のメタデータは、SCD（Service Configuration Description）である
（１）乃至（８）のいずれかに記載の受信装置。
（１０）
受信装置の受信方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを取得し、
前記第２のメタデータに基づいて、前記第１のメタデータを取得し、
前記第１のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
ステップを含む受信方法。
（１１）
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを生成する生成部と、
生成された前記第２のメタデータを送信する送信部と
を備える送信装置。
（１２）
前記第１のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第１のシグナリングデータであり、
前記第２のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第２のシグナリングデータである
（１１）に記載の送信装置。
（１３）
前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータのストリームは、FLUTEを拡張したROUTEセッションで伝送される
（１２）に記載の送信装置。
（１４）
前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータとは、異なるBBPストリームで伝送される
（１３）に記載の送信装置。
（１５）
送信装置の送信方法において、
前記送信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを生成し、
生成された前記第２のメタデータを送信する
ステップを含む送信方法。
１，２ サービス提供システム， １０ 送信装置， ２０Ａ，２０Ｂ，２０ 受信装置， ３０ ブロードバンドサーバ， ４０ インターネットサーバ， ５０ 中継局， ６０ アクセスポイント， ９０ インターネット， １１１ シグナリング生成部， １１３ ビデオデータ取得部， １１５ オーディオデータ取得部， １１７ 字幕データ取得部， １２２ 送信部， ２１２ チューナ， ２１４ 制御部， ２１７ 通信部， ２５１ 選局制御部， ２５２ フィルタリング制御部， ２５３ シグナリング取得部， ２５４ シグナリング解析部， ２５５ 通信制御部， ２５６ パケットヘッダ監視部， ２７１ LLSシグナリング取得部， ２７２ SCSシグナリング取得部， ３１１ シグナリング生成部， ３１３ ビデオデータ取得部， ３１５ オーディオデータ取得部， ３１７ 字幕データ取得部， ３２２ 通信部， ９００ コンピュータ， ９０１ CPU

Claims (15)

  1. IP（Internet Protocol）伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを取得する第１の取得部と、
    前記第２のメタデータに基づいて、前記第１のメタデータを取得する第２の取得部と、
    前記第１のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する制御部と
    を備える受信装置。
  2. 前記制御部は、前記第１のフラグが、前記第１のメタデータのみで前記サービスを構成するコンポーネントが取得できることを示しており、かつ前記第２のフラグが、前記通信経由で伝送されるコンポーネントのストリームがないことを示している場合、前記第１のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
    請求項１に記載の受信装置。
  3. 前記第２の取得部は、前記第２のフラグが、前記通信経由で伝送されるコンポーネントのストリームがあることを示している場合、前記通信経由で伝送されるコンポーネントのストリームの再生を管理するための第３のメタデータを取得し、
    前記制御部は、前記第１のメタデータ及び前記第３のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームと、前記通信経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
    請求項１に記載の受信装置。
  4. 前記第１のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第１のシグナリングデータであり、
    前記第２のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第２のシグナリングデータである
    請求項１に記載の受信装置。
  5. 前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータのストリームは、FLUTE（File Delivery over Unidirectional Transport）を拡張したROUTE（Real-time Object Delivery over Unidirectional Transport）セッションで伝送される
    請求項４に記載の受信装置。
  6. 前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータから構成され、
    前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータとは、異なるBBP（Base Band Packet）ストリームで伝送される
    請求項５に記載の受信装置。
  7. 前記第２の取得部は、放送経由又は通信経由で伝送される前記第１のシグナリングデータを取得する
    請求項４に記載の受信装置。
  8. 前記コンポーネントは、ビデオ、オーディオ、又は字幕であり、
    前記サービスは、番組である
    請求項１に記載の受信装置。
  9. 前記第１のメタデータは、LSID（LCT Session Instance Description）であり、
    前記第２のメタデータは、SCD（Service Configuration Description）である
    請求項１に記載の受信装置。
  10. 受信装置の受信方法において、
    前記受信装置が、
    IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを取得し、
    前記第２のメタデータに基づいて、前記第１のメタデータを取得し、
    前記第１のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
    ステップを含む受信方法。
  11. IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを生成する生成部と、
    生成された前記第２のメタデータを送信する送信部と
    を備える送信装置。
  12. 前記第１のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第１のシグナリングデータであり、
    前記第２のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第２のシグナリングデータである
    請求項１１に記載の送信装置。
  13. 前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータのストリームは、FLUTEを拡張したROUTEセッションで伝送される
    請求項１２に記載の送信装置。
  14. 前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータから構成され、
    前記放送経由で伝送されるコンポーネントと、前記第１のシグナリングデータとは、異なるBBPストリームで伝送される
    請求項１３に記載の送信装置。
  15. 送信装置の送信方法において、
    前記送信装置が、
    IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第１のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第１のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第２のフラグとを含む第２のメタデータを生成し、
    生成された前記第２のメタデータを送信する
    ステップを含む送信方法。
JP2016553048A 2014-10-10 2015-09-28 受信装置、受信方法、送信装置、及び、送信方法 Expired - Fee Related JP6610553B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014209501 2014-10-10
JP2014209501 2014-10-10
PCT/JP2015/077244 WO2016056412A1 (ja) 2014-10-10 2015-09-28 受信装置、受信方法、送信装置、及び、送信方法

Publications (2)

Publication Number Publication Date
JPWO2016056412A1 true JPWO2016056412A1 (ja) 2017-07-20
JP6610553B2 JP6610553B2 (ja) 2019-11-27

Family

ID=55653029

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016553048A Expired - Fee Related JP6610553B2 (ja) 2014-10-10 2015-09-28 受信装置、受信方法、送信装置、及び、送信方法

Country Status (8)

Country Link
US (3) US10305949B2 (ja)
EP (1) EP3206409B1 (ja)
JP (1) JP6610553B2 (ja)
KR (1) KR102456991B1 (ja)
CN (1) CN105981399B (ja)
CA (1) CA2932717C (ja)
MX (1) MX366870B (ja)
WO (1) WO2016056412A1 (ja)

Families Citing this family (18)

* 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
JP6579391B2 (ja) * 2014-07-07 2019-09-25 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
MX366870B (es) 2014-10-10 2019-07-29 Sony Corp Dispositivo de recepción, método de recepción, dispositivo de transmisión, y método de transmisión.
KR101781884B1 (ko) * 2014-11-04 2017-09-26 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN106233692B (zh) * 2014-11-12 2019-09-13 Lg电子株式会社 广播信号发送装置、广播信号接收装置、广播信号发送方法和广播信号接收方法
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
EP3232668A4 (en) * 2014-12-10 2018-06-13 LG Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method and broadcast signal reception method
US10264624B2 (en) 2014-12-17 2019-04-16 Sony Corporation Transmission apparatus, transmission method, reception apparatus, and reception method
EP3249914A4 (en) * 2015-01-21 2018-07-18 LG Electronics Inc. Broadcast signal transmission apparatus, broadcast signal receiving apparatus, broadcast signal transmission method, and broadcast signal receiving method
US10356451B2 (en) 2015-07-06 2019-07-16 Lg Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
CA3082203C (en) * 2015-10-23 2022-11-08 Sharp Kabushiki Kaisha Signaling method, receiving method signaling device, and receiving device
JP2019135806A (ja) * 2018-02-05 2019-08-15 ソニーセミコンダクタソリューションズ株式会社 復調回路、処理回路、処理方法、および処理装置
US11159833B2 (en) * 2018-11-23 2021-10-26 Sony Corporation Buffer management for storing files of a received packet stream
US11616822B2 (en) * 2019-09-30 2023-03-28 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
US11570509B2 (en) 2020-01-06 2023-01-31 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
US11228796B2 (en) * 2020-01-07 2022-01-18 Tencent America LLC Pattern addressing for session-based dash operations
US11363310B2 (en) * 2020-09-21 2022-06-14 Sony Corporation ATSC 3.0 hospitality TV system
US11323778B2 (en) * 2020-09-23 2022-05-03 Sony Group Corporation Unified programming guide for content associated with broadcaster and VOD applications

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6630963B1 (en) * 2001-01-23 2003-10-07 Digeo, Inc. Synchronizing a video program from a television broadcast with a secondary audio program
EP2075935A1 (en) * 2007-12-31 2009-07-01 Motorola, Inc. A method and apparatus for providing uninterrupted media to a user
JP5045535B2 (ja) 2008-04-28 2012-10-10 ソニー株式会社 受信装置及び受信方法
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
CA2743997C (en) * 2008-11-18 2013-06-11 Lg Electronics Inc. Method for receiving a broadcast signal
US8099752B2 (en) * 2008-12-03 2012-01-17 Sony Corporation Non-real time services
US8782725B2 (en) * 2009-01-15 2014-07-15 Lg Electronics Inc. Method of processing non-real time service and broadcast receiver
JP5278059B2 (ja) * 2009-03-13 2013-09-04 ソニー株式会社 情報処理装置及び方法、プログラム、並びに情報処理システム
US8320823B2 (en) * 2009-05-04 2012-11-27 Siport, Inc. Digital radio broadcast transmission using a table of contents
US8621520B2 (en) * 2009-05-19 2013-12-31 Qualcomm Incorporated Delivery of selective content to client applications by mobile broadcast device with content filtering capability
KR101809957B1 (ko) * 2010-03-29 2017-12-18 엘지전자 주식회사 비실시간 서비스 처리 방법 및 방송 수신기
US20130211567A1 (en) * 2010-10-12 2013-08-15 Armital Llc System and method for providing audio content associated with broadcasted multimedia and live entertainment events based on profiling information
FR2973632A1 (fr) 2011-03-31 2012-10-05 France Telecom Procede d'acces a un service, notamment un portail web, par un terminal de restitution d'un flux multimedia
CA2833762C (en) * 2011-04-20 2016-09-13 Lg Electronics Inc. Transmission method for broadcast service, reception method therefor, and reception apparatus therefor
US9584238B2 (en) * 2011-06-24 2017-02-28 Nokia Corporation Accessing service guide information in a digital video broadcast system
CN102868937A (zh) * 2011-07-08 2013-01-09 中兴通讯股份有限公司 多媒体数据的传输方法及***
JP6071187B2 (ja) 2011-11-09 2017-02-01 オリンパス株式会社 撮像ユニットおよび撮像モジュール
MX2014008657A (es) * 2012-01-24 2014-10-06 Sony Corp Dispositivo de recepcion, metodo de recepcion, programa y sistema de procesamiento de informacion.
US9942601B2 (en) * 2013-01-24 2018-04-10 Saturn Licensing Llc Storing non-real time content
US9967522B2 (en) 2013-02-27 2018-05-08 GM Global Technology Operations LLC Driver monitoring camera system
CN105009601A (zh) * 2013-02-27 2015-10-28 索尼公司 信息处理装置和方法、程序和内容供应***
US8938033B2 (en) * 2013-03-15 2015-01-20 Intel Corporation Enhanced low power active radio reception
MX366870B (es) 2014-10-10 2019-07-29 Sony Corp Dispositivo de recepción, método de recepción, dispositivo de transmisión, y método de transmisión.

Also Published As

Publication number Publication date
EP3206409B1 (en) 2024-01-03
CN105981399B (zh) 2020-05-08
US10841350B2 (en) 2020-11-17
EP3206409A1 (en) 2017-08-16
US20160248828A1 (en) 2016-08-25
MX2016007240A (es) 2016-08-11
KR20170068408A (ko) 2017-06-19
EP3206409A4 (en) 2018-05-23
JP6610553B2 (ja) 2019-11-27
CN105981399A (zh) 2016-09-28
US10305949B2 (en) 2019-05-28
KR102456991B1 (ko) 2022-10-21
US20210037075A1 (en) 2021-02-04
CA2932717A1 (en) 2016-04-14
US20190297128A1 (en) 2019-09-26
MX366870B (es) 2019-07-29
US11374993B2 (en) 2022-06-28
CA2932717C (en) 2023-10-10
WO2016056412A1 (ja) 2016-04-14

Similar Documents

Publication Publication Date Title
JP6610553B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
KR102332387B1 (ko) 수신 장치, 수신 방법, 송신 장치 및 송신 방법
KR102484513B1 (ko) 수신 장치, 수신 방법, 송신 장치, 및, 송신 방법
JP6519586B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
KR102384709B1 (ko) 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
WO2015198872A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180913

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: 20191001

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191014

R151 Written notification of patent or utility model registration

Ref document number: 6610553

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees