반응형
참고
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가 필요하지 않습니다.

 

Unconfirmed mode
Confirmed mode

( 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를 설정한 만큼 재전송합니다. 그래서 보통 unconfirmed mode는 retransmission을 사용하지 않습니다.

confirmed mode retransmission

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

Data-Rate Adaptation during Message Retransmissions in confirmed mode

 


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

 

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

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

 

Best Practices

 

www.thethingsindustries.com

 

confirmed mode가 꼭 필요하지 않다면, unconfirmed mode 사용하세요.

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

 

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

728x90
반응형
반응형

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

 

[LoRa] Unconfirmed mode VS Confirmed mode

참고 LoRa Alliance Link Layer Specification v1.0.2 Confirmed mode : Confirmed mode에서 모든 Uplink(End Device(ED)에서 Network Server(NS)로 전송된 패킷) 후에 Class A ED는 두 개의 수신 창(RX)을 사용하..

coding-yoon.tistory.com


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로 여는 것입니다. 

728x90
반응형

+ Recent posts