코딩도상국

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

https://www.thethingsnetwork.org/docs/lorawan/end-device-activation/

• Over-The-Air-Activation (OTAA) - the most secure activation method for end devices. Devices perform a join procedure with the network, during which a dynamic device address is assigned and security keys are negotiated with the device.
• Activation By Personalization (ABP) - requires hardcoding the device address as well as the security keys in the device. ABP is less secure than OTAA and also has the downside that devices can not switch network providers without manually changing keys in the device.

OTAA와 ABP의 차이는 인증방식이다.

ABP는 사전에 Application_Key, Network_Key를 가지고, 하나의 채널을 Default로 고정하여 사용한다. 그러므로 Join_Request, Join_Accept 과정이 필요하지 않는다.

반면 OTAA는 ABP와 달리 네트워크 첫 진입 시  Join_Request, Join_Accept 를 주고 받으며, 인증을 받는다. 아래 그림은 OTAA 메세지 흐름을 설명한다. 

End_Device가 Join_Request 메세지를 업링크(Up_Link)한다. Application_Server가 Join_Request에 대한 세션 키를 생성하면 Join_Accept 메세지를 End_Device로 다운링크(Down_Link)한다. (이는 기본적으로 Class_A로, End_Device 주도방식이다.)

여기서 Join_Accept 메세지 안의 CFList가 중요하다. 

CFList(16bytes) – contains the optional list of channel frequencies to be used for the end device 

Join_Accept 메세지 안에는 End_Device가 Channel_Frequency를 사용할  CFList가 들어 있다. 여기서 ABP와 큰 차이점을 가진다. ABP는 하나의 Channel_Frequency를 사용한다면, OTAA는 CFList를 통해 Channel_Frequency가 바뀐다.

MBED 구현 부분이다. 

https://github.com/ARMmbed/mbed-os-example-lorawan

mbed_app.json 파일 안에 OTAA와 ABP 설정 관련된 부분을 설명한다.

• For OTAA

"lora.device-eui": "{ YOUR_DEVICE_EUI }",
"lora.application-eui": "{ YOUR_APPLICATION_EUI }",
"lora.application-key": "{ YOUR_APPLICATION_KEY }"​

• For ABP

"lora.over-the-air-activation": false,

"lora.appskey": "{ YOUR_APPLICATION_SESSION_KEY }",
"lora.nwkskey": "{ YOUR_NETWORK_SESSION_KEY }",
"lora.device-address": " YOUR_DEVICE_ADDRESS_IN_HEX  "

ABP를 사용하기 위해선 OTAA를 꺼야 한다.