Performance of TCP/IP and its Application Protocols over Narrowband Bearers with high Latency

Thomas Wierlemann and Thorsten Kassing

DeTeMobil, Deutsche Telekom MobilNet GmbH, P.O. Box 8865, D-480 47 Münster, Germany 



Future cellular networks like UMTS have to be designed to deliver pictures, graphics, video communications and other wide-band information as well as voice and data. These UMTS services must be easy to use, and be customizable in order to address individual users needs and preferences (personalization). High data rates (up to 2 Mbit/s) together with the inherent Internet Protocol (IP) suite support, will be a powerful combination to deliver interactive multimedia services as well as other new wideband applications such as video telephony and video conferencing. For this purpose UMTS integrates packet and circuit data transmission. UMTS is also being designed to offer data rate on demand, where the network reacts flexibly to the user's demand, his or her profile and the current status of the network. Together, the combination of packet data and data rate on demand will remove technical barriers for the user and make operation of the system much cheaper, making efficient use of available network resources.

To guarantee this efficiency for cellular networks a two step measurement campaign was defined.

Step 1: Performance of TCP/IP traffic in GSM

Limited bandwidth, high latencies, and high bit-error rates and temporary disconnection characterize communication over wireless links. The Transport protocol TCP has been tuned for traditional networks made up of wired links and stationary hosts. TCP performs very well on such networks by adapting to end-to-end delays and packet losses caused by congestion. TCP provides reliability by maintaining a running average of estimated round trip delays and mean deviation, and by retransmitting any packet whose acknowledgement is not recieved within a certain time frame. The objective of this campaign was to show whether this behavior is appropriate for communication over wireless links. Therefore an isolated test site was set-up (see Figure 1) to minimize influence from competing internet traffic taking into account the needs of detailed measurements within lower protocol layers.

To consider all real world situations three measurement conditions have been chosen: good to excellent coverage, poor to bad coverage, heavily fluctuating coverage in a driving car. The asynchronous, non-transparent GSM data bearer (9600 bps) employing the RLP protocol for error protection was chosen for the measurements. Between the GSM IWF and the analogue modem at the gateway the V.42 transport protocol was used. Compression e.g. V.42 bis was not used. Between the analogue modem at the gateway and the mobile client the PPP protocol was running.

TCP/IP performance was measured as maximum throughput for file transfers using the FTP protocol. Following scenarios have been chosen:

For the FTP performance measurements three different file types were used: ABC, text and binary of varying length (100, 300, 500, 700, 900 and 1800 kbyte). These files have been transmitted ten times and then the aritmethic mean value was calculated. For this measurements the MTU was set to 808, this value was determined as optimum for this network configuration.

Figure 1 TCP/IP performance over GSM

Step 1 Results

FTP performance for text files achieved a maximum throughput of 0,89 kbyte/s, ABC-files a maximum of 0,91 kbyte/s (see Figure 2). The measured maximum throughput for binary files was with 0,81 kbyte/s slightly slower.

Remarkable is that the performance (maximum throughput) under poor and heavily fluctuating radio channels did not degrade (see Figure 3). On average a maximum throughput of 0,81 kbyte/s for binary files was measured. This only slightly below the value (0.82 kbyte/s) which was measured for the mobile client being connected via a fixed line (PSTN) with the same bandwidth as GSM. The measured throughput for text files was on average 0.88 kbyte/s while for ABC files the measured mean value was 0.91 kbyte/s.

Figure 2 measured throughput for ABC -, text - and binary files

For the calculation of the theoretical maximum throughput for FTP over GSM (bandwidth 1200 byte/s) the header size of TCP/IP (10 byte with Van Jacobsen header compression) and V.42 (6 byte for every 134 byte data packet) has to be considered. For the MTU of 808 byte the measured throughput was between 75% and 90% of the maximum possible throughput.

Figure 3 measured throughput for binary files under v= arious radio conditions

These measurements have shown that under real world conditions TCP/IP performs satisfactory over low bandwidth links with high latency in terms of throughput. Also the GSM RLP protocol could demonstrate robust performance as almost 97% of the file transfers were completed successfully. In addition the throughput was almost constant for all radio conditions down to a threshold where the radio link breaks down. This shows that both TCP error recovery mechanisms and GSM RLP are well dimensioned and perform sufficiently together.

Step 2: Performance of higher layer TCP/IP application protocol HTTP

The behavior of higher layer protocols like HTTP and the interaction of their mechanisms with the behavior of lower layer protocols like TCP/IP have a significant impact on the performance which is visible to the end users. Therefore the 2nd step of this campaign has been executed with the objective to investigate what happens when WWW traffic is carried over mobile networks to reach optimum support of Internet based M3 (mobile multimedia) applications.

Again above all weight was placed on the selection of the measurement conditions to consider all real world situations. The same conditions as in step 1 have been chosen: good to excellent coverage, poor to bad coverage, heavy fluctuating coverage in a driving car. The performance of the WWW traffic was measured as transaction performance (number of completed requests and responses per unit of time) for the HTTP protocol. The network, which was used for step 1 was extended to fit the requirements of this HTTP performance tests (see Figure 4). Linux was used as the main operating system for the measurements. Also comparison measurements have been performed on other operating systems to investigate whether the results are independent of the operating system in use and if possible to detect any faulty behavior of the protocol stack implementation for a special operating system.

An Ethernet network was set-up behind the gateway consisting of three computers with different operating systems (Linux, Windows 3.11, Window NT 4.0). The mobile client laptop could connect to the test network via a mobile phone with a PC-card. Again the asynchronous, non-transparent GSM data bearer (9600 bps) employing the RLP protocol for error protection was chosen for the measurements. To be able to control the measurement from the mobile client, e.g. while being in a car, scripts for automatic connection set-up in up- and downlink direction were used. The transaction performance was measured with the Netperf test programs "TCP request/response (RR)" and "TCP connect/request/response (CRR)". For the exact control of the datastream TCPdump was installed as a network monitor.

Averaging the results from 30 RR or CRR did the transaction performance evaluation. One RR or CRR action takes 60 s for 30 actions the measurement took 60 minutes, which is long enough to satisfy statistical requirements. The sizes of the messages were chosen as 200 byte for request and 2000 byte response. These are typical values taken from long-term investigations with real WWW-servers.

Summary of transaction performance measurements which have been performed:

Figure 4 HTTP performance over GSM

Step 2 Results

GSM with its maximum data rate of 9600 bps is rather slow compared to fixed data networks like Ethernet. On top of that the round trip delay of GSM is nearly twice that of PSTN. For this experimental network a RTT of 920 ms measured. The RTT seems to be the main factor influencing the transaction performance (no. of completed requests and responses per minute of time) which is responsible for the efficient transfer of HTML pages and its embedded objects.

Figure 5 Transaction performance RR test

The proposed RR (see Figure 5) method could not improve the transaction performance for GSM compared to the CRR method (see Figure 6). For GSM 0.14 transactions per second were measured. This compares to several dozen transactions per second on fixed data networks, in theory. Noticeably those even bad radio link conditions, which are typical in driving cars, did not influence the transaction performance.

Figure 6 Transaction Performance CRR test

Analysis and Outlook

This test campaign has shown that TCP/IP and its transport- and control mechanisms are very well suited for cellular radio links with low bandwidth and high latency under typical real world radio conditions. This was measured on GSM circuit switched data bearers, further investigation should be done for packet switched bearers which will soon be implemented in GSM by GPRS and also for broadband bearers which will be provided by 3rd generation mobile networks like UMTS.

On the application layer the performance could not satisfy and needs urgently improvement. As this performance is most visible to end users and therefore most important for the market success of M3 (mobile multimedia) services on the Internet.

Following requirements for cellular operators and its mobile Internet users can be stated:


This work has been partially funded by the Commission of the European Communities in the ACTS program under the AC034 OnTheMove Project. The authors would like to acknowledge the contributions of their colleagues from Bonnier Information Services AB, BT, Burda Com GmbH Media Solutions, Deutsche Telekom MobilNet GmbH, Ericcson Eurolab Deutschland GmbH, Ericsson Radio Systems AB, Tecsi, IBM, Royal Institute for Technology, RWTH Aachen, Siemens AG, Swedish Institute of Computer Science, Sony Deutschland GmbH, IONA Ltd., National University of Singapore, although the views expressed are those of the authors and do not necessarily represent those of the project as a whole.