Survey of Foraging Techniques

A SURVEY OF CYBER FORAGING & CLOUD OFFLOAD TECHNIQUES 1
A Survey of Cyber Foraging & Cloud Offload
Techniques
Deepanker Aggarwal, Sahil Jain, Soumyavardhan Singh,
Vinayak Chopra, Yash Lamba
Abstract—In the present day scenario, the number of mobile devices i.e. (smartphones and tablets) are fast outnumbering
the traditional non-mobile devices. Today’s users expect to be able to run powerful, resource-intensive applications on
mobile 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 of
computing 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 proposed
to combat this problem. It involves taking help from the nearby non-mobile computers called surrogates. These surrogates
help the mobile device by running whole or parts of applications on behalf of the mobile device. Some application even
leverage machines available on the cloud for performing the computations. 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 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 that
disappear. They weave themselves into the fabric of
everyday life until they are indistinguishable from
it.” [1] This is how Mark Weiser, the chief architect
of pervasive computing envisaged the idea. At the
time of proposing the idea, it seemed a far-fetched
one. 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 which
are required to perform powerful computations,
but are small enough in size so as to fit into this
indistinguishable idea.
The modern day mobile devices fit into this idea
at least with respect to the size part. The current
market share of operating system is very positive
from 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 information
anywhere and anytime is getting closer to reality
[3]. However, mobile devices are resource poor [4].
Weight, size, battery life, and most importantly heat
dissipation impose severe restrictions on computa-
tional resources such as processor speed, memory
size and disk capacity [4]. The following will give
a nice idea of the nature of cyber foraging. Bob is
waiting for his flight at the airport. He suddenly
receives a voice message from a colleague in French.
Unfortunately, Bob is not fluent in French. Bob
wants to use a language translation application to
convert the email from French to English. However,
this is a resource consuming application, and his
mobile device wont be able to do it. Now, the
mobile detects a server nearby which can provide
computing resources to the phone. The phone sends
most of its computing tasks to the server; which
returns the result to the phone after the computa-
tion. Bob is able to understand the message and act
accordingly.
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 line
with the idea of pervasive computing. For long,
researchers have been focusing on applications that
can do just a bit extra. Researchers have been
coming up with wonderful applications ranging
from 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 requires
higher computing power, memory, and battery life-

time. Even if mobile devices are able to provide
sufficient computing power and memory, battery
and heat dissipation limit the deployment of such
applications. Although researchers have come up
with innovative solution to remove the problem of
battery 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 that
enables running the aforementioned applications.
The architecture for cyber foraging is made up of
a client and surrogates. The client is the resource
constrained device, while the surrogate is a server
or a desktop computer that possesses a high com-
puting capacity. The connection between the client
and surrogate is through the wireless connection.
In the following sections we discuss cyber forag-
ing in detail. Section 2 gives an overview of cyber
foraging. It discusses the feasibility of offloading,
the general steps that are common in all foraging
systems and the factors that affect the decision to
offload. Section 3 puts forward the use of surro-
gates as a performance enhancement technique for
foraging systems. Section 4 explains a few of the
traditional cyber foraging systems. Section 5 gives
an introduction to foraging systems that use virtual
machines. Section 6 discusses a few systems that
make use of the cloud, including a cloning based
solution. Section 7 mentions a few performance im-
provement techniques that have been incorporated
in the cloud based systems. Section 8 is dedicated
to the concept of cloudlets, while section 9 dis-
cusses an application that tries to take advantage of
opportunistic networks to offload computations. A
comparison of the aforementioned systems is given
in section 10. Finally, section 11 and 12 discuss the
major challenges and the current research in this
domain.
2 MECHANISM OVERVIEW
The term “cyber foraging” was first introduced by
Rajesh Balan and Satyanarayanan [10]. This mecha-
nism was introduced to augment the computational
and storage capabilities resources of a wireless mo-
bile device by utilising available static computers. It
was initially aimed at improving the performance of
interactive applications and distributed file systems
using 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 surrogates
for cyber foraging. There is no guarantee of avail-
ability of surrogates and application service level
in computational Clouds [20]. Cloud services are
generally paid [20] and require a device to always
be online [17]. 3G is still not upto the required
standards in terms of bandwidth, latency [18], [19],
[21]. Despite of all challenges, in some scenarios
such as when there is no surrogate in the vicinity of
mobile devices, the employment of cyber foraging
in clouds would be useful [4], [22].
2.1 Feasibility
Offloading is not reasonable in all situations. Of-
floading is required only when a mobile device
lacks the sufficient amount of memory or storage
to run a program. It may also be that a mobile has
the required amount of resources, but does not have
enough battery to allow the computation. However,
the decision to offload or not, is not made not
only on the basis of the mobile device, but also
the surrogates nearby. The availability of resources
on surrogates and the amount of resources required
for offloading are important factors that need to be
considered while offloading. Since, cyber foraging is
used to improve response time or energy consump-
tion, the offloading mechanism is more effective for
applications requiring more computation than com-
munication such as a game of chess or generation
of 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 make
sure that the cost of execution outweighs the cost
of communication. Next comes another practical
issue that is posed by mobility itself. It may be
possible that a task is quite large and before its
execution is completed the mobile-device has to
move out of the vicinity of the surrogate. In such
a scenario, offloading to a nearby machine is not
of too much use, since it requires the introduction
of checkpointing and various other time-consuming
solutions. In such, scenarios obviously using the
cloud is more ideal, but again brings the question
of communication costs into the picture. As a re-
sult, a suitable offloading approach must specially
consider the mobility nature of mobile devices and
manage a trade-off between mobility and task size.

Fig. 1: Flow of running a mobile application [38]
2.2 Steps
Broadly we can classify the process of cyber for-
aging into the steps mentioned below. (These steps
take into account the scenario when the surrogates
are not on the cloud) :-
• Surrogate Discovery - [23] - [26] deal with
surrogate discovery.
• Context Gathering - It involves monitoring the
resource levels of the nearby surrogates and
mobile devices in question. The context also
involves estimates of the resource consump-
tion of the application. [30], [31] talk about
context gathering.
• Partitioning - While partitioning, a task is
divided into smaller size subtasks. [12], [27]
focus on partitioning.
• Scheduling - Scheduling involves assigning
tasks to the surrogate, based on the context
information. [23], [28], [30], [31] deal with this
step.
• Remote Execution Control - This step involves
connecting to the surrogate and performing
remote 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 Offload
The decision to offload or not is based upon a
number of factors. The specifications of the client
and the surrogates, the specifications of the appli-
cations, the network and the context all determine
the feasibility of offloading. Specifications of the
clients and surrogates are important since there
is a lot of variability in processors, memory and
storage capacities of devices and so every time a
decision has to be made the total cost of using a
surrogate is measured in terms of processor cycles,
memory size, storage size, communication traffic
rate, input data size, and execution time of the
chosen surrogate. In case of the cloud, the financial
cost of surrogating comes into play as well.
The nature of the application plays a crucial role
as well. Offloading is of more use to processor
intensive applications as compared to memory or
storage intensive ones. However, just being proces-
sor intensive is not important. It may be the case
that some parts of an application are dependent on
the local device and as a result cannot be sent to a
surrogate even though it is computationally expen-
sive or the speed of the network and the bandwidth
are less for a particular application because of which

Fig. 2: Factors influencing offloading decision [38]
the decision to offload may need to be changed.
Finally, the resource availability on both the
clients and the surrogates plays an important role.
Since, a surrogate may be catering to the demands
of other clients as well, the levels of resource con-
sumption keeps on fluctuating. However, irrespec-
tive of the above factors the users have the ultimate
say, because it is their data that has to be offloaded
and they have a better idea of what they need from
an application. A user may want to save battery
whereas another may want accurate results even
if it is at the cost of battery. Hence, the decision
making process itself is quite complicated.
3 USING SURROGATES FOR DATA STAGING
The first main works on cyber foraging considered
surrogates to be untrusted and unmanaged ma-
chines which make use of widespread and reliable
software. A surrogate was supposed to be state-
less, and was independent of the file system. Data
staging constituted an important part of the cyber-
foraging system. Data staging is the prefetching and
caching of files by a surrogate in order to improve
the performance of the client [29]. The main idea
behind data staging is to remove bottleneck created
by the communication in the network. The main
idea is to cache the files that are mostly likely to be
accessed in the future. This prediction is done using
a prediction algorithm.
Data staging takes place as follows: - A proxy
residing on the client manages the communication
between the file client and the surrogate, file server
and the data pump. Data pump is a module that
hoards files for the client proxy and is always
present on a idle desktop belonging to the user.
The proxy on detecting the existence of a surrogate,
registers with the surrogate. When the client proxy
needs to stage a file, it sends a message to the data
pump. The data pump authenticates the message,
reads the file from the file server, encrypts the
file, generates a cryptographic hash, transmits the
encrypted file to the surrogate, and sends the file
key and hash to the client. If a file staged on the
surrogate is read by the application, the client proxy
fetches the file from the surrogate, decrypts the file,
and checks if the file has been modified. Prefetching
on a surrogate can reduce the latency for access-
ing files from the remote distributed system. Since
files are encrypted on data pump and decrypted
on client proxy, this framework provides security
features for the files during transmission.
Prefetching has its own challenges. In case the
prediction goes wrong, we may end up using more
resources. However, Flinn proved that on tradi-
tional desktop computers, prefetching often gives
decent results. Thus, data staging helps in over-
coming the problem between efficiency and limited
resources in mobile systems. The execution times
are down by 26%-54% depending on the size of the

cache on the mobile device, the network bandwidth
between the data pump and the surrogate, and
whether some files have already been cached on
the mobile devices cache. However, this idea of
untrusted and unmanaged surrogate, lost traction
with time and other works by the same authors only
involved trusted machines.
Fig. 3: Data Staging Architecture [29]
4 USING SURROGATES FOR REMOTE EXECU-
TION
4.1 Spectra
Spectra [31] is one of the earliest proposed cyber
foraging systems. The main focus of Spectra is to
reduce latency and energy consumption. Spectra
comes with a special feature called self-tuning.
As the name suggests the purpose of self-tuning
is to monitor the application behaviour and the
resource consumption. Based on real-time data, it
estimates the resources needed to execute an appli-
cation. Mathematically, Spectra makes use of linear
regression to model resource demands in terms of
application fidelity and input parameters for further
prediction of future resource demands. However,
Spectra does not separate the energy rate of an idle,
computing or communicating mobile device while
estimating energy consumption. It simply monitors
energy consumption of local execution and remote
execution. Consequently, the estimations of Spectra
become inaccurate when the input data of a task
changes. Moreover, Spectra monitors battery level
before and after execution. Therefore, Spectra does
not use the monitored data, when some tasks exe-
cute in parallel. Thus, the required time to reach a
good estimation about energy consumption of each
task increases.
Spectra is only usable for applications with pre-
installed corresponding services on surrogates. For
any such application the application developer is
required to follow the cyber foraging steps in Spec-
tra manually. This produces a significant addition in
the application code. A normal application and an
application built to use Spectra are vastly different.
An application is required to call Spectra before
execution to determine the execution location of
each operation. Following which the application is
responsible for executing operations according to
Spectras proposed plan. Finally, after the operation
is done, the application is required to notify Spectra.
4.2 Chroma
Fig. 4: Architecture of Chroma [29]
Chroma [30] uses an approach based on using
nearby computing resources to execute part of the
application. It improves upon Spectra by making it
much more convenient for developers to adapt their
programs to Chroma. Chroma makes use of a new
concept called Tactics that allows different ways of
partitioning the application into components that
can be executed locally and remotely.
Different tactics have different fidelity and use up
different amounts of resources. During the execu-
tion of the application, Chroma uses brute-force to
choose the best or near best tactic. To choose among
tactics, Chroma uses a fixed utility function with
equal weights for fidelity and latency but ignores
battery lifetime. Therefore, a tactic is chosen that
maximizes the rate of fidelity/latency.

This process of determining the optimal tactic is
challenging since partitioning a process into compo-
nents to be executed remotely s highly application
specific and platform specific. Moreover, resources
like bandwidth and energy vary greatly with time.
As a result, applications need to be re-partitioned to
adapt to the changes. For this reason, partitioning
the application automatically for remote execution
is necessary.
Moreover, Chroma exploits over-provisioned en-
vironments by sending a task execution request
in parallel to several surrogates and choosing the
fastest response. The operation data is split and
each part is forwarded to a different surrogate. This
method of data decomposition and composition is
specified by the developer. Finally, the same task
execution request with different fidelity is sent to
different surrogates and the result with the high-
est fidelity that satisfies the latency threshold is
selected.
Vivendi
This concept of tactics was implemented using a
little language called Vivendi, which enables con-
cise description of the tactics and fidelities of an
application. Each application code component that
may benefit from remote execution is identified in
Vivendi by the tag REMOTEOP. A remoteops size
and complexity determine the granularity at which
cyber foraging occurs. The tactics file specifies the
Fig. 5: Sample Tactics File [30]
critical variables that influence the amount of re-
sources consumed by executing the remoteop. This
indicates that quality is the variable corresponding
to fidelity for the remoteop render. Parameters and
fidelities are specified like C variables, with the key-
word IN indicating parameters and OUT indicating
fidelities. The tag TACTIC identifies a tactic for the
remoteop. Each tactic represents a different way of
combining RPCs to produce a remoteop result.
Chroma selects the appropriate tactic and the
binding of RPCs to compute servers. These choices
are frozen for the duration of a remoteop, but are
re-evaluated for the next remoteop. Vivendi syntax
allows any combination of sequential and parallel
RPCs to be specified as a tactic. It also provides
control over placement of specific RPCs on servers.
The RPCs used in tactics are specified using a syn-
tax similar to that for standard function prototype
definitions.
4.3 MAUI
MAUI enables fine grained energy offload of mobile
code to infrastructure in order to minimize energy
consumption. MAUI supports programs written in
code environments such as Microsoft .Net CLR and
Java. MAUI has a client server architecture. At the
mobile device side, MAUI consists of an interface
to the decision unit residing in the MAUI server
side, a proxy to control a candidate method for
offloading, and a profiler for collecting information
about the energy and data transfer requirements of
programs. At the server side, there are four modules
whose proxy and profiler modules are similar to
their counterparts in the mobile device [13]. The
solver provides the call graph of the program and
schedule methods, and the controller is responsible
for checking the available requests and to allocate
them 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

the other to run remotely in the infrastructure.
MAUI can even ignore the differences in instruction
set architecture with the help of managed code. It
uses programming reflection along with type safety
to automatically identify the remote able methods
and extract only the state needed by them. MAUI
profiles all the methods of an application and then
uses serialization to determine the size of the state
to be shipped over the network and the computing
CPU costs with measurements of bandwidth and
latency to construct a linear programming formu-
lation of the code offload problem. The solution
to this dictates how to partition the application at
run time to save energy in the present conditions.
However, it gives no consideration to the effect of
input size on execution time of tasks.
4.4 Scavenger
Scavenger [25] focuses on two things - augmenting
CPU power of the devices and decreasing the re-
sponse time of applications. It uses a dual adaptive
history-based profiling approach to estimate the
execution time of application according to input
size and the architecture of execution location. Con-
sideration of the input size is a huge difference from
MAUI. The effect of input size on execution time
is estimated by keeping the records of execution
time of tasks for different input sizes in separate
buckets if their variations are higher than a certain
percentage.
The Presence Library, shown in figure 7, performs
surrogate discovery, while the Scavenger Library
schedules tasks and controls remote executions. At
the surrogate side, the Scavenger front-end com-
municates with the mobile device through RPC en-
try points. Scavenger first measures a performance
score for mobile device and the surrogates to get
a rough estimate of the processing power of each
machine. After execution, it uses online profiling to
improve upon the estimates. Every surrogate peri-
odically sends its processing power and the number
of its running tasks to the mobile device. Based on
these inputs, Scavenger tries to estimate the CPU
utilisation effect. However, it overlooks a number
of things in the process. Firstly, it considers that all
tasks utilize resources equally and require the same
time for execution irrespective of the underlying
architecture, which is not always true. Secondly,
it does not consider the effect of background pro-
cesses on the operating system. Consequentially, the
system reduces the scheduling time and decision
Fig. 7: Overview of Scavenger [25]
making time, at the cost of decreasing the precision
and accuracy of the decisions.
5 VIRTUAL MACHINE BASED FORAGING SYS-
TEMS
5.1 Virtual Machines
In order to effectively use heterogeneous re-
sources, computation within an application must
be portable. The computation must be migrated to
other destinations as and when required by the
user. These portability and migration challenges
can be addressed by abstracting the underlying
hardware as a virtual machine. Visualization is the
technique/method of creating a virtual version of
something such as a virtual hardware platform,
operating system (OS), storage device, or network
resources. It is like migrating the thread of compu-
tation from one device to another. The virtual ma-
chine abstracts the underlying machine hardware
into a package which can then be migrated to other
devices. Recent work highlights that virtualization
can be applied at the level of a single application,
at the level of a single physical machine, or at the
level of an entire distributed system.
5.2 Goyal and Carter System
Goyal and Carter [24] were the first to use the
virtual machine technology. The system created by

Fig. 8: Goyal and Carter’s system [24]
them needs Internet and hence is not bound by
the locality. The aim of the system is to increase
application performance and decrease energy con-
sumption. The system proposed by them has a
service discovery server that allows all surrogates
to register themselves. The process of registration
uses an XML descriptor file. A mobile device sends
a request to the service discovery server, when
it needs to use the system. The server assigns a
surrogate to the mobile device. It sends a message
containing the IP address and port number of the
surrogate.
The mobile device then analyses the resources it
requires. Accordingly, it requests a virtual server
with specific resource guarantees. If the surrogate
can cater to the mobile devices demands, it starts a
virtual server and sends its IP address to the mobile
device. On recieving the IP address, the mobile
device sends the URL of the program. It also sends
a shell script which downloads the real program
over the Internet. The script is also responsible
for installing and running the program. This entire
process requires a lot of time. Hence, this system is
not suitable for real-time applications.
5.3 Slingshot
In Slingshot [32], the mobile device and surrogates
are always connected to the internet. A reliable
home server is always accessible via the Internet
and in the absence of surrogates in the LAN, heavy
tasks are offloaded to the home server. Since, the
home server is accessible via the internet the latency
is higher. In addition, the lower bandwidth in the
Internet makes offloading to the home server slower
as compared to offloading to nearby surrogates.
Therefore, Slingshot tries to send the task to the
home server and all available surrogates and then
finally uses the fastest response.
Fig. 9: Slingshot [32]
6 CLOUD BASED SYSTEMS
6.1 Cloud and Local Device Cooperation
Gradually, foraging systems moved from using
the internet for connecting to surrogates to clouds
maintained by professional organisations. The aim
was on integrating relatively resource-poor mobile
devices with the resource-rich cloud. Some of the
works went to the extent of considering the desk-
tops in their work, since they are also resource
poor compared to the cloud. There are basically
two perspectives under this domain. The first is a
cloud-centric thread where the cloud is viewed as
the authoritative home of data and local devices are
little more than access portals for that data. The
second is a local-device-centric thread where the
local device is the home of the data and the cloud

is an auxiliary processor to which the local device
occasionally reaches out for help with large tasks.
6.2 Clone-cloud Execution
An exemplar of cloud based system has been given
in [11]. Chun et. al implement a system in which
execution is ofﬂoaded from the smartphone to a
cloud having smartphone clones. The cloud con-
tains loosely synchronised virtualised or emulated
replicas of the mobile device. Tasks are executed
in the cloned whole-system image of the device.
On completion, the results are reintegrated at the
smartphone. This way the mobile device believes it
is as powerful as its clone.
Fig. 10: Types of Augmentations [11]
Figure 10 shows the 5 different methods for
augmentation. Primary augmentation is similar to
designing the application as a client-server service,
where the cloud takes care of the high-power com-
putation. Background augmentation comes into the
picture when applications do not directly interact
with the user. The background processes takes place
at the clone and the results are returned to the
device. Any application that switches from primary
to background falls in the category of mainline
augmentation. Finally, augmentation multiplicity
discusses the scenario where multiple clones are
maintained for a device and in case of multiple
possible paths that an application can take, the
best one can be determined by running all of the
methods on the clones.
Although the implementation of such a system
is not as trivial, but it does truly demonstrate how
the cloud can be used to make our mobile devices
extremely powerful.
7 PERFORMANCE IMPROVEMENT TECH-
NIQUES USED IN CLOUD BASED SYSTEMS
In this section, we discuss few of the principles
involved that have been applied to address the
challenges faced in cyber foraging in cloud based
systems[33].
7.1 Locality
The locality of reference also known as the principle
of locality is a phenomenon which states that at a
given time applications reference data only from
a limited locality and users use applications from
a physical limited locality. Using these patterns,
network challenges and storage limitations can be
solved. Cloud Computing basically involves two
types of locality reference- temporal and spatial.
The principle of temporal locality of reference says
that an application tends to reuse a relatively small
amount of data (a locality)during any time frame. In
case of multiple applications working in the same
locality, Cooperative caching [32] is used. By us-
ing several simple cooperative caching algorithms,
server disk accesses and read response times can
be reduced by roughly 50% . The spatial aspect
of locality says that performance improves when
computation is near the data it references. This
principle is applied by copying distant data into a
nearby cache, whether on a local disk, in physical
memory, or in the processor’s fast cache memory
or registers. Systems that successfully pair mobile
and cloud devices further exploit spatial locality of
reference in unique ways.
7.2 Redundancy Elimination
Low-bandwidth network links impose severe con-
straints on communication, just as the limited ca-
pacity of mobile devices imposes constraints on
storage. Recent work exploits redundancy in three
aspects- data content, access patterns, and even
computation in order to address these challenges.
Redundancy in data content can be exploited to
reduce storage requirements and to improve com-
munication by reducing utilization of slow network
links. Data access patterns may also exhibit redun-
dancy, and recent work [34] has taken advantage of
these patterns. Cooperative caching, as discussed
earlier under the principle of temporal locality
of reference, improves performance when multiple
clients show similarity in their access patterns. One
technique to avoid redundant computation is mem-
oization. This technique is applied in the context of

data-intensive computing using MapReduce in the
Incoop [39] system.
7.3 Laziness
The principle of laziness performs computations
and access data only on demand. This laziness
applies to data access, to application partitioning,
and even to resource provisioning. As computation
migrates from one resource to another, it becomes
necessary to access remote state as well. The cost
of this migration can be significantly reduced by
deferring it until specific data is accessed. In a
distributed system comprising multiple resources
for computation, it is necessary to partition the
application; to determine which portions of com-
putation will be performed at which resource. This
partitioning can be done lazily at runtime to im-
prove the performance.
8 CLOUDLET BASED CYBER FORAGING SYS-
TEMS
8.1 Internet Suspend/Resume Model
The Internet Suspend/Resume Model [36] was a
landmark in the field of pervasive computing. It
took mobile computing to another level. The In-
ternet Suspend/Resume (ISR) model is similar to
the suspend capability found in laptops. The main
aim of this model is to make computing hardware
available at any place, at any time on which any
user could resume his PC state. The ISR model no
more binds the state of a PC with a particular PC
hardware. A user is able to suspend work at one
machine and to resume it at another.
ISR Architecture
ISR uses virtual machine technology and dis-
tributed storage technology- the virtual machine
(VM) is used as a layer above the distributed system
technology. Every VM encloses a different execution
and user customization state which is given the
name of a parcel. It is now the responsibility of
the underlying distributed storage to transport this
parcel from the suspend site to the resume site.
Users can manage multiple parcels similar to the
analogy of owning multiple machines.
Figure 11 shows the ISR model from a clients per-
spective. The virtual machine monitor (VMM) saves
the VM state in a local disk partition from where the
ISR layer redirects this saved state to the distributed
storage. Before the parcel is handed over to the
Fig. 11: Modular structure of an Internet Sus-
pend/Resume (ISR) client [36]
distributed system, the ISR client software encrypts
the data. The distributed storage system mechanism
does not contain unencrypted user state. On the
web, few remote servers are located which are ad-
ministered by small professional staff who handle
tasks like backup, load balancing, adding new users
etc. Generally, the server and the respective staff
are dedicated to a specific organisation such as a
university, company or ISP. Figure 12 illustrates
a rough idea as to how the ISR model can be
implemented over a wide area network (WAN).
Fig. 12: A hypothetical deployment of ISR among
various organisations [36]

The ISR model has evolved over the years
starting from ISR-1 which used Distributed Stor-
age Technology- Network File System(NFSv3) and
VMware Workstation 3.0 on Linux Host. In version
1, the entire VM state would be copied between
file servers and the local disk. A parcel with 128-
MB main memory and 2-GB virtual memory took 2
minutes on a 100-MB ethernet to suspend/resume.
It was observed that suspend latency is less per-
ceived than resume latency. Users can suspend and
depart while the suspend operation can carry on
behind.
Version 2 enabled the use of portable storage for
VM state transfers. It shifted form NFSv3 to Coda
File System. The ISR layer was implemented in two
parts- Fauxide and Vulpes. Fauxide was a load-
able kernel module which served as device driver
for pseudodevice, while Vulpes was the user level
process which handled VMware requests to the
pseudodevice. Lookaside caching which integrated
portable storage with distributed storage was also
introduced. The data on the portable storage was
used as a hint to reduce resume latency. Before
using the data, an ISR client compares the crypto-
graphic hash to that provided by the server. If the
hash matches, the client can copy the state from the
portable storage device instead of a fetching it from
the server.
Version 3 was quite flexible when it came to
the distributed System Technology. It supported
Coda/OpenAFS/Lustre/built-in storage layer
based on HTTP and now used VMware Workstation
4.5. This version was developed for real world
deployment. The point that emerged from the
deployment at CMU was that the VM state should
be stored on servers at much finer granularity
(4 to 16 KB) compared to (128 to 256 KB) in
ISR-2 and ISR-3 because similarity across parcel
images outweighs the metadata overhead of finer
granularity.
Currently work is going on Open ISR which aims
at providing flexibility to use different VMMs. It
features a thin client mode for short duration use
and enables data sharing among users and between
parcels
8.2 The Concept of Cloudlet
Offloading of tasks on cloud services like Amazon
EC2 [34] became quite popular over the years, but
it has an inherent problem. Using the cloud for
offloading is not always feasible due to high WAN
latency. This problem aggravates further in cases
where a result is needed in real time. For example,
in case of GPS or gesture recognition where results
are needed within less than a second. Hence, la-
tency is a big issue when it comes to using the cloud
as a surrogate. Satyanarayanan et. al came up with
the concept of Cloudlets to deal with this problem
[4]. The idea behind a cloudlet was that one cannot
move the mobile close to the cloud, but the cloud
can be brought close to the mobile.
Fig. 13: Cloudlets [4]
Clouldlet is nothing but a one-hop machine that
is connected to the cloud. It provides a virtual ma-
chine just like the cloud. But since, it is nearby, the
issue of latency is removed. Mobile users can then
rapidly instantiate custom virtual machines(VMs)
on the cloudlet running the required software in
a thin client fashion. Influenced by their work
on 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 the
cloudlet. The second was dynamic VM Synthesis, in
which the cloudlet would provide a base VM and
the state of the computation would be transferred
as an an overlay VM. The overlay VM combiines
with the base VM and the application execution
continues. After the task is completed, the VM
residue is sent to the mobile device and is discarded
by the cloudlet.
However, this design has two drawbacks as
pointed out in [35]. Firstly, the service providers
have to provide users with such infrastructure [4] in
LAN. Secondly, coarse granularity of VM is another
drawback. Chun, Byung-Gon, [12] shows that one
can achieve better performance by dynamically par-

titioning the application in components instead of
executing the whole application in VM. Verbelen,
Tim, et. al [35] presents a cloudlet architecture
which targets these drawbacks. They propose a
dynamic cloudlet concept in which all devices in the
LAN network can help in formation of the cloudlet.
Fig. 14: Ad-hoc Cloudlet [35]
There are three layers for a cloudlet namely the
component level,the node level and the cloudlet
level. Execution Environment (EE) controls the
working of components. In case of distributed de-
pendencies, proxies and stubs are generated and
components communicate using remote procedure
calls(RPCs). Based on resource usage of components
EE can offload components or lower down the
configuration of component.There are one or more
EEs running on top of an OS. Hardware together
with OS is called a node and Node Agent(NA)
manages it. Like EE NA manages EE and can stop
or start new EEs based on requirement.
Cloudlet is formed by a collection of nodes which
are near to each other i.e. have low latency. Cloudlet
is managed by Cloudlet Agent(CA). A node with
most resources hosts the CA. It communicates with
Node Agents and can also communicate with other
CAs eg. when offloading of a component is re-
quired. When there is a performance violation in
case of components, EE notifies NA which further
notifies CA and CA decides further on where Com-
ponent should be offloaded. This is done by CA
due to number of reasons for example, CA has the
global overview and can best decide on optimum
of components.Then it has most resources to exe-
cute complex logic algorithms. As resources can be
limited even in cloudlet, they suggest component
offloading. This way one can prioritize allocation
of resources of the cloudlet. Latency-critical parts of
application can be executed on cloudlet and other
parts on a distant cloud.
Fig. 15: Proposed Architecture [35]
9 SYSTEM USING INTERMITTENTLY CON-
NECTED MOBILE DEVICES
A new direction in foraging systems is to make
use of opportunistic networks [37]. Serendipity is a
system that makes use of intermittent connections
that a mobile device has with other devices. The
other devices provide computational power, allow-
ing mobile devices to perform tasks considered too
intensive for them to carry out easily. The primary
objective is to distribute any resource intensive task
to any devices that may be in close proximity and
thus can be expected to take the task and give
results quickly before getting out of range. The
main difference in this work is that the authors
acknowledge that processing power of mobile de-
vices, however small, have still increased a lot over
the years and therefore, they make use of that
processing power instead of relying on dedicated
infrastructure on the cloud.
An overview of the proposed solution is given
further.
Job model
Each job consists of a directed acyclic graph of PNP
blocks each of which have three components-
• a pre-process program
• n parallel task programs
• a post-progress program
The Pre-process part deals with processing and
passing on input data to the parallel task programs.
When all inout has been processed, the n tasks
are sent to their allocated nodes and finally, the
post-process program processes the results from all

the task programs to create the final result. Each
node is supposed to create a device profile for
itself and share it with other ecountered nodes.
This device profile is supposed to provide an idea
of the execution time of the node and it’s energy
requirements and available energy. Also each job
has an execution profile that includes its DAG of
PNP blocks and input data required. The creation
of execution profiles is out of scope of the paper
and is assumed to exist while other components go
about their job.
All the pre-process and post-process programs
are executed on the initiator node itself while the
task programs are disseminated to other nodes for
independent execution. Three solutions for three
different scenarios have been proposed :-
• Predictable Contact with control Channel- In
this scenario, the duration and time of contact
with a any node can be accurately predicted
and a control channel is present for sharing
administrative information. This contact need
not be direct but could be through a series
of nodes. The device simply gets the device
profile of the other nodes and their shortest
path using the Dikstra routing algorithm and
calculates the estimated time of execution on
that node given the execution profile of the job
as well. It sends the task to the node that can
complete the task in the quickest time without
going out of range.
• Predictable Contact without Control Chan-
nel - Since we don’t have a control channel,
task execution time cannot be reserved in
advance any more. The primary idea behind
the solution is that each intermediate node ex-
ecutes the task and sends it opportunistically
to any other encountered nodes until all tasks
finish.
• Unpredictable Contacts - In the absence of
any information on contacts with other nodes,
the authors propose an even more simplistic
solution. Each time a node encounters another
node, they exchange tasks so as to minimize
each others’ execution times.
The experiments done by the authors demon-
strate that as the workload increases, the solution
achieves greater decreases in job completion time.
It is observed that for a set 10 tasks, local execu-
tion completes them in 180 sec while Serendipity
achieves a completion time of almost 100 seconds.
For a bigger task set of 300 tasks, the time taken
to complete the processes locally stood at almost
5000 sec while for the same set of tasks, Serendip-
ity finished it in almost 1000 secs which is a big
improvement. Thus, demonstrating that such ad-
hoc mechanisms can also work well and dedicated
surrogates may not always be needed.
10 COMPARING THE FORAGING SYSTEMS
Cyber Foraging systems can be compared on the
following lines:-
• Offloading Type - Offloading can be both
static and dynamic. Static offload is done prior
to execution, while dynamic offload is per-
formed at run-time.
◦ Static offload - The programmer or
a middleware partitions the program.
However, due to the expanded diversity
of surrogates and environments, static
offloading 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 partitions
are made according to the availability of
resources at runtime. However, this type
of offloading creates more overheads on
the system relating to latency, profiling
and run-time decision making that can
lead to unnecessary offloading too.
• Offloading Granularity - Offloading can be
fine-grained and course-grained.
◦ Fine-grain - Fine-grain offloading refers
to offloading parts of the program. The
partitioning of an application can be
done automatically by a cyber foraging
system or it can be provided by the
programmer. Such a strategy leads to
large energy savings as only the parts
that benefit from remote executions are
offloaded.
◦ Coarse-grain - Coarse-grain offloading
refers to offloading the whole program.
This strategy reduces the programmers
responsibilities because there is no need
to modify programs for remote execu-
tion and partition it. However, a mobile
device may lead to regular offloading
to surrogates leading to waste of energy
and time.
• Parameters of Decision - Foraging system may
differ on the factors that they consider while
making decisions. Energy, memory, storage,

application responsiveness and I/O cycles are
important parameters and may be considered
at the time of offloading.
• Surrogate Type - The system may use static
surrogates for offloading or it may use mobile
surrogates as well.
• Offloading Scale - The system may select one
surrogate from the available surrogates to run
a task or multiple surrogates may be used as
the offload locations of a task.
• Remote Execution Aspect - The assumptions
made by the system with respect to code
availability and data availability may vary.
◦ Code Availability - The system may as-
sume that the task is pre-installed on
a surrogate and is ready for service;
which does not work for new surrogates
or the system may make use of virtual
machines; 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 the
surrogate, or it needs to be transferred
from the device to the surrogate or the
necessary information may be captured
from an old surrogate [9].
• Live Migration - The systems capabilities of
being able to withstand disconnection be-
tween the mobile client and the surrogate.
• System Overhead - The overheads associated
with monitoring resource availability, predict-
ing resource demands, assessing costs and
making decisions on task execution location,
preparing the surrogates to perform a task for
the first time, and remote execution.
Figure 16 presents a comparison of the traditional
foraging system. As for the systems using cloud and
cloudlets, all of the systems support both static and
dynamic offloads and support fine-grained offload-
ing. Energy and performance are guiding factors
for all these sysetems. Latency issue in cloud based
system was the reason for the inception of cloudlets.
Hence, cloudlet based mechansims take latency as
a factor as well. Both cloud and cloudlet based
systems use stationary surrogates and the clients to
some extent act as thin clients while the cloud and
cloudlet take care of the things most of the time.
Virtual Machines are an integral part of the systems
and allow live migration. However, in case of cloud
only systems live migration is not the concern of
the system and is handled at the end of the service
provider.
11 SECURITY & PRIVACY
In pervasive computing environments, a surrogate
was initially assumed to be a device that is un-
managed and untrusted. However, over time re-
searchers started considering it to be managed by
an untrusted third party and later on a few works
by Satyanarayanan considered them to be trusted
devices. Perhaps the idea of untrusted or unman-
aged did not successfully work out. Nevertheless,
there is no work that makes the reason behind this
change in perception clear.
Irrespective of the perception of the surrogate,
privacy and security are of utmost concern. In
data staging, privacy is ensured by encrypting files
from distributed file servers on the data pump.
The surrogate only receives the encrypted files. The
encryption keys as well as the hash are forwarded
to client proxy that is located in the mobile device.
When the application on mobile device needs a
file on surrogate, it fetches the encrypted file from
the surrogate, decrypts the file using the key, and
checks the file for modifications.
However, ensuring security and privacy on re-
mote execution is much more complicated. In data
staging, the surrogate only acts as a cache to stage
files for the client, it does not perform any type
of processing for the files. Hence, encryption and
hashing are sufficient to maintain privacy. But, for
remote execution, application code is executed on
the surrogate and only the results are returned back
to the client. A malicious surrogate, may easily be
able to modify the file or may return false returns.
The lack of transparency makes it very difficult for
mobile devices to guarantee the correctness of the
returned result.
Using the cloud is relatively safer, since they
are managed by professionals working for large
organisations. Hence, to some extent the cloud has
emerged as a secure platform to offload programs.
However, the traditional username, password secu-
rity may not be sufficient in the near future and we
may need more advanced security mechanisms.
12 CHALLENGES & CURRENT RESEARCH
In case of cloud based surrogates it is not an issue,
but in general the availability of surrogates is still
a huge challenge. Data confidentiality and security
are still two aspects where more work needs to be

Fig. 16: Comparison of the Traditional Foraging Systems [38]
done before any such system can be widely de-
ployed. Another issue is the nature of applications
itself. Cyber foraging is of use only to application
which have some considerably large task that is
capable of being transferred. It cannot help appli-
cations where large tasks are not transferable. In
case of small transferable tasks the communication
overhead would generally nullify all advantages.
Hence, it is hard to answer how much benefit could
real-world deployment of such systems provide.
Lastly, developing programs for such systems is not
trivial. Hence, there is also a need of APIs which can
enable programmers to adapt their applications for
cyber foraging.
The current research in this domain focuses on
having a good estimation of execution cost on every
location before real execution. There is a need to
estimate the cost for local and remote executions
accurately, while considering the effect of input
size of the task and the current load of machines.
Combining the effects of these with the application-
history is expected to considerably improve the
estimates.
Another area of work is context gathering. Cur-
rent researches gather context information and cy-
ber foraging metrics periodically, instead of just
before execution of task that contains the real and
precise context information. Periodic profiling re-
moves the overhead of context gathering just before
executing the task and increases the performance.
However, it decreases the accuracy of decisions
that are based on historical data and if there is no
demand to execute a task on the mobile device for a
long time, periodic context gathering is useless and
burdens the system with unnecessary overhead.
The upcoming works are attempting to solve the
problem with a combination of static and dynamic
context gathering; where all context information is
gathered at first time and only variable information
is updated before real execution.
13 CONCLUSION
The ubiquity of mobile devices has grabbed the
imaginations of every user and has brought the
world a step closer to the Mark Weiser’s world of
pervasive computing. However, the resource con-
straints poses a challenge to their extensive use. In
our report, we studied cyber foraging as a mecha-
nism to augment the resource limitations of mobile
devices. Cyber foraging is offloading the whole pro-
gram or a part of it from mobile devices to nearby
static computers or to the cloud, depending on the
application and other considerations. In addition,
we also studied the use of clouds and cloudlets
as surrogates and provided examples of systems
which use the same.
We study cyber foraging, give an overview of the
mechanism, highlight the important steps, discuss
the factors that influence the decision of using the
surrogate and descibe the traditional cyber foraging
systems along with the underlying techniques. We
try to show a comparison of the traditional systems.
This is followed by the systems which leverage
the cloud and then we go on to cloudlets. Finally,
we discuss certain challenges and solutions that
have been proposed for those challenges. Moreover,

cyber foraging is a very good solution to augment
the capabilities of the resource-constrained mobile
devices, but it has its limitations too. However, if we
see it in the light of Mark Weiser’s vision then it is
a very positive sign and is a leap in the direction of
pervasive computing.
ACKNOWLEDGMENTS
We would like express our special thanks to our
professor Dr. Hrishikesh Bhattacharya who gave
us the opportunity to work on a survey under
his guidance and monitoring. This survey would
not have been possible without his support and
encouragement.
REFERENCES
[1] M. Weiser, “The Computer for the 21st Century,” Scientific
Amer., Sept., 1991.
[2] M. Satyanarayanan, “Pervasive Computing: Vision and
Challenges,” 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, “The
case for VM-based cloudlets in mobile computing,” IEEE
Pervasive 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 power
demands 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-aware
adaptation for mobility,” in 16th ACM Symp. Operating
Systems Principles (SOSP), Saint-Malo, 1997, pp. 276287.
[8] M. Satyanarayanan, “Pervasive computing: Vision and
challenges,” 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 Pervasive
Computing, 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 10th
Workshop on ACM SIGOPS European Workshop: beyond
the PC, New York, NY, USA, 2002.
[11] B. Chun and P. Maniatis, “Augmented smartphone appli-
cations through clone cloud execution,” in 12th Workshop
on Hot Topics in Operating Systems (HotOS), Monte
Verita, Switzerland, 2009.
[12] B. Chun and P. Maniatis, “Dynamically partitioning ap-
plications between weak devices and clouds,” in 1st ACM
Workshop 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 international
conference on Mobile systems, applications, and services
(ACM MobiSys10), San Francisco, USA, 2010, pp. 4962.
[14] K. Kumar and Y. Lu, “Cloud computing for mobile
users: Can offloading computation save energy?” IEEE
Computer, 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 the
5th 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: Power
to 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 and
cloud,” 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 using
ThinkAir,” 2011.
[20] R. Kemp, N. Palmer, T. Kielmann, F. Seinstra, N. Drost,
J. Maassen, and H. Bal, “eyeDentify: Multimedia cyber
foraging 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 efficiency
of mobile clients in cloud computing,” in 2nd USENIX
Workshop 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 and
Science (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 cyber
foraging infrastructure for resource-constrained devices,”
in 6th IEEE Workshop on Mobile Computing Systems
and 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 discovery
for mobile ad hoc networks: A survey of issues and
techniques,” IEEE Commun. Surveys Tutorials, vol. 10, no.
3, pp. 3045, 2008.
[27] G. C. Hunt and M. L. Scott, “The coign automatic
distributed partitioning system,” in 3rd Symposium on
Operating Systems Design and Implementation (OSDI99),
New Orleans, 1999, pp. 187200.

[28] M. D. Kristensen and N. O. Bouvin, “Scheduling and
development support in the scavenger cyber foraging
system,” 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,” in
5th USENIX International Conference on Mobile Systems,
Applications and Services (MobiSys), San Juan, Puerto
Rico, 2007, pp. 272285.
[31] J. Flinn, S. Park, and M. Satyanarayanan, “Balancing per-
formance, energy, and quality in pervasive computing,” in
22nd International Conference on Distributed Computing
Systems (ICDCS02), Vienna, Austria, 2002, pp. 217226.
[32] Y. Y. Su and J. Flinn, “Slingshot: Deploying stateful ser-
vices in wireless hotspots,” in 3rd International Conference
on 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 mobile
phones as interfaces to cloud applications.” Middleware
2009. Springer Berlin Heidelberg, 2009. 83-102.
[35] Verbelen, Tim, et al. “Cloudlets: Bringing the cloud to the
mobile user.” Proceedings of the third ACM workshop on
Mobile 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 in
an 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 symposium
on Mobile Ad Hoc Networking and Computing. ACM,
2012.
[38] Shariﬁ, Mohsen, Somayeh Kafaie, and Omid Kasheﬁ.
“A survey and taxonomy of cyber foraging of mobile
devices.” (2011): 1-12.
[39] P. Bhatotia, A. Wieder, R. Rodrigues, U. A. Acar, and
R. Pasquin. Incoop: MapReduce for incremental compu-
tations. In Proceedings of the 2nd ACM Symposium on
Cloud Computing, SOCC ’11, pages 114, Cascais, Portugal,
2011. ACM.

Survey of Foraging Techniques

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

En vedette

En vedette (20)

Similaire à Survey of Foraging Techniques

Similaire à Survey of Foraging Techniques (20)

Plus de Sahil Jain

Plus de Sahil Jain (8)

Dernier

Dernier (20)

Survey of Foraging Techniques