SlideShare ist ein Scribd-Unternehmen logo
1 von 34
Downloaden Sie, um offline zu lesen
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
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
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
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
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
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
CAR –> Ergebnisse Simulation (1)




                                       Systems Architecture Group
                                   http://sar.informatik.hu-berlin.de
CAR –> Ergebnisse Simulation (2)




                                       Systems Architecture Group
                                   http://sar.informatik.hu-berlin.de
CAR –> Ergebnisse Simulation (3)




                                       Systems Architecture Group
                                   http://sar.informatik.hu-berlin.de
CAR –> Ergebnisse Simulation (4)




                                       Systems Architecture Group
                                   http://sar.informatik.hu-berlin.de
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
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
MEED -> Ansatz
Optimierung der 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
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
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
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
MEED -> Simulation (2)




                             Systems Architecture Group
                         http://sar.informatik.hu-berlin.de
MEED -> Simulation (3)




                             Systems Architecture Group
                         http://sar.informatik.hu-berlin.de
MEED -> Simulation (4)




                             Systems Architecture Group
                         http://sar.informatik.hu-berlin.de
MEED -> Simulation (5)




                             Systems Architecture Group
                         http://sar.informatik.hu-berlin.de
MEED -> Simulation (6)




                             Systems Architecture Group
                         http://sar.informatik.hu-berlin.de
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
Swim




       Swim-Sensor mit Pfeil


                                   Systems Architecture Group
                               http://sar.informatik.hu-berlin.de
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
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
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
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
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
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
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
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
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
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
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

Weitere ähnliche Inhalte

Andere mochten auch

Ejercicio c soc y clr i ago 2009
Ejercicio c soc y clr i ago 2009Ejercicio c soc y clr i ago 2009
Ejercicio c soc y clr i ago 2009
2012tirs
 
Antecedentes de la computación
Antecedentes de la computaciónAntecedentes de la computación
Antecedentes de la computación
cace97
 
Thesenpapier – Rettet die Münchner Freiheit
Thesenpapier – Rettet die Münchner FreiheitThesenpapier – Rettet die Münchner Freiheit
Thesenpapier – Rettet die Münchner Freiheit
mucfreiheit
 
international PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekten
international PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekteninternational PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekten
international PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekten
smueller_sandsmedia
 
Ein bisschen über mich selbst und meine Familie
Ein bisschen über mich selbst und meine FamilieEin bisschen über mich selbst und meine Familie
Ein bisschen über mich selbst und meine Familie
deutschcclvm
 

Andere mochten auch (19)

Cv vela valeria fernandez version corregida
Cv vela valeria fernandez version corregidaCv vela valeria fernandez version corregida
Cv vela valeria fernandez version corregida
 
Ejercicio c soc y clr i ago 2009
Ejercicio c soc y clr i ago 2009Ejercicio c soc y clr i ago 2009
Ejercicio c soc y clr i ago 2009
 
Antecedentes de la computación
Antecedentes de la computaciónAntecedentes de la computación
Antecedentes de la computación
 
Trabajo f
Trabajo fTrabajo f
Trabajo f
 
Talleres
TalleresTalleres
Talleres
 
Cuetionario h web 2.0
Cuetionario h web 2.0Cuetionario h web 2.0
Cuetionario h web 2.0
 
Relaunches erfolgreich planen. White Paper Insight Driven, August, 2015
Relaunches erfolgreich planen. White Paper Insight Driven, August, 2015 Relaunches erfolgreich planen. White Paper Insight Driven, August, 2015
Relaunches erfolgreich planen. White Paper Insight Driven, August, 2015
 
Social Media Menüs in WordPress
Social Media Menüs in WordPressSocial Media Menüs in WordPress
Social Media Menüs in WordPress
 
Tecnische Universitaet
Tecnische UniversitaetTecnische Universitaet
Tecnische Universitaet
 
Thesenpapier – Rettet die Münchner Freiheit
Thesenpapier – Rettet die Münchner FreiheitThesenpapier – Rettet die Münchner Freiheit
Thesenpapier – Rettet die Münchner Freiheit
 
international PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekten
international PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekteninternational PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekten
international PHP2011_Henning Wolf_ Mit Retrospektivenzu erfolgreichen Projekten
 
Ein bisschen über mich selbst und meine Familie
Ein bisschen über mich selbst und meine FamilieEin bisschen über mich selbst und meine Familie
Ein bisschen über mich selbst und meine Familie
 
Aplicaciones informáticas
Aplicaciones informáticasAplicaciones informáticas
Aplicaciones informáticas
 
wordpress
wordpresswordpress
wordpress
 
Solar Decathlon 17.04.2014 @ TIS | David Calas (LISI)
Solar Decathlon 17.04.2014 @ TIS | David Calas (LISI)Solar Decathlon 17.04.2014 @ TIS | David Calas (LISI)
Solar Decathlon 17.04.2014 @ TIS | David Calas (LISI)
 
Curso de Desarrollo Personal. Tema 4. Las Estructuras de Carácter. 1
Curso de Desarrollo Personal. Tema 4. Las Estructuras de Carácter. 1Curso de Desarrollo Personal. Tema 4. Las Estructuras de Carácter. 1
Curso de Desarrollo Personal. Tema 4. Las Estructuras de Carácter. 1
 
Borges
BorgesBorges
Borges
 
Dr. luis mario
Dr. luis marioDr. luis mario
Dr. luis mario
 
Pei
PeiPei
Pei
 

Ähnlich wie DTN Routing Verfahren

Präsentation Monitoring 31.1.2011
Präsentation Monitoring 31.1.2011Präsentation Monitoring 31.1.2011
Präsentation Monitoring 31.1.2011
Maikel Hahahup
 
Ruby on Rails in a metro session
Ruby on Rails in a metro sessionRuby on Rails in a metro session
Ruby on Rails in a metro session
Virttoo org
 
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best PracitcesConfiguration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
kaftanenko
 

Ähnlich wie DTN Routing Verfahren (20)

Die Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der FahrzeugentwicklungDie Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der Fahrzeugentwicklung
 
Dr. Thomas Petrik (Sphinx IT Consulting)
Dr. Thomas Petrik (Sphinx IT Consulting)Dr. Thomas Petrik (Sphinx IT Consulting)
Dr. Thomas Petrik (Sphinx IT Consulting)
 
Apache Kafka
Apache KafkaApache Kafka
Apache Kafka
 
Präsentation Monitoring 31.1.2011
Präsentation Monitoring 31.1.2011Präsentation Monitoring 31.1.2011
Präsentation Monitoring 31.1.2011
 
Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop
Realtime BigData Step by Step mit Lambda, Kafka, Storm und HadoopRealtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop
Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop
 
Apache Cassandra - Einführung
Apache Cassandra - EinführungApache Cassandra - Einführung
Apache Cassandra - Einführung
 
Ruby on Rails in a metro session
Ruby on Rails in a metro sessionRuby on Rails in a metro session
Ruby on Rails in a metro session
 
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
OEM Cloud Control - Hochverfügbar von Kopf bis Fuß
 
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best PracitcesConfiguration Management (Fokus: Version-Controlling) – Best Pracitces
Configuration Management (Fokus: Version-Controlling) – Best Pracitces
 
LAIK: A Library for Fault Tolerant Distribution of Global Data
LAIK: A Library for Fault Tolerant Distribution of Global DataLAIK: A Library for Fault Tolerant Distribution of Global Data
LAIK: A Library for Fault Tolerant Distribution of Global Data
 
OpenStack – Automatisiertes Bereitstellen von Instanzen
OpenStack – Automatisiertes Bereitstellen von InstanzenOpenStack – Automatisiertes Bereitstellen von Instanzen
OpenStack – Automatisiertes Bereitstellen von Instanzen
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
 
Streaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlStreaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der Wahl
 
Cloud-native Applikationen
Cloud-native ApplikationenCloud-native Applikationen
Cloud-native Applikationen
 
Microservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OSMicroservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OS
 
Cloud Native und Java EE: Freund oder Feind?
Cloud Native und Java EE: Freund oder Feind?Cloud Native und Java EE: Freund oder Feind?
Cloud Native und Java EE: Freund oder Feind?
 
Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?
 
VIT 3-2014
VIT 3-2014VIT 3-2014
VIT 3-2014
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
[15] Nu P 08 1
[15] Nu P 08 1[15] Nu P 08 1
[15] Nu P 08 1
 

Mehr von Florian Holzhauer (9)

Varnish PHP Unconference Hamburg 2012
Varnish PHP Unconference Hamburg 2012Varnish PHP Unconference Hamburg 2012
Varnish PHP Unconference Hamburg 2012
 
Entwicklung mit Chef und Vagrant - PHPUG HH
Entwicklung mit Chef und Vagrant - PHPUG HHEntwicklung mit Chef und Vagrant - PHPUG HH
Entwicklung mit Chef und Vagrant - PHPUG HH
 
Text Link Spam-Erkennung und -Unterdrückung
Text Link Spam-Erkennung und -UnterdrückungText Link Spam-Erkennung und -Unterdrückung
Text Link Spam-Erkennung und -Unterdrückung
 
Slides Link Spam-Erkennung und -Unterdrückung
Slides Link Spam-Erkennung und -UnterdrückungSlides Link Spam-Erkennung und -Unterdrückung
Slides Link Spam-Erkennung und -Unterdrückung
 
IP Geolocation
IP GeolocationIP Geolocation
IP Geolocation
 
Jabber is more than instant messaging
Jabber is more than instant messagingJabber is more than instant messaging
Jabber is more than instant messaging
 
bephpug - varnish & co
bephpug - varnish & cobephpug - varnish & co
bephpug - varnish & co
 
Jabber/XMPP
Jabber/XMPPJabber/XMPP
Jabber/XMPP
 
Linkspam: Erkennung und Unterdrückung
Linkspam: Erkennung und UnterdrückungLinkspam: Erkennung und Unterdrückung
Linkspam: Erkennung und Unterdrückung
 

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 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ü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 –> 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ü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 Optimierung der 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 – 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