JP5331814B2 - バーストモードアクティビティを通信する装置および方法 - Google Patents

Description

本開示は、一般にデジタル放送システムのオペレーションに関し、特に、モバイル装置、歩行者用装置（pedestrian device）、およびパーソナル装置による使用が意図されているテレビジョン放送用データの符号化および復号化に関する。

本出願は米国特許商標庁に提出した仮出願（１）２００７年１０月１５日に提出した出願番号６０／９９８９７８、（２）２００７年１０月１５日に提出した出願番号６０／９９８９６１、（３）２００７年１０月１５日に提出した出願番号６０／９９９０４０、（４）２００８年８月２９日に提出した出願番号６１／１９０４９９、（５）２００８年８月２９日に提出した出願番号６１／１９０５１６、（６）２００８年８月２９日に提出した出願番号６１／１９０５１７について３５Ｕ.Ｓ.Ｃ.§１１９に基づいた利益を主張する。

関連出願についての表示
本出願は、本出願人が共通して所有する次の同時継続中の米国特許出願と関連する。（１）国際特許出願(出願番号ＰＣＴ／ＵＳ０８／００６３３４，トムソン整理番号ＭＩＣＲ０７００１)として２００８年５月１６日に出願したＮｏ．ＸＸＸ、発明の名称「APPRATUS AND METHOD FOR ENCODING AND DECODING SIGNALS」、（２）国際特許出願(出願番号ＰＣＴ／ＵＳ０８／００６３３５，トムソン整理番号ＭＩＣＲ０７００２)として２００８年５月１６日に出願した出願番号ＸＸＸ、発明の名称「APPRATUS AND METHOD FOR ENCODING AND DECODING SIGNALS」、（３）国際特許出願(出願番号ＰＣＴ／ＵＳ０８／００６３３３，トムソン整理番号ＭＩＣＲ０７００３)として２００８年５月１６日に出願した出願番号ＸＸＸ、発明の名称「APPRATUS AND METHOD FOR ENCODING AND DECODING SIGNALS」（４）国際特許出願(出願番号ＰＣＴ／ＵＳ０８／００６３３２，トムソン整理番号ＭＩＣＲ０７００４)として２００８年５月１６日に出願した出願番号ＸＸＸ、発明の名称「APPRATUS AND METHOD FOR ENCODING AND DECODING SIGNALS」、（５）国際特許出願(出願番号ＰＣＴ／ＵＳ０８／００６３３１，トムソン整理番号ＭＩＣＲ０８００１)として２００８年５月１６日に出願した出願番号ＸＸＸ、発明の名称「APPRATUS AND METHOD FOR ENCODING AND DECODING SIGNALS」、（６）国際特許出願(出願番号ＸＸＸ，トムソン整理番号ＰＵ０８０１４５)として２００８年１０月１４日に出願した出願番号ＸＸＸ、発明の名称「PREAMBLE FOR A DIGITAL TELEVISION SYSTEM」、（７）国際特許出願(出願番号ＸＸＸ，トムソン整理番号ＰＵ０８０１６２)として２００８年１０月１４日に出願した出願番号ＸＸＸ、発明の名称「CODE RATE IDENTIFIER IN PSUEDORANDOM」、（８）国際特許出願(出願番号ＸＸＸ，トムソン整理番号ＰＵ０７０２５５)として２００８年１０月１４日に出願した出願番号ＸＸＸ、発明の名称「APPRATUS AND METHOD FOR ENCODING AND DECODING SIGNALS」。

このセクションの記載は、下記で説明される本発明の様々な態様に関連する可能性のある技術の様々な態様を読み手に紹介することを意図している。この説明は背景情報を読み手に提供することの手助けになり、これにより本発明の様々な態様のより良い理解を促進する。したがって、これらの記載は、このような観点から読まれるべきであって、従来技術の承認として読まれるべきではないことを理解されたい。

世界中のテレビ放送システムは、アナログのオーディオおよびビデオ信号の配信から最新デジタル通信システムに移ってきている。例えば、米国では、ＡＴＳＣ(Advanced Television Standards Committee）が、「ＡＴＳＣ規格：デジタルテレビジョン規格Ａ／５３」（Ａ５３規格）と称される規格を開発した。Ａ５３規格はデジタルテレビ放送用のデータをどのように符号化し復号化すべきかを定義している。さらに、米国のＦＣＣ（Federal Communications Commission：連邦通信委員会）は、テレビ放送用の電磁スペクトルの領域の割り当てを行っている。ＦＣＣは、その割り当てられた領域内の連続的な６ＭＨｚのチャネルを、地上デジタルテレビジョン放送（すなわち、ケーブルや衛星ではない）を伝送する放送会社に割り振っている。各６ＭＨｚのチャネルは、Ａ５３規格の符号化および変調フォーマットに基づいて、約１９Ｍｂ／秒のチャネル容量を有している。さらに、ＦＣＣは、６ＭＨｚのチャネルを介した地上デジタルテレビジョンデータの伝送がＡ５３規格に準拠しなければならないことを義務づけている。

Ａ５３規格は、ソースデータ（例えば、デジタルのオーディオおよびビデオデータ）を、チャネルを通じて伝送される信号へと、どのように処理し変調すべきかを定義している。その処理により、冗長情報（redundant information）がソースデータに追加され、その結果、チャネルから信号を受信する受信側は、該チャネルによりノイズやマルチパルス干渉（multi-path interference）が伝送される信号に加えられたとしても、ソースデータを回復することができる。ソースデータに追加される冗長情報は、伝送されるソースデータの有効データレートを減少させるが、伝送信号からのソースデータの回復が成功する可能性を増加させる。

図１は、Ａ５３規格に準拠した信号を送信する一般的な送信システム１００のブロック図を示している。データは送信ソース１０２によって生成され、複数のパケットに編成される。該パケットは、１つまたは複数のコードワード(codeword)を含むことができる１８７バイトのサイズである。各パケットは３バイトのヘッダを含み、該ヘッダのうちの１３ビットは、そのパケットとして送信されるデータのタイプを識別するパケットＩＤ（ＰＩＤ）である。例えば、値０ｘ１１（１６進数で１１）のＰＩＤを有するパケットは、第１のビデオストリームを有するコンテンツを識別することができ、値０ｘ１４のＰＩＤを有するパケットは、該パケットのコンテンツを第１のオーディオストリームとして識別することができる。データランダマイザ（data randomizer）１０４は、パケットをランダム化して、そのパケットをリードソロモン符号化器（Reed-Solomon encoder）１０６に供給する。リードソロモン符号化器１０６は、２０パリティバイトを計算して、ランダム化されたデータに連結し、２０７バイトを有するＲ−Ｓパケットを生成する。

畳み込みインタリーバ（convolutional interleaver）１０８は、データを時間内にさらにランダム化するために、Ｒ−Ｓパケットをインタリーブする。トレリス符号化器１１０は、インタリーブ化されたパケットを符号化して、８２８の３バイトのシンボルからなるブロックを生成する。Ａ５３規格は、１２のトレリス符号化器の使用を指定しており、各トレリス符号化器は、インタリーブ化されたパケット内にある２ビット毎に３ビットのシンボルを生成する、２／３レートのトレリス符号化器である。したがって、トレリス符号化器１１０は、デマルチプレクサ、１２のパラレル２／３レートトレリス符号化器、およびマルチプレクサを含んでいる。畳み込みインタリーバ１０８からのデータは、非多重化（de-multiplexed）され、１２のトレリス符号化器に分配され、そして、１２のトレリス符号化器によって生成されるシンボルは、シンボルのストリームに多重化される。

同期マルチプレクサ（sync multiplexer）１１２は、各８２８シンボルブロックの先頭部分に４つの所定のセグメント同期シンボル（segment sync symbol）を挿入して、８３２シンボルセグメントを作成する。さらに、同期マルチプレクサ１１２は、生成される３１２セグメント毎に、８３２のシンボルを有するフィールド同期（field sync）を挿入する。特に、フィールド同期シンボルは３１２のセグメントの前に位置する。

８−ＶＳＢ変調器１１４は、トレリス符号化器１１０によって符号化されたデータ、セグメント同期シンボル、およびフィールド同期を含む多重化されたシンボルを用いて、８−ＶＳＢ（vestigial sideband：残留側波帯）変調によりキャリア信号を変調する。特に、８−ＶＳＢ変調器１１４は信号を生成するが、該生成される振幅は、各離散レベル（discrete level）が特定の３ビットシンボルに対応する８つの離散レベルのうちのいずれかである。この信号は、その後回路（図示せず）を使用して、デジタルからアナログの信号フォーマットに変換され、そして無線周波数信号に周波数が変換（up-convert）される。その無線周波数信号は、アンテナ１１６を使用して送信される。典型的に、データランダマイザ１０４、リードソロモン符号化器１０６、畳み込みインタリーバ１０８、およびトレリス符号化器１１０の組み合わせは、８−ＶＳＢ符号化器１２０と称される。８−ＶＳＢ符号化器１２０は、Ａ５３符号化器またはＡＴＳＣ符号化器と称されることもある。

送信ソース１０２によって生成されるデータは、ＩＳＯ／ＩＥＣ(International Standards Organization/International Electrotechnical Commission)の１３８１８−２フォーマットと同じＭＰＥＧ２(Motion Picture Entertainment Group)フォーマットを用いて符号化されたソースであるビデオを含む。送信ソース１０２は、ＡＣ−３(Dolby Arc Consistency algorithm #3)を用いて符号化されたソースであるオーディオデータも含む。Ａ５３規格は、番組ガイドデータなどの他のプログラム要素に関するメタデータの使用も許可しており、そのようなプログラム要素は他の方法を用いて符号化されたソースとすることもできる。さらに、Ａ５３規格は、標準解像度のインタレーステレビジョン品質からプログレッシブスキャンワイドスクリーンの高解像度品質にまで及ぶ、様々なビデオ品質レベルおよび様々な表示フォーマットでビデオを送信することも許可している。ＦＣＣは、放送会社が、送信ソース１０２によって生成されたデータを、Ａ５３規格を用いて符号化しなければならないことを要求している。デジタルテレビ番組放送の送信に、割り当てられたチャネルの１９Ｍｂ／秒の容量の全ては必要ではない場合、放送会社は、余分な容量を使用して、おそらくポータブル受信機および携帯電話機などの装置に対しても他のサービスを放送することができる。しかしながら、ＦＣＣは、その余分な容量を使用してそのような他の装置に送信されるデータを、Ａ５３規格に従って送信しなければならないことを要求している。Ａ５３規格の修正は可能であり、ＡＴＳＣによって検討されているが、既存のデジタルテレビジョン受像機、すなわち、いわゆるレガシーデジタルテレビジョン受像機を継続して使用できるように進展しなければならない。同様に、既存のＡ５３規格に従う信号の符号化および送信もレガシー符号化および送信と称することができる。

図２は、既存すなわちレガシーＡ５３規格に準拠する受信信号からソース情報を抽出するのに使用される受信機２００のブロック図である。アンテナ２０２は、放送波を通じて送信された電磁信号から受信電気信号を生成する。アナログ／デジタル（Ａ／Ｄ）変換器２０４が、該受信信号のデジタルサンプルを生成し、トレリス復号化器２０６が、該デジタルサンプルを復号化して、データストリーム内の複数のビットのトレリス復号化予測値（trellis-decoded estimates of bits）のストリームを生成する。Ａ／Ｄ変換器２０４は、受信信号において所望チャネルを受信するためにチューナなどの追加のフロントエンド処理回路を含むことができる。既存またはレガシーＡ５３規格に従って、トレリス復号化器２０６は、信号デマルチプレクサ、１２個の２／３レートのトレリス復号化器、および信号マルチプレクサを含んでいる。そのデマルチプレクサは、デジタルサンプルを１２個の２／３レートのトレリス復号化器に分配し、そしてマルチプレクサは、１２個の２／３レートのトレリス復号化器の各々によって生成される予測値を多重化する。

畳み込みデインタリーバ（convolutional de-interleaver）２０８は、トレリス復号化ビット予測値のストリームを非インタリーブ化し、２０７バイトを含むように配置されたシーケンスまたはパケットを生成する。パケット配置は、図示されていない同期信号の位置の判断および識別とともに行われる。リードソロモンエラー修正回路（error correction circuit）２１０は、デインタリーバ２０８によって生成された２０７バイトの各シーケンスを１つまたは複数のコードワードとみなし、該コードワードまたはパケット内の全てのバイトが、送信中のエラーのために破損したか否かを判断する。この判断はしばしば、コードワードについてシンドロームのセットまたはエラーパターンのセットを計算して評価することによって行われる。破損が検出されると、リードソロモンエラー修正回路２１０は、パリティバイトに符号化された情報を使用して破損バイトを回復するように試みる。その結果エラー修正されたデータストリームは、デランダマイザ２１２によって非ランダム化（de-randomize）されて、その後、送信されるコンテンツのタイプに応じてデータストリームを復号化するデータ復号化器２１４に提供される。典型的に、トレリス復号化器２０６と、デインタリーバ２０８と、リードソロモンエラー復号化器２１０と、デランダマイザ２１２の組み合わせは、受信機２００内の８−ＶＳＢ復号化器２２０として識別される。一般にレガシーＡ５３規格に準拠した信号を受信するための典型的な受信機は、受信処理を送信処理とは逆の順序で行うことに留意されたい。

一般に、リードソロモン符号化および復号化に利用されるアルゴリズムは、当技術分野の当業者には周知である。上述のように、図１のリードソロモン符号化器１０６は、２０のパリティバイトを、１８７バイトを有するデータパケットに追加することによって、２０７バイトを有するコードワードを生成する。図２のコードソロモン復号化器２１０は、上記符号化器によって追加された２０バイトを使用して、コードワードの１０バイトまでのエラーを修正する。

リードソロモンエラー修正アルゴリズムはガロア域(Galois Field)のプロパティを利用する。特に、ガロア域ＧＦ(pⁿ)は、有限数の要素pⁿを有する数学的集合であり、ここで、ｐおよびｎの値は整数である。特定のガロア域は、生成多項式ｇ(x)を使用して定義される。ガロア域の各要素を、ｎビットを有する一意のビットパターン（unique bit pattern）で表すことができる。さらに、次数pⁿの一意の多項式を各要素と関連付けることができ、ここでその多項式の各係数は０とｐ−１との間である。さらに、ガロア域の数学的演算は重要なプロパティを有する。ガロア域ＧＦ(pⁿ)の２つの要素の加算は、加算される２つの要素と関連付けられるその多項式の係数のｐを法とした合計である係数を有する、多項式と関連付けられた要素として定義される。同様に、２つの要素の乗算は、ガロア域と関連付けられた生成多項式ｇ(x)を法として２つの要素に関連付けられた多項式の乗算として定義される。加算演算子および乗算演算子はガロア域において、該ガロア域の任意の２つの要素の和および積がガロア域の要素となるように定義される。リードソロモンコードワードのプロパティは、該コードワードの各バイトがガロア域の要素と乗算され、その結果、別の有効なリードソロモンコードワードとなる。さらに、２つのリードソロモンコードワードのバイト毎の加算により、別のリードソロモンコードワードが生成される。レガシーＡ５３規格は、リードソロモンアルゴリズムで使用するための２５６個の要素のガロア域ＧＦ(2⁸)および関連する生成多項式ｇ(x)を定義する。また、ガロア域のプロパティは、エラーを判断するためにコードワード用のシンドロームを生成する能力（ability）も作り出す。

デランダマイザからの出力パケットはデータ復号化器２１４に提供される。データ復号化器２１４は、復号化されたパケットのヘッダ内のＰＩＤを使用して、該パケット内の情報のタイプ、および該情報をどのように復号化するべきか判断する。ヘッダ内のＰＩＤは、データストリームの一部として受信機に周期的に送信されて更新される、プログラムマップテーブル（ＰＭＴ）内の情報と比較される。データ復号化器２１４は、認識済みタイプでないデータパケットのＰＩＤを有するパケットを無視する。このように、レガシーＡ５３規格は、送信ソースが新しいパケットタイプの一意のＰＩＤ値を割り当てることによって、元の規格で意図されていない新しいパケットタイプの作成を可能にする。その新しいパケットタイプをサポートしていないレガシー復号化器は、そのようなパケットを無視することができるが、新しいパケットタイプを認識する新しい復号化器は、そのようなパケットを処理することができる。

明らかであるように、受信機２００において２／３レートのトレリス復号化器２０６およびリードソロモン復号化器２１０によって適切に復号化されるそれらのパケットだけが、データ復号化器２１４に供給されることになる。２／３レートのトレリス復号化器２０６またはリードソロモン復号化器２１０がパケットを復号化することができない場合、受信機は通常、そのようなパケットをエラーパケットとして廃棄する。あまりに多くのエラーパケットが受信される場合、Ａ５３規格に準拠した信号を受信することができる一部の受信機は、送信機との再同期を試みることができる。

Ａ５３規格に準拠した信号は一般に、同軸ケーブルまたは電話線を介した送信を含め無線放送以外の方法で送信することもできることに留意されたい。

既存またはレガシーＡ５３規格は現在、一般に固定された（例えば、家庭などの）受信機であって、送信信号をキャプチャするための大きなアンテナに結合された受信機による使用目的のために信号を生成することおよび送信することを定義している。しかしながら、送信される信号は、ポータブルテレビ、車載テレビ、携帯テレビ、ＰＤＡ(Personal Data Assistant)などで使用される小さなアンテナを有するモバイル受信機または受信機が、上記信号内に符号化されたソースデータを効果的に抽出することができるほど、十分には頑健またはロバストではない。特に、２／３レートのトレリス符号化器によって提供される冗長性は十分ではなく、モバイルアプリケーションのためには、より低レートの符号化器（すなわち、より大きい冗長性を有するもの）が必要である。したがって、モバイル装置、ハンドヘルド装置、および歩行者用装置において進展した受信機とともにより良く動作するように適合された、より強固な符号化処理を提供することが望まれている。

モバイル送信システムのバーストモードの発生およびそのようなモードのデータコンテンツを通信するための発明を開示する。

Ａ５３規格に準拠した信号を送信する典型的な送信システムを示すブロック図である。 Ａ５３規格に準拠した信号を受信する典型的な受信機を示すブロック図である。 本開示の送信装置で使用される符号化器のさらに別の実施形態を示すブロック図である。 本開示の行方向のデータを示すテーブルである。 本開示の列方向のデータを示すテーブルである。 本開示の符号化処理の一実施形態を示すフローチャートである。 本開示の符号化処理の別の実施形態を示すフローチャートである。 本開示のインタリーバにおけるバイトのマッピングを示すテーブルである。 本開示の復号化器の一実施形態を示すブロック図である。 ＶＳＢ−８フレームの一実施形態を示す図である。

本発明の特徴および利点は、例示として提供される以下の詳細な説明からより明らかになる。

本開示の１つまたは複数の特定の実施形態を以下に説明する。それらの実施形態の簡潔な説明を提供するために、実際の実装に関する全ての特徴は本明細書内に説明していない。任意のそのような実際の実装の開発では、システム関連およびビジネス関連の制約の順守など開発者特有の目的に達するように、エンジニアリングまたは設計プロジェクトにおいて様々な実装特有の決定を行うことができ、そしてある実装から別の実装へと変化しうることを理解されたい。さらに、そのような開発の試みは、それでもなお、本開示の利益を受ける当業者にとって設計、製作、および製造を行うルーチンとなるであろうことを認識されたい。

以下に、テレビジョン放送信号、特に、米国での使用のために定義されるような放送信号に関連するシステムを説明する。説明される実施形態をモバイル装置、ハンドヘルド装置または歩行者用装置に使用することができる。使用される装置の例には、携帯電話、インテリジェント電話、ＰＤＡ、ラップトップコンピュータ、およびポータブルテレビが含まれるが、これらには限定されない。他のタイプの信号を送受信するのに利用される他のシステムも、類似の構成および処理を含むことができる。当技術分野の当業者には、本明細書で説明される回路および処理に関する実施形態は単に１組の潜在的な実施形態であることが理解されよう。従って、代替的な実施形態では、本システムのコンポーネントを再配置または削除することができ、またはさらなるコンポーネントを追加することができる。例えば、小さな修正を加えることで、世界のどこかで使用されるサービスを含む衛星ビデオおよびオーディオサービスまたは電話データサービスで使用するために、説明されるシステムを構成することができる。

図３を参照すると、符号化器３００の実施形態のブロック図が示されている。図３に示される復号化器は、ＭＰＥＧトランスポートストリームを修正し、該ストリームをＡＴＳＣ Ａ／５３レガシーシステムの一部として送信されるモバイル送信システム（ＡＴＳＣ Ｍ／Ｈなど）で使用するための送信用に処理するシステムとして動作する。符号化器３００は、ＭＰＥＧトランスポートストリームソース１３０２を含む。ＭＰＥＧトランスポートストリームソース３０２は、複数のさらなるブロックを含むＡＴＳＣ Ｍ／Ｈブロック３１０に接続されている。ＡＴＳＣ Ｍ／Ｈブロック３１０内に含まれるブロックは、入力（incoming）データストリームを処理し、モバイル装置、歩行者用装置およびハンドヘルド装置による受信および使用に適合されたラグド（rugged：頑健な）データストリームを生成する。これらのブロックは以下でさらに説明する。ＡＴＳＣ Ｍ／Ｈブロック３１０は、複数のさらなるブロックを含むＡＴＳＣ Ａ５３レガシーブロック３５０に接続されている。ＡＴＳＣ Ａ５３レガシーブロック３５０内に含まれるデータランダマイザ３５２、リードソロモン符号化器３５４、畳み込みバイトインタリーバ３５６、トレリス符号化器１３５８、同期挿入（sync insertion）ブロック３６０、および変調ブロック３６２は、図１で説明されたこれらのブロックと同様である。したがって、ここではこれらのブロックについて更なる説明はしない。

ＡＴＳＣ Ｍ／Ｈブロック３１０内では、パケットインタリーバ３１２は、パケットに配置されたデータのストリームを受信する。各パケットは１８７バイトを有し、パケットの識別のために使用される３バイトのヘッダを含む。パケットインタリーバ３１２の出力は、ＧＦ（２５６）ＳＣＢＣ（Serial Concatenated Block Coder：直列連結ブロック符号器）３１４に接続されている。ＧＦ（２５６）ＳＣＢＣ ３１４の出力は、パケットデインタリーバ３１６に接続される。パケットデインタリーバ３１６の出力は、トランスポートストリームヘッダモディファイア（transport stream header modifier）３１８に接続される。トランスポートストリームヘッダモディファイア３１８の出力は、アプリオリトランスポートパケット挿入器（a-priori transport packet inserter）３２０に接続されている。アプリオリトランスポートパケット挿入器３２０の出力は、ＡＴＳＣ Ａ５３レガシーブロック３５０に接続される。

パケットインタリーバ３１２は、行に配置されたパケットとして受信されたデータを、パケットの行からバイトの列に基づいたコードワードに再配置する。パケットインタリーバ３１２は、図４に図示されるような行毎の順番で一定数の連続パケットからバイトを取り出し、図５に図示されるように列毎に該バイトを出力する。特に、図４および図５は、１８７バイトの１２行のパケットを読み取り、１８７列の１２バイトのコードワードを出力することを図示している。そのパケットインタリーブの結果として、ＢＹＴＥ０とラベル付けされた複数の第１のバイトの全てが一緒にグループ化され、ＢＹＴＥ１とラベル付けされた複数の第２のバイトの全てが一緒にグループ化されており、以下も同様である。インタリーバに読み込まれるパケットの数は、ソースフレームを構成し、このパケットの数は、ＧＦ（２５６）ＳＣＢＣ ３１４における処理に必要とされるソースのコードワードまたはシンボルの数に等しい。パケットインタリーバ３１２の次元(dimension)は、含まれるメモリのタイプおよびサイズに基づいて変更することができることに留意されたい。例えば、第１の次元を列に変更し、第２の次元を行に変更することができる。さらに、他の次元の配置を使用することもできる。

ＧＦ（２５６）ＳＣＢＣ ３１４は、上述のバイトコード符号化器と同様のブロックコード復号化器である。特に、ＧＦ（２５６）ＳＣＢＣ ３１４は、ガロア域ＧＦ（２５６）空間において短い線形のブロックコードを使用して実装される。２つの構成ブロックコードを使用することができる。レート１／２のブロックコード符号化器は次の生成行列（generator matrix）を使用する。

上記（４）の行列は、第２の列内に式（１）からの値を有するｂ要素を含む。レート１／２のブロックコード符号化器は次の生成行列を使用する。

生成行列は、恒等行列（identity matrix）およびｂ要素の列を使用して形成される。行列（５）の第３の列は、Ｂ１およびＢ２が２に等しいように２の値を有する式（２）および式（３）からのｂ要素を含む。各構成コードに対する生成行列の係数は、エラー修正システム全体および変調処理へのブロックコード符号化の関係に基づいて最適化されていることに留意されたい。最適化は、特に８−ＶＳＢ変調におけるトレリス符号化およびビットとシンボルのマッピングを考慮しているが、これは、それらの態様が受信および変調処理の第１の態様であるからである。

ＧＦ（２５６）ＳＣＢＣ ３１４は、単一のブロックコード符号化器または連結されたブロックコード符号化器である。連結されたブロックコード符号化器は、上述したようにインタリーブおよびパンクチャリング(puncturing)などの他の機能を含むことができる。ＧＦ（２５６）ＳＣＢＣ ３１４は、多くの符号化レートで符号化することもでき、さらに、図示していないレートモードコントローラを介してレートモードを切り替えることができる。好ましい実施形態ではＧＦ（２５６）ＳＣＢＣ ３１４を、上述したレート１／２の構成コードの１つ、すなわちレート１２／２６コード、レート１２／５２コード、またはレート１７／２６コードを使用してデータの入力ストリームを符号化するように適合することができる。

ＧＦ（２５６）ＳＣＢＣ ３１４は、インタリーバ３１２から出力された列に沿ってバイトを符号化する。言い換えると、ＧＦ（２５６）ＳＣＢＣ ３１４は、パケットインタリーバ１３１２内の処理を通じて形成されたインタリーバ行列の第２の次元に従って符号化する。

パケットデインタリーバ３１６は、ＧＦ（２５６）ＳＣＢＣ ３１４によって生成されたコードワードの符号化ストリームを受信し、１８７バイトのパケットの再構成された行を出力する。パケットデインタリーバ３１６は、ＧＦ（２５６）ＳＣＢＣ ３１４内の処理によって追加された冗長バイトまたは非系統的（non-systematic）バイトを含む各列とともに、列順で列に符号化コードワードを入力し、行毎の配置でバイトを出力する。その処理は、基本的には、図４および図５の順を逆にすることによる、パケットインタリーバ３１２について説明した処理の逆である。パケットデインタリーバ３１２は、コードワードの同じ数の列を入力し、ここで各コードワードは、符号化された非系統的バイトのセットを含む。その出力における行の数は、符号化コードワードの長さに対応する。例えば、１２／２６コードレートにおいては、２６行のパケットが出力される。パケットデインタリーバ３１６の次元を、含まれるメモリのタイプおよびサイズに基づいて変更することができることに留意されたい。さらに、第１の次元を行に変更することができ、第２の次元を列に変更することができる。加えて、他の次元の配置を使用することができる。

パケットを２つの別個のグループに配置することができる。パケットの第１のグループは、系統的（systematic）パケットと称することができ、トランスポートストリームソース３０２によって提供される最初のデータパケットと同じである。パケットの第２のグループは、非系統的パケットと称することができ、ＧＦ（２５６）ＳＣＢＣ ３１４でブロック符号化処理によって形成されるパリティパケットである。ブロック符号化処理の結果として、列の数（すなわち、第２の次元のサイズ）が増加されていることに留意されたい。

ＭＰＥＧトランスポートストリームヘッダモディファイア３１８は、系統的パケットおよび非系統的パケットのグループを含む、非インタリーブ化された１８７バイトのパケットを受信する。上述したように、各パケットは３バイトのヘッダを有する。その３バイトのヘッダは、そのパケットに関する情報を伝送するのに使用される複数の他のビットまたはビットのグループとともに、ＰＩＤを含む。レガシーまたはＡ５３放送信号を受信することができるが、ＡＴＳＣ Ｍ／Ｈ符号化パケットを正しく復号化することができない受信機（例えば、レガシー受信機）の最も効率的な動作を維持するために、ＡＴＳＣ Ｍ／Ｈ符号化パケットの一部分のヘッダ内の特定のビットを変更することができる。非系統的パケットヘッダ内のそれらのビットを変更することにより、レガシー受信機は、パケットを無視するが、破損として該パケットを考慮しない。例えば、ＭＰＥＧトランスポートストリームヘッダモディファイア３１８は、ＴＥＩビット、ペイロードユニット開始インジケータビット、およびトランスポート優先ビットを、「０」のビット値にセットすることができる。さらに、スクランブル制御（scrambling control）および適応フィールドビット（各２ビット）を「００」にセットすることができる。また、３ビットの長さの連続カウンタを「０００」にセットすることができる。最後に、ＰＩＤを、全てのレガシー受信機によって無視される公知の値など、一意の使用されていない値にセットすることができる。ＭＰＥＧトランスポートストリームヘッダモディファイア３１８は、非系統的パケットのグループに対して各ヘッダを変更するので、ＧＦ（２５６）ＳＣＢＣ ３１４が非系統的パケットのグループに対してヘッダを処理する必要はないことに留意されたい。さらに、ＭＰＥＧトランスポートストリームヘッダモディファイア３１８は、系統的パケットがレガシー受信機によって処理されず、正しく復号化されない場合、該系統的パケットのヘッダを変更することもできる。系統的パケットがＧＦ（２５６）ＳＣＢＣ符号化器３１４によって符号化されない場合、またはＭＰＥＧトランスポートストリームヘッダモディファイア３１８によって処理されない場合、結果のデータストリームは、モバイル装置およびレガシー受信機の両方に同時放送され、その両方によって受信され得る。

アプリオリトランスポートパケット挿入器３２０は、所定のトラッキングパケットをラグドデータストリーム内に配置することができる。その所定のパケットは、モバイル装置、歩行者用装置、またはハンドヘルド装置で使用される受信機などのラグドデータストリームを受信することができる受信機に完全にまたはよく知られている、情報のパケットを表す。その所定のパケットは、受信機において使用されて、レガシーまたは既存のＡ５３符号化部分が信号を符号化し送信する間に作成されるトレリス状態の復号化を補助する。その所定のパケットは、受信機のイコライザ（equalizer）部分の収束（convergence）を補助することもできる。所定のパケットは、レガシー受信機における受信を改善するようには意図されていないが、潜在的な改善をもたらすことができることに留意されたい。また、従来のトレーニング情報とは異なり、該所定のパケットは追加のレガシー符号化を行う前に追加されるので、該所定のパケットは、送信機の出力で直接識別することはできない。特に、所定のパケットは、トレリス符号化の処理によって変更される。したがって、該所定のパケットは、トレリス符号化の間には直接のトレーニングを提供せず、むしろトレリス符号化マップまたは分岐を決定する際に使用されるアプリオ分岐情報（a priori branch information）を提供する。

所定のトラッキングパケットを、公知のトレーニングシーケンス処理を使用して多くの方法で生成することができる。好ましい実施形態においては、所定のトラッキングパケットは、受信機に対しても知られている擬似乱数（ＰＮ：pseudo-random number）ジェネレータを使用して生成される残りのバイトを有する有効なヘッダを含む。アプリオリトレーニングデータ、トレリスで隠された（trellis-obscured）トレーニングデータ、または擬似トレーニングパケットと呼ばれることもある所定のトラッキングパケットを、ＡＴＳＣ Ｍ／Ｈ送信を通していくつかの方法で分配することができ、またはＡＴＳＣ Ｍ／Ｈ信号送信のための前置き（preamble）として作用するようにパケットまたはパケットのグループを配置することを含め、グループにクラスタ化することができる。

レガシーＡＴＳＣ符号化器３５０は、上述したようにレガシーＡ５３規格に準拠する系統的パケットおよび非系統的パケットを同じにように符号化する。ラグドデータストリームまたはロバストデータストリームを生成するＡＴＳＣ Ｍ／Ｈブロック３１０の追加の機能を、最小限の変更で送信機器の既存のハードウェア構成に追加することができる。さらに、ＭＰＥＧトランスポートソース３０２からの入力パケットの一部分を、ＡＴＳＣ Ｍ／Ｈブロック３１０において１つまたは複数の符号化レートで符号化するために抽出することもできる。符号化されたパケットを、次いで入力パケットの残りの未処理の部分に再挿入または付加することができ、符号化された部分および未処理の部分の両方をレガシーＡＴＳＣ符号化器３５０で符号化することができる。代替的には、パケットの個々のストリームをＡＴＳＣ Ｍ／Ｈブロック３１０に提供することができ、その符号化された出力を、パケットの第２のストリームに挿入または付加してＡＴＳＣ符号化器３５０に供給することができる。

図６に移ると、図６には、一実施形態の符号化処理６００を示すフローチャートが示されている。処理６００は、データの入力ストリームからラグドデータストリームを生成するのに使用することができる、連結されたバイト−コード符号化処理を図示している。処理６００は主として、連結されたバイト−コード符号化器との関連で説明される。しかしながら、処理は任意のバイト−コード符号化器に容易に適合させることも可能である。処理６００を、個々の処理ブロックを含むハードウェア、あるいは必要なブロックの一部または全てを含む集積回路を含むハードウェアを使用して、マイクロプロセッサ装置において動作するソフトウェアを使用して、またはハードウェアとソフトウェアの両方の組み合わせを使用して実行することができる。さらに、処理６００はバイト、コードワード、およびデータのパケットとの関連で説明される。しかしながら、他のデータ構成または配置が可能であり、これらを使用できることを当業者は認識されたい。

まず、ステップ６１０では、データのストリームが受信される。該データのストリームは、データのバイトをコードワードとしてグループ化することができるように配置され、さらに、１つまたは複数のコードワードの全てまたは一部を含むパケットに配置され得る。例えば、該データを、各パケットが識別ために使用されるパケットヘッダを含む、１８７バイトのデータを含むパケットに配置することができる。次に、ステップ６２０では、データのパケットがバイト−コードに符号化される。ステップ６２０の符号化を、上記した構成の符号化器のうちのいずれか１つを使用して実行することができる。例えば、符号化ステップ６２０は、１２の入力バイトのデータ毎に１８バイトのデータを出力する、レート２／３のバイト−コード符号化を使用することができる。代替的に、この符号化ステップは、レート１／２などの別のバイト−コード符号化レートを使用することもできる。入力データを補うことには、バイトコード符号化処理またはブロックコード符号化処理などの符号化処理を通じてエラー修正または冗長データバイトを作成することが含まれる。出力バイトは、６バイトの冗長データまたは非系統的データとともに、系統的バイトとして知られる１２入力バイトのデータの複製を含む。

次に、ステップ６３０では、ステップ６２０からの符号化データバイトがインタリーブされる。インタリーバのサイズを最適化して、ホワイトノイズ（white noise）の存在においてバイトエラーレートを低減することができる。次に、ステップ６４０では、ステップ６３０によりインタリーブされたバイトが、２回目のバイト−コード符号化される。その第２のバイト−コード符号化ステップ６４０を、上述の構成符号化器のうちのいずれか１つを使用して実行することができる。例えば、ステップ６２０の符号化は、１８入力バイトのデータ毎に２７バイトのデータを出力することになるレート２／３のバイト−コード符号化を使用することができる。代替的に、該符号化ステップは、レート１／２などの別のバイト−コード符号化レートを使用することができる。出力バイトは、９バイトの冗長データまたは非系統的データとともに、系統的バイトとして知られる１８の入力バイトのデータの複製を含む。一部の系統的バイトは元の入力データのバイトのうちのいずれか１つの複製とすることができ、または第１のバイト−コード符号化ステップ６２０によって冗長バイトまたは非系統的バイトとして展開されたバイトとすることもできることが明らかである。

次に、ステップ６５０では、バイトデータの第２の符号化ストリームがパンクチャリングされる。パンクチャリングステップ６５０は、第２の符号化ストリームからのデータのバイトのうちのいずれか１つを削除する。削除されるバイトは、第２の符号化ステップ６４０の非系統的バイトとすることができ、さらに、第１の符号化ステップ６２０からの非系統的バイトとすることもできる。最後に、ステップ６６０では、データストリームは、レガシーまたは既存のＡ５３符号化などの追加の処理のために提供される。ステップ６６０は、データストリームを提供する前に、符号化バイトを、最初に受信された配置と同様のパケットに再パケット化することを含むことができる。説明される処理６００の結果、レート１２／２６のバイト−コード符号化データストリームが生成される。

処理６００にとってステップ６５０のパンクチャリングはオプションである。削除するバイトの選択は、ステップ６３０におけるインタリーブに基づいて行われる。例えば、第２の符号化ステップ６４０がその符号化の一部として非系統的バイトのうちの１つを生成することができず、直接パンクチャリングされたストリームになることがあり得る。さらに、パンクチャリングステップ６５０をバイパスして、パンクチャリングされていないレート１２／２７のバイト−コード符号化データストリームを生成することもできる。

ステップ６５０のパンクチャリングは、第２の符号化ストリームから１超のバイトを削除することもできる。例えば、削除することができる３バイトを識別して、レート１２／２４のバイト−コード符号化データストリームを生成することが可能である。１超のバイトをパンクチャリングすることは、符号化の有効性を低下させることとなるが、符号化レートの向上を図ることができる。パンクチャリングステップ６５０における追加バイトの削除は、ステップ６３０における最適なインタリーブに基づいて達成することができる。このように、パンクチャリングおよびインタリービングのやりとりは、所与の出力ブロックのサイズの出力パケットの生成に基づいた最適なコードレートを可能にする。

ステップ６３０およびステップ６４０を、２つのインタリーブステップおよび３つのバイト−コード符号化ステップを含む異なる連結バイトコード符号化処理を形成するために、繰り返すことができる。繰り返されるステップ６３０およびステップ６４０を用いた処理を使用して、レート１２／５２のラグドデータストリームを生成することができる。処理６００を、上述のような他のコードレートに容易に適用させることもできる。

図７に移ると、図７には、別の実施形態の符号化処理７００を示すフローチャートが示されている。処理７００は、既存またはレガシーＡ５３信号フォーマットに準拠する系統的パケットおよび非系統的パケットまたは冗長データパケットを含む、ＡＴＳＣ Ｍ／Ｈデータストリームを符号化して送信するためのステップを示している。処理７００は主として、図３の符号化器３００に関連して説明される。上記のように、処理７００を、個々の処理ブロックを含むハードウェア、あるいは必要なブロックの一部または全てを含む集積回路を含むハードウェアを使用して、マイクロプロセッサ装置において動作するソフトウェアを使用して、またはハードウェアとソフトウェアの両方の組み合わせを使用して実行することができる。正確な必要とされる実装に基づいて、所定のステップを削除または再配置することによって処理７００を適合させることができることに留意されたい。

まず、ステップ７１０では、パケットのトランスポートストリームが受信される。各パケットは、１８７バイトを有し、ヘッダを含む。ヘッダは、ＰＩＤ、ならびにパケットに関する他の情報を含む。次に、ステップ７２０では、ＡＴＳＣ Ｍ／Ｈパケットに使用されるように識別されるパケットが、分離または抽出される。残りのパケットは未処理として識別される。ＡＴＳＣ Ｍ／Ｈパケットを、組み合わされた単一のトランスポートストリームから抽出する代わりに、パケットの個々の入力トランスポートストリームとして提供することもできる。さらに、トランスポートストリーム内の全てのパケットをＡＴＳＣ Ｍ／Ｈパケットとして識別することができる。それらの条件のいずれかが抽出ステップ７２０の必要性を除去することがある。さらに、ＡＴＳＣ Ｍ／Ｈパケットおよび未処理パケットのいずれかとして識別されたパケットをグループ化することができ、該ＡＴＳＣ Ｍ／Ｈ識別されたパケットを、別個の符号化コード−レートによってさらに識別してグループ化することができる。

次に、ステップ７３０では、ＡＴＳＣ Ｍ／Ｈで識別されたパケットのセットまたはグループが、行として読み込まれるか、または入力され、そして列またはインタリーブされたパケットとして出力される。出力データの列は、各コードワードがパケットのグループのサイズと等しいサイズを有するコードワードと同等である。図１４および図１５は、ステップ７３０で行を読み取って列を出力するパケットのインタリーブを示すマトリックスを図示している。ステップ７３０で使用されるインタリーバの次元を、例えば、列を入力して行を出力するように変更すること、あるいはインタリーバの実装に基づいて任意の他の次元の態様を使用するように変更することができる。次に、ステップ７４０では、ステップ７３０からの各コードワードがブロックコード符号化される。ステップ７３０のブロックコード符号化は、処理６００のバイト−コード符号化に類似しており、単一符号化処理または連結された符号化処理のいずれかを使用することができる。例えば、ブロックコード符号化ステップ７３０は、レート１／２の構成コード、レート１２／２６のコード、レート１２／５２のコード、またはレート１７／２６のコードを使用してコードワードを符号化することができる。

次に、ステップ７５０では、符号化されたコードワードのセットは、コードワードを列として入力し、データパケットを行として出力することによって、パケット非インタリーブ化される。入力コードワードはここで、ステップ７３０のブロックコード符号化によって生成されたバイトの数を含んでいる。出力パケットは、１８７バイトを有するパケットに再構成される。ブロックコード符号化ステップ７３０で生成された非系統的バイトは、符号化されたデータのストリームにおいてパケットの追加の行を構成する。ステップ７６０で使用されるデインタリーバの次元を、例えば、列を入力して行を出力するように変更すること、あるいはインタリーバの実装に基づいて任意の他の次元の態様を使用するように変更することができる。

次に、ステップ７６０では、符号化された非インタリーブ化パケットのヘッダバイトが変更される。ステップ７６０の変更は、ヘッダ情報がレガシー受信機によって認識されることを防ぐことにより、ＡＴＳＣ Ｍ／Ｈデータパケットを復号化することができない受信機での性能問題を防ぐ方法を提供する。変更ステップ７６０は、ＴＥＩビット、ペイロードユニット開始インジケータビット、およびトランスポート優先ビットを、「０」のビット値にセットすることを含むことができる。変更ステップ７６０は、スクランブル制御ビットおよび適応フィールドビット（各２ビット）を「００」にセットすることを含むこともできる。変更ステップ７６０は、３ビットの長さの連続カウンタを「０００」にセットすることを含むこともできる。最後に、変更ステップ７６０は、ＰＩＤを、全てのレガシー受信機によって無視されることとなる公知の値など、一意で未使用の値にセットすることを含むことができる。ヘッダバイトを無視して符号化ステップ６４０では処理しないこともできることに留意されたい。

ステップ７７０では、所定のパケットまたはアプリオリトラッキングパケットが、変更されたヘッダ情報を含む符号化パケットのストリームに挿入される。アプリオリトラッキングパケットの挿入は、ＡＴＳＣ Ｍ／Ｈまたはモバイルビデオ符号化信号を受信することができる受信機の性能を改善する。挿入ステップ７７０は、既存の冗長パケットまたは非系統的パケットを配置することができ、あるいはデータパケットのストリーム内にヌルパケットとしてステップ７１０で最初に提供されたパケットを配置することができる。

ステップ７８０では、ステップ７７０からのＡＴＳＣ Ｍ／Ｈ符号化パケットが、データのトランスポートストリームの未処理の部分と組み合わされる。ＡＴＳＣ Ｍ／Ｈ符号化パケットを、データパケットのトランスポートストリームの以前に識別された未処理の部分に挿入または付加することができる。代替的に、ステップ７７０からのＡＴＳＣ Ｍ／Ｈ符号化パケットを、レガシーの放送の受信のみについて識別された第２のトランスポートストリームに挿入または付加することができる。ステップ７１０で全てのパケットがＡＴＳＣ Ｍ／Ｈデータパケットとして識別され処理されていた場合は、ステップ７８０を削除することもできることに留意されたい。次に、ステップ７９０では、全てのパケット、すなわち、符号化されているかまたは符号化されていないＡＴＳＣ Ｍ／Ｈを含む、完全なデータストリームが、Ａ５３規格に準拠したレガシーまたは既存の符号化を使用して処理される。ステップ７９０のレガシー符号化には、リードソロモン符号化、ランダム化、インタリーブ、トレリス符号化、および同期挿入が含まれる。レガシー符号化ステップ７９０を、レガシー符号化器３５０内に示されるようなブロックによって実行することができる。

最後に、ステップ７９５では、ＡＴＳＣ Ｍ／Ｈデータとして符号化されたストリームの全てまたは一部を含む、完全に符号化されたデータストリームが送信される。送信ステップ７９５は、特に識別された周波数範囲を使用して送信することを含むことができ、同軸ケーブルなどの有線技術を使用して送信すること、または放送波で電磁的に送信することを含むことができる。ＡＴＳＣ Ｍ／Ｈデータを連続的に送信することができることに留意されたい。このモードでは、ＡＴＳＣ Ｍ／Ｈ系統的パケットは、レガシー受信機におけるデータパケットとしても機能する。非系統的パケットは、無視されることとなる。しかしながら、別個のＡＴＳＣ Ｍ／Ｈデータおよびレガシーデータを、ＡＴＳＣ Ｍ／Ｈデータが周期的に送信される方法で、または短い不連続期間に連続的に送信される方法で送信することもできる。

図８を参照すると、本発明の例示的な実施形態かかる、畳み込みバイトインタリーバ３５６の後の送信フレームにおけるデータブロックの位置を示す図が示されている。より具体的には、インタリーバマップ（interleaver map）８００は、図３の畳み込みバイトインタリーバの処理中のデータの入力バイトの構成を図示している。畳み込みバイトインタリーバ３５６は、一連の遅延線（delay line）を使用して実装することができるが、インタリーバマップ８００は、インタリーバのメモリマップ（memory map）とみなされることもある。

インタリーバマップ８００は、配置されるかまたは書き込まれた入力バイトの位置、および出力バイトがどのように読み出されるかを示す。インタリーバマップ８００の次元は、０から２０８まで番号付けされた上端のバイトと、０から１０３まで番号付けされた上端から下端に沿ったセグメントの行として示されている。破線８０５は、バイトが読み出される順番を示している。例えば、ライン８０５は行２０を表すので、行２０のバイトの全ては、バイト０で開始してバイト２０８で終了するように読み出される。最後のバイト、すなわちバイト２０８が行２０から読み出されると、読み出しは、インタリーバの最後の行が読み出されるまでは１行進み、行２１になる。その最後の行が読み出されると、読み出しは（新しいパケットデータの）第１の行の読み出しを始める。

ライン８１３は、２０７バイトのリードソロモンコードワードの最初の５２バイトの位置を示し、これはバイト畳み込みバイトインタリーバ３５６へのそれらのバイトにおける読み出しに基づいている。ライン８１３は、パケットのバイト０の位置で開始し、センタライン８４０のバイト５１の位置で終了する。ライン８１５、８１７、８１９ａ、８１９ｂは第１のパケットの残りのバイトの位置を示している。ライン８１５はラインの上端のバイト５２の位置で開始し、他ラインも同様であり、ライン８１５、８１７、８１９ａの各々のバイト位置で処理する。バイトの残りの部分はライン８１９ｂに沿って位置され、ライン８４０の下の行の位置のバイト２０８で終了する。連続するパケットのバイトの位置は、第１のパケットの位置の左に続き、ライン８４０の上の進行および位置をミラーリングするライン８４０より下のマップの部分に処理する。例えば、ライン８５０は畳み込みバイトインタリーバ３５６における５２番目のパケット（第１のパケット後に５２パケット入力するパケット）のバイトの部分の位置を示している。ライン８５３は、グループ化パケットの送信のための境界線を図示している。各連続パケットでは、そのパケットから次の連続するバイトはその境界線に位置する。したがって、ライン８５３は、パケット０、バイト０の位置の後にパケット１、バイト１の位置が続き、そして同様に続いてパケット５２、バイト５２の位置までを表している。

畳み込みバイトインタリーバ３５６および同期挿入部（Sync Insertion）３６０の後のＭ／Ｈデータブロックにおけるデータの位置を、以下に説明する。同期データは、畳み込みバイトインタリーバ３５６の後に同期挿入部３６０で挿入されるので、同期データはインタリーブされないことに留意されたい。図８は、各々が１つの行によって表される１０４のデータセグメントのシーケンスを図示している。この例において、上方くさび形状部８２０は、データブロック８およびデータブロック９を表している。下方くさび形状部８３０は、データブロック０およびデータブロック１を表している。中央ダイアモンド形状部８１０は、データブロック２１０およびデータブロック２１５を表している。ライン８４０は、同期挿入部３６０によって挿入されるべき同期データを表している。

図８に図示されるように、プリアンブルデータの最終バイトは、バイトインタリーバ３５６のためにほぼ５２データセグメントによって遅延されることとなる。したがって、２ブロック長のプリアンブル（すなわち、５２パケット）からのデータ（５２のインタリーブされたデータセグメントと同じ量のデータ）は、インタリーブされたＡＴＳＣ Ａ／５３送信ストリームにおいて１０４データセグメントの比較的短い範囲内にのみ広がる。これは、Ｍ／Ｈ受信機が所望の短い時間期間内にインタリーブされたプリアンブルデータを復号化するのを助ける。上記したように、早急に復号化されたプリアンブルデータを、Ｍ／Ｈデジタルテレビジョン信号の受信の改善のために使用しても良い。要約すれば、適切な長さのプリアンブルは、プリアンブル情報の復号化を含め、信号の処理をスピードアップするのに重要である。

パケットのセットの或る特定の配置により、ロバストデータストリームのより最適な送信配置を提供することができる。ロバストデータストリームが連続して送信されない（すなわち、データストリームの一部がレガシーデータである）場合、ロバストデータストリームの配置は重要であり得る。例えば、５２パケットのセットは、図８に図示されるように、受信システムにおいて非インタリーブ化の処理を使用して容易に予測し識別することができる方法でロバストデータを送信することを含む、送信の特性（transmission characteristic）になる。

図９に移ると、受信機システムにおいて使用される復号化器９００の実施形態のブロック図が示されている。復号化器９００は、上述のようなデータストリームの非系統的パケットなどの冗長パケットを使用するように適合された回路を含む。復号化器９００は一般に、レガシーまたは既存のＡ５３規格を使用して符号化されたデータを復号化することもできる。

復号化器９００において、初期チューニング、復調、および他の回路（図示せず）による処理に続いて、トレリス復号化器９０２は入力信号を受信する。トレリス復号化器９０２は畳み込みデインタリーバ９０４に接続されている。バイト−コード復号化器９０６は、リードソロモン復号化器９０８に接続される出力を有する。リードソロモン復号化器９０８の出力は、デランダマイザ９１０に接続される。デランダマイザ９１０の出力は、データ復号化器９１２に接続される。復号化器９１２は、ビデオ表示またはオーディオ再生など、受信機システムの残りの部分で使用するための出力信号を提供する。トレリス復号化器９０２、デインタリーバ９０４、リードソロモン復号化器９０８、デランダマイザ９１０、およびデータ復号化器９１２は、図２で説明されたブロックと機能において同様であり、ここでさらには説明しないこととする。

データパケットのバイトデータの形式で受信されたデータは、トレリス復号化器９０２によって復号化され、デインタリーバ９０４によって非インタリーブ化される。データパケットは、２０７バイトのデータを含むことができ、該データパケットをさらに、複数のグループに、または２４、２６、もしくは５２のパケットにグループ化することができる。トレリス復号化器９０２およびデインタリーバ９０４は、入力のレガシーフォーマットのデータ、ならびにバイト−コード復号化されたデータを処理することができる。受信機が知っている所定のパケット送信シーケンスに基づいて、バイト−コード復号化器９０６は、パケットがバイト−コード復号化データストリームまたはロバストデータストリームに含まれるパケットであるか否かを判断する。受信されたパケットが、バイト−コード復号化データストリームからのものでない場合、該受信されたパケットは、バイト−コード復号化器９０６で更なる処理をすることなくリードソロモン復号化器９０８に供給される。また、バイト−コード復号化器９０６は、復号化中にそのデータストリームによって乗算される既知の定数のシーケンス、またはそのデータストリームに加算される既知の定数のシーケンスを削除するデランダマイザを含むことができる。ラグドデータストリームは、元のデータに等しい系統的パケットおよびバイトと、冗長データを含む非系統的パケットおよびバイトとの両方を含むことに留意されたい。

バイト−コード復号化器９０６は、ロバストデータストリームまたはラグドデータストリームに属するバイト−コード復号化パケットが受信されたと判断した場合、そのパケットを、同じデータストリームを備える他のパケットとともに復号化することができる。一実施形態において、同じデータストリームのバイト−コード復号化パケットは、上記の式(（２）で示したように、バイト−コードパケットを展開するのに使用されたｂ要素の値の逆の値でパケット内の各バイトを乗算することによって、復号化される。非系統的パケットのバイトの復号化された値を系統的パケットのバイトの値と比較して、同じではないその２つのパケット内の任意のバイトの値を、系統的パケットにおいて消去（すなわち、ゼロにセット）することができ、あるいは該任意のバイトの値を、非系統的パケットにおいて情報によって置き換えることができる。その後、消去されたエラーバイトを有する系統的パケットを、リードソロモン復号化器９０８で実行されるリードソロモン復号化を使用して復号化することができる。さらに、バイト−コード復号化器の他の実施形態の説明を以下に説明する。

バイト−コード復号化器９０６を、信号を復号化するためのブロックコーダとして動作するように適合することもできる。例えば、バイト−コード復号化器９０６は、パケットインタリーバ３１２と類似したパケットインタリーバと、パケットデインタリーバ３１６と類似したパケットデインタリーバとを含むことができる。加えて、バイト−コード符号化機能は、ＧＦ（２５６）ＳＣＢＣ（Serial Concatenated Block Coded）信号を復号化するように適合されることができる。さらに、バイト−コード復号化器９０６は、モバイル受信（mobile reception）もしくはＡＴＳＣ Ｍ／Ｈ受信のため、および／またはアプリオリトレーニングパケットの識別のために符号化されたデータを識別するのに使用される識別子ブロックを含むこともできる。加えて、識別子ブロックは、例えば、入力パケットのヘッダがモバイル受信に使用されるＰＩＤを含むか否かを判断するためのパケット識別子ブロックを含むことができる。

バイト−コード符号化は、データパケットのリードソロモン符号化に先行して行うこともできることに留意されたい。しかしながら、本明細書に示される復号化器９００では、入力データはリードソロモン復号化される前にバイト−コード復号化される。バイト−コード動作およびリードソロモンコード動作の両方が、Ａ５３規格で使用されるガロア域ＧＦ（２５６）において線形であり、線形演算子がガロア域で可換（commutative）であるので、並べ替え（re-ordering）は可能である。バイト−コード符号化が、受信信号におけるエラーの回復についてより高い信頼性を提供し、そしてバイトコードが、効率的なソフト符号化アルゴリズム（soft encoding algorithm）を可能にするため、並べ替えの重要性は重要である。したがって、リードソロモン復号化の前にバイト−コード復号化を行うことにより、ビットのエラー率、および信号とノイズの比に関して測定される受信機の性能が改善される。

さらに、図３の符号化器３００の実施形態の説明のように、バイト−コード復号化要素および処理を、レガシー受信機に対する最小限の変更で、該レガシー受信機において必要とされ使用される要素、コンポーネント、および回路に追加することができることに留意されたい。しかしながら、バイト−コード復号化処理の特徴をレガシー受信機における他のブロックに組み込むことによって、復号化処理を向上させることができる。

上述されるバイト−コード符号化および復号化の配置を用いる様々なシステムは、既存またはレガシー放送システムの適用の拡張を可能にする。第１に、既存のレガシー受信機はＡＴＳＣ Ｍ／Ｈを使用して符号化されたパケットの更なる存在から利益を得ることができる。よりロバストなＳＣＢＣ符号化パケットおよびアプリオリトラッキングパケットを、トレリス復号化器およびイコライザによって処理して、動的な信号環境状態におけるトラッキングを改善することができる。第２に、ロバストデータまたはラグドデータを作成するＡＴＳＣ Ｍ／Ｈ符号化データは、モバイル装置、ハンドヘルド装置または歩行者用装置の受信システムが、レガシーＡ５３送信を受信することができない信号環境においてロバストストリームを受信できるようにする。例えば、レート１２／５２のＡＴＳＣ Ｍ／Ｈ符号化は、レガシーＡ５３受信の約１５デシベル（ｄＢ）のホワイトノイズ閾値を比べると３．５ｄＢに等しいホワイトノイズ閾値での信号受信を可能にする。レガシーＡ５３データとともに周期的な方法でＡＴＳＣ Ｍ／Ｈパケットを生成しそのパケットを送信することによって、動作はさらに向上する。周期的な送信は、放送教材（broadcast material）のビデオおよびオーディオ配信を許可にするのに重要である。ＡＴＳＣ Ｍ／Ｈパケットを、１つまたは複数の送信バースト（transmission burst）としてグループ化して送信することもできる。モバイル装置、ハンドヘルド装置または歩行者用装置による後の使用のために格納され得るデータコンテンツまたはコンテンツの配信のためにバーストでの送信は重要である。

そのような周期送信の送信は、「バーストモード」として知られ、実質的には図３の送信システムが、レガシーＡ５３送信において（例えば、図８に示したエリア内）周期的な間隔でＡＴＳＣ Ｍ／Ｈ情報を送信することを可能にする。すなわち、ＡＴＳＣ Ｍ／Ｈシステムで使用される受信機は、受信したＡＴＳＣ Ｍ／Ｈの送信を常にトラッキングする訳ではなく、したがって受信機は、符号化データペイロードを短い時間間隔を獲得して受信するように構成されることが可能である。一部の場合には、これらの「バーストモード」はデータペイロードの連続的な送信である。他の場合には、「バーストモード」はデータペイロードの低頻度での送信である。

加えて、送信されているデータペイロードのタイプは、受信機がどのバーストモードに関心があるかに影響する可能性がある。例えば、あるバーストモードは、信号同期およびチャネル獲得の機能において受信機を補助するプリアンブルとして送信されるデータパケットを有することができる。他のバーストモードは、特定のタイプのビデオ／オーディオプログラミングが受信機に送信されるところで動作することができ、そのようなプログラミングを後で見るためにキャッシュすることができる。

理想的には、バーストモードは、上記したように、標準ＭＰＥＧデータパケット（１８７バイトと２０のリードソロモンバイト）の動作に基づいて２６パケットに等しい標準の時間ブロックスライスを使用する。２６パケットから構成されるブロックを用いるサイズは、モバイルデータの２ミリ秒を表し、インタリービングの後、送信の４ミリ秒の間に広がることが予期される。バーストモード動作に関連付けられた情報の送信は、２６パケットの倍数を表現している。そのような２６パケットの倍数を無期限にまたは有限の期間の間送信するように、図３の送信システムを構成することもできる。

図３の送信システムはさらに、バーストモードのタイミング、バーストモードのコンテンツ、およびそのようなバーストモードの期間を示す受信機に、情報を中継するように構成することができる。この情報を通信するための１つのアプローチは、１３バイトを表す１０４の予約シンボル（reserved symbol）（各シンボルは１ビットを表す）を有する図１０に示されるようなＶＳＢ−８フレームに使用されるフィールド同期において存在する、１０４の予約シンボルにそのような情報を挿入することである。様々な実施形態において、使用されるシンボルは、１ビットより長いサイズを有し、したがって以下に示されるものよりも大きいアレイの値となることが考えられる。

表１は、１０４の予約シンボルをどのように割り当てることができるかを示すサンプルの分析である。第１のバイトは、受信されているデータが、バーストモード用であるかどうか、例えば、「０００００００１」であるかまたは「００００００００」でないかを表す。第２から第３のバイトは、いくつの連続パケットがバーストバケットとするかを表す。オプションとして、第２のバイトおよび第３のバイトの値を全て「１」にセットして、値が「０」にセットされるまでバーストパケットが無期限で続くことを示すこともできる。

サンプルの第４のバイトの値は表２に示されており、表２では異なるサンプル値が示されている。

表３は、第６のバイトのバーストモードにおける番組コンテンツを示すサンプル値を開示している。

第７のバイトは、受信されている情報用に使用する符号化のタイプを示す。（１０進法フォーマットで示される）それらの値の様々な例が、表４に開示されている。

第８のバイトおよび第９のバイトは、バーストモードの情報が関連付けられる特定の放送チャネル(１−２^１６)を示すのに予約されている。好ましい実施形態においては、使用されるチャネルは、ＡＴＳＣ Ａ／５３を用いる放送チャネルに使用されるチャネルの番号に対応する。同様に、第１０のバイトは、特定のサブチャネルを表すことができ、その番号は好ましくはＡＴＳＣ Ａ／５３で用いられるサブチャネル番号に対応する。第１１のバイトは、バーストモードの符号化レート（１／２、３／４など）に関する送信情報など、将来の動作のために予約されている。

オプションの実施形態においては、第１１番目を、時間値を表すように構成することができ、該時間値は、バーストモードが実装される次の時を表す。これはバーストモードが連続的なブロックを備えないシナリオを説明する。このオプションの実施形態の観点で、送信されるべきバーストモードについて異なるものを表すために異なる値を使用する他の例示を実装することができる。

代替の実施形態においては、１０４の予約シンボルがセグメント同期に分割され、この場合、予約シンボルの１２がアプリオリデータセグメントからの最後の１２セグメントに対応するので、９２シンボルだけが利用できるようになる。この場合、予約シンボルのレート情報およびバーストモード発生情報を示す制御パッケージのタイプとしてセグメント同期を用いることができ、そして（表１〜表４に説明されたように）バーストモードのコンテンツなどの情報および／またはバーストモードに関する追加の情報を示すデータセグメントのペイロードを用いることができる。

上記の例を踏まえて、フィールド同期における予約シンボルの割り当て方法の他の構成を実装することができる。代替的に、ＭＰＥＧ−２トランスポートストリームの一部として復号化されるＰＩＤ値を使用することによりバーストモード情報を通信することができ、そのようなＰＩＤ値を、同期ブロックに関して示された上記の様々な値を表すように定めることができる。

さらなるオプションの実施形態においては、本発明の原理は携帯電話、ラップトップコンピュータなどのモバイル装置に適用されるので、バーストモード情報の使用により、送信を受信するためにパワーアップまたはダウンすべきときをポータブル装置に示すことができる。すなわち、コンテンツが（ユーザプロファイルに鑑みて）ユーザにとって興味がないものであるとき、装置はバーストモード送信のコンテンツを前もって知ることになるため、該装置は、そのバーストモードのコンテンツを無視する。例えば、図３の情報を参照することによって、ユーザがテレビ番組に興味がなく、オーディオ送信だけを好むとき、装置は（第１のバイト〜第３のバイトの情報を参照して）バーストモードのコンテンツおよびそれがどれ程続くかの両方を知ることとなるので、該装置は、特定のバーストモードのためにパワーアップすべきか否かを知ることとなる。本発明の開示された原理に鑑みて、本実施形態の原理の他の構成を実装することもできる。

実施形態は様々な変更および代替の形態を受け入れることができるが、特定の実施形態を例示として図面に示し、本明細書で詳細に説明してきた。しかしながら、本開示が開示された特定の形態に限定されるようには意図されていないことは理解されたい。むしろ、本開示は、特許請求の範囲によって定義されるように、本開示の範囲内の全ての変更、等価、および代替を含む。

Claims (8)

1. デジタル放送システムにおいてバーストモード情報を通信するための方法であって、
   第１の送信モードの間にバーストモードが起こるときを示すデータを送信するステップを備え、前記情報はバーストモードの長さを含み、バーストモードが起こるときに関する情報がパケットのヘッダに挿入され、バーストモードのコンテンツに関する情報がパケットのペイロードに挿入される、前記方法。
2. 前記バーストモード情報のコンテンツを示すデータを含むバーストモード情報を送信するステップをさらに備える、請求項１に記載の方法。
3. ビデオプログラム、オーディオプログラム、システム維持情報、宣伝、およびインタラクティブ情報のうちの少なくとも１つを含むバースモード情報を送信するステップを備える、請求項２に記載の方法。
4. 前記バーストモードの間に送信されたコンテンツの符号化フォーマットを示すバーストモード情報を送信するステップを備える、請求項２に記載の方法。
5. 前記バーストモード情報を送信するステップは、ユーザのプロファイルに応じて再生されるべき宣伝である前記バーストモード情報を示すことを含む、請求項２に記載の方法。
6. バーストモードコンテンツをキャプチャするためにパワーアップすべきとき、および前記バーストモードコンテンツを無視するためにパワーダウンすべきときを受信機に示すバースモード情報を送信するステップを備える、請求項２に記載の方法。
7. 前記情報は、残留側波帯（ＶＳＢ）送信に使用されるフィールド同期パケットに挿入される、請求項１に記載の方法。
8. 前記情報は、パケット識別子に挿入される、請求項１に記載の方法。

Images