JPWO2018168455A1 - 送信装置、受信装置、及び、データ処理方法 - Google Patents

送信装置、受信装置、及び、データ処理方法 Download PDF

Info

Publication number
JPWO2018168455A1
JPWO2018168455A1 JP2019505852A JP2019505852A JPWO2018168455A1 JP WO2018168455 A1 JPWO2018168455 A1 JP WO2018168455A1 JP 2019505852 A JP2019505852 A JP 2019505852A JP 2019505852 A JP2019505852 A JP 2019505852A JP WO2018168455 A1 JPWO2018168455 A1 JP WO2018168455A1
Authority
JP
Japan
Prior art keywords
packet
plp
cid
header
stream
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
JP2019505852A
Other languages
English (en)
Other versions
JP7139310B2 (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
Sony Semiconductor Solutions Corp
Original Assignee
Sony Corp
Sony Semiconductor Solutions 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, Sony Semiconductor Solutions Corp filed Critical Sony Corp
Publication of JPWO2018168455A1 publication Critical patent/JPWO2018168455A1/ja
Application granted granted Critical
Publication of JP7139310B2 publication Critical patent/JP7139310B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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
    • 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
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/37—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying segments of broadcast information, e.g. scenes or extracting programme ID
    • 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/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T

Abstract

本技術は、受信側の回路の実装を容易にすることができるようにする送信装置、受信装置、及び、データ処理方法に関する。放送信号に含まれる複数のPLPごとに、ストリームを処理して、当該ストリームを構成するパケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を、パケットのヘッダに含める処理部を備える送信装置が提供される。本技術は、例えば、IP伝送方式又はMPEG2-TS方式等のデータ伝送の方式に適用することができる。

Description

本技術は、送信装置、受信装置、及び、データ処理方法に関し、特に、受信側の回路の実装を容易にすることができるようにした送信装置、受信装置、及び、データ処理方法に関する。
例えば、次世代地上放送規格の１つであるATSC(Advanced Television Systems Committee)3.0では、データ伝送に、主として、TS(Transport Stream)パケットではなく、IP/UDP、すなわち、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを用いる方式（以下、IP伝送方式ともいう）が採用されることが決定されている。また、ATSC3.0以外の放送方式でも、将来的に、IP伝送方式が採用されることが期待されている。
また、DVB-T2(Digital Video Broadcasting - Second Generation Terrestrial)で規定されているM-PLP(Multiple PLP)方式では、受信側において、トランスポートストリーム（TS）の復元処理を行う前段の回路と、デコード等の処理を行う後段の回路との間が、単一のインターフェースで実現されている（例えば、非特許文献１参照）。
ETSI EN 302 755 V1.3.1 (2011-11)
ところで、IP伝送方式を採用した場合においても、コストの面から、DVB-T2と同様に、受信側における復調デバイス（復調LSI）と、その後段のシステムオンチップ（SoC：System on Chip）との間は、より少ないインターフェースであることが望ましい。
このように、より少ないインターフェースで接続されるようにすることで、より少ないコストで受信側の回路を構成することが可能となるが、実際に実装することを考慮すれば、受信側の回路の実装が容易であることが望ましい。
本技術はこのような状況に鑑みてなされたものであり、受信側の回路の実装を容易にすることができるようにするものである。
本技術の一側面の送信装置は、放送信号に含まれる複数のPLP(Physical Layer Pipe)ごとに、ストリームを処理して、当該ストリームを構成するパケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を、前記パケットのヘッダに含める処理部を備える送信装置である。
本技術の一側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の一側面のデータ処理方法は、上述した本技術の一側面の送信装置に対応するデータ処理方法である。
本技術の一側面の送信装置、及び、データ処理方法においては、放送信号に含まれる複数のPLP(Physical Layer Pipe)ごとに、ストリームが処理され、当該ストリームを構成するパケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報が、前記パケットのヘッダに含められる。
本技術の一側面の受信装置は、放送信号に含まれる複数のPLP(Physical Layer Pipe)ごとに得られるストリームを構成するパケットを復調する復調部と、前記復調部により復調された前記パケットを処理する処理部とを備え、前記復調部と前記処理部とは、単一のインターフェースを介して接続され、前記復調部は、前記パケットのヘッダから得られる、当該パケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を処理し、前記処理部は、前記復調部から単一のインターフェースを介して入力される前記パケットのヘッダから得られる前記マッピング情報に基づいて、当該パケットが属していたPLPを識別する受信装置である。
本技術の一側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の一側面のデータ処理方法は、上述した本技術の一側面の受信装置に対応するデータ処理方法である。
本技術の一側面の受信装置、及び、データ処理方法においては、放送信号に含まれる複数のPLPごとに得られるパケットを復調する復調部と、前記復調部により復調された前記パケットを処理する処理部とが、単一のインターフェースを介して接続される。また、前記復調部側で、前記パケットのヘッダから得られる、当該パケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報が処理され、前記処理部側で、前記復調部から単一のインターフェースを介して入力される前記パケットのヘッダから得られる前記マッピング情報に基づいて、当該パケットが属していたPLPが識別される。
本技術の一側面によれば、受信側の回路の実装を容易にすることができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した放送システムの構成例を示すブロック図である。 送信装置の構成例を示すブロック図である。 受信装置の構成例を示すブロック図である。 単一のインターフェースを介して出力されるALPパケットの出力タイミングの例を示した図である。 物理層フレームの構造の例を示す図である。 ALPパケットの構造の例を示す図である。 単一のインターフェースを介して出力されるALPパケットに対する、PLP_IDの付加タイミングの例を示した図である。 復調部側ALPパケット出力処理の流れを説明するフローチャートである。 処理部側ALPパケット入力処理の流れを説明するフローチャートである。 ALPパケットの構造の例を示す図である。 ALPヘッダのシンタックスの例を示す図である。 単一のインターフェースを介して出力されるALPパケットに対する、PLP_IDの付加タイミングの例を示した図である。 IPデータフローの構成の例を示す図である。 IRパケットの構造の例を示す図である。 IR-DYNパケットの構造の例を示す図である。 UO-0パケットの構造の例を示す図である。 Add-CID octetの構造の例を示す図である。 第１の送信側CID対応処理の流れを説明するフローチャートである。 処理部側CID対応処理の流れを説明するフローチャートである。 第２の送信側CID対応処理の流れを説明するフローチャートである。 第３の送信側CID対応処理の流れを説明するフローチャートである。 復調部側CID対応処理の流れを説明するフローチャートである。 TSパケットのシンタックスの例を示す図である。 PIDの構造の例を示す図である。 第１の送信側PID対応処理の流れを説明するフローチャートである。 処理部側PID対応処理の流れを説明するフローチャートである。 第２の送信側PID対応処理の流れを説明するフローチャートである。 復調部側PID対応処理の流れを説明するフローチャートである。 コンピュータの構成例を示す図である。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．第１の実施の形態
（１）同一のPLPの先頭のパケットに付加する方式
（２）分割パケットの場合に付加する方式
３．第２の実施の形態
（１）CIDにマッピングする方式
（２）PIDにマッピングする方式
４．変形例
５．コンピュータの構成
＜１．システムの構成＞
（放送システムの構成例）
図１は、本技術を適用した放送システムの構成例を示すブロック図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
図１において、放送システム１は、送信装置１０と、受信装置２０から構成される。この放送システム１では、所定の放送方式に準拠したデータ伝送が行われる。
送信装置１０は、そこに入力されるコンテンツ（例えば、放送番組等）のデータに対して、変調や誤り訂正等の処理を施し、その結果得られる放送信号を、送信所の送信用アンテナにより送信する。
送信装置１０からの放送信号は、伝送路３０を介して、エンドユーザの各家庭などに設置される受信用アンテナを介して、テレビ受像機等の受信装置２０により受信される。受信装置２０は、伝送路３０を介して受信される放送信号を処理し、その結果得られるコンテンツ（例えば、放送番組等）の映像や音声のデータを出力する。
なお、放送システム１において、伝送路３０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV：Common Antenna TeleVision）などであってもよい。
（送信装置の構成例）
図２は、図１の送信装置１０の構成例を示すブロック図である。
送信装置１０は、IP伝送方式に対応している送信機であって、放送番組等のコンテンツを含む放送ストリームを、伝送路３０を介して送信する。図２において、送信装置１０は、マルチプレクサ１１１及び変調部１１２を含んで構成される。
マルチプレクサ１１１は、そこに入力される複数のIPストリームを処理して、変調部１１２に供給する。なお、ATSC3.0の場合には、PLP(Physical Layer Pipe)に対応して、所定の周波数帯域ごとに、最大64個のIPストリームが入力される。
変調部１１２は、マルチプレクサ１１１から供給される複数のIPストリームに対して、誤り訂正符号化処理や変調処理等の物理層（PHY）に関する処理を行い、その処理の結果得られる信号を、送信所の送信用アンテナを介して、放送信号として送信する。
送信装置１０は、以上のように構成される。
なお、図２に示した構成では、送信装置１０が単独で、マルチプレクサ１１１及び変調部１１２を有する構成を示しているが、一般的な放送システムでは、マルチプレクサ１１１と変調部１１２は、異なる場所に設置されるものである。例えば、マルチプレクサ１１１は、各放送局内に設置されるデータ処理装置（不図示）に設けられる一方で、変調部１１２は、送信所に設置されるデータ処理装置（不図示）に設けられるようにすることができる。
また、図２においては、データ伝送の方式として、IP伝送方式が採用され、IPストリームを処理する構成を示したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式が採用されるようにしてもよい。MPEG2-TS方式が採用された場合、送信装置１０では、IPストリームの代わりに、TSストリームに対する処理が行われる。
（受信装置の構成例）
図３は、図１の受信装置２０の構成例を示すブロック図である。
受信装置２０は、IP伝送方式に対応している受信機であって、送信装置１０から伝送路３０を介して送信されてくる放送ストリームを受信し、放送番組等のコンテンツを再生する。図３において、受信装置２０は、復調部２１１及び処理部２１２を含んで構成される。
ここで、復調部２１１は、例えば、RF ICや復調LSI等の復調デバイスとして構成される。また、処理部２１２は、例えば、システムオンチップ（SoC：System On Chip）として構成される。すなわち、受信装置２０では、復調部２１１と処理部２１２とが、異なるチップ（Chip）として構成されている。
復調部２１１は、そこに入力される信号に対して、復調処理や誤り訂正復号処理等の物理層（PHY）に関する処理、パケットに関する処理などを行い、その処理の結果得られる１つのALPストリームを、単一のインターフェース（I/F）を介して、後段の処理部２１２に出力する。
復調部２１１は、フレーム処理部２３１、FEC処理部２３２−１乃至２３２−４、及び復調マルチプレクサ２３３から構成される。
フレーム処理部２３１は、受信用アンテナ２２１を介して受信される放送信号から得られる物理層フレームを処理し、その結果得られるデータを、PLPごとに、FEC処理部２３２−１乃至２３２−４のいずれかに供給する。
FEC処理部２３２−１は、フレーム処理部２３１から、PLPごとに入力されるデータに対し、誤り訂正復号処理を施し、その結果得られるデータを、復調マルチプレクサ２３３に供給する。また、FEC処理部２３２−２乃至２３２−４は、FEC処理部２３２−１と同様に、誤り訂正復号処理を行い、その結果得られるデータを、復調マルチプレクサ２３３に供給する。
復調マルチプレクサ２３３は、FEC処理部２３２−１乃至２３２−４から、PLPごとに入力されるストリームを処理し、その結果得られる１つのALPストリームを、単一のインターフェース（I/F）を介して、処理部２１２に出力する。
処理部２１２は、単一のインターフェース（I/F）を介して、前段の復調部２１１から入力される１つのALPストリームを処理し、選局された放送番組（プログラム）に対応するIPストリームを、後段の回路（不図示）に出力する。なお、後段の回路では、IPストリームに含まれるビデオやオーディオのデータをデコードする処理などが行われ、選局された放送番組等のコンテンツが再生されることになる。
処理部２１２は、デマルチプレクサ２４１、及びカプセル化解除部２４２−１乃至２４２−４から構成される。
デマルチプレクサ２４１は、そこに入力される１つのALPストリームに含まれるALPパケットを処理して、その結果得られるALPストリームを、PLPごとに、カプセル化解除部２４２−１乃至２４２−４のいずれかに供給する。
カプセル化解除部２４２−１は、デマルチプレクサ２４１から、PLPごとに入力されるALPストリームに対し、カプセル化解除処理（Decap）を施し、その結果得られるIPストリームを、後段の回路に出力する。また、カプセル化解除部２４２−２乃至２４２−４は、カプセル化解除部２４２−１と同様に、カプセル化解除処理（Decap）を行い、その結果得られるIPストリームを、後段の回路に出力する。
受信装置２０は、以上のように構成される。
なお、受信装置２０は、テレビ受像機やセットトップボックス（STB：Set Top Box）、パーソナルコンピュータ、ゲーム機などの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機として構成される。さらに、受信装置２０は、ヘッドマウントディスプレイ（HMD：Head Mounted Display）などのウェアラブルコンピュータであってもよい。
また、図３においては、データ伝送の方式として、IP伝送方式が採用され、IPストリームを処理する構成を示したが、IP伝送方式に限らず、例えば、MPEG2-TS方式等の他の方式が採用されるようにしてもよい。MPEG2-TS方式が採用された場合、受信装置２０では、IPストリームの代わりに、TSストリームに対する処理が行われる。
＜２．第１の実施の形態＞
ところで、一般的な受信機において、復調デバイスとシステムオンチップ（SoC）との間には、放送番組等のコンテンツを含むストリームに対応して、複数のインターフェース（I/F）が設けられるのが一般的である。
例えば、次世代地上放送規格の１つであるATSC3.0では、データ伝送に、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットが用いられるが、送信機は、所定の周波数帯域ごとに、最大64個のPLP(Physical Layer Pipe)に対応することができる。
一方で、一般的な受信機では、最大で4個のPLPを同時に受信する必要がある。このように、受信機で、複数のPLPが同時に受信されるようにすることで、例えば、PLPごとに、変調方式や符号化方式（符号化率）などを変更して、より高いロバスト性を有する音声や、より高品質の映像などを提供することが可能となる。
そして、ATSC3.0の場合には、PLPに対応して、所定の周波数帯域ごとに、最大64個のIPストリームが処理される。このIPストリームは、IPパケットからなるストリームであって、放送番組等のコンテンツに対応したビデオやオーディオのコンポーネント、シグナリングなどが含まれる。
この場合に、一般的な受信機においては、復調デバイスから出力される４つのIPストリームが、システムオンチップ（SoC）に入力されるため、これらのIPストリームの数に応じて、４つのインターフェース（I/F）が必要となる。
一方で、図３の受信装置２０においては、復調デバイスとしての復調部２１１と、システムオンチップ（SoC）としての処理部２１２との間が、単一のインターフェース（I/F）により実現されている。
これは、復調部２１１側で、ALPパケットに対し、PLP_IDを含むPLP情報が付加されるようにすることで、処理部２１２側では、ALPパケットから得られるPLP_IDに基づいて、単一のインターフェース（I/F）を介して復調部２１１から入力されるALPパケットが、どのPLPに属しているのかを識別することが可能となる。
（ALPパケットの出力タイミング）
次に、図４乃至図６を参照して、受信装置２０で処理されるALPパケットの出力タイミングについて説明する。
図４には、受信装置２０において、復調部２１１から処理部２１２に対し、単一のインターフェース（I/F）を介して出力されるALPパケットの出力タイミングが表されている。なお、図４において、横方向は、時間（Time）を表し、縦方向は、フレームやパケットを処理して得られるデータを、階層ごとに段階的に表している。
図４において、最も低いレベルの階層のデータは、物理層フレームである。例えば、ATSC3.0で規定される物理層フレームは、ブートストラップ（Bootstrap）と、プリアンブル（Preamble）と、ペイロード（Payload）から構成される。
プリアンブルには、例えば、L1Bシグナリング（L1-Basic Signaling）やL1Dシグナリング（L1-Detail Signaling）などの物理層シグナリングを含めることができる。この例では、プリアンブルに、時刻情報としてのPTP(Precision Time Protocol)が配置されている。
ここで、図５には、ATSC3.0で規定された物理層フレームの構造の例を示している。物理層フレームにおいて、ペイロード（データ）は、サブフレームに配置される。物理層フレームを処理する際には、ブートストラップとプリアンブルを取得した後に、その後のサブフレームを取得することが可能となる。
なお、２以上のサブフレームが含まれる場合には、サブフレームごとに、例えば、FFTサイズやガードインターバル長、パイロットパターン等の変調パラメータを変更することができる。
図４の説明に戻り、受信装置２０の復調部２１１においては、フレーム処理部２３１及びFEC処理部２３２によって、物理層フレームが処理され、サブフレームから、１又は複数のBBパケット（Baseband Packet，以下、「BBP」とも記述する）が抽出される。
また、復調部２１１においては、復調マルチプレクサ２３３によって、BBパケットが処理され、１又は複数のALPパケットが抽出される。このとき、復調マルチプレクサ２３３は、ALPパケットに対して、PLP_IDを含むPLP情報が付加されるようにする。
これにより、復調部２１１から処理部２１２に対し、単一のインターフェース（I/F）を介して出力されるALPパケットには、PLP_IDが付加されるので、処理部２１２では、ALPパケットごとに付加されているPLP_IDに基づいて、単一のインターフェース（I/F）を介して復調部２１１から入力されるALPパケットが、どのPLPに属しているのかを識別することが可能となる。
ここで、図６を参照して、ALPパケットの構造について説明する。
図６のＡは、通常のALPパケットの構造を示す図である。図６のＡにおいて、通常のALPパケットは、ALPヘッダ（ALP Packet Header）とペイロード（Payload）から構成される。
ALPヘッダの先頭には、3ビットのTypeが設定される。このTypeは、ALPパケットのペイロードに配置されるデータのタイプに関する情報が設定される。
ALPヘッダにおいて、Typeの次には、1ビットのPC(Payload Configuration)が配置される。PCとして、"0"が設定された場合、その次に配置される1ビットのHM(Header Mode)に応じて、シングルパケットモード（Single packet mode）となって、ALPヘッダには、11ビットのLengthや、ALP拡張ヘッダ（Additional header）が配置される。
通常のALPパケットの場合には、HMとして"0"が設定され、ALPヘッダでは、HMに続いて、11ビットのLengthが配置される。また、通常のALPパケットにおいては、ALPヘッダに続いて、ペイロードが配置される。
図６のＢは、ALP拡張ヘッダに、PLP_IDを付加した場合のALPパケット（以下、PLP_ID付のALPパケットともいう）の構造を示す図である。
PLP_ID付のALPパケットにおいて、ALPヘッダには、3ビットのTypeと、1ビットのPCと、1ビットのHMが配置され、HMとして、"1"が設定されている。HMとして、"1"が設定された場合、11ビットのLengthに続いて、ALP拡張ヘッダ（Additional header）が配置される。
このALP拡張ヘッダ（Additional header）は、5ビットのLength_MSBと、1ビットのRSV(reserved)と、1ビットのSIF(Sub-stream Identifier Flag)と、1ビットのHEF(Header Extension Flag)から構成される。
Length_MSBは、ALPパケットの総ペイロード長の最上位ビット（MSB）をバイト単位で示し、ALPヘッダの11ビットのLengthが示す最下位ビット（LSB）と連結して、総ペイロード長が得られる。
SIFは、サブストリーム用のオプショナルヘッダ（Optional header）が配置されるかどうかを示すフラグである。SIFとして、"0"が設定された場合には、オプショナルヘッダが配置されないことを意味する。
HEFは、オプショナルなヘッダ拡張がなされるかどうかを示すフラグである。HEFとして、"1"が設定された場合には、ヘッダ拡張がなされる。図６のＢのPLP_ID付のALPパケットのALPヘッダでは、ALP拡張ヘッダに対し、3バイトのヘッダ拡張がなされている。
このヘッダ拡張には、8ビットのExtension_typeと、8ビットのExtension_lengthと、6ビットのPLP_IDと、2ビットのダミーデータ（dummy）が配置される。この例では、プライベートユーザデータ（PUD：Private User Data）として、6ビットのPLP_IDが配置されるため、この配置に対応したタイプと長さの値が、Extension_typeとExtension_lengthにそれぞれ設定される。
なお、このPLP_IDとしては、例えば、ATSC3.0では、L1Dシグナリング（L1-Detail Signaling）に規定される6ビットのL1D_plp_idが対応している。L1Dシグナリングの詳細については、下記の非特許文献２に開示されている。また、ALPパケットの構造の詳細については、下記の非特許文献３に開示されている。
非特許文献２：ATSC Standard：Physical Layer Protocol (A/322)
非特許文献３：ATSC Standard：Link-Layer Protocol (A/330)
（１）同一のPLPの先頭のパケットに付加する方式
（PLP_IDの付加タイミング）
図７は、単一のインターフェース（I/F）を介して出力されるALPパケットに対する、PLP_IDの付加タイミングの例を示した図である。
ここでは、比較のために、現状の方式を用いた場合のPLP_IDの付加のタイミングを、図７のＡに示し、本技術の方式を用いた場合のPLP_IDの付加のタイミングを、図７のＢに示している。
図７のＡに示すように、現状の方式では、ALPパケットごとに、ヘッダ拡張のプライベートユーザデータ（PUD）を利用して、PLP_IDを付加している。すなわち、現状の方式においては、全てのALPパケットに対し、PLP_IDが付加されている。
そのため、ALPパケットごとに、6バイトの情報で構成されるPLP_IDが付加されることで、復調部２１１と処理部２１２との間の単一のインターフェース（I/F）での伝送レートが上昇してしまう。例えば、6バイトからなるALPパケットが連続した場合には、PLP_IDを付加した場合の伝送レートは、2倍となる。
そこで、本技術の方式では、このような単一のインターフェース（I/F）での伝送レートの上昇を抑制するための技術を提案する。すなわち、本技術の方式では、同一のPLP_IDのALPパケットが連続する場合には、先頭のALPパケットに対してのみ、PLP_IDを付加して、それ以降のALPパケットには、PLP_IDが付加されないようにする。
例えば、図７のＢに示すように、PLP_ID = 1のPLPから連続して得られるALPパケットのうち、先頭のALPパケットにのみ、ヘッダ拡張のプライベートユーザデータ（PUD）を利用して、PLP_IDを付加する。また、PLP_ID = 2，3のPLPから連続して得られるALPパケットについても同様に、先頭のALPパケットに対してのみ、PLP_IDが付加されている。
このようにして、受信装置２０において、復調部２１１側では、同一のPLP（PLP_ID = 1のPLP）から連続して得られるALPパケットのうち、先頭のALPパケットにのみPLP_ID（PLP_ID = 1）が付加されるようにしている。
そして、処理部２１２側では、あるPLP_ID（PLP_ID = 1）が付加されたALPパケットから、別のPLP_ID（PLP_ID = 2）が付加されたALPパケットの１つ前のALPパケットまでのパケット群を、同一のPLP（PLP_ID = 1のPLP）に属するALPパケットであるとみなして処理を行うことができる。
これにより、特定のALPパケットに対し、最低限のPLP_IDを付加すればよいため、復調部２１１と処理部２１２との間の単一のインターフェース（I/F）での伝送レートの上昇を抑制することができる。その結果として、受信側の回路の実装を容易にすることができる。
なお、図５に示した物理層フレームのように、時分割多重化方式（TDM：Time Division Multiplexing）の場合には、PLPごとの信号が得られるため、復調部２１１の復調マルチプレクサ２３３では、PLPごとに、連続したALPパケットを取得することができる。
また、例えば、周波数分割多重化方式（FDM）や階層分割多重化方式（LDM：Layered Division Multiplexing）等の時分割多重化方式（TDM）の方式であっても、復調部２１１の復調マルチプレクサ２３３がバッファメモリを有していれば、このバッファメモリに、各PLPから得られる信号を記録して、PLPごとに、連続したALPパケットとなるように並び替えればよい。
また、上述したALPパケットに対するPLP_IDの付加の方式は、一例であって、PLP_IDの付加の方式としては、様々な方式を採用することができる。例えば、上述した説明では、ALPパケット外に、PLP_IDが付加される場合を説明したが、ALPパケット内に、PLP_IDが付加されるようにしてもよい。また、例えば、ALPパケット化せずに、PLP_IDを、パケットの先頭、最後尾、又は途中に付加するようにしてもよい。
さらに、PLP_IDは、6ビットの絶対的なIDではなく、例えば、2ビット等の相対的なIDに置き換えて、送るようにしてもよい。さらにまた、PLP_IDが付加されるパケットは、ALPパケットに限らず、例えば、IPパケットやBBパケット等の他のパケットであってもよい。
次に、図８及び図９のフローチャートを参照して、受信側で実行されるALPパケットの出入力処理の詳細について説明する。
（ALPパケット出力処理）
まず、図８のフローチャートを参照して、受信装置２０の復調部２１１により実行される復調部側ALPパケット出力処理の流れについて説明する。
ステップＳ１０１において、復調マルチプレクサ２３３は、そこに入力されるBBPストリームを処理することで、ALPパケットを抽出する。
ステップＳ１０２において、復調マルチプレクサ２３３は、ステップＳ１０１の処理で抽出されたALPパケットについて、同一のPLP_IDとなるALPパケットが連続しているかどうかを判定する。
ステップＳ１０２において、同一のPLP_IDとなるALPパケットが連続していない、すなわち、あるPLPにおける先頭のALPパケットであると判定された場合、処理は、ステップＳ１０３に進められる。
ステップＳ１０３において、復調マルチプレクサ２３３は、あるPLPにおける先頭のALPパケットに対し、ヘッダ拡張のプライベートユーザデータ（PUD）を利用して、PLP_IDを付加する。ステップＳ１０３の処理で、先頭のALPパケットに対し、PLP_IDが付加されると、処理は、ステップＳ１０４に進められる。
また、ステップＳ１０２において、同一のPLP_IDとなるALPパケットが連続している、すなわち、あるPLPにおける２番目以降のALPパケットであると判定された場合、ステップＳ１０３の処理はスキップされ、処理は、ステップＳ１０４に進められる。これにより、あるPLPにおいて、２番目以降のALPパケットには、PLP_IDを付加していないことになる。
ステップＳ１０４において、復調部２１１の復調マルチプレクサ２３３は、ALPパケットを、単一のインターフェース（I/F）を介して、処理部２１２に出力する。すなわち、復調マルチプレクサ２３３から出力されるALPパケットとしては、あるPLPにおける先頭のALPパケットには、PLP_IDが付加され、２番目以降のALPパケットには、PLP_IDが未付加とされる。
ステップＳ１０５においては、ALPパケットに対する処理を終了するかどうかが判定される。ステップＳ１０５において、ALPパケットに対する処理を終了しないと判定された場合、処理は、ステップＳ１０１に戻り、それ以降の処理が繰り返される。
例えば、PLPは、PLP_ID = 1, 2, 3, ・・・ などにより識別されるが、PLP_ID = 1のPLPにおいては、先頭のALPパケットに対して、PLP_ID = 1 が付加され、２番目以降のALPパケットには、PLP_IDが未付加とされる。
同様にまた、PLP_ID = 2のPLPにおいては、先頭のALPパケットにのみ、PLP_ID = 2 が付加され、PLP_ID = 3のPLPにおいては、先頭のALPパケットにのみ、PLP_ID = 3 が付加される。なお、繰り返しになるので、その説明は省略するが、PLP_ID = 4 以降についても同様に処理される。
一方で、ステップＳ１０５において、ALPパケットに対する処理を終了すると判定された場合には、図８の復調部側ALPパケット出力処理は終了される。
以上、復調部側ALPパケット出力処理の流れを説明した。
（ALPパケット入力処理）
次に、図９のフローチャートを参照して、受信装置２０の処理部２１２により実行される処理部側ALPパケット入力処理の流れについて説明する。
ステップＳ１２１において、デマルチプレクサ２４１は、復調部２１１から単一のインターフェース（I/F）を介して入力されるALPパケットを取得する。
ステップＳ１２２において、デマルチプレクサ２４１は、ステップＳ１２１の処理で取得されたALPパケットのヘッダ拡張のプライベートユーザデータ（PUD）に、PLP_IDが付加されているかどうかを判定する。
ステップＳ１２２において、ALPパケットに、PLP_IDが付加されていると判定された場合、処理は、ステップＳ１２３に進められる。ステップＳ１２３において、デマルチプレクサ２４１は、ステップＳ１２２の処理での判断対象のALPパケットを、付加されたPLP_IDに応じた新たなPLPの系列のALPパケットとする。
また、ステップＳ１２２において、ALPパケットに、PLP_IDが付加されていないと判定された場合、処理は、ステップＳ１２４に進められる。ステップＳ１２４において、デマルチプレクサ２４１は、ステップＳ１２２の処理での判断対象のALPパケットを、現時点でのPLP_IDと同一のPLPの系列のALPパケットとみなす。
すなわち、復調部２１１側では、あるPLPにおける先頭のALPパケットには、PLP_IDが付加され、２番目以降のALPパケットには、PLP_IDが未付加とされるので、処理部２１２側では、PLP_IDが付加されたALPパケットから、次にPLP_IDが付加されたALPパケットの１つ前のALPパケットまでは、同一のPLP_IDのALPパケットが連続しているとみなすことができる。
例えば、PLP_ID = 1のPLPにおいては、先頭のALPパケットに対して、PLP_ID = 1 が付加されるので、当該ALPパケットを、PLP_ID = 1の新たなPLPの系列とする（Ｓ１２３）。その後、PLP_ID = 1のPLPにおいて、２番目以降のALPパケットには、PLP_IDが未付加とされるので、当該ALPパケットを、現時点でのPLP_ID、すなわち、PLP_ID = 1 と同一のPLPの系列とみなす（Ｓ１２４）。
ステップＳ１２３又はＳ１２４の処理が終了すると、処理は、ステップＳ１２５に進められる。
ステップＳ１２５において、デマルチプレクサ２４１は、PLPの系列ごとに、ALPパケットを、カプセル化解除部２４２に出力する。例えば、PLP_ID = 1のPLPの系列のALPパケットは、カプセル化解除部２４２−１乃至２４２−４のうち、カプセル化解除部２４２−１に出力される。
ステップＳ１２６においては、ALPパケットに対する処理を終了するかどうかが判定される。ステップＳ１２６において、ALPパケットに対する処理を終了しないと判定された場合、処理は、ステップＳ１２１に戻り、それ以降の処理が繰り返される。
例えば、PLP_ID = 2のPLPにおいて、先頭のALPパケットは、PLP_ID = 2 が付加されるので、PLP_ID = 2の新たなPLPの系列（現時点でのPLP_IDと異なるPLPの系列）とされ（Ｓ１２３）、２番目以降のALPパケットは、PLP_IDが未付加とされるので、現時点でのPLP_ID、すなわち、PLP_ID = 2 と同一のPLPの系列とみなされる（Ｓ１２４）。そして、PLP_ID = 2のPLPの系列のALPパケットは、カプセル化解除部２４２−２に出力される（Ｓ１２５）。
なお、繰り返しになるので、その説明は省略するが、PLP_ID = 3, 4 以降についても同様に処理され、PLP_IDが付加されたALPパケットが取得されたとき、新たなPLPの系列とされ、例えば、PLP_ID = 3のPLPの系列のALPパケットは、カプセル化解除部２４２−３に出力され、PLP_ID = 4のPLPの系列のALPパケットは、カプセル化解除部２４２−４に出力される。
一方で、ステップＳ１２６において、ALPパケットに対する処理を終了すると判定された場合には、図９の処理部側ALPパケット入力処理は終了される。
以上、処理部側ALPパケット入力処理の流れを説明した。
（２）分割パケットの場合に付加する方式
ところで、ATSC3.0では、ALPパケットとして、セグメンテーションパケット（Segmentation Packet）やコンカティネーションパケット（Concatenation Packet）が規定されている。以下、セグメンテーションパケットが利用される場合における、PLP_IDを付加する際の対応について説明する。
（ALPパケットの構造）
図１０は、ALPパケットの構造の例を示す図である。
図１０のALPパケットにおいて、ALPヘッダの先頭には、3ビットのTypeと、1ビットのPC(Payload Configuration)が配置される。PCとして、"0"が設定された場合には、その次に配置される1ビットのHM(Header Mode)に応じて、シングルパケットモード（Single packet mode）となって、ALPヘッダには、11ビットのLengthや拡張ヘッダ（Additional header）が配置されるのは、先に述べた通りである。
一方で、PCとして、"1"が設定された場合には、その次に配置される1ビットのS/C（Segmentation/Concatenation）に応じて、セグメンテーションモード（Segmentation mode）又はコンカティネーションモード（Concatenation mode）となって、ALPヘッダには、11ビットのLengthや拡張ヘッダ（Additional header）が配置される。
図１１には、ALPヘッダのシンタックスの例を示している。なお、セグメンテーションパケットやコンカティネーションパケットの詳細については、非特許文献３の「Figure 5.2 Structure of Base Header for ALP packet encapsulation.」や、「Table 5.1 Header Syntax for ALP Packet Encapsulation」などに、その詳細な内容が記載されている。
（PLP_IDの付加タイミング）
図１２は、単一のインターフェース（I/F）を介して出力されるALPパケットに対する、PLP_IDの付加タイミングの例を示した図である。
ここでは、比較のために、現状の方式を用いた場合のPLP_IDの付加のタイミングを、図１２のＡに示し、本技術の方式を用いた場合のPLP_IDの付加のタイミングを、図１２のＢに示している。
図１２のＡに示すように、現状の方式においては、ALPヘッダのPC(Payload Configuration)の値に関係なく、すなわち、シングルパケットモードや、セグメンテーションモード、コンカティネーションモードなどのALPパケットの種類に関係なく、全てのALPパケットに対して、PLP_IDが付加されている。
そのため、ALPパケットごとに、6バイトの情報で構成されるPLP_IDが付加されることで、復調部２１１と処理部２１２との間の単一のインターフェース（I/F）での伝送レートが上昇してしまうのは、先に述べた通りである。
また、ALPヘッダのPCとして、"1"が設定された場合であって、セグメンテーションモードとなるとき、IPパケットが分割され、分割されたIPパケットの一部が伝送される。この分割されたIPパケットが、ALPパケット（セグメンテーションパケット）とされる。
また、ALPヘッダのPCとして、"1"が設定された場合であって、コンカティネーションモードとなるとき、複数のIPパケットが結合（連結）され、結合されたIPパケットが伝送される。この結合されたIPパケットが、ALPパケット（コンカティネーションパケット）とされる。
このとき、ALPパケットが内包している情報（例えば、CID(Context Identifier)等）によって、PLP_IDを識別可能であったとしても、ALPパケットの分割が起こると、識別可能な情報は、分割されたALPパケット（セグメンテーションパケット）のうち、先頭のALPパケット（セグメンテーションパケット）にしか残らない。
そのため、このままであると、分割されたALPパケット（セグメンテーションパケット）のうち、先頭のALPパケット（セグメンテーションパケット）以外のALPパケット（セグメンテーションパケット）は、PLP_IDを識別する方法がなくなってしまう。
そこで、本技術の方式では、ALPヘッダのPCとして、"1"が設定され、かつALPヘッダのS/Hとして、"0"が設定された場合に、ALPパケット（セグメンテーションパケット）に対し、PLP_IDが付加されるようにする。すなわち、本技術の方式では、PC = 1 のALPパケット（セグメンテーションパケット）に対してのみ、PLP_IDを付加して、PC = 0 のALPパケットに対しては、PLP_IDが付加されないようにする。
例えば、図１２のＢに示すように、PC = 0, 1 のALPパケットのうち、PC = 1の ALPパケットにのみ、ヘッダ拡張のプライベートユーザデータ（PUD）を利用して、PLP_IDを付加する。これにより、分割されたALPパケット（セグメンテーションパケット）のうち、先頭のALPパケット（セグメンテーションパケット）だけでなく、それ以外のALPパケット（セグメンテーションパケット）についても、ヘッダ拡張のプライベートユーザデータ（PUD）を参照して、PLP_IDを識別することが可能となる。
なお、ここでは、セグメンテーションパケットを中心に述べたが、コンカティネーションパケットについても同様に、ヘッダ拡張のプライベートユーザデータ（PUD）を利用して、PLP_IDを付加することが可能となる。
＜３．第２の実施の形態＞
（１）CIDにマッピングする方式
（IPデータフローの例）
図１３は、IP伝送方式によるデータ伝送の構成の例を示す図である。
図１３において、ブロードキャストストリームID（BS_ID）により識別されるRFチャンネルでは、１又は複数のPLP(Physical Layer Pipe)によって、各種のパケットを含むストリームが伝送される。
図１３の例では、PLP_ID = 0, 1, 2, 3の４つのPLPによって、１つのサービスが構成されている。また、各PLPでは、IP伝送方式が採用される場合には、IPデータフローごとにストリームが伝送される。ここで、IPデータフローとは、IPアドレスとポート番号が同一となるIPパケットの集合である。また、IPデータフローは、CID(Context Identifier)により識別される。
図１３の例では、PLP_ID = 0 のPLPでは、２つのIPデータフロー#0，#1によって、ストリームが伝送される。同様に、PLP_ID = 1 のPLPでは、２つのIPデータフロー#2，#3によって、ストリームが伝送され、PLP_ID = 2 のPLPでは、２つのIPデータフロー#4，#5によって、ストリームが伝送され、PLP_ID = 3 のPLPでは、２つのIPデータフロー#6，#7によって、ストリームが伝送される。
これらのIPデータフローには、CIDがそれぞれ割り当てられるが、異なるPLPで伝送される伝送パケット（例えば、後述するヘッダが圧縮されたIPパケット）において、CIDが重複する場合には、PLP_IDによりIPデータフローを判別する必要がある。
例えば、図１３の例では、PLP_ID = 0 のPLPで、CID = 0 のIPデータフロー#0が伝送され、PLP_ID = 3 のPLPで、CID = 0 のIPデータフロー#7が伝送されているが、この場合、CIDが0で重複しているため、0, 3のPLP_IDにより、それぞれのIPデータフローを判別することになる。
換言すれば、同一のサービス内で、CIDが重複しなければ、伝送パケットに対してPLP_IDを付加しなくとも、IPデータフローを特定することが可能とされる。
例えば、図１３の例では、PLP_ID = 3 のPLPにおいて、IPデータフロー#7のCIDを、0ではなく、7にすることで、４つのPLPにより構成されるサービス内で、CIDが固有の値となって、PLP_IDなしで、IPデータフローを特定することができる。
ところで、IPデータフローで伝送されるIPパケットは、ヘッダに様々な情報が含まれるため、オーバーヘッドが大きい。そこで、IPパケットを効率的に伝送するための、IPパケットのヘッダを圧縮するための技術として、IETF(The Internet Engineering Task Force)によるRFC3095で規定されているRoHC(Robust Header Compression)がある。
RoHCでは、IPヘッダとUDPヘッダのヘッダ情報をすべて含む伝送パケット（完全な伝送パケット）が送信され、その後の伝送パケットのヘッダ情報については、直前の完全な伝送パケットのヘッダ情報との差分の情報が送信される。
すなわち、RoHCは、UDPパケットを含むIPパケットを構成するIPヘッダとUDPヘッダに配置されるヘッダ情報を、静的な情報（SC：Static Chain）と、動的な情報（DC：Dynamic Chain）とに分離し、静的な情報（SC）を繰り返し送らないようにしてその伝送回数を減らすことで、ヘッダ情報の圧縮を実現する方式である。
なお、ここで、静的な情報（SC）とは、ヘッダ情報のうち、あらかじめ設定された内容が変化しないものや、状況を通じて一貫してその内容が維持されるものをいう。一方で、動的な情報（DC）とは、ヘッダ情報のうち、あらかじめ設定された内容が状況に応じて変化するものや、状況に合わせて選択できたりする柔軟性を持っているものをいう。
（IRパケットの構造）
図１４は、パケットタイプがIRパケットである伝送パケットの構造の例を示す図である。
図１４の伝送パケットのヘッダにおいて、先頭から1バイト（1〜8ビット）には、Add-CID octetが配置される。このAdd-CID octetには、PLP_IDやCIDが設定されるが、その詳細な構造は、図１７を参照して後述する。
また、次の1バイト(9〜16ビット)のうち、先頭から7ビットには、"1111110"が固定で設定され、最後の1ビットには、動的な情報（DC）があるかどうかのフラグ（D）が設定される。さらに、次の2バイト（17〜24，25〜32ビット）は、CIDが4ビット以上となる場合に、必要に応じて用いられる拡張用のCID領域（large CID）となる。
また、次の1バイト(33〜40ビット)には、8ビットのプロファイル(profile)が設定される。図１４の伝送パケットには、"0x0002"であるプロファイルが設定されている。さらに、次の1バイト（41〜48ビット）には、8ビットの誤り検出符号（CRC：Cyclic Redundancy Check）が設定される。誤り検出符号（CRC）の次には、可変長の静的な情報（SC）と動的な情報（DC）が配置される。
パケットタイプがIRパケットである伝送パケットのヘッダは、以上のような構造を有し、このヘッダに続いて、ペイロード（Payload）が配置される。
（IR-DYNパケットの構造）
図１５は、パケットタイプがIR-DYNパケットである伝送パケットの構造の例を示す図である。
図１５の伝送パケットのヘッダにおいて、先頭から1バイト（1〜8ビット）には、Add-CID octetが配置される。このAdd-CID octetには、PLP_IDやCIDが設定されるが、その詳細な構造は、図１７を参照して後述する。
また、次の1バイト(9〜16ビット)には、"11111000"が固定で設定される。さらに、次の2バイト（17〜24，25〜32ビット）は、CIDが4ビット以上となる場合に、必要に応じて用いられる拡張用のCID領域（large CID）となる。
また、次の1バイト(33〜40ビット)には、8ビットのプロファイル(profile)が設定される。図１５の伝送パケットには、"0x0002"であるプロファイルが設定されている。さらに、次の1バイト（41〜48ビット）には、8ビットの誤り検出符号（CRC）が設定される。誤り検出符号（CRC）の次には、可変長の動的な情報（DC）が配置される。
パケットタイプがIR-DYNパケットである伝送パケットのヘッダは、以上のような構造を有し、このヘッダに続いて、ペイロード（Payload）が配置される。
（UO-0パケットの構造）
図１６は、パケットタイプがUO-0パケットである伝送パケットの構造の例を示す図である。ただし、図１６においては、CIDが15以下となる場合の構造を、図１６のＡに示し、CIDが16以上となる場合の構造を、図１６のＢに示している。
図１６のＡの伝送パケットのヘッダにおいて、先頭から1バイト（1〜8ビット）には、Add-CID octetが配置される。
また、次の1バイト(9〜16ビット)のうち、先頭の1ビットには、"0"が固定で設定される。さらに、次の4ビットには、SN(Sequence Number)が設定され、次の3ビットには、誤り検出符号（CRC）が設定される。
図１６のＢの伝送パケットのヘッダにおいて、先頭から1バイト（1〜8ビット）のうち、先頭の1ビットには、"0"が固定で設定される。さらに、次の4ビットには、SN(Sequence Number)が設定され、次の3ビットには、誤り検出符号（CRC）が設定される。
次の2バイト（9〜16，17〜24ビット）は、必要に応じて用いられる拡張用のCID領域（large CID）となる。
なお、図１４乃至図１６に示したRoHCのパケットタイプは一例であって、RoHCには、例えば、UO-1，UOR-2パケット等の他のパケットタイプも規定されている。また、RoHCのパケットタイプについては、RoHCの規格書（RObust Header Compression (ROHC):Framework and four profiles: RTP, UDP, ESP, and uncompressed）に、その詳細な内容が記述されている。
本技術では、IRパケットやIR-DYNパケット、UO-0パケット等の伝送パケットにおいて、ヘッダのAdd-CID octetの領域（以下、CID領域（small CID）ともいう）や、拡張用のCID領域（large CID）に、当該伝送パケットが属するPLPのPLP_IDにマッピングされたマッピング情報として、CID領域情報を含めることで、当該伝送パケットが属するPLPが識別されるようにする。
以下、このようなCID領域情報（マッピング情報）を用いて、伝送パケットが属するPLPを識別する方式として、第１のCID対応方式乃至第４のCID対応方式の４つの方式について説明する。
（１−１）第１のCID対応方式
（Add-CID octetの構造）
図１７は、Add-CID octetの構造の例を示す図である。
RoHCでは、図１４，図１５，図１６のＡに示した伝送パケットのヘッダにおいて、先頭から1バイト（1〜8ビット）には、Add-CID octetとして、"1110 CID"、すなわち、上位の4ビットに、"1110"が固定で設定され、下位の4ビットに、CIDが設定されることが規定されている。
一方で、本技術では、第１のCID対応方式を採用する場合、Add-CID octetのCID領域において、下位の4ビットのCIDのうち、上位2ビットに、PLP_IDを割り当て、残りの2ビットに、CIDを割り当てる。このように割り当てられた2ビットのPLP_IDによって、同一のサービス内で、最大で4個のPLPを識別可能となる。
なお、このCID領域におけるビットの割り当ては、一例であって、例えば、識別すべきPLPの数に応じて、割り当てるビットを変更することができる。
次に、図１８及び図１９のフローチャートを参照して、送信側と受信側で実行されるCID対応処理の詳細について説明する。
（第１の送信側CID対応処理）
まず、図１８のフローチャートを参照して、送信装置１０により実行される第１の送信側CID対応処理の流れについて説明する。
ステップＳ２０１において、変調部１１２は、そこに入力される伝送パケットを処理し、そのヘッダのAdd-CID octetのCID領域内の4ビットのうち、上位2ビットに、PLP_IDを配置する。
すなわち、CID領域内に配置されるCID領域情報として、下位2ビットのCIDとともに、2ビットのPLP_IDが含まれる。このようにして得られる伝送パケットには、変調処理等の必要な処理が施され、その結果得られる放送信号が送信される。
以上、第１の送信側CID対応処理の流れを説明した。
（処理部側CID対応処理）
次に、図１９のフローチャートを参照して、受信装置２０により実行される処理部側CID対応処理の流れについて説明する。
なお、図１９に示した処理は、受信装置２０において、処理部２１２により実行される処理であって、その前段の処理として、復調部２１１での処理が行われている。すなわち、復調部２１１によって、送信装置１０から受信した放送信号に対し、復調処理等の必要な処理が施され、その結果得られるALPパケットが、単一のインターフェース（I/F）を介して処理部２１２に出力される。
ステップＳ２１１において、デマルチプレクサ２４１は、そこに入力されるALPパケットを処理して、伝送パケットを取得する。この伝送パケットは、例えば、IRパケットやIR-DYNパケット、UO-0パケット等とされる。
ステップＳ２１２において、デマルチプレクサ２４１は、ステップＳ２１１の処理で取得された伝送パケットのヘッダ（のAdd-CID octetのCID領域）から、CID領域情報を抽出する。
ステップＳ２１３において、デマルチプレクサ２４１は、ステップＳ２１２の処理で抽出されたCID領域情報を解析する。
ここで、第１のCID対応方式においては、伝送パケットのヘッダのCID領域から得られるCID領域情報として、CID領域内の4ビットのうち、上位2ビットに、PLP_IDが配置されているため、当該PLP_IDに応じたPLPの系列が、処理対象の伝送パケットごとに特定される。
ステップＳ２１４において、デマルチプレクサ２４１は、ステップＳ２１３の処理で得られる解析結果に基づいて、PLPの系列ごとに、伝送パケットを出力する。
ステップＳ２１５においては、伝送パケットに対する処理を終了するかどうかが判定される。ステップＳ２１５において、伝送パケットに対する処理を終了しないと判定された場合、処理は、ステップＳ２１１に戻り、それ以降の処理が繰り返される。
例えば、PLP_ID = 1のPLPの系列の伝送パケットは、カプセル化解除部２４２−１等の第１処理系列に出力される。また、PLP_ID = 2のPLPの系列の伝送パケットは、カプセル化解除部２４２−２等の第２処理系列に出力される。さらに、PLP_ID = 3, 4 以降についても同様に、第３処理系列や第４処理系列等のPLPの系列に応じた処理系列にそれぞれ出力される。
一方で、ステップＳ２１５において、伝送パケットに対する処理を終了すると判定された場合には、図１９の処理部側CID対応処理は終了される。
以上、処理部側CID対応処理の流れを説明した。
（１−２）第２のCID対応方式
RoHCでは、図１４，図１５，図１６のＢに示した伝送パケットのヘッダにおいては、拡張用のCID領域（Large CID）が確保されているので、本技術では、第２のCID対応方式を採用する場合に、この拡張用のCID領域に、PLP_IDが配置されるようにする。
このとき、PLP_IDとして、2ビットを確保することで、同一のサービス内で、最大で4個のPLPを識別可能となる。また、上述した第１のCID対応方式と比べて、先頭から1バイトのAdd-CID octetのCID領域には、PLP_IDを割り当てないため、Add-CID octetを、RoHCでの規定どおりに利用することができる。ただし、PLP_IDのビット数は、2ビットに限らず、任意のビットとされる。
（第２の送信側CID対応処理）
ここで、図２０のフローチャートを参照して、送信装置１０により実行される第２の送信側CID対応処理の流れについて説明する。
ステップＳ２２１において、変調部１１２は、そこに入力される伝送パケットを処理し、そのヘッダの拡張用のCID領域に、2ビットのPLP_IDを配置する。
これにより、CID領域と、拡張用のCID領域内に配置されるCID領域情報として、Add-CID octetのCIDとともに、PLP_IDが含まれる。このようにして得られる伝送パケットには、変調処理等の必要な処理が施され、その結果得られる放送信号が送信される。
以上、第２の送信側CID対応処理の流れを説明した。
なお、第２のCID対応方式において、受信装置２０により実行される処理は、上述した第１のCID対応方式の場合と基本的に同様であるため、その詳細な説明は省略するが、次の点が異なる。
すなわち、受信装置２０の処理部２１２においては、デマルチプレクサ２４１によって、伝送パケットのヘッダから得られるCID領域情報として、拡張用のCID領域に配置されたPLP_IDが得られる。これにより、デマルチプレクサ２４１は、このPLP_IDに応じたPLPの系列ごとに、伝送パケットを出力することができる。
（１−３）第３のCID対応方式
RoHCでは、図１４，図１５，図１６に示した伝送パケットのヘッダにおいて、CID領域又は拡張用のCID領域に、CIDが配置されるが、本技術では、第３のCID対応方式を採用する場合に、送信側の送信装置１０によって、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する。
（第３の送信側CID対応処理）
ここで、図２１のフローチャートを参照して、送信装置１０により実行される第３の送信側CID対応処理の流れについて説明する。
ステップＳ２３１において、変調部１１２は、そこに入力される伝送パケットを処理し、そのヘッダのCID領域又は拡張用のCID領域に、CIDを設定する際に、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する。
ここでは、例えば、変調部１１２が、内蔵するメモリに、CIDの管理用のテーブルを記録して、当該テーブルを参照しながら、処理対象のサービス内で使用されるCIDを管理することで、CIDが重複しないようにする。
例えば、上述した図１３の例では、１つのサービスを構成する４つのPLP（PLP_ID = 0, 1, 2, 3のPLP）ごとに、２つのIPデータフローがそれぞれ伝送されているが、変調部１１２によって、各IPデータフローに対し、固有のCIDが割り当てられるようにする。
より具体的には、図１３の例に示したように、IPデータフロー#0乃至#7に対し、CIDとして、0から7までの値が順に割り当てられるようにすることで、４つのPLPにより構成されるサービス内で、CIDが固有の値となって、PLP_IDなしで、IPデータフローを特定することができる。
すなわち、伝送パケットのヘッダのCID領域又は拡張用のCID領域内のCID領域情報として、送信側の送信装置１０で重複しないように管理されたCIDが含まれる。このようにして得られる伝送パケットには、変調処理等の必要な処理が施され、その結果得られる放送信号が送信される。
以上、第３の送信側CID対応処理の流れを説明した。
なお、第３のCID対応方式において、受信装置２０により実行される処理は、上述した第１のCID対応方式の場合と基本的に同様であるため、その詳細な説明は省略するが、次の点が異なる。
すなわち、受信装置２０の処理部２１２においては、デマルチプレクサ２４１によって、伝送パケットのヘッダのCID領域又は拡張用のCID領域から得られるCID領域情報として、送信側の送信装置１０で重複しないように管理されたCIDが得られる。これにより、デマルチプレクサ２４１は、CIDに応じたIPデータフローの系列（PLPの系列）ごとに、伝送パケットを出力することができる。
（１−４）第４のCID対応方式
RoHCでは、図１４，図１５，図１６に示した伝送パケットのヘッダにおいて、CID領域又は拡張用のCID領域に、CIDが配置されるが、本技術では、第４のCID対応方式を採用する場合に、受信側の受信装置２０（の復調部２１１）によって、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する。
（復調部側CID対応処理）
ここで、図２２のフローチャートを参照して、受信装置２０により実行される復調部側CID対応処理の流れについて説明する。
ステップＳ２４１において、復調マルチプレクサ２３３は、そこに入力される伝送パケットを処理し、そのヘッダのCID領域又は拡張用のCID領域に設定されたCIDを認識する際に、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する。
すなわち、復調マルチプレクサ２３３は、複数のPLPで構成される１つのサービス内で、CIDが重複する場合には、重複しないCIDに置き換えるようにする。ここでは、例えば、復調マルチプレクサ２３３が、内蔵するメモリに、CIDの管理用のテーブルを記録して、当該テーブルを参照しながら、処理対象のサービス内で使用されるCIDを管理することで、CIDが重複しないようにする。
例えば、上述した図１３の例では、１つのサービスを構成する４つのPLP（PLP_ID = 0, 1, 2, 3のPLP）ごとに、２つのIPデータフローがそれぞれ伝送されているが、復調マルチプレクサ２３３によって、各IPデータフローに対し、固有のCIDが割り当てられるようにする。
より具体的には、図１３の例に示したように、送信側の送信装置１０でCIDが管理されておらず、IPデータフロー#0乃至#7に対し、CIDとして、0，1，2，3，4，5，6，0である値が順に割り当てられている場合、復調マルチプレクサ２３３が、IPデータフロー#7のCIDを、0から7に置き換えるようにする。これにより、４つのPLPにより構成されるサービス内で、CIDが固有の値となって、処理部２１２側では、PLP_IDなしで、IPデータフローを特定することができる。
なお、第４のCID対応方式において、処理部２１２により実行される処理は、上述した第１のCID対応方式の場合と基本的に同様であるため、その詳細な説明は省略するが、次の点が異なる。
すなわち、受信装置２０の処理部２１２においては、デマルチプレクサ２４１によって、伝送パケットのヘッダのCID領域又は拡張用のCID領域から得られるCID領域情報として、受信側（の復調部２１１）で重複しないように管理されたCIDが得られる。これにより、デマルチプレクサ２４１は、CIDに応じたIPデータフローの系列（PLPの系列）ごとに、伝送パケットを出力することができる。
以上のように、IRパケット等の伝送パケットのヘッダのCID領域（small CID）又は拡張用のCID領域（large CID）に、PLP_IDのマッピング情報としてのCID領域情報が配置されるようにすることで、受信側では、当該CID領域情報を用いて、伝送パケットが属するPLPを識別することが可能となる。
また、PLP_IDに相当する情報が、他の領域（CID領域や拡張用のCID領域）にマッピングされ、例えば、ALPパケットに対し、PLP_IDを付加することが不要となるため、受信側の受信装置２０では、復調デバイスとしての復調部２１１と、システムオンチップ（SoC）としての処理部２１２との間の単一のインターフェース（I/F）での伝送レートの上昇を抑制することになる。その結果として、受信側の回路の実装を容易にすることができる。
なお、上述したように、例えば、ATSC3.0では、データ伝送に、UDPパケットを含むIPパケットを用いるIP伝送方式が採用されているため、上述したような、CIDにマッピングする方式を適用することができる。また、ATSC3.0以外の放送方式でも、IP伝送方式が採用された放送方式では、CIDにマッピングする方式を適用することができる。
また、上述した説明では、送信側のCIDに関する処理が、例えば、送信所側に設置される（データ処理装置の）変調部１１２（処理部）により実行されるとして説明したが、送信側のCIDに関する処理は、放送局側に設置される（データ処理装置の）マルチプレクサ１１１（処理部）により実行されるようにしてもよい。
さらに、ATSC3.0では、CIDは、1バイトまでと規定されているが、本技術では、そのような限定はなく、例えば、CIDが2バイトの場合も含んでいる。
（２）PIDにマッピングする方式
（TSパケットの構造）
図２３は、TSパケットのシンタックスの例を示す図である。
MPEG-2 TS(Transport Stream)方式に準拠したTSストリームは、TSパケットから構成される。このTSパケットのヘッダは、8ビットのsync_byte，1ビットのtransport_error_indicator，1ビットのpayload_unit_start_indicator，1ビットのtransport_priority，13ビットのPID，2ビットのtransport_scrambling_control，2ビットのadaptation_field_control，4ビットのcontinuity_counterを含む32ビットからなる。
ここで、13ビットのPID(Packet ID)は、MPEG-2 TSに準拠したTSパケットごとに割り当てられるパケット識別子である。このパケット識別子は、各TSパケットのそれぞれが何を伝送しているものかを示すための識別子である。
本技術では、TSパケットにおいて、ヘッダのPIDの領域に、当該TSパケットが属するPLPのPLP_IDにマッピングされたマッピング情報として、PID領域情報を含めることで、当該TSパケットが属するPLPが識別されるようにする。
以下、このようなPID領域情報（マッピング情報）を用いて、TSパケットが属するPLPを識別する方式として、第１のPID対応方式乃至第３のPID対応方式の３つの方式について説明する。
なお、PIDにマッピングする方式では、TSパケットにより構成されるTSストリームを処理することになるため、送信側の送信装置１０（図２）と、受信側の受信装置２０（図３）においては、IPストリームの代わりに、TSストリームを処理することになる。
（２−１）第１のPID対応方式
（PIDの構造）
図２４は、PIDの構造の例を示す図である。
TSパケットのヘッダにおいて、PIDには、13ビットが割り当てられるのは先に述べた通りである。本技術では、第１のPID対応方式を採用する場合に、13ビットのPIDのうち、上位2ビットに、PLP_IDを割り当て、残りの11ビットに、PIDを割り当てる。このように割り当てられた2ビットのPLP_IDによって、同一のサービス内で、最大で4個のPLPを識別可能となる。
次に、図２５及び図２６のフローチャートを参照して、送信側と受信側で実行されるPID対応処理の詳細について説明する。
（第１の送信側PID対応処理）
まず、図２５のフローチャートを参照して、送信装置１０により実行される第１の送信側PID対応処理の流れについて説明する。
ステップＳ３０１において、変調部１１２は、そこに入力されるTSパケットを処理し、そのヘッダのPIDの13ビットのうち、上位2ビットに、PLP_IDを配置する。
これにより、TSパケットのヘッダのPIDの領域内に配置されるPID領域情報として、下位11ビットのPIDとともに、2ビットのPLP_IDが含まれる。このようにして得られるTSパケットには、変調処理等の必要な処理が施され、その結果得られる放送信号が送信される。
以上、第１の送信側PID対応処理の流れを説明した。
（処理部側PID対応処理）
次に、図２６のフローチャートを参照して、受信装置２０により実行される処理部側PID対応処理の流れについて説明する。
なお、図２６に示した処理は、受信装置２０において、処理部２１２により実行される処理であって、その前段の処理として、復調部２１１での処理が行われている。すなわち、復調部２１１によって、送信装置１０から受信した放送信号に対し、復調処理等の必要な処理が施され、その結果得られるTSパケットが、単一のインターフェース（I/F）を介して処理部２１２に出力される。
ステップＳ３１１において、デマルチプレクサ２４１は、そこに入力されるTSパケットを取得する。
ステップＳ３１２において、デマルチプレクサ２４１は、ステップＳ３１１の処理で取得されたTSパケットのヘッダのPID領域から、PID領域情報を抽出する。
ステップＳ３１３において、デマルチプレクサ２４１は、ステップＳ３１２の処理で抽出されたPID領域情報を解析する。
ここで、第１のPID対応方式においては、TSパケットのヘッダのPID領域から得られるPID領域情報として、13ビットの情報のうち、上位2ビットに、PLP_IDが配置されているため、当該PLP_IDに応じたPLPの系列が、処理対象のTSパケットごとに特定される。
ステップＳ３１４において、デマルチプレクサ２４１は、ステップＳ３１３の処理で得られる解析結果に基づいて、PLPの系列ごとに、TSパケットを出力する。
ステップＳ３１５においては、TSパケットに対する処理を終了するかどうかが判定される。ステップＳ３１５において、TSパケットに対する処理を終了しないと判定された場合、処理は、ステップＳ３１１に戻り、それ以降の処理が繰り返される。
例えば、PLP_ID = 1のPLPの系列のTSパケットは、カプセル化解除部２４２−１等の第１処理系列に出力される。また、PLP_ID = 2のPLPの系列のTSパケットは、カプセル化解除部２４２−２等の第２処理系列に出力される。さらに、PLP_ID = 3, 4 以降についても同様に、第３処理系列や第４処理系列等のPLPの系列に応じた処理系列にそれぞれ出力される。
一方で、ステップＳ３１５において、TSパケットに対する処理を終了すると判定された場合には、図２６の処理部側PID対応処理は終了される。
以上、処理部側PID対応処理の流れを説明した。
（２−２）第２のPID対応方式
MPEG2-TS方式では、図２３に示したTSパケットのヘッダにおいて、PID領域に、13ビットのPIDが配置されるが、本技術では、第２のPID対応方式を採用する場合に、送信側の送信装置１０によって、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する。
（第２の送信側PID対応処理）
ここで、図２７のフローチャートを参照して、送信装置１０により実行される第２の送信側PID対応処理の流れについて説明する。
ステップＳ３２１において、変調部１１２は、そこに入力されるTSパケットを処理し、そのヘッダのPID領域に、PIDを設定する際に、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する。
ここでは、例えば、変調部１１２が、内蔵するメモリに、PIDの管理用のテーブルを記録して、当該テーブルを参照しながら、対象のサービス内で使用されるPIDを管理することで、PIDが重複しないようにする。
これにより、TSパケットのヘッダのPID領域内のPID領域情報として、送信側の送信装置１０で重複しないように管理されたPIDが含まれる。このようにして得られるTSパケットには、変調処理等の必要な処理が施され、その結果得られる放送信号が送信される。
以上、第２の送信側PID対応処理の流れを説明した。
なお、第２のPID対応方式において、受信装置２０により実行される処理は、上述した第１のPID対応方式の場合と基本的に同様であるため、その詳細な説明は省略するが、次の点が異なる。
すなわち、受信装置２０の処理部２１２においては、デマルチプレクサ２４１によって、TSパケットのヘッダのPID領域から得られるPID領域情報として、送信側の送信装置１０で重複しないように管理されたPIDが得られる。これにより、デマルチプレクサ２４１は、PIDに応じたPLPの系列ごとに、TSパケットを出力することができる。
（２−３）第３のPID対応方式
MPEG2-TS方式では、図２３に示したTSパケットのヘッダにおいて、PID領域に、13ビットのPIDが配置されるが、本技術では、第３のPID対応方式を採用する場合に、受信側の受信装置２０（の復調部２１１）によって、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する。
（復調部側PID対応処理）
ここで、図２８のフローチャートを参照して、受信装置２０により実行される復調部側PID対応処理の流れについて説明する。
ステップＳ３３１において、復調マルチプレクサ２３３は、そこに入力されるTSパケットを処理し、そのヘッダのPID領域に設定されたPIDを認識する際に、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する。
すなわち、復調マルチプレクサ２３３は、複数のPLPで構成される１つのサービス内で、PIDが重複する場合には、重複しないPIDに置き換えるようにする。ここでは、例えば、復調マルチプレクサ２３３が、内蔵するメモリに、PIDの管理用のテーブルを記録して、当該テーブルを参照しながら、処理対象のサービス内で使用されるPIDを管理することで、PIDが重複しないようにする。
以上、復調部側PID対応処理の流れを説明した。
なお、第３のPID対応方式において、処理部２１２により実行される処理は、上述した第１のPID対応方式の場合と基本的に同様であるため、その詳細な説明は省略するが、次の点が異なる。
すなわち、受信装置２０の処理部２１２においては、デマルチプレクサ２４１によって、伝送パケットのヘッダのPID領域から得られるPID領域情報として、受信側（の復調部２１１）で重複しないように管理されたPIDが得られる。これにより、デマルチプレクサ２４１は、PIDに応じたPLPの系列ごとに、TSパケットを出力することができる。
以上のように、TSパケットのヘッダのPID領域に、PLP_IDのマッピング情報としてのPID領域情報が配置されるようにすることで、受信側では、当該PID領域情報を用いて、TSパケットが属するPLPを識別することが可能となる。
また、PLP_IDに相当する情報が、他の領域（PID領域）にマッピングされ、例えば、ALPパケットに対し、PLP_IDを付加することが不要となるため、受信側の受信装置２０では、復調デバイスとしての復調部２１１と、システムオンチップ（SoC）としての処理部２１２との間の単一のインターフェース（I/F）での伝送レートの上昇を抑制することになる。その結果として、受信側の回路の実装を容易にすることができる。
なお、上述した説明では、送信側のPIDに関する処理が、例えば、送信所側に設置される（データ処理装置の）変調部１１２（処理部）により実行されるとして説明したが、送信側のPIDに関する処理は、放送局側に設置される（データ処理装置の）マルチプレクサ１１１（処理部）により実行されるようにしてもよい。
＜４．変形例＞
（他の放送方式への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述したように、データ伝送の方式としては、IP伝送方式に限らず、例えば、MPEG2-TS方式等の他の方式が適用されるようにしてもよい。
また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
（放送方式以外の方式への適用）
また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。その場合には、放送システム１（図１）の伝送路３０として、インターネットや電話網などの通信回線が利用され、送信装置１０は、インターネット上に設けられたサーバとすることができる。そして、当該通信サーバと、受信装置２０とが、伝送路３０（通信回線）を介して双方向の通信を行うことになる。
（受信側の他の構成）
なお、上述した説明では、受信装置２０において、復調デバイスとしての復調部２１１と、システムオンチップ（SoC）としての処理部２１２との間が、単一のインターフェース（I/F）により接続される構成を説明したが、復調部２１１の復調マルチプレクサ２３３に入力される、PLPに対応したIPストリームの系列の数よりも少なければ、インターフェース（I/F）の数は、１本に限らず、２本以上であってもよい。
すなわち、復調部２１１と処理部２１２との間のインターフェース（I/F）の数は、単一又はPLPの個数よりも少ない数とされる。また、例えば、受信装置２０において、１つの復調部２１１に対し、複数の処理部２１２が設けられる場合には、複数のインターフェース（I/F）が設けられることになる。
＜５．コンピュータの構成＞
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
（１）
放送信号に含まれる複数のPLP(Physical Layer Pipe)ごとに、ストリームを処理して、当該ストリームを構成するパケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を、前記パケットのヘッダに含める処理部を備える
送信装置。
（２）
前記ストリームは、IP(Internet Protocol)ストリームであり、
前記パケットは、RoHC(Robust Header Compression)で規定されるパケットであり、
前記マッピング情報は、RoHCで規定されるCID(Context Identifier)の領域に含まれる
前記（１）に記載の送信装置。
（３）
前記CIDの領域は、前記ヘッダのAdd-CID octet内の領域であって、所定のビットが、PLPの識別情報に割り当てられ、残りのビットが、CIDに割り当てられる
前記（２）に記載の送信装置。
（４）
前記CIDの領域は、前記ヘッダのAdd-CID octet以外のCIDの領域であって、所定のビットが、PLPの識別情報に割り当てられる
前記（２）に記載の送信装置。
（５）
前記処理部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する
前記（２）に記載の送信装置。
（６）
前記ストリームは、TS(Transport Stream)ストリームであり、
前記パケットは、TSパケットであり、
前記マッピング情報は、MPEG2-TS(Transport Stream)で規定されるPID(Packet ID)の領域に含まれる
前記（１）に記載の送信装置。
（７）
前記PIDの領域には、所定のビットが、PLPの識別情報に割り当てられ、残りのビットが、PIDに割り当てられる
前記（６）に記載の送信装置。
（８）
前記処理部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する
前記（６）に記載の送信装置。
（９）
前記識別情報は、PLP_IDである
前記（１）乃至（８）のいずれかに記載の送信装置。
（１０）
送信装置のデータ処理方法において、
前記送信装置が、
放送信号に含まれる複数のPLPごとに、ストリームを処理して、当該ストリームを構成するパケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を、前記パケットのヘッダに含めるステップを含む
データ処理方法。
（１１）
放送信号に含まれる複数のPLP(Physical Layer Pipe)ごとに得られるストリームを構成するパケットを復調する復調部と、
前記復調部により復調された前記パケットを処理する処理部と
を備え、
前記復調部と前記処理部とは、単一の又はPLPの個数よりも少ないインターフェースを介して接続され、
前記復調部は、前記パケットのヘッダから得られる、当該パケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を処理し、
前記処理部は、前記復調部から単一の又はPLPの個数よりも少ないインターフェースを介して入力される前記パケットのヘッダから得られる前記マッピング情報に基づいて、当該パケットが属していたPLPを識別する
受信装置。
（１２）
前記ストリームは、IP(Internet Protocol)ストリームであり、
前記パケットは、RoHC(Robust Header Compression)で規定されるパケットであり、
前記マッピング情報は、RoHCで規定されるCID(Context Identifier)の領域に含まれる
前記（１１）に記載の受信装置。
（１３）
前記復調部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する
前記（１２）に記載の受信装置。
（１４）
前記ストリームは、TS(Transport Stream)ストリームであり、
前記パケットは、TSパケットであり、
前記マッピング情報は、MPEG2-TS(Transport Stream)で規定されるPID(Packet ID)の領域に含まれる
前記（１１）に記載の受信装置。
（１５）
前記復調部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する
前記（１４）に記載の受信装置。
（１６）
前記識別情報は、PLP_IDである
前記（１１）乃至（１５）のいずれかに記載の受信装置。
（１７）
前記復調部は、復調デバイスであり、
前記処理部は、システムオンチップ（SoC：System on Chip）である
前記（１１）乃至（１６）のいずれかに記載の受信装置。
（１８）
放送信号に含まれる複数のPLPごとに得られるストリームを構成するパケットを復調する復調部と、
前記復調部により復調された前記パケットを処理する処理部と
を有し、
前記復調部と前記処理部とは、単一の又はPLPの個数よりも少ないインターフェースを介して接続される
受信装置のデータ処理方法において、
前記復調部が、前記パケットのヘッダから得られる、当該パケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を処理し、
前記処理部が、前記復調部から単一の又はPLPの個数よりも少ないインターフェースを介して入力される前記パケットのヘッダから得られる前記マッピング情報に基づいて、当該パケットが属していたPLPを識別する
ステップを含むデータ処理方法。
１ 放送システム， １０ 送信装置， ２０ 受信装置， ３０ 伝送路， １１１ マルチプレクサ， １１２ 変調部， ２１１ 復調部， ２１２ 処理部， ２３１ フレーム処理部， ２３２−１乃至２３２−４ FEC処理部， ２３３ 復調マルチプレクサ， ２４１ デマルチプレクサ， ２４２−１乃至２４２−４ カプセル化解除部， １０００ コンピュータ， １００１ CPU

Claims (18)

  1. 放送信号に含まれる複数のPLP(Physical Layer Pipe)ごとに、ストリームを処理して、当該ストリームを構成するパケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を、前記パケットのヘッダに含める処理部を備える
    送信装置。
  2. 前記ストリームは、IP(Internet Protocol)ストリームであり、
    前記パケットは、RoHC(Robust Header Compression)で規定されるパケットであり、
    前記マッピング情報は、RoHCで規定されるCID(Context Identifier)の領域に含まれる
    請求項１に記載の送信装置。
  3. 前記CIDの領域は、前記ヘッダのAdd-CID octet内の領域であって、所定のビットが、PLPの識別情報に割り当てられ、残りのビットが、CIDに割り当てられる
    請求項２に記載の送信装置。
  4. 前記CIDの領域は、前記ヘッダのAdd-CID octet以外のCIDの領域であって、所定のビットが、PLPの識別情報に割り当てられる
    請求項２に記載の送信装置。
  5. 前記処理部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する
    請求項２に記載の送信装置。
  6. 前記ストリームは、TS(Transport Stream)ストリームであり、
    前記パケットは、TSパケットであり、
    前記マッピング情報は、MPEG2-TS(Transport Stream)で規定されるPID(Packet ID)の領域に含まれる
    請求項１に記載の送信装置。
  7. 前記PIDの領域には、所定のビットが、PLPの識別情報に割り当てられ、残りのビットが、PIDに割り当てられる
    請求項６に記載の送信装置。
  8. 前記処理部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する
    請求項６に記載の送信装置。
  9. 前記識別情報は、PLP_IDである
    請求項１に記載の送信装置。
  10. 送信装置のデータ処理方法において、
    前記送信装置が、
    放送信号に含まれる複数のPLPごとに、ストリームを処理して、当該ストリームを構成するパケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を、前記パケットのヘッダに含めるステップを含む
    データ処理方法。
  11. 放送信号に含まれる複数のPLP(Physical Layer Pipe)ごとに得られるストリームを構成するパケットを復調する復調部と、
    前記復調部により復調された前記パケットを処理する処理部と
    を備え、
    前記復調部と前記処理部とは、単一の又はPLPの個数よりも少ないインターフェースを介して接続され、
    前記復調部は、前記パケットのヘッダから得られる、当該パケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を処理し、
    前記処理部は、前記復調部から単一の又はPLPの個数よりも少ないインターフェースを介して入力される前記パケットのヘッダから得られる前記マッピング情報に基づいて、当該パケットが属していたPLPを識別する
    受信装置。
  12. 前記ストリームは、IP(Internet Protocol)ストリームであり、
    前記パケットは、RoHC(Robust Header Compression)で規定されるパケットであり、
    前記マッピング情報は、RoHCで規定されるCID(Context Identifier)の領域に含まれる
    請求項１１に記載の受信装置。
  13. 前記復調部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、CIDが重複しないように管理する
    請求項１２に記載の受信装置。
  14. 前記ストリームは、TS(Transport Stream)ストリームであり、
    前記パケットは、TSパケットであり、
    前記マッピング情報は、MPEG2-TS(Transport Stream)で規定されるPID(Packet ID)の領域に含まれる
    請求項１１に記載の受信装置。
  15. 前記復調部は、前記マッピング情報として、複数のPLPで構成される１つのサービス内で、PIDが重複しないように管理する
    請求項１４に記載の受信装置。
  16. 前記識別情報は、PLP_IDである
    請求項１１に記載の受信装置。
  17. 前記復調部は、復調デバイスであり、
    前記処理部は、システムオンチップ（SoC：System on Chip）である
    請求項１１に記載の受信装置。
  18. 放送信号に含まれる複数のPLPごとに得られるストリームを構成するパケットを復調する復調部と、
    前記復調部により復調された前記パケットを処理する処理部と
    を有し、
    前記復調部と前記処理部とは、単一の又はPLPの個数よりも少ないインターフェースを介して接続される
    受信装置のデータ処理方法において、
    前記復調部が、前記パケットのヘッダから得られる、当該パケットが属するPLPを識別可能な識別情報にマッピングされたマッピング情報を処理し、
    前記処理部が、前記復調部から単一の又はPLPの個数よりも少ないインターフェースを介して入力される前記パケットのヘッダから得られる前記マッピング情報に基づいて、当該パケットが属していたPLPを識別する
    ステップを含むデータ処理方法。
JP2019505852A 2017-03-14 2018-02-28 送信装置、受信装置、及び、データ処理方法 Active JP7139310B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2017049172 2017-03-14
JP2017049172 2017-03-14
PCT/JP2018/007407 WO2018168455A1 (ja) 2017-03-14 2018-02-28 送信装置、受信装置、及び、データ処理方法

Publications (2)

Publication Number Publication Date
JPWO2018168455A1 true JPWO2018168455A1 (ja) 2020-01-16
JP7139310B2 JP7139310B2 (ja) 2022-09-20

Family

ID=63523292

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019505852A Active JP7139310B2 (ja) 2017-03-14 2018-02-28 送信装置、受信装置、及び、データ処理方法

Country Status (7)

Country Link
US (1) US11889145B2 (ja)
EP (1) EP3598763A4 (ja)
JP (1) JP7139310B2 (ja)
KR (1) KR102514752B1 (ja)
CN (1) CN110402582B (ja)
TW (1) TWI673984B (ja)
WO (1) WO2018168455A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200213423A1 (en) * 2019-01-02 2020-07-02 Qualcomm Incorporated Systems, methods, and computing platforms for context identifier allocation for data packet header compression

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016171496A1 (ko) * 2015-04-23 2016-10-27 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017065020A1 (ja) * 2015-10-15 2017-04-20 ソニー株式会社 受信装置、送信装置、及び、データ処理方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010050656A1 (en) * 2008-10-31 2010-05-06 Lg Electronics Inc. Apparatus for transmitting and receiving a signal and method of transmitting and receiving a signal
EP2362653A1 (en) * 2010-02-26 2011-08-31 Panasonic Corporation Transport stream packet header compression
KR101874433B1 (ko) 2011-06-16 2018-07-06 삼성전자주식회사 디지털 방송 시스템에서 방송 서비스 수신을 위한 시그널링 정보를 송수신하는 방법 및 장치
CN106464635B (zh) * 2014-04-21 2020-01-21 Lg电子株式会社 广播信号发送设备、广播信号接收设备、广播信号发送方法以及广播信号接收方法
WO2016064150A1 (ko) 2014-10-20 2016-04-28 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
WO2016132899A1 (ja) * 2015-02-17 2016-08-25 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
MX2020011942A (es) * 2015-08-31 2022-12-14 Samsung Electronics Co Ltd Aparato y método para transmitir y recibir señal en sistema multimedia.

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016171496A1 (ko) * 2015-04-23 2016-10-27 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017065020A1 (ja) * 2015-10-15 2017-04-20 ソニー株式会社 受信装置、送信装置、及び、データ処理方法

Also Published As

Publication number Publication date
US11889145B2 (en) 2024-01-30
CN110402582A (zh) 2019-11-01
KR20190126319A (ko) 2019-11-11
JP7139310B2 (ja) 2022-09-20
TW201836338A (zh) 2018-10-01
WO2018168455A1 (ja) 2018-09-20
EP3598763A1 (en) 2020-01-22
KR102514752B1 (ko) 2023-03-28
US20190356946A1 (en) 2019-11-21
CN110402582B (zh) 2022-10-04
EP3598763A4 (en) 2020-01-22
TWI673984B (zh) 2019-10-01

Similar Documents

Publication Publication Date Title
US10334088B2 (en) Transmitting apparatus and signal processing method thereof
US11677865B2 (en) Transmitting apparatus and signal processing method thereof
KR102515018B1 (ko) 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
JP2016208161A (ja) 送信装置、送信方法、受信装置、及び、受信方法
KR20210034571A (ko) 송신 장치, 수신 장치 및 그 제어 방법
US11838099B2 (en) Reception apparatus and data processing method
KR102514752B1 (ko) 송신 장치, 수신 장치 및 데이터 처리 방법
KR102062897B1 (ko) 송신 장치, 수신 장치 및 그 신호 처리 방법
US20240137603A1 (en) Transmission apparatus, reception apparatus, and data processing method
CN111447243B (zh) 发送装置和接收装置及其信号处理方法
KR20200003769A (ko) 송신 장치, 수신 장치 및 그 신호 처리 방법
WO2016181806A1 (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: 20190802

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220411

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220907

R150 Certificate of patent or registration of utility model

Ref document number: 7139310

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150