Continuous Testing for DevOps Teams

IoT Testing : Decoding the underlying protocols

2 years ago
Qapitol QA > Blog > IoT > IoT Testing : Decoding the underlying protocols
qapitol qa testing IoT

IoT Testing : Decoding the underlying protocols

  • IoT, Quality
  • No Comments
  • Sreedhar

iOT (internet of things) is the newest or rather trendiest edition in the ever changing world of technology.  As much as ‘iOT’ is interesting, it is equally challenging to crack the core of it when it comes to the testing of the softwares, devices, sensors and overall internet of things.

An effective testing for anything as per say requires a good understanding of the requirement, components involved, endpoints and overall end to end knowledge of the system to be tested. Same goes for internet of things. It’s vital to understand the underlying protocols used, communication mechanism, and difference between them to use them wisely.

This article talks about various protocols available for iOT and explains two of them in detail.

There are many options to communicate with electronics and devices, following could be few to name:

  • Bluetooth 
  • Zigbee 
  • Z-Wave 
  • 6LoWPAN 
  • Thread 
  • WiFi 
  • Cellular 
  • Sigfox 
  • Neul
  • LoRaWAN

Though there are two protocols (MQTT and CoAP) that are most promising iOT protocols for small devices.

MQTT and CoAP both are suited because:

  • They are open standards 
  • Run on IP 
  • Provides mechanism for asynchronous communication


MQTT stands for message queue telemetry transport which is a publish/subscribe protocol for lightweight M2M communications. It was originally developed by IBM and now is an open standard.

MQTT has a client/server model, where every sensor is a client and connects to a server, known as a broker, over TCP.

MQTT is message oriented. Every message is a discrete chunk of data, opaque to the broker.

Every message is published to an address, known as a topic. Clients may subscribe to multiple topics. Every client subscribed to a topic receives every message published to the topic.

For example, assume a network of three devices A, B, and C with a broker(server) as D.

In this scenario A,B and C can publish or subscribe a topic. Broker D will validate and send the topic to the respective client. Say C has subscribed to a topic as Weather Forecast, now if any other client in the network publishes Weather Forecast broker D will send it to client C.

In MQTT, topics has hierarchical system same as a file system (D:/Publisher/Topic/WeatherForecast). There are two variations + and # in the hierarchy. If any client has subscribed to ‘Weather Forecast +’ it can access D:/Publisher/Topic/Weather Forecast/Rainy and if client has subscribed to ‘Weather Forecast #’ it can access D:/Publisher/Topic/Weather Forecast/Rainy/Gloomy .

For the validation of topics being received and sent MQTT has three levels of quality of service:

  • QoS
    Fire and Forget level, where broker sends the topic to the clients and forget it without having a confirmation of topic being delivered
  • QoS1
    Delivered at least once, where broker sends the topic and make sure that respective clients receive the topic at least once
  • QoS2
    Delivered exactly once, where broker sends the topic and make sure that clients receive the topic exactly once

MQTT also has message persistence, it allows broker to persist the messages sent from clients on request. Only the last persistent message is stored and sent to the clients if they have subscribed to that topic.

To provide a secured communication broker may require username and password from the clients to connect while to maintain the privacy TCP connection may be encrypted with SSL/TLS.


CoAP is the Constrained Application Protocol from the CoRE (Constrained Resource Environments) IETF group.

Like HTTP, CoAP is a document transfer protocol. Unlike HTTP, CoAP is designed for the needs of constrained devices.

CoAP packets are much smaller than HTTP TCP flows. Bit Fields and mappings from strings to integers are used extensively to save space. Packets are simple to generate and can be parsed in place without consuming extra RAM in constrained devices.

CoAP runs over UDP, not TCP. Clients and servers communicate through connectionless datagrams. Retries and reordering are implemented in the application stack. Removing the need for TCP may allow full IP networking in small microcontrollers. CoAP allows UDP broadcast and multicast to be used for addressing.

CoAP follows a client/server model. Clients make requests to servers, servers send back responses. Clients may GET, PUT, POST and DELETE resources.

CoAP is designed to interoperate with HTTP and the RESTful web at large through simple proxies.

Because CoAP is datagram based, it may be used on top of SMS and other packet based communications protocols.

Requests and response messages may be marked as “confirmable” or “non confirmable”. Confirmable messages must be acknowledged by the receiver with an ack packet.

Non Confirmable messages are “fire and forget”.

In CoAP, like HTTP content negotiation is done. Client use ACCEPT option to express the interest in a particular representation of a resource while servers reply with a CONTENT_TYPE option to tell clients what they are getting.

Because CoAP is built on top of UDP not TCP, SSL/TLS are not available to provide security. DTLS, Datagram Transport Layer Security provides the same assurances as TLS but for transfers of data over UDP.

CoAP has an OBSERVE flag option, which allows server to continue to reply a get request even after the initial document is sent.


MQTT and CoAP are both useful as IoT protocols, but have fundamental differences.

MQTT is a many-to-many communication protocol for passing messages between multiple clients through a central broker. It decouples producer and consumer by letting clients publish and having the broker decide where to route and copy messages. While MQTT has some support for persistence, it does best as a communications bus for live data.

CoAP is, primarily, a one-to-one protocol for transferring state information between client and server. While it has support for observing resources, CoAP is best suited to a state transfer model, not purely event based.

MQTT clients make a long-lived outgoing TCP connection to a broker. This usually presents no problem for devices behind NAT. CoAP clients and servers both send and receive UDP packets. In NAT environments, tunnelling or port forwarding can be used to allow CoAP, or devices may first initiate a connection to the head-end as in LWM2M.

MQTT provides no support for labelling messages with types or other metadata to help clients understand it. MQTT messages can be used for any purpose, but all clients must know the message formats up-front to allow communication. CoAP, conversely, provides inbuilt support for content negotiation and discovery allowing devices to probe each other to find ways of exchanging data.

Both protocols have pros and cons, choosing the right one depends on your application.

Write to us at: [email protected]

Call: +0044 7850 987 161 (UK),  +91 98450 08696 (India)

Author: Sreedhar