TCP performance issues in LTE networks
Hyun-Seo Park Jae-Yong Lee, Byung-Chul Kim
Internet Future Technology Research Department
ETRI
Daejeon, KOREA
hspark@etri.re.kr
Abstract We describe issues on the TCP performance in LTE
networks. TCP throughput is determined by various factors such
as TCP window size, loss probability and RTT. We present
measurement results of TCP throughput in a real LTE testbed
with various factors and TCP auto-tuning enabled. As expected,
the test results show that the AM bearer outperforms the UM
bearer due to less loss probability in the former. However, test
results show that delay spikes incurred by the RLC ARQ
increase TCP RTT and degrade TCP performance. We propose
some enhancements for improving TCP throughput in LTE
networks.
Keywords LTE, TCP, ARQ, HARQ, RLC, Reordering, Auto-
Tuning.
I. INTRODUCTION
rd
The 3 Generation Partnership Project (3GPP) specified the
Long Term Evolution (LTE) radio interface to meet the
increasing performance requirements of mobile broadband.
LTE provides a peak data rate of up to 300Mbps in the
downlink and 75Mbps in the uplink with 20MHz bandwidth.
Currently, the 3GPP is specifying the LTE-Advanced radio
interface to meet the IMT-Advanced requirements. LTE-
Advanced provides a peak data rate of up to 1Gbps in the
downlink with peak spectral efficiency 30bps/Hz and 500Mbps
in the uplink with peak spectral efficiency 15bps/Hz using up
to 100MHz bandwidth [1].
LTE is now on the market. In July 2011, an update from the
Global Mobile Suppliers Association (GSA) confirms that 218
operators in 80 countries now make investments in LTE
networks. The organization's latest update states that 166 firm
commercial LTE network deployments are in progress or
planned in 62 countries. This includes 24 networks which have
commercially launched, while a further 52 operators in 19
additional countries are engaged in LTE technology trials, tests
or studies.
In January 2011, ETRI demonstrated the worlds first LTE-
Advanced system. The system provides a peak data rate of up
to 600Mbps and a peak effective data rate, i.e., application
layer throughput, of up to 440Mbps in the downlink and
220Mbps in the uplink with 40MHz bandwidth [2].
In December 2010, the 3GPP approved the new Release 11
study item, UE Application Layer Data Throughput
Performance. The Global Certification Forum (GCF)
indicated that they want 3GPP to perform UE application-layer
data throughput measurements under various simulated
This work was supported by the IT R&D program of MKE/KEIT.
[KI001484, Research on service platform for the next generation mobile
communication].
978-1-4577-1268-5/11/$26.00 2011 IEEE
Dept. of Information Communications Engineering
Chungnam National University (CNU)
Daejeon, KOREA
jyl@cnu.ac.kr, byckim@cnu.ac.kr
network conditions. The test will measure the achieved average
application-layer data rates using Transmission Control
Protocol (TCP) or User Datagram Protocol (UDP) in High
Speed Packet Access (HSPA) and LTE networks [3].
Although TCP performance over various wireless networks
has been heavily studied in the literature, different wireless
environment may introduce new challenges to TCP. TCP
window auto-tuning is the default feature on various operating
systems such as Windows Vista, Windows 7, Windows 2008
Server and Linux, and so on. However, TCP performance over
wireless networks with auto-tuning enabled is almost never
mentioned. Reference [4] is the only one that discusses TCP
performance with auto-tuning enabled. It shows the TCP
throughput measurement of TCP variants over commercial
WiMAX networks with auto-tuning enabled. The results
indicate that the WiMAX link does not adversely affect the
intended operation of TCP variants, but that it is not well-suited
for the aggressive Cubic and window auto-tuning. Therefore it
concludes that TCP Cubic and window auto-tuning are not
recommended for connections traversing WiMAX links.
In this paper, we describe issues on the TCP performance in
LTE networks. Section II briefly introduces the LTE radio
interface focusing on the user plane protocol, including
Medium Access Control (MAC) Hybrid Automatic Repeat
request (HARQ) and Radio Link Control (RLC) Automatic
Repeat request (ARQ). Section III discusses TCP performance
factors such as TCP window size, loss probability, and Round
Trip Time (RTT). We also show the test results in the ETRI
LTE-Advanced system with varying TCP performance factors
in LTE links and TCP auto-tuning enabled. To the best of our
knowledge, this work is one of the first detailed measurements
of TCP performance on a real LTE-Advanced system and on
LTE-family networks with TCP auto-tuning enabled. Section
IV discusses a discovered problem in which delay spikes
incurred by MAC HARQ reordering and RLC ARQ increase
TCP RTT and degrade TCP performance. Finally, we propose
some enhancements to alleviate the problem and improve TCP
throughput in LTE networks as a result. Some concluding
remarks, including future works, are given in section V.
II. BACKGROUND INFORMATION
A. LTE User Plane Protocol
In the LTE user plane, the PHY layer provides a bit pipe
with Adaptive Modulation and Coding (AMC) by protected
turbo-coding and a cyclic redundancy check (CRC), and
processes CRC ACK/NACK feedback. The MAC sub-layer
493 ICTC 2011
provides multiplexing/de-multiplexing, error correction
through HARQ, and scheduling. The RLC sub-layer provides
the segmentation/concatenation/reassembly of RLC SDUs,
reordering of RLC PDUs, in-sequence delivery, and error
correction through ARQ. The Packet Data Convergence
Protocol (PDCP) sub-layer provides header compression,
ciphering/integrity protection, and in-sequence delivery and
retransmission of PDCP SDUs at handover [5]. Fig. 1 shows
the LTE user plane protocol stack.
III. TCP PERFORMANCE IN LTE NETWORKS
We measured the TCP throughput in the ETRI LTE-
Advanced system through varying TCP performance factors
such as TCP window size, loss probability, and RTT in LTE
links. In the test, the TCP client in the UE is on Windows OS
and the TCP server is on Linux. The TCP on Linux uses Cubic
TCP as the default congestion control with auto-tuning enabled.
In our testbed, the RTT between the TCP client and TCP server
is about 13ms. Also, a UE can use two carriers, and the
maximum bandwidth between a UE and eNB is 110Mbps per
carrier, so the maximum bandwidth per UE is 220Mbps in total.
The Robust Header Compression (ROHC) function at the
PDCP sub-layer is disabled in the test. We show the test results
and discuss the TCP performance factors one by one. We
repeated each test ten times and measured the average TCP
throughput and utilization. Table I shows the test parameters.

TABLE I. TEST PARAMETERS

FTP File size 700.74MB AVI file

Figure 1. LTE user plane protocol stack TCP segment size (MSS) 1380Bytes
TCP Receive Window 65535Bytes (Windows XP)
If the receiver detects a transmission error, the receiver
Size (rwnd) Auto-tuning (Windows 7)
sends CRC NACK feedback to the sender. When the MAC
sub-layer HARQ function of the sender receives CRC NACK UE IP connection IPv6
feedback from the receiver, it performs retransmissions of the Bandwidth 220Mbps
corrupted transport blocks, and thereby corrects the majority of PDCP/RLC/MAC Header Under 0.005% (Minimum)
all transmission errors. The HARQ protocol uses eight stop- overhead
and-wait HARQ processes, and HARQ RTT in the uplink is Max HARQ TX 4
8ms and that in the downlink is minimum 8ms [6]. Max ARQ ReTX 5
LTE supports two types of bearer, a Unacknowledged HARQ BLER Under 0.1%
Mode (UM) bearer and an Acknowledged Mode (AM) bearer. HARQ RTT 8ms
The UM bearer makes use of a fail recovery by the HARQ at PUSCH Always scheduled
the MAC sub-layer only, and thus can be used for radio bearers RF Bandwidth 40MHz (20MHz*2 Carriers)
that can tolerate a certain amount of loss. The AM bearer
RF Frequency 3.56 ~ 3.60GHz
provides more reliability than the UM bearer by the help of
ARQ retransmission at the RLC sub-layer. Delay bet. eNB and FTP Under 5ms
server
If the RLC sub-layer receiver detects a gap in the sequence
of the received PDUs, it starts a reordering timer assuming that A. TCP Window Size
the missing PDU still is being retransmitted in the HARQ The achievable TCP throughput is bounded at [Throughput
protocol. HARQ failures appear if a maximum number of <= TCP rwnd/RTT], where rwnd is the TCP receive window
HARQ transmission attempts are exceeded or HARQ feedback size and RTT is the round-trip-time of the path. To optimize
NACK-to-ACK errors occur. When the timer expires, usually the TCP throughput, the receive window is greater than [path
in a HARQ failure case, an RLC UM receiver delivers SDUs to bandwidth * RTT], which is known as the bandwidth-delay
PDCP with a certain amount of loss. However, an RLC AM product (BDP). Unfortunately, Windows XP TCP/IPv6 stack
receiver sends a status message comprising the sequence does not support window scaling, and thus the maximum
number of the missing PDUs to the sender. The ARQ function receive window size is only 65,535 bytes. As a result, the
of the RLC AM sender performs retransmissions based on the achievable TCP throughput is bounded at about 40Mbps.
received status message. The RLC ARQ protocol is a window-
based selective repeat ARQ [7], [8]. Next-generation TCP/IP stacks in Windows Vista and
Windows 7 support TCP receive window auto-tuning and no
Thus, the RLC UM is a high-persistent ARQ protocol longer use the TCPWindowSize registry value. TCP auto-
and RLC AM is a perfectly-persistent ARQ protocol except a tuning automatically determines the optimal receive window
Radio Link Failure (RLF) event. TCP applications can usually size on a per-connection basis. Thus, the user no longer needs
be mapped on the AM bearer due to greater reliability. to manually configure a TCP receive window for a specific
However, the ARQ persistence of the RLC AM ARQ increases connection or specific computers. It determines the optimal
latency and delay jitter to application data, and adversely receive window size by measuring the BDP and the application
delays the flow of TCP control information [9]. retrieve rate allowing up to a 16MB maximum receive window
size using the TCP window scaling option [10]. Through the
help of the auto-tuning feature, the measured TCP throughput

494
is around 200Mbps with the RLC PDU loss probability under
0.001%.
In conclusion, the UE should support the TCP window
scaling option to obtain a better performance if the BDP of a
TCP connection is larger than 65,535 bytes.
B. Loss Probability
The achievable TCP throughput is bounded at [Throughput
<= MSS/(RTT*sqrt(Ploss))], where the MSS is the maximum
segment size, RTT is the round-trip-time of the path, and Ploss
is the probability of packet loss. We measured the TCP
throughput of the UM and AM bearers by varying the RLC
PDU loss probability from 0.001% to 1%. In the UM bearer,
the probability of a packet loss is much the same as the RLC
PDU loss probability. However, in the AM bearer, the
probability of a packet loss in the wireless last-hop between
eNB and UE is nearly 0% through the help of the RLC ARQ.
Fig. 2 shows the measured TCP throughput of the UM
bearer vs. AM bearer. As expected, the AM bearer almost
always achieves better throughput than the UM bearer due to
less loss probability. The UM bearer shows much the same
throughput as the AM bearer with loss probability on the order
of 10-5. With the loss probability on the order of 10-5, the
utilization of the AM bearer is almost 90%, and that of the UM
bearer is nearly 87%. The missing 10% in utilization is due to
the time period of the TCP slow start phase in the TCP server
and the time taken to determine the optimal TCP receive
window size by auto-tuning in the TCP client.
Compared with that of AM bearer, the utilization of the
UM bearer is 75% with a loss probability on the order of 10-4,
25% with a loss probability on the order of 10-3, and at worst,
only 12% with a loss probability on the order of 10-2. From an
LTE design, the HARQ feedback NACK-to-ACK error
probability is on the order of 10-4 and the RLC PDU loss
probability after the HARQ is on the order of 10-3. Thus, the
UM bearer is not appropriate for TCP applications.
In conclusion, TCP applications should be serviced on the
AM bearer to obtain better performance.
Figure 2. TCP throughput of UM bearer vs. AM bearer
with variable loss probabilities of 10-5, 10-4, 10-3 and 10-2
C. RTT
In Fig. 2, the TCP throughput of the AM bearer is degraded
in proportion to the RLC PDU loss probability despite nearly
no application-layer PDU loss. This is due to increased TCP
495
RTT incurred by RLC ARQ retransmissions, as the achievable
TCP throughput is inversely proportional to the RTT.
In the LTE, layer 2 only provides in-sequence delivery of
SDUs to the upper layer. If an RLC AM receiver detects a gap
in the sequence of received PDUs, it starts a reordering timer
(t_Reordering) assuming that the missing PDU is still being
retransmitted in the HARQ protocol. When t_Reordering
expires, usually in a HARQ failure case, it sends a status
message comprising the sequence number of the missing PDUs
to the sender. The ARQ function of RLC AM sender performs
retransmissions based on the received status message. After the
gap is filled by the ARQ retransmission, it delivers
reassembled RLC SDUs to the upper layer in sequence.
Therefore, the TCP RTT of a packet that is retransmitted by the
RLC ARQ is proportional to the RLC ARQ RTT.
The RLC ARQ RTT is influenced by many factors such as
t_Reordering, status prohibit timer (t_StatusProhibit), and UL
scheduling (e.g., scheduling request, buffer status reporting).
We measured the TCP throughput of the AM bearer with
varying t_Reordering of 30ms, 15ms, and 0ms. Actually, 0ms
t_Reordering is not suitable, but we used it anyway as a
reference of the minimum TCP RTT with RLC ARQ.
Figure 3 shows the measured TCP throughput of the AM
bearer with t_Reordering of 30ms, 15ms, and 0ms. As expected,
the AM bearer with t_Reordering of 0ms almost always
achieves better throughput than the larger t_Reordering case
with every loss probability. The 0ms t_Reordering case shows
4%, 9%, and 32% gain compared with 30ms t_Reordering with
a loss probability on the order of 10-4, 10-3, and 10-2,
respectively. The 15ms t_Reordering case shows 3%, 2%, and
10% gain compared with 30ms t_Reordering with loss
probability on the order of 10-4, 10-3, and 10-2, respectively.
In conclusion, as we decrease the RLC ARQ RTT, the
throughput of TCP applications can be increased.
Figure 3. TCP throughput of AM bearer
with variable t_Reordering of 0ms, 15ms, 30ms
IV. ISSUES AND CONSIDERATIONS
As shown previously, the TCP throughput of the AM bearer
is degraded in proportion to the RLC PDU loss probability
despite nearly no application-layer PDU loss. This is due to
increased TCP RTT incurred by RLC ARQ retransmissions.
We discuss two points for decreasing TCP RTT, that is, a way
to decrease RLC ARQ RTT and a way to decrease TCP RTT
only. Also, we discuss the behavior of the TCP sender with
TCP auto-tuning enabled when the TCP ACK suffers delay
spikes.
We can decrease the RLC ARQ RTT by introducing a local
NACK [11], [12], but the gain from decreasing the RLC ARQ
RTT is not great. The local NACK has HARQ-assisted ARQ
mechanisms. There are three mechanisms for a local NACK.
First, if the HARQ transmitter detects a HARQ failure, the
transmitter ARQ entities are notified and retransmissions can
be initiated. Second, if the HARQ receiver detects a NACK to
ACK error, the transmitter ARQ entities are notified via
explicit signaling. Third, if the HARQ receiver detects a
HARQ failure, the transmitter ARQ entities are notified. A
local NACK clearly can be a help in decreasing the RLC ARQ
RTT, but the effect of a local NACK is similar to the use of
t_Reordering between 30ms and 15ms. From the previous RTT
section, the gain from using 15ms t_Reordering is under 10%.
Also, simulation results from [11] show that the gain from a
local NACK is marginal.
We can decrease the TCP RTT by introducing an out-of-
sequence delivery into LTE layer 2. An in-sequence delivery
of RLC and PDCP in AM mode increases the TCP RTT of all
SDUs in every PDU from the SN of the retransmitted PDU.
Therefore, this frequently incurs delay spikes in the TCP data
and TCP ACK compression. On the other hand, an out-of-
sequence delivery can increase the TCP RTT of the SDUs in
the retransmitted PDU only. However, an out-of-sequence
delivery is not included in the LTE specification due to a lack
of study on TCP performance of a UE when TCP auto-tuning
is enabled. Also, an out-of-sequence delivery incurs packet
reordering in the upper layers more, but packet reordering is
not a rare event in current high-speed networks, and there are
some mechanisms to alleviate the reordering problem [13]. We
also discovered that the TCP sender stops sending data when a
delay spike of TCP data is incurred by an RLC ARQ and the
delay of the TCP ACK is large. We consider this to be due to
the fact that the TCP sender misinterprets an increased TCP
RTT as an indication of decreased bandwidth with the same
BDP or possible congestion. Therefore an out-of-sequence
delivery can help relieve a misinterpretation of the TCP
sender.
V. CONCLUSIONS
In this paper we described the TCP performance in LTE
networks. We measured the TCP throughput in a real LTE
testbed based on various factors and TCP auto-tuning enabled.
As expected, the test results show that the AM bearer
outperforms the UM bearer due to less loss probability in the
former. However, the test results show that delay spikes
incurred by the RLC ARQ increase the TCP RTT and degrade
496
the TCP performance. We propose some enhancements for
improving the TCP throughput in LTE networks. First, a local
NACK decreases the TCP RTT as well as the RLC ARQ RTT.
Second, an out-of-sequence delivery helps decrease the delay
spikes of TCP data and TCP ACK compression. Finally, an
out-of-sequence delivery can help the TCP sender interpret
the available bandwidth and RTT of the TCP connection
exactly. For future work, we will study and test extensively an
out-of-sequence delivery in LTE networks with TCP auto-
tuning enabled.
ACKNOWLEDGMENT
We thank all members who actively participated in tough
but fruitful development and testing of the worlds first
operational LTE-Advanced System demonstrated outside lab
conditions.
REFERENCES
[1] The 3rd Generation Partnership Project (3GPP), http://www.3gpp.org/,
online.
[2] ETRI LTE-Advanced system, http://www.etri.re.kr/eng/,
http://eng.kcc.go.kr/download.do?fileSeq=30503, online.
[3] 3GPP TR 37.901, UE Application Layer Data Throughput Performance
Study Item Technical Report, V1.0.0, June 2011.
[4] E. Halepovic, Q. Wu, C. Williamson and M. Ghaderi, TCP over
WiMAX: A measurement study, IEEE International Symposium on
Modeling, Analysis and Simulation of Computers and
Telecommunication Systems (MASCOTS), pp. 1-10, 2008.
[5] 3GPP TS 36.300, Evolved Universal Terrestrial Radio Access (E-
UTRA) and Evolved Universal Terrestrial Radio Access Network (E-
UTRAN); Overall description; Stage 2, V10.4.0, June 2011.
[6] 3GPP TS 36.321, Evolved Universal Terrestrial Radio Access (E-
UTRA); Medium Access Control (MAC) protocol specification,
V10.2.0, June 2011.
[7] 3GPP TS 36.322, Evolved Universal Terrestrial Radio Access (E-
UTRA); Radio Link Control (RLC) protocol specification, V10.0.0,
Dec. 2010.
[8] A. Larmo, M. Lindstrm, M. Meyer, G. Pelletier, J. Torsner and H.
Wiemann, The LTE link-layer design, IEEE Communications
Magazine, vol. 47, no. 4, pp. 52-59, April 2009.
[9] G. Fairhurst and L. Wood, Advice to link designers on link Automatic
Repeat reQuest (ARQ), RFC 3366, Aug. 2002.
[10] J. Davies, The Cable Guy: TCP receive window auto-tuning,
http://msdn.microsoft.com/en-us/library/2007.01.cableguy.aspx, online.
[11] 3GPP R2-062772, Simulation results on HARQ assisted ARQ scheme,
Samsung, RAN2#55, Oct. 2006.
[12] D. M. Kim, Y. K. Choi, S. G. Jin, K. H. Han and S. H. Choi, A
MAC/PHY cross-layer design for efficient ARQ protocols, IEEE
Communications Letters, vol. 12, no. 12, pp. 909-911, Dec. 2008.
[13] K. C. Leung, V. O.K. Li and D. Yang, An overview of packet
reordering in TCP: problems, solutions, and challenges, IEEE
Transactions on Parallel and Distributed Systems, vol. 18, no. 4, pp.
522-535, April 2007.