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

Abstract

【課題】選局時間を短縮する。【解決手段】送信方法は、放送を通じてコンテンツを送信する送信方法であって、コンテンツが格納された第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットと、コンテンツの再生のための時刻を示す基準クロック情報を含む第２ＩＰパケットとが格納された伝送用のフレームを生成する生成ステップ（Ｓ４２１）と、生成されたフレームを送信する送信ステップ（Ｓ４２２）とを含み、生成ステップ（Ｓ４２１）では、第１ＩＰパケットに対してはヘッダ圧縮を行い、第２ＩＰパケットに対してはヘッダ圧縮を行わない。【選択図】図５５

Description

本発明は、送信方法、受信方法、送信装置及び受信装置に関する。

ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）方式（非特許文献１参照）は、映像及び音声などのコンテンツを多重化及びパケット化し、放送または通信などの一つ以上の伝送路で送信するための多重化方式である。ＭＭＴ方式を放送システムに適用する場合、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置におけるシステムクロックを生成する。

Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ − Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔ − Ｐａｒｔ１：ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ ＤＩＳ ２３００８−１ ＡＲＩＢ標準規格 ＡＲＩＢ ＳＴＤ−Ｂ４４ （２．０版）、「高度広帯域衛星デジタル放送の伝送方式」、第３章「時刻情報の伝送に関するガイドライン」

このような受信装置では、選局時間を短縮できることが望まれている。

本発明は、選局時間を短縮できる送信方法、受信方法、送信装置又は受信装置を提供することを目的とする。

本発明の一態様に係る送信方法は、放送を通じてコンテンツを送信する送信方法であって、前記コンテンツが格納された第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットを含む１つの第１ＩＰデータフローと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む第２ＩＰパケットを含む１つの第２ＩＰデータフローとが格納されたＴＬＶストリームを含む伝送用のフレームを生成する生成ステップと、生成された前記フレームを送信する送信ステップとを含み、前記生成ステップでは、前記第１ＩＰパケットに対してはヘッダ圧縮を行い、前記第２ＩＰパケットに対してはヘッダ圧縮を行わず、前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）パケットに格納される。

また、本発明の一態様に係る受信方法は、放送を通じてコンテンツを受信する受信方法であって、前記コンテンツが格納された、ヘッダ圧縮されている第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットを含む１つの第１ＩＰデータフローと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む、ヘッダ圧縮されていない第２ＩＰパケットを含む１つの第２ＩＰデータフローとが格納されたＴＬＶストリームを含む伝送用のフレームを受信する受信ステップと、ＩＰパケットがヘッダ圧縮されているか否かに応じて、当該ＩＰパケットが前記第１ＩＰパケットであるか前記第２ＩＰパケットであるかを判定する判定ステップと、前記判定の結果に応じて、前記第２ＩＰパケットに格納された前記基準クロック情報を用いて、前記第１ＩＰパケットに格納された前記コンテンツを再生する再生ステップとを含み、前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）パケットに格納される。

なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよい。また、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。

本発明は、選局時間を短縮できる送信方法、受信方法、送信装置又は受信装置を提供できる。

図１は、ＭＭＴ方式及び高度ＢＳ伝送方式を用いて伝送を行う場合のプロトコルスタックを示す図である。 図２は、ＴＬＶパケットのデータ構造を示す図である。 図３は、受信装置の基本構成を示すブロック図である。 図４は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置の機能構成を示すブロック図である。 図５は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図６は、制御情報に基準クロック情報が格納される場合の受信装置の機能構成を示すブロック図である。 図７は、制御情報に基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図８は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置の構成を示すブロック図である。 図９は、ロングフォーマットＮＴＰがＴＬＶパケットに格納される例を示す図である。 図１０は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図１１は、ＩＰパケットのヘッダの直前に基準クロック情報が付加される構成を示す図である。 図１２は、ＴＬＶパケットの直前に基準クロック情報が付加される構成を示す図である。 図１３は、伝送スロットの構成を示す図である。 図１４は、伝送スロットのスロットヘッダの構成を示す図である。 図１５は、スロットヘッダの未定義領域にフラグが格納される例を示す図である。 図１６は、高度広帯域衛星デジタル放送の伝送方式におけるＴＭＣＣ制御情報の構成を示す図である。 図１７は、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報を示す図である。 図１８は、スロットヘッダの未定義フィールドに基準クロック情報が格納される例を示す図である。 図１９は、ＴＭＣＣ制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置の機能構成を示すブロック図である。 図２０は、スロットヘッダに基準クロック情報を含むことを示す情報がＴＭＣＣ制御情報に格納される場合の基準クロック情報の取得フローを示す図である。 図２１は、ＩＰパケットまたは圧縮ＩＰパケットから特定位置のビット列を抽出する場合のフローを示す図である。 図２２は、ＴＭＣＣ拡張情報の構成を示す図である。 図２３は、このように分類された拡張種別が用いられた拡張領域のデータ構造の一例を示す図である。 図２４は、拡張種別を使用する場合のシンタックスを示す図である。 図２５は、実施の形態２に係る受信装置の機能構成を示すブロック図である。 図２６は、実施の形態２に係る受信装置の動作フローを示す図である。 図２７は、複数レイヤのそれぞれに基準クロック情報が格納される例を模式的に示す図である。 図２８は、一つのレイヤに複数の基準クロック情報が格納される例を模式的に示す図である。 図２９は、異なる放送局のデータがストリームに分けて格納される例を説明するためのブロック図である。 図３０は、差分情報の送信方法を説明するための図である。 図３１は、差分情報の送信方法の変形例を説明するための図である。 図３２は、実施の形態３に係る受信装置の機能構成を示すブロック図である。 図３３は、実施の形態３に係る受信装置の動作フローを示す図である。 図３４は、実施の形態３に係る受信装置の別の動作フローを示す図である。 図３５は、送信装置の機能構成を示すブロック図である。 図３６は、送信装置の動作フローを示す図である。 図３７は、実施の形態４に係る受信装置のブロック図である。 図３８は、実施の形態４に係る主信号及び基準クロック情報のタイミングを示す図である。 図３９は、実施の形態４に係る復号部における動作フローを示す図である。 図４０は、実施の形態４に係る受信装置における動作フローを示す図である。 図４１は、実施の形態４に係る上位レイヤにおける動作フローを示す図である。 図４２は、実施の形態４に係る復号装置の動作フローを示す図である。 図４３は、実施の形態４に係る逆多重化装置の動作フローを示す図である。 図４４は、実施の形態５に係る伝送フレームの構成を示す図である。 図４５は、実施の形態５に係る伝送フレームの構成を示す図である。 図４６は、実施の形態５に係る伝送フレームの構成を示す図である。 図４７は、実施の形態５に係る送信方法を説明するための図である。 図４８は、実施の形態５に係る送信装置の動作フローを示す図である。 図４９は、実施の形態５に係る伝送フレームの構成を示す図である。 図５０は、実施の形態６に係るヘッダ圧縮を説明するための図である。 図５１は、実施の形態６に係るヘッダ圧縮を説明するための図である。 図５２は、実施の形態６に係る受信装置の動作フローを示す図である。 図５３は、実施の形態６に係る受信装置の動作フローを示す図である。 図５４は、実施の形態６に係る送信装置のブロック図である。 図５５は、実施の形態６に係る送信装置の動作フローを示す図である。 図５６は、実施の形態６に係る受信装置のブロック図である。 図５７は、実施の形態６に係る受信装置の動作フローを示す図である。

（本発明の基礎となった知見）
本発明は、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）で規格化中のＭＭＴ方式を用いるハイブリッド配信システムにおいて、送信側から基準クロック情報を送信し、受信側で基準クロック情報を受信し、基準クロックを生成（再生）する方法及び装置に関する。

ＭＭＴ方式は、映像及び音声を多重化及びパケット化し、放送または通信などの一つ以上の伝送路で送信するための多重化方式である。

ＭＭＴ方式を放送システムに適用する場合、送信側の基準クロックをＩＥＴＦ ＲＦＣ
５９０５ に規定されるＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に同期させ、基準クロックを基に、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）や、ＤＴＳ（Ｄｅｃｏｄｅ Ｔｉｍｅ Ｓｔａｍｐ）などのタイムスタンプをメディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置における基準クロック（以下、システムクロックとも記載する）を生成する。

放送システムでは、基準クロック情報として絶対時刻を示すことの可能な６４ビットのロングフォーマットＮＴＰが使用されることが望ましい。しかし、従来のＭＭＴ方式では、ＭＭＴパケットヘッダに３２ビットのショートフォーマットＮＴＰを格納して伝送することは規定されているが、ロングフォーマットＮＴＰを伝送することは規定されておらず、受信機側で精度のよい基準クロック情報を取得することができない。

これに対し、メッセージ、テーブル、または記述子などの制御情報としてロングフォーマットＮＴＰを定義し、制御情報にＭＭＴパケットヘッダを付加して伝送することが可能である。この場合、ＭＭＴパケットは、ＩＰパケットに格納されるなどして放送伝送路または通信伝送路を通じて伝送される。

ＭＭＴパケットをＡＲＩＢ規格で規定される高度ＢＳ伝送方式を用いて伝送する場合、ＭＭＴパケットをＩＰパケットへカプセル化し、ＩＰパケットをＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）パケットへカプセル化した後、高度ＢＳ伝送方式で規定される伝送スロットへと格納する。

受信装置は、ＴＬＶストリームから所望のＩＰデータフローを抽出する際には、ＩＰデータフローのフィルタリング、又はＩＰパケット或いはＵＤＰパケットのフィルタリングを実施する。また、受信装置は、ＩＰデータフローをフィルタリングする際には、所望のサービスのＩＰデータフローを特定し、所望のＩＰデータフローに属するパケットを識別する必要がある。

しかしながら、受信装置は、フルヘッダの受信後でなければ、所望のＩＰデータフローに属するパケットを識別できない。これにより、受信装置がフルヘッダを始めに受信するまで、処理が遅延し、選局時間が長くなるという課題がある。さらに、フルヘッダの送信間隔が長い場合、さらにこの選局時間が長くなる。

本発明の一態様に係る送信方法は、放送を通じてコンテンツを送信する送信方法であって、前記コンテンツが格納された第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む第２ＩＰパケットとが格納された伝送用のフレームを生成する生成ステップと、生成された前記フレームを送信する送信ステップとを含み、前記生成ステップでは、前記第１ＩＰパケットに対してはヘッダ圧縮を行い、前記第２ＩＰパケットに対してはヘッダ圧縮を行わない。

これにより、受信装置は、ヘッダ圧縮がされているか否かに応じて、ＩＰデータフローをフィルタリングできる。よって、選局時間を短縮できる。

例えば、前記生成ステップでは、前記ヘッダ圧縮として、（１）複数の前記第１ＩＰパケットのうち一部の第１ＩＰパケットに、前記複数の第１ＩＰパケットが属するＩＰデータフローを特定する特定情報を含むフルヘッダを付与し、（２）前記複数の第１ＩＰパケットのうち前記一部の第１ＩＰパケット以外の第１ＩＰパケットに前記特定情報を含まない圧縮ヘッダを付与してもよい。

例えば、前記基準クロック情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）であってもよい。

例えば、前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ
Ｔｒａｎｓｐｏｒｔ）パケットに格納されてもよい。

例えば、前記フレームは、固定長の複数の第２の伝送単位を含み、前記複数の第２伝送単位の各々は１以上の第１の伝送単位を含み、前記１以上の第１の伝送単位の各々は、前記第１ＩＰパケット又は前記第２ＩＰパケットを含んでもよい。

例えば、前記第１の伝送単位は、ＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）パケットであり、前記第２の伝送単位は、高度ＢＳ伝送方式におけるスロットであり、前記フレームは、高度ＢＳ伝送方式における伝送スロットであってもよい。

本発明の一態様に係る受信方法は、放送を通じてコンテンツを受信する受信方法であって、前記コンテンツが格納された、ヘッダ圧縮されている第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む、ヘッダ圧縮されていない第２ＩＰパケットとが格納された伝送用のフレームを受信する受信ステップと、ＩＰパケットがヘッダ圧縮されているか否かに応じて、当該ＩＰパケットが前記第１ＩＰパケットであるか前記第２ＩＰパケットであるかを判定する判定ステップと、前記判定の結果に応じて、前記第２ＩＰパケットに格納された前記基準クロック情報を用いて、前記第１ＩＰパケットに格納された前記コンテンツを再生する再生ステップとを含む。

これにより、受信装置は、ヘッダ圧縮がされているか否かに応じて、ＩＰデータフローをフィルタリングできる。よって、選局時間を短縮できる。

例えば、前記ヘッダ圧縮として、（１）複数の前記第１ＩＰパケットのうち一部の第１ＩＰパケットに、前記複数の第１ＩＰパケットが属するＩＰデータフローを特定する特定情報を含むフルヘッダが付与されており、（２）前記複数の第１ＩＰパケットのうち前記一部の第１ＩＰパケット以外の第１ＩＰパケットに前記特定情報を含まない圧縮ヘッダが付与されていてもよい。

例えば、前記基準クロック情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）であってもよい。

例えば、前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ
Ｔｒａｎｓｐｏｒｔ）パケットに格納されてもよい。

例えば、前記フレームは、固定長の複数の第２の伝送単位を含み、前記複数の第２伝送単位の各々は１以上の第１の伝送単位を含み、前記１以上の第１の伝送単位の各々は、前記第１ＩＰパケット又は前記第２ＩＰパケットを含んでもよい。

例えば、前記第１の伝送単位は、ＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）パケットであり、前記第２の伝送単位は、高度ＢＳ伝送方式におけるスロットであり、前記フレームは、高度ＢＳ伝送方式における伝送スロットであってもよい。

本発明の一態様に係る送信装置は、放送を通じてコンテンツを送信する送信装置であって、前記コンテンツが格納された第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む第２ＩＰパケットとが格納された伝送用のフレームを生成する生成部と、生成された前記フレームを送信する送信部とを備え、前記生成部は、前記第１ＩＰパケットに対してはヘッダ圧縮を行い、前記第２ＩＰパケットに対してはヘッダ圧縮を行わない。

これにより、受信装置は、ヘッダ圧縮がされているか否かに応じて、ＩＰデータフローをフィルタリングできる。よって、選局時間を短縮できる。

本発明の一態様に係る受信装置は、放送を通じてコンテンツを受信する受信装置であって、前記コンテンツが格納された、ヘッダ圧縮されている第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む、ヘッダ圧縮されていない第２ＩＰパケットとが格納された伝送用のフレームを受信する受信部と、ＩＰパケットがヘッダ圧縮されているか否かに応じて、当該ＩＰパケットが前記第１ＩＰパケットであるか前記第２ＩＰパケットであるかを判定する判定部と、前記判定の結果に応じて、前記第２ＩＰパケットに格納された前記基準クロック情報を用いて、前記第１ＩＰパケットに格納された前記コンテンツを再生する再生部とを含む。

これにより、受信装置は、ヘッダ圧縮がされているか否かに応じて、ＩＰデータフローをフィルタリングできる。よって、選局時間を短縮できる。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態１）
［ＭＭＴ方式の基本的な構成］
まず、ＭＭＴ方式の基本的な構成について説明する。図１は、ＭＭＴ方式及び高度ＢＳ伝送方式を用いて伝送を行う場合のプロトコルスタック図を示す。

ＭＭＴ方式では、映像や音声などの情報を、複数のＭＰＵ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ）や複数のＭＦＵ（Ｍｅｄｉａ Ｆｒａｇｍｅｎｔ Ｕｎｉｔ）に格納し、ＭＭＴパケットヘッダを付与してＭＭＴパケット化する。

一方、ＭＭＴ方式では、ＭＭＴメッセージなどの制御情報に対してもＭＭＴパケットヘッダを付与し、ＭＭＴパケット化する。ＭＭＴパケットヘッダには、３２ビットのショートフォーマットのＮＴＰを格納するフィールドが設けられており、このフィールドは、通信回線のＱｏＳ制御等に用いることができる。

ＭＭＴパケット化されたデータは、ＵＤＰヘッダまたはＩＰヘッダを有するＩＰパケットにカプセル化される。このとき、ＩＰヘッダまたはＵＤＰヘッダにおいて、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別が同じパケットの集合をＩＰデータフローとした場合、１つのＩＰデータフローに含まれる複数のＩＰパケットは、ヘッダが冗長である。このため、１つのＩＰデータフローにおいては、一部のＩＰパケットは、ヘッダ圧縮される。

次に、ＴＬＶパケットについて詳細に説明する。図２は、ＴＬＶパケットのデータ構造を示す図である。

ＴＬＶパケットには、図２に示されるように、ＩＰｖ４パケット、ＩＰｖ６パケット、圧縮ＩＰパケット、ＮＵＬＬパケット、及び、伝送制御信号が格納される。これらの情報は、８ビットのデータタイプを用いて識別される。伝送制御信号には、例えばＡＭＴ（Ａｄｄｒｅｓｓ Ｍａｐ Ｔａｂｌｅ）、及び、ＮＩＴ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）などがある。また、ＴＬＶパケットにおいては、１６ビットのフィールドを用いてデータ長（バイト単位）が示され、そのあとにデータの値が格納される。データタイプの前には１バイトのヘッダ情報がある（図２において図示せず）ため、ＴＬＶパケットは、合計４バイトのヘッダ領域を有する。

ＴＬＶパケットは、高度ＢＳ伝送方式における伝送スロットにマッピングされ、ＴＭＣＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｎｔｒｏｌ）制御情報（制御信号）に、スロット毎に包含される最初のパケットの先頭位置と最後のパケットの末尾の位置を示すポインタ／スロット情報が格納される。

次に、ＭＭＴパケットを高度ＢＳ伝送方式を用いて伝送する場合の受信装置の構成について説明する。図３は、受信装置の基本構成を示すブロック図である。なお、図３の受信装置の構成は、簡略化されたものであり、より具体的な構成については、基準クロック情報が格納される態様に応じて個別に後述される。

受信装置２０は、受信部１０と、復号部１１と、ＴＬＶデマルチプレクサ（ＤＥＭＵＸ）１２と、ＩＰデマルチプレクサ（ＤＥＭＵＸ）１３と、ＭＭＴデマルチプレクサ（ＤＥＭＵＸ）１４とを備える。

受信部１０は、伝送路符号化データを受信する。

復号部１１は、受信部１０によって受信された伝送路符号化データを復号し、誤り訂正などを施し、ＴＭＣＣ制御情報、及び、ＴＬＶデータを抽出する。復号部１１によって抽出されたＴＬＶデータは、ＴＬＶデマルチプレクサ１２によってＤＥＭＵＸ処理される。

ＴＬＶデマルチプレクサ１２のＤＥＭＵＸ処理は、データタイプに応じて異なる。例えば、データタイプが圧縮ＩＰパケットである場合は、ＴＬＶデマルチプレクサ１２は、圧縮されたヘッダを復元してＩＰレイヤに渡すなどの処理を行う。

ＩＰデマルチプレクサ１３は、ＩＰパケットまたはＵＤＰパケットのヘッダ解析などの処理を行い、ＩＰデータフロー毎にＭＭＴパケットを抽出する。

ＭＭＴデマルチプレクサ１４では、ＭＭＴパケットヘッダに格納されているパケットＩＤを基にフィルタリング処理（ＭＭＴパケットフィルタリング）を行う。

［ＭＭＴパケットに基準クロック情報を格納する方法］
上記図１〜図３を用いて説明したＭＭＴ方式では、ＭＭＴパケットヘッダに３２ビットのショートフォーマットＮＴＰを格納して伝送することができるが、ロングフォーマットＮＴＰを伝送する方法は存在しない。

以下、ＭＭＴパケットに基準クロック情報を格納する方法について説明する。まず、ＭＭＴパケット内に基準クロック情報を格納する方法について説明する。

基準クロック情報を格納するための記述子、テーブル、またはメッセージを定義し、制御情報としてＭＭＴパケットに格納する場合、基準クロック情報を示す記述子やテーブル、またはメッセージであることを示す識別子が制御情報内に示される。そして、制御情報は、送信側においてＭＭＴパケットに格納される。

これにより、受信装置２０は、識別子を基に基準クロック情報を識別することができる。なお、既存のディスクリプタ（例えば、ＣＲＩ＿ｄｅｓｃｒｉｐｔｏｒ（）等）を用いることによって、基準クロック情報がＭＭＴパケットに格納されてもよい。

次に、ＭＭＴパケットヘッダに基準クロック情報を格納する方法について説明する。

例えば、ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎフィールド（以下拡張フィールドと記載する。）を用いて格納する方法がある。拡張フィールドは、ＭＭＴパケットヘッダのｅｘｔｅｎｓｉｏｎ＿ｆｌａｇを‘１’とすることで有効になる。

拡張フィールドには、拡張フィールドに格納するデータのデータ種別を示す拡張フィールドタイプを格納し、拡張フィールドタイプに、基準クロック情報（例えば、６４ビットのロングフォーマットＮＴＰ）であることを示す情報を格納し、拡張フィールドに基準クロック情報を格納する方法がある。

この場合、受信装置２０は、ＭＭＴパケットヘッダのｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇが‘１’となっている場合は、ＭＭＴパケットの拡張フィールドを参照する。拡張フィールドタイプに基準クロック情報であることが示されている場合には、基準クロック情報を抽出し、クロックを再生する。

なお、基準クロック情報は、既存のヘッダフィールドに格納されてもよい。また、未使用のフィールドがある場合や、放送に必要のないフィールドがある場合、これらのフィールドに基準クロック情報が格納されてもよい。

また、基準クロック情報は、既存のフィールドと拡張フィールドとを併用して格納されてもよい。例えば、既存の３２ｂｉｔショートフォーマットＮＴＰフィールドと拡張フィールドとが併用されてもよい。

既存フィールドと互換性を保つために、６４ｂｉｔロングフォーマットＮＴＰのうち、ショートフォーマットのフォーマットに対応する３２ｂｉｔ部分のみが既存フィールドに格納され、残りの３２ｂｉｔが拡張フィールドに格納されてもよい。

なお、基準クロック情報は、例えば、基準クロック情報が格納されるＭＭＴパケットの先頭のビットが所定の位置を通過するとき（例えば、送信装置の特定の構成要素から出力されるとき）の時刻であるが、他の位置のビットが所定の位置を通過するときの時刻であってもよい。

基準クロック情報が制御情報としてＭＭＴパケットに格納される場合、制御情報を含むＭＭＴパケットは、所定の送信間隔で送信される。

基準クロック情報がＭＭＴパケットの拡張フィールドに格納される場合は、所定のＭＭＴパケットのヘッダの拡張フィールドに格納される。具体的には、例えば、基準クロック情報は、１００ｍｓ間隔で少なくとも１つ以上、ＭＭＴパケットのヘッダ拡張フィールドに格納される。

なお、ＭＭＴパケットに基準クロック情報が格納される場合、プログラム情報には、基準クロック情報が格納されているＭＭＴのパケットＩＤが格納される。受信装置２０は、プログラム情報を解析し、基準クロック情報が格納されたＭＭＴパケットを取得する。このとき、基準クロック情報が格納されたＭＭＴパケットのパケットＩＤは、あらかじめ固定値として規定されてもよい。これにより、受信装置２０は、プログラム情報を解析することなく基準クロック情報を取得できる。

［ＭＭＴパケットに基準クロック情報を格納した場合の動作フロー］
次に、ＭＭＴパケットに基準クロック情報を格納した場合の動作フロー（基準クロック情報の取得フロー）について説明する。

まず、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローについて説明する。図４は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置２０の機能構成を示すブロック図である。図５は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローを示す図である。

図４に示されるように、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合、ＭＭＴデマルチプレクサ１４内には、基準クロック情報抽出部１５（抽出部の一例）が設けられ、ＭＭＴデマルチプレクサ１４の後段には、基準クロック生成部１６（生成部の一例）が設けられる。

図５のフローにおいて、受信装置２０の復号部１１は、受信部１０が受信した伝送路符号化データを復号し（Ｓ１０１）、伝送スロットからＴＬＶパケットを抽出する（Ｓ１０２）。

次に、ＴＬＶデマルチプレクサ１２は、抽出されたＴＬＶパケットをＤＥＭＵＸし、ＩＰパケットを抽出する（Ｓ１０３）。このとき、圧縮ＩＰパケットのヘッダが再生される。

次に、ＩＰデマルチプレクサ１３は、ＩＰパケットをＤＥＭＵＸし、指定されたＩＰデータフローを取得し、ＭＭＴパケットを抽出する（Ｓ１０４）。

次に、ＭＭＴデマルチプレクサ１４は、ＭＭＴパケットのヘッダを解析し、拡張フィールドが使用されているかどうか、拡張フィールドに基準クロック情報があるかどうかの判定を行う（Ｓ１０６）。拡張フィールドに基準クロック情報がない場合は（Ｓ１０６でＮｏ）、処理を終了する。

一方、拡張フィールドに基準クロック情報があると判定された場合（Ｓ１０６でＹｅｓ）、基準クロック情報抽出部１５は、拡張フィールドから基準クロック情報を抽出する（Ｓ１０７）。そして、基準クロック生成部１６は、抽出された基準クロック情報を基にシステムクロックを生成する（Ｓ１０８）。システムクロックは、言い換えれば、コンテンツを再生するためのクロックである。

次に、制御情報に基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローについて説明する。図６は、制御情報に基準クロック情報が格納される場合の受信装置２０の機能構成を示すブロック図である。図７は、制御情報に基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローを示す図である。

図６に示されるように、制御情報に基準クロック情報が格納される場合、基準クロック情報抽出部１５は、ＭＭＴデマルチプレクサ１４の後段に配置される。

図７のフローにおいて、ステップＳ１１１〜ステップＳ１１４の処理は、図５で説明したステップＳ１０１〜ステップＳ１０４のフローと同一である。

ステップＳ１１４に続いて、ＭＭＴデマルチプレクサ１４は、プログラム情報から基準クロック情報を含むパケットのパケットＩＤを取得し（Ｓ１１５）、当該パケットＩＤのＭＭＴパケットを取得する（Ｓ１１６）。続いて、基準クロック情報抽出部１５は、抽出したＭＭＴパケットに含まれる制御信号から基準クロック情報を抽出し（Ｓ１１７）、基準クロック生成部１６は、抽出された基準クロック情報を基にシステムクロックを生成する（Ｓ１１８）。

［ＴＬＶパケットに基準クロック情報を格納する方法］
図５及び図７で説明したように、ＭＭＴパケットに基準クロック情報が格納される場合、受信側で基準クロック情報を得るためには、受信装置２０は、伝送スロットからＴＬＶパケットを抽出し、ＴＬＶパケットからＩＰパケットを抽出する。さらに、受信装置２０は、ＩＰパケットからＭＭＴパケットを抽出し、さらにＭＭＴパケットのヘッダまたはペイロードから基準クロック情報を抽出する。このように、ＭＭＴパケットに基準クロック情報が格納される場合、基準クロック情報を取得するための処理が多く、さらに取得までに多くの時間を要することが課題である。

そこで、基準クロックを基に映像や音声などのメディアにタイムスタンプを付与する処理及びメディアを伝送する処理は、ＭＭＴ方式を用いて実現し、かつ、基準クロック情報の伝送を、ＭＭＴレイヤよりも下位のレイヤ、下位のプロトコル、または下位の多重化方式を用いて行う方法について説明する。

まず、ＴＬＶパケットに基準クロック情報を格納して伝送する方法について説明する。図８は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置２０の構成を示すブロック図である。

図８に示される受信装置２０では、基準クロック情報抽出部１５と、基準クロック生成部１６との配置が図４及び図６と異なる。また、図８では同期部１７及び復号提示部１８も図示されている。

ＴＬＶパケットの構成は、上記図２に示されるように、８ビットのデータタイプ、１６ビットのデータ長、及び８＊Ｎビットのデータから構成される。また、上述のようにデータタイプの前には、図２において図示されない１バイトのヘッダが存在する。なお、データタイプは、具体的には、例えば、０ｘ０１：ＩＰｖ４パケット、０ｘ０３：ヘッダ圧縮したＩＰパケットなどと規定される。

新規のデータをＴＬＶパケットに格納するために、データタイプの未定義領域を用いてデータタイプが規定される。ＴＬＶパケットに基準クロック情報が格納されていることを示すために、データタイプには、データが基準クロック情報であることを示す記述がなされる。

なお、データタイプは、基準クロックの種類毎に規定されてもよい。例えば、ショートフォーマットＮＴＰ、ロングフォーマットＮＴＰ、及びＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）を示すデータタイプがそれぞれ個別に規定されてもよい。図９は、ロングフォーマットＮＴＰがＴＬＶパケットに格納される例を示す図であり、ロングフォーマットＮＴＰは、データフィールドに格納されている。

この場合、基準クロック情報抽出部１５は、ＴＬＶパケットのデータタイプを解析し、基準クロック情報が格納されている場合には、データ長を解析し、データフィールドから基準クロック情報を抽出する。

なお、データタイプによって、データ長が一意に決定されている場合、基準クロック情報抽出部１５は、データ長フィールドを解析することなく基準クロック情報を取得してもよい。例えば、データタイプが６４ｂｉｔロングローマットＮＴＰであることが示されている場合、基準クロック情報抽出部１５は、４バイト＋１ビット目から４バイト＋６４ビット目までを抽出してもよい。また、基準クロック情報抽出部１５は、６４ｂｉｔのデータから、所望のビットだけを抽出してもよい。

次に、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置２０の動作フロー（基準クロック情報の取得フロー）について、図１０を用いて説明する。図１０は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローを示す図である。

図１０のフローにおいては、まず、復号部１１は、受信部１０が受信した伝送路符号化データを復号し（Ｓ１２１）、伝送スロットからＴＬＶパケットを抽出する（Ｓ１２２）。

次に、ＴＬＶデマルチプレクサ１２は、ＴＬＶパケットのデータタイプを解析し（Ｓ１２３）、データタイプが基準クロック情報であるかどうかの判定を行う（Ｓ１２４）。データタイプが基準クロックである場合は（Ｓ１２４でＹｅｓ）、基準クロック情報抽出部１５は、ＴＬＶパケットのデータフィールドから基準クロック情報を抽出する（Ｓ１２５）。そして、基準クロック生成部１６は、基準クロック情報を基に、システムクロックを生成する（Ｓ１２６）。一方、データタイプが基準クロック情報でない場合は（Ｓ１２４でＮｏ）、基準クロック情報の取得フローは終了する。

また、図示されないフローにおいて、ＩＰデマルチプレクサ１３は、データタイプに応じてＩＰパケットを抽出する。そして、抽出されたＩＰパケットに対してＩＰ ＤＥＭＵＸ処理、及びＭＭＴ ＤＥＭＵＸ処理が行われてＭＭＴパケットが抽出される。さらに、同期部１７は、抽出されたＭＭＴパケットに含まれる映像データのタイムスタンプがステップＳ１２６で生成された基準クロックに一致するタイミングで復号提示部１８に当該映像データを出力し、復号提示部１８は、映像データを復号及び提示する。

以上説明した送信方法では、ＴＬＶパケットのタイプデータにおいて基準クロック情報を格納していることが示され、ＴＬＶパケットのデータフィールドに基準クロック情報が格納される。このように、ＭＭＴレイヤよりも下位のレイヤまたは下位のプロトコルを用いて基準クロック情報を格納し、送信することにより、受信装置２０における基準クロック情報を抽出するまでの処理や時間を削減することができる。

また、ＩＰレイヤにまたがって、より下位のレイヤで基準クロック情報が抽出・再生できるため、基準クロック情報の抽出をハードウェア実装により行うことができる。これにより、基準クロック情報の抽出をソフトウェア実装により行う場合よりもジッタなどの影響を軽減することができ、より高精度な基準クロックを生成することが可能となる。

次に、基準クロック情報を格納するその他の方法について説明する。

上記図１０のフローにおいて、データタイプによってデータ長が一意に決定される場合、データ長フィールドは、送信されなくてもよい。なお、データ長フィールドが送信されない場合は、データ長フィールドが送信されないデータであることを示す識別子が格納される。

また、図１０の説明では、基準クロック情報は、ＴＬＶパケットのデータフィールドに格納されたが、基準クロック情報は、ＴＬＶパケットの直前や直後に付加されてもよい。また、基準クロック情報は、ＴＬＶパケットに格納されるデータの直前や直後に付加されてもよい。これらの場合、基準クロック情報が付加されている場所を特定できるようなデータタイプが付与される。

例えば、図１１は、ＩＰパケットのヘッダの直前に基準クロック情報が付加される構成を示す図である。この場合、データタイプは、基準クロック情報付ＩＰパケットであることを示す。受信装置２０（基準クロック情報抽出部１５）は、データタイプが基準クロック情報付ＩＰパケットであること示す場合、ＴＬＶパケットのデータフィールドの先頭から、あらかじめ定めされた所定の基準クロック情報の長さのビットを抽出することにより、基準クロック情報を取得できる。このとき、データ長は、基準クロック情報の長さを含むデータの長さを指定してもよいし、基準クロック情報の長さを含まない長さを指定してもよい。データ長に基準クロック情報の長さを含むデータの長さが指定されている場合、受信装置２０（基準クロック情報抽出部１５）は、データ長から基準クロック情報の長さを減算した長さのデータを基準クロック情報の直後から取得する。データ長に基準クロック情報の長さを含まないデータの長さが指定されている場合、受信装置２０（基準クロック情報抽出部１５）は、データ長に指定されている長さのデータを基準クロック情報の直後から取得する。

また、図１２は、ＴＬＶパケットの直前に基準クロック情報が付加される構成を示す図である。この場合、データタイプは従来通りのデータタイプとし、ＴＬＶパケットが基準クロック情報付ＴＬＶパケットであること示す識別子が、例えば、伝送スロットのスロットヘッダまたはＴＭＣＣ制御情報に格納される。図１３は、伝送スロットの構成を示す図であり、図１４は、伝送スロットのスロットヘッダの構成を示す図である。

図１３に示されるように、伝送スロットは、複数のスロット（図１３の例では、Ｓｌｏｔ＃１−Ｓｌｏｔ＃１２０の１２０個のスロット）から構成される。各スロットに含まれるビット数は、誤り訂正の符号化率に基づいて一意に定められた固定ビット数であり、スロットヘッダを有し、１以上のＴＬＶパケットが格納される。なお、図１３に示されるように、ＴＬＶパケットは、可変長である。

図１４に示されるように、スロットヘッダの先頭ＴＬＶ指示フィールド（１６ｂｉｔｓ）には、スロット中の最初のＴＬＶパケットの先頭バイトの位置を、スロットヘッダを除いたスロット先頭からのバイト数で示したものが格納される。スロットヘッダの残りの１６０ｂｉｔｓは、未定義である。伝送スロットは、上述のように１フレームあたり１２０個のスロットで構成され、スロットへの変調方式の割り当ては５スロット単位である。また、１フレーム内では最大１６のストリームを伝送可能である。なお、１つの伝送スロットに含まれる複数のストリームは、例えば、当該ストリームによって伝送されるコンテンツ（または、コンテンツを提供する事業者）が互いに異なる。また、ストリームは、１以上のスロットで構成され、１つのスロットが複数のストリームにまたがることはない。

ＴＬＶパケットが基準クロック情報付ＴＬＶパケットであること示す識別子が、スロットヘッダに格納される場合、例えば、スロット内において基準クロック情報付ＴＬＶパケットの位置を特定できる情報、基準クロック情報の種類、及びデータ長などが、スロットヘッダの未定義フィールドを拡張（利用）して格納される。

なお、基準クロック情報付ＴＬＶパケットの位置を特定できる情報、基準クロック情報の種類、及び、データ長のすべての情報がスロットヘッダに格納されていなくてもよい。基準クロック情報付ＴＬＶパケットを特定及び参照することができる情報が示されていればよい。

例えば、基準クロック情報が、６４ビットロングフォーマットＮＴＰであり、１つのスロットに格納できる基準クロック情報付ＴＬＶパケットは１つであり、かつ、必ず先頭のＴＬＶパケットであると定義される場合、スロットヘッダの未定義領域にフラグが格納されてもよい。図１５は、スロットヘッダの未定義領域にフラグが格納される例を示す図である。

図１５の例では、スロットヘッダの未定義領域に、当該スロットに基準クロック情報が含まれているかどうか示すフラグ（図中で「Ｆ」と記載）が格納されている。このようなフラグによって、受信装置２０は、先頭のＴＬＶパケットが基準クロック情報付ＴＬＶパケットであると判断してもよい。

また、ＴＬＶパケットが基準クロック情報付ＴＬＶパケットであること示す識別子（情報）は、ＴＭＣＣ制御情報に格納されてもよい。図１６は、高度広帯域衛星デジタル放送の伝送方式におけるＴＭＣＣ制御情報の構成を示す図である。

基準クロック情報付ＴＬＶパケットを特定及び参照するための情報は、図１６に示されるＴＭＣＣ制御情報内の拡張情報に格納されてもよいし、ＴＭＣＣ制御情報内のその他の場所に格納されてもよい。例えば、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報が、基準クロック情報付ＴＬＶパケットを特定及び参照するための情報として使用されてもよい。図１７は、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報を示す図である。

図１７に示されるように、ストリーム種別／相対ストリーム情報においては、１６本のストリーム毎のストリーム種別が８ビットで示される。つまり、１フレームの伝送スロットによれば、最大１６本（１６種別）のストリームを伝送することができる。例えば、ＭＰＥＧ２−ＴＳストリームのストリーム種別は、「００００００００」であり、ＴＬＶストリームのストリーム種別は、「００００００１０」である。しかしながら、その他のストリームに対しては、現状、割り当て種別なし又は未定義である。

そこで、基準クロック付ＴＬＶストリームのストリーム種別を、例えば「０００００１００」と定義し、相対ストリームが基準クロック付ＴＬＶストリームである場合には、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報に「０００００１００」を格納する。ここで、ストリーム種別が「０００００１００」となっているストリームにおいては、例えば、スロット割り当て単位である５スロット単位に一回、または、フレーム単位に一回、基準クロック情報を含むＴＬＶパケットが格納される。

このような構成においては、受信装置２０は、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報を解析し、ストリーム種別が「０００００１００」となっている場合、あらかじめ定められたスロットから基準クロック付ＴＬＶパケットを取得する。

なお、ダウンロード型ＴＬＶパケットを含むストリーム種別と、映像や音声などのストリーム型ＴＬＶパケットを含むストリーム種別とが定義される場合が考えられる。このような場合、受信装置２０は、受信したストリームのストリーム種別が、ストリーム型ＴＬＶパケットであるときに、ストリームに基準クロック情報が含まれると判断してもよい。なぜなら、ダウンロード型のＴＬＶパケットの再生においては、通常、基準クロック情報は用いられないからである。

また、基準クロック情報付ＴＬＶパケットを特定及び参照するための情報がＴＭＣＣ制御情報の拡張情報に格納される場合は、例えば、１６本の相対ストリーム毎の情報がＴＭＣＣ制御情報の拡張領域に格納される。

また、図１８に示されるように、スロットヘッダの未定義フィールドに基準クロック情報が格納される領域が新たに定義されてもよい。図１８は、スロットヘッダの未定義フィールドに基準クロック情報が格納される例を示す図である。

また、あらかじめ定められたスロットに基準クロック情報が格納されてもよいし、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納されてもよい。ここで、あらかじめ定められたスロットは、例えば、伝送スロットのうちの先頭のスロット（図１３の例ではＳｌｏｔ＃１）であり、このスロット内の先頭のＴＬＶパケットにＩＰパケットに格納された基準クロック情報が含まれてもよい。また、伝送スロットに複数のストリームが含まれる場合、あらかじめ定められたスロットは、例えば、伝送スロットに含まれる各ストリームの先頭のスロットであり、このスロット内の先頭のＴＬＶパケットにＩＰパケットに格納された基準クロック情報が含まれてもよい。

また、ＴＭＣＣ制御情報には、基準クロック情報を含むスロットヘッダを特定し参照するための情報が格納されてもよい。なお、基準クロック情報を含むスロットヘッダを特定及び参照するための情報のＴＭＣＣ制御情報への格納方法は、上述した基準クロック情報付ＴＬＶパケットを特定及び参照するための情報の格納方法と同様であるため、説明が省略される。

この場合、受信装置２０は、ＴＭＣＣ制御情報を解析し、スロットヘッダに基準クロック情報があると判定した場合には、スロットヘッダから基準クロック情報を抽出する。

また、ＴＭＣＣ制御情報に基準クロック情報を含むことを示す情報が格納されてもよい。図１９は、ＴＭＣＣ制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置２０の機能構成を示すブロック図である。図２０は、スロットヘッダに基準クロック情報を含むことを示す情報がＴＭＣＣ制御情報に格納される場合の基準クロック情報の取得フローである。

図１９に示されるように、ＴＭＣＣ制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置２０においては、基準クロック情報抽出部１５は、復号部１１から出力される伝送スロットから基準クロック信号を取得する。

図２０のフローでは、復号部１１は、伝送路符号化データを復号し（Ｓ１３１）、ＴＭＣＣ制御情報を解析し（Ｓ１３２）、伝送スロット内のスロットヘッダに基準クロック情報があるかどうかを判定する（Ｓ１３３）。スロットヘッダに基準クロック情報がある場合は（Ｓ１３３でＹｅｓ）、基準クロック情報抽出部１５は、スロットヘッダから基準クロック情報を抽出し（Ｓ１３４）、基準クロック生成部１６は、基準クロック情報を基にシステムの基準クロック（システムクロック）を生成する（Ｓ１３５）。一方、スロットヘッダに基準クロック情報がない場合は（Ｓ１３３でＮｏ）、基準クロック情報の取得フローは終了する。

このような受信装置２０は、伝送スロットのレイヤで基準クロック情報を取得することができるため、ＴＬＶパケットに格納する場合よりもさらに早く基準クロック情報を取得できる。

以上説明したように、ＴＬＶパケットや伝送スロットに基準クロック情報を格納することにより、受信装置２０において、基準クロック情報を取得するまでの処理を軽減することができ、かつ、基準クロック情報の取得時間を短縮できる。

また、このように、物理レイヤにおいて基準クロック情報が格納されることにより、ハードウェアによる基準クロック情報の取得及び再生が容易に実現でき、ソフトウェアによる基準クロック情報の取得及び再生よりも精度の高いクロック再生が可能である。

また、上記実施の形態１に係る送信方法は、まとめると、ＩＰレイヤを含む複数のレイヤ（プロトコル）が存在するシステムにおいて、ＩＰレイヤより上位のレイヤで基準クロック情報を基にメディアのタイムスタンプを付与し、ＩＰレイヤより下位のレイヤで基準クロック情報を送信する。このような構成によれば、受信装置２０において基準クロック情報をハードウェアで処理することが容易となる。

なお、同様の思想に基づき、ＩＰパケット内にＭＭＴパケットに格納されない状態で基準クロック情報を格納することも考えられる。このような場合であっても、ＭＭＴパケットに基準クロック情報が格納される場合よりも、基準クロック情報を取得するための処理を軽減することができる。

［基準クロック情報の送出周期］
以下、基準クロック情報の送出周期について補足する。

ＴＬＶパケットに基準クロック情報を格納する場合、例えば、送信側においてＴＬＶパケットの先頭のビットが送出される時刻を基準クロック情報として格納する。また、先頭のビットの送出時刻ではなく、他に定められた所定の時刻が基準クロック情報として格納されてもよい。

基準クロック情報を含むＴＬＶパケットは、所定の間隔で送信される。言い換えれば、基準クロック情報を含むＴＬＶパケットは、伝送スロットに含まれて所定の送信周期で送信される。例えば、基準クロック情報は、１００ｍｓ間隔に少なくとも１つ以上、ＴＬＶパケットに格納されて伝送されてもよい。

また、高度ＢＳ伝送方式の伝送スロットの所定の場所に、所定の間隔で基準クロック情報を含むＴＬＶパケットが配置されてもよい。また、ＴＬＶパケットのスロット割り当て単位である５スロット単位毎に一回、基準クロック情報を含むＴＬＶパケットが格納され、５スロット単位のうち一番初めのスロットの先頭のＴＬＶパケットに基準クロック情報が格納されてもよい。すなわち、伝送スロット内の先頭のスロット内の先頭（つまり、スロットヘッダの直後）に、基準クロック情報を含むＴＬＶパケットが配置されてもよい。

また、高度広帯域衛星デジタル放送の伝送方式の伝送スロットの所定の場所に、所定の間隔で基準クロック情報を含むＴＬＶパケットが配置されてもよい。例えば、スロット割り当て単位である５スロット単位にごとに一回、基準クロック情報が一番初めのスロットの先頭のＴＬＶパケットに格納されてもよい。すなわち、伝送スロットに含まれる各ストリームの先頭のスロット内で先頭に位置するＴＬＶパケットに、基準クロック情報が含まれてもよい。また、基準クロック情報は、相対ストリームの中で１番目のスロットに格納されてもよい。

また、基準クロック情報の送出周期及び送出間隔は、伝送路符号化方式の変調方式または符号化率に応じて変更されてもよい。

［上位レイヤの基準クロック情報を早く取得する方法］
次に、受信装置２０において下位レイヤから上位レイヤまでのＤＥＭＵＸを一括で処理することにより、基準クロック情報の取得までの時間を短縮する方法について説明する。

ここでは、ＭＭＴパケットなどの上位レイヤに基準クロック情報を格納し、基準クロック情報が格納されたＭＭＴパケットをＩＰパケットに格納する方法について説明する。以下で説明する方法では、基準クロック情報が格納されたＩＰパケットをＴＬＶパケットに格納するためのプロトコルを定義することにより、ＴＬＶパケットのような下位レイヤから、上位レイヤであるＭＭＴパケットを直接参照し、通常のＤＥＭＵＸ処理をすることなくＭＭＴパケットに含まれる基準クロック情報を取得する。

送信側において、基準クロック情報は、上述のＭＭＴパケットに格納される制御情報に含まれる。基準クロック情報を含む制御情報には、あらかじめ定められたパケットＩＤが付与される。そして、送信側においては、基準クロック情報を含むＭＭＴパケットは、専用のＩＰデータフローに格納され、あらかじめ定められた、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別が付与される。

このように生成された伝送路符号化データを受信した受信装置２０においては、ＴＬＶデマルチプレクサ１２があらかじめ定められたＩＰデータフロー取得することにより、基準クロック情報を含むＩＰパケットを抽出することができる。

なお、ＩＰパケットがヘッダ圧縮される場合には、例えば、同一のＩＰデータフローであることを示すコンテクスト識別子に、基準クロック情報を含むＩＰパケットであることを示す識別子が付与される。コンテクスト識別子は、圧縮ＩＰパケットヘッダに格納されている。この場合、受信装置２０は、圧縮ＩＰパケットヘッダのコンテクスト識別子を参照することにより、基準クロック情報を含むＩＰパケットを抽出できる。

また、基準クロック情報を含むＩＰパケットは、ヘッダ圧縮されないと規定されてもよいし、必ずヘッダ圧縮されると規定されてもよい。基準クロック情報を含むＩＰパケットには、あらかじめ定めされたコンテクスト識別子が付与され、すべてのヘッダが圧縮されると規定されてもよい。

また、ＴＬＶのデータタイプフィールドに、基準クロック情報を含むＩＰデータフローに属するＩＰパケットであることを示す識別子、または、基準クロック情報を含むＩＰデータフローに属する圧縮ＩＰパケットであることを示す識別子などを定義する方法も考えられる。また、このような識別子は、ＴＬＶのデータタイプフィールド以外のフィールドに定義されてもよい。

基準クロック情報を下位のレイヤから直接参照する場合、基準クロック情報はあらかじめ定められた位置に格納され、基準クロック情報が格納されるパケット（ＭＭＴパケット、ＩＰパケット、及びＴＬＶパケットなど）は、基準クロック情報専用のパケットとする。また、パケットヘッダ長は固定長にするなど、基準クロック情報よりも前のフィールドの長さは一定となるようにする。

このとき、基準クロック情報よりも前のフィールドの長さは、一定でなくてもよい。下位のレイヤにおいて、基準クロック情報よりも前のフィールドの長さが特定できればよい。例えば、基準クロック情報までの長さの情報としてＡとＢの２種類がある場合、受信装置２０は、下位レイヤにおいてＡとＢのどちらであるかをシグナリングすることにより、基準クロック情報の位置を特定できる。或いは、送信側で、上位レイヤの基準クロック情報を直接参照可能な基準クロック情報の位置情報を下位レイヤに格納し、受信装置２０は、下位レイヤから位置情報に基づいて参照してもよい。

以下、上位レイヤの基準クロック情報を早く取得する方法について具体的に説明する。

受信装置２０は、ＴＬＶのデータタイプを判定し、基準クロック情報を含むと判定されれば、ＩＰパケットからＭＭＴパケット内に含まれる基準クロック情報を直接取得する。

このように、受信装置２０は、ＩＰアドレスやポート番号、コンテクスト識別子を解析することなく、ＩＰパケットや圧縮ＩＰパケットから特定位置のビット列を抽出することで、ＭＭＴパケットに含まれる基準クロック情報を抽出してもよい。特定位置のビット列を抽出するとは、例えば、ＴＬＶパケットヘッダから、固定長バイトだけオフセットした位置から特定の長さ分の情報を抽出することを意味し、これにより、基準クロック情報が取得される。

基準クロック情報を抽出するための固定長バイトのオフセットの長さは、ＩＰパケットと圧縮ＩＰパケットとのそれぞれにおいて一意に決まる。このため、受信装置２０は、ＴＬＶのデータタイプを判定した後、直ちに固定長バイトだけオフセットした位置から特定の長さ分の情報を抽出することにより基準クロック情報を取得できる。なお、このときの抽出は、ＴＬＶパケットヘッダから固定長オフセットした位置ではなく、ＴＬＶの特定のフィールドから固定長オフセットした位置から行われてもよい。

なお、上記の方法は一例であり、他のプロトコルや識別子を定義することにより、下位レイヤから上位レイヤの基準クロック情報が取得されてもよい。例えば、ＩＰパケットに基準クロック情報を含むかどうかの識別子がＴＬＶデータタイプ以外のフィールドに格納されてもよい。

また、例えば、ＩＰアドレスやポート番号、コンテクスト識別子を解析することなく、ＩＰパケットまたは圧縮ＩＰパケットから特定位置のビット列を抽出することで、ＭＭＴパケットに含まれる基準時刻情報を抽出してもよい。

ＩＰデータフローの識別情報から基準クロック情報を含むＩＰデータフローを判定できない場合には、基準クロック情報を含むＭＭＴパケットに付与された固有の識別情報（パケットＩＤ）に基づいて基準クロック情報を含むＭＭＴパケットが特定されてもよい。この場合、上述のように特定のフィールドから基準クロック情報が抽出される。

また、ＭＭＴパケットに含まれる基準クロック情報があらかじめ定められた位置に格納されていない場合、または、ＭＭＴパケットに含まれる基準クロック情報が格納されている位置を特定できない場合が想定される。このような場合、受信装置２０は、上記の方法を用いて基準クロック情報を含むＭＭＴパケットを特定し、ＭＭＴパケットヘッダ情報を基に基準クロック情報の位置を特定し、抽出する。

なお、上記では、ＭＭＴパケットがＩＰパケットに格納される場合を例に説明したが、ＩＰパケットに格納されるデータは、ＭＭＴパケットでなくてもよく、例えば、他のデータ構造を持つデータでもよい。つまり、基準クロック情報は、ＩＰパケットに、ＭＭＴパケットと異なるデータ構造で含まれてもよい。他のデータ構造を持つデータの場合でも、上記の例と同様に、基準クロック情報を含むデータが専用のＩＰデータフローに格納され、基準クロック情報を含むデータであることを示す識別情報や基準クロック情報を含むＩＰデータフローであることを示す識別情報が付与される。

受信装置２０は、基準クロック情報を含むデータであることや、基準クロック情報を含むデータを含むＩＰデータフローであること識別し、基準クロック情報を含む場合には、基準クロック情報を抽出する。また、受信装置２０は、データの特定の位置に基準クロック情報が格納されている場合は、下位のレイヤのパケット構成から特定の位置を参照することでデータに含まれる基準クロック情報を抽出できる。

上記の例では、ＩＰパケットや圧縮ＩＰパケットから基準クロック情報を抽出するために、受信装置２０は、ＩＰパケットであるか圧縮ＩＰパケットであるかに基づいて、それぞれ異なる固定長オフセット位置から基準クロック情報を抽出する。しかしながら、基準クロック情報を含むＩＰパケットはヘッダ圧縮されない、または、基準クロック情報を含むすべてのＩＰパケットがヘッダ圧縮されると定められていれば、受信装置２０におけるＩＰパケットか圧縮ＩＰパケットかの判定を省略することができる。また、圧縮ＩＰパケットのヘッダが復元された後に、基準クロック情報を含むかどうかの判定が行われてもよい。

以下、ＩＰパケットまたは圧縮ＩＰパケットから特定位置のビット列を抽出する場合の受信方法について、フローチャートを参照しながら説明する。図２１は、ＩＰパケットまたは圧縮ＩＰパケットから特定位置のビット列を抽出する場合のフローである。なお、この場合の受信装置２０の構成は、図８に示されるブロック図と同様である。

図２１のフローにおいては、まず、復号部１１は、受信部１０が受信した伝送路符号化データを復号し（Ｓ１４１）、伝送路スロットからＴＬＶパケットを抽出する（Ｓ１４２）。

次に、ＴＬＶデマルチプレクサ１２は、ＴＬＶパケットのデータタイプを解析し（Ｓ１４３）、データタイプが基準クロック情報を含むＩＰであるかどうかの判定を行う（Ｓ１４４）。データタイプが基準クロック情報を含むＩＰパケットでないと判定された場合（Ｓ１４４でＮｏ）、フローは終了する。データタイプが基準クロック情報を含むＩＰパケットであると判定された場合（Ｓ１４４でＹｅｓ）、ＩＰパケット及びＭＭＴパケットを解析し、ＩＰヘッダが圧縮されているかどうかの判定を行う（Ｓ１４５）。

ＩＰヘッダが圧縮されていない場合（Ｓ１４５でＮｏ）、基準クロック情報抽出部１５は、ＴＬＶヘッダから固定長Ｎバイトだけオフセットした位置のＭＭＴパケットの中に含まれる基準クロック情報を取得する（Ｓ１４６）。ＩＰヘッダが圧縮されている場合（Ｓ１４５でＹｅｓ）、基準クロック情報抽出部１５は、ＴＬＶヘッダから固定長Ｍバイトだけオフセットした位置のＭＭＴパケットの中に含まれる基準クロック情報を取得する（Ｓ１４７）。

例えば、ステップＳ１４５においてＩＰヘッダが圧縮されていると判定された場合、ステップＳ１４６では、基準クロック情報抽出部１５は、ＴＬＶヘッダからＮバイトオフセットした位置からＭＭＴパケットに含まれる基準クロック情報を取得する。一方、ステップＳ１４５においてＩＰヘッダ圧縮されていないと判定された場合、ステップＳ１４７において、基準クロック情報抽出部１５は、ＴＬＶヘッダからＭバイトオフセットした位置からＭＭＴパケットに含まれる基準クロック情報を取得する。

最後に、基準クロック生成部１６は、基準クロック情報を基に、システムクロックを生成する（Ｓ１４８）。

なお、ＩＰパケットがＩＰｖ４であるか、ＩＰｖ６であるかによって、ＩＰパケットヘッダのデータ構造が異なるため、固定長Ｎバイトや、Ｍバイトは異なる値となる。

音声、映像、及び制御信号などを含む通常のＭＭＴパケットは、通常のステップでＤＥＭＵＸ処理が行なわれるのに対し、基準クロック情報を含むＭＭＴパケットは、下位レイヤから上位レイヤまでのＤＥＭＵＸ処理が一括で行われる。これにより、上位レイヤに基準クロック情報が格納されている場合であっても、下位レイヤにおいて基準クロック情報の取得ができる。つまり、基準クロック情報の取得のための処理を軽減し、かつ、基準クロック情報の取得までの時間を短縮することができ、ハードウェア実装も容易となる。

（実施の形態２）
現在、高度ＢＳ伝送方式におけるＴＭＣＣ制御情報（以下、単にＴＭＣＣとも記載する）の拡張領域の活用方法として、緊急性の高い情報などをペイロードとして送信する方法がＡＲＩＢ（電波産業会）において検討されている。

しかし、提案されている従来のＴＭＣＣ制御情報の拡張領域の使用方法は、数フレームに渡るＴＭＣＣ制御情報を用いて、テキストや画像などのデータペイロードを送信する方法に限定したものである。したがって、ＴＭＣＣ制御情報の拡張領域の使用方法が限定されてしまうという課題があった。

特に、従来の伝送モードや、スロット情報などの、フレーム毎に値の変わらない制御情報（制御信号）、または、基準クロック情報など、フレーム毎に値の変わる制御情報は、数フレームにまたがるペイロードデータと同時にＴＭＣＣ制御情報の拡張領域に格納することができなかった。

そこで、実施の形態２では、ＴＭＣＣ制御情報の拡張領域に格納される情報やデータの種別に応じて、ＴＭＣＣ制御情報の拡張領域を分割することにより、受信処理が異なるデータを同時にＴＭＣＣ制御情報の拡張領域に格納することを可能とする方法について説明する。このような方法で拡張領域の使用に拡張性を持たせることにより、拡張の柔軟性を向上させることができる。また、受信装置は、データの種別に基づいて、種別毎に異なる受信方法でＴＭＣＣ制御情報の受信や解析をすることができる。

また、このような方法によれば、数フレームにまたがるペイロードデータと、１フレームのみのペイロードデータとを拡張領域において混在させることが可能である。数フレームにまたがるペイロードデータが受信できない間でも、１フレームのみのペイロードデータを先に取得できることから、緊急性の高い情報をより早く取得、提示することが可能となる。

［ＴＭＣＣ拡張情報の構成］
以下、ＴＭＣＣ拡張情報の構成について説明する。なお、ＴＭＣＣ制御情報の基本構成は、図１６に示される構成であり、ＴＭＣＣ制御情報に格納される制御情報の種類は、次の二つに大別される。

一つは、フレームに関する制御情報であって、フレーム毎に値が変化しない制御情報である。このような制御情報の最小更新間隔はフレーム単位であり、値が変更される場合は２フレーム先行して変更後の情報が送信される。また、変更がある場合は、８ｂｉｔの変更指示がインクリメントされることにより通知が行われる。このような制御情報は、具体的には、ポインタ情報及びスロット情報以外の情報が該当する。

もう一つは、フレームに関する制御情報であって、フレーム毎に値が変化する制御情報である。このような制御情報は、フレーム毎に値が変わる情報であるため、変更指示は行われない。このような制御情報は、具体的には、ポインタ情報及びスロット情報である。

ＴＭＣＣ拡張情報は、図２２の（ａ）に示されるように、１６ビットの拡張識別と３５９８ビットの拡張領域とで構成され、拡張識別にａｌｌ ０以外の値を設定することで拡張領域が有効となる。図２２は、ＴＭＣＣ拡張情報の構成を示す図である。

図２２の（ｂ）は、従来提案されている、拡張領域がペイロードとして使用される場合のビット割り当て方法の一例を示した図である。図２２の（ｂ）に示されるように、拡張領域がペイロードとして使用される場合、ページ数は１６ビットで構成され、付加情報ペイロードは、伝送中のＴＭＣＣ制御情報が何フレーム分にわたって伝送されるかを示す。

ページ番号は、１６ビットで構成され、現在伝送中のＴＭＣＣ制御情報がページ数のうちの何ページ目かを示す。付加情報種別は、８ビットで構成され、付加情報の種別を指定する。付加情報種別は、具体的には、例えば、文字（字幕）スーパー、グラフィック、音声などである。

このような構成の場合、拡張領域すべてをペイロードとして使用することになり、拡張領域を用いて、従来のＴＭＣＣ制御情報のような制御情報を拡張領域に格納することができない。

［ＴＭＣＣ拡張領域の拡張方法］
ここでは、ＴＭＣＣ拡張領域に格納される情報やデータの種別に応じて、ＴＭＣＣ拡張領域を分割することにより、受信処理が異なるデータをＴＭＣＣ拡張領域に格納することを実現する方法について説明する。

ＴＭＣＣ拡張領域に格納される情報やデータの種別（以下では拡張種別と呼ぶ）を、例えば下記のように分類する。

Ｔｙｐｅ Ａ：
・フレームに関する制御情報であり、フレーム毎に値が変化しない。

・最小更新間隔はフレーム単位である。値に変更がある場合は２フレーム先行して変更後の情報が送信される。

・また、変更がある場合は、８ｂｉｔの変更指示のインクリメントにより変更の通知が行われる。

Ｔｙｐｅ Ｂ：
・フレームに関する制御情報であり、フレーム毎に値が変化する。

・フレーム毎に値が変わる情報であり、変更指示は行われない。

Ｔｙｐｅ Ｃ：
・ペイロードとして使用される（従来の拡張方式）。

・ただし、変更指示には、拡張領域でないＴＭＣＣと同じ変更指示フィールドが用いられてもよいし、拡張領域で独自に変更指示フィールドが規定されてもよい。

図２３は、このように分類された拡張種別が用いられた拡張領域のデータ構造（ビット配置）の一例を示す図である。図２４は、拡張種別を使用する場合のシンタックスを示す図である。

図２３の例では、拡張種別として上記の３タイプのみが定義される。また、図２４の（ａ）に示されるように、３タイプの拡張種別のそれぞれにおけるデータ長が格納された後に続いて、拡張種別毎に、データ長に示された長さの拡張データが格納される。受信装置においては、拡張種別毎に、データ長に示された長さのデータを拡張領域から抽出し、処理を行う。

例えば、受信装置は、ＴｙｐｅＡのデータについては、変更指示があった場合のみデータを取得し、ＴｙｐｅＡのデータに変更があった場合には、制御情報が変更されたとして、制御情報に変更に従った処理をする。

また、受信装置は、ＴｙｐｅＢのデータについては、ＴｙｐｅＢのデータがフレーム毎に値が変化するデータであることから、毎フレーム取得する。例えば、フレーム毎に値が変化する基準クロック情報がＴＭＣＣ制御情報に格納される場合には、ＴｙｐｅＢのデータ領域に格納される。

ＴｙｐｅＣのデータには、従来の拡張方式のペイロード情報が含まれており、受信装置は、ＴｙｐｅＣのデータについては、従来の拡張方式の取得に従った動作をする。

上記の例では、それぞれの拡張種別毎のデータ構成の詳細は別途規定される必要がある。別途規定される場合、図２２の（ｂ）に示されるＴｙｐｅＣのデータにおける付加情報種別や対象サービス指定方法と同様の識別子が、他のタイプにおいて規定されてもよい。なお、付加情報種別は、共通のテーブルを用いて定義されてもよいし、拡張識別と付加情報種別とがマージされてもよい。

また、データ長が途中で変わる可能性がある情報は、ＴｙｐｅＡのデータと同様の種別とされてもよい。この場合、データ長の変更がある場合には、２フレーム先行して変更後の情報を送信することにより変更指示が行われてもよい。受信装置は、変更指示があった場合には、拡張種別のデータ長を参照し、データ長に変化がないかどうかを確認する。

なお、データ構造は、図２３のような構造に限定されるものではない。例えば、拡張種別のデータ長があらかじめ固定である場合には、データ長は送信されなくてもよい。具体的には、図２３において拡張種別がＴｙｐｅＡのデータ長が固定長である場合には、データ構造内に拡張種別ＴｙｐｅＡのデータ長が配置されなくてもよい。また、拡張種別ＴｙｐｅＡのデータ長及び拡張種別ＴｙｐｅＢのデータ長が固定長である場合には、すべてのタイプのデータ長が配置されなくてもよい。また、データ構造内には、拡張種別のデータがあるかないかを示すフラグが設けられてもよい。

また、拡張種別を使用する場合のシンタックスは、図２４の（ａ）に示されるシンタックスに限定されない。例えば、図２４の（ｂ）に示される例では、拡張領域数が設定され、拡張領域数毎に、拡張種別及び拡張領域長が格納される。続いて拡張領域数の拡張データが格納される。

このような構成は、将来の拡張種別の追加にも対応可能である。また、このような構成は、同じ拡張種別のデータを複数格納することが可能であるため、同じ拡張種別毎のデータの構成の詳細をあらかじめ決める必要がない。また、このような構成は、ペイロードとして（ＴｙｐｅＣとして）使用される場合でも、映像及び音声など、ページ数の異なるデータを同じフレームに複数記述できる。

なお、図２４の（ｂ）に示される構成において、拡張領域数、拡張種別、及び拡張領域長はＴｙｐｅＡと同様の種別とされてもよい。つまり、これらの情報は、変更指示に従う情報であると規定されてもよい。このように、変更指示に従うデータが連続して格納されることにより変更有無の判定が容易になる。

また、将来の拡張に備え、拡張種別に未定義領域が設けられてもよい。将来的に導入される拡張種別としては、例えば、次のような種別が想定される。

・数フレーム毎に更新される制御信号であり、変更指示は行われない。

・緊急用の信号の場合、ＴｙｐｅＡと同様に変更指示が行われるが、２フレーム先行した情報でなく、変更指示の取得後、当該フレームにおいて直ちに処理が行われる。

また、上記の緊急用の信号の場合、緊急用のフラグは、変更指示を伴う拡張種別を用いて送信され、緊急用のデータはペイロードを用いて送信されてもよい。また、拡張種別は、変更指示に従うか否かで分けられてもよい。

［詳細構成と動作フロー］
以上説明したような受信装置の機能構成と動作フローについて説明する。図２５は、実施の形態２に係る受信装置の機能構成を示すブロック図である。図２６は、実施の形態２に係る受信装置の動作フローを示す図である。なお、以下の説明では、拡張種別は、上述のようにＴｙｐｅＡ、ＴｙｐｅＢ、及びＴｙｐｅＣの３つのみであるとする。

図２５に示されるように受信装置４０は、拡張識別部４１と、拡張種別判定部４２と、変更指示確認部４３と、データ更新確認部４４と、更新データ取得部４５とを備える。

まず、拡張識別部４１は、ＴＭＣＣ制御情報の拡張識別を解析する（Ｓ１６１）。ここで拡張識別が、ａｌｌ ０以外であれば、拡張領域が有効であるとして、受信装置４０は、拡張領域毎に以下の処理を実行する。

次に、拡張種別判定部４２は、拡張種別の判別（判定）を行う（Ｓ１６２）。拡張種別がＴｙｐｅＡであると判別された場合（Ｓ１６２でＴｙｐｅＡ）、拡張領域長により特定される領域のデータは、フレーム毎に値が変化せず、変更指示に従う制御情報である。したがって、変更指示確認部４３は、フレーム毎に変更指示を確認する（Ｓ１６３）。

続いて、データ更新確認部４４は、データ更新の判定を行う（Ｓ１６４）。変更指示があり、かつ当該拡張データに変更があると判定された場合（Ｓ１６４でＹｅｓ）、更新データ取得部４５は、更新された拡張データを取得し、変更に伴う処理を実行する（Ｓ１６５）。

一方、ステップＳ１６４において上記のように判定されなかった場合（Ｓ１６４でＮｏ）、更新データ取得部４５は、当該拡張データに変更がないと判断する。

また、ステップＳ１６２において拡張種別がＴｙｐｅＢであると判別された場合（Ｓ１６２でＴｙｐｅＢ）、更新データ取得部４５は、拡張領域長により特定されるデータを参照し、フレーム毎に更新されるデータを取得し、変更に伴う処理を実行する（Ｓ１６７）。

ステップＳ１６２において拡張種別がＴｙｐｅＣであると判別された場合（Ｓ１６２でＴｙｐｅＣ）、更新データ取得部４５は、従来のペイロード拡張方式の受信方法に基づく処理を実行する（Ｓ１６６）。

なお、上述のように拡張領域数、拡張種別、及び拡張領域長が、変更指示に従うＴｙｐｅＡと同様の種別であると判別された場合には、更新データ取得部４５は、変更指示を確認し、変更指示がある場合には、情報が更新されているかどうかを確認する。

なお、受信装置４０は、拡張種別に基づいて受信処理を決定し、どの処理ブロックにおいてデータ処理をするかを決定してもよい。受信装置４０は、例えば、ＴｙｐｅＡのデータ及びＴｙｐｅＢのデータは、ハードウェアで処理し、ＴｙｐｅＣのデータはソフトウェアで処理することを決定してもよい。

［効果等］
以上説明したように、実施の形態２では、高度ＢＳ伝送方式におけるＴＭＣＣ拡張領域を拡張種別毎に分割し、拡張データをＴＭＣＣ拡張領域に格納する方法について説明した。このような方法においては、受信装置４０は、拡張種別に基づいて拡張データの処理方法を決定する。

これにより、受信処理が異なる複数のデータを同時にＴＭＣＣ拡張領域に格納することが可能となる。つまり、ＴＭＣＣ拡張領域の使用方法に拡張性を持たすことが可能となる。

具体的には、例えば、ペイロード及び基準クロック情報を同時に拡張領域に格納することが可能となる。

また、数フレームにまたがるペイロードデータと、１フレームのみのペイロードデータとをＴＭＣＣ拡張領域に混在させることも可能となる。したがって、受信装置４０は、数フレームにまたがるペイロードデータが受信できない間でも、１フレームのみのペイロードデータを先に取得できる。よって、受信装置４０は、緊急性の高い情報をより早く取得及び提示することが可能となる。

（実施の形態３）
実施の形態３では、各々が異なるレイヤに属する複数の基準クロック情報を送信する方法について説明する。

［概要］
図２７は、複数レイヤのそれぞれに基準クロック情報が格納される例を模式的に示す図である。

図２７の例では、第１のレイヤは第２のレイヤに対して上位のレイヤであり、第１のレイヤには、第１の基準クロック情報が格納される。第２のレイヤには、第２の基準クロック情報が格納される。

送信装置は、基本的に第１のレイヤのＭＵＸ処理の後に第２のレイヤのＭＵＸ処理をする。また、受信装置は、基本的に第２のレイヤのＤＥＭＵＸ処理の後に第１のレイヤのＤＥＭＵＸ処理をする。

第１の基準クロック情報を第１のレイヤに格納し、第２の基準クロック情報を第２のレイヤに格納する場合、送信装置は、第１の基準クロック情報と、第２の基準クロック情報との関係性を示す情報として、例えば下記に示す情報を格納することができる。

第１の例として、送信装置は、送信信号（例えば、伝送フレーム）内に複数の基準クロック情報が格納されていることを示す情報を送信信号に含めることができる。

具体的には、送信装置は、基準クロック情報が含まれるレイヤのうち、少なくとも１つ以上のレイヤにおいて、当該レイヤ以外のレイヤにも基準クロック情報が格納されていることを示す情報を格納する。

また、送信装置は、基準クロック情報が含まれないレイヤにおいて、複数の基準クロック情報が格納されていることを示してもよい。例えば、送信装置は、下位レイヤ（第２のレイヤ）において上位レイヤ（第１のレイヤ）に基準クロック情報を含むかどうかを示す情報を格納してもよい。この場合、受信装置は、下位レイヤの処理において上位レイヤに基準クロック情報を含むかどうかを考慮して、下位レイヤの基準クロック情報の取得及び基準クロックの再生を行うかどうかを判定できる。

第２の例として、送信装置は、第１の基準クロック情報及び第２の基準クロック情報に関する情報を送信信号に含めることができる。

具体的には、送信装置は、それぞれのレイヤに、当該レイヤに含まれる基準クロック情報の種類を示す情報を格納する。あるいは、送信装置は、それぞれのレイヤに、当該レイヤ以外のレイヤに含まれる基準クロック情報の種類を示す情報を格納する。

基準クロック情報には、例えば、３２ｂｉｔのＮＴＰ、６４ｂｉｔのＮＴＰ、２４ｂｉｔのＳＭＰＴＥタイムコードなどの種類があり、基準クロック情報の種類を示す情報は、基準クロック情報のフォーマット（精度等の情報を含む）を特定できる情報である。

なお、あらかじめ所定の種類の基準クロック情報が含まれていることが既知である場合は、このような情報は含まれなくてよい。

第３の例として、送信装置は、第１の基準クロック情報と第２のクロック情報の相対関係を示す情報を送信信号に含めることができる。

具体的には、送信装置は、基準クロック情報の精度の相対関係を示す情報を含めることができる。例えば、送信装置は、第１の基準クロック情報の精度に対して第２の基準クロック情報の精度が高いまたは低いことを示す情報を含める。

また、このような相対関係を示す情報は、基準クロック情報の総ビット数の大小に基づく相対関係を示す情報であってもよいし、整数部のビット数の大小に基づいてダイナミックレンジの相対関係を示す情報であってもよい。

あるいは、相対関係を示す情報は、小数部のビット数の大小に基づいて分解能（解像度）の精度の相対関係を示す情報であってもよい。また、相対関係を示す情報は、送信装置における基準クロック情報のそもそもの信頼性や、伝送路の品質、送信処理や受信処理における処理能力の違いに起因する精度の違いに基づいて、基準クロック情報の取得時における精度の相対関係を示す情報であってもよい。

また、相対関係を示す情報は、基準クロック情報間の精度の差を示す情報であってもよい。例えば、小数ビット数に差がある場合、小数ビット数の差を示す情報であってもよい。相対関係を示す情報は、互いの精度が同じであるかを示す情報を示す情報であってもよいし、精度が異なる場合のみ相対関係を示す情報として格納されてもよい。なお、あらかじめ精度の相対関係が既知である場合は、このような精度の相対関係を示す情報は含まれなくてもよい。

このような、精度の相対関係を示す情報が送信されれば、受信装置は、送信された情報が第１の基準クロック情報の精度に対して第２の基準クロック情報の精度が低いことを示す場合、第２の基準クロック情報の取得及び再生を実施せず、第１の基準クロック情報の取得及び再生を実施し、第１の基準クロック情報に基づいて同期再生を行う、といった制御ができる。あるいは、受信装置は、送信された情報が第１の基準クロック情報の精度に対して第２の基準クロック情報の精度が高いことを示す場合、第１の基準クロック情報の取得及び再生を実施せず、第２の基準クロック情報の取得及び再生を実施し、第２の基準クロック情報に基づいて同期再生を行う、といった制御ができる。

第４の例として、送信装置は、基準クロック情報間の時間の相対関係を示す情報を送信信号に含めることができる。具体的には、送信装置は、第１の基準クロック情報と第２の基準クロック情報の相対時刻を示す情報を送信する。例えば、送信装置は、ＭＭＴ方式におけるＣＲＩ＿ｄｅｓｃｒｉｐｔｏｒを用いて送信する。なお、第１の基準クロック情報と第２の基準クロック情報とが同じ基準クロックに基づいて生成されたものであるかどうかを示す情報が含まれてもよい。

それぞれの基準クロック情報が、同じ基準クロックに基づいて生成される場合、受信装置においては、通常、第１の基準クロック情報と第２の基準クロック情報の取得のタイミングに差がある。つまり、それぞれの基準クロック情報のＥｎｄ−ｔｏ−Ｅｎｄ遅延に固定の時間差が生じる。

このため、送信装置は、第１の基準クロック情報の付与タイミングと第２の基準クロック情報の付与タイミングとの時間差Δ＿Ａを算出し、算出した時間差Δ＿Ａを、第１の基準クロック情報と第２の基準クロック情報の取得のタイミングに相当する時間として送信信号に格納する。受信装置は、時間差Δ＿Ａを送信信号から取得し、時間差Δ＿Ａに基づいて第１の基準クロック情報と第２の基準クロック情報とのＥｎｄ−ｔｏ−Ｅｎｄ遅延差を補正する。

また、それぞれの基準クロック情報が同じフォーマットの基準クロックに基づいて生成されており、それぞれの基準クロック情報に固定の遅延差Δ＿Ｂがある場合、送信装置は、基準クロック情報の固定の遅延差Δ＿Ｂを示す情報を格納し、送信する。受信装置は、遅延差Δ＿Ｂを取得し、遅延差Δ＿Ｂに基づいて基準クロックの固定遅延差を補正する。

また、それぞれの基準クロック情報の基になる基準クロックに固定遅延Δ＿Ｂがある場合、送信装置は、下位のレイヤである第２のレイヤに固定遅延Δ＿Ｂを含めて送信する。

また、それぞれの基準クロック情報、同じフォーマットの基準クロックに基づいて生成されている場合、第２の基準クロック情報は、第１の基準クロック情報をベースとして、第１のクロック情報に対する差分で表されてもよい。この場合。第２の基準クロック情報がベースとされてもよい。

第５の例として、送信装置は、複数の基準クロック情報が格納されている場合、異なるレイヤに格納されている基準クロック情報を用いるかどうかの情報を送信信号に含めることができる。送信装置は、例えば、第２のレイヤに格納された第２の基準クロック情報を第１のレイヤにおいて使用することを指示する情報を送信信号に含める。この場合、受信装置は、当該情報に基づいて、第２の基準クロック情報を生成し第１のレイヤに出力することを決定することができる。

以上説明したような情報は、少なくとも１つ以上のレイヤに格納される。例えば、このような情報は、第１のレイヤのみに上記情報が格納されてもよいし、第２のレイヤのみに格納されてもよい。また、このような情報は、両方のレイヤに格納されてもよい。あるいは、それぞれのレイヤにおいて、当該レイヤにおける基準クロック情報に関する情報が格納され、相対関係を示す情報のみが少なくとも１つ以上のレイヤに格納されてもよい。

なお、相対関係を示す情報は、下位のレイヤ（第２のレイヤ）に格納されることが望ましい。あるいは、第２のレイヤよりも下位のレイヤ（図２７で図示せず）に格納されてもよい。受信装置では、下位のレイヤ（第２のレイヤ）のＤＥＭＵＸ処理の際に、上位のレイヤ（第１のレイヤ）の基準クロック情報に関する情報を取得できることにより、より高速な処理が可能となる。

なお、第１のレイヤと第２のレイヤとの組み合わせは、どのような組み合わせであってもよい。例えば、第１のレイヤと第２のレイヤとの組み合わせは、ＭＭＴレイヤとＩＰレイヤ、ＭＭＴレイヤと伝送レイヤ、ＩＰレイヤと伝送レイヤ、のそれぞれの組み合わせであってもよい。また、第１のレイヤと第２のレイヤとの組み合わせは、ＭＭＴｏｖｅｒＴＳの場合は、ＭＭＴとＴＳとの組み合わせでもよい。

また、上記のような情報は、各レイヤの制御信号に格納される。例えば、ＭＭＴ方式では、ディスクリプタやテーブル、メッセージ、パケットヘッダ情報に格納され、ＭＰＥＧ２−ＴＳ方式では、ディスクリプタやテーブル、セクション、ヘッダ情報に格納される。また、伝送レイヤにおけるＴＭＣＣやスロットヘッダに格納されてもよい。伝送方式がＤＶＢである場合は、ＴＰＳ、Ｌ１データ、Ｌ２データ、Ｐ１データ、Ｐ２データなどに格納される。

なお、第１の基準クロック情報と第２の基準クロック情報とは、同じ種類の基準クロック情報であってもよいし、異なる種類の基準クロック情報であってもよい。また、第１の基準クロック情報と第２の基準クロック情報とは、精度の異なる基準クロック情報であってもよい。第１の基準クロック情報と第２の基準クロック情報とは、同じ基準クロックに基づいた基準クロック情報であってもよいし、それぞれ異なる基準クロックに基づいた基準クロック情報であってもよい。

また、送信装置は、３以上の基準クロック情報を送信してもよいし、３以上のレイヤにそれぞれ基準クロック情報を格納して送信してもよい。また、同じレイヤ内のデータ構造の中で異なるフィールドのそれぞれに基準クロック情報が格納されてもよい。第１のレイヤと第２のレイヤとの間には、他のレイヤが存在していてもよい。

基準クロック情報は、例えば、ＮＴＰ、タイムコード、及び、ＰＴＰであるが、これ以外の基準クロック情報であってもよい。また、基準クロック情報は、他の時刻に関する情報（例えば、ＴＯＴ（Ｔｉｍｅ Ｏｆｆｓｅｔ Ｔａｂｌｅ）及びＴＤＴ（Ｔｉｍｅ Ｄａｔｅ Ｔａｂｌｅ））でもよい。

図２８は、一つのレイヤに複数の基準クロック情報が格納される例を模式的に示す図である。図２８の例では、第１のレイヤには、第１の基準クロック情報、第２の基準クロック情報、及び第３の基準クロック情報の３つの基準クロック情報が含まれる。

この場合も、送信装置は、第１の基準クロック情報及び第２の基準クロック情報に関する情報や、それぞれの（精度や時刻の）相対関係を示す情報などを格納することができる。

一例として、ＴＭＣＣに複数の基準クロック情報を格納する場合の例について説明する。図１７で説明したように、高度ＢＳ伝送方式では１６本のストリームを送信することができ、例えば、異なる放送局のデータがストリームに分けて格納されることが想定される。図２９は、異なる放送局のデータがストリームに分けて格納される例を説明するためのブロック図である。

図２９に示されるように、第１の放送局５１、第２の放送局５２、及び第３の放送局５３は、それぞれの放送局において生成したデータを、それぞれ光回線などの有線や無線を用いて衛星の送信局５４に送信する。衛星の送信局５４は、それぞれの放送局のストリームを同一の高度ＢＳ伝送方式の伝送チャネルに多重する。衛星の送信局５４は、それぞれの放送局のストリームに対応する基準クロック情報をＴＭＣＣに格納し、受信装置５０に伝送する。

この場合、図２８の例では、第１の基準のクロック情報が第１の放送局５１の基準クロック情報、第２の基準クロック情報が第２の放送局５２の基準クロック情報、第３の基準クロック情報は第３の放送局５３にそれぞれ相当する。

ところで、それぞれの放送局が、ＮＴＰなどの共通の基準クロック情報に基づいて処理を行っている場合において、衛星の送信局５４におけるそれぞれの基準クロック情報は、衛星の送信局に到着するまでの受信処理遅延や伝送遅延によるＥｎｄ−ｔｏ−Ｅｎｄ遅延の違いにより時間差を有する。

ここで、それぞれの放送局において用いられる共通の基準クロック情報をＮＴＰ＿ｂａｓｅとすると、衛星の送信局における第１の基準クロック情報はＮＴＰ＿ｂａｓｅ＋Δ１、第２の基準クロック情報はＮＴＰ＿ｂａｓｅ＋Δ２、第３の基準クロック情報はＮＴＰ＿ｂａｓｅ＋Δ３と表される。

この場合、図３０に示されるように、送信装置は、共通となる基準クロック情報ＮＴＰ＿ｂａｓｅを送信し、かつ、それぞれの基準クロック情報と共通の基準クロック情報との差分情報（Δ１、Δ２、Δ３）を送信してもよい。図３０は、差分情報の送信方法を説明するための図である。また、例えば、６４ｂｉｔの基準クロック情報のうち、ベースの基準クロック情報は上位１６ｂｉｔによって表現し、差分情報は残りの４８ｂｉｔによって表現することにより、基準クロック情報の伝送時の情報量（サイズ）を削減することができる。

なお、ベースとなる基準クロック情報は、ＮＴＰ＿ｂａｓｅでなくてもよく、複数の基準クロック情報の中で、最も早い（遅延の少ない）基準クロック情報であってもよい。あるいは、ベースとなる基準クロック情報（基準値）は、最も早い基準クロック情報の値よりも小さな値であればよい。

また、図３１に示されるように、ベースの基準クロック情報は、毎フレーム送信され、差分情報は、３フレーム毎に順番に送信されるなど、ベースの基準クロック情報と差分情報とは異なる頻度で送信されてもよい。図３１は、差分情報の送信方法の変形例を説明するための図である。図３１に示されるような送信方法により、基準クロック情報の伝送時の情報量（サイズ）を削減することができる。

受信装置５０は、ベースの基準クロック情報を用いてベースの基準クロックを再生する。ベースの基準クロック情報の再生後に、差分情報を用いて、それぞれの基準クロックを生成してもよい。

［詳細構成と動作フロー］
ここで、受信装置５０の機能構成と動作フローについて説明する。図３２は、受信装置５０の機能構成を示すブロック図である。図３３は、受信装置５０の動作フローを示す図である。なお、以下では、ＩＰレイヤ、及び伝送レイヤのいずれか一方にのみ基準クロック情報が格納されており、いずれかの基準クロック情報に基づいて受信装置５０が基準クロックを再生する例について説明される。

受信装置５０は、受信部１０と、復号部１１と、ＴＬＶデマルチプレクサ１２と、ＩＰデマルチプレクサ１３と、ＭＭＴデマルチプレクサ１４と、同期部１７と、復号提示部１８とを備える。また、受信装置５０は、第１基準クロック情報抽出部１５ａと、第２基準クロック情報抽出部１５ｂと、第１基準クロック生成部１６ａと、第２基準クロック生成部１６ｂとを備える。

伝送レイヤの制御情報（スロットヘッダ及びＴＭＣＣなど。ここではＴＭＣＣ。）には、ＩＰレイヤに基準クロック情報があるかどうかを示すフラグが格納される。また、伝送レイヤの制御情報には、ＩＰレイヤに基準クロック情報がない場合に基準クロック情報が格納される。

また、伝送レイヤの制御情報には、ＩＰレイヤに基準クロック情報がない場合に、伝送レイヤにおいて取得された基準クロック情報が上位レイヤの処理に必要かどうかを示すフラグ、または、再生された基準クロック情報が上位レイヤの処理に必要がどうかを示すフラグが格納される。

例えば、基準クロック情報が６４ビットのＮＴＰである場合、基準クロック情報を示す６４ビットのフィールドにＮＴＰが格納される。また、ＩＰレイヤに基準クロック情報があるかどうかを示すフラグが基準クロック情報のフィールドに設けられてもよい。ＩＰレイヤに基準クロック情報が格納されている場合は、伝送レイヤには基準クロック情報が格納される必要がないため、当該フィールドを活用できる。

例えば、ＩＰレイヤに基準クロック情報がある場合には基準クロック情報のフィールドに所定の値（例えば、ＡＬＬ１）がある場合、受信装置５０は、当該値は基準クロック情報でなく、ＩＰレイヤに基準クロック情報があることを示すフラグであると判定する。あるいは受信装置５０は、基準クロック情報のフィールドにＡＬＬ１が１回だけ示された場合には基準クロック情報があると判定し、ＡＬＬ１が所定の回数以上連続して示された場合にはＩＰレイヤに基準クロック情報があると判定するなど、所定の規則に基づいた値がフラグとして用いられてもよい。

受信装置５０の復号部１１は、伝送レイヤにおいて制御情報であるＴＭＣＣを解析し、各種フラグや、基準クロック情報を解析する（Ｓ１７１）。そして、復号部１１は、上記フラグに基づく判定を行う（Ｓ１７２）。ＩＰレイヤに基準クロック情報がない（伝送レイヤに基準クロック情報がある）と判定された場合（Ｓ１７２でＮｏ）、第２基準クロック情報抽出部１５ｂは、伝送レイヤにおいて基準クロック情報を取得（抽出）し、第２基準クロック生成部１６ｂは、基準クロックを再生（生成）する。

次に、復号部１１は、伝送レイヤにおいて再生された基準クロックが上位レイヤの処理に必要かどうかの判定を行う（Ｓ１７４）。伝送レイヤにおいて再生された基準クロックが上位レイヤの処理に必要であると判定された場合（Ｓ１７４でＹｅｓ）、第２基準クロック生成部１６ｂは、ステップＳ１７４において再生した基準クロックを上位レイヤに出力する（Ｓ１７５）。伝送レイヤにおいて再生された基準クロックが上位レイヤの処理に必要であると判定されなかった場合（Ｓ１７４でＮｏ）、処理は終了される。

一方、ＩＰレイヤに基準クロック情報がある（伝送レイヤに基準クロック情報がない）と判定された場合（Ｓ１７２でＹｅｓ）、伝送レイヤでは基準クロック情報の取得及び基準クロックの再生は実施されない。この場合、第１基準クロック情報抽出部１５ａ、及び、第１基準クロック生成部１６ａによって、ＩＰレイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される（Ｓ１７６）。

なお、伝送レイヤにおいて基準クロックの再生が必要でない場合、及び、上位レイヤが基準クロックを必要としていない場合、伝送レイヤにおける基準クロック情報の取得及び基準クロックの再生（Ｓ１７３）は行われなくてもよい。

また、上位レイヤにおいて基準クロックが必要な場合、再生した基準クロックを出力するのではなく、基準クロック情報を上位レイヤに渡し、上位レイヤにおいて基準クロックの再生が行われてもよい。また、伝送レイヤにおいて再生された基準クロックに基づいて、新規に基準クロック情報が生成され、生成された基準クロック情報が上位レイヤに出力されてもよい。

上位レイヤに基準クロックを出力する方法としては、再生された基準クロックをそのまま出力する方法や、取得した基準クロック情報あるいは新規に生成した基準クロック情報を、上位レイヤへ出力するデータ構造に格納あるいは変換して出力する方法などがある。

［動作フローの別の例］
次に、受信装置５０の別の動作フローについて説明する。図３４は、受信装置５０の別の動作フローを示す図である。なお、受信装置５０の構成は、図３２と同様の構成である。

図３４の例では、ＩＰレイヤ、及び伝送レイヤのそれぞれに基準クロック情報が格納でき、複数の基準クロック情報が格納されている場合には、その基準クロック情報の精度の相対情報が格納されているものとする。

復号部１１は、ＴＭＣＣを解析し（Ｓ１８１）、フラグに基づく判定を行う（Ｓ１８２）。ＩＰレイヤに基準クロック情報がないと判定された場合（Ｓ１８２でＮｏ）、伝送レイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される（Ｓ１８５）。

一方、ステップＳ１８２においてＩＰレイヤに基準クロック情報があると判定された場合（Ｓ１８２でＹｅｓ）、復号部１１は、伝送レイヤの基準クロック情報とＩＰレイヤの基準クロック情報とのどちらの精度が高いかを判定する（Ｓ１８３）。伝送レイヤの基準クロック情報よりもＩＰレイヤの基準クロック情報のほうが精度が高いと判定された場合（Ｓ１８３でＹｅｓ）、ＩＰレイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される（Ｓ１８４）。伝送レイヤの基準クロック情報よりもＩＰレイヤの基準クロック情報のほうが精度が低いと判定された場合（Ｓ１８３でＮｏ）、伝送レイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される（Ｓ１８５）。

［効果等］
以上説明したように、１つ以上のレイヤで複数の基準クロック情報が送信されてもよい。複数の基準クロック情報が送信されている場合、受信装置５０は、どちらか一方の基準クロック情報を選択して基準クロック（システムクロック）の生成に用いてもよいし、両方を用いて基準クロックを生成してもよい。このとき、受信装置５０は、精度の高い基準クロック情報を選択してもよいし、より早く取得できる基準クロック情報を選択してもよい。

また、複数のレイヤで基準クロック情報が送信されている場合、送信側では、複数のレイヤで基準クロック情報が送信されていることを示す情報が格納されてもよい。また、複数のレイヤで基準クロック情報が送信されていることを示す情報、または、基準クロック情報が送信されているレイヤやプロトコルに係る情報が、下位のレイヤにおいて送信されてもよい。さらに、異なるレイヤに格納された基準クロック情報間の関係性を示す情報が送信されてもよい。

これにより、受信装置５０は、下位のレイヤのＤＥＭＵＸ処理時に、上位のレイヤに基準クロック情報が含まれていることを判定することができ、判定に基づいてどの基準クロック情報を用いるかを決定することができる。どの基準クロック情報を用いるかの決定は、受信装置５０がどのレイヤの基準クロック再生に対応しているかどうかに基づいて決定されてもよいし、推奨される基準クロック再生が放送局によって指定されてもよい。

複数のレイヤで基準クロック情報が送信されている場合、受信装置５０は、下位のレイヤにおいて基準クロック情報を抽出すると同時に、下位のレイヤから上位のレイヤに含まれる基準クロック情報を抽出してもよい。そして、受信装置５０は、抽出した少なくとも１つ以上の基準クロック情報を用いて基準クロックを生成してもよい。

なお、複数の伝送路を通じて複数の基準クロック情報が送信されてもよい。この場合、複数の基準クロック情報が複数の伝送路を通じて送信されていることや、基準クロック情報が伝送されている伝送路に係る情報が送信されてもよい。

（その他の実施の形態）
以上、実施の形態について説明したが、本発明は、上記実施の形態に限定されるものではない。

例えば、従来のＭＭＴパケットヘッダに含まれる３２ｂｉｔショートフォーマットＮＴＰに加えて、より高精度な基準クロック情報を送信することが想定される。このような場合、送信側からは、受信装置が高精度な基準クロック情報を用いて３２ｂｉｔショートフォーマットＮＴＰを再生するための情報がさらに送信される。このような情報は、例えば、互いのクロックの相対関係を示す時刻情報であり、ＣＲＩ＿ｄｅｓｃｒｉｐｔｏｒ（）等を用いて送信される構成などが考えられる。

なお、受信装置において３２ｂｉｔショートフォーマットＮＴＰが再生できる場合には、従来のＭＭＴパケットヘッダに含まれるＮＴＰフィールドは不要である。このため、ＮＴＰフィールドには別の情報が格納されてもよいし、ＮＴＰフィールドを削減することによりヘッダ圧縮が行われてもよい。ヘッダ圧縮がされる場合には、ＮＴＰフィールドを削減したことを示す情報が送信される。受信装置は、ＮＴＰフィールドが削減されている場合には、他の基準クロック情報を用いて基準クロックを生成するとともに、３２ｂｉｔショートフォーマットＮＴＰを再生する。

また、ＭＭＴパケットが通信伝送路を用いて伝送される場合、受信装置は、ＱｏＳ制御のために３２ｂｉｔショートフォーマットＮＴＰを使用し、基準クロック情報は使用しない可能性がある。そのため、通信伝送路では基準クロック情報が送信されなくてもよい。また、通信伝送路のＥｎｄ−ｔｏ−Ｅｎｄ遅延が一定以内である場合は、基準クロック情報をクロック再生に用いてもよい。

なお、上記実施の形態１では、ＭＭＴ／ＩＰ／ＴＬＶ方式を用いる場合を例に説明したが、多重化方式として、ＭＭＴ方式以外の方式が用いられてもよい。例えば、ＭＰＥＧ２−ＴＳ方式、ＲＴＰ方式、またはＭＰＥＧ−ＤＡＳＨ方式にも本発明を適用することができる。

また、ＩＰパケットのヘッダ圧縮の方法としては、ＲｏＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）、及びＨＣｆＢ（Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ ｆｏｒ Ｂｒｏａｄｃａｓｔｉｎｇ）がある。

ＩＰパケットを放送に格納する方式としては、ＴＬＶ方式以外にも、ＧＳＥ（Ｇｅｎｅｒｉｃ Ｓｔｒｅａｍ Ｅｎｃａｐｓｕｌａｔｉｏｎ）方式、及びＵＬＥ（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｌｉｇｈｔ−ｗｅｉｇｈｔ． Ｅｎｃａｐｓｕｌａｔｉｏｎ）を用いたＩＰｏｖｅｒＴＳ方式などがある。

以上のようないずれの方式を用いる場合にも本発明は適用可能であり、本発明の適用により、受信装置における基準クロック情報を取得までの時間の短縮や処理の軽減、ハードウェア化実装によるクロックの高精度化などを実現することができる。

なお、上記実施の形態における基準クロック情報は、多重化方式がＭＭＴである場合は、ＮＴＰであるが、例えば、多重化方式がＭＰＥＧ２−ＴＳ方式である場合には、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）である。また、多重化方式がＭＭＴである場合においても、ＩＥＥＥ１５８８で規定されるＰＴＰをＮＴＰ形式で伝送することもある。ＮＴＰの一部のビットのみが伝送されることもある。つまり、基準クロック情報は、送信側が設定する時刻を示す情報であればよい。なお、ＮＴＰは、必ずしもインターネットで一般的に使用される、ＮＴＰサーバにおけるＮＴＰ値を意味するわけではない。

また、本発明は、上記のような方法で基準クロック情報を格納した伝送スロットを送信する送信装置（送信方法）として実現されてもよい。以下、このような送信装置の構成について補足する。図３５は、送信装置の機能構成を示すブロック図である。図３６は、送信装置の動作フローである。

図３５に示されるように、送信装置３０は、生成部３１と、送信部３２とを備える。なお、送信装置３０の構成要素は、具体的には、マイクロコンピュータ、プロセッサ、または専用回路などによって実現される。

送信装置３０は、具体的には、放送サーバであり、上記実施の形態１の「送信側」の一例である。

生成部３１は、例えば、ＩＰパケットが格納されたＴＬＶパケットが１以上格納されたスロットを複数格納した伝送スロットを生成する（図３６のＳ１５１）。

このとき、生成部３１は、伝送スロット内の先頭のスロット内で先頭に位置するＴＬＶパケット格納されたＩＰパケット（以下、対象ＩＰパケットとも記載する）に、コンテンツ（例えば、映像または音声などの放送コンテンツ）の再生のための時刻を示すＮＴＰなどの第１の基準クロック情報を含める。このとき、対象ＩＰパケットは、ヘッダ圧縮されていないＩＰパケットであり、第１の基準クロック情報は、例えば、対象ＩＰパケット内でＭＭＴパケットと異なるデータ構造で格納される。

また、生成部３１は、伝送スロット内の制御情報（ＴＭＣＣ）にコンテンツの再生のための時刻を示す第２の基準クロック情報を格納する。

生成部３１は、具体的には、放送コンテンツを符号化する符号化部、ＭＭＴマルチプレクサ、ＩＰマルチプレクサ、及び、ＴＬＶマルチプレクサなどからなる。なお、ＴＬＶパケットは、第１の伝送単位の一例であり、スロットは、第２の伝送単位の一例であり、伝送スロットは、伝送用のフレームの一例である。

送信部３２は、生成部３１によって生成された伝送スロット（伝送スロットを含む伝送路符号化データ）を、放送を通じて送信する（図３６のＳ１５２）。

上記実施の形態でも説明したように、このような送信装置３０によれば、受信装置が基準クロック情報を取得する処理を簡素化できる。したがって、受信装置が基準クロック情報を取得するまでの時間を短縮することができる。

また、フレーム内の制御情報にコンテンツの再生のための時刻を示す第２の基準クロック情報が格納されることにより、受信装置は、第１の基準クロック情報及び第２の基準クロック情報のいずれの基準クロック情報を使用するかを選択できる。

（実施の形態４）
本実施の形態では、受信装置において、上位レイヤに基準クロック情報を渡す方法及びそのインターフェースについて説明する。

図３７は、本実施の形態に係る受信装置６０の構成を示すブロック図である。この受信装置６０は、下位レイヤの処理を行う復号装置６１と、上位レイヤの処理を行う逆多重化装置６２とを含む。例えば、復号装置６１と逆多重化装置６２とは異なるＬＳＩとして形成される。なお、復号装置６１と逆多重化装置６２とは単一のＬＳＩとして形成されてもよい。

復号装置６１は、受信部１０と復号部１１とを備える。受信部１０は、伝送路符号化データを受信する。復号部１１は、受信部１０によって受信された伝送路符号化データを復号することでＴＬＶパケットを抽出し、当該ＴＬＶパケットを逆多重化装置６２に出力する。

逆多重化装置６２は、取得部６３と逆多重化部６４とを備える。取得部６３は、復号装置６１から主力されたＴＬＶパケットを取得する。逆多重化部６４は、ＴＬＶパケットを逆多重化する。例えば、逆多重化部６４は、図３２に示す処理部のうち受信部１０及び復号部１１以外の処理部を含む。なお、逆多重化部６４は、他の実施の形態で説明した受信装置に含まれる処理部のうち受信部１０及び復号部１１以外の処理部を含んでもよい。また、逆多重化部６４は、これらの処理部の全てを含む必要はなく一部のみを含んでもよい。また、逆多重化装置６２は、復号装置６１の出力を制御する。

図３２及び図３３で説明したように、下位レイヤの復号装置６１は、下位レイヤに基準クロック情報が含まれる場合に、再生した基準クロックを上位レイヤの逆多重化装置６２に出力せずに、基準クロック情報を逆多重化装置６２に渡し、逆多重化装置６２において基準クロックを再生する方法について捕捉し、詳細を説明する。

以下では、非特許文献２（ＡＲＩＢ標準規格 ＡＲＩＢ ＳＴＤ−Ｂ４４ （２．０版）、「高度広帯域衛星デジタル放送の伝送方式」における第３章「時刻情報の伝送に関するガイドライン」）に記載される方法、及びデータ構造に基づいた基準クロックの送受信について説明する。

上記規格では、基準クロック情報をＴＭＣＣに格納する方法が示されているものの、具体的に送信される時刻情報、および受信装置における動作が規定されておらず、受信装置において正確な時刻情報を得ることができない。例えば、上記規格では「ＴＭＣＣに格納する基準クロック情報は、本ＴＭＣＣ信号が送信サーバを出発する時刻」としているが、具体的な定義ではない。

ＴＭＣＣ制御情報（ＴＭＣＣ制御信号）は、送信装置において、伝送フレーム毎に、本線系の主信号とは別系統で生成され、誤り訂正符号化及びインターリーブ処理が行われた後に、１フレーム分の主信号（主信号も誤り訂正符号化及びインターリーブ処理を行った後の信号である。）の中に分散的にマッピングされる。

図３８は、主信号及び基準クロック情報のタイミングを示す図である。

ＴＭＣＣ制御情報に基準クロック情報が格納される場合は、基準クロック情報（図３８ではＮＰＴｎ，ＮＰＴｎ＋１，…）は、伝送フレーム時間長の間隔（Ｔ_Ｆ）で生成される。基準クロック情報は、生成された後、伝送フレームの単位で送出される。このとき、基準クロック情報の生成から伝送フレームの送出までには、誤り訂正符号化、インターリーブ処理、及び伝送フレーム送出タイミングなどによる処理遅延が発生する。図３８では、ＮＴＰｎは伝送フレームＭ＋１に格納されて伝送され、ＮＴＰｎ＋１は伝送フレームＭ＋２に格納されて伝送される。なお、ここでは、伝送遅延は０として、伝送フレームの送出時刻及び受信時刻は同一であるとして説明する。

受信装置は、１伝送フレーム分のデータを受信し、誤り訂正処理及びデインターリーブ処理後にＴＭＣＣ制御情報を抽出する。そのため基準クロック情報の受信タイミングは、１フレーム以上遅延する。

同様に、本線系の主信号に対しても、誤り訂正及びインターリーブ処理により送受信において処理遅延が発生する。

しかしながら、本線系と、ＴＭＣＣ制御情報の系とでは、送受信それぞれにおいて、遅延時間が異なるため、受信装置において取得した基準クロック情報の時刻が、本線系の時刻に対してどの時刻であるかが不明確であるという課題がある。また、受信装置において取得した基準クロック情報を上位レイヤに格納するタイミングの規定がないという課題がある。

そこで、本実施の形態では、下記方法に従い、ＴＭＣＣ制御情報に基準クロック情報を格納する。

送信装置は、ＴＭＣＣ制御情報に格納する基準クロック情報を、例えば、主信号の伝送フレームがサーバを送出する時刻（例えば、伝送フレームの先頭のパケットがサーバを送出する時刻）に設定する。

受信装置は、ＴＭＣＣ制御情報から抽出した基準クロック情報を、次の伝送フレームの先頭位置に格納して上位レイヤに伝送する。

上記の動作により、本線系と、ＴＭＣＣ制御情報の系との処理遅延の違いによる、相対的な関係は、伝送フレームの整数倍（Ｎ×Ｔ_Ｆ）（Ｎは整数）となる。

さらに、本線系とＴＭＣＣ制御情報から抽出した基準クロック情報との時間関係を一致させるために、Ｎ×Ｔ_Ｆの補正がされる。

予めＮを一意に決定できる場合は、送信装置がＮ×ＴＦの補正をした時刻をＴＭＣＣ制御情報に格納してもよいし、受信装置が時刻を補正してもよい。Ｎが一意に決定できない場合には、受信装置がＮを推定し、時刻を補正する。

また、基準クロック情報が、ＴＭＣＣ制御情報に加え、主信号（ＴＬＶパケット）で伝送されている場合には、送信装置は、ＴＭＣＣ制御情報に、ＴＬＶパケットに格納される時刻と同一の時刻を格納する。或いは、送信装置は、ＴＬＶパケットに格納される時刻に対して、Ｎ×Ｔ_Ｆに応じた補正を行った時刻をＴＭＣＣ制御情報に格納する。

受信装置では、ＴＭＣＣ制御情報より抽出した時刻情報にＮ×Ｔ_Ｆの補正を加えることにより、主信号に格納される時刻と同一の時刻を算出し、算出した時刻を上位レイヤに出力する。

なお、基準クロック情報をＴＭＣＣ制御情報より抽出し、補正後の基準クロック情報を上位レイヤに伝送する方法として、受信装置は、ＴＬＶパケット内の基準クロック情報を置き換えて出力してもよい。

また、ＴＭＣＣ制御情報とＴＬＶパケットとに格納される基準クロック情報において基準となる時刻は同一であるため、上位レイヤではこれらの基準クロック情報を同じ情報として扱うことが可能である。

また、受信装置６０は、ＴＭＣＣ制御情報とＴＬＶパケットとに格納される基準クロック情報のどちらか一方のみを主信号（ＴＬＶパケット）として出力する方法と、両方を出力する方法となどを、選択スイッチ等により切り替えてもよい。また、下位レイヤにおけるこの切り替えは、上位レイヤの逆多重化装置６２が選択してもよい。また、復号装置６１と逆多重化装置６２とが物理的に異なる場合は、レジスタなどにより一方の方法が選択されてもよい。また、ＴＭＣＣ制御情報とＴＬＶパケットとに格納される基準クロック情報のどちらか一方のみを出力する場合は、どちらを出力するかが選択できてもよい。

ここで、基準クロック情報が主信号（ＴＬＶパケット）で伝送される場合は、基準クロック情報は、伝送フレームにおけるＴＬＶストリームの先頭スロットの先頭ＴＬＶパケットに格納されている。よって、復号装置６１は、伝送レイヤにおいて、基準クロック情報が格納されているＴＬＶパケットを一意に特定できる。

しかし、上位レイヤの逆多重化装置６２では、伝送フレームの境界情報を把握できないため、受信したＴＬＶパケットが基準クロック情報を含むかどうかを判定できるのが、ＴＬＶパケットヘッダ及びＩＰパケットヘッダの解析後となる。そこで、本実施の形態では、下位レイヤの復号装置６１が上位レイヤの逆多重化装置６２に対し、そのＴＬＶパケットが伝送フレームにおけるＴＬＶストリームの先頭であること、又は、そのＴＬＶパケットが基準クロック情報を含むことをシグナリング（通知）する。これにより、上位レイヤの逆多重化装置６２は、そのＴＬＶパケットが基準クロック情報を含むことを、ＩＰパケットをヘッダを解析することなしに、検出することができる。

ＴＬＶパケットが伝送フレームにおけるＴＬＶストリームの先頭であること、又は、ＴＬＶパケットが基準クロック情報を含むことをシグナリングする方法としては、例えば、ＴＬＶパケットのパケットタイプの未定義領域を活用する方法がある。

例えば、ＩＰｖ４パケットに基準クロック情報が含まれている場合は、復号装置６１は、ＴＬＶタイプを、ＩＰｖ４パケットを示すＴＬＶタイプから、基準クロック情報が含まれるＩＰｖ４パケットであることを示すＴＬＶタイプに書き換え、書き換え後のＴＬＶパケットを逆多重化装置６２に出力する。また、ＩＰｖ６パケットに基準クロック情報が含まれている場合は、復号装置６１は、ＴＬＶタイプを、ＩＰｖ６パケットを示すＴＬＶタイプから、基準クロック情報が含まれるＩＰｖ６パケットであることを示すＴＬＶタイプに書き換え、書き換え後のＴＬＶパケットを逆多重化装置６２に出力する。

また、受信装置６０は、復号装置６１から逆多重化装置６２に、ＴＬＶパケットが基準クロック情報を含むことをシグナリングするかどうかを選択できるスイッチなどを有してもよい。例えば、この選択は逆多重化装置６２から行われてもよい。

以上の処理により、高精度な基準クロック情報の取得、及びクロック再生が可能となる。

図３９は、受信装置６０の復号部１１における動作フローを示す図である。

まず、復号部１１は、伝送フレームを復号し（Ｓ１９１）、その後、処理をする対象の基準クロック情報が、ＴＭＣＣに格納される基準クロック情報であるか、主信号に格納される基準クロック情報であるかを判定する（Ｓ１９２）。復号部１１は、主信号に格納される基準クロック情報を処理する場合（Ｓ１９２で主信号）には、ＴＬＶパケットをそのまま上位レイヤに出力する（Ｓ１９３）。一方、復号部１１は、ＴＭＣＣ制御情報に格納される基準クロック情報を処理する場合（Ｓ１９２でＴＭＣＣ）には、ＴＭＣＣ制御情報から基準クロック情報を抽出し、抽出した基準クロック情報を補正し、補正後の基準クロック情報を、伝送フレームにおけるＴＬＶストリームの先頭ＴＬＶパケットに格納し、当該ＴＬＶパケットを逆多重化装置６２に出力する（Ｓ１９４）。

図４０は、復号部１１を含む受信装置６０における動作フローを示す図である。

まず、逆多重化装置６２（上位レイヤ）は、復号装置６１から逆多重化装置６２へ出力する基準クロック情報を指定する（Ｓ２０１）。逆多重化装置６２に出力する基準クロック情報が主信号に含まれる基準クロック情報である場合（Ｓ２０２で主信号）、復号装置６１は、ＴＬＶパケットをそのまま逆多重化装置６２に出力する（Ｓ２０３）。一方、逆多重化装置６２に出力する基準クロック情報がＴＭＣＣ制御情報に格納される基準クロック情報である場合（Ｓ２０２でＴＭＣＣ）、復号装置６１は、ＴＭＣＣ制御情報から基準クロック情報を抽出し、抽出した基準クロック情報を補正し、補正後の基準クロック情報を、伝送フレームにおけるＴＬＶストリームの先頭ＴＬＶパケットに格納し、当該ＴＬＶパケットを逆多重化装置６２に出力する（Ｓ２０４）。

図４１は、復号装置６１が、そのＴＬＶパケットが基準クロック情報を含むかどうかをＴＬＶパケットタイプにシグナリングしている場合の、逆多重化装置６２における動作フローを示す図である。

まず、逆多重化装置６２は、復号装置６１から取得したＴＬＶパケットのパケットタイプを解析し（Ｓ２１１）、当該ＴＬＶパケットが基準クロック情報を含むかどうかを判定する（Ｓ２１２）。

当該ＴＬＶパケットが基準クロック情報を含む場合（Ｓ２１２でＹｅｓ）には、逆多重化装置６２は、ＩＰパケットヘッダを解析せずに、基準クロック情報を取得する（Ｓ２１３）。これにより、処理時間の短縮、及び処理量の削減が可能である。

一方、当該ＴＬＶパケットが基準クロック情報を含まない場合（Ｓ２１２でＮｏ）には、逆多重化装置６２は、当該ＴＬＶパケットに基準クロック情報が含まれないとして通常のＴＬＶＤｅｍｕｘ及びＩＰＤｅｍｕｘを行う（Ｓ２１４）。

なお、放送サービスのＩＰデータフローが、ＭＭＴパケットを格納するＩＰデータフローと基準クロック情報を格納するＩＰデータフローの２つである場合、受信装置６０が、ＴＬＶパケットタイプにより基準クロック情報を識別することにより、ＩＰアドレスの解析が不要になる。なぜならば、基準クロック情報をＴＬＶパケットタイプにより識別することにより、基準クロック情報を格納するＩＰデータフローおよびＭＭＴパケットを格納するＩＰデータフローはそれぞれ１つであることから、ＭＭＴパケットを格納するＩＰデータフローを識別するためのＩＰアドレスの解析も不要となるためである。

以上のように、本実施の形態に係る復号装置６１及び逆多重化装置６２には以下の処理を行う。

図４２は、本実施の形態に係る復号装置６１における動作フローを示す図である。

まず、受信部１０は伝送スロットを受信する（Ｓ２２１）。また、伝送スロットとは、図１３に示すように、コンテンツが多重化されることで得られたＴＬＶパケット（第１の伝送単位）が１以上含まれるスロット（第２の伝送単位）を複数格納した伝送用のフレームである。また、上述したように、伝送スロット内の先頭のスロット内で先頭に位置するＴＬＶパケットは基準クロック情報を含む。

次に、復号部１１は、伝送スロットを復号することで複数のＴＬＶパケットを取得する。また、復号部１１は、さらに、伝送スロット内の先頭のスロット内で先頭に位置するＴＬＶパケットを特定するための情報を生成する（Ｓ２２２）。

具体的には、復号部１１は、伝送スロット内の先頭のスロット内で先頭に位置するＴＬＶパケットに格納される、当該ＴＬＶパケットの管理情報（パケットタイプ）として、当該ＴＬＶパケットが基準クロック情報を含むことを示す情報を格納する。または、伝送スロット内の先頭のスロット内で先頭に位置するＴＬＶパケットを特定するための情報は、伝送スロット内の複数のＴＬＶパケットのうち、伝送スロット内の先頭のスロット内で先頭に位置するＴＬＶパケットを示す情報である。

つまり、復号部１１は、伝送スロット内の先頭のスロット内で先頭に位置するＴＬＶパケットを特定するための情報を生成し、当該情報を逆多重化装置６２に通知する。具体的には、復号部１１は、ＴＬＶパケット内に当該情報を追加する、又は、他の信号により当該情報を逆多重化装置６２に通知する。

次に、復号部１１は、上記情報を含むＴＬＶパケット、又は、ＴＬＶパケット及び上記情報を逆多重化装置に出力する（Ｓ２２３）。

図４３は、本実施の形態に係る逆多重化装置６２における動作フローを示す図である。

まず、取得部６３は、復号装置６１から伝送スロットを取得する（Ｓ２３１）。ここで、ＴＬＶパケットの各々は、当該ＴＬＶパケットが基準クロック情報を含む場合には、当該当該ＴＬＶパケットが基準クロック情報を含むことを示す管理情報（パケットタイプ）を含む。

逆多重化部６４は、管理情報に基づき、基準クロック情報を含むＴＬＶパケットを特定し（Ｓ２３２）、特定したＴＬＶパケットから基準クロック情報を取得する（Ｓ２３３）。また、逆多重化部６４は、複数のＴＬＶパケットを逆多重化することでコンテンツを取得する（Ｓ２３４）。

以上により、本実施の形態に係る受信装置６０では、復号装置６１から逆多重化装置６２に、基準クロック情報を含むＴＬＶパケットを特定するための情報が通知される。これにより、逆多重化装置６２は、ＩＰパケットヘッダ等を解析することなく、基準クロック情報を取得できるので、処理量の低減及び高速化を実現できる。

（実施の形態５）
本実施の形態では、図１１〜図１７で説明した、基準クロック情報を含むＴＬＶパケットを、伝送フレーム（伝送スロット）における相対ストリーム毎の先頭スロットの先頭ＴＬＶに格納する方法について捕捉する。ここで、１つの伝送フレームには、１又は複数の相対ストリームが含まれる。

図１６に示すＴＭＣＣ制御信号におけるポインタ／スロット情報は、スロットごとに包含される最初のパケットの先頭位置と最後のパケットの末尾の位置を示す。トップポインタの値は、スロット中の最初のパケットの先頭バイトの位置を、スロットヘッダを除いたスロット先頭からのバイト数で示す。ただし、０ｘＦＦＦＦは先頭バイトの不在を示す。ラストポインタの値は、スロット中の最後の配置完了パケットの最終バイトの、スロットヘッダを除いたスロット先頭からのバイト数に１を加えた値を示す。ただし、０ｘＦＦＦＦは最終バイトの不在を示す。

例えば、図４５に示すＳｌｏｔ＃１２０の例では、トップポインタは、ＴＬＶ＃（ｎ−２）の先頭バイト位置を示し、ラストポインタはＴＬＶ＃（ｎ−２）の最終バイト位置に１を加えた値（ＴＬＶ＃（ｎ−１）の先頭バイト位置）を示す。

基準クロック情報を含むＴＬＶパケットを相対ストリーム毎の先頭スロットの先頭に格納する場合、当該スロットのスロット／ポインタ情報の、トップポインタの値は０である。必然的に、同一のＴＬＶパケットが複数のフレームに跨ることはなく、伝送フレームにおいて、相対ストリーム毎の最後のスロットに格納される最後のＴＬＶパケット（以降では、最終ＴＬＶパケットと記載する）の最後のバイトは、相対ストリーム毎の最後のスロットの最後バイト（以降では、相対ストリーム毎のフレーム境界と記載する）に一致するよう、ＴＬＶパケットを格納しなければならない。

図４４は、基準クロック情報を含まない伝送フレームの構成を示し、図４５は、基準クロック情報を先頭スロットの先頭に含む伝送フレームの構成を示す。

ここでは、１フレームが１２０スロットで構成され、１２０スロット全てが１つの相対ストリームである場合の例を示す。Ｓｌｏｔ＃１２０が伝送フレームＭにおける相対ストリームの最後のスロットであり、Ｓｌｏｔ＃１が伝送フレームＭ＋１における相対ストリームの先頭スロットであり、伝送フレームＭのＳｌｏｔ＃１２０の最後のバイト、及び、伝送フレームＭ＋１のＳｌｏｔ＃１のスロットヘッダを除く先頭バイトがＴＬＶストリームのフレーム境界である。

図４４では、ＴＬＶ＃ｎが、複数のフレームに跨っている。一方、図４５では、相対ストリームの先頭スロット（Ｓｌｏｔ＃１）に基準クロック情報が配置されるため、ＴＬＶパケットはフレームを跨ない。つまり、伝送フレームＭのＳｌｏｔ＃１２０の最終バイトは、ＴＬＶ＃（ｎ−１）の最終バイトと一致するよう配置されなければならない。

ここで、ＴＬＶパケットには、伝送制御情報、ＩＰパケット、又は圧縮ＩＰパケットが格納されており、パケットサイズは可変長である。可変長のＴＬＶパケットを、固定長の伝送フレームに順に配置すると、最終ＴＬＶパケットの最後は、フレーム境界に揃わない場合がある。そこで、このような場合には、データタイプがＮＵＬＬのＴＬＶパケットを配置することにより、最終ＴＬＶパケットの最終バイトをフレーム境界に合わせることができる。ここで、データタイプがＮＵＬＬであるＮＵＬＬパケットとは、無効なデータであり、受信装置で使用されないデータが格納されるパケットである。

図４６に示すように、相対ストリーム毎にフレームにＴＬＶパケットが配置される。ＴＬＶ＃（ｎ−１）のＴＬＶパケットが配置された後、同一フレーム内にＴＬＶ＃ｎを配置できないため、ＴＬＶ＃ｎの代わりにＮＵＬＬパケットが配置される。これにより、ＮＵＬＬパケットの最終バイトがフレーム境界に一致する。

しかし、ＴＬＶパケットは、パケットのデータ構造、及び送信装置又は受信装置の制約等により、パケットサイズに最小値及び最大値が存在する場合がある。例えば、ＴＬＶパケットのヘッダは４バイトであるため、ＴＬＶパケットのペイロード部分に０バイトのＮＵＬＬを配置した場合でも、ＴＬＶパケットサイズは４バイトである。よって、この場合のＴＬＶパケットの最小値は４バイトである。さらに送信装置或いは受信装置の制約、又は規格の制約等により、この最小値は、より大きなバイト数（例えば２０バイトなど）に制約される可能性もある。同様に、ＴＬＶパケットサイズの最大値も制限される場合がある。

例えば、ＴＬＶパケットの最小値がＸ＿ｍｉｎバイトであり、最大値がＸ＿ｍａｘバイトであり、ＴＬＶ＃（ｎ−１）のパケットが配置された後の、フレーム境界までの残りバイト数がＹバイトである場合、Ｙ＜Ｘ＿ｍｉｎの場合には、ＮＵＬＬパケットを配置することができないという課題がある。例えば、Ｘ＿ｍｉｎが４バイトである場合は、４バイト未満の場合にはＮＵＬＬパケットを配置することができない。

以下、この課題を解決する本実施の形態の手法について説明する。

本実施の形態では、例えば、伝送フレームに順番にＴＬＶパケットが配置され、最後にＮＵＬＬパケットが配置される動作において、フレーム境界までの残りのバイト数と、これから格納する少なくとも２つ以上のＴＬＶパケットのバイト数が予め考慮されて、適切にＮＵＬＬパケットが配置される。

例えば、下記の規則に従い、ＮＵＬＬパケットが配置される。

図４７に示すように、フレームにおける相対ストリームにおいて、フレーム境界までの残りのバイト数をＹとし、ＴＬＶパケットの最小パケットサイズをＸ＿ｍｉｎバイトとし、ＴＬＶパケットの最大パケットサイズをＸ＿ｍａｘバイトとし、これから配置しようとするＴＬＶパケット（ＴＬＶ＃ｉ）のパケットサイズをＸ＿ｉバイトとし、さらに次のＴＬＶパケット（ＴＬＶ＃（ｉ＋１））のパケットサイズをＸ＿（ｉ＋１）とする。また、図４８は、本実施の形態に係る送信装置による動作のフローチャートである。

まず、送信装置は、処理対象のＴＬＶパケットであるＴＬＶ＃ｉのフレームへの配置を検討する（Ｓ３０１）。次に、送信装置は、ＴＬＶ＃ｉの次のＴＬＶパケットであるＴＬＶ＃（ｉ＋１）をフレーム内に配置することが可能かどうかを判定する（Ｓ３０２）。具体的には、送信装置は、ＴＬＶ＃ｉとＴＬＶ＃（ｉ＋１）との合計サイズが、残りバイト数より小さいかを判定する。つまり、送信装置は、Ｘ＿ｉ＋Ｘ（ｉ＋１）＜Ｙが満たされるかを判断する。

ＴＬＶ＃（ｉ＋１）をフレーム内に配置することが可能な場合（Ｓ３０２でＹｅｓ）、送信装置は、図４７の（１）に示すようにＴＬＶ＃ｉをフレームに配置する（Ｓ３０３）。次に、送信装置は、ＴＬＶ＃ｉ次のＴＬＶ＃（ｉ＋１）を選択し（Ｓ３０４）、選択したＴＬＶ＃（ｉ＋１）に対して、ステップＳ３０１以降の処理を行う。この場合、各処理におけるｉは全て１インクリメントされる。

一方、ＴＬＶ＃（ｉ＋１）をフレーム内に配置できない場合（Ｓ３０２でＮｏ）、送信装置は、残りの領域にＮＵＬＬパケットを配置すると決定する（Ｓ３０５）。

次に、送信装置は、ＴＬＶ＃ｉを配置した後の残りの領域が、ＴＬＶパケットの最小値より大きいかを判定する（Ｓ３０６）。つまり、送信装置は、（Ｙ−Ｘ＿ｉ＞Ｘ＿ｍｉｎが満たされるかを判定する。

ＴＬＶ＃ｉを配置した後の残りの領域が、ＴＬＶパケットの最小値より大きい場合（Ｓ３０６でＹｅｓ）、送信装置は、図４７の（２）に示すように、ＴＬＶ＃ｉをフレームに配置し、Ｙ−Ｘ＿ｉのサイズのＮＵＬＬパケットを生成し、生成したＮＵＬＬパケットをフレームのＴＬＶ＃ｉの後に配置し（Ｓ３０７）、当該フレームへのＴＬＶパケットの配置を完了する（Ｓ３０８）。

一方、ＴＬＶ＃ｉを配置した後の残りの領域がＴＬＶパケットの最小値より小さい場合（Ｓ３０６でＮｏ）、送信装置は、図４７の（３）に示すように、ＴＬＶ＃ｉをフレームに配置せず、ＹバイトのＮＵＬＬパケットを配置し（Ｓ３０９）、当該フレームへのＴＬＶパケットの配置を完了する（Ｓ３０８）。

なお、図４８には図示しないが、Ｙ＞Ｘ＿ｍａｘが満たされる場合は、送信装置は、図４７の（４）に示すように、２つ以上のＮＵＬＬパケットをフレームに配置してもよい。

以上のように、本実施の形態に係る送信装置は、フレームの中の相対ストリーム毎に定められた固定データ領域（或いはスロット数）に、可変長のＴＬＶパケットを格納する場合において、可変長のＮＵＬＬパケットに最小値パケットサイズの制約がある場合、例えば、少なくとも２つの可変長ＴＬＶパケットのバイト数とフレーム境界までの残りのバイト数とを常に監視する。これにより、最終ＴＬＶパケットをフレーム境界に揃えることができる。

なお、図４７の例では、フレーム境界までの残りのバイト数と、これから配置する２つのＴＬＶパケットのバイト数とを予め考慮してフレームに配置する方法について説明したが、送信装置は、３つ以上のＴＬＶパケットのバイト数を考慮してＮＵＬＬパケットを配置してもよい。

また、図４７の例では、ステップＳ３０２において、フレームの終端であるかを判定し、フレームの終端である場合（Ｓ３０２でＮｏ）に、ＴＬＶ＃ｉを配置した後の残りの領域が、ＴＬＶパケットの最小値より大きいかに応じて、ＮＵＬＬパケットのみ、又はＴＬＶ＃ｉ及びＮＵＬＬパケットを配置しているが、先にフレームの終端であるかを判定しない場合には、送信装置は、１つのＴＬＶパケット（ＴＬＶ＃ｉ）のみのバイト数を考慮してＮＵＬＬパケットを配置できる。

例えば、送信装置は、（１）ＴＬＶ＃ｉのパケットサイズが残りのバイト数Ｙより小さく、かつ、（２）ＴＬＶ＃ｉを配置した後の残りの領域Ｙ−Ｘｉが、ＴＬＶパケットの最小値より大きい場合には、ＴＬＶ＃ｉを配置し、（１）及び（２）の少なくとも一方が満たされない場合には、ＴＬＶ＃ｉを配置せず、ＮＵＬＬパケットを配置してもよい。

なお、図４７に示すように、先にフレームの終端であるかを判定することにより、ステップＳ３０５以降の処理の発生頻度を下げることができるので送信装置の処理量を低減できる。

また、図４６等から明らかなように、フレーム境界において、対象フレームに配置されなかったＴＬＶパケットは、次のフレームに配置される。具体的には、当該ＴＬＶパケットは、次のフレームの基準クロック情報を含むＴＬＶパケットの直後に配置される。

以下、本実施の形態の変形例について説明する。

送信装置は、最終ＴＬＶパケットをフレーム境界に揃えず、パディングを行ってもよい。ここで、基準クロック情報を含むＴＬＶパケットが伝送フレームの相対ストリーム毎の先頭スロットの先頭に格納される場合、ＴＬＶパケットがフレームを跨がないことは自明であるため、ラストポインタの値（最終ＴＬＶパケットの最後のバイトに１を足した値）からフレーム境界まではパディングすると規定する。この場合、受信装置は、ラストポインタの値により、パディングバイト数を判定できる。

また、図４９に示すように、送信装置は、必ず基準クロック情報を含むＴＬＶパケットを、相対ストリーム毎の先頭スロットの先頭に配置しながらも、基準クロック情報を含まないＴＬＶパケットを、基準クロック情報を越えて（跨いで）伝送スロットに配置してもよい。

図４９では、ＴＬＶ＃ｎは、複数のフレームを跨って配置される。さらに、ＴＬＶ＃ｎは基準クロック情報を含むＴＬＶパケットを挟んで配置される。この場合、基準クロック情報を含むＴＬＶパケットの位置及びサイズは既知であるため、トップポインタの値は、基準クロック情報を含むＴＬＶパケットの先頭バイト（＝０）を示すかわりに、基準クロック情報を含むＴＬＶパケットの最後のバイトに１を足したバイトを示してもよいし、基準クロック情報を含むＴＬＶパケット以外のＴＬＶパケットの先頭バイトを示してもよい。

また、伝送フレームには、最大１６本の相対ストリームが格納され、それぞれに基準クロック情報を含むＴＬＶパケットが配置される。複数の相対ストリームに共通の基準クロックが付与される場合、フレームにおいて、それぞれの相対ストリームの先頭には、必ず同じ情報が格納される。

よって、受信装置の復調部は、複数の相対ストリームに共通の基準クロックが付与されていると判定した場合には、複数の基準クロックが同じビット（値）であると判断し、複数のビットを平均化処理する。これにより、誤り訂正能力を向上できる。

また、ＴＭＣＣ制御情報の領域に、ＴＬＶパケットに格納される基準クロック情報と同じデータが格納されている場合、受信装置は、ＴＭＣＣ制御情報の基準クロック情報とＴＬＶパケットの基準クロック情報とが同じビットであると判断し、上記と同様の処理を行う。これにより、誤り訂正能力を向上できる。

また、ＴＭＣＣ制御情報は受信品質が高いため、受信装置は、ＴＭＣＣ制御情報の基準クロック情報でＴＬＶパケットの基準クロック情報を置き換えてもよい。

また、このような場合には、誤り訂正能力を向上させるためには、ＴＭＣＣ制御情報の基準クロック情報とＴＬＶパケットの基準クロック情報とが同一のビットである必要がある。よって、基準クロック情報を含むＴＬＶパケットには、スクランブル又は電力拡散は行われなくもよい。また、スクランブル系列が相対ストリーム毎に同一に設定され、基準クロック情報を含むＴＬＶパケットには、同一のスクランブル系列がかけられてもよい。

（実施の形態６）
本実施の形態では、選局時間を短縮する方法を説明する。

第１の方法では、受信装置は、フルヘッダを用いずにフィルタリングを開始する。受信装置がフルヘッダを用いずにフィルタリングを開始できるようにするために、ＩＰデータフローに対応するＣＩＤが予め設定される。或いは、受信装置がＣＩＤを特定するための情報が伝送される。

受信装置は、視聴者の選局動作により所望のサービスが指定されると同時に、ＡＭＴを受信し、ＡＭＴの情報に基づいてＩＰデータフロー及びＣＩＤを決定する。ＣＩＤを決定した時点でＩＰデータフローのフィルタリングが可能となるため、選局時間を短縮できる。さらに受信処理量を削減できる。

第２の方法では、ＭＭＴパケット（ＭＭＴＰパケットとも呼ぶ）を伝送するＩＰデータフローが、ＴＬＶストリーム内で１本であり、かつ、当該ＩＰデータフローとＮＴＰを伝送するＩＰデータフローとを合わせて計２本のＩＰデータフローがＴＬＶストリーム内に存在する場合に、ＭＭＴパケットを伝送するＩＰデータフローは必ずヘッダ圧縮し、ＮＴＰパケットを伝送するＩＰデータフローは必ずヘッダ圧縮しないと規定する。

受信装置では、ＴＬＶパケットにおけるデータタイプを用いて、ＩＰパケットがヘッダ圧縮されているかどうかに基づいてＩＰデータフローのフィルタリングを実施する。これにより、ＩＰデータフローのフィルタリングが不要となるため、選局時間を短縮できる。さらに受信処理量を削減できる。

まず、ＩＰパケット及びＡＲＩＢ ＳＴＤ−Ｂ３２に規定されるＩＰヘッダ圧縮（ＨＣｆＢ：Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ ｆｏｒ Ｂｒｏａｄｃａｓｔｉｎｇ）の詳細を、図５０を用いて説明する。

図２で説明したように、ＴＬＶパケットには、ＩＰｖ４パケット、ＩＰｖ６パケット、及び圧縮ＩＰパケットなどを格納することが可能である。また、ＴＬＶパケットにどの種別のＩＰパケットが格納されているかは、ＴＬＶヘッダに含まれるデータタイプを用いて識別される。圧縮ＩＰパケットは、コンテクスト識別ヘッダ種別（以降、ＣＩＤタイプと表記する）毎に異なるヘッダ構造を持つ。

ＣＩＤタイプ＝０ｘ２０は、部分ＩＰｖ４ヘッダであり、コンテクスト識別子（以降、ＣＩＤと表記する）、及びＩＰｖ４パケットヘッダにおける一部のフィールドを除いたヘッダなどを有する。部分ＩＰｖ４ヘッダは、ＩＰデータフローの特定情報を含む。ＩＰデータフローの特定情報とは、宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号、送信元ポート番号、およびプロトコル種別であり、ＩＰｖ６の場合は、プロトコル種別に代わりネクストヘッダーが示される。なお、図５０において、ドットのハッチングで示すヘッダ情報は、ＩＰデータフローの特定情報を含む。ＣＩＤは、同一ＩＰデータフローを識別するための識別子であり、ＩＰデータフローの特定情報が同一である圧縮ＩＰパケットには同一のＣＩＤが付与される。

ＣＩＤタイプ＝０ｘ２１は、ＣＩＤ、及びＩＰｖ４ヘッダにおけるｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールドを含み、ＩＰデータフローの特定情報を含まない。

ＣＩＤタイプ＝０ｘ６０は、ＣＩＤ、及びＩＰｖ６ヘッダにおける一部のフィールドを除いたヘッダを有し、ＩＰデータフローの特定情報を含む。

ＣＩＤタイプ＝０ｘ６１は、ＣＩＤのみを含み、ＩＰヘッダを含まない。このＣＩＤタイプは、通常、ＩＰｖ６でのみ用いられるが、ＩＰｖ４で用いてもよい。以降では、このＣＩＤタイプをＩＰｖ６のみで用いる前提で説明する。

なお、図示しないが、圧縮ＩＰパケットにおけるすべてのＣＩＤタイプのヘッダには、４ｂｉｔのシーケンス番号、及びＣＩＤタイプが示される。また、ＩＰデータフローの特定情報を含むヘッダ（ＣＩＤタイプ＝０ｘ２０、０ｘ６０）をフルヘッダと呼び、ＩＰデータフローの特定情報を含まないヘッダ（０ｘ２１、０ｘ６１）を圧縮ヘッダと呼ぶ。

フルヘッダは、一部のＩＰパケットにおける一部のフィールドが削減されているが、受信装置において、ＴＬＶヘッダなどの情報に基づいて、同一パケット完結でＩＰヘッダを再構成（ＩＰヘッダ伸張）できる。一方、圧縮ヘッダは、ＩＰデータフローの特定情報などを含まず、単独のパケットではＩＰヘッダ伸張できない。受信装置は、例えば、圧縮ヘッダと同一のＣＩＤを持つフルヘッダのヘッダ情報に基づいて必要な情報を得る。

図５１は圧縮パケットの多重方法を示す図である。これは、同一ＩＰデータフローのＩＰｖ６パケットをヘッダ圧縮する例であり、図示しないＴＬＶパケットヘッダには、圧縮ＩＰパケットであることを示すデータタイプが示される。ＩＰｖ６パケットをヘッダ圧縮する場合には、ＣＩＤタイプ＝０ｘ６０、０ｘ６１のいずれかが使用される。これらのパケットは、同一ＩＰデータフローに属するため、ＣＩＤには、同一の値が示される。なお、以降ではＩＰｖ６パケットを例に説明するが、ＩＰｖ４パケットでも同様である。

図５１の例では、３パケットに１回フルヘッダが送信され、残りの２パケットに対しては圧縮ヘッダが送信される。このように、定期的にフルヘッダを挿入し、残りを圧縮ヘッダとすることにより、ヘッダのオーバーヘッドを削減できる。

受信装置は、ＴＬＶヘッダの情報などに基づいて、フルヘッダの受信後に当該フルヘッダをヘッダ伸張する。また、受信装置は、圧縮ヘッダを、フルヘッダと共にヘッダ伸張する必要があるため、当該圧縮ヘッダと同一のＣＩＤを有するフルヘッダの受信後に、当該圧縮ヘッダを伸張する。また、受信装置は、ヘッダ伸張後に、ＩＰデータフローの特定情報に基づいて、ＩＰパケット又はＵＤＰパケットのフィルタリング処理を実施する。

なお、必ずしもヘッダ伸張は必要ではなく、ヘッダ伸張をしない実装方法も考えられている。その場合、ＣＩＤを用いてフィルタリングすることにより、ＩＰパケット又はＵＤＰパケットのフィルタリングと同等の動作を実施できる。この場合、受信装置は、フルヘッダに基づいて、ＩＰデータフローの特定情報とＣＩＤとの対応テーブルを別途作成し、所望のＩＰデータフローに対応するＣＩＤを持つパケットをフィルタリングする。

しかしながら、このような手法は以下の課題を有する。１つのＴＬＶストリーム内には、複数のＩＰデーフローが存在し、少なくとも、ＮＴＰを伝送するＩＰデータフロー、及びＭＭＴパケットを伝送するＩＰデータフローが存在する。ＭＭＴパケットを伝送するＩＰデータフローは、ＴＬＶストリーム内に１つである場合と、複数存在する場合がある。さらに、制御情報であるＭＭＴ−ＳＩを伝送する専用のＩＰデータフローが存在することもある。

受信装置は、ＴＬＶストリームから所望のＩＰデータフローを抽出する際には、ＩＰデータフローのフィルタリング、又は、ＩＰパケット或いはＵＤＰパケットのフィルタリングを実施する。また、受信装置は、ＩＰデータフローをフィルタリングする際には、所望のサービスのＩＰデータフローを特定し、所望のＩＰデータフローに属するパケットを識別する必要がある。

しかしながら、受信装置は、フルヘッダの受信後でなければ、所望のＩＰデータフローに属するパケットを識別できない。よって、受信装置がフルヘッダを始めに受信するまで、処理が遅延し、選局時間が長くなる。さらに、フルヘッダの送信間隔が長い場合、さらに選局時間が長くなる。例えば、フルヘッダの送信間隔がＮ秒である場合には、選局時間が最大Ｎ秒長くなる。

以下、選局時間を短縮する第１の方法を説明する。受信装置は、フルヘッダを用いずにフィルタリングを開始する。受信装置がフルヘッダを用いずにフィルタリングを開始できるようにするために、ＩＰデータフローに対応するＣＩＤが予め設定される。

例えば、ＮＴＰのＩＰデータフローはＣＩＤ＝０、サービス１のＩＰデータフローはＣＩＤ＝１、サービス２のＩＰデータフローはＣＩＤ＝２、サービス３のＩＰデータフローはＣＩＤ＝３、ＳＩ専用のＩＰデータフローはＣＩＤ＝２０など、ＩＰデータフローの種別に応じたＣＩＤの固定値が予め設定される。

また、ＴＬＶストリーム内に複数のサービスが含まれる場合は、サービスＩＤとＣＩＤとの対応を一意に決定できるよう規則性を設ける。例えば、サービスＩＤの下位ＮｂｉｔをＣＩＤと同じ値に設定することにより、サービスＩＤとＣＩＤとを対応付けできる。

これにより、受信装置は、視聴者の選局動作により所望のサービスが指定されると同時に、所望のＩＰデータフローのＣＩＤを決定できる。よって、ＩＰデータフローの特定情報は不要となり、受信装置は、フルヘッダの受信を待たずに、ＩＰデータフローのフィルタリングを開始できる。これにより、選局時間を短縮できる。

なお、別の方法として以下の方法を用いてもよい。ＩＰデータフローに対応するＣＩＤを予め定めるのではく、例えば、ＩＰデータフローとＣＩＤとの対応を示す情報が放送信号に多重して伝送されてもよい。例えば、この情報は、ＩＰデータフローのフィルタリングを開始するより前に処理できる制御情報に格納されることが望ましい。例えば、この情報は、ＴＬＶパケットに格納される伝送制御情報であるＡＭＴ（Ａｄｄｒｅｓｓ Ｍａｐ
Ｔａｂｌｅ）に格納される。また、他の例として、ＩＰデータフローのフィルタリングを開始するより前に処理できる制御情報は、ＭＭＴ−ＳＩであるＰＬＴあるいはＭＰＴ等に格納されてもよい。

ＡＭＴは、サービス毎の宛先ＩＰアドレス及び送信元ＩＰアドレスを格納するテーブルである。このＡＭＴには、宛先ポート番号、送信元ポート番号及びプロトコル種別等が含まれないため、受信装置は、ＡＭＴを用いてサービスに対応するＩＰデータフローを特定できない。しかし、ポート番号及びプロトコル番号を既知の値とすることにより、ＡＭＴをＩＰデータフローを特定する情報として活用できる。或いは、ＡＭＴに含まれるｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ領域を、ポート番号及びプロトコル種別を指定できるよう拡張してもよい。

上記の方法により、ＡＭＴを、サービスに対応するＩＰデータフローを特定するためのテーブルとして用いる場合、さらに、ＩＰデータフローに対応するＣＩＤを示す情報が信号内に格納される。例えば、ＩＰデータフローに対応するＣＩＤは、ＡＭＴに含まれるｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ領域に示される。

受信装置は、視聴者の選局動作により所望のサービスが指定されると同時に、ＡＭＴを受信し、ＡＭＴの情報に基づいて、所望のサービスに対応するＩＰデータフロー及びＣＩＤを特定する。受信装置は、ＣＩＤを特定した時点でＩＰデータフローのフィルタリングを行うことができるため、選局時間を短縮できる。さらに受信処理量を削減できる。

なお、上記方法を用いる場合、必ずしもフルヘッダを送信する必要はなく、圧縮ＩＰパケットのみを伝送してもよい。この場合、さらにヘッダ圧縮効果がある。

なお、ＡＭＴは、サービス毎の情報を示すテーブルであるため、ＳＩ（ＭＭＴ−ＳＩ）専用のＩＰデータフロー又はＮＴＰを伝送するＩＰデータフローの情報を示すことができない。従って、ＳＩ専用のＩＰデータフロー又はＮＴＰを伝送するＩＰデータフローのＣＩＤを予め定められた固定値に設定し、サービス毎のＣＩＤは、ＡＭＴに示してもよい。または、ＡＭＴをサービス以外のＣＩＤを指定できるよう拡張してもよい。

なお、ＴＬＶストリーム内に複数のサービスが存在しない場合は、必ずしもＡＭＴにＩＰデータフロー特定情報及びＣＩＤを示す必要はない。

また、受信装置は、ＡＭＴにＩＰデータフローの特定情報及びＣＩＤが記載されている場合のみ、フルヘッダを用いない選局動作を実施してもよい。

次に、選局時間の短縮する第２の方法について説明する。

第２の方法では、ＭＭＴパケットを伝送するＩＰデータフローをＴＬＶストリーム内で１つに制限する。また、ＴＬＶストリーム内には、ＮＴＰを伝送するＩＰデータフロー、及びＭＭＴパケットを伝送するＩＰデータフローが１本ずつ格納され、ＳＩ専用のＩＰデータフローが存在しない場合を説明する。

この場合、第１の方法を用いても選局時間を短縮できるが、下記の方法により、ＩＰデータフロー及びＣＩＤを特定する情報を送信しなくても受信装置はＩＰフィルタリングの開始時間を早められる。

ＭＭＴパケットを伝送するＩＰデータフローが、ＴＬＶストリーム内で１本の場合、ＴＬＶストリーム内には、当該ＩＰデータフローと、ＮＴＰを伝送するＩＰデータフローとの合計２本のＩＰデータフローが存在する。ここで、ＭＭＴパケットを伝送するＩＰデータフローは必ずヘッダ圧縮し、ＮＴＰパケットを伝送するＩＰデータフローは必ずヘッダ圧縮しないと規定する。

ＮＴＰパケットを伝送するＩＰデータフローをヘッダ圧縮しないことよりジッタ変動を抑えることが可能である。また、ＭＭＴパケットを伝送するＩＰデータフローは必ずヘッダ圧縮することにより、オーバーヘッド削減効果を向上できる。

受信装置は、ＴＬＶパケットにおけるデータタイプを用いて、ＩＰパケットがヘッダ圧縮されているかどうかを判定し、判定の結果に基づいてＩＰデータフローのフィルタリングを実施する。

具体的には、受信装置は、ＩＰパケットがヘッダ圧縮されている場合（データタイプ＝ヘッダ圧縮パケット）、当該ＩＰパケットがＭＭＴパケットを伝送するＩＰデータフローに属すると判定する。また、受信装置は、ＩＰパケットがヘッダ圧縮されていない場合（データタイプ＝ＩＰｖ４パケット又はＩＰｖ６パケット）、当該ＩＰパケットがＮＴＰパケットを伝送するＩＰデータフローに属すると判定する。

上記処理により、ＩＰヘッダ伸張、ＩＰ或いはＵＤＰアドレスを用いたフィルタリング、及びＣＩＤを用いたフィルタリング等が不要であるため、受信装置におけるフルヘッダ受信までに生じる遅延を削減できる。また、ＡＭＴを用いないことにより、ＡＭＴ受信までの遅延を短縮できる。さらに受信処理量も削減できる。

なお、上記方法を用いる場合においても、必ずしもフルヘッダを送信する必要はなく、圧縮ＩＰパケットのみを伝送してもよい。この場合、さらにヘッダ圧縮効果がある。

また、受信装置は、別途、フルヘッダを取得し、ＩＰデータフローの特定情報を解析できる。

以下、その他の変形例について説明する。

（１）ＴＬＶストリーム内に、複数のサービスが含まれ、ＳＩ専用のＩＰデータフローを格納する場合においても、ＭＭＴパケットを伝送するＩＰデータフローは必ずヘッダ圧縮し、ＮＴＰパケットを伝送するＩＰデータフローは必ずヘッダ圧縮しないと規定してもよい。この場合でも受信装置は、ヘッダ圧縮されてないＴＬＶパケットをＮＴＰパケットであると判定することが可能である。よって、ＮＴＰパケットを含むＩＰデータフローのフィルタリングが不要となり、受信処理量を削減でき、ＮＴＰパケットを用いたクロック再生などの処理開始時間を短縮できる。

（２）受信装置が十分なメモリを備えている場合、選局時間の短縮の第１の方法及び第２の方法を用いずに選局時間を短縮できる。

受信装置は、例えば、フルヘッダを受信する前であり、所望のＩＰデータフローを特定できない状態において、ＣＩＤに基づいてフィルタリングを開始する。このとき、受信装置は、フィルタリングしたデータを全て蓄積する。その後、受信装置は、フルヘッダを受信し、所望のＩＰデータフローを特定し、ＣＩＤを特定する。その後、受信装置は、蓄積しているデータのうち、特定したＣＩＤを有するデータ以外を破棄し、特定したＣＩＤを有するデータを高速処理する。これにより、選局時間を短縮できる。

（３）ＭＭＴパケットを伝送するＩＰパケットフローのうち、ＳＩ専用のＩＰデータのみ、ヘッダ圧縮しないと規定してもよい。

受信装置は、ＴＬＶパケットヘッダにおいてデータタイプがヘッダ圧縮パケットである場合、当該ＩＰパケットが、ＳＩ専用のＩＰデータフローを除くＭＭＴパケットを伝送するＩＰデータフローに属すると判定する。また、受信装置は、ＴＬＶパケットヘッダにおいてデータタイプがＩＰｖ４パケット又はＩＰｖ６パケットである場合（ヘッダ圧縮されていない場合）、当該ＩＰパケットが、ＮＴＰパケットを伝送するＩＰデータフロー又はＳＩ専用のＩＰデータフローに属すると判定する。

さらに、ＮＴＰを伝送するＩＰデータフロー、及びＭＭＴパケットを伝送するＳＩ専用のＩＰデータフローにおけるＩＰデータフローの特定情報が予め定められている場合、受信装置は、ＴＬＶパケットヘッダのフィルタリングと同時にＩＰデータフローの特定情報に基づいてＩＰデータフローがＮＴＰパケットであるかＳＩ専用のＩＰデータフローであるかを判定できる。

これまでの説明では、受信装置において、ＴＬＶストリームのＴＬＶパケットが連続で受信される場合を例に説明してきた。

ＴＬＶストリームのＴＬＶパケットが連続で受信される場合とは、例えば、受信装置が、伝送レイヤで取得したＴＬＶパケットを、ＴＬＶパケットの状態で順番にＴＬＶパケット処理に入力する場合である。

伝送レイヤでは、１つの伝送フレームに、１以上のＴＬＶストリームが格納されるとともに、複数のＴＬＶパケットが格納される。受信装置では、伝送レイヤ処理において、複数のＴＬＶパケットがバースト的に受信される。受信装置は、伝送レイヤにおいて、ＴＬＶストリーム毎に複数のＴＬＶパケットを受信した後、所望のＴＬＶストリームのＩＰヘッダ圧縮伸張を実施する。これにより得られた圧縮されていない完全なＩＰパケットが、順番にＩＰパケット処理に入力される場合、伝送フレーム内に含まれるＴＬＶストリーム内のＩＰデータフローに、少なくとも１以上のフルヘッダを含むＴＬＶパケットが含まれていれば、受信装置は、１伝送フレーム内のすべてのＩＰデータフローのヘッダ伸張を実施できる。

上記処理を可能とするため、伝送フレームに含まれるＴＬＶストリーム内のＩＰデータフローにおいては、少なくとも１以上はフルヘッダを伝送すると規定する。これにより、受信装置は、伝送レイヤで一括でヘッダ伸張を実施することが可能となる。よって、受信装置は、以降の処理でヘッダ伸張又はフルヘッダの受信を待機する必要がなくなり、選局時間を短縮できる。

また、伝送フレームにおけるＴＬＶストリームにおいて、フルヘッダを含むＴＬＶパケットの位置を予め定めることにより、受信装置は容易にフルヘッダを取得できる。例えば、伝送フレームに含まれるＴＬＶストリームにおいて先頭に位置するＴＬＶパケットが必ずフルヘッダであると規定する。なお、ＴＬＶストリームの先頭ＴＬＶパケットが必ずＮＴＰである場合には、２番目のＴＬＶパケットが必ずフルヘッダであると規定してもよい。または、その他の規則でもよい。

以下、受信装置の処理の流れを説明する。図５２は、上記第１の方法（ＣＩＤが予め設定される）における受信装置による受信処理のフローチャートである。

まず、受信装置は、ＡＭＴを解析し、ＣＩＤが予め設定されているかどうかを判定する（Ｓ４０１）。ＣＩＤが設定されており、所望のＩＰデータフローを特定できる場合（Ｓ４０２でＹｅｓ）、受信装置は、ＡＭＴを用いてＣＩＤを取得し、フルヘッダを受信する前にＩＰデータフローのフィルタリングを開始する（Ｓ４０３）。

一方、ＣＩＤが設定されていない場合（Ｓ４０２でＮｏ）は、受信装置は、フルヘッダを受信した後に所望のＩＰデータフローを特定し、ＩＰデータフローのフィルタリングを開始する（Ｓ４０４）。

図５３は、上記第２の方法（ＭＭＴパケットを伝送するＩＰデータフローは必ずヘッダ圧縮し、ＮＴＰパケットを伝送するＩＰデータフローは必ずヘッダ圧縮しない）における受信装置による受信処理のフローチャートである。

まず、受信装置は、ＴＬＶヘッダのデータタイプ解析し、ＴＬＶヘッダに格納されるＩＰパケットがヘッダ圧縮されているかどうかを判定する（Ｓ４１１）。ＩＰパケットがヘッダ圧縮されている場合（Ｓ４１２でＹｅｓ）、受信装置は、当該ＩＰパケットが、ＭＭＴパケットを伝送するＩＰデータフローに属すると判定する（Ｓ４１３）。一方、ＩＰパケットがヘッダ圧縮されていない場合（Ｓ４１２でＮｏ）、受信装置は、当該ＩＰパケットが、ＮＴＰパケットを伝送するＩＰデータフローに属すると判定する（Ｓ４１４）。

なお、ＴＬＶストリームの処理において、圧縮ＩＰヘッダ又はＩＰパケットヘッダを用いたＩＰデータフローの解析は不要である。

以上のように、本実施の形態に係る送信装置は、放送を通じてコンテンツを送信する。図５４は、本実施の形態に係る送信装置７０のブロック図である。この送信装置７０は、生成部７１と、送信部７２とを備える。

図５５は、本実施の形態に係る送信装置７０による送信方法のフローチャートである。まず、生成部７１は、コンテンツ（例えばＭＭＴパケット）が格納された第１ＩＰパケットと、コンテンツの再生のための時刻を示す基準クロック情報（例えばＮＴＰ）を含む第２ＩＰパケットとが格納された伝送用のフレーム（伝送フレーム）を生成する（Ｓ４２１）。具体的には、生成部７１は、第１ＩＰパケットに対してはヘッダ圧縮を行い、第２ＩＰパケットに対してはヘッダ圧縮を行わない。

具体的には、生成部７１は、図５０及び図５１に示すように、ヘッダ圧縮として、複数の第１ＩＰパケットのうち一部の第１ＩＰパケットに、複数の第１ＩＰパケットが属するＩＰデータフローを特定する特定情報を含むフルヘッダを付与し、複数の第１ＩＰパケットのうち上記一部の第１ＩＰパケット以外の第１ＩＰパケットに特定情報を含まない圧縮ヘッダを付与する。

次に送信部７２は、生成部７１により生成されたフレームを送信する（Ｓ４２２）。

また、本実施の形態に係る受信装置は、放送を通じてコンテンツを受信する。図５６は、本実施の形態に係る受信装置８０のブロック図である。この受信装置８０は、受信部８１と、判定部８２と、再生部８３とを備える。

図５７は、本実施の形態に係る受信装置８０による受信方法のフローチャートである。まず、受信部８１は、コンテンツ（例えばＭＭＴパケット）が格納された、ヘッダ圧縮されている第１ＩＰパケットと、コンテンツの再生のための時刻を示す基準クロック情報（例えばＮＴＰ）を含む、ヘッダ圧縮されていない第２ＩＰパケットとが格納された伝送用のフレーム（伝送フレーム）を受信する（Ｓ４３１）。

次に、判定部８２は、ＩＰパケットがヘッダ圧縮されているか否かに応じて、当該ＩＰパケットが第１ＩＰパケットであるか第２ＩＰパケットであるかを判定する（Ｓ４３２）。具体的には、図５０及び図５１に示すように、ヘッダ圧縮として、複数の第１ＩＰパケットのうち一部の第１ＩＰパケットに、複数の第１ＩＰパケットが属するＩＰデータフローを特定する特定情報を含むフルヘッダが付与されており、複数の第１ＩＰパケットのうち上記一部の第１ＩＰパケット以外の第１ＩＰパケットに特定情報を含まない圧縮ヘッダが付与されている。また、判定部８２は、ヘッダ圧縮されているＩＰパケットを第１ＩＰパケットと判定し、ヘッダ圧縮されていないＩＰパケットを第２ＩＰパケットと判定する。

次に、再生部８３は、上記判定の結果に応じて、第２ＩＰパケットに格納された基準クロック情報を用いて、第１ＩＰパケットに格納されたコンテンツを再生する（Ｓ４３３）。

また、図５０に示すように、ＩＰヘッダがヘッダヘッダ圧縮されているか否かは、ＴＬＶパケットのヘッダに含まれる情報（データタイプ）により示される。

つまり、ステップＳ４２１において、生成部７１は、第１ＩＰパケットが格納されるＴＬＶパケットのヘッダに、当該第１ＩＰパケットがヘッダ圧縮されていることを示す情報を格納し、第２ＩＰパケットが格納されるＴＬＶパケットのヘッダに、当該第２ＩＰパケットがヘッダ圧縮されていないことを示す情報を格納する。

また、ステップＳ４３２において、判定部８２は、ＴＬＶパケットのヘッダに格納される情報に基づき、当該ＴＬＶパケットに格納されているＩＰパケットが第１ＩＰパケットであるか第２ＩＰパケットであるかを判定する。

以上により、受信装置は、ヘッダ圧縮がされているか否かに応じて、ＩＰデータフローをフィルタリングできる。よって、選局時間を短縮できる。

なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

また、各構成要素は、回路でもよい。これらの回路は、全体として１つの回路を構成してもよいし、それぞれ別々の回路でもよい。また、これらの回路は、それぞれ、汎用的な回路でもよいし、専用の回路でもよい。

例えば、上記各実施の形態において、特定の処理部が実行する処理を別の処理部が実行してもよい。また、複数の処理の順序が変更されてもよいし、複数の処理が並行して実行されてもよい。

以上、一つまたは複数の態様に係る受信装置（受信方法）及び送信装置（送信方法）について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

本発明の送信方法及び受信方法は、例えば、ＭＭＴ方式を放送システムに適用できる。

１０ 受信部
１１ 復号部
１２ ＴＬＶデマルチプレクサ
１３ ＩＰデマルチプレクサ
１４ ＭＭＴデマルチプレクサ
１５ 基準クロック情報抽出部
１５ａ 第１基準クロック情報抽出部
１５ｂ 第２基準クロック情報抽出部
１６ 基準クロック生成部
１６ａ 第１基準クロック生成部
１６ｂ 第２基準クロック生成部
１７ 同期部
１８ 復号提示部
２０、４０、５０、６０ 受信装置
３０ 送信装置
３１ 生成部
３２ 送信部
４１ 拡張識別部
４２ 拡張種別判定部
４３ 変更指示確認部
４４ データ更新確認部
４５ 更新データ取得部
５１ 第１の放送局
５２ 第２の放送局
５３ 第３の放送局
５４ 衛星の送信局
６１ 復号装置
６２ 逆多重化装置
６３ 取得部
６４ 逆多重化部
７０ 送信装置
７１ 生成部
７２ 送信部
８０ 受信装置
８１ 受信部
８２ 判定部
８３ 再生部

Claims (4)

1. 放送を通じてコンテンツを送信する送信方法であって、
   前記コンテンツが格納された第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットを含む１つの第１ＩＰデータフローと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む第２ＩＰパケットを含む１つの第２ＩＰデータフローとが格納されたＴＬＶストリームを含む伝送用のフレームを生成する生成ステップと、
   生成された前記フレームを送信する送信ステップとを含み、
   前記生成ステップでは、
   前記第１ＩＰパケットに対してはヘッダ圧縮を行い、
   前記第２ＩＰパケットに対してはヘッダ圧縮を行わず、
   前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）パケットに格納される
   送信方法。
2. 放送を通じてコンテンツを受信する受信方法であって、
   前記コンテンツが格納された、ヘッダ圧縮されている第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットを含む１つの第１ＩＰデータフローと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む、ヘッダ圧縮されていない第２ＩＰパケットを含む１つの第２ＩＰデータフローとが格納されたＴＬＶストリームを含む伝送用のフレームを受信する受信ステップと、
   ＩＰパケットがヘッダ圧縮されているか否かに応じて、当該ＩＰパケットが前記第１ＩＰパケットであるか前記第２ＩＰパケットであるかを判定する判定ステップと、
   前記判定の結果に応じて、前記第２ＩＰパケットに格納された前記基準クロック情報を用いて、前記第１ＩＰパケットに格納された前記コンテンツを再生する再生ステップとを含み、
   前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）パケットに格納される
   受信方法。
3. 放送を通じてコンテンツを送信する送信装置であって、
   前記コンテンツが格納された第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットを含む１つの第１ＩＰデータフローと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む第２ＩＰパケットを含む１つの第２ＩＰデータフローとが格納されたＴＬＶストリームを含む伝送用のフレームを生成する生成部と、
   生成された前記フレームを送信する送信部とを備え、
   前記生成部は、
   前記第１ＩＰパケットに対してはヘッダ圧縮を行い、
   前記第２ＩＰパケットに対してはヘッダ圧縮を行わず、
   前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）パケットに格納される
   送信装置。
4. 放送を通じてコンテンツを受信する受信装置であって、
   前記コンテンツが格納された、ヘッダ圧縮されている第１ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットを含む１つの第１ＩＰデータフローと、前記コンテンツの再生のための時刻を示す基準クロック情報を含む、ヘッダ圧縮されていない第２ＩＰパケットを含む１つの第２ＩＰデータフローとが格納されたＴＬＶストリームを含む伝送用のフレームを受信する受信部と、
   ＩＰパケットがヘッダ圧縮されているか否かに応じて、当該ＩＰパケットが前記第１ＩＰパケットであるか前記第２ＩＰパケットであるかを判定する判定部と、
   前記判定の結果に応じて、前記第２ＩＰパケットに格納された前記基準クロック情報を用いて、前記第１ＩＰパケットに格納された前記コンテンツを再生する再生部とを含み、
   前記コンテンツは、前記第１ＩＰパケット内のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）パケットに格納される
   受信装置。

Images