Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “routing protocols”

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.

125 records · Page 7
All sourcesNASA NTRSDOE OSTI
NASA NTRS1991

NSI directed to continue SPAN's functions

During a series of network management retreats in June and July 1990, representatives from NASA Headquarters Codes O and S agreed on networking roles and responsibilities for their respective organizations. The representatives decided that NASA Science Internet (NSI) will assume management of both the Space Physics Analysis Network (SPAN) and the NASA Science Network (NSN). SPAN is now known as the NSI/DECnet, and NSN is now known as the NSI/IP. Some management functions will be distributed between Ames Research Center (ARC) and Goddard Space Flight Center (GSFC). NSI at ARC has the lead role for requirements generation and networking engineering. Advanced Applications and the Network Information Center is being developed at GSFC. GSFC will lead the NSI User Services, but NSI at Ames will continue to provide the User Services during the transition. The transition will be made as transparent as possible for the users. DECnet service will continue, but is now directly managed by NSI at Ames. NSI will continue to work closely with routing center managers at other NASA centers, and has formed a transition team to address the change in management. An NSI/DECnet working group had also been formed as a separate engineering group within NSI to plan the transition to Phase 5, DECnet's approach to Open System Integration (OSI). Transition is not expected for a year or more due to delays in produce releases. Plans to upgrade speeds in tail circuits and the backbone are underway. The proposed baseline service for new connections is up to 56 Kbps; 9.6 Kbps lines will gradually be upgraded as requirements dictate. NSI is in the process of consolidating protocol traffic, tail circuits, and the backbone. Currently NSI's backbone is fractional T1; NSI will go to full T1 service as soon as it is feasible.

Rounds, Fred↗
NASA NTRS2016

Deploying a Route Optimization EFB Application for Commercial Airline Operational Trials

The Traffic Aware Planner (TAP), developed for NASA Langley Research Center to support the Traffic Aware Strategic Aircrew Requests (TASAR) project, is a flight-efficiency software application developed for an Electronic Flight Bag (EFB). Tested in two flight trials and planned for operational testing by two commercial airlines, TAP is a real-time trajectory optimization application that leverages connectivity with onboard avionics and broadband Internet sources to compute and recommend route modifications to flight crews to improve fuel and time performance. The application utilizes a wide range of data, including Automatic Dependent Surveillance Broadcast (ADS-B) traffic, Flight Management System (FMS) guidance and intent, on-board sensors, published winds and weather, and Special Use Airspace (SUA) schedules. This paper discusses the challenges of developing and deploying TAP to various EFB platforms, our solutions to some of these challenges, and lessons learned, to assist commercial software developers and hardware manufacturers in their efforts to implement and extend TAP functionality in their environments. EFB applications (such as TAP) typically access avionics data via an ARINC 834 Simple Text Avionics Protocol (STAP) server hosted by an Aircraft Interface Device (AID) or other installed hardware. While the protocol is standardized, the data sources, content, and transmission rates can vary from aircraft to aircraft. Additionally, the method of communicating with the AID may vary depending on EFB hardware and/or the availability of onboard networking services, such as Ethernet, WIFI, Bluetooth, or other mechanisms. EFBs with portable and installed components can be implemented using a variety of operating systems, and cockpits are increasingly incorporating tablet-based technologies, further expanding the number of platforms the application may need to support. Supporting multiple EFB platforms, AIDs, avionics datasets, and user interfaces presents a challenge for software developers and the management of their code baselines. Maintaining multiple baselines to support all deployment targets can be extremely cumbersome and expensive. Certification also needs to be considered when developing the application. Regardless of whether the software is itself destined to be certified, data requirements in support of the application and user interface elements may introduce certification requirements for EFB manufacturers and the airlines. The example of TAP, the challenges faced, solutions implemented, and lessons learned will give EFB application and hardware developers insight into future potential requirements in deploying TAP or similar flight-deck EFB applications.

Roscoe, David A.↗
NASA NTRS2011

Trajectory Assessment and Modification Tools for Next Generation Air Traffic Management Operations

This paper reviews three Next Generation Air Transportation System (NextGen) based high fidelity air traffic control human-in-the-loop (HITL) simulations, with a focus on the expected requirement of enhanced automated trajectory assessment and modification tools to support future air traffic flow management (ATFM) planning positions. The simulations were conducted at the National Aeronautics and Space Administration (NASA) Ames Research Centers Airspace Operations Laboratory (AOL) in 2009 and 2010. The test airspace for all three simulations assumed the mid-term NextGenEn-Route high altitude environment utilizing high altitude sectors from the Kansas City and Memphis Air Route Traffic Control Centers. Trajectory assessment, modification and coordination decision support tools were developed at the AOL in order to perform future ATFM tasks. Overall tool usage results and user acceptability ratings were collected across three areas of NextGen operatoins to evaluate the tools. In addition to the usefulness and usability feedback, feasibility issues, benefits, and future requirements were also addressed. Overall, the tool sets were rated very useful and usable, and many elements of the tools received high scores and were used frequently and successfully. Tool utilization results in all three HITLs showed both user and system benefits including better airspace throughput, reduced controller workload, and highly effective communication protocols in both full Data Comm and mixed-equipage environments.

Brasil, Connie↗
NASA NTRS2004

User-Friendly Interface Developed for a Web-Based Service for SpaceCAL Emulations

A team at the NASA Glenn Research Center is developing a Space Communications Architecture Laboratory (SpaceCAL) for protocol development activities for coordinated satellite missions. SpaceCAL will provide a multiuser, distributed system to emulate space-based Internet architectures, backbone networks, formation clusters, and constellations. As part of a new effort in 2003, building blocks are being defined for an open distributed system to make the satellite emulation test bed accessible through an Internet connection. The first step in creating a Web-based service to control the emulation remotely is providing a user-friendly interface for encoding the data into a well-formed and complete Extensible Markup Language (XML) document. XML provides coding that allows data to be transferred between dissimilar systems. Scenario specifications include control parameters, network routes, interface bandwidths, delay, and bit error rate. Specifications for all satellite, instruments, and ground stations in a given scenario are also included in the XML document. For the SpaceCAL emulation, the XML document can be created using XForms, a Webbased forms language for data collection. Contrary to older forms technology, the interactive user interface makes the science prevalent, not the data representation. Required versus optional input fields, default values, automatic calculations, data validation, and reuse will help researchers quickly and accurately define missions. XForms can apply any XML schema defined for the test mission to validate data before forwarding it to the emulation facility. New instrument definitions, facilities, and mission types can be added to the existing schema. The first prototype user interface incorporates components for interactive input and form processing. Internet address, data rate, and the location of the facility are implemented with basic form controls with default values provided for convenience and efficiency using basic XForms operations. Because different emulation scenarios will vary widely in their component structure, more complex operations are used to add and delete facilities.

Liszka, Kathy J.↗
NASA NTRS1994

Design of a cooperative problem-solving system for en-route flight planning: An empirical evaluation

Both optimization techniques and expert systems technologies are popular approaches for developing tools to assist in complex problem-solving tasks. Because of the underlying complexity of many such tasks, however, the models of the world implicitly or explicitly embedded in such tools are often incomplete and the problem-solving methods fallible. The result can be 'brittleness' in situations that were not anticipated by the system designers. To deal with this weakness, it has been suggested that 'cooperative' rather than 'automated' problem-solving systems be designed. Such cooperative systems are proposed to explicitly enhance the collaboration of the person (or a group of people) and the computer system. This study evaluates the impact of alternative design concepts on the performance of 30 airline pilots interacting with such a cooperative system designed to support enroute flight planning. The results clearly demonstrate that different system design concepts can strongly influence the cognitive processes and resultant performances of users. Based on think-aloud protocols, cognitive models are proposed to account for how features of the computer system interacted with specific types of scenarios to influence exploration and decision making by the pilots. The results are then used to develop recommendations for guiding the design of cooperative systems.

Layton, Charles↗
NASA NTRS2006

Lessons Learned from Daily Uplink Operations during the Deep Impact Mission

The daily preparation of uplink products (commands and files) for Deep Impact was as problematic as the final encounter images were spectacular. The operations team was faced with many challenges during the six-month mission to comet Tempel One of the biggest difficulties was that the Deep Impact Flyby and Impactor vehicles necessitated a high volume of uplink products while also utilizing a new uplink file transfer capability. The Jet Propulsion Laboratory (JPL) Multi-Mission Ground Systems and Services (MGSS) Mission Planning and Sequence Team (MPST) had the responsibility of preparing the uplink products for use on the two spacecraft. These responsibilities included processing nearly 15,000 flight products, modeling the states of the spacecraft during all activities for subsystem review, and ensuring that the proper commands and files were uplinked to the spacecraft. To guarantee this transpired and the health and safety of the two spacecraft were not jeopardized several new ground scripts and procedures were developed while the Deep Impact Flyby and Impactor spacecraft were en route to their encounter with Tempel-1. These scripts underwent several adaptations throughout the entire mission up until three days before the separation of the Flyby and Impactor vehicles. The problems presented by Deep Impact's daily operations and the development of scripts and procedures to ease those challenges resulted in several valuable lessons learned. These lessons are now being integrated into the design of current and future MGSS missions at JPL.

uplink↗
NASA NTRS2018

Use of Nack Oriented Reliable Multicast (NORM) Protocol for Transport of Spacecraft Telemetry in Ground Networks

Frequently it is necessary to distribute spacecraft telemetry to multiple destinations on Internet Protocol (IP) networks. There are various methods of delivering this data, but when the data is high rate and there are many destinations IP multicast provides the best solution from a network perspective. However, IP multicast only supports the User Datagram Protocol (UDP) which is connectionless and unreliable. This nature of UDP and by extension the low priority treatment of UDP packets by some network hardware creates a difficult environment for distribution of high rate telemetry to a number of recipients over IP networks. NACK (Negative ACKnowledgment) Oriented Reliable Multicast (NORM) is defined by IETF (Internet Engineering Task Force) RFC (Request for Comments) 5740 in 2009 by B. Adamson et al. NORM provides a mechanism of retransmission and or forward error correction for UDP packets, potentially overcoming the limits of UDP for the transmission of spacecraft telemetry. Marshall Space Flight Center’s (MSFC) Huntsville Operations Support Center (HOSC) manages the delivery of the International Space Station (ISS) payload science and health data. The ISS IP Ground Routed (IIGoR) network provides the delivery of the data from the ground stations to the control centers. HOSC personnel have been experimenting with the use of NORM on the link between the ground stations and the front end processor equipment in Huntsville, AL.

Baldwin, Patrick A.↗
NASA NTRS2009

Wireless Avionics Packet to Support Fault Tolerance for Flight Applications

In this protocol and packet format, data traffic is monitored by all network interfaces to determine the health of transmitter and subsystems. When failures are detected, the network inter face applies its recover y policies to provide continued service despite the presence of faults. The protocol, packet format, and inter face are independent of the data link technology used. The current demonstration system supports both commercial off-the-shelf wireless connections and wired Ethernet connections. Other technologies such as 1553 or serial data links can be used for the network backbone. The Wireless Avionics packet is divided into three parts: a header, a data payload, and a checksum. The header has the following components: magic number, version, quality of service, time to live, sending transceiver, function code, payload length, source Application Data Interface (ADI) address, destination ADI address, sending node address, target node address, and a sequence number. The magic number is used to identify WAV packets, and allows the packet format to be updated in the future. The quality of service field allows routing decisions to be made based on this value and can be used to route critical management data over a dedicated channel. The time to live value is used to discard misrouted packets while the source transceiver is updated at each hop. This information is used to monitor the health of each transceiver in the network. To identify the packet type, the function code is used. Besides having a regular data packet, the system supports diagnostic packets for fault detection and isolation. The payload length specifies the number of data bytes in the payload, and this supports variable-length packets in the network. The source ADI is the address of the originating interface. This can be used by the destination application to identify the originating source of the packet where the address consists of a subnet, subsystem class within the subnet, a subsystem unit, and the local ADI number. The destination ADI is used to route the packet to its ultimate destination. At each hop, the sending interface uses the destination address to determine the next node for the data. The sending node is the node address of the interface that is broadcasting the packet. This field is used to determine the health of the subsystem that is sending the packet. In the case of a packet that traverses several intermediate nodes, it may be the node address of the intermediate node. The target node is the node address of the next hop for the packet. It may be an intermediate node, or the final destination for the packet. The sequence number is used to identify duplicate packets. Because each interface has multiple transceivers, the same packet will appear at both receivers. The sequence number allows the interface to correlate the reception and forward a single, unique packet for additional processing. The subnet field allows data traffic to be partitioned into segregated local networks to support large networks while keeping each subnet at a manageable size. This also keeps the routing table small enough so routing can be done by a simple table lookup in an FPGA device. The subsystem class identifies members of a set of redundant subsystems, and, in a hot standby configuration, all members of the subsystem class will receive the data packets. Only the active subsystem will generate data traffic. Specific units in a class of redundant units can be identified and, if the hot standby configuration is not used, packets will be directed to a specific subsystem unit.

Block, Gary L.↗
NASA NTRS2016

Essential SpaceWire Hardware Capabilities for a Robust Network

The Geostationary Operational Environmental Satellite R-Series Program (GOES-R) mission is a joint program between National Oceanic & Atmospheric Administration (NOAA) and National Aeronautics & Space Administration (NASA) Goddard Space Flight Center (GSFC). GOES-R project selected SpaceWire as the best solution to satisfy the desire for simple and flexible instrument to spacecraft command and telemetry communications. GOES-R development and integration is complete and the observatory is scheduled for launch October 2016. The spacecraft design was required to support redundant SpaceWire links for each instrument side, as well as to route the fewest number of connections through a Slip Ring Assembly necessary to support Solar pointing instruments. The final design utilized two different router designs. The SpaceWire standard alone does not ensure the most practical or reliable network. On GOES-R a few key hardware capabilities were identified that merit serious consideration for future designs. Primarily these capabilities address persistent port stalls and the prevention of receive buffer overflows. Workarounds were necessary to overcome shortcomings that could be avoided in future designs if they utilize the capabilities, discussed in this paper, above and beyond the requirements of the SpaceWire standard.

SpaceWire↗
NASA NTRS1992

A domain-specific design architecture for composite material design and aircraft part redesign

Advanced composites have been targeted as a 'leapfrog' technology that would provide a unique global competitive position for U.S. industry. Composites are unique in the requirements for an integrated approach to designing, manufacturing, and marketing of products developed utilizing the new materials of construction. Numerous studies extending across the entire economic spectrum of the United States from aerospace to military to durable goods have identified composites as a 'key' technology. In general there have been two approaches to composite construction: build models of a given composite materials, then determine characteristics of the material via numerical simulation and empirical testing; and experience-directed construction of fabrication plans for building composites with given properties. The first route sets a goal to capture basic understanding of a device (the composite) by use of a rigorous mathematical model; the second attempts to capture the expertise about the process of fabricating a composite (to date) at a surface level typically expressed in a rule based system. From an AI perspective, these two research lines are attacking distinctly different problems, and both tracks have current limitations. The mathematical modeling approach has yielded a wealth of data but a large number of simplifying assumptions are needed to make numerical simulation tractable. Likewise, although surface level expertise about how to build a particular composite may yield important results, recent trends in the KBS area are towards augmenting surface level problem solving with deeper level knowledge. Many of the relative advantages of composites, e.g., the strength:weight ratio, is most prominent when the entire component is designed as a unitary piece. The bottleneck in undertaking such unitary design lies in the difficulty of the re-design task. Designing the fabrication protocols for a complex-shaped, thick section composite are currently very difficult. It is in fact this difficulty that our research will address.

Punch, W. F., III↗
NASA NTRS1995

Performance and policy dimensions in internet routing

The Internet Routing Project, referred to in this report as the 'Highball Project', has been investigating architectures suitable for networks spanning large geographic areas and capable of very high data rates. The Highball network architecture is based on a high speed crossbar switch and an adaptive, distributed, TDMA scheduling algorithm. The scheduling algorithm controls the instantaneous configuration and swell time of the switch, one of which is attached to each node. In order to send a single burst or a multi-burst packet, a reservation request is sent to all nodes. The scheduling algorithm then configures the switches immediately prior to the arrival of each burst, so it can be relayed immediately without requiring local storage. Reservations and housekeeping information are sent using a special broadcast-spanning-tree schedule. Progress to date in the Highball Project includes the design and testing of a suite of scheduling algorithms, construction of software reservation/scheduling simulators, and construction of a strawman hardware and software implementation. A prototype switch controller and timestamp generator have been completed and are in test. Detailed documentation on the algorithms, protocols and experiments conducted are given in various reports and papers published. Abstracts of this literature are included in the bibliography at the end of this report, which serves as an extended executive summary.

Mills, David L.↗
NASA NTRSDate not supplied

m:N ConOps/R&R Remote Simulation

This presentation details the experimental design of an investigation of small unmanned aircraft system (sUAS) operations involving multiple vehicle management by a remote operator. The study is part of an ongoing effort to explore multiple vehicle control by multiple operators, i.e., the control of N vehicles by m operators (m:N operations). For this effort, NASA and collaborators have developed prototypes of a concept of operations (ConOps), roles and responsibilities (R&R) for operators and supervisors, and a ground control station (GCS), including software displays and interfaces. Participants in this study acted as the pilot-in-command of twelve aircraft flying pre-approved routes in a simulation of a food delivery operation utilizing sUAS in the San Diego, CA area. Each participant experienced four experimental trials. Twice within the course of each trial, participants were responsible for responding to a sudden, unanticipated, and high-priority contingency: an airspace restriction for sUAS operations known as a UAS Volume Reservation (UVR). Upon issuance of a UVR, pilots were expected to reroute affected vehicles around the airspace. The level of automation (LoA) and workload of the flight rerouting task were varied. The LoA was manipulated by providing reroute suggestions ("auto" condition) for aircraft or by requiring pilots to manually reroute ("manual" condition) affected vehicles. Workload was varied as a function of the number of vehicles affected by the UVR contingencies: 2 vehicles ("low workload" condition) versus 4 vehicles ("high workload" condition). Additionally, some vehicles required pilots to adjust for terrain conflicts while avoiding the UVR region. Due to the COVID-19 pandemic, in-person data collection for this study was not possible. Researchers adapted to this circumstance through the development of remote data collection protocol. Participants were able to view adapted GCS displays using the Microsoft Teams teleconferencing platform and responded to events by using a verbal protocol developed for the experiment. Using this protocol, participants provided instructions for actions to a researcher, referred to as the surrogate, to carry out on their behalf. This presentation describes the experiment design, including special details for remote data collection via a subject-surrogate configuration, and concludes with planned data analysis and results to be presented at a later date.

multi-UAS↗
NASA NTRS2018

The Way to the Future Has Already Started: ICAO Aeronautical Telecommunication Network (ATN) Using Internet Protocol Suite (IPS) Standards and Protocol Evolution Update

Millions of people are able to exchange information over phones, computers, tablets and an array of new interconnected devices such as sensors, cameras, home appliances and others are increasingly becoming networked. At the core of this sizeable interconnection is a set of underlying protocols that enable millions of devices to seamlessly talk to each other. Aviation, as many other industries have, utilizes the internet protocol for ground-to-ground network communications and efforts are underway to bring it to the cockpit.In 2015, the International Civil Aviation Organization (ICAO) published the second edition of Document 9896 (Doc 9896) titled: Manual on the Aeronautical Telecommunication Network (ATN) using Internet Protocol Suite (IPS) Standards and Protocol. This manual adopted the Internet protocol version 6 (IPv6) for Internet layer interoperability. Document 9896 defined data communications protocols and services to be used for implementing aeronautical telecommunication network (ATN) using the Internet protocol suite (IPS). The document provided technical specifications that addressed security, network and transport protocols, described applications, supported by ATN/IPS and provided communications guidance. The international aviation community working under the guidance of ICAO initiated work on updates to Doc 9896. Under the ICAO Communication Panel, Working Group Internetworking (WG-I) got this challenging task. Key areas of work for WG-I are related to ATN/IPS Security and ANT/IPS Mobility. Two sub-groups have been assembled to work on these elements. The ICAO anticipates the release of updated Doc 9896 in 2020. Additional ATN/IPS standardization efforts include Radio Technical Commission for Aeronautics Special Committee 223 (RTCA SC-223) IPS profile development, Airlines Electronic Engineering Committee (AEEC) A658 Roadmap of IPS future activities and European Organization for Civil Aviation Equipment (EUROCAE) WG-108 development of guidance documentation.This paper describes ICAO WG-I approach to update key areas of the document in closed coordination with AEEC, RTCA and EUROCAE committees supporting the development of ATN/IPS. Additionally, the paper will explore WG-I mobility solutions under investigation, security developments, IPv6 addressing challenges and other proposed updates. Finally, as new operational expectations such as Free Route and Remote Piloted Aircraft System integration are currently pushing the boundaries set by old operational concepts, the paper identifies the emerging new challenges that will drive the ATN/IPS development beyond 2020. They are related to future voice utilization, System Wide Information Management and Remotely Piloted Aircraft System deployment. IPS systems are seen as the only way forward.

Apaza, Rafael↗
NASA NTRS2009

Robotic Recon for Human Exploration

Robotic reconnaissance has the potential to significantly improve scientific and technical return from lunar surface exploration. In particular, robotic recon may increase crew productivity and reduce operational risk for exploration. However, additional research, development and field-testing is needed to mature robot and ground control systems, refine operational protocols, and specify detailed requirements. When the new lunar surface campaign begins around 2020, and before permanent outposts are established, humans will initially be on the Moon less than 10% of the time. During the 90% of time between crew visits, robots will be available to perform surface operations under ground control. Understanding how robotic systems can best address surface science needs, therefore, becomes a central issue Prior to surface missions, lunar orbiters (LRO, Kaguya, Chandrayyan-1, etc.) will map the Moon. These orbital missions will provide numerous types of maps: visible photography, topographic, mineralogical and geochemical distributions, etc. However, remote sensing data will not be of sufficient resolution, lighting, nor view angle, to fully optimize pre-human exploration planning, e.g., crew traverses for field geology and geophysics. Thus, it is important to acquire supplemental and complementary surface data. Robotic recon can obtain such data, using robot-mounted instruments to scout the surface and subsurface at resolutions and at viewpoints not achievable from orbit. This data can then be used to select locations for detailed field activity and prioritize targets to improve crew productivity. Surface data can also help identify and assess terrain hazards, and evaluate alternate routes to reduce operational risk. Robotic recon could be done months in advance, or be part of a continuing planning process during human missions.

Deans, Matthew↗
NASA NTRS2004

NASA Tech Briefs, August 2004

Topics covered include: Data Relay Board with Protocol for High-Speed, Free-Space Optical Communications; Software and Algorithms for Biomedical Image Data Processing and Visualization; Rapid Chemometric Filtering of Spectral Data; Prioritizing Scientific Data for Transmission; Determining Sizes of Particles in a Flow from DPIV Data; Faster Processing for Inverting GPS Occultation Data; FPGA-Based, Self-Checking, Fault-Tolerant Computers; Ultralow-Power Digital Correlator for Microwave Polarimetry; Grounding Headphones for Protection Against ESD; Lightweight Stacks of Direct Methanol Fuel Cells; Highly Efficient Vector-Inversion Pulse Generators; Estimating Basic Preliminary Design Performances of Aerospace Vehicles; Framework for Development of Object-Oriented Software; Analyzing Spacecraft Telecommunication Systems; Collaborative Planning of Robotic Exploration; Tools for Administration of a UNIX-Based Network; Preparing and Analyzing Iced Airfoils; Evaluating Performance of Components; Fuels Containing Methane of Natural Gas in Solution; Direct Electrolytic Deposition of Mats of MnxOy Nanowires; Bubble Eliminator Based on Centrifugal Flow; Inflatable Emergency Atmospheric-Entry Vehicles; Lightweight Deployable Mirrors with Tensegrity Supports; Centrifugal Adsorption Cartridge System; Ultrasonic Apparatus for Pulverizing Brittle Material; Transplanting Retinal Cells using Bucky Paper for Support; Using an Ultrasonic Instrument to Size Extravascular Bubbles; Coronagraphic Notch Filter for Raman Spectroscopy; On-the-Fly Mapping for Calibrating Directional Antennas; Working Fluids for Increasing Capacities of Heat Pipes; Computationally-Efficient Minimum-Time Aircraft Routes in the Presence of Winds; Liquid-Metal-Fed Pulsed Plasma Thrusters; Personal Radiation Protection System; and Attitude Control for a Solar-Sail Spacecraft.

Source record↗
NASA NTRSDate not supplied

Pilot Assessment of Immune Dysregulation, Stress and Latent Herpesvirus Reactivation at Palmer, Antarctica - Platform for validation of Immune Countermeasures?

Recent studieshave characterized adverse health events potentially relatedto immune system dysregulation, latent herpesvirus reactivation, and clinical incidence for crewmembers onboard ISS. Both areview article describing potential spaceflight countermeasures related to immunityand a specific countermeasures protocol for deep space missions were recently published. An appropriate ground analogto enable spaceflight countermeasures has yet to be validated, although winterover in Antarctica (AWO) seems a highly relevant mission parallel to spaceflight. AWO consists of prolonged deployment, extreme environment, circadian misalignment, personal isolation, station lifestyle (varies by base), and personal risk. Through several studies, AWO at several European bases has beencharacterized, and to date the data has revealed that (immunologically) deployment to interior bases at elevation and with persistent hypobaric hypoxia possesses certaindissimilarities to spaceflight. This proposal seeks to collect low cost pilot data assessing stress, immunity and viral reactivation during AWOat thecoastalU.S. Palmer Station. Even among coastal bases, lifestyle, available crew time/workload and logistical access can vary considerably. Considering all factors, if validated, Palmer may be the most feasible location to evaluate NASA countermeasures. The goal of this pilot study is to ascertain if Palmer may serve as a spaceflight analog option for ground validation of immune countermeasures.The study initiatedwith the crew deployed for winterover at Palmer in 2020.A second crew participated in the recently concluded WO2021 season.All participatingcrew havecollectedand preservedsaliva, plasma and hair samples. On location, the crewmembers alsoperformeda fingerstick blood collection for immediate analysis of basic peripheral leukocyte subsets. Preserved biosamples have beenreturned for analysis, with the WO2020 samples received, and the WO2021 samples currently en-route to Houston. It should be noted that COVID-19 had significant impacts on operations, including training and the collection of pre-mission baseline samples. Preliminary data from the 2020 crewmembers indicate that a relatively mild but detectable immune dysregulation persists at Palmer Station, including alterations in concentration of some plasma cytokines and consistent increases in the incidence of EBV reactivation. Final study data will be tabulated upon receipt of the 2021 crew samples.

Stephanie Krieger↗
NASA NTRS2011

Licklider Transmission Protocol Implementation

This software is an implementation of the Licklider Transmission Protocol (LTP), a communications protocol intended to support the Bundle Protocol in Delay-Tolerant Network (DTN) operations. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times and/or frequent interruptions in connectivity. Communication in interplanetary space is the most prominent example of this sort of environment, and LTP is principally aimed at supporting long-haul reliable transmission over deep-space RF links. Like any reliable transport service employing ARQ (Automatic Repeat re-Quests), LTP is stateful. In order to assure the reception of a block of data it has sent, LTP must retain for possible retransmission all portions of that block which might not have been received yet. In order to do so, it must keep track of which portions of the block are known to have been received so far, and which are not, together with any additional information needed for purposes of retransmitting part, or all, of the block. Long round-trip times mean substantial delay between the transmission of a block of data and the reception of an acknowledgement from the block s destination, signaling arrival of the block. If LTP postponed transmission of additional blocks of data until it received acknowledgement of the arrival of all prior blocks, valuable opportunities to use what little deep space transmission bandwidth is available would be forever lost. For this reason, LTP is based in part on a notion of massive state retention. Any number of requested transmission conversations (sessions) may be concurrently in flight at various displacements along the link between two LTP engines, and the LTP engines must necessarily retain transmission status and retransmission resources for all of them. Moreover, if any of the data of a given block are lost en route, it will be necessary to retain the state of that transmission during an additional round trip while the lost data are retransmitted; even multiple retransmission cycles may be necessary. LTP's possible multiplicity of sessions per association makes it necessary for each segment of application data to include an additional demultiplexing token: a session ID that uniquely identifies the session in which the segment was issued and, implicitly, the block of data being conveyed by this session. This software comprises a prototype implementation developed by Johns Hopkins University APL in cooperation with JPL, together with adaptations that improve the robustness, correctness, and operability of that implementation.

Burleigh, Scott C.↗