SEARCH · Engineering Papers

Results for “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 577 records · Page 32

All sources NASA NTRS DOE OSTI

NASA NTRS2011

Generic, Extensible, Configurable Push-Pull Framework for Large-Scale Science Missions

The push-pull framework was developed in hopes that an infrastructure would be created that could literally connect to any given remote site, and (given a set of restrictions) download files from that remote site based on those restrictions. The Cataloging and Archiving Service (CAS) has recently been re-architected and re-factored in its canonical services, including file management, workflow management, and resource management. Additionally, a generic CAS Crawling Framework was built based on motivation from Apache s open-source search engine project called Nutch. Nutch is an Apache effort to provide search engine services (akin to Google), including crawling, parsing, content analysis, and indexing. It has produced several stable software releases, and is currently used in production services at companies such as Yahoo, and at NASA's Planetary Data System. The CAS Crawling Framework supports many of the Nutch Crawler's generic services, including metadata extraction, crawling, and ingestion. However, one service that was not ported over from Nutch is a generic protocol layer service that allows the Nutch crawler to obtain content using protocol plug-ins that download content using implementations of remote protocols, such as HTTP, FTP, WinNT file system, HTTPS, etc. Such a generic protocol layer would greatly aid in the CAS Crawling Framework, as the layer would allow the framework to generically obtain content (i.e., data products) from remote sites using protocols such as FTP and others. Augmented with this capability, the Orbiting Carbon Observatory (OCO) and NPP (NPOESS Preparatory Project) Sounder PEATE (Product Evaluation and Analysis Tools Elements) would be provided with an infrastructure to support generic FTP-based pull access to remote data products, obviating the need for any specialized software outside of the context of their existing process control systems. This extensible configurable framework was created in Java, and allows the use of different underlying communication middleware (at present, both XMLRPC, and RMI). In addition, the framework is entirely suitable in a multi-mission environment and is supporting both NPP Sounder PEATE and the OCO Mission. Both systems involve tasks such as high-throughput job processing, terabyte-scale data management, and science computing facilities. NPP Sounder PEATE is already using the push-pull framework to accept hundreds of gigabytes of IASI (infrared atmospheric sounding interferometer) data, and is in preparation to accept CRIMS (Cross-track Infrared Microwave Sounding Suite) data. OCO will leverage the framework to download MODIS, CloudSat, and other ancillary data products for use in the high-performance Level 2 Science Algorithm. The National Cancer Institute is also evaluating the framework for use in sharing and disseminating cancer research data through its Early Detection Research Network (EDRN).

Foster, Brian M.↗

NASA NTRS2011

Asynchronous Message Service Reference Implementation

This software provides a library of middleware functions with a simple application programming interface, enabling implementation of distributed applications in conformance with the CCSDS AMS (Consultative Committee for Space Data Systems Asynchronous Message Service) specification. The AMS service, and its protocols, implement an architectural concept under which the modules of mission systems may be designed as if they were to operate in isolation, each one producing and consuming mission information without explicit awareness of which other modules are currently operating. Communication relationships among such modules are self-configuring; this tends to minimize complexity in the development and operations of modular data systems. A system built on this model is a society of generally autonomous, inter-operating modules that may fluctuate freely over time in response to changing mission objectives, modules functional upgrades, and recovery from individual module failure. The purpose of AMS, then, is to reduce mission cost and risk by providing standard, reusable infrastructure for the exchange of information among data system modules in a manner that is simple to use, highly automated, flexible, robust, scalable, and efficient. The implementation is designed to spawn multiple threads of AMS functionality under the control of an AMS application program. These threads enable all members of an AMS-based, distributed application to discover one another in real time, subscribe to messages on specific topics, and to publish messages on specific topics. The query/reply (client/server) communication model is also supported. Message exchange is optionally subject to encryption (to support confidentiality) and authorization. Fault tolerance measures in the discovery protocol minimize the likelihood of overall application failure due to any single operational error anywhere in the system. The multi-threaded design simplifies processing while enabling application nodes to operate at high speeds; linked lists protected by mutex semaphores and condition variables are used for efficient, inter-thread communication. Applications may use a variety of transport protocols underlying AMS itself, including TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and message queues.

Burleigh, Scott C.↗

NASA NTRS2011

Space Flight Middleware: Remote AMS over DTN for Delay-Tolerant Messaging

This paper describes a technique for implementing scalable, reliable, multi-source multipoint data distribution in space flight communications -- Delay-Tolerant Reliable Multicast (DTRM) -- that is fully supported by the "Remote AMS" (RAMS) protocol of the Asynchronous Message Service (AMS) proposed for standardization within the Consultative Committee for Space Data Systems (CCSDS). The DTRM architecture enables applications to easily "publish" messages that will be reliably and efficiently delivered to an arbitrary number of "subscribing" applications residing anywhere in the space network, whether in the same subnet or in a subnet on a remote planet or vehicle separated by many light minutes of interplanetary space. The architecture comprises multiple levels of protocol, each included for a specific purpose and allocated specific responsibilities: "application AMS" traffic performs end-system data introduction and delivery subject to access control; underlying "remote AMS" directs this application traffic to populations of recipients at remote locations in a multicast distribution tree, enabling the architecture to scale up to large networks; further underlying Delay-Tolerant Networking (DTN) Bundle Protocol (BP) advances RAMS protocol data units through the distribution tree using delay-tolerant storeand- forward methods; and further underlying reliable "convergence-layer" protocols ensure successful data transfer over each segment of the end-to-end route. The result is scalable, reliable, delay-tolerant multi-source multicast that is largely self-configuring.

Disruption Tolerant Networking (DTN)↗

NASA NTRS2012

Field Geologic Observation and Sample Collection Strategies for Planetary Surface Exploration: Insights from the 2010 Desert RATS Geologist Crewmembers

Observation is the primary role of all field geologists, and geologic observations put into an evolving conceptual context will be the most important data stream that will be relayed to Earth during a planetary exploration mission. Sample collection is also an important planetary field activity, and its success is closely tied to the quality of contextual observations. To test protocols for doing effective planetary geologic field- work, the Desert RATS(Research and Technology Studies) project deployed two prototype rovers for two weeks of simulated exploratory traverses in the San Francisco volcanic field of northern Arizona. The authors of this paper represent the geologist crew members who participated in the 2010 field test.We document the procedures adopted for Desert RATS 2010 and report on our experiences regarding these protocols. Careful consideration must be made of various issues that impact the interplay between field geologic observations and sample collection, including time management; strategies relatedtoduplicationofsamplesandobservations;logisticalconstraintson the volume and mass of samples and the volume/transfer of data collected; and paradigms for evaluation of mission success. We find that the 2010 field protocols brought to light important aspects of each of these issues, and we recommend best practices and modifications to training and operational protocols to address them. Underlying our recommendations is the recognition that the capacity of the crew to flexibly execute their activities is paramount. Careful design of mission parameters, especially field geologic protocols, is critical for enabling the crews to successfully meet their science objectives.

Hurtado, Jose M., Jr.↗

NASA NTRS2011

Tools and Technologies Needed for Conducting Planetary Field Geology While On EVA: Insights from the 2010 Desert RATS Geologist Crewmembers

Observation is the primary role of all field geologists, and geologic observations put into an evolving conceptual context will be the most important data stream that will be relayed to Earth during a planetary exploration mission. Sample collection is also an important planetary field activity, and its success is closely tied to the quality of contextual observations. To test protocols for doing effective planetary geologic fieldwork, the Desert RATS (Research and Technology Studies) project deployed two prototype rovers for two weeks of simulated exploratory traverses in the San Francisco volcanic field of northern Arizona. The authors of this paper represent the geologist crewmembers who participated in the 2010 field test. We document the procedures adopted for Desert RATS 2010 and report on our experiences regarding these protocols. Careful consideration must be made of various issues that impact the interplay between field geologic observations and sample collection, including time management; strategies related to duplication of samples and observations; logistical constraints on the volume and mass of samples and the volume/transfer of data collected; and paradigms for evaluation of mission success. We find that the 2010 field protocols brought to light important aspects of each of these issues, and we recommend best practices and modifications to training and operational protocols to address them. Underlying our recommendations is the recognition that the capacity of the crew to "flexibly execute" their activities is paramount. Careful design of mission parameters, especially field geologic protocols, is critical for enabling the crews to successfully meet their science objectives.

Young, Kelsey↗

NASA NTRS2016

NASA'S Standard Measures During Bed Rest: Adaptations in the Cardiovascular System

Bed rest is a well-accepted analog of space flight that has been used extensively to investigate physiological adaptations in a larger number of subjects in a shorter amount of time than can be studied with space flight and without the confounding effects associated with normal mission operations. However, comparison across studies of different bed rest durations, between sexes, and between various countermeasure protocols have been hampered by dissimilarities in bed rest conditions, measurement protocols, and testing schedules. To address these concerns, NASA instituted standard bed rest conditions and standard measures for all physiological disciplines participating in studies conducted at the Flight Analogs Research Unit (FARU) at the University of Texas-Medical Branch. Investigators for individual studies employed their own targeted study protocols to address specific hypothesis-driven questions, but standard measures tests were conducted within these studies on a non-interference basis to maximize data availability while reducing the need to implement multiple bed rest studies to understand the effects of a specific countermeasure. When possible, bed rest standard measures protocols were similar to tests nominally used for medically-required measures or research protocols conducted before and after Space Shuttle and International Space Station missions. Specifically, bed rest standard measures for the cardiovascular system implemented before, during, and after bed rest at the FARU included plasma volume (carbon monoxide rebreathing), cardiac mass and function (2D, 3D and Doppler echocardiography), and orthostatic tolerance testing (15- or 30-minutes of 80 degree head-up tilt). Results to-date indicate that when countermeasures are not employed, plasma volume decreases and the incidence of presyncope during head-up tilt is more frequent even after short-duration bed rest while reductions in cardiac function and mass are progressive as bed rest duration increases. Additionally, while plasma volume loss can be corrected and cardiac mass can be prevented with properly applied countermeasures, orthostatic tolerance is more difficult to protect when supine exercise is the only countermeasure. Similar results have been observed after space flight. Plasma volume, cardiac chamber volume, and orthostatic tolerance recover relatively quickly with resumption of ambulation and normal activity levels after bed rest but restoration of cardiac mass is prolonged.

Lee, Stuart M. C.↗

NASA NTRS2016

A Multi-Center Space Data System Prototype Based on CCSDS Standards

Deep space missions beyond earth orbit will require new methods of data communications in order to compensate for increasing Radio Frequency (RF) propagation delay. The Consultative Committee for Space Data Systems (CCSDS) standard protocols Spacecraft Monitor & Control (SM&C), Asynchronous Message Service (AMS), and Delay/Disruption Tolerant Networking (DTN) provide such a method. However, the maturity level of this protocol stack is insufficient for mission inclusion at this time. This Space Data System prototype is intended to provide experience which will raise the Technical Readiness Level (TRL) of this protocol set. In order to reduce costs, future missions can take advantage of these standard protocols, which will result in increased interoperability between control centers. This prototype demonstrates these capabilities by implementing a realistic space data system in which telemetry is published to control center applications at the Jet Propulsion Lab (JPL), the Marshall Space Flight Center (MSFC), and the Johnson Space Center (JSC). Reverse publishing paths for commanding from each control center are also implemented. The target vehicle consists of realistic flight computer hardware running Core Flight Software (CFS) in the integrated Power, Avionics, and Power (iPAS) Pathfinder Lab at JSC. This prototype demonstrates a potential upgrade path for future Deep Space Network (DSN) modification, in which the automatic error recovery and communication gap compensation capabilities of DTN would be exploited. In addition, SM&C provides architectural flexibility by allowing new service providers and consumers to be added efficiently anywhere in the network using the common interface provided by SM&C's Message Abstraction Layer (MAL). In FY 2015, this space data system was enhanced by adding telerobotic operations capability provided by the Robot API Delegate (RAPID) family of protocols developed at NASA. RAPID is one of several candidates for consideration and inclusion in a new international standard being developed by the CCSDS Telerobotic Operations Working Group. Software gateways for the purpose of interfacing RAPID messages with the existing SM&C based infrastructure were developed. Telerobotic monitor, control, and bridge applications were written in the RAPID framework, which were then tailored to the NAO telerobotic test article hardware, a product of Aldebaran Robotics.

Rich, Thomas M.↗

NASA NTRS2018

Overview of the Exploration Exercise Device Validation Study Plans

The NASA has determined that a multi-functional exercise device will be developed for use as an exercise device during exploration missions. The device will allow for full body resistance and metabolic exercise necessary to minimize physiological losses during space flight and to maintain fitness necessary to perform critical mission tasks. Prior to implementation as an exercise device on an Exploration vehicle, there will be verification and validation testing completed to determine device efficacy at providing the necessary training stimuli to achieve desired goals. Because the exploration device will be new device that has yet be specified, specific Verification and Validation (V&V) protocols have yet to be developed. Upon delivery of an exploration exercise device training unit, stakeholders throughout NASA will develop V&V plans that include ground-based testing and testing on the International Space Station (ISS). Stakeholders will develop test protocols that include success criterion for the device. Ground tests will occur at NASA Johnson Space Station prior to flight testing. The intents of the ground tests are to allow crew, spaceflight medicine, science, engineering, Astronaut Strength, Conditioning, and Reconditioning staff, and others to gain experience in the best utilization of the device. The goal is to obtain an evidence base for recommending use of the device on the ISS. The developed protocol will be created to achieve multiple objectives, including determining if the device provides an adequate training stimulus for 5th - 95th percentile males and females, allows for exercise modalities that protect functional capability, and is robust and can withstand extensive human use. Although protocols are yet to be determined, current expectations include use of the device by test subjects and current crew in order to obtain quantitative and qualitative feedback. Information obtained during the ground tests may be used to influence device modifications during design iterations. Assuming successful ground tests, the device will be installed on the ISS for testing during space flight. Spaceflight testing is envisioned to include an activation and checkout (ACO) phase and a V&V phase. During the ACO phase, 1-2 crewmembers will exercise with the device to ensure proper function. ACO is expected to last multiple months because of the many modes and methods of exercise that need to be assessed. However, the goal is to complete the ACO as quickly as possible. Once successful ACO occurs, the crew will be free to use the device for normal exercise pending concurrence from stakeholders. V&V tests on the ISS will ideally consist of crew using the device for all of their exercise for an entire mission. Exercise prescriptions will be supplied that replicate expected prescriptions during exploration missions. Crew that are not enrolled in the V&V studies would be also free to use the device as their schedule permits. As experience is gained by users, exercise protocols could change. The intent of all V&V testing is to ensure that all have thorough understanding of experience at optimizing device capability

DeWitt, J. K.↗

NASA NTRS2020

X-HAB 2020: AR Field Treks Summary and Conclusions

As part of the FY20 X-Hab Challenge, BLiSS sought to create an Augmented Reality (AR) toolkit to help with analog field trek operations under the supervision of the Solar System Exploration Research Virtual Institute (SSERVI). These treks are operational and technical demonstrations at space-like destinations on Earth to test current extra-vehicular activity (EVA) techniques. While BLiSS as an organization has experience studying operational tasks such as this, it has never developed AR software at this scale. For that reason, another team at the University was brought on to work in parallel. The Collaborative Lab for Advancing Work in Space (CLAWS) is a veteran group of the NASA Spacesuit User Interface Technologies for Students (SUITS) challenge in which Hololens displays for astronauts are created within a year. The operational and technological pairing was ideally suited for tackling this problem. The team divided its responsibilities so that BLiSS would handle the research required to shape the project. As this deliverable had an end user, it was decided that interviewing these field geologists and operations specialists would provide the best insight. These interviews paired with literature review would reveal niche applications for AR that remained within feasible bounds. These science-driven EVAs in unknown terrain require more flexible tools than the current generation of EVA assistants. Rather than focus on sequential instructions, there instead needs to be a broad toolkit that's only called upon in specific instances. This AR Toolkit for Lunar Astronauts and Scientists (ATLAS) became the development goal of the project: create a non-intrusive assembly of tools that could be accessed in AR on the field. The current ATLAS design makes use of a geospatially and temporally annotated eld note system called GeoNotes. This allows for data to be collected and coordinated in a way that's synchronized across time, space, and different users. A Mission Control Center (MCC) and Mobile Support Equipment (MSE) were all needed to transport the AR headset into the field with the user. A network infrastructure was designed and set up within the University to enable this functionality. The software is based on a Protocol-Module structure that allows for modular development of each capability. A Protocol Manager coordinates different protocols that make use of modules. Each module tackles a different individual task while the protocol puts each one to use. The protocol manager coordinates when these are called to be used. This software is hosted on a head-mounted display (HMD) with the MCC acting as support from afar. While the software would be unit-tested at each level and each hardware component verified, a final demonstration would serve to prove the system's capabilities: an analog field trek. The team would prepare to support a user in a remote location from the MCC back at the University. A local area near campus would be tested before going out to do sample field geology further away. This unfortunately became impossible with the arrival of COVID-19. Access to all of the facilities to complete the project as planned were shut down. Our team was scattered across the globe and forced to complete the rest virtually. Adjustments were made to produce a small virtual concept in Adobe XD in the meantime. Even digital surveys were created based on the NASA task-load index (TLX) originally intended for testing actual users. The goal shifted towards completing software and getting feedback on the user interfaces (UI) and user experiences (UX). This team has reformed in response to COVID and its focus has shifted to what can be done remotely. There is still an intention to finish the original deliverable described in this report. The work has been expanded beyond the original X-Hab challenge and has instead become its own research e ort to be continued afterwards. This report collects the processes and knowledge gained from a year of studying and working at this problem with two teams. It should preserve it for the time until the world returns to normal and work can resume. CLAWS will be taking over full responsibility from that point forward, eventually surpassing the original needs of the project. While this document captures the work done towards an eventual end, the CLAWS team has written their own proposal alongside it. It outlines a new future for ATLAS beyond X-Hab, BLiSS, and hopefully beyond COVID-19. This project began as a vague goal hoping to place a new technology into the unique setting of exploration science. The project has since comfortably taken root and will hopefully bloom over the next year.

Alex Sena↗

NASA NTRS2021

BPv6 and BPv7 Coexistence in Delay Tolerant Networking (DTN)

As DTN has progressed since its inception in 2002, the community stabilized around Bundle Protocol version 6 (BPv6). This protocol was standardized by the RFC 5050’s definition of BPv6 and was later standardized and refined for space operations by the CCSDS Bundle Protocol Specification. After the release of RFC 5050, a variety of implementations and missions used BPv6 and noted several improvements that could be made to the protocol. These improvements culminated in a push to release a new protocol version, BPv7. Unfortunately, the vast improvements and difference in encoding that separates BPv7 from BPv6 also makes the two versions inherently incompatible. Consequently, there is an issue implementing BPv7 in existing systems while continuing support for BPv6 implementations. In response to this issue, two solutions emerge: (1) Bundle-in-Bundle Encapsulation (BIBE), a capability that wraps a bundle in another bundle for shipping between intermediary nodes, and (2) version agnostic DTN implementations. These concepts have been proven out in the MSFC DTN implementation known as DTNME.

Joshua Deaton↗

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

Mars Sample Return: Risk Management & Sample Safety Assessment

Returning samples from Mars has long been a major planetary science objective due to the high scientific value and transformative potential of the resulting data. An exciting dimension of this objective is the potential for the detection of ancient microbiological life, and the possibility of improving our understanding of the evolution of habitable environments on Mars and the development of life on Earth. To ensure that returned samples meet stringent planetary protection requirements and do not expose Earth to potential biohazards, the joint NASA/ESA Sample Receiving Project (SRP) assembled the Sample Safety Assessment Protocol Tiger Team (SSAP-TT). Members were recruited with the specific goal of creating a multi-disciplinary and internationally distributed team of experts in their respective fields across the federal government, academia, and private industry. This team was chartered with reassessing previous sample safety assessment strategies, defining what constitutes a biological hazard, developing a protocol to test for potential biohazards, and establishing a statistical framework to determine if samples are “safe” for release. The team developed a three-step protocol, supported by a Bayesian statistical framework, to assess whether returned samples contain potential biohazards that could present a risk to Earth’s biosphere. Initial conclusions indicated that an effective and comprehensive safety assessment protocol is feasible using modern techniques and does not require an excessive amount of sample consumption or traditional microbiological detection methodology. Herein, we will present an overview of the MSR SRP, the proposed safety assessment protocol, and how aspects of this novel approach can be applied to biological assessment in healthcare product manufacturing practices.

Alvin L Smith↗

NASA NTRS2009

The Deep Impact Network Experiment Operations Center Monitor and Control System

The Interplanetary Overlay Network (ION) software at JPL is an implementation of Delay/Disruption Tolerant Networking (DTN) which has been proposed as an interplanetary protocol to support space communication. The JPL Deep Impact Network (DINET) is a technology development experiment intended to increase the technical readiness of the JPL implemented ION suite. The DINET Experiment Operations Center (EOC) developed by JPL's Protocol Technology Lab (PTL) was critical in accomplishing the experiment. EOC, containing all end nodes of simulated spaces and one administrative node, exercised publish and subscribe functions for payload data among all end nodes to verify the effectiveness of data exchange over ION protocol stacks. A Monitor and Control System was created and installed on the administrative node as a multi-tiered internet-based Web application to support the Deep Impact Network Experiment by allowing monitoring and analysis of the data delivery and statistics from ION. This Monitor and Control System includes the capability of receiving protocol status messages, classifying and storing status messages into a database from the ION simulation network, and providing web interfaces for viewing the live results in addition to interactive database queries.

Delay/Disruption Tolerant Network (DTN)↗

NASA NTRS2015

Kennedy Space Center Timing and Countdown Interface to Kennedy Ground Control Subsystem

Kennedy Ground Control System (KGCS) engineers at the National Aeronautics and Space Administration (NASA) Kennedy Space Center (KSC) are developing a time-tagging process to enable reconstruction of the events during a launch countdown. Such a process can be useful in the case of anomalies or other situations where it is necessary to know the exact time an event occurred. It is thus critical for the timing information to be accurate. KGCS will synchronize all items with Coordinated Universal Time (UTC) obtained from the Timing and Countdown (T&CD) organization. Network Time Protocol (NTP) is the protocol currently in place for synchronizing UTC. However, NTP has a peak error that is too high for today's standards. Precision Time Protocol (PTP) is a newer protocol with a much smaller peak error. The focus of this project has been to implement a PTP solution on the network to increase timing accuracy while introducing and configuring the implementation of a firewall between T&CD and the KGCS network.

Protocol↗

NASA NTRS2015

Inconsistent Strategies to Spin up Models in CMIP5: Implications for Ocean Biogeochemical Model Performance Assessment

During the fifth phase of the Coupled Model Intercomparison Project (CMIP5) substantial efforts were made to systematically assess the skill of Earth system models. One goal was to check how realistically representative marine biogeochemical tracer distributions could be reproduced by models. In routine assessments model historical hindcasts were compared with available modern biogeochemical observations. However, these assessments considered neither how close modeled biogeochemical reservoirs were to equilibrium nor the sensitivity of model performance to initial conditions or to the spin-up protocols. Here, we explore how the large diversity in spin-up protocols used for marine biogeochemistry in CMIP5 Earth system models (ESMs) contributes to model-to-model differences in the simulated fields. We take advantage of a 500-year spin-up simulation of IPSL-CM5A-LR to quantify the influence of the spin-up protocol on model ability to reproduce relevant data fields. Amplification of biases in selected biogeochemical fields (O2, NO3, Alk-DIC) is assessed as a function of spin-up duration. We demonstrate that a relationship between spin-up duration and assessment metrics emerges from our model results and holds when confronted with a larger ensemble of CMIP5 models. This shows that drift has implications for performance assessment in addition to possibly aliasing estimates of climate change impact. Our study suggests that differences in spin-up protocols could explain a substantial part of model disparities, constituting a source of model-to- model uncertainty. This requires more attention in future model intercomparison exercises in order to provide quantitatively more correct ESM results on marine biogeochemistry and carbon cycle feedbacks.

histories↗

NASA NTRS1984

ARQ schemes for data transmission in mobile radio systems

The problem of providing data communications over a land mobile radio channel is considered, taking into account error detection combined with retransmission on request as a means of obtaining reliability in digital data transmission. The considered systems are referred to as automatic RQ (repeat-request) or ARQ. It is pointed out that the distinguishing features of a land mobile radio (LMR) system, as far as the ARQ protocol is concerned, are a frequency or pair of frequencies shared by a large population of half-duplex users which cannot transmit and receive simultaneously. A description is presented of those variations of ARQ which are adaptable to an LMR system. A new channel model for a fading LMR channel is developed, and several ARQ protocols and some new protocol combinations are described. The relationships are developed for a description of the various protocols in terms of channel failure probabilities. Undetected error probabilities are developed and compared.

Comroe, R. A.↗

NASA NTRS1985

Verification and performance tests of HYCAR program

The HYCAR program simulates the network protocols of HYPERchannel and Fiber Optic Demonstration System (FODS) and other related protocols. Verification tests of the program were conducted using the FODS protocol. The tests validated the operation of the program through deterministic and analytical means. Extensive experimentation with the simulator produced a set of performance characteristics for the FODS protocol under varied loading conditions. These characteristics are consistent with those expected, and are documented with the validation tests.

Bhatia, Veena↗