3. Protocol Function

Protocol?

2주차 내용(구조)이 실루엣이라면 실제 생김새는 알지 못했다
실제 생김새 == protol fucntion

Protocol Function

여러 protocol에서 두루 사용되는 특정 procedure / mechanism
- 여기저기서 공통적으로 등장하는 주/조연 같은 존재

예시
error control : PDU가 정상적으로 전달되지 않는 상황에서 protocol entity의 동작
flow control : enitty간 data를 주고받는 속도 및 형태를 조절
fragmentation : 위에서 받은 SDU가 너무 큰 경우 잘라서 PDU로 나눠서 보내는 것

Error Control

Connection - Oriented communications protocol의 핵심 역활중 하나

• 상대방에게 확실하게 PDU를 전달하는 것 (Correctly / Reilably)
  

  

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

Detect
송신측에서 error한 상황을 인지

React
error 상황에서 송신 측 동작

How Detact : Confimation

한쪽 entity에서 PDU를 보내면 receiver entity에 그 PDU가 도달했는지 여부를 확인할 수 있어야한다
→ PDU와 ACK를 사용

ExplicitAcknoweldgement:receiver entity가 PDU를 온전히 받았는지 여부를 다시 보내준다

Explicit ACK
명시적으로 ACK를 주는 것으로 두가지 방법이 존재

Positive ACK

• 정상 수신된 PDU를 알려주는 방식
• 송신자는 PDU에 번호를 매겨서 보내게 된다. 그러면 수신자는 지금까지 수신한 PDU의 다음 sequence number를 ACK로 알려준다
• network load를 줄이기 위해cumulative ACK가 주로 사용된다
  매번 PDU를 받을 때마다 ACK를 보내게되면 네트워크에 부하가 심하므로, 1~6번까지 보내면 그제서야 7번 ACK를 보내는 등 어느정도 텀을 두고 보내는 방식이다
  → 따라서 보내는 쪽 패킷 타이머도 그만큼 적게 사용하게 된다

Negative ACK

• 미 수신된 PDU를 알려주는 방식
• faulty or outstanding sequence
• PDU를 받고나서 못받은 PDU를 알려주는 방식으로 active error control이라고 한다
• reaction == 재전송, 하지만 재전송이 계속 실패하면 연결을 끊는 경우도 있다

Piggybacking

• 한쪽에서만 데이터를 보내는 것이 아니라 양방향 통신일 때, ACK 전송이 아니라, PDU에 실어서 ACK 정보를 같이 전송한다
• 마찬가지로 explicit한 방식이다, 명시적 전달

Timer

ACK에 문제가 생기는 경우에는?
송신한 PDU가 잘 가서 수신측에서 ACK를 보냈는데 이 ACK에 문제가 생겨서 못가게 될수도 있다. 그러면 송신측은 ACK를 계속 기다리고, 수신측은 송신할 데이터를 기다리는 서로 아무것도 안하는DeadLock상황이 발생할 수 있다

따라서 송신측에서 PDU를 보낼때 Timer도 같이 재서 ACK가 제시간에 오지 않는다면 Error로 간주하고 Detect하고 필요한 Action을 취하게 된다

• timer에 의해 ACK 정상 도달을 monitoring
• 보통 PDU를 보낼 때 timer를 시작한다

Timer 가동시

• timer interval은 ACK가 도달할 예상 시간을 감안하여 정의한다
• ACK이 제시간안에 도달하지 않으면 timer expiry가 되고
  time-out이 되면 기정의된 액션을 수행하여 deadlock에 빠지지 않도록 해준다
• 잘 도달하면 timer를 reset해준다

Activity Timer
보통 프로토콜에서 timer는 peer entity에 대한 monitoring용도로 활용한다

• peer entity가 모종의 이유에 의해서 communication을 멈추었을 때 DeadLock이 발생할 수 있으므로 timer를 가동 →peer entity의 inactivity를 감지한다
• 항상 peer partner의 reaction 감지 시 timer를 멈춘다
• Ack가 오거나, PDU가 오거나 등등 정상 작동을 하고있음을 알게되면
• 보통 reaction 시간보다 충분히 크게 timer interval을 잡는다

Timer의 중요성
Protocol specification에 있어서 핵심 내용 중 하나가 Timer를 정의하는 것이다

• Timer name, interval, start, stop, expiry

Timer interval을 적절한 길이로 설정해야한다

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

PDU Loss and Duplication

Error Control이 실제로 발생하는 대표적인 경우로 Data Packet을 계속해서 보내는 동안에 발생

Loss 판단

• PDU가 time-out interval 이후에도 도달하지 않은 경우
• 더 큰 sequence number PDU를 수신한 경우
• 중복된 ACK sequence를 수신하거나, ACK가 빠진 sequence를 알려줌으로서 pdu loss를 파악하게 된다

Duplication

• Timer를 초과해서 Ack가 온 경우 중복으로 Data를 보내게 된다
  (잘 받았는데도 ACK가 너무 늦게 와서 time-out처리후 다시 보냄)PDU의 Sequence Number를 확인해서 감지할수 있다

• 

• (혹은 interval이 너무 짧아서)
• ACK 자체가 손실되고 TX측에서 time-out에 의해 PDU가 재전송된 경우
  (즉, 제대로 받았는데 ACK 손실로인해 타임아웃되서 또받음)
• 수신측에서는 PDU의 Sequence number를 확인하고 Discard할 수 있다

---

ARQ - Automatic Repeat reQuest

ARQ = Acknoweldgement + Timer +Reactions

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

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

• Stop and Wait
• Go Back N
• Selective Repeat

Stop and Wait

• 위에서 설명한 방식
• 가장 기본적이면서 느린 방식
• 말그대로 PDU를 보내고 Timer를 재면서 ACK를 기다린다. 이후 맞는 상황에 대해 맞춰서 진행

Go Back N

• N번으로 되돌아가는 방식
• N번째 Unconfirmed PDU로 되돌아가서 거기서부터 재전송한다
• 만약 N번째 PDU에서 Error가 발생했고, N + 1, N + 2 , .. 의 N번 이후의 PDU에 대해선 에러가 없었어도 N번 이후 보냈던 PDU를 포함해서 다시 N번부터 재전송하게 된다
• TX Entity는 ACK를 받기 전까지 보낸 PDU를 버퍼에 모두 저장하고 있어야하지만, RX는 따로 버퍼에 대한 요구사항이 없다
  반면, RX Entity는 Error가 생긴 N번 이후의 PDU를 그냥 버리기만 하고 다시 받으면 되는 부분이므로 버퍼링에 대한 요구상항은 적다
  → 따라서 RX Entity는 따로 버퍼링에 대한 요구사항이 없다, 단지 다음 시퀀스 넘버만 알고있다가 잘못오면 그거 달라고 요구ack를 보내면서 다 폐기하면 된다
• 즉, 수신되는 sequence number를 확인하다가 n번이 와야되는데 n+1이 오면 n번부터 문제가 있다 판단하고, 그 이후 수신되는 모든 패킷은 폐기한다. 이때, 수신측은 Ack로 n번을 받아야한다고 알려준다
• → TX만 버퍼링에 대한 요구사항이 있다

Selective Repeat

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

Go Back N vs. Selective Repeat

• Go Back N은 TX Entity에 Buffer만 필요
• SR은 TX, RX entity 둘 다에 대해 buffer가 필요
• Go Back N은 재전송 수신까지 시간이 걸리지만 (여러개 다시 다보냄)
• Selective Repeat은 재전송 수신이 상대적으로 시간이 덜걸린다 (다시 보낼거만 찝어서 보냄)

Forward Error Control (FEC)

Coding theory: 자가 치유 능력
→ 일부 bit 오류에 대해 정정이 가능하도록 data bit를 뻥튀기 해주는 이론
(3bit 보낼거를 10bit로 보내고 수신자는 해당 비트를 다시 3bit로 만들면서 오류들을 수정하게 된다)
(추가적인 비트에 대해서redundant Data라 한다)

FEC

• coding theory 기반으로 PDU의 일부 오류를 정정한다
• redundant Data 추가
• 보통 계산량이 많다
• real-time traffic에 유리하다 (Voice, Video 스트리밍)재전송을 할 여유가 없으므로 받는 즉시 정정하는 것이 바람직하다 (재전송 자체가 의미없다)
• 시간이 지나면 수신 PDU가 의미 없어지는 서비스들
• 오늘날 모든 무선 통신 시스템에서 활용bit error가 잦게 발생하는 곳에서 사용한다
• 계산 능력의 향상, 무선 자원에 대한 효율적 사용

Cyclic Redundant Check (CRC)

FEC가 모든 Bit 오류를 다 고쳐주지는 못한다

• bit오류가 너무 많거나, 연속적인 bit오류는 완벽하게 정정하지 못한다

CRC의 활용 :Error Detect

• 아무리 고치려 시도해도 오류가 여전히 있다면 버려야한다
• "오류가 여전히 있음"을 감지하기 위해서 CRC를 활용한다
• 즉, 고치는 목적이 아니라오류가 있음을 인지하는데 목적이 있다

CRC의 원리

• 부가정보를 붙이고 수신측에서 부가 정보를 가지고 깨졌는지 아닌지를 확인하게 된다

방식

원 데이터에 Parity bit들을 꼬리에 추가한다

• LTE의 경우 16 / 24bit 추가
• 원 데이터 bit들을 입력해서 parity bit를 만든다 (원 데이터와 연관이 있는 비트들이다)

주로 여기에 FEC를 조합해서 쓰인다

• parity bit가 원 데이터에 붙어있고 + Redundant Data도 붙어있는 상황

수신쪽에서 데이터를 받아서 FEC 처리를 통해 최대한 고친다 → 이러면 고친 Data + CRC (parity bit) 구조가 된다
그럼, CRC를 떼어내고 받은(고친) Data를 가지고 RX에서 CRC를 생성해본다
→ 받은 CRC vs. 만들어본 CRC 를 통해 다르다면 error bit가 존재한다고 Error Detect를 하게 된다
(100% data의 오류여부를 알수 있게된다)

CRC 생성 방식

input bit에 대해서 원하는 길이 L 만큼 Data의 비트를 접근해서 CRC Paritiy bit로 추가해준다