'lora'에 해당되는 글 8건

Prototype/IoT Platform


Github

https://github.com/wpgnss/Arduino_Kakao_PlusFriends


카카오톡 친구 추가

Arduino_Kakao_PlusFriends

이 어플리케이션은 SKT의 LoRa 디바이스로부터 약속된 포맷의 GPS 데이터를 수신해 KAKAOTALK의 플러스친구로 위치정보를 알려주는 어플리케이션이다.

LoRa와 카카오톡을 이용한 GPS 트래커에 대한 내용을 오프라인 강의를 진행합니다.



서버 생성하기

아두이노 Web Server 예제를 기반으로 서버를 생성한다. 이 서버는 아래 그림과 같이 ThingPlug에서 Push 해주는 데이터 수신과 KakaoTalk에서 데이터를 요청하는 데이터 전송 기능을 담당하는 서버 역할을 한다.
이 예제는 사설 IP로 구현되었기 때문에 공유기 설정에서 Port Forwading 설정까지 해주어야 한다. 아니면 공인 IP를 사용해야 한다.

GPS 데이터 수신하기

SKT의 LoRa + GPS 디바이스에서 주기적으로 GPS 데이터를 생성&전달 해준다.
이 데이터는 SKT의 IoT 플랫폼인 ThingPlug에 저장되며, 이 데이터를 Subscription 기능을 사용해 아두이노 서버에서 수신하게 된다.

ThingPlug Subscription에 대한 간단한 설명: http://1byte.tistory.com/25

카카오톡 플러스 친구 개발하기

카카오톡에서 위치정보를 확인하기 위해서 카카오톡의 ‘플러스친구’를 사용했다.

카카오톡 플러스친구: https://center-pf.kakao.com
카카오톡 플러스친구 API: https://github.com/plusfriend/auto_reply

아두이노에서 플러스 친구를 사용하기 위해서는 ‘자동응답’ 설정을 ‘API형 자동응답’으로 설정해야 한다.

그 후 아래 두가지에 대한 내용을 개발해야 한다.

  1. keyboard
    keyboard는 사용자에게 제공할 입력 수단이다. 직접 text 입력을 받을 수도 있고, 정해진 버튼을 만들어 사용자가 선택하도록 할 수도 있다.

    ex) GET url:port/keyboard HTTP/1.1

  2. message
    사용자가 keyboard를 통해 입력&선택하게 되면 아두이노 서버에 message 로 요청이 오게 된다.

    ex) POST url:port/message HTTP/1.1

위 두 기능을 구현하면 아래와 같이 카카오톡 플러스친구를 통해 아두이노 서버와 통신할 수 있다.

카카오톡에서 위치 정보 확인

Location, Roadview 기능이 구현되어 있다.

  • Location을 누르면, 자동응답으로 가장 최신의 GPS 데이터를 기반으로 지도 정보를 보내준다. 메세지에는 간략한 지도정보 이미지를 보여주고, 자세히 보기를 누르면 다음 지도로 연결된다.
  • Roadview를 누르면, 자세히 보기 클릭시 GPS 위치의 Roadview를 보여주게 된다.
  • Alert은 아직 추가되지 않았지만, Alert을 누르면 아이에게 진동이나 알림음으로 알려주는 기능을 추가할 예정이다.


저작자 표시 비영리
신고
0 0
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' 카테고리의 다른 글

SKT LoRa 서비스의 보안 방식  (0) 2017.07.03
LoRa ID 체계 (App Key, App EUI, Dev EUI, LTID)에 대한 정리  (0) 2017.05.17
LoRa Class (A/B/C)  (0) 2017.02.07
0 0
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 ID 체계 (App Key, App EUI, Dev EUI, LTID)에 대한 정리  (0) 2017.05.17
LoRa Class (A/B/C)  (0) 2017.02.07
0 0
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일로 예정되어 있으며, 위 링크에서 신청하실 수 있습니다.

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


저작자 표시 비영리
신고
0 0
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' 강의도 준비되어 있습니다.



저작자 표시 비영리
신고
0 0
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'에서 확인할 수 있다.

저작자 표시 비영리
신고
0 0
IoT Open House/LoRa

 

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 기술 상 이슈로 아래 이미지에서는 노란색 중간중간 비워두었다.




저작자 표시
신고

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

SKT LoRa 서비스의 보안 방식  (0) 2017.07.03
LoRa ID 체계 (App Key, App EUI, Dev EUI, LTID)에 대한 정리  (0) 2017.05.17
LoRa Class (A/B/C)  (0) 2017.02.07
0 0
IoT/WiFi

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


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


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



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

http://wiznetacademy.com/



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


저작자 표시
신고

'IoT > WiFi' 카테고리의 다른 글

SKT ThingPlug 더 쉽게 시작하기(embedded WiFi)  (0) 2017.02.07
0 0
1
블로그 이미지

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

1byte