코딩도상국

참고
LoRa Alliance Link Layer Specification v1.0.2

Confirmed mode : Confirmed mode에서 모든 Uplink(End Device(ED)에서 Network Server(NS)로 전송된 패킷) 후에 Class A ED는 두 개의 수신 창(RX)을 사용하여 확인 알림으로 NS의 ACK를 요구합니다.

Unconfirmed mode : Unconfirmed mode에서는 NS에서 ED로의 Downlink(DL) ACK가 필요하지 않습니다.

( GW : Gateway )
각 ED에는 전송된 데이터 Frame 수를 추적하기 위한 두 개의 Frame Counter(FCnt)가 있다. 
ex) FCnt Uplink(FCntUp)와 FCnt Downlink(FCntDown)
위 글은 Unconfirmed mode와 Confirmed mode의 차이를 간단히 도식하기 위해 Uplink만 언급한다.

FCntUp은 ED가 Uplink를 성공하면 1씩 증가한다.
(MAC Layer의 파라미터 중 하나로 16bits(2^16까지 표현 가능), 32bits(2^32까지 표현 가능)를 선택할 수 있다. 만약, FCnt가 16bits로 선언됐고, FCntUp이 2^16-1 이상까지 증가하였다면, 다음은 0으로 초기화한다.)

Unconfirmed mode와 Confirmed mode의 가장 큰 차이는 ACK 유무입니다. 하지만 또 다른 차이는 재전송(Retransmission) 입니다. 

Retransmission은 말 그대로 Uplink Packet을 GW가 수신 받지 못했을 경우를 대비해 재전송하는 방법입니다. 당연히 똑같은 Packet을 전송하므로 FCntUp은 증가하지 않습니다.

(nb는 전송 횟수입니다.)

unconfirmed mode는 무조건 똑같은 패킷을 retransmission를 설정한 만큼 재전송합니다. 그래서 보통 unconfirmed mode는 retransmission을 사용하지 않습니다.

confirmed mode의 경우, Uplink Packet에 대한 ACK를 수신하면, 재전송하지 않고 다음 Packet을 전송합니다. 하지만 ACK를 수신하지 못하면, 재전송을 시작하는데, 아래 테이블과 같이 DR을 설정하는데, 이를 ED의 Adaptive Data Rate(ADR)이라고 합니다.

unconfirmed mode와 confirmed mode를 간략히 설명했습니다. 

TTN에서 모범 사례라 하여 unconfirmed mode와 confirmed mode에 대해 언급한 부분이 있습니다.

https://www.thethingsindustries.com/docs/devices/best-practices/

LoRaWAN에서 unconfirmed mode를 지향하는 이유는  ALOHA 방식과 유사하기 때문입니다.

ED가 몇 백개 정도라면 괜찮겠지만, ED가 몇 만개가 된다면 채널의 혼잡도가 가중되기 때문에 최대한 불필요한 Packet을 줄이는 것이 중요합니다. confirmed 모드는 ACK가 필요하므로 채널을 혼잡하게 한다고 판단하는 것 같습니다.