(57)【特許請求の範囲】
【請求項１】
電子信号を出力することが可能な１つまたは複数の送信機を介してデータを電子的に送信する方法であって、送信されるべき前記データがソースシンボルの順序セットによって表され、符号化プロセスの中間ステップ中にソースシンボルの前記順序セットから生成されるシンボルは、中間シンボルによって表わされ、前記データが、前記中間シンボルから生成される一連の被符号化シンボルとして送信され、前記符号化シンボルは、電子信号の少なくとも一部分を表す、前記方法は、
電子的に読取り可能な形態で、ソースシンボルの前記順序セットを取得することと、
ソースシンボルの前記順序セットから中間シンボルのセットを生成することであって、前記ソースシンボルが中間シンボルの前記セットから再生され得る、中間シンボルのセットを生成することと、
送信より前に、各中間シンボルが中間シンボルの前記セットのうちの１つのメンバーに指定され、少なくとも中間シンボルの第１のセットおよび中間シンボルの第２のセットがあるように、前記中間シンボルの前記セットを指定することであって、中間シンボルの各セットが、別個の符号化パラメータと関連付けられており、少なくとも１つの中間シンボルをメンバーとして有する、中間シンボルの前記第１のセットが、信念伝搬復号のためのシンボルとして指定され、中間シンボルの前記第２のセットが、信念伝搬復号のために永久的に非活動化されるべきシンボルとして指定される、指定することと、
複数の被符号化シンボルを生成することであって、被符号化シンボルが前記中間シンボルのうちの１つまたは複数から生成され、少なくとも１つの被符号化シンボルが、直接または間接的に、中間シンボルの複数の前記セットから選択された複数の中間シンボルから生成される、複数の被符号化シンボルを生成することと
を備える方法。
【請求項２】
各被符号化シンボルが、中間シンボルの前記第１のセットのうちの１つまたは複数の中間シンボルから生成された第１のシンボルと、中間シンボルの前記第２のセットのうちの１つまたは複数の中間シンボルから生成された第２のシンボルとの組合せから生成される、請求項１に記載の方法。
【請求項３】
各被符号化シンボルが、第１の度数分布を有する中間シンボルの前記第１のセットのうちの１つまたは複数の中間シンボルから生成された第１のシンボルと、前記第１の度数分布とは異なる第２の度数分布を有する中間シンボルの前記第２のセットのうちの１つまたは複数の中間シンボルから生成された第２のシンボルとの組合せから生成されるように、前記別個の符号化パラメータが少なくとも別個の度数分布を備える、請求項２に記載の方法。
【請求項４】
前記第１のシンボルが、中間シンボルの前記第１のセットに適用される連鎖反応符号化プロセスを使用して生成される、請求項２に記載の方法。
【請求項５】
前記第２のシンボルが、中間シンボルの前記第２のセットからランダムに選定された固定数のシンボルのＸＯＲである、請求項２に記載の方法。
【請求項６】
前記第２のシンボルが、中間シンボルの前記第２のセットからランダムに選定された第１の数のシンボルのＸＯＲであり、前記第１の数が、前記第１のシンボルを生成するために前記第１のセットから選定された前記シンボルの数に等しい第２の数に依存する、請求項２に記載の方法。
【請求項７】
前記組合せが、前記第１のシンボルと前記第２のシンボルとの前記ＸＯＲである、請求項２に記載の方法。
【請求項８】
前記中間シンボルが、ソースシンボルの前記順序セットと、ソースシンボルの前記順序セットから生成された冗長ソースシンボルのセットとを備える、請求項１に記載の方法。
【請求項９】
前記冗長シンボルの少なくともいくつかがＧＦ［２］演算を使用して生成され、他の冗長シンボルがＧＦ［２５６］演算を使用して生成される、請求項８に記載の方法。
【請求項１０】
前記中間シンボルが、符号化中に、復号プロセスを使用して前記ソースシンボルから生成され、前記復号プロセスが、前記中間シンボルと前記ソースシンボルとの間の関係の線形セットに基づく、請求項１に記載の方法。
【請求項１１】
前記線形関係の少なくともいくつかがＧＦ［２］に関する関係であり、他の線形関係がＧＦ［２５６］に関する関係である、請求項１０に記載の方法。
【請求項１２】
ソースシンボルの所与の順序セットから生成され得る別個の被符号化シンボルの数が、その順序セット中のソースシンボルの数とは無関係である、請求項１に記載の方法。
【請求項１３】
被符号化シンボルを生成するために実行されるシンボル演算の平均数が、その順序セット中のソースシンボルの数とは無関係である定数によって制限される、請求項１に記載の方法。
【請求項１４】
中間シンボルの前記第１のセットが中間シンボルの前記第２のセットよりも２桁以上大きい、請求項１に記載の方法。
【請求項１５】
ソースからデータを受信する方法であって、前記データがパケット通信チャネルを介して宛先において受信され、ソースシンボルの順序セットから導出された被符号化シンボルのセットによって表現可能な前記データが、前記ソースから前記宛先に送られた前記データを表し、前記方法は、
受信された被符号化シンボルの前記セットを取得することと、
受信された被符号化シンボルの前記セットから中間シンボルのセットを復号することと、
前記中間シンボルの各々を中間シンボルのセットに関連付けることであって、前記中間シンボルが少なくとも２つのセットに関連付けられ、第１のセットは、信念伝搬復号のためのシンボルとして前記ソースによって指定されるシンボルを備え、第２のセットは、信念伝搬復号のための永久的に非活動化されるシンボルとして前記ソースによって指定されるシンボルを備え、前記第２のセットの前記シンボルは永久的非活動化復号を使用して復号されるべきである、関連づけることと、
復号プロセスに従って中間シンボルの前記セットから、ソースシンボルの前記順序セットの前記ソースシンボルの少なくともいくつかを復元することと
を備える方法。
【請求項１６】
前記復号プロセスは、少なくとも、永久的に非活動化されるシンボルを備える前記第２のセットと、動的に非活動化されたシンボルを備えるシンボルの第３のセットであって、シンボルの前記第１のセットのサブセットであるシンボルの第３のセットとに依存する、低減された被符号化シンボルのセットが生成される第１の復号段階と、低減された被符号化シンボルの前記セットが、シンボルの前記第２のセットとシンボルの前記第３のセットとを復号するために使用される第２の復号段階と、シンボルの前記復号された第２のセット、シンボルの前記第３のセット、および受信された被符号化シンボルの前記セットが、シンボルの前記第１のセット中にある残りの中間シンボルの少なくともいくつかを復号するために使用される第３の復号段階とを備える、請求項１５に記載の方法。
【請求項１７】
前記第１の復号段階が、非活動化復号と組み合わされた信念伝搬復号を使用し、および／または前記第２の復号段階がガウス消去法を使用する、請求項１６に記載の方法。
【請求項１８】
前記第３の復号段階が、後退代入、または後退掃引と後続の前進掃引を使用する、請求項１６に記載の方法。
【請求項１９】
シンボルの前記第３のセット中のシンボルの数がソースシンボルの数の１０％よりも少なく、および／またはシンボルの前記第２のセット中のシンボルの数の１０％よりも少ないことを考慮して、前記復号プロセスが、シンボルの前記第３のセットに対して演算する、請求項１６に記載の方法。
【請求項２０】
前記受信された被符号化シンボルが、ＬＤＰＣ符号生成シンボルまたはリードソロモン符号生成シンボルとして演算される、請求項１５に記載の方法。
【請求項２１】
受信された被符号化シンボルの前記セットの各受信された被符号化シンボルが、シンボルの前記第１のセットのうちの１つまたは複数のシンボルから生成された第１のシンボルと、シンボルの前記第２のセットのうちの１つまたは複数のシンボルから生成された第２のシンボルとの組合せであるものとして演算される、請求項１５に記載の方法。
【請求項２２】
各受信された被符号化シンボルが、前記第１のシンボルと前記第２のシンボルとのＸＯＲである前記組合せとして演算される、請求項２１に記載の方法。
【請求項２３】
各受信された被符号化シンボルが、シンボルの前記第２のセットからランダムに選定された固定数のシンボルのＸＯＲである前記第２のシンボルとして演算される、請求項２１に記載の方法。
【請求項２４】
各受信された被符号化シンボルが、シンボルの前記第２のセットからランダムに選定された第１の数のシンボルのＸＯＲである前記第２のシンボルとして演算され、シンボルの前記第１の数が、前記第１のシンボルを生成するためにシンボルの前記第１のセットから選定されたシンボルの第２の数に依存する、請求項２１に記載の方法。
【請求項２５】
前記復号プロセスは、前記第１のシンボルがシンボルの前記第１のセットから連鎖反応符号に基づいて選定されたかのように演算する、請求項２１に記載の方法。
【請求項２６】
前記復号プロセスは、シンボルの前記第２のセットのサイズがソースシンボルの数の平方根に比例するかのように演算する、請求項１５に記載の方法。
【請求項２７】
前記復号プロセスは、前記中間シンボルが、ソースシンボルの前記順序セットと、ソースシンボルの前記順序セットから生成された冗長シンボルのセットとを備えるかのように演算する、請求項１５に記載の方法。
【請求項２８】
前記復号プロセスは、前記冗長シンボルの少なくともいくつかがＧＦ［２］演算を使用して生成され、他の冗長シンボルがＧＦ［２５６］演算を使用して生成されたかのように演算する、請求項２７に記載の方法。
【請求項２９】
前記復号プロセスは、前記中間シンボルがソースシンボルの前記順序セットを備えるかのように演算する、請求項１５に記載の方法。
【請求項３０】
前記復号プロセスは、前記中間シンボルが、前記中間シンボルと前記ソースシンボルとの間の関係の線形セットに基づく復号プロセスを使用して前記ソースシンボルから生成されたシンボルであるかのように演算する、請求項１５に記載の方法。
【請求項３１】
前記復号プロセスは、前記線形関係の少なくともいくつかがＧＦ［２］に関する関係であり、他の線形関係がＧＦ［２５６］に関する関係であるかのように演算する、請求項３０に記載の方法。
【請求項３２】
前記復号プロセスは、受信され得る異なる可能な被符号化シンボルの数が、前記順序セット中のソースシンボルの数とは無関係であるかのように演算する、請求項１５に記載の方法。
【請求項３３】
受信された被符号化シンボルの前記セットからのソースシンボルの前記セットを復号するために実行されるシンボル演算の平均数が、ソースシンボルの数の定数倍によって制限され、前記定数がソースシンボルの数とは無関係である、請求項１５に記載の方法。
【請求項３４】
前記復号プロセスは、シンボルの前記第１のセット中のシンボルの数が、シンボルの前記第２のセット中のシンボルの数よりも２桁以上大きいかのように演算する、請求項１５に記載の方法。
【請求項３５】
あるＫ、ＮおよびＡについて、Ｎ＝Ｋ＋Ａ個の被符号化シンボルのセットからのＫ個のソースシンボルの前記セットのすべての復元は、Ａ＝０、１または２の場合、少なくとも下限の成功の確率１−（０．０１）＾（Ａ＋１）を有し、前記下限がソースシンボルの数とは無関係であるように、前記復号プロセスが演算する、請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
相互参照
本出願は、Ｍ．Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉらの、２００９年１０月２３日に出願された「Method and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes」と題する米国特許出願第１２／６０４，７７３号の一部継続出願であり、さらに、それぞれＭ．Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉらの、それぞれ「Method and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes」と題する、２０１０年６月１１日に出願された米国仮特許出願第６１／３５３，９１０号、２００９年１１月２日に出願された米国仮特許出願第６１／２５７，１４６号、および２００９年８月１９日に出願された米国仮特許出願第６１／２３５，２８５号の優先権を主張する。上記の各仮出願および非仮出願は、すべての目的のために参照により本明細書に組み込まれる。
【０００２】
以下の参考文献は、すべての目的のためにそれらの全体が参照により本明細書に組み込まれる。
【０００３】
１）Ｍｉｃｈａｅｌ  Ｇ．Ｌｕｂｙに発行された「Information Additive Code Generator and Decoder for Communication Systems」と題する米国特許第６，３０７，４８７号（以下「Ｌｕｂｙ  Ｉ」）、
２）Ｍｉｃｈａｅｌ  Ｇ．Ｌｕｂｙに発行された「Information Additive Group Code Generator and Decoder for Communication Systems」と題する米国特許第６，３２０，５２０号（以下「Ｌｕｂｙ  ＩＩ」）、
３）Ｍ．Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉに発行された「Multi-Stage Code Generator and Decoder for Communication Systems」と題する米国特許第７，０６８，７２９号（以下「Ｓｈｏｋｒｏｌｌａｈｉ  Ｉ」）、
４）Ｍ．Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉに発行された「Systems and Processes for Decoding a Chain Reaction Code Through Inactivation」と題する米国特許第６，８５６，２６３号（以下「Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩ」）、
５）Ｍ．Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉに発行された「Systematic Encoding and Decoding of Chain Reaction Codes」と題する米国特許第６，９０９，３８３号（以下「Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩＩ」）、
６）Ｍｉｃｈａｅｌ  Ｇ．ＬｕｂｙおよびＭ．Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉの、「In-Place Transformations with Applications to Encoding and Decoding Various Classes of Codes」と題する米国特許公開第２００６／０２８０２５４号（以下「Ｌｕｂｙ  ＩＩＩ」）、
７）Ｍ．Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉの、「Multiple-Field Based Code Generator and Decoder for Communications Systems」と題する米国特許公開第２００７／０１９５８９４号（以下「Ｓｈｏｋｒｏｌｌａｈｉ  ＩＶ」）。
【０００４】
本発明は、通信システム中でデータを符号化および復号することに関し、より詳細には、効率的な方法で、通信されたデータ中の誤りおよびギャップをなくすためにデータを符号化および復号する通信システムに関する。
【背景技術】
【０００５】
通信チャネルを介した送信側と受信側との間のファイルの送信のための技法は、多くの文献の主題である。好ましくは、受信側は、ある程度の確度でチャネルを介して送信側によって送信されたデータの正確なコピーを受信することを望む。チャネルが、（物理的に実現可能なほとんどすべてのシステムをカバーする）完全な忠実度を有していない場合、１つの懸念は、送信中に損失されたまたはゆがめられたデータをどのように処理するかということである。受信側は、破損したデータがいつ間違って受信されたかを常に把握することができるわけではないので、損失したデータ（消去）は、破損したデータ（誤り）よりも、しばしば処理しやすい。消去および／または誤りを訂正するために多数の誤り訂正符号が開発されてきた。一般に、使用される特定の符号は、データが送信されているチャネルの不忠実度と、送信されているデータの性質とに関する何らかの情報に基づいて選定される。たとえば、チャネルが長い周期の不忠実度を有することが知られている場合、バースト誤り符号がその適用例に最も適しているだろう。ごく短い、まれにしか起こらない誤りが予想される場合、単純なパリティ符号が最良であろう。
【０００６】
本明細書で使用する「ソースデータ」は、１つまたは複数の送信側において利用可能であるデータ、および受信機を使用して、誤りおよび／または消去を伴うまたは伴わない送信シーケンスからの復元によって取得されるデータなどを指す。本明細書で使用する「被符号化データ」は、搬送され、ソースデータを復元または取得するために使用され得るデータを指す。単純なケースでは、被符号化データはソースデータのコピーであるが、受信された被符号化データが、（誤りおよび／または消去により）送信された被符号化データとは異なる場合、この単純なケースでは、ソースデータは、ソースデータに関する追加のデータがなければ、完全には回復可能でないことがある。送信は空間または時間にわたって行われ得る。より複雑なケースでは、被符号化データは、変換においてソースデータに基づいて生成され、１つまたは複数の送信側から受信機に送信される。ソースデータが被符号化データの一部であることがわかる場合、符号化は「システマティック」であると言われる。システマティック符号化の単純な例では、被符号化データを形成するためにソースデータに関する冗長情報がソースデータの末尾に付加される。
【０００７】
また、本明細書で使用する「入力データ」は、ＦＥＣ（順方向誤り訂正）エンコーダ装置またはＦＥＣエンコーダモジュール、構成要素、ステップなど（「ＦＥＣエンコーダ」）の入力に存在するデータを指し、「出力データ」は、ＦＥＣエンコーダの出力に存在するデータを指す。相応して、出力データは、ＦＥＣデコーダの入力に存在することが予想され、ＦＥＣデコーダは、それが処理した出力データに基づいて、入力データ、またはその対応物を出力することが予想されるであろう。場合によっては、入力データはソースデータであるかまたはそれを含み、場合によっては、出力データは被符号化データであるかまたはそれを含む。他の場合には、送信側デバイスまたは送信側プログラムコードは２つ以上のＦＥＣエンコーダを備え得、すなわち、ソースデータは一連の複数のＦＥＣエンコーダ中で被符号化データに変換される。同様に、受信機において、受信された被符号化データからソースデータを生成するために適用される２つ以上のＦＥＣデコーダがあり得る。
【０００８】
データはシンボルに区分されると考えられ得る。エンコーダは、ソースシンボルまたは入力シンボルのシーケンスから被符号化シンボルまたは出力シンボルを生成するコンピュータシステム、デバイス、電子回路などであり、デコーダは、受信または復元された被符号化シンボルまたは出力シンボルからソースシンボルまたは入力シンボルのシーケンスを復元するカウンターパートである。エンコーダとデコーダとはチャネルによって時間的および／または空間的に分離されており、受信された被符号化シンボルは、対応する送信された被符号化シンボルとまったく同じではないことがあり、それらが送信されたシーケンスとまったく同じシーケンスで受信されないことがある。シンボルが実際にビットストリームに分解されるか否かにかかわらず、シンボルの「サイズ」はビットで測定され得、シンボルが２M個のシンボルのアルファベットから選択されたとき、シンボルはＭビットのサイズを有する。本明細書の多くの例では、シンボルはバイトで測定され、符号は２５６個の可能性の領域（２５６個の可能な８ビットパターンがある）を超えることがあるが、データ測定の異なる単位が使用され得ることと、様々な方法でデータを測定することがよく知られていることとを理解されたい。
【０００９】
Ｌｕｂｙ  Ｉには、計算効率的、メモリ効率的および帯域幅効率的な方法で誤り訂正に対処するための、連鎖反応（chain reaction）符号などの符号の使用が記載されている。連鎖反応エンコーダによって生成される被符号化シンボルの１つの特性は、受信機が、十分な被符号化シンボルが受信されるとすぐに元のファイルを復元することが可能であることである。詳細には、元のＫ個のソースシンボルを高い確率で復元するために、受信機は、約Ｋ＋Ａ個の被符号化シンボルを必要とする。
【００１０】
所与の状況についての「絶対受信オーバーヘッド」は値Ａによって表され、「相対受信オーバーヘッド」は比Ａ／Ｋとして計算され得る。絶対受信オーバーヘッドは、どのくらいの余分のデータが情報理論的最小データ量を超えて受信される必要があるかの測度であり、デコーダの信頼性に依存し得、ソースシンボルの数Ｋに応じて変動し得る。同様に、相対受信オーバーヘッドＡ／Ｋは、復元されているソースデータのサイズに対して、どのくらいの余分のデータが情報理論的最小データ量を超えて受信される必要があるかの測度であり、同じくデコーダの信頼性に依存し得、ソースシンボルの数Ｋに応じて変動し得る。
【００１１】
連鎖反応符号は、パケットベースネットワークを介した通信のために極めて有用である。しかしながら、それらは時々かなり計算集約的であり得る。連鎖反応符号または別のレートレス（rateless）符号を使用して符号化する動的エンコーダより前に静的エンコーダを使用してソースシンボルが符号化される場合、デコーダは、より頻繁にまたはより容易に復号することが可能であり得る。そのようなデコーダは、たとえば、Ｓｈｏｋｒｏｌｌａｈｉ  Ｉに示されている。そこに示されている例では、ソースシンボルは静的エンコーダへの入力シンボルであり、静的エンコーダは、動的エンコーダへの入力シンボルである出力シンボルを生成し、動的エンコーダは、被符号化シンボルである出力シンボルを生成し、ただし、動的エンコーダは、入力シンボルの数に対して固定レートでない量のいくつかの出力シンボルを生成することができるレートレスエンコーダである。静的エンコーダは、２つ以上の固定レートエンコーダを含み得る。たとえば、静的エンコーダは、ハミング（Hamming）エンコーダ、低密度パリティ検査（「ＬＤＰＣ：low-density parity-check」）エンコーダ、高密度パリティ検査（「ＨＤＰＣ：high-density parity-check」）エンコーダなどを含み得る。
【００１２】
連鎖反応符号は、いくつかのシンボルが受信シンボルからデコーダにおいて復元されるとき、それらのシンボルを使用して追加のシンボルを復元することが可能であり得、今度はその追加のシンボルを使用してさらに多くのシンボルを復元し得るという特性を有する。好ましくは、デコーダにおけるシンボル解決の連鎖反応は、受信シンボルのプールが使い果たされる前に所望のシンボルのすべてが復元されるように続くことができる。好ましくは、連鎖反応符号化および復号プロセスを実行することの計算複雑さは低い。
【００１３】
デコーダにおける復元プロセスは、どのシンボルが受信されたかを判断することと、元の入力シンボルを受信された被符号化シンボルにマッピングするであろう行列を作成することと、次いで行列を反転させ、反転した行列と受信された被符号化シンボルのベクトルとの行列乗算を実行することとに関与し得る。典型的なシステムでは、これのブルートフォース（brute force）実装形態は、過大な計算作業とメモリ要件とを消費し得る。もちろん、受信された被符号化シンボルの特定のセットについて、元の入力シンボルのすべてを復元することは不可能であり得るが、それが可能である場合でも、結果を計算することは極めて計算コストが高くなり得る。
【００１４】
Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩには、復号が２つのステップで行われる「非活動化（inactivation）」と呼ばれる手法が記載されている。第１のステップでは、デコーダは、どのような受信された被符号化シンボルが利用可能であるか、行列がどのように見え得るかを評価し、受信された被符号化シンボルを仮定すれば、連鎖反応プロセスを完了させることを可能にするであろう復号ステップのシーケンスを少なくとも概算的に判断する。第２のステップでは、デコーダは、復号ステップの判断されたシーケンスに従って連鎖反応復号を実行する。これは、メモリ効率的な方法（すなわち、よりメモリ非効率的なプロセスほどには演算のためのメモリストレージを必要としない方法）で行われ得る。
【００１５】
非活動化手法では、第１の復号ステップは、解決され得るいくつかの入力シンボルを判断するために行列またはそれの等価物を操作することと、判断がストールしたとき、入力シンボルのうちの１つを「非活動化シンボル」として指定し、非活動化シンボルが実際は解決されると仮定して判断プロセスを継続することと、次いで最後に、ガウス消去法、または元の復号行列よりもはるかに小さい行列を反転させるための何らかの他の方法を使用して非活動化シンボルを解決することとに関与する。その判断を使用して、元の入力シンボルのすべてまたは元の入力シンボルの好適なセットのいずれかであり得る復元された入力シンボルに到達するために、受信された被符号化シンボルに対して連鎖反応シーケンスが実行され得る。
【００１６】
限られたメモリおよび計算能力をもつ低電力デバイス中にデコーダがある場合など、あるいは許容できる絶対または相対受信オーバーヘッドに対する厳しい制約があるときなど、デコーダに対して厳しい制約を課するいくつかの適用例では、上記で説明した非活動化手法に比較して改善された方法が示され得る。
【００１７】
また、ファイルまたは大きいデータブロックを、最小サブシンボルサイズに対する制約を条件として、できるだけ少数のソースブロックに区分し、さらに、これを条件として、最大サブブロックサイズに対する制約を条件として、できるだけ少数のサブブロックに分割するための方法が有用であり得る。
【発明の概要】
【００１８】
本発明の態様によるエンコーダの一実施形態によれば、送信側におけるエンコーダ、送信側の中のエンコーダ、または送信側のためのエンコーダが、通信チャネルを介して１つまたは複数の送信側から１つまたは複数の受信機にソースシンボルの順序セットを送信し、エンコーダは、ソースシンボルから生成される複数の被符号化シンボルを含む、送られるべきデータを生成する。第１のステップでは、中間シンボルは、可逆である方法を使用してソースシンボルから生成され、すなわち、中間シンボルからソースシンボルを生成するための逆方法もある。別のステップでは、中間シンボルは、中間シンボルの第１のセットと中間シンボルの第２のセットとに区分され、少なくとも１つの中間シンボルが中間シンボルの第１のセット中にあり、少なくとも１つの中間シンボルが中間シンボルの第２のセット中にあり、少なくとも１つの被符号化シンボルが、２つのセットの各々からの少なくとも１つの中間シンボルから生成される。いくつかの変形態では、３つ以上のセットがある。
【００１９】
いくつかの実施形態では、一時的シンボルの第１のセットおよび第２のセットの値が生成され、一時的シンボルの第１のセットのための値が中間シンボルの第１のセットの値に依存し、一時的シンボルの第２のセットの値が中間シンボルの第２のセットの値に依存する。被符号化シンボルの値は、一時的シンボルの第１のセットおよび第２のセットから生成される。
【００２０】
いくつかの変形態では、生成され得る被符号化シンボルの数は、ソースシンボルの数とは無関係である。
【００２１】
また、デコーダ実施形態が提供される。本発明の態様によるデコーダの一実施形態によれば、受信機におけるデコーダ、受信機中のデコーダ、または受信機のためのデコーダが中間シンボルから生成された被符号化シンボルを受信し、中間シンボルは、可逆である方法を使用してソースシンボルから生成され、すなわち、中間シンボルからソースシンボルを生成するための逆方法もあり、中間シンボルのうちの少なくとも１つが永久的非活動シンボルに指定され、永久的非活動シンボルのうちにない中間シンボルのうちの少なくとも別の１つがある。デコーダは、受信された被符号化シンボルから中間シンボルのセットを復号し、デコーダは、少なくとも１つの永久的非活動シンボルを考慮に入れ、逆方法を使用して中間シンボルの復号されたセットからソースシンボルを生成する。
【００２２】
復号では、永久的非活動シンボルのスケジューリングを除外して、復号ステップがスケジュールされる。永久的非活動シンボルは、新規の方法または従来の方法を使用して解決され、さらには他の中間シンボルについて解決する際に使用され得る。永久的非活動シンボル（および使用する場合、他のオンザフライ非活動化）について解決する１つの手法は、非活動シンボルについて解決するためにガウス消去法を適用することであり得る。残りの中間シンボルのいくつかは、復元された永久的非活動シンボルの値と受信された被符号化シンボルの値とに基づいて復元される。
【００２３】
復号方法のいくつかの変形態では、永久的非活動シンボルは、符号化実施形態からの中間シンボルの第２のセットを備える。復号方法のいくつかの変形態では、永久的非活動シンボルは中間シンボルのサブセットを備え、対応する符号化方法はマルチステージ連鎖反応符号ではない。そのような符号化方法は、中間シンボルのサブセットのためのトルネード符号、リードソロモン符号、連鎖反応符号（Ｌｕｂｙ  Ｉに記載されている例）などのうちの１つまたは複数を含み得る。
【００２４】
中間シンボルは、符号化および復号のために使用され、ソースシンボルから中間シンボルを生成するための方法および対応する逆方法は、復号可能性など、パフォーマンス特性の所望のセットのために示される。いくつかの実施形態では、中間シンボルはソースシンボルを備える。いくつかの実施形態では、中間シンボルは、ソースシンボルから生成される冗長シンボルとともにソースシンボルを備え、冗長シンボルは、連鎖反応シンボル、ＬＤＰＣシンボル、ＨＤＰＣシンボルまたは他のタイプの冗長シンボルであり得る。代替的に、中間シンボルは、シンボル間の規定関係、たとえば、中間シンボルとソースシンボルとの間の関係、ならびに中間シンボル間の追加のＬＤＰＣおよびＨＤＰＣ関係に基づき得、復号方法は、規定関係に基づいてソースシンボルから中間シンボルを生成するために使用される。
【００２５】
電子回路によって、またはプログラミング命令を実行し、符号化および／または復号を実装するために適切な命令プログラムコードを有する処理デバイスによって、それらの方法およびシステムが実装され得る。
【００２６】
多数の利益が本発明によって達成される。たとえば、特定の実施形態において、チャネルを介した送信のためにデータを符号化する計算費用は低減される。別の特定の実施形態では、そのようなデータを復号する計算費用は低減される。別の特定の実施形態では、絶対および相対受信オーバーヘッドは実質的に低減される。実施形態に応じて、これらの利益の１つまたは複数が達成され得る。これらおよび他の利益は、本願明細書全体にわたって、特に以下に、より詳細に与えられる。
【００２７】
本明細書の残りの部分および添付の図面を参照すれば、本明細書で開示する本発明の性質および利点をさらに理解することができる。
【図面の簡単な説明】
【００２８】
【図１】他の特徴および要素とともに、永久的非活動化を含むマルチステージコーディングを使用する通信システムのブロック図。
【図２】本明細書で様々な他の図において使用される変数、アレイなどのテーブルの図。
【図３】図１に示すエンコーダの特定の実施形態のブロック図。
【図４】図３の動的エンコーダをより詳細に示すブロック図。
【図５】永久的非活動化（ＰＩ：permanent inactivation）符号化プロセスを示すフローチャート。
【図６】動的符号化プロセスを示すフローチャート。
【図７】シンボル計算のための重みを計算する演算のフローチャート。
【図８】ルックアップ値に基づいてシンボルの度数を判断するために使用可能な、メモリに記憶され得るテーブルを示す図。
【図９】符号化または復号プロセスにおいて使用される行列を示す図。
【図１０】特定の最小多項式について、図９に示す行列の一部を表す式を示す図。
【図１１】符号化または復号において使用するアレイをセットアップするためのプロセスを示すフローチャート。
【図１２】Ｒ個の静的シンボルを表す部分行列ＳＥ、またはデコーダによって知られる式を使用して、受信された被符号化シンボルを表すアレイＤ（）から、復元されたソースシンボルを表すアレイＣ（）を復元するためにデコーダによって解かれるべき式のセットの行列表現を示す図。
【図１３】ＯＴＦ非活動化を使用して、図１２の行列の行／列置換から生じる行列を示す図。
【図１４】図１２中の行列を生成するためのプロセスを表すブロック図。
【図１５】部分行列ＳＥと永久的非活動シンボルに対応する部分行列とを使用して、受信された被符号化シンボルを表すアレイＤ（）から、復元されたソースシンボルを表すアレイＣ（）を復元するためにデコーダによって解かれるべき式のセットの行列表現を示す図。
【図１６】図１２の行列または図１５の行列において使用され得るＬＴ部分行列を生成するためのプロセスを示すフローチャート。
【図１７】図１５の行列において使用され得るＰＩ部分行列を生成するためのプロセスを示すフローチャート。
【図１８】行列生成器のブロック図。
【図１９】ＳＥ部分行列を生成するためのプロセスを示すフローチャート。
【図２０】ＰＩ部分行列を生成するためのプロセスを示すフローチャート。
【図２１】デコーダにおいて復元されたシンボルについて解決するためのプロセスを示すフローチャート。
【図２２】置換後に、受信された被符号化シンボルを表すアレイＤ（）から、復元されたソースシンボルを表すアレイＣ（）を復元するためにデコーダによって解かれるべき式のセットの行列表現を示す図。
【図２３】図２６に示す行列に対応する、デコーダによって解かれるべき式のセットの行列表現を示す図。
【図２４】復号プロセスの一部として使用可能な行列表現を示す図。
【図２５】復号プロセスの別の一部として使用可能な行列表現を示す図。
【図２６】部分的解決後にデコーダによって解かれるべき式のセットの行列表現を示す図。
【図２７】デコーダにおいて復元されたシンボルについて解決するための別のプロセスを示すフローチャート。
【図２８】デコーダによって解かれるべき式のセットの行列表現を示す図。
【図２９】デコーダによって解かれるべき式のセットの行列表現を示す図。
【図３０】プログラムストアに記憶され、プロセッサによって実行されるハードウェアモジュール、ソフトウェアモジュール、またはプログラムコードの部分として、場合によっては、図に示すように分離されていないコードの集合的なユニットとして実装され得る例示的な符号化システムを示す図。
【図３１】プログラムストアに記憶され、プロセッサによって実行されるハードウェアモジュール、ソフトウェアモジュール、またはプログラムコードの部分として、場合によっては、図に示すように分離されていないコードの集合的なユニットとして実装され得る例示的な復号システムを示す図。
【発明を実施するための形態】
【００２９】
付録Ａとして添付されているのは、データオブジェクトの信頼できる配信に対するエンコーダ／デコーダシステム、誤り訂正方式、および適用例の特定の実施形態のためのコード仕様であり、時々本発明の詳細が使用されており、システマティックエンコーダ／デコーダがオブジェクト配信トランスポートにおいてどのように使用され得るかの仕様をも含む。付録Ａ中で説明されている特定の実施形態は本発明の限定的な例ではないこと、および本発明のいくつかの態様は付録Ａの教示を使用し得るが、他の態様は使用し得ないことを理解されたい。また、付録Ａ中の限定的な記載が特定の実施形態の要件に関して限定的であり得、そのような限定的な記載は、請求される本発明に関係することも関係しないこともあり、したがって、クレームの文言は、そのような限定的な記載によって限定される必要はないことを理解されたい。
【００３０】
本明細書で参照するエンコーダおよびデコーダの部分を実装するための詳細は、Ｌｕｂｙ  Ｉ、Ｌｕｂｙ  ＩＩ、Ｓｈｏｋｒｏｌｌａｈｉ  Ｉ、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩ、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩＩ、Ｌｕｂｙ  ＩＩＩ、およびＳｈｏｋｒｏｌｌａｈｉ  ＩＶによって与えられ、簡潔のためにここで完全には繰り返さない。それらの開示全体は、すべての目的のために参照により本明細書に組み込まれ、本発明には本明細書中の実装形態が必要であるわけではなく、別段に規定されていない限り、多くの他の変形形態、変更形態、または代替形態も使用され得ることを理解されたい。
【００３１】
マルチステージ符号化は、本明細書で説明するように、ソースデータを複数のステージで符号化する。常にではないが、一般に、第１のステージは、ソースデータに所定量の冗長性を追加する。次いで、第２のステージは、連鎖反応符号などを使用して、元のソースデータと、第１のステージの符号化によって計算された冗長シンボルとから被符号化シンボルを生成する。１つの特定の実施形態では、受信データは、最初に連鎖反応復号プロセスを使用して復号される。そのプロセスが元のデータを完全に復元することに成功しなかった場合、第２の復号ステップが適用され得る。
【００３２】
本明細書で教示する実施形態の一部は、多くの他のタイプの符号、たとえば、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ（ＲＦＣ）５１７０に記載されている符号（以下、「ＩＥＴＦ  ＬＤＰＣ符号」）、ならびに米国特許第６，０７３，２５０号、６，０８１，９０９号および６，１６３，８７０号に記載されている符号（以下、「トルネード符号」）に適用され得、それらのタイプの符号の信頼性および／またはＣＰＵおよび／またはメモリパフォーマンスが改善されることになる。
【００３３】
本明細書で教示するいくつかの実施形態の１つの利点は、連鎖反応コーディング単独と比較して、被符号化シンボルを生成するのにより少ない算術演算が必要であることである。第１のステージの符号化と第２のステージの符号化とを含むいくつかの特定の実施形態の別の利点は、第１のステージの符号化と第２のステージの符号化とが、別の時間においておよび／または別々のデバイスによって行われ得、したがって、計算負荷を分割し、全体的な計算負荷、また、メモリサイズおよびアクセスパターン要件を最小限に抑えることである。マルチステージ符号化の実施形態では、第１のステージの符号化中に入力ファイルから冗長シンボルが生成される。これらの実施形態では、第２のステージの符号化において、入力ファイルと冗長シンボルとの組合せから被符号化シンボルが生成される。これらの実施形態のうちの一部では、必要に応じて被符号化シンボルが生成され得る。第２のステージが連鎖反応符号化を備える実施形態では、各被符号化シンボルは、他の被符号化シンボルがどのように生成されるかを顧慮せずに生成され得る。生成された後、これらの被符号化シンボルは、パケットに入れられ、それらの宛先に送信され得、各パケットは１つまたは複数の被符号化シンボルを含んでいる。代わりにまたはその上、非パケット化送信技法が使用され得る。
【００３４】
本明細書で使用する「ファイル」という用語は、１つまたは複数のソースに記憶されており、ユニットとして１つまたは複数の宛先に配信されるべきデータを指す。したがって、ファイルサーバまたはコンピュータストレージデバイスからのドキュメント、画像、およびファイルはすべて、配信され得る「ファイル」の例である。ファイルは、（ハードディスクに記憶された１メガバイト画像など）既知のサイズであるか、または（ストリーミングソースの出力から取られたファイルなど）未知のサイズであり得る。どちらにしても、ファイルは、各ソースシンボルがファイル中の位置と値とを有する、ソースシンボルのシーケンスである。「ファイル」はまた、ストリーミングソースの短い部分を指すために使用され得、すなわち、データストリームは１秒区間に区分され得、そのような各１秒区間内のソースデータブロックは「ファイル」であると考えられ得る。別の例として、ビデオストリーミングソースからのデータブロックは、たとえばビデオストリームをプレイアウトすることができるビデオシステムによって定義されたそのデータの優先度に基づいて複数の部分にさらに区分され得、各ブロックの各部分は「ファイル」であると考えられ得る。したがって、「ファイル」という用語は、一般的に使用され、広範囲にわたって限定するものではない。
【００３５】
本明細書で使用するソースシンボルは、送信または搬送されるべきデータを表し、被符号化シンボルは、ソースシンボルの信頼できる受信および／または再生を可能にするために、通信ネットワーク上で搬送されるかまたは記憶されたソースシンボルに基づいて生成されたデータを表す。中間シンボルは、符号化プロセスまたは復号プロセスの中間ステップ中に使用または生成されるシンボルを表し、一般に、ソースシンボルから中間シンボルを生成するための方法と、中間シンボルからソースシンボルを生成するための対応する逆方法とが存在する。入力シンボルは、符号化または復号のプロセス中に１つまたは複数のステップに入力されるデータを表し、出力シンボルは、符号化または復号のプロセス中に１つまたは複数のステップから出力されるデータを表す。
【００３６】
多くの実施形態において、これらの異なるタイプまたはラベルのシンボルは、同じであるか、または少なくとも部分的に他のタイプのシンボルから構成され得、いくつかの例では、これらの用語は互換的に使用される。一例では、送信されるべきファイルは、各文字がソースシンボルと見なされる１０００文字のテキストファイルであると仮定する。それらの１０００個のソースシンボルがそのままエンコーダに与えられた場合、エンコーダは、送信される被符号化シンボルを出力し、ソースシンボルは入力シンボルでもある。ただし、第１のステップにおいて１０００個のソースシンボルが１０００個の（またはより多いもしくはより少ない）中間シンボルに変換され、第２のステップにおいてそれらの中間シンボルがエンコーダに与えられて被符号化シンボルを生成する実施形態では、第１のステップにおいて、ソースシンボルは入力シンボルであり、中間シンボルは出力シンボルであり、第２のステップにおいて、中間シンボルは入力シンボルであり、被符号化シンボルは出力シンボルであるが、ソースシンボルは、この２ステップエンコーダへの全体的な入力シンボルであり、被符号化シンボルは、この２ステップエンコーダの全体的な出力シンボルである。この例では、エンコーダがシステマティックエンコーダである場合、被符号化シンボルは、中間シンボルから生成されたリペアシンボルとともにソースシンボルを備え得るが、中間シンボルは、ソースシンボルと被符号化シンボルの両方とは異なる。代わりに、この例において、エンコーダが非システマティックエンコーダである場合、中間シンボルは、第１のステップにおいてたとえばＬＤＰＣおよび／またはＨＤＰＣエンコーダを使用してソースシンボルから生成された冗長シンボルとともにソースシンボルを備え得るが、被符号化シンボルは、ソースシンボルと中間シンボルの両方とは異なる。
【００３７】
他の例では、より多くのシンボルが存在し、各シンボルは２つ以上の文字を表す。いずれの場合も、送信機中にソース中間（source-to-intermediate）シンボル変換がある場合、受信機は、その逆として対応する中間ソース（intermediate-to-source）シンボル変換を有し得る。
【００３８】
送信とは、ファイルを配信するために、チャネルを通してデータを１つまたは複数の送信側から１つまたは複数の受信側に送信するプロセスである。送信側はまた、エンコーダと呼ばれることがある。１つの送信側が、完全なチャネルによって任意の数の受信側に接続されている場合、受信データは、すべてのデータが正しく受信されるので、ソースファイルの正確なコピーになることができる。ここで、チャネルが完全ではないことを仮定し、それは、たいていの現実世界のチャネルの実情である。多くのチャネル欠陥のうち、注目する２つの欠陥は、データ消去と、（データ消去の特殊な場合として扱われ得る）データ不完全性とである。データ消去は、チャネルからデータが損失または欠落したときに発生する。データ不完全性は、データの一部が受信側を通過してしまうまで受信側がデータを受信し始めないとき、送信が終了する前に受信側がデータを受信することを停止したとき、受信側が送信データの一部分のみを受信することを選定したとき、および／または受信側がデータを受信することを間欠的に停止および再開したときに発生する。データ不完全性の一例として、移動中の衛星送信側が、ソースファイルを表すデータを送信しており、受信側がレンジ内に入る前に送信を開始することがあり得る。受信側がレンジ内に入ると、衛星がレンジ外に移動するまでデータが受信され得、衛星がレンジ外に移動した時点で、受信側は、レンジ内に移動した別の衛星によって送信されている同じ入力ファイルに関するデータを受信し始めるために、受信側のサテライトディッシュを向け直すことができる（その時間中、受信側はデータを受信していない）。本明細書を読めば明らかであるように、受信側が全時間にレンジ内にあったが、受信側がデータを受信し始めた時点まで、チャネルからすべてのデータが損失したかのように、受信側はデータ不完全性を扱うことができる（また受信側は同じ問題を有する）ので、データ不完全性はデータ消去の特殊な場合である。また、通信システム設計においてよく知られているように、検出可能な誤りは、検出可能な誤りを有するすべてのデータブロックまたはシンボルを単に欠落したことによる消去と等価であると考えられ得る。
【００３９】
いくつかの通信システムでは、受信側は、複数の送信側によって、または複数の接続を使用する１つの送信側によって生成されたデータを受信する。たとえば、ダウンロードを高速化するために、受信側は、同じファイルに関するデータを送信するために２つ以上の送信側に同時に接続し得る。別の例として、マルチキャスト送信では、複数のマルチキャストデータストリームが送信されるので、受信側は、これらのストリームのうちの１つまたは複数に接続して、アグリゲート送信レートを、受信側を送信側に接続するチャネルの帯域幅に一致させることが可能になり得る。すべてのそのような場合において、問題は、すべての送信データが受信側に対して独立に使用されること、すなわち、異なるストリームについて送信レートが非常に異なるとき、および恣意的な損失パターンがあるときでも、複数のソースデータがストリーム間で冗長でないことを保証することである。
【００４０】
概して、通信チャネルは、データ送信のために送信側と受信側とを接続するチャネルである。チャネルがデータを入手したときにチャネルがデータを送信側から受信側に移動させる場合、通信チャネルはリアルタイムチャネルであり得、あるいは通信チャネルは、送信側から受信側へのデータ輸送においてデータの一部または全部を記憶するストレージチャネルであり得る。後者の例は、ディスクストレージまたは他のストレージデバイスである。その例では、データを生成するプログラムまたはデバイスは、データをストレージデバイスに送信する送信側として考えられ得る。受信側は、ストレージデバイスからデータを読み込むプログラムまたはデバイスである。ストレージデバイス上にデータを得るために送信側が使用する機構と、ストレージデバイス自体と、ストレージデバイスからデータを得るために受信側が使用する機構とが、集合的にチャネルを形成する。それらの機構またはストレージデバイスがデータを損失し得る可能性がある場合、それは、通信チャネルにおけるデータ消去として扱われるであろう。
【００４１】
送信側と受信側とが、シンボルが消去され得る通信チャネルによって分離されているとき、入力ファイルの正確なコピーを送信するのではなく、消去の復元を支援する入力ファイルから生成されたデータを送信することが好ましい。エンコーダは、そのタスクを処理する回路、デバイス、モジュール、またはコードセグメントである。エンコーダの演算を見る１つの方法は、エンコーダがソースシンボルから被符号化シンボルを生成することであり、ソースシンボル値のシーケンスは入力ファイルを表す。したがって、各ソースシンボルは、入力ファイル中の位置と値とを有することになる。デコーダは、受信側によって受信された被符号化シンボルからソースシンボルを再構成する回路、デバイス、モジュールまたはコードセグメントである。マルチステージコーディングでは、エンコーダとデコーダとは、時々、各々が異なるタスクを実行するサブモジュールにさらに分割される。
【００４２】
マルチステージコーディングシステムの実施形態では、エンコーダとデコーダとは、各々が異なるタスクを実行するサブモジュールにさらに分割され得る。たとえば、いくつかの実施形態では、エンコーダは、本明細書において静的エンコーダおよび動的エンコーダと呼ぶものを備える。本明細書で使用する「静的エンコーダ」は、ソースシンボルのセットからいくつかの冗長シンボルを生成するエンコーダであって、冗長シンボルの数が符号化より前に判断される、エンコーダである。マルチステージコーディングシステムにおいて静的符号化が使用されるとき、ソースシンボルと、静的エンコーダを使用してソースシンボルから生成された冗長シンボルとの組合せは、しばしば中間シンボルと呼ばれる。潜在的な静的符号化符号の例には、リードソロモン符号、トルネード符号、ハミング符号、ＩＥＴＦ  ＬＤＰＣ符号などのＬＤＰＣ符号がある。「静的デコーダ」という用語は、本明細書では、静的エンコーダによって符号化されたデータを復号することができるデコーダを指すために使用される。
【００４３】
本明細書で使用する「動的エンコーダ」は、入力シンボルのセットから被符号化シンボルを生成するエンコーダであって、可能な被符号化シンボルの数が入力シンボルの数とは無関係であり、生成されるべき被符号化シンボルの数が固定である必要がない、エンコーダである。しばしば、マルチステージ符号では、入力シンボルは、静的符号を使用して生成された中間シンボルであり、被符号化シンボルは、動的エンコーダを使用して中間シンボルから生成される。動的エンコーダの一例は、Ｌｕｂｙ  ＩおよびＬｕｂｙ  ＩＩにおいて教示されているエンコーダなど、連鎖反応エンコーダである。「動的デコーダ」という用語は、本明細書では、動的エンコーダによって符号化されたデータを復号することができるデコーダを指すために使用される。
【００４４】
いくつかの実施形態では、マルチステージ符号でありシステマティックである符号化は、中間シンボルの間で静的エンコーダによって定義され、および中間シンボルとソースシンボルとの間で動的エンコーダによって定義された関係に基づいて中間シンボル値を取得するためにソースシンボルに適用された復号プロセスを使用し、次いで、動的エンコーダが、中間シンボルから追加の被符号化シンボルまたはリペアシンボルを生成するために使用される。同様に、対応するデコーダは、被符号化シンボルを受信し、中間シンボルの間で静的エンコーダによって定義され、および中間シンボルと受信された被符号化シンボルとの間で動的エンコーダによって定義された関係に基づいて中間シンボル値を受信された被符号化シンボルから復号する復号プロセスを有し、次いで、動的エンコーダが、中間シンボルから消失したソースシンボルを生成するために使用される。
【００４５】
マルチステージコーディングの実施形態は、特定のタイプのシンボルに限定される必要はない。一般に、シンボルの値は、何らかの正の整数Ｍについて、２M個のシンボルのアルファベットから選択される。そのような場合、ソースシンボルは、入力ファイルからのデータのＭビットのシーケンスによって表され得る。Ｍの値は、しばしば、たとえば、アプリケーションの使用、通信チャネル、および／または被符号化シンボルのサイズに基づいて決定される。さらに、被符号化シンボルのサイズは、しばしば、アプリケーション、チャネル、および／またはソースシンボルのサイズに基づいて決定される。場合によっては、被符号化シンボル値とソースシンボル値とが同じサイズであった（すなわち、同じビット数によって表せるかまたは同じアルファベットから選択された）場合、コーディングプロセスは簡略化され得る。そのような場合、被符号化シンボル値サイズが制限されているとき、ソースシンボル値サイズは制限される。たとえば、被符号化シンボルを、制限されたサイズのパケットに入れることが所望され得る。被符号化シンボルに関連する鍵に関する何らかのデータが、受信機において鍵を復元するために送信されるべき場合、被符号化シンボルは、好ましくは、被符号化シンボル値と鍵に関するデータとを１パケット中に収容するために十分小さくなるであろう。
【００４６】
一例として、入力ファイルが多メガバイトファイルである場合、その入力ファイルは、数千、数万、または数十万個のソースシンボルに分解され得、各ソースシンボルは、数千、数百、またはわずか数バイトを符号化する。別の例として、パケットベースインターネットチャネルの場合、１０２４バイトのサイズのペイロードをもつパケットが適切であり得る（１バイトは８ビットである）。この例では、各パケットが１つの被符号化シンボルと８バイトの補助情報とを含んでいると仮定すると、８１２８ビットの被符号化シンボルサイズ（（１０２４−８）＊８）が適切になるであろう。したがって、ソースシンボルサイズは、Ｍ＝（１０２４−８）＊８、すなわち８１２８ビットとして選定され得る。別の例として、いくつかの衛星システムがＭＰＥＧパケット規格を使用し、各パケットのペイロードが１８８バイトを備える。その例では、各パケットが１つの被符号化シンボルと４バイトの補助情報とを含んでいると仮定すると、１４７２ビットの被符号化シンボルサイズ（（１８８−４）＊８）が適切になるであろう。したがって、ソースシンボルサイズは、Ｍ＝（１８８−４）＊８、すなわち１４７２ビットとして選定され得る。マルチステージコーディングを使用した汎用通信システムでは、ソースシンボルサイズ（すなわち、ソースシンボルによって符号化されたビット数Ｍ）などの特定用途向けパラメータは、アプリケーションによって設定された変数であり得る。
【００４７】
各被符号化シンボルは値を有する。以下で考察する１つの好適な実施形態では、各被符号化シンボルはまた、「鍵」と呼ばれる識別子をそれに関連付けている。好ましくは、受信側が１つの被符号化シンボルを他の被符号化シンボルと区別することを可能にするために、各被符号化シンボルの鍵は受信側によって容易に判断され得る。好ましくは、ある被符号化シンボルの鍵は、すべての他の被符号化シンボルの鍵とは異なる。従来技術において説明されている様々な形式のキーイングが存在する。たとえば、Ｌｕｂｙ  Ｉは、本発明の実施形態において採用され得る様々な形式のキーイングについて説明している。付録Ａで説明している実施形態など、他の好適な実施形態では、被符号化シンボルの鍵は、「被符号化シンボル識別子（Encoded Symbol Identifier）」、または「符号化シンボル識別子（Encoding Symbol Identifier）」、またはより簡単に「ＥＳＩ」と呼ばれる。
【００４８】
データ消去が予想される場合、またはちょうど送信が開始および終了したときに受信側が受信を開始および終了しない場合、マルチステージコーディングは特に有用である。後者の条件は、本明細書では「データ不完全性」と呼ぶ。消去イベントに関して、マルチステージコーディングは、Ｌｕｂｙ  Ｉにおいて教示されている連鎖反応コーディングの利益の多くを共有する。特に、マルチステージ被符号化シンボルは情報付加的であり、したがって、所望の正確度まで入力ファイルを復元するために任意の好適な数のパケットが使用され得る。マルチステージコーディングを用いて生成された被符号化シンボルは情報付加的であるので、マルチステージコーディングが使用されたとき、これらの条件は通信プロセスに悪影響を及ぼさない。たとえば、データ消去を引き起こすノイズバーストにより１００個のパケットが損失した場合、そのバースト後に、消去されたパケットの損失分を置き換えるために追加の１００個のパケットがピックアップされ得る。送信機が送信を開始したときに受信機が送信機に同調しなかったために数千個のパケットが損失した場合、受信機は、他の送信期間から、さらには別の送信機から、それらの数千個のパケットをただピックアップすることができる。マルチステージコーディングでは、受信機は、パケットの特定のセットをピックアップするように制約されず、したがって、受信機は、１つの送信機からいくつかのパケットを受信し、別の送信機に切り替え、いくつかのパケットを損失し、所与の送信の始端または終端を消失し、それでも入力ファイルを復元することができる。受信機送信機協調なしに送信に入り、離れる能力は、通信プロセスを簡略化するのに役立つ。
【００４９】
いくつかの実施形態では、マルチステージコーディングを使用してファイルを送信することは、入力ファイルからソースシンボルを生成、形成または抽出することと、冗長シンボルを計算することと、ソースシンボルと冗長シンボルとを１つまたは複数の被符号化シンボルに符号化することであって、各被符号化シンボルが、すべての他の被符号化シンボルとは無関係にその各被符号化シンボルの鍵に基づいて生成される、符号化することと、チャネルを介して１つまたは複数の受信側に被符号化シンボルを送信することとを含むことができる。さらに、いくつかの実施形態では、マルチステージコーディングを使用して入力ファイルのコピーを受信（し、再構成）することは、より多くのデータストリームのうちの１つから被符号化シンボルのいくつかのセットまたはサブセットを受信することと、受信した被符号化シンボルの値と鍵とからソースシンボルを復号することとを含むことができる。
【００５０】
システマティック符号および非システマティック符号
システマティック符号は、ソースシンボルが、送信され得る被符号化シンボルの中にある符号である。この場合、被符号化シンボルは、ソースシンボルと、ソースシンボルから生成されたリペアシンボルとも呼ばれる冗長シンボルとから構成される。システマティック符号は、様々な理由で、多くの適用例では非システマティック符号よりも好ましい。たとえば、ファイル配信適用例では、リペアデータを生成するプロセスが何らかの時間量を取り得る場合、リペアデータを生成するためにデータが使用されている間、連続順序でそのデータを送信し始めることが可能であることが有用である。別の例として、多くの適用例は、１つのチャネルに元のソースデータを連続順序でそれの無変更形式で送り、別のチャネルにリペアデータを送ることを選好する。このことの１つの典型的な理由は、ソースデータチャネルのみに入るＦＥＣ復号を組み込まないレガシー受信機をサポートすることと、同時に、ソースデータチャネルとリペアデータチャネルの両方に入るＦＥＣ復号を組み込んだ拡張受信機により良いエクスペリエンスを提供することの両方である。
【００５１】
これらおよび関係するタイプの適用例では、受信機によって受信されたソースシンボル中の損失パターンおよび損失の部分が、受信されたリペアシンボル間で遭遇される損失パターンおよび損失の部分と極めて異なる場合が時々あり得る。たとえば、ソースシンボルがリペアシンボルより前に送られたとき、チャネルのバースト的損失状態により、ソースシンボル中の損失の部分およびパターンは、リペアシンボル中の損失の対応する部分およびパターンとは極めて異なり得、ソースシンボル中の損失のパターンは、損失が一様にランダムであった場合よりも典型的であり得たものとはかけ離れ得る。別の例として、ソースデータが１つのチャネル上で送られ、リペアデータが別のチャネル上で送られるとき、それらの２つのチャネル上で極めて異なる損失状態が存在し得る。したがって、様々なタイプの損失状態の下でうまく動作するシステマティックＦＥＣ符号を有することが望ましい。
【００５２】
本明細書の例は、（出力または被符号化シンボルがソースまたは入力シンボルを含む）システマティック符号、あるいは非システマティック符号に言及しているが、本明細書の教示は、別段に規定されていない限り、両方に適用可能であると考えられるべきである。Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩＩでは、非システマティック符号のロバストネス性が、そのように構築されたシステマティック符号によって維持されるような方法で、非システマティック連鎖反応符号をシステマティック符号に変換するための方法を教示している。
【００５３】
特に、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩＩにおいて教示されている方法を使用する場合、構築されたシステマティック符号は、損失したソースシンボルと、損失したリペアシンボルとの間でデコーダによる復元可能性に関してほとんど区別がない性質を有し、すなわち、復号復元確率は、リペアシンボル中の損失の比率と比較して、ソースシンボル中の損失の比率とはほとんど無関係に所与の総損失量に対して本質的に同じである。さらに、被符号化シンボル中の損失のパターンは、復号復元確率に有意に影響を及ぼさない。比較において、トルネード符号またはＩＥＴＦ  ＬＤＰＣ符号について記述されている構成など、他のシステマティック符号の構成では、多くの場合、損失したソースシンボルと損失したリペアシンボルとの間にデコーダによる復元可能性に関して強い区別がある、すなわち、リペアシンボルの間の損失の比率と比較してソースシンボルの間の損失の比率に応じて、復号復元確率は所与の総損失量に対して同じものに対して大きく異なり得る。さらに、被符号化シンボル中の損失のパターンは、復号復元確率に強い影響を有し得る。被符号化シンボルの損失が被符号化シンボルのすべての間で一様にランダムである場合、トルネード符号とＩＥＴＦ  ＬＤＰＣ符号とは適度に良好な復元特性を有するが、復元特性は、損失モデルが一様ランダム損失からそれるにつれて劣化する。したがって、この意味において、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩＩにおいて教示されている実施形態は、システマティック符号の他の構成よりも利点を有する。
【００５４】
損失したソースシンボルと損失したリペアシンボルとの比率に応じて、および損失パターンに応じてデコーダによる復元可能性に関して強い影響がある特性をもつＦＥＣ符号の場合、この特性を克服するための１つの手法は、その手法が適用可能であるときは、被符号化シンボルを一様にランダムな順序で送ること、すなわち、ソースシンボルとリペアシンボルとの組合せを一様にランダムな順序で送り、このようにして、ソースシンボルをリペアシンボル間でランダムに点在させることである。ランダム順序で被符号化シンボルを送ることは、チャネル損失モデルが何であろうと、また損失がバースト的であるか、一様にランダムであるか、または何らかの他のタイプの損失であるかにかかわらず、被符号化シンボルに対する損失は依然としてランダムであるという利点を有する。ただし、上記のように、この手法は、いくつかの適用例、たとえば、リペアシンボルの前にソースシンボルを順々に送ることが望ましい適用例、または、ソースシンボルが、リペアシンボルとは異なるチャネル上で送られる適用例では望ましくない。
【００５５】
そのような場合、被符号化シンボル中の損失のパターンがデコーダの復元特性にあまり影響を及ぼさないシステマティック符号の構成が望まれ、いくつかの例を本明細書で提供する。
【００５６】
本明細書で使用する「ランダム」および「擬似ランダム」は、しばしば等価および／または交換可能であり、コンテキストに依存し得る。たとえば、ランダム損失は、真にランダムイベントであり得る、どのシンボルがチャネルによって損失したかを指し得、一方、シンボルネイバーのランダム選択は、実際は非ランダムプロセスによる繰り返し可能な擬似ランダム選択であり得るが、それは、真ランダム選択の場合がそうであるように同じまたは同様の特性または挙動を有する。明示的にまたはコンテキストによって別段に規定されていない限り、あるものをランダムとして特徴づけることは、擬似ランダム性を除外するものではない。
【００５７】
そのようなシステマティックＦＥＣエンコーダに対する１つの手法では、ソースシンボルは、複数のエンコーダサブブロックまたはサブプロセスを含むエンコーダによって取得され、それらの複数のエンコーダサブブロックまたはサブプロセスのうちの１つは、別のサブブロックまたはサブプロセスへの入力シンボルである中間シンボルを生成するデコーダとして動作する。次いで、中間シンボルは、被符号化シンボルが、（追加の冗長シンボルとともに）１つの一貫したプロセスから生成されたソースシンボルを含むように、中間シンボルを被符号化シンボルに符号化する別のサブブロックまたはサブプロセスに適用され、それによって、被符号化シンボルセット用にソースシンボルを得るために１つのプロセス（たとえば、コピー）を使用し、被符号化シンボルセット用に冗長シンボルを得るために別のプロセスを使用するシステマティックエンコーダであるエンコーダに勝る、ロバストネスの利益と他の利益とを提供する。
【００５８】
出力符号化は、連鎖反応エンコーダ、静的エンコーダまたは他の変形態であり得る。付録Ａは、システマティック符号実施形態について説明している。本開示を読めば、当業者は、同じくシステマティック符号であるが、より良い復元特性を有するこれらの符号の新しいバージョンを生み出すために、トルネード符号およびＩＥＴＦ  ＬＤＰＣ符号などのシステマティック符号に適用するようにＳｈｏｋｒｏｌｌａｈｉ  ＩＩＩの教示を容易に拡張することが可能であるはずである。特に、以下で説明する概略的な方法を適用することによって得られたこれらの符号の新しいバージョンは、リペアシンボル中の損失の比率と比較してソースシンボル中の損失の比率が、復号復元確率に有意に影響を及ぼさず、さらに、損失のパターンが復号復元確率に有意に影響を及ぼさないという特性を有するように拡張される。したがって、これらの符号は、ソースシンボルとリペアシンボルとの間の異なる部分損失量または異なる損失パターンによって強く影響されない復元特性をもつシステマティックＦＥＣ符号の使用を必要とする上記で説明した適用例において効果的に使用され得る。
【００５９】
新しい符号化方法は、概して、新しい拡張システマティックＦＥＣ符号のための総合的符号化方法を生み出すために、システマティックＦＥＣ符号、非システマティックＦＥＣ符号、固定レートＦＥＣ符号および連鎖反応ＦＥＣ符号の符号化に適用され得る。また、適用され得る対応する新しい復号方法が存在する。
【００６０】
エンコーダ中のデコーダの例
次に、エンコーダ中のデコーダの一例を与える。
【００６１】
符号化方法Ｅが、Ｋ個のソースシンボルからＮ個の被符号化シンボルを生成する固定レート（非システマティックまたはシステマティック）ＦＥＣ符号Ｅのために（送信機または他の場所における）エンコーダによって使用される符号化方法であるとし、ただし、Ｎは少なくともＫである。同様に、復号方法Ｅが、受信機または他の場所におけるデコーダによって使用される、ＦＥＣ符号Ｅのための対応する復号方法であるとする。
【００６２】
ＦＥＣ符号Ｅは、Ｎ個の被符号化シンボルのうちのＫ個のランダムセットが、復号方法Ｅを使用して元のＫ個のソースシンボルを妥当な確率で復元するのに十分であるという特性を有すると仮定し、ただし、妥当な確率は、たとえば、確率１／２であり得る。妥当な確率は、使用法またはアプリケーションによる何らかの要件セットであり得、１／２以外の値であり得る。特定の符号の構成は、特定の復元確率に固有である必要はないが、アプリケーションとシステムとは、ロバストネスのそれらの特定のレベルに設計され得ることを理解されたい。いくつかの事例において、復元確率は、Ｋ個よりも多くのシンボルを考察し、次いで、復号プロセスを使用して、これらの考察されたシンボルの中から正常な復号を可能にするＫ個のシンボルのセットを判断することによって高められ得る。
【００６３】
ＦＥＣ符号Ｅのために、ＥＳＩ（被符号化シンボル識別子）が各被符号化シンボルに関連付けられ、ＥＳＩはその被符号化シンボルを識別すると仮定する。一般性の損失なしに、ＥＳＩは、本明細書では、０，１，２，．．．，Ｎ−１で標示される。
【００６４】
ＦＥＣ符号Ｅのための方法を使用して生成されたシステマティックＦＥＣ符号Ｆのためのシステマティック符号化方法Ｆの一実施形態では、ＫおよびＮが入力パラメータである。ＦＥＣ符号ＦのソースシンボルはＥＳＩ  ０，．．．，Ｋ−１を有し、ＦＥＣ符号ＦのリペアシンボルはＥＳＩ  Ｋ，．．．，Ｎ−１を有することになる。ＦＥＣ符号Ｆのためのシステマティック符号化方法Ｆは、ＦＥＣ符号Ｅのための符号化方法Ｅと復号方法Ｅとを使用してＫ個のソースシンボルＣ（０），．．．，Ｃ（Ｋ−１）からＮ個の被符号化シンボルを生成し、ハードウェアおよび／またはソフトウェアによって次のように実行される。
【００６５】
（１）ＦＥＣ符号Ｅに関連付けられたＮ個のＥＳＩをランダムに置換して、ＦＥＣ符号Ｅ置換ＥＳＩセットＸ（０），．．．，Ｘ（Ｎ−１）に達し、この置換ＥＳＩセットは、ＦＥＣ符号ＥのＫ個のソースシンボルが、ＥＳＩ  Ｘ（０），．．．，Ｘ（Ｋ−１）の置換順序に関してＦＥＣ符号Ｅの最初のＫ個の被符号化シンボルから復号され得るように編成される。
【００６６】
（２）各ｉ＝０，．．．，Ｎ−１について、ＦＥＣ符号ＦのＥＳＩ  ｉをＦＥＣ符号ＥのＥＳＩ  Ｘ（ｉ）に関連付ける。
【００６７】
（３）各ｉ＝０，．．．，Ｋ−１について、ＥＳＩ  Ｘ（ｉ）をもつＦＥＣ符号Ｅの被符号化シンボルの値をソースシンボルＣ（ｉ）の値に設定する。
【００６８】
（４）対応するＦＥＣ符号Ｅ  ＥＳＩ  Ｘ（０），．．．，Ｘ（Ｋ−１）をもつソースシンボルＣ（０），．．．，Ｃ（Ｋ−１）に復号方法Ｅを適用して、復号シンボルＥ（０），．．．，Ｅ（Ｋ−１）を生成する。
【００６９】
（５）復号シンボルＥ（０），．．．，Ｅ（Ｋ−１）に符号化方法Ｅを適用して、関連するＦＥＣ符号ＥＳＩ  ０，．．．，Ｎ−１をもつＦＥＣ符号Ｅの被符号化シンボルＤ（０），．．．，Ｄ（Ｎ−１）を生成する。
【００７０】
（６）ＥＳＩ  ０，１，．．．，Ｎ−１を用いた符号化方法Ｆのための被符号化シンボルは、Ｄ（Ｘ（０）），Ｄ（Ｘ（１）），．．．，Ｄ（Ｘ（Ｎ−１））である。
【００７１】
符号化方法Ｆの出力は、Ｎ個の被符号化シンボルであり、それらのＮ個の被符号化シンボルのうち、最初のＫ個は、関連するＥＳＩ  ０，１，．．．，Ｋ−１をもつソースシンボルＣ（０），．．．，Ｃ（Ｋ−１）であることに留意されたい。したがって、符号化方法Ｆは、ソースデータのシステマティック符号化を生成する。
【００７２】
今説明した符号化方法Ｆに対応する復号方法Ｆの一実施形態は、次のとおりであり、ただし、ＫおよびＮは、全体を通して使用されるこの方法への入力パラメータである。この復号方法Ｆは、関連するＦＥＣ符号Ｆ  ＥＳＩ  Ｙ（０），．．．，Ｙ（Ｋ−１）をもつＫ個の受信された被符号化シンボルＤ（０），．．．，Ｄ（Ｋ−１）からＫ個のソースシンボルＣ（０），．．．，Ｃ（Ｋ−１）を復元する。これらの受信シンボルは、必ずしも送信されたシンボルである必要はない。ハードウェアおよび／またはソフトウェアによって実行される本方法は次のとおりである。
【００７３】
（１）ＦＥＣ符号Ｅに関連付けられたＮ個のＥＳＩをランダムに置換して、ＦＥＣ符号Ｅ置換ＥＳＩセットＸ（０），．．．，Ｘ（Ｎ−１）に達し、この置換ＥＳＩセットは、ＦＥＣ符号ＥのＫ個のソースシンボルが、ＥＳＩ  Ｘ（０），．．．，Ｘ（Ｋ−１）の置換順序に関してＦＥＣ符号Ｅの最初のＫ個の被符号化シンボルから復号され得るように編成される。
【００７４】
（２）関連するＦＥＣ符号Ｅ  ＥＳＩ  Ｘ（Ｙ（０）），．．．，Ｘ（Ｙ（Ｋ−１））をもつ被符号化シンボルＤ（０），．．．，Ｄ（Ｋ−１）に復号方法Ｅを適用して、復号シンボルＥ（０），．．．，Ｅ（Ｋ−１）を生成する。
【００７５】
（３）符号化方法Ｅを使用して、Ｅ（０），．．．，Ｅ（Ｋ−１）からＦＥＣ符号Ｅ  ＥＳＩ  Ｘ（０），．．．，Ｘ（Ｋ−１）をもつ被符号化シンボルＣ（０），．．．，Ｃ（Ｋ−１）を生成する。
【００７６】
（４）ＥＳＩ  ０，．．．，Ｋ−１をもつＦＥＣ符号Ｆの復号ソースシンボルは、Ｃ（０），．．．，Ｃ（Ｋ−１）である。
【００７７】
今説明したように動作する方法および装置は、いくつかの望ましい性質を有する。たとえば、システマティック符号であるＦＥＣ符号Ｅであって、Ｋ個の受信された被符号化シンボルのランダムセットが高確率に復号され得るという性質を有するが、Ｋ個の被符号化シンボルが受信されたとき、受信された被符号化シンボル中のソースシンボルの比率がＫ／Ｎに近接していないという性質をも有する、ＦＥＣ符号について考えると、そのＦＥＣ符号Ｅは高確率に復号され得ない。この場合、本実施形態は、ＦＥＣ符号Ｅの符号化方法と復号方法とを使用する新しいＦＥＣ符号Ｆについて説明し、その新しいＦＥＣ符号Ｆは、ソースシンボルである受信された被符号化シンボルの比率とは無関係に、Ｋ個の受信された被符号化シンボルのセットから高確率に復号するという望ましい性質を有する。
【００７８】
上記の実施形態の多くの変形態がある。たとえば、符号化方法Ｆのステップ（１）において、ＥＳＩのランダム置換は、擬似ランダムであり得、またはランダムでも擬似ランダムでもないＥＳＩの良好な選択を生成する何らかの他の方法に基づき得る。ＦＥＣ符号Ｅがシステマティック符号である場合、システマティックＥＳＩの中からステップ（１）において選択された置換中の最初のＫ個のＥＳＩの部分は、ＦＥＣ符号Ｅのレートに比例する、すなわち、Ｋ／Ｎに比例することが好ましい。ステップ（１）中の新しい符号化方法Ｆによって行われるＥＳＩのランダム選定は、簡潔なデータ量によって表され得る、たとえば、新しい復号方法Ｆが、同じシードと擬似乱数発生器とＥＳＩを生成するための方法とに基づいてステップ（１）においてまったく同じＥＳＩ置換選定を行うことができるように、シードと、擬似乱数発生器がどのように動作するかとに基づいてＥＳＩを選定する同意済みの方法とともに、周知または同意済みの擬似乱数発生器へのシードによって表され得ることが好ましい。概して、ＥＳＩのシーケンスを生成するためにステップ（１）中の新しい符号化方法Ｆにおいて使用されるプロセスと、ＥＳＩのシーケンスを生成するためにステップ（１）中の新しい復号方法Ｆにおいて使用されるプロセスとが、両方ともＥＳＩの同じシーケンスを生成する場合、新しい復号方法Ｆが新しい符号化方法Ｆの逆になるようにすることが好ましい。
【００７９】
同様に、たとえば、明示的ＥＳＩを使用せず、代わりに、ある被符号化シンボルの一意の識別子が、他の被符号化シンボルに対するその被符号化シンボルの位置によるか、または他の手段による、他の変形態がある。
【００８０】
上記の説明では、ＦＥＣ符号Ｅの元のＥＳＩは、ソースシンボルの順序セットに連続順序でＥＳＩ  ０，．．．，Ｋ−１が割り当てられ、リペアシンボルにＥＳＩ  Ｋ，．．．，Ｎ−１が割り当てられるように、ＦＥＣ符号Ｆによってリマッピングされる。他の変形態が可能であり、たとえば、ＥＳＩの再マッピングは、符号化方法Ｆが被符号化シンボルを生成した直後に、しかし被符号化シンボルが送信される前に、送信側において行われ得、ＥＳＩの逆再マッピングは、被符号化シンボルが受信されたとき、しかし被符号化シンボルが復号方法Ｆによって元のソースシンボルの復元のために処理される前に、受信機において行われ得る。
【００８１】
別の変形態として、新しい符号化方法Ｆのステップ（１）において、最初にＫ＋Ａ個のＦＥＣ符号Ｅ  ＥＳＩを選択することによって置換が選択され得、ただし、Ａは、高確率の復号可能性を保証するために選定された値であり、次いで、復号プロセスのシミュレーション中に、Ｋ＋Ａ個のＥＳＩの中からどのＫ個が実際に復号中に使用されるかが判断され、選択された置換は、置換の最初のＫ個のＥＳＩとなるべき、Ｋ＋Ａ個のＥＳＩの初期セットの中から実際に復号中に使用されるＫ個のＥＳＩを選択し得る。同様の変形態が、新しい復号方法Ｆに適用される。
【００８２】
符号化方法Ｆの別の変形態として、ステップ（１）において生成されるＥＳＩの置換に関連付けられるＦＥＣ符号Ｅの最初のＫ個の被符号化シンボルが復号可能であることを保証するために、ランダム置換を生成するために使用されるシードがＫの値について事前計算され、次いで、このシードは、ステップ（１）において置換を生成するために、符号化方法Ｆおよび対応する復号方法Ｆのステップ（１）におけるＫについて常に使用される。そのようなシードを選定するための方法は、ステップ（１）における復号可能性を保証するシードが発見されるまでシードをランダムに選定することと、次いで、このシードを選択することとを含む。代替的に、これらの性質をもつシードが符号化方法Ｆによって動的に生成され得、次いで、このシードは復号方法Ｆに通信され得る。
【００８３】
符号化方法Ｆの別の変形態として、ステップ（１）において部分置換が選択され得、すなわち、ＥＳＩのすべてと、被符号化シンボルのすべてとがステップ（５）および（６）において必要とされるのでなければ、たとえば、それらは、被符号化シンボルの一部であるソースシンボルに対応するので、またはＮ個未満の被符号化シンボルしか生成される必要がないので、新しい符号化方法Ｆのステップ（１）におけるＥＳＩのすべてが生成され、被符号化シンボルのすべてが生成される必要があるわけではない。他の変形態では、受信された被符号化シンボルの一部は、復元されているソースシンボルの一部に対応し得るので、新しい復号方法Ｆのステップ（３）および（４）における被符号化シンボルのすべてが再計算される必要があるわけではない。同様に、新しい復号方法Ｆのステップ（２）において、たとえば、ステップ（２）において復号されたシンボルの一部が、被符号化シンボルを生成するために後続のステップにおいて必要とされない場合、すべてのＫ個のシンボルＥ（０），．．．，Ｅ（Ｋ−１）が復号される必要があるわけではない。
【００８４】
上記で説明した方法および実施形態は多くの適用例を有する。たとえば、符号化方法Ｆおよび復号方法Ｆならびにそれらの変形態は、改善された受信オーバーヘッドと復号失敗確率パフォーマンスとを与えるためにトルネード符号およびＩＥＴＦ  ＬＤＰＣ符号に適用され得る。概して、これらの新しい方法は、任意の固定レートＦＥＣ符号に適用される。これらの新しい方法の変形態はまた、固定レートを有しないＦＥＣ符号、すなわち、生成され得る被符号化シンボルの数がソースシンボルの数とは無関係である、連鎖反応符号などのＦＥＣ符号に適用され得る。
【００８５】
Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩＩは、連鎖反応符号のためのシステマティック符号化および復号方法を作成するための同様の教示を含んでいる。いくつかの実施形態では、これらの符号のために使用される符号化方法および復号方法Ｅは、Ｌｕｂｙ  Ｉ、Ｌｕｂｙ  ＩＩ、Ｓｈｏｋｒｏｌｌａｈｉ  Ｉ、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩ、Ｌｕｂｙ  ＩＩＩ、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＶにおいて教示されている方法である。システマティックエンコーダについて説明するためには、符号化方法Ｅと復号方法Ｅとについて説明し、これらの方法をシステマティック符号化方法Ｆとシステマティック復号方法Ｆとに変換するために、上記で説明し、それらの文献から知られる一般的原理を使用することでしばしば十分である。したがって、本開示と引用文献とを読めば、符号化方法Ｅと復号方法Ｅとについて説明している本教示をどのように取り入れ、同教示をシステマティック符号化方法Ｆとシステマティック復号方法Ｆとに適用すべきかなどが当業者には明らかであるはずである。非活動化
Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩなどにおいて教示されている非活動化復号は、既知の一次方程式値のセットから未知の変数のセットについて解くときはいつでも信念伝搬と組み合わせて適用され得る一般的な方法であり、一次方程式のセットに基づいて効率的な符号化方法と復号方法とを実装するときは特に有益である。Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩに記載されている非活動化復号と、本明細書で以下で説明する永久的非活動化復号とを区別するために、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩの方法および教示を参照するためには「オンザフライ」非活動化（所々で「ＯＴＦ非活動化」と略す）を使用し、非活動化が事前に選択される本明細書の方法および教示を参照するためには「永久的非活動化」を使用する。
【００８６】
信念伝搬復号の１つの教義は、復号プロセス中に可能であるときはいつでも、デコーダは、１つの残りの未知の変数について解くために、その変数に依存する方程式（場合によっては簡約方程式）を使用しなければならず、したがって、その方程式は、その変数に関連付けられ、次いで、解かれた変数に対するそれらの方程式の依存性をなくすことによって残りの未使用の方程式を簡約するということである。そのような単純な信念伝搬ベースの復号プロセスは、たとえば、トルネード符号、Ｌｕｂｙ  Ｉ、Ｌｕｂｙ  ＩＩ、Ｓｈｏｋｒｏｌｌａｈｉ  Ｉ、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩ、Ｌｕｂｙ  ＩＩＩ、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＶに記載されている連鎖反応符号、およびＩＥＴＦ  ＬＤＰＣ符号の実施形態の一部において使用されている。
【００８７】
ＯＴＦ非活動化復号は複数の段階で進行する。ＯＴＦ非活動化復号方法の第１の段階では、ただ１つの残りの未知の変数に依存する残りの方程式がないので信念伝搬復号プロセスが進むことができないときはいつでも、デコーダは、１つまたは複数の未知の変数を「ＯＴＦ非活動化」し、それらの未知の変数を、（実際にはそうでないにもかかわらず）信念伝搬プロセスに関して「解かれ」、残りの方程式から「除去された」ものと見なし、このようにして、場合によっては信念伝搬復号プロセスが進むことを可能にする。次いで、たとえば第２の段階において、第１の段階中にＯＴＦ非活動化された変数について、たとえばガウス消去法またはより計算量的に効率的な方法を使用して解かれ、次いで、第３の段階において、これらのＯＴＦ非活動化された変数の値は、復号の第１の段階中に方程式に関連付けられた変数について完全に解くために使用される。
【００８８】
Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩなどにおいてより詳細に教示されているＯＴＦ非活動化復号は、連鎖反応符号以外の多くの他のタイプの符号に適用され得る。たとえば、そのＯＴＦ非活動化復号は、ＬＤＰＣおよびＬＤＧＭ符号の一般的クラス、特にＩＥＴＦ  ＬＤＰＣ符号およびトルネード符号に適用され得、その結果、それらのタイプの符号について信頼性が改善され（デコードに失敗する確率を減少させ）、ならびに／あるいはＣＰＵおよび／またはメモリパフォーマンスが改善される（符号化および／または復号の速度を増加させ、および／または所要メモリサイズおよび／またはアクセスパターン要件を減少させる）。
【００８９】
ＯＴＦ非活動化復号と組み合わせた連鎖反応符号実施形態の変形態のいくつかがＳｈｏｋｒｏｌｌａｈｉ  ＩＶにおいて説明されている。本出願では他の変形態について説明する。
【００９０】
システム概観
図１は、マルチステージコーディングを使用する通信システム１００のブロック図である。このブロック図は、Ｓｈｏｋｒｏｌｌａｈｉ  Ｉに示されているものと同様であるが、この場合、エンコーダ１１５は、どの中間シンボルの指定が「永久的非活動化」されているかを考慮に入れ、動的符号化プロセス中に永久的非活動化されていない中間シンボルとは異なってそれらの中間シンボルに作用する。同様に、デコーダ１５５も、復号するときに永久的非活動化中間シンボルを考慮に入れる。
【００９１】
図１に示すように、Ｋ個のソースシンボル（Ｃ（０），．．．，Ｃ（Ｋ−１））がエンコーダ１１５に入力され、デコーダ１５５が利用可能になるシンボルの復号に成功した場合、デコーダ１１５は、それらのＫ個のソースシンボルのコピーを出力することができる。いくつかの実施形態では、ストリームは、Ｋ個のシンボルブロックにパースされ、いくつかの実施形態では、Ｋよりも大きいいくつかのソースシンボルのファイルは、Ｋサイズのシンボルブロックに分割され、そのように送信される。いくつかの実施形態では、Ｋ′＞Ｋのブロックサイズが好適である場合、Ｋ′−Ｋ個のパディングシンボルがＫ個のソースシンボルに追加され得る。これらのパディングシンボルは、値０を有するか、あるいはエンコーダ１１５とデコーダ１５５の両方に知られている（かまたは場合によってはデコーダ１５５において判断されることが可能である）任意の他の固定値を有することができる。エンコーダ１１５は複数のエンコーダ、モジュールなどを備えることがあり、それはデコーダ１５５についても当てはまり得ることを理解されたい。
【００９２】
図示のように、エンコーダ１１５はまた、動的鍵生成器１２０から動的鍵のシーケンスを、および静的鍵生成器１３０から静的鍵のシーケンスを受信し、動的鍵生成器１２０と静的鍵生成器１３０の各々は乱数発生器１３５によって駆動され得る。動的鍵生成器１２０の出力は単に基数シーケンスであってよいが、そうである必要はない。鍵生成器の演算は、Ｓｈｏｋｒｏｌｌａｈｉ  Ｉに示されているとおりでよい。
【００９３】
図に示す様々な機能ブロックは、入力信号として与えられる指定された入力をもつハードウェアとして実装され得、または、命令メモリに記憶されており、対応する機能を実行するために適切な順序で実行される命令を実行するプロセッサによって実装され得ることを理解されたい。場合によっては、それらの機能を実行しおよび／またはプログラムコードを実行するための専用ハードウェアが使用される。プログラムコードおよびプロセッサは常に示されているわけではないが、当業者ならば、本開示を読めば、そのような詳細をどのように実装すべきかがわかるであろう。
【００９４】
エンコーダ１１５はまた、本明細書の他の場所で説明するラインに沿って、非活動化指定器１２５からの入力と、システム１００への他のパラメータ入力とを受信する。非活動化指定器１２５の出力は、復号のために「永久的非活動化」されていると指定された中間シンボルの数を表す値Ｐを含み得る（「ＰＩリスト」は、中間シンボルのうちのどのＰ個がリスト上にあるかを示す）。他の場所で説明するように、いくつかの実施形態では、符号化プロセスのために使用される中間シンボルはＫ個のソースシンボルだけであるが、他の実施形態では、Ｋ個のソースシンボルをコピーするだけでなくそれらから中間シンボルを生成する何らかのタイプの処理、変換、符号化、復号などがある。
【００９５】
入力パラメータは、（以下でより詳細に説明する）鍵生成器および／またはエンコーダの符号化プロセスによって使用されるランダムシード、生成すべき被符号化シンボルの数、生成すべきＬＤＰＣシンボルの数、生成すべきＨＤＰＣシンボルの数、生成すべき中間シンボルの数、生成すべき冗長シンボルの数などを含み得、および／またはこれらの値のいくつかは、エンコーダ１１５にとって利用可能な他の値から計算される。たとえば、生成されるべきＬＤＰＣシンボルの数は、固定式およびＫの値から完全に計算され得る。
【００９６】
エンコーダ１１５は、それの入力から被符号化シンボルのシーケンス（Ｂ（Ｉ0），Ｂ（Ｉ1），Ｂ（Ｉ2），．．．）を生成し、そのシーケンスを送信モジュール１４０に供給し、その送信モジュール１４０は、動的鍵生成器１２０から動的鍵値（Ｉ0，Ｉ1，Ｉ2，．．．）をも受信するが、その情報を搬送する別の方法がある場合、これは必要でないことがある。送信モジュール１４０は、送信モジュール１４０に与えられたものを、場合によっては、ここでより詳細に説明する必要がない従来の方法でチャネル１４５に搬送する。受信モジュール１５０は、被符号化シンボルと（必要な場合に）動的鍵値とを受信する。チャネル１４５は、（別の場所において受信されるためにある場所から送信するための）空間を通るチャネル、または（たとえば、後の時間にリプレイバックするために媒体に記録するための）時間を通るチャネルであり得る。チャネル１４５は、被符号化シンボルのうちの一部の損失を生じ得る。したがって、デコーダ１１５が受信モジュール１５０から受信する被符号化シンボルＢ（Ｉa），Ｂ（Ｉb），．．．は、送信モジュールが送った被符号化シンボルに等しくないことがある。これは、異なる下つき添字インデックスによって示されている。
【００９７】
デコーダ１５５は、好ましくは、動的鍵再生器１６０と乱数発生器１６３と静的鍵生成器１６５とを使用して、（鍵が異なることがある）受信シンボルのために使用される鍵を再生し、様々な復号パラメータを入力として受信することが可能である。これらの入力のいくつかはハードコーディングされ（すなわち、デバイスの構築中に入力され）得、いくつかは変更可能な入力であり得る。
【００９８】
図２は、他の図においておよび本開示全体にわたってほとんどの場合に使用される、表記法の概要を伴う、変数、アレイなどのテーブルである。特に明記しない限り、Ｋは、エンコーダのソースシンボルの数を示し、Ｒは、静的エンコーダによって生成される冗長シンボルの数を示し、Ｌは、「中間シンボル」、すなわち、ソースシンボルと冗長シンボルの組合せの数であり、したがって、Ｌ＝Ｋ＋Ｒである。
【００９９】
以下で説明するように、静的エンコーダのいくつかの実施形態では、２つのタイプの冗長シンボルが生成される。ここでの多くの例において使用される、特定の実施形態では、第１のセットはＬＤＰＣシンボルを備え、第２のセットはＨＤＰＣシンボルを備える。一般性の損失なしに、本明細書の多くの例は、ＳをＬＤＰＣシンボルの数として参照し、ＨをＨＤＰＣシンボルの数として参照する。３つ以上の冗長シンボルのタイプが存在し得、したがって、Ｒ＝Ｓ＋Ｈである必要はない。ＬＤＰＣシンボルとＨＤＰＣシンボルとは異なる度数分布を有し、当業者ならば、本開示を読めば、ＬＤＰＣシンボルまたはＨＤＰＣシンボルではない冗長シンボルであって、２つ（またはそれ以上）のシンボルセットを備え、各セットが他のセットの度数分布とは異なる度数分布を有する、冗長シンボルをどのように使用すべきかがわかるであろう。よく知られているように、冗長シンボルのセットの度数分布は、度数の分布を指し、冗長シンボルの度数は、冗長シンボルが依存するソースシンボルの数を指す。
【０１００】
Ｐは、中間シンボルの中の永久的非活動シンボルの数を示す。永久的非活動シンボルは、信念伝搬を続ける （および次いで非活動化シンボルを解決した後に解決するために戻って くる）ために、信念伝搬ネットワークにおいて特定の処理のために指定されたシンボル、すなわち、「除外」または「非活動化」されるべきシンボルであり、永久的非活動化シンボルは、そのような処理のためにエンコーダにおいて指定されるという点で、他の非活動化シンボルとは区別される。
【０１０１】
Ｎは、復号の試みがデコーダ１５５によって行われる受信シンボルの数を示し、Ａは、「オーバーヘッド」シンボルの数、すなわち、Ｋを超えた受信された被符号化シンボルの数である。したがって、Ａ＝Ｎ−Ｋである。
【０１０２】
Ｋ、Ｒ、Ｓ、Ｈ、Ｐ、ＮおよびＡは、整数であり、典型的にはすべて１以上の整数であるが、特定の実施形態では、これらのうちのいくつかは１または０であり得る（たとえば、Ｒ＝０は、冗長シンボルがない場合であり、Ｐ＝０は、ＯＴＦ非活動化しかない、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩの場合に頼る）。
【０１０３】
ソースシンボルのベクトルは（Ｃ（０），．．．，Ｃ（Ｋ−１））で示され、冗長シンボルのベクトルは（Ｃ（Ｋ），．．．，Ｃ（Ｌ−１））で示される。したがって、システマティックな場合、（Ｃ（０），．．．，Ｃ（Ｌ−１））は中間シンボルのベクトルを示す。それらの中間シンボルのうちのＰ個は、「永久的非活動」であると指定される。「ＰＩリスト」は、中間シンボルのうちのどれが永久的非活動シンボルであるかを示す。多くの実施形態では、ＰＩリストは単に最後のＰ個の中間シンボル、すなわち、Ｃ（Ｌ−Ｐ），．．．，Ｃ（Ｌ−１）を指すが、これは要件ではない。その場合は、この説明の残りの部分を簡略化するためのものとのみ考えられる。
【０１０４】
ＰＩリスト上にない中間シンボルは、本明細書では「ＬＴ中間シンボル」と呼ぶ。本例では、ＬＴ中間シンボルはＣ（０），．．．，Ｃ（Ｌ−Ｐ−１）となる。Ｄ（０），．．．，Ｄ（Ｎ−１）は、受信された被符号化シンボルを示す。
【０１０５】
値のアレイが「Ｎ（０），．．．，Ｎ（ｘ）」などと記述される場合、それは１つまたは２つの値しかない場合を除外するものではないので、これは、少なくとも３つの値を必要とするものと考えられるべきではないことに留意されたい。
【０１０６】
永久的非活動化を使用した符号化方法
図３は、図１に示すエンコーダ１１５の１つの特定の実施形態のブロック図である。そこで示されているように、ソースシンボルは、入力バッファ２０５に記憶され、静的エンコーダ２１０と動的エンコーダ２２０とに供給され、動的エンコーダ２２０は、鍵入力と他の入力とをも受信する。静的エンコーダ２１０は、内部値とプログラム命令とを記憶するための内部記憶装置２１５（メモリ、バッファ、仮想メモリ、登録記憶装置など）を含み得る。同様に、動的エンコーダ２２０は、内部値とプログラム命令とを記憶するための内部記憶装置２２５（メモリ、バッファ、仮想メモリ、登録記憶装置など）を含み得る。
【０１０７】
いくつかの実施形態では、冗長性計算器２３０は、作成すべき冗長シンボルの数Ｒを判断する。いくつかの実施形態では、静的エンコーダ２１０は、冗長シンボルの２つの別個のセットを生成し、特定の実施形態では、第１のセットは、最初のＳ個の冗長シンボル、すなわち、シンボルＣ（Ｋ），．．．，Ｃ（Ｋ＋Ｓ−１）であり、それらはＬＤＰＣシンボルであるが、第２のセットは、次のＨ個の冗長シンボル、すなわち、Ｃ（Ｌ−Ｈ），．．．，Ｃ（Ｌ−１）であり、それらはＨＤＰＣシンボルである。ＰＩリストが最後のＰ個の冗長シンボルである場合、（Ｐ≧Ｈである場合）Ｈ個の冗長シンボルのすべてがＰＩリスト上にあるか、または（Ｐ＜Ｈの場合）Ｐ個の冗長シンボルのすべてがＨＤＰＣシンボルであり得る。
【０１０８】
シンボルのこれらの２つのセットの生成をもたらす演算は極めて異なり得る。たとえば、以下で説明するいくつかの実施形態では、ＬＤＰＣ冗長シンボルを生成するための演算はバイナリ演算であり、ＨＤＰＣシンボルを生成するための演算は非バイナリ演算である。
【０１０９】
動的エンコーダ２２０の演算が図４にさらに詳細に説明されている。一実施形態によれば、動的エンコーダ２２０は、２つのエンコーダ、すなわち、ＰＩエンコーダ２４０とＬＴエンコーダ２５０とを備える。いくつかの実施形態では、ＬＴエンコーダ２５０は連鎖反応エンコーダであり、ＰＩエンコーダ２４０は特定のタイプの連鎖反応エンコーダである。他の実施形態では、これらの２つのエンコーダは極めて同様であり得るか、またはＰＩエンコーダ２４０は連鎖反応エンコーダではない。これらのエンコーダがどのように定義されようとも、ＬＴエンコーダ２５０は、永久的非活動的でないと指定されたＬＴ中間シンボルＣ（０），．．．，Ｃ（Ｌ−Ｐ−１）からシンボルを生成し、ＰＩエンコーダ２４０は、永久的非活動中間シンボルＣ（Ｌ−Ｐ），．．．，Ｃ（Ｌ−１）からシンボルを生成する。これらの２つの生成されたシンボルはコンバイナ２６０に入り、コンバイナ２６０は、最終の被符号化シンボル２７０を生成する。
【０１１０】
本発明のいくつかの実施形態では、永久的非活動化シンボルの一部はＬＴ符号化プロセスに関与し、永久的非活動化シンボルでないシンボルの一部はＰＩ符号化プロセスに関与し得る。言い換えれば、ＰＩリストと、ＬＴ中間シンボルを備えるシンボルのセットとは、独立である必要はない。
【０１１１】
好適な実施形態では、コンバイナ２６０に供給されるシンボルは、同じ長さを有し得、コンバイナ２６０によって実行される機能は、被符号化シンボル２７０を生成するための、これらのシンボルに対するＸＯＲ演算である。ただし、これは、本発明の動作には不要である。同様の結果をもたらし得る他のタイプのコンバイナが想定され得る。
【０１１２】
他の実施形態では、中間シンボルは、３つ以上のセット、たとえば、各々がそれの関連するエンコーダ２４０をもつ、ＬＴシンボルの１つのセットと、ＰＩシンボルのいくつか（２つ以上）のセットとに再分割される。もちろん、各関連するエンコーダは、異なるセットのための異なるエンコーダとして働くとき、符号化プロセスに従って異なる命令に基づいて動作する、共通のコンピューティング要素またはハードウェア要素として実装され得る。
【０１１３】
ＰＩエンコーダ２４０によって実行され得るＰＩ符号化プロセス２４１の例示的な演算が図５に例示されている。生成されるべき被符号化シンボルに対応する鍵Ｉ＿ａを使用して、ステップ２６１において、エンコーダは、正の重みＷＰと、両端の値を含むＬＰとＬ−１との間のＷＰ個の整数を含んでいるリストＡＬＰとを判断する。ステップ２６３において、リストＡＬＰ＝（ｔ（０），．．．，ｔ（ＷＰ−１））である場合、シンボルＸの値を
【数１】
0005602858.tif 000002
【０１１４】
に設定し、ただし、
【数２】
0005602858.tif 000003
【０１１５】
はＸＯＲ演算を示す。
【０１１６】
いくつかの実施形態では、重みＷＰは、３、または４、または何らかの他の固定数など、何らかの数に固定される。他の実施形態では、重みＷＰは、２または３のいずれかに等しくなるように選定などされている、可能なそのような数の小さいセットに属し得る。たとえば、付録Ａの実施形態に示すように、重みＷＰは、ＬＴエンコーダ２５０によって実行され得るＬＴ符号化プロセス２５１によって生成されたシンボルの重みに依存する。ＬＴエンコーダ２５０によって生成された重みが２である場合、ＷＰは、鍵Ｉ＿ａに応じて、２または３のいずれかとなるように選定され、ＷＰが２であるかまたは３であるかの回数の比率はほぼ等しい。ＬＴエンコーダ２５０によって生成された重みが３よりも大きい場合、ＷＰは２となるように選定される。
【０１１７】
図６は、本発明の実施形態のうちの１つによる、Ｌｕｂｙ  ＩとＳｈｏｋｒｏｌｌａｈｉ  Ｉとの教示を使用したＬＴ符号化プロセス２５１の一例である。ステップ２６７において、鍵Ｉ＿ａを使用して、それぞれ重みＷＬとリストＡＬとを生成する。ステップ２６９において、リストＡＬＰ＝（ｊ（０），．．．，ｊ（ＷＬ−１））である場合、シンボルＸの値を
【数３】
0005602858.tif 000004
【０１１８】
に設定する。
【０１１９】
図７に、重みＷＬを計算する演算を示す。そこで示されているように、ステップ２７２において、生成されるべき被符号化シンボルに関連する数ｖを作成し、その被符号化シンボルの鍵Ｉ＿ａに基づいて計算し得る。エンコーダとデコーダとが一致することができる限り、数ｖは、被符号化シンボルのインデックス、代表ラベルなどであるか、または別個の数であり得る。この例では、ｖは、０と２20との間にあるが、他の例では、（０〜２32などの）他の範囲が可能である。ｖの生成は、ランダム性生成テーブルを使用して明示的に行われ得るが、これらの乱数をどのように生成すべきかの厳密な演算は異なることができる。
【０１２０】
エンコーダはテーブルＭにアクセスできるものと仮定され、それの一例が図８に与えられている。「度数分布ルックアップ」テーブルと呼ばれるテーブルＭは、２つの列と複数の行とを含んでいる。左列は、重みＷＬの起こり得る値で標示され、右列は、両端の値を含む０と２20との間の整数で標示されている。ｖのどんな値にも、度数分布ルックアップテーブルのＭ［ｄ］列中に、Ｍ［ｄ−１］＜ｖ≦Ｍ［ｄ］が真である、厳密に１つのセルがある。その１つのセルに対して、ｄ列中の対応する値があり、エンコーダは、その値を被符号化シンボルの重みＷＬとして使用する。たとえば、被符号化シンボルがｖ＝９０００００を有する場合、その被符号化シンボルの重みはＷＬ＝７となる。
【０１２１】
静的エンコーダ２１０は要素ＳＥ（ｋ，ｊ）にアクセスでき、ただし、ｋ＝０，．．．，Ｒ−１およびｊ＝０，．．．，Ｌ−１である。これらの要素は、α＊Ｘがシンボルであるようにフィールドの要素αとシンボルＸとの間の演算＊が存在する任意の有限フィールドに属することができ、
【数４】
0005602858.tif 000005
【０１２２】
であり、ただし、
【数５】
0005602858.tif 000006
【０１２３】
はＸＯＲ演算を示す。そのようなフィールドおよび演算はＳｈｏｋｒｏｌｌａｈｉ  ＩＶに詳述されている。静的エンコーダ２１０の演算は、ソースシンボルＣ（０），．．．，Ｃ（Ｋ−１）の所与のシーケンスについて、式１に示す関係を満たす冗長シンボルＣ（Ｋ），．．．，Ｃ（Ｌ−１）のシーケンスを計算するものとして記述され得、ただし、Ｚ（０），．．．，Ｚ（Ｒ−１）は、エンコーダとデコーダとに知られている値（たとえば、０）である。
【数６】
0005602858.tif 000007
【０１２４】
式１では、エントリＳＥ（ｋ，ｊ）はすべてバイナリであり得、またはそれらの一部はフィールドＧＦ（２）に属することができるが、他のエントリは他のフィールドに属する。たとえば、付録Ａの実施形態の対応する行列が図９に与えられている。それは、Ｓ個の行をもつ部分行列と、Ｈ個の行をもつ部分行列という、２つの部分行列を備える。上側の部分行列は２つの部分を備える。その部分行列は、あらゆる行が２つの連続する１を有する、最後のＰ個の列を備える（位置はモジュロＰで計数される）。この行列の最初のＷ＝Ｌ−Ｐ個の列は、Ｓ×Ｓ単位行列を伴う循環行列（circulant matrix）を備える。循環行列はＢ個の列を備え、各々（場合によっては最後以外）はＳ個の行を有する。これらの循環行列の数はｃｅｉｌ（Ｂ／Ｓ）である。これらの循環行列中の列は、各々厳密に３つの１を有する。ｋ番目の循環行列の第１の列は、位置０と、（ｋ＋１）  ｍｏｄ  Ｓと、（２ｋ＋１）  ｍｏｄ  Ｓとに１を有する。他の列は、第１の列の巡回（cyclic）シフトである。図９中の下側のＨ個の行は、Ｈ×Ｈ単位行列を伴うＧＦ（２５６）中のエントリをもつ行列Ｑを備える。
【０１２５】
αが、最小多項式ｘ8＋ｘ4＋ｘ3＋ｘ2＋１をもつＧＦ（２５６）の要素を示す場合、行列Ｑは、図１０に与える行列に等しい。ここで、Δ1，．．．，ΔK+S-1は、２つの非ゼロエントリの位置が、付録Ａのセクション５．３．３．３．で概説するプロシージャに従って擬似ランダムに判断される重み２の列である。（付録Ａに与えたものなどの）値Ｓ、Ｐ、およびＨの適切な選定のために、図１０の行列は、対応する符号の優れた復元特性をもたらす。上記で説明したプロシージャは図１１に例示されている。ステップ２７６において、行列ＳＥを０に初期化する。ステップ２７８において、ＬＤＰＣシンボルの数に等しい入力変数Ｓをプロセスに与え、ペア（ｉ，ｊ）について、ｉ＝ｊ  ｍｏｄ  Ｓ、またはｉ＝（１＋ｆｌｏｏｒ（ｊ／Ｓ））＋ｊ  ｍｏｄ  Ｓ、またはｉ＝２＊（１＋ｆｌｏｏｒ（ｊ／Ｓ））＋ｊ  ｍｏｄ  Ｓとなるように、ＳＥ（ｉ，ｊ）の値を１に設定する。このステップは、図９中の循環行列に対処する。
【０１２６】
ステップ２８０において、図９中の単位行列ＩSに対応する位置を１に設定する。ステップ２８２において、図９中の行列のＰＩ部分に対応する位置を１に設定する。これらの位置は形式（ｉ，ｌ）および（ｉ，ｔ）であり、ただし、ｌ＝ｉ  ｍｏｄ  Ｐおよびｔ＝（ｉ＋１）  ｍｏｄ  Ｐである。ステップ２８４において、図９中の行列Ｑに対応する位置を設定する。したがって、行列Ｑは、このステップへの追加の入力として与えられる。ステップ２８６において、図９の行列中の単位行列ＩHに対応する位置を１に設定する。
【０１２７】
行列ＳＥのための他の選定は、可能であり、特定の適用例と、全体的な符号に要求される要件とに依存する。式１中の行列がどのように選定されようとも、静的エンコーダ２１０のタスクは様々な方法で達成され得る。たとえば、本開示を読めば当業者に明らかになるように、未知の値Ｃ（Ｋ），．．．，Ｃ（Ｌ−１）を復元するためのプロセスとしてガウス消去法が使用され得る。
【０１２８】
復号および永久的非活動化
復号問題は、デコーダ１５５が、対応する鍵Ｉa，Ｉb，．．．とともにＮ個の被符号化シンボルＢ（Ｉa），Ｂ（Ｉb），．．．を有することであると述べられ得る。これらの被符号化シンボルのセット全体、またはそれらのサブセットは、デコーダによって受信されていることがあり得るが、他の被符号化シンボルは、他の手段によってデコーダに与えられていることがあり得る。デコーダの目的は、ソースシンボルＣ（０），．．．，Ｃ（Ｋ−１）を復元することである。表示を簡略化するために、受信された被符号化シンボルをＤ（０），．．．，Ｄ（Ｎ−１）によって示す。
【０１２９】
復号演算の多くは、行列とそのような行列に対する演算との言語とを使用して、特に、そのような行列をもつ連立方程式を解くことによって簡潔に記述され得る。以下の説明では、方程式は、受信された被符号化シンボルに対応することができ、変数は、受信された被符号化シンボルに基づいて解決されるべきである、ソースシンボル、または中間シンボルとしばしば呼ばれるソースシンボルとソースシンボルから生成された冗長シンボルとの合成セットに対応することができる。付録Ａとして与える仕様では、被符号化シンボルは、「符号化シンボル」と呼ばれることがある（また他の変形態が存在する）が、明細書全体および付録を読めば、参考文献がどのように関係するかが明らかなはずである。また、方程式に対する行列および演算および解は、それらの数学演算に対応するコンピュータ命令として実装され得、実際には、コンピュータ、プロセッサ、ハードウェアまたは何らかの電子的要素なしにそのような演算を行うことは実用的でないことを理解されたい。
【０１３０】
永久的非活動化は、復号プロセスの第１の段階が開始される前に、永久的非活動化シンボルまたは変数と呼ばれる非活動化すべき変数のセットをデコーダにおいて判断するために使用される。以下で説明する永久的非活動化復号方法が既存の符号に適用されるか、または、符号が、永久的非活動化復号に関連してより一層良好に動作するように特別に設計され得る。永久的非活動化復号方法は、どんな連立一次方程式を解くためにも適用され得、特に、連鎖反応符号、ＩＥＴＦ  ＬＤＰＣ符号、およびトルネード符号に適用され得る。
【０１３１】
永久的非活動化復号は、既知の一次方程式値のセットから未知の変数のセットについて解くときはいつでも信念伝搬復号および／またはＯＴＦ非活動化復号と組み合わせて適用され得る一般的な方法であり、一次方程式のセットに基づいて効率的な符号化方法と復号方法とを実装するときは特に有益である。第１の段階では、既知の符号化方法の構造に基づいて、または受信した方程式に基づいて、未知の変数のセットが、永久的非活動化であると宣言され、永久的非活動化変数は、復号プロセスの第２の段階において、（第２の段階の一次方程式が簡約されたとき、同じ簡約が永久的非活動化変数に対して実行されることを除いて）一次方程式から除去され、「解かれた」ものと見なされる。
【０１３２】
第２の段階では、信念伝搬復号が、前に説明した信念伝搬復号を使用して永久的非活動化されていない未知の変数に適用されるか、または、ＯＴＦ非活動化復号方法の第１の段階について説明したものと同様に、ＯＴＦ非活動化復号が、永久的非活動化されていない未知の変数に適用され、それによって、簡約された被符号化シンボルまたは方程式のセットを生成する。第２の段階から生じた簡約された被符号化シンボルまたは方程式は、非活動化されていない変数またはシンボルへの依存性が除去され、したがって、簡約された被符号化シンボルまたは方程式は非活動化変数またはシンボルのみに依存するという特性を有する。いくつかの実装形態では、元の被符号化シンボルと簡約された被符号化シンボルとの両方が利用可能であり得るように、元の被符号化シンボルまたは方程式も保持され得ることに留意されたい。
【０１３３】
第３の段階では、ＯＴＦ非活動化復号を使用して第２の段階において生成された追加のＯＴＦ非活動化変数とともに永久的非活動化変数について、簡約された被符号化シンボルまたは方程式を使用して、たとえば、ガウス消去法、または永久的非活動化変数の間の関係の特殊な構造がもしあればそれを使用して解かれ、一次方程式が、ガウス消去法を使用することによるよりも効率的に解くために使用される。
【０１３４】
第４の段階では、非活動化されなかった変数について解くために、元の被符号化シンボルまたは方程式（あるいは再導出された元の被符号化シンボルまたは方程式）とともに、解かれた非活動化変数、すなわち、ＯＴＦ非活動化変数または永久的非活動化変数のいずれかの値が使用される。
【０１３５】
永久的非活動化復号方法の利点のうちの１つは、永久的非活動化以外のＯＴＦ非活動化の数ｗが、概して小さくなるかまたは０になり、また、どの被符号化シンボルが受信されるかとはほとんど無関係になることができるということである。これは、どの被符号化シンボルが受信されるかとは無関係に復号複雑度を一貫して小さくさせ、より信頼できる復号を可能にし、より効率的にスケジュールされ得るより予測可能で少ないメモリアクセスを可能にすることができる。第２の段階には少数のＯＴＦ非活動化しかなく、また、第２の段階におけるＯＴＦ非活動化は、概して、シンボル演算のパターンをいくぶん予測不可能にさせ得る復号プロセス中でしか判断されないので、復号中にメモリアクセスパターンがより予測可能になり、全体的により予測可能で効率的な復号プロセスが可能になる。
【０１３６】
上記の多くの変形態がある。たとえば、段階は、非連続インターリーブ順序で実行され得る。別の例として、非活動化シンボルについて、今度は、複数の追加の段階においてＯＴＦ非活動化復号または永久的非活動化復号のいずれかを使用して、第３の段階中に解決され得る。別の例として、永久的非活動化復号は、誤り訂正符号、または消去訂正符号、あるいは連立一次方程式を使用して解決され得る他の適用例のために使用され得る、連立一次方程式および変数に適用され得る。別の例として、これらの方法は、システマティック符号と非システマティック符号の両方に適用され得る。別の例として、これらの方法はまた、符号化プロセス中に、たとえば、非システマティック符号からシステマティック符号を生成するためのＳｈｏｋｒｏｌｌａｈｉ  ＩＩＩにおいて教示されている方法を使用して符号化するときに適用され得る。
【０１３７】
場合によっては、永久的非活動化復号方法が特に有効となるように符号化プロセスを設計することが可能である。たとえば、信念伝搬復号は、適用され得るときはいつでも、計算量的に効率的であることが知られているが、単独で使用されると、高信頼性復号を行うことができないことも知られている。信念伝搬復号がＯＴＦ非活動化復号内で使用されるとき、信念伝搬ステップは極めて効率的に処理され得るが、信念伝搬ステップ内に点在させられたＯＴＦ非活動化ステップは、復号を減速させる可能性があり、そのようなＯＴＦ非活動化ステップがより多くあればあるほど、復号プロセスはより遅くなる。
【０１３８】
ＯＴＦ非活動化復号の典型的な実施形態では、Ｎ＋Ｒ個の一次方程式値を使用してＫ＋Ｒ個の未知の変数について解くことを試みるとき、ＯＴＦ非活動化ステップの数は、一般に、Ｎ＝Ｋのとき、すなわち、ゼロオーバーヘッドを使用して変数を解くことを試みるときに最大になる。一方、ＮがＫよりも大きくなるにつれて、一般的には、ＯＴＦ非活動化ステップが場合によってはなくなる程度にＮが十分大きくなるときまで、ＯＴＦ非活動化復号の複雑さは、より少ないＯＴＦ非活動化ステップに起因して減少することになり、非活動化復号は、信念伝搬復号と同程度またはほぼ同程度に計算量的に効率的になる。ＯＴＦ非活動化復号の他の実施形態では、ＮがＫよりもかなり大きいときでも、ＯＴＦ非活動化の数は大きいままであり得る。
【０１３９】
永久的非活動化復号の１つの好適な実施形態では、永久的非活動化変数の数Ｐと、一次方程式の構造とは、一次方程式のＫ＋Ｒ個の値からＯＴＦ非活動化復号を使用して永久的非活動化されていないＬ−Ｐ個の変数について解くとき、ＯＴＦ非活動化復号中にＯＴＦ非活動化ステップの数が小さく、場合によっては０になり、したがって、ＯＴＦ非活動化復号ステップが、信念伝搬とほぼ同程度に計算量的に効率的になるように設計される。
【０１４０】
好適な実施形態では、一次方程式の構造は、ＯＴＦ非活動化復号段階が信念伝搬復号とほぼ同程度に効率的になるように設計される。そのような好適な実施形態では、一次方程式に対する永久的非活動化変数の関係は、ＯＴＦ非活動化復号段階からのＯＴＦ非活動化変数とともに永久的非活動化変数から構成される非活動化変数について解く段階が効率的に実行され得るものになる。さらに、好適な実施形態では、永久的非活動化シンボルの構造は、解かれた非活動化変数から非活動化されていない変数の解を完成する段階が計算量的に効率的であるものになる。
【０１４１】
永久的非活動化を用いた連鎖反応符号の復号
図１２に、Ｎ個の受信された被符号化シンボルまたは式と、Ｒ個の既知の静的シンボルまたは式とを使用して、デコーダによって解かれるべき変数のセットの行列表現を示す。デコーダのタスクは、この図に与えられている連立一次方程式を解くことである。一般に、シンボル／式は、デコーダによってアクセス可能なメモリまたはストレージに記憶された値によって表され、以下で説明する行列演算は、デコーダによって実行可能な命令によって実装される。
【０１４２】
図１２に示す行列は、Ｌ＝Ｋ＋Ｒ個の列と、Ｎ＋Ｒ個の行とを備える。ＬＴ部分行列は、Ｎ個の被符号化シンボルと、ＬＴ符号化プロセス２５１によって判断されたＬ個の中間シンボルのうちのＬ−Ｐ個のＬＴシンボルとの間の関係を表す。ＰＩ部分行列は、Ｎ個の被符号化シンボルと、ＰＩ符号化プロセス２４１によって判断されたＬ個の中間シンボルのうちのＰ個のＰＩシンボルとの間の関係を表す。式１の行列ＳＥは、静的エンコーダ２１０によって判断された中間シンボルの間の関係を表す。デコーダは、受信された被符号化シンボルの鍵に基づいて、および符号構成から、これらの関係を判断することができる。
【０１４３】
図１２の連立一次方程式は、図１３に示す形式に上記の行列を変換するために、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩにおいて教示されているＯＴＦ非活動化方法を使用して、上記の行列の行／列置換によって解かれる。図１３は、下三角行列ＬＯ３１０と、ＯＴＦ非活動化に対応する（ＯＴＦＩと呼ばれる）行列３２０を備えるいくつかの列と、永久的非活動中間シンボルのセットまたはそれのサブセットに対応する行列３３０ＰＩと、行列ＬＯをもたらす三角行列化プロセスにおいて使用されない被符号化シンボルまたは静的シンボルに対応する行列３４０ＥＬとを備える。
【０１４４】
図１４は、図１２中の行列をもたらすプロセスを実行し得る要素について説明しているブロック図である。図１４は、ＬＴ行列生成器３４７と、ＰＩ行列生成器３４９と、静的行列生成器３５０とを備える。鍵Ｉa，Ｉb，．．．を受信すると、ＬＴ行列生成器は図１２中の行列ＬＴを作成し、ＰＩ行列生成器３４９は図１２の行列ＰＩを作成する。これらの２つの行列の連結が静的行列生成器３５０に転送され、静的行列生成器３５０は、追加のヒントとして静的鍵Ｓ＿０，Ｓ＿１，．．．を取り得る。静的行列生成器のタスクは行列ＳＥの作成であり、静的行列生成器の出力は、図１２に与えられている完全行列である。
【０１４５】
ＬＴ行列生成器３４７の演算とＰＩ行列生成器３４９の演算とは、図１５中のＬＴエンコーダ２５０の演算とＰＩエンコーダ２４０の演算とにそれぞれ密結合される。静的行列生成器３５０の演算は、静的符号化のために使用される式１の行列ＳＥの再作成である。
【０１４６】
次に、ＬＴ行列生成器３４７と、ＰＩ行列生成器３４９と、静的行列生成器とについて、それらが実行し得る演算に関してさらに詳細に説明する。
【０１４７】
図１６は、ＬＴ行列生成器３４７によって採用される方法の一実施形態５００を示すフローチャートである。ステップ５０５において、ＬＴ行列生成器３４７は、フォーマットＮ×（Ｌ−Ｐ）の行列ＬＴをすべて０に初期化する。次に、ステップ５１０において、鍵Ｉa，Ｉb，．．．を使用して、重みＷＬ（０），．．．，ＷＬ（Ｎ−１）とリストＡＬ（０），．．．，ＡＬ（Ｎ−１）とをそれぞれ生成する。リストＡＬ（ｉ）の各々は、範囲０，．．．，Ｌ−Ｐ−１内のＷＬ（ｉ）個の整数（ｊ（０），．．．，ｊ（ＷＬ（ｉ）−１））を備える。ステップ５１５において、これらの整数を使用して、エントリＬＴ（ｉ，ｊ（０）），．．．，ＬＴ（ｉ，ｊ（ＷＬ（ｉ）−１））を１に設定する。上記で説明したように、行列ＬＴは、受信シンボル（Ｄ（０），．．．，Ｄ（Ｎ−１））に関して未知数（Ｃ（０），．．．，Ｃ（Ｌ−１））の連立方程式に寄与する。
【０１４８】
当業者なら諒解され得るように、ここで説明するＬＴ行列生成器の演算は、図６のＬＴ符号化プロセス２５１の演算と同様である。
【０１４９】
図１７は、ＰＩ行列生成器３４９によって採用される方法の一実施形態６００を示すフローチャートである。ステップ６１０において、ＰＩ行列生成器３４９は、フォーマットＮ×Ｐの行列ＰＩをすべて０に初期化する。次に、ステップ６１５において、鍵Ｉa，Ｉb，．．．を使用して、重みＷＰ（０），．．．，ＷＰ（Ｎ−１）とリストＡＬＰ（０），．．．，ＡＬＰ（Ｎ−１）とをそれぞれ生成する。リストＡＬＰ（ｉ）の各々は、範囲０，．．．，Ｐ−１内のＷＰ（ｉ）個の整数（ｊ（０），．．．，ｊ（ＷＰ（ｉ）−１））を備える。ステップ６２０において、これらの整数を使用して、エントリＰＩ（ｉ，ｊ（０）），．．．，ＰＩ（ｉ，ｊ（ＷＰ（ｉ）−１））を１に設定する。ＰＩ行列生成器の演算は、図５中のＰＩ符号化プロセス２４１の演算と同様である。
【０１５０】
上記で説明したように、行列ＬＴおよびＰＩは、受信シンボル（Ｄ（０），．．．，Ｄ（Ｎ−１））に関して未知数（Ｃ（０），．．．，Ｃ（Ｌ−１））の連立方程式に寄与する。その理由は、ＬＴエンコーダが重みＷＬ（ｉ）と関連リストＡＬ（ｉ）＝（ｊ（０），．．．，（ＷＬ（ｉ）−１））とを選定し、ＰＩエンコーダが重みＷＰ（ｉ）と関連リストＡＬＰ（ｉ）＝（ｔ（０），．．．，ｔ（ＷＰ（ｉ）−１））とを選定すると、対応する被符号化シンボルＤ（ｉ）が、以下で示すように得られるからである。これらの式は、０とＮ−１との間のｉのすべての値について累算されると、式２に表す所望の連立方程式を生じる。
【数７】
0005602858.tif 000008
【０１５１】
重みＷＬは、図７に与えられているプロシージャと同様のプロシージャを使用して計算され得る。当業者ならば、本開示を検討すれば、どのようにこれを、各々が異なる度数分布で動作している３つ以上のエンコーダがある場合に拡張すべきかがわかるであろう。
【０１５２】
行列生成器のわずかに異なる流れ図が図１８に与えられている。図１８は、ＬＴ行列生成器７１０と、静的行列生成器７１５と、ＰＩ行列生成器７２０とを備える。鍵Ｉa，Ｉb，．．．を受信すると、ＬＴ行列生成器７１０は、図１５に示す行列ＬＴを作成し、静的行列生成器７１５は、図１５に示す行列ＳＥを作成し、さらなる入力として追加の静的鍵Ｓ＿０，Ｓ＿１，．．．を取り得る。これらの２つの行列の連結がＰＩ行列生成器７２０に転送され、ＰＩ行列生成器７２０は行列ＰＩを作成する。ＬＴ行列生成器７１０の演算は、図１６において詳述したＬＴ行列生成器３４７の演算とまったく同じであり得る。静的行列生成器７１５の演算は、図１４中の静的行列生成器３５０の演算とは異なり得る。具体的に、図１９に、そのような演算の例示的な一実施形態を詳述する。
【０１５３】
ステップ７２５において、行列ＳＥを０に初期化する。ステップ７３０において、ＬＤＰＣシンボルの数に等しい入力変数Ｓをプロセスに与え、ペア（ｉ，ｊ）について、ｉ＝ｊ  ｍｏｄ  Ｓ、ｉ＝（１＋ｆｌｏｏｒ（ｊ／Ｓ））＋ｊ  ｍｏｄ  Ｓ、またはｉ＝２＊（１＋ｆｌｏｏｒ（ｊ／Ｓ））＋ｊ  ｍｏｄ  Ｓであるとき、ＳＥ（ｉ，ｊ）の値を１に設定する。ステップ７３５において、図９中の単位行列ＩＳに対応する位置を１に設定する。ステップ７４０において、行列Ｔに対応する位置を、このステップへの追加の入力として与える。この行列は、複数の有限フィールドにおけるエントリを有し得、異なる適用例に対して異なることができる。それは、符号に要求される要件に基づいて選定され得る。
【０１５４】
図２０は、ＰＩ行列生成器７２０によって採用される方法の一実施形態を示す簡略流れ図である。ステップ７４５において、ＰＩ行列生成器３４９は、フォーマット（Ｎ＋Ｒ）×Ｐの行列ＰＩをすべて０に初期化する。次に、ステップ７５０において、鍵Ｉ＿ａ，Ｉ＿ｂ，．．．を使用して、重みＷＰ（０），．．．，ＷＰ（Ｎ−１）とリストＡＬＰ（０），．．．，ＡＬＰ（Ｎ−１）とをそれぞれ生成する。リストＡＬＰ（ｉ）の各々は、範囲０，．．．，Ｐ−１内のＷＰ（ｉ）個の整数（ｊ（０），．．．，ｊ（ＷＰ（ｉ）−１））を備える。ステップ７５５において、これらの整数を使用して、エントリＰＩ（ｉ，ｊ（０）），．．．，ＰＩ（ｉ，ｊ（ＷＰ（ｉ）−１））を１に設定する。図２０中のＰＩ行列生成器の演算は、この行列生成器が、もうＲ個の行をもつ行列を作成し、図１５中の行列と密結合されることを除いて、図１７のＰＩ行列生成器の演算と同様である。
【０１５５】
図１２または図１５中の連立方程式は、一般に疎であり、すなわち、関与する行列中の非ゼロエントリの数は、一般に、可能なエントリの半分よりもはるかに小さい。そのような場合、行列は直接記憶される必要がないことがあるが、これらの行列のあらゆる個々のエントリを再作成するのを助ける指示が記憶され得る。たとえば、行列ＬＴまたはＰＩの行の各々について、プロセスは、図５〜図６において計算された重みとネイバーのリストとを記憶することを希望し得る。他の方法も可能であり、それらの方法の多くは、本明細書において、または参照により本明細書に組み込まれる開示において説明されている。
【０１５６】
行列生成器が、図１２または図１５によって与えられた形式で連立方程式を作成した後、デコーダのタスクは、Ｃ（０），．．．，Ｃ（Ｌ−１）の未知の値についてこの連立方程式を解くことである。この目的を達成するために、限定はしないが、ガウス消去法、あるいはＬｕｂｙ  Ｉ、Ｌｕｂｙ  ＩＩ、Ｓｈｏｋｒｏｌｌａｈｉ  Ｉ、ＩＩ、ＩＩＩ、ＩＶ、またはＶに記載されている方法のうちのいずれかを含む、いくつかの異なる方法が適用され得る。
【０１５７】
次に、図１２または図１５における連立方程式を解くための可能な方法について、図２１〜図２６を参照しながら略述する。本発明の実施形態のうちのいくつかによるデコーダの演算のフローチャートが図２１に与えられている。ステップ１３０５において、前に説明した方法のうちのいくつかを使用して復号行列を作成する。ステップ１３１０において、行置換と列置換とを使用してこの行列を再構成する。上記で説明したように、行置換と列置換とを適用することによって図１２中の行列または図１５中の行列のいずれかからそのような行列を取得し得る。これを達成するために、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩのオンザフライ非活動化復号と組み合わせた連鎖反応復号が使用され得る。したがって、図２２中の式が満たされるように、セット｛０，１，．．．，Ｌ−１｝に作用する置換πと、セット｛０，１，．．．，Ｎ＋Ｒ−１｝に作用する置換τとがある。
【０１５８】
本明細書では、ｗは、図１３中の行列ＬＯの行と列との数、すなわち、永久的非活動化もＯＴＦ非活動化もされていない中間シンボルの数を示す。ステップ１３１５において、図１３の行列ＬＯを使用して、対角線を下回る行列ＬＯのすべてのエントリをゼロアウトする。そうする際に、図２３中の式の右辺にあるシンボルのセットは、連立方程式の新しい右辺がＤ（τ（ｉ））の一部のＸＯＲによって取得されるように、同じ演算を尊重する必要がある。
【０１５９】
図２４に示すように、この演算後に、行列８１０は単位行列になり、８４０中の行列ＥＬはそのままになり、復号プロセスが、行列ＬＯを単位行列に簡約するのに必要であった演算に従ってこれらの行列の行を一緒にＸＯＲする必要があるので、行列ＯＴＦＩおよびＰＩは、８２０中のＯＴＦＩ−２および８３０中のＰＩ−２に変わる。
【０１６０】
復号プロセスの次のステップはステップ１３２０であり得、ＬＯを下回る残りの行列の残部を除去して、図２５に示す形式の行列を得る。このステップ後に、Ｅ（０），．．．，Ｅ（Ｎ＋Ｒ−１）と、行列ＥＬ＿２の行の数ｕと、ＥＬ＿２の列の数ｇとによって元のシンボルＤ（０），．．．，Ｄ（Ｎ＿Ｒ−１）の置換され簡約された値を示すことにより、図２５中の行列の構造は、式３に従って値Ｃ（π（Ｌ−ｇ）），．．．，Ｃ（π（Ｌ−１））についてｕ個のより小さい連立一次方程式を生じる。
【数８】
0005602858.tif 000009
【０１６１】
図２１で説明する復号プロセスなどの復号プロセスは、ステップ１３３０においてこの連立方程式を様々な手段で解き得、たとえば、ガウス消去法プロセス、または連鎖反応コーディングとガウス消去法との組合せを使用することによって、あるいは非活動化復号の別の適用によって、あるいは他の手段によって解き得る。ガウス消去法は、たとえば、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＶにおいて教示されているように、行列ＥＬが複数のフィールドに属する要素を有する場合、ＧＦ（２５６）などのより大きいフィールドにおける計算からＧＦ（２）における計算を分離するように変更され得る。
【０１６２】
式３の連立方程式が、デコーダによって採用されたプロセスを使用して解けない場合、ステップ１３３５において、デコーダは対策を施し得る。そのような対策は、エラーのフラグを付け、プロセスを停止することを含み得るか、あるいはより多くの被符号化シンボルを要求することを含み得るか、あるいはプロセスを停止し、これまで復元することが可能であった中間シンボルまたはソースシンボルのリストを、デコーダを使用しているアプリケーションに戻し得る。連立方程式が解ける場合、デコーダは、非活動化中間シンボルの値Ｃ（π（Ｌ−ｇ）），．．．，Ｃ（π（Ｌ−１））を復元し得る。いくつかの変形態では、ステップ１３３０において、非活動化中間シンボルの他にいくつかの他の中間シンボルが復元されることもあり得る。
【０１６３】
これらのシンボルの値が復元されると、デコーダは、後退代入に関与するステップ１３４０に進む。値Ｃ（π（Ｌ−ｇ）），．．．，Ｃ（π（Ｌ−１））を復元すると、図２６に与えられているタイプの連立方程式を生じる。この連立方程式は、一般的な連立方程式よりも解くのが容易である。たとえば、デコーダは、そのように行うために図２３に示すプロセスを使用し得る。図２３の右辺にある第１のベクトルを取得するプロセスは、既知のシンボルの値を連立方程式に代入するプロセスであるので、後退代入と呼ばれることがある。当業者なら本開示を読めばわかるように、図２３と図２６とに与えられている連立方程式は数学的に等価である。
【０１６４】
図２３において、デコーダは、右辺上の行列のエントリが、行列乗算のルールを使用して、すでに解決されたベクトルＣ（π（Ｌ−ｇ）），．．．，Ｃ（π（Ｌ−１））のエントリで乗算され、得られたエントリをＥ（０），．．．，Ｅ（Ｌ−ｇ−１）でＸＯＲするプロセスを実装することによって、未知の値Ｃ（π（０）），．．．，Ｃ（π（Ｌ−ｇ−１））を取得する。得られたエントリをＥ（０），．．．，Ｅ（Ｌ−ｇ−１）でＸＯＲし、このようにして値Ｃ（π（０）），．．．，Ｃ（π（Ｌ−ｇ−１））を復元するプロセスは、図２１中のデコーダのステップ１３４５を備える。
【０１６５】
いくつかの適用例では有用であるが、図２３の右辺の行列は一般に疎でなく、したがって、要素Ｃ（π（ｊ））の１つを得るためには、ｇに比例する数のＸＯＲが実行されなければならないので、この方法は、いくつかの好適な実施形態において大きい計算オーバーヘッドをもたらし得る。いくつかの実施形態では、この数は、たとえば、永久的非活動化の数Ｐがそもそも大きくなるように選定されており、ｇが少なくともＰと同程度の大きさであり得るので、大きくなり得る。これは、永久的非活動化シンボルの数Ｐの値に厳しい制限を与える可能性があり、より小さい値のＰが使用された場合、これはＯＴＦ非活動化中間シンボルの数の増加をもたらし得る。
【０１６６】
図２７は、図２１で説明したプロセスよりも計算量的に効率的であり得る修正された復号プロセスについて説明するものである。このプロセスのステップ１４０５から１４３５は、図１４中のプロセスの対応するステップと同じであり得る。随意に、このプロセスは、将来の使用のために、図１２または図１５中の元の行列あるいはこの行列の関係する部分、ならびに元のシンボルＤ（０），．．．，Ｄ（Ｎ＋Ｒ−１）のコピーを追加のメモリロケーション中に保持し得る。これは、このプロセスの動作には不要であるが、アプリケーションがこれらのコピーを保持するための十分なメモリリソースを有する場合、それはさらなる速度の利点をもたらし得る。代替的に、プロセスは、元のシンボルＤ（０），．．．，Ｄ（Ｎ＋Ｒ−１）のコピーのみを保持し、行列のコピーを保持せず、プロセスが必要とするときにその行列を再作成し得る。ステップ１４４０は、図２２中の元の連立方程式、または図２８に与えられているこの連立方程式の最上部のみを取り戻すために、行列の記憶されたコピーを使用するかまたはステップ１４１５のプロセスを元に戻す。この時点で、図２９に与えられている行列１５１０は疎であり、値Ｃ（π（ｗ）），．．．，Ｃ（π（Ｌ−１））は知られており、ただし、ｗ＝Ｌ−ｇである。
【０１６７】
よく知られているように、図２９中の式の右辺は、少数のＸＯＲのシンボル、すなわち、行列ＯＴＦＩ中の非ゼロエントリの数＋行列ＰＩ中の非ゼロエントリの数に等しい数のＸＯＲのシンボルに関与する、計算量的に効率的なプロセスを介して計算され得る。プロセスのこのステップは、図２７の１４４５によって示されている。このステップが完了した後、図２９中の式の右辺は計算されており、未知数が値Ｃ（π（０）），．．．，Ｃ（π（ｗ−１））である連立方程式を解くことになる。右辺の下三角ＬＯが疎であるので、すなわち、この連立方程式を解くためのシンボルのＸＯＲの数が、行列ＬＯ中の非ゼロエントリの数に 等しく、この数は、一般に、可能な非ゼロエントリの最大数ｗ＊ｗよりもはるかに小さいので、この連立方程式は、ステップ１４５０において連鎖反応復号を使用して解かれ得る。
【０１６８】
永続的非活動化の数の選定
永久的非活動化の数の選定は、パフォーマンス全体に影響を及ぼすことができ、したがって重要であり得る。一方では、この数は、できるだけ大きくなるように選定される必要がある。この数が大きい場合、ＯＴＦ非活動化の数は極めて小さい数に低減され、時々０にさえ低減され得る。これは、図１５中のＬＴ行列とＳＥ行列（または図２３中のそれらの対応する変形態）の組合せが、効果的にも、大きいオーバーヘッドをもつ連鎖反応符号の復号行列であるからである。このことが、ＯＴＦ非活動化の数を極めて小さくさせる。ＯＴＦ非活動化は、いくつかの実施形態では管理することがより困難になり得、したがって、ＯＴＦ非活動化の数を低減することは、速度および／またはメモリに関して利点をもたらし得る。
【０１６９】
一方、永久的非活動化の数を増加させることは、実行時間に悪影響を有し得る。たとえば、図２１の復号プロセス中のステップ１３３０と、図２７のプロセス中の対応するステップ１４３０とは、少なくともＰ個の行および列を有する連立方程式を解くことを必要とする。これを行う１つの方法は、図２５中の行列ＥＬ−２の可逆部分行列を識別し、その行列を反転させ、反転した行列を使用して中間シンボルの値Ｃ（π（Ｌ−ｇ−１）），．．．，Ｃ（π（Ｌ−１））を得ることであろう。行列ＥＬ−２は実施形態の多くにおいて疎であり得ないので、中間シンボルの値を得ることは、約ｇ×ｇのシンボルのＸＯＲを受け得る。ｇは少なくともＰであるので、シンボルのＸＯＲの数は少なくともＰ×Ｐになり得、したがって、シンボルのＸＯＲの全体的な数がＫにおいて線形に保持されるべき場合、良い選定は、数ＰをＫの平方根に比例するように設定することである。付録Ａの特定の実施形態は、Ｐを２．５＊ｓｑｒｔ（Ｋ）程度となるように選定し、この観測と歩調を合わせる。Ｐのこの選定を用いた場合、一般に、ＯＴＦ非活動化の数は、約Ｐから０に極めて近くなるかまたは０に等しくなってかなり小さくなるので、これはＰの良い選定である。
【０１７０】
注目する別の量は、被符号化シンボル、または静的シンボルのために存在する非活動化中間シンボルネイバーの平均数Ｉである。図２７中の復号プロセスのステップ１４４５は、このステップを達成するために、復元されていない中間シンボルごとに平均してＩ個ほどのシンボルのＸＯＲを必要とし得る。Ｉが大きい場合、ＸＯＲのこの数は、復号または符号化プロセスを実行しているプロセスのメモリおよび計算リソースにとって過大であり得る。一方、Ｉが非常に小さい場合、図２５の行列ＥＬ−２は最大階数を有していないことがあり、復号可能性を危うくし得る。
【０１７１】
より詳細な分析により、永久的非活動化の重要な態様は、図１５の行列ＰＩに、列が互いに線形独立であるにように、すなわち、行列ができる限り最大階数であるように作用させることであることが明らかになっている。ＰＩがランダムバイナリ行列である場合、可能な限界までの最大階数が達成され得ることが当業者によく知られている。一方、ＰＩは、平均すると、Ｋの平方根に反比例する１の部分を各列中に有し得、依然として純ランダム行列の階数特性と同じ階数特性を満たし得る。このために、付録Ａにおける特定の実施形態は、Ｉが２と３との間の数になるように選定し、したがって、Ｋの平方根に比例するＰを選定する場合、これは、ＰＩの各列中の１の数が、平均するとＫの平方根に反比例することを意味する。
【０１７２】
本開示を読めば当業者なら認識されるように、これらの方法の多くの変形態がある。たとえば、ＸＯＲは、他の演算子、たとえば、より大きい有限フィールド上の線形演算子と置き換えられ得、または、演算子は、異なる演算子、たとえば、いくつかの演算のためのより大きい有限フィールド上のいくつかの線形演算子と、他の演算のためのより小さいより大きい有限フィールド上の他の線形演算子との混合であり得る。
【０１７３】
付録Ａに関する特定の例
上記で詳述したように、永久的非活動化（すなわち、どの被符号化シンボルが、連鎖反応復号のシーケンスを判断することの一部となる行列操作の部分にならないかに関する所定の決定）がなければ、ＯＴＦ非活動化の数は、極めてランダムであり得、メモリ消費量に関して潜在的な問題を生じ得る。ソースシンボルの数が極めて大きく、オーバーヘッドが極めて小さい場合、誤り確率は、容認できないほど１に近接し得る。
【０１７４】
小さいオーバーヘッドに対する高い誤り確率のために、ソースシンボルの数が大きいとき、良好なシステマティック情報を発見することがますます困難になり得る。本明細書では、システマティック情報は、Ｓｈｏｋｒｏｌｌａｈｉ  ＩＩＩの意味においてシステマティック符号を構築することが可能になるために、エンコーダとデコーダとに提供するために必要とされる情報を指す。その上、システマティック情報が取得されたときはいつでも、「平均」では符号はゼロオーバーヘッドにおいて失敗するはずであるので、符号の挙動が、平均的な挙動とは極めてかけ離れていることが予想される。
【０１７５】
永久的非活動化を用いた連鎖反応符号の構築のためのパラメータの一部は、図４のＬＴエンコーダ２５０のために使用される度数分布と、ＰＩエンコーダ２４０のパラメータと、永久的非活動化シンボルの数の判断と、冗長静的シンボルの数およびそれらの構造の判断とを含み得、特定の方法の乱数が、発生され、図１中のエンコーダ１１５とデコーダ１５５との間で共有され得る。
【０１７６】
ＲＱ符号を使用するエンコーダおよびデコーダ
本明細書で説明する方法を使用する、以下「ＲＱ符号」と呼ぶ符号の好適な実施形態が、付録Ａのセクション５に詳細に規定されている。付録Ａの残りは、ブロードキャストまたはマルチキャストネットワークを介したオブジェクトの信頼できる配信にＲＱ符号を適用する１つの方法について説明している。
【０１７７】
ＲＱ符号は、システマティック符号を実装するために以上および以下で説明する方法を使用し、システマティック符号は、すべてのソースシンボルが、生成され得る被符号化シンボルの中にあることを意味し、したがって、被符号化シンボルは、元のソースシンボルと、エンコーダによって生成されたリペアシンボルとの組合せであると見なされ得る。
【０１７８】
以上の符号のいくつかは良好な特性を有するが、それらの実際的適用を高めるいくつかの改善がある。重要な２つの潜在的な改善は、より急なオーバーヘッド障害曲線と、ソースブロック当たりのより大きい数のサポートされるソースシンボルとである。オーバーヘッドは、受信された被符号化シンボルの数と、ソースブロック中のソースシンボルの数との間の差であり、たとえば、オーバーヘッド２は、Ｋ個のソースシンボルでソースブロックを復号するためにＫ＋２個の被符号化シンボルが受信されたことを意味する。所与のオーバーヘッドにおける失敗確率は、受信された被符号化シンボルの数がそのオーバーヘッドに対応するとき、デコーダがソースブロックを完全に復元することに失敗する確率である。オーバーヘッド障害曲線は、オーバーヘッド０において開始するオーバーヘッドの増加に応じて、失敗確率がどのように下がるかのプロットである。オーバーヘッド障害曲線は、オーバーヘッドに応じてデコーダの失敗確率が高速または急に低下する場合により優れている。
【０１７９】
ランダムバイナリコードは、作業不能な計算複雑さとともに、各追加のオーバーヘッドシンボルについて失敗確率が本質的に係数２だけ下がるオーバーヘッド失敗確率曲線を有するが、本説明の主題は、オーバーヘッド失敗確率曲線に限定され、計算複雑さには限定されない。いくつかのアプリケーションでは、これは十分なオーバーヘッド障害曲線であるが、いくつかの他のアプリケーションでは、より急なオーバーヘッド障害曲線が好適である。たとえば、ストリーミングアプリケーションでは、ソースブロック中のソースシンボルの数の範囲は広くなり得、たとえば、Ｋ＝４０、Ｋ＝２００、Ｋ＝１０００、Ｋ＝１００００になる。良好なストリーミングエクスペリエンスを提供するために、失敗確率は低いこと、たとえば、１０-5または１０-6の失敗確率が必要とされ得る。帯域幅はしばしばストリーミングアプリケーションのために貴重であるので、ソースシンボルの部分として送られるリペアシンボルの割合は最小限に抑えられなければならない。たとえば、Ｋ＝２００をもつソースブロックを使用するとき、ストリームが送られるネットワークが１０％までのパケット損失に対して保護されなければならず、失敗確率が多くて１０-6であることが必要とされると仮定する。ランダムバイナリコードは、１０-6の失敗確率を達成するためには少なくとも２０のオーバーヘッドを必要とし、すなわち、受信機は、この失敗確率で復号するために２２０個の被符号化シンボルを必要とする。ｃｅｉｌ（２２０／（１−０．１））＝２４５であるので、要件を満たすためにソースブロックごとに合計２４５個の被符号化シンボルが送られる必要がある。したがって、リペアシンボルは、ストリームの帯域幅要件に追加の２２．５％を追加する。
【０１８０】
本明細書と付録Ａのセクション５とにおいて説明されているＲＱ符号は、Ｋ′のすべてのサポートされる値について値がＫ＝Ｋ′である場合、ならびにＫの最後のサポートされる値を除くすべてについて値がＫ＝１およびＫ＝Ｋ′＋１である場合、それぞれ、オーバーヘッド０、１、および２に対して１０-2、１０-4、および１０-6よりも小さい失敗確率を達成する。テストは、様々な損失確率、たとえば、１０％、２０％、５０％、７０％、９０％および９５％の損失確率に対して行われている。
【０１８１】
ＲＱ符号を使用する上記の例では、２のオーバーヘッドは１０-6の失敗確率を達成するのに十分であり、したがって、ｃｅｉｌ（２０２／（１−０．１））＝２２５であるので、要件を満たすためにソースブロックごとに合計２２５個の被符号化シンボルのみが送られる必要がある。この場合、リペアシンボルは、ストリームの帯域幅要件に追加の１２．５％を追加し、すなわち、ランダムバイナリコードによって必要とされる帯域幅オーバーヘッドよりも１０％少ない。したがって、ＲＱ符号改善されたオーバーヘッド障害曲線は、いくつかの極めて肯定的な実際的結果を有する。
【０１８２】
ソースブロックごとに多数のソースシンボルをサポートすることが望ましい適用例がある。たとえば、モバイルファイルブロードキャスト適用例では、ネットワーク効率の観点からは、ファイルを単一のソースブロックとして符号化すること、または、より一般的には、ファイルを、実際的である程度に少数のソースブロックに区分することが有利である。たとえば、５０００００００バイトのファイルをブロードキャストすべきであり、被符号化シンボルを搬送するために各パケット内で利用可能なサイズが１０００バイトであると仮定する。ファイルを単一のソースブロックとして符号化することは、Ｋ＝５００００の値がサポートされることを必要とする。（実質的により少ないメモリを使用した復号を可能にする前述のサブブロック化技法があることに留意されたい。）
符号のためにサポートされるソースシンボルの数が制限され得る数個の理由がある。１つの典型的な理由は、リードソロモン符号の場合など、Ｋが増加するにつれて計算複雑さが法外になることであるが、これは、連鎖反応符号などの符号については当てはらない。別の理由は、Ｋが増加するにつれて、ゼロオーバーヘッドにおける失敗確率がほぼ１にまで増加して、良好なシステマティック符号構築を生じるシステマティックインデックスを発見することがより困難になることであり得る。ゼロオーバーヘッドにおける失敗確率は、これは、本質的に、システマティックインデックスがランダムに選定されたとき、得られたシステマティック符号構築が、最初のＫ個の被符号化シンボルがＫ個のソースシンボルを復号することが可能である特性を有する確率であるので、良好な符号構築を導出することの困難さを規定することができる。
【０１８３】
ＲＱ符号設計のオーバーヘッド障害曲線が、Ｋのすべての値について非常に急であるので、良好なシステマティックインデックスを発見し、したがって、Ｋのはるかにより大きい値をサポートすることは容易に可能である。付録Ａのセクション５に記載されているＲＱ符号は、５６４０３までのＫの値をサポートし、またソースブロックごとに１６７７７２１６までの被符号化シンボルの総数をサポートする。ＲＱ符号のサポートされる値に対するこれらの制限は、知覚されたアプリケーション要件に基づく実際的考慮により設定されたものであり、ＲＱ符号設計の制限によるものではない。付録Ａに示す実施形態以外の他の実施形態は、異なる値を有し得る。
【０１８４】
ＲＱ符号は、サポートされる様々なソースブロックサイズの数を次のように制限する。被符号化または復号されるべきＫ個のソースシンボルをもつソースブロックを仮定すれば、Ｋ′値は、付録Ａのセクション５．６に示すテーブルに基づいて選択される。テーブル中の第１の列は、Ｋ′の可能な値を記載している。選択されたＫ′の値は、Ｋ≦Ｋ′であるような可能性のうちの最小値である。Ｋ個のソースシンボルＣ′（０），．．．，Ｃ′（Ｋ−１）は、０に設定された値をもつＫ′−Ｋ個のシンボルＣ′（Ｋ），．．．，Ｃ′（Ｋ′−１）でパディングされて、Ｋ′個のソースシンボルＣ′（０），．．．，Ｃ′（Ｋ′−１）を備えるソースブロックを生成し、次いで、このパディングされたソースブロックに対して符号化および復号が実行される。
【０１８５】
上記の手法は、サポートされる必要があるシステマティックインデックスの数を低減する、すなわち、数万の代わりに数百のみに低減するという利益を有する。Ｋのオーバーヘッド失敗確率は、選択されたＫ′のオーバーヘッド障害曲線と同じであるので、Ｋのオーバーヘッド失敗確率に関する欠点はない。Ｋの値が与えられれば、デコーダは、Ｋ′の値を計算し、Ｃ′（Ｋ），．．．，Ｃ′（Ｋ′−１）の値を０に設定することができ、したがって、デコーダは、ソースブロックのＫ′個のソースシンボルのうちの残りのＫ個を復号しなければならないだけである。唯一の潜在的な欠点は、わずかにより多くのソースシンボルを符号化および復号するために、わずかにより多くのメモリまたは計算リソースが必要とされ得ることである。しかしながら、Ｋ′の連続する値の間の間隔は、Ｋ′がより大きい値である場合、ほぼ１％であり、したがって、この潜在的な欠点は無視できる。
【０１８６】
ＫからＫ′へのソースブロックのパディングのために、ＲＱ符号内の被符号化シンボルＣ′（０），Ｃ′（１），．．．の識別子は内部シンボル識別子（Internal Symbol Identifier）（ＩＳＩと略す）と呼ばれ、ただし、Ｃ′（０），．．．，Ｃ′（Ｋ′−１）はソースシンボルでありＣ′（Ｋ′），Ｃ′（Ｋ′＋１），．．．はリペアシンボルである。
【０１８７】
エンコーダとデコーダとを採用する外部アプリケーションは、元のソースシンボルＣ′（０），．．．，Ｃ′（Ｋ−１）を識別するために０からＫ−１にわたり、リペアシンボルＣ′（Ｋ′），Ｃ′（Ｋ′＋１），．．．を識別するためにＫ，Ｋ＋１，．．．と続く、符号化シンボル識別子（ＥＳＩと略す）とも呼ばれる、被符号化シンボル識別子を使用する。したがって、ＲＱ符号内のＩＳＩ  Ｘで識別されたリペアシンボルＣ′（Ｘ）は、ＥＳＩ  Ｘ−（Ｋ′−Ｋ）を用いて外部に識別される。これについては、付録Ａのセクション５．３．１においてより詳細に説明されている。
【０１８８】
ＲＱ符号の符号化と復号とは、２つのタイプの関係、すなわち、中間シンボル間の制約関係、および中間シンボルと被符号化シンボルとの間のＬＴ−ＰＩ関係によって定義される。制約関係は、図１２または図１５に示す例の場合のように、ＳＥ行列によって定義された中間シンボル間の関係に対応する。ＬＴ−ＰＩ関係は、図１２または図１５に示す例の場合のように、ＬＴ行列とＰＩ行列とによって定義された中間シンボルと被符号化シンボルとの間の関係に対応する。
【０１８９】
符号化は、（１）ソースシンボル値と、（２）ソースシンボルと中間シンボルとの間のＬＴ−ＰＩ関係と、（３）中間シンボル間の制約関係とに基づいて中間シンボル値を判断することによって進む。リペアシンボルの値は、中間シンボルとリペアシンボルとの間のＬＴ−ＰＩ関係に基づいて中間シンボルから生成され得る。
【０１９０】
同様に、復号は、（１）受信された被符号化シンボル値と、（２）受信された被符号化シンボルと中間シンボルとの間のＬＴ−ＰＩ関係と、（３）中間シンボル間の制約関係とに基づいて中間シンボル値を判断することによって進む。消失したソースシンボルの値は、中間シンボルと消失したソースシンボルとの間のＬＴ−ＰＩ関係に基づいて中間シンボルから生成され得る。したがって、符号化および復号は、本質的に対称的なプロシージャである。
【０１９１】
例示的なハードウェア構成要素
図３０〜図３１に、上記で説明した方法を実装するために使用され得るハードウェアのブロック図を示す。各要素は、汎用プロセッサまたはカスタム目的プロセッサ（custom-purpose processor）またはその組合せによって実行されるハードウェア、プログラムコードまたは命令とすることができる。
【０１９２】
図３０に、プログラムストア１００２に記憶され、プロセッサ１００４によって実行されるハードウェアモジュール、ソフトウェアモジュール、またはプログラムコードの部分として、場合によっては、図に示すように分離されていないコードの集合的なユニットとして実装され得る例示的な符号化システム１０００を示す。符号化システム１０００は、ソースシンボルとパラメータ情報を搬送する入力信号を受信し、その情報を搬送する信号を出力する。
【０１９３】
入力インターフェース１００６は、ソースシンボルバッファ１００８への着信ソースシンボルを記憶する。ソース中間シンボル生成器１０１０は、ソースシンボルから中間シンボルを生成する。これは、いくつかの実施形態におけるパススルー、および（「システマティック」実施形態などの）他の実施形態におけるデコーダモジュールとすることができる。
【０１９４】
冗長シンボル生成器１０１２は、ソースシンボルから冗長シンボルを生成する。これは連鎖反応コーダ、ＬＤＰＣコーダ、ＨＤＰＣコーダ、または同様のものとして実装され得る。非活動化器（inactivator）１０１４は、場合によっては、ソースシンボル、中間シンボルおよび／または冗長シンボルを受信し、ＰＩバッファ１０１８にそれらの一部である永久的非活動シンボルを記憶し、その他を出力エンコーダ１０１６に与える。このプロセスは、物理的ではなく、単に論理的に実装され得る。
【０１９５】
ＸＯＲ演算子などの演算子１０２０は、出力エンコーダ１０１６からの１つまたは複数の被符号化シンボル（いくつかの実施形態では、１つ）に対して演算し、ＰＩバッファ１０１８からのＰＩシンボルのうちの１つまたは複数（いくつかの実施形態では、１つ）に対して演算し、演算の結果は、システム１０００から信号を出力する送信インターフェース１０３０に与えられる。
【０１９６】
図３１に、プログラムストア１１０２に記憶され、プロセッサ１１０４によって実行されるハードウェアモジュール、ソフトウェアモジュール、またはプログラムコードの部分として、場合によっては、図に示すように分離されていないコードの集合的なユニットとして実装され得る例示的な復号システム１１００を示す。一部のプロセスは、物理的ではなく、単に論理的に実装され得る。
【０１９７】
復号システム１１００は、入力信号および場合によっては他の情報を取り入れ、可能な場合、ソースデータを出力する。入力信号は、バッファ１１０８に受信シンボルを記憶する受信インターフェース１１０６に与えられる。受信シンボルのＥＳＩは行列生成器１１１０に与えられ、行列生成器１１１０は、受信された特定のシンボルに応じて、本明細書で説明する行列を生成し、結果を行列メモリ１１１２に記憶する。
【０１９８】
スケジューラ１１１４は、行列メモリ１１１２から行列の細部を読み取ることができ、スケジュールメモリ１０１６に記憶されるスケジュールを生成する。スケジューラ１１１４はまた、完了したときに、完了信号（done signal）を生成し、ＰＩ行列をＰＩ解決器（solver）１１１８に搬送する。ＰＩ解決器１１１８は、解決されたＰＩシンボル値を解決器１１２０に与え、解決器１１２０はまたスケジュールを使用して、受信シンボルとスケジュールとＰＩシンボルとから中間シンボルを復号する。
【０１９９】
中間シンボルは、エンコーダまたはパススルーとすることができる、中間ソースシンボル生成器１１２２に与えられる。中間ソースシンボル生成器１１２２の出力は、ソースデータ、またはどんなソースデータが出力のために利用可能であるかを出力する出力インターフェース１１２４に与えられる。
【０２００】
他の考慮事項
いくつかの状況では、復号可能性の向上が必要であり得る。本明細書の他で与えられる例では、被符号化シンボルはＬＴネイバーとＰＩネイバーの両方を有したが、ＬＤＰＣシンボルは、ＬＴネイバー、またはＨＤＰＣシンボルの中でないＰＩネイバーを有するのみだった。いくつかの事例では、ＬＤＰＣシンボルが、ＨＤＰＣシンボルを含むＰＩネイバーをも有する場合、復号可能性は改善される。ＰＩシンボルのすべてのうちのネイバーがＨＤＰＣシンボルを含む場合、ＬＤＰＣシンボルに値する復号は、被符号化シンボルの復号とより類似していることがある。本明細書の他で説明するように、両方の利点が存在し得るように、（符号化および復号するのが容易であり得る）ＬＴシンボルに依存し、ＰＩシンボルにも依存するシンボルは、（高い信頼性復号を行うことができる）ＨＤＰＣシンボルを含む。
【０２０１】
一例では、各ＬＤＰＣシンボルは２つのＰＩネイバーを有し、すなわち、ＬＤＰＣシンボルの値は２つのＰＩシンボルの値に依存する。
【０２０２】
また、いくつかの状況では、重複被符号化シンボルの生成を低減して復号可能性が改善され得、２つの被符号化シンボルは、まったく同じ全ネイバーセットを有する場合、重複であり、被符号化シンボルのための全ネイバーセットはＬＴネイバーセットとＰＩネイバーセットとから構成される。同じ全ネイバーセットをもつ重複被符号化シンボルは、それらが生成された中間ソースブロックに関する、まったく同じ情報を搬送し、したがって、２つ以上の重複被符号化シンボルを受信したことからの復号には、重複被符号化シンボルのうちの１つを受信したことからによるよりも良い見込みがなく、すなわち、２つ以上の重複シンボルの受信は、受信オーバーヘッドを増し、重複のうちの被符号化シンボルの１つのみが復号のために有用である。
【０２０３】
好ましい特性は、各受信された被符号化シンボルが他の受信された被符号化シンボルの重複でないということであり、これは、各受信された被符号化シンボルが復号のために有用であり得ることを意味することに起因する。したがって、そのような重複の数を低減するか、または重複の発生確率を低減することが好ましいことがある。
【０２０４】
１つの手法は、各被符号化シンボルが有することができるＬＴネイバーの数を限定することである。たとえば、Ｗ個の可能なネイバーがある場合、ネイバーの最大数はＷ−２に限定され得る。これは、場合によっては、すべてのＷ個の可能なネイバーを備える近傍セットが可能ではないので、全近傍セットが重複されるという見込みを低減する。制約がＤｅｇ［ｖ］＝ｍｉｎ（ｄ，Ｗ−２）である場合、度数Ｗ−２のＷ＊（Ｗ−１）／２個の異なる近傍セットがある。したがって、重複の全ネイバーセットが被符号化シンボルのために生成される可能性がより低くなり得る。Ｗｇ＝２以外のあるＷｇについてのｍｉｎ（ｄ，Ｗ−Ｗｇ）など、他の制約、または何らかの他の制約が代わりに使用され得る。
【０２０５】
単独でまたは上記の重複低減技法とともに使用され得る別の技法は、被符号化シンボルのための重複ＰＩネイバーがある可能性がより低く、したがって、重複の全ネイバーセットが被符号化シンボルのために生成される可能性がより低くなるように、各被符号化シンボルについて２つ以上のＰＩネイバーを選定することである。ＬＴネイバーが生成されるのと同様の方法で、たとえば、付録Ａ、セクション５．３．５．４に示すように、以下の符号の断片に従って第１に（ｄ１，ａ１，ｂ１）を生成することによって、ＰＩネイバーは生成され得る。
【数９】
0005602858.tif 000010
【０２０６】
この例では、ＰＩネイバーの数ｄ１に対して定義される非自明な（non-trivial）ランダム度数分布があり、その分布は、ＬＴネイバーの選定された数ｄに依存し、ＬＴネイバーの数がより小さいとき、ＰＩネイバーの数はより大きくなる可能性があることに留意されたい。これは、被符号化シンボルの全度数が、重複被符号化シンボルが生成され、したがって受信される見込みを低減するようになる特性を与える。
【０２０７】
付録Ａ、セクション５．３．５．３に示す（ｄ１，ａ１，ｂ１）、および以下の符号の断片によって定義されるネイバーを使用して、被符号化シンボル値は生成され得る。
【数１０】
0005602858.tif 000011
【０２０８】
これらの復号可能性特徴をサポートするために、または別に復号可能性を実現するために、付録Ａ中のセクション５．６の表２に示すものなど、Ｋ′の値についての異なるシステマティックインデックスＪ（Ｋ′）が使用され得る。
【０２０９】
システマティックインデックスＪ（Ｋ′）を生成するために送信および／または受信システムにおいて実行可能なプロセスの例は、次のように示される。可能なＫ′のリスト中の各Ｋ′について、一般に、適切にプログラムされた回路またはプロセッサによって実行され得る１つのプロセスは、いくつかのインデックスを適合性について検査することである。たとえば、Ｊ＝１．．．１０００［または何らかの他の範囲］の間、回路／プロセッサは、以下の基準が可能なシステマティックインデックスＪに関して満たされるかどうかを検査し得る。
【０２１０】
（ａ）復号は、Ｋ′個のソースシンボルからゼロオーバーヘッドで可能であるか？
はいの場合、オンザフライ非活動化の数を記録する。
【０２１１】
（ｂ）（ＥＳＩ  ０，．．．，Ｋ′／０．０６をもつ）第１のＫ′／０．０６個の可能な被符号化シンボルのうちに、重複の全ネイバーセットがあるか？［他のしきい値が代わりに使用され得る。］
（ｃ）１００００ラン［またはある他のテスト］内で第１のＫ′個の受信された被符号化シンボルを使用して復号したときに、各被符号化シンボルが他の被符号化シンボルとは無関係に各ランにおいて確率０．９３［またはある他のしきい値］で損失したとき、復号失敗確率は０．００７［またはある他のしきい値］を下回るか？
次いで、回路／プロセッサは、上記の基準（ａ）、（ｂ）および（ｃ）を満たす可能なシステマティックインデックスＪのうちから、ステップ（ａ）においてオンザフライ非活動化の平均数を記録したシステマティックインデックスを選定する。
【０２１２】
上記の選択基準の多くの変形態があることに留意されたい。たとえば、場合によっては、上記の（ａ）、（ｂ）および（ｃ）を満たし、指定された数のラン内でステップ（ｃ）において最も少数の復号失敗を生じるシステマティックインデックスを選定することが好ましいことがある。別の例として、オンザフライ非活動化の数と復号失敗確率との組合せは、システマティックインデックスを選定するときに考慮に入れられ得る。別の例として、各Ｋ′値についての複数のシステマティックインデックスは利用可能であり得、その場合、それらの１つは特定の適用例内でランダムに選定される。
【０２１３】
付録Ａのセクション５．６中の表２に記載されたＫ′値のためのシステマティックインデックスは、付録Ａで説明する符号のためのシステマティックインデックスの１つの潜在的なリストである。
【０２１４】
サブブロック化プロセスの変形態
さらなる処理のために、ブロックをより小さいユニットに物理的にまたは論理的に区分するサブブロック化は、様々な目的のために知られている。たとえば、サブブロック化はＩＥＴＦ  ＲＦＣ５０５３において使用されている。サブブロック化はまた、米国特許第７，０７２，９７１号から知られている。サブブロック化方法の主要な用途の１つは、ＦＥＣデコーダを使用してデータブロックを復元するために受信機におけるデータブロックのサイズよりもはるかに小さいメモリの量を使用すると同時に、データの大きいブロックがＦＥＣ符号によって単一のエンティティとして保護されることを可能にすることである。
【０２１５】
ＩＥＴＦ  ＲＦＣ５０５３に記載されているサブブロックの数を選定するための１つの方法は、パラメータの多くの妥当な設定のための良好なソースブロック区分およびサブブロック区分を提供するが、それは、いくつかの状況では、サブブロックサイズＷＳに対する上限を厳密に満たし得ない解を作り出し得る（とはいえ、これらの場合でも、それは、サブブロックサイズが、サブブロックサイズに対する所与の制約ＷＳよりも大きい適度のファクタであるソリューションを作り出す）。（ソースブロック中のソースシンボルの最大数がＩＥＴＦ  ＲＦＣ５０５３の場合よりもはるかに大きい）ｄｒａｆｔ−ｌｕｂｙ−ｒｍｔ−ｂｂ−ｆｅｃ−ｒａｐｔｏｒｇ−ｏｂｊｅｃｔ−００における別の例として、セクション４．２において、Ｔ、Ｚ、およびＮを計算するための以下の秘訣が与えられ、Ｔはシンボルサイズであり、Ｚはファイル（またはデータブロック）が区分されたソースブロックの数であり、Ｎはサブブロックの数である。また、Ｐ′はシンボルのためのパケットペイロードサイズであり、Ｆはバイト単位のファイルサイズであり、Ｋ′＿ｍａｘは、サポートされるソースシンボルの最大数（たとえば、５６４０４）であり、Ａｌは、より効率的な復号を可能にするために、シンボルまたはサブシンボルのサイズがＡｌバイトの倍数となるべきであることを指定するアラインメントファクタであり、たとえば、現代のＣＰＵの場合にはＡｌ＝４が選好され、ＷＳは、バイト単位のサブブロックサイズに対する所望の上限である。
【０２１６】
パラメータＴ、Ｚ、およびＮの導出がＦ、Ａｌ、およびＰ′の値に基づいて送信側または代替サーバにおいて行われ得ることに留意されたい。受信機は、ファイルまたはデータブロックに関係する、受信されたパケット中のファイルまたはデータブロックのサブブロックおよびソースブロック構造を判断するために、Ｆ、Ａｌ、Ｔ、Ｚ、およびＮの値を知るだけでよい。受信機は、受信されたパケットのサイズからＰ′を判断することができる。また、送られ、受信されたパケットは、一般にパケットのコンテンツを識別する他の情報、たとえば、一般にサイズが４バイトであり、パケット中で搬送されるソースブロック番号（ＳＢＮ）と第１のシンボルの被符号化シンボル識別子（ＥＳＩ）とを搬送するＦＥＣペイロードＩＤを含んでいることに留意されたい。
【０２１７】
Ｔ、Ｚ、Ｎを計算するための、ｄｒａｆｔ−ｌｕｂｙ−ｒｍｔ−ｂｂ−ｆｅｃ−ｒａｐｔｏｒｇ−ｏｂｊｅｃｔ−００のセクション４．２に記載されている以前の方法は、Ｔ、Ｚ、Ｎを以下の値に設定することである。
【数１１】
0005602858.tif 000012
【０２１８】
これらの計算では、ｃｅｉｌ（）はそれの入力以上の最小整数を出力する関数であり、ｆｌｏｏｒ（）はそれの入力以下の最大整数を出力する関数である。また、ｍｉｎ（）は、それの入力の最小値を出力する関数である。
【０２１９】
ソースブロックおよびサブブロック区分を導出するこの方法を用いたパラメータのいくつかの設定の１つの問題は、Ｔ／Ａｌがｃｅｉｌ（ｃｅｉｌ（Ｋｔ／Ｚ）＊Ｔ／ＷＳ）よりも小さい場合、サブブロックサイズＷに対する上限が尊重され得ないことである。
【０２２０】
潜在的な第２の問題は、これにより、サブシンボルが、一般に４バイトに設定されるＡｌと同じくらい小さくなることが可能になり、あまりに小さくて実際には効率的でないことがあるということである。一般に、サブシンボルサイズが小さくなればなるほど、サブブロックを符号化または復号するための処理オーバーヘッドはより多くなる。さらに、特に受信機において、より小さいサブシンボルサイズは、より多くのサブブロックが多重分離され、復号される必要があることを意味し、これにより、ＣＰＵサイクルおよびメモリアクセスなどの受信機リソースを消費することがある。一方、より小さい許容サブシンボルサイズは、ソースブロックが、サブブロックサイズに対して指定された上限ＷＳを尊重する、より多くのサブブロックに区分され得ることを意味する。したがって、より小さいサブシンボルは、より大きいソースブロックがサポートされることを可能にし、したがって、このソースブロック上に与えられるＦＥＣ保護は、より良い保護とより良いネットワーク効率とを生じる。実際には、多くの場合、サブシンボルが少なくとも指定された最小サイズであることを保証することが好ましく、それにより、受信機における処理要件およびメモリ要件と、ネットワークリソースの効率的な使用との間のより良い平衡を得るための機会を与える。
【０２２１】
以下は、Ｔ、Ｚ、Ｎを計算するための、ｄｒａｆｔ−ｌｕｂｙ−ｒｍｔ−ｂｂ−ｆｅｃ−ｒａｐｔｏｒｇ−ｏｂｊｅｃｔ−００のセクション４．２に記載されている以前の方法を使用して導出されたパラメータの例である。
【０２２２】
入力：
【数１２】
0005602858.tif 000013
【０２２３】
計算：
【数１３】
0005602858.tif 000014
【０２２４】
この例では、２５６個のサブブロックを備える１つのソースブロックがあり、各サブブロックは約２２０ＫＢ（ＷＳよりも大きい）であり、少なくともいくつかのサブブロックはサブシンボルサイズ４バイト（極めて小さい）を有する。
【０２２５】
第３の問題は、ＡＬ−ＦＥＣソリューションがすべての可能な数のソースシンボルをサポートし得ないことであり、すなわち、それは、Ｋ′値の選択されたリストのみをサポートし得、Ｋ′は、ソースブロック中のソースシンボルのサポートされる数であり、さらには、ソースブロック中で所望されるソースシンボルの実際の数ＫがＫ′値の１つでない場合、Ｋは最も近いＫ′値までパディングされ、それは、以上のことから、使用されるソースブロックのサイズが、計算されたＫ値よりもいくぶん大きいとすることができることを意味する。
【０２２６】
次に、上記で説明した以前の方法に対する改善である新しいサブブロック化方法について説明する。説明のために、サブブロック化のためのモジュールは、区分されるべきデータＦと、ＷＳ、Ａｌ、ＳＳおよびＰ′を含む値とをそれの入力として取り得、それらの変数の意味について以下でより詳細に説明する。
【０２２７】
ＷＳは、受信機における作業メモリ中で復号可能である、場合によってはバイト単位の最大サイズサブブロックに対して与えられた制約を表す。Ａｌはメモリアラインメントパラメータを表す。シンボルおよびサブシンボルがメモリアラインメント境界に沿ってメモリ中で整合させられた場合、受信機メモリがより効率的に動作し得るので、Ａｌを追跡し、Ａｌバイトの倍数単位で値を記憶することは有用であり得る。たとえば、一般に、多くのメモリデバイスが４バイト境界上でメモリ中のデータを当然アドレッシングするので、Ａｌ＝４である。Ａｌの他の値、たとえば、Ａｌ＝２またはＡｌ＝８も可能である。一般に、Ａｌは、すべての多くの可能な受信機の最小公倍数メモリアラインメントに設定され得る。たとえば、いくつかの受信機が２バイトメモリアラインメントをサポートし、他の受信機が４バイトメモリアラインメントをサポートする場合、Ａｌ＝４が推奨されるであろう。
【０２２８】
パラメータＳＳは、サブシンボルサイズに対する下限がＳＳ＊Ａｌバイトであるように、サブシンボルサイズに対する好適な下限に基づいて判断される。復号演算は一般にサブシンボル上で実行されるので、サブシンボルサイズをＡｌの倍数にすることが好ましいことがある。
【０２２９】
以下は、データＦをＺ個のソースブロックに区分し、次いで、それらのＺ個のソースブロックをＮ個のサブブロックに区分するための方法の詳細な説明である。本明細書では、Ｐ′は、送られるべきシンボルのパケット内の利用可能なバイトを表す、メモリに記憶された（または暗示された）変数を指し、Ｐ′はＡｌの倍数であると仮定される。Ｔは、送られたパケット内に配置されるべきシンボルのサイズを表す変数である。他の変数はテキストから推測され得る。
【０２３０】
Ｔ、ＺおよびＮを判断するための新しいサブブロック化方法
【数１４】
0005602858.tif 000015
【０２３１】
これらのパラメータが判断されると、Ｚ個のソースブロックの各々のサイズ、および各ソースブロックのＮ個のサブブロックのサブシンボルのサイズは、ＩＥＴＦ  ＲＦＣ５０５３に記載されているように、すなわち、Ｋｔ＝ｃｅｉｌ（Ｆ／Ｔ）、（ＫＬ，ＫＳ，ＺＬ，ＺＳ）＝Ｐａｒｔｉｔｉｏｎ［Ｋｔ，Ｚ］、および（ＴＬ，ＴＳ，ＮＬ，ＮＳ）＝Ｐａｒｔｉｔｉｏｎ［Ｔ／Ａｌ，Ｎ］であるように判断され得る。
【０２３２】
Ｋｔはファイル中のソースシンボルの数である。サブブロックモジュールでは、Ｋｔ個のソースシンボルはＺ個のソースブロックに区分され、ＫＬ個のソースシンボルの場合それぞれＺＬ個のソースブロックに区分され、ＫＳ個のソースシンボルの場合それぞれＺＳ個のソースブロックに区分される。次いで、ＫＬはＫＬ′まで丸められ、ＫＬ′は少なくともＫＬであるソースシンボルのサポートされる最小数であり（追加のＫＬ′−ＫＬ個のゼロパディングシンボルが、符号化および復号のためにソースブロックに追加されるが、これらの追加のシンボルは、一般に送られない、または受信されない）、同様に、ＫＳはＫＳ′まで丸められ、ＫＳ′は、少なくともＫＳであるソースシンボルのサポートされる最小数である（追加のＫＳ′−ＫＳ個のゼロパディングシンボルが、符号化および復号のためにソースブロックに追加されるが、これらの追加のシンボルは、一般に送られない、または受信されない）。
【０２３３】
（サブブロックモジュール、別のソフトウェアモジュール、またはハードウェアによって実行される）これらの計算では、ソースブロックのためのソースシンボルの数は、それらの数が合計でファイル中のソースシンボルの数Ｋｔになるという制約を条件として、できるだけ等しくなることを保証する。また、これらの計算では、サブブロックのためのサブシンボルのサイズは、それらがＡｌの倍数であり、それらのサイズが合計でシンボルサイズになるという制約を条件として、できるだけ等しくなることを保証する。
【０２３４】
次いで、サブシンボルパラメータＴＬ、ＴＳ、ＮＬおよびＮＳが計算され、より大きいサブシンボルサイズＴＬ＊Ａｌを使用するＮＬ個のサブブロックがあり、より小さいサブシンボルサイズＴＳ＊Ａｌを使用するＮＳ個のサブブロックがある。関数Ｐａｒｔｉｔｉｏｎ［Ｉ，Ｊ］は、ソフトウェアまたはハードウェアにおいて実装され、一連の４つの整数（ＩＬ、ＩＳ、ＪＬ、ＪＳ）である出力をもつ関数として定義され、ＩＬ＝ｃｅｉｌ（Ｉ／Ｊ）、ＩＳ＝ｆｌｏｏｒ（Ｉ／Ｊ）、ＪＬ＝Ｉ−ＩＳ＊Ｊ、およびＪＳ＝Ｊ−ＪＬである。
【０２３５】
これらの新しい方法の性質のいくつかに注目すべきである。サブブロックモジュールは、使用される最小サブシンボルサイズに対して導出される下限を判断することができる。上式から、ＴＳ＝ｆｌｏｏｒ（Ｔ／（Ａｌ＊Ｎ））であることが知られ、ＴＳ≦ＴＬなので、ＴＳ＊Ａｌは、使用される最小サブシンボルサイズである。Ｎ＝Ｎ＿ｍａｘのとき、最小サブシンボルが使用されることに留意されたい。正のＸおよびＹの場合、Ｘ／（ｆｌｏｏｒ（Ｙ））≧Ｘ／Ｙを使用して、ＴＳは、少なくともｆｌｏｏｒ（Ｔ／（Ａｌ＊ｆｌｏｏｒ（Ｔ／（ＳＳ＊Ａｌ））））であり、これは、少なくともｆｌｏｏｒ（ＳＳ）＝ＳＳである。これらのことにより、本明細書で説明する区分方法によって生成された最小サブシンボルサイズは、必要に応じて、少なくともＴＳ＊Ａｌ＝ＳＳ＊Ａｌになる。
【０２３６】
サブブロックモジュールは、最大サブシンボルサイズに対して導出される上限を判断することができる。使用される最大サブブロックサイズはＴＬ＊Ａｌ＊ＫＬ′であり、ＫＬ′は、少なくともＫＬ＝ｃｅｉｌ（Ｋｔ／Ｚ）である上記の表中の最小Ｋ′値である。Ｎの定義によって、ＫＬ′≦ＫＬ（Ｎ）、およびＴＬ＝ｃｅｉｌ（Ｔ／（Ａｌ＊Ｎ））であることに留意されたい。ＫＬ（Ｎ）≦ＷＳ／（Ａｌ＊（ｃｅｉｌ（Ｔ／（Ａｌ＊Ｎ））））なので、結果としてＷＳ≧ＫＬ（Ｎ）＊Ａｌ＊ｃｅｉｌ（Ｔ／（Ａｌ＊Ｎ））≧ＫＬ′＊Ａｌ＊ＴＬになる。
【０２３７】
変数Ｎ＿ｍａｘは、サイズＴのソースシンボルが区分され得るサブシンボルの最大数を表すことができる。Ｎ＿ｍａｘをｆｌｏｏｒ（Ｔ／（ＳＳ＊Ａｌ））に設定することは、最小サブシンボルサイズが少なくともＳＳ＊Ａｌであることを保証する。ソースブロックのサブブロックの各々のサイズが高々ＷＳであることを保証するために、ＫＬ（ｎ）は、ソースブロックのシンボルがそれぞれｎ個のサブシンボルに区分されるときにサポートされ得るソースブロック中のソースシンボルの最大数である。
【０２３８】
ソースブロックの数Ｚは、各ソースブロック中のソースシンボルの数が高々ＫＬ（Ｎ＿ｍａｘ）であるという制約を条件としてできるだけ小さくなるように選定され得、ＫＬ（Ｎ＿ｍａｘ）は、各ソースシンボルが少なくともサイズＳＳ＊Ａｌのサブシンボルに区分され得、得られたサブブロックのサイズが高々ＷＳであることを保証する。サブブロックモジュールは、Ｚの値から、ソースブロックの数とＺ個のソースブロックの各々におけるシンボルの数とを判断する。
【０２３９】
この区分方法によって生成されるよりも小さいＺの値が使用される場合、ＷＳよりも大きいソースブロックのうちの１つのサブブロックが存在することになるか、またはそうでなければ、ＳＳ＊Ａｌよりも小さいサブシンボルサイズを有するソースブロックのうちの１つのサブブロックが存在することになるかのいずれかであることに留意されたい。また、この区分方法が生成するソースブロックの最小のものは、これらの２つの制約を条件としてできるだけ大きくなり、すなわち、その最小ソースブロックがこの区分方法によって生成された最小ソースブロックよりも大きくなるように、両方の制約を尊重する、ファイルまたはデータブロックをソースブロックに区分するための他の方法はない。したがって、この意味で、この区分方法によって生成されたＺの値は最適である。
【０２４０】
ソースブロックが区分されるサブブロックの数Ｎは、各サブブロックについて、サブブロックのサブシンボルのサイズ×サブブロックが区分するソースブロック中のソースシンボルの数が高々ＷＳであるという制約を条件としてできるだけ小さくなるように選定され得る。
【０２４１】
Ｚの値からこの区分方法によって生成されるよりも小さいＮの値が使用された場合、サイズがＷＳを超える少なくとも１つのサブブロックがあるであろうことに留意されたい。また、この区分方法がＺの所与の値から生成する最小サブシンボルサイズは、最大サブブロックサイズがＷＳを超えるべきでないという制約を条件としてできるだけ大きくなり、すなわち、最小サブシンボルサイズがこの区分方法によって生成される最小サブシンボルサイズよりも大きくなるように、最大サブブロック制約を尊重する、Ｚの値によって判断されたソースブロックのサブブロックを生成するための他の方法はない。したがって、この意味で、この区分方法によって生成されたＮの値は最適である。
【０２４２】
以下の例では、すべての可能なＫ′値がソースブロック中のソースシンボルの数としてサポートされると仮定される。
【０２４３】
例１
入力：
【数１５】
0005602858.tif 000016
【０２４４】
計算：
【数１６】
0005602858.tif 000017
【０２４５】
例２
入力：
【数１７】
0005602858.tif 000018
【０２４６】
計算：
【数１８】
0005602858.tif 000019
【０２４７】
上記の方法の多くの変形態がある。たとえば、あるＦＥＣ符号の場合、そのＦＥＣ符号のソースブロック受信オーバーヘッドを最小限に抑えるためにソースブロック中に少なくとも最小数のソースシンボルを有することが望ましい。実際に小さいファイルサイズまたはデータブロックサイズＦについて、ソースシンボルのサイズが非常に小さくなり得るので、また、パケットが区分される最大数のソースシンボルがあり得る。たとえば、ＩＥＴＦ  ＲＦＣ５０５３において、ソースブロック中のソースシンボルの所望の最小数はＫｍｉｎ＝１０２４であり、パケットが区分されるソースシンボルの最大数はＧｍａｘ＝１０である。
【０２４８】
以下は、今説明した追加のパラメータＫｍｉｎとＧｍａｘとを考慮に入れている、上記で説明した新しいサブブロック化方法の別の変形態であり、Ｇは、各パケット中で搬送されるソースブロックのためのシンボルの数であり、この変形態は、エンコーダ、デコーダ、送信機および／または受信機における、サブブロック化モジュール、あるいはより一般的にはあるモジュールまたはソフトウェアまたはハードウェアによって実行可能である。
【０２４９】
この変形態では、各パケットは、パケット中の第１のシンボルのＥＳＩを搬送し、次いで、パケット中の各後続のシンボルは、暗黙的に、パケット中の先行するシンボルよりも１大きいＥＳＩを有する。
【０２５０】
Ｇ、Ｔ、ＺおよびＮを判断するための新しいサブブロック化方法
【数１９】
0005602858.tif 000020
【０２５１】
Ｇが計算される方法によって、シンボルサイズが少なくともＳＳ＊Ａｌである、すなわち、シンボルサイズが少なくとも最小サブシンボルサイズであることが保証されることに留意されたい。また、シンボルサイズが少なくともＳＳ＊Ａｌとなり得るように、ＳＳ＊Ａｌが少なくともＰ′であるべきである（および、そうでない場合、Ｇは０になる）ことに留意されたい。
【０２５２】
例３
入力：
【数２０】
0005602858.tif 000021
【０２５３】
計算：
【数２１】
0005602858.tif 000022
【０２５４】
今説明したように、これらの新しい方法は、任意のサブブロックのために使用される最小サブシンボルサイズに対する制約を導入する。本開示は、最大サブブロックサイズに対する制約を同時に厳密に尊重しながら、この追加の制約を尊重するサブブロック化のための新しい方法を提供する。この方法は、ファイルまたは大きいデータブロックを、最小サブシンボルサイズに対する制約を条件として、できるだけ少数のソースブロックに区分し、さらに、これを条件として、最大サブブロックサイズに対する制約を条件として、できるだけ少数のサブブロックに分割するという目的を満たすソースブロック化およびサブブロック化ソリューションを生成する。
【０２５５】
変形態
いくつかの適用例では、ソースシンボルのすべてを復号することは可能でないこと、または比較的低い確率であるがソースシンボルのすべてを復号することが可能であることを許容できることがある。そのような適用例では、受信機は、Ｋ＋Ａ個の被符号化シンボルを受信した後に、ソースシンボルのすべてを復号することを試みるのを止めることができる。または、受信機は、Ｋ＋Ａ個よりも少ない被符号化シンボルを受信した後に、被符号化シンボルを受信することを止めることができる。いくつかの適用例では、受信機は、さらにはＫ個またはより少ない被符号化シンボルのみを受信し得る。したがって、本発明のいくつかの実施形態では、所望の正確度が、すべてのソースシンボルの完全な復元を必要とするわけではないことを理解されたい。
【０２５６】
さらに、不完全な復元が許容できるいくつかの適用例では、ソースシンボルのすべてが復元され得ないように、またはソースシンボルの完全な復元がソースシンボルの数よりもはるかに多い被符号化シンボルの受信を必要とするように、データが符号化され得る。そのような符号化は、一般的により少ない計算費用を必要とするであろうし、したがって、符号化の計算費用を減少させるための許容できる方法であり得る。
【０２５７】
上記で説明した図における様々な機能ブロックは、ハードウェアおよび／またはソフトウェアの組合せによって実装され得、特定の実装形態では、ブロックの一部の機能の一部または全部が組み合わせられ得ることを理解されたい。同様に、本明細書で教示する様々な方法はハードウェアおよび／またはソフトウェアの組合せによって実装され得ることも理解されたい。
【０２５８】
上記の説明は例示的であり、限定的ではない。本開示を検討すると、本発明の多くの変形態が当業者には明らかになるであろう。したがって、本発明の範囲は、上記の説明に関して判断されるべきでないが、代わりに、等価物のそれらの全範囲とともに添付の特許請求の範囲に関して判断されるべきである。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
[Ｃ１]
電子信号を出力することが可能な１つまたは複数の送信機を介してデータを電子的に送信する方法であって、送信されるべき前記データがソースシンボルの順序セットによって表され、前記データが、前記電子信号の少なくとも一部分を表す一連の被符号化シンボルとして送信され、前記方法は、
電子的に読取り可能な形態で、ソースシンボルの前記順序セットを取得することと、
ソースシンボルの前記順序セットから中間シンボルのセットを生成することであって、前記ソースシンボルが中間シンボルの前記セットから再生され得る、中間シンボルのセットを生成することと、
各中間シンボルが中間シンボルの前記セットのうちの１つのメンバーに指定され、少なくとも中間シンボルの第１のセットおよび中間シンボルの第２のセットがあるように、前記中間シンボルの前記セットを指定することであって、中間シンボルの各セットが、別個の符号化パラメータと関連付けられており、少なくとも１つの中間シンボルをメンバーとして有する、指定することと、
複数の被符号化シンボルを生成することであって、被符号化シンボルが前記中間シンボルのうちの１つまたは複数から生成され、少なくとも１つの被符号化シンボルが、直接または間接的に、中間シンボルの複数の前記セットから選択された複数の中間シンボルから生成される、複数の被符号化シンボルを生成することと
を備える方法。
[Ｃ２]
中間シンボルの前記第１のセットが、信念伝搬復号のためのシンボルに指定され、中間シンボルの前記第２のセットが、信念伝搬復号のための非活動化されるべきシンボルに指定される、Ｃ１に記載の方法。
[Ｃ３]
各被符号化シンボルが、中間シンボルの前記第１のセットのうちの１つまたは複数から生成された第１のシンボルと、中間シンボルの前記第２のセットのうちの１つまたは複数から生成された第２のシンボルとの組合せから生成される、Ｃ１に記載の方法。
[Ｃ４]
各被符号化シンボルが、第１の度数分布を有する中間シンボルの前記第１のセットのうちの１つまたは複数から生成された第１のシンボルと、前記第１の度数分布とは異なる第２の度数分布を有する中間シンボルの前記第２のセットのうちの１つまたは複数から生成された第２のシンボルとの組合せから生成されるように、前記別個の符号化パラメータが少なくとも別個の度数分布を備える、Ｃ３に記載の方法。
[Ｃ５]
前記第１のシンボルが、中間シンボルの前記第１のセットに適用される連鎖反応符号化プロセスを使用して生成される、Ｃ３に記載の方法。
[Ｃ６]
前記第２のシンボルが、中間シンボルの前記第２のセットからランダムに選定された固定数のシンボルのＸＯＲである、Ｃ３に記載の方法。
[Ｃ７]
前記第２のシンボルが、中間シンボルの前記第２のセットからランダムに選定された第１の数のシンボルのＸＯＲであり、前記第１の数が、前記第１のシンボルを生成するために前記第１のセットから選定された前記シンボルの数に等しい第２の数に依存する、Ｃ３に記載の方法。
[Ｃ８]
前記組合せが、前記第１のシンボルと前記第２のシンボルとの前記ＸＯＲである、Ｃ３に記載の方法。
[Ｃ９]
前記中間シンボルが、ソースシンボルの前記順序セットと、ソースシンボルの前記順序セットから生成された冗長ソースシンボルのセットとを備える、Ｃ１に記載の方法。
[Ｃ１０]
前記冗長シンボルの少なくともいくつかがＧＦ［２］演算を使用して生成され、他の冗長シンボルがＧＦ［２５６］演算を使用して生成される、Ｃ９に記載の方法。
[Ｃ１１]
前記中間シンボルが、符号化中に、復号プロセスを使用して前記ソースシンボルから生成され、前記復号プロセスが、前記中間シンボルと前記ソースシンボルとの間の関係の線形セットに基づく、Ｃ１に記載の方法。
[Ｃ１２]
前記線形関係の少なくともいくつかがＧＦ［２］に関する関係であり、他の線形関係がＧＦ［２５６］に関する関係である、Ｃ１１に記載の方法。
[Ｃ１３]
ソースシンボルの所与の順序セットから生成され得る別個の被符号化シンボルの数が、その順序セット中のソースシンボルの数とは無関係である、Ｃ１に記載の方法。
[Ｃ１４]
被符号化シンボルを生成するために実行されるシンボル演算の平均数が、その順序セット中のソースシンボルの数とは無関係である定数によって制限される、Ｃ１に記載の方法。
[Ｃ１５]
シンボルの前記第１のセットがシンボルの前記第２のセットよりも２桁以上大きい、Ｃ１に記載の方法。
[Ｃ１６]
ソースからデータを受信する方法であって、前記データがパケット通信チャネルを介して宛先において受信され、ソースシンボルの順序セットから導出された被符号化シンボルのセットによって表現可能な前記データが、前記ソースから前記宛先に送られた前記データを表し、前記方法は、
受信された被符号化シンボルの前記セットを取得することと、
受信された被符号化シンボルの前記セットから中間シンボルのセットを復号することと、
前記中間シンボルの各々を中間シンボルのセットに関連付けることであって、前記中間シンボルが少なくとも２つのセットに関連付けられ、１つのセットが、前記受信された被符号化シンボルから前記中間シンボルを復元するための復号プロセスをスケジュールするために永久的非活動シンボルのセットに指定される、関連付けることと、
前記復号プロセスに従って中間シンボルの前記セットから、ソースシンボルの前記順序セットの前記ソースシンボルの少なくともいくつかを復元することと
を備える方法。
[Ｃ１７]
前記復号プロセスは、少なくとも、永久的非活動シンボルの第２のセットと、シンボルの前記第１のセットのサブセットである動的非活動シンボルの第３のセットとに依存する、低減された被符号化シンボルのセットが生成される第１の復号段階と、低減された被符号化シンボルの前記セットが、永久的非活動シンボルの前記第２のセットと動的非活動シンボルの前記第３のセットとを復号するために使用される第２の復号段階と、永久的非活動シンボルの前記復号された第２のセット、動的非活動シンボルの前記第３のセット、および受信された被符号化シンボルの前記セットが、シンボルの前記第１のセット中にある残りの中間シンボルの少なくともいくつかを復号するために使用される第３の復号段階とを備える、Ｃ１６に記載の方法。
[Ｃ１８]
前記第１の復号段階が、非活動化復号と組み合わされた信念伝搬復号を使用し、および／または前記第２の復号段階がガウス消去法を使用する、Ｃ１７に記載の方法。
[Ｃ１９]
前記第３の復号段階が、後退代入、または後退掃引と後続の前進掃引を使用する、Ｃ１７に記載の方法。
[Ｃ２０]
動的非活動シンボルの第３のセット中のシンボルの数がソースシンボルの数の１０％よりも少なく、および／または永久的非活動化シンボルの前記第２のセット中のシンボルの数の１０％よりも少ないことを考慮して、前記復号プロセスが、動的非活動シンボルの前記第３のセットに対して演算する、Ｃ１７に記載の方法。
[Ｃ２１]
前記受信された被符号化シンボルが、ＬＤＰＣ符号生成シンボルまたはリードソロモン符号生成シンボルとして演算される、Ｃ１６に記載の方法。
[Ｃ２２]
受信された被符号化シンボルの前記セットの各受信された被符号化シンボルが、シンボルの前記第１のセットのうちの１つまたは複数から生成された第１のシンボルと、シンボルの前記第２のセットのうちの１つまたは複数から生成された第２のシンボルとの組合せであるものとして演算される、Ｃ１６に記載の方法。
[Ｃ２３]
各受信された被符号化シンボルが、前記第１のシンボルと前記第２のシンボルとのＸＯＲである前記組合せとして演算される、Ｃ２２に記載の方法。
[Ｃ２４]
各受信された被符号化シンボルが、前記第２のセットからランダムに選定された固定数のシンボルのＸＯＲである前記第２のシンボルとして演算される、Ｃ２２に記載の方法。
[Ｃ２５]
各受信された被符号化シンボルが、前記第２のセットからランダムに選定された第１の数のシンボルのＸＯＲである前記第２のシンボルとして演算され、シンボルの前記第１の数が、前記第１のシンボルを生成するために前記第１のセットから選定されたシンボルの前記第２の数に依存する、Ｃ２２に記載の方法。
[Ｃ２６]
前記復号プロセスは、前記第１のシンボルがシンボルの前記第１のセットから連鎖反応符号に基づいて選定されたかのように演算する、Ｃ２２に記載の方法。
[Ｃ２７]
前記復号プロセスは、永久的非活動シンボルの前記第２のセットのサイズがソースシンボルの数の平方根に比例するかのように演算する、Ｃ１６に記載の方法。
[Ｃ２８]
前記復号プロセスは、前記中間シンボルが、ソースシンボルの前記順序セットと、ソースシンボルの前記順序セットから生成された冗長シンボルのセットとを備えるかのように演算する、Ｃ１６に記載の方法。
[Ｃ２９]
前記復号プロセスは、前記冗長シンボルの少なくともいくつかがＧＦ［２］演算を使用して生成され、他の冗長シンボルがＧＦ［２５６］演算を使用して生成されたかのように演算する、Ｃ２８に記載の方法。
[Ｃ３０]
前記復号プロセスは、前記中間シンボルがソースシンボルの前記順序セットを備えるかのように演算する、Ｃ１６に記載の方法。
[Ｃ３１]
前記復号プロセスは、前記中間シンボルが、前記中間シンボルと前記ソースシンボルとの間の関係の線形セットに基づく復号プロセスを使用して前記ソースシンボルから生成されたシンボルであるかのように演算する、Ｃ１６に記載の方法。
[Ｃ３２]
前記復号プロセスは、前記線形関係の少なくともいくつかがＧＦ［２］に関する関係であり、他の線形関係がＧＦ［２５６］に関する関係であるかのように演算する、Ｃ３１に記載の方法。
[Ｃ３３]
前記復号プロセスは、受信され得る異なる可能な被符号化シンボルの数が、前記順序セット中のソースシンボルの数とは無関係であるかのように演算する、Ｃ１６に記載の方法。
[Ｃ３４]
受信された被符号化シンボルの前記セットからのソースシンボルの前記セットを復号するために実行されるシンボル演算の平均数が、ソースシンボルの数の定数倍によって制限され、前記定数がソースシンボルの数とは無関係である、Ｃ１６に記載の方法。
[Ｃ３５]
前記復号プロセスは、シンボルの前記第１のセット中のシンボルの数が、永久的非活動シンボルの前記第２のセット中のシンボルの数よりも２桁以上大きいかのように演算する、Ｃ１６に記載の方法。
[Ｃ３６]
あるＫ、ＮおよびＡについて、Ｎ＝Ｋ＋Ａ個の被符号化シンボルのセットからのＫ個のソースシンボルの前記セットのすべての復元は、Ａ＝０、１または２の場合、少なくとも下限の成功の確率１−（０．０１）＾（Ａ＋１）を有し、前記下限がソースシンボルの数とは無関係であるように、前記復号プロセスが演算する、Ｃ１６に記載の方法。
[Ｃ３７]
データネットワークに結合されたサーバを使用してファイルをサービスするための方法であって、サービスすることが、前記ファイルのデータを１つまたは複数のブロックに編成し、ブロックの前記データに基づいて前記ブロックのための１つまたは複数の被符号化シンボルを生成することを含み、少なくとも１つのブロックが物理的にまたは論理的に複数のサブブロックに編成され、少なくとも１つの被符号化シンボルが物理的にまたは論理的に複数のサブシンボルに編成され、前記方法は、
入力ファイルを整数個のブロックに区分することであって、各ブロックが少なくとも１つのサブブロックを含み、各サブブロックが少なくとも１つのソースシンボルを含む、区分することと、
メモリ制約に基づいてサブブロックの最大サイズを表す値ＷＳを判断することと、
値ＳＳを判断することであって、ＳＳ＊ＡＬが、好適なメモリユニットサイズＡＬの単位で、サブシンボルサイズの下限を表す、値ＳＳを判断することと、
前記整数個のブロックのうちのどのブロックが複数のサブブロックに編成されるべきかを判断することと、そのようなブロックごとに、ソースブロックのためのソースシンボルの数がしきい値内で等しく、前記数が前記ファイル中のソースシンボルの前記数Ｋｔに等しいことを保証し、各サブブロックの前記サブシンボルサイズが高々ＳＳ＊ＡＬであることを保証し、各サブブロックの前記サイズが高々ＷＳであることを保証する方法で、送られるべき被符号化シンボルのパケット内の利用可能な空間によって判断されたサイズ、各送られるパケット内で使用されるべきシンボルサイズを有する複数のサブブロックに前記ブロックを編成することと、
ブロックから被符号化シンボルを生成することであって、各被符号化シンボルが１つのブロックからのデータに依存するように、サブシンボルがサブブロックから生成される、生成することと、
前記生成された被符号化シンボルを出力することと
を備える方法。
[Ｃ３８]
データネットワークに結合されたクライアントを使用して受信機におけるデータのブロックを復元するための方法であって、ブロックが１つまたは複数のサブブロックのグルーピングを含み、前記方法は、
前記ブロックから生成された複数の被符号化シンボルを受信することであって、各被符号化シンボルが、演算の共通のセットを使用して少なくとも１つのサブブロックから生成された複数のサブシンボルを含む、受信することと、
メモリ制約に基づいてサブブロックの最大サイズを表す値ＷＳを判断することと、
値ＳＳを判断することであって、ＳＳ＊ＡＬが、好適なメモリユニットサイズＡＬの単位で、サブシンボルサイズの下限を表す、値ＳＳを判断することと、
整数個のブロックのうちのどのブロックが複数のサブブロックに編成されるべきかを判断することと、そのようなブロックごとに、パケット内の利用可能な空間を表す、送信側によって設定された第１のパラメータ、各パケット内で使用されるシンボルサイズを表す第２のパラメータによって判断されたサイズを有する複数のサブブロックに前記ブロックを編成することであって、前記パラメータは、ソースブロックのためのソースシンボルの数がしきい値内で等しく、前記数が前記ファイル中のソースシンボルの前記数Ｋｔに等しくなるようなものである、編成することと、
受信された被符号化シンボルからブロックを復号することであって、サブブロックがサブシンボルから復号され、前記サブブロックがブロックを形成し、各サブブロックの前記サブシンボルサイズが高々ＳＳ＊ＡＬであり、各サブブロックの前記サイズが高々ＷＳである、復号することと、
前記復号されたブロックを出力することと
を備える方法。
【０２５９】
付録Ａ
信頼できるマルチキャストトランスポート                              Ｍ．Ｌｕｂｙ
インターネットドラフト                Ｑｕａｌｃｏｍｍ  Ｉｎｃｏｒｐｏｒａｔｅｄ
対象ステータス：標準化過程                            Ａ．Ｓｈｏｋｒｏｌｌａｈｉ
有効期限：２０１１年２月１２日                                          ＥＰＦＬ
Ｍ．Ｗａｔｓｏｎ
Ｑｕａｌｃｏｍｍ  Ｉｎｃｏｒｐｏｒａｔｅｄ
Ｔ．Ｓｔｏｃｋｈａｍｍｅｒ
Ｎｏｍｏｒ  Ｒｅｓｅａｒｃｈ
Ｌ．Ｍｉｎｄｅｒ
Ｑｕａｌｃｏｍｍ  Ｉｎｃｏｒｐｏｒａｔｅｄ
２０１０年８月１１日
オブジェクト配信のためのＲａｐｔｏｒＱ前方誤り訂正方式
ｄｒａｆｔ−ｉｅｔｆ−ｒｍｔ−ｂｂ−ｆｅｃ−ｒａｐｔｏｒｑ−０４
要約
この文書では、ＲａｐｔｏｒＱ前方誤り訂正符号のための、ＦＥＣ符号化ＩＤ６（要確認（ｔｂｃ））に対応する完全指定ＦＥＣ方式と、データオブジェクトの信頼できる配信へのそれの適用例とについて説明する。
【０２６０】
ＲａｐｔｏｒＱ符号は、ＲＦＣ５０５３におけるＲａｐｔｏｒ符号よりも優れたフレキシビリティと、より大きいソースブロックサイズのサポートと、良好なコーディング効率とを提供する新しい符号ファミリーである。ＲａｐｔｏｒＱはまた、ファウンテン符号であり、すなわち、必要な数の符号化シンボルがデータのソースブロックのソースシンボルからエンコーダによってオンザフライで生成され得る。デコーダは、たいていの場合はソースシンボルの数に等しく、まれな場合はソースシンボルの数よりもわずかに多い符号化シンボルのセットからソースブロックを復元することが可能である。
【０２６１】
ここで説明するＲａｐｔｏｒＱ符号はシステマティック符号であり、これは、すべてのソースシンボルが、生成され得る符号化シンボルの中にあることを意味する。
【０２６２】
このメモのステータス
このインターネットドラフトは、ＢＣＰ７８およびＢＣＰ７９の規定に完全に準拠して提出されている。
【０２６３】
インターネットドラフトはＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）の作業文書である。他のグループが作業文書をインターネットドラフトとして配布することもあり得ることに留意されたい。現在のインターネットドラフトのリストは、http://datatracker.ietf.org/drafts/current/にある。
【０２６４】
インターネットドラフトは、最大６カ月有効な草案文書であり、いつでも他の文書によって更新されるか、置き換えられるか、または廃止され得る。インターネットドラフトを参考文献として使用すること、またはそれらを「作業中」以外のものとして引用することは不適当である。
【０２６５】
このインターネットドラフトは２０１１年２月１２日が有効期限である。
【０２６６】
著作権表示
Ｃｏｐｙｒｉｇｈｔ  （ｃ）２０１０  ＩＥＴＦ  Ｔｒｕｓｔおよび本文書の著者として特定される個人。著作権所有。
【０２６７】
この文書は、ＢＣＰ７８と、この文書の公開日に施行されているＩＥＴＦ文書に関するＩＥＴＦ  Ｔｒｕｓｔの法的規定（http://trustee.ietf.org/license-info）とに従うものである。この文書に関する権利および制限が記載されているので、それらの文書を注意深く精査されたい。この文書から抜粋されるコード構成要素は、Ｔｒｕｓｔの法的規定のセクション４．ｅに記載されている簡易ＢＳＤライセンステキストを含めなければならず、簡易ＢＳＤライセンスに記載されているように無保証で提供される。
【０２６８】
目次
１．    序論．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ５
２．    要件表記法．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ５
３．    フォーマットおよび符号．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ５
３．１．    ＦＥＣペイロードＩＤ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ５
３．２．    ＦＥＣオブジェクト送信情報．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ６
３．２．１．    必須．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ６
３．２．２．    共通．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ６
３．２．３．    方式固有．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ７
４．    プロシージャ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ８
４．１．    序論．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ８
４．２．    コンテンツ配信プロトコル要件．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．  ８
４．３．    例示的なパラメータ導出アルゴリズム．．．．．．．．．．．．．．．．．．．．．．．．．．  ８
４．４．    オブジェクト配信．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１０
４．４．１．    ソースブロック構成．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１０
４．４．２．    符号化パケット構成．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１２
５．    ＲａｐｔｏｒＱ  ＦＥＣ符号の仕様．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１３
５．１．    定義、記号および略語．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１３
５．１．１．    定義．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１３
５．１．２．    記号．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１４
５．１．３．    略語．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１６
５．２．    概観．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１７
５．３．    システマティックＲａｐｔｏｒＱエンコーダ．．．．．．．．．．．．．．．．．．．．１８
５．３．１．    序論．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１８
５．３．２．    符号化の概観．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．１９
５．３．３．    第１の符号化ステップ：中間シンボル生成．．．．．．．．．．．．．．．．２１
５．３．４．    第２の符号化ステップ：符号化．．．．．．．．．．．．．．．．．．．．．．．．．．２７
５．３．５．    生成器．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．２７
５．４．    例示的なＦＥＣデコーダ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３０
５．４．１．    概略．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３０
５．４．２．    拡張ソースブロックの復号．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３１
５．５．    乱数．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３６
５．５．１．    テーブルＶ０．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３６
５．５．２．    テーブルＶ１．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３７
５．５．３．    テーブルＶ２．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３８
５．５．４．    テーブルＶ３．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．３９
５．６．    システマティックインデックスおよび他のパラメータ．．．．．．．．．．．．４０
５．７．    オクテット、シンボルおよび行列を用いる演算．．．．．．．．．．．．．．．．．．６０
５．７．１．    概略．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６０
５．７．２．    オクテットに対する算術演算．．．．．．．．．．．．．．．．．．．．．．．．．．．．６１
５．７．３．    テーブルＯＣＴ＿ＥＸＰ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６２
５．７．４．    テーブルＯＣＴ＿ＬＯＧ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６３
５．７．５．    シンボルに対する演算．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６３
５．７．６．    行列に対する演算．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６４
５．８．    対応デコーダの要件．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６４
６．    セキュリティ考慮事項．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６５
７．    ＩＡＮＡ考慮事項．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６５
８．    謝辞．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６６
９．    参考文献．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６６
９．１．    必須参考文献．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６６
９．２．    非必須参考文献．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６６
著者の住所．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６６
１．    序論
この文書では、オブジェクト配信適用例に関するＲａｐｔｏｒＱ前方誤り訂正符号のためのＦＥＣ方式について詳述する。ＦＥＣ方式の概念はＲＦＣ５０５２［ＲＦＣ５０５２］において定義されており、この文書は、そこで規定されている形式に従い、その文書の用語を使用する。この文書で説明するＲａｐｔｏｒＱ符号は、ＲＦＣ５０５３［ＲＦＣ５０５３］に記載されているＲａｐｔｏｒ符号の次世代である。ＲａｐｔｏｒＱ符号は、ＲＦＣ５０５３［ＲＦＣ５０５３］のＲａｐｔｏｒ符号よりも優れた信頼性と、より良いコーディング効率と、より大きいソースブロックサイズのサポートとを提供する。これらの改善は、ＲＦＣ５０５３［ＲＦＣ５０５３］に比較して、オブジェクト配信コンテンツ配信プロトコルにおけるＲａｐｔｏｒＱ符号の使用を簡略化する。
【０２６９】
ＲａｐｔｏｒＱ  ＦＥＣ方式は、ＦＥＣ符号化ＩＤ６（ｔｂｃ）に対応する完全指定ＦＥＣ方式である。
【０２７０】
編集者注：確定されたＦＥＣ符号化ＩＤはまだ定義されていないが、ＩＡＮＡ登録プロセスにおけるＦＥＣ符号化ＩＤの連続的な使用を予想して、このインターネットドラフトでは、「６（ｔｂｃ）」を仮の値として使用する。
【０２７１】
ＲａｐｔｏｒＱは、ファウンテン符号であり、すなわち、必要な数の符号化シンボルがブロックのソースシンボルからエンコーダによってオンザフライで生成され得る。デコーダは、ソースシンボルの数よりもほんのわずかに多い数の符号化シンボルのセットからソースブロックを復元することが可能である。
【０２７２】
この文書で説明する符号はシステマティック符号であり、すなわち、元のソースシンボルならびにいくつかのリペアシンボルは送信側から受信機に変更なしに送られ得る。信頼できるマルチキャストにおける前方誤り訂正符号の使用に関する背景の詳細については、［ＲＦＣ３４５３］を参照されたい。
【０２７３】
２．    要件表記法
この文書中のキーワード「しなければならない（MUST）」、「してはならない（MUST NOT）」、「必要とされる（REQUIRED）」、「するものとする（SHALL）」、「しないものとする（SHALL NOT）」、「すべきである（SHOULD）」、「すべきでない（SHOULD NOT）」、「推奨される（RECOMMENDED）」、「してもよい（MAY）」、および「随意（OPTIONAL）」は、［ＲＦＣ２１１９］に記載されているように解釈するものとする。
【０２７４】
３．    フォーマットおよび符号
３．１．    ＦＥＣペイロードＩＤ
ＦＥＣペイロードＩＤは、次のように定義される４オクテットフィールドでなければならない。
【表１】
0005602858.tif 000023
【０２７５】
○  ソースブロック番号（ＳＢＮ）、（８ビット、符号なし整数）：パケット内の符号化シンボルが関係するソースブロックの非負整数識別子。
【０２７６】
○  符号化シンボルＩＤ（ＥＳＩ）、（２４ビット、符号なし整数）：パケット内の符号化シンボルの非負整数識別子。
【０２７７】
ソースブロック番号および符号化シンボル識別子の解釈はセクション４において定義されている。
【０２７８】
３．２．    ＦＥＣオブジェクト送信情報
３．２．１．    必須
ＦＥＣ符号化ＩＤの値は、ＩＡＮＡによって割り当てられるように、６でなければならない（セクション７参照）。
【０２７９】
３．２．２．    共通
このＦＥＣ方式によって使用される共通ＦＥＣオブジェクト送信情報要素は以下のとおりである。
【０２８０】
○  転送長さ（Ｆ）、（４０ビット、符号なし整数）：最高でも９４６２７０８７４８８０である非負整数。これは、オクテット単位のオブジェクトの転送長さである。
【０２８１】
○  シンボルサイズ（Ｔ）、（１６ビット、符号なし整数）：２＾＾１６よりも小さい正の整数。これは、オクテット単位のシンボルのサイズである。
【０２８２】
符号化された共通ＦＥＣオブジェクト送信情報フォーマットを図２に示す。
【表２】
0005602858.tif 000024
【０２８３】
注１：転送長さに関する９４６２７０８７４８８０の限界は、シンボルサイズが２＾＾１６−１に制限されること、ソースブロック中のシンボルの数が５６４０３に制限されること、およびソースブロックの数が２＾＾８に制限されることの結果である。
【０２８４】
３．２．３．    方式固有
以下パラメータが、このＦＥＣ方式のための方式固有ＦＥＣオブジェクト送信情報要素中で搬送される。
【０２８５】
○  ソースブロックの数（Ｚ）（１２ビット、符号なし整数）
○  サブブロックの数（Ｎ）（１２ビット、符号なし整数）
○  シンボルアラインメントパラメータ（Ａｌ）（８ビット、符号なし整数）
これらのパラメータはすべて正の整数である。符号化された方式固有オブジェクト送信情報は、図３に示すようにパラメータＺ、ＮおよびＡｌからなる４オクテットフィールドである。
【表３】
0005602858.tif 000025
【０２８６】
符号化されたＦＥＣオブジェクト送信情報は、符号化された共通ＦＥＣオブジェクト送信情報と符号化された方式固有ＦＥＣオブジェクト送信情報との連結からなる１２オクテットフィールドである。
【０２８７】
これらの３つのパラメータは、セクション４．４．１．２に記載されているようにソースブロック区分を定義する。
【０２８８】
４．    プロシージャ
４．１．    序論
このセクションにおいて使用される未定義の記号または関数、特に関数「ｃｅｉｌ」および「ｆｌｏｏｒ」については、セクション５．１を参照されたい。
【０２８９】
４．２．    コンテンツ配信プロトコル要件
このセクションでは、ＲａｐｔｏｒＱ  ＦＥＣ方式と、オブジェクト配信のためにＲａｐｔｏｒＱ  ＦＥＣ方式を利用する任意のコンテンツ配信プロトコル（ＣＤＰ）との間の情報交換について説明する。
【０２９０】
オブジェクト配信のためのＲａｐｔｏｒＱエンコーダ方式およびＲａｐｔｏｒＱデコーダ方式は、ＣＤＰからの以下の情報を必要とする。
【０２９１】
○  オクテット単位のオブジェクトの転送長さ、Ｆ
○  シンボルアラインメントパラメータ、Ａｌ
○  オクテット単位のシンボルサイズ、Ｔ。これは、Ａｌの倍数でなければならない。
【０２９２】
○  ソースブロックの数、Ｚ
○  各ソースブロック中のサブブロックの数、Ｎ
オブジェクト配信のためのＲａｐｔｏｒＱエンコーダ方式は、さらに以下を必要とする。
【０２９３】
−  符号化されるべきオブジェクト、Ｆオクテット
ＲａｐｔｏｒＱエンコーダ方式は、送られるべき各パケットについての以下の情報をＣＤＰに供給する。
【０２９４】
○  ソースブロック番号（ＳＢＮ）
○  符号化シンボルＩＤ（ＥＳＩ）
○  （１つまたは複数の）符号化シンボル
ＣＤＰは、この情報を受信機に通信しなければならない。
【０２９５】
４．３．    例示的なパラメータ導出アルゴリズム
このセクションでは、３つのトランスポートパラメータ、Ｔ、ＺおよびＮの導出についての推奨を行う。この推奨は以下の入力パラメータに基づく。
【０２９６】
○  Ｆ  オクテット単位のオブジェクトの転送長さ
○  ＷＳ  オクテット単位の、作業メモリにおいて復号可能である最大サイズブロック
○  Ｐ′  オクテット単位の最大ペイロードサイズ。これは、Ａｌの倍数であると仮定される。
【０２９７】
○  Ａｌ  オクテット単位のシンボルアラインメントパラメータ
○  ＳＳ  サブシンボルサイズに対する所望の下限がＳＳ＊Ａｌであるパラメータ
○  Ｋ′＿ｍａｘ  ソースブロック当たりのソースシンボルの最大数。
【０２９８】
注：セクション５．１．２において、Ｋ′＿ｍａｘは５６４０３であると定義されている。
【０２９９】
上記の入力に基づいて、トランスポートパラメータＴ、ＺおよびＮは次のように計算される。
【０３００】
次のように仮定する。
【０３０１】
○  Ｔ＝Ｐ′
○  Ｋｔ＝ｃｅｉｌ（Ｆ／Ｔ）
○  Ｎ＿ｍａｘ＝ｆｌｏｏｒ（Ｔ／（ＳＳ＊Ａｌ））
○  すべてのｎ＝１，．．．，Ｎ＿ｍａｘについて、
・ＫＬ（ｎ）は、次式を満たすような、セクション５．６の表２中の最大値Ｋ′である。
【０３０２】
Ｋ′≦ＷＳ／（Ａｌ＊（ｃｅｉｌ（Ｔ／（Ａｌ＊ｎ））））
○  Ｚ＝ｃｅｉｌ（Ｋｔ／ＫＬ（Ｎ＿ｍａｘ））
○  Ｎは、ｃｅｉｌ（Ｋｔ／Ｚ）≦ＫＬ（ｎ）を満たすような最小値ｎ＝１，．．．，Ｎ＿ｍａｘである。
【０３０３】
各パケットは厳密に１つのシンボルを含んでいることが推奨される。しかしながら、受信機は、複数のシンボルを含んでいるパケットの受信をサポートするものとする。
【０３０４】
値Ｋｔは、オブジェクトのソースデータを表すために必要とされるシンボルの総数である。
【０３０５】
セクション４．４．１．２において定義されている、上記のアルゴリズムは、サブシンボルサイズがシンボルアラインメントパラメータＡｌの倍数であることを保証する。これは、符号化および復号のために使用される和演算が、概して、一度に数オクテット、たとえば、３２ビットプロセッサ上で一度に少なくとも４オクテット実行されるので有用である。したがって、サブシンボルサイズがこのオクテット数の倍数である場合、符号化および復号はより高速に実行され得る。
【０３０６】
入力パラメータＡｌの推奨設定は４である。
【０３０７】
パラメータＷＳを使用して被符号化データを生成することができ、被符号化データは、デコーダにおいて限られた作業メモリを用いて効率的に復号され得る。ＷＳの所与の値に対する実際の最大デコーダメモリ要件は実装形態に依存するが、ＷＳよりもほんのわずかに大きい作業メモリを使用して復号を実装することが可能であることに留意されたい。
【０３０８】
４．４．    オブジェクト配信
４．４．１．    ソースブロック構成
４．４．１．１．    概略
ソースオブジェクトにＲａｐｔｏｒＱエンコーダを適用するために、オブジェクトは、ソースブロックとして知られるＺ≧１個のブロックに分解され得る。ＲａｐｔｏｒＱエンコーダは各ソースブロックに別個に適用される。各ソースブロックは一意のソースブロック番号（ＳＢＮ）によって識別され、第１のソースブロックはＳＢＮ  ０を有し、第２のソースブロックはＳＢＮ  １を有するなどである。各ソースブロックは、それぞれサイズＴオクテットのＫ個のソースシンボルに分割される。各ソースシンボルは一意の符号化シンボル識別子（ＥＳＩ）によって識別され、ソースブロックの第１のソースシンボルはＥＳＩ  ０を有し、第２のソースシンボルはＥＳＩ  １を有するなどである。
【０３０９】
Ｋ個のソースシンボルをもつ各ソースブロックは、作業メモリ中で復号されるのに十分小さいＮ≧１個のサブブロックに分割される。各サブブロックは、サイズＴ′のＫ個のサブシンボルに分割される。
【０３１０】
Ｋの値は、必ずしもオブジェクトの各ソースブロックについて同じではなく、Ｔ′の値は、必ずしもソースブロックの各サブブロックについて同じでない場合があることに留意されたい。しかしながら、シンボルサイズＴは、オブジェクトのすべてのソースブロックについて同じであり、シンボルの数Ｋは、ソースブロックのあらゆるサブブロックについて同じである。ソースブロックおよびサブブロックへのオブジェクトの厳密な区分は、以下のセクション４．４．１．２に記載されている。
【０３１１】
４．４．１．２．    ソースブロックおよびサブブロック区分
ソースブロックおよびサブブロックの構成は、５つの入力パラメータ、Ｆ、Ａｌ、Ｔ、ＺおよびＮと関数Ｐａｒｔｉｔｉｏｎ［］とに基づいて判断される。５つの入力パラメータは次のように定義される。
【０３１２】
○  Ｆ  オクテット単位のオブジェクトの転送長さ
○  Ａｌ  オクテット単位のシンボルアラインメントパラメータ
○  Ｔ  オクテット単位のシンボルサイズ。これは、Ａｌの倍数でなければならない。
【０３１３】
○  Ｚ  ソースブロックの数
○  Ｎ  各ソースブロック中のサブブロックの数
これらのパラメータは、ｃｅｉｌ（ｃｅｉｌ（Ｆ／Ｔ）／Ｚ）≦Ｋ′＿ｍａｘであるように設定されなければならない。これらのパラメータの導出についての推奨はセクション４．３に与えられている。
【０３１４】
関数Ｐａｒｔｉｔｉｏｎ［］は、入力として正の整数（Ｉ，Ｊ）のペアをとり、出力として４つの非負整数（ＩＬ，ＩＳ，ＪＬ，ＪＳ）を導出する。詳細には、Ｐａｒｔｉｔｉｏｎ［Ｉ，Ｊ］の値はシーケンス（ＩＬ，ＩＳ，ＪＬ，ＪＳ）であり、ＩＬ＝ｃｅｉｌ（Ｉ／Ｊ）、ＩＳ＝ｆｌｏｏｒ（Ｉ／Ｊ）、ＪＬ＝Ｉ−ＩＳ＊ＪおよびＪＳ＝Ｊ−ＪＬである。Ｐａｒｔｉｔｉｏｎ［］は、サイズＩのブロックをほぼ等しいサイズのＪ個のブロックに区分するためのパラメータを導出する。詳細には、長さＩＬのＪＬ個のブロックおよび長さＩＳのＪＳ個のブロックである。
【０３１５】
ソースオブジェクトは、次のようにソースブロックとサブブロックとに区分されなければならない。
【０３１６】
次のように仮定する。
【０３１７】
○  Ｋｔ＝ｃｅｉｌ（Ｆ／Ｔ）、
○  （ＫＬ，ＫＳ，ＺＬ，ＺＳ）＝Ｐａｒｔｉｔｉｏｎ［Ｋｔ，Ｚ］、
○  （ＴＬ，ＴＳ，ＮＬ，ＮＳ）＝Ｐａｒｔｉｔｉｏｎ［Ｔ／Ａｌ，Ｎ］。
【０３１８】
すると、オブジェクトは、それぞれＫＬ＊Ｔオクテット、すなわち、各々がＴオクテットのＫＬ個のソースシンボルを有する最初のＺＬ個のソースブロックと、各々がＫＳ＊Ｔオクテット、すなわち、それぞれＴオクテットのＫＳ個のソースシンボルを有する残りのＺＳ個のソースブロックとのＺ＝ＺＬ＋ＺＳ個の連続ソースブロックに区分されなければならない。
【０３１９】
Ｋｔ＊Ｔ＞Ｆである場合、符号化目的のために、最後のソースブロックの最後のシンボルはその末尾においてＫｔ＊Ｔ−Ｆ個の０オクテットを用いてパディングされなければならない。
【０３２０】
次に、Ｋ個のソースシンボルをもつ各ソースブロックは、各々がＴＬ＊ＡｌオクテットのサイズのＫ個の連続サブシンボルからなる最初のＮＬ個のサブブロックと、各々がＴＳ＊ＡｌオクテットのサイズのＫ個の連続サブシンボルからなる残りのＮＳ個のサブブロックとのＮ＝ＮＬ＋ＮＳ個の連続サブブロックに分割されなければならない。シンボルアラインメントパラメータＡｌは、サブシンボルが常にＡｌオクテットの倍数であることを保証する。
【０３２１】
最後に、ソースブロックのｍ番目のシンボルは、Ｎ個のサブブロックの各々からのｍ番目のサブシンボルの連結からなる。これは、Ｎ＞１であるとき、シンボルはオブジェクトの連続部分でないことを暗示することに留意されたい。
【０３２２】
４．４．２．    符号化パケット構成
各符号化パケットは以下の情報を含んでいる。
【０３２３】
○  ソースブロック番号（ＳＢＮ）
○  符号化シンボルＩＤ（ＥＳＩ）
○  （１つまたは複数の）符号化シンボル
各ソースブロックは他のソースブロックとは無関係に符号化される。ソースブロックは０から連続的に番号付けされる。
【０３２４】
０からＫ−１までの符号化シンボルＩＤ値は、連続順序でソースブロックのソースシンボルを識別し、Ｋは、ソースブロック中のソースシンボルの数である。Ｋ以降の符号化シンボルＩＤは、ＲａｐｔｏｒＱエンコーダを使用してソースシンボルから生成されるリペアシンボルを識別する。
【０３２５】
各符号化パケットは、完全にソースシンボル（ソースパケット）からなるか、または完全にリペアシンボル（リペアパケット）からなる。パケットは、同じソースブロックからの任意の数のシンボルを含み得る。ソースパケット中の最後のソースシンボルがＦＥＣ符号化目的で追加されたパディングオクテットを含む場合、これらのオクテットはパケット中に含まれる必要はない。そうではなく、全シンボルのみが含まれなければならない。
【０３２６】
各ソースパケット中で搬送される符号化シンボルＩＤ  Ｘは、そのパケット中で搬送される第１のソースシンボルの符号化シンボルＩＤである。パケット中の後続のソースシンボルは、連続順序で符号化シンボルＩＤ  Ｘ＋１〜Ｘ＋Ｇ−１を有し、Ｇは、パケット中のシンボルの数である。
【０３２７】
同様に、リペアパケットに配置される符号化シンボルＩＤ  Ｘは、リペアパケット中の第１のリペアシンボルの符号化シンボルＩＤであり、パケット中の後続のリペアシンボルは、連続順序で符号化シンボルＩＤ  Ｘ＋１〜Ｘ＋Ｇ−１を有し、Ｇは、パケット中のシンボルの数である。
【０３２８】
受信機がリペアパケットの総数を知る必要はないことに留意されたい。
【０３２９】
５．    ＲａｐｔｏｒＱ  ＦＥＣ符号の仕様
５．１．    定義、記号および略語
このセクションでは、ＲａｐｔｏｒＱ  ＦＥＣ符号の仕様のために、以下の定義、記号および略語を適用する。
【０３３０】
５．１．１．    定義
○  ソースブロック：ＲａｐｔｏｒＱ符号化および復号目的のために一緒に考慮されるＫ個のソースシンボルのブロック。
【０３３１】
○  拡張ソースブロック：ソースブロックと０個以上のパディングシンボルとから構成される、Ｋ′≧ＫであるＫ′個のソースシンボルのブロック。
【０３３２】
○  シンボル：データ単位。オクテット単位のシンボルのサイズはシンボルサイズとして知られている。シンボルサイズは常に正の整数である。
【０３３３】
○  ソースシンボル：符号化プロセス中に使用される最小データ単位。ソースブロック内のすべてのソースシンボルは同じサイズを有する。
【０３３４】
○  パディングシンボル：拡張ソースブロックを形成するためにソースブロックに追加される全０ビットをもつシンボル。
【０３３５】
○  符号化シンボル：ソースブロックの符号化の一部として送られ得るシンボル。ソースブロックの符号化シンボルは、ソースブロックのソースシンボルと、ソースブロックから生成されるリペアシンボルとからなる。ソースブロックから生成されるリペアシンボルは、そのソースブロックのソースシンボルと同じサイズを有する。
【０３３６】
○  リペアシンボル：ソースシンボルではない、ソースブロックの符号化シンボル。リペアシンボルは、ソースブロックのソースシンボルに基づいて生成される。
【０３３７】
○  中間シンボル：逆符号化プロセスを使用してソースシンボルから生成されるシンボル。次いで、中間シンボルからリペアシンボルが直接生成される。符号化シンボルは中間シンボルを含まず、すなわち、中間シンボルはソースブロックの符号化の一部として送られない。中間シンボルは、ＬＴシンボルとＰＩシンボルとに区分される。
【０３３８】
○  ＬＴシンボル：符号化シンボルのＬＴネイバーであり得る中間シンボルのサブセット。
【０３３９】
○  ＰＩシンボル：符号化シンボルのＰＩネイバーであり得る中間シンボルのサブセット。
【０３４０】
○  システマティック符号：すべてのソースシンボルがソースブロックの符号化シンボルの一部として含まれる符号。この文書で説明するＲａｐｔｏｒＱ符号はシステマティック符号である。
【０３４１】
○  符号化シンボルＩＤ（ＥＳＩ）：送信および受信目的のためにソースブロックに関連する各符号化シンボルを一意に識別する情報。
【０３４２】
○  内部シンボルＩＤ（ＩＳＩ）：符号化および復号目的のために拡張ソースブロックに関連する各シンボルを一意に識別する情報。
【０３４３】
○  オクテットとシンボルと行列とに対する算術演算：ソースシンボルから符号化シンボルを生成するために、およびその逆を生成するために使用される演算。セクション５．７参照。
【０３４４】
５．１．２．    記号
ｉ、ｊ、ｕ、ｖ、ｈ、ｄ、ａ、ｂ、ｄ１、ａ１、ｂ１、ｖ、ｍ、ｘ、ｙは、コンテキストに応じて、あるタイプまたは別のタイプの値または変数を表す。
【０３４５】
Ｘは、コンテキストに応じて、ＩＳＩ値またはＥＳＩ値のいずれかである非負整数値を示す。
【０３４６】
ｃｅｉｌ（ｘ）は、ｘ以上である最小整数を示し、ｘは実数値である。
【０３４７】
ｆｌｏｏｒ（ｘ）は、ｘ以下である最大整数を示し、ｘは実数値である。
【０３４８】
ｍｉｎ（ｘ，ｙ）は、値ｘおよびｙの最小値を示し、概して、すべての引数値の最小値を示す。
【０３４９】
ｍａｘ（ｘ，ｙ）は、値ｘおよびｙの最大値を示し、概して、すべての引数値の最大値を示す。
【０３５０】
ｉ％ｊは、ｊを法とするｉを示す。
【０３５１】
ｉ＋ｊは、ｉとｊとの和を示す。ｉおよびｊがオクテットであり、それぞれシンボルである場合、これは、セクション５．７において定義されているように、それぞれシンボルであるオクテットに対する算術を指定する。ｉおよびｊが整数である場合、ｉ＋ｊは通常の整数加算を示す。
【０３５２】
ｉ＊ｊは、ｉとｊとの積を示す。ｉおよびｊがオクテットである場合、これは、セクション５．７において定義されているように、オクテットに対する算術を指定する。ｉがオクテットであり、ｊがシンボルである場合、これは、同じくセクション５．７において定義されているように、シンボルにオクテットを掛ける乗算を示す。最後に、ｉおよびｊが整数である場合、ｉ＊ｊは整数の通常の積を示す。
【０３５３】
ａ＾＾ｂは、ａのｂ乗の演算を示す。ａがオクテットであり、ｂが非負整数である場合、これはａ＊ａ＊．．．＊ａ（ｂ項）を意味すると理解され、「＊」は、セクション５．７において定義されているようにオクテット積である。
【０３５４】
ｕ＾ｖは、等長ビットストリングｕおよびｖについて、ｕとｖとのビット単位の排他論理和を示す。
【０３５５】
Ｔｒａｎｓｐｏｓｅ［Ａ］は、行列Ａの転置行列を示す。この仕様では、すべての行列は、オクテットであるエントリを有する。
【０３５６】
Ａ＾＾−１は、行列Ａの逆行列を示す。この仕様では、すべての行列はオクテットをエントリとして有し、したがって、行列エントリの演算は、セクション５．７に示すように行われるものであることと、Ａ＾＾−１は、オクテット算術に関してＡの逆行列であることとを理解されたい。
【０３５７】
Ｋは、単一のソースブロック中のシンボルの数を示す。
【０３５８】
Ｋ′は、拡張ソースブロック中のソースシンボル＋パディングシンボルの数を示す。この仕様の大部分では、パディングシンボルは追加のソースシンボルであると見なされる。
【０３５９】
Ｋ′＿ｍａｘは、単一のソースブロック中にあり得るソースシンボルの最大数を示す。５６４０３に設定される。
【０３６０】
Ｌは、単一の拡張ソースブロックの中間シンボルの数を示す。
【０３６１】
Ｓは、単一の拡張ソースブロックのＬＤＰＣシンボルの数を示す。これらはＬＴシンボルである。セクション５．６の表２に示すＫ′の各値について、Ｓの対応する値は素数である。
【０３６２】
Ｈは、単一の拡張ソースブロックのＨＤＰＣシンボルの数を示す。これらはＰＩシンボルである。
【０３６３】
Ｂは、ＬＤＰＣシンボルを除いてＬＴシンボルである中間シンボルの数を示す。
【０３６４】
Ｗは、ＬＴシンボルである中間シンボルの数を示す。セクション５．６に示す表２中のＫ′の各値について、Ｗの対応する値は素数である。
【０３６５】
Ｐは、ＰＩシンボルである中間シンボルの数を示す。これらは、すべてのＨＤＰＣシンボルを含んでいる。
【０３６６】
Ｐ１は、Ｐ以上の最小素数を示す。
【０３６７】
Ｕは、ＰＩシンボルである非ＨＤＰＣ中間シンボルの数を示す。
【０３６８】
Ｃは、中間シンボルＣ［０］，Ｃ［１］，Ｃ［２］，．．．，Ｃ［Ｌ−１］のアレイを示す。
【０３６９】
Ｃ′は、拡張ソースブロックのシンボルのアレイを示し、Ｃ′［０］，Ｃ′［１］，Ｃ′［２］，．．．，Ｃ′［Ｋ−１］はソースブロックのソースシンボルであり、Ｃ′［Ｋ］，Ｃ′［Ｋ＋１］，．．．，Ｃ′［Ｋ′−１］はパディングシンボルである。
【０３７０】
Ｖ０、Ｖ１、Ｖ２、Ｖ３は、セクション５．５に示すように、Ｖ０［０］，Ｖ０［１］，．．．，Ｖ０［２５５］、Ｖ１［０］，Ｖ１［１］，．．．，Ｖ１［２５５］、Ｖ２［０］，Ｖ２［１］，．．．，Ｖ２［２５５］、およびＶ３［０］，Ｖ３［１］，．．．，Ｖ３［２５５］の３２ビット符号なし整数の４つのアレイを示す。
【０３７１】
Ｒａｎｄ［ｙ，ｉ，ｍ］は、擬似乱数発生器を示す。
【０３７２】
Ｄｅｇ［ｖ］は、度数生成器を示す。
【０３７３】
Ｅｎｃ［Ｋ′，Ｃ，（ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）］は、符号化シンボル生成器を示す。
【０３７４】
Ｔｕｐｌｅ［Ｋ′，Ｘ］は、タプル生成器関数を示す。
【０３７５】
Ｔは、オクテット単位のシンボルサイズを示す。
【０３７６】
Ｊ（Ｋ′）は、Ｋ′に関連するシステマティックインデックスを示す。
【０３７７】
Ｇは、任意の生成器行列を示す。
【０３７８】
Ｉ＿Ｓは、Ｓ×Ｓ単位行列を示す。
【０３７９】
５．１．３．    略語
ＥＳＩ              符号化シンボルＩＤ
ＨＤＰＣ            高密度パリティ検査
ＩＳＩ              内部シンボルＩＤ
ＬＤＰＣ            低密度パリティ検査
ＬＴ                Ｌｕｂｙ変換
ＰＩ                永久的非活動
ＳＢＮ              ソースブロック番号
ＳＢＬ              ソースブロック長さ（シンボル単位）
５．２．    概観
このセクションはシステマティックＲａｐｔｏｒＱ  ＦＥＣ符号を定義する。
【０３８０】
シンボルは符号化および復号プロセスの基本データ単位である。各ソースブロックについて、すべてのシンボルは、シンボルサイズＴと呼ばれる同じサイズである。符号化と復号の両方のためにシンボルに対して実行されるアトミック演算は、セクション５．７において定義されている算術演算である。
【０３８１】
基本エンコーダはセクション５．３に記載されている。エンコーダは、最初に、ソースブロックのソースシンボルから中間シンボルのブロックを導出する。この中間ブロックは、ソースシンボルとリペアシンボルの両方が同じプロセスを使用して中間ブロックから生成され得るという特性を有する。エンコーダは、効率的なプロセスを使用して中間ブロックからリペアシンボルを生成し、そのような各リペアシンボルはブロックからの少数の中間シンボルの排他的論理和である。ソースシンボルはまた、同じプロセスを使用して中間ブロックから再生され得る。符号化シンボルはソースシンボルとリペアシンボルとの組合せである。
【０３８２】
デコーダの例はセクション５．４に記載されている。中間ブロックからソースシンボルとリペアシンボルとを生成するためのプロセスは、符号化シンボルのセット中のソースシンボルとリペアシンボルとの混合とは無関係に、中間ブロックが符号化シンボルの十分に大きいセットから復元され得るように設計される。中間ブロックが復元されると、ソースブロックの消失したソースシンボルが符号化プロセスを使用して復元され得る。
【０３８３】
ＲａｐｔｏｒＱ対応デコーダの要件はセクション５．８に与えられている。これらの要件を達成するために、いくつかの復号アルゴリズムが可能である。これらの要件を達成するための効率的な復号アルゴリズムはセクション５．４に与えられている。
【０３８４】
中間シンボルおよびリペアシンボルの構成は、セクション５．３に記載されている擬似乱数発生器に部分的に基づく。この発生器は、送信側と受信機の両方に利用可能でなければならない１０２４個の乱数の固定セットに基づく。これらの数はセクション５．５に与えられている。ＲａｐｔｏｒＱの符号化および復号演算はオクテットに対する演算を使用する。セクション５．７において、これらの演算をどのように実行するかについて説明する。
【０３８５】
最後に、ソースシンボルからの中間シンボルの構成は「システマティックインデックス」によって支配され、その値は、６〜Ｋ′＿ｍａｘ＝５６４０３個のソースシンボルの特定の拡張ソースブロックサイズについてセクション５．６に与えられている。したがって、ＲａｐｔｏｒＱ符号は、１〜５６４０３個のソースシンボルをもつソースブロックをサポートする。
【０３８６】
５．３．    システマティックＲａｐｔｏｒＱエンコーダ
５．３．１．    序論
Ｋ個のソースシンボルの所与のソースブロックについて、符号化および復号目的のために、ソースブロックは、Ｋ′−Ｋ個の追加のパディングシンボルを用いて増補され、Ｋ′は、セクション５．６の表２のシステマティックインデックス中の少なくともＫである最小値である。ソースブロックをＫ′の倍数までパッドアウトする理由は、より高速な符号化および復号を可能にすること、ならびにエンコーダおよびデコーダに記憶される必要があるテーブル情報の量を最小限に抑えることである。
【０３８７】
データを送信および受信する目的で、Ｋの値は、ソースブロック中のソースシンボルの数を判断するために使用され、したがって、Ｋは送信側および受信機において知られている必要がある。この場合、送信側および受信機は、ＫからＫ′を計算し得、Ｋ′−Ｋ個のパディングシンボルは、追加の通信なしに自動的にソースブロックに追加され得る。符号化シンボルＩＤ（ＥＳＩ）は、送信側および受信機がソースブロックの符号化シンボルを識別するために使用され、ソースブロックの符号化シンボルは、ソースシンボルと、ソースブロックに関連するリペアシンボルとからなる。Ｋ個のソースシンボルをもつソースブロックでは、ソースシンボルのＥＳＩは、０，１，２，．．．，Ｋ−１であり、リペアシンボルのＥＳＩは、Ｋ，Ｋ＋１，Ｋ＋２，．．．である。トランスポートの際に符号化シンボルを識別するためのＥＳＩを使用することは、ＥＳＩ値がソースシンボルとリペアシンボルとの間で連続的に続くことを保証する。
【０３８８】
データを符号化および復号する目的で、Ｋから導出されるＫ′の値は、符号化演算および復号演算が実行される拡張ソースブロックのソースシンボルの数として使用され、Ｋ′個のソースシンボルは、元のＫ個のソースシンボルと追加のＫ′−Ｋ個のパディングシンボルとからなる。内部シンボルＩＤ（ＩＳＩ）は、エンコーダおよびデコーダが拡張ソースブロックに関連するシンボルを識別するため、すなわち、符号化シンボルを生成および復号するために使用される。Ｋ個の元のソースシンボルをもつソースブロックでは、元のソースシンボルのＩＳＩは、０，１，２，．．．，Ｋ−１であり、Ｋ′−Ｋ個のパディングシンボルのＩＳＩは、Ｋ，Ｋ＋１，Ｋ＋２，．．．，Ｋ′−１であり、リペアシンボルのＩＳＩは、Ｋ′，Ｋ′＋１，Ｋ′＋２，．．．である。符号化および復号のためにＩＳＩを使用することは、拡張ソースブロックのパディングシンボルが拡張ソースブロックの他のソースシンボルと同様に扱われることを可能にし、リペアシンボルの所与のプレフィックスが、Ｋとは無関係に、拡張ソースブロック中のソースシンボルの所与の数Ｋ′と一貫しているように生成されることを可能にする。
【０３８９】
ＥＳＩとＩＳＩとの間の関係は単純である。元のＫ個のソースシンボルのＥＳＩとＩＳＩは同じであり、Ｋ′−Ｋ個のパディングシンボルはＩＳＩを有するが、（パディングシンボルは送られることも受信されることもないシンボルであるので）対応するＥＳＩを有せず、リペアシンボルＩＳＩは、単にリペアシンボルＥＳＩ＋Ｋ′−Ｋである。送られ、受信される符号化シンボルを識別するために使用されるＥＳＩ間の変換、ならびに符号化および復号のために使用される対応するＩＳＩ、ならびに符号化および復号のために使用されるパディングシンボルを用いた拡張ソースブロックの適切なパディングは、ＲａｐｔｏｒＱエンコーダ／デコーダ中のパディング機能の責任である。
【０３９０】
５．３．２．    符号化の概観
システマティックＲａｐｔｏｒＱエンコーダを使用して、拡張ソースブロックＣ′に配置されたＫ個のソースシンボルからなるソースブロックから任意の数のリペアシンボルを生成する。図４に符号化の概観を示す。
【０３９１】
符号化の第１のステップは、シンボルの総数Ｋ′が、セクション５．６に記載されている値のうちの１つになるように、０個以上のパディングシンボルを追加することによって拡張ソースブロックを構成することである。各パディングシンボルは、各オクテットの値が０であるＴ個のオクテットからなる。Ｋ′は、Ｋ以上である、セクション５．６のテーブルからのＫ′の最小値として選択されなければならない。
【表４】
0005602858.tif 000026
【０３９２】
Ｃ′［０］，．．．，Ｃ′［Ｋ−１］は、Ｋ個のソースシンボルを示すとする。
【０３９３】
Ｃ′［Ｋ］，．．．，Ｃ′［Ｋ′−１］は、すべて０ビットに設定されるＫ′−Ｋ個のパディングシンボルを示すとする。すると、Ｃ′［０］，．．．，Ｃ′［Ｋ′−１］は、符号化および復号が実行される拡張ソースブロックのシンボルである。
【０３９４】
この説明では、以降、これらのパディングシンボルを追加のソースシンボルと見なし、そのように呼ぶ。しかしながら、これらのパディングシンボルは符号化シンボルの一部ではなく、すなわち、それらは符号化の一部として送られない。受信機において、Ｋ′の値はＫに基づいて計算され得、次いで、受信機は、Ｋ個のソースシンボルのソースブロックの末尾にＫ′−Ｋ個のパディングシンボルを挿入し、受信された符号化シンボルからソースブロックの残りのＫ個のソースシンボルを復元することができる。
【０３９５】
符号化の第２のステップは、Ｋ′個のソースシンボルからＬ＞Ｋ′個の中間シンボルを生成することである。このステップでは、セクション５．３．５．４に記載されているＴｕｐｌｅ［］生成器を使用して、Ｋ′個のソースタプル（ｄ［０］，ａ［０］，ｂ［０］，ｄ１［０］，ａ１［０］，ｂ１［０］），．．．，（ｄ［Ｋ′−１］，ａ［Ｋ′−１］，ｂ［Ｋ′−１］，ｄ１［Ｋ′−１］，ａ１［Ｋ′−１］，ｂ１［Ｋ′−１］）が生成される。Ｋ′個のソースタプルとＫ′個のソースシンボルに関連するＩＳＩとを使用して、逆符号化プロセスを使用してソースシンボルからＬ個の中間シンボルＣ［０］，．．．，Ｃ［Ｌ−１］が判断される。このプロセスはＲａｐｔｏｒＱ復号プロセスによって実現され得る。
【０３９６】
いくつかの「プリコーディング関係」がＬ個の中間シンボル内で成り立たなければならない。セクション５．３．３．３において、これらの関係について説明する。セクション５．３．３．４において、ソースシンボルから中間シンボルがどのように生成されるかについて説明する。
【０３９７】
中間シンボルが生成されると、リペアシンボルが生成され得る。ＩＳＩ  Ｘ＞Ｋ′をもつリペアシンボルについて、セクション５．３．５．４に記載されているＴｕｐｌｅ［］生成器を使用して、非負整数のタプル（ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）が生成され得る。次いで、（ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）タプルとＩＳＩ  Ｘとを使用して、セクション５．３．５．３に記載されているＥｎｃ［］生成器を使用して中間シンボルから対応するリペアシンボルが生成される。したがって、このリペアシンボルの対応するＥＳＩはＸ−（Ｋ′−Ｋ）である。拡張ソースブロックのソースシンボルも同じプロセスを使用して生成され得、すなわち、任意のＸ＜Ｋ′について、このプロセスを使用して生成されるシンボルはＣ′［Ｘ］と同じ値を有することに留意されたい。
【０３９８】
５．３．３．    第１の符号化ステップ：中間シンボル生成
５．３．３．１．    概略
この符号化ステップは、ソースシンボルＣ′［０］，．．．，Ｃ′［Ｋ′−１］からＬ個の中間シンボルＣ［０］，．．．，Ｃ［Ｌ−１］を生成するためのプリコーディングステップであり、Ｌ＞Ｋ′は、セクション５．３．３．３において定義されている。中間シンボルは、以下の制約の２つのセットによって一意に定義される。
【０３９９】
１．    中間シンボルは、ソースシンボルタプルのセットによって、およびソースシンボルのＩＳＩによってソースシンボルに関係付けられる。セクション５．３．５．４に記載されているＴｕｐｌｅ［］生成器を使用するソースシンボルタプルの生成は、セクション５．３．３．２において定義されている。
【０４００】
２．    いくつかのプリコーディング関係が中間シンボル自体の内で成り立つ。これらはセクション５．３．３．３において定義されている。
【０４０１】
さらに、Ｌ個の中間シンボルの生成はセクション５．３．３．４において定義されている。
【０４０２】
５．３．３．２．    ソースシンボルタプル
Ｋ′個のソースシンボルの各々は、０≦Ｘ＜Ｋ′の場合、ソースシンボルタプル（ｄ［Ｘ］，ａ［Ｘ］，ｂ［Ｘ］，ｄ１［Ｘ］，ａ１［Ｘ］，ｂ１［Ｘ］）に関連付けられる。ソースシンボルタプルは、セクション５．３．５．４において定義されているタプル生成器を使用して、次のように判断される。
【０４０３】
０≦Ｘ＜Ｋ′である各Ｘについて、
（ｄ［Ｘ］，ａ［Ｘ］，ｂ［Ｘ］，ｄ１［Ｘ］，ａ１［Ｘ］，ｂ１［Ｘ］）＝Ｔｕｐｌｅ［Ｋ，Ｘ］
５．３．３．３．    プリコーディング関係
Ｌ個の中間シンボルの間のプリコーディング関係は、中間シンボルのＳ＋Ｈ個の線形結合のセットが０になる必要があることによって定義される。Ｓ個のＬＤＰＣシンボルおよびＨ個のＨＤＰＣシンボルがあり、したがって、Ｌ＝Ｋ′＋Ｓ＋Ｈである。Ｌ個の中間シンボルの別の区分は、Ｗ個のＬＴシンボルの１つのセットとＰ個のＰＩシンボルの別のセットとの２つのセットであり、したがって、同じくＬ＝Ｗ＋Ｐである。Ｐ個のＰＩシンボルは、符号化プロセスにおいてＷ個のＬＴシンボルとは別様に扱われる。Ｐ個のＰＩシンボルは、Ｈ個のＨＤＰＣシンボルと、Ｕ＝Ｐ−Ｈ個の他のＫ′個の中間シンボルのセットとからなる。Ｗ個のＬＴシンボルは、Ｓ個のＬＤＰＣシンボルと、Ｗ−Ｓ個の他のＫ′個の中間シンボルとからなる。これらのパラメータの値は、以下で説明するようにＫ′から判断され、Ｈ（Ｋ′）、Ｓ（Ｋ′）、およびＷ（Ｋ′）は、セクション５．６の表２から導出される。
【０４０４】
次のように仮定する。
【０４０５】
○  Ｓ＝Ｓ（Ｋ′）
○  Ｈ＝Ｈ（Ｋ′）
○  Ｗ＝Ｗ（Ｋ′）
○  Ｌ＝Ｋ′＋Ｓ＋Ｈ
○  Ｐ＝Ｌ−Ｗ
○  Ｐ１は、Ｐ以上の最小素数を示す。
【０４０６】
○  Ｕ＝Ｐ−Ｈ
○  Ｂ＝Ｗ−Ｓ
○  Ｃ［０］，．．．，Ｃ［Ｂ−１］は、ＬＴシンボルであるがＬＤＰＣシンボルではない中間シンボルを示す。
【０４０７】
○  Ｃ［Ｂ］，．．．，Ｃ［Ｂ＋Ｓ−１］は、ＬＴシンボルでもあるＳ個のＬＤＰＣシンボルを示す。
【０４０８】
○  Ｃ［Ｗ］，．．．，Ｃ［Ｗ＋Ｕ−１］は、ＰＩシンボルであるがＨＤＰＣシンボルではない中間シンボルを示す。
【０４０９】
○  Ｃ［Ｌ−Ｈ］，．．．，Ｃ［Ｌ−１］は、ＰＩシンボルでもあるＨ個のＨＤＰＣシンボルを示す。
【０４１０】
ＬＤＰＣ関係と呼ばれる、プリコーディング関係の第１のセットについて以下で説明し、これは、このプロセスの終了時にシンボルＤ［０］，．．．，Ｄ［Ｓ−１］のセットがすべて０であることを必要とする。
【０４１１】
○  シンボルＤ［０］＝Ｃ［Ｂ］，．．．，Ｄ［Ｓ−１］＝Ｃ［Ｂ＋Ｓ−１］を初期化する。
【０４１２】
○  ｉ＝０，．．．，Ｂ−１に対して、以下を実行する。
【０４１３】
・  ａ＝１＋ｆｌｏｏｒ（ｉ／Ｓ）
・  ｂ＝ｉ％Ｓ
・  Ｄ［ｂ］＝Ｄ［ｂ］＋Ｃ［ｉ］
・  ｂ＝（ｂ＋ａ）％Ｓ
・  Ｄ［ｂ］＝Ｄ［ｂ］＋Ｃ［ｉ］
・  ｂ＝（ｂ＋ａ）％Ｓ
・  Ｄ［ｂ］＝Ｄ［ｂ］＋Ｃ［ｉ］
○  ｉ＝０，．．．，Ｓ−１に対して、以下を実行する
・  ａ＝ｉ％Ｐ
・  ｂ＝（ｉ＋１）％Ｐ
・  Ｄ［ｉ］＝Ｄ［ｉ］＋Ｃ［Ｗ＋ａ］＋Ｃ［Ｗ＋ｂ］
シンボルの加算は、セクション５．７において指定されているように行われるものであることを想起されたい。
【０４１４】
上記のアルゴリズムにおいて定義されているＬＤＰＣ関係は線形であり、したがって、次式を満たすようなＳ×Ｂ行列Ｇ＿ＬＤＰＣ，１およびＳ×Ｐ行列Ｇ＿ＬＤＰＣ，２が存在することに留意されたい。
【０４１５】
Ｇ＿ＬＤＰＣ，１＊Ｔｒａｎｓｐｏｓｅ［（Ｃ［０］，．．．．，Ｃ［Ｂ−１］）］＋Ｇ＿ＬＤＰＣ，２＊Ｔｒａｎｓｐｏｓｅ（Ｃ［Ｗ］，．．．，Ｃ［Ｗ＋Ｐ−１］）＋Ｔｒａｎｓｐｏｓｅ［（Ｃ［Ｂ］，．．．，Ｃ［Ｂ＋Ｓ−１］）］＝０
（行列Ｇ＿ＬＤＰＣ，１は、上記のアルゴリズム中の第１のループによって定義されており、Ｇ＿ＬＤＰＣ，２は、第２のループから推論され得る。）
中間シンボルＣ［０］，．．．，Ｃ［Ｌ−１］の間の関係の第２のセットはＨＤＰＣ関係であり、それらは次のように定義される。
【０４１６】
次のように仮定する。
【０４１７】
○  αは、セクション５．７において定義されているように、整数２によって表されるオクテットを示す。
【０４１８】
○  ＭＴは、オクテットのＨ×（Ｋ′＋Ｓ）行列を示し、ｊ＝０，．．．，Ｋ′＋Ｓ−２の場合、ｉ＝Ｒａｎｄ［ｊ＋１，６，Ｈ］またはｉ＝（Ｒａｎｄ［ｊ＋１，６，Ｈ］＋Ｒａｎｄ［ｊ＋１，７，Ｈ−１］＋１）％Ｈであれば、エントリＭＴ［ｉ，ｊ］は整数１によって表されるオクテットであり、ｉのすべての他の値について、ＭＴ［ｉ，ｊ］は０要素であり、ｊ＝Ｋ′＋Ｓ−１の場合、ｉ＝０，．．．，Ｈ−１について、ＭＴ［ｉ，ｊ］＝α＾＾ｉである。
【０４１９】
○  ＧＡＭＭＡは、オクテットの（Ｋ′＋Ｓ）×（Ｋ′＋Ｓ）行列を示し、
ＧＡＭＭＡ［ｉ，ｊ］＝
ｉ≧ｊの場合は、α＾＾（ｉ−ｊ）であり、
他の場合は、０である。
【０４２０】
すると、第１のＫ′＋Ｓ個の中間シンボルＣ［０］，．．．，Ｃ［Ｋ′＋Ｓ−１］とＨ個のＨＤＰＣシンボルＣ［Ｋ′＋Ｓ］，．．．，Ｃ［Ｋ′＋Ｓ＋Ｈ−１］と間の関係は次式によって与えられる。
【０４２１】
Ｔｒａｎｓｐｏｓｅ［Ｃ［Ｋ′＋Ｓ］，．．．，Ｃ［Ｋ′＋Ｓ＋Ｈ−１］］＋ＭＴ＊ＧＡＭＭＡ＊Ｔｒａｎｓｐｏｓｅ［Ｃ［０］，．．．，Ｃ［Ｋ′＋Ｓ−１］］＝０
上式で、「＊」は、オクテットの行列とシンボルの行列（特にシンボルの列ベクトル）との乗算を定義するためにオクテット乗算を利用する標準行列乗算を表し、「＋」は、オクテットベクトルに対する加算を示す。
【０４２２】
５．３．３．４．    中間シンボル
５．３．３．４．１．    定義
Ｋ′個のソースシンボルＣ′［０］，Ｃ′［１］，．．．，Ｃ′［Ｋ′−１］を仮定すれば、Ｌ個の中間シンボルＣ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］は、以下の条件を満たす一意に定義されたシンボル値である。
【０４２３】
１．    Ｋ′個のソースシンボルＣ′［０］，Ｃ′［１］，．．．，Ｃ′［Ｋ′−１］はＫ′個の制約を満たす。
【０４２４】
０≦Ｘ＜Ｋ′であるすべてのＸについて、Ｃ′［Ｘ］＝Ｅｎｃ［Ｋ′，（Ｃ［０］，．．．，Ｃ［Ｌ−１］），（ｄ［Ｘ］，ａ［Ｘ］，ｂ［Ｘ］，ｄ１［Ｘ］，ａ１［Ｘ］，ｂ１［Ｘ］）］
上式で、（ｄ［Ｘ］，ａ［Ｘ］，ｂ［Ｘ］，ｄ１［Ｘ］，ａ１［Ｘ］，ｂ１［Ｘ］））＝Ｔｕｐｌｅ［Ｋ′，Ｘ］であり、Ｔｕｐｌｅ［］はセクション５．３．５．４において定義されており、Ｅｎｃ［］はセクション５．３．５．３に記載されている。
【０４２５】
２．    Ｌ個の中間シンボルＣ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］は、セクション５．３．３．３において定義されているプリコーディング関係を満たす。
【０４２６】
５．３．３．４．２．    中間シンボルの計算のための例示的な方法
このセクションでは、セクション５．３．３．４．１の制約を満たすＬ個の中間シンボルＣ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］の計算のための可能な方法について説明する。
【０４２７】
Ｌ個の中間シンボルは次のように計算され得る。
【０４２８】
次のように仮定する。
【０４２９】
○  Ｃは、Ｌ個の中間シンボルＣ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］の列ベクトルを示す。
【０４３０】
○  Ｄは、Ｓ＋Ｈ個の０シンボルと、それに続くＫ′個のソースシンボルＣ′［０］，Ｃ′［１］，．．．，Ｃ′［Ｋ′−１］とからなる列ベクトルを示す。
【０４３１】
すると、上記の制約は、次式を満たすようなオクテットのＬ×Ｌ行列Ａを定義する。
【０４３２】
Ａ＊Ｃ＝Ｄ
行列Ａは次のように構成され得る。
【０４３３】
次のように仮定する。
【０４３４】
○  Ｇ＿ＬＤＰＣ，１およびＧ＿ＬＤＰＣ，２は、セクション５．３．３．３において定義されているＳ×Ｂ行列およびＳ×Ｐ行列である。
【０４３５】
○  Ｇ＿ＨＤＰＣは、次式を満たすようなＨ×（Ｋ′＋Ｓ）行列である。
【０４３６】
Ｇ＿ＨＤＰＣ＊Ｔｒａｎｓｐｏｓｅ（Ｃ［０］，．．．，Ｃ［Ｋ′＋Ｓ−１］）＝Ｔｒａｎｓｐｏｓｅ（Ｃ［Ｋ′＋Ｓ］，．．．，Ｃ［Ｌ−１］）
すなわち、Ｇ＿ＨＤＰＣ＝ＭＴ＊ＧＡＭＭＡ
○  Ｉ＿Ｓは、Ｓ×Ｓ単位行列である。
【０４３７】
○  Ｉ＿Ｈは、Ｈ×Ｈ単位行列である。
【０４３８】
○  Ｇ＿ＥＮＣは、次式を満たすようなＫ′×Ｌ行列である。
【０４３９】
Ｇ＿ＥＮＣ＊Ｔｒａｎｓｐｏｓｅ［（Ｃ［０］，．．．，Ｃ［Ｌ−１］）］＝Ｔｒａｎｓｐｏｓｅ［（Ｃ′［０］，Ｃ′［１］，．．．，Ｃ′［Ｋ′−１］）］
すなわち、Ｃ［ｊ］が、Ｅｎｃ［Ｋ′，（Ｃ［０］，．．．，Ｃ［Ｌ−１］），（ｄ［ｉ］，ａ［ｉ］，ｂ［ｉ］，ｄ１［ｉ］，ａ１［ｉ］，ｂ１［ｉ］）］を生成するために合計されるシンボル中に含まれる場合のみ、Ｇ＿ＥＮＣ［ｉ，ｊ］＝１であり、他の場合は、Ｇ＿ＥＮＣ［ｉ，ｊ］＝０である。
【０４４０】
すると、次のようになる。
【０４４１】
○  Ａの最初のＳ行は、Ｇ＿ＬＤＰＣ，１｜Ｉ＿Ｓ｜Ｇ＿ＬＤＰＣ，２に等しい。
【０４４２】
○  Ａの次のＨ行は、Ｇ＿ＨＤＰＣ｜Ｉ＿Ｈに等しい。
【０４４３】
○  Ａの残りのＫ′行は、Ｇ＿ＥＮＣに等しい。
【０４４４】
行列Ａを以下の図（図５）に示す。
【表５】
0005602858.tif 000027
【０４４５】
次いで、中間シンボルは次のように計算され得る。
【０４４６】
Ｃ＝（Ａ＾＾−１）＊Ｄ
任意のＫ′について、行列Ａが最大階数を有し、したがって可逆であるようなソースタプルが生成される。この計算は、Ｌ個の中間シンボルＣ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］を生成するために、Ｋ′個のソースシンボルＣ′［０］，Ｃ′［１］，．．．，Ｃ′［Ｋ′−１］にＲａｐｔｏｒＱ復号プロセスを適用することによって実現され得る。
【０４４７】
ソースシンボルから中間シンボルを効率的に生成するために、セクション５．４で説明するデコーダ実装形態など、効率的なデコーダ実装形態を使用することが推奨される。
【０４４８】
５．３．４．    第２の符号化ステップ：符号化
第２の符号化ステップでは、タプル（ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）＝Ｔｕｐｌｅ［Ｋ′，Ｘ］を使用して、Ｌ個の中間シンボルＣ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］に、セクション５．３．５．３において定義されている生成器Ｅｎｃ［Ｋ′，（Ｃ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］），（ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）］を適用することによって、ＩＳＩ  Ｘ（Ｘ≧Ｋ′）をもつリペアシンボルが生成される。
【０４４９】
５．３．５．    生成器
５．３．５．１．    乱数発生器
乱数発生器Ｒａｎｄ［ｙ，ｉ，ｍ］は次のように定義され、ｙは非負整数であり、ｉは２５６よりも小さい非負整数であり、ｍは正の整数であり、生成される値は０とｍ−１との間の整数である。Ｖ０、Ｖ１、Ｖ２およびＶ３をセクション５．５に与えられているアレイとする。
【０４５０】
次のように仮定する。
【０４５１】
○  ｘ０＝（ｙ＋ｉ）ｍｏｄ２＾＾８
○  ｘ１＝（ｆｌｏｏｒ（ｙ／２＾＾８）＋ｉ）ｍｏｄ２＾＾８
○  ｘ２＝（ｆｌｏｏｒ（ｙ／２＾＾１６）＋ｉ）ｍｏｄ２＾＾８
○  ｘ３＝（ｆｌｏｏｒ（ｙ／２＾＾２４）＋ｉ）ｍｏｄ２＾＾８
すると、次のようになる。
【０４５２】
Ｒａｎｄ［ｙ，ｉ，ｍ］＝（Ｖ０［ｘ０］＾Ｖ１［ｘ１］＾Ｖ２［ｘ２］＾Ｖ３［ｘ３］）％ｍ
５．３．５．２．    度数生成器
度数生成器Ｄｅｇ［ｖ］は次のように定義され、ｖは、２＾＾２０＝１０４８５７６よりも小さい非負整数である。ｖを仮定すれば、ｆ［ｄ−１］≦ｖ＜ｆ［ｄ］であるような表１中のインデックスｄを見つけ、Ｄｅｇ［ｖ］＝ｍｉｎ（ｄ，Ｗ−２）を設定する。Ｗは、セクション５．３．３．３に記載されているように、Ｋ′から導出されることを想起されたい。
【表６】
0005602858.tif 000028
【０４５３】
５．３．５．３．    符号化シンボル生成器
符号化シンボル生成器Ｅｎｃ［Ｋ′，（Ｃ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］），（ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）］は以下の入力をとる。
【０４５４】
○  Ｋ′は、拡張ソースブロックのソースシンボルの数である。Ｌ、Ｗ、Ｂ、Ｓ、ＰおよびＰ１は、セクション５．３．３．３に記載されているように、Ｋ′から導出されるものとする。
【０４５５】
○  （Ｃ［０］，Ｃ［１］，．．．，Ｃ［Ｌ−１］）は、セクション５．３．３．４に記載されているように生成されたＬ個の中間シンボル（サブシンボル）のアレイである。
【０４５６】
○  （ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）は、セクション５．３．５．４において定義されているタプル生成器を使用してＩＳＩ  Ｘから判断されたソースタプルであり、ただし、
・  ｄは、符号化シンボルＬＴ度数を示す正の整数である。
【０４５７】
・  ａは、両端の値を含む１とＷ−１との間の正の整数である。
【０４５８】
・  ｂは、両端の値を含む０とＷ−１との間の非負整数である。
【０４５９】
・  ｄ１は、符号化シンボルＰＩ度数を示す、値２または３のいずれかを有する正の整数である。
【０４６０】
・  ａ１は、両端の値を含む１とＰ１−１との間の正の整数である。
【０４６１】
・  ｂ１は、両端の値を含む０とＰ１−１との間の非負整数である。
【０４６２】
符号化シンボル生成器は、以下のアルゴリズムに従って、単一の符号化シンボルを（ｒｅｓｕｌｔ（結果）と呼ばれる）出力として生成する。
【０４６３】
○  ｒｅｓｕｌｔ＝Ｃ［ｂ］
○  ｊ＝１，．．．，ｄ−１に対して、以下を実行する。
【０４６４】
・  ｂ＝（ｂ＋ａ）％Ｗ
・  ｒｅｓｕｌｔ＝ｒｅｓｕｌｔ＋Ｃ［ｂ］
○  （ｂ１≧Ｐ）である間、ｂ１＝（ｂ１＋ａ１）％Ｐ１を実行する。
【０４６５】
○  ｒｅｓｕｌｔ＝ｒｅｓｕｌｔ＋Ｃ［Ｗ＋ｂ１］
○  ｊ＝１，．．．，ｄ１−１に対して、以下を実行する。
【０４６６】
・  ｂ１＝（ｂ１＋ａ１）％Ｐ１
・  （ｂ１≧Ｐ）である間、ｂ１＝（ｂ１＋ａ１）％Ｐ１を実行する。
【０４６７】
・  ｒｅｓｕｌｔ＝ｒｅｓｕｌｔ＋Ｃ［Ｗ＋ｂ１］
○  ｒｅｓｕｌｔを戻す。
【０４６８】
５．３．５．４．    タプル生成器
タプル生成器Ｔｕｐｌｅ［Ｋ′，Ｘ］は以下の入力をとる。
【０４６９】
○  Ｋ′  −  拡張ソースブロック中のソースシンボルの数
○  Ｘ  −  ＩＳＩ
次のように仮定する。
【０４７０】
○  Ｌは、セクション５．３．３．３に記載されているように、Ｋ′から判断される。
【０４７１】
○  Ｊ＝Ｊ（Ｋ′）は、セクション５．６の表２において定義されているように、Ｋ′に関連するシステマティックインデックスである。
【０４７２】
タプル生成器の出力は、タプル（ｄ，ａ，ｂ，ｄ１，ａ１，ｂ１）であり、次のように判断される。
【０４７３】
○  Ａ＝５３５９１＋Ｊ＊９９７
○  （Ａ％２＝＝０）である場合、｛Ａ＝Ａ＋１｝
○  Ｂ＝１０２６７＊（Ｊ＋１）
○  ｙ＝（Ｂ＋Ｘ＊Ａ）％２＾＾３２
○  ｖ＝Ｒａｎｄ［ｙ，０，２＾＾２０］
○  ｄ＝Ｄｅｇ［ｖ］
○  ａ＝１＋Ｒａｎｄ［ｙ，１，Ｗ−１］
○  ｂ＝Ｒａｎｄ［ｙ，２，Ｗ］
○  （ｄ＜４）である場合、｛ｄ１＝２＋Ｒａｎｄ［Ｘ，３，２］｝、そうでない場合、｛ｄ１＝２｝
○  ａ１＝１＋Ｒａｎｄ［Ｘ，４，Ｐ１−１］
○  ｂ１＝Ｒａｎｄ［Ｘ，５，Ｐ１］
５．４．    例示的なＦＥＣデコーダ
５．４．１．    概略
このセクションでは、この仕様において導入されるＲａｐｔｏｒＱ符号のための効率的な復号アルゴリズムについて説明する。各受信された符号化シンボルは中間シンボルの既知の線形結合であることに留意されたい。
【０４７４】
したがって、各受信された符号化シンボルは中間シンボルの間の一次方程式を与え、これは、中間シンボルの間の既知の線形プリコーディング関係とともに連立一次方程式を与える。したがって、連立一次方程式を解くためのアルゴリズムは、中間シンボルを正常に復号することができ、したがってソースシンボルを正常に復号することができる。しかしながら、選定されるアルゴリズムは復号の計算効率に対して大きな影響を有する。
【０４７５】
５．４．２．    拡張ソースブロックの復号
５．４．２．１．    概略
デコーダは、シンボルサイズＴと、ソースブロック中のシンボルの数Ｋと、拡張ソースブロック中のソースシンボルの数Ｋ′とを含む、復号すべきソースブロックの構造を知っていると仮定する。
【０４７６】
セクション５．３で説明したアルゴリズムから、ＲａｐｔｏｒＱデコーダは、中間シンボルの総数Ｌ＝Ｋ′＋Ｓ＋Ｈを計算し、復号されるべき拡張ソースブロックから中間シンボルがどのように生成されたかを判断することができる。この説明では、復号されるべき拡張ソースブロックの受信された符号化シンボルがデコーダに渡されると仮定する。さらに、そのような符号化シンボルごとに、その和が符号化シンボルに等しい中間シンボルの数およびセットがデコーダに渡されると仮定する。パディングシンボルを含むソースシンボルの場合、セクション５．３．３．２で説明したソースシンボルタプルは、その和が各ソースシンボルを与える中間シンボルの数およびセットを示す。
【０４７７】
Ｎ≧Ｋ′を、拡張ソースブロックのパディングシンボルを含む、復号のために使用されるべき受信された符号化シンボルの数とし、Ｍ＝Ｓ＋Ｈ＋Ｎとする。すると、セクション５．３．３．４．２の表記法によれば、Ａ＊Ｃ＝Ｄが得られる。
【０４７８】
拡張ソースブロックを復号することは、既知のＡおよびＤからＣを復号することと等価である。Ｃは、Ａの階数がＬである場合のみ復号され得ることは明らかである。Ｃが復号されると、ソースシンボルタプルを使用して、各消失したソースシンボルを取得するために合計されなければならない中間シンボルの数およびセットを判断することによって、消失したソースシンボルが取得され得る。
【０４７９】
Ｃの復号における第１のステップは、復号スケジュールを形成することである。このステップでは、Ａは、（行演算と行および列の並べ替えとを使用する）ガウス消去法を使用して、Ｍ−Ｌ行を廃棄した後に、Ｌ×Ｌ単位行列に変換される。復号スケジュールは、ガウス消去法プロセス中の行演算と行および列の並べ替えとのシーケンスからなり、Ａのみに依存し、Ｄには依存しない。
【０４８０】
ＤからのＣの復号は復号スケジュールの形成と同時に行うことができるか、または復号は復号スケジュールに基づいて後で行うことができる。
【０４８１】
復号スケジュールとＣの復号との間の対応は以下のとおりである。初めに、ｃ［０］＝０，ｃ［１］＝１，．．．，ｃ［Ｌ−１］＝Ｌ−１およびｄ［０］＝０，ｄ［１］＝１，．．．，ｄ［Ｍ−１］＝Ｍ−１とする。
【０４８２】
○  復号スケジュールにおいてＡの行ｉの倍数βが行ｉ′に加算されるたびに、復号プロセスにおいてシンボルβ＊Ｄ［ｄ［ｉ］］がシンボルＤ［ｄ［ｉ′］］に加算される。
【０４８３】
○  Ａの行ｉにオクテットβが乗算されるたびに、復号プロセスにおいてシンボルＤ［ｄ［ｉ］］にもβが乗算される。
【０４８４】
○  復号スケジュールにおいて行ｉが行ｉ′と交換されるたびに、復号プロセスにおいてｄ［ｉ］の値がｄ［ｉ′］の値と交換される。
【０４８５】
○  復号スケジュールにおいて列ｊが列ｊ′と交換されるたびに、復号プロセスにおいてｃ［ｊ］の値がｃ［ｊ′］の値と交換される。
【０４８６】
この対応から、拡張ソースブロックの復号におけるシンボルに対する演算の総数がガウス消去法における（交換でない）行演算の数であることは明らかである。Ａは、ガウス消去法後の、および最後のＭ−Ｌ行を廃棄した後のＬ×Ｌ単位行列であるので、正常な復号の終了時に、Ｌ個のシンボルＤ［ｄ［０］］，Ｄ［ｄ［１］］，．．．，Ｄ［ｄ［Ｌ−１］］がＬ個のシンボルＣ［ｃ［０］］，Ｃ［ｃ［１］］，．．．，Ｃ［ｃ［Ｌ−１］］の値であることは明らかである。
【０４８７】
復号スケジュールを形成するためにガウス消去法が実行される順序は、復号が成功するか否かとは関係しない。しかしながら、復号の速度はガウス消去法が実行される順序に大きく依存する。（さらに、ここでは説明しないが、Ａの疎表現を維持することが重要である）。このセクションでは、以降、ガウス消去法が実行され得る比較的効率的な順序について説明する。
【０４８８】
５．４．２．２．    第１の段階
ガウス消去法の第１の段階では、行列Ａは概念的に部分行列に区分され、さらに行列Ｘが作成される。この行列は、Ａと同数の行および列を有し、第１の段階の間中、下三角行列になる。この段階の開始時に、行列Ａは行列Ｘにコピーされる。
【０４８９】
部分行列サイズは、それぞれ０およびＰＩシンボルの数Ｐに初期化される非負整数ｉおよびｕによってパラメータ化される。Ａの部分行列は以下のとおりである。
【０４９０】
１．    最初のｉ行と最初のｉ列との交差によって定義される部分行列Ｉ。これは、この段階における各ステップの終了時の単位行列である。
【０４９１】
２．    最初のｉ行と、最初のｉ列および最後のｕ列以外のすべての列との交差によって定義される部分行列。この部分行列のすべてのエントリは０である。
【０４９２】
３．    最初のｉ列と、最初のｉ行以外のすべての列との交差によって定義される部分行列。この部分行列のすべてのエントリは０である。
【０４９３】
４．    すべての行と最後のｕ列との交差によって定義される部分行列Ｕ。
【０４９４】
５．    最初のｉ列および最後のｕ列以外のすべての列と、最初のｉ行以外のすべての行との交差によって形成される部分行列Ｖ。
【０４９５】
図６にＡの部分行列を示す。第１の段階の開始時に、Ｖ＝Ａである。各ステップにおいて、Ａの行が選定される。
【表７】
0005602858.tif 000029
【０４９６】
Ａのどの行が選定されるかを判断する際に、Ｖの構造によって定義される以下のグラフが使用される。Ｖと交差する列はグラフ中のノードであり、Ｖにおいて厳密に２つの非ゼロエントリを有し、ＨＤＰＣ行でない行は、その２つの１の位置で２つの列（ノード）を接続するグラフのエッジである。このグラフ中の構成要素は、グラフ中のノード／エッジの各ペア間にパスがあるような、ノード（列）およびエッジ（行）の最大セットである。構成要素のサイズは構成要素中のノード（列）の数である。
【０４９７】
第１の段階では、最高でもＬ個のステップがある。ｉ＋ｕ＝Ｌであるとき、すなわち、ＶおよびＶの上の全０部分行列が消滅したときにこの段階は正常に終了し、Ａは、Ｉと、Ｉの下の全０部分行列と、Ｕとからなる。Ｖが消滅する前のあるステップにおいて、そのステップにおいて選定すべきＶ中の非ゼロ行がない場合、この段階は復号失敗で不成功に終わる。各ステップにおいて、Ａの行は次のように選定される。
【０４９８】
○  Ｖのすべてのエントリが０である場合、行は選定されず、復号は失敗する。
【０４９９】
○  ｒを、Ａの少なくとも１つの行がＶにおいて厳密にｒ個の１を有するような最小整数とする。
【０５００】
・  ｒ！＝２である場合、すべての非ＨＤＰＣ行が処理されるまでＨＤＰＣ行を選定すべきでないことを除いて、すべてのそのような行の中で元の最小度数をもつ、Ｖにおいて厳密にｒ個の１をもつ行を選定する。
【０５０１】
・  ｒ＝２である場合、Ｖによって定義される、上記で説明したグラフ中の最大サイズ構成要素の一部である、Ｖにおいて厳密に２つの１をもつ任意の行を選定する。
【０５０２】
このステップにおいて行が選定された後、選定された行がＶと交差する最初の行であるように、Ｖと交差するＡの最初の行は選定された行と交換される。Ｖと交差するＡの列は、選定された行におけるｒ個の１のうちの１つがＶの最初の列に現れるように、および残りのｒ−１個の１がＶの最後の列に現れるように並べ替えられる。同じ行および列演算が行列Ｘに対しても実行される。次いで、選定された行の適切な倍数が、Ｖの最初の列に非ゼロエントリを有する、選定された行の下のＡのすべての他の行に加算される。詳細には、選定された行の下の行がＶの最初の列にエントリβを有し、選定された行がＶの最初の列にエントリαを有する場合、Ｖの最初の列に０値を残すために、選定された行を乗算したβ／αがこの行に加算される。最後に、ｉは１だけ増分され、ｕはｒ−１だけ増分され、ステップは完了する。
【０５０３】
影響を受けた行自体が復号プロセス中に選定されるまで、上記で特定した行演算が実際に実行されなければ、効率が改善され得ることに留意されたい。これは、復号プロセスにおいて最終的に使用されない行に対する行演算の処理を回避し、特に、実際に必要とされるまで、β！＝１である行を回避する。さらに、ＨＤＰＣ行に必要な行演算は、セクション５．３．３．３で説明したアルゴリズムを使用することによって、１つのプロセスにおいてすべてのそのような行に対して実行され得る。
【０５０４】
５．４．２．３．    第２の段階
この時点で、Ｘが下三角形状を有するように、最初のｉ行およびｉ列の外側のＸのすべてのエントリが廃棄される。次にＸがｉ行ｉ列を有するように、Ｘの最後のｉ行およびｉ列が廃棄される。部分行列Ｕは、最初のｉ行Ｕ＿ｕｐｐｅｒ、および残りのＭ−ｉ行Ｕ＿ｌｏｗｅｒにさらに区分される。第２の段階においてＵ＿ｌｏｗｅｒに対してガウス消去法を実行して、Ｕ＿ｌｏｗｅｒの階数がｕよりも小さいことを判断する（復号失敗）か、またはＵ＿ｌｏｗｅｒを最初のｕ行が単位行列である行列に変換する（第２の段階の成功）。このｕ×ｕ単位行列をＩ＿ｕと呼ぶ。Ｕ＿ｌｏｗｅｒ−Ｉ＿ｕと交差するＡのＭ−Ｌ行が廃棄される。この段階の後、ＡはＬ行およびＬ列を有する。
【０５０５】
５．４．２．４．    第３の段階
第２の段階の後、Ｌ×Ｌ単位行列へのＡの変換を完了するために０で埋める必要があるＡの唯一の部分はＵ＿ｕｐｐｅｒである。部分行列Ｕ＿ｕｐｐｅｒの行ｉの数は、概して、Ｕ＿ｕｐｐｅｒの列ｕの数よりもはるかに大きい。その上、この時点で、行列Ｕ＿ｕｐｐｅｒは一般に密であり、すなわち、この行列の非ゼロエントリの数は大きい。この行列を疎形式に簡約するために、行列Ｕ＿ｌｏｗｅｒを取得するために実行される演算のシーケンスを反転させる必要がある。この目的で、行列Ｘに、Ａの最初のｉ行からなるＡの部分行列が乗算される。この演算の後、最初のｉ行とｉ列との交差からなるＡの部分行列はＸに等しいが、行列Ｕ＿ｕｐｐｅｒは疎形式に変換される。
【０５０６】
５．４．２．５．    第４の段階
Ｕ＿ｕｐｐｅｒの最初のｉ行の各々に対して次の演算を行う。行が位置ｊにおいて非ゼロエントリを有する場合、およびその非ゼロエントリの値がｂである場合、この行にＩ＿ｕの行ｊをｂ回加算する。このステップの後、最初のｉ行とｉ列との交差からなるＡの部分行列はＸに等しく、部分行列Ｕ＿ｕｐｐｅｒは０からなり、最後のｕ行と最初のｉ列との交差からなる部分行列は０からなり、最後のｕ行およびｕ列からなる部分行列は行列Ｉ＿ｕである。
【０５０７】
５．４．２．６．    第５の段階
１からｉまでのｊに対して以下の演算を実行する。
【０５０８】
１．    Ａ［ｊ，ｊ］が１でない場合、Ａの行ｊをＡ［ｊ，ｊ］で除算する。
【０５０９】
２．    １からｊ−１までのｌに対して、Ａ［ｊ，ｌ］が０でない場合、Ａの行ｌを乗算したＡ［ｊ，ｌ］をＡの行ｊに加算する。
【０５１０】
この段階の後、ＡはＬ×Ｌ単位行列であり、完全な復号スケジュールが正常に形成されている。次いで、復号スケジュールに基づいて、中間シンボルを復元するために、既知の符号化シンボルを合計することからなる対応する復号が実行され得る。すべてのソースシンボルに関連するタプルが、セクション５．３．３．２に従って計算される。受信されたソースシンボルのタプルは復号において使用される。消失したソースシンボルのタプルは、消失したソースシンボルを復元するために、どの中間シンボルが合計される必要があるかを判断するために使用される。
【０５１１】
５．５．    乱数
セクション５．３．５．１において使用されている４つのアレイＶ０、Ｖ１、Ｖ２およびＶ３を以下で与える。４つのアレイの各々の中に２５６個のエントリがある。各アレイへのインデックス付けは０で開始し、エントリは３２ビット符号なし整数である。
【０５１２】
５．５．１．    テーブルＶ０
【表８】
0005602858.tif 000030
【０５１３】
５．５．２．    テーブルＶ１
【表９】
0005602858.tif 000031
【０５１４】
５．５．３．    テーブルＶ２
【表１０】
0005602858.tif 000032
【０５１５】
５．５．４．    テーブルＶ３
【表１１】
0005602858.tif 000033
【０５１６】
５．６．    システマティックインデックスおよび他のパラメータ
以下の表２は、Ｋ′のサポートされた値を指定する。この表はまた、Ｋ′の各サポートされた値について、システマティックインデックスＪ（Ｋ′）と、ＨＤＰＣシンボルの数Ｈ（Ｋ′）と、ＬＤＰＣシンボルの数Ｓ（Ｋ′）と、ＬＴシンボルの数Ｗ（Ｋ′）とを指定する。Ｋ′の各値について、Ｓ（Ｋ′）およびＷ（Ｋ′）の対応する値は素数である。
【０５１７】
システマティックインデックスＪ（Ｋ′）は、ソースシンボルタプルのセット（ｄ［０］，ａ［０］，ｂ［０］，ｄ１［０］，ａ１［０］，ｂ１［０］），．．．，（ｄ［Ｋ′−１］，ａ［Ｋ′−１］，ｂ［Ｋ′−１］，ｄ１［Ｋ′−１］，ａ１［Ｋ′−１］，ｂ１［Ｋ′−１］）が、Ｌ個の中間シンボルが一意に定義されるようなものであり、すなわち、図６中の行列Ａが最大階数を有し、したがって可逆であるようなものであるという特性を有するように設計される。
【表１２】
0005602858.tif 000034
0005602858.tif 000035
0005602858.tif 000036
0005602858.tif 000037
0005602858.tif 000038
0005602858.tif 000039
0005602858.tif 000040
0005602858.tif 000041
0005602858.tif 000042
0005602858.tif 000043
0005602858.tif 000044
0005602858.tif 000045
0005602858.tif 000046
0005602858.tif 000047
0005602858.tif 000048
0005602858.tif 000049
0005602858.tif 000050
0005602858.tif 000051
0005602858.tif 000052
0005602858.tif 000053
【０５１８】
５．７．    オクテット、シンボルおよび行列を用いる演算
５．７．１．    概略
このセクションでは、以降、ソースシンボルから符号化シンボルを生成するため、および符号化シンボルからソースシンボルを生成するために使用される算術演算について説明する。
【０５１９】
数学的に、オクテットは有限フィールドの要素、すなわち、２５６個の要素をもつ有限フィールドＧＦ（２５６）の要素として考えられ得、したがって、加算演算および乗算演算と、両方の演算に対する恒等元および逆元とが定義される。行列演算およびシンボル演算は、オクテットに対する算術演算に基づいて定義される。これは、有限フィールドの基礎をなす数学を理解する必要なしに、これらの算術演算の完全実装を可能にする。
【０５２０】
５．７．２．    オクテットに対する算術演算
オクテットは、通常の方法で範囲０〜２５５内の非負整数にマッピングされ、Ｂ［７］が最上位ビットであり、Ｂ［０］が最下位ビットである、シンボルＢ［７］，Ｂ［６］，Ｂ［５］，Ｂ［４］，Ｂ［３］，Ｂ［２］，Ｂ［１］，Ｂ［０］からのデータの単一のオクテットは、整数ｉ＝Ｂ［７］＊１２８＋Ｂ［６］＊６４＋Ｂ［５］＊３２＋Ｂ［４］＊１６＋Ｂ［３］＊８＋Ｂ［２］＊４＋Ｂ［１］＊２＋Ｂ［０］にマッピングされる。
【０５２１】
２つのオクテットｕおよびｖの加算はＸＯＲ演算として定義され、すなわち、次式のとおりである。
【０５２２】
ｕ＋ｖ＝ｕ＾ｖ
減算は同様に定義され、したがって、同じく次式が得られる。
【０５２３】
ｕ−ｖ＝ｕ＾ｖ
０要素（加法的単位元）は、整数０によって表されるオクテットである。ｕの加法逆元は単にｕであり、すなわち、次式のとおりである。
【０５２４】
ｕ＋ｕ＝０
２つのオクテットの乗算は、それぞれセクション５．７．３およびセクション５．７．４に与えられている２つのテーブルＯＣＴ＿ＥＸＰおよびＯＣＴ＿ＬＯＧによって定義される。テーブルＯＣＴ＿ＬＯＧは（０要素以外の）オクテットを非負整数にマッピングし、ＯＣＴ＿ＥＸＰは非負整数をオクテットにマッピングする。２つのオクテットｕおよびｖについて、次のように定義する。
【０５２５】
ｕ＊ｖ＝
ｕまたはｖのいずれかが０である場合、０
他の場合、ＯＣＴ＿ＥＸＰ［ＯＣＴ＿ＬＯＧ［ｕ］＋ＯＣＴ＿ＬＯＧ［ｖ］］
上式の右辺の「＋」は、それの引数が通常の整数であるので、通常の整数加算であることに留意されたい。
【０５２６】
ｖ！＝０である、２つのオクテットｕおよびｖの除算ｕ／ｖは、次のように定義される。
【０５２７】
ｕ／ｖ＝
ｕ＝＝０である場合、０
他の場合、ＯＣＴ＿ＥＸＰ［ＯＣＴ＿ＬＯＧ［ｕ］−ＯＣＴ＿ＬＯＧ［ｖ］＋２５５］
１要素（乗法単位元）は、整数１によって表されるオクテットである。あるオクテットについて、０要素でないｕ、すなわち、ｕの乗法逆元は次のようになる。
【０５２８】
ＯＣＴ＿ＥＸＰ［２５５−ＯＣＴ＿ＬＯＧ［ｕ］］
αによって示されるオクテットは、整数表現２をもつオクテットである。ｉが非負整数０≦ｉ＜２５６である場合、次式が得られる。
【０５２９】
α＾＾ｉ＝ＯＣＴ＿ＥＸＰ［ｉ］
５．７．３．    テーブルＯＣＴ＿ＥＸＰ
テーブルＯＣＴ＿ＥＸＰは５１０個のオクテットを含んでいる。インデックス付けは０で開始し、５０９にまでわたり、エントリは以下の正の整数表現をもつオクテットである。
【表１３】
0005602858.tif 000054
【０５３０】
５．７．４．    テーブルＯＣＴ＿ＬＯＧ
テーブルＯＣＴ＿ＬＯＧは２５５個の非負整数を含んでいる。テーブルは、整数として解釈されるオクテットによってインデックス付けされる。整数０によって表される、０要素に対応するオクテットはインデックスとして除外され、したがって、インデックス付けは１で開始し、２５５にまでわたり、エントリは以下のとおりである。
【表１４】
0005602858.tif 000055
【０５３１】
５．７．５．    シンボルに対する演算
シンボルに対する演算は、この仕様における長さＴのオクテットのベクトルに対する演算と同じセマンティクスを有する。したがって、ＵおよびＶが、それぞれオクテットｕ［０］，．．．，ｕ［Ｔ−１］およびｖ［０］，．．．，ｖ［Ｔ−１］によって形成される２つのシンボルである場合、シンボルＵ＋Ｖの和は、オクテットの構成要素単位の和であると定義され、すなわち、次式を満たすようなオクテットｄ［０］，．．．，ｄ［Ｔ−１］によって形成されるシンボルＤに等しい。
【０５３２】
ｄ［ｉ］＝ｕ［ｉ］＋ｖ［ｉ］，０≦ｉ＜Ｔ
さらに、βがオクテットである場合、積β＊Ｕは、Ｕの各オクテットにβを乗算することによって取得されるシンボルＤであると定義され、すなわち、次式のとおりである。
【０５３３】
ｄ［ｉ］＝β＊ｕ［ｉ］，０≦ｉ＜Ｔ
５．７．６．    行列に対する演算
この仕様におけるすべての行列は、オクテットであるエントリを有し、したがって、行列演算および定義は、基礎をなすオクテット算術、たとえば、行列、行列階数および行列反転に対する演算に関して定義される。
【０５３４】
５．８．    対応デコーダの要件
ＲａｐｔｏｒＱ対応デコーダが、ソースブロックの再構成のために、セクション５．３のエンコーダ仕様に従って生成された符号化シンボルの数学的に十分なセットを受信した場合、そのようなデコーダはソースブロック全体を復元すべきである。
【０５３５】
ＲａｐｔｏｒＱ対応デコーダは、セクション５．６の表２中のＫ′のすべての値について、Ｋ′個のソースシンボルをもつソースブロックに対して以下の復元特性を有するものとする。
【０５３６】
１．    デコーダが、可能なＥＳＩの範囲から無関係に一様ランダムに選定された対応するＥＳＩをもつ、セクション５．３のエンコーダ仕様に従って生成されたＫ′個の符号化シンボルを受信した場合、平均して、デコーダは、ソースブロック全体を復元することに１００回のうち最高でも１回失敗する。
【０５３７】
２．    デコーダが、可能なＥＳＩの範囲から無関係に一様ランダムに選定された対応するＥＳＩをもつ、セクション５．３のエンコーダ仕様に従って生成されたＫ′＋１個の符号化シンボルを受信した場合、平均して、デコーダは、ソースブロック全体を復元することに１００００回のうち最高でも１回失敗する。
【０５３８】
３．    デコーダが、可能なＥＳＩの範囲から無関係に一様ランダムに選定された対応するＥＳＩをもつ、セクション５．３のエンコーダ仕様に従って生成されたＫ′＋２個の符号化シンボルを受信した場合、平均して、デコーダは、ソースブロック全体を復元することに１００００００回のうち最高でも１回失敗する。
【０５３９】
セクション５．４において規定されている例示的なＦＥＣデコーダは、以下の両方の要件を満たすことに留意されたい。
【０５４０】
１．    セクション５．３のエンコーダ仕様に従って生成された符号化シンボルの数学的に十分なセットを受信する限り、ソースブロックを再構成することができる。
【０５４１】
２．    上記の必須の復元特性を満たす。
【０５４２】
６．    セキュリティ考慮事項
データ配信は、受信機によって正当なものとして受け付けられる破損したパケットを送る攻撃者によるサービス拒否攻撃を受けることがある。破損したパケットはマルチキャストツリーのルートに近いセッションに注入され得、その場合、破損したパケットは多くの受信機に届くことになるので、これはマルチキャスト配信に関して特に問題である。符号化データを含んでいる１つの破損したパケットの使用でさえ、完全に破損し使用不可能であるオブジェクトの復号に結果し得るので、これは、この文書で説明した符号が使用されるときに特に問題である。したがって、オブジェクトをアプリケーションに配信する前に、ソース認証および完全性検査を復号されたオブジェクトに適用することが推奨される。たとえば、オブジェクトのＳＨＡ−１ハッシュ［ＳＨＡ１］が送信の前に付加され得、ＳＨＡ−１ハッシュは、オブジェクトが復号された後、そのオブジェクトがアプリケーションに配信される前に計算され、検査される。ソース認証は、たとえば、ハッシュ値に加えて計算される、受信機によって検証可能なデジタル署名を含めることによって行われるべきである。また、ＴＥＳＬＡ［ＲＦＣ４０８２］などのパケット認証プロトコルを使用して、着信時に破損したパケットを検出し、廃棄することが推奨される。この方法はまた、ソース認証を行うために使用され得る。さらに、不正エージェントが破損したパケットをマルチキャストツリーデータ経路に首尾よく注入する可能性を制限するために、送信側から受信機への経路に沿ってすべてのネットワークルータおよびスイッチにおいて逆経路転送検査を可能にすることが推奨される。
【０５４３】
別のセキュリティ問題は、セッション記述中の一部のＦＥＣ情報が帯域外受信機によって取得され得ること、および、セッション記述がねつ造されたかまたは破損している場合、受信機は、受信されたパケットからコンテンツを復号するための正しいプロトコルを使用しないことである。これらの問題を回避するために、たとえば、ソース認証を使用して、受信機が許可された送信側からの正当なセッション記述のみを受け付けること保証することによって、受信機が誤ったセッション記述を受け付けることを防ぐための対策をとることが推奨される。
【０５４４】
７．    ＩＡＮＡ考慮事項
ＦＥＣ符号化ＩＤとＦＥＣインスタンスＩＤとの値はＩＡＮＡ登録の対象となる。この文書に適用されるＩＡＮＡ考慮事項に関する一般的なガイドラインについては、［ＲＦＣ５０５２］を参照されたい。この文書は、「ＲａｐｔｏｒＱ符号」にｉｅｔｆ：ｒｍｔ：ｆｅｃ：符号化名前空間の下の完全指定ＦＥＣ符号化ＩＤ６（ｔｂｃ）を割り当てる。
【０５４５】
８．    謝辞
Ｒａｎｇａｎａｔｈａｎ（Ｒａｎｇａ）Ｋｒｉｓｈｎａｎに謝意を表する。Ｒａｎｇａ  Ｋｒｉｓｈｎａｎは、実装詳細の発見および解決において、およびシステマティックインデックスの発見において大いに支えとなった。さらに、Ｈａｂｅｅｂ  Ｍｏｈｉｕｄｄｉｎ  ＭｏｈａｍｍｅｄおよびＡｎｔｏｎｉｏｓ  Ｐｉｔａｒｏｋｏｉｌｉｓ（両者ともミュンヘン工科大学（ＴＵＭ））およびＡｌａｎ  Ｓｈｉｎｓａｔｏは、この仕様に関する問題を明確化することおよび解決することに役立ったＲａｐｔｏｒＱエンコーダ／デコーダの２つの独立した実装を行った。
【０５４６】
９．    参考文献
９．１．    必須参考文献
［ＲＦＣ２１１９］    Ｂｒａｄｎｅｒ，Ｓ．、「Ｋｅｙ  ｗｏｒｄｓ  ｆｏｒ  ｕｓｅ  ｉｎ  ＲＦＣｓ  ｔ○  Ｉｎｄｉｃａｔｅ  Ｒｅｑｕｉｒｅｍｅｎｔ  Ｌｅｖｅｌｓ」、ＢＣＰ１４、ＲＦＣ２１１９、１９９７年３月
［ＲＦＣ４０８２］    Ｐｅｒｒｉｇ，Ａ．、Ｓｏｎｇ，Ｄ．、Ｃａｎｅｔｔｉ，Ｒ．、Ｔｙｇａｒ，Ｊ．、およびＢ．Ｂｒｉｓｃｏｅ、「Ｔｉｍｅｄ  Ｅｆｆｉｃｉｅｎｔ  Ｓｔｒｅａｍ  Ｌｏｓｓ−Ｔｏｌｅｒａｎｔ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  （ＴＥＳＬＡ）：  Ｍｕｌｔｉｃａｓｔ  Ｓｏｕｒｃｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｔｒａｎｓｆｏｒｍ  Ｉｎｔｒｏｄｕｃｔｉｏｎ」、ＲＦＣ４０８２、２００５年６月
［ＳＨＡ１］    「Ｓｅｃｕｒｅ  Ｈａｓｈ  Ｓｔａｎｄａｒｄ」、Ｆｅｄｅｒａｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｔａｎｄａｒｄｓ  Ｐｕｂｌｉｃａｔｉｏｎ（ＦＩＰＳ  ＰＵＢ）１８０−１、２００５年４月
［ＲＦＣ５０５２］    Ｗａｔｓｏｎ，Ｍ．、Ｌｕｂｙ，Ｍ．、およびＬ．Ｖｉｃｉｓａｎｏ、「Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ  （ＦＥＣ）  Ｂｕｉｌｄｉｎｇ  Ｂｌｏｃｋ」、ＲＦＣ５０５２、２００７年８月
９．２．    非必須参考文献
［ＲＦＣ３４５３］    Ｌｕｂｙ，Ｍ．、Ｖｉｃｉｓａｎｏ，Ｌ．、Ｇｅｍｍｅｌｌ，Ｊ．、Ｒｉｚｚｏ，Ｌ．、Ｈａｎｄｌｅｙ，Ｍ．、およびＪ．Ｃｒｏｗｃｒｏｆｔ、「Ｔｈｅ  Ｕｓｅ  ｏｆ  Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ  （ＦＥＣ）  ｉｎ  Ｒｅｌｉａｂｌｅ  Ｍｕｌｔｉｃａｓｔ」、ＲＦＣ３４５３、２００２年１２月
［ＲＦＣ５０５３］    Ｌｕｂｙ，Ｍ．、Ｓｈｏｋｒｏｌｌａｈｉ，Ａ．、Ｗａｔｓｏｎ，Ｍ．、およびＴ．Ｓｔｏｃｋｈａｍｍｅｒ、「Ｒａｐｔｏｒ  Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ  Ｓｃｈｅｍｅ  ｆｏｒ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ」、ＲＦＣ５０５３、２００７年１０月
著者の住所
Ｍｉｃｈａｅｌ  Ｌｕｂｙ
Ｑｕａｌｃｏｍｍ  Ｉｎｃｏｒｐｏｒａｔｅｄ
３１６５  Ｋｉｆｅｒ  Ｒｏａｄ
Ｓａｎｔａ  Ｃｌａｒａ，ＣＡ    ９５０５１
Ｕ．Ｓ．Ａ．
電子メール：ｌｕｂｙ＠ｑｕａｌｃｏｍｍ．ｃｏｍ
Ａｍｉｎ  Ｓｈｏｋｒｏｌｌａｈｉ
ＥＰＦＬ
Ｌａｂｏｒａｔｏｉｒｅ  ｄ’ａｌｇｏｒｉｔｈｍｉｑｕｅ
ＥＰＦＬ
Ｓｔａｔｉｏｎ  １４
Ｂａｔｉｍｅｎｔ  ＢＣ
Ｌａｕｓａｎｎｅ    １０１５
Ｓｗｉｔｚｅｒｌａｎｄ
電子メール：ａｍｉｎ．ｓｈｏｋｒｏｌｌａｈｉ＠ｅｐｆｌ．ｃｈ
Ｍａｒｋ  Ｗａｔｓｏｎ
Ｑｕａｌｃｏｍｍ  Ｉｎｃｏｒｐｏｒａｔｅｄ
３１６５  Ｋｉｆｅｒ  Ｒｏａｄ
Ｓａｎｔａ  Ｃｌａｒａ，ＣＡ    ９５０５１
Ｕ．Ｓ．Ａ．
電子メール：ｗａｔｓｏｎ＠ｑｕａｌｃｏｍｍ．ｃｏｍ
Ｔｈｏｍａｓ  Ｓｔｏｃｋｈａｍｍｅｒ
Ｎｏｍｏｒ  Ｒｅｓｅａｒｃｈ
Ｂｒｅｃｈｅｒｓｐｉｔｚｓｔｒａｓｓｅ  ８
Ｍｕｎｉｃｈ    ８１５４１
Ｇｅｒｍａｎｙ
電子メール：ｓｔｏｃｋｈａｍｍｅｒ＠ｎｏｍｏｒ．ｄｅ
Ｌｏｒｅｎｚ  Ｍｉｎｄｅｒ
Ｑｕａｌｃｏｍｍ  Ｉｎｃｏｒｐｏｒａｔｅｄ
３１６５  Ｋｉｆｅｒ  Ｒｏａｄ
Ｓａｎｔａ  Ｃｌａｒａ，ＣＡ    ９５０５１
Ｕ．Ｓ．Ａ．
電子メール：ｌｍｉｎｄｅｒ＠ｑｕａｌｃｏｍｍ．ｃｏｍ
【図１】
0005602858.tif 000056
【図２】
0005602858.tif 000057
【図３】
0005602858.tif 000058
【図４】
0005602858.tif 000059
【図５】
0005602858.tif 000060
【図６】
0005602858.tif 000061
【図７】
0005602858.tif 000062
【図８】
0005602858.tif 000063
【図９】
0005602858.tif 000064
【図１０】
0005602858.tif 000065
【図１１】
0005602858.tif 000066
【図１２】
0005602858.tif 000067
【図１３】
0005602858.tif 000068
【図１４】
0005602858.tif 000069
【図１５】
0005602858.tif 000070
【図１６】
0005602858.tif 000071
【図１７】
0005602858.tif 000072
【図１８】
0005602858.tif 000073
【図１９】
0005602858.tif 000074
【図２０】
0005602858.tif 000075
【図２１】
0005602858.tif 000076
【図２２】
0005602858.tif 000077
【図２３】
0005602858.tif 000078
【図２４】
0005602858.tif 000079
【図２５】
0005602858.tif 000080
【図２６】
0005602858.tif 000081
【図２７】
0005602858.tif 000082
【図２８】
0005602858.tif 000083
【図２９】
0005602858.tif 000084
【図３０】
0005602858.tif 000085
【図３１】
0005602858.tif 000086