1. Lunar Surface DTN Scenarios DTN-1

2. 2 9/10/09 Lunar Electric Rover Lunar Relay Satellite Flight Controllers Lunar Communications Terminal S-Band/Ka-Band IP S-Band/Ka-Band Ground Networks DTN LSS Scenarios: Assets & Links Surface link Lunar Electric Rover EVA

3. Data Flow: DEN vs. Local DTN-3 ATHLETE (JPL) ATHLETE (JPL) LRS (GSFC) LRS (GSFC) EVA (GRC) EVA (GRC) LER (JSC) LER (JSC) MCT (GSFC) MCT (GSFC) HAB (JSC) HAB (JSC) GN (GSFC) GN (GSFC) LER (JSC) LER (JSC) EVA (GRC) EVA (GRC) LCT (GSFC) LCT (GSFC) MCC (JSC) MCC (JSC) DEN Local Orion (JSC) Orion (JSC) Altair (JSC) Altair (JSC)

4. DTN LSS Scenarios Test DTN under a variety of LSS scenarios and elements –Focusing on scenarios 4 (architecture robustness) and 8 (extreme mobility) for first cut –Elements: Altair, Lunar Electric Rover, ATHLETE, EVA, Habitat, Lunar Communications Terminal, Portable Communications Terminal, Lunar Relay Satellite, Orion, Ground Systems, Mission Systems Scenario numbering: –1 st number = LSS scenario –2 nd number = data type 1.motion imagery 2.Audio 3.file transfer 4.Telemetry 5.command & control –3 rd number = data source 1. Habitat 2. Rover 3. Lander 4. EVA 5. Depot –4 th number = scenario number (1, 2, 3, …) DTN-4

5. LSS DTN Scenarios Rover/EVA Motion Imagery (DTN.LSS.8.1.2.1) –High data rate Rover/EVA Audio (DTN.LSS.8.2.2.1) –Low data rate EVA Biomedical Telemetry (DTN.LSS.*.4.4.1) –Low data rate Navigation and Location Estimation (DTN.LSS.4.4.2.1) –Very low data rate Wireless Sensor Network (DTN.LSS.4.4.1.1) –Low Data Rate Inventory Management and Asset Tracking (DTN.LSS.4.4.1.2) –Very low data rate DTN-5

6. DTN.LSS.8.1.2.1: Rover/EVA Motion Imagery Overview Reference: LSS scenarios 8.0.0 & 8.1.0 Extreme Mobility Data Type: Motion imagery Stakeholders: –End User: Mission Systems (MS), Habitat, NASA PAO –Providers: LSS, rover, habitat, LCT, LRS, Orion, EVA –Analog Providers: LER, Wireless Habitat Testbed, ATHLETE/µHab, PCT analog, EVA pressure garment, CSTL (GSFC), ESTL (JSC), MCC (JSC) Objectives: 1.Transfer imagery from rover or EVA to MS via DTN-enabled communications link with link disruptions 2.Evaluate operations impacts of stored motion imagery vs. near-real time (when end-to-end link is available) How do we prioritize real-time or near-real time imagery over stored imagery? 3.Real-time streaming of imagery from “prime” rover HD camera 4.Store all HD images and forward as the channel permits Expected Benefits –Alleviate demands on channel data rates, thus reducing LSS cost and probably schedule Optimize link utilization –Motion imagery streaming during intermittent links –Increase average throughput –Retain images that otherwise might be lost 6

7. DTN.LSS.8.1.2.1: Rover/EVA Motion Imagery Operations Concept 6-8 HD cameras mounted on each rover –1 camera per rover selected as “primary”, others “secondary” Rover operators will switch between cameras while driving Second rover may swap motion imagery with first rover Ground operators will select camera(s) for downlink to Earth –Front camera for navigation and hazard avoidance Need to know where EVA is with respect to rover – no vehicle-pedestrian accidents –Side cameras for situational awareness –Minimum 1 motion imagery stream while under way –All motion imagery stored locally for later forwarding 1-2 cameras per EVA –Camera selectable by EVA crew member DTN-7

8. DTN.LSS.81.2.1: Issues/Forward Work DTN Capabilities Required/Issues –Data rate: ~5-21 Mbps per HDTV video channel (4-20 Mbps video + 1 Mbps overhead) Can this be supported by lunar surface communications link, or do we need to start with standard definition video? How many cameras can we simultaneously support with existing video equipment? –Application integration with respect to lunar surface communications – how do we get encoded video into a bundle? HD-SDI/HDMI or IP is easiest from camera POV UDP tunnel could be used for initial “quick & dirty” testing; inefficient use of bandwidth Long-term solution would likely require custom encoder/packetizer in conjunction with DTN node –Characterize link drops Disruption, disconnection, delay –LOS blockage, multipath Intermittent, length of drop, fading, etc. Initial standard definition video sent BP-over-IP between JPL and JSC –No store-and-forward capability Forward Work –Upgrade to HDTV –Add store-and-forward DTN-8

9. Motion Imagery Data Flow: Notional DTN-9

10. Motion Imagery Data Flow Rover Communications Stack Diagram DTN-10 BP 802.16 IP UDP IP UDP AOS Encap RF IP RTP ETH MPEG-2 TS BP IP UDP AOS Encap RF IP UDP RF AOS Encap RTP BP 802.16 MPEG-2 TS IP UDP H.264 PCT LER LRS MCC GS BP Tunnel App BP IP UDP RF ETH AOS Encap BP Tunnel App IP

11. Motion Imagery Data Flow EVA Communications Stack Diagram DTN-11 BP 802.16 IP UDP IP UDP AOS Encap RF PCT BP IP UDP AOS Encap RF IP UDP RF AOS Encap LRS MCC GS BP Tunnel App BP IP UDP RF ETH AOS Encap EVA IP RTP 802.11 MPEG-2 TS H.264 LER BP 802.16 IP UDP IP RTP 802.11 MPEG-2 TS H.264 ETH IP RTP MPEG-2 TS H.264 BP Tunnel App IP

12. Rover Motion Imagery DTN Test Demonstration Surface/Infrastructure ElementDemonstration ElementLocation RoverChariotJSC HDTV camera Cisco 4500 HDTV IP cameraJSC H.264 encoder Packetizer HD recorderTBDJSC Radio802.11 & 802.16JSC EVATBDGRC HDTV CameraTBDGRC H.264 encoderTBDGRC PacketizerTBDGRC Radio802.11 radioGRC Lunar surface communications node802.16 base stations (multiple vendors)JSC/GRC Portable Communications Terminal802.16 & 802.11 & router, CSTLGSFC Lunar Relay SatelliteCSTLGSFC OrionESTLJSC Ground SystemsCSTLGSFC Flight ControllersMission Control Center Flight Control Room (FCR)JSC De-packetizer Envivio 4Caster HD30JSC H.264 decoder HDTV displayMission Control Center Flight Control Room (FCR)JSC 12 9/10/09

13. DTN.LSS.8.2.2.1: Rover/EVA Audio Overview Reference: LSS scenarios 8.0.0 & 8.1.0 Extreme Mobility Data Type: Audio Stakeholders: –End User: Mission Systems (MS), Habitat, NASA PAO –Providers: LSS, rover, habitat, LCT, LRS, Orion, EVA –Analog Providers: LER, Wireless Habitat Testbed, PCT analog, EVA pressure garment, CSTL (GSFC), ESTL (JSC), MCC Objectives: 1.Transfer audio between rover or EVA to MS via DTN-enabled communications link with link disruptions 2.Evaluate operations impacts of stored audio vs. near-real time (when end-to-end link is available) How do we prioritize real-time or near-real time audio over stored audio? 3.Audio stream from each crew member 4.Store all audio and forward as the channel permits Expected Benefits –Alleviate demands on channel data rates, thus reducing LSS cost and probably schedule Optimize link utilization –Audio streaming during intermittent links –Increase average throughput –Retain audio that otherwise might be lost 13

14. DTN.LSS.8.1.2.1: Rover/EVA Audio Operations Concept Each crew member will have microphone/speaker combination, as well as MS/CAPCOM Each audio stream will be encoded via G.729 Crew members in local proximity need “continuous” communication Each rover needs to communicate with the other –Any requirement for rover to communicate directly with non-local EVA? CAPCOM needs to communicate with all crew members –Bi-directional audio traffic Audio streams may need to be encrypted Caution & Warning tones need to be routed to appropriate crew members –This may end up as “command” for local element to play pre-determined MP3 file –Will need to better define this sort of off-nominal scenario DTN-14

15. DTN.LSS.8.1.2.1: Issues/Forward Work DTN Capabilities Required/Issues –Data rate: ~21 kbps per audio channel (unencrypted), ~55 kbps encrypted (w/IPsec, TBD kbps w/link layer encryption) –Application integration with respect to lunar surface communications – how do we get encoded audio into a bundle? COTS VoIP phone with UDP tunnel could be used for initial “quick & dirty” testing; inefficient use of bandwidth Long-term solution would likely require custom encoder/packetizer in conjunction with DTN node –Characterize link drops Disruption, disconnection, delay –LOS blockage, multipath Intermittent, length of drop, fading, etc. Forward work –Integrate G.729 VoIP phone with DTN Builds off of motion imagery work DTN-15

16. Audio Data Flow: Notional DTN-16

17. Audio Data Flow Rover Communications Stack Diagram BP 802.16 IP UDP IP UDP AOS Encap RF IP RTP ETH G.729 BP IP UDP AOS Encap RF IP UDP RF AOS Encap IP RTP BP 802.16 G.729 IP UDP PCT LER LRS MCC GS BP Tunnel App BP IP UDP RF ETH AOS Encap BP Tunnel App IP DTN-17

18. Audio Data Flow EVA Communications Stack Diagram DTN-18 BP 802.16 IP UDP IP UDP AOS Encap RF PCT BP IP UDP AOS Encap RF IP UDP RF AOS Encap LRS MCC GS BP Tunnel App BP IP UDP RF ETH AOS Encap EVA IP RTP 802.11 G.729 LER BP 802.16 IP UDP IP RTP 802.11 G.729 ETH IP RTP G.729 BP Tunnel App IP

19. Rover Audio DTN Test Demonstration Surface/Infrastructure ElementDemonstration ElementLocation RoverLERJSC Microphone/Speaker Cisco IP phoneJSC G.729 encoder Packetizer Audio recorderTBDJSC Radio802.11 & 802.16JSC EVATBDGRC Microphone/SpeakerTBDGRC G.729 encoderTBDGRC PacketizerTBDGRC Radio802.11 radioGRC Lunar surface communications node802.16 base stations (multiple vendors)JSC/GRC Portable Communications Terminal802.16 & 802.11 & routerGSFC Lunar Relay SatelliteCSTLGSFC OrionESTLJSC Ground SystemsCSTLGSFC Flight ControllersMission Control Center Flight Control Room (FCR)JSC De-packetizer Cisco IP phoneJSC H.264 decoder Microphone/Speaker 19 9/10/09

20. DTN.LSS.*.4.4.1: EVA Biomedical Data Overview Reference: All LSS scenarios Data Type: Electrocardiogram (ECG) - telemetry Stakeholders: –End User: Mission Systems (MS), Habitat –Providers: EVA, Rover, LCT, LRS, Orion, MS –Analog Providers: LER, Wireless Habitat Testbed, PCT analog, EVA pressure garment, CSTL (GSFC) or ESTL (JSC), MCC Objectives: 1.Transfer ECG telemetry from EVA to MS via DTN-enabled communications link with link disruptions 2.Monitor crew health during EVA 3.Evaluate operations impacts of stored ECG vs. near-real time (when end-to-end link is available) How do we prioritize real-time or near-real time ECG over stored ECG? 4.Store all ECG telemetry and forward as the channel permits Expected Benefits –Better monitor crew health when end-to-end communications is not available –Archival of data that would otherwise be lost for overall health monitoring 20

21. DTN.LSS.4.4.1: Ops Concept and Variations EVA suit is wired with ECG and potentially other biomedical sensors Suit also generates telemetry that can be used to monitor crew health –consumables, temperature, pressure Estimated minimum of 25 kbps combined for biomed and suit telemetry Telemetry monitored by MS, habitat (scenario 4), and rover IVA crew (scenario 8) during EVA EVA could conceivably be cut short due to biomed or suit telemetry “Fresh” telemetry needs to be prioritized but all data needs to be sent to MS eventually Rover or habitat would act as relay and data storage most of the time Question: does suit have DTN node ? –Will have storage (voice, status, motion imagery) – recorder only or DTN -> TBD Some sort of store-and-forward likely for locally generated data No current plans to store-and-forward data from other suits or surface elements DTN-21

22. EVA ECG Data Flow: Notional DTN-22

23. ECG Data Flow EVA Communications Stack Diagram DTN-23 PCTLRSMCCGS BP 802.11 IP UDP IP UDP AOS Encap RF IP UDP ETH ECG BP IP UDP AOS Encap RF IP UDP RF AOS Encap BP 802.11 ECG IP UDP EVA BP IP TCP IP TCP ETH

24. DTN.LSS.4.4.2.1: Navigation/Localization Overview Reference: LSS scenarios 8.0.0 & 8.1.0 Extreme Mobility Data Type: Telemetry Stakeholders: –End User: Mission Systems (MS), Habitat –Providers: LSS, LER, ATHLETE, habitat, LCT, LRS, Orion –Analog Providers: LER, Wireless Habitat Testbed, ATHLETE, CSTL (GSFC), ESTL (JSC), MCC (JSC) Objectives: 1.Transfer rover (LER or ATHLETE) position in local habitat area (~ 1600 m LOS) via DTN-enabled communications link with link disruptions 2.Evaluate operations impacts of stored position vs. near-real time (when end-to-end link is available) Expected Benefits –Increase average throughput –Use DTN to “backfill” historical positions for increased situational awareness or to support search & rescue operations 24

25. DTN.LSS.4.2.1: Navigation/Localization DTN-25

26. DTN.LSS.4.2.1: Navigation/Localization Operations Concept LER and/or ATHLETE outfitted with UWB transmitters Surveyed UWB receivers around habitat perimeter establish baseline Time-of-Arrival used to estimate element (LER, ATHLETE) locations Position estimates sent from habitat to LER, ATHLETE, and MCC Alternate Concept LER and/or ATHLETE outfitted with UWB receivers Surveyed UWB transmitters around habitat perimeter establish baseline Time-of-Arrival used to estimate element location Position estimates sent from element to habitat Position estimates sent from habitat to MCC Ties into localization/asset tracking scenario to give operator location of rover and all surface assets in reference to rover location DTN-26

27. DTN.LSS.4.2.1: Navigation/Localization Forward Work DTN Capabilities Required/Issues –Data rate: < 1Kbps –Application integration completed Still need to integrate display with localization/asset tracking display –Ready for DEN testing DTN-27

28. DTN.LSS.4.4.1.1: Wireless Sensor Network Overview Reference: LSS scenarios 4.0.0 Data Type: telemetry & C2 Stakeholders: –End User: Mission Systems (MS), Habitat –Providers: LSS, habitat, LCT, LRS, Orion, Mission Systems –Analog Providers: LER/Small Pressurized Rover (SPR), Wireless Habitat Testbed, ATHLETE/µHab, PCT analog, (GSFC), ESTL (JSC), MCC Objectives: 1.Transfer data from wireless sensors on rover pressurized volumes (SPR or µHab), habitat, EVA, habitat proximity elements, or surface science packages to MS via DTN-enabled communications link with link disruptions 2.Evaluate tele-operation of habitat and rover systems using wireless sensors/actuators over channel with disruptions 3.Store all sensor data and forward as channel permits Expected Benefits –Alleviate demands on channel data rates, thus reducing LSS cost and probably schedule Optimize link utilization –Increase average throughput –Retain sensor data that might otherwise be lost 28

29. DTN.LSS.4.4.1.1: Wireless Sensor Network Operations Concept Wireless sensor/actuator nodes mounted in/around habitat –Some sensors generate data on a fixed schedule Environmental sensors (e.g., radiation, temperature) sample data continuously May be lower priority for DTN delivery with intermittent links –Some sensors generate event-driven data MMOD impact, leak detection sensors only report when critical event takes place May be higher priority for DTN delivery with intermittent links –Nodes can also respond to commands Configuration on sensor node can be changed in response to command issued remotely (e.g., sampling rate, method of data pre-processing) Actuators on nodes controlling habitat systems (e.g., air valves, thermostats) can be driven in response to commands issued remotely Priority for DTN delivery of commands will depend on criticality for DTN delivery with intermittent links DTN-29

30. DTN.LSS.4.4.1.1: Issues/Forward Work DTN Capabilities Required/Issues –Sensor data rate very low compared to other applications (e.g., video) How can this opportunistically be interleaved with higher-rate flows? Over what period should sensor data be aggregated into a bundle before shipping over DTN? How does application criticality affect this? How should different sensor data bundles be prioritized based on criticality of sensing/actuation application? –Characterize link drops Disruption, disconnection, delay –LOS blockage, multipath Intermittent, length of drop, fading, etc. DTN-30

31. Wireless Sensor Network Data Flow (Notional) DTN-31

32. Wireless Sensor Network Data Flow Rover Communications Stack Diagram DTN-32 BP 802.16 IP UDP IP UDP AOS Encap RF IP ETH BP IP UDP AOS Encap RF IP UDP RF AOS Encap PCT LRS MCC GS BP Tunnel App BP IP UDP RF ETH AOS Encap IP Sensor data (APP Layer Habitat/SPR/µHab BP 802.16 IP UDP IP 802.15 BP Tunnel App 802.15 Wireless HART/ ISA100. 11a Sensor data (APP Layer)

33. Wireless Sensor Network DTN Test Demonstration Surface/Infrastructure ElementDemonstration ElementLocation Pressurized Volume HabitatJSC LER/SPRJSC ATHLETE/µHabJPL Sensor nodes, gatewaysWirelessHART/ISA100.11a sensor network test bed hardwareJSC Lunar surface communications node802.16 base stations (multiple vendors)JSC/GRC Portable Communications Terminal802.16 & 802.11 & router, CSTLGSFC Lunar Relay SatelliteTDRSSGSFC OrionESTLJSC Ground SystemsCSTLGSFC Flight ControllersMission Control Center Flight Control Room (FCR)JSC 33 9/10/09

34. DTN.LSS.4.4.1.2: Inventory Management and Asset Tracking - Overview Reference: LSS scenario 4.0.0 Data Type: inventory tracking data (telemetry) Stakeholders: –End User: Mission Systems (MS), Habitat –Providers: LSS, habitat, LCT, LRS, Orion, Mission Systems –Analog Providers: LER, Wireless Habitat Testbed, ATHLETE/µHab, PCT analog, (GSFC), ESTL (JSC), MCC Objectives: 1.Transfer data from RFID tags items within rover pressurized volumes (SPR or µHab), habitat, habitat proximity elements, or surface science packages to enable remote logistical tracking by MS via DTN- enabled communications link with link disruptions 2.Database synchronization across intermittently connected assets Expected Benefits –Improve crew time utilization –Reduced ground support 34

35. DTN.LSS.4.4.1.2: RFID Inventory Operations Concept RFID tags mounted on all portable crew equipment, food packages, consumables (e.g. medicine containers), etc. RFID interrogators mounted in habitable volume –Habitable volume coverage provides general location of items –“Smart shelves” detect removal of items –“Smart trash can” detects consumption of food via disposal of packaging materials External interrogators outside habitable volume –Lost item location (e.g. Apollo 16 dropped tool) –Geologic sample “bag & tag” Interrogators periodically determine location of inventory items and relay changes to inventory database both local crew inventory systems and MS inventory databases Tags can also provide environmental data to help determine if any items have been exposed to harmful environments DTN-35

36. DTN.LSS.4.4.1.2: Issues/Forward Work DTN Capabilities Required/Issues –Sensor data rate very low How can this opportunistically be interleaved with higher-rate flows? Over what period should sensor data be aggregated into a bundle before shipping over DTN? How does application criticality affect this? How should different sensor data bundles be prioritized based on criticality of sensing/actuation application? –Characterize link drops Disruption, disconnection, delay –LOS blockage, multipath Intermittent, length of drop, fading, etc. Forward work –Integration of data from RFID interrogators (hand held, smart shelf, smart trash can) into BioNet –Any data within BioNet is DTn-enabled DTN-36

37. RFID Inventory System Data Flow (Notional) DTN-37

38. RFID Inventory System Data Flow Communications Stack Diagram DTN-38 PCTLRSMCCGS BP 802.16 IP UDP IP UDP AOS Encap RF IP UDP ETH RFID tag BP IP UDP AOS Encap RF IP UDP RF AOS Encap BP 802.16 RFID tag IP UDP BP IP TCP IP TCP ETH Habitat/SPR/µHab

39. Wireless Sensor Network DTN Test Demonstration Surface/Infrastructure ElementDemonstration ElementLocation Pressurized Volume HabitatJSC LER/SPRJSC ATHLETE/µHabJSC RFID tags & InterrogatorsTBDJSC Lunar surface communications node802.16 base stations (multiple vendors)JSC/GRC Portable Communications Terminal802.16 & 802.11 & router, CSTLGSFC Lunar Relay SatelliteTDRSSGSFC OrionESTLJSC Ground SystemsCSTLGSFC Flight ControllersMission Control Center Flight Control Room (FCR)JSC 39 9/10/09