## 4 Experimental Evaluation  
An experiment was carried out to evaluate the use of narrowband IoT to dispatch MQTT messages across MQTT clients. The goal of the experiment was to provide an estimation of the time needed to forward a message to/from an MQTT client over NB-IoT  
Figure 4: Architecture of the proposed smart fan application.  
Figure 3: Messages flow from the user command up to the MQTT message generated by AWS that is forwarded to the device.  
to show whether the protocol is suitable for applications, such as the one developed in this paper, that require an acceptable latency performance to ensure a good user experience.  
The experiment involves the following nodes  
* An MQTT Client (Client 1) that publishes messages on a dedicated topic named Topic1;
* An MQTT broker;
* A NB-IoT module subscribed to Topic1 and publishing on a dedicated topic named Topic2;
* A second MQTT Client (Client 2) subscribed to Topic2.  
This experimental setup is shown in Figure 5. The two MQTT clients might represent cloud applications sending or receiving messages from a smart object, such as vocal commands or state updates, while the NB-IoT device stands for the smart object itself. This setup reflects the interaction between users and the smart extractor fan system, where client 1 might be a Lambda function publishing a command on the broker to control the NB-IoT module/smart fan, which will then immediately publish a status update on the OutState topic once it sets the correct output variables.  
At the start of the evaluation, the board registers to the NB-IoT network, connects to the MQTT broker, and it subscribes to Topic1. At the same time, the two clients also establish a connection to the MQTT broker, and Client 2 subscribes to its assigned topic. After waiting a short time to ensure that each MQTT client has successfully connected to the broker, Client 1 will publish a first message on Topic1, containing a timestamp \(T1\) representing the start of the communication. The broker then forwards the message to the evaluation board. The board will then publish a new message on Topic2 containing \(T1\) and the time elapsed between reception of the first message from the broker and the transmission of the second message. The broker will forward this message to Client 2, which will save the timestamp of reception (\(T2\)). This information, alongside the one obtained from the first client, the board, and the broker, is used to evaluate latency at different sections of the communication. The procedure is repeated multiple times at intervals of 10 s between each message.  
The two MQTT clients were implemented on a computer using the Paho-MQTT [62] Python library. The MQTT broker was deployed on a different machine in the same  
Figure 5: Diagram of the evaluation testbed used to evaluate NB-IoT latency for dispatching MQTT messages.  
network. The broker of choice was the Eclipse' Mosquito [63] broker. The MQTT clients are synchronized using the network time protocol. The NB-IoT module is connected to a mobile IoT network, which provides acceptable network coverage and reliability. In debug mode, Mosquito does not provide a precision for packets logging below the second. However, the time difference between the transmission of the packet and its reception on the broker is not higher than a second, as verified on the Mosquito log file. Therefore, considering symmetrical links and a negligible delay for the communication between the clients and the broker on the same network, the communication delay between the broker and the smart object was estimated as  
\[T_{NB-IoT}=\frac{T_{2}-T_{1}-\Delta}{2},\]  
in which \(\Delta\) represents the time elapsing between the reception of the message on the board and the transmission of a message toward the broker.