(57)【要約】  新規機能が、従来の放送送信をモバイルデバイスで利用可能にする。本実施形態は、信号を符号化および復号するための装置および方法を説明する。方法（１１００）は、データブロックを生成するステップ（１１１０）と、第１のエンコーディングレートを使用して、データブロックの第１の組を符号化するステップ（１１４０）と、第２のエンコーディングレートを使用して、データブロックの第２の組を符号化するステップ（１１４０）と、制御パケットを生成するステップ（１１８０）であって、制御パケットが、データブロックの第１の組および第１のエンコーディングレートを識別し、またデータブロックの第２の組および第２のエンコーディングレートを識別する、ステップ（１１８０）とを含む。装置（１２００）は、データを受け取り、制御パケットを含むデータの第１のサブセットを第１のデコーディングレートで復号する第１のデコーダ（１２１６）と、復号された制御パケットに基づいて、第１のデコーダ（１２１６）の動作を制御するコントローラ（１２６０）とを含む。
2011501926.tif 000002
【特許請求の範囲】
【請求項１】
データブロックを生成するステップ（１１１０）と、
第１のエンコーディングレートを使用して、データブロックの第１の組を符号化するステップ（１１４０）と、
第２のエンコーディングレートを使用して、データブロックの第２の組を符号化するステップ（１１４０）と、
制御パケットを生成するステップ（１１８０）であって、前記制御パケットは、データブロックの前記第１の組および前記第１のエンコーディングレートを識別し、またデータブロックの前記第２の組および前記第２のエンコーディングレートを識別する、ステップ（１１８０）と
を含むことを特徴とする方法（１１００）。
【請求項２】
前記データブロックは、現在のデータバーストを表すことを特徴とする請求項１に記載の方法（１１００）。
【請求項３】
前記制御パケットは、後続するデータバーストのデータブロックの第１の組および第１のエンコーディングレートをさらに識別することを特徴とする請求項２に記載の方法（１１００）。
【請求項４】
前記制御パケットは、前記現在のデータバーストと後続するデータバーストの間の時間長をさらに識別することを特徴とする請求項３に記載の方法（１１００）。
【請求項５】
前記第１のエンコーディングレートは、前記第２のエンコーディングレートよりも低いデータレートを生み出すことを特徴とする請求項１に記載の方法（１１００）。
【請求項６】
データブロックの前記第１の組を符号化する前記ステップ（１１４０）およびデータブロックの前記第２の組を符号化する前記ステップ（１１４０）は、バイトコード符号化プロセスを使用することを特徴とする請求項１に記載の方法（１１００）。
【請求項７】
リード−ソロモン符号化プロセスを使用して、データブロックの前記第１の組、データブロックの前記第２の組、および前記制御パケットを符号化するステップ（１１９０）をさらに含むことを特徴とする請求項１に記載の方法（１１００）。
【請求項８】
データブロックの前記第１の組を送信する前に、前記制御パケットを送信するステップ（１１９５）をさらに含むことを特徴とする請求項７に記載の方法（１１００）。
【請求項９】
データブロックを生成する手段（６０２）と、
第１のエンコーディングレートおよび第２のエンコーディングレートの一方を使用して、前記データブロックの少なくとも部分を符号化する手段（６０４）と、
制御パケットを生成する手段（６０４、６７０）であって、前記制御パケットは、前記データブロックの前記少なくとも部分を識別し、また前記第１のエンコーディングおよび前記第２のエンコーディングレートの一方としてエンコーディングレートを識別する、手段（６０４、６７０）と
を含むことを特徴とする装置（６００）。
【請求項１０】
データブロックの第１の組を符号化するステップ（１１４０）と、
符号化されたデータブロックの前記第１の組のデータ長を決定するステップ（１１８０）と、
前記データ長がデータ長閾値よりも大きい場合、データブロックの第２の組からの少なくとも１つのデータブロックを符号化されたデータブロックの前記第１の組内に挿入するステップ（１１８０）と
を含むことを特徴とする方法（１１００）。
【請求項１１】
第２の符号化プロセスを使用して、前記少なくとも１つのデータブロックを含むデータブロックの前記第１の組を符号化するステップ（１１９０）と、
データブロックの第２の符号化された組を送信するステップ（１１９５）と
を含むことを特徴とする請求項１０に記載の方法（１１００）。
【請求項１２】
符号化する前記ステップ（１１４０）は、データブロックの前記第１の組をバイトコード符号化することを特徴とする請求項１０に記載の方法（１１００）。
【請求項１３】
前記データ長閾値は、データブロックの前記第２の組からの前記少なくとも１つのデータブロックを復号および認識することが可能なデータ受信機の特性に基づいて決定されることを特徴とする請求項１０に記載の方法（１１００）。
【請求項１４】
データブロックの前記第２の組は、放送テレビ送信信号を表すことを特徴とする請求項１０に記載の方法（１１００）。
【請求項１５】
第１のデコーダ（１２１６）であって、データを受け取り、制御パケットを含む前記データの第１のサブセットを第１のデコーディングレートで復号する、第１のデコーダ（１２１６）と、
前記第１のデコーダ（１２１６）に結合されるコントローラ（１２６０）であって、前記復号された制御パケットに基づいて、前記第１のデコーダ（１２１６）の動作を制御する、コントローラ（１２６０）と
を含むことを特徴とする受信装置（１２００）。
【請求項１６】
前記第１のデコーダ（１２１６）は、前記復号された制御パケットに基づいて、データの第２のサブセットを第２のデコーディングレートで復号することを特徴とする請求項１５に記載の受信装置（１２００）。
【請求項１７】
前記制御パケットは、データの前記第１のサブセットの受信とデータの前記第２のサブセットの受信の間の期間を含むことを特徴とする請求項１６に記載の受信装置（１２００）。
【請求項１８】
前記コントローラ（１２６０）は、データの前記第１のサブセットの受信とデータの前記第２のサブセットの受信の間の期間、前記第１のデコーダ（１２１６）の動作を変更することを特徴とする請求項１７に記載の受信装置（１２００）。
【請求項１９】
前記コントローラ（１２６０）は、データの前記第１のサブセットの受信とデータの前記第２のサブセットの受信の間の期間、前記第１のデコーダ（１２１６）の動作を動作不能にすることを特徴とする請求項１７に記載の受信装置（１２００）。
【請求項２０】
前記第１のデコーダ（１２１８）に結合される第２のデコーダ（１２１６）であって、復号データの前記第１のサブセットおよび復号データの前記第２のサブセットを第３のデコーディングレートで復号する第２のデコーダをさらに含むことを特徴とする請求項１５に記載の受信装置（１２００）。
【請求項２１】
前記第２のデコーダは、リード−ソロモンデコーダであることを特徴とする請求項２０に記載の受信装置（１２００）。
【請求項２２】
前記第１のデコーダは、バイトコードデコーダを含むことを特徴とする請求項１５に記載の受信装置（１２００）。
【請求項２３】
前記第１のデコーダは、反復デコーダであることを特徴とする請求項１５に記載の受信装置（１２００）。
【請求項２４】
第１の信号を第１のデータレートで送信するステップと、
前記第１のデータレートがデータレート閾値を下回るかどうかを決定するステップ（１１８０）と、
前記第１のデータレートが前記データレート閾値よりも小さい場合、前記第１の信号の代わりに第２の信号を送信するステップと
を含むことを特徴とする方法（１１００）。
【請求項２５】
バイトコード符号化プロセスを使用して、前記第２の信号を符号化するステップをさらに含むことを特徴とする請求項２４に記載の方法（１１００）。
【請求項２６】
リード−ソロモン符号化プロセスを使用して、前記第１の信号を符号化するステップと、
前記第２の信号が前記バイトコード符号化プロセスを使用して符号化された後、リード−ソロモン符号化プロセスを使用して、前記第２の信号を符号化するステップと
をさらに含むことを特徴とする請求項２５に記載の方法（１１００）。
【請求項２７】
前記第１の信号を送信しているとき、前記第２の信号を送信すべき時を決定するために、前記第１の信号の前記データレートを監視するステップをさらに含むことを特徴とする請求項２４に記載の方法（１１００）。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に、デジタル放送システムの動作に関し、より詳細には、モバイルデバイス、歩行者用デバイス、および個人用デバイスによる使用を意図した、放送テレビ用のデータの符号化および復号に関する。
【背景技術】
【０００２】
（関連出願の相互参照）
本出願は、３５  Ｕ．Ｓ．Ｃ．  §１１９のもとで、２００７年１０月１５日に米国で出願された仮出願第６０／９９８，９７８号、２００７年１０月１５日に米国で出願された仮出願第６０／９９９，０４０号、および２００７年１０月１５日に米国で出願された仮出願第６０／９９８，９６１号の利益を主張する。
【０００３】
本出願は、以下の同時係属中の、所有者が共通の米国特許出願、すなわち、（１）国際特許出願として２００８年５月１６日に出願された、ＡＰＰＡＲＡＴＵＳ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＥＮＣＯＤＩＮＧ  ＡＮＤ  ＤＥＣＯＤＩＮＧ  ＳＩＧＮＡＬＳと題する第ＸＸＸ号（出願第ＰＣＴ／ＵＳ０８／００６３３４号、トムソン整理番号第ＭＩＣＲ０７００１号）、（２）国際特許出願として２００８年５月１６日に出願された、ＡＰＰＡＲＡＴＵＳ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＥＮＣＯＤＩＮＧ  ＡＮＤ  ＤＥＣＯＤＩＮＧ  ＳＩＧＮＡＬＳと題する第ＸＸＸ号（出願第ＰＣＴ／ＵＳ０８／００６３３５号、トムソン整理番号第ＭＩＣＲ０７００２号）、（３）国際特許出願として２００８年５月１６日に出願された、ＡＰＰＡＲＡＴＵＳ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＥＮＣＯＤＩＮＧ  ＡＮＤ  ＤＥＣＯＤＩＮＧ  ＳＩＧＮＡＬＳと題する第ＸＸＸ号（出願第ＰＣＴ／ＵＳ０８／００６３３３号、トムソン整理番号第ＭＩＣＲ０７００３号）、（４）国際特許出願として２００８年５月１６日に出願された、ＡＰＰＡＲＡＴＵＳ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＥＮＣＯＤＩＮＧ  ＡＮＤ  ＤＥＣＯＤＩＮＧ  ＳＩＧＮＡＬＳと題する第ＸＸＸ号（出願第ＰＣＴ／ＵＳ０８／００６３３２号、トムソン整理番号第ＭＩＣＲ０７００４号）、（５）国際特許出願として２００８年５月１６日に出願された、ＡＰＰＡＲＡＴＵＳ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＥＮＣＯＤＩＮＧ  ＡＮＤ  ＤＥＣＯＤＩＮＧ  ＳＩＧＮＡＬＳと題する第ＸＸＸ号（出願第ＰＣＴ／ＵＳ０８／００６３３１号、トムソン整理番号第ＭＩＣＲ０８００１号）、（６）国際特許出願として２００８年１０月１４日に出願された、ＡＰＰＡＲＡＴＵＳ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＥＮＣＯＤＩＮＧ  ＡＮＤ  ＤＥＣＯＤＩＮＧ  ＳＩＧＮＡＬＳと題する第ＸＸＸ号（出願第ＸＸＸ号、トムソン整理番号第ＰＵ０８０１５９号）、（７）国際特許出願として２００８年１０月１４日に出願された、ＣＯＤＥ  ＲＡＴＥ  ＩＤＥＮＴＩＦＩＥＲ  ＩＮ  ＰＳＵＥＤＯＲＡＮＤＯＭ  ＳＥＱＵＥＮＣＥ  ＩＮ  ＡＴＳＣ  ＳＩＧＮＡＬと題する第ＸＸＸ号（出願第ＸＸＸ号、トムソン整理番号第ＰＵ０８０１６２号）、および（８）国際特許出願として２００８年１０月１４日に出願された、ＰＲＥＡＭＢＬＥ  ＦＯＲ  Ａ  ＤＩＧＩＴＡＬ  ＴＥＬＥＶＩＳＯＮ  ＳＹＳＴＥＭと題する第ＸＸＸ号（出願第ＸＸＸ号、トムソン整理番号第ＰＵ０８０１４５号）に関係する。
【０００４】
このセクションは、以下で説明される本発明の様々な態様に関連し得る技術の様々な態様について導入となる説明を読者に与えることを意図している。本発明の様々な態様のより良い理解を促進する背景情報を読者に提供する点で、この説明は有益であると思われる。したがって、これらの言明は、この点に鑑みて読まれるべきであり、従来技術の容認（ａｄｍｉｓｓｉｏｎ）として読まれるべきではないことを理解されたい。
【０００５】
世界中のテレビ放送システムは、アナログのオーディオ信号およびビデオ信号の配信から、現代的なデジタル通信システムに移行している。例えば、米国では、ＡＴＳＣ（次世代テレビ標準化委員会（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｔａｎｄａｒｄｓ  Ｃｏｍｍｉｔｔｅｅ））が、「ＡＴＳＣ規格：デジタルテレビ規格Ａ／５３」（Ａ５３規格）と呼ばれる規格を開発した。Ａ５３規格は、デジタルテレビ放送用のデータをどのように符号化および復号すべきかを定義する。加えて、米国のＦＣＣ（連邦通信委員会（Ｆｅｄｅｒａｌ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｃｏｍｍｉｓｓｉｏｎ））は、電磁スペクトルの一部をテレビ放送用に割り当てている。ＦＣＣは、割り当てられた部分内の連続する６ＭＨｚチャネルを、地上（すなわちケーブルまたは衛星ではない）デジタルテレビ放送の送信用に放送事業者に割り振っている。各６ＭＨｚチャネルは、Ａ５３規格における符号化および変調フォーマットに基づいて約１９Ｍｂ／秒のチャネル容量を有する。さらに、ＦＣＣは、６ＭＨｚチャネルを介した地上デジタルテレビデータの送信はＡ５３規格に準拠しなければならないことを命じている。
【０００６】
Ａ５３規格などのデジタル放送信号送信規格は、ソースデータ（例えばデジタルオーディオおよびビデオデータ）をどのように処理し、チャネルを介して送信される信号に変調すべきかを定義する。処理は、チャネルが送信信号に雑音およびマルチパス干渉を付加したとしても、チャネルから信号を受信した受信機がソースデータを回復できるように、ソースデータに冗長情報を追加する。ソースデータに追加された冗長情報は、ソースデータが送信される有効データレートを低下させるが、送信信号からのソースデータの回復が成功する可能性を増加させる。
【０００７】
Ａ５３規格の開発プロセスは、ＨＤＴＶ（高精細度テレビ（ｈｉｇｈ  ｄｅｆｉｎｉｔｉｏｎ  ｔｅｌｅｖｉｓｉｏｎ））および固定受信に重点を置いていた。システムは、すでに市場に出始めていた大型の高解像度テレビスクリーンに対してビデオビットレートを最大化するように設計された。しかし、ＡＴＳＣ  Ａ／５３規格のもとで放送される送信は、モバイル受信機に対して困難を与える。モバイルデバイスによるデジタルテレビ信号の堅牢な受信のためには、規格の増強が必要とされる。
【０００８】
ＦＣＣは、放送事業者が、Ａ５３規格を使用して、放送送信用に生成されたデータを符号化しなければならないことを要求する。デジタルテレビ番組放送の送信が、割り当てられたチャネルの１９Ｍｂ／秒の容量を必ずしもすべて必要としない場合、放送事業者は、任意の余剰容量を使用して、おそらくポータブル受信機およびセルラ電話などのデバイスにさえも、他のサービスを放送することができる。しかし、ＦＣＣは、余剰容量を使用して、そのような他のデバイスに送信されるデータはいずれも、Ａ５３規格に従って送信されなければならないことを要求する。Ａ５３規格の改定は可能であり、ＡＴＳＣによって企図されているが、既存またはいわゆるレガシデジタルテレビ受信機を使用し続けることができるような、展開が生じなければならない。同様に、既存のＡ５３規格に従った信号の符号化および送信も、レガシ符号化および送信と呼ばれることがある。
【０００９】
この事実を認識して、２００７年に、ＡＴＳＣは、放送事業者がテレビコンテンツおよびデータをデジタル放送信号によってモバイルデバイスおよびハンドヘルドデバイスに配信することを可能にする規格を開発するプロセスの着手を公表した。その結果のＡＴＳＣ  Ｍ／Ｈと呼ばれる規格案は、既存のＡ５３規格と下位互換性をもつように意図されており、既存の受信機器に悪影響を与えることなく、同じＲＦ（無線周波）チャネルにおける既存のＡＴＳＣサービスの動作を可能とする。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
既存またはレガシＡ５３規格は、現在のところ、一般に（例えば住宅内に）固定され、放送信号を捕捉するための大型アンテナに結合される受信機による使用が意図された信号の生成および送信を定義している。しかし、レガシＡ５３規格送信信号は、モバイル受信機、またはポータブルテレビ、自動車テレビ、セルラ電話、携帯情報端末などで使用される小型アンテナを有する受信機が、そのような信号内に符号化されたソースデータを効果的に抽出することを可能にするほどには十分に頑健または堅牢ではない。特に、既存のＡ５３規格放送信号の送信において使用されるリードソロモンエンコーダ（Ｒｅｅｄ  Ｓｏｌｏｍｏｎ  ｅｎｃｏｄｅｒ）と２／３レートトレリス（２／３−ｒａｔｅ  ｔｒｅｌｌｉｓ）の組み合わせによって提供される冗長性は十分ではなく、モバイルアプリケーションのためには、より低いレートのエンコーダ（すなわちより大きな冗長性を有するエンコーダ）が必要である。したがって、モバイルデバイス、ハンドヘルドデバイス、および歩行者用デバイス内の新型受信機とともにより良く作動するように適合された、より堅牢な符号化プロセスを導入することが望ましい。さらに、送信用の可変符号化率（ｃｏｄｅ  ｒａｔｅ）および可変データセグメントサイズを含む、モバイル放送内の様々な動作を可能にすることが望ましい。加えて、レガシＡ５３規格内で動作する新しいシステムはいずれも、下位互換性をもつことが期待される。結果として、長いデータセグメント送信を使用するモバイルシステムが、レガシＡ５３送信を受信しようと意図する受信機の性能の低下を防止する機構を含むことも望ましい。
【課題を解決するための手段】
【００１１】
本実施形態の一態様によれば、データブロックを生成するステップと、第１のエンコーディングレート（ｅｎｃｏｄｉｎｇ  ｒａｔｅ）を使用して、データブロックの第１の組を符号化するステップと、第２のエンコーディングレートを使用して、データブロックの第２の組を符号化するステップと、制御パケットを生成するステップであって、制御パケットが、データブロックの第１の組および第１のエンコーディングレートを識別し、またデータブロックの第２の組および第２のエンコーディングレートを識別するステップとを含む方法が開示される。
【００１２】
本実施形態の別の態様によれば、データブロックを生成する手段と、第１のエンコーディングレートおよび第２のエンコーディングレートの一方を使用して、データブロックの少なくとも部分を符号化する手段と、制御パケットを生成する手段であって、制御パケットが、データブロックの少なくとも部分を識別し、また第１のエンコーディングおよび第２のエンコーディングレートの一方としてエンコーディングレートを識別する、手段とを含む装置が開示される。
【００１３】
本実施形態の別の態様によれば、データブロックの第１の組を符号化するステップと、符号化されたデータブロックの第１の組のデータ長を決定するステップと、データ長がデータ長閾値よりも大きい場合、データブロックの第２の組からの少なくとも１つのデータブロックを符号化されたデータブロックの第１の組内に挿入するステップとを含む方法が開示される。
【００１４】
本実施形態の別の態様によれば、第１のデコーダであって、データを受け取り、制御パケットを含むデータの第１のサブセットを第１のデコーディングレート（ｄｅｃｏｄｉｎｇ  ｒａｔｅ）で復号する第１のデコーダと、第１のデコーダに結合されるコントローラであって、復号された制御パケットに基づいて、第１のデコーダの動作を制御するコントローラとを含む装置が開示される。
【００１５】
本実施形態の別の態様によれば、第１の信号を第１のデータレートで送信するステップと、第１のデータレートがデータレート閾値を下回るかどうかを決定するステップと、第１のデータレートがデータレート閾値よりも小さい場合、第１の信号の代わりに第２の信号を送信するステップとを含む方法が開示される。
【図面の簡単な説明】
【００１６】
【図１】本開示のエンコーダの一実施形態のブロック図である。
【図２】本開示の連結バイトコードエンコーダ（ｃｏｎｃａｔｅｎａｔｅｄ  ｂｙｔｅ−ｃｏｄｅ  ｅｎｃｏｄｅｒ）の一実施形態のブロック図である。
【図３】本開示のデータインタリービングのマップを示す表である。
【図４】本開示の連結バイトコードエンコーダの別の実施形態のブロック図である。
【図５】本開示のデータインタリービングの別のマップを示す表である。
【図６】本開示の送信デバイス内で使用されるエンコーダの別の実施形態のブロック図である。
【図７】本開示の行方向順データを示す表である。
【図８】本開示の列方向順データを示す表である。
【図９】本開示の送信用符号化データの編成を示す図である。
【図１０】本開示の符号化プロセスの一実施形態のフローチャートである。
【図１１】本開示の符号化プロセスの別の実施形態のフローチャートである。
【図１２】本開示のデコーダの一実施形態のブロック図である。
【図１３】本開示の連結バイトコードデコーダ（ｃｏｎｃａｔｅｎａｔｅｄ  ｂｙｔｅ−ｃｏｄｅ  ｄｅｃｏｄｅｒ）の一実施形態のブロック図である。
【発明を実施するための形態】
【００１７】
本発明の特徴および利点は、例として与えられる以下の説明から、より明らかとなる。  本開示の１つまたは複数の特定の実施形態が以下で説明される。これらの実施形態の簡潔な説明を提供しようと努めるにあって、本明細書では、実際の実施の必ずしもすべての特徴が説明されるわけではない。任意のそのような実際の実施の開発においては、任意の工学または設計プロジェクトにおけるのと同様に、それぞれの実施によって様々であり得る、システム関連制約およびビジネス関連制約の遵守など、開発者に特有の目標を達成するために、多くの実施特有の決定が行われなければならないことを理解されたい。さらに、それにも関わらず、そのような開発努力は、この開示から利益を得る当業者にとって、設計、製作、および製造の定例的な仕事であることを理解されたい。
【００１８】
以下では、テレビ放送信号に関連する、より具体的には米国において使用するために定義された放送信号に関連するシステムについて説明する。説明される実施形態は、モバイルデバイス、ハンドヘルドデバイス、または歩行者用デバイスにおいて使用することができる。使用されるデバイスの例は、セルラフォン、インテリジェントフォン、携帯情報端末、ラップトップコンピュータ、およびポータブルテレビを含むが、それらに限定されない。他のタイプの信号を送信および受信するために利用される他のシステムも、類似の構造およびプロセスを含むことができる。本明細書で説明される回路およびプロセスの実施形態は、可能性のある実施形態の１組にすぎないことを当業者であれば理解されよう。Ａ５３規格などの放送規格および無線規格に準拠した信号は一般に、衛星リンク、同軸ケーブル、または電話回線を介した送信を含む、オーバザエア（ｏｖｅｒ  ｔｈｅ  ａｉｒ）以外の方式でも送信できることに留意することが重要である。そのようなものとして、代替的実施形態では、システムのコンポーネントを再編成もしくは省略することができ、または付加的なコンポーネントを追加することができる。例えば、わずかな変更を施すだけで、説明されるシステムは、世界のどこか別の場所で使用されるサービスを含む、衛星ビデオおよびオーディオサービスまたは電話データサービスにおいて使用するために構成することができる。
【００１９】
ここで図１を参照すると、エンコーダ１００の一実施形態のブロック図が示されている。エンコーダ１００は、データを符号化して頑健または堅牢なデータストリームをもたらすように適合された処理回路を含む。データを頑健なデータストリームに符号化することで、困難な伝送環境におけるデータの回復が可能になる。例えば、エンコーダ１００によって生み出された頑健なデータストリームは、ハンドヘルド受信デバイス、モバイル受信デバイス、または歩行者用受信デバイスによる、放送テレビ信号の改善された受信を可能にする。データ生成器１０２は、オーディオおよびビデオコンテンツなどの到来データコンテンツを受け取り、処理する。データ生成器１０２は、バイトコードエンコーダ１０４に接続する。バイトコードエンコーダ１０４は、ランダマイザ１０６に接続する。ランダマイザ１０６は、リードソロモンエンコーダ１０８に接続する。リードソロモンエンコーダ１０８は、インタリーバ１１０に接続する。インタリーバ１１０は、トレリスエンコーダ１１２に接続する。トレリスエンコーダ１１２は、残りの送信システムにおいて使用するための頑健または堅牢なデータストリームを提供する。
【００２０】
バイトコードエンコーダ１０４は、データパケットに編成されるデータのストリームをデータ生成器１０２から受け取る。データパケットのストリームは、１８７バイトからなるグループに組織することができる。各データパケットは一般に、３バイトのヘッダを含み、その３バイトのうちの１３ビットは、パケットに収容して送信されるデータのタイプを識別するＰＩＤ（パケット識別子（ｐａｃｋｅｔ  ｉｄｅｎｔｉｆｉｅｒ））である。例えば、０ｘ１１（１６進の１１）の値を有するＰＩＤを含むパケットは、パケットの内容を第１のビデオストリームの一部として識別することができ、０ｘ１４の値を有するＰＩＤを含むパケットは、パケットの内容を第１のオーディオストリームの一部として識別することができる。データパケットのストリームの他の編成も可能であることに留意することが重要である。加えて、各データパケットは、１つまたは複数の符号語を含むことができ、さらに符号語の一部を含むこともできる。バイトコードエンコーダ１０４は、符号語の編成に基づいて各データパケットを符号化し、新しい符号語を生み出す。一実施形態では、バイトコードエンコーダ１０４は、レート１／２エンコーダである。レート１／２バイトコードエンコーダ１０４は、入力において提供される各符号語につき２つの出力符号語を提供する。バイトコードエンコーダ１０４のために、他のエンコーディングレートを使用することもできる。バイトコードエンコーダ１０４の詳細な動作は、以下でさらに詳しく説明される。
【００２１】
新しい符号語を含むデータパケットのストリームが、バイトコードエンコーダ１０４からランダマイザ１０６に提供される。ランダマイザ１０６は、送信源１２０からのデータパケットのストリームをランダム化する。典型的には、ランダマイザは、データストリームの伝送品質および受信を改善するために、到来データと既知の値の系列との乗算またはＸＯＲ（排他的論理和）などの、既知のランダム化関数を使用する。ランダマイザ１０６は、データパケットのストリームをリードソロモンエンコーダ１０８に提供する。リードソロモンエンコーダ１０８は、１８７バイトの各ランダム化パケットを符号化して、１つまたは複数の符号語を含む２０７バイトのパケットを生み出す。
【００２２】
リードソロモン誤り訂正アルゴリズムは、ガロア体（Ｇａｌｏｉｓ  Ｆｉｅｌｄ）の特性を利用する。具体的には、ガロア体ＧＦ（ｐn）は、有限個の要素ｐnを含む数学的集合であり、ここで、ｐおよびｎの値は整数である。特定のガロア体は、生成多項式（ｇｅｎｅｒａｔｏｒ  ｐｏｌｙｎｏｍｉａｌ）ｇ（ｘ）を使用して定義される。ガロア体の各要素は、ｎビットを有する一意的なビットパターンによって表すことができる。さらに、次数ｐnの一意的な多項式を各要素に関連付けることができ、ここで、多項式の各係数は、０とｐ−１の間である。さらに、ガロア体における数学的演算は、重要な特性を有する。ガロア体ＧＦ（ｐn）の２つの要素の加法は、加算される２つの要素に関連付けられた多項式の係数のｐを法とする和を係数として有する多項式に関連付けられた要素として定義される。同様に、２つの要素の乗法は、２つの要素に関連付けられた多項式の、ガロア体に関連付けられた生成多項式ｇ（ｘ）を法とする乗算として定義される。加法演算子および乗法演算子は、ガロア体の任意の２つの要素の和および積がガロア体の要素となるように、ガロア体上で定義される。リードソロモン符号語の特性は、符号語の各バイトにガロア体の要素を乗じた結果が、別の有効なリードソロモン符号語になることである。さらに、２つのリードソロモン符号語のバイト毎の加算は、別のリードソロモン符号語を生み出す。レガシＡ５３規格は、リードソロモンアルゴリズムにおいて使用するために、２５６個の要素を有するガロア体ＧＦ（２8）と、関連する生成多項式ｇ（ｘ）とを定義する。ガロア体の特性は、誤りを決定するために符号語に対するシンドロームを生成する能力ももたらす。
【００２３】
リードソロモンエンコーダ１０８は一般に、２０個の新しいバイトを生み出し、２０個の新しいバイトを１８７バイト符号語の末尾に追加する。インタリーバ１１０は、リードソロモンエンコーダ１０８から出力された２０７バイト符号語の各々をインタリーブし、その結果を、変調および送信に備えて、トレリスエンコーダ１１２に提供する。ランダマイザ１０６、リードソロモンエンコーダ１０８、インタリーバ１１０、およびトレリスエンコーダ１１２は、レガシＡ５３規格などの既存のテレビ放送規格に準拠した既存のレガシ送信機において使用されるものと同一とすることができる。
【００２４】
図示されるように、データ生成器１０２およびバイトコードエンコーダ１０４は、送信源１２０の一部と見なすことができる。バイトコードエンコーダ１０４によって生成されたパケット（元の内容および符号化バイトコード）は、レガシ８−ＶＳＢ信号エンコーダ１３０の一部として含まれるランダマイザ１０６に提供することができる、頑健なデータストリーム内に含まれる。レガシ８−ＶＳＢエンコーダ１３０は、頑健または堅牢な符号語またはパケットをＡ５３規格に準拠して符号化する。さらに、レガシ８−ＶＳＢエンコーダ１３０など、既存の送信機器の既存のハードウェア構造に、最低限の変更を施すだけで、頑健または堅牢なデータストリームを生み出すバイトコードエンコーダ１０４の付加機能を追加することができる。
【００２５】
上で説明されたように、レート１／２バイトコードエンコーダ１０２によって生成された２つの符号語またはパケットは、最初に入力された符号語の複製と、元の符号語に冗長性を提供する新しい符号語とを含む。２つの符号語は、システマティックデータ（ｓｙｓｔｅｍａｔｉｃ  ｄａｔａ）および非システマティックデータ（ｎｏｎ−ｓｙｓｔｅｍａｔｉｃ  ｄａｔａ）とも呼ばれることがある。システマティックデータおよび非システマティックデータを表す符号語は、より大きなデータ構造を形成するように編成できることに留意することが重要である。好ましい一実施形態では、符号語は、データパケットの頑健なデータストリームを形成するように組織することができる。頑健なデータストリームは、データパケットの複製であるシステマティックパケットをストリーム部分Ａに含み、バイトコードエンコーダの処理により生成された非システマティックパケットをストリーム部分Ａ’に含む。非システマティックパケットは、頑健なデータストリームの他のシステマティックパケットおよび非システマティックパケットから導出できるパケットも含む。さらに、頑健なデータストリーム内のパケットは、システマティックバイトおよび非システマティックバイトからさらに成ることができる。そのような実施形態では、システマティックバイトは、コンテンツデータのバイトの複製であり、非システマティックバイトは、他のシステマティックバイトおよび非システマティックバイトから導出されるバイトである。
【００２６】
バイトコードエンコーダによって出力される冗長または非システマティック符号語またはパケットは、到来符号語またはパケットの各バイトにガロア体ＧＦ（２５６）の要素ｂを乗じた結果である。一実施形態では、送信源としてのデータ生成器１０２が、バイトＭ（１）、Ｍ（２）、．．．、Ｍ（１８７）から成るメッセージＭであって、Ｍ（１）がメッセージの第１バイト、Ｍ（２）がメッセージの第２バイト、以降も同様であるメッセージＭを生成した場合、その後、バイトコードエンコーダ１０４は、以下のように、符号語Ｍから符号語ＡおよびＡ’を生み出す。
【００２７】
Ａ（ｉ）＝Ｍ（ｉ）  ｉ＝１，２，．．．，１８７  （１）
Ａ’（ｉ）＝ｂ＊Ｍ（ｉ）  ｉ＝１，２，．．．，１８７  （２）
【００２８】
値ｂは、リードソロモンエンコーダ１０８によっても使用できる同じガロア体ＧＦ（２５６）の所定の（非ゼロ）要素である。例示的な一実施形態では、ｂ要素の値は２である。バイトコードエンコーダおよびリードソロモンエンコーダの両方で同じガロア体を使用することで、２つのエンコーダの間でガロア体の特性に基づいた演算が可能になることは明らかであろう。バイトコードエンコーダ１０４は、ＰＩＤを含むヘッダを形成するバイトを含む、データパケットのバイトのすべてを符号化して、頑健なデータストリームの１つまたは複数の非システマティックパケットを生成する。したがって、各非システマティックパケットのＰＩＤは、符号化されたバイトコードであり、受信デバイスに認識可能なＰＩＤ値をもはや表すことができない。
【００２９】
エンコーダ１００によって表される送信機の実施形態によって符号化されるパケットはいずれも、Ａ５３規格に準拠するレガシ受信機において使用されるデコーダの一実施形態によって復号できることは明らかであろう。レガシ受信機内のデコーダは、頑健なデータストリームのパケットをデータデコーダに提供する。頑健なデータストリームは、バイトコードエンコーダを使用して符号化された非システマティックパケットを含み、非システマティックパケットは、レガシ受信機内のデコーダによって正確に復号されるが、レガシ受信機によって認識不能なデータコンテンツをもたらす。しかし、そのようなパケットは、ＰＭＴ（プログラムマップテーブル（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ））内で既存またはレガシデータフォーマットに関連付けられていないＰＩＤを有するので、レガシ受信機内のコンテンツデコーダは、頑健なデータストリームのこれらの非システマティックパケットを無視する。
【００３０】
バイトコードエンコーダ１０４は、上記の式（２）を使用して、各システマティックパケットに対して非システマティックパケットを生成し、送信用に１／２の有効データレート（すなわち１バイト入力、２バイト出力）を有する符号化ストリームを生み出すために、両方のパケットをレガシ８−ＶＳＢエンコーダ１３０に提供する。先に言及されたように、バイトコードエンコーダ１０４は、他の有効データレートを生み出すために、他のエンコーディングレートを使用することが可能なこともある。いくつかの実施形態では、バイトコードエンコーダは、２つのシステマティックパケットと１つの非システマティックパケットとを含むレート２／３の頑健なデータストリームを生成するために、データ生成器１０２によって生み出された２つのソースパケットＭAおよびＭBにつき１つのバイト符号化パケットを以下のように生み出すことができる。
【００３１】
ＭAB（ｉ）＝ＭA（ｉ）＊ｂ1＋ＭB（ｉ）＊ｂ2  ｉ＝１，２，．．．，１８７  （３）
【００３２】
ここで、ＭAおよびＭBは、データ生成器１０２によって生み出された連続的なシステマティックパケットであり、ｂ1およびｂ2は、リードソロモンエンコーダ１０８によって使用されるガロア体などのガロア体の所定の要素である。例示的な一実施形態では、ｂ1要素およびｂ2要素の値は２である。いくつかの実施形態では、ｂ1の値とｂ2の値は、同一でなくてもよい。バイトコードエンコーダ１０４は、パケットＭA、ＭB、およびＭABを、さらなる符号化および送信のために、レガシ８−ＶＳＢエンコーダ１３０に提供する。
【００３３】
バイトコードエンコーダ１０４は、冗長パケットを生成するための追加の入力データパケットを含むことによって、異なるコーディングレートを使用して、頑健なデータストリーム（すなわちより低いデータレートを有するデータストリーム）を生み出すことができる。バイトコードエンコーダ１０４の別の実施形態は、データ生成器１０２からの４つのシステマティックパケットＭA、ＭB、ＭC、およびＭDと、以下のように計算される５つの非システマティックパケットとを利用することによって、レート４／９のデータストリームを生み出す。
【００３４】
【数１】
2011501926.tif 000003
【００３５】
値ｂ1、ｂ2、．．．、ｂ10は、ガロア体から選択された所定の要素である。例示的な一実施形態では、ｂ1、ｂ2、．．．、ｂ10の値は２である。加えて、式（８）に示されるように、パケットＭABCDは、他の冗長パケットのみから、具体的にはパケットＭABおよびＭCDから生成される冗長パケットである。冗長パケットＭABCDが代替的に冗長パケットＭACおよびＭBDの要素を使用して生成できることは明らかであろう。送信源生成器１２０のいくつかの実施形態では、パンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）として知られる操作において、１つまたは複数の非システマティックパケットの除去を実行することができる。例えば、冗長パケットのみを利用するパケットの１つ（すなわちこのケースではＭABCD）を、このパケットは最少量の本質的データを含むにすぎないことを理由に、生成しないことによって、パンクチャレート４／８を生み出すことができる。任意のパケットまたは符号語を削除することができる。しかし、最少量の本質的データを含むにすぎないパケットまたは符号語の削除が最適であり得る。コードパンクチャリングは、送信されるパケットまたは符号語の数に対するある制限を満たすように、送信パケットの数を変更するために使用することができる。
【００３６】
さらに、バイトコードエンコーダ１０４は、以下のように８個のデータパケットＭA、ＭB、．．．、ＭHを利用して１９個の非システマティックパケットを生み出すことによって、８／２７のデータレートを有する頑健なデータストリームも生み出すことができる。
【００３７】
【数２】
2011501926.tif 000004
【００３８】
加えて、本質的データ値が最少量のパケットＭABCDEFGHまたは冗長パケットのみから生成される別のパケットを生成しないことによって、バイトコードエンコーダ１０４によって、８／２６のデータレートを有するパンクチャコードを生成することができる。
【００３９】
上で説明されたように、バイトコードエンコーダは、使用される符号語またはパケットの数と、単一の符号化プロセスを介して形成される符号語またはパケットの数とに基づいて、あるエンコーディング符号化率を生み出すように構成することができる。加えて、先に説明された符号化率エンコーダの特定の構成を構築ブロックまたは構成符号化率エンコーダ（ｃｏｎｓｔｉｔｕｅｎｔ  ｃｏｄｅ  ｒａｔｅ  ｅｎｃｏｄｅｒ）として使用して、より複雑な符号化率を組み立てることができる。さらに、連結バイトコードエンコーダを形成するために、追加的な処理ブロックを含むこともできる。例えば、連結バイトコードエンコーダは、生み出されるデータストリームの頑健性を改善するために、冗長性に加えて、構成バイトコードエンコーダ（ｃｏｎｓｔｉｔｕｅｎｔ  ｂｙｔｅ−ｃｏｄｅ  ｅｎｃｏｄｅｒ）の間で追加的なインタリービングブロックを使用することができる。連結バイトコードエンコーダの様々な実施形態が以下で説明される。
【００４０】
ここで図２を参照すると、連結バイトコードエンコーダ２００の一実施形態が示されている。連結バイトコードエンコーダ２００は、図１において説明された構成バイトコードエンコーダ１０４の代わりに使用することができ、１２／２６の符号化率を使用したデータストリーム内の符号語の符号化を可能にする。連結バイトコードエンコーダは、パケットまたは符号語を受け取り、それらを第１の２／３レートバイトコードエンコーダ２０２に提供する。第１の２／３レートバイトコードエンコーダ２０２の出力は、インタリーバ２０４に提供される。インタリーバ２０４の出力は、第２の２／３レートバイトコードエンコーダ２０６に提供される。第２の２／３レートバイトコードエンコーダ２０６の出力は、バイトパンクチャブロック２０８に提供される。パンクチャブロック２０８の出力は、データパケット化器２１０に提供される。データパケット化器２１０の出力は、さらなる処理（例えば先に図１において説明されたレガシ送信符号化）のために提供することができる。
【００４１】
第１の２／３レートバイトコードエンコーダ２０２は、１２バイトのコンテンツデータパケットを受け取り、その１２バイトから第１のバイトコード符号化ストリームを生成する。１２バイトのうちの２つのコンテンツデータバイトＭAおよびＭB毎に、第１のバイトコード符号化ストリームは、バイトＭAおよびＭBの複製と、先に説明されたように計算される冗長バイトＭABとを含む。いくつかの実施形態では、コンテンツデータバイトＭAおよびＭBは、データ生成器（例えば図１のデータ生成器１０２）によって生成された１つのコンテンツデータパケットのうちのバイトである。他の実施形態では、第１の２／３レートバイトコードエンコーダ２０２は、コンテンツデータバイトＭAおよびＭBをそれぞれ２つの異なるコンテンツデータパケットＡおよびＢから選択する。１２バイトのコンテンツデータにつき、１８バイトが、第１のバイトコード符号化出力ストリームの一部として出力される。
【００４２】
第１のバイトコードエンコーダ２０２からのバイトコード符号化ストリームは、インタリーバ２０４によってインタリーブされ、１８個のインタリーブバイトを含むインタリーブストリームを生み出す。インタリーバ２０４は、以下で説明される他のインタリーバと同様に、当技術分野で知られた任意のインタリービング方法（例えば、疑似ランダム、行−列、符号最適化など）を使用することができる。加えて、インタリーバは、インタリーバデータの全長を記憶できる記憶容量を有するメモリも含むことができる。好ましい一実施形態では、インタリーバ２０４は、図３に示される表３００で提示されるように、出力バイトを配列する。表３００は、入力におけるバイトの位置を示す行３１０を含む。行３２０は、出力において読み出されるバイトの順番を示す。インタリーブストリームは、第２の２／３レートバイトコードエンコーダ２０６に提供される。第２の２／３レートバイトコードエンコーダ２０６は、インタリーブストリーム内の１８個のインタリーブバイトからなるグループを符号化して、２７バイトからなるグループを含む第２のバイトコード符号化ストリームを生成する。上で説明されたように、インタリーバによって生み出された２つのバイトＭAおよびＭB毎に、第２の２／３レートバイトコードストリームは、２つのバイトＭAおよびＭBの複製と、バイトＭABとを有する。バイトＭAは、データ生成器（例えば図１のデータ生成器１０２）によって生成されたコンテンツデータのバイトの１つの複製とすることができること、または第１のバイトコードエンコーダ２０２によって冗長もしくは非システマティックバイトとして作成されたバイトとすることができることは明らかであろう。同様に、バイトＭBは、コンテンツデータのバイトの複製とすることができ、または第１のバイトコードエンコーダ２０２によって冗長もしくは非システマティックとして作成されたバイトとすることができる。
【００４３】
エンコーダ内で使用されるインタリーバは、インタリーバ長または深さがしばしば非常に長い。例えば、従来のインタリーバは、畳み込み符号化システムとともに利用される場合、長いインタリービング長または深さを重要視する。コーディング性能の改善は一般に、畳み込みエンコーダとともに利用されるより長いインタリーバの結果として得られる。多くの場合、インタリーバ長が長くなるほど、より高いコーディング性能利得がもたらされる。長いインタリーバ長または深さのため、インタリーバパターンは、一般にランダム化され、最大コーディング利得のためのパターンの最適化は、実際的ではない。対照的に、連結バイトコードエンコーダ内で使用されるインタリーバ２０４などのインタリーバは、長さが短く、コーディングレートに関して最適化される。従来の手法とは反対に、バイトコード符号化プロセスとともに使用されるインタリーバは、少ない待ち時間を重要視し、短い長さまたは深さを使用する。バイトコードエンコーダは、線形ブロック符号化プロセスを含み、畳み込みエンコーダのような方式では動作しない。符号語の長さの３倍を超えるインタリーバ長を利用するインタリーバは、コーディング性能の目減りした改善をもたらす。説明されたバイトコードエンコーダにおいて使用されるような、短いインタリーバ長に基づいたインタリーバパターンの最適化は、可能であり、望ましい。
【００４４】
バイトパンクチャブロック２０８は、第２のバイトコード符号化ストリーム内の２７バイトからなるグループから１バイトを削除して、２６バイトからなるグループを含むパンクチャストリームを生み出す。バイトパンクチャリングは、与えられたコーディング構造に合わせて、提供および送信されるバイトの数を削減することによって、データ効率を改善するために使用される。しかし、改善されたデータ効率は、その結果である受信機内の復号回路の性能低下とトレードオフの関係にあり、この性能低下は、１つまたは複数の符号化バイトがデータストリームから欠落していることが原因である。バイトパンクチャリングは、送信フォーマットにとって都合がよい、符号化データのバイトまたはパケットのグルーピングまたはブロックを生み出すためにも使用することができる。バイトまたはパケットの何らかのグルーピングに基づいたコーディング構造は、しばしばブロック符号（ｂｌｏｃｋ  ｃｏｄｅ）と呼ばれる。
【００４５】
バイトパンクチャブロック２０８は、第２の符号化ストリームから２バイト以上を削除することもできる。例えば、削除できる３バイトを識別して、１２／２４レートデータストリームを生み出すことも可能である。２バイト以上のパンクチャリングは、コーディングレートの改善をもたらすが、符号化の有効性をさらに低下させる。バイトパンクチャブロック２０８における１つまたは複数のバイトの削除は、上で説明されたようなインタリーバ２０４における最適インタリービングに基づいて、コーディング性能損失が最小となるように達成することができる。このように、パンクチャリングと、上で説明されたようなショートレングスインタリービングとは、与えられた出力ブロックサイズの出力パケットを生み出すことに基づいた最適符号化率を可能にするために対話する。
【００４６】
パケット化器２１０は、パンクチャストリームからのバイトを組み合わせ、１８７バイトからなる個別パケットにグループ化する。バイトコードエンコーダ２００のコンポーネントによって生み出された頑健なデータストリームは、１２／２６レートデータストリームを生み出す。バイトコードエンコーダ２００は、バイトパンクチャブロック２０８が使用されない場合、１２／２７レートデータストリームも生み出すことができる。
【００４７】
上で説明された１２／２７レートおよび１２／２６レートの頑健なデータストリーム以外の頑健なデータストリームを生み出すために、連結バイトコードエンコーダ６００に類似した連結バイトコードエンコーダを利用することができる。例えば、１７／２６レートおよび１２／５２レートなどの符号化率を有するデータストリームを、構成バイトコードエンコーダ、インタリーバ、およびパンクチャブロックの組み合わせを介して生み出すことができる。同様に、他のタイプまたは構成のインタリーバまたはパンクチャブロックに、説明された実施形態において使用されたものの代わりをさせることができる。
【００４８】
ここで図４を参照すると、連結バイトコードエンコーダ４００の別の実施形態が示されている。示されたバイトコードエンコーダは、２４／２０８符号化率の符号化システムを表す。示されたバイトコードエンコーダ４００は、ブロック符号エンコーダと呼ばれることもある。パケットからなる到来データストリームは、エンコーダにおける高いコーディングレベルまたは冗長性レベルの導入を容易にするために、データのブロックに編成することができる。一般に、２４／２０８符号化率を使用する頑健なデータストリームは、データレートが非常に低い符号化システムを表す。そのような低データレートの頑健なデータストリームは、きわめて困難な信号環境において有益なことがあり、元のデータの１バイトにつき７個の冗長バイトを提供することによって、高いレベルのデータ冗長性を提供する。エンコーダ４００は、効率的な構造を提供し、同一の動作ブロックを多数回再利用することによって並列動作または高速多重化順次動作を可能にするために、並列符号化構造を利用する。完全並列構成をとるエンコーダ４００について説明が行われるが、全体的なハードウェアサイズを縮小するために、既知の多重化技法および再利用技法を使用することができる。
【００４９】
到来データストリームは、分割または逆多重化され、２４個のレート１／４バイトコードエンコーダ４０２ａ〜４０２ｘに提供される。各レート１／４バイトコードエンコーダ４０２ａ〜４０２ｘの出力は、シンボルインタリーバ４０４に接続される。シンボルインタリーバ４０４は、８個の出力を生み出し、各出力は、レート２／３バイトコードエンコーダ４０６ａ〜４０６ｈに接続される。各レート２／３バイトコードエンコーダ４０６ａ〜４０６ｈは、シンボルインタリーバ４０８ａ〜４０８ｈに接続する。各シンボルインタリーバ４０８ａ〜４０８ｈは、第２のレート２／３バイトコードエンコーダ４１０ａ〜４１０ｈに接続する。第２のレート２／３バイトコードエンコーダ４１０ａ〜４１０ｈの各々は、パンクチャブロック４１２ａ〜４１２ｈに接続する。各パンクチャブロック４１２ａ〜４１２ｈの出力は、再び組み合わされて、ブロックコード化データストリームを形成する。第１のバイトコードエンコーダ４０６ａ〜４０６ｈ、シンボルインタリーバ４０８ａ〜４０８ｈ、第２のバイトコードエンコーダ４１０ａ〜４１０ｈ、およびパンクチャブロック４１２ａ〜４１２ｈの各並列構成は、図２において説明されたエンコーダに等しいレート１２／２６エンコーダ構造を形成し、ここではさらには説明されない。
【００５０】
到来データストリームは、バイト順に並列に配列されたデータまたは符号語の２４バイトからなるグループに分解される。２４バイトは、１バイトずつに分離されて、レート１／４バイトコードエンコーダ４０２ａ〜４０２ｘにおいて処理され、各々が４バイトを含む２４個の出力を生み出す。上で説明されたように、４バイトは、１つのシステマティックバイトと、３つの非システマティックまたは冗長バイトとから成る。結果として、バイトコードエンコーダ４０２ａ〜４０２ｘは、以下のように符号語Ｍから符号語Ａ、Ａ’、Ａ”、Ａ”’を生み出す。
【００５１】
【数３】
2011501926.tif 000005
【００５２】
上で説明されたように、値ｂ1、ｂ2、およびｂ3は、後続のリード−ソロモンエンコーダによっても使用できる同じガロア体ＧＦ（２５６）の所定の（非ゼロ）要素である。例示的な一実施形態では、ｂ1、ｂ2、およびｂ3の値は２である。いくつかの実施形態では、ｂ1、ｂ2、およびｂ3の値は、同一でなくてもよい。
【００５３】
２４個の４バイトからなる組が、バイト順に集められ、シンボルインタリーバ４０４に入力される。シンボルインタリーバ４０４は、図２において先に説明されたように、当技術分野で知られた任意のインタリービング方法（例えば、疑似ランダム、行−列、符号最適化など）を使用することができる。加えて、インタリーバは、インタリーバデータの全長を記憶できる記憶容量を有するメモリも含むことができる。好ましい一実施形態では、インタリーバ４０４は、図５に示される表５００で提示されるように、出力バイトを配列する。表５００は、入力におけるバイトの位置を示す行５１０を含む。行５２０は、出力において読み出されるバイトの順番を示す。インタリーバ４０４は、その入力においてバイト収集機能または多重化機能を含むことができる。インタリーバ４０４は、その出力においてバイトセット分離機能または多重化機能を含むこともできる。
【００５４】
インタリーバ４０４からの出力バイトは、８個の１２バイトからなる組に再びグループ化される。１２バイトからなる各組は、レート２／３バイトコードエンコーダ４０６ａ〜４０６ｈに入力され、上で図２において説明されたようなレート１２／２６符号化を使用して頑健なデータストリームを符号化するための、説明されたような残りの処理チェーンを通過する。パンクチャブロック４１２ａ〜４１２ｈの各々の出力は、レート１２／２６でコード化されたストリームを表し、２０８バイトを含む信号バイトコード符号化ストリームに再組み合わされまたは逆多重化される。
【００５５】
データバイトの分離、配列、および再組み合わせは、いくつかの可能な構成に従って実行できることに留意することが重要である。入力順および対応する出力順は同じでなくてよい。バイトの入力部分の組の数およびバイトの出力部分の組の数も異なってよい。例えば、１つの構成では、インタリーバ４０４は、レート１／４バイトコードエンコーダの各々からの到来バイトを、１個のシステマティックバイトと３個の非システマティックバイトの構成を維持することによって並べることができる。その場合、出力インタリービングプロセスは、１２バイトからなる各組内に３個のシステマティックバイトと９個の非システマティックバイトを含む、１２バイトからなる出力の組をもたらすことができる。第２の構成では、インタリービングプロセスは、元の２４個の非システマティックバイトを最初の２個の１２バイトからなる組内に集めることを可能にする。残りの非システマティックバイトは、残りの６個の１２バイトからなる組を組み立てる。後者の構成は、システマティックバイトが適切に復号および回復された場合には、受信機が非システマティックバイトの一部または全部を廃棄することを可能にすることによって、より効率的な受信および復号を可能にすることができる。
【００５６】
ここで図６を参照すると、エンコーダ６００のさらなる一実施形態のブロック図が示されている。エンコーダ６００は、図１に示されたエンコーダ１００の代替であり、Ａ５３送信規格に合わせて頑健なストリームを符号化および送信するのに特に適している。エンコーダ６００は、ＭＰＥＧトランスポートストリーム源６０２を含む。ＭＰＥＧトランスポートストリーム源６０２は、いくつかの追加ブロックを含むＡＴＳＣ  Ｍ／Ｈブロック６１０に接続される。ＡＴＳＣ  Ｍ／Ｈブロック６１０内に含まれるブロックは、到来データストリームを処理し、モバイルデバイス、歩行者用デバイス、およびハンドヘルドデバイスによる受信および使用に適合された頑健なデータストリームを生み出す。これらのブロックは、以下でさらに説明される。ＡＴＳＣ  Ｍ／Ｈブロック６１０は、ｍｕｘ６３０に接続される。ｍｕｘ６３０も、レガシＡＴＳＣ  Ａ５３限定の符号化とともに使用されるトランスポートデータコンテンツを受け取る。ｍｕｘ６３０は、やはりその内部にいくつかの追加ブロックを含むＡＴＳＣ  Ａ５３レガシブロック５５０に接続する。ＡＴＳＣ  Ａ５３レガシブロック６５０を伴うブロックは、Ａ５３信号フォーマットで既存の放送信号を符号化および送信するために使用されるブロックを表す。これらのブロックも、以下でさらに説明される。コントローラ６７０は、ｍｕｘ６３０およびＭＰＥＧトランスポートストリーム源６０２に接続される。コントローラ６７０は、エンコーダ６００内の他のブロックにも接続することができる。
【００５７】
ＡＴＳＣ  Ｍ／Ｈブロック６１０内では、パケットインタリーバ６１２が、パケットに編成されるデータのストリームを受け取る。各パケットは、１８７バイトを含み、パケット識別に使用される３バイトのヘッダを含む。パケットインタリーバ６１２の出力は、ＧＦ（２５６）  ＳＣＢＣ（直列連結ブロックコーダ（Ｓｅｒｉａｌ  Ｃｏｎｃａｔｅｎａｔｅｄ  Ｂｌｏｃｋ  Ｃｏｄｅｒ））６１４に提供される。ＧＦ（２５６）  ＳＣＢＣ６１４の出力は、パケットデインタリーバ６１６に接続される。パケットデインタリーバ６１６の出力は、トランスポートストリームヘッダ変更器６１８に接続される。トランスポートストリームヘッダ変更器６１８の出力は、事前トランスポートパケット挿入器６２０に接続される。事前トランスポートパケット挿入器６２０の出力は、ｍｕｘ６３０に接続される。
【００５８】
パケットインタリーバ６１２は、行に配列されたパケットとして受け取ったデータを、パケットの行からバイトの列への読み替えに基づいて、符号語に再編成する。パケットインタリーバ６１２は、図７に示されるように、一定数の連続するパケットから行方向順にバイトを取得し、図８に示されるように、列方向順にバイトを出力する。特に、図７および図８は、１２行分の１８７バイトパケットを読み込み、１８７列分の１２バイト符号語を出力する。パケットインタリービングの結果として、バイト０と表記された第１バイトのすべては、一緒にグループ化され、バイト１と表記された第２バイトのすべては、一緒にグループ化され、以降も同様である。インタリーバに読み込まれる個数分のパケットは、ソースフレームを構成し、パケットの数は、ＧＦ（２５６）  ＳＣＢＣ６１４における処理で必要とされるソース符号語またはシンボルの数に等しい。パケットインタリーバ６１２の次元は含まれるメモリのタイプおよびサイズに基づいて変更できることに留意することが重要である。例えば、第１の次元を列に変更し、第２の次元を行に変更することができる。加えて、他の次元構成を使用することもできる。
【００５９】
ＧＦ（２５６）  ＳＣＢＣ６１４は、先に説明されたバイトコードエンコーダに類似したブロック符号エンコーダである。特に、ＧＦ（２５６）  ＳＣＢＣ６１４は、ガロア体（２５６）空間上の短い線形ブロック符号を使用して実施される。２つの構成ブロック符号を使用することができる。レート１／２ブロック符号エンコーダは、以下の生成行列（ｇｅｎｅｒａｔｏｒ  ｍａｔｒｉｘ）を使用する。
【００６０】
Ｇ＝（１  ２）  （３２）
【００６１】
（３２）の行列は、２の値を有する式（２）のｂ要素を含み、これは、第２の列に存在する。レート２／３ブロック符号エンコーダは、以下の生成行列を使用する。
【００６２】
【数４】
2011501926.tif 000006
【００６３】
生成行列は、単位行列と、ｂ要素からなる列とを使用して形成される。行列（３３）の第３の列は、２の値を有する式（３）のｂ要素を含む。同様に、レート１／４ブロック符号エンコーダは、以下の生成行列を使用する。
【００６４】
Ｇ＝（１  ２  ２  ２）  （３４）
【００６５】
（３４）の行列は、２の値を有する式（２９）、（３０）、および（３１）のｂ要素を含み、これらは、第２の列、第３の列、および第４の列に配置されている。各構成符号のための生成行列内の係数は、ブロック符号符号化と誤り訂正システムおよび変調プロセスの全体との関係に基づいて最適化されていることに留意することが重要である。他の係数を使用することもできる。最適化は特に、８−ＶＳＢ変調におけるトレリスコーディングおよびビット対シンボルマッピング（ｂｉｔ  ｔｏ  ｓｙｍｂｏｌ  ｍａｐｐｉｎｇ）を考慮しているが、それは、これらの側面が、受信および復調プロセスにおける第１の側面であるためである。
【００６６】
ＧＦ（２５６）  ＳＣＢＣ６１４は、単一ブロック符号エンコーダまたは連結ブロック符号エンコーダとすることができる。連結ブロック符号エンコーダは、先に説明されたインタリービングおよびパンクチャリングなどの他の機能を含むことができる。ＧＦ（２５６）  ＳＣＢＣ６１４は、多数のエンコーディングレートで符号化することを可能にすることもでき、さらに図示されていないレートモードコントローラを介してレートモードを切り替えることを可能にすることもできる。好ましい一実施形態では、ＧＦ（２５６）  ＳＣＢＣ６１４は、図１で説明されたようなレート１／２構成符号、図２で説明されたようなレート１２／２６符号、または図４で説明されたようなレート２４／２０８符号の１つを使用して、データの到来ストリームを符号化するように適合することができる。
【００６７】
ＧＦ（２５６）  ＳＣＢＣ６１４は、インタリーバ６１２から出力された列に沿ってバイトを符号化する。言い換えると、ＧＦ（２５６）  ＳＣＢＣ６１４は、パケットインタリーバ６１２における処理によって形成されたインタリーバ行列の第２の次元に従って符号化する。
【００６８】
パケットデインタリーバ６１６は、ＧＦ（２５６）  ＳＣＢＣ６１４によって生み出された符号語の符号化ストリームを受け取り、１８７バイトパケットからなる再構成された行を出力する。パケットデインタリーバ６１６は、各列がＧＦ（２５６）  ＳＣＢＣ６１４における処理によって追加された冗長または非システマティックバイトを含む列方向順に、符号化された符号語を入力し、行方向編成でバイトを出力する。このプロセスは基本的に、パケットインタリーバ６１２に関して説明されたプロセスの逆であり、図７および図８の順序が逆になる。パケットデインタリーバ６１６は、同じ列数の符号語を入力し、今では各符号語は、符号化された非システマティックバイトの組を含む。出力における行の数は、符号化された符号語の長さに対応する。例えば、１２／２６の符号化率では、２６行のパケットが出力される。パケットデインタリーバ６１６の次元は含まれるメモリのタイプおよびサイズに基づいて変更できることに留意することが重要である。さらに、第１の次元を行に変更し、第２の次元を列に変更することができる。加えて、他の次元構成を使用することもできる。
【００６９】
パケットは、２つの異なるグループに編成することができる。パケットの第１のグループは、システマティックパケットと呼ばれることがあり、トランスポートストリーム源６０２によって提供された元のデータのパケットと同じである。パケットの第２のグループは、非システマティックパケットと呼ばれることがあり、ＧＦ（２５６）  ＳＣＢＣ６１４におけるブロックコーディングプロセスによって形成されるパリティパケットである。ブロックコーディングプロセスの結果として、列の数（すなわち第２の次元のサイズ）が増加することに留意することが重要である。
【００７０】
ＭＰＥＧトランスポートストリームヘッダ変更器６１８は、システマティックパケットのグループおよび非システマティックパケットのグループを含む、デインタリーブされた１８７バイトパケットを受け取る。先に説明されたように、各パケットは、３バイトヘッダを含む。その３バイトは、パケットに関する情報を伝えるのに使用されるいくつかの他のビットまたはビットのグループとともに、ＰＩＤを含む。レガシまたはＡ５３放送信号を受信することは可能であるが、ＡＴＳＣ  Ｍ／Ｈ符号化パケットを正しく復号および／または認識することが可能でない受信機（例えばレガシ受信機）の最も効率的な動作を維持するため、ＡＴＳＣ  Ｍ／Ｈパケットの一部のヘッダ内のあるビットを変更することができる。非システマティックパケットヘッダ内のこれらのビットを変更することによって、パケットを不正とは見なさないものの、レガシ受信機にパケットを無視させる。例えば、ＭＰＥＧトランスポートストリームヘッダ変更器６１８は、ＴＥＩビット、ペイロードユニット開始インジケータビット、およびトランスポートプライオリティビットを、ビット値の「０」に設定することができる。加えて、スクランブリング制御ビットおよびアダプテーションフィールド（ａｄａｐｔａｔｉｏｎ  ｆｉｅｌｄ）ビット（各々２ビット）を「００」に設定することができる。３ビット長の連続性カウンタ（ｃｏｎｔｉｎｕｉｔｙ  ｃｏｕｎｔｅｒ）も「０００」に設定することができる。最後に、ＰＩＤは、すべてのレガシ受信機によって無視される既知の値など、一意的かつ未使用の値に設定することができる。ＭＰＥＧトランスポートストリームヘッダ変更器６１８は、非システマティックパケットのグループに対して、各ヘッダを変更するので、非システマティックパケットのグループに対しては、ＧＦ（２５６）  ＳＣＢＣ６１４のヘッダ処理を不要にできることに留意することが重要である。加えて、ＭＰＥＧトランスポートストリームヘッダ変更器６１８は、システマティックパケットがレガシ受信機によって処理され、正しく復号されるべきでない場合、これらのパケットのヘッダも変更することができる。システマティックパケットが、ＧＦ（２５６）  ＳＣＢＣ６１４によって符号化されない場合、またはＭＰＥＧトランスポートストリームヘッダ変更器６１８によって処理されない場合、結果のデータのストリームは、モバイルデバイスおよびレガシ受信機の両方に同報され、その両方によって受信することができる。
【００７１】
事前トラッキングパケット挿入器６２０は、所定のトラッキングパケットを頑健なデータストリーム内に配置することができる。所定のパケットは、モバイルデバイス、歩行者用デバイス、またはハンドヘルドデバイスにおいて使用される受信機など、頑健なデータストリームを受信することが可能な受信機に完全にまたはほとんど知られている情報からなるパケットを表す。所定のパケットは、信号符号化および送信のうちのレガシまたは既存Ａ５３符号化部分の最中に生成されたトレリス状態の復号を支援するために、受信機において使用される。所定のパケットは、受信機の等化器部分における収束を支援することもできる。所定のパケットは、レガシ受信機における受信の改善を意図してはいないが、それでも改善の可能性をもたらし得ることに留意することが重要である。また、従来のトレーニング情報とは異なり、所定のパケットは、追加的なレガシ符号化が実行される前に追加されるので、送信機出力において直接的に識別可能ではない。特に、所定のパケットは、トレリス符号化の処理によって変更される。結果として、所定のパケットは、トレリス復号中に直接的なトレーニングを提供しないが、代わりに、トレリス復号マップまたはブランチを決定する際に使用される事前ブランチ情報を提供する。
【００７２】
所定のトラッキングパケットは、知られたトレーニング系列プロセスを使用する多くの方法で生成することができる。好ましい一実施形態では、所定のトラッキングパケットは、受信機にも知られているＰＮ（疑似乱数）発生器を使用して生成された残りのバイトとともに有効ヘッダを含む。事前トレーニングデータ、トレリスオブスキュアド（ｔｒｅｌｌｉｓ−ｏｂｓｃｕｒｅｄ）トレーニングデータ、または疑似トレーニングパケットと呼ばれることもある所定のトラッキングパケットは、ＡＴＳＣ  Ｍ／Ｈ送信全体にわたって何らかの仕方で分散させることができ、またはグループ内に群集させることができ、それにはＡＴＳＣ  Ｍ／Ｈ信号送信用のプレアンブルとして役立つ仕方でパケットもしくはパケットのグループを配置することを含む。
【００７３】
ＡＴＳＣ  Ｍ／Ｈブロック６１０において生成された頑健または堅牢なデータストリームは、ｍｕｘ６３０に提供される。ｍｕｘ６３０は、図示されていないデータ源からレガシデータストリームも受け取る。いくつかの実施形態では、レガシデータストリームは、ＭＰＥＧトランスポートストリーム源６０２から提供されてよいことに留意されたい。ｍｕｘ６３０は、到来した堅牢なＡＴＳＣ  Ｍ／Ｈデータストリームおよびレガシデータストリームの部分を記憶するために、バッファメモリを含むことができる。ｍｕｘ６３０は、頑健なＡＴＳＣ  Ｍ／Ｈデータストリームとレガシデータストリームを一緒にした時間多重化を生成し、多重化ストリームをＡＴＳＣ  Ａ５３レガシブロック６５０に提供する。
【００７４】
ｍｕｘ６３０は、コントローラ６７０によって制御される。コントローラ６７０は、マイクロプロセッサまたはマイクロコントローラとして具現される別個の回路とすることができる。あるいは、コントローラ６７０は、ＭＰＥＧトランスポートストリーム源６０２など、他のブロックの１つに含まれることもできる。コントローラ６７０は、変調および送信装置全体の動作のために使用されるコントローラ内に組み込むこともできる。ｍｕｘ６３０に制御を提供することに加えて、コントローラ６７０は、ｍｕｘ６３０の切り替えを制御するために、堅牢なデータストリーム、レガシデータストリーム、またはその両方を監視することもできる。コントローラ６７０は、堅牢なデータストリームの送信に関連する制御情報を生成することもできる。制御情報は、ＭＰＥＧトランスポートストリーム源６０２または他のストリーム源ブロックに提供される制御データからなる１つまたは複数のパケットの形式をとることができる。加えて、制御情報は、ＭＰＥＧトランスポートストリームヘッダ変更器６１８など、エンコーダ内の他のブロックにも提供することができ、また堅牢なデータストリーム内に挿入すること、または堅牢なデータストリームとともに含ませることができる。コントローラ６７０は、エンコーダ符号化率の設定および事前パケット挿入など、エンコーダ６００内のブロックの他の動作の制御も含むことができる。
【００７５】
レガシＡＴＳＣエンコーダ６５０は、多重化データストリームとして提供されたシステマティックパケットと非システマティックパケットを、レガシＡ５３規格に従って同じように符号化する。データランダマイザ６５２は、パケットをランダム化し、そのパケットをリード−ソロモンエンコーダ６５４に提供する。リード−ソロモンエンコーダ６５４は、２０個のパリティバイトを計算し、それらをランダム化データに連結して、２０７バイトを有するＲ−Ｓパケットを生み出す。
【００７６】
畳み込みインタリーバ６５６は、時間的にデータをさらにランダム化するために、Ｒ−Ｓパケットをインタリーブする。トレリスエンコーダ６５８は、インタリーブパケットを符号化して、８２８個の３ビットシンボルからなるブロックを生み出す。Ａ５３規格は、１２個のトレリスエンコーダの使用を規定し、各トレリスエンコーダは、インタリーブパケット内に存在する２ビットにつき３ビットシンボルを生み出す、２／３レートトレリスエンコーダである。結果として、トレリスエンコーダ６５８は、デマルチプレクサと、１２個の並列２／３レートトレリスエンコーダと、マルチプレクサとを含む。畳み込みインタリーバ６５６からのデータは、逆多重化され、１２個のトレリスエンコーダに分配され、１２個のトレリスエンコーダによって生成されたシンボルは、シンボルのストリームに多重化される。
【００７７】
ｓｙｎｃ挿入器６６０は、各８２８シンボルブロックの先頭に４つの事前定義されたセグメント同期シンボルを挿入して、８３２シンボルセグメントを生成する。加えて、ｓｙｎｃ挿入器６６０は、生成された３１２個のセグメント毎に８３２個のシンボルを含むフィールド同期を挿入する。特に、フィールド同期シンボルは、３１２個のセグメントの前に置かれる。
【００７８】
８−ＶＳＢ変調器６６２は、８−ＶＳＢ（残留側波帯（ｖｅｓｔｉｇｉａｌ  ｓｉｄｅｂａｎｄ））変調を使用して搬送波信号を変調するために、トレリスエンコーダ６５８によって符号化されたデータ、セグメント同期シンボル、およびフィールド同期を含む多重化シンボルを使用する。具体的には、８−ＶＳＢ変調器６６２は、ＰＡＭ（パルス振幅変調）信号を生成する。ＰＡＭ信号の振幅は、８つの離散的レベルの１つにあり、各離散レベルは、特定の３ビットシンボルに対応する。ＰＡＭ信号は、デジタル信号フォーマットからアナログ信号フォーマットに変換され、正確な信号パルス形状を生み出すためにフィルタリングされ、図示されていない回路を使用して、無線周波数にアップコンバートされる。
【００７９】
ＭＰＥＧトランスポートストリーム源６０２またはレガシコンテンツ用のソースなどの送信源によって生成されたデータは、ＩＳＯ／ＩＥＣ（国際標準化機構／国際電気標準会議）１３８１８−２フォーマットにも等しい、ＭＰＥＧ（モーションピクチャエンタテイメントグループ）２フォーマットを使用して情報源符号化されたビデオを含む。データは、ドルビＡＣ−３（アーク整合性（Ａｒｃ  Ｃｏｎｓｉｓｔｅｎｃｙ）アルゴリズム＃３）を使用して情報源符号化されたオーディオデータも含む。Ａ５３規格は、番組ガイドデータなど、他の番組要素のためのメタデータの使用も可能にし、そのような番組要素は、他の方法を使用して情報源符号化することができる。加えて、Ａ５３規格は、標準精細度インタレーステレビ品質からプログレッシブスキャンワイドスクリーン高精細度品質にわたる、様々なビデオ品質レベルおよび表示フォーマットでのビデオの送信を可能にする。
【００８０】
送信機器の既存のハードウェア構造に、最低限の変更を施すだけで、頑健または堅牢なデータストリームを生み出すＡＴＳＣ  Ｍ／Ｈブロック６１０の付加機能を追加することができる。加えて、ＡＴＳＣ  Ｍ／Ｈブロック６１０において、ＭＰＥＧトランスポートストリーム源６０２から到来するパケットの部分を抽出して、エンコーディングレートの１つまたは複数で符号化することができる。その場合、符号化パケットは、コントローラ６７０の制御下でｍｕｘ６３０を使用して、入力パケットの残りの無処理部分に挿入または追加することができ、ストリームの頑健な符号化部分および無処理部分はともに、ＡＴＳＣ  Ａ５３レガシエンコーダ６５０において符号化される。あるいは、パケットの個別のストリームをＡＴＳＣ  Ｍ／Ｈブロック６１０に提供することができ、符号化出力が、パケットの第２のストリームに挿入または追加されて、ＡＴＳＣ  Ａ５３レガシエンコーダ６５０に提供される。
【００８１】
コントローラ６７０は、ｍｕｘ６３０用の制御回路に加えて、付加的な処理回路も含むことができる。コントローラ６７０は、頑健なデータストリームおよびレガシデータストリームを監視し、頑健な符号化データのバーストの長さ、またはレガシデータのコンテンツデータレートおよびレガシデータ内のデータ挿入ポイントなど、そのデータストリームの特徴を決定するための回路を含むことができる。コントローラ６７０は、決定された特徴に基づいて付加的な制御情報を生成し、この付加的な制御情報を、エンコーダ内に示されたＭＰＥＧトランスポートストリームヘッダ変更器６１８などのブロックならびに変調および送信装置の他の部分に提供することもできる。コントローラ６７０は、変調および送信装置の他の部分から情報を受け取り、その情報を処理して、エンコーダ６００内のｍｕｘ６３０および他のブロックを制御するために必要な制御情報を生成することもできる。コントローラ６７０は、受け取った情報を使用して、頑健または堅牢なデータストリーム内に含める制御情報を生成することもできる。
【００８２】
図９を参照すると、ＡＴＳＣモバイルデータ送信用のデータの編成９００を示す図が示されている。編成９００では、データは、セグメントまたはブロック内に編成され、各ブロックは、データのパケットの組を含む。一実施形態では、各データブロックは、ＡＴＳＣ  Ｍ／Ｈエンコーダ６１０におけるデータのパケットの編成に一致する、データの２６個のパケットを表す。２つのプリアンブルブロック９１０ａおよび９１０ｂが、信号送信に先立ってレガシＡ５３規格に従って追加されるフィールド同期９４０ａに時間的に先行する位置に示されている。プリアンブルブロック９１０ａおよび９１０ｂは、事前トラッキングパケット挿入器６２０によって挿入される事前トレーニングパケットを含む。プリアンブルブロック９１０ａおよび９１０ｂの存在は、ＡＴＳＣモバイルデータが送信されていることの１つの標識を提供する。
【００８３】
ＡＴＳＣモバイルデータバーストを含む一連のデータブロック９３０ａ〜９３０Ｎが、プリアンブルブロック９１０ａおよび９１０ｂの後に続く。データブロックの数Ｎは、所望の送信バーストに応じて可変であり、短い場合には１ブロックのこともあり、または必要な長さだけ連続的に続くこともある。データブロック０として識別されるデータブロック９３０ａは一般に、現在のデータバースト用の制御情報を含むことができる。データブロック９３０ａは、制御情報のみを含むことができ、さらにモバイルデータバースト用の制御ブロックと呼ばれることもある。制御情報は、堅牢な符号化モバイルデータの受信のために受信機内のデコーダによって必要とされるパラメータを含む。制御情報は、送信システム内で、図１のデータ生成器１０２などのデータ生成器、または図６のコントローラ６７０において生成される。制御情報は、有効ＭＰＥＧヘッダを有する有効ＭＰＥＧパケットとして生成することができる。定義データバイトを含む制御情報用の例示的な構造が、以下の表に示されている。
【００８４】
【表１−１】
2011501926.tif 000007
【００８５】
【表１−２】
2011501926.tif 000008
【００８６】
各要素のシンタックスのフォーマットは、ｕｉｍｓｂｆ（最上位ビットを先頭とする符号なし整数（ｕｎｓｉｇｎｅｄ  ｉｎｔｅｇｅｒ  ｍｏｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔ  ｆｉｒｓｔ））であるか、または事前定義されており、ここでさらに説明される。要素の各々は、頑健または堅牢なデータストリームの送信において使用される制御要素を表す。ｆｉｅｌｄ  ｎｕｍｂｅｒは、エポック（ｅｐｏｃｈ）フィールドのための特定のフィールド開始を識別するための順次的番号である。データブロック９３０ａ内の制御パケットの後に続くフィールド同期９４０ｂが、フィールド１として識別される。エポックは、スポーツチャンネルまたはニュースチャンネルなど、特定のコンテンツソースまたはコンテンツチャンネルを用いて識別されるパケットのストリームである。エポックは、繰り返すことができ、モバイルデータバーストの一部だけを含むことができる。加えて、制御情報は、エポック長のトラッキングを可能にする。
【００８７】
ｂｕｒｓｔ＿ｔｙｐｅは、周期的または可変として指示することができる。各タイプについて、追加的パラメータが提供される。周期的バーストの場合（値＝１）、ｂｕｒｓｔ＿ｎｕｍｂｅｒは、特定のバーストを識別するための順次的番号である。バースト毎に、番号が、直前のバーストから１だけ増やされる。ｂｕｒｓｔ＿ｎｕｍｂｅｒは、０ｘＦＦＦＦの次は先頭に戻り、再び０ｘ００００から増え始める。ｂｕｒｓｔ＿ｌｅｎｇｔｈは、現在の周期的バーストの（パケット単位またはブロック単位の）長さを識別する。いくつかのレートモードを定義し、エポックなどのサービスのために与えられたエンコーディングレートでのデータの長さとともに含めることができる。データバースト内では、レートモードは、以下の値を有するとして定義される。
【００８８】
１２／５２レートコーディング
１２／２６レートコーディング
１７／２６レートコーディング
２４／２０８レートコーディング
【００８９】
識別された各レートモードは、識別されたレートにおける連続ブロックの数を表すブロックカウント値を含む。多数の符号化率を使用してデータブロックを送信するために使用される順番は、モバイル受信機またはハンドヘルド受信機における受信性能に利点を提供できることに留意することが重要である。好ましい一実施形態では、符号化率２４／２０８を使用するデータブロックが、最初に送信されるべきである。符号化率１２／５２を使用するデータブロックが、２番目に送信されるべきである。符号化率１７／２６を使用するデータブロックが、３番目に送信され、符号化率１２／２６を使用するデータブロックが、最後に送信されるべきである。制御情報は、ｎｅｘｔ＿ｐｅｒｉｏｄｉｃ＿ｂｕｒｓｔ＿ｔｙｐｅおよびｎｅｘｔ＿ｐｅｒｉｏｄｉｃ＿ｂｕｒｓｔ＿ｃｏｕｎｔ、ならびに次の周期的バーストのエンコーディングレートのタイプおよび長さで定義される、次の、後続する、または来つつある周期的送信バーストのための情報も含む。
【００９０】
可変バースト用の制御情報は、周期的バーストの制御情報と類似している。現在のモバイルデータバーストおよび次のモバイルデータバーストのための情報が提供される。ｎｅｘｔ＿ｖａｒ＿ｂｕｒｓｔ＿ｃｏｕｎｔ＝０は、現在のエポックまたはサービスに基づいた追加的な堅牢なバーストデータが利用可能でないことを示す。
【００９１】
ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、現在のパケットの長さを超えて制御情報が続くことを可能にする。結果として、制御情報が１８４バイトを超える場合、このフラグは１となり、制御情報は、次の１８４バイトパケットへと続く。データブロック９３０ａ内のパケット内の制御情報を正確に伝達する能力を変えることなく、表に示された情報の順序の変更が可能であり得ることに留意することが重要である。
【００９２】
データブロック９３０ａの一部として含まれる制御パケットの情報は、多くの可能な構成で生成し、送信することができる。上で説明されたように、制御パケットは、２つの連続するＡＴＳＣ  Ｍ／Ｈデータバーストのコンテンツを定義するのに必要なシステム情報を含むことができる。加えて、ただ１つのコーディングレートが使用される場合、制御パケットは一般に、データブロック９３０ａ内の残りの２６個のパケット内のデータと同じコーディングレートを有することができ、モバイルデータバースト内の残りのデータブロックと同じコーディングレートを有することができる。最良の受信および復号の機会を可能にするために、多数の符号化率が使用される場合、データブロック９３０ａは、現在のモバイルデータバースト内で使用される最低のコーディングデータレート（すなわち最低量の元のコンテンツデータを送信するコーディングレート）を用いて符号化することができる。
【００９３】
上で説明された制御情報は、モバイル受信機またはハンドヘルド受信機の動作の効率的なプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）を可能にする。制御情報は、利用可能ないくつかの中から１つのサービスまたは１つのエポックだけを受信するなど、受信機アプリケーションが多重モバイルデータの一部のみを必要とする場合に、電力を節約する受信機の実施を可能にする。さらに、制御規定は、受信機によって独立に回復され得る「仮想ストリーム（ｖｉｒｔｕａｌ  ｓｔｒｅａｍ）」と呼ばれるサブセットストリームに到来信号を分割することを可能にする。制御情報を介して識別されるこれらの仮想ストリームの時分割多重から、電力節約およびより高い動作効率性がもたらされる。例えば、堅牢なデータストリームの時分割多重に関連するパラメータは、符号化率識別子およびエポック識別子を使用してモバイル受信機に送信される。モバイル受信機は、対象データを含まない時間間隔の間、受信機がシャットダウンまたは「スリープ」モードに入ることを可能にし、電力消費の低減をもたらす、制御情報内のパラメータを回復および復号する。
【００９４】
制御ブロックは、絶対時間値を確立および送信するための規定も含むことができる。絶対時間値の送信は、異なるネットワーク周波数、送信アンテナ位置、または放送送信局を用いて動作する連携ネットワークから配信されるコンテンツのシームレスな受信デバイス移行（ｓｅａｍｌｅｓｓ  ｒｅｃｅｉｖｉｎｇ  ｄｅｖｉｃｅ  ｔｒａｎｓｉｔｉｏｎ）などの特徴の実施を可能にすることができる。
【００９５】
上で説明されたように、エンコーダ６００および関連制御情報は、データブロック１個の短いデータバースト、または堅牢なモバイル放送データを完全に送信するのに必要とされる長いデータバーストを送信するために、柔軟性を含む。堅牢なモバイル放送データバーストは、必要であれば、レガシ受信機において使用されるレガシデータの送信を著しく削減して、連続データ送信に接近することができる。しかし、レガシ受信機の適切な動作を維持しなければならない場合に、実際的な問題が生じることがある。レガシ受信機は、機能が停止したように視聴者から見えることなく動作を継続するために、到来受信データの適切なコンテンツ復号に依存することがある。コンテンツデータの適切な復号および認識の失敗は、受信機をサーチモードに入らせることがあり、またはユーザに他の何らかの望ましくないエラー表示を提供することがある。ＡＴＳＣモバイルデータの長いデータバーストのせいで、レガシ受信機において長期間にわたるコンテンツデータの認識不能が発生すると、さらに、オーディオとビデオ表示の間に同期誤差が生じることがあり、またはオーディオコンテンツおよびビデオコンテンツを保存するために使用されるバッファにおいてバッファアンダフローが生じることがある。
【００９６】
長いモバイルデータバーストの送信によって引き起こされる問題に対処するため、レガシデータオーバレイモード（ｌｅｇａｃｙ  ｄａｔａ  ｏｖｅｒｌａｙ  ｍｏｄｅ）を導入することができる。レガシデータオーバレイモードでは、レガシデータの１つまたは複数のデータブロックが、モバイルデータバースト内に挿入される。必要であれば、レガシデータの多数のデータブロックを挿入することができ、堅牢なモバイルデータバーストの長さに応じて、レガシデータブロックを周期的に挿入することができる。一実施形態では、既存のレガシ受信機の同期および動作を維持するために、データブロック９３０ｋが、フィールド同期９４０の位置の直前に挿入されたレガシデータのブロックを含む。レガシデータを含む頻度はレガシ受信機性能に基づいて経験的に決定できることに留意することが重要である。例えば、堅牢なモバイルデータバーストが２４ミリ秒よりも長く続く送信において、各フィールド同期の間に、レガシデータの１個から２個のデータブロックを挿入することができる。
【００９７】
レガシデータオーバレイモードを識別するため、制御ブロック９３０ａは、レガシデータオーバレイモードの使用および存在、ならびにレガシデータを含む１つまたは複数のデータブロックの識別についての情報を含むことができる。上で説明された情報と同様に、モバイルデータバーストとともに送信される制御情報内のレガシオーバレイモード識別およびレガシデータブロック位置は、モバイル受信機またはハンドヘルド受信機におけるより効率的な動作およびプロビジョニングを可能にする。加えて、コントローラ６７０またはＭＰＥＧトランスポートストリーム源６０２は、モバイルデータバーストの長さを監視し、レガシデータブロックの包含および位置を識別するための制御情報を挿入することができる。コントローラ６７０は、入力を堅牢なモバイルデータバーストからレガシデータストリームに切り替えて、レガシストリームデータブロックを挿入するために、制御信号をｍｕｘ６３０に提供する。レガシストリームデータブロックが挿入された後、ｍｕｘ６３０は、入力を堅牢なモバイルデータバーストに再び切り替える。堅牢なモバイルデータバーストの長さに応じて、モバイルデータバーストの２つ以上の部分がレガシデータブロックを含み得ることに留意することが重要である。
【００９８】
コントローラ６７０は、コントローラ６７０による少なくとも１つのデータストリームの監視に基づいた、ｍｕｘ６３０による堅牢なモバイルデータストリームとレガシデータストリームの間の切り替えも制御することができる。一実施形態では、コントローラ６７０は、レガシデータストリームのデータレートを監視する。先に言及されたように、レガシデータストリームは、１９Ｍｂ／秒という高いデータレートを含むことができる。しかし、ある期間の間、レガシデータレートは、より低くなることがある。コントローラ６７０は、レガシストリームデータレートを監視する。レガシデータストリームのデータレートがある期間にわたって所定の閾値を下回る場合、コントローラ６７０は、入力をレガシデータストリームから切り替えるために信号をｍｕｘ６３０に提供し、堅牢なモバイルデータの１つまたは複数のブロックの挿入を可能にする。３０秒間にわたって１０Ｍｂ／秒の閾値を下回ると、最高で９Ｍｂ／秒（符号化後）の堅牢なデータストリームを３０秒間にわたって含めることが可能になる。結果として、コントローラ６７０は、送信レガシ信号を検出し、第１の信号のデータレートがデータレート閾値を下回る場合、レガシ信号に代わって堅牢な信号の送信だけを許可する。レガシデータレートが低い間の時間多重制御の使用は、堅牢なデータが特定の配信時間に影響されにくい場合、モバイル受信機に送信される堅牢なデータにとって役立つことがある。
【００９９】
ここで図１０を参照すると、符号化プロセス１０００の一実施形態を示すフローチャートが示されている。プロセス１０００は、データの入力ストリームから頑健なデータストリームを生成するために使用できる、連結バイトコード符号化プロセスを示している。プロセス１０００は、主として、図２に示された連結バイトコードエンコーダ２００を参照して説明される。しかし、プロセスは、図４に示され、上で説明されたエンコーダ４００を含む、任意のバイトコードエンコーダに容易に適合させることができる。プロセス１０００は、個別処理ブロックまたは必要なブロックの一部もしくは全部を含む集積回路を含むハードウェアを使用して、マイクロプロセッサデバイスにおいて動作するソフトウェアを使用して、あるいはハードウェアおよびソフトウェアの組み合わせで実行できることに留意することが重要である。加えて、プロセス１０００は、データのバイト、符号語、およびパケットを参照して説明される。しかし、他のデータ構成または編成が可能であり、使用できることは、当業者には明らかであろう。
【０１００】
最初にステップ１０１０において、データのストリームが受け取られる。データのストリームは、数バイトのデータが符号語としてグループ化でき、さらに１つまたは複数の符号語の全部または一部を含むパケットに編成できるように、編成することができる。例えば、データは、１８７バイトのデータを含むパケットに編成することができ、各パケットは、識別目的で使用されるパケットヘッダを含む。次にステップ１０２０において、データのパケットが、バイトコード符号化される。ステップ１０２０における符号化は、先に説明された構成エンコーダの１つを使用して実行することができる。例えば、符号化ステップ１０２０は、データの１２個の入力バイト毎に１８バイトのデータを出力する結果をもたらす、レート２／３バイトコード符号化を使用することができる。
【０１０１】
あるいは、符号化ステップは、レート１／２などの別のバイトコードエンコーディングレートを使用することもできる。符号化ステップ１０２０は、データの入力バイトを補足するために、式（３２）から式（３４）に示されたような生成行列を使用することができる。入力データの補足は、バイトコード符号化プロセスまたはブロックコード符号化プロセスなどの符号化プロセスを介した、誤り訂正バイトまたは冗長データバイトの生成を含む。出力バイトは、システマティックバイトとして知られる、データの１２個の入力バイトの複製を、６バイトの冗長または非システマティックデータとともに含む。
【０１０２】
符号化ステップ１０２０は、符号語の分離または逆多重化も含むことができる。逆多重化は、符号語の２つ以上の部分を生成し、各部分に別々のバイトコード符号化を施すことを可能にする。別々のバイトコード符号化は、並列方式で、またはより高い処理クロック速度による順次方式で実行することができる。分離または逆多重化は、図４のエンコーダ４００において説明されたように符号語を処理するために使用することができる。
【０１０３】
次にステップ１０３０において、ステップ１０２０からの符号化データバイトがインタリーブされる。いくつかのインタリービング編成を使用することができる。例えば、図３に示されたようなインタリービング編成である。図３のインタリービング編成は、相対的に小さなインタリーバサイズに対して提供され、バイトコード符号化ステップ１０２０において生成された符号の距離を最大化する。言い換えると、インタリーバサイズは、白色雑音の存在下でバイト誤り率を低減するように最適化することができる。次にステップ１０４０において、ステップ１０３０からのインタリーブバイトは、第２のバイトコード符号化を施される。第２のバイトコード符号化ステップ１０４０は、先に説明された構成エンコーダの１つを使用して実行することができる。例えば、ステップ１０４０における符号化は、データの１８個の入力バイト毎に２７バイトのデータを出力する結果をもたらす、レート２／３バイトコード符号化を使用することができる。あるいは、符号化ステップは、レート１／２などの別のバイトコードエンコーディングレートを使用することもできる。符号化ステップ１０４０は、上述のように、データの入力バイトを補足するために、式（３２）から式（３４）に示されたような生成行列を使用することができる。出力バイトは、システマティックバイトとして知られる、データの１８個の入力バイトの複製を、８バイトの冗長データまたは非システマティックデータとともに含む。いくつかのシステマティックバイトは、元の入力データのバイトの１つの複製とすることができ、または第１のバイトコード符号化ステップ１０２０によって冗長もしくは非システマティックバイトとして作成されたバイトとすることができることも明らかであろう。
【０１０４】
次にステップ１０５０において、データのバイトの第２の符号化ストリームがパンクチャリングされる。パンクチャリングステップ１０５０は、第２の符号化ストリームからデータのバイトの１つを削除する。削除されるバイトは、第２の符号化ステップ１０４０の非システマティックバイトとすることができ、さらに第１の符号化ステップ１０２０からの非システマティックバイトとすることもできる。最後にステップ１０６０において、データストリームが、レガシまたは既存のＡ５３符号化などの付加的な処理に提供される。ステップ１０６０は、データストリームを提供するのに先立って、符号化バイトを、最初に受け取った編成に類似したパケットに再パケット化することも含むことができる。説明されたプロセス１０００は、レート１２／２６バイトコード符号化データストリームの生成をもたらす。
【０１０５】
ステップ１０５０におけるパンクチャリングは、プロセス１０００から削除することができる。削除されるバイトの選択は、ステップ１０３０におけるインタリービングに基づいて実行される。例えば、第２の符号化ステップ１０４０は、その符号化の一部として非システマティックバイトの１つを生成しないことができ、直接的にパンクチャストリームをもたらすことを可能にすることができる。加えて、パンクチャリングステップ１０５０は、非パンクチャレート１２／２７のバイトコード符号化データストリームを生み出すためにバイパスすることもできる。
【０１０６】
ステップ１０５０におけるパンクチャリングは、第２の符号化ストリームから２バイト以上を削除することもできる。例えば、削除される３バイトを識別して、レート１２／２４のバイトコード符号化データストリームを生み出すことを可能にすることができる。２バイト以上のパンクチャリングは、符号化の有効性をさらに低下させるが、コーディングレートの改善を獲得する。パンクチャリングステップ１０５０におけるさらなるバイトの削除は、ステップ１０３０の最適インタリービングに基づいて達成される。このように、パンクチャリングとインタリービングとは、先に説明されたように、与えられた出力ブロックサイズの出力パケットを生み出すことに基づいた最適符号化率を可能にするために対話する。
【０１０７】
ステップ１０３０および１０４０は、２つのインタリービングステップおよび３つのバイトコード符号化ステップを含む異なる連結バイトコード符号化プロセスを形成するために、反復できることに留意することが重要である。反復ステップ１０３０および１０４０を使用するプロセスは、レート１２／５２の頑健なデータストリームを生成するために、エンコーダによって使用することができる。さらに、ステップ１０５０は、出力データストリームを形成するために、符号語の２つ以上の並列部分の再組み合わせまたは逆多重化も含むことができる。再組み合わせは、図４のエンコーダ４００などの並列構造バイトコードエンコーダと併せて使用される。プロセス１０００は、先に上で説明されたような他の符号化率にも容易に適合させることができる。
【０１０８】
ここで図１１を参照すると、符号化プロセス１１００の別の実施形態を示すフローチャートが示されている。プロセス１１００は、やはり既存またはレガシＡ５３信号フォーマットに準拠する、システマティックデータパケットおよび非システマティックまたは冗長データパケットを含む、ＡＴＳＣ  Ｍ／Ｈデータストリームを符号化および送信するためのステップを示している。プロセス１１００は、主として、図６に示されたエンコーダ６００を参照して説明される。上述のように、プロセス１１００は、個別処理ブロックまたは必要なブロックの一部もしくは全部を含む集積回路を含むハードウェアを使用して、マイクロプロセッサデバイスにおいて動作するソフトウェアを使用して、あるいはハードウェアおよびソフトウェアの組み合わせで実行することができる。プロセス１１００は、まさに必要とされる実施に基づいて、ある設定を削除または再編成することによって適合させ得ることに留意することが重要である。
【０１０９】
最初にステップ１１１０において、パケットのトランスポートストリームが、受け取られ、処理される。各パケットは、１８７バイトを含み、またヘッダを含む。ヘッダは、ＰＩＤの他に、パケットに関する他の情報も含む。次にステップ１１２０において、ＡＴＳＣ  Ｍ／Ｈパケット用に使用されるとして識別されたパケットが、分離または抽出される。残りのパケットは、無処理として識別される。ＡＴＳＣ  Ｍ／Ｈパケットは、組み合わされた単一のトランスポートストリームから抽出する代わりに、パケットの別々の入力トランスポートストリームとして提供できることに留意することが重要である。加えて、トランスポートストリーム内のすべてのパケットを、ＡＴＳＣ  Ｍ／Ｈパケットとして識別することもできる。これらの状況はどちらも、抽出ステップ１１２０の必要性を排除することができる。さらに、ＡＴＳＣ  Ｍ／Ｈまたは無処理として識別されたパケットは、グループ化することができ、ＡＴＳＣ  Ｍ／Ｈとして識別されたパケットは、別々のエンコーディング符号化率によってさらに識別およびグループ化することができる。好ましい一実施形態では、ステップ１１１０または１１２０において、ＡＴＳＣ  Ｍ／Ｈパケットは、図９において説明されたのと同様の編成で、ブロックにグループ化され、各ブロック内のデータのパケットの数は、そのパケットに対して使用されるコーディングレートに基づいて決定される。
【０１１０】
ステップ１１１０における処理は、ＡＴＳＣ  Ｍ／Ｈパケットとして識別されたデータの他に、レガシデータストリームに関連するデータパケットの監視も含む。レガシデータストリーム内のパケットのいくつかは、ＡＴＳＣ  Ｍ／Ｈパケットとしても識別され得ることに留意することが重要である。監視は、コンテンツデータレート、トランスポートパケットレート、データサービス中のデータの持続時間、およびデータのタイプを含むが、これらに限定されない。ステップ１１１０におけるデータの監視は、ＡＴＳＣ  Ｍ／Ｈとして識別されるパケットを決定することの他に、識別されたＡＴＳＣ  Ｍ／Ｈパケットに基づいて頑健なデータストリームの長さを決定すること、および識別されたＡＴＳＣ  Ｍ／Ｈパケット用のバイトコードエンコーディング符号化率を決定することを可能にする。制御情報は、ステップ１１１０における監視および決定に基づいて生成することができ、識別されたＡＴＳＣ  Ｍ／Ｈパケットとして頑健なデータストリームに追加することができる。
【０１１１】
次にステップ１１３０において、ＡＴＳＣ  Ｍ／Ｈとして識別されたパケットの組またはグループが、行として読み込みまたは入力され、列またはインタリーブされたパケットとして出力される。出力データの列は、符号語に等しく、各符号語のサイズは、パケットのグループのサイズに等しい。図７および図８は、ステップ１１３０における、行を読み込んで列を出力するパケットインタリービングを示す行列を示している。ステップ１１３０において使用されるインタリーバの次元は、例えば、入力列および出力行に変更でき、またはインタリーバの実施に基づいて他の任意の次元態様を使用するように変更できることに留意することが重要である。次にステップ１１４０において、ステップ１１３０からの各符号語が、ブロックコード符号化される。ステップ１１４０におけるブロックコード符号化は、プロセス１０００におけるバイトコード符号化と類似しており、単一符号化プロセスまたは連結符号化プロセスを使用することができる。例えば、ブロックコード符号化ステップ１１３０は、レート１／２構成符号、レート１２／２６符号、レート１２／５２符号、またはレート１７／２６符号を使用して、符号語を符号化することができる。
【０１１２】
次にステップ１１５０において、符号化符号語の組が、符号語を列として入力し、データパケットを行として出力することによって、パケット化デインタリーブ（ｐａｃｋｅｔ−ｄｅｉｎｔｅｒｌｅａｖｅ）される。今では入力符号語は、ステップ１１３０におけるブロックコード符号化によって生成された個数のバイトを含む。出力パケットは、１８７バイトを含むパケットに再構成される。ブロックコード符号化ステップ１１３０において生成された非システマティックバイトは、データの符号化ストリーム内においてパケットの追加行を構成する。ステップ１１５０において使用されるデインタリーバの次元は、例えば、入力列および出力行に変更でき、またはインタリーバの実施に基づいて他の任意の次元態様を使用するように変更できることに留意することが重要である。
【０１１３】
次にステップ１１６０において、符号化デインタリーブパケット内のヘッダバイトが変更される。１１６０における変更ステップは、ヘッダ情報がレガシ受信機によって認識されることを妨げることによって、ＡＴＳＣ  Ｍ／Ｈデータパケットを復号することが可能でない受信機で起こる性能問題を予防する方法を提供する。ステップ１１６０における変更は、ＴＥＩビット、ペイロードユニット開始インジケータビット、およびトランスポートプライオリティビットを、ビット値の「０」に設定することを含むことができる。ステップ１１６０における変更は、スクランブリング制御ビットおよびアダプテーションフィールドビット（各々２ビット）を「００」に設定することも含むことができる。ステップ１１６０における変更は、３ビット長の連続性カウンタを「０００」に設定することも含むことができる。最後に、ステップ１１６０における変更は、ＰＩＤを、すべてのレガシ受信機によって無視される既知の値など、一意的かつ未使用の値に設定することを含むことができる。ヘッダバイトは、符号化ステップ１１４０において、無視でき、処理しなくてよいことに留意することが重要である。
【０１１４】
ステップ１１７０において、所定のパケットまたは事前トラッキングパケットが、変更されたヘッダ情報を含む符号化パケットのストリーム内に挿入される。事前トラッキングパケットの挿入は、ＡＴＳＣ  Ｍ／Ｈ信号またはモバイルビデオ符号化信号を受信することが可能な受信機の性能を改善する。挿入ステップ１１７０は、既存の冗長もしくは非システマティックパケットを置換でき、または最初にステップ１１１０においてデータパケットのストリーム内のヌルパケットとして提供されたパケットを置換できることに留意することが重要である。
【０１１５】
ステップ１１８０において、ステップ１１７０からのＡＴＳＣ  Ｍ／Ｈ符号化パケットは、データのトランスポートストリームの無処理部分と組み合わされる。ＡＴＳＣ  Ｍ／Ｈ符号化パケットは、データパケットのトランスポートストリームの先に識別された無処理部分に挿入または追加することができる。あるいは、ステップ１１７０からのＡＴＳＣ  Ｍ／Ｈ符号化パケットは、もっぱらレガシ放送受信のために識別された第２のトランスポートストリームと組み合わせることができ、または第２のトランスポートストリームに挿入もしくは追加することができる。ステップ１１８０は、ステップ１１１０におけるパケットのすべてがＡＴＳＣ  Ｍ／Ｈデータパケットとして識別され、処理された場合には、除去することもできることに留意することが重要である。
【０１１６】
加えて、ステップ１１８０において、頑健なデータストリーム内に含まれるＡＴＳＣ  Ｍ／Ｈ符号化パケットと、第２のまたはレガシ限定のデータストリームからのパケットは、ステップ１１１０における監視および制御情報に基づいて、多重化することができる。好ましい一実施形態では、制御情報は、バーストモード動作の実施を指示することができる。バーストモード動作では、所定のデータレートを下回るデータレートを有するレガシ放送データストリームが提供され、追加データを放送送信内に含めることを可能にする。レガシ放送データストリームの所定のデータレートに基づいた周期的な時間間隔で、頑健なデータストリームパケットが、送信用の出力データストリームに挿入される。
【０１１７】
好ましい別の実施形態では、制御情報は、レガシデータオーバレイモード動作の実施を指示することができる。レガシデータオーバレイモード動作では、ＡＴＳＣ  Ｍ／Ｈ符号化パケットとして連続して提供されたパケットの数と、ステップ１１１０において決定された監視および制御情報とに基づいて、レガシ放送パケットが挿入される。上で説明されたように、挿入ステップ１１７０の制御は、コントローラ６７０などのコントローラによって実行することができる。
【０１１８】
次にステップ１１９０において、ＡＴＳＣ  Ｍ／Ｈ符号化であるかどうかに関わらず、すべてのパケットを含む完全なデータストリームが、Ａ５３規格に準拠するレガシまたは既存の符号化を使用して処理される。ステップ１１９０におけるレガシ符号化は、リード−ソロモン符号化、ランダム化、インタリービング、トレリス符号化、および同期挿入を含む。レガシ符号化ステップ１１９０は、レガシエンコーダ６５０内に示されたようなブロックによって実行することができる。
【０１１９】
最後にステップ１１９５において、ＡＴＳＣ  Ｍ／Ｈデータとして符号化されたストリームの全部または一部を含む、完全符号化データストリームが送信される。送信ステップ１１９５は、明確に識別された周波数範囲を使用した送信を含むことができ、同軸ケーブルなどの有線技術を使用した送信、または電磁的に放送波（ａｉｒｗａｖｅ）を介した送信を含むことができる。ＡＴＳＣ  Ｍ／Ｈデータは連続的に送信できることに留意することが重要である。このモードでは、ＡＴＳＣ  Ｍ／Ｈシステマティックパケットは、レガシ受信機においてもデータパケットとして役立つ。非システマティックパケットは無視される。しかし、個別のＡＴＳＣ  Ｍ／Ｈデータおよびレガシデータは、ＡＴＳＣ  Ｍ／Ｈデータを周期的に送信する方式で、または断続する短い期間中に連続的に送信する方式で送信することができる。
【０１２０】
ここで図１２を参照すると、受信機において使用されるデコーダ１２００の一実施形態のブロック図が示されている。デコーダ１２００は、空中の電磁波などの伝送媒体を介した信号の送信によって悪影響を受けている信号を受け取り、復号するための付加的な回路および処理を含む。デコーダ１２００は、頑健なデータストリームとレガシデータストリームの両方を復号することが可能である。例えば、デコーダ１２００は、ＡＴＳＣ  Ｍ／Ｈ信号として送信された信号を受信し、復号することが可能な受信機内に含まれることができる。
【０１２１】
デコーダ１２００では、初期処理の後に続いて、到来信号が、等化器１２０６に提供される。等化器１２０６は、トレリスデコーダ１２１０に接続され、トレリスデコーダ１２１０は、２つの出力を提供する。トレリスデコーダ１２１０からの第１の出力は、フィードバックを提供し、フィードバック入力として等化器１２０６に接続される。トレリスデコーダ１２１０からの第２の出力は、畳み込みデインタリーバ１２１４に接続される。畳み込みデインタリーバ１２１４は、バイトコードデコーダ１２１６に接続され、バイトコードデコーダ１２１６も、２つの出力を提供する。バイトコードデコーダ１２１６からの第１の出力は、畳み込みインタリーバ１２１８を介して、フィードバック入力としてトレリスデコーダ１２１０に接続される。バイトコードデコーダ１２１６からの第２の出力は、リード−ソロモンデコーダ１２２０に接続される。リード−ソロモンデコーダ１２２０の出力は、デランダマイザ１２２４に接続される。デランダマイザ１２２４の出力は、データデコーダ１２２６に接続される。頑健ストリームコントローラ１２６０は、バイトコードデコーダ１２１６およびデランダマイザ１２２４に接続される。リード−ソロモンデコーダ１２２０、デランダマイザ１２２４、およびデータデコーダ１２２６は、ＡＴＳＣ  Ａ５３レガシ放送信号を受信するために使用される畳み込み受信機内のそれらのブロックと類似した仕方で接続され、機能的に動作することに留意することが重要である。
【０１２２】
受信機のフロントエンド処理（例えば、アンテナ、同調器、復調器、Ａ／Ｄ変換器）（図示されず）からの入力信号は、等化器１２０６に提供される。等化器１２０６は、受け取った信号を回復しようと試みて、受け取った信号を処理し、送信チャネルの影響を完全または部分的に除去する。様々な除去方法または等化方法が、当業者によく知られており、ここでは説明されない。等化器１２０６は、ＦＦＥ（フィードフォワード等化器（ｆｅｅｄ−ｆｏｒｗａｒｄ  ｅｑｕａｌｉｚｅｒ））部およびＤＦＥ（判定フィードバック等化器（ｄｅｃｉｓｉｏｎ−ｆｅｅｄｂａｃｋ−ｅｑｕａｌｉｚｅｒ））部を含む処理回路の多数の部分を含むことができる。
【０１２３】
等化信号は、トレリスデコーダ１２１０に提供される。トレリスデコーダ１２１０は、１つの出力として、等化器１２０６のＤＦＥ部に提供される判定値の組を生み出す。トレリスデコーダ１２１０は、やはり等化器１２０６のＤＦＥ部に提供される中間判定値も生成することができる。ＤＦＥ部は、判定値をトレリスデコーダ１２１０からの中間判定値とともに使用して、等化器１２０６内のフィルタタップの値を調整する。調整されたフィルタタップ値は、受け取った信号内に存在する干渉および信号反射を打ち消す。反復プロセスは、等化器１２０６が、トレリスデコーダ１２１０からのフィードバックの助けを借りて、時間とともに変化する可能性のある信号伝送環境状態に合わせて動的に調整を行うことを可能にする。反復プロセスは、デジタルテレビ放送信号の場合の１９Ｍｂ／ｓなど、信号の到来データレートに類似したレートで発生できることに留意することが重要である。反復プロセスは、到来データレートよりも高いレートで発生することもできる。
【０１２４】
トレリスデコーダ１２１０は、トレリス復号データストリームを畳み込みデインタリーバ１２１４にも提供する。畳み込みデインタリーバ１２１４は、図６において説明されたデインタリーバに類似した動作を行い、データパケット内に組織されるデインタリーブバイトを生成する。データパケットは、バイトコードデコーダ１２１６に提供される。上で説明されたように、頑健なデータストリームの一部ではないパケットは、単にバイトコードデコーダ１２１６を通過して、リード−ソロモンデコーダ１２２０に渡される。頑健なデータストリームの一部として識別されたパケットの場合、バイトコードデコーダ１２１６は、上で説明されたように、非システマティックパケット内の冗長情報を使用して、パケット内のバイトを初期的に復号する。識別が完了する時に先立って、受け取ったすべてのパケットの初期復号を実行できることに留意することが重要である。
【０１２５】
バイトコードデコーダ１２１６およびトレリスデコーダ１２１０は、ターボデコーダと呼ばれる反復方式で動作し、頑健なデータストリームを復号する。具体的には、トレリスデコーダ１２１０は、畳み込みデインタリーバ１２１４によるデインタリービングの後、頑健なデータストリーム内に含まれるパケットの各バイトについて、第１の軟判定ベクトルをバイトコードデコーダ１２１６に提供する。一般に、トレリスデコーダ１２１０は、確率値からなるベクトルとして軟判定を生み出す。いくつかの実施形態では、ベクトル内の各確率値は、そのベクトルに関連するバイトが有することのできる値に関連する。他の実施形態では、２／３レートトレリスデコーダは２ビットシンボルを推定するので、確率値からなるベクトルは、システマティックパケット内に含まれるハーフニブル（ｈａｌｆ−ｎｉｂｂｌｅ）（すなわち２ビット）毎に生成される。いくつかの実施形態では、トレリスデコーダ１２１０は、バイトの４つのハーフニブルに関連する４つの軟判定を組み合わせて、バイトが有することのできる値の確率からなるベクトルである１つの軟判定を生み出す。そのような実施形態では、バイトに対応する軟判定は、バイトコードデコーダ１２１６に提供される。他の実施形態では、バイトコードデコーダは、システマティックパケットのバイトに関する軟判定を４つの軟判定値に分離し、その場合、４つの軟判定の各々は、バイトのハーフニブルに関連する。
【０１２６】
バイトコードデコーダ１２１６は、頑健なデータストリームのパケットを構成するバイトに関連する軟判定ベクトルを使用して、パケットを構成するバイトの第１の推定を生み出す。バイトコードデコーダ１２１６は、システマティックパケットと非システマティックパケットの両方を使用して、頑健なストリームを構成するパケットの各バイトについて第２の軟判定ベクトルを生成し、畳み込みインタリーバ１２１８による再インタリービングの後、第２の軟判定ベクトルをトレリスデコーダ１２１０に提供する。その後、トレリスデコーダ１２１０は、第２の軟判定ベクトルを使用して、第１の判定ベクトルのさらなる反復を生み出し、それをバイトコードデコーダ１２１６に提供する。トレリスデコーダ１２１０およびバイトコードデコーダ１２１６は、トレリスデコーダとバイトコードデコーダとによって生み出された軟判定ベクトルが収束するか、または所定の回数の反復が行われるまで、このように反復する。その後、バイトコードデコーダ１２１６は、システマティックパケットの各バイトについての軟判定ベクトル内の確率値を使用して、システマティックパケットの各バイトについての硬判定を生成する。硬判定値（すなわち復号バイト）は、バイトコードデコーダ１２１６からリード−ソロモンデコーダ１２２０に出力される。トレリスデコーダ１２１０は、ＭＡＰ（帰納的最大（Ｍａｘｉｍｕｍ  ａ  Ｐｏｓｔｅｒｉｏｒｉ））デコーダを使用して実施することができ、バイト軟判定またはハーフニブル（シンボル）軟判定に基づいて動作することができる。
【０１２７】
ターボ復号は一般に、到来データレートよりも高い、ブロック間での判定データ受け渡しに関する反復レートを利用することに留意することが重要である。可能な反復の回数は、データレートと反復レートの比に制限される。結果として、実用の範囲では、ターボデコーダにおけるより高い反復レートは一般に、誤り訂正結果を改善する。一実施形態では、到来データレートの８倍の反復レートを使用することができる。
【０１２８】
図１２において説明されたような軟入力軟出力バイトコードデコーダは、ベクトル復号機能を含むことができる。ベクトル復号は、システマティックバイトおよび非システマティックバイトを含むデータのバイトをグループ化することを含む。例えば、レート１／２バイトコード符号化ストリームの場合、１つのシステマティックバイトと１つの非システマティックバイトがグループ化される。２つのバイトは、６４０００を超える可能な値を有する。ベクトルデコーダは、２つのバイトの各可能な値についての確率を決定または推定し、確率マップを生成する。可能性の一部または全部の確率に対する重み付けと可能な符号語までのユークリッド距離（Ｅｕｃｌｉｄｅａｎ  ｄｉｓｔａｎｃｅ）とに基づいて、軟判定が行われる。ユークリッド距離の誤差が閾値を下回った場合に、硬判定を行うことができる。
【０１２９】
バイトコードデコーダ１２１６の硬判定出力または軟判定出力は、リード−ソロモンデコーダ１２２０に提供される。リード−ソロモンデコーダ１２２０は、出力データを、例えば、２０７バイトのパケットに形成する。リード−ソロモンデコーダ１２２０は、バイトコードデコーダによって生み出された２０７バイトの各系列を１つまたは複数のリード−ソロモン符号語と見なし、符号語またはパケット内のいずれかのバイトが送信中の誤りのせいで改悪されていないかどうか判定する。判定はしばしば、符号語のシンドロームまたは誤りパターンの組を計算し、評価することによって実行される。改悪が検出された場合、リード−ソロモンデコーダ１２２０は、パリティバイト内に符号化された情報を使用して、改悪バイトを回復しようと試みる。その後、結果的に誤り訂正されたデータストリームは、デランダマイザ１２２４によって逆ランダム化され、その後、データデコーダ１２２６に提供され、データデコーダ１２２６は、送信されるコンテンツのタイプに従ってデータストリームを復号する。
【０１３０】
データデコーダ１２２６は、復号パケットのヘッダ内のＰＩＤなどの識別子を使用して、パケットで搬送された情報のタイプと、そのような情報をどのように復号すべきかを決定する。ヘッダ内のＰＩＤは、データストリームの一部として定期的に送信され、更新され得る、受信機内のＰＭＴ（プログラムマップテーブル）内の情報と比較される。データデコーダ１２２６は、認識されるタイプに属さないデータパケットのＰＩＤを有するパケットをいずれも無視する。
【０１３１】
頑健ストリームコントローラ１２６０は、逆ランダム化データストリームも受け取る。頑健ストリームコントローラ１２６０は、マイクロプロセッサまたはマイクロコントローラとして具現される別個の回路とすることができる。あるいは、頑健ストリームコントローラ１２６０は、バイトコードデコーダ１２１６など、他のブロックの１つに含まれることもできる。頑健ストリームコントローラ１２６０は、受信装置全体の動作のために使用されるコントローラ内に組み込むこともできる。頑健ストリームコントローラ１２６０は、例えば、頑健なデータストリーム用に使用されるプリアンブルの形式をとる事前トランスポートパケットの存在を判定することができる。事前トランスポートパケットの存在に基づいて、頑健ストリームコントローラ１２６０は、頑健なデータストリーム内の制御情報を識別し、復号する。好ましい一実施形態では、頑健ストリームコントローラ１２６０は、頑健なデータストリーム内のプリアンブルデータブロックを識別した後、第１のデータブロック内の制御パケットを復号する。
【０１３２】
識別された制御情報を使用して、頑健ストリームコントローラ１２６０は、バイトコードデコーダ１２１６に制御信号を提供する。制御信号は、復号レートを設定するための情報、復号されるデータの符号語、パケット、またはブロックの数を表す情報を含むことができる。頑健ストリームコントローラ１２６０は、先に説明されたようなバーストモード動作またはレガシオーバレイモード動作におけるレガシデータストリームを伴う頑健なデータストリームの送信であることに基づいて、データのある受け取った符号語、パケット、またはブロックをレガシデータとして無視できるかどうかを表す制御信号も提供することができる。好ましい一実施形態では、頑健ストリームコントローラ１２６０は、制御情報を使用して、頑健なデータのブロックを識別し、頑健なストリームに関連しないブロックが無処理のままバイトコードデコーダを通過できるように、バイトコードデコーダの動作を変更する。別の実施形態では、頑健ストリームコントローラ１２６０は、モバイルデータバーストどうしの間の識別された期間中、シャットダウンするようバイトコードデコーダ１２１６に命令する。頑健ストリームコントローラ１２６０は、受信機が制御情報に基づいてシャットダウンできるように、デコーダ１２００内の他のブロックおよび受信機の他の部分にも信号を提供することができる。
【０１３３】
図１２において説明されたようなデコーダは、単一バイトコードエンコーダまたは連結バイトコードエンコーダによる符号化を含む、先に説明されたバイトコードエンコーダによる符号化が施された頑健なデータストリームを復号することができる。図１２のデコーダは、単一の符号化ステップを含むだけの単一または構成バイトコードエンコーダによって符号化された頑健なデータストリームの復号を説明する。連結バイトコード復号は、デインタリービング、デパンクチャリング、および再挿入などの中間処理に加えて、２つ以上の復号ステップで、到来した符号語またはバイトを復号することを含む。
【０１３４】
ここで図１３を参照すると、連結バイトコードデコーダ１３００の一実施形態のブロック図が示されている。連結バイトコードデコーダ１３００は、図１２に示されるようなターボデコーダ構成において動作するように構成される。連結バイトコードデコーダ１３００も、頑健なデータストリーム内の連結バイトコード符号化パケットを復号するために反復プロセスを使用するターボデコーダとして内部的に動作する。連結バイトコードデコーダ１３００は、レート１２／２６バイトコード符号化信号ストリームを復号して、最初の符号化２６バイトから１２バイトのデータを生み出すように適合される。
【０１３５】
２６バイトの軟判定値を表すデータストリームが、バイト挿入ブロック１３０２に提供される。バイト挿入ブロック１３０２の出力は、第１の２／３レートバイトコードデコーダ１３０４に接続される。第１の２／３レートバイトコードデコーダ１３０４は、２つの出力を提供する。第１の出力は、パンクチャブロック１３０６に接続され、パンクチャブロックの出力は、図１２に示されるように、インタリーバを介して、トレリスデコーダに、フィードバック入力として接続される。第１の２／３レートバイトコードデコーダ１３０４の第２の出力は、デインタリーバ１３０８に接続される。シンボルデインタリーバ１３０８の出力は、やはり２つの出力を有する第２の２／３レートバイトコードデコーダ１３１０に接続される。第１の出力は、インタリーバ１３１２を介して、第１の２／３レートバイトコードデコーダ１３０４に、フィードバック入力として接続される。第２の出力は、リード−ソロモンデコーダなどの他の処理ブロックに接続される。
【０１３６】
バイト挿入ブロック１３０２に入力される２６バイトは、データのシステマティックバイトまたはシステマティックパケットに関する、図１２のトレリスデコーダ１２１０などのトレリスデコーダによって生成された、第１の軟判定と、データの非システマティックバイトまたは非システマティックパケットに関する軟判定とを含む。データのシステマティックバイトおよび非システマティックバイトは、バイトコード符号化されたパケットからのものとすることができる。２／３レートバイトコードデコーダは、２つのデータバイトを復号するために３バイトを必要とする。しかし、元の連結符号化は、符号語を２７バイトから２６バイトに縮小するために、好ましくは非システマティックバイトを削除することによって１バイトを削除した。結果として、符号化プロセスのパンクチャリングによって削除されたバイトに代わるバイトが必要とされる。加えて、トレリスデコーダへの入力ストリームは、パンクチャバイトを含んでいないので、トレリスデコーダは、データストリームにおいて、パンクチャバイトに関する軟判定を生成しない。結果として、パンクチャバイトの値に等しい可能性があることを表す軟判定値が挿入される。バイト挿入ブロック１３０２からの、挿入された軟判定値を含む、第１の軟判定が、第１の２／３レートバイトコードデコーダ１３０４に提供される。第１の２／３レートバイトコードデコーダ１３０４は、システマティックパケットおよび非システマティックパケットのバイトの復号に基づいて、第１の軟判定を使用して、第２の軟判定を生成する。軟判定の生成は、例えば、バイトの組に、上記の式（２）および式（３）に示されるようなバイトコード化パケットを作成するために使用されたｂ1要素およびｂ2要素の値の逆数を乗じる乗算を利用する。
【０１３７】
第１の２／３レートバイトコードデコーダからの２７バイト軟出力は、パンクチャブロック１３０６に提供される。２７バイト軟出力は、第１の２／３レートバイトコードデコーダにおける復号後の、システマティックバイトおよび非システマティックバイトの両方についての更新された軟判定値の組を表す。パンクチャブロック１３０６は、バイトフォーマットをトレリスデコーダによって最初に処理された２６バイトフォーマットに戻すために、先に挿入された軟判定バイトを削除する。
【０１３８】
システマティックバイトのみを表す、第１の２／３レートバイトコードデコーダからの１８バイト軟出力は、デインタリーバ１３０８に提供される。デインタリーバ１３０８は、２／３レートバイトコード符号化プロセスにおいて実行されたインタリービングを逆転させる仕方で、１８バイトのデータをデインタリーブする。デインタリーバ１３０８は、例えば、図７の行７１０と行７２０を逆にすることによって、エンコーダ内のインタリービングマップを正確に逆転させる。
【０１３９】
デインタリーブバイトは、第２の２／３レートバイトコードデコーダ１３１０に提供される。第２の２／３レートバイトコードデコーダ１３１０は、デインタリーブ軟判定システマティックバイトを使用して、上で説明されたのと類似の仕方で、軟判定バイトの２つの追加出力を生成する。１８バイトの軟出力が、インタリーバ１３１２に提供される。１８バイトの軟出力は、第１の２／３レートバイトコードデコーダ１３１０における復号からの、システマティックバイトおよび非システマティックバイトの両方についての更新された軟判定値の組を表す。インタリーバ１３１２は、デインタリーブバイトを第１の２／３レートバイトコードデコーダによって使用されたバイトフォーマットに戻すために、デインタリーブバイトを再インタリーブする。インタリーバ１３１２は、図６のインタリーバ６１２など、エンコーダ内で使用されるインタリーバと基本的に同一であり、再インタリーブされた１８バイトからなる組を第１の２／３レートバイトコードデコーダ１３０４に提供する。再インタリーブされた１８バイトからなる組は、第１の２／３レートバイトコードデコーダ１３０４によって行われた軟判定を改善するために使用される。
【０１４０】
第２の２／３レートバイトコードデコーダ１３１０からの１２バイト出力は、１２／２６レートバイトコード符号化された頑健なデータストリームについてのシステマティックバイト復号データ出力を表す。第２の２／３レートバイトコードデコーダ１３１０によって生成された１２個のシステマティック出力バイトについての軟判定が、決定的なものであるか、または正しいデータ値であると結論できる所定の閾値内にある場合、第２の２／３レートバイトコードデコーダ１３１０は、その軟判定を使用して、１２個の出力バイトに関して硬判定を生成し、１２個の出力バイトをリード−ソロモンデコーダなどのさらなる処理ブロックに提供する。しかし、第２の２／３レートバイトコードデコーダによって生成された軟判定が、決定的なものでない場合、直前の反復の最中に作成され、フィードバックされた軟情報を使用して、上記のようにさらなる反復が進展する。この付加的な軟情報は、先行するデコーダによって、各軟デコーダに提供される。すなわち、トレリスデコーダは、パンクチャブロック１３０６を介して提供される、第１の２／３レートバイトコードデコーダ１３０４からのフィードバックを使用し、第１の２／３レートバイトコードデコーダ１３０４は、インタリーバ１３１２を介して提供される、第２の２／３レートバイトコードデコーダ１３１０からのフィードバックを使用する。第２の２／３レートバイトコードデコーダ１３１０によって生成された軟判定が十分に収束するまで、または所定の回数の反復が行われるまで、このように反復が継続する。上述のように、使用されるターボ復号は一般に、到来データレートよりも高い、ブロック間での判定データの受け渡しに関する反復レートを利用する。
【０１４１】
図２に示されたエンコーダ２００などの好ましいエンコーダでは、バイトコード符号化が、データパケットのリード−ソロモン符号化に先行することに留意することが重要である。しかし、ここに示されたデコーダ１３００では、到来データは、リード−ソロモン復号される前にバイトコード復号される。バイトコード操作およびリード−ソロモン符号操作はともに、Ａ５３規格において使用されるガロア体（２５６）上で線形であり、線形操作はガロア体において可換であるので、順序の入れ替えが可能である。バイトコード符号化は、受け取った信号内の誤りの回復に関してより高い信頼性を提供するので、順序の入れ替えは重要である。加えて、バイトコード符号化は、軟判定アルゴリズムを使用して復号することができ、さらにトレリス復号を用いた反復復号プロセスに含まれることができる。リード−ソロモン復号は主として、硬判定復号として動作し、軟判定復号を使用しても、性能は改善されない。結果として、リード−ソロモン復号に先立つバイトコード復号の実行は、ビット誤り率および信号対雑音比に関する測定において、改善された受信機性能をもたらす。
【０１４２】
加えて、図１のエンコーダ１００および図６のエンコーダ６００の実施形態についての説明と同様に、他のコーディングレートを復号するためのバイトコードデコーダの他の実施形態も使用できることに留意されたい。例えば、他のデコーディングレートを復号するために、レート２／３構成バイトコードデコーダの代わりに、レート１／２およびレート２／３の符号化率のための構成バイトコードデコーダが含まれ、挿入されてもよい。さらに、図４において説明されたようなレート２４／２０８バイトコード符号化信号を復号するために必要とされることがある、並列復号または順次的高速復号を可能にするために、付加的なブロックが含まれてもよい。レガシ受信機に最低限の変更を施すだけで、レガシ受信機で必要とされ、使用される要素、コンポーネント、および回路に、バイトコード復号要素および処理を追加できることにも留意されたい。しかし、バイトコード復号プロセスの機能をレガシ受信機の他のブロックに組み込むことによって、復号プロセスを増強してもよい。
【０１４３】
上で説明されたバイトコード符号化および復号の構成を使用する様々なシステムは、既存またはレガシ放送システムのアプリケーションの拡張を可能にする。第１に、既存のレガシ受信機は、ＡＴＳＣ  Ｍ／Ｈを使用して符号化されたパケットの追加的な存在から利益を得ることができる。動的な信号環境状態におけるトラッキングを改善するために、より堅牢なＳＣＢＣ符号化パケットおよび事前トラッキングパケットを、トレリスデコーダおよび等化器によって処理することができる。第２に、堅牢または頑健なデータを生成するＡＴＳＣ  Ｍ／Ｈ符号化データは、レガシＡ５３送信を受信できない信号環境において、モバイルデバイス、ハンドヘルドデバイス、および歩行者用デバイス内の受信システムが堅牢なストリームを受信することを可能にする。例えば、レート２４／２０８でのＡＴＳＣ  Ｍ／Ｈ符号化は、レガシＡ５３受信用の約１５ｄＢ（デシベル）の白色雑音閾値と比べて、２．０ｄＢに等しい白色雑音閾値での信号受信を可能にする。ＡＴＳＣ  Ｍ／Ｈパケットを生成し、そのパケットをレガシＡ５３データとともに周期的に送信することによって、動作がさらに増強される。周期的な送信は、放送素材のビデオおよびオーディオ配信を可能にするために重要である。ＡＴＳＣ  Ｍ／Ｈパケットは、グループ化して、１つまたは複数の送信バーストとして送信することもできる。バーストでの送信は、データコンテンツ、またはモバイルデバイス、ハンドヘルドデバイス、もしくは歩行者用デバイスによって後で使用するために保存できるコンテンツのために重要である。
【０１４４】
実施形態は様々な変更および代替的形態を許すことができるが、特定の実施形態が、図面において例として示され、本明細書において詳細に説明された。しかし、本開示は、開示された特定の形態への限定を意図していないことを理解されたい。むしろ、本開示は、以下に記載の特許請求の範囲によって確定される開示の主旨および範囲内に含まれるすべての変更、均等物、および代替を包含するものとされる。
【図１】
2011501926.tif 000009
【図２】
2011501926.tif 000010
【図３】
2011501926.tif 000011
【図４】
2011501926.tif 000012
【図５】
2011501926.tif 000013
【図６】
2011501926.tif 000014
【図７】
2011501926.tif 000015
【図８】
2011501926.tif 000016
【図９】
2011501926.tif 000017
【図１０】
2011501926.tif 000018
【図１１】
2011501926.tif 000019
【図１２】
2011501926.tif 000020
【図１３】
2011501926.tif 000021
【国際調査報告】
2011501926.tif 000022
2011501926.tif 000023
2011501926.tif 000024
2011501926.tif 000025
2011501926.tif 000026
2011501926.tif 000027