DTN Routing Verfahren
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

DTN Routing Verfahren

on

  • 1,048 views

 

Statistics

Views

Total Views
1,048
Views on SlideShare
1,048
Embed Views
0

Actions

Likes
0
Downloads
31
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DTN Routing Verfahren Presentation Transcript

  • 1. Humboldt University Computer Science Department Systems Architecture Group http://sar.informatik.hu-berlin.deDTN-Routing-Verfahren Florian Holzhauer, Ralf Cremerius (fh@fholzhauer.de, cremeriu@informatik.hu-berlin.de) Interplanetary Internet Seminar, 2006 08.06.2006
  • 2. Gliederung• Context-aware Adaptive Routing (CAR)⇒ Metrik der Zustellungswahrscheinlichkeit• Minimum Estimated Expected Delay (MEED)⇒ Metrik der Verzögerung• Shared Wireless Infostation Model (SWIM)⇒ Queue-Behandlung• Probabilistic Routing Protocol using History of Encounters and Transitivity (PROPHET)⇒ Metrik über Begegnungswahrscheinlichkeit Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 3. CAR -> EinführungZiel• Ermöglichung asynchroner Kommunikation• Nachrichtenzustellung mit Kontextinformationen optimierenRouting• Abschätzungen über Mobilität und Knotenparameter• hopweises Routing an besten NachbarknotenAnnahmen• Keine absoluten Positionsinformationen• Annahme mobiler Knoten zwischen unverbundenen Netzen• Netzwerk kooperierender Knoten Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 4. CAR –> Routing• „Kontext“: Für Nachrichtenzustellung relevante AttributeRoutingprinzipien der Knoten• synchrones Routing für netzinterne Zielknoten asynchrones Routing für netzexterne Zielknoten• berechnen Zustellungswahrscheinlichkeiten durch Kontext• abschätzen von Kontextinformationen zwischen Updates• berechnen Routingtabelle: (Ziel, Nachbarknoten, Zustellungswahrsch.)• Nachrichtenweiterleitung an maximal mobilen Netzknoten Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 5. CAR –> Kontextbewertung• Statisch gewichtete Kontextbewertung  n  Maximise  f ( U ( xi ) ) = ∑ wU i ( xi )  i  i =1 • Dynamisch gewichtete Kontextbewertung  n  Maximise  f ( U ( xi ) ) = ∑ ai ( xi )U i ( xi )   i =1  ai ( xi ) dabei zusammengesetzter Parameter, z.B. aus: – Dringlichkeit – Vorhersagbarkeit – Verfügbarkeit Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 6. CAR –> Mobilitätsmodell• Standardannahme völliger Zufälligkeit unrealistisch• Knoten streben zufällige Zielpunkte an• Neuorientierung bei Erreichen der Zielpunkte• Entscheidungen durch Zufallszahlenvergleich mit Treshold• Einzelne Netze bewegen sich im Ganzen Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 7. CAR –> Ergebnisse Simulation (1) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 8. CAR –> Ergebnisse Simulation (2) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 9. CAR –> Ergebnisse Simulation (3) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 10. CAR –> Ergebnisse Simulation (4) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 11. CAR -> Zusammenfassung• Effizientes Routing durch Bewertung und Vorhersage von Kontextinformationen• Wenig Overhead• Mäßiger Berechnungsaufwand• Gute Zustellungsleistung Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 12. MEED -> EinführungDesignziele• Routing selbstkonfigurierend• Performanz• Ressourceneffizienz• SkalierbarkeitAnnahmen• Kein Wissen über Netzwerk• Netzwerk als ungerichteter Graph• Konstante Bandbreite der Verbindungen• Verzögerung wird vernachlässigt Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 13. MEED -> AnsatzOptimierung der Zustellungszeit• Komponenten der Zustellungszeit: – Wartezeit – Abarbeitungsverzögerung – Übertragungszeit – Latenz⇒ berechen- und quantifizierbarMobilitätsabschätzung gemäß Vergangenheit• Knoten beobachten An- und Abmeldungen anderer Knoten• Begrenzung auf BeobachtungsfensterOptimierung Link-State-Protokoll⇒ Knoten können irrelevante Updates unterdrücken Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 14. MEED -> RoutingTechnik: Per-contact routing• Routingtabelle bei Nachrichtenankunft berechnen⇒ Entscheidung auf Basis aktuellster Information• Verfügbare Links mit 0 bewerten⇒ Spontane Nutzung von „Abkürzungen“ Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 15. MEED -> Routing (2)Vorteil• Alternativenfindung für tote LinksNachteil• Verwendung Link-State-Protokoll + veränderliche Topologie⇒ Anfälligkeit für Zyklen • W enn sich Kantenbewertungen schnell genug ändern ⇒ Besonders bei Abkürzungen problematisch: Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 16. MEED -> Simulation (1)Vertreter• ED – Earliest delivery• MED - Minimum expected delay• MED mit per-contact routing• Epidemic• MEEDBedingungen• Abgeleitete Daten aus WLAN-Traces• Betrachtung von 30 Knoten Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 17. MEED -> Simulation (2) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 18. MEED -> Simulation (3) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 19. MEED -> Simulation (4) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 20. MEED -> Simulation (5) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 21. MEED -> Simulation (6) Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 22. MEED -> Zusammenfassung• Effizientes Routing durch Beobachtung von Wartezeiten• Hohe Zustellungswahrscheinlichkeit mit nur einer Nachricht• Flexibel gegenüber Topologieänderungen• große Routingtabellen durch Link-State-Routing⇒ Großer Speicher- und Verarbeitungsaufwand bei Updates⇒ Viel Overhead in großen Netzwerken• Zyklen können auftreten Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 23. Swim Swim-Sensor mit Pfeil Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 24. Swim - Bedingungen• Wenig Speicherplatz (60 KB)• Wenig Energie (8-35 mA bei Übertragung)• „Schnelle“ Datenübertragung (25Kbit/s)• Maximal 3 Monate Zeit zur Übertragung Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 25. Swim - Netztopologie• Datenaustausch zwischen den Walen – Soziale Faktoren bei Begegnungswahrscheinlichkeit – Keine echter Zufall – Löschung einzelner Pakete bei vollem Speicher• Endstation „Swim-Station“ – Schwimmende Tonnen – Mehrere Tonnen verteilt im W asser – Komplettleerung der Queue Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 26. SWIM Stations • Gute Wahl der Swim Stations sinnvoller als Anzahl • F(T): Wahrscheinlichkeit der Auslieferung nach T Timeticks Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 27. Queue Management• JUST_TTL: Paket wird nach TTL gelöscht• FULL_ERASE: Beim Übergeben an die Swim Station wird Speicher komplett gelöscht• IMMUNE: Nach Übergabe wird Paket nicht mehr angenommen• IMMUNE_TX: Wie IMMUNE, zusätzlich Weitergabe der Information über erfolgte Auslieferung an andere Wale mit der Nachricht• VACCINE: Wie IMMUNE_TX, aber Auslieferungsinfo an alle Wale Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 28. Queue Management II• Delivery Confidence hängt von F(T) ab -> Zeitdauer unterschiedlich• Mehr Puffer -> weniger Delay Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 29. Prophet - Routing• Bisher erfolgte Begegnungen als Grundlage der Routingtabelle• Nicht zufälliges („Soziales“) Netzwerk• Umweltfaktoren• „Transitiv“ Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 30. Prophet - Vorhersagbarkeit?• „delivery predictability“• Tabelle mit P(a,b) – Wahrscheinlichkeit des Wiedersehens mit bereits getroffenen Knoten• Treffen zweier Knoten -> Austausch und Aktualisierung der Routingtabelle• Keine Berücksichtigung von Umweltfaktoren• PInit, Beta, Gamma? Unklar. Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 31. Prophet – Update I• Update beim Treffen zweier Nodes• P(a,b) = P(a,b)old + (1- P(a,b)old) * PInit• Pinit = (O,1]• „Häufige Begegnung = Hohe Wahrscheinlichkeit“ Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 32. Prophet – Update II k• P(a,b) = P(a,b)old * γ• γ = „Alterungskonstante“ (0,1)• K = Zeiteinheiten seit letzter Begegnung• Alterung wird regelmässig ausgeführt Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 33. Prophet - Transivitität• P(a,c) = P(a,c)old +(1-P(a,c)old) * P(a,b) * P(b,c) * β• Β „scaling constant“ - entscheidet über Einfluss der Transitivität [0,1]• A sieht häufig B, B häufig C => Routing von A nach C am besten über B Systems Architecture Group http://sar.informatik.hu-berlin.de
  • 34. Quellen• Adaptive Routing for Intermittently Connected Mobile Ad Hoc Networks Mirco Musolesi, Stephen Hailes, Cecilia Mascolo• Practical Routing in Delay-Tolerant Networks Evan P. C. Jones, Lily Li, Paul A. S. Ward• Probabilistic Routing in Intermittently Connected Networks Anders Lindgren, Avri Doria, Olov Schelén• A Sensor Network for Biological Data Acquisition Tara Small, Zygmunt J. Haas, Alejandro Purgue, Kurt Fristrup• http://de.wikipedia.org/wiki/Link-State Systems Architecture Group http://sar.informatik.hu-berlin.de