Building a Better “Connected Car” with MQTT 5.0

Solace PubSub+ Event Brokers have always supported a rich variety of client APIs and wire line protocols. Architects and developers can choose the best technology for each app they are building, with confidence those apps will interoperate. That includes JMS, Spring, AMQP for server-side apps and thick client apps, MQTT 3.1.1 and now MQTT 5.0 for the Internet of Things (IoT), REST and webhooks for integration with cloud native services, JavaScript for browser-based and mobile apps – all this and more is possible with a PubSub+ Event Broker.

When it comes to IoT, MQTT 3.1.1 is the widely adopted industry standard. Whether it’s connected cars, industrial IoT, smart cities, or connected devices in your home, there’s a good chance those devices are using MQTT 3.1.1 to talk to the back-end servers, and to each other.

MQTT is a lightweight protocol ideal for “things” with limited RAM and CPU. It provides basic pub/sub semantics, with persistent and non-persistent Quality of Service (QoS) delivery options, making it a great fit for simple devices. It was released as an OASIS standard in 2014 as version 3.1.1, and has come to be supported by a broad ecosystem of open source APIs and a strong developer community. The clear protocol specification ensures good interoperability between different API implementations, and you can even write your own API to run on your “thing’s” custom hardware if you need to!

What is MQTT 5.0?

MQTT 5.0 is the latest version of the MQTT specification, supported today in PubSub+ Broker version 9.9.0 (and beyond). And MQTT 5.0 support is already available, or coming soon, in the most popular open source MQTT APIs.

Simply put, MQTT 5.0 lets you do more, while preserving everything that made MQTT 3.1.1 so successful. MQTT 5.0 makes it easier to build more powerful apps on the “things,” and makes MQTT rich enough to also be used for robust sever-side apps. This means you can you can use the same protocol on your servers and your “things”, if you want to.

MQTT 5.0 offers:

• More powerful options for building messages
• More flexible apps
• Scalable server-side apps
• Better broker resource management
• Better app potability
• Easier debugging

Now let’s look at what MQTT 5.0 can add to a connected car example use-case.

MQTT 5.0 and a Connected Car Use Case

Here is what a connected car platform might look like:

As illustrated, we have connected cars, back-end applications, and the mobile apps used by the car owners to monitor and control their vehicles, all connected using a PubSub+ Event Mesh. Newer cars could be using MQTT 5.0, while older cars might be using MQTT 3.1.1. The mobile apps could be using MQTT 5.0, or the Solace JavaScript API, while the back-end applications can be written using a variety of APIs – in our example some are using MQTT 5.0, while others are using JMS and .NET.

The cars communicate with the applications by exchanging events with the applications through a connectivity tier. And car owners control their cars using mobile apps, by sending events through the application tier. So the event flow through the mesh looks something like this:

Read on if you want to learn more on how the many new MQTT 5.0 features help us build this connected car platform. If you prefer watching, feel free to check out my video from the Solace Connect user conference:

More Powerful Options for Building Messages

• Content Type and Payload Format: Cars will be sending all kinds of data to the apps. Status and sensor data (cabin temperature, engine status, etc.) might be sent as JSON payloads. The car’s security system might be sending pictures (e.g. when someone stands too close to the car). With MQTT 3.1.1, there was no way for the sender to tell the receiver what kind of data was in the event – the receiver had to know in advance what to expect on a given topic, or extra information had to be added to the payload of the event. MQTT 5.0 adds “content type” and “payload format” as standard message headers, making it easy for the sender to tell the apps what kind of data is in each event – JSON, JPEG, etc., and how text has been encoded.
• User Properties: Senders of events often want to include extra meta-data with each event. In a connected car platform, cars might want to include their VIN numbers, so apps know which car an event is coming from. Or they might want to include their firmware version, so the mobile app only presents the owner with options supported in the car’s firmware. MQTT 3.1.1 didn’t have any capability for apps to add meta-data to their events. That is solved with the introduction of User Properties in MQTT 5.0.

More Flexible Apps

• Message Expiry: Imagine the car owner presses the “honk horn” icon on their mobile app. What happens if the car is parked in a spot where it can’t get a mobile connection? It wouldn’t be good for the horn to sound “spontaneously” whenever the car’s mobile connection is restored – maybe minutes or even hours later! With message expiry, the “honk horn” message can be sent with a 10 second or 20 second expiry time. If the PubSub+ Broker can’t deliver the message in that time, the message is automatically deleted by the broker, rather than being queued indefinitely until it can be delivered to the car.
• Request-Reply: Remember that security alert, with a photo taken by the car? From the mobile app, the car owner can send a request to “take a new picture”. The car replies with a new photo, the owner sees a friend standing in the rain, and send an “unlock doors” command to the car. The car can then unlock the doors, and send a “doors unlocked” reply. For request-reply to work, the sender of the request needs to indicate where the reply should be sent. But MQTT 3.1.1 didn’t have any way of telling the recipient of a request where to send replies. Now, with MQTT 5.0, request-reply is a standard part of the protocol.

Scalable Server-Side Apps

• Shared Subscriptions: The application tier of our IoT platform needs to handle updates from millions of cars. But that’s many more events than a single instance of a microservice can handle. To scale, the messages need to be load-balanced across many instances of the microservices in the application tier. And that allows you to scale the infrastructure as new cars join the event mesh. MQTT 3.1.1 doesn’t provide a way to load-balance messages, shared subscriptions were added to MQTT 5.0 to fill this gap. The PubSub+ Event Broker supports QoS-0 shared subscriptions today, with QoS-1 shared subscriptions coming in 2022.

Better Resource Management on the Brokers

• Session Expiry: There are all sorts of reasons why cars may disconnect from the event mesh and perhaps never return. Cars get sold, scrapped, moved to different countries. And if there are persistent messages queued in the brokers for those cars, they need to be cleaned up – an expensive, tedious administrative activity in MQTT 3.1.1. MQTT 5.0’s session expiry lets event brokers clean up the resources automatically when the sessions expire.
• Server Reference: Millions of cars need dozens of interconnected PubSub+ Event Brokers to handle all their connections. But it’s inconvenient to “hard code” which broker each car should connect to. The network operator can’t easily add more brokers, and rebalance the cars across the larger pool of brokers. Using MQTT 5.0’s server reference, a car can connect through a load-balancer to any broker in the mesh, and have its connection automatically redirected to the broker that is hosting the car. The PubSub+ Event Broker will support server reference in 2022.

Better Application Portability

• Optional Server Capabilities Announcement: Brokers use MQTT 5.0’s server capabilities to tell the apps what features the broker supports. Apps can dynamically adjust what services they offer the user, based on the capability of the broker.
• Receive Maximum, Maximum Packet Size: The apps running in the car will have limited RAM and CPU… but as the cars evolve, the onboard computers will become more powerful. Receive Maximum lets the car tell the broker how many events can be sent to the car in one burst. And Max Packet Size tells the broker how big each event can be. So with MQTT 5.0, different cars can advertise different capabilities, ensuring that a broker won’t overwhelm a connected car by sending too much data at once.

Easier Debugging

• Reason code and strings on all acks, Server Disconnect: In MQTT 3.1.1, when a broker doesn’t like or understand a message, all it can do is disconnect the app. This makes it very hard for the app programmer – or end user – to figure out why the connection is failing. MQTT 5.0 lets the broker reply to events it doesn’t like with reason codes and strings, so developers can easily debug their apps. This can be very helpful when using MQTT 5.0 for your server-side apps like the application layer of our connected car platform, where there is continuous development, innovation, and integration, and new code being rolled out.

Conclusion

MQTT is a powerful tool not just for building IoT apps, but also for building server-side apps, when portability and open standards are desired. MQTT 5.0 is fully interoperable with all the other protocols and APIs available in PubSub+ – including MQTT 3.1.1 apps – so you can choose the best tools for the apps you want to build and the problems you want to solve. And it is available today in PubSub+ Event Broker.