MQTT

 

MQTT  (Message Queuing Telemetry Transport) is a lightweight connectivity protocol used on TCP/IP connections, enabling M2M/IOT connectivity on everything from sensors to embedded systems, mobile phones, and much more. MQTT is in the process of becoming a standardized protocol and it has the backing of large companies like IBM and Cisco. MQTT is openly published with a royalty free license and is the protocol of choice for those companies, like Silicon Engines, who believe an open protocol will help the IoT connect anything to anything.

 

MQTT was designed to minimize bandwidth and device requirements while ensuring robust communications over a wide variety of network types, making it suitable for lower end devices and allowing those devices to become connected.

 

MQTT implements messaging based on a publish/subscribe model where messages are sent and received using topical strings via a message broker. When a client publishes a message to a topic, its broker then delivers that message to all clients who have subscribed to that topic.

 

Topics are hierarchical and may contain many levels of nesting, depending on the developer’s preferences. For example if developing an application around weather stations, the topics may be designed like country/state/county/city/sensor so a temperature sensor in Skokie, Illinois, in Cook County may report via topic us/il/cook/skokie/temp and a humidity sensor in Algonquin, Illinois, Kane County would use topic us/il/kane/algonquin/humidity.

 

Quality of Service Levels

 

There are three Quality of Service (QoS) levels used by the MQTT protocol to determine how messages are delivered.

 

• QoS 0 is the simplest and requires the least amount of overhead. Messages are delivered via best efforts of the underlying TCP/IP network connection and they may get lost or arrive more than once. This QoS setting is best suited for messages that are frequent and/or non-critical. For example, a sensor reporting temperature every 10 minutes.

 

• QoS 1 assures that messages will be delivered at least once, but duplicates may arrive. This QoS setting is best suited for messages that absolutely must arrive, like an alarm event for example. If duplicates are a problem, the end user could embed additional information in the message for uniqueness, so duplicate messages can be ignored, or you can use QoS 2.

 

• QoS 2 assures that messages will be delivered once and only once. This setting is best suited to very important events like a point-of-sale purchase for example, where it is important that the customer be charged only once and that the end user get confirmation of the charge.

 

MQTT messaging can occur in the clear, or for applications requiring security, SSL is an option. The payload data in a MQTT message is not used or processed by the protocol, it is just moved as is, so the end user can place whatever binary data they require in the payload. To simplify data encoding between different platforms, the Silicon Engines’ MQTT package includes our implementation of Google’s protocol buffers. This capability provides a flexible means for new messages and payloads to be loaded into an IoT device, without changing the basic firmware.

 

Our work on MQTT benefits from two key Silicon Engines’ partnerships:

 

Eurotech is a listed global company that integrates hardware, software, services and expertise to deliver embedded computing platforms

 

STMicroelectronics is one of Europe’s largest semiconductor companies and the $8B manufacturer of the ST95 NFC/RFID chips and the ARM Cortex M3 microcontrollers that make cost-effective IoT applications possible.