(57)【要約】  本技術は、パケットが無駄に破棄されるのを防止することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置は、復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される伝送パケットのヘッダに含まれる誤り検出符号を用いて、誤り検出処理を行う。本技術は、例えば、ATSC3.0等の放送規格に準拠したデータ伝送に適用することができる。
2017145790.tif 000002
【特許請求の範囲】
【請求項１】
復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを配置したペイロードとから構成される前記伝送パケットを処理する処理部を備え、
前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
受信装置。
【請求項２】
前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いた誤り検出処理によりエラーが検出された場合、前記エラーの検出位置に応じた処理を行う
請求項１に記載の受信装置。
【請求項３】
前記処理部は、前記エラーの検出位置が、前記伝送パケットのペイロードである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを抽出してそのまま処理する
請求項２に記載の受信装置。
【請求項４】
前記伝送パケットは、前記エラーの検出位置が、前記伝送パケットのヘッダである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを破棄する
請求項２に記載の受信装置。
【請求項５】
前記誤り検出符号は、巡回冗長検査（CRC：Cyclic Redundancy Check）である
請求項１に記載の受信装置。
【請求項６】
前記伝送パケットは、可変長のパケットであり、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
請求項１に記載の受信装置。
【請求項７】
受信装置のデータ処理方法において、
前記受信装置が、
復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
ステップを含むデータ処理方法。
【請求項８】
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成する処理部を備え、
前記処理部は、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
送信装置。
【請求項９】
送信装置のデータ処理方法において、
前記送信装置が、
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成し、
前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
ステップを含むデータ処理方法。
【請求項１０】
復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットを処理する処理部を備え、
前記処理部は、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
受信装置。
【請求項１１】
前記誤り検出符号は、巡回冗長検査（CRC）である
請求項１０に記載の受信装置。
【請求項１２】
前記伝送パケットは、可変長のパケットであり、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
請求項１０に記載の受信装置。
【請求項１３】
受信装置のデータ処理方法において、
前記受信装置が、
復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
ステップを含むデータ処理方法。
【請求項１４】
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成する処理部を備え、
前記処理部は、前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
送信装置。
【請求項１５】
送信装置のデータ処理方法において、
前記送信装置が、
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成し、
前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、パケットが無駄に破棄されるのを防止することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
現在、次世代地上放送規格の１つであるATSC(Advanced Television Systems Committee)3.0の策定が進められている（例えば、非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ATSC Candidate Standard：Physical Layer Protocol（Doc. S32-230r21 28 September 2015）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、ATSC3.0等の放送規格では、パケット単位でデータを伝送することが規定されているが、パケット内のデータでエラーが発生した場合に、パケットが無駄に破棄されるときがあった。そのため、パケット内のデータでエラーが発生した場合であっても、パケットが無駄に破棄されるのを防止するための提案が要請されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、パケットが無駄に破棄されるのを防止することができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを配置したペイロードとから構成される前記伝送パケットを処理する処理部を備え、前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う受信装置である。【０００７】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【０００８】
本技術の第１の側面の受信装置、及び、データ処理方法においては、復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットが処理され、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理が行われる。【０００９】
本技術の第２の側面の送信装置は、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成する処理部を備え、前記処理部は、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する送信装置である。【００１０】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１１】
本技術の第２の側面の送信装置、及び、データ処理方法においては、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットが生成され、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットが配置される。【００１２】
本技術の第３の側面の受信装置は、復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットを処理する処理部を備え、前記処理部は、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う受信装置である。【００１３】
本技術の第３の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第３の側面のデータ処理方法は、上述した本技術の第３の側面の受信装置に対応するデータ処理方法である。【００１４】
本技術の第３の側面の受信装置、及び、データ処理方法においては、復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットが処理され、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理が行われる。【００１５】
本技術の第４の側面の送信装置は、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成する処理部を備え、前記処理部は、前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する送信装置である。【００１６】
本技術の第４の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第４の側面のデータ処理方法は、上述した本技術の第４の側面の送信装置に対応するデータ処理方法である。【００１７】
本技術の第４の側面の送信装置、及び、データ処理方法においては、変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットが生成され、前記ベースバンドパケットのヘッダに、誤り検出符号が配置され、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットが配置される。
【発明の効果】
【００１８】
本技術の第１の側面乃至第４の側面によれば、パケットが無駄に破棄されるのを防止することができる。【００１９】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００２０】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】送信装置の構成例を示す図である。
【図３】受信装置の構成例を示す図である。
【図４】本技術で用いられるパケットの相関を示す図である。
【図５】BBパケットに付加されるBBヘッダの構造を示す図である。
【図６】オプショナルフィールドフラグの例を示す図である。
【図７】ALPパケットのALPヘッダのシンタックスの例を示す図である。
【図８】additional_header_for_single_packet()のシンタックスの例を示す図である。
【図９】additional_header_for_segmentation()のシンタックスの例を示す図である。
【図１０】additional_header_for_concatenation()のシンタックスの例を示す図である。
【図１１】sub_stream_identification()のシンタックスの例を示す図である。
【図１２】header_extension()のシンタックスの例を示す図である。
【図１３】現状のパケット処理を説明する図である。
【図１４】現状のパケット処理の流れを説明するフローチャートである。
【図１５】ALPパケットのシンタックスの例を示す図である。
【図１６】パケットタイプの例を示す図である。
【図１７】ALPパケットの拡張ヘッダのシンタックスの例を示す図である。
【図１８】拡張データタイプの例を示す図である。
【図１９】拡張データにCRCを配置する場合のデータ構造の例を示す図である。
【図２０】拡張データタイプの他の例を示す図である。
【図２１】BBパケットのBBヘッダにCRCを配置する場合の構造の例を示す図である。
【図２２】本技術のパケット処理（ケース１）を説明する図である。
【図２３】本技術のパケット処理（ケース２）を説明する図である。
【図２４】送信側データ処理の流れを説明するフローチャートである。
【図２５】受信側データ処理の流れを説明するフローチャートである。
【図２６】本技術のパケット処理の流れを説明するフローチャートである。
【図２７】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００２１】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００２２】
１．システムの構成
２．現状の規格の概要
３．本技術の実施の形態
（１）第１の方式：ALPヘッダに誤り検出符号を配置
（２）第２の方式：BBヘッダに誤り検出符号を配置
（３）本技術のパケット処理
４．変形例
５．コンピュータの構成
【００２３】
＜１．システムの構成＞
【００２４】
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００２５】
図１において、伝送システム１は、送信装置１０と受信装置２０から構成される。この伝送システム１では、ATSC3.0等のデジタル放送の規格に準拠したデータ伝送が行われる。
【００２６】
なお、次世代地上放送規格の１つであるATSC3.0では、データ伝送に、主として、TS(Transport Stream)パケットではなく、UDP/IPパケット、すなわち、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを用いる方式が採用されることが想定されている。また、ATSC3.0以外の放送方式でも、将来的に、IPパケットを用いた方式が採用されることが期待されている。
【００２７】
送信装置１０は、伝送路３０を介してコンテンツを送信する。例えば、送信装置１０は、放送番組等のコンテンツを構成するビデオやオーディオ等（のコンポーネント）とシグナリングを含む放送ストリームを、放送波として伝送路３０を介して送信する。
【００２８】
受信装置２０は、送信装置１０から伝送路３０を介して送信されてくる、コンテンツを受信して出力する。例えば、受信装置２０は、送信装置１０からの放送波を受信して、放送ストリームから、コンテンツを構成するビデオやオーディオ等（のコンポーネント）とシグナリングを取得し、放送番組等のコンテンツの映像や音声を再生する。
【００２９】
なお、図１の伝送システム１においては、説明を簡単にするために、受信装置２０を１つだけ図示しているが、受信装置２０は複数設けることができ、送信装置１０が送信（一斉同報配信）する放送波は、伝送路３０を介して複数の受信装置２０で同時に受信することができる。
【００３０】
また、図１の伝送システム１においては、送信装置１０も複数設けることができる。複数の送信装置１０のそれぞれでは、別個のチャネルとしての、例えば、別個の周波数帯域で、放送ストリームを含む放送波を送信し、受信装置２０では、複数の送信装置１０のそれぞれのチャンネルの中から、放送ストリームを受信するチャネルを選択することができる。
【００３１】
さらに、図１の伝送システム１において、伝送路３０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
【００３２】
（送信装置の構成例）
図２は、図１の送信装置１０の構成例を示す図である。
【００３３】
図２において、送信装置１０は、AVエンコーダ１０１、FLUTEエンコーダ１０２、UDP/IPパケタイザ１０３、ALPパケタイザ１０４、BBパケタイザ１０５、スクランブラ１０６、BCHエンコーダ１０７、LDPCエンコーダ１０８、パリティインターリーバ１０９、カラムツイストインターリーバ１１０、データマッパ１１１、CQディレイ部１１２、セルインターリーバ１１３、時間インターリーバ１１４、フレームマッパ１１５、周波数インターリーバ１１６、OFDM送信部１１７、及びRF出力部１１８から構成される。
【００３４】
AVエンコーダ１０１は、ビデオやオーディオ（のコンポーネント）のデータを、所定の符号化方式に従い、エンコードし、FLUTEエンコーダ１０２に供給する。FLUTEエンコーダ１０２は、AVエンコーダ１０１からのデータを処理（エンコード）して、FLUTE(File Delivery over Unidirectional Transport)形式に対応したデータを生成し、UDP/IPパケタイザ１０３に供給する。
【００３５】
UDP/IPパケタイザ１０３は、FLUTEエンコーダ１０２からのデータを処理して、UDPパケットを含むIPパケット（UDP/IPパケット）を生成し、ALPパケタイザ１０４に供給する。ALPパケタイザ１０４は、UDP/IPパケタイザ１０３からのUDP/IPパケットを処理して、ALP(ATSC Link layer Protocol)パケットを生成し、BBパケタイザ１０５に供給する。
【００３６】
BBパケタイザ１０５は、ALPパケタイザ１０４からのALPパケットを処理して、BB(BaseBand)パケットを生成し、スクランブラ１０６に供給する。スクランブラ１０６は、BBパケタイザ１０５からのデータ（BBパケット）にスクランブルを施し、その結果得られるデータを、BCHエンコーダ１０７に供給する。
【００３７】
BCHエンコーダ１０７は、スクランブラ１０６からのデータをBCH(Bose-Chaudhuri-Hocquenghem)符号化し、その結果得られるデータを、LDPCエンコーダ１０８に供給する。LDPCエンコーダ１０８は、BCHエンコーダ１０７からのデータをLDPC(Low Density Parity Check)符号化し、その結果得られるデータを、パリティインターリーバ１０９に供給する。
【００３８】
パリティインターリーバ１０９は、LDPCエンコーダ１０８からのデータに対し、パリティインターリーブを行い、そのパリティインターリーブ後のデータを、カラムツイストインターリーバ１１０に供給する。カラムツイストインターリーバ１１０は、パリティインターリーバ１０９からのデータに対し、カラムツイストインターリーブを行い、そのカラムツイストインターリーブ後のデータを、データマッパ１１１に供給する。
【００３９】
データマッパ１１１は、カラムツイストインターリーバ１１０からのデータを、そのデータ（LDPC符号）の１ビット以上の符号ビットの単位（シンボル単位）で、直交変調の１つのシンボルを表す信号点にマッピングして直交変調（多値変調）を行う。データマッパ１１１での処理により得られるデータは、CQディレイ部１１２を介して、セルインターリーバ１１３に供給される。
【００４０】
セルインターリーバ１１３は、CQディレイ部１１２からのデータに対し、セルインターリーブを行い、そのセルインターリーブ後のデータを、時間インターリーバ１１４に供給する。時間インターリーバ１１４は、セルインターリーバ１１３からのデータに対し、時間インターリーブを行い、時間インターリーブ後のデータを、フレームマッパ１１５に供給する。
【００４１】
フレームマッパ１１５は、時間インターリーバ１１４からのデータに対し、フレーム（物理層フレーム）に関する処理を行い、その結果得られるデータを、周波数インターリーバ１１６に供給する。周波数インターリーバ１１６は、フレームマッパ１１５からのデータに対し、周波数インターリーブを行い、その周波数インターリーブ後のデータを、OFDM送信部１１７に供給する。
【００４２】
OFDM送信部１１７は、周波数インターリーバ１１６からのデータを処理して、OFDM(Orthogonal Frequency Division Multiplexing)信号を生成し、RF出力部１１８に供給する。RF出力部１１８は、アンテナ（不図示）と接続され、OFDM送信部１１７からのOFDM信号を、RF(Radio Frequency)信号として、伝送路３０を介して送信する。
【００４３】
送信装置１０は、以上のように構成される。
【００４４】
（受信装置の構成例）
図３は、図１の受信装置２０の構成例を示す図である。
【００４５】
図３において、受信装置２０は、RF入力部２０１、OFDM受信部２０２、周波数デインターリーバ２０３、フレームデマッパ２０４、時間デインターリーバ２０５、セルデインターリーバ２０６、CQディレイ部２０７、データデマッパ２０８、カラムツイストデインターリーバ２０９、パリティデインターリーバ２１０、LDPCデコーダ２１１、BCHデコーダ２１２、デスクランブラ２１３、BBデパケタイザ２１４、ALPデパケタイザ２１５、UDP/IPデパケタイザ２１６、FLUTEデコーダ２１７、及びAVデコーダ２１８から構成される。
【００４６】
RF入力部２０１は、アンテナ（不図示）と接続され、送信装置１０から伝送路３０を介して送信されてくるRF信号を受信し、OFDM信号として、OFDM受信部２０２に供給する。OFDM受信部２０２は、RF入力部２０１からのOFDM信号を処理し、それにより得られるデータを、周波数デインターリーバ２０３に供給する。
【００４７】
周波数デインターリーバ２０３は、OFDM受信部２０２からのデータに対し、周波数デインターリーブを行い、その周波数デインターリーブ後のデータを、フレームデマッパ２０４に供給する。フレームデマッパ２０４は、周波数デインターリーバ２０３からのデータに対し、フレーム（物理層フレーム）に関する処理を行い、その結果得られるデータを、時間デインターリーバ２０５に供給する。
【００４８】
時間デインターリーバ２０５は、フレームデマッパ２０４からのデータに対し、時間デインターリーブを行い、その時間デインターリーブ後のデータを、セルデインターリーバ２０６に供給する。セルデインターリーバ２０６は、時間デインターリーバ２０５からのデータに対し、セルデインターリーブを行い、そのセルデインターリーブ後のデータを、CQディレイ部２０７を介して、データデマッパ２０８に供給する。
【００４９】
データデマッパ２０８は、CQディレイ部２０７からのデータ（コンスタレーション上のデータ）を、送信装置１０側で行われる直交変調で定められる信号点の配置（コンスタレーション）に基づいて、デマッピング（信号点配置復号）して直交復調し、その結果得られるデータ（LDPC符号）を、カラムツイストデインターリーバ２０９に供給する。
【００５０】
カラムツイストデインターリーバ２０９は、データデマッパ２０８からのデータに対し、カラムツイストデインターリーブを行い、そのカラムツイストデインターリーブ後のデータを、パリティデインターリーバ２１０に供給する。パリティデインターリーバ２１０は、カラムツイストデインターリーバ２０９からのデータに対し、パリティデインターリーブを行い、そのパリティデインターリーブ後のデータを、LDPCデコーダ２１１に供給する。
【００５１】
LDPCデコーダ２１１は、パリティデインターリーバ２１０からのデータをLDPC復号化し、その結果得られるデータを、BCHデコーダ２１２に供給する。BCHデコーダ２１２は、LDPCデコーダ２１１からのデータをBCH復号化し、その結果得られるデータを、デスクランブラ２１３に供給する。デスクランブラ２１３は、BCHデコーダ２１２からのデータにデスクランブルを施し、その結果得られるデータを、BBデパケタイザ２１４に供給する。
【００５２】
BBデパケタイザ２１４は、デスクランブラ２１３からのデータからBBパケットを抽出して処理し、その結果得られるデータを、ALPデパケタイザ２１５に供給する。また、BBデパケタイザ２１４には、LDPCデコーダ２１１又はBCHデコーダ２１２からエラー訂正情報が入力される。このエラー訂正情報は、LDPC復号化やBCH復号化の処理でエラーが発生したことを示す情報であり、BBデパケタイザ２１４では、エラー訂正情報によって、LDPC復号化やBCH復号化で訂正不可能なデータが存在することを認識することができる。
【００５３】
ALPデパケタイザ２１５は、BBデパケタイザ２１４からのデータからALPパケットを抽出して処理し、その結果得られるデータを、UDP/IPデパケタイザ２１６に供給する。UDP/IPデパケタイザ２１６は、ALPデパケタイザ２１５からのデータからUDP/IPパケットを抽出して処理し、その結果得られるデータを、FLUTEデコーダ２１７に供給する。
【００５４】
FLUTEデコーダ２１７は、UDP/IPデパケタイザ２１６からのデータ（FLUTE形式に対応したデータ）を処理（デコード）して、その結果得られるデータを、AVデコーダ２１８に供給する。AVデコーダ２１８は、FLUTEデコーダ２１７からのデータを、所定の復号方式に従い、デコードし、その結果得られるビデオやオーディオ（のコンポーネント）のデータを出力する。
【００５５】
受信装置２０は、以上のように構成される。
【００５６】
＜２．現状の規格の概要＞
【００５７】
（パケットの相関図）
図４は、本技術で用いられるパケットの相関を示す図である。
【００５８】
本技術では、レイヤごとに、複数の種類のパケットが利用される。BB(BaseBand)パケットは、ベースバンドのレイヤ１のパケットである。ALP(ATSC Link layer Protocol)パケットは、レイヤ１の上位階層であるレイヤ２のパケット（伝送パケット）である。IP(Internet Protocol)パケットは、レイヤ２の上位階層であるレイヤ３のパケットである。また、IPパケットには、UDP(User Datagram Protocol)パケットが含まれる。
【００５９】
BBパケットは、BBヘッダ（BB Header）とペイロード（BB packet payload）から構成される。BBパケットのペイロードには、１又は複数のALPパケットが配置される。BBヘッダには、パケット長とポインタなどの情報が含まれる。このポインタは、BBパケットのペイロードに配置される先頭のALPパケットの位置を表している。以下の説明では、このポインタを、先頭ALPポインタと称する。
【００６０】
なお、BBパケットのBBヘッダの詳細な構造は、図５及び図６を参照して後述する。また、BBパケットの最大サイズは、8196バイトとされる。
【００６１】
ALPパケットは、ALPヘッダ（ALP Header）とペイロード（ALP payload）から構成される。ALPパケットのペイロードには、１又は複数のIPパケットが配置される。ALPパケットのALPヘッダには、パケット長などの情報が含まれる。また、ALPパケットは可変長であり、その最大サイズは、65536バイトとされる。
【００６２】
ここで、BBパケットのペイロードに配置される１又は複数のALPパケットは、BBヘッダの先頭ALPポインタと、ALPヘッダのパケット長（ALPパケットのパケット長）を用いることで、抽出することができる。すなわち、あるBBパケットにおいて、先頭ALPポインタを用いて、あるALPパケットの位置が特定されれば、仮に、次のBBパケットにまたがってALPパケットが配置されている場合でも、ALPヘッダのパケット長を用いることで、次のALPパケットの位置を特定することができる。
【００６３】
例えば、図４においては、３個のBBパケットに対し、３個のALPパケットが配置される場合を例示しているが、BBパケットによっては、複数のBBパケットをまたいで配置されるALPパケットが存在している。この例では、２番目のALPパケットが、１番目乃至３番目のBBパケットをまたいで配置されている。
【００６４】
この場合において、１番目（先頭）のALPパケットは、１番目（先頭）のBBパケットのBBヘッダの先頭ALPポインタによりその位置が特定されることで、１番目（先頭）のBBパケットのペイロードから抽出される。同様に、３番目のALPパケットは、３番目のBBパケットのBBヘッダの先頭ALPポインタによりその位置が特定されることで、３番目のBBパケットのペイロードから抽出される。
【００６５】
一方で、２番目のALPパケットは、１番目と２番目のALPパケットのALPヘッダのパケット長により、（１番目のBBパケットのBBヘッダの）先頭ALPポインタからそのパケット長に応じた位置が特定されることで、１番目乃至３番目のBBパケットのペイロードから抽出される。なお、この例では、２番目のBBパケットには、ALPパケットの先頭が存在しないため、２番目のBBパケットのBBヘッダの先頭ALPポインタの値は、"0"とされる。
【００６６】
なお、ALPパケットのALPヘッダとしては、基本のヘッダ（ALP Base Hdr）であるALPパケットヘッダ（ALP_packet_header）のほか、アディショナルなヘッダ（ALP Add Hdr）である追加ヘッダ（additional_header）と、オプショナルなヘッダ（ALP Opt Hdr）である拡張ヘッダ（header_extension）を配置することができる。なお、ALPパケットのALPヘッダの詳細な構造は、図７乃至図１２を参照して後述する。
【００６７】
IPパケットは、IPヘッダ（IP Header）とデータ部（Data）から構成される。IPパケットのデータ部には、UDPパケットが配置される。IPパケットのIPヘッダは、Version(Ver)，Header Length(Head Len)，Service，Total Length(Total Len)，ID，Flag，Flag offset，TTL(Time To Live)，Protocol，Checksum，Source IP address(Src Add)，Destination IP address(Dest Add)，及び、Optionを有する。なお、IPパケットの最大サイズは、65536バイトとされる。
【００６８】
UDPパケットは、UDPヘッダ（UDP Header）とデータ部（Data）から構成される。UDPパケットのデータ部には、ビデオやオーディオ等のコンポーネントや、シグナリングのデータが配置される。UDPパケットのUDPヘッダは、Source port number(Src Port)，Destination port number(Dest Port)，Length，及び、Checksumを有する。なお、UDPパケットの最大サイズは、65507バイトとされる。
【００６９】
（BBヘッダの構造）
図５は、BBパケットに付加されるBBヘッダの構造を示す図である。
【００７０】
図５において、BBパケットは、BBヘッダとペイロード（Payload）から構成される。BBヘッダには、1又は2バイトのベースフィールド（Base Field）のほか、オプショナルフィールド（Optional Field）と、拡張フィールド（Extension Field）を配置することができる。
【００７１】
すなわち、ベースフィールドにおいて、1ビットのモード（MODE）として、"0"が設定された場合には、7ビットのポインタ（Pointer(LSB)）が配置される。このポインタは、上述した先頭ALPポインタであって、BBパケットのペイロードに配置される先頭のALPパケットの位置を表している。例えば、あるBBパケットに最後に配置されたALPパケットのデータが、次のBBパケットにまたがって配置される場合に、先頭ALPポインタとして、次のBBパケットに配置される先頭のALPパケットの位置を設定することができる。
【００７２】
また、モード（MODE）として、"1"が設定された場合には、7ビットのポインタ（Pointer(LSB)）のほかに、6ビットのポインタ（Pointer(MSB)）と、2ビットのオプショナルフラグ（OPTI：OPTIONAL）が配置される。オプショナルフラグは、オプショナルフィールド（Optional Field）と、拡張フィールド（Extension Field）を配置して、ヘッダを拡張するかどうかを示す情報である。
【００７３】
ここで、図６に示すように、オプショナルフィールドと拡張フィールドの拡張を行わない場合、オプショナルフラグには、"00"が設定される。また、1バイトのオプショナルフィールドと、拡張フィールドの拡張を行う場合、オプショナルフラグには、"01"が設定され、ショート拡張モード（Short Extension Mode）となる。一方で、2バイトのオプショナルフィールドと、拡張フィールドの拡張を行う場合、オプショナルフラグは、"10"又は"11"が設定され、ロング拡張モード（Long Extension Mode）又はミックス拡張モード（Mixed Extension Mode）となる。
【００７４】
図５の説明に戻り、オプショナルフィールドの先頭には、3ビットの拡張タイプ（EXT_TYPE）が設定される。この拡張タイプには、拡張フィールドのタイプ（Extension type）が設定される。ショート拡張モードの場合には、拡張タイプ（EXT_TYPE）に続いて、5ビットの拡張データ長（EXT_LEN）と、0〜31バイトの拡張データ（Extension）が配置される。
【００７５】
ロング拡張モードの場合には、拡張タイプ（EXT_TYPE）に続いて、5ビットの拡張データ長（EXT_LEN(LSB)）と、8ビットの拡張データ長（EXT_LEN(MSB)）と、0〜full BBPの拡張データ（Extension）が配置される。なお、ミックス拡張モードは、ロング拡張モードと基本的に同様であるため、その説明は省略する。
【００７６】
以上、BBヘッダの構造について説明した。次に、図７乃至図１２を参照して、ALPパケットに付加されるALPヘッダについて説明する。
【００７７】
（ALPヘッダの構造）
図７は、ALPヘッダのシンタックスの例を示す図である。
【００７８】
3ビットのpacket_typeは、ALPパケットのパケットタイプを示す。1ビットのpayload_configurationは、ALPヘッダに設定される情報に応じて、"0"又は"1"が設定される。
【００７９】
payload_configurationとして、"0"が指定された場合、ALPヘッダには、header_mode，lengthが配置される。1ビットのheader_modeは、ヘッダモードを示す。11ビットのlengthは、ALPパケットのパケット長（ALPパケット長）を示す。
【００８０】
header_modeとして、"1"が指定された場合、ALPヘッダには、追加ヘッダとして、additional_header_for_single_packet()が配置される。このadditional_header_for_single_packet()の詳細な構造については、図８を参照して後述する。
【００８１】
payload_configurationとして、"1"が指定された場合、ALPヘッダには、segmentation_concatenation，lengthが配置される。1ビットのsegmentation_concatenationは、追加ヘッダの種別に応じて、"0"又は"1"が設定される。11ビットのlengthは、ALPパケットのパケット長（ALPパケット長）を示す。
【００８２】
segmentation_concatenationとして、"0"が指定された場合、ALPヘッダには、追加ヘッダとして、additional_header_for_segmentation()が配置される。このadditional_header_for_segmentation()の詳細な構造については、図９を参照して後述する。
【００８３】
segmentation_concatenationとして、"1"が指定された場合、ALPヘッダには、追加ヘッダとして、additional_header_for_concatenation()が配置される。なお、このadditional_header_for_concatenation()の詳細な構造については、図１０を参照して後述する。
【００８４】
なお、フォーマット（Format）として、uimsbf(unsigned integer most significant bit first)が指定された場合、ビット演算をして、整数として扱われることを意味する。また、bslbf(bit string, left bit first)が指定された場合には、ビット列として扱われることを意味する。
【００８５】
（additional_header_for_single_packetの構造）
図８は、図７のadditional_header_for_single_packet()のシンタックスの例を示す図である。
【００８６】
5ビットのlength_MSBは、最上位ビット（MSB：Most Significant Bit）のパケット長を示す。1ビットのSIFは、サブストリームID（sub_stream_identification）が存在するかどうかのフラグを示す。サブストリームIDが存在する場合、SIF="1"とされる。
【００８７】
1ビットのHEFは、拡張ヘッダ（header_extension）が存在するかどうかのフラグを示す。拡張ヘッダが存在する場合、HEF="1"とされる。
【００８８】
SIFとして、"1"が指定される場合、ALPヘッダには、sub_stream_identification()が配置される。このsub_stream_identification()の詳細な構造については、図１１を参照して後述する。
【００８９】
HEFとして、"1"が指定される場合、ALPヘッダには、拡張ヘッダとして、header_extension()が配置される。このheader_extension()の詳細な構造については、図１２を参照して後述する。
【００９０】
（additional_header_for_segmentationの構造）
図９は、図７のadditional_header_for_segmentation()のシンタックスの例を示す図である。
【００９１】
5ビットのsegment_sequence_numberは、セグメントシーケンス番号を示す。1ビットのlast_segment_indicatorは、最後のセグメントのインジケータを示す。
【００９２】
SIFは、サブストリームIDが存在するかどうかのフラグを示す。SIFとして、"1"が指定される場合、ALPヘッダには、sub_stream_identification()が配置される。また、HEFは、拡張ヘッダが存在するかどうかのフラグを示す。HEFとして、"1"が指定される場合、ALPヘッダには、header_extension()が配置される。なお、sub_stream_identification()と、header_extension()の詳細な構造は、図１１と、図１２を参照して後述する。
【００９３】
（additional_header_for_concatenationの構造）
図１０は、図７のadditional_header_for_concatenation()のシンタックスの例を示す図である。
【００９４】
5ビットのlength_MSBは、最上位ビット（MSB）のパケット長を示す。3ビットのcountは、カウント値を示す。このカウント値に応じて、12ビットのcomponent_lengthが配置される。component_lengthは、コンポーネント長を示す。
【００９５】
1ビットのHEFは、拡張ヘッダが存在するかどうかのフラグを示す。HEFとして、"1"が指定される場合、ALPヘッダには、header_extension()が配置される。なお、header_extension()の詳細な構造は、図１２を参照して後述する。
【００９６】
（sub_stream_identificationの構造）
図１１は、図８及び図９のsub_stream_identification()のシンタックスの例を示す図である。
【００９７】
8ビットのSIDは、サブストリームIDを示す。
【００９８】
（header_extensionの構造）
図１２は、図８乃至図１０のheader_extension()のシンタックスの例を示す図である。
【００９９】
8ビットのextension_typeは、拡張タイプを示す。8ビットのextension_lengthは、拡張データ長を示す。拡張データ長に応じた拡張ループ内には、8ビットのextension_byteが配置される。このextension_byteとしては、extension_typeにより指定される拡張タイプのデータが、extension_lengthで指定される拡張データ長に応じて配置されることになる。
【０１００】
なお、以下の説明では、ALPヘッダの拡張ヘッダ（header_extension）のextension_typeにより指定される「拡張タイプ」を、図５に示したBBヘッダのオプショナルフィールド（Optional Field）の拡張タイプ（EXT_TYPE）と区別するために、便宜的に「拡張データタイプ」と称するものとする。
【０１０１】
以上、ALPヘッダの構造について説明した。
【０１０２】
（現状のパケット処理の問題点）
上述したように、受信装置２０（のBBデパケタイザ２１４）において、BBパケットのペイロードに配置される１又は複数のALPパケットは、BBヘッダの先頭ALPポインタと、ALPヘッダのパケット長（ALPパケットのパケット長）を用いることで、BBパケットから読み出されることになる。
【０１０３】
一方で、その前段のLDPCデコーダ２１１によるLDPC復号化や、BCHデコーダ２１２によるBCH復号化の処理で、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合、その旨を通知するためのエラー訂正情報が、BBデパケタイザ２１４に通知されることになる。
【０１０４】
BBデパケタイザ２１４では、このエラー訂正情報によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生したことを認識することはできるものの、エラーの有無を示す情報しか通知されないため、データのどの位置でエラーが発生しているのかを認識することができない。
【０１０５】
そのため、例えば、現状のATSC3.0では、あるBBパケットにおいて、LDPCやBCHによる誤り訂正が不可能なデータが存在する場合には、当該BBパケットのペイロードに配置される、すべてのALPパケットを破棄する（FECブロックに含まれるALPパケットをすべて破棄する）ことになる。このようにすべてのALPパケットを破棄してしまうと、結果として、エラーの発生していないデータを含むALPパケットまでも破棄してしまうことになる。
【０１０６】
図１３は、現状のパケット処理を説明する図である。
【０１０７】
図１３の現状のパケット処理においては、BBパケットのペイロードに配置される、複数のALPパケットのうち、先頭のALPパケットのペイロードで、LDPCやBCHによる誤り訂正が不可能なエラーが発生している。BBデパケタイザ２１４では、エラー訂正情報によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生していることは認識できるが、エラーの発生位置までを特定することができないため、当該エラーが発生した先頭のALPパケットのみならず、BBパケットのペイロードに配置される、すべてのALPパケットを破棄する。
【０１０８】
そのため、実際には、BBパケットのペイロードに配置される、先頭のALPパケット（のペイロード）でのみエラーが発生しているにもかかわらず、当該エラーが発生した先頭のALPパケットだけでなく、BBパケットのペイロード内のすべてのALPパケット（エラーのないALPパケットを含む）を抽出することができなくなる。
【０１０９】
（現状のパケット処理）
ここで、図１４のフローチャートを参照して、現状のパケット処理の流れについて説明する。なお、この現状のパケット処理は、受信装置２０（図１）のBBデパケタイザ２１４乃至UDP/IPデパケタイザ２１６（図３）などにより実行される。
【０１１０】
ステップＳ５１１において、BBデパケタイザ２１４は、次の処理対象のBBパケットを取得する。ステップＳ５１２において、BBデパケタイザ２１４は、LDPCデコーダ２１１又はBCHデコーダ２１２からのエラー訂正情報に基づいて、ステップＳ５１１の処理で取得されたBBパケット（のペイロードに配置される複数のALPパケット）に対し、LDPCデコーダ２１１又はBCHデコーダ２１２による誤り訂正が不可能なエラー（LDPC/BCHエラー）が発生したかどうかを判定する。
【０１１１】
ステップＳ５１２において、処理対象のBBパケットで、LDPC/BCHエラーが発生したと判定した場合、処理は、ステップＳ５１１に戻り、次の処理対象のBBパケットが取得される（Ｓ５１１）。
【０１１２】
すなわち、BBデパケタイザ２１４においては、LDPCデコーダ２１１又はBCHデコーダ２１２による誤り訂正が不可能なエラーが発生した場合には、LDPC/BCHエラーが発生したBBパケットのペイロードに配置される、すべてのALPパケットを破棄して、次の処理対象のBBパケットを取得することになる。
【０１１３】
その理由であるが、BBデパケタイザ２１４の前段のLDPCデコーダ２１１又はBCHデコーダ２１２でパリティエラーが発生している場合には、そのFECブロックが破壊されていることになる。しかしながら、エラー訂正情報であると、どこが破壊されているのかが分からず、長さ情報を含むヘッダが壊れている可能性もあり、可変長連鎖が途切れるため、当該FECブロックを破棄することになるからである。
【０１１４】
一方、ステップＳ５１２において、処理対象のBBパケットで、LDPC/BCHエラーが発生していないと判定された場合、処理は、ステップＳ５１３に進められる。ステップＳ５１３において、BBデパケタイザ２１４は、処理対象のBBパケットのペイロードに配置されるALPパケットが、ALPパケットの途中であるかどうかを判定する。
【０１１５】
ステップＳ５１３において、ALPパケットの途中ではないと判定された場合、処理は、ステップＳ５１４に進められる。ステップＳ５１４において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを取得する。また、ステップＳ５１５において、BBデパケタイザ２１４は、ステップＳ５１４の処理で取得されたBBヘッダに含まれる先頭ALPポインタを取得する。
【０１１６】
ステップＳ５１６において、BBデパケタイザ２１４は、ステップＳ５１５の処理で取得された先頭ALPポインタにより特定される位置に基づいて、処理対象のALPパケット（先頭のALPパケット）のALPヘッダを取得する。また、ステップＳ５１７において、BBデパケタイザ２１４は、ステップＳ５１６の処理で取得されたALPヘッダに含まれるALPパケット長（ALPパケットのパケット長）を取得する。
【０１１７】
ステップＳ５１８において、BBデパケタイザ２１４は、処理対象のALPパケットのペイロードを取得する。ステップＳ５１８の処理で、ALPパケットのペイロードが取得されると、処理は、ステップＳ５１９に進められる。
【０１１８】
ステップＳ５１９においては、処理対象のBBパケットが終了したかどうかが判定される。ステップＳ５１９において、処理対象のBBパケットが終了していないと判定された場合、処理は、ステップＳ５２０に進められる。
【０１１９】
ステップＳ５２０においては、処理対象のALPパケットが終了したかどうかが判定される。ステップＳ５２０において、処理対象のALPパケットが終了していないと判定された場合、処理は、ステップＳ５１８に戻り、それ以降の処理が繰り返される。すなわち、処理対象のBBパケットが終了するか（Ｓ５１９の「YES」）、あるいは、処理対象のALPパケットが終了する（Ｓ５２０の「YES」）まで、処理対象のALPパケットのペイロードが取得される（Ｓ５１８）。
【０１２０】
ステップＳ５２０において、処理対象のALPパケットが終了したと判定された場合、処理は、ステップＳ５２１に進められる。ステップＳ５２１においては、UDP/IP処理が行われる。このUDP/IP処理では、例えば、ALPデパケタイザ２１５によって、BBパケット（のペイロード）から抽出されたALPパケットに対する処理や、UDP/IPデパケタイザ２１６によって、ALPパケット（のペイロード）から抽出されたUDP/IPパケットに対する処理が行われる。
【０１２１】
ステップＳ５２１の処理が終了すると、処理は、ステップＳ５１６に進められる。そして、BBデパケタイザ２１４等では、ステップＳ５１７の処理で取得されたALPパケット長（ALPパケットのパケット長）により特定される位置に応じて、次の処理対象のALPパケット（のALPヘッダやペイロード）が取得され、上述した処理対象のALPパケットに対する処理（Ｓ５１６以降の処理）と同様の処理が行われる。
【０１２２】
また、ステップＳ５１９において、処理対象のBBパケットが終了したと判定された場合、処理は、ステップＳ５１１に進められる。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ５１１以降の処理）と同様の処理が行われる。
【０１２３】
なお、ステップＳ５１３において、ALPパケットの途中であると判定された場合、処理は、ステップＳ５２２に進められる。ステップＳ５２２において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを空読みする。ステップＳ５２２の処理が終了すると、処理は、ステップＳ５１８に進められ、それ以降の処理が実行される。
【０１２４】
以上のように、現状のパケット処理では、LDPCデコーダ２１１又はBCHデコーダ２１２からのエラー訂正情報基づいて、LDPC/BCHエラーが発生したと判定された場合（Ｓ５１２の「YES」）、処理対象のBBパケットのペイロードに配置される、すべてのALPパケットを破棄して、次の処理対象のBBパケットを取得する（Ｓ５１１）。すなわち、特定のALPパケットで、LDPCやBCHによる誤り訂正が不可能なエラーが発生してしまうと、当該エラーが発生したALPパケットのみならず、処理対象のBBパケット内のすべてのALPパケットが抽出できなくなってしまう（すべてのALPパケットが破棄されてしまう）。
【０１２５】
このとき、エラーのないALPパケットも破棄されてしまうため、BBパケット内のALPパケットで、誤り訂正が不可能なエラーが発生した場合でも、処理対象のBBパケット内のALPパケットが無駄に破棄されるのを防止するための提案が要請されていた。
【０１２６】
そこで、本技術では、BBパケットのBBヘッダや、ALPパケットのALPヘッダに、誤り検出符号が配置されるようにすることで、BBパケット内のALPパケットで、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合であっても、そのエラーの発生位置を検出して、対象のBBパケット内のALPパケットが無駄に破棄されるのを防止することができるようにする。以下、このような本技術の実施の形態について説明する。
【０１２７】
＜３．本技術の実施の形態＞
【０１２８】
本技術の実施の形態では、パケット内の誤り検出符号の伝送方式として、ALPパケットのALPヘッダに誤り検出符号を配置する第１の方式と、BBパケットのBBヘッダに誤り検出符号を配置する第２の方式について説明する。
【０１２９】
（１）第１の方式：ALPヘッダに誤り検出符号を配置
【０１３０】
（ALPパケットのシンタックス）
図１５は、ALPパケットのシンタックスの例を示す図である。なお、以下で説明するALPヘッダの構造は、上述した図７乃至図１２に示したALPヘッダの構造を拡張したものである。
【０１３１】
図１５において、ALPパケットは、ALPヘッダとペイロードから構成される。また、ALPヘッダは、ALPパケットヘッダ（ALP_packet_header）、追加ヘッダ（additional_header）、及び拡張ヘッダ（header_extension）から構成される。
【０１３２】
ALPパケットヘッダは、packet_type，PC(payload_configuration)，HM（header_mode），及び、lengthを有している。ただし、上述したように、1ビットのpayload_configurationとして、"0"を指定することで、ALPパケットヘッダに、HM（header_mode）とlengthが配置されることになる。
【０１３３】
3ビットのpacket_typeは、ALPパケットのパケットタイプを示す。このパケットタイプには、"000"が固定で指定される。図１６には、パケットタイプの例を示している。例えば、パケットタイプとして、"000"が指定された場合、当該パケットは、IPv4(Internet Protocol version 4 )のパケットとされる。
【０１３４】
図１５の説明に戻り、1ビットのHM（header_mode）は、ヘッダモードを示す。このヘッダモードとしては、"1"が固定で指定される。上述したように、header_modeとして、"1"を指定することで、ALPヘッダに、追加ヘッダ（additional_header）が配置されることになる。11ビットのlengthは、ALPパケットのパケット長（ALPパケット長）を示す。
【０１３５】
追加ヘッダは、length_MSB，SIF(SubStream Identification Flag)，及び、HEF(Header Extension Flag)を有している。
【０１３６】
5ビットのlength_MSBは、MSB(Most Significant Bit)のパケット長を示す。1ビットのSIFは、サブストリームID（sub_stream_identification）が存在するかどうかのフラグを示す。サブストリームIDが存在する場合、SIF="1"とされる。
【０１３７】
1ビットのHEFは、拡張ヘッダ（header_extension）が存在するかどうかのフラグを示す。拡張ヘッダが存在する場合、HEF="1"とされる。本技術では、ALPパケットのALPヘッダに誤り検出符号を配置する場合に、この拡張ヘッダに誤り検出符号が配置されるようにするので、HEF="1"とされ、ヘッダが拡張される。この拡張ヘッダには、図１７に示すように、extension_typeにより指定される拡張データタイプのデータを、extension_lengthで指定される拡張データ長に応じて配置することができる。
【０１３８】
図１５の説明に戻り、図１５の拡張ヘッダ（header_extension）においては、8ビットのnum_extension_typeを拡張して、拡張データタイプの個数を指定できるようにすることで、１又は複数の拡張データタイプ（extension_type[i]）ごとに、拡張データ長（extension_length[i]）に応じたデータ（DATA[i][j]）を配置できるようにしている。
【０１３９】
ここで、図１８には、拡張データタイプの例を示している。図１８においては、拡張データタイプ（extension_type）として、"0x00"が指定された場合、拡張データ長（extension_length）に応じたループ内のデータ（DATA）には、CRC（巡回冗長検査：Cyclic Redundancy Check）が配置されることを表している。
【０１４０】
また、図１８の拡張データタイプを使用する場合、図１５の拡張データ長に応じたループ内のデータ（DATA）として、例えば、図１９のCRC_DATAのデータ構造を配置することができる。図１９において、CRC_DATAには、modeと、CRCが配置される。
【０１４１】
8ビットのmodeは、CRCのモード（以下、CRCモードという）を示す。例えば、"0"であるCRCモードは、CRC-8を表す。また、例えば、"1"であるCRCモードは、CRC-16を表す。CRCには、modeにより指定されるCRCモードに応じたCRCのデータが配置される。
【０１４２】
CRC-8やCRC-16には、多項式の違いにより様々な種類が存在するが、ここでは、例えば、CCITT (Comite Consultatif International Telegraphique et Telephonique：国際電信電話諮問委員会)で規定されたCRC-8-CCITT（X8 + X7 + X3 + X2 + 1）や、CRC-16-CCITT（X16 + X12 + X5 + 1）を用いることができる。
【０１４３】
ただし、CRC-8-CCITT以外の他のCRC-8や、CRC-16-CCITT以外の他のCRC-16は勿論、例えば、CRC-32やCRC-64などの他のCRCが用いられるようにしてもよい。また、CRCは、誤り検出符号の一例であり、他の誤り検出符号が用いられるようにしてもよい。
【０１４４】
なお、図１８の拡張データタイプとして、"0xff"が指定された場合、拡張データ長に応じたループ内のデータ（DATA）には、プライベートユーザデータ（Private User Data）が配置されることを表している。このプライベートユーザデータとしては、例えば、デバイス間で通知したいデータなど、任意のデータを配置することができる。また、図１８において、"0x01"〜"0xfe"である拡張データタイプは、将来の拡張用の領域（Reserved）とされる。
【０１４５】
また、図１８の拡張データタイプでは、CRCのみを指定し、CRC-8やCRC-16などのCRCモードは、図１９のCRC_DATAで指定されるようにしたが、CRCモードに応じたCRCが、拡張データタイプにより指定されるようにしてもよい。
【０１４６】
図２０には、CRCモードに応じたCRCを指定可能な拡張データタイプの例を示している。図２０においては、拡張データタイプ（extension_type）として、"0x00"が指定された場合、図１５の拡張データ長（extension_length）に応じたループ内のデータ（DATA）には、CRC-8のデータが配置されることを表している。また、拡張データタイプとして、"0x01"が指定された場合、図１５の拡張データ長に応じたループ内のデータ（DATA）には、CRC-16のデータが配置されることを表している。
【０１４７】
以上のように、第１の方式を採用した場合、ALPパケットのALPヘッダ（拡張ヘッダ）に誤り検出符号（例えば、CRC-8やCRC-16）が配置されるので、受信装置２０（のBBデパケタイザ２１４）では、このALPヘッダに含まれる誤り検出符号を用いた誤り検出処理を行い、その検出位置（LDPCやBCHによる誤り訂正が不可能なエラーの発生位置）に応じて、BBパケットのペイロードに配置されたALPパケットを処理することができる。
【０１４８】
（２）第２の方式：BBヘッダに誤り検出符号を配置
【０１４９】
（BBヘッダの構造）
図２１は、BBパケットのBBヘッダにCRCを配置する場合のデータ構造の例を示す図である。なお、図２１のBBヘッダの構造は、上述した図５に示したBBヘッダの構造に対応しており、説明が繰り返しになる部分については、その説明を適宜省略するものとする。
【０１５０】
図２１において、BBパケットは、BBヘッダとペイロード（Payload）から構成される。BBヘッダには、ベースフィールド（Base Field）のほか、オプショナルフィールド（Optional Field）と、拡張フィールド（Extension Field）を配置することができる。
【０１５１】
ベースフィールドには、2ビットのオプショナルフラグ（OPTI：OPTIONAL）が配置される。このオプショナルフラグとして、"01"，"10"，又は"11"が設定された場合、オプショナルフィールドと拡張フィールドの拡張が行われる。この拡張が行われた場合には、オプショナルフィールドの先頭に、3ビットの拡張タイプ（EXT_TYPE）が設定される。
【０１５２】
この拡張タイプには、拡張フィールドのタイプが指定される。例えば、拡張タイプとして、"001"が指定された場合、拡張フィールドには、CRC-8のデータが配置されることを表している。また、拡張タイプとして、"010"が指定された場合、拡張フィールドには、CRC-16のデータが配置されることを表している。
【０１５３】
ここでは、上述した第１の方式と同様に、CRC-8とCRC-16としては、例えば、CRC-8-CCITT（X8 + X7 + X3 + X2 + 1）や、CRC-16-CCITT（X16 + X12 + X5 + 1）を用いることができる。ただし、CRC-8-CCITT以外の他のCRC-8や、CRC-16-CCITT以外の他のCRC-16は勿論、例えば、CRC-32やCRC-64などの他のCRCが用いられるようにしてもよい。また、CRCは、誤り検出符号の一例であり、他の誤り検出符号が用いられるようにしてもよい。
【０１５４】
なお、図２１の拡張タイプ（EXT_TYPE）において、"011"〜"110"である拡張タイプは、将来の拡張用の領域とされる。また、拡張タイプとして、"000"が指定された場合には、カウンタが配置されることを意味し、"111"が指定された場合には、パディングされることを意味する。
【０１５５】
以上のように、第２の方式を採用した場合、BBパケットのBBヘッダ（拡張フィールド）に誤り検出符号（例えば、CRC-8やCRC-16）が配置されるので、受信装置２０（のBBデパケタイザ２１４）では、このBBヘッダに含まれる誤り検出符号を用いた誤り検出処理を行うことができる。
【０１５６】
なお、第１の方式と第２の方式は、いずれか一方の方式を採用してもよいし、両方の方式を同時に採用してもよい。両方の方式を同時に採用した場合には、ALPパケットのALPヘッダと、BBパケットのBBヘッダのそれぞれに対し、誤り検出符号が配置されることになる。
【０１５７】
（３）本技術のパケット処理
【０１５８】
（本技術のパケット処理）
次に、上述した第１の方式や第２の方式によって、ALPパケットのALPヘッダやBBパケットのBBヘッダに、誤り検出符号が配置された場合の具体的なパケット処理の内容について説明する。ここでは、パケット内の誤り検出符号の伝送方式として、第１の方式が採用された場合に、受信装置２０（のBBデパケタイザ２１４）で実行される、ALPパケットのALPヘッダに含まれる誤り検出符号（例えばCRC-8やCRC-16）を用いた誤り検出処理について説明する。
【０１５９】
ただし、この誤り検出処理では、エラーの検出位置（LDPCやBCHによる誤り訂正が不可能なエラーの発生位置）に応じて、ALPパケットに対する処理内容が変わるため、以下、エラーの検出位置がALPパケットのペイロードである場合と、エラーの検出位置がALPパケットのALPヘッダである場合についてそれぞれ説明する。
【０１６０】
（Ａ）ケース１：エラー検出位置がペイロードの場合
図２２は、エラーの検出位置がALPパケットのペイロードである場合における、本技術のパケット処理を説明する図である。
【０１６１】
図２２の本技術のパケット処理においては、ALPパケットのALPヘッダに含まれる誤り検出符号（例えばCRC-8やCRC-16）を用いた誤り検出処理によって、処理対象のBBパケットのペイロードに配置される、複数のALPパケットのうち、先頭のALPパケットのペイロードで、LDPCやBCHによる誤り訂正が不可能なエラーが発生したことが検出されている。
【０１６２】
図２２の本技術のパケット処理では、処理対象のBBパケットのBBヘッダの先頭ALPポインタによりその位置が特定される先頭のALPパケットのペイロードでエラーが発生していることを検出（認識）された場合でも、当該ALPパケットのALPヘッダにエラーがないので、ALPヘッダのパケット長（ALPパケットのパケット長）に応じて、エラーが検出された先頭のALPパケット以降のALPパケットを抽出することができる。
【０１６３】
すなわち、ALPヘッダの誤り検出符号を用いた誤り検出処理によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生していることを認識するだけでなく、そのエラーの発生している位置が検出されるため、エラーが発生しているALPパケット（のペイロード）を特定して、処理対象のBBパケットのペイロード内で、ALPパケットの可変長連鎖が途切れないようにすることで、エラーの発生していないALPパケットが破棄されないようにしている。
【０１６４】
換言すれば、BBパケットのペイロードに配置されるALPパケットのペイロードで、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合でも、ALPパケットのALPヘッダ（の誤り検出符号）にエラーが発生していなければ、処理対象のBBパケットのペイロード内で、継続してALPパケットを抽出することができる。
【０１６５】
これにより、図２２の本技術のパケット処理では、上述した現状のパケット処理（図１３）のような、LDPCやBCHによる誤り訂正が不可能なエラーが発生したALPパケットのみならず、BBパケットのペイロードに配置される、すべてのALPパケットを破棄するといった処理が行われないため、ALPパケットが無駄に破棄されるのを防止することができる。
【０１６６】
（Ｂ）ケース２：エラー検出位置がALPヘッダの場合
図２３は、エラーの検出位置がALPパケットのALPヘッダである場合における、本技術のパケット処理を説明する図である。
【０１６７】
図２３の本技術のパケット処理においては、ALPパケットのALPヘッダに含まれる誤り検出符号（例えばCRC-8やCRC-16）を用いた誤り検出処理によって、処理対象のBBパケットのペイロードに配置される、複数のALPパケットのうち、２番目のALPパケットのALPヘッダで、LDPCやBCHによる誤り訂正が不可能なエラーが発生したことが検出されている。
【０１６８】
図２３の本技術のパケット処理では、２番目のALPパケットのALPヘッダでエラーが発生していることが検出（認識）されているため、当該ALPヘッダの情報が正しい情報とは限らないので、２番目のALPパケット以降のALPパケットは破棄するが、１つ前の先頭のALPパケットでは、エラーが発生していないため、先頭のALPパケットは破棄しないようにする。
【０１６９】
すなわち、ALPヘッダの誤り検出符号を用いた誤り検出処理によって、LDPCやBCHによる誤り訂正が不可能なエラーが発生していることを認識するだけでなく、そのエラーの発生している位置が検出されるため、エラーが発生しているALPパケット（のALPヘッダ）を特定して、処理対象のBBパケットのペイロード内で、可能な限り、エラーの発生していないALPパケットが破棄されないようにしている。
【０１７０】
換言すれば、BBパケットのペイロードに配置されるALPパケットのALPヘッダで、LDPCやBCHによる誤り訂正が不可能なエラーが発生した場合でも、処理対象のBBパケットのペイロード内で、当該ALPヘッダを含むALPパケットの直前のALPパケットまでは、継続してALPパケットを抽出することができる。
【０１７１】
これにより、図２３の本技術のパケット処理では、処理対象のBBパケットのペイロードに配置される、すべてのALPパケットを破棄しないようにすることはできないが（救うことはできないが）、エラーが発生したALPヘッダを含むALPパケットの直前のALPパケットまでの一部のALPパケットを破棄しないようにすることができる（ある程度のALPパケットを救うことができる）。
【０１７２】
つまり、図２３の本技術のパケット処理では、一部のALPパケットは破棄されるものの、上述した現状のパケット処理（図１３）のような、エラーが発生したALPパケットのみならず、BBパケットのペイロードに配置される、すべてのALPパケットを破棄するといった処理が行われないため、ALPパケットが無駄に破棄されるのを防止することができる。
【０１７３】
次に、図２４乃至図２６のフローチャートを参照して、図１の伝送システム１を構成する送信装置１０と受信装置２０で実行される処理の詳細な内容について説明する。
【０１７４】
（送信側データ処理）
まず、図２４のフローチャートを参照して、送信装置１０（図１）により実行される送信側データ処理の流れを説明する。
【０１７５】
ステップＳ１０１においては、放送番組等のコンテンツのデータに対するパケット処理が行われる。このパケット処理では、UDP/IPパケタイザ１０３、ALPパケタイザ１０４、及びBBパケタイザ１０５によって、UDP/IPパケット、ALPパケット、及びBBパケットを生成する処理が行われる。
【０１７６】
ただし、パケット内の誤り検出符号の伝送方式として、第１の方式を採用する場合、ステップＳ１０１の処理で生成されるALPパケットのALPヘッダには、例えば、CRC-8やCRC-16等の誤り検出符号が配置される。ここでは、例えば、図１５に示したように、ALPヘッダの拡張ヘッダ（header_extension）に、拡張データタイプ（extension_type）に応じた誤り検出符号（DATA）が配置される。
【０１７７】
また、パケット内の誤り検出符号の伝送方式として、第２の方式を採用する場合、ステップＳ１０１の処理で生成されるBBパケットのBBヘッダには、例えば、CRC-8やCRC-16等の誤り検出符号が配置される。ここでは、例えば、図２１に示したように、BBヘッダの拡張フィールド（Extension Field）に、拡張タイプ（EXT_TYPE）に応じた誤り検出符号（例えばCRC-8やCRC-16）が配置される。
【０１７８】
ステップＳ１０２においては、ステップＳ１０１の処理で得られるデータに対する誤り訂正符号化処理が行われる。この誤り訂正符号化処理では、BCHエンコーダ１０７によるBCH符号化や、LDPCエンコーダ１０８によるLDPC符号化などの処理が行われる。
【０１７９】
ステップＳ１０３においては、ステップＳ１０２の処理で誤り訂正符号化処理が施されたデータに対する変調処理が行われる。この変調処理では、各種のインターリーバによるインターリーブ処理や、データマッパ１１１やOFDM送信部１１７による処理などが行われる。そして、この変調処理で得られるRF信号（OFDM信号）が、伝送路３０を介して送信される。
【０１８０】
以上、送信側データ処理の流れについて説明した。
【０１８１】
（受信側データ処理）
次に、図２５のフローチャートを参照して、受信装置２０（図１）により実行される受信側データ処理の流れを説明する。
【０１８２】
ステップＳ２０１においては、送信装置１０から伝送路３０を介して送信されてくるRF信号（OFDM信号）に対する復調処理が行われる。この復調処理では、OFDM受信部２０２やデータデマッパ２０８による処理や、各種のデインターリーバによるデインターリーブ処理などが行われる。
【０１８３】
ステップＳ２０２においては、ステップＳ２０１の処理で復調されたデータに対する誤り訂正復号化処理が行われる。この誤り訂正復号化処理では、LDPCデコーダ２１１によるLDPC復号化や、BCHデコーダ２１２によるBCH復号化などの処理が行われる。
【０１８４】
ステップＳ２０３においては、ステップＳ２０２の処理で誤り訂正復号化処理が施されたデータに対するパケット処理が行われる。このパケット処理では、BBデパケタイザ２１４、ALPデパケタイザ２１５、及びUDP/IPデパケタイザ２１６によって、BBパケット、ALPパケット、及びUDP/IPパケットに対するパケット処理が行われる。
【０１８５】
ただし、パケット内の誤り検出符号の伝送方式として、第１の方式を採用する場合、ステップＳ２０３の処理で処理されるALPパケットのALPヘッダ（の拡張ヘッダ（header_extension））には、拡張データタイプ（extension_type）に応じた誤り検出符号（例えばCRC-8やCRC-16）が配置されているので、このALPヘッダの誤り検出符号を用いた誤り検出処理が行われる。
【０１８６】
また、パケット内の誤り検出符号の伝送方式として、第２の方式を採用する場合、ステップＳ２０３の処理で処理されるBBパケットのBBヘッダ（の拡張フィールド（Extension Field））には、拡張タイプ（EXT_TYPE）に応じた誤り検出符号（例えばCRC-8やCRC-16）が配置されているので、このBBヘッダの誤り検出符号を用いた誤り検出処理が行われる。
【０１８７】
なお、このパケット処理の詳細な処理内容については、図２６のフローチャートを参照して後述する。また、パケット処理後のデータが、AVデコーダ２１８等によりデコードされることで、受信装置２０では、放送番組等のコンテンツが再生される。
【０１８８】
以上、受信側データ処理の流れについて説明した。
【０１８９】
（本技術のパケット処理）
最後に、図２６のフローチャートを参照して、図２５のステップＳ２０３の処理に対応する本技術のパケット処理の流れを説明する。なお、この本技術のパケット処理は、受信装置２０（図１）のBBデパケタイザ２１４乃至UDP/IPデパケタイザ２１６（図３）などにより実行される。
【０１９０】
ステップＳ２１１において、BBデパケタイザ２１４は、次の処理対象のBBパケットを取得する。ステップＳ２１２において、BBデパケタイザ２１４は、ステップＳ２１１の処理で取得された処理対象のBBパケットのペイロードに配置されるALPパケットが、ALPパケットの途中であるかどうかを判定する。
【０１９１】
ステップＳ２１２において、ALPパケットの途中ではないと判定された場合、処理は、ステップＳ２１３に進められる。ステップＳ２１３において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを取得する。
【０１９２】
ステップＳ２１３Ａにおいて、BBデパケタイザ２１４は、ステップＳ２１３の処理で取得されたBBヘッダ（の拡張フィールド）に含まれるCRC値（BB CRC値）を取得する。また、ステップＳ２１３Ｂにおいて、BBデパケタイザ２１４は、ステップＳ２１３Ａの処理で取得されたCRC値（BB CRC値）に基づいて、CRC値（BB CRC値）を計算する。
【０１９３】
ステップＳ２１３Ｃにおいて、BBデパケタイザ２１４は、ステップＳ２１３Ｂの計算結果に従い、CRC値（BB CRC値）の比較エラーが発生したかどうかを判定する。なお、このBB CRC値を用いた比較エラーの判定処理（Ｓ２１３Ｃ）は、後述するALP CRC値を用いた比較エラー判定処理（Ｓ２１８）と同様に処理されるので、ここでは、その詳細な内容の説明は省略する。
【０１９４】
ステップＳ２１３Ｃにおいて、CRC値（BB CRC値）の比較エラーが発生したと判定された場合、処理は、ステップＳ２１１に戻される。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ２１１以降の処理）と同様の処理が行われる。
【０１９５】
一方、ステップＳ２１３Ｃにおいて、CRC値（BB CRC値）の比較エラーが発生していないと判定された場合、処理は、ステップＳ２１４に進められる。ステップＳ２１４において、BBデパケタイザ２１４は、ステップＳ２１３の処理で取得されたBBヘッダに含まれる先頭ALPポインタを取得する。
【０１９６】
ステップＳ２１５において、BBデパケタイザ２１４は、ステップＳ２１４の処理で取得された先頭ALPポインタにより特定される位置に基づいて、処理対象のALPパケット（先頭のALPパケット）のALPヘッダを取得する。
【０１９７】
ステップＳ２１６において、BBデパケタイザ２１４は、ステップＳ２１５の処理で取得されたALPヘッダ（の拡張ヘッダ）に含まれるCRC値（ALP CRC値）を取得する。また、ステップＳ２１７において、BBデパケタイザ２１４は、ステップＳ２１６の処理で取得されたCRC値（ALP CRC値）に基づいて、CRC値（ALP CRC値）を計算する。
【０１９８】
ステップＳ２１８において、BBデパケタイザ２１４は、ステップＳ２１７の計算結果に従い、CRC値（ALP CRC値）の比較エラーが発生したかどうかを判定する。
【０１９９】
ここでは、例えば、CRC-8やCRC-16が用いられる場合に、送信装置１０から伝送路３０を介して、入力されたデータ列に対して所定の計算が行われ、その余りがチェック用の値として追加されたデータが送信されてくるので、受信装置２０（のBBデパケタイザ２１４）では、送信装置１０からのデータを用いて同じ計算（所定の計算）を行い、その計算結果を、チェック用の値と比較することで、データの破損の有無が判定されることになる。
【０２００】
ステップＳ２１８において、CRC値（ALP CRC値）の比較エラーが発生したと判定された場合、処理は、ステップＳ２１１に戻される。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ２１１以降の処理）と同様の処理が行われる。
【０２０１】
すなわち、この場合、ALPパケットのALPヘッダでエラーが検出されたことになるので（図２３のケース２のエラー検出位置がALPヘッダの場合に相当）、当該ALPヘッダを含むALPパケット以降のALPパケットは破棄するが、当該ALPヘッダを含むALPパケットよりも前のALPパケットでは、エラーが発生していないため、それらのALPパケットが破棄されないようにしている。
【０２０２】
一方、ステップＳ２１８において、CRC値（ALP CRC値）の比較エラーが発生していないと判定された場合、処理は、ステップＳ２１９に進められる。ステップＳ２１９において、BBデパケタイザ２１４は、ステップＳ２１５の処理で取得されたALPヘッダに含まれるALPパケット長（ALPパケットのパケット長）を取得する。なお、ここで取得されるALPパケット長は、CRCのエラー検出処理よってエラーが検出されなかったALPヘッダから取得されたデータであるため、信頼できる情報であると言える。
【０２０３】
ステップＳ２２０において、BBデパケタイザ２１４は、処理対象のALPパケットのペイロードを取得する。ステップＳ２２０の処理で、ALPパケットのペイロードが取得されると、処理は、ステップＳ２１１に進められる。
【０２０４】
ステップＳ２２１においては、処理対象のBBパケットが終了したかどうかが判定される。ステップＳ２１１において、処理対象のBBパケットが終了していないと判定された場合、処理は、ステップＳ２２２に進められる。
【０２０５】
ステップＳ２２２においては、処理対象のALPパケットが終了したかどうかが判定される。ステップＳ２２２において、処理対象のALPパケットが終了していないと判定された場合、処理は、ステップＳ２２０に戻り、それ以降の処理が繰り返される。すなわち、処理対象のBBパケットが終了するか（Ｓ２２１の「YES」）、あるいは、処理対象のALPパケットが終了する（Ｓ２２２の「YES」）まで、処理対象のALPパケットのペイロードが取得される（Ｓ２２０）。
【０２０６】
ステップＳ２２２において、処理対象のALPパケットが終了したと判定された場合、処理は、ステップＳ２２３に進められる。ステップＳ２２３においては、UDP/IP処理が行われる。このUDP/IP処理では、例えば、ALPデパケタイザ２１５によって、BBパケット（のペイロード）から抽出されたALPパケットに対する処理や、UDP/IPデパケタイザ２１６によって、ALPパケット（のペイロード）から抽出されたUDP/IPパケットに対する処理が行われる。
【０２０７】
ステップＳ２２３の処理が終了すると、処理は、ステップＳ２１５に進められる。そして、BBデパケタイザ２１４等では、ステップＳ２１９の処理で取得されたALPパケット長（ALPパケットのパケット長）により特定される位置に応じて、次の処理対象のALPパケット（のALPヘッダやペイロード）が取得され、上述した処理対象のALPパケットに対する処理（Ｓ２１５以降の処理）と同様の処理が行われる。
【０２０８】
また、ステップＳ２２１において、処理対象のBBパケットが終了したと判定された場合、処理は、ステップＳ２１１に進められる。そして、次の処理対象のBBパケットが取得され、上述した処理対象のBBパケットに対する処理（Ｓ２１１以降の処理）と同様の処理が行われる。
【０２０９】
なお、ステップＳ２１２において、処理対象のALPパケットの途中であると判定された場合、処理は、ステップＳ２２４に進められる。ステップＳ２２４において、BBデパケタイザ２１４は、処理対象のBBパケットのBBヘッダを空読みする。ステップＳ２２４の処理が終了すると、処理は、ステップＳ２２０に進められ、それ以降の処理が実行される。
【０２１０】
以上、本技術のパケット処理の流れについて説明した。この本技術のパケット処理では、ALPパケットのALPヘッダでエラーが検出された場合に、一部のALPパケットは破棄されるものの、エラーの発生していないALPパケットは破棄されないため、ALPパケットが無駄に破棄されるのを防止することができる。
【０２１１】
＜４．変形例＞
【０２１２】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IPパケットを用いたIP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０２１３】
また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS)や通信衛星（CS）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
【０２１４】
また、上述したパケットやヘッダなどの名称は、一例であって、他の名称が用いられる場合がある。例えば、BBパケット(Baseband Packet)は、BBS(Baseband Stream)やBBF(Baseband Frame)などと称される場合がある。また、ALP(ATSC Link layer Protocol)パケットは、Genericパケットなどと称される場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のパケットやヘッダなどの実質的な内容が異なるものではない。
【０２１５】
さらに、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。その場合には、伝送システム１（図１）の伝送路３０として、インターネットや電話網などの通信回線が利用され、送信装置１０は、インターネット上に設けられたサーバとすることができる。そして、受信装置２０が通信機能を有するようにすることで、送信装置１０（サーバ）は、受信装置２０からの要求に応じて、処理を行うことになる。一方で、受信装置２０は、送信装置１０（サーバ）から伝送路３０（通信回線）を介して送信されてくるデータを処理する。
【０２１６】
＜５．コンピュータの構成＞
【０２１７】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２７は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０２１８】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０２１９】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１０１１を駆動する。
【０２２０】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０２２１】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０２２２】
コンピュータ１０００では、プログラムは、リムーバブルメディア１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。そのほか、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０２２３】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０２２４】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０２２５】
また、本技術は、以下のような構成をとることができる。
【０２２６】
（１）
復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットを配置したペイロードとから構成される前記伝送パケットを処理する処理部を備え、
前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
受信装置。
（２）
前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いた誤り検出処理によりエラーが検出された場合、前記エラーの検出位置に応じた処理を行う
（１）に記載の受信装置。
（３）
前記処理部は、前記エラーの検出位置が、前記伝送パケットのペイロードである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを抽出してそのまま処理する
（２）に記載の受信装置。
（４）
前記伝送パケットは、前記エラーの検出位置が、前記伝送パケットのヘッダである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを破棄する
（２）に記載の受信装置。
（５）
前記誤り検出符号は、巡回冗長検査（CRC：Cyclic Redundancy Check）である
（１）乃至（４）のいずれかに記載の受信装置。
（６）
前記伝送パケットは、可変長のパケットであり、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
（１）乃至（５）のいずれかに記載の受信装置。
（７）
受信装置のデータ処理方法において、
前記受信装置が、
復調後のベースバンドパケットのペイロートに複数配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
ステップを含むデータ処理方法。
（８）
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成する処理部を備え、
前記処理部は、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
送信装置。
（９）
送信装置のデータ処理方法において、
前記送信装置が、
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードとから構成される前記伝送パケットを生成し、
前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
ステップを含むデータ処理方法。
（１０）
復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットを処理する処理部を備え、
前記処理部は、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
受信装置。
（１１）
前記誤り検出符号は、巡回冗長検査（CRC）である
（１０）に記載の受信装置。
（１２）
前記伝送パケットは、可変長のパケットであり、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
前記ベースバンドパケットのペイロードに配置される複数の前記伝送パケットの配置位置は、前記ポインタと前記データ長により特定される
（１０）又は（１１）に記載の受信装置。
（１３）
受信装置のデータ処理方法において、
前記受信装置が、
復調後のベースバンドパケットであって、誤り検出符号を含むヘッダと、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される伝送パケットを複数配置したペイロードとから構成される前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
ステップを含むデータ処理方法。
（１４）
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成する処理部を備え、
前記処理部は、前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
送信装置。
（１５）
送信装置のデータ処理方法において、
前記送信装置が、
変調前のベースバンドパケットのペイロードに配置される伝送パケットであって、UDPパケットを含むIPパケットを配置したペイロードを含んで構成される前記伝送パケットを生成し、
前記ベースバンドパケットのヘッダに、誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、複数の前記伝送パケットを配置する
ステップを含むデータ処理方法。
【符号の説明】
【０２２７】
１  伝送システム，  １０  送信装置，  ２０  受信装置，  ３０  伝送路，  １０１  AVエンコーダ，  １０２  FLUTEエンコーダ，  １０３  UDP/IPパケタイザ，  １０４  ALPパケタイザ，  １０５  BBパケタイザ，  １０６  スクランブラ，  １０７  BCHエンコーダ，  １０８  LDPCエンコーダ，  １０９  パリティインターリーバ，  １１０  カラムツイストインターリーバ，  １１１  データマッパ，  １１２  CQディレイ部，  １１３  セルインターリーバ，  １１４  時間インターリーバ，  １１５  フレームマッパ，  １１６  周波数インターリーバ，  １１７  OFDM送信部，  １１８  RF出力部，  ２０１  RF入力部，  ２０２  OFDM受信部，  ２０３  周波数デインターリーバ，  ２０４  フレームデマッパ，  ２０５  時間デインターリーバ，  ２０６  セルデインターリーバ，  ２０７  CQディレイ部，  ２０８  データデマッパ，  ２０９  カラムツイストデインターリーバ，  ２１０  パリティデインターリーバ，  ２１１  LDPCデコーダ，  ２１２  BCHデコーダ，  ２１３  デスクランブラ，  ２１４  BBデパケタイザ，  ２１５  ALPデパケタイザ，  ２１６  UDP/IPデパケタイザ，  ２１７  FLUTEデコーダ，  ２１８  AVデコーダ，  １０００  コンピュータ，  １００１  CPU
【図１】
2017145790.tif 000003
【図２】
2017145790.tif 000004
【図３】
2017145790.tif 000005
【図４】
2017145790.tif 000006
【図５】
2017145790.tif 000007
【図６】
2017145790.tif 000008
【図７】
2017145790.tif 000009
【図８】
2017145790.tif 000010
【図９】
2017145790.tif 000011
【図１０】
2017145790.tif 000012
【図１１】
2017145790.tif 000013
【図１２】
2017145790.tif 000014
【図１３】
2017145790.tif 000015
【図１４】
2017145790.tif 000016
【図１５】
2017145790.tif 000017
【図１６】
2017145790.tif 000018
【図１７】
2017145790.tif 000019
【図１８】
2017145790.tif 000020
【図１９】
2017145790.tif 000021
【図２０】
2017145790.tif 000022
【図２１】
2017145790.tif 000023
【図２２】
2017145790.tif 000024
【図２３】
2017145790.tif 000025
【図２４】
2017145790.tif 000026
【図２５】
2017145790.tif 000027
【図２６】
2017145790.tif 000028
【図２７】
2017145790.tif 000029
【手続補正書】
【提出日】平成29年6月27日(2017.6.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ベースバンドパケットのペイロートに配置される可変長の伝送パケットであって、誤り検出符号及びデータ長を含むヘッダと、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）パケットを含むＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットを配置したペイロードとから構成される前記伝送パケットを処理する処理部を備え、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定され、
前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、前記ポインタ、又は前記ポインタ及び前記データ長により配置位置が特定される前記伝送パケットのうち、抽出すべき前記伝送パケットを特定するための誤り検出処理を行う
受信装置。
【請求項２】
前記処理部は、前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いた誤り検出処理によりエラーが検出された場合、前記エラーの検出位置に応じた処理を行う
請求項１に記載の受信装置。
【請求項３】
前記処理部は、前記エラーの検出位置が、前記伝送パケットのペイロードである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを抽出してそのまま処理する
請求項２に記載の受信装置。
【請求項４】
前記伝送パケットは、前記エラーの検出位置が、前記伝送パケットのヘッダである場合、前記ベースバンドパケットのペイロードにおいて、前記エラーの検出位置以降に配置される前記伝送パケットを破棄する
請求項２に記載の受信装置。
【請求項５】
前記誤り検出符号は、巡回冗長検査（ＣＲＣ：Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）である
請求項１に記載の受信装置。
【請求項６】
前記伝送パケットは、ＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍｓ  Ｃｏｍｍｉｔｔｅｅ）３．０で規定されるＡＬＰ（ＡＴＳＣ  Ｌｉｎｋ−Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）パケットである
請求項１に記載の受信装置。
【請求項７】
受信装置のデータ処理方法において、
前記受信装置が、
ベースバンドパケットのペイロートに配置される可変長の伝送パケットであって、誤り検出符号及びデータ長を含むヘッダと、ＵＤＰパケットを含むＩＰパケットを配置したペイロードとから構成される前記伝送パケットを処理する
ステップを含み、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定され、
前記伝送パケットのヘッダに含まれる前記誤り検出符号を用いて、前記ポインタ、又は前記ポインタ及び前記データ長により配置位置が特定される前記伝送パケットのうち、抽出すべき前記伝送パケットを特定するための誤り検出処理を行う
ステップをさらに含むデータ処理方法。
【請求項８】
ベースバンドパケットのペイロードに配置される可変長の伝送パケットであって、誤り検出符号及びデータ長を含むヘッダと、ＵＤＰパケットを含むＩＰパケットを配置したペイロードとから構成される前記伝送パケットを生成する処理部を備え、
前記処理部は、前記ベースバンドパケットのヘッダに、前記伝送パケットの先頭の位置を示すポインタを含めるとともに、前記ベースバンドパケットのペイロードに、前記伝送パケットを配置し、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定される
送信装置。
【請求項９】
送信装置のデータ処理方法において、
前記送信装置が、
ベースバンドパケットのペイロードに配置される可変長の伝送パケットであって、誤り検出符号及びデータ長を含むヘッダと、ＵＤＰパケットを含むＩＰパケットを配置したペイロードとから構成される前記伝送パケットを生成し、
前記ベースバンドパケットのヘッダに、前記伝送パケットの先頭の位置を示すポインタを含めるとともに、前記ベースバンドパケットのペイロードに、前記伝送パケットを配置する
ステップを含み、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定される
データ処理方法。
【請求項１０】
ベースバンドパケットであって、誤り検出符号を含むヘッダと、ＵＤＰパケットを含むＩＰパケットを配置したペイロードを含んで構成される可変長の伝送パケットを配置したペイロードとから構成される前記ベースバンドパケットを処理する処理部を備え、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定され、
前記処理部は、前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
受信装置。
【請求項１１】
前記誤り検出符号は、巡回冗長検査（ＣＲＣ）である
請求項１０に記載の受信装置。
【請求項１２】
前記伝送パケットは、ＡＴＳＣ３．０で規定されるＡＬＰパケットである
請求項１０に記載の受信装置。
【請求項１３】
受信装置のデータ処理方法において、
前記受信装置が、
ベースバンドパケットであって、誤り検出符号を含むヘッダと、ＵＤＰパケットを含むＩＰパケットを配置したペイロードを含んで構成される可変長の伝送パケットを配置したペイロードとから構成される前記ベースバンドパケットを処理する
ステップを含み、
前記ベースバンドパケットのヘッダは、前記伝送パケットの先頭の位置を示すポインタを含み、
前記伝送パケットのヘッダは、前記伝送パケットのデータ長を含み、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定され、
前記ベースバンドパケットのヘッダに含まれる前記誤り検出符号を用いて、誤り検出処理を行う
ステップを含むデータ処理方法。
【請求項１４】
ベースバンドパケットのペイロードに配置される可変長の伝送パケットであって、データ長を含むヘッダと、ＵＤＰパケットを含むＩＰパケットを配置したペイロードを含んで構成される前記伝送パケットを生成する処理部を備え、
前記処理部は、前記ベースバンドパケットのヘッダに、前記伝送パケットの先頭の位置を示すポインタ、及び誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、前記伝送パケットを配置し、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定される
送信装置。
【請求項１５】
送信装置のデータ処理方法において、
前記送信装置が、
ベースバンドパケットのペイロードに配置される可変長の伝送パケットであって、データ長を含むヘッダと、ＵＤＰパケットを含むＩＰパケットを配置したペイロードを含んで構成される前記伝送パケットを生成し、
前記ベースバンドパケットのヘッダに、前記伝送パケットの先頭の位置を示すポインタ、及び誤り検出符号を配置し、前記ベースバンドパケットのペイロードに、前記伝送パケットを配置する
ステップを含み、
前記ベースバンドパケットのペイロードに配置される前記伝送パケットの配置位置は、前記ポインタ、又は前記ポインタ及び前記データ長により特定される
データ処理方法。
【国際調査報告】
2017145790.tif 000030
2017145790.tif 000031
2017145790.tif 000032
2017145790.tif 000033