MQTT for ANPR Devices
We recently had to add an efficient means of sending messages from our server / Cloud infrastructure to our ANPR cameras in order to request locally stored data, such as video files, be uploaded on demand. Uploading such files only on demand allows us to record higher quality video or capture high resolution images without breaking the budget on mobile data charges and available bandwidth.
We also wanted to be able to utilise this communication channel for configuration updates, as well as other kinds of messages we haven’t even thought of yet. In other words, we needed a flexible and light-weight – yet robust – protocol suitable for low-power devices with relatively expensive and sometimes unreliable mobile connectivity.
The Achilles’ heel of IP cameras
An all too common practice among camera manufacturers is to simply run a Web server listening on a public port. But this comes with a number of downsides that were not acceptable to us:
- Running an entire Web server just to receive simple messages is not efficient.
- It introduces a much larger attack surface, likely requiring regular security updates just to keep the Web server from providing an unwanted pathway onto the device.
- It does not “just work” behind NAT routers and firewalls, because the connection is established by the Cloud service, rather than the edge device.
- Without custom retry functionality on the server side, the client needs to be online at the very moment the message is sent.
- It is just plain ugly.
So we needed a more elegant solution and, given the proliferation of IoT devices in the last years, it came as no big surprise that such a solution already existed: The Message Queuing Telemetry Transport, or simply MQTT.
Streaming vs on-device ANPR processing
Quite often the ANPR processing is done by a cloud server or even a local desktop computer receiving a video stream from an IP camera. The camera has a live connection to the server and can receive commands any time. It is a very power and data hungry solution.
Sensorable ANPR cameras process the video right on the device and can be completely offline or communicating infrequently to save power and cellular data. Hence the need for a light-weight communication protocol to talk back to the camera when needed.
MQTT – perfect for small messages
MQTT was originally conceived at IBM and Arcom (now Cirrus Link), but in 2013 version 3.1 was submitted to the open standards consortium OASIS, and in 2016 MQTT version 3.1.1 became ISO/IEC standard 20922. So this protocol not only benefits from years of development, but also from a rigorous specification that ensures interoperability between different implementations.
If that wasn’t enough, Amazon provides a message broker, the server side component in MQTT, as part of their AWS IoT Core service. This made things a lot easier for us, given that our Cloud infrastructure already makes use of several other AWS services. They have also integrated the popular open source Eclipse Paho MQTT Java client into their Software Development Kit (SDK), which ensures that messages are sent via a secure channel and integrates with the advanced authentication and authorisation functionality provided by Amazon’s own IAM and IoT Core services.
But what makes MQTT itself so appealing for edge devices such as ANPR cameras? For one, clients connect to the broker (server), not the other way around, to establish a session. This means the above mentioned problems with clients operating behind NAT routers are avoided, and firewalls do not have to allow traffic to pass unless the connection was established from within their local network. Furthermore, the AWS MQTT broker is available on port 443, which is the TLS/SSL port widely used for HTTPS connections and, therefore, generally not blocked for outgoing connections by even the tightest firewall rules.
Once established, the session allows bi-directional communication between the client and broker, only requiring the occasional small PING request to be sent by the client if no other messages are exchanged to maintain the session.
Following this scenario, we could imagine a topic named 123456/file/request that the camera with ID 123456 subscribes to. When a user requests a video recorded by this camera to be uploaded through the Web app, a message with the name of the requested file in its payload is published to this topic by the MQTT client running in the micro-service responsible for this particular functionality. The broker sees that camera 123456 is subscribed to the topic and forwards the message to it. The camera in turn uploads the requested video file, and within seconds of the user making the request another event is triggered on the server side to update the Web UI and let them know that the video is ready to be watched.