Internet of Things and its Protocols

Author: Vaishali Singh


The Internet of Things (IoT)is a pretty cool concept. It simply means taking all the things in the world and connecting them to the internet. When something is connected to the internet, that means that it can send information or receive information, or both. This ability to send and/or receive information makes things smart, and smart is good.

The Internet of things (IoT) is the network of devices, such as vehicles and home appliances, which contain electronics, software, actuators, and connectivity that allows these things to connect, interact, and exchange data.

MQTT and CoAP are the Communications Protocols used for IoT. MQTT and CoAP allow for communication from Internet-based, resource-rich devices to IoT-based, resource-constrained devices.


MQTT (Message Queuing Telemetry Transport)

It is an ISO standard (ISO/IEC PRF 20922) publish-subscribe-based messaging protocol. It works on top of the TCP/IP protocol. It is an extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. The design principles are to minimize network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also make the protocol ideal for the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.

MQTT was invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link) back in 1999.

The main aspect of pub/sub is the decoupling of publisher and receiver:

  • Space decoupling
  • Time decoupling
  • Synchronization decoupling

Other aspects of the pub/sub model are:

CoAP (Constrained Application Protocol)

This is a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine and IoT applications, developed by Internet Engineering Task Force (IETF). Like https, CoAP provides a request/response interaction model between application end-points. It supports built-in resource discovery, and includes key web concepts such as URLs and content-types. CoAP easily translates to https for integration with the web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Restful Environments (CoRE) working group aims at realizing the REST (Representational State Transfer) architecture in a suitable form for the most constrained nodes. CoAP is not a replacement for https, but a new design, which comes with features to accommodate the limitations of https (i.e., computational complexity, low data rate, and high energy consumption).

CoAP employs a two-layered structure:

Comparison between MQTT and CoAP

  • MQTT is ideal for communicating between devices on a wide area network (WAN, internet) because of the publish/subscribe architecture with the broker in the middle, whereas in CoAP, UDP allows broadcast and multicast, and you can potentially transmit to multiple hosts using less bandwidth. This makes it good for local network environments where devices need to speak with each other quickly, which is traditional for some M2M settings.
  • MQTT is most useful in situations where bandwidth is limited, such as remote field sites or other areas lacking a robust network. CoAP is built on User Datagram Protocol (UDP) which can be useful in some resource-constrained environments.
  • MQTT is a part of Azure and Amazon service offerings(the big cloud players have picked it), so it has a lot of established architecture, making it easily adapted for current developers. For CoAP, the strongest use case is its compatibility with https. If you have an existing system that is web service-based, then adding in CoAP is a good option. It is built on UDP, which can be useful in some resource-constrained environments.


  • CoAP was started by a standards body as opposed to MQTT, which was originally designed by private companies, including IBM.
  • CoAP has been designed to handle resource-constrained environments and it may become the winner, but for the time being MQTT seems like it is in the lead.
  • There is significant momentum behind MQTT — the big cloud players have picked it. However, one possibility is that some software development that has standardized around https (mobile app development for instance) could start to leverage CoAP both for working with peripherals and to communicate to the back end to help reduce bandwidth on bad connections.

Vaishali Singh
An IoT enthusiast with a demonstrated history of working in Industrial Automation. Skilled in Amazon Web Services, AWS IoT Core, and Internet of Things . Currently working as a Software Development and Testing Specialist with eWandzDigital Services.