## 3 SLedge Model
### Architecture  
We propose an integration model for Apache Storm that extends the processing platform to support the use of external resources such as mobile phones, tablets, Etc. This model was designed to enable the SPS to provision external processing resources under post-disaster situations when traditional processing infrastructure may be scarce. In this model, we consider mobile phones as external processing resources due to their penetration in the country. The integration model proposed uses the MAPE control loop [27], a well-known model for self-adaptive systems composed of four phases: Monitor, Analyze, Plan, and Execute. We create a hierarchical MAPE control pattern of two levels, as shown in Figure 1. This two-level model enables to steer the system's adaptation. With multiple control loops, we can work at different time scales and manage different resources or different kinds of resources. This pattern provides a layered separation of concerns to manage the elasticity of complex systems [28]. Such hierarchical design allows overcoming the system bottleneck represented by the centralized components of the MAPE loop in the master-slave pattern for its application to elastic data stream processing, especially when the system is composed of a multitude of processing entities scattered in a large-scale geo-distributed environment [29]. Figure 1: Hierarchical integration model with MAPE control loops. At the highest level, the RM (Regional Manager) builds and maintains the cluster with the available mobile nodes. At the lowest level, the OM (Operator Manager) monitors and coordinates the mobile node at a local level, considering the operators deployed inside. Different groups of devices may collaborate with computing power, which we call processing _regions_. The devices connected to the same access point constitute a region. Moreover, an SPS may use several regions that interact independently with the central SPS cluster. The physical nodes (static and mobile nodes) in the architecture are the operator's containers. We classify the operators according to their function in _source operators_, _processing operators_, or _terminal operators_. The source operators (spouts in Storm terminology) capture data from external sources and transform data into events to send them downstream into the graph topology. It is possible to have more than one source operator. We differentiate between the Storm's bolts to maintain persistence, making two groups of operators, processing and terminal: mobile devices can only host processing operators but no terminal operators. Those operators receive events from upstream nodes and send them downstream in the graph. A terminal operator, on the other hand, is where the processed data converge. The terminal operator outputs the processed information towards databases, visualization tools, a new stream of events, and the like. Within a processing region, we define the following components:  
* Region Manager (RM): It is located in a static node and coordinates and monitors the region. * Operator Manager (OM): It is located in the nodes that interact with the processing operator hosted by mobile devices. It is responsible for the communication with the RM and OMs of the nodes connected downstream and upstream in the processing graph. This component manages load balance among mobile devices. Figure 2 shows the integration between the components of our architecture and Storm's architecture. We include the RM alongside Nimbus for the control of the nodes and the OM with the Worker Supervisor for the node's administration. A node is considered different in our model if deployed in a mobile device or a static device; we call them _mobile node_ (MN) and _static node_ (SN). A _static node_ is a common SPS node deployed in a cluster machine that is permanently connected to electric power and the Internet. A _mobile node_ is deployed in a mobile device that shares its processing power with an SPS.