IEEE Instrumentation and Measurement Technology Conference Budapest, Hungary, May 21-23, 2001.
Design of a Space Channel Simulator Using Virtual Instrumentation Software Stephen Horan New Mexico State University Las Cruces, New Mexico 88003-8001, USA Phone: +1 505 646-5870, Fax: +1 505 646-6417 Email:
[email protected], URL: http://telemetry.nmsu.edu/~shoran/ Abstract – The ability to simulate satellite channels gives protocol designers the ability to test design options prior to their use in space communications. Here we describe a software-based space channel simulator with variable channel error-rate, channel delay, and user bit error rate. This simulator is used to model the communications channel for testing various Internet-type protocol options for space communications.
1. 2. 3. 4.
Keywords – virtual instrumentation, simulation design, space communications channels.
I.
INTRODUCTION
The use of Internet-type protocols for space communications is no longer considered a “new” topic of investigation. Research on the subject has been conducted at government, contractor, and university facilities for several years now. At New Mexico State University (NMSU), we have been concentrating on the performance of two protocols suites: the file transfer protocol (ftp), the application-layer protocol that is running over the Transmission Control Protocol/Internet Protocol (TCP/IP) stack and the file protocol (fp) that is an application-layer protocol within the Space Communications Protocol Standard (SCPS) [1] developed under the Consultative Committee for Space Data Systems (CCSDS) standards process. In the NMSU studies, we have been concentrating on the performance of the protocols in a small satellite environment. By that, we mean that the anticipated user would be interested in the following characteristics and capabilities: 1. 2. 3. 4. 5.
Forward and return data rates from 2400 bps through 115200 bps, selectable in each direction, Bit Error Rate (BER) selection from 0 through 0.0001, selectable in each direction, Data file sizes from 1 Kbyte through 1 Mbyte, Short transfer opportunities, e.g., typical 5-minute ground station passes, User-selectable delay times for the forward and return link up to 5 seconds.
We have developed a Space-to-Ground Link Simulator (SGLS) to provide the simulation capabilities to test both protocol suites ([2], [3], and [4]). The decision to develop a channel simulator was based upon This effort was funded under grants NAG5-7520 and NAG5-9323 from the National Aeronautics and Space Administration.
0-7803-6646-8/01/$10.00 ©2001 IEEE
The high cost of satellite time for conducting experiments The difficulty in scheduling blocks of time to run tests or conduct background investigations The lack of variability in link delay The lack of flexibility in setting link parameters, e.g., bit error rate or data link transmission rate.
Given these constraints, it was decided to develop an inlaboratory simulator that would allow for maximum flexibility in modeling the space channel. II.
SIMULATOR ENVIRONMENT
The SGLS channel simulator is used to perform the error generation and link delay used to test the protocol suite performance. In this section, we describe the simulator and the standard tools for gathering data to measure the performance. The Space-to-Ground Link Simulator (SGLS) has been developed to model space channel characteristics experienced in transmitting data. Basically, the SGLS configuration allows the user to configure the simulated channel to 1. 2. 3.
4.
Allow for simultaneous bi-directional data flow (forward and return channels), Allow user-selectable error rates and statistical descriptions of the channel, Allow different data rates on the forward and return links as would be found in satellite links, e.g. 2400 baud forward, 115200 baud return, and Provide for a simulated delay up to 5 seconds on each link.
The SGLS utilizes the LabVIEW [5] programming language to control data throughput through the simulator, mix the baseband data stream with the user-selected error vector, and provide for the user-selectable link delay value. The hardware configuration is illustrated in Figure 1. The LabVIEW software is run as an application on each of the SGLS computers. Typically, the LabVIEW modules are the only applications software running on the computers. This configuration was developed to model point-to-point satellite links in
LabView ratechange computer
LabView ratechange computer
R2
Linux-based PC
3. R1
R2 R1 - forward link baud rate R2 - return link baud rate
Virtual circuit for file transport over a PPP link
R1
Linux-based PC
Figure 1 - SGLS hardware configuration its current configuration. The bandwidth-delay product for the system under a 115200 bps symmetric link with no imposed channel delay is 671 bytes. As a comparison, a T-1 line crossing the United States has an estimated bandwidth delay product of 11,580 bytes [6]. Therefore, this simulator corresponds to a relatively low capacity system as typically found in small satellite systems. The three PCs in the SGLS are Dell 600-MHz computers with 128 Mbytes of memory running Windows 98 second edition. The first Linux-based PC is a Dell 266 MHz computer. This is our logical ground station computer. The second Linux-based PC is a Gateway 166 MHz. This is out logical satellite computer. Both Linux computers are running Red Hat Linux version 6.1. The SGLS is connected to the Linux computers using serial cables connected to the COM serial ports on each computer. The data connections are configured without hardware or software handshaking to allow for a simulation that would be similar to interfacing with a satellite radio system. In all cases, the links between the SGLS and the Linux computer were set to 115200 bps (R2 in Figure 1). The simulations run with symmetric links had the forward link (R1 in Figure 1) also set to 115200 bps. The simulations run with asymmetric links had the forward link set to 2400 bps. SIMULATOR DESIGN
By using a PC-based configuration and not a generic networking simulator package, we believe that using the LabVIEW Virtual Instrument (VI) method of development allows for several advantages over commercial hardware and software simulation methodologies, including: 1.
Providing portability so that can be placed in a laptop PC with appropriate interface cables; The ability to be configured to work with multiple networking and communications technologies (RS232, RS-422, Ethernet, etc.).
R2
R2
Channel error-rate LabVIEW host computer
III.
2.
Allowing tests on actual live data streams with operating system interactions at the source and sink nodes included and not just simulations of those data streams;
The simulations are conducted at baseband and not include any effects of modulation. This is done for two reasons: it allows for simulating network channels other than space channels, and we are really interested in testing the performance of the networking protocols while the modulation provides an added layer of complexity to the simulation environment without providing more accurate results when looking at protocol performance. If there are modulation losses in the system, the bit error rate and statistical descriptions can be adjusted to match the expected performance without modulating the data explicitly. The user interfaces for the simulator provide the following features: 1.
2.
3.
4.
5.
Provide the user with a means to select the communications ports to configure the forward and return data links and the communications port interfacing with the external computer system that will either source or sink the data. Provide the user with the means to select the error vector from the disk library to control the forward and return link statistical error characteristics. Provide the user with a means to select the baud rate for the forward and return links. Normally, standard RS-232 rates will be selected. Most PC communications ports support baud rates from 1200 bps through 115200 bps. Provide the user with real-time indications of data flow. This is done by showing the input queue size on each communications port upon each program iteration. Provide the user with a run-time means to disable the software processing (an on/off switch).
The user interface for the error generation module is given in Figure 2 while the user interface for the two rate-split and delay components is illustrated in Figure 3. The input for the user-selectable parameters is done using the LabVIEW Text Tool on the panel. The specification of the external data computer (External Port Number), and SGLS interface ports (Channel Forward Port Number and Channel Return Port Number) can be selected by incrementing the selection slide on the user interface using the Operating Tool. The error generation VI gives the user a Windows file manager interface to select the forward and return error files. The software enable/disable is done using the button switch on the VI panel. This can be clicked by using the mouse to halt processing. The LabVIEW execution is initiated by clicking the
occur. The 1s are distributed over the vector according to the statistics specified by the user. The program was designed to develop vectors for AWGN, radio frequency interference, and mixed noise-and-interference environments. Other statistical distributions can be generated by modifying the program to generate the desired statistical model. For all of the testing shown here, the AWGN statistical model was used.
Figure 2 - User interface for the error generation module
The error generation methodology used in the VI is based upon the known relationship from digital logic that if one takes a digital data stream of logic 0s and 1s and then performs an Exclusive-Or (XOr) operation on the data stream then every place where the data stream is Ex-Ored with a logic 0, the data is unchanged while every place where the data stream is XOred with a logic 1, the data symbol is complemented [9]. This can be used to model the channel error generation process: the channel can be modeled as an XOr gate that randomly operates on the input data stream. This is illustrated in Figure 4 where a single bit error is generated in the output data stream. The rate splitting and delay generation methodology used in the VIs is based the following data flow: 1.
2.
3.
Figure 3 - User interface for the 1x2 module. The 2x1 module is similar. left-pointing arrow (Ö) on the command bar using the mouse. To properly model a channel, the user needs a proper statistical description of the channel error generation mechanism. A typical channel error statistical description is Additive White Gaussian Noise (AWGN) where the errors are described by a Gaussian random process parameterized by the link Energyper-bit-to-Noise-density ratio (Eb/No) [7]. Here, we use a computer program [8] to develop a library of error vectors for use in the simulator so that the error process does not need to be computed in real-time and thereby slowing down the simulation process. In the program, the user specifies an Eb/No value, the number of bit errors to be generated, and the type of statistics to be used and the program would produce a vector meeting this specification. The error vector will be all 0s except for 1s at the locations where the bit errors are to
Data will enter and leave the overall simulator (rate and delay functions as well as the error generation module) at the highest data rate to be used on either the forward or return data links. Two additional PCs will be used in conjunction with the SGLS error-generation PC to perform the rate splitting and delay functions independently on the forward and return data links. The additional PCs will drop the low-rate channel baud rate prior to entering the SGLS channel error simulator and then raise it back to the original level upon coming out of the SGLS and prior to passing it out of the overall simulator. These same PCs will provide the desired link delay on the forward and return data links using user-selectable delay values.
Input Data Stream:
à00011001à
Error Vector:
à00000100à
Output Data Stream: à 0 0 0 1 1 1 0 1 à bit error location > Figure 4 - Error generation process
Forw ard Delay Element External
Rx
1x2
Forw ard
Forw ard Out
In
In
Out
Error XOr
Out
In
In
Out Return
Return
2x1
External
Tx
Return Delay Element
Figure 5 - Relationship between data source and data sink locations and the simulator modules
This overall process is illustrated in Figure 5 showing the relationship between the data lines, the splitting functions, the delay functions, and the error Xor error generation operation. Here, Tx and Rx are the source and sink nodes for the data. External is the data link between the Tx and Rx nodes, and the overall space channel simulator. Forward is the path from Txto Rx while Return is the path between Rx and Tx inside the channel simulator. The module 1x2 provides the interface between the Forward and Return paths inside the simulator, and the External link to the Rx node. The module also provides the Forward link propagation delay element. The 2x1 module provides the complementary interface between the overall simulator and the Tx node and the Return link propagation delay element. The link speeds and delays inside the 1x2 and 2x1 modules are independently selectable by the user. The error generation process for the forward and return links is in the block labeled Error XOr. The LabVIEW VIs for the rate splitting and delay do not perform any error
processing of the data streams. The actual hardware configuration for the computers and software modules was illustrated in Figure 1. There, R1 and R2 are the forward and return data rates, the channel error PC hosts the SGLS VI for producing the channel errors, the rate change PCs host the VIs for splitting and recombining the separate data transmission rates and providing the link propagation delays. The channel error PC requires a total of four serial communications ports and each of the rate change computers requires a total of three serial communications ports. IV.
This simulator has been used to test the networking protocols for a space environment to give estimates of their performance in small satellite applications. A typical results is shown in Figure 6 for the TCP/IP ftp protocol with various file sizes and link configurations.
(a) header compression ON
b) header compression OFF 1000
1000 100
Time (seconds)
Time (seconds)
RESULTS
10 1 0.1
100
10
1
0.1
0.01
0.01
0.001 1KB
10KB
100KB
File Size
1000KB
1KB
10KB
100KB
1000KB
File Size
ms 120 ms 3 ms 1280 ms of header 120compression ms 3 ms Figure 6 - Effect on throughput for the ftp 1280 protocol as a function of link delay for symmetric links.
To date, we have conducted experiments to test 1. 2. 3. 4.
Effects of unbalanced link transmission rates Effects of header compression and time stamp options Effects of round-trip link delay Effects of congestion control algorithms.
modifications do not take long to realize and test in the laboratory. Capabilities currently under development include allowing for time-variable channel BER analysis and timevariable link delay analysis. These will allow for capabilities that do not exist in “real” satellite channels for testing performance and conducting experiments. REFERENCES
Other types of experiments can be conducted as well to investigate protocol performance. The simulator has been validated to the extent of verification of correct overall data flow. We are presently negotiating with a facility to replicate the entire suite of simulator settings over an actual satellite link. V.
ADVANTAGES
The advantage to a simulator such as this is that we can change configurations quickly and easily to allow for new experiments. The experiment configuration does not require negotiation with a satellite service provider. We can also enhance or modify the simulator to allow for new capabilities. Because of the modular nature of the software, most
[1] Consultative Committee for Space Data Systems, “Space Communications Protocol Specification (SCPS) - File Protocol (SCPS-FP),” CCSDS 717.0-R-3, September 1997. [2] S. Horan and R. Wang, “Design of a Channel Error Simulator Using Virtual Instrument Techniques for the Initial Testing of TCP/IP and SCPS Protocols,” NMSU-ECE-99-002, 1 April 1999. [3] S. Horan and R. Wang, "Enhancement of The NMSU Channel Error Simulator to Provide Unbalanced Forward And Return Transmission Rates," NMSU-ECE-99-003, April 1999. [4] S. Horan and R. Wang, "Enhancement of the NMSU Channel Error Simulator to Provide User-Selectable Link Delays," NMSU-ECE-00001, May 2000. [5] National Instruments™, LabVIEW™, Austin, Texas, January 1998. [6] W. Stevens, TCP/IP Illustrated Vol.1, Addison-Wesley: Reading, MA, 1994, Chapter 20. [7] B. Sklar, Digital Communications Fundamentals and Applications, Prentice-Hall: Englewood Cliffs, NJ, 1988, p. 156. [8] J.C. Moser and W.P. Osborne, “Error Pattern Generation for Coded BPSK,” NMSU-ECE-95-007, August 1995. [9] Sklar, ibid., p. 276.
