Internet of Things, MQTT and Markets

Internet of Things (IoT) computing concept and related technology capture increasing attention over the last years. Verified Market Research reported the Global IoT Market Size valued at $212.1 Billion in 2018 and is expected to witness a growth of 25.68% from 2019-2026 and reach $1,319.08 Billion by 2026. IoT provides various opportunities to benefit from smart interconnection of physical objects and systems in order to complete business and every-day   tasks efficiently.

IoT also very useful for fleet management, allowing fleet owners to take advantage of this technology by deriving information from various sensors, gathering vital data on drivers behavior, equipment performance, getting the opportunity to remote fleets tracking and more possibilities to reduce overall costs.

According to the Grand View Research report, the global IoT fleet management market size is expected to touch $16.86 billion by 2025. Nowadays, it seems that the most popular protocol used in IoT is so-called MQTT (used to be Message Queuing Telemetry Transport, but it’s no longer an acronym today) protocol, enabling efficient communication with the Internet of Things (IoT) devices.

However, we are for sure not saying here, that MQTT is one and only IoT-suitable protocol: there are potentially many others such as XMPP, CoAP, AMQP, LWM2M, and more. If we do a funny thing here, asking Google Trends then…MQTT will definitely lead.

To make this stricter, we should say that there are definitely some nice engineering reasons behind why this is the case. We further discuss some working principles and features of MQTT, and some reasons why it became so popular in IoT.

Principles of MQTT operation

MQTT currently a major protocol, employed to deal with IoT projects. The official MQTT 3.1.1 specification states that MQTT “is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement.

These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium “‎.

While it’s already a good short description, we’ll try to explain it with a bit more details. This protocol was originally developed in 1999 by IBM, with initial goal to connect with oil pipelines via satellite using some bandwidth efficient and lightweight protocol that could be simply implemented and provide minimal battery loss while preserving continuous session awareness and Quality of Service (QoS) data delivery. After 20 years, MQTT still following these principles.

MQTT is essentially a lightweight application-layer messaging protocol, based on the publish-subscribe architecture and consisting of a broker, publishers and subscribers.

There are also two specially-named associated processes: when a client (device/sensor) wants to send some data to the broker, this operation called “publish”, when a client (device/sensor) wants to receive data from the broker, operation called “subscribe”.

Messages in MQTT are always published on topics, representing the destination address for a message. A client may subscribe and publish to various topics. Each client subscribed to a topic receives all the messages published to that topic.

MQTT publish/subscribe model provides an alternative to traditional client-server architecture, where a client communicates directly with an endpoint: publishers and subscribers in MQTT never contact each other directly, they actually don’t know that the other exists. The connection between them provided by the broker. The aim of the broker is to filter all incoming messages and correctly distribute them to subscribers.

Overall, we named five main “MQTT components”: message = data that a device/sensor receives when subscribing from a topic or send when publishing to a topic, publish = process device/sensor does to send message to broker, subscribe = process device/sensor does to obtain a message from broker, topic = place a device/sensor want to put/retrieve a message to/from, and a broker acting as kind of server that handles the data transmission among the clients/subscribers/publishers. 

To give an example, let’s consider a speed meter (publisher), that aims to send its readings to a broker. A phone or desktop application on the other side (subscribers) want to receive the speed value. The device/sensor defines the topic it wants to publish – in our case   “speed”, and then it publishes the message, say: “70 mph” (“mph ” stands for “miles per hour “). The phone or desktop application subscribes to the topic ” speed”. Then, it receives the message that the device/sensor has published, which is “70 mph”. The broker role here is to take the message “70 mph” and deliver it to phone or desktop application.

MQTT standard packet structure and QoS

Here we only briefly consider MQTT standard pocket structure and QoS, since a detailed one any interested person could find in a MQTT specification, available at https://mqtt.org/documentation.

MQTT v5.0 is an OASIS Standard and MQTT v3.1.1 is an older ISO and OASIS Standard.  MQTT 5 considered to be the most feature-rich and extensive update to the MQTT protocol specification so far. MQTT is a binary based protocol meaning that the control elements are binary bytes, not text strings.

MQTT standard pocket has three fields: Fixed header, Variable header and Payload. Fixed header is 2 bytes in size and present in all the packet. Variable header and Payload are not necessarily present in the all packets and size of both may vary. Therefore, the overall size of MQTT packet is also variable. 

Quality of Service (QoS) in MQTT is an agreement between sender and receiver acting as a guarantee of delivering a message. It has three levels: 0 – at most once (client just publishes the message, without any “acknowledgement” by the broker), 1 – at least once (sending is guaranteed, but message may reach the broker more than once) and 2 – exactly once (both receiver and sender are sure that the message was sent exactly once).

When a client (device/sensor) is publishing to a broker client also determines the QoS level for a sent message. The QoS of the message is determined by an original publisher, and it will be kept the same all the way to final recipient. Therefore, when the broker sends the message to a subscribing client (device/sensor), the QoS set by the first client (device/sensor) for that message will be used again.

Which level to choose depends on a particular application, reliability of the connection, and network resources.

MQTT implementation

MQTT could be used in wide range of IoT applications. Here we consider a couple implementation examples related to fleet management. HiveMQ delivers an enterprise MQTT platform that makes it easy to move data to and from connected vehicles in a reliable and fast manner.

HiveMQ is a MQTT broker and a client based messaging platform designed for the fast, efficient and reliable movement of data to and from connected IoT devices. It uses the MQTT protocol for instant, bi-directional push of data between the device and enterprise systems.

HiveMQ makes it possible for fleet management system to: maintain a persistent always-on connection between vehicle and cloud, guarantee reliable data delivery between vehicle and cloud, enable secure non-addressable clients for vehicles to limit potential of cyber-attack, provide a scalable cloud infrastructure that will meet the demands of a growing fleet system and integrate the messaging data with other existing enterprise systems for scheduling, dashboards, supply chain systems, etc.

Platform by ThingsBoard “provides out-of-the-box components and APIs to dramatically reduce time to market and efforts to develop fleet tracking solutions”. According to ThingsBoard, “the platform provides production ready server infrastructure to connect smart cars and vehicles, collect, store and analyze various vehicle data, and share results of the analysis with your customers and end-users. 

There are plenty of connectivity options for vehicle sensors: either direct connection to the cloud or through the IoT Gateway. Platform supports industry standard encryption algorithms (SSL) and device credentials types (X.509 certificates and access tokens). The collected data is stored in Cassandra – fault-tolerant and reliable NoSQL database. ThingsBoard Rule Engine allows you to forward incoming data to various analytics systems, such as Apache Spark or Hadoop using Kafka or other Message buses”.

Before MQTT implementation, one also needs to think about which MQTT broker to choose, based on requirements of a particular application. There are many of them currently available, such as Mosquitto, EMQ, VerneMQ, Rabbit MQ, HiveMQ and others. 

MQTT is essentially a lightweight application-layer messaging protocol, based on the publish-subscribe architecture and consisting of a broker, publishers and subscribers.

It is currently one of the most commonly used protocols in IoT projects, and could be successfully implemented for a purposes of a fleet management, making the process of fleet management system data integration more immediate and scalable.

References

  • http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html
  • http://embeddedlaboratory.blogspot.com 
  • www.hivemq.com 
  • http://steves-internet-guide.com 
  • www.thingsboard.io 
  • https://1sheeld.com/mqtt-protocol
  • https://mosquitto.org
  • http://mqtt.org 
  • https://bevywise.com/blog/mqtt-vs-rest-iot-implementation 
  • https://grandviewresearch.com 
  • https://verifiedmarketresearch.com