データ伝送web講座

8. 伝送誤り制御

line

8.3. 誤り制御の手順

8.3.(1) 一般的手順

◆ 伝送誤りを検出する、チェックコードには、誤りを検出できるだけのものと、誤りを訂正できる能力を持つものとがあります。通常は、誤り検出能力を使用して、誤り制御を行います。誤り検出能力を使用して、誤り制御を行う手順について解説します。

8.3.(1-A) 誤り発生の場所

◆ 概要については、図.2 に示しました。ただし、、これでは不十分です。図.2 では、伝送誤りは、データ部分に発生するものとしています。しかし、伝送誤りは、データ部分に発生するとは限りません。たとえば、図.13 のようなことも、起こります。

[図.13] 誤りは各所で発生する

誤りは各所で発生する

◆ (a) は、同期式で、フレームの先頭に、フレーム同期がある場合です。このフレーム同期に誤りが有ったときは、受信側では、フレーム同期を認識できませんから、このフレームを取り込むことができません。
(b) は、ネットワーク伝送です。フレームの先頭に、宛先アドレスがあり、この宛先アドレスを含んだ、フレーム全体に対して、チェックコードを付けている例です。受信側で、誤りを発見したときは、返事を出せません。
◆ (c) は、受信側から出した返事が、何らかの原因によって、送信側に届かない例です。
(d) は、送信側は、受信側からの返事は、受け取ったにですが、伝送誤りがあったために、返事の内容が分かりません。

8.3.(1-B) 各種の誤りに対応する手順

◆ 以上のように、いろいろな状況があります。どのような事態になったとしても、誤り制御が行われる必要があります。少なくとも、ハングアップだけは、避けなければなりません。
これらに、対応するための手順を示します(図.14)。

[図.14] 各種の誤りに対応できる手順の例

各種の誤りに対応できる手順の例

◆ この図は、状態遷移図と呼ばれる形式で書かれています。図の読み方については、コラム.2 を参照してください。
図において、正常終了は、図のプロトコルで、うまく処理できたときです。しかし、正常に処理できなかったときは、異常終了になります。
◆ この図では、正常終了、異常終了ともに、単に終了となっていますが、ユーザーに対して、終了を通知します。異常終了のときは、異常の原因を、ユーザーに通知します。
伝送自体は、終了しますから、伝送系としては、ハングアップしません。ただし、異常通知を受け取ったユーザーは、その対策を行う必要があります。

8.3.(1-C) 抜けと重複の発生

◆ 図.14 のような処理を行うことによって、バングアップは、防ぐことができますが、まだ、問題があります。2 重取り込みが発生する恐れがあるのです(図.15)。

[図.15] 2 重取り込みの発生

2 重取り込みの発生

◆ この原因は、返事には、誤り制御を行っていないからです。HDLC では、返事に対しても、誤り制御を行っています。したがって、このような現象は起こりません。しかし、誤り制御を行っていても、誤りも逃しは、あり得ます。したがって、絶対ではありませんが、誤りも逃しは、無視できる確率です。
◆ 送信側から送ったはずのデータが、受信側に届かず、しかもそれが検出されないと言う、抜けの現象も、起こり得ます。

8.3.(1-D) ブロック番号を付ける

◆ 抜けと重複とを防止する方法は、各種ありますが、その一つを紹介します。複数のブロックを連続して送る場合を考えます。このときは、送信するブロックに、送信の時間的順序にしたがって、ブロック番号を付けます(図.16)。

[図.16] ブロック番号による制御

ブロック番号による制御

◆ ブロックに、ブロック番号が付いていますから、受信側では、ブr-ック番号をチェックすることができます。この例では、伝送誤りのために、ブロック番号 i のブロックを 2 重送りしています。しかし、受信側では、2 重に送られてきたことを検出できますから、2 回目に送られてきたブロックを捨てて、ACK を返します。
◆ HDLC の順序番号は、この用途にも、利用されています。そして、返事にも誤り制御を行っていることと相まって、信頼性の高い伝送を行います。

8.3.(1-E) メッセージを識別する

◆ 以上によって、完璧のように、思われますが、これでも、まだ、不十分です。図.17 のようなことが起こります。

[図.17] ブロック番号だけでは駄目

ブロック番号だけでは駄目

◆ 図の(a)においては、(2)は、(1)の再送です。これに対して、図の(b)においては、(2)は、(1)と別のメッセージです。しかし、(a)と(b)とを区別することができません。この原因は、メッセージが識別されないことにあります。この対策は、メッセージを識別することです(図.18)。

[図.18] メッセージを識別する

メッセージを識別する

◆ 図で、ENQ はメッセージの開始を識別するコードです。その後に、ブロック番号をつけたデータブロックを送ります。ENQ には、ブロック番号が付いていませんが、2 重に送られてきても識別することができます。ENQ を使用することによって、メッセージとメッセージとを、区切りますから、図.17 の問題は起こりません。
このように、送信側と受信側とで、メッセージのやり取り開始を確認し合う作業のことを、接続処理 と呼んでいます。
◆ HDLC では、接続処理で、メッセージの先頭を識別するだけでなく、切断処理 によって、メッセージの終了も認識しますから、さらに信頼性の高いやり取りができます。
HDLC では、順序番号は、3 ビットです。したがって、ブロック数が多いときは、番号の繰り返しになります。同一メッセージ中に、同じ番号を繰り返すことは、許されませんから、これによって、メッセージ中のブロック数が制約されます。
◆ HDLC では、順序番号を活用して、ブロックごとに返事をしないで、まとめて返事をすることができます。これによって、効率の高い伝送が可能です(図.19)。

[図.19] まとめて返事する

まとめて返事する

◆ 以上、いろいろ眺めてきたように、HDLC は、優れたプロトコルであることが、分かります。

8.3.(1-F) ポーリング

◆ 以上、セレクションについて、見てきましたが、ポーリングについても、同様です。ポーリングにおける 2 重取り込み防止を、図.20 に示します。

[図.20] ポーリングの場合

ポーリングの場合
ポーリングの場合(a)
ポーリングの場合(b)

◆ 図で、RES は、メッセージの終わりを意味します。図.18 では、メッセージの開始を、ENQ で示しましたが、それに代わるものです。なお、ENQ も RES も、セレクションとポーリングの、どちらに使用しても差し支えありません。

[コラム 8.2] プロトコルの表現方法

★ 実際のプロトコルは、複雑です。正常時のプロトコルは、簡単であっても、 8.3.(1) に示したように、いろいろな異常が発生します。したがって、異常処理は、複雑になります。複雑なプロトコルを、分かりやすく表現することが、必要です。絶対的な、良い方法は存在しませんから、目的、用途によって使い分けます。以下に代表的な表現方法を示します。

★ (1) コマンド・シーケンス
コマンドシーケンス を、図.C31 に示します。

[図.C31] コマンドシーケンス

コマンド・シーケンス

★ この図の、縦と横を逆にしたものもあります。正常時のシーケンスを、分かりやすく示すのに向いています。しかし、異常時を含んで表現しようとすると、それぞれを、別の図に書かなければなりません。したがって、どのようなときはどうなるのかと言う、相互の関係が分かりません。

★ (2) フローチャート
フローチャート は、コンピュータ・ソフトウェアのフローチャートと同じです(図.c32)。

[図.C32] フローチャート

フローチャート

★ コンピュータのプログラムが、休み無く仕事を続けるのに対して、プロトコルは、その逆です。すなわち、プロトコルは、ある状態で、次のイベントを待ち、イベント発生によって、ある仕事をしたら、次の状態に入り、さらに次のイベント発生を待つという、シーケンスが多いのです。
★ このフローチャートは、この表現を、ごまかして書いてあります。フローチャートは、正確にプロトコルを表現するのには、向きません。

★ (3) 状態遷移図(その1)
図.14状態遷移図 で書かれています。この図.14 を例に、説明します。この図は、送信側のプロトコルを表わしています。この送信を受ける受信側が動作している筈ですが、示されていません。
★ 状態遷移図においては、○ は、状態を表わします。そして、線が、イベントを表わします。イベントとは、所定の仕事を実行することです。状態とは、何も仕事をしないで、イベントの発生を待っている状態のことです。
★ 状態遷移図では、イベント待ちの状態で、次のイベント発生を待ちます。イベントを実行すると、次のイベント待ちの状態に入ります。これを、逐次繰り返すことによって、シーケンスが進みます。
★ 逆にいうと、このように、進行する仕事を表現するのに、適しています。
データ伝送は、状態遷移図で表わすのに、適した仕事です。
★ 図.14 の説明に入ります。
アイドルは、何もしていない状態です。すなわち、まだ伝送を開始していない状態です。
開始は、ユーザーによって、送信要求が出されたので、送信を開始することを意味します。
★ 次の○は、送信待ちの状態です。すなわち、送信のための準備を完了し、送信の実行を待っている状態です。
★ 次のイベントは、1 ブロックのデータ送信です。
送信後、返事待ちの状態に入ります。返事待ちの状態では、次に発生するイベントは複数あり、そのうち、どれか 1 つのイベントが実行に入ります。
★ ACK を受信したときは、正常終了に入ります。その他のイベントのときは、それぞれの、異常処理を行います。そして、このシーケンスの範囲内の異常処理では、処理不可能を判定されたとき、異常終了となります。
★ この状態遷移図では、正常終了と異常終了の具体的な内容は、記載されていませんが、それぞれ、具体的な、処理内容が、あります。
★ コンピュータ プログラムを表現する、フローチャートには、概略から、詳細に至るまでの、いろいろな種類があります。状態遷移図も同様で、目的用途によって、各種使い分けます。

★ (4) 状態遷移図(その2)
状態遷移図は、データ伝送のプロトコルを表現するのに、適した手法です。しかし、一般的な、状態遷移図では、必ずしも、十分では、ありません。図.14 は、送信側のプロトコルです。これに対応した、受信側のプロトコルが存在します。
★ 送信側と、受信側とを、ペアにして、相互の関連を示すようにすれば、状態遷移図 は、一層、明確であり、分かりやすくなります(図.c33)。

[図.C33] 送受信間の関連を示した状態遷移図

送受信間の関連を示した状態遷移図

★ (5) 状態遷移表
状態遷移表 は、状態遷移図と同様な内容を、表現しますが、図ではなく、表の形で表わしたものです(表.C31)。

[表3.1] 状態遷移表

状態遷移表

★ 横の行が状態を、縦の列がイベントを表わします。交点は、ある状態にあるときに、あるイベントが発生したことを表わします。交点を、上下に分けて、上側にイベントの内容を、下側にそのイベントが終了したときに移行する状態を記入します。
★ 状態遷移表は、見易さの点では、状態遷移図に比べて、大きく劣ります。しかし、状態遷移表は、状態遷移図には無い、大きな特徴があります。それは、ロジックの抜けをチェックできることです。マトリックスになっていますから、全ての組み合わせが、表示されます。無視する、すなわち何もしない、または何も起こらない欄には、「-」を記入します。
★ したがって、空欄があれば、それは、まだチェックしていないことを意味します。
状態遷移表も、状態遷移図と同様に、目的用途によって、精粗、各種のものを作ることができます。

★ (6) タイムチャート
プロトコルにおいても、必要に応じて、タイムチャート を使用します。



目次に戻る   前に戻る   次に進む