An overview of how we implemented MQTT to minimize data consumption and maximize battery life, thereby enabling effective relay of a continuous stream of valuable data from our pilots’ smartphones.
To ensure 100% data driven operations and enable advanced technology applications, our pilots (truck drivers) and vehicles are connected and tracked through IoT devices. RIVIGO pilots carry smartphone devices and use the pilot app which enables relay of a continuous stream of valuable data. There were two major challenges here – heavy draining of battery life and high data consumption. Of course, continuous charging is one of the hardware solutions, but this could have adverse effects on battery life in the long term. The solution had to be one that led to reduction in data packets ensuring reliability, security and high availability.
Our key objective was to build a solution that would maximize battery life and minimize data consumption on a pilot’s smartphone. This meant that the solution should enable the following.
After carefully evaluating alternatives, we decided to use MQTT as it maintains a live connection, reduces payload on each network call and is highly reliable as it works on a TCP layer.
MQTT (Message Queue Telementory Transport) is a very lightweight and binary protocol, which excels when transferring data over the wire in comparison to protocols like HTTP. This is because MQTT has only a minimal packet overhead. Another important aspect is that MQTT is extremely easy to implement on the client side. This fit perfectly for constrained devices with limited resources.
MQTT is decoupled across three dimensions.
Quality of service
Quality of service (QoS) refers to a network’s ability to achieve maximum bandwidth and deal with other network performance elements like latency, error rate and uptime. Quality of service also involves controlling and managing network resources by setting priorities for specific types of data (video, audio, files) on the network.
MQTT provides three levels of QoS. Below is the functionality of each of these levels:
We used RabbitMQ as the MQTT Broker. RabbitMQ is lightweight and easy to deploy on premises and in the cloud. It supports multiple messaging protocols. RabbitMQ can be deployed in distributed and federated configurations to meet high-scale, high-availability requirements.
Earlier, on HTTP, we used to capture pilot’s GPS and other data periodically. While working on periodic pushing/polling task on the mobile side, we also needed to take care of the system performance. HTTP does not maintain live connection and hence affects system performance and does not sit well with our objectives.
Why did we prefer MQTT over HTTP ?
HTTP is the most popular and widely used protocol. But over the last few years, MQTT has gained significant traction. The following features of MQTT helped us with our objectives:
MQTT follows a publisher/subscriber pattern. A client can send a message to another client without knowing who the publisher or the subscriber is. This means that the publisher and subscriber are decoupled and do not know about each other’s existence. They are connected to the broker which is a third important component of the protocol. Broker filters all the incoming message and distributes them accordingly.
MQTT works in two parts, namely, the publisher and the subscriber (or consumer).
In our case, it is the pilot device which publishes the GPS and battery information. Whenever a pilot completes his login process, we establish a connection between the publisher and the broker. Once the connection is created, we do not recreate it periodically.
In comparison to a message queue, a topic is very lightweight. There is no need for a client to create the desired topic before publishing or subscribing to it. This is because a broker accepts each valid topic without any prior initialization.
On QoS level 1, once successfully published, broker sends an acknowledgement to the client. Broker maintains a queue which stores data until consumption. Broker’s queue size depends on machine storage allocated size which is configurable.
In the above snippet (taken from our android client), MQTT publisher thread runs on runnable thread so it will not block any UI updates. This is why the user will not experience any lag during publishing the data. The mqttAndroidClient sends an encoded message to the broker on respective topic along with the corresponding identifier. Here we maintain local storage (SQLite database) on the client side as well so to prevent data loss during unavailability of internet.
In our case, Chronos (data storage layer) acts as a consumer which subscribes to relevant topic with the targeted identifier. On the broker side, once data is successfully consumed, the broker gets an acknowledgement and releases the memory. Consumed data is further stored in Mongo.
We used battery historian for measuring the battery and data usage by the pilot app. This helped us accurately measure data usage and battery consumption.
The screenshot above shows how data consumption dropped to over half the original levels once we moved to MQTT. It also helped improve battery life by about 4%.
MQTT opens new areas for messaging use-case for billions of things connected through the Internet. As MQTT specializes in low-bandwidth, high-latency environments, it is considered to be an ideal protocol for machine-to-machine (M2M) communication. Most of time RIVIGO pilots are working in remote areas where they get limited access of resources. By implementing MQTT, we’ve solved for some key challenges in this regard and enabled effective data collection which fuels our pilot auto allocation engine and other applications.