## 5 Results  
The performance of the developed smart fans was monitored using Amazon Cloudwatch and forcing a situation with frequent calls to Lambda. By setting a refresh time of 1 min for the OutState topic, the Lambda function responsible for updating the state database is called once every minute by the AWS IoT rule that handles messages received on the OutState topic. The function simply parses the JSON message forwarded to it by AWS IoT core, containing the new states and the identifier of the smart object, and updates a DynamoDB table with this new information, also increasing a usage atomic counter on the table to keep track of the usage of each smart device. Such a frequent refresh time might be incompatible with NB-IoT, given the high transmission load compared to the relatively low throughput expected of applications using this protocol, but more suitable to WiFi implementation. Furthermore, configuring the device so that the OutState topic is refreshed only when there is a state variable change is an implementation choice with an acceptable load for NB-IoT, and possibly a more realistic work condition for the smart home object. In the case of the Cloudwatch evaluation, the goal was to evaluate a situation with frequent calls to the serverless Lambda function; therefore, the number of state updates was incremented. The results of the evaluation are shown in Figures 6 and 7. The device was left on for about 24 h and the Cloudwatch Lambda insights service was used to keep track of various parameters. Figure 6 shows the median, 90 th percentile, and maximum duration of Lambda function calls, computed in intervals of 5 min. Figure 7 shows the maximum CPU usage time and network load during 24 h, computed in 5-min intervals. The spikes in duration correspond to \"cold starts\" that were also recorded by Cloudwatch. A cold start is the time required to allocate cloud resources to instantiate a Lambda function environment for the first time. Each Lambda function is only kept \"warm\" for a certain amount of time, requiring a new, prolonged startup to instantiate a new execution environment once the execution environment turns \"cold\". Setting up provisioned concurrency can help mitigate the effect of cold starts when there are multiple devices invoking the Lambda function. The results of the experimental evaluation carried out to evaluate the use of narrowband IoT to send MQTT messages through MQTT clients are shown in Figure 8. The delay has a mean value of 0.447 s, with occasional spikes of up to 11.41 s. The 90 th percentile is 0.527 s, and the standard deviation is 0.938 s. The contribution of \(\Delta\) is negligible and has minimal variations across multiple repetitions. To investigate the reason behind the spikes, the experiment was repeated keeping track of packet numbers and MQTT acknowledgment (ACK) messages received by the board. Having set the MQTT quality of service to 1, the MQTT broker forwards an ACK message toward the board whenever a message has been published correctly. The NB-IoT board firmware was therefore slightly modified so that, after an ACK is received from the broker, a second MQTT message containing the current ACK number and \(\Delta\) is also immediately published on Topic2. Client 2 therefore keeps track of the packet numbers, their associated timestamps, and the ACK numbers, besides computing the time difference between the timestamp of reception and the timestamp sent by Client 1, as in the previous experimental setup. The new experiment flow is detailed in Figure 9.  
Figure 6: Median, 90 th percentile, and maximum duration of a lambda function calls, computed in intervals of 5 min. Figure 7: Maximum CPU (**top**) and network (**bottom**) usage during the Lambda function testing, computed in intervals of 5 min. The iteration of the experiment described in the Figure comprises the following steps. At first, a packet P1 containing a timestamp T1 and packet number \(N1=1\) is sent to the  
Figure 8: Estimated latency from the NB-IoT device to the MQTT broker.