1 / 16

CCSDS Fall 2009 Meeting ESTEC 28/10/2009

Progress Report on ESA/ESOC DTN Testbed V. Tsaoussidis, DUTH – Greece. CCSDS Fall 2009 Meeting ESTEC 28/10/2009. ESA DTN Testbed. Departing Question: What are the driving needs for DTN?  No, not just interoperability.

dareh
Download Presentation

CCSDS Fall 2009 Meeting ESTEC 28/10/2009

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. Progress Report on ESA/ESOC DTN Testbed V. Tsaoussidis, DUTH – Greece CCSDS Fall 2009 Meeting ESTEC 28/10/2009

  2. ESA DTN Testbed Departing Question: What are the driving needs for DTN?  No, not just interoperability Fundamental Issues: Does it work? Can it work for Space? (Where) Is it functionally richer than CFDP, for example? Is it efficient enough, performance-wise? Can we quantify the gain from the use of DTN? DTN should not just work, but work where others fail. – By Definition. Evaluate it in stressed environments – search every aspect of it. CCSDS Fall 2009 Meeting 2/13

  3. When we say search, we mean search.

  4. Design a testbed for • Dynamic control of network parameters • Emulation of fundamental network parameters (bandwidth, PER, connectivity availability) • Realistic and dynamic adaptation to parameter changes in real-time (packet loss rate emulating solar storms, etc.) • Scalability • Efficient scaling over a large number of communication nodes • Transparency • Network emulation should be transparent to upper layer protocols and applications • Flexibility • Emulation of any desirable communication topology • Incorporation of new protocols, architectures, mechanisms • Interoperability with other DTN testbeds • Reusable infrastructure CCSDS Fall 2009 Meeting 3/13

  5. Architecture CCSDS Fall 2009 Meeting 4/13

  6. Architecture: Administrative Part • Graphical User Interface • Input of experiment parameters regarding: • Nodes (number, data production – consumption, storage size) • Links (bandwidth, error rate, propagation delay, availability) • Available protocols • Modification of parameters while the experiment is on progress • Real-time presentation of testbed statistics and status information • Kinematics Modeling System • Creation of the communication scenarios • Creation of the corresponding control data for the nodes • Central Management System • Handling of the communication between the various testbed components • Exchange of control data and status reports with the Emulation Nodes CCSDS Fall 2009 Meeting 5/13

  7. Architecture: Emulation Part • Emulation Nodes • Control Daemon • sets node parameters • generates status reports • communicates with Central Management System through the Control Plane • Node Protocol Stack • Protocol stack under evaluation • Individual PCs communicate through the Data plane, exchanging files • such as images, measurements, etc. CCSDS Fall 2009 Meeting 6/13

  8. Testbed Topology • Ten Emulation Nodes • Suitable for complex space communication scenarios • Intercontinental Link with MIT - Boston • Suitable for terrestrial scenarios • Geostationary Link (HellasSat Geo Satellite) • Suitable for low-orbit scenarios CCSDS Fall 2009 Meeting 7/13

  9. Protocol Stack • DTN Implementation: Interplanetary Overlay Network (ION) • Bundle Protocol • Asynchronous Message Service (AMS) • Licklider Transmission Protocol (LTP) • Contact Graph Routing (CGR) • Interoperates with DTN2 • An advanced application layer protocol is • required (e.g. CFDP) • CCSDS File Delivery Protocol (CFDP) • Automatic, reliable file transfer • File segmentation • Remote file management and directory listing • Lacks dynamic routing support CCSDS Fall 2009 Meeting 8/13

  10. Complicated Scenario CCSDS Fall 2009 Meeting 9/13

  11. Progress so far • Integration of CFDP into ION protocol stack • Performance evaluation of CFDP over ION versus CFDP as a stand alone application • Integration of CCSDS Space Packet protocol • Implementation of the protocol’s basic functionality • Evaluation of several DTN routing protocols • Comparison of Contact Graph Routing (CGR) with Probabilistic Routing Protocol using a History of Encounters and Transitivity (PRoPHET) and Flood routing • Design of efficient space oriented DTN transport • protocols • DS-TP • DTTP CCSDS Fall 2009 Meeting 10/13

  12. Progress so far • Integration of CFDP into ION protocol stack • Objective: Exploit CFDP file management features • CFDP on endpoints in unacknowledged mode • All intermediate nodes run ION • Reliability is achieved by the underlying network (BP, LTP) • Integration: • Middleware Application • Receives CFDP PDUs • Each CFPD PDU is encapsulated into a bundle • Requires mapping between CFDP ID and DTN EID • Validation – Evaluation: CFDP over BP/TCP and CFDP over BP/LTP CCSDS Fall 2009 Meeting 10/13

  13. Progress so far • Integration of CCSDS Space Packet Protocol into ION • Objective: Deployment of an architecture possibly used by ESA in future DTN space communications • Basic implementation of the Space Packet Protocol below LTP • Each LTP segment is encapsulated into a Space Packet • LTP Engine Number to APID mapping • Independent Packet Sequence Count for each LTP span • Intermediate nodes supporting only the Space Packet Protocol • Static routing of space packets based on APID between non-DTN nodes CCSDS Fall 2009 Meeting 10/13

  14. Progress so far • Evaluation of several DTN routing protocols • Objective: Comparison of Contact Graph Routing (CGR) with Probabilistic Routing Protocol using a History of Encounters and Transitivity (PRoPHET) and Flood routing • Observations • CGR outperforms both PRoPHET and Flood Routing when delay is in the order of seconds • PRoPHET does not perform well even for short delay values • CGR needs to have predetermined contact plans in order to operate and cannot cope with opportunistic contacts CCSDS Fall 2009 Meeting 10/13

  15. Work-in-Progress • Evaluation of Fragmentation and Bundle-size performance • Design and implementation of an efficient DTN routing • scheme, using parameters such as • Resource availability • Custody requirements • Foreign agency assets exploitation • Implementation of an advanced Kinematics module • Dynamic adjustment of link characteristics, based on real planet and satellite trajectories, random solar storms etc. CCSDS Fall 2009 Meeting 11/13

  16. Suggestion Test functionality – prove it is operational Test efficiency – custody, fragmentation, routing Test efficiency – when others fail.

More Related