코딩도상국

참고
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가 필요하므로 채널을 혼잡하게 한다고 판단하는 것 같습니다. 

https://coding-yoon.tistory.com/163

이전 글에서 Chirp Spread Spectrum에 대해 이야기했습니다. 

LoRa는 Chirp기반 확산 스펙트럼 변조로, Symbol은 Chirp입니다.

아래의 하나의 블록 이미지를 Chirp이라 하였고, 주파수의 변화에 따라 Up-Chrip, Down-Chirp로 구별할 수 있습니다.

전 글에서는 세로폭에 대해 제대로 짚고 넘어가지 않았습니다. 

세로 폭은 SF((orthogonal)Spreading Factor; (직교)확산계수, 초당 데이터 비트, 시간 단위당 변조되는 기호), DR(Data Rate, 데이터 속도) 입니다. 

ToA : Time on Air; 통신 시간 (SF7~SF12)
SF : Spreading Factor; 확산 계수
DR : Data Rate; 데이터 속도 (DR5~DR0)

전에 LoRa 장거리 통신을 위해 세로 폭을 늘리게 되면, ToA가 늘어나게 됩니다.  SF는 시간 단위당 변조되는 기호로, 기본적으로 SF가 높을수록 통신이 느려집니다. 

SF는 두가지 값을 알 수 있습니다. 

1. 각 기호에 포함된 chip의 수는 2^SF
2. 해당 기호로 인코딩할 수 있는 원시 비트 수는 SF입니다. 

그러므로 SF가 커지면,

1. 통신 거리가 증가한다.
2. ToA가 늘어난다.
3. 전력 소모가 증가한다.
4. DR은 감소한다.

그렇다면 큰 SF가 좋은가? 그렇지 않습니다. 

SF가 크면 통신 거리는 증가하는 반면, DR이 줄어, ToA가 늘어나며, 전력 소모가 증가하는 문제점이 생기기 때문에, 적절한 SF와 DR을 골라야 합니다. 

참고 SF, 주파수, 대역폭을 알면 ToA를 계산할 수 있다. 
계산기 : https://www.thethingsnetwork.org/airtime-calculator
공식 : https://www.rfwireless-world.com/calculators/LoRaWAN-Airtime-calculator.html

기본적으로 LoRa 통신은 Class A 방식으로, End Device가 Up-Link를 해야만, Gateway가 Down-Link를 할 수 있습니다. 여기서 가장 최신의 20개 Up-Link를 이용해 정적인(움직이지 않는) End Device(EN)에서 가장 적절한 DR 혹은 SF를 고를 수 있는데, 그것이 ADR(Adaptive Date Rate)입니다.

ADR을 통해 DR을 변경하면, End Device의 수명을 늘리고 링크 품질 최적화를 시킬 수 있습니다.

Mac Layer에서 Mac Command가 있습니다. Mac Command를 이용해 4가지 파라미터(SF, Channel Mask, Tx Power, Retransmission)를 설정할 수 있다. 위 파라미터를 이용해 만든 알고리즘이 ADR이다. 기본적으로 ADR은 Typical ADR을 말하며, TTN, Chirp Stack, SKT 등에서 Typical ADR 알고리즘을 사용한다.

https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate/

ChirpStack Github에 Go Language로 구현.

https://github.com/brocaar/chirpstack-network-server/blob/master/internal/adr/default.go