1

D-CLOC: A Delay Tolerant Cloud Formation UsingContext-Aware Mobile Crowdsourcing

Shahid Al Noor and Ragib Hasan {shaahid, ragib}@cis.uab.eduDepartment of Computer and Information Sciences, UAB, AL 35294-1170

Abstract—Gathering information and providing remote assis-tant is a common trend as it saves time and cost associatedwith visiting the actual location in person. The widely availablemobile sensors are used in collecting information during a taskprocessing. However, gathering information from a remote place,or an area of disaster, is not trivial, given the unavailability ofappropriate infrastructure. Existing delay tolerant networkingapproaches address this issue but suffer from unsatisfactoryperformance due to the lack of sufficient user participation.We propose the Delay-tolerant Cloud Computing framework(D-CLOC), a cloud framework utilizing the contextual infor-mation of a mobile client. Our proposed architecture combinescrowdsourcing and the cellular network and forms a temporaldelay tolerant cloud. D-CLOC uses a bidding incentive modelto ensure and promote user participation in the cloud. Weprovide a detailed reasoning of the security and feasibility ofour model, and delineate probable approaches for solving thevarious security related aspects. The paper includes the designand implementation of a realistic-simulation model for D-CLOC.The simulation scenario incorporates an example face recognitiontask for evaluating the performance of our proposed model. Ourexperimental results show that D-CLOC performs quite wellcompared to some of the existing DTN approaches and can bedeployed for solving any real life problems using crowdsourcingwithin a delay tolerant cloud infrastructure.

Index Terms—delay tolerant cloud, ad hoc cloud, sense cloud.

I. INTRODUCTION

Mobile computing and sensing have become popular in re-cent years. However, it is difficult to provide any computationalor sensing service in places where no network infrastructureis available or the existing network service stops functioningbecause of the occurrence of any unexpected event, such as,natural disasters. One way to solve this issue is to find aperson who is planning to visit that place and request thatperson for collecting and processing the data related to humanquery, and sending the result while coming back from thatplace, or in case of computational needs, ask the person tovisit the location and contribute computational resources atthat place. However, motivating a person for visiting that place,performing the required sensing and computing operations, anddelivering the result on time are very challenging. In addition,tracking the progress of the assigned task and verifying theauthenticity of the received result are very difficult. Using thedelay tolerant network (DTN) [1, 2], we can ensure the deliveryof a user query to that network disconnected area. However, theDTN system does not work if the retrieval of the informationrequires distributed sensing or computing operations in thatarea. Moreover, in the DTN approach, the task provider needsto participate actively for hiring some suitable mobile nodes,determining the incentive policy for the nodes, detecting theselfish or malicious nodes, and validating the received result.Therefore, we must have an automated system that sends any

task to a network uncovered area, collects and process dataassociated with the task, performs required computations onthose data to generate the result, and delivers that result backto the task provider.

Researchers proposed several routing schemes for improvingthe performance of the DTN. Reputation based delay tolerantprotocols are discussed in [3–5], while probabilistic approacheswere presented in [6–9] and context based approaches werediscussed in [10–12]. However, using the existing DTN ap-proach, it is hard to predict the frequency of interaction betweentwo nodes. Moreover, all the existing DTN systems do nothave any proper countermeasures for protecting the selfishnessbehavior of a user. In addition, the DTN approach suffers if amobile device in a remote place has limited resources whilethe task requires resource intensive computations. Some ofthe researchers proposed sensor cloud for performing suchresource intensive computation where a group of mobile userscollaboratively collect data using their mobile sensors and sendthe data to any third party cloud provider for processing [13, 14].The problem occurs when people fail to communicate with anythird party cloud provider for data processing due to the absenceof any network service in their current place. On the other hand,several researchers proposed ad hoc cloud architectures forinstant computation of resource intensive tasks [15, 16]. Most ofsuch architectures fail due to the absence of a proper incentivemodel for the participants. Crowdsourcing is a human-basedcomputational process that motivates users for task participationby providing monetary incentives to them [17–19]. However,finding loyal users with adequate knowledge and preservinga reasonable level of quality along with ensuring continuousnetwork connectivity are major challenges on human basedcomputation [20].

We propose D-CLOC, a Delay-tolerant CLOud Computingarchitecture that coalesces cellular network and the DTN, andforms an ad hoc cloud using crowdsourcing and contextualanalysis of the participants. During the formation of D-CLOC,the interested users are requested to register their devices as bid-ders in order to participate on a task computation. The biddersparticipating on a task are provided monetary incentives thatvaries depending on their performance. The client contacts D-CLOC for accessing a place of interest (POI) and accomplishesa task on that place. D-CLOC collects contextual information,such as bidders possible future location and average movementspeed, and selects some bidders appropriate for task forwardingto the POI. The selected bidders might opportunistically chooseanother bidder for task forwarding. As soon as a bidder reachesto the POI with a task, an ad hoc cloud is formed to computethat task by considering the available bidders in the POI. Afterfinishing the task, the ad hoc cloud searches for appropriatebidders for result delivery. The selected bidders deliver the

2

result to a base station either directly or indirectly through itsappointed bidders.Contributions:

1) To the best of our knowledge, this is the first attemptto form a delay tolerant cloud system using mobilecrowdsourcing in the DTN system.

2) We introduce a context based task forwarding schemefor the DTN for efficient delivery of a task to the POI.

3) We provide thorough performance analysis via simula-tions to show the feasibility and performance of ourapproach.

The rest of the paper is organized as follows. In section II,we specify the motivation of our research. Section III providesa discussion of related research work. Section IV describes ourD-CLOC architecture followed by the elaboration of individualunits in section V. Section VI covers potential challenges inD-CLOC. We demonstrate our experimental result in sectionVII. Finally, in section VIII and IX we conclude our workalong with discussion and future prospect.

II. MOTIVATION

A geographical area is referred to as a communicationchallenged area if it is in high demand but difficult to accessphysically due to the absence of any network service. Thetraditional telecommunication operators hesitate to invest insuch areas because of the high risks of not getting returnon their investment. Therefore, it is hard to ensure a cloudservice on those areas for solving a real life problem. Inthe following sections, we mention some of the possiblehypothetical application scenarios where we can use D-CLOC.A. Information collection during natural disaster: Recently,several areas of a village Trenton is damaged because ofearthquake. Mr. Han lives in a city Patathorne and wants toknow about his friend Mr. John, who lives in Trenton. Dueto the earthquake, both the cellular and the Internet service iscurrently unavailable. However, Mr. Han can contact D-CLOCin order to know about his friend’s current condition.B. Getting a Uber like service: Although around 1000people live in Fellaby, it is a place with very poor networkinfrastructure. Mr. Mark lives in Frannycote and is planning tovisit one of his friend who lives in Fellaby. Mr. Mark wants tomake sure that someone can dfdsfds him from the bus stationto his friend’s house at around 11 PM. However, due to theabsence of proper network services, he cannot contact directlyto anyone from his current place. Mr. Mark can use D-CLOCin order to get a ride on payment basis.

edfC. Monitoring agriculture and irrigation remotely: Mr.Jacob has some crop fields in his village while he worksin a city that is 300 miles far from that village. Mr. Jacobhas already established some sensors in his crop field in orderto collect images, temperature, CO2 concentration, and soilmoisture. Now, he needs some refinement and processing onthose sensor’s collected data for gathering specific informationabout his crop field. Moreover, he is also looking for someonewho can deliver that information from the filed to him. Since thecrop field is outside of any network coverage, he cannot contactanybody directly for crowdsourcing. However, Mr. Jacob cantake D-CLOC service and monitor his crop field remotely.

III. RELATED WORK

Researchers proposed several routing protocols for improvingthe performance of the DTN. One such method is barter-based strategy where each node needs to send a message to anode in order to receive a message from it [21]. This modelunderperforms when a node has more number of messagesthan another node. Another method is credit-based mechanismwhere each node receives some rewards either from the sourcenode (message purse model) [22] or from the destinationnode (message trade model) [23] for participating on messageforwarding. In future, the node can use those rewards for its ownmessage transfer. In message purse model, the node can reuseits reward for delivering another message while its previousmessage is still on the process of delivery. On the other hand,one primary problem of message trade model is that the sourcenode might intentionally be involved in message flooding forearning reward. For reducing the flooding, Jain et al. proposedsingle copy of message system for each intermediate node[24]. However, this approach has a very high latency and lowdelivery packet transfer ratio. Reputation based strategy is theanother popular DTN approach, where a node earns a reputationvalue if it successfully forwards a message [3]. However, thisapproach fails to detect collusion cheating.

Sensor cloud is a popular approach where sensor nodes areused for collecting information where as, third party cloudproviders are used for storing, processing, or analyzing thoseinformation [25]. Fortino et al. proposed BodyCloud, a sensorcloud system that used cloud services for processing bodysensor data streams [26]. Similar kind of architecture wasproposed by Doukas and Maglogiannis for pervasive healthcarewhere IOT devices were used as sensors [27]. Chatterjee et al.proposed dynamic mapping algorithm that used sensor cloudfor tracking of multiple targets [28]. Zingirian et al. proposeda sensor cloud architecture for providing an intelligent truckmonitoring service [29]. However, all the above cloud basedsensor data processing architectures fail if no third party cloudprovider can be contacted due to the absence of any network.

Recently, hiring human for performing computational taskhas gained immense popularity on several areas of computersciences. Amazon Mechanical Turk is one such instance ofgeneral purpose crowdsourcing that act as a mediator betweenlabor requesters and workers [17]. CastingWords and ClariTransare two popular domain-specific mechanical turks that are ableto transcript audio whereas, Tagasaurus and TagCow are twopopular mechanical turks for image classification. Buildinglarge knowledge databases based on human computationis a very effective approach in AI [30, 31],business [32],cryptography [33], art [34], genetic algorithms [35], and HCI[36]. However, finding loyal users with adequate knowledge andpreserving a reasonable level of quality are major challengeson human based computation [20]. In addition, integratingseveral interrelated complicated tasks in crowdsourcing isdifficult due to the absence of any complete automationsystem. Furthermore, anticipating the time and the cost ofa task completion in crowdsourcing is hard because, skills andmonetary expectations vary from human to human.

Noor et al. proposed CellCloud, a mobile cloud architecture

3

formed by unused mobile devices [37] . Users on the CellCloudwere provided monetary incentives based on their performancehistory. However, their model requires continuous networkconnectivity with cellular system in order to serve the client.Hasan et al. presented Aura, an ad hoc IoT based cloudcomputing model, which allowed mobile clients to createproximal clouds using the IoT and other computing devices inthe nearby physical environment [38]. However, their researchwork requires an extensive experiment with larger task sizeand more number of IoT devices in order to consider it as anefficient ad hoc cloud system.

IV. D-CLOC ARCHITECTURE OVERVIEW

Our proposed D-CLOC architecture is depicted in fig 1 anda simulated diagram of D-CLOC formation is shown in fig 2.In this section, we provide a high level overview of D-CLOCand provide the operational details in the next section. At thestarting phase of D-CLOC formation, the D-CLOC providerrequests all of its users to participate in bidding along withproviding an incentive scheme to the user. This scheme showsusers the amount of money it can receive for different reputationpoints (RP). The RP denotes the level of trustworthiness ofa bidder for a task. The interested users register themselvesas bidders and receive an initial RP. This RP is increasedor decreased depending on the bidder’s behavior. We referclients as those who contact D-CLOC for a task. The Cloudcentral point (CCP) is the central part of the D-CLOC. TheCCP receives a task and query every base stations (BS) forsubmitting the contextual information of the bidders withintheir coverage area. A detailed analysis is performed by theCCP on the collected contextual information. The CCP uses atwo phase nomination-selection strategy in order to determinethe best bidder for a task forwarding (described in section V).

After the detailed analysis of available resources, CCPdecides whether it is possible to perform the task usingthe available resources. CCP selects some of the bidders asforwarding bidders (FB) for transferring the task to the POI.In case an FB cannot reach to the POI, it searches for anotherbidder and if it meets a bidder, includes that bidder in itsforwarding plan. The newly included bidder is also referred toas an FB, i.e., it imitates all the functionality of a regular FB.After reaching to the POI, an FB starts searching for someavailable bidders for forming an ad hoc cloud. During thead hoc cloud formation, some of the hired bidders are onlyassociated with a task computation. We refer them as secondarybidder (SB). On the other hand, some of the bidders in additionto a task computation are also responsible for task distributionand monitoring, result verification and reduction, and resultdelivery. We refer them as primary bidders (PB).

Once a task is successfully finished, PBs search for biddersthat are planning to move outside from the POI and deliverthe result separately on each of them. The FB tries to reachto a BS for delivering the result. In case it cannot reach, itstarts searching another bidder for result delivery. Once a BSreceives a result, it delivers it to the CCP. The CCP evaluatesthe cost of the operation that includes transfer, computational,and receiving cost, and decides the price of the task afterconsidering its profit. Upon the approval of the client on theprice, the CCP delivers the result to the client.

V. OPERATIONAL MODELA. Role of the CCP

Providing interface: A client can request D-CLOC for atask using an web interface (D-Web). Client browses D-Weband fills all the required information related to the task suchas, POI, deadline, budget etc. The information is processedand converted to an intermediate format (IF) for simplifyingthe analysis process for the CCP. JSON is used as IF forinformation exchange between two bidders or between a bidderand a base station. Fig 3 shows the snapshot of a generatedJSON file while the client submits its request for a task.Collection of contextual information: The CCP retrievesbidder’s contextual information using either of the followingtwo procedures:

1) Event collection: There are plenty of social networkingsites (e.g., Flickr, YouTube, Twitter, Facebook) that are con-sidered as an effective source of collecting user context [39].User frequently creates events on those sites and invites otherusers to participate on those events. When a user creates anevent, he/she also posts the time and location of that event.Moreover, user uses several third party apps that are designedspecifically for generating events such as, Google calendar. Ifa bidder allows automatic retrieval of context then the CCPcan retrieve the time and places where user is planning to visit.

2) User intervention: Some users might not feel comfortin allowing the CCP to access any events or status informationfrom their social networking profiles or created events. Insuch cases, the CCP sends separate forms to know the usercontext. At first, CCP queries the user whether he has anyplan to visit the POI within deadline. If the user replies withno answer then user receives another form where he needs tosubmit the information of his future location in hourly basisfor next couple of hours. If the user does not want to providethe detailed information about his future location then the CCPcommunicates with the user using get&response protocol. Eachget message contains one location name and query the userwhether he has any plan to visit that place. User sends hisanswer in reply message. The process is repeated until eitherthe user sends a “yes” as a reply message or the thresholdlevel of get message is exceeded.Bidders’ performance evaluation: The bidders’ performancesare evaluated by assigning them RP, which varies from -1 to1. CCP assigns an RP of 0.5 as soon as a user registers hisdevice as a bidder. A reward point of 1 is assigned to a bidderif it has contribution on either 1) a successful delivery of taskto the POI, 2) successful delivery of result from the POI toany BS, or 3) computation of a valid result.

The new RP of the bidder is, rpnew = (rpcurrent + reward)/2 .On the other hand, a bidder is punished by reducing its RP ifit is involved in any of the following activities:

1) task modification: In this case, the bidder who detectsthe incident of task modification, reports against the sender tothe CCP as malicious incident. The CCP verifies the reportand upon finding a malicious communication, it punishes themalicious bidder with a penalize point of -1.

2) wrong result transmission: In this case, the bidder whodetects the incident of wrong result, reports against the senderto the CCP as suspicious incident. In addition, a client can also

4

         

                         Adhoc Cloud in POI

Client FB

SB

SB

SB Primary Bidders

Central Control Point (CCP)

FB

SB

BS BS BS

FB FB FB FB FB

Fig. 1: architecture Fig. 2: Simulated diagram of D-CLOC formation

{"client_type":  "normal",  "task_info":  {  

"input":  "image",  "type"  :  "face_recogni8on”},  

"loca8on":  {        "la8tude":  41.25,        "longitude":  -­‐120.97,        "radius":  50m}  "reliability":  null}  

"deadline":  {        "start_date”:"04/20/2015",        "start_8me":  "11:30"          "end_date":  "04/20/2015",        "end_8me":  "14:30”}  

Fig. 3: Intermediate message format

report against a result that it has already received. However,it is not necessarily true that a bidder always intentionallyprovides wrong result. Due to the lack of knowledge of theenvironment, a bidder can also deliver wrong result. The CCPverifies the report and punishes a bidder with a penalize pointof 0 upon finding an involvement of intentional malicious resultgeneration. The new RP is computed as, rpnew = (rpcurrent +

penalty)/2 .Calculation of the cost of operation: We consider two typesof cost associated with a task during total cost computation;cost of using network resources and cost of hiring a bidder.Cost of network varies from operator to operator since theinvestment on the network resources for transferring each unitof data is not the same for every operator and each operatorhas its own return on investment plan. If we consider thatan operator pays Ct for transferring each unit of data and anoperator exchanges u unit of data within its network then thecost for operator is ctu. Let us assume that an operator makess% profit on its total cost of data transfer. Then the cost afterconsidering the profit is, Cn = ctu ∗ (100 + s)/100 .

Cost of hiring a bidder depends on how long a bidder ishired for a task either in the form of FB, PB, or SB, and theRP of that bidder. If the operator decides to pay p unit ofincentives for each seconds of hiring a bidder and a bidder ishired for t unit of time then the total cost of a bidder with RPof r is, Cb = 10 ∗ (r + 1) ∗ p ∗ t .

B. Role of Bidder

A bidder can act as an FB, PB, or SB. The role of each ofthose types of bidders are described bellow:Forwarding Bidder (FB): An FB is responsible for forwardinga task to a bidder in the POI or a place close to the POI. Itcan receive the task from a BS or another FB. In addition,an FB also forwards a result receiving from another FB toa BS or another FB. A receipt as a proof of delivery is sentby the sending FB to the receiving FB after transferring atask. The receipt contains the time and location of deliveryalong with the FB’s signature. If requires, the bidder can showthis receipt in future for claiming its participation on a validcommunication.Secondary Bidder (SB): The primary responsibility of anSB is to compute a task as instructed by the PB. A PB sendsinstructions to an SB in abstract form. First, the SB extracts theinformation of required sensors for data collection from thoseinstructions. Next, SB extracts the meaningful information fromits sensor collected data. For example, suppose client wantsto know the total exhibition stands in a trade fair. First, thecamera collects all the images of the exhibition that includesnot only the images of exhibition but also the people observing

that exhibition. Therefore, the images are filtered and then thepart of the image representing an exhibition stand is extractedin the second phase. This raw data (image, audio, video etc)are transferred to PBs after each periodic interval along withthe extracted meaningful information.Primary Bidder (PB): Just like an SB, the primary bidder canalso participate actively on a task computation. In addition, aPB simplifies the computational procedure by dividing a largetask into smaller subtasks, distributes those among other PBsand SBs, and collaboratively perform that task. Moreover, aPB communicates with another PB to know its progress. PBis also responsible for refining the data collected from an SB.A PB periodically receives the raw or preprocessed data fromSBs. Since SBs are located very close to each other, there isa high chance of getting redundant data. Matching the time,location, and the sensor collected raw data, a PB identifies anyredundancy if exists. Furthermore, a PB is also responsible forverifying a result sent by SBs or other PBs.

C. Formation of Ad hoc Cloud

When an FB contacts the POI, it initiates a query messageand broadcasts it within its coverage area for knowing thepresence of other bidders. The bidders in the POI acknowledgethe message and broadcast further within their coverage area.On the other hand, a bidder ignores the query message if it isoutside the POI or it has already received the message. Theflow diagram of query message is shown in fig 4a. From thequery reply message, a bidder knows the information of itsadjacent bidders. A bidder is considered as a core bidder if ithas at least K adjacent bidders. A zone is formed by the biddersin the POI where within a zone a bidder has connectivity toany other bidder either directly or through the core bidder(s)in a path. The core bidders within a zone are considered asPB and are primarily responsible to decide the policy for thetask in that zone. A sample zone formation process is shownin fig 4b where we assume that the minimum adjacent biddersrequired for becoming a core bidder is 3. From fig 4b, we seethat bidder number 2,4, and 9 are core bidders since they haveat least 3 adjacent bidders. There are two zones; red zoneswith PBs (2,4) and SBs (1,3,5,6), and yellow zones with PB9 along with SBs (8, 10, 11). The bidder 7 is considered asan isolated bidder since it is a non-core bidder and has noconnectivity to any of the core bidder. Therefore, bidder 7 isnot considered for any task until it becomes a core bidder orit meets any core bidder to become a member of a zone.

In the ad hoc cloud formation, any bidder can dynamicallyjoin or leave and act as a PB or SB. An SB can be maturedto as a PB if it fulfills the criteria for the core bidder. Oncea bidder is promoted to as a PB, it will remain as a PB even

5

         

       

FB B

B

B

B

B

B B

B B B

B

B

                 

Query

Reply

Discard

POI

Outside POI

(a) Flow of Initial query

2

7

5 1

Secondary bidder

Primary Bidder

6

8

9

4

3

10

11

Isolated Bidder

(b) Process of forming zone

Fig. 4: Formation of Adhoc Cloud

after loosing its core tag. On the other hand, if a PB/SB leavesthe zone, it will no longer be considered as a PB/SB for thatzone. However, that bidder can be a PB/SB of another zoneif it satisfies the criteria for PB/SB after joining in that zone.An SB informs the corresponding PB/PBs before leaving azone. If there is any partially deliverable result, SB transfersthat result to the corresponding PB/PBs. On the other hand, aPB cannot leave a zone immediately until it is approved by50% of the total PB on that zone. Just like an SB, a PB alsotransfers any deliverable result before leaving the zone andwaits for getting approval of at least 50% of the total PBs inthe zone. Every time a bidder meets another bidder, it checksthe following conditions before changing its status:

Bidders in the same zone: Two bidders are considered as thesame zone bidders if they have the same zone id. If any twosame zone bidders meet each other, then they just update theiradjacency information. If any of the two bidders becomes coreafter the update, it informs that incident to the PBs on thatzone. The PBs on that zone send confirmation to that bidderregarding its promotion to a PB. If both the bidders are alreadyPB, then they just update their adjacency information.

Bidders in different zones: If two non core bidders meet eachother, then the bidder(s) that become(s) core after discoveringthe other bidder form(s) a zone with a randomly chosen corebidder as zone id. Otherwise, each bidder just updates itsadjacency information without forming a zone. If bidders oftwo different zones meet each other and both become core afterconsidering each other as neighbor, then the two zones aremerged into a single zone. Any zone id between the two zonesis chosen randomly as the new zone id. If a non-core bidderbecomes a core bidder after meeting another non-core bidder, itrequests the other PBs to approve it as a PB. All the non-coreadjacent bidders of that new PB are then considered as thepart of that zone. Otherwise, they just update their adjacencyinformation. However, a bidder can only be part of a singlezone. Therefore, if a non-core bidder has connectivity withtwo bidders of different zones, it is considered a member ofonly one zone.

Zones in the POI are independent to each other and computethe task separately. As soon as a bidder computes the task,the result is sent to the PBs for verification. PBs verify theresult and approve or reject the result. If the tasks assignedto the bidders are dependent on each other, then PBs wait forgetting all the results. Once they receive the result from all thebidders, they start reducing the result. Otherwise, as soon asa result is received, PBs start searching for some appropriateFBs to forward the result.

D. Nomination-Selection Strategy

The CCP constructs the context of a bidder in the form ofa set S composed of all <L,T> pairs, which indicates bidderslocation L at time point T. If we divide the time durationinto n number of time slots then S contains n number ofLT pairs. During the nomination phase of bidder selectionstrategy, each bidder nominates its best LT pair in S. SupposeSm =< L1, T1 > ... < Ln, Tn > be the n LT pairs of a bidder m.Then the cost for nth LT pair in S, fn = Tn + hn . Here, hndenotes the possible time bidder can reach to the POI. Wedefine hn considering two parameters; the straight line distancebetween Ln and center of the POI, and the speed of the bidder.If dn is the distance between Ln and the POI, and the biddermoves at a speed of vn unit/s then hn = dn/vn. The nominated<L,T>pair for a bidder m is, NBm = min(fn).

In the selection phase, we compute a normalized value foreach bidder from its nominated cost and RP. The normalizedcost of a bidder m is defined as, NCBm

= NBm/rp. Thebidders are sorted in ascending order based on their normalizedcost. The bidders that come first in the sorted list are selectedfirst for task forwarding.

VI. THREAT MODELA. Challenges

In this section, we will discuss the possible challenges thatwe might face during the design of D-CLOC.

1) Authentication Problem: In D-CLOC, it can be possiblethat a malicious node modifies or deletes the task. In addition,it can also fabricate a misleading result. Hence, it is veryimportant to verify both the sender and receiver beforeexchanging any information.

2) Task Verification Problem: Malicious bidders inside theD-CLOC can modify the task and provide wrong task to thebidders in the POI. Consequently, bidders deliver wrong resultto the CCP. Hence, D-CLOC requires a proper mechanism toverify the integrity of a task that was originally sent by theCCP.

3) Tracking Bidder: Some of the bidders can claim thatthey were involved during a task computation without actuallyparticipating on it. In addition, a group of malicious bidders canunnecessarily interexchange the task among them and claimmoney from D-CLOC for task forwarding. Therefore, findingout the actual bidders associated with a task computation orsending/receiving result to/from the POI is very challenging.Additionally, a proper mechanism needs to be implemented inorder to prevent flooding within a malicious group.

4) Result Verification: Result verification is another majorchallenge in D-CLOC. A bidder can provide wrong or incorrectresult due to the presence of malware in its device. Moreover,a bidder can also generate a fake result for earning moneywithout actually involving in task computation. Therefore, weneed to provide a mechanism for verifying the result.

B. Countermeasure1) Authentication and Tracking Bidders: The CCP

generates a private-public key pair (KCR, KCA) during theformation of D-CLOC. In addition, when a bidder joins inthe bidding process, a private-public key pair (KHostR, KHostA)is assigned to that bidder. The CCP generates a hash value

6

after attaching a time stamp with the task and signed it as,EkCR

[H(Task, Ts), Task, Ts] .Before forwarding the task, sending bidder generates a

random challenge, encrypts it using KCA, and ask the receivingbidder to response. If the receiving bidder responses withcorrect challenge, sender attaches a time stamp that indicates thetime of task transfer and sends the task to the receiving bidderafter encryption. The receiving bidder decrypts the messageusing KCA, generates the hash value from the decryptedmessage, matches it with the sender generated hash value,and discards the message if these two mismatches. The aboveapproach prohibits any unauthorized user to participate on thecomputation. Only the registered bidder knows the KCA and isable to decrypt the challenge and can participate on the task.The malicious bidder still can access the task since they haveKCA. However, they cannot modify the task content since thehash value will be different after modification. Morover, theCCP signs the task. Therefore, no other bidder can generate arandom task, and request any other bidder to participate.

In addition, each bidder keeps track of the path the taskhas traversed so far. We propose a hash-based approach fortracking the bidders in a task chain where each bidder receivesthe hash value of the nodes the task visited before arriving toit. The bidder computes the new hash value of the chain ofnodes by adding its id with previously received hash value. Forexample, if there are 4 bidders X, Y, Z , and U in the chainthen the sequence of computation will be as follows:

X− > Y : MX = [H(IDX , EKCA(IDX , KXA, 1], Y− > Z : MY =

[H(MX , IDY ), [EKCA(IDY ), EKCA

(IDX ], KY A, 2], Z− > U : MZ =

[H(MY , IDZ), [EKCA(IDZ), EKCA

(IDY ), EKCA(IDX)], KZA, 3].

From the communication between Y and Z, we find that Ygenerates a hash value of its ID and the hash value generatedby X. It also encrypts its ID using the public key of the CCP.Moreover, it attaches its public key along with the encrypted IDof X. Finally, it also sends the total path that the task so far hasvisited. If any malicious bidder removes a legitimate bidder onthe task chain then the CCP can easily verify that by computingthe hash value of the bidder list on the chain. Furthermore,each receiving bidder can only know the information about thesender while the id of the other bidders on the task transferchain is concealed through encryption. The CCP can verifytotal bidders participated on forwarding by extracting thenumber from the attached massage. In the above example, theCCP decrypts three values EKCA

(IDZ), EKCA(IDY ), and

EKCA(IDX) using KCR since the value attached with the

message is 3. After decryption, the CCP will find that hostsX, Y, and Z participated on forwarding before reaching to thePOI. The CCP will then verify whether any malicious bidderhas modified the content by computing the hash value M’X,M’Y, M’Z and matching it with the hash value MZ. If the hashvalue matches , the CCP will considers this communication asa valid communication.

2) Verifying Result: In D-CLOC, it is the responsibility ofthe PBs to ensure that an SB is eligible for a task computation.In addition, PBs also ensure that the result delivered by an SB iscorrect. For testing the eligibility of an SB, a PB extracts a smallsubtask from a task as a challenge and ask the SB to computethe challenge. The PB sends the actual task for computation

only after successfully completion of that challenge. EachSB sends its sensor collected raw data and the correspondingcomputed result to that PB. The PB randomly selects a portionof the collected result for verification. This portion is dividedinto n number of slots where each slot is a combination of araw data and its corresponding result. For each slot, k numberof PBs within the zone are randomly selected. The slot issent to those selected PBs for verification. The selected PBsseparately compute their result from the received raw dataand acknowledge the received result if it matches with theircomputed result. A threshold level r is defined for each slot.The slot is considered valid if r bidders confirms the result.A result from an SB is considered valid if all the slots of theselected portion of that result are valid.

C. Security Policy

We define the following policies in order to protect D-CLOCfrom misusing and deliver authentic result to the client.Pay only active bidders: The bidders who were involvedsomehow with a successful task completion are considered asactive bidders. We divide our tasks in three parts; i) deliverthe task on the POI, ii) compute the task in the POI, iii)deliver the result from the POI to a BS. The representativebidder (RB) is the first bidder that receives the task in the POI.The RB provides a receipt as a proof of successful deliveryof the message. The receipt also includes the receiving timeand location along with the encrypted list of FBs associatedwith the task forwarding to that RB. Similarly, once a taskis successfully completed, the bidder that carries the resultprovides a receipt as a proof of task completion. The receiptalso includes the time and the location of receiving the resultalong with the id of the bidders involved in task computation.Accept the first path: A bidder can receive a task frommultiple bidders through different paths. The bidder onlyaccepts the first valid task while rejects the others. Similarly,if several bidders carry the same result and forward it to eithera bidder or a BS, only the first valid result will be accepted.Incentive for the first valid computation: In the POI, eachzone individually produces a result. Therefore, k number ofresults can be produced if k zones are formed by the bidders inthe POI. Those k independent results are forwarded separatelyto the CCP. As soon as a result is received by the CCP, itperforms a spot check for verifying that result. If the resultpasses the spot check, the CCP accepts the result and discardsall the other results that it has received. All the bidders in thezone that is associated with producing that result receive moneyfor the computation. Since only one zone is awarded, all thezones will try to produce a valid result as soon as possible.Eventually, this will reduce the selfish nature of a bidder sincea bidder will not receive any money for producing fake resultor making unnecessary delay in task computation.Client feedback: After delivering a result to the client, theclient is asked to provide feedback regarding the result. Clientscan send their dissatisfaction regarding the quality, time, orcost of the result. To ensure fairness for both the client andthe D-CLOC provider, we consider a small amount of taskregistration fee for each task regardless of client receives asatisfactory or unsatisfactory result. In addition, the CCP shows

7

a small demo result to the client and delivers the completeresult only after receiving client’s approval. Moreover, theCCP might verify again some portion of the result in order todetermine whether client dissatisfaction claim is valid or not.Furthermore, an RP is assigned to each client which can beincreased or decreased depending on client’s behavior.

VII. SIMULATION SETUP

We used the Opportunistic Network Environment (ONE),which is a Java based open source simulator for delay tolerantnetwork [40]. Each bidder has a Bluetooth interface withtransmission radius of 10 meter along with a 4G activatedcell service. We simulated our model considering the Helsinkicity map as the base of our simulating environment. In ourfirst experiment, we compared the performance of D-CLOCwith the three other popular DTN approaches: epidemic [41],spray and wait [42], and prophet [43] routing approach. Weassumed that the pedestrian are moving from 0.5 to 1.5 m/sspeed and a pause time of 0 to 120s while the cars and busesare moving from 2.7 to 13.9 m/s and 7 to 10 m/s respectivelywith a pause time of 0 to 120s and 10 to 30s respectively. Weassumed that bidders are randomly distributed over the city.The probability that a person has some evening activities afterfinishing the work is 0.5 with a group size of 1 to 3 friends.The length of the working day is set to 28800s and the pausetimes within office follows Pareto distribution with coefficient0.5, min value of 10s and max value of 10000s. The differencein schedules of bidders follow a normal distribution with astandard deviation of 7200s. The size of message varies from5 KB to 15 KB. Messages are generated in every 10s intervalswith TTL value of 300 minutes. All the radio devices are set toa transmission speed of 250 KBps and a buffer size of 20 MB.We run the simulation for D-CLOC, Epidemic Routing, Sprayand wait Routing, and Prophet Routing. The correspondingresults are shown in fig 5a, 5b, and 5c respectively.

From fig 5a and 5b, we can see that the average messagetransfer time is much smaller while the packet delivery rate ismuch higher in D-CLOC than Epidemic, Spray and Wait, andProphet routing protocol. D-CLOC uses cellular network’s BSas an intermediate node during message forwarding. Hence,using D-CLOC, we get much better performance than theother DTN routing protocols. Additionally, using the contextualinformation during selection of a node ensures that a task canbe reached quickly to the POI while traversing through thenetwork uncovered areas. On the other hand, from figure 5c,we see that power consumption is much higher in D-CLOCthan the other three DTN approaches. There are two reasonsfor the excessive power consumption. First, both base stationsand the CCP consume a significant amount of power. Second,a node located outside the coverage area of the cellular systemforwards the task to all the nodes that it meets on its way.

In the second experiment, we considered an image recogni-tion task as our sample task and showed the performance of ourD-CLOC with different bidder sizes. In this task, client wantsto know whether a target person (TP) is (will be) present in thePOI at any time within a specified time interval (deadline). Weconsidered the same map structure as described in our previousexperiment but instead of distributing the traffic randomly

throughout the map, we divide the traffic into two groups. Ourfirst group (G1) was composed of the bidders that are movingthroughout the entire map. We assumed that there are somebidders that are moving only within the POI and the secondgroup (G2) of bidders is formed considering those bidders. Forsimplicity, we assumed that the TP is (will be) existed insidethe POI during the deadline. Our primary intention was to seehow fast D-CLOC finds the TP and returns a snapshot of the TPfrom the POI to the client. Using android openCV platform, wecreated an app that can automatically turns on the camera, takethe picture from the camera, detect any face from the picture,and save it to its storage device. Initially, we train our appwith some sample images of the TP. We ran our app on threedifferent devices; nexus7(1.5GHz processor and 2 GB ram),htc(1GHz processor and 512MB RAM), and Motorola(1GHzprocess and 1 GB RAM). The average time taken by the deviceto return a match or un-match result is considered as the basetime for it. We assumed that each bidder carries any of thesethree devices. If a match is found the bidder sends the detectedface to PBs. For calculating the cost of operation, we assumedthat each bidder with an RP of 0.1 receives 1 cent for holdingthe task for a second. In addition, we assumed that when azone completes a task successfully, all the PBs and SBs withinthat zone receive 1 cent for every second of task computation.In our first scenario, we assumed that there are total 10 numberof G1 bidders. Client sends several TPs within a deadline andask D-CLOC to search that TP in the POI. We carry out theexperiment, repeatedly, by varying the number of G2 biddersfrom 5 to 50. In each iteration, we computed the average of allthe receiving result’s time. In second scenario, we increasedthe size of G2 bidders from 10 to 20 and repeat the wholeprocedure. The corresponding graph for the time and the costof the operation is shown in fig 6a and 6b respectively.

From fig 6a, we see that increasing the G2 bidder sizedecreases the task completion time as more bidders arenow searching for the TP. The cost of the operation alsoincreases because more bidders participate on task computation.Moreover, increasing the G1 bidder size decreases the taskcompletion time further since this increases chances to visitthe POI. However, cost of the operation decreases becauseaccording to our cost model, we pay more if the task takeslonger time to reach in the POI. But for large number of G1bidders, the task reaches more quickly to the POI.

VIII. DISCUSSION

One limitation of D-CLOC is that its energy consumptionfor forwarding a task is much higher than the other DTNmodels. In D-CLOC, the sending bidder does not have anyknowledge of the context of the receiving bidder. Therefore,forwarding the task to a bidder that does not have any planto visit the POI will not help in faster delivery of the task. Itwill just consume some energy unnecessarily. Instead, if wecan design a protocol where two bidders can exchange theircontext or some parts of the context, then we can make ourprocess more efficient. In that case, only the appropriate biddersafter context analysis will be selected for task forwarding. Asa consequence, the energy consumption will be smaller thancurrent approach. However, exchanging the context between

8

Transfer

 Time

 (ms)  

0  

2000  

4000  

6000  

8000  

10000  

12000  

14000  

16000  

Epidemic   Spray  &  Wait  

Prophet   D-­‐CLOC  

(a) Average message transfer time

0  5  

10  15  20  25  30  35  40  45  50  

Epidemic   Spray  &  Wait  

Prophet   D-­‐CLOC  

Total

 Messag

e  Delivered

 

(b) Total delivered message

Power  C

onsum

p-on  (W

a1)  

0  

10  

20  

30  

40  

50  

60  

Epidemic   Spray  &  Wait  

Prophet   D-­‐CLOC  

(c) Average power consumption for delivering each message

Fig. 5: Performance comparison of D-CLOC and the other three major DTN routing protocol

0  

5000  

10000  

15000  

20000  

25000  

5   10   15   20   25   30   35   40   45   50  

For  G1  bidder  size  of  10  For  G1  bidder  size  of  20  

Time  (secon

d)  

Size  of  G2  bidder  

(a) Task completion time

0  100  200  300  400  500  600  700  800  

5   10   15   20   25   30   35   40   45   50  

For  G1  bidder  size  of  10  For  G1  bidder  size  of  20  

Cost  (cen

t)  

Size  of  G2  bidder  

(b) Cost of task completion

Fig. 6: Performance of D-CLOC for an image recognition task

two bidders is a challenging task since we have to ensure thatany malicious bidder cannot misuse the collected contextualinformation and obstructs users privacy or security. Therefore,we need to specify precisely regarding the information that twobidders can exchange along with some security guidelines toprotect from misusing those information by malicious bidders.

IX. CONCLUSION AND FUTURE WORK

Despite the ubiquity of network connectivity, many locationsaround the world are still out of network due to small populardensity, topographical impediments, and large geographicaldistances. To the best of our knowledge, D-CLOC is the firstattempt that combines both the cellular network and the DTNto form a delay tolerant cloud using the contextual informationof the participants. Moreover, our proposed feature providesincentives based on bidders’ reputation to motivate more usersto participate and sincerely compute a task. Our experimentalresult shows that D-CLOC takes much smaller task transferringtime than some of the existing DTN models. Therefore, wecan conclude that the real life deployment of D-CLOC can bea sound business decision for provider in addition to providingbenefit to both the clients and the bidders. Currently, we areworking on a small scale real life implementation of D-CLOCin order to determine the feasibility and complexity of designingsuch systems.Acknowledgements. This research was supported by theNational Science Foundation CAREER Award CNS-1351038.

REFERENCES[1] B. Walker, T. Clancy, and J. Glenn, “Using localized random walks to model delay-

tolerant networks,” in MILCOM, 2008.[2] H. Ntareme, M. Zennaro, and B. Pehrson, “Delay tolerant network on smartphones:

Applications for communication challenged areas,” in ExtremeCom, 2011.[3] L. Wei, Z. Cao, and H. Zhu, “Mobigame: A user-centric reputation based incentive

protocol for delay/disruption tolerant networks,” in GLOBECOM, 2011.[4] G. Dini and A. L. Duca, “Towards a reputation-based routing protocol to contrast

blackholes in a delay tolerant network,” Ad Hoc Networks, vol. 33, 2012.[5] N. Li and S. K. Das, “A trust-based framework for data forwarding in opportunistic

networks,” Ad Hoc Networks, 2013.[6] A. Lindgren, A. Doria, and O. Schelen, “Probabilistic routing in intermittently

connected networks,” SIGMOBILE Mob. Comput. Commun. Rev., vol. 7, 2003.[7] X. Zhang, G. Neglia, J. Kurose, and D. Towsley, “Performance modeling of

epidemic routing,” Comput. Networks, vol. 51, 2007.[8] J. Burgess, B. Gallagher, D. Jensen, and B. Levine, “Maxprop: Routing for vehicle-

based disruption-tolerant networks,” in INFOCOM, 2006.

[9] J. Leguay, T. Friedman, and V. Conan, “Evaluating mobility pattern space routingfor dtns,” in INFOCOM, 2006.

[10] C. Boldrini, M. Conti, J. Jacopini, and A. Passarella, “Hibop: a history basedrouting protocol for opportunistic networks,” in WoWMoM, 2007.

[11] H. A. Nguyen and S. Giordano, “Context information prediction for social-basedrouting in opportunistic networks,” Ad Hoc Networks, vol. 10, 2012.

[12] C. E. Palazzi and A. Bujari, “Social-aware delay tolerant networking for mobile-to-mobile file sharing,” IJCS, vol. 25, 2012.

[13] M. M. Hassan, B. Song, and E.-N. Huh, “A framework of sensor-cloud integrationopportunities and challenges,” in ICUIMC, 2009.

[14] S. Dash, J. Sahoo, S. Mohapatra, and S. Pati, “Sensor-cloud: Assimilation ofwireless sensor network and the cloud,” in Advances in Computer Science andInformation Technology. Networks and Communications, 2012, vol. 84.

[15] E. Miluzzo, R. Caceres, and Y.-F. Chen, “Vision: mclouds - computing on cloudsof mobile devices,” in Mobile cloud computing and services, 2012.

[16] L. Lacuesta and P. Sendra, “Spontaneous ad hoc mobile cloud computing network,”The Scientific World Journal, 2014.

[17] Amazon Mechanical Turk, https://www.mturk.com/.[18] D. Wightman, “Crowdsourcing human-based computation,” in NordiCHI, 2010.[19] H. Zhang, E. Horvitz, R. C. Miller, and D. C. Parkes, “Crowdsourcing general

computation.” ACM CHI 2011 Workshop on Crowdsourcing and HumanComputation, January 2011.

[20] J. Oomen and L. Aroyo, “Crowdsourcing in the cultural heritage domain: Oppor-tunities and challenges,” in C&T, 2011.

[21] L. Liu, “A survey on barter-based incentive mechanism in opportunistic networks,”in IMSNA, Dec 2013.

[22] H. Zhu, X. Lin, R. Lu, Y. Fan, and X. Shen, “Smart: A secure multilayer credit-based incentive scheme for delay-tolerant networks,” TVT, vol. 58, 2009.

[23] B. Chen and M. C. Chan, “Mobicent: a credit-based incentive system for disruptiontolerant network,” in IEEE INFOCOM, 2010.

[24] S. Jain, K. Fall, and R. Patra, “Routing in a delay tolerant network,” in SIGCOMM,2004.

[25] A. Alamri, W. S. Ansari, M. M. Hassan, M. S. Hossain, A. Alelaiwi, and M. A.Hossain, “A survey on sensor-cloud: Architecture, applications, and approaches,”International Journal of Distributed Sensor Networks, 2013.

[26] G. Fortino, M. Pathan, and G. Di Fatta, “Bodycloud: Integration of cloud computingand body sensor networks,” in CloudCom, 2012.

[27] C. Doukas and I. Maglogiannis, “Bringing iot and cloud computing towardspervasive healthcare,” in IMIS, 2012.

[28] S. Chatterjee and S. Misra, “Target tracking using sensor-cloud: Sensor-targetmapping in presence of overlapping coverage,” IEEE Communications Letters,2014.

[29] N. Zingirian and C. Valenti, “Sensor clouds for intelligent truck monitoring,” inIEEE Intelligent Vehicles Symposium (IV), 2012.

[30] D. B. Lenat, “Cyc: A large-scale investment in knowledge infrastructure,” Commu-nications of the ACM, vol. 58, 1995.

[31] H. Lieberman and et al., “Common consensus: a web-based game for collectingcommonsense goals,” in IUI, 2007.

[32] P. G. Ipeirotis, F. Provost, and J. Wang, “Quality management on amazon mechan-ical turk,” in HCOMP, 2010.

[33] L. Von Ahn, “Human computation,” Ph.D. dissertation, Carnegie Mellon University,2005.

[34] P. Edmunds, “Swarmsketch,” http://www.swarmsketch.com/.[35] A. Kosorukoff, “Human based genetic algorithm,” in International Conference on

Systems, Man, and Cybernetics, 2001.[36] C. Hu, B. B. Bederson, and P. Resnik, “Translation by iterative collaboration

between monolingual users,” in HCOMP, 2010.[37] S. Noor, M. Haque, and R. Hasan, “Cellcloud: A novel cost effective formation of

mobile cloud based on bidding incentives,” in IEEE Cloud, 2014.[38] R. Hasan, M. M. Hossain, and R. Khan, “Aura: An iot based cloud infrastructure

for localized mobile computation outsourcing,” in IEEE Cloud, 2015.[39] H. Becker, D. Iter, M. Naaman, and L. Gravano, “Identifying content for planned

events across social media sites,” 2012.[40] “The opportunistic network environment simulator,” http://www.netlab.tkk.fi/

tutkimus/dtn/theone/.[41] Z. Feng and K.-W. Chin, “A unified study of epidemic routing protocols and their

enhancements,” in IPDPSW, 2012.[42] N. Kishore, S. Jain, and V. Soares, “An empirical review on the spray and wait

based algorithms for controlled replication forwarding in delay tolerant networks,”in WOCN, 2013.

[43] S. Grasic, E. Davies, A. Lindgren, and A. Doria, “The evolution of a dtn routingprotocol - prophetv2,” in ACM Workshop on Challenged Networks, 2011.