1 / 30

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

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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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 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)

  4. 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

  5. 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

  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! ) 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

  7. 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

  8. 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)

  9. 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

  10. Throughput The 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

  12. Stimulation for Cooperation in Multi-hop Cellular Networks Part 2 N. Ben Salem, L. Buttyán, J.-P. Hubaux and M. Jakobsson

  13. 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

  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? D S

  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 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

  22. 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

  23. 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

  24. 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

  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(m, Ku) = 1 iffdHamming(m, 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. 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)

  28. 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

  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)

More Related