# Presentation: 416066

## Space-base DTN using a Commercially Operational  Low Earth Orbiting Satellite

## Satellite Communication 101 (or maybe 1.01)

- The United Kingdom -Disaster Monitoring Constellation (UK-DMC) satellite is an imaging satellite
- One of 5 (or 6 or 7 as constellation grows)
- Commercial Money Making Operation
*You* can request an image (and pay)
- Polar Orbit approximately once every 100 minutes
- Satellite is in view of any one ground station for 8 to 14 minutes – hence disruption.
- Round Trip Time Delay is ~ 100 msec, thus delay is not the issue here (unlike for deep space).

## UK-DMC Characteristic

- Onboard experimental Payload, Cisco router in Low Earth Orbit (CLEO)
-  Not Used for DTN Testing
- Three Solid State Data Recorders
- 1 with a StrongARM Processor
- 2 with Motorola MPC8260 PowerPC  (We use one of these)
- RTEMS operating system (POSIX API, BSD sockets)
- Storage Capacity 1 GByte RAM
- Operating System Image limit is 1 Mbyte
- Uplink is 9600 bits per second
- Downlink is 8.134 Mbps
- Datalink – Frame Relay/HDLC
- Network Protocol – IPv4 (could easily run IPv6)
- Transport Protocol (Saratoga version 0 over UDP)
- Saratoga version 0 is existing SSTL transport
- Saratoga version 1 is what is in the Internet Drafts
- Enhances version 0 to make it more widely usable

## Costs

- If DTN code upload DOES NOT disrupt SSTL normal operations
***$Y US*** per pass to SSTL
- If DTN code upload disrupts SSTL normal operations
- Approximately ***10 times $Y US*** per 24 hours
- For general use, UK-DMC
- Satellite cost is ***$Y US*** per pass
- If one uses other ground stations such as Universal Space Networks (USN), cost is:
***$Y US*** per pass to SSTL
-  approximately $700 per pass to USN

**Thus, Ground-based Testing is extremely Important.**

## DTN Testbed

- Spirent
- (Adtech)
- SX/14
- Channel
- Emulator

**Sx/14**
**Channel**
**Emulator**

- 3640
- Configured as
- Frame Relay
- Switch

- Emulated
- Ground Router
- Network A

- DTN Source
- Cisco
- Engineering
- Model
- SSDR

- 3640
- Configured as
- Frame Relay
- Switch

- 8 Mbps

- 9600 bps

- Clock
- Source

- Clock
- Sink

- DCE

- DTE     DCE

- DCE      DTE

- DCE

**DCE  West**

**DTE  East**

- Null Modem Cable
- (Both Systems Supply Clock)

- Channel Timing:
- from DTE & DCE

**2-Port**
**Serial**
**Switch**

- Emulated
- Ground Router
- Network B

- DCE

- SIGMA and
- DTN
- Sink

**DTN Testbed**

**Channel Emulation**

## Number of Possible Tests per Pass

| Description | Units |   |   |   |   |   |
| --- | --- | --- | --- | --- | --- | --- |
| Pass time | min | 8 | 9 | 10 | 11 | 12 |
| Pass time | seconds | 480 | 540 | 600 | 660 | 720 |
| Image Size (Mbytes) | Mbytes | 160 | 160 | 160 | 160 | 160 |
| Fragment Size (Mbytes) | Mbytes | 80 | 80 | 80 | 80 | 80 |
| Number of Fragments | GCI | 2 | 2 | 2 | 2 | 2 |
| Downlink Line Rate | Mbps | 8 | 8 | 8 | 8 | 8 |
| Test1: Saratoga full file Transfer Test | seconds | 160 | 160 | 160 | 160 | 160 |
| Test 2: DTN full Bundle Transfer | seconds | 160 | 160 | 160 | 160 | 160 |
| Test 3: Saratoga Proactive Fragmentation Transfer  | seconds | 160 | 160 | 160 | 160 | 160 |
| Number of Tests Completed |  | 3 | 3.375 | 3.75 | 4.125 | 4.5 |
| Number of bundles that can be transferred in test 3  |  | 2 | 2.75 | 3.5 | 4.25 | 5 |

## DTN Test Plan 

- Goal
- Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground Station
- Demonstrate that DTN code and general SSTL code can coexist without affecting normal SSTL Operations
- Reduces costs from  ***10 times $Y*** per 24 hours to ***$Y*** per pass
- Configuration
- UK-DMC acquired a150 Mbyte image over the Gulf of Khambhat, India at ~04:35 UTC on 25 January 2008.
- DTN bundling code default set to 80 Mbytes for proactive fragmentation
- Tests
- Basic file download using existing technique (GRC implementation of Saratoga version 0)
- Same file downloaded but treated as single bundle (DTN)
- Same file download but using DTN proactive fragmentation with 80 Mbytes preconfigured fragments.
- SSTL used their Workstation and SSTL implementation of Saratoga version 0

## UK-DMC Implementation

- Only Bundling and Forwarding Implemented

- Full DTN Protocol Implemented

**SSTL **
**Saratoga **
**Client**

****** ****Test 4**

## Bundles on UK-DMC

****** ****70 - 80 bytes**

****** ****70 - 80 bytes**

****** ****70 bytes**

****** ****70 - 80 bytes**

**Not to Scale**

****** ****150 Mbytes**

**80 MB**

**70 MB**

## File Names

**Payload**

**DTN Metadata**

**Proactive Fragmentation **
**Metadata - 1 **

**Proactive Fragmentation **
**Metadata - 0 **

**DU000c76pm**

****** ****DU000c76pm.0-79999999.dtn**

****** ****DU000c76pm.79999999-153700328.dtn**

****** ****DU000c76pm.dtn**

## DTN Test Results 

- Test 1 - Image file DU00076pm was received using GRC Saratoga version 0 implementation
- Test 2 - DTN file and associated metadata for the full bundle was received by Bundling-SSTL and then forwarded as a full bundle to Bundinging-GRC1
- Test 3 – Proactive Fragmentation:
- The 1st proactive fragmented bundle from the UK-DMC and it was automatically transferred using DTN-2 between Bundling-SSTL to Bundling-GRC1.
- The 2nd proactive fragmentation bundle was not retrieved
- The directory and the syslog file showed creation of the 1st fragmentation metadata file, but not the second.
- Analysis showed SSTL operating system limits file names to 32 characters.
- Test 4 – SSTL downloaded 150 Mbyte image cleanly
- Post Test analysis
- Reconstructed DTN bundle payload and image file (tests 1 and 2) did not match
- Bug found in GRC Saratoga Implementation of “Holes to fill” (we did not request retransmissions properly)

## Lessons Learned

- “Holes to fill” bug would have been caught with checksums (reliability check)
- Improve ground-based testing to hopefully avoid future problems
- Error generation was not turned on as BER system was out of the loop for a while during testbed debugging – one of a kind system is temperamental .... sometimes
- Time Synchronization is critical
- Test time synchronization of all DTN nodes prior to testing
- DTN expiration timer is 3 days
- Requires image to be taken within 3 days of download.
- Perhaps current DTN requirement for time synchronization should be reconsidered.
- Perhaps decrement time on hop-by-hop to avoid loops
- Perhaps time synchronization optional?
- Not all DTN nodes may be able to do time synchronization.

## How does DTN fit into a Low Earth Orbit Space Network? “Operationally Responsive Space”

**These slides have animation.  As such, they are available as MS PowerPoint at:**
**http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRTF-DTN.ppt**

## Secure Autonomous Integrated Controller for Distributed Sensor Webs

**VMOC**

**NOC**

**NOC**

**NOC**

**Secure Autonomous Integrated Controller ****for Distributed Sensor Webs**

## Open Internet

**Home**
**Agent**
**(GRC)**

**Battlefield Operations**
**(Vandenberg AFB)**

**Segovia NOC**

**2nd Ground Station**

**VMOC-2**
**(GRC)**

**SSTL**

**VMOC-1**

**Open Internet**

**VMOC**

**Database**

**Experiments**
**Workstation**

**Satellite**
**Scheduler**
**& Controller**

**Rate Mismatch**
**Problem**

**Desire is to buffer locally while in sight of the satellite  then redistribute to the VMOC**

- <<- Time <<-

**Large File Transfer**
**Over Multiple Ground Stations**
**- The Problem - **

**Ideal LARGE Image Transfer – Multiple Ground Stations**
**(New Capability – Application Being Developed)**

## Open Internet

**Home Agent**

**VMOC**

**Open Internet**

**VMOC**

**Database**

**Satellite**
**Scheduler**
**& Controller**

**Ground **
**Station 3**

**Ground **
**Station 2**

**Ground **
**Station 1**

- ->> Time ->>

**Large File Transfer**
**Over Multiple Ground Stations**
**- DTN is a Potential Solution - **

## Open Internet

**Home Agent**

**VMOC**

**Open Internet**

**VMOC**

**Database**

**Satellite**
**Scheduler**
**& Controller**

**Ground **
**Station 3**

**Ground **
**Station 2**

**Ground **
**Station 1**

- ->> Time ->>

**DTN Bundle Agent**
**Source**

**Combining Mobile-IP and DTN for File Upload**