SKT의 LoRa 단말의 데이터는 SKT의 ThingPlug로 저장된다.

따라서 SKT LoRa 개발자는 ThingPlug 상에서 LoRa 단말의 데이터가 정상적으로 전송되었는지 체크할 수 있다.

이 포스팅에서는 Postman이라는 API 테스트 툴을 활용해서 SKT LoRa 단말의 데이터를 확인하는 기본 방법에 대해서 작성한다.

자세한 내용은 IoT 오픈하우스를 통해 문의할 수 있다.

https://www.sktiot.com/iot/support/openhouse/reservation/openhouseMain

앞서 설명한대로, SKT LoRa는 ThingPlug로 연동되며, 사용자 앱서버에서는 MQTT나 HTTP로 LoRa 단말의 데이터 조회와 제어 등을 할 수 있다.

API를 사용하기 위해서는 우선 ThingPlug에서 발급해주는 ukey(사용자 인증키)가 필요하다.

(ThingPlug 가입/단말 등록 등은 이번 포스팅에서 다루지 않음.)

테스트 툴은 postman이라는 API 테스트 툴을 사용한다.

https://www.getpostman.com/

그리고 아래 script를 다운로드한다. script는 두 종류로 나누어져 있는데, 테스트 script와 ukey, 단말 id 등 환경 변수를 입력하는 파일로 나뉘어져 있다.

https://github.com/wpgnss/thingplug_lora_script

두 파일의 사용법은 아래와 같다.

우선, [Script]_ThingPlug_API.postman.json 파일을 postman에서 import 한다.

다음은 [Env]_ThingPlug.postman.json 파일로 환경 변수파일을 추가로 import 한다.

환경변수 파일을 import 하면 아래처럼 각각 value를 입력할 수 있으며, 테스트를 위해 최대한 입력한다.

최소한 app_eui, ltid, uKey, platform_url은 입력되어 있어야 기본 테스트를 진행할 수 있다.

LPWAN(Low Power Wide Area Network), 즉 적은 전력으로 긴 거리를 통신하는 기술이다. LPWAN은 통신빈도가 적고, 소량의 데이터를 사용하는 Metering, Tracking 등의 응용에 적합한대, LoRa와 NB-IoT가 바라보고 있는 응용 분야갸 같기 때문에 전혀 다른 기반기술임에도 많은 비교가 되고 있다.

이번 포스팅에서는 LoRa의 단점 중 하나라고 지적되는 LoRa의 보안 이슈를 SKT의 LoRa에 대해서 적어보려고 한다.(Public LoRa와 차이점이 있음.)

1. LoRa Device - Network Server

LoRa Device와 Gateway 사이는 비면허 대역이고 Broadcast로 통신하는 LoRa 특성상 보안 이슈가 발생할 수 있다.

일단 LoRaWAN 프로토콜 자체에서  AES-128 Encryption으로 Network Session Key를 관리한다. Public LoRa는 아래 그림에서 Pseudo App Key Join 단계만 수행하게 된다.

SKT LoRa는 Pseudo Join 단계를 통해 암호화된 Real App Key를 생성하게 되고, 이 Real App Key를 사용해 Real Join을 하도록 설계되어 있다. 다시말해 서로 다른 키를 이용해 AES-128로 2회 encryption 하는 것이다.

2단계의 Join 과정을 통해 Join Key가 외부로 유출되는 것을 원천 차단하고 있고, SKT에서 인증받지 않은 단말은 SKT LoRa Network에 접속할 수 없게 된다.

또한, LoRa는 IP 기반이 아닌 EUI64 기반의 ID 체계를 사용하기 때문에 DDOS, 스미싱, 스캐니닝, 바이러스 등 IP 기반의 공격에 안전하다.

2. ThingPlug - App Server

ThingPlug와 App/Web Server 사이에서는 MQTT/HTTP 기반에 oneM2M 프로토콜을 사용한다.

1) TCP Layer 보안

 MQTT와 HTTP는 TCP/IP Layer 기반에서 제공되는 SSL encryption도 지원하고 있다.

2) oneM2M Layer 보안

ThingPlug에서 REST API를 사용해 데이터를를 조회하거나, 디바이스를 조회하기 위해서는 사용자 인증키가 필요하다.

이 사용자 인증키는 SKT에서 발급해 주는 키로 타인의 접근을 방지는 역할을 하게 된다.

3) MQTT Layer 보안

MQTT를 사용하는 경우에도 oneM2M 프로토콜을 사용하기 때문에 사용자 인증키 보안을 사용한다.

추가로 경우 MQTT 접속시에 client ID, username, password를 적용하여 타인의 접속 자체를 차단하고 있다.

LoRa를 이용해 무엇인가를 만들려고할 때 App Key, App EUI, Dev EUI, LTID 라는 ID를 접할 수 있는데, 각 ID가 어떻게 사용되는지 알아보자.

아래 설명될 내용은 public LoRa 보다는 국내에서 서비스 중인 SKT의 LoRa에 맞추어 설명 되었습니다.

1. <LoRa Device>-<N/W 서버>

먼저, App EUI와 Dev EUI, App Key는 위 시스템 구성 예시에서 <LoRa Device>-<N/W 서버> 사이에서 사용된다.

디바이스가 LoRa network에 접속할 때(OTAA: over the air activation) 사용하는 ID와 activation key이다.

접속 과정에서 App EUI와 Dev EUI는 디바이스에 할당된 unique한 ID로 사용되며, App Key는 데이터 암호화를 위해 사용된다.

 App Key는 SSL에서 사용하는 인증서와 같은 개념이라고 볼 수 있다.

LoRaWAN Specification을 보면 APP EUI와 Dev EUI는 아래와 같이 정의되어 있다.

6.1.2 Application identifier (AppEUI)

The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame.

The AppEUI is stored in the end-device before the activation procedure is executed.

6.2.1 device identifier (DevEUI)

The DevEUI is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device

단순히 App EUI는 서비스를 구분하는 ID, Dev EUI는 디바이스를 구분하는 ID라고 보면 된다.

다시말해, 만약 100개의 LoRa 디바이스를 사용한다면, 모든 LoRa 디바이스의 Dev EUI는 다르고, App EUI는 100개 모두 동일할 수가 있다.

App EUI는 IEEE에서 정의한 64bit Address로 되어 있으며, SKT로부터 서비스마다 할당 받게 된다.

Dev EUI는  IEEE에서 정의한 64bit Address로 되어 있으며, LoRa 칩 개발사인 Semtech에서 할당 받는다.

2. <N/W 서버>-<ThingPlug>

LTID를 조합하는 예제

• App EUI: 0000000000000004

• Dev EUI: ffffffff12345678

만약 위와 같은 App EUI와 Dev EUI를 가진 LoRa 디바이스라면 LTID는 "00000004ffffffff12345678" 가 된다.

SK Telecom의 LoRa를 이용한 서비스의 개발은 아래와 같은 그림으로 구성됩니다.

App Server를 구현하기 위하기 위한 방법은 아래와 같습니다.

1. 프로토콜 선택

- HTTP

- MQTT

2. 데이터 수집 방법 선택

- Polling

-Subscription

데이터 수집 방식을 그림으로 표현하면 아래와 같습니다.

자세한 내용이 궁금하다면 강의에 참석해 보세요.

https://lora.sktiot.com/openhouse/introduction/academy.do

이번 달 강의는 4월 25일로 예정되어 있으며, 위 링크에서 신청하실 수 있습니다.

(강의 신청은 추후에 오픈될 예정입니다.)

ThingPlug Bridge는 위 LoRa 서비스에서 (A) 위치에 해당하는 툴이다.

원래는, (B)에 해당하는 서비스 App 서버가 ThingPlug와 연동해 LoRa 디바이스의 데이터를 가져가고, 제어명령을 내려야 한다.

하지만, 기존의 App 서버를 변경하지 않고 LoRa 서비스를 사용하고 싶은 경우 ThingPlug Bridge를 활용하면 가능해진다.

ThingPlug Bridge 본 글에 첨부되어 있다.

ThingPlug_Bridge (2).z01

ThingPlug_Bridge (2).z02

ThingPlug_Bridge (2).zip

ThingPlug Bridge 의 역할

ThingPlug Bridge는 ThingPlug의 subscription 기능을 활용해서 만들어졌다. ThingPlug 포털의 ID와 PWD로 로그인을 하게 되면 아래와 같이 User Key를 받아오게 된다.

(User Key는 App이 ThingPlug에 접근하기 위한 권한이다.)

이 User Key를 가지고 로그인한 계정에 있는 LoRa Device 리스트를 조회 할 수 있고, ThingPlug는 Device들의 데이터를 ThingPlug Bridge로 Push 해준다.

Bridge는 ThingPlug로 부터 Push 받은 데이터를 설정된 서버로 보내고, Log 파일로 남기는 역할을 하게 된다.

ThingPlug Bridge 사용방법

1. 로그인

로그인하기 전, 접속하고자 하는 ThingPlug 플랫폼의 주소와 Port 번호를 우선 입력한다.(테스트망, 상용망에 따라 이 주소가 다르다.)

그 후 ID와 PWD를 입력해 Login 버튼으로 User Key를 얻어온다.

2. 설정

APP EUI와 App Server 정보를 입력한다.

APP EUI: LoRa 서비스의 경우, SKT로부터 할당받게 되며, ThingPlug만 사용하는 경우 'ThingPlug' 그대로 두면 된다.

App Server: Push 받은 데이터를 다시 보낼 서버의 주소를 입력한다.

3. RUN

RUN!

4. 디바이스 리스트

ThingPlug 계정에 등록된 디바이스의 리스트를 확인할 수 있다.

5. 디바이스 제어

ThingPlug 디바이스를 제어할 수 있다. data 필드를 이용해 유저 데이터를 보낼 수 있는데, LoRa 디바이스는 extDevMgmt 명령에서만 가능하다.

6. App Server

위 설정에서 App Server로 설정된 서버로 실제 LoRa 디바이스가 보낸 데이터를 보내게 된다.(1234567890 x 4)

7. 데이터 로그

데이터의 Log는 'log\debug_log.txt'에서 확인할 수 있다.

LoRa의 Class, 서비스 형태에 따라 선택해야 한다.

LoRa 디바이스로 구성된 LoRa network에서 LoRa 디바이스는 통신을 위해 3가지 클래스로 동작한다.

이 클래스는 Down-Link 할 수 있는 타이밍에 따라 구분된다. LoRa 디바이스는 LoRa Gateway에 Join 하면서 사용할 클래스에 대한 정보를 Gateway와 공유하게 된다. 그리고 LoRa 디바이스의 클래스에 따라서 디바이스에게 데이터를 보내는 타이밍을 정한다.

Class를 선택하기 위해서는 LoRa 서비스의 형태와 LoRa 디바이스에 상시전원을 공급할 수 있는지 여부로 판단할 수 있다.

서비스의 형태는 LoRa 디바이스가 Up-Link 위주의 서비스인지, Down-Link도 포함하는지 여부이다.

A Class

LoRa 디바이스와 LoRa 게이트웨이 사이의 A Class 통신은, LoRa 디바이스가 게이트웨이에게 Up-Link 전송을 수행한 이후에 두 번에 걸쳐 Down-Link 수신할 수 있다.

LoRa 디바이스는 Tx를 하기 전에는 Tx와 Rx를 꺼두었다가 Tx 이후 정해진 시간에 잠깐 Rx 신호를 감지한다.

A Class를 사용하면 Rx를 수신하기 위해서 Tx를 사용해야 한다. 그렇기 때문에 Tx 위주의 서비스나, 상시전원을 사용하지 않고 배터리로 운영하는 경우에 사용한다.

아래 그림에서 (노란색)은 LoRa 디바이스가 Rx 할 수 있는 상태이다. Tx 1회당 2번의 Rx를 할 수 있는데, 첫 번째 Rx 타이밍에 수신한 데이터가 없을 때 두 번째 Rx를 시도 한다.

B Class

A Class가 Up-Link(Tx) 위부의 Class라면 B Class는 Down-Link(Rx)를 고려하고, A Class에 비해 낮은 지연시간의 Class 이다.

B Class는 일정 시간 간격마다 Rx를 수신할 수 있는 상태(노란색)가 되고, 해당 타이밍에 LoRa Gateway로 부터 데이터를 수신할 수 있다.

B Class는 A Class와 달리 Rx 위주의 서비스와, 배터리로 운영하는 경우 고려할 수 있다.

주로 A와 C를 사용한다.

C Class

C Class는 Rx 가능 상태를 유지하기 때문에 타 Class에 비해 최소 지연시간을 갖지만, 가장 많은 전력을 소비한다. 그래서 C Class를 사용하기 위해서는 충분한 전력이 공급되는 상황에서 고려해야 한다.

항상 Rx 가능 상태이기 때문

에 LoRa를 이용한 스마트 플러그, 원격 제어등 액츄에이터 구현에 적합한 Class이다.

Rx1, Rx2, Tx 등등 LoRa 기술 상 이슈로 아래 이미지에서는 노란색 중간중간 비워두었다.