## 3 SLedge Model
### Architecture
Finally, we analyze the network overhead produced by the SLedge system due to the coordination messages between the nodes and the managers RM and OM. In SLedge we have four types of messages: _checkpoint_, _overload_, _delete_, and _update_ messages. These messages represent the messages exchanged between the OM and the RM:

* CHECKPOINT: a checkpoint is performed. * OVERLOAD: a node becomes overloaded. * DELETE: to discard an active connection. * UPDATE: to update the node. To reflect changes in the number of available processing resources, we introduce a Gauss-Markov mobility model for simulating the mobile nodes' movements. Mobility triggers the fault tolerance mechanism that enables the system to create a checkpoint when the state of the resources is at a critical level (i.e., signal and battery). The energy model used and its parametrization was described in Section 4.3. Table 4 summarizes the number of messages sent of each type of message in this scenario. We collect 2,160,001 messages where 10.28% correspond to messages related to the system organization (22,226 messages). From the ten executions of the scenario, only an average of 0.1% of events were lost. SLedge system maintains a low overhead in the system to avoid draining excessive energy from the mobile devices; which is our main

Figure 10: Static nodes utilization over time under traffic spikes for Edge architecture. (**a**) Event Latency. (**b**) Mobile node utilization. (**c**) Static node utilization. concern. This result can be further diminished by lengthening the duration of the RM's and OM's cycles. There is a relation between the speed of change in the node's behavior and the number of messages that need to be exchanged to avoid data loss. As discussed in Section 3.1, we propose to deploy this system over semi-static nodes to maintain a low overhead of messages related to checkpointing. ## 5 Conclusions

In this article, we have proposed SLedge an edge-based processing model that enables the use of external processing resources such as mobile devices to support stream processing systems under post-disaster scenarios. The model consists of a two-level control loop that automatically schedules SPS's tasks over connected devices and balances the load they receive, considering mobile devices' characteristics and preventing draining of the devices' battery. We specifically tackle scheduling and load balance operators in an integration model with a pool of mobile devices to deploy small tasks as part of an SPS. The ability to exploit external processing resources (e.g., mobile phones, tablets, etc.) to allocate processing tasks brings resilience to the processing systems by provisioning resources to keep the systems running. In particular, stream processing systems are prompt to data loss and compromise their output accuracy. The latter is crucial in disaster scenarios where accurate and timely information is vital for saving lives or reducing the disaster's impact. Latency is critical in decision-making, SLedge provides a reduction of more than five times the event latency compared to a cloud architecture, as can be seen in Figure 8.

Disaster scenarios are highly dynamic scenarios where traffic can suddenly change. In this context, we demonstrate that SLedge can cope with such behavior by providing better load balancing than the cloud architecture. A better load balancing also enables the system to deal with traffic spikes. The latter is the main source of data loss in stream processing systems. Figures 9 and 10 validate our claims. SLedge arrives to distribute the load better, not overloading its resources while keeping nodes' utilization stable. Low utilization is a key feature for mobile processing resources in disaster scenarios since it can optimize battery energy. With Sledge, we can exploit external processing resources to analyze data in real-time to enrich government formal data sources and support decision-making.