Stimulation for Cooperation in Ad Hoc and Multi-hop Cellular Networks

N. Ben Salem*, L. Buttyán*, J.-P. Hubaux* and M. Jakobsson**

* Laboratory of Computer Communications and Applications Swiss Federal Institute of Technology – Lausanne, Switzerland

** RSA Laboratories, Hoboken, NJ, USA

Stimulation for Cooperation in

(pure) Ad Hoc Networks

Part 1

N. Ben Salem, L. Buttyán and J.-P. Hubaux

3

Motivation and goal

Ad hoc networks• no infrastructure• all networking services are provided by the nodes themselves• cooperation is essential

Problem• assume that nodes don’t belong to a single authority• there’s no good reason to cooperate• nodes tend to be selfish

Exampleif the average number of hops from source to destination is ~5 ~80 % of the energy is devoted to packet forwarding temptation to deny packet forwarding is strong

Our goal: to design a mechanism that stimulates cooperation (packet forwarding)

4

Proposed stimulation mechanism

Each node has a credit counter c, and1. when sending an own packet

– the number n of needed intermediate forwarding nodes is estimated– if c < n, then the packet cannot be sent– otherwise, the packet can be sent, in which case c is decreased by n

2. when forwarding a packet– c is increased by 1

+ Protection that ensures that– the user cannot manipulate the credit counter– the user cannot tamper with the above mechanism (but she can decide to drop a packet before the mechanism is

called !)– c is increased only if the packet has indeed been forwarded

• We propose a protection mechanism that is based on a tamper resistant hardware module in each node

5

Single node model (basic)

B, C, NINo

INf

OUT = OUTo + OUTf

DRP = DRPo + DRPf

B – initial battery levelC – initial credit levelN – constant charge

b – batteryc – credit counter

outo – own packets sent (during whole lifetime)outf – forwarding packets sent (during whole lifetime)

Selfishness: maximize outo subject to

(1) outo, outf 0(2) N outo – outf C(3) outo + outf = B

b,c

6

Single node model (extended)- own packets are generated at rate ro

- forwarding packets arrive at rate rf

- no buffering (if an own packet cannot be sent due to the low level of the credit counter, then it is dropped)

tend – time when the battery is drained out (not a constant! )

Selfishness: maximize outo and zo subject to

zo = outo / ro tend – fraction of own packets sent

(1) outo, outf 0(2) outo ro tend

(3) outf rf tend

(4) N outo – outf C(5) outo + outf = B

7

Forwarding rules

If f = (NB – C)/(N + 1) then drop else– rule 1: always forward– rule 2: if c C then forward else forward with prob C /c– rule 3: if c C then forward else drop– rule 4: if c C then forward with prob c /C else drop

where f is the number of packets forwarded so far and c is the current credit level

Prfwd(c)1

C c

rule 1 Prfwd(c)1

C c

rule 2

Prfwd(c)1

C c

rule 3 Prfwd(c)1

C c

rule 4

8

Comparison of forwarding rules (1)

Simulation parametersB = 100000 ro = 0.2 pkt/s

C = 100 rf = 0.6 … 1.6 pkt/sN = 5

Simulation results outo = 16683 = (B + C )/(N + 1)

9

Comparison of forwarding rules (2)

Simulation parametersspace 500 m x 500 m pkt generation rate 0.2 (0.5, 0.8) pkt/snumber of nodes 100 choice of pkt. dest. randompower range 120 m routing geodesic pkt fwdingmobility model random waypoint initial credits 100speed 1 m/s – 3 m/s credit sync interval 5 (10, 15,

20) savg. pause time 60 s simulation time 7200 s

Simulation results

10

ThroughputThe effect of less cooperative nodes (rule 3) on the total cumulative throughput

11

Conclusion

• We proposed a mechanism to stimulate the nodes of an ad hoc network for packet forwarding

• Our approach is based on a credit counter and enforcement of some simple rules in each node (tamper resistant hardware)

• We showed that the mechanism is effective assuming the following:– each node generates packets continuously– own packets are not buffered (they must be sent immediately or

dropped)– selfishness is represented by the goal of dropping as few own

packets as possible

Future work• Weakening the above assumptions• Application to other network functions (not only packet fwding)• Application in higher layers (e.g., peer-to-peer systems)• Application in hybrid (multi hop cellular) networks

Stimulation for Cooperation in

Multi-hop Cellular Networks

Part 2

N. Ben Salem, L. Buttyán, J.-P. Hubaux and M. Jakobsson

13

S

D

Multi-hop cellular

• Set of base stations connected to a backbone (like in cellular)• Potentially, multi-hop communication between the mobile

station and the base station (unlike in cellular)

14

Multi-hop cellular

• Advantages:– Energy consumption of the mobile stations can be

reduced– Immediate side effect: Reduced interference– Number of base stations (fixed antennas) can be

reduced– Coverage of the network can be increased– Closely located mobile stations can communicate

independently from the infrastructure (ad hoc networking)

• Disadvantages:– Routing?– Synchronization?

15

Our model

• Multi-hop up-link• Single-hop down-link

Problem: How to encourage the nodes to relay packets for the benefit of other nodes?

S

D

16

Approach

• The same old approach: Remunerating the forwarders (and charging the packet originator)

• with the following new elements (compared to the previous solution):– there is an operator (trusted by all nodes)– the operator maintains a billing account for each node – charging and remunerating are done by manipulating

billing accounts

17

The solution in three easy steps

Step 1: • Assume that all packet sending/receiving events can be

observed by an observer• The observer could tell who did what

– who originated a packet (who to charge)– who forwarded a packet (who to remunerate)– who dropped a packet (who to punish?)

Step 2: • Assume that every node honestly reports its own

sending/receiving events to the operator• The operator could tell who did what• Problems:

– nodes may not be motivated to send reports– nodes may lie (send false reports)– reporting all events may be a huge overhead

18

The solution in three easy steps

Step 3:• Nodes get paid for their reports

nodes are motivated to send reports

• Events to be reported are selected probabilistically this reduces the overhead

• Based on the received reports, the operator performs statistical analysis (auditing) this allows detection of cheating behavior

19

Assumptions

• Multi-hop cellular with multi-hop up-link and single-hop down-link

• Symmetric-key crypto, each node shares a long-term symmetric key with the operator (base stations)

• The operator is trusted by every node for

– not revealing secret keys

– correctly transmitting packets

– correctly performing billing and auditing

• Users are not trusted to act according to the protocol

– users behave rationally

– they can tamper with their devices

– users could collude

20

Protocol

• Setup– users register with the operator

– each registered user u gets an id and a symmetric key Ku

– Ku is shared by the user and the operator (base stations)

• Maintaining connectivity information– each user u keeps a list of triplets (ui, di, Li), where

• ui is a neighbor

• with distance (in hops) di from the base station and

• with reward level Li

– the list is sorted in terms of increasing values of di and Li

• Reward levels– packets have reward levels too– a higher reward level means higher charge for the originator and

higher reward for the forwarders

– ui is willing to forward packets with a reward level higher than Li

21

Protocol

• Packet origination: originator o wants to send payload p– o selects a reward level L

– computes a MAC = MACKo( L | p )

– transmits [ o | L | p | ] according to the Packet Transmission Protocol

• Packet transmission: user u – originator or forwarder – wants to transmit packet P = [ o | L | p | ]1. u selects his first as yet unselected entry (ui, di, Li) where Li < L

2. sends a forward request to ui (contains L and possibly more info)

3. waits for an ack from ui

• if received, then u sends P to ui

• if not received, then u increases i by one and goes to step 2

In any case: if u is not the originator, then u performs the Reward Recording Protocol

22

Protocol

• Network processing: the base station receives a packet P = [ o | L | p | ]

– it looks up the secret key Ko of the originator o

– verifies the MAC • if not correct, then drops the packet• if correct, then transmits the packet to the destination

– keeps a count of the number of packets transmitted for o– records a fraction of all triplets (, L, u), where u is the id of the

user from which it received the packet [ o | L | p | ]– periodically sends the recorded information to an accounting

center

23

Protocol

• Reward recording: user u has forwarded a packet P = [ o | L | p | ]– u interprets as a lottery ticket

– the ticket is winning for u iff f(, Ku) = 1 for some function f

– if is winning, then u records (u1, u2, , L), where

• u1 is the user from which he received P

• u2 is the user (or base station) to which he forwarded P

• Reward claim: user u has a list M of reward records– when u is adjacent to a base station, he transmits a claim

[ u | M | MACKu(M) ] to the base station

– the base station verifies the MAC• if incorrect, then ignores the claim• if correct then records the claim and sends an ack

– when u receives the ack, he deletes M from memory– the base station sends the recorded reward claims to the

accounting center

24

Protocol

• Accounting:– the accounting center receives

• reward claims of the form: “u claims (u1, u2, , L)”

• traffic info recorded by the base stations of the form: “(, L, u) from o”

– all originators whose identity has been recorded by a base station are charged

– all users whose identity figures as a claimant in an accepted reward claim are credited

– all users whose identity figures as sending or receiving neighbor in an accepted reward claim are also credited

– where a reward claim is accepted if

• it is correct ( f(, Ku) = 1 )

• the base station has reported the packet associated to as having been transmitted

25

Lottery ticket evaluation

• Requirements on the function f :– Evaluation must be performed for every packet the user

handles f should be lightweight– Users should not be able to verify reward claims on behalf of

each other without having to trust each other with their keys f should use all bits in Ku

– Reward recording and claiming should not dominate the protocol probability of winning should be small enough

– Auditing is possible only on a sufficiently large data set probability of winning should be large enough (trade-off)

• An example: f(, Ku) = 1 iff dHamming(, Ku) h

• Note: If f is not one-way, then all claims should be encrypted during transmission.

26

Auditing

Observation: • The probability for a ticket to win is independent of the

identity of the user who evaluates it

each user should figure as a claimant with approximately the same frequency as he figures as either sending or receiving neighbor of a claimant

27

Examples for abuses and their detection

• Packet droppingDescription: the user agrees to forward, but he doesn’t

forwardDetection: receiving neighbor freq. > sending neighbor

freq.

• Ticket sniffingDescription: the user claims credit for overheard

packetsDetection:– claimant freq. > receiving neighbor or sending

neighbor freq.– conflicting claims

b claims (a, c, , L)

d claims (b, c, , L)

a

bc

d

28

Examples for abuses and their detection

• Greedy ticket collectionDescription: a set of users collect and share tickets allowing

each other to choose from a larger pool than they forwardedDetection:– unusually long transmission paths (counted in number of

claims per packet)– abnormally high packet transmission rates per time unit by

some user (if timing information is also collected at the base station)

• Reward level tamperingDescription: the packet carries a large reward level during some

portion of the route, but the reward level is reduced by a colluder before the packet is transmitted to the base station

Detection:– claimants indicate a higher reward level in their claim than

that registered by the base station for a given packet

29

Conclusion

• We proposed a micro-payment scheme encouraging packet forwarding in multi-hop cellular networks

• Two motivations for forwarding:1.

• all users whose identity figures as a claimant in an accepted reward claim are credited

• a claim is accepted only if the base station has reported the corresponding packet

if the packet contains a winning ticket for u, then u is interested in forwarding the packet

2.• all users whose identity figures as sending or receiving

neighbor in an accepted reward claim are also credited if u sends the packet to the next hop v, then v may file

a claim, in which case u will be credited as a sending neighbor

30

Conclusion

• Our scheme relies on the existence of a trusted and powerful operator in the system

• Main features:– we encourage users to report about their packet

sending/receiving events by paying for these reports– events to be reported are selected probabilistically (lottery

tickets) which reduces overhead– the operator performs statistical analysis of the received

reports in order to detect cheating– extremely low overhead for the nodes (especially, in terms

of computation)