ieee transactions on mobile computing, vol. …bbcr.uwaterloo.ca/~xshen/paper/2012/ffeasc.pdf ·...

FESCIM: Fair, Efficient, and SecureCooperation Incentive Mechanism

for Multihop Cellular NetworksMohamed M.E.A. Mahmoud, Member, IEEE, and Xuemin (Sherman) Shen, Fellow, IEEE

Abstract—In multihop cellular networks, the mobile nodes usually relay others’ packets for enhancing the network performance and

deployment. However, selfish nodes usually do not cooperate but make use of the cooperative nodes to relay their packets, which has

a negative effect on the network fairness and performance. In this paper, we propose a fair and efficient incentive mechanism to

stimulate the node cooperation. Our mechanism applies a fair charging policy by charging the source and destination nodes when both

of them benefit from the communication. To implement this charging policy efficiently, hashing operations are used in the ACK packets

to reduce the number of public-key-cryptography operations. Moreover, reducing the overhead of the payment checks is essential for

the efficient implementation of the incentive mechanism due to the large number of payment transactions. Instead of generating a

check per message, a small-size check can be generated per route, and a check submission scheme is proposed to reduce the

number of submitted checks and protect against collusion attacks. Extensive analysis and simulations demonstrate that our

mechanism can secure the payment and significantly reduce the checks’ overhead, and the fair charging policy can be implemented

almost computationally free by using hashing operations.

Index Terms—Network-level security and protection, wireless communication, payment schemes, hybrid systems.

Ç

1 INTRODUCTION

MULTIHOP cellular network (MCN) [1], [2], [3], [4] is anetwork architecture that incorporates the ad hoc

characteristics into the cellular system. A node’s traffic isusually relayed through other nodes to the destination. Thenetwork nodes commit bandwidth, data storage, CPU cycles,battery power, etc., forming a pool of resources that can beshared by all of them. The utility that the nodes can obtainfrom the pooled resources is much higher than that they canobtain on their own. The considered MCN is used for civilianapplications where the network has long life and the mobilenodes are supposed to have long-term relations with thenetwork. Multihop packet relay can reduce the dead areasby extending the communication range of the base stationswithout additional costs. It can also reduce the energyconsumption because packets are transmitted over shorterdistances, and improve the area spectral efficiency and thenetwork throughput and capacity [5], [6], [7]. However, dueto involving autonomous devices in packet relay, the packetrouting process suffers from new security challenges thatendanger the practical implementation of MCN.

The assumption that the network nodes are willing torelay other nodes’ packets may not hold for civilianapplications where the nodes are autonomous and self-interested in the sense that they aim to maximize their welfareand minimize their contributions. Although the proper

network operation requires the nodes to collaborate, colla-boration consumes the nodes’ resources such as energy andcomputing power, and does not provide direct benefits.Selfish nodes are not interested in cooperation withoutincentive and make use of the cooperative nodes to relaytheir packets, which has a negative effect on the networkfairness and performance. A fairness issue arises when selfishnodes take advantage of the cooperative nodes without anycontribution to them. The selfish behavior also significantlydegrades the network performance, which may result infailure of the multihop communications [8], [9].

Reputation-based and incentive mechanisms [10], [11]have been proposed to thwart selfishness attacks. Forreputation-based mechanisms [12], [13], [14], the nodesusually monitor the transmissions of their neighbors tomake sure that the neighbors relay other nodes’ traffic, andthus, selfish nodes can be identified and punished. Forincentive mechanisms, packet relay is a service not anobligation. The source and destination nodes pay credits (orvirtual currency) to the intermediate nodes for relayingtheir packets. Credits can stimulate the nodes’ cooperationby proving that it is more beneficial for the nodes tocooperate than behaving selfishly.

Reputation-based mechanisms suffer from essentialproblems that discourage implementing them in MCN.First, monitoring the nodes’ transmissions by overhearingthe channel is not energy efficient for transmitters. The full-power transmission is used instead of adapting thetransmission power according to the distance separatingthe transmitter and the receiver [15] to enable moreneighboring nodes to hear the packet transmission. Second,reputation-based mechanisms do not achieve fairnessbecause the highly contributing nodes are not compensated.For example, although the nodes at the network center relay

IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 5, MAY 2012 753

. The authors are with the Department of Electrical and ComputerEngineering, University of Waterloo, Waterloo, ON N2L 3G1, Canada.E-mail: {mmabdels, xshen}@bbcr.uwaterloo.ca.

Manuscript received 23 May 2010; revised 20 Feb. 2011; accepted 12 Mar.2011; published online 28 Apr. 2011.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TMC-2010-05-0247.Digital Object Identifier no. 10.1109/TMC.2011.92.

1536-1233/12/$31.00 � 2012 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS

more packets than those at the periphery, they are notcompensated. Third, the mechanisms suffer from unreliabledetection of the selfish nodes and false accusation of thehonest nodes. That is because it is difficult to differentiatebetween a node’s unwillingness and incapability to co-operate, e.g., due to low resources, packet collision, andnetwork congestion.

In addition to cooperation stimulation, the incentivemechanisms can achieve fairness by charging or rewardingcredits to balance a node’s contribution and its benefit. Thenode’s contribution can be relaying other nodes’ packets orpaying credits, whereas the node’s benefit can be relayingits packets or earning credits. In other words, credits areused to compensate the nodes for relaying other nodes’packets to enforce fairness. Moreover, incentive mechanismscan discourage launching Resource-Exhaustion attack bysending bogus messages to exhaust the intermediate nodes’resources because the nodes pay for relaying their packets.Incentive mechanisms can also efficiently bill the networkusers when they roam among different foreign networks bypaying all the parties involved in the communicationwithout contacting distant home location registers [16].

However, the efficient implementation of the existingincentive mechanisms is questionable because they imposesignificant overhead. First, the fair charging policy is tocharge both the source and destination nodes when both ofthem benefit from the communication. To securely imple-ment this charging policy, two signatures are usuallyrequired per message (one from the source node and theother from the destination node) to prevent paymentrepudiation and manipulation. Nevertheless, the extensiveuse of the public key cryptography is very costly, whichdegrades the network performance and stimulates thenodes to behave selfishly. Second, since a trusted partymay not be involved in the communication sessions, thenodes usually compose undeniable proof of packet relayingcalled check, and submit the checks to a central unit calledthe accounting center (AC) for clearance. However, sub-mitting and processing a large number of checks impliessignificant communication and computation overhead andimplementation complexity.

In this paper, we propose FESCIM, a Fair, Efficient, andSecure Cooperation Incentive Mechanism, to stimulate thenode cooperation in MCN. In order to efficiently andsecurely charge the source and destination nodes, thelightweight hashing operations are used in the ACK packetsto reduce the number of public-key-cryptography opera-tions. The destination node generates a hash chain andsigns its root, and acknowledges message reception byreleasing a hash value from the hash chain. In this way, thedestination node generates a signature per group ofmessages instead of generating a signature per message.

Furthermore, instead of generating a check per messageor generating a nodal check for each intermediate node, asmall-size check containing the payment data for all theintermediate nodes is generated per route. In addition,trusting one node to submit the check is not secure becausethis node may collude with the source and destinationnodes to not submit the check, as we will discuss inSection 4.2. Instead of submitting the checks by all theintermediate nodes to thwart collusion attack, a Probabil-istic-Check-Submission scheme is proposed to reduce the

number of submitted checks and protect against collusionattack. In Section 5, we will show that if each intermediatenode submits a low ratio of randomly chosen checks, mostof the checks can be probabilistically submitted undercollusion attack. Extensive analysis and simulations de-monstrate that FESCIM can secure the payment, charge thesource and destination nodes almost computationally free,and significantly reduce the number of generated andsubmitted checks.

The remainder of this paper is organized as follows:Section 2 reviews the related work and Section 3 presentsthe system models. The proposed cooperation incentivemechanism is presented in Section 4. Security analysis andperformance evaluation are provided in Sections 5 and 6,respectively, followed by conclusion and future work inSection 7.

2 RELATED WORK

In tamper-proof device (TPD)-based incentive mechanisms[17], [18], [19], [20], [21], a TPD is installed in each node tomanage its credit account and secure its operation. InNuglets [17], [18], the self-generated and forwardingpackets are passed to the TPD to decrease and increasethe node’s credit account, respectively. The packet purseand the packet trade models have been proposed. In thepacket purse model, only the source node pays by loadingsome credits in each packet before sending it. Eachintermediate node acquires the amount of credits that coverthe packet’s relaying cost. In the packet trade model, eachintermediate node runs an auction to sell the packets to thefollowing node in the route. In this way, each intermediatenode earns some credits and the destination node paysthe total packet relaying cost. In SIP [19], after receiving adata packet, the destination node sends a paymentRECEIPT packet to the source node to issue a REWARDpacket to increment the credit accounts of the intermediatenodes. In CASHnet [20], [21], the source node’s traffic creditaccount is charged and a signature is attached for each datapacket. Upon receiving the packet, the destination node’straffic credit account is also charged and a digitally signedACK packet is sent back to increase the helper creditaccounts of the intermediate nodes. Users regularly visitservice points to buy traffic credits with real money and/ortransfer helper credits to traffic credits.

The TPD-based incentive mechanisms suffer from thefollowing problems. First, the assumption that the TPDcannot be tampered is neither secure nor practical forMCNs. That is because the nodes are autonomous and self-interested and the attackers can communicate freely in anundetectable way if they could compromise the TPDs [22].Moreover, since the security protection of these mechan-isms completely fails if the TPDs are tampered, only a smallnumber of manufacturers can be trusted to make thenetwork nodes, which is too restrictive for civilian net-works. Second, a node cannot communicate if it does nothave sufficient credits at the communication time. Thenodes at the network edge cannot earn as many credits asthe nodes at other locations because they are less frequentlyselected by the routing protocol. Furthermore, the creditdistribution has direct impact on the network performance,e.g., if a small number of nodes have a large ratio of thenetwork credits, the network performance significantly

754 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 5, MAY 2012

degrades because the rich nodes are not motivated tocooperate and the poor nodes cannot initiate communica-tions. Finally, since credits are cleared in real time, thenetwork performance degrades if the network does nothave enough credits circulating around. In [23], it is shownthat the overall credits in the network decline graduallybecause the total charges are not necessarily equal to thetotal rewards. That is because the source node is fullycharged after sending a packet but some intermediate nodesmay not be rewarded when the route is broken. AlthoughCASHnet can alleviate this problem by buying credits withreal money, it is shown in [23] that in spite of having helpercredits, some nodes starve because they cannot find aservice point to convert them to traffic credits.

In order to eliminate the need for TPDs, a central bankcalled the AC can be used to store and manage the nodes’accounts. In [24], the source node appends a payment tokento each transmitted packet, and each intermediate nodeuses its secret key to check whether the token correspondsto a winning ticket. Winning tickets are submitted to the ACto reward the winning nodes. The source and destinationnodes are charged per packet but the intermediate nodesare rewarded per winning ticket. In a security flaw, thecolluding nodes can exchange tokens to be checked in eachnode to steal credits. In our earlier work [25], instead ofsubmitting payment checks to the AC, each node submitsan activity report containing its alleged charges andrewards of different sessions. The AC uses a reputationsystem to identify the cheating nodes that report falsecharges and/or rewards to steal credits. However, due tothe nature of the reputation systems, some honest nodesmay be falsely identified as cheaters and the colludingnodes may manage to steal credits.

In [26], each node in a route buys packets from theprevious node and sells them to the next node. The packets’buyers contact the AC to get deposited coins and thepackets’ sellers submit the coins to the AC to claim theirpayment. However, the interactive involvement of the ACin each communication session is not efficient and creates abottleneck at the AC. In [27], an incentive mechanism hasbeen proposed for MCN. Unlike the original MCNarchitecture proposed in [1], the base stations are involvedin every communication session, which may lead tosuboptimal routes when the source and destination nodesreside in the same cell. In addition, the corrupted messagesare relayed to the base station before they are droppedbecause the intermediate nodes cannot verify the authen-ticity and the integrity of the messages.

In Sprite [28], the source node signs the identities of thenodes in the route and appends its signature to eachtransmitted message. The intermediate and the destinationnodes compose checks and submit them to the AC to claimthe payment. In Express [29], the source node generates ahash chain for each intermediate node IDK and commits tothe hash chain by digitally signing the root of the hash chainand sending the signature to IDK. Each time the node IDK

relays a message, the source node releases the preimage ofthe last sent hash value. The source, intermediate, anddestination nodes compose checks and submit them to theAC. However, the nodes have to generate and store a largenumber of hash chains because any node in the networkmay act as an intermediate node due to the node mobility.The packet overhead is large especially if the number of

intermediate nodes is large because the source nodeattaches one hash value for each intermediate node. InSprite and Express, only the source node pays no matterhow the destination node benefits from the communication.Moreover, since the intermediate nodes are rewarded forthe relayed messages that do not reach the destination, allthe nodes in a route submit the checks because packet relayis considered successful by a node if a next node in theroute submits a valid check. We call this check submissionscheme All-Submitters because all the intermediate nodessubmit all the checks. In Sprite and Express, significantcommunication and computation overhead is implied dueto generating and submitting a large number of checksbecause a check is generated per message and all the nodesin a route submit all the checks.

In [30], an incentive mechanism has been proposed forad hoc networks that are used to connect the nodes to theInternet. The source node signs the identities of the nodes inthe route and appends this signature to the message, andthe destination node signs a check and sends it to the lastintermediate node to submit to the AC. Since only the lastintermediate node submits the check, we call this checksubmission scheme Fixed-Submitter. However, the sourceand destination nodes can communicate freely and theintermediate nodes are not rewarded if the last intermediatenode colludes with the source and destination nodes to notsubmit the checks. Moreover, generating two signatures permessage is too costly for mobile nodes. In [31], a hash chainis used to efficiently authenticate digital streams butFESCIM uses a hash chain to achieve payment nonrepudia-tion to secure the payment.

3 SYSTEM MODELS

3.1 Network and Communication Models

As shown in Fig. 1, the considered MCN includes anaccounting center, a set of base stations, and mobile nodes.The AC stores and manages the credit accounts of thenodes, and generates private/public key pair and certificatewith unique identity for each node. Once the AC receives acheck, it updates the accounts of the participating nodes.The base stations are connected with each other and withthe AC by a backbone network that may be wired or

MAHMOUD AND SHEN: FESCIM: FAIR, EFFICIENT, AND SECURE COOPERATION INCENTIVE MECHANISM FOR MULTIHOP CELLULAR... 755

Fig. 1. The architecture of the multihop cellular network.

wireless. FESCIM can be implemented on the top of anyrouting protocol, such as DSR [32] and AODV [33], toestablish an end-to-end communication session providedthat the full identities of the nodes in the route are known tothe source and destination nodes. It is important to includethese identities in the source and the destination node’ssignatures to compose valid checks.

All communications are unicast and the nodes cancommunicate in one of two modes: pure ad hoc or hybrid.For pure ad hoc mode, the source and destination nodescommunicate without involving base stations. The sourcenode’s messages may be relayed in several hops by theintermediate nodes to the destination node. For hybridmode, at least one base station is involved in thecommunication. The source node transmits its messagesto the source base station (BSS), if necessary in multiplehops. If the destination node resides in a different cell, themessages are forwarded to the destination base station(BSD) that transmits the messages to the destination nodepossibly in multiple hops. The nodes can contact the AC atleast once every few days. This connection can occur via thebase stations or the wired networks such as the Internet.During this connection, the nodes submit checks, renewtheir certificates, and convert credits to real money and/orpurchase credits with real money.

3.2 Threat and Trust Models

Since the mobile nodes are autonomous and self-interested,the attacker has full control on his node, and thus he canchange its operation. The attackers work individually orcollude with each other under the control of one authorityto launch sophisticated attacks. The attackers are rational inthe sense that they misbehave when they can achieve morebenefits than behaving honestly. Specifically, the attackersattempt to steal credits, pay less, and communicate freely.The mobile nodes are probable attackers because they aremotivated to misbehave to increase their welfare, but theAC is fully secure. It is impossible to realize secure paymentbetween two entities without trusted third party [34]. Forthe trust models, the network nodes fully trust the AC tocorrectly perform billing and auditing, but the AC does nottrust any node or base station in the network. The networknodes also trust their operators’ base stations but do nottrust those of other operators.

3.3 Payment Model

A fair charging policy is to support cost sharing betweenthe source and destination nodes when both of them benefitfrom the communication. In order to make FESCIM flexible,the payment-splitting ratio is adjustable and servicedependent, e.g., a DNS server should not pay for nameresolution. For rewarding policy, some incentive mechan-isms, such as [35], consider that a packet relaying reward isproportional to the incurred energy in relaying the packet. Itis difficult to implement this rewarding policy in practicewithout involving complicated route discovery process andcalculation of enroute individual payments. Therefore,similar to [19], [25], [28], [29], we use fixed rewarding rate,e.g., � credits per unit-sized packet.

In MCNs, packet loss may occur normally due to nodemobility, channel impairment, etc. Ideally, any node thathas ever tried to relay a packet should be rewarded nomatter whether the packet eventually reaches its destination

or not because relaying a packet consumes the node’sresources. However, it is difficult to corroborate anintermediate forwarding action without involving too muchoverhead, e.g., all the intermediate nodes have to submit allthe checks in [28], [29]. Moreover, rewarding the nodes forrelaying route establishment packets or packet retransmis-sions significantly increases the number of checks because alarge number of nodes may relay route establishmentpackets and packet retransmission frequently happens inwireless networks. Therefore, the AC charges the sourceand destination nodes for every transmitted message even ifthe message does not reach the destination, but the ACrewards the intermediate nodes only for the deliveredmessages. For fair rewarding policy, the value of � isdetermined to compensate the nodes for relaying route-establishment packets, packet retransmission, and undeliv-ered packets. In Section 5, we will argue that our chargingand rewarding policies can thwart rational attacks andencourage the nodes’ cooperation. Similar to the VISAsystem and the incentive mechanisms in [25], [28], [29], [30],the nodes communicate first and pay later. The AC issuescertificates to enable the nodes to transact by issuing digitalchecks without the need for direct verification from the ACto avoid frequently contacting the AC and thus creating abottleneck at the AC.

The nodes at the network border cannot earn as manycredits as those at other locations because they are lessfrequently selected by the routing protocol. In order tocommunicate, they can purchase credits with real money.However, we do not consider this as a fairness problembecause the philosophy behind incentive mechanisms isthat packet relay is a service not an obligation. This servicemay not be requested from some nodes, i.e., the customers(source and destination nodes) request the packet-relayservice from the best service providers (shortest routenodes). If the traffic is directed through the border nodes,obviously, we sacrifice the network performance becausethe routes may be long. Due to the node mobility, theborder nodes can change their location and earn morecredits as shown in [19]. Moreover, the border nodes donot relay as many packets as others, and thus, it is fair tocharge the border nodes real money to compensate theother nodes that relayed more packets. Table 1 gives theused notations in this paper.

4 THE PROPOSED FESCIM

In this section, we first present FESCIM for hybrid modeand then for pure ad hoc mode.

4.1 Hybrid Mode

4.1.1 Route Discovery Phase

In order to establish an end-to-end route, the source nodebroadcasts the Route Request Packet (RREQ) containing theidentities of the source (IDS) and the destination (IDD)nodes, the route establishment time stamp (TS), and thepayment-splitting ratio (Pr). The source node is charged theratio of Pr of the total payment and the destination node ischarged the ratio of 1�Pr. A network node appends itsidentity and broadcasts the packet if the time stamp iswithin a proper range. The RREQ packet is relayed by BSS

to BSD (if the destination node resides in a different base


station) that broadcasts it. Finally, the destination nodesends back the Route Reply Packet (RREP) to establish theroute. The source node initiates a new route discoveryphase if the route is broken.

As shown in Fig. 2, the destination node generates ahash chain with size of Zþ 1 by iteratively hashing arandom value called seed (HD

0ðiÞ) Z times to obtain a finalhash value called root (HZ

DðiÞ), where HXDðiÞ ¼ HðHX�1

D ðiÞÞand i is the hash-chain number. Note that multiple hashchains may be used in one route. From Fig. 3, the RREPpacket contains the session identifier (Si), the destinationnode’s certificate, the root of the first hash chain (HZ

Dð1Þ),and the destination node’s signature (SigDðSi;H

ZDð1ÞÞ). Si

contains the identities of the nodes in the route, TS, and Pr,e.g., Si ¼ IDS , ID1, ID2, BSS, ID3, ID4, IDD, TS, Pr for the routeshown in Fig. 3. The destination node’s signature authenti-cates the node and proves its approval to pay for thesession. The signature also proves that the hash chain hasindeed been created by the destination node and links it tothe route. Upon receiving the RREP packet, each inter-mediate node relays the packet if the signature is correctlyverified, and the source node starts data transmission.

4.1.2 Data Generation and Relay Phase

For the Xth data packet, Fig. 3 shows that the source nodeappends the message MX and its signature (SigSðSi;X;HðMXÞÞ). Signing the hash of the message instead of the

message can significantly reduce the check size becausethe smaller size HðMXÞ and not MX is attached to the check.The source node attaches its certificate to the first datapacket to enable the intermediate and destination nodes toverify its signatures. Before relaying a data packet, eachintermediate node verifies the attached signature to ensurethe message’s integrity and authenticity and to verify thepayment data that include Si and X. The intermediate nodesstore only the last source node’s signature to be used in thecheck composition, i.e., after receiving the Xth data packet,the intermediate nodes delete SigSðSi;X� 1;HðMX�1ÞÞ andstore SigSðSi;X;HðMXÞÞ that is enough to prove that Xmessages have been transmitted and X� 1 messages havebeen delivered. Each node in the route restarts a timer eachtime the node transmits or relays a packet. The route isconsidered broken when the timer expires. After receivingthe ACK of the last message, the source node sends End ofSession (EoS) packet to close the session.

4.1.3 ACK Generation and Relay Phase

Upon receiving the Xth data packet and X � Z, thedestination node sends back ACK packet containing thepreimage of the last released hash value, or HZ�X

D ð1Þ, toacknowledge receiving the message in an undeniable way.Therefore, instead of generating a signature per ACKpacket, one signature is generated per Z ACKs. Paymentnonrepudiation and nonmanipulation are achievable be-cause the hash function is one-way, i.e., only the destinationnode could have generated the hash chain because it is notpossible to compute HZ�X�1

D ð1Þ from HZ�XD ð1Þ. Each inter-

mediate node verifies the hash value by making sure thatHZ�X

D ð1Þ is generated from hashing HZ�X�1D ð1Þ. As illustrated

in Fig. 3, after releasing all the hash values of the first hashchain, the destination node creates a new hash chain andauthenticates it by signing all the used hash chains’ roots, orSigDðSi;H

ZDð1Þ;HZ

Dð2ÞÞ, instead of signing only the last hashchain’s root. In this way, the intermediate nodes store only


TABLE 1The Useful Notations

Fig. 2. Hash chain generated by the destination node.

Fig. 3. The exchanged security tags in a session.

the last destination node’s signature for the check composi-tion because it can authenticate all the used hash chains inthe route. The intermediate nodes also store the hashchains’ roots and seeds and the last released hash value forthe check composition.

4.1.4 Check Composition Phase

For each route, one check containing the payment data forall the intermediate nodes can be composed. The generalformat of the route check is shown in Fig. 4a, where “[Y]”means that Y may not exist in some cases. A check containstwo main parts: Descriptor (D) and Security Token (St). TheDescriptor contains Si that has the identities of the payersand the payees, TS, and Pr. The Descriptor also contains themessages’ number (X), the hash value of the last receivedmessage, the hash chains’ roots and seeds, and the lastreleased hash value (½HZ�L

D ðvÞ�). The Security Token is anundeniable proof that prevents payment repudiation andmanipulation, and thus ensures that the check is undeni-able, unmodifiable, and unforgeable. In order to signifi-cantly reduce the check size, the Security Token is composedby hashing the source and destination nodes’ signaturesinstead of attaching the large-size signatures. The check sizedepends on the number of used hash chains because twohash values should be attached for each hash chain, andthus properly choosing the hash chain size can minimizethe check size.

Fig. 4b shows the composed check when the route isbroken during relaying the Xth data packet and 1 � X � Z,i.e., only one hash chain is used. If the route is broken afterreceiving the first data packet (X ¼ 1), the check does nothave HZ�Xþ1

D ð1Þ because the ACK packet is not received.However, for 1 < X � Z, the last hash value received fromthe destination node (HZ�Xþ1

D ð1Þ) is attached to the check.Fig. 4c shows the composed check when the route is brokenafter receiving the Xth data packet and Z < X � 2 � Z, i.e.,two hash chains are used. It can be seen that the checkcontains the seed and the root of the first hash chain, the

root of the second hash chain, and the last released hashvalue (HZ�L�1

D ð2Þ), where X ¼ Zþ Lþ 1. Moreover, the twohash chains’ roots are included in the destination node’ssignature. Fig. 4d shows the composed check when the lastreceived packet is the ACK of the Xth message.

4.1.5 Check Clearance Phase

The base station submits the check to the AC forredemption, but the nodes submit the check if the basestation belongs to a different operator. The nodes alsosubmit the check if the route is not complete, i.e., the EOSpacket is not received, and the base station does not havecorrect payment information. For example, if the route isbroken during relaying the ACK of MX from IDD to BSD, theBSD’s check does not prove that the Xth message isdelivered, and thus, the nodes are not rewarded for thelast message if they do not submit the check. Once the ACreceives a check, it checks that the check has not beendeposited before using its unique identifier (Si). Then, theAC generates the source and destination nodes’ signaturesand hashes them to verify the check’s credibility. The checkis valid if the resultant hash value is identical to the check’sSecurity Token. For a check (SC(X)), the number oftransmitted messages (X) is signed by the source node,and the number of delivered messages can be computedfrom the number of hashing operations to map HZ�X

D ð1Þ toHZ

Dð1Þ. Finally, the AC clears the check according to thecharging and rewarding policy discussed in Section 3.3.

4.2 Pure Ad Hoc Mode

The proposed mechanism for hybrid mode can be used forpure ad hoc mode, but the intermediate nodes have tosubmit the checks to the AC because the base stations arenot involved in the communication. A check containspayment data for all the nodes in the route, but it is notsecure to trust one node to submit the check because itmay collude with the source and destination nodes so asnot to submit the check to increase their welfare. Fig. 5shows the charges and rewards for sending X messages ina route with n intermediate nodes. If the source anddestination nodes collude with K intermediate nodes andthe check is not submitted, the colluders can save X � � �ðn�KÞ credits. Obviously, the colluders can achieve gainswhen K < n, and thus, the source and destination nodescan compensate the colluding intermediate nodes. On theother hand, it is not efficient to submit a check by eachintermediate node [28], [29] due to significantly increasingthe number of redundant checks. In this section, wepropose two schemes for efficiently thwarting the collusionattacks against check submission.

4.2.1 Changeable-Submitter Check Submission

Scheme

Similar to [30], one node submits the check, but the positionof the check submitter is randomly changed instead offixed. All the intermediate nodes execute a public function


Fig. 4. The formats of the payment checks.

Fig. 5. The charges and rewards for X messages.

called Selector to decide the check submitter. The Selector’sinput is the session identifier and the return value is theposition of the check submitter, e.g., if the return value is 1,the first intermediate node after the source node is the checksubmitter and so on. Obviously, changing the function’sinput can change the position of the check submitter, whichincreases the difficulty of the collusion attack. The Selectorcan be implemented using a hash function with deriving thereturn value from the output hash value such that allpossible cases are equally likely, i.e., all the intermediatenodes have the same probability to be the check submitter.

4.2.2 Probabilistic-Check-Submission Scheme

Instead of submitting all the checks by each intermediatenode [28], [29], each node submits the ratio of RC ofrandomly chosen checks such that a minimum ratio of theunrepeated checks will be submitted probabilistically.Equations (1) and (2) give the probability that at least qunrepeated checks out of � are submitted for routes with nintermediate nodes and C colluding nodes, where Q denotesan integer random variable ð0 � Q � �Þ that represents thenumber of unrepeated checks that are submitted:

PðQ � qÞ ¼X�

j¼q

PðQ ¼ jÞ ð1Þ

PðQ ¼ jÞ ¼ �

j

� �� ð1� ð1�RcÞn�CÞj � ðð1� RcÞn�CÞ��j: ð2Þ

Fig. 6 shows the relation between PðQ � qÞ and RC atdifferent values of q and n assuming that � is 1,000 checksand all the nodes do not collude (C ¼ 0). It can be seen thatmost of the checks can be submitted with a very high probabilitywhen RC is much less than 1. For example, when n equals to6, the probabilities of submitting at least 80 percent and90 percent of the checks are 1 if each node submits only27 percent and 34 percent of the checks, respectively.However, when n equals to 3, RC should be 0.44 and 0.57to submit at least 80 percent and 90 percent of the checkswith the probability of 1, respectively, i.e., RC should belarger for shorter routes to guarantee submitting the sameratio of the checks. RC should be determined to achieve aspecific probability of submitting a minimum ratio of thechecks. In this paper, we assume that RC is chosen to make

PðQ � qÞ ¼ 0:9. The minimum RC that achieves thisprobability is denoted by RC

�, e.g., from Fig. 6, RC� is

0.56 and 0.33 when n equals 3 and 6, respectively. Therationale here is that a little increase in RC significantlyincreases the number of redundant checks in the long run,but the increase of RC above RC

� has little effect on thecheck submission probability. From Fig. 6, when n equals 3,the increase of RC from 0.52 to 0.55 and from 0.55 to 0.58changes PðQ � 0:9 � �Þ with 0.75 and 0.15, respectively.

Fig. 7 shows the effect of � on the probability of clearingat least 90 percent of the checks. The figure demonstratesthat properly choosing the value of RC, e.g., between 0.5and 0.55, can make � have very little effect on PðQ � 0:9 � �Þ.Fig. 8 shows the effect of the collusion attack on PðQ �0:9 � �Þ at different values of RC and n of 5. The figuredemonstrates how the honest nodes can take protectivemeasures to protect against the colluding nodes. Tomitigate the effect of one and two colluding nodes, RC

�

should be 0.46 and 0.56, respectively, i.e., if each nodesubmits only 56 percent of the checks, we can probabil-istically guarantee submitting at least 90 percent of thechecks even if two nodes collude. Therefore, the increase ofRC strengthens the robustness against the collusion attack butwith additional redundant checks, which shows an intuitivetrade-off between security and overhead.

4.3 Discussion

Although our focus was on the unidirectional data transmis-sion in the previous sections, FESCIM can also be applied forbidirectional data transmission. In this case, FESCIM canbypass sending some ACK packets by using the data packets


Fig. 6. The effect of RC on the number of submitted checks.

Fig. 7. The effect of � on PðQ � 0:9 � �).

Fig. 8. The effect of collusion attack on the ratio of submitted checks.

to serve as ACKs. Fig. 9 shows the exchanged security tags inFESCIM for bidirectional data transmission assuming thatthe nodes IDA and IDB send X2 and X1 messages,respectively, and X2 > X1. The Xth data packet sent fromIDA to IDB contains Si, X, the message MA;X and its hash value,and the signature SigAðSi;X;HðMA;XÞÞ. The Xth data packetsent from IDB to IDA contains Si, X, the message MB;X and itshash value, and the signature SigBðSi;X;HðMB;XÞÞ. Thesecurity tag SigBðSi;X;HðMB;XÞÞ means that node IDB hassent X messages to IDA and has also received X messagesfrom IDA. After IDB sends all its messages, it switches to thehash-chain-based ACKs to enable IDA to complete sending itsmessages. The first ACK packet contains IDB’s signature for ahash chain root ðHZ

Bð1ÞÞ and X1. Fig. 10a shows the checkformat of the bidirectional data transmission.

FESCIM can also be used for asymmetric paths. Asshown in Fig. 11, the path P1 with the intermediate nodesID1 and ID2 can only transport packets from IDS to IDD, andthe path P2 with the intermediate nodes ID3 and ID4 canonly transport packets from IDD to IDS . The Xth data packet

in P1 contains DataP1ðXÞ that is similar to the data packet inFig. 3, and ACKP1ðX� 1Þ that contains the destinationnode’s ACK for the message MX�1, where ACKP1ðX� 1Þ issent from IDD to IDS through P2. The Xth data packet in P1also contains the source node’s ACK for the X � 1th datapacket sent through P2 ðACKp2ðX � 1ÞÞ to enable ID3 andID4 to compose checks. In other words, P1 transports thesource node’s messages and P2 transports the ACKs of themessages. The source and destination nodes compose twohash chains by iteratively hashing random values to obtainthe hash chains’ roots ðHZ

Dð1Þ and HZSð1ÞÞ. The source and

destination nodes send the signatures SigSðSi;P2;HZSð1ÞÞ and

SigDðSi;P2;HZDð1ÞÞ to authenticate the hash chains and link

them to P2, where Si;P2 ¼ IDS; ID4; ID3; IDD;TS;Pr. Thesource and destination nodes release one element fromtheir hash chains, i.e., DataP2ðXÞ contains a hash value fromthe destination node’s hash chain to acknowledge the datareceived from IDS through P1, and ACKP2ðX� 1Þ contains ahash value from the source node’s hash chain to acknowl-edge receiving DataP2ðX� 1Þ. ID1 and ID2 can composechecks using the mechanism discussed in Section 4.1, andFig. 10b shows the composed checks by ID3 and ID4.

5 SECURITY ANALYSIS

For Double-Rewarding attack, the attacker attempts toillegally increase its rewards by submitting a check multipletimes. In order to thwart the attack and identify theattackers, the AC checks whether the check has beendeposited using the check unique identifier (Si). ForDouble-Spending attack, the attacker attempts to generateidentical checks for different sessions to pay once. Twochecks cannot have the same identifier because it containsthe identities of the session nodes and time stamp. ForCheck-Forgery-and-Manipulation attack, the attackers attemptto forge checks or manipulate valid checks to increase theirrewards. This is not possible with using secure hashfunction and signature scheme because it is not possibleto forge or modify the source and destination nodes’signatures and to compute the private keys from the publicones. It is also infeasible to compute the hash value of thesource and destination nodes’ signatures without comput-ing the signatures, and to compute HZ�X

D ðiÞ from HZ�Xþ1D ðiÞ.

The AC can identify the attackers when the verifications oftheir checks repeatedly fail.

For Receiver-Robbery attack, the source node colludeswith some intermediate nodes to steal credits from the


Fig. 9. The security tags of the bidirectional data transmission.

SC(X1, X2)

D = Si, X1, X2, H(MA,X2), HBZ(1), HB

Z-(X2-X1)-1(1)

St = H( SigA(Si, X2, H(MA,X2)), SigB(Si, HBZ(1), X1) )

Fig. 10. The check format of the bidirectional data transmission andasymmetric paths.

Fig. 11. FESCIM for asymmetric paths.

destination node by sending bogus messages paid by thesource and destination nodes or composing faked ormanipulated checks. For example, from Fig. 5, if the sourcenode colludes with K intermediate nodes, the colludingintermediate nodes earn ðX � � �KÞ credits but the sourcenode pays ðX � � � n � PrÞ for X messages. Obviously, thecolluders can achieve gains when ðX � � �K�X � � � n �PrÞ > 0 or ðK� n � PrÞ > 0. In FESCIM, the colluding nodescannot fake or manipulate checks to steal credits from thedestination node because the destination node’s signatureand hash chain elements are required to compose a validcheck. Moreover, a session cannot be established and avalid check cannot be composed if the destination node isnot interested in the communication because its signature isrequired. The intermediate nodes are rewarded only whenthe destination node acknowledges receiving correctmessages, and thus they do not earn from bogus messages.For Packet-Replay attacks, the internal or external attackersmay record valid packets and replay them in different placeand/or time claiming that they are fresh, to establishsessions under the name of other nodes to communicatefreely. FESCIM uses time stamp to ensure that stale packetscan be identified and dropped. For Impersonation attack, theattackers attempt to impersonate other nodes to commu-nicate freely or steal credits. This attack is not possiblebecause the nodes use their private keys to sign the packets,and the attackers cannot compute other nodes’ private keys.

For Free-Riding attacks, two colluding intermediatenodes in a legitimate session manipulate the session packetsto piggyback their data to communicate freely. To thwartthis attack, the integrity of the packets should be checked ateach node, and thus, the first node after the first colludercan detect the packet manipulation and drop the packet.For data and RREP packets, the source and destinationnodes’ signatures can ensure the packets’ integrity. Theintegrity of the ACK packets can also be ensured because itcontains one element of the hash chain, which is verified ateach node. The RREQ packets are much shorter than thedata packets, e.g., if a node’s identity requires 4 bytes andthe average number of nodes in a route is 5, the averagesize of the RREQ packet is nearly 20 bytes, which isincomparable with 512 bytes of the data packets. FESCIMcan be implemented on the top of a secure routing protocolsuch as ARAN [36] and Ariadne [37]. In this protocol, theintermediate nodes authenticate themselves to thwart theexternal attacks, e.g., the external attackers that are notmembers in the network participate in route discoveryphase with the intention of dropping the data packets tolaunch Denial-of-Service attacks. Fig. 12 shows securedRREQ packets that can authenticate the intermediate nodesand thwart packet manipulation. Each intermediate nodeappends its certificate and signs the packet’s signature toauthenticate itself. In this way, launching Free-Riding

attacks against RREQ packets is not possible because thepacket integrity can be checked at each node.

For Denial-of-Check-Submission attack, the colluding attack-ers residing close to the base station may attempt to preventthe nodes from submitting the checks to the AC. First, thenodes accumulate the checks and submit them to the AC inbatch to reduce the communication overhead, e.g., checksmay be submitted every few days, and thus, the nodes canrepeatedly try to contact the AC during this time. Second, thenodes do not delete the checks before receiving the Checks-Submission-Confirmation packet from the AC. The nodestransmit the Checks-Submission-Request packet to the AC tosubmit the checks. This packet contains the identity of thesubmitter, time stamp, the checks, and the submitter’ssignature. The signature authenticates the submitter, thwartsPacket-Replay attack, and ensures the packet’s integrity. TheAC replies with the Checks-Submission-Confirmation packetcontaining the AC’s signature for the checks to confirm thesubmission of the checks. Third, the nodes may change theircells due to the nodes’ mobility, and thus, if they cannotsubmit the checks through one base station, they can submitthem through other base stations. Finally, the nodes cancontact the AC using wired networks such as the Internet andWi-Fi, as explained in Section 3.1.

Due to using the postpaid payment policy, the nodes cancommunicate even if they do not have sufficient credits atthe communication time. For Payment-Denial attacks, theattackers may join the network for a short time and leavewithout paying their debts. Different from the traditional adhoc networks that can be temporarily established andsimilar to the current single-hop cellular networks, MCN isa long-life network where the nodes have long-termrelations with the network. Moreover, the postpaid pay-ment policy has been widely used successfully in manyservices such as credit cards and cellular networks. InFESCIM, each node needs a certificate to use the network.Issuing a certificate is not free to make changing an identitycostly. Similar to the existing single-hop cellular networks,the AC stores the personal information of the users, andthus, it can take the legal procedures against the users whodo not pay. To limit the debt, a certificate lifetime is shortand depends on the node’s credits at the certificate issuingtime and its average credit consumption rate. We can alsomix both the prepaid and the postpaid payment policies toreduce the debt amount, e.g., each node has to pay somemoney in advance at certificate renewal.

Our payment model can counteract the rational attacksand encourage node cooperation. Particularly, the rationalattacker can exhibit one of the following actions:

1. If the intermediate nodes are rewarded for relayingthe messages that do not reach the destination node[28], [29], the colluding nodes can drop a messageand relay only the source node’s signature that ismuch shorter than the message to claim the paymentfor relaying the message. In our payment model, thenodes are motivated to forward the messagesbecause they are rewarded only when the destina-tion node receives them.

2. If the source and destination nodes are chargedonly for the successfully delivered messages, the


Fig. 12. Secured RREQ packets.

destination node and/or colluding intermediatenode may claim that the message does not reachthe destination so as not to pay. To prevent this,both the source and destination nodes are chargedfor the undelivered messages.

3. Relaying the route establishment packets is bene-ficial for the nodes to participate in sessions and thusearn credits. If the destination node does notacknowledge a message, it pays for the messageand the source node does not send the next message.Relaying the ACK packets is beneficial for theintermediate nodes to trigger the source node togenerate more messages and thus earn more credits.

Although the charges are always more than or equal tothe rewards, our payment model does not make creditsdisappear because purchasing credits for real money cancompensate the credit loss. The rich nodes that have muchmore credits than their credit consumption may stopcooperation to save their resources. The AC converts creditsto real money to motivate these nodes to cooperate becausethis conversion reduces the nodes’ credits. Similar tothe existing mechanisms, we believe that ACK packets areessential to secure the payment whether only the sourcenode pays or both the source and destination nodes pay.That is because 1) if only the source node pays, someintermediate nodes may drop the messages and save onlythe source node’s signature to be rewarded for theundelivered messages; and 2) if both the source anddestination nodes pay, the source node may collude withsome intermediate nodes to steal credits from the destina-tion node by sending bogus messages.

In order to evaluate the security strength of the proposedcheck submission schemes, we introduce (3) and (4) whichgive the probabilities that a check is not submitted in theProbabilistic and Changeable Submitter schemes, respectively.They are equivalent to the probabilities that a session has atleast one honest node and the honest nodes do not submitthe check. Phði; nÞ given in (5) is the probability that i honestnodes participate in a session with n intermediate nodes. Pm

is the probability that an intermediate node is a colluder,which is equivalent to the ratio of colluding nodes in thenetwork. nt and n are the total number of nodes in thenetwork and the number of intermediate nodes in a session,respectively. nh and nc are the number of honest andcolluding nodes, where nh ¼ ð1� PmÞ � nt and nc ¼ Pm � nt�From Fig. 13, in order to prevent submitting a low ratio of thechecks in the Probabilistic-Check-Submission scheme, the sourceand destination nodes have to collude with a large number ofnodes, which is not realistic for civilian applications and scalablenetwork. For example, in order to prevent submitting10 percent of the checks, the ratios of the colluding nodesare 33 percent, 48 percent, and 64 percent when RC is 0.55,0.65, and 0.75, respectively. The figure also shows that theProbabilistic scheme can protect the check submission muchbetter than the Changeable-Submitter scheme. The increase ofRC can reduce the probability of unsubmitting a check butwith additional redundant checks. The probability ofunsubmitting a check decreases at large value of Pm

because the probability that an honest node participates inthe session decreases:

Puðprobabilistic schemeÞ ¼Xi¼ni¼1

phði; nÞ � ð1� RcÞi; ð3Þ

PuðChangeable Submitter schemeÞ ¼Xi¼ni¼1

phði; nÞ �n� i

n; ð4Þ

Phði; nÞ ¼n

i

� ��Qi�1

f¼0ðnh � fÞ �Qn�i�1

b¼0 ðnc � bÞQn�1k¼0ðnt � kÞ

: ð5Þ

In Table 2, T is the total number of submitted checks in anoncollusion case, and Q is the number of unrepeatedchecks submitted under the collusion attack for a route withfive intermediate nodes and 1,000 checks. It can be seen thatthere is no redundant checks (cost ¼ 0) in Fixed-Submitterand Changeable-Submitter schemes because each check is


Fig. 13. The probability of unsubmitting a check.

TABLE 2The Number of Submitted Checks, n ¼ 5

submitted once. However, for the Fixed-Submitter scheme, ifthe source and destination nodes collude with the lastintermediate node in the route (C ¼ 1), all the checks are notsubmitted. The Changeable-Submitter scheme is more securethan the Fixed-Submitter scheme because the source anddestination nodes have to collude with a larger number ofnodes to achieve gains. The all-Submitters scheme is notvulnerable to the collusion attacks because each nodesubmits all the checks, but the number of redundant checksis large because six and seven copies of each check aresubmitted in Sprite and Express, respectively. For theProbabilistic-Check-Submission scheme, the increase of RC

enhances the robustness against the collusion attack butwith additional redundant checks. For example, theincrease of RC from 0.56 to 0.71 increases the number ofsubmitted checks probabilistically from 903 to 969 when Cequals 2 but with increasing the cost from 1,800 to 2,550.Moreover, the Probabilistic-Check-Submission scheme is lesssensitive to the number of colluders comparing with theChangeable-Submitter scheme, e.g., at RC ¼ 0:56, when Cincreases from 1 to 3, Q drops from 800 to 400 in theChangeable-Submitter scheme and from 955 to 790 in theProbabilistic-Check-Submission scheme.

Choosing a proper value for RC is important for reducingthe number of redundant checks and mitigating thecollusion attacks. The value of RC may depend on thelikelihood or the ease of attacking the incentive mechanism,e.g., the ease of obtaining multiple identities and compro-mising a device. The AC can dynamically estimate the valueof RC and broadcast it to the nodes. The AC can increase RC

to improve the protection level when more nodes complainthat they receive less rewards than their estimations.Moreover, storage area should not be the main concernand the more important factors are bandwidth and energybecause the capacities of the flash memories continue to riseas per Moore’s Law and their costs continue to plummet[38]. Each node can store all the checks but submit only theratio of RC. The AC informs the nodes about the identifiersof the cleared checks, and thus, the nodes delete them andsubmit the uncleared checks to the AC.

6 PERFORMANCE EVALUATION

In this section, we evaluate the checks’ overhead in terms ofthe check size and the number of generated checks. We alsoevaluate the overhead of the signed and hash-chain-basedACKs in terms of energy consumption and end-to-endpacket delay.

6.1 Simulation Setup

In our simulation, we consider the RSA signature schemeand SHA-1 hash function with digest length of 20 bytes [39],[40]. Although the signature tags of the DSA and ECDSAsignature schemes are shorter than that of the RSA, theseschemes increase the end-to-end delay significantly becausethe verifying operations performed by the intermediate anddestination nodes are computationally more demandingthan the signing operations performed by the source node.In [41], it is shown that the verification time of the 1,024-bitRSA is more than 31 and 45 times faster than those of the168-bit ECDSA and 1,024-bit DSA, respectively, and thesignature generation is measured to be around 8 and 6 times

slower. According to NIST guidelines [42], the secureprivate keys should have at least 1,024 bits.

In order to estimate the computational processing timesfor the signing, verifying, and hashing operations, we haveimplemented 1,024-bit RSA and SHA-1 using the Crypto++library [43]. The mobile node is a laptop with an Intelprocessor at 1.6 GHZ and 1 GB Ram, and the operatingsystem of the mobile node is Windows XP. The resultsgiven in Table 3 indicate that the RSA signature generationis computationally intensive but the signature verificationis much faster. The energy consumption of the RSA andSHA-1 operations is measured in [44] and the results aregiven in Table 3. The resources of a real mobile node maybe less than a laptop, so the results given in Table 3 arescaled by the factor of 5 in our simulations to estimate alimited-resource node.

We simulate an MCN in a square cell of 1;000 m �1;000 m. Thirty-five mobile nodes are randomly deployedand a fixed base station is located at the center of the cell.The radio transmission range of the mobile nodes and thebase station is 125 m. We use the modified randomwaypoint model [45] to emulate the nodes’ mobility.Specifically, a node travels toward a random destinationuniformly selected within the network field; upon reachingthe destination, it pauses for some time; and the processrepeats itself afterward. The node speed is uniformlydistributed in the range ½0; Smax� m/s and the pause timeis 20 s. The constant-bit-rate traffic source is implemented ineach node as an application layer. The source anddestination pairs are randomly selected. All data packetshave 512 bytes and are sent at the rate of 0.5 packets/s. Wesimulate the dynamic source routing (DSR) protocol [32]over distributed coordination function of the IEEE 802.11medium access control protocol. The time stamp, node’sidentity, and the number of messages are 5, 4, and 2 bytes,respectively. Network simulator NS2 (version 2.27) isused to evaluate the end-to-end delay and the networkthroughput using signed and hash-chain-based ACKs, andMATLAB is used to evaluate the check overhead. Oursimulation is executed for 15 simulated min and each datapoint represents the average of 50 runs.

6.2 Simulation Results

6.2.1 Check Overhead

The simulation results given in Table 4 demonstrate thatalthough FESCIM adopts more fair charging policy thanSprite and Express, the check size can be less. This isbecause of hashing the source and destination nodes’signatures and signing the hash of the message instead ofthe message, i.e., hashing the signatures can alleviate theeffect of the long RSA signature tag. For FESCIM, a check


TABLE 3The Processing Times and Energy for RSA and SHA-1

size depends on the number of used hash chains in thesession (i) because two hash values are attached to the checkper hash chain. If the hash-chain size is long enough,FESCIM can generate one fixed-size check per route. Astorage area of 1 MB can store up to 8,283; 5,176; and 5,350checks in FESCIM, Sprite, and Express, respectively, whenone hash chain is used in FESCIM.

Table 5 gives the statistical distribution of the number ofhash chains used for a route. The simulation resultsdemonstrate that more hash chains are used in low nodemobility because more packets are transmitted before theroute is broken. It can also be seen that the probability ofusing only one hash chain increases with the increase of Z.Properly choosing Z can reduce the number of used hashchains, which reduces the check size and saves the destina-tion node’s resources because the unused hash values in achain should not be used for other routes to secure thepayment. A good Z depends on the average number oftransmitted packets before the route is broken, which isrelated to the packet transmission rate, the node speed, andthe expected number of packets transmitted in the session.

Table 6 gives the expected number of checks and theamount of paid and earned credits in Sprite, Express, andFESCIM for a 300-second data transmission with differentnode speed. During the data transmission, a new route isestablished when the route is broken. For Sprite and Express,the simulation results demonstrate that the number of checksis large due to generating a check per message. The increaseof the nodes’ speed increases the number of checks becausechecks are generated for undelivered packets. FESCIM cansignificantly reduce the number of checks due to generatingone check per route. More checks are generated at high nodemobility because the routes are more frequently broken, i.e.,the messages are transmitted over larger number of routes.

For Sprite and Express, the amount of paid credits isequal to the amount of earned credits because the payment isonly for the nodes that relayed the undelivered messages.For FESCIM, the amount of paid credits is always more thanor equal to the amount of earned credits because the sourceand destination nodes are charged full payment for theundelivered messages to reduce the number of submitted

checks. The increase of the nodes’ speed increases theamount of paid credits because more credits are paid for theundelivered messages. In FESCIM, the amount of earnedcredits does not depend on the nodes’ speed because thenodes earn credits only for the delivered messages. How-ever, more credits are paid at high speed because the sourceand destination nodes pay for more undelivered messages.

6.2.2 ACK Overhead

For Z messages, the destination node generates Zsignatures in signed ACK-based incentive mechanisms,but one signature and Z hashing operations are requiredin the ACK packets of FESCIM. From Table 3, we can seethat the computational times of the signing and verifyingoperations are sufficient for 539 and 18 hashing operationsfor 512 bytes, respectively; and the consumed energy forthe signing and verifying operations are sufficient for 1,404and 41 hashing operations for 512 bytes, respectively,which demonstrates that FESCIM can adopt fair chargingpolicy almost computationally free.

The average end-to-end delay is the average timeinterval between the data packet transmission and thereception of the destination node’s acknowledgment. FromFig. 14, it can be seen that FESCIM can significantly reducethe end-to-end delay due to replacing the destinationnode’s signature with the lightweight hashing operations.Above 20 connections, the delay increases significantly withand without implementing the cooperation incentivemechanism due to the significant increase in the channelcontention and queuing delays.

The average network throughput is computed bydividing the size of the received data by all the nodes over


TABLE 4Average Check Size (Bytes)

TABLE 5The Statistical Distribution of

the Number of Used Hash Chains

TABLE 6The Number of Checks and the

Amount of Paid and Earned Credits

Fig. 14. The end-to-end delay for the signed ACK mechanisms andFESCIM.

the simulation time. As shown in Fig. 15, it can be seen thatincreasing the number of connections increases the networkthroughput until the network reaches its capacity. FESCIMis little better because more congestions occur in signedACK mechanisms due to the longer packet processing delayin the intermediate nodes.

7 CONCLUSION AND FUTURE WORK

In this paper, we have proposed a fair, efficient, and securecooperation incentive mechanism for MCN. In order to fairlyand efficiently charge the source and destination nodes, thelightweight hashing operations are used to reduce thenumber of public-key-cryptography operations. Moreover,to reduce the overhead of the payment checks, one small-sizecheck is generated per session instead of generating a checkper message, and the Probabilistic-Check-Submission schemehas been proposed to reduce the number of submitted checksand protect against the collusion attack. Extensive analysisand simulations have demonstrated that our incentivemechanism can secure the payment and significantly reducethe overhead of storing, submitting, and processing thechecks. In addition, replacing the destination node’s signa-tures with the hashing operations can charge the source anddestination nodes almost computationally free.

In this paper, instead of generating two signatures perpacket (one from the source and the other from thedestination), we have replaced the destination node’ssignature with hashing operations to reduce the number ofpublic-key-cryptography operations nearly by half. Thesource node attaches a signature in each data packet toensure the payment nonrepudiation and to verify themessage integrity at each intermediate node to thwart Free-Riding attacks. In our future work, we will focus on reducingthe number of public-key-cryptography operations due tothe source node’s signatures. Although the payment non-repudiation can be achieved using a hash chain at the sourcenode side, we will study how to efficiently verify themessage integrity at each intermediate node. In addition,similar to the existing incentive mechanisms, FESCIM canthwart selfishness attacks, but it cannot identify theirrational nodes that involve themselves in sessions withthe intention of dropping the data packets to launch Denial-of-Service attacks. In our future work, we will study how theAC can process the checks to identify the irrational nodes. InFESCIM, if two nodes IDA and IDB submit checks with

SigSðSi;X;HðMXÞÞ and SigSðSi;X� 1;HðMX�1ÞÞ, the AC canlearn that the data packet number X is dropped by anintermediate node A, B, or in-between node. However,packets may be dropped sometime, e.g., due to mobility orbad channel, or maliciously, but frequently droppingpackets is an obvious malicious behavior. In our futurework, we will study how the AC can precisely differentiatebetween the honest nodes and the irrational packet droppersin order to reduce the number of honest nodes that arefalsely identified as irrational packet droppers.

ACKNOWLEDGMENTS

This paper was presented in part at the 2009 IEEE

International Conference on Communications.

REFERENCES

[1] Y. Lin and Y. Hsu, “Multihop Cellular: A New Architecture forWireless Communications,” Proc. IEEE INFOCOM, vol. 3,pp. 1273-1282, Mar. 2000.

[2] X. Li, B. Seet, and P. Chong, “Multihop Cellular Networks:Technology and Economics,” Computer Networks, vol. 52, no. 9,pp. 1825-1837, June 2008.

[3] C. Gomes and J. Galtier, “Optimal and Fair Transmission RateAllocation Problem in Multi-Hop Cellular Networks,” Proc. Int’lConf. Ad-Hoc, Mobile and Wireless Networks, pp. 327-340, Aug. 2009.

[4] H. Wu, C. Qios, S. De, and O. Tonguz, “Integrated Cellular andAd Hoc Relaying Systems: iCAR,” IEEE J. Selected Areas in Comm.,vol. 19, no. 10, pp. 2105-2115, Oct. 2001.

[5] G. Shen, J. Liu, D. Wang, J. Wang, and S. Jin, “Multi-Hop Relay forNext-Generation Wireless Access Networks,” Bell Labs Technical J.,vol. 13, no. 4, pp. 175-193, 2009.

[6] R. Schoenen, R. Halfmann, and B. Walke, “MAC Performance of a3GPP-LTE Multihop Cellular Network,” Proc. IEEE Int’l Conf.Comm. (ICC), pp. 4819-4824, May 2008.

[7] 3rd Generation Partnership Project, Technical Specification GroupRadio Access Network, “Opportunity Driven Multiple Access,”3G Technical Report 25.924, Version 1.0.0, Dec. 1999.

[8] S. Marti, T. Giuli, K. Lai, and M. Baker, “Mitigating RoutingMisbehavior in Mobile Ad Hoc Networks,” Proc. ACM MobiCom,pp. 255-265, Aug. 2000.

[9] P. Michiardi and R. Molva, “Simulation-Based Analysis ofSecurity Exposures in Mobile Ad Hoc Networks,” Proc. EuropeanWireless Conf., Feb. 2002.

[10] J. Hu, “Cooperation in Mobile Ad Hoc Networks,” TechnicalReport TR-050111, Computer Science Dept., Florida State Univ.,Jan. 2005.

[11] G. Marias, P. Georgiadis, D. Flitzanis, and K. Mandalas,“Cooperation Enforcement Schemes for MANETs: A Survey,”J. Wireless Comm. and Mobile Computing, vol. 6, no. 3, pp. 319-332,2006.

[12] C. Song and Q. Zhang, “OMH-Suppressing Selfish Behavior inAd Hoc Networks with One More Hop,” Mobile Networks andApplications, vol. 14, no. 2, pp. 178-187, Feb. 2009.

[13] D. Djenouri and N. Badache, “On Eliminating Packet Droppers inMANET: A Modular Solution,” Ad Hoc Networks, vol. 7, no. 6,pp. 1243-1258, Aug. 2009.

[14] G. Bella, G. Costantino, and S. Riccobene, “Evaluating the DeviceReputation Through Full Observation in MANETs,” J. InformationAssurance and Security, vol. 4, no. 5, pp. 458-465, Mar. 2009.

[15] L. Feeney, “An Energy-Consumption Model for PerformanceAnalysis of Routing Protocols for Mobile Ad Hoc Networks,”Mobile Networks and Applications, vol. 3, no. 6, pp. 239-249, 2001.

[16] M. Peirce and D. O’Mahony, “Micropayments for Mobile Net-works,” technical report, Dept. of Computer Science, TrinityCollege, 1999.

[17] L. Buttyan and J. Hubaux, “Enforcing Service Availability inMobile Ad-Hoc WANs,” Proc. ACM MobiHoc, pp. 87-96, Aug.2000.

[18] L. Buttyan and J. Hubaux, “Stimulating Cooperation in Self-Organizing Mobile Ad Hoc Networks,” Mobile Networks andApplications, vol. 8, no. 5, pp. 579-592, Oct. 2004.


Fig. 15. The throughput for the signed ACK mechanisms and FESCIM.

[19] Y. Zhang, W. Lou, and Y. Fang, “A Secure Incentive Protocol forMobile Ad Hoc Networks,” ACM Wireless Networks, vol. 13, no. 5,pp. 569-582, Oct. 2007.

[20] A. Weyland and T. Braun, “Cooperation and Accounting Strategyfor Multi-Hop Cellular Networks,” Proc. IEEE Local and Metropo-litan Area Networks (LANMAN ’04), pp. 193-198, Apr. 2004.

[21] A. Weyland, “Cooperation and Accounting in Multi-Hop CellularNetworks,” PhD thesis, Univ. of Bern, Nov. 2005.

[22] J. Hubaux, L. Buttyan, and S. Capkun, “The Quest for Security inMobile Ad Hoc Networks,” Proc. ACM Symp. Mobile Ad HocNetworking and Computing, Oct. 2001.

[23] A. Weyland, T. Staub, and T. Braun, “Comparison of Motivation-Based Cooperation Mechanisms for Hybrid Wireless Networks,”J. Computer Comm., vol. 29, pp. 2661-2670, 2006.

[24] M. Jakobsson, J. Hubaux, and L. Buttyan, “A Micro-PaymentScheme Encouraging Collaboration in Multi-Hop Cellular Net-works,” Proc. Seventh Financial Cryptography (FC ’03), pp. 15-33,Jan. 2003.

[25] M. Mahmoud and X. Shen, “Stimulating Cooperation in Multi-Hop Wireless Networks Using Cheating Detection System,” Proc.IEEE INFOCOM, pp. 776-784, Mar. 2010.

[26] J. Pan, L. Cai, X. Shen, and J. Mark, “Identity-Based SecureCollaboration in Wireless Ad Hoc Networks,” Computer Networks,vol. 51, no. 3, pp. 853-865, 2007.

[27] N. Salem, L. Buttyan, J. Hubaux, and M. Jakobsson, “NodeCooperation in Hybrid Ad Hoc Networks,” IEEE Trans. MobileComputing, vol. 5, no. 4, pp. 365-376, Apr. 2006.

[28] S. Zhong, J. Chen, and R. Yang, “Sprite: A Simple, Cheat-Proof,Credit Based System for Mobile Ad-Hoc Networks,” Proc. IEEEINFOCOM, vol. 3, pp. 1987-1997, Mar./Apr. 2003.

[29] H. Janzadeh, K. Fayazbakhsh, M. Dehghan, and M. Fallah, “ASecure Credit-Based Cooperation Stimulating Mechanism forMANETs Using Hash Chains,” Future Generation ComputerSystems, vol. 25, no. 8, pp. 926-934, Sept. 2009.

[30] B. Lamparter, K. Paul, and D. Westhoff, “Charging Support forAd Hoc Stub Networks,” J. Computer Comm., vol. 26, no. 13,pp. 1504-1514, 2003.

[31] S. Miner and J. Staddon, “Graph-Based Authentication of DigitalStreams,” Proc. IEEE Symp. Security and Privacy, pp. 232-246, May2001.

[32] D. Johnson and D. Maltz, “Dynamic Source Routing in Ad HocWireless Networks,” Mobile Computing, pp. 153-181, chapter 5,Kluwer Academic, 1996.

[33] C. Perkins and E. Royer, “Ad-Hoc On-Demand Distance VectorRouting,” Proc. IEEE Workshop Mobile Computing Systems andApplications, pp. 90-100, Feb. 1999.

[34] H. Pagnia and F. Gartner, “On the Impossibility of Fair Exchangewithout a Trusted Third Party,” Technical Report TUD-BS-1999-02, Darmstadt Univ. of Technology, Mar. 1999.

[35] L. Anderegg and S. Eidenbenz, “Ad Hoc-VCG: A Trustful andCost-Efficient Routing Protocol for Mobile Ad Hoc Networks withSelfish Agents,” Proc. ACM MobiCom, Sept. 2003.

[36] K. Sanzgiri, D. LaFlamme, B. Dahill, B. Levine, C. Shields, and E.Belding-Royer, “Authenticated Routing for Ad Hoc Networks,”IEEE Selected Areas in Comm., vol. 23, no. 3, pp. 598-610, Mar. 2005.

[37] Y. Hu, A. Perrig, and D. Johnson, “Ariadne: A Secure On-DemandRouting Protocol for Ad Hoc Networks,” Proc. ACM MobiCom,Sept. 2002.

[38] A. Mitra et al., “High-Performance Low Power Sensor PlatformsFeaturing Gigabyte Scale Storage,” Proc. IEEE/ACM Measurement,Modeling, and Performance Analysis of Wireless Sensor Networks,2005.

[39] A. Menzies, P. Oorschot, and S. Vanstone, Handbook of AppliedCryptography, http://www.cacr.math.uwaterloo.ca/hac, CRCPress, 1996.

[40] Nat’l Inst. Standards and Technology (NIST), “Digital HashStandard,” Fed. Information Processing Standards Publication180-1, Apr. 1995.

[41] M. Wiener, “Performance Comparison of Public-Key Cryptosys-tems,” Technical Newsletter of RSA Laboratories’ CryptoBytes, vol. 4,no. 1, pp. 3-5, 1998.

[42] Nat’l Inst. of Standards and Technology (NIST), “Recommenda-tion for Key Management - Part 1: General (Revised),” SpecialPublication 800-57 200, 2007.

[43] W. Dai, “Crypto++ Library 5.6.0,” http://www.cryptopp.com,2011.

[44] N. Potlapally, S. Ravi, A. Raghunathan, and N. Jha, “A Study ofthe Energy Consumption Characteristics of Cryptographic Algo-rithms and Security Protocols,” IEEE Trans. Mobile Computing,vol. 5, no. 2, pp. 128-143, Mar./Apr. 2006.

[45] J. Yoon, M. Liu, and B. Nobles, “Sound Mobility Models,” Proc.ACM MobiCom, Sept. 2003.

Mohamed M.E.A. Mahmoud received the PhDdegree (April 2011) in electrical and computerengineering from the University of Waterloo,Ontario, Canada. He is currently a postdoctoralfellow with the Centre for Wireless Communica-tions, Department of Electrical and ComputerEngineering, University of Waterloo, under thesupervision of Prof. Sherman (Xuemin) Shen.His research interests include wireless networksecurity, privacy-preserving schemes, anon-

ymous and secure routing protocols, trust and reputation systems,cooperation incentive mechanisms, and cryptography. Dr. Mahmoud isthe first author for more than 20 papers published in major IEEEconferences and transactions. He won the prestigious Best PaperAward from the IEEE International Conference on Communications (ICC2009), Dresden, Germany. This award was one of only 14 given, among1,046 papers presented and more than 3,000 submitted, and was thesole award for the Communication and Information Systems SecuritySymposium. He has also served as a technical program committeemember and reviewer for many conferences and journals. He is amember of the IEEE.

Xuemin (Sherman) Shen received the BScdegree from Dalian Maritime University, China,in 1982, and the MSc and PhD degrees fromRutgers University, Camden, New Jersey, in1987 and 1990, respectively, all in electricalengineering. He is currently a professor and theuniversity research chair with the Centre forWireless Communications, Department of Elec-trical and Computer Engineering, University ofWaterloo, Ontario, Canada. He is the author or

coauthor of three books and more than 400 papers and book chapterson wireless communications and networks, control, and filtering. Heserves as the editor-in-chief for peer-to-peer networking and applica-tions and an associate editor for Computer Networks, ACM/WirelessNetworks, and Wireless Communications and Mobile Computing. Hehas also served as a guest editor for ACM Mobile Networks andApplications. His research focuses on mobility and resource manage-ment in interconnected wireless/wired networks, ultra wideband wirelesscommunications networks, wireless network security, wireless bodyarea networks, and vehicular ad hoc and sensor networks. He is aregistered professional engineer in the Province of Ontario and adistinguished lecturer of the IEEE Communications Society. He receivedthe Excellent Graduate Supervision Award in 2006 and the OutstandingPerformance Award in 2004 and 2008 from the University of Waterloo,the Premier’s Research Excellence Award in 2003 from the Province ofOntario, and the Distinguished Performance Award in 2002 and 2007from the Faculty of Engineering, University of Waterloo. He served asthe tutorial chair for the 2008 IEEE International Conference onCommunications, the technical program committee chair for the 2007IEEE Global Telecommunications Conference, the general cochair forthe 2007 International Conference in Communications and Networkingin China and the 2006 International Conference on Quality of Service inHeterogeneous Wired/Wireless Networks, and the founding chair for theIEEE Communications Society Technical Committee on P2P Commu-nications and Networking. He also serves as a founding area editor forthe IEEE Transactions on Wireless Communications and an associateeditor for the IEEE Transactions on Vehicular Technology and the KICS/IEEE Journal of Communications and Networks. He has also served asa guest editor for the IEEE Journal on Selected Areas in Communica-tions, IEEE Wireless Communications, and the IEEE CommunicationsMagazine. He is a fellow of the IEEE.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


ieee transactions on mobile computing, vol. …bbcr.uwaterloo.ca/~xshen/paper/2012/ffeasc.pdf ·...

Documents