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 computation, communication and storage. The requirements for running applications with 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 computationally intensive tasks to the resource-rich cloud service providers, such as Amazon’s EC2Footnote 1, Microsoft AzureFootnote 2 and Rackspace CloudFootnote 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 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 participation 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 maximizing 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 communication 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 presented a performance analysis of mobile devices. Liyanage et al. proposed a lightweight 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.

Fig. 1.
figure 1

Mobile cloud architecture

Full size image

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 = \left\{ {s_{1} ,s_{2} , \ldots } \right\} \) , 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 \( A_{t} = \left\{ {\left( {r_{i} ,n_{i} } \right)} \right\}_{i = 1}^{m} \) , where m is the total number of the types of the available resources that a mobile device can provide, and \( r_{i} \) and \( n_{i} \) denote 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 \( I_{t} = \left\{ {\left( {r_{i} ,n_{i} } \right)} \right\}_{i = 1}^{m} \).

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 computing [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

$$ I\left( {t,r} \right) = A\left( {t,r} \right) - \sum\nolimits_{{q \in E_{t} }} {R_{r} \left( q \right)} $$
(1)

where \( I\left( {t, r} \right) \) denotes the amount of resource \( r \) that is idle at time \( t \),\( A\left( {t,r} \right) \) denotes the amount of resource \( r \) that is available at time \( t \), \( q \in E_{t} \) denotes the request executing on the mobile device at time \( t \), and \( R_{r} \left( q \right) \) denotes the amount of resource \( r \) that 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 = \left\{ {\left( {r_{i} ,n_{i} } \right)} \right\}_{i = 1}^{m} \) , where m is the number of types of required resources, and \( r_{i} \) and \( n_{i} \) denote 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 \( t^{e} \) , 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 \( \left( {s, d, t^{a} , t^{d} } \right) \) , where:

  • s is the service that is requested;

  • d is the index of the mobile device, to which the request is delivered;

  • \( t^{a} \) is the arrival time of the request;

  • \( t^{d} \) is 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 environment, service requests are highly likely to express real-time requirements, so we introduce \( t^{d} \) to 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 \( E_{t} = \left\{ {q_{i} } \right\}_{i = 1}^{n} \) , expressing that during time unit t, a mobile device d will process n service requests including \( q_{1} \), \( q_{2} \) ,…, \( q_{n} \) , simultaneously.

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. 2 shows an example of an execution sequence, which describes the service execution of a mobile device within the time period of 5 time units.

Fig. 2.
figure 2

Execution sequence example

Full size image

To describe the execution time of a service request, we let \( {}_{ }^{ \bullet } q \) denote the time when request \( q \) starts to be processed and \( q^{ \bullet } \) denotes the time when \( q \) is completed. Corresponding 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 \( E\left( {{}_{ }^{*} q} \right) \) and \( E\left( {q^{*} } \right) \) denote the request that is right ahead of and right behind \( q \) respectively. Specifically, \( E_{l} \) denotes the last request of the execution sequence. For example, according to Fig. 2, we have \( E\left( {q_{1}^{*} } \right) = q_{2} \), \( E\left( {{}_{ }^{*} q_{3} } \right) = q_{2} \) and \( E_{l} = q_{3} \).

Definition 5

(Revenue-Driven Service Provision). Given a mobile device d, with its available resources \( A_{t} = \left\{ {\left( {r_{i} ,n_{i} } \right)} \right\}_{i = 1}^{m} \) and idle resources \( I_{t} = \left\{ {\left( {r_{j} ,n_{j} } \right)} \right\}_{j = 1}^{m} \) , and the incoming service requests \( q_{1} \), \( q_{2} \) , … \( q_{n} \) , the revenue-driven service provision is to select a set of service requests S from the request sequence and schedule them in the execution sequence E to

$$ {\text{Maximize}}\mathop \sum \limits_{q \in S} v_{q} , $$
$$ {\text{s}}.{\text{t}}.\quad q^{ \bullet } - {}_{ }^{ \bullet } q = t_{q}^{e} ,\;for\;each\;q \in S $$
(2)
$$ q^{ \bullet } \le t_{q}^{d} ,\;for\;each\,q \in S $$
(3)
$$ \forall t, \sum\nolimits_{{q \in E_{t} \cap S}} {R_{q} \left( r \right) \le A_{t} \left( r \right)} ,\;for\;{\text{each}}\,r \in A_{t} $$
(4)

It is reasonable to regard maximizing overall revenue of a mobile device as the optimization objective for its service provisioning. Equation 2 implies 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.

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 summarized in Table 1.

Table 1. Mathematical Notations
Full size table

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. (1)

    The request can be completed before its deadline;

  2. (2)

    The request can be allocated with sufficient resources;

  3. (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

$$ t_{q}^{s} = t_{q}^{d} - t_{q}^{e} $$
(5)

where \( t_{q}^{d} \) is the deadline of the request q, and \( t_{q}^{e} \) is the execution time of the request q.

Figure 3 shows the flowchart of the RESP algorithm. For a given request \( q_{i} \), we first 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 \( t_{c} \), 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 \( {\mathcal{T}} \) will 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 \( q_{i} \). The actual start time can be before, equal to or after the reference start time \( {\mathcal{T}} \).

Fig. 3.
figure 3

Flowchart of the RESP algorithm

Full size image

The pseudo code of the RESP algorithm is shown in Algorithm 1. For an incoming service request \( q_{i} \), we first 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 \( q_{i} \) to the rear of the execution sequence (line 5). If there exists a scheduled request in the execution sequence and its deadline is behind \( q_{i} \), then the reference start time of \( q_{i} \) should be moved forward (lines 6-7).

Once the reference start time \( {\mathcal{T}} \) is determined, we will use the start time minimization technique to check whether \( q_{i} \) can be performed before \( {\mathcal{T}} \) (lines 9-12). If there is a time interval where the mobile device has more idle resources than those required (line 10), then \( q_{i} \) can 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 \( q_{i} \) is not before \( {\mathcal{T}} \) (line 13), then we check whether \( q_{i} \) can be started at \( {\mathcal{T}} \). If the mobile device has enough available resources for \( q_{i} \) during its execution period (line 14), then \( q_{i} \) should be started from \( {\mathcal{T}} \) (line 15). If the idle resources during that interval are not enough for \( q_{i} \), \( q_{i} \) can 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 \( q_{i} \), the algorithm will continue checking whether there is any time interval between \( {\mathcal{T}} \) and the latest start time of \( q_{i} \) that has sufficient resources (lines 17-21). If one exists, \( q_{i} \) should be inserted to that interval (line 19).

After the above search process, if \( q_{i} \) cannot 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 \( q_{i} \) or some other scheduled requests being declined. For the cases that \( q_{i} \) is 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.

Definition 7

(Dominance). Given a service request \( q_{i} \) , an execution sequence E and a set of scheduled service requests S in E, \( q_{i} \) dominates S if and only if

$$ \exists t\,{\text{s}}.{\text{t}}.\,\forall t_{0} \in \left( {t, t + t_{{q_{i} }}^{e} } \right)\,{\text{and}}\,\forall r \in R_{{q_{i} }} , $$
$$ R_{{q_{i} }} \left( r \right) < I_{{t_{0} }} \left( r \right) + \sum\nolimits_{{q \in S \cap E_{{t_{0} }} }} {R_{q} \left( r \right)} \,{\text{and}}\, v_{{q_{i} }} > \sum\nolimits_{q \in S} {v_{q} } $$
(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 \( S \) exceeds the required resources of \( q_{i} \). Meanwhile, the revenue for executing \( q_{i} \) is more than executing all requests in \( S \). Obviously, if \( q_{i} \) dominates \( S \), the requests in \( S \) can be safely replaced by \( q_{i} \), 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 \( q_{i} \), the algorithm tries to find a dominated 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 \( q_{i} \) and with less revenue than the previous minimum revenue, which is represented by \( {\mathcal{M}} \) in 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 \( q_{i} \) and with less revenue (lines 8-13). 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 \( q_{i} \) and move the subsequent requests accordingly (line 15), otherwise, it means that no request set dominated by \( q_{i} \) is found and \( q_{i} \) should 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 \( q_{i} \) is inserted to an execution sequence by the RESP algorithm, conditions (1), (2) and (3) hold.

Proof.

If \( q_{i} \) is inserted to the execution sequence by Algorithm 1, we can see the algorithm confirms that \( q_{i} \) can 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 \( q_{i} \) (lines 10, 14 and 18), so condition (2) holds. As for condition (3), if the insertion of \( q_{i} \) does not cause timeout of any request, it is obvious that the revenue of the mobile device has increased by \( v_{{q_{i} }} \). If the insertion of \( q_{i} \) causes timeout of a request whose revenue is larger than \( q_{i} \), then the request will be reinserted by Algorithm 2, which also increases the revenue. Therefore, condition (3) holds.

If \( q_{i} \) is inserted to an execution sequence by Algorithm 2, there must be a request set dominated by \( q_{i} \). Algorithm 2 confirms that the insert time is before \( t_{{q_{i} }}^{s} \) (line 2), so if \( q_{i} \) replaces 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 \( q_{i} \), and the revenue of the requests in the dominated request set adds up to exceed the revenue of \( q_{i} \), therefore conditions (2) and (3) hold.□

The time complexity of both the RESP Algorithm and Timeouts Algorithm are O(lt e n), where l denotes the length of the execution sequence, t e denotes the length of the execution time of the request (the number of time units) and n denotes 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 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.

Fig. 4.
figure 4

Experimental results of effectiveness evaluation

Full size image

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 improvement, 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.

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.

Table 2. Execution time comparison
Full size table

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 execution 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.

Fig. 5.
figure 5

Experimental results of efficiency evaluation

Full size image

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.

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.