## 3 SLedge Model
### Architecture
Figure 4 shows this process: In the \(i\)th cycle, a mobile node is overloaded, so the system divides the flow of events between the node and a static node, giving both of them a weight of \(W_{x}\); in the \(i+1\)th cycle, the mobile node still is overloaded, so the system increases in \(2\alpha\) the weight of the static node decreasing the flow that is sent to the mobile node; in the \(i+2\)th cycle, the mobile node is underloaded, then the system increases the weight of the mobile node by \(\alpha\); in the \(i+n\)th cycle, the mobile node is in a healthy state. 4. Execution: The OM performs the actions defined in the previous phase. \begin{table}
\begin{tabular}{l c c c} \hline \hline  & **Cloud Server** & **Edge Server** & **Mobile Device** \\ \hline Processor & \(2\times\) Intel Xeon Silver 4116 & AMD Ryzen 7 3700\(\times\) & Exynos 9820 \\ Total Cores & \(2\times 24\) & 8 & 8 \\  & & & \(2\times 2.73\) GHz \\ Frequency & \(48\times 2.1\) GHz & \(8\times 3.6\) GHz & \(2\times 2.31\) GHz \\  & & & \(4\times 1.95\) GHz \\ RAM & \(128\) GB & \(16\) GB & \(8\) GB \\ Model & - & - & Samsung Galaxy S10 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Processing resources characteristics used in benchmarks. ### Fault Tolerance

The static part of this model inherits the Storm's checkpointing, which creates an additional spout specialized in the emission of checkpointing tuples. The stateful bolts receive the tuples and trigger the bolt's state to be saved, emitting the checkpointing tuple to the stream. For the mobile nodes, the model detects if the RM does not receive the resources report of an OM, assuming the device is unavailable. Moreover, if an OM detects a processing operator deployed in a mobile node downstream in the graph fails, it first verifies its reachability. It then changes the scheduling process to send all the events to the processing operator that replicates the missing operator in a static node. Figure 5 shows the recovery of the system when a downstream mobile processing operator fails. The OM replaces the missing processing operator with its static replica. If the node that fails is located upstream in the processing graph, the mobile operator starts receiving events from the failed node's static replica. Figure 4: Example of the weighted round–robin scheduling algorithm. We use the checkpointing-based approach proposed in [25] to decrease the number of event losses due to signal loss or battery drained in the device. Our model performs checkpointing in the mobile devices when the state of the resources is at a critical level (i.e., signal and battery) and every OM's MAPE cycle. In both cases, the OM manages the checkpointing mechanism, monitors the mobile device, and sends the checkpoint state to the deployed operator's static replica. With this mechanism, we can guarantee an at-least-once semantic for the processing events as the Storm system. However, we recommend using stateless topologies due to the mobile devices' volatility in a processing region, where a node may come in and out of the region multiple times. ## 4 Experimental Evaluation

The methodology used to evaluate SLedge is based on simulation, which allows experimenting with many devices and node's movements. We defined four stages: (1) experimental design, (2) benchmarking with real devices, (3) implementation in the NS-3 network simulator, and (4) experiment execution and analysis of results. In this section, we detail the main parts of the methodology. ### Experimental Design

In this evaluation, our goal is two-fold:

1. Compare a stream processing system executing in a cloud architecture versus SLedge, an edge architecture with integrated mobile devices. We aim at measuring the resources required at the edge to achieve an equal or greater performance than the cloud architecture and identify the trade-offs involved. Figure 6 shows both considered architectures.