[American Institute of Aeronautics and Astronautics AIAA Modeling and Simulation Technologies Conference and Exhibit - San Francisco, California ()] AIAA Modeling and Simulation Technologies

American Institute of Aeronautics and Astronautics

1

Evaluating Space-Based Protocols through the Protocol Research Evaluation Environment (PREE)

Richard A. Slywczak*, Thong Luu†, Allen Holtz‡, Kul Bhasin§ NASA/Glenn Research Center (GRC), Cleveland, Ohio, 44135

Thaddeus J. Kollar** Integral System, Inc./NASA/GRC, Cleveland, Ohio, 44135

As NASA continues to develop and expand the vision for space exploration, software and hardware based tools will be essential for successful missions. The new missions, to explore the Moon and pave the way for the return of a manned flight, will require a new extensive and flexible communications network that has not been available on previous missions. When man returns to the lunar surface and, eventually, establishes habitats, communications requirements will require 24/7 coverage for the entire surface. This will necessitate a two-fold approach: first the development and adoption of new technology and, second, the adaptation of technology that is currently available.

Maturing these technologies requires tools that can evaluate new concepts in an emulated

environment before they become launch ready. Additionally, even though these technologies are needed in the 2010-2014 timeframe, the evaluation tools must be developed now so that they can reach the required level of maturity. This paper will discuss the Protocol Research Evaluation Environment (PREE) that permits future missions to evaluate and test protocols that are effective on long duration, long distance missions where the communication environment is particularly harsh. In the current environment, scenarios represent realistic missions by combining the components to create an end-to-end data flow between lunar-based and Earth-based assets.

Tools like PREE will help to evaluate future missions by focusing on specific

characteristics that will present unique challenges. However, once these tools are developed and become mature, they will become critical to mission planning, design and development.

I. � Introduction ver the past year, NASA has been aggressively evaluating current and new technologies to implement the Vision for Space Exploration1. With the goal of returning to the Moon and then attempting to place humans on

Mars, there are a number of unique challenges that NASA must encounter and overcome. One of these challenges will be not only continuous but effective communications between each of the mission elements. Over the past decade, NASA and other agencies have been developing communications protocols, whether extensions to TCP/IP or entirely new protocols, such as the Space Communications Protocol Standards (SCPS)2 or the Multicast Dissemination Protocol (MDP)3, to deal with the harsh realities of the space environment. Due to large latencies and high bit error rates, communications on these missions will be stressed to their limits. To this end, NASA/Glenn Research Center (GRC) has developed the Protocol Research Evaluation Environment (PREE) as an effective tool for testing these protocols.

The goal of PREE is to allow researchers to implement protocols either in a gateway or in-kernel configuration and test them through customized scenarios. As part of the scenario definition, the elements can be specified along with the protocols that will be used within the mission. During the scenario run, data will be transferred between * Computer Engineer, Satellite Networks and Architectures, 21000 Brookpark Road, AIAA Member. † Computer Engineer, Computational Sciences Branch, 21000 Brookpark Road ‡ Computer Scientist, Computing Science Division, 21000 Brookpark Road § Manager, Communications, Computing Electronics, and Imaging Projects 21000 Brookpark Road, AIAA Member. ** Systems Engineer, NASA: Office of the Chief Information Officer, 21000 Brookpark Road

O

AIAA Modeling and Simulation Technologies Conference and Exhibit15 - 18 August 2005, San Francisco, California

AIAA 2005-6418

This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States.


2

elements using the specified link conditions. Either during or the end of the emulation run, data can be visualized through a custom three-dimensional graphics application developed specially for this environment.

As NASA continues to develop the Space Exploration concepts and candidate missions, the value of software and hardware based tools becomes essential to develop and refine these missions. PREE is the one of the first tools that can be used for future missions. This paper explains the tool and its architecture rather than concentrating on evaluating protocols or explaining the limitations of communications in the space environment for long duration missions. NASA/GRC is currently evaluating a series of space-based protocols for a sister project, Space Communications Testbed (SCT)4 and will make these results, along with the protocol integration with PREE, available.

This focus of this paper is three-fold. First, the paper concentrates on the design and development of PREE by identifying and discussing architectural elements of the environment. It stresses elements, such as the link emulator and protocol gateways, that make this environment appropriate for evaluating protocols for long duration communications. Second, the environment is discussed from a user viewpoint emphasizing scenario setup and configuration. The scenario definition provides the degree of realism into the environment that permits the testing of prospective missions. Currently, the environment provides two pre-configured scenarios that emphasize constant and variable communications parameters in Earth to Moon communications. Third, the paper discusses the PREE analysis environment where data is collected through the Linux utility ULOG and evaluated through a custom visualizer. Viewing the data graphically provides an easy-to-use representation of the communicating elements, communications patterns and an indication of the quantity and quality of the transferred data.

II. � Space Exploration Vision Space Exploration under the Vision for Space Exploration is dividing into three logical stages, where the next

increment or stage will build upon the previous one. • Stage One: the first stage involves short missions to the moon lasting seven days or less. • Stage Two: the second stage will utilize pre-deployed equipment with lunar missions lasting up to 98

days. • Stage Three: the third stage involves long term missions ultimately arriving at Mars.

Each stage of space exploration requires constant communications via a space network so that human missions will be able to communicate with Earth-based station continuously. 5 The PREE environment only evaluates lunar communications.

The complete space network will consist of smaller specialized and segmented networks, where each will have different characteristics. Some of these specialized networks include the following:

• Backbone Networks include communications between Earth-based and space-based assets, such as satellites orbiting the Earth, Moon, or Mars. Backbone networks imply a significant delay for the data transmission and, mostly likely, will use an optimized protocol. These links typically utilize S-Band (7 Mbps) or Ka-Band (6.25 Mbps).

• Access Networks consist of communications between the outer edges of a backbone network and spacecraft, mission vehicles and other entities around and/or on the surface of a planet. Since these distances would not incur a large latency, missions have a greater choice for desired protocols.

Surface networks are made up of three individual types of networks: the Surface Wide Area Network, the

Wireless Local Area Network, and the Personal Area Network. Each individual network has its own characteristics. • Surface Wide Area Networks include large or fixed structures including landers, habitats, and rovers.

They may be separated by as much as 60 kilometers. • Wireless Local Area Networks are made up of mobile and medium size systems such as robots and

astronauts. These systems may be separated by as much as 5 kilometers. • Personal Area Networks are made up of wired and wireless links between small devices, sensors, and

subsystems on a larger system. All of these networks, both space and ground, must integrate seamlessly and provide transparency to the user in

a similar way the terrestrial Internet operates. The user and/or application should only be concerned with the end points (i.e., the source and destination) of a transmission. These networks must be fault tolerant, flexible and self-healing so that they do not contain a single point of failure. Robust networks will be required, since data critical to the lives and health of a crew will be sent over the network. Finally, the networks should implement store-and-forward techniques, so that data can traverse the network even though nodes may be unable to communicate.


3

Multiple applications will utilize the space network. Each application may produce network traffic with different characteristics. For example, some applications may have bursts of data for several minutes and then no data transmission for hours. Other applications may be able to tolerate moderate packet loss; however, the transmission rate must be significant for an extended period of time.

III. System Architecture The system architecture, as shown in Figure 1, provides the overall view of PREE by showing each of the major

components. Also included in the diagram are the interactions between each of these components along with the data flows. With the exception of the visualizer, the PREE objects are completely written in the Java programming language and implement many of the concepts of the Java Enterprise Edition7 including servlets, web services, etc. Communications between each of the components is accomplished via the Remote Method Invocation (RMI) methodology that allows a client program to interact with the corresponding server component through a well-defined Application Programming Interface (API). Data is passed between the components through the eXtensible Markup Language (XML)8. Each of these technologies will be defined and explained during the discussion of the System Architecture. PREE is divided into three main components, as follows:

• Client: The client represents a standalone application that can run either on the PREE environment or on a remote system. Its purpose is to provide the user with a Graphical User Interface (GUI) to developed scenarios that can execute within PREE. During the scenario development, the user can choose from a series of elements including ground stations, satellites, planets and datalinks. The user can modify the properties of each of these elements, for example specifying the type of protocol(s) that can operate over a datalink. Once the file is complete, it is saved to a local disk in XML format and then validated before transferring to PREE. Once the user validates access to PREE through a username/password combination, the scenario can be transferred to the processing system and scheduled for processing.

After processing begins, the user can use the interface to check the status of the scenarios, as well as, providing job control functions, such as stopping the scenario.

• Emulation Manager (EM): The EM is the part of the PREE cluster that is resident at NASA/GRC and provides multiple uses to the testbed. It validates the username/password combination before the user has access to the cluster. This service is provided by the Java technique called web services though an Apache product called Axis, that allows a well-defined interface to provide, in this case, access services. The EM is also responsible for parsing the transferred XML file according to the functional elements and distributing them to the processing nodes. For example, the ground station information will be parsed from the file and placed in the processing node XML file.

• Nodes: The nodes are individual computers that emulate portions of the scenario and are segmented with respect to functionality, such as the CEV, lunar-orbiting satellite or ground station. The parsed XML file is provided to the Node Emulation Manager (NEM), which is a process running on each of the nodes that parses the node specific file and allocates resource on the node in accordance with this definition. Each node contains two interfaces. First the Data Network Interface (DNI) provides the network interface that carries the data that is relevant to the actual scenario, such as science or commanding data. The Management Network Interface (MNI) carries the data that is relevant to the configuration of each node, such as the XML file(s). When the scenario is ready for processing, each of the nodes will be prepared for processing the scenario.


4

A. XML Data File

The XML file is the interface between the scenario defined by the user through the GUI and the processing system that will emulate that scenario, see Figure 1. The file is comprised of elements that define the scenario based on the components that the user selected through the client program and the configuration of those components. The elements of the XML file are summarized as follows:

• Start/Stop Times of the Scenario: This element represents the emulated time that the scenario will execute. For example, if the desire is to look forward to a 2014 launch of the CEV, those times are described by this element. The format of the element is date and time with the granularity to the second.

• Planet: Defines the central bodies with which the corresponding elements can associate at the start time of the scenario. During the emulation, elements can transfer between planets and, therefore, change their central body. Current planet definitions include the Earth and Moon.

• Satellite: Provides the basic definition for an entity that represents a satellite with specified orbiting characteristics. Current descriptors are the satellite name that provides a unique tag for the satellite, ephemeris data that describes the orbital characteristics of the satellite and central body that describes the entity that the satellite is orbiting.

• Crew Exploration Vehicle (CEV): The CEV provides the basic definition for the new, modular launch vehicle that NASA is currently developing. PREE wanted to provide a glimpse of the communication patterns for the CEV. Currently, the definition is very similar to the satellite parameter, but the goal is to provide more detail as information becomes available. The descriptors are the same as the satellite.

• Ground Station: Describes a ground facility to which the satellite or CEV can transmit data. In PREE, the DSN9 dishes that are located in Goldstone, California, Canberra, Australia and Madrid, Spain represent the ground stations. The current descriptors for the ground station include the ground station name a unique identifier for the ground station, the location that defines the location in terms of latitude and longitude and the central body, which indicates the planet location of the ground station (i.e., provides future expansion to locate a ground station on the Moon).

• Antenna (Sub-element to Satellite, Ground Station and CEV): The antenna sub-element provides the ability to augment the definition of either a satellite, ground station or CEV. The current descriptors are the antenna name that uniquely defines the antenna, the bandwidth that defines the amount of data the antenna can transfer and the dish diameter that defines the size of the antenna. In PREE, all antennas are assumed to be parabolic dishes.

Client Axis Tomcat Apache

XML

Login Info Web Services

Emulation Manager

Nodes

RMI

Management Network Data Network

Figure 1: The PREE System Architecture


5

IV. Scenarios The PREE development team created two well-defined scenarios where each scenario provides unique aspects of

the communications system. The goals of the scenarios were to test the system from an end-to-end perspective by providing as many of the NASA elements as possible and emulating realistic space communications conditions. Testing the various space-based protocols requires a diverse, multi-layered communications platform to emulate the harsh space environment that lunar missions will encounter and the PREE platform provides these characteristics. The default PREE scenarios are the following:

• Communications between a ground station and a satellite orbiting the Moon. In the first scenario as shown in Figure 2, space-based communications will be tested between a ground site and a satellite orbiting the Moon during valid contact times. The ground-based assets emulated are the Deep Space Network (DSN) dishes that are located in Goldstone California, Madrid, Spain and Canberra Australia. The space-based asset orbiting the Moon represents a typical science-based mission satellite with Earth-based communications capabilities. The unique aspect of this scenario is to test the system with a constant delay and BER. The communications stream between the entities represents both commanding data and science data transfers.

• Communications on a dual link between the CEV and the Earth or Moon while the CEV is performing a transition orbit. The second scenario as shown in Figure 3 provides a communications aspect from the view of the CEV. Communications will be tested as the CEV is in transition moving from an Earth-based to a lunar-based orbit. Since communications will be presented from the aspect of the CEV, there are two distinct links. The first represents communications between the CEV and the DSN dishes and the second link is from the CEV to a Moon base. The unique aspect of the second scenario is that the delay and BER are variable during the transition orbit and must be updated in the architecture. For the first link, CEV to Earth, the delay will increase as the CEV moves farther from Earth orbit and, for the second link, the delay will decrease as the CEV gets closer to the Moon. The BER will be variable as the transition orbit occurs due to disturbances in the atmosphere and these characteristics must be realistically represented in the environment. The communications stream on both links represents both commanding and health and status data.

V. � Component Architecture In the system architecture, the major components of PREE were described along with the interconnections of the

data flows between them. In the component architecture, individual nodes that represent the components of the scenario will be described. Once the scenario file has been parsed, it will be distributed among the nodes for processing in the emulation environment. This includes not only the nodes that represent the space-based assets, but also those that support the emulation system for data storage and post-analysis processing. The component architecture is shown in Figure 5. This figure indicates those components that are in Earth orbit and those that are in lunar orbit; the exception is the CEV, since it crosses between the Earth and lunar segments.

In this study, the goal was to determine how space-based protocols would impact missions that extend beyond Earth orbit but limiting to lunar missions. In addition, the secondary goal was to develop a system where protocols that address the long latency, high BER issues could be easily implemented and tested in a controlled environment. Given these two goals, this section will thoroughly explain each component and focus on the Delay/BER Generator and the Protocols Gateways.


6

A. PREE Link Infrastructure

The PREE cluster consists of twelve computers designated spectra01-12. Spectra01 acts as the delay/BER generator and is configured as a bridge between spectra02 and spectra03. Spectra02 and spectra03 act as protocol gateways as shown in Figure 4. Each system in the PREE has a gigabit Ethernet interface for management and system traffic (not pictured). Spectras 02-12 each use a gigabit Ethernet interface to connect to their respective test VLANs10, but it has been slowed to 100 Mbps. The spectra01-spectra02 and spectra02-spectra03 connections are back-to-back at 100 Mbps.

S04

VLAN1 S08

S10

S06

S12

S05

VLAN2 S09

S11

S07

10.10.2/24

10.10.3/24

S03 SCPS GW

S01 Delay/ BER

Bridge

S02 SCPS GW

10.10.1.2

10.10.1.3

Long Delay Link Delay = 1.23 sec. (one way) BER = 10-6

Figure 2: Scenario 1 – Communications with a lunar orbiting satellite

Long Delay Link Delay = Variable BER = 10-6

Figure 3: Scenario 2 – Communications with a CEV in a transition orbit

Figure 4: Link Architecture showing the connection via Virutal LANS


7

B. Delay/BER Generator Several candidate open source projects were reviewed and evaluated for Delay/BER Generator in PREE.

Netem11 was selected because 1) it is actively maintained and 2) as a part of the Linux QoS subsystem12, it is easy to create sophisticated chains of filters and actions to apply to each packet. However, Netem lacks a bit error generator by default, so a patch to the Linux kernel and iproute13 tools was written to provide that capability.

The host providing delays/errors, spectra01, is inserted as an Ethernet bridge14 between two routers/protocol gateways, spectras 02 and 03. As a bridge it is transparent to network layers above the data link, so only a single IP subnet is required. To allow a delay or BER to affect a link, the end points must be on different VLANs. This forces the traffic to be routed through the protocol gateways and across the bridge.

During PREE scenarios, filters are based on the packet source/destination IP address and time/date the kernel receives it. The rules are loaded into the netfilter15 mangle table prior to the start of the scenario. To avoid duplicating a set of netem disciplines for each interface, they are assigned to an “intermediate queuing device”, through which all filtered traffic is diverted. The intermediate queuing device is available as a kernel and iptables patch.

Statistics are collected on spectra01 using a kernel netfilter target called ULOG and a user-space daemon called ulogd. After each packet experiences delay/BER emulation but before it is transmitted, it passes through the ULOG target which captures and queues information for ulogd. The information includes Ethernet, IP, and transport layer headers, the kernel time down to the microsecond, plus a user-defined field called a prefix. Spectra01 uses the prefix to log the name of the link and the delay and BER applied. Ulogd is configured to send the information to a MySQL16 database, although it can also be directed to a flat file or tcpdump-like pcap file. The capture rate of ULOG/ulogd in the PREE environment is high at around 96% for gigabit speeds. The ULOG data is available for post-processing analysis once the execution of the scenario file has been completed and is used extensively in the custom visualization environment developed specifically for PREE.

Additional configurations of the delay/bit error generator are possible. One example is to install multiport network cards into a computer with an expansion bus of adequate performance to provide wire speed to each port. Every client can be connected directly to the system so that it acts like a network switch, with the appropriate LANs created internally with kernel bridges. Filters can be applied to the bridges instead of IP addresses, and alternate network-layer protocols can be tested.

Delay/BER Generator

Protocol Gateway

Protocol Gateway

Satellite

Application

Ground Station

Controller

Application

CEV

Visualization

Emulation Data

MySQL

STK

Madrid26

Canberra26

Goldstone

Earth Moon

Figure 5 – The component architecture of PREE


8

C. Protocol Gateways Generically, protocol gateways are routers that receive a stream of data in one network protocol and forward it

using a different protocol. The protocol gateways are bi-directional and, therefore, the data stream that reaches the space asset can also has a response data stream that goes through the same gateway. They are useful for allowing systems that only speak different protocols to communicate transparently. For example, TCP is a very common protocol in which every packet sent must be acknowledged by the receiver. These protocols are unsuitable for long delay links because the sender spends too much time waiting for the acknowledgement and the connection is slowed significantly. It’s also unsuitable for error prone links because packets can be corrupted or lost, resulting in no acknowledgement being sent and the connection hanging. Through the use of either new or TCP-enhanced protocols, the techniques that provide high-quality data transmission on the terrestrial Internet can be adapted to the space environment.

One solution to this problem is to use a TCP-based protocol called Space Communications Protocol Standards (SCPS). Instead of acknowledging every packet, SCPS will only transmit messages about packets that don’t arrive at the destination, which is referred to as the Selective Negative Acknowledgement (SNACK) scheme and, therefore, only missed messages are resent to the destination. Most network devices don’t speak SCPS. However, they can still take advantage of it, if TCP/SCPS protocol gateways are used at each end of a long delay/error prone link.

The Mitre Corporation developed a SCPS reference implementation for Linux that includes a gateway daemon. This is the gateway software used in the PREE at GRC. Each of the two VLANs in the PREE has a router running the Mitre SCPS gateway. A delay/BER generator sits between the routers. When the gateway daemon is started, all traffic forwarded through the routers is automatically directed through the gateway by netfilter rules.

The Mitre gateway daemon only accepts TCP traffic from its LAN; UDP and ICMP are dropped. The daemon only affects routed traffic; traffic originating from the router itself is unmodified. A different implementation of a SCPS gateway daemon would be required to convert locally originating traffic.

D. Application The application nodes represent typical applications that will reside on either the satellite or CEV and,

eventually, scenarios that could be expanded to include space habitats. Given that the protocol gateways will transform each packet into an enhanced space-based protocol, the goal was to execute traditional terrestrial applications on these nodes. Some example include, web browsers, such as Netscape, or network performance tools, such as ttcp17 or iperf18.

Assuming that the application is executing on the ground node on the terrestrial Internet, the packets will go to the DSN for transmission to the satellite or CEV in lunar orbit. Before the data leave the DSN, it will be converted into the SCPS by adding options to the TCP/IP packets and then sending them to the destination. The same process will occur at the destination by transforming the packets (i.e., removing the options) before the data is transferred to the final destination on-board the satellite.

In the emulation environment, the application node is represented by one of the spectra machines and has a gigabit Ethernet connection. The nodes will execute third-party applications in either interactive or batch processing mode.

E. Satellite The satellite nodes were developed to represent a single satellite, single mission that is in a lunar orbit. It was

defined to be an orbiting body that will contain one or more antenna, which is represented by one or more parabolic dish. All orbital information for the satellite was generated via the Satellite Toolkit (STK), which is a commercial application. Currently, there is no assumed internal structure to the satellite, since the goal was to only emulate the data throughput. However, there is an assumption that a computer is aboard the satellite where a third-party commercial application is executing. That application has the ability to communicate with the ground through the DSN.

For communication purposes, the satellite uses the application node for data generation and all data is transported via the satellite antenna to the ground system. The satellite will maintain its location data and write this data to the database for visualization capabilities. The satellite will also monitor the antenna with the ability to set the bandwidth to either accelerate or throttle the data flow based on the type of antenna being emulated.

In the emulation environment, the satellite node is represented by one of the spectra machines that are connected to the local network via a gigabit Ethernet card.


9

F. Crew Exploration Vehicle (CEV) The CEV represents the new crew vehicle that NASA is planning to replace the Space Shuttle in the 2010

timeframe. It will be launched in segments that, depending on the end goals of the mission, require assembly of the pieces in space to successfully complete the mission. The goal for the emulation environment is to introduce the vehicle as an element and to develop the CEV as requirements are defined and more information is released in the public domain.

The current implementation of the CEV is very similar to that of a satellite where it is emulated as an object that contains an antenna. As the requirements define the type of antenna and data transmitted from/to the CEV, the emulated definition will continually be developed. The major difference between the satellite and CEV is that it will contain different orbital characteristics, since it is required in Scenario 2, to make a trans-lunar maneuver to orbit the Moon. Communications from the CEV will be either directed at the Earth or the Moon base, depending on either the location of the vehicle or the type of data that must be transmitted.

In the emulation system, the CEV is represented by one of the spectra machines that are connected to the local network via a gigabit Ethernet card.

G. Deep Space Network (DSN) The DSN logically represents the DSN that is currently resident in Goldstone, California, Madrid, Spain and

Canberra Australia. In the emulation system, the dishes are divided into their respective components, but also include a fundamental change from the actual system. The real system is a highly scheduled environment that will provide slots for elements to communicate; systems only have the time that is allocated in a particular slot to communicate. If NASA adopts the networking model, as used in PREE, the highly schedule system becomes an impediment to the getting the data through the system as efficiently as possible. For this reason, PREE started to look at an on-demand DSN system. To this end, PREE contains Ground Station Controller (GSC) that will be responsible not only for the coordination of the DSNs, but also to function as a router by trying to get the data to appropriate DSN dish. On the communications uplink, the GSC will use the terrestrial Internet to route the data to the appropriate dish and, if a dish looses communications with the space asset due to orbital movements, the GSC will route the data to the next available dish. For the uplink segment, the DSN dish becomes transparent to the requesting user. On the downlink segment, the space asset will continually transmit to the DSN dish with which it has line of sight availability and the GSC will be responsible for routing the data to the user in a reliable manner via traditional terrestrial mechanisms. For the downlink segment, the DSN dish that the data arrived through is transparent to the sender and the receiver.

Whether NASA implements this model or some variant will be determined by the requirement definitions and the scenarios that will be developed by exploration systems. PREE will continue the development of the networking model, as well as add a scheduled system, to show the possibilities of future communication.

H. MySQL MySQL was chosen as the data repository for PREE and contains not only the scenario configuration data, but

also the resulting communications and access information from the emulation runs. Numerous sources will add to the database and the user will be able to either use the PREE Visualization program to view the emulation run or query the database directly based on their own requirements. In addition, the database can be exported to a number of formats, if desired. The current version of MySQL running in the production environment is 4.1.11-standard.

Each scenario will be a database with the user-defined name of the scenario serving as the name of the database. The table structure within the database will be created, as shown in the following table.

Table Name Function

Scenario Contains high-level information about the scenario, such as the start/stop times.

Entities Contains all of the entities defined by the user in the Scenario file. This table will be used for scenario reconstruction, if needed.

Antenna Contains all of the antenna information and the relationship of the antenna to the space asset.

Position Contains the position data for the space assets Access Contains the access information between components. Delay Contains the link delay as a function of distance. Data Transfer Shows the output data transfer information that is provided by the ULOG


10

Table Name Function service.

Routing Shows the network topology at various times and provides routing information for each of the nodes.

Event Indicates specific events that may occur during the emulation run. Table 1: List of Tables Contained in a Scenario Database

I. Satellite Toolkit (STK) To ensure compatibility between processes, orbit propagation and delay reports where generated through the

commercial product STK by Analytical Graphics, Inc. STK is becoming the industry standard for simulation of space and terrestrial scenarios. Since the basic STK product provides simulation capabilities for Low Earth Orbit (LEO), the AGI companion product, Astrogator, was used to provide lunar orbiting characteristics. The reports produced by STK include the following:

• DSN Access Reports: Contains the start/end contact time and duration for which each DSN station has access to the specified objects in the scenarios.

• Space Asset Position Reports: Contains the positions of the CEV and satellites based on time. These report will provide the elements with their locations.

• Propagation Delay Reports: Contains the delays that each asset will encounter during the emulation run. The delay/BER generator will use this information.

The current implementation of PREE requires the scenario to be preconfigured into STK and then the simulation

executed before the emulation can be started. Once the STK simulation phase has been completed, the reports can be distributed to each of the scenario elements and the emulation can begin. In future revisions of PREE, the STK simulation will be automated so that the scenario reports can be generated without manual intervention.

VI. Visualization Visualization plays an important role in simulations and emulations. For space exploration, it is even more vital

because of the complex geospatial nature of the space environment and networking statistics. To the end user, the visualization component becomes invaluable, since it provides a mechanism to quickly review a scenario run where it would take much longer to review all of the data. The raw data would only be needed where a detailed investigation of an event is required.

The PREE environment provides users with an advanced 3D visualization capability. It is a multi-platform, stand-alone application that can run in real-time with an on-going emulation or in playback mode. With the playback capability, remote users can see the emulation at any time without the need of being present in the testbed. The visualizer is written in C++ on top of OpenGL (graphics) and glut (windowing) libraries.

The basic functions of this visualizer are 1) displays all space entities in a 3D view and provides means for navigation, view saving and restoration, 2) shows orbits and trajectory of satellites, 3) shows possible connection between entities and data communications, 4) shows network statistics of an active link including the type of data, direction, protocol used, throughput, bandwidth, delay, and bit error rate and 4) shows history of access.

In playback mode, the visualizer can playback a previously run scenario and provide user with basic Fast-Forward/Rewind, Pause/Resume functions. Time steps can be set incrementally. In both playback and real-time modes, the data is buffered and a remote user can connect to the emulation at any time during the run and visualize the emulation data from the start of the scenario to the present.


11

Figure 6 - This screen shot shows the paths of both the CEV and the Moon, communication between the CEV

and Madrid (pink and yellow dashed lines), and access (but no current communication) between the CEV and a station on the moon.

Figure 7 - A shot showing communication between the CEV and a Goldstone (red and blue dashed lines),

access (but not data transfer) between the CEV and the Moon (brown line) and the path of the CEV.


12

Figure 8 - This wide shot shows a summary of all areas of access during the emulation. Orange areas show connectivity between the CEV and the Moon, cyan, yellow, and magenta are between the CEV and ground

stations (note the overlap where two stations are able to see the CEV at the same time).

VII. � Future Directions The current implementation of PREE provides basic functionality for evaluating space-based communication

protocols on mission that encompass both LEO and lunar orbiting elements. However, continued development on the current system will remove the degree of manual intervention currently required and improve the core capabilities. Specifically, future work for PREE will include the following:

• Automate STK Report Generation: Since it is an industry standard, STK will continue to function as the report generator for the scenario simulation before the emulation can run. While it is currently a manual process to develop the simulation scenario and run the reports, the goal is to automate the process to improve the efficiency of the emulation. Most importantly, this modification does not change the results from the current emulation system but will enhance the efficiency.

• Continue to Develop the CEV Definition: In PREE, the CEV contains a notional architecture where it is emulated by a satellite with an antenna. During the development of PREE, the CEV architecture was initially being developed and information was not available. As more information is published, the CEV definition will change accordingly.

• Fine Tune the Visualization Application: The current PREE visualizer has tremendous capability by allowing the user to zoom, accelerate the playback of data, modify the viewing angle and display the history and future of the communication structure. However, advanced techniques for viewing the data not only graphically but also effectively will be added to the visualizer.

• Enhance the Manageability of the Delay/BER Generator: The first generation of the delay/BER generator is controlled through scripts, accessed remotely with the secure shell program and preloaded settings. Future versions will be accessed with the Simple Object Access Protocol (SOAP) and will permit dynamic management throughout the scenario.

VIII. � Conclusion To accomplish and succeed at the Vision for Space Exploration, NASA must effectively examine technologies

on Earth before they can be deemed ready for flight. Obviously, the farther the space asset is from Earth the more difficult it becomes to perform updates or repairs given issues with long range communications. Therefore, NASA


13

needs to develop and appraise tools that will play a pivotal role in evaluating these technologies. This paper explained an environment that will permit the testing and evaluation of space-based protocols that specialize in communication over high latent, high bit error rate links. The environment provides an architecture that will allow components of real missions to be emulated so that communications between each of the assets can be as realistic as possible. If used effectively, tools like PREE will create successful long duration, long distance missions.

IX. � References 1. NASA, “The Vision for Space Exploration”, http://www.nasa.gov/missions/solarsystem/explore_main.html, Accessed 8 August 2005 2. SCPS Homepage, http://www.scps.org, Accessed 8 August 2005 3. MDP Homepage, http://mdp.pf.itd.nrl.navy.mil/, Access 8 August 2005 4. NASA Funds Space Communications Testbed Project for Comsat Laboratories, http://www.satnews.com/stories2005/991.htm, Accessed 8 August 2005 5. Bhasin, K., Linsky, T., Hayden, J., Tseng, S., “Surface Communication Network Architectures for Exploration Missions”, AIAA Space 2005 Conference, Long Beach, CA, 2005 6. Bhasin, K., Hayden, J., “Space Internet Architectures and Technologies for NASA Enterprises”, IEEE Aerospace Conference, Big Sky MT, 2001. 7. Java 2 Platform, Enterprise Edition, http://java.sun.com/j2ee/index.jsp, Accessed 8 August 2005 8. eXtensible Markup Language, http://www.w3.org/XML/, Access 8 August 2005 9. Deep Space Network Homepage, http://deepspace.jpl.nasa.gov/dsn/, Accessed 9 August 2005 10. Virtual Local Area Networks (VLANs), IEEE 802.11Q 11. Hemminger, Stephen. Netem. OSDL, http://developer.osdl.org/shemminger/netem/index.html. Accessed 2 June 2005. 12. Hubert, B., Graf, T., Maxwell G.,van Mook, R., van Oosterhout, M., Schroeder P., Spaans J., and Larroy, P.. Linux Advanced Routing & Traffic Control HOWTO, http://lartc.org/howto/, Accessed 2 June 2005. 13. Hemminger, Stephen. Iproute2 utilities. OSDL, http://developer.osdl.org/dev/iproute2/. Accessed 13 June 2005. 14. Hemminger, Stephen. Linux Ethernet Bridging. OSDL, ftp://bridge.sourceforge.net/. Accessed 9 June 2005 15. Netfilter/iptables project home page, http://www.netfilter.org/. Accessed 2 June 2005 16. MySQL Reference Manual. MySQL AB, http://dev.mysql.com/doc/mysql/en/index.html. Accessed 9 June 2005 17. Test TCP Homepage, http://ftp.arl.mil/~mike/ttcp.html, Accessed 8 August 2005 18. NLANR/DAST: iperf 1.7.0 – The TCP/UDP Bandwidth Measurement Tool, http:://dast.nlanr.net/Projects/ iperf, Accessed 8 August 2005

Documents

[American Institute of Aeronautics and Astronautics AIAA Modeling and Simulation Technologies Conference and Exhibit - San Francisco, California ()] AIAA Modeling and Simulation Technologies