# A Performance Analysis of Internet of Things Networking Protocols: Evaluating MQTT, CoAP, OPC UA
## 3 An Overview on IoT Communication Protocols and Frameworks
### Mgtt  
The _Message Queuing Telemetry Transport_ (_MQTT_) protocol [13], developed by _IBM_ and currently an _OASIS_ standard is, in comparison to AMQP [9; 10] (ISO 19464), a lighter message-oriented protocol. It has been designed to support remote monitoring and as such it provides low latency, assured messaging over fragile networks, and efficient distribution of data to one or many receivers. Due to this, it became popular in _Machine-to-Machine (M2M)_ scenarios. It is TCP-based and asynchronous, and can integrate a publish-subscribe communication model.  
As with AMQP, MQTT relies on the notion of a broker which receives subscription requests from clients on specific topics and which receives messages from publishers and forwards them, based on the client's subscribe/publish policies on topics. MQTT brings in the advantage of having the possibility to consider multiple _Quality of Service_ (_QoS_) levels.  
Specifically focusing on Industrial IoT scenarios, there is a specific specification of MQTT, MQTT Sparkplug ([[https://github.com/eclipse/tau](https://github.com/eclipse/tau)]([https://github.com/eclipse/tau](https://github.com/eclipse/tau)) (accessed on 15 May 2021)), that defines a standardad MQTT namespace optimized for industrial applications. The specification considers an MQTT payload definition that is extensible, but that has been optimized for SCADA implementations. The specification also provides specific architectural design to address redundancy and scale. It is important also to highlight that MQTT can also in a \"request/response\" pattern, supporting one-to-one messaging that provides specific information based on parameters provided. The MQTT request-response pattern is not similar to a synchronous client/server approach request/response (such as the pattern of HTTP). With MQTT, a request, or a response, can have more than one (or none) subscriber. Moreover, correlation data assists in keeping the relation between request and response stable. The request-response pattern of MQTT is relevant in use-cases where there is the need for acknowledgement functionality.  
A first drawback of MQTT in the context of IoT is that it requires TCP support. TCP introduces more reliability but brings in issues in regards to mobility as well as to security. Therefore, MQTT considers SSL/TLS to provide secure communication and data encryption.  
A second drawback in comparison to AMQP is that it offers few control options, and real-time communication is considered to be in the order of seconds MQTT has been designed for reliability, and not for speed.  
On the other hand, a strong advantage of the MQTT design is scalability. It supports a large number of small, constrained devices, providing a simple way to ensure asynchronous communication of devices.  
MQTT has another strong advantage, which is the support of three classes of QoS to messaging: (1) fire-and-forget/unreliable; (2) \"at least once\" to ensure it is sent a minimum of one time (but might be sent more than one time), and (3) \"exactly once\".  
Finally, its lightweight design and compact binary packet payload are advantages in terms of IoT environments, as shall be further discussed in Section 3.8.