코딩도상국

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

End Device와 Gateway로 구성된 LoRaWAN MAC 계층을 기반으로 LoRaWAN에는 세 가지 종류의 End Device(ED)가 있습니다. Class는 Class A, Class B 및 Class C로 정의됩니다.  모든 LoRa 클래스 기반 End Device는 본질적으로 양방향 (Bi-directional) 통신입니다. 

Class A는 가장 에너지 효율적이며 배터리 수명이 가장 길며, 기본 Class입니다. Class B, Class C는 Class A에서 파생된 방식입니다.

참고
LoRa Alliance - Link Layer Specification v1.0.2
Semtech - An In-depth Look at LoRaWAN® Class A Devices
SKT - 저전력 IoT LoRa 디바이스 기술 요구사항

LoRa Class A ED의 기능입니다.
• 프레임은 일반적으로 uplink 전송과 downlink 전송으로 구분된다. uplink는 1개의 Slot과 2개의 downlink slot(또는 Window)으로 구성됩니다.
• Uplink Slot은 필요에 따라 ED 자체에서 스케줄링됩니다. ALOHA 프로토콜과 유사하게 무작위로 결정됩니다.
• 가장 낮은 전력의 LoRa ED입니다.

위 그림을 자세히 보면 Class A가 배터리 효율적인 이유를 알 수 있습니다. ED가 uplink를 송신하고 일정 시간 동안만 수신 윈도우(RX)를 여는 시간을 제외하고는 대부분을 Sleep 상태로 유지합니다. 

여기서 중요한 것은 ED가 uplink 송신을 해야만 GW로부터의 downlink를 받을 수 있습니다. 

에너지 측면에서는 굉장히 효율적이지만 downlink를 제때 받기가 어렵습니다. 이를 해결하기 위해 Class B, C가 나온 것입니다. 

그리고 Class A를 설명하기 전 unconfirmed mode와 confirmed mode를 설명했습니다. 

( 날짜를 보면 이 글이 먼저 포스팅되있지만, unconfirmed mode와 confirmed mode가 Class A에서 어떻게 동작하는지 설명하기 위해 비공개로 미리 올려놓고 중단했기 때문에 글의 순서가 다릅니다.)

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

Class A에서 unconfirmed mode는 굉장히 단순합니다. 아래의 그림처럼 uplink를 송신하고 downlink를 수신 받기 위해 RECEIVCE_DELAY1, RECEIVCE_DELAY2 이 후에 각각 RX1, RX2를 엽니다. 

SKT LoRa 기술요구사항 (Regional Parameters)을 보면 RX1, RX2에 관해 자세히 알 수 있습니다. 

RX1은 922.1~923.3MHz 대역에서 SF7~SF12를 사용할 수 있습니다. 

RX2는 921.9MHz에서 오로지 SF12 전용 채널로 사용되고 있습니다.

RX2를 SF12 전용 채널로 사용하는 이유를 confirmed mode에서 대략 유추해볼 수 있습니다. 

confirmed mode는 unconfirmed mode와 다르게 ACK를 수신 받습니다. 

confirmed mode는 unconfirmed mode와 다르게 RX1에서 ACK를 수신 받으면, RX2를 열지 않습니다. 

RX1에서 ACK를 수신 받지 못하면, RX2에서 좀 더 확실하게 ACK나 downlink를 받기 위해 SF12로 여는 것입니다. 

안녕하세요.

국내 LoRa Specification을 관련해서 찾아보던 중 SKT 홈페이지에서 LoRa 관련 사업을 보게 되었습니다. 

그 중 하나가 Smart [지킴이] 입니다. 

ED에 GPS를 장착해 위치를 GW/NS 로 보내고 AS에서 공공기관으로 Integration 하는 방식인 것 같습니다. ( 일반적인 LoRaWAN이므로, 당연한 이야기입니다. )

저전력, 장거리 통신인 LoRa를 이용한 가장 기본적으로 생각해볼 수 있는 아이디어 인 것 같습니다. 

ED : End Device
GW : Gateway
NS : Network Server
AS : Application

이 사업을 보면서 들었던 생각은 과연 SF 결정은 어떻게 하는지 의문이 들었습니다. 

SF를 결정하는 Typcial ADR(Chirpstack 방식, TTN 방식)은 Static으로 즉, 움직이지 않는 ED를 대상으로 SF를 결정하므로, 움직이는 ED에는 적합하지 않습니다. 

https://coding-yoon.tistory.com/164?category=952690 

그래서 지킴이 사업 같은 경우는 GPS가 탑재된 ED를 착용한 사람은 움직이기 때문에 Mobility를 위한 ADR이 필요합니다.

Semtech방식의 Blind ADR을 소개하려고 합니다. 

https://lora-developers.semtech.com/uploads/documents/files/LoRaWAN_Mobile_Apps-Blind_ADR_Downloadable.pdf

기본적으로 Typical ADR은 SNR Margin을 계산하여 SF를 GW에서 다운링크로 주고 ED에서 다운링크를 받고 SF를 결정하는 방식입니다. 나중에 시간이 된다면, Chirpstack Opensource를 이용해 자세히 봐보겠습니다.

하지만, 채널 조건이 급격하게 변하는 모바일 어플리케이션의 경우엔 Typical ADR은 사용할 수 없어 Semtech은 Blind ADR을 제시합니다. 

Blind ADR은 생각보다 간단합니다. 이동체를 예측할 수 없기 때문에, 다운링크를 주는 방식이 아닌 ED에서 일정 주기를 가지고 SF를 규칙적으로 변경하는 것입니다. 그림을 보면 쉽게 이해할 수 있습니다.

한 시간에 SF12로 한 번, SF10로 두 번, SF7로 세 번 씩, 위와 같이 변경하면서 전송하는 방식입니다. 

이 Semtech 방식의 간단한 Blind ADR은 애완 동물 추적 같은 응용 프로그램에서 낮은 전력 소비를 유지할 수 있었다고 합니다. 

지킴이 대상인 어르신, 어린이 같은 몸이 약한 사람이 애완 동물보다 빨라 봐야 얼마나 빠르겠습니까. 그래서 Semtech 방식의 Blind ADR을 쓰지 않았을까 조심스럽게 예상해봅니다.

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