'SKT'에 해당되는 글 10건

IoT Open House/ThingPlug

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

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

 

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

 

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

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

 

SK telecom IoT Portal

목적 - 기술지원을 통한 서비스 개발 및 상용화 기간 단축 - 개발자 지원을 통한 자생적 개발환경 조성 및 LoRa, Cat.M1, LTE-M 생태계 활성화 지원대상 - LoRa, Cat.M1, LTE-M 단말 및 서비스 상용화 준비중인 중소기업 및 스타트업 지원업무 - 기술지원을 통한 서비스 개발 및 상용화 기간 단축 - 개발자 지원을 통한 자생적 개발환경 조성 및 LoRa, Cat.M1, LTE-M 생태계 활성화 지원업무 설명 컨설팅 기획/개발, 디바

www.sktiot.com

 

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

 

 

 

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

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

 

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

https://www.getpostman.com/

 

Postman | API Development Environment

Postman is the only complete API development environment used by more than 6 million developers and 200,000 companies worldwide.

www.getpostman.com

 

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

 

https://github.com/wpgnss/thingplug_lora_script

 

wpgnss/thingplug_lora_script

Contribute to wpgnss/thingplug_lora_script development by creating an account on GitHub.

github.com

 

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

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

 

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

 

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

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

 

IoT/News

LPWAN은 어떻게 펌웨어 업그레이드가 진행될까?

디바이스가 출시된 이후에도 버그 수정이나 성능 향상을 위해 펌웨어 업데이트가 필요하다. 펌웨어를 업데이트 하는 방법은 다양하지만, 네트워크에 연결된 단말들은 FOTA(Firmware Over The Air)라는 기능을 활용해 펌웨어를 업데이트 해왔다.
FOTA는 무선 네트워크를 활용해 자동으로 디바이스의 펌웨어를 업데이트 하는 방법 중 하나이며, 펌웨어를 ‘배포’할 수 있다는 장점을 같는다. 이는 공급자의 입장에서 다바이스를 각각 따로 업데이트를 하지 않고, 선택된 디바이스로 펌웨어를 배포함으로써 수많은 IoT 디바이스에 일괄적으로 펌웨어를 업데이트할 수 있다.

기하급수적으로 늘어날 것으로 예상되는 IoT 디바이스들도 FOTA가 가능하면 디바이스 관리 측면에서 많은 장점이 있을 수 있다.
이 글에서는 SKT에서 제공하고 있는 IoT 통신방식인 LoRa와 Cat.M1은 FOTA가 가능한지 여부와 FOTA 방법에 대해 소개하도록 하겠다.

Cellular/WiFi 등의 Network와 LPWAN(Low Power Wide Area Network)의 차이점

Celluar Network와 LPWAN은 사용 목적 부터 다르다. Celluar Network는 스마트폰이나 셋탑박스등에서 더 많은 양의 데이터더 빨리 보내기 위해 발전해 왔다. (3GPP는 Release 13에서 IoT를 위해 LTE 기반의 LPWAN인 NB-IoT와 Cat.M1을 발표했다.)
하지만 LPWAN은 IoT 디바이스의 요구에 맞추어 저렴한 가격으로 저전력으로 오랜 시간 동작이 가능하며, 먼 거리로 데이터를 전송하도록 설계되었다. 그렇기 때문에 trade off로 낮은 data rate를 갖는다

LoRa와 Cat.M1의 차이점은 사용하는 주파수 대역과 통신방식, 속도 등이 있을 것이다.

우선, LoRa의 사용 주파수 대역은 국가마다 차이가 있지만 비면허 대역을 사용한다. Cat.M1은 LTE 면허 대역을 사용하기 때문에 허가된 공급자만 서비스할 수 있다. 면허 대역과 비면허 대역을 사용하는데서 발생하는 데이터의 무결성 또한 차이가 있다.

통신 방식의 차이도 있다.
Cat.M1의 경우에는 LTE 계열이기 때문에 IP 통신을 한다. 이 말은 Cat.M1을 사용하는 IoT 디바이스는 IoT 서버에 직접 접속할 수 있다는 의미이다.
반면 LoRa의 경우 자체 정의된 비 IP 통신을 한다. 그렇기 때문에 IoT 서버와 연결되기 위해서는 중간에 LoRa 프로토콜을 IP 통신으로 변환해주는 LoRa 게이트웨이가 필수이다.

LPWAN의 데이터 다운로드 속도

SKT의 IoT Portal을 보면, SKT LPWAN의 속도에 대한 자료가 있다.(https://www.sktiot.com/iot/introduction/iotnetwork/iotNetworkCatM1)
이 자료를 보면, LoRa는 5.4Kbps, Cat.M1은 375Kbps의 속도로 표기되어 있다.

이 속도는, 디바이스가 100KB의 펌웨어 파일을 수신하기 위해서는..
LoRa의 경우 92.6초가 소요 되며, Cat.M1의 경우 2.14초가 소요 된다.

그리고 SKT LoRa의 경우 LoRa 망의 안정성을 위해 디바이스당 데이터 양을 60Byte, 전송 주기를 1분으로 제한을 두고 있다.
그렇기 때문에 100KB의 펌웨어를 디바이스로 전달하기 위해서는 최소 1,667분이 소요된다.

사실상 SKT LoRa의 경우에는 FOTA를 사용해 펌웨어를 업데이트 하기에는 제약이 있다.

FOTA 서버를 활용한 펌웨어 업그레이드

LoRa 디바이스 펌웨어 업그레이드

SKT의 LoRa를 사용하는 경우 FOTA는 사실상 불가능한 것으로 보인다. Private LoRa의 경우에는 Data rate 등의 조정으로 FOTA를 서비스하는 경우도 있다.

SKT ThingPlug를 활용한 Cat.M1 디바이스 펌웨어 업그레이드

SKT는 ThingPlug라는 이름으로 IoT 서버 플랫폼 서비스를 제공한다. ThingPlug에서는 기본적인 IoT 디바이스 관리나 데이터 저장과 같은 서비스를 제공하고 있으며, FOTA 서비스를 추가로 제공하고 있다.

SKT Cat.M1과 ThingPlug를 이용한 FOTA 방법은 아래 글에서 확인할 수 있다.

https://www.wiznetian.com/lte-cat-m1-application-note-firmware-over-the-air-%ED%99%9C%EC%9A%A9%ED%95%98%EA%B8%B0%EC%9A%B0%EB%A6%AC%EB%84%B7-2/


IoT Open House/LoRa



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를 적용하여 타인의 접속 자체를 차단하고 있다.


'IoT Open House > LoRa' 카테고리의 다른 글

LoRa ID 체계 (App Key, App EUI, Dev EUI, LTID)에 대한 정리  (0) 2017.05.17
LoRa Class (A/B/C)  (0) 2017.02.07
IoT Open House/LoRa

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>


N/W서버와 ThingPlug, 그리고 Web/App 서버에서 사용하는 디바이스의 unique ID를 LTID(LoRa ThingPlug ID)라고 한다.
LTID는 SKT에서 정의한 ID 체계이며, AppEUI와 DevEUI를 조합한 unique한 ID이다.




LTID를 조합하는 예제

  • App EUI: 0000000000000004

  • Dev EUI: ffffffff12345678


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




'IoT Open House > LoRa' 카테고리의 다른 글

SKT LoRa 서비스의 보안 방식  (0) 2017.07.03
LoRa Class (A/B/C)  (0) 2017.02.07
IoT Open House/ThingPlug


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




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


1. 프로토콜 선택

- HTTP

- MQTT


2. 데이터 수집 방법 선택

- Polling

-Subscription



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








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


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



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

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


IoT/News

LoRa를 이용해 IoT 제품을 개발하시려는 분들에게 무료 강의를 진행합니다.


SKT에서 서비스하는 LoRa 기술과 ThingPlug에 대한 강의 입니다.


아래 링크에서 강의를 신청하실 수 있습니다.

http://wiznetacademy.com/index.php?module=lecture&act=dispCourseInfo&course_seq=3178


LoRa 강의는 아래 SKT LoRa Potal 을 통해 강의 신청을 받기로 했습니다.

https://lora.sktiot.com/openhouse/main.do




이 외에도 '아두이노'와 'mbed' 기초 강의도 진행하고 있으며, 응용 강의로 '스마트팩토리', facebook으로 디바이스를 제어하는 'Javis' 강의도 준비되어 있습니다.



IoT Open House/ThingPlug


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'에서 확인할 수 있다.

IoT/WiFi

SKT ThingPlug 더 쉽게 시작하기 강의록입니다.


ThingPlug Device로는 Nucleo F411RE와 WizFi310(Embedded WiFi module)을 사용했습니다.


Application은 Python으로 작성한 대시보드를 사용했습니다.



ThingPlug 뿐만 아니라, Arduino, mbed, Embedded WiFi 관련 강의가 준비되어 있습니다.

http://wiznetacademy.com/



(강의록 로딩이 조금 오래 걸립니다.)


Prototype/IoT Platform

 

 

아래 게시글의 ThingPlug 대시보드는 Local PC에 node.js 서버를 구동해서 만든 대시보드였다.

http://1byte.tistory.com/10

 

그렇기 때문에 외부에서 접근하기 위해서는 port forwading 등 서버 port에 접속하기 위한 별도의 작업이 필요하고, Local PC에서 서버를 구동하고 있는 동안에만 접속할 수 있다.

 

따라서, 위 문제점등을 해결하기 위해서 외부에서 호스팅 해주는 방법이 필요해 보였다.

 

구글링 결과, Heroku라는 클라우드 플랫폼을 선택했다. Heroku는 테스트 용도로 적합해 보이며, 꽤 쉽게 어플리케이션을 호스팅 할 수 있었다.

 

 

1. ThingPlug Starter Kit 소스코드 다운로드

 

https://github.com/SKT-ThingPlug/thingplug-lora-starter-kit

 

우선 ThingPlug Lora Starter Kit을 다운 받았다. Starter kit의 사용 방법은 PC에 starter kit 소스코드와 node.js를 다운로드 받고, config_x.js 파일에 테스트할 node id, user key, container 등등 ThingPlug web Application에서 필요한 정보들과,  디바이스 시뮬레이터를 실행 시키기 위한 config 내용들이 모두 포함되어 있다.

그렇기 때문에 config_x.js 에 node id, user key, container등의 정보가 정상적으로 저장되어 있어야만 최신 데이터 조회, 디바이스 제어 등을 수행할 수 있다.

 

2. ThingPlug Starter Kit 소스코드 수정

 

제공하는 StarterKit도 쓸만하지만, 여러 사용자들이 Config 파일과 상관 없이 접근 가능한 대시보드를 만드는 것이 목표였기 때문에,, 조금 StarterKit의 소스코드를 조금 수정했다.

 

      

왼쪽의 서버 소스코드를 오른쪽 처럼 Node ID, User Key, Container Name 을 직접 입력 받도록 수정했다.

이 과정에서 필요 없는 부분인 google 지도와 Event trigger를 없앴다.

https://github.com/wpgnss/ThingPlug_starter_kit_for_academy

 

 

3. Heroku 사용하기

Heroku에서 어플리케이션을 배포하기 위한 방법은 3가지를 지원한다.

Heroku CLI를 다운로드 받아서 Heroku Git에 소스코드를 업로드 하는 방법과 GitHub나 Dropbox에 소스코드를 업로드 후 연결하는 방법이 있다.

 

Heroku CLI를 사용하는 방법은 구글링에도 많이 나오기 때문에, 머리아픈 CLI 없이 GitHub와 연동하는 방법으로 해보기로 했다.

 

4. Heroku 사용하기 – Procfile

 

Heroku를 사용하기 위해서 자신의 ThingPlug StarterKit repository에 꼭 필요한 파일이 있다. Procfile이라는 파일이다. 해당 파일을 생성 후 commit & push 해주자.

이 파일은 처음 실행되어야 할 web app의 이름을 정의하는 파일이다.

 

ThingPlug Starter Kit의 메인 js 파일은 application_web.js이니까 아래처럼 작성해 준다.

 

web: node application_web.js

 

 

5. Heroku 사용하기 – Create New App

https://dashboard.heroku.com

Heroku에 가입 후 dashboard 사이트에 접속하게 되면 오른쪽 상단에서 New->Create new app을 선택한다.

 

Create App을 선택한다.

 

GitHub를 선택한다. (이미 GitHub와 연동되었기 때문에 아래처럼 나오지만 처음이라면 GitHub에 권한을 요청하는 팝업이 뜬다.)

 

Search를 클릭한 후 원하는 Repository에 Connect를 누른다.

 

Enable Automatic Deploys 를 누른다.

 

정상적으로 진행했다면, Overview 탭에서 Dyno formation 에서 web node application_web.js    ON 으로 변하면서 서버가 정상 동작하게 된다.

만약 Dyno formation이 바뀌지 않는다면, Manual deploys로 해보자.

 

 

Open app을 누르면 동작 중인 서버에 접속할 수 있다.

 

이렇게…

 

 

사이트 주소 뒤에 /dashboard 를 입력하면 SKT ThingPlug 대시보드가 정상적으로 동작하는 것을 확인할 수 있다.

https://boiling-everglades-36951.herokuapp.com/dashboard/

Prototype/IoT Platform

  ThingPlug 대시보드  


Node-Red 대시보드

Node.js 대시보드








해당 ThingPlug 대시보드는 SKT의 ThingPlug-LoRa-Staterkit을 수정하여 만들어졌습니다. 

(https://github.com/SKT-ThingPlug/thingplug-lora-starter-kit)






1
블로그 이미지

IoT 개발자 블로그이고 싶다.

1byte