Search NASA⌕ Search

SEARCH · Search NASA

Results for “forward link data services”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3

TechEdSat-11: Prototyping Autonomous Communications in Orbit

Cognitive Engine 1 (CE-1) is a state-of-the-art automated system designed to manage routine operations and respond to adverse events without requiring human operator input. CE-1 will optimize scheduling capabilities, detect and react to link failures, and ensure data delivery deadlines are met efficiently. Seamless roaming between government and commercial providers will allow for a robust and cost-effective network. TechEdSat-11 will demonstrate two key components of CE-1: User Initiated Services (UIS) and Delay Tolerant Networking (DTN). The first phase of the experiment will use UIS to automate on-demand scheduling of a commercial S-band ground station. Later phases of the experiment will demonstrate DTN store-and-forward and space internetworking capabilities through the TechEdSat-11 S-band radio. This paper will discuss the CE-1 main components relevant to the experiment, the flight and ground software architecture, experiment concept of operations and preliminary results.

Rachel Dudukovich↗

Implementing Strategic Planning Capabilities Within the Mars Relay Operations Service

Since the Mars Exploration Rovers (MER), Spirit and Opportunity, began their travels across the Martian surface in January of 2004, orbiting spacecraft such as the Mars 2001 Odyssey orbiter have relayed the majority of their collected scientific and operational data to and from Earth. From the beginning of those missions, it was evident that using orbiters to relay data to and from the surface of Mars was a vastly more efficient communications strategy in terms of power consumption and bandwidth compared to direct-to-Earth means. However, the coordination between the various spacecraft, which are largely managed independently and on differing commanding timelines, has always proven to be a challenge. Until recently, the ground operators of all these spacecraft have coordinated the movement of data through this network using a collection of ad hoc human interfaces and various, independent software tools. The Mars Relay Operations Service (MaROS) has been developed to manage the evolving needs of the Mars relay network, and specifically to standardize and integrate the relay planning and coordination data into a centralized infrastructure. This paper explores the journey of developing the MaROS system, from inception to delivery and acceptance by the Mars mission users.

tactical planning↗

Mars Interoperability 2008-2015: Options for Relay Orbiter Support to Mars Bound Assets

The current relay orbiter infrastructure at Mars, in support of the user assets presently at Mars and those scheduled for the 2008 to 2015 time frame, only have a need to store-and-forward the returned data collected by an asset to Earth as a single non-prioritized data file. In the forward direction, the relay orbiters are only required to relay the forward link data, i.e., command sequences, software and configuration information assembled on the ground, to the Asset. There are currently no requirements for status/control messages or files to be sent in the return direction from an Asset to an application located on the Relay, nor are there requirements in the forward direction to send status/control messages or files originating on a Relay to an Asset. In addition there are currently no networking requirements at Mars where data originally sent by an Asset is to be delivered to another user asset. However, we foresee the day when standard services for 1) on-board file prioritization of user asset data by a Relay, 2) control/status message transfer between assets and a Relay, and 3) networking between assets i.e., Asset to Asset message/file transfer via a Relay will be required. Each of these services will require the Relay to be capable of understanding the data type and routing needs of the user asset data and be capable of processing it for these purposes. This paper will focus on the innovative enhancements required to the existing communications infrastructure at Mars to enable these future services.

File Transfer↗

Security Analysis of DTN Architecture and Bundle Protocol Specification for Space-Based Networks

A Delay-Tolerant Network (DTN) Architecture (Request for Comment, RFC-4838) and Bundle Protocol Specification, RFC-5050, have been proposed for space and terrestrial networks. Additional security specifications have been provided via the Bundle Security Specification (currently a work in progress as an Internet Research Task Force internet-draft) and, for link-layer protocols applicable to Space networks, the Licklider Transport Protocol Security Extensions. This document provides a security analysis of the current DTN RFCs and proposed security related internet drafts with a focus on space-based communication networks, which is a rather restricted subset of DTN networks. Note, the original focus and motivation of DTN work was for the Interplanetary Internet . This document does not address general store-and-forward network overlays, just the current work being done by the Internet Research Task Force (IRTF) and the Consultative Committee for Space Data Systems (CCSDS) Space Internetworking Services Area (SIS) - DTN working group under the DTN and Bundle umbrellas. However, much of the analysis is relevant to general store-and-forward overlays.

Ivancic, William D.↗

Space Link Extension Protocol Emulation for High-Throughput, High-Latency Network Connections

New space missions require higher data rates and new protocols to meet these requirements. These high data rate space communication links push the limitations of not only the space communication links, but of the ground communication networks and protocols which forward user data to remote ground stations (GS) for transmission. The Consultative Committee for Space Data Systems, (CCSDS) Space Link Extension (SLE) standard protocol is one protocol that has been proposed for use by the NASA Space Network (SN) Ground Segment Sustainment (SGSS) program. New protocol implementations must be carefully tested to ensure that they provide the required functionality, especially because of the remote nature of spacecraft. The SLE protocol standard has been tested in the NASA Glenn Research Center's SCENIC Emulation Lab in order to observe its operation under realistic network delay conditions. More specifically, the delay between then NASA Integrated Services Network (NISN) and spacecraft has been emulated. The round trip time (RTT) delay for the continental NISN network has been shown to be up to 120ms; as such the SLE protocol was tested with network delays ranging from 0ms to 200ms. Both a base network condition and an SLE connection were tested with these RTT delays, and the reaction of both network tests to the delay conditions were recorded. Throughput for both of these links was set at 1.2Gbps. The results will show that, in the presence of realistic network delay, the SLE link throughput is significantly reduced while the base network throughput however remained at the 1.2Gbps specification. The decrease in SLE throughput has been attributed to the implementation's use of blocking calls. The decrease in throughput is not acceptable for high data rate links, as the link requires constant data a flow in order for spacecraft and ground radios to stay synchronized, unless significant data is queued a the ground station. In cases where queuing the data is not an option, such as during real time transmissions, the SLE implementation cannot support high data rate communication.

Computer Networking↗

TDRSS performance evaluation for TDRSS services using analytical simulation

An analytical simulation package which can predict bit error rate and tracking performance for nonlinear, bandlimited satellite links was developed for the Tracking and Data Relay Satellite System (TDRSS). It is based on analytical simulation, i.e., a combination of simulation techniques and analytical performance evaluation. This allows the use of a more realistic signal format than is possible with a purely analytical approach and maintains the advantage of short computation time on bandlimited, nonlinear channels with a noisy uplink. The link models and the main features of the program are described and an overview of the mathematical approach is given. Sample results of computer runs are provided for current power budgets and system design parameters for both forward and return links.

Braun, W. R.↗

Payload Performance of Third Generation TDRS and Future Services

NASA has accepted two of the 3rd generation Tracking and Data Relay Satellites, TDRS K, L, and M, designed and built by Boeing Defense, Space & Security (DSS). TDRS K, L, and M provide S-band Multiple Access (MA) service and S-band, Ku-band and Ka-band Single Access (SA) services to near Earth orbiting satellites. The TDRS KLM satellites offer improved services relative to the 1st generation TDRS spacecraft, such as: an enhanced MA service featuring increased EIRPs and G/T; and Ka-band SA capability which provides a 225 and 650 MHz return service (customer-to-TDRS direction) bandwidth and a 50 MHz forward service (TDRS-to-customer direction) bandwidth. MA services are provided through a 15 element forward phased array that forms up to two beams with onboard active beamforming and a 32 element return phased array supported by ground-based beamforming. SA services are provided through two 4.6m tri-band reflector antennas which support program track pointing and autotrack pointing. Prior to NASAs acceptance of the satellites, payload on-orbit testing was performed on each satellite to determine on-orbit compliance with design requirements. Performance parameters evaluated include: EIRP, G/T, antenna gain patterns, SA antenna autotrack performance, and radiometric tracking performance. On-orbit antenna calibration and pointing optimization was also performed on the MA and SA antennas including 24 hour duration tests to characterize and calibrate out diurnal effects. Bit-Error-Rate (BER) tests were performed to evaluate the end-to-end link BER performance of service through a TDRS K and L spacecraft. The TDRS M is planned to be launched in August 2017. This paper summarizes the results of the TDRS KL communications payload on-orbit performance verification and end-to-end service characterization and compares the results with the performance of the 2nd generation TDRS J. The paper also provides a high-level overview of an optical communications application that will augment the data rates supported by the Space Network.

RF↗

Payload Performance of TDRS KL and Future Services

NASA has accepted two of the 3nd generation Tracking and Data Relay Satellites, TDRS K, L, and M, designed and built by Boeing Defense, Space Security (DSS). TDRS K, L, and M provide S-band Multiple Access (MA) service and S-band, Ku-band and Ka-band Single Access (SA) services to near Earth orbiting satellites. The TDRS KLM satellites offer improved services relative to the 1st generation TDRS spacecraft, such as: an enhanced MA service featuring increased EIRPs and GT; and Ka-band SA capability which provides a 225 and 650 MHz return service (customer-to-TDRS direction) bandwidth and a 50 MHz forward service (TDRS-to-customer direction) bandwidth. MA services are provided through a 15 element forward phased array that forms up to two beams with onboard active beamforming and a 32 element return phased array supported by ground-based beamforming. SA services are provided through two 4.6m tri-band reflector antennas which support program track pointing and autotrack pointing. Prior to NASAs acceptance of the satellites, payload on-orbit testing was performed on each satellite to determine on-orbit compliance with design requirements. Performance parameters evaluated include: EIRP, GT, antenna gain patterns, SA antenna autotrack performance, and radiometric tracking performance. On-orbit antenna calibration and pointing optimization was also performed on the MA and SA antennas including 24 hour duration tests to characterize and calibrate out diurnal effects. Bit-Error-Rate (BER) tests were performed to evaluate the end-to-end link BER performance of service through a TDRS K and L spacecraft. The TDRS M is planned to be launched in August 2017. This paper summarizes the results of the TDRS KL communications payload on-orbit performance verification and end-to-end service characterization and compares the results with the performance of the 2nd generation TDRS J. The paper also provides a high-level overview of an optical communications application that will augment the data rates supported by the Space Network.

Laser↗

Considerations for Isochronous Data Services over the Proximity-1 Space Link

Future mission concepts for robotic and human explorations will involve a high level of real time control/monitoring operations such as tele-operation for spacecraft rendezvous and surface mobile platforms carrying life-support equipments. The timely dissemination of voice, command, and real-time telemetry for monitoring and coordination purposes is critical for mission success. It is envisioned that future missions will require a network infrastructure capable of supporting isochronous data services. The CCSDS Proximity-1 Space Link Protocol1 could be used to carry isochronous traffic. This paper we will focus on the data link layer portion of the Proximity-1 protocol specification and analyze its jitter and performance for supporting isochronous applications. In particular we will focus on constrained scenarios where the protocol operates in full-duplex mode, carrying isochronous traffic in one direction and error-controlled traffic in the other direction. We analyze the impact of the strict priority scheme in Proximity-1 used to arbitrate channel access on the latency jitter of the isochronous traffic and the efficiency of the reliable data transfer. In general, jitter performance is driven by the loading of the acknowledgement traffic on the forward link. Under light loading condition, the upper-bound of the delay jitter is the transmission duration of an acknowledgement frame on the forward link; for higher loading scenarios, the maximum jitter is scaled up by the inverse of the residual bandwidth, i.e., the spare capacity available in the forward link after accounting for the acknowledgement traffic. We derive analytical expression on the maximum jitter and discuss its performance.

space link↗

Simulation Modeling and Performance Evaluation of Space Networks

In space exploration missions, the coordinated use of spacecraft as communication relays increases the efficiency of the endeavors. To conduct trade-off studies of the performance and resource usage of different communication protocols and network designs, JPL designed a comprehensive extendable tool, the Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE). The design and development of MACHETE began in 2000 and is constantly evolving. Currently, MACHETE contains Consultative Committee for Space Data Systems (CCSDS) protocol standards such as Proximity-1, Advanced Orbiting Systems (AOS), Packet Telemetry/Telecommand, Space Communications Protocol Specification (SCPS), and the CCSDS File Delivery Protocol (CFDP). MACHETE uses the Aerospace Corporation s Satellite Orbital Analysis Program (SOAP) to generate the orbital geometry information and contact opportunities. Matlab scripts provide the link characteristics. At the core of MACHETE is a discrete event simulator, QualNet. Delay Tolerant Networking (DTN) is an end-to-end architecture providing communication in and/or through highly stressed networking environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, the DTN protocols reside at the application layer of the constituent internets, forming a store-and-forward overlay network. The key capabilities of the bundling protocols include custody-based reliability, ability to cope with intermittent connectivity, ability to take advantage of scheduled and opportunistic connectivity, and late binding of names to addresses. In this presentation, we report on the addition of MACHETE models needed to support DTN, namely: the Bundle Protocol (BP) model. To illustrate the use of MACHETE with the additional DTN model, we provide an example simulation to benchmark its performance. We demonstrate the use of the DTN protocol and discuss statistics gathered concerning the total time needed to simulate numerous bundle transmissions

network protocols↗

Demand access communications for TDRSS users

The Tracking and Data Relay Satellite System (TDRSS) has long been used to provide reliable low and high-data rate relay services between user spacecraft in Earth orbit and the ground. To date, these TDRSS services have been implemented via prior scheduling based upon estimates of user needs and mission event timelines. While this approach may be necessary for large users that require greater amounts of TDRSS resources, TDRSS can potentially offer the planned community of smaller science missions (e.g., the small explorer missions), and other emerging users, the unique opportunity for services on demand. In particular, innovative application of the existing TDRSS Multiple Access (MA) subsystem, with its phased array antenna, could be used to implement true demand access services without modification to either the TDRSS satellites or the user transponder, thereby introducing operational and performance benefits to both the user community and the Space Network. In this paper, candidate implementations of demand access service via the TDRSS MA subsystem are examined in detail. Both forward and return link services are addressed and a combination of qualitative and quantitative assessments are provided. The paper also identifies further areas for investigation in this ongoing activity that is being conducted by GSFC/Code 531 under the NASA Code O Advanced Systems Program.

Zillig, David↗

An Implementation Analysis of Communications, Navigation, and Surveillance (CNS) Technologies for Unmanned Air Systems (UAS)

The aviation industry and government agencies face a rapidly-emerging need for integrating large-scale populations of Unmanned Air Systems (UAS) into the worldwide controlled and uncontrolled airspace. Critical components for integration include the Communications, Navigation, and Surveillance (CNS) technologies necessary for ensuring safe UAS operations. Under NASA program NNA16BD84C, our work on CNS architectural concepts for the safe operation of UAS in controlled and uncontrolled airspace has introduced CNS architectures which must be analyzed in terms of implementation readiness.Controlled airspace operations for UAS are consistent with the needs for manned aviation in the worldwide Air Traffic Management (ATM) service. Uncontrolled airspace operations are consistent with the NASA Unmanned (air) Traffic Management (UTM) concept of operations. Implementation readiness is based on the NASA concept of Technology Readiness Levels (TRLs) ranging from TRL1 (basic principles observed and reported) to TRL9 (actual system flight proven through successful mission operations). In the architecture concepts, we have introduced a number of new CNS architectural elements which need to be correlated with TRL levels.In this paper, we present our implementation analysis for communications networks, communications data links, navigation, and surveillance. Each area has been under active research and development during the course of the current NASA program which has produced studies on UAS CNS Requirements, UAS CNS Architecture for Controlled Airspace and UAS CNS Architecture for Uncontrolled Airspace. We have published our architecture concepts in major UAS-related conferences (including iCNS2017, IEEE Aerospace 2018, and iCNS2018) and will continue to seek additional publication opportunities. We look forward to continuing our work to realize a full integration testing scenario for both controlled and uncontrolled airspace operation.

Ponchak, Denise↗

Use of CCSDS and OSI Protocols on the Advanced Communications Technology Satellite

Although ACTS (Advanced Communications Technology Satellite) provides an almost error-free channel during much of the day and under most conditions, there are times when it is not suitable for reliably error-free data communications when operating in the uncoded mode. Because coded operation is not always available to every earth station, measures must be taken in the end system to maintain adequate throughput when transferring data under adverse conditions. The most effective approach that we tested to improve performance was the addition of an 'outer' Reed-Solomon code through use of CCSDS (Consultative Committee for Space Data Systems) GOS 2 (a forward error correcting code). This addition can benefit all users of an ACTS channel including those applications that do not require totally reliable transport, but it is somewhat expensive because additional hardware is needed. Although we could not characterize the link noise statistically (it appeared to resemble uncorrelated white noise, the type that block codes are least effective in correcting), we did find that CCSDS GOS 2 gave an essentially error-free link at BER's (bit error rate) as high as 6x10(exp -4). For users that demand reliable transport, an ARQ (Automatic Repeat Queuing) protocol such as TCP (Transmission Control Protocol) or TP4 (Transport Protocol, Class 4) will probably be used. In this category, it comes as no surprise that the best choice of the protocol suites tested over ACTS was TP4 using CCSDS GOS 2. TP4 behaves very well over an error-free link which GOS 2 provides up to a point. Without forward error correction, however, TP4 service begins to degrade in the 10(exp -7)-10(exp -6) range and by 4x10(exp -6), it barely gives any throughput at all. If Congestion Avoidance is used in TP4, the degradation is even more pronounced. Fortunately, as demonstrated here, this effect can be more than compensated for by choosing the Selective Acknowledgment option. In fact, this option can enable TP4 to deliver some throughput at error rates as high as 10(exp -5).

Chirieleison, Don↗

Development of the ISS EMU SPEEDR

The Self Powered EVA EMU Data Recorder (SPEEDR) is an FPGA (Field-programmable gate array) based device designed to collect high-rate EMU (Extravehicular Mobility Unit) PLSS (Primary Life Support Subsystem) data for download at a later time. The existing EMU PLSS data down-link capability during EVA is one data packet every 2 minutes and is subject to bad packets or loss of signal. High-rate PLSS data is generated by the ECWS (Enhanced Caution and Warning System) but is not normally captured or distributed. Access to high-rate data will increase the capability of EMU anomaly resolution team to pinpoint issues remotely, saving crew time by reducing required call-down Q&A and on-orbit diagnostic activities. With no Shuttle flights post FY11, and potentially limited down-mass capability, the ISS crew and ground support personnel will have to be capable of on-orbit operations to maintain, diagnose, repair, and return to service EMU hardware, possibly through 2028. Collecting high-rate EMU PLSS data during both IVA (Intravehicular Activity) and EVA (Extravehicular Activity) operations will provide trending analysis for life extension and/or predictive performance. The SPEEDR concept has generated interest as a tool/technology that could be used for other ISS subsystems or future exploration-class space suits where hardware reliability/availability is critical and low/variable bandwidth may require "store then forward" methodology. Preliminary work in FY11 produced a functional prototype consisting of an FPGA evaluation board, custom memory/interface circuit board, and custom software. The SPEEDR concept includes a stand-alone battery that is recharged by a computer USB (Universal Serial Bus) port while data is being downloaded.

Bernard. Craig↗

Remote Asynchronous Message Service Gateway

The Remote Asynchronous Message Service (RAMS) gateway is a special-purpose AMS application node that enables exchange of AMS messages between nodes residing in different AMS "continua," notionally in different geographical locations. JPL s implementation of RAMS gateway functionality is integrated with the ION (Interplanetary Overlay Network) implementation of the DTN (Delay-Tolerant Networking) bundle protocol, and with JPL s implementation of AMS itself. RAMS protocol data units are encapsulated in ION bundles and are forwarded to the neighboring RAMS gateways identified in the source gateway s AMS management information base. Each RAMS gateway has interfaces in two communication environments: the AMS message space it serves, and the RAMS network - the grid or tree of mutually aware RAMS gateways - that enables AMS messages produced in one message space to be forwarded to other message spaces of the same venture. Each gateway opens persistent, private RAMS network communication channels to the RAMS gateways of other message spaces for the same venture, in other continua. The interconnected RAMS gateways use these communication channels to forward message petition assertions and cancellations among themselves. Each RAMS gateway subscribes locally to all subjects that are of interest in any of the linked message spaces. On receiving its copy of a message on any of these subjects, the RAMS gateway node uses the RAMS network to forward the message to every other RAMS gateway whose message space contains at least one node that has subscribed to messages on that subject. On receiving a message via the RAMS network from some other RAMS gateway, the RAMS gateway node forwards the message to all subscribers in its own message space.

Wang, Shin-Ywan↗

A Lunar Communications and Navigation Satellite Concept for the Robotic Lunar Exploration Program

The Second Robotic Lunar Exploration Program (RLEP) mission has two primary objectives. Broadly stated, they are "To See the Light" and "To Touch the Ice", meaning one mission objective is to survey the lighting conditions on the rim of a candidate crater over the course of a year, and the second objective is to descend into th.! s crater to search for water ice. The Space Communications Program Office at NASA/GSFC is supporting the RLEP-2 Project by developing a communications and navigation architecture for the mission. The primary candidate crater studied is the Shackleton Crater near the South Pole of the Moon. The rim of this crater has approximately 14 contiguous days of visibility to the Earth over the course of a month, while mission elements in the crater have no line of sight to either the Earth or potentially an element on the rim of the crater. One solution studied is to launch a relay spacecraft with RLEP-2 to provide communications and navigation services to the elements on the lunar surface. To support operations concepts requiring long duration contacts between the relay and the elements in the crater, an inclined elliptical orbit originally conceived by Todd Ely a t JPL was chosen for the relay. The orbit was adjusted to lower the maximum range while maintaining its "frozen" nature, meaning once placed in this orbit little delta-V is required for orbit maintenance. The orbital parameters were adjusted such that the relay has visibility into the crater for approximately 8.7 hours of the 12 hour orbital period. The relay satellite design draws heavily upon heritage concepts and hardware to achieve a very low risk implementation. The design concept is a 3-axis spacecraft that is capable of supporting return communication links from multiple surface elements concurrently through a four-element S-Band Multiple Access phased array with two forward links provided through single dedicated elements. The payload is a bent-pipe relay with beamforming performed on the ground (Earth). To mitigate concerns with multipath observed during Mars missions, the preliminary design employs PN-spread signal structures which have been used successfully by Tracking and Data Relay Satellite System (TDRSS) users for simultaneous real-time and recorded data playback. Details of the relay communication trade studies and rationale for the selected design elements are discussed in the paper.

Gramling, Jeffrey J.↗

Optical Communications Systems for NASA's Human Space Flight Missions

The Laser-Enhanced Mission Communications Navigation and Operational Services (LEMNOS) office at Goddard Space Flight Center (GSFC) manages two NASA optical communication related projects, the Orion EM-2 Optical Communications Terminal (O2O) and the Integrated Laser Communications Relay Demonstration (LCRD) Low-Earth Orbit (LEO) User Modem and Amplifier Terminal (ILLUMA-T) projects. The main goal of LEMNOS is the advancement and implementation of optical communications systems and technologies for NASA missions. The O2O mission is sponsored by NASA's Human Exploration and Operations (HEO) Mission Directorate. The O2O project will provide optical communications capability to the Orion series of spacecraft, starting with the demonstration of operational utility on EM-2. It will be the first time a human exploration mission will rely on optical communications for its high-bandwidth link. ILLUMA-T is sponsored by the Space Communications and Navigation (SCaN) Program Office. It is destined for the International Space Station (ISS) as an external payload attached to the Japanese Experiment Module - Exposed Facility (JEM-EF). The ILLUMA-T project is developing an optical communications user terminal to demonstrate high bandwidth data transfer between LEO and the ground through the geosynchronous LCRD relay. ILLUMA-T will be the first demonstration of a LEO user of the LCRD system, pointing and tracking from a moving spacecraft at LEO to GEO satellite and vice versa, end-to-end operational utility of optical communications, and 51 Mbps forward link to ISS from ground. Both projects are collaborations between GSFC, Massachusetts Institute of Technology â€" Lincoln Laboratory (MIT-LL), and a number of contractors.

Lasercom↗

Optical Communications Systems for NASA's Human Space Flight Missions

The Laser-Enhanced Mission Communications Navigation and Operational Services (LEMNOS) office at Goddard Space Flight Center (GSFC) manages two NASA optical communication related projects, the Orion EM-2 Optical Communications Terminal (O2O) and the Integrated Laser Communications Relay Demonstration (LCRD) Low-Earth Orbit (LEO) User Modem and Amplifier Terminal (ILLUMA-T) projects. The main goal of LEMNOS is the advancement and implementation of optical communications systems and technologies for NASA missions. The O2O mission is sponsored by NASA's Human Exploration and Operations (HEO) Mission Directorate. The O2O project will provide optical communications capability to the Orion series of spacecraft, starting with the demonstration of operational utility on EM-2. It will be the first time a human exploration mission will rely on optical communications for its high-bandwidth link. ILLUMA-T is sponsored by the Space Communications and Navigation (SCaN) Program Office. It is destined for the International Space Station (ISS) as an external payload attached to the Japanese Experiment Module - Exposed Facility (JEM-EF). The ILLUMA-T project is developing an optical communications user terminal to demonstrate high bandwidth data transfer between LEO and the ground through the geosynchronous LCRD relay. ILLUMA-T will be the first demonstration of a LEO user of the LCRD system, pointing and tracking from a moving spacecraft at LEO to GEO satellite and vice versa, end-to-end operational utility of optical communications, and 51 Mbps forward link to ISS from ground. Both projects are collaborations between GSFC, Massachusetts Institute of Technology-Lincoln Laboratory (MIT-LL), and a number of contractors.

Laser Communications↗