1 / 39

Lunar Surface DTN Scenarios

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

nenet
Download Presentation

Lunar Surface DTN Scenarios

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. Lunar Surface DTN Scenarios

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

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

  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: • 1st number = LSS scenario • 2nd number = data type • motion imagery • Audio • file transfer • Telemetry • command & control • 3rd number = data source • Habitat • Rover • Lander • EVA • Depot • 4th number = scenario number (1, 2, 3, …)

  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

  6. 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: • Transfer imagery from rover or EVA to MS via DTN-enabled communications link with link disruptions • 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? • Real-time streaming of imagery from “prime” rover HD camera • 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

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

  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

  9. Motion Imagery Data Flow: Notional

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

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

  12. Rover Motion Imagery DTN Test Demonstration

  13. 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: • Transfer audio between rover or EVA to MS via DTN-enabled communications link with link disruptions • 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? • Audio stream from each crew member • 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

  14. 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

  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

  16. Audio Data Flow: Notional

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

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

  19. Rover Audio DTN Test Demonstration

  20. 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: • Transfer ECG telemetry from EVA to MS via DTN-enabled communications link with link disruptions • Monitor crew health during EVA • 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? • 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

  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

  22. EVA ECG Data Flow: Notional

  23. ECG Data FlowEVA Communications Stack Diagram PCT LRS GS MCC EVA ECG ECG BP BP UDP BP BP IP ETH TCP TCP UDP UDP UDP UDP UDP IP IP IP IP IP IP IP Encap Encap Encap ETH 802.11 ETH 802.11 AOS AOS AOS RF RF RF

  24. 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: • Transfer rover (LER or ATHLETE) position in local habitat area (~ 1600 m LOS) via DTN-enabled communications link with link disruptions • 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

  25. DTN.LSS.4.2.1: Navigation/Localization

  26. 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

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

  28. 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: • 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 • Evaluate tele-operation of habitat and rover systems using wireless sensors/actuators over channel with disruptions • 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

  29. DTN.LSS.4.4.1.1: Wireless Sensor NetworkOperations 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

  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.

  31. Wireless Sensor Network Data Flow (Notional)

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

  33. Wireless Sensor Network DTN Test Demonstration

  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: • 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 • Database synchronization across intermittently connected assets • Expected Benefits • Improve crew time utilization • Reduced ground support

  35. 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

  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

  37. RFID Inventory System Data Flow (Notional)

  38. RFID Inventory System Data FlowCommunications Stack Diagram PCT LRS GS MCC Habitat/SPR/µHab RFID tag RFID tag BP BP UDP BP BP IP ETH TCP TCP UDP UDP UDP UDP UDP IP IP IP IP IP IP IP Encap Encap Encap ETH 802.16 ETH 802.16 AOS AOS AOS RF RF RF

  39. Wireless Sensor Network DTN Test Demonstration

More Related