1. UMass DieselNet: A Disruption-Tolerant Network Testbed John Burgess Department of Computer Science UMass Amherst John Burgess Department of Computer Science UMass Amherst

2. DieselNet Vehicular DTN deployed in Amherst and surrounding county Now includes 40 buses Each bus: Linux “brick” computer; USB 802.11b adapter; 802.11b AP; GPS receiver, 40GB hard drive Buses transfer data as they pass by each other and via available hot spots.

3. The Openbrick Small form factor Plentiful I/O Binary availability for x86 60w peak power draw Low heat dissipation

4. DieselNet Software Considerations  Autonomous operation and “shutdown”  Maximal failure tolerance  No remote administrator login or local terminal  Physical inaccessibility during operation (6am - 1am)  Nodes versus support staff  Handle network interface configurations  Support IP programs  Handle bundle routing  Support DTN programs  Autonomous operation and “shutdown”  Maximal failure tolerance  No remote administrator login or local terminal  Physical inaccessibility during operation (6am - 1am)  Nodes versus support staff  Handle network interface configurations  Support IP programs  Handle bundle routing  Support DTN programs

5. Init and Restore  Linux and initial software stored on 1st partition  All DTN software, logs, bundles, cached web content, etc. stored on 2nd partition  Restore checks for the presence of critical files  If any critical files are inaccessible  Clear extended partition  Restore initial software package from system disk  Otherwise, Init starts system software  Linux and initial software stored on 1st partition  All DTN software, logs, bundles, cached web content, etc. stored on 2nd partition  Restore checks for the presence of critical files  If any critical files are inaccessible  Clear extended partition  Restore initial software package from system disk  Otherwise, Init starts system software 1GB hdc139GB hdc5

6. Autoupdate  Install new software  Check for new gzip files on prisms web site  Verify prisms signature  Install update atomically  Sync system clock with server  Report current location  Report log entries  Connection events  Program error messages  Upload files  Bzip file, MIME encode it, and upload via HTTP request header  Install new software  Check for new gzip files on prisms web site  Verify prisms signature  Install update atomically  Sync system clock with server  Report current location  Report log entries  Connection events  Program error messages  Upload files  Bzip file, MIME encode it, and upload via HTTP request header

7. LiveIP  Manage network interfaces  802.11b  Scan for ssid broadcasts on all channels  Connect to other buses  Hash foreign bus MAC address to determine subnet  Connect to access points  DHCP  Ping foreign device to decide when to resume scanning  Reload 802.11 driver to clear malfunctions  Additional interfaces to be managed  900mhz long-range radio (1km)  CDMA modem  Manage network interfaces  802.11b  Scan for ssid broadcasts on all channels  Connect to other buses  Hash foreign bus MAC address to determine subnet  Connect to access points  DHCP  Ping foreign device to decide when to resume scanning  Reload 802.11 driver to clear malfunctions  Additional interfaces to be managed  900mhz long-range radio (1km)  CDMA modem

8. GPSupdate  Receive NMEA formatted information via RS232  Compute speed, direction, etc.  Periodically log location  Provide location information to onboard programs  Receive NMEA formatted information via RS232  Compute speed, direction, etc.  Periodically log location  Provide location information to onboard programs

9. DTNdaemon  Accept data and send bundles  via local TCP socket  Route bundles according to configured protocol  MaxProp  Deliver data to appropriate onboard programs  Programs connect via TCP socket  Programs register as appropriate destination application  Platform and IP network interface independent  Java implementation with no external dependencies  DTN2 2004 bundle format compatibility  Accept data and send bundles  via local TCP socket  Route bundles according to configured protocol  MaxProp  Deliver data to appropriate onboard programs  Programs connect via TCP socket  Programs register as appropriate destination application  Platform and IP network interface independent  Java implementation with no external dependencies  DTN2 2004 bundle format compatibility

10. Software Components  Init and Restore  Perl and Python  Auto update  Python  Live IP  Java 1.4  GPS update  Python  DTN daemon  Java 1.4 and linux-only Java 1.3  Init and Restore  Perl and Python  Auto update  Python  Live IP  Java 1.4  GPS update  Python  DTN daemon  Java 1.4 and linux-only Java 1.3

11. Connection Events  Red dots indicate bus-to-bus transfers (1 month)  Measurement of real TCP throughput  Traces collected everyday  Red dots indicate bus-to-bus transfers (1 month)  Measurement of real TCP throughput  Traces collected everyday

12. Measurements Buses log their status via available access points (and update software). Transfer duration Inter-transfer opportunity time Bytes transferred

13. Future Work  Deploy different DTN routing protocols  Develop useful disruption tolerant applications  Expand network to include other types of nodes  Deploy different DTN routing protocols  Develop useful disruption tolerant applications  Expand network to include other types of nodes

14. Summary  DieselNet is a DTN Testbed deployed on public transportation busses  Network inaccessibility often corresponds to physical inaccessibility, making DTN administration difficult  DTN system administration must be accomplished in a disruption-tolerant manner  Current above-IP DTN solutions must handle configuration of IP, Link, and physical network  Future solutions running above the link layer will still need to configure the link and physical layer  DieselNet is a DTN Testbed deployed on public transportation busses  Network inaccessibility often corresponds to physical inaccessibility, making DTN administration difficult  DTN system administration must be accomplished in a disruption-tolerant manner  Current above-IP DTN solutions must handle configuration of IP, Link, and physical network  Future solutions running above the link layer will still need to configure the link and physical layer