17

Assume that there are numerous weak sensors (e.g., Arduino level devices) which rely on BLE as means of communication and that these devices are connected to a more powerful gateway (e.g., Raspberry pi level of devices).

I would like to know if MQTT is considered an appropriate protocol for transmitting their readings (short, frequent bursty messages).

A number of blogs/documents consider MQTT appropriate for "IoT applications" because it is light(er) weight when compared to HTTP and conserves power. However, to my understanding it requires a connection be be kept open which is not the case with BLE or other communication protocols appropriate for IoT. BLE does not maintain the connection open for prolonged periods of time to reserve energy. Apparently, MQTT is appropriate when a MAC layer protocol such as WiFi is used. This almost breaks the rationale behind using MQTT in the first place (i.e., if the device computably handles a protocol such as WiFi then it might not need a protocol such as MQTT). Do you see a flaw in this logic?

Is there any alternative application layer protocol for that purpose? What is the most frequently seen structure of these type of messages (e.g., raw binary data, JSON, XML) when they communicate with a gateway and when they communicate with a server directly?

Improve this question
3
  • 1
    Is the native BLE mechanism inappropriate for any particular reason?
    – Sean Houlihane
    Jul 20, 2017 at 13:10
  • Sean's question might be best split into two parts - A) are native BLE protocol mechanisms workable for the immediate link from the device, and B) where does the data ultimately need to go? If the answer to part B is beyond the range of BLE, then a bridge (at least between radio formats but probably protocols as well) is needed.
    – Chris Stratton
    Jul 20, 2017 at 14:51
  • Does the gateway consume the raw readings, or simply relay them, and in that context can it make sense to tunnel MQTT end-to end rather than bridge BLE native to MQTT at the gateway?
    – Sean Houlihane
    Jul 20, 2017 at 15:52

2 Answers 2

Reset to default
16

MQTT has to run over TCP/IP (I can't remember if it's actually in the spec or if just enough assumptions are made to make it so) but its sister protocol MQTT-SN can be run over nearly any protocol that can pass data, I've seen implementations in UDP and serial.

Having said that I'm not sure what you gain by running either over BLE, BLE's built in Characteristics offer much of the same benefit (if only on a 1 to 1 basis) with things like notification.

I think one of the important thing to remember is what the "I" stands for in IoT, it's implies access to the Internet at some point (even if it's a gateway device or phone). At that point MQTT can be very useful, but it doesn't necessarily mean all the way to the (bleeding) edge.

Improve this answer
4
  • First of all thanks for letting me know about the existence of MQTT-SN. The vast majority of literature is somewhat misleading because it implies that MQTT empowers the edge devices mostly due to its power-saving attributes. In that case reduced power consumption is not that much of a real argument because in devices with that profile it simply won't matter. The devices should implement a full IP stack and since MQTT maintains an open connection, energy-efficient MAC layer protocols are not an option.
    – dr.doom
    Jul 19, 2017 at 18:52
  • 1
    MQTT does save power in comparison to something like HTTP because an open TCP connection doesn't actually consume that much power to keep open once your already running a TCP stack, and the keep alive packets are tiny. Also the protocol overhead is much lower than HTTP because a HTTP header is huge compared to a MQTT packet header. A lot of the computation literature is based on a cellular device e.g. phone
    – hardillb
    Jul 19, 2017 at 19:15
  • Also the edge has moved, it used to be where TCP/IP stopped, things like ble and ZigBee (especially with lpwan) and even lower power processors have moved to even thinner devices
    – hardillb
    Jul 19, 2017 at 19:22
  • It's explicitly not just TCP/IP; the only requirement is that the protocol must provide "ordered, lossless, bi-directional connections". It's like the second paragraph of the doc's abstract. SN exists because that requirement is onerous for small systems, particularly radio-based ones. Maybe that's what you mean by "enough assumptions are made to make it so", but it's most definitely not reliant on TCP/IP.
    – Dave Newton
    Jul 24, 2018 at 15:37
11

Arguably, you'd be better off doing a simple mapping of the data from BLE paradigms to MQTT, rather than trying to literally send MQTT over BLE.

BLE generally exchanges data in the form of characteristics. These have various BLE-unique mechanisms for discovering value change that you may find useful. But they have a maximum data length of 20 bytes.

It is possible to stream serial data over BLE, moving 20 bytes at a time. This is sometimes done to implement a virtual serial port, and you could tunnel full MQTT through this.

But you'd probably do better to use a collection of BLE characteristics to carry the data of different topics, and have a bridge which maps the characteristic identity to an MQTT topic and maps the value to the MQTT payload.

BLE has its own sense of ongoing connected sessions vs. non-connected ones. Likely you should figure out what usage of BLE is best for your application, and then map this to the MQTT sense of maintaining a connection.

You should be able to do this in either or both directions: BLE->MQTT and MQTT->BLE

Improve this answer
2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.