## 3 Simulating MQTT-SN
### Protocol Simulation  
Although some implementations of MQTT-SN brokers are available (e.g., Mosquitto ([[https://mosquitto.org/](https://mosquitto.org/)]([https://mosquitto.org/](https://mosquitto.org/)) (accessed on 15 October 2022))), in this work we opt for a simulated approach, which allows us to better control the network characteristics as well as perform large scale experiments easily. For the task at hand, we implemented a version of the MQTT-SN protocol in the NS-3 network simulation environment ([[https://www.nsnam.org/](https://www.nsnam.org/)]([https://www.nsnam.org/](https://www.nsnam.org/)) (accessed on 15 October 2022)). The framework allows us to simulate a network from the  
Figure 1: Sketch of the MQTT-SN architecture. application down to physical layer, furthermore allowing us to compute and keep track of all measures needed in order to build the QoS controller (i.e., communication delay, throughput, etc.). We focus particularly on the characteristics of the MQTT-SN protocol which are related to QoS (publish-subscribe mechanisms over UDP with retransmission mechanisms), without considering technical aspects such as, e.g., connection procedures at the application layer, topic registration or last will and testament messages. In details, we used NS-3 to implement a classic MQTT-SN network architecture composed by a MQTT-SN broker, a MQTT-SN gateway and the various client nodes (publishers, subscribers and interference nodes). The network topology is illustrated in Figure 2 and structured as it follows:  
* Client nodes connect to the broker through a IEEE 802.11b connection by means of a standard Access Point. The specific choice of 802.11b is motivated by the fact that the majority of commercially available Wi-Fi-enabled IoT devices work in the 2.4 GHz band and have no or very limited support for more recent amendments such as 802.11 ac/ax or for using higher frequency bands like the 5 GHz band. The physical layer is configured to have a bandwidth of 2 Mbit/s and a propagation delay of 2 \(\upmu\)s. All clients use UDP protocol over IP at the transport layer. * the MQTT-SN broker is directly connected to the access point through a point-to-point connection, with an ideal channel. In order to simulate a real WSN use case, we implemented three different types of client sharing the same 2 Mbps channel:  
* Publisher nodes: The origin of the MQTT-SN traffic; these nodes send messages to the broker at a certain rate with a specific payload to be delivered to all the subscribers (a single common topic is used)
* Subscriber nodes: The receiving end of the publish messages. After correctly receiving a packet from the publisher, the broker has to forward the publications to the subscribers that requested it (all of them in our case)
* Interference nodes: These nodes generate generic non-MQTT-SN traffic and have been introduced to create undesired traffic to mimic a real network scenario in which several devices share the wireless channel. To simplify the scenario, we consider only one topic in the network: therefore, every message transmitted by a publisher is received by the broker and forwarded to all subscribers. For each message published by the clients (or forwarded by the broker to the subscribers), the simulator allows to control its QoS level: specific retransmission procedures, where applicable, are implemented following the best practices of the MQTT and  
Figure 2: Simulator architecture. MQTT-SN protocol specification. For QoS 0, no retransmissions are expected. For QoS 1, the standard specifies a retry timer \(T_{retry}\) (in the order of seconds) and a retry counter \(N_{retry}\) (between 3 and 5 retransmissions). No indications are given on how to manage the retransmission timeout in case of a transmission failure. We implemented a simple approach according to which the retransmission timer is incremented linearly by 1 s for each retransmission. The maximum number of retransmission has been set to 4.