LoRa - IOT4
LoRa - IOT4
1. End Device Activation
End node와 network server 사이에 주고 받는 key값들이 필요하고 등록도 필요하다. 이러한 방법들에 대해 생각해야 한다.
1) Information keys ( 중요 key 로는 아래의 key들을 둘 수 있다.)
-
Application Identifier (App EUI)
-
Globally unique end-device
identifier (Dev EUI)
-
Device Address (DevAddr)
-
Authentication with Application
key (App key)
-
Network Session Key ( NwkSkey)
-
Application Session Key (AppSkey)
위의 이러한 부분들이 server에 잘 등록이 되어 있어야 network server와 device들이 잘 통신을 할 수 있다.
Session Key 와 Application
Key를 기반으로 만들기 때문에 이중 App Key가 제일 중요한 정보이다.
이부분들을 1.0.2 버전의 스펙을 따르고 있기 대문에 1.1 스펙에선 용어가 조금씩 바뀜을 유의 해야 한다.
2) Provisioning
Make App key Based on DevEUI and AppEUI and share the key
Provisioning 같은 경우에는 DevEUI, AppEUI, 그리고 AppKey를 공유(share)하고 있어야 한다. 이런 Provisioning 과정을 개통 단계라고 한다. 어떤 network를 사용하더라도 이런 부분들을 등록하고 적용하는 과정 필요하다.
3) 통신방법
Provisioning까지 마친 network는 통신을 할 수 있는 상태가 된다.
LoRaWAN의 경우 network server와 device server 간에 통신하는
방법을 두가지 제공 해 준다.
(1)
ABP 모드 (Activation By Personalization)
shared keys (Device Address, NwkSKey, AppSkey) stored at at production time.
Locked to a specific network
ABP 모드는 개발자
모드이다.
Device Address, NwkSkey, AppSKey들이 server와 개발자 간에 서로 공용된 key값을 이용해서 server가 "어느 device에서 온 누구다" 라는 것을 바로 알 수 있는 상태 이다. device는
자신의 소개 없이 application data를 바로 전송을 하면 server에서 그 data를 바로 알아보고 처리하는 그러한 과정이다.
(2)
OTAA 모드 (Over-the-air Activation)
Based on Globally Unique Identifier
Over the air message handshaking
우리가
흔히 protocol에서 사용하는 모드로 "내가 누구다" 라는 것을 server에게 알려주는데, 그러면 server가 "어 누구냐 그럼 너는 Device address를 이걸 써라" 라고 알려준다. 그다음에는 device에서는 해당하는 device address와 booting할 때 마다 만들어진 key를 이용해서 server와
송수신을 하는 그런 모드이다.
(3) ABP 모드와 OTAA 모드 정리
ABP 모드인 경우에는 개발자 모드라고 한 이유가 해킹에 취약한 모드이다. key들을 서로 공유 하고 있고 바꾸지 않기 때문에 언제든지 노출이 될 수 있는 상태여서 이러한 모드는 잘
사용하지 않는다.
실질적으로는 OTAA를 통해서 헤킹에 노출되지 않도록 하는 방법을 사용하고
있다.
2. LoRaWAN OTAA Join Procecure
OTAA 에는 Device가 sever에 "내가 누구다" 라고 하는 것을 알리는 과정이 있다. 이것을 Join Procedure이라고 이야기 한다.
End Device Mac layer : LoRaWAN slave layer
Network Server : LoRAWAN master layer
application layer에서 start가
일어 나면 LoRaWAN Device에서 Dev EUI, App EUI,
Dev Nonce, App Key를 전송 한다.
Dev EUI, App EUI, AppKey는 Network Server에서 똑같이 가지고 있다. 그래서 어느 Device에서 왔다는 것을 network server가 안다.
Dev
EUI, App EUI, Dev Nonce, App Key 값이 전송이 되면 network server는 App server에 join request가 왔다고 Indication(Ind)을 해도 되고 하지
않아도 된다. 필수가 아니다.
join Request는 incoding 되지 않은 data 이다.
LoRa Device에서 network로 data를 전송할 때 유일하게 incoding 되지 않은 data가 join request message이다.
network sever는 message가 왔을 때 App Key로 message를 incoding 해서
response를 보내는데 이를 join Accept 과정이라고
한다.
End Device MAC Layer에서 이것을 AppKey로 복호화 해서 indication을 알려줘도 되고 알려주지 않아도 된다.
실질적으로 AppSkey와 NwkSKey가
만들어 진다.
이 이후 부터는 AppSkey와 NwkSkey를
이용하여 데이터를 암호화 하여 전송하게 된다.
3. LoRAWAN Data Flow
1) Application Message Flow
End Device App Layer는 sensor data(센서 데이터)를 얻어와서 data를
End Device Mac Layer를 통해서 App Server 까지
전송을 해야 한다.
먼저 Application Message 생성
Mac Layer에 전송 요청한다. -> Mac Layer는 AppSKey로 data를 암호화 한다.-> 이것을 network server에 전송을 하면 이를 application server에 전송한다. -> application server는
이제 AppSKey로 message를 복호화 해서 어떤 data가 들어왔다는 것을 알게된다.
어플리케이션 메시지
flow
2) Network Message Flow
Network message는
End Node와 network sever 간에 data를 잘 주고 받을 수 있는 방법을 논의 하는 message 이다. End Node가 data를 보냈는데 network server가 데이터를 잘 못받는 경우가 발생한다.
이런 경우 network server가 그걸 판단해서 End Node의 data bit rate를 낮추라고 하거나 너무 자주 들어오면 data bit rate를 높여서 다른 것은 사용
하지 말라고 하거나 여러가지 message들을 주고 받을 수 있다.
End node와
network server간에 data를 주고 받는다. 이런 경우 NwKSkey로 message를 암호화 또는 복호화 한다.
End node Mac Layer와
Network Sever 간에 Network message를
주고 받을 때에는 주로 request Mac Commend라는 용어를 사용한다.
NwKsKey로
메시지를 암호화 또는 복호화 하는데 End Node에서 또한 이것을 NwkSKey를 통해 암호화 복호화를 해서 응답 주고 받는다. 만약 반대로 end node에서
요청을 해도 네트웍 서버에서 응답을 주고 받을때 NwkSKey로 암호화 , 복호화 한다.
참고 :
서울 IoT 워크숍 LoRa 강의 05강
댓글
댓글 쓰기