エラー訂正コード

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

コンピューティング通信情報理論、および符号理論では、エラー訂正コード、場合によってはエラー訂正コードECC)が、信頼性の低いまたはノイズの多い通信チャネルを介したデータのエラーを制御するために使用されます。[1] [2]中心的な考え方は、送信者がメッセージを冗長な情報でECCの形式でエンコードすることです。冗長性により、受信者はメッセージのどこかで発生する可能性のある限られた数のエラーを検出し、多くの場合、再送信せずにこれらのエラーを修正できます。アメリカの数学者リチャードハミングは1940年代にこの分野を開拓し、1950年に最初のエラー訂正コードであるハミング(7,4)コードを発明しました。[2]

ECCは、発生したエラーを単に検出するのではなく修正できるという点で、エラー検出とは対照的です。利点は、ECCを使用するシステムでは、エラーが発生したときにデータの再送信を要求するためにリバースチャネルを必要としないことです。欠点は、メッセージに追加される固定オーバーヘッドがあるため、より高い転送チャネル帯域幅が必要になることです。したがって、ECCは、一方向通信リンクやマルチキャストで複数の受信機に送信する場合など、再送信にコストがかかるか不可能な状況で適用されます。待ち時間の長い接続にもメリットがあります。天王星の周りを周回している衛星の場合、エラーによる再送信により、5時間の遅延が発生する可能性があります。通常、ECC情報はに追加されます破損したデータの回復を可能にする大容量記憶装置は、モデムで広く使用されており、プライマリメモリがECCメモリであるシステムで使用されます。

受信機でのECC処理は、デジタルビットストリームまたはデジタル変調された搬送波の復調に適用できます。後者の場合、ECCは受信機での最初のアナログ-デジタル変換の不可欠な部分です。ビタビ復号器、ノイズによって破損したアナログ信号からデジタルデータを復調するためのソフトデシジョンアルゴリズムを実装しています。多くのECCエンコーダー/デコーダーは、ビットエラーレート(BER)信号を生成することもできます。これは、アナログ受信電子機器を微調整するためのフィードバックとして使用できます。

訂正できるエラーまたは欠落ビットの最大割合は、ECCコードの設計によって決定されるため、さまざまなエラー訂正コードがさまざまな条件に適しています。一般に、コードが強いほど冗長性が高まり、使用可能な帯域幅を使用して送信する必要があります。これにより、有効なビットレートが低下し、受信した実効信号対雑音比が向上します。クロード・シャノンのシャノンの通信路コーディング定理与えられた最大許容エラー確率に対して達成可能な最大通信帯域幅を計算するために使用できます。これにより、特定のベースノイズレベルを持つチャネルの理論上の最大情報転送速度の限界が確立されます。ただし、証明は建設的なものではないため、容量を達成するコードを構築する方法についての洞察は得られません。長年の研究の結果、2016年現在の一部の高度なECCシステム[3]は、理論上の最大値に非常に近づいています。

前方誤り訂正

電気通信情報理論、および符号理論では前方誤り訂正FEC)またはチャネル符号化[4] [3]は、信頼性の低いまたはノイズの多い通信チャネルを介したデータ伝送のエラーを制御するために使用される手法です。中心的な考え方は、送信者が冗長な方法でメッセージをエンコードすることです。ほとんどの場合、ECCを使用します。

冗長性により、受信者はメッセージのどこかで発生する可能性のある限られた数のエラーを検出し、多くの場合、再送信せずにこれらのエラーを修正できます。FECにより、受信機は、データの再送信を要求するために逆方向チャネルを必要とせずにエラーを修正できますが、固定された、より高い順方向チャネル帯域幅が犠牲になります。したがって、FECは、一方向通信リンクやマルチキャストで複数の受信機に送信する場合など、再送信にコストがかかるか不可能な状況で適用されます。FEC情報は通常、大容量記憶装置(磁気、光、ソリッドステート/フラッシュベース)デバイスに追加され、破損したデータの回復を可能にします。これはモデムで広く使用されています。は、プライマリメモリがECCメモリであるシステムや、受信機に再送信を要求する機能がない、またはそうするとかなりの遅延が発生するブロードキャスト状況で使用されます。たとえば、天王星を周回する衛星の場合、デコードエラーのために再送信すると、少なくとも5時間の遅延が発生します。

受信機でのFEC処理は、デジタルビットストリームまたはデジタル変調された搬送波の復調に適用できます。後者の場合、FECは受信機での最初のアナログ-デジタル変換の不可欠な部分です。ビタビ復号器、ノイズによって破損したアナログ信号からデジタルデータを復調するためのソフトデシジョンアルゴリズムを実装しています。多くのFECコーダーは、アナログ受信電子機器を微調整するためのフィードバックとして使用できる ビット誤り率(BER)信号を生成することもできます。

訂正できるエラーまたは欠落ビットの最大比率はECCの設計によって決定されるため、さまざまな順方向エラー訂正コードがさまざまな条件に適しています。一般に、コードが強いほど冗長性が高まり、使用可能な帯域幅を使用して送信する必要があります。これにより、有効なビットレートが低下し、受信した実効信号対雑音比が向上します。シャノンの通信路コーディング定理of Claude Shannonは、デコードエラーの確率をゼロにする最も効率的なコードを使用しながら、データ通信にどれだけの帯域幅が残っているかという質問に答えます。これにより、特定のベースノイズレベルを持つチャネルの理論上の最大情報転送速度の限界が確立されます。彼の証明は建設的なものではないため、容量を達成するコードを構築する方法についての洞察は得られません。しかし、長年の研究の後、極座標コード[3]のようないくつかの高度なFECシステムは、無限の長さのフレームの仮説の下でシャノンチャネル容量を達成します。

仕組み

ECCは、アルゴリズムを使用して送信情報に冗長性を追加することによって実現されます。冗長ビットは、多くの元の情報ビットの複雑な機能である可能性があります。元の情報は、エンコードされた出力に文字通り表示される場合と表示されない場合があります。出力に変更されていない入力を含むコードは体系的ですが、そうでないコードは非体系的です。

ECCの単純な例は、各データビットを3回送信することです。これは、(3,1)繰り返しコードとして知られています。ノイズの多いチャネルを介して、受信者は8つのバージョンの出力を見る可能性があります。以下の表を参照してください。

トリプレットを受け取りました として解釈
000 0(エラーなし)
001 0
010 0
100 0
111 1(エラーなし)
110 1
101 1
011 1

これにより、3つのサンプルのいずれかのエラーを「多数決」または「民主的投票」で修正できます。このECCの修正能力は次のとおりです。

  • エラーのあるトリプレットの最大1ビット、または
  • 最大2ビットのトリプレットが省略されます(大文字と小文字は表に示されていません)。

実装は簡単で広く使用されていますが、この三重モジュラー冗長性は比較的非効率的なECCです。より優れたECCコードは、通常、最後の数十または最後の数百の以前に受信したビットを調べて、現在の少数のビット(通常は2〜8ビットのグループ)をデコードする方法を決定します。

エラーを減らすためのノイズの平均化

ECCは「ノイズの平均化」によって機能すると言えます。各データビットは多くの送信シンボルに影響を与えるため、ノイズによる一部のシンボルの破損により、通常、同じユーザーデータに依存する破損していない他の受信シンボルから元のユーザーデータを抽出できます。

ほとんどの通信システムは、予想される最悪の場合のビットエラーレートを許容するように設計された固定チャネルコードを使用し、ビットエラーレートがさらに悪化するとまったく機能しなくなります。ただし、一部のシステムは特定のチャネルエラー条件に適応します。ハイブリッド自動再送要求の一部のインスタンスは、ECCがエラーレートを処理できる限り固定ECC方式を使用し、エラーレートが高くなりすぎる とARQに切り替えます。アダプティブ変調およびコーディングは、さまざまなECCレートを使用し、チャネルのエラーレートが高い場合はパケットごとにエラー訂正ビットを追加し、不要な場合はそれらを削除します。

ECCの種類

エラー訂正コードの簡単な分類

ECCコードの2つの主要なカテゴリは、ブロックコード畳み込みコードです。

  • ブロックコードは、所定のサイズのビットまたはシンボルの固定サイズのブロック(パケット)で機能します。実用的なブロックコードは、一般に、多項式時間でブロック長にハードデコードできます。
  • 畳み込み符号は、任意の長さのビットまたはシンボルストリームで機能します。他のアルゴリズムが使用されることもありますが、ほとんどの場合、ビタビアルゴリズムでソフトデコードされます。ビタビ復号化は、畳み込み符号の制約長を増加させながら漸近的に最適な復号化効率を可能にしますが、複雑さを指数関数的に増加させます。終了する畳み込みコードは、入力データのブロックをエンコードするという点で「ブロックコード」でもありますが、畳み込みコードのブロックサイズは一般に任意ですが、ブロックコードのサイズは代数的特性によって決まります。畳み込み符号の終了のタイプには、「テールバイティング」と「ビットフラッシング」があります。

ブロックコードには多くの種類があります。リードソロモン符号化は、コンパクトディスクDVD、およびハードディスクドライブで広く使用されていることで注目に値します古典的なブロックコードの他の例には、ゴレイBCH多次元パリティ、およびハミングコードが含まれます。

ハミングECCは、NANDフラッシュメモリエラーを修正するために一般的に使用されます。[5] これにより、シングルビットエラー訂正と2ビットエラー検出が提供されます。ハミングコードは、より信頼性の高いシングルレベルセル(SLC)NANDにのみ適しています。Denserマルチレベルセル(MLC)NANDは、BCHやリードソロモンなどのマルチビット補正ECCを使用する場合があります。[6] [7] NORフラッシュは通常、エラー訂正を使用しません。[6]

従来のブロックコードは通常、ハードデシジョンアルゴリズムを使用してデコードされます[8]。これは、すべての入力信号と出力信号について、1ビットと0ビットのどちらに対応するかをハードデシジョンすることを意味します。対照的に、畳み込み符号は通常、ビタビ、MAP、またはBCJRアルゴリズムなどのソフト決定アルゴリズムを使用してデコードされます。これらのアルゴリズムは、(離散化された)アナログ信号を処理し、ハード決定デコードよりもはるかに高いエラー訂正パフォーマンスを可能にします。

ほぼすべての古典的なブロックコードは、有限体の代数的特性を適用します。したがって、古典的なブロックコードはしばしば代数コードと呼ばれます。

エラー検出またはエラー訂正機能を指定することが多い従来のブロックコードとは対照的に、LDPCコードなどの多くの最新のブロックコードにはそのような保証がありません。代わりに、最新のコードはビットエラーレートの観点から評価されます。

ほとんどの前方誤り訂正コードは、ビットフリップのみを訂正し、ビット挿入またはビット削除は訂正しません。この設定では、ハミング距離がビット誤り率を測定する適切な方法です。マーカーコードやウォーターマークコードなど、いくつかの前方誤り訂正コードは、ビット挿入とビット削除を訂正するように設計されています。このようなコードを使用する場合、レーベンシュタイン距離はビットエラーレートを測定するためのより適切な方法です。 [9]

コードレートと信頼性とデータレートのトレードオフ

ECCの基本原理は、送信機によってエンコードされた真のメッセージをデコーダーが見つけられるようにするために、冗長ビットを追加することです。特定のECCシステムのコードレートは、特定の通信パッケージ内の情報ビット数とビットの総数(つまり、情報と冗長ビット)の比率として定義されます。したがって、コードレートは実数です。ゼロに近い低いコードレートは、良好なパフォーマンスを達成するために多くの冗長ビットを使用する強力なコードを意味し、1に近い大きなコードレートは、弱いコードを意味します。

情報を保護する冗長ビットは、保護しようとしているのと同じ通信リソースを使用して転送する必要があります。これにより、信頼性とデータレートの間に根本的なトレードオフが発生します。[10]極端な例として、強力なコード(コードレートが低い)は、実効データレートを低下させる代わりに、受信機のSNR(信号対雑音比)を大幅に増加させ、ビットエラーレートを低下させる可能性があります。 。一方、ECCを使用しない場合(つまり、コードレートが1に等しい場合)は、追加の保護なしでビットを残すという犠牲を払って、情報転送の目的でフルチャネルを使用します。

興味深い質問の1つは、次のとおりです。情報転送の観点から、デコードエラー率が無視できるECCはどれほど効率的でしょうか。この質問は、Claude Shannonが2番目の定理で答えました。これは、チャネル容量は、エラーレートがゼロになる傾向があるECCによって達成可能な最大ビットレートであるというものです。[11]彼の証明は、ガウスランダムコーディングに依存しています。実際のアプリケーション。シャノンの仕事によって与えられた上限は、究極のパフォーマンス境界に近づくことができるECCを設計する上での長い旅に影響を与えました。今日のさまざまなコードは、ほぼシャノンの限界に達する可能性があります。ただし、ECCを達成する容量は、通常、実装が非常に複雑です。

最も人気のあるECCには、パフォーマンスと計算の複雑さの間のトレードオフがあります。通常、それらのパラメーターは、シナリオに応じて最適化できる、可能なコードレートの範囲を提供します。通常、この最適化は、データレートへの影響を最小限に抑えながら、デコードエラーの可能性を低くするために行われます。コードレートを最適化するためのもう1つの基準は、通信のエネルギーコストに合わせて、低いエラーレートと再送信数のバランスを取ることです。[12]

パフォーマンスを向上させるための連結ECCコード

古典的な(代数的)ブロックコードと畳み込み符号は、短い制約長のビタビ復号畳み込み符号がほとんどの作業を行い、より大きな記号サイズとブロック長のブロック符号(通常はリードソロモン)を含む連結符号化方式で頻繁に組み合わされます畳み込みデコーダーによって発生したエラーを「モップアップ」します。このファミリのエラー訂正コードを使用したシングルパスデコードでは、エラーレートが非常に低くなる可能性がありますが、長距離の伝送条件(深宇宙など)では、反復デコードをお勧めします。

ボイジャー2号が1986年の天王星との遭遇でこの技術を最初に使用して以来、連結コードは衛星および深宇宙通信の標準的な慣行となっていますガリレオ航空機は、アンテナの故障によって引き起こされる非常に高いエラー率の状態を補償するために、反復的な連結コードを使用しました。

低密度パリティチェック(LDPC)

低密度パリティチェック(LDPC)コードは、多くのシングルパリティチェック(SPC)コードから作成された非常に効率的な線形ブロックコードのクラスです。それらは、ブロック長に関して線形時間計算量で、反復ソフト決定デコードアプローチを使用して、チャネル容量(理論上の最大値)に非常に近いパフォーマンスを提供できます。実際の実装は、構成要素であるSPCコードを並列にデコードすることに大きく依存しています。

LDPCコードは、1960年にRobert G. Gallagerの博士論文で最初に導入されましたが、エンコーダーとデコーダーの実装における計算作業とリードソロモンコードの導入により、1990年代までほとんど無視されていました。

LDPCコードは現在、 DVB-S2(デジタルビデオ放送–衛星–第2世代)、WiMAX(マイクロ波通信のIEEE 802.16e標準)、高速無線LAN(IEEE 802.11n )などの最近の多くの高速通信標準で使用されています。 )、[13] 10GBase-Tイーサネット(802.3an)およびG.hn/G.9960(電力線、電話線、および同軸ケーブルを介したネットワークのITU-T標準)。その他のLDPCコードは、 3GPP MBMS内のワイヤレス通信標準用に標準化されていますファウンテンコードを参照)。

ターボ符号

ターボ符号化は、2つ以上の比較的単純な畳み込み符号とインターリーバーを組み合わせて、シャノンの限界の1デシベル以内で実行できるブロック符号を生成する反復ソフト復号化方式です実用的なアプリケーションの観点からLDPCコードよりも前から、同様のパフォーマンスを提供するようになりまし

ターボ符号化の最も初期の商用アプリケーションの1つは、Qualcommによって開発され、 Verizon WirelessSprint、およびその他の通信事業者によって販売されたCDMA2000 1x(TIA IS-2000)デジタルセルラーテクノロジーでした。また、特にインターネットアクセス用のCDMA2000 1x、 1xEV-DO(TIA IS-856)の進化にも使用されます。1xと同様に、EV-DOはQualcommによって開発され、 Verizon WirelessSprint、およびその他の通信事業者によって販売されています(Verizonの1xEV-DOのマーケティング名はBroadband Accessであり、Sprintの1xEV-DOの消費者およびビジネスマーケティング名はPowerVisionMobileです。ブロードバンド、 それぞれ)。

コードのローカルデコードとテスト

場合によっては、メッセージの1ビットをデコードするか、特定の信号がコードワードであるかどうかを確認し、信号全体を見ずにデコードする必要があります。これは、コードワードが大きすぎて従来の速度で十分に高速にデコードできず、今のところメッセージのほんの数ビットしか関心がないストリーミング設定では意味があります。また、そのようなコードは、計算の複雑さの理論において、たとえば確率的にチェック可能な証明の設計のための重要なツールになっています

ローカルでデコード可能なコードはエラー訂正コードであり、コードワードが一定の位置で破損した後でも、コードワードの少数の(たとえば一定の)位置を確認するだけで、メッセージの1ビットを確率的に回復できます。ローカルでテスト可能なコードは、信号の少数の位置を確認するだけで、信号がコードワードに近いかどうかを確率的にチェックできるエラー訂正コードです。

インターリーブ

インターリーブのアイデアの簡単な図

インターリーブは、前方誤り訂正符号のパフォーマンスを向上させるために、デジタル通信およびストレージシステムで頻繁に使用されます。多くの通信チャネルはメモリレスではありません。エラーは通常、独立してではなくバーストで発生します。コードワード内のエラーの数がエラー訂正コードの機能を超えると、元のコードワードの回復に失敗します。インターリーブは、複数のコードワード間でソースシンボルをシャッフルすることでこの問題を軽減し、それによってエラーのより均一な分布を作成します。[14]したがって、インターリーブはバーストエラー訂正に広く使用されています

ターボコードLDPCコードなどの最新の反復コードの分析では、通常、エラーの独立した分布を想定しています。[15]したがって、LDPCコードを使用するシステムは、通常、コードワード内のシンボル間で追加のインターリーブを使用します。[16]

ターボ符号の場合、インターリーバーは不可欠なコンポーネントであり、その適切な設計は優れたパフォーマンスのために重要です。[14] [17]反復デコードアルゴリズムは、デコーダーを表す因子グラフに短いサイクルがない場合に最適に機能します。インターリーバーは、短いサイクルを避けるために選択されます。

インターリーバーの設計には次のものが含まれます。

  • 長方形(または均一)インターリーバー(上記のスキップ係数を使用する方法と同様)
  • 畳み込みインターリーバー
  • ランダムインターリーバー(インターリーバーが既知のランダム順列である場合)
  • S-ランダムインターリーバー(インターリーバーは、距離S内の入力シンボルが出力のSの距離内に表示されないという制約のある既知のランダム順列です)。[18]
  • 競合のない2次置換多項式(QPP)。[19]使用例は、3GPP Long TermEvolutionモバイル通信規格にあります。[20]

マルチキャリア通信システムでは、キャリア間のインターリーブを使用して、周波数ダイバーシティを提供し、たとえば、周波数選択性フェージングまたは狭帯域干渉を軽減することができる。[21]

インターリーブなしの送信

エラーのないメッセージ:aaaabbbbccccddddeeeeffffgggg
バーストエラーのある送信:aaaabbbbccc ____ deeeeffffgggg

ここで、同じ文字の各グループは、4ビットの1ビットのエラー訂正コードワードを表します。コードワードccccは1ビットで変更されて修正できますが、コードワードddddは3ビットで変更されているため、まったくデコードできないか、正しくデコードされていない可能性があります。

インターリーブあり

エラーのないコード語:aaaabbbbccccddddeeeeffffgggg
インターリーブ:abcdefgabcdefgabcdefgabcdefg
バーストエラーのある送信:abcdefgabcd ____ bcdefgabcdefg
デインターリーブ後に受信したコードワード:aa_abbbbccccdddde_eef_ffg_gg

コードワード「aaaa」、「eeee」、「ffff」、および「gggg」のそれぞれで、1ビットのみが変更されるため、1ビットのエラー訂正コードはすべてを正しくデコードします。

インターリーブなしの送信

元の送信された文:ThisIsAnExampleOfInterleaving
バーストエラーのある文を受信しました:ThisIs ______ pleOfInterleaving

「AnExample」という用語は、ほとんど理解できず、修正が困難になります。

インターリーブあり

送信された文:ThisIsAnExampleOfInterleaving .. ..
エラーのない送信:TIEpfeaghsxlIrv.iAaenli.snmOten。
バーストエラーのある文を受信しました:TIEpfe ______ Irv.iAaenli.snmOten。
デインターリーブ後に受信した文:T_isI_AnE_amp_eOfInterle_vin_..。

単語が完全に失われることはなく、欠落している文字は最小限の推測で回復できます。

インターリーブのデメリット

インターリーブ技術を使用すると、全体の遅延が増加します。これは、パケットをデコードする前に、インターリーブされたブロック全体を受信する必要があるためです。[22]また、インターリーバーはエラーの構造を隠します。インターリーバーがない場合、より高度なデコードアルゴリズムはエラー構造を利用し、インターリーバーと組み合わせた単純なデコーダーよりも信頼性の高い通信を実現できます[要出典]このようなアルゴリズムの例は、ニューラルネットワーク[23]構造 に基づいています。

エラー訂正コード用のソフトウェア

ソフトウェアでエラー訂正コード(ECC)の動作をシミュレートすることは、ECCを設計、検証、および改善するための一般的な方法です。今後のワイヤレス5G規格は、ソフトウェアECCの新しい範囲のアプリケーションを開発します。ソフトウェア無線(SDR)コンテキストでのクラウド無線アクセスネットワーク(C-RAN)です。アイデアは、通信でソフトウェアECCを直接使用することです。たとえば、5Gでは、ソフトウェアECCをクラウドに配置し、アンテナをこのコンピューティングリソースに接続できます。これにより、通信ネットワークの柔軟性が向上し、最終的にはシステムのエネルギー効率が向上します。

これに関連して、以下にリストされているさまざまな利用可能なオープンソースソフトウェアがあります(網羅的ではありません)。

  • AFF3CT(Fast Forward Error Correction Toolbox):C ++の完全な通信チェーン(Turbo、LDPC、Polarコードなどの多くのサポートされているコード)、非常に高速で、チャネルコーディングに特化しています(シミュレーション用のプログラムとして、またはSDR用のライブラリ)。
  • IT ++:線形代数、数値最適化、信号処理、通信、および統計のためのクラスと関数のC ++ライブラリ。
  • OpenAir:Evolved Packet Core Networksに関する3GPP仕様の実装(C)。

エラー訂正コードのリスト

距離 コード
2(単一エラー検出) パリティ
3(単一エラー訂正) 三重モジュール冗長性
3(単一エラー訂正) ハミングなどの完璧なハミング(7,4)
4(SECDED 拡張ハミング
5(二重エラー訂正)
6(ダブルエラー修正-/トリプルエラー検出)
7(3つのエラー訂正) 完璧なバイナリゴレイコード
8(TECFED) 拡張されたバイナリゴレイコード

も参照してください

参考文献

  1. ^ グローバー、ニール; ダドリー、トレント(1990)。エンジニアのための実用的なエラー修正設計(改訂1.1、第2版)。CO、USA:CirrusLogicISBN 0-927239-00-0
  2. ^ a b ハミング、リチャード・ウェズリー(1950年4月)。「エラー検出およびエラー訂正コード」。ベルシステムテクニカルジャーナル米国:AT&T29(2):147–160。土井10.1002 /j.1538-7305.1950.tb00463.x
  3. ^ a b c Maunder、Robert(2016)。「チャネルコーディングの概要」
  4. ^ チャールズ・ワン; ディーン・スクラール; ダイアナジョンソン(2001年から2002年の冬)。「前方誤り訂正符号化」クロスリンクエアロスペースコープレーション。3(1)。2012年2月25日にオリジナルからアーカイブされました2006年3月5日取得フォワードエラー訂正コードのしくみ {{cite journal}}:(ヘルプ外部リンク|quote=
  5. ^ 「NANDフラッシュメモリデバイスのハミングコード」 2016年8月21日にWaybackMachineでアーカイブされました。EETimes-アジア。どうやら「MicronテクニカルノートTN-29-08:NANDフラッシュメモリデバイスのハミングコード」に基づいています。2005年。どちらも次のように述べています。「ハミングアルゴリズムは、多くのSLCNANDフラッシュベースのアプリケーションでエラーを検出および修正するための業界で認められた方法です。」
  6. ^ a b 「フラッシュメモリではどのタイプのECCを使用する必要がありますか?」(アプリケーションノート)スパンション。2011.リードソロモンアルゴリズムとBCHアルゴリズムの両方が、MLCNANDフラッシュの一般的なECCの選択肢です。...ハミングベースのブロックコードは、SLCで最も一般的に使用されるECCです。...リードソロモンとBCHはどちらも複数のエラーを処理でき、MLCフラッシュで広く使用されています。
  7. ^ ジムクック(2007年8月)。「NANDフラッシュメモリの不便な真実」(PDF)p。28. SLCの場合、補正しきい値が1のコードで十分です。t = 4が必要です... MLCの場合。
  8. ^ Baldi、M。; Chiaraluce、F。(2008)。「マルチメディア送信におけるBCHおよびRSコードの信念伝搬復号化のための簡単なスキーム」デジタルマルチメディア放送の国際ジャーナル2008:1–12。土井10.1155 / 2008/957846
  9. ^ シャー、ガウラフ; モリーナ、アンドレス; ブレイズ、マット(2006)。「キーボードと秘密チャネル」USENIX 2018年12月20日取得
  10. ^ ツェ、デビッド; Viswanath、Pramod(2005)、Fundamentals of Wireless CommunicationCambridge University Press、UK
  11. ^ シャノン、CE(1948)。「コミュニケーションの数学的理論」(PDF)ベルシステムテクニカルジャーナル27(3–4):379–423&623–656。土井10.1002 /j.1538-7305.1948.tb01338.xhdl11858 / 00-001M-0000-002C-4314-2
  12. ^ Rosas、F。; ブランテ、G。; Souza、RD; Oberli、C。(2014)。「エネルギー効率の高い無線通信を実現するためのコードレートの最適化」IEEEワイヤレス通信およびネットワーク会議(WCNC)の議事録土井10.1109 /WCNC.2014.6952166
  13. ^ IEEE標準、セクション20.3.11.6 "802.11n-2009" 2013年2月3日にWaybackMachineでアーカイブ、IEEE、2009年10月29日、2011年3月21日にアクセス。
  14. ^ a b Vucetic、B。; 元、J。(2000)。ターボ符号:原理と応用SpringerVerlagISBN 978-0-7923-7868-6
  15. ^ ルビー、マイケル; ミッツェンマッハー、M。; Shokrollahi、A。; Spielman、D。; Stemann、V。(1997)。「実用的な損失回復力のあるコード」。Proc。計算理論に関する第29回ACM(Association for Computing Machinery)シンポジウム
  16. ^ 「デジタルビデオ放送(DVB);放送、インタラクティブサービス、取材およびその他の衛星ブロードバンドアプリケーション(DVB-S2)用の第2世代フレーミング構造、チャネルコーディングおよび変調システム」。En 302307ETSI(V1.2.1)。2009年4月。
  17. ^ アンドリュース、KS; Divsalar、D。; Dolinar、S。; ハムキンス、J。; ジョーンズ、CR; Pollara、F。(2007年11月)。「深宇宙アプリケーション用のターボおよびLDPCコードの開発」。IEEEの議事録95(11):2142–2156。土井10.1109 /JPROC.2007.905132S2CID9289140_ 
  18. ^ Dolinar、S。; Divsalar、D。(1995年8月15日)。「ランダムおよび非ランダム順列を使用したターボコードの重み分布」。TDA進捗レポート122:42–122。Bibcode1995TDAPR.122 ... 56DCiteSeerX10.1.1.105.6640_ 
  19. ^ 竹下、オスカー(2006)。「置換多項式インターリーバー:代数幾何学的展望」。情報理論に関するIEEEトランザクション53(6):2116–2132。arXivcs / 0601048Bibcode2006cs ........ 1048T土井10.1109 /TIT.2007.896870S2CID660_ 
  20. ^ 3GPP TS 36.212、バージョン8.8.0、14ページ
  21. ^ 「デジタルビデオ放送(DVB);第2世代地上デジタルテレビ放送システム(DVB-T2)のフレーム構造、チャネルコーディングおよび変調」。En 302755ETSI(V1.1.1)。2009年9月。
  22. ^ Techie(2010年6月3日)。「インターリーブの説明」W3Techieブログ2010年6月3日取得
  23. ^ Krastanov、Stefan; 江、梁(2017年9月8日)。「スタビライザーコード用のディープニューラルネットワーク確率デコーダー」ScientificReports7(1):11003。arXiv1705.09334Bibcode2017NatSR ... 711003K土井10.1038 / s41598-017-11266-1PMC5591216_ PMID28887480_  
  24. ^ ペリー、ジョナサン; バラクリシュナン、ハリ; Shah、Devavrat(2011)。「レートレス脊椎コード」ネットワークのホットトピックに関する第10回ACMワークショップの議事録土井10.1145 /2070562.2070568hdl1721.1 / 79676

さらに読む

外部リンク