300 likes | 365 Views
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
E N D
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
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 Example if 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)
Proposed stimulation mechanism Each node has a credit counter c, and 1. 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
B, C, N INo OUT = OUTo + OUTf INf DRP = DRPo + DRPf Single node model (basic) B – initial battery level C – initial credit level N – constant charge b – battery c – credit counter b,c 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
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! ) zo = outo / ro tend – fraction of own packets sent Selfishness: maximize outo and zo subject to (1) outo, outf³ 0 (2) outo£ro tend (3) outf£rf tend (4) N outo – outf£ C (5) outo + outf = B
Prfwd(c) Prfwd(c) rule 2 rule 1 1 1 C c c C Prfwd(c) rule 3 1 c C rule 4 Prfwd(c) 1 c C 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 /Celse drop where f is the number of packets forwarded so far and c is the current credit level
Comparison of forwarding rules (1) Simulation parameters B = 100000 ro = 0.2 pkt/s C = 100 rf = 0.6 … 1.6 pkt/s N = 5 Simulation resultsouto = 16683 = (B + C )/(N + 1)
Comparison of forwarding rules (2) Simulation parameters space 500 m x 500 m pkt generation rate 0.2 (0.5, 0.8) pkt/s number of nodes 100 choice of pkt. dest. random power range 120 m routing geodesic pkt fwding mobility model random waypoint initial credits 100 speed 1 m/s – 3 m/s credit sync interval 5 (10, 15, 20) s avg. pause time 60 s simulation time 7200 s Simulation results
Throughput The effect of less cooperative nodes (rule 3) on the total cumulative throughput
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
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) D S
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?
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? D S
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
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
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
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
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
Protocol • Packet origination:originator o wants tosend payload p • o selects a reward level L • computes a MAC m = MACKo( L | p ) • transmits [ o | L | p | m ] according to the Packet Transmission Protocol • Packet transmission: user u – originator or forwarder – wants to transmit packet P = [ o | L | p | m ] 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
Protocol • Network processing: the base station receives a packet P = [ o | L | p | m ] • it looks up the secret key Ko of the originator o • verifies the MAC m • 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 (m, L, u), where u is the id of the user from which it received the packet [ o | L | p | m ] • periodically sends the recorded information to an accounting center
Protocol • Reward recording: user u has forwarded a packet P = [ o | L | p | m ] • u interprets m as a lottery ticket • the ticket is winning for u iff f(m, Ku) = 1 for some function f • if m is winning, then u records (u1, u2, m, L), where • u1 is the user from which he received P • u2is 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
Protocol • Accounting: • the accounting center receives • reward claims of the form: “u claims (u1, u2, m, L)” • traffic info recorded by the base stations of the form: “(m, 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(m, Ku) = 1 ) • the base station has reported the packet associated to m as having been transmitted
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(m, Ku) = 1 iffdHamming(m, Ku) £ h • Note: If f is not one-way, then all claims should be encrypted during transmission.
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
d a c b Examples for abuses and their detection • Packet dropping Description: the user agrees to forward, but he doesn’t forward Detection: receiving neighbor freq. > sending neighbor freq. • Ticket sniffing Description: the user claims credit for overheard packets Detection: • claimant freq. > receiving neighbor or sending neighbor freq. • conflicting claims d claims (b, c, m, L) b claims (a, c, m, L)
Examples for abuses and their detection • Greedy ticket collection Description: a set of users collect and share tickets allowing each other to choose from a larger pool than they forwarded Detection: • 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 tampering Description: 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
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
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)