Modelling the Offload Decision

Based on the experimental results in Section 6.6, and the aim of not adding any additional overhead to the mobile device, a decision model for offloading over the cellular network connection is introduced. This model uses the variables outlined in Table 6.1.

The offload decision model is then defined as:

The three case stack in 6.7.1 has 3 possible outcomes. A priority variable p. If this is set to 1, then regardless of the signal strength r or battery percentage b, offload will take place immediately; hence o is set to 1. The user can specify if a task is high priority using the CAMCS Client. The second and third cases rely on a decide function, which encapsulates a set of rules to determine if offload should take place. If the device is connected to a Wi-Fi network, offload will always take place immediately, as the network is considered to be of superior quality when compared with the cellular network. However, the decision pro-cess can easily be applied to this connection as well, in terms of the battery power, or even extended further to take into account performance based on Wi-Fi signal strength. The decide function takes three parameters, r, s, and b.

The algorithm pseudo code is presented in Algorithm 1.

The comments in Algorithm 1 describe how the algorithm decides if the of-fload should occur. Any developer, or even the user, may choose their own battery policies for offload decisions; this is just one implementation. One may even leave the battery percentage values in the cases to the user to decide as a preference on the CAMCS Client. The important decision processes in this algorithm are the cases; offload does not occur if the signal strength is weaker than -100dBm. Otherwise, the size of the data offload and the current battery situation are both considered. For cases where the data offload size is greater than 500KB, in the results, the offload time would vary depending on the size.

For cases where the data offload size is less than or equal to 500KB, there was little difference in the offload times. As described in Subsection 6.6.1, for sizes below 500KB the time is mostly dominated by network overhead, rather than payload size. Where the battery drops to 10% or lower, the user more than likely wants to conserve the battery life of the device for important calls or messages, rather than having additional network activity occur.

It is worthwhile briefly mentioning a situation where the signal strength changes during the offload. If the signal strength weakens to a value less than

-Input: GSM signal strength r, data size s (in Kilobytes), battery percentage b Output: true if offload should occur, false otherwise

if −100 < r then; // If signal is weaker than -100dBm

return false ; // Do not offload

else

switch s do

case s > 500; // Case: data size greater than 500KB if b > 0.25 then; // If battery percentage is greater than 25%

return true ; // Offload

else

return false ; // Do not offload

case s <= 500; // Case: data size less than or equal to 500KB

if b >= 0.10 then; // If battery percentage is greater than 10%

return true ; // Offload

else

return false ; // Do not offload

endsw end

Algorithm 1:Algorithm Decide

100dBm, perhaps the offload should be suspended. This is not implemented in this model. If an offload has started, then regardless of how the signal strength changes, it should continue until completion. In the related works, disconnec-tion during offload is not discussed, except for in the MAUI framework [21].

With MAUI, if the mobile device suffers a disconnection from the cloud while code has been offloaded, after a certain timeout period, the local application will execute the offloaded code itself. This is a waste of resources in the case where offload has successfully taken place, but no result has been received.

The preference taken was that starting an offload in this model, and using up time and energy as a result, should not be made to count for nothing if the signal strength deteriorates.

This algorithm must be seen as a trade-off between accuracy and the zero-overhead goal. The related works perform more extensive network profiling as has been discussed, resulting in a more accurate picture of the network

con-ditions. This is at the cost of the overhead associated with the extensive profil-ing. The model used here is less accurate, since no additional network profiling takes place, and because the model is based on the GSM network, rather than the CDMA network. As the GSM measure does not take into account network traffic levels, or other measures such as the signal-to-noise ratio, the model is a guideline only, and does not guarantee optimal network quality at any given time, even when the GSM signal strength is greater than -100dBm. Essentially, it is used as a prediction of the network performance. However, using this model as a guideline for offloading, does meet the user experience aim of im-posing no additional overhead. Hence, it is used within the CAMCS Client as the basis for determining if queued tasks should be offloaded, or remain in the queue until a later time.