## 3 SLedge Model
### Architecture
### Experiments and Results

The scenario of the experiments that we carried out is a system that processes a video feed. We executed each simulation ten times, and computed average values and standard deviation values, represented in the graphs with \(\sigma\). The default parameters are the following:

* The number of events per second emitted by the camera is 60, corresponding to the number of frames per second. * Nodes are static during the participation in the SLedge system so no mobility model is required. * CPU utilization thresholds are 0.4 and 0.9 for low and high thresholds, respectively. * _energy_threshold_ is 15%. We employ the basic energy model provided by NS3. This model determines the energy spent in the transmission of a message (tx), in the reception of a message (rx), and a harvester (hv), that drains energy periodically from the device. We configured the values based on the benchmark results (Energy model parametrization values: rx = 3.373, tx = 3.373, hv = \(-\)0.179). We assigned an initial battery power randomly between 15% and 100% of the maximum device capacity (3400 mAh). * RM's MAPE cycle is 5 s.
* OM's MAPE cycle is 6 s.

In the first experiments, we analyze the contribution of the mobile nodes to the system in general, particularly how the event's latency is affected when changing the number of mobile nodes in the SLedge. We measure latency as the time an event goes through the whole topology, from the moment the spout generates the event until the terminal node consumes the event. The topology has two processing operators (bolts), with a replication of three nodes each. Twenty-five mobile nodes enter one by one in the SLedge system. Figure 8 shows the results. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Face Detection Bolt** & **Face Recognition Bolt** & **Number of Workers** \\ \hline Cloud Server & 25.871 ms & 47.462 ms & 12 \\ Edge Server & 15.272 ms & 29.171 ms & 6 \\ Mobile Device & 10.220 ms & 23.365 ms & 1 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Latency benchmark results. \begin{table}
\begin{tabular}{c c c} \hline \hline  & **Face Detection Bolt** & **Face Recognition Bolt** \\ \hline Cloud Server & 25.5–26.5 ms & 47.5–48.5 ms \\ Edge Server & 14.5–15.5 ms & 29.5–30.5 ms \\ Mobile Device & 9.5–10.5 ms & 22.5–23.5 ms \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Latency ranges for simulation. After a certain number of nodes enter the system, the contribution of new nodes becomes marginal to the latency reduction; this number is around ten mobile nodes in our simulations. This behavior results from the communication overhead produced by the distributed model of SLedge, where each worker is in a different mobile node. We conclude that the system should limit the number of mobile nodes allowed in SLedge at the same time, considering this latency measure if the data arrival rate is constant like in this scenario. However, in a dynamic scenario, the number of nodes that parallelize the processing system decreases latency changes. The adaptability and self-adjustment of the system are important, and in SLedge the number of nodes does not harm the latency metric; it only stops improving. In the next experiment, we simulate the system over both architectures described in Figure 6, the cloud architecture versus the SLedge model. We measure the event's latency to compare the systems. The delay between the end-user and the cloud server was set to 137 ms, while the number of mobile devices was set to ten nodes, considering the previous experimentation results. The result obtained in this simulation is that the average latency of events of the edge architecture is 42 ms and 228 ms for the cloud architecture. The edge architecture has a lower event latency since the data generation is much closer to where it is being processed. Moreover, even if we decrease the delay between the user and the cloud server, the edge architecture still performs better since the flow of events congests the server.