Protocol Functions

Course Outline

• 다양한 protocol function들에 대해 이해
• Error control
• ARQ

---

Protocol

protocol stack 부분에서 model 과점에서 protocol개념에 대해 접근

2주차 내용(구조)가 실루엣이라면 실제 생김새는 실감이 안난다.

실제 생김새는 protocol function

---

Protocol Functions

여러 protocol에서 두루 사용되는 특정 procedure / mechanism

여기저기 공통적으로 등장하는 주연/조연 같은 존재

 

ex)

• error control: PUD가 정상적으로 전달되지 않은 상황에서의 protocol entity 동작
• fragmentation, flow control: entity간 data를 서로 주고 받는 속도 및 형태 조절

Error Control

Connection-oriented communicatoins protocol에게 주어지는 중요한 역할 중 하나는 상대방에게 확실하게 PDU 전달하는 것 (correctly / reliably)

Protocol에서 "확실한 전달"을 하려면 두가지 동작에 대한 정의 필요

1. Detect : 송신 측에서 error한 상황 인지
2. react: error 상황에서 송신 측 동작

---

How Detect: Confirmation

한 쪽 entity에서 PDU를 보내면 송신측 entity에 그 PDU가 도달했는지 여부를 확인할 수 있어야함

 

Explicit acknowledgement (Explicit ACK)

TX가 RX에서 잘 받았나 확인 (ACK)

• 수신측 entity가 PDU를 온전히 받았는지 여부를 다시 보내줌
• 명시적으로 받았는지 확인을 하는 것
• error control을 위해서 필요한 동작이다.
• 가장 단순하고도 확실하게 confirmation하는 방법
• 반대로 implicit는 내재적인 확인으로 아무런 메시지를 받지 않으면 잘 받았다고 하는 것
• reaction == 재전송, 대개 못받은 PDU를 재전송하거나 연결을 끊음

 

Piggybacking

• explicit한 ACK 메시지 전송이 아닌, PDU에 실어서 같이 ACK 정보 전송
• A가 B에게 메시지를 보내고 B가 그것을 수신한 다음, B는 메시지를 잘 수신했음을 A에게 알려주는데, 이때 B는 A에게 즉시 ACK를 보내느 것이 아니라 약간 기다린 다음에 (응답 데이터가 준비될때까지) ACK와 함께 응답 메시지를 보낸다
• 한쪽에서만 데이터를 보내는 것이 아니라 양방향 통신일 때 , ack 전송이 아니라 pdu에 실어서 ack벙보를 같이 전송
• 전송이 한번 일어나게 된다. (Explicit ACK인 경우 2번의 전송이 일어남)

 

Explicit ACK는 기본적으로 두가지 세부 방법 존재

 

1. Positive ACK: 정상 수신된 PDU를 알려주는 방식 

• 지금까지 수신한 PDU의 다음 sequence number를 알려줌
• network load 를 줄이기 위해 cumulative ACK가 주로 사용됨. → 어느 정도 텀을 두고 보내는 방식 (아래 사진 참고)

PDU를 보낼때 마다 ACK를 보내면 네트워크에 부하가 심해서, 1~6번까지 보내면 그제서야 7번 ACK 를 보낸다.

2. Negative ACK: 미수신 PDU를 알려주는 방식

• fault or outstanding sequence
• active error control: pdu를 받고나서 못받은 pdu를 알려주는 방식이다.

---

Timer

Acknowledgement(ACK) 전송 역시 손실될 수 있음 → 송신 측에서 ACK를 계속 기다리게 되는 상황 발생

• TX entity입장에서는 PDU를 보낸뒤 ACK를 무기한 기다릴 수 없다
• Deadlock 상황이 발생한다.

따라서 ACK에 대한 기한을 두고 기한을 넘기면 action을 취할 필요가 있음

• timer에 의해 ACK 도달을 모니터링해서 timer에 설정된 기한을 넘기면 특정 조치 취하기

보통 PDU를 보낼때 timer 시작

 

timer 가동시

• timer interval은 ACK가 도달할 예상 시간을 감안하여 정의 → 이미 표준화 되어 있다. timer의 길이는 적절해야하고 적절한 정도는 protocol마다 timer의 길이를 정해 놓음
• ACK이 도달하지 않으면 타이머 만료가 되고 time-out이 되면 기정의된 plan B를 수행하여 deadlock에 빠지지 않도록 한다.
• ACK이 도달하면 timer를 reset한다.

---

Activity Timer

PDU 수신확인하고 ACK보내는 신호 기다리는 timer보다 범위가 넓은 timer이다.

 

보통 protocol에서 timer는 peer entity에 대한 monitoring 용도로 활용 → peer entity의 inactivity 감지

• peer entity가 무슨 이유에 의해서 communicatoin을 멈췄을 때 deadlock이 발생할 수 있으므로, 이를 방시하기 위해 timer 가동

항상 peer partner의 reaction 감지 시 timer 멈춘다. (PDU 수신하거나 정상 작동 중이면..)

보통 reaction 시간 보다 충분히 크게 timer interval을 잡는다.

---

Timer 의 중요성

Protocol specification(정의)에 있어서 핵심 내용중 하나가 timer를 정의하는 것이다.

• timer name / interval / start / stop / expiry(만료) → 이런 시간이 이미 설계가 되어 있다

Time interval은 적당한 길이로 설정되어야한다.

• 너무 짧으면 time-out이 빈번하게 일어나서 불필요한 reaction 발생
• 너무 길면 reaction이 너무 늦어지면서 불필요한 deadlock 구간 발생

---

PDU Loss and Duplication

Data transmission동안 PDU가 손실되거나 중복 수신이 될 수 있음

• PDU손실이나 중복 수신을 entity가 PDU sequence number에 의해 감지할 수 있다

PDU 손실의 경우

 

RX가 PUD loss를 파악하는 경우

1. RX에게 PDU가 time-out interval이후에도 도달하지 않은 경우
2. RX가 갑자기 더 큰 sequence number PDU 수신 시

TX가 PDU loss를 파악하는 경우

1. ACK를 통해 빠진 sequence 인식 - 보낸  pdu 개수보다 받은 ack 개수가 적다
2. 중복된 ACK sequence 수신 - pdu1을 보내고 ack(2)로 2번 pdu를 보내달라고 TX에 전달한 후에 pdu 2가 loss하면 Tx는 다시 ack(2)를 중복 수신하게 된다.

PDU duplication의 경우 (ACK 손실)

 

• ACK가 손실되고 TX 측에서 time-out에 의해 PDU가 재전송 된 경우
• 수신 측에서는 sequence number를 확인하고 discard(무시)할 수 있음

DT1과 DT2를 보냈는데 time-out 이후에 ACK를 보내서 송신 측이 data를 못받을 줄 알고 다시 DT1과 DT2를 보내는 중복 수신

sequence number확인하고 중복되면 무시

---

Automatic Repeat reQuset (중요)

ARQ: Acknowledgement + timer + reactions (에러 상황이면 reaction)

ACK + timer (tx 측에서 timer가 만료 되었고 ACK loss) = PDU를 못받았다 이면 reaction해라

 

• 자동반복 요청
• 신뢰성 있는 PDU 전송을 위한 가장 보편적인 protocol function
• TX/RX가 confirmation (ACK)를 받거나 time-out까지 기다리는 동안 하는 일련의 동작 포함

재전송 방법에 따라 여러가지 방식 존재

 

• stop and wait: 위에서 설명한 방식으로 하나 PDU보내면 해당 PDU의 ACK기다리는 방식 → 비효율적이다
• go back N
• selective repeat

Go back N

• N으로 돌아가기
• N번째 unconfirmed PDU로 돌아가서 거기서부터 재전송함
• RX entity는 N번째 PDU가 문제가 생기면 이후 PDU는 모두 버림
• time-out의 경우 N번째 PDU부터 재전송
• TX entity는 ACK를 받기 전까지 보낸 PDU를 버퍼에 모두 저장하고 있어야하지만, RX는 따로 버퍼에 대한 요구사항이 없음. 반면, RX entity는 Erorr 가 생긴 n번 이후의 PDU를 그냥 버리기만 하고 다시 받으면 되는 부분이므로 버퍼링에 대한 요구사항은 적다.

→ 따라서 RX entity는 따로 버퍼링에 대한 요구사항이 없다. 단지 다음 시퀀스 넘버만 알고 있다가 잘못오면 빠트린 시퀀스 넘버 PDU달라고 요구하는 ACK를 보내면서 이후 PDU를 폐기하면 된다. 즉 수신되는 시퀀스 넘버를 확인하다가 n 번이 와야하는데 n+1이 오면 n번부터 문제 있다고 판단하고, 그 이후 수신되는 패식은 폐기. 이때 ,수신측은 ACK로 n번을 받아야한다고 알려준다. → TX만 버퍼링에 대한 요구사항이 있다.

 

Selective repeat

• 손실된 PDU에 대해서만 골라서 재전송
• RX entity는 제대로 받은 PDU을 저장 → transmission order대로 다 받을 때까지 저장
• cumulative ACK를 통해 제대로 전달된 PDU를 TX entity에서 확인
• RX entity는 n번을 못받고 n+1, n+2는 받았다면 제대로 받은 PDU를 저장하고 있는다 → TX와 RX모두 버퍼에 대한 요구사항이 있다.
• TX는 재전송을 위해 당연히 버퍼를 갖고 있고 (손실된 PDU) + RX에서도 재전송되는 패킷을 받을 때까지 정상 수신된 패킷을 버퍼에 갖고 있어야 한다.
• 송신측은 ACK로 제대로 받았다는 내용만 보게 되고, n번 패킷이 오다가 loss가 나면 송신 측 n번 패킷에서 time 만료가 나면 해당 n번 패킷만 재전송하게 된다.
• 제대로 전달받은 PDU를 보관해얗나는 RX측 버퍼링 요구사항과 TX측에서 보내는 패킷마다 timer를 설정해서 만료를 체크하고 다시 보내야하는 부담감이 있다. (모든 패킷에 대한 timer의 부담으로 실제 실무에서는 go back n을 사용)

Go back N vs. selective repeat

• selective repeat는 RX entity 측에 buffer 필요 → receiver 쪽이 부담
• Go back N은 TX entity측에 buffer 필요
• Go back N은 재전송 수신까지 시간이 걸리나 selective repeat은 재전송 수신이 상대적으로 시간이 덜 걸림 (N번 패킷이 에러가 나면 그것만 다시 보내면 되니까)

---

Forward Error Control (FEC)

Coding theory

• 자가 치유 능력
• 일부 bit 오류에 대해 정정이 가능하도록 data bit를 뻥튀기 해주는 이론 → bit 뻥튀기 해주면 컴퓨터가 어느정도 자가치유 할 수 있다.

FEC

• coding theory 기반으로 PDU의 일부를 정정
• redundant data 추가 → 뻥튀기되는 비트에서 추가적인 비트를 말함
• 보통 계산량이 많음
• real-time traffic에 유리 (voice, video)
  • 시간이 지나면 수신 PDU가 의미가 없어지는 서비스
  • 재전송 하 여유가 없으므로 받는 즉시 정정하는 것이 바람직함.
• 오늘날 모든 무선 통신 시스템에서 활용
  • 계산 능력이 향상 됐고 무선 자원 에 대해 효율적을 사용 가능

---

Cyclic Redundant Check (CRC) 시험출제

FEC가 모든 bit 오류를 다 고쳐주진 못함 → bit 오류가 많거나, 연속적인 bit 오류는 완벽하게 정정하지 못함

CRC 활용

• 오류 감지 (Error detection)
• 아무리 고치려 시도해도 오류가 여전히 있으면 버려야함
• "오류가 여전히 있음" 을 감지하기 위해서 CRC활용

CRC 원리

• 부가적인 정보를 붙이고, 수신 측에서 부가 정보를 활용해서 깨졌는지 여부 확인

CRC 방식

• 원 데이터에 parity bit 들을 꼬리에 추가
  • LTE의 경우 16 / 24 bit 추가
  • 원 데이터 bit들을 입력해서 parity bit 만든다.
• 주로 FEC와 조합하여 쓰임
  • 수신쪽에서 데이터를 받아서 FEC 처리를 통해 최대한 고친다. → 이러면 고친 DATA + CRC(parity bit) 구조가 된다. 그럼, CRC를 떼어내고 받은(고친) 데이터를 가지고 RX에서 CRC를 생성한다.
  • 수신 CRC vs. 다시 만들어본 CRC가 같은지 확인
    • 같으면 error bit가 없음.
    • 같지 않으면 error bit 존재
  • channel coding이 원데이터를 완벽하게 복원했는지 확인하는 용도로 활용

CRC 계산 방법

https://depotceffio.tistory.com/entry/CRC%EC%9D%98-%EB%9C%BB%EA%B3%BC-%EA%B3%84%EC%82%B0-%EB%B0%A9%EB%B2%95