図書館員のコンピュータ基礎講座

• TOP
• エラー制御

エラー制御

エラー検出

データは長い距離を旅しているわけですから、通信を行っている間にどうしてもエラーが発生します。電話回線にしても、LAN回線にしても周りの環境などによりノイズが発生します。通信途中でノイズが入ったとしても、コンピュータは素直にエラーの入ったままデータをやり取りします。「0」と「1」の、2種類しか存在しないコンピュータの世界では、少しノイズが入っただけでも、送り側のデータと受け側のデータが全く異なったものになってしまいます。例えば、テキストデータを受信する場合にノイズが入ると、そこから文字化けが起こり、何が書いてあるか全くわからないものになってしまいます。

文字化け

私が図書館業務で通信を始めたころには、この様な文字化けはよく起こっていました。そこで、通信などで受送信したデータを通信終了後プリントアウトしてエラーのチェックを人の目で確認し、文字化けなどが起こっていたら、再度同じデータを受送信したりしてエラーを修正したりしていました。ひどい時には途中で通信ができなくなり、回線が切れてしまうこともありました。
この様なエラーを機械的にチェックするために考え出されたのがエラー制御（Error Control）の仕組みです。シンプルなものから、徐々に高性能なものが搭載されるようになったのですが、ここでは代表的なものを幾つかご紹介します。初めてパソコン通信する場合などには、どの方法でエラーチェックをするのか、予め通信ソフトで設定しておく必要があります。
今回の話は、少し難しいかも知れません。インターネットのみを利用していて、Nifty-ServeやNEC PC-VANなどのパソコン通信は利用していない人にはほとんど知らなくていい世界です。パソコン通信をしている人も、特に内容を理解する必要はありません。どの方式でエラーチェックを行うかを調べて、そのようにソフトを設定できれば良いのです。

パリティ・チェック（Parity check）

通信ソフトやモデムの設定欄には、大抵「パリティ」という項目があります。「偶数(even)パリティ」、「奇数(odd)パリティ」、「パリティなし(none)」などの選択ができるようになっています。
パリティ・チェックは、基本的でシンプルなエラー制御方式です。この方式では、まず、どの方法でチェックするのか（「偶数」か「奇数」か「なし」か）を送信側と受信側で先に決めておきます。そして、データに1ビット（0か1）を加えて、常に偶数か奇数の状態になるようにしてチェックを行うのです。例えば、「A」という文字のASCIIコードは「01000001」ですが、「偶数(even)」パリティでは、最後に「0」を加えて、「010000010」の形にして送信します（この最後の0をパリティ・ビットと呼びます）。すると、データ内の「1」の数が2つ、つまり、偶数になります。受信側では、送られてきたデータの1の数が偶数ならば正しいデータ、奇数ならばエラー・データと判断します。

偶数パリティチェック（末尾の数字がパリティビット）

正しく送受信された場合

送信側

01000001

0

01000001

0

受信側

（1の数が偶数なので正しいデータだな）

通信中にノイズが入り、5ビット目の「0」が「1」になってしまった場合

送信側

01000001

0

01001001

0

受信側

（1の数が奇数なのでエラー・データだな）

大変シンプルなエラーチェックの方法ですが、遇数個のビットにエラーが発生した場合にはエラーだと検出できませんし、0が1に入れ代わるだけでなく、いくつかのビットが欠落したりした場合にも有効ではありません。

通信中にノイズが入り、7ビット目の「0」が「1」に、8ビット目の「1」が「0」になってしまった場合

送信側

01000001

0

01000010

0

受信側

（1の数が偶数なので正しいデータだな）

そこで、この文字単位でパリティチェックを行う方式（垂直パリティ・チェック）だけではなく、複数の文字からなるブロック単位にパリティビットを追加する方式（水平パリティ・チェック）も利用されることがあります。

「偶数」、「奇数」以外のパリティチェック方式には、上のように「パリティなし」、「マーク・パリティ」、「スペース・パリティ」などがあります。

「パリティなし」は、「ノン・パリティ」とも呼ばれ、パリティ・ビットを付加しません。したがって、パリティチェックは行われません。
「マーク・パリティ」は、パリティ・ビットには常に1が設定され、8番目のビットとして使用さます。
「スペース・パリティ」はパリティ・ビットとして0が8番目のビットとして使用されます。

チェックサム

チェックサム（check sum）の「サム」は合計を意味します。その名の通り、データの数値を順に足していき、その合計をチェック用の符号としてデータ本体に付け加えます。受信側でも、受け取ったデータの数値を同じ様に足していき、その合計と、チェック用の符号とを比較し、同じなら正しいデータ、違っていたらエラー・データと判断します。例えば、「CAT」という文字を下の表の様に足し算すると、答えは16進数で「D8」になります。そして、この「D8」がチェックサムです。

チェックサムは、幾つかのデータのまとまりごとにチェック用の符号を付加する形をとりますので、幾つごとに付加するかを予め決めておかなければなりません。チェックサムは、パソコン通信で広く使用されているXmodem（エックスモデム）というファイル転送プロトコルで用いられていますが、Xmodemの場合には128バイト単位でチェックサムを1バイト分だけ付加（つまり、合計の最後の2桁のみを付加）してデータを送受信します。
しかし、Xmodemのチェックサムは足し算した結果の最後の1バイトだけでチェックする方式ですので、計算結果が同じになるエラーが発生した場合や、文字の順番が入れ替わる場合などにはエラーチェックができません。

CRC（巡回冗長検査）

CRC（巡回冗長検査または、巡回冗長符号；Cyclic Redundancy Check）は、今まで紹介した検査方法の欠点を解決するために考案された検査方法のひとつで、Xmodemをはじめ、広く用いられています。チェックサムが、足し算を基本としてチェックしていたのに対して、この方式では割り算を基本としています。
データをあるまとまったブロックで分け、そのブロック毎に特定の数で割り、その余りを検出符号として使用します。その割るための数（生成多項式という）にはいろいろあるのですが、一般的には16ビット「CRC-16」か、32ビット「CRC32」のCRC値が使われます（12ビット「CRC-12」のCRC値もあります）。例えば、16ビットのCRCは「1 0001 0000 0010 0001（X¹⁶+X¹²+X⁵+1）」という数を使用します。この方式はXmodem以外に、Ymodem（ワイモデム）、B-Plus（ビープラス）などのファイル転送プロトコルで使用されてているほか、LHAなどのファイル圧縮・解凍ソフトの誤り検出にも用いられています。また、より高精度の検出を実現するために32ビットのCRC値を使用する場合もあります。この方式はZmodem（ゼットモデム）や圧縮ソフトなどでも用いられています。

エラー訂正

エラーを発見したとしても、「エラーが発生しました」というメッセージが表示されるだけでは、不便です。エラーを発見したら訂正してくれる方法があってこそエラー制御と呼べるでしょう。私が持っている28800bpsのモデムの仕様の欄には、

のような記載があります。現在市販されているモデムのほとんどには、エラー訂正機能として、MNPとV.4.2が採用されています。2つとも、基本的には次のような手順でエラー訂正を行います。まず、送信側はデータを一定の大きさのブロックに分割し、エラーチェック用のデータをつけて相手に送ります。受信側では、エラーデータが送られてきた場合には、送信側にその部分だけ再送してもらうのです。

MNP

MNP（Microcom Networking Protocol）は、Microcomが開発したモデム間のデータ転送の規格です。機能に応じたクラス分けがしてあり、クラス1から4までが、エラー訂正のためのプロトコルに当てられていますが、現在市販されているモデムのほとんどは、エラー訂正機能として、MNPクラス4に準拠しています。

V.42

V.42は、電気通信の国際的な規格であるITU-T勧告のひとつで、2種類のエラー訂正機能を併せ持っています。ひとつは、LAPM（エルエイピーエム、ラップエム；Link Access Procedure for Modems）というプロトコルで、もうひとつは、先に紹介したクラス1から4までのMNP機能です。

これらは、モデムの規格なので、送信側と受信側のモデムが同じプロトコルに対応している必要があります。しかし、利用者が、相手のモデムに合わせてモデムをいちいち取り替えなければならないわけではありません。接続時にモデム同士が自己紹介をし、V.42対応なのかMNPのみ対応なのか、何にも対応していないのかの情報をやり取りし、共通するプロトコルで通信を始めるのです。ただし、現在はITU-T規格が主流で、MNPのみで使用される事はあまりありません。