CENTURION: Incentivizing Multi-Requester Mobile Crowd SensingWe sincerely thank Professor Julia Chuzhoy for her valuable contribution. We gratefully acknowledge the support of National Science Foundation grants CNS-1330491, and 1566374. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the sponsors.

CENTURION: Incentivizing Multi-Requester Mobile Crowd Sensingthanks: We sincerely thank Professor Julia Chuzhoy for her valuable contribution. We gratefully acknowledge the support of National Science Foundation grants CNS-1330491, and 1566374. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the sponsors.

Haiming Jin1, Lu Su2, Klara Nahrstedt1
1Department of Computer Science, University of Illinois at Urbana-Champaign, IL, USA
2Department of Computer Science and Engineering, State University of New York at Buffalo, NY, USA
Email: hjin8@illinois.edu, lusu@buffalo.edu, klara@illinois.edu
Abstract

The recent proliferation of increasingly capable mobile devices has given rise to mobile crowd sensing (MCS) systems that outsource the collection of sensory data to a crowd of participating workers that carry various mobile devices. Aware of the paramount importance of effectively incentivizing participation in such systems, the research community has proposed a wide variety of incentive mechanisms. However, different from most of these existing mechanisms which assume the existence of only one data requester, we consider MCS systems with multiple data requesters, which are actually more common in practice. Specifically, our incentive mechanism is based on double auction, and is able to stimulate the participation of both data requesters and workers. In real practice, the incentive mechanism is typically not an isolated module, but interacts with the data aggregation mechanism that aggregates workers’ data. For this reason, we propose CENTURION, a novel integrated framework for multi-requester MCS systems, consisting of the aforementioned incentive and data aggregation mechanism. CENTURION’s incentive mechanism satisfies truthfulness, individual rationality, computational efficiency, as well as guaranteeing non-negative social welfare, and its data aggregation mechanism generates highly accurate aggregated results. The desirable properties of CENTURION are validated through both theoretical analysis and extensive simulations.

\pdfinclusioncopyfonts

=1

I Introduction

Recent years have witnessed the rise of mobile crowd sensing (MCS), a newly-emerged sensing paradigm that outsources the collection of sensory data to a crowd of participating users, namely (crowd) workers, who usually carry increasingly capable mobile devices (e.g., smartphones, smartwatches, smartglasses) with a plethora of on-board sensors (e.g., gyroscope, camera, GPS, compass, accelerometer). Currently, a large variety of MCS systems [1, 2, 3, 4, 5, 6] have been deployed that cover almost every aspect of our lives, including healthcare, smart transportation, environmental monitoring, and many others.

To perform the sensing tasks, the participating workers typically consume their own resources such as computing and communicating energy, and expose themselves to potential privacy threats by sharing their personal data. For this reason, a participant would not be interested in participating in the sensing tasks, unless she receives a satisfying reward to compensate her resource consumption and potential privacy breach. Therefore, it is necessary to design an effective incentive mechanism that can achieve the maximum user participation. Due to the paramount importance of stimulating participation, many incentive mechanisms [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31] have been proposed by the research community. However, most of these aforementioned past literature assume that there is only one data requester who also serves as the platform in the MCS system. In practice, however, there are usually multiple data requesters competing for human resources, who usually outsource worker recruiting to third-party platforms (e.g., Amazon Mechanical Turk [32]) that have already gathered a large number of workers. Therefore, in this paper, we focus on such MCS systems where three parties, including the data requesters, a platform (i.e., a cloud-based central server), as well as a crowd of participating workers co-exist, and aim to develop a new incentive mechanism that can decide which worker serves which data requester at what price.

In real practice, the sensory data provided by individual workers are usually quite unreliable due to various factors (e.g., poor sensor quality, lack of sensor calibration, environment noise). Hence, in order to cancel out the possible errors from individual workers, it is highly necessary that the platform utilizes a data aggregation mechanism to properly aggregate their noisy and even conflicting data. In an MCS system, the incentive and the data aggregation mechanism are usually not isolated from each other. In fact, the data aggregation mechanism typically interacts with the incentive mechanism, and thus, affects its design and performance. Intuitively, if the platform aggregates workers’ data in naive ways (e.g., voting and average) that treat all workers’ data equally, the incentive mechanism does not need to distinguish them with respect to their reliability. However, a weighted aggregation method that puts higher weights on more reliable workers is much more desirable, because it shifts the aggregated results towards the data provided by the workers with higher reliability. Accordingly, the incentive mechanism should also incorporate workers’ reliability, and selects workers that are more likely to provide reliable data.

Therefore, different from most of the aforementioned existing work [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31], we propose CENTURION111The name CENTURION comes from inCENTivizing mUlti-Requester mobIle crOwd seNsing., a novel integrated framework for multi-requester MCS systems, which consists of a weighted data aggregation mechanism that considers workers’ diverse reliability in the calculation of the aggregated results, together with an incentive mechanism that selects workers who potentially will provide more reliable data. Specifically, CENTURION’s incentive mechanism is based on double auction [33], which involves auctions among not only the workers, but also the data requesters, and is able to incentivize the participation of both data requesters and workers. This paper makes the following contributions.

  • Different from existing work, we propose a novel integrated framework for multi-requester MCS systems, called CENTURION, consisting of a data aggregation and an incentive mechanism. Such an integrated design, which captures the interactive effects between the two mechanisms, is much more complicated and challenging than designing them separately.

  • CENTURION’s double auction-based incentive mechanism is able to incentivize the participation of both data requesters and workers, and bears many desirable properties, including truthfulness, individual rationality, computational efficiency, as well as non-negative social welfare.

  • The data aggregation mechanism of CENTURION takes into consideration workers’ reliability, and calculates highly accurate aggregated results.

In the rest of this paper, we first discuss the past literature that are related to this work in Section II, and introduce the preliminaries in Section III. Then, the design details of CENTURION’s data aggregation and incentive mechanism are described in Section IV. In Section V, we conduct extensive simulations to validate the desirable properties of CENTURION. Finally in Section VI, we conclude this paper.

Ii Related Work

Aware of the paramount importance of attracting worker participation, the research community has recently developed various incentive mechanisms [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31] for MCS systems. Among them, game-theoretic incentive mechanisms [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28], which utilize either auction [10, 18, 19, 20, 28, 11, 12, 13, 24, 21, 22, 23, 25, 26, 27] or other game-theoretic models [16, 17, 9, 8, 15, 14], have gained increasing popularity due to their ability to tackle workers’ selfish and strategic behaviors. These mechanisms typically aim to maximize the platform’s profit [18, 19, 20, 21, 16, 17, 15, 14, 22, 23] or social welfare [10, 11, 12, 13, 9], and minimize the platform’s payment [24, 8, 7, 25, 26, 27] or social cost [28].

Different from most of the aforementioned past literature which assume that there exists only one data requester, we propose a novel incentive mechanism for MCS systems with multiple data requesters that compete for human resources. In fact, there do exist several prior work [22, 19, 28] designing incentive mechanisms for the multi-requester scenario. However, they do not provide any joint design of the data aggregation and the incentive mechanism as in this paper, which is much more challenging than designing the two mechanisms as isolated modules. Moreover, although similar integrated designs that consider the two mechanisms are proposed in some existing work [25, 26], as previously mentioned, they assume that only one data requester exists in the MCS system.

Iii Preliminaries

In this section, we introduce the system overview, reliability level model, auction model, as well as the design objectives.

Iii-a System Overview

CENTURION is an MCS system framework consisting of a cloud-based platform, a set of participating workers, denoted as , and a set of requesters, denoted as . Each requester has a sensing task to be executed by the workers. The set of all requesters’ tasks is denoted as . We are specifically interested in the scenario where is a set of different binary classification tasks that require workers to locally decide the classes of the events or objects, and report to the platform their local decisions (i.e., the labels of the observed events or objects). Such MCS systems, collecting binary labels from the crowd, constitute a large portion of the currently deployed MCS systems (e.g., congestion detection systems that decide whether or not particular road segments are congested [2], geotagging campaigns that tag whether bumps or potholes exist on specific segments of road surface [1, 3]).

Each task has a true label , unknown to the requesters, the platform, and the workers. If a worker is chosen to execute task , she will provide to the platform a label . We define as the matrix containing all workers’ labels, where means that task is not executed by worker . For every task , the platform aggregates workers’ labels into an aggregated result, denoted as , so as to cancel out the errors from individual workers. The framework of CENTURION is given in Figure 1, and we describe its workflow as follows.

Fig. 1: Framework of CENTURION (where circled numbers represent the order of the events).
  • Incentive Mechanism. Firstly, in the double auction-based incentive mechanism, each requester submits to the platform a sensing request containing the sensing task to be executed (step

    1

    ), and a bid , the amount she is willing to pay if the task is executed (step

    2

    ). Then, the platform announces the set of sensing tasks to the workers (step

    3

    ). After receiving the task set, every worker sends to the platform the set of tasks she wants to execute, denoted as , as well as a bid , which is her bidding price for executing them (step

    4

    ). Based on received bids, the platform determines the set of winning requesters , the set of winning workers , as well as the payment charged from every winning requester and the payment paid to every winning worker (step

    5

    ). Note that losing requesters’ tasks are not executed, and thus, they do not submit any payment. Similarly, losing workers do not receive any payment, as they do not execute any task.

  • Data Aggregation Mechanism. Next, the platform collects the labels submitted by the winning workers (step

    6

    ), calculates the aggregated results, and sends them to the winning requesters (step

    7

    ).

  • Finally, the platform charges from winning requester (step

    8

    ), and pays to winning worker (step

    9

    ).

We denote the requesters’ and workers’ bid profile as and , respectively. Moreover, the requesters’ and workers’ payment profile is denoted as and , respectively.

Iii-B Reliability Level Model

Before worker executes task , her label about this task can be regarded as a random variable . Then, we define the reliability level of a worker in Definition 1.

Definition 1 (Reliability Level).

A worker ’s reliability level about task is defined as the probability that she provides a correct label about this task, i.e.,

(1)

Moreover, we denote the workers’ reliability level matrix as .

We assume that the platform knows the reliability level matrix a priori, and maintains a historical record of it. In practice, the platform could obtain through various approaches. For example, as, in many scenarios, workers tend to have similar reliability levels for similar tasks, the platform could assign to workers some tasks with known labels, and use workers’ labels about these tasks to estimate their reliability levels for similar tasks as in [34]. In cases where ground truth labels are not available, can still be effectively inferred from workers’ characteristics (e.g., the prices of a worker’s sensors, a worker’s experience and reputation for similar tasks) using the algorithms proposed in [35], or estimated using the labels previously submitted by workers about similar tasks by the methods in [36, 37].

Iii-C Auction Model

In this paper, we consider the scenario where both requesters and workers are strategic and selfish that aim to maximize their own utilities. Since CENTURION involves auctions among not only the workers, but also the requesters, we utilize the following double auction for Multi-rEquester mobiLe crOwd seNsing (MELON double auction), formally defined in Definition 2, as the incentive mechanism.

Definition 2 (MELON Double Auction).

In a double auction for multi-requester mobile crowd sensing (MELON double auction), each requester obtains a value , if her task is executed, and bids to the platform , the amount she is willing to pay for the execution of her task. Each worker is interested in executing one subset of the tasks, denoted as , and bids to the platform , her bidding price for executing these tasks. Her actual sensing cost for executing all tasks in is denoted as . Both the requesters’ values and workers’ costs are unknown to the platform.

Then, we define a requester’s and worker’s utility, as well as the platform’s profit in Definition 3, 4, and 5.

Definition 3 (Requester’s Utility).

A requester ’s utility is defined as

(2)
Definition 4 (Worker’s Utility).

A worker ’s utility is defined as

(3)
Definition 5 (Platform’s Profit).

The profit of the platform is defined as

(4)

Based on Definition 3, 4, and 5, we define the social welfare of the MCS system in Definition 6.

Definition 6 (Social Welfare).

The social welfare of the MCS system is defined as

(5)

Clearly, the social welfare is the sum of the platform’s profit and all requesters’ and workers’ utilities.

Iii-D Design Objectives

In this paper, we aim to ensure that CENTURION bears the following advantageous properties.

Since the requesters are strategic and selfish in our model, it is possible that any requester submits a bid that deviates from (i.e., her value for task ). Similarly, any worker might also submit a bid that differs from (i.e., her cost for executing all tasks in ). Thus, one of our objectives is to design a truthful incentive mechanism defined in Definition 7.

Definition 7 (Truthfulness).

A MELON double auction is truthful if and only if bidding and is the dominant strategy for each requester and worker , i.e., bidding and maximizes, respectively, the utility of each requester and worker , regardless of other requesters’ and workers’ bids.

By definition 7, we aim to ensure that both requesters and workers bid truthfully to the platform. Apart from truthfulness, another desirable property that we aim to achieve is individual rationality defined in Definition 8.

Definition 8 (Individual Rationality).

A MELON double auction is individual rational if and only if no requesters or workers receive negative utilities, i.e., we have , and , for every requester and worker , respectively.

Individual rationality is a crucial property to stimulate the participation of both requesters and workers, because it ensures that the charge to a requester is no larger than her value, and a worker’s sensing cost is also totally compensated. As mentioned in Section III-A, CENTURION aggregates workers’ labels to ensure that the aggregated results have satisfactory accuracy, which is mathematically defined in Definition 9.

Definition 9 (-Accuracy).

A task is executed with -accuracy if and only if , where , and denotes the random variable representing the aggregated result for task .

By Definition 9, -accuracy ensures that the aggregated result equals to the true label with high probability. Note that, for every task , is a parameter chosen by the platform, and a smaller implies a stronger requirement for the accuracy.

In short, our objectives are to ensure that the proposed CENTURION framework provides satisfactory accuracy guarantee for the aggregated results of all executed tasks, and incentivizes the participation of both requesters and workers in a truthful and individual rational manner.

Iv Design Details

In this section, we present the design details of the incentive and data aggregation mechanism of CENTURION.

Iv-a Data Aggregation Mechanism

Iv-A1 Proposed Mechanism

Although the data aggregation mechanism follows the incentive mechanism in CENTURION’s workflow, we introduce it first, as it affects the design of the incentive mechanism.

In order to capture the effect of workers’ diverse reliability on the calculation of the aggregated results, CENTURION adopts the following weighted aggregation method. That is, the aggregated result for every executed task is calculated as

(6)

where is worker ’s weight on task . Furthermore, the function equals to , if , and otherwise.

Intuitively, higher weights should be assigned to workers who are more likely to submit correct labels, which makes the aggregated results closer to the labels provided by more reliable workers. In fact, many state-of-the-art literature [36, 37] utilize such weighted aggregation method to aggregate workers’ data. As the weight ’s highly affect the accuracy of the aggregated results, we propose, in the following Algorithm 1, the data aggregation mechanism of CENTURION.

Input: , , , , ;
Output: ;
1 foreach  s.t.  do
2        ;
3       
4return ;
Algorithm 1 Data Aggregation Mechanism

Algorithm 1 takes as inputs the reliability level matrix , the workers’ label matrix , the profile of workers’ interested task sets, denoted as , the winning requester set , and the winning worker set . Note that a large indicates that a worker has a high reliability level for task , and any worker with will not be selected as a winner by the incentive mechanism. The aggregated result for each winning requester ’s task is calculated (line 1-1) using Equation (6) with the weight

(7)

By Equation (7), we have that , i.e., worker ’s weight for task , increases with , which conforms to our intuition that the higher the probability that worker provides a correct label about task , the more her label should be counted in the calculation of the aggregated result about this task. We provide the formal analysis about the data aggregation mechanism in Section IV-A2.

Iv-A2 Analysis

In Theorem 1, we prove that the aggregated results calculated by Algorithm 1 has desirable accuracy guarantee.

Theorem 1.

For each executed task , the data aggregation mechanism given in Algorithm 1 minimizes the upper bound of the error probability of the aggregated result, i.e., (where is the random variable representing the aggregated result for task mentioned in Definition 9), and satisfies that

(8)
Proof.

We denote as the random variable for worker ’s weighted label about task , i.e., with probability , and with probability . Then, we define , and thus, .

The error probability of the aggregated result can be calculated as , and based on the Chernoff-Hoeffding bound, we have

Then, we define the vector for every executed task , which contains every such that , and . Therefore, minimizing the upper bound of is equivalent to finding the vector that maximizes the function defined as

Based on the Cauchy-Schwarz inequality, we have

and equality is achieved if and only if . Thus,

(9)

Similarly, from the Chernoff-Hoeffding bound, we have

The upper bound of is also minimized if and only if based on the Cauchy-Schwarz inequality, and we have

(10)

From Inequality (9) and (10), we have that when , the upper bound of is minimized, and

which exactly proves Theorem 1. ∎

By Theorem 1, we have that the data aggregation mechanism proposed in Algorithm 1 upper bounds the error probability by , which in fact is the minimum upper bound of this probability. Next, we derive Corollary 1, which is directly utilized in our design of the incentive mechanism in Section IV-B.

Corollary 1.

For every executed task , the data aggregation mechanism proposed in Algorithm 1 satisfies that if

(11)

then , i.e., -accuracy is satisfied for this task , where is a platform chosen parameter. Moreover, we define as the vector .

Proof.

By setting the upper bound of given in Theorem 1 to be no greater than , we have

which is equivalent to

(12)

Hence, together with Theorem 1, we have that Inequality (12) indicates that . ∎

Corollary 1 gives us a sufficient condition, represented by Inequality (11), that the set of winning workers selected by the incentive mechanism (proposed in Section IV-B) should satisfy so as to achieve -accuracy for each executed task .

Iv-B Incentive Mechanism

Now, we introduce the design details of CENTURION’s incentive mechanism, including its mathematical formulation, the hardness proof of the formulated integer program, the proposed mechanism, as well as the corresponding analysis.

Iv-B1 Mathematical Formulation

As mentioned in Section III-C, CENTURION’s incentive mechanism is based on the MELON double auction defined in Definition 2. In this paper, we aim to design a MELON double auction that maximizes the social welfare, while guaranteeing satisfactory data aggregation accuracy. The formal mathematical formulation of its winner selection problem is provided in the following MELON double auction social welfare maximization (MELON-SWM) problem.  

MELON-SWM Problem:

(13)
s.t. (14)
(15)

Constants. The MELON-SWM problem takes as inputs the task set , the worker set , the requesters’ and workers’ bid profile and , the profile of workers’ interested task sets , the workers’ reliability level matrix , and the vector.

Variables. On one hand, the MELON-SWM problem has a vector of binary variables, denoted as . Any indicates that task will be executed, and thus, requester is a winning requester (i.e., ), whereas means . On the other hand, the problem has another vector of binary variables, denoted as , where indicates that worker is a winning worker (i.e., ), and means .

Objective function. The objective function satisfies that , which is exactly the social welfare defined in Definition 6 based on the requesters’ and workers’ bids.

Constraints. For each task , Constraint (14) naturally holds, if . When , it is equivalent to Inequality (11) given in Corollary 1, which specifies the condition that the set of selected winning workers should satisfy in order to guarantee -accuracy for task . To simplify the presentation, we introduce the following notations, namely , , , and . Thus, Constraint (14) can be simplified as

(16)

Besides, we say a task is covered by a solution, if .

Iv-B2 Hardness Proof

We prove the NP-hardness of the MELON-SWM problem by performing a polynomial-time reduction from the 3SAT(5) problem which is formally defined in Definition 10.

Definition 10 (3SAT(5) Problem).

In a 3SAT(5) problem, we are given a set of Boolean variables, and a collection of clauses. Each clause is an OR of exactly three literals, and every literal is either a variable of or its negation. Moreover, every variable participates in exactly 5 clauses. Therefore, . Given some constant , a 3SAT(5) instance is a Yes-Instance if there is an assignment to the variables of satisfying all clauses, whereas it is a No-Instance (with respect to ), if every assignment to the variables satisfies at most clauses. An algorithm distinguishes between the Yes- and No-instances of the problem, if, given a Yes-Instance, it returns a “YES” answer, and given a No-Instance it returns a “NO” answer.

Regarding the hardness of the 3SAT(5) problem, we introduce without proof the following well-known Lemma 1, which is a consequence of the PCP theorem [38].

Lemma 1.

There is some constant , such that distinguishing between the Yes- and No-instances of the 3SAT(5) problem, defined with respect to , is NP-complete.

Next, we introduce Theorem 2 and 3 that will be utilized to prove the NP-hardness of the MELON-SWM problem.

Theorem 2.

Any 3SAT(5) instance is polynomial-time reducible to an instance of the MELON-SWM problem.

Proof.

The reduction goes as follows. Assume there is a 3SAT(5) instance on variables and clauses. We define 3 parameters: (), , and . The exact values of and are not important. We just need to ensure . We construct an instance of the MELON-SWM problem corresponding to , by defining the task set , and the profile of workers’ interested task sets .

Out of the 8 possible assignments to the variables of some clause , exactly one does not satisfy . Let be the set of the remaining 7 assignments. We define a set of tasks for each clause and assignment , let for each clause and assignment , set the value of each worker and task as , and set her bid as . We also create a dummy worker , with , , and being her interested task set. We start with all set ’s being empty, gradually define the tasks, and specify which sets they belong to. The task set consists of 4 subsets.

  • The 1st subset contains a task for each variable and assignment to this variable. belongs to each set , such that participates in , and the assignment to the variables of gives assignment to . The value of the task corresponding to is set as , and the value of this task is set as .

  • The 2nd subset contains tasks . Each belongs to all sets corresponding to and , i.e., belongs to all sets with the subscripts being modulo . The value of each such is set as , and its value is set as .

  • The 3rd subset contains a task for each clause , and belongs to set for each . The value of the task corresponding to is set as 1, and its value is set as .

  • The 4th subset contains a single task , whose value is set as and value is set as . The task only belongs to set .

This finishes the description of the reduction. Clearly, given a 3SAT(5) instance , we can construct an instance of the MELON-SWM problem in time polynomial in . ∎

We now analyze the optimal social welfare for an instance of the MELON-SWM problem that corresponds to a 3SAT(5) instance , when is a Yes- or No-Instance. Note that the following analysis uses the same reduction as in Theorem 2.

Theorem 3.

If the 3SAT(5) instance is a Yes-Instance, then there is a solution to the resulting instance of the MELON-SWM problem whose social welfare is . If is a No-Instance, then any solution has social welfare at most .

Proof.

Let be a Yes-Instance, and be an assignment to the variables satisfying all clauses. We construct a solution to the MELON-SWM problem. Firstly, we add to . Next, for each clause , we add to the unique set , where is the assignment consistent with . Then , and the total cost of all sets is . We now analyze the number of tasks covered by , and their values. Clearly, is covered by , and it contributes to the solution value.

  • For each clause , the unique task is covered. Thus, all tasks in are covered, and overall they contribute value to the solution.

  • Consider some . contains one set corresponding to and , respectively. Since belongs to both these sets, and its is 2, it is covered. Thus, all tasks in are covered, and they contribute value to the solution.

  • Consider some variable , and let be the assignment to under . If is any clause containing , and is the set that belongs to , then gives the assignment to . Thus, for all five clauses containing , the corresponding sets chosen to contain , and this task is covered. So the total number of tasks of covered by is . Each such task contributes value 5, and the total value contributed by the tasks in is .

Therefore, the overall social welfare of this solution is .

Assume now that is a No-Instance, and let be any solution with positive social welfare. We can assume that , and task is covered by . We then introduce the following observations, whose proofs are provided in the appendices.

Observation 1.

For every clause of , at most one of the sets belongs to , and .

Observation 2.

For every variable , at most one of the two tasks and is covered by .

We say that a variable is bad if neither nor is covered by ; otherwise it is good. We next show that only a small number of the variables are bad.

Observation 3.

There are at most bad variables.

Then, we construct the following assignment to the variables of . If variable is good, then there is a unique value , such that task is covered by . We then assign the value . If is bad, we assign it any value arbitrarily. We now claim that the above assignment satisfies more than clauses. We say that a clause is bad if it contains a bad variable, and it is good otherwise. Since there are at most bad variables, and each variable participates in 5 clauses, the number of bad clauses is at most . So there are more than good clauses. Let be a good clause, and be the set corresponding to that belongs to . Then is an assignment to the variables of that satisfies , and each variable participating in was assigned a value consistent with . So clause is satisfied.

To conclude, we have assumed that is a No-Instance, and showed that, if the MELON-SWM problem has a solution with non-negative social welfare, there is an assignment to the variables of satisfying more than of its clauses, which is impossible for a No-Instance. Therefore, if is a No-Instance, every solution has social welfare at most . ∎

Next, we describe Theorem 4 that states the NP-hardness and inapproximability of the MELON-SWM problem.

Theorem 4.

The MELON-SWM problem is NP-hard, and for any factor , there is no efficient -approximation algorithm to the MELON-SWM problem.

Proof.

Based on Theorem 2, there exists a reduction from any 3SAT(5) problem instance to an instance of the MELON-SWM problem. From Theorem 3, we have that the optimal solution to also gives a solution to . That is, if the optimal social welfare of is positive, then is a Yes-Instance; otherwise, is a No-Instance. Together with Lemma 1 stating the NP-completeness of the 3SAT(5) problem, we conclude that the MELON-SWM problem is NP-hard.

In fact, Theorem 2 and 3 give an inapproximability result about the MELON-SWM, as well. Suppose there is an efficient factor- approximation algorithm for the MELON-SWM problem. We can use it to distinguish Yes- and No-instances of the 3SAT(5) problem on variables. If is a Yes-Instance, then the algorithm has to return a solution with positive social welfare for , and if is a No-Instance, then any solution has social welfare at most 0. So algorithm distinguishes the Yes- and the No-instances of 3SAT(5), contradicting Lemma 1. ∎

Iv-B3 Proposed Mechanism

Theorem 4 not only shows the NP-hardness of the MELON-SWM problem, but also indicates that there is no efficient algorithm with a guaranteed approximation ratio for it. Therefore, we relax the requirement of provable approximation ratio, and propose the following MELON double auction that aims to ensure non-negative social welfare, instead. Its winner selection algorithm is given in the following Algorithm 2.

Input: , , , , , , , ;
Output: , , ;
// Initialization
1 , ;
// Find a feasible cover
2 ;
3 foreach  s.t.  do
4        ;
5       
// Main loop
6 while  do
7        ;
8        ;
9        ;
10        ;
11        foreach  s.t.  do
12               ;
13              
14       
15return ;
Algorithm 2 MELON Double Auction Winner Selection

Algorithm 2 takes as inputs the task set , the requester set , the worker set , the profile of workers’ interested task sets , the requesters’ and workers’ bid profile and , the matrix, as well as the vector. Firstly, it initializes the winning requester and worker set as (line 2). Then, it calculates a feasible cover, denoted by , containing the set of workers that make Constraint (16) feasible for each task given that each , by calling another algorithm FC which takes the task set , the profile of workers’ interested task sets , the matrix, and the vector as inputs (line 2). Algorithm FC can be easily implemented in time polynomial in and . For example, FC could greedily select each worker into the feasible cover in a decreasing order of the value until all constraints are satisfied. The computational complexity of such FC is . We assume that FC adopts such a greedy approach in the rest of this paper. Note that the specific choice of FC is not important, as long as it returns a feasible cover in polynomial time. Next, for each task , Algorithm 2 chooses from the feasible cover the set of workers whose interested task sets contain this task (line 2-2).

Based on , the main loop (line 2-2) of the algorithm selects the set of winning requesters and workers that give non-negative social welfare. It executes until , the maximum marginal social welfare of including a new requester and the set of workers into, respectively, the winning requester and worker set, becomes negative (line 2). In each iteration of the main loop, the Algorithm finds first the index of the requester that provides the maximum marginal social welfare (line 2). Next, it includes into the winning requester set (line 2), removes from the requester set (line 2), and includes all workers in into the winning worker set (line 2). The last step of the main loop is to remove all workers in from for each task (line 2). Finally, Algorithm 2 returns the winning requester and worker set and (line 2).

Next, we present the pricing algorithm of the MELON double auction in Algorithm 3.

Input: , , , , , , , , , ;
Output: , ;
// Initialization
1 , ;
// Pricing for winning requesters
2 foreach  s.t.  do
3        run Algorithm 2 on and ;
4        winning requester set when line 3 stops;
5        foreach  s.t.  do
6               ;
7              
8       if  then
9               ;
10              
11       
// Pricing for winning workers
12 foreach  s.t.  do
13        run Algorithm 2 on and ;
14        winning requester set when line 3 stops;
15        foreach  s.t. and  do
16               sort requesters according to the decreasing order of ;
17               index of the first requester with ;
18               if  then
19                      ;
20                     
21              else
22                      ;
23                     
24              
25       
26return ,