Your SlideShare is downloading. ×
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Downlink TCP Proxy Solutions for Interactive Gaming over ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Downlink TCP Proxy Solutions for Interactive Gaming over ...

2,248

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,248
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Downlink TCP Proxy Solutions for Interactive Gaming over HSDPA and 3G Networks MARCO FIORENZI Master’s Degree Project Stockholm, Sweden 2007
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. vi A CKNOWLEDGEMENTS 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.
  • 6. 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
  • 7. viii I NTRODUCTION 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
  • 8. I NTRODUCTION 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
  • 9. x I NTRODUCTION 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
  • 10. I NTRODUCTION 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.
  • 11. 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
  • 12. xiv C ONTENTS 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
  • 13. 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
  • 14. 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
  • 15. xviii L IST OF F IGURES 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
  • 16. 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
  • 17. 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
  • 18. 2 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - 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
  • 19. 1.2. HSDPA C ONCEPT 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
  • 20. 4 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA channel allocation to the users. Scheduling is a key feature in the HSDPA con- cept and is tightly coupled to fast link adaptation. Note that the time-shared nature of the channel used in HSDPA provides significant trunking benefits over DCH for bursty high data rate traffic. The HSDPA shared channel does not support soft handover due to the com- plexity of synchronizing the transmission from various cells. Fast cell selection can be used in this case to replace the soft handover. It could be advantageous to be able to rapidly select the cell with the best Signal to Interference Ratio (SIR) for the downlink transmission. HSDPA work with enhancement techniques [2] applied on a combined: CDMA-TDMA (Time Division Multiple Access) channel shared by users. This channel, called High Speed Downlink Shared Channel (HS-DSCH), is divided into slots called Transmit Time Intervals (TTIs) each one equal to 2ms. The sig- nal transmitted during each TTI uses the CDMA technique. Since link adap- tation is used, the variable spreading factor is deactivated because its long- term adjustment to the average propagation conditions is not required any- more. Therefore, the spreading factor is fixed and equal to 16. The use of rela- tively low spreading factor addresses the provision for increased applications bit rates. 1.3 Fast Link Adaptation The wireless channel in cellular systems is a composite multipath/shadowing channel. The radio waves follow several paths from the transmitter to reach the destination. Fading occurs when many paths interfere, adding up to a com- posite signal exhibiting short time signal power variations at the receiver. This power could be weaker or stronger than the required power needed to achieve a given user Quality of Service (QoS). The link quality between the transmit- ter and the receiver is also affected by slow variations of the received signal amplitude mean value due to shadowing from terrains, buildings, and trees. To deal with the problems caused by multipath fast fading, the existing wireless systems use diversity techniques such as long interleaving, robust channel coding, frequency hopping, and direct sequence spread spectrum. The
  • 21. 1.3. FAST L INK A DAPTATION 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.
  • 22. 6 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA Although, CQIs are meant to help Node B to perform link adaptation, Node B will execute fast link adaptation depending on the implemented algorithm, which is vendor specific. Not only decisions will be based on the CQI (or any other implemented algorithm), but decisions will be also based on the available resources of Node B. In general, regardless of the implemented algorithm, link adaptation algorithms will select a transport block size, a modulation, and the number of codes. This set of parameters is called transport format and resource combination (TFRC). In the 3GPP Release 6 [2], enhancements are added to the CQI reporting method by introducing tuneable reporting rates through additional CQI re- ports during periods of downlink activity and fewer reports at other times. These additional CQIs can be initiated on demand of fast layer signalling. In addition, a certain number of successive CQI values may be averaged with re- spect to channel quality at the UE. The averaged value is reported and used with the instantaneous CQI measured to select the Modulation and Coding Scheme (MCS). The motivation for this technology is to improve the selection of MCS, so that the delay due to HARQ retransmissions can be reduced. In addition, the UL signalling overhead may be reduced and this decreases the uplink interference. 1.4 Adaptive Modulation and Coding HSDPA uses two modulation schemes for the HS-DSCH channel. One is the QPSK modulation which was already used for the DCH channel in Release 99. The second modulation scheme is 16QAM [4]. The modulation 16QAM uses four bits to represent a symbol, while QPSK uses just two bits for the same purpose. Hence, 16QAM doubles the data rate. The achievable bit rates for HSDPA are depending on the modulation, code rate, and the number of channelization codes. Node B will adjust the modulation required in each TTI depending on the radio environment of the UE. This fact will minimize the effect of the near-far problem. In other words, UEs nearer Node B will receive better Es/N0 (Energy per symbol / noise spectral density) than those UEs situated far from Node B.
  • 23. 1.5. H YBRID 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.
  • 24. 8 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA The fastest retransmissions will be MAC-hs retransmissions since Node B is the only element involved in the process. After a certain number of retrans- missions, RNC will take over Node B and it will perform a RLC retransmis- sion. RLC retransmissions will have longer delays, which are direct effect of the transmission through the Iub interface and the additional processing steps. Finally, if the RLC retransmissions fail or a time-out at the application level happens, a TCP retransmission will be necessary. TCP retransmissions will be the slowest since these retransmissions will need to go through the whole RAN, core network, and the Internet. The fast retransmission procedure can be presented and simplified into four steps. In the first step, RNC sends a packet to the UE. This packet will go through Node B where it will be buffered, scheduled, and finally forwarded to the UE. Second step, the UE will reply with an ACK, or a NACK. The ACK/NACK is forwarded to RNC. Third step, in UMTS, RNC would take care of retransmitting the appropriate packet whether it is necessary. Instead, in Release 5, the ACK/NACK is received by Node B which will take action to retransmit the appropriate data to the UE. Finally, the UE sends a positive ac- knowledgement, fourth step, to Node B which will forward the ACK/NACK back to RNC. Whether the UE sends a negative acknowledge to Node B, Node B will retransmit again the correct data. After a certain amount of repetitions, Node B will ask RNC to take action (RLC retransmission) and the process will start again. If after n RLC retransmissions the UE still replies with negative acknowledgements, higher levels will take over the retransmission and a TCP retransmission will be performed. HARQ [6] implements two different retransmission strategies: chase com- bining and incremental redundancy. ”Chase combining”[8] means that retrans- missions will be totally identical to the original transmitted data. On the other hand, ”incremental redundancy” means that retransmissions will differ from the original transmitted data. The output of the channel coding module is the in- put of the HARQ module. The output of the HARQ module will depend on the transmission strategy selected and the puncturing/repetition rate. First transmissions will always be self-decodable. All systematic bits are sent, in addition to some parity bits. The number of parity bits will depend on
  • 25. 1.6. FAST PACKET S CHEDULING 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.
  • 26. 10 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA The most famous scheduling algorithms are: Round Robin (RR), Max C/I, Proportional Fair (PF) and Fair Channel-Dependent Scheduler (FCDS). Round Robin: RR algorithm allocates the channel to the users in a cyclic order offering a fair time resource sharing among users. Since this scheduler ignores the radio channel conditions, it does not provide a fair throughput among users. The absence of the scheduling adaptation to the short term chan- nel variations counteracts the fast link adaptation introduced in HSDPA. Con- sequently, this scheduler provides low cell throughput. The only advantage of using this algorithm is its implementation simplicity. Max C/I: in this algorithm, the node B tracks the channel quality of each user by measuring the SIR (Signal to Interference Ratio) on the CPICH channel (Common Pilot Indicator Channel) and allocates the HS-DSCH channel to the user with the best SIR. In the ideal situation when channel conditions of the users present the same statistics, this strategy maximizes the total capacity of the system and the throughput of individual users. In reality, the statistics are not symmetrical since the users can be closer to the base station with a bet- ter average SIR or at the cell border with relatively bad conditions, stationary or moving at high speed, in a rich scattering environment or with no scatter- ers around them. Therefore, by using the Max C/I strategy in practice, the channel is always allocated with higher order MCS (i.e. higher average trans- mission rate) but induces starvation of users with relatively bad channel con- ditions. Consequently, this algorithm maximizes the cell capacity but presents a problem of fairness between users especially for users at the cell border. In addition, the QoS constraints (e.g. the throughput in a given time scale and not the long term average throughput) of different services are not considered in this scheduler which can have a drastic effect on higher layers such as TCP or on certain services such as streaming. Proportional Fair: PF realizes a reasonable trade-off between efficiency and fairness among users [9] [10]. It consists in transmitting to the user with the highest data rate relative to its currently achieved mean data rate. During each TTI, the channel is allocated to the user having max(r/S); variable r is the trans- mission rate in the current TTI (according to the transmission scheme selected) and S is the average bit rate transmitted in the previous TTIs.
  • 27. 1.7. HSDPA A RCHITECTURE 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.
  • 28. 12 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA Transport Channels HSDPA consists of a time shared channel between users and is consequently suitable for bursty data traffic. HSDPA is basically conceived for non real time data traffic. Research is actually ongoing to handle streaming traffic over HS- DPA using improved scheduling techniques. The High Speed Downlink Shared Channel (HS-DSCH) is the specific trans- port channel tied to HSDPA. Unlike DCH, which is a dedicated transport chan- nel, HS-DSCH is a downlink channel which is shared by all UEs within a cell, i.e. HS-DSCH is a common transport channel. The fast adaptation to the short term channel variations requires handling of fast link adaptation at the node B. Therefore, the data transport channel HS-DSCH is terminated at the node B. This channel is mapped onto a pool of physical channels called High Speed Physical Downlink Shared Channel (HS- PDSCH) to be shared among all the HSDPA users on a time and code multiplexed manner [12] [13]. This transport channel can be mapped to either a (HS-PDSCH) or to a High Speed Shared Control Channel (HS-SCCH) depending whether the transmitted information is user data or signaling information, respectively. The transport channel coding structure is reproduced as follows: one trans- port block is allocated per TTI, so that no transport block concatenation (such as in UMTS DCH based transmission) is used. The transport block size changes according to the Modulation and Coding Scheme (MCS) selected using the Adaptive Modulation and Coding (AMC) technique. To each transport block, a Cyclic Redundancy Check (CRC) sequence with 24 bits is added. Since er- rors occur in bursts, one CRC sequence per transport block (i.e. per TTI) is sufficient. Once the CRC sequence is attached, the transport block bits are bit scrambled and segmented into blocks to apply Turbo block encoding. The code block size depends upon the turbo coding rate and can reach a maximum value of 5114 bits [14]. The coding rate changes according to the MCS scheme selected by the link adaptation technique. At the turbo encoder output, rate matching is applied by the physical layer HARQ functionality. After matching the number of bits to the number of bits in the allocated HS-DSCH physical channels, segmentation divides the resulting bits among the HS-DSCH physi- cal channels.
  • 29. 1.7. HSDPA A RCHITECTURE 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
  • 30. 14 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA monitor at most four HS-SCCH channels. Figure 1.1: 4 HS-SCCH frame structure High Speed Dedicated Physical Control Channel (HS-DPCCH) In the uplink, signalling information has to be transmitted for the HARQ ac- knowledgment and the feedback measurement. The use of fast link adaptation on the HS-DSCH channel requires knowledge of the channel quality during the transmission. The UE measures the channel quality on the Common Pi- lot Indicator Channel (CPICH) and sends the result to the node B. The use of HARQ requires an acknowledgment message from the user to the node B, so that the node B retransmits the erroneously received packet or a new packet. The HS-DPCCH channel is an uplink channel used for signaling purposes. The modulation scheme for this channel is BPSK and the spreading factor is 256; thus, this channel has a bit rate of 15 Kbps. Moreover, HS-DPCCH channel is power controlled. The signaling information sent through this channel is related to Ack/Nack, and to CQIs. Thanks to this feedback, Node B will be able to perform link adaptation, scheduling decisions, and to retransmit erroneous information. The H-ARQ acknowledgment is a 1-bit Ack/Nack indication repeated 10 times and transmitted in one slot. The H-ARQ acknowledgement field is gated off when there is no Ack/Nack information being sent. The measurement feed- back information contains Channel Quality Indicator (CQI) that may be used to select transport format and resource by HS-DSCH serving Node-B, accord-
  • 31. 1.8. T RANSPORT 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-
  • 32. 16 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA ditions enable the use of the higher rate modulation. This leads to a more bandwidth demanding access in terms of transmission between the BTS and the RNC. This impact on the throughput per BTS will depend on the mobile performances for HSDPA, which are characterized by the UE category. For instance, up to 4.8 Mbps per cell on the Iub, which is the interface be- tween the BTS and the RNC, is expected with HSDPA in the next couple of years, which means that even with a statistical multiplexing gain of 50 percent, 8 Mbps will be required for hot spots. Besides, the inversion of the nature of the traffic with more than 60 percent of data traffic will require wireless operators to plan new transmission archi- tectures by adding more points of concentration in the access network in order to take the best of the statistical multiplexing gain. It will also change the way of engineering the transmission network by dedicating specific transport chan- nels for recollecting the HSDPA traffic. 1.9 Performances with HSDPA Indoor vs. outdoor HSDPA solutions In the indoor environment, the small cell size, the very good and controlled coverage, and low mobility lead to a very high spectrum efficiency and very high data rate per user. Even if the 16 QAM modulation is very sensitive to the radio conditions, this modulation will be used most of the time in an Indoor environment. In addition, there is a very low impact on PA power for HSDPA operation, which means the downlink throughput is not significantly impacted by the minimum power required for the signaling HS-SCCH channel. However, when dealing with outdoor configurations, the broadband per- formances are much more challenging due to higher interference at the cell edge and larger cell size compared to indoor coverage for WLAN-type ser- vices. Basically, there is a significant impact on PA power for HSDPA operation, i.e., lower downlink throughput due to required power for HS-SCCH. There- fore, HS-SCCH power control is required to reduce impact on HSDPA through- put. Otherwise, more than 10 percent of the PA should be reserved for the HS
  • 33. 1.10. B EYOND 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-
  • 34. 18 C HAPTER 1. H IGH S PEED D OWNLINK PACKET A CCESS - HSDPA UPA (Enhanced DCH in 3GPP Release 6), MIMO (Multiple-Input Multiple- Output) and OFDM (Orthogonal Frequency Division Multiplexing) in 3GPP Release 7. Going further to 3GPP Release 7 and to ensure competitiveness in an even longer time frame, i.e., for the next 10 years and beyond, a long-term evolution of the 3GPP radio-access technology is now under investigation in 3GPP RAN Working Group. 1.10.1 HSUPA The 3GPP objectives with HSUPA are to improve performance of uplink ded- icated transport channels by scheduling the Uplink UE data rates depending on the interferences and on the Node B processing resources, while increasing the radio interface robustness with the HARQ protocol. The 3GPP Study has concluded that the use of these mechanisms associated with a shorter TTI of 2 ms can lead to the following enhancements: • 50-70% improvement in UL capacity; • 20-55% reduction in end-user packet call delay; • around 50% in user packet call throughput. HSUPA is a very important step that can be achieved in the next years. By reaching high spectrum efficiency and low latency for both the uplink and downlink with HSDPA/HSUPA, wireless operators will be able to provide seamless access services like VoIP. 1.10.2 MIMO MIMO (Multiple-Input Multiple-Output) is also a very promising technology that will empower UMTS HSDPA networks by providing three times more throughput than HSDPA. MIMO increases the capacity due to the multi-stream transmissions and code reuse with multiple antennas on both the transmitter and receiver sides. MIMO has been studied for a long time, but due to the very high processing
  • 35. 1.10. B EYOND 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).
  • 36. 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
  • 37. 22 C HAPTER 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
  • 38. 2.2. T RANSMISSION C ONTROL P ROTOCOL 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
  • 39. 24 C HAPTER 2. TCP OVER UMTS-HSDPA description of how TCP tries to govern its send rate and control congestion, can be found in [20], while here we give only a short basic overview of TCP functionality. Many different versions of the TCP protocol have been devel- oped to address various details of the data transport. They generally use the same mechanism, but the details in their operation differs. TCP sends data packets and the receiver acknowledges the received data to the sender. Congestion is detected by measuring the time between data are sent and they are acknowledged, called the round trip time (RTT). If this time exceeds a time-out value, TCP assumes that the data have been delayed by congestion in the network. The time-out value is a prediction based on, and updated by, the measured RTTs. The TCP protocol uses a congestion window when determining its send rate. The window describes how much data are al- lowed to be transferred through the network without congestion and together with the RTT it determines the send rate of the TCP algorithm. To determine the initial allowed transfer rate, TCP starts with a low amount of data and then uses an exponential increase in data rate. This is called a slow start, which in steps double the data that are transferred to the receiver. When congestion is detected, either by triple duplicate or a retransmission timeout, or until the window size reaches a threshold called slow-start threshold, the initial con- gestion window size is determined to be half the amount of data transferred in the last slow start step, so to be half the slow-start threshold. But, once the slow-start threshold is reached, the slow-start soft state is replaced with the congestion-avoidance soft state, where the growth of the congestion window slows down. The slow-start mechanism can be regarded as a soft phase where the sender probes the buffer space in the network. The successive ACKs are interpreted by the sender as an available space in the network to more transmitted packets. Therefore, the sender keeps increasing the window size. On the other hand, the aggressive exponential growth of the congestion window aims at rapidly fill- ing the bottleneck to have a small effect on the throughput performance and to optimize the system efficiency. An important part in achieving a high throughput with TCP is to have a stable RTT. If the RTT varies a lot, the TCP algorithm can not predict it accu-
  • 40. 2.2. T RANSMISSION C ONTROL P ROTOCOL 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
  • 41. 26 C HAPTER 2. TCP OVER UMTS-HSDPA Figure 2.1: TCP’s Congestion Window in Reno implementation the Tahoe algorithm, where a timeout is not considered different from three du- plicated acks. Both congestion indications result in the sender shrinking cwnd to one segment, setting the value of the threshold to half the value it had at the moment congestion was detected, and going back to slow start. Newer TCP versions (such as TCP Reno) consider this algorithm too conservative, and they distinguish a loss indication due to a timeout from the occurrence of three du- plicated acks. A timeout causes the TCP Reno sender behave in the same way as the previous Tahoe implementations, but the reception of three duplicated acks are considered as a warning rather than an indication of congestion. In such case both the threshold and cwnd are set to half the value of the previous threshold. Thus, the sending rate is reduced by half, and the sender stays in Congestion Avoidance instead of going back to Slow Start. 2.3 Key parameters to evaluate TCP Performance The performance of TCP can be measured or valuated in different ways ac- cording to the context, the system used, and the application carried over the TCP connection. TCP Performance can be evaluated using the following key parameters [21]: • Effective throughput: The effective throughput, called also effective band- width, is the data transmission rate of the application in bits/s. The ef- fective throughput is more significant than the communication channel throughput, since a inefficient implementation or a cross-layer interac- tion between TCP and RLC may result in a transmission rate reduction
  • 42. 2.4. TCP C ONNECTION 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
  • 43. 28 C HAPTER 2. TCP OVER UMTS-HSDPA managing different connections over the air interface. Therefore, the main data buffer is located in the Node B instead of the RNC. Losses in wireless network segments are produced by high-bit error rates and handoff procedures. The ARQ protocol is used to recover from packet losses over the radio interface, but this increases the delay of receiving packets at the TCP layer. The use of soft-combining algorithms with ARQ in the Node B reduces the delay generated by the ARQ protocol. In UMTS Release 99, the ARQ protocol is implemented in the RNC, whereas in HSDPA it is handled by the MAC-hs entity in the node B; in both cases, the data is delivered to the TCP layer in sequence. This implies that the ARQ delay may only generate a timeout in the TCP connection. When studying TCP performance in UMTS systems, either Release 99 or HSDPA, several parameters or variables can interact and affect TCP efficiency. These parameters are the: • TCP version such as Reno or SACK; • Slow-start threshold, ssthresh; • Initial congestion window, cwnd (1,2 Maximum Segment Size or more); • MTU size; • TCP receiver buffer size, which limits the advertised window, awnd ; • Round-trip time (RTT) in the internet, which has a direct impact on the TCP flow rate; • Congestion rate and the segment losses in the Internet; • Error rate over the air interface and the ARQ protocol used; • RLC MaxDAT, which indicates the maximal number of retransmissions of a given RLC PDU; • Allocated DCH channel (e.g., SF, bit rate) in UMTS Release 99, which has a direct impact on the overall RTT value; • Scheduling algorithm used in HSDPA, which determines the transmis- sion rate over the air interface and the delay jitter due to the variable storage duration of the data in the Node B buffer;
  • 44. 2.4. TCP C ONNECTION 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.
  • 45. 30 C HAPTER 2. TCP OVER UMTS-HSDPA In UMTS Release 99, the initial and the maximum size of the transmission- window are configured by the RRC entity [25]. During the connection, the receiver can request a change of the transmission-window size (this modifica- tion can be due to, for example, a limited receiver buffer size, user equipment capabilities, reception complexity, or delays); therefore the sender informs the receiver about this change through one field carried in a status PDU. In HS- DPA, the transmission-window size indicates the number of parallel HARQ processes, or instances, that can be handled by the MAC-hs entity (up to eight HARQ channels can be used simultaneously, in this way the maximum size of the transmission window is limited to eight MAC-hs PDUs). Reliable TCP protocol provide another important service to transmitted data such as segmentation to the data received from upper layers. In TCP, the segment size is variable and is upper bounded by a maximum size called MSS (maximum segment size). MSS is negotiated between the end TCP entities and is delimited by the size of MTU (Maximum transmission unit) at the IP level. In UMTS Release 99, the RLC PDU size is selected during the con- figuration of the RLC entity. The PDU size is generally equal to 43 bytes (3 bytes for RLC header). IN HSDPA, the RLC PDU size is selected in the same way as in UMTS Release 99. However, the MAC-hs PDU size changes dynamically ac- cording to the selected MCS (an MCS is the combination of a modulation order M, a channel coding rate τ , and a number of parallel HS-DSCH channel codes N). The MAC-hs PDU is transmitted over one TTI (TTI is 2ms). Each RLC PDU corresponds to one or more MAC-hs PDUs. 2.5 Modelling of TCP over UMTS-HSDPA The TCP protocol has been widely studied and discussed in the literature. With the growth of the applications services relying on the TCP/IP protocol stack, the performance of TCP in the currently developed data networks has become a more and more relevant research topic. A large number of analytical TCP models have been developed with the aim of describing the TCP interaction between the TCP protocol and the protocols and the control mechanism used in a real data network. Even though these models consider a wide variety of
  • 46. 2.5. M ODELLING 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
  • 47. 32 C HAPTER 2. TCP OVER UMTS-HSDPA effect of TCP on HSDPA requires estimates of the latency time of the slow-start phase, the loss recovery, and the steady-state phase. In HSDPA, the size of a TCP segment is 1500 octets and each TCP seg- ment is transmitted using several predefined TTIs, that is one segment each 2ms. Transmitting a TCP segment requires between 12 and 60 TTIs (depend- ing upon the modulation and coding schemes used on the radio interface) [30]. Note also that the HARQ used in HSDPA is ”stop and wait”. The number of retransmission required to deliver the TCP segment is a random variable due to varying radio channel conditions. The time needed to transmit an error free TCP segment is: ns i=1 NT T I (i) RT T = Tj + RT Twired = RT Twireless + RT Twired ns Where (from [30]): ns NT T I (i) • Ni = i=1 ns is 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; • NT T I (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 : 1 + Pe − Pe Ps N= 1 − Pe Ps Pe (1 − Pe + Pe Ps ) σ2 = (1 − Pe Ps )2 Pe is the probability of errors after decoding the information segment via FEC
  • 48. 2.5. M ODELLING 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 − Pe Ps ) 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(RT T = Gaussian > To ) with the Gaussian assumption leads to Q( To −E(RT ) ) ) σ 2 (RT T T 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: data R= 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-
  • 49. 34 C HAPTER 2. TCP OVER UMTS-HSDPA missions (NT CP ) becomes important. When NT CP 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. NT CP 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 .
  • 50. 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
  • 51. 36 C HAPTER 3. E NHANCING 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-
  • 52. 3.1. L INK - LAYER S OLUTIONS 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
  • 53. 38 C HAPTER 3. E NHANCING TCP OVER WIRELESS that packet losses can also be detected by local timeout since the snoop.ack module maintains an update estimate of the RTT. The main advantages: • It maintains the end-to-end semantics of the TCP connection; • It performs efficiently during a handoff process since cached packets will be transmitted to the mobile as soon as it can receive them. The snoop relies on TCP acknowledgments to detect whether a packet is received or not. The main disadvantages: • Snoop requires heavy storage and processing to cache TCP segments. In the case of the cellular networks, the snoop is impractical due to the high number of users in each cell. A snoop agent will be implemented in the RNC, in the UMTS and not in the base station. • The wireless gateway needs to snoop inside TCP connections, which does not work when the packets are encrypted. 3.1.2 Delayed Duplicate Acknowledgments An important link-layer solution is the Delayed Duplicate Acknowledgments that tries to imitate the behavior of the snooping protocol but makes modifica- tions [30] at the receiver rather than at the base station. When out-of-sequence packets are received at the TCP receiver (e.g., mobile host, user equipment) the receiver sends duplicate acknowledgments for the first two out-of-order pack- ets. The third and subsequent duplicate acknowledgements are delayed for a duration d. Indeed, this scheme assumes that the out-of-sequence is generated by packet losses over wireless links, and a reliable link-layer protocol such as ARQ is used. Therefore, the erroneous packets will finally be received correctly after a certain delay.
  • 54. 3.2. S PLIT S OLUTIONS 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-
  • 55. 40 C HAPTER 3. E NHANCING TCP OVER WIRELESS tween the wireless gateway and the mobile host, or the receiver. Consequently, TCP performance in the first connection are affected only by the congestion in the wired network, and wireless errors are hidden from the sender. TCP connections are split at the wireless gateways connected to both wire- less and wired links. In this manner, when packets are corrupted by transmis- sion errors over the wireless link, they can be retransmitted over the wireless section of the path only. One efficient approach to improve TCP performance over wireless networks is to introduce a proxy between the server and the terminal, i.e., splitting the connection into one connection between the server and the proxy, and another one between the proxy and the terminal. This approach is often denoted split TCP. This approach generate changes only to the proxy and possibly the ter- minal, but the advantage of this solution is that the server will see an ordinary wired network, and this approach will not required changes at the sending server. With split TCP, one can in many cases use an arbitrary transport pro- tocol between the proxy and the terminal. This may be an attractive option if the operator has control over the networking software running on the termi- nals, but when supporting off-the-shelf terminals, deployment of a specialized transport protocol is difficult. Indirect-TCP, also known as I-TCP[33], is a TCP enhancement scheme based on the split approach. This protocol splits the connection into two connections, the first one between a fixed host, such as a remote server, and a mobile sup- port router located at the beginning of the wireless network, the second con- nection is established between the mobile host and the mobile support router so that faster reaction to mobility and wireless errors can be performed. In this scheme, a software agent at the wireless gateway intercepts TCP connection establishment messages and transparently decomposes the end-to-end connec- tion into separate TCP connections for the wired and wireless parts of the path. The agent bridges these connections by forwarding TCP packets between the two. The connection over the wireless part has a lower delay, leading to faster TCP retransmissions, while the connection over the wired part remains un- aware of wireless losses. TCP can also be replaced over the wireless part of the path by another transport protocol providing improved error recovery.
  • 56. 3.2. S PLIT S OLUTIONS 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
  • 57. 42 C HAPTER 3. E NHANCING TCP OVER WIRELESS of the packets received from the fixed network into METP packets. This result in a reduced header since the transport and IP headers are removed. 3.3 End-to-End Solutions End-to-End Solutions include some changes to TCP mechanics and involves more cooperation between the sender and the receiver to separate wireless losses and network congestion. There are a lot of end-to-end TCP enhance- ment schemes, such as: TCP SACK, Forward Acknowledgment, SMART Re- transmissions, Explicit Congestion Notification, and so on... In this thesis we restriction attention to: Eiffel and TCP over Wireless Using ICMP Control Mes- sages. 3.3.1 Eifel Algorithm In the case of spurious timeouts, the TCP senders proceeds to a retransmission of the segment interpreted to be dropped. When the sender receives an ACK after the segment retransmission, it cannot decide if that ACK corresponds to the retransmitted segment or to the first one. This phenomenon, is called re- transmission ambiguity. The TCP Eiffel was proposed to deal with this situation of retransmission am- biguity [34][35]. Eliminating the retransmission ambiguity requires extra in- formation in ACKs that the sender can use to unambiguously distinguish an ACK for the original transmission of a segment from that of a retransmission. The TCP timestamp option provides exactly what we need. The timestamp value, the current congestion-window-size, and the slow-start threshold are stored by the sender. When using the timestamp option the TCP sender writes the current value of a ”timestamp clock” into the header of each outgoing seg- ment. The receiver then echos those timestamps in the corresponding ACKs. Eliminating the retransmission ambiguity is then implemented as follows. The sender always stores the timestamp of the first retransmission triggered by an expiration of the retransmission timer. Then, when the first ACK that acknowl- edges the retransmission arrives, the sender compares the timestamp of that ACK with the stored value. If it is smaller than the stored value, this indicates
  • 58. 3.3. E ND - TO -E ND S OLUTIONS 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.
  • 59. 44 C HAPTER 3. E NHANCING TCP OVER WIRELESS Therefore, the sender receives surely either an ACK or an ICMP-DIFFER within one RTT after the packet transmission. At the receipt of the ICMP-DIFFER mas- sage, the sender resets its retransmission timer according to the current RTT estimate without changing its congestion-windows size and slow-start thresh- old. The timer’s postponement of a retransmission timeout (RTO) gives the base station sufficient time to locally retransmit the erroneous packet. In the case of successive failures of the packet transmission, another ICMP message, called ICMP-RETRANSMIT is sent to the TCP source. At the same time, the TCP receiver generates duplicate ACKs since other subsequent packets have been received. At the receipt of ICMP-RETRANSMIT and the first duplicate ACK, the sender goes into fast recovery phase and retransmits the erroneous packet. Once a new ACK is received, the recovery phase is ended and the congestion-window size is set to the value before ICMP-RETRANSMIT was generated. If neither ICMP-DIFFER nor ICMP-RETRANSMIT are sent to the sender, the TCP congestion follows conventional TCP algorithms once a triple duplicate ACKs or a retransmission timeout occur. It is better to generate ICMP messages at the base station rather than at the TCP receiver, since wireless errors may span all the corrupted packets in- cluding the TCP and IP header. On the other hand, this solution requires an intelligent and sophisticated base station capable of keeping track of all the packets going through it and to note whether a packet has been acknowledged or not. 3.4 Proxy Solution 3.4.1 Proxy Overview A different approach to improve TCP over wireless is to introduce a new con- trol structure between the server and the terminal. This new element for wire- less systems is the proxy. The functions and goals of a proxy can take many forms. Some proxies are mainly intended as HTTP caching devices, while oth- ers may serve as security ”watchdogs”, preventing user access to improper www sites. Yet another feature could be load balancing, where the proxy in- telligently chooses a mirror site when the traffic is too heavy. The list goes on.
  • 60. 3.4. P ROXY S OLUTION 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).
  • 61. 46 C HAPTER 3. E NHANCING TCP OVER WIRELESS 4. The proxy forwards the packet to the server, now announcing itself as the sender. 5. The server receives the request and produces a response, which it sends back to the source (i.e. the proxy). 6. The proxy receives the response, looks up the client connection from its mappings and forwards it to the client, announcing itself as the sender. As the proxy performs an application level service, the IP header of the packets will change when passing through the proxy, giving the proxy as the sender. Hence, no node on the path between the proxy and the server will not be able to see the client. Still, however, the server is visible to everyone. 3.4.2 Using Radio Network Feedback to Improve TCP Perfor- mance over Cellular Networks A new control structure is proposed to improve user experience of wireless Internet because the large end-to-end round-trip time (RTT) that is common in wireless networks makes the control problem even harder [36][37][38]. For high-bandwidth and long-delay networks, TCP throughput is limited by the maximum TCP window size, which is less than or equal to 64 KB. The expo- nential back-off, slow-start, and congestion avoidance mechanisms in TCP fur- ther limit the throughput and may also force over-dimensioned layer-2 buffers in the cellular system. A proxy-based scheme can improve both the user experience of wireless Internet, and the utilization of existing infrastructure. To give a general idea of this scheme it’s possible to contemplate the presence of one proxy that resides between the Internet and the cellular system. Whit an appropriate custom pro- tocol between the radio network controller (RNC) of the cellular system and the proxy, the data-link layer within the RNC provides information to the transport layer within the proxy, this communication is called Radio Network Feedback (RNF) [39]. The procedure is this: when the radio link bandwidth changes, the RNC sends an RNF message with the radio connection’s new bandwidth to the proxy. The proxy then takes appropriate action by adjusting the TCP window size. The computation of a suitable window size in the proxy also
  • 62. 3.4. P ROXY S OLUTION 47 Figure 3.1: Proposed architecture takes into consideration the queue in the RNC, which needs to be controlled at a suitable level due to delay fluctuations and other uncertainties in the cel- lular system. Note that the proposed scheme does not require any changes to the terminals or to the Internet server, but they may utilize any of the standard TCP protocols. The architecture of the scheme that we want to use is illustrated in the Fig.3.1. The mobile terminal on the left downloads a file from the server on the right, via a operator’s radio access network that it is composed by two special nodes: an RNC that is responsible for allocating bandwidth to user con- nections, and a proxy which acts as a gateway between the operator’s network and the internet. Two TCP connections have been established: one between the terminal and the proxy and one between the proxy and the server. The endpoints use standard TCP to communicate with the proxy. The proxy, on the other hand, adapts its sending rate towards the terminal using a custom control algorithm, which is aided by extra information provided by the RNC. The RNC sends RNF messages to the proxy, including information about the current bandwidth allocation and the queue length in the RNC. The RNF mes- sages are sent every time the bandwidth changes, and also periodically with a relatively long period time. In a typical scenario, a mobile terminal wants to request a file from a remote web server. It initiates a TCP connection to the proxy, and sends an HTTP request. The proxy receives the request, initiates another TCP connection to the server, and forwards the request. Upon receipt of the request, the server begins to send the file according to its standard TCP algorithm. The transferred data is received by the proxy, where it is buffered and then forwarded to the
  • 63. 48 C HAPTER 3. E NHANCING TCP OVER WIRELESS mobile terminal as soon as possible. Note that the bottleneck for the end-to- end connection in most practical situations is in the cellular system. Even if there is a TCP connection between the proxy and the terminal, the proxy does not need to utilize the standard TCP congestion control. The idea with a proxy- based scheme is to modify the control of the proxy’s sending rate to adapt to the varying wireless conditions. In this way, the TCP connection to the remote server does not suffer from the effects of the wireless link, and the connection to the mobile terminal is tailored to the current link characteristics. The proxy controls the sending rate by adjusting the TCP window size based on information about the available radio link bandwidth and the RNC queue. For this reason the proxy permits an event-triggered feedforward mech- anism, based on the bandwidth changes and a time-triggered feedback mech- anism based on the RNC queue size. The objective is to achieve a high utiliza- tion of the radio link and maintain the RNC queue close to a reasonably small reference value qref , by controlling the sending rate of the proxy. Like in stan- dard TCP, the proxy use a window-based algorithm, but unlike standard TCP, it takes advantage of explicit information provided by the RNC. Consider the following notation: • b is the bandwidth of the radio link; • τf is the time it takes for a packet that is sent by the proxy to reach the RNC; • τb is the time it takes for a packet that is forwarded by the RNC to reach the terminal, and for the corresponding acknowledgement to get back to the proxy; • q is the queue length at the RNC; • The RTT of the cellular network, excluding queueing delay at the RNC, is: τ = τf + τb ; q • The RTT, pondering queueing delay at the RNC, is: τ + b ; • ω is the current window size at the proxy. The control structure is illustrated in Fig. 3.2. The control signal is the non-
  • 64. 3.4. P ROXY S OLUTION 49 Figure 3.2: Control Structure negative window size w, which indirectly determines the sending rate. The network provides the proxy controller with two kinds of information. The con- trol structure, with feedforward of radio bandwidth b, and feedback of queue length q. Bandwidth variation act as a disturbance which can be measured but not affected, which is why this part of the controller is a feed-forward com- pensator. When the available bandwidth over the radio channel is changed, the RNC sends an RNF message to the proxy to inform it about the new band- width. The controller uses an event-triggered feedforward mechanism that takes advantage of this information, and resets the window size to a new value: ω = ˆτ + qref bˆ where ˆ and τ are respectively the estimate of propagation delay τ and the new b ˆ 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
  • 65. 50 C HAPTER 3. E NHANCING TCP OVER WIRELESS proxy and the terminal. Even if the traffic is controlled as described above, the amount of buffered data in the proxy can increase considerably, leading to scalability problems when applying the proposed proxy controller in prac- tice. It is necessary to set a limit on the amount of data per connection that the proxy can buffer. The remote server should thus be informed when the proxy is running out of space. The connection between the server and the proxy uses the receive window sent from the proxy to adjust the server sending rate. A reasonable buffer size for a TCP flow is the bandwidth-delay product for con- nection between the server and the proxy. The performance of the proxy setup was evaluate in terms of the average link utilization and the time to serve a user (TTSU). The TTSU is defined as the time elapsed from when the connection is established (SYN packet sent by the request) until the last data packet is received at the terminal. Outages and disconnections, which are typical for wireless connections, affect the performance of TCP connections considerably. For the proxy setup, an out- age only increases the TTSU by the precise duration of the outage. The proxy controller is able to successfully resume the transmission immediately after the terminal is reconnected. Therefore, the improvements are larger when (possi- bly many) small files are transferred. Many outages and bandwidth variations also worsen the performance for the no proxy scenario, compared to the new proxy solution. The new setup, that with the utilize of proxy, reduces time to serve users, sub- stantially increases radio link utilization and decreases the needed buffer size in the RNC. The proposed control architecture might substantially improve the user experience of wireless Internet. The proposal is transparent to both and points, so no modifications need to be done to the terminal or the server. 3.4.3 Objective of the proxy solution The proxy-solution is based on the information received from the RNC, whose aim is to help the proxy draw an accurate picture of the current wireless link characteristics. Most TCP versions try to estimate the available bandwidth by means of RTT measurement and loss events, or, like TCP Vegas, by computing
  • 66. 3.4. P ROXY S OLUTION 51 an estimate of the queue length at the bottleneck. However, in the case of HS- DPA, such information is already known by the Node B, because it receives the signalling information in uplink with the HS-SCCH channel, and it can be for- warded to the proxy. The RNC encapsulates all the necessary information in a Radio Network Feedback message (RNFMessage), and sends it to the proxy via UDP. The main reason to use UDP is to make the information available as soon as possible, and to reduce the overhead introduced by a reliable protocol (such as TCP), in order to quickly adapt to link changes. The RNFMessage includes the available bandwidth for a flow and the queue length at the bottleneck, and it is sent every time the bandwidth changes. To sum up, from the servers point of view, the servers send the requested files to the destination at the highest speed that the IP network can support, according to their own implemented TCP algorithms. From the mobile terminals point of view, they receive the requested data as fast as the wireless link allows, and they acknowledge and deliver the data to the applications. The proxy is located in the middle, and its own TCP mechanisms are responsible for adapting the connection adequately. It receives data from the servers and buffers it, and sends it to the destinations simultaneously. At the same time it receives the RNFMessages from the RNC and computes the appropriate parameters accordingly.
  • 67. 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
  • 68. 54 C HAPTER 4. 3G N ETWORK G AMING 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
  • 69. 4.2. IMS AND G AMING S ERVICE 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-
  • 70. 56 C HAPTER 4. 3G N ETWORK G AMING 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
  • 71. 4.2. IMS AND G AMING S ERVICE 57 network connectivity and general support for gaming. • Game Provider is a human, an organization, or a collection of humans and/or organizations that own a game application, or have the right to use and publish a game application (e.g. Tetris, Quake, Age Of Empires). The Game Provider publishes and distributes games via the Gaming Ser- vice. • Community Service consists of different services that enable the players to communicate. Examples for Community Services are: Instant/Voice/Mul- timedia Messaging, Chat or Conferencing. • Game Information Service contains functionalities for the management of game related information. The 3GPP IP Multimedia Subsystem (IMS) is a standardized infrastructure, able to run services of all categories while allowing ease of inter-working be- tween (mobile) operators. The IMS is not part of R’99 but the so-called Phase1 IMS is specified in 3GPP Release 5 and contains the basic mechanisms for mul- timedia session management. The 3GPP Release 6 adds many new capabilities to the system and the IMS. Examples are: Presence, Conferencing, Messaging, WLAN-Interworking, and Group Management. The IP Multimedia Subsystem (IMS) is an extension of the 3GPP packet-switch- ed core network. It uses SIP to setup, maintain and terminate voice and multi- media sessions. The IMS network architecture is specified in [41] The IMS network architecture is composed by the following elements. The Call Session Control Function (CSCF) in IMS is needed for session manage- ment and support for QoS provisioning in the core network. The CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF). The P-CSCF is the first contact point for the UE (User Equipment = terminal) within the IMS; the S-CSCF actually handles the session states in the network; the I-CSCF is mainly the contact point within an operator’s network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator’s service area. The Home Subscriber Server (HSS) is the master database for a given user. It is
  • 72. 58 C HAPTER 4. 3G N ETWORK G AMING 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
  • 73. 4.2. IMS AND G AMING S ERVICE 59 is associated at least with one game session. A Game Server may be capable to provide more than one game session. A Game Server can initiate a request towards the Game Focus to a setup game session and to be associated with it, or the Game Focus can initiate a request to some pre-configured Game Server to start and associate a game server with a game session. The Game Client(s) may learn about games and game session by using game presence information. A Game Client manages its participation in game ses- sions via the Game Focus using the SIP protocol. The central component of Gaming Service architecture is the Game Focus. The Focus maintains a SIP signaling relationship with each player in the game. The Focus has access to the game policy (composed of membership policy, mes- saging policy and game presence policy, proxy policy), an instance of which exists for each game. The game policy can be thought of as a database that contains policy information about how the focus should operate and may also contain player authorization information. It is the responsibility of the focus to enforce those policies. The game Focus may function as a proxy and forward a received SIP-Request to another Game Focus. This may occur according to the game server state, game client capabilities and/or the user location, which may be retrieved throu- gh a query to the HSS by the Game Focus. A game Focus may provide proxy functionalities for access to IMS Messag- ing capabilities that are supported in a game. A user who wishes to access to those services initiates a SIP request with an indicator for the messaging ser- vice targeted to the game Focus. The Game Focus will enforce the messaging and proxy policy installed for that user and forwards the request accordingly. Similarly, the Game Focus may provide proxy functionalities for access to game presence information. Game presence information may be provided by the IMS Presence services. Whenever there is a need to inter-work with the IMS Presence Service for game and player related presence information, the focus takes the role of the so-called presence user agent. The proxy function of the Game Focus will be used in the following situa- tions: • Forwarding SIP-requests for joining a game to another game Focus, e.g.
  • 74. 60 C HAPTER 4. 3G N ETWORK G AMING 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
  • 75. 4.3. P ERFORMANCE E NHANCING P ROXY FOR I NTERACTIVE 3G N ETWORK G AMING 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.
  • 76. 62 C HAPTER 4. 3G N ETWORK G AMING 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,
  • 77. 4.3. P ERFORMANCE E NHANCING P ROXY FOR I NTERACTIVE 3G N ETWORK G AMING 63 hence focusing on design of network-optimized differential coding to produce small but loss-resilient packets; ii) is tailored WING for HSDPA of 3G wireless networks, optimizing perfor- mance by intelligently configuring parameters of the RLC layer. This approach is proxy-based, such that it can achieve a gaming optimization exclusively for 3G networks. HSDPA of UMTS Release 5, improves upon Release 4 with numerous low- er-layer optimizations. It is important to note that the RLC-layer buffers upper layer service data units (SDU) on a per-session basic, IP packets in this case, and segments each SDU into smaller protocol data units (PDU) and await transmis- sion at lower layers. RLC can discard SDUs using a method of retransmission- based discard (RBD), an SDU can be discarded before successful transmission. In a nutshell, an SDU is discarded if a predefined maximum number of retrans- missions B has been reached before successful transmission of a PDU belong- ing to the SDU. An approach of prediction used at a network game client to predict locations of other game players in the virtual game world entails the need of defining a new type of transport data called variable deadline data. The usefulness (utility) of a game datum is inversely proportional to the time it requires to deliver it. This relationship between utility and transmission delay is the behavioral result of a commonly used game view reconstruction procedure at a game client called dead-reckoning[45]. The three optimizations of gaming proxy WING [43] in details are: 1)Proxy- based congestion control, 2)Optimizing RLC configuration, 3)Loss-optimized Differential coding. 1) Traditional congestion control algorithms like TCP-friendly Rate Con- trol (TFRC) space outgoing packets with interval Tcc as a function of estimated packet loss rate (PLR), RTT mean and RTT variance due to wired network con- gestion. Split connection offers the possibility to avoid unnecessary rate re- duction due to erroneous perception of wireless losses as network congestion by completely shielding sender from packet losses due to wireless link failures. Moreover, by performing TFRC in the server-WING connection using only sta- ble wired network statistics, split connection shields the server-WING connec-
  • 78. 64 C HAPTER 4. 3G N ETWORK G AMING 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 P DU is the PDU loss rate, it is possible to calculate the proba- bility density function (pdf) of PDU transmission delay Φ(φ) which is assumed 2 to have mean mφ and variance σφ . First, the expected number of PDUs frag- SSDU mented from an SDU is N = SP DU . For a given B, the expected SDU loss rate lSDU can be written simply: B i−1 PP DU = P DU (1 − P DU ) i=1 N lSDU = 1 − PP DU where PP DU 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 dq t q SDU and transmission delay dSDU . Queuing delay dSDU is the delay experienced by an SDU while waiting for head-of-queue SDUs to clear due to early termination or delivery success. dt SDU is the expected wireless medium transmission delay given the SDU is successfully delivered. dt SDU is easier and can be calculated [43] as: B 1 i−1 XP DU = i P DU (1 − P DU ) PP DU i=1 dt SDU = N mφ XP DU where XP DU is the expected number of PDU (re)transmissions given PDU de- livery success. To calculated dq SDU , 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 σq . The dq 2 SDU can be calculated [43] as: 2 σq λq mq (1 + m2 ) dq SDU = q mq 2(1 − λq mq )
  • 79. 4.3. P ERFORMANCE E NHANCING P ROXY FOR I NTERACTIVE 3G N ETWORK G AMING 65 In the application, λq is the rate at which game data arrive at WING from the server, which is assumed to be known. mq is the mean service rate for both cases of SDU delivery success and failure and can be derived as follows: N 1 B i−1 YSDU = (B + (i − 1)XP DU ) P DU PP DU lSDU i=1 mq = (1 − lSDU )dt SDU + lSDU mq YSDU 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 2 service rate σq for our application is: 2 2 2 σq = (1 − lSDU )N 2 XP DU σφ + lSDU YSDU σφ 2 2 We can now evaluate expected queuing delay dq SDU , from which we evaluate expected delay dSDU . Optimal B is one that maximizes: (1 − lSDU )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
  • 80. 66 C HAPTER 4. 3G N ETWORK G AMING 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.
  • 81. 4.4. G AME T RANSPORT P ROTOCOL (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
  • 82. 68 C HAPTER 4. 3G N ETWORK G AMING 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.
  • 83. 4.4. G AME T RANSPORT P ROTOCOL (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.
  • 84. 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
  • 85. 72 C HAPTER 5. S IMULATIONS 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
  • 86. 5.1. S IMULATOR : N S -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.
  • 87. 74 C HAPTER 5. S IMULATIONS AND RESULTS 5.2 EURANE Although ns-2 doesn’t provide appropriate modules for UTRAN/UMTS, some contributed work was developed such as Pablo Martin and Paula Ballester’s contributed modules, Alfredo Todini and Francesco Vacirca’s UMTS module for ns and EURANE [49]. Within those modules EURANE is the only one which provides the support of HS-DSCH. The simulator EURANE (Enhanced UMTS Radio Access Network Exten- sions for ns-2) is one of the main of SEACORN [50] (Simulation of Enhanced UMTS Access and Core Networks), which investigates enhancements to UMTS for RAN and Core Network through simulation. EURANE is an end to end extension which adds three extra radio link nodes to ns-2, the Radio Network Controller (RNC), Base station (BS) and the User Equipment (UE). These nodes support four kinds of transport channels, include common channels FACH and RACH, dedicated Channel DCH, and high speed channel HS-DSCH. In EU- RANE, R99 channels, i.e. DCH, RACH and FACH, use standard error model provided by ns-2, for HS-DSCH, a pre-computed input power trace file and a block error rate (BLER) performance curve are introduced to generate the error model of high-speed channel. The Node RNC, BS and UE are all implemented from new object class, namely UMTSNode class. Based on different configurations, different kinds of classifiers and link objects are used to compose different nodes. The most important parameter should be determined first is the node type, after that, other peculiarity of this node type can be configured further. Each UMTS node has zero or more UMTS network interfaces (NIF) stacks, composed of objects representing different layers in the stack, the major com- ponents being RLC, MAC and physical layer objects. Channels are connected to the physical layer object in the stack. NIFs are also important for packet tracing since the common methods in ns-2 can not trace the traffic within radio links. Typically, NIF stacks at the UE will have all of these objects but those at the BS will only have MAC layer and physical/channel layer objects. At the RNC, each NIF stack will only be composed of one RLC layer object.
  • 88. 5.3. O BJECTIVE 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
  • 89. 76 C HAPTER 5. S IMULATIONS AND RESULTS possible, by taking advantage of feedback information provided by the net- work itself. The main idea is to split the connection between a server and a mobile user through the introduction of a proxy, which terminates both con- nections and is capable of adapting its parameters to get the best out of the available resources. The proxy takes advantage of the fact that most of the information that a TCP sender needs to infer in order to perform congestion control, is already known by the radio network. In that case, it can be transmit- ted to the proxy in order to feed its adaptation algorithm, as is the case of the bandwidth available for a determined connection, or the network load. It should add on the performance improvements brought by HSDPA, which provides broadband support for downlink packet-based traffic. It should also overcome the problems that TCP connections face over wireless links. In a typical scenario, such as the simulation scenario, a mobile terminal at- tempts to establish a connection to one of the remote servers. The initial TCP connection establishment packet (SYN) is received by the proxy, which returns the corresponding reply (SYNACK), and the terminal-proxy connection is com- pleted. It also establishes a connection to the specified server, and forwards the initial file request sent by the client. The result is that two different TCP con- nections are established. Upon receipt of the request, a remote server begins to send the file following the traditional TCP algorithms, including Flow and Congestion Control. All the transferred data is received by the proxy, where it is buffered in order to be sent to the mobile terminal as soon as possible. Note that, while the remote server modifies its TCP parameters according to its own TCP implementation, the proxy receives every packet at the highest rate possi- ble and buffers it. Then, it can use whatever TCP parameters it needs in order to adapt the connection to the variable wireless conditions. This way, the TCP connection to the remote server does not suffer the effects of the wireless link, and the connection to the mobile terminal is tailored to the current link charac- teristics. At the same time, it is totally transparent to both endpoints.
  • 90. 5.4. D ESIGN D ECISIONS 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. Terminal Bas Sta e tion RNC Proxy Ser ver 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
  • 91. 78 C HAPTER 5. S IMULATIONS AND RESULTS two separated TCP connections are established, one between the terminal and the proxy, and the other between the proxy and a remote server. The results are compared to those of a basic setup, where there is only a TCP connection from server to terminal, via the RNC. The addressed scenario includes a HSDPA UMTS radio cell covered by a Node-B connect to a RNC. The simulation model consists of a terminal (UE1) that is the reference terminal, and other nine terminal (UE2-UE10) that are ”competitor terminals”. These terminals are all connected to a HS-DSCH (the users are all HS-DSCH user). Reference terminal and competitor terminals are placed in different distances away from the node B in a Rayleigh fading envi- ronment. The simulation model is based on the HSDPA architecture such as indicated in the 3GPP specification, and after we have introduced the proxy entity between remote server and terminal. The wired part of the simulation model consists of a Node B, a RNC, a SGSN, a GGSN, a fixed external node and finally the proxy. The characteristics of connection lines between them are shown in Tables 5.1 and 5.2. Furthermore, over these tables we can see that the average delay at the wired part of the network model is 76 msec. From To Bandwidth Av. Delay Server GGSN 10Mbit 50ms GGSN SGSN 622Mbit 10ms SGSN RNC 622Mbit 0.4ms RNC Node B 622Mbit 15ms Average total delay through the wired part of the model: 76ms Table 5.1: Connection lines between Nodes, without proxy The parameters of HS-DSCH, in all the scenarios, are configured as follow- ing: • Environment: Pedestrian A • Velocity of UE: 3km/h • Distance between Node B and the UE: 450m
  • 92. 5.4. D ESIGN D ECISIONS 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. Terminal Bas Sta e tion RNC Ser ver TCP Figure 5.2: Architectural TCP Reno scenario
  • 93. 80 C HAPTER 5. S IMULATIONS AND RESULTS Terminal Bas Sta e tion RNC Proxy Ser ver 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.
  • 94. 5.5. E XPERIMENTAL 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. Rate (Mbits/s) Round Robin 1.600 Max C/I 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 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
  • 95. 82 C HAPTER 5. S IMULATIONS AND RESULTS same policy. That will take off the priority to use the high speed channel from the user with favorable long-term channel quality. Therefore the throughput it offered is always lower than the other one can provide. For these reasons, in the next simulations we prefer to work with the third kind of scheduler, that is FCDS, so a trade-off between the two extreme meth- ods of scheduling can be achieved. 5.5.2 Proxy Performance In the following set of simulations, we evaluate the improvements that the proxy-solution introduces in the HSDPA and 3G networks compared to the TCP Reno solution. In order to model the proxy behaviour, as well as the intermediate elements, several C++ modules were added to EURANE. A new TCP sink was devel- oped in order to model a UMTS terminal with variable processing delay. This includes an application which is in charge of forwarding packets between the two TCP connections, as well as a TCP Reno Agent for the server-proxy con- nection, and a RNFProxy Agent for the TCP connection towards the terminals. The application simply forwards packets in both directions. The RNFProxy Agent is the modified TCP Agent in charge of adapting the parameters of the TCP connection between terminals and proxy, and include most of the proxy functionality. First of all, we have to evaluate the maximum data rate for the reference user within the HSDPA network during the simulation’s interval (see Figure 5.5). All the scenarios, and the simulations that we realized, are compared with this maximum rate. Specifically, Fig.5.5 shows the maximum data rate that the reference user can theoretically experience from the base station toward the UE. Such data rate is the link bandwidth. Figures 5.6 and 5.7 show the results for two different setups. Here, we can compare performance of the proxy to performance of TCP Reno. In both cases, a TCP connection is established in order to download a 32Mb file, which should be big enough to test the proxy behavior versus TCP’s Slow Start phase. In both figures 5.6 and 5.7, the transmission rate is plotted as a function of time, for the proxy setup (which adapts its initial window to the
  • 96. 5.5. E XPERIMENTAL RESULTS 83 Rate (Mbits/s) 2.200 Link Bandwidth 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.5: Link Bandwidth Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.6: Throughput Reno scenario
  • 97. 84 C HAPTER 5. S IMULATIONS AND RESULTS Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.7: Throughput Proxy solution Rate (Mbits/s) 2.200 Link bandwidth Reno 2.000 Reno + Proxy 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.8: Reno vs. Proxy
  • 98. 5.5. E XPERIMENTAL RESULTS 85 current link bandwidth), as well as TCP Reno. The plots shows the proxy’s throughput and the TCP-Reno’s throughput compared to the link-bandwidth. The figures show a significant improvement of performance when the proxy is used, compared to TCP Reno. The reason is that a TCP sender does not have information about the available bandwidth of the path, so it has to begin the transmission with the lowest rate possible. By the contrary, the proxy can set its initial value to fully utilize the bandwidth assigned to the connection, since such a value is known. The improvement is even larger if TCP’s Slow Start Threshold is set to a low value (such as 20) in the Reno senders. The reason is that, in such a case, the TCP sender enters an early Congestion Avoidance Phase, which reduces even more the increase of the transmission rate. To obtain high values of throughput in the Reno scenario we set the TCP’s Slow Start Threshold to 62. Figure 5.9 shows the congestion windows of the sender for Reno scenario as obtained by simulation. Packets 65 Cwnd 60 55 50 45 40 35 30 25 20 15 10 5 0 Time (s) 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-
  • 99. 86 C HAPTER 5. S IMULATIONS AND RESULTS tion Avoidance phase. The Sender remains in this phase until occurs a con- gestion event. In this case, we have a duplicate acknowledgement, so Reno TCP enters in the Fast retransmit and Fast recovery state. When the third du- plicate ACK is received, the Reno TCP transmitter sets ssthresh to one half of the current congestion window (cwnd) and retransmits the missing segment. The cwnd is then set tossthresh plus three segments (one segment per each du- plicate ACK that has already received). Then, cwnd can be increased by one segment on reception of each duplicate ACK if it continues to arrive after fast- retransmission. This allows the transmitter to send new data when cwnd is increased beyond the value of the cwnd before the fast-retransmission. After that, if arrive an ACK that acknowledges all outstanding data sent before the duplicate ACKs then, the cwnd is set to ssthresh so that the transmitter slows down the transmission rate and enters the linear increase phase. By the con- trary in our scenario we have that ACK do not arrive, and at about 2,5 seconds there is a timeout. In this way the cwnd is set to one and triggers again the slow start phase. In the proxy scenario, we have two congestion windows, one for the proxy and another for the TCP sender. In the figure ?? we can see the congestion windows for the proxy (on the left), and the congestion window of the Reno Server, when the slow start threshold to the sender is set to 20. The TCP sender enters an early Congestion Avoidance Phase, but now, this is not a problem, because there is the proxy splitting the connection. The proxy set its congestion window value to pipe capacity (product between bandwidth and delay) plus the value of the queue on the RNC. The proxy receive RNFMessages every time there is a bandwidth variation. These messages make the proxy compute the cwnd value, and continue sending with a new transmission rate. In this way the proxy can always transmit to the available maximum rate. Figure 5.11 shows the congestion window of Reno Server for Proxy scenario, but in the same scenario there is also another congestion windows, that is the congestion window od RNFProxy (see Fig.5.10) Now, we want to test, the reliability of the proxy control algorithm with respect to UDP packets losses. UDP packets loss or corruption in the link from the RNC to the Proxy is possible. Therefore, retransmissions of RNFMessages
  • 100. 5.5. E XPERIMENTAL RESULTS 87 Packets Cwnd 35 30 25 20 15 10 5 0 Time (s) 0.0 5.0 10.0 15.0 Figure 5.10: Congestion Window of RNFProxy for Proxy scenario Packets 70 Cwnd 60 50 40 30 20 10 0 Time (s) 0.0 5.0 10.0 15.0 Figure 5.11: Congestion Window of TCP Reno Server for Proxy scenario
  • 101. 88 C HAPTER 5. S IMULATIONS AND RESULTS have to be dealt with in some other way. For that reason, the RNC periodically sends a new RNFMessage to the proxy, so if one message is lost the necessary information will arrive within the next period. The figures 5.12 and 5.13 show the results of the reliability test, where the setup is analogous to the previous case. Now we have only simulated the situation where the RNFMessages do not arrive to the proxy from the RNC, because during the simulation interval all UDP packets are lost in the link. We can see that the RNF-proxy don’t work very well, and in this situation we have an average value of the throughput that is about 975Kbps, whereas if there were not UDP packets loss, there is a average value of the throughput that is about 1111Kbps. Note that this is an especially unfavorable case, and the probability of losing and corruption of only one packet is very small, so our simulation scenario is unrealistic, and the simulations only aims to test the algorithm reliability. Rate (Mbits/s) 2.200 Link bandwidth Reno + simple proxy 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 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.
  • 102. 5.5. E XPERIMENTAL RESULTS 89 Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 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
  • 103. 90 C HAPTER 5. S IMULATIONS AND RESULTS Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.14: Snoop Agent in TCP Reno scenario Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.15: Eifel Agent in TCP Reno scenario
  • 104. 5.5. E XPERIMENTAL RESULTS 91 was proposed to deal with retransmission ambiguity (spurious timeouts and spurious fast retransmit cause the so called retransmission ambiguity). So, it uses the timestamp option in the TCP header to assign a number to the trans- mitted segment. The timestamp value, the current congestion-window-size, and the slow-start threshold are stored by the sender. Once an ACK is received, the sender compares the timestamp values of the ACK and the retransmitted segment. If the ACK-timestamp value is less than that of retransmitted seg- ment, the sender concludes that a spurious retransmission occurred. There- fore, it resumes the transmission with new data and stores the congestion- windows size and the slow-start threshold values before the spurious retrans- mission. The main advantage is that it suppresses duplicate acknowledgments and timeouts for TCP segments lost and retransmitted locally, thereby avoid- ing unnecessary fast retransmissions and congestion control invocations by the sender. In this way the Reno sender can transmit with higher rate and with less congestion events. In Figures 5.16 and 5.17 we want to compare performance of the proxy with that of the Reno scenario and implementation of Snoop and Eifel. We obtain that the average throughput is better in the RNFProxy solution than in the Snoop and Eifel solution. Rate (Mbits/s) 2.200 Link bandwidth Reno + Snoop 2.000 Reno + Proxy 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.16: Comparison between Snoop and Proxy
  • 105. 92 C HAPTER 5. S IMULATIONS AND RESULTS Rate (Mbits/s) 2.200 Link bandwidth Reno + Eifel 2.000 Reno + Proxy 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 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.
  • 106. 5.5. E XPERIMENTAL RESULTS 93 Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.18: Proxy with Snoop Agent Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.19: Proxy with Eifel Agent
  • 107. 94 C HAPTER 5. S IMULATIONS AND RESULTS Rate (Mbits/s) 2.200 Link bandwidth Throughput 2.000 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.20: Definition both Snoop and Eifel in RNFProxy scenario Rate (Mbits/s) 2.200 Link bandwidth R. + Proxy + S. + E. 2.000 R. + Proxy 1.800 1.600 1.400 1.200 1.000 0.800 0.600 0.400 0.200 0.000 Time (s) 0.0 5.0 10.0 15.0 Figure 5.21: Comparison between Proxy and Proxy with TCP enhancement protocols
  • 108. 5.5. E XPERIMENTAL RESULTS 95 Scenario Average throughput(Kbps) Reno 624 Eifel 629 Snoop 666 Proxy 1110 Proxy+Eifel 1111 Proxy+Snoop 1130 Proxy+Eifel+Snoop 1131 Table 5.3: Average Throughput in different scenarios 5.5.4 Buffer Size The sizes of buffers in RNC and Node B are parameters influencing how the schedulers behave in TCP traffic model, and these sizes limit the throughput of the system. When the buffer size in RNC is big enough, data always queue in RNC even though TCP connection is ended, so it is not very necessary to study this buffer. We focus on the buffer size in MAC-hs in Node B and check how different schedulers influence TCP performance when we adjust its size. In this section, all buffer size means the size of buffer in MAC-hs. In EURANE, the Node B buffer size can be changed. The default value is 250, as we used in all the simulations we have discussed above. Analyzing the system throughput for different value of node B buffer size, we can summarize how buffer size in Node B matters in TCP service. As the buffer size increasing, the system throughput increases. But there is a trade-off value. When buffer size increases, there are more data waiting at Node B. It will take a longer time queuing there so that the delay increases too. IP packets arriving at RNC are first stored in an input buffer before they are segmented into radio blocks and transmitted to the Node B via the Iub interface. Additionally, the RLC layer may protect the transmitted radio blocks with an ARQ mechanism if the connection is to be operated in Acknowledged Mode (AM). The transmission of data on the Iub-interface is regulated by a flow control mechanism. In the Node B, the radio blocks are stored in priority queues, before they are concatenated to larger MAC frames, protected by the
  • 109. 96 C HAPTER 5. S IMULATIONS AND RESULTS HARQ mechanism and finally transmitted on the air interface. In a multi-user scenario, a scheduler in the Node B has to decide which users are allowed to transmit in each scheduling round. Among others, this decision may depend on the current channel state towards each terminal (channel aware scheduling), on the QoS parameters of each connection (QoS aware scheduling), or on a combination of both. Signaling delays and measurement inaccuracies of the Iub flow control may lead to long queuing delays in the Node B. If the flow control detects a buffer congestion in the Node B, it will not allow any further radio blocks to be transmitted from the RNC until the congestion has cleared. This will also block uplink RLC status report messages, not allowing them to benefit from the prioritization in the Node B. For this reason, when one of the prioritization schemes is active, we will override the flow control decision in such a way that we always allow the transmission of uplink RLC status report messages from the RNC to the Node B regardless of the Node B buffer fill level. There are some distinct behaviors at the base station for different kind of schedulers and different buffer sizes. With FCDS the delay and throughput increase equitably while buffer size increasing. When the buffer size is not big enough, FCDS causes more delay in transmission. As buffer size rising, FCDS can offer better throughput without gain much more delay. Thus, it is important to adjust buffer size into larger when operator designs the scheduler as FCDS in TCP traffic. The time allotted for this thesis work did not allow me to find an optimum value of the buffer in the Node B.
  • 110. 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
  • 111. 98 C HAPTER 6. C ONCLUSIONS 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
  • 112. 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.
  • 113. 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
  • 114. 102 R EFERENCES [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. a ¨ [21] G. Xylomenos, G. C. Polyzos, M. Saaranen, and P. M¨ honen, 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).
  • 115. R EFERENCES 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.
  • 116. 104 R EFERENCES [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
  • 117. R EFERENCES 105 [47] E. Altman and T. Jim´ nez, NS Simulator for beginners, Univ. de Los Andes, e M´ rida, Venezuela and ESSI, Dec 2003. e [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/

×