MQTT in Teltonika trackers: what it is for
Teltonika explains how trackers such as the FMB130 send data over the MQTT protocol: lightweight messages through a broker, TLS encryption and two-way communication help avoid data loss in congested urban networks and with large numbers of devices.
Teltonika explains how trackers such as the FMB130 send data over the MQTT protocol: lightweight messages through a broker, TLS encryption and two-way communication help avoid data loss in congested urban networks and with large numbers of devices. This use case is not about a particular industry but about data transport. Any monitoring system rests on how the tracker delivers positions and events to the server. When there are thousands of devices and the city network is congested, the choice of protocol decides whether the dispatcher sees a vehicle now or in ten minutes' time. MQTT is one of the options Teltonika supports alongside its own native protocols. Let us look at what it is for and who will find it useful.
What this scenario solves
Cities are filling up with connected devices, and mobile networks are running at their limit.
Network congestion turns into delays, dropped connections and lost data.
For government projects, ambulance services, oil and gas and expensive corporate fleets, late data is unacceptable.
Sending telemetry without encryption exposes data about vehicles and people to interception.
Cities are filling up with connected devices, and mobile networks are running at their limit.
Network congestion turns into delays, dropped connections and lost data.
For government projects, ambulance services, oil and gas and expensive corporate fleets, late data is unacceptable.
Sending telemetry without encryption exposes data about vehicles and people to interception.
On UN projections, by 2030 the urban population will have grown by almost 700 million people and will reach 5.2 billion, roughly 60% of everyone on the planet. Along with the people, cities are filling up with small, inexpensive, low-power devices: meters, sensors, cameras, trackers. All of them share the same cellular network.
In practice this looks like periodic drops in throughput, an unstable connection among dense buildings, dead zones. Add the weather and interference, which nobody controls, and you get a network where a data packet sometimes simply does not arrive first time.
For a private motorist that is a minor inconvenience. For an ambulance control room, a cash-in-transit security service, an oilfield services company or a fleet of executive cars it is a serious risk. Customers like these pay for data that arrives on time and in full, and they do not accept explanations about a busy network.
The other side of it is security. The coordinates of service vehicles, their routes, data about drivers — all of this is sensitive information. If the exchange protocol is not encrypted, it can be intercepted or tampered with. So the requirement placed on a modern tracker sounds like this: send data economically, reliably and securely, all at the same time.
What Teltonika offers
Teltonika proposes using the MQTT protocol in trackers such as the FMB130: it sends short messages through a broker on a publish-and-subscribe model, holds the session open on an unstable network and is encrypted with TLS.
Installation and setup
Fitting the device and configuring it for the fleet scenario at hand.
Data transfer
The device collects data and sends it to the monitoring platform; how often depends on the model and its settings.
Analysis and control
The person in charge gets reports and alerts and looks into what stands out.
A little history. MQTT (Message Queuing Telemetry Transport) was devised in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper of Eurotech. The problem they faced was a similar one: linking remote devices over expensive and unreliable channels while using a minimum of traffic and computing resources. Since then the protocol has become one of the standards for machine-to-machine communication (M2M) and for the internet of things, transport telematics included.
How it is arranged. MQTT has clients and a broker. A client is any device or program with an MQTT library: a tracker, a sensor, a server, a mobile application. The broker is an intermediate server through which every message passes. It checks who is connecting, keeps track of sessions and subscriptions and distributes messages to their recipients.
Messages are published into topics. An FMB130 tracker publishes, for example, its coordinates and events into the topic belonging to its vehicle. The monitoring server, the dispatcher's application or an accounting system subscribe to the topics they need and receive the data as soon as it appears. Sender and recipient never talk to each other directly, only through the broker. That is why several systems can be attached to a single data stream without loading the tracker with extra connections.
It works in both directions. The server can publish messages too, which the tracker subscribes to: commands, new settings, requests. And a single message can be sent out to a whole group of devices at once, for instance to one company's entire fleet.
How this helps on a poor network. MQTT messages are small and the protocol carries a minimum of overhead traffic, so it works perfectly well where the connection comes and goes. The protocol maintains session state and offers levels of delivery guarantee: the broker can hold messages for a device until it comes back online, and the tracker does not treat data as sent until it receives an acknowledgement. After a dropout the session resumes without resending everything from the start.
Security. MQTT itself runs over TCP and by default does not encrypt data. The broker and the clients therefore have to use TLS: it encrypts the channel and makes it possible to verify the authenticity of both the server and the device. Teltonika explicitly recommends not skipping this setting. Without TLS all the advantages of the protocol become meaningless for any serious project.
Scale. MQTT brokers are designed for very large numbers of connections, up to millions of devices. For a telematics service provider this means that growth in the customer fleet will not hit a wall in the data exchange architecture.
What to agree before the switch. The protocol version and the message format supported by the tracker firmware are checked against the customer's broker. The topic structure is built so that each tracker publishes only into its own topic, while subscriber systems are given access only to the topics they need through the broker's access rules. TLS certificates have an expiry date: once it passes, the trackers will stop connecting, so replacement is planned in advance and the new settings are rolled out remotely through FOTA WEB.
Testing and rollback. The switch starts with a test group of trackers, and their previous configuration with the native protocol is kept. If the broker does not accept the data, or messages go missing, the group is returned to the old arrangement with the same remote task, without travelling out to the vehicles.
Where the catch is. MQTT demands infrastructure of its own: a broker, topic configuration, TLS certificates, handlers on the server side. For a small fleet working with an off-the-shelf monitoring platform this is an extra layer, and the tracker's native protocol is usually quite enough there.
What you get
Data gets through even on a poor network
Short messages, session persistence and delivery acknowledgement reduce losses when the link drops.
Encryption and device verification
TLS closes the channel to interception and stops an unauthorised client connecting.
One stream for several systems
Monitoring, accounting and analytics subscribe to the same topics with no extra load on the tracker.
Commands in both directions
The server sends settings and requests to the tracker over the same channel, including to a whole group of devices at once.
Less traffic
Minimal overhead saves mobile data, which is noticeable on large fleets.
Growth without redesigning the architecture
MQTT brokers cope with very large numbers of connected devices.
Why this solution
Teltonika trackers support MQTT alongside the manufacturer's native protocol, and it is enabled by a setting in the Configurator, with no special firmware. You can choose the broker, the topics and the TLS parameters and still keep every other tracker function: sensors, scenarios, CAN.
The FMB130 was chosen as the example for a reason: it is a versatile tracker with inputs and outputs for sensors, and it is often fitted in corporate fleets. The same MQTT support is present in other Teltonika models, so an integrator can build a project on a mix of devices but with a single data exchange scheme.
For companies with IT systems of their own this is an important argument: data from the trackers lands directly in their infrastructure over an open, standard protocol, with no tie to one particular platform.
How this works in Azerbaijan. Baku has dense building and heavy load on the Azercell, Bakcell and Nar networks, especially in the centre and at peak hours, while outside the city, in Absheron and in the mountains, coverage disappears altogether. MQTT is mainly of interest to large customers: oil, gas and services companies in Absheron, government bodies, banks with cash-in-transit vehicles, ambulance and emergency services, and logistics companies that want tracker data delivered straight into their ERP and dispatch systems. For an ordinary fleet running on an off-the-shelf monitoring platform, the native Teltonika protocol is enough, and resilience to dropouts is provided by the tracker's memory, which stores positions and sends them on once the network returns. GPS.az configures Teltonika trackers for the required protocol, connects them to the Wialon platform and helps with integration when the data has to travel further, into the customer's internal systems.
Related case studies
Related rollouts and equipment
Questions about the “MQTT in Teltonika trackers: what it is for” scenario
Request a call
A specialist will call back and match a solution to your fleet and your task.