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/


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을 누르면 아이에게 진동이나 알림음으로 알려주는 기능을 추가할 예정이다.


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
1 2 3 4 5 6 7 8 ··· 14
블로그 이미지

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

1byte