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

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

Info

Publication number
JPWO2016129407A1
JPWO2016129407A1 JP2016555629A JP2016555629A JPWO2016129407A1 JP WO2016129407 A1 JPWO2016129407 A1 JP WO2016129407A1 JP 2016555629 A JP2016555629 A JP 2016555629A JP 2016555629 A JP2016555629 A JP 2016555629A JP WO2016129407 A1 JPWO2016129407 A1 JP WO2016129407A1
Authority
JP
Japan
Prior art keywords
transmission
information
fit
service
control information
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.)
Ceased
Application number
JP2016555629A
Other languages
English (en)
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 JPWO2016129407A1 publication Critical patent/JPWO2016129407A1/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/28—Arrangements for simultaneous broadcast of plural pieces of information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • 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/95—Arrangements characterised by the broadcast information itself characterised by a specific format, e.g. MP3 (MPEG-1 Audio Layer 3)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/323—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the physical layer [OSI layer 1]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists

Abstract

本技術は、運用形態に応じた制御情報の伝送を行うことができるようにする送信装置、送信方法、受信装置、及び、受信方法に関する。受信装置は、サービスの選局時に必要となる情報を含む制御情報と、制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータであって、伝送系列情報に応じた伝送系列で送信されてくる第１のデータを受信し、伝送系列情報に応じて取得される制御情報に基づいて、サービスを構成するコンポーネントのデータを含む第２のデータに対する処理を制御する。本技術は、例えば、テレビ受像機に適用することができる。

Description

本技術は、送信装置、送信方法、受信装置、及び、受信方法に関し、特に、運用形態に応じた制御情報の伝送を行うことができるようにした送信装置、送信方法、受信装置、及び、受信方法に関する。
日本や米国を含む各国においては、デジタルテレビ放送のサービスが開始されている（例えば、特許文献１参照）。また、デジタルテレビ放送規格では、デジタルテレビ放送のサービスを実現するために、各種の制御情報が規定されている。
特開２００８−２６３６１６号公報
ところで、この種の制御情報には、その内容に応じて、受信装置側で直ちに取得されるべき情報や、特に急いで取得される必要がない情報などがあり、運用形態に応じて制御情報の伝送を行うことができるようにしたいという要請があった。
また、この種の制御情報を複数のサービス事業者に横断して１つの管理テーブルとして伝送したいという要請のほか、サービス事業者ごとに独立して管理し、それぞれの運用形態に応じて制御情報を伝送したいという要請があった。
本技術はこのような状況に鑑みてなされたものであり、運用形態に応じた制御情報の伝送を行うことができるようにするものである。
本技術の第１の側面の送信装置は、サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータを生成する生成部と、前記サービスを構成するコンポーネントのデータを含む第２のデータとともに、前記伝送系列情報に応じた伝送系列で前記第１のデータを送信する送信部とを備える送信装置である。
本技術の第１の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の送信方法は、上述した本技術の第１の側面の送信装置に対応する送信方法である。
本技術の第１の側面の送信装置、及び、送信方法においては、サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータが生成され、前記サービスを構成するコンポーネントのデータを含む第２のデータとともに、前記伝送系列情報に応じた伝送系列で前記第１のデータが送信される。
本技術の第２の側面の受信装置は、サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータであって、前記伝送系列情報に応じた伝送系列で送信されてくる前記第１のデータを受信する受信部と、前記伝送系列情報に応じて取得される前記制御情報に基づいて、前記サービスを構成するコンポーネントのデータを含む第２のデータに対する処理を制御する制御部とを備える受信装置である。
本技術の第２の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の受信方法は、上述した本技術の第２の側面の受信装置に対応する受信方法である。
本技術の第２の側面の受信装置、及び、受信方法においては、サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータであって、前記伝送系列情報に応じた伝送系列で送信されてくる前記第１のデータが受信され、前記伝送系列情報に応じて取得される前記制御情報に基づいて、前記サービスを構成するコンポーネントのデータを含む第２のデータに対する処理が制御される。
本技術の第１の側面、及び、第２の側面によれば、運用形態に応じた制御情報の伝送を行うことができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した伝送システムの一実施の形態の構成を示す図である。 L1フレーム伝送方式を説明する図である。 L1フレーム伝送方式の派生例を説明する図である。 L2パケット伝送方式１を説明する図である。 L2パケット伝送方式１の派生例を説明する図である。 L2パケット伝送方式２を説明する図である。 L2パケット伝送方式２の派生例を説明する図である。 L1フレーム伝送方式を用いた運用例１を説明する図である。 L2パケット伝送方式を用いた運用例２を説明する図である。 １つの伝送帯域を１つのサービス事業者のみが利用する場合の伝送形態を模式的に示した図である。 １つの伝送帯域を複数のサービス事業者が利用する場合の伝送形態を模式的に示した図である。 １つの伝送帯域を複数のサービス事業者が共同で利用する場合の送出処理を説明する図である。 １つの伝送帯域を複数のサービス事業者が共同で利用する場合のFITとサービスコンポーネントの関係を説明する図である。 FITのシンタックスの例を示す図である。 サービスステータス記述子のシンタックスの例を示す図である。 サービス名称記述子のシンタックスの例を示す図である。 ケイパビリティ記述子のシンタックスの例を示す図である。 サービスブートストラップ記述子のシンタックスの例を示す図である。 シグナリングテンプレート記述子のシンタックスの例を示す図である。 シグナリングオーバーインターネット記述子のシンタックスの例を示す図である。 FITのシンタックスの他の例を示す図である。 送信装置の構成例を示す図である。 受信装置の構成例を示す図である。 送信処理を説明するフローチャートである。 初期スキャン処理を説明するフローチャートである。 FIT取得処理を説明するフローチャートである。 選局処理を説明するフローチャートである。 選局中のFIT取得処理を説明するフローチャートである。 コンピュータの構成例を示す図である。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．クラス情報とバージョン情報の伝送方式
３．運用例
（１）運用例１：L1フレーム伝送方式
（２）運用例２：L2パケット伝送方式
（３）運用例３：事業者IDを用いたFITの伝送
４．シンタックスの例
５．各装置の構成
６．各装置で実行される処理の流れ
７．変形例
８．コンピュータの構成
＜１．システムの構成＞
（伝送システムの構成例）
図１において、伝送システム１は、デジタルテレビ放送（デジタル放送）のサービスを提供するためのシステムである。伝送システム１は、送信装置１０、受信装置２０、及び、サーバ３０から構成される。また、図１において、受信装置２０とサーバ３０は、インターネット９０を介して相互に接続されている。
送信装置１０は、デジタル放送の所定の規格に対応した送信機であって、放送事業者（サービス事業者）により提供される。なお、本技術の実施の形態において、デジタル放送の規格としては、例えば、ATSC（Advanced Television Systems Committee standards）等の規格を採用することができる。
送信装置１０は、サービスを構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、シグナリングデータとともに、デジタル放送の放送波によって、伝送路８０を介して送信する。ここで、サービスは、例えば、放送事業者（サービス事業者）により制作された番組（テレビ番組）を編成したものである。また、シグナリングデータは、サービスを視聴するために必要となる制御情報である。
受信装置２０は、例えばATSC等のデジタル放送の所定の規格に対応した受信機であって、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータ、ノート型のパーソナルコンピュータ、自動車内で利用される端末などのモバイル受信機である。
受信装置２０は、送信装置１０から送信されるデジタル放送の放送波を、伝送路８０を介して受信して、デジタル放送の放送波で伝送されるシグナリングデータを取得する。受信装置２０は、シグナリングデータに基づいて、送信装置１０から送信されるデジタル放送の放送波で伝送されるサービス（を構成するコンポーネント）のストリームに接続して、そのストリームから得られる映像と音声を再生（出力）する。
サーバ３０は、受信装置２０からの要求に応じて、サービスを構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、インターネット９０を介してストリーミング配信する。また、サーバ３０は、受信装置２０からの要求に応じて、シグナリングデータを、インターネット９０を介して配信する。なお、サーバ３０は、シグナリングデータ（後述するSLSシグナリングデータ）のほか、ESG(Electronic Service Guide)メタデータやアプリケーションなどのNRT(Non Real Time)コンテンツなどを提供してもよい。
受信装置２０は、通信機能を有しており、インターネット９０を介して、サーバ３０にアクセスすることができる。受信装置２０は、送信装置１０又はサーバ３０からのシグナリングデータに基づいて、サーバ３０からインターネット９０を介してストリーミング配信されるサービス（を構成するコンポーネント）のストリームに接続して、そのストリームから得られる映像と音声を再生（出力）する。
なお、図１においては、送信装置１０からのデジタル放送の放送波が直接、受信装置２０により受信される構成を図示しているが、１又は複数の中継局（不図示）を介してデジタル放送の放送波が伝送されるようにしてもよい。また、受信装置２０は、モバイル受信機である場合、公衆無線LAN（Local Area Network）のアクセスポイントを介してインターネット９０に接続するか、あるいはLTE（Long Term Evolution）等のモバイル系のネットワーク（不図示）を介して、サーバ３０に接続することになる。
また、受信装置２０は、通信機能を有していない場合や、通信機能を有しているがその通信機能が無効になっている場合がある。その場合には、受信装置２０は、サーバ３０にアクセスすることができない。さらに、図１においては、説明の簡略化のため、サーバ３０が、ビデオやオーディオ等のコンポーネントのストリームと、シグナリングデータの両方を配信する場合を図示しているが、コンポーネントのストリームと、シグナリングデータは、別のサーバから配信されるようにしてもよい。
＜２．クラス情報とバージョン情報の伝送方式＞
シグナリングデータには、サービスに依存しない低レイヤのLLS（Low Layer Signaling）シグナリングデータと、サービス単位のSLS（Service Layer Signaling）シグナリングデータがある。ここで、デジタル放送の規格として、IP(Internet Protocol)パケットを用いたIP伝送方式を採用した場合、IP伝送方式のプロトコルスタックにおいて、LLSシグナリングデータは、IP層（レイヤ）よりも下位の階層で伝送され、SLSシグナリングデータは、IP層（レイヤ）よりも上位の階層で伝送される。ただし、LLSシグナリングデータは、SLSシグナリングデータ、及び、データの伝送との共通化を図るために、IP層（レイヤ）によってパケット化されて伝送されるようにしてもよい。
なお、現在策定が進められている米国の次世代放送規格であるATSC3.0では、IP伝送方式を用いたデジタル放送の採用が見込まれている。
LLSシグナリングデータは、EAD（Emergency Alerting Description），RRD（Region Rating Description），DCD（Default Component Description）等のメタデータのほか、FIT(Fast Information Table)が含まれる場合がある。すなわち、FITは、LLSシグナリングデータとして伝送される以外に、レイヤ１（物理層）で伝送される場合がある。
FITは、MPEG2-TS(Moving Picture Experts Group phase 2 - Transport Stream)方式に対応したID体系によって、放送ネットワーク内のストリームやサービスの構成を示す情報等を含んでいる。また、FITには、サービスレベルの記述子として、サービスステータス記述子、サービス名称記述子、ケイパビリティ記述子、サービスブートストラップ記述子、シグナリングテンプレート記述子、又は、シグナリングオーバーインターネット記述子などが配置される。
サービスステータス記述子は、サービスの状態を記述している。サービス名称記述子は、サービスの名称を記述している。ケイパビリティ記述子は、受信装置２０の能力を記述している。サービスブートストラップ記述子は、SLSシグナリングデータを取得するためのブートストラップ情報を記述している。シグナリングテンプレート記述子は、シグナリングデータのテンプレートを記述している。シグナリングオーバーインターネット記述子は、サーバ３０により配信されるSLSシグナリングデータに関する情報を記述している。
FITには、クラス（系列）が定義される。クラス（系列）は、FITを複数の異なる周期により伝送する場合に用いられる。また、クラス（系列）は、FITを複数の異なるサービス事業者により伝送する場合に用いられる。クラスは、配信クラスID（delivery_group_id）と事業者ID（provider_id）で構成される。複数の異なる周期は、配信クラスIDで識別され、複数の異なるサービス事業者は、事業者IDによって識別される。クラス（系列）は、クラスIDにより識別される。すなわち、配信クラスIDと事業者IDによって識別される。また、各クラス（系列）のFITは、バージョン情報によりそのバージョンが管理される。以下の説明では、クラスIDと、クラスの数を示すクラス数を総称して、「クラス情報」という。また、クラス情報とバージョン情報を総称して、「伝送系列情報」という。
SLSシグナリングデータは、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），SPD（Service Parameter Description）等のメタデータが含まれる。ただし、これらのメタデータのうち、実際に用いられるメタデータは、運用に応じて決定される。
ここで、SLSシグナリングデータは、ROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送される。ROUTEは、放送のライブサービス向けに、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。ただし、ROUTEは、FLUTE + (FLUTE plus)やFLUTE enhancementなどの別の名称で呼ばれる場合がある。なお、サービスを構成するビデオやオーディオ、字幕等のコンポーネントのストリームについても、ROUTEセッションで伝送することができる。
なお、以下の説明において、LLSシグナリングデータと、SLSシグナリングデータを特に区別する必要がない場合、単に、「シグナリングデータ」と称する。
（L1フレーム伝送方式）
図２は、L1フレーム伝送方式として、L1フレームのヘッダ部を用いた伝送系列情報の伝送を説明する図である。
L1フレームは、レイヤ１（物理層）のフレームであって、ヘッダ部とペイロード部から構成される。L1フレームのペイロード部には、複数のL2パケット（レイヤ２のパケット）が配置され、カプセル化されている。
ヘッダ部には、FITのほか、1ビットのFIT伝送フラグ（FIT_delivery_flag）と、15ビットのFITバージョン情報（FIT_version）が配置される。
FIT伝送フラグは、FITが伝送されているかどうかを示すフラグである。例えば、FIT伝送フラグが"TRUE"である場合、FITが伝送されていることを示し、FIT伝送フラグが"FALSE"である場合、FITが伝送されていないことを示す。
FITバージョン情報は、3ビットのクラス数（num_of_class）、4ビットのクラスID（class_id）、及び、8ビットのバージョン情報（version）から構成される。換言すれば、FITバージョン情報は、伝送系列情報を含んでいる。クラス数は、伝送されているFITのクラス（系列）の数を示す。クラスIDは、FITのクラス（系列）を識別するためのIDである。バージョン情報は、FITのクラス（系列）ごとのバージョンを示す。
このように、L1フレーム伝送方式では、L1フレームのヘッダ部に、FIT伝送フラグとFITバージョン情報が配置されている。そのため、受信装置２０は、L1フレームを取得した段階で、FIT伝送フラグによりFITが伝送されているかどうかを判定し、FITが伝送されている場合には、クラス情報とバージョン情報（伝送系列情報）により、FITが属しているクラス（系列）と、そのバージョンを認識することができる。これにより、受信装置２０は、L1フレームのヘッダ部の伝送系列情報を参照して、そのヘッダ部に配置されたFITを取得（抽出）して処理をすべきかどうかを判定することが可能となる。
また、１つのブロードキャストストリームを複数のサービス事業者が利用する場合、サービス事業者ごとにクラスIDに、事業者IDの値を記述することが可能であり、受信装置２０は、この事業者IDを用いてフィルタリングを行うことで、効率的に所望のFITのみを取得することが可能となる。
（L1フレーム伝送方式の派生例）
図３は、L1フレーム伝送方式の派生例を説明する図である。
図３において、L1フレームのヘッダ部に、15ビットのFITバージョン情報が配置され、当該FITバージョン情報が、クラス数、クラスID、及び、バージョン情報から構成される点は、図２の構成と同様である。ただし、図３のFITバージョン情報において、クラスIDは、事業者ID（provider_id）と、配信クラスID（delivery_group_id）から構成されている。
事業者IDは、複数の異なるサービス事業者を識別するためのIDである。配信クラスIDは、FITの時系列に異なる伝送系列を識別するためのIDである。すなわち、クラスIDは、複数のサービス事業者と複数の時系列が異なる伝送系列を識別する情報から構成される。このように、当該FITの提供元であるサービス事業者を識別するIDと、FITの伝送周期を識別するための情報がクラスによって提供される。
なお、運用によっては、１つのサービス事業者と、１つの時系列に異なる伝送系列から構成されるようにしてもよい。ここで、クラスIDは、複数のサービス事業者と複数の時系列に異なる伝送系列を識別するためのIDであるが、運用によっては、サービスを受信するために必要な受信装置２０の性能を示すためのIDなど、他の伝送系列を示してもよい。なお、各要素のサイズ（ビット数）は運用の一例であって、実際のサイズは運用に応じて決定される。
（L2パケット伝送方式１）
図４は、L2パケット伝送方式１として、L2パケットのヘッダ部の拡張ヘッダを用いた伝送系列情報の伝送を説明する図である。
L2パケットは、レイヤ２のパケットであって、ヘッダ部とペイロード部から構成される。ここで、例えばデジタル放送の規格としてIP伝送方式が採用されている場合、L2パケットのペイロードには、１又は複数のIPパケットが配置され、カプセル化されている。IPパケットのデータとしては、例えば、ビデオやオーディオのデータのほか、シグナリングデータなどが配置される。
L2パケットのヘッダ部において、拡張ヘッダ（header extension）には、8ビットのタイプ情報（type）、16ビットの拡張タイプ情報（type extension）、及び、8ビットのデータバージョン情報（data version）が配置される。
タイプ情報は、当該L2パケットで伝送されるシグナリングデータのタイプを示す。L2パケットのペイロード部にFITが配置される場合、タイプ情報には、"FIT"を示すビット列が設定される。
拡張タイプ情報には、3ビットのクラス数（num_of_class）、及び、4ビットのクラスID（class_id）が含まれる。クラス数は、伝送されているFITのクラス（系列）の数を示す。クラスIDは、FITのクラス（系列）を識別するためのIDである。なお、拡張タイプ情報には、9ビットのリザーブド領域（reserved）が設けられている。
データバージョン情報は、FITのクラス（系列）ごとのバージョンを示すバージョン情報である。
このように、L2パケット伝送方式１では、L2パケットのヘッダ部の拡張ヘッダに、タイプ情報、クラス情報、及び、データバージョン情報が配置されている。そのため、受信装置２０は、L2パケットを取得した段階で、タイプ情報によりFITが伝送されているかどうかを判定し、FITが伝送されている場合には、クラス情報とバージョン情報（伝送系列情報）により、FITが属しているクラス（系列）と、そのバージョンを認識することができる。これにより、受信装置２０は、L2パケットのヘッダ部の拡張ヘッダの伝送系列情報を参照して、そのペイロード部に配置されるFITを取得（抽出）して処理すべきかどうかを判定することが可能となる。
また、１つのブロードキャストストリームを複数のサービス事業者が利用する場合、サービス事業者ごとにクラスIDに、事業者IDの値を記述することが可能であり、受信装置２０は、この事業者IDを用いてフィルタリングを行うことで、効率的に所望のFITのみを取得することが可能となる。
（L2パケット伝送方式１の派生例）
図５は、L2パケット伝送方式１の派生例を示す図である。
図５において、L2パケットのヘッダ部に、拡張ヘッダが配置され、当該拡張ヘッダが、タイプ情報、拡張タイプ情報、及び、データバージョン情報から構成される点は、図４の構成と同様である。ただし、図５の拡張タイプ情報には、グループ数（num_of_group）とグループID（group_id）が配置される。また、グループIDは、事業者ID（provider_id）と、配信クラスID（delivery_group_id）から構成されている。
事業者IDは、複数の異なるサービス事業者を識別するためのIDである。配信クラスIDは、FITの時系列に異なる伝送系列を識別するためのIDである。すなわち、クラスIDは、複数のサービス事業者と複数の時系列が異なる伝送系列を識別する情報から構成される。このように、当該FITの提供元であるサービス事業者を識別するIDと、FITの伝送周期を識別するための情報がクラスによって提供される。
なお、運用によっては、１つのサービス事業者と、１つの時系列に異なる伝送系列から構成されるようにしてもよい。ここで、クラスIDは、複数のサービス事業者と複数の時系列に異なる伝送系列を識別するためのIDであるが、運用によっては、サービスを受信するために必要な受信装置２０の性能を示すためのIDなど、他の伝送系列を示してもよい。なお、各要素のサイズ（ビット数）は運用の一例であって、実際のサイズは運用に応じて決定される。
（L2パケット伝送方式２）
図６は、L2パケット伝送方式２として、L2パケットのペイロード部のペイロードヘッダを用いた伝送系列情報の伝送を説明する図である。
L2パケットは、ヘッダ部とペイロード部から構成される。
L2パケットのペイロード部において、ペイロードヘッダ（payload header）には、8ビットのタイプ情報（type）、16ビットの拡張タイプ情報（type extension）、及び、8ビットのデータバージョン情報（data version）が配置される。
タイプ情報は、当該L2パケットのペイロード部で伝送されるシグナリングデータのタイプを示す。L2パケットのペイロード部にFITが配置される場合、タイプ情報には、"FIT"を示すビット列が設定される。
拡張タイプ情報は、3ビットのクラス数（num_of_class）、及び、4ビットのクラスID（class_id）が含まれる。クラス数は、伝送されているFITのクラス（系列）の数を示す。クラスIDは、FITのクラス（系列）を識別するためのIDである。なお、拡張タイプ情報には、9ビットのリザーブド領域（reserved）が設けられている。
データバージョン情報は、FITのクラス（系列）ごとのバージョンを示すバージョン情報である。
このように、L2パケット伝送方式２では、L2パケットのペイロード部のペイロードヘッダに、タイプ情報、クラス情報、及び、データバージョン情報が配置されている。そのため、受信装置２０は、L2パケットを取得した段階で、タイプ情報によりFITが伝送されているかどうかを判定し、FITが伝送されている場合には、クラス情報とバージョン情報（伝送系列情報）により、FITが属しているクラス（系列）と、そのバージョンを認識することができる。これにより、受信装置２０は、L2パケットのペイロード部のペイロードヘッダの伝送系列情報を参照して、そのペイロード部に配置されたFITを取得（抽出）して処理すべきかどうかを判定することが可能となる。
また、１つのブロードキャストストリームを複数のサービス事業者が利用する場合、サービス事業者ごとにクラスIDに、事業者IDの値を記述することが可能であり、受信装置２０は、この事業者IDを用いてフィルタリングを行うことで、効率的に所望のFITのみを取得することが可能となる。
（L2パケット伝送方式２の派生例）
図７は、L2パケット伝送方式２の派生例を示す図である。
図７において、L2パケットのペイロード部に、ペイロードヘッダが配置され、当該ペイロードヘッダが、タイプ情報、拡張タイプ情報、及び、データバージョン情報から構成される点は、図６の構成と同様である。ただし、図７の拡張タイプ情報には、グループ数（num_of_group）とグループID（group_id）が配置される。また、グループIDは、事業者ID（provider_id）と、配信クラスID（delivery_group_id）から構成されている。
事業者IDは、複数の異なるサービス事業者を識別するためのIDである。配信クラスIDは、FITの時系列に異なる伝送系列を識別するためのIDである。すなわち、クラスIDは、複数のサービス事業者と複数の時系列が異なる伝送系列を識別する情報から構成される。このように、当該FITの提供元であるサービス事業者を識別するIDと、FITの伝送周期を識別するための情報がクラスによって提供される。
なお、運用によっては、１つのサービス事業者と、１つの時系列に異なる伝送系列から構成されるようにしてもよい。ここで、クラスIDは、複数のサービス事業者と複数の時系列に異なる伝送系列を識別するためのIDであるが、運用によっては、サービスを受信するために必要な受信装置２０の性能を示すためのIDなど、他の伝送系列を示してもよい。なお、各要素のサイズ（ビット数）は運用の一例であって、実際のサイズは運用に応じて決定される。
＜３．運用例＞
次に、L1フレーム伝送方式とL2パケット伝送方式の具体的な運用例について説明する。
（１）運用例１
図８は、L1フレーム伝送方式を用いた運用例１を説明する図である。
図８において、レイヤ１として、「Ｌ」、「Ｍ」、「Ｓ」が記された四角は、L1フレームを表している。このL1フレームのヘッダ部には、FITが配置されているが、「Ｌ(long)」が記された四角は、受信装置２０側で、例えば10秒周期などの比較的長い周期で取得（更新）すべきFIT（以下、「長周期のFITL」ともいう）が配置されたL1フレームを意味している。
また、「Ｓ(short)」が記された四角は、受信装置２０側で、例えば100ミリ秒周期などの比較的短い周期で取得（更新）すべきFIT（以下、「短周期のFITS」ともいう）が配置されたL1フレームを意味している。さらに、「Ｍ(middle)」が記された四角は、例えば1秒周期などの「Ｌ」の周期と「Ｓ」の周期との間の周期で取得（更新）すべきFIT（以下、「中間周期のFITM」ともいう）が配置されたL1フレームを意味している。
以下、「Ｌ」が記されたL1フレームを、「L1フレームＬ」と記述する。同様に、「Ｍ」が記されたL1フレームを、「L1フレームＭ」と記述し、「Ｓ」が記されたL1フレームを、「L1フレームＳ」と記述する。また、図８において、時間の方向は、図中の左側から右側の方向とされる。
図８においては、L1フレームＳ，L1フレームＳ，L1フレームＭの伝送が３回繰り返された後、L1フレームＬが伝送される。その後、全ては図示していないが、同様に、２回のL1フレームＳの伝送と１回のL1フレームＭの伝送を、３回繰り返した後に、L1フレームＬを伝送することが繰り返される。
すなわち、時間的に連続して伝送される１０個のL1フレームのまとまりに注目すれば、短周期のFITSが配置されたL1フレームＳが６個伝送され、中間周期のFITMが配置されたL1フレームＭが３個伝送され、長周期のFITLが配置されたL1フレームＬが１個伝送されている。
換言すれば、L1フレームＬ，L1フレームＭ，L1フレームＳは、異なる周期で伝送されているが、L1フレームＳの伝送周期が最も短い周期となり、L1フレームＭの伝送周期がその次に短い周期となり、L1フレームＬの伝送周期が最も長い周期となっている。
ここで、受信装置２０においては、注目している処理対象のL1フレーム（以下、「対象L1フレーム」ともいう）のヘッダ部に配置されるFIT伝送フラグ（FIT_delivery_flag）を参照して、対象L1フレームでFITが伝送されているかどうかを判定する。図８の運用例１においては、すべてのL1フレームでFITが伝送されているので、FIT伝送フラグには、"TRUE"が設定されている。
また、ヘッダ部に配置されるFITバージョン情報（FIT_version）には、クラス情報とバージョン情報が含まれるので、受信装置２０は、対象L1フレームで伝送されているFITが属しているクラス（系列）とバージョンを認識することができる。
図８においては、L1フレームＬ，L1フレームＭ，L1フレームＳの３つの系列が伝送されているので、クラス数（num_of_class）には、"3"が設定される。したがって、図８においては、すべてのL1フレームのヘッダ部のFITバージョン情報で、クラス数として"3"が設定されている（図示は省略している）。また、クラスID（class_id）として、短周期のFITSには、"01"が設定され、中間周期のFITMには、"00"が設定され、長周期のFITLには、"10"が設定される。さらに、バージョン情報には、クラスごとに、FITの内容が更新される度に、例えば、１ずつインクリメントされた値が設定される。
ここで、時系列に並べられたL1フレームのうち、L1フレームＳに注目すれば、先頭のL1フレームＳが、対象L1フレームとなる場合、そのヘッダ部のFITバージョン情報には、"01"であるクラスIDと、"001"であるバージョン情報が設定されている。受信装置２０では、それらのクラス情報とバージョン情報を参照して、先頭のL1フレームＳで伝送される短周期のFITSを取得して記録（更新）すべきかどうかを判定する。
例えば、受信装置２０において、短周期のFITSが取得済みであって、そのバージョン情報として"001"が設定されている場合、先頭のL1フレームＳのヘッダ部に配置されたFITSを無視する。
なお、短周期のFITSが未取得である場合や、短周期のFITSが取得済みであるが、そのバージョン情報として"000"が設定されている場合などには、受信装置２０は、先頭のL1フレームＳのヘッダ部に配置されたFITSを取得して、記録（更新）することになる。
次に、先頭から２番目のL1フレームＳが、対象L1フレームとなる場合、そのヘッダ部のFITバージョン情報には、"01"であるクラスIDと、"001"であるバージョン情報が設定されている。受信装置２０では、それらのクラス情報とバージョン情報を参照することで、同一のバージョンのFITSが取得済みであることが認識されるので、２番目のL1フレームＳのヘッダ部に配置されたFITSを無視する。
同様に、先頭から４番目、５番目、及び、７番目のL1フレームＳが、対象L1フレームとなる場合、受信装置２０では、そのヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITSが取得済みであることが認識されるので、対象L1フレームのヘッダ部に配置されたFITSを無視する。
そして、先頭から８番目のL1フレームＳが、対象L1フレームとなる場合、そのヘッダ部のFITバージョン情報には、"002"であるバージョン情報が設定されており、１つ前にFITSを配置していた７番目のL1フレームＳにおける"001"であるバージョン情報が、インクリメントされている。この場合、受信装置２０は、FITSのバージョンが異なっていることを認識し、８番目のL1フレームＳのヘッダ部に配置されたFITSを取得して、記録（更新）することになる。
その後、先頭から１１番目、１２番目、１４番目、及び、それ以降のL1フレームＳが、対象L1フレームとなる場合、受信装置２０では、そのヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITSが取得済みであることが認識された場合、対象L1フレームのヘッダ部に配置されたFITSを無視する。一方、受信装置２０では、ヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、異なるバージョンのFITSが未取得であることが認識された場合、対象L1フレームのヘッダ部に配置されたFITSを取得して、記録（更新）することになる。
このように、短周期のFITSは、中間周期のFITMや長周期のFITLと比べて、例えば100ミリ秒周期などの短い周期で伝送されるので、受信装置２０が直ちに取得（更新）すべき情報（時間的な制限がある情報）を伝送する目的に利用することができる。例えば、このような時間的な制限がある情報としては、選局されたサービスの状況に応じて動的に更新すべき情報（動的パラメータ）などが該当する。
短周期のFITSには、時間的な制限がある情報を、A_descriptor()等のサービスレベル記述子として配置することができる。例えば、サービスステータス記述子（service status descriptor）が、FITSに配置されるようにすることで、受信装置２０は、サービス選局時に、短い周期で伝送されるFITSのバージョンが変化したときに、迅速にFITSを取得（更新）して、サービスの状態を確認することができる。
また、時系列に並べられたL1フレームのうち、L1フレームＭに注目すれば、先頭から３番目のL1フレームＭが、対象L1フレームとなる場合、そのヘッダ部のFITバージョン情報には、"00"であるクラスID、及び、"001"であるバージョン情報が設定されている。例えば、受信装置２０において、中間周期のFITMが取得済みであって、そのバージョン情報として"001"が設定されている場合、３番目のL1フレームＭのヘッダ部に配置されたFITMを無視する。
同様に、先頭から６番目のL1フレームＭが、対象L1フレームとなる場合、受信装置２０では、そのヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITMが取得済みであることが認識されるので、６番目のL1フレームＭのヘッダ部に配置されたFITMを無視する。
そして、先頭から９番目のL1フレームＭが、対象L1フレームとなる場合、そのヘッダ部のFITバージョン情報には、"002"であるバージョン情報が設定されており、１つ前にFITMを配置していた６番目のL1フレームＭにおける"001"であるバージョン情報が、インクリメントされている。この場合、受信装置２０は、FITMのバージョンが異なっていることを認識し、９番目のL1フレームＭのヘッダ部に配置されたFITMを取得して、記録（更新）することになる。
その後、先頭から１３番目、及び、それ以降のL1フレームＭが、対象L1フレームとなる場合、受信装置２０では、そのヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITMが取得済みであることが認識された場合、対象L1フレームのヘッダ部に配置されたFITMを無視する。一方、受信装置２０では、ヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、異なるバージョンのFITMが未取得であることが認識された場合、対象L1フレームのヘッダ部に配置されたFITMを取得して、記録（更新）することになる。
このように、中間周期のFITMは、例えば1秒周期などの短周期のFITSと長周期のFITLとの間の周期で伝送されるので、受信装置２０が直ちに取得（更新）する必要はないが、取得するまでの時間がかかり過ぎると不都合があるような情報（時間的な制限がある程度許容された情報）を伝送する目的に利用することができる。例えば、このような時間的な制限がある程度許容された情報としては、初期スキャン処理時に取得すべき情報（初期スキャンパラメータ）などが該当する。
中間周期のFITMは、時間的な制限がある程度許容された情報を、B_descriptor()，C_descriptor()，D_descriptor()等のサービスレベル記述子として配置することができる。例えば、サービス名称記述子（service name descriptor）、ケイパビリティ記述子（capability descriptor）、サービスブートストラップ記述子（service bootstrap descriptor）などが配置される。受信装置２０は、初期スキャン処理時に、中間周期のFITMを取得して、サービス名称記述子、ケイパビリティ記述子、及び、サービスブートストラップ記述子に記述された情報（初期スキャンパラメータ）を、選局情報として記録することができる。
また、時系列に並べられたL1フレームのうち、L1フレームＬに注目すれば、先頭から１０番目のL1フレームＬが、対象L1フレームとなる場合、そのヘッダ部のFITバージョン情報には、"10"であるクラスID、及び、"002"であるバージョン情報が設定されている。例えば、受信装置２０において、１つ前にFITLを配置していたL1フレームＬにおけるバージョン情報が"001"であった場合、バージョンの値がインクリメントされている。この場合、受信装置２０は、FITLのバージョンが異なっていることを認識し、１０番目のL1フレームＬのヘッダ部に配置されたFITLを取得して、記録（更新）することになる。
その後、それ以降のL1フレームＬが、対象L1フレームとなる場合、受信装置２０では、そのヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITLが取得済みであることが認識された場合、対象L1フレームのヘッダ部に配置されたFITLを無視する。一方、受信装置２０では、ヘッダ部のFITバージョン情報に設定されたクラス情報とバージョン情報を参照することで、異なるバージョンのFITLが未取得であることが認識された場合、対象L1フレームのヘッダ部に配置されたFITLを取得して、記録（更新）することになる。
このように、長周期のFITLは、短周期のFITSや中間周期のFITMと比べて、例えば10秒周期などの長い周期で伝送されるので、受信装置２０が特に急いで取得（更新）する必要がない情報（時間的な制限がない情報）を伝送する目的に利用することができる。例えば、このような時間的な制限がない情報としては、静的に更新すべき情報（静的パラメータ）が該当する。
長周期のFITLは、時間的な制限がない情報を、E_descriptor()，F_descriptor()等のサービスレベル記述子として配置することができる。例えば、シグナリングテンプレート記述子（signaling template）や、シグナリングオーバーインターネット記述子（signaling over internet）などが配置される。受信装置２０は、任意のタイミングで、長い周期で伝送される長周期のFITLを取得して、シグナリングテンプレート記述子やシグナリングオーバーインターネット記述子に記述された情報を記録することができる。
以上のように、L1フレーム伝送方式を用いた運用例１では、L1フレームのヘッダ部に配置されるFITバージョン情報に、伝送系列情報（クラス情報）を設定して、FITをクラスごとに複数の系列に分類することで、例えば、短周期のFITS（例えば100ミリ秒周期）や長周期のFITL（例えば10秒周期）、中間周期のFITM（例えば1秒周期）など、複数の伝送周期でFITを伝送することができる。また、伝送周期ごとに、FITに配置されるサービスレベル記述子が異なるようにすることで、例えば、時間的な制限がある情報や時間的な制限がない情報などを、用途に応じて適切なタイミングで伝送することができる。
これにより、クラス（系列）ごとに、FITに記述されるサービスレベル記述子を分類（設定）して、異なる伝送周期で伝送されるようにすることができるので、運用形態に応じたFITの伝送を行うことができる。その結果、運用形態に柔軟に対応することが可能となる。また、FITがクラスごとに複数の伝送周期で伝送されることから、FITの伝送帯域の削減を実現することができる。
（２）運用例２
図９は、L2パケット伝送方式を用いた運用例２を説明する図である。なお、運用例２では、L2パケット伝送方式２を代表して説明するものとする。
図９において、レイヤ２として、「Ｌ」、「Ｍ」、「Ｓ」が記された四角は、L2パケットを表しているが、その意味は、図８のL1フレームの場合と同様である。図９では、「Ｌ」、「Ｍ」、「Ｓ」が記されたL2パケットをそれぞれ、「L2パケットＬ」、「L2パケットＭ」、「L2パケットＳ」と記述する。すなわち、L2パケットＬには、例えば10秒周期などの長周期のFITLが配置され、L2パケットＭには、例えば1秒周期などの中間周期のFITMが配置され、L2パケットＳには、例えば100ミリ秒周期などの短周期のFITSが配置される。
図９においては、L2パケットＳ，L2パケットＳ，L2パケットＭの伝送が３回繰り返された後、L2パケットＬが伝送される。その後、全ては図示していないが、同様に、２回のL2パケットＳの伝送と１回のL2パケットＭの伝送を、３回繰り返した後に、L2パケットＬを伝送することが繰り返される。
すなわち、時間的に連続して伝送される１０個のL2パケットのまとまりに注目すれば、短周期のFITSが配置されたL2パケットＳが６個伝送され、中間周期のFITMが配置されたL2パケットＭが３個伝送され、長周期のFITLが配置されたL2パケットＬが１個伝送されている。
ここで、受信装置２０においては、注目している処理対象のL2パケット（以下、「対象L2パケット」ともいう）のペイロード部のペイロードヘッダに配置されるタイプ情報（type）を参照して、対象L2パケットでFITが伝送されているかどうかを判定する。図９の運用例２においては、すべてのL2パケットでFITが伝送されているので、タイプ情報には、"FIT"を示すビット列が設定されている。
また、ペイロードヘッダに配置される拡張タイプ情報には、クラス情報が含まれ、データバージョン情報には、バージョン情報が含まれているので、受信装置２０は、対象L2パケットで伝送されているFITが属しているクラス（系列）とバージョンを認識することができる。
図９においては、L2パケットＬ，L2パケットＭ，L2パケットＳの３つの系列が伝送されているので、すべてのL2パケットのペイロード部のペイロードヘッダにおいて、クラス数（num_of_class）には、"3"が設定される（図示は省略している）。また、図９においては、図８と同様に、クラスID（class_id）として、短周期のFITSには、"01"が設定され、中間周期のFITMには、"00"が設定され、長周期のFITLには、"10"が設定される。さらに、バージョン情報には、クラスごとに、FITの内容が更新される度に、例えば、１ずつインクリメントされた値が設定される。
ここで、時系列に並べられたL2パケットのうち、L2パケットＳに注目すれば、先頭のL2パケットＳ，並びに、先頭から２番目、４番目、５番目、及び、７番目のL2パケットＳが、対象L2パケットとなる場合、そのペイロード部のペイロードヘッダには、"01"であるクラスIDと、"001"であるバージョン情報が設定されている。受信装置２０では、そのペイロードヘッダに設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITSが取得済みであることが認識されるので、対象L2パケットのペイロード部に配置されたFITSを無視する。
そして、先頭から８番目のL2パケットＳが、対象L2パケットとなる場合、そのペイロード部のペイロードヘッダには、"002"であるバージョン情報が設定されており、１つ前にFITSを配置していた７番目のL2パケットＳにおける"001"であるバージョン情報が、インクリメントされている。この場合、受信装置２０は、FITSのバージョンが異なっていることを認識し、８番目のL2パケットＳのペイロード部に配置されたFITSを取得して、記録（更新）することになる。
その後、先頭から１１番目、１２番目、１４番目、及び、それ以降のL2パケットＳが、対象L2パケットとなる場合、受信装置２０では、そのペイロード部のペイロードヘッダに設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITSが取得済みであることが認識された場合、L2パケットのペイロード部に配置されたFITSを無視する。一方、受信装置２０では、ペイロード部のペイロードヘッダのクラス情報とバージョン情報を参照することで、異なるバージョンのFITSが未取得であることが認識された場合、対象L2パケットのペイロード部に配置されたFITSを取得して、記録（更新）することになる。
このように、短周期のFITSは、中間周期のFITMや長周期のFITLと比べて、例えば100ミリ秒周期などの短い周期で伝送されるので、受信装置２０が直ちに取得（更新）すべき情報（時間的な制限がある情報）を伝送する目的に利用することができる。例えば、このような時間的な制限がある情報としては、選局されたサービスの状況に応じて動的に更新すべき情報（動的パラメータ）などが該当する。
短周期のFITSには、時間的な制限がある情報を、A_descriptor()，F_descriptor()等のサービスレベル記述子として配置することができる。例えば、サービスステータス記述子（service status descriptor）が、FITSに配置されるようにすることで、受信装置２０は、サービス選局時に、短い周期で伝送されるFITSのバージョンが変化したときに、迅速にFITSを取得（更新）して、サービスの状態を確認することができる。
また、時系列に並べられたL2パケットのうち、L2パケットＭに注目すれば、先頭から３番目、及び、６番目のL2パケットＭが、対象L2パケットとなる場合、そのペイロード部のペイロードヘッダには、"00"であるクラスIDと、"001"であるバージョン情報が設定されている。受信装置２０では、そのペイロードヘッダに設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITMが取得済みであることが認識されるので、対象L2パケットのペイロード部に配置されたFITMを無視する。
そして、先頭から９番目のL2パケットＭが、対象L2パケットとなる場合、そのペイロード部のペイロードヘッダには、"002"であるバージョン情報が設定されており、１つ前にFITMを配置していた６番目のL2パケットＭにおける"001"であるバージョン情報が、インクリメントされている。この場合、受信装置２０は、FITMのバージョンが異なっていることを認識し、９番目のL2パケットＭのペイロード部に配置されたFITMを取得して、記録（更新）することになる。
その後、先頭から１３番目、及び、それ以降のL2パケットＭが、対象L2パケットとなる場合、受信装置２０では、そのペイロード部のペイロードヘッダに設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITMが取得済みであることが認識された場合、対象L2パケットのペイロード部に配置されたFITMを無視する。一方、受信装置２０では、ペイロード部のペイロードヘッダに設定されたクラス情報とバージョン情報を参照することで、異なるバージョンのFITMが未取得であることが認識された場合、対象L2パケットＭのペイロード部に配置されたFITMを取得して、記録（更新）することになる。
このように、中間周期のFITMは、例えば1秒周期などの短周期のFITSと長周期のFITLとの間の周期で伝送されるので、受信装置２０が直ちに取得（更新）する必要はないが、取得するまでの時間がかかり過ぎると不都合があるような情報（時間的な制限がある程度許容された情報）を伝送する目的に利用することができる。例えば、このような時間的な制限がある程度許容された情報としては、初期スキャン処理時に取得すべき情報（初期スキャンパラメータ）などが該当する。
中間周期のFITMは、時間的な制限がある程度許容された情報を、A_descriptor()，B_descriptor()，C_descriptor()，D_descriptor()，F_descriptor()等のサービスレベル記述子として配置することができる。例えば、サービス名称記述子（service name descriptor）、ケイパビリティ記述子（capability descriptor）、サービスブートストラップ記述子（service bootstrap descriptor）などが配置される。受信装置２０は、初期スキャン処理時に、中間周期のFITMを取得して、サービス名称記述子、ケイパビリティ記述子、及び、サービスブートストラップ記述子に記述された情報（初期スキャンパラメータ）を、選局情報として記録することができる。
なお、中間周期のFITMのクラスIDである"00"を、マジックナンバーとすることで、受信装置２０における初期スキャン処理において、"00"であるクラスIDのFITMのみを取得すればよいことになるので、受信装置２０は、効率的に、かつ、迅速に初期スキャン処理を行うことができる。
また、時系列に並べられたL2パケットのうち、L2パケットＬに注目すれば、先頭から１０番目のL2パケットＬが、対象L2パケットとなる場合、そのペイロード部のペイロードヘッダには、"10"であるクラスIDと、"002"であるバージョン情報が設定されている。例えば、受信装置２０において、１つ前にFITLを配置していたL2パケットＬにおけるバージョン情報が"001"であった場合、バージョンの値がインクリメントされている。この場合、受信装置２０は、FITLのバージョンが異なっていることを認識し、１０番目のL2パケットＬのペイロード部に配置されたFITLを取得して、記録（更新）することになる。
その後、それ以降のL2パケットＬが、対象L2パケットとなる場合、受信装置２０では、そのペイロード部に配置されるペイロードヘッダに設定されたクラス情報とバージョン情報を参照することで、同一のバージョンのFITLが取得済みであることが認識された場合、対象L2パケットのペイロード部に配置されたFITLを無視する。一方、受信装置２０では、ペイロード部のペイロードヘッダに設定されたクラス情報とバージョン情報を参照することで、異なるバージョンのFITLが未取得であることが認識された場合、対象L2パケットのペイロード部に配置されたFITLを取得して、記録（更新）することになる。
このように、長周期のFITLは、短周期のFITSや中間周期のFITMと比べて、例えば10秒周期などの長い周期で伝送されるので、受信装置２０が特に急いで取得（更新）する必要がない情報（時間的な制限がない情報）を伝送する目的に利用することができる。例えば、このような時間的な制限がない情報としては、静的に更新すべき情報（静的パラメータ）が該当する。
長周期のFITLは、時間的な制限がない情報を、E_descriptor()等のサービスレベル記述子として配置することができる。例えば、シグナリングテンプレート記述子（signaling template descriptor）などが配置される。受信装置２０は、任意のタイミングで、長い周期で伝送される長周期のFITLを取得して、シグナリングテンプレート記述子に記述された情報を記録することができる。
なお、図８の運用例１では、A_descriptor()は、短周期のFITSのみに配置され、F_descriptor()は、長周期のFITLのみに配置されるなど、FITの系列ごとに、１又は複数のサービスレベル記述子が関連付けられていた。一方、図９の運用例２においては、A_descriptor()とF_descriptor()は、短周期のFITSと中間周期のFITMの両方のFITに配置されており、１又は複数のサービスレベル記述子が、複数のクラス（系列）にまたがって関連付けられている。
前者の運用例１（図８）の場合、FITのクラス（系列）ごとに、サービスレベル記述子が異なっているため、同一のFITのクラス（系列）内で、最新のサービスレベル記述子での更新（上書き）処理を行えば、常に最新のサービスレベル記述子を参照することができる。一方、後者の運用例２（図９）の場合には、サービスレベル記述子が複数のクラス（系列）に属しているので、クラス（系列）ごとに優先度を与えて、優先度の高いクラス（系列）で伝送されるサービスレベル記述子により、優先度の低いクラス（系列）で伝送されるサービスレベル記述子を更新（上書き）できるようにすればよい。
例えば、クラスIDの値が大きいほど優先度が高くなるように設定すれば、"10"であるクラスIDの長周期のFITLが最も優先度が高く、"01"であるクラスIDの短周期のFITS、"00"であるクラスIDの中間周期のFITMの順に優先度が低くなる。したがって、図９の運用例２においては、A_descriptor()とF_descriptor()は、短周期のFITSと中間周期のFITMの両方に配置されているが、中間周期のFITMよりも優先度の高い短周期のFITSに配置されるA_descriptor()又はF_descriptor()により、中間周期のFITMに配置されるA_descriptor()又はF_descriptor()を更新（上書き）することができる。
このように、例えばクラスIDの値が大きいほど優先度が高くなるように設定するなど、クラス（系列）ごとに優先度を与えて、優先度に応じた上書き処理を行うことで、不要な上書き処理の繰り返しを削減することができる。
以上のように、L2パケット伝送方式２を用いた運用例２では、L2パケットのペイロード部のペイロードヘッダに、伝送系列情報（クラス情報）を設定して、FITをクラスごとに複数の系列に分類することで、例えば、短周期のFITS（例えば100ミリ秒周期）や長周期のFITL（例えば10秒周期）、中間周期のFITM（例えば1秒周期）など、複数の伝送周期でFITを伝送することができる。また、伝送周期ごとに、FITに配置されるサービスレベル記述子が異なるようにすることで、例えば、時間的な制限がある情報や時間的な制限がない情報などを、用途に応じて適切なタイミングで伝送することができる。
これにより、クラス（系列）ごとに、FITに記述されるサービスレベル記述子を分類（設定）して、異なる伝送周期で伝送されるようにすることができるので、運用形態に応じたFITの伝送を行うことができる。その結果、運用形態に柔軟に対応することが可能となる。また、FITがクラスごとに複数の伝送周期で伝送されることから、FITの伝送帯域の削減を実現することができる。
なお、運用例２では、L2パケット伝送方式２として、ペイロードヘッダに伝送系列情報（クラス情報とバージョン情報）が配置される場合を説明したが、伝送系列情報が、ヘッダ部の拡張ヘッダに配置される点以外については、L2パケット伝送方式１を用いた場合も同様とされる。また、図８の運用例１と、図９の運用例２においては、説明を簡略化するため、クラスIDを2ビットのビット列で表し、バージョン情報を3ビットのビット列で表している。
（３）運用例３
（放送サービスの伝送形態１）
図１０は、１つの伝送帯域を１つのサービス事業者のみが利用する場合の伝送形態を模式的に示した図である。
放送サービスに割り当てられた周波数帯域は、あらかじめ定められた周波数帯域（例えば6MHz帯域）ごとに分割され、電波周波数を管理する当局などが物理チャンネル番号を割り当てることにより、管理される。図１０においては、物理チャンネル１を放送局Ａ（Broadcaster A）、物理チャンネル２を放送局Ｂ（Broadcaster B）が占有する形態で割り当てられている。放送局Ａは、チャンネルに10.1を付与してサービスを提供する。一方で、放送局Ｂは、チャンネルに11.1及び11.2を付与してサービスを提供する。
ここで、「10」及び「11」は、サービス事業者ごとに割り当てられるメジャーチャンネル番号を示し、このメジャーチャンネル番号と小数点に続く数字は、マイナーチャンネル番号を示す。メジャーチャンネル番号は、サービス地域において、サービス事業者を識別するための番号であり、マイナーチャンネル番号は、サービス事業者ごとにチャンネルを識別するための番号である。
サービス事業者は、１又は複数のチャンネルを提供することができる。図１０の例では、放送局Ａは、１つのチャンネル（10.1）を放送し、放送局Ｂは、２つのチャンネル（11.1及び11.2）を放送している。
図１０の放送サービスの伝送形態では、１つの伝送帯域を、１つのサービス事業者のみが利用することから、当該伝送帯域によって伝送されるFITは、１つのサービス事業者が提供するサービスの構成情報を記述すればよい。すなわち、当該サービス事業者が独立してFITを作成（生成）、管理、運用すればよいことになる。
（放送サービスの伝送形態２）
図１１は、１つの伝送帯域を複数のサービス事業者が利用する場合の伝送形態を模式的に示した図である。
図１１においては、１つの伝送帯域（例えば6MHz帯域）を、複数のサービス事業者が共同で利用する場合を示している。これは、放送サービスに割り当てられた周波数帯域が、図１０の伝送形態と同様に、6MHzごとに分割されて管理、利用されるが、昨今の物理層の伝送技術や音声、映像データを圧縮する技術の向上などにより、周波数の利用効率が高まることによって、従来と同じ伝送帯域で多くのサービスが伝送可能になることが見込まれることが影響している。また、電波周波数を管理する当局から効率的に電波を利用することが要請されており、今後の放送サービスにおいては、複数のサービス事業者が１つの伝送帯域を共用することが求められる。
図１１には、物理チャンネル１を、放送局Ａ（Broadcaster A）と放送局Ｂ（Broadcaster B）が共同で利用する例を示している。放送局Ａが、チャンネルに10.1を付与し、放送局Ｂが、チャンネルに11.1及び11.2を付与してサービスを提供する形態は、図１０の伝送形態と同様である。
図１１の放送サービスの伝送形態では、複数のサービス事業者が１つの伝送帯域を共用することから、当該伝送帯域によって伝送されるFITには、複数のサービス事業者が提供するサービスの構成情報を記述しなければならない。図１１の放送サービスの伝送形態において、図１０の伝送形態と同様に、当該伝送帯域によって放送するサービスを１つのFITによって記述すると、送出側（送信装置１０側）の設備によって、複数のサービス事業者を横断してサービスを管理、運用しなければならないという問題点がある。
（FITの管理、運用例）
図１２は、１つの伝送帯域を複数のサービス事業者が共同で利用する場合の送出処理（送信処理）を説明する図である。
図１２においては、１つの伝送帯域によって放送局（BC1：Broadcaster 1）がチャンネル10.1及び10.2を放送し、放送局（BC2：Broadcaster 2）がチャンネル11.1を放送する例を示している。
放送局（BC1）及び放送局（BC2）は、各サービスを構成するコンポーネントを重畳して放送送出設備に配信するのと並行して、当該サービスの構成情報が記述されたFITを生成して配信する。すなわち、FITを伝送するLLSシグナリングデータのストリームには、放送局（BC1）のサービス構成情報が記述されたFITと、放送局（BC2）のサービス構成情報が記述されたFITが伝送される。
図１２の送出処理（送信処理）においては、放送局（BC1）及び放送局（BC2）が、それぞれのサービス構成に基づいたFITを生成し、放送送出機（送信装置１０）によって、サービスコンポーネント（コンポーネント）、サービスメタデータ（メタデータ）、及び、FITを送出する。つまり、各サービス事業者が、独立してサービスを運用する形態である。本送出方式では、FITがどのサービス事業者から提供されるのかを示す情報として、LLSパケットヘッダとFITの共通パラメータに事業者ID（provider_id）を記述するが、その詳細は、図１３を参照して説明する。
（FITとサービスコンポーネントの関係）
図１３は、１つの伝送帯域を複数のサービス事業者が共同で利用する場合のFITとサービスコンポーネント（コンポーネント）の関係を説明する図である。
図１３において、１つの伝送帯域は、ブロードキャストストリーム（Broadcaster Stream）により表され、さらに、PLP（Physical Layer Pipe）によって、１又は複数のROUTEセッションが伝送される。ROUTEセッションによって各サービスのコンポーネントが伝送される。各サービスには、サービスを識別するためのサービスIDが付与され、さらにサービス事業者ごとに事業者ID（provider_id）が付与される。
FITは、LLSシグナリングデータのストリームで伝送される。LLSシグナリングデータは、PLPによって、L2パケット（レイヤ２のパケット）で伝送される。ただし、運用によっては、LLSシグナリングデータを、L1フレーム（レイヤ１のフレーム）、あるいはIPパケット、UDPパケット、又はROUTEパケットによりパケット化して伝送されるようにしてもよい。
LLSシグナリングデータのストリームで伝送されるFITは、LLSヘッダが付加されたパケットにより伝送される。このLLSヘッダには、図５又は図７に示したグループID（group_id）の事業者ID（provider_id）によって、当該FITとサービス事業者が関連付けられる。また、図１４又は図２１に示したFITにも、事業者ID（provider_id）が記述することができるため、FITとサービス事業者が関連付けられる。
この運用例３においては、受信装置２０は、LLSヘッダによって当該パケットによって伝送されるタイプがシグナリング（LLSシグナリングデータ）であって、FITであること、さらに、シグナリングがFITの場合に、FITを提供するサービス事業者と伝送周期系列を認識することができるので、効率的にフィルタリングを行うことができる。すなわち、受信装置２０は、所望のFITのみを容易に取得することができる。
なお、図１３のFITには、共通パラメータ部に、事業者ID（provider_id）が配置されている。これは、ストリームとの関連付けを行うためである。また、図１３のFITにおいて、事業者ごとのプロバイダループは規定していないが、共通パラメータ部に、事業者IDの代わりに、プロバイダループが配置されるようにしてもよい。
＜４．シンタックスの例＞
（FITのシンタックス）
図１４は、バイナリ形式のFITのシンタックスの例を示す図である。
8ビットのFIT_protocol_versionには、プロトコルのバージョン情報が指定される。16ビットのBroadcast_stream_idには、ブロードキャストストリームIDが指定される。
8ビットのnum_servicesには、サービスの個数が指定される。このサービスの個数に応じて、サービスループが繰り返される。4ビットのclass_idには、クラスIDが指定される。8ビットのversionには、FITのバージョンが指定される。サービスループには、以下の内容が配置される。
16ビットのservice_idには、対象のサービスのサービスIDが指定される。16ビットのprovider_idには、事業者IDが指定される。5ビットのservice_categoryには、対象のサービスのカテゴリが指定される。例えば、カテゴリとしては、NRT(Non Real Time)サービスや、ESG(Electronic Service Guide)サービス等が指定される。1ビットのsp_indicatorには、対象のサービスの保護を示す暗号化情報が指定される。
1ビットのSLS_simpleserviceには、対象のサービスが、ベーシックサービスであるか、あるいはリッチービスであるかを示す。例えば、SLS_simpleserviceとしては、ベーシックサービスの場合には"TRUE"が指定され、リッチサービスの場合には"FALSE"が指定される。
ここで、ベーシックサービスとは、サービスを構成するコンポーネントのストリームが、MIMEタイプにより個別に識別可能なサービスである。対象のサービスがベーシックサービスである場合、SLSシグナリングデータのうち、MPDとLSIDを取得することで、コンポーネントのストリームに接続することができる。また、リッチサービスとは、ベーシックサービス以外のサービスである。対象のサービスがリッチサービスである場合、コンポーネントのストリームに接続するためには、すべてのSLSシグナリングデータが必要となる。
4ビットのnum_srv_level_descriptorには、サービスレベルの記述子の個数が指定される。このサービスレベルの記述子の個数に応じて、サービスレベル記述子ループが繰り返される。サービスレベル記述子ループには、サービスレベル記述子（srv_level_descriptor()）が配置される。
このサービスレベル記述子としては、例えば、サービスステータス記述子、サービス名称記述子、ケイパビリティ記述子、サービスブートストラップ記述子、シグナリングテンプレート記述子、又は、シグナリングオーバーインターネット記述子などが配置される。なお、サービスレベル記述子の詳細な構造は、図１５乃至図２０のシンタックスを参照して後述する。
サービスループの次には、1ビットのnum_FIT_level_descriptorが配置される。num_FIT_level_descriptorには、FITレベルの記述子の個数が指定される。このFITレベルの記述子の個数に応じて、FITレベル記述子ループが繰り返される。FITレベル記述子ループには、FITレベル記述（FIT_level_descriptor()）が配置される。
なお、図１４において、SLS_simpleserviceの次には、1ビットのリザーブド領域（reserved）が設けられている。また、サービスレベル記述子ループと、FITレベル記述子ループの次には、4ビットのリザーブド領域（reserved）がそれぞれ設けられている。
次に、図１５乃至図２０を参照して、図１４のサービスレベル記述子ループに配置される、サービスレベル記述子の詳細な構造について説明する。
（サービスステータス記述子のシンタックス）
図１５は、バイナリ形式のサービスステータス記述子（service_status_descriptor）のシンタックスの例を示す図である。
8ビットのdescriptor_tagには、各記述子を識別するための記述子タグが指定される。ここでは、サービスステータス記述子の記述子タグが指定される。8ビットのdescriptor_lengthには、このフィールドよりも後に続くデータバイト数を書き込む領域とする記述子長が指定される。ここでは、サービスステータス記述子の記述子長が指定される。
8ビットのSLS_data_versionには、SLSシグナリングデータのバージョン情報が指定される。3ビットのservice_statusには、対象のサービスのステータスが指定される。例えば、ステータスとしては、対象のサービスが提供中であることを示すアクティブ状態（active）や、対象のサービスが休止されていることを示す非アクティブ状態（inactive）などが指定される。
なお、service_statusの次には、5ビットのリザーブド領域（reserved）が設けられている。
（サービス名称記述子のシンタックス）
図１６は、バイナリ形式のサービス名称記述子（service_name_descriptor）のシンタックスの例を示す図である。
8ビットのdescriptor_tagと、8ビットのdescriptor_lengthには、サービス名称記述子の記述子タグと、記述子長が指定される。
24ビットのISO_639_language_codeには、ISO 639規格に準拠した言語のコードが指定される。3ビットのshort_service_name_lengthには、ショートサービス名の長さが指定される。16*Nビットのshort_service_nameには、ショートサービス名が指定される。
なお、short_service_name_lengthの次には、5ビットのリザーブド領域（reserved）が設けられている。
（ケイパビリティ記述子のシンタックス）
図１７は、バイナリ形式のケイパビリティ記述子（capability_descriptor）のシンタックスの例を示す図である。
8ビットのdescriptor_tagと、8ビットのdescriptor_lengthには、ケイパビリティ記述子の記述子タグと、記述子長が指定される。
8ビットのcapability_codeには、１つのサービスを複数の異なるターゲットに対して提供するためのケイパビリティコードが指定される。例えば、ケイパビリティコードとしては、"2K"や"4K"等が指定される。
例えば、同一のサービス（例えば番組）を、受信環境が不安定なモバイル受信機向けには、高ロバストネスの２Ｋ解像度（横2000×縦1000ピクセル程度の解像度）の映像と音声で配信する一方、受信環境が安定している固定受信機向けには、ロバストネス性能は低いが、４Ｋ解像度（横4000×縦2000ピクセル程度の解像度）の映像と高音質の音声で配信する場合などが想定される。
（サービスブートストラップ記述子のシンタックス）
図１８は、バイナリ形式のサービスブートストラップ記述子（service_bootstrap_descriptor）のシンタックスの例を示す図である。
8ビットのdescriptor_tagと、8ビットのdescriptor_lengthには、サービスブートストラップ記述子の記述子タグと、記述子長が指定される。
1ビットのIP_version_flagには、IPパケットのバージョンを示すフラグが指定される。SLS_src_IP_addr_flagには、IPパケットの送信元（source）のIPアドレスを示すフラグが指定される。6ビットのリザーブド領域の次には、SLS_src_IP_addr_flagが、IPアドレスが存在していることを示している場合、32ビット又は128ビットのSLS_dst_IP_addrとして、送信元（source）のIPアドレスが指定される。
32ビット又は128ビットのSLS_dst_IP_addrには、宛先（destination）のIPアドレスが指定される。16ビットのSLS_dst_port_numには、ポート番号が指定される。16ビットのSLS_TSIには、TSI(Transport Session Identifier)が指定される。また、8ビットのSLS_PLP_idには、SLSシグナリングデータが伝送されるPLP(Physical Layer Pipe)を識別するためのIDが指定される。
これらのSLSシグナリングデータを取得するためのIPアドレス、ポート番号、TSI、及び、PLP IDにより、SLSブートストラップ情報が形成される。
（シグナリングテンプレート記述子のシンタックス）
図１９は、バイナリ形式のシグナリングテンプレート記述子（signaling_template_descriptor）のシンタックスの例を示す図である。
8ビットのdescriptor_tagと、8ビットのdescriptor_lengthには、シグナリングテンプレート記述子の記述子タグと、記述子長が指定される。
4ビットのencoding_typeには、エンコードのタイプ情報が指定される。16ビットのtemplate_lengthには、このフィールドよりも後に続くデータバイト数を書き込む領域として、シグナリングテンプレート長が指定される。8*Nビットのtemplateには、シグナリングテンプレートが配置される。
ここで、シグナリングテンプレートは、プラットフォームで共通となる継続的に利用可能な情報をテンプレートとして提供したものである。実際に利用可能となるシグナリングデータとの差分の情報は、差分情報として提供されることになる。ただし、XML(Extensible Markup Language)形式のシグナリングデータのテンプレートを配置する場合には、所定の変換方式に従い、テキスト形式をバイナリ形式に変換してから配置することになる。
（シグナリングオーバーインターネット記述子のシンタックス）
図２０は、バイナリ形式のシグナリングオーバーインターネット記述子（signaling_over_internet_descriptor）のシンタックスの例を示す図である。
8ビットのdescriptor_tagと、8ビットのdescriptor_lengthには、シグナリングオーバーインターネット記述子の記述子タグと、記述子長が指定される。
16ビットのuri_lengthには、このフィールドよりも後に続くデータバイト数を書き込む領域として、URI(Uniform Resource Identifier)長が指定される。
8*NビットのSLS_uriには、SLSシグナリングデータを通信経由で取得する場合のURIが配置される。例えば、SLS_uriには、インターネット９０を介してサーバ３０により配信されるSLSシグナリングデータを取得するためのURIが指定される。ただし、テキスト形式の文字列からなるURIを配置する場合には、所定の変換方式に従い、テキスト形式をバイナリ形式に変換してから配置することになる。
（FITのシンタックスの他の例）
図２１は、FITのシンタックスの他の例を示す図である。
図２１のFITのシンタックスは、図１４のFITのシンタックスと比べて、4ビットのnum_total_classと、4ビットのreservedが追加されている点が異なっている。
num_total_classには、FITに指定するクラスの総数が指定される。
なお、図２１において、num_total_classとreservedが追加された以外については、図１４のFITのシンタックスと同様であるため、その説明は省略する。
なお、図１４乃至図２１において、FITとサービスレベル記述子がバイナリ形式で記述された場合を例示したが、FITとサービスレベル記述子は、例えば、XML形式等のマークアップ言語により記述されるようにしてもよい。また、図１４乃至図２１に示したFITとサービスレベル記述子のシンタックスは一例であって、他のシンタックスが採用されるようにしてもよい。例えば、図１４や図２１のFITにおいて、class_idとversionを配置しない構造を採用することもできる。
＜５．各装置の構成＞
次に、図１の伝送システムを構成する、送信装置１０と受信装置２０の詳細な構成を説明する。
（送信装置の構成）
図２２は、図１の送信装置１０の構成例を示す図である。
図２２において、送信装置１０は、コンポーネント取得部１１１、エンコーダ１１２、シグナリング生成部１１３、シグナリング処理部１１４、パケット生成部１１５、フレーム生成部１１６、及び、送信部１１７から構成される。
コンポーネント取得部１１１は、外部のサーバや内蔵するストレージ、あるいはビデオカメラやマイクロフォン等から、ビデオやオーディオ、字幕等のコンポーネントのデータを取得し、エンコーダ１１２に供給する。
エンコーダ１１２は、コンポーネント取得部１１１から供給される、ビデオやオーディオ、字幕等のデータを、MPEG(Moving Picture Experts Group)等の符号化方式に準拠して符号化し、パケット生成部１１５に供給する。
シグナリング生成部１１３は、外部のサーバや内蔵するストレージ等から、シグナリングデータを生成するための素データを取得する。シグナリング生成部１１３は、シグナリングデータの素データを用いて、シグナリングデータを生成し、シグナリング処理部１１４に供給する。ここでは、シグナリングデータとして、LLSシグナリングデータと、SLSシグナリングデータが生成される。
シグナリング処理部１１４は、シグナリング生成部１１３から供給されるシグナリングデータを処理し、パケット生成部１１５又はフレーム生成部１１６に供給する。
すなわち、シグナリング処理部１１４は、L1フレーム伝送方式が用いられる場合、LLSシグナリングデータのうち、FITを、フレーム生成部１１６に供給するとともに、FIT以外のLLSシグナリングデータと、SLSシグナリングデータを、パケット生成部１１５に供給する。また、シグナリング処理部１１４は、L2パケット伝送方式が用いられる場合、LLSシグナリングデータと、SLSシグナリングデータを、パケット生成部１１５に供給する。
パケット生成部１１５は、エンコーダ１１２から供給されるコンポーネントのデータと、シグナリング処理部１１４から供給されるシグナリングデータを用い、IPパケットを生成する。また、パケット生成部１１５は、１又は複数のIPパケットをカプセル化することで、L2パケットを生成し、フレーム生成部１１６に供給する。
ただし、パケット生成部１１５は、L2パケット伝送方式１が用いられる場合、L2パケットのヘッダ部の拡張ヘッダに、タイプ情報、クラス情報、及び、データバージョン情報が配置されるようにする。また、パケット生成部１１５は、L2パケット伝送方式２が用いられる場合、L2パケットのペイロード部のペイロードヘッダに、タイプ情報、クラス情報、及び、データバージョン情報が配置されるようにする。
そして、パケット生成部１１５は、L2パケット伝送方式１又はL2パケット伝送方式２が用いられる場合に、FITを伝送するときには、タイプ情報に、"FIT"を示すビット列を設定するとともに、クラス情報とデータバージョン情報（バージョン情報）を設定して、それらの伝送系列情報に応じた伝送系列でL2パケットが伝送されるようにする。なお、この場合、FITは、L2パケットのペイロード部に配置される。
フレーム生成部１１６は、パケット生成部１１５から供給される、複数のL2パケットをカプセル化することで、L1フレームを生成し、送信部１１７に供給する。
ただし、フレーム生成部１１６は、L1フレーム伝送方式が用いられる場合、L1フレームのヘッダ部に、FIT伝送フラグ、クラス情報、及び、バージョン情報が配置されるようにする。そして、フレーム生成部１１６は、L1フレーム伝送方式が用いられる場合に、FITを伝送するときには、FIT伝送フラグに、"TRUE"を設定するとともに、クラス情報とバージョン情報を設定して、それらの伝送系列情報に応じた伝送系列でL1フレームが伝送されるようにする。なお、この場合、FITは、L1フレームのヘッダ部に配置される。
送信部１１７は、フレーム生成部１１６から供給されるL1フレームに対して、例えば、符号化、OFDM(Orthogonal Frequency Division Multiplexing)等のデジタル変調、RF（Radio Frequency）帯へのアップコンバージョン、又は電力増幅などの処理を行い、アンテナ１１８を介して、デジタル放送信号として送信する。
（受信装置の構成）
図２３は、図１の受信装置２０の構成例を示す図である。
図２３において、受信装置２０は、チューナ２１２、デマルチプレクサ２１３、制御部２１４、NVRAM２１５、入力部２１６、通信部２１７、デコーダ２１８、及び、出力部２１９から構成される。
チューナ２１２は、制御部２１４からの制御に従い、アンテナ２１１で受信されたデジタル放送信号から所定の周波数チャンネルの成分について同調を行う。また、チューナ２１２は、制御部２１４からの制御に従い、同調されたデジタル放送信号の復調処理を行う。この復調処理では、デジタル放送信号として受信されたL1フレームに対する復調処理が行われ、復調の結果得られるストリームが、デマルチプレクサ２１３に供給される。
デマルチプレクサ２１３は、制御部２１４からの制御に従い、チューナ２１２から供給されるストリームを、ビデオやオーディオ、字幕等のコンポーネントのデータと、シグナリングデータに分離する。デマルチプレクサ２１３は、コンポーネントのデータをデコーダ２１８に供給し、シグナリングデータを制御部２１４に供給する。
制御部２１４は、受信装置２０の各部の動作を制御する。また、制御部２１４は、デマルチプレクサ２１３から供給されるシグナリングデータに基づいて、デマルチプレクサ２１３を制御し、ビデオやオーディオ、字幕等のコンポーネントのデータが、デコーダ２１８に供給されるようにする。また、制御部２１４は、デマルチプレクサ２１３から供給されるシグナリングデータに基づいて、通信部２１７を制御する。
ここで、制御部２１４は、L1フレーム伝送方式が用いられる場合、チューナ２１２により処理されるL1フレームのヘッダ部に、FIT伝送フラグ、クラス情報、及び、バージョン情報が配置されているので、FIT伝送フラグに"TRUE"が設定されているときには、伝送系列情報に従い、ヘッダ部に配置されているFITを取得する。
また、制御部２１４は、L2パケット伝送方式１が用いられる場合、デマルチプレクサ２１３により処理されるL2パケットのヘッダ部の拡張ヘッダに、タイプ情報、クラス情報、及び、データバージョン情報が配置されているので、タイプ情報に、"FIT"を示すビット列が設定されているときには、伝送系列情報に従い、ペイロード部に配置されているFITを取得する。
さらに、制御部２１４は、L2パケット伝送方式２が用いられる場合、デマルチプレクサ２１３により処理されるL2パケットのペイロード部のペイロードヘッダに、タイプ情報、クラス情報、及び、データバージョン情報が配置されているので、タイプ情報に、"FIT"を示すビット列が設定されているときには、伝送系列情報に従い、ペイロード部に配置されているFITを取得する。
制御部２１４は、L1フレーム又はL2パケットから取得されたFITを、NVRAM２１５に記録する。NVRAM２１５は、不揮発性メモリであって、制御部２１４からの制御に従い、各種のデータ（例えばFIT）を記録する。入力部２１６は、ユーザの操作に応じて、操作信号を制御部２１４に供給する。
通信部２１７は、制御部２１４からの制御に従い、インターネット９０を介してサーバ３０にアクセスし、SLSシグナリングデータの配信を要求する。通信部２１７は、サーバ３０から配信されるSLSシグナリングデータを、インターネット９０を介して受信し、制御部２１４に供給する。制御部２１４は、通信部２１７から供給されるSLSシグナリングデータに基づいて、デマルチプレクサ２１３又は通信部２１７を制御する。
通信部２１７は、制御部２１４からの制御に従い、インターネット９０を介してサーバ３０にアクセスし、ビデオやオーディオ、字幕等のコンポーネントのデータの配信を要求する。通信部２１７は、サーバ３０から配信される、ビデオやオーディオ、字幕等のコンポーネントのデータを受信し、デコーダ２１８に供給する。
デコーダ２１８には、デマルチプレクサ２１３又は通信部２１７から、ビデオやオーディオ、字幕等のコンポーネントのデータが供給される。デコーダ２１８は、制御部２１４からの制御に従い、ビデオやオーディオ、字幕等のコンポーネントのデータを、MPEG等の復号方式に準拠して復号し、出力部２１９に供給する。
出力部２１９は、デコーダ２１８から供給されるビデオや字幕のデータを、ディスプレイ（不図示）に供給する。また、出力部２１９は、デコーダ２１８から供給されるオーディオのデータを、スピーカ（不図示）に出力する。これにより、ディスプレイには、選局されたサービスの映像が表示され、スピーカからは、その映像に対応する音声が出力される。
なお、図２３においては、受信装置２０がテレビ受像機等である場合には、ディスプレイやスピーカが内蔵された構成とすることができる。また、受信装置２０は、通信部２１７等の通信機能を有しない構成とすることができる。
＜６．各装置で実行される処理の流れ＞
次に、図２４乃至図２８のフローチャートを参照して、図１の伝送システム１を構成する各装置で実行される処理の流れについて説明する。
（送信処理）
まず、図２４のフローチャートを参照して、図１の送信装置１０により実行される送信処理の流れを説明する。
ステップＳ１１１において、コンポーネント取得部１１１は、外部のサーバ等から、ビデオやオーディオ、字幕等のコンポーネントのデータを取得する。また、ステップＳ１１１において、エンコーダ１１２は、コンポーネント取得部１１１からのビデオやオーディオ、字幕等のデータを、MPEG等の符号化方式に準拠して符号化する。
ステップＳ１１２において、シグナリング生成部１１３は、外部のサーバ等から取得されるシグナリングデータの素データを用いて、LLSシグナリングデータ又はSLSシグナリングデータを生成する。また、ステップＳ１１２において、シグナリング処理部１１４は、LLSシグナリングデータ又はSLSシグナリングデータを処理する。
ステップＳ１１３において、パケット生成部１１５は、エンコーダ１１２からのコンポーネントのデータと、シグナリング処理部１１４からのシグナリングデータに基づいて、L2パケットを生成する。例えば、パケット生成部１１５は、L2パケット伝送方式１が用いられる場合、L2パケットのヘッダ部の拡張ヘッダに、タイプ情報、クラス情報、及び、データバージョン情報を設定するとともに、ペイロード部にFITを配置して、伝送系列情報に応じた伝送系列でL2パケットが伝送されるようにする。
なお、FITは、各サービス事業者が生成する、サービスを選局する際に必要となる制御情報をまとめて１つのFITとして配置して伝送してもよいし、あるいは、各サービス事業者がそれぞれのサービスを選局する際に必要になる制御情報を記述したFITを生成して配置して伝送してもよい。前者の場合、事業者ID（provider_id）は、１つの値を指定すればよい。一方で、後者の場合には、事業者ID（provider_id）は、複数の事業者ごとに異なる値を指定し、受信装置２０が、サービス事業者ごとに提供されるFITの系列を識別できるように伝送する必要がある。
ステップＳ１１４において、フレーム生成部１１６は、パケット生成部１１５からのL2パケットに基づいて、L1フレームを生成する。ただし、フレーム生成部１１６は、L1フレーム伝送方式が用いられる場合、L1フレームのヘッダ部に、FIT伝送フラグ、クラス情報、及び、バージョン情報を設定するとともに、ヘッダ部にFITを配置して、伝送系列情報に応じた伝送系列でL1フレームが伝送されるようにする。
ステップＳ１１５において、送信部１１７は、フレーム生成部１１６からのL1フレームに対して、OFDMデジタル変調等の処理を行い、アンテナ１１８を介して、デジタル放送信号として送信する。
以上、送信処理の流れについて説明した。この送信処理においては、L1フレーム伝送方式が用いられる場合、伝送系列情報に応じた伝送系列で、そのヘッダ部にFITが配置されたL1フレームが伝送され、L2パケット伝送方式が用いられる場合、伝送系列情報に応じた伝送系列で、そのペイロード部にFITが配置されたL2パケットが伝送される。
（初期スキャン処理）
次に、図２５のフローチャートを参照して、図１の受信装置２０により実行される初期スキャン処理の流れを説明する。
ステップＳ２１１においては、制御部２１４によって、入力部２１６からの操作信号等が監視され、初期スキャン処理開始イベントが発生した場合、初期スキャン処理が開始され、処理は、ステップＳ２１２に進められる。
ステップＳ２１２において、チューナ２１２は、制御部２１４からの制御に従い、周波数スキャン処理を行う。ステップＳ２１３においては、ステップＳ２１２の周波数スキャン処理によって、周波数スキャンが成功したかどうかが判定される。
ステップＳ２１３において、周波数スキャンが失敗したと判定された場合、処理は、ステップＳ２１２の処理に戻り、再度、周波数スキャン処理が行われる。一方、ステップＳ２１３において、周波数スキャンに成功したと判定された場合、処理は、ステップＳ２１４に進められる。
ステップＳ２１４においては、FIT取得処理が行われる。このFIT取得処理では、L1フレーム伝送方式を用いた場合に、L1フレームで初期スキャン向けのFITが伝送されているとき、当該FITが取得され、記録される。また、L2パケット伝送方式を用いた場合に、L2パケットで初期スキャン向けのFITが伝送されているとき、当該FITが取得され、記録される。なお、FIT取得処理の詳細な内容は、図２６のフローチャートを参照して後述する。
FIT取得処理が終了すると、処理は、ステップＳ２１５に進められる。ステップＳ２１５においては、全周波数帯域のスキャンが完了したかどうかが判定される。
ステップＳ２１５において、全周波数帯域のスキャンが未完了であると判定された場合、処理は、ステップＳ２１２に戻り、ステップＳ２１２以降の処理が繰り返される。これにより、各周波数帯域における周波数スキャン処理が行われ、初期スキャン向けのFITが取得され、記録される。そして、ステップＳ２１５において、全周波数帯域のスキャンが完了したと判定された場合、図２５の周波数スキャン処理は終了される。
以上、初期スキャン処理の流れについて説明した。
（FIT取得処理）
次に、図２６のフローチャートを参照して、図２５のステップＳ２１４の処理に対応するFIT取得処理の詳細について説明する。
なお、FIT取得処理の内容は、L1フレーム伝送方式と、L2パケット伝送方式とでは異なるので、最初に、L1フレーム伝送方式を用いた場合のFIT取得処理を説明してから、その次に、L2パケット伝送方式を用いた場合のFIT取得処理を説明する。ただし、L2パケット伝送方式としては、L2パケット伝送方式１を代表して説明する。
（１）L1フレーム伝送方式を用いた場合のFIT取得処理
ステップＳ２３１において、チューナ２１２は、デジタル放送信号の復調処理を行い、L1フレーム（対象L1フレーム）を取得する。なお、この対象L1フレームのヘッダ部の情報は、制御部２１４に供給される。
ステップＳ２３２において、制御部２１４は、対象L1フレームのヘッダ部のFIT伝送フラグ（FIT_delivery_flag）が"TRUE"、すなわち、FITが伝送されていることを示しているかどうかを判定する。
ステップＳ２３２において、FITが伝送されていると判定された場合、処理は、ステップＳ２３３に進められる。ステップＳ２３３において、制御部２１４は、対象L1フレームのヘッダ部のFITバージョン情報（FIT_version）に含まれるクラスID（class_id）が、初期スキャン向けのFITの系列を示しているかどうかを判定する。
ステップＳ２３３において、クラスIDが初期スキャン向けのFITの系列を示していると判定された場合、処理は、ステップＳ２３４に進められる。ステップＳ２３４において、制御部２１４は、対象L1フレームのヘッダ部に配置されているFITを取得し、選局情報として、NVRAM２１５に記録する。
ここでは、例えば、初期スキャン向けのFIT（例えば、"00"であるクラスIDの中間周期のFITM）には、サービスレベル記述子として、サービス名称記述子、ケイパビリティ記述子、及び、サービスブートストラップ記述子が配置されているので、それらの記述子に記述された内容が記録される。なお、FITが事業者ID（provider_id）で示される複数のサービス事業者によって伝送されている場合、受信装置２０は、ステップＳ２３１乃至Ｓ２３４の処理（FIT取得処理）によって、サービス事業者ごとに取得される、サービスの選局時に必要となる情報を記録することになる。
そして、ステップＳ２３４の処理が終了すると、処理は、図２５のステップＳ２１４に戻り、それ以降の処理が繰り返される。なお、ステップＳ２３２において、FITが伝送されていないと判定された場合、又は、ステップＳ２３３において、クラスIDが初期スキャン向けのFITの系列を示していないと判定された場合、ステップＳ２３３又はＳ２３４の処理はスキップされ、処理は、図２５のステップＳ２１４の処理に戻される。
以上、L1フレーム伝送方式を用いた場合のFIT取得処理の流れを説明した。
（２）L2パケット伝送方式１を用いた場合のFIT取得処理
ステップＳ２３１において、デマルチプレクサ２１３は、L2パケット（対象L2パケット）を取得する。なお、この対象L2パケットのヘッダ部やペイロードヘッダの情報は、制御部２１４に供給される。
ステップＳ２３２において、制御部２１４は、対象L2パケットのヘッダ部の拡張ヘッダのタイプ情報（type）に、"FIT"を示すビット列が設定されている、すなわち、FITが伝送されているかどうかを判定する。
ステップＳ２３２において、FITが伝送されていると判定された場合、処理は、ステップＳ２３３に進められる。ステップＳ２３３において、制御部２１４は、対象L2パケットのヘッダ部の拡張ヘッダに配置される拡張タイプ情報に含まれるクラスID（class_id）が、初期スキャン向けのFITの系列を示しているかどうかを判定する。
ステップＳ２３３において、クラスIDが初期スキャン向けのFITの系列を示していると判定された場合、処理は、ステップＳ２３４に進められる。ステップＳ２３４において、制御部２１４は、対象L2パケットのペイロード部に配置されるFITを取得し、選局情報として、NVRAM２１５に記録する。
ここでは、例えば、初期スキャン向けのFIT（例えば、"00"であるクラスIDの中間周期のFITM）には、サービスレベル記述子として、サービス名称記述子、ケイパビリティ記述子、及び、サービスブートストラップ記述子が配置されているので、それらの記述子に記述された内容が記録される。なお、FITが事業者ID（provider_id）で示される複数のサービス事業者によって伝送されている場合、受信装置２０は、ステップＳ２３１乃至Ｓ２３４の処理（FIT取得処理）によって、サービス事業者ごとに取得される、サービスの選局時に必要となる情報を記録することになる。
そして、ステップＳ２３４の処理が終了すると、処理は、図２５のステップＳ２１４に戻り、それ以降の処理が繰り返される。なお、ステップＳ２３２において、FITが伝送されていないと判定された場合、又は、ステップＳ２３３において、クラスIDが初期スキャン向けのFITの系列を示していないと判定された場合、ステップＳ２３３又はＳ２３４の処理はスキップされ、処理は、図２５のステップＳ２１４の処理に戻される。
なお、上述した処理では、L2パケット伝送方式１を用いた場合について説明したが、L2パケット伝送方式２を用いた場合には、タイプ情報（type）は、対象L2パケットのペイロード部のペイロードヘッダに配置される。また、クラスIDは、対象L2パケットのペイロード部のペイロードヘッダの拡張タイプ情報に含まれる。
以上、L2パケット伝送方式１を用いた場合のFIT取得処理の流れを説明した。
このFIT取得処理において、受信装置２０は、例えば、"00"であるクラスIDのFIT（中間周期のFITM）のみを取得（抽出）すればよいので、効率よく処理を行うことができる。特に、初期スキャン処理時には、"10"であるクラスIDのFIT（長周期のFITL）を無視することで、迅速に初期スキャン処理を完了させることができる。
（選局処理）
次に、図２７のフローチャートを参照して、図１の受信装置２０により実行される選局処理の流れを説明する。
ステップＳ２５１においては、制御部２１４によって、入力部２１６からの操作信号等が監視され、サービス選局イベントが発生するまで、待機する。そして、ステップＳ２５２において、サービス選局イベントが発生したと判定された場合、処理は、ステップＳ２５３に進められる。
ステップＳ２５３において、制御部２１４は、選局されたサービスに対応するサービスID（チャンネル番号）を取得する。また、ステップＳ２５４において、制御部２１４は、NVRAM２１５を参照して、選局情報（FIT）が記録され、取得済みであるかどうかを判定する。
ステップＳ２５４において、選局情報が取得済みであると判定された場合、処理は、ステップＳ２５５に進められる。ステップＳ２５５において、制御部２１４は、NVRAM２１５に記録された選局情報（FIT）を読み出して取得する。
一方、ステップＳ２５４において、選局情報が取得済みではないと判定された場合、処理は、ステップＳ２５６に進められる。ステップＳ２５６においては、FIT取得処理が行われる。このFIT取得処理では、L1フレーム伝送方式を用いた場合には、L1フレームで伝送される初期スキャン向けのFITが取得され、記録される。また、L2パケット伝送方式を用いた場合には、L2パケットで伝送される初期スキャン向けのFITが取得され、記録される。なお、FIT取得処理の詳細な内容は、図２６のフローチャートの説明で先に述べたとおりである。
ステップＳ２５７においては、チューナ２１２、デマルチプレクサ２１３、及び、制御部２１４等によって、ステップＳ２５５の処理で取得された選局情報（FIT）に基づいた選局処理が行われる。受信装置２０では、この選局処理の結果、選局されたサービスの映像と音声が出力される。
以上、選局処理の流れについて説明した。
（選局中のFIT取得処理）
最後に、図２８のフローチャートを参照して、図１の受信装置２０により実行される選局中のFIT取得処理の流れを説明する。ただし、図２８のフローチャートの処理が実行される前提として、図２７の選局処理が実行され、選局されたサービスが視聴されているものとする。
なお、選局中のFIT取得処理の内容は、L1フレーム伝送方式と、L2パケット伝送方式とでは異なるので、最初に、L1フレーム伝送方式を用いた場合の選局中のFIT取得処理を説明してから、その次に、L2パケット伝送方式を用いた場合の選局中のFIT取得処理を説明する。ただし、L2パケット伝送方式としては、L2パケット伝送方式１を代表して説明する。
（１）L1フレーム伝送方式を用いた場合の選局中のFIT取得処理
ステップＳ２７１において、チューナ２１２は、デジタル放送信号の復調処理を行い、L1フレーム（対象L1フレーム）を取得する。なお、この対象L1フレームのヘッダ部の情報は、制御部２１４に供給される。
ステップＳ２７２において、制御部２１４は、対象L1フレームのヘッダ部のFIT伝送フラグ（FIT_delivery_flag）が"TRUE"、すなわち、FITが伝送されていることを示しているかどうかを判定する。
ステップＳ２７２において、FIT伝送フラグが"FALSE"となり、FITが伝送されていないと判定された場合、処理は、ステップＳ２７１に戻り、それ以降の処理が繰り返される。そして、ステップＳ２７１乃至Ｓ２７２の処理が繰り返され、FIT伝送フラグが"TRUE"となるL1フレームが取得された場合、処理は、ステップＳ２７３に進められる。
ステップＳ２７３において、制御部２１４は、対象L1フレームのヘッダ部のFITバージョン情報（FIT_version）に含まれるクラスID（class_id）とバージョン情報（version）を取得する。
ステップＳ２７４において、制御部２１４は、ステップＳ２７３の処理で取得したクラスIDとバージョン情報に基づいて、FITが更新されているかどうかを判定する。ここで、クラスIDは、事業者ID（provider_id）と配信クラスID（delivery_group_id）で構成することができる。すなわち、FITを提供するサービス事業者が異なれば、当該クラスIDは異なるため、ここでは、サービス事業者ごとに、FITが更新されているかどうかの判定が行われる。
ステップＳ２７４において、FITが更新されていると判定された場合、処理は、ステップＳ２７５に進められる。ステップＳ２７５において、制御部２１４は、動的パラメータを伝送する系列のFITが更新されたかどうかを判定する。
ステップＳ２７５において、動的パラメータを伝送する系列のFITが更新されたと判定された場合、処理は、ステップＳ２７６に進められる。ステップＳ２７６において、制御部２１４は、動的パラメータを含むFITの内容が、視聴中のサービスの状態に反映されるようにする。
ここでは、例えば、動的パラメータを伝送する系列のFIT（例えば、"00"であるクラスIDの短周期のFITS）には、サービスレベル記述子として、サービスステータス記述子が記述されているので、対象のサービスのステータスとして、非アクティブ状態（inactive）が指定されている場合には、視聴中のサービスを終了させる。
なお、ステップＳ２７５において、動的パラメータを伝送する系列のFITが更新されていないと判定された場合、処理は、ステップＳ２７７に進められる。ステップＳ２７７において、制御部２１４は、静的パラメータを伝送する系列のFITが更新されたかどうかを判定する。
ステップＳ２７７において、静的パラメータを伝送するFITが更新されたと判定された場合、処理は、ステップＳ２７８に進められる。ステップＳ２７８において、制御部２１４は、静的パラメータを含むFITを更新して、NVRAM２１５に記録されるようにする。
ここでは、例えば、静的パラメータを伝送するFIT（例えば、"10"であるクラスIDの長周期のFITL）には、シグナリングテンプレート記述子、又は、シグナリングオーバーインターネット記述子が記述されているので、シグナリングテンプレートやSLSシグナリングデータを取得するためのURIが更新されることになる。
ステップＳ２７８の処理が終了すると、選局中のFIT取得処理は終了する。なお、ステップＳ２７７において、静的パラメータを伝送する系列のFITが更新されていないと判定された場合、ステップＳ２７８の処理はスキップされる。また、ステップＳ２７４において、FITが更新されていないと判定された場合、ステップＳ２７５乃至Ｓ２７８の処理は、スキップされる。
以上、L1フレーム伝送方式を用いた場合の選局中のFIT取得処理の流れを説明した。
（２）L2パケット伝送方式１を用いた場合の選局中のFIT取得処理
ステップＳ２７１において、デマルチプレクサ２１３は、L2パケット（対象L2パケット）を取得する。なお、この対象L2パケットのヘッダ部やペイロードヘッダの情報は、制御部２１４に供給される。
ステップＳ２７２において、制御部２１４は、対象L2パケットのヘッダ部の拡張ヘッダのタイプ情報（type）に、"FIT"を示すビット列が設定されている、すなわち、FITが伝送されているかどうかを判定する。ステップＳ２７２において、FITが伝送されていると判定された場合、処理は、ステップＳ２７３に進められる。
ステップＳ２７３において、制御部２１４は、対象L2パケットのヘッダ部の拡張ヘッダに配置される拡張タイプ情報に含まれるクラスID（class_id）と、拡張ヘッダに配置されるデータバージョン情報（data version）を取得する。
ステップＳ２７４において、制御部２１４は、ステップＳ２７３の処理で取得したクラスIDとデータバージョン情報に基づいて、FITが更新されているかどうかを判定する。ここで、クラスIDは、事業者ID（provider_id）と配信クラスID（delivery_group_id）で構成することができる。すなわち、FITを提供するサービス事業者が異なれば、当該クラスIDは異なるため、ここでは、サービス事業者ごとに、FITが更新されているかどうかの判定が行われる。
なお、ステップＳ２７５乃至Ｓ２７８の処理は、上述したL1フレーム伝送方式を用いた場合の選局中のFIT取得処理と同様であり、その説明は繰り返しになるため、省略する。ただし、L2パケット伝送方式１を用いた場合、FITは、対象L2パケットのペイロード部に配置されている。
なお、上述した処理では、L2パケット伝送方式１を用いた場合について説明したが、L2パケット伝送方式２を用いた場合には、タイプ情報（type）は、対象L2パケットのペイロード部のペイロードヘッダに配置される。また、クラスIDは、対象L2パケットのペイロード部のペイロードヘッダの拡張タイプ情報に含まれる。
以上、L2パケット伝送方式１を用いた場合の選局中のFIT取得処理の流れを説明した。
この選局中のFIT取得処理においては、L1フレームのヘッダ部やL2パケットのヘッダ部の拡張ヘッダに、伝送系列情報（クラス情報とバージョン情報）が設定されることで、FITがクラスごとに複数の系列に分類され、例えば、短周期のFITS（例えば100ミリ秒周期）や長周期のFITL（例えば10秒周期）、中間周期のFITM（例えば1秒周期）など、複数の伝送周期でFITが伝送されている。そのため、伝送周期ごとに、FITに配置されるサービスレベル記述子が異なるようにすることで、例えば、受信装置２０では、時間的な制限がある情報や時間的な制限がない情報などを、用途に応じて適切なタイミングで取得することができる。
さらに、伝送系列情報として、FITを提供するサービス事業者を識別する事業者ID（provider_id）が設定されているので、FITを、サービス事業者ごとに分類することができる。例えば、チャンネル10.1と10.2を放送する放送局Ａと、チャンネル11.1を放送する放送局Ｂと、チャンネル10.1と10.2と11.1のESGメタデータを配信するESGサービス事業者Ｃにより提供されるFITを、別々の系列で配信することができる。この場合、受信装置２０において、チャンネル10.1が視聴されている場合、放送局ＡのFITを監視すれば、サービスの動的パラメータを取得することができることから、サービスの視聴状況に適したFITのみをフィルタリングして取得することができる。
＜７．変形例＞
上述した説明では、現在策定が進められている米国の次世代放送規格であるATSC3.0において、IP伝送方式を用いたデジタル放送の採用が見込まれているため、デジタル放送の規格として、米国等で採用されている方式であるATSCを例示したが、日本等が採用する方式であるISDB（Integrated Services Digital Broadcasting）や、欧州の各国等が採用する方式であるDVB（Digital Video Broadcasting）などに適用するようにしてもよい。また、地上デジタル放送のほか、衛星デジタル放送やデジタル有線テレビ放送などで採用するようにしてもよい。
また、上述した説明では、シグナリングデータの名称として、Descriptionの略である「D」を用いたが、Tableの略である「T」が用いられる場合がある。例えば、SPD（Service Parameter Description）は、SPT（Service Parameter Table）と記述される場合がある。ただし、これらの名称の違いは、「Description」と「Table」との形式的な違いであって、各シグナリングデータの実質的な内容が異なるものではない。
さらに、上述した説明では、シグナリングデータが、バイナリ形式により記述された場合における、その構成要素について説明したが、それらの構成要素の名称は一例であって、他の名称が採用されるようにしてもよい。例えば、FITに規定される「ブロードキャストストリームID（Broadcast_stream_id）」は、「ネットワークID（Network ID）」や「RFアロケーションID（RF Alloc ID）」、「RFチャンネルID（RF Channel ID）」などと称するようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの構成要素の実質的な内容が異なるものではない。
さらに、上述した説明では、クラスIDは、事業者ID（provider_id）と配信クラスID（delivery_group_id）で構成される説明をしたが、実際のサービスの運用形態によっては、クラスIDを別の伝送系列情報に用いてもよい。例えば、サービス事業者が、受信装置２０のデコード・出力能力（例えば、H.264/AVC又はHEVC、４Ｋ又は２Ｋなど）に応じてチャンネルを構成する場合、サービスの受信に必要な受信装置２０の能力を示してもよい。また、サービス事業者が放送チャンネルを特定の地域に限定して提供したい場合、クラスIDの一部を地域コードと関連づけられた値（例えば１又は複数の郵便番号や緯度経度情報など）にしてもよい。また、FITがサービスループによって複数のサービスを記述する場合、サービスの記述ごとに複数の伝送系列によって伝送されてもよい。すなわち、クラスIDは、上述した例に限定するものではなく、複数の伝送系列を示す識別子として利用することができる。
また、上述した説明では、伝送系列を識別するIDの名称として「クラスID」を用いたが、別の名称が用いられる場合がある。例えば、FITの伝送系列のグループを示すことから「グループID」や「伝送グループID」、「セグメントID」や「伝送セグメントID」、「パート番号」や「トータルパート数」、「パートID」などが採用されてもよい。また、「事業者ID（provider_id）」は、「事業者タグ（provider_tag）」などと称されるようにしてもよい。これらの名称の違いは、形式的な違いであって、それらの構成要素の実質的な内容が異なるものではない。
＜８．コンピュータの構成＞
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ９００において、CPU（Central Processing Unit）９０１，ROM（Read Only Memory）９０２，RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記録されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
（１）
サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータを生成する生成部と、
前記サービスを構成するコンポーネントのデータを含む第２のデータとともに、前記伝送系列情報に応じた伝送系列で前記第１のデータを送信する送信部と
を備える送信装置。
（２）
前記伝送系列情報は、
前記制御情報の系列の数を示すクラス数と、前記制御情報の系列を識別するためのクラスIDとを含むクラス情報と、
前記制御情報の系列ごとのバージョンを示すバージョン情報と
を含む
（１）に記載の送信装置。
（３）
前記クラスIDは、伝送周期ごとに、異なる伝送系列として前記制御情報を識別し、
前記送信部は、伝送系列に応じた伝送周期で前記制御情報が伝送されるように、前記第１のデータを送信する
（２）に記載の送信装置。
（４）
前記クラスIDは、前記サービスの選局を行う受信装置において動的に更新すべき前記制御情報と、前記受信装置において静的に更新すべき前記制御情報とを異なる伝送系列であると識別し、
前記送信部は、動的に更新すべき前記制御情報の伝送周期が、静的に更新すべき前記制御情報の伝送周期よりも短くなるように、前記第１のデータを送信する
（３）に記載の送信装置。
（５）
前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
前記１又は複数の記述子は、前記制御情報の系列ごとに関連付けられている
（２）乃至（４）のいずれかに記載の送信装置。
（６）
前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
前記１又は複数の記述子は、前記制御情報の系列にまたがって関連付けられており、
前記制御情報の系列には、前記クラスIDに応じた更新の優先度が割り当てられている
（２）乃至（４）のいずれかに記載の送信装置。
（７）
前記第１のデータは、レイヤ１のL1フレームであり、
前記伝送系列情報は、前記L1フレームのヘッダ部に配置され、
前記制御情報は、前記L1フレームのヘッダ部に配置される
（２）乃至（６）のいずれかに記載の送信装置。
（８）
前記第１のデータは、レイヤ２のL2パケットであり、
前記伝送系列情報は、前記L2パケットのヘッダ部の拡張ヘッダに配置され、
前記制御情報は、前記L2パケットのペイロード部に配置される
（２）乃至（６）のいずれかに記載の送信装置。
（９）
前記第１のデータは、レイヤ２のL2パケットであり、
前記伝送系列情報は、前記L2パケットのペイロード部のペイロードヘッダに配置され、
前記制御情報は、前記L2パケットのペイロード部のペイロードに配置される
（２）乃至（６）のいずれかに記載の送信装置。
（１０）
前記伝送系列情報は、サービスを提供するサービス事業者を識別する情報を含む
（１）に記載の送信装置。
（１１）
送信装置の送信方法において、
前記送信装置が、
サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータを生成し、
前記サービスを構成するコンポーネントのデータを含む第２のデータとともに、前記伝送系列情報に応じた伝送系列で前記第１のデータを送信する
ステップを含む送信方法。
（１２）
サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータであって、前記伝送系列情報に応じた伝送系列で送信されてくる前記第１のデータを受信する受信部と、
前記伝送系列情報に応じて取得される前記制御情報に基づいて、前記サービスを構成するコンポーネントのデータを含む第２のデータに対する処理を制御する制御部と
を備える受信装置。
（１３）
前記伝送系列情報は、
前記制御情報の系列の数を示すクラス数と、前記制御情報の系列を識別するためのクラスIDとを含むクラス情報と、
前記制御情報の系列ごとのバージョンを示すバージョン情報と
を含む
（１２）に記載の受信装置。
（１４）
前記クラスIDは、伝送周期ごとに、異なる伝送系列として前記制御情報を識別し、
前記受信部は、伝送系列に応じた伝送周期で前記制御情報が伝送されるように送信されてくる、前記第１のデータを受信する
（１３）に記載の受信装置。
（１５）
前記クラスIDは、前記サービスの選局を行う受信装置において動的に更新すべき前記制御情報と、前記受信装置において静的に更新すべき前記制御情報とを異なる伝送系列であると識別し、
前記受信部は、動的に更新すべき前記制御情報の伝送周期が、静的に更新すべき前記制御情報の伝送周期よりも短くなるように送信されてくる、前記第１のデータを受信する
（１４）に記載の受信装置。
（１６）
前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
前記１又は複数の記述子は、前記制御情報の系列ごとに関連付けられている
（１３）乃至（１５）に記載の受信装置。
（１７）
前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
前記１又は複数の記述子は、前記制御情報の系列にまたがって関連付けられており、
前記制御情報の系列には、前記クラスIDに応じた更新の優先度が割り当てられている
（１３）乃至（１５）に記載の受信装置。
（１８）
前記第１のデータは、レイヤ１のL1フレームであり、
前記伝送系列情報は、前記L1フレームのヘッダ部に配置され、
前記制御情報は、前記L1フレームのヘッダ部に配置される
（１３）乃至（１７）に記載の受信装置。
（１９）
前記第１のデータは、レイヤ２のL2パケットであり、
前記伝送系列情報は、前記L2パケットのヘッダ部の拡張ヘッダに配置され、
前記制御情報は、前記L2パケットのペイロード部に配置される
（１３）乃至（１７）に記載の受信装置。
（２０）
前記第１のデータは、レイヤ２のL2パケットであり、
前記伝送系列情報は、前記L2パケットのペイロード部のペイロードヘッダに配置され、
前記制御情報は、前記L2パケットのペイロード部のペイロードに配置される
（１３）乃至（１７）に記載の受信装置。
（２１）
前記伝送系列情報は、サービスを提供するサービス事業者を識別する情報を含む
（１２）に記載の受信装置。
（２２）
受信装置の受信方法において、
前記受信装置が、
サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータであって、前記伝送系列情報に応じた伝送系列で送信されてくる前記第１のデータを受信し、
前記伝送系列情報に応じて取得される前記制御情報に基づいて、前記サービスを構成するコンポーネントのデータを含む第２のデータに対する処理を制御する
ステップを含む受信方法。
１ 伝送システム， １０ 送信装置， ２０ 受信装置， ３０ サーバ， ８０ 伝送路， ９０ インターネット， １１１ コンポーネント取得部， １１２ エンコーダ， １１３ シグナリング生成部， １１４ シグナリング処理部， １１５ パケット生成部， １１６ フレーム生成部， １１７ 送信部， ２１２ チューナ， ２１３ デマルチプレクサ， ２１４ 制御部， ２１５ NVRAM， ２１６ 入力部， ２１７ 通信部， ２１８ デコーダ， ２１９ 出力部， ９００ コンピュータ， ９０１ CPU

Claims (22)

  1. サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータを生成する生成部と、
    前記サービスを構成するコンポーネントのデータを含む第２のデータとともに、前記伝送系列情報に応じた伝送系列で前記第１のデータを送信する送信部と
    を備える送信装置。
  2. 前記伝送系列情報は、
    前記制御情報の系列の数を示すクラス数と、前記制御情報の系列を識別するためのクラスIDとを含むクラス情報と、
    前記制御情報の系列ごとのバージョンを示すバージョン情報と
    を含む
    請求項１に記載の送信装置。
  3. 前記クラスIDは、伝送周期ごとに、異なる伝送系列として前記制御情報を識別し、
    前記送信部は、伝送系列に応じた伝送周期で前記制御情報が伝送されるように、前記第１のデータを送信する
    請求項２に記載の送信装置。
  4. 前記クラスIDは、前記サービスの選局を行う受信装置において動的に更新すべき前記制御情報と、前記受信装置において静的に更新すべき前記制御情報とを異なる伝送系列であると識別し、
    前記送信部は、動的に更新すべき前記制御情報の伝送周期が、静的に更新すべき前記制御情報の伝送周期よりも短くなるように、前記第１のデータを送信する
    請求項３に記載の送信装置。
  5. 前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
    前記１又は複数の記述子は、前記制御情報の系列ごとに関連付けられている
    請求項２に記載の送信装置。
  6. 前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
    前記１又は複数の記述子は、前記制御情報の系列にまたがって関連付けられており、
    前記制御情報の系列には、前記クラスIDに応じた更新の優先度が割り当てられている
    請求項２に記載の送信装置。
  7. 前記第１のデータは、レイヤ１のL1フレームであり、
    前記伝送系列情報は、前記L1フレームのヘッダ部に配置され、
    前記制御情報は、前記L1フレームのヘッダ部に配置される
    請求項２に記載の送信装置。
  8. 前記第１のデータは、レイヤ２のL2パケットであり、
    前記伝送系列情報は、前記L2パケットのヘッダ部の拡張ヘッダに配置され、
    前記制御情報は、前記L2パケットのペイロード部に配置される
    請求項２に記載の送信装置。
  9. 前記第１のデータは、レイヤ２のL2パケットであり、
    前記伝送系列情報は、前記L2パケットのペイロード部のペイロードヘッダに配置され、
    前記制御情報は、前記L2パケットのペイロード部のペイロードに配置される
    請求項２に記載の送信装置。
  10. 前記伝送系列情報は、サービスを提供するサービス事業者を識別する情報を含む
    請求項１に記載の送信装置。
  11. 送信装置の送信方法において、
    前記送信装置が、
    サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータを生成し、
    前記サービスを構成するコンポーネントのデータを含む第２のデータとともに、前記伝送系列情報に応じた伝送系列で前記第１のデータを送信する
    ステップを含む送信方法。
  12. サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータであって、前記伝送系列情報に応じた伝送系列で送信されてくる前記第１のデータを受信する受信部と、
    前記伝送系列情報に応じて取得される前記制御情報に基づいて、前記サービスを構成するコンポーネントのデータを含む第２のデータに対する処理を制御する制御部と
    を備える受信装置。
  13. 前記伝送系列情報は、
    前記制御情報の系列の数を示すクラス数と、前記制御情報の系列を識別するためのクラスIDとを含むクラス情報と、
    前記制御情報の系列ごとのバージョンを示すバージョン情報と
    を含む
    請求項１２に記載の受信装置。
  14. 前記クラスIDは、伝送周期ごとに、異なる伝送系列として前記制御情報を識別し、
    前記受信部は、伝送系列に応じた伝送周期で前記制御情報が伝送されるように送信されてくる、前記第１のデータを受信する
    請求項１３に記載の受信装置。
  15. 前記クラスIDは、前記サービスの選局を行う受信装置において動的に更新すべき前記制御情報と、前記受信装置において静的に更新すべき前記制御情報とを異なる伝送系列であると識別し、
    前記受信部は、動的に更新すべき前記制御情報の伝送周期が、静的に更新すべき前記制御情報の伝送周期よりも短くなるように送信されてくる、前記第１のデータを受信する
    請求項１４に記載の受信装置。
  16. 前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
    前記１又は複数の記述子は、前記制御情報の系列ごとに関連付けられている
    請求項１３に記載の受信装置。
  17. 前記制御情報は、前記サービスごとに、各種の機能を提供するための１又は複数の記述子を含み、
    前記１又は複数の記述子は、前記制御情報の系列にまたがって関連付けられており、
    前記制御情報の系列には、前記クラスIDに応じた更新の優先度が割り当てられている
    請求項１３に記載の受信装置。
  18. 前記第１のデータは、レイヤ１のL1フレームであり、
    前記伝送系列情報は、前記L1フレームのヘッダ部に配置され、
    前記制御情報は、前記L1フレームのヘッダ部に配置される
    請求項１３に記載の受信装置。
  19. 前記第１のデータは、レイヤ２のL2パケットであり、
    前記伝送系列情報は、前記L2パケットのヘッダ部の拡張ヘッダに配置され、
    前記制御情報は、前記L2パケットのペイロード部に配置される
    請求項１３に記載の受信装置。
  20. 前記第１のデータは、レイヤ２のL2パケットであり、
    前記伝送系列情報は、前記L2パケットのペイロード部のペイロードヘッダに配置され、
    前記制御情報は、前記L2パケットのペイロード部のペイロードに配置される
    請求項１３に記載の受信装置。
  21. 前記伝送系列情報は、サービスを提供するサービス事業者を識別する情報を含む
    請求項１２に記載の受信装置。
  22. 受信装置の受信方法において、
    前記受信装置が、
    サービスの選局時に必要となる情報を含む制御情報と、前記制御情報が伝送される系列を示す伝送系列情報とを含む第１のデータであって、前記伝送系列情報に応じた伝送系列で送信されてくる前記第１のデータを受信し、
    前記伝送系列情報に応じて取得される前記制御情報に基づいて、前記サービスを構成するコンポーネントのデータを含む第２のデータに対する処理を制御する
    ステップを含む受信方法。
JP2016555629A 2015-02-10 2016-01-29 送信装置、送信方法、受信装置、及び、受信方法 Ceased JPWO2016129407A1 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2015024779 2015-02-10
JP2015024779 2015-02-10
JP2015042752 2015-03-04
JP2015042752 2015-03-04
PCT/JP2016/052583 WO2016129407A1 (ja) 2015-02-10 2016-01-29 送信装置、送信方法、受信装置、及び、受信方法

Publications (1)

Publication Number Publication Date
JPWO2016129407A1 true JPWO2016129407A1 (ja) 2017-11-24

Family

ID=56614285

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016555629A Ceased JPWO2016129407A1 (ja) 2015-02-10 2016-01-29 送信装置、送信方法、受信装置、及び、受信方法

Country Status (8)

Country Link
US (2) US11444885B2 (ja)
EP (1) EP3258696B1 (ja)
JP (1) JPWO2016129407A1 (ja)
KR (2) KR102330694B1 (ja)
CN (1) CN106134207B (ja)
CA (1) CA2944781C (ja)
MX (1) MX2016012951A (ja)
WO (1) WO2016129407A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3220653B1 (en) * 2014-11-13 2019-12-04 Sony Corporation Reception device, reception method, transmission device, and transmission method for layer-coded services using route sessions
US9860571B2 (en) * 2014-12-10 2018-01-02 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
US10498792B2 (en) * 2015-05-17 2019-12-03 Lg Electronics Inc. Apparatus and method for transmitting or receiving broadcast signal
US20220299617A1 (en) * 2021-03-19 2022-09-22 Facebook Technologies, Llc Systems and methods for automatic triggering of ranging

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5502726A (en) * 1992-01-31 1996-03-26 Nellcor Incorporated Serial layered medical network
EP0899955A3 (en) 1997-08-27 2001-01-31 Matsushita Electric Industrial Co., Ltd. Control information generating apparatus for broadcast system
JPH11163814A (ja) * 1997-08-27 1999-06-18 Matsushita Electric Ind Co Ltd 放送システムの制御情報作成装置
US20060123097A1 (en) * 2004-12-02 2006-06-08 Nokia Corporation Enhanced electronic service guide container
KR101456002B1 (ko) * 2007-06-26 2014-11-03 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR101461958B1 (ko) * 2007-06-29 2014-11-14 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
US8051451B2 (en) * 2007-08-24 2011-11-01 Lg Electronics, Inc. Digital broadcasting system and method of processing data in digital broadcasting system
WO2009038440A2 (en) * 2007-09-21 2009-03-26 Lg Electronics Inc. Digital broadcasting receiver and method for controlling the same
US8171308B2 (en) * 2007-09-21 2012-05-01 Lg Electronics Inc. Digital broadcasting system and method of processing data in digital broadcasting system
EP2063638A1 (fr) * 2007-11-26 2009-05-27 Nagravision S.A. Méthode d'évaluation de droits d'utilisateurs stockés dans un module de sécurité
JP5045535B2 (ja) 2008-04-28 2012-10-10 ソニー株式会社 受信装置及び受信方法
EP2654266B1 (en) * 2008-06-07 2018-12-12 Coherent Logix Incorporated Transmitting and receiving control information for use with multimedia streams
US8422509B2 (en) * 2008-08-22 2013-04-16 Lg Electronics Inc. Method for processing a web service in an NRT service and a broadcast receiver
KR20100074818A (ko) * 2008-12-24 2010-07-02 엘지전자 주식회사 데이터 방송 서비스 제공 방법 및 그를 위한 장치
KR101598093B1 (ko) * 2009-02-02 2016-02-26 엘지전자 주식회사 송/수신 시스템 및 데이터 처리 방법
US9204289B2 (en) * 2011-02-15 2015-12-01 Samsung Electronics Co., Ltd. Method and apparatus of handling user equipment category in wireless communication system
US20130034032A1 (en) * 2011-08-05 2013-02-07 Nokia Corporation Accessing Service Guide Information in a Broadcast System
US9838748B2 (en) 2013-07-05 2017-12-05 Samsung Electronics Co., Ltd. Transmitting apparatus and receiving apparatus, and signal processing method thereof
US10271269B2 (en) * 2013-09-27 2019-04-23 Nokia Solutions And Networks Oy Changes of cluster head

Also Published As

Publication number Publication date
EP3258696A4 (en) 2018-08-29
KR20160119865A (ko) 2016-10-14
US20170034066A1 (en) 2017-02-02
KR101722364B1 (ko) 2017-03-31
KR20170106287A (ko) 2017-09-20
CN106134207A (zh) 2016-11-16
US11956159B2 (en) 2024-04-09
WO2016129407A1 (ja) 2016-08-18
CN106134207B (zh) 2020-12-11
MX2016012951A (es) 2017-01-20
US20220377018A1 (en) 2022-11-24
EP3258696B1 (en) 2021-04-28
EP3258696A1 (en) 2017-12-20
CA2944781C (en) 2023-10-24
KR102330694B1 (ko) 2021-11-25
US11444885B2 (en) 2022-09-13
CA2944781A1 (en) 2016-08-18

Similar Documents

Publication Publication Date Title
US11395123B2 (en) Reception apparatus, reception method, transmission apparatus, and transmission method
US11343549B2 (en) Reception apparatus, reception method, transmission apparatus, and transmission method
US11956159B2 (en) Transmission device, transmission method, reception device, and reception method
US11871087B2 (en) Receiver, reception method, transmitter, and transmission method
JP6598031B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法

Legal Events

Date Code Title Description
A524 Written submission of copy of amendment under article 19 pct

Free format text: JAPANESE INTERMEDIATE CODE: A527

Effective date: 20160902

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190117

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191219

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200214

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200714

A045 Written measure of dismissal of application [lapsed due to lack of payment]

Free format text: JAPANESE INTERMEDIATE CODE: A045

Effective date: 20201124