# Speeding up Smartphone-Based Dew Computing: In Vivo Experiments Setup Via an Evolutionary Algorithm

^{1}

^{2}

^{*}

## Abstract

**:**

## 1. Introduction

- (1)
- Define a workload;
- (2)
- Define the initial conditions for the testbed;
- (3)
- For each load balancing algorithm within the set of load balancing algorithms under evaluation:
- (a)
- Assure initial conditions for the testbed;
- (b)
- Run the workload on the testbed using the current load balancing algorithm;
- (c)
- Collect results for further analysis.

- –
- Inclusion of a multi-device battery preparation stage as an optimization problem that uses time-related battery (dis)charging events as input;
- –
- Proposal of an evolutionary algorithm to automate and minimize the battery preparation time, evaluated using real smartphone battery traces and several combinations of smartphone cluster sizes and target battery levels;
- –
- Publicly available evolutionary algorithm and simulation engine code, experiment configuration and battery traces for reuse and modification.

## 2. The Motrol Platform: Background on the Architecture and Basic Concepts

#### The Battery Preparation Problem for Running Synchronized Tests

## 3. Evolutionary-based Preparation of Smartphones for Synchronized Test Plans

#### 3.1. Input Data of the Component and Pre-Condition Considered

#### 3.2. The Designed Evolutionary Algorithm

_{c}to generate a pool of new solutions. In this sense, we designed a crossover process feasible for the used encoding of solutions, which generates new solutions by interchanging the sequences of actions indicated for the m smartphones in the parent solutions. Then, a mutation process is applied on each new solution with a probability P

_{m}to incorporate diversity in the pool of new solutions. In this respect, we designed a mutation process feasible for the used encoding of solutions, which generates changes in the sequences of actions indicated for the m smartphones. After that, each new solution is evaluated by the fitness evaluation process. Then, a survival selection process is applied on the current population and the pool of new solutions to decide which solutions will compose the new population for the next iteration. In this respect, the well-known steady-state selection process is applied [6], with a replacement percentage r, in order to preserve the best solutions obtained by the algorithm so far.

#### 3.2.1. Encoding of Solutions

_{1}, s

_{2}, …, s

_{m}>, where m is the number of smartphones considered, i.e., attached to the platform at the time the synchronized test starts. Then, the term s

_{i}(i = 1,…, m) represents a feasible sequence of charge/discharge actions (a

_{i}

_{1}, a

_{i}

_{2}, …, a

_{in(i)}) for smartphone i, which allows to reach sbl(i) (the start battery level corresponding to i) from cbl(i) (the current battery level of i). When cbl(i) is lower than sbl(i), cbl(i) must be increased; thus, sequence s

_{i}only includes battery charge actions. Otherwise, when cbl(i) is higher than sbl(i), cbl(i) must be decreased; thus, sequence s

_{i}only includes discharge actions. In both cases, the number, n(i), of actions of the sequence s

_{i}is calculated as detailed in Equations (1) and (2).

_{ij}(j = 1,…,n(i)) is represented as a tuple with five elements: <k_action, initial_level, finish_level, CPU_load, screen_state>, where k_action refers to the kind of battery-related action (i.e., charge/discharge), initial_level indicates the initial battery level for the action, and finish_level indicates the end battery level for the action. The element CPU_load refers to the CPU load under which the action increases/decreases from/to initial_level. As mentioned in Section 3.1, CPU load belongs to the set {0, 30, 50, 75, 100}%. Finally, the element screen_state refers to the screen state (i.e., on/off) under which the action increases/decreases from/to initial_level.

_{1}, s

_{2}, …, s

_{m}> is calculated as detailed in Equation (3).

#### 3.2.2. Fitness Evaluation Process

_{1}, s

_{2}, …, s

_{m}>, where s

_{i}represents a feasible sequence of charge/discharge actions to prepare the smartphone i, the process calculates the average difference (i.e., average error) between the time of each sequence s

_{i}and the minimum amount of time to prepare the m smartphones. This average difference is determined by a well-known metric named mean absolute percentage error (MAPE). This metric is calculated as detailed in Equation (4), where t(s

_{i}) refers to the time (milliseconds) of s

_{i}and T is the minimal possible time (milliseconds) to prepare the m smartphones. The term t(s

_{i}) is calculated by Equation (5), where t(a

_{ij}) represents the time (milliseconds) required to develop the action a

_{ij}. In this respect, the times of actions a

_{ij}are provided by the charge/discharge profiles of smartphone i.

_{i}), of the sequences s

_{i}detailed for preparing the m smartphones are closest to T. In these solutions, the times, t(s

_{i}), of the sequences s

_{i}are also closer to each other. Therefore, these solutions minimize the discharge of the m smartphones once these are prepared according to the sequences s

_{i}(i.e., once the start battery levels, sbl(i), are reached).

_{i}) of the sequences s

_{i}of two feasible solutions A and B for an example case where a set of four smartphones have to be prepared. These solutions differ considerably regarding their MAPE value. In this sense, the MAPE value of solution A (0.01%) is much better (i.e., much lower) than that of solution B (52.37%). This is because the times, t(s

_{i}), of solution A (i.e., t(s

_{1}) = 16,575,027, t(s

_{2}) = 16,575,096, t(s

_{3}) = 16,584,583, and t(s

_{4}) = 16,575,097) are closer to T than those of solution B (i.e., t(s

_{1}) = 5,819,963, t(s

_{2}) = 16,575,096, t(s

_{3}) = 1,623,840, and t(s

_{4}) = 7,560,004). As a result, the times, t(s

_{i}), of solution A are closer to each other. Specifically, the times, t(s

_{i}), of solution A have very low differences among them (i.e., differences are in the range of [1,9556] ms), whereas the times, t(s

_{i}), of solution B have very significant differences among them (i.e., the differences are in the range of [9,015,092, 14,951,256] ms).

_{3}) is the maximum of the times t(s

_{i}). Therefore, smartphone 1 will reach sbl(1) at t(s

_{1}), and so it will be prepared before smartphone 3 reaches sbl(3). Then, given that the time between t(s

_{1}) and t(s

_{3}) (i.e., 9556 ms) is not enough to decrease sbl(1), smartphone 1 will maintain sbl(1) until smartphone 3 reaches sbl(3). In a similar way, smartphone 2 will maintain sbl(2) and smartphone 4 will maintain sbl(4) until smartphone 3 reaches sbl(3). Thus, solution A prevents the discharge of the start battery levels sbl(i) reached by the smartphones. Unlike solution A, in solution B, the time t(s

_{2}) is the maximum of the times t(s

_{i}). Thus, smartphone 4 will reach sbl(4) at t(s

_{4}), and it will be prepared before smartphone 2 reaches sbl(2). Then, since the time between t(s

_{4}) and t(s

_{2}) (i.e., 9,015,092 ms) is long enough to decrease sbl(4), smartphone 4 will not be able to maintain sbl(4) until smartphone 2 reaches sbl(2). Likewise, smartphone 1 will not be able to maintain sbl(1) and smartphone 3 will not be able to maintain sbl(3) until smartphone 2 reaches sbl(2). Note that the decrease in the levels of sbl(4)/sbl(1)/sbl(3) (in battery units) depends on the time between t(s

_{4})/t(s

_{1})/t(s

_{3}) and t(s

_{2}). The longer the time between t(s

_{4})/t(s

_{1})/t(s

_{3}) and t(s

_{2}), the higher the decrease in sbl(4)/sbl(1)/sbl(3). Therefore, solution B enables the discharge of the start battery levels sbl(i) reached by the smartphones. All in all, solution A outperforms solution B in terms of minimizing the discharge of the smartphones once the start battery levels sbl(i) are reached.

#### 3.2.3. Crossover Process

_{c}to generate new encoded solutions. We designed a crossover process feasible for the encoding of solutions presented in Section 3.2.1. The details of this process is described below.

_{i}detailed in p1 and p2 for i, and after that analyzes one by one the actions, a

_{ij}, of each sequence. For each action, a

_{ij}, of the sequence s

_{i}detailed in p1(p2), the process considers the five elements which compose the action and then copies the values detailed in p1(p2) for k_action, initial_level, and finish_level to the new solution o1(o2), in the same positions for these values in p1(p2). Regarding the values detailed in p1(p2) for the elements CPU_load and screen_state, each of these values is copied to the new solution, o1(o2), according to a given probability, u. Specifically, for each of the mentioned elements, the process generates a random number in the range of [0,1]. If this number is lower than u, the process copies the value detailed in p1(p2) for the element to o1(o2), in the same position for this value in p1(p2). Otherwise, if this number is higher than or equal to u, the process copies the value detailed in p1(p2) for the element to o2(o1), in the same position for this value in p1(p2). Therefore, this crossover process allows the generation of two new encoded solutions by interspersing the values detailed in p1 and p2 for the elements of the actions of each sequence.

#### 3.2.4. Mutation Process

_{m}, so as to incorporate diversity into the pool of new encoded solutions, and thus to preserve the diversity of the population throughout the generations of the algorithm. We designed a mutation process feasible for the encoding of solutions presented in Section 3.2.1. The behavior of this process is described below.

_{i}

_{,}detailed in p1 for i, and then analyzes one by one the actions, a

_{ij}, of this sequence. For each action, a

_{ij}, the process considers the five elements that compose the action. Then, the process copies the values detailed in p1 for k_action, initial_level, and finish_level to the new solution o1, in the same positions for these values in p1. In relation to the values detailed in p1 for the elements CPU_load and screen_state, each one of these values is copied to the new solution o1 according to the mutation probability, P

_{m}. In particular, for each one of the two mentioned elements, the process generates a random number in the range of [0,1]. When this number is higher than P

_{m}, the process copies the value detailed in p1 for the element to o1 to the same position for this value in p1. On the other hand, when this number is lower than or equal to P

_{m}, the process does not copy the value detailed in p1 for the element to o1. In this case, the process randomly chooses other possible value for the element, and then copies this value to o1 to the same position for the value detailed in p1. Thus, this mutation process allows the generation of a new encoded solution by changing the values detailed in p1 for the elements of the actions of each sequence according to P

_{m}.

## 4. Computational Experiments

#### 4.1. Instance Sets

**Aspect S**. This aspect refers to the number of smartphones m considered in the instance. Here, this number belongs to the following set: {4, 8, 16}. Considering that the local facet of Dew computing comprises on-premise devices within the boundaries of a wireless local area network, aspect S corresponds to potential on-premise devices in a Dew computing setting, for which we selected 16 as an upper limit representing the number of devices a domestic router can handle without compromising the delivered QoS. Thus, three different categories were considered in relation to the number of smartphones, namely S4, S8, and S16.

**Aspect A**. This aspect refers to the total number of charge/discharge actions (1 percent battery level changes) to be applied by the m smartphones considered in the set to reach the desired start battery levels (i.e., the sum of current-to-target battery level differences of all smartphones considered in the instance). This number is named A, and is calculated as detailed in Equation (7), where actions(i) refers to the number of actions to be applied by smartphone i. Note that actions(i) is calculated as detailed in Equation (2) (Section 3.2.1). Thus, A belongs to the value range [1*m, 100*m]. In this value range, the value 1*m corresponds to the instances where each smartphone i must apply only one action to reach the desired start battery level from the current battery level, and the value 100*m corresponds to the instances where each smartphone i must apply 100 actions to reach the start battery level from the current battery level. This value range has been divided into three distinct subranges in order to consider three different categories in relation to A. Specifically, this range has been divided into the following subranges: [1*m, 40*m], [41*m, 70*m], and [71*m, 100*m], in order to define the categories Low A (LA), Medium A (MA), and High A (HA) with similar subrange width, respectively.

**Aspect V**. This aspect refers to the variation in the number of charge/discharge actions among the m smartphones considered in the set. In other words, it is a way to differentiate problem instances based on how the total number of actions (Aspect A) is distributed among participating smartphones. That is, a smartphone set where a few smartphones have to perform the majority of the total number of actions presents a quite different challenge regarding all of them performing the same percentage of the total number of actions. This variation is measured by a well-known metric named coefficient of variation (CV). This metric is calculated as detailed in Equation (8), where M refers to the average number of actions to be applied by the m smartphones (Equation (10)) and SD refers to the standard deviation of the number of actions to be carried out by the m smartphones (Equation (9)). Thus, this metric provides a real value in the range of [0,100]%. In this range, the value 0% corresponds to the instances where the m smartphones must develop the same number of actions to reach sbl(i) from cbl(i) (i.e., there is no variation regarding the number of actions among the m smartphones). This range also has been divided into three distinct subranges in order to consider three different categories in relation to V. In particular, this range has been divided into the following subranges: [0,10]%, [10,50]%, and [50,100]%, which determines the categories Low V (LV), Medium V (MV), and High V (HV), respectively.

#### 4.2. Experimental Setting

_{m}, note that one of the considered settings is 1/L. The term L refers to the number of elements on which the mutation is applied, with P

_{m}, in an encoded solution. In this case, as detailed in Section 3.2.4, given an encoded solution, the mutation is applied, with P

_{m}, on two elements of each action of each one of the m smartphones considered in the solution. Thus, L is equal to 2*(n(1) + n(2) + … + n(m)), where n(i) is the number of actions corresponding to the smartphone i in the encoded solution, as described in Section 3.2.1.

#### 4.3. Current Method to Prepare Smartphones in the Context of Motrol

_{i}, which allows the battery to reach the level sbl(i) from cbl(i) in the minimal possible amount of time for the smartphone i. When cbl(i) is lower than sbl(i), cbl(i) must be increased to reach sbl(i). Thus, the method defines a charge action, a

_{i}, which must be developed from the level cbl(i) and must continue until sbl(i) is reached. In addition, a

_{i}must be developed under a CPU load of 0% with the screen off to achieve sbl(i) in the minimum possible time for i. Otherwise, when cbl(i) is higher than sbl(i), cbl(i) must be decreased to reach sbl(i). Therefore, the method defines a discharge action, a

_{i}, which must be carried out from cbl(i) and must continue until sbl(i) is reached. Moreover, a

_{i}must be carried out under a CPU load of 100% with the screen on in order to achieve sbl(i) in the minimum possible amount of time for i. Finally, this method provides a solution, which is composed of the m actions a

_{i}defined to prepare the m smartphones.

_{i}, for each smartphone i, which allows Motrol to reach sbl(i) from cbl(i) in the minimum possible amount of time for the smartphone i. Thus, the action, a

_{i}, of each smartphone i is defined independently of the actions of the other smartphones in the set. Unlike this, the evolutionary algorithm explores many different sequences, s

_{i}, of actions for each smartphone i, with the aim of finding a sequence, s

_{i}, to collectively reach sbl(i) from cbl(i) at time T. As described in Section 3.2.2, T is the minimum possible time-taken to prepare the set of m smartphones. Second, this method does not consider the difference among the times of the actions, a

_{i}, defined for the m smartphones. In contrast to this, the evolutionary algorithm considers the difference between the time of the sequence s

_{i}determined for each of the m smartphones and the time T, and consequently considers the difference among the times of the sequences s

_{i}, which is important to minimize the discharge of the m smartphones once these are prepared according to the sequences s

_{i}(i.e., once the start battery levels sbl(i) are reached).

#### 4.4. Experimental Results

_{EA}(i.e., the solution given by the evolutionary algorithm), regarding the estimated discharge of the m smartphones once these are prepared according to s

_{M}(i.e., the solution given by the Motrol method). This metric is calculated according to Equation (11), where bud(s

_{M}, i) and bud(s

_{EA}, i) refer to the estimated discharge (in battery units) of smartphone i once it is prepared according to the solutions of s

_{M}and s

_{EA}, respectively. When the RPD value is positive, this means that s

_{EA}has achieved a saving when compared to s

_{M}in terms of the estimated discharge (in battery units) of the m smartphones once these are prepared.

_{1}, s

_{2}, …, s

_{m}> described in Section 3.2.1, we first calculated the preparation time t(s

_{i}) of smartphone i, by applying Equation (5) detailed in Section 3.2.1. After that, we calculated the maximal preparation time, MPT(s), of the m smartphones with Equation (12), which determines the preparation time of the set of m smartphones. As described in Section 3.2.2, when MPT(s) is higher than t(s

_{i}), smartphone i will be prepared (i.e., smartphone i will reach its start battery level sbl(i)) before the smartphones that require a preparation time of MPT(s). Thus, smartphone i will discharge its battery level, sbl(i), during the time between t(s

_{i}) and MPT(s). This discharge of sbl(i) (in battery units) depends on the time between t(s

_{i}) and MPT(s). The longer this time, the higher the discharge of sbl(i). Therefore, we calculated this time td(s, i), as detailed in Equation (13). Once td(s, i) is calculated, the estimated discharge (in battery units), bud(s, i), of sbl(i) during td(s, i) can be determined from the battery discharge profile of smartphone i (i.e., battery discharge profile inherent to a CPU load of 0% with the screen off).

_{1}, s

_{2}, …, s

_{m}>, where s

_{i}represents a feasible sequence of actions for smartphone i. Therefore, the computing time of these processes, and consequently the computing time of the algorithm, depend on the length of the encoded solutions. As detailed in Section 3.2.1, the length of the encoded solutions is proportional to the total number of actions to be applied by the m smartphones in the set. Thus, the higher the total number of actions, the higher the length of the encoded solutions; therefore, the higher the computing time of the evolutionary algorithm.

## 5. Related Work

## 6. Conclusions and Future Work

## Author Contributions

## Funding

## Institutional Review Board Statement

## Informed Consent Statement

## Data Availability Statement

## Conflicts of Interest

## References

- Ray, P.P. Minimizing dependency on internetwork: Is dew computing a solution? Trans. Emerg. Telecommun. Technol.
**2018**, 30, e3496. [Google Scholar] [CrossRef] [Green Version] - Hirsch, M.; Mateos, C.; Zunino, A.; Majchrzak, T.A.; Grønli, T.M.; Kaindl, H. A simulation-based performance evaluation of heuristics for dew computing. In Proceedings of the 54th Hawaii International Conference on System Sciences, Grand Wailea, Maui, HI, USA, 5 January 2021; pp. 7207–7216. [Google Scholar]
- Mateos, C.; Hirsch, M.; Toloza, J.; Zunino, A. Motrol 2.0: A Dew-oriented hardware/software platform for batch-benchmarking smartphones. In Proceedings of the IEEE 45th Annual Computers, Software, and Applications Conference (COMPSAC), Madrid, Spain, 12–16 July 2021; pp. 1772–1777. [Google Scholar]
- Hirsch, M.; Mateos, C.; Zunino, A.; Toloza, J. A platform for automating battery-driven batch benchmarking and profiling of Android-based mobile devices. Simul. Modell. Pract. Theory
**2021**, 109, 102266. [Google Scholar] [CrossRef] - Hirsch, M.; Mateos, C.; Zunino, A. Augmenting computing capabilities at the edge by jointly exploiting mobile devices: A survey. Future Gener. Comput. Syst.
**2018**, 88, 644–662. [Google Scholar] [CrossRef] - Eiben, A.E.; Smith, J.E. Introduction to Evolutionary Computing, 2nd ed.; Springer: Berlin/Heidelberg, Germany, 2015. [Google Scholar]
- Toloza, J.M.; Hirsch, M.; Mateos, C.; Zunino, A. Motrol: A hardware-software device for batch benchmarking and profiling of in-lab mobile device clusters. HardwareX
**2022**, 12, e00340. [Google Scholar] [CrossRef] [PubMed] - Hirsch, M.; Mateos, C.; Rodriguez, J.M.; Zunino, A. DewSim: A trace-driven toolkit for simulating mobile device clusters in Dew computing environments. Softw. Pract. Exper.
**2020**, 50, 688–718. [Google Scholar] [CrossRef] - Chen, J.; Ran, X. Deep learning with edge computing: A review. Proc. IEEE
**2019**, 107, 1655–1674. [Google Scholar] [CrossRef] - Mednieks, Z.R.; Dornin, L.; Meike, G.B.; Nakamura, M. Programming Android; O’Reilly Media, Inc.: Newton, MA, USA, 2012. [Google Scholar]
- Keur, C.; Hillegass, A. iOS Programming: The Big Nerd Ranch Guide; Pearson Technology Group: London, UK, 2016. [Google Scholar]
- Raspberry Pi Model 4B. Available online: https://www.raspberrypi.com/products/raspberry-pi-4-model-b/ (accessed on 1 August 2022).
- Ferrer, A.J.; Marquès, J.M.; Jorba, J. Towards the decentralised cloud: Survey on approaches and challenges for mobile, ad hoc, and edge computing. ACM Comput. Surv.
**2019**, 51, 1–36. [Google Scholar] [CrossRef] - Yousefpour, A.; Fung, C.; Nguyen, T.; Kadiyala, K.; Jalali, F.; Niakanlahiji, A.; Kong, J.; Jue, J.P. All one needs to know about fog computing and related edge computing paradigms: A complete survey. J. Syst. Archit.
**2019**, 98, 289–330. [Google Scholar] [CrossRef] - Mobile Operating Systems’ Market Share Worldwide. Available online: https://www.statista.com/statistics/272698/global-market-share-held-by-mobile-operating-systems-since-2009/ (accessed on 1 August 2022).
- Hirsch, M.; Mateos, C.; Zunino, A.; Majchrzak, T.A.; Grønli, T.M.; Kaindl, H. A Task Execution Scheme for Dew Computing with State-of-the-Art Smartphones. Electronics
**2021**, 1016, 2–22. [Google Scholar] [CrossRef] - Markus, A.; Biro, M.; Skala, K.; Šojat, Z.; Kertesz, A. Modeling Dew Computing in DISSECT-CF-Fog. Appl. Sci.
**2022**, 12, 8809. [Google Scholar] [CrossRef] - Javadzadeh, G.; Rahmani, A.M.; Kamarposhti, M.S. Mathematical model for the scheduling of real-time applications in IoT using Dew computing. J. Supercomput.
**2022**, 78, 7464–7488. [Google Scholar] [CrossRef] - Roy, A.; Midya, S.; Majumder, K.; Phadikar, S. Distributed resource management in dew based edge to cloud computing ecosystem: A hybrid adaptive evolutionary approach. Trans. Emerg. Telecommun. Technol.
**2020**, 31, e4018. [Google Scholar] [CrossRef] - Farkhana, M.; Hanan, A.A. Mobility in mobile ad-hoc network testbed using robot: Technical and critical review. Rob. Autom. Syst.
**2018**, 108, 153–178. [Google Scholar] [CrossRef] - Alvanou, A.G.; Zervopoulos, A.; Papamichail, A.; Bezas, K.; Vergis, S.; Stylidou, A.; Tsipis, A.; Komianos, V.; Tsoumanis, G.; Koufoudakis, G.; et al. CaBIUs: Description of the enhanced wireless campus testbed of the Ionian University. Electronics
**2020**, 9, 454. [Google Scholar] [CrossRef] [Green Version] - Appavoo, P.; William, E.K.; Chan, M.C.; Mohammad, M. Indriya2: A heterogeneous wireless sensor network (wsn) testbed. In Proceedings of the International Conference on Testbeds and Research Infrastructures, Shanghai, China, 16–18 November 2018; pp. 3–19. [Google Scholar]
- Falcón-Cardona, J.G.; Hernández-Goméz, R.; Coello, C.A.; Catillo Tapia, M.G. Parallel Multi-Objective Evolutionary Algorithms: A Comprehensive Survey. Swarm Evol. Comput. Computation
**2021**, 67, 100960. [Google Scholar] [CrossRef] - Normapp. Available online: https://github.com/matieber/livedewstream/tree/main/src/emanager_server/Normapp (accessed on 1 October 2022).

**Figure 6.**MAPE values and times t(s

_{i}) of two feasible solutions for an example case (Y axis is in milliseconds).

Instance Set | S | A | V (%) | Nr. of Instances |
---|---|---|---|---|

S4_LA_LV | 4 | [4, 160] | [0, 10] | 10 |

S4_LA_MV | 4 | [4, 160] | (10, 50] | 10 |

S4_LA_HV | 4 | [4, 160] | (50, 100] | 10 |

S4_MA_LV | 4 | [164, 280] | [0, 10] | 10 |

S4_MA_MV | 4 | [164, 280] | (10, 50] | 10 |

S4_MA_HV | 4 | [164, 280] | (50, 100] | 10 |

S4_HA_LV | 4 | [284, 400] | [0, 10] | 10 |

S4_HA_MV | 4 | [284, 400] | (10, 50] | 10 |

S4_HA_HV | 4 | [284, 400] | (50, 100] | 10 |

S8_LA_LV | 8 | [8, 320] | [0, 10] | 10 |

S8_LA_MV | 8 | [8, 320] | (10, 50] | 10 |

S8_LA_HV | 8 | [8, 320] | (50, 100] | 10 |

S8_MA_LV | 8 | [328, 560] | [0, 10] | 10 |

S8_MA_MV | 8 | [328, 560] | (10, 50] | 10 |

S8_MA_HV | 8 | [328, 560] | (50, 100] | 10 |

S8_HA_LV | 8 | [568, 800] | [0, 10] | 10 |

S8_HA_MV | 8 | [568, 800] | (10, 50] | 10 |

S8_HA_HV | 8 | [568, 800] | (50, 100] | 10 |

S16_LA_LV | 16 | [16, 640] | [0, 10] | 10 |

S16_LA_MV | 16 | [16, 640] | (10, 50] | 10 |

S16_LA_HV | 16 | [16, 640] | (50, 100] | 10 |

S16_MA_LV | 16 | [656, 1120] | [0, 10] | 10 |

S16_MA_MV | 16 | [656, 1120] | (10, 50] | 10 |

S16_MA_HV | 16 | [656, 1120] | (50, 100] | 10 |

S16_HA_LV | 16 | [1136, 1600] | [0, 10] | 10 |

S16_HA_MV | 16 | [1136, 1600] | (10, 50] | 10 |

S16_HA_HV | 16 | [1136, 1600] | (50, 100] | 10 |

Parameter | Value |
---|---|

Population size | 100 |

k (tournament selection) | 10 |

P_{c} (crossover) | 1.0 |

P_{m} (mutation) | 1/L |

r (steady-state selection) | 50% |

Number of generations or iterations | 2000 |

Parameter | Values Considered |
---|---|

Population size | {100, 200} |

k (tournament selection) | {2, 5, 10} |

P_{c} (crossover) | {0.7, 0.8, 0.9, 1.0} |

P_{m} (mutation) | {1/L} U {0.1, 0.2, 0.3} |

r (steady-state selection) | {25%, 50%} |

Number of generations or iterations | {1000, 2000, 3000, 4000, 5000} |

**Table 4.**Average, maximum, and minimum MAPE (%) value obtained by the evolutionary algorithm (EA) and the Motrol method (M) for each instance set. Bold values indicate better average MAPE (%) values. The symbol * indicates that the maximum MAPE (%) value reached by EA is lower than the minimum MAPE (%) value reached by M.

MAPE (%) | ||||||
---|---|---|---|---|---|---|

Instance Set | Average | Maximum | Minimum | |||

EA | M | EA | M | EA | M | |

S4_LA_LV | 17.09 | 46.66 | 64.11 | 70.56 | 3,E-04 | 22.31 |

S4_LA_MV | 12.19 | 48.07 | * 33.26 | 66.73 | 0.01 | 34.58 |

S4_LA_HV | 26.30 | 52.14 | 53.49 | 68.72 | 4.63 | 26.70 |

S4_MA_LV | 5.05 | 33.53 | * 12.51 | 43.64 | 2,E-05 | 19.13 |

S4_MA_MV | 8.26 | 37.48 | 25.96 | 47.53 | 1,E-04 | 21.26 |

S4_MA_HV | 17.99 | 50.37 | 36.87 | 65.05 | 1,E-03 | 34.56 |

S4_HA_LV | 3.80 | 31.43 | * 10.22 | 45.21 | 2,E-05 | 13.45 |

S4_HA_MV | 5.14 | 35.93 | * 19.95 | 48.84 | 1,E-04 | 22.49 |

S4_HA_HV | 10.74 | 45.25 | * 23.86 | 52.37 | 0.01 | 36.29 |

S8_LA_LV | 20.07 | 50.23 | 53.35 | 73.70 | 4.19 | 28.71 |

S8_LA_MV | 11.62 | 52.40 | * 27.99 | 62.00 | 2.32 | 38.80 |

S8_LA_HV | 15.75 | 57.88 | * 24.92 | 71.31 | 4.15 | 41.10 |

S8_MA_LV | 5.76 | 33.66 | * 11.30 | 45.77 | 3,E-04 | 19.21 |

S8_MA_MV | 16.15 | 49.84 | * 30.59 | 58.13 | 1.47 | 36.37 |

S8_MA_HV | 13.81 | 48.21 | * 27.63 | 55.87 | 0.01 | 36.78 |

S8_HA_LV | 5.72 | 40.60 | * 15.69 | 52.64 | 7,E-05 | 32.41 |

S8_HA_MV | 6.39 | 40.93 | * 19.22 | 57.58 | 0.01 | 29.26 |

S8_HA_HV | 16.51 | 49.29 | * 30.29 | 57.37 | 2.34 | 37.24 |

S16_LA_LV | 6.22 | 35.24 | *8.59 | 43.22 | 2.50 | 24.87 |

S16_LA_MV | 18.83 | 58.69 | * 25.76 | 65.45 | 9.37 | 54.63 |

S16_LA_HV | 25.45 | 61.99 | * 46.31 | 75.78 | 14.60 | 51.59 |

S16_MA_LV | 4.42 | 34.97 | * 10.38 | 50.27 | 2,E-03 | 24.70 |

S16_MA_MV | 15.42 | 55.39 | * 23.81 | 64.78 | 7.56 | 48.38 |

S16_MA_HV | 23.41 | 61.45 | * 36.31 | 67.81 | 14.75 | 53.77 |

S16_HA_LV | 4.87 | 35.31 | * 7.75 | 42.60 | 0.14 | 28.25 |

S16_HA_MV | 12.70 | 46.82 | * 22.34 | 52.11 | 7.57 | 37.75 |

S16_HA_HV | 16.99 | 49.82 | * 24.05 | 57.52 | 11.00 | 38.72 |

**Table 5.**Average, maximum, and minimum RPD (%) values obtained by the evolutionary algorithm for each instance set.

Instance Set | RPD (%) | ||
---|---|---|---|

Average | Maximum | Minimum | |

S4_LA_LV | 32.81 | 75.00 | 25.00 |

S4_LA_MV | 45.00 | 75.00 | 25.00 |

S4_LA_HV | 33.10 | 75.00 | 25.00 |

S4_MA_LV | 50.00 | 75.00 | 25.00 |

S4_MA_MV | 49.54 | 75.00 | 18.75 |

S4_MA_HV | 50.83 | 75.00 | 35.42 |

S4_HA_LV | 56.25 | 75.00 | 25.00 |

S4_HA_MV | 52.50 | 75.00 | 25.00 |

S4_HA_HV | 50.21 | 75.00 | 25.00 |

S8_LA_LV | 31.40 | 62.50 | 12.50 |

S8_LA_MV | 51.98 | 87.50 | 25.00 |

S8_LA_HV | 50.17 | 77.08 | 12.50 |

S8_MA_LV | 41.25 | 56.25 | 29.17 |

S8_MA_MV | 50.73 | 68.75 | 19.79 |

S8_MA_HV | 41.87 | 62.50 | 18.75 |

S8_HA_LV | 61.98 | 81.25 | 50.00 |

S8_HA_MV | 58.44 | 75.00 | 25.00 |

S8_HA_HV | 52.50 | 71.88 | 37.50 |

S16_LA_LV | 12.95 | 15.63 | 12.50 |

S16_LA_MV | 53.93 | 68.75 | 29.69 |

S16_LA_HV | 53.58 | 68.75 | 33.33 |

S16_MA_LV | 44.69 | 65.63 | 31.25 |

S16_MA_MV | 61.05 | 83.33 | 49.48 |

S16_MA_HV | 53.31 | 71.46 | 25.63 |

S16_HA_LV | 53.39 | 65.63 | 31.25 |

S16_HA_MV | 58.88 | 67.19 | 50.00 |

S16_HA_HV | 54.36 | 69.27 | 41.07 |

**Table 6.**Average, maximum, and minimum computing time (in seconds) required by the evolutionary algorithm for each instance set.

Instance Set | Computing Time (in Seconds) | ||
---|---|---|---|

Average | Maximum | Minimum | |

S4_LA_LV | 5.00 | 7.20 | 2.00 |

S4_LA_MV | 5.96 | 7.60 | 3.60 |

S4_LA_HV | 5.64 | 7.60 | 3.20 |

S4_MA_LV | 9.92 | 13.20 | 5.60 |

S4_MA_MV | 9.64 | 13.20 | 6.80 |

S4_MA_HV | 7.88 | 10.00 | 6.00 |

S4_HA_LV | 13.16 | 16.40 | 10.00 |

S4_HA_MV | 11.96 | 14.80 | 9.60 |

S4_HA_HV | 11.60 | 13.60 | 9.60 |

S8_LA_LV | 10.32 | 14.80 | 3.60 |

S8_LA_MV | 11.84 | 14.80 | 8.00 |

S8_LA_HV | 11.48 | 14.80 | 8.80 |

S8_MA_LV | 19.80 | 25.60 | 13.60 |

S8_MA_MV | 18.12 | 24.40 | 10.80 |

S8_MA_HV | 15.24 | 21.60 | 10.80 |

S8_HA_LV | 26.88 | 35.20 | 19.20 |

S8_HA_MV | 23.92 | 30.00 | 18.80 |

S8_HA_HV | 22.64 | 26.80 | 18.80 |

S16_LA_LV | 20.58 | 22.60 | 18.60 |

S16_LA_MV | 20.80 | 22.40 | 19.20 |

S16_LA_HV | 20.36 | 22.80 | 18.00 |

S16_MA_LV | 29.88 | 40.00 | 23.20 |

S16_MA_MV | 33.64 | 36.80 | 29.60 |

S16_MA_HV | 28.92 | 34.80 | 23.60 |

S16_HA_LV | 49.04 | 59.60 | 41.60 |

S16_HA_MV | 42.32 | 45.20 | 41.20 |

S16_HA_HV | 41.60 | 42.80 | 40.40 |

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |

© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Yannibelli, V.; Hirsch, M.; Toloza, J.; Majchrzak, T.A.; Zunino, A.; Mateos, C.
Speeding up Smartphone-Based Dew Computing: In Vivo Experiments Setup Via an Evolutionary Algorithm. *Sensors* **2023**, *23*, 1388.
https://doi.org/10.3390/s23031388

**AMA Style**

Yannibelli V, Hirsch M, Toloza J, Majchrzak TA, Zunino A, Mateos C.
Speeding up Smartphone-Based Dew Computing: In Vivo Experiments Setup Via an Evolutionary Algorithm. *Sensors*. 2023; 23(3):1388.
https://doi.org/10.3390/s23031388

**Chicago/Turabian Style**

Yannibelli, Virginia, Matías Hirsch, Juan Toloza, Tim A. Majchrzak, Alejandro Zunino, and Cristian Mateos.
2023. "Speeding up Smartphone-Based Dew Computing: In Vivo Experiments Setup Via an Evolutionary Algorithm" *Sensors* 23, no. 3: 1388.
https://doi.org/10.3390/s23031388