Search NASA⌕ Search

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.

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

At least 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
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↗
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↗
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 (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 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↗
NASA NTRS2011

Interplanetary Overlay Network Bundle Protocol Implementation

The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.

Burleigh, Scott C.↗
NASA NTRSDate not supplied

NASA’s Interest in 3GPP Mobile Telecommunications Protocols for Near Earth Space and the Lunar Surface

In the next several years, NASA intends to return astronauts to the Moon through the Artemis Program. Under Artemis, NASA plans to collaborate with commercial and international partners to establish a long-term presence on the Moon. Near-term Artemis missions will be analogous but much more sophisticated versions of the last couple of Apollo missions. For example, the first area expected to be explored by an Artemis mission is near the south pole as opposed to the mid-latitudes visited by the Apollo astronauts, which makes direct communications with Earth more complicated. Lunar infrastructure will eventually be built over time by many organizations, public and private, to support sustained human exploration, science, and industrial activities on the Moon. A robust lunar communications and navigation infrastructure will be essential to realizing this long-term vision. Meanwhile, on Earth, major advances are being made as5G mobile telecommunications rollout across the globe. Furthermore, the 3rdGeneration Partnership Project (3GPP) is beginning to define future 6G capabilities. NASA envisions a lunar communications and navigation network with capabilities similar to those of communication networks we enjoy here on Earth. Building such a network will require participation by many organizations. NASA’s Tipping Point program seeks industry-developed space technologies that can both foster commercial space capabilities and benefit future NASA missions. This paper provides an overview of NASA’s interest in 3GPPanddescribescurrent work based on 3GPP standards within NASA or funded by NASA, such as Nokia’s upcoming Tipping Point demonstration of 4G/LTE on the lunar surface in early 2023.

Bernard L Edwards↗
NASA NTRS2000

Internet Technologies for Space-based Communications: State of the Art and Challenges

The Internet is rapidly changing the ways we communicate information around the globe today. The desire to provide Internet-based services to anyone, anywhere, anytime has brought satellite communications to the forefront to become an integral part of the Internet. In spite of the distances involved, satellite links are proving to be capable of providing Internet services based on Internet protocol (TCP/IP) stack. This development has led to the question particularly at NASA; can satellites and other space platforms become an Internet-node in space? This will allow the direct transfer of information directly from space to the users on Earth and even be able to control the spacecraft and its instruments. NASA even wants to extend the near earth space Internet to deep space applications where scientists and the public here on Earth may view space exploration in real time via the Internet. NASA's future solar system exploration will involve intensive in situ investigations of planets, moons, asteroids, and comets. While past missions typically involved a single fly-by or orbiting science spacecraft, future missions will begin to use fleets of small, highly intelligent robotic vehicles to carry out collaborative investigations. The resulting multi-spacecraft topologies will effectively create a wide area network spanning the solar system. However, this will require significant development in Internet technologies for space use. This paper provides the status'of the Internet for near earth applications and the potential extension of the Internet for use in deep space planetary exploration. The paper will discuss the overall challenges of implementing the space Internet and how the space Internet will integrate into the complex terrestrial systems those forms the Internet of today in a hybrid set of networks. Internet. We envision extending to the deep space environment such Internet concepts as a well-designed layered architecture. This effort will require an ability to develop and infuse new physical layer technology to increase network bandwidth at very low-bit error rates. In addition, we identify network technologies such as routers and switches needed to maintain standard application layer interfaces, while providing low-cost, efficient, modular networking solutions. We will describe the overall architectural approach to extending the concept of the Internet to space and highlight the important technological challenges and initiatives that will make it a reality.

Bhasin, K.↗
NASA NTRS2014

Carbon-Temperature-Water Change Analysis for Peanut Production Under Climate Change: A Prototype for the AgMIP Coordinated Climate-Crop Modeling Project (C3MP)

Climate change is projected to push the limits of cropping systems and has the potential to disrupt the agricultural sector from local to global scales. This article introduces the Coordinated Climate-Crop Modeling Project (C3MP), an initiative of the Agricultural Model Intercomparison and Improvement Project (AgMIP) to engage a global network of crop modelers to explore the impacts of climate change via an investigation of crop responses to changes in carbon dioxide concentration ([CO2]), temperature, and water. As a demonstration of the C3MP protocols and enabled analyses, we apply the Decision Support System for Agrotechnology Transfer (DSSAT) CROPGRO-Peanut crop model for Henry County, Alabama, to evaluate responses to the range of plausible [CO2], temperature changes, and precipitation changes projected by climate models out to the end of the 21st century. These sensitivity tests are used to derive crop model emulators that estimate changes in mean yield and the coefficient of variation for seasonal yields across a broad range of climate conditions, reproducing mean yields from sensitivity test simulations with deviations of ca. 2% for rain-fed conditions. We apply these statistical emulators to investigate how peanuts respond to projections from various global climate models, time periods, and emissions scenarios, finding a robust projection of modest (<10%) median yield losses in the middle of the 21st century accelerating to more severe (>20%) losses and larger uncertainty at the end of the century under the more severe representative concentration pathway (RCP8.5). This projection is not substantially altered by the selection of the AgMERRA global gridded climate dataset rather than the local historical observations, differences between the Third and Fifth Coupled Model Intercomparison Project (CMIP3 and CMIP5), or the use of the delta method of climate impacts analysis rather than the C3MP impacts response surface and emulator approach.

climate change↗
NASA NTRS2009

Standards-Based Wireless Sensor Networking Protocols for Spaceflight Applications

Wireless sensor networks (WSNs) have the capacity to revolutionize data gathering in both spaceflight and terrestrial applications. WSNs provide a huge advantage over traditional, wired instrumentation since they do not require wiring trunks to connect sensors to a central hub. This allows for easy sensor installation in hard to reach locations, easy expansion of the number of sensors or sensing modalities, and reduction in both system cost and weight. While this technology offers unprecedented flexibility and adaptability, implementing it in practice is not without its difficulties. Any practical WSN deployment must contend with a number of difficulties in its radio frequency (RF) environment. Multi-path reflections can distort signals, limit data rates, and cause signal fades that prevent nodes from having clear access to channels, especially in a closed environment such as a spacecraft. Other RF signal sources, such as wireless internet, voice, and data systems may contend with the sensor nodes for bandwidth. Finally, RF noise from electrical systems and periodic scattering from moving objects such as crew members will all combine to give an incredibly unpredictable, time-varying communication environment.

Barton, Richard J.↗
NASA NTRS2008

The NASA Real Time Mission Monitor - A Situational Awareness Tool for Conducting Tropical Cyclone Field Experiments

The NASA Real Time Mission Monitor (RTMM) is a situational awareness tool that integrates satellite, aircraft state information, airborne and surface instruments, and weather state data in to a single visualization package for real time field experiment management. RTMM optimizes science and logistic decision-making during field experiments by presenting timely data and graphics to the users to improve real time situational awareness of the experiment's assets. The RTMM is proven in the field as it supported program managers, scientists, and aircraft personnel during the NASA African Monsoon Multidisciplinary Analyses (investigated African easterly waves and Tropical Storm Debby and Helene) during August-September 2006 in Cape Verde, the Tropical Composition, Cloud and Climate Coupling experiment during July-August 2007 in Costa Rica, and the Hurricane Aerosonde mission into Hurricane Noel in 2-3 November 2007. The integration and delivery of this information is made possible through data acquisition systems, network communication links, and network server resources built and managed by collaborators at NASA Marshall Space Flight Center (MSFC) and Dryden Flight Research Center (DFRC). RTMM is evolving towards a more flexible and dynamic combination of sensor ingest, network computing, and decision-making activities through the use of a service oriented architecture based on community standards and protocols. Each field experiment presents unique challenges and opportunities for advancing the functionality of RTMM. A description of RTMM, the missions it has supported, and its new features that are under development will be presented.

Goodman, Michael↗
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 NTRS2011

Tracking Climate Effects on Plant-Pollinator Interaction Phenology with Satellites and Honey Bee Hives

Background/Question/Methods: The complexity of plant-pollinator interactions, the large number of species involved, and the lack of species response functions present challenges to understanding how these critical interactions may be impacted by climate and land cover change on large scales. Given the importance of this interaction for terrestrial ecosystems, it is desirable to develop new approaches. We monitor the daily weight change of honey bee (Apis mellifera) colonies to record the phenology of the Honey Bee Nectar Flow (HBNF) in a volunteer network (honeybeenet.gsfc.nasa.gov). The records document the successful interaction of a generalist pollinator with a variety of plant resources. We extract useful HBNF phenology metrics for three seasons. Sites currently exist in 35 states/provinces in North America, with a concentration in the Mid-Atlantic region. HBNF metrics are compared to standard phenology metrics derived from remotely sensed vegetation indices from NASA's MODIS sensor and published results from NOAA's A VHRR. At any given time the percentage of plants producing nectar is usually a sma11 fraction of the total satellite sensor signal. We are interested in determining how well the 'bulk' satellite vegetation parameters relate to the phenology of the HBNF, and how it varies spatially on landscape to continental scales. Results/Conclusions: We found the median and peak seasonal HBNF dates to be robust, with variation between replicate scale hives of only a few days. We developed quality assessment protocols to identify abnormal colony artifacts. Temporally, the peak and median of the HBNF in the Mid-Atlantic show a significant advance of 0.58 d/y beginning about 1970, very similar to that observed by the A VHRR since 1982 (0.57 d/y). Spatially, the HBNF metrics are highly correlated with elevation and winter minimum temperature distribution, and exhibit significant but regionally coherent inter-annual variation. The relationship between median of the spring HBNF with the "Green-up" metric from the 500 meter MODIS NDVI phenology product, for sites throughout the Eastern US 2000-2009, is well described by a single linear fit (r(exp 2) = 0.72). We conclude.that for the tree-dominated areas of the Eastern US at least the spring HBNF can be tracked very well by MODIS phenology. Analysis of other regions and seasons is presently underway but with more limited data. Spatial patterns in the eastern US and management implications will be presented and discussed.

Esaias, Wayne E.↗
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 NTRS2016

High Data Rate Architecture (HiDRA)

One of the greatest challenges in developing new space technology is in navigating the transition from ground based laboratory demonstration at Technology Readiness Level 6 (TRL-6) to conducting a prototype demonstration in space (TRL-7). This challenge is com- pounded by the relatively low availability of new spacecraft missions when compared with aeronautical craft to bridge this gap, leading to the general adoption of a low-risk stance by mission management to accept new, unproven technologies into the system. Also in consideration of risk, the limited selection and availability of proven space-grade components imparts a severe limitation on achieving high performance systems by current terrestrial technology standards. Finally from a space communications point of view the long duration characteristic of most missions imparts a major constraint on the entire space and ground network architecture, since any new technologies introduced into the system would have to be compliant with the duration of the currently deployed operational technologies, and in some cases may be limited by surrounding legacy capabilities. Beyond ensuring that the new technology is verified to function correctly and validated to meet the needs of the end users the formidable challenge then grows to additionally include: carefully timing the maturity path of the new technology to coincide with a feasible and accepting future mission so it flies before its relevancy has passed, utilizing a limited catalog of available components to their maximum potential to create meaningful and unprecedented new capabilities, designing and ensuring interoperability with aging space and ground infrastructures while simultaneously providing a growth path to the future. The International Space Station (ISS) is approaching 20 years of age. To keep the ISS relevant, technology upgrades are continuously taking place. Regarding communications, the state-of-the-art communication system upgrades underway include high-rate laser terminals. These must interface with the existing, aging data infrastructure. The High Data Rate Architecture (HiDRA) project is designed to provide networked store, carry, and forward capability to optimize data flow through both the existing radio frequency (RF) and new laser communications terminal. The networking capability is realized through the Delay Tolerant Networking (DTN) protocol, and is used for scheduling data movement as well as optimizing the performance of existing RF channels. HiDRA is realized as a distributed FPGA memory and interface controller that is itself controlled by a local computer running DTN software. Thus HiDRA is applicable to other arenas seeking to employ next-generation communications technologies, e.g. deep space. In this paper, we describe HiDRA and its far-reaching research implications.

DTN↗