Downlink TCP Proxy Solutions for
Interactive Gaming over HSDPA and
3G Networks
MARCO FIORENZI
Master’s Degree Project
Stockholm, Sweden 2007
Downlink TCP Proxy Solutions for
Interactive Gaming over HSDPA and
3G Networks
MARCO FIORENZI
Master’s Degree Project
February 2007
Automatic Control Group
School of Electrical Engineering
Abstract
High Speed Packet Data Access (HSDPA) is a recent development of third gen-
eration (3G) wireless systems to enable several applications to be available
through wireless communication. In order to increase performance (reliable
and timely data delivery), HSDPA supports new features related to the con-
trol of the radio resources, and scheduling of the users. However, even though
HSDPA evolution offers several performance improvements, large fluctuations
in the delay of the data delivery still exist. This makes difficult the adoption
of the Transmission Control Protocol (TCP) over HSDPA. In this thesis, a con-
trol structure already proposed in literature is studied and extended to im-
prove user experience of TCP over HSDPA. Specifically, the control structure
is a proxy entity residing in the communication chain between the server and
the mobile phone. The proxy can enhances the timeliness and reliability of
data delivery, thus it is a good candidate for real time applications. We have
implemented a complete HSDPA communication chain from the server (the
transmitter) and the receiver (the mobile phone) using the ns2 EURANE sim-
ulation environment. In the simulator, we have implemented the extended
proxy solution, and it includes also existing solutions for improving TCP over
wireless (as, e.g., Snoop). The simulator allows to benchmark the validity of
the proxy solution with respect to some existing solutions widely adopted for
internet communication. The application of our solution to interactive gaming
over HSDPA is also addressed.
iii
Acknowledgements
The work on this thesis has been an exciting and interesting experience. After
all this time in Sweden I really have to thank many people who has helped me
and supported me not to give up. It has been un intense work, but during this
period I have had the luck of meeting incredible people and find new friends.
First of all, I want to thank my supervisor Dr. Carlo Fischione, for his con-
tinuous support, advices all along the way and for his patience. I also want to
mention Neils Moller who always helped me when I needed it. Special thanks
to my examiner Prof. Karl Henrik Johansson; I’m very grateful for the op-
portunity I had to work with you at the Kungliga Tekniska Hogskolan (KTH),
Stockholm.
I would also like to express my gratitude to Prof. Fortunato Santucci from
University of L’Aquila, Italy, for trusting me and giving me the chance of doing
my Master Thesis within KTH and Ericsson.
I would like to give particular thanks to my friend, Daniele, for always
being there when I needed him, and for supporting me through all these years
and for supporting and helping me during this period of work.
I cannot forget all the guys that have worked with me in the Automatic
Control Group of the KTH: Pan, Pablo, Roberto and Viviana and all others
who, in one way or another, have helped me or cheered me up in some points.
Words are not enough to express all my gratitude. But, I can’t forget some of
my important Italian friends: Gianluca, Massimo, Matteo and Maria. Thanks
guys for your help, especially during these lasts days.
But above all, I want to thank my parents. They have always supported
me and helped me. They have tried to understand and respect my decisions. I
know how hard it has been for them because decisions were never easy to take
v
vi ACKNOWLEDGEMENTS
and many did not make me happy, but I had to take them. After all, as you
can see now, all I have gone through had a meaning. Thanks family. Thanks,
parents, for all.
Introduction
The increased use of Internet and data services motivated the evolution of cel-
lular systems from second to third generation. Since its introduction, third-
generation (3G) cellular technology has been heralded for its ability to deliver
more voice channels and higher-bandwidth pipes. The UMTS system (Uni-
versal Mobile for Telecommunications System) in Europe has prepared for this
evolution in successive releases within the third generation partnership project
(3GPP) that standardizes and specifies the UMTS air interface, the access and
core network architectures. Various advanced radio technologies are being in-
troduced through the various releases in order to convey mass market multi-
media services in UMTS networks.
Release 99 of UMTS, the first release, relies mostly on the introduction of
CDMA based radio and access technologies. This step in the evolution remains
insufficient to achieve full compatibility with IP (Internet Protocol). The air in-
terface as specified in release 99 does not provide the needed higher data rates
either. Therefore, releases 5 and 6 introduce a number of additional enhance-
ments into the standard to enable flexible and adaptive packet transmissions
and to offer Internet based services.
HSDPA (High Speed Downlink Packet Access) is a 3G mobile telephony
protocol in the HSPA (High Speed Packet Access) family, which provides a
smooth evolutionary path for UMTS-based networks allowing for higher data
transfer speed. This technology promises to bridge the gap between 3G and
the Internet, providing an overlay for the existing protocol stack, which makes
possible the delivery of high-speed data access to many users in a cell. Instead
of limiting high-speed data access to few users in a cell, HSDPA can deliver
384-kbit/s data to many more, up to 30, users. HSDPA has been introduced
vii
viii INTRODUCTION
in the standards after R99, essentially in release 5. Release 6 contains some
enhancements to this technology in order to improve performance.
The major evolutions introduced are at the physical and data link layers
specifically, the techniques introduced in HSDPA are adaptive modulation and
coding (AMC) to achieve better spectral efficiency, link adaptation to mitigate
radio channel impairments, Hybrid ARQ (Automatic Repeat Request) to re-
transmit erroneously received radio blocks and to increase link reliability and
scheduling to enable intelligent allocation of resources to improve capacity and
offer packet based multimedia services. Scheduling over shared channels must
take into account radio channel conditions, mobile location in the cell and ser-
vice type to provide tangible throughput, capacity and delay benefits. Schedul-
ing must also ensure fairness with respect to users and applications.
At the data link layer (Radio Link Control and Medium Access Control)
and the radio resource control, another major enhancement was the addition
of the downlink shared channels next to the release 99 dedicated channels. The
dedicated channels are suitable for real time services but are inadequate for
packet services. The introduction of shared channels results in power savings,
interference mitigation and system capacity improvements.
Besides, multiple transmit and receive antennas can also be used to achieve
higher data rates and improve system capacity. The introduction of multiple
antennas is planned for the last phases of the UMTS architecture enhance-
ments.
Recent activity in mobile computing and wireless networks strongly indi-
cates that mobile computers and their wireless communication links will be
an integral part of future internet works. Communication over wireless links
is characterized by limited bandwidth, high latencies, high bit-error rates and
temporary disconnections that must be dealt with by network protocols and
applications. In addition, protocols and applications have to handle user mo-
bility and the handoffs that occur as users move from cell to cell in cellular
wireless networks. These handoffs involve transfer of communication state
(typically network-level state) from one base station to another, and typically
last anywhere between a few tens to a few hundreds of milliseconds. Reliable
transport protocols such as TCP (Transport Control Protocol) have been tuned
INTRODUCTION ix
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 delay and mean deviation, and by
retransmitting any packet whose acknowledgment is not received within four
times the deviation from the average. Due to the relatively low bit-error rates
over wired networks, all packet losses are correctly assumed to be because of
congestion. In the presence of the high error rates and intermittent connectiv-
ity characteristic of wireless links, TCP reacts to packet losses as it would in the
wired environment: it drops its transmission window size before retransmit-
ting packets, initiates congestion control or avoidance mechanisms and resets
its retransmission timer. These measures result in an unnecessary reduction in
the link’s bandwidth utilization, thereby causing a significant degradation in
performance in the form of bad throughput and very high interactive delays.
The introduction of new features in networks to improve data rates and
enhance reliability of data transmission over the air interface can have nev-
ertheless an impact on end to end performance and efficiency. Retransmis-
sion mechanisms relying on ARQ interact with higher layer protocols, espe-
cially the TCP used in conjunction with IP to offer non real time services. Real
time services are typically offered using UDP/IP and streaming services using
RTSP/RTP/IP. Cross layer interactions can have a drastic impact on overall
throughput and capacity. Care must be taken to characterize these interactions
and suggest ways of preventing or at least reducing any negative effects result-
ing from the introduction of ARQ and other techniques in wireless networks
that unavoidably interact with congestion control mechanisms in Internet net-
works (when TCP protocol is used) and generate additional delay in receiving
data which can affect the efficiency of HSDPA for services with stringent delay
constraints (e.g., streaming).
Over wireless networks, where losses are mainly caused by mobility and
intermittent bad channel conditions, poor TCP performance is experienced.
To alleviate these problems over wireless links, several approaches have been
proposed for TCP enhancement (e.g. Physical Layer Solutions, Split Solutions
and End-to-End Solutions). One of these approaches, is to introduce a proxy
x INTRODUCTION
between the server and the terminal, i.e., splitting the connection into one con-
nection between the server and the proxy, and another one between the proxy
and the terminal. This approach has the advantage that changes in the system
are made only to the proxy and possibly the terminal; the server will see an
ordinary wired network. The control algorithm in the proxy sets the window
size according to event-triggered information on radio bandwidth changes and
time-triggered information on the queue length of the RNC. The scheme does
not require any changes to the terminals or to the Internet server, but they
may utilize any of the standard TCP protocols. The proxy then takes appropri-
ate action by adjusting the TCP window size. The computation of a suitable
window size in the proxy also takes into consideration the queue in the RNC,
which needs to be controlled at a suitable level due to delay fluctuations and
other uncertainties in the cellular system. After a bandwidth change, with the
proxy solution, the system is able to dynamically adjust the queue accordingly.
A proxy architecture can enhance the timeliness and reliability of data de-
livery of interactive games over 3G wireless networks. Unlike non-time-critical
applications like email and file transfer, network games demand timely data
delivery to maintain the seemingly interactive presence of players in the virtual
game world. Yet the inherently large transmission delay mean and variance of
3G cellular links make on-time game data delivery difficult. Further complicat-
ing the timely game data delivery problem is the frequent packet drops at these
links due to inter-symbol interference, fading and shadowing at the physical
layer. Mobile devices offer the opportunity to play games nearly everywhere.
Moreover, networked games allow individual players to interact with other
people and to participate in a larger gaming world, which also provides for
new business opportunities.
The focus for this thesis is implementation and simulation of proxy solution
within HSDPA networks with ns-2.
The rest of this thesis is organized as follows: in Chapter 1 the concept
of High Speed Downlink Packet Access and its main features are described
and analyzed in depth, while an overview of the main problems with TCP
in wireless and 3G networks are presented in Chapter 2. Chapter 3 presents
the proposed improvements to TCP for wireless links with a brief theoretical
INTRODUCTION xi
analysis of the Proxy solution performance. Chapter 4 presents an overview
of the 3G network gaming and study a possible implementation of interactive
gaming over HSDPA. After, the proposed solution is tested through a set of
simulations that are described in Chapter 5. Finally in Chapter 6 we conclude
our work with some conclusions and propose some guidelines for future work.
Contents
1 High Speed Downlink Packet Access - HSDPA 1
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 HSDPA Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Fast Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Adaptive Modulation and Coding . . . . . . . . . . . . . . . . . 6
1.5 Hybrid ARQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Fast Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 HSDPA Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7.1 Mac-hs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7.2 Channel Structure . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Transport evolution with HSDPA . . . . . . . . . . . . . . . . . . 15
1.9 Performances with HSDPA . . . . . . . . . . . . . . . . . . . . . 16
1.10 Beyond HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.10.1 HSUPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.10.2 MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.10.3 OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 TCP over UMTS-HSDPA 21
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . 23
2.3 Key parameters to evaluate TCP Performance . . . . . . . . . . . 26
2.4 TCP Connection over UMTS-HSDPA . . . . . . . . . . . . . . . . 27
2.5 Modelling of TCP over UMTS-HSDPA . . . . . . . . . . . . . . . 30
xiii
xiv CONTENTS
3 Enhancing TCP over wireless 35
3.1 Link-layer Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1 Snooping TCP at Base Stations . . . . . . . . . . . . . . . 36
3.1.2 Delayed Duplicate Acknowledgments . . . . . . . . . . . 38
3.1.3 Scheduling over Reliable Shared Channel . . . . . . . . . 39
3.2 Split Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 End-to-End Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1 Eifel Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2 TCP over Wireless Using ICMP Control Messages . . . . 43
3.4 Proxy Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.1 Proxy Overview . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.2 Using Radio Network Feedback to Improve TCP Perfor-
mance over Cellular Networks . . . . . . . . . . . . . . . 46
3.4.3 Objective of the proxy solution . . . . . . . . . . . . . . . 50
4 3G Network Gaming 53
4.1 Characteristics of Game Traffics . . . . . . . . . . . . . . . . . . . 53
4.2 IMS and Gaming Service . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Performance Enhancing Proxy for Interactive 3G Network Gaming 60
4.4 Game Transport Protocol (GTP) . . . . . . . . . . . . . . . . . . . 67
5 Simulations and results 71
5.1 Simulator: Ns-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 EURANE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Objective and simulation scenario . . . . . . . . . . . . . . . . . 75
5.4 Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5 Experimental results . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5.1 Scheduler behaviour . . . . . . . . . . . . . . . . . . . . . 80
5.5.2 Proxy Performance . . . . . . . . . . . . . . . . . . . . . . 82
5.5.3 Snoop and Eifel implementation . . . . . . . . . . . . . . 88
5.5.4 Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6 Conclusions 97
References 101
List of Tables
5.1 Connection lines between Nodes, without proxy . . . . . . . . . 78
5.2 Connection lines between Nodes, with proxy . . . . . . . . . . . 79
5.3 Average Throughput in different scenarios . . . . . . . . . . . . 95
xv
List of Figures
1.1 4 HS-SCCH frame structure . . . . . . . . . . . . . . . . . . . . . 14
1.2 HS-DPCCH frame structure . . . . . . . . . . . . . . . . . . . . . 15
1.3 Timing of HSDPA channels . . . . . . . . . . . . . . . . . . . . . 15
2.1 TCP’s Congestion Window in Reno implementation . . . . . . . 26
3.1 Proposed architecture . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Control Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Components in a General Game Service . . . . . . . . . . . . . . 56
4.2 Game Service over the IMS . . . . . . . . . . . . . . . . . . . . . 58
4.3 WING in 3G Wireless Network . . . . . . . . . . . . . . . . . . . 62
4.4 Example of Differential Coding . . . . . . . . . . . . . . . . . . . 66
4.5 Structure of the GTP packet header . . . . . . . . . . . . . . . . . 67
5.1 Architectural RNFProxy scenario . . . . . . . . . . . . . . . . . . 77
5.2 Architectural TCP Reno scenario . . . . . . . . . . . . . . . . . . 79
5.3 Architectural RNFProxy scenario . . . . . . . . . . . . . . . . . . 80
5.4 Comparison between scheduler algorithms . . . . . . . . . . . . 81
5.5 Link Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.6 Throughput Reno scenario . . . . . . . . . . . . . . . . . . . . . . 83
5.7 Throughput Proxy solution . . . . . . . . . . . . . . . . . . . . . 84
5.8 Reno vs. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.9 Congestion Window of TCP Reno server for Reno scenario . . . 85
5.10 Congestion Window of RNFProxy for Proxy scenario . . . . . . 87
5.11 Congestion Window of TCP Reno Server for Proxy scenario . . 87
xvii
xviii LIST OF FIGURES
5.12 Without send RNF messages . . . . . . . . . . . . . . . . . . . . . 88
5.13 Correct Proxy solution . . . . . . . . . . . . . . . . . . . . . . . . 89
5.14 Snoop Agent in TCP Reno scenario . . . . . . . . . . . . . . . . . 90
5.15 Eifel Agent in TCP Reno scenario . . . . . . . . . . . . . . . . . . 90
5.16 Comparison between Snoop and Proxy . . . . . . . . . . . . . . 91
5.17 Comparison between Eifel and Proxy . . . . . . . . . . . . . . . 92
5.18 Proxy with Snoop Agent . . . . . . . . . . . . . . . . . . . . . . . 93
5.19 Proxy with Eifel Agent . . . . . . . . . . . . . . . . . . . . . . . . 93
5.20 Definition both Snoop and Eifel in RNFProxy scenario . . . . . . 94
5.21 Comparison between Proxy and Proxy with TCP enhancement
protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
List of Abbreviations
CQI Channel Quality Indicator
DCH Dedicated Control Channel
EURANE Enhanced UMTS Radio Access Network Extensions
FCDS Fair Channel-Dependent Scheduler
FDD Frequency Division Duplex
HARQ Hybrid Automatic Repeat Request
HSDPA High Speed Downlink Packet Access
HS-DSCH High Speed Downlink Shared Channel
MAC Medium Access Control
MCS Modulation and Coding scheme
PDU Protocol Data Unit
RAN Radio Access Network
RLC Radio Link Control
RNC Radio Network Controller
RR Round Robin
SDU Service Data Unit
TCL Tool Command Language
TDD Time Division Duplex
TPC Transmit Power Control
TTI Transmission Time Interval
UE User Equipment
UMTS Universal Mobile Telecommunication System
xix
Chapter 1
High Speed Downlink Packet
Access - HSDPA
1.1 Overview
Mobile networks have evolved significantly during the last 3 decades. There
has been a clear need for higher bit rates as well as better spectral efficiency in
mobile communications. Several technologies such as CDMA-2000 or WiMAX,
provide solutions to offer high bit rates. In order to compete with these new
technologies and support the new needs, UMTS added a new feature in 3GPP
Release 5. This feature enhanced the bit rates as well as the spectral efficiency.
Furthermore, this feature will help to maintain UMTS as a very competitive
technology to provide high bit rates in mobile communications. This feature is
High Speed Downlink Packet Access [1].
The HSDPA system has been proposed as one of the possible long term
enhancements of the UMTS standard for downlink transmission. It has been
adopted by the 3GPP and will be used in Europe during the next years. HS-
DPA introduces, first, adaptive modulation and coding, retransmission mech-
anisms over the radio link and fast packet scheduling and, later on, multiple
transmit and receive antennas. UMTS architecture has not really gone through
many changes to introduce HSDPA. Only, a new MAC layer has been intro-
duced. Furthermore, some logical functions traditionally performed in RNC
1
2 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
have been moved to Node B. This new MAC layer is called MAC-hs and it
is located in Node B. MAC-hs will perform among other things scheduling,
HARQ, and flow control. These functions have been traditional performed in
RNC. Next to this, the physical layer has been upgraded with new physical
channels with shorter frame size (2 ms) and with link adaptation functions,
such as adaptive modulation and coding. Link adaptation replaces two im-
portant features of the traditional UMTS system. These features are variable
spreading factor and fast power control.
1.2 HSDPA Concept
Unlike two-way voice communications, that are essentially ”symmetric” in
their use of radio, many 3G mobile services - such as web browsing or stream-
ing live video - create more traffic coming to the user (downlink) than from the
user (uplink). HSDPA offers a way to increase downlink capacity within the
existing spectrum. There are no reliable studies available from open sources,
but the estimates generally state that HSDPA increases the downlink air in-
terface capacity 2-3 -fold. The first 3GPP networks conform to a 3GPP stan-
dard version called Release 99. Release 99 is a full 3G system, with clearly
improved capabilities compared to 2G (the basic GSM) and 2.5G (GPRS and
EDGE) systems. The maximum data rate per user in Release 99 systems is typ-
ically 384kbit/s, whereas in 2.5G systems it is a few tens of kbit/s, or just over
100 kbit/s at best. Current 3G technology can accommodate only a few max-
imum data rate users at a time before the cell capacity runs out in the down-
link direction. A typical user consumes more downlink than uplink resources.
Some applications, such as web browsing and many games, use uplink only for
control signalling, whereas the downlink carries lots of payload data for those
applications. Therefore, it is clear that a Release 99 system will first run out of
capacity in the downlink. A number of performance enhancing technologies
must be included in the UMTS standard to achieve higher aggregate bit rates
in the downlink and to increase the spectral efficiency of the entire system.
HSDPA [1] aims to improve downlink capacity, and thus remove the po-
tential bottleneck from the system. It increases both the system capacity as a
1.2. HSDPA CONCEPT 3
whole, and the data rate that can be allocated for one user. The maximum the-
oretical data rate for one user is 14.4 Mbit/s, but in real systems, this is likely
to be limited to around 2 Mbit/s at first (2048 or more).
HSDPA technology is based on Adaptive Modulation and Coding (AMC),
fast link adaptation, Hybrid ARQ and fast scheduling. The use of higher order
modulation and coding increases the bit rate of each user but requires more
energy to maintain decoding performance at the receiver. Hence, the introduc-
tion of fast link adaptation is essential to extract any benefit from introducing
higher order modulation and coding in the system. The standard link adap-
tation used in current wireless system is power control. However, to avoid
power rise as well as cell transmission power headroom requirements, other
link adaptation mechanisms to adapt the transmitted signal parameters to the
continuously varying channel conditions must be included. One approach is
to tightly couple AMC and Scheduling. Link adaptation to radio channel con-
ditions is the baseline philosophy in HSDPA, which serves users having favor-
able channel conditions. Users with bad channel conditions should wait for
improved conditions to be served. HSDPA adapts in parallel the modulation
and the coding rates according to the instantaneous channel quality experi-
enced by each user.
AMC still result in errors due to channel variations during packet trans-
mission and feedback-delays in receiving channel quality measurements. A
Hybrid-ARQ scheme can be used to recover from link adaptation errors. With
Hybrid-ARQ, erroneous transmissions of the same information block can be
combined with subsequent retransmission before decoding. By combining the
minimum number of packets needed to overcome the channel conditions, the
receiver minimizes the delay required to decode a given packet. There are three
main schemes for implementing HARQ: Chase combining (retransmissions are
a simple repeat of the entire coded packet), Incremental redundancy IR (addi-
tional redundant information is incrementally transmitted) and self decodable
IR(additional information is incrementally transmitted but each transmission
or retransmission is self decodable).
The link adaptation concept adopted in HSDPA implies the use of time
shared channels. Therefore, scheduling techniques are needed to optimize the
4 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
channel allocation to the users. Scheduling is a key feature in the HSDPA con-
cept and is tightly coupled to fast link adaptation. Note that the time-shared
nature of the channel used in HSDPA provides significant trunking benefits
over DCH for bursty high data rate traffic.
The HSDPA shared channel does not support soft handover due to the com-
plexity of synchronizing the transmission from various cells. Fast cell selection
can be used in this case to replace the soft handover. It could be advantageous
to be able to rapidly select the cell with the best Signal to Interference Ratio
(SIR) for the downlink transmission.
HSDPA work with enhancement techniques [2] applied on a combined:
CDMA-TDMA (Time Division Multiple Access) channel shared by users. This
channel, called High Speed Downlink Shared Channel (HS-DSCH), is divided
into slots called Transmit Time Intervals (TTIs) each one equal to 2ms. The sig-
nal transmitted during each TTI uses the CDMA technique. Since link adap-
tation is used, the variable spreading factor is deactivated because its long-
term adjustment to the average propagation conditions is not required any-
more. Therefore, the spreading factor is fixed and equal to 16. The use of rela-
tively low spreading factor addresses the provision for increased applications
bit rates.
1.3 Fast Link Adaptation
The wireless channel in cellular systems is a composite multipath/shadowing
channel. The radio waves follow several paths from the transmitter to reach
the destination. Fading occurs when many paths interfere, adding up to a com-
posite signal exhibiting short time signal power variations at the receiver. This
power could be weaker or stronger than the required power needed to achieve
a given user Quality of Service (QoS). The link quality between the transmit-
ter and the receiver is also affected by slow variations of the received signal
amplitude mean value due to shadowing from terrains, buildings, and trees.
To deal with the problems caused by multipath fast fading, the existing
wireless systems use diversity techniques such as long interleaving, robust
channel coding, frequency hopping, and direct sequence spread spectrum. The
1.3. FAST LINK ADAPTATION 5
spread spectrum technique (frequency hopping and direct sequence) spread
the signal bandwidth over a wider frequency spectrum so that only a part of
the spectrum is affected by the fading. Interleaving can be seen as spreading
technique over time. By reordering the bits before transmission, the informa-
tion message is spread out over time. Therefore, bursty errors caused by the
fading channel are spread out in time so the decoder receives distributed non
bursty random errors that are easier to detect and correct. The channel coding
includes redundancy in the transmitted signal to increase robustness against
errors. Introducing more redundancy increases robustness but decreases effec-
tive information bit rate. In current systems, the channel coding rate is fixed to
deal with the worst case and the transmission power is adapted to the channel
conditions [3] in order to achieve the application QoS.
Since fading results from the addition of different waves from multiple
paths, it can potentially be predicted. Channel parameters (amplitude, phase,
frequency), remain stationary for time windows of the order of half a wave-
length. Estimation of the channel is feasible over a few ms and power can be
consequently adjusted over such time scales.
In the UMTS R99, channel estimation is used to adapt the transmission
power of each user, every slot, to the short term channel variations. This is
achieved at the cost of some power rise and higher interference.
In HSDPA, the HS-DSCH channel can be allocated to the user with favor-
able channel conditions. To this avail, a Channel Quality Indicator (CQI) has
been introduced in HSDPA to enable such intelligent allocation of resources to
users.
The idea is to measure the channel quality over the Common Pilot Indi-
cator Channel (CPICH) and to transmit the measurement report over the HS-
DPCCH channel to the node B, so that scheduling and AMC can act accord-
ing to the CQI and hence optimize channel resource allocation. The time win-
dow between the channel conditions measurement and the resource allocation
should not exceed half a wavelength as indicated previously. By considering
the transmission time of the HS-DSCH channel (1 TTI), the overall delay be-
tween the radio channel measurement and the end of the packet transmission
over the HS-DSCH channel is 10 timeslots.
6 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
Although, CQIs are meant to help Node B to perform link adaptation, Node
B will execute fast link adaptation depending on the implemented algorithm,
which is vendor specific. Not only decisions will be based on the CQI (or any
other implemented algorithm), but decisions will be also based on the available
resources of Node B. In general, regardless of the implemented algorithm, link
adaptation algorithms will select a transport block size, a modulation, and the
number of codes. This set of parameters is called transport format and resource
combination (TFRC).
In the 3GPP Release 6 [2], enhancements are added to the CQI reporting
method by introducing tuneable reporting rates through additional CQI re-
ports during periods of downlink activity and fewer reports at other times.
These additional CQIs can be initiated on demand of fast layer signalling. In
addition, a certain number of successive CQI values may be averaged with re-
spect to channel quality at the UE. The averaged value is reported and used
with the instantaneous CQI measured to select the Modulation and Coding
Scheme (MCS). The motivation for this technology is to improve the selection
of MCS, so that the delay due to HARQ retransmissions can be reduced. In
addition, the UL signalling overhead may be reduced and this decreases the
uplink interference.
1.4 Adaptive Modulation and Coding
HSDPA uses two modulation schemes for the HS-DSCH channel. One is the
QPSK modulation which was already used for the DCH channel in Release
99. The second modulation scheme is 16QAM [4]. The modulation 16QAM
uses four bits to represent a symbol, while QPSK uses just two bits for the
same purpose. Hence, 16QAM doubles the data rate. The achievable bit rates
for HSDPA are depending on the modulation, code rate, and the number of
channelization codes.
Node B will adjust the modulation required in each TTI depending on the
radio environment of the UE. This fact will minimize the effect of the near-far
problem. In other words, UEs nearer Node B will receive better Es/N0 (Energy
per symbol / noise spectral density) than those UEs situated far from Node B.
1.5. HYBRID ARQ 7
Therefore, Node B will select a higher modulation level (16QAM) for the for-
mer UEs, while a lower modulation level (QPSK) will be preferred for the later
UEs. Higher modulation levels are selected when the Es/No received by the
UE is appropriate for those higher modulations levels. For instance, 16QAM
will be selected when the Es/No at the UE guarantees a correct demodulation
by the UE.
UMTS system makes use of both convolutional and turbo encoders; how-
ever, HSDPA uses only turbo encoders since turbo encoders are more effi-
cient than convolutional encoders [5]. For backward compatibility reasons,
HSDPA still continues using 1/3 rate turbo encoders. The effective code rate
(ECR), though, will differ from the turbo encoder rate. After scrambling the
data through the turbo encoder, the data rate will be adjusted according to the
TFRC. Data is adjusted by means of puncturing or repetition of the turbo en-
coder output. Puncturing or repetition rate will, then, adjust the ECR [6].
The task of the turbo encoder module and the puncturing/repetition mod-
ule is to encode the data sent over the air interface in a way that data is pro-
tected against channel noise, i.e. data can be recovered even if the channel
noise corrupting it. Puncturing and repetition is a HARQ functionality.
1.5 Hybrid ARQ
Hybrid automatic repeat request is an error control method performed in L1.
HSDPA uses HARQ stop-and-wait. Stop-and-wait means that the sender will
be halt until an acknowledgement is received. After that, the sender will con-
tinue sending information. Stop-and-wait is very inefficient unless several
processes are handled in parallel. In this way, while a process is halt and wait-
ing for an acknowledgement, another process can send information to another
user.
In UMTS, retransmissions are handled by RNC. Due to this fact, RTTs were
relatively high. In Release 5, HSDPA retransmissions are handled by Node B.
As a result, faster retransmissions and smaller RTTs will be achieved. Release
99 achieved RTTs around 110 and 150 ms. However, RTTs in HSDPA [7] will
be around 70 ms.
8 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
The fastest retransmissions will be MAC-hs retransmissions since Node B
is the only element involved in the process. After a certain number of retrans-
missions, RNC will take over Node B and it will perform a RLC retransmis-
sion. RLC retransmissions will have longer delays, which are direct effect of
the transmission through the Iub interface and the additional processing steps.
Finally, if the RLC retransmissions fail or a time-out at the application level
happens, a TCP retransmission will be necessary. TCP retransmissions will
be the slowest since these retransmissions will need to go through the whole
RAN, core network, and the Internet.
The fast retransmission procedure can be presented and simplified into four
steps. In the first step, RNC sends a packet to the UE. This packet will go
through Node B where it will be buffered, scheduled, and finally forwarded
to the UE. Second step, the UE will reply with an ACK, or a NACK. The
ACK/NACK is forwarded to RNC. Third step, in UMTS, RNC would take
care of retransmitting the appropriate packet whether it is necessary. Instead,
in Release 5, the ACK/NACK is received by Node B which will take action to
retransmit the appropriate data to the UE. Finally, the UE sends a positive ac-
knowledgement, fourth step, to Node B which will forward the ACK/NACK
back to RNC. Whether the UE sends a negative acknowledge to Node B, Node
B will retransmit again the correct data. After a certain amount of repetitions,
Node B will ask RNC to take action (RLC retransmission) and the process will
start again. If after n RLC retransmissions the UE still replies with negative
acknowledgements, higher levels will take over the retransmission and a TCP
retransmission will be performed.
HARQ [6] implements two different retransmission strategies: chase com-
bining and incremental redundancy. ”Chase combining”[8] means that retrans-
missions will be totally identical to the original transmitted data. On the other
hand, ”incremental redundancy” means that retransmissions will differ from the
original transmitted data. The output of the channel coding module is the in-
put of the HARQ module. The output of the HARQ module will depend on
the transmission strategy selected and the puncturing/repetition rate.
First transmissions will always be self-decodable. All systematic bits are
sent, in addition to some parity bits. The number of parity bits will depend on
1.6. FAST PACKET SCHEDULING 9
the puncturing/repetition rate. If data needs to be retransmitted, the sender
will either choose to send again a self-decodable stream or a non-self-decodable
stream. On one hand, chase combining mechanism will be made of two (iden-
tical) self-decodable streams. On the other hand, incremental redundancy will
be made of a self decodable stream and a non-self-decodable stream. Which
strategy is to be used will mainly depend on the channel quality and the UE
capability class.
As stated before, HARQ also performs puncturing and repetition of the
data obtained in the turbo encoder. Puncturing and repetition function are to
adjust the number of bits returned by the turbo encoder to the number of bits
of the HS-DSCH physical channel.
1.6 Fast Packet Scheduling
The shared time structure of the HS-DSCH channel supports the use of time
scheduling. Fast link adaptation based on AMC tightly coupled with schedul-
ing provides higher transmission rates and average throughput. By allocating
the HS-DSCH channel to the user with favorable channel conditions, higher or-
der MCS are selected and higher achievable data rate and average throughput
are provided. Introducing the MAC-hs entity in the node B for scheduling and
using low TTI value of 2 ms allow better tracking of the short term variations
of the radio channel. Users with temporary good channel conditions are more
easily selected.
With the growing demand on data application services (especially non real
time services such as interactive and background), HSDPA, should provide the
capability of supporting a mixture of services with different quality of service
requirements.
The scheduler has two tasks to accomplish: increasing the average through-
put by allocating the HS-DSCH channels to the user having favorable channel
conditions and achieving fairness between services. These two objectives are
in contradiction and there is a risk in achieving one at the expense of the other.
A trade-off between fairness and efficiency (e.g. increasing the cell throughput)
should be performed by the scheduler.
10 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
The most famous scheduling algorithms are: Round Robin (RR), Max C/I,
Proportional Fair (PF) and Fair Channel-Dependent Scheduler (FCDS).
Round Robin: RR algorithm allocates the channel to the users in a cyclic
order offering a fair time resource sharing among users. Since this scheduler
ignores the radio channel conditions, it does not provide a fair throughput
among users. The absence of the scheduling adaptation to the short term chan-
nel variations counteracts the fast link adaptation introduced in HSDPA. Con-
sequently, this scheduler provides low cell throughput. The only advantage of
using this algorithm is its implementation simplicity.
Max C/I: in this algorithm, the node B tracks the channel quality of each
user by measuring the SIR (Signal to Interference Ratio) on the CPICH channel
(Common Pilot Indicator Channel) and allocates the HS-DSCH channel to the
user with the best SIR. In the ideal situation when channel conditions of the
users present the same statistics, this strategy maximizes the total capacity of
the system and the throughput of individual users. In reality, the statistics are
not symmetrical since the users can be closer to the base station with a bet-
ter average SIR or at the cell border with relatively bad conditions, stationary
or moving at high speed, in a rich scattering environment or with no scatter-
ers around them. Therefore, by using the Max C/I strategy in practice, the
channel is always allocated with higher order MCS (i.e. higher average trans-
mission rate) but induces starvation of users with relatively bad channel con-
ditions. Consequently, this algorithm maximizes the cell capacity but presents
a problem of fairness between users especially for users at the cell border. In
addition, the QoS constraints (e.g. the throughput in a given time scale and not
the long term average throughput) of different services are not considered in
this scheduler which can have a drastic effect on higher layers such as TCP or
on certain services such as streaming.
Proportional Fair: PF realizes a reasonable trade-off between efficiency and
fairness among users [9] [10]. It consists in transmitting to the user with the
highest data rate relative to its currently achieved mean data rate. During each
TTI, the channel is allocated to the user having max(r/S); variable r is the trans-
mission rate in the current TTI (according to the transmission scheme selected)
and S is the average bit rate transmitted in the previous TTIs.
1.7. HSDPA ARCHITECTURE 11
Fair Channel-Dependent Scheduler: FCDS is a more practical scheduler
which has a strategy that incorporates both the RR method and the Max C/I
method, i.e. it uses variations of the radio channel conditions to improve sys-
tem capacity while implementing a degree of fairness. Thus it can be concerned
as a trade-off between the two extreme scheduling methods.
1.7 HSDPA Architecture
1.7.1 Mac-hs
A new MAC layer was introduced in 3GPP Release 5 to implement HSDPA.
Despite all MAC functions have been traditionally performed in RNC, HSDPA
has moved part of RNC intelligence to Node B. Hence, faster decisions and
shorter reaction times can be achieved. MAC-hs has four main functions [11]:
flow control, scheduling and priority handling, hybrid ARQ functionality han-
dling, and transport format and resource combination selection. On the other
hand, MAC-hs has slightly different functions at the UE side. These functions
are HARQ handling, reordering, and de-assembly.
The output of the MAC-hs is the HS-DSCH channel. Furthermore, a HS-
DSCH channel is associated to a downlink signaling channel and to an uplink
signaling channel. Besides of these channels, HS-DSCH channel needs to have
a DCH associated channel to carry user and system information in the uplink.
1.7.2 Channel Structure
HSDPA introduced only few new channels in 3GPP Release 5. Nonetheless,
HSDPA has continued developing and new channels were added in the fol-
lowing release, 3GPP Release 6, such as for example F-DPCH.
HSDPA can only send user information in the downlink path. Therefore,
HSDPA will need, besides its physical channels, an associated dedicated phys-
ical channel (DPCH) to provide a complete bi-directional interaction. These
associated channels will carry signaling traffic or data traffic depending on the
needs.
12 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
Transport Channels
HSDPA consists of a time shared channel between users and is consequently
suitable for bursty data traffic. HSDPA is basically conceived for non real time
data traffic. Research is actually ongoing to handle streaming traffic over HS-
DPA using improved scheduling techniques.
The High Speed Downlink Shared Channel (HS-DSCH) is the specific trans-
port channel tied to HSDPA. Unlike DCH, which is a dedicated transport chan-
nel, HS-DSCH is a downlink channel which is shared by all UEs within a cell,
i.e. HS-DSCH is a common transport channel. The fast adaptation to the short
term channel variations requires handling of fast link adaptation at the node
B. Therefore, the data transport channel HS-DSCH is terminated at the node
B. This channel is mapped onto a pool of physical channels called High Speed
Physical Downlink Shared Channel (HS- PDSCH) to be shared among all the
HSDPA users on a time and code multiplexed manner [12] [13]. This transport
channel can be mapped to either a (HS-PDSCH) or to a High Speed Shared
Control Channel (HS-SCCH) depending whether the transmitted information
is user data or signaling information, respectively.
The transport channel coding structure is reproduced as follows: one trans-
port block is allocated per TTI, so that no transport block concatenation (such
as in UMTS DCH based transmission) is used. The transport block size changes
according to the Modulation and Coding Scheme (MCS) selected using the
Adaptive Modulation and Coding (AMC) technique. To each transport block,
a Cyclic Redundancy Check (CRC) sequence with 24 bits is added. Since er-
rors occur in bursts, one CRC sequence per transport block (i.e. per TTI) is
sufficient. Once the CRC sequence is attached, the transport block bits are
bit scrambled and segmented into blocks to apply Turbo block encoding. The
code block size depends upon the turbo coding rate and can reach a maximum
value of 5114 bits [14]. The coding rate changes according to the MCS scheme
selected by the link adaptation technique. At the turbo encoder output, rate
matching is applied by the physical layer HARQ functionality. After matching
the number of bits to the number of bits in the allocated HS-DSCH physical
channels, segmentation divides the resulting bits among the HS-DSCH physi-
cal channels.
1.7. HSDPA ARCHITECTURE 13
Physical Channels
HSDPA defines three new different physical channels [13], two for the down-
link and one for the uplink. All physical HSDPA channels have a shorter frame
structure than the traditional UMTS. While UMTS used, in general, a 10 ms
channel frame, HSDPA channel frame uses a 2 ms TTI length.
High Speed Physical Downlink Shared Channel (HS-PDSCH)
HS-PDSCH is, actually, the physical channel used to carry the user data in the
downlink. It does not, though, carry any signaling data. HS-PDSCH has a fix
SF equal to 16, and it is not power controlled. Variable SF and power control
were the key to provide different bit rates in UMTS. To cope with this, HSDPA
has brought another modulation scheme. Thus, HS-PDSCH can use two types
of modulations: QPSK or 16-QAM.
Though HS-PDSCH has a SF equal 16, only 15 codes can be allocated for
each scrambling code. This is due to the fact that one code is needed for the
common channels HS-SCCH and HS-DPCCH. Nonetheless, the final number
of codes used will be UE dependant. Proposed UEs can support 5, 10, or 15
codes.
High Speed Shared Control Channel (HS-SCCH)
HS-SCCH is a downlink channel. This channel arrives 2 slots before the HS-
PDSCH. HS-SCCH channel transports the signaling data associated to a trans-
port channel. Basically, HS-SCCH indicates to the UE how to demodulate the
HS-DSCH. HS-SCCH is divided into two parts. The first part, which is more
critical, contains the UE identity, modulation used in the HS-DSCH, and cod-
ing information. This first part will provide enough information to the UE
to decode the HS-PDSCH. The second part of the HS-SCCH transports less
critical information, such as for example HARQ information, or redundancy
information.
This physical channel uses a SF equal to 128, and the modulation scenario
for this channel is QPSK. Unlike HS-PDSCH, HS-SCCH may be power con-
trolled.
Networks are configured with one HS-SCCH channel if HSDPA is time-
multiplex based. However, if HSDPA is code-multiplex based, the network
will need to be configured with more than one HS-SCCH channel. UEs, can
14 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
monitor at most four HS-SCCH channels.
Figure 1.1: 4 HS-SCCH frame structure
High Speed Dedicated Physical Control Channel (HS-DPCCH)
In the uplink, signalling information has to be transmitted for the HARQ ac-
knowledgment and the feedback measurement. The use of fast link adaptation
on the HS-DSCH channel requires knowledge of the channel quality during
the transmission. The UE measures the channel quality on the Common Pi-
lot Indicator Channel (CPICH) and sends the result to the node B. The use of
HARQ requires an acknowledgment message from the user to the node B, so
that the node B retransmits the erroneously received packet or a new packet.
The HS-DPCCH channel is an uplink channel used for signaling purposes.
The modulation scheme for this channel is BPSK and the spreading factor is
256; thus, this channel has a bit rate of 15 Kbps. Moreover, HS-DPCCH channel
is power controlled. The signaling information sent through this channel is
related to Ack/Nack, and to CQIs. Thanks to this feedback, Node B will be able
to perform link adaptation, scheduling decisions, and to retransmit erroneous
information.
The H-ARQ acknowledgment is a 1-bit Ack/Nack indication repeated 10
times and transmitted in one slot. The H-ARQ acknowledgement field is gated
off when there is no Ack/Nack information being sent. The measurement feed-
back information contains Channel Quality Indicator (CQI) that may be used
to select transport format and resource by HS-DSCH serving Node-B, accord-
1.8. TRANSPORT EVOLUTION WITH HSDPA 15
Figure 1.2: HS-DPCCH frame structure
ing to CQI tables specified in [15]. The channel quality information, consisting
of 5 bits, is coded using a (20,5) code transmitted over two slots.
Figure 1.3: Timing of HSDPA channels
1.8 Transport evolution with HSDPA
As already explained, HSDPA will provide higher spectrum efficiency thanks
to the new shared downlink channel and enhanced mechanisms like adaptive
modulation and coding, and the 16 QAM modulation when good radio con-
16 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
ditions enable the use of the higher rate modulation. This leads to a more
bandwidth demanding access in terms of transmission between the BTS and
the RNC. This impact on the throughput per BTS will depend on the mobile
performances for HSDPA, which are characterized by the UE category.
For instance, up to 4.8 Mbps per cell on the Iub, which is the interface be-
tween the BTS and the RNC, is expected with HSDPA in the next couple of
years, which means that even with a statistical multiplexing gain of 50 percent,
8 Mbps will be required for hot spots.
Besides, the inversion of the nature of the traffic with more than 60 percent
of data traffic will require wireless operators to plan new transmission archi-
tectures by adding more points of concentration in the access network in order
to take the best of the statistical multiplexing gain. It will also change the way
of engineering the transmission network by dedicating specific transport chan-
nels for recollecting the HSDPA traffic.
1.9 Performances with HSDPA
Indoor vs. outdoor HSDPA solutions
In the indoor environment, the small cell size, the very good and controlled
coverage, and low mobility lead to a very high spectrum efficiency and very
high data rate per user. Even if the 16 QAM modulation is very sensitive to the
radio conditions, this modulation will be used most of the time in an Indoor
environment. In addition, there is a very low impact on PA power for HSDPA
operation, which means the downlink throughput is not significantly impacted
by the minimum power required for the signaling HS-SCCH channel.
However, when dealing with outdoor configurations, the broadband per-
formances are much more challenging due to higher interference at the cell
edge and larger cell size compared to indoor coverage for WLAN-type ser-
vices.
Basically, there is a significant impact on PA power for HSDPA operation,
i.e., lower downlink throughput due to required power for HS-SCCH. There-
fore, HS-SCCH power control is required to reduce impact on HSDPA through-
put. Otherwise, more than 10 percent of the PA should be reserved for the HS
1.10. BEYOND HSDPA 17
SCCH Signaling channel.
Typically, in an outdoor environment, the signal to interference ratio is less
than -2 dB for more than 90 percent of the cell, which means a minimum power
of – 9 dB on HS-SCCH to guarantee a probability of error on the signaling
downlink channel of one percent.
Throughput per cell and throughput per user
The capability to change the modulation, the coding and the number of SF
allocated per user during the communication enables a higher average data
rate and higher spectrum efficiency. But the support of a high number of SF
16 codes and the support of the 16 QAM modulation require very good radio
conditions, i.e., high CQI.
Coverage
In most cases, wireless operators have already deployed a large number of
UMTS BTSs by using RF dimensioning for 64-kbps services. It is very impor-
tant to understand the impact of a migration towards HSDPA in terms of ca-
pacity and coverage.
Paradoxically, HSDPA enables a wider coverage than UMTS R99 due to
the adaptive modulation and coding and the fast scheduler in the BTS, which
provides more granularity in term of radio resource management.
At the cell edge, HSDPA is still able to deliver data while preserving the
capacity of the neighbor cells. Even with Soft Handover for UMTS R99, it is
possible to provide a 384-kbps dedicated channel at the cell edge that would
strongly impact all the capacity of sites involved in the Soft Handover.
Basically, this is the Dedicated Uplink Channel which will determine the
HSDPA coverage. For a typical cell design based on 64 kbps (PS or CS), the im-
pact is very limited and occurs only when the HS-DPCCH is effectively trans-
mitted.
1.10 Beyond HSDPA
With wireless mobile radio communication, there is an endless quest for in-
creased capacity and improved quality. As HSDPA is about to launch, new
technologies are promising even more bandwidth and new services like HS-
18 CHAPTER 1. HIGH SPEED DOWNLINK PACKET ACCESS - HSDPA
UPA (Enhanced DCH in 3GPP Release 6), MIMO (Multiple-Input Multiple-
Output) and OFDM (Orthogonal Frequency Division Multiplexing) in 3GPP
Release 7.
Going further to 3GPP Release 7 and to ensure competitiveness in an even
longer time frame, i.e., for the next 10 years and beyond, a long-term evolution
of the 3GPP radio-access technology is now under investigation in 3GPP RAN
Working Group.
1.10.1 HSUPA
The 3GPP objectives with HSUPA are to improve performance of uplink ded-
icated transport channels by scheduling the Uplink UE data rates depending
on the interferences and on the Node B processing resources, while increasing
the radio interface robustness with the HARQ protocol. The 3GPP Study has
concluded that the use of these mechanisms associated with a shorter TTI of 2
ms can lead to the following enhancements:
• 50-70% improvement in UL capacity;
• 20-55% reduction in end-user packet call delay;
• around 50% in user packet call throughput.
HSUPA is a very important step that can be achieved in the next years.
By reaching high spectrum efficiency and low latency for both the uplink and
downlink with HSDPA/HSUPA, wireless operators will be able to provide
seamless access services like VoIP.
1.10.2 MIMO
MIMO (Multiple-Input Multiple-Output) is also a very promising technology
that will empower UMTS HSDPA networks by providing three times more
throughput than HSDPA.
MIMO increases the capacity due to the multi-stream transmissions and
code reuse with multiple antennas on both the transmitter and receiver sides.
MIMO has been studied for a long time, but due to the very high processing
1.10. BEYOND HSDPA 19
power needed to recover the transmitted signals, it was not possible to imple-
ment such a technology in former processors.
MIMO is now part of the 3GPP Release 7 for multi-stream transmission
with code reuse and Transmit Diversity with more than two antennas. It is not
restrictive to HSDPA.
1.10.3 OFDM
Orthogonal Frequency Division Multiplexing (OFDM) is a spread spectrum
technology that distributes the data over a large number of carriers that are
spaced apart at precise frequencies. OFDM has already been used in the global
ADSL (asymmetric digital subscriber line) standard.
OFDM splits the available bandwidth into many narrow band channels.
The carriers for each channel are made orthogonal to one another, allowing
them to be spaced very close together.
The orthogonality of the carriers means that each carrier has an integer
number of cycles over a symbol period. Due to this, the spectrum of each
carrier has a null at the center frequency of each of the other carriers in the sys-
tem. This results in no interference between the carriers, allowing them to be
spaced as close as theoretically possible.
Each carrier in an OFDM signal has a very narrow bandwidth (i.e., 1 kHz),
thus the resulting symbol rate is low. This results in the signal having a high
tolerance to multipath delay spread, as the delay spread must be very long to
cause significant intersymbol interference (e.g., more than 100 micro sec).
Chapter 2
TCP over UMTS-HSDPA
2.1 Introduction
Transmission control protocol (TCP) is the most widely used transport proto-
col for packet data services (multimedia and streaming services) in wireless
networks. TCP was initially designed for wired networks where packet losses
and delays are mainly caused by congestion. TCP includes a drastic recovery
mechanism that reacts to congestion situations with abrupt throughput reduc-
tions. It then takes a long time to reach again its normal operating level.
Over wireless networks, where losses are mainly caused by mobility and in-
termittent poor channel conditions [16], poor TCP performance is experienced.
TCP misinterpret delays as congestion indications. Useless retransmissions are
experienced and much time is wasted during the slow start and the congestion
avoidance phases. To alleviate these problems over wireless links, several ap-
proaches have been proposed for TCP enhancement. Some solutions try to
introduce changes in the TCP paradigm, while others deal with popular TCP
versions (Reno and its variants). Eifel and Westwood TCP try to improve the
classic TCP behavior to keep it applicable over both wireless and wired net-
works. TCP selective acknowledgments (SACK) [17] is proposed to alleviate
the inefficiency of TCP in handling multiple drops in a single data window.
In split TCP[18], the end-to-end path is divided into two segments (typically
one wireless segment and one wired segment) on which different connections
21
22 CHAPTER 2. TCP OVER UMTS-HSDPA
are established and locally optimized. Split TCP violates TCP semantics [19]
and is incompatible with security requirements.
Most of the above proposed enhancements are based on the fact that wire-
less networks suffer from low throughput and high error rates. The main
source of packet loss in wireless systems is the link errors generated by unper-
fect transmission adaptation to short-term channel variations. Static or fixed
link-protection techniques, such as channel coding and interleaving, are not
effective in providing link protection and in correcting all errors experienced
over the radio link. The use of ARQ to retransmit erroneous packets is manda-
tory to achieve error-free radio transmission. In fact, introducing ARQ incurs
additional delays in packet delivery due to retransmissions. These delays con-
flict with TCP control mechanisms that interpret delay in packet delivery over
the wireless link as congestion in the fixed and Internet segments. The presence
of TCP in the end-to-end path between hosts is a fact that must be taken into
account when introducing advanced techniques in wireless. Ideally, changes
to TCP should also be avoided since it has already been widely deployed over
the past decade. TCP Reno is the most implemented version and is extensively
used by Internet applications.
However, over wireless networks, many enhancements are proposed. EGPRS
offers higher bit rates than GPRS, while in UMTS networks, the use of HS-
DPA offers higher throughput and makes the radio link channels more reliable.
Therefore, the need for a more complex or for a specific wireless TCP variant
becomes more and more questionable. HSDPA is one of a number of perfor-
mance enhancing technologies considered for the evolution of WCDMA. HS-
DPA includes techniques such as Adaptive Modulation and Coding (AMC),
Hybrid ARQ, fast scheduling, fast cell selection and Multiple Input Multiple
Output (MIMO) antenna solutions. Higher order modulations and coding pro-
vide higher spectral efficiency but because they degrade performance of the
decoded signal at the receiver, the use of fast link adaptation is essential. Even
though the modulation and coding rate could be selected on a dynamic basis
according to signal-to-interference ratio (SIR) estimated at the mobile termi-
nal, AMC still result in errors due to the variation of the channel during packet
transmission and feedback delays in the channel quality measurements. A
2.2. TRANSMISSION CONTROL PROTOCOL 23
hybrid- ARQ scheme can be used to recover from these link adaptation errors.
The combination of the Forward Error Correction (FEC) and Automatic Repeat
Request (ARQ) is called Hybrid ARQ and it can be used with soft combining
based on the Chase algorithm, to improve TCP performance. The FEC used in
HSDPA is a turbo code with a rate varying from 1/4 to 3/4. With HARQ, erro-
neous transmissions of the same information block can be combined with sub-
sequent retransmission before decoding. By combining the minimum number
of packets needed to overcome the channel conditions, the receiver minimizes
the delay required to decode a given packet.
2.2 Transmission Control Protocol
Two commonly used transport layer protocols are TCP and UDP. The latter
is a connectionless protocol that does not guarantee delivery of data. Exam-
ples of how it is used is in server client type request-reply situations and in
applications where prompt delivery of data is more important than accurate
delivery. As a contrast to UDP, TCP is a transport protocol with connections
that provides a reliable way of transporting in-sequence data from a sender to a
receiver. Some of the properties of TCP may be desired by certain applications,
but not all and the TCP overhead for the extra features may be undesired. They
can then use UDP messages and provide their own delivery mechanisms.
The reliable connection of TCP is achieved by segmenting the incoming
data flow into packets and sending each packet separately to the destination.
By using an acknowledgment mechanism consisting of sequence numbering
the data packets, the transmission of all data in the flow is assured. Any lost
data packets are detected by the acknowledgement mechanism and are retrans-
mitted. This allows all data to be received without any losses. The data packets
are then reassembled into the original byte flow using the sequence numbers
of bytes within the transported data packets.
Another service provided by the TCP protocol is congestion control. A
property of the network layer is that congestion of data in this layer causes
lower overall data throughput. By avoiding or limiting congestion in the net-
work layer, TCP can maintain a high level of data throughput. A complete
24 CHAPTER 2. TCP OVER UMTS-HSDPA
description of how TCP tries to govern its send rate and control congestion,
can be found in [20], while here we give only a short basic overview of TCP
functionality. Many different versions of the TCP protocol have been devel-
oped to address various details of the data transport. They generally use the
same mechanism, but the details in their operation differs.
TCP sends data packets and the receiver acknowledges the received data
to the sender. Congestion is detected by measuring the time between data are
sent and they are acknowledged, called the round trip time (RTT). If this time
exceeds a time-out value, TCP assumes that the data have been delayed by
congestion in the network. The time-out value is a prediction based on, and
updated by, the measured RTTs. The TCP protocol uses a congestion window
when determining its send rate. The window describes how much data are al-
lowed to be transferred through the network without congestion and together
with the RTT it determines the send rate of the TCP algorithm. To determine
the initial allowed transfer rate, TCP starts with a low amount of data and then
uses an exponential increase in data rate. This is called a slow start, which
in steps double the data that are transferred to the receiver. When congestion
is detected, either by triple duplicate or a retransmission timeout, or until the
window size reaches a threshold called slow-start threshold, the initial con-
gestion window size is determined to be half the amount of data transferred
in the last slow start step, so to be half the slow-start threshold. But, once the
slow-start threshold is reached, the slow-start soft state is replaced with the
congestion-avoidance soft state, where the growth of the congestion window
slows down.
The slow-start mechanism can be regarded as a soft phase where the sender
probes the buffer space in the network. The successive ACKs are interpreted
by the sender as an available space in the network to more transmitted packets.
Therefore, the sender keeps increasing the window size. On the other hand, the
aggressive exponential growth of the congestion window aims at rapidly fill-
ing the bottleneck to have a small effect on the throughput performance and to
optimize the system efficiency.
An important part in achieving a high throughput with TCP is to have a
stable RTT. If the RTT varies a lot, the TCP algorithm can not predict it accu-
2.2. TRANSMISSION CONTROL PROTOCOL 25
rately. This means that the algorithm more often signals for congestion and
reduces its send rate, although it might just be a short, temporary increase in
RTT.
Congestion Avoidance: as soon as the congestion window reaches the slow-
start threshold, the congestion-avoidance soft state takes over the evolution
control of the congestion window. During this phase, TCP slows down the
probing of the network for more available bandwidth [21]. The congestion-
window increase becomes linear: it is increased by one every cycle or RTT. In
other words, the congestion window (cwnd) gains incrementally by 1/(cwnd)
each time an acknowledgment is received. TCP gets out of this congestion
phase once a segment loss is detected. Then Sender enter in the third phase
of TCP’s Congestion Control algorithm, that is Reaction to congestion and the
behavior of TCP depends on how this loss is detected by a triple duplicate or a
timeout.
If the timer expires before receiving an acknowledgement, that is the so
called timeout occur, TCP interprets this phenomenon as a severe congestion
in the network. The network is overloaded, and the transmitted segments are
lost, which implies retransmission of the segments and a brutal reduction of
the congestion window. The earliest unacknowledged segment is then retrans-
mitted via fast retransmission, and the RTO is updated so twice than the last
RTO [22]. In addition, the congestion window is set to its initial value.
When a loss is detected by triple duplicate ACK, TCP interprets this phe-
nomenon as a congestion [23] in the network, and the lost segment is retrans-
mitted via fast retransmission algorithm. Then the control of the (cwnd) evolu-
tion depends on the implemented version of TCP.
Every subsequently received duplicate acknowledgment indicates that a seg-
ment has been received and stored in the received buffer. This fast recovery
phase is terminated as soon as a fresh acknowledgment is received. The fresh
acknowledgment acknowledges all the segments up to and including the data
that was outstanding when fast recovery started. Once the recovery phase has
ended, a new segment can be transmitted by the TCP sender.
But, it is true that the way of this ”Reaction to congestion” is performed
depends on the TCP version. The first implementations of TCP used to follow
26 CHAPTER 2. TCP OVER UMTS-HSDPA
Figure 2.1: TCP’s Congestion Window in Reno implementation
the Tahoe algorithm, where a timeout is not considered different from three du-
plicated acks. Both congestion indications result in the sender shrinking cwnd
to one segment, setting the value of the threshold to half the value it had at the
moment congestion was detected, and going back to slow start. Newer TCP
versions (such as TCP Reno) consider this algorithm too conservative, and they
distinguish a loss indication due to a timeout from the occurrence of three du-
plicated acks. A timeout causes the TCP Reno sender behave in the same way
as the previous Tahoe implementations, but the reception of three duplicated
acks are considered as a warning rather than an indication of congestion. In
such case both the threshold and cwnd are set to half the value of the previous
threshold. Thus, the sending rate is reduced by half, and the sender stays in
Congestion Avoidance instead of going back to Slow Start.
2.3 Key parameters to evaluate TCP Performance
The performance of TCP can be measured or valuated in different ways ac-
cording to the context, the system used, and the application carried over the
TCP connection. TCP Performance can be evaluated using the following key
parameters [21]:
• Effective throughput: The effective throughput, called also effective band-
width, is the data transmission rate of the application in bits/s. The ef-
fective throughput is more significant than the communication channel
throughput, since a inefficient implementation or a cross-layer interac-
tion between TCP and RLC may result in a transmission rate reduction
2.4. TCP CONNECTION OVER UMTS-HSDPA 27
at the TCP layer.
• Throughput variation: For some applications and services, it is impor-
tant to know the instantaneous throughput. The throughput variation
over a given timescale, depending on the application, is very important
to assess end-to-end performance.
• File transfer time: The time needed to transfer the entire file. This para-
meter is directly related to the effective throughput.
• Round trip time: The time between the transmission of a segment and the
reception of the acknowledgment. This time includes the delay in the in-
termediate network nodes (e.g., routers), which depends on the distance
and the traffic load in the network. This parameter can limit the effective
throughput.
• Delay variation or jitter: The jitter represents the time variation in receiv-
ing packets, (in other words, the variation of the RTT). This variation can
have a direct impact on the appearance of triple duplicate and timeout
events, which result in throughput limitation and wasting of resources.
• Fairness: it is an important characteristic, especially when TCP applica-
tions are carried over wireless systems. Unfair resource allocation can
have drastic effects on the effective throughput.
• Resource consumption: The amount of resources (e.g., buffer space, less
transmission power) needed to achieve a given effective throughput.
2.4 TCP Connection over UMTS-HSDPA
The significant differences between the data transfer over UMTS Release 99
and the HSDPA systems lies in the UTRAN. IN UMTS Release 99, a dedicated
channel is established between the user equipment and the node B to assure the
data transfer over the air interface. The node B and the Iub interface perform
a simple transfer of data to the RNC [24], which controls the user equipment
connection and the scheduling between different connections. In HSDPA, the
scheduling is located in the node B, and one shared channel is in charge of
28 CHAPTER 2. TCP OVER UMTS-HSDPA
managing different connections over the air interface. Therefore, the main data
buffer is located in the Node B instead of the RNC.
Losses in wireless network segments are produced by high-bit error rates and
handoff procedures. The ARQ protocol is used to recover from packet losses
over the radio interface, but this increases the delay of receiving packets at
the TCP layer. The use of soft-combining algorithms with ARQ in the Node
B reduces the delay generated by the ARQ protocol. In UMTS Release 99, the
ARQ protocol is implemented in the RNC, whereas in HSDPA it is handled
by the MAC-hs entity in the node B; in both cases, the data is delivered to the
TCP layer in sequence. This implies that the ARQ delay may only generate a
timeout in the TCP connection.
When studying TCP performance in UMTS systems, either Release 99 or
HSDPA, several parameters or variables can interact and affect TCP efficiency.
These parameters are the:
• TCP version such as Reno or SACK;
• Slow-start threshold, ssthresh;
• Initial congestion window, cwnd (1,2 Maximum Segment Size or more);
• MTU size;
• TCP receiver buffer size, which limits the advertised window, awnd ;
• Round-trip time (RTT) in the internet, which has a direct impact on the
TCP flow rate;
• Congestion rate and the segment losses in the Internet;
• Error rate over the air interface and the ARQ protocol used;
• RLC MaxDAT, which indicates the maximal number of retransmissions
of a given RLC PDU;
• Allocated DCH channel (e.g., SF, bit rate) in UMTS Release 99, which has
a direct impact on the overall RTT value;
• Scheduling algorithm used in HSDPA, which determines the transmis-
sion rate over the air interface and the delay jitter due to the variable
storage duration of the data in the Node B buffer;
2.4. TCP CONNECTION OVER UMTS-HSDPA 29
• RNC buffering capabilities in UMTS Release 99 and the node B buffering
capabilities in HSDPA;
• RLC transmission-window size, which indicate the maximum number of
RLC PDU that can be transmitted before receiving an acknowledgment;
• Number of HARQ channels in HSDPA, which indicates the number of
parallel HARQ processes that can be handled by the MAC-hs entity. Any
increase of this number reduces significantly the HARQ delay.
TCP, RLC and MAC-hs rely on the ARQ scheme to recover from packet
losses. All three entities ensure error-free reception of transmitted packets. In
UMTS Release 99, selective ARQ is used, whereas in HSDPA an N-channel
stop-and-wait scheme is implemented.
The packet loss is detected in TCP by a triple duplicate or timeout. In UMTS
Release 99 and HSDPA, a negative acknowledgment is transmitted and feed-
back to request the retransmission of the RLC PDU, UMTS Release 99, or the
MAC-hs PDU, HSDPA. The acknowledgment in TCP is controlled by the re-
ceiver. The sender does not have any control to request an acknowledgment.
The TCP acknowledgment is integrated in the header of a TCP segment which
is ACK field over 4 bytes. In UMTS Release 99, the acknowledgment is sent,
either periodically or when a RLC PDU is erroneous, by the receiver. In HS-
DPA, the acknowledgment of each received MAC-hs block is transmitted over
the HS-DPCCH channel and multiplexed with the channel quality indicator. In
fact, HSDPA introduces a new transport channel, high-speed downlink shared
channel (HS-DSCH), to be used for best-effort data. This channel is shared be-
tween users in the time and code domain, with a spreading factor (SF) fixed
at 16 and a transmit time interval (TTI) of 2ms. In addition to HS-DSCH, HS-
DPA uses two other channels shared control channel (SCCH) and dedicated
control channel (DPCCH) to carry the control signaling information according
to HS-DSCH.
TCP, RLC and MAC-hs allow packet transmission using a sliding window
(where the transmission window size change dynamically according to the
congestion control algorithm) so that several packets are transmitted before
receiving an acknowledgment of the packet in sequence in the sliding window.
30 CHAPTER 2. TCP OVER UMTS-HSDPA
In UMTS Release 99, the initial and the maximum size of the transmission-
window are configured by the RRC entity [25]. During the connection, the
receiver can request a change of the transmission-window size (this modifica-
tion can be due to, for example, a limited receiver buffer size, user equipment
capabilities, reception complexity, or delays); therefore the sender informs the
receiver about this change through one field carried in a status PDU. In HS-
DPA, the transmission-window size indicates the number of parallel HARQ
processes, or instances, that can be handled by the MAC-hs entity (up to eight
HARQ channels can be used simultaneously, in this way the maximum size of
the transmission window is limited to eight MAC-hs PDUs).
Reliable TCP protocol provide another important service to transmitted
data such as segmentation to the data received from upper layers.
In TCP, the segment size is variable and is upper bounded by a maximum size
called MSS (maximum segment size). MSS is negotiated between the end TCP
entities and is delimited by the size of MTU (Maximum transmission unit) at
the IP level. In UMTS Release 99, the RLC PDU size is selected during the con-
figuration of the RLC entity. The PDU size is generally equal to 43 bytes (3 bytes
for RLC header). IN HSDPA, the RLC PDU size is selected in the same way as
in UMTS Release 99. However, the MAC-hs PDU size changes dynamically ac-
cording to the selected MCS (an MCS is the combination of a modulation order
M, a channel coding rate τ , and a number of parallel HS-DSCH channel codes
N). The MAC-hs PDU is transmitted over one TTI (TTI is 2ms). Each RLC PDU
corresponds to one or more MAC-hs PDUs.
2.5 Modelling of TCP over UMTS-HSDPA
The TCP protocol has been widely studied and discussed in the literature. With
the growth of the applications services relying on the TCP/IP protocol stack,
the performance of TCP in the currently developed data networks has become
a more and more relevant research topic. A large number of analytical TCP
models have been developed with the aim of describing the TCP interaction
between the TCP protocol and the protocols and the control mechanism used
in a real data network. Even though these models consider a wide variety of
2.5. MODELLING OF TCP OVER UMTS-HSDPA 31
TCPs, from TCP Tahoe [26], [27] and Reno [27], [28] to the new version such as
TCP SACK and Vegas. TCP Reno is the version most addressed in the litera-
ture, since it is widely implemented in current systems.
Small-scale degradations over the air interface, such as fast fading, induce fluc-
tuations, and losses over the air interface that are mistakenly taken as conges-
tion over the fixed networks by TCP. Radio retransmission, used to achieve
error-free communications over the air interface, cause delays that are larger
compared to TCP timescales, resulting in degradation of end-to-end through-
put between distant hosts. In fact, TCP misinterprets errors over wireless links
as congestions and reacts by retransmitting TCP segments and by reducing the
congestion window and in fine the overall application throughput.
Major approaches have been developed to capture the characteristics of TCP
and to evaluate connection throughput and latency time. To develop a math-
ematically tractable and solvable model, many assumptions are made to sim-
plify the analysis. In most of these models, the TCP performance (i.e., latency
and throughput) are described based on the network parameters such as TCP,
RTT and packet loss rate. Some of these approaches consider only the triple
duplicate without capturing the timeout and its impact on TCP throughput.
But, it was observed [29] that 90 percent of the congestions in TCP result in
timeouts. The most popular model that includes the timeout impact assumes
TCP Reno and an independent packet loss model. This model provides a sim-
ple equation that can be used to determine the TCP transmission rate according
to the packet loss rate, the RTT, and the base timeout value.
In this section, we want to present a simple model to evaluate the per-
formance of TCP over HSDPA. This model is an extension of the packet-loss
model. The losses in the Internet are supposed to be independent and they
are often bursty and correlated. Therefore, new models are needed to capture
the impact of random correlated losses on TCP performance. Unfortunately,
including correlation for losses in existing models seems to be complicated.
TCP detect losses in two way: RTOs and triple-duplicate ACKs. The RTOs of
TCP can be caused by a congestion in the Internet network or by a delay due to
limited bit rate or to multiple retransmissions on the radio interface generated
by the ARQ technique, which increase RTT and RTOs of TCP. Modeling the
32 CHAPTER 2. TCP OVER UMTS-HSDPA
effect of TCP on HSDPA requires estimates of the latency time of the slow-start
phase, the loss recovery, and the steady-state phase.
In HSDPA, the size of a TCP segment is 1500 octets and each TCP seg-
ment is transmitted using several predefined TTIs, that is one segment each
2ms. Transmitting a TCP segment requires between 12 and 60 TTIs (depend-
ing upon the modulation and coding schemes used on the radio interface) [30].
Note also that the HARQ used in HSDPA is ”stop and wait”. The number of
retransmission required to deliver the TCP segment is a random variable due
to varying radio channel conditions. The time needed to transmit an error free
TCP segment is:
RTT =∑ns
i=1 NTTI(i)ns
Tj + RTTwired = RTTwireless + RTTwired
Where (from [30]):
• Ni =Pns
i=1 NT T I(i)
nsis the number of transmissions of a TCP segment;
• ns (variable) is the number of TTI needed to transmit a TCP segment
when no errors occur on the radio interface;
• NTTI(i) is the number of transmissions of TTI due to HARQ;
• Tj is the transmission time of a segment on the radio interface.
Since, each file, packet call or TCP segment is transmitted over a certain
number of TTIs, therefore the use of scheduling on a shared channel makes the
errors on each TTI independent (the successive TTIs are allocated to various
users), then the number of retransmission of each TTI data is independent from
the other TTIs. Using the central limit theorem, the sum of a large number of
independent and identically distributed (iid) symmetric random variables can
be considered as a Gaussian variable. Hence, the number of transmissions of
the packets (Ni) has a Gaussian distribution with mean value and variance N
and σ2:
N =1 + Pe − PePs
1− PePs
σ2 =Pe(1− Pe + PePs)
(1− PePs)2
Pe is the probability of errors after decoding the information segment via FEC
2.5. MODELLING OF TCP OVER UMTS-HSDPA 33
and Ps is the probability of errors after soft combining two successive trans-
missions of the same information block.
The parameters, N and σ2 can be calculated as follows: first of all, we sup-
pose that all the errors are detected, thanks to a CRC. Then only the last two
transmissions, and not all the erroneous transmissions, are combined. This ap-
proach can be considered as an approximation especially for block error rate
(BLER) around 10%. Moreover, we assume that the fast link adaptation keeps
the received SIR of each transmission scheme (modulation and coding) fairly
constant (equal to SIR target). Consequently, the probability to properly de-
code the packet and be error free after j (j>1) transmissions is:
Pj = (Pe)j−1(Ps)j−2(1− PePs)
Hence, the number of transmissions of a TCP segment (Ni) can be mod-
elled by a Gaussian variable, consequently the time needed to transmit a TCP
segment (RTT) is a Gaussian variable. The probability of timeout RTO ex-
pressed as prob(RTT = Gaussian > To) with the Gaussian assumption leads
to Q(To−E(RTT )σ2(RTT ) )
The data rate at the TCP layer is computed by dividing the data size by the
mean value of latency time E(T); a Markov process is assumed. Let Tss be the
latency time of the slow start phase, Tloss be the recovery time and retransmis-
sion timeouts (RTO) cost and Tca represent the latency time of the steady state
phase. Hence, the data rate is given by:
R =data
E(Tss) + E(Tloss) + E(Tca)
Consequently, modelling the effect of TCP on HSDPA requires estimates of
the latency time of the slow-start phase, the loss recovery, and the steady-state
phase.
The decrease of the TCP bit rate over the radio interface is due to two rea-
sons: decrease of TCP window size, and retransmissions of TCP segments. In
the case of dedicated channels, it is interesting to evaluate the final TCP bit rate
since the number of users is fixed. However, when several users share the same
channel in time, the performance of TCP includes the user bit rate and the sys-
tem throughput. The evaluation of the mean number of TCP segments retrans-
34 CHAPTER 2. TCP OVER UMTS-HSDPA
missions (NTCP ) becomes important. When NTCP has a low value compared
to the decrease of TCP window size, the decrease of TCP bit rate is essentially
due to the decrease of window size. In this case, the number of TCP segments
arriving at the node B decreases, and more TTIs are available on the shared
channel. By allocating these TTIs to the other users, the radio interface bit rate
can be increased: the transmission rate of each TCP segment, which limits the
increase of RTT and consequently reduces the degradation of TCP bit rate.
NTCP can be evaluated using the probability of transmitting segments n
times before correct reception. The probability that a segment is transmitted
only once is (1 − e) (let e be the probability of retransmission (congestion +
RTO): e = p + q − pq). The TCP segment is transmitted two times with a
probability e(1 − e). The retransmission of a segment could be caused by an
RTO or a triple duplicate. In the case of a RTO, the timeout period is To. If
another timeout occurs, To doubles to 2 To. This doubling is repeated for each
unsuccessful retransmission until a To of 64 To is reached, after which the To is
kept constant at 64 To. However, in the case of triple duplicate, a timeout still
equals To.
Chapter 3
Enhancing TCP over wireless
The applications and services built over the TCP/IP protocol stack today rep-
resent a large share of the overall traffic volume in the Internet and wireless
networks. Wireless networks are characterized by high losses due to radio
propagation impairments, higher delays, and very scarce bandwidth. The TCP
control mechanism originally designed for high bandwidth, short delays, and
congestion-limited networks are in fact not suitable for wireless systems.
To cope with the wireless link issues and to achieve better performance of
TCP over wireless networks, several solutions and TCP enhancements have
been proposed during last years. These solutions are suggested for integration
in different layers, spanning from link layer to transport layer solutions.
To enhance TCP performance over wireless systems there are two ideal be-
haviors:
1. the TCP sender should simply retransmit a packet lost due to transmis-
sion errors, without taking any congestion control actions;
2. the transmission errors should be recovered transparently and efficiently
by the network, that is, it should be hidden from the sender.
To acquire better understanding of the interactions that can occur between ra-
dio link layer and TCP, it’s possible to define three categories of schemes [31]:
Link Layer Solutions; Split Solutions and End-to-End Solutions.
35
36 CHAPTER 3. ENHANCING TCP OVER WIRELESS
3.1 Link-layer Solutions
Link-layer solutions aim at making the wireless link layer behave like wired
segments with respect to higher-level protocols. The basic idea is that errors
over wireless links should be recovered in wireless system without including
TCP in the recovery process. In other words, these solutions try to mask or
hide the error recovery from TCP. In the majority of the current wireless sys-
tem, the use of ARQ protocol allows recovery from wireless link errors and
provides relatively reliable transfer of packets to the upper layers. However, it
was observed that the interaction between ARQ and TCP may result in poor
performance due to spurious retransmissions caused by an incompatible set-
ting of timers at the two layers.
The snooping protocol provides a reliable link layer closely coupled with
the transport layer so that incompatibility and unnecessary retransmissions are
avoided. The main idea is to introduce an agent in the base station, or wireless
gateway, which can snoop inside TCP connections to gather the TCP sequence
number, to cache the unacknowledged segment in the base station, and to mask
the wireless link errors from the TCP sender by crushing the correspondent
acknowledgements.
3.1.1 Snooping TCP at Base Stations
The Snoop TCP scheme has the objective to confine retransmissions over the
wireless part of the path only. This is achieved by snooping inside TCP con-
nections so as to transparently retransmit corrupted packets without breaking
end-to-end TCP semantics. In this scheme a Snoop agent maintains state for
each TCP connection traversing the wireless gateway. TCP data packets sent
from the wired to the wireless host are cached locally, until TCP acknowledg-
ments from the wireless host verify that they were received. When duplicate
acknowledgments arrive, indicating that a packet was lost, the packet is re-
transmitted by the agent from its local cache. The duplicate acknowledgments
are then suppressed, i.e. they are not propagated to the wired host, to avoid
triggering end-to-end TCP retransmissions and congestion control. The agent
also uses local timers in order to detect losses when duplicate acknowledg-
3.1. LINK-LAYER SOLUTIONS 37
ments themselves are lost. The agent snoops inside TCP packet headers to
gather the state information it needs so as to avoid generating its own con-
trol messages. Snoop outperforms split TCP connection, even when TCP with
the SACK option is used over the wireless link, without violating TCP seman-
tics, since TCP itself remains unmodified. It also avoids conflicting local and
TCP retransmissions by suppressing duplicate TCP acknowledgments when-
ever it performs local error recovery. With Snoop, however, only the direction
of transfer from the wired to the wireless host benefits from local error recov-
ery, as the TCP receiver is implicitly expected to be located next to the wire-
less gateway. This is because Snoop relies on TCP acknowledgments to detect
whether a packet was received or lost, which are returned very fast when the
agent and the TCP receiver are on either side of the wireless link. If a wireless
host is sending data to a remote receiver though, TCP acknowledgments are
returned too late, and they may even signify congestion losses over a wired
link. As a result, Snoop is most profitable when nearly all data flow from the
wired towards the wireless host.
Snoop protocol consist of a TCP-aware link agent that monitors TCP seg-
ments in either direction. Two procedure are implemented in the snoop agent
in the base station [32]: snoop.data for data segments and snoop.ack for ac-
knowledgments.
The base station monitors all TCP segments received from the wired host, or
sender, and maintains a cache of new unacknowledged packets before for-
warding them to the mobile host. The snoop agent decides if a packet is new
or not by gathering the sequence number inside the segment header. When an
out-of-sequence packet passes through the base station, the packet is marked as
retransmitted by the sender to facilitate the behavior of the snoop.ack module
once it receives a duplicate acknowledgement of this segment. At the same
time, snoop acknowledgment module keeps track of the acknowledgement
transmitted from the mobile host. When a triple duplicate acknowledgement
sent by the module host corresponds to a packet cached in the base station, the
snoop.ack deduces that it is due to wireless link errors. So it retransmits the
correspondent packet and suppresses the duplicate acknowledgement. Note
38 CHAPTER 3. ENHANCING TCP OVER WIRELESS
that packet losses can also be detected by local timeout since the snoop.ack
module maintains an update estimate of the RTT.
The main advantages:
• It maintains the end-to-end semantics of the TCP connection;
• It performs efficiently during a handoff process since cached packets will
be transmitted to the mobile as soon as it can receive them. The snoop
relies on TCP acknowledgments to detect whether a packet is received or
not.
The main disadvantages:
• Snoop requires heavy storage and processing to cache TCP segments. In
the case of the cellular networks, the snoop is impractical due to the high
number of users in each cell. A snoop agent will be implemented in the
RNC, in the UMTS and not in the base station.
• The wireless gateway needs to snoop inside TCP connections, which does
not work when the packets are encrypted.
3.1.2 Delayed Duplicate Acknowledgments
An important link-layer solution is the Delayed Duplicate Acknowledgments
that tries to imitate the behavior of the snooping protocol but makes modifica-
tions [30] at the receiver rather than at the base station. When out-of-sequence
packets are received at the TCP receiver (e.g., mobile host, user equipment) the
receiver sends duplicate acknowledgments for the first two out-of-order pack-
ets. The third and subsequent duplicate acknowledgements are delayed for a
duration d. Indeed, this scheme assumes that the out-of-sequence is generated
by packet losses over wireless links, and a reliable link-layer protocol such as
ARQ is used. Therefore, the erroneous packets will finally be received correctly
after a certain delay.
3.2. SPLIT SOLUTIONS 39
3.1.3 Scheduling over Reliable Shared Channel
Another link-layer solution to improve the TCP performance is the Scheduling
over Reliable Shared Channel. We have seen in chapter 2 that the impact of the
wireless link scheduler on the TCP system performance was very important,
also because it can improve the long-lived TCP performance while reducing
the latency of short TCP flows. These improvements are shown to provide
efficient wireless-channel utilization. The idea of this link layer solution is to
simultaneously use a network-based solution called windows regulator and a
proportional fair scheduler with rate priority (PF-RP). The windows regulator
algorithm conveys the instantaneous wireless-channel conditions to the TCP
source by using the receiver windows field in the acknowledgements packets.
Link-layer solutions appear to be the most promising ones for improving
TCP performance over wireless systems using just ARQ and scheduling over
the radio link. More research is required to exploit wireless diversity more
extensively by taking more advantage of the random short-term channel vari-
ations of users to maximize over-all system throughput, to reduce TCP perfor-
mance degradations, and to achieve fairness among TCP flows.
3.2 Split Solutions
Another category of scheme to enhance TCP performance over wireless sys-
tems is the split solutions one. To shield the TCP sender from spurious re-
transmissions caused by wireless errors, several solutions propose to split the
TCP Connection into two connections at the point where the wired and the
wireless networks meet, since these two subnetworks do not have the same
characteristics and the same transmission rate. This splitting point is the wire-
less gateway, or the mobile router, and it changes from a wireless system to
another, for example in cellular networks as GPRS and UMTS it corresponds
to the GGSN, since the base station is not IP capable. The connection splitting
is handled by a software agent implemented in the wireless gateway. The first
connection -from sender to the wireless gateway- still uses TCP, whereas either
TCP or other reliable connection-oriented transport protocol can be used be-
40 CHAPTER 3. ENHANCING TCP OVER WIRELESS
tween the wireless gateway and the mobile host, or the receiver. Consequently,
TCP performance in the first connection are affected only by the congestion in
the wired network, and wireless errors are hidden from the sender.
TCP connections are split at the wireless gateways connected to both wire-
less and wired links. In this manner, when packets are corrupted by transmis-
sion errors over the wireless link, they can be retransmitted over the wireless
section of the path only.
One efficient approach to improve TCP performance over wireless networks
is to introduce a proxy between the server and the terminal, i.e., splitting the
connection into one connection between the server and the proxy, and another
one between the proxy and the terminal. This approach is often denoted split
TCP. This approach generate changes only to the proxy and possibly the ter-
minal, but the advantage of this solution is that the server will see an ordinary
wired network, and this approach will not required changes at the sending
server. With split TCP, one can in many cases use an arbitrary transport pro-
tocol between the proxy and the terminal. This may be an attractive option if
the operator has control over the networking software running on the termi-
nals, but when supporting off-the-shelf terminals, deployment of a specialized
transport protocol is difficult.
Indirect-TCP, also known as I-TCP[33], is a TCP enhancement scheme based
on the split approach. This protocol splits the connection into two connections,
the first one between a fixed host, such as a remote server, and a mobile sup-
port router located at the beginning of the wireless network, the second con-
nection is established between the mobile host and the mobile support router
so that faster reaction to mobility and wireless errors can be performed. In this
scheme, a software agent at the wireless gateway intercepts TCP connection
establishment messages and transparently decomposes the end-to-end connec-
tion into separate TCP connections for the wired and wireless parts of the path.
The agent bridges these connections by forwarding TCP packets between the
two. The connection over the wireless part has a lower delay, leading to faster
TCP retransmissions, while the connection over the wired part remains un-
aware of wireless losses. TCP can also be replaced over the wireless part of the
path by another transport protocol providing improved error recovery.
3.2. SPLIT SOLUTIONS 41
The main drawback of the split approach is that it violates end-to-end TCP
semantics, since an acknowledgment originating from the wireless gateway
may reach the sender before the corresponding data packet reaches its desti-
nation. If the gateway crashes after the acknowledgment has been returned to
the sender but before the data packet has reached the receiver, the sender will
incorrectly assume that the packet has reached its destination safely. Another
issue with split schemes is that wireless gateway faces significant overhead as
packets must undergo TCP processing twice.
Others TCP enhancement scheme based on the split approach, are: Mobile-
TCP and Mobile End Transport Protocol (METP)
The Mobile-TCP was used to deal with the handoff process that create fre-
quent wireless disconnections and dynamic wireless link bandwidth while main-
taining end-to-end TCP semantic. A architecture of this scheme adopts a three-
level hierarchy with the mobile host at the lowest level, the mobile support
station at the cell level, and the supervisor host at the highest level. The mo-
bile support station has the role of communicating with the mobile host and to
transfer packets to the supervisor host, which controls and manages the con-
nections between the mobile host and fixed host. The supervisor host con-
trols several mobile support stations, or cells. Using two TCP clients at the
supervisor host, the TCP connection is split into two connections: classic TCP
connection between the fixed host and the supervisor host; and Mobile-TCP
connection between the supervisor host and the mobile host. To preserve the
end-to-end TCP semantics, the supervisor host does not acknowledge a seg-
ment received from the fixed host until it receives its acknowledgment from
the mobile host.
The Mobile End Transport Protocol (METP) is a new transport protocol that
eliminates TCP and IP layers and operates directly over the link layer. By im-
plementing METP on wireless link, that is on the second connection between
the mobile host and the base station, performance problems can be avoided.
This performance problems are caused by the use of the TCP/IP protocol stack
for the second connection (i.e. between the base station and the mobile host like
in I-TCP); then this performance with METP can be avoided. The base station,
or splitting point, acts as a proxy for a TCP connection providing a conversion
42 CHAPTER 3. ENHANCING TCP OVER WIRELESS
of the packets received from the fixed network into METP packets. This result
in a reduced header since the transport and IP headers are removed.
3.3 End-to-End Solutions
End-to-End Solutions include some changes to TCP mechanics and involves
more cooperation between the sender and the receiver to separate wireless
losses and network congestion. There are a lot of end-to-end TCP enhance-
ment schemes, such as: TCP SACK, Forward Acknowledgment, SMART Re-
transmissions, Explicit Congestion Notification, and so on... In this thesis we
restriction attention to: Eiffel and TCP over Wireless Using ICMP Control Mes-
sages.
3.3.1 Eifel Algorithm
In the case of spurious timeouts, the TCP senders proceeds to a retransmission
of the segment interpreted to be dropped. When the sender receives an ACK
after the segment retransmission, it cannot decide if that ACK corresponds to
the retransmitted segment or to the first one. This phenomenon, is called re-
transmission ambiguity.
The TCP Eiffel was proposed to deal with this situation of retransmission am-
biguity [34][35]. Eliminating the retransmission ambiguity requires extra in-
formation in ACKs that the sender can use to unambiguously distinguish an
ACK for the original transmission of a segment from that of a retransmission.
The TCP timestamp option provides exactly what we need. The timestamp
value, the current congestion-window-size, and the slow-start threshold are
stored by the sender. When using the timestamp option the TCP sender writes
the current value of a ”timestamp clock” into the header of each outgoing seg-
ment. The receiver then echos those timestamps in the corresponding ACKs.
Eliminating the retransmission ambiguity is then implemented as follows. The
sender always stores the timestamp of the first retransmission triggered by an
expiration of the retransmission timer. Then, when the first ACK that acknowl-
edges the retransmission arrives, the sender compares the timestamp of that
ACK with the stored value. If it is smaller than the stored value, this indicates
3.3. END-TO-END SOLUTIONS 43
that the retransmission was spurious. Therefore, it resumes the transmission
with new data and restores the congestion-windows size and the slow-start
threshold values before the spurious retransmission.
A case when a timeout occurs due to lost ACKs. When receiving a duplicate
segment below the cumulative ACK some TCPs update a cached timestamp. If
a TCP sender receives the timestamp from the original segment after a timeout,
it deduces that the timeout was spurious. Therefore, if the receiver echoes the
original timestamp in response to duplicate segments, then a timeout due to
lost ACKs is considered spurious. Restoring the congestion control state in
this situation is partly justified; there is no loss and therefore no congestion in
the forward path. Ideally, TCP should implement some mechanism to reduce
the amount of generated ACKs to alleviate congestion in the reverse path.
The advantage of this scheme is that it uses one of the TCP options: it does
not require a new standardization. On the other hand, use of TCP options
increases the size of TCP segments. TCP SACK uses the header options field to
indicate up to four lost segments in an RTT. The use of timestamp or other TCP
options limits the number of lost segments indicated by the SACK scheme. To
overcome this constraint, Eifel can use a new specific bit in the TCP header
to indicate whether an acknowledgment is for a retransmitted segment or for
the original one. The disadvantage of this solution is that it requires a new
standardization to specify the new bit in the TCP segment header.
Finally, it is important to note that the Eifel algorithm does not prevent
the spurious timeouts, but it detects them after the segments retransmission,
which limits the efficient use of the wireless bandwidth.
3.3.2 TCP over Wireless Using ICMP Control Messages
The Internet Control Message Protocol (ICMP)[30] tries to avoid spurious time-
outs by using an explicit feedback mechanism. A TCP agent is introduced at
the base station. This scheme allows the sender to distinguish whether losses
are likely due to congestion or wireless errors, thereby avoiding the sender
from needlessly cutting down its congestion window. If the first attempt of a
packet transmission over wireless link fails, an ICMP control message called
ICMP-DIFFER and containing TCP and IP headers is sent to the TCP sender.
44 CHAPTER 3. ENHANCING TCP OVER WIRELESS
Therefore, the sender receives surely either an ACK or an ICMP-DIFFER within
one RTT after the packet transmission. At the receipt of the ICMP-DIFFER mas-
sage, the sender resets its retransmission timer according to the current RTT
estimate without changing its congestion-windows size and slow-start thresh-
old. The timer’s postponement of a retransmission timeout (RTO) gives the
base station sufficient time to locally retransmit the erroneous packet. In the
case of successive failures of the packet transmission, another ICMP message,
called ICMP-RETRANSMIT is sent to the TCP source. At the same time, the
TCP receiver generates duplicate ACKs since other subsequent packets have
been received. At the receipt of ICMP-RETRANSMIT and the first duplicate
ACK, the sender goes into fast recovery phase and retransmits the erroneous
packet. Once a new ACK is received, the recovery phase is ended and the
congestion-window size is set to the value before ICMP-RETRANSMIT was
generated. If neither ICMP-DIFFER nor ICMP-RETRANSMIT are sent to the
sender, the TCP congestion follows conventional TCP algorithms once a triple
duplicate ACKs or a retransmission timeout occur.
It is better to generate ICMP messages at the base station rather than at
the TCP receiver, since wireless errors may span all the corrupted packets in-
cluding the TCP and IP header. On the other hand, this solution requires an
intelligent and sophisticated base station capable of keeping track of all the
packets going through it and to note whether a packet has been acknowledged
or not.
3.4 Proxy Solution
3.4.1 Proxy Overview
A different approach to improve TCP over wireless is to introduce a new con-
trol structure between the server and the terminal. This new element for wire-
less systems is the proxy. The functions and goals of a proxy can take many
forms. Some proxies are mainly intended as HTTP caching devices, while oth-
ers may serve as security ”watchdogs”, preventing user access to improper
www sites. Yet another feature could be load balancing, where the proxy in-
telligently chooses a mirror site when the traffic is too heavy. The list goes on.
3.4. PROXY SOLUTION 45
But one common thing about most proxies today is that they exclusively han-
dle HTTP traffic. A more general proxy approach is made by the TCP proxy,
serving the whole TCP protocol suite. The main intention of the TCP proxy
is to offer secure connections between TCP applications, but any ”ordinary”
proxy service can be performed. The key feature of the TCP proxy is that the
traffic is identified by TCP ports. In other words, the way the TCP proxy keeps
track on where the packets should be forwarded is by mapping incoming and
outgoing TCP ports.
With a TCP proxy installed on the subnet the TCP client will open a con-
nection to the proxy, which, in turn, opens a connection to the specified server.
The mapping between the client-proxy connection and the proxy-server con-
nection can be either static or dynamic.
• In case of static mapping, the proxy will have a table of incoming ports,
each one mapped to a specific server. When the client opens a connection
to the proxy it then chooses the port number associated with the server
he wants to talk to.
• In case of dynamic mapping, the client must provide information about
who the intended server is. The proxy then opens a connection to that
server and maps the client and the server connection together.
In more detail (regardless of the mapping policy) a request/response would
look like this:
1. The client opens a TCP connection to the proxy providing the intended
server’s address (this by connecting to a predefined port or by providing
the address explicitly).
2. The proxy opens a TCP connection to the intended server and constructs
a mapping between the two connections (i.e. ”what comes in on this port
should go out on that port”).
3. The client sends a request packet to the proxy. (IP sender: client, IP re-
ceiver: proxy).
46 CHAPTER 3. ENHANCING TCP OVER WIRELESS
4. The proxy forwards the packet to the server, now announcing itself as the
sender.
5. The server receives the request and produces a response, which it sends
back to the source (i.e. the proxy).
6. The proxy receives the response, looks up the client connection from its
mappings and forwards it to the client, announcing itself as the sender.
As the proxy performs an application level service, the IP header of the
packets will change when passing through the proxy, giving the proxy as the
sender. Hence, no node on the path between the proxy and the server will not
be able to see the client. Still, however, the server is visible to everyone.
3.4.2 Using Radio Network Feedback to Improve TCP Perfor-
mance over Cellular Networks
A new control structure is proposed to improve user experience of wireless
Internet because the large end-to-end round-trip time (RTT) that is common
in wireless networks makes the control problem even harder [36][37][38]. For
high-bandwidth and long-delay networks, TCP throughput is limited by the
maximum TCP window size, which is less than or equal to 64 KB. The expo-
nential back-off, slow-start, and congestion avoidance mechanisms in TCP fur-
ther limit the throughput and may also force over-dimensioned layer-2 buffers
in the cellular system.
A proxy-based scheme can improve both the user experience of wireless
Internet, and the utilization of existing infrastructure. To give a general idea of
this scheme it’s possible to contemplate the presence of one proxy that resides
between the Internet and the cellular system. Whit an appropriate custom pro-
tocol between the radio network controller (RNC) of the cellular system and the
proxy, the data-link layer within the RNC provides information to the transport
layer within the proxy, this communication is called Radio Network Feedback
(RNF) [39]. The procedure is this: when the radio link bandwidth changes,
the RNC sends an RNF message with the radio connection’s new bandwidth
to the proxy. The proxy then takes appropriate action by adjusting the TCP
window size. The computation of a suitable window size in the proxy also
3.4. PROXY SOLUTION 47
Figure 3.1: Proposed architecture
takes into consideration the queue in the RNC, which needs to be controlled
at a suitable level due to delay fluctuations and other uncertainties in the cel-
lular system. Note that the proposed scheme does not require any changes to
the terminals or to the Internet server, but they may utilize any of the standard
TCP protocols.
The architecture of the scheme that we want to use is illustrated in the
Fig.3.1. The mobile terminal on the left downloads a file from the server on
the right, via a operator’s radio access network that it is composed by two
special nodes: an RNC that is responsible for allocating bandwidth to user con-
nections, and a proxy which acts as a gateway between the operator’s network
and the internet. Two TCP connections have been established: one between
the terminal and the proxy and one between the proxy and the server. The
endpoints use standard TCP to communicate with the proxy. The proxy, on
the other hand, adapts its sending rate towards the terminal using a custom
control algorithm, which is aided by extra information provided by the RNC.
The RNC sends RNF messages to the proxy, including information about the
current bandwidth allocation and the queue length in the RNC. The RNF mes-
sages are sent every time the bandwidth changes, and also periodically with a
relatively long period time.
In a typical scenario, a mobile terminal wants to request a file from a remote
web server. It initiates a TCP connection to the proxy, and sends an HTTP
request. The proxy receives the request, initiates another TCP connection to
the server, and forwards the request. Upon receipt of the request, the server
begins to send the file according to its standard TCP algorithm. The transferred
data is received by the proxy, where it is buffered and then forwarded to the
48 CHAPTER 3. ENHANCING TCP OVER WIRELESS
mobile terminal as soon as possible. Note that the bottleneck for the end-to-
end connection in most practical situations is in the cellular system. Even if
there is a TCP connection between the proxy and the terminal, the proxy does
not need to utilize the standard TCP congestion control. The idea with a proxy-
based scheme is to modify the control of the proxy’s sending rate to adapt to
the varying wireless conditions. In this way, the TCP connection to the remote
server does not suffer from the effects of the wireless link, and the connection
to the mobile terminal is tailored to the current link characteristics.
The proxy controls the sending rate by adjusting the TCP window size
based on information about the available radio link bandwidth and the RNC
queue. For this reason the proxy permits an event-triggered feedforward mech-
anism, based on the bandwidth changes and a time-triggered feedback mech-
anism based on the RNC queue size. The objective is to achieve a high utiliza-
tion of the radio link and maintain the RNC queue close to a reasonably small
reference value qref , by controlling the sending rate of the proxy. Like in stan-
dard TCP, the proxy use a window-based algorithm, but unlike standard TCP,
it takes advantage of explicit information provided by the RNC.
Consider the following notation:
• b is the bandwidth of the radio link;
• τf is the time it takes for a packet that is sent by the proxy to reach the
RNC;
• τb is the time it takes for a packet that is forwarded by the RNC to reach
the terminal, and for the corresponding acknowledgement to get back to
the proxy;
• q is the queue length at the RNC;
• The RTT of the cellular network, excluding queueing delay at the RNC,
is: τ = τf + τb ;
• The RTT, pondering queueing delay at the RNC, is: τ + qb ;
• ω is the current window size at the proxy.
The control structure is illustrated in Fig. 3.2. The control signal is the non-
3.4. PROXY SOLUTION 49
Figure 3.2: Control Structure
negative window size w, which indirectly determines the sending rate. The
network provides the proxy controller with two kinds of information. The con-
trol structure, with feedforward of radio bandwidth b, and feedback of queue
length q. Bandwidth variation act as a disturbance which can be measured but
not affected, which is why this part of the controller is a feed-forward com-
pensator. When the available bandwidth over the radio channel is changed,
the RNC sends an RNF message to the proxy to inform it about the new band-
width. The controller uses an event-triggered feedforward mechanism that
takes advantage of this information, and resets the window size to a new value:
ω = bτ + qref
where b and τ are respectively the estimate of propagation delay τ and the new
bandwidth from the RNC’s RNF message.
Between bandwidth updates, the RNC periodically sends RNF messages with
the current queue length. The controller compares this feedback information
to the reference value and adjusts its window:
ωk+1 = ωk + c(qref − qk+1)
where c is a constant. The feedback loop is designed to compensate for the bias
caused by a feedforward controller based on uncertain information. On shorter
time scales, the transmission window is fixed, and transmission is governed by
the usual ACK clock.
The proxy adjust its window size by ωk+1, but when the delay in the network
increases, more of the packets in a window w¡ill be in transit, and fewer will
be waiting in the RNC buffer, leading to a decreased queue length.
A challenge in split TCP is how to handle the buffer in the proxy, which is
needed because of the bandwidth variations in the connection between the
50 CHAPTER 3. ENHANCING TCP OVER WIRELESS
proxy and the terminal. Even if the traffic is controlled as described above,
the amount of buffered data in the proxy can increase considerably, leading
to scalability problems when applying the proposed proxy controller in prac-
tice. It is necessary to set a limit on the amount of data per connection that the
proxy can buffer. The remote server should thus be informed when the proxy
is running out of space. The connection between the server and the proxy uses
the receive window sent from the proxy to adjust the server sending rate. A
reasonable buffer size for a TCP flow is the bandwidth-delay product for con-
nection between the server and the proxy.
The performance of the proxy setup was evaluate in terms of the average
link utilization and the time to serve a user (TTSU). The TTSU is defined as the
time elapsed from when the connection is established (SYN packet sent by the
request) until the last data packet is received at the terminal.
Outages and disconnections, which are typical for wireless connections, affect
the performance of TCP connections considerably. For the proxy setup, an out-
age only increases the TTSU by the precise duration of the outage. The proxy
controller is able to successfully resume the transmission immediately after the
terminal is reconnected. Therefore, the improvements are larger when (possi-
bly many) small files are transferred. Many outages and bandwidth variations
also worsen the performance for the no proxy scenario, compared to the new
proxy solution.
The new setup, that with the utilize of proxy, reduces time to serve users, sub-
stantially increases radio link utilization and decreases the needed buffer size
in the RNC. The proposed control architecture might substantially improve the
user experience of wireless Internet. The proposal is transparent to both and
points, so no modifications need to be done to the terminal or the server.
3.4.3 Objective of the proxy solution
The proxy-solution is based on the information received from the RNC, whose
aim is to help the proxy draw an accurate picture of the current wireless link
characteristics. Most TCP versions try to estimate the available bandwidth by
means of RTT measurement and loss events, or, like TCP Vegas, by computing
3.4. PROXY SOLUTION 51
an estimate of the queue length at the bottleneck. However, in the case of HS-
DPA, such information is already known by the Node B, because it receives the
signalling information in uplink with the HS-SCCH channel, and it can be for-
warded to the proxy. The RNC encapsulates all the necessary information in a
Radio Network Feedback message (RNFMessage), and sends it to the proxy via
UDP. The main reason to use UDP is to make the information available as soon
as possible, and to reduce the overhead introduced by a reliable protocol (such
as TCP), in order to quickly adapt to link changes. The RNFMessage includes
the available bandwidth for a flow and the queue length at the bottleneck, and
it is sent every time the bandwidth changes. To sum up, from the servers point
of view, the servers send the requested files to the destination at the highest
speed that the IP network can support, according to their own implemented
TCP algorithms. From the mobile terminals point of view, they receive the
requested data as fast as the wireless link allows, and they acknowledge and
deliver the data to the applications. The proxy is located in the middle, and its
own TCP mechanisms are responsible for adapting the connection adequately.
It receives data from the servers and buffers it, and sends it to the destinations
simultaneously. At the same time it receives the RNFMessages from the RNC
and computes the appropriate parameters accordingly.
Chapter 4
3G Network Gaming
The purpose of this chapter is to report on some ongoing works related to Net-
work Gaming. The arguments studied have to be considered as an example
of possible solutions for TCP used for Network Gaming. The time allotted for
this thesis work not allow a deeper investigation of this interesting topic.
4.1 Characteristics of Game Traffics
The development of GTP was motivated by the fact that game traffic in MM-
POGs has characteristics which are different from those of other Internet ap-
plications such as the WWW, File Transfer Protocol (FTP), e-mail services, etc.
However, since game traffic is highly dependent on the features of the game
itself, it is difficult to generalize these characteristics. Therefore, in order to
characterize game traffic, it is necessary to select some representative network
games. The inter-arrival time of packets and their packet size, are some of
the important information that we have to measure, for the traffic analysis in
a Network Gaming. Usually, in a networked on-line game worldwide, TCP
is used for session and user management, while UDP is used for delivery of
game event data. In terms of packet size, almost all event data consists of less
than 64 bytes, with 60% of this data being made up of just 50 bytes. This means
that the packet size of game traffic is much smaller than that of general data
traffic and that the variance is also small. For example the inter-arrival time
can be generally less than 100 msec. This shows that event data tend to occur
53
54 CHAPTER 4. 3G NETWORK GAMING
in the form of bursts.
As a result of the traffic analysis, we defined several requirements for a new
transport protocol for MMPOGs.
Low delivery latency: The most important factor in MMPOGs is to deliver
game event data within the specified time boundary. For example, if the event
data for the movement of an object in the game is delivered after the specified
time limit, the data will become useless and, as a result, user satisfaction will
decrease dramatically. Therefore it is essential to guarantee low delivery la-
tency. However, it is impossible to provide on-time delivery over the current
IP networks, because IP networks support only best-effort services. Of course,
there are many proposals for providing Quality of Service (QoS) over IP net-
works, however, for a variety of reasons these solutions have not been widely
deployed. Therefore, we propose a flexible method in GTP for on-time de-
livery. Although this method does not guarantee absolutely on-time delivery,
it can be selectively inter-worked with various existing network technologies
such as DiffServ, MPLS, etc.
Adaptive reliable transmission: In MMPOGs, it is necessary to deliver event
data reliably in order for the games to be able to progress correctly. Therefore,
many commercial games use TCP as a transport protocol in spite of its over-
head. However, not all event data has to be delivered reliably. For example,
in on-line shooting games, when a user pushes the spacebar hundreds of times
to shoot the gun, each key pressed generates event data. Although a portion
of the event may be lost, this has no effect on the progress of the game. There-
fore, this kind of data does not require guaranteed reliable transmission. On
the other hand, user commands that make an object move in a certain direction
should be delivered without any data loss and retransmission in case of packet
loss should be supported in this case.
Low protocol overhead: MMPOGs based on the client-server model are de-
signed to support millions of concurrent users. Therefore, the transport pro-
tocol used should be a light-weighted protocol. The currently used transport
protocol, TCP, is not a lightweight protocol, because of its complex flow con-
trol mechanisms and control blocks. Therefore, it cannot meet the scalability
requirements of MMPOGs. Furthermore, since TCP uses a byte-based window
4.2. IMS AND GAMING SERVICE 55
scheme, it is difficult to support retransmission. Therefore, in developing GTP,
there was the focus on reducing the protocol overhead for the sake of scalabil-
ity.
Connection-oriented service: In terms of low protocol overhead, UDP may be
a suitable choice as a transport protocol in MMPOGs. It does not provide any
retransmission mechanism or flow control scheme. In addition, it transmits
data using a connection-less service model. However, in MMPOGs, it is essen-
tial to manage the game states for each user, so that a connection-oriented ser-
vice model is required. Therefore, GTP was designed as connection-oriented
protocol, unlike UDP.
4.2 IMS and Gaming Service
A new 3G network element called IP Multimedia Subsystem (IMS) has been
introduced in 3GPP specifications R5 and later. This because some standards
organizations and other related bodies have agreed to co-operate for the pro-
duction of a complete set of globally applicable technical specifications for a
3rd Generation Mobile System based on the evolved GSM core networks and
the radio access technologies supported by 3GPP partners. The technical spec-
ifications will be developed in view of global roaming and circulation of termi-
nals. From 3GPP specifications, a complete solution for the support of IP mul-
timedia applications (including voice communications) shall be available. The
solution consists of terminals, GERAN (GSM EDGE Radio Access Network)
or UTRAN (UMTS Terrestrial Radio Access Network) radio access networks
and GPRS evolved core network. The 3GPP IP Multimedia Subsystem (IMS)
enables a “platform” with capabilities like presence, multimedia conferencing,
messaging, and support for QoS (Quality of Service) for data traffic, etc.
By use of IMS service capabilities and standards protocols, a new QoS for
games as well as better performance and scalability can be achieved. Com-
plex services can be created and integrated into a game based on simple IMS
services, such as Instant Messaging and/or special services, such as a scoring
service. The availability of information as location, terminal capabilities and
presence status can significantly ease the development and feature enhance-
56 CHAPTER 4. 3G NETWORK GAMING
Figure 4.1: Components in a General Game Service
ment of games.
There is an important platform for the IMS that is a novel architecture and
platform games on the IMS that allows games to utilize the features and ca-
pabilities that are inherent to the IMS. At the same time existing games can be
flexibly adapted to this new type of network. Another advantage is the possi-
bility to reserve network resources for game data transmission, thus improving
the experience of players.
Multiplayer games allow two or more people to play together or against
each other in the same game. Networked multiplayer games are playable over
a network (e.g. the Internet). The communication range, speed, network cov-
erage, bandwidth and latency, as well as parameters of the game client devices
(processor, memory, graphics, etc.) have an influence on what kinds of multi-
player games can be developed.
Independently of the type of network that connects the players with the game,
the physical limitation of the network cannot be ignored. Important limita-
tions are the scarcity of resources, interferences, etc. on the radio link, leading
to small bandwidth and high latency.
The Game Service [40] is the sum of the contributions of all these compo-
nents, (see Fig. 4.1):
• Gaming Service is the central component, a server-side platform providing
4.2. IMS AND GAMING SERVICE 57
network connectivity and general support for gaming.
• Game Provider is a human, an organization, or a collection of humans
and/or organizations that own a game application, or have the right to
use and publish a game application (e.g. Tetris, Quake, Age Of Empires).
The Game Provider publishes and distributes games via the Gaming Ser-
vice.
• Community Service consists of different services that enable the players to
communicate. Examples for Community Services are: Instant/Voice/Mul-
timedia Messaging, Chat or Conferencing.
• Game Information Service contains functionalities for the management of
game related information.
The 3GPP IP Multimedia Subsystem (IMS) is a standardized infrastructure,
able to run services of all categories while allowing ease of inter-working be-
tween (mobile) operators. The IMS is not part of R’99 but the so-called Phase1
IMS is specified in 3GPP Release 5 and contains the basic mechanisms for mul-
timedia session management. The 3GPP Release 6 adds many new capabilities
to the system and the IMS. Examples are: Presence, Conferencing, Messaging,
WLAN-Interworking, and Group Management.
The IP Multimedia Subsystem (IMS) is an extension of the 3GPP packet-switch-
ed core network. It uses SIP to setup, maintain and terminate voice and multi-
media sessions. The IMS network architecture is specified in [41]
The IMS network architecture is composed by the following elements. The
Call Session Control Function (CSCF) in IMS is needed for session manage-
ment and support for QoS provisioning in the core network. The CSCF can
act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF
(I-CSCF). The P-CSCF is the first contact point for the UE (User Equipment =
terminal) within the IMS; the S-CSCF actually handles the session states in the
network; the I-CSCF is mainly the contact point within an operator’s network
for all IMS connections destined to a subscriber of that network operator, or
a roaming subscriber currently located within that network operator’s service
area.
The Home Subscriber Server (HSS) is the master database for a given user. It is
58 CHAPTER 4. 3G NETWORK GAMING
Figure 4.2: Game Service over the IMS
the entity containing the subscription-related information to support the net-
work entities actually handling calls/sessions. The HSS also generates User Se-
curity information for mutual authentication, communication integrity check
and ciphering.
The Game Platform proposed for game services over the IMS ”sits” be-
tween the games and the 3G network (Fig. 4.2). It allows using the IMS ca-
pabilities (e.g. presence, messaging, QoS), but also may offer additional func-
tionalities that every game needs (e.g. player and game management). The
platform API is used on both client and server side of the game, but with differ-
ent functionality. For example, when a game server does Create Application, a
new game session is created. On the client side Create Application either lets
a player join a game session or create a new one.
The game application is not part of the Gaming Platform. Usually the game
application consists of two sides: client and server. They are located on top
of the game platform using the Gaming Platform functionalities via the OMA
Game Services API. The game server makes sure that the actual game data
flows are available to the player on the client side in the game. The Game
Server and the Game Focus communicate with each other to setup a new game
session and to add or remove a player from a game session. Each Game Server
4.2. IMS AND GAMING SERVICE 59
is associated at least with one game session. A Game Server may be capable
to provide more than one game session. A Game Server can initiate a request
towards the Game Focus to a setup game session and to be associated with it,
or the Game Focus can initiate a request to some pre-configured Game Server
to start and associate a game server with a game session.
The Game Client(s) may learn about games and game session by using game
presence information. A Game Client manages its participation in game ses-
sions via the Game Focus using the SIP protocol.
The central component of Gaming Service architecture is the Game Focus.
The Focus maintains a SIP signaling relationship with each player in the game.
The Focus has access to the game policy (composed of membership policy, mes-
saging policy and game presence policy, proxy policy), an instance of which
exists for each game. The game policy can be thought of as a database that
contains policy information about how the focus should operate and may also
contain player authorization information. It is the responsibility of the focus to
enforce those policies.
The game Focus may function as a proxy and forward a received SIP-Request
to another Game Focus. This may occur according to the game server state,
game client capabilities and/or the user location, which may be retrieved throu-
gh a query to the HSS by the Game Focus.
A game Focus may provide proxy functionalities for access to IMS Messag-
ing capabilities that are supported in a game. A user who wishes to access to
those services initiates a SIP request with an indicator for the messaging ser-
vice targeted to the game Focus. The Game Focus will enforce the messaging
and proxy policy installed for that user and forwards the request accordingly.
Similarly, the Game Focus may provide proxy functionalities for access to game
presence information. Game presence information may be provided by the
IMS Presence services. Whenever there is a need to inter-work with the IMS
Presence Service for game and player related presence information, the focus
takes the role of the so-called presence user agent.
The proxy function of the Game Focus will be used in the following situa-
tions:
• Forwarding SIP-requests for joining a game to another game Focus, e.g.
60 CHAPTER 4. 3G NETWORK GAMING
depending on user location, game client capabilities, or other game per-
formance considerations;
• Forwarding SIP-requests for joining an IMS Messaging Service to the IMS
Messaging Service, e.g. in case the Messaging Service supported in the
game must be joined through the game Focus;
• Forwarding SIP-SUBSCRIBE requests to the IMS Presence Service, e.g. in
case a subscription for game presence information must be done through
the Game Service.
4.3 Performance Enhancing Proxy for Interactive 3G
Network Gaming
Until some years ago, most games were stand-alone applications designed for
only a single player. This has changed lately, where many games are directed
towards a multi-player scenario where people can interact and compete. Re-
cently, most of these networked multiplayer games are developed for PCs con-
nected to fixed networks. Especially in the early days games had to cope with
severe bandwidth limitations, e.g. due to narrowband modem links. Nowa-
days, many computers have access to broadband services (e.g. via ADSL).
Multiplayer games can be distinguished by their flexibility with regard to
location and network connectivity. In online multiplayer computer games and
console games the players are usually connected via a fixed line network and
thus quite restricted for choosing their location. Players on mobile handheld
devices are more flexible: they may play in different locations and/or net-
works, and they may even move while playing. Currently, game develop-
ers, providers and players get more and more interested in games that can
be played everywhere. Thus, games must be available on mobile devices.
For the recent explosive development on the wired Internet there was the
application of an important class of networks, such as network gaming that
have long been projected to deliver an efficient service in wired networks. Un-
like non-time-critical applications like e-mail and file transfer, network games
demand timely data delivery to maintain the seemingly interactive presence
4.3. PERFORMANCE ENHANCING PROXY FOR INTERACTIVE 3G NETWORKGAMING 61
of players in the virtual game world. Yet the inherently large transmission de-
lay mean and variance of 3G cellular links make on-time game data delivery
difficult. Further complicating the timely game data delivery problem is the
frequent packet drops at these links due to inter-symbol interference, fading
and shadowing at the physical layer. For this reason, 3G wireless networks,
combat wireless link failures at the MAC and physical layer with an elaborate
system of channel coding, retransmission, modulation and spreading. In this
way there will be a huge reduction of the packet loss rate but the detrimental
side-effect to network gaming is the large and often unpredictable transmis-
sion delay mean and variance[42]. A possible solution is the utilization of a
performance enhancing proxy that optimize a new time-critical data, where
the utility of a datum is inversely proportional to the time required to deliver
it.
In fact, 3G network packet losses can indeed be successfully overcome by
using ample link layer retransmissions, but the detrimental side-effect is that
the resulting large RTT mean and variance may severely affect performance
of a TCP-like congestion avoidance rate control that is based on end-to-end
observable statistics of RTT. The limiting rate constraint and undesirable fluc-
tuations can be alleviated using a proxy with split-connection.
To improve the timely delivery of network game data in 3G wireless net-
works it is possible to use a performance enhancing proxy (PEP) called (W)ire-
less (I)nteractive (N)etwork (G)aming Proxy (WING) [43] (see Fig.4.3). WING
is located inside IMS (IP Multimedia Subsystem, it’s a new 3G network el-
ement) as an application service on top of the myriad of services that IMS
already provides. The Session Initiation Protocol (SIP-based IMS) provides
a multitude of multimedia services: from establishing connections from the
legacy telephone networks to the new IP core network using Voice over IP
(VoIP), to delivering streaming services such as video as a value-added service
to mobile users (UE). Strategically located as a pseudogateway to the private
and heavily provisioned 3G networks, it is foreseeable that IMS will continue
to enlarge and enrich its set of multimedia services in future wireless networks.
In a nutshell, WING improves the delivery of game data from the game
server to 3G wireless game layers using the following three techniques.
62 CHAPTER 4. 3G NETWORK GAMING
Figure 4.3: WING in 3G Wireless Network
1. By virtue of locating at the intersection of the private wireless network
and the open Internet, connection from the game server to the wireless
game player can be strategically split; for the server-WING connection,
only the statistically stable and fast round-trip time (RTT) and low wired-
network-only packet loss rate (PLR) are used for congestion control, re-
sulting in a steady yet TCP-friendly server-WING connection.
2. Second, by configuring parameters in the radio link layer (RLC) specif-
ically for gaming during session setup, excessive RLC retransmissions
are avoided, and timeliness of game data is improved at the controlled
expense of increased packet losses.
3. By constructing small but error-resilient packets that contain location da-
ta, packets can be transmitted in fewer MAC-layer protocol data units
(PDU) and hence further reduces delay.
Recently, efforts on proxy design have shifted to delay-sensitive multime-
dia transport, and an early work on gaming protocol is [44], which defined a
Game Transport Protocol (GTP) for massive multi-player on-line games (MM-
POGs) over the Internet. This work is: Game transport protocol: A reliable light-
weight transport protocol for massively multiplayer on-line games (MMPOGs).
It is possible to use another strategy because the gaming proxy WING dif-
fers in the following respects:
i) is designed WING specifically for lossy, bandwidth-limited networks,
4.3. PERFORMANCE ENHANCING PROXY FOR INTERACTIVE 3G NETWORKGAMING 63
hence focusing on design of network-optimized differential coding to
produce small but loss-resilient packets;
ii) is tailored WING for HSDPA of 3G wireless networks, optimizing perfor-
mance by intelligently configuring parameters of the RLC layer.
This approach is proxy-based, such that it can achieve a gaming optimization
exclusively for 3G networks.
HSDPA of UMTS Release 5, improves upon Release 4 with numerous low-
er-layer optimizations. It is important to note that the RLC-layer buffers upper
layer service data units (SDU) on a per-session basic, IP packets in this case, and
segments each SDU into smaller protocol data units (PDU) and await transmis-
sion at lower layers. RLC can discard SDUs using a method of retransmission-
based discard (RBD), an SDU can be discarded before successful transmission.
In a nutshell, an SDU is discarded if a predefined maximum number of retrans-
missions B has been reached before successful transmission of a PDU belong-
ing to the SDU.
An approach of prediction used at a network game client to predict locations
of other game players in the virtual game world entails the need of defining a
new type of transport data called variable deadline data.
The usefulness (utility) of a game datum is inversely proportional to the
time it requires to deliver it. This relationship between utility and transmission
delay is the behavioral result of a commonly used game view reconstruction
procedure at a game client called dead-reckoning[45].
The three optimizations of gaming proxy WING [43] in details are: 1)Proxy-
based congestion control, 2)Optimizing RLC configuration, 3)Loss-optimized
Differential coding.
1) Traditional congestion control algorithms like TCP-friendly Rate Con-
trol (TFRC) space outgoing packets with interval Tcc as a function of estimated
packet loss rate (PLR), RTT mean and RTT variance due to wired network con-
gestion. Split connection offers the possibility to avoid unnecessary rate re-
duction due to erroneous perception of wireless losses as network congestion
by completely shielding sender from packet losses due to wireless link failures.
Moreover, by performing TFRC in the server-WING connection using only sta-
ble wired network statistics, split connection shields the server-WING connec-
64 CHAPTER 4. 3G NETWORK GAMING
tion from large rate fluctuations due to large RTT variance in the last-hop 3G
link as shown in. For this reason, indeed proxy-based split-connection conges-
tion control performs better than end-to-end counterparts, even in negligible
wireless loss environments.
2) Given utility-delay function u(d) it is necessary to optimize configuration
of RLC to maximize utility. More precisely, the value of maximum retransmis-
sion limit B is considered, inducing expected SDU loss rate l∗ and delay d∗,
so that the expected utility (1−l∗)u(d∗) is maximized. If SSDU is the average
SDU size, and εPDU is the PDU loss rate, it is possible to calculate the proba-
bility density function (pdf) of PDU transmission delay Φ(φ) which is assumed
to have mean mφ and variance σ2φ. First, the expected number of PDUs frag-
mented from an SDU is N = d SSDU
SP DUe. For a given B, the expected SDU loss rate
lSDU can be written simply:
PPDU =B∑
i=1
εi−1PDU (1− εPDU )
lSDU = 1− PNPDU
where PPDU is the probability that a PDU is successfully delivered given B.
The delay dSDU experienced by a successfully delivered SDU is the sum of
queuing delay dqSDU and transmission delay dt
SDU . Queuing delay dqSDU is the
delay experienced by an SDU while waiting for head-of-queue SDUs to clear
due to early termination or delivery success. dtSDU is the expected wireless
medium transmission delay given the SDU is successfully delivered. dtSDU is
easier and can be calculated [43] as:
XPDU =1
PPDU
B∑
i=1
iεi−1PDU (1− εPDU )
dtSDU = NmφXPDU
where XPDU is the expected number of PDU (re)transmissions given PDU de-
livery success. To calculated dqSDU , a M/G/1 is assumed (even if the arrivals of
game data are more likely to be deterministic than Markovian, so the system
is actually more similar to a D/G/1) queue with arrival rate λq ,mean service
time mq , and variance of service time σ2q . The dq
SDU can be calculated [43] as:
dqSDU =
λqmq(1 + σ2q
m2q)
2(1− λqmq)mq
4.3. PERFORMANCE ENHANCING PROXY FOR INTERACTIVE 3G NETWORKGAMING 65
In the application, λq is the rate at which game data arrive at WING from the
server, which is assumed to be known. mq is the mean service rate for both
cases of SDU delivery success and failure and can be derived as follows:
YSDU =1
lSDU
N∑
i=1
(B + (i− 1)XPDU )εBPDUP i−1
PDU
mq = (1− lSDU )dtSDU + lSDUmqYSDU
where YSDU is the expected total number of PDU (re)transmissions in an SDU
given SDU delivery failure. Similar analysis will show that the variance of
service rate σ2q for our application is:
σ2q = (1− lSDU )N2X2
PDUσ2φ + lSDUY 2
SDUσ2φ
We can now evaluate expected queuing delay dqSDU , from which we evaluate
expected delay dSDU . Optimal B is one that maximizes:
(1− l∗SDU )u(d∗SDU )
3) If the location data, player position updates sent to improve dead-reck-
oning, are in absolute values, then the size of the packet containing the data can
be large, resulting in large delay due to many PDU fragmentation and spread-
ing. The alternative is to describe the location in relative terms-the difference in
the location from a previous time slot. Differential values are smaller, resulting
in fewer encoded bits and smaller packets, and hence smaller transmission de-
lay. This differential coding of location data is used today in networked games.
The obvious disadvantage of differential coding is that the created dependency
chain is vulnerable to network loss; a single loss can result in error propaga-
tion until the next absolute location data (refresh)is sent. To lessen the error
propagation effect while maintaining the coding benefit of differential coding,
one can reference a position in an earlier time slot. For an example we can
see Fig. 4.4, where that position 3 (ξ)3 references ξ1 instead of ξ2. This way,
loss of packet containing ξ2 will not affect (ξ3), which depends only on ξ1. The
problem is then: for a new position ξt, so how to select reference position ξt−r
for differential coding such that the right tradeoff of error resilience and packet
size can be selected? One solution for this problem is that the selection must
66 CHAPTER 4. 3G NETWORK GAMING
Figure 4.4: Example of Differential Coding
be done in an on-line manner as new position becomes available from the ap-
plication to avoid additional delay.
To implement loss-optimized differential coding, a coding specification that
dictates how the receiver should decode location packets has to be specified.
Each coding modes is specified by a designated bit sequence (mode marker) in
the packet. For given position ξt = (xt, yt) and reference ξt−r = (xt−r, yt−r),
some modes may be infeasible due to the fixed coding bit budgets for refer-
ence and coordinate sizes. So limited to the set of feasible modes, we seek a
(reference position/mode) pair that maximizes an objective function. For an
IP packet of size st containing position ξt that is sent at time t, first define the
probability that it is correctly delivered by time τ as αt(τ). Next define the
probability that position ξt is correctly decoded by time τ as Pt(τ).
Now, given utility function u(d) (where the utility of a datum is inversely
proportional to the time required to deliver it and u(d) is the relationship be-
tween utility and transmission delay) and decode probability, the optional (ref-
erence position/mode) pair is one that maximizes the following objective func-
tion:
maxPt(t + d(st))u(d(st))
After, we want to introduce the IP Multimedia Subsystem and define the
principal characteristics of Gaming applications.
4.4. GAME TRANSPORT PROTOCOL (GTP) 67
Figure 4.5: Structure of the GTP packet header
4.4 Game Transport Protocol (GTP)
Since GTP needs to provide reliable transmission, its header structure is simi-
lar to that of TCP. However, several fields are modified to support the unique
characteristics of GTP (see Fig. 4.5 ).
Detailed descriptions for each field are as follows.
• Source port & Destination port: They contain the GTP port numbers
that identify the application programs at each end of the GTP connection.
They perform the same functions as the source and destination ports in
TCP.
• Sequence number & Acknowledgment number: In TCP, the SEQUENCE
NUMBER field is used to identify the position of the data in the packet
in the sender’s byte stream. However, GTP uses the packet-based win-
dow scheme and not the byte-based window scheme. Therefore, in GTP,
this field identifies the position in the sender’s packet stream. The AC-
KNOWLEDGMENT NUMBER field identifies the number of the packet
that the source expects to receive next.
• HLEN: This field contains an integer that specifies the length of the packet
header measured in multiples of 32-bits. It is needed because the OP-
TIONS field varies in length, depending on which options have been in-
cluded. Thus, the size of the GTP header varies according to the options
68 CHAPTER 4. 3G NETWORK GAMING
selected.
• Mode: The characteristics of game traffic in MMPOGs vary according to
the categorization and contents of the games. Therefore, it is necessary
to provide diverse flow control options within the application layer. By
offering multiple options, applications can selectively choose a suitable
flow control mechanism. The MODE field is therefore designed to sup-
port the multiple options available in the transport layer.
• Class: This field is used to separate GTP packets into several classes. This
classification information is used in the adaptive retransmission scheme
and the inter-working with DiffServ.
• Code bits: GTP uses the 4-bit field labeled CODE BITS to determine the
purpose and contents of the GTP packet.
• Window size: The WINDOW SIZE field advertises how much data a
GTP session is willing to accept, by specifying its buffer size every time a
packet is sent.
• Options: The OPTIONS field is defined to provide additional functions
in a GTP session. It is not currently used.
In MMPOGs, there are continuous interactions between game servers and
user clients. Therefore, connection-oriented data transmission should be sup-
ported in MMPOGs. For the purpose of establishing connections, GTP uses a
three-way handshake method that is similar to that used by TCP. To support
full-duplex communication, GTP uses only three frames instead of four pack-
ets.
Connection setup begins by the client setting a bit, known as the SYN bit,
within the GTP header, indicating a request for synchronization with the des-
tination GTP process. The receiving host’s GTP session must acknowledge the
receipt of this SYN request and send its own SYN request. The SYN request
should also contain the ACK bit. Namely, the packet has both the SYN and
ACK bits set. The SYN request must be acknowledged by the sending client.
By means of these message flows, a full-duplex connection is established.
4.4. GAME TRANSPORT PROTOCOL (GTP) 69
If the client does not need to maintain the established connection with the
server any longer, it can tear down the connection. The GTP session teardown
process utilizes the same three-way handshake method as was used for ses-
sion setup. It utilizes a three-frame exchange to close the session. The client
requesting session closure sets the FIN bit within the GTP header, indicating
that the request is to close the session; it then sends the FIN packet to the other
side. The recipient must in turn acknowledge receipt of the initial FIN packet
and send its own FIN packet, which is then acknowledged by the original host
requesting to close the session. At this point both sides release the allocated
resources and make them available for other processes.
Chapter 5
Simulations and results
To evaluate communication system performance, we choose ns-2 as simulator
environment. It already supported some wireless modules, but the functional-
ities provided by those modules are not sufficient to simulate a radio link with
UMTS HSDPA, therefore we utilize a contribution module EURANE of ns-2 to
implement HSDPA.
5.1 Simulator: Ns-2
Ns-2 is an event driven network simulator that is originally based on the REAL
network simulator developed by UC Berkeley, but it has been further devel-
oped in the VINT project [46]. It is an open source software, commonly used by
network researchers for evaluating and developing network related research.
Since it is an open source software and additions are encouraged, many other
network researchers have contributed to the development of the simulator.
The simulator is developed by two programming languages, OTcl and C++.
OTcl [47] is an object oriented version of the Tcl (Tool Command Language)
language [48], which is an interpreted scripting language. The OTcl part of the
simulator is mainly concerned with configuring the network prior to simula-
tion starts, and the C++ part mainly handles the packet processing within the
network when running a simulation. The scripting properties of OTcl lets de-
velopers quickly explore many network layouts, while the compiled C++ code
effectively executes the large amounts of data processing required by packet
71
72 CHAPTER 5. SIMULATIONS AND RESULTS
handling during simulations.
A simulating environment in ns-2 consists of network elements that simu-
late the behaviour of a network, and network connections that generates the
data traffic used in the simulation. The network elements in ns-2 mainly con-
sist of nodes and links between the nodes. At a higher detail level, each link
and node consists of several internal elements to implement the behaviour of
the node . Nodes acts as routers and traffic generation points, and links acts as
transfer element between the nodes.
A connection in ns-2 consists of a traffic generator, a traffic sink and a trans-
port agent. All these components can be configured into a node by simple
OTcl procedure calls. A traffic generator produces traffic in form of request to
transport agents to send a certain amount of data. The transport agent then
generates packets to transport the data to the receiver and inserts them in the
network which propagates the packets to the receiver. When the packets arrive
at the destination node, they are delivered to the other end of the transport
agent, which announces the arrival of the data to the traffic sink. This is the
way in which most data is propagated through a ns-2 network, although some
protocols and networking scenarios allow different ways of data transport.
Ns-2 is an event driven simulator where each event is executed at a precise
moment in simulated time. Events are processed synchronously and no events
are executed concurrently. An event may be a packet arrival at a component
input point or other scheduled activities that performs controlling actions in
the simulator.
The simulator consists of a large collection of network elements that have
been developed to suit a large number of different scenarios. The components
can be described from two different views, the conceptual view and the im-
plementation view. The conceptual view is mostly used when describing net-
work scenarios, and the implementation view is used when implementing new
components and by the simulator during simulations. In the conceptual view,
overall behaviour of components are considered and not the implementation
details. The conceptual components consists of the nodes and links in a sce-
nario as well as connection agents. The simulator’s conceptual view is mostly
implemented in OTcl, with an interface to C++ where required. Nodes and
5.1. SIMULATOR: NS-2 73
links are viewed as single components with input lines and output lines and
some internal properties that provide the behaviour of the components. In
the implementation view, the conceptual objects are broken down into their
internal building blocks, where all actual object connections are implemented
through associations between objects. An example of this is a link, which in
conceptual view is a single component connecting two nodes to each other
and have internal bandwidth and delay properties.
Node: this is a main point of routing and start and end points for connec-
tions in ns-2. A node consists of several interconnected objects to create the
functionality of a network node. In the node there is the possibility to install
a hierarchical routing module. This is an addition that allows ns-2 to run with
a different node addressing scheme compared to the standard one, which uses
another routing module. Hierarchical routing is required by certain network
scenarios. The routing module in turn consists of other components that pro-
duce its routing behaviour. The main difference between a node with the hier-
archical routing and a normal node is the way in which the routing classifiers
are organized, since they have different address routing modules.
Link: is another essential object to establish a network scenario for simula-
tion. In ns a link object represents a single direction, simplex link. To create a
duplex-link for simulation, two simplex links in both direction.
An Agent in a node can be either an active or a reactive component during
network implementation. Links and nodes are reactive components that re-
act to incoming packets and apply their behaviors to the packet. Compared to
them, agents can be an active component. For instance, when transport agents
TCP and UDP react to external orders for sending data, they may generate nec-
essary packets for data transmission or generate connection control packets. In
the case of transport agents, they require external components to generate data
to send.
To analyze results of simulations, the traffic must be traced during the process.
When a link is traced, the trace objects (EnqT, DeqT, DrpT and RecvT) are in-
serted within the link objects. For every packet that passes a trace object, infor-
mation about the packet is written to the specified trace file.
74 CHAPTER 5. SIMULATIONS AND RESULTS
5.2 EURANE
Although ns-2 doesn’t provide appropriate modules for UTRAN/UMTS, some
contributed work was developed such as Pablo Martin and Paula Ballester’s
contributed modules, Alfredo Todini and Francesco Vacirca’s UMTS module
for ns and EURANE [49]. Within those modules EURANE is the only one
which provides the support of HS-DSCH.
The simulator EURANE (Enhanced UMTS Radio Access Network Exten-
sions for ns-2) is one of the main of SEACORN [50] (Simulation of Enhanced
UMTS Access and Core Networks), which investigates enhancements to UMTS
for RAN and Core Network through simulation. EURANE is an end to end
extension which adds three extra radio link nodes to ns-2, the Radio Network
Controller (RNC), Base station (BS) and the User Equipment (UE). These nodes
support four kinds of transport channels, include common channels FACH and
RACH, dedicated Channel DCH, and high speed channel HS-DSCH. In EU-
RANE, R99 channels, i.e. DCH, RACH and FACH, use standard error model
provided by ns-2, for HS-DSCH, a pre-computed input power trace file and a
block error rate (BLER) performance curve are introduced to generate the error
model of high-speed channel.
The Node RNC, BS and UE are all implemented from new object class,
namely UMTSNode class. Based on different configurations, different kinds
of classifiers and link objects are used to compose different nodes. The most
important parameter should be determined first is the node type, after that,
other peculiarity of this node type can be configured further.
Each UMTS node has zero or more UMTS network interfaces (NIF) stacks,
composed of objects representing different layers in the stack, the major com-
ponents being RLC, MAC and physical layer objects. Channels are connected
to the physical layer object in the stack. NIFs are also important for packet
tracing since the common methods in ns-2 can not trace the traffic within radio
links.
Typically, NIF stacks at the UE will have all of these objects but those at the
BS will only have MAC layer and physical/channel layer objects. At the RNC,
each NIF stack will only be composed of one RLC layer object.
5.3. OBJECTIVE AND SIMULATION SCENARIO 75
The main functionality additions to ns-2 come in the form of the RLC Ac-
knowledged Mode (AM) and Unacknowledged Mode (UM), which is imple-
mented at RNC and UE. The RLC entity AM-hs is developed to support HS-
DSCH. Unacknowledged mode is also supported for HS-DSCH by the subsets
of AM-hs, namely UM-hs.
After, there are also, a new MAC architecture to support high speed chan-
nel. So, the more complicated MAC-hs is used for the HS-DSCH. The trans-
mission of the MAC-hs PDUs to their respective UEs is achieved through the
use of the parallel Stop-and-Wait (SAW) HARQ processes. The implemented
HARQ algorithm uses Chase-Combining, which utilises retransmissions to ob-
tain a higher likelihood of packet acknowledgement.
Scheduling plays an important role in HSDPA, and is defined on MAC-hs
entity in EURANE. At every TTI the MAC-hs checks the status of the flow/pri-
ority buffers, and depending on the scheduling algorithm, determines which
packets (and the amount) will be used to construct a MAC-hs PDU for trans-
mission.
EURANE work with three kind of scheduling algorithm: Round Robin, Maxi-
mum C/I and Fair Channel-Dependent Scheduling (FCDS).
EURANE, to define the physical layer, uses a standard ns-2 channel ob-
ject to connect the BS and UE. This is combined with the attachment of an
error model. The transmission error model implemented for HSDPA is the
pre-processed out of ns-2 and consists of two parts. One is a physical layer
simulator to generate a BLER performance curve, the other is an input trace
file of received powers and CQI generated from Matlab scripts.
5.3 Objective and simulation scenario
The aim of this thesis is to design, analyze and simulate a proxy-based solu-
tion, called Radio Network Feedback (RNF), to improve the performance of
TCP over HSDPA and 3G Networks. It improves the resource utilization and
maximize the transmission rates while maintaining the shortest response time
76 CHAPTER 5. SIMULATIONS AND RESULTS
possible, by taking advantage of feedback information provided by the net-
work itself. The main idea is to split the connection between a server and a
mobile user through the introduction of a proxy, which terminates both con-
nections and is capable of adapting its parameters to get the best out of the
available resources. The proxy takes advantage of the fact that most of the
information that a TCP sender needs to infer in order to perform congestion
control, is already known by the radio network. In that case, it can be transmit-
ted to the proxy in order to feed its adaptation algorithm, as is the case of the
bandwidth available for a determined connection, or the network load.
It should add on the performance improvements brought by HSDPA, which
provides broadband support for downlink packet-based traffic. It should also
overcome the problems that TCP connections face over wireless links.
In a typical scenario, such as the simulation scenario, a mobile terminal at-
tempts to establish a connection to one of the remote servers. The initial TCP
connection establishment packet (SYN) is received by the proxy, which returns
the corresponding reply (SYNACK), and the terminal-proxy connection is com-
pleted. It also establishes a connection to the specified server, and forwards the
initial file request sent by the client. The result is that two different TCP con-
nections are established. Upon receipt of the request, a remote server begins
to send the file following the traditional TCP algorithms, including Flow and
Congestion Control. All the transferred data is received by the proxy, where it
is buffered in order to be sent to the mobile terminal as soon as possible. Note
that, while the remote server modifies its TCP parameters according to its own
TCP implementation, the proxy receives every packet at the highest rate possi-
ble and buffers it. Then, it can use whatever TCP parameters it needs in order
to adapt the connection to the variable wireless conditions. This way, the TCP
connection to the remote server does not suffer the effects of the wireless link,
and the connection to the mobile terminal is tailored to the current link charac-
teristics. At the same time, it is totally transparent to both endpoints.
5.4. DESIGN DECISIONS 77
5.4 Design Decisions
HSDPA is a system with the integration of voice and data services. The base
station (Node B) will contain a set of different transport channels, e.g. common
channel (FACH and RACH) for voice services, dedicated channel (DCH) and
HS-DSCH simultaneously. Besides the power provided to common channels
and DCH channels, the remainder can be entirely allocated to HS-DSCH, thus
to keep the maximum efficiency of utilization to the power of base station. In
this case, the available power of HS-DSCH is not a constant value and varies
on the base of the quantity and channel conditions of other channels within
base station. In EURANE, the input power trace files are pre-computed from
Matlab scripts, to generate the Channel Quality Indicator.
Results of the ns2 link-level simulator are used in the network-level simu-
lator by means of input trace files containing SNR levels fluctuating in time.
In order to test performance of HSDPA network and the proxy setup we
performed several simulations. Specifically, we considered a scenario where
there is a FTP downloading. Most of them aim to compare the proxy to the
TCP protocol (TCP Reno was chosen, as the reference version and it is the most
used version today), while others check the performance of the proxy with
other protocols implemented in the base station to improve TCP performance,
that is Snoop and Eifel. The picture: Fig.5.1 describe the simulation scenario.
ProxyRNC Base Station ServerTerminal
TCP TCP
Figure 5.1: Architectural RNFProxy scenario
The simulations can be classified in two main groups, each of them with
different aims. One group is focused on comparing proxy-solution to that of
TCP Reno. The second group is oriented to test performance of both the proxy
setup and a common TCP sender, with the introduction of the other protocols.
The simulations setup follows the scheme shown in previous sections, where
78 CHAPTER 5. SIMULATIONS AND RESULTS
two separated TCP connections are established, one between the terminal and
the proxy, and the other between the proxy and a remote server. The results
are compared to those of a basic setup, where there is only a TCP connection
from server to terminal, via the RNC.
The addressed scenario includes a HSDPA UMTS radio cell covered by a
Node-B connect to a RNC. The simulation model consists of a terminal (UE1)
that is the reference terminal, and other nine terminal (UE2-UE10) that are
”competitor terminals”. These terminals are all connected to a HS-DSCH (the
users are all HS-DSCH user). Reference terminal and competitor terminals are
placed in different distances away from the node B in a Rayleigh fading envi-
ronment. The simulation model is based on the HSDPA architecture such as
indicated in the 3GPP specification, and after we have introduced the proxy
entity between remote server and terminal.
The wired part of the simulation model consists of a Node B, a RNC, a
SGSN, a GGSN, a fixed external node and finally the proxy. The characteristics
of connection lines between them are shown in Tables 5.1 and 5.2. Furthermore,
over these tables we can see that the average delay at the wired part of the
network model is 76 msec.
From To Bandwidth Av. Delay
Server GGSN 10Mbit 50ms
GGSN SGSN 622Mbit 10ms
SGSN RNC 622Mbit 0.4ms
RNC Node B 622Mbit 15ms
Average total delay through the wired part of the model: 76ms
Table 5.1: Connection lines between Nodes, without proxy
The parameters of HS-DSCH, in all the scenarios, are configured as follow-
ing:
• Environment: Pedestrian A
• Velocity of UE: 3km/h
• Distance between Node B and the UE: 450m
5.4. DESIGN DECISIONS 79
From To Bandwidth Av. Delay
Server GGSN 10Mbit 50ms
GGSN SGSN 622Mbit 10ms
SGSN Proxy 622Mbit 0.3ms
Proxy RNC 622Mbit 0.1ms
RNC Node B 622Mbit 15ms
Average total delay through the wired part of the model: 76ms
Table 5.2: Connection lines between Nodes, with proxy
• Correlation in Shadow Fading: 40m
• Number of users: 10
In general, the UMTS network is assumed to be properly dimensioned to
handle all the traffic, as well as the link to the Internet. In such case, the limiting
link will always be the wireless one, with lower (and variable) bandwidth.
The link delays are set according to the tables, and the processing delay in
the terminal is initially set to 40 ms, but the processing delays in intermediate
elements such as the RNC are not considered to be significant. The condition
of wireless links varies over time, with bandwidths in the range 2.4-7.2 Mb/s
according to the predetermined allowable MCS sets, and a propagation delay
which includes processing delay at the base station (BS) and receivers.
RNC Base Station ServerTerminal
TCP
Figure 5.2: Architectural TCP Reno scenario
80 CHAPTER 5. SIMULATIONS AND RESULTS
ProxyRNC Base Station ServerTerminal
TCP TCP
Figure 5.3: Architectural RNFProxy scenario
5.5 Experimental results
This section is dedicated to describing the results in terms of performance of
TCP over HSDPA air interface. The performance parameters of primary in-
terest is throughput over wireless link, but there are also other important para-
meters such as end-to-end packet delay, the congestion windows of sender and
proxy and so on. Network Simulator Version 2 (ns-2.30) was used to perform
the simulations.
5.5.1 Scheduler behaviour
First of all we simulated several HSDPA communications to check the enhance-
ments its features promise.
For the HS-DSCH a fast link adaptation is applied. This involves a selection
of the modulation and coding scheme. A bad channel condition does not re-
sult in a higher transmission power, but instead prescribes another coding and
modulation scheme. The focus of HSDPA is best effort traffic, so, mainly users
in favorable channel conditions can benefit from the higher data rate achiev-
able through the use of HS-DSCH. We analyze the results of throughput to
evaluate the effects of such mechanisms.
A real communication system must support all traffic classes, which re-
quires a consideration on resource management algorithm. The interesting
part of the simulations is how the variation of scheduling will influence the
communication system. The simulations are presented from an FTP file down-
load using TCP. In our simulations we use ”continuous data” scenario to in-
dicate the TCP traffic. We select this basic traffic model to simulate the real
system.
5.5. EXPERIMENTAL RESULTS 81
According to HS-DSCH used in TCP traffic, several parameters can impact
the transport capacity. For instance, one of them is the buffer size at MAC-hs in
BS, that can also influence the throughput as we choose one of schedulers. The
other one is the user number, which also influences capabilities of schedulers.
We consider a scenario with 20 terminals, and we evaluated the through-
put of two schedulers (Round Robin and Max C/I). Throughput of reference
terminal with two scheduler is presented in Figure 5.4.
Round Robin
Max C/I
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
0.0 5.0 10.0 15.0
Figure 5.4: Comparison between scheduler algorithms
X-axis shows the duration of the simulation while Y-axis presents the through-
put for each scheduler. It is evident that the two schedulers provide almost
equal throughput, but some time Max C/I performs better than the other. For
user with most favorable long-term channel quality, Max C/I can offer the
most rapid data transmission, and hence the throughput of this user should be
higher than the others. However, the user with less favorable long-term chan-
nel quality may not get the desirable throughput. FCDS scheduler combines
MaxC/I and RR together, even if it can not offer the throughput to user in best
channel condition as much as Max C/I does, it can provide more throughput
than Max C/I for the other users.
RR does not offer the best throughput since it considers all users with the
82 CHAPTER 5. SIMULATIONS AND RESULTS
same policy. That will take off the priority to use the high speed channel from
the user with favorable long-term channel quality. Therefore the throughput it
offered is always lower than the other one can provide.
For these reasons, in the next simulations we prefer to work with the third
kind of scheduler, that is FCDS, so a trade-off between the two extreme meth-
ods of scheduling can be achieved.
5.5.2 Proxy Performance
In the following set of simulations, we evaluate the improvements that the
proxy-solution introduces in the HSDPA and 3G networks compared to the
TCP Reno solution.
In order to model the proxy behaviour, as well as the intermediate elements,
several C++ modules were added to EURANE. A new TCP sink was devel-
oped in order to model a UMTS terminal with variable processing delay. This
includes an application which is in charge of forwarding packets between the
two TCP connections, as well as a TCP Reno Agent for the server-proxy con-
nection, and a RNFProxy Agent for the TCP connection towards the terminals.
The application simply forwards packets in both directions. The RNFProxy
Agent is the modified TCP Agent in charge of adapting the parameters of the
TCP connection between terminals and proxy, and include most of the proxy
functionality.
First of all, we have to evaluate the maximum data rate for the reference
user within the HSDPA network during the simulation’s interval (see Figure
5.5). All the scenarios, and the simulations that we realized, are compared with
this maximum rate. Specifically, Fig.5.5 shows the maximum data rate that the
reference user can theoretically experience from the base station toward the
UE. Such data rate is the link bandwidth.
Figures 5.6 and 5.7 show the results for two different setups. Here, we can
compare performance of the proxy to performance of TCP Reno.
In both cases, a TCP connection is established in order to download a 32Mb
file, which should be big enough to test the proxy behavior versus TCP’s Slow
Start phase. In both figures 5.6 and 5.7, the transmission rate is plotted as a
function of time, for the proxy setup (which adapts its initial window to the
5.5. EXPERIMENTAL RESULTS 83
Link Bandwidth
0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
0.0 5.0 10.0 15.0
Time (s)
Rate (Mbits/s)
Figure 5.5: Link Bandwidth
0.0 5.0 10.0 15.0
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
Figure 5.6: Throughput Reno scenario
84 CHAPTER 5. SIMULATIONS AND RESULTS
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
0.0 5.0 10.0 15.0
Figure 5.7: Throughput Proxy solution
0.0 5.0 10.0 15.0
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
Reno + Proxy
Link bandwidth
Reno
Figure 5.8: Reno vs. Proxy
5.5. EXPERIMENTAL RESULTS 85
current link bandwidth), as well as TCP Reno. The plots shows the proxy’s
throughput and the TCP-Reno’s throughput compared to the link-bandwidth.
The figures show a significant improvement of performance when the proxy is
used, compared to TCP Reno. The reason is that a TCP sender does not have
information about the available bandwidth of the path, so it has to begin the
transmission with the lowest rate possible. By the contrary, the proxy can set
its initial value to fully utilize the bandwidth assigned to the connection, since
such a value is known. The improvement is even larger if TCP’s Slow Start
Threshold is set to a low value (such as 20) in the Reno senders. The reason
is that, in such a case, the TCP sender enters an early Congestion Avoidance
Phase, which reduces even more the increase of the transmission rate. To obtain
high values of throughput in the Reno scenario we set the TCP’s Slow Start
Threshold to 62. Figure 5.9 shows the congestion windows of the sender for
Reno scenario as obtained by simulation.
Cwnd
Packets
Time (s)0
5
10
15
20
25
30
35
40
45
50
55
60
65
0.0 5.0 10.0 15.0
Figure 5.9: Congestion Window of TCP Reno server for Reno scenario
In Fig.5.9, we can see that at the beginning of the connection the TCP sender
is trying to reach the maximum bandwidth available to the connection as fast
as possible (this is a slow start phase). When the value of congestion win-
dow reaches the threshold value (ssthresh=62), the Sender enters in Conges-
86 CHAPTER 5. SIMULATIONS AND RESULTS
tion Avoidance phase. The Sender remains in this phase until occurs a con-
gestion event. In this case, we have a duplicate acknowledgement, so Reno
TCP enters in the Fast retransmit and Fast recovery state. When the third du-
plicate ACK is received, the Reno TCP transmitter sets ssthresh to one half of
the current congestion window (cwnd) and retransmits the missing segment.
The cwnd is then set tossthresh plus three segments (one segment per each du-
plicate ACK that has already received). Then, cwnd can be increased by one
segment on reception of each duplicate ACK if it continues to arrive after fast-
retransmission. This allows the transmitter to send new data when cwnd is
increased beyond the value of the cwnd before the fast-retransmission. After
that, if arrive an ACK that acknowledges all outstanding data sent before the
duplicate ACKs then, the cwnd is set to ssthresh so that the transmitter slows
down the transmission rate and enters the linear increase phase. By the con-
trary in our scenario we have that ACK do not arrive, and at about 2,5 seconds
there is a timeout. In this way the cwnd is set to one and triggers again the
slow start phase.
In the proxy scenario, we have two congestion windows, one for the proxy
and another for the TCP sender. In the figure ?? we can see the congestion
windows for the proxy (on the left), and the congestion window of the Reno
Server, when the slow start threshold to the sender is set to 20. The TCP sender
enters an early Congestion Avoidance Phase, but now, this is not a problem,
because there is the proxy splitting the connection. The proxy set its congestion
window value to pipe capacity (product between bandwidth and delay) plus
the value of the queue on the RNC. The proxy receive RNFMessages every
time there is a bandwidth variation. These messages make the proxy compute
the cwnd value, and continue sending with a new transmission rate. In this
way the proxy can always transmit to the available maximum rate. Figure 5.11
shows the congestion window of Reno Server for Proxy scenario, but in the
same scenario there is also another congestion windows, that is the congestion
window od RNFProxy (see Fig.5.10)
Now, we want to test, the reliability of the proxy control algorithm with
respect to UDP packets losses. UDP packets loss or corruption in the link from
the RNC to the Proxy is possible. Therefore, retransmissions of RNFMessages
5.5. EXPERIMENTAL RESULTS 87
Cwnd
Packets
Time (s)0
5
10
15
20
25
30
35
0.0 5.0 10.0 15.0
Figure 5.10: Congestion Window of RNFProxy for Proxy scenario
Cwnd
Packets
Time (s)0
10
20
30
40
50
60
70
0.0 5.0 10.0 15.0
Figure 5.11: Congestion Window of TCP Reno Server for Proxy scenario
88 CHAPTER 5. SIMULATIONS AND RESULTS
have to be dealt with in some other way. For that reason, the RNC periodically
sends a new RNFMessage to the proxy, so if one message is lost the necessary
information will arrive within the next period. The figures 5.12 and 5.13 show
the results of the reliability test, where the setup is analogous to the previous
case. Now we have only simulated the situation where the RNFMessages do
not arrive to the proxy from the RNC, because during the simulation interval
all UDP packets are lost in the link. We can see that the RNF-proxy don’t work
very well, and in this situation we have an average value of the throughput
that is about 975Kbps, whereas if there were not UDP packets loss, there is a
average value of the throughput that is about 1111Kbps.
Note that this is an especially unfavorable case, and the probability of losing
and corruption of only one packet is very small, so our simulation scenario is
unrealistic, and the simulations only aims to test the algorithm reliability.
0.0 5.0 10.0 15.0
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200 Link bandwidth
Reno + simple proxy
Figure 5.12: Without send RNF messages
5.5.3 Snoop and Eifel implementation
The last group of simulations was done to test the enhancement TCP perfor-
mance thanks to the introduction of protocols to the base station to improve
the proxy-solution and to permit streaming services and timely data delivery
in HSDPA and 3G Networks.
5.5. EXPERIMENTAL RESULTS 89
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
0.0 5.0 10.0 15.0
Figure 5.13: Correct Proxy solution
Specifically, to evaluate TCP performance enhancements with the introduc-
tion of the functionalities of new protocols in base station, such as Snoop and
Eifel, simulations were performed. In order to model the Snoop and Eifel Pro-
tocols behavior, several C++ modules were added to the EURANE simulator.
In the first set of simulations, the main aspects we wanted to test is perfor-
mance of above mentioned TCP protocols in a common HSDPA network, with
TCP Reno Agent and without proxy between server and terminal. Figures 5.14
and 5.15 show the TCP improvements compared to the simple scenario with
only a TCP Reno Agent.
In both cases, a TCP connection is established in order to download a file
and the average throughput value is always higher than the simple TCP Reno
scenario. Indeed, now there are Snoop and Eifel protocol at the base station
that deal with Duplicate ACKs and timeouts.
The Snoop Agent monitors every packet that passes through the TCP con-
nection in both directions and maintains a cache of TCP segments sent across
the link that have not yet been acknowledged by the receiver. A packet loss is
detected by the arrival of a small number of duplicate acknowledgments from
the receiver or by a local timeout. The snoop agent retransmits the lost packet if
it has it cached and suppresses the duplicate acknowledgments. The TCP Eiffel
90 CHAPTER 5. SIMULATIONS AND RESULTS
0.0 5.0 10.0 15.0
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
Figure 5.14: Snoop Agent in TCP Reno scenario
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
0.0 5.0 10.0 15.0
Figure 5.15: Eifel Agent in TCP Reno scenario
5.5. EXPERIMENTAL RESULTS 91
was proposed to deal with retransmission ambiguity (spurious timeouts and
spurious fast retransmit cause the so called retransmission ambiguity). So, it
uses the timestamp option in the TCP header to assign a number to the trans-
mitted segment. The timestamp value, the current congestion-window-size,
and the slow-start threshold are stored by the sender. Once an ACK is received,
the sender compares the timestamp values of the ACK and the retransmitted
segment. If the ACK-timestamp value is less than that of retransmitted seg-
ment, the sender concludes that a spurious retransmission occurred. There-
fore, it resumes the transmission with new data and stores the congestion-
windows size and the slow-start threshold values before the spurious retrans-
mission. The main advantage is that it suppresses duplicate acknowledgments
and timeouts for TCP segments lost and retransmitted locally, thereby avoid-
ing unnecessary fast retransmissions and congestion control invocations by the
sender. In this way the Reno sender can transmit with higher rate and with less
congestion events.
In Figures 5.16 and 5.17 we want to compare performance of the proxy with
that of the Reno scenario and implementation of Snoop and Eifel. We obtain
that the average throughput is better in the RNFProxy solution than in the
Snoop and Eifel solution.
0.0 5.0 10.0 15.0
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
Reno + Proxy
Link bandwidth
Reno + Snoop
Figure 5.16: Comparison between Snoop and Proxy
92 CHAPTER 5. SIMULATIONS AND RESULTS
Reno + Proxy
0.0 5.0 10.0 15.0
Link bandwidth
Reno + Eifel
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
Figure 5.17: Comparison between Eifel and Proxy
When there is the proxy between remote server and terminal in the HSDPA
network and there is also Snoop or Eifel Agent to the base station, the situation
it is the same, these new Agents try to improve TCP performance suppressing
duplicate ACKs and timeouts for TCP segments lost over the wireless channel,
and retransmitting them locally at the node B. Figures 5.18 and 5.19 show the
throughput as a function of time, for the proxy-snoop setup and for the proxy-
eifel setup.
In this way, we realize a particular HSDPA network with the definition of
split solution of TCP (with RNFProxy) and with the implementation of two
new protocol at the base station. This permit to rapidly follow the variation of
the bandwidth (thanks to the proxy algorithm) and permit to suppress dupli-
cate acknowledgements and timeouts to avoid unnecessary retransmission by
the sender.
In our simulations, for different scenarios, we got the average throughput
reported in table 5.3:
We can see that the introduction of the proxy entity within the HSDPA ar-
chitecture improve the performance of the wireless network. After, thanks the
introduction of new TCP protocols the average value of throughput is more
and more high.
5.5. EXPERIMENTAL RESULTS 93
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
0.0 5.0 10.0 15.0
Figure 5.18: Proxy with Snoop Agent
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
0.0 5.0 10.0 15.0
Figure 5.19: Proxy with Eifel Agent
94 CHAPTER 5. SIMULATIONS AND RESULTS
Link bandwidth
Throughput
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
0.0 5.0 10.0 15.0
Figure 5.20: Definition both Snoop and Eifel in RNFProxy scenario
0.0 5.0 10.0 15.0
Rate (Mbits/s)
Time (s)0.000
0.200
0.400
0.600
0.800
1.000
1.200
1.400
1.600
1.800
2.000
2.200
R. + Proxy
Link bandwidth
R. + Proxy + S. + E.
Figure 5.21: Comparison between Proxy and Proxy with TCP enhancement
protocols
5.5. EXPERIMENTAL RESULTS 95
Scenario Average throughput(Kbps)
Reno 624
Eifel 629
Snoop 666
Proxy 1110
Proxy+Eifel 1111
Proxy+Snoop 1130
Proxy+Eifel+Snoop 1131
Table 5.3: Average Throughput in different scenarios
5.5.4 Buffer Size
The sizes of buffers in RNC and Node B are parameters influencing how the
schedulers behave in TCP traffic model, and these sizes limit the throughput
of the system. When the buffer size in RNC is big enough, data always queue
in RNC even though TCP connection is ended, so it is not very necessary to
study this buffer. We focus on the buffer size in MAC-hs in Node B and check
how different schedulers influence TCP performance when we adjust its size.
In this section, all buffer size means the size of buffer in MAC-hs.
In EURANE, the Node B buffer size can be changed. The default value is
250, as we used in all the simulations we have discussed above. Analyzing the
system throughput for different value of node B buffer size, we can summarize
how buffer size in Node B matters in TCP service. As the buffer size increasing,
the system throughput increases. But there is a trade-off value. When buffer
size increases, there are more data waiting at Node B. It will take a longer time
queuing there so that the delay increases too.
IP packets arriving at RNC are first stored in an input buffer before they
are segmented into radio blocks and transmitted to the Node B via the Iub
interface. Additionally, the RLC layer may protect the transmitted radio blocks
with an ARQ mechanism if the connection is to be operated in Acknowledged
Mode (AM). The transmission of data on the Iub-interface is regulated by a
flow control mechanism. In the Node B, the radio blocks are stored in priority
queues, before they are concatenated to larger MAC frames, protected by the
96 CHAPTER 5. SIMULATIONS AND RESULTS
HARQ mechanism and finally transmitted on the air interface. In a multi-user
scenario, a scheduler in the Node B has to decide which users are allowed to
transmit in each scheduling round. Among others, this decision may depend
on the current channel state towards each terminal (channel aware scheduling),
on the QoS parameters of each connection (QoS aware scheduling), or on a
combination of both. Signaling delays and measurement inaccuracies of the
Iub flow control may lead to long queuing delays in the Node B. If the flow
control detects a buffer congestion in the Node B, it will not allow any further
radio blocks to be transmitted from the RNC until the congestion has cleared.
This will also block uplink RLC status report messages, not allowing them to
benefit from the prioritization in the Node B. For this reason, when one of the
prioritization schemes is active, we will override the flow control decision in
such a way that we always allow the transmission of uplink RLC status report
messages from the RNC to the Node B regardless of the Node B buffer fill level.
There are some distinct behaviors at the base station for different kind of
schedulers and different buffer sizes. With FCDS the delay and throughput
increase equitably while buffer size increasing. When the buffer size is not
big enough, FCDS causes more delay in transmission. As buffer size rising,
FCDS can offer better throughput without gain much more delay. Thus, it is
important to adjust buffer size into larger when operator designs the scheduler
as FCDS in TCP traffic. The time allotted for this thesis work did not allow me
to find an optimum value of the buffer in the Node B.
Chapter 6
Conclusions
In this report, a proxy-based solution to improve the performance of TCP on
3G networks has been studied.
First, the main problems of TCP over wireless links have been identified,
and some proposed solutions have been studied. Previous solutions have fo-
cused on some of the problems, but none of them addresses all in one. The
proxy-solution aims at addressing a number of the TCP over wireless connec-
tion problems at once, and without the need to change the remote servers nor
the mobile terminals. This can be achieved if the transport agent at the proxy
is aware of the varying wireless link conditions, and modifies its congestion
window in order to adapt its transmission rate to the bandwidth changes. It
takes advantage of the network information received from the RNC, while TCP
needs to take conservative measures, due to the fact that it can only count on
end-to-end information.
In order to compare the proxy setup to TCP Reno, a set of simulations have
been performed. General performance aspects and performance in practical
situations have been tested and analyzed. The simulations results show that it
is possible to significantly improve the link utilization and efficiency of a TCP
connection, as well as to reduce buffer needs and queuing delays. The studied
Radio Network Feedback solution remarkably outperforms a common TCP
version such as TCP Reno. The proxy reduces the Slow Start latency, increases
the link utilization and properly adapts to abrupt bandwidth changes.
97
98 CHAPTER 6. CONCLUSIONS
To improve the TCP performance we have decided to define Snoop and
Eifel agent at the base station. In order to identify the TCP enhancements so-
lutions some simulations have been performed. The simulations results show
that it is possible to improve TCP performance both in a proxy scenario and
in a TCP Reno scenario. All the simulations have been performed in a real
HSDPA network with the implementation of a particular situation of one ref-
erence user and nine competitor users.
Performance improvements can be measured in terms of end user’s expe-
rience, as well as from the mobile operator’s point of view. End users are in-
terested in reduced latency and response times, and the possibility of enjoying
interactive and real time services, which is directly related to end-to-end de-
lay and delay variation. On the other hand, operators are interested in fully
utilizing the scarce and expensive radio resources, supporting the maximum
number of users per cell, and making their systems scalable. Using a proxy
allows to perform all the adaptation without the need to change the remote
servers, nor the mobile terminals. For the simulations, Drop-Tail buffers have
been used (Drop-Tail queue is simple; i.e., if the buffer is full, all incoming
packets are dropped). We have evaluated that the Radio Network Feedback so-
lution is focused on the problems introduced by variable bandwidth and delay,
wireless link utilization, and sporadic disconnections of mobile terminals. The
solution does not address other problems such as congestion or dimensioning
of the wired part of the UMTS network, nor congestion on parts that do not
belong to the 3G network (i.e, between the proxy and the remote servers). It
assumes that all possible link errors are recovered by the link level protocols,
and that the 3G backbone is properly dimensioned. Therefore, there is room
for possible future work. However, the improved TCP implementation in the
proxy still has the basic TCP functionalities, thus it would be able to function
well (although without any added improvements on the basic TCP algorithms)
in the face of such situations.
In addition, it would be interesting to study and compare the proxy solution
and TCP with more advanced buffer management techniques. Also, it would
be interesting to study the proxy-solution with the implementation in the base
99
station of another protocol to improve TCP performance, that is ICMP.
On the other hand, a simple algorithm has been used for the closed-loop queue
control, but it would be desirable to develop more advanced algorithms, in
order to get the most out of the RNC queue information.
Finally, we can say that there is the possibility to define interactive network
gaming on mobile device thanks to a performance enhancing proxy that opti-
mizes time critical data. Game Transport Protocol (GTP) is a transport protocol
for multiplayer on-line games (MMPOGs). GTP was developed in order to
provide for more efficient transmission of game traffic. In the future, it will be
necessary to implement TCP friendly rate control (TFRC) mechanisms. These
are proposed as a means of overcoming the unfairness existing between TCP
flows and non-TCP flows. Since many Internet applications use TCP as a trans-
port protocol, GTP should be able to support the TFRC mechanism, in order to
coexist with other flows.
GTP is a specialized transport protocol, designed for MMPOGs, and it can-
not entirely replace the existing transport layer protocols such as TCP and UDP.
However, when we consider the tremendous growths in the game markets, the
development of GTP represents a meaningful approach to providing MMPOGs
with efficient network functions, and it is hoped that it will be widely deployed
in client-server programs.
References
[1] HSDPA Overall Description, stage 2, 3GPP TS 25.308 v6.3.0, (Rel. 6), (2004-
12).
[2] High Speed Download Packet Access (HSDPA) enhancements, 3GPP TR 25.899
v6.1.0, (Rel. 6), (2004-09).
[3] N.C.Ericsson, “On scheduling and adaptive modulation in wireless com-
munications,” Technical Licentiate Thesis, UPPSALA University, Sweden,
June 2001.
[4] Spreading and modulation, 3GPP TS 25.213 v6.4.0, (Rel. 6).
[5] L. N. Lee, A. R. Hammons, F.-W. Sun, and M. Erozm, “Application and
standardization of turbo codes in third-generation high-speed wireless
data services,” IEEE Transactions on Vehicular Technology, volume 49, No-
vember 2000.
[6] Multiplexing and channel coding, 3GPP TS 25.212 v6.7.0, (Rel. 6).
[7] H. Harri and T. Antti, “Hsdpa/hsupa for umts,” Wiley, 2006.
[8] D.Chase, “Code combining a maximum-likelihood decoding approach for
combining an arbitrary number of noisy packets,” IEEE Transactions on
Communications, Volume: 33 Issue: 5, May 1985.
[9] J. Holtzman, “Cdma forward link waterfilling power control,” In Proc. of
IEEE VTC Spring, 2000.
[10] A. Jalali, R. Padovani, and R. Pankaj, “Data throughput of cdma-hdr a
high efficiency-high data wireless personal communication system,” in
Proc. 50th annual Int. VTC, vol. 3, Tokyo, May 2000.
101
102 REFERENCES
[11] UTRA High Speed Downlink Packet Access (HSDPA); Overall description,
3GPP TS 25.308 v6.3.0, (Rel. 6).
[12] Physical layer - General description, 3GPP TS 25.201 v6.2.0, (Rel. 6), (2005-06).
[13] Physical channels and mapping of transport channels onto physical channels,
3GPP TS 25.211 v6.7.0, (Rel. 6).
[14] Multiplexing and channel coding (FDD, 3GPP TS 25.212 v6.6.0, (Rel. 6),
(2005-09).
[15] Physical layer procedures (FDD), 3GPP TS 25.214 v6.5.0, (Rel. 6), (2005-03).
[16] A. Dahlen and P. Ernstrm, “Tcp over umts,” RVK02, 2002.
[17] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, “Tcp selective ac-
knowledgment options,” RFC 2018, April 1996.
[18] A. Bakre and B. R. Badrinath, “I-tcp: indirect tcp for mobile hosts,”
Proceedings-International Conference on Distributed Computing Systems, Van-
couver, Canada, 1995.
[19] M. Mathis and J. Mahdavi, “Forward acknowledgement: Refining tcp
congestion control,” in Proceedings of the ACM SIGCOMM, August 1996.
[20] F. Xin and A. Jamalipour, “Tcp throughput and fairness performance in
presence of delay spikes in wireless networks,” International Journal of
Communication Systems, 2005.
[21] G. Xylomenos, G. C. Polyzos, M. Saaranen, and P. Mahonen, TCP/IP Per-
formance over Wireless Networks, M. HASSAN and R. JAIN, Eds. HIGH
PERFORMANCE TCP/IP NETWORKING, PRENTICE HALL, 2002.
[22] V. Paxson and M. Allman, “Computing tcp’s retransmission timer,” RFC
2988, November 2000.
[23] W. Stevens, M. Allman, and V. Paxson, “Tcp congestion control,” RFC
2581, April 1999.
[24] High Speed Downlink Packet Access (HSDPA) Iub/Iur protocol aspects, 3GPP
TR 25.877 V5.1.0, (Rel. 5), (2002-06).
REFERENCES 103
[25] Radio Resource Control (RRC) Protocol Specification, 3GPP TS 25.331 v6.7.0,
(Rel. 6), (2005-09).
[26] C. Casetti and M. Meo, “A new approach to model the stationary bahav-
iour of tcp connections,” In Proc. of the IEEE Conference on Computer Com-
munications (INFOCOM), 2000.
[27] A.Kumar, “Comparative performance analysis of versions of tcp in a local
network with a lossy link,” IEEE/ACM Transactions on Networking, 6, no.
4:485-98, August 1998.
[28] J. Padhye. Web page, tcp modeling. [Online]. Available:
http://www.icir.org/padhye/tcp-model.html
[29] J. Padhye, V. Frnoiu, D. Towsley, and J. Kurose, “Modeling tcp through-
put: A simple model and its empirical validation,” IEEE/ACM Transactions
on Networking, vol. 8, no. 2, pp. 133–45, April 2000.
[30] M. Assaad and D. Zeghlache, “Tcp performance over umts-hsdpa sys-
tems,” Auerbach Publications, 2006.
[31] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, and R. H. Katz, “A
comparison of machanisms for improving tcp performance over wireless
link,” In Proc. of the AMC Annual Conference of the Special Interest Group on
Data Communication (SIGCOMM)96, Stanford, CA, 1996.
[32] H. Balakrishnan, S. Seshan, and R. H. Katz, “Improving reliable transport
and handoff performance in cellular wireless networks,” AMC Wireless
Networks, vol. 1, no. 4, pp. 469–81, 1995.
[33] B. Badrinath and A. Bakre, “I-tcp: Indirect tcp for mobile hosts,” 15th In-
ternational Conference on Distributed Computing Systems, Vancouver, Canada,
May 1995.
[34] R. Ludwig and R. H. Katz, “The eifel algorithm: Making tcp robust against
spurious re-transmission,” ACM Computer Communication Review 30, no. 1,
pp. 30–36, January 2000.
[35] R. Ludwig and M. Meyer, “The eifel detection algorithm for tcp,” Internet
Draft, IETF, February 2002.
104 REFERENCES
[36] M. Kazantzidis and M. Gerla, “End-to-end versus explicit feedback mea-
surement in 802.11 networks.”
[37] D. Dutta and Y. Zhang, “An early bandwidth notification (ebn) architec-
ture for dynamic bandwidth environment,” in IEEE International Confer-
ence on Communications, vol. 4, April 2002.
[38] H. Lim, K. Xu, and M. Gerla, “Tcp performance over multipath routing in
mobile ad hoc networks.”
[39] N. Moller, I. C. Molero, K. H. Johansson, J. Petersson, R. Skog, and
A. Arvidsson, “Using radio network feedback to improve tcp perfor-
mance over cellular networks,” in Proceedings of the 44th IEEE Conference
on Decision and Control, and the European Control Conference 2005, Seville,
Spain, December 2005.
[40] J. D. Pellegrino and C. Dovrolis, “Bandwidth requirements and state con-
sistency in three multiplayer game architectures,” NetGames, 2003.
[41] Technical Specification Group Services and Systems Aspects; Network architec-
ture, 3GPP TS 23.002, 3rd Generation Partnership Project, (Rel. 6).
[42] M. Meyer, J. Sachs, and M. Holzke, “Performance evaluation of a tcp
proxy in wcdma networks,” In IEEE Wireless Communications, October
2003.
[43] G. Cheung, T. Sakamoto, and M. Sweeney, “Performance enhancing proxy
for interactive 3g network gaming,” In ACM IWCMC’06, Canada, July
2006.
[44] S. Pack, E. Hong, Y. Choi, I. Park, J.-S. Kim, and D. Ko, “Game transport
protocol: A reliable lightweight transport protocol for massively multi-
player on-line games (mmpogs),” In SPIE-ITCOM, Boston, MA, July 2002.
[45] S. Aggarwal, H. Banavar, and A. Khandelwal, “Accuracy in dead-
reckoning based distributed multi-player games,” In ACM SIGCOMM
NetGames, Portland, OR, August 2004.
[46] ([2003-01-15]) Ns-2 ucb/lbnl/vint network simulator. [Online]. Available:
http://www.isi.e-du/nsnam/ns/index.html
REFERENCES 105
[47] E. Altman and T. Jimenez, NS Simulator for beginners, Univ. de Los Andes,
Merida, Venezuela and ESSI, Dec 2003.
[48] ([2003-01-15]) Tcl tool command language. [Online]. Available:
http://www.tcl.tk/
[49] Eurane website. [Online]. Available: http://www.ti-wmc.nl/eurane/
[50] Seacorn website. [Online]. Available: http://seacorn.ptinovacao.pt/