02. 사물인터넷 통신 프로토콜

 

1. 개요

IoT는 스마트 홈/시티/팩토리/팜, 자율주행, 피트니스 트래커, 리테일, 헬스 케어 등을 가능하게 만드는 포함된 시스템, 무선 센서 네트워크, 제어 시스템, 자동화가 수렴된 것입니다.

 

IoT 기술은 수많은 서비스 공급 기업, 다양한 플랫폼, 매년 출현하는 수백만 개의 새로운 디바이스를 통해 계속 확장되고 있습니다.

 

본 내용은 전반적인 IoT 프로토콜에 관한 내용을 다룹니다. IoT에 관한 기본적인 내용은 아래의 이전 글을 참고 바랍니다.

 

01. 사물인터넷(Internet Of Things, IoT)

 

2. 프로토콜 및 연결

IoT 기기간 게이트웨이 또는 기본 기능을 통해 연결을 하고 프로토콜에 따라 통신을 합니다.

 

1) IoT 게이트웨이

게이트웨이는 IoT 디바이스를 클라우드에 연결하는 데 사용할 수 있는 IoT 기술의 일부입니다. 모든 IoT 디바이스에 게이트웨이가 필요하지는 않지만, 게이트웨이를 사용하여 디바이스 간 통신을 설정하거나 IP 기반이 아니고 클라우드에 직접 연결할 수 없는 디바이스를 연결할 수 있습니다. IoT 디바이스에서 수집된 데이터는 게이트웨이를 통해 이동하고 에지에서 전처리된 후 데이터베이스 또는 클라우드로 전송됩니다.

 

IoT 게이트웨이를 사용하면 대기 시간이 짧아지고 전송 크기를 줄일 수 있습니다. 또한 IoT 프로토콜의 일부로 게이트웨이를 사용하면 직접 인터넷에 액세스하지 않고 디바이스를 연결할 수 있으며 양방향으로 이동하는 데이터를 보호하여 추가 보안 계층을 제공할 수 있습니다.

 

2) IoT 디바이스는 네트워크로의 연결

IoT 프로토콜의 일부로 사용하는 연결 형식은 디바이스, 해당 기능, 해당 사용자에 따라 다릅니다. 일반적으로 데이터가 이동해야 하는 거리(단거리 또는 장거리)가 필요한 IoT 연결 형식을 결정합니다.

 

3) IoT 네트워크 유형

- 저전력, 단거리 네트워크

 ∙  가정, 사무실, 기타 소규모 환경에 적합합니다. 이 네트워크는 소형 배터리가 필요한 경향을 보이며 일반적으로 작동 비용이 저렴합니다.

네트워크	설명
Bluetooth	고속 데이터 전송에 적합한 Bluetooth는 음성 및 데이터 신호를 최대 10미터까지 전송
NFC	4cm(1.5인치) 이하의 거리에서 두 전자 디바이스 간에 통신할 수 있게 해주는 통신 프로토콜 세트입니다. NFC는 더 강력한 무선 연결을 부트스트랩하는 데 사용할 수 있는 간단한 설정으로 저속 연결을 제공
WiFi/802.11	Wi-Fi는 작동 비용이 저렴하여 가정과 사무실에서 표준이 되었음그러나 범위가 제한되어 있고 연중무휴로 에너지를 소비하기 때문에 모든 시나리오에 적합하지는 않을 수도 있음
Z-Wave	저에너지 전파를 사용하여 어플라이언스 간에 통신하는 메시 네트워크임
Zigbee	소형 저전력 디지털 라디오를 사용하여 개인 영역 네트워크를 만드는 데 사용되는 고급 통신 프로토콜 모음에 대한 IEEE 802.15.4 기반 사양임

 

- 저전력 광역 네트워크(LPWAN)

 ∙  최소 500미터 범위에서 통신할 수 있게 해주며 최소한의 전력이 필요하고 대부분 IoT 디바이스에 사용됩니다.

네트워크	설명
4G LTE IoT	높은 용량과 짧은 대기 시간을 제공하는 이 네트워크는 실시간 정보나 업데이트가 필요한 IoT 시나리오에 적합함
5G IoT	아직 사용할 수 없지만, 5G IoT 네트워크는 지정된 지역에서 더 많은 디바이스에 훨씬 더 빠른 다운로드 속도와 연결을 제공하여 IoT 분야에서 더 많은 혁신을 이뤄낼 수 있게 해줄 것으로 예상됨
Cat-0	이 LTE 기반 네트워크는 가장 저렴한 비용 옵션으로 2G를 대체할 기술인 Cat-M의 토대를 마련함
Cat-1	셀룰러 IoT에 대한 표준으로 궁극적으로 3G를 대체합니다. Cat-1 네트워크는 설정하기 쉬우며 음성 또는 브라우저 인터페이스가 필요한 애플리케이션에 적합한 솔루션을 제공함
LoRaWAN	LoRaWAN(장거리 광역 네트워크)은 배터리로 작동하는 양방향 보안 모바일 디바이스를 연결함
LTE Cat-M1	이 네트워크는 LTE 네트워크와 완전히 호환되며 IoT 애플리케이션용으로 특별히 설계된 2세대 LTE 칩에서 비용과 전력을 최적화함
협대역 또는 NB-IoT/Cat-M2	NB-IoT/Cat-M2는 DSSS(직접 시퀀스 확산 스펙트럼) 변조를 사용하여 서버에 직접 데이터를 보냄으로써 게이트웨이의 필요성을 없애줌. NB-IoT 네트워크를 설정하는 데 비용이 더 많이 들지만, 게이트웨이가 필요하지 않아 실행 비용은 더 저렴함
Sigfox	이 글로벌 IoT 네트워크 공급 기업은 연속 데이터를 내보내는 저전력 개체를 연결할 수 있는 무선 네트워크를 제공함.
UWB	군사용 레이더 및 원격 탐지용 주파수에 대한 상업적 이용을 허용하며 근거리 광대역 통신 기술로 표준화 되어 있음.

 

- 사물인터넷 전용

네트워크	설명
기본 특징	∙ 빠른속도가 아님 ∙ 속도를 늦추면 출력이 낮아지고, 배터리 수명이 늘어나며, 칩과 기기 가격도 낮아짐 ∙ 이를 토대로 속도를 늦춤으로써 저전력 소모, 장거리 전송, 낮은 구축 비용, 대규모 단말기 접속을 구현함
LoRa	∙ 장거리 통신에 장점 ∙ 상위 계층에서 배터리 수명과 용량, QoS를 결정짓는 프로토콜과 구조를 가짐 ∙ 기기간 동기를 맞추거나 채널에 대한 모니터링이 필요가 없음 ∙ Sensitivity 특성이 좋아 잡음에 강하고 넓은 범위를 갖음 ∙ 전력소모가 적어 원격검침이나 화재 알림 등에 사용 가능 ∙ 지연율과 배터리 수명의 트레이드오프 관계에 따라 A, B, C 클래스로 나뉨 : 각 클래스는 분류A가 가장 긴 배터리 수명을 가지나 uplink 전송만 가능하고 C는 downlink 전송 가능하나 배터리 수명이 짧음
LTE-M	∙ 3GPP에서 표준화함 ∙ 150KBps 이하의 데이터 전송 속도와 8km이상의 장거리 서비스를 지원 ∙ 이동통신사가 구축한 LTE망을 그대로 활용 가능 ∙ LTE를 사용하기에 짧은 시간에 저용량 데이터를 송수신할 수 있어 기존 트래픽 처리에 영향을 받지 않음

 

 

3. IoT 프로토콜

IoT 기기는 IoT 프로토콜을 사용하여 통신합니다. IP(인터넷 프로토콜)는 데이터가 인터넷으로 전송되는 방식을 지정하는 규칙 집합입니다. IoT 프로토콜은 한 기기 또는 센서의 정보를 다른 기기, 게이트웨이, 서비스에서 읽고 인식하도록 합니다. 다양한 시나리오 및 사용을 위해 다양한 IoT 프로토콜이 설계 및 최적화되었습니다. 다양한 IoT 기기를 사용할 수 있는 경우 적절한 컨텍스트에서 적절한 프로토콜을 사용하는 것이 중요합니다.

모든 인터넷 네트워크는 기술 스택입니다. 장치를 물리적으로(같은 위치에 있는 장치 또는 라우터에) 연결하고, 논리적 주소를 할당하고, 네트워크를 통해 데이터를 라우팅하고, 클라이언트 측에서 데이터 교환을 관리하는 기술이 있습니다.

 

표준화 및 프로토콜 구현을 위해 이러한 기술은 서로 다른 계층에 배치됩니다. 일반적인 인터넷 네트워크는 인터넷에 대한 ISO 표준 모델인 OSI(Open Systems Interconnection) 모델을 따릅니다. OSI 모델 아키텍처는 인터넷을 물리적, 데이터 링크, 네트워크, 전송, 세션, 프레젠테이션 및 애플리케이션의 7개 계층으로 구성합니다. OSI 모델의 실제 구현은 7 계층 OSI 모델을 4 계층 인터넷 프로토콜 제품군으로 단순화하는 TCP-IP 모델을 통해 수행되지만. TCP-IP 모델(OSI 모델의 실제 구현)에서는 물리적 및 데이터 링크 계층이 병합되어 물리적 및 네트워크 액세스 계층을 형성하고 OSI 모델의 세션, 프레젠테이션 및 응용 프로그램 계층이 단일 응용 프로그램 계층으로 병합됩니다.

 

필요한 IoT 프로토콜 유형은 데이터가 이동하는 시스템 아키텍처 계층에 따라 다릅니다. OSI모델은 데이터를 보내고 받는 다양한 계층의 맵을 제공합니다. IoT 시스템 아키텍처의 각 IoT 프로토콜은 디바이스 간, 디바이스 및 게이트웨이 간, 게이트웨이 및 데이터 센터 간 또는 게이트웨이 및 클라우드 간 통신과 데이터 센터 간 통신을 가능하게 합니다.

계층	기능	프로토콜 종류
Application	지정된 IoT 프로토콜 내에서 사용자와 디바이슨 간 인터페이스 역할	AMQP, CoAP, MQTT, DDS
Transport	데이터가 계층 간에 이동할 때 데이터의 통신을 가능하게 하고 보호	TCP, UDP
Network	개별 기기가 라우터와 통신하는 데 도움을 줌	IP, 6loWPAN
Datalink	시스템 아키텍처 내에서 데이터를 전송하여 물리적 계층에서 발견된 오류를 식별하고 수정	IEEE 802.15.4, LPWAN
Physical	특정 환경 내의 디바이스 간 통신 채널	BLE, 이더넷, LTE, NFC, PLC, RFID, WiFI/802.11, Z-Wave, Zigbee

 

이중에서 Application에서 사용되는 프로토콜을 살펴보겠습니다.

 

 

4. HTTP(HyperText Transfer prototcol)

 

HTTP 는 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)의 약자로, 사용자가 월드 와이드 웹에서 데이터를 통신할 수 있도록 하는 분산, 협업, 하이퍼미디어 정보 시스템용 애플리케이션 프로토콜입니다.

 

작동 방식은 다음과 같습니다. 처음에는 클라이언트가 서버에 SYN 패킷을 보낸 다음 웹 서버가 SYN-ACK 패킷으로 응답하여 수신 성공을 확인합니다. 그런 다음 클라이언트는 다시 ACK 패킷을 전송하여 연결 설정을 완료하며, 이를 일반적으로 3방향 핸드셰이크라고도 합니다. 또한 클라이언트는 리소스에 대한 HTTP 요청을 서버에 보내고 요청에 응답할 때까지 기다립니다. 그런 다음 웹 서버는 요청을 처리하고 리소스를 찾은 다음 클라이언트에 응답을 보냅니다. 클라이언트에 더 이상 리소스가 필요하지 않으면 FIN 패킷을 전송하여 TCP 연결을 닫습니다.

장점

- 검색 기능: HTTP는 간단한 메시징 프로토콜이지만 단일 요청으로 데이터베이스를 검색할 수 있는 기능을 포함함. 이를 통해 프로토콜을 사용하여 SQL 검색을 수행하고 HTML 문서에서 편리하게 형식화된 결과를 반환할 수 있음 - 프로그래밍 용이성: HTTP는 일반 텍스트로 코딩되므로 조회가 필요한 코드를 사용하는 프로토콜보다 따르고 구현하기가 더 쉬움. 데이터는 변수 또는 필드의 문자열이 아닌 텍스트 줄로 서식이 지정됨 - 보안: HTTP 1.0은 독립 연결을 통해 각 파일을 다운로드한 다음 연결을 닫음. 따라서 전송 중 가로채기의 위험을 크게 줄일 수 있음

단점

- 소형 장치에 적합하지 않음: 무선 센서와 같은 소형 장치는 많은 상호 작용이 필요하지 않고 전력을 거의 소비하지 않으므로 HTTP는 너무 무거워서 이러한 장치에 적합하지 않음. HTTP 요청에는 최소 9개의 TCP 패킷이 필요하며, 연결 불량으로 인한 패킷 손실을 고려하면 훨씬 더 많으며 일반 텍스트 헤더는 매우 장황해질 수 있음 - 이벤트 기반 통신용으로 설계되지 않음: 대부분의 IOT 애플리케이션은 이벤트 기반임. 센서 장치는 온도, 공기 질과 같은 일부 변수를 측정하며 스위치 끄기와 같은 이벤트 기반 결정을 내려야 할 수 있음. HTTP는 이벤트 기반 통신이 아닌 요청-응답 기반 통신을 위해 설계되었음. 또한 HTTP 프로토콜을 사용하여 이 이벤트 기반 시스템을 프로그래밍하는 것은 특히 센서 장치의 제한된 컴퓨팅 리소스로 인해 큰 도전이 됨. - 실시간 문제: 서버에 리소스를 요청한 후 클라이언트는 서버가 응답할 때까지 기다려야 하므로 데이터 전송 속도가 느려짐. IOT 센서는 컴퓨팅 리소스가 매우 제한된 소형 장치이므로 동기식 방식으로 효율적으로 작동할 수 없음. 널리 사용되는 모든 IOT 프로토콜은 비동기 모델을 기반으로 함

 

 

5. CoAP(Constrained Application Protocol)

IETF에서 개발한 CoAP은 저전력 센서로 구성되는 IoT 네트워크에서 메시지 전송에 적합합니다.

 

CoAP은 UDP 기반으로 설계되었으며, 다음 그림처럼 클라이언트-서버 모델에 따라 클라이언트가 정보를 요청하면 서버가 응답하는 구조입니다. 요청/응답 계층은 통신 방법과 관련이 있으며 요청/응답 메시지를 처리합니다.

 

CoAP과 HTTP는 모두 REST 구조를 따르며 동시에 사용될 수 있습니다. 즉, 인터넷 망에서는 HTTP를 사용하고 IoT 센서로 구성되는 제한된 접속망에서는 CoAP를 사용합니다. CoAP은 일반적으로 UDP 위에서 동작하며, HTTP는 TCP 위에서 동작합니다.

장점	- 간단한 프로토콜이며 UDP를 통한 작업으로 인해 오버헤드를 덜 사용합니다. 이로 인해 긴 배터리 수명을 가짐 - IPSEC(IP 보안) 또는 DTLS(데이터그램 전송 계층 보안)를 사용하여 보안 통신을 제공함 - CoAP 프로토콜에서는 동기 통신이 필요하지 않음 - HTTP에 비해 대기 시간이 짧음 - 불필요한 재전송을 방지하여 HTTP보다 전력을 덜 소비 - CoAP 프로토콜은 홈 통신 네트워크에 가장 적합한 프로토콜 선택으로 사용됨
단점	- CoAP는 UDP를 사용하기 때문에 신뢰할 수 없는 프로토콜이므로 CoAP 메시지는 순서가 지정되지 않은 상태로 도달하거나 대상에 도착할 때 손실됨 - 각 메시지 수신을 확인하므로 처리 시간이 늘어나며, 수신된 메시지가 제대로 디코딩되었는지 여부를 확인하지 않음 - MQTT와 같은 암호화되지 않은 프로토콜이며 DTLS를 사용하여 구현 오버헤드를 희생하면서 보안을 제공함 - CoAP는 NAT(Network Address Translation) 뒤에 있는 디바이스에 대한 통신 문제가 있음

 

 

6. MQTT(Message Queuing Telemetry Transport)

가장 널리 사용되는 프로토콜인 MQTT는 서로 다른 디바이스 간에 데이터를 거래하기 위해 출판/구독 모델을 사용합니다. 이 모델에서 장치는 생산자(Publisher), 소비자(Subscriber) 및 브로커(중개)의 세 가지 유형으로 나뉩니다. 생산자는 토픽이라는 이름으로 데이터를 출판합니다. 토픽은 기본적으로 생산자가 관련 데이터를 출판할 수 있는 채널입니다. 그러면 해당 특정 채널을 구독하는 소비자 장치가 메시지를 수신합니다. 생산자에서 구독자로의 전체 데이터 전송은 브로커의 도움으로 가능합니다. 브로커는 생산자로부터 메시지를 수신한 다음 지정된 주제로 필터링하고 각 주제에 대해 구독자와 공유합니다.

 

MQTT는 TCP/IP 프로토콜을 사용하여 여러 디바이스 간의 통신을 활성화합니다. 산업 수준 제품에 이상적인 이유는 여러 장치 간의 메시지 송수신을 단순화한다는 것입니다. 의위 그램은 스마트 습도 센서의 예를 사용하여 MQTT의 데이터 트랜잭션 모델을 보여줍니다. 이 예에서 가습기는 별도의 주제로 브로커에 데이터를 출판하는 생산자입니다. 따라서 생산자는 브로커에 데이터를 출판하고 브로커는 구독자에게 데이터를 출판합니다.

 

 

7. XMPP(Extensible Messaging and Presence Protocol)

XMPP는 인스턴트 메시징 통신 프로토콜로 시작했지만 곧 IoT 프로토콜로 발전했습니다. XML 기반 서버/클라이언트 모델 프로토콜입니다. 클라이언트는 XMPP 서버에 연결하여 통신합니다. 서버는 클라이언트 간의 통신 세션을 용이하게 합니다. 통신 매체가 XML에 있기 때문에 전송되는 데이터의 크기를 줄이고 트랜잭션을 더 빠르게 만듭니다.

 

그러나 XMPP에는 엔터프라이즈급 IoT 애플리케이션에 이상적인 솔루션이 아닌 몇 가지 단점이 있습니다. 우선, XMPP에는 CoAP와 달리 서비스 품질 기능이 없어 신뢰할 수 없습니다. 둘째, 종단 간 암호화가 없어 민감한 데이터 전송에 안전하지 않습니다.

 

 

8. DDS(Data Distribution Service)

DDS는 MQTT와 유사하지만 더 좋습니다. 출판/구독 모델을 따르지만 장치 간 데이터 트랜잭션을 위해 브로커가 필요하지 않습니다. 또한 멀티캐스팅 및 서비스 품질도 지원하므로 산업 수준 제품에서 사용하기에 이상적입니다. OMG(Object Management Group)는 확장성을 염두에 두고 DDS를 처음 설계했습니다. 따라서 브로커 없는 모델은 확장성이 뛰어나고 변화하는 요구 사항에 적응할 수 있습니다.

 

DDS 아키텍처는 데이터 중심 출판/구독 계층(DCPL)과 선택적 DLRL(data-local reconstruction layer)로 구성됩니다. 확장성, 리소스 인식 및 빠른 속도의 데이터 배포는 DCPL 계층의 도움으로 보장되며, DLRL 계층은 DCPL 계층의 운영을 위한 인터페이스를 제공합니다.

 

실시간 시스템의 실시간성(real-time), 규모가변성(scalable), 안전성 (dependable), 고성능 (high performance)를 가능하게 합니다. DDS는 금융거래, 항공 교통관제, 스마트 그리드 관리, 산업자동화 시스템등의 mission critical 애플리케이션을 위해 디자인되었다. 과거에는 국방, 항공 우주산업에 제한적으로 사용되었지만, 현재는 다양한 분야의 지능화 시스템 (Intelligent System)에 사용되는 사례가 늘어나고 있습니다.

 

 

9. AMQP(Advanced Message Queuing Protocol)

AMQP는 주로 트랜잭션 완료 보장에 중점을 둔 또 다른 출판/구독 모델 기반 프로토콜입니다. 2003년에 설계되었으며 명백한 이유로 주로 금융 부문에서 사용되었습니다. AMQP는 고급 대기열 및 배포 기술을 사용하여 보안, 안정성 및 속도를 보장합니다.

 

게시자는 미리 지정된 라우팅 키를 메시지에 첨부하여 AMQP 브로커에 메시지를 게시합니다. 브로커는 라우팅 키를 사용하여 지정된 사용자에게 배달할 메시지를 대기열에 넣습니다. 이러한 메시지는 바인딩을 통해 교환에 바인딩됩니다. 그러나 AMQP 모델에는 IoT 공간에서의 대량 채택을 제한하는 몇 가지 단점이 있습니다. 우선, 대역폭과 전력이 부족한 더 작은 IoT 장치에 적합하지 않은 무거운 프로토콜입니다. 둘째, 메시지 전달 보장이 모든 IoT 프로젝트에서 항상 높은 우선 순위는 아닙니다.

 

10. 적합한 IoT 프로토콜?

IoT는 하드웨어뿐만 아니라 소프트웨어 측면에서도 프로젝트마다 요구 사항이 많이 달라집니다. 예를 들어, 내부 조명 시스템에는 클라우드와의 연결이 필요할 수 있지만 다른 유사한 조명 시스템에는 보다 현지화된 솔루션이 필요할 수 있습니다. 일부 프로젝트에서는 확장성과 속도가 최우선 순위인 반면, 다른 프로젝트에서는 트랜잭션 완료 보장과 보안에 중점을 둘 수 있습니다. 이전 섹션에서 설명한 것처럼 프로토콜은 이러한 요구 사항을 용이하게 하는 데 중요한 역할을 합니다. 하드웨어가 본체라면 프로토콜은 장치의 두뇌입니다.

 

이를 염두에 두고 프로젝트 요구 사항에 대한 자세한 감사 및 검토를 수행하는 것이 좋습니다. 이와 관련하여 고려해야 할 사항은 다음과 같습니다.

 

1. HTTP의 모든 장점과 함께 RESTful 프레임워크를 사용하는 것이 프로젝트의 주요 요구 사항이라면 CoAP를 사용할 수 있습니다. CoAP는 HTTP의 모든 기능과 함께 UDP 및 메시지 레이블링이 제공하는 추가 속도 및 안정성을 제공합니다.

 

2. IoT 디바이스에 주요 배터리 관련 제약 조건이 있고 경량 프로토콜이 필요한 경우 MQTT가 프로젝트에 더 적합합니다. 단, MQTT는 지연 시간 문제로 어려움을 겪을 수 있습니다.

 

3. 프로젝트가 데이터 집약적이고 여러 장치 간에 빠른 메시지 트랜잭션이 필요한 경우 XMPP를 고려할 가치가 있는 프로토콜일 수 있습니다. 그러나 XMPP에는 보안 기능이 내장되어 있지 않으므로 데이터 보안을 고려하지 않는 경우 사용이 가능합니다. 프로젝트에서 XML을 사용하는 경우 XMPP를 사용해야 합니다.

 

4. 작업 중인 것이 자율 주행 자동차 및 스마트 항공 교통 관제 시스템에 사용되는 것과 같은 대규모 고성능 센서 네트워크인 경우 DDS가 이상적인 선택일 것입니다. 그러나 프로토콜을 선택하기 전에 실사가 필요하며 이러한 고급 프로젝트를 다룰 때는 더욱 그렇습니다. DDS는 헤비급 프로토콜이며 장치가 작동하려면 적절한 배터리 수명과 대역폭이 필요합니다.

 

5. AMQP는 전력 소비에 대한 걱정 없이 데이터 집약적인 작업을 처리할 수 있는 중공업 기계와 같은 엔드 투 엔드 애플리케이션인 프로젝트에 고려할 수 있는 프로토콜입니다. 트랜잭션 완료가 프로젝트에 절대적으로 필요한 경우 AMQP는 가장 신뢰할 수 있는 프로토콜입니다.

 

 

1. https://swingswing.tistory.com/142

2. https://blog.naver.com/PostView.nhn?blogId=lghmms&logNo=222105220159

3. https://azure.microsoft.com/ko-kr/solutions/iot/iot-technology-protocols

4. https://fishpoint.tistory.com/6473

5. https://www.daviteq.com/blog/en/what-are-the-most-popular-iot-protocols/

6. https://www.opensourceforu.com/2022/02/choose-the-most-optimal-iot-protocol-for-your-project/

7. https://hashstudioz.com/blog/top-iot-communication-protocols/

8. https://chloe-codes1.gitbook.io/til/network-2/03_tcp_ip