Content uploaded by Hongyue Wu
Author content
All content in this area was uploaded by Hongyue Wu on Oct 18, 2019
Content may be subject to copyright.
Revenue-Driven Service Provisioning
for Resource Sharing in Mobile Cloud
Computing
Hongyue Wu
1,2
, Shuiguang Deng
1(&)
, Wei Li
2
, Jianwei Yin
1(&)
,
Qiang Yang
3
, Zhaohui Wu
1
, and Albert Y. Zomaya
2
1
College of Computer Science and Technology, Zhejiang University,
Hangzhou, China
{hongyue_wu,dengsg,zjuyjw,wzh}@zju.edu.cn
2
School of Information Technologies, The University of Sydney,
Sydney, Australia
liwei@it.usyd.edu.au, albert.zomaya@sydney.edu.au
3
College of Electrical Engineering, Zhejiang University, Hangzhou, China
qyang@zju.edu.cn
Abstract. A new mobile cloud architecture has recently been proposed, where
neighbouring mobile devices are brought together as a cohort for resource
sharing. Thus, a mobile application can be partitioned into multiple tasks and be
performed on different mobile devices, without offloading some tasks to remote
cloud services for their processing. In this work, we consider a broker-based
architecture, where a proper reward mechanism is used to incentivize users to
share their available resources as a service with other mobile devices. Within
such a system, each mobile device is rational and justified in maximizing its
revenue by using its relatively limited resources to complete the requests allo-
cated by the broker. How to select the appropriate service requests from all
incoming requests and complete the selected requests on time so that the rev-
enue can be maximized has become a critical issue for resource sharing. To
address this issue, we propose a joint resource sharing and request scheduling
approach called RESP (REvenue-driven Service Provision for mobile devices)
in a move towards a lightweight one-phase approach for handling request
selection, request scheduling and resource allocation for mobile devices. We
evaluate the performance of our proposed algorithm through a number of
experiments and the experimental results validate the efficacy of our approach.
Keywords: Mobile cloud computing Scheduling Service provisioning
Resource sharing
1 Introduction
Mobile devices have been one of the fastest adopted consumer products of all time and
highly integrated into our daily life. The manufacturers of mobile devices have also
made breakthrough contributions to improve hardware capabilities in terms of com-
putation, communication and storage. The requirements for running applications with
©Springer International Publishing AG 2017
M. Maximilien et al. (Eds.): ICSOC 2017, LNCS 10601, pp. 625–640, 2017.
https://doi.org/10.1007/978-3-319-69035-3_46
high computation requirements, e.g. multimedia processing, social networking and
natural language processing on mobile devices become more intense. However, in
general, mobile devices are still resource constrained compared to dedicated computers.
To enable such applications to run effectively on mobile devices, a natural solution is
mobile cloud computing (MCC) [10], so that the mobile devices can offload compu-
tationally intensive tasks to the resource-rich cloud service providers, such as Ama-
zon’s EC2
1
, Microsoft Azure
2
and Rackspace Cloud
3
and complete the applications
collaboratively. In most cases, these cloud services are geographically remote from the
mobile devices, and a reliable Internet connection is required to transmit the data
between the two ends.
By fully utilizing the increasing amount of mobile devices and their ubiquitous
presence, a new architecture for MCC has recently been proposed [9], where the
neighbouring mobile devices are brought together as a cohort for resource sharing.
Using the idle resources of a collection of mobile devices in the vicinity, an application
can thus be partitioned into multiple tasks and be performed on different devices
collaboratively. With such an approach, the unstable and costly Internet connection of
mobile devices is no longer a constraint as it is in the traditional MCC architectures.
Also the data exchange among the mobile devices in the local area can benefit from
different wireless communication technologies, e.g. WiFi and Bluetooth. To better
distinguish the MCC architectures, we refer to the new one that enables device-residing
resource sharing as NMCC for the rest of the paper.
One of the key techniques to realize resource sharing in the NMCC is service
provisioning, so that the available resources of each mobile device can be provided as
on-demand services anytime, anywhere. In contrast to the powerful remote cloud
servers, when accommodating excessive service requests, mobile devices may not be
able to satisfy all the requests since they have limited computing capabilities and
resources. In addition, the remote cloud service providers are equipped with
resource-rich devices to allow them to use sophisticated solutions, e.g. machine
learning methods for processing incoming requests. As these solutions are normally
associated with high computational overhead, they cannot be simply applied to mobile
devices. To ensure the quality of service (QoS) on the resource-constrained mobile
devices, a lightweight QoS-aware service-based framework needs to be provided to
(1) determine whether to accept or reject an incoming service request and (2) perform
resource allocation for the selected service requests according to the available resources
of a mobile device and the requirements of the tasks to be met. For example, if the
remaining energy of a mobile device is high and its available network bandwidth is
low, it would be preferable to accept computation intensive service requests rather than
communication intensive service requests.
Apart from enabling a lightweight QoS-aware service-based framework in NMCC,
it is not hard to see that the service provisioning in such systems strongly depends on
the willingness to participate of the owners of mobile devices. To further ensure the
1
http://aws.amazon.com.
2
http://azure.microsoft.com/en-us/.
3
http://www.rackspace.com.
626 H. Wu et al.
quality of services, such NMCC systems need to employ a proper incentive mechanism
to motivate the resource sharing of mobile devices [21]. Mobile service requesters can
always encourage resource sharing by providing some rewards (e.g. discount, credit
points, etc.), so that the mobile device owners can decide the degree of their partici-
pation to gain the corresponding revenue. We also assume that all the mobile devices
have the same objective to maximize the revenue of their providing services.
In this paper, we study the issue of how to incentivize user participation for
addressing the resource sharing in NMCC systems. To tackle the issue, we model it as a
service provisioning and resource allocation problem of mobile devices, which is
generally a constrained optimization problem. Using the task scheduling technique, we
designed a lightweight approach called RESP (REvenue-driven Service Provision for
mobile devices) for handling all the incoming requests with the objective of maxi-
mizing the revenue of the mobile devices. The approach can achieve efficient service
request selection, request scheduling and resource allocation simultaneously. The
performed experiments demonstrate that our proposed algorithm outperforms the
selected benchmarks and provides the best overall performance for the users.
The rest of the paper is organized as follows. In Sect. 2, we review related works.
In Sect. 3, we introduce the models used in this paper and formally define the problem.
Then the details of our proposed algorithm are presented and discussed in Sect. 4.In
Sect. 5, we show the conducted experiments and analyse the results. Finally, we
conclude the paper and outline our future work in Sect. 6.
2 Related Work
The problem of service provision in MCC has been studied extensively, and various
approaches have been proposed from different perspectives. Most of them focus on
using remote resource-rich cloud services to enhance the capabilities of mobile devices.
Liu et al. proposed a novel approach to predict the total workload for facilitating auto
scaling resource management [14]. Lee et al. proposed a heuristic algorithm-based
auction system to determine when and how the providers should allocate their
resources and to which users [13]. Albagli-Kim et al. presented a comparative study of
approximation algorithms and heuristics for scheduling jobs with dwindling resource
requirements [1]. Maguluri et al. focused on scheduling jobs with unknown duration in
clouds, and presented a load balancing and scheduling algorithm [17]. However, these
works assume that the services are provided by the remote large-scale cloud servers and
stable Internet connections are available, which may not be always true for some
mobile users. These approaches cannot be simply applied to the MCC platforms that
are formed by a cohort of mobile devices and the required services are provided from
these mobile devices.
In recent years, with the rapid development of mobile devices and wireless com-
munication techniques, some works have proposed forming a mobile cloud that avoids a
connection being made to a remote cloud by using nearby mobile devices while
maintaining the main benefits of resource sharing [7,8]. Fernando et al. analysed the
need for a mobile cloud and highlighted the direction of future work [10]. In [19], the
authors discussed the feasibility of mobile service provision on smartphones and
Revenue-Driven Service Provisioning for Resource Sharing 627
presented a performance analysis of mobile devices. Liyanage et al. proposed a light-
weight mobile Web service provisioning framework, designed for resource-constrained
Internet of Things applications to achieve lightweight mobile Web service provisioning
[16]. Moreover, Arslan et al. aimed to develop a distributed computing infrastructure
using smartphones, and they implemented a prototype, which employs a novel
scheduling algorithm to minimize the makespan of computation tasks [3].
The aforementioned framework for a mobile cloud is promising, and a proper
incentive mechanism is the key to motivate users to share their resources within such a
system. The incentive mechanisms can generally be divided into two categories, double-
sided bidding and single-sided bidding. The Vickrey-Clarke-Groves (VCG) mechanism
is a well-known double-sided bidding, however, it induces intensive computational cost
[4] in real-world implementations and thus they are difficult to adopt widely in the
NMCC systems. For addressing such issues, few researchers have designed several
single-side bidding incentive mechanisms for NMCC. In [18], the authors introduced the
prototype of mClouds and analysed some incentive strategies that may help mClouds
become a viable and effective alternative to the traditional MCC model. In [2], the
authors developed the mobile device based cloud system CellCloud and proposed a
reputation-based economic incentive model to reward phone owners for sharing the
resources of their devices. Besides, an optimal incentive mechanism was developed in
[12] to minimize the total payment to all the smartphones.
3 System Models and Problem Formulation
3.1 Mobile Cloud Architecture
Our proposed framework is designed for NMCC systems, which are composed of
multiple mobile devices and a trusted broker, as shown in Fig. 1. The broker serves as
an intermediary responsible for discovery and communication among the neighbouring
mobile devices. The mobile devices are within the coverage of the broker and each one
of them could act as two roles within the system simultaneously. One role is service
requester who needs to offload tasks to other nearby mobile devices. The other role is
service provider who has idle resources and is willing to participate in resource sharing.
All mobile devices directly send their service requests and/or service provisioning
information to the broker. After receiving such information, the broker performs the
matching between service requesters and providers by jointly considering the
requirements of the requests and the functionality and QoS of services. Once a service
request is received by a mobile device, the device can choose to accept or decline it
according to its current status in terms of resource utilization. If a mobile device accepts
a service request, it will obtain the corresponding revenue by successfully completing
the request. The result of the task will be sent back to the service requester through the
broker. If a service request is declined, it will be returned to the broker for reallocation.
Eventually, the service requester combines all the received results to obtain the final
result.
628 H. Wu et al.
3.2 Mobile Services and Requests
Definition 1 (Mobile Device). In NMCC systems, a mobile device is represented as a
3-tuple (S, A, I), where:
–S¼s1;s2;...
fg
, describing the set of services that a mobile device is able to
provide;
–A is the function used to describe all the available resources a mobile device can
share with other devices. At a given time t, the available resources are denoted as a
set of 2-tuples At¼ri;ni
ðÞ
fg
m
i¼1, where m is the total number of the types of the
available resources that a mobile device can provide, and riand nidenote the type
and the amount of the i-th kind of resource, respectively.
–I is a function used to describe the current idle resources of a mobile device. Idle
resources refer to the resources that are available and not yet occupied by the
service requests. At a given time t, it can be represented by It¼ri;ni
ðÞ
fg
m
i¼1.
In our study, we assume that time is slotted and the minimum time slot is a time
unit. Similar to a number of existing works in MCC [5,6,15,20] and mobile com-
puting [11], we consider a quasi-static scenario where the mobile devices remain
unchanged for a period of time, which may change over consecutive periods in our
work. Since most mobile devices are personal devices, the resource sharing should not
disturb the predominant usage of the device owners. This hard requirement also means
the available resources of mobile devices are varied over time. For example, if the
owner of a mobile device wants to download some files, the available bandwidth used
to share should be reduced. The amount of idle resources of a mobile device is an
important factor for our proposed framework to perform service request selection and
scheduling, which will be elaborated later. It can be calculated by
It;rðÞ¼At;rðÞ
Xq2Et
RrqðÞ ð1Þ
where It;rðÞdenotes the amount of resource rthat is idle at time t,At;rðÞdenotes the
amount of resource rthat is available at time t,q2Etdenotes the request executing on
Fig. 1. Mobile cloud architecture
Revenue-Driven Service Provisioning for Resource Sharing 629
the mobile device at time t,andRrqðÞdenotes the amount of resource rthat is occupied
by the request q.
As mentioned before, mobile devices share their resources with others in the form
of services. Mobile services can be the computing capabilities, resources, applications,
data, sensors, etc. of mobile devices.
Definition 2 (Mobile Service). A mobile service is represented as a 5-tuple (d, R, v, F,
QoS), where:
–d is the index of the mobile device in the NMCC systems;
–R describes the resources needed for the mobile device to execute the service, which
can be denoted as a set of 2-tuples R ¼ri;ni
ðÞ
fg
m
i¼1, where m is the number of types
of required resources, and riand nidenote the type and number of the i-th kind of
resource, respectively;
–v is the revenue the mobile device can obtain by successfully completing the service;
–F is the functional description of the service;
–QoS is a set of attributes of the requested services, including execution time te,
which is the makespan needed for a mobile device to execute the service.
Functional description and QoS parameters are key criteria for the broker to select
services for requests in the matching process. In this paper, we mainly consider the
execution time of a requested service, since it plays an important role in the scheduling
and resource allocation of mobile devices.
Definition 3 (Service Request). A service request is represented as a 4-tuple
s;d;ta
;td
, where:
–s is the service that is requested;
–d is the index of the mobile device, to which the request is delivered;
–tais the arrival time of the request;
–tdis the deadline for the request to be completed.
As introduced in Definition 3, a service request consists of information on a
required service, service host and time. In the dynamic and versatile mobile environ-
ment, service requests are highly likely to express real-time requirements, so we
introduce tdto guarantee that services are completed in time. It is obvious that one
request corresponds to one service. In the remaining parts of the paper, we will use the
terms request and service interchangeably.
3.3 Problem Statement
Each mobile device manages an execution sequence, by which it conducts service
execution, requests insertion, deletion, scheduling, and resource allocation.
Definition 4 (Execution Sequence). For a mobile device d, its execution sequence
describes the services that will be performed on each time unit. It can be formulated as
a time function Et¼qi
fg
n
i¼1, expressing that during time unit t, a mobile device d will
process n service requests including q1,q2,…,q
n, simultaneously.
630 H. Wu et al.
In an execution sequence, each time unit corresponds to a set of service requests
that will be processed during that time unit. For example, Fig. 2shows an example of
an execution sequence, which describes the service execution of a mobile device within
the time period of 5 time units.
To describe the execution time of a service request, we let qdenote the time when
request qstarts to be processed and qdenotes the time when qis completed. Corre-
sponding to a given execution sequence, there is a request sequence where the requests
involved are sorted by the time when they begin to be executed. We let Eq
and
Eq
ðÞdenote the request that is right ahead of and right behind qrespectively.
Specifically, Eldenotes the last request of the execution sequence. For example,
according to Fig. 2, we have Eq
1
¼q2,Eq3
¼q2and El¼q3.
Definition 5 (Revenue-Driven Service Provision). Given a mobile device d, with its
available resources At¼ri;ni
ðÞ
fg
m
i¼1and idle resources It¼rj;nj
m
j¼1, and the
incoming service requests q1,q2,…qn, the revenue-driven service provision is to select
a set of service requests S from the request sequence and schedule them in the exe-
cution sequence E to
Maximize X
q2S
vq;
s:t:qq¼te
q;for each q 2Sð2Þ
qtd
q;for each q 2Sð3Þ
8t;Xq2Et\SRqrðÞAtrðÞ;for each r2Atð4Þ
It is reasonable to regard maximizing overall revenue of a mobile device as the
optimization objective for its service provisioning. Equation 2implies that the
arrangement of each request is in accordance with its execution time. Equation 3
illustrates that each request should be completed before its deadline. Moreover, the
allocated resources should not exceed the available resources of the mobile device at
any time, as specified in Eq. 4. Therefore, revenue-driven service provision is to select
service requests to maximize the revenue of mobile devices, with given dynamic
resource constraints and diverse time constraints of requests.
q1q1q3q3q3
q2q2
t
01 2345
Fig. 2. Execution sequence example
Revenue-Driven Service Provisioning for Resource Sharing 631
4 RESP Approach
In this section, we present the RESP algorithm. It is a one-phase algorithm, which
means that the service request selection, scheduling and resource allocation of a mobile
device are made in an integrated manner. The symbols used in this paper are sum-
marized in Table 1.
4.1 RESP Algorithm
Service requests are sent to mobile devices via the broker, so that mobile devices are
required to deal with these requests sequentially. For each incoming request, a mobile
device needs to make a decision on the following three criteria:
(1) The request can be completed before its deadline;
(2) The request can be allocated with sufficient resources;
(3) The total revenue is increased.
A service request can be accepted by a mobile device for its execution if and only if
the above three criteria are all met. We first provide the definition of latest start time,
which is a core element of our approach.
Definition 6 (Latest Start Time). For a given request q, its latest start time is the
latest time for a mobile device to start performing it, so that it can be completed before
its deadline. The latest start time can be calculated by
Table 1. Mathematical Notations
Symbol Description Symbol Description
ta
qThe arrival time of request qEq
The request ahead of request qin E
te
qThe execution time of request
q
Eq
ðÞ The request behind request qin E
td
qThe deadline of request qEt
ðÞ The request behind the time point
tin E
ts
qThe latest start time of
request q
ElThe last request in the execution
sequence E
tcThe current time AtThe available resource set at time t
vqThe reward for completing
request q
AtrðÞ The amount of the available resource
rat time t
•qThe time slot request qstarts
to process
ItrðÞ The amount of the idle resource rat
time t
q•The time slot request qis
completed
RqThe total required resources of
request q
EtThe requests in Ewith the
same time t
RqrðÞ The amount of a required resource
rof request q
632 H. Wu et al.
ts
q¼td
qte
qð5Þ
where td
qis the deadline of the request q, and te
qis the execution time of the
request q.
Figure 3shows the flowchart of the RESP algorithm. For a given request qi,wefirst
calculate its latest start time and use it to evaluate whether the request can be completed
before its deadline on the device. If the latest start time of the service request is before
the current time tc, the request will not be able to complete in time and it is thus rejected.
Otherwise, we schedule it with the accepted but not yet started requests located in the
execution sequence E. All the requests are sorted in non-decreasing order according to
their deadlines. A reference start time Twill be generated for the request q
i
. Next, by
considering the available resource of a mobile device, we look for the actual start time
of qi. The actual start time can be before, equal to or after the reference start time T.
The pseudo code of the RESP algorithm is shown in Algorithm 1. For an incoming
service request qi,wefirst calculate its latest start time (line 1) and check whether it can be
completed before its deadline (lines 2-3) compared with the current time t
c
. If the request
is schedulable, we determine its reference start time in the execution sequence according
to its deadline (lines 5-7). To do so, we put qito the rear of the execution sequence
(line 5). If there exists a scheduled request in the execution sequence and its deadline is
behind qi, then the reference start time of qishould be moved forward (lines 6-7).
Once the reference start time Tis determined, we will use the start time mini-
mization technique to check whether qican be performed before T(lines 9-12). If there
is a time interval where the mobile device has more idle resources than those required
(line 10), then qican be safely placed into that time interval (line 11) without affecting
the execution of the scheduled requests. If no such time interval exists and the latest
start time of qiis not before T(line 13), then we check whether qican be started at T.
If the mobile device has enough available resources for qiduring its execution period
Start
Calculate the latest start
time of request qi
The latest start time of qiis
later than current time
Decline request qi
Find the reference start
time of qi
Y
Y
Insert qito that
time interval
There is a time interval
before , during w hich idle resources
are sufficient for qi
N
NDuring the time interval
starting at , ava ilable resources are
sufficient for qi
N
There is a time interval
before the deadline of qi, during
which available resources are
sufficient for qi
Invoke timeouts
processing for qi
End
Y
Y
N
Fig. 3. Flowchart of the RESP algorithm
Revenue-Driven Service Provisioning for Resource Sharing 633
(line 14), then qishould be started from T(line 15). If the idle resources during that
interval are not enough for qi,qican occupy the resources that have been allocated to
other requests with later deadlines (line 15). When this step still does not provide
enough resources to perform qi, the algorithm will continue checking whether there is
any time interval between Tand the latest start time of qithat has sufficient resources
(lines 17-21). If one exists, qishould be inserted to that interval (line 19).
After the above search process, if qicannot be inserted into the execution sequence,
then the Timeouts algorithm will be invoked (lines 22-23), implying that the mobile
device cannot accept all requests. This will lead to either qior some other scheduled
requests being declined. For the cases that qiis inserted to the execution sequence and
thus causes one or more scheduled requests cannot being started on schedule, the
timeouts algorithm needs to be used for these requests.
4.2 Timeouts Processing Algorithm
In this subsection, we present the timeouts processing algorithm, which is invoked
when timeouts occurs. To better describe the algorithm, we first introduce the definition
of dominance.
634 H. Wu et al.
Definition 7 (Dominance). Given a service request qi, an execution sequence E and a
set of scheduled service requests S in E, qidominates S if and only if
9ts:t:8t02t;tþte
qi
and 8r2Rqi;
RqirðÞ\It0rðÞþXq2S\Et0
RqrðÞand vqi[Xq2Svqð6Þ
In Definition 7, constraint (6) illustrates that there is a time interval, during which
the sum of the idle resources and the resources allocated to the requests in Sexceeds the
required resources of qi. Meanwhile, the revenue for executing qiis more than exe-
cuting all requests in S. Obviously, if qidominates S, the requests in Scan be safely
replaced by qi, with the revenue for the mobile device increased.
The timeouts process algorithm is shown in Algorithm 2. It is realized by searching
for the dominated request set with the minimum price. For each time slot before the
reference start time point of an incoming request qi, the algorithm tries to find a dom-
inated request set with less revenue (lines 2-20). The search is started from the current
time to the earlier one of the reference time point and the latest start time (line 2).
For each time point, the request starting at it is set as the first request to check (lines 1).
If a request is found to be dominated by qiand with less revenue than the previous
minimum revenue, which is represented by Min the algorithm (line 4), then it will be
assigned to the replaced request set, its revenue will be assigned to the minimum revenue,
and the time point will be marked (line 5). Otherwise, the algorithm will check whether
the following request set can be dominated by qiand with less revenue (lines 8-13).
Revenue-Driven Service Provisioning for Resource Sharing 635
If it is, the algorithm will reallocate the minimum revenue, request set and time (line 10).
Otherwise, the algorithm will continue expanding the set until we can determine that it is
not qualified (line 13).
After the searching process, if the algorithm finds a dominated request with less
revenue (line 14), it will replace these requests with qiand move the subsequent
requests accordingly (line 15), otherwise, it means that no request set dominated by qi
is found and qishould be rejected (line 17).
4.3 Algorithm Analysis
In the following, we prove the effectiveness of the proposed RESP algorithm, by
verifying the three conditions mentioned at the beginning of this subsection.
Theorem 1 (Effectiveness of the RESP algorithm). If service request qiis inserted to
an execution sequence by the RESP algorithm, conditions (1), (2) and (3) hold.
Proof. If qiis inserted to the execution sequence by Algorithm 1, we can see the
algorithm confirms that qican be completed in time before inserting it to any part of the
execution sequence (lines 9, 13 and 17), so condition (1) holds. Similarly, the algorithm
confirms that the resources are sufficient before inserting qi(lines 10, 14 and 18), so
condition (2) holds. As for condition (3), if the insertion of qidoes not cause timeout of
any request, it is obvious that the revenue of the mobile device has increased by vqi.If
the insertion of qicauses timeout of a request whose revenue is larger than qi, then the
request will be reinserted by Algorithm 2, which also increases the revenue. Therefore,
condition (3) holds.
If qiis inserted to an execution sequence by Algorithm 2, there must be a request
set dominated by qi. Algorithm 2 confirms that the insert time is before ts
qi(line 2), so if
qireplaces the dominated request set, it can be completed in time, i.e. condition
(1) holds. According to Algorithm 2 and Eq. (6), for each time point, the resources
allocated to the dominated request set and the idle resources of the mobile device add
up to exceed the required resources of qi, and the revenue of the requests in the
dominated request set adds up to exceed the revenue of qi, therefore conditions (2) and
(3) hold. □
The time complexity of both the RESP Algorithm and Timeouts Algorithm are O
(lt
e
n), where ldenotes the length of the execution sequence, t
e
denotes the length of the
execution time of the request (the number of time units) and ndenotes the number of
types of available resources. It implies that the execution time of both algorithms is
feasibly low and it would not cause high overhead to mobile devices.
5 Experiments
We have implemented the algorithms in Python and our experiments are conducted on
a MacBook Pro (macOS Sierra Version 10.12.5). Since no standard platforms and
dataset are available, we generated our experimental data in a synthetic way. Each
mobile device is equipped with three kinds of resource. Service requests are randomly
generated with the revenue ranging from 1 to 10, execution time is from 1 to 6 and the
636 H. Wu et al.
required number of each resource is from 0 to 5. For each request, the time difference
between its deadline and its arrival is from 1 to 10. The number of incoming requests
per time unit obeys normal distribution N(15, 5) and is greater than 0. All the following
experiments are repeated 200 times and we adopt the average values.
5.1 Effectiveness Evaluation
To evaluate the effectiveness of RESP, we compare it with three well-known
scheduling algorithms, namely, First Come First Serve (FCFS), Priority Scheduling
(PS), and Genetic Algorithm (GA). FCFS performs service requests according to their
arrival time. PS assigns higher priorities to the requests with higher revenue and
performs them in a non-increasing order. Both FCFS and PS reject a request if no
sufficient resources or time to execute it. GA is a widely used heuristic method in
scheduling, and it is realised by successively iterating to generate better solutions. In
the following, we vary the mean of the number of incoming requests per time unit from
5 to 40 to compare the effectiveness of the four methods. The result is shown in Fig. 4.
From Fig. 4(a), the RESP approach outperforms FCFS, PS and GA in terms of
revenue at all times. FCFS performs worst due to that fact it does not consider the
revenue of the requests and only processes them according to their arrival sequence. PS
prioritizes the requests by their revenue. To do so, it will cause all the resources to be
used to perform the requests with high priorities and the requests with low priorities are
ignored. As a result, the total amount of service requests drops and leads to the revenue
dropping as well. GA considers both resource and revenue, so its performance is better
than FCFS and PS. However, due to its algorithmic complexity, it is hard to generate
the optimal solution in an online manner. With the significant performance improve-
ment, our proposed approach does not cause the overuse of mobile devices. As shown
in Fig. 4(b), there is no obvious difference in the resource utilization rate of the four
methods, which suggests that, by using the RESP approach, mobile devices can create
more revenue with same amount of resources.
Fig. 4. Experimental results of effectiveness evaluation
Revenue-Driven Service Provisioning for Resource Sharing 637
5.2 Efficiency Evaluation
To evaluate the efficiency of RESP, we compared the execution time of the four
methods. For the GA approach, we set the number of iterations from 20 to 100 with the
increment interval of 20. The result is shown in Table 2, from which we can see that
the execution time of GA is several orders of magnitude higher than the other three
methods. The revenue of GA becomes stable from GA-60, but the overall revenue is
still worse than our RESP method.
We further vary the length of the execution sequence, mean requests number, mean
execution time and the number of the type of resources respectively to evaluate the
scalability of the RESP algorithm. As shown in Fig. 5(a)-(c), with the increasing of the
length of execution sequence, mean requests number, mean execution time, the exe-
cution time of RESP increases almost linearly, which is in accordance with the analysis
given in Subsect. 4.3. Besides, as shown in Fig. 5(d), with the increasing number of the
type of resources, the execution time of RESP decreases. This is because the increased
resource number makes requests more difficult to be executed and thus decreases the
length of the request sequence. Overall, the execution time of RESP is feasibly low and
it has good scalability, which demonstrates the applicability of RESP to mobile devices.
6 Conclusion
In this paper, we study the problem of revenue-driven service provision for mobile
devices. A lightweight service-based approach called RESP (revenue-driven service
provision for mobile devices) is proposed to perform service request selection, request
scheduling and resource allocation simultaneously, with the objective to maximizing
the revenue of the mobile devices. To evaluate the performance of the approach, we
have conducted a set of experiments, which demonstrated the efficacy of RESP.
Table 2. Execution time comparison
FCFS PS RESP GA-20 GA-40 GA-60 GA-80 GA-100
Revenue 58.4 61.9 76.7 60.6 65.6 69.5 70.0 70.2
Execution time (ms) 0.59 0.62 3.06 386.82 818.80 1145.57 1487.51 1851.06
(a) (b) (c) (d)
Fig. 5. Experimental results of efficiency evaluation
638 H. Wu et al.
In future, we will focus on elaborating RESP in detail and fine tuning its parameters
to improve its performance. Furthermore, we will implement RESP on a real scenario
and adjust the algorithm by analysing the feedback.
Acknowledgement. This research was partially supported by Key Research and Development
Project of Zhejiang Province (No. 2015C01027, No. 2015C01034, No. 2015C01029, and
No. 2017C01013), Natural Science Foundation of Zhejiang Province (No. LY17F020014) and
Major Science and Technology Innovation Project of Hangzhou (No. 20152011A03).
References
1. Albagli-Kim, S., Shachnai, H., Tamir, T.: Scheduling jobs with dwindling resource
requirements in clouds. In: 2014 International Conference on Computer Communications
(INFOCOM), pp. 601–609. IEEE (2014)
2. Al Noor, S., Hasan, R., Haque, M.: Cellcloud: a novel cost effective formation of mobile
cloud based on bidding incentives. In: 2014 International Conference on Cloud Computing
(CLOUD), pp. 200–207. IEEE (2014)
3. Arslan, M.Y., Singh, I., Singh, S., Madhyastha, H.V., Sundaresan, K., Krishnamurthy, S.V.:
CWC: a distributed computing infrastructure using smartphones. IEEE T. Mobile Comput.
14(8), 1587–1600 (2015)
4. Ausubel, L.M., Milgrom, P.: The lovely but lonely Vickrey auction. Comb. Auct. 17,22–26
(2006)
5. Chen, X.: Decentralized computation offloading game for mobile cloud computing. IEEE
Trans. Parallel Distrib. Syst. 26(4), 974–983 (2015)
6. Chen, X., Jiao, L., Li, W., Fu, X.: Efficient multi-user computation offloading for
mobile-edge cloud computing. IEEE/ACM Trans. Netw. 24(5), 2795–2808 (2016)
7. Deng, S., Huang, L., Wu, H., Wu, Z., Zomaya, A.Y.: Constraints-driven service composition
in mobile cloud computing. In: 2016 International Conference on Web Services (ICWS),
pp. 228–235. IEEE (2016)
8. Deng, S., Huang, L., Wu, H., Tan, W., Taheri, J., Zomaya, A.Y., Wu, Z.: Toward mobile
service computing: opportunities and challenges. IEEE Cloud Comput. 3(4), 32–41 (2016)
9. Dinh, H.T., Lee, C., Niyato, D., Wang, P.: A survey of mobile cloud computing:
architecture, applications, and approaches. Wirel. Commun. Mob. Com. 13(18), 1587–1611
(2013)
10. Fernando, N., Loke, S.W., Rahayu, W.: Mobile cloud computing: a survey. Future Gener.
Comput. Syst. 29(1), 84–106 (2013)
11. Iosifidis, G., Gao, L., Huang, J., Tassiulas, L.: An iterative double auction for mobile data
offloading. In: 2013 International Symposium on Modeling & Optimization in Mobile, Ad
Hoc & Wireless Networks (WiOpt), pp. 154–161. IEEE (2013)
12. Koutsopoulos, I.: Optimal incentive-driven design of participatory sensing systems. In: 2013
International Conference on Computer Communications (INFOCOM), pp. 1402–1410.
IEEE (2013)
13. Lee, C., Wang, P., Niyato, D.: A real-time group auction system for efficient allocation of
cloud internet applications. IEEE T. Serv. Comput. 8(2), 251–268 (2015)
14. Liu, C., Shang, Y., Duan, L., Chen, S., Liu, C., Chen, J.: Optimizing workload category for
adaptive workload prediction in service clouds. In: Barros, A., Grigori, D., Narendra,
Nanjangud C., Dam, H.K. (eds.) ICSOC 2015. LNCS, vol. 9435, pp. 87–104. Springer,
Heidelberg (2015). doi:10.1007/978-3-662-48616-0_6
Revenue-Driven Service Provisioning for Resource Sharing 639
15. Liu, K., Peng, J., Li, H., Zhang, X., Liu, W.: Multi-device task offloading with
time-constraints for energy efficiency in mobile cloud computing. Future Gener. Comput.
Syst. 64,1–14 (2016)
16. Liyanage, M., Chang, C., Srirama, S. N.: Lightweight mobile web service provisioning for
sensor mediation. In: 2015 International Conferences on Mobile Services, pp. 57–64. IEEE
(2015)
17. Maguluri, S.T., Srikant, R.: Scheduling jobs with unknown duration in clouds. IEEE ACM
T. Netw. 22(6), 1938–1951 (2014)
18. Miluzzo, E., Cáceres, R. and Chen, Y.F.: Vision: mClouds-computing on clouds of mobile
devices. In: 2012 Workshop on Mobile cloud computing and services, pp. 9–14. ACM
(2012)
19. Srirama, S.N., Jarke, M., Prinz, W.: Mobile host: a feasibility analysis of mobile web service
provisioning. In: UMICS (2006)
20. Wang, C., Yu, F.R., Liang, C., Chen, Q., Tang, L.: Joint computation offloading and
interference management in wireless cellular networks with mobile edge computing. IEEE T.
Veh. Technol. (2017)
21. Yousafzai, A., Chang, V., Gani, A., Noor, R.M.: Directory-based incentive management
services for ad-hoc mobile clouds. Int. J. Inform. Manage. 36(6), 900–906 (2016)
640 H. Wu et al.
