Lunar Surface DTN Scenarios

DTN-1

29/10/09

LunarElectric

Rover

LunarRelay

Satellite Flight Controlle

rs

Lunar Communicatio

nsTerminal

S-Band/Ka-Band

S-Band/Ka-BandIP

S-Ba

nd/K

a-Ba

nd

GroundNetworks

DTN LSS Scenarios: Assets & Links

Surface link

LunarElectric

Rover

EVAEVA

Data Flow: DEN vs. Local

DTN-3

ATHLETE(JPL)

LRS(GSFC)

EVA(GRC)

LER(JSC)

MCT(GSFC)

HAB(JSC)

GN(GSFC)

LER(JSC)

EVA(GRC)

LCT(GSFC)

MCC(JSC)

DEN

Local

Orion(JSC)

Altair(JSC)

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:– 1st number = LSS scenario– 2nd number = data type

1. motion imagery2. Audio3. file transfer4. Telemetry5. command & control

– 3rd number = data source1. Habitat2. Rover3. Lander4. EVA5. Depot

– 4th number = scenario number (1, 2, 3, …)

DTN-4

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

DTN.LSS.8.1.2.1: Rover/EVA Motion ImageryOverview

• 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

disruptions2. 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 camera4. 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

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

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

Motion Imagery Data Flow: Notional

DTN-9

Motion Imagery Data FlowRover 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 H.264

PCTLER LRS MCCGS

BP Tunnel App

BP

IP

UDP

RF

ETH

AOS

Encap

BP Tunnel App

IP

Motion Imagery Data FlowEVA 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 MCCGS

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

Rover Motion Imagery DTN Test Demonstration

Surface/Infrastructure Element Demonstration Element Location

Rover Chariot JSC

HDTV camera

Cisco 4500 HDTV IP camera JSCH.264 encoder

Packetizer

HD recorder TBD JSC

Radio 802.11 & 802.16 JSC

EVA TBD GRC

HDTV Camera TBD GRC

H.264 encoder TBD GRC

Packetizer TBD GRC

Radio 802.11 radio GRC

Lunar surface communications node 802.16 base stations (multiple vendors) JSC/GRC

Portable Communications Terminal 802.16 & 802.11 & router, CSTL GSFC

Lunar Relay Satellite CSTL GSFC

Orion ESTL JSC

Ground Systems CSTL GSFC

Flight Controllers Mission Control Center Flight Control Room (FCR) JSC

De-packetizerEnvivio 4Caster HD30 JSC

H.264 decoder

HDTV display Mission Control Center Flight Control Room (FCR) JSC

129/10/09

DTN.LSS.8.2.2.1: Rover/EVA AudioOverview

• 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 disruptions2. 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 member4. 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

DTN.LSS.8.1.2.1: Rover/EVA AudioOperations 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

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

Audio Data Flow: Notional

DTN-16

Audio Data FlowRover 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

PCTLER LRS MCCGS

BP Tunnel App

BP

IP

UDP

RF

ETH

AOS

Encap

BP Tunnel App

IP

DTN-17

Audio Data FlowEVA 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 MCCGS

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

Rover Audio DTN Test Demonstration

Surface/Infrastructure Element Demonstration Element Location

Rover LER JSC

Microphone/Speaker

Cisco IP phone JSCG.729 encoder

Packetizer

Audio recorder TBD JSC

Radio 802.11 & 802.16 JSC

EVA TBD GRC

Microphone/Speaker TBD GRC

G.729 encoder TBD GRC

Packetizer TBD GRC

Radio 802.11 radio GRC

Lunar surface communications node 802.16 base stations (multiple vendors) JSC/GRC

Portable Communications Terminal 802.16 & 802.11 & router GSFC

Lunar Relay Satellite CSTL GSFC

Orion ESTL JSC

Ground Systems CSTL GSFC

Flight Controllers Mission Control Center Flight Control Room (FCR) JSC

De-packetizer

Cisco IP phone JSCH.264 decoder

Microphone/Speaker

199/10/09

DTN.LSS.*.4.4.1: EVA Biomedical DataOverview

• 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 disruptions2. Monitor crew health during EVA3. 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

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

EVA ECG Data Flow: Notional

DTN-22

ECG Data FlowEVA Communications Stack Diagram

DTN-23

PCT LRS MCCGS

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 ETH

DTN.LSS.4.4.2.1: Navigation/LocalizationOverview

• 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 disruptions2. 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

DTN.LSS.4.2.1: Navigation/Localization

DTN-25

DTN.LSS.4.2.1: Navigation/LocalizationOperations 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

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

DTN.LSS.4.4.1.1: Wireless Sensor NetworkOverview

• 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

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

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

Wireless Sensor Network Data Flow (Notional)

DTN-31

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 MCCGS

BP Tunnel App

BP

IP

UDP

RF

ETH

AOS

Encap

IP

Sensor data (APP Layer

Habitat/SPR/µHab

BP

802.16

IP

UDPIP

802.15

BP Tunnel App

802.15

Wireless

HART/ISA100.11a

Sensor data

(APP Layer)

Wireless Sensor Network DTN Test Demonstration

Surface/Infrastructure Element Demonstration Element Location

Pressurized Volume

Habitat JSC

LER/SPR JSC

ATHLETE/µHab JPL

Sensor nodes, gateways WirelessHART/ISA100.11a sensor network test bed hardware JSC

Lunar surface communications node 802.16 base stations (multiple vendors) JSC/GRC

Portable Communications Terminal 802.16 & 802.11 & router, CSTL GSFC

Lunar Relay Satellite TDRSS GSFC

Orion ESTL JSC

Ground Systems CSTL GSFC

Flight Controllers Mission Control Center Flight Control Room (FCR) JSC

339/10/09

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

DTN.LSS.4.4.1.2: RFID InventoryOperations 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

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

RFID Inventory System Data Flow (Notional)

DTN-37

RFID Inventory System Data FlowCommunications Stack Diagram

DTN-38

PCT LRS MCCGS

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 ETH

Habitat/SPR/µHab

Wireless Sensor Network DTN Test Demonstration

Surface/Infrastructure Element Demonstration Element Location

Pressurized Volume

Habitat JSC

LER/SPR JSC

ATHLETE/µHab JSC

RFID tags & Interrogators TBD JSC

Lunar surface communications node 802.16 base stations (multiple vendors) JSC/GRC

Portable Communications Terminal 802.16 & 802.11 & router, CSTL GSFC

Lunar Relay Satellite TDRSS GSFC

Orion ESTL JSC

Ground Systems CSTL GSFC

Flight Controllers Mission Control Center Flight Control Room (FCR) JSC

399/10/09