[American Institute of Aeronautics and Astronautics AIAA Modeling and Simulation Technologies Conference and Exhibit - Keystone, Colorado ()] AIAA Modeling and Simulation Technologies

American Institute of Aeronautics and Astronautics

1

Modeling Space-Based Communications using a Dynamic Channel Emulator

Richard A. Slywczak*

NASA/Glenn Research Center (GRC), Cleveland, Ohio, 44135

Thaddeus J. Kollar† RS Information Systems, Inc./NASA/GRC, Cleveland, Ohio, 44135

NASA is aggressively pursuing the Vision for Space Exploration where the goal is to not only maintain a Low Earth Orbit (LEO) presence in the post-Shuttle era, but also to extend the US presence by returning man to the Moon and eventually to Mars. As NASA continues this endeavor, they will transition from a point-to-point communication system to a network-based architecture that ensures efficient and productive use of the space-based assets. One of the major benefits is “visibility” to astronauts and/or spacecrafts either in-orbit or on the Moon surface regardless of the data connectivity between the two entities. They will have the ability to route to the next visible node to ensure end-to-end connectivity even when a Line-of-Sight opportunity between the source and the destination does not exist.

While the first missions are still on the drawing board, NASA must model space networks through such techniques as simulation and emulation, and NASA/Glenn Research Center (GRC) has been at the forefront of developing these systems. This paper focuses on the Channel Emulator (CE), which is responsible for emulating space data links by providing delays, jitter, bit errors, packet duplication, and packet reordering. The CE also emulates antenna access patterns based on simulation data and can maintain multiple connections between emulated elements.

The goal of this paper is to introduce the concepts of simulation/emulation and how these techniques will aid NASA’s future direction. This overall architecture must be presented to understand how the CE is used within the framework. The concepts and the design parameters for the NASA/GRC-developed emulator will be presented and described in detail along with the design methodology. Finally, the configuration interfaces that demonstrate how the emulator can be locally or remotely configured are presented.

I. � Introduction uture space networks, a combination of private industry, government, and academia with international cooperation, will be adaptable and extensible to accommodate dynamic nodes of the mesh-networking

environment1. Based on current directions, these will be packet-based networks that will closely model the existing terrestrial environment to not only promote compatibility between space and ground networks, but to effectively share bandwidth and conserve resources. In addition, where applicable by the architecture, they can share an established, tested, and verified code base. As NASA continues the design and development of the next man-rated vehicle to replace the shuttle, the agency will debate whether to replace the tried and true point-to-point networks

* Computer Engineer, Satellite Networks and Architectures, 21000 Brookpark Road, AIAA Senior Member. † Systems Engineer, NASA: Office of Chief Information Officer, 21000 Brookpark Road

F

AIAA Modeling and Simulation Technologies Conference and Exhibit21 - 24 August 2006, Keystone, Colorado

AIAA 2006-6128

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


2

with more flexible packet-based networks. NASA has the benefit of using simulation and emulation to determine the most valuable architectures and the effective protocols that can be utilized.

Simulation and Emulation are computer techniques that allow components to be modeled before they are built in

actual systems. For the purposes of this paper, simulation and emulation can be defined as follows: Simulation: Simulation is performed on a single computer where simulated components are defined in terms of

models or statistical analysis rather than actual code. Simulation runs in faster than real-time (i.e., wall clock time). Emulation: Emulation is performed on multiple computers where emulated components are modeled using

actual code rather than models. Emulation runs in real-time (i.e., wall clock time). As shown in Figure 1, there is a relationship between Simulation, Emulation, and Testing. To define a solution

and develop requirements, simulation is used to prototype these models. They can be changed or modified quickly and statistics can be gathered about the systems being modeled. Once the simulation is completed, verified, and development is started, real models (or code) can run in a controlled environment using emulation. Emulation will usually run in wall clock time so that, in the case of communication systems, actual data transfers can be used between components of the system. Both simulation and emulation can model end-to-end systems, which, in architecture development, will be very valuable to NASA. Most importantly, there are also hybrids where components in the system might not be realistic enough – based on requirements - to have actual code; it will incorporate elements of both simulation and emulation.

The channel emulator is a realistic and flexible platform to provide space attributes to the data links and

functions as a Level 2 link-layer bridge. Currently, the emulator can insert delay, jitter, bit errors, packet duplication, and packet reordering on both one-way and bi-directional links and, in addition, it can limit the bandwidth on these data links. It can take input from commercial simulation programs that indicates the amount of delay (as a function of time) and the access patterns between space elements. In addition, the current version is distributed on a remastered Knoppix LiveCD2 to simplify the installation and setup procedures.

The Channel Emulator (CE) plays a key role in emulation systems development. As these environments mature, NASA, as the principal user, will be able to determine where the problems and pitfalls exist within the architectures.

Figure 1: Comparison between Simulation, Emulation, and Testing


3

These issues can, in turn, produce solutions to correct the models in the emulation system and produce better results. Once the results are satisfactory, the parameters and models will be valuable in building the engineering and flight systems so that these problems do not present themselves in orbit where they might be difficult or impossible to correct.

II. � Types of Space Data Links The CE represents space data links between entities whether they are spacecraft, manned vehicles, Earth ground

stations, rovers, etc. Currently, there are four (4) recognized categories of space data links, and unique parameters will differentiate between the data links categories. The uniqueness of the data links within a category can be represented by parameters such as the following: the type of antenna (size, throughput, operating characteristics), environment (solar activity, distance to the next hop), and spacecraft characteristics (power, architecture).

The four categories of data links are as follows3:

• Backbone Links: The backbone data links are the long-haul links, which are represented by the Earth-Moon or Earth-Mars links. The delay will be greater than 1.5 seconds - one-way delay to the Moon - and they will have variable bit errors depending on the environment. For example, a Mars lander (or supporting communications relay satellite) communicating to the Deep Space Network represents a backbone link.

• Access Links: The access data links are those, which are at the outer edges of the backbone networks and represent communications from a satellite to either a planetary surface or another spacecraft. For example, a satellite that transfers data to Earth via the TDRSS relay satellites use access links. Delay times are around 0.5 seconds.

• Inter-Spacecraft Links: Inter-spacecraft links are inter-communication links between satellites (or other vehicles) that cooperate as part of a constellation. These differ from other types of links given time requirements or communication characteristics that might be required.

• Proximity Links: Proximity links are close range links either between surface elements or between a spacecraft to a surface element. Proximity links closely resemble terrestrial links with short latencies (less than 0.5 second).

III. � Heritage In early 2005, a project requirement existed to find a delay and bit error simulator capable of emulating a link

between the Earth and Moon. The Ohio Network Emulator (ONE)4 could provide both functions, but was only distributed for Solaris and not actively maintained. NISTNet5 was another candidate, but at that time was only available for version 2.4 of the Linux kernel. Two more possibilities were Netem6 for Linux and Dummynet7 for FreeBSD.

Netem, included in recent Linux kernels, was vigorously pursued due to the availability and familiarity of Linux systems. Netem also had two basic features that other candidates lacked. One was that it operated at a lower network layer enabling the emulation of non-IP protocols. Another was that it was part of the Linux QoS subsystem and was not monolithic. This permitted the creation of sophisticated rule sets and functionality. However, at the time Netem did not have a method for corrupting packets. To address this lack of functionality, GRC developers patched the module source with an algorithm similar to that found in ONE, and patched the iproute28 “tc” command with the ability to configure the emulator (the current version of Netem and tc support corruption natively, so these patches are no longer needed).

The first application in which GRC researchers incorporated Netem was the Protocol Research Evaluation Environment (PREE)9. In this setting, the server hosting Netem was configured as a bridge10 between two routers. Each router acted as a gateway for a different LAN. Filters on the bridge system selectively applied delays and errors based on the source and destination IP addresses, as well as wall clock time. At the initialization of the scenario, the mission time was converted to wall clock time, and a different filter was generated for each time slice. The two scenarios that were demonstrated in the PREE were an Earth-based ground station communicating with a lunar satellite, and an Earth-based ground station communicating with the CEV as it moved from the Earth to the Moon. Large image files were transferred over these links using a combination of SSH and the SCPS protocol. Packet data was captured on the bridge system using the Linux kernel ulog facility, which stored its data in a MySQL database.


4

Lessons learned in PREE development were used in the Space Communications Testbed (SCT) and incorporated into the Link Emulator (LE) device11. The LE differed from the PREE bridge system in that it operated totally at the link layer level (rather than filtering IP addresses), allowed clients to plug-in directly rather than routing, and supported virtual interfaces that allowed the “partitioning” of physical interfaces on each client to emulate multiple antennas. Since the LE could potentially support thousands of virtual networks, it was much more complex than PREE. A central daemon ran on the LE that accepted SOAP/web services configuration commands from local and remote sources. A MySQL database stored the topology and parameters for each scenario so it could be programmed once and executed repeatedly. Each client system optionally ran a slave daemon through which the central daemon could command the creation of virtual interfaces, set transmission rates, and configure IP information. In the late stages of LE development, an interactive web page was also created to simplify the configuration process and status reporting.

Following SCT, a new multi-Center project required a device that could create delays, jitter, errors, and packet loss that was referred to as a Channel Emulator (CE). During SCT, the LE had been configured locally at GRC and shipped to a remote site for production, but the centers participating in the new project already had installed the hardware onsite. Since the CE required customization of the Linux kernel, system libraries, and tools, it proved difficult to configure remotely. To address this issue, a live CD based on Knoppix was remastered with all of the necessary functionality. The remote user could download, burn, and boot from the image without needing to install a complete system from scratch.

The CE provides additional basic functionality that was not incorporated into the LE, including jitter and packet duplication; it is also a simplification of the LE, which had grown beyond the boundaries of emulating the ether. Development of the CE takes a layered approach in which the lowest layer provides management of the data link layer, and is isolated from higher layers providing IP and testbed management.

IV. � Representative CE Architectures Since emulation testbed are custom developed, they provide a high degree of flexibility. Given the test

parameters and architectures chosen, the design and development of the CE had to account for a number of architectural configurations. Three of these options are presented to show the range of architectures that the CE can accommodate; they will vary from the ultra-simplistic – a couple of machines that have been configured for basic testing – to a complex testbed environment where nodes will join the scenario at arbitrary, but pre-determined intervals based on orbital projections. As shown in Figure 2, the basic CE will take a data stream into the device and output a manipulated stream that has been injected with delays, bit errors, etc. Figure 2 represents a basic testing environment to determine how an application, protocol, etc. will function under various space link conditions. This environment and CE is simple to configure, but does not utilize the CE efficiently.

The next example is shown in Figure 3 and represents the configuration of two diverse networks where the

communication path must encounter a delay intolerant path. The path can be a simple terrestrial environment where

Figure 2: Simplistic CE Testing Environment

Figure 3: Multi-Network CE Implementation


5

delays are on the order of milliseconds (i.e., one network on the East coast and one network on the West coast) or it could represent a network on the lunar surface communicating over a backbone link to an Earth-based network. While multiple applications can be tested simultaneously, the limitation is that each of the elements on the network will be subjected to the same delay and bit error rate, since a single connection to the CE will apply the same link conditions.

Figure 4 represents a more complex network comprised of a lunar segment and an Earth segment. The lunar segment has an orbiting satellite, a network for a habitat module, and two of rovers. The orbiting satellite and one of the rovers have multiple antennas, which is reflected in the configured Virtual LANs (VLANS) where each VLAN represents an antenna on a space asset. Each of these interfaces can be configured with varying parameters and antenna characteristics to uniquely identify the individual capabilities. The Earth side of the emulator is represented as an Earth ground station that receives the data on a predetermined interval. In addition, simulation data that represents access times and delays (as a function of time) are ingested into the emulator; the access times file permits the emulator to dynamically create or terminate links.

Based on the configuration of the emulator, a number of scenarios can be developed to study the

communications and access patterns for each of the elements. Using Figure 4, the satellite orbiting the Moon can be part of a relay network used to collect data destined for Earth. The scenario could be constructed, as follows: the rovers are collecting data, one on the near side of the lunar surface and the second on the far side of the lunar surface. The rovers will store the data in on-board storage until they have connectivity with the relay spacecraft and, during that access period, they can transmit their data. If they exceed the constraints for the on-board storage before they have connectivity, they have the option of transmitting the data to a space habitat that has extended storage capabilities. In this case, if the habitat has data to upload, it will transmit the data when it has connectivity. When the relay spacecraft has connectivity with Earth, it can downlink the data to the appropriate ground station. Using the flexibility of the emulator, it can be reconfigured, including the access and delay schedule, to push the Moon segment out to a Mars-based environment and, using the same functional components, the scenario could be evaluated based on Martian characteristics.

V. � Design Parameters

A. Delay For immediate projects, the emulator must provide a one-way delay of at least 1.7 seconds, which represents the

time it takes for communications to travel from the Earth to the Moon. This excludes many commercial telecommunications testing products that typically support a maximum delay of one second. A secondary requirement was that the emulator be able to support Mars-length communications, which has an approximate one-way trip time of over 22 minutes.

Figure 4: Multiple Lunar Elements Connected to the CE


6

The CE can support a delay of up to 34 minutes, restricted by the use of signed 32-bit integers in the Linux kernel. That is more than adequate for Mars communications, but not enough for Jupiter and beyond. With a 64-bit patch, the CE can support a delay of 585,000 years, but the maximum delay for a continuous data stream depends on the supported bandwidth and available memory in the emulator.

B. Jitter The emulator must be capable of varying the delay (i.e., jitter) to a configurable degree. The delay cannot be reduced below the minimum possible time it would take a radio wave to travel the simulated distance in space. Netem supports random variation and correlation approximation, but the value supplied can make the delay lower than required (e.g. a base delay of 1200ms with a requested variation of 10ms produces values between 1190ms and 1210ms). To compensate, 50% of the supplied variation value is added to the base delay as well as supplied to Netem. Using the requested values from the previous example would result in computed base delay of 1205ms with a variation of 5ms generating delays between 1200ms and 1210ms. A data stream with jitter can result in packet reordering and the system must be able to emulate this reordering. Conversely, when no jitter is desired, the emulator should only produce a constant delay. The standard deviation of the round trip time (RTT) for a set of test packets should be similar to that of an identical number of test packet transferred without an emulated delay. Table, 1, displays the results of three tests running “ping –c 100 –n –r” between two clients connected through a channel on the CE. In the first column, no additional delay is applied. Note that even without an artificial delay, one packet took 1.911ms to make the round trip. This minor variation can be caused by factors outside the scope of CE development such as client responsiveness, hardware, drivers, or running processes. In the second column there is a one-way delay of 1500ms but no jitter is applied, so the RTT is very close to 3000ms. In the third column, a 1500ms delay is applied with a jitter of 100ms, which can potentially produce round trip times between 3000 and 3200ms.

Measurements Settings

Delay 0ms Jitter 0ms



Measured % Loss 0 0 0 Minimum RTT (ms) 0.134 3000.850 3006.855 Average RTT (ms) 0.494 3001.237 3101.923

Maximum RTT (ms) 1.911 3002.789 3189.623 Standard Deviation (ms) 0.394 1.272 43.016 Table 1: Results of sending 100 ICMP echo requests using “ping –c 100 –n –r”

through the CE under extreme delay conditions.

C. Stream Mangling: Packet Corruption (Bit Errors), Loss, and Duplication The emulator must be able to flip a random bit in a random packet at a configurable statistical rate, and the packet must make it to the receiver in that condition to force it to compensate for the error. The emulator must also be able to drop packets at a configurable rate, forcing the receiver to detect the missing packet by relying on packets already received. The emulator must also be able to duplicate packets, forcing the receiver to recognize when it has already received a packet. The CE provides capabilities for each of these requirements. Table 2 demonstrates the effect of each type of mangling on random UDP traffic flowing at 400 Mbit/s. The data was collected using “iperf –u –b400M –c X”, where X is the IP address of a server on the other side of the CE running “iperf –u –s”. In such a test, enabling duplication in concert with either packet loss or corruption nearly replaces the total amount of data eliminated by one of those settings. Obviously the data is still unusable. An improved test would measure exactly how many packets were corrupted, lost, or duplicated.


7

BER 0%

Loss 0% Dup 0%

BER 10% Loss 0% Dup 0%







MBytes Sent

483 483 483 483 483 483 483 483

MBytes Received

483 435 435 532 391 479 479 431

Percent Received

100% 90% 90% 110% 81% 99% 99% 89%

Table 2: Results of using corruption, packet loss, and duplication on a 400 Mbit/s data stream for 10 seconds.

D. Maximum Throughput The highest rate link the channel emulator support at this point is 622 Mbit/s. Gigabit Ethernet cards can easily achieve this data rate and 10 GbE cards have been available for some time. Since potential throughput is primarily a hardware limitation, the bandwidth delay product dictates how much memory will be required to achieve the maximum throughput.

E. Mid-Scenario Attribute Changes In a dynamic communications scenario, objects are moving and getting closer/farther apart, gaining/losing visibility, encountering changing weather conditions, receiving commands that modify their behavior, etc. The emulator must be able to handle these changes either automatically or with user intervention, without disrupting data streams unintentionally. The CE can change conditions using rules based on mission time (linked to wall clock time), receiving remote programmatic commands, or accepting direct user interaction.

F. Remote Configurability The emulator must allow for remote configurations due to the distributed nature of emulation environments. This includes options for both simple remote shell session and a programmatic interface. The CE supports SSH and web access for direct user interaction and uses SOAP/WSDL for programmatic functions.

G. Data Collection For real-time and post-scenario analysis and visualization, packet headers and counters must be collected. The CE accomplishes this through the Linux ulog facility. Filters in the kernel capture packets and direct them to a user space daemon, which store them in a combination of a database, pcap file, or plain text log.

H. One-Way Communication It is not uncommon for a receiver in space to be unable, by design, to reply back to a sender. To provide this functionality (only when configured to do so), the CE can ignore packets that are directed to it from the receiver’s side. However, since the CE uses Ethernet, it is necessary for both the sender and receiver to have entries in each other’s ARP tables. This can be accomplished in two ways: by manually entering the addresses into the ARP table for each client, or by using a “cheat” mode, in which only ARP packets are allowed through in both directions.

I. Serial Connections During SCT, there was a requirement to be able to connect a satellite modem to the emulator using a RS-422 serial port rather than an Ethernet connection. To accommodate this, a daemon was written which read data from a serial port and sent through a Linux TAP device that could be bridged.

VI. Theory of Operation The CE operates somewhat like a standard network switch. Clients plug directly into network interfaces and

connections are created between them. However, unlike common hardware switches, connections across the CE must be created deliberately. The mechanism used to accomplish this is an 802.3 bridge. Bridging is similar to routing, except that it operates at layer 2 (data link) instead of layer 3 (network). This makes it possible to accommodate protocols other than IP.

To participate in a Linux bridge, each connected member network interface must run in promiscuous mode. This could potentially be problematic if the interfaces were on a busy network, but in this instance the network is isolated


8

between each client and the CE. Bridges are created and manipulated through CE interfaces that invoke the “brctl” command.

To apply emulated network attributes, the CE configures Netem queuing discipline (qdisc) as the egress queue of each interface on the bridge. Packet delay, corruption, loss, and duplication are all set at that location. Additional functionality, such as logging and one-way communication is configured with Ethernet bridge table (ebtables) filtering. Figure 5 shows a single channel with one client on each side of the CE. Arrows with solid lines represent unmodified traffic and arrows with broken lines represent traffic that has been perturbed.

Bridges can also incorporate 802.1q virtual (tag-based VLAN) interfaces if support is available on the client. Normally, VLANs are used to partition network switches into isolated LANs unable to communicate with each other. Their application in the CE is different, in that they are used to create virtual networks between the client and the CE. This allows “partitioning” a single pair of network interfaces into a multitude (default max. 4096), saving hardware costs and cabling. The virtual network does not extend across the bridge to a second client – it may be using a different virtual network on that side or just a physical Ethernet connection. This is because when the 802.1q interface itself (e.g. eth1.2) is joined to a bridge, the tag is stripped from its outgoing traffic and an interface on the other side does not require a matching tag to accept the data. If the underlying physical interface (e.g. eth1) had been joined to the bridge instead, the tag would be retained and a different topology would be required to accommodate it (i.e. only interfaces on the bridge with the same tag could communicate).

Figure 6 demonstrates two channels incorporating virtual interfaces (many other configurations are possible). Packets sent from Client A to Client B must flow through VLAN 1, identified by their 802.1q tags. When the packets get to Bridge #1, the tag is stripped, and NIC 2 is able to forward on them to Client B. Going in the opposite direction, packets going from Client B to Client A have no choice but to flow over Bridge #1. On the other size, the 802.1q tag is added and the proper virtual interface on Client A recognizes them.

Although Linux bridging allows many Ethernet interfaces to join the same bridge, the CE model only allows two per bridge (however, there may be as many bridges as there are pairs of physical or virtual interfaces). The primary reason for this is that they represent a point-to-point communications channel rather than a broadcast. A broadcast model requires a more complex design (e.g. different delays between endpoints) and there has not been a request for this utility so far. However, several clients from a single simulated location can be connected to one or both sides of the bridge (e.g. a group of computers on the CEV communicating with a lab in a terrestrial ground station): each side is connected to an ordinary hardware switch first and then that switch plugged into the CE. Alternatively, each group of computers can use its own router, and only the routers are connected to the CE.

Clie

nt A

Channel Emulator Client B

NIC

NIC

1

NIC

2

NIC

802.3 Bridge

Figure 5: A simple CE configuration.

Clie

nt A

Channel Emulator Client B

NIC

NIC

1

NIC

2

NIC

802.3 Bridge #1

802.3 Bridge #2

Client C

NIC

NIC

3

VLA

N 1

V

LAN

2

VLA

N 1

VLA

N 2

Figure 6: The CE with two channels configured, incorporating virtual interfaces.


9

VII. � Interfaces/Operational Concepts

A. Command Line Interface The CE is packaged with a script that permits the user to create an active environment with basic input. The script is called channel and can be executed from the command line; it is part of the LiveCD distribution. The command line will permit the user to input channel characteristics that will be applied to the data stream until the parameters have been updated through one of the CE interfaces. Commands can be issued dynamically while data is flowing through the CE to modify the parameters of the data link. The command line parameters are the following:

channel [options] [operation] [–c[channel number]] [-i[interfaces]] where: options are defined as the following: -A (Cheat and allow ARP packets through with one-way comm.) -d <delay_milliseconds> [-j jitter_milliseconds] -D Turn on debugging output. -b <ber_percentage> -g (Enable logging with the kernel ulog facility) -G (Disable logging) -l <loss_percentage> -p (Enable priority scheduling based on TOS bits) -P (Disable priority scheduling) -q <queue_length> (NOTE: system default queue length is 1000 packets, CE default is 20000) -t <target_interface> (Enable one-way comm. to target_interface) -T <target_interface> (Disable one-way comm. to target_interface) -u <duplication_percentage> -z (Wait for channel to begin forwarding packets before exiting) operations can be defined as the following: -a create a new channel that includes the input and output interfaces -m modify the parameters of an existing channel -x delete an existing channe -s get status for all channels

• channel number is the logical channel number assigned to this link that is represented by a series of

interfaces. The channel number is a simple number that is assigned by the user or by the system to a default value of zero (0).

• interfaces: is a set of interface over which the bridge will be created. Once this bridge has been created, it will be assigned to a logical channel number that will be used in subsequent operations.

1. Command Line Examples The following examples will show a number of configurations for the CE that comprises creating, modifying, and deleting a channel. 2. Creating a Channel Example 1: Creating a channel with default parameters (minimum number):

Interface 1: emu2 Interface 2: emu3

channel –a –i emu2, emu3

Example 2: Creating a channel with user specified parameters:


10

Interface 1: eth0 Interface 2: eth1 Channel Number: 2 Delay: 1.2 seconds BER: 0.001% Debugging: On

channel –d 1200 –b 0.001% -c 2 -D –a –i eth0, eth1

3. Modifying Channels Example 1: Modifying a channel to increase the delay and BER:

Channel Number: 2 Delay: 1.7 seconds BER: 1e-5 Debugging: On channel –d 1700 –b 0.001% -c 2 -D –m

Example 2: Modifying a channel to increase the delay, add jitter, and add packet loss:

Channel Number: 0 (default channel) Delay: 1.2 seconds Jitter: 0.02 seconds BER: 1e-7% Packet Loss: 30% Debugging: On channel –d 1200 –j 20 –b 0.00001% -l 30% -D –m

4. Deleting Channels Example 1: Deleting a channel with the default channel number:

Channel Number: 0 (default) channel –x

Example 2: Deleting a channel with user specified channel number:

Channel Number: 2 Debugging: On channel -c 2 -D –x

B. Web Interface When the Channel Emulator has a management network interface configured with an IP address, channels can be remotely created, modified, monitored, and deleted through an interactive web page. The page displays the layout of each existing channel, including its emulated parameters, bridged interfaces, and counters. New channels can be created by submitting a form at the bottom of the page, and existing channels can be deleted by clicking the Delete button next to each. Emulated network parameters are presented in form fields and can be edited and applied by clicking the Modify button. Counters are updated by refreshing the page.


11

VIII. Future Directions SOAP/WSDL Interface: The previous generation Link Emulator, as developed for SCT, used SOAP as its only interface either directly or indirectly through command line and web page wrappers. Every function provided by the central daemon had a SOAP counterpart. The revised CE, with a design that relies on system status rather than database records, will export fewer functions but still provide the necessary functionality. The user will have direct control of the system rather than being required to set up a model first.

IX. � 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 needs to develop and appraise tools that will play a pivotal role in evaluating these technologies. This paper discussed how simulation and emulation plays a pivotal role in developing these architectures. The cornerstone of these systems will be the GRC-developed Channel Emulator (CE), which allows realistic emulation of data links by inserting characteristics, such as delay, bit errors, jitter, packet reordering, and packet duplication. Utilizing the CE in systems development, it can accurately emulate space data links on which NASA will be relying in future architectures.

X. � References 1. Bhasin, K., Hackenberg, T., Slywczak, R., Bose, P., Bergamo, M., Hayden., J, “Lunar Relay Satellite Network for Space Exploration: Architecture, Technologies, and Challenges”, International Communications Satellite Systems Conference, San Diego, CA, 2006. 2. Knoppix Linux Live CD, http://www.knoppix.org, Accessed 7 August 2006

Figure 7: Web-based Interface


12

3. Bhasin, K. and Hayden, J., “Space Internet Architectures and Technologies for NASA Enterprises”, IEEE Aerospace Conference, Big Sky, MT, 2001 4. Caldwell, Adam, Shawn Ostermann, Mark Allman, and Jim McKim. ONE User Manual, http://irg.cs.ohiou.edu/one/manual.html, Accessed 27 Jul 2006 5. Carson, Mark, NISTNet Homepage, http://www-x.antd.nist.gov/nistnet, National Institute of Standards and Technology, Accessed 27 July 2006 6. Hemminger, Stephen and others. Netem – LinuxNet. Open Source Development Lab. <http://linux-net.osdl.org/index.php/Netem>. Accessed 27 Jul 2006 7. Rizzo, Luigi. IP_DUMMYNET. <http://info.iet.unipi.it/~luigi/ip_dummynet/>. Accessed 27 Jul 2006. 8. Hemminger, Stephen. Iproute2 utilities. OSDL, http://developer.osdl.org/dev/iproute2/. Accessed 13 June 2005. 9. Slywczak, R., Luu, T., Holtz, A., Bhasin, K., Kollar, T., “Evaluating Space-based Protocols through the Protocol Research Evluation Environment”, AIAA Modeling, Simulation, and Technologies Conference, San Francisco, CA, 2005 10. Hemminger, Stephen and others. Bridge - LinuxNet. Open Source Development Lab. <http://linux-net.osdl.org/index.php/Bridge>. Accessed 27 Jul 2006. 11. Rieser, J., Berry, K., Clare, L., Slywczak, R., “The NASA Space Communications Testbed (SCT)”, IEEE Aerospace Conference, Big Sky, MT, 2006

Documents

[American Institute of Aeronautics and Astronautics AIAA Modeling and Simulation Technologies Conference and Exhibit - Keystone, Colorado ()] AIAA Modeling and Simulation Technologies