Last updated: January 16, 2009
This section is only applicable to the lab application.
This topic details the following:
Testing the throughput of an IP-based packet switched data connection typically requires both a data source and a data sink. The requirements on the data source are usually straightforward and can often be summarized as "send data as fast as the air interface will allow". Most test environments use a generic PC or Linux server connected to the test set's LAN. This PC is colloquially referred to as the "server", because it is often running an FTP server. Sometimes the data sink will be the phone itself or another PC, often referred to as the "client" PC connected to the DUT and using the DUT as a modem.
The internal Data Generator functionality in the 8960 lab applications can be used to simplify your test environment by removing the need for an external "server" PC for simple throughput testing. As well as shortening test environment setup time this simplification typically results in more repeatable results as the configuration of Windows PCs, and their data throughput capabilities, can vary widely from one PC to another.
The two standard use-cases for throughput testing involve sending either UDP or TCP data as fast as the air interface will allow.
UDP does not impose any throughput restrictions of its own. UDP is a protocol which does not require any acknowledgements of the received data from the recipient of the transmission for retransmission of missed / bad blocks. It is therefore a good mechanism for testing the data throughput capable to almost theoretical limits but may not be completely representative of the end user experience.
TCP is used by common protocols like HTTP and FTP so is a good choice for measuring throughput that an actual user will experience, however end-to-end throughput can be restricted by TCP mechanisms in the server PC (such as receive window size and congestion control) that are not related to over-the-air capacity.
The TCP data generator is an implementation of the RFC 864 CHARGEN service that runs on port 19 on the test set's protocol processor. Please note that a Special High Data Rate hardware test set is required (or a test set with the equivalent hardware upgrades). To use this feature, you simply establish a TCP connection with the test set on port 19 and the generator will start streaming data over the link as fast as possible for as long as the connection exists. The format of the transmitted data is the example described on page 3 of RFC 864 (http://www.ietf.org/rfc/rfc0864.txt). Any user data received over the TCP connection is discarded by the test set.
There are no user-settable configuration parameters associated with this feature.
To start the character generation function while on a PS data connection, use a command line telnet program on the client PC to connect to port 19 of the test set's protocol IP address.:
C:\> telnet <lan 2 address> 19
When successful, a large amount of scrolling text can be seen on the screen. The telnet program is making a TCP connection to port 19 on the test set's protocol processor. The chargen service is listening on port 19 and upon connection establishment, the service streams data as fast as it can over that connection. To stop, type "Ctrl+]" to get the command prompt back and then type "quit". Note that the data rate is usually limited by how fast the telnet program can draw the data to the screen. Alternatively, you can create your own socket application to establish the chargen connection. This would be likely to increase the throughput since there would be no drawing of data to the display. A socket application could be created quickly in Perl or Python.
To demonstrate the Discard function, where the source of the TCP data is on the client PC, use a command line telnet program on the client PC to connect to port 9 of the test set's protocol IP address:
This makes a TCP connection to the discard server running on port 9. Discard is the opposite of chargen in that the test set simply sits there and discards anything that arrives on the connection. You can send characters simply by typing in the telnet window (although it is unlikely that you will see characters on the screen because they are not being echoed by the Discard server).
All traffic transmitted or received by the TCP data generator will be recorded as part of the IP and OTA lines on the Data Throughput Monitor and all IP traffic will also be logged to WPA under the IP logging point.
Although the intention of the TCP generator is to keep the air interface link fully loaded with data the LAN port and internal ping functionality that is normally used to send data to the DUT are not disabled while either generator is active. This means that you can activate a data generator and still send packets to the DUT through either the external LAN port or internal ping functionality. However those packets have to compete with the active data generator for buffer space in the transmit queue so will likely experience high packet loss rates and possibly higher than normal latencies.
In a two-box environment any traffic going to/from the data generators will follow the phone as it moves between boxes. This means that if you establish a connection to the TCP traffic generator on a particular box and then hand the phone over to the other box the TCP traffic generator will remain active.