**3.1 MQTT: message queue telemetry transport**

Created by IBM in 1999, MQTT is an open source protocol designed to be simple, lightweight and easy to implement. It is a messaging protocol based on the

**Figure 2.** *Simplified version of high-level architecture.*

*Interaction Protocols for Multi-Robot Systems in Industry 4.0 DOI: http://dx.doi.org/10.5772/intechopen.97481*

In **Figure 2** a simplified version of the M2M architecture is presented, where important elements of the architecture are shown, in addition to defining the

The authors in [6] categorize M2M systems into two types, namely dynamic M2M systems and static M2M systems. The main difference between the two is its topology, where in dynamic systems, some nodes (for example, M2M devices and M2M gateways) are moving, that is, the topology is changing over time, resulting in a change in the quality of communication, and dynamic resource allocation. Examples of dynamic M2M systems include: vehicle M2M system, the medical M2M system and the robotic M2M system. In contrast, the topology for static M2M systems remains unchanged for a relatively long time, as an example the M2M

There are several communication protocols responsible for managing the transfer of data between computers on the internet, among them we can mention some examples such as HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) and SFTP (SSH File Transfer Protocol). When the communication needs to be made between two or more devices (or several applications) connected in a network, the need arises to have a protocol that manages this communication, that is, the exchange of data between the devices in an efficient way considering the characteristics and restrictions imposed by the environment. According to [4], in this scenario, two protocols arise that can be used in restricted environments: Messaging Queue Telemetry Transport (MQTT) and the Constrained Application

The following will present the MQTT and CoAP protocols, identifying their main characteristics and limitations, in addition to highlighting the best scenarios

Created by IBM in 1999, MQTT is an open source protocol designed to be simple, lightweight and easy to implement. It is a messaging protocol based on the

where each can be applied in the context of Industry 4.0.

**3.1 MQTT: message queue telemetry transport**

power system, domestic M2M system and the industrial M2M system.

application domain.

Protocol (CoAP).

**Figure 2.**

**158**

*Simplified version of high-level architecture.*

**2.2 M2M systems categories**

*Robotics Software Design and Engineering*

**3. M2M communication protocols**

*publish/subscribe* architecture (**Figure 3**), which has a small transport overhead (fixed byte header of 2 bytes), making MQTT an interesting solution for unreliable networks with limited resources, such as bandwidth and high latency [4]. This protocol is based on a broker (**Figure 4**) using the message pattern *publish/ subscribe*, while the server broker acts as a intermediary for messages sent from a device that publishes to subscribing customers, providing a distribution of one-tomany messages decoupled from the use case of the application.

For a client to send a message, it needs to publish it in a topic (called a MQTT broker) (**Figure 4**). If another client wants to receive the content of this message, he will have to subscribe to this same topic. A client can publish or subscribe to multiple topics at the same time, and there may be situations where the publication or subscription on a topic is disputed between different clients, thus having a system that is asynchronous [7].

The PDU (Protocol Data Unit) of the MQTT protocol is encapsulated by the TCP (Transmission Control Protocol) protocol, that is, the MQTT header and data are sent in the TCP data area [8]. In this way, the MQTT protocol messages have a fixed header (**Figure 5**) composed of two bytes, where the first byte contains the field that identifies the type of message, such as also the markers (DUP, QoS level and RETAIN). There is a version of MQTT, called MQTT-SN (MQTT Sensor Network), where PDU is encapsulated by the UDP protocol, which, in turn, is encapsulated by the IP or the 6LowPAN protocol. One of the main differences between two standards, in addition to the network layer they focus on, is the simplification of

**Figure 3.** *Broker Publisher/subscriber messaging template.*

**Figure 4.** *Publisher/subscriber messaging template.*


end-to-end larger, but no lost messages at this level. The higher the level of QoS, the greater is the packet exchange. If the loss of messages a problem, a lower level of QoS can be used, resulting in less consumption of available bandwidth and less end-to-end delay, which represents limited networks wired or wireless. To further reduce the use of the band, the UDP can be used instead

The Constrained Application Protocol (CoAP), created by the Internet Engineering Task Force (IETF) working group called restricted RESTful environments (CoRE), has been adapted from HTTP, being optimized for devices with limited processing power and capacity, generally applied to intelligent objects in IoT environments [9]. CoAP acts on the UDP transport layer, specifying a minimum set of restrictions such as POST, GET, PUT and DELETE, with some support for resource

According to [10], CoAP is a transfer protocol aimed at nodes and restricted networks, being designed for M2M applications, such as home automation. CoAP has four types of messages: Confirmable, Non-confirmable, Acknowledgmente and

• Confirmable (CON): Are those messages that need confirmation at the

• Non-confirmable (NON): They are those messages that do not require acknowledgment of receipt, being very useful for applications that receive constant readings in a short period of time, where the loss of one or the other

• Acknowledgment: These are the messages that confirm receipt of a messages,

• Reset: Its function is to indicate that an NOC or NON message was received, but for lack of some context the same could not be properly processed. It can occur in case a device has restarted and the message sent was not properly

The COAP uses the request/response model, where devices act as a client or as a server, supporting service discovery and include Web services such as the Uniform

• The Coap message exchanges are transported over UDP, and encoding the same are made in binary format with a 4 byte header (**Figure 7**), followed by a

• It has a binary header UDP-based transport, causing thus less delay and

• HTTP mapping that allows proxies to provide access to CoAP resources.

• Asynchronous message exchange, allowing smart objects to send information

of TCP, but with reduced guaranteed message delivery [9].

**3.2 CoAP: constrained application protocol**

*Interaction Protocols for Multi-Robot Systems in Industry 4.0*

*DOI: http://dx.doi.org/10.5772/intechopen.97481*

storage and discovery of embedded resources.

message does not affect the process;

Reset.

destination;

Confirmable;

interrupted.

**161**

Resources Identifiers (URIs) [9].

The following are the main features of the COAP:

reduced battery consumption during transmission;

variable width token (0 to 8 bytes);

only when the application changes;

#### **Figure 5.**

*Fixed header of an MQTT message.*


**Figure 6.** *QoS levels.*

messages exchanged between broker and clients, using predefined topic identifiers and short names of topics in addition to a short message format [7].

According to [8], the PDU of the MQTT protocol is encapsulated by the TCP protocol, that is, the MQTT header and data are sent in the TCP data area (**Figure 5**). In this way the MQTT protocol messages have a fixed header (**Figure 5**) composed of two bytes, where the first byte contains the field that identifies the type of the message, as well as the markers (DUP, QoS level and RETAIN). There is a version of MQTT, called MQTT-SN (MQTT Sensor Network), where your PDU is encapsulated by the UDP protocol, which, in turn, is encapsulated by the IP or the 6LowPAN protocol. One of the main differences between two standards, in addition to the network layer they focus on, is the simplification of messages exchanged between broker and clients, using predefined topic identifiers and short names of topics in addition to a short message format [5].

As can be seen in **Figure 5**, "byte 1" is responsible for four fields:


end-to-end larger, but no lost messages at this level. The higher the level of QoS, the greater is the packet exchange. If the loss of messages a problem, a lower level of QoS can be used, resulting in less consumption of available bandwidth and less end-to-end delay, which represents limited networks wired or wireless. To further reduce the use of the band, the UDP can be used instead of TCP, but with reduced guaranteed message delivery [9].
