MQTT 프로토콜이 BLE를 통한 센서 판독 값 전송에 적합합니까?


12

통신 수단으로 BLE에 의존하는 수많은 약한 센서 (예 : Arduino 레벨 장치)가 있고이 장치가보다 강력한 게이트웨이 (예 : Raspberry pi 레벨 장치)에 연결되어 있다고 가정합니다.

MQTT가 판독 값 (짧고 빈번한 메시지)을 전송하는 데 적합한 프로토콜로 간주되는지 알고 싶습니다.

다수의 블로그 / 문서는 MQTT가 HTTP와 비교할 때 무게가 가볍고 전력을 보존하기 때문에 "IoT 애플리케이션"에 적합한 것으로 간주합니다. 그러나 이해하기 위해서는 BLE 또는 IoT에 적합한 다른 통신 프로토콜의 경우가 아닌 연결을 열어 두어야합니다. BLE는 에너지를 예약하기 위해 오랫동안 연결을 개방 상태로 유지하지 않습니다. WiFi와 같은 MAC 계층 프로토콜을 사용하는 경우 MQTT가 적합합니다. 이로 인해 MQTT를 처음 사용할 때의 이론적 근거가 거의 깨집니다 (즉, 디바이스가 WiFi와 같은 프로토콜을 계산 가능하게 처리하는 경우 MQTT와 같은 프로토콜이 필요하지 않을 수 있음). 이 논리에 결함이 있습니까?

해당 목적을위한 대체 응용 계층 프로토콜이 있습니까? 게이트웨이와 통신 할 때와 서버와 직접 통신 할 때 이러한 유형의 메시지 (예 : 원시 이진 데이터, JSON, XML)에서 가장 자주 보이는 구조는 무엇입니까?


네이티브 BLE 메커니즘이 특정 이유로 부적절합니까?
Sean Houlihane

Sean의 질문은 두 부분으로 나눌 수 있습니다. A) 장치에서 즉시 연결하는 데 사용할 수있는 기본 BLE 프로토콜 메커니즘이 있으며 B) 데이터가 궁극적으로 어디로 가야합니까? 파트 B에 대한 답변이 BLE 범위를 벗어나면 브리지 (적어도 무선 형식 사이이지만 프로토콜도 가능)가 필요합니다.
Chris Stratton

게이트웨이가 원시 판독 값을 소비하거나 단순히 릴레이 하는가? 그런 맥락에서 게이트웨이에서 BLE 기본 브리지를 MQTT로 브리지하는 대신 MQTT를 엔드 투 엔드로 터널링하는 것이 이치에 맞습니까?
Sean Houlihane

답변:


14

MQTT는 TCP / IP를 통해 실행해야합니다 (실제로 사양에 있는지 또는 충분한 가정이 이루어진 경우 는 기억 나지 않습니다 ). 자매 프로토콜 MQTT-SN 은 데이터를 전달할 수있는 거의 모든 프로토콜에서 실행될 수 있습니다. UDP 및 직렬 구현을 보았습니다.

BLE를 통해 실행하여 얻는 것이 확실하지 않다고 말했지만, BLE의 기본 제공 특성은 알림과 같은 것들과 동일한 이점을 많이 제공합니다 (1 ~ 1 기준).

기억해야 할 중요한 것 중 하나는 IoT에서 "I"의 약자라고 생각합니다. 게이트웨이 장치 나 전화 인 경우에도 인터넷에 액세스하는 것을 의미합니다. 이 시점에서 MQTT는 매우 유용 할 수 있지만 반드시 (블리딩) 가장자리까지가는 것은 아닙니다.


우선 MQTT-SN의 존재에 대해 알려 주셔서 감사합니다. 대부분의 문헌은 MQTT가 전력 절약 속성으로 인해 에지 장치에 권한을 부여한다는 것을 암시하므로 다소 오해의 소지가 있습니다. 이 경우 전력 소비 감소는 그다지 중요한 논거가 아닙니다. 그 프로파일을 가진 장치에서는 단순히 문제가되지 않기 때문입니다. 디바이스는 전체 IP 스택을 구현해야하며 MQTT는 열린 연결을 유지하므로 에너지 효율적인 MAC 계층 프로토콜은 옵션이 아닙니다.
dr.doom

1
개방형 TCP 연결은 TCP 스택을 이미 실행 한 후에도 개방 상태를 유지하는 데 실제로 많은 전력을 소비하지 않으며 연결 유지 패킷이 작기 때문에 MQTT는 HTTP와 비교하여 전력을 절약합니다. 또한 HTTPTT가 MQTT 패킷 헤더에 비해 크기 때문에 프로토콜 오버 헤드가 HTTP보다 훨씬 낮습니다. 많은 계산 문헌은 휴대폰과 같은 셀룰러 장치를 기반으로합니다
hardillb

또한, 에지가 이동, 이는 TCP / IP는, BLE와 (특히 lpwan)와 지그비에도 저전력 프로세서 같은 것들도 얇은 장치에 이동 한 정지 위치를 예전
hardillb

그것은 명시 적입니다 하지 단지 TCP / IP; 유일한 요구 사항은 프로토콜이 "순 서적, 무손실 양방향 연결"을 제공해야한다는 것입니다. 그것은 문서 초록의 두 번째 단락과 같습니다. SN은 소규모 시스템, 특히 무선 기반 시스템에 대한 요구 사항이 까다롭기 때문에 존재합니다. 어쩌면 그것은 "충분히 가정하기에 충분한 가정"이라는 의미 일 것입니다. 그러나 TCP / IP에 의존하지 않는 것이 가장 확실합니다.
Dave Newton

9

말 그대로, BLE를 통해 문자 그대로 MQTT를 보내려고하는 대신 BLE 패러다임에서 MQTT로 데이터를 간단히 맵핑하는 것이 좋습니다.

BLE는 일반적으로 특성 의 형태로 데이터를 교환합니다 . 여기에는 유용한 값 변경을 발견하기위한 다양한 BLE 고유 메커니즘이 있습니다. 그러나 최대 데이터 길이는 20 바이트 입니다.

시간에서 20 바이트를 이동 BLE 통해 직렬 데이터 스트림. 이는 때때로 가상 직렬 포트를 구현하기 위해 수행되며이를 통해 전체 MQTT를 터널링 할 수 있습니다.

그러나 여러 주제의 데이터를 전달하기 위해 BLE 특성 콜렉션을 사용하고 특성 ID 를 MQTT 주제에 맵핑하고 을 MQTT 페이로드에 맵핑하는 브릿지를 사용하는 것이 좋습니다 .

BLE는 지속적으로 연결된 세션과 연결되지 않은 세션에 대한 자체 감각을 가지고 있습니다. 응용 프로그램에 가장 적합한 BLE 사용법을 파악한 다음이를 연결 유지 보수의 MQTT 감각에 맵핑해야합니다.

BLE-> MQTT 및 MQTT-> BLE 중 하나 또는 두 방향으로이를 수행 할 수 있어야합니다.


5
MQTT 2 BLE 브리지를 원한다면 내 github.com/hardillb/mqtt2ble
hardillb를 참조하십시오.

해당 링크에 대해 감사합니다. 지금 살펴보고 있습니다.
dr.doom
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.