Akamai’s IoT Edge Connect is Beta Testing MQTT
Akamai is beta testing MQTT for IoT Edge Connect, imagining “a hyperconnected world [that] makes every aspect of our lives better”.
IoT Edge Connect provides the worldwide messaging network and storage infrastructure that manages and secures IoT device connection and data storage. IoT Edge Connect is constructed to optimize the transmission and gathering of data to reduce storage needs and offer real-time access to data. It does this through “the complete implementation of the MQTT protocol”.
Traditional modes of CDN protection are not sufficient for next-gen IoT delivery, hence Akamai beta testing MQTT for IoT Connect. In the words of developer Alif Abdullah in a recent Medium post, “MQTT is one of the most widely used lightweight protocol to carry minimal data overhead. It’s a hot cake for the developers who are specially working with Internet of Things (IoT)”.
What is MQTT?
The MQTT.org describes it as “a machine-to-machine (M2M)/IoT connectivity protocol”. MQTT stands for MQ Telemetry Transport.
Its Original Goals and Uses
MQTT was invented in 1999 by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (now Eurotech) as a publish/subscribe, highly simple and lightweight messaging transport. Stanford-Clark and Nipper built MQTT for use within low-bandwidth, high latency and unreliable networks. Their design goals were straightforward: “to ensure reliability and some degree of assurance of delivery” within these kinds of more challenging environments. Their initial primary focus was to connect oil pipeline telemetry systems over satellite.
The MQTT protocol is lightweight, open, simple, and built to be easy to implement. It is therefore particularly suitable for connections in remote locations in which a small code footprint is required and/or network bandwidth is a challenge.
OASIS Standard
The protocol specification started its life as a live proprietary protocol. It was released royalty free in 2010. Various companies, including Eurotech (then Arcom) implemented the technology into their products.
In 2014, MQTT v.3.1 became an open source OASIS standard.
Two Versions
- MQTT, the original version (which we focus on here) – designed to work over the TCP/IP networks
- MQTT-SN specified in 2013 – designed to work over UDP, ZigBee and other network transports (not currently highly popular, but it has a very similar protocol to MQTT)
MQTT Key Characteristics
- MQTT clients do not need addresses such as email addresses and phone numbers as with most messaging systems;
- It runs on top of the TCP/IP protocol, or over “other network protocols that provide ordered, lossless, bi-directional connections” (OASIS Standard);
- MQTT is agnostic to the payload content;
Publish/Subscribe
- Unlike the traditional client/server protocol, it is not end-to-end; rather MQTT is a client server publish/subscribe messaging transport protocol, which provides one-to-many message distribution and application decoupling;
- The publisher sends and the subscriber receives (collectively the subscriber is known as clients);
- A client can be both publisher and subscriber at the same time;
- It does not maintain any queue unlike other messaging protocols;
Central Broker
- MQTT requires the use of another role in the middle: a central message broker (the term broker has been standardized as ‘server’ – hence the terms can be used interchangeably);
- The broker/server collects the messages from the publishers and dispatches them to the subscribers;
- Once the message has been sent to its clients by the broker, it is typically not stored (although persistent connections, QoS levels and retained messages can mean that messages are temporarily stored on the broker/server);
- A message can be stored if a retain flag is set;
Topic
- Topic is the routing mechanism for MQTT i.e. each message has a topic (similar to a category), which decides which message will be received by whom (a topic consists of several levels);
Messages
- Like all messenger systems, a Message is the information we exchange with other parties within the communication system;
QoS: Three Levels
- As it was designed for use over unreliable networks, MQTT lets you select from three different qualities of service for message delivery depending on how important your messages are:
- QoS O – “At most once” in which messages are delivered in relation to the best efforts of the operating environment, thus message loss is possible e.g. for use in relation to ambient sensor data – if an individual reading is lost, it doesn’t matter as the next one will be published not long afterwards. This is the lowest QoS level – which you can select if your application can tolerate lost or missing messages.
- QoS 1 – “At least once”, in which messages are guaranteed to arrive, however, it doesn’t matter if duplicates occur’
- QoS 2 – “Exactly once”, on which message are assured to arrive exactly once e.g. for use with billing systems in which duplicate or lost messages could lead to incorrect charges;
The higher the QoS level, the more message overhead there is.
MQTT Packet
- MQTT uses control packets to deliver messages and maintain connections;
- An MQQ packet comprises of a fixed header, an optional variable header and an optional payload;
- The smallest MQTT packet is 2 bytes;
- MQTT defines 14 message types, which include the potential to connect/disconnect, to publish messages, to subscribe to topics, to maintain the connection or to ensure the QoS.
Why MQTT for IoT?
MQTT is quickly becoming one of the main protocols for IoT deployments. There are many different types of connectivity protocols around the world; some like HTTP are used by millions of application. Why not one of the more widely used protocols for IoT? Why MQTT for IoT?
As the IoT has become an emerging part of the technological present and future, MQTT has emerged as a powerful contender as a highly suitable protocol for the M2M world of connected devices, hence Akamai beta testing it for use with its IoT Edge Connect network.
In the optimal IoT world, anything that can be connected will become connected in a smart home e.g. when you wake off an alarm on your smartphone, it will tell your air conditioning to turn on, your coffee maker to begin making coffee, your news show to switch on your smart TV…
MQTT was designed from the beginning for machine-to-machine telemetry; and most importantly it is a lightweight protocol with a very small code footprint, which doesn’t require a high bandwidth. The IoT needs these simple specifications in order to work at the level of the future smart home or smart city.
MQTT and Mobile Use
The lightweight messaging transport is also suitable for mobile applications due to its small size, minimal use of power, reduced size data packets, and efficient distribution of information to one or many receivers. It provides mobile users with low-latency and low power usage messaging over unreliable networks and offers a secure request-response protocol.
A couple of years ago, we wrote about a test run on Android devices to determine the different efficiency levels of HTTPS and MQTT in relation to mobile, which had interesting results. MQTT surpassed HTTPS – by an order of magnitude with certain components of the test over both WiFi and 3G. It also used less battery energy and received all messages sent in comparison to HTTPS, which received a significantly smaller number over 3G and WiFi. Overall, “power consumption was less and messages were received more reliably with the MQTT connection”.
MQTT and Node.js
The MQTT protocol can also be used by developers in Node.js. This has been made simpler recently due to the MQTT API provided by npm. For a thorough demonstration of a basic MQTT establishment in the Node.js program, see the Medium post by Alif Abdullah.
Notable Initial Use Cases of MQTT
MQTT has been widely used in a range of industries since 1999. The MQTT.org Projects page highlights some particularly interesting projects that have made use of MQTT and related technologies, including:
- The FloodNet project – a University of Southampton, UK project, which has an embedded monitoring presence whereby a set of sensors monitor the flow of a river and functional floodplain environment in order to obtain “an environmental self-awareness and resilience to ensure robust transmission of data in adverse conditions and environments.”
- Location Aware Messaging for Accessibility – LAMA was built in 2006 as part of IBM’s Extreme Blue Projects as a system “for making information available to people in a way that is relevant to their interests and location”. It uses MQTT along with various other technologies to do so.
Does MQTT Support Security?
Security is a key topic for Akamai in relation to every aspect of its platform; no less so for the IoT. IoT Edge Connect uses mutual authentication and access to the network is managed through access control technology. It’s imperative for Akamai that MQTT can successfully support security, which it can. A user name and password with an MQTT packet in V3.1 (the latest version) of the protocol can be passed. Encryption across the network can also be also handled – via SSL, independently of the MQTT protocol. Further security can also be added by an application encrypting data that it sends and receives; however, this is not built-in to the protocol because of the design goal of simplicity.
