SEARCH · Search NASA

Results for “Network Time Protocol”

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.

SourceResearch connectionFrom yearThrough year

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

At least 289 records · Page 16

All sources NASA NTRS DOE OSTI

NASA NTRS1991

An overview of SAFENET and its implications for aerospace applications

The survivable, adaptable fiber optic embeddable network (SAFENET) is a draft standard for local area networking (LAN) developed by the Navy which, when adopted, will become a military standard. The standard is being developed for procurement specifications of computer resources to be used on ships and aircraft and has some of the real-time concerns that network standards for space vehicles have. Architecture and survivability are considered. It is noted that the token-ring LAN must implement the IEEE 802.5 recommended practice for dual ring reconfiguration, which is currently being reviewed for inclusion into the IEEE standard. A trunk coupling unit is used at each station to isolate a station from the ring in case of failure. Up to five stations can be bypassed in this fashion. Communication architecture has an OSI profile but differs from the standard concept of the seven layers by allowing alternate suits and breaking the layers into three groupings of services to allow for physical interfacing. It also provides several paths, even if only one profile is used. Management and synchronization protocols are discussed and security issues are addressed. Implications for aerospace applications are considered and it is projected that interoperability with the Navy and other U.S. Government systems may require SAFENET specifications for NASA systems.

Collins, George C.↗

NASA NTRS1993

System services and architecture of the TMI satellite mobile data system

The North American Mobile Satellite Service (MSS) system being developed by AMSC/TMI and scheduled to go into service in early 1995 will include the provision for real time packet switched services (mobile data service - MDS) and circuit switched services (mobile telephony service - MTS). These services will utilize geostationary satellites which provide access to mobile terminals (MT's) through L-band beams. The MDS system utilizes a star topology with a centralized data hub (DH) and will support a large number of mobile terminals. The DH, which accesses the satellite via a single Ku band beam, is responsible for satellite resource management, for providing mobile users with access to public and private data networks, and for comprehensive network management of the system. This paper describes the various MDS services available for the users, the ground segment elements involved in the provisioning of these services, and a summary description of the channel types, protocol architecture, and network management capabilities provided within the system.

Gokhale, D.↗

NASA NTRS2008

Web-Enabled Optoelectronic Particle-Fallout Monitor

A Web-enabled optoelectronic particle- fallout monitor has been developed as a prototype of future such instruments that (l) would be installed in multiple locations for which assurance of cleanliness is required and (2) could be interrogated and controlled in nearly real time by multiple remote users. Like prior particle-fallout monitors, this instrument provides a measure of particles that accumulate on a surface as an indication of the quantity of airborne particulate contaminants. The design of this instrument reflects requirements to: Reduce the cost and complexity of its optoelectronic sensory subsystem relative to those of prior optoelectronic particle fallout monitors while maintaining or improving capabilities; Use existing network and office computers for distributed display and control; Derive electric power for the instrument from a computer network, a wall outlet, or a battery; Provide for Web-based retrieval and analysis of measurement data and of a file containing such ancillary data as a log of command attempts at remote units; and Use the User Datagram Protocol (UDP) for maximum performance and minimal network overhead.

Lineberger, Lewis P.↗

NASA NTRS2016

Network Security via Biometric Recognition of Patterns of Gene Expression

Molecular biology provides the ability to implement forms of information and network security completely outside the bounds of legacy security protocols and algorithms. This paper addresses an approach which instantiates the power of gene expression for security. Molecular biology provides a rich source of gene expression and regulation mechanisms, which can be adopted to use in the information and electronic communication domains. Conventional security protocols are becoming increasingly vulnerable due to more intensive, highly capable attacks on the underlying mathematics of cryptography. Security protocols are being undermined by social engineering and substandard implementations by IT organizations. Molecular biology can provide countermeasures to these weak points with the current security approaches. Future advances in instruments for analyzing assays will also enable this protocol to advance from one of cryptographic algorithms to an integrated system of cryptographic algorithms and real-time expression and assay of gene expression products.

cybersecurity↗

NASA NTRS2003

Enhanced Multi-Modal Access to Planetary Exploration

Tomorrow's Interplanetary Network (IPN) will evolve from JPL's Deep-Space Network (DSN) and provide key capabilities to future investigators, such as simplified acquisition of higher-quality science at remote sites and enriched access to these sites. These capabilities could also be used to foster public interest, e.g., by making it possible for students to explore these environments personally, eventually perhaps interacting with a virtual world whose models could be populated by data obtained continuously from the IPN. Our paper looks at JPL's approach to making this evolution happen, starting from improved communications. Evolving space protocols (e.g., today's CCSDS proximity and file-transfer protocols) will provide the underpinning of such communications in the next decades, just as today's rich web was enabled by progress in Internet Protocols starting from the early 1970's (ARPAnet research). A key architectural thrust of this effort is to deploy persistent infrastructure incrementally, using a layered service model, where later higher-layer capabilities (such as adaptive science planning) are enabled by earlier lower-layer services (such as automated routing of object-based messages). In practice, there is also a mind shift needed from an engineering culture raised on point-to-point single-function communications (command uplink, telemetry downlink), to one in which assets are only indirectly accessed, via well-defined interfaces. We are aiming to foster a 'community of access' both among space assets and the humans who control them. This enables appropriate (perhaps eventually optimized) sharing of services and resources to the greater benefit of all participants. We envision such usage to be as automated in the future as using a cell phone is today - with all the steps in creating the real-time link being automated.

interplanetary network (IPN)↗

NASA NTRS2003

Flight Test Results from the Low Power Transceiver Communications and Navigation Demonstration on Shuttle (CANDOS)

The Low Power Transceiver (LPT) is an advanced signal processing platform that offers a configurable and reprogrammable capability for supporting communications, navigation and sensor functions for mission applications ranging from spacecraft TT&C and autonomous orbit determination to sophisticated networks that use crosslinks to support communications and real-time relative navigation for formation flying. The LPT is the result of extensive collaborative research under NASNGSFC s Advanced Technology Program and ITT Industries internal research and development efforts. Its modular, multi-channel design currently enables transmitting and receiving communication signals on L- or S-band frequencies and processing GPS L-band signals for precision navigation. The LPT flew as a part of the GSFC Hitchhiker payload named Fast Reaction Experiments Enabling Science Technology And Research (FREESTAR) on-board Space Shuttle Columbia s final mission. The experiment demonstrated functionality in GPS-based navigation and orbit determination, NASA STDN Ground Network communications, space relay communications via the NASA TDRSS, on-orbit reconfiguration of the software radio, the use of the Internet Protocol (IP) for TT&C, and communication concepts for space based range safety. All data from the experiment was recovered and, as a result, all primary and secondary objectives of the experiment were successful. This paper presents the results of the LPTs maiden space flight as a part of STS- 107.

Rush, John↗

NASA NTRS2015

Ethernet for Aerospace Applications - Ethernet Heads for the Skies

One of the goals of aerospace applications is to reduce the cost and complexity of avionic systems. Ethernet is a highly scalable, flexible, and popular protocol. The aerospace market is large, with a forecasted production of over 50,000 turbine-powered aircraft valued at $1.7 trillion between 2012 and 2022. Boeing estimates demand for commercial aircraft by 2033 to total over 36,000 with a value of over $5 trillion. In 2014 US airlines served over 750 million passengers and this is growing over 2% yearly. Electronic fly-by-wire is now used for all airliners and high performance aircraft. Although Ethernet has been widely used for four decades, its use in aerospace applications is just beginning to become common. Ethernet is the universal solution in commercial networks because of its high bandwidths, lower cost, openness, reliability, maintainability, flexibility, and interoperability. However, when Ethernet was designed applications with time-critical, safety relevant and deterministic requirements were not given much consideration. Many aerospace applications use a variety of communication architectures that add cost and complexity. Some of them are SpaceWire, MIL-STD-1553, Avionics Full Duplex Switched Ethernet (AFDX), and Time-Triggered Ethernet (TTE). Aerospace network designers desire to decrease the number of networks to reduce cost and effort while improving scalability, flexibility, openness, maintainability, and reliability. AFDX and TTE are being considered more for critical aerospace systems because they provide redundancy, failover protection, guaranteed timing, and frame priority and are based on Ethernet IEEE 802.3. This paper explores the use of AFDX and TTE for aerospace applications.

Ethernet↗

NASA NTRS2016

Network Security via Biometric Recognition of Patterns of Gene Expression

Molecular biology provides the ability to implement forms of information and network security completely outside the bounds of legacy security protocols and algorithms. This paper addresses an approach which instantiates the power of gene expression for security. Molecular biology provides a rich source of gene expression and regulation mechanisms, which can be adopted to use in the information and electronic communication domains. Conventional security protocols are becoming increasingly vulnerable due to more intensive, highly capable attacks on the underlying mathematics of cryptography. Security protocols are being undermined by social engineering and substandard implementations by IT (Information Technology) organizations. Molecular biology can provide countermeasures to these weak points with the current security approaches. Future advances in instruments for analyzing assays will also enable this protocol to advance from one of cryptographic algorithms to an integrated system of cryptographic algorithms and real-time assays of gene expression products.

cybersecurity↗

NASA NTRS2006

CCSDS Time-Critical Onboard Networking Service

The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.

Parkes, Steve↗

NASA NTRS2010

Enabling IP Header Compression in COTS Routers via Frame Relay on a Simplex Link

NASA is moving toward a networkcentric communications architecture and, in particular, is building toward use of Internet Protocol (IP) in space. The use of IP is motivated by its ubiquitous application in many communications networks and in available commercial off-the-shelf (COTS) technology. The Constellation Program intends to fit two or more voice (over IP) channels on both the forward link to, and the return link from, the Orion Crew Exploration Vehicle (CEV) during all mission phases. Efficient bandwidth utilization of the links is key for voice applications. In Voice over IP (VoIP), the IP packets are limited to small sizes to keep voice latency at a minimum. The common voice codec used in VoIP is G.729. This new algorithm produces voice audio at 8 kbps and in packets of 10-milliseconds duration. Constellation has designed the VoIP communications stack to use the combination of IP/UDP/RTP protocols where IP carries a 20-byte header, UDP (User Datagram Protocol) carries an 8-byte header, and RTP (Real Time Transport Protocol) carries a 12-byte header. The protocol headers total 40 bytes and are equal in length to a 40-byte G.729 payload, doubling the VoIP latency. Since much of the IP/UDP/RTP header information does not change from IP packet to IP packet, IP/UDP/RTP header compression can avoid transmission of much redundant data as well as reduce VoIP latency. The benefits of IP header compression are more pronounced at low data rate links such as the forward and return links during CEV launch. IP/UDP/RTP header compression codecs are well supported by many COTS routers. A common interface to the COTS routers is through frame relay. However, enabling IP header compression over frame relay, according to industry standard (Frame Relay IP Header Compression Agreement FRF.20), requires a duplex link and negotiations between the compressor router and the decompressor router. In Constellation, each forward to and return link from the CEV in space is treated independently as a simplex link. Without negotiation, the COTS routers are prevented from entering into the IP header compression mode, and no IP header compression would be performed. An algorithm is proposed to enable IP header compression in COTS routers on a simplex link with no negotiation or with a one-way messaging. In doing so, COTS routers can enter IP header compression mode without the need to handshake through a bidirectional link as required by FRF.20. This technique would spoof the routers locally and thereby allow the routers to enter into IP header compression mode without having the negotiations between routers actually occur. The spoofing function is conducted by a frame relay adapter (also COTS) with the capability to generate control messages according to the FRF.20 descriptions. Therefore, negotiation is actually performed between the FRF.20 adapter and the connecting COTS router locally and never occurs over the space link. Through understanding of the handshaking protocol described by FRF.20, the necessary FRF.20 negotiations messages can be generated to control the connecting router, not only to turn on IP header compression but also to adjust the compression parameters. The FRF.20 negotiation (or control) message is composed in the FRF.20 adapter by interpreting the incoming router request message. Many of the fields are simply transcribed from request to response while the control field indicating response and type are modified.

Nguyen, Sam P.↗

NASA NTRS1996

Gigabit Satellite Network for NASA's Advanced Communication Technology Satellite (ACTS)

The advanced communication technology satellite (ACTS) gigabit satellite network provides long-haul point-to-point and point-to-multipoint full-duplex SONET services over NASA's ACTS. at rates up to 622 Mbit/s (SONET OC-12), with signal quality comparable to that obtained with terrestrial fiber networks. Data multiplexing over the satellite is accomplished using time-division multiple access (TDMA) techniques coordinated with the switching and beam hopping facilities provided by ACTS. Transmissions through the satellite are protected with Reed-Solomon encoding. providing virtually error-free transmission under most weather conditions. Unique to the system are a TDMA frame structure and satellite synchronization mechanism that allow: (a) very efficient utilization of the satellite capacity: (b) over-the-satellite dosed-loop synchronization of the network in configurations with up to 64 ground stations: and (c) ground station initial acquisition without collisions with existing signalling or data traffic. The user interfaces are compatible with SONET standards, performing the function of conventional SONET multiplexers and. as such. can be: readily integrated with standard SONET fiber-based terrestrial networks. Management of the network is based upon the simple network management protocol (SNMP). and includes an over-the-satellite signalling network and backup terrestrial internet (IP-based) connectivity. A description of the ground stations is also included.

Hoder, Douglas↗

DOE OSTI2024

LEED: A Lightwave Energy-Efficient Datacenter

The Lightwave Energy-Efficient Datacenter (LEED) program is a disruptive “green-field” approach that provides a quantum leap in the energy efficiency of datacenters. LEED’s fundamental value proposition is that a novel and re-architected optical network—RotorNet— can deliver “more bandwidth per buck” as well as unique system-level attributes that significantly improve overall datacenter energy efficiency and performance. LEED has developed three system-level testbeds. The first testbed uses calibrated hardware and software power measurements to determine server energy efficiency as a function of network bandwidth and workload. These measurements have shown that increasing network communications bandwidth dramatically increases server energy efficiency providing a realistic path to the overall ENLITENED program goal of doubling the number of transactions per joule. The second testbed demonstrates key hardware: a prototype low-loss, high-port count optical “selector switch”. This switch was fabricated, racked, and tested. Measured switch characteristics include loss, bandwidth, crosstalk, switch time, system-level switch time (including the transceivers), and bit error rate. The third testbed demonstrates a fully working and manufactured pinwheel design which dramatically lowers the cost of design, while delivering high switch radix and low reconfiguration times. The LEED project has tied these three novel photonic switch prototypes together with production servers and software through the development of a novel FPGA-based NIC platform called Corundum. Corundum ensures that the packet-switched protocols supported by commodity operating systems and devices can interface with the Rotor switch design. The LEED group has used this combined hardware and software prototype to characterize applications running at a commercially relevant scale. The project has used a combination of enhanced optical modulation amplitude (OMA) modulators, broadband multiplexers and demultiplexers, avalanche photodiodes, and a novel burst-mode receivers to enable the insertion of LEED-developed optical switches without the need for expensive optical amplification. Our modeling has shown that measured LEED-developed device characteristics can achieve link characteristics of 2 pJ/bit including both transceivers and the Rotor switch. In summary, the LEED program has demonstrated a credible and practical path, through novel hardware and software, to realize the program objectives of ENLITENED. The net result will ensure that the United States maintains its strength in the crucial sector of Information Technology, which is vital to both our economic security and our national security.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

NASA NTRS1999

Performance Analysis of TCP Enhancements in Satellite Data Networks

This research examines two proposed enhancements to the well-known Transport Control Protocol (TCP) in the presence of noisy communication links. The Multiple Pipes protocol is an application-level adaptation of the standard TCP protocol, where several TCP links cooperate to transfer data. The Space Communication Protocol Standard - Transport Protocol (SCPS-TP) modifies TCP to optimize performance in a satellite environment. While SCPS-TP has inherent advantages that allow it to deliver data more rapidly than Multiple Pipes, the protocol, when optimized for operation in a high-error environment, is not compatible with legacy TCP systems, and requires changes to the TCP specification. This investigation determines the level of improvement offered by SCPS-TP's Corruption Mode, which will help determine if migration to the protocol is appropriate in different environments. As the percentage of corrupted packets approaches 5 %, Multiple Pipes can take over five times longer than SCPS-TP to deliver data. At high error rates, SCPS-TP's advantage is primarily caused by Multiple Pipes' use of congestion control algorithms. The lack of congestion control, however, limits the systems in which SCPS-TP can be effectively used.

Broyles, Ren H.↗

NASA NTRS2018

Advanced Utilization of the Payload Executive Processor (PEP) Ethernet Port to Support JSL Based Payloads

Increased interest by Payload Developers in utilization of the Joint Station LAN (Local Area Network) (JSL) for command and data transactions has driven the investigation of providing bi-directional Ethernet communication with PEP (Payload Executive Processor). Ethernet-only payload developers are interested in taking advantage of the services provided by PEP. Enabling Ethernet communications within PEP requires more than just turning on the hardware. PEP contains no Operating System (OS) or Ethernet stack so it does not inherit any built in functionality for Ethernet support. Both hardware drivers and application software must be developed from scratch. In the absence of an OS (Operating System) the design must address security issues in terms of access and data transferred, i.e. blocking unauthorized users and preventing denial of service. Developing a design to process Ethernet data within the existing real-time constraints of PEP requires a few compromises: data rates, supported protocols, custom packet format and limited client connections to name a few. Integration of the light weight internet protocol (LwIP). Ethernet stack provides a customizable solution for the embedded real-time environment. As utilization of the JSL increases, the successful implementation of an Ethernet interface enhances the utilization of PEP, and provides a new path for future Ethernet-only payloads to gain access to around the clock command and data services.

Guyette, Greg↗

DOE OSTI2025

Accelerating charge estimation in molecular dynamics simulations using physics-informed neural networks: corrosion applications

Molecular Dynamics (MD) simulations are used to understand the effects of corrosion on metallic materials in salt brine. Reactive force fields in classical MD enable accurate modeling of bond formation and breakage in the aqueous medium and at the metal-electrolyte interface, while also facilitating dynamic partial charge equilibration. However, MD simulations are computationally intensive and unsuitable for modeling the long time scales characteristic of corrosive phenomena. To address this, we develop reduced-order machine learning models that provide accurate and efficient predictions of charge density in corrosive environments. Specifically, we use Long Short-Term Memory (LSTM) networks to forecast charge density evolution based on atomic environments represented by Smooth Overlap of Atomic Positions (SOAP) descriptors. A physics-informed loss function enforces charge neutrality and electronegativity equivalence. The atomic charges predicted by the deep learning model trained on this work were obtained two orders of magnitude faster than those from molecular dynamics (MD) simulations, with an error of less than 3% compared to the MD-obtained charges, even in extrapolative scenarios, while adhering to physical constraints. This demonstrates the excellent accuracy, computational efficiency, and validity of the developed model. Lastly, even though developed for corrosion, these protocols are formulated in a phenomenon-agnostic manner, allowing application to various variable-charge interatomic potentials and related fields.

Atomistic models↗

NASA NTRS2023

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

NASA NTRS2024

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.3.0

Delay Tolerant Networking↗

NASA NTRSDate not supplied

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗