Als PDF, PPTX herunterladen
![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](https://image.slidesharecdn.com/dtn2slides-110513050125-phpapp02/85/DTN-Routing-Verfahren-31-320.jpg)
![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](https://image.slidesharecdn.com/dtn2slides-110513050125-phpapp02/85/DTN-Routing-Verfahren-33-320.jpg)
![[8] Nu P 04 3](https://cdn.slidesharecdn.com/ss_thumbnails/8nup043-090228074202-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[1] Nu P 01 3](https://cdn.slidesharecdn.com/ss_thumbnails/1nup013-090228074027-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[10] Nu P 06 1](https://cdn.slidesharecdn.com/ss_thumbnails/10nup061-090228074301-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[4] Nu P 02 1](https://cdn.slidesharecdn.com/ss_thumbnails/4nup021-090228074056-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[5] Nu P 02 1](https://cdn.slidesharecdn.com/ss_thumbnails/5nup021-090228074104-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
DTN Routing Verfahren
- 1. Humboldt University Computer Science Department Systems Architecture Group http://sar.informatik.hu-berlin.de DTN-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 AdaptiveRouting (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ührung Ziel • Ermöglichung asynchroner Kommunikation • Nachrichtenzustellung mit Kontextinformationen optimieren Routing • Abschätzungen über Mobilität und Knotenparameter • hopweises Routing an besten Nachbarknoten Annahmen • 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 Attribute Routingprinzipien 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 –> ErgebnisseSimulation (1) Systems Architecture Group http://sar.informatik.hu-berlin.de
- 8. CAR –> ErgebnisseSimulation (2) Systems Architecture Group http://sar.informatik.hu-berlin.de
- 9. CAR –> ErgebnisseSimulation (3) Systems Architecture Group http://sar.informatik.hu-berlin.de
- 10. CAR –> ErgebnisseSimulation (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ührung Designziele •Routing selbstkonfigurierend • Performanz • Ressourceneffizienz • Skalierbarkeit Annahmen • 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 -> Ansatz Optimierungder Zustellungszeit • Komponenten der Zustellungszeit: – Wartezeit – Abarbeitungsverzögerung – Übertragungszeit – Latenz ⇒ berechen- und quantifizierbar Mobilitätsabschätzung gemäß Vergangenheit • Knoten beobachten An- und Abmeldungen anderer Knoten • Begrenzung auf Beobachtungsfenster Optimierung Link-State-Protokoll ⇒ Knoten können irrelevante Updates unterdrücken Systems Architecture Group http://sar.informatik.hu-berlin.de
- 14. MEED -> Routing Technik: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 Links Nachteil • 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 • MEED Bedingungen • 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 – UpdateI • 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 – UpdateII 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