downlink tcp proxy solutions for interactive gaming over...

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


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.


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.


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.


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.


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


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-


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-


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


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


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


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.


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


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-


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


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-


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


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.


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).


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


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


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-


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


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


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-


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


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


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


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.


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.


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,


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-


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


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


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


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.


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


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


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


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


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


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


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


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-


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


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


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.


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


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


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


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.


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


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


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


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/

downlink tcp proxy solutions for interactive gaming over...

Documents