Survey of Foraging Techniques

1,011 views

Published on

A survey of Cyber Foraging and Cloud Offload Techniques.
We present a survey of cyber foraging and
cloud computing techniques as a solution to aid computing on resource-constrained mobile devices. We also explain some
important cyber foraging systems and present a categorization of the existing approaches considering various factors like
their dynamics, granularity, metrics used, surrogate types and their overheads.

Published in: Education, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,011
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Survey of Foraging Techniques

  1. 1. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 1A Survey of Cyber Foraging & Cloud OffloadTechniquesDeepanker Aggarwal, Sahil Jain, Soumyavardhan Singh,Vinayak Chopra, Yash LambaAbstract—In the present day scenario, the number of mobile devices i.e. (smartphones and tablets) are fast outnumberingthe traditional non-mobile devices. Today’s users expect to be able to run powerful, resource-intensive applications onmobile devices. They even expect the same performance from the applications irrespective of them running on a mobile-device or a traditional computer. Whilst mobile devices are very powerful, they still are a decade behind in terms ofcomputing abilities as compared to traditional computers. This follows from the fact that mobiles are constrained by weight,size, and mobility in spite of all the advancements in recent years. Cyber-foraging is one solution that has been proposedto combat this problem. It involves taking help from the nearby non-mobile computers called surrogates. These surrogateshelp the mobile device by running whole or parts of applications on behalf of the mobile device. Some application evenleverage machines available on the cloud for performing the computations. We present a survey of cyber foraging andcloud computing techniques as a solution to aid computing on resource-constrained mobile devices. We also explain someimportant cyber foraging systems and present a categorization of the existing approaches considering various factors liketheir dynamicity, granularity, metrics used, surrogate types and their overheads.Keywords—Cyber Foraging, Cloud Computing, Cloudlets, Offload, Virtual Machines, Internet Suspend/Resume!1 INTRODUCTION“The most profound technologies are those thatdisappear. They weave themselves into the fabric ofeveryday life until they are indistinguishable fromit.” [1] This is how Mark Weiser, the chief architectof pervasive computing envisaged the idea. At thetime of proposing the idea, it seemed a far-fetchedone. However, following the developments in dis-tributed computing and mobile computing, perva-sive computing today seems to be more likely [2].Pervasive computing talks of small devices whichare required to perform powerful computations,but are small enough in size so as to fit into thisindistinguishable idea.The modern day mobile devices fit into this ideaat least with respect to the size part. The currentmarket share of operating system is very positivefrom the aspect of pervasive computing. Android +iOS, both of which are Mobile OSs, take up a mam-moth 65% share. With mobile computing and wire-less Internet, the dream of accessing informationanywhere and anytime is getting closer to reality[3]. However, mobile devices are resource poor [4].Weight, size, battery life, and most importantly heatdissipation impose severe restrictions on computa-tional resources such as processor speed, memorysize and disk capacity [4]. The following will givea nice idea of the nature of cyber foraging. Bob iswaiting for his flight at the airport. He suddenlyreceives a voice message from a colleague in French.Unfortunately, Bob is not fluent in French. Bobwants to use a language translation application toconvert the email from French to English. However,this is a resource consuming application, and hismobile device wont be able to do it. Now, themobile detects a server nearby which can providecomputing resources to the phone. The phone sendsmost of its computing tasks to the server; whichreturns the result to the phone after the computa-tion. Bob is able to understand the message and actaccordingly.With the increase in power of mobile devices,people expect their devices to be able to run re-source expensive applications like the ones men-tioned in the above example; and this falls in linewith the idea of pervasive computing. For long,researchers have been focusing on applications thatcan do just a bit extra. Researchers have beencoming up with wonderful applications rangingfrom context detection to aiding Alzheimers pa-tients with a head-up display in the form of eye-glasses, a camera for scene capture and earphones[4]. Unfortunately, any such application requireshigher computing power, memory, and battery life-
  2. 2. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 2time. Even if mobile devices are able to providesufficient computing power and memory, batteryand heat dissipation limit the deployment of suchapplications. Although researchers have come upwith innovative solution to remove the problem ofbattery life, the current solutions are not sufficient[5][10].Offloading computations whether to nearby sur-rogates or to the cloud is one of the solutions thatenables running the aforementioned applications.The architecture for cyber foraging is made up ofa client and surrogates. The client is the resourceconstrained device, while the surrogate is a serveror a desktop computer that possesses a high com-puting capacity. The connection between the clientand surrogate is through the wireless connection.In the following sections we discuss cyber forag-ing in detail. Section 2 gives an overview of cyberforaging. It discusses the feasibility of offloading,the general steps that are common in all foragingsystems and the factors that affect the decision tooffload. Section 3 puts forward the use of surro-gates as a performance enhancement technique forforaging systems. Section 4 explains a few of thetraditional cyber foraging systems. Section 5 givesan introduction to foraging systems that use virtualmachines. Section 6 discusses a few systems thatmake use of the cloud, including a cloning basedsolution. Section 7 mentions a few performance im-provement techniques that have been incorporatedin the cloud based systems. Section 8 is dedicatedto the concept of cloudlets, while section 9 dis-cusses an application that tries to take advantage ofopportunistic networks to offload computations. Acomparison of the aforementioned systems is givenin section 10. Finally, section 11 and 12 discuss themajor challenges and the current research in thisdomain.2 MECHANISM OVERVIEWThe term “cyber foraging” was first introduced byRajesh Balan and Satyanarayanan [10]. This mecha-nism was introduced to augment the computationaland storage capabilities resources of a wireless mo-bile device by utilising available static computers. Itwas initially aimed at improving the performance ofinteractive applications and distributed file systemsusing nearby computers. However in recent years,cloud computing has also been used for cyber for-aging. [11] [20].Although mobile devices can benefit from of-floading their tasks to Clouds, there are some addi-tional challenges in employing Clouds as surrogatesfor cyber foraging. There is no guarantee of avail-ability of surrogates and application service levelin computational Clouds [20]. Cloud services aregenerally paid [20] and require a device to alwaysbe online [17]. 3G is still not upto the requiredstandards in terms of bandwidth, latency [18], [19],[21]. Despite of all challenges, in some scenariossuch as when there is no surrogate in the vicinity ofmobile devices, the employment of cyber foragingin clouds would be useful [4], [22].2.1 FeasibilityOffloading is not reasonable in all situations. Of-floading is required only when a mobile devicelacks the sufficient amount of memory or storageto run a program. It may also be that a mobile hasthe required amount of resources, but does not haveenough battery to allow the computation. However,the decision to offload or not, is not made notonly on the basis of the mobile device, but alsothe surrogates nearby. The availability of resourceson surrogates and the amount of resources requiredfor offloading are important factors that need to beconsidered while offloading. Since, cyber foraging isused to improve response time or energy consump-tion, the offloading mechanism is more effective forapplications requiring more computation than com-munication such as a game of chess or generationof very large prime numbers.Cyber foraging involves striking a balance be-tween execution times and communication times.In order to maximize the benefit, we need to makesure that the cost of execution outweighs the costof communication. Next comes another practicalissue that is posed by mobility itself. It may bepossible that a task is quite large and before itsexecution is completed the mobile-device has tomove out of the vicinity of the surrogate. In sucha scenario, offloading to a nearby machine is notof too much use, since it requires the introductionof checkpointing and various other time-consumingsolutions. In such, scenarios obviously using thecloud is more ideal, but again brings the questionof communication costs into the picture. As a re-sult, a suitable offloading approach must speciallyconsider the mobility nature of mobile devices andmanage a trade-off between mobility and task size.
  3. 3. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 3Fig. 1: Flow of running a mobile application [38]2.2 StepsBroadly we can classify the process of cyber for-aging into the steps mentioned below. (These stepstake into account the scenario when the surrogatesare not on the cloud) :-• Surrogate Discovery - [23] - [26] deal withsurrogate discovery.• Context Gathering - It involves monitoring theresource levels of the nearby surrogates andmobile devices in question. The context alsoinvolves estimates of the resource consump-tion of the application. [30], [31] talk aboutcontext gathering.• Partitioning - While partitioning, a task isdivided into smaller size subtasks. [12], [27]focus on partitioning.• Scheduling - Scheduling involves assigningtasks to the surrogate, based on the contextinformation. [23], [28], [30], [31] deal with thisstep.• Remote Execution Control - This step involvesconnecting to the surrogate and performingremote execution on the transferred material.The final results are collected from the surro-gate during this phase only [24], [30], [31].2.3 Factors Affecting the Decision to OffloadThe decision to offload or not is based upon anumber of factors. The specifications of the clientand the surrogates, the specifications of the appli-cations, the network and the context all determinethe feasibility of offloading. Specifications of theclients and surrogates are important since thereis a lot of variability in processors, memory andstorage capacities of devices and so every time adecision has to be made the total cost of using asurrogate is measured in terms of processor cycles,memory size, storage size, communication trafficrate, input data size, and execution time of thechosen surrogate. In case of the cloud, the financialcost of surrogating comes into play as well.The nature of the application plays a crucial roleas well. Offloading is of more use to processorintensive applications as compared to memory orstorage intensive ones. However, just being proces-sor intensive is not important. It may be the casethat some parts of an application are dependent onthe local device and as a result cannot be sent to asurrogate even though it is computationally expen-sive or the speed of the network and the bandwidthare less for a particular application because of which
  4. 4. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 4Fig. 2: Factors influencing offloading decision [38]the decision to offload may need to be changed.Finally, the resource availability on both theclients and the surrogates plays an important role.Since, a surrogate may be catering to the demandsof other clients as well, the levels of resource con-sumption keeps on fluctuating. However, irrespec-tive of the above factors the users have the ultimatesay, because it is their data that has to be offloadedand they have a better idea of what they need froman application. A user may want to save batterywhereas another may want accurate results evenif it is at the cost of battery. Hence, the decisionmaking process itself is quite complicated.3 USING SURROGATES FOR DATA STAGINGThe first main works on cyber foraging consideredsurrogates to be untrusted and unmanaged ma-chines which make use of widespread and reliablesoftware. A surrogate was supposed to be state-less, and was independent of the file system. Datastaging constituted an important part of the cyber-foraging system. Data staging is the prefetching andcaching of files by a surrogate in order to improvethe performance of the client [29]. The main ideabehind data staging is to remove bottleneck createdby the communication in the network. The mainidea is to cache the files that are mostly likely to beaccessed in the future. This prediction is done usinga prediction algorithm.Data staging takes place as follows: - A proxyresiding on the client manages the communicationbetween the file client and the surrogate, file serverand the data pump. Data pump is a module thathoards files for the client proxy and is alwayspresent on a idle desktop belonging to the user.The proxy on detecting the existence of a surrogate,registers with the surrogate. When the client proxyneeds to stage a file, it sends a message to the datapump. The data pump authenticates the message,reads the file from the file server, encrypts thefile, generates a cryptographic hash, transmits theencrypted file to the surrogate, and sends the filekey and hash to the client. If a file staged on thesurrogate is read by the application, the client proxyfetches the file from the surrogate, decrypts the file,and checks if the file has been modified. Prefetchingon a surrogate can reduce the latency for access-ing files from the remote distributed system. Sincefiles are encrypted on data pump and decryptedon client proxy, this framework provides securityfeatures for the files during transmission.Prefetching has its own challenges. In case theprediction goes wrong, we may end up using moreresources. However, Flinn proved that on tradi-tional desktop computers, prefetching often givesdecent results. Thus, data staging helps in over-coming the problem between efficiency and limitedresources in mobile systems. The execution timesare down by 26%-54% depending on the size of the
  5. 5. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 5cache on the mobile device, the network bandwidthbetween the data pump and the surrogate, andwhether some files have already been cached onthe mobile devices cache. However, this idea ofuntrusted and unmanaged surrogate, lost tractionwith time and other works by the same authors onlyinvolved trusted machines.Fig. 3: Data Staging Architecture [29]4 USING SURROGATES FOR REMOTE EXECU-TION4.1 SpectraSpectra [31] is one of the earliest proposed cyberforaging systems. The main focus of Spectra is toreduce latency and energy consumption. Spectracomes with a special feature called self-tuning.As the name suggests the purpose of self-tuningis to monitor the application behaviour and theresource consumption. Based on real-time data, itestimates the resources needed to execute an appli-cation. Mathematically, Spectra makes use of linearregression to model resource demands in terms ofapplication fidelity and input parameters for furtherprediction of future resource demands. However,Spectra does not separate the energy rate of an idle,computing or communicating mobile device whileestimating energy consumption. It simply monitorsenergy consumption of local execution and remoteexecution. Consequently, the estimations of Spectrabecome inaccurate when the input data of a taskchanges. Moreover, Spectra monitors battery levelbefore and after execution. Therefore, Spectra doesnot use the monitored data, when some tasks exe-cute in parallel. Thus, the required time to reach agood estimation about energy consumption of eachtask increases.Spectra is only usable for applications with pre-installed corresponding services on surrogates. Forany such application the application developer isrequired to follow the cyber foraging steps in Spec-tra manually. This produces a significant addition inthe application code. A normal application and anapplication built to use Spectra are vastly different.An application is required to call Spectra beforeexecution to determine the execution location ofeach operation. Following which the application isresponsible for executing operations according toSpectras proposed plan. Finally, after the operationis done, the application is required to notify Spectra.4.2 ChromaFig. 4: Architecture of Chroma [29]Chroma [30] uses an approach based on usingnearby computing resources to execute part of theapplication. It improves upon Spectra by making itmuch more convenient for developers to adapt theirprograms to Chroma. Chroma makes use of a newconcept called Tactics that allows different ways ofpartitioning the application into components thatcan be executed locally and remotely.Different tactics have different fidelity and use updifferent amounts of resources. During the execu-tion of the application, Chroma uses brute-force tochoose the best or near best tactic. To choose amongtactics, Chroma uses a fixed utility function withequal weights for fidelity and latency but ignoresbattery lifetime. Therefore, a tactic is chosen thatmaximizes the rate of fidelity/latency.
  6. 6. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 6This process of determining the optimal tactic ischallenging since partitioning a process into compo-nents to be executed remotely s highly applicationspecific and platform specific. Moreover, resourceslike bandwidth and energy vary greatly with time.As a result, applications need to be re-partitioned toadapt to the changes. For this reason, partitioningthe application automatically for remote executionis necessary.Moreover, Chroma exploits over-provisioned en-vironments by sending a task execution requestin parallel to several surrogates and choosing thefastest response. The operation data is split andeach part is forwarded to a different surrogate. Thismethod of data decomposition and composition isspecified by the developer. Finally, the same taskexecution request with different fidelity is sent todifferent surrogates and the result with the high-est fidelity that satisfies the latency threshold isselected.VivendiThis concept of tactics was implemented using alittle language called Vivendi, which enables con-cise description of the tactics and fidelities of anapplication. Each application code component thatmay benefit from remote execution is identified inVivendi by the tag REMOTEOP. A remoteops sizeand complexity determine the granularity at whichcyber foraging occurs. The tactics file specifies theFig. 5: Sample Tactics File [30]critical variables that influence the amount of re-sources consumed by executing the remoteop. Thisindicates that quality is the variable correspondingto fidelity for the remoteop render. Parameters andfidelities are specified like C variables, with the key-word IN indicating parameters and OUT indicatingfidelities. The tag TACTIC identifies a tactic for theremoteop. Each tactic represents a different way ofcombining RPCs to produce a remoteop result.Chroma selects the appropriate tactic and thebinding of RPCs to compute servers. These choicesare frozen for the duration of a remoteop, but arere-evaluated for the next remoteop. Vivendi syntaxallows any combination of sequential and parallelRPCs to be specified as a tactic. It also providescontrol over placement of specific RPCs on servers.The RPCs used in tactics are specified using a syn-tax similar to that for standard function prototypedefinitions.4.3 MAUIMAUI enables fine grained energy offload of mobilecode to infrastructure in order to minimize energyconsumption. MAUI supports programs written incode environments such as Microsoft .Net CLR andJava. MAUI has a client server architecture. At themobile device side, MAUI consists of an interfaceto the decision unit residing in the MAUI serverside, a proxy to control a candidate method foroffloading, and a profiler for collecting informationabout the energy and data transfer requirements ofprograms. At the server side, there are four moduleswhose proxy and profiler modules are similar totheir counterparts in the mobile device [13]. Thesolver provides the call graph of the program andschedule methods, and the controller is responsiblefor checking the available requests and to allocatethem adequate resources.Fig. 6: Architecture of MAUI [13]MAUI uses code portability to create two ver-sions of the smartphone, one to run locally and
  7. 7. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 7the other to run remotely in the infrastructure.MAUI can even ignore the differences in instructionset architecture with the help of managed code. Ituses programming reflection along with type safetyto automatically identify the remote able methodsand extract only the state needed by them. MAUIprofiles all the methods of an application and thenuses serialization to determine the size of the stateto be shipped over the network and the computingCPU costs with measurements of bandwidth andlatency to construct a linear programming formu-lation of the code offload problem. The solutionto this dictates how to partition the application atrun time to save energy in the present conditions.However, it gives no consideration to the effect ofinput size on execution time of tasks.4.4 ScavengerScavenger [25] focuses on two things - augmentingCPU power of the devices and decreasing the re-sponse time of applications. It uses a dual adaptivehistory-based profiling approach to estimate theexecution time of application according to inputsize and the architecture of execution location. Con-sideration of the input size is a huge difference fromMAUI. The effect of input size on execution timeis estimated by keeping the records of executiontime of tasks for different input sizes in separatebuckets if their variations are higher than a certainpercentage.The Presence Library, shown in figure 7, performssurrogate discovery, while the Scavenger Libraryschedules tasks and controls remote executions. Atthe surrogate side, the Scavenger front-end com-municates with the mobile device through RPC en-try points. Scavenger first measures a performancescore for mobile device and the surrogates to geta rough estimate of the processing power of eachmachine. After execution, it uses online profiling toimprove upon the estimates. Every surrogate peri-odically sends its processing power and the numberof its running tasks to the mobile device. Based onthese inputs, Scavenger tries to estimate the CPUutilisation effect. However, it overlooks a numberof things in the process. Firstly, it considers that alltasks utilize resources equally and require the sametime for execution irrespective of the underlyingarchitecture, which is not always true. Secondly,it does not consider the effect of background pro-cesses on the operating system. Consequentially, thesystem reduces the scheduling time and decisionFig. 7: Overview of Scavenger [25]making time, at the cost of decreasing the precisionand accuracy of the decisions.5 VIRTUAL MACHINE BASED FORAGING SYS-TEMS5.1 Virtual MachinesIn order to effectively use heterogeneous re-sources, computation within an application mustbe portable. The computation must be migrated toother destinations as and when required by theuser. These portability and migration challengescan be addressed by abstracting the underlyinghardware as a virtual machine. Visualization is thetechnique/method of creating a virtual version ofsomething such as a virtual hardware platform,operating system (OS), storage device, or networkresources. It is like migrating the thread of compu-tation from one device to another. The virtual ma-chine abstracts the underlying machine hardwareinto a package which can then be migrated to otherdevices. Recent work highlights that virtualizationcan be applied at the level of a single application,at the level of a single physical machine, or at thelevel of an entire distributed system.5.2 Goyal and Carter SystemGoyal and Carter [24] were the first to use thevirtual machine technology. The system created by
  8. 8. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 8Fig. 8: Goyal and Carter’s system [24]them needs Internet and hence is not bound bythe locality. The aim of the system is to increaseapplication performance and decrease energy con-sumption. The system proposed by them has aservice discovery server that allows all surrogatesto register themselves. The process of registrationuses an XML descriptor file. A mobile device sendsa request to the service discovery server, whenit needs to use the system. The server assigns asurrogate to the mobile device. It sends a messagecontaining the IP address and port number of thesurrogate.The mobile device then analyses the resources itrequires. Accordingly, it requests a virtual serverwith specific resource guarantees. If the surrogatecan cater to the mobile devices demands, it starts avirtual server and sends its IP address to the mobiledevice. On recieving the IP address, the mobiledevice sends the URL of the program. It also sendsa shell script which downloads the real programover the Internet. The script is also responsiblefor installing and running the program. This entireprocess requires a lot of time. Hence, this system isnot suitable for real-time applications.5.3 SlingshotIn Slingshot [32], the mobile device and surrogatesare always connected to the internet. A reliablehome server is always accessible via the Internetand in the absence of surrogates in the LAN, heavytasks are offloaded to the home server. Since, thehome server is accessible via the internet the latencyis higher. In addition, the lower bandwidth in theInternet makes offloading to the home server sloweras compared to offloading to nearby surrogates.Therefore, Slingshot tries to send the task to thehome server and all available surrogates and thenfinally uses the fastest response.Fig. 9: Slingshot [32]6 CLOUD BASED SYSTEMS6.1 Cloud and Local Device CooperationGradually, foraging systems moved from usingthe internet for connecting to surrogates to cloudsmaintained by professional organisations. The aimwas on integrating relatively resource-poor mobiledevices with the resource-rich cloud. Some of theworks went to the extent of considering the desk-tops in their work, since they are also resourcepoor compared to the cloud. There are basicallytwo perspectives under this domain. The first is acloud-centric thread where the cloud is viewed asthe authoritative home of data and local devices arelittle more than access portals for that data. Thesecond is a local-device-centric thread where thelocal device is the home of the data and the cloud
  9. 9. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 9is an auxiliary processor to which the local deviceoccasionally reaches out for help with large tasks.6.2 Clone-cloud ExecutionAn exemplar of cloud based system has been givenin [11]. Chun et. al implement a system in whichexecution is offloaded from the smartphone to acloud having smartphone clones. The cloud con-tains loosely synchronised virtualised or emulatedreplicas of the mobile device. Tasks are executedin the cloned whole-system image of the device.On completion, the results are reintegrated at thesmartphone. This way the mobile device believes itis as powerful as its clone.Fig. 10: Types of Augmentations [11]Figure 10 shows the 5 different methods foraugmentation. Primary augmentation is similar todesigning the application as a client-server service,where the cloud takes care of the high-power com-putation. Background augmentation comes into thepicture when applications do not directly interactwith the user. The background processes takes placeat the clone and the results are returned to thedevice. Any application that switches from primaryto background falls in the category of mainlineaugmentation. Finally, augmentation multiplicitydiscusses the scenario where multiple clones aremaintained for a device and in case of multiplepossible paths that an application can take, thebest one can be determined by running all of themethods on the clones.Although the implementation of such a systemis not as trivial, but it does truly demonstrate howthe cloud can be used to make our mobile devicesextremely powerful.7 PERFORMANCE IMPROVEMENT TECH-NIQUES USED IN CLOUD BASED SYSTEMSIn this section, we discuss few of the principlesinvolved that have been applied to address thechallenges faced in cyber foraging in cloud basedsystems[33].7.1 LocalityThe locality of reference also known as the principleof locality is a phenomenon which states that at agiven time applications reference data only froma limited locality and users use applications froma physical limited locality. Using these patterns,network challenges and storage limitations can besolved. Cloud Computing basically involves twotypes of locality reference- temporal and spatial.The principle of temporal locality of reference saysthat an application tends to reuse a relatively smallamount of data (a locality)during any time frame. Incase of multiple applications working in the samelocality, Cooperative caching [32] is used. By us-ing several simple cooperative caching algorithms,server disk accesses and read response times canbe reduced by roughly 50% . The spatial aspectof locality says that performance improves whencomputation is near the data it references. Thisprinciple is applied by copying distant data into anearby cache, whether on a local disk, in physicalmemory, or in the processor’s fast cache memoryor registers. Systems that successfully pair mobileand cloud devices further exploit spatial locality ofreference in unique ways.7.2 Redundancy EliminationLow-bandwidth network links impose severe con-straints on communication, just as the limited ca-pacity of mobile devices imposes constraints onstorage. Recent work exploits redundancy in threeaspects- data content, access patterns, and evencomputation in order to address these challenges.Redundancy in data content can be exploited toreduce storage requirements and to improve com-munication by reducing utilization of slow networklinks. Data access patterns may also exhibit redun-dancy, and recent work [34] has taken advantage ofthese patterns. Cooperative caching, as discussedearlier under the principle of temporal localityof reference, improves performance when multipleclients show similarity in their access patterns. Onetechnique to avoid redundant computation is mem-oization. This technique is applied in the context of
  10. 10. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 10data-intensive computing using MapReduce in theIncoop [39] system.7.3 LazinessThe principle of laziness performs computationsand access data only on demand. This lazinessapplies to data access, to application partitioning,and even to resource provisioning. As computationmigrates from one resource to another, it becomesnecessary to access remote state as well. The costof this migration can be significantly reduced bydeferring it until specific data is accessed. In adistributed system comprising multiple resourcesfor computation, it is necessary to partition theapplication; to determine which portions of com-putation will be performed at which resource. Thispartitioning can be done lazily at runtime to im-prove the performance.8 CLOUDLET BASED CYBER FORAGING SYS-TEMS8.1 Internet Suspend/Resume ModelThe Internet Suspend/Resume Model [36] was alandmark in the field of pervasive computing. Ittook mobile computing to another level. The In-ternet Suspend/Resume (ISR) model is similar tothe suspend capability found in laptops. The mainaim of this model is to make computing hardwareavailable at any place, at any time on which anyuser could resume his PC state. The ISR model nomore binds the state of a PC with a particular PChardware. A user is able to suspend work at onemachine and to resume it at another.ISR ArchitectureISR uses virtual machine technology and dis-tributed storage technology- the virtual machine(VM) is used as a layer above the distributed systemtechnology. Every VM encloses a different executionand user customization state which is given thename of a parcel. It is now the responsibility ofthe underlying distributed storage to transport thisparcel from the suspend site to the resume site.Users can manage multiple parcels similar to theanalogy of owning multiple machines.Figure 11 shows the ISR model from a clients per-spective. The virtual machine monitor (VMM) savesthe VM state in a local disk partition from where theISR layer redirects this saved state to the distributedstorage. Before the parcel is handed over to theFig. 11: Modular structure of an Internet Sus-pend/Resume (ISR) client [36]distributed system, the ISR client software encryptsthe data. The distributed storage system mechanismdoes not contain unencrypted user state. On theweb, few remote servers are located which are ad-ministered by small professional staff who handletasks like backup, load balancing, adding new usersetc. Generally, the server and the respective staffare dedicated to a specific organisation such as auniversity, company or ISP. Figure 12 illustratesa rough idea as to how the ISR model can beimplemented over a wide area network (WAN).Fig. 12: A hypothetical deployment of ISR amongvarious organisations [36]
  11. 11. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 11The ISR model has evolved over the yearsstarting from ISR-1 which used Distributed Stor-age Technology- Network File System(NFSv3) andVMware Workstation 3.0 on Linux Host. In version1, the entire VM state would be copied betweenfile servers and the local disk. A parcel with 128-MB main memory and 2-GB virtual memory took 2minutes on a 100-MB ethernet to suspend/resume.It was observed that suspend latency is less per-ceived than resume latency. Users can suspend anddepart while the suspend operation can carry onbehind.Version 2 enabled the use of portable storage forVM state transfers. It shifted form NFSv3 to CodaFile System. The ISR layer was implemented in twoparts- Fauxide and Vulpes. Fauxide was a load-able kernel module which served as device driverfor pseudodevice, while Vulpes was the user levelprocess which handled VMware requests to thepseudodevice. Lookaside caching which integratedportable storage with distributed storage was alsointroduced. The data on the portable storage wasused as a hint to reduce resume latency. Beforeusing the data, an ISR client compares the crypto-graphic hash to that provided by the server. If thehash matches, the client can copy the state from theportable storage device instead of a fetching it fromthe server.Version 3 was quite flexible when it came tothe distributed System Technology. It supportedCoda/OpenAFS/Lustre/built-in storage layerbased on HTTP and now used VMware Workstation4.5. This version was developed for real worlddeployment. The point that emerged from thedeployment at CMU was that the VM state shouldbe stored on servers at much finer granularity(4 to 16 KB) compared to (128 to 256 KB) inISR-2 and ISR-3 because similarity across parcelimages outweighs the metadata overhead of finergranularity.Currently work is going on Open ISR which aimsat providing flexibility to use different VMMs. Itfeatures a thin client mode for short duration useand enables data sharing among users and betweenparcels8.2 The Concept of CloudletOffloading of tasks on cloud services like AmazonEC2 [34] became quite popular over the years, butit has an inherent problem. Using the cloud foroffloading is not always feasible due to high WANlatency. This problem aggravates further in caseswhere a result is needed in real time. For example,in case of GPS or gesture recognition where resultsare needed within less than a second. Hence, la-tency is a big issue when it comes to using the cloudas a surrogate. Satyanarayanan et. al came up withthe concept of Cloudlets to deal with this problem[4]. The idea behind a cloudlet was that one cannotmove the mobile close to the cloud, but the cloudcan be brought close to the mobile.Fig. 13: Cloudlets [4]Clouldlet is nothing but a one-hop machine thatis connected to the cloud. It provides a virtual ma-chine just like the cloud. But since, it is nearby, theissue of latency is removed. Mobile users can thenrapidly instantiate custom virtual machines(VMs)on the cloudlet running the required software ina thin client fashion. Influenced by their workon the Internet Suspend/Resume system, Satya-narayanan provided two methods in which com-putations could be offloaded. The first was of sus-pending the VM, and migrating the entire VM to thecloudlet. The second was dynamic VM Synthesis, inwhich the cloudlet would provide a base VM andthe state of the computation would be transferredas an an overlay VM. The overlay VM combiineswith the base VM and the application executioncontinues. After the task is completed, the VMresidue is sent to the mobile device and is discardedby the cloudlet.However, this design has two drawbacks aspointed out in [35]. Firstly, the service providershave to provide users with such infrastructure [4] inLAN. Secondly, coarse granularity of VM is anotherdrawback. Chun, Byung-Gon, [12] shows that onecan achieve better performance by dynamically par-
  12. 12. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 12titioning the application in components instead ofexecuting the whole application in VM. Verbelen,Tim, et. al [35] presents a cloudlet architecturewhich targets these drawbacks. They propose adynamic cloudlet concept in which all devices in theLAN network can help in formation of the cloudlet.Fig. 14: Ad-hoc Cloudlet [35]There are three layers for a cloudlet namely thecomponent level,the node level and the cloudletlevel. Execution Environment (EE) controls theworking of components. In case of distributed de-pendencies, proxies and stubs are generated andcomponents communicate using remote procedurecalls(RPCs). Based on resource usage of componentsEE can offload components or lower down theconfiguration of component.There are one or moreEEs running on top of an OS. Hardware togetherwith OS is called a node and Node Agent(NA)manages it. Like EE NA manages EE and can stopor start new EEs based on requirement.Cloudlet is formed by a collection of nodes whichare near to each other i.e. have low latency. Cloudletis managed by Cloudlet Agent(CA). A node withmost resources hosts the CA. It communicates withNode Agents and can also communicate with otherCAs eg. when offloading of a component is re-quired. When there is a performance violation incase of components, EE notifies NA which furthernotifies CA and CA decides further on where Com-ponent should be offloaded. This is done by CAdue to number of reasons for example, CA has theglobal overview and can best decide on optimumof components.Then it has most resources to exe-cute complex logic algorithms. As resources can belimited even in cloudlet, they suggest componentoffloading. This way one can prioritize allocationof resources of the cloudlet. Latency-critical parts ofapplication can be executed on cloudlet and otherparts on a distant cloud.Fig. 15: Proposed Architecture [35]9 SYSTEM USING INTERMITTENTLY CON-NECTED MOBILE DEVICESA new direction in foraging systems is to makeuse of opportunistic networks [37]. Serendipity is asystem that makes use of intermittent connectionsthat a mobile device has with other devices. Theother devices provide computational power, allow-ing mobile devices to perform tasks considered toointensive for them to carry out easily. The primaryobjective is to distribute any resource intensive taskto any devices that may be in close proximity andthus can be expected to take the task and giveresults quickly before getting out of range. Themain difference in this work is that the authorsacknowledge that processing power of mobile de-vices, however small, have still increased a lot overthe years and therefore, they make use of thatprocessing power instead of relying on dedicatedinfrastructure on the cloud.An overview of the proposed solution is givenfurther.Job modelEach job consists of a directed acyclic graph of PNPblocks each of which have three components-• a pre-process program• n parallel task programs• a post-progress programThe Pre-process part deals with processing andpassing on input data to the parallel task programs.When all inout has been processed, the n tasksare sent to their allocated nodes and finally, thepost-process program processes the results from all
  13. 13. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 13the task programs to create the final result. Eachnode is supposed to create a device profile foritself and share it with other ecountered nodes.This device profile is supposed to provide an ideaof the execution time of the node and it’s energyrequirements and available energy. Also each jobhas an execution profile that includes its DAG ofPNP blocks and input data required. The creationof execution profiles is out of scope of the paperand is assumed to exist while other components goabout their job.All the pre-process and post-process programsare executed on the initiator node itself while thetask programs are disseminated to other nodes forindependent execution. Three solutions for threedifferent scenarios have been proposed :-• Predictable Contact with control Channel- Inthis scenario, the duration and time of contactwith a any node can be accurately predictedand a control channel is present for sharingadministrative information. This contact neednot be direct but could be through a seriesof nodes. The device simply gets the deviceprofile of the other nodes and their shortestpath using the Dikstra routing algorithm andcalculates the estimated time of execution onthat node given the execution profile of the jobas well. It sends the task to the node that cancomplete the task in the quickest time withoutgoing out of range.• Predictable Contact without Control Chan-nel - Since we don’t have a control channel,task execution time cannot be reserved inadvance any more. The primary idea behindthe solution is that each intermediate node ex-ecutes the task and sends it opportunisticallyto any other encountered nodes until all tasksfinish.• Unpredictable Contacts - In the absence ofany information on contacts with other nodes,the authors propose an even more simplisticsolution. Each time a node encounters anothernode, they exchange tasks so as to minimizeeach others’ execution times.The experiments done by the authors demon-strate that as the workload increases, the solutionachieves greater decreases in job completion time.It is observed that for a set 10 tasks, local execu-tion completes them in 180 sec while Serendipityachieves a completion time of almost 100 seconds.For a bigger task set of 300 tasks, the time takento complete the processes locally stood at almost5000 sec while for the same set of tasks, Serendip-ity finished it in almost 1000 secs which is a bigimprovement. Thus, demonstrating that such ad-hoc mechanisms can also work well and dedicatedsurrogates may not always be needed.10 COMPARING THE FORAGING SYSTEMSCyber Foraging systems can be compared on thefollowing lines:-• Offloading Type - Offloading can be bothstatic and dynamic. Static offload is done priorto execution, while dynamic offload is per-formed at run-time.◦ Static offload - The programmer ora middleware partitions the program.However, due to the expanded diversityof surrogates and environments, staticoffloading cannot guarantee the best par-titioning for all possible situations.◦ Dynamic offload - The tasks are of-floaded when one of the required re-sources is insufficient and the partitionsare made according to the availability ofresources at runtime. However, this typeof offloading creates more overheads onthe system relating to latency, profilingand run-time decision making that canlead to unnecessary offloading too.• Offloading Granularity - Offloading can befine-grained and course-grained.◦ Fine-grain - Fine-grain offloading refersto offloading parts of the program. Thepartitioning of an application can bedone automatically by a cyber foragingsystem or it can be provided by theprogrammer. Such a strategy leads tolarge energy savings as only the partsthat benefit from remote executions areoffloaded.◦ Coarse-grain - Coarse-grain offloadingrefers to offloading the whole program.This strategy reduces the programmersresponsibilities because there is no needto modify programs for remote execu-tion and partition it. However, a mobiledevice may lead to regular offloadingto surrogates leading to waste of energyand time.• Parameters of Decision - Foraging system maydiffer on the factors that they consider whilemaking decisions. Energy, memory, storage,
  14. 14. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 14application responsiveness and I/O cycles areimportant parameters and may be consideredat the time of offloading.• Surrogate Type - The system may use staticsurrogates for offloading or it may use mobilesurrogates as well.• Offloading Scale - The system may select onesurrogate from the available surrogates to runa task or multiple surrogates may be used asthe offload locations of a task.• Remote Execution Aspect - The assumptionsmade by the system with respect to codeavailability and data availability may vary.◦ Code Availability - The system may as-sume that the task is pre-installed ona surrogate and is ready for service;which does not work for new surrogatesor the system may make use of virtualmachines; which though is an good ap-proach, but produces a great overhead.◦ Data Availability - The system may as-sume that data is already available on thesurrogate, or it needs to be transferredfrom the device to the surrogate or thenecessary information may be capturedfrom an old surrogate [9].• Live Migration - The systems capabilities ofbeing able to withstand disconnection be-tween the mobile client and the surrogate.• System Overhead - The overheads associatedwith monitoring resource availability, predict-ing resource demands, assessing costs andmaking decisions on task execution location,preparing the surrogates to perform a task forthe first time, and remote execution.Figure 16 presents a comparison of the traditionalforaging system. As for the systems using cloud andcloudlets, all of the systems support both static anddynamic offloads and support fine-grained offload-ing. Energy and performance are guiding factorsfor all these sysetems. Latency issue in cloud basedsystem was the reason for the inception of cloudlets.Hence, cloudlet based mechansims take latency asa factor as well. Both cloud and cloudlet basedsystems use stationary surrogates and the clients tosome extent act as thin clients while the cloud andcloudlet take care of the things most of the time.Virtual Machines are an integral part of the systemsand allow live migration. However, in case of cloudonly systems live migration is not the concern ofthe system and is handled at the end of the serviceprovider.11 SECURITY & PRIVACYIn pervasive computing environments, a surrogatewas initially assumed to be a device that is un-managed and untrusted. However, over time re-searchers started considering it to be managed byan untrusted third party and later on a few worksby Satyanarayanan considered them to be trusteddevices. Perhaps the idea of untrusted or unman-aged did not successfully work out. Nevertheless,there is no work that makes the reason behind thischange in perception clear.Irrespective of the perception of the surrogate,privacy and security are of utmost concern. Indata staging, privacy is ensured by encrypting filesfrom distributed file servers on the data pump.The surrogate only receives the encrypted files. Theencryption keys as well as the hash are forwardedto client proxy that is located in the mobile device.When the application on mobile device needs afile on surrogate, it fetches the encrypted file fromthe surrogate, decrypts the file using the key, andchecks the file for modifications.However, ensuring security and privacy on re-mote execution is much more complicated. In datastaging, the surrogate only acts as a cache to stagefiles for the client, it does not perform any typeof processing for the files. Hence, encryption andhashing are sufficient to maintain privacy. But, forremote execution, application code is executed onthe surrogate and only the results are returned backto the client. A malicious surrogate, may easily beable to modify the file or may return false returns.The lack of transparency makes it very difficult formobile devices to guarantee the correctness of thereturned result.Using the cloud is relatively safer, since theyare managed by professionals working for largeorganisations. Hence, to some extent the cloud hasemerged as a secure platform to offload programs.However, the traditional username, password secu-rity may not be sufficient in the near future and wemay need more advanced security mechanisms.12 CHALLENGES & CURRENT RESEARCHIn case of cloud based surrogates it is not an issue,but in general the availability of surrogates is stilla huge challenge. Data confidentiality and securityare still two aspects where more work needs to be
  15. 15. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 15Fig. 16: Comparison of the Traditional Foraging Systems [38]done before any such system can be widely de-ployed. Another issue is the nature of applicationsitself. Cyber foraging is of use only to applicationwhich have some considerably large task that iscapable of being transferred. It cannot help appli-cations where large tasks are not transferable. Incase of small transferable tasks the communicationoverhead would generally nullify all advantages.Hence, it is hard to answer how much benefit couldreal-world deployment of such systems provide.Lastly, developing programs for such systems is nottrivial. Hence, there is also a need of APIs which canenable programmers to adapt their applications forcyber foraging.The current research in this domain focuses onhaving a good estimation of execution cost on everylocation before real execution. There is a need toestimate the cost for local and remote executionsaccurately, while considering the effect of inputsize of the task and the current load of machines.Combining the effects of these with the application-history is expected to considerably improve theestimates.Another area of work is context gathering. Cur-rent researches gather context information and cy-ber foraging metrics periodically, instead of justbefore execution of task that contains the real andprecise context information. Periodic profiling re-moves the overhead of context gathering just beforeexecuting the task and increases the performance.However, it decreases the accuracy of decisionsthat are based on historical data and if there is nodemand to execute a task on the mobile device for along time, periodic context gathering is useless andburdens the system with unnecessary overhead.The upcoming works are attempting to solve theproblem with a combination of static and dynamiccontext gathering; where all context information isgathered at first time and only variable informationis updated before real execution.13 CONCLUSIONThe ubiquity of mobile devices has grabbed theimaginations of every user and has brought theworld a step closer to the Mark Weiser’s world ofpervasive computing. However, the resource con-straints poses a challenge to their extensive use. Inour report, we studied cyber foraging as a mecha-nism to augment the resource limitations of mobiledevices. Cyber foraging is offloading the whole pro-gram or a part of it from mobile devices to nearbystatic computers or to the cloud, depending on theapplication and other considerations. In addition,we also studied the use of clouds and cloudletsas surrogates and provided examples of systemswhich use the same.We study cyber foraging, give an overview of themechanism, highlight the important steps, discussthe factors that influence the decision of using thesurrogate and descibe the traditional cyber foragingsystems along with the underlying techniques. Wetry to show a comparison of the traditional systems.This is followed by the systems which leveragethe cloud and then we go on to cloudlets. Finally,we discuss certain challenges and solutions thathave been proposed for those challenges. Moreover,
  16. 16. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 16cyber foraging is a very good solution to augmentthe capabilities of the resource-constrained mobiledevices, but it has its limitations too. However, if wesee it in the light of Mark Weiser’s vision then it isa very positive sign and is a leap in the direction ofpervasive computing.ACKNOWLEDGMENTSWe would like express our special thanks to ourprofessor Dr. Hrishikesh Bhattacharya who gaveus the opportunity to work on a survey underhis guidance and monitoring. This survey wouldnot have been possible without his support andencouragement.REFERENCES[1] M. Weiser, “The Computer for the 21st Century,” ScientificAmer., Sept., 1991.[2] M. Satyanarayanan, “Pervasive Computing: Vision andChallenges,” IEEE Personal Communications, 8(4), Aug.2001.[3] M. Perry, K. Ohara, A. Sellen, B. Brown, and R. Harper,“Dealing with mobility: Understanding access anytime,anywhere,” ACM Trans. Computer-Human Interaction(TOCHI), vol. 8, no. 4, pp. 323347, 2001.[4] M. Satyanarayanan, P. Bahl, R. Cceres, and N. Davies, “Thecase for VM-based cloudlets in mobile computing,” IEEEPervasive Computing, vol. 8, no. 4, pp. 1423, 2009[5] M. Satyanarayanan, “Avoiding dead batteries,” IEEE Per-vasive Computing, vol. 4, no. 1, pp. 23, 2005.[6] R. K. Balan, “Powerful change part 2: Reducing the powerdemands of mobile devices,” IEEE Pervasive Computing,vol. 3, no. 2, pp. 7173, 2004.[7] B. D. Noble, M. Satyanarayanan, D. Narayanan, J. E.Tilton, J. Flinn, and K. R. Walker, “Agile application-awareadaptation for mobility,” in 16th ACM Symp. OperatingSystems Principles (SOSP), Saint-Malo, 1997, pp. 276287.[8] M. Satyanarayanan, “Pervasive computing: Vision andchallenges,” IEEE Personal Commun., vol. 8, no. 4, pp.1017, 2001.[9] T. E. Starner, “Powerful change part 1: Batteries and pos-sible alternatives for the mobile market,” IEEE PervasiveComputing, vol. 2, no. 4, pp. 8688, 2003.[10] R. K. Balan, J. Flinn, M. Satyanarayanan, S. Sinnamo-hideen, and H. Yang, “The case for cyber foraging,” in 10thWorkshop on ACM SIGOPS European Workshop: beyondthe PC, New York, NY, USA, 2002.[11] B. Chun and P. Maniatis, “Augmented smartphone appli-cations through clone cloud execution,” in 12th Workshopon Hot Topics in Operating Systems (HotOS), MonteVerita, Switzerland, 2009.[12] B. Chun and P. Maniatis, “Dynamically partitioning ap-plications between weak devices and clouds,” in 1st ACMWorkshop on Mobile Cloud Computing and Services(MCS 2010), San Francisco, 2010, pp. 15.[13] E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman,S. Saroiu, R. Chandra, and P. Bahl, “MAUI: Making smart-phones last longer with code offload,” in 8th internationalconference on Mobile systems, applications, and services(ACM MobiSys10), San Francisco, USA, 2010, pp. 4962.[14] K. Kumar and Y. Lu, “Cloud computing for mobileusers: Can offloading computation save energy?” IEEEComputer, vol. 43, no. 4, pp. 5156, 2010.[15] R. Buyya, S. Yeo, Chee, S. Venugopal, J. Broberg, and I.Brandic, “Cloud computing and emerging IT platforms:Vision, hype, and reality for delivering computing as the5th utility,” Future Generation Computer Systems, vol. 25,no. 6, pp. 599616, 2009.[16] R. Kemp, N. Palmer, T. Kielmann, and H. Bal, “Cuckoo:a computation offloading framework for smartphones,”in 3rd International Conference on Mobile Computing,Applications, and Services (MobiCASE), Santa Clara, CA,USA, 2010.[17] R. Kemp, et al., “The smartphone and the cloud: Powerto the user,” in International Workshop on Mobile Com-puting and Clouds (MobiCloud), Santa Clara, CA, USA,2010.[18] B. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti,“CloneCloud: elastic execution between mobile device andcloud,” in 6th conference on Computer Systems (EuroSys),Salzburg, Austria, 2011.[19] S. Kosta, A. Aucinas, P. Hui, R. Mortier, and X. Zhang,“Unleashing the power of mobile cloud computing usingThinkAir,” 2011.[20] R. Kemp, N. Palmer, T. Kielmann, F. Seinstra, N. Drost,J. Maassen, and H. Bal, “eyeDentify: Multimedia cyberforaging from a smartphone,” in IEEE International Sym-posium on Multimedia (ISM2009), San Diego, 2009, pp.392399.[21] A. P. Miettinen and J. K. Nurminen, “Energy efficiencyof mobile clients in cloud computing,” in 2nd USENIXWorkshop on Hot Topics in Cloud Computing (HotCloud),Boston, MA, USA, 2010.[22] M. Nkosi and F. Mekuria, “Cloud computing for en-hanced mobile health applications,” in IEEE 2nd Interna-tional Conference on Cloud Computing Technology andScience (CloudCom), Indianapolis, IN, USA, 2010.[23] X. Gu, A. Messer, I. Greenbergx, D. Milojicic, and K.Nahrstedt, “Adaptive offloading for pervasive comput-ing,” IEEE Pervasive Computing Mag., vol. 3, no. 3, pp.6673, 2004.[24] S. Goyal and J. Carter, “A lightweight secure cyberforaging infrastructure for resource-constrained devices,”in 6th IEEE Workshop on Mobile Computing Systemsand Applications (WMCSA 04), English Lake District, UK,2004, pp. 186195.[25] M. D. Kristensen, “Scavenger - mobile remote execution,”University of Aarhus, Technical Report DAIMI PB-587,2008.[26] C. N. Ververidis and G. C. Polyzos, “Service discoveryfor mobile ad hoc networks: A survey of issues andtechniques,” IEEE Commun. Surveys Tutorials, vol. 10, no.3, pp. 3045, 2008.[27] G. C. Hunt and M. L. Scott, “The coign automaticdistributed partitioning system,” in 3rd Symposium onOperating Systems Design and Implementation (OSDI99),New Orleans, 1999, pp. 187200.
  17. 17. A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 17[28] M. D. Kristensen and N. O. Bouvin, “Scheduling anddevelopment support in the scavenger cyber foragingsystem,” Pervasive and Mobile Computing, vol. 1, no. 6,pp. 677692, 2010.[29] Jason Flinn, Shafeeq Sinnamohideen, Niraj Tolia, and M.Satyanarayanan, “Data Staging on Untrusted Surrogates,”In the 2nd USENIX Conference on File and Storage Tech-nology, San Francison, CA, March/April 2003.[30] R. K. Balan, D. Gergle, M. Satyanarayanan, and J. Herb-sleb, “Simplifying cyber foraging for mobile devices,” in5th USENIX International Conference on Mobile Systems,Applications and Services (MobiSys), San Juan, PuertoRico, 2007, pp. 272285.[31] J. Flinn, S. Park, and M. Satyanarayanan, “Balancing per-formance, energy, and quality in pervasive computing,” in22nd International Conference on Distributed ComputingSystems (ICDCS02), Vienna, Austria, 2002, pp. 217226.[32] Y. Y. Su and J. Flinn, “Slingshot: Deploying stateful ser-vices in wireless hotspots,” in 3rd International Conferenceon Mobile Systems, Applications, and Services, New York,NY, USA, 2005, pp. 7992.[33] Heintz, Benjamin. “Cloud and Local Device Cooperation:Combining Two Research Threads.” (2012).[34] Giurgiu, Ioana, et al. “Calling the cloud: enabling mobilephones as interfaces to cloud applications.” Middleware2009. Springer Berlin Heidelberg, 2009. 83-102.[35] Verbelen, Tim, et al. “Cloudlets: Bringing the cloud to themobile user.” Proceedings of the third ACM workshop onMobile cloud computing and services. ACM, 2012.[36] Mahadev Satyanarayanan; Gilbert, B.; Toups, M.; Tolia,N.; O”Hallaron, D.R.; Ajay Surie; Wolbach, A.; Harkes, J.;Perrig, A.; Farber, D.J.; Kozuch, M.A.; Helfrich, C.J.; Nath,P.; Lagar-Cavilla, H.A., “Pervasive Personal Computing inan Internet Suspend/Resume System,” Internet Comput-ing, IEEE , vol.11, no.2, pp.16,25, March-April 2007[37] Shi, Cong, et al. ”Serendipity: Enabling remote comput-ing among intermittently connected mobile devices.” Pro-ceedings of the thirteenth ACM international symposiumon Mobile Ad Hoc Networking and Computing. ACM,2012.[38] Sharifi, Mohsen, Somayeh Kafaie, and Omid Kashefi.“A survey and taxonomy of cyber foraging of mobiledevices.” (2011): 1-12.[39] P. Bhatotia, A. Wieder, R. Rodrigues, U. A. Acar, andR. Pasquin. Incoop: MapReduce for incremental compu-tations. In Proceedings of the 2nd ACM Symposium onCloud Computing, SOCC ’11, pages 114, Cascais, Portugal,2011. ACM.

×