## 3 Simulating MQTT-SN  
### Protocol Overview  
The MQTT protocol has emerged as the gold standard for IoT applications: as a matter of fact, all major cloud platforms (e.g., Amazon AWS, Microsoft Azure, and IBM) expose their IoT services through MQTT, and many IoT-related enterprises provide MQTT-based data collection and communication solutions.  
At the same time, MQTT requires an underlying reliable transport layer, such as TCP, that provides an ordered lossless connection capability. This may be either unavailable or too complex to handle for very simple, small footprint, and low-cost devices such as wireless sensors or in general smart devices used typically in IoT scenarios. This reason motivated the release of an adaptation of the MQTT over the UDP transport layer, with reduced size messages and additional lightweight functionalities to fit perfectly to the peculiarities of wireless sensor networks. This protocol takes the name of MQTT-SN (MQTT for Sensor Networks): a simple sketch of its architecture is reported in Figure 1.  
As one can see, in MQTT-SN, a Gateway device interconnects clients to a legacy MQTT broker. The role of the Gateway, which is often co-located with the broker, is to act as a translator between the two protocols, allowing the compatibility and integration of MQTT-SN with legacy MQTT applications. MQTT-SN introduces optimizations to adapt to the peculiarities of a wireless communication environment such as low bandwidth, high link failures and short message length. In particular, to cope with the latter issue, MQTT-SN allows us to refer to topics using small 2-byte topic identifiers, which are registered in the broker/gateways and mapped to legacy string-based topics. Other optimizations include the support of frequently sleeping clients through buffering, and reduced-length application layer connection procedures. In terms of QoS, MQTT-SN inherits the three MQTT quality of service levels, as described above, with an additional QoS -1 level to be used only from publishers to send messages skipping the connection phase. Clearly, due to the lack of a reliable transport layer such as TCP, QoS management at the application layer is a fundamental aspect for ensuring specific delivery performance.  
Giving the clients the capability of controlling the QoS to use for each published message allows the adaptation to different and dynamic network conditions. However, selecting the best QoS is not a trivial choice for clients, which may not be aware of the underlying network characteristics. Under bad network conditions, increasing the QoS clearly leads to an increase of the reliability, but at the cost of increasing the number of messages produced and the overall delay in the communication (which may be not affordable in strict real-time scenarios). Finding the best trade-off and hence the most performing QoS to use for sending/receiving messages is crucial for improving the communication efficiency. In the particular scenario of WSNs, bringing intelligence into the constrained devices in order to automatically adapt the QoS is not always possible, due to resource limitation. For this reason, this work sets the goal of building a reactive controller to be placed in the gateway/broker with the goal of optimizing the application layer quality of service of each client analyzing simple and easy to compute performance indicators derived from the communication network.