การแก้ไขข้อผิดพลาดโดยการส่งข้อมูลซ้ำ
(Error Correction via Retransmission)

             เมื่อข้อผิดพลาดได้มีการตรวจพบ จะต้องดำเนินการแก้ไข ซึ่งวิธีง่ายและได้ผล รวมถึงมีต้นทุนที่ต่ำ ก็คือการแก้ไขข้อผิดพลาดด้วยการส่งข้อมูลซ้ำ การส่งข้อมูลซ้ำจะเกิดขึ้นต่อเมื่อฝั่งรับได้ตรวจจับพบข้อผิดพลาดขึ้น จึงตอบรับกลับไปยังฝั่งส่งด้วยรหัส NAK เพื่อให้ฝั่งส่งจัดส่งเฟรมใหม่ไปให้รอบใหม่ เราเรียกกระบวนการนี้ว่า การร้องขอเพื่อส่งข้อมูลซ้ำอัตโนมัติ (Automatic Repeat Request : ARG) ซึ่งกระบวนการดังกล่าวจะช่วยสร้างความน่าเชื่อถือในข้อมูลบนชั้นสื่อสารดาต้าลิงค์ยิ่งขึ้น สำหรับรูปแบบของ ARQ โดยทั่วไปแล้วจะมีอยู่สองวิธีหลักๆ ด้วยกันคือ Stop-and-Wait ARQ และ Continuous ARQ

Stop-and-Wait ARQ

            เป็นเทคนิคควบคุมข้อผิดพลาดที่จัดอยู่ในโปรโตคอลประเภท Stop-and-Wait โดยโปรโตคอลดังกล่าวจะมีกระบวนการทำงานแบบง่ายๆ พิจารณาจากรูปที่ 4.1 ที่ฝั่งส่ง (สถานี A) ได้ส่งเฟรมข้อมูลไปยังฝั่งรับ (สถานี B) จากนั้นฝั่งส่งจะรอการตอบรับจากฝั่งรับ ซึ่งหากเฟรมข้อมูลที่ส่งก็จะรอการตอบรับจากฝั่งรับ ซึ่งหากเฟรมข้อมูลที่ส่งไปปราศจากข้อผิดพลาด ฝั่งรับก็จะแจ้งข่าวสารกลับมายังฝั่งส่งด้วยรหัส ACK แต่ถ้าเฟรมข้อมูลที่ส่งไปเกิดข้อผิดพลาดขึ้น ก็จะแจ้งรหัส NAK หรือ REJ (Reject) กลับไป ทั้งนี้หากฝั่งรับดีรับแจ้งข่าวสารเป็นรหัส ACK ก็จะส่งเฟรมข้อมูลในลำดับถัดไปในขณะที่เป็นรหัส NAK หรือ REJ ก็จะส่งเฟรมที่เสียหายในขณะนั้นไปรอบใหม่

Continuous ARQ
            ข้อดีของ Stop-and-wait ARQ คือมีกระบวนการทำงานแบบง่ายๆ ไม่ซับซ้อน ส่วนข้อเสียก็คือจะทำให้เกิดการหน่วงเวลาค่อนข้างสูง เนื่องจากฝั่งส่งจะต้องได้รับการตอบรับจากฝั่งรับทุกๆ ครั้งที่การส่งเฟรมแต่ละเฟรม ดังนั้นจึงวิธีแบบ Continuous ARQ ขึ้นมา ซึ่งวิธีนี้จัดอยู่ในโปรโตคอลประเภท Sliding Window ที่ฝั่งส่งสามารถส่งข้อมูลไปยังรับฝั่งรับได้อย่างต่อเนื่อง แต่ละเฟรมที่ส่งไปไม่ต้องรอการตอบรับจากฝั่งรับโดยทันทีอย่างวิธี Stop-and-Wait จึงทำให้วิธีนี้มีประสิทธิภาพที่ดีกว่า อย่างไรก็ตาม Continuous ARQ ยังสามารถแบ่งออกเป็น 2 วิธีย่อยด้วยกันคือ

            Go-Back-N ARQ
            วิธีนี้ฝั่งส่งสามารถส่งเฟรมข้อมูลไปยังฝั่งรับได้อย่างต่อเนื่อง แต่ถ้าฝั่งรับได้ตอบรับข้อผิดพลาดกลับมายังฝั่งส่ง ฝั่งส่งจะต้องย้อนกลับไปยังตำแหน่งเฟรมที่ผิดพลาด และเริ่มต้นส่งใหม่ทั้งหมดอีกครั้ง ถึงแม้ว่าจะมีเฟรมที่ส่งล่วงหน้าไปแล้วก็ตาม การทำงานลักษณะนี้จึงเป็นที่มาของชื่อ Go-Back-N นั่นเอง ตังอย่างเช่น ฝั่งส่งได้ส่งเฟรม 4, 5, 6, 7 และ 0 ไปยังฝั่งรับ และฝั่งรับได้แจ้งกลับมาว่าเฟรม 5 ชำรุดเสียหาย ดังนั้นฝั่งส่งจะต้องย้อนกลับไปยังตำแหน่งเฟรมที่เสียหายคือเฟรมที่ 5 และทำการเริ่มต้นส่งรอบใหม่ทั้งหมดอีกครั้งคือ 5, 6, 7 และ 0 ถึงแม้ว่าเฟรม 6, 7 และ 0 ที่ส่งไปก่อนหน้าจะไม่พบข้อผิดพลาดใดๆ ก็ตาม ซึ่งเป็นไปตามตัวอย่างรูปที่ 4.2

            Selective-Reject ARQ
            เป็นวิธีที่คล้ายกันแบบ Go-Bank-N ARQ แต่จะมีประสิทธิภาพเหนือกว่า กล่าวคือ ฝั่งส่งจะส่งเฉพาะเฟรมที่ผิดพลาดกลับไปเท่านั้น ส่วนเฟรมที่จะส่งไปลำดับถัดไป สามารถเริ่มต้นถัดจากเฟรมที่ส่งล้วงหน้าไปได้ทันที ตัวอย่างกรณีเดียวกันกับ Go-Back-N ARQ ข้างต้น ฝั่งส่งจะส่งเพียงเฟรมที่ชำรุดเสียหายกลับไปใหม่เท่านั้น นั้นก็คือเฟรม 5 และเฟรมถัดไปที่ส่งก็คือเฟรมหมายเลข 1 เป็นต้นไป
            เมื่อพิจารณา จะพบว่า Go-Back-N ARQ และ Selective-Reject ARQ มีความคล้ายคลึงกันมากและเกิดเพื่อให้เกิดความเข้าใจในรายละเอียดยิ่งขึ้น ดังนั้นเนื้อหาต่อไปจากนี้ จะแสดงถึงความเป็นไปได้ในรูปแบบต่างๆที่ก่อให้เกิดข้อผิดพลาด โดยจะมีรูปประกอบพร้อมอธิบายตามกรณีต่างๆดังนี้
            จากเหตุการณ์ดังกล่าว ? ซึ่งจะพบว่าฝั่งส่ง (สถานี A) ได้ส่งเฟรม 0, 1, 2 และ 3 ไปยังฝั่งรับ (สถานี B) และฝั่งรับก็ได้ตอบรับ RR4 กลับมา จากนั้นฝั่งส่งก็ได้ส่งเฟรมข้อมูลต่อเนื่องไปอีกคือ เฟรมหมายเลข 4, 5, 6, 7 และ 0 ไปขณะที่ฝั่งรับได้ตอบรับรหัส RR4 กลับมาก่อน (ได้รับเฟรมหมายเลข 4, 5 และ 6 แล้ว ต้องการเฟรมถัดไป) ต่อมาก็เกิด Timeout แต่หลังจาก Timeout แล้ว ฝั่งส่งยังแปลกใจว่า เกิดอะไรขึ้นเกี่ยวกับการตอบรับข้อมูล 2 เฟรมที่ยังคั่งค้างอยู่ (เฟรม 7 และ 0) ดังนั้นจึงดำเนินการส่งรหัส RR4 (Receive Ready) ไปยังฝั่งรับเพื่อสอบถามว่าบางเฟรมที่ได้รับไปเกิดสูญหายหรือได้รับล่าช้าหรือเปล่า และต้องการเฟรมถัดไปหมายเลขใด ฝั่งรับก็ตอบกลับมาว่าได้รับเฟรมที่คั่งค้างเรียบร้อยแล้ว และต้องการข้อมูลถัดไปคือ เฟรมหมายเลข 1
            จะเกิดอะไรขึ้นเมื่อเฟรมข้อมูลสูญหาย? จากรูปจะพบว่าฝั่งส่งได้รับข้อมูลไป 5 เฟรมด้วยกัน และมี 2 เฟรมสุดท้ายสูญหายไปในระหว่างทาง ฝั่งรับจึงตอบรับรหัส RR3 กลับมาหลังจาก Timeout ฝั่งส่งก็ได้ส่งรหัส RR3 ไปยังฝั่งรับเกี่ยวกับเฟรมที่ยังคงคั่งค้าง ฝั่งรับก็ตอบกลับมาว่าต้องการเฟรมหมายเลข 3 (RR3) ฝั่งส่งจึงได้ส่งเฟรมที่สูญหายไปคือ 3 และ 4 ไปให้อีกรอบหนึ่ง
            จากตัวอย่างข้างต้น เฟรมข้อมูลส่วนปลายได้เกิดการสูญหาย แต่ถ้าเฟรมข้อมูลที่สูญหายนั้นอยู่กึ่งกลางของเฟรมทั้งหมดที่ส่งไป จะเกิดอะไรขึ้นต่อไปนี้ จะพบว่าฝั่งส่งได้ส่งเฟรม 0, 1, 2 และ 3 ไป จากนั้นฝั่งรับก็ตอบรับกลับมาด้วย RR4 ฝั่งส่งจึงส่งเฟรม 4, 5, 6, 7 และ 0 ไปอย่างรวดเร็วแต่เฟรมหมายเลข 5 เกิดสูญหายไประหว่างทาง ครั้นเมื่อฝั่งรับได้รับเฟรม และตรวจสอบพบว่ามีเฟรมหมายเลข 6 แต่ไม่พบเฟรมหมายเลข 5 ดังนั้นจึงส่งรหัส REJ5 กลับไป และเมื่อฝั่งส่งได้รับรหัส Reject กลับมา พบว่ามี ข้อผิดพลาดที่เฟรมหมายเลข 5 ดังนั้นจึงย้อนกลับไปยังตำแหน่งเฟรมหมายเลข 5 และเริ่มต้นส่งข้อมูลรอบใหม่ทั้งหมดคือเฟรมหมายเลข 5, 6, 7 และ 0 ซึ่งกระบวนการดังกล่าว เป็นวิธี Go-Back-N ARQ นั่นเอง ในขณะที่วิธี Selective-Reject ARQ ก็จะส่งเฉพาะเฟรมที่หายไปรอบใหม่เท่านั้น คือเฟรมหมายเลข 5 จากนั้นเฟรมถัดไปก็จะเป็นเฟรมที่อยู่ถัดจากเฟรมที่ส่งล่วงหน้าไป