1 / 48

Delay Tolerant Networks

Delay Tolerant Networks. Arezu Moghadam PhD Candidacy Talk 12/18/2007. Networking expansion. CDN Pub/sub. P2P overlays. Pervasive computing. Sensor nets. wireless. DTN. Internet. 2000. Applications rule!. 1990. Internet. ATM. 1970. 1980. B-ISDN. OSI.

lyris
Download Presentation

Delay Tolerant 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. Delay Tolerant Networks Arezu Moghadam PhD Candidacy Talk 12/18/2007

  2. Networking expansion CDN Pub/sub P2P overlays Pervasive computing Sensor nets wireless DTN Internet 2000 Applications rule! 1990 Internet ATM 1970 1980 B-ISDN OSI

  3. Interplanetary communication Ref: [1] Picture: http://www.intel-research.net/berkeley

  4. Tracking node with CPU, FLASH, radio and GPS Data Store-and-forward communications Data Data Data ZebraNet (a real life application) First deployment in 2004 in Kenya http://www.princeton.edu/~mrm/zebranet.html

  5. Internet environment End-to-end RTT is not large. Some path exists between endpoints. E2E reliability using ARQ works well. Packet-switching is the right abstraction. DTN characteristics Very large delays. Intermittent and scheduled links. Different network architectures. Conversational protocols fail. No ARQ. DTN characteristics Ref: [2], [3]

  6. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

  7. Architectural requirements • Asynchronous message delivery. • Naming • Tuples (names): ordered pairs (R, L) • No ARQ • Reliability • At least Hop-by-hop. • Type of links • Scheduled vs. non-scheduled. • Contact, an opportunity to transfer the data. • Predictable vs. opportunistic. Ref: [2], [3], [6]

  8. Persistent message storage A Data S R B Intermittent link “Always on” link R provides store-and-forward service Reliability • End-to-end vs. per-hop reliability. • Custody transfer • Not delete a message until delivery to another custodian. • Head of line blocking. • Even “always on” link is blocked. Ref: [4]

  9. Interplanetary or satellite GW Internet GW Sensors GW Bus route Suggested architectures • Sequential heterogeneous regions interconnected by gateways. • ParaNet • Users access more than one network over one device. • Different paths for signaling and data. • Challenges • Routing, transport protocol, naming, security over multiple paths and etc. Ref: [2]

  10. Data or control information over satellite DTN Store and forward Lightweight cellular network for signaling Suggested architectures • Sequential heterogeneous regions interconnected by gateways. • ParaNet • Users access more than one network over one device. • Different paths for signaling and data. • Challenges • Routing, transport protocol, naming, security over multiple paths and etc. Ref: [5]

  11. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

  12. Routing Challenges • Routing objectives: • Minimize delay • Maximize throughput • Per-hop routing vs. source routing. • No end-to-end path • MANET’s routing protocols fail. • Proactive and reactive • Store-carry-forward • Storage constraints • No Topology knowledge • Time varying connectivity graph Ref: [8]

  13. Routing Models • Flooding based protocols • Epidemic [18], Erasure coding [11] • Knowledge based routing • Oracle [8], Message Ferrying [15], [16], Practical routing [9] • Probabilistic routing • PROPHET [13], RPLM [12], MaxProp [14], MobySpace [10]

  14. Flooding based routing • Epidemic [18] • Exchanging summary vectors (hash values). • Erasure coding [11] • Use r relays wait for one or rxk relays and wait for k • Message can be decoded if k relays make it to the destination. >

  15. u v S w D x Knowledge based routing • An oracle which provides topology info. • Contacts, buffer constraints, traffic demands… [8] • Partial topology info. • Message ferrying [15],[16] • Using history to predict future topology. • Practical routing [9] Each edge is a contact meaning an opportunity to transfer data.

  16. Routing with global knowledge • Oracle; source of knowledge about topology • How much knowledge to achieve an acceptable delay. • Modified Dijkstra with time varying edge costs. • Source routing. • The more knowledge the better performance. (too obvious!) • Not realistic! Ref: [8] >>

  17. Routing with partial knowledge MF: Sparse MANETs with different deployment areas • Message ferrying • Ferries broadcast their situation. • Ferry route design to minimize drops NP hard  reduced to TSP. • Practical routing • Instead of contact schedules uses contact history. • Per-contact routing vs. per-hop routing. 1 2 3 4 Scalability: How increasing number of mobile nodes affects number of ferries? >> Ref: [15] , [16]

  18. D D 2 2 2 2 B C B C 3 8 3 0 A A Routing with partial knowledge • Message ferrying • Ferries broadcast their situation. • Ferry route design to minimize drops NP hard  reduced to TSP. • Practical routing • Instead of contact schedules uses contact history. • Per-contact routing. • Update the graph upon contact changes. Practical routing: Source: A dest: D Per-hop or per-source: A-B-D Per-contact: A-C-D (don’t wait for B) >> Ref: [9]

  19. Probabilistic routing • Estimate delivery likelihood. • Initially assign a delivery probability to each node. • Update upon meeting a node based on some criteria. • Link state routing to disseminate probability tables. A C B D Ref: [10], [12], [13], [14]

  20. Probabilistic routing • Estimate delivery likelihood. • Initially assign a delivery probability to each node. • Update upon meeting a node based on some criteria. • Link state routing to disseminate probability tables. A C B D Ref: [10], [12], [13], [14]

  21. Probabilistic routing > > >>

  22. Issues of the probabilistic routing. High rank Low rank Packets with hop counts < thresh Sorted by hop count Packets with hop counts > thresh Sorted by delivery likelihood Packets transmitted from here Packets deleted from here • Covered • No a priori knowledge of contacts. • Storage constraint and buffer management. • Network wide acks to free up buffer space or provide reliable delivery. • Not covered • What initial values to start with to converge to reasonable delivery probabilities? • What if nodes change their habits. How adaptive? • No mathematical proof of efficiency of the routing algorithms. Ref: [14], [12]

  23. Mobility model and performance analysis • Node mobility characteristic  better performance analysis. • Algorithms developed for specific scenarios. • Random with core aided nodes. • Community based. • Mixture of RWP and ferries. Ref: [17], [7]

  24. Performance evaluation Ref: [7], … , [17]

  25. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

  26. Multicast requirements and challenges. • Disaster recovery, battlefield… • Distribution of news to a group of users; • Who is the recipient? • Group membership changes during data transfer. • Routing is the most challenging problem. • Multicast semantics • Temporal membership: each message contains a membership interval. • Delivery interval as well as membership interval. • Current member: receiver should be a member at delivery time. Ref: [19]

  27. Group-based routing (UBR) Broadcast-based routing (BBR) R2 R1 R2 R1 S S Epidemic routing to all nodes [19] Forwarding group [19] Routing models.

  28. R F Tree-based routing (TBR) R R R R R1 MFER; MF with Epidemic routing [20] R2 R F S R Along the spanning tree containing all receivers [19] R R R MFGR; MF with group routing [20] Routing models contd… >>

  29. Performance Ref: [21] , [20] , [19]

  30. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

  31. TEK system • Searching WWW using email. • Email-based communication protocol. • TEK server located at MIT. • TEK client a Java proxy server. • Batchedrequests are emailed to the server. Remote TEK Client Req ISP Web Browser TEK Proxy Store-and-forward WWW Rep TEK Server MIT Ref: [23] , [25], [22]

  32. Internet 7DS • Based on epidemic routing. • Utilizing opportunistic contacts to pass email messages. • Basic platform to develop store-and-forward applications. Ref: [26]

  33. Agenda • Architecture • Routing • Multicast • Implementation • Conclusion

  34. Conclusions and future directions • A killer application! • Implementation efforts have been limited to specific not everyday life applications. • When Joint tactical radio system becomes available? [25] • ParaNet!? • Challenges: topology estimation and routing. • So far research focus on predictable network topologies. • Knowledge based approaches requiring a global view of the network are unrealistic. • Hybrid of MF with probabilistic routing!? • Absence of real world mobility patterns in algorithms evaluations. • Security issues still not discussed! • Lack of common APIs to abstract DTN.

  35. References • Papers list

  36. Back up slides…

  37. Probabilistic routing criteria • PROPHET • Delivery predictability calculation. • Routing with Persistent Link Modeling (RPLM) • Monitors link connectivity to calculate its cost. • Dijkstra to find a minimum cost path. • MaxProp • Assigning a cost value to each destination based on probability. • Priority queue  younger messages higher chances. • MobySpace • MobyPoint  each node’s coordinates or mobility pattern. • Distance on each axes probability of contacts or presence in a location.

  38. Routing with global knowledge • Message arrival time at a node must be predicted. • Predicted arrival time is used to determine the cost • At light load ED performance comparable to EDAQ and EDLQ. • Heavy traffic results in congested queues  Algorithms with queue knowledge are the winners.

  39. H T T T H H VANETS • Propagation of location specific information. • Directional propagation protocol • Custody transfer protocol • Inter-cluster routing protocol • Intra-cluster routing protocol • Routing based on local parameters and TTL • Routing in the absence of a global naming scheme. • Ex: traffic data to cars 5 miles away… West East

  40. PROPHET • Delivery predictability is calculated at each node for all destinations B; P(A,B) • When node A encounters node B the parameter P(A,B) is updated. • Packet transfer if delivery predictability at new node is higher than current one.

  41. Link Cost History • Idea is cost is related to the duration of connectivity. • Link with high transitions will get connected soon. • Compared with PROPHET • Single forwarding • Multi-forwarding • PROPHET doesn’t differentiate between carriers X and Y.

  42. Erasure Routing • Transforms a message of n blocks to a message of > n blocks. • Receiver can recover the original message from a subset of blocks • Fraction of the required blocks is the ratio r. • 1/r blocks are necessary • Instead of propagating among r relays as in srep distributes them among rk • Whether to use r relays and wait for one to succeed or to use rk relays and wait for k to succeed? • Worst case scenario

  43. D D 2 2 2 2 B C B C 3 8 3 0 A A Practical routing • MEED Minimizing estimated expected delay. • Using the contact history instead of contact schedule. • Nodes record connection and disconnection periods over a sliding window. • Propagating link state table. • Per-contact routing instead of source or per-hop routing.

  44. Practical routing simulation • Wireless LAN traces converted into a DTN scenario • Nodes are connected when associated to the same AP

  45. Message Ferrying – Single • Node Initiated MF • The ferry moves according to a specific route • Nodes make proactive movement to meet up with ferry • Message drops: buffer overflow or message time out • Nodes task time vs. meeting the ferry Ferry Initiated MF • Long range radios in nodes. • Service_Request • Location_Update • Ferry trajectory control based on minimizing message drop rate along the path. • NP-hard problem • Nearest Neighbor • Traffic aware

  46. Message Ferrying – Multiple • To allow scalability in traffic load • Single ferry single point of failure • Different scenarios • No interaction • Ferry relaying • Node relaying • Designing the ferry routes to minimize weighted delay.

  47. Ferry route design • Assigning nodes to ferries to minimize weighted delay. • Optimization problem with BW constraints • The higher the data rate the longer the route length.

  48. Multicasting with MF • Long-duration partitions makes multicast forwarding structure spanning all group members difficult. • Hybrid approach for Ferry initiated MC • Message Ferry with Epidemic Routing • Message Ferry with Group Routing • Adaptive Scheme

More Related