## 5 COGNIFOG Evaluation in an IoT Connectivity Testbed
### Test Description and Results
As shown in Figure 8, during Stage 1, with no background traffic, the \(L\) of MQTT messages sent by the two analyzed IoT devices (IDs #167590 and #167 DEC) remains stable with values around 1 s. However, as soon as UDP background traffic is introduced in Stage 2, \(L\) starts to grow until reaching even more than 25 s in both evaluated devices between 12:04:00 and 12:05:00. \(L\) from both IoT devices also experiences remarkable drops during Stage 2. These are caused by the queue and buffer management mechanisms operating in network devices, which, when facing saturation, discard packets to manage the existing congestion. Be that as it may, a few seconds after the limitation of BW to background traffic is applied at the beginning of Stage 3, \(L\) values smoothly return to the previous stable ranges from Stage 1. \(D\) is considered here as the time difference between two consecutive received MQTT messages. As depicted in Figure 9, \(D\) remains relatively stable in Stage 1, with \(D~{}\approx~{}t_{\text{ESP}}\) and \(t_{\text{ESP}}~{}=~{}2\) s. However, during most of Stage 2, \(D~{}>~{}t_{\text{ESP}}\), occasionally reaching peaks over 3 s, which was primarily due to the existing background traffic that disrupts the regular reception of MQTT messages. In fact, the internal dynamics of queue and buffer management mechanisms under congested conditions contribute significantly to the fluctuations observed in \(D\) during this stage. But again, the benefits of applying the BW limitation become evident in Stage 3, where \(D~{}\approx~{}t_{\text{ESP}}\) after a brief transient period of approximately 30 s.  
Figure 10 represents with a bullet each MQTT packet from traffic type C correctly received by the edge server. Bullets are referenced by the message generation timestamp on the X-axis and the reception timestamp on the Y-axis. Consequently, the slope of the line formed by the succession of bullets is related to the timely transmission of periodic MQTT packets, while any gaps indicate packet loss. As it can be observed, the stability of the system during Stage 1 is disrupted in Stage 2, where the increasing degradation in the continuous reception of packets results in two noticeable time periods in which all MQTT packets are lost (just before 12:05:00 and 12:06:00). Nevertheless, the BW limitation implemented in Stage 3 facilitates the rapid transmission of stored MQTT packets at the beginning of this stage, subsequently restoring the stability observed in Stage 1. \begin{table}
\begin{tabular}{c c c c} \hline  & **Parameter** & **Description** & **Value** \\ \cline{2-4}  & \(T\) & Test duration & 600 s \\ \cline{2-4}  & \(C_{\text{UL}}\) & UL capacity & 4 Mbps \\ \hline \multirow{4}{*}{**Traffic type**} & \(R_{\text{UDP}}\) & UDP traffic generation rate & 8 Mbps \\ \cline{2-4}  & \(B^{\prime}_{\text{UDP}}\) & UDP bandwidth limitation & 2 Mbps \\ \cline{2-4}  & & \(n_{\text{SW}}\) & Number of simulated smartwatches & 150 \\ \cline{2-4}  & \(k_{\text{SW}}\) & Number of messages & 5 \\ \cline{2-4}  & \(k_{\text{SW}}\) & per smartwatch and transmission period & \\ \cline{2-4}  & \(t_{\text{SW}}\) & Transmission period of smartwatches & 2 s \\ \cline{2-4}  & \(L_{\text{SW}}\) & Length of a smartwatch message & 350 B \\ \cline{2-4}  & \(n_{\text{ESP}}\) & Number of real IoT devices & 2 \\ \cline{2-4}  & \(k_{\text{ESP}}\) & Number of messages & 1 \\ \cline{2-4}  & \(k_{\text{ESP}}\) & per IoT device and transmission period & \\ \cline{2-4}  & \(t_{\text{ESP}}\) & Transmission period of IoT devices & 2 s \\ \cline{2-4}  & \(L_{\text{ESP}}\) & Length of an IoT device message & 250 B \\ \hline \end{tabular}
\end{table} 
Table 1: Test configuration parameters. Figure 8: End-to-end computed \(L\) of the MQTT messages sent by the two IoT devices.