The topic of mobile devices and mobile solutions is a hot one in the IT industry. I’ll devote a series of articles to exploring and explaining this very interesting topic. This first piece will focus on MQTT for the Internet of Things – a telemetry functionality originally provided through IBM.

MQTT provides communication in the Internet of Things – specifically, between the sensors and actuators. The reason MQTT is unique is, unlike several other communication standards, it’s rigorous enough to support low latency and poor connectivity and still provide a well-behaved message-delivery system.

Within the Internet of Things there’s a universe of devices that provide inter-communication. These devices and their communications are what enables “smart devices,” and these devices connect to other devices or networks via different wireless protocols that can operate to some extent both interactively and autonomously. It’s widely believed that these types of devices, in very short time, will outnumber any other forms of smart computing and communication, acting as useful enablers for the Internet of Things.

MQTT architecture is publish/subscribe and is designed to be open and easy to implement, with up to thousands of remote clients capable of being supported by a single server. From a networking standpoint, MQTT operates using TCP for its communication. TCP (unlike UDP) provides stability to message delivery because of its connection-oriented standard. Unlike the typical HTTP header, the MQTT header can be as little as 2 bytes, and that 2 bytes can store all of the information required to maintain a meaningful communication. The 2 bytes store the information in binary using 8 bits to a byte. It has the capability to add an optional header of any length. The 2 bytes of the standard header can carry such information as QOS, type of message, clean or not.

The quality-of-service parameters control the delivery of the message to the repository or server. The options are:

Quality-Of-Service Option Meaning
1 At most once
2 At least once
3 Exactly once

These quality-of-service options control the delivery to the destination. The first 4 bits of the byte control the type of message, which defines who’ll be interested in receipt of these messages. The type of message indicates the topic of the message, which will manage who receives the message. The last element will be the clean byte, which like the persistence in MQ will determine whether the message should be retained or not. The clean option goes a step further in that it will also tell the repository manager whether messages related to this topic should be retained.

In my next blog I’ll discuss the broker or repository for these messages. There are several repositories that can be used, including MessageSight and Mosquitto among others. The beauty of these repositories is their stability.

(Photo by University of Liverpool Faculty of Health & Life)

Gary Dischner is a certified Enterprise Architect with deep experience across diverse technology areas including application, network, security, infrastructure and devops. He's certified on many IBM product sets including Solution Designer for WODM 6.0, Program Manager for BPM (Lombardi) 7.5, WebSphere MQ Solution Designer 7.0, WebSphere MQ Administration 7.0, Connect Direct Administration, IBM MobileFirst Sales Mastery (mobility certification), IBM Social Business Solution Sales Mastery, Power System with Power 7 Common Sales Skills, Power System with Power 7 Technical Skills and Enterprise Architecture. Gary has served as the lead for many first-of-a-kind solutions including voter modernization for the State of Florida, healthcare-delivery modernization, BMS from discovery to market modernization process, and many first-of-a-kinds at Morgan Stanley for go-to-market projects. He's served as Associate Professor at Canisius College in Buffalo, NY for over 10 years and has also served as an ambassador in representation of IBM at several college forums.

Pin It on Pinterest

Share This