## 6 M2M Application Protocols
### Mqtt  
MQTT, developed by researchers at IBM, is a lightweight broker-based publish-subscribe messaging protocol designed to be open, simple, lightweight, and easy to implement [55]. The authors claim that MQTT's characteristics make it ideal for use in constrained environments, where, for example, the network is expensive, has low bandwidth or is unreliable, or when it runs on embedded devices with limited processing or memory capacities. MQTT does not comply with REST.  
MQTT is an asynchronous protocol. Some MQTT messages contain a variable header, present after the fixed header and before the payload, that contains, for instance, the protocol name, the protocol version, and flags. There are 14 different message types defined in MQTT, including CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, DISCONNECT, and PINGREQ and PINGRESP. Several of these messages have dedicated acknowledgement messages. For example, if an MQTT subscriber wants to subscribe to a topic, the subscriber sends a SUBSCRIBE message, and waits for the correspondent SUBACK response from the broker (server).  
Even though the use of MQTT implies the use of a reliable connection oriented transport protocol, like TCP, MQTT supports three types of application reliability to the delivery of publish messages:  
* deliver message exactly once, which guarantees that messages arrive exactly once;
* deliver message at least once, which guarantees that messages arrive, but duplicates may occur;
* deliver message at most once, where messages arrive according to the best efforts of the underlying TCP/IP network, which means that message loss or duplication, introduced by software or other causes, can occur.
These options are selected in the QoS flag present in the header of each MQTT message.  
The protocol has a small header whose fixed-length is just 2 bytes, and protocol exchanges are minimized to reduce network traffic. The standard does not specify security mechanisms, therefore IPSEC or TLS can be used.  
MQTT for Sensor Networks (MQTT-S) [63] is an extension of MQTT. MQTT-S is optimized for the implementation on low-cost, battery-operated devices with even more limited processing and storage resources, such as wireless sensor devices. While MQTT is based on the TCP/IP stack, MQTT-S operates on any network technology that provides a datagram service, like UDP. MQTT-S is aimed at minimizing network bandwidth and device resource requirements while targeting reliability. Additionally, an MQTT-S gateway can be integrated in the broker to translate between MQTT-S and MQTT.  
Figure 4 illustrates the concepts of transparent and aggregating gateway. A transparent gateway sets up and maintains an MQTT connection to the MQTT broker for each connected MQTT-S client. The gateway only performs translation between the two protocols. The implementation of this type of gateways is simpler than the implementation of an aggregating gateway. The use of an aggregating gateway requires only one MQTT connection to the broker. While connections at the transparent gateway are end-to-end (client to broker), connections with an aggregating gateway end at the gateway (client to gateway) that then decides which information will be given further to the broker [63]. Therefore, there is a trade-off between complexity and scalability of the gateways' implementation.