Search NASA⌕ Search

SEARCH · Search NASA

Results for “Data Packets”

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 181 records · Page 10

The SAMPEX Data Processing Unit

The paper discusses salient features of the SAMPEX Data Processing Unit (DPU), the primary function of which is to collect sensor data to create telemetry packets for transmission to the solid-state recorder located within the Small Explorer Data System. Particular attention is given to the sensor interface electronics, the space command interface, the spacecraft telemetry interface, and the memory mapper of the DPU system; the task scheduling concept; and system reconfiguring. A block diagram of the DPU system is included.

Mabry, D. J.↗

Marslink

The Marslink Project focuses on the development, dissemination, and evaluation of instructional materials about the composition, structure, and dynamics of the Martian atmosphere, surface, and interior. A multi-year effort is underway so that middle and high school students can follow a full Martian year of seasonal changes using data from NASA's Mars Observer spacecraft, and the Mars Observer Project has time to process and release the appropriate data sets. Monthly activity packets for students, teacher enhancement sessions, a teacher resource center, an on-call Mars data specialist, daily SPACELINK electronic bulletin board updates, and semi-annual NASA Select TV broadcasts will constitute the basis of the Marslink Project. Various aspects of the Marslink Project are briefly discussed.

Arvidson, R. E.↗

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

Launch Support Video Site

The goal of this project is to create a website that displays video, countdown clock, and event times to customers during launches, without needing to be connected to the internal operations network. The requirements of this project are to also minimize the delay in the clock and events to be less than two seconds. The two parts of this are the webpage, which will display the data and videos to the user, and a server to send clock and event data to the webpage. The webpage is written in HTML with CSS and JavaScript. The JavaScript is responsible for connecting to the server, receiving new clock data, and updating the webpage. JavaScript is used for this because it can send custom HTTP requests from the webpage, and provides the ability to update parts of the webpage without having to refresh the entire page. The server application will act as a relay between the operations network, and the open internet. On the operations network side, the application receives multicast packets that contain countdown clock and events data. It will then parse the data into current countdown times and events, and create a packet with that information that can be sent to webpages. The other part will accept HTTP requests from the webpage, and respond to them with current data. The server is written in C# with some C++ files used to define the structure of data packets. The videos for the webpage will be shown in an embedded player from UStream.

OFarrell, Zachary L.↗

Telemetry distribution and processing for the second German Spacelab Mission D-2

For the second German Spacelab Mission D-2 all activities related to operating, monitoring and controlling the experiments on board the Spacelab were conducted from the German Space Operations Control Center (GSOC) operated by the Deutsche Forschungsanstalt fur Luft- und Raumfahrt (DLR) in Oberpfaffenhofen, Germany. The operational requirements imposed new concepts on the transfer of data between Germany and the NASA centers and the processing of data at the GSOC itself. Highlights were the upgrade of the Spacelab Data Processing Facility (SLDPF) to real time data processing, the introduction of packet telemetry and the development of the high-rate data handling front end, data processing and display systems at GSOC. For the first time, a robot on board the Spacelab was to be controlled from the ground in a closed loop environment. A dedicated forward channel was implemented to transfer the robot manipulation commands originating from the robotics experiment ground station to the Spacelab via the Orbiter's text and graphics system interface. The capability to perform telescience from an external user center was implemented. All interfaces proved successful during the course of the D-2 mission and are described in detail in this paper.

Rabenau, E.↗

System services and architecture of the TMI satellite mobile data system

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

Gokhale, D.↗

Flow visualization of a wave packet on a rotating disk

A wave packet on a disk rotating in still air has been investigated using the somke wire flow visualization technique. The packet was initiated by a short duration suction pulse through a small surface orifice at a radius corresponding to a sub-critical Reynolds number equal to 256. Photographs show that the initial disturbance evolves into a wave packet consisting of three or four waves which spread and grow along a path dictated by the stationary crossflow vortex emanating from the orifice. The data suggests that the packet may have a higher growth rate than the stationary vortex and further experimental and theoretical study is indicated.

Wilkinson, S. P.↗

A synchronous fiber optic ring local area network for multigigabit/s mixed-traffic communication

A synchronous-ring fiber optic local area network is reported that facilitates the simultaneous transmission of packet and real-time traffic at gigabit/s rates, minimizes the amount of high-speed logic, and simplifies the user interface to the network. The novelty of the technique is based on (1) suspending in transit around the ring's circumference an integral number of data frames and (2) achieving this condition by skewing the frame clock rate a small amount. Rather than use the whole data frame as one packet destined to a specific user, many individual channels are instead time-multiplexed into the data frame. This technique only becomes feasible for local networks as data rates approach the Gbit/s range. This departure from other synchronous rings results in several advantages both in terms of system performance and hardware simplicity.

Bergman, L. A.↗

Data transport concepts for future NASA spacecraft

The anticipated increase in data quantity from NASA spacecraft over the next decade is expected to far exceed the capability of the present NASA data/information system to effectively manage and process that data. Conceptual designs aimed at providing more responsive and cost-effective methods for transporting and interpreting space-generated data are presented. Details of the Modular Data Transport System (MDTS) and Ancillary Data and Support Computing (ADSC) efforts done under the NASA End-to-End Data System (NEEDS) program are discussed. The common 'thread' throughout the data transport process involves the use of packet telemetry. Characteristics and benefits of packet telemetry are presented along with a discussion of techniques for generating and advantages of including ancillary data in each packet.

Lord, D. D.↗

The Advanced Orbiting Systems Testbed Program: Results to date

The Consultative Committee for Space Data Systems (CCSDS) Recommendations for Packet Telemetry (PT) and Advanced Orbiting Systems (AOS) propose standard solutions to data handling problems common to many types of space missions. The Recommendations address only space/ground and space/space data handling systems. Goddard Space Flight Center's (GSFC's) AOS Testbed (AOST) Program was initiated to better understand the Recommendations and their impact on real-world systems, and to examine the extended domain of ground/ground data handling systems. The results and products of the Program will reduce the uncertainties associated with the development of operational space and ground systems that implement the Recommendations.

Otranto, John F.↗

On Convergence of Development Costs and Cost Models for Complex Spaceflight Instrument Electronics

Development costs of a few recent spaceflight instrument electrical and electronics subsystems have diverged from respective heritage cost model predictions. The cost models used are Grass Roots, Price-H and Parametric Model. These cost models originated in the military and industry around 1970 and were successfully adopted and patched by NASA on a mission-by-mission basis for years. However, the complexity of new instruments recently changed rapidly by orders of magnitude. This is most obvious in the complexity of representative spaceflight instrument electronics' data system. It is now required to perform intermediate processing of digitized data apart from conventional processing of science phenomenon signals from multiple detectors. This involves on-board instrument formatting of computational operands from row data for example, images), multi-million operations per second on large volumes of data in reconfigurable hardware (in addition to processing on a general purpose imbedded or standalone instrument flight computer), as well as making decisions for on-board system adaptation and resource reconfiguration. The instrument data system is now tasked to perform more functions, such as forming packets and instrument-level data compression of more than one data stream, which are traditionally performed by the spacecraft command and data handling system. It is furthermore required that the electronics box for new complex instruments is developed for one-digit watt power consumption, small size and that it is light-weight, and delivers super-computing capabilities. The conflict between the actual development cost of newer complex instruments and its electronics components' heritage cost model predictions seems to be irreconcilable. This conflict and an approach to its resolution are addressed in this paper by determining the complexity parameters, complexity index, and their use in enhanced cost model.

Kizhner, Semion↗

The New Galileo Communication System

ave been developed to get as much data as possible from the Galileo spacecraft even without the high gain antenna. These methods include extensive data compression, a new packetized telemetry format, new error-correcting codes, new modulation, new ground receivers, and antenna arraying. (abstract only).

Galileo data compression spacecraft mission operat↗

In-Space Networking on NASA's SCAN Testbed

The NASA Space Communications and Navigation (SCaN) Testbed, an external payload onboard the International Space Station, is equipped with three software defined radios and a flight computer for supporting in-space communication research. New technologies being studied using the SCaN Testbed include advanced networking, coding, and modulation protocols designed to support the transition of NASAs mission systems from primarily point to point data links and preplanned routes towards adaptive, autonomous internetworked operations needed to meet future mission objectives. Networking protocols implemented on the SCaN Testbed include the Advanced Orbiting Systems (AOS) link-layer protocol, Consultative Committee for Space Data Systems (CCSDS) Encapsulation Packets, Internet Protocol (IP), Space Link Extension (SLE), CCSDS File Delivery Protocol (CFDP), and Delay-Tolerant Networking (DTN) protocols including the Bundle Protocol (BP) and Licklider Transmission Protocol (LTP). The SCaN Testbed end-to-end system provides three S-band data links and one Ka-band data link to exchange space and ground data through NASAs Tracking Data Relay Satellite System or a direct-to-ground link to ground stations. The multiple data links and nodes provide several upgradable elements on both the space and ground systems. This paper will provide a general description of the testbeds system design and capabilities, discuss in detail the design and lessons learned in the implementation of the network protocols, and describe future plans for continuing research to meet the communication needs for evolving global space systems.

space networks↗

Making Wireless Networks Secure for NASA Mission Critical Applications using Virtual Private Network (VPN) Technology

With so many security issues involved with wireless networks, the technology has not been fully utilized in the area of mission critical applications. These applications would include the areas of telemetry, commanding, voice and video. Wireless networking would allow payload operators the mobility to take computers outside of the control room to their offices and anywhere else in the facility that the wireless network was extended. But the risk is too great of having someone sit just inside of your wireless network coverage and intercept enough of your network traffic to steal proprietary data from a payload experiment or worse yet hack back into your system and do even greater harm by issuing harmful commands. Wired Equivalent Privacy (WEP) is improving but has a ways to go before it can be trusted to protect mission critical data. Today s hackers are becoming more aggressive and innovative, and in order to take advantage of the benefits that wireless networking offer, appropriate security measures need to be in place that will thwart hackers. The Virtual Private Network (VPN) offers a solution to the security problems that have kept wireless networks from being used for mission critical applications. VPN provides a level of encryption that will ensure that data is protected while it is being transmitted over a wireless local area network (IAN). The VPN allows a user to authenticate to the site that the user needs to access. Once this authentication has taken place the network traffic between that site and the user is encapsulated in VPN packets with the Triple Data Encryption Standard (3DES). 3DES is an encryption standard that uses a single secret key to encrypt and decrypt data. The length of the encryption key is 168 bits as opposed to its predecessor DES that has a 56-bit encryption key. Even though 3DES is the common encryption standard for today, the Advance Encryption Standard (AES), which provides even better encryption at a lower cycle cost is growing acceptance. The user computer running the VPN client and the. target site that is running the . VPN firewall exchange this encryption key and therefore are the only ones that are able to decipher the data. The level of encryption offered by the VPN is making it possible for wireless networks to pass the strict security policies that have kept them from being used in the past. Now people will be able to benefit from the many advantages that wireless networking has to offer in the area of mission critical applications.

Nichols, Kelvin F.↗

Making Wireless Networks Secure for NASA Mission Critical Applications Using Virtual Private Network (VPN) Technology

With so many security issues involved with wireless networks, the technology has not been fully utilized in the area of mission critical applications. These applications would include the areas of telemetry, commanding, voice and video. Wireless networking would allow payload operators the mobility to take computers outside of the control room to their off ices and anywhere else in the facility that the wireless network was extended. But the risk is too great of having someone sit just inside of your wireless network coverage and intercept enough of your network traffic to steal proprietary data from a payload experiment or worse yet hack back into your system and do even greater harm by issuing harmful commands. Wired Equivalent Privacy (WEP) is improving but has a ways to go before it can be trusted to protect mission critical data. Today s hackers are becoming more aggressive and innovative, and in order to take advantage of the benefits that wireless networking offer, appropriate security measures need to be in place that will thwart hackers. The Virtual Private Network (VPN) offers a solution to the security problems that have kept wireless networks from being used for mission critical applications. VPN provides a level of encryption that will ensure that data is protected while it is being transmitted over a wireless local area network (LAN). The VPN allows a user to authenticate to the site that the user needs to access. Once this authentication has taken place the network traffic between that site and the user is encapsulated in VPN packets with the Triple Data Encryption Standard (3DES). 3DES is an encryption standard that uses a single secret key to encrypt and decrypt data. The length of the encryption key is 168 bits as opposed to its predecessor DES that has a 56-bit encryption key. Even though 3DES is the common encryption standard for today, the Advance Encryption Standard (AES), which provides even better encryption at a lower cycle cost is growing acceptance. The user computer running the VPN client and the target site that is running the VPN firewall exchange this encryption key and therefore are the only ones that are able to decipher the data. The level of encryption offered by the VPN is making it possible for wireless networks to pass the strict security policies that have kept them from being used in the past. Now people will be able to benefit from the many advantages that wireless networking has to offer in the area of mission critical applications.

Nichols, Kelvin F.↗

Test Telemetry And Command System (TTACS)

The Jet Propulsion Laboratory has developed a multimission Test Telemetry and Command System (TTACS) which provides a multimission telemetry and command data system in a spacecraft test environment. TTACS reuses, in the spacecraft test environment, components of the same data system used for flight operations; no new software is developed for the spacecraft test environment. Additionally, the TTACS is transportable to any spacecraft test site, including the launch site. The TTACS is currently operational in the Galileo spacecraft testbed; it is also being provided to support the Cassini and Mars Surveyor Program projects. Minimal personnel data system training is required in the transition from pre-launch spacecraft test to post-launch flight operations since test personnel are already familiar with the data system's operation. Additionally, data system components, e.g. data display, can be reused to support spacecraft software development; and the same data system components will again be reused during the spacecraft integration and system test phases. TTACS usage also results in early availability of spacecraft data to data system development and, as a result, early data system development feedback to spacecraft system developers. The TTACS consists of a multimission spacecraft support equipment interface and components of the multimission telemetry and command software adapted for a specific project. The TTACS interfaces to the spacecraft, e.g., Command Data System (CDS), support equipment. The TTACS telemetry interface to the CDS support equipment performs serial (RS-422)-to-ethernet conversion at rates between 1 bps and 1 mbps, telemetry data blocking and header generation, guaranteed data transmission to the telemetry data system, and graphical downlink routing summary and control. The TTACS command interface to the CDS support equipment is nominally a command file transferred in non-real-time via ethernet. The CDS support equipment is responsible for metering the commands to the CDS; additionally for Galileo, TTACS includes a real-time-interface to the CDS support equipment. The TTACS provides the basic functionality of the multimission telemetry and command data system used during flight operations. TTACS telemetry capabilities include frame synchronization, Reed-Solomon decoding, packet extraction and channelization, and data storage/query. Multimission data display capabilities are also available. TTACS command capabilities include command generation verification, and storage.

Fogel, Alvin J.↗

Data Systems Dynamic Simulator

The Data System Dynamic Simulator (DSDS) is a discrete event simulation tool. It was developed for NASA for the specific purpose of evaluating candidate architectures for data systems of the Space Station era. DSDS provides three methods for meeting this requirement. First, the user has access to a library of standard pre-programmed elements. These elements represent tailorable components of NASA data systems and can be connected in any logical manner. Secondly, DSDS supports the development of additional elements. This allows the more sophisticated DSDS user the option of extending the standard element set. Thirdly, DSDS supports the use of data streams simulation. Data streams is the name given to a technique that ignores packet boundaries, but is sensitive to rate changes. Because rate changes are rare compared to packet arrivals in a typical NASA data system, data stream simulations require a fraction of the CPU run time. Additionally, the data stream technique is considerably more accurate than another commonly-used optimization technique.

Rouff, Christopher↗