Data Protocols for Smart City

Comparison of data protocols for Smart City — MQTT vs. CoAP

Edin Golubovic
Feb 9, 2018 · 9 min read

In the architecture context, Smart Cities are composed of heterogeneous technology elements with different power, communication, and computation characteristics. Smart City includes sensor nodes and gateways that have limited battery and computational resources. Hence, Smart City systems require protocols for data transmission that are, bandwidth and energy-efficient and need a small memory footprint in the implementation. These requirements dictate that protocols for Smart City applications must be very different from those that facilitate the data exchange in conventional Internet applications.

Most of the Internet traffic is made out of the utilization of HTTP over TCP medium. However, HTTP is verbose, complex, and not suitable for deployment on the constrained devices found in Smart City applications. HTTP has a human-readable format which was very helpful for the communication between people, however, the communication between machines demands a different approach.

Trends

Current trends in data protocols for Smart City applications tend to be so-called “messaging” protocols where a series of messages are exchanged between the device and cloud. Among available data protocols, two of them became very popular for Smart City, namely, Message Queue Telemetry Transport — MQTT and Constrained Application protocol — CoAP. Both protocols were invented to accommodate ultra-constrained Internet-connected devices requirements such as energy efficiency, lightweight, bandwidth-friendly, and reliability in environments dominated with intermittent connectivity.

MQTT

MQTT was first proposed by the engineers at IBM and Arcom and was standardized in 2013 at OASIS. MQTT has a client-server model where IoT nodes act as a client that connects to a server known as a broker. MQTT was designed to be a lightweight protocol for devices with limited computational abilities to send data over constrained bandwidth networks. A possible scenario for the adaptation of MQTT was intended to be interconnected sensor networks that operate on the scale of thousands of nodes deployed in harsh physical environments.

The architecture of the MQTT protocol consists of a message broker, a client subscriber, and a client publisher. The broker maintains a topic subscription state and information about the clients. A client can publish messages on one or more topics, can subscribe to one or more topics, and can both simultaneously publish and subscribe. MQTT is implemented on top of the TCP IP and has a small overhead with minimized protocol exchanges to reduce network traffic. It also uses the publish/subscribe message mechanism so that clients can broadcast messages to many different channels. The protocol has three levels of quality of service (QoS);

MQTT has a small overhead and protocol exchanges are minimized to reduce network traffic. Figure 1a. illustrates the publish-subscribe process that the protocol is based on and Figure 2b. shows the MQTT message format. The message format is as follows; Message Type specifies the type of message including connect, connack (notification about disconnection), publish, subscribe, etc.; DUP stands for message duplication; quality of service is identified in the QoS field; Retain field stand for message retention, any message can be retained and publish as the first message to a new subscriber; and Remaining Length field indicates the remaining length of the message.

Figure 1a — Publish/subscribe process (Source)
Figure 1b — MQTT message format (Source)

CoAP

Constrained Application Protocol (CoAP) is a protocol designed for the “constrained” environments concerning the energy, computational power, and bandwidth of communication of devices that employ this protocol. CoAP was designed specifically to keep the message overhead small. The protocol was created by the IETF Constrained RESTful Environments (CoRE) working group and is officially defined as the application layer protocol for IoT, and as such, is a very popular data protocol for Smart City applications as well. The CoAP is based on REpresentational State Transfer (REST) which is a simple method for exchange of the data between HTTP clients and HTTP servers. However, CoAP differs from the REST because it is based on UDP and not TCP which makes CoAP more suitable for constrained Smart City applications. Furthermore, CoAP also modifies HTTP to meet the low power and resource-constrained operations (IoT applications). Additionally, since the CoAP was designed to resemble REST, two protocols can easily be translated using REST-CoAP proxies.

The protocol consists of two layers; messaging and request/response layer. Due to the implementation of CoAP over UDP, the transport layer the error recovery mechanism doesn’t exist. The error recovery is handled on the messaging level where duplicates of the messages are detected and a certain level of reliability is implemented. The request/response layer, on the other hand, handles modified REST-like communication. CoAP utilizes four types of messages: confirmable, non-confirmable, reset, and acknowledgment. Confirmable and non-confirmable messages are implemented to increase the reliability of the CoAP protocol. It can operate in four different modes as depicted in Figure 2.

Figure 2. — CoAP message types (Source)

The CoAP message format is shown in Figure 3. Messages are encoded in a simple and small format. Each message consists of the following fields; four bytes header; a token value (up to 8 bytes), options, and payload which are all optional fields.

Figure 3 — CoAP message format (Source)

The main advantages of CoAP protocol are;

Comparison

Two discussed protocols can be compared both qualitatively and quantitatively. Qualitatively, the comparison can be made regarding the communication pattern, transport protocol, reliability, design orientation, message detainment (caching), fragmentation, and discovery features. It is carried out based on official protocol documents.

Experimental Case Studies

Due to the popularity of MQTT and CoAP protocols, many researchers investigated how do these two protocols compare quantitively in terms of performance criteria. Thangavel et.al. studied the performance of two protocols using a common middleware. Aggregated sensor data was transported from the gateway node to the server/broker. The performance of two protocols was compared experimentally and the following conclusions were drawn;

The main conclusion from these authors was that MQTT is better in terms of reliability but generates more traffic.

In a separate study DeCaro et.al. compared these two protocols on the experimental basis as well. They also achieved a similar result where CoAP gives better results both in terms of bandwidth usage and round trip time. In terms of reliability, MQTT performs better due to the additional control mechanisms. However, MQTT’s reliability is only dominant when the data needs to be exchanged frequently.

Limitations

The main limitation of both protocols is that communication security is not explicitly addressed in the protocol implementation. One of the main reasons for this is due to their design goal of being lightweight with small overheads. Nevertheless, extensive security implementation is becoming more of a necessity than a luxury in Smart City applications. Both MQTT and CoAP benefit from the security related to their underlying medium of communication, TCP and UDP respectively. MQTT can be implemented over the Secure Sockets Layer (SSL) and CoAP uses Datagram Transport Layer Security (DTLS). Other layers of security such as user protection, sensitive content protection, and exchange of enhanced encryption keys are still missing. Possibly, MQTT and CoAP could embed application-level security algorithms soon.

Conclusion

MQTT and CoAP, the two most popular protocols for data exchange in constrained environments such as Smart City were analyzed. The thorough analysis uncovered the main underlying features of these two protocols, their main advantages, and disadvantages, their comparative analysis, and their limitations. MQTT is identified as a reliable pub/sub protocol for situations where tiny amounts of data need to be exchanged between client and server frequently. The integration of MQTT with the existing Internet services is somewhat complex and MQTT does not rate well when it comes to resource exposure. On the other hand, CoAP is based on the REST architectural style and easily integrates with the existing Internet services. However, CoAP is based on the UDP and inherently less reliable than MQTT. CoAP produces smaller amounts of traffic and is often a more preferred protocol for constrained applications. The main limitation of both protocols is the lack of security at the transport level. They both rely on the security schemes of the underlying TCP or UDP but fail to fulfill the basic needs of user protection, sensitive content protection, and exchange of enhanced encryption keys.

Inovatink

Your IoT Solution Partner

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store