4. Protocol Function 2

Synchronization

• TX와 RX간 데이터를 보내고 받는 상황에 대해 서로 consensus가 이뤄지도록 하는 것
• 쉬고있는(idle) RX와 TX를 메시지나 데이터를 보내고 받을수 있는 상태(state)를 맞추는 event 동작
• connection setup / release 에서 주로 활용
• Synchronization이 이뤄지지 않은 상태에서 연결 요청만 하고 연결이 됐다고 생각하고 데이타를 보내는 경우 데이타 손실(PDU loss)가 발생한다

RX-TX peer entity간 connection (호 연결)

data를 보내기 전 connection이 맺어졌는지 여부 확인
handshaking방식을 통해 이뤄진다 (2-way, 3-way 2가지 방식 존재)
2-way
TX에서 (Service Primitive을 이용해서) CR를 보내면 RX에서 CC (Connection Confirm)을 줌으로서 Synchronization이 이뤄진다
3-way
추가적으로 TX에서 한번더 DT(Data Transmission) complete를 보내게 된다

• 

2-way handshaking

initiator enitty (TX) : request PDU 전송
관련 parameter를 모두 담아서 한번에 responder에게 전달
(전송률, 지연, 처리량, 와이파이 or lte 등 채널, pud 크기 정보 등)

responder entity (RX) : confirm PDU 전송
RX는 confrim PDU 전송 직후 connection이 맺어졌다 가정

문제점 (confirm PDU의 loss)
confirm PDU의 loss가 발생해도 마찬가지로 connection이 맺어졌다 가정한다

unidirectional 형태 전송의 경우 2-way handshake로 충분하지만
(TX에서 request PDU 보냈고, RX에서도 confim PDU를 보냈으므로 TX에서 Data를 보내고 RX가 받을 수 있다)
bidirectional 형태 전송의 경우 문제 발생
(RX에서 confirm PDU가 loss났는데 data를 바로 보내버리면 TX는 아직 받는 data가 자신에게 보낸 데이터인지 모른다)
(Timer로도 해결이 불가능)

3-way handshaking

request / setup / complete

2-way에 추가적으로 Initiator(TX)가 confimation수신에 대해 responder에게 confirm(complete)를 해준다. responder는 complete를 수신하면 connection이 맺어진걸로 간주한다
만약 TX에서 보낸 complete가 손실되더라도, responder는 다음 pdu를 받으면 complete를 받은것으로 인지해서 connection이 맺어진 상태가 된다

• 이전 request를 받았고, 그에 대한 응답으로 confirm을 보냈다 (따라서, initiator의 상태는 확인 되었다)
• initiator에게서 complete를 못받아도 후속 data PDU를 수신하면 complete를 수신한 것으로 간주할 수 있다

---

Connection Management

connection-oriented protocol(TCP)에서 connection을 설정 / 관리 / 해제를 하기 위한 동작

Connection Establishment (설정)

• Establish connection : entity간 connection 연결 [수용 / 거부] 상태를 맞추는 과정. 이때 negotination이 이뤄질 수 있다
• Negotiate the Quality of Service (QoS) : 전송에 대한 품질 협의추가적으로 handshake 과정을 통해서 synchronization이 이뤄진다. (throughput, delay, error / loss rate etc)
• responder는 connection request에대해 reject할수 도 있다
  • resource부족으로 connection을 다루지 못하는 경우
  • (reduce의 경우 responder가 역제안을 주고, initiator가 받을지 결정해야 한다)
  • request 메시지내에 요청한 QoS를 받아들일수 없는 경우 (negotiation 실패)

peer entity들 간 connection 설정

Explicitly (명시적)
- (2-way, 3-way)메시지 교환을 마치고 서로 연결 상태로 전환
- connection setup / data transfer phase 두가지로 명확하게 나뉜다
- 2-way or 3-way handshake를 활용한다

Implicitly (암시적)
connection establishment 시작과 동시에 connection이 맺어졌다고 가정. 잘 사용하지 않는다
- confimation 메시지를 기다리지 않고 REQ 전송과 함께 Data 전송
- connection establishment delay가 성능 저하를 일으키지 않는다
- 현대 무선 중심의 데이터 교환 환경에서 packet손실의 가능성이 매우 높으므로 이런 connection을 미리 갖는 것이 (request PDU등을 통해 사전 정보를 받고 QoS의 진행 등) Data transfer가 안정적으로 진행 될 수 있다

Connection Maintenance (관리)

Breakdown of a connection 상황 발생 시

• 하위 layer에서 문제가 발생하면 상위 layer에 알린다
• Re-establishment of Connection 을 수행하게 된다
  (휴대폰이 기지국을 잃은 경우 계속 다시 연결되기 위해 하는 시도)

Re-establishment of Connection

• 상위 layer에서 하위 connection에 문제가 발생한 경우
• re-synchronization
  broken (N-1) connection에 대해 re-establishment 하는 것

• reassignment
  새로운 (N-1) connection에 대해 establishment 한다

Connection Release (해제)

SAP간 connection이 더이상 쓸모가 없어졌을 때 수행한다
말그대로 통신이 정상적으로 종료된 상황 : explicit release
비정상적으로 종료된 경우 (주파가 닿지 않거나, 너무 많은 장치에서 채널을 공유하러 하는 경우(축제 등)) : abrupt release

Explicit release

• 서로 합의 하에 종료
• release 직전의 data 전달 동작 처리
• peer간 메시지 교환을 통한 release 상태에 대한 synchronization종료를 위한 요청을 보냈고, 응답으로 ACK를 보냈지만, 반복적으로 ACK의 유실이 발생했고, time out으로 인해 재 송신을 반복하다가 일정 횟수 이후에는 강제로 연결을 종료하게 된다
• 단, 잘못하면 half - open connection problem이 발생 할 수 있다
• 항상 메시지 유실 상황을 대비해야 한다

Unidirectional connection 에서의 Release

• TX entity 쪽에서 release 요청을 해야한다release 메시지가 이전 PDU 보다 먼저 도착할 수도있다. 따라서, release 요청 PDU 또한 sequence number를 가짐으로서 해당 PUD가 release 이전 메시지 임을 알려줘야 한다
• (RX는 PDU의 전송 상황을 모르므로 release를 요청시 PDU 유실 여지가 있다)
• release 절차는 2-way handshake로 release 요청을 받고 release confirm을 보내줘야 release 여부를 알수 있다

Bidirectional Connection 에서의 Release

기본적으로 unidirectional connection 두개에 대해 각각 release를 하는 것과 같다 (=half close)

• 3-way handshake 절차를 사용시
  1. TX → RX : (DR)release Request 전송
  2. RX → TX : DR 요청 받고 똑같이 (DR) release Request 전송
  3. RX : DISC ind(discard indicator)를 다음 layer에 전송 & (DC) release confrim 전송
  4. RX : DC 받고 DISC ind를 다음 layer에 전송
• 양방향 connection에 대해서 모두다 release를 하는 것

connection relase 때 3-way handshake에서의 synchronization 문제점

PUD 손실에 대한 문제 발생시 대부분 PDU Timer로 해결

• (2)번 RX측 DR 손실 시
  • TX는 DR을 보내고, RX부터의 응답이 Time out 시 release 수행
  • RX 또한 DR을 보냈는데, TX로 부터 confirm이 오지 않아 Time out 시 release 수행
  • (DR이 손실 되었으므로 TX는 모른다)
  • TX, RX 모두 Timer Expiry
• (3)번 TX측 DC 손실 시
  • TX는 release도 보냈고, confirm도 받았으므로 release 정상 수행
  • RX는 DR 응답을 보내고, confirm에 대한 Time out 시 release를 수행한다
  • RX 만 Timer Expiry
• (1)번 TX측 DR 손실 시 RX는 Activity Timer Expiry
  • TX는 DR을 보내고 난 후 Time out시 release 수행
  • RX는 Activity Timer를 가지고 판단하게 된다RX는 TX로부터 Activity Time out시 TX가 동작하지 않는다 판단하고 release를 수행
  • Activity Timer : 실제로 TX가 동작하고 있는지 모니터링하는 타이머
  • TX는 PDU Timer Expiry

 

Abrupt release

• 비정상적인 상황에서 곧바로 connection 해제
• 아무리 재전송을 해도 ACK가 오지 않는 경우 등
• data transfer loss가 필연적으로 발생 할 수밖에 없다
• 예외적인 case
  • security issue (보안 이슈)
  • irreversible transmission error (되돌릴수 없는 전송 에러)

Reuse of Connection reference 문제에 대한 방지
→ freezing of connection reference : 일정 시간 동안 해당 연결을 사용하지 않는 방법이 있다