(57)【特許請求の範囲】
【請求項１】
ディジタル・エンコード信号として受信されて複数のパケット・タイプを有する固定長パケットのストリームを処理する装置であって、
各パケットは、ヘッダ部およびデータ部を含み、前記ヘッダ部は、同期バイトを含み、
前記装置が、
チェックサムに基づいてデータパケット内の前記同期バイトの位置を示すＳｙｎｃ＿ｆｌａｇ信号を出力し、ｌｏｃｋ＿ｆｌａｇ信号を出力する同期検出器と、
受信パケットがヌル・パケットか否かを検出すると共に、検出したヌル・パケットの前記同期バイトの位置を特定するヌル・パケット検出器であって、ヌル・パケットのプリアンブルを最初に検出し、後続のデータビットが予想されるデータパターンと等しいか、又は前記予想されるデータパターンとの差が所定のビットエラー数以下であるかを判断し、さらに、受信パケットがヌル・パケットであるかを示すＮｕｌｌ＿ｆｌａｇ信号を生成し、検出されたヌル・パケットの前記同期バイトの位置を示すＮｕｌｌ＿ｓｙｎｃ信号を生成するヌル・パケット検出器と、
前記ヌル・パケット検出器から前記Ｎｕｌｌ＿ｆｌａｇ信号を受信し、パケットのブロック内にあるヌル・パケットの数に基づくＮｕｌｌ＿ｌｏｃｋ信号を出力する状態機械と、
前記同期検出器から前記Ｓｙｎｃ＿ｆｌａｇ信号、前記ｌｏｃｋ＿ｆｌａｇ信号を、前記状態機械からＮｕｌｌ＿ｓｙｎｃ信号、前記Ｎｕｌｌ＿ｌｏｃｋ信号を受信し、前記Ｎｕｌｌ＿ｌｏｃｋ信号が第１の値を有していれば前記ヌル・パケット検出器から受信した信号に基づいてロック出力を行い、前記Ｎｕｌｌ＿ｌｏｃｋ信号が第２の値を有してれば前記同期検出器から受信した信号に基づいてロック出力を行う決定論理手段と、
を備える、前記装置。
【請求項２】
前記ヌル・パケット検出器は、Ｎｕｌｌ＿ｆｌａｇ信号を生成して、受信パケットがヌル・パケットか否かを示すと共に、Ｎｕｌｌ＿ｓｙｎｃ信号を生成して、検出されたヌル・パケットの前記同期バイトの位置を示す、請求項１記載の装置。
【請求項３】
前記Ｎｕｌｌ＿ｓｙｎｃ信号により示された前記同期バイト位置に、所定の同期バイト値を挿入するように構成される回路を備える、請求項２記載の装置。
【請求項４】
前記Ｎｕｌｌ＿ｆｌａｇ信号をフィルタリングするように構成されると共に、第１の値が複数のヌル・パケットを含む前記ストリームを示すＮｕｌｌ＿ｌｏｃｋ信号を生成するように構成されるフィルタを備える、請求項１記載の装置。
【請求項５】
前記フィルタは、ヒステリシス閾値処理を実行する、請求項４記載の装置。
【請求項６】
前記フィルタは、有限状態機械により実行される、請求項４記載の装置。
【請求項７】
前記フィルタにより出力されるＮｕｌｌ＿ｌｏｃｋ信号の前記第１の値は、前記ストリームが第１の連続パケット数内で第１のヌル・パケット閾値数を含むことを示す、請求項４記載の装置。
【請求項８】
前記第１の閾値数および前記第１の連続パケット数の少なくとも一方は、プログラム可能である、請求項７記載の装置。
【請求項９】
前記フィルタにより出力されるＮｕｌｌ＿ｌｏｃｋ信号の第２の値は、第２の連続パケット数内で、前記ストリームがヌル・パケットではない第２のパケット閾値数を含むことを示す、請求項７記載の装置。
【請求項１０】
前記第１の閾値数および前記第２の閾値数の少なくとも一方は、プログラム可能である、請求項８記載の装置。
【請求項１１】
前記ヌル・パケット検出器は、受信パケットがヌル・パケットか否かを、前記受信パケットの前記ヘッダ部を第１の所定値と比較することで判断する、請求項２記載の装置。
【請求項１２】
前記ヌル・パケット検出器は、受信パケットがヌル・パケットか否かを、前記受信パケットの前記データ部のコンテンツを第２の所定値と比較することで判断する、請求項１１記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディジタル映像および音声を含むマルチメディア・データを送受信することに関し、特に、ＭＰＥＧ−２ストリーム放送を、ディジタル伝送システムを介して、受信機（レシーバ）のトランスポート層に対して、高い信頼性で同期および送給する方法および装置に関する。
【背景技術】
【０００２】
ディジタル伝送システムは、圧縮音声（オーディオ）および映像（ビデオ）ストリームを含む高品位マルチメディア・データを消費者に提供する。放送者は、データの圧縮により、幾つかの番組を同じアナログ帯域幅で配信できる。番組の音声成分および映像成分は、放送元において圧縮され、オリジナルの番組を再生するのに必要な他のプログラムおよびシステム情報と共に時間多重化される。ディジタル多重通信は、物理層により処理され、消費者へ送信される。消費者側では、受信機が信号を処理して、多重化ディジタル・ストリームを復元し、対象のプログラム（番組）を抽出し、圧縮音声および圧縮映像をデコード（復号化）して、テレビジョン等の映像／音声ディスプレイ上に提示する。
【０００３】
様々な製造業者からの相互運用可能なコンポーネントの開発を促進するために、ＭＰＥＧ−２国際圧縮規格（標準）が開発された。この規格は、ビットストリームをエンコード（符号化）、多重化、およびデコード（復号化）する手法を指定しておらず、データの形式のみを指定している。これにより、製造業者には、半導体、プロセッサ能力、およびメモリといったリソース（資源）を使用する方法と、エラーを隠す能力またはエラーから回復する能力とにより、自分の製品を差別化する機会が残されている。この規格は、システム、映像（ビデオ）、および音声（オーディオ）を対象とする主に三種類の部分から成る。映像部分および音声部分では、圧縮映像データおよび圧縮音声データの形式を指定しており、一方、システム部分では、一つ以上の番組の音声および映像と、番組の復元に必要な情報とを多重化する形式を指定している。
【０００４】
ＡＮＳＩ／ＳＣＴＥ  ０７  ２０００（旧ＳＣＴＥ  ＤＶＳ  ０３１）およびＩＴＵ−Ｔ  Ｊ．８３Ｂ規格は、ほぼ同一であり、映像、音声、およびデータ・サービスのケーブル配信用のディジタル伝送システムを記述している。特に、ＡＮＳＩ／ＳＣＴＥ  ０７  ２０００規格は、米国でのディジタル・ケーブル伝送に採用された規格を記述している。両規格では、物理層（チャネル・コーディングおよび変調）に入力されるデータ形式は、ＭＰＥＧ−２トランスポートになると想定される。
【０００５】
物理層において、ＭＰＥＧフレーミングは、処理の最も外側の層となる。トランスミッタでは、ＭＰＥＧフレーミング・ブロックには、順方向誤り訂正（ＦＥＣ：Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）エンコーダと、６４値および２５６値直交振幅変調（ＱＡＭ：Ｑｕａｄｒａｔｕｒｅ  Ａｍｐｌｉｔｕｄｅ  Ｍｏｄｕｌａｔｏｒ）とが続く。順方向誤り訂正（ＦＥＣ）システムは、ＭＰＥＧ−２ストリームのような一方向通信システムにおけるエラーを制御する方法のクラスである。ＦＥＣエンコーダは、受信機がデータのチェックおよび訂正を行うために使用できる余分な情報をデータと共に送る。ＦＥＣエンコーダは、リード・ソロモン（ＲＳ：Ｒｅｅｄ−Ｓｏｌｏｍｏｎ）エンコーダと、幾つかのモードが可能なインタリーバと、ランダマイザと、トレリス・エンコーダとを含む連結システムで構成される。ＦＥＣエンコーダは、中程度の複雑性とオーバヘッドとにより、高い符号化利得を生成する。ＦＥＣシステムは、１５分当たり１エラー事象のしきい出力エラー事象率での疑似エラー・フリー動作に最適化される。受信機では、対応する変調およびＦＥＣデコード機能が実行され、ＭＰＥＧフレーミング・ブロックが後に続く。
【０００６】
受信機のＭＰＥＧフレーミング処理ブロックは、連続的な形式で、最上位ビット（ＭＳＢ）が最初に伝送される固定長（１８８バイト）パケットの連続ストリームから成るＭＰＥＧ−２トランスポート・データ・ストリームを送給する。
【０００７】
各パケットのいわゆる「リンク（ｌｉｎｋ）」ヘッダは、パケット同期および識別と、エラー表示と、条件付きアクセスとのためのフィールドを含んでいる。後続の適応ヘッダは、デコーディングおよびプレゼンテーション処理用の同期およびタイミング情報を伝送する。ペイロード（１４６ビット）は、圧縮映像および音声ストリームを含む任意のマルチメディア・データを収容できる。
【０００８】
ＭＰＥＧ−２トランスポート層のデータ・パケットは１８８バイトを有し、４バイト・トランスポート・パケット・ヘッダで開始され、ヘッダは、同期を目的とする１バイト（同期バイトと呼ばれ、４７Ｈｅｘ（１６進）の一定値を有する）と、サービス識別、スクランブル、および制御情報を含む後続の３バイトとを有する。
【０００９】
４バイト・トランスポート・パケット・ヘッダには、１８４バイトのＭＰＥＧ−２または補助データが続く。トランスポート・パケット・ヘッダは、次の順序のように配列される。
ａ）同期（Ｓｙｎｃ）バイト：０ｘ４７（４７Ｈｅｘ（１６進））の固定値から成る８ビット。
ｂ）Ｔｒａｎｓｐｏｒｔ＿ｅｒｒｏｒ＿ｉｎｄｉｃａｔｏｒ：現在のトランスポートパケットにおける訂正不可能ビット・エラーを示す１ビット。この情報は、トランスミッタまたは受信機により設定してよい。
ｃ）Ｐａｙｌｏａｄ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｉｎｄｉｃａｔｏｒ：新しいＰＥＳ（パケット化エレメンタリ・ストリーム）パケットまたは新しいＴＳ＿ＰＳＩ（トランスポート・ストリーム−プログラム固有情報）セクションの存在を示す１ビット。
ｄ）Ｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙ：他のパケットより高い優先順位を示す１ビット。
ｅ）ＰＩＤ：１３ビットのパケットＩＤ。値０および１が事前に割り当てられ、一方、値２乃至１５はリザーブされる。値０ｘ００１０乃至０ｘ１ＦＦＥは、プログラム固有情報（ＰＳＩ）により割り当ててよい。値０ｘ１ＦＦＦは、ヌル（ｎｕｌｌ：ナル）パケット用にリザーブされる。
ｆ）Ｔｒａｎｓｐｏｒｔ＿ｓｃｒａｍｂｌｉｎｇ＿ｃｏｎｔｒｏｌ：パケット・ペイロードのスクランブル・モードを示す２ビット。
ｇ）Ａｄａｐｔａｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌ：適応フィールドまたはペイロード・データ・フィールドの存在を示す２ビット。
ｈ）Ｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒ：ＰＩＤ値当たり一つのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒを表す４ビット。対応するＰＩＤ値を有する非反復トランスポート・ストリーム・パケット毎に増分する。
【００１０】
放送ＭＰＥＧ−２ストリームは、音声データおよび映像データの幾つかの多重化番組を、必要なシステム・データと共に含んでいてもよく、データの各パケットは、パケット・ヘッダ内の一意のタグまたはパケットＩＤ（ＰＩＤ）により特定される。
【００１１】
ＭＰＥＧ−２データ・ストリームのセクションは、特定のＰＩＤにおいて強くバイアスを加えること、或いは、多くのＰＩＤに渡って均一に加重すること、或いは、高いパーセンテージのヌル・パケットを含むことが可能である。エラーは、公知および未知のものを含め、トランスポート・ストリーム配信に内在しており、常に発生する可能性がある。ビット不正またはデータ損失等の未知のエラーは、ストリームの任意のビット位置で発生可能であり、トランスポートを誤って異常処理へ導く恐れがある。
【００１２】
ＭＰＥＧ−２同期バイトには、デコーダでのパケットの線引きを容易にする目的がある。しかしながら、他の多くのディジタル伝送規格とは異なり、ディジタル・ケーブル伝送システムの物理層でのＭＰＥＧ−２同期用に使用される方法は、順方向誤り訂正（ＦＥＣ）同期から切り離される。第１に、ＭＰＥＧ−２パケットは、ＦＥＣフレームの整数を含まず、或いは、リード・ソロモン（ＲＳ）コード・ワードさえ含んでいない。（１２８，１２２）コードを使用するリード・ソロモン（ＲＳ）符号化は、ＲＳブロック内で三つまでの７ビット符号を訂正するブロック・エンコーディングおよびデコーディングを提供する。従って、ＭＰＥＧ−２パケットおよびＦＥＣフレーム、またはＭＰＥＧ−２パケットおよびＲＳコード・ワードは、互いに対して非同期となる。第２に、同期バイトは、送信側において、ＦＩＲパリティ・チェック・リニア・ブロック・コードの剰余類であるパリティ・チェックサムにより、ＭＰＥＧフレーミング・ブロック内部で置き換えられる。
【００１３】
従って、受信機側のＭＰＥＧフレーミング・ブロックは、同期バイトを復元して、同期バイトに対してロックするために、このパリティ・チェック・ブロック・コードをデコードする必要がある。その後、ＭＰＥＧフレーミング・ブロックは、トランスポート・ブロックを含む下流の受信機ブロックに、ＭＰＥＧパケット同期を送給する。このブロックの出力は、出力クロックと、シリアル形式またはパラレル形式のデータ・ストリームと、データ・ストリーム内の同期バイトの位置を特定する同期信号と、出力データ・ストリームにデータが存在する時期を特定する有効信号と、パケットが無効（訂正不可能）またはエラー・フリー（エラーが無い）と考えられるかを特定するエラー信号とを含んでよい。
【００１４】
この同期分断の特徴は、同期バイトの情報保持能力を利用するために、処理の追加層として組み込まれる。トランスミッタでは、有限インパルス応答（ＦＩＲ：Ｆｉｎｉｔｅ  Ｉｍｐｕｌｓｅ  Ｒｅｓｐｏｎｓｅ）パリティ・チェック・リニア・ブロック・コード（ＬＢＣまたはＦＩＲ−ＰＣＣ）の剰余類であるパリティ・チェックサムは、パケット線引き機能の改善の目的で、この同期バイトと、ＦＥＣ層から独立したエラー検出能力との代用となる。パリティ・チェックサムは、直前のＭＰＥＧ−２パケット・コンテンツ（マイナス同期バイト）を構成する、隣接した１８７バイトで計算される。ブロック・コードのパリティ・チェックは、有限インパルス応答（ＦＩＲ）線形時不変（二進）フィルタの出力を観察することで、受信機において計算される。パリティ・チェック構造は、（二進）原始多項式により生成されたＰＮシーケンスに基づく。
【００１５】
トランスミッタ側において、チェックサムは、次の式に記載されるように、１４９６ペイロード・ビットを線形フィードバック・シフト・レジスタ（ＬＦＳＲ）に通すことで計算される。
ｆ（Ｘ）＝［１＋Ｘ１４９７ｂ（Ｘ）］／ｇ（Ｘ）、
ここで、ｇ（Ｘ）＝１＋Ｘ＋Ｘ５＋Ｘ６＋Ｘ８、
ｂ（Ｘ）＝１＋Ｘ＋Ｘ３＋Ｘ７
【００１６】
６７Ｈｅｘ（１６進）のオフセットは、自己相関特性の改善のために、このチェックサム結果に追加され、有効なコード・ワードが存在する時のシンドローム・デコード動作中に４７Ｈｅｘ（１６進）の結果を発生させる。この構造は、再帰的な形式で、全体として自己同期式である、計算効率に優れたパリティ・チェックＦＩＲフィルタの実行を可能とし、従って、同時的なパケット同期およびエラー検出をサポートする。デコーダは、パケットの開始を検出するための有効コード・ワードの検出を使用して、シリアル・データ・ストリーム上のスライディング・チェックサムを計算する。
【００１７】
パリティ・チェック・マトリクスは、有効なチェックサムを特定するためにデコーダにより使用される。シンドローム発生器を利用してもよい。コードは、ビットストリームの適切な１８８バイト（チェックサムを含む）をパリティ・チェック・マトリクスに対して乗算した際に、計算された積が４７Ｈｅｘ（１６進）の結果を発生させる時に肯定一致が示されるように設計されている（チェックサムは、ＭＰＥＧ−２同期デコーダに未だに受信されていない１８７バイトではなく、以前の１８７バイトに基づいて計算されることに留意されたい。これは、通常、同期バイトが受信パケットの最初のバイトとして記述される従来のＭＰＥＧパケットのシンタックス（構文）とは対照的である）。
【００１８】
図１は、受信機側の従来技術によるＭＰＥＧフレーミング・ブロック２００を表すブロック図である。データ・ストリームはシリアル化され、シリアル・データ・ストリームは、ＡＮＳＩ／ＳＣＴＥ  ０７  ２０００規格において指定されたシンドローム発生器２１０を介して送られる（例えば、規格の図３に例示されたシンドローム発生器を参照）。シンドローム検出器２２０は、シンドローム発生器２１０の出力を、パケット数ＮＰに対する４７Ｈｅｘ（１６進）と、およびプログラム可能閾値Ｓｙｎｄ＿ｔｈｒｅｓｈとに比較し、同期バイトが実際に検出されたかを決定する。例えば、ＮＰパケット中、４７Ｈｅｘ（１６進）に等しいシンドローム出力の数がＳｙｎｄ＿ｔｈｒｅｓｈ以上である場合、同期バイトが検出されたことになる。Ｌｏｃｋ＿ｆｌａｇは、データ・ストリーム内で同期バイトが検出されたか否かを、それぞれ、例えば、論理１または０とすることにより示す。Ｓｙｎｃ＿ｆｌａｇは、データ・ストリーム内の同期バイトの位置を、例えば、同期バイト中を論理１、その他を論理０とすることにより示す。ロック済みの整合条件が設定されると、予想位置における有効コード・ワードの欠如は、パケット・エラーを示す。この場合、以前のパケットのＥｒｒｏｒ＿ｆｌａｇは、１に設定可能であり、その他の場合、パケットはエラー・フリーとみなされ、Ｅｒｒｏｒ＿ｆｌａｇは、０に設定される。
【００１９】
パラレル・パスにおいて、オリジナルのシリアル・データ・ストリームは、（遅延ブロック２３０により）適切に遅延され、ＭＰＥＧ同期再挿入ブロック２４０へ送られ、ここで同期バイトは、パリティ・チェックサム（トランスミッタのＭＰＥＧフレーミング・ブロックにおいて作成される、図示なし）の代わりに再挿入される。従って、トランスポート層へのデータ・ストリーム出力は、復元された標準のＭＰＥＧ−２トランスポート・ストリームとなる。このデータは、シリアルまたはパラレル・モードで出力できる。図１に図示されていない二種類の追加信号、即ち、クロック、およびデータに関連する有効またはイネーブル信号も、トランスポート層に送られる。
【００２０】
ＭＰＥＧ−２の同期分断の特徴は、柔軟性を導入すること、例えば、非同期転送モード（ＡＴＭ）パケットを、ＡＴＭ同期に干渉せずに、システムが容易に配信できるようにすることを目的としていた。しかしながら、この特徴の意図しない結果は、図１のＭＰＥＧフレーミング・ブロック内の従来技術によるシンドローム検出器における「不正ロック」の設定の増加である。
【００２１】
これが発生するのは、トランスミッタ側でエンコードされたパリティ・チェック・ブロック・コードがあまり強力ではなく、受信機側のデコーダ（シンドローム発生器２１０）では、正しいものが唯一である時に、同期バイトの可能性があるものを発見できる場所をパケット内で幾つか示し得るためである。これは、ＦＥＣが完全にロックされて、エラー・フリー・データ・ストリームを送給する場合にも発生し得る。幸いにも、通常のデータ・ストリームは、一般に、周期的な特性を見せず、パリティ・チェック・ブロック・デコーダにより処理された後、異なるパケットは、正しい同期位置を共介して有する傾向にある。しかしながら、例えば、多数のヌル・パケットを有するデータ・ストリーム等、周期的なデータ・ストリームの場合、この問題は深刻となり、従来技術による同期ロック検出器（シンドローム検出器２２０）は、パリティ・チェック・ブロック・デコーダにより特定されたパケット内の幾つかの不正同期バイト位置の一つに誤ってロックされ、ＦＥＣが完全にロックされてエラー・フリー・データ・ストリームを送給する時でも、トランスポート・ブロックに無効なパケットを送る恐れがある。定期的にデータ・ストリーム内で乗算される十分なヌル・パケットが存在する限り、これは、ロック検出器が誤ってロックされた状態を長時間に渡って維持するのに十分なものとなり得る。
【００２２】
ロック（同期）検出後、従来技術によるＭＰＥＧフレーミング・ブロック内のＭＰＥＧ同期再挿入部２４０は、パリティ・チェック・ブロック・デコーダにより特定された同期バイト位置に同期バイトを挿入し、Ｓｙｎｃ＿ｆｌａｇ信号と、Ｅｒｒｏｒ＿ｆｌａｇ信号と、有効およびクロック信号とを出力し、データ・ストリームをトランスポート層へ送る。不正ロックの場合、トランスポート層は、１８８データ・バイトを、同期バイトであると予想される第１のバイトと、データ・バイトに一致する有効信号と、エラー・フリー・パケットを示すエラー信号と共に受信しているため、不正パケットを容易に特定できない。
【００２３】
放送において、データ・ストリームは、反復的なヌル・パケットを含む可能性があり、反復的なヌル・パケットにより、従来技術によるＭＰＥＧフレーミング・ブロック内のシンドローム検出器２２０は、不正な（同期）バイト位置にロックされ、これにより、ＦＥＣが完全にロックされて、エラー・フリー・データ・ストリームを送給する時でも、トランスポート・ブロックへ出力される無効なＭＰＥＧ−２パケットを生成する恐れがある。
【発明の開示】
【００２４】
（発明の概要）
本発明は、パケット・ストリームが複数のヌル・パケットまたは固定された反復データ・パターンを含んだ複数のパケットを含む場合に、ディジタル伝送システムを介して受信したＭＰＥＧ−２パケット同期バイト位置を高い信頼性で検出すると共に、受信機のトランスポート層にＭＰＥＧ−２ストリーム放送を高い信頼性で同期および配信する方法および装置を提供する。ヌル・パケット検出回路は、現在のパケットのコンテンツを固定（または所定）ビット・パターンと比較し、ＭＰＥＧ−２ヌル・パケットを検出し、ヌル・パケット内のチェックサム・エンコード済み同期バイトの位置を高い信頼性で特定するように提供し得る。同期バイト位置は、ストリーム内の一つまたは複数のヌル・パケットのヘッダ部における、所定の固定ビット・パターンの位置に基づいて特定される。
本発明の上記の特徴は、その例示的実施形態を、添付図面を参照して詳細に説明することで更に明らかとなろう。
【発明を実施するための最良の形態】
【００２５】
図２は、本発明の実施形態による、ディジタル伝送システムの受信機側におけるＭＰＥＧフレーミング・ブロック２９９のブロック図である。本発明のＭＰＥＧフレーミング・ブロック２９９は、図１に示した従来技術によるＭＰＥＧフレーミング・ブロック２００に類似するが、三種類の追加ブロック、即ち、ヌル・パケット検出器２５０、状態機械２５５、および決定論理ブロック２６０を備えてよい。
【００２６】
ヌル・パケット検出器２５０は、シリアル・データ・ストリーム内で受信したヌル・パケットを検出する。
【００２７】
ヌル・パケットは、通常、固定データ・パターン（例えば、ゼロ）の前に所定のプリアンブルを有する。ヌル・パケットにおいて、プリアンブルは、ヌル・パケットに固有である、パケット・ヘッダ内の特定のビット含んでいる。こうしたビットは、次の通りである。
ａ）ｐａｙｌｏａｄ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｉｎｄｉｃａｔｏｒ＝‘０'
ｂ）ＰＩＤ＝０ｘ１ＦＦＦ
ｃ）Ｔｒａｎｓｐｏｒｔ＿ｓｃｒａｍｂｌｉｎｇ＿ｃｏｎｔｒｏｌ＝‘００'
ｄ）適応フィールド＝‘０１'
【００２８】
場合によりは、ヌル・パケットは、更に、所定のデータ・パターン（全てゼロ（０）、または全てゼロ以外のビットのシーケンス）を含むペイロード・データの前に、所定のプリアンブルを含んでもよい。
【００２９】
ヌル・パケット検出器２５０は、最初に、所定のヌル・パケット・プリアンブル（ｐｒｅａｍｂｌｅ）（例えば、０ｘ１ＦＦＦｈｅｘ（１６進）（８１９１ｄｅｃ（１０進））に等しいＰＩＤ）を検出し、所定のヌル・パケット・プリアンブルを検出すると、後続のデータ・ビットが予想される（所定の）固定データ・パターン（例えば、ゼロの連続）に等しいかを判断する。所定のヌル・パケット・プリアンブルが検出され、後続の所定の（固定）データ・パターンが検出された（例えば、ゼロに等しい）場合、ヌル・パケットは「発見」（検出）されたとみなされる。
【００３０】
代替実施形態では（例えば、ノイズおよび干渉に対するヌル・パケット検出の堅牢性を高めるために）、予想される（所定の）固定データ・パターンと受信ペイロード・データとの間の差（ビット・エラー）のビット数をカウント（計数）し、ビット差（ビット・エラー）カウントを、プログラム可能閾値Ｎｕｌｌ＿ｔｈｒｅｓｈと比較する。プリアンブルは検出されたが、非一致ビット数（カウントされたビット・エラー）がＮｕｌｌ＿ｔｈｒｅｓｈより大きい場合、パケットは、ヌル・パケットとはみなされず、その他の場合には（プリアンブルが検出された場合）、パケットは、ヌル・パケットとみなされる。所定のヌル・パケット・プリアンブルが検出され、その後、Ｎｕｌｌ＿ｔｈｒｅｓｈ以下であるビット・エラー数がカウントされると、ヌル・パケット検出器は、「ヌル検出信号」（Ｎｕｌｌ＿ｆｌａｇ）を生成する。Ｎｕｌｌ＿ｆｌａｇは、例えば、ヌル・パケットが検出された時に論理「１」となり、その他の場合に論理「０」となるように定義してよい。加えて、ヌル・パケット検出器２５０は、ヌル・パケットのプリアンブルおよび所定のデータ・パターンの検出により示されるような（パケット・ストリーム内の）（ヌル）パケット内部でのＭＰＥＧ同期バイトの位置を示すＮｕｌｌ＿ｓｙｎｃ信号を作成する。
【００３１】
検出の信頼性を高めるために、ヌル・パケット検出器の機能は、履歴特性の低域濾波（ローパス）フィルタリング機能により加減できる。状態機械２５５をヌル・パケット検出器２５０の後に提供し、ヌル検出器２５０の出力に基づいた同期バイト位置の選択における高い周波数の変動を除去する履歴特性を検出回路に与えてもよい。この機能は、ヌル・パケット検出器のロックを宣言する（この時点でＮｕｌｌ＿ｌｏｃｋは１に設定される）前に、指定（またはプログラム可能）閾値パケット数Ｌｏｃｋ＿Ｉｎ＿ｔｈｒｅｓｈ以上のカウントに対してＮｕｌｌ＿ｆｌａｇが１であるかを、所定またはプログラム可能パケット数Ｎｐａｃｋｅｔｓ１中にカウントすることで実行してよい。一方、Ｎｕｌｌ＿ｌｏｃｋが１になると、回路は、プログラム可能パケット数Ｎｐａｃｋｅｔｓ０（例えば、Ｎｐａｃｋｅｔｓ０＝Ｎｐａｃｋｅｔｓ１＝Ｎｐａｃｋｅｔｓ）中に、０であるＮｕｌｌ＿ｌｏｃｋの発生をカウントし、ロックの喪失を宣言する（この時点でＮｕｌｌ＿ｌｏｃｋは０に設定される）前に、指定（またはプログラム可能）閾値パケット数Ｌｏｃｋ＿Ｏｕｔ＿ｔｈｒｅｓｈ以上のカウントに対してＮｕｌｌ＿ｆｌａｇが０になったと判断する。一部の実施形態において、プログラム可能パケット数Ｎｐａｃｋｅｔｓ０およびＮｐａｃｋｅｔｓ１（受信パケット数、例えば、Ｎｐａｃｋｅｔｓに渡る検索「ウィンドウ」を表す）は、それぞれの閾値パケット数（Ｌｏｃｋ＿Ｏｕｔ＿ｔｈｒｅｓｈおよびＬｏｃｋ＿Ｉｎ＿ｔｈｒｅｓｈ）と等しくてもよいが、好ましくは、より大きく、検索ウィンドウ内の受信パケットの選択可能部分（例えば、四分の三）がヌル・パケットである（またはヌル・パケットではない）時に、Ｎｕｌｌ＿ｌｏｃｋが１に設定される（または０にリセットされる）ようになる。
【００３２】
履歴特性の他のバリエーションは、一般性を失うことなく可能であり、代替として、ヌル・パケット検出器２５０および（状態機械２５５の）履歴特性機能は、マイクロプロセッサまたはＡＳＩＣにより実行できる。
【００３３】
決定論理ブロック２６０は、次のように動作する：ヌル・パケット検出器２５０がヌル・パケットを検出しない時（例えば、Ｎｕｌｌ＿ｓｙｎｃ＝０およびＮｕｌｌ＿ｌｏｃｋ＝０）、ＭＰＥＧ同期出力（Ｓｙｎｃ）は、チェックサムに基づく同期検出器（シンドローム発生器２１０および検出器２２０ブロック）により、従来技術のように生成される（即ち、同期バイト位置は、チェックサムに基づく検出器２２０により決定されたＳｙｎｃ＿ｆｌａｇ信号により示される）。しかしながら、ヌル・パケットが検出された時（およびＮｕｌｌ＿ｌｏｃｋが１である時）、ＭＰＥＧ同期は、ヌル・パケット検出器２５０により決定され、その出力Ｎｕｌｌ＿ｓｙｎｃは、ＭＰＥＧ同期再挿入ブロック２４０において使用されるＭＰＥＧ同期出力（Ｓｙｎｃ）として使用される。決定論理ブロック２６０のエラー出力は、シンドローム検出器２２０から受信されるＥｒｒｏｒ＿ｆｌａｇと同じである。決定論理のロック出力は、Ｎｕｌｌ＿ｌｏｃｋが１である場合にＮｕｌｌ＿ｌｏｃｋとなり、Ｎｕｌｌ＿ｌｏｃｋが０である場合にＬｏｃｋ＿ｆｌａｇとなる。決定論理ブロック２６０は、ヌル検出器２５０から出力される従来のＳｙｎｃ＿ｆｌａｇおよびＮｕｌｌ＿ｓｙｎｃ信号を多重化し、上で説明した決定論理ブロック２６０の選択方法に従って、一方または他方を選択するマルチプレクサを事実上含む回路として実行してよい。本発明の代替実施形態において、状態機械（ステート・マシン）２５５（例えば、履歴特性フィルタ）の機能は、決定論理ブロック２６０に融合し、これに組み込んでもよい。
【００３４】
ＭＰＥＧフレーミング・ブロック２９９の残りの動作部分は、一般に、図１の従来技術と同様に動作する。
【００３５】
本発明の一部の実施形態において、ＭＰＥＧフレーミング装置（例えば、２９９）のヌル・パケット検出器２５０は、ヌル・パケットに関連する所定のプリアンブルを検出するように構成される（或いは、更に単純に、０ｘ１ＦＦＦｈｅｘ（１６進）（８１９１ｄｅｃ（１０進））に等しいＰＩＤフィールドのみを検出するように構成される）検出器を備えてよい。本発明の他の実施形態において、ヌル・パケット検出器２５０は、最初にプリアンブルを検出し、次に（パケットのペイロード内の）後続のデータ・ビットがヌル・パケットに関連する固定データ・パターン（例えば、ゼロの連続または全てゼロ）に対応するかのチェックに進んでよい。本発明の一部の実施形態において、ヌル・パケット検出器２５０の（Ｎｕｌｌ＿ｆｌａｇ）出力は、（例えば、状態機械２５５により実行される履歴機能により）フィルタリングされ、フィルタ済み出力（Ｎｕｌｌ＿ｌｏｃｋ）が生成される。本発明の他の実施形態において、ヌル・パケット検出器２５０の出力は、フィルタリングされない（図３参照）。
【００３６】
本発明の実施形態によるＭＰＥＧフレーミング・ブロック（例えば、図２の２９９）の動作について、図３および図４を参照して更に説明する。
【００３７】
図３は、本発明の実施形態による、同期バイト位置を選択するために実行される一般的方法を説明するフロー・チャートである。ステップＳ１において、固定長（例えば、１８８バイト）パケットを備えたシリアル・データ・ストリームは、所定のプロトコルに準拠する（例えば、ＡＮＳＩ／ＳＣＴＥ  ０７  ２０００およびＩＴＵ−Ｔ  Ｊ．８３Ｂ規格に準拠する）ディジタル・エンコード（ＭＰＥＧ−２）信号として受信され、プロトコルは、複数のパケット・タイプ（例えば、ヌル・パケット）を定義し、各パケットは、ヘッダ部（パケットをヌル・パケットとして特定するプリアンブルを含むことが可能）と、ペイロード・データ部とを含み、ヘッダ部は、チェックサム・エンコード済みの同期バイトを含んでいる。
【００３８】
ステップＳ２において、受信されたシリアル・データ・ストリームは、ＡＮＳＩ／ＳＣＴＥ  ０７  ２０００規格において指定されたシンドローム発生器（例えば、この規格の図３に例示されたシンドローム発生器を参照）を介して送られ、次に、シンドローム検出器２２０は、シンドローム発生器の出力を、所定の同期チェックサムと比較して、（可能性のある）同期バイトが検出されたかを決定する。
【００３９】
ステップＳ２において実行された従来のチェックサム方法により同期バイトが検出された場合、次にステップＳ３が実行され、ステップＳ４ＡまたはステップＳ４Ｂの一方が実行され、その後、ステップＳ５およびステップＳ６が実行される。
【００４０】
ステップＳ３では、現在の受信パケットがヌル・パケットか否かを判断する。現在の受信パケットがヌル・パケットであるとされた場合、ヌル・フラグ（Ｎｕｌｌ＿ｆｌａｇ）が（例えば、１に）設定され、ステップＳ４ＡとステップＳ５およびステップＳ６とが実行され、現在の受信パケットがヌル・パケットではないとされた場合、ヌル・フラグ（Ｎｕｌｌ＿ｆｌａｇ）が（例えば、０に）リセットされ、ステップＳ４ＢとステップＳ５およびステップＳ６とが実行される。
【００４１】
次に、ステップＳ５では、ステップＳ４ＡおよびステップＳ４Ｂの一方により選択された同期バイト位置に同期バイト値（４７ｈｅｘ（１６進））が再挿入され、ステップＳ６において、上記のように復元された同期バイトを含むデータ・ストリームが、復元された標準のＭＰＥＧ−２トランスポート・ストリームとして、トランスポート層へ出力される。
【００４２】
図４は、本発明の別の実施形態による、データ・ストリームが多数のヌル・パケットを含むか否かを検出するために使用されるアルゴリズムを更に正確に説明するフロー・チャートである。
【００４３】
ヌル・パケット検出ステップＳ３Ｂは、図３の単純なヌル・パケット検出ステップＳ３の代替方法であり、図２のヌル検出器２５０および状態機械２５５により実行可能であり、サブステップＢ１、Ｂ２、およびＢ３を備えている。従来のチェックサム方法により（図３のステップＳ２において実行されるように）同期バイトが検出された場合、ステップＳ３Ｂが実行される（その後、ステップＳ４ＡまたはステップＳ４Ｂの何れかが実行され、次に図３のステップＳ５およびステップＳ６が実行される）。
【００４４】
サブステップＢ１では、現在の受信パケットが（例えば、チェックサムに基づく同期により示されるようなヘッダ（ＰＩＤ）位置において）ヌル・パケットに関連する所定のプリアンブル（例えば、０ｘ１ＦＦＦｈｅｘ（１６進）（８１９１ｄｅｃ（１０進））に等しいＰＩＤを含む）を含むか否かが判断される。所定のヌル・パケット・プリアンブルが（予想位置において）検出された場合、ヌル・フラグ（Ｎｕｌｌ＿ｆｌａｇ）は、サブステップＢ２において行われる判断を条件として、暫定的に（例えば、１に）設定してよく、次にサブステップＢ２が実行される。所定のヌル・パケット・プリアンブル（第１の固定ビット・パターン）が（予定位置において）検出されない場合、ヌル・フラグ（Ｎｕｌｌ＿ｆｌａｇ）は、（例えば、０に）リセットされ、その判断（Ｎｕｌｌ＿ｆｌａｇ）は、履歴特性サブステップＢ３へ送信される。
【００４５】
サブステップＢ２では、現在の受信パケットの（後続の）データ・ペイロードが所定の固定データ・パターン（第２の固定ビット・パターン、例えば、ゼロ（０）の連続または全てゼロ）を含むか否かが判断される。受信データと所定の（固定）データ・パターンとの間のビット差（エラービット数）がカウントされ、プログラム可能閾値Ｎｕｌｌ＿ｔｈｒｅｓｈと比較される。所定の（固定）データ・パターンが検出された場合（例えば、ゼロに等しいデータ・ビットまたはエラー・ビット数が、Ｎｕｌｌ＿ｔｈｒｅｓｈ以下）、ヌル・パケットが「発見」（検出）されたとみなされ、ヌル・フラグ（Ｎｕｌｌ＿ｆｌａｇ）は（例えば、１に）設定され、次にサブステップＢ３が実行される。
【００４６】
所定の（固定）データ・パターン（例えば、ゼロの連続または全てゼロ）が（Ｎｕｌｌ＿ｔｈｒｅｓｈ閾値内で）検出されなかった場合、ヌル・フラグ（Ｎｕｌｌ＿ｆｌａｇ）は（例えば、０に）リセットされ、その判断（Ｎｕｌｌ＿ｆｌａｇ）は、履歴特性サブステップＢ３へ送信される。従って、所定の（固定）データ・パターンが検出されなかった（多数のエラー・ビットがカウントされた）場合、ヌル・パケットは、「発見」（検出）されなかったとみなされ、ヌル・フラグ（Ｎｕｌｌ＿ｆｌａｇ）は（例えば、０に）リセットされ、次にサブステップＢ３が実行される。
【００４７】
サブステップＢ３では、サブステップＢ１またはサブステップＢ２の何れかにより生じたＮｕｌｌ＿ｆｌａｇ信号が、（例えば、履歴特性により）フィルタリングされる。このフィルタリングは、状態機械（例えば、図２の２５５）により実行可能であり、シリアル・データ・ストリームを介して受信されたパケットにおけるＭＰＥＧ−２同期バイトの本来の位置を特定するために使用されるヌル・パケットの（例えば、図２のヌル検出器２５０による）検出を示すフラグにおける急速な変動を低減できる。こうした履歴特性の実行の詳細は、図２の状態機械２５５の動作に関する上記説明に関連して前述したものと同じにすることが可能であり、パケット数について判断されたヌル・パケット状態（例えば、Ｎｐａｃｋｅｔｓが１より大きい）を調べて、（図３のステップＳ４ＡまたはステップＳ４Ｂの何れかの実行を選択するために）状態機械の決定出力を判断する。フィルタリング・サブステップＢ３の結果は、次に、図３のステップＳ４ＡまたはステップＳ４Ｂの何れかの実行を選択するために使用され、その後、ステップＳ５およびステップＳ６が実行される。
【００４８】
以上、本発明の例示的実施形態を説明すると共に図示してきた。しかしながら、本発明は、上記の例示的実施形態に限定されず、本発明の趣旨および範囲内で、当業者が変更および変形を成し得ることは明らかであろう。従って、例示的実施形態は、限定としてではなく、例として理解されるべきである。本発明の範囲は、上記説明ではなく特許請求の範囲により決定され、特許請求の範囲および等価物により画定される本発明の範囲から逸脱することなく本発明の実施形態に変更および変形を施し得る。
【図面の簡単な説明】
【００４９】
【図１】ディジタル伝送システムの受信機側における従来技術によるＭＰＥＧフレーミング・ブロックのブロック図である。
【図２】本発明の実施形態による、ディジタル伝送システムの受信機側におけるＭＰＥＧフレーミング・ブロックのブロック図である。
【図３】本発明の実施形態による、ヌル・パケットの場合の同期バイト位置を決定するために実行される方法を説明するフロー・チャートである。
【図４】本発明の別の実施形態による、ヌル・パケットを含むデータ・ストリームを検出するために使用されるアルゴリズムを更に正確に説明するフロー・チャートである。
【図１】
0004848274.tif 000002
【図２】
0004848274.tif 000003
【図３】
0004848274.tif 000004
【図４】
0004848274.tif 000005