(57)【要約】【課題】ＦＥＣ復号化の待ち時間およびパケット・バッファのサイズが著しく低減する、ＦＥＣ復号化のための受信機および方法を提供すること。【解決手段】一実施形態では、リアルタイム伝送プロトコル（ＲＴＰ）および前方誤り訂正（ＦＥＣ）を利用するメディア・パケットのフレーム用の受信機を開示する。この受信機は、パケット・バッファおよびＦＥＣデコーダを備える。パケット・バッファがパケットを受信した後に、ＦＥＣデコーダは、このパケットを読み取り、ＦＥＣ処理の一部として、フレーム全体（または、実際にはフレームの任意の後続パケット）を受信するのを待つことなく、このパケットに対してＸＯＲ演算を実行する。フレーム内の欠落パケットを再構成するのに十分なパケットを受信するまで、ＸＯＲ演算の結果が蓄積される。このＸＯＲ演算は、後続のパケットを待つことによるいかなる遅延もなく、パケットを受信した後ただちに実行されるので、受信機の待ち時間は非常に少なく、パケット・バッファは相対的に小さくてもよい。【選択図】図４
2011055500.tif 000002
【特許請求の範囲】
【請求項１】
受信機内で誤り訂正（ＥＣ）処理を実行するための方法であって、
（ａ）３つ以上のデータ・パケットおよびＥＣパケットを含む第１のフレームのパケットのサブセットを連続的に受信すること、ならびに
（ｂ）前記第１のフレームのパケットの前記サブセットにＥＣ処理を実行して、前記第１のフレームのうちの少なくとも１つのパケットを再構成することであって、前記ＥＣ処理が、パケットの前記サブセット全体を受信する前に開始されることを含む方法。
【請求項２】
前記ＥＣ処理は、前記サブセット内の後続パケットの受信を待つことなく、受信すると前記サブセット内の各パケットを処理することを含む、請求項１に記載の発明。
【請求項３】
前記サブセット内の少なくとも１つの受信パケットについて、前記ＥＣ処理は、
（ｂ１）前記受信パケット、およびメモリに格納された値に数学演算を実行すること、ならびに
（ｂ２）後続の数学演算用に前記メモリ内に格納される値として、前記数学演算の結果を格納することを含む、請求項２に記載の発明。
【請求項４】
前記サブセット内の最後の受信パケットについて、前記ＥＣ処理は、
（ｂ３）前記最後の受信パケット、および前記メモリに格納された前記値に最後の数学演算を実行すること、ならびに
（ｂ４）前記最後の数学演算の結果に基づいて、前記第１のフレームの欠落データ・パケットを再構成することを含む、請求項３に記載の発明。
【請求項５】
（ｃ）３つ以上のデータ・パケットおよびＥＣパケットを含む第２のフレームのパケットのサブセットを連続的に受信すること、ならびに
（ｄ）前記第２のフレームのパケットの前記サブセットにＥＣ処理を実行して、前記第２のフレームのうちの少なくとも１つのパケットを再構成することであって、前記第２のフレームの前記ＥＣ処理が、前記第１のフレームの前記ＥＣ処理が完了する前に開始されることをさらに含む、請求項１に記載の発明。
【請求項６】
前記第１のフレームの前記ＥＣ処理は、前記第２のフレームの前記ＥＣ処理が開始する前に開始される、請求項５に記載の発明。
【請求項７】
（ａ１）前記第１のフレームのパケットの前記サブセット内の各パケットを、パケット・バッファ内に格納すること、
（ａ２）前記パケットにＥＣ処理を実行する前に、前記パケット・バッファから各パケットを読み取ること、および
（ｃ）前記第１のフレームのパケットの前記サブセット内の各パケットへのＥＣ処理が完了した後に、再構成されたパケットを前記パケット・バッファ内に格納することをさらに含む、請求項１に記載の方法。
【請求項８】
３つ以上のデータ・パケットおよび誤り訂正（ＥＣ）パケットを含む第１のフレームのパケットのサブセットを連続的に受信するように構成されたパケット・バッファ、ならびに
前記第１のフレームのパケットの前記サブセットにＥＣ処理を実行して、前記第１のフレームのうちの少なくとも１つのパケットを再構成するように構成されたＥＣデコーダであって、前記ＥＣ処理が、パケットの前記サブセット全体を受信する前に開始されるＥＣデコーダを備える受信機。
【請求項９】
受信機内で誤り訂正（ＥＣ）処理を実行する装置であって、
（ａ）３つ以上のデータ・パケットおよびＥＣパケットを含む第１のフレームのパケットのサブセットを連続的に受信する手段、ならびに
（ｂ）前記第１のフレームのパケットの前記サブセットにＥＣ処理を実行して、前記第１のフレームのうちの少なくとも１つのパケットを再構成する手段であって、前記ＥＣ処理が、パケットの前記サブセット全体を受信する前に開始される手段を備える装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、誤り訂正デコーダ、および詳細には前方誤り訂正（ＦＥＣ）デコーダを有する受信機におけるバッファ・メモリ管理に関する。
【背景技術】
【０００２】
ＦＥＣ技法は、普通はインターネットなどのパケットベースのネットワークで使用されて、パケット損失を補償する。リアルタイム伝送プロトコル（ＲＴＰ）を利用するリアルタイム・メディアのパケットとともに使用するのに適したＦＥＣ技法は、米国特許第６，１４１，７８８号、およびインターネット協会から１９９９年１２月発行のＪ．  Ｒｏｓｅｎｂｅｒｇらによる「Ａｎ  ＲＴＰ  Ｐａｙｌｏａｄ  Ｆｏｒｍａｔ  ｆｏｒ  Ｇｅｎｅｒｉｃ  Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ」と題するインターネット標準化過程プロトコル番号ＲＦＣ−２７３３に記載されており、それぞれその全体を参照により本明細書に組み込む。この技法によれば、伝送する前に、チェックサム・パケットまたはＦＥＣパケットと呼ばれる追加のパケットが、メディア・フレームまたはデータ・パケットのブロックに追加される。受信機において、チェックサム・パケットと首尾よく受信したデータ・パケットとを組み合わせることにより、フレーム内の損失データ・パケットを回復し再構成することができる。より具体的には、チェックサム・パケットと首尾よく受信したデータ・パケットに数学演算（たとえば、排他的論理和（ＸＯＲ）論理演算）を実行することにより、損失データ・パケットが回復される。次いで、この数学演算の結果から、損失データ・パケットを再構成することができる。
【０００３】
図１には、インターネット標準化過程プロトコル番号ＲＦＣ−２７３３によるＦＥＣ復号化を利用する、従来の受信機１００が示してある。受信機１００は、ＦＥＣデコーダ１０８および再生バッファ１０６に接続されたパケット・バッファ１０４を備える。ＦＥＣデコーダ１０８も、再生バッファ１０６に接続されている。
【０００４】
図２には、従来の受信機１００の動作が示してある。ブロック２０２で動作が始まる。ブロック２０４で、受信パケット１０２が、パケット・バッファ１０４に格納される。ブロック２０６で、パケット１０２のコピーが再生バッファ１０６に転送されるが、パケット１０２は、ＦＥＣデコーダ１０８による後続処理のためにパケット・バッファ１０４内に保持される。ブロック２０８で、ＦＥＣデコーダ１０８は、（たとえば、所与のメディア・フレームＦについて、ＦＥＣパケットおよび１つのデータ・パケットを除くすべてのデータ・パケットを受信したとき）、パケット１０２の属するメディア・フレームＦがＦＥＣ復号化可能かどうか判定する。符号化が可能でない場合には、動作はブロック２０４に戻り、そこで後続のパケットを受信して格納する。しかし、フレームＦがＦＥＣ復号化可能である場合、ブロック２１０で、ＦＥＣデコーダ１０８は、メディア・フレームＦについての受信パケット（すなわち、１つのデータ・パケットを除くすべてのデータ・パケットおよびＦＥＣパケット）をパケット・バッファ１０４から読み取り、受信パケットに数学演算（たとえば、ＸＯＲ論理演算）を実行する。ブロック２１２で、よく知られた技法により、ＦＥＣデコーダ１０８は、数学演算の結果に基づいて欠落パケットを再構成する。ブロック２１４で、ＦＥＣデコーダ１０８は、回復したパケットを再生バッファ１０６に転送する。
【０００５】
しかし、従来の受信機１００の不利な点は、パケット・バッファ１０４のサイズが相対的に大きくなることである。たとえば、ＭＰＥＧメディア・フレームは、２４までのデータ・パケットに加えて１つのＦＥＣパケットの、合計２５のパケットを有することができる。したがって、ＭＰＥＧメディア・フレームを格納する必要があるパケット・バッファ１０４内のバッファ・メモリの量ＭｅｍＰｅｒＦｒａｍｅは、以下の通り定義することができる。
【０００６】
【数１】
2011055500.tif 000003
さらに、各パケットは、最大サイズのユーザデータグラムプロトコル（ＵＤＰ）最大パケット・サイズ（たとえば、従来のイーサネットの最大伝送単位（ＭＴＵ）のサイズである１．５ＫＢ）を有することがある。したがって、サイズが１．５ＫＢの２５のパケットを有するＭＰＥＧメディア・フレームは、３７．５ＫＢのメモリを必要とするはずである。
【０００７】
こうしたｍ個のフレームを格納するために必要となる合計バッファ・メモリは、（ｍ×ＭｅｍＰｅｒＦｒａｍｅ）である。パケット・バッファ１０４に格納しなければならないフレームの数ｍは、いくつかの変数の関数であり、それらの変数は（ｉ）ＦＥＣデコーダ１０８の待ち時間（すなわち、フレームの第１のパケットの受信と、そのフレームに対するＦＥＣ復号化の開始との間の期間）、（ｉｉ）ＦＥＣ復号化の遅延（すなわち、たとえばフレームに対して２４組のＸＯＲ論理演算を実行することを含む、フレームに対するＦＥＣ復号化の開始からＦＥＣ復号化の完了までの期間）、および（ｉｉｉ）入力パケットのパケット・ジッタを含む。従来の受信機１００では、パケット・バッファ１０４内に格納されるフレームの数ｍは、通常１２から３０の間である。したがって、従来の受信機１００が、ＭＰＥＧメディア・パケットを受信するように設計されている場合、パケット・バッファ１０４は、４５０ＫＢから１．１２５ＭＢの間のメモリを通常必要とするはずである。
【０００８】
この説明では、図３には、パケット・バッファ１０４の例示的な一実装形態が示してあり、このパケット・バッファには１２のメディア・フレーム３０２１〜３０２１２（それぞれ２５のパケットを有する）を格納することができる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許第６，１４１，７８８号
【非特許文献】
【００１０】
【非特許文献１】インターネット協会から１９９９年１２月発行のＪ．  Ｒｏｓｅｎｂｅｒｇらによる「Ａｎ  ＲＴＰ  Ｐａｙｌｏａｄ  Ｆｏｒｍａｔ  ｆｏｒ  Ｇｅｎｅｒｉｃ  Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ」と題するインターネット標準化過程プロトコル番号ＲＦＣ−２７３３
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の例示的な一実施形態は、ＦＥＣ復号化の待ち時間およびパケット・バッファのサイズが著しく低減する、ＦＥＣ復号化のための受信機および方法を提供する。
【課題を解決するための手段】
【００１２】
したがって、第１の実施形態では、本発明は、受信機内で誤り訂正（ＥＣ）処理を実行するための方法である。３つ以上のデータ・パケットおよびＥＣパケットを含む第１のフレームのパケットのサブセットが連続的に受信される。この第１のフレームのパケットのサブセットにＥＣ処理が実行されて、第１のフレームのうちの少なくとも１つのパケットを再構成する。このＥＣ処理は、パケットのサブセット全体を受信する前に開始される。
【００１３】
他の実施形態では、本発明は受信機である。この受信機は、３つ以上のデータ・パケットおよび誤り訂正（ＥＣ）パケットを含む第１のフレームのパケットのサブセットを連続的に受信するように構成されたパケット・バッファを備える。この受信機はさらに、第１のフレームのパケットのサブセットにＥＣ処理を実行して、第１のフレームのうちの少なくとも１つのパケットを再構成するように構成されたＥＣデコーダを備え、このＥＣ処理は、パケットのサブセット全体を受信する前に開始される。
【００１４】
本発明の他の態様、特徴、および利点は、以下の詳細な説明、添付特許請求の範囲、および添付図面から、より完全に明白になるであろう。各図面において、同じ参照番号は、同様のまたは同一の要素を指す。
【図面の簡単な説明】
【００１５】
【図１】ＦＥＣ復号化を利用する従来の受信機の簡略化されたブロック図である。
【図２】図１の従来の受信機の動作を示す流れ図である。
【図３】図１の従来の受信機でのパケット・バッファの説明図である。
【図４】本発明によるＦＥＣ復号化を利用する受信機の一実施形態の簡略化されたブロック図である。
【図５】図４に示した受信機の動作を示す流れ図である。
【図６】図４に示した受信機でのパケット・バッファの説明図である。
【図７】図４に示した受信機におけるＦＥＣデータ構造を含むキャッシュ・メモリの一部分の説明図である。
【図８】図５に示したフレーム判定ブロックのより詳細な流れ図である。
【図９】図４に示した受信機のより詳細なブロック図である。
【発明を実施するための形態】
【００１６】
本明細書において「一実施形態（ｏｎｅ  ｅｍｂｏｄｉｍｅｎｔ）」または「一実施形態（ａｎ  ｅｍｂｏｄｉｍｅｎｔ）」という場合、その実施形態に関して記述された具体的な特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれ得ることを意味する。本明細書の様々な場所で「一実施形態では（ｉｎ  ｏｎｅ  ｅｍｂｏｄｉｍｅｎｔ）」という表現が現れるが、必ずしもすべてが同じ実施形態を指すものではなく、または他の実施形態を必然的に相互に排除する別個のまたは代替の実施形態でもない。同じことが「実装形態」という用語にも当てはまる。
【００１７】
図４は、本発明による受信機４００の一実施形態を示す。図４に示すように、受信機４００は、パケット・バッファ４０４、再生バッファ４０６、ＦＥＣデコーダ４０８、およびＦＥＣキャッシュ４１０を備える。受信機４００では、ＦＥＣデコーダ４０８は、各受信パケットを実質的にリアルタイムに、たとえば各パケットが到達し、パケット・バッファ４０４に格納された後すぐに処理する。パケットの属するフレームが不完全な場合でも、ＦＥＣ処理は各パケットに対して開始される。こうした理由で、ＦＥＣデコーダ４０８は、ＦＥＣキャッシュ４１０に格納されるＦＥＣ処理中間結果を生成し維持する。各入力パケットを受信しＦＥＣ処理した後に、ＦＥＣデコーダ４０８は、ＦＥＣキャッシュ４１０に格納された中間結果を更新する。したがって、ＦＥＣデコーダ４０８は、図１の従来技術のＦＥＣデコーダ１０８とは異なるが、ＦＥＣデコーダ１０８は、メディア・フレーム内のデータ・パケットのうちの１つを除くすべてのパケットを受信するまで待ってから、ＦＥＣ処理を開始する。
【００１８】
ＦＥＣデコーダ４０８は、実質的にリアルタイムで（受信すべきフレーム内で、さらなるパケットを待つことなく）受信パケットを処理するので、パケット・バッファ４０４は、図１の従来技術のパケット・バッファ１０４よりも著しく小さくてよい。パケット・バッファ４０４は、（ｉ）受信パケットを再生バッファ４０６に転送するために、また（ｉｉ）受信パケットをＦＥＣデコーダ４０８に転送するために、必要とされる期間のみ受信パケットを格納する。こうした転送が完了した後に、受信パケットが占めているパケット・バッファ４０４内のメモリは、クリアされ、別の入力パケット用に使用されてもよい。したがって、パケット・バッファ４０４は、フレームがＦＥＣ処理可能と見なされるまでフレームにおけるパケットのすべてを格納する必要はない。したがって、再生バッファ４０６は、再生バッファ１０６よりも著しく小さくてよい（たとえば、約１／２〜約１／１０の範囲）。
【００１９】
たとえば、一実施形態では、再生バッファ４０６は、約１２から約２４の間のパケット（これらのパケットは、１２の異なる連続伝送されるフレームに属してもよい）を格納することができるようなサイズにしてもよく、ＦＥＣデコーダ４０８は、これら１２の連続伝送されるフレームについて、パケットをＦＥＣ処理するように構成される。しかし、パケット・バッファ４０４が扱うように設計されているパケットの数、およびＦＥＣデコーダ４０８が扱うように設計されているフレームの数は、パケットベースのネットワーク内でのパケット・ジッタ、ＦＥＣデコーダ４０８の待ち時間、およびＦＥＣデコーダ４０８の処理遅延に基づいて変化させてもよいことを理解されたい。
【００２０】
説明を簡潔にするために、一実施形態では、受信機４００は、同時に連続伝送される３つのメディア・フレームに属するパケット上で、ＦＥＣデコーダ４０８が動作できるようにするのに十分に小さいパケット・ジッタを有する通信システムで使用するように設計されていることを、以下に仮定する。こうした一実施形態では、ＦＥＣキャッシュ４１０は、とりわけ、連続伝送される３つのメディア・フレーム（以下では、前のフレームＦ１、現在のフレームＦ２、および次のフレームＦ３と呼ぶ）についての中間の数学的結果（たとえば、ＸＯＲ論理演算結果）を格納するための３つの記憶場所ｆｅｃ＿ｓｔｒ１、ｆｅｃ＿ｓｔｒ２、およびｆｅｃ＿ｓｔｒ３（図４には図示せず）と、現在の受信パケットを格納するための１つの記憶場所ｃｕｒｒｅｎｔ＿ｐａｃｋｅｔとを含む。ＦＥＣフレームによって保護されるパケットの数は、当業者に知られている技法に従って、受信機４００と送信機（図示せず）の間で事前に決定されるか取り決められることを、以下でさらに仮定する。
【００２１】
図５には、受信機４００の動作が示してある。ブロック５０２で動作が始まる。ブロック５０４で、記憶場所ｆｅｃ＿ｓｔｒ１、ｆｅｃ＿ｓｔｒ２、およびｆｅｃ＿ｓｔｒ３がクリアされる（たとえば、ゼロにセットされる）。ブロック５０６で、受信パケット４０２が、パケット・バッファ４０４に格納される。ブロック５０８で、受信パケット４０２は、パケット・バッファ４０４から、ＦＥＣキャッシュ４１０内の記憶場所ｃｕｒｒｅｎｔ＿ｐａｃｋｅｔおよび再生バッファ４０６に転送され、受信パケット４０２が占めているパケット・バッファ４０４内の記憶場所を他のパケット用に解放する。ブロック５１０で、ＦＥＣデコーダ４０８は、パケット４０２のヘッダ情報を読み取り、パケット４０２がどちらのメディア・フレーム（たとえば、前のフレームＦ１）に属しているのか判定する。
【００２２】
ブロック５１２で、ＦＥＣデコーダ４０８は、パケット４０２の属するメディア・フレーム（たとえば、前のフレームＦ１）において、パケット４０２が、受信機４００が受信した第１のパケットであるかどうか判定する。そうである場合、ブロック５１４で、ＦＥＣデコーダは、パケット４０２の属するメディア・フレームに対応する記憶場所（ｆｅｃ＿ｓｔｒ１、ｆｅｃ＿ｓｔｒ２、またはｆｅｃ＿ｓｔｒ３）にパケット４０２を格納し、動作はブロック５０６に戻って、別の受信パケットを処理する。パケット４０２の属するメディア・フレーム（たとえば、前のフレームＦ１）において、パケット４０２が、受信機４００が受信した第１のパケットではない場合、ブロック５１６で、ＦＥＣデコーダ４０８は、パケット４０２のデータ部分と、このパケットの属するメディア・フレームに対応する記憶場所（たとえば、ｆｅｃ＿ｓｔｒ１）のコンテンツとの間で数学演算（たとえば、ＸＯＲ論理演算）を実行する。次いで、数学演算の結果は、同じ記憶場所（たとえば、ｆｅｃ＿ｓｔｒ１）に格納され、それにより、この記憶場所の前のコンテンツを置き換える。
【００２３】
ブロック５１８で、ＦＥＣデコーダは、パケット４０２の属するメディア・フレームがＦＥＣ復号化可能かどうか判定する（たとえば、このメディア・フレームについて、ＦＥＣパケットおよび１つのデータ・パケットを除くすべてのデータ・パケットを受信したときに）。（図８を参照しながら、フレーム判定ブロック５１８を、以下でより詳細に説明する。）パケット４０２の属するフレームがＦＥＣ復号化可能でない場合、動作はブロック５０６に戻って、別の受信パケットを処理する。
【００２４】
メディア・フレームがＦＥＣ復号化可能である場合、ブロック５２０で、ＦＥＣデコーダ４０８は、パケット４０２の属するメディア・フレーム（たとえば、前のフレームＦ１）に対応する記憶場所（たとえば、ｆｅｃ＿ｓｔｒ１）に格納されている数学演算結果を使用して、米国特許第６，１４１，７８８号およびインターネット標準化過程プロトコル番号ＲＦＣ−２７３３に記載されている技法など、よく知られた技法に従って、欠落パケットを再構成する。最後に、ブロック５２２で、ＦＥＣデコーダ４０８は、回復されたパケットを再生バッファ４０６内に格納し、次の入力パケットのために記憶場所（たとえば、ｆｅｃ＿ｓｔｒ１）がクリアされる。
【００２５】
図６は、ＦＥＣキャッシュ４１０の説明図である。一実施形態では、ＦＥＣキャッシュ４１０は、３つのデータ構造（または、定義されたメモリ部分）６０２１、６０２２、および６０２３（それぞれ、ＦＥＣ＿ＲＸ＿ＤＡＴＡ１、ＦＥＣ＿ＲＸ＿ＤＡＴＡ２、およびＦＥＣ＿ＲＸ＿ＤＡＴＡ３とされる）、ならびに現在の受信パケットを格納するためのｃｕｒｒｅｎｔ＿ｐａｃｋｅｔの記憶場所６０４を含む。データ構造（または、定義されたメモリ部分）６０２１、６０２２、および６０２３において、ＦＥＣデコーダ４０８は、それぞれメディア・フレームＦ１、Ｆ２、およびＦ３をＦＥＣ復号化するのに有用な情報を格納する。
【００２６】
一実施形態では、データ構造６０２１、６０２２、および６０２３は、以下のように定義される。
ｔｙｐｅｄｅｆ  ｓｔｒｕｃｔ  ＦＥＣ＿ＲＸ＿ＤＡＴＡ
｛
ｕｉｎｔ１６＿ｔ  ｓｎｍｉｎ；
ｕｉｎｔ１６＿ｔ  ｓｎｍａｘ；
ｕｉｎｔ８＿ｔ  ｆｅｃ＿ｓｔｒ  ［ＭＡＸ＿ＲＴＰ＿ＰＡＣＫＥＴ＿ＳＩＺＥ］；
ｕｉｎｔ１６＿ｔ  ｆｓｔｒｌｅｎ；
ｕｉｎｔ８＿ｔ  ｆｅｃ＿ｒｅｃ  ［ＭＡＸ＿ＲＴＰ＿ＰＡＣＫＥＴ＿ＳＩＺＥ］；
ｕｉｎｔ１６＿ｔ  ｆｒｅｃｌｅｎ；
ｓｔｒｕｃｔ  ＦＥＣ＿ＲＸ＿ＤＡＴＡ  ＊  ｐｒｅｖ；
ｓｔｒｕｃｔ  ＦＥＣ＿ＲＸ＿ＤＡＴＡ  ＊  ｎｅｘｔ；
｝  ＦＥＣ＿ＲＸ＿ＤＡＴＡ＿ｔ；
ここで、データ・フィールドは以下のように定義される。
【００２７】
【表１】
2011055500.tif 000004
【００２８】
説明するために、図７には、データ構造６０２１が図示してある。
【００２９】
図８は、図５のフレーム判定ブロック５１０をより詳細に示す流れ図であり、ここで、ＦＥＣデコーダ４０８は、受信パケット４０２がどのメディア・フレーム（たとえば、前のフレームＦ１）に属するのか判定する。
【００３０】
ブロック８０２で、ＦＥＣデコーダ４０８は、図４に示したパケット・バッファ４０４内に格納されている受信パケット４０２の、ペイロード・タイプ記述子ＰＴおよびシーケンス番号ＳＮＲｃｖｄを読み取る。ブロック８０４で、ＦＥＣデコーダ４０８は、受信パケット４０２がＦＥＣパケットである（すなわち、ペイロード・タイプ記述子ＰＴが所定の値ＦＥＣ＿ＴＹＰＥに等しい）かどうか検査する。受信パケット４０２がＦＥＣパケットでない場合、ブロック８０６で動作が続く。ブロック８０６で、ＦＥＣデコーダ４０８は、シーケンス番号ＳＮＲｃｖｄが、現在のフレームＦ２内のメディア・パケットの最小シーケンス番号ｓｎｍｉｎよりも大きい、またはそれと等しいかを検査する。そうでない場合、ブロック８０８で、ＦＥＣデコーダ４０８は、受信パケット４０２を前のフレームＦ１に属するものと識別し、ポインタが、前のフレームＦ１に関係するＦＥＣ復号化情報を格納するための定義された記憶場所であるデータ構造６０２１（ＦＥＣ＿ＲＸ＿ＤＡＴＡ１）にセットされる。ブロックＩｉで動作が続き、ここで動作は、図５のブロック５１６に戻る。ブロック５１６で、ＦＥＣデコーダ４０８は、ポインタを使用して、パケット４０２のデータ部分に数学演算を実行する際に使用される記憶場所（たとえば、ｆｅｃ＿ｓｔｒ１）を有するデータ構造（たとえば、ＦＥＣ＿ＲＸ＿ＤＡＴＡ１）を識別する。
【００３１】
しかし、ブロック８０６で、シーケンス番号ＳＮＲｃｖｄが、現在のフレームＦ２内のメディア・パケットの最小シーケンス番号ｓｎｍｉｎよりも大きい、またはそれと等しいとＦＥＣデコーダ４０８が判定する場合、動作はブロック８１０に進む。ＦＥＣデコーダ４０８は、受信パケットのシーケンス番号ＳＮＲｃｖｄと、現在のフレームＦ２内のＲＴＰメディア・パケットの最小シーケンス番号ｓｎｍｉｎとの差が、ＦＥＣパケットによって保護することができるパケットの所定の最大数ＭＡＸ＿ＦＥＣ＿ＰＫＴ＿ＰＥＲ＿ＦＥＣよりも大きいまたはそれと等しいかどうか検査する。たとえば、ＭＰＥＧ  ＲＴＰメディア・フレームでは、ＦＥＣパケットによって保護することができるパケットの、所定の最大数ＭＡＸ＿ＦＥＣ＿ＰＫＴ＿ＰＥＲ＿ＦＥＣは２４である。
【００３２】
受信パケットのシーケンス番号ＳＮＲｃｖｄと、現在のフレームＦ２内のＲＴＰメディア・パケットの最小シーケンス番号ｓｎｍｉｎとの差が、所定の最大数ＭＡＸ＿ＦＥＣ＿ＰＫＴ＿ＰＥＲ＿ＦＥＣよりも大きくなくまたそれと等しくもない（すなわちそれ未満の）場合、ブロック８１４で、ＦＥＣデコーダ４０８は、受信パケット４０２を現在のフレームＦ２に属するものと識別する。具体的には、ポインタがデータ構造６０２２（ＦＥＣ＿ＲＸ＿ＤＡＴＡ２）にセットされ、ＦＥＣ復号化情報を格納するための定義された記憶場所は、現在のフレームＦ２に関係する。ブロックＩｉで動作が続き、ここで動作は、図５のブロック５１６に戻る。ブロック５１６で、ＦＥＣデコーダ４０８は、ポインタを使用して、データ・パケット４０２のデータ部分に数学演算を実行する際に使用される記憶場所（たとえば、ｆｅｃ＿ｓｔｒ２）を有するデータ構造（たとえば、ＦＥＣ＿ＲＸ＿ＤＡＴＡ２）を識別する。
【００３３】
ブロック８１０に戻ると、受信パケットのシーケンス番号ＳＮＲｃｖｄと、現在のフレームＦ２内のＲＴＰメディア・パケットの最小シーケンス番号ｓｎｍｉｎとの差が、所定の最大数ＭＡＸ＿ＦＥＣ＿ＰＫＴ＿ＰＥＲ＿ＦＥＣよりも大きいまたはそれと等しい（すなわち、それ以上である）とＦＥＣデコーダ４０８が判定する場合、ブロック８１２で動作が続く。ＦＥＣデコーダ４０８は、受信パケット４０２を次のフレームＦ３に属するものと識別する。具体的には、ポインタがデータ構造６０２３（ＦＥＣ＿ＲＸ＿ＤＡＴＡ３）にセットされ、ＦＥＣ復号化情報を格納するための定義された記憶場所は、次のフレームＦ３に関係する。ブロックＩｉで動作が続き、ここで動作は、図５のブロック５１６に戻る。ブロック５１６で、ＦＥＣデコーダ４０８は、ポインタを使用して、パケット４０２のデータ部分に数学演算を実行する際に使用される記憶場所（たとえば、ｆｅｃ＿ｓｔｒ３）を有するデータ構造（たとえば、ＦＥＣ＿ＲＸ＿ＤＡＴＡ３）を識別する。
【００３４】
ブロック８０４で、受信パケット４０２がＦＥＣパケットである（すなわち、ペイロード・タイプ記述子ＰＴが所定の値ＦＥＣ＿ＴＹＰＥに等しい）とＦＥＣデコーダ４０８が判定する場合、ブロック８１６で動作が続く。ブロック８１６で、パケット４０２のマスク・フィールドおよびｓｎベース・フィールドを使用して、パケット４０２が、どのフレーム（たとえば、前のフレームＦ１、現在のフレームＦ２、または次のフレームＦ３）に属するのかを判定する。次いで、ブロック８１８で、ＦＥＣキャッシュ４１０内の適切なデータ構造（ＦＥＣ＿ＲＸ＿ＤＡＴＡ１、ＦＥＣ＿ＲＸ＿ＤＡＴＡ２、またはＦＥＣ＿ＲＸ＿ＤＡＴＡ３）内のｆｅｃ＿ｒｅｃ記憶場所にパケット４０２が格納され、ブロック８２０で、図５のブロック５１８に動作が戻る。
【００３５】
図９は、図４に示した受信機４００のより詳細なブロック図である。ＦＥＣデコーダ４０８は、英国ケンブリッジにあるＡＲＭ  Ｈｏｌｄｉｎｇｓ  ｐｌｃから入手可能なコア設計に基づく、ＡＲＭ１１７６Ｊ−Ｓプロセッサなどの縮小命令セットコンピューティング（ＲＩＳＣ）プロセッサとして実装されることが好ましい。ＲＩＳＣプロセッサは、少なくとも２５０ＭＨｚの速度で動作することが好ましい。
【００３６】
パケット・バッファ４０４およびＦＥＣキャッシュ４１０は、ＲＩＳＣプロセッサ内の６４ＫＢのデータ密結合メモリ（Ｄ−ＴＣＭ）９１０内に実装されることが好ましい。ＲＩＳＣプロセッサはまた、８ＫＢのデータ・キャッシュ（Ｄ−キャッシュ）、８ＫＢの命令キャッシュ（Ｉ−キャッシュ）、および６４ＫＢの命令密結合メモリ（Ｉ−ＴＣＭ）を備えてもよい。
【００３７】
図９に示すように、再生バッファ４０６およびＦＥＣデコーダ４０８は、６４ビットのアドバンスト・エクステンシブル・インタフェース（ＡＸＩ）ベースのバス・マトリックス９１４を介して接続されている。再生バッファ４０６は、（ｉ）データ転送速度が毎秒５億３３００万回であり、（ｉｉ）「ＤＤＲ２  ＳＤＲＡＭ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」と題するＪＥＤＥＣ規格番号ＪＥＳＤ７９−２Ｅに準拠し、（ｉｉｉ）「ｘ１６」構成で実装される（すなわち、ＤＤＲ２−５３３  ｘ１６メモリ）、外部のダブル・データ・レート（ＤＤＲ）シンクロナス・ダイナミック・ランダム・アクセス・メモリ（ＳＤＲＡＭ）であることが好ましい。再生バッファ４０６は、ＤＤＲ２外部メモリ・インターフェース（ＥＭＩ）９３８を介して、バス・マトリックス９１４に接続される。
【００３８】
受信機４００はまた、ＦＥＣデコーダ４０８が使用するための、２５６ＫＢの汎用ＳＲＡＭメモリ（「ＰＰＢＭＥＭ」）９１２を備える。
【００３９】
受信機４００はまた、イーサネットをサポートするための、媒体アクセス制御装置（ＭＡＣ）９２４、９３０を備える。ＭＡＣ９２４、９３０は、パケット分類エンジン（ＰＣＥ）コプロセッサ９２０、９２８および送信ＭＡＣ  ＤＭＡ（ＴＸＤ）コプロセッサを介して、バス・マトリックス９１４に接続される。ＰＣＥコプロセッサ９２０、９２８は、Ｌ２／Ｌ３／Ｌ４のＩＰおよびＵＤＰのパケット分類、ならびにＭＡＣ９２４、９３０と受信パケット用のパケット・バッファ４０４との間での直接メモリアクセス（ＤＭＡ）のサポートを実現する。ＴＸＤコプロセッサ９２２、９２６は、ＭＡＣ９２４、９３０と送信パケット用の送信メモリ（図示せず）との間でのＤＭＡのサポートを実現する。４８ＫＢの汎用ＳＲＡＭメモリ９０２も、ＰＣＥコプロセッサ９２０、９２８用に設けられて、たとえば、インターネット・プロトコル・バージョン６（ＩＰｖ６）をサポートするための表を格納する。
【００４０】
受信機４００はまた、（外部メモリ・インターフェース９３８を介して）再生バッファ４０６に対してＤＭＡをサポートするＤＭＡ制御装置９３２を備える。
【００４１】
ＦＥＣデコーダ４０８はまた、（ｉ）ＡＸＩ／ＡＰＢブリッジ９１６を介して接続されたアドバンスト・ペリフェラル・バス（ＡＰＢ）９１８を介してＭＡＣ９２４、９３０およびＰＣＥコプロセッサ９２０、９２８と通信し、また（ｉｉ）ＡＸＩ／ＡＨＢブリッジ９３４を介して接続されたアドバンスト・ハイパフォーマンス・バス（ＡＨＢ）９３６を介してＤＭＡ制御装置９３２およびＤＤＲ２外部メモリ・インターフェース９３８と通信することが好ましい。
【００４２】
１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）（図示せず）もまた、バス・マトリックス９１４に接続して、再生バッファ４０６内に格納されたメディア・パケットを復号化してもよい。
【００４３】
このように、複数のデータ・パケットおよび誤り訂正パケットを有するメディア・フレームを受信するための、新規で革新的なシステムおよび方法を説明してきた。図４に示す前述の受信機４００において、ＦＥＣデコーダ４０８は、対応するメディア・フレーム内に残っているパケットのすべてまたはほとんどを受信するまで遅延することなく、ただちに各受信パケットに数学演算（たとえば、ＸＯＲ論理演算）を実行することに留意してもよい。対照的に、図１に示す従来の受信機１００においては、ＦＥＣデコーダ１０８は、バッファリングされたフレームがＦＥＣ復号化可能であると判定されるまで（たとえば、このフレームにおけるＦＥＣパケットおよび１つのデータ・パケットを除くすべてのデータ・パケットが受信されるまで）、いかなる数学演算の実行をも遅延する。したがって、ＦＥＣデコーダ４０８は、従来のＦＥＣデコーダ１０８よりも、待ち時間が著しく少ない。さらに、ＦＥＣデコーダ４０８は、各受信パケットにただちに数学演算を実行するので、パケット・バッファ４０４が、各フレームのほとんどすべてのパケットを格納することができる必要はない。その結果、パケット・バッファ４０４は、図１のパケット・バッファ１０４よりも、サイズをはるかに小さくすることができる。
【００４４】
本発明は、（ＡＳＩＣまたはＦＰＧＡなどの）単一の集積回路、マルチチップ・モジュール、単一カード、またはマルチカード回路パックのような実現可能な実装形態を含め、オールデジタル、オールアナログ、またはアナログ回路とデジタル回路両方をベースにするプロセスのハイブリッドとして実施してもよい。当業者には明らかになるように、回路要素の様々な機能をも、ソフトウェア・プログラム内の処理ブロックとして実装してもよい。このようなソフトウェアは、たとえば、デジタル信号プロセッサ、マイクロコントローラ、または汎用コンピュータで利用してもよい。
【００４５】
本発明の本質を説明するために説明し図示してきた各部品の詳細、材料、および構成には、以下の特許請求の範囲に記載された本発明の範囲を逸脱することなく、当業者によって様々な変更を加えてもよいことがさらに理解されよう。
【００４６】
したがって、本発明は、ＸＯＲ論理演算を使用する誤り訂正に関してこれまで述べてきたが、本発明は、それに限定されるものではなく、他の論理演算（たとえば、否定排他的論理和（ＮＸＯＲ）論理演算）を使用してもよい。さらに、本発明を、論理演算以外の数学演算に基づく他の誤り訂正（ＥＣ）アルゴリズムを使用して実施してもよいのは、このようなＥＣアルゴリズムにより、遅延することなく、たとえば、ＥＣ処理が開始される前に、フレーム内のすべてのまたは実質的にすべてのパケットが存在する必要もなく、ＦＥＣ処理を各受信パケットについて行うことができる場合である。
【００４７】
さらに、本発明は、特定の長さおよび量に関してこれまで述べてきたが、本発明は、それに限定されるものではなく、他の長さおよび量を使用してもよい。たとえば、ＦＥＣデコーダ４０８およびパケット・バッファ４０４が扱うように設計されているフレームの数、ならびにＦＥＣキャッシュ４１０内の記憶場所の数は、パケットベースのネットワーク内のパケット・ジッタ、および／またはＦＥＣデコーダ４０８の待ち時間に基づいて増減させてもよい。たとえば、本発明の一実施形態では、前述の３フレーム・パケット・バッファではなく、２フレーム・パケット・バッファを利用してもよい。このような実施形態では、前述の３つではなく、２つのデータ構造６０２１、６０２２のみがＦＥＣキャッシュ４１０内で必要となる。
【００４８】
他の実施形態では、ネットワークのパケット・ジッタが非常に小さい場合、１フレーム・パケット・バッファを利用してもよく、ＦＥＣキャッシュ４１０は、単一のデータ構造６０２１を含んでもよく、またそれから構成されてもよい。一方で、パケット・ジッタが大きい場合、ＦＥＣデコーダ４０８およびパケット・バッファ４０４は、４つ（以上）のフレームを扱うように設計してもよく、対応する数のデータ構造がＦＥＣキャッシュ４１０内に必要となるはずである。たとえば、パケット・ジッタが、前述の受信機１００の場合と同様に大きい場合（パケット・バッファ１０４が１２フレームを格納することができるように設計された場合）、ＦＥＣデコーダ４０８およびパケット・バッファ４０４もまた、ＦＥＣキャッシュ４１０内の１２のデータ構造を使用する場合には、１２フレームを扱うように設計してもよいことが予想される。
【００４９】
本明細書で説明した例示的な方法の各ステップは、必ずしも説明した順序で実行する必要はなく、このような方法のステップの順序は、単に例示的なものと理解すべきであることも理解されたい。同様に、本発明の様々な実施形態に合致する方法においては、このような方法に追加のステップを含んでもよく、また何らかのステップを割愛してもよく、または組み合わせてもよい。
【図１】
2011055500.tif 000005
【図２】
2011055500.tif 000006
【図３】
2011055500.tif 000007
【図４】
2011055500.tif 000008
【図５】
2011055500.tif 000009
【図６】
2011055500.tif 000010
【図７】
2011055500.tif 000011
【図８】
2011055500.tif 000012
【図９】
2011055500.tif 000013