Technische Universität Wien
Diplomarbeit
TCP/IP over UMTS
ausgeführt am
Institut für
Nachrichtentechnik und Hochfrequenztechnik
der Technischen Universität Wien
unter der Anleitung von
o. Univ. Prof. Dr. techn. Ernst Bonek
DI Manfred Taferner
durch
Georg Löffelmann
A - 1210 Wien, Eichfelderstraße 17
Wien, im September 2000
Zusammenfassung
Die steigende Nachfrage für mobilen Internetzugang verlangt nach hochdatenratigen,
paketvermittelten Mobilkommunikationssytemen.
Universal Mobile Telecommunications System (UMTS) ist das Mobilfunksystem der drit-
ten Generation und soll 2002 in Betrieb gehen. UMTS bietet Datenübertragungsraten
bis maximal 2048 kbit/s. Die UMTS Funkschnittstelle UMTS Terrestrial Radio Access
(UTRA) basiert auf Direct Sequence Code Division Multiple Access (DS-CDMA). UTRA
bietet paketvermittelte Transportdienste und dynamische Ressourcenzuweisung. Der Ra-
dio Link Control (RLC) Layer an der Funkschnittstelle verfügt über verschiedene Übertra-
gungsmodi: Unacknowledged Mode Data (RLC UMD) mit Fehlererkennung und Acknowl-
edged Mode Data (RLC AMD) mit Fehlerkorrektur, wobei, basierend auf Negative Ac-
knowledgements (NACKs), fehlerhafte Daten neu übertragen werden. UMTS stellt auch
optionale TCP/IP Header-Kompression für die paketvermittelten Datendienste bereit.
Das Standard Transportprotokoll für die fehlerfreie Datenübertragung über das Internet
ist das Transmission Control Protocol (TCP) mit einer auf Acknowledgements (ACKs)
basierenden Fehlerkorrektur durch Anzeige korrekt empfangener Daten. TCP setzt auf
dem Internet Protocol (IP) auf.
In dieser Diplomarbeit beschreibe ich die Simulation von Datenübertragungen zwischen
einem herkömmlichen Internet-Server und einer UMTS Mobilstation. Der TCP Durchsatz
wird für variierende Blockfehlerraten (BLER) am Transportkanal für Transportdienste mit
12.2 kbit/s, 64 kbit/s, 144 kbit/s, 384 kbit/s und 2048 kbit/ ausgewertet. Die maximal
erlaubte BLER liegt im Bereich von ca. 10% für RLC AMD und etwa 1% für RLC UMD.
Der TCP Gesamtdurchsatz beim 64 kbit/s Transportdienst steigt bei Aktivierung der
Header-Kompression mit RLC AMD, fällt aber für RLC UMD unter den Wert, der
ohne Header-Kompression erreicht wird. Für den 384 kbit/s Transportdienst wurden ver-
schiedene Verkehrsszenarien, darunter gleichzeitige FTP Downloads, gleichzeitige FTP Up-
und Downloads sowie HTTP Web Browsing, ausgewertet. Die Dynamik des Flußkontrol-
lalgorithmus von TCP führt zu Durchsatzergebnissen unter dem theoretischen Maximum.
Ich komme zu dem Schluß, daß die derzeit am häufigsten verwendete TCP Reno Implemen-
tation nicht optimal über UMTS Transportdienste bei hohen Datenraten arbeitet. Neuere
Implementationen, wie TCP Vegas, sollten hier den Durchsatz erhöhen. Die Verwendung
von WindowScaling und Selective Acknowledgements (SACKs) ist für hohe Datenraten
auf der UMTS Funkschnittstelle zwingend notwendig.
i
Abstract
The rising demand for mobile Internet access requires mobile telecommunications systems
with the ability to handle packet switched data at high data rates.
Universal Mobile Telecommunications System (UMTS) is the third generation mobile radio
system and is expected to launch in 2002. UMTS provides raw data rates for packet
switched data of up to 2048 kbit/s. The UMTS radio interface UMTS Terrestrial Radio
Access (UTRA) is based on Direct Sequence Code Division Multiple Access (DS-CDMA).
UTRA provides transport services for the packet switched domain and dynamic allocation
of resources. The Radio Link Control (RLC) layer of the UMTS radio interface provides
different modes for transmission of packet switched data: Unacknowledged Mode Data
(UMD), providing error detection, and Acknowledged Mode Data (AMD), providing error
correction by retransmitting corrupt data based on Negative Acknowledgements (NACKs).
UMTS packet switched data services also provide optional TCP/IP header compression.
The standard transport protocol for reliable transmission of data on the Internet is the
Transmission Control Protocol (TCP) with an error correction based on Acknowledgements
(ACKs), indicating valid received data. TCP operates on top of the Internet Protocol (IP).
In this thesis, I will describe simulations of data transmissions between a conventional
Internet server and a UMTS User Equipment (UE). TCP throughput is evaluated for
varied block error ratios (BLER) on the transport channel for transport services with data
rates of 12.2 kbit/s, 64 kbit/s, 144 kbit/s, 384 kbit/s and 2048 kbit/s. The maximum
allowed BLER is in the range of about 10% for RLC AMD and about 1% for RLC UMD.
The overall TCP throughput for the 64 kbit/s transport service is increased if header
compression is activated when using the RLC AMD mode. However, a decrease below the
value evaluated without header compression is observed for the RLC UMD mode. Several
traffic scenarios are evaluated for the 384 kbit/s transport service, including simultaneous
FTP downloads, simultaneous FTP up- and download and HTTP web browsing. The
dynamics of TCP’s congestion control algorithm lead to throughput results below the
theoretical maximum.
I come to the conclusion that the, today’s most commonly used, TCP Reno implementation
performs not optimal over UMTS transport services at high data rates. Newer implemen-
tations, like TCP Vegas, should increase overall throughput. The use of WindowScaling
and Selective Acknowledgements (SACKs) is mandatory for high data rates in heavy-loss
environments, like the UMTS radio interface.
ii
Acknowledgement
I wish to express my appreciation to Prof. Dr. Ernst Bonek for his endeavors throughout
the time I wrote this diploma thesis. He encouraged me in many ways and provided
valuable hints on the presentation of topics and the English Language.
I want to thank all members of the Mobile Communications Group for their best care and
attention and numerous constructive discussions.
Special thanks go to my supervisor DI Manfred Taferner. He had great patience in teaching
me the mysteries of the simulation software and was always supportive in an exemplary
way.
He shared his work on evaluation of TCP/IP data transmission with the simulation soft-
ware, which was of great help and provided many insights. He also had very helpful
suggestions when proof reading my thesis.
I would like to dedicate this diploma thesis to my parents. You never lost faith in what I
did and it is your singular support I admire with great respect.
iii
Contents
1 Introduction
1
1.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 UMTS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3 UMTS Protocol Architecture
. . . . . . . . . . . . . . . . . . . . . . . . .
5
2 UTRAN Protocol Architecture
7
2.1 Packet Data Convergence Protocol
. . . . . . . . . . . . . . . . . . . . . .
7
2.2 Radio Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.1 Unacknowledged Mode Data, UMD . . . . . . . . . . . . . . . . . .
11
2.2.2 Acknowledged Mode Data, AMD . . . . . . . . . . . . . . . . . . .
12
2.3 Medium Access Control
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.1 MAC-c/sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.2 MAC-d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3 TCP/IP Protocol Stack
18
3.1
IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2.1
Sliding Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.2 Retransmission Timer
. . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.3
Slowstart and Congestion Avoidance
. . . . . . . . . . . . . . . . .
24
3.2.4 Fast Retransmit and Fast Recovery . . . . . . . . . . . . . . . . . .
26
3.2.5 Delayed Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.6 Window Scaling for Long, Fat Networks
. . . . . . . . . . . . . . .
27
3.3 Performance Issues and Influences . . . . . . . . . . . . . . . . . . . . . . .
28
3.3.1
IP Maximum Transmission Unit . . . . . . . . . . . . . . . . . . . .
28
3.3.2 TCP Maximum Segment Size . . . . . . . . . . . . . . . . . . . . .
28
3.3.3 TCP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3.4 UMTS PDCP Header Compression . . . . . . . . . . . . . . . . . .
29
iv
CONTENTS
v
3.3.5 UMTS RLC Mode . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3.6 UMTS MAC Scheduling and Physical Layer Transmission Format .
32
3.3.7 External Packet Data Network . . . . . . . . . . . . . . . . . . . . .
32
4 Simulation Model
34
4.1 Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2.1 TCP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.2
IP Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.2.3 PDCP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.2.4 RLC Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.2.5 MAC Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2.6 Channel Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2.7
Internet Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2.8 FTP Server Model
. . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.9 HTTP Traffic Model . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3 Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5 Investigation of Transport Services
44
5.1 12.2 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.2 64 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.2.1 RLC AMD/UMD + TCP/IP Header Compression
. . . . . . . . .
50
5.3 144 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.4 384 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.4.1 RLC AMD + Lossy Internet . . . . . . . . . . . . . . . . . . . . . .
56
5.4.2 RLC AMD + Simultaneous FTP Downloads . . . . . . . . . . . . .
58
5.4.3 RLC AMD + FTP Up- and Download . . . . . . . . . . . . . . . .
63
5.4.4 RLC AMD + HTTP Traffic . . . . . . . . . . . . . . . . . . . . . .
64
5.5 2048 kbit/s
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.5.1 Modifications to TCP Reno . . . . . . . . . . . . . . . . . . . . . .
71
6 Summary and Conclusion
75
A Ptolemy Universes
79
B Frequently Used Acronyms
81
List of Figures
1.1 UMTS functional parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2 UMTS circuit switched and packet switched domain . . . . . . . . . . . . .
4
1.3 UMTS architecture (PS domain)
. . . . . . . . . . . . . . . . . . . . . . .
4
1.4 UMTS protocol stack (PS domain)
. . . . . . . . . . . . . . . . . . . . . .
5
2.1 PDCP service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2 PDCP SDU and PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3 RLC service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4 RLC segmentation and concatenation . . . . . . . . . . . . . . . . . . . . .
10
2.5 UMD peer entities ([TS25.322, Figure 4.3]) . . . . . . . . . . . . . . . . . .
11
2.6 AMD peer entities ([TS25.322, Figure 4.4]) . . . . . . . . . . . . . . . . . .
12
2.7 MAC service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.8 UE side MAC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1 TCP/IP header field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2 Sliding window principle . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3 Slowstart, congestion avoidance and timeout . . . . . . . . . . . . . . . . .
25
3.4 Fast retransmit and fast recovery . . . . . . . . . . . . . . . . . . . . . . .
27
3.5
Interaction of TCP with RLC UMD/AMD, (a) (b)
. . . . . . . . . . . . .
31
4.1 Simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.2 TCP/IP simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3 PDCP simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.4 RLC simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.5 MAC simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.6
Internet simulation model
. . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.7 FTP server model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.8 Payload generator model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.9 HTTP traffic model - file size request distribution . . . . . . . . . . . . . .
42
vi
LIST OF FIGURES
vii
5.1 12.2 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.2 64 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.3 64 kbit/s - TCP throughput (header compression) . . . . . . . . . . . . . .
51
5.4 144 kbit/s - TCP throughput
. . . . . . . . . . . . . . . . . . . . . . . . .
53
5.5 384 kbit/s - TCP throughput
. . . . . . . . . . . . . . . . . . . . . . . . .
55
5.6 384 kbit/s - TCP Throughput (RLC AMD, lossy Internet) . . . . . . . . .
57
5.7 384 kbit/s - TCP and RLC data rate (2 FTP downloads) . . . . . . . . . .
59
5.8 384 kbit/s - TCP and RLC PDF of packet delay (2 FTP downloads)
. . .
60
5.9 384 kbit/s - TCP throughput dynamics (5 FTP downloads)
. . . . . . . .
61
5.10 384 kbit/s - TCP throughput dynamics (lossy, 5 FTP downloads) . . . . .
62
5.11 384 kbit/s - TCP throughput dynamics comparison (5 FTP downloads) . .
63
5.12 384 kbit/s - TCP throughput dynamics (FTP up- and download)
. . . . .
64
5.13 384 kbit/s - TCP and RLC data rate (FTP up- and download) . . . . . . .
65
5.14 384 kbit/s - TCP and RLC PDF of packet delay (FTP up- and download)
66
5.15 384 kbit/s - TCP throughput over file size (HTTP traffic, 1 client) . . . . .
67
5.16 384 kbit/s - TCP throughput over file size (HTTP traffic, 2 clients) . . . .
68
5.17 2048 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.18 2048 kbit/s - TCP data rate comparison . . . . . . . . . . . . . . . . . . .
72
5.19 2048 kbit/s - TCP PDF of packet delay comparison . . . . . . . . . . . . .
73
6.1 Maximum allowed BLER for required throughput ratios . . . . . . . . . . .
77
A.1 FTP scenarios - Evaluation of TCP throughput . . . . . . . . . . . . . . .
79
A.2 HTTP scenarios - Evaluation of TCP throughput . . . . . . . . . . . . . .
80
List of Tables
2.1 PID value allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2 C/T field structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3 Channel coding and transmission format . . . . . . . . . . . . . . . . . . .
16
4.1 Fixed simulation parameter set
. . . . . . . . . . . . . . . . . . . . . . . .
43
4.2 Variable simulation parameter set (default values) . . . . . . . . . . . . . .
43
5.1 UMTS service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.2 12.2 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . .
46
5.3 12.2 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.4 64 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . . .
48
5.5 64 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.6 144 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . .
52
5.7 144 kbit/s - TCP throughput
. . . . . . . . . . . . . . . . . . . . . . . . .
52
5.8 384 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . .
54
5.9 384 kbit/s - TCP throughput
. . . . . . . . . . . . . . . . . . . . . . . . .
56
5.10 384 kbit/s - simulation parameter set (RLC AMD, lossy Internet) . . . . .
56
5.11 384 kbit/s - simulation parameter set (simultaneous FTP downloads) . . .
58
5.12 384 kbit/s - TCP throughput dynamics (5 FTP downloads)
. . . . . . . .
61
5.13 2048 kbit/s - simulation parameter set
. . . . . . . . . . . . . . . . . . . .
69
5.14 2048 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . .
70
viii
Chapter 1
Introduction
Demand for mobile telecommunication systems providing data transmission at high data
rates is growing rapidly. By 2004, one-third of all Europeans are estimated to regularly
use their mobile phones to access Internet services (Forrester Research 1999).
The Global System for Mobile Communications (GSM), standardized by the European
Telecommunications Standards Institute (ETSI) and todays leader in wireless communica-
tions, provides circuit switched (CS) data transmission at maximum rates of 14.4 kbit/s.
Circuit switched means, that a dedicated transmission medium is reserved and engaged
during the entire connection phase, even if no data is actually transmitted. General Packet
Radio Service (GPRS) enhances GSM with packet switched (PS) data transmission capabil-
ities at single user rates of 172.2 kbit/s as stated in [GSM03.64]. Packed switched means,
that data streams are segmented into packets and multiple users may share one single
medium. However, GPRS decreases GSM cell capacity.
The Universal Mobile Telecommunications System (UMTS) is the third generation mo-
bile system. The organizational partners of the Third Generation Partnership Project
(3GPP) cooperate in specifying UMTS. It is based on an evolved GSM core network and
a completely new radio access technology. The current partners forming 3GPP are: Euro-
pean Telecommunications Standards Institute (ETSI), Committee T1, Telecommunications
Technology Association (TTA), Telecommunication Technology Committee (TTC), Associ-
ation of Radio Industries and Businesses (ARIB) and China Wireless Telecommunication
Standard (CWTS).
Since several specifications for UMTS are still subject to further development and discus-
sion, it is here stated that Release 99 (issued in March 00) is used and all implementation
details refer to this issue unless otherwise stated.
1.1 Contribution
The aim of this diploma thesis is analysis and evaluation of TCP/IP performance over
UMTS packet switched data services and is restricted to an FDD mode radio interface and
1
CHAPTER 1. INTRODUCTION
2
its related transmission formats.
End-to-end performance of packet switched data has been evaluated in detail for TCP
connections. Careful attention has been given to the interaction of TCP/IP with UMTS
packet switched data modes and services.
Performance analysis of TCP throughput and the behavior of the TCP/IP protocol stack
for various UMTS transport services and traffic scenarios is performed on a simulation-
based UMTS model environment. The UMTS model developed for this thesis supports
various configurations and uses a simple block error model as the channel model.
UTRAN Protocol Architecture
This chapter explains the basic functions of the protocols defined for UMTS terrestrial
radio access. The functions include header compression of transferred user data, error
detection and error correction on the radio interface and dynamic allocation of resources
for multi-user scenarios.
TCP/IP Protocol Stack
After a short overview on the header structure of TCP/IP, detailed information on TCP
and IP is given. Flow control and known limitations of TCP are described and illustrated.
Three versions of TCP implementations are presented and compared against each other.
Further sections are dedicated to influences of UMTS packet switched data transmission
on the behavior of TCP.
Simulation Environment
The used simulation tool and its structure is shortly described here. The used models for
UTRAN protocols and TCP/IP are visualized with detailed descriptions of their general
function and parameters.
Investigation of Transport Services
This chapter shows the simulation results performed for five different UMTS transport
services. The maximum TCP throughput is evaluated for different scenarios of losses on
the radio interface and the external packet data network.
The influence of TCP/IP header compression is illustrated for the 64 kbit/s transport
service.
Different traffic scenarios, including multiple FTP downloads and simultaneous FTP up-
and download have been simulated for the 384 kbit/s transport service. Another simulation
shows achievable TCP throughput for HTTP traffic scenarios with a single client and with
two clients, operating simultaneously.
CHAPTER 1. INTRODUCTION
3
Summary and Conclusions
After a review of the most important insights of this thesis, conclusions are drawn about
practical applicability and limitations of different modes and services of UMTS packet
switched data transmission for use with TCP/IP. Requirements for future TCP implemen-
tations conclude this thesis.
1.2 UMTS Architecture
The UMTS network is divided into two functional parts: A Core Network (CN) and an
Access Network (AN). A UMTS Terrestrial Radio Access Network (UTRAN) performs the
terrestrial mobile radio access to User Equipments (UE) (see Fig. 1.1).
UE
UTRAN
CN
Uu
Iu
Figure 1.1: UMTS functional parts
The radio interface uses Direct Sequence Code Division Multiple Access (DS-CDMA) with
two duplex modes: Frequency Division Duplex (FDD) and Time Division Duplex (TDD).
UMTS offers packet switched data transport services (defined in[TS25.944]) with data rates
of up to 2048 kbit/s.
UMTS packet switched data services support various transport protocols like the Trans-
mission Control Protocol (TCP, specified in [P81b]) together with the Internet Protocol
(IP, specified in [P81a] and [DH98]) for connections to the Internet and other packet data
networks.
The UMTS core network in Release 99 is logically divided into a Circuit Switched Do-
main (CS) and a Packet Switched Domain (PS) as shown in Fig. 1.2 [TS23.101]. The
protocols and interfaces used are GSM Phase 2+ compliant and defined in [TS22.060] and
[TS23.060]. Packet switched nodes as Serving GPRS Support Node (SGSN) and Gateway
GPRS Support Node (GGSN) have to be enhanced to support higher data rates in the
packet switched domain.
Section 1.3 describes a core network protocol architecture currently under investigation,
using ATM connectivity within the core network for the packet switched domain. This
configuration is suggested in [TS25.401].
Release 00 however, is expected to contain an All IP Network without any need for a CS
domain. All Types of Services (voice, data, video, etc.) will be transmitted and routed
using the PS services and capabilities.
The UMTS Architecture used for this thesis is shown in Fig. 1.3. A UEis connected to
UTRAN over the Radio Interface Uu. It has radio connections to one or more NodeBs
CHAPTER 1. INTRODUCTION
4
SGSN
CN
RNC
RNC
RNS
RNS
RNC
NodeB
RNC
NodeB
GGSN
UE
UTRAN
CN
Uu
Iub
Iur
IuPS
Iub
Uu
Iu
UE
GMSC
IuCS
PSTN
Gn
Gi
Gp
PSTN
PSTN
CS
PS
MSC
Figure 1.2: UMTS circuit switched and packet switched domain
RNC
RNC
RNS
RNS
RNC
NodeB
SGSN
RNC
NodeB
GGSN
CN
UE
UTRAN
CN
Uu
Iub
Iur
IuPS
Iub
Packet
Data
Network
Uu
Iu
PDN
TE
TE
UE
Figure 1.3: UMTS architecture (PS domain)
CHAPTER 1. INTRODUCTION
5
(UMTS Radio Transceiver Stations) and logical connections to a Radio Network Controller
(RNC). One or more radio network controller together with their related NodeBs form a
Radio Network Subsystem (RNS) which is connected to the core network via the IuPS
interface.
Within the Core Network SGSN holds interconnections to other Public Land Mobile Net-
works (PLMN) and GGSN interconnects to Packet Data Networks (PDN) like the Internet.
1.3 UMTS Protocol Architecture
The UMTS protocol stack (Release 99) is shown in Fig. 1.4. ATM transport technology
is used in UTRAN and for the Iu interface. ATM is capable of supporting various and
especially high data rates. Additionally an inherent support to meet stringent Quality of
Service (QoS) requirements and scalability is provided.
Figure 1.4: UMTS protocol stack (PS domain)
The scenario in Fig. 1.4 shows a UEthat established a TCP connection to a Terminal
Equipment (TE) connected to an external packet data network (PDN).
TCP (Transmission Control Protocol , see Section 3.2) controls end-to-end transmission of
user data, thus one entity of the TCP protocol stack can be found on both the UEand
TE.
IP (Internet Protocol , see Section 3.1) performs addressing of network nodes and routing
(forwarding) of IP datagrams. IP protocol stacks are necessary not only on the respective
transmitting and receiving nodes, but also on all nodes, where routing is needed to deliver
IP datagrams to a specific branch of a network, especially for the dynamically changing
network configurations of mobile users (handover, roaming).
PDCP (Packet Data Convergence Protocol , see Section 2.1) ensures proper framing of IP
datagrams and provides optional header compression capabilities. Framing information is
CHAPTER 1. INTRODUCTION
6
needed only on the radio interface Uu to distinguish between different other network layer
protocols beside IP.
RLC (Radio Link Control , see Section 2.2) provides different modes for transmission of
higher layer data over the radio interface, including error detection and error recovery .
MAC (Medium Access Control , see Section 2.3) is used to share resources on transport
channels.
Service Data Units (SDU) are exchanged between a protocol layer and its respective higher
layer. The exchange point to a higher layer is called Service Access Point (SAP). Protocol
Data Units (PDU) are generated in the protocol and are transferred to and received from
the lower layer (see Fig. 2.1 for illustration).
IP packets are tunneled between nodes SGSN and RNC using the GPRS Tunneling Protocol
(GTP-U) over the User Datagram Protocol (UDP [P80]). UDP/IP is handed down to
ATM using ATM Adaption Layer 2 (AAL2) on NodeB and RNC, ATM Adaption Layer 5
(AAL5) on RNC and SGSN respectively. End-to-end addressing and routing is achieved
in user IP packets, whereas local addressing of SGSN and RNC is expected to be achieved
by means of UDP/IP below GTP-U and ATM addressing.
A Controlling Radio Network Controller (CRNC) controls logical connections to a UE,
whereas a Serving Radio Network Controllers (SRNC) actually provides the connections
via its NodeBs. SRNC and CRNC can be one RNC entity, as shown in Fig. 1.4. SRNC
and CRNC can be separated in case of handover scenarios given in [TS25.401].
All UTRAN data transmission related protocol entities are sited on UEand the counterpart
on SRNC/CRNC. They are described in more detail in Chapter 2.
Since the shared medium must be transparent between all related UEs and SRNC/CRNC
an additional framing protocol between SRNC/CRNC and the actual transceiving NodeBs
for multiplexing is needed to transmit certain channel data to NodeBs. Dedicated framing
protocols for shared channels are defined in [TS25.401]. Figure 1.4 shows the framing of
the Common Packet Channel (CPCH) with a specified Common Packet Channel Framing
Protocol (CpchFP) over AAL2.
Chapter 2
UTRAN Protocol Architecture
The UTRAN protocol architecture is logically divided into Control Plane and User Plane.
All control functions like resource management, call establishment and instantiation of
data transmission protocols entities are performed by protocols belonging to the control
plane. User plane protocols are responsible for actual transmission of user data. An overall
description is given in [TS25.401].
All UTRAN related issues belong to the Radio Network Layer . The Transport Network
Layer incorporates all transport technology used for UTRAN, but without specific UTRAN
requirements.
A Radio Access Bearer (RAB) uses a specific radio access scheme to transmit data. A single
UEmay have multiple RABs. A Radio Link is a logical association between a single UE
and a single UTRAN Access Point and consists of one or more radio bearer transmissions.
The UTRAN access point is unique for one cell. It is the UTRAN-side end point of a radio
link.
This thesis is restricted to simulation of user plane protocols. All simulations start at
a point, where control plane protocols finished all connection setup and instantiation of
needed resources. Especially all dynamic relocations of RNCs/RNSs are omitted.
In the following sections the UTRAN protocols will be described in more detail. The entire
protocol stack has already been shown in Fig. 1.4.
2.1 Packet Data Convergence Protocol
The Packet Data Convergence Protocol (PDCP [TS25.323]) transfers data packets from and
to the network layer in a transparent way, thus ensuring the operability of a wide range of
network layer protocols over UMTS. Figure 2.1 gives an overview of the interconnections to
other protocols. In Release 99, the supported protocols are IPv4 and IPv6 . Every Radio
Access Bearer (RAB) is connected to one PDCP entity and one PDCP entity is connected
to one RLC entity.
7
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
8
It provides functions that improve channel efficiency, standardized IETF header compres-
sion algorithms are specified. In general the following functions are performed:
• Transfer of user data.
• TCP/IP and UDP/IP Header Compression and Decompression.
• Buffering of transmitted PDCP SDUs and sequence numbering used for lossless SRNS
relocation1.
• Release 00: Multiplexing of RABs onto one RLC entity.
IP
RLC
MAC-c/shIP
RLC
UE
Uu
Iub
NodeB
CRNC/SRNC
PDCP
MAC-c/shPDCP
MAC-d
MAC-d
PDCP SDU
PDCP PDU
PDCP SDU
PDCP PDU
Figure 2.1: PDCP service
The header compression method is chosen upon the network layer protocol type by Radio
Resource Control (RRC). Any signalling between compressors and decompressors during
data transmission is carried out in the user plane.
In order to distinguish multiple different header compression types and to process user
data packets with the correct compression method, a Packet Identifier (PID) is assigned
to each PDCP Protocol Data Unit (PDU). The assignment of PID values in Release 99 is
shown in Tab. 2.1.
The PID is conveyed in the header field of each PDU. It defines the used optimization
method for the PDCP peer entities. Any PID value not defined upon setup shall invalidate
the PDU and it is discarded.
There are two formats of Protocol Data units defined with PDCP. PDCP No-Header PDU,
which introduces no overhead to the PDCP SDU, and PDCP Data PDU, which holds
compressed or uncompressed user data in PDCP SDUs and a PID to distinguish the
compression algorithm.
1Lossless SRNS relocation allows forwarding of PDUs from an old SRNC to the target SRNC during
relocation procedures. A more detailed description can be found in [TS25.323, Section 5.5].
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
9
PID value Optimization method
Packet type
0
No header compression
-
1
RFC2507
Full header
2
RFC2507
Compressed TCP
3
RFC2507
Compressed TCP non-delta
4
RFC2507
Compressed non TCP
5
RFC2507
Context state
6
Method A
Uncompressed TCP/IP
...
...
...
Table 2.1: PID value allocation
PDCP PDU
PDCP SDU
IP
TCP
User Data
PID
User Data
CH
Figure 2.2: PDCP SDU and PDU
2.2 Radio Link Control
Radio Link Control (RLC) is specified in [TS25.322]. Figure 2.3 gives an overview of the
connections to other protocols. There are three modes for data transmission available with
RLC. Transparent Mode Data (TrD) allows data transmission without introducing any
overhead. Unacknowledged Mode Data (UMD) and Acknowledged Mode Data (AMD) add
overhead but also introduce several functions including error detection/correction and flow
control. Details on the latter two modes are given in Sections 2.2.1 and 2.2.2.
Radio Link Control in general supports the following functions:
• Segmentation and reassembly of higher layer SDUs.
• Concatenation
• Padding
• Transfer of user data.
• In-sequence delivery of higher layer SDUs.
• Error detection (UMD)
• Error correction (AMD)
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
10
• Duplicate Detection (UMD/AMD)
• Ciphering
IP
MAC-c/shIP
UE
Uu
Iub
NodeB
CRNC/SRNC
PDCP
MAC-c/shPDCP
MAC-d
MAC-d
RLC
RLC
RLC SDU
RLC SDU
RLC PDU
RLC PDU
Figure 2.3: RLC service
The length of RLC PDUs depends on the Transport Formats (TF) and Transport Format
Combinations (TFC). It is negotiated upon setup and during connection by Radio Resource
Control (RRC). Its length is not necessarily a multiple of 8 bits. Incoming RLC SDUs are
of arbitrary size and thus a Segmentation and Reassembly Mechanism is implemented in
RLC to fit the data into RLC PDUs.
RLC SDU
IP
TCP
PID
RLC PDU
SN LI
User Data
RLC PDU
SN
RLC PDU
SN LI
RLC SDU
IP
TCP
PID
User Data
IP
TCP
PID
IP
TCP
PID
Pad
Figure 2.4: RLC segmentation and concatenation
Figure 2.4 shows a typical process upon reception of higher layer SDUs. The first SDU is
segmented and inserted into two PDUs. The second SDU is concatenated with the first
SDU into the second PDU.
The last field in the third PDU “Pad” refers to an unused space, known as “padding”.
Padding is necessary, because RLC PDUs need to have fixed sizes to fit into a MAC PDU
(see Section 2.3).
There are two PDU formats defined. Data PDUs carry actual user data received in RLC
SDUs in one of the three known modes TrD, UMD or AMD. Control PDUs can be of type
STATUS, where one entire PDU or piggybacked status information on a data PDU can be
used. Other types are RESET and RESET ACK for peer-to-peer entity re-initialization.
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
11
2.2.1 Unacknowledged Mode Data, UMD
Figure 2.5 shows the model of unacknowledged mode peer entities.
Transm.
UM-Entity
Transmission
buffer
UM-SAP
Receiver
UM-Entity
Receiver
buffer
UM-SAP
Radio Interface
Segmentation &
Concatenation
Ciphering
Add RLC header
Reassembly
Deciphering
Remove RLC
header
CCCH/DCCH/
DTCH/SHCCH
CTCH
CCCH/DCCH/D
TCH/ SHCCH
CTCH
Figure 2.5: UMD peer entities ([TS25.322, Figure 4.3])
SDUs are received by the transmitting entity through the Unacknowledged Mode Service
Access Point (UM-SAP). They are then segmented into pieces of appropriate length and
inserted into PDUs. Higher layer SDUs will be concatenated in PDUs, if possible.
After ciphering of SDU data, the RLC header is generated and added to the PDU. It is
stored in a transmission buffer where RLC PDUs are deployed to the MAC sublayer upon
request.
RLC header information includes a PDU Sequence Number with range 27 (0 .. 127) and
Length Indicators (LI), which indicate the end of one or more higher layer SDUs within
this PDU.
PDUs are received and stored in a receive buffer through one of the logical channels from
the MAC sublayer. RLC header data is removed and user data is deciphered. Reassembly
rebuilds higher layer SDUs and delivers them to PDCP.
If UMD should detect loss of PDUs, higher layers are informed by RLC. Duplicated or
corrupted PDUs received from MAC sublayer are discarded and the loss is signalled.
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
12
2.2.2 Acknowledged Mode Data, AMD
Figure 2.6 shows the model of acknowledged mode peer entities.
Transmission
buffer
Retransmission
buffer &
mangement
MUX
Set fields in RLC Header (e.g. set
poll bits).
RLC Control Unit
ReceivedacknowledgementsAcknowledgements
DCCH/
DTCH
*
AM-SAP
DCCH/
DTCH
**
DCCH/
DTCH
**
AM-Entity
Demux/Routing
DCCH/
DTCH
*
DCCH/
DTCH
**
DCCH/
DTCH
**
Receiver buffer &
Retransmission
management
Transmitting Side
Receiving Side
Segmentation/Concatenation
Ciphering
Add RLC header
Reassembly
Deciphering
Remove RLC header & Extract
Piggybacked information
Piggybacked status
Optional
Figure 2.6: AMD peer entities ([TS25.322, Figure 4.4])
SDUs are received here through an Acknowledged Mode Service Access Point (AM-SAP).
The SDUs are segmented into one or more PDUs if necessary and concatenated if possible.
The length of a protocol unit is a semi-static value, which is negotiated during connection
setup or through dynamic reconfiguration of the Transport Format Combination by RRC.
To determine the end of an SDU a Length Indicator (LI) is inserted into this PDU. There
is one LI for every end of an SDU in a PDU. It is inserted at the beginning of a PDU.
Sequence numbering is also used here with sequence number range 212 (0 .. 4095).
Padding can be replaced by piggybacking status information, allowing almost continuous
message exchange between transmitting and receiving RLC entity. This guarantees all
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
13
state information to be consistent and up to date.
PDUs are placed into a Transmission Buffer and a Retransmission Buffer , excluding pig-
gybacked status information. Excluding the status reports is necessary, since retransmitted
out-of-date status information will seriously harm consistency of state variables in both
entities.
The Multiplexer (MUX) afterwards decides, which PDU has to be delivered to MAC and
schedules the time of transmission. Scenarios are possible, where control PDUs are for-
warded to another logical channel than data PDUs. The broad dashed lines in Fig. 2.6
illustrate this case. The retransmission buffer receives acknowledgements from the receiver,
indicating already ACK-ed packets, which can be deleted from the retransmission buffer.
Every sent packet also has its own retransmission timer, ensuring loss-free retransmission
of packets in case of late or no status information updates due to corrupted control PDUs
or protocol errors.
A function implemented for simulation is the use of a timer for Periodic Poll , which polls
the counterpart peer entity of RLC every 3 seconds for an update of status information,
ensuring consistency when recovering from protocol errors.
The transmission of status information (RLC Status Reports) is triggered by several con-
ditions during data transmission. The available trigger conditions for exchange of reports
is negotiated by RRC upon setup. The receiver should always send a status report when
receiving a poll request. The following triggers are available:
• Detection of one or more PDUs missing (Negative Acknowledgement NACK).
• Timer based transfer of status information.
• Estimated PDU Counter (EPC) mechanism (described in the following).
The Estimated PDU Counter (EPC) is used for scheduling the retransmission of status
reports at the receiving entity. The receiving entity will send a new status report, requesting
PDUs not yet received. Subsequent status report retransmissions are not equally spaced
in time, but controlled by this counter. It is started at transmissions of STATUS PDUs. If
not all PDUs requested for retransmission have been received before the EPC has reached
zero, a new status report is transmitted. EPC adapts the retransmission timeout to the
current bit rate indicated in the Transport Format Indicator (TFI) in order to minimize
delay of status report retransmissions.
The EPC is decremented every Transmission Time Interval (TTI, see Tab. 2.3) with the
estimated number of PDUs that should have been transmitted during that TTI. If PDUs
are missing, the receiver generates a status report (NACK) and sets EPC to the number
of requested (missing) PDUs.
When EPC reaches zero and not all of the previous requested PDUs have been received
correctly, a new status report is generated and EPC is set accordingly.
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
14
2.3 Medium Access Control
Medium Access Control (MAC) is specified in [TS25.321]. MAC entity functions are dif-
ferent for UEand UTRAN.
IP
MAC-c/shIP
UE
Uu
Iub
NodeB
CRNC/SRNC
PDCP
MAC-c/shPDCP
RLC
RLC
MAC-d
MAC-d
MAC SDU
MAC SDU
MAC PDU
MAC PDU
Figure 2.7: MAC service
Following entities are defined for FDD mode:
• Medium Access Control - broadcast (MAC-b): MAC entity handling the
Broadcast Channel (BCH). There is one MAC-b entity in each UEand one MAC-b
in UTRAN for each cell.
• Medium Access Control - common/shared (MAC-c/sh): MAC entity han-
dling the Paging Channel (PCH), the Forward Access Channel (FACH), the Random
Access Channel , the Uplink Common Packet Channel (UL CPCH) and the Down-
link Shared Channels (DSCH). There is one MAC-c/sh entity in each UEand one
MAC-c/sh in the UTRAN for each cell.
• Medium Access Control - dedicated (MAC-d): MAC entity handling dedi-
cated logical channels and Dedicated Transport Channels (DCH) allocated to a UE.
There is one MAC-d entity in each UE and one MAC-d entity for each UE in the
UTRAN. It is also responsible for selecting a Transport Format Indicator (TFI) and
Transport Format Combination Indicator (TFCI) to be used in each Transmission
Time Interval (TTI) when dynamically sharing resources between bearers supported
by a UE.
MAC entities perform several functions on both UEand UTRAN side:
• Mapping between logical and transport channels
• Selection of transport format for each transport channel depending on instantaneous
source rate
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
15
• Priority handling between data flows of one UE, between UEs with dynamic schedul-
ing, between data flows of several users on the DSCH and FACH
• Identification of UEs on common transport channels. Note, that identification is not
used for end-to-end addressing but is resolved by MAC multiplexer and demultiplexer
and is dynamically allocated and negotiated by RRC.
• Multiplexing of higher layer data into transport blocks delivered to the physical layer
on common transport channels and vice versa.
• Multiplexing of higher layer data into transport block sets delivered to the physical
layer on dedicated transport channels and vice versa.
• Traffic Monitoring
• Dynamic switching of Transport Channel type
• Ciphering of TrD RLC (not provided by RLC, see Section 2.2)
• Access Service Class (ASC) selection for RACH and CPCH transmission.
MAC PDUs are bit strings with length not necessarily a multiple of 8 bits. Depending
on the provided and negotiated transport service, MAC SDUs are bit strings with any
non-null length and is included into MAC PDUs from first bit onward.
All PDUs delivered to the physical layer in the UEfor uplink within one TTI are defined
as Transport Block Sets (TBS). A TBS consists of one or more transport blocks, each
containing one MAC PDU.
The order of delivery shall be adopted from the order of reception of SDUs from RLC. The
same goes for multiplexing multiple RLC PDUs from different logical channels.
MAC PDUs consist of an optional MAC header and one MAC SDU. There are several
fields defined for the MAC header. The Target Channel Type Field (TCTF) provides
identification of logical channel classes (BCCH, CCCH, ...) on FACH and RACH channels.
The Channel Type Field (C/T) is used to provide identification of logical channel instances,
channel types on dedicated transport channels and data transmission over FACH and
RACH, respectively. The MAC header used in further simulations is 4 bits (C/T), and
used on DTCH and DCCH which are mapped to DCH.
A C/T field with all bits set as shown in Tab. 2.2 is reserved and the current version of
the protocol will discard MAC PDUs with this C/T type.
RLC has to provide RLC PDUs to MAC, which fit into the available transport blocks on
the transport channels. This is described in Section 2.2.
The transmission formats used for simulations in this thesis are shown in Tab. 2.3 and
are examples taken from [TS25.944]. Cyclic Redundancy Check (CRC) is applied to each
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
16
C/T field
Designation
0000
Logical channel 1
0001
Logical channel 2
...
...
1110
Logical channel 15
1111
reserved
Table 2.2: C/T field structure
Transport service Transport block Set size CRC TTI
12.2 kbit/s
244 bit
1
12 bit 20 ms
64 kbit/s
1280 bit
1
16 bit 20 ms
144 kbit/s
2880 bit
1
16 bit 20 ms
384 kbit/s
3840 bit
1
16 bit 10 ms
2048 kbit/s
4096 bit
40
16 bit 80 ms
Table 2.3: Channel coding and transmission format
Transport Block . The only exception is the 12.2 kbit/s transport service, where the 12-
bit CRC is only attached to Transport Block Segment #1. The used Transmission Time
Interval (TTI) is a multiple of the basic Radio Frame duration of 10 ms.
The used 12.2 kbit/s transport service can be applied to Adaptive Multi-Rate (AMR)
speech transmission over packet switched data services. Another possible use is the use
of 12.2 kbit/s for uplink in highly asymmetric scenarios, like with HTTP Clients running
on UEs (Web Surfing). The 64 kbit/s and 144 kbit/s transport services will be used for
interactive applications with demand for multimedia data transmission at moderate data
rates. These transport services may also serve as the backward path of highly asymmetric
data transmissions.
384 kbit/s is used for highly interactive multimedia applications. 2048 kbit/s is defined for
high data rate multimedia applications.
2.3.1 MAC-c/sh
Medium Access Control - common/shared (MAC-c/sh) entities provide mapping between
logical and transport channels and handling of the TCTF field in the MAC header. TCTF
indicates also the logical channel type.
If a dedicated logical channel is used, MAC distinguishes between UEs by the UE Id field
in the MAC header.
It is possible to use transport format selection in the uplink. If a CPCH is used, a transport
format is selected out of a transport format set determined from status information on the
CSICH.
CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE
17
Scheduling and priority handling is used to transmit information received from MAC-d on
RACH and CPCH. In order to prioritize transport channels, Transport Format Combina-
tion Selection can be performed. A Channel Transport Combination is then selected out
of a negotiated set of TFCs. The negotiation is done by RRC.
Figure 2.8: UEside MAC architecture
2.3.2 MAC-d
Medium Access Control - dedicated (MAC-d) entities perform several functions, including
Dynamic Transport Channel Type Switching based on RRC decision. Further functions in-
clude multiplexing of dedicated logical channels, with C/T header field in their packets set,
onto appropriate transport channels and downlink mapping of dedicated logical channels
onto common and dedicated transport channels.
One dedicated logical channel can be mapped simultaneously onto DCH and DSCH. A
MAC-d entity using common or downlink shared channels is connected to a MAC-c/sh
entity that handles data reception on UE-assigned common channels. See Fig. 2.8 for
illustration of this interconnection.
The UTRAN side architecture of MAC-d is similar and differs only by the way MAC-c/sh
and MAC-d are interconnected. In case SRNC/CRNC are separated, this interconnection
is obviously not local, but established via the Iur interface (see Fig. 1.3).
Chapter 3
TCP/IP Protocol Stack
Transmission Control Protocol (TCP) / Internet Protocol (IP) is an entire protocol suite
covering OSI layers 3 and 4. It evolved from ARPANET , an ancestor of the Internet,
connecting US Universities in the early 1970’s and replaced the original Network Control
Program (NCP) protocol. Rising popularity of the Internet spread this protocol suite all
over the world. Its ease of implementation and the continuous research and investigations
on its behavior lead to an ongoing increase of performance with every new (backward
compatible) version.
IP in its current version 4 (IPv4) is able to address 232 different network nodes. IPv6
expands the address range to 128 bits (2128 nodes).
TCP typically adds a 20 byte header structure to user data and IP adds another 20 bytes.
Thus the minimum header size for non fragmented TCP/IP packets is 40 bytes. Both IP
and TCP provide 16-bit checksum fields covering different areas for error detection.
3.1
IP
IP is a network layer protocol (OSI layer 3). It provides functions like datagram delivery
service, addressing and fragmentation.
IP Versions 4 and 6 are defined in [P81a] and
[DH98], respectively. An IP Datagram is the basic unit of a TCP/IP data packet. It
consists of an IP header and user data. The minimum length of the IP header field is 20
bytes. A minimum TCP/IP header is shown in Fig. 3.1.
The maximum length of an IP datagram is 65,535 bytes (octets). The IP layer on inter-
mediate gateways may fragment datagrams during transmission. This implies, that the
receiving side must be capable of reassembling a datagram before it is processed and user
data is handed up to higher layers. All IP hosts are required to support and process IP
datagrams of sizes up to 576 bytes without fragmentation.
Datagram fragments contain almost identical headers, which are basically copies of the
original header with only few modifications, and user data. Fragments are treated as
normal IP datagrams during transmission.
18
CHAPTER 3. TCP/IP PROTOCOL STACK
19
Figure 3.1: TCP/IP header field
CHAPTER 3. TCP/IP PROTOCOL STACK
20
Since IP provides only unreliable datagram service, the entire IP datagram is considered
corrupted and is discarded by the receiver, if one or more fragments are lost or corrupted
during transmission.
The first 20 octets in Fig. 3.1 form the IP Header:
• Protocol Version: Current version is 4 (IPv4) and 6 denotes IPv6. Besides 4 and
6 only 5 (experimental) is defined.
• Header Length: Length of IP Header counted in 32-bit quantities excluding user
data field.
• Service Type: Indication of the Quality of Service requested for this datagram.
• Total Length: Total length in bytes of this datagram, including header.
• Identification: Unique number assigned by the sender. Used for reassembly in the
receiver. All fragments of a datagram carry the same Identification.
• Flags: Don’t fragment (DF) and More Fragments (MF) used for fragmentation
processing.
• Fragment Offset: Offset of user data in this fragment given in 64-bit pieces.
• Time to Live: Denotes the time in seconds, that a datagram can be in transit
including all processing effort. Most routers, however, will process and deliver data-
grams in fractions of seconds nowadays. TTL now is a hop-count metric rather than
a time metric. It is decremented at every router the packet travels through. When it
reaches zero the packet is assumed to be running in some closed loop and discarded.
• Protocol Number: Indicates the higher layer protocol. TCP has protocol number
6, UDP 17, ICMP has 1. Even for IP a number, 4, is assigned for IP encapsulation
techniques.
• Header Checksum: This header checksum covers the header area only and does
not extend onto the user data area. It is calculated as the 16-bit one’s complement of
the one’s complement sum of all 16-bit words in the IP header. While calculating the
checksum this field is considered all zero for obvious reasons. A checksum mismatch
discards a packet.
• Source IP Address: 32-bit identification number of the network node the data-
gram originated from. A more human-readable format is the dotted-decimal format
convention, where each dot-delimited section refers to one byte of the 32-bit number.
A valid IP Address therefore could be “128.131.67.83”.
• Destination IP Address: 32-bit identification number of the target network node
of the datagram.
CHAPTER 3. TCP/IP PROTOCOL STACK
21
An IP Options field of variable length, following the basic header fields may contain further
information for all IP layers, passed during the transmission and forwarding of this packet.
The maximum IP header length including options can be 60 bytes.
When crossing different gateways and networks, IP datagrams may get fragmented due to
restrictions in maximum frame sizes these networks are willing to handle. The Maximum
Transmission Unit (MTU) quantizes this parameter. IP requires each link to be capable
of offering a minimum MTU of 68 bytes. IP implementations are not required to han-
dle unfragmented IP datagrams larger than 576 bytes. However, most implementations
nowadays offer MTUs of 8192 bytes or higher and almost all a minimum of 1500 bytes.
If fragmentation is necessary, the corresponding flags and offsets will be set in the datagram.
Since IP fragments may travel to their destination using different routes in some cases,
the receiver must be capable of reassembling the original IP datagram, even if fragments
overtake each other or in case of duplication (cloning) of datagrams by gateways.
Fragments can even be subject to further fragmentation, if the MTU of a used network
path requires this. Modern TCP implementations use MTU Path Discovery techniques to
avoid fragmentation by setting the datagram size in a way, that the whole IP datagram
passes through all gateways unfragmented.
3.2 TCP
The Transmission Control Protocol (TCP) is a transport layer protocol (OSI layer 4). It is
specified in [P81b]. TCP adds a 20 byte header structure (without options) to user data.
TCP provides error recovery, flow control and reliable data transmission over unreliable
transmission media. TCP is a connection-oriented protocol unlike the User Datagram Pro-
tocol (UDP) which is connectionless. Connection-oriented means, that both entities of the
protocol related with the transmission of user data (transmitter and receiver) have knowl-
edge of each others state condition. They are exchanging data not only in the forward but
also in the backward direction (acknowledgement traffic). Connection-oriented protocols
require exchange of data to set up a connection, do actual data transfer and undergo a
well-defined release procedure.
Most of todays application protocols like TELNET , FTP and HTTP require lossless trans-
mission of user data and make use of TCP.
TCP provides a byte-stream connection, sequence numbering every byte in the stream.
This contiguous stream of data is divided into TCP segments prior to transmission.
TCP is a so-called self-clocking protocol, adapting the senders’ rate to the offered band-
width. TCP sends one or more segments only, if prior ACKs from the receiving side have
reached the transmitter. The only exception are timeout-based retransmissions.
The second 20 bytes (20 .. 39) in Fig. 3.1 form a TCP header structure:
• Source Port: 16-bit source port number, used for replies.
CHAPTER 3. TCP/IP PROTOCOL STACK
22
• Destination Port: 16-bit destination port number indicating the port at the re-
ceiver where this segment is delivered to.
• Sequence Number: Indicates the byte number of the first byte of user data in this
segment.
• Acknowledgement Number: Indicates the next sequence number, the receiver is
willing to accept (only used if ACK flag set).
• Data Offset: Offset of user data in this segment. This indicates the size of the TCP
header including options.
• URG: Indicates that the urgent pointer field carries relevant data.
• ACK: Indicates that the acknowledgement field carries relevant data.
• RST, SYN, FIN: Used as indicators for reset, synchronization and end of trans-
mission state messaging between the two peer entities, and used during setup and
release of a TCP connection.
• Window: Specifies the number of bytes which the sender of this segment is willing
to accept, beginning with the one indicated in the acknowledgement field.
• Checksum: This checksum covers header and data fields and is calculated as the
one’s complement sum of all 16-bit words in a pseudo-header, the TCP header and
the user data. The Checksum field is considered all zero during calculation. The
pseudo-header used in this calculation covers IP information and consists of Source
IP Address, Destination IP Address, the Protocol Type and TCP length.
TCP Options are defined like IP Options. They are of variable size and format. One option
exists for agreeing upon theMaximum Segment Size (MSS) the peers are willing to handle.
Another important option is the TCP WindowScale Option. See also Section 3.2.6.
The first TCP implementation available was TCP Tahoe, offering basic flowcontrol and
timeout-based retransmissions. It was followed by TCP Reno, which provides more so-
phisticated congestion avoidance mechanisms, and TCP Vegas with newer functions like
WindowScaling, Selective Acknowledgement (SACK) increasing performance while main-
taining Reno’s congestion avoidance.
3.2.1 Sliding Window
Since TCP is a self-clocking, or to be more exact, an ACK-clocked protocol, decision on
whether to send a segment is taken upon reception of ACKs from the receiving side. This
may decline performance on lines with a large Bandwidth Delay Product (see Section 3.2.6)
A possible solution to this imperfection is to increase line efficiency by sending more seg-
ments out onto the line without waiting for every particular segment to be acknowledged.
CHAPTER 3. TCP/IP PROTOCOL STACK
23
1 2 3 4 5 6 7 8 9
Window
1 2 3 4 5 6
8
Window
5
6
7
8
ACK=6, WND=2
TCP
Receiver
TCP
Sender
Figure 3.2: Sliding window principle
This principle is illustrated in Fig. 3.2. A window containing four segments is used on both
peers, enabling the transmitter to send four segments without waiting for an ACK for the
segment at the left edge of the transmission window. For reasons of clarification, segment
numbers are used where byte-sequence numbers would be used in real implementations.
A certain amount of segments is allowed to be sent without having to wait for their ac-
knowledgement, thus filling the pipe. When ACKs arrive, new packets can be sent, thus
obtaining a continuous flow of data.
TCP uses cumulative ACKs, indicating the last correctly received segment with its sequence
number. In this case segment #7 is lost on the line or had to be discarded due to checksum
errors. The receiving side informs the sender, not only of a possible loss by (multiple)
indicating only correct reception of segments up to #6, but also indicates, that it is willing
to accept only two more new packets before the reception window closes. Since the receiver
has to hold out-of-band segments in a reception buffer, this prevents overflowing of the
receivers buffer and reduces unnecessary transmissions and occupied bandwidth on the
line.
After some time, the sender will retransmit segment #7 and the receiver will send back
an ACK indicating correct received segments up to #8. It will also indicate a re-opened
receiver window. The sender can now slide its window three segments, allowing it to send
packets #9 through #12.
The requirement for a TCP sender, of never sending more segments, than the receiver is
willing to receive, indicated through its receive window, makes it possible for the receiver
to regulate the segment arrival rate by adjusting the senders transmission window.
3.2.2 Retransmission Timer
In case of corrupted or lost segments, the receiver will respond to all further well-received
segments with acknowledgements only indicating the last correctly received segment. The
sender will stop sending further segments since it reaches the right edge of its transmission
window.
However, the TCP sender started a retransmission timer for each outgoing segment and
eventually a timeout will occur.
The further behavior, on whether to send just the missing segment or all segments from
that point on, is subject to the implementer. Resending just one segment and waiting for
further timeouts in case of multiple losses, or resending all segments within the current
window - whatever strategy is used, maximum throughput is lost.
CHAPTER 3. TCP/IP PROTOCOL STACK
24
An adaption of transmission rate rises the need for a dynamical adaption of the retransmis-
sion timer timeout value. First, TCP has to know the current Round Trip Time (RTT) for
its outgoing segments. RTT is the time between transmission of one segment and reception
of the corresponding ACK. TCP records the time of sending a segment together with its
expected ACK sequence number. Upon reception, a simple subtraction with the senders
internal time base gives the RTT of this segment and its ACK.
Equation 3.1 shows the weighted average, which is calculated over several RTTs and is
used as a Retransmission Timeout (RTO) value for the retransmission timers.
ε = RTT −A
(3.1)
A = A+
1
8
ε
D = D +
1
4
(|ε| −D)
RTO = A+ 4D
RTO is the weighted average, A, plus the fourfold deviation, D, which ensures accurate
retransmissions while avoiding spurious retransmissions during quick changes in network
conditions.
Since the internal time base and resolution varies on different platforms, no absolute values
are given for clock granularity . Recommended are clock ticks not larger than 500 ms.
3.2.3 Slowstart and Congestion Avoidance
TCP Congestion Control was introduced in the late 1980’s in [AVS99] and was first imple-
mented in TCP Tahoe. The Internet suffered from severe congestion collapse at that time.
TCP sender would start transmissions sending all segments in their advertised windows.
This caused large bursts of data on connected networks, without knowing their behavior
and/or conditions. Intermediate gateways then would drop segments due to shortage in
available queue sizes. The result is, that large blocks of segments had to be retransmitted,
causing even more congestion.
By using ACKs to pace the transmission of segments, TCP is able to determine network
conditions only when the pipe is filled and transmission is in progress. However, a mech-
anism had to be implemented to slowly probe a network for its available bandwidth upon
the start of a transmission.
TCP has to hold a new state variable, called Congestion Window (CWND), used by
the sender to limit the amount of data that can be in transit. This does not change
flow control, achieved by setting the transmission window to a size not larger than the
advertised receiving window. The effective window size is just the minimum of the senders
congestion window and the receivers advertised window. Thus, a TCP sender adapts its
rate of sending segments to the slowest component - network or receiver.
CHAPTER 3. TCP/IP PROTOCOL STACK
25
Determination of the size of CWND is not a trivial task. TCP increases CWND slowly if
no congestion is observed and reduces CWND fast upon indication of congestion. CWND
is not allowed to fall below the Maximum Segment Size (MSS).
TCP assumes that the main reason of segments not being delivered to the receiving entity
is dropping due to congestion. TCP interprets timeouts as a sign of congestion and reduces
the transmission rate.
Each time a timeout occurs, the sender reduces the size of the CWND to one MSS.
A strategy only decreasing CWND is obviously very risk averse, but lacks recovery mech-
anisms, if the available line bandwidth rises. TCP adds one MSS to CWND every time
segments, worth of the current CWND size, have been ACK-ed. Most implementations,
however, do not use this increment. They increment CWND by a fraction of MSS each
time an ACK is received.
384 kbps: CWND, RTO, RTT
RTT
CWND
RTO
[MSS],[s]
Time[s]
0.00
5.00
10.00
15.00
20.00
25.00
30.00
35.00
40.00
45.00
0.00
20.00
40.00
60.00
80.00
100.00
Figure 3.3: Slowstart, congestion avoidance and timeout
A typical plot of the continuous change of CWND size is shown in Fig. 3.3. CWND is
plotted in MSS rather than in bytes for clarification here. Please note the timeout, resetting
CWND to one MSS at simulation time T≈80 s.
TCP provides a second mechanism for increasing CWND much faster as long as CWND
is below a given threshold ssthresh. SlowStart adds one MSS on each received ACK. This
accelerates the initial ramp up of CWND. It corresponds to an exponential increase of
CWND over time. This behavior is also shown in Fig. 3.3. The used threshold is simply
CWND after congestion detection. The actual CWND is set to one MSS. It ramps up in
slow start mode to a point, where it reaches the threshold and congestion avoidance again
takes over.
CHAPTER 3. TCP/IP PROTOCOL STACK
26
3.2.4 Fast Retransmit and Fast Recovery
The major problem of timeout-based retransmissions is the possible loss of ACK clocking.
This happens, if all ACKs reach the sender before timeouts occur. This is called “draining
of the pipe” and fatally decreases performance.
Fast Retransmit is a heuristic that is capable of retransmitting dropped packets sooner than
regular transmission timeouts would do. This preserves the ACK Clock (see [AVS99]) in
case of single dropped segments in a flight of segments. Fast retransmit is an enhancement
to timeouts and does not replace them.
The idea behind fast retransmit is, that every time a duplicate ACK is received by the
sender it not only indicates the loss of segments, but also that segments were received and
have left the network.
In practice, TCP waits for the reception of the third duplicate ACK and retransmits the
segment indicated lost by these ACKs. After that Fast Recovery governs the transmission
of new data until a new (non-duplicate) ACK arrives.
The threshold ssthresh, used by the sender to determine whether to use slowstart or
congestion avoidance, is set to a value not larger than given in Eqn. 3.2.
ssthresh = max
(
Flightsize
2
, 2MSS
)
(3.2)
Flightsize is the number of user data currently in flight, i.e. data conveyed in segments
that is not yet acknowledged. CWND is set to ssthresh plus 3MSS. This inflates the
window by the number of segments that actually have left the network so far and which
the receiver has buffered. Every duplicate ACK received after the start of fast recovery
inflates the window further by MSS for every ACK to reflect another segment that has left
the network. TCP shall transmit new segments, if CWND allows that.
The first ACK that indicates new data acknowledged, triggers the deflating of the window
and CWND is set to the value at the start of fast recovery.
Figure 3.4 illustrates TCP’s behavior. Upon reception of the third duplicate ACK TCP
resends what appears to be the missing segment and lowers its CWND. The CWND rises
rapidly to a point, where fast recovery detects new ACKs. Then the window is deflated.
Slow start is never entered here and this heuristic will keep the pipe filled and ACK clocking
preserved, reducing throughput much lesser than timeout-based retransmissions.
3.2.5 Delayed Acknowledgement
TCP Reno was the first implementation that introduced delayed acknowledgement in the
receiver. Acknowledgements are sent only for every other packet received, thus reducing
traffic in the backward direction. Another reason for introduction is increased efficiency
for interactive traffic, where ACKs can be piggybacked on echoed characters.
CHAPTER 3. TCP/IP PROTOCOL STACK
27
384 kbps: CWND, RTO, RTT
RTT
CWND
RTO
[MSS],[s]
Time[s]
0.00
5.00
10.00
15.00
20.00
25.00
30.00
0.00
5.00
10.00
15.00
20.00
Figure 3.4: Fast retransmit and fast recovery
However, TCP receivers shall not delay ACKs more than 500 ms to prevent spurious
retransmissions of already received segments.
To keep accuracy of retransmissions high, TCP receivers shall also report received out-of-
order segments or duplicate segments immediately back in ACKs, without any delaying.
3.2.6 Window Scaling for Long, Fat Networks
A link with a given bandwidth and delay has the following pipesize, i.e. the maximum
amount of data in transit:
Pipesize[bits] = Bandwidth[bit/s] ·Delay[s]
(3.3)
This is called the Bandwidth-Delay-Product . In case of not delaying ACKs at the receiver,
it takes a minimum of two times a link delay, until an ACK for a previously sent segment
arrives at the sender. To make full use of the lines capacity, segments worth two times the
pipesize can be sent. If the window is lower, not the full capacity of the line is used. As
the doubled delay equals the RTT, the limit in bandwidth is
Bandwidth[bit/s]max =
Windowsize[bit]
RTT [s]
(3.4)
Paths with high bandwidth delay products are called long, fat pipes - networks containing
these paths long, fat networks (LFN).
The original TCP implementation provides handling of window sizes of up to 64 kbytes,
which gives poor performance over some specific links (e.g. satellite links). WindowScal-
CHAPTER 3. TCP/IP PROTOCOL STACK
28
ing allows TCP to scale the original 16-bit window size value by another 16 bits and is
performed in a backwards compatible way during the initial handshake. Window scaling
is described in [JBB92] and is implemented in TCP Vegas.
3.3 Performance Issues and Influences
This section describes known and other possible performance influences of TCP/IP over
UMTS packet switched data services.
3.3.1
IP Maximum Transmission Unit
The MTU size can not be seen isolated for the Uu radio interface, but has to be considered
for configurations, where the counterpart TCP is on a Terminal Equipment (TE) outside
of the core network connected through a packet data network.
If RLC AMD is used, MTU is mainly an issue on the connected paths in public data
networks, like the Internet. All RLC modes perform segmentation and concatenation of
higher layer SDUs, thus providing nearly constant overhead, regardless of the SDU size.
RLC AMD provides error-free transmission of SDUs and thus the influence of MTU size
on performance is negligible.
Most links nowadays, including ATM, provide MTUs of 1500 bytes and more.
3.3.2 TCP Maximum Segment Size
TCP Maximum Segment Size (MSS) is closely related to MTU. Most implementations
allow a minimum of 64 byte for TCP/IP header information. Thus MSS must be smaller
or equal (MTU − 64) bytes to achieve one segment to be carried in one IP datagram.
An evaluation of the optimum including considerations about protocol overhead and seg-
ment loss is given in [TA00]. Since MSS is also negotiated during connection setup and
depends on MTU size, no dynamic adaption can be achieved.
As modern TCP implementations use MTU path discovery to set MTU and negotiate
a proper MSS, IP fragmentation mainly occurs on international lines with heavy loads
where some packets get diverted and may take different routes, getting fragmented there
(per-packet load balancing).
3.3.3 TCP Implementation
The TCP Implementation has the largest influence on performance. Since most UMTS
packet switched configurations, especially with higher data rates, can be seen as LFNs (see
Section 3.2.6), all implementations prior to TCP Reno like TCP Tahoe, relying just on
retransmission timeouts perform poor.
CHAPTER 3. TCP/IP PROTOCOL STACK
29
TCP Reno performs well to a point, where multiple losses in a flight of packets corrupt the
fast retransmit and fast recovery heuristic. TCP Reno also has no WindowScaling Option
implemented, running into the same troubles as TCP Tahoe as described in Section 3.2.6.
TCP Vegas is expected to overcome all these limits. It not only provides window scaling,
but also provides a more accurate measurement method of the RTT based on Time Stamps
and uses Selective Acknowledgement (SACK) to trigger selective packets to be resent.
Clock granularity has a small influence on heavy congested or lossy paths, where many
retransmissions occur and accurate timing of retransmissions become important.
Another problem is the restart of transmissions on idle connections as discussed in [VH97].
In case of persistent connections, like with HTTP , the TCP connection is not released after
transmission but kept open for further transmissions. This may introduce large bursts of
data on the network paths, since the last CWND is used for new transmission and the slow
start phase is omitted.
This is proven to lead to diminished performance. A possible refinement to the original
TCP protocol implementation is to sense for a transmission pause. If this pause exceeds
3RTO, slow start is invoked and CWND is lowered to one MSS for further transmission of
data. The implementation of TCP in this thesis is using this mechanism.
The used window size also affects the minimum required queue size of RLC and interme-
diate packet data network routers. This is especially true for lossless or nearly lossless
simulation scenarios, where CWND reaches its upper limit of 64 kbytes.
More packets are being induced into the network and are queued at RLC level or in routers.
The resulting rise of the packet round trip time is smaller than the rise of the congestion
window, resulting in a rise of packets that have to be queued. The amount of queued
packets stops to rise only if the congestion window reaches its upper limit and maintains
constant.
Whether lossless transmission is a realistic scenario or not - this effect has to be kept in
mind for simulation.
3.3.4 UMTS PDCP Header Compression
Header compression of TCP/IP headers increase throughput efficiency, thus increasing the
fraction
UserDataSize
TCPIPDataPacketSize
.
The compression algorithms defined in [J90] and [DNP99] encode only the changes to vital
protocol fields. Other fields, that may change not so often or never during a connection,
are maintained in local state variables.
A typical minimum TCP/IP header is 40 bytes long and is delta-compressed to 3 ÷ 6 (!)
bytes for typical FTP and TELNET scenarios.
The algorithm defined in [J90] is also known as Van Jacobson Header Compression. It
provides no signalling between decompressor and compressor, thus relying totally on the
behavior of TCP. When transmitting new data, the compressor assigns this connection an
ID and transmits the segment unaltered. Only the ID carried in the protocol type field
CHAPTER 3. TCP/IP PROTOCOL STACK
30
is changed. This allows the decompressor to build up a state variable structure for this
connection.
Subsequent packets are compressed in the compressor. The compressor outputs only un-
expected changes (e.g. advertised window size) and an unaltered TCP checksum to ensure
integrity of the segments. The decompressor restores the segment with the help of its local
state variable structure and the changes indicated in the compressed packet.
Error Recovery is achieved by sensing TCP’s sequence numbers. A retransmission uses
a sequence number equal to or lower than the last sent sequence number, causing the
compressor to send a full, uncompressed segment. This allows the decompressor to reset
its state variable structure to a new base.
Although the algorithm in [DNP99] provides signalling between compressor and decom-
pressor, both algorithms may be a source of diminished performance over UMTS packet
switched configurations. If a segment is dropped or lost on the radio interface, the de-
compressor is not informed, creating perfectly valid TCP segments with a state variable
structure, which is “one behind” the actual wanted state. These TCP segments make it all
the way to the TCP receiver and are discarded there, since a TCP checksum error occurs.
ACKs will be received by the sender, indicating the loss and the fast retransmit algorithm
will try to retransmit the lost segment. But one assumption of the fast retransmit heuris-
tic is invalidated, since multiple segment loss occurs. The first was actually dropped, all
preceding segments are falsely decompressed and discarded by the receiver. A retransmis-
sion triggers the compressor to send an uncompressed packet, resetting the decompressor’s
state.
[DNP99] provides more accurate information, since direct signalling between compressor
and decompressor is used. However, header compression especially on lossy links without
inherent error correction (e.g. RLC UMD) with higher data rates (see Section 5.2.1) will
actually decrease performance rather than increase throughput.
3.3.5 UMTS RLC Mode
Whether to use RLC UMD or RLC AMD is subject to different requirements and needs.
TCP is mostly used for Non Real-time Services (NRT) like FTP or HTTP , where overall
delay is not an issue, but transmission has to be loss-free.
RLC AMD is an error-recovering and correcting protocol and is based on retransmission of
erroneous data. Thus, RLC AMD, like TCP, cannot guarantee certain upper boundaries
for packet delay and time of arrival at the receiving entity. In this thesis I tested both
modes AMD and UMD with TCP.
Figure 3.5 illustrates the interaction of TCP with RLC UMD and RLC AMD. In the
case of RLC UMD, TCP data packets and ACKs are encapsulated in RLC PDUs. The
computational effort is low, since only sequence number assignment, segmentation and
concatenation has to be done, without any need for local buffers for retransmission.
Dropped packets on the radio interface cause all RLC SDUs, that are segmented or con-
CHAPTER 3. TCP/IP PROTOCOL STACK
31
TCP ACK
TCP DATA
TCP ACK
TCP DATA
AMD NACK (TCP DATA), STATUS
AMD DATA (TCP DATA), STATUS
AMD DATA (TCP ACK), STATUS
AMD NACK (TCP ACK), STATUS
UMD DATA (TCP DATA)
MAC-d
UMD DATA (TCP ACK)
IP
PDCP
MAC-d
IP
PDCP
MAC-d
GTP-U
GTP-U
IP
TCP
UE
UTRAN
CN
PDN
IP
TCP
TE
IP
IP
PDCP
MAC-d
IP
PDCP
GTP-U
GTP-U
IP
TCP
IP
TCP
IP
TCP DATA
TCP ACK
TCP DATA
TCP ACK
RLC
RLC
RLC
RLC
(a) TCP over RLC UMD (Unacknowledged Mode):
(b) TCP over RLC AMD (Acknowledged Mode):
Figure 3.5: Interaction of TCP with RLC UMD/AMD, (a) (b)
catenated in this PDU, to be dropped. TCP has to provide proper error correction, using
its end-to-end error correction algorithms.
RLC AMD on the other hand provides lossless transmission of RLC PDUs with the addi-
tional cost of providing retransmission techniques and appropriate buffers. Extra delay in
introduced in the case of retransmissions. TCP’s timeout-scheduling actually copes with
such delays, but certain assumptions regarding the continuous flow of data are invalidated
in case of RLC retransmissions.
After the retransmission of RLC PDUs, multiple PDUs are handed up to higher layers, since
out-of-order PDUs are stored in the receiver buffer and now can be deployed simultaneously.
This severely effects RTT measurement and can lead to spurious retransmissions triggered
by false estimation of the current RTT.
However, RLC AMD gives better results, since the lossy radio interface is closed loop
feedback controlled by RLC AMD. RLC can react faster on errors, because the endpoints
are directly located at the endpoints of the radio interface. Also the transport block size
is better suited for the unreliable radio interface.
Figure 3.5 (b) shows the inner loop of Data PDUs and Control PDUs (STATUS). SDUs
containing TCP Data are transmitted over the radio interface. RLC adds status infor-
mation by means of piggybacking the information onto the Data PDUs or by sending
dedicated Control PDUs. If an error occurs and a PDU is lost, the receiving peer sends a
Negative Acknowledgement (NACK), indicating the lost PDU to be resent.
It should be stated, that RLC UMD adds slightly less overhead to PDUs and there is a
certain break-even, where RLC UMD overtakes RLC AMD in performance, when assuming,
that the rest of the paths is loss-free. This break-even is mostly at channel block error
CHAPTER 3. TCP/IP PROTOCOL STACK
32
ratios of 10−5 or less and is not existent for lossy packet data networks.
3.3.6 UMTS MAC Scheduling and Physical Layer Transmission
Format
There are numerous investigations on the behavior of TCP’s congestion control mecha-
nisms. The dynamics are described in [ZSC91], but yet not fully understood. TCP probes
the network for available bandwidth in the slow start phase. What happens, if multi-
ple TCP connections share a single transport medium, depends on the respective sizes of
CWND and many other factors. The most dominant influence comes from the scheduling
method of the intermediate routers.
Simple First-In-First-Out (FIFO) queueing of incoming packets is the worst method, caus-
ing one or several TCPs to lower their CWND down to one MSS and sending only upon
timeouts. In most traffic scenarios, one TCP connection remains dominant, taking the
whole bandwidth, while all other TCP connections suffer from starvation.
A MAC scheduler has to provide appropriate scheduling methods, to prevent multiple
TCP connections from showing these phenomena. The usual solution is to serve every
connection once at a time, which is called Fair Queueing , and is used for simulation in this
thesis.
The transmission format in UMTS physical layer also affects TCP throughput. See Tab. 2.3
for the used channel coding in this thesis. Examples for channel codings change very
frequently with every new release of the related 3GPP standards [TS25.101], [TS25.104]
and [TS25.944].
In general, all coding schemes in UMTS using large sets of transport blocks and large
transmission time intervals (TTI) tend to introduce problems to TCP transmissions.
The original coding scheme of the 384 kbit/s transport service had transport block set sizes
of 4·3840 bit and a TTI of 40 ms. The TTI was lowered to 20 ms and is 10 ms in the
newest standards of Release 99.
Large transport block sets containing multiple SDUs (e.g. multiple TCP ACKs) are re-
ceived and handed up to higher layer all in one. This causes major problems to TCPs’
timeout estimation. For the 2048 kbit/s transport service the size of PDUs delivered in
one block is around 20 kbytes - which is nearly 1
3
of the available window size of TCP
implementations without window scaling (TCP Tahoe, TCP Reno).
This not only causes bursts of data on connected networks, but also rapid and large queue
size fluctuations in intermediate routers, like described in [ZSC91]. See Chapter 5 on effects
observed in simulation.
3.3.7 External Packet Data Network
Since the overall performance of TCP depends on the weakest link of the transmission chain,
properties of the external packet data network are of great influence. Congestion and heavy
CHAPTER 3. TCP/IP PROTOCOL STACK
33
loss here invalidate all advantages RLC AMD offers. See Chapter 5 for simulation results
and further discussion. The influence of delay in the external packet data network affects
both RLC modes equally. Packet switched transport services with high data rates turn
into long, fat networks (LFNs), if the additional delays introduced on these paths exceed
a few 10 ms. WindowScaling is needed to make full use of the available bandwidth. The
possible loss of multiple packets in one single flight of packets on large pipes gets higher,
which affects TCPs Fast Retransmit and Fast Recovery .
This is a general problem of TCP in the Internet. But the high losses over the radio interface
intensifies this problem. In GSM this was not an issue yet, because the bandwidth was not
high enough.
Chapter 4
Simulation Model
4.1 Simulation Environment
The used simulation tool is Ptolemy Classic, Version 0.7.1 for Linux. It is a set of programs,
developed at the University of Berkeley. It provides an X11 compatible graphical interface
as well as a console-driven direct simulation of compiled universes. Ptolemy and all parts
developed for simulation are written in C++.
A simulation environment in Ptolemy is called universe, containing stars and galaxies.
Galaxies are a number of stars linked together. There are several domains defined for
simulation. All simulation in this thesis is carried out in the Discrete Event (DE) domain.
The events are triggered by particles traveling from star to star. The DEdomain provides
a general environment for time-oriented simulations of systems, such as communication
networks. A scheduler processes events in chronological order. Time intervals between
events are not fixed and Time Stamps are associated to each particle. Time stamps are
generated by the star sending the particle. It is based on the time stamp of the received
particles and the latency of the block.
Data Units (SDUs, PDUs), used for inter-protocol communications, are objects of protocol
classes1. All protocols and their related data units are defined in these classes. The only
exception is MAC, which uses RLC PDUs and a special property of RLC as its MAC
header field.
4.2 Models
Around 20 different stars (classes) have been implemented in C++. The following subsec-
tions give an overview and short insight of the most important stars. The latency of most
stars is zero, i.e. processing a particle takes no simulated computation time. Delays that
1Class in this context means a C++ class.
34
CHAPTER 4. SIMULATION MODEL
35
represent processing of data units are explicitly inserted into simulations. The simulation
model used in this thesis is shown in Fig. 4.1.
CN +
PDN
UE 2
RNC
UE 1
TCP / IP
RLC
PDCP
MAC-d
FTP
Server
TCP / IP
RLC
PDCP
HTTP
Client
TCP / IP
RLC
PDCP
HTTP
Client
RLC
PDCP
MAC-d
RLC
PDCP
RLC
PDCP
INTERNET
INTERNET
INTERNET
TE1
TE1
TE1
TCP / IP
FTP
Server
TCP / IP
HTTP
Server
TCP / IP
HTTP
Server
CHANNEL
Figure 4.1: Simulation model
User data is generated in FTP Server Models or HTTP Server Models. FTP server models
are used for evaluation of maximum TCP throughput performance and for observation of
TCP’s behavior in scenarios with shared transmission resources. User data is segmented
into packets of appropriate length for insertion into a TCP segment. HTTP server models
put out a certain amount of user data. The amount is requested by HTTP Client Models.
See Section 4.2.9 for a more detailed description on HTTP traffic modeling.
TCP segments enter the TCPIP Model, where a source port number and a destination port
number is assigned. The TCP checksum is calculated and included into the TCP header.
The TCP segments are inserted into one or more IP datagrams afterwards. A source and
destination IP address is assigned and the IP checksum is calculated before transmission.
The Internet Model does not alter the data structure. IP datagrams are only delayed or
discarded as described in Section 4.2.7.
IP datagrams enter the PDCP Model, where the datagrams are either compressed or left
unaltered. However, the data structure changes. PDCP PDUs consist of a packet identifier
and the output data of the compressor.
The RLC Model segments and concatenates the PDCP PDUs into RLC PDUs of appro-
priate size and transfers the RLC PDUs into the transmission buffer and places a copy
into its retransmission buffer .
The MAC Model has its own set of buffers and demands RLC to flush the transmission
CHAPTER 4. SIMULATION MODEL
36
buffer every time transmission interval. It inserts RLC PDUs into MAC PDUs and applies
the MAC header field.
A more detailed description of the queueing algorithm and prioritizing of MAC PDUs is
given in Section 4.2.5.
The Channel Model transmits the MAC PDUs with a given loss probability.
4.2.1 TCP Model
The galaxy TCPIP, which includes other TCP related stars, is shown in Fig. 4.2. Star
Sliding Window incorporates a queue for incoming packets and deploys packets upon a
given limit (sequence number). TCPSender holds a retransmission buffer and has full TCP
Reno functionality. Additional features are window scaling , restart of idle connections and
a modified RTO calculation for high data rates over UMTS as described in Section 5.5.1.
Whenever packets are being transmitted, the corresponding sequence number leaves the
star and is fed back to the star at a delay of current RTO. Incoming timeout sequence
numbers simulate the retransmission timer and appropriate reaction can start. Other
outputs are used for graphic visualization of CWND, RTT and RTO.
IPReceiver
outTcp
outUdp
outAck
Delay
TCPReceiver
inTcp
AckEnd
size
outAck
outTcp
AckStart
IPSender
SlidingWin
winSize
inData
outData
overflow
XMgraph
TCPSender
inACK
inTCP
inReTx
demand
outTCP
outReTx
mRTO
mCWND
mRTT
Figure 4.2: TCP/IP simulation model
Star TCPReceiver has three outputs. One is for received segments, one for generated
acknowledgements ready for transmission back to the sender and the third output is used
by the delayed acknowledgement mechanism. The segments leaving this output are delayed
by 500 ms and fed back to the TCP receiver. Out-of-order data is immediately indicated
CHAPTER 4. SIMULATION MODEL
37
to the sender as described in Section 3.2.5. Piggybacking of ACKs onto data segments in
case of direct TCP two-way traffic is not implemented.
Parameters available within TCP models are:
• Version: Denotes the use of normal or modified RTO calculation.
• Window Size: Specifies the maximum size of the transmit and receive window.
• Window Scale Factor: Specifies the scale factor for the transmit and receive win-
dow size.
• MSS: Specifies the TCP Maximum Segment Size used for segmentation of user data
streams.
• ACK Delaying: Specifies whether to use delayed acknowledgements or to acknowl-
edge every incoming segment.
4.2.2
IP Model
The stars IPSender and IPReceiver in Fig. 4.2 are capable of processing TCP and UDP
packets and offer full IP datagram fragmentation implementation, if necessary. The receiver
has three outputs for received TCP data packets, TCP ACKs and for UDP datagrams.
The only parameter is the IP Maximum Transmission Unit (MTU).
4.2.3 PDCP Model
The PDCP star performs framing and TCP/IP header compression modes defined in [J90],
as well as unaltered (uncompressed) transmission of data for up to 256 different TCP
connections over one single line.
PDCP
inIP
inPDCP
outIP
outPDCP
Figure 4.3: PDCP simulation model
The maximum uncompressed SDU size is limited to 64 kbytes. Actual compression and
decompression is implemented for all cases related to the transmission of single data seg-
ments or single ACK segments. Piggybacking is not implemented. The PDCP model has
only one parameter, specifying whether to use header compression or not.
CHAPTER 4. SIMULATION MODEL
38
4.2.4 RLC Model
The RLC star covers the full functionality of RLC modes UMD and AMD. This star
incorporates both sender and receiver. Three different queues are used for transmission,
retransmission and receiver buffer. The size of this queues is variable. Overflowing a buffer
causes RLC to discard the newest PDUs arriving at the queue (drop tail mechanism).
RLC
inRLC
inDeployRLC
inPDCP
inTimer
outRLC
outPDCP
outTimer
Figure 4.4: RLC simulation model
RLC AMD uses periodic status report messaging as a backup system for the timer-based
retransmission mechanism as well as RLC PDU retransmission timeouts. The peer on
the far end is polled every 3 seconds, requesting a status report. The EPC mechanism,
as described in Section 2.2.2, is not implemented. Received out-of-order RLC PDUs and
missing segments trigger an immediate status report (negative acknowledgement).
Like TCP, this star uses corresponding delayed sequence numbers which are fed back to
the star to trigger retransmissions.
Higher layer SDUs are segmented and concatenated into remaining PDUs in the transmis-
sion buffer. After that, a copy is put into the retransmission buffer. Particles incoming at
inDeployRLC input trigger flushing of the transmission buffer and transmission of PDUs
to MAC.
If RLC UMD PDUs are lost, RLC waits for a PDU with an indication for the beginning of
a new SDU, discarding the one in progress. An indication is the existence of one or more
length indicators (LI) in the header area of a RLC PDU.
A specific node-number is inserted upon transmission and checked upon reception of a
RLC PDU, to be able to distinguish between different RLC entities. This represents the
C/T field value in the MAC header.
Available parameters for RLC include:
• PDU Size: Specifies the fixed size of RLC PDUs ready for insertion into MAC
PDUs.
• Mode: Specifies the used mode for this entity (UMD or AMD)
• Queue Size: Specifies the maximum buffer size in PDUs for all three buffers -
transmission buffer, receive buffer and retransmission buffer - used in the RLC model.
CHAPTER 4. SIMULATION MODEL
39
4.2.5 MAC Model
The MAC star is capable of serving an arbitrary amount of RLC entities. In practice,
the size is limited to 15 when using the C/T field in MAC headers. The value received
at inClock causes MAC to send particles containing RLC PDUs out on outDCH. The
maximum number of particles, that can be sent, is indicated by the value received at
inClock. When receiving particles at inDCH, PDUs contained will be sent to all RLC
entities. In this simulation environment, it is the task of the RLC models to check the
C/T-field for conformity.
MAC
inClock
inDCH
inRLC
outDCH
outRLC
outDeployRLC
Figure 4.5: MAC simulation model
In order to prevent TCP from running into problems with multiple connections over a
shared medium, as described in Section 3.3.6, Fair Scheduling is implemented. Every
connected RLC entity is assigned two unique input buffers by MAC, caching Control and
Data PDUs independently.
Every time PDUs are allowed to be transmitted onto the channel, MAC first gets all Control
PDUs, deploying single PDUs from each RLC Control PDU buffer, one buffer after the
other. If more PDUs can be sent, MAC repeats this loop for all Data PDU buffers.
This ensures prioritization of status report messaging between two RLC peer entities and
results in more timely feedback.
4.2.6 Channel Model
The Channel Model used for all simulations is a transport block loss model. Two parame-
ters are specified for the channel model.
• Loss Probability: Probability of loss of one transport block while being transmitted
over the channel. The losses occur uniformly distributed, since interleaving is used
for actual transmission of transport blocks (see [TS25.101] and [TS25.104] for details)
• Delay: This parameter specifies the delay of packets after actual transmission to
a point, where MAC PDUs are available on the receiving side and all decoding is
finished.
4.2.7
Internet Model
The model for traffic over large packet data networks like the Internet is shown in Fig. 4.6.
It represents a path with delay, limited bandwidth, a specific queue size for an intermediate
CHAPTER 4. SIMULATION MODEL
40
router and a certain loss probability. The router uses the drop tail mechanism and discards
the newest datagram arriving at a full input queue.
BwLimiter
Delay
LossyInput
Figure 4.6: Internet simulation model
The following parameters can be specified:
• Loss Probability: Probability of loss of one IP datagram while being transmitted
over this path. The losses occur uniformly distributed.
• Delay: This parameter specifies the delay of IP datagrams on this path.
• Bandwidth: Limits the maximum rate of transmission of IP datagrams.
• Queue size: Limits the maximum input queue size and is given in bytes.
4.2.8 FTP Server Model
The FTP Server Model is a galaxy that produces random user data of given size and
transmits it in TCP segments.
Figure 4.7 shows the stars within this galaxy. The MakeDataPacket star produces user
data packets with a maximum size of TCP Maximum Segment Size each. MakeTCPPacket
receives data packets and includes them in TCP segments.
Delay
MakeDataPacket
MakeTCPPacket
Impulse
Figure 4.7: FTP server model
Three parameters are defined for this galaxy.
• Start Time: Indicates the simulation time, where the transmission of TCP segments
start.
• Size: Specifies the total size of user data in bytes to be transmitted.
CHAPTER 4. SIMULATION MODEL
41
• Rate: Specifies the interval between to consecutive TCP segments leaving the galaxy.
In all simulation this is set to a value much higher than the maximum transmission
rate on the bottleneck paths. However, this can be used for limiting the rate of user
data being transmitted to the TCP/IP stack.
The FTP Server Model is used in almost all simulations. Single FTP Server Models are
used for measurements of maximum TCP throughput, multiple FTP Server Models are
used for simultaneous FTP download scenarios and simultaneous FTP up- and download
scenarios.
4.2.9 HTTP Traffic Model
The HTTP Traffic Model consists of two galaxies, HTTPClient and HTTPServer . Both
galaxies have only one input and one output for TCP segments.
HTTPServer is connected to a TCP Simulation Model on the RNC side. HTTPServer
reads segments and looks up the first bytes of user data within these segments.
If a
(pseudo) HTTP GET request is embedded here, HTTPServer transmits the indicated
amount of bytes. A typical pseudo-header could be: GET /123456, indicating a request for
a file of 123456 bytes in size.
HTTPClient is connected to a TCP Simulation Model on the UE side. This galaxy contains
a PayloadGenerator star, which is shown in Fig. 4.8.
PayloadGenerator
TxSize
size
rate
Figure 4.8: Payload generator model
The PayloadGenerator represents a user, requesting files of different size from a server
(web surfing). The star performs consecutive requests, i.e. it waits for a transmission to
complete, before another request is started.
Three parameters are available:
• Start Time: Indicates the simulation time, where a web session starts, i.e. where
consecutive file requests start.
• Max Time: Specifies the maximum time between an end of a transmission and the
start of a new request. The actual time is uniformly distributed between zero and
the entered value.
• Mean Data: Specifies the mean value for the exponentially distributed file sizes,
that are requested. Note, that a constant of 10000 is added to the actual realized
CHAPTER 4. SIMULATION MODEL
42
random file size value, to omit requests smaller than 10 kbytes. Since the TCP Reno
implementation in this thesis uses slowstart to restart an idle connection, the effect
of slow start is dominant for the average throughput of small files being transmitted.
See also Section 5.4.4, Fig. 5.15 for illustration of this effect.
The parameters used for simulations of HTTP traffic scenarios lead to a file size request
distribution as shown in Fig. 4.9.
HTTP file size request distribution
0%
5%
10%
15%
20%
10000200003000040000500006000070000800009000010
00
00
11
00
00
12
00
00
13
00
00
14
00
00
15
00
00
16
00
00
17
00
00
18
00
00
19
00
00
20
00
00
21
00
00
22
00
00
23
00
00
24
00
00
25
00
00
File size [bytes]
Figure 4.9: HTTP traffic model - file size request distribution
Values larger than 250 kbytes are omitted in Fig. 4.9. Please note that this figure was
drawn using 5000 realizations and some granularity is still visible.
4.3 Simulation Parameters
There are two types of Parameter Sets used for simulation in this thesis. Table 4.1 shows
the Fixed Simulation Parameter Set , containing fixed parameters used for all subsequent
simulations. Table 4.2 shows the Variable Simulation Parameter Set , containing parame-
ters that may vary from simulation to simulation or within one specific simulation.
Both TCP Maximum Segment Size and IP Maximum Transmission Unit are fixed, allowing
maximum TCP/IP header sizes of 64 bytes. The maximum window size is 65535 bytes to
ensure maximum throughput.
The UL/DL Frame Delay is specified in [TS25.211] to be 1024 chips, which gives roughly
276 µs. Internet queue size is large enough to prevent dropping of datagrams due to buffer
overflows. The Internet bandwidth is 2048 kbit/s for IP datagrams (including headers).
CHAPTER 4. SIMULATION MODEL
43
Model
Parameter
Value Range
Unit
FTP
Segment Size
MSS
536 ÷ 65535
bytes
HTTP
Mean Data
50000
10000 ÷ ∞
bytes
HTTP
Max. Time
20
0 ÷ ∞
s
TCP
MSS
1436
536 ÷ 65535
bytes
TCP
ACK Delaying
ON
ON, OFF
-
TCP
Clock Granularity
500
500
ms
TCP
Max. Window Size
65535 MSS ÷ 65535 bytes
IP
MTU
1500
68 ÷ 65535
bytes
PDCP
Header Size
1
1
byte
MAC
Header Size
4
4
bits
PHY
UL/DL Frame Delay 276
276
µs
INTERNET IP Packet Delay
100
100
ms
INTERNET Queue Size
100k
MTU ÷ ∞
bytes
INTERNET Bandwidth
2048
2048
kbit/s
Table 4.1: Fixed simulation parameter set
Model
Parameter
Value Range
Unit
TCP
Version
Reno
Reno, ModReno
-
TCP
Window Scale Factor
1
1 ÷ 65535
bytes
PDCP
Header Compression OFF
ON, OFF
-
RLC
PDU Size
240 ÷ 4092
bits
RLC
Mode
UMD, AMD
-
RLC
Header Size SN
1 (UMD), 2 (AMD) bytes
RLC
Header Size LI
1 (UMD), 2 (AMD) bytes
RLC
Queue Size
500
1 ÷ ∞
packets
MAC
Transport Block Size
244 ÷ 4096
bits
MAC
Transport Block Set
1, 2, 40
blocks
MAC
Transmission Interval
10, 20, 80
ms
CHANNEL Block Delay
10, 20, 80
ms
CHANNEL Block Error Ratio
0
0 ÷ 3·10−1
INTERNET IP Packet Loss
0
0 ÷ 2·10−2
Table 4.2: Variable simulation parameter set (default values)
Chapter 5
Investigation of Transport Services
The investigation of different UMTS transport services shows simulation results for UMTS
transport service data rates from 12.2 kbit/s to 2048 kbit/s on the radio interface.
Four Service Classes are defined for UMTS to meet Quality of Service (QoS) demands from
different applications on network performance parameters.
Service class
Example of service Requirement
Background class
E-mails, SMS
loss-free transmission
Interactive class
web browsing,
loss-free transmission,
server access
moderate transfer delay
Streaming class
video, audio
low transfer delay
Conversation class Voice over IP,
low inter-arrival variation,
video conferencing
low transfer delay
Table 5.1: UMTS service classes
Table 5.1 shows typical examples of applications using different service classes. The rea-
son for splitting the traffic in different service classes is to enhance the system capacity.
Throughput is optimized for each type of traffic by specific handling of the traffic.
Five transport services of the packet switched domain (12.2 kbit/s, 64 kbit/s, 144 kbit/s,
384 kbit/s, 2048 kbit/s) were chosen for investigation in this thesis. The investigated
service classes are the Background Class and the Interactive Class. TCP provides loss-free
transmission of data, which meets the requirement for these two service classes.
For the Streaming Class and the Conversation Class, however, TCP is not the optimal
choice. Both requirements, low transfer delay and low inter-arrival variation, can not
be guaranteed. TCP provides loss-free transmission by retransmitting lost or corrupted
segments. This not only delays delivery of data in case of losses, but also may result in
segments being delivered almost simultaneously in clusters, followed by relatively long idle
periods.
The effect of header compression is shown for the 64 kbit/s transport service and interesting
traffic scenario evaluations have been performed for the 384 kbit/s transport service.
44