## 3 SLedge Model
### Architecture
We represent the cloud architecture with a server at the Internet core that dedicates resources to execute more workers than one edge server or one mobile device can dedicate. 2. Evaluate the SLedge performance under different settings, such as the overload of mobile devices, increasing or decreasing the flow of events into the system, adding or removing devices to the pool of available resources, and failure of mobile nodes that are working as part of SLedge. ### Benchmarks and Parameterization

Aiming to simulate the environment for evaluating SLedge precisely, we implemented a benchmark with real devices for the three types of architecture components: the cloud server, the edge server, and mobile devices. In particular, we measured the time it takes for an event to go through a bolt in a Storm topology. We call this metric _processing latency_. The processing latency results are an input to the simulator, configuring the model with the measured behavior of the real components. Figure 5: Example scenario of a mobile node failure and fail over process in SLedge. In this benchmark, a real implementation of Storm is used. The Storm application topology used is presented in Figure 7. First, the _Image Spout_ emits a black and white image. The _Face Detection Bolt_ receives the image and detects the faces it contains using the Haar Cascade algorithm [30]. The _Face Detection Bolt_ emits a cropped image for each face. Finally, the _Face Recognition Bolt_ takes the cropped images and uses the LBPH algorithm [31] to recognize a face. This topology is simple and highly parallelizable, with bolts that do not save state (stateless). Table 1 presents the hardware characteristics of the devices that executed the topology, and Table 2 presents the benchmark results with the processing latency for each bolt and the number of workers that the device can deploy. The processor frequency and the number of workers per component impact the latency results. Even though the latency in the cloud server is higher than the other components, its throughput is higher since the processor allows more workers per server. On the other hand, SLedge forces only one worker per mobile node, which also produces minor congestion. We observe in the results that the lowest processing latency is obtained by the mobile device and the highest one is obtained by the cloud server. We attribute these to two factors: first, due to the parallelization capacity of each device, specifically, the cloud server has the greatest parallelization capacity due to its large number of cores, which allows it to process a greater number of events simultaneously, compared to edge server or mobile device. Furthermore, Second, because the restriction imposed by the SLedge system was respected, only one worker was hosted on the mobile device, which means that the processing queues are emptier, unlike the servers' behaviour which has the highest utilization possible. Figure 6: Architectures for experimentation: (**a**) Cloud Architecture and (**b**) SLedge Edge Architecture. Figure 7: Storm application topology used in benchmarks. From this benchmark, we establish the range of latency values for the simulation shown in Table 3. We uniformly generate latency values within the range. Besides latency, communication time is an important parameter to define for the simulation model. In order to simulate the network latency to the cloud, we assumed the distance between a server in S ao Paulo and Santiago, Chile ([[https://wondernetwork.com/pings](https://wondernetwork.com/pings)]([https://wondernetwork.com/pings](https://wondernetwork.com/pings)); accessed on 13 April 2021), which are common locations for datacenter infrastructure in South America. Finally, to simulate video feed processing, we define the size of each image frame using the distribution presented in [32] that found that the Pearson distributions are the best fit for the dataset used using both the graphical method and the hypothesis test.