JP2014505450A - フレキシブルなソースブロックのマッピングを伴う伸縮性符号を使用した符号化および復号 - Google Patents

Abstract

ソースシンボルをベースブロックに割り当て、ベースブロックをソースブロックに割り当て、各ソースブロックを符号化シンボルに符号化することによって、データを符号化することができ、この場合、少なくとも一対のソースブロックは、対の両方のソースブロックと共通する少なくとも1つのベースブロック、および対の他方のソースブロックと共通しない少なくとも1つのベースブロックを有するようになる。あるソースブロックの符号化は、他のソースブロックの内容と無関係であり得る。元のソースシンボルを有する所望のセットをすべてリカバリするために復号することを、複数のソースブロックからの符号化シンボルを有するセットから行うことができ、この場合、第1のソースブロックからの符号化シンボルの量は、第1のソースブロックにおけるソースデータの量を下回り、第2のソースブロックについても同様である。

Description

相互参照
本特許出願は、各々が本明細書と同時に出願された、本出願の譲受人に譲渡され、参照により本明細書に明確に組み込まれる以下の同時係属米国特許出願に関する。

代理人整理番号第092888U1号を有するMark Watsonらによる「Framing for an Improved Radio Link Protocol Including FEC」と題する米国特許出願、および
代理人整理番号第092888U2号を有するMichael G.Lubyらによる「Forward Error Correction Scheduling for an Improved Radio Link Protocol」と題する米国特許出願。

以下の発行された特許は、すべての目的のために参照により本明細書に明確に組み込まれる。

2005年6月21日に発行されたShokrollahiらに対する「Systematic Encoding and Decoding of Chain Reaction Codes」と題する米国特許第6,909,383号(以下「Shokrollahi-Systematic」)、および
2005年2月15日に発行されたShokrollahiらに対する「Systems and Processes for Decoding Chain Reaction Codes Through Inactivation」と題する米国特許第6,856,263号(以下「Shokrollahi-Inactivation」)。

本開示は、一般に、喪失および/または誤りが予想される中、時間的かつ/または空間的にチャネルを通じて送信するデータを符号化し、当該データを復号するための方法、回路、装置およびコンピュータプログラムコードに関し、より詳細には、他のソースブロックと部分的または全体的に重複し得るソースブロックを使用してデータを符号化するための方法、回路、装置およびコンピュータプログラムコードに関する。

通信チャネルを通じた送信側と受信側との間でのファイルの送信は、多くの文献の主題となっている。好ましくは、受信側は、送信側によってチャネルを通じて送信されたデータの完璧なコピーを、あるレベルの確かさで受信することを望む。チャネルの忠実度が完全ではない場合(ほとんどすべての物理的に実現可能なシステムが該当する)、1つの問題は、送信中に消失したか歪められたデータをどのように扱うかということである。消失したデータ(喪失)は、破損したデータ(誤り)よりも扱いが容易であることが多い。それは、破損したデータが誤って受信されたデータであると、受信側が常に見分けることはできないからである。多くの誤り訂正符号が、喪失および/または誤りを訂正するために開発されてきた。通常、使用される具体的な符号は、データの送信に使われるチャネルの非忠実度、および送信されたデータの性質についての何らかの情報に基づいて、選択される。たとえば、チャネルの非忠実である期間が長いとわかっている場合、そのような用途にはバースト誤り符号が最適であり得る。短く頻繁ではない誤りしか予想されない場合には、単純なパリティ符号が最善であり得る。

特定の適用例では、2つ以上のサービスレベルを扱う必要がある。たとえば、放送事業者は、2つのサービスレベルをブロードキャストすることがあり、この場合、ただ1つのレベルを受信することが可能なデバイスは許容可能なデータセットを受信し、第1のレベルおよび第2のレベルを受信することが可能なデバイスは第2のレベルを使用して、第1のレベルのデータを改善する。これの一例はFMラジオであり、この場合、モノラル信号を受信するだけであるデバイスもあれば、モノラル信号およびステレオ信号を受信するデバイスもある。この方式の1つの特性は、上位レイヤは通常、下位レイヤがなければ有用ではないことである。たとえば、ラジオが二次的なステレオ信号を受信したが、ベース信号を受信していない場合、それは特に有用であるとは認められない一方、これと反対のことが生じ、一次レベルが受信されたが、二次レベルが受信されていない場合、少なくともある程度有用な信号が提供され得る。このために、一次レベルは二次レベルよりも保護に値すると考えられることが多い。FMラジオの例では、一次信号は、より頑強になるように、二次信号の場合よりもベースバンドに近接して送られる。

同様の概念がデータトランスポートおよびブロードキャストシステムに存在し、この場合、データトランスポートの第1のレベルが基本信号に対するものであり、第2のレベルが拡張レイヤに対するものである。一例としてH.264Scalable Video Coding(SVC)があり、拡張レイヤとともにH.264ベース準拠ストリームが送られる。一例として、1メガビット/秒(mbps)のベースレイヤおよび1mbpsの拡張レイヤがある。一般に、受信機がベースレイヤのすべてを復号することができる場合、受信機は有用な出力を提供することができ、受信機が拡張レイヤのすべてを復号するができる場合、受信機は改善された出力を提供することができるが、受信機がベースレイヤのすべてを復号することはできない場合、拡張レイヤを復号しても、通常は何ら有用なものはもたらされない。

送信されたデータをリカバリする受信機の能力を高めるために、前方向誤り訂正(「FEC」)が使われることが多い。FECにより、送信機、または送信機のために動作する何らかの演算、モジュールもしくはデバイスは、送信されるデータを符号化し、それにより受信機は、喪失および/または誤りが存在する場合でも、送信された符号化データから元のデータをリカバリすることができる。

1つのレイヤの消失の影響が別のレイヤの場合と異なるので、レイヤごとに異なるコーディングが使用されることがある。たとえば、ベースレイヤのデータが、ベースレイヤにおけるデータのFECコーディングを表す追加データとともに送信され、次いで拡張レイヤのデータが、ベースレイヤおよび拡張レイヤにおけるデータのFECコーディングを表す追加データとともに送信され得る。この手法では、後者のFECコーディングは、受信機においてベースレイヤが正常に復号され得ることをさらに保証することができる。

そのような階層化された手法はいくつかの適用例では有用であることもあるが、他の適用例では非常に限定的であり得る。たとえば、上記の手法は、レイヤのうちの1つから生成されたいくつかの符号化シンボルおよび2つ以上のレイヤの組合せから生成された他の符号化シンボルを使用する2つ以上のレイヤの結合の効果的復号には非実用的であり得る。

米国特許第6,307,487号 米国特許第7,068,729号

ソースシンボルをベースブロックに割り当て、ベースブロックをソースブロックに割り当て、各ソースブロックを符号化シンボルに符号化することによって、データを符号化することができ、この場合、少なくとも一対のソースブロックは、対の両方のソースブロックと共通する少なくとも1つのベースブロック、および対の他方のソースブロックと共通しない少なくとも1つのベースブロックを有するようになる。あるソースブロックの符号化は、他のソースブロックの内容と無関係であり得る。元のソースシンボルを有する所望のセットをすべてリカバリするために復号することを、複数のソースブロックからの符号化シンボルを有するセットから行うことができ、この場合、第1のソースブロックからの符号化シンボルの量は、第1のソースブロックにおけるソースデータの量を下回り、第2のソースブロックについても同様である。

特定の実施形態では、エンコーダは、ソースシンボルを符号化シンボルに符号化することができ、デコーダは、適切な数の符号化シンボルからそれらのソースシンボルを復号することができる。各ソースブロックからの符号化シンボルの数は、当該ソースブロックにおけるソースシンボルの数よりも少なくてよく、それでも完全な復号が可能であり得る。

第1のソースブロックが第1のベースブロックを含み、第2のソースブロックが第1のベースブロックおよび第2のベースブロックを含むより具体的な実施形態では、デコーダは、第1のソースブロックからの符号化シンボルを有するセットおよび第2のソースブロックからの符号化シンボルを有するセットから第1のベースブロックおよび第2のベースブロックをすべてリカバリすることができ、この場合、第1のソースブロックからの符号化シンボルの量は、第1のソースブロックにおけるソースデータの量を下回り、第2のソースブロックについても同様であり、復号プロセスにおけるシンボル演算の数は、第2のソースブロックにおけるソースシンボルの数の平方よりもかなり少ない。

本発明の態様による、伸縮性符号を使用する通信システムのブロック図である。 本発明の態様による、伸縮性符号を使用する受信機の一部として使用されるデコーダの一例のブロック図である。 図1に示すエンコーダまたはエンコーダアレイにおける1つのエンコーダユニットであり得るエンコーダをより詳細に示す図である。 伸縮性符号によるソースブロックマッピングの一例を示す図である。 プレフィックス符号およびG=4である伸縮性符号を示す図である。 修復シンボルのブロックによる演算を示す図である。

付録Aとして添付されているのは、喪失チャネルに関するSlepian-Wolfタイプの問題を提示する文書であり、これはエンコーダ/デコーダシステムの特定の実施形態を伴い、使用される本発明の詳細を時々示しており、いくつかの実際の適用例、たとえばストリーミングにおけるいくつかの特別なケースおよび代替解も含む。付録Aで説明する特定の実施形態は本発明の限定的な例ではないこと、および本発明の態様のうち、付録Aの教示を使用する態様もあれば、使用しない態様もあることを理解されたい。付録Aにおける限定的な記述は特定の実施形態の要件に対する限定であることがあり、そのような限定的な記述は特許請求される発明に関係することも関係しないこともあり、したがって特許請求の文言はそのような限定的な記述によって限定される必要はないことも理解されたい。

理解を容易にするために、図に共通する同じ要素を区別するために必要に応じてサフィックスが追加される場合を除いて、そのような要素を示すために可能な場合には同じ参照番号が使用されている。図面における画像は、説明の目的で簡略化されており、必ずしも一定の縮尺で図示されているとは限らない。

添付の図面は、本開示の例示的な構成を示しており、したがって、他の同等に効果的な構成を認め得る本開示の範囲を限定するものと考えるべきではない。相応して、いくつかの構成の特徴は、さらなる説明なしに他の構成に有利に組み込まれ得ることが企図されている。

本発明は、送信される特定のタイプのデータに限定されない。しかしながら、本明細書の例では、送信され得るデータは一連の1つまたは複数のソースシンボルによって表されると仮定され、各ソースシンボルは時々ビットで測られる特定のサイズを有すると仮定される。必要条件ではないが、これらの例では、ソースシンボルのサイズは符号化シンボルのサイズでもある。シンボルが実際にビットストリームへと分解されるかどうかにかかわらず、シンボルの「サイズ」はビットで測ることができ、シンボルが2^M個のシンボルのアルファベットから選択される場合、シンボルのサイズはMビットである。

本明細書で使用する用語では、伝達されるデータはソースシンボルの数によって表され、その数を表すためにKが使用される。場合によっては、Kは事前に知られている。たとえば、伝達されるデータが、未知のサイズを有するファイルであり、そのサイズがソースシンボルのサイズの整数倍であるとき、Kは単にその倍数の整数である。一方、Kが送信前に知られていない場合や、送信がすでに開始された後まで知られていない場合もある。たとえば、送信機がデータストリームを送信しているとき、送信機はデータを受信し、データストリームがいつ終了し得るかを示す指示を有さないことがある。

エンコーダは、ソースシンボルに基づいて符号化シンボルを生成する。ここでは、符号化シンボルの数をNと呼ぶことが多い。KによりNが固定される場合、符号化プロセスは符号レートr=K/Nを有する。情報理論によれば、すべてのソースシンボル値が同等に見込まれる場合、K個のソースシンボルを完全にリカバリするには、少なくともK個の符号化シンボルを受信する必要があり(ソースシンボルおよび符号化シンボルのサイズが同じであると仮定した場合)、それによってK個のソースシンボルをすべてリカバリすることができる。したがって、FECを使用した符号レートは通常、1未満である。多くの場合、符号レートが低くなると冗長性が増し、ひいては信頼性が増すが、その代償として帯域幅が低下し、場合によっては計算作業が増大する。符号化シンボル1つについて、いくつかの符号は他の符号よりも多くの計算を必要とし、多くの適用例において、符号化および/または復号の計算コストは、有用な実装形態と扱いにくい実装形態との差を意味する。

各ソースシンボルは、値および送信されるデータ内における位置を有し、送信機および/もしくは受信機、コンピュータ可読メモリまたは他の電子ストレージの中の様々な場所に記憶されてよく、特定のソースシンボルの値の表現が内包される。同様に、各符号化シンボルは値およびインデックスを有し、後者はある符号化シンボルを別の符号化シンボルから区別するためのものであり、各符号化シンボルはまた、コンピュータ可読形態または電子的可読形態で表され得る。したがって、しばしばシンボルおよびその物理的表現が説明において互換的に使用され得ることを理解されたい。

システマティックエンコーダでは、ソースシンボルは符号化シンボルの一部であり、ソースシンボルではない符号化シンボルは、修復シンボルと呼ばれることがあり、その理由は、それらがデコーダにおいて、消失または誤りによるダメージを「修復」するために使用され得ること、すなわち、消失したソースシンボルのリカバリを支援し得ることにある。使用される符号に応じて、ソースシンボルは、すべて修復シンボルであるか、一部がソースシンボルで一部が修復シンボルであり得る受信符号化シンボルから完全にリカバリすることができる。非システマティックエンコーダでは、符号化シンボルはソースシンボルの一部を含み得るが、符号化シンボルのすべてが修復シンボルであることもある。システマティックエンコーダおよび非システマティックエンコーダに別個の専門用語を使用しなくてすむように、「ソースシンボル」という用語は、宛先に送信または提供されるデータを表すシンボルを指し、「符号化シンボル」という用語は、それらの符号化シンボルがソースシンボルであるか修復シンボルであるかを問わず、誤りまたは消失に直面した場合のリカバリ可能性を高めるためにエンコーダによって生成されるシンボルを指すことを理解されたい。場合によっては、ソースシンボルはエンコーダにデータを提示する前に前処理され、その場合、エンコーダへの入力は、ソースシンボルと区別するために「入力シンボル」と呼ばれることがある。デコーダが入力シンボルを復号するとき、一般に追加のステップが、一般にデコーダの最終目標であるソースシンボルに至るために必要とされる。

1つの効率的な符号として単純なパリティ検査符号があるが、その頑強さは十分でないことが多い。使用され得る別の符号として、本出願の譲受人に譲渡され、参照により本明細書に明確に組み込まれるLubyに対する米国特許第6,307,487号(以下「Luby I」)で説明される連鎖反応符号、および本出願の譲受人に譲渡され、参照により本明細書に明確に組み込まれるShokrollahiらに対する米国特許第7,068,729号(以下「Shokrollahi I」)で説明されるマルチステージ連鎖反応などのレートレス符号がある。

本明細書で使用する「ファイル」という用語は、1つまたは複数のソースに記憶され、1つまたは複数の宛先に1つの単位として供給される任意のデータを指す。したがって、ファイルサーバまたはコンピュータ記憶デバイスからの文書、画像、およびファイルはすべて、供給され得る「ファイル」の例である。ファイルは既知のサイズを有する(ハードディスクに記憶された1メガバイトの画像など)ことも、未知のサイズを有する(ストリーミングソースの出力から取られたファイルなど)こともある。どちらにしても、ファイルは一連のソースシンボルであり、各ソースシンボルはファイル内における位置および値を有する。

本明細書で使用する「ファイル」という用語は、位置の線形セットへの編成または順序付けが行われないが、データが多次元における順序付けを有し得ることを表し得る、送信される他のデータ、たとえば、平面マップデータ、または時間軸に沿って、かつ他の軸に沿って優先度に従って編成されるデータ、たとえば、階層化され、提示のために互いに依存する複数のレイヤを有するビデオストリーミングデータを指すこともある。

送信は、ファイルを供給するためにチャネルを通じて1つまたは複数の送信側から1つまたは複数の受信側にデータを送信するプロセスである。送信側は送信機と呼ばれることがあることもある。1つの送信側が完全なチャネルによって任意の数の受信側につながっている場合、データはすべて正しく受信されるので、受信データは入力ファイルの完璧なコピーであり得る。ここでは、現実世界のチャネルの多くがそうであるように、チャネルは完全ではないと仮定する。多くのチャネルの不完全性のうち、注目される2つの不完全性はデータ喪失およびデータ不完全性(これはデータ喪失の特別なケースとして扱われ得る)である。データ喪失は、チャネルがデータを消失するときか、落とすときに生じる。データ不完全性は、受信側がデータの一部がすでに通り過ぎた状態になるまでデータの受信を開始しないとき、受信側が伝送終了前にデータの受信を停止したとき、受信側が伝送データの一部分のみを受信することを選択したとき、および/または受信側がデータの受信を間欠的に停止し、再び開始したときに生じる。

パケットネットワークが使用される場合、1つもしくは複数のシンボル、または場合によってはシンボルの部分が伝送用にパケットに含まれ、各パケットは正しく受信されているか、まったく受信されていないと仮定される。伝送は、受信側および送信側が障害に直面して、受信側が結果に満足するまで互いに連絡するという点で「信頼できる」ことがあり、または受信側が送信側によって提供されたものに対処しなければならず、結果的に失敗することがあるという点で「信頼できない」ことがある。FECにより、送信機は伝送途中に消失し得る情報を補うために追加情報などを提供することによってデータを符号化し、FEC符号化は通常、誤りを実際に知る前に実行され、事前に誤りを防止しようとする。

一般に、通信チャネルは、データ伝送のために送信側と受信側とをつなぐものである。通信チャネルは、チャネルがデータを取得するとデータを送信側から受信側に移動させるリアルタイムチャネルであることがあり、または通信チャネルは、送信側から受信側への伝送途中にデータの一部または全部を記憶する記憶チャネルであることがある。後者の例は、ディスクストレージまたは他の記憶デバイスである。この例では、データを生成するプログラムまたはデバイスは、送信側として、データを記憶デバイスに送信すると考えられ得る。受信側は、記憶デバイスからデータを読み取るプログラムまたはデバイスである。送信側が記憶デバイスにデータを入れるために使用する機構、記憶デバイス自体、および受信側が記憶デバイスからデータを取得するために使用する機構は集合的にチャネルを形成する。それらの機構または記憶デバイスがデータを消失する可能性がある場合、それは通信チャネルにおけるデータ喪失として扱われる。

「喪失符号(erasure code)」は、K個のソースシンボルを有するセットを、符号化シンボルを有するより大きい(>K)セットにマップする符号であり、元のソースシンボルが符号化シンボルのいくつかの適正なサブセットからリカバリされ得るという特性がある。エンコーダは、提供されたソースシンボルから符号化シンボルを生成するように動作し、喪失符号(エンコーダはその喪失符号を提供されるか、その喪失符号を実現するようにプログラムされる)に従ってそのように動作する。喪失符号が有用である場合、元のソースシンボル(または場合によっては、完全なリカバリには至らないが、特定の用途の必要性を満たすのに十分なレベル)は、たまたま受信機/デコーダで受信された符号化シンボルのサブセットから、当該サブセットのサイズがソースシンボルのサイズ以上である場合にはリカバリが可能であり(「理想的な」符号)、または少なくともこれは、適度に高い確率で当てはまるはずである。実際には、「シンボル」は通常、バイトの集合、場合によって数百バイトであり、すべてのシンボル(ソースシンボルおよび符号化シンボル)はサイズが同じである。

「ブロック喪失符号(block erasure code)」は、ソースシンボルの特定の独立サブセット(「ブロック」)を有するセットの中の1つを各符号化シンボルにマップする喪失符号である。符号化シンボルを有するセットが1つのブロックから生成されるとき、それらの符号化シンボルは、その1つのブロックをリカバリするために互いに組み合わされて使用され得る。

ある符号化シンボルの「範囲」は、当該符号化シンボルが生成される際の元になるブロック、および当該符号化シンボルを使用し、他の符号化シンボルを組み合わせて使用して復号する対象となるブロックである。

所与の符号化シンボルの「近傍セット」は、符号化シンボルが直接依存するソースシンボルのブロック内のソースシンボルを有するセットである。近傍セットは、符号化シンボルの範囲の非常にスパースなサブセットであり得る。連鎖反応符号(たとえば、LT符号)、LDPC符号、およびマルチステージ連鎖反応符号(たとえば、Raptor符号)を含む多くのブロック喪失符号は、効率性などの理由から、符号化シンボルを生成するためにスパース技法を使用する。スパース性の測定の一例は、ブロック内のシンボル数に対する符号化シンボルが依存する近傍セット内のシンボル数の比率である。たとえば、1つのブロックが256個のソースシンボルを含み(k=256)、各符号化シンボルがそれらの256個のソースシンボルの2個と5個との間のXORである場合、比率は2/256と5/256との間になる。同様に、K=1024であり、各符号化シンボルがちょうど3個のソースシンボルの関数である(すなわち、各符号化シンボルの近傍セットがちょうど3個のメンバーを有する)場合、比率は3/1024である。

Raptor符号のようないくつかの符号の場合、符号化シンボルは、ブロックのソースシンボルから直接生成されず、代わりに他の中間シンボルから生成され、かかる中間シンボル自体は、ブロックのソースシンボルから生成される。いずれの場合も、Raptor符号の場合、近傍セットは、これらの符号化シンボルの(ブロック内のソースシンボルの数に等しい)範囲のサイズよりもはるかに小さいことがある。これらの場合、効率的な符号化および復号が問題であり、得られる符号構成はスパースであり、符号化シンボルの近傍セットは、その範囲よりもはるかに小さいことがあり、異なる符号化シンボルは、同じ範囲から生成されるときでも、異なる近傍セットを有し得る。

ブロック喪失符号のブロックは独立しているので、1つのブロックから生成された符号化シンボルを使用して、異なるブロックからのシンボルをリカバリすることはできず、その理由は、それらが当該他のブロックに関する情報を一切内包していないことにある。一般に、符号の設計、そのような独立ブロック喪失符号のエンコーダおよびデコーダは、符号の性質に起因して一定の方法で振る舞う。エンコーダ/デコーダが非独立ブロック(すなわち、あるブロックの範囲が別のブロックの範囲と重複し得る場合)に対応するように変更されただけである場合、重複ブロックから生成された符号化シンボルを、ブロックの集合からソースシンボルを効率的にリカバリするように使用することはできない、すなわち、復号プロセスは、重複ブロックを復号するために使用されるときの符号化シンボルの小さい近傍セットの効率的使用に対応しない。結果として、重複ブロックの復号に適用されるときのブロック喪失符号の復号効率は、設計目的、すなわち、独立ブロックの復号に適用されるときのこれらの符号の復号効率よりもはるかに悪い。

「システマティック符号(systematic code)」は、符号化シンボルを有するセットがソースシンボル自体を内包する符号である。この文脈では、区別はソースシンボルと「修復シンボル(repair symbol)」との間で行われることがあり、後者は、ソースシンボルとマッチングする符号化シンボル以外の符号化シンボルを指す。システマティック符号が使用され、符号化シンボルのすべてが正しく受信された場合、余剰分(修復シンボル)は受信機で必要とされないが、いくつかのソースシンボルが伝送途中で消失または喪失した場合、修復シンボルを使用してそのような状況を修復し、それにより、デコーダは紛失したソースシンボルをリカバリすることができる。符号化シンボルが修復シンボルを含み、ソースシンボルが直接的には符号化シンボルの一部ではない場合、符号は「非システマティック」と考えられる。

これらの定義を念頭に、次に様々な実施形態について説明する。

伸縮性符号(Elastic Code)のためのエンコーダ/デコーダの概要
エンコーダでは、符号化シンボルがソースシンボル、入力パラメータ、符号化ルールおよび場合によっては他の考慮事項から生成される。本明細書で説明するブロックベースの符号化の例では、符号化シンボルが依存し得るソースシンボルを有するこのセットは「ソースブロック」と呼ばれ、または代替的に符号化シンボルの「範囲」と呼ばれる。エンコーダはブロックベースであるので、所与の符号化シンボルは、1つのソースブロック内のソースシンボル(および場合によっては他の詳細)にのみ依存し、または代替的にその範囲内のソースシンボルにのみ依存し、そのソースブロックまたは範囲の外にあるソースシンボルには依存しない。

ブロック喪失符号は効率的な符号化および効率的な復号を可能にするうえで有用である。たとえば、受信機が所与のソースブロックのソースシンボルをすべて正常にリカバリすると、受信機はそのソースブロック内のソースシンボルに関して符号化するすべての他の受信符号化シンボルの処理を停止し、代わりに他のソースブロックの符号化シンボルに焦点を当てることができる。

単純なブロック喪失エンコーダでは、ソースデータは固定サイズの連続する非重複ソースブロックに分割され得る、すなわち、各ソースブロックは同じ数のソースシンボルを有し、ソースブロックのレンジ内にあるソースシンボルはすべて、ソースデータ内のロケーションにおいて隣接しており、各ソースシンボルは厳密に1つのソースブロックに属する。ただし、用途によっては、そのような制約はパフォーマンスを低下させ、頑強さを低下させ、かつ/または符号化および/もしくは復号の計算作業を増大させることがある。

伸縮性喪失符号は、いくつかの点でブロック喪失符号とは異なる。第一に、伸縮性喪失符号エンコーダおよびデコーダは、重複するブロックの集合に直面したときに、より効率的に動作する。本明細書で説明する伸縮性喪失符号方法のいくつかでは、生成される符号化シンボルがスパースであり、すなわち、それらの近傍セットが、それらの範囲のサイズよりもはるかに小さく、重複する範囲(ブロック)の組合せから生成された符号化シンボルが、当該範囲の集合を復号するために使用されるとき、対応するデコーダプロセスは効率的である(復号プロセスにおいて符号化シンボルのスパース性を活用し、復号するためのシンボル演算の数は、高次の連立方程式を解くのに必要なシンボル演算の数よりもかなり少ない)とともに、受信オーバーヘッドが小さい(範囲の集合をリカバリするのに必要な符号化シンボルの数は、範囲の集合のサイズに等しいか、範囲の集合のサイズをそれほど上回らない)。たとえば、各符号化シンボルの近傍セットのサイズは、それがK個のソースシンボルを有するブロックから生成されるとき、すなわち、それが範囲Kを有するとき、Kの平方根であり得る。その場合、2つの重複するブロックの集合をそれらの2つのブロックから生成された符号化シンボルからリカバリするのに必要なシンボル演算の数は、K'(2つのブロックの集合はK'個のソースシンボルを含む)の平方よりもはるかに少ないことがある。

本明細書で説明する伸縮性喪失コーディングでは、ソースブロックは、サイズが固定である必要はなく、場合によっては隣接しないロケーションを含めることができるとともに、所与のソースシンボルが2つ以上のソースブロックによって「エンベロープされる」ようにソースブロックが重複することを許容できる。

以下で説明するエンコーダの実施形態では、符号化されるデータは順序付き複数のソースシンボルであり、エンコーダは、各ソースシンボルが1つのベースブロックによってカバーされるようなソースシンボルを表す「ベースブロック」を決定するか、または当該ベースブロックの決定、当該ベースブロックの境界を取得し、1つのソースブロックが1つまたは複数のベースブロック(およびそれらのベースブロック内のソースシンボル)をエンベロープする場合のソースブロックの決定および境界を取得する。各ソースブロックが厳密に1つのベースブロックをエンベロープする場合、結果は従来型のブロックエンコーダと似たものになる。しかしながら、コーディングにはいくつかの有用で予想外の利点があり、その場合、ソースブロックが互いに重複可能であることから、いくつかのベースブロックが2つ以上のソースブロックに存在し得ることにより、2つのソースブロックがそれらのインターセクションにおいて少なくとも1つのベースブロックを有し、2つのソースブロックの集合が、いずれか一方のソースブロックにあるソースシンボルよりも多くのソースシンボルを含む。

符号化により、一対のソースブロックの集合によって表されるソースデータの部分が、対の第1のソースブロックから生成された符号化シンボルを有する第1のセットと、対の第2のソースブロックから生成された符号化シンボルを有する第2のセットとの組合せからリカバリが可能である場合、より単純な符号化プロセスが使用される場合に求められていることがあるより少ない受信シンボルを使用して復号することが可能であり得る。この符号化プロセスでは、得られる符号化シンボルは、場合によっては、2つ以上のソースブロックのソースシンボルを効率的にリカバリするために組み合わせて使用され得る。

これがそうである理由を以下で説明するが、最初に、実装形態の例について説明する。これらの実装形態は、ハードウェア、プロセッサまたはコンピュータによって実行されるプログラムコード、汎用コンピュータで動作するソフトウェアなどで行われ得ることを理解されたい。

伸縮性符号の理想的なリカバリ特性
ブロック符号にとって、理想的なリカバリは、ブロックのK個のソースシンボルを、ブロックから生成されたK個の符号化シンボルを有する任意の受信セットからリカバリする能力を意味する。この理想的なリカバリ特性を有するブロック符号があることがよく知られている。たとえば、喪失符号として使用されるリードソロモン符号は、この理想的なリカバリ特性を示している。

同様の理想的なリカバリ特性が伸縮性符号のために定義され得る。伸縮性符号通信システムが設計され、それにより、受信機が符号化シンボルを有する何らかのセットを受信し(この場合にチャネルが符号化シンボルのうちのいくつかの消失を招いていることがあり、そのためエンコーダにおいて正確なセットを指定できないことがある)、受信機が元のソースシンボルのすべてをリカバリしようとし、この場合にエンコーダにおいて、重複する範囲を有するセットから符号化シンボルが生成されると仮定する。重複する範囲により、受信符号化シンボルは、重複するソースシンボルを有する複数のソースブロックから生成され、この場合に各受信符号化シンボルの範囲はソースブロックのうちの1つである。言い換えれば、符号化シンボルはT個のブロック(範囲)b₁、b₂、…、b_Tを有するセットから生成され、各符号化シンボルはT個のブロック(範囲)のうちの厳密に1つから生成される。

この文脈では、以下が成り立つ場合に、1≦S≦Tとなるような任意のSについて、{1, …, T}のすべてのサブセット{i₁, …, i_S}について、受信符号化シンボルのサブセットEからT個のブロックを有するセットをリカバリする能力として、伸縮性喪失符号の理想的なリカバリ特性について説明されることがある。1≦s≦Sとなるようなすべてのsについて、{i₁, …, i_S}ののすべてのサブセット{i₁', …, i_s'}について、

のうちのいずれかから生成されたEにおけるシンボルの数は、最大でも、

の集合のサイズであり、

のうちのいずれかから生成されたEにおけるシンボルの数は、

の集合のサイズに等しい。Eは受信符号化シンボルのサブセットであってよいこと、すなわち、ブロック(範囲)を有する特定のセットがリカバリが可能であるかどうかを確認するためにこの理想的なリカバリの定義を評価するときに、いくつかの受信符号化シンボルは考慮されないことがあることに留意されたい。

理想的には、ブロック(範囲)を有するセットのリカバリは、計算上効率的であるべきであり、たとえば、復号プロセスが使用するシンボル演算の数は、二次方程式などとは異なり、リカバリの範囲の集合におけるソースシンボルの数に線形的に比例し得る。

本明細書における説明の一部は、伸縮性喪失符号の符号化、処理、復号などのための方法およびプロセスについて記述することがあり、これらが上記の理想的なリカバリ特性を実現する場合もあるが、伸縮性符号の理想的なリカバリおよび効率性の特性の近似のみが実現される場合もあり、それでもなお、伸縮性喪失符号の符号化、処理、復号などの定義内に入ると考えられることに留意されたい。

システムの概要
図1は、伸縮性符号を使用する通信システム100のブロック図である。

システム100において、伸縮性符号ブロックマッパー(「マッパー」)110は、ソースブロックに対するベースブロックのマッピングのほか、場合によってはベースブロックの境界も生成する。図1に示すように、通信システム100は、マッパー110、ソースブロックマッピング用のストレージ115、エンコーダアレイまたはエンコーダ120、符号化シンボル用のストレージ125、および送信機モジュール130を含む。

マッパー110は、様々な入力および場合によってはそこに表されるルールセットから、どのソースブロックがどのベースブロックに対応するかを判断し、対応をストレージ115に記憶する。これが確定的かつ反復可能なプロセスである場合、このマッピングを取得するために同じプロセスをデコーダにおいて実行することができるが、ランダムであるか、完全に確定的ではない場合、デコーダがマッピングを判断できるように、マッピングがどのように生じるかに関する情報を宛先に送ることができる。

図示のように、マッパー110の動作を制御するためにこの実施形態において(決して網羅的であることが要求されていない)入力のセットが使用される。たとえば、いくつかの実施形態では、マッピングは、ソースシンボル自体の値、ソースシンボルの数(K)、マッパー110の内部でもっぱら生成されるのではなく入力として提供されるベースブロック構造、受信機フィードバック、データ優先度信号、または他の入力に依存し得る。

一例として、マッパー110は、マッパー110への入力として提供されるベースブロック境界を示す特定の指示に依存するエンベロープを有するソースブロックを作成するようにプログラムされ得る。

ソースブロックマッピングは受信機フィードバックにも依存し得る。これは、受信機フィードバックが送信機にとってすぐに利用可能であり、受信機がデータの正常受信を示す場合に有用であり得る。したがって、受信機は送信機に対し、受信機がi番目のシンボルまでのすべてのソースシンボルを受信しリカバリしたことをシグナリングすることがあり、マッパー110は、i番目のシンボルの前に来た完全にリカバリしたベースブロックを除外するようにソースブロックのエンベロープを変更することによって応答することがあり、これにより送信機および受信機における計算作業および/または記憶を節減することができる。

ソースブロックマッピングは、ソースブロックまたはベースブロックによって異なるデータ優先度値をマッパー110にシグナリングするデータ優先度入力に依存し得る。これの使用例は、送信機がデータを送信しており、送信されているデータが他のデータよりも優先度が低いことを示す信号を受信するケースであって、この場合、低優先度データを犠牲にして高優先度データのコーディングおよび頑強さが増大し得る。これは、マップがロードされているときにエンドユーザが「関心対象」ポイントを移し得るマップディスプレイなどのアプリケーションにおいて、またはエンドユーザがビデオシーケンスの伝送中に早送りもしくは巻き戻しを行うビデオアプリケーションにおいて有用である。

いずれの場合も、エンコーダアレイ120は、ソースシンボル値、および送信機モジュール130による最終的送信のためにストレージ125に記憶される符号化シンボルを生成するために符号化するための他のパラメータとともにソースブロックマッピングを使用する。当然のこととして、ソースシンボル値および他の入力を読み取り、記憶される符号化シンボルを生成するソフトウェアにおいて、システム100は全面的に実装され得ることを理解されたい。ソースブロックマッピングはエンコーダアレイにとって利用可能であり、符号化シンボルは、その符号化シンボルに関連するソースブロックにないソースシンボルとは無関係であり得るので、エンコーダアレイ120は、異なるソースブロックに対してそれぞれ動作する複数の独立した動作をするエンコーダを含むことができる。適用例によっては、各符号化シンボルは、それが生成された直後に、またはほぼ直後に送られ、したがって、ストレージ125が必要ないことがあり、または符号化シンボルはほんの短い時間だけ送信前にストレージ125内に記憶され得ることも理解されたい。

次に図2を参照すると、宛先において受信機の一部として使用されるデコーダの例が示されている。図2に示されているように、受信機200は受信機モジュール210、受信符号化シンボル用のストレージ220、デコーダ230、復号ソースシンボル用のストレージ235、および対応するソースブロックマッピング用ストレージ215を含む。示されていないのは、送信機から必要とされる場合にソースブロックマッピングを作成する方法に関する情報を受信するのに必要な接続である。

受信機モジュール210は、場合によっては喪失、消失および/または紛失データを含む信号を送信機から受信し、受信信号から符号化シンボルを導出し、符号化シンボルをストレージ220に記憶する。

デコーダ230は、利用可能な符号化シンボル、ストレージ215からのソースブロックマッピングを読み取って、マッピング、利用可能な符号化シンボル、およびストレージ235内の以前に復号されたシンボルに基づいて、符号化シンボルからどのシンボルが復号され得るかを判断することができる。デコーダ230の結果はストレージ235に記憶され得る。

受信符号化シンボル用のストレージ220および復号ソースシンボル用のストレージ235は、共通のメモリ要素によって実装され得ること、すなわち、デコーダ230は、復号するために使用される受信符号化シンボルと同じ記憶エリアに復号結果を保存する場合があることを理解されたい。また本開示から、とりわけ、最初に符号化シンボルが到着したときと復号データが他のアプリケーションによって使用されるときとの間に短い遅延がある場合に、符号化シンボルおよび復号ソースシンボルがランダムアクセスメモリ(RAM)またはキャッシュなどの揮発性記憶装置に記憶され得ることも理解されたい。他のアプリケーションでは、シンボルは様々なタイプのメモリに記憶される。

図3は、図1に示すエンコーダまたはエンコーダアレイにおける1つのエンコーダユニットであり得るエンコーダ300をより詳細に示している。いずれの場合も、図示のように、エンコーダ300は、ソースシンボルの値が記憶されるシンボルバッファ305を有する。図示では、K個のソースシンボルすべてが一度に記憶可能であるが、エンコーダは、ソースシンボルすべてよりも少ないソースシンボルを有するシンボルバッファでも同等に動作し得ることを理解されたい。たとえば、符号化シンボルを生成するための所与の動作が、1ソースブロックに相当するソースシンボルか、さらには1ソースブロック全体に満たないソースシンボルだけを内包するシンボルバッファで実行され得る。

シンボルセレクタ310は、シンボルバッファ305におけるソースシンボル位置の1〜Kの中から選択し、オペレータ320は、ソースシンボルに対応するオペランドに対して演算し、それにより符号化シンボルを生成する。特定の例では、シンボルセレクタ310はスパース行列を使用して、ソースブロックまたは生成される符号化シンボルの範囲からシンボルを選択し、オペレータ320は、被選択シンボルに対する演算を、当該シンボルに対するビット単位の排他的論理和(XOR)演算によって実行して、符号化シンボルをもたらす。XOR以外の他の演算も可能である。

本明細書で使用する、特定の符号化シンボル用のオペランドであるソースシンボルは、その符号化シンボルの「近隣」と呼ばれ、所与のソースシンボルに依存するすべての符号化シンボルを有するセットは、そのソースシンボルの近傍と呼ばれる。

演算がXORであるとき、符号化シンボルの近隣であるソースシンボルは、その符号化シンボルのすべての他の近隣ソースシンボルが利用可能である場合に、符号化シンボルおよび他の近隣のXOR演算を行うことによって、その符号化シンボルからリカバリされ得る。これは他のソースシンボルを復号することを可能にし得る。他の演算も同様の機能を有し得る。

近隣関係が知られている場合、符号化関係を表すソースシンボルおよび符号化シンボルのグラフが存在する。

伸縮性符号の詳細
伸縮性符号は、ブロック符号または畳込み符号またはネットワーク符号と比べて多くの利点を有し、符号化中に受信されたフィードバックに基づいて変更するようにコーディングされる内容に容易に対応する。多くの適用場面において、たとえばデータのストリーミングのときに、時間的制約を理由にデータがすべてリカバリされ得る前にあらかじめ決められた順序でデータをリカバリすることは有用であることを考慮し、チャネルの既知の誤り状態および/またはフィードバックに基づいて、符号化が進行する中でデータの様々な部分に対してコーディングすることは有利であり得るが、ブロック符号は、データのブロック全体に対してコーディングするという要件のために限定的である。

畳込み符号は、所定のパターン化された方法でデータのストリームに修復シンボルを追加すること、たとえば、所定のパターンに基づいて所定のレートでストリームに修復シンボルを追加することによって、ストリームに対して何らかの保護を提供する。畳込み符号は、任意のソースブロック構造に対応せず、ソースデータの様々な部分から様々な量の符号化シンボルを生成する柔軟性をもたらさず、畳込み符号も、リカバリ特性や符号化および復号の効率性を含め、多くの他の形で限定される。

ネットワーク符号は様々な中間受信機を通じて送信されるデータに保護を提供し、その場合、そのような各中間受信機は、受信した内容に基づいてデータを符号化し、追加の符号化データを送信する。ネットワーク符号は、ソースブロック構造を判断する柔軟性をもたらさず、ブルートフォースよりも良好な既知の効率的な符号化および復号手順がなく、ネットワーク符号も多くの他の形で限定される。

伸縮性符号は適切なレベルのデータ保護を提供すると同時に、リアルタイムストリーミング体験に対応する、すなわち、誤り状態に対して保護するために導入されたコーディングによる現在の誤り状態を踏まえたプロセス中のレイテンシをできるだけ少なくする。

説明したように、伸縮性符号は、各符号化シンボルがソースシンボルの任意のサブセットに依存し得る符号である。一般的な伸縮性符号の1つのタイプとして伸縮性コード符号があり、この場合、ソースシンボルが順に配置され、各符号化シンボルが、連続するソースシンボルを有するセットから生成される。伸縮性コード符号については、以下でより詳細に説明する。

伸縮性符号の他の実施形態は、線形符号でもある伸縮性符号である。すなわち、この場合には各符号化シンボルが、それが依存するソースシンボルの線形和であり、GF(q)線形符号が、任意の符号化シンボルの構成におけるソースシンボルの係数が有限体GF(q)の要素である線形符号である。

本明細書で説明する伸縮性符号を使用するエンコーダおよびデコーダおよび通信システムは、レイテンシおよび帯域幅オーバーヘッドを最小化する良好な均衡をもたらす。

マルチ優先度コーディングのための伸縮性符号の使用
伸縮性符号はまた、複数の部分を含むオブジェクトを供給する必要がある通信システムにおいて有用であり、それらの部分は異なる供給特性を有することがあり、その特性は静的または動的に特定される。

静的優先度の一例として、様々な部分に区分されるデータがあり、かかる様々な部分は、当該部分に依存する優先度で供給され、この場合に様々な部分は、時間または何らかの他の因果性の次元のいずれかにおいて、互いに論理的に関係または依存し得る。この場合、プロトコルは受信側から送信側へのフィードバックを有さないこと、すなわち開ループであることがある。

動的優先度の一例として、マップの様々な部分に対するエンドユーザの焦点が動的かつ予想外に変動する中で、部分的に動的にエンドユーザに対して2次元マップ情報を供給しているプロトコルがある。この場合、配信されるマップの様々な部分の優先度は、たとえば、変化するネットワーク状態、受信側の入力もしくは関心または他の入力に応答して、プロトコルの過程におけるフィードバックに基づいて把握されるにすぎない未知の先験的優先度に基づいて変動する。たとえば、エンドユーザは、現在のマップビュー内の情報ならびに個人的好みおよび/または目的に基づいて、次にマップのどの部分を閲覧するかに関して、自らの関心事項を変えることがある。マップデータは象限(quadrant)に区分されることがあり、各象限内には様々な調整レベルがあるため、各象限のレベルごとにベースブロックが存在することがあり、ソースブロックは1つまたは複数のベースブロックの集合を含むことがあり、たとえば、1つの象限内の様々な調整レベルに関連するベースブロックの集合を含むソースブロックもあれば、1つの調整レベルの隣接象限に関連するベースブロックの集合を含むソースブロックもある。これは閉ループプロトコルの一例である。

伸縮性喪失コーディングを使用するエンコーダ
本明細書で説明するエンコーダは、データの任意のサブセットに対する符号化を許容する新規コーディングを使用する。たとえば、1つの修復シンボルが、データシンボルを有する1つのセットに対して符号化することができ、一方、第2の修復シンボルが、データシンボルを有する第2のセットに対して符号化することができ、この場合、これら2つの修復シンボルが、それらの範囲のインターセクションにある2つのソースシンボルの消失からリカバリすることができ、各修復シンボルは、自身の範囲にあるが、他方の修復シンボルの範囲にはないデータシンボルからの1つのデータシンボルの消失からリカバリすることができる。伸縮性符号の1つの利点として、伸縮性符号はリカバリ能力とエンドツーエンドレイテンシとの間の伸縮性トレードオフをもたらし得る。そのような符号の別の利点としては、優先度が様々であるデータを保護するためにそのような符号を使用することができ、この場合、最高優先度データのために提供される修復のみでは最高優先度データのリカバリに十分ではないときでも、データ全体をリカバリするためにデータ全体ために提供されるデータと最高優先度データのためにのみ提供される保護とを組み合わせることができる。

これらの符号は、フィードバックがまったくない場合およびプロトコル内にフィードバックがある場合における完全なプロトコル設計において有用である。プロトコルにフィードバックがある場合、提供される保護とコーディングによる追加のレイテンシとの最良の組合せをもたらすために、符号はフィードバックに基づいて動的に変化し得る。

ブロック符号は、単一のソース範囲を有する(各ソースシンボルがたった1つのソースブロックに属する)ことによって、伸縮性符号を使用する退化したケースと考えることができる。伸縮性符号では、ソース範囲の決定は完全に柔軟に行われてよく、ソースシンボルは複数の範囲に属することができ、ソース範囲は所定の通常のパターン以外でオンザフライで決定されること、ソースデータの基底構造によって決定されること、トランスポート状況または他の要素によって決定されることがある。

図4は、下行のボックスがソースシンボルを表し、シンボルの上でくくっている線は、ソースブロックのエンベロープを一例として示している。この例では、3つのソースブロックが存在し、したがって3つの符号化ブロックが存在することになり、かかる符号化ブロックは、ソースブロックのうちの1つをそれぞれ符号化している。この例では、ソースブロックがベースブロックから作成される際には、矢印で示されているベースブロックの境界により5つのベースブロックが存在しうる。

一般に、伸縮性符号を使用するエンコーダおよびデコーダは、ソースシンボルの各々が、1つのベースブロック内にあるが、ソースシンボルの各々が、2つ以上のソースブロックまたはソース範囲において、ソースブロックの一部が重複し、少なくとも場合によっては、完全に他のソースブロックのサブセットとなるようなことはない、すなわち、いくつかのソースシンボルを共有しながらも、ソースブロックのうちの一方に現れて他方には現れないソースシンボルを各々が有する少なくとも2つのソースブロックがある、状態で行われる。ソースブロックは、修復シンボルが生成される際の元になる単位、すなわち、修復シンボルの範囲であり、それにより、1つのソースブロックに関する修復シンボルは、当該ソースブロックにないソースシンボルとは無関係であることが可能となり、その結果、別のソースブロックの符号化シンボル、受信シンボルまたは修復シンボルにアクセスすることをデコーダに要求することなく、当該ソースブロックの符号化シンボル、受信シンボルおよび/または修復シンボルを使用してソースブロックのソースシンボルを復号できるようになる。

ソースブロックの範囲のパターンは、任意であってよく、かつ/または宛先デコーダのニーズもしくは要求に依存してよい。いくつかの実装形態では、ソース範囲はオンザフライで決定されること、ソースデータの基底構造によって決定されること、トランスポート状況によって決定されること、および/または他の要素によって決定されることがある。所与のソースブロックから生成され得る修復シンボルの数は、ソースブロックごとに同じでよく、異なってもよい。所与のソースブロックから生成される修復シンボルの数は、符号レートに基づいて固定されてよく、連鎖反応符号の場合のようにソースブロックとは無関係であってもよい。

従来型のブロック符号または連鎖反応符号の場合、ソースシンボルをリカバリするために互いに組み合わせてデコーダによって使用される修復シンボルは通常、1つのソースブロックから生成されるが、本明細書で説明する伸縮性符号の場合、修復シンボルはソースデータの任意の部分から、またソースデータの重複する部分から生成可能であり、ソースブロックに対するソースシンボルのマッピングはフレキシブルであり得る。

選択される設計に関する考慮事項
伸縮性符号の設計において、効率的な符号化および復号が主たる問題となる。たとえば、理想的な効率性は、リカバリされるソースシンボルの数において線形であるいくつかのシンボル演算を使用して復号し得る伸縮性符号に見い出されることがあり、したがって、リカバリのためにブルートフォース方法よりもかなり少ないシンボル演算を使用する任意のデコーダが好ましく、一般にブルートフォース方法は、リカバリされるソースシンボルの数において二次方程式であるいくつかのシンボル演算を必要とする。

最小受信オーバーヘッドで復号することも目標であり、この場合の「受信オーバーヘッド」は、デコーダによって必要とされる分を上回るが、前述の理想的なリカバリ特性を実現するためには必要とされる余剰符号化シンボルの数として表され得る。さらに、保証されたリカバリ、または確率が高いリカバリ、または可能性が非常に高いリカバリ、または一般に信頼性が高いリカバリが好ましい。言い換えれば、適用例によっては、目標は完全なリカバリである必要はない。

伸縮性符号はいくつかの環境において有用である。たとえば階層化コーディングでは、高優先度データのブロックを保護するために、修復シンボルを有する第1のセットが提供される一方、修復シンボルを有する第2のセットが、高優先度データのブロックと低優先度データのブロックとの組合せを保護し、その結果、高優先度データブロックが別個に符号化され、低優先度データブロックが別個に符号化された場合、復号において要求されるシンボルが少なくなる。いくつかの既知の符号は階層化コーディングをもたらすが、その代償として、重複するソースブロックの集合の効率的復号を実現できないこと、および/または信頼性が高いリカバリを実現できないことが多い。

以下で説明する伸縮性ウィンドウベースの符号は、重複するソースブロックの効率的で信頼性が高い復号を同時に実現することが可能であり、階層化コーディングの場合もそれが可能である。

ネットワークコーディングとの組合せ
別の環境では、ネットワークコーディングが使用され、この場合、元のノードがソースデータの符号化を、様々な消失パターンを経験し得る中間ノードに送り、中間ノードは宛先ノードに、受信された符号化データの部分から生成された符号化データを送る。次いで宛先ノードは、複数の中間ノードから受信した符号化データを復号することによって、元のソースデータをリカバリすることができる。伸縮性符号はネットワークコーディングプロトコル内で使用でき、この場合に得られる解は、元のソースデータの効率的で信頼性が高いリカバリをもたらす。

伸縮性コード符号の単純な構成
説明のために、伸縮性コード符号の単純な構成を提供する次のような修復シンボルを有するセットをエンコーダが生成すると仮定する。この単純な構成は、必ずしも伸縮性コード符号であるとは限らない伸縮性符号を提供するように拡張可能であり、この場合、修復シンボルおよびその近傍セットまたは範囲の識別は、ここで説明する識別の拡張である。GF(256)における要素を有するm×n行列Aを生成する。i番目の行およびj番目の列における要素をA_ij、ソースシンボルをS_j(j= 0, 1, 2,…)で示す。次いで、任意の組(e, l, i)について、e、lおよびiは整数であり、e≧l>0および0≦i<mであり、修復シンボルR_e,l,iは式1に示す値を有する。

R_e,l,iを明確にするために、GF(256)の要素によるシンボルの乗算の概念およびシンボルの加算の概念を明記する必要があることに留意されたい。ここでの例では、GF(256)の要素はオクテットとして表され、各シンボルは一連のオクテットであってよく、GF(256)の一連の要素と考えられる。フィールド要素によるシンボルの乗算は、同じフィールド要素によるシンボルの各要素の乗算を伴う。シンボルの加算は単に、加算されるシンボルにおける対応するフィールド要素の和の連結から形成されるシンボルである。

所与の修復シンボルに関する式1に現れるソースシンボルを有するセットは、修復シンボルの「範囲」として知られ、それらの修復シンボルの各々に関する式1に現れる所与のソースシンボルを持つそれらの修復シンボルを有するセットは、所与のソースシンボルの「近傍」と呼ばれる。したがって、この構成では、修復シンボルの近傍セットは、修復シンボルの範囲と同じである。

そして符号の符号化シンボルは、本明細書で定義するようにソースシンボルと修復シンボルとを含む、すなわち、構成された符号はシステマティックである。

2つの異なる伸縮性符号に対応する行列Aに関する2つの代替的構成について考える。「ランダムコード符号(Random Chord Code)」の場合、Aの要素はGF(256)の非ゼロ要素から擬似ランダムに選ばれる。本明細書では全体を通して、別段に規定されていない限り、何かがランダムに選ばれるものとして説明される場合、擬似ランダム選択がその説明に含まれること、およびより一般的には、ランダム動作が擬似ランダムに実行され得ることを想定すべきであることを理解されたい。「コーシーコード符号(Cauchy Chord Code)」の場合、Aの要素は式2に示すように定義され、ここではk=255-mであり、g(x)は、オクテット表現がxである有限体要素である。

伸縮性コード符号の単純な構成を使用した符号化によるシンボルの復号
符号化シンボル自体と同様に、デコーダはシンボルごとの識別情報にアクセスすることができ、この識別情報は単にインデックスであってよい、すなわち、ソースシンボルS_jの場合、識別情報はインデックスjである。修復シンボルR_e,l,iの場合、識別情報は組(e, l, i)である。もちろん、デコーダは行列Aにアクセスすることもできる。

受信修復シンボルごとに、デコーダは識別情報を判断し、ソースシンボル値が既知である場合にはソースシンボル値を使用し、ソースシンボル値が未知である場合にはゼロシンボルを使用して、式1から当該修復シンボルの値を計算する。そのように計算された値が受信修復シンボルに追加されたとき、修復シンボルが正しく受信されたと仮定すると、結果は、修復シンボルの範囲または近傍にある残存する未知のソースシンボルの和である。

簡単のために、この説明では、少なくとも1つの受信修復シンボルの範囲にあるすべての未知のソースシンボルをリカバリしようとするようにプログラムされたデコーダがある。本開示を読めば、すべてに満たない分もしくはすべてを高い確率であるが確実ではない確率で、またはそれらの組合せをリカバリするようにデコーダを変更する方法が明らかになろう。

この例において、受信修復シンボルの範囲の集合にある未知のソースシンボルの数をtとし、これらの未知のソースシンボルのインデックスをj₀、j₁、…、j_t-1とする。受信修復シンボルの数をuとし、受信修復シンボルを(任意に)R₀、…、R_u-1として示す。

エントリーE_pqを有するu×t行列Eを構成し、ここでE_pqは、修復シンボルR_pに関する式1におけるソースシンボル

の係数であるか、または

が式に現れない場合には、ゼロである。そして、ステップ1適用後に、

が紛失ソースシンボルのベクトルであり、R=(R₀,…,R_μ-1)^Tが受信修復シンボルのベクトルである場合、式3の式は満たされる。
R=E・S (式3)

Eがランクuを有さない場合、Eのランクを変えずに除去され得るEの行が存在する。これを除去し、uを1だけ減分し、残存する修復シンボルの番号を振り直して、式3がなお成立するようにする。Eがランクuを有するまでこのステップを繰り返す。

u=tである場合、完全な復号が可能であり、Eはフルランクの正方形であるので、可逆である。Eは可逆であるので、SはE^-1Rから見い出すことができ、復号は完了する。u<tである場合、ソースシンボルのこのサブセットの追加のソースシンボルおよび/または修復シンボルの受信なしには、または何らかの他の手段によりソースシンボルに関する他の情報を得ることなしには、完全な復号は不可能である。

u<tである場合、フルランクのEのu×uサブ行列をE'とする。適切な列置換により、Eは(E'|U)と書くことができ、ここでUはu×(t-u)行列である。式3の両側にE'^-1を掛けると、式4の式を得ることができ、E^-1Rの行に対応するソースシンボルの解がもたらされ、ここでE'^-1Uはゼロである。
E^'-1・R=(I|E^'-1・U)・S (式4)

式4は、さらなる修復シンボルおよび/またはソースシンボルが受信される場合に、残存するソースシンボルのより単純なリカバリを可能にする。

ソースシンボルの他の部分のリカバリは、少なくとも1つの受信修復シンボルの範囲にあるすべての未知のソースシンボルのリカバリが可能ではないときでも、可能であり得る。たとえば、いくつかの未知のソースシンボルが少なくとも1つの受信修復シンボルの範囲にあるが、未知のソースシンボルをリカバリするのに十分な修復シンボルがない場合、または修復シンボルと未知のソースシンボルとの間の式のいくつかが線形従属である場合がある。これらの場合、少なくともソースシンボルの相対的に小さいサブセットを、ソースシンボルの相対的に小さいサブセットの中にある範囲を有する修復シンボルのみを使用してリカバリすることが可能であり得る。

伸縮性コード符号の単純な構成を使用するストリームベースのデコーダ
「ストリーム」モードの動作では、ソースシンボルはストリームを形成し、修復シンボルは、修復が生成されるときにソースシンボルのサフィックスにわたって生成される。このストリームベースのプロトコルは、上述の伸縮性コード符号の単純な構成を使用する。

デコーダにおいて、ソースシンボルおよび修復シンボルは、場合によっては何らかの並べ替えが行われて1つずつ到着し、ソースシンボルまたは修復シンボルが到着するとすぐに、デコーダは、消失したソースシンボルが復号可能であるかどうかを特定し、このソースシンボルを復号し、デコーダの出力部に供給することができる。

これを達成するために、デコーダは行列(I|E^'-1・U)を維持し、下記の手順に従って新しいソースシンボルまたは修復シンボルが受信されるたびにこれを更新する。

「復号行列」(I|E^'-1・U)をDとする。位置(i, j)における要素をD_ijとし、Dのj番目の列をD_*jとし、Dのi番目の行をD_i*とする。

下記の手順では、デコーダは復号行列に対して様々な演算を実行する。復号を実現するために修復シンボルに対して等価演算が実行される。これらは行列演算と同時に実行され得るが、いくつかの実装形態では、これらの演算は、実際のソースシンボルが下記のシンボルリカバリ手順でリカバリされるまで先送りされる。

ソースシンボルを受信すると、ソースシンボルが、紛失したソースシンボルの1つ、

である場合、デコーダはDの対応する列を除去する。除去された列が最初のu個の列のうちの1つであった場合、デコーダは、除去された列に非ゼロ要素を有する行に関連する修復シンボルを特定する。次いでデコーダは、この修復シンボルの受信のために下記の手順を繰り返す。除去された列が最初のu個の列のうちの1つではなかった場合、デコーダは下記のシンボルリカバリ手順を実行する。

修復シンボルを受信すると、最初にデコーダは、現在は未知であり、新しい修復シンボルの範囲内にあり、Dの列にまだ関連付けられていないソースシンボルごとにDに新しい列を追加する。次にデコーダは、受信修復シンボルのためにDに新しい行D_u*を追加し、この行に式1からの係数をポピュレートする。

0からu-1までのiの場合、デコーダは、D_u*を(D_u*-D_ui D_i*)に置き換える。このステップの結果、D_u*の最初のu個の要素が消去される(すなわち、ゼロになる)。この消去ステップの後でD_u*がゼロでない場合、デコーダは、(必要に応じて)列交換を実行し、それによりD_uuはゼロでなくなり、D_u*を(D_uu ^-1D_u*)に置き換える。

u-1から0までのiの場合、デコーダは、D_i* を(D_i*-D_iu D_u*)に置き換える。このステップの結果、列uの要素は行uを除いて消去される(すなわち、ゼロになる)。

行列はここでもう一度(I|E^'-1・U)の形式となり、デコーダはu:=u+1をセットすることができる。

シンボルリカバリ手順を実行するために、デコーダは、ゼロであるE'^-1Uの各行、またはE'^-1Uが空である場合にDのすべての行について考慮する。Dの当該行において列がゼロでないソースシンボルがリカバリされ得る。記憶された一連の演算を修復シンボルに対して実行することによって、リカバリが達成される。具体的には、デコーダは、行D_i*を(D_i*-αD_j*)に置き換えるときはいつでも、対応する修復シンボルR_iを(R_i-αR_i)に置き換え、行D_i*が(αD_i*)に置き換えられるときはいつでも、修復シンボルR_iをαR_iに置き換える。

これらの演算が実行される順序が重要であり、行列演算が実行された順序と同じであることに留意されたい。

演算が実行されると、ゼロであるE'^-1Uの行ごとに、対応する修復シンボルは今や、Dの当該行において列がゼロではないソースシンボルの値に等しい値を有し、したがって、シンボルはリカバリされている。次いで、この行および列はDから除去され得る。

いくつかの実装形態では、シンボル演算は、少なくとも1つのシンボルがリカバリされ得ることが特定されているときのみ実行される。シンボル演算はDのすべての行に関して実行されるが、その結果、紛失したシンボルすべてのリカバリとはならないことがある。したがってデコーダは、どの修復シンボルが「処理されて」おり、どの修復シンボルが処理されていないかを追跡し、追加の行列演算が実行される中で、処理されたシンボルを最新の状態に保つように注意する。

この「ストリーム」モードにおける伸縮性符号の特性は、依存性を過去に向けてどこまでも拡大することができ、したがって復号行列Dは恣意的に大きくなり得る。実際には、実装形態はDのサイズに制限を設けるべきである。実際の適用例では、所与のソースシンボルの供給に関する「期限」があること、すなわち、その期限の後は、シンボルが上位のプロトコルレイヤにとって有用でなくなること、または、その期限の後は、上位のレイヤが消失シンボルなしでとにかく進むように通知されることが多い。

Dの最大サイズはこの制約に基づいて設定され得る。しかしながら、伸縮性符号デコーダにとって、所与のソースシンボルがアプリケーションに今後供給されることはない場合でも、当該シンボルをリカバリするために有用であり得る情報を保持することが有利であることがある。これは、代替的に、問題のソースシンボルに依存するすべての修復シンボルが処分され、期限が到来していない異なるソースシンボルをリカバリするためにそれらの修復シンボルのうちのいくつかが使用される場合があるからである。

Dのサイズの代替的制限は、伸縮性符号デコーダに記憶される情報の総量に関係する。いくつかの実装形態では、受信ソースシンボルはサーキュラーバッファでバッファされ、供給されているシンボルは保持されるが、その理由は、後に受信された修復シンボルを解釈する(たとえば、上記の式1の値を計算する)ためにこれらが必要になり得ることにある。(バッファが一杯であるために)ソースシンボルが最終的に処分されるとき、範囲がそのシンボルを含む任意の(未処理の)修復シンボルを処分(または処理)する必要がある。このこととソースバッファのサイズとを踏まえ、場合により、範囲がすべてソースバッファ内にある受信される見込みの修復シンボルの最大数に対応できるように、行列Dのサイズを変更する必要がある。

代替実装形態では、上記の理想的なリカバリ特性に従って正常に復号する可能性があるときのみ、行列Dを構成する。

計算の複雑さ
上述した符号の計算の複雑さは、シンボル演算によって決まる。

シンボルの追加は、シンボルのビット単位の排他的論理和であり得る。これは、いくつかのプロセッサ上で、一度に64ビットまたは128ビットのデータに対してXOR演算を実行し得る幅広いレジスタ(たとえば、x86アーキテクチャによるCPU上でのSSEレジスタ)を使用することによって効率的に達成され得る。しかしながら、有限体の要素によるシンボルの乗算は、バイト単位で実行されなければならないことが多く、その理由は、プロセッサは通常、有限体の演算のためのネイティブ命令を提供せず、したがって参照用テーブルを使用しなければならないことにあり、これは、各バイトの乗算が、データの処理以外のメモリへのアクセスを含むいくつかのプロセッサ命令を必要とすることを意味する。

エンコーダにおいて、上記の式1を使用して各修復シンボルを計算する。これは、l個のシンボル乗算およびl-1個のシンボル加算を伴い、ここでlは、修復シンボルの範囲にあるソースシンボルの数である。各ソースシンボルが厳密にr個の修復シンボルによって保護される場合、全体の複雑さはO(r・k)個のシンボル演算であり、ここでkはソースシンボルの数である。代替的に、各修復シンボルがl個のソースシンボルを有する範囲または近傍セットを有する場合、生成される修復シンボル1個あたりの計算の複雑さは、O(l)個のシンボル演算である。本明細書で使用する表現O()は、通常の「およそ」を意味するものとして理解されたい。

デコーダにおいて、複雑さに対する2つの構成要素があり、それらは、受信したソースシンボルの消去、および消失したソースシンボルのリカバリである。第1の構成要素は、符号化演算、すなわちO(r・k)個のシンボル演算に相当する。第2の構成要素は、u×u行列Eの反転から生じるシンボル演算であり、ここでuは消失したソースシンボルの数であり、したがってその複雑さはO(u²)個のシンボル演算である。

消失レートが低い場合、uは小さく、したがって、すべての修復シンボルがデコーダで使用された場合、符号化および復号の複雑さは似たものとなる。しかしながら、複雑さの主要構成要素は修復シンボルの数によって増減するので、修復シンボルのすべてが使用されるのではない場合、複雑さは低下する。

上述のように、一実装形態では、修復シンボルの処理は、データがリカバリされ得ることがわかるまで先送りされる。これにより、シンボル演算は最小限に抑えられ、符号の計算上の要件も最小限に抑えられる。しかしながら、それは復号活動の突発を招く。

代替的実装形態では、(式1を使用して)受信ソースシンボルについての消去演算をシンボルの到着に伴い実行することによって、計算負荷を抑制することができる。この結果、すべての修復シンボルについての消去演算を、それらがすべて使用されてはいない場合でも実行し、その結果、計算の複雑さが高まる(ただし、安定性が増す)。これを可能にするために、デコーダは、どの修復シンボルが生成されることになるかについて、事前に情報を持っていなければならず、これはすべてのアプリケーションで可能であるとは限らない。

復号確率
あらゆる修復シンボルは、それが受信される前にその範囲にあるすべてのソースシンボルがすでにリカバリまたは受信されているために明白に冗長であること、または消失したソースシンボルをリカバリするのに有用であること、のいずれかであることが理想的である。これがどのくらいの頻度で当てはまるかは、符号の構成による。

消去ステップ後に、新しい受信修復シンボルを受けてDにゼロの行が追加されるとき、この理想からの乖離がデコーダ論理で検出され得る。そのようなシンボルはデコーダに新しい情報をもたらさないので、不要な処理を回避するために処分される。

ランダムなGF(256)符号の実装形態の場合、これは、新しいランダムな行がフルランクのGF(256)に対してu×u+1行列に追加されるときに、得られるu×u行列がフルランクを有さない確率は1/256であることに基づいて、256につき約1個の修復シンボルの場合であり得る。

コーシー符号の実装形態の場合、ブロック符号として使用されるとき、ソースシンボルおよび修復シンボルの総数が256未満である場合、失敗確率はゼロである。そのような符号はリードソロモン符号に相当する。

ブロックモードの結果
ブロック符号として使用される伸縮性コード符号のテスト(すなわち、k個のソースシンボルを有するフルセットに等しい範囲でいくつかの修復ブロックをすべて生成する)では、固定のブロックサイズ(k=256)および修復量(r=8)において、符号化速度および復号速度は、約200バイトを上回る様々なブロックサイズにおいてほぼ同じであるが、それを下回ると、速度は落ちる。これはおそらく、200バイトを下回るシンボル(または条件に応じた何らかの他のしきい値)では、シンボル演算を決定するのに必要な論理のオーバーヘッドがシンボル演算自体と比較して著しいが、シンボルサイズがより大きい場合、シンボル演算自体が支配的であるためだと思われる。

他のテストでは、固定ブロックおよびシンボルサイズに関する修復オーバーヘッド(r/k)の関数としての符号化および復号の速度は、その符号化および復号の複雑さが修復シンボルの数に比例する(したがって速度が1/rに比例する)ことを示した。

ストリームモードの結果
消失レートがオーバーヘッドを大幅に下回るとき、平均レイテンシは低いが、消失レートが符号オーバーヘッドに近づくにつれて平均レイテンシは急激に増大する。これは予想されることであり、その理由は、消失レートがオーバーヘッドを大幅に下回るとき、たいていの消失は1つの修復シンボルを使用してリカバリされ得ることにある。消失レートが上昇するにつれて、1つの修復シンボルの範囲内で複数の消失が生じて、より多くの修復シンボルを使用しなければない場合が多くなる。

生じ得る別の微調整として、上記の例では256であった修復シンボルのスパン(スパンは、修復シンボルの範囲または近傍セットにあるソースシンボルの数である)を変える効果について考える。スパンを減らした場合、固定のオーバーヘッドにおいて、各ソースシンボルを保護する修復シンボルの数が減るので、これが残余誤差レートを上昇させると予想される。ただし、スパンを減らすと、エンコーダとデコーダの両方において計算の複雑さも低下する。

ファウンテンブロック符号(Fountain Block Code)であるウィンドウベースの符号
多くのエンコーダおよびデコーダでは、符号化および復号に割り振られる計算能力および時間の量は限られている。たとえば、デコーダがバッテリ電源式ハンドヘルドデバイスである場合、復号は効率的であるべきであり、過度の計算能力を要求すべきではない。符号化および復号演算に必要な計算能力の1つの尺度は、シンボルを有する特定のセットを復号するのに必要なシンボル演算(2つのシンボルの加算、乗算、XOR演算、コピーなど)の数である。これを念頭に置いて符号を設計すべきである。正確な演算数は、どの符号化シンボルが受信されるか、またどれだけの数の符号化シンボルが受信されるかに基づいて変わり得るので、事前にはわからないこともあるが、平均的ケースまたは最悪のケースを判断して相応に設計を構成することは可能であることが多い。

このセクションは、新しいタイプのファウンテンブロック符号について説明する。この符号は、本明細書では「ウィンドウベースの符号」と呼ばれ、効率的な符号化および復号のいくつかの態様を示す以下でさらに述べる伸縮性符号のいくつかの土台である。最初に説明するウィンドウベースの符号は非システマティック符号であるが、以下でさらに説明するように、本開示を読めば明らかなるシステマティック符号に非システマティック符号を変換するための方法がある。この場合、各符号化シンボルの範囲はK個のソースシンボルを有するブロック全体であるが、各符号化シンボルの近傍セットは格段にスパースであり、K個よりもかなり少ないB個の近隣からなり、様々な符号化シンボルの近傍セットは通常、互いにかなり異なる。

K個のソースシンボルを有するブロックについて考える。エンコーダは次のように動作する。最初に、エンコーダはB個のゼロシンボルをブロックの各側に(論理的または実際的に)付加し、K+2B個のシンボルX₀、X₁、…、X_K+2B-1を有する拡張ブロック、すなわち、最初のB個のシンボルおよび最後のB個のシンボルがゼロシンボルであり、中間のK個のシンボルがソースシンボルである拡張ブロックを形成する。符号化シンボルを生成するために、エンコーダは1とK+B-1との間の開始位置tをランダムに選択し、適切な有限体(たとえば、GF(2)またはGF(256))からランダムまたは疑似ランダムに値α₀、…、α_B-1を選ぶ。次いで符号化シンボル値ESVは、エンコーダによって式5の式を使用して計算され、この場合、生成された符号化シンボルの近傍セットは、拡張ブロックの位置t〜t+B-1にあるシンボルから選択される。

デコーダは、少なくともK個の符号化シンボルを受信すると、復号するために拡張ブロックにおけるソースシンボルの位置に対して往復掃引を使用する。第1の掃引はブロックの最初の位置にあるソースシンボルから最後の位置にあるソースシンボルまでとし、当該ソースシンボルsとそれをリカバリし得る符号化シンボルeとをマッチングし、後方位置にあるソースシンボルをリカバリするために使用され得る符号化シンボルのsに対する依存性を消去し、eに対するsの寄与を調整して単にsとなるようにする。第2の掃引は、ブロックの最後の位置にあるソースシンボルから最初の位置にあるソースシンボルまでとし、前方位置にあるソースシンボルをリカバリするために使用される符号化シンボルの当該ソースシンボルsに対する依存性を消去する。往復掃引に成功した後、各ソースシンボルのリカバリされた値は、それがマッチングされる符号化シンボルの値である。

第1の掃引プロセスのために、デコーダはすべての受信符号化シンボルを有するセットEを取得する。ソースシンボルsごとに、拡張ブロック内の位置i=B,…, B+K-1において、デコーダは、近隣セットにsを有するE内のすべての符号化シンボルのうちで最先の近隣エンド位置を有する符号化シンボルeを選択し、次いで、eとsとをマッチングし、Eからeを削除する。この選択は、現在の一次方程式セットにおける符号化シンボルeに対するsの寄与がゼロではない、すなわちsがβ・s (β≠0)をeに提供する場合のeの中から行う。sの寄与がゼロではない符号化シンボルeがない場合、sを復号することができず、復号は失敗する。ソースシンボルsが符号化シンボルeとマッチングされると、符号化シンボルeはセットEから除去され、ガウス消去法を使用して、E内のすべての符号化シンボルに対するsの寄与を消去し、eに対するsの寄与は、eに対するsの寄与の係数の逆数とeとを掛けることによって、単にsになるように調整される。

デコーダの第2の掃引プロセスは次のように動作する。ソースシンボルsごとに、ソース位置i=K-1,…, 0において、ガウス消去法を使用して、iに先行する位置にあるソースシンボルとマッチングされるE内のすべての符号化シンボルに対するsの寄与を消去する。

受信符号化シンボルによって定義される連立一次方程式がランクKを有する場合、かつその場合に限り、復号はすべてのソースシンボルを完全にリカバリすることに成功する、すなわち、受信符号化シンボルがランクKを有する場合、上記の復号プロセスは、ブロックのK個のソースシンボルをリカバリすることが保証される。

生成される符号化シンボル1個あたりのシンボル演算の数はBである。

符号化シンボルの射程は、符号化シンボルの近隣である最初の位置と符号化シンボルの近隣である最後の位置との間の拡張ブロック内の位置を有するセットとなるように定義される。上記の構成では、各符号化シンボルの射程のサイズはBである。復号シンボル演算の数は、復号に使用される符号化シンボルの射程のサイズの合計によって制限される。これは、上記のマッチングプロセスが設計される方法によって、符号化シンボルの射程が復号プロセス中に決して拡張されず、各復号シンボル演算が符号化シンボルの射程のサイズの合計を1つ減らすからである。これは、K個のソースシンボルを復号するためのシンボル演算の数がO(K・B)であることを暗示している。

ウィンドウベースの符号の計算の複雑さとそのリカバリ特性との間にはトレードオフがある。B=O(K^1/2)である場合であって、有限体のサイズが十分に大きくなるように、たとえばO(K)になるように選ばれた場合、ブロックのK個のソースシンボルはすべて、K個の受信符号化シンボルから高い確率でリカバリが可能であり、さらに受信した各符号化シンボルに応じて失敗の確率が急激に低下することが、単純な分析によって示され得る。ウィンドウベースの符号のリカバリ特性は、GF[2]またはGF[256]がそれぞれ有限体として使用され、B=O(K^1/2)であるときにランダムGF[2]符号またはランダムGF[256]符号のリカバリ特性に似ている。

同様の分析を使用して、B=O(ln(K/δ)/ε)である場合、K(1+ε)個の符号化シンボルが受信された後に、ブロックのK個のソースシンボルすべてを少なくとも1-δの確率でリカバリすることができる。

当業者が認識するように、本明細書で説明するウィンドウベースの符号には多くの変形形態がある。一例として、K+2B個のシンボルを有する拡張ブロックを作成する代わりに、K個のソースシンボルから符号化シンボルを直接生成することができ、この場合、符号化シンボルごとに0とK-1との間でランダムにtが選ばれ、次いで式6に示すように符号化シンボル値が計算される。この変形ウィンドウベースのブロック符号のために復号する1つの方法として、上記の復号手順に類似する復号手順を使用するが、その例外として、最初に、K個のソースシンボルのうちのB個を有する連続セットが「非アクティブ化」され、復号は、これらのB個の非アクティブ化ソースシンボル値が既知であると仮定して前述のように進行し、符号化シンボルとB個の非アクティブ化ソースシンボルとの間のB×B連立方程式が作成され、解かれ、次いでこれと往復掃引の結果とに基づいて、残存するK-B個のソースシンボルが解かれる。この仕組みの詳細は、Shokrollahi-Inactivationに記載されている。

システマティックウィンドウベースのブロック符号
上記のウィンドウベースの符号は非システマティック符号である。システマティックウィンドウベースの符号は、これらの非システマティックウィンドウベースの符号から構成可能であり、そのように構成されたシステマティック符号の効率性およびリカバリ特性は、それらが構成される際の元になる非システマティック符号の効率性およびリカバリ特性に非常に似ている。

一般的な実装形態では、K個のソースシンボルが、非システマティック符号によって生成される最初のK個の符号化シンボルの位置に配置され、復号されて拡張ブロックが取得され、次いで修復シンボルが、復号拡張ブロックからシステマティック符号のために生成される。この仕組みの詳細は、Shokrollahi-Systematicに記載されている。このウィンドウベースのブロック符号のための単純で好ましいそのようなシステマティック符号構成について以下で説明する。

ファウンテンブロック符号である上述の非システマティックウィンドウベースの符号について、システマティック符号を構成するために最初のK個の符号化シンボルを生成する好ましい1つの方法は、以下のとおりである。最初のK個の符号化シンボルについて1とK+B-1との間の開始位置tを選ぶ代わりに、以下を行う。B'=B/2とする(一般性を失わずにBは偶数であると仮定する)。最初のK個の符号化シンボルについてt=B', B'+1,…, B'+K-1を選ぶ。最初のK個の符号化シンボルを生成する際、有限体の非ゼロ要素となるように係数α_Bが選ばれる(この係数を非ゼロにすることで、復号プロセスは、この符号化シンボルからこの係数に対応するソースシンボルをリカバリすることができるようになる)ことが常に該当するのでない場合に、例外があり得るが、生成はまさに上記のとおりである。これらの符号化シンボルが構成される方法によって、これらの最初のK個の符号化シンボルからブロックのK個のソースシンボルをリカバリすることが常に可能である。

システマティック符号の符号化構成は次のとおりである。非システマティックウィンドウベースの符号に関する前パラグラフで説明したプロセスに従って生成される最初のK個の符号化シンボルの位置にK個のソースシンボルの値を配置し、非システマティックウィンドウベースの符号の往復復号プロセスを使用して、拡張ブロックのK個のソースシンボルを復号し、次いで、往復復号プロセスから生じる復号ソースシンボルを内包する拡張ブロックに適用される非システマティックウィンドウベースの符号を使用して、追加の修復シンボルを生成する。

符号化シンボルに対するソースシンボルのマッピングは、Kのランダム置換を使用して、突発する連続ソースシンボルの消失(および他の消失パターン)が符号化シンボルの任意の部分からの拡張ブロックのリカバリの可能性、すなわち、ソースシンボルおよび修復シンボルの受信の任意のパターンおよび構成に影響しないようにすべきである。

システマティック復号プロセスは、システマティック符号化プロセスの鏡像である。受信符号化シンボルを使用して、非システマティックウィンドウベースの符号の往復復号プロセスを使用して拡張ブロックをリカバリし、次いで拡張ブロックに非システマティックウィンドウベースのエンコーダを適用して、任意の紛失ソースシンボル、すなわち、紛失した最初のK個の符号化シンボルのうちのいずれかを符号化する。

復号がエンコーダで生じ、符号化がデコーダで生じる、システマティック符号化および復号に対するこの手法の1つの利点として、システマティックシンボルおよび修復シンボルが、両方にわたって一貫したプロセスを使用して作成され得る。実際、符号化シンボルを生成するエンコーダの部分は、符号化シンボルのK個が元のK個のソースシンボルとたまたま完全にマッチングすることを認識すらしなくてもよい。

ファウンテン伸縮性符号(Fountain Elastic Code)であるウィンドウベースの符号
ウィンドウベースの符号ファウンテンブロック符号は、効率的であるとともに良好なリカバリ特性を有するファウンテン伸縮性符号を構成するための基礎として使用され得る。構成の説明を簡単にするために、サイズが等しい複数のベースブロックX¹、…、X^Lがあるとき、すなわちL個のベースブロックの各々がK個のソースシンボルを含むときの構成について説明する。当業者は、これらの構成および方法を、ベースブロックがすべて同じサイズではないケースに拡大適用できることを認識しよう。

前述のように、ソースブロックは、L個のベースブロックの任意の空でないサブセットの集合を含み得る。たとえば、1つのソースブロックは第1のベースブロックを含むことができ、第2のソースブロックは第1および第2のベースブロックを含むことができ、第3のソースブロックは第2および第3のベースブロックを含むことができる。場合によっては、ベースブロックの一部または全部はサイズが異なり、ソースブロックの一部または全部はサイズが異なる。

エンコーダは次のように動作する。最初に、ベースブロックXⁱごとに、エンコーダはブロックの各側にB個のゼロシンボルを(論理的または実際的に)付加して、K+2B個のシンボル

を有する拡張ブロック、すなわち、最初のB個のシンボルおよび最後のB個のシンボルがゼロシンボルであり、中間のK個のシンボルがベースブロックXⁱのソースシンボルである拡張ブロックを形成する。

エンコーダは次のようにソースブロックSの符号化シンボルを生成し、ここでSはL'個のベースブロックを含み、また一般性を失わずに、これらがベースブロックX¹、…、X^L'であると仮定する。エンコーダは、1とK+B-1との間の開始位置tをランダムに選択し、すべてのi=1,…, L'について、値

を適切な有限体(たとえば、GF(2)またはGF(256))からランダムに選ぶ。各i=1,…, L'について、エンコーダは、同じ開始位置tに基づいて符号化シンボル値を生成し、これは式7に示すとおりである。

そして、ソースブロックに関して生成される符号化シンボル値ESVは、ESVⁱのi=1,…, L'にわたるシンボル有限体の合計にすぎず、これは式8に示すとおりである。

デコーダを使用してベースブロックのサブセットを復号すると仮定し、また一般性を失わずに、これらがベースブロックX¹、…、X^L'であると仮定する。これらのL'個のベースブロック内のソースシンボルをリカバリするために、デコーダは、X¹、…、X^L'のサブセットの集合からなるソースブロックから生成された任意の受信符号化シンボルを使用することができる。効率的な復号を促進するために、デコーダは復号行列を構成し、この場合、行列の行は、復号に使用され得る受信符号化シンボルに対応し、行列の列は、インターリーブされた順序で構成されたベースブロックX¹、…、X^L'の拡張ブロックに対応する。

ファウンテンブロック符号に関する前述の往復デコーダと同様に、デコーダは、復号するために上述の行列の列位置にわたって往復掃引を使用する。第1の掃引は行列の最小列位置から最大列位置までとし、当該列位置に対応するソースシンボルsとそれをリカバリし得る符号化シンボルeとをマッチングし、後方列位置に対応するソースシンボルをリカバリするために使用され得る符号化シンボルのsに対する依存性を消去し、eに対するsの寄与を調整して単にsとなるようにする。第2の掃引は、行列の最大列位置から最小列位置まで、ブロックの最後の位置にあるソースシンボルから最初の位置にあるソースシンボルまでとし、前方位置にあるソースシンボルをリカバリするために使用される符号化シンボルの当該列位置に対応するソースシンボルsに対する依存性を消去する。往復掃引に成功した後、各ソースシンボルのリカバリされた値は、それがマッチングされる符号化シンボルの値である。

第1の掃引プロセスにおいて、デコーダは、ベースブロックX¹、…、X^L'を復号するのに有用であり得るすべての受信符号化シンボルを有するセットEを取得する。L'個の基本ブロックのうちの1つの基本ブロックのソースシンボルsに対応する各位置i=L'・B,…,L'・(B+K)-1について、デコーダは、近隣セットにsを有するE内のすべての符号化シンボルのうちで最先の近隣エンド位置を有する符号化シンボルeを選択し、次いで、eとsとをマッチングし、Eからeを削除する。この選択は、現在の一次方程式セットにおける符号化シンボルeに対するsの寄与がゼロではない、すなわちsがβ・s(β≠0)をeに提供する場合のeの中から行う。sの寄与がゼロではない符号化シンボルeがない場合、sを復号することができず、復号は失敗する。ソースシンボルsが符号化シンボルeとマッチングされると、符号化シンボルeはセットEから除去され、ガウス消去法を使用して、E内のすべての符号化シンボルに対するsの寄与を消去し、eに対するsの寄与は、eに対するsの寄与の係数の逆数とeとを掛けることによって、単にsになるように調整される。

デコーダの第2の掃引プロセスは次のように動作する。L'個の基本ブロックのうちの1つの基本ブロックのソースシンボルsに対応する各位置i=L'・(B+K)-1,…,L'・Bについて、ガウス消去法を使用して、iに先行する位置に対応するソースシンボルとマッチングされるE内のすべての符号化シンボルに対するsの寄与を消去する。

受信符号化シンボルによって定義される連立一次方程式がランクL'・Kを有する場合、かつその場合に限り、復号はすべてのソースシンボルを完全にリカバリすることに成功する、すなわち、受信符号化シンボルがランクL'・Kを有する場合、上記の復号プロセスは、L'個の基本ブロックのL'・K個のソースシンボルをリカバリすることが保証される。

生成される符号化シンボル1個あたりのシンボル演算の数はB・Vであり、ここでVは、符号化シンボルが生成される際の元になるソースブロックによってエンベロープされる基本ブロックの数である。

符号化シンボルの射程は、復号行列における近隣ソースシンボルに対応する最小列位置と近隣ソースシンボルに対応する最大列位置との間の列位置を有するセットになるように定義される。符号化プロセスおよび復号行列の特性によって、符号化シンボルの射程のサイズは、上記の復号プロセスにおいて最大でB・L'である。復号シンボル演算の数は、最大でも符号化シンボルの射程のサイズの合計であり、その理由は、上記のマッチングプロセスの特性により、符号化シンボルの射程が復号シンボル演算によって元の射程を越えて拡張されることは決してなく、各復号シンボル演算が符号化シンボルの射程のサイズの合計を1つ減らすことにある。これは、L'個の基本ブロックにおけるN=K・L'個のソースシンボルを復号するためのシンボル演算の数がO(N・B・L')であることを暗示している。

ウィンドウベースの符号の計算の複雑さとそのリカバリ特性との間にはトレードオフがある。B = O(ln(L)・K^1/2)である場合であって、有限体のサイズが十分に大きくなるように、たとえばO(L・K)になるように選ばれた場合に、前述の理想的なリカバリ伸縮性符号のリカバリ条件がL'個の基本ブロックに関する受信符号化シンボルによって満たされる場合、L'個の基本ブロックのすべてのL'・K個のソースシンボルは高い確率でリカバリが可能であり、さらに受信した各符号化シンボルに応じて失敗の確率が急激に低下することが、単純な分析によって示され得る。ウィンドウベースの符号のリカバリ特性は、GF[2]またはGF[256]がそれぞれ有限体として使用され、B = O(ln(L)・K^1/2)であるときにランダムGF[2]符号またはランダムGF[256]符号のリカバリ特性に似ている。

同様の分析を使用して、B=O(ln(L・K/δ)/ε)である場合に、L'個の基本ブロックのすべてのL'・K個のソースシンボルが、以下の条件において少なくとも1-δの確率でリカバリされ得ることを示すことができる。L'個の基本ブロックを復号するのに有用である受信符号化シンボルが生成される際の元になるソースブロックの数をTとする。その場合、T個のソースブロックから生成される受信符号化シンボルの数は、少なくともL'・K・(1+ε)個になるはずであり、すべてS≦Tの場合に、S個のソースブロックを有する任意のセットから生成される符号化シンボルの数は、最大でも、それらのS個のソースブロックの集合におけるソースシンボルの数になるはずである。

上記のウィンドウベースの符号は非システマティック伸縮性符号である。システマティックウィンドウベースのファウンテン伸縮性符号は、これらの非システマティックウィンドウベースの符号から構成可能であり、そのように構成されたシステマティック符号の効率性およびリカバリ特性は、それらが構成される際の元になる非システマティック符号の効率性およびリカバリ特性に非常に似ており、このことは、ファウンテンブロック符号であるウィンドウベースの符号に関して上述したシステマティック構成と同様である。この仕組みの詳細は、Shokrollahi-Systematicに記載されている。

当業者であれば認識するように、本明細書で説明するウィンドウベースの符号には多くの変形形態がある。一例として、基本ブロックごとにK+2B個のシンボルを有する拡張ブロックを作成する代わりに、符号化シンボルが生成される際の元になるソースブロックの一部である各基本ブロックのK個のソースシンボルから符号化シンボルを直接生成することができ、この場合、符号化シンボルごとに0とK-1との間でtがランダムに選ばれ、次いで、そのような各基本ブロックに関して式6に示す符号化シンボル値と同様に、符号化シンボル値が計算される。

この変形ウィンドウベースのブロック符号のために復号する1つの方法として、上記の復号手順に類似する復号手順を使用するが、その例外として、最初に、L'・K個のソースシンボルのうちのL'・B個を有する連続セットが「非アクティブ化」され、復号は、これらのL'・B個の非アクティブ化ソースシンボル値が既知であると仮定して前述のように進行し、符号化シンボルとL'・B個の非アクティブ化ソースシンボルとの間のL'・B ×L'・B連立方程式が作成され、解かれ、次いでこれと往復掃引の結果とに基づいて、残存するL'・(K-B)個のソースシンボルが解かれる。この仕組みの詳細は、Shokrollahi-Inactivationに記載されている。

上記のウィンドウベースの符号には多くの他の変形形態がある。たとえば、各基本ブロックが同じ数のソースシンボルを含むという条件を緩和することが可能である。たとえば、符号化プロセス中に、各基本ブロックを符号化するために使用されるB の値は、当該基本ブロックのソースブロックの数に比例し得る。たとえば、第1の基本ブロックはK個のソースシンボルを備え、第2の基本ブロックはK'個のソースシンボルを備えると仮定し、これらのブロックのサイズの比をμ=K/K'とする。その場合、第1の基本ブロックに使用される値Bおよび第2の基本ブロックに使用される対応する値B'は、B/B'=μを満たすことができる。この変形形態では、両方の基本ブロックをエンベロープするソースブロックから生成される符号化シンボルに対する基本ブロックの寄与を計算する際の2つの基本ブロック内の開始位置は異なることがあり、たとえば、符号化プロセスは0と1との間で均一に値

を選び、次いで第1の基本ブロックに開始位置

を使用し、第2の基本ブロックに開始位置

を使用する(これらの値は最寄の整数位置に切り上げられる)ことができる。この変形形態では、復号される基本ブロックの各々からのインタリーブされたシンボルを含む復号行列をデコーダで形成するとき、第2の基本ブロックに対応する位置の頻度に対する第1の基本ブロックに対応する位置の頻度が比率μとなるようにインターリービングを行うことができ、たとえば、第1の基本ブロックのサイズが第2の基本ブロックのサイズの2倍である場合、第1の基本ブロックに対応する列位置の数は、第2の基本ブロックに対応する列位置の数の2倍であり、この条件は、復号行列内の列位置の連続セットに当てはまる(モジュロ丸め誤差)。

当業者であれば認識するように、多くの他の変形形態もある。たとえば、完全な復号行列を記憶して処理しなければならない代わりに、デコーダにおいて復号行列のスパース行列表現を使用することができる。これは復号の記憶および時間の複雑さを大幅に減らし得る。

他の変形形態も可能である。たとえば、符号化は、2つのタイプの符号化シンボルの混合を含むことがあり、これらは、上記のように生成される多数部分の第1のタイプの符号化シンボル、およびランダムでスパースに生成される少数部分の第2のタイプの符号化シンボルである。たとえば、第1のタイプの符号化シンボルの割合が1-K^-1/3であることがあり、第1のタイプの各符号化シンボルの射程がB =O(K^1/3)であることがあり、第2のタイプの符号化シンボルの割合がK^-1/3であることがあり、第2のタイプの各符号化シンボルの近隣の数がK^2/3であることがある。2つのタイプの符号化シンボルのそのような混合の1つの利点として、復号の成功を確実にするために第1のタイプに使用されるBの値をかなり小さくすることができ、たとえば、1つのタイプのみ使用されるときにはB=O(K^1/2)であるのに対して、2つのタイプが使用されるときにはB=O(K^1/3)になり得る。

第1のステップにおいて、復号を続けられるように、復号が立ち往生したときはいつでも、ソースシンボルを非アクティブ化する非アクティブ化復号を使用して、上記の往復復号プロセスが第1のタイプの符号化シンボルに適用されるように、復号プロセスは変更される。次いで第2のステップにおいて、第2のタイプの符号化シンボルを使用して、非アクティブ化ソースシンボル値がリカバリされ、次いで第3のステップにおいて、これらの解かれた符号化シンボル値と往復復号の第1のステップの結果とを使用して、残りのソースシンボル値を解く。この変更の利点は、リカバリ特性を劣化させずに符号化および復号の複雑さを大幅に改善することである。3つ以上のタイプの符号化シンボルを使用するさらなる変形形態も、リカバリ特性を劣化させずに符号化および復号の複雑さをさらに改善することが可能である。

理想的なリカバリ伸縮性符号
このセクションは、前述の理想的なリカバリ伸縮性符号の特性を実現する伸縮性符号について説明する。この構成は、ソースブロックが以下の条件を満たすときに適用される。各ソースブロックのソースシンボルが連続するような順番でソースシンボルを配置することができ、それにより、任意の第1のソースブロックおよび任意の第2のソースブロックについて、第1のソースブロックにあるが第2のソースブロックにはないソースシンボルが、すべて第2のソースブロックの前またはすべて第2のソースブロックの後のいずれかに存在するようになる、すなわち、第1のソースブロックおよび第2のソースブロックについて、第1のソースブロックの一部のシンボルが第2のソースブロックの前に来ることも、第1のソースブロックの一部のシンボルが第2のソースブロックの後に来ることもなくなる。簡潔のために、ここではそのような符号を非サブセットコード伸縮性符号または「NSCE符号」と呼ぶ。NSCE符号はプレフィックス伸縮性符号を含む。

本明細書における「構成」は、抽象的に考えられ得る数学的概念を伴うことがあるが、そのような構成は有用な目的に、かつ/またはデータ、電気信号もしくは物品の変換に適用されることを理解されたい。たとえば、次に符号化を復号することになる受信機/デコーダに送信するデータのシンボルを符号化しようとするエンコーダによって、構成は実行され得る。このようにして、本明細書で説明する発明は、説明が数学に焦点を当てる場合でも、エンコーダ、デコーダ、エンコーダとデコーダとの組合せ、符号化および/または復号するプロセスにおいて実施されてよく、プログラムコードを実行および/または解釈するハードウェアおよび/またはソフトウェアとともに使用するコンピュータ可読媒体に記憶されたプログラムコードによって実施されてもよい。

NSCE符号の例示的な構成では、n^c(n)個のフィールド要素を有する有限体が使用され、ここではc(n)=O(n^C)であり、Cはソースブロックの数である。以下は構成の概要であるが、当業者がこの概要を読めば、実装形態は明らかになろう。この構成は、いくつかの場合において、少なくとも幾分か、必要な有限体のサイズをさらに縮小するために最適化され得る。

概要において、nは符号化され復号されるソースシンボルの数であり、Cはコードとも呼ばれる、符号化プロセスで使用されるソースブロックの数であり、c(n)はおよそn^Cである所定の値である。コードは、修復シンボルを生成する際に使用されるn個のソースシンボルのサブセット(真部分集合であるかどうかを問わない)であり、「ブロック」は、同じ領域内から生成されたシンボルを有するセットであるので、使用されるコードと使用されるブロックとの間には1対1の対応がある。ここで、これらの要素の使用について、エンコーダまたはデコーダに言及しながら説明するが、明示されていない場合でも両方によって同様のステップが実行され得ることを理解されたい。

エンコーダは、1からCまで幅があり得る、処理される現在のブロック/コードを示す変数jを管理する。何らかの論理または計算によって、エンコーダは、ブロックjごとに、ブロックjに関連するソースシンボルの数k_j、および符号化シンボルの数n_jを決定する。次いでエンコーダは、ブロックjについてk_j×n_jのコーシー行列M_jを構成する。したがって、コーシー行列を表すためにベース有限体に必要なフィールドのサイズは、すべてのjについて最大k_j+n_jである。このベースフィールドにおける要素の数をqとする。

エンコーダは、q^D個の要素を有するより大きいフィールドFにわたって動作し、ここでDはおよそq^Cである。次数Dを有するFの要素をωとする。エンコーダは符号化シンボルを計算するのに使用される行列を変更するために、ωの累乗を(少なくとも論理的に)使用する。C個のブロックのうちのブロック1について、行列M₁は変更されていない。ブロック2について、i番目のソースシンボルに対応するM₂の行には、ωⁱを掛ける。ブロックjについて、i番目のソースシンボルに対応するM_jの行にはω^iq(j)を掛け、ここでq(j)=q^j-2である。

変更された行列をM'₁、…、M'_Cとする。これらはC個のブロックについて符号化シンボルを生成するために使用される行列である。これらの行列の主要な特性は、以下で説明する観察から示される。

受信機が様々なブロックから生成された符号化シンボルの混合を受信したと仮定する。その受信機は、ソースシンボルおよび受信符号化シンボルに対応する行列Mの行列式が非ゼロであるかどうかを判断したいことがある。

受信符号化シンボルとソースシンボルとの間で2つに分かれたグラフであって、隣接が必然的に定義されたグラフ、すなわち、ソースシンボルが、符号化シンボルが生成される際の元になるブロックの一部である場合に、符号化シンボルとソースシンボルとの間にエッジがあるグラフについて考える。このグラフ内にマッチングがある場合であって、ソースシンボルのすべてがマッチングされる場合、ソースシンボルは受信符号化シンボルから復号可能であるはずであり、Mの行列式はゼロではない。次いで各マッチングを、ソースシンボルがどのように符号化シンボルのブロックとマッチングされるかを示す「シグニチャ」によって分類し、たとえば、(1,1,3,2,3,1,2,3)のシグニチャは、このマッチングにおいて、第1のソースシンボルはブロック1の符号化シンボルとマッチングされ、第2のソースシンボルはブロック1の符号化シンボルとマッチングされ、第3のソースシンボルはブロック3の符号化シンボルとマッチングされ、第4のソースシンボルはブロック2の符号化シンボルとマッチングされる、といった具合である。次いで、マッチングは、それらのシグニチャに従って区分されてよく、Mの行列式は、これらのシグニチャによって規定される行列の行列式の合計として見ることができ、ここで、そのような各シグニチャ行列式はコーシー行列に対応し、したがってゼロではない。ただし、シグニチャ行列式は互いに消去し得る。

変更された行列M'₁、…、M'_Cを構成することによって、結果として存在するシグニチャは、当該シグニチャに対応する行列式の係数としてωの最大累乗を一意に有し、これは、この一意のシグニチャの行列式を任意の他の行列式が消去することができないので、Mの行列式はゼロではないことを暗示する。これは、ブロックのコード構造が重要である場合である。

ソースシンボル内で最初に開始(および終了)するコードに第1のブロックを対応させ、一般に、ソースブロック内で開始(および終了)するj番目のコードであるコードにブロックjを対応させる。サブセットコードがないので、任意の1つのブロックは、2番目のブロックの前に開始した場合、2番目のブロックの前に終了しなければならず、さもなければ2番目のブロックはサブセットである。

次いでデコーダは、第1のブロックに関する符号化シンボルのすべてがソースシンボルのプレフィックスとマッチングされる場合、第2のブロックに関する符号化シンボルのすべてが(第1のブロックとマッチングされるソースシンボルを除く)ソースシンボルの次のプレフィックスとマッチングされる場合などのマッチングを処理する。特に、このマッチングはe₁ 1's、次にe₂ 2's、さらに次にe₃ 3'sなどのシグニチャを有し、ここでe_iは、ブロックiから生成されたソースシンボルを復号するために使用される符号化シンボルの数である。このマッチングは(2コードの場合の定理1で使用される引数と同様に)係数としてのωの最大累乗を一意に有するシグニチャを有する、すなわち、ソースシンボルと受信符号化シンボルとの間の有効なマッチングに対応する任意の他のシグニチャは、係数としてのωのより小さい累乗を有する。したがって、行列式はゼロではないことになる。

コード伸縮性符号に関する1つの欠点は、サブセットが存在する場合、すなわち、あるコードが別のコードに内包される場合に生じる。そのような場合、各ブロックに関する符号化シンボルを貪欲に使用する場合、すなわち、少なくともソースシンボルの元の順序により、第1のソースシンボルに対してブロック1に関するすべてを使用し、これにブロック2が続くなどの場合、マッチングを常に見つけることをデコーダに保証することができない。

場合によっては、ソースシンボルは、非内包的コード構造を取得するために並べ替えられ得る。たとえば、ソースシンボルの元の順序によるコードのセットが、後続する各コードが先行コードのすべてを内包するように構成されている場合、ソースシンボルを並べ替えて、構造がプレフィックス符号の構造となる、すなわち、内部から外部にソースシンボルを並べ替えて、第1のソースシンボルが、コードのすべての内部にあるものとなり、これに最小コードを除くコードの内部にあるソースシンボルが続き、さらに最小コード2つを除くコードの内部にあるソースシンボルが続くといった具合である。この並べ替えにより、上記の構成を適用して、理想的なリカバリ特性を有する伸縮性符号を取得することができる。

伸縮性符号の使用の例
一例では、エンコーダ/デコーダは、400msのパケット往復時間(RTT)、1Mbps(ビット/秒)の供給レート、128バイトのシンボルサイズなどの予想される状況に対応するように設計される。したがって、送信側は毎秒約1000個のシンボル(1000シンボル/秒×128バイト/シンボル×8ビット/バイト=1.024Mbps)を送る。軽度の消失(たとえば、最大5%)および時には重度の消失(たとえば、最大50%)からなる中度の消失状況を想定する。

一手法では、G個のソースシンボルごとに後ろに修復シンボルが挿入され、消失からリカバリするために最大レイテンシをG個のシンボルに抑えることができる場合、ソースシンボルをリカバリしないことのある送信可能な修復シンボルの割合はX=1/Gである。Gは現在の消失状況、RTTおよび/または帯域幅に基づいて変わり得る。

伸縮性符号がプレフィックス符号であり、G=4である図5の例を考える。ソースシンボルが連続的に示されており、修復シンボルが適用されるソースブロックを表す括弧付きのラベルとともに修復シンボルが示されている。

すべての消失が最初に連続的に始まっており、1つのシンボルが消失した場合、もたらされるレイテンシは最大Gであり、2つのシンボルが消失した場合、もたらされるレイテンシは最大2×Gであり、i個のシンボルが消失した場合、もたらされるレイテンシは最大i×Gである。したがって、消失量は、もたらされるレイテンシに線形的に影響する。

許容可能な冗長オーバーヘッドがたとえば5%に制限されている場合、G=20となる、すなわち、20個のソースシンボルごとに1個の修復シンボルが送られる。上記の例では、1msあたり1個のシンボルが送られ、これは、ある修復シンボルと次の修復シンボルとの間隔が20msであることを意味し、リカバリ時間は、2つのシンボルが消失した場合に40ms、3個のシンボルが消失した場合に60ms、といった具合である。これらの状況でARQだけを使用すると、リカバリ時間は少なくとも400ms、RTTであることに留意されたい。

この例では、修復シンボルのブロックは、先行して送られたすべてのシンボルを有するセットである。受信機から返信される単純なレポートが許容される場合、ブロックは、受信されたか、必要としなくなった先行ソースシンボルを除外するように変更され得る。図6に一例が示されており、これは図5の内容の変形形態である。

この例では、エンコーダは送信側から、最小関連ソースインデックス(Relevant Source Index)のSRSIインジケータを受信する。SRSIは、すべての先行ソースシンボルが受信されるか、必要としなくなるたびに上昇し得る。その場合、エンコーダは、SRSIよりも低いインデックスを有するソースシンボルに依存する修復シンボルを持っている必要はなく、計算が節減される。一般に、SRSIは、すでに受信したソースシンボルの最大プレフィックスの直後のソースシンボルのインデックスである。次いで送信側は、受信側から受信した最大SRSIからソースシンボルの最後に送られたインデックスまでの修復シンボルの範囲を計算する。これは、フィードバックなしの場合とまったく同じリカバリ特性をもたらすが、送信側および受信側における複雑さ/メモリ要件を低下させる。図6の例では、SRSI=5である。

フィードバックにより、プレフィックス伸縮性符号をより効率的に使用することができ、フィードバックは複雑さ/メモリ要件を低下させる。送信側は消失を示すフィードバックを得ると、修復シンボルの範囲を相応に調整することができる。したがって、前方向誤り訂正および反応性誤り訂正を組み合わせるために、追加の最適化が可能である。たとえば、前方向誤り訂正(FEC)を調整して、許容可能な冗長オーバーヘッドを、たいていの消失を事前にリカバリするのに十分な高さにしながらも、過度のオーバーヘッドをもたらすほど高くないようにすることができる一方で、反応性訂正は相対的にまれな消失用とする。たいていの消失はFECを使用して迅速にリカバリされるので、たいていの消失はRTTレイテンシペナルティなしにリカバリされる。反応性訂正はRTTレイテンシペナルティを有するが、その使用は、よりまれである。

変形形態
ソースブロックのマッピングは、ソースシンボルを有するどのブロックが(一般には符号化シンボルまたはより具体的には修復シンボルであり得る)符号化シンボルを有するセットの値を決定するために使用されるかを示している。特に、ソースブロックのマッピングは、メモリに記憶されることがあり、複数のベースブロックの規模を示し、それらのベースブロックのうちのどれがどのソースブロックの「範囲内」にあるかを示している。場合によっては、少なくとも1つのベースブロックが2つ以上のソースブロックに存在する。多くの実装形態では、エンコーダおよびデコーダの動作は、ソースブロックのマッピングとは無関係であってよく、それにより任意のソースブロックのマッピングが可能になっている。したがって、所定の通常のパターンが使用され得るが、それは必須ではなく、実際には、ソースブロックの範囲はソースデータの基底構造から、トランスポート状態によって、または他の要素によって決定されることがある。

いくつかの実施形態では、エンコーダおよびデコーダは、単なる伸縮性喪失コーディングではなく誤り訂正伸縮性コーディングを適用することができる。いくつかの実施形態では、階層化コーディングが使用され、この場合、修復シンボルを有する1つのセットが高優先度データのブロックを保護し、修復シンボルを有する第2のセットが高優先度データのブロックと低優先度データのブロックとの組合せを保護する。

通信システムによっては、ネットワークコーディングが伸縮性符号と組み合わされ、この場合に元のノードが、ソースデータの符号化を中間ノードに送り、中間ノードは、中間ノードが受信した符号化データの部分から生成された符号化データを送る(設計上、またはチャネル誤差により、中間ノードはソースデータをすべて取得するとは限らない)。次いで宛先ノードは、中間ノードから受信した符号化データを復号することによって元のソースデータをリカバリし、次いでこれを再び復号してソースデータをリカバリする。

伸縮性符号を使用するいくつかの通信システムでは、たとえば、ファイル/ストリームがすべて利用可能になる前にファイル/ストリームのプレフィックスを送る必要があるときのファイル供給/ストリーミングのプログレッシブダウンロードのような様々な適用がサポートされ得る。そのようなシステムはまた、PLP置換またはオブジェクトトランスポートに使用され得る。

さらに、本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを、当業者は本開示を読めば諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の例示的な実施形態の範囲からの逸脱を生じるものと解釈すべきではない。

本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または、本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで、実装または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。

本明細書で開示される実施形態に関して説明される方法またはアルゴリズムのステップは、直接ハードウェアで実施されるか、プロセッサによって実行されるソフトウェアモジュールで実施されるか、またはその2つの組合せで実施され得る。ソフトウェアモジュールは、ランダムアクセスメモリ(RAM)、フラッシュメモリ、読取り専用メモリ(ROM)、電気的プログラマブルROM(EPROM)、電気消去可能プログラマブルROM(EEPROM)、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または、当技術分野で既知の任意の他の形態の記憶媒体中に常駐し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC中に常駐し得る。ASICはユーザ端末中に常駐し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末中に個別構成要素として常駐し得る。

1つまたは複数の例示的な実施形態では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装する場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために使用でき、コンピュータによってアクセスできる、任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用される場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびBlu-Ray(登録商標)ディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

開示される例示的な実施形態の上記の説明は、いかなる当業者も本発明を作成または使用できるようにするために提供される。これらの例示的な実施形態への様々な修正が当業者には容易に明らかになることになり、本明細書に定義する一般原理は、本発明の趣旨および範囲を逸脱することなしに他の実施形態に適用され得る。したがって、本発明は、本明細書に示す実施形態に限定されるものではなく、本明細書で開示する原理および新規の特徴に一致する最大の範囲を与えられるものである。

100 通信システム、システム
110 弾性符号ブロックマッパー、マッパー
115 ストレージ
120 エンコーダアレイ、エンコーダ
125 ストレージ
130 送信機モジュール
200 受信機
210 受信機モジュール
215 ソースブロックマッピング用ストレージ、ストレージ
220 ストレージ
230 デコーダ
235 ストレージ
300 エンコーダ
305 シンボルバッファ
310 シンボルセレクタ
320 オペレータ

Claims (51)

1. 誤りまたは喪失をもたらす可能性がある通信チャネルを通じて送信されるデータを符号化するための方法であって、ソースデータは順序付き複数のソースシンボルによって表され、前記ソースデータは送信された符号化シンボルからリカバリが可能であり、前記方法は、
   前記順序付き複数のソースシンボルのシンボルの各々に対するベースブロックを特定するステップであって、前記特定されるベースブロックは、符号化される前記ソースデータを集合的にカバーする複数のベースブロックのうちの1つである、ステップと、
   そのベースブロックをエンベロープする少なくとも1つのソースブロックを、複数のソースブロックから、そしてベースブロックの各々に対して、特定するステップであって、前記複数のソースブロックは、少なくとも一対のソースブロックを含み、一対のソースブロックは、前記対の両方のソースブロックによってエンベロープされる少なくとも1つのベースブロックが存在するとともに、そのソースブロックによってエンベロープされ、前記対の他方のソースブロックによってエンベロープされない、前記対のソースブロックの各々に対する少なくとも1つのベースブロックが存在する、という特性を有する、ステップと、
   符号化プロセスに従って前記複数のソースブロックの各々を符号化して符号化シンボルをもたらすステップであって、前記符号化プロセスは、符号化シンボルを生成するために1つのソースブロックに対して演算し、前記符号化シンボルは、前記1つのソースブロックによってエンベロープされないベースブロックからのソースシンボルのソースシンボル値とは独立であり、前記符号化により、前記対のソースブロックの集合によって表される前記ソースデータの部分は、前記対の第1のソースブロックから生成された符号化シンボルを有する第1のセットと前記対の第2のソースブロックから生成された符号化シンボルを有する第2のセットとの組合せからリカバリが可能であることが保証され、前記第1のセットにおける符号化シンボルの量は前記第1のソースブロックにおけるソースデータの量を下回り、前記第2のセットにおける符号化シンボルの量は前記第2のソースブロックにおけるソースデータの量を下回る、ステップと
   を含む、方法。
2. 前記符号化プロセスにより、前記符号化シンボルおよび前記ソースシンボルが同じサイズを有するとき、符号化シンボルを有する前記第1のセットがM1個の符号化シンボルを含み、前記第1のソースブロックがN1個のソースシンボルを含み、符号化シンボルを有する前記第2のセットがM2個の符号化シンボルを含み、前記第2のソースブロックがN2個のソースシンボルを含むとき、かつ前記第1および第2のソースブロックのインターセクションがゼロを上回るN3個のソースシンボルを含むとき、前記対のソースブロックの前記集合のリカバリ可能性は、M1<N1およびM2<N2となる値の少なくともいくつかの組合せについて、M1+M2=N1+N2-N3である場合、所定のしきい値確率を超えて保証される、請求項1に記載の方法。
3. 前記対のソースブロックの前記集合の前記リカバリ可能性は、M1≦N1およびM2≦N2となるようなM1およびM2の値のすべての組合せについて、M1+M2=N1+N2-N3である場合、所定のしきい値確率をより高いことが保証される、請求項2に記載の方法。
4. 前記対のソースブロックの前記集合の前記リカバリ可能性は、M1≦N1およびM2≦N2となるようなM1およびM2の値のすべての組合せについて、M1+M2=N1+N2-N3である場合、確実である、請求項2に記載の方法。
5. 前記対のソースブロックの前記集合のリカバリ可能性は、M1およびM2の値の少なくともいくつかの組合せについて、M1+M2が、所定のパーセンテージを下回るパーセンテージだけN1+N2-N3よりも大きいが、N1+N2よりも小さい場合、所定のしきい値確率よりも高い確率で保証される、請求項2に記載の方法。
6. ソースブロックから生成された少なくとも1つの符号化シンボルは、そのソースブロックによって表される前記ソースデータの前記部分からのソースシンボルに等しい、請求項1に記載の方法。
7. 前記符号化により、前記対の前記第1のソースブロックによって表される前記ソースデータの前記部分は、前記第1のソースブロックから生成された符号化シンボルを有する第3のセットからリカバリが可能であることが保証され、前記第3のセットにおける符号化シンボルの量は、前記第1のソースブロックに表されるソースデータの量を上回らない、請求項1に記載の方法。
8. 前記符号化により、前記対の前記第1のソースブロックによって表される前記ソースデータの前記部分は、前記第1のソースブロックから生成された符号化シンボルを有する第3のセットから、所定のしきい値確率よりも高い確率でリカバリが可能であることが保証され、前記第3のセットにおける符号化シンボルの量は、前記第1のソースブロックに表されるソースデータの量を少しだけ上回る、請求項1に記載の方法。
9. 各ソースブロックから生成され得る別個の符号化シンボルの数は、前記ソースブロックのサイズとは独立である、請求項1に記載の方法。
10. 各ソースブロックから生成され得る別個の符号化シンボルの数は、前記ソースブロックのサイズに依存する、請求項1に記載の方法。
11. シンボルに対するベースブロックを特定するステップは、符号化を開始する前に実行される、請求項1に記載の方法。
12. ベースブロックに対するソースブロックを特定するステップは、符号化を開始する前に実行される、請求項1に記載の方法。
13. ベースブロックがソースシンボルの各々に対して特定される前に、または前記エンベロープされるベースブロックが前記ソースブロックの各々に対して決定される前に、または前記ソースデータのすべてが生成されるか利用可能になる前に、少なくとも1つの符号化シンボルは生成される、請求項1に記載の方法。
14. 符号化シンボルを受信中であるか受信したデコーダにおける結果を表す受信機フィードバックを受信するステップと、
    ベースブロックにおけるソースシンボルの構成要素、ソースブロックをエンベロープする際のベースブロックの構成要素、ベースブロック1個あたりのソースシンボルの数、ソースブロックにおけるシンボルの数、および/またはソースブロックから生成される符号化シンボルの数のうちの1つまたは複数を調整するステップであって、前記調整は前記受信機フィードバックに少なくとも部分的に基づいて行われる、ステップと
    をさらに含む、請求項1に記載の方法。
15. 調整するステップは、新しいベースブロックを決定するステップ、または以前に決定されたベースブロックにおけるソースシンボルの構成要素を変更するステップを含む、請求項14に記載の方法。
16. 調整するステップは、新しいソースブロックを決定するステップ、または以前に決定されたソースブロックのベースブロックのエンベロープを変更するステップを含む、請求項14に記載の方法。
17. 前記ソースデータに関する様々なデータ優先度選好を表すデータ優先度選好信号を受信するステップと、
    ベースブロックにおけるソースシンボルの構成要素、ソースブロックをエンベロープする際のベースブロックの構成要素、ベースブロック1個あたりのソースシンボルの数、ソースブロックにおけるシンボルの数、および/またはソースブロックから生成される符号化シンボルの数のうちの1つまたは複数を調整するステップであって、前記調整は前記データ優先度選好信号に少なくとも部分的に基づいて行われる、ステップと
    をさらに含む、請求項1に記載の方法。
18. 各ソースブロックによってエンベロープされる前記ベースブロックにおけるソースシンボルの数は、前記ソースブロックのうちの2つ以上の間で独立である、請求項1に記載の方法。
19. ベースブロックのものと特定されるソースシンボルは、前記順序付き複数のソースシンボル内で連続していない、請求項1に記載の方法。
20. ベースブロックのものと特定される前記ソースシンボルは、前記順序付き複数のソースシンボル内で連続する、請求項1に記載の方法。
21. ソースブロックによってエンベロープされる前記ベースブロックのものと特定されるソースシンボルは、前記順序付き複数のソースシンボル内で連続する、請求項20に記載の方法。
22. あるソースブロックに関して生成され得る符号化シンボルの数は、他のソースブロックに関して生成され得る符号化シンボルの数とは独立である、請求項1に記載の方法。
23. 所与のソースブロックに関して生成される符号化シンボルの数は、前記所与のソースブロックによってエンベロープされる前記ベースブロックにおけるソースシンボルの数とは独立である、請求項1に記載の方法。
24. 符号化するステップは、
    符号化シンボルごとに、有限体から選択される係数セットを決定するステップと、
    単一のソースブロックによってエンベロープされる1つまたは複数のベースブロックのソースシンボルの組合せとして、前記符号化シンボルを生成するステップであって、前記組合せは前記係数セットによって部分的に定義される、ステップと
    を含む、請求項1に記載の方法。
25. ソースブロックから符号化シンボルを生成するシンボル演算の数は、前記ソースブロックによって表される前記ソースデータの前記部分におけるソースシンボルの数よりもはるかに少ない、請求項1に記載の方法。
26. ソースシンボルを有するセットによって表されたソースデータをリカバリするために、誤りまたは喪失を含む可能性がある通信チャネルを通じて受信されるデータを復号するための方法であって、
    ソースシンボルの各々に対するベースブロックを特定するステップであって、前記特定されるベースブロックは、前記ソースデータを集合的にカバーする複数のベースブロックのうちの1つである、ステップと、
    そのベースブロックをエンベロープする少なくとも1つのソースブロックを、複数のソースブロックから、ベースブロックの各々に対して、特定するステップであって、前記複数のソースブロックは、少なくとも一対のソースブロックを含み、一対のソースブロックは、前記対の両方のソースブロックによってエンベロープされる少なくとも1つのベースブロックが存在するとともに、そのソースブロックによってエンベロープされ、前記対の他方のソースブロックによってエンベロープされない、前記対のソースブロックの各々に対する少なくとも1つのベースブロックが存在する、という特性を有する、ステップと、
    複数の受信シンボルを受信するステップと、
    受信シンボルごとにソースブロックを特定するステップであって、その受信シンボルは前記ソースブロックに関する符号化シンボルである、ステップと、
    前記複数の受信シンボルからソースシンボルを有するセットを復号するステップであって、前記対のソースブロックの集合によって表される前記ソースデータの部分は、前記対の第1のソースブロックから生成された符号化シンボルに対応する受信シンボルを有する第1のセットと前記対の第2のソースブロックから生成された符号化シンボルに対応する受信シンボルを有する第2のセットとの組合せからリカバリが可能であることが保証され、前記第1のセットにおける受信シンボルの量は前記第1のソースブロックにおけるソースデータの量を下回り、前記第2のセットにおける受信シンボルの量は前記第2のソースブロックにおけるソースデータの量を下回る、ステップと
    を含む、方法。
27. N1が前記第1のソースブロックの前記ソースデータにおけるソースシンボルの数である場合、N2が前記第2のソースブロックの前記ソースデータにおけるソースシンボルの数である場合、N3がゼロを上回る、前記第1および第2のソースブロックのインターセクションにおけるソースシンボルの数である場合、前記符号化シンボルおよび前記ソースシンボルが同じサイズを有する場合、R1が受信シンボルを有する前記第1のセットにおける受信シンボルの数であり、R2が受信シンボルを有する前記第2のセットにおける受信シンボルの数である場合、R1個の受信シンボルを有する前記第1のセットから、またR2個の受信シンボルを有する前記第2のセットから前記一対のソースブロックの前記集合を復号するステップは、R1<N1およびR2<N2となるようなR1およびR2の少なくとも1つの値について、R1+R2=N1+N2-N3である場合、所定のしきい値確率を超えて保証される、請求項26に記載の方法。
28. 前記対のソースブロックの前記集合を復号するステップは、R1≦N1およびR2≦N2のすべての値について、R1+R2=N1+N2-N3である場合、所定のしきい値確率を超えて保証される、請求項27に記載の方法。
29. 前記対のソースブロックの前記集合を復号するステップは、R1≦N1およびR2≦N2のすべての値について、R1+R2=N1+N2-N3である場合、確実である、請求項27に記載の方法。
30. 前記対の前記第1のソースブロックによって表される前記ソースデータの前記部分は、前記第1のソースブロックから生成された符号化シンボルを有する第3のセットからリカバリが可能であり、前記第3のセットにおける符号化シンボルの量は、前記第1のソースブロックに表されるソースデータの量を上回らない、請求項26に記載の方法。
31. 各ソースブロックから生成され得る別個の符号化シンボルの数は、前記ソースブロックのサイズとは独立である、請求項26に記載の方法。
32. ソースシンボルに対するベースブロックを特定するステップおよびベースブロックのソースブロックを特定するステップのうちの少なくとも1つは、符号化を開始する前に実行される、請求項26に記載の方法。
33. ベースブロックがソースシンボルの各々に対して特定される前に、かつ/または前記エンベロープされるベースブロックが前記ソースブロックの各々に対して決定される前に、少なくともいくつかの符号化シンボルが生成される、請求項26に記載の方法。
34. どの受信シンボルが受信されたか、および/または前記ソースデータのどの部分が受信機において望まれるか、および/またはデータ優先度選好に基づいて、デコーダにおける結果を表す受信機フィードバックを決定するステップと、
    符号化プロセスを変更するのに使用可能であるような前記受信機フィードバックを出力するステップと
    をさらに含む、請求項26に記載の方法。
35. 各ソースブロックによってエンベロープされる前記ベースブロックにおけるソースシンボルの数は、前記ソースブロックのうちの2つ以上の間では独立である、請求項26に記載の方法。
36. ベースブロックのものと特定される前記ソースシンボルは、前記順序付き複数のソースシンボル内で連続する、請求項26に記載の方法。
37. ソースブロックによってエンベロープされる前記ベースブロックに特定されるソースシンボルは、前記順序付き複数のソースシンボル内で連続する、請求項26に記載の方法。
38. 復号するステップは、
    受信シンボルごとに、有限体から選択される係数セットを決定するステップと、
    2つ以上の受信シンボルまたは以前に復号されたソースシンボルから、前記2つ以上の受信シンボルに前記係数セットを使用して少なくとも1つのソースシンボルを復号するステップと
    をさらに含む、請求項26に記載の方法。
39. 1つまたは複数のソースブロックの集合をリカバリするシンボル演算の数は、前記ソースブロックの前記集合によって表される前記ソースデータの前記部分におけるソースシンボルの数の平方よりもはるかに少ない、請求項26に記載の方法。
40. 誤りまたは喪失をもたらす可能性がある通信チャネルを通じて送信するためのデータを復号するエンコーダであって、
    順序付き複数のソースシンボルによって表されるソースデータを受信するための入力部であって、前記ソースデータは送信された符号化シンボルからリカバリが可能である、入力部と、
    複数のベースブロックの少なくとも一部分のためのストレージであって、各ベースブロックは前記順序付き複数のソースシンボルのうちの1つまたは複数のソースシンボルの表現を含む、ストレージと、
    機械可読形態で記憶されるか、論理命令に従って生成可能である、複数のソースブロックの各々を1つまたは複数のベースブロックにマッピングする論理マップであって、前記複数のソースブロックは、少なくとも一対のソースブロックを含み、一対のソースブロックは、前記対の両方のソースブロックによってエンベロープされる少なくとも1つのベースブロックが存在するとともに、そのソースブロックによってエンベロープされ、前記対の他方のソースブロックによってエンベロープされない、前記対のソースブロックの各々に対する少なくとも1つのベースブロックが存在する、という特性を有する、論理マップと、
    符号化ブロックのためのストレージと、
    複数の符号化シンボルを形成するためにソースブロックのソースシンボルをそれぞれ符号化する1つまたは複数のエンコーダであって、所与の符号化シンボルは、それが符号化するソースシンボルを有する前記ソースブロック以外のソースブロックからのソースシンボル値とは独立であり、それにより、前記対のソースブロックの集合によって表される前記ソースデータの部分は、前記対の第1のソースブロックから生成された符号化シンボルを有する第1のセットと前記対の第2のソースブロックから生成された符号化シンボルを有する第2のセットとの組合せからリカバリが可能であることが保証され、前記第1のセットにおける符号化シンボルの量は前記第1のソースブロックにおけるソースデータの量を下回り、前記第2のセットにおける符号化シンボルの量は前記第2のソースブロックにおけるソースデータの量を下回る、エンコーダと
    を含む、エンコーダ。
41. 前記第1のセットにおける符号化シンボルの数と前記第2のセットにおける符号化シンボルの数との和は、前記対のソースブロックの前記集合によって表される前記ソースデータの前記部分におけるソースシンボルの数を、前記符号化シンボルおよび前記ソースシンボルが同じサイズを有する場合には上回らない、請求項40に記載のエンコーダ。
42. 前記対の前記第1のソースブロックによって表される前記ソースデータの前記部分は、前記第1のソースブロックから生成された符号化シンボルを有する第3のセットからリカバリが可能であり、前記第3のセットにおける符号化シンボルの量は、前記第1のソースブロックに表されるソースデータの量を上回らない、請求項40に記載のエンコーダ。
43. 各ソースブロックから生成され得る別個の符号化シンボルの数は、前記ソースブロックのサイズとは独立である、請求項40に記載のエンコーダ。
44. 符号化シンボルを受信中であるか受信したデコーダにおける結果を表す受信機フィードバックを受信するための入力部と、
    ベースブロックにおけるソースシンボルの構成要素、ソースブロックをエンベロープする際のベースブロックの構成要素、ベースブロック1個あたりのソースシンボルの数、ソースブロックにおけるシンボルの数、および/またはソースブロックから生成される符号化シンボルの数のうちの1つまたは複数を調整するための論理であって、前記調整は前記受信機フィードバックに少なくとも部分的に基づいて行われる、論理と
    をさらに含む、請求項40に記載のエンコーダ。
45. 前記ソースデータに関する様々なデータ優先度選好を表すデータ優先度選好信号を受信するための入力部と、
    ベースブロックにおけるソースシンボルの構成要素、ソースブロックをエンベロープする際のベースブロックの構成要素、ベースブロック1個あたりのソースシンボルの数、ソースブロックにおけるシンボルの数、および/またはソースブロックから生成される符号化シンボルの数のうちの1つまたは複数を調整するための論理であって、前記調整は前記データ優先度選好信号に少なくとも部分的に基づいて行われる、論理と
    をさらに含む、請求項40に記載のエンコーダ。
46. 各ソースブロックによってエンベロープされる前記ベースブロックにおけるソースシンボルの数は、前記ソースブロックのうちの2つ以上の間では独立である、請求項40に記載のエンコーダ。
47. ベースブロックのものと特定される前記ソースシンボルは、前記順序付き複数のソースシンボル内で連続する、請求項40に記載のエンコーダ。
48. ソースブロックによってエンベロープされる前記ベースブロックに特定されるソースシンボルは、前記順序付き複数のソースシンボル内で連続する、請求項40に記載のエンコーダ。
49. あるソースブロックに関して生成され得る別個の符号化シンボルの数は、他のソースブロックに関して生成され得る符号化シンボルの数とは独立である、請求項40に記載のエンコーダ。
50. 所与のソースブロックに関して生成される別個の符号化シンボルの数は、前記所与のソースブロックによってエンベロープされる前記ベースブロックにおけるソースシンボルの数とは独立である、請求項40に記載のエンコーダ。
51. 複数の前記符号化シンボルの各々について有限体から選択される係数セットのためのストレージと、
    単一のソースブロックによってエンベロープされる1つまたは複数のベースブロックのソースシンボルの組合せとして、前記符号化シンボルを生成するための論理であって、前記組合せは前記係数セットによって部分的に定義される、論理と
    をさらに含む、請求項40に記載のエンコーダ。