2- Third Author: Michael D. Bender Department of Defense 9800 Savage Road Fort Meade, MD 20755 E-mail: mdbende@afterlife.ncsc.mil
3- For our presentation, we would like to have a projector that can be connected to a laptop.
4- No, we do not prefer to give the presentation in the form of a poster session.
5- Topic of our submission: Other- Routing Protocols for Satellite Networks
6- Title: A New Multicast Routing Scheme for IP-Based LEO Satellite Networks
7- Abstract: The IP-based LEO satellite networks
can provide lower delays to multicast applications such as tele-education
and IP-based tele-conferencing at global scale. The multicast routing problem
in terrestrial datagram networks has already been studied in the past extensively.
However, none of the existing multicast routing protocols are well-suited
for LEO satellite networks since they do not consider the limited processing
power and power supplies of the satellites. To our knowledge, there is
no multicast routing protocol specifically designed for satellite networks.
One of the newest routing algorithms for IP-based LEO satellite networks
is the Datagram Routing Algorithm. The Datagram Routing Algorithm aims
to forward packets on minimum propagation delay paths between source-destination
pairs and guarantees that the propagation delay experienced by a packet
is smaller than or equal to the propagation delay on the longest minimum
hop path between the same source-destination pair. By using the Datagram
Routing Algorithm, our new multicast protocol creates multicast trees in
the LEO satellite constellation rooted at the source of each multicast
group. The individual propagation delays to the multicast group members
are bounded by the propagation delay of the longest minimum hop path. The
multicast tree is created such that the multicast packet replication is
minimized in each satellite. Unless the multicast group membership changes,
no tree maintenance is required. Using the logical location concept, our
new multicast protocol preserves the initial tree structure despite of
the satellite mobility. The bandwidth utilization and delay characteristics
of our new multicast routing protocol are assessed through simulations.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRINCIPAL AUTHOR/CONTACT: Dr. Carl J. Beckmann Sanders, Advanced Systems and Technology PO Box 868, MER-2350 Nashua, NH 03061-0868 603-885-0761 carl.j.beckmann@lmco.com
ADDITIONAL AUTHORS: Michael Harris Sanders, Mission Space and Microwave Electronics
SPECIAL REQUIREMENTS none
POSTER SESSION no (prefer to give a talk)
GENERAL TOPIC OF SUBMISSION Products/Services
TITLE OF ABSTRACT PAYLOAD IP NETWORKING WITH THE IMPROVED SPACE ARCHITECTURE CONCEPT
ABSTRACT The Improved Space Architecture Concept (ISAC) is an advanced, scaleable, standards-based high performance computer, derived from DARPA High Performance Computing research, and adapted for space on-board processing Jointly developed by the Air Force and NASA to satisfy a variety of on-board sensor and data processing requirements, the system is designed as an affordable alternative that has the performance, power, and hardness flexibility to meet both near- and far-term needs.
This paper shows how the architecture supports the internet protocols, and how it can be used to implement on-board IP networking, as well as IP-based networking with the ground. This will allow space-based scientific and surveillance instruments to be directly connected with terrestrial networks using standard internet protocols for reduced life cycle costs and increased flexibility IP Based Space Networking Migrating to standard Internet Protocols for near-earth space networks will result in two major benefits for NASA and the Air Force. The first is cost reductions resulting from the use of a standardized, more autonomous network infrastructure using common practices and equipment as in the commercial internet; and the second is increased capability, by allowing scientists and engineers more direct and flexible access to spaceborne payloads, and allowing more autonomous payload processing including spacecraft cross-cueing and autonomous on board processing and data downlinking.
A key component in such an internetwork of spacecraft and ground stations is the Spacecraft IP Server (SIPS) which would act as a router between instruments and processing resources on board the spacecraft, and an RF link providing connectivity with the ground and possibly other space-based nodes directly. A key feature of this network is provisioning of bandwidth on demand to ground-based requestors, or client software running on the spacecraft itself. A SIPS-outfitted spacecraft may, for instance, be in continuous or near-continuous contact with the ground at a low data rate (via TDRSS low-rate multi-access (MA) channels, or commercial satellite service). But when the spacecraft or a ground user demands it, a high rate link is established temporarily for a large, fast data dump This would be provisioned autonomously and dynamically (as in the terrestrial internet) via available ground stations, or even cross-satellite links, e.g. to a commercial internet service provider, rather than relying solely on pre-scheduled service through TDRSS or other fixed assets as is done today Improved Space Architecture Concept The Air Force's Improved Space Architecture Concept program (ISAC) is developing a multicomputing architecture to meet the demanding requirements of future military space assets. NASA's Remote Exploration and Experimentation (REE) project is adapting terrestrial supercomputer technology for use in space science missions, with an emphasis on maximizing the operations per watt through the use of unhardened commercial components in space. Jointly under these two programs, Sanders has developed the ISAC architecture to meet a broad array of system applications and with efficient scaleability from 1 GFLOPS to greater than 1 TFLOPS. The architecture is based on open standards with a commercial heritage. A 16-GFLOPS testbed demonstrating a 20-node homogeneous computer has been built.
In order to protect processing efficiency, the ISAC architecture uses a two level multicomputing approach in which the application processing resource is isolated from the communication and control layer. This approach isolates the processing element from the communications infrastructure, using modular, architecturally structured nodes. Each node consists of an application-specific resource layer (processor, pre-processor, mass memory, input/output device, etc.) and a communication and control layer. Isolating the network layers enables efficient utilization of the expensive (cost and power) application processing resource by permitting it to be exclusively concerned with application execution, thus improving overall system cost/performance. Isolation of the processing element from the communication layer also permits easier substitution of the processor and de-couples the implementation from specific hardware dependence.
The Node Controller provides communication and control functions for each node. Reliable communication features such as message authentication, automatic retry, and alternate route selection for the on-board network are included. In addition, self-initialization, built-in test, power management and fault recovery operations; and features that directly support the system survivability approach, such as check-point roll-back are allocated to the Node Controller. The functionality provided by the Node Controller offers a stable architectural infrastructure that is independent of the faster-changing application processing technology. The Node Controller's "open standards" hardware and software interfaces also provide a means by which multiple vendors can (and are) inserting their products into the architecture in a "just in time" fashion to reduce mission hardware development cost and risk, and maximize capability On-Board Networking Nodes in the ISAC architecture are interconnected by a reconfigurable high-speed system network, which, in the first generation of systems, is based on Myrinet (ANSI/VITA 26-1998). Myrinet is a commercial switch-based network supporting a scaleable system configuration of up to 64,000 nodes using currently available 4, 8 or 16 port switches. A Myrinet interface consists of a pair of byte-wide links for concurrent input and output transfers, achieving a bi-section peak bandwidth of 1.28 Gbits/second per link for each direction.
Although the current generation is based on Myrinet, much of Node Controller architecture is independent of the physical layer, and will eventually support other physical layer standards. Morever, interfaces to other LAN formats can readily be accomplished over the industry standard PCI bus used to connect the Node Controller and Application Processor This would readily support, for instance, Ethernet or IEEE 1394 interfaces for lower-bandwidth on-board LANs.
At the application layer, the supercomputing Message Passing Interface 1.2 (MPI) protocol is supported as well as sockets and the Network File System (NFS). Support for TCP/IP is provided for standard socket and NFS services to further maximize application programming flexibility and portability For applications requiring complex communication patterns (1 to 1, many to 1, 1 to many, round robin), or hard real-time communications the Data Synchronization Queues (DSQ) protocol is supported. The MPI 1.2 standard allows parallel applications to be developed on commercial workstation platforms, and directly ported to the hardware testbed, demonstrating the ease of transportability of the application software across processor and technology generations.
The Node Controller is designed to support multiple simultaneous protocols, and unaccelerated and accelerated "zero copy" protocols, as well as highly reliable fault tolerant protocols, within the on-board system network. The Node Controller uses a commercial RTOS, and third party support for standard IP protocol software and extensions are available. Ground Link To support space networking requirements for the ground link, customized hardware and software functions are added to the base architecture. In software, these include support for mobility, security and authentication, and encryption, as well as TCP extensions for differentiating congestion from noise-induced packet loss. All these can be implemented in the Node Controller firmware. Some of these are available as third-party products, and some will be developed specially with space networking requirements in mind.
The RF link itself is another Application Resource,
in this case an "unintelligent" I/O resource. It will be implemented using
COTS or GOTS hardware, and will perform analog/digital conversion, RF (de)modulation,
synchronization and clock recovery, and channel coding. Cell and packet
recovery are also performed in the RF module, but network and transport
protocol processing is handled in the Node Controller. For high-bandwidth
en/decryption of real-time data streams, the two-level architecture provides
for accelerator hardware to be plugged in as a separate Application Processing
Resource.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A Study of TCP Mechanisms for Distinguishing Losses Due to Errors vs. Losses Due to Congestion
Gregory Romaniak & David Beering Infinite Global Infrastructures, LLC
Michael Rupar & Mark Solsman US Naval Research Laboratory
During the NASA-sponsored ACTS 154 Experiment, satellite channels with extremely high capacity (622 megabits per second) and geo-stationary delay were studied. The ACTS links utilized during this experiment utilized fixed Reed-Solomon Forward Error Correction (FEC) to produce satellite channels with near-fiber quality. However, even in this environment, occasional bit errors were encountered. As a result, even though many of the commercial TCP implementations tested were capable of producing reliable data transfers in the hundreds of megabits per second, the occasional bit errors had a deleterious effect on channel utilization. This resulted from the fact that TCP interprets all losses in the end-to-end connection between hosts as congestion.
In an effort to better understand the problem space and to develop some recommendations to mitigate this problem with standard TCP implementations, the 154 team formed a small focus group to study the problem in more detail. On potential result of this work would be a new Request For Comment (RFC) in the IETF.
During the spring of 2000 the 154 team issued a call for participation to the Internet community through IETF distributions, NASA distributions and personal invitations. The result was a sub-experiment that defined the future of the larger 154 experiment beyond the nominal lifetime of the ACTS spacecraft.
Two sites were equipped to support the experiment: the US Naval Research Laboratory in Washington, DC and the Lockheed Martin Space Operations facility in Houston, TX. Since these studies did not require the extremely high data rates of the core TCP performance experiments, the group elected to utilize 1.2 meter Ultra Small Aperture Terminals (USATs) from the ACTS inventory. An additional benefit of this approach was that the USATs exhibited a much higher reliability than the HDR terminals, resulting in higher effective utilization of scheduled satellite time. Data rates for these experiments ranged from 1 mbps to 4 mbps.
The experiment continued after the de-commissioning of ACTS utilizing a Ku-Band space segment on LORAL Skynet's Telstar 11 spacecraft.
This presentation will describe in detail the equipment
that was assembled at the two sites to support the experiment. Also discussed
will be the link characterizations performed on ACTS and Telstar 11, as
well as the specific results that were achieved for the mechanisms that
were evaluated. Finally, the future of this work and its relationship to
NASA missions and research projects will be discussed.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
High Rate TCP Communication over Geo-Stationary Distances
David Brooks, Arun Welch & David Beering Infinite Global Infrastructures, LLC
Scott Jakl Lockheed Martin Space Operations
Following the successful launch and on-orbit tests of the Advanced Communications Technology Satellite in late 1993, NASA made the spacecraft available for testing by universities and commercial industry. During the successful ACTS experiments program, more than 160 experiments were conducted. These experiments ranged from remote telemetry applications involving 0.3 meter terminals operating at tens of kilobits per second, to collaborative supercomputing applications involving 3.4 meter terminals operating at 622 megabits per second.
For the past four years NASA has sponsored an industry consortium to support the development of TCP/IP implementations that perform efficiently in environments with a very high bandwidth*delay product, such as those encountered on high capacity links over geo-stationary distances. The consortium consisted of NASA entities, universities, and companies from the space, computing, and communication arenas. All of the experiments performed by the consortium operated at either 155 megabits per second or 622 megabits per second. The latest iteration of this experiment (FY 2000) operated under the title of ACTS Experiment 154. With the retirement of the Advanced Communications Technology Satellite (ACTS) this phase of the effort has come to a close.
In this presentation we will describe the experiment consortium, the test bed configuration, the tools and techniques used to conduct experiments, a synopsis of the final results, and the implications this testing has on the space communications community.
The primary test bed configuration consisted of two ground stations, one at the Glenn Research Center (GRC) and the other initially at the Jet Propulsion Laboratory. Later, terminals located at Lawrence-Livermore National Laboratory and at the Lockheed Martin Space Operations facility in Houston, TX were also utilized. The test sites were connected via ACTS and also the Internet. The satellite connection provided the test link, while the Internet link was used for configuration and management of remote test assets. Each site had local network infrastructure and a suite of platforms from assorted vendors that were used for testing and data collection.
Various common TCP test tools were used to conduct the experiments. The primary tools were the ttcp (test TCP) and tcpdump programs. Project-developed software was also used to coordinate test runs and collect diagnostic information from the test bed. Post-run analysis was performed through packet trace inspection via tcptrace and xplot and through direct inspection of logged outputs. This experiment effectively demonstrated that efficient, high rate communication over geo-stationary distances is available through the use of standard TCP stacks of many commercial platforms with some tuning of network parameters. While market demand for performance under these conditions is currently very low, the vendors recognize this as an important area for further development, especially as the satellite industry faces the deployment of numerous Ka-Band geo-stationary constellations. The work of the consortium will continue under a experiment different name utilizing other satellite platforms provided by NASA and industry.
Final detailed results will be published in a NASA
document under development at this time. A synopsis of those results will
be presented the workshop. Links to further information will also be made
available.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PolyLAB: From the Classroom to Space, http://polylab.sfu.ca/
Text follows (inline):
Title: Internet communications for planetary exploration
Authors: Stephen Braham (Simon Fraser University),
Peter Anderson (Simon Fraser University)
Richard Alena (NASA Ames Research Center),
Brian Glass (NASA Ames Research Center),
Pascal Lee (SETI/NASA Ames Research Center),
Communications technology will be essential for the exploration of other planets. However, communications between instruments, robots, and eventually astronauts on the surface of a distant planet presents specific constraints that must be addressed by novel technical solutions. For instance, Mars presents varied terrains with substantial relief (craters, canyons, volcanoes, etc.), has no stable ionosphere to reliably support ground-based long-range wireless communications, and presents a hostile environment that requires high-speed video, audio and data communication to ensure safe robotic and human mission operations with the highest possible science return.
Communications from Earth to Mars with a Mars-based exploration network will require a range of protocol solutions. Flexible methods must be found to provide appropriate quality of service guarantees while still ensuring easy interoperability, short development timescales, and system robustness Project PlanetNet is a NASA/Simon Fraser University (SFU) collaboration that has been examining communication technologies, both software and hardware, that would enable the support of exploration missions to other planets, in particular to Mars. Various communications technologies have already been experimentally deployed during the 1999 and 2000 field seasons of the NASA Haughton-Mars Project (HMP), a Mars analog field research program focused on the Haughton impact crater site, Devon Island, Nunavut.
The NASA Haughton-Mars Project involves the detailed exploration of an extremely important Canadian scientific resource, namely the Haughton crater site. The HMP is yielding significant new insights into the geology, environmental evolution, and possibly the biology of Mars, as well as into the natural history of the Canadian Arctic and the effects of impacts on Earth. Scientifically, the HMP addresses many themes central to Astrobiology. The HMP also includes studies of the technologies, strategies and logistics of field exploration itself, including issues of field instrumentation, transportation, communications, and team-based scientific research in a relatively hostile and isolated environment. This includes the operation of robotic elements in the field and their synergy with human exploration, especially with regards to communications.
Within the above context, the research team hopes to achieve an understanding of the precise technological needs of communications on Mars, both at a hardware and protocol level. SFU and NASA are investigating the use ofboth space-based and ground-based wireless networking in the exploration of the Haughton Crater site, both for this terrestrial site itself and as a concept for the future exploration of Mars. From the standpoint of communications, the topography at Haughton can be characterized as presenting an intricate network of hills and valleys, including vast tracks of inter-valley rocky plateau surfaces and deep canyon systems. The region experiences periods of extreme, and transportation of hardware systems across the region by all-terrain vehicles and autonomous robots inflicts high impact and vibration loads on electronic equipment Furthermore, logistical support available at the site is limited, and the science and exploration research teams in the field are faced with the challenge of having to setup, configure, monitor and maintain complex systems to ensure that high-quality science information is collected while coping with field survival and safety concerns. All these issues pose important constraints on the technologies that may be used in the field and make the site a useful preliminary paradigm for both overall logistics and communication problems on Mars.
Space-based communication uses the Canadian Anik E1 satellite at high-power levels to achieve high data rates into the crater region. This allows the study of space-based communication at the extremes of the signal margins typically used for commercial deployment. In the field and planetary exploration context, the systems are fully integrated into the networks used in the base camp, and the radio systems used to signal across the Haughton Crater site. Furthermore, due to topographical difficulties, the C-band satellite terminal system is not directly connected to the base network, but relies on high-speed radio communications from an exposed, rugged, Mars-like test site to the less exposed base camp via the PlanetNet regional broadband data network. Presently all protocols are IP-based within the field site, but other protocols are under investigation.
Communications are supported for Telemedicine research, communications with the Johnson Space Centre Mission Control Center (MCC), as well as for public outreach. Data that needs to be transmitted includes asynchronous and synchronous delivery of images, video, and telemetry. future field operations are expected to support Teleoperation research, Telelearning, and other telematically-delivered resources.
The above complex structure indicates the complexity that will be needed for extensive human exploration of another planet, as well as what may be needed when it comes time to deploy interacting communities of robots within a region on a planetary body. Critical command and control networking infrastucture will need to be constructed in parallel, or on top of, high-speed networking solutions, and integrated into the systems and protocols needed for the interplanetary link. Inter-experiment telemetry may come from systems with highly constrained resources, without the capability to support full TCP/IP or ATM network layers, and may need to be brokered by local infrastructure. Significant two-way delay requires flexible error-handling protocols, especially in the collaborative domain.
Software and application technologies will be just
as important as the hardware technologies. Mobile computing solutions will
need to integrate into the protoco infrastructure present at the exploration
site, the interplanetary protocol, and the Earth-based processing and communication
systems. This requires standards for software development, ranging from
software component protocols through to middleware systems, distributed
processing standards, and much more. The techniques and standards used
must be flexible enough to allow easy extension and interoperation with
emerging standards or COTS solutions.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mr. Tim Burch Email: Timothy.Burch@motorola.com
Ms. Paula Holmes Phone: 480/675-2620 FAX: 623/441-6777 Email: Paula.Holmes@motorola.com Two-way Pager: 1-800-skytel2 PIN: 3473912
Abstract: Using a Generic XML Driven Translator for Downlink and Uplink data
One of the issues that is apparent in creating a viable solution to the space internet is that downlink and uplink data formats are extremely heterogeneous. This is especially true for older systems that use legacy proprietary formats. In order for a space internet solution to be viable, each space vehicle's downlink and uplink data needs to be translated to a format that can be displayed to and or commanded from internet browsers. Additionally, the information needs to be portable between different processors and operating systems. One solution to this problem is to write customized translators for every type of space vehicle. This translator would essentially convert downlink data streams into internet browser formats using HTML/XML or Java applets. It would also convert commands/requests coming from sources like HTML forms or Java applets into appropriately formatted streams for uplink. Considering the need for many customized translators it seems reasonable to consider a generic translator that can be programmed easily.
XML has quickly become an industry standard for defining data structure. The data streams required for legacy space vehicle uplinks as well as the data received from the downlinks of these vehicles has structure. The data streams that command each vehicle are defined by protocols designed for each legacy system. The data streams received from each vehicle need to be presented to humans in a meaningful and efficient manner. XML is the perfect tool to define the structure of the uplink and downlink data.
A generic translator can use XML files to determine how to translate downlink data into browser formatted HTML/XML or Java applets. It can also use XML to determine how to translate commands or requests initiating from HTML forms or Java applets into legacy protocols for uplinking. With this approach it becomes relatively easy to write XML files that translate uplink and downlink data that allow users to interface with space vehicles via internet browsers.
The XML files can also be used for other purposes including enforcing security through a firewall. This type of security could be built into the generic translator by not allowing the translator to translate any data unless the requestor had the appropriate authorizations.
The presentation for this concept would include more detail including an example of the XML files and how the translator would use them as well as information on implementation strategies.
The following picture shows a summary of this concept:
E:\mev\Work\Space Internet\IP_workshop\Abstracts\HILLS.DOC E:\mev\Work\Space Internet\IP_workshop\Abstracts\HILLS.DOC
[Ed. Note: please contact the author for the graphics.]
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mr. John Capulli Email: John.Capulli@motorola.com [John_Capulli-P25955@email.mot.com]
Ms. Paula Holmes Phone: 480/675-2620 FAX: 623/441-6777 Email: Paula.Holmes@motorola.com Two-way Pager: 1-800-skytel2 PIN: 3473912
ñ 3G Wireless Solutions
The next wave of opportunity for our industry will be known as the "Wireless Internet". In this new world, we will see rapid development of mobile services leveraging the Internet and TCP/IP connectivity. Personalized information, transaction- based services, location-and time-driven services will be among the winning services. The commercial success of these new services, however, depends upon certain key enabling technologies and standards. The operators that take advantage of these technologies, and the new revenue streams they create, will be the leaders in the new wireless Internet world.
Driven by the demands of consumers, computing, telecommunications and multimedia services are converging. A key enabling technology behind this convergence is the Internet infrastructure and protocol, often generically referred to as "IP". This is occurring because IP is so well suited to seamlessly integrate these services and technologies. The marriage of IP with wireless is inevitable.
Each of us prefers to use and carry different portable communications devices. Users should not have to care about which device they are using, or even which network they are connected to. What is important to the user is to be able to send or receive messages from any fixed or wireless terminal to any other terminal. Using an IP core, future networks will have the advantage of much greater throughput, which opens the door to new classes of applications like web and data base access, document and image transfer, and video. These are rich in content and more valuable to the consumer. Many of the new Wireless Internet services will use personalization, preference selection, prioritization of information and content, and location. These feature servers will be key to enabling the Personal Networks created by Motorola. The success of these solutions will be highly dependent on appropriate security and authentication services, as well. These feature servers will work together to create sophisticated new services using multiple inputs from diverse sources. This implies a level of analytic capability with rules control, some of which will be established by both the network operator, and the subscriber. Common to both these approaches is a requirement for higher resolution screens to manage the richer content that will be accessed. New and friendlier user interfaces, such as the micro browser, will enable a smoother interaction with the complex communications environment, richer content, and applications.
From the operator's perspective, 3G is really about offering new revenue generating services to the consumer and providing these services at lower costs. This combination improves profits by increasing overall revenues while decreasing cost. 3G offers new revenue generating opportunities through the ability to offer high speed data access to the wireless consumer. The applications range from e-mail to Internet browsing to videoconferencing. In addition, 3G lowers system costs through air interface capacity improvements, thereby increasing spectrum efficiency (2X for voice and 4-6X for data). Although 3G involves the engineering and implementation of new architectures, air interfaces, and applications, the benefits to the operator are reflected in opportunities for new revenues and cost reductions. Application of the product life-cycle concept to the telecommunications industry shows that wireline voice, wireless voice, and wireline e- mail and internet applications have been widely accepted in the marketplace. Each application, though, is in a different stage of life.
In the future, once 3G systems are deployed, FDX could create another partnership, or erect a public 3G system of their own and, just like with the 2G system, deliver information via any of the wireless networks. It would be a matter of the device and network controllers selecting the right network for delivering the information with all of the subscriber maintenance, application operations, etc. being established so that the delivery mechanism was transparent.
Motorola is uniquely positioned to provide operators
with their 3G needs. Motorola is a member, and often key participant in
all of the important standards bodies related to 3G. Motorola is currently
engaged in 3G technologies and would be interested in discussing the applicability
of these at the Space Internet Workshop and potentially pursuing a partnership
with NASA to further development of their offerings.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author:
Ed Criscuolo Computer Sciences Corp 7700 Hubble Dr Lanham-Seabrook MD 20706
(301) 794-4072 fax (301) 794-9480 Ed.Criscuolo@gsfc.nasa.gov
[2] Additional Authors:
Keith Hogie, Ron Parise - Computer Sciences Corp (CSC)
[3] Special requirements for presentations? POWERPOINT & PROJECTOR
[4] Presentation in the form of a poster session? NO
[5] What is the general topic of your submission? SYSTEM ENGINEERING
[6] Title of Abstract:
Transport Protocols and Applications for Internet Use in Space
[7] Abstract :
An Internet datagram delivery service between space systems only provides end-to-end addressability. Building systems and performing actual spacecraft operations requires a variety of services operating over the Internet datagram delivery service. This paper discusses ways to use the capabilities of the upper layer Internet protocols to support the varied communication needs of satellites. It focuses on protocols in the transport layer (layer 4) and application layer (layer 7) which use the basic packet delivery capabilities of the Internet Protocol (IP) and the network layer (layer3).
The transport layer primarily adds data stream multiplexing and reliable data delivery options for use by applications. Data stream multiplexing is provided by the port mechanism in the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP). UDP provides a basic packet delivery service similar to that used in today's spacecraft while TCP provides and automatic retransmission capability for reliable data stream delivery. Data streaming is also supported by the Real Time Protocol (RTP) which operates over UDP. Each of these protocols has benefits and limitations in various space communication environments with a range of link errors, propagation delays, and bit rates. Transport protocol selection and operational usage discussed with respect to satellite communication requirements.
Finally, actual spacecraft operations are performed by using applications running over transport protocols . The use of standard Internet applications such as NTP, FTP, SMTP, and telnet is discussed with respect to satellite operational requirements. The actual use and performance of many of these protocols by the Operating Missions as Nodes on the Internet (OMNI) project at NASA/GSFC on orbit with the UoSAT-12 spacecraft is also described.
[8] Comments:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FILE MANAGEMENT IN SPACE
Authors: Anna R. Critchfield, Computer Sciences Corporation (CSC) 7515 Mission Drive, Lanham, MD 20706. 301-805-3734; acritchf@csc.com Robert H. Zepp, Computer Sciences Corporation (CSC) 7515 Mission Drive, Lanham, MD 20706. 301-805-3766; rzepp@csc.com
Purpose
We propose that the user interact with the spacecraft as if the spacecraft were a file server, so that the user can select and receive data as files in standard formats (e.g., tables or images, such as jpeg) via the Internet. Internet technology will be used end-to-end from the spacecraft to authorized users, such as the flight operation team, and project scientists. The proposed solution includes a ground system and spacecraft architecture, mission operations scenarios, and an implementation roadmap showing migration from current practice to the future, where distributed users request and receive files of spacecraft data from archives or spacecraft with equal ease. This solution will provide ground support personnel and scientists easy, direct, secure access to their authorized data without cumbersome processing, and can be extended to support autonomous communications with the spacecraft.
Problem
In current practice, the science user is often "distant" from spacecraft science data. The ground system and operations team act together as a "middleman" that receives and processes the raw data before the end user sees the result. Science teams are often co-located with the spacecraft operations center at great expense to give the science team better and quicker access to the raw spacecraft data. Retrieval and reconstruction of spacecraft data on the ground is a significant cost and source of complexity in the ground system. Modern spacecraft are already equipped with a random-access Solid State Recorder (SSR) onboard, capable of supporting a file system, but is presently used primarily as a FIFO buffer.
Bottlenecks in the SSR to ground system and ground system to science data user communications limit the flexibility and operability of the old architecture. Currently, the contents of the SSR is typically dumped during each contact. On the ground, the data are captured, logged, stored in history files, and processed depending on their nature. The housekeeping data from the SSR is subsequently processed for user telemetry monitoring and trend analysis. The instrument science data usually requires additional data reduction before it is made available to the science users In this scenario, the ground support personnel play the role of a data broker between spacecraft and scientist. The SSR's random access capability onboard the spacecraft and the scientist's secure remote access via the Internet provide an opportunity for file-based data communications.
Proposed Solution
The proposed File Management In Space (FMIS) solution eliminates the old architecture's bottlenecks. Internet Protocols, world-wide high speed data communication and more powerful on-board computer resources are major enabling factors in migration from the old architecture to FMIS. The FMIS architecture requires changes in the spacecraft onboard software, in the ground system, and for the science data users.
The spacecraft onboard software supports the retrieval of related measurements as if they were a file. This file is identified by a name, format type, file size and created/modified time tags. Organization and management of the SSR is entirely flexible so long as the file paradigm is maintained in the SSR to ground system interface. A reliable, guaranteed delivery communications protocol is used to deliver files from the spacecraft to the ground system.
The ground system allows authorized users to request files of information from the spacecraft, and distributes the retrieved files to the requesting user. Files of archived measurements and spacecraft files are indistinguishable in format and transport protocol, when distributed by the ground system. Calibration and data reduction, currently performed by the ground system, can be migrated to the spacecraft as the application and spacecraft resources permit. Autonomous inter-platform file transfers can be supported, moderated by the ground system, by treating the autonomous system as an authorized user.
The operations team, scientists, and other authorized users view the spacecraft SSR as a directory, request files, and specify processing for those files before delivery to the requesting user. This architecture supports a spectrum of alternatives, allowing data reduction processing either on the ground or in space based on spacecraft processing power and downlink bandwidth tradeoffs. In the future, the user will be able to specify criteria for onboard data reduction, so the files downlinked from the spacecraft will contain only data that fit to the selected criteria.
Summary
The FMIS solution provides a standard way of treating
the SSR data as a collection of files, which can be browsed, selected,
and transferred to the ground. The FMIS will use the Internet and standard
tools for data requests and transfer. The FMIS solution closes the loop
between experimenter and spacecraft instrument, reduces ground system complexity
and data processing support required, and reduces the need for custom applications
to handle and process spacecraft data.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Authors: James Cutler, jwc@stanford.edu, 650-725-6794
Bob Twiggs, btwiggs@stanford.edu, 650-723-8651
Address: Space Systems Development Laboratory
Durand Building, Room 250
Stanford University
Stanford, CA 94305-4035
Title: A Testbed for Internet Based Operations
Abstract:
Global access to remote systems is becoming a reality
through advances in the Internet. Applied to spacecraft operations, this
provides the opportunity for spacecraft operators to access remote system
resources from any location with Internet access. As part of its space
operations research, Stanford University's Space Systems Development Laboratory
(SSDL) is exploring the ability of Internet based operations to improve
the cost effectiveness of space mission operation. A prototype Internet
operation systems has been developed that enables teleoperation of remote
resources, agent-based autonomous control, as well as mission product generation,
planning, and delivery. The prototype, known as Mercury, has been implemented
on SSDL's OSCAR-class amateur radio ground station and is in use to conduct
operations on SSDL's first orbiting microsatellite, OPAL. All OPAL operations
are conducted via the Internet. This paper outlines various Internet based
operation techniques and discusses the design of the Mercury prototype.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Endpoint Security Using Biometric Authentication for Secure Remote Mission Operations
Authors:
John T. Donohue, NASA/GSFC Code 584, Real Time Software Engineering Branch, ISC, Greenbelt, MD 20771. 301-286-6149, john.t.donohue.1@gsfc.nasa.gov
Anna R. Critchfield, Computer Sciences Corporation (CSC) 7515 Mission Drive, Lanham, MD 20706. 301-805-3734; acritchf@csc.com
Purpose
We propose a flexible security authentication solution for the spacecraft end-user, which will allow the user to interact over Internet with the spacecraft, its instruments, or with the ground segment from anywhere, anytime based on the user's pre-defined set of privileges. This package includes biometrics authentication products, such as face, voice or fingerprint recognition, authentication services and procedures, such as: user registration and verification over the Internet and user database maintenance, with a configurable schema of spacecraft users' privileges This fast and reliable user authentication mechanism will become an integral part of end-to-end ground-to-space secure Internet communications and migration from current practice to the future. All modules and services of the proposed package are commercially available and built to the NIST BioAPI standard, which facilitates "pluggability" and interoperability.
Problem
There are vast varieties of spacecraft users with different scope of authority. They include flight operations team (FOT), scientists, principal investigators (PI), mission planners and analysts. Within each group, user privileges and authority are further subdivided, for example, command controller and flight controller for the FOT or individual instrument for the responsible scientist or PI. The users' home "turf" is often located in different physical or geographical areas (countries, universities, offices, and personal residences). An individual user may be replaced or the user's assignment and corresponding privileges may change as a normal practice All of these issues require that the Internet, which is a communication medium for spacecraft operations, be re-enforced with a highly reliable, configurable, and user-friendly end-user authentication solution. The proposed biometrics authentication via the Internet provides necessary functionality and attributes that facilitate end-point security authentication.
Proposed Solution
The proposed authentication solution uses unique biometric signatures, such as a user's unique face and fingerprint. Access is restricted to trusted users only. Traditional authentication solutions such as PIN, password/pass-phrase, even smart/magnetic/proximity cards and digital certificates do not guarantee that only a trusted user is allowed to access a secure network or web site. This solution combines the advantages of biometrics and the Internet to offer the most secure and efficient method to verify user IDs with the least amount of capital expenditure, integration effort, maintenance, and risk. Several products have been demonstrated to Code 584, including Etrue Systems (www.etrue.com).
Operational Scenario
Users request registration and verification of their face and/or finger from their client PCs to the destination server that they want to access in a secure manner. The request is sent via a secure network (Virtual Private Network) to an authentication processing system performed by an Authentication Services Provider (ASP). The ASP administers a secure server and performs registration, verification, logging audit trail, database maintenance, and other authentication business logic and services. The authorized user can then access the requested destination server. The authentication process is seamless and works in a few seconds, similar to the credit card approval process at a retail store.
This is a modular plug-and-play solution. The client's biometric signature capture devices (camera, finger scanner) can be changed and upgraded with new devices with no significant impact on the ASP server. The ASP server can be built and maintained in house (e.g.,Goddard) or these services can be procured from an approved commercial ASP company. The user privileges are database driven, configurable, and modifiable without needing re-registration. The authentication can be performed via the WEB or via a dedicated VPN.
Benefits
Biometric authentication over the Internet is a robust and efficient method for authenticating remote users and user privileges. Automated biometric authentication will allow access of mission functions/commands and data on a secure mission server in a seamless and secure manner.
A user's biometric signature is unique and cannot be transferred or used by someone else.
There are no passwords to steal and user identities cannot be falsified Also, transactions cannot be repudiated.
An automated registration wizard to capture and
encode a user's biometric data is used. Routine verification and authentication
takes approximately two seconds, via a camera and finger sensor. A user's
privileges can be easily configured or reconfigured.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A Basis for Security Utilizing the Internet Protocol
for Command and Telemetry of Spacecrafts
James Rash, Freemon Johnson III - National Aeronautics and Space Administration (NASA)
Once you establish the basic Internet datagram delivery service over satellite RF links, you need security implementations to follow. In doing so ensures the access, authenticity, confidentiality, integrity both of the data and its path from source to destination, and prevention of denial of service attacks to all assets that are nodes between that source and destination. This paper will give a foundation for security preparation of commanding and receiving telemetry via the Internet.
Since there is no one correct solution to security the paper will be objective to any methodology, premises equipment and software configuration. It is more important that the solutions are commercially available, and relatively inexpensive. Therefore, proprietary solutions will not be discussed for purposes of cost benefits, interoperability, and most importantly taking advantage of commercial industries research efforts and capital.
Levels of security implementation will be covered by means of a risk analysis for a particular configuration. Essentially, security measures are deterrents. Depending on the level of knowledge of a "hacker" determines the level of the deterring factor. This is achieved with a risk analysis Levels of risk are directly proportional to levels of security. The paper will show the correlation and it will be up to the implementers to determine what risk they would accept for a given project's assets.
The reason why risk assessment is essential is because the levels of security/risk are also proportional to communication efficiency and cost The paper will show the correlation of added security is proportional to cost of premise equipment, added complexity in configuration, utilization of bandwidth, and CPU utilization.
This basis is a snapshot of the current technology as it is used today and how it can be configured and implemented for command and telemetry of spacecraft and instrumentation. There is also some future assessment that since the security technology is dynamic, as well as the "hackers" level of knowledge, the solutions today are volatile and iterative as well.
Freemon Johnson III National Aeronautics and Space Administration (NASA) Mail Code 585, Bldg.23 Rm. W-429 Greenbelt Rd Greenbelt, MD 20771
(301) 286-1567 fax (301) 286-1768 Freemon.Johnson@gsfc.nasa.gov
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author/Contact : Jason Gracilieri SpaceDev 13855 Stowe Drive Poway, CA 92064 858 375 2022 jasong@spacedev.com <mailto:jasong@spacedev.com>
[2] Additional Authors : Simon Dawson, SpaceDev Will Marchant, University of California, Berkeley, Space Sciences Lab Jonathan Wolff, SpaceDev
[3] Do you have any special requirements or needs for your presentations? : PowerPoint and a projector
[4] Would you prefer to give this presentation in the form of a poster session? No
[5] What is the general topic of your submission?: Mission and Program
[6] Title of Abstract: CHIPSat, 1st NASA UnEx Mission: Satellite Communications Via the Internet
[7] Abstract: See below
[8] Comments:
CHIPSat, 1st NASA UnEx Mission: Satellite Communications Via the Internet
Authors: Jason Gracilieri, SpaceDev Simon Dawson, SpaceDev Will Marchant, University California, Berkeley
This paper will detail the use of the Internet
and standard Internet protocols in the command and telemetry operations
of the Cosmic Hot Interstellar Plasma Spectrometer Satellite (CHIPSat).
CHIPSat is one of two satellites under the new NASA University Explorer
(UNEX) program. The primary objective of the project is to meet the science
requirements of the mission within budget and on schedule. A successful
communication system design will be reliable, of adequate performance,
low cost, and require minimal development effort. If these are our only
criteria for judging system validity, then the Internet and standard Internet
communication protocols are an appropriate solution to the design problem
at hand. All commanding and telemetry communication between CHIPSat and
the Mission Control Center (MCC) will be operated via the Internet, using
TCP/IP and UDP/IP communication protocols. CHIPSat will have two dedicated
IP addresses corresponding to the Local Area Networks of the two Ground
Stations, thereby allowing static routes between the MCC and the respective
Ground Stations to be established. Real-time data will be broadcast via
UDP protocols while time-tagged commanding and stored telemetry will be
transmitted via FTP sessions established between the MCC and CHIPSat. All
connections will be made using a Virtual Private Network between the Ground
Station routers and the MCC. CHIPSat is simply another node on an existing,
secure and reliable, communication network. CHIPSat is due to be launched
in the first quarter of 2002 as a secondary payload on a Delta II GPS replenishment
mission.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author:
Keith Hogie Computer Sciences Corp 7700 Hubble Dr Lanham-Seabrook MD 20706
(301) 794-2999 fax (301) 794-9480 Keith.Hogie@gsfc.nasa.gov
[2] Additional Authors:
Ed Criscuolo, Ron Parise - Computer Sciences Corp (CSC)
[3] Special requirements for presentations? POWERPOINT & PROJECTOR
[4] Presentation in the form of a poster session? NO
[5] What is the general topic of your submission? SYSTEM ENGINEERING
[6] Title of Abstract:
Link and Routing Issues for Internet Protocols in Space
[7] Abstract :
The first step in using Internet Protocols in space is to establish the basic Internet datagram delivery service over satellite RF links. This paper discusses the low-level data link and data routing issues related to using Internet protocols to support spacecraft communications. It covers issues related to layer 1 (physical), layer 2 (data link), and layer 3 (network). It does NOT cover layer 4 (transport) and above.
At the physical layer, the paper presents various applications of forward-error-correction (FEC) coding techniques, such as convolutional coding and Reed-Solomon. It describes approaches for using these techniques in ways that are independent of the protocols used at the data link layer and above.
At the data link layer, common, commercially available framing schemes are discussed along with how they can be easily deployed. A rationale is provided for the selection of HDLC/frame relay framing along with IETF multi-protocol encapsulation.
At the network layer, the Internet Protocol end-to-end addressability and routing is discussed in the context of space-based applications. Standard solutions for dealing with the intermittent and mobile links of satellites are also discussed. These include a discussion of Mobile IP and mobile routing protocols.
Finally, deployment of these protocols in both spacecraft and ground systems are discussed. Details of current implementations by the Operating Missions as Nodes on the Internet (OMNI) project at NASA/GSFC using operational space and ground systems such as UoSAT-12 and TDRS are also provided.
[8] Comments:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Potential for Using LEO Telecommunications Constellations to Support Nanosatellite Formation Flying
Stephen Horan Lujan Space Tele-Engineering Program Klipsch School of Electrical and Computer Engineering New Mexico State University Las Cruces, New Mexico 88003-8001 Phone: (505) 646-5870; FAX (505) 646-6417 e-mail: shoran@nmsu.edu
Developers of nanosatellite for formation flying applications need methods for inter-satellite communications as well as traditional space-to-ground bi-directional links. Currently, there are no direct commercial services offering such a service however, there are potential customers beginning to emerge, for example, the participating schools in the University Nanosatellite program funded by the Air Force, DARPA, and NASA.
In this paper, we will examine issues related to formation flying needs for such a program using the 3 Corner Satellite constellation as a model for a potential user. The 3 Corner Satellite constellation is composed of three nanosatellites using communications to form a virtual formation (no active propulsion for control). The satellites will be in a 350-km, >36 deg inclination orbit. The satellites need to regularly communicate position and status information between the members to coordinate and control the science mission. Expected data volumes are approximately 8 MB per day including both satellite health and welfare telemetry and mission science data.
University researchers and nanosatellite designers have a direct interest in applying wireless- Internet techniques to this type of satellite constellation. Functions to be supported include test, data transfer (space-to-space, space-to-ground and ground-to-space) for science data and coordination, distributed ground operations. To accomplish these tasks, the communications infrastructure need to be light weight and relatively low power in the space segment, preferably off-the-shelf, and capable of interfacing with standard communications and computer interfaces. One method to accomplish this is to us commercial telecommunications satellites for the data link. This would include both the space-to-space links and space-to-ground/ground-to-space links. In this paper, we will look at design issues related to supporting wireless-Internet services to nanosatellites including:
1 - expected data throughput for low-rate links found in commercial telecommunications service providers; 2 - potential access availability, duration and throughput for these links; 3 - potential protocol options and implications for nanosatellite hardware; and 4 - communications issues such a Doppler shifts.
The first two issues will be addressed using simulation
results developed at NMSU. The space channel at error rates from 0 through
0.0001 have been simulated for low-bandwidth channels for TCP/IP and SCPS
protocols. From these simulations, we estimate the required contact time
for file transfers necessary to support nanosatellite constellations. The
access times and durations, and communications parameters such as Doppler
shifts are simulated with Satellite Tool Kit using the 3 Corner Satellite
constellation and candidate LEO telecommunications satellite parameters.
From these simulations, we will look how the LEO telecommunications constellations
can support the nanosatellite constellations using technology that is currently
available.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Integrating & Applying Internet Protocols with a Reconfigurable Software Radio--The Low Power Transceiver
[1] Principal Author/Contact:
William Horne Advanced Engineering & Sciences Division ITT Industries 1761 Business Center Dr Reston, VA 20190-5333 USA 1 703-438-8148 1 703-438-8112 (fax) William.Horne@itt.com
[2] Additional Authors:
David J. Zillig, Group Leader Network Support Group/ Code 567 NASA Goddard Space Flight Center Greenbelt, MD 20771 Telephone: (301) 286-8003 david.j.zillig@gsfc.nasa.gov
Marc Harlacher Advanced Engineering & Sciences Division ITT Industries 1 703-438-3193 Marc.Harlacher@itt.com
[3] Special Requirements: None
[4] Would you prefer to give this presentation in the form of a poster session? No
[5] General Topic Experimental Activities (could also be considered a Products/Services paper)
[6] Title of Abstract: Integrating & Applying Internet Protocols with a Reconfigurable Software Radio--The Low Power Transceiver
[7] Abstract:
Emerging reconfigurable software radio technology provides an opportunity to implement new spacecraft data system architectures that can support internetworking in space and on-board spacecraft. Traditionally, telecommunications equipment destined for space have been hardware-specific devices limited to executing physical and data link layer processes with limited capability to support networking and higher level functions. The digital processing capability of software-configurable radios can support internetworking while also enabling new on-board data system architectures and operations that integrate networking functions directly into the communications devices and processes.
A software radio performs functions that are traditionally carried out solely in hardware, such as the generation of the transmitted radio signal and the detection and demodulation of the received radio signal, by using software residing in high-speed digital signal processors. Since these functions are carried out in software, the radio can be programmed to transmit and receive over a wide range of frequencies and to emulate virtually any desired transmission format. The operating parameters can be altered even after it is deployed by a simple software change.
The key component of a software radio is an architecture that uses high speed digital signal processing to perform signal transmission and reception. The radio design also needs to achieve favorable size, weight, and power consumption characteristics necessary for the space environment The basic radio architecture features digital signal processing that can be implemented using different devices including Field-Programmable Gate Arrays (FPGAs), microprocessors, and digital signal processing chips.
The significant level of digital processing available to a software radio allows it to perform higher level functions in addition to the basic waveform processing enabling new on-board data handling architectures and mission operations. For example, the radio could act as a "router" or "server" supporting each instrument or sub-system of the spacecraft allowing distributed control of these devices by different operators rather than through a centralized operations center. The advantages of a software radio, however, are also available to missions choosing a centralized system through reduced costs of implementing standard protocols and the flexibility to update them as needed.
The Low Power Transceiver (LPT) developed for the Goddard Space Flight Center (GSFC) provides an opportunity to test these internetworking capabilities of software configurable radios. The LPT is a modular, multi-channel software configurable radio leveraging a novel architecture and high speed digital signal processing to achieve favorable size, weight, and power consumption characteristics. The initial version of the LPT developed for GSFC is intended to transmit/receive S-Band Tracking Data Relay Satellite System (TDRSS) signals and receive L-Band GPS signals (L1 C/A). The receiver portion of the transceiver has 12 channels. The multi-channel capability enables a wide variety of applications especially for networking since it can provide continuous global data communications utilizing the NASA TDRS System.
The GSFC Communications and Navigation Demonstration on Shuttle (CANDOS) project is the first space-based demonstration of the LPT. The project is implementing and integrating new capabilities into the LPT to demonstrate on-orbit Space Network (SN) communications, GPS-based onboard navigation, and LPT reconfiguration. Specifically, the LPT will be tested aboard a Space Shuttle flight using the Shuttle Small Payloads Project Hitchhiker (HH) carrier system. The demonstrations will be conducted during a Space Shuttle flight in mid 2001. The paper will discuss the various CANDOS demonstrations of the LPT that will validate its Internet Protocol (IP) in space capabilities.
The reconfigurable software radio represents the
logical evolution from hardware specific communications solutions. Software
radios provide functionality that can be used to support new approaches
to science missions, such as sensor webs, as well as internetworking and
protocol support.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The NASA Space Network Demand Access System: A Building Block Toward the Space Internet
[1] Principal Author/Contact:
William Horne Advanced Engineering & Sciences Division ITT Industries 1761 Business Center Dr Reston, VA 20190-5333 USA 1 703-438-8148 1 703-438-8112 (fax) William.Horne@itt.com
[2] Additional Authors:
David J. Zillig, Group Leader Network Support Group/ Code 567 NASA Goddard Space Flight Center Greenbelt, MD 20771 Telephone: (301) 286-8003 david.j.zillig@gsfc.nasa.gov
[3] Special Requirements: None
[4] Would you prefer to give this presentation in the form of a poster session? No
[5] General Topic System Engineering
[6] Title of Abstract: The NASA Space Network Demand Access System: A Building Block Toward the Space Internet
[7] Abstract:
NASA's Space Network including the Tracking and Data Relay Satellite System (TDRSS), developed by the Goddard Space Flight Center GSFC, enables global connectivity between mission control centers and their low earth orbiting (LEO) spacecraft thus providing a building block for a future Space Internet. Current efforts to enhance the Space Network will enable automated internetworking and messaging between spacecraft, control centers, and, in the future, any authorized user located anywhere where there is a connection to the appropriate network.
To enable internetworking, a communication service must provide interconnectivity for transferring data. This communication service may involve direct cross-links between satellites or "virtual cross-links," which use communications via a satellite or ground networks. Network communication has the advantages of interconnecting missions even when they are not in view of each other and of enabling intermediate processing to occur at mission control centers. Network interconnection includes both a real-time receive capability as well as a distribution component to forward the messages to other satellites or centers. The paper will discuss the existing Space Network architecture as well as the evolving services that provide the messaging and internetworking capability. The paper will not address operations involving direct cross-links between spacecraft.
The service concept takes advantage of the emerging Space Network Demand Access System (DAS), which will provide a real-time receive capability on a continuous, global basis to LEO spacecraft. DAS utilizes the TDRSS Multiple Access system as well as low-cost dedicated equipment chains that receive data whenever a satellite transmits. GSFC is currently developing the DAS return service and plans to initiate operation in early 2002. DAS provides a communication foundation over which Internet protocols may be used. The initial phase of the system will implement Consultative Committee for Space Data Systems (CCSDS) Space Link Extension (SLE) protocols to transfer data from DAS to the users. The paper will provide an overview of the DAS architecture and its operation.
In addition to the DAS receive (spacecraft to mission center) service currently under development, the future Space Network will also provide an automated forward (mission center to spacecraft) service, thus enabling a two-way communications channel that is required to provide network (e.g., Internet Protocol (IP)) capabilities. GSFC recently completed a demonstration of this automated service using TDRSS where a small data file was (i) successfully transmitted from an Earth location to the White Sands Complex (WSC) via TDRSS, (ii) transferred the file from WSC to an Earth location via a terrestrial network, (iii) after which a TDRSS forward service was automatically scheduled, and (iv) the "message" was routed through TDRSS to a destination receiver. The demonstration also showed the feasibility of using the Space Network Web Services Interface (SWSI) prototype developed by GSFC to obtain TDRSS services. This file transfer demonstrated an automated TDRSS forward service that complements the DAS return service by providing the "forward" path for a two-way connection The paper will discuss the future automated forward service as well as the demonstration.
Although the initial phase of the Space Network
DAS will only implement Internet protocols to receive commands from and
route data to the terrestrial-based control centers and users, future evolution
will include the capability to "route" IP addressed messages to the intended
locations This future upgrade treats the Tracking and Data Relay Satellites
(TDRSs) and the associated ground station at the White Sands Complex (WSC)
in New Mexico as network nodes, or gateways, that "route" messages directly
between the originating and destination spacecraft, like the Internet.
While the data path is distinct, the methods may use the same networking
techniques and protocols as the Internet. This future capability will also
allow messages to flow directly from one satellite to another satellite
using the Space Network, specifically TDRSS DAS. In this vision, satellites
can autonomously generate messages addressed to other satellites and send
them through an upgraded TDRSS DAS that would then automatically "route"
the messages to the intended user or spacecraft. Such a "router" operation
will enable true internetworking and autonomous operations for the constellation
of Earth science satellites or other emerging science missions.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author/Contact
Dave Israel NASA/GSFC Code 567.3 Greenbelt, MD 20771 301-286-5294 dave.israel@gsfc.nasa.gov
[2] Additional Authors - none
[3] Do you have any special requirements or needs for your presentations? Projector for Powerpoint slides
[4] Would you prefer to give this presentation in the form of a poster session? no
[5] What is the general topic of your submission? System Engineering
[6] Title of Abstract - TDRSS' History as an Internet Service Provider
[7] Abstract
In 1997, the South Pole TDRSS Relay Project (SPTR) connected the NASA Tracking and Data Relay Satellite System directly to the Internet for the first time. SPTR currently provides Internet connectivity at 1.024 Mbps to the South Pole for five hours a day. The Internet connection has also enabled various other demonstrations over the last three years
This presentation will discuss how the TDRSS ground stations, the White Sands Complex (WSC), were modified to allow TDRSS to function as an "Internet service provider". The discussion will include technical and operational issues that were encountered. The history also includes the TDRSS Internet Link Terminal and other demos that have used TDRSS as an ISP
[8] Comments - none
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author/Contact
Dave Israel NASA/GSFC Code 567.3 Greenbelt, MD 20771 301-286-5294 dave.israel@gsfc.nasa.gov
[2] Additional Authors - none
[3] Do you have any special requirements or needs for your presentations? Projector for Powerpoint slides
[4] Would you prefer to give this presentation in the form of a poster session? no
[5] What is the general topic of your submission? System Engineering
[6] Title of Abstract - The Ground Station Router Interface Device (GRID)
[7] Abstract
The Ground Station Router Interface Device (GRID) will allow ground stations to connect their command and telemetry data systems to a standard COTS router. This will allow Internet Protocol traffic to flow through the station's links, making the RF link to the spacecraft a serial IP connection. The GRID is an in-house GSFC technology development.
In 1997, the South Pole TDRSS Relay Project (SPTR) installed routers at the White Sands Complex (WSC) which were interfaced to the WSC data system via a TDRSS Data Interface (TDI) which was designed specifically for SPTR. Besides providing the electrical interfaces required, the TDI also performed data scrambling and descrambling, differential encoding and decoding, and convolutional encoding. The existence of the TDI and router interface at WSC has allowed other Internet-based projects such as the TDRSS Internet Link Terminal (TILT) and Operating Missions as a Node on the Internet (OMNI) the capability to use TDRSS for IP traffic. Because the TDI was designed specifically for SPTR, it has the following limitations:
- It can only interface one router serial port to WSC - It can only operate at fixed data rates (32 kbps, 64 kbps, 128 kbps, 256 kbps, 512 kbps, and 1024 kbps) - It has to be configured manually
The GRID is proposed to replace the TDI units at WSC and to expand their capabilities. It will also be designed to allow integration into other ground stations, both NASA and commercial. The baseline GRID design is a compact PCI chassis with an embedded computer and multiple GRID Channel Cards (GCC). Each GCC will interface to a different router serial port. The GCC are configured via an interface to the embedded computer. The configuration interface will let a Ground Station computer configure each GCC to different data rates and data format options. There may also be an optional matrix switch in the chassis that will be able to patch the output from each GCC to different Ground Station interfaces/ports.
[8] Comments - none
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author/Contact
Dave Israel NASA/GSFC Code 567.3 Greenbelt, MD 20771 301-286-5294 dave.israel@gsfc.nasa.gov
[2] Additional Authors - none
[3] Do you have any special requirements or needs for your presentations? Projector for Powerpoint slides
[4] Would you prefer to give this presentation in the form of a poster session? no
[5] What is the general topic of your submission? System Engineering
[6] Title of Abstract - An IP Ground Station Architecture
[7] Abstract
Successful implementation of IP in Space will require changes to ground stations, besides changes to spacecraft. An IP ground station architecture will be presented along with discussions of the various components and the types of operations they will enable. The discussion will not include any RF components. It will concentrate on the following items: router, file server, store and forward server, and packet capture server
The architecture will be presented at the functional level for each device. This presentation is intended to instigate more discussions and development related to the ground side of a Space IP link
[8] Comments - none
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(1) Principal Author/Contact: Kerri Kusza / Mike Paluszek Affiliation: Princeton Satellite Systems Address: 33 Witherspoon St, Princeton, NJ 08540 Phone: (609) 279-9606 E-mail: kusza@stanford.edu, map@psatellite.com
(2) Additional Authors: none
(3) Special needs and requirements for presentation: Projector
(4) Would you prefer to give presentation in the form of a poster session? No
(5) What is the general topic of your submission? STANDARDS
(6) Intersatellite Links: Lower Layer Protocols for Autonomous Constellations
(7) Abstract
Using the combined resources of several smaller, smarter satellites for applications such as distributed aperture remote sensing has significant scientific, performance and cost advantages over using large, instrument-heavy satellites. In order to effectively combine the resources of autonomous, formation-flying constellations of smaller satellites, the satellites must have the ability to communicate with each other. Intersatellite links (ISLs) allow satellites to share their individual information and use their combined resources to achieve a more complex goal
Selecting the lower layer protocols for use with an ISL-based communication system demands a comparison of system requirements against the functionality of existing standards. Using an existing standard is simplest in terms of cost and time. However, standards currently used in similar applications for ISLs are based on networking protocols developed over a decade ago and are not optimized for short range space links. Modifications to optimize existing protocols for use in ISLs are not simple and are almost always proprietary.
This paper compares and contrasts existing standards such as X.25/LAP-B, TCP/IP, ATM, and even the wireless IEEE 802.11 protocol to determine which best meets the needs of the lower layers for an autonomous constellation such as TechSat 21. The comparision also includes the upcoming CCSDS Proximity-1 protocol that was created specifically for proximity-range space links, and evaluates the CCSDS Proximity-1 stack against the X.25 stack.
(8) Comments: None so far
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author:
Jim Langston Computer Sciences Corporation 7700 Hubble Drive Lanham-Seabrook, MD 20706
jlangsto@csc.com 301-794-2115
[2] Additional Authors: none
[3] Special requirements for presentations? POWERPOINT & PROJECTOR
[4] Presentation in the form of a poster session? PREFER PRESENTATION
[5] What is the general topic of your submission? NEW MISSION CONCEPTS
[6] Title of Abstract:
Operations Concepts Enabled by Cooperating Internet Spacecraft
[7] Abstract :
Putting spacecraft and instruments on the Internet simplifies spacecraft design, interface specification, integration and test. Additional standardization to provide a uniform cross-link capability enables dissimilar spacecraft to cooperate and opens up a whole new arena of operations concepts. These concepts apply to constellations of spacecraft as well as cooperation between instruments on dissimilar spacecraft and ground devices.
Internet protocol (IP)-based communication architectures support all existing operations concepts. Real-time housekeeping data is monitored during a pass using universal datagram protocol (UDP) and only requires a uni-directional down-link. Guaranteed delivery of real-time data packets is achieved using transfer control protocol (TCP). In both cases, a simple application layer function is needed. Science and engineering data are stored in the onboard file system. These files are transferred to the ground with guaranteed complete, time-ordered records using file transmission protocol (FTP) eliminating much of the traditional level zero processing This requires an adequate return link for use of TCP that can be available for most orbit profiles. For cases where the return link is not sufficient, new application layer protocols are being developed for guaranteed file delivery. An alternate approach for delivering onboard stored data is to use the simple mail transfer protocol (SMTP). In this case, the instrument or C&DH sends an email message with the file as an attachment to the principal investigator. The onboard mail server stores the file until the next contact and then automatically transfers it to the ground for delivery to the owner of the data. The interface is very simple and the flight software is based on proven ground software. All of these scenarios are based on simply having an IP-stack and associated Internet address on the spacecraft.
The IP suite supports various commanding scenarios. Basic real-time commands are sent to the spacecraft using TCP with guaranteed delivery. When the downlink is not available for acknowledgement, "blind" commands are sent using UDP. This is needed for non-nominal situations such as rescuing a spacecraft from tumbling. Stored commands are sent as a file with FTP or as an attachment to a message using SMTP. A principal investigator could conceivably log onto the instrument processor using telnet and make incremental adjustments to the instrument configuration while monitoring the results over a real-time UDP data stream.
These basic capabilities can be used to support new, complex scenarios. For instance, an instrument on one spacecraft studying solar winds could detect a solar flare. This instrument could email a message about the event to a list of IP addresses. One recipient could be a ground-based clearinghouse for the power grid to safeguard against damage from solar flares. Another could be an instrument measuring the earth atmosphere that is normally in a mapping mode. Upon receipt of the message it would place itself in a special measurement mode to study the effects of solar flares on atmospheric chemistry. It is not too difficult to imagine a third instrument that instructs its host via an onboard script to maneuver to target measurements during the event.
The next step is to leverage this new inter-operability with a new standard communications mechanism. Imagine a standard, lightweight, low power, omni-directional transceiver that supports cross-link communication between different spacecraft. Given the use of the IP suite across many missions, a spacecraft could send a small, emergency distress message to the ground via cross-links to a spacecraft already in contact with a ground station. The IP addressing would ensure the message was routed to the correct recipient Emergency response would be hastened and might save an otherwise lost mission.
Similarly, commands could be delivered to a spacecraft using a cooperative network of cross-linked spacecraft. Imagine never scheduling operations to support spacecraft contacts. During the normal work period, commands are sent to the spacecraft as needed and are automatically routed to the target spacecraft via the IP addressing, immediately. Imagine large data volumes are automatically delivered to the correct addressees on the ground via automated email type store and forward during the next spacecraft contact without operators setting up complex pass automation scripts. Imagine your instrument, which just happens to be on a spacecraft, behaves like any other instrument or device on your Internet-based network.
These scenarios also highlight the capabilities needed for constellations of spacecraft. The same cross-link capability would be used. Formation flyers would message back and forth to keep their group navigation within specifications. Constellations of nanosats would message their data to larger members of the constellation with the power for delivery to the ground. This last scenario also provides the basic building blocks for an interplanetary Internet. Application level protocols provide guaranteed packet and file delivery across large space gaps with large transmission times (such as between Mars and Earth).
In summary, IP-based addressing and standard cross-link capabilities enable operations scenarios, which take the control center concept from the emerging mode of ground-based automation into one of spacecraft autonomy and timely data delivery to the researcher. Further, the basic control model for constellations is greatly simplified by eliminating the dependence on scheduling operations around contact periods. Finally, the use of the IP-based suite of functions is less expensive due to the reuse of highly reliable, well-established software and simplified interfaces. These lead to cheaper and easier interface control documents and integration and testing processes.
[8] Comments: This topic of new operations concepts
might be a good topic for panel/audience discussion.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author/Contact : Will Marchant (marchant@ssl.berkeley.edu) University of California, Berkeley, Space Sciences Lab 7962 Leeds Manor Road Marshall, VA 20115-2624 Voice: (540) 347-1461 Fax: (954) 301-5786
[2] Additional Authors : Simon Dawson, SpaceDev; Jason Gracilieri, SpaceDev; Jonathan Wolff, SpaceDev
[3] Do you have any special requirements or needs for your presentations? : Computer with MS-PowerPoint and a projector
[4] Would you prefer to give this presentation in the form of a poster session? No
[5] What is the general topic of your submission? : Mission and Program
[6] Title of Abstract: Use of the Internet to expedite early integration on CHIPSat
[7] Abstract: The CHIPS mission is a low cost, small satellite that will perform world class astronomy from LEO. Significant challenges face projects attempting to implement such science missions.
The Space Sciences Laboratory at the University of California, Berkeley has been using Internet protocols and tools for reducing mission cost since the mid-1980s. But in order to cut costs by an order of magnitude, and to retain quality in the program, more use needs to be made of commercial tools.
The CHIPS project has made a commitment to effectively utilize modern networking and software technologies through all phases of the mission The challenge of effectively integrating geographically distributed design teams can be effectively addressed with Internet based tools Early integration tests of hardware units can be performed between remote facilities assuring a high degree of interface compliance before shipment and costly tests at integration facilities begin. And using commercial software tools and protocols to "Operate a Mission as a Node on the Internet" (OMNI) can drastically reduce the cost and complexity of operational systems. The OMNI concept utilizes commercial Internet protocols to connect all of the terrestrial project resources as well as to connect the space borne experiments seamlessly.
This paper will briefly discuss the major phases of the CHIPS project and then focus on early integration activities to show how Internet technologies are being used to cut costs and decrease risk.
[8] Comments: None
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] The PRINCIPAL AUTHOR/CONTACT is Giacomo Morabito Broadband and Wireless Networking Lab School of ECE Georgia Institute of Technology Atlanta, GA Phone: 404 894 6616 Fax: 404 894 7883 Email: giacomo@ece.gatech.edu
[2] The OTHER AUTHORS are: Ian F. Akyildiz and Sergio Palazzo
[3] For the presentation we need a projector
[4] Would you prefer to give this presentation in the form of a poster session? NO
[5] What is the general topic of your submission? System Engineering (Networking)
[6] Title of Abstract TCP-Peach: A New Flow Control Scheme for Satellite IP networks
[7] Abstract
Current TCP protocols have lower throughput performance
in satellite networks mainly due to the effects of long propagation delays
and high link error rates. In this paper, a new flow control scheme called
the TCP-Peach is introduced for satellite networks. TCP-Peach is composed
of three new algorithms, namely Sudden Start, Rapid Recovery and Over-Transmit
as well as the two traditional TCP algorithms, Congestion Avoidance and
Fast Retransmit. The new algorithms are based on the novel concept of using
dummy segments to probe the availability of network resources without carrying
any new information to the sender. Dummy segments are treated as low priority
segments and accordingly they do not effect the throughput of actual data
traffic. Simulation experiments show that TCP-Peach outperforms other TCP
schemes for satellite networks in terms of throughput and also provides
a fair share of network resources.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author:
Ron Parise Computer Sciences Corp Code 686.9 NASA/GSFC Greenbelt MD 20771
(301) 286-3896 fax (301) 286-1752 Ron.Parise@gsfc.nasa.gov
[2] Additional Authors:
Keith Hogie, Ed Criscuolo, Jim Langston - Computer Sciences Corp (CSC)
[3] Special requirements for presentations? POWERPOINT & PROJECTOR
[4] Presentation in the form of a poster session? NO
[5] What is the general topic of your submission? SYSTEM ENGINEERING
[6] Title of Abstract:
"Faster, Better, Cheaper" - Benefits of Internet Protocols in Space
[7] Abstract :
The use of Internet protocols for spacecraft communication provides capabilities heretofore either too expensive or simply not feasible with current spacecraft communication protocols. Also, the cost to implement systems using Internet protocols is much less than current approaches due to the availability of highly reliable, widely available, and standard Internet tools.
The "faster, better, cheaper" benefits of Internet protocols can be realized across the entire life cycle of a mission. They begin during initial mission definition and design, flow into integration and test, and continue on through mission operations.
The use of standard Internet applications onboard spacecraft reduces the risk of obsolescence inherent in custom protocols due to extremely wide use across all domains. These basic communication building blocks provide the framework for building onboard software to support direct user communication with payloads including payload control. Other benefits are payload to payload communication from dissimilar spacecraft, constellations of spacecraft, and reconfigurability on orbit.
The Operating Missions as Nodes on the Internet (OMNI) project, at NASA/GSFC, has shown that standard Internet technology works in space missions with demonstrations using the UoSAT-12 spacecraft. An Internet Protocol (IP) stack was installed on the orbiting UoSAT-12 spacecraft and tests were run to demonstrate Internet connectivity and measure performance.
This paper presents the end-to-end benefits of using Internet protocols for space missions and with supporting information based on real spacecraft tests.
[8] Comments:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author:
James Rash Code 588 NASA/GSFC Greenbelt MD 20771
(301) 286-5246 fax (301) 286-1768 James.Rash@gsfc.nasa.gov
[2] Additional Authors:
Keith Hogie, Ed Criscuolo, Ron Parise, Frank Hallahan, Thinh Le - Computer Sciences Corp
[3] Special requirements for presentations? POWERPOINT & PROJECTOR, INTERNET CONNECTION for live access through TDRSS to OMNI van
[4] Presentation in the form of a poster session? NO
[5] What is the general topic of your submission? EXPERIMENTAL ACTIVITIES
[6] Title of Abstract:
Demonstrations of Internet Protocols in Space Using TDRSS
[7] Abstract :
During 1999 and 2000 the Operating Missions as Nodes in the Internet (OMNI) project at NASA/GSFC performed many demonstrations using Internet protocols to perform spacecraft communication functions through the NASA Tracking and Data Relay Satellite (TDRS) communication system. This provided a high-delay and real space communication environment similar to that used by many spacecraft. This paper describes the applications and lessons learned from those demonstrations.
The primary demonstrations consisted of assembling a simulated spacecraft with an IP based communication architecture. This equipment was then installed in a van and driven around GSFC while communicating with the rest of the world via TDRS and the Internet. It demonstrated spacecraft operational functions such as commanding, file transfer, and one-way communication.
The basic equipment configuration was also repackaged and deployed on a cruise ship in the Black Sea in August of 1999 to provide a live webcast of the total solar eclipse. This mission also included using functions such as email, web browsing, audio, and streaming video over Internet protocols and TDRS.
Another demonstration was performed for 3 days in Nov. 1999 to support the JSC Inspection Day '99 activities. This consisted of the initial "spacecraft" van demonstrations with a variety of audio/video and other Internet applications added.
This paper describes the technical details of how each configuration was implemented along with lessons learned from the demonstrations.
[8] Comments:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[1] Principal Author:
James Rash Code 588 NASA/GSFC Greenbelt MD 20771
(301) 286-5246 fax (301) 286-1768 James.Rash@gsfc.nasa.gov
[2] Additional Authors:
Keith Hogie, Ron Parise, Ed Criscuolo, Jim Langston - Computer Sciences Corp Chris Jackson - Surrey Satellite Technology Ltd. (SSTL) Harold Price - VyTek Wireless
[3] Special requirements for presentations? POWERPOINT & PROJECTOR, possibly INTERNET CONNECTION for live spacecraft access
[4] Presentation in the form of a poster session? NO
[5] What is the general topic of your submission? EXPERIMENTAL ACTIVITIES
[6] Title of Abstract:
Results of "Internet in Space" Tests Using the UoSAT-12 Satellite
[7] Abstract :
The Operating Missions as Nodes on the Internet (OMNI) project at NASA's Goddard Space flight Center (GSFC), is demonstrating the use of standard Internet protocols for spacecraft communication systems. This year, demonstrations of Internet access to a flying spacecraft have been performed with the UoSAT-12 spacecraft from Surrey Satellite Technology Ltd. (SSTL). These activities are part of NASA's Space Operations Management Office (SOMO) Technology Program. The work is focused on defining the communication architecture for future NASA missions to support both NASA's "faster, better, cheaper" concept and to enable new types of collaborative science. The use of standard Internet communication technology for spacecraft simplifies design, supports initial integration and test across the Internet, and enables direct communication between scientists and instruments as well as between different spacecraft.
The most recent demonstrations consisted of uploading an Internet Protocol (IP) software stack to the UoSAT-12 spacecraft, simple modifications to the SSTL ground station, and a series of tests to measure performance of various Internet applications. The spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 5 months. The tests included basic network connectivity (PING), automated clock synchronization (NTP), and reliable file transfers (FTP). Future tests are planned to include additional protocols such as Mobile IP, email, and virtual private networks (VPN) to enable automated, operational spacecraft communication networks. This paper summarizes the work performed and results of the current tests.
[8] Comments:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Operations Concepts for the Mars Relay Satellite (MarSat)
Timothy B. Rykowski Goddard Space Flight Center Greenbelt, MD 20771 (301) 286-2460 Timothy.B.Rykowski@gsfc.nasa.gov
David J. Israel Goddard Space Flight Center Greenbelt, MD 20771 (301) 286-5294 David.J.Israel@gsfc.nasa.gov
Abstract
This presentation will describe in detail the data communications and delivery service operations concepts for the planned Mars Relay Satellite (MarSat). MarSat is a telecommunications relay satellite to be launched around Mars in support of the 2005 and beyond launch opportunities. MarSat will provide bi-directional communications between Mars assets (i.e., rovers, landers, orbiters, and probes) and Earth, as well as supporting bi-directional communications requirements between Mars assets.
The objective of the presentation is to present a candidate service architecture for providing Earth-Mars, Mars-Mars, and Mars-Earth data communications and delivery through MarSat which exhibits the following characteristics:
a. The ability to support multiple classes of data delivery latency and quality: The presentation will describe how the operations concept service architecture provides the capability to support minimum latency, non-guaranteed data delivery as well as guaranteed data delivery requirements.
b. The ability to support all communications requirements with a common service architecture: The presentation will describe how a single set of delivery services can satisfy all communications requirements from Mars assets to Earth, from Earth to Mars assets, and between Mars assets.
c. The ability to support data delivery operations in a data-driven manner: The presentation will describe how the MarSat operations concept for data delivery allows delivery operations to occur independently without the need for schedule or coordination from a ground control location. d. The ability to provide maximum interoperability with ground networks/locations: The presentation will describe how the MarSat operations concept for data delivery provides maximum flexibility and independence with respect to data routing and delivery on the ground.
The presentation is service-oriented and makes
no specific recommendations for protocol stacks to support the proposed
service architecture. The presentation will provide a list of requirements
that represent the characteristics that a protocol stack must provide such
that the proposed service model can be implemented.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Authors: Richard Schnurr
Richard G Schnurr Jr Assistant for Technology Electrical Systems Center Applied Engineering and Technology Directorate NASA GSFC Code 560.0 Greenbelt MD 20771
(301)-286-6069
Title: Flight system architectures using Internet Protocol methods
Special Equipment: Projector
Abstract:
The presentation will include several complete on board system designs using Internet protocols. Each of the major spacecraft and instrument communications functions will be described in detail. The protocols used and software interfaces required will be presented in detail. Operational scenarios will also be explored in detail.
The use of Internet Protocols and methodologies enable autonomously created connections on board a spacecraft, between spacecraft, and between spacecraft and the ground. This new capability radically increases the flexibility available to mission designers and scientists. This increased flexibility requires new operations paradigms to be developed. This presentation will explore operational paradigms enabled by standard communications channels. Many new methodologies are explored in detail in an end to end manor. System and RF channel requirements needed to enable information sharing across platforms are examined. Examples of the cases covered are two instruments linked by a low rate continuous link, instruments sending low rate emergency messages to the ground, and instruments coordinating operations through a single ground based server.
Any two space components that implement standard
Internet protocols can create a communications pipe or socket as long as
the two items have a routeable network path. Indeed even in the case where
a direct network path such as a cross-link, ground station, or TDRS is
not available files and messages can be queued and forwarded when appropriate.
For example small e-mail messages can be generated, stored, and forwarded
automatically using standard and custom servers. Information can be downloaded
to the ground using files while e-mail is used to notify people and other
spacecraft about the availability and location of the new data. Instruments
and spacecraft can send E-mail to each other that determines the way data
is taken. This greatly increased flexibility comes with a price however.
For space assets to inter-operate without a-priori knowledge and special
communications software truly standard communications protocols must be
developed. The requirements and implementations for such system implementation
will be explored in this presentation as well.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Authors: Richard Schnurr, Glenn Rakow, Evan Webb
Richard G Schnurr Jr Assistant for Technology Electrical Systems Center Applied Engineering and Technology Directorate NASA GSFC Code 560.0 Greenbelt MD 20771
(301)-286-6069
Title: On board flight network development activity at NASA GSFC
Special Equipment: Projector
Standard on board network interfaces is an important component of any Internet Protocol based spacecraft. This presentation will detail the development of space qualified network components at GSFC. The SOMO Internet in space campaign area is supporting the development of both an IEEE-1355 / Spacewire and an Ethernet 10/100 base-T flight network components. The development status and plans for each network will be detailed along with the technical goals for each program.
Spacewire is a very simple Low Voltage Differential Signaling Based network which was designed to allow many distributed processors to communicate using one, two, or three dimensional worm routed network. GSFC has developed an Intellectual Property core, which implements significant portions of the Spacewire specification. The future goals of the program are to implement the routing features of Spacewire and to implement a TCP/IP stack to allow real time operating systems to use the Spacewire interface for a standard IP network.
The Ethernet interface is by far the most popular
network interface in the world. The SOMO GSFC effort detailed will provide
a path to a flight qualified protocol chip and investigate the performance,
which can be achieved with this popular interface.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mobile-Router
Presenters Dan Shell, Cisco System dshell@cisco.com; Will Ivancic, NASA Glenn Research Center, wivancic@grc.nasa.gov
Mobile IP allows devices to roam while maintaining their sessions. Since the IP address of the device does change. Such a device is called a Mobile Node (MN). The Home Agent (HA), which is the router directly attached to the home network of the MN, forwards packets destined for the MN to the Foreign Agent (FA), which is the router directly attached to the MN on the foreign network. The FA will forward the packets to the MN. As the MN moves, it registers back to its HA through the FA. A tunnel is established between the HA and FA to forward packets to the MN.
A Mobile Router (MR) allows entire network(s) to roam. Hence, a device connected to the MR does not need to be a MN since the MR is providing the roaming capabilities. The HA will forward all packets for the mobile networks to the FA, which will pass the packets to the MR, which then forwards the packets to the devices on its networks. As the MR moves, it will register with its HA on its whereabouts via the FA.
NASA GRC has been performing joint research with
Cisco Systems to enable the development and deployment of mobile-router.
The joint Cisco/Glenn presentation will: - Describe the mobile-router characteristics;
- Describe the commercial market and applications to space; - Discuss operation
and key timing parameters; and, - Describe out Early-Field-Trial tests
including the mobile-van and aeronautical terminal.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Deployment Tests of COTS Networking Equipment in STS and ISS
Presenters
Dan Shell, Cisco System dshell@cisco.com; Will Ivancic, NASA Glenn Research Center, wivancic@grc.nasa.gov)
From October 9 through 18, NASA Glenn, JSC Mission Control Center, and Cisco will be testing COTS networking equipment in the JSC Electronic System Test Laboratory to determine the applicability of COTS equipment to STS and ISS. The goals of these tests are to:
- Show that COTS equipment can be deployed with little or no additional hardware; - Show that COTS protocols can be utilized for NASA's manned and unmanned missions; - Determine the performance efficiencies of the protocols; - Determine the parameter settings for the protocols and routers; and - Provide an upgrade path for future communications needs (150 Mbps+, wireless communications onboard, VIOP, IP-TV, HDTV, etc=85)
This will be a view-graph presentation. The presentation
will describe the tests that were perform, the success or failure of these
tests, problems and solutions interfacing COTS equipment to NASA legacy
equipment and a recommended upgrade path.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SOMO Commercialization and the Space Internet
Dr. Daniel Heimingdinger COSC Commercialization Manager
Mr. Jon M Smith SOMO Commercialization Manager
Abstract
NASA's Space Operations Management Office (SOMO),
and Lockheed Martin's CSOC organization are guided by a vision of the future.
That future includes significant participation by the private sector in
providing communications services to a broad group of domestic and international
missions. A key component of this vision is the concept of URL access to
TT&C over the Internet. SOMO/CSOC envision a future space Internet
infrastructure that includes URL's on spacecraft, at earth stations and
in program mission control centers that will revolutionize space operations.
It is expected that this vision will take 20 years to implement. This paper
presents views of this new space operations infrastructure at 2005 and
at 2020 and discusses the challenges facing NASA and CSOC as they ponder
the campaign to commercialize elements of NASA's Ground, Space, NISN and
Deep Space Networks.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Crosslink Transceiver for Integrated Navigation and Communications in Distributed Spacecraft Systems
P. A. Stadter
The Johns Hopkins University Applied Physics Laboratory Laurel, MD 20723-6099
The Crosslink Transceiver (CLT) represents an integrated crosslink communication and relative navigation system for multiple distributed spacecraft flying in formation. The CLT will support interspacecraft communications focussed primarily upon the distribution of command and control information. This includes the dissemination of directives for vehicle coordination and well as ancillary data exchange needed to support intelligent control strategies. The nature of the crosslink data is not limited to high-level control directives, indeed lower level control approaches (e.g., decentralized control methodologies that rely upon state vector sharing) are also supported. The data fields for interspacecraft communications are generic and protocol dependent, with a nominal, packetized approach that is CCSDS compliant, however critical functionality will be advantageously embedded into the protocol, possibly requiring alternative IP-like capabilities.
A critical aspect of the CLT crosslink communications approach is that it is explicitly designed to support formation flying missions, which requires capabilities such as dynamic adaptivity, scalability, and robustness. As such, the CLT is designed to simultaneous receive data from multiple spacecraft and the signal structure is such that it will support a variety of logical C2 architectures (e.g., centralized, hierarchical, fully distributed) by providing a flexible communications infrastructure.
The CLT provides both an absolute and relative navigation solution (position and velocity) and provides precision time recovery and a steered one pulse-per-second output. Orbit determination is provided by reception of GPS signals and processing by an extended Kalman filter. In addition, crosslink signals support relative navigation, with the potential for both direct solutions as well as relative GPS solutions which rely upon the computation of double differences of GPS data in a pairwise manner among spacecraft. Ranging using crosslink pseudorandom noise codes can supplement the GPS measurements in the relative navigation solution to enable more rapid convergence of the solution for low Earth orbit missions. The crosslink ranging data could entirely replace the GPS measurements for highly elliptical or deep space missions. In this case the relative clock error and range can be solved on a per-link basis. The ranges establish the relative geometry of the constellation, subject to an indeterminate rigid- body rotation.
The CLT represents a generic technology that is
required to realize the advantages of distributed spacecraft systems such
as increased capability, improved robustness, and graceful degradation
of functionality relative to complex, monolithic solutions. As such it
is a key component in an end-to-end systems approach to formation flying
missions that must address issues of control, communications, and navigation
needed to enable such systems.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FlightLinux: Enabling Migration of the Internet to Space-Based Systems
Author:
Patrick H. Stakem, QSS Group, Inc 7404 Executive Place, Suite 400 Lanham, MD 20706 (301) 867-0052 pstakem@qssmeds.com Professor of Engineering Science Graduate School, Loyola College pstakem@vax.loyola.edu
Abstract
FlightLinux is a project of NASA's Earth Science Technology Office (ESTO), Advanced Information Systems Technology (AIST) initiative. It is being conducted as a joint industry (QSS Group, Inc.) and Government (GSFC Codes 586 and 582) project. FlightLinux addresses the area of operating systems for onboard computers for traditional and constellation spacecraft missions.
As a variation of FlightLinux, and thus Unix, FlightLinux is open source. This means the source code is readily available and free. As GSFC's Omni Project has demonstrated, TCP/IP can be used to communicate with orbiting spacecraft. FlightLinux's support for TCP/IP is built in FlightLinux currently addresses soft real- time requirements and will be extended to support hard real-time, e.g., for attitude control applications.. The real-time extensions to FlightLinux provide the interrupt response and deterministic behavior required for control applications.
The use of FlightLinux will simplify several previously difficult areas in spacecraft onboard software. FlightLinux imposes a file system on onboard data storage resources. In the best case, Earth-based support personnel and experimenters may network-mount onboard storage resources to their local systems. FlightLinux not only provides a path to migrate applications onboard, it necessarily enforces a commonality between ground- based and space platforms.
An onboard file system can be implemented in bulk memory, attached to the Command & Data Handling computer. A simple Linux device driver then allows use of the bulk memory as a file system. The file system holds the Linux root files, swap space, and application code. This is the concept used in standard Linux for a disk implemented in RAM, or RAMDISK. The flight software load is then tailored to eliminate unnecessary software components and to minimize the onboard memory footprint.
FlightLinux is an evolving concept. FlightLinux is an embedded, real-time version of the open source Linux operating system for use onboard spacecraft. FlightLinux will provide a level of commonality between science, instrument development, integration and test, and operational platforms. It will also enable the use of common communication protocols and utilities, as well as a common file system The use of FlightLinux is seen to reduce the development time and cost of flight systems, while increasing the timeliness and accessibility of onboard science data. The Linux kernal functions will fit within the resources of current and planned systems. We have demonstrated a minimally functional system in 1 megabyte of ram.
A wide variety of laboratory bench-top systems, as well as the WIRE spacecraft on-orbit test bed, provide a set of opportunities to test the concepts expressed and evolved in this project. A set of legacy flight code in the C language, POSIX compliant, is available.
The concept of FlightLinux enables the onboard portion of the end-to-end satellite networking issue. Already, spacecraft data travels on the Internet, under TCP/IP protocols, after receipt at the ground station Downlink data is typically CCSDS encapsulated, and instruments talk to an onboard instrument computer via a 1553 bus and dedicated high-speed interfaces using synchronous serial protocol, for example. The use of onboard Linux will allow the connection of instruments in the same manner, or allow for the connection of instruments in a LAN architecture, perhaps using ATM, or IpV6 protocols. The central instrument computer, then, acts more like a router. The feasibility of implementing IP-over-1553 will be investigated as an interim solution.
To enable the migration of functionality onboard,
the FlightLinux concept provides the same operating environment as the
laboratory bench-top system. It also provides a common environment with
instrument and component integration and test. The FlightLinux concept
addresses a wide variety of issues in the historically complex world of
flight software.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++