## 3 SLedge Model
### Architecture
3:for each \(mn\)in list_mn do
4:if\(mn.energy>energy\_threshold\)then
5:\(mn.energy=\)\"normal\"
6:else
7:\(mn.energy=\)\"low\"
8:endif
9:if\(mn.signal>signal\_threshold\)then
10:\(mn.signal=\)\"normal\"
11:else
12:\(mn.signal=\)\"low\"
13:endif
14:endfor
15:returnlist_mn
```  
**Algorithm 1** Critical resources' state categorization ```
1:\(type\leftarrow\) Mobile node type
2:Operator's ID to be replicated
3:procedureCalculatePriority(\(op\))
4:\(priority\gets 0\)
5:for each node in \(op\).replicasdo\(\triangleright\) List of nodes that replicate the operator \(op\)
6:if\(node\_type==\)low_endthen
7:\(priority\gets priority+priority\_low\_end\)
8:elseif\(node\_type==\)high_endthen
9:\(priority\gets priority+priority\_high\_end\)
10:endif
11:endfor
12:return priority
13:endprocedure
14:\(op\_min\_priority\gets M\)\(\triangleright\)\(M\) is a high number
15:for each op in list_opdo\(\triangleright\) List of operators in the topology
16:if\(op\_task==\)lightthen
17:\(op\_priority\gets priority\_light\_task+\textsc{CalculatePriority}(op)\)
18:elseif\(op\_task==\)heavythen
19:\(op\_priority\gets priority\_heavy\_task+\textsc{CalculatePriority}(op)\)
20:else
21:\(op\_priority\gets M\)
22:endif
23:if\(op\_min\_priority>\)\(op\_priority\)then
24:\(op\_min\_\gets op\)
25:elseif\(op\_min\_priority==\)\(op\_priority\)then
26:if\(op\_task==\)lightand\(type==\)low_endthen
27:\(op\_min\gets op\)
28:elseif\(op\_task==\)heavyand\(type==\)high_endthen
29:\(op\_min\gets op\)
30:endif
31:endfor
32:return\(op\_min\_id\)
```

**Algorithm 2** Operator selection

Figure 3: Example of mapping mobile resources. ### Event Flow and Load Balancing

We include mechanisms for balancing load and fault tolerance. For operators deployed over static nodes, the SPS uses the default communication model of the SPS. For the mobile nodes, the system uses the same [PERSON]'s model, a _push_ model, where the events are sent directly to the mobile nodes. The OMs coordinate the event distribution towards the mobile nodes. The number of upstream connections of an operator in a mobile device is limited to one; this restriction curbs network congestion and reduces the energy spent by the amount of event processed. Furthermore, the RM forbids the assignation of operators that have more than one downstream connection to mobile devices, avoiding multiple communication channels. We allow direct connections in the system between processing operators located on mobile devices to avoid a bottleneck in the cluster. Figure 3 shows an example of a flow of events among operators. We describe the exchanges between the static operators with a dashed line in the figure. The second level of the MAPE control loop manages local resources inside the mobile devices and implements a load balance mechanism:

1. Monitor: The OM measures CPU utilization considering the processor state, the I/O operations, and the memory usage. 2. Analysis: The OM decides if a mobile operator is _overloaded_, _healthy_, or _underloaded_ using two CPU utilization thresholds (high and low). This mechanism avoids consuming all the mobile node resources with the load assigned by the RM and assigns a sufficient amount of load to under-utilized nodes. 3. Planning: If the mobile node is overloaded, the OM changes the upstream node's scheduling algorithm to decrease the number of events received. The system offloads the remaining events to a static node that deploys a processing operator's replica. We use the weighted round-robin load algorithm that adapts the weights (representing the load of events) at each MAPE loop cycle. The algorithm decreases the number of events sent to an overloaded node while increasing the static replica's events. The scheduling process starts with equal weights and changes them in each loop until the device is no longer _overloaded_. In case a mobile node is underloaded, the system increases the weight of the underloaded node in the upstream node connection, so the number of events received by the node also increases.