The MQTT protocol is becoming widely adopted in GPS tracking device communication. In fact, leading manufacturers including TOPFLYtech, DCT, Squarell Technology, Globalmatix, Xirgo Global, and Teltonika are already offering MQTT-compatible devices.
Let's take a look at what is behind this trend and what exactly are the advantages of the MQTT protocol over traditional communication between GPS devices and applications.
Why MQTT is getting trendier in GPS / Vehicle Telematics
Telematics systems that comprise vehicle telematics devices and applications are becoming increasingly more complex. Today these systems can incorporate GPS devices, various sensors, CAN-bus controllers, and multiple software components that process data independently and are often maintained by different development teams. IoT devices are also constrained by connectivity, battery life, processing power, and data usage, which can increase the value of effective communication between components of such complex systems.
Let’s take car-sharing services as an example. There are a whole bunch of aspects that should be addressed: vehicle location sharing, remote access and control, timely refueling and maintenance, driver scoring, road accidents, anti-theft, and many more. Such systems require processing a lot of data from hundreds of vehicle sensors and thousands of user interactions, while also being scalable enough to support thousands of vehicles across multiple cities.
The use of MQTT protocol for complex and scalable systems is advantageous because of its usefulness in mitigating IoT communication constraints and its nearly universal compatibility across platforms including AWS IoT Core, Cloud IoT Core, and Azure IoT Hub. Thus MQTT has become quite common in use by both software developers and device manufacturers.
Let’s take a closer look at the advantages of MQTT protocol:
- Publish & Subscribe
- Quality of Service
- Commonality
- Lightweight
Publish & Subscribe pattern: a better way to exchange useful portions of data
Unlike the traditional Request/Response messaging pattern commonly used in telematics systems, MQTT utilizes the Publish/Subscribe method, which offers the ability to broadcast messages to many clients at once.
Data from any IoT device type can be easily and quickly distributed among many apps. Each app can subscribe to particular data communications from clients connected to a broker called a topic. The app will only receive data related to the topic it is subscribed to, which limits the amount of traffic on the network. For example, one app can subscribe to a GPS topic and another for a CAN bus topic. The publish and subscribe feature helps make complex systems like Navixy more scalable with multiple nodes and data sets.
Publish/Subscribe communication models make sense in environments that have many servers and clients that need to share data and services. They are implemented in an asynchronous way (using message queue) and create much less network traffic than traditional Request/Response communication models which require all clients and servers that need to share data to be connected to each other. They also must poll each other regularly in the Request/Response model, which creates even more network traffic, to see if there is new data compared to the Publish/Subscribe model which only sends data when it changes. Furthermore, communication between devices is decoupled, meaning it’s easier to keep the entire network more secure.
Quality of Service (QoS): guarantee delivery of critical data and don’t worry about less important data
Some data packets are more important than others. For example, it might be quite critical to receive every alert on a car alarm, whereas missing a pair of coolant temperature measurements is okay. This is where the Quality of Service (QoS) mechanism really helps: it allows developers and integrators of telematics systems to set certain expectations on data deliverability.
QoS ensures that certain high-priority data is delivered to/from the devices or applications under limited network capacity. The MQTT protocol has three QoS levels which are determined by the client or subscription type:
- QoS 0 (Fire forget). This is the lowest level and it is used when some data packet loss is acceptable. For example, some coolant temperature readings from the CAN bus can be missed in many scenarios.
- QoS 1 (At Least Once). This is the most common level that is used when duplicate messages are acceptable and can be easily handled. For example, regular messages with GPS location data of the vehicle.
- QoS 2 (Exactly Once). This level guarantees delivery only once. It is used in critical applications and has the highest overhead. For example, a command to an engine cutoff controller.
MQTT allows setting QoS for each particular type of message, e.g. for GPS location, fuel sensor readings, device commands.
Commonality: faster and less expensive way to integrate systems
Prior to MQTT existing, connecting devices and networks to software and apps required complex, timely, and expensive integrations due to the use of a variety of communication protocols. MQTT is commonly used across applications and industries and is uncomplicated for developers to work with to build apps and software packages in clouds or on-premises. For example, Mosquitto MQTT can be deployed with an MQTT bridge set-up with Navixy Broker on Navixy Central. AWS IoT, Azure IoT, and Google Cloud IoT all have MQTT brokers and compatibility on their cloud computing platforms.
Lightweight: save on traffic costs
It is worth mentioning that the MQTT protocol was originally designed for monitoring IoT sensors in the desert via satellite links. That is why MQTT has a small code footprint and does not add much overhead. It maximizes available bandwidth and reduces update rates to seconds. Plus, it can also be used to control devices by sending commands from apps. Any number of devices can receive commands such as in bulk updates.
For vehicle telematics, the advantage of being lightweight helps keep costs for cellular and satellite connectivity as low as possible.
MQTT Structures
Thanks to the low overhead and integrated QoS mechanism, the MQTT messaging protocol can be used in any physical network. For vehicle telematics, it is most commonly GPRS, SAT, or LPWAN networks.
MQTT requires an underlying transport that provides an ordered, lossless stream of bytes between the client and broker. It does not require the support of any specific transport protocol but may support TCP/IP, Transport Layer Security, and Websocket among others. Connectionless network transports such as UDP are not suitable on their own because they might reorder data.
MQTT is a binary protocol where the control elements are binary bytes and not text strings. It has a command and command acknowledgment format, so when a publisher/client sends a message to establish a connection to the broker, the broker sends an acknowledgment. Further acknowledgments are determined by the QoS level. Packets consist of a header, a variable header, and a payload.
On the higher level, MQTT messages can encapsulate various data structures. Based on observations made on the devices already supported by Navixy, MQTT protocol carries either of the following:
- Packets of proprietary protocols of device manufacturers
Some manufacturers such as Teltonika and TOPFLYtech use their compact binary data formats to transfer data using MQTT. - JSON or XML formatted messages
For example, Globalmatix provides GPS information, raw CANbus data along with other signals and events in simple JSON structures.
The second approach might seem more developer-friendly as it does not require complex decoding. However, for scalable and device-agnostic systems, it is advantageous to have Navixy MQTT Central that reduces device protocol complexity, unifies data formats, and handles app integrations. To learn more about MQTT structures visit the Navixy Academy.
Using MQTT devices with Navixy
One of Navixy’s core attributes is ease of integration with a wide variety of device types. It currently has integration built with over 1,200 types of devices that can be connected to Navixy using MQTT or any other proprietary protocol. In an MQTT use case, Navixy acts as the MQTT broker and supports MQTT protocol v3.1.1 and all levels of QoS. Navixy also utilizes a REST API for easy access to gathered data. These features make it convenient for GPS providers and integrators to connect MQTT-compatible devices to Navixy and build complex IoT and GPS networks.
Navixy can also be set up as an MQTT client that receives published updates from other clients connected to a 3rd party broker. In this instance, Navixy subscribes to relevant MQTT topics that are published by the other clients. Navixy only receives published data from topics it is subscribed to. The device types which can be integrated will be dictated by the 3rd party broker and not Navixy. This can limit the number of device types available to collect data from.
How GPS device manufacturers use MQTT today
Many leading GPS device manufacturers already produce MQTT compatible hardware and the number of these device types is constantly increasing.
TOPFLYtech recently deployed MQTT in its new 4G device series. According to Sales Director Blazer Hou, MQTT significantly optimizes communication in large systems with many servers and applications. Therefore, the company sees fundamental new opportunities in creating large IoT solutions based on MQTT.
The German manufacturer Globalmatix finds MQTT advantageous in working with CANbus data. The specific application of its devices is the ability to work with a large number of CAN-bus parameters. Thanks to the possibility of using MQTT Topics, application developers can easily subscribe only to the set of parameters they need.
Device manufacturer Xirgo Global, recently acquired by Sensata Holding, also uses MQTT in its most advanced devices, such as the XG3700. This line is focused on applications in non-standard solutions: integrators can use the SDK to create their own scripts for managing peripheral devices, including via the CAN bus. It makes sense that MQTT was chosen as the communication protocol for devices designed for these complex projects.
A similar approach is followed by Digital Communications Technologies (DCT), which produces an onboard gateway for Syrus 4G telematics data that also uses MQTT for communication. The gateway is built on a Linux platform and provides an API and SDK for integrators.
Other companies that use MQTT in their devices include Teltonika, Aplicom, Squarell Technology, InHand, Thinkrace, and many others. Therefore, it can be said that there is a trend in the use of MQTT for communication with flexibly configurable GPS devices.
A Good time to consider MQTT for your next project
A poor choice in messaging protocol can be costly, delay development, and derail implementations. If you are building a telematics system with the prospect of serious development, then you should carefully look at the use of MQTT as the main protocol between your GPS devices and IoT applications.
Integrators and developers can use any GPS/IoT equipment operating with MQTT protocol with the Navixy platform. The capabilities of the Navixy MQTT Broker and Navixy MQTT Central allow you to create flexible and reliable solutions ready for high overhead.
