Workflow-Oriented Greedy Autonomous Offload Algorithm

We now present a Workflow-Oriented Greedy Autonomous Offload (WGAO) Algorithm to pro- duce offload strategies for mobile workflows, as shown in Algorithm 3. In this algorithm, we apply a similar structure to that of the Greedy Autonomous Offload (GAO) algorithm which we developed in Section 3.4.2 of Chapter 3.

We partition WGAO into two stages so that it can be implemented on the mobile nodes and the workflow’s monitoring server respectively. The first two procedures (line 1 to 20) of our algorithm are executed by the workflow engine. WGAO-Main(line 1) traverses the list of tasks

and communicates with each task’s host to see if any offload action is possible. If the host’s feedback is positive, then the workflow engine tries to construct an offload tree cluster with that task being the root usingWGAO-Tree (line 11).

The third procedure (line 21) is implemented on the smartphones and helps its host to find the best possible offload point for its tasks according to the environmental parameters it gathers in real-time. For each of its tasks, out of all cloudlets that satisfy both time and energy constraints (if any), it selects the one which gives the largest amount of energy savings as its

offload destination. A user has the ability to set a task’s property to “isfixed” in order to protect the relevant content from being offloaded. At line 25Nc(nlti)represents the set of cloudlets that are visible to taskti’s local mobile node at that time.

The following document some of the algorithm’s desired properties that we identified in designing the algorithm:

Autonomous Decision Making Ability Each participating smartphone node should have

the ability to make simple offload decisions based on the environment it is currently situated in without prior knowledge or instruction from the server. A mobile wireless data connection, especially when implemented over a cellular network, is prone to connectivity disruption. In such cases, the isolated node should be able to carry on executing its own tasks in an energy- efficient manner. WGAO-Device is designed to take on such duty.

Offload Authorisation Not all resources on a mobile device are dedicated to a specific

workflow. Although an offload action might be beneficial to the overall performance of the workflow, the owner of the device should still be able to have the authority to stop a task and its relevant data to be offloaded. Examples of which include sensitive or private information that the user is not prepared to share; extra financial expenditure for using a faster wireless connection in range, etc. Hence the isfixed property as used inWGAO-TreeandWGAO- Device.

This is especially true in choosing the type of wireless connections for the smartphone nodes. In practice, although 3G and WiFi modules can be enabled at the same time on a smartphone, it is normally up to the local OS to decide which connection is to be used for data transfer tasks. A remote workflow decision engine’s role is to give advice to the user rather than altering the existing settings on the device.

Furthermore, as discussed in Section 3.1.3, some tasks are not suitable to be offloaded. This includes user interface processes, I/O components and processes that are observed by external processes that require the output to be produced on the local node only [22, 24, 37, 80].

Task Clustering Offloading two tasks to the same cloudlet greatly reduces the energy con-

4.2 Offload Strategies for Mobile Workflows

Algorithm 3Workflow-Oriented Greedy Autonomous Offload

1: procedure WGAO-Main(W)

This procedure is executed by the workflow engine, triggered by the changes in network conditions or periodically.

2: sortworkloads in setW in topological order 3: forti∈T do

4: if ti.nof f ==nullthen

5: if WGAO-Device(ti)≠nullthen

6: _WGAO-Tree(ti) 7: end if 8: end if 9: end for 10: end procedure 11: procedure WGAO-Tree(ti) 12: fortj∶ (tj∈T∧ (ti, tj) ∈E)do

13: if tj.nof f==null∧ ¬tj.isf ixedthen

14: if EPM(ti, nc) ∧ EPM(ti, nc) then 15: tj.nof f←ti.nof f 16: WGAO-Tree(tj) 17: end if 18: end if 19: end for 20: end procedure 21: procedure WGAO-Device(ti)

This procedure may either execute on the mobile devices or on the workflow engine.

22: nc←null

23: gmax← 0 // maximum energy saving

24: if ti.isf ixedthen return nc end if

25: for allnj∈Nc(nlti)do 26: if EPM(ti, nc) ∧ EPM(ti, nc) ∧Gl(ti) −Gr(ti, nc) >gmax then 27: nc←nj 28: gmax←Gl(ti) −Gr(ti, nc) 29: end if 30: end for

31: if nc≠nullthenti.nof f←nj end if

32: returnnc

belong to different smartphone nodes, clustering essentially eliminates the need to transfer data over a wireless connection between the mobile nodes. In WGAO-Tree, once a task

has been approved to offload to a cloudlet, we then attempt to exploit the same offload route and offload the same task’s leaf tasks to the same cloudlet. Recursive calls toWGAO-Tree

expand the offload cluster.

Update on Event Mechanism The outcome of the decision making process depends heav-

ily on the mobile node’s real-time environmental parameters. Thus accuracy of this infor- mation directly affects the offload’s efficiency. However, it is expensive in both time and energy to constantly update the information onto the server [81], especially when no changes have occurred between updates. One solution to this problem is to use the wake-on-event mechanism provided by the mobile’s operating systems [51], especially on events like entering a WiFi zone or moving into the range of a Cloudlet as demonstrated in [82].

Our algorithm is designed so thatWGAO-Device is triggered on the handset when signifi-

cant change has occurred in its network connectivity. Updated information including a new local offload plan is then feedback to the workflow engine.