Paper

Diplomarbeit
Scheduling Algorithms for UMTS FDD Downlink
ausgefhrt am
Institut fr Nachrichten- und Hochfrequenztechnik
der Technischen Universitt Wien
von
Werner Perndl
4431 Haidershofen, Trstlberg 33
Wien, im Juli 2001
Betreuer:
Univ.Ass. Dipl.-Ing. Thomas Neubauer
O.Univ.Prof. Dipl.-Ing. Dr.techn. Ernst Bonek
Abstract
The deployment of third generation mobile communication systems enables many new applications. In particular, services with high data rates become possible. In rst and second
generation mobile systems, data is transferred in a circuit-switched way. This is inecient
for data services, since resources are occupied even if there is no transmission.
Mobile
systems of the third generation overcome this drawback by transferring data services in a
packet-switched way both in the core network and over the radio interface.
In order to
meet the quality requirements of the users, scheduling algorithms must be applied.
In my thesis, I deal with algorithms for assigning resources to mobile users.
I focus my
research on the upcoming European UMTS standard, with emphasis on web transfer over
the downlink shared channel (DSCH) in the frequency division duplex (FDD) mode. For
this purpose I developed a simulation tool to investigate the radio interface protocol behavior and the inuence of dierent scheduling algorithms. In my tool, users are equally
distributed within the cell and they originate web sessions according to a Poisson process.
Data is generated following the web trac model proposed by the European Telecommunications Standards Institute, ETSI.
One issue of my investigations is the inuence of parameters of the radio interface protocol.
With these results, I analyze standard scheduling algorithms like Round Robin, Short Queue
First and Long Queue First.
I improve these algorithms in order to enhance the active
session throughput.
The performance of these algorithms is evaluated depending on the active session throughput and the number of satised users. Again I use the proposals from ETSI extended by a
further satisfaction criterion. I also measure the delay of packets and the duration of web
sessions. Furthermore, the power consumption and the number of users within the system
is evaluated. For these parameters I provide the mean values and the distribution functions
depending on the system load.
My investigations showed that the algorithm Round Robin is most suitable for scheduling
of non-real time trac. The schedulers Short Queue First and Long Queue First are not
acceptable since with these algorithms users with the opposite queue size are not served.
I further conclude that scheduling should be done in a time division manner, i.e., only a
few users transmit with high data rates at the same time. This is caused since coding and
interleaving is more ecient for high data rates (384kbit/s) than for low data rates (64
kbit/s).
Zusammenfassung
Der bergang zum Mobilfunksystem der dritten Generation ermglicht viele neue Anwendungen, insbesondere werden Dienste mit hohen Datenraten mglich. In Mobilfunksystemen der ersten und zweiten Generation werden Daten leitungsvermittelt bertragen.
Das bringt vor allem fr Datendienste den Nachteil, dass Ressourcen belegt bleiben, auch
wenn gerade keine bertragung stattndet. Diesen Nachteil vermeiden Systeme der dritten
Generation, indem Datendienste auch ber die Funkschnittstelle paketvermittelt bertragen
werden. Bedieneralgorithmen sorgen dafr, dass die Qualittsanforderungen der Teilnehmer
eingehalten werden.
In der vorliegenden Arbeit untersuche ich Bedieneralgorithmen fr den europischen UMTSStandard.
Im speziellen betrachte ich Datenbertragung von Internet-Servern zu Mobil-
funkgerten ber den Downlink Shared Channel (DSCH) im Modus mit Frequenzduplex
(FDD). Dafr habe ich eine Simulationsumgebung entwickelt, mit der es mglich ist,
die Eigenschaften der Funkschnittstelle und deren Zusammenwirken mit verschiedenen
Bedieneralgorithmen zu ermitteln.
Die Teilnehmer werden innerhalb der Zelle gleich-
verteilt angenommen und fordern gem eines Poissonprozesses Internet-Dienste an. Als
Datenmodell verwende ich das vom Europischen-Telekommunikation-StandardisierungsInstituts, ETSI, vorgeschlagene Modell.
Einen Punkt meiner Untersuchungen stellt das Verhalten der bertragung in Abhngigkeit
von den Parametern der Protokolle der Funkschnittstelle dar. Aufbauend auf diese Ergebnisse untersuche ich die Bedieneralgorithmen Round Robin, Short Queue First und Long
Queue First. Diese Algorithmen habe ich weiter entwickelt, um den Datendurchsatz noch
zu steigern.
Um die Leistungsfhigkeit der Algorithmen zu bestimmen, habe ich den Datendurchsatz
sowie die Anzahl der zufriedenen Benutzer ausgewertet.
Dabei halte ich mich wieder an
die Empfehlungen von ETSI, erweitere jedoch das Kriterium fr die Zufriedenheit von
Teilnehmern.
Weiters ermittle ich die Verzgerung der Pakete und die Dauer der Web-
Sitzungen fr die verschiedenen Algorithmen. Der Leistungsverbrauch sowie die mittlere

Anzahl von Teilnehmern im System werden ebenfalls bestimmt. Fr diese Parameter wird
sowohl der Mittelwert also auch die Verteilungsfunktion dargestellt.
Bei meinen Untersuchungen stellte sich heraus, dass der Bedieneralgorithmus Round Robin
fr den praktischen Einsatz sehr gut geeignet ist. Die Algorithmen Short Queue First und
Long Queue First sind nicht einsetzbar, da jene Teilnehmer mit entgegengesetzter Gre
der Warteschlange nicht bedient werden.
Weiters habe ich gezeigt, dass hherer Datendurchsatz erzielt wird, wenn die Zuordnung
der Funkkanle in kurzen Zeitabschnitten mit hoher Datenrate erfolgt. Der Grund dafr
ist, dass fr hohe Datenrate (384 kbit/s) ezientere Kodierung mglich ist als fr niedrige
Datenrate (64 kbit/s).
II
Acknowledgement
I am grateful to Prof. Ernst Bonek for giving me the opportunity to be a member of the
mobile communications group and to do my diploma thesis under his supervision.
Thanks to Thomas Neubauer for technical discussions, for proof-reading my thesis and for
encouragement whenever I needed assistance. With his corrections I really could improve
the quality of my thesis.
I also thank Mobilkom Austria AG for nancial support of this work. The views expressed
in this paper are those of the author and do not necessarily reect the views of Mobilkom
Austria AG.
Special thanks I owe to Christoph Mecklenbrucker.
He supported my work with many
important advice.
Further I express thanks to my colleagues, especially to Thomas Baumgartner, Gnther

Pospischil, Elmar Trojer, Markus Herdin, Hseyin zcelik and Johannes Platz for valuable
technical discussions.
Thanks to Martin Toeltsch for supporting me whenever I had problems with Linux and
Latex.
Finally, I would like to thank my parents. Without their assistance I would not have reached
my goal. This thesis is dedicated to them.
III
Contents
1 Introduction
1.1
Evolution of Wireless Telephony and Internet Access
. . . . . . . . . . . . .
1.2
Quality of Service (QoS) in Wireless Networks . . . . . . . . . . . . . . . . .
1.3
Motivation and Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Universal Mobile Telecommunication System UMTS
2.1
Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
UMTS Protocol Architecture
. . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Radio Interface Protocol Architecture . . . . . . . . . . . . . . . . . . . . . .
2.3.1
Physical (PHY) Layer
. . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.2
Medium Access Control (MAC) Layer . . . . . . . . . . . . . . . . . .
17
2.3.3
Radio Link Control (RLC) Layer
. . . . . . . . . . . . . . . . . . . .
19
2.3.4
Packet Data Convergence Protocol (PDCP) Layer . . . . . . . . . . .
26
2.3.5
Radio Resource Control (RRC) Layer . . . . . . . . . . . . . . . . . .
27
2.3.6
Interaction between Layers . . . . . . . . . . . . . . . . . . . . . . . .
27
3 Propagation Environment
3.1
Cell Conguration
3.2
Channel Model
33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.1
COST-Walsch-Ikegami-Model
. . . . . . . . . . . . . . . . . . . . .
34
3.2.2
Shadow Fading
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.3
Spatially Correlated Shadow Fading . . . . . . . . . . . . . . . . . . .
35
3.2.4
Received Signal Power
. . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3
Interference Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.4
Coverage Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
IV
CONTENTS
4 Scheduling Algorithms
40
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2
Scheduling Best-Eort Applications . . . . . . . . . . . . . . . . . . . . . . .
42
4.2.1
First-In-First-Out Scheduling
. . . . . . . . . . . . . . . . . . . . . .
42
4.2.2
Weighted Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.2.3
Priority Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.2.4
Queue Length Dependent Scheduling . . . . . . . . . . . . . . . . . .
43
4.2.5
Channel State Dependent Scheduling . . . . . . . . . . . . . . . . . .
43
4.3
Scheduling Guaranteed-Service Applications
. . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . . . . . . . .
44
. . . . . . . . . . . . . . . . . . . . . . .
44
4.4
Comparison of Scheduling Algorithms . . . . . . . . . . . . . . . . . . . . . .
44
4.5
Scheduling in UMTS
44
4.3.1
Earliest-Due-Date Scheduling
4.3.2
Rate-Controlled Scheduling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1
Transport Format Selection
. . . . . . . . . . . . . . . . . . . . . . .
45
4.5.2
Round Robin
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.5.3
Short Queue First (SQF) . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.5.4
Long Queue First (LQF) . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.5.5
Weighted Scheduler (WS)
48
. . . . . . . . . . . . . . . . . . . . . . . .
5 Simulation Environment
52
5.1
Simulation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.2
UMTS Simulator
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.2.1
Trac Source at the UTRAN side . . . . . . . . . . . . . . . . . . . .
54
5.2.2
RLC at the UTRAN/UE side
55
5.2.3
MAC-d at UTRAN side and MAC at UE side
5.2.4
MAC-c/sh at the UTRAN side
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
55
. . . . . . . . . . . . . . . . . . . . .
56
5.2.5
Sink at the UE side . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.2.6
RRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
CONTENTS
VI
6 Results
60
6.1
6.2
Optimization of the RLC-Protocol Stack
. . . . . . . . . . . . . . . . . . . .
60
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.1.1
RLC Parameters
6.1.2
Maximum Window Size
. . . . . . . . . . . . . . . . . . . . . . . . .
64
Investigation of the Scheduling Algorithms . . . . . . . . . . . . . . . . . . .
65
6.2.1
RR, SQF and LQF . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.2.2
Weighted Scheduler (WS)
70
. . . . . . . . . . . . . . . . . . . . . . . .
7 Summary and Conclusions

7.1
Summary
7.2
Conclusions
73
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
76
A The ETSI Web Trac Model
77
B Discrete Event Simulation System OMNET++
81
B.1
Discrete Event Simulation
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
B.2
Simulation Structure
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
B.3
Programming
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
B.4
The Graphical User Interface: Tkenv
. . . . . . . . . . . . . . . . . . . . . .
86
C Transport Formats
87
D Generation of random numbers from an arbitrary distribution
91
D.1
Truncated Pareto Distribution . . . . . . . . . . . . . . . . . . . . . . . . . .
91
E Programming Issues
93
Glossary
95
Bibliography
98
List of Figures
1.1
Worldwide subscribers to xed, mobile, and xed Internet networks [Forum00]
2.1
UMTS network architecture [Holma00]
. . . . . . . . . . . . . . . . . . . . .
2.2
The logical role of an RNC [Holma00] . . . . . . . . . . . . . . . . . . . . . .
2.3
Protocol architecture, PS domain [UMTS-23.060]
. . . . . . . . . . . . . . .
2.4
Radio interface protocol architecture (after [UMTS-25.301]) . . . . . . . . . .
10
2.5
Protocol termination for a common channel (after [UMTS-25.301]) . . . . . .
10
2.6
Physical layer for transmitting situation
11
2.7
Frame structure for downlink DPCH [UMTS-25.211]
. . . . . . . . . . . . .
12
2.8
Frame structure for downlink PDSCH [UMTS-25.211] . . . . . . . . . . . . .
13
2.9
PDSCH timing [Holma00]
14
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10 DSCH code tree examples [Holma00]
. . . . . . . . . . . . . . . . . . . . . .
14
2.11 Mapping of logical channels, transport channels and physical channels in the
downlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.12 Transport formats [UMTS-25.302] . . . . . . . . . . . . . . . . . . . . . . . .
16
2.13 MAC protocol suite [UMTS-25.321] . . . . . . . . . . . . . . . . . . . . . . .
17
2.14 MAC PDU and SDU [Loem00]
. . . . . . . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . . . .
20
2.15 RLC AM entity [UMTS-25.322]
2.16 RLC segmentation and concatenation [Loem00]
. . . . . . . . . . . . . . .
21
2.17 AM data PDU (a) and Status PDU (b) [UMTS-25.322] . . . . . . . . . . . .
22
2.18 PDCP SDU and PDU [Loem00] . . . . . . . . . . . . . . . . . . . . . . . .
27
2.19 DSCH Data Frames on Iub-interface (a) [UMTS-25.425], and Iur-interface

(b) [UMTS-25.435]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.20 Data transfer over RLC acknowledged mode
3.1
29
. . . . . . . . . . . . . . . . . .
32
Cell conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
VII
LIST OF FIGURES
VIII
3.2
Spatially uncorrelated (left side) and correlated (right side) shadow fading
36
3.3
Interference ratio depending on the position of the user . . . . . . . . . . . .
38
3.4
Average interference ratio depending on the distance between base station

and the mobile
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.1
Schedulable region [Keshav97] . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2
Scheduling in UMTS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.3
Weight calculation for buer occupancy . . . . . . . . . . . . . . . . . . . . .
48
4.4
Weight calculation for shadow fading
49
4.5
Weight calculation for recently allocated PDU's
. . . . . . . . . . . . . . . .
49
5.1
Schematic owchart of the simulation procedure . . . . . . . . . . . . . . . .
52
5.2
UMTS simulator
54
6.1
RLC performance depending on the Window_Size (in PDU's) and the Sta-
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tus_Prohibit_Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
62
RLC performance depending on the Status_Prohibit_Time with a Window_Size=1024 PDU's . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.3
Number of unsatised users depending on the inter session arrival time
66
6.4
Mean number of active sessions depending on the inter session arrival time
. . .
(a) and cdf of the number of active sessions for an inter session arrival time
of 1.7 s (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5
Mean SDU delay depending on the inter session arrival time (a) and cdf of
the SDU delay for an inter session arrival time of 1.7 s (b)
6.6
. . . . . . . . . .
68
Mean session duration depending on the inter session arrival time (a) and
cdf of the session duration for an inter session arrival time of 1.7 s (b) . . . .
6.7
67
68
Mean active session throughput depending on the inter session arrival time
(a) and cdf of the active session throughput for an inter session arrival time
of 1.7 s (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8
69
Mean power consumption depending on the inter session arrival time (a) and
cdf of the power consumption for an inter session arrival time of 1.7 s (b) . .
6.9
Comparison of RR_384 and WS_SQF_384 ( 1 =1.0,
A.1
Typical web browsing session
A.2
Pareto distribution
g2 =0.0, g3 =0.3)
70
. . . .
72
. . . . . . . . . . . . . . . . . . . . . . . . . .
77
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
B.1
Example of a NED-structure . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
B.2
Command window of the graphical user interface
86
. . . . . . . . . . . . . . .
List of Tables
2.1
PDSCH spreading factor and bit rates [UMTS-25.211] . . . . . . . . . . . . .
13
2.2
Parameter values for RLC layer [UMTS-25.331]
. . . . . . . . . . . . . . . .
28
2.3
MAC layer parameters [UMTS-25.331]
. . . . . . . . . . . . . . . . . . . . .
28
3.1
Simulation parameters (1)
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2
Link level simulation results for UDD services, Pedestrian A channel in downlink direction [ARIB98, Annex3] . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.3
39
4.1
Comparison of scheduling algorithms
. . . . . . . . . . . . . . . . . . . . . .
45
6.1
Parameters for optimization of Window_Size and Status_Prohibit_Time . .
61
6.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.4
Parameters for the Weighted Scheduler WS_SQF_384
. . . . . . . . . . . .
70
A.1
Model parameters for dierent UDD services [ETSI98]
. . . . . . . . . . . .
79
C.1
Transport channel parameters for a 384 kbit/s DSCH [UMTS-34.108]
. . . .
88
C.2
Transport channel parameters for a 144 kbit/s DSCH [UMTS-34.108]
. . . .
89
C.3
Transport channel parameters for a 64 kbit/s DSCH [UMTS-34.108] . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
IX
Chapter 1
Introduction
1.1 Evolution of Wireless Telephony and Internet Access
The combination of mobility and telephony has become very popular within the past ten
years. In parallel to the amazing growth of mobile communications, xed network communication is growing rapidly as well. Access to the Internet oers a large variety of dierent applications. Communication services like electronic mail, web-browsing, le transfer,
voice and music broadcasting and video transmission become a standard equipment to a
constantly increasing number of people. In the business world as well as privately, working
without Internet is not imaginable any more. In Figure 1.1 a comparison of the worldwide
Subscribers in Millions
2000
1500
Fixed Telephony
Fixed Internet
Mobile Subscribers
1000
500
0
1990
1995
2000
2005
2010
Figure 1.1: Worldwide subscribers to xed, mobile, and xed Internet networks [Forum00]
growth in subscribers to xed telephony networks, mobile networks, and to the wired Internet is shown. This comparison quoted from [Forum00] was done in July 2000. It points out
that there are more than a quarter of a million people around the world who are signing up
for mobile cellular services every day. Internet usage is growing by over half a million new
subscribers per day. The target of one billion mobile subscribers worldwide will be reached
by 2002. Another interesting fact is that there will be more mobile than xed subscribers by
2002 or 2003. Of course, there are several forecasts from other institutes leading to dierent
results. Nevertheless, latest forecasts almost always provided signicant underestimations.
CHAPTER 1. INTRODUCTION
In the future, users will demand to utilize the above mentioned xed network services in
a mobile environment. Therefore, mobile networks of third generation, like UMTS, focus
on both speech and data services. But enabling connectivity to the Internet anytime and
anywhere is just one of the opportunities of third generation mobile networks. There will
be further, enhanced mobile applications, e.g., location-based services where the actual
location of the user determines the behavior of the application. In the near future such
data services will be dominant in mobile networks.
1.2 Quality of Service (QoS) in Wireless Networks

Second generation (2G) mobile networks are mostly utilized and optimized for voice services.
So in 2G wireless networks, trac is transferred via circuit-switched links. This is reasonable
for voice calls because it keeps the network complexity relatively low. So there is no need
for assigning resources to users during the call since every user occupies the bandwidth the
whole time it is active. Nevertheless this approach wastes bandwidth also for voice calls
due to the fact that the participants don't speak all the time.
For data services, like web browsing, this approach is quite inecient because of the bursty
nature of the trac.
Most of the time the user is reading downloaded information.
To
occupy bandwidth during this time is out of question. Therefore it is necessary to allocate
resources only during that time transmission really happens.
This arises the problem of assigning resources dynamically to the users. The goal of this
bandwidth provisioning is to satisfy the requirements of as many users as possible. The
possible demands of a user depend on various things. First of all, every operator or provider
oers various charge models which imply appropriate priority levels. Another criterion is
the kind of trac, e.g., real time trac has very strict delay requirements whereas for non
real time trac, transmission is not as critical.
All these needs of the user dene a set
of transmission parameters which must be fullled during a call.
These requirements of
course vary between the users. Quality of Service (QoS) is responsible for meeting these
requirements.
Parameters assigned to services in order to dierentiate between them for example are:

guaranteed and maximum bit rate

mean, maximum and variance of the packet delay
admission and retention priority
residual bit error rate.
Real-time services for example require strict delay requirements opposed to background
trac. Also the variance of the delay could arise problems in real-time applications whereas
in background trac the delay jitter doesn't matter.
Background trac also approves
a higher raw bit error ratio since retransmissions in error cases are possible.
Priority
parameters specify the relative importance compared to other services.

In order to guarantee compliance of these parameters, a collaboration of the following entities is necessary: admission control, congestion control, trac conditioning, power control
and scheduling.
The task of admission control is to decide whether a certain service can be accepted or not.
Quality of Service for active services can only be guaranteed if the number of users in the
system is limited. An important fact for wireless links is that no absolute QoS guarantees
are possible.
coverage.
Due to mobility, a user could reach locations with poor or even no radio
In such situations it is not reasonable to ensure the negotiated conditions for
such users, because it would require too much resources and hence the QoS of all other
users would get worse.
So, a control entity has to decrease QoS for such a user or, if
necessary, the user has to be dropped.

Due to the bursty nature of data trac, congestion could appear. It's the task of the trac
conditioner to provide conformance of the actual input trac situation, in order to avoid
congestion. If congestion still occurs, congestion control returns the network into normal
working conditions.
Another entity to provide QoS is the scheduler. Its task is to assign resources in order to
satisfy as many users as possible. Due to a heterogenous service mix it is very challenging
to fulll the requirements of many dierent services. In combination with power control
higher priority is given to those users with good channel conditions.
1.3 Motivation and Outline

In my thesis, I will investigate scheduling in wireless networks.
The needs for assigning
resources dynamically to mobile users arises due to the transition to packet-switched transmission. This is necessary in order to utilize resources more eciently. Although there are
scheduling experiences in wireline communication, in the wireless environment additional
diculties due to the error-prone radio channel appear. I will develop these algorithms for
the upcoming third generation mobile radio standard, UMTS, however the main insights
into scheduling will be valid also for other mobile communication systems. I specialize my
work on the frequency division duplex (FDD) mode of UMTS which will be applied in
macro cell environments. The main application I concentrate on will be web browsing.
In Chapter 2 I will provide those parts of the UMTS standard which are necessary in
order to understand my thesis. First I will describe the network structure, I will explain
the function of the radio interface protocol in detail and I will point out the problems of
packet-switched transmission in UMTS. I also present the handling of the Downlink Shared
Channel (DSCH) which will be the objective channel type throughout my thesis.
In Chapter 3 the structure of the propagation environment in my simulation is explained. I
will point out the channel model I used and the way I included other cell interference. I also
will notify the assumptions I made in order to do simulations for a multi-cell architecture.
Chapter 4 deals with scheduling principles. First I introduce dierent approaches and then
I will present those algorithms I actually implemented in my simulation.
In Chapter 5 the simulation environment that I have chosen is explained. I will present
both the naked simulation tool and the environment I have created.
In Chapter 6 my simulation results are shown.
First I will provide the results for opti-
mizing the RLC protocol for dierent network load. This is necessary in order to adjust
the parameters correctly for simulations on scheduler performance. Then the behavior of
dierent scheduler algorithms is investigated.
In Chapter 7 I will present conclusions deduced from my simulation results.
Chapter 2
Universal Mobile Telecommunication
System UMTS
The Third Generation Partnership Project 3GPP has been founded in order to harmonize
dierent standardization approaches. It is a cooperation of several companies and institutes
in order to get a worldwide standard for third generation mobile systems.
Nevertheless
there are several dierent systems dened. The european approach is the Universal Mobile
Telecommunications System (UMTS) which is batched in releases.
The rst release of UMTS, Release 99, is an evolution of the circuit-switched Global System
for Mobile communication (GSM) and the packet-switched General Packet Radio System
(GPRS). In Release 99, a new radio interface was introduced, known as UMTS Terrestrial
Radio Access Network (UTRAN). This interface is based on wideband CDMA technology.
The basic structure of the core network is similar to that of GSM and GPRS.
In a second phase, Release 4 and Release 5 are introduced. Release 4 adds some functionality
to Release 99 but there are no substantial changes. In UMTS Release 5, known as Release
2000, the core network will be replaced by an IP network. Real time services like speech
and multimedia services will be transmitted in a packet-switched manner.
Since standardization of Release 4 and 5 is open by far, in my thesis I will refer to Release
99. Release 99 is issued four times a year, so I refer to the latest available issue, which is
from December 2000.
Detailed information of the above mentioned systems can be found in the following references:
A clear description of the GSM system is given in [Ebersp99].
The GPRS architecture
as well as its protocols are well summarized at [Kalden00], [Cai97] and [Bettst99]. And a
very comprehensive description of the UMTS network and many background information
is presented in [Holma00].
Of course the 3GPP specications can be downloaded from
www.3gpp.org.
CHAPTER 2. UNIVERSAL MOBILE TELECOMMUNICATION SYSTEM UMTS
2.1 Network Architecture

The system architecture of UMTS includes the User Equipment (UE), the UMTS Terrestrial
Radio Access Network (UTRAN), and the Core Network (CN). The entities of the core
network are connected to external networks.
UTRAN
Iub
EXT.
NETWORK
CN
RNC
MSC
IuCS
Node B
Iub
PSTN
circuit
switched
IuPS
IuCS
GMSC
Node B
IuPS
Iub
UE
RNC
Gp
SGSN
packet
switched
Gn
Node B
Gi
GGSN
Figure 2.1: UMTS network architecture [Holma00]
User Equipment (UE)

The user equipment is the physical device which enables the user to access to network services. It consists of the Mobile Termination (MT), which performs the radio transmission,
the Terminal Equipment (TE) and the UMTS Subscriber Identity Module (USIM). The TE
is the entity which enables the end-to-end application, e.g., a laptop that is connected to
a mobile phone. The USIM is realized as a smart card which provides subscriber identity,
authentication and encryption keys.
UMTS Terrestrial Radio Access Network (UTRAN)

UTRAN is responsible for all functionality related to radio access.
It hides all access
activities from the core network. The radio access network consists of a set of Radio Network
Subsystems (RNS) which are connected to the core network through the Iu-interface. A
RNS consists of one Radio Network Controller (RNC) and one or more Node B's.
A Node B is responsible for processing all physical layer activities. This includes channel
coding, modulation, spreading, interleaving, forward error correction, puncturing and so
on. It also provides measurement reports to the RNC and it takes part in power control.
Depending on sectoring, one or more cells are served by a Node B. The Node B is connected
to the RNC via the Iub-interface and to the mobile through the Uu-interface.
The Uu-
interface represents the radio interface.

The RNC performs all functions for radio resource management like establishment, control and release of connections, macro diversity during soft handover, admission control,
broadcast of messages, paging, and so on. The RNC is connected with the core network
via the Iu-interface, with other RNC's via the Iur-interface and with the Node B's via the
Iub-interface. These interfaces are explained in detail in Section 2.3.6.
The RNC can appear in three dierent logical roles. The Serving RNC (SRNC) handles all
the radio resource management tasks mentioned above. During soft handover the mobile
communicates via two or more radio links to dierent base stations. If these base stations
belong to dierent RNC, the tasks of the RNC has to be split up. The RNC which is closest
to the core network is the SRNC. All other RNC's which are involved in the active connection are declared as Drift RNC (DRNC). A DRNC is only responsible for the allocation of
code resources. The term Controlling RNC (CRNC) is used to dene the RNC controlling
one Node B, i.e., it indicates the RNC which terminates the Iub interface towards the considered Node B. So every RNC is CRNC for the Node B's within its service area. A single
RNC entity can act as CRNC, SRNC and DRNC simultaneously for dierent links.
Uu
DRNC
MSC
IuCS
Iub
UE
IuPS
Node B
Iur
IuCS
Iub
IuPS
SRNC
SGSN
Node B
Figure 2.2: The logical role of an RNC [Holma00]
Core Network (CN)

The task of the UMTS core network is to route calls and data connections to external
networks. The core network in Release 99 consists of two domains.
The circuit-switched domain which will be used for real-time applications like speech. This
domain is an evolution of the already existing CN in GSM. The important entities are the
Mobile Switching Center (MSC) and the Gateway Mobile Switching Center (GMSC). The
MSC acts as a switching node and additionally provides functionality for mobile subscribers
like authentication, location updates, handovers, and call routing to a roaming user. The
GMSC is a node to connect the mobile network to an external circuit-switched network.
The second domain is the packet-switched domain for connection to external data networks.
This is an evolution of the GPRS core network and it consists of the Serving GPRS Support
Node (SGSN) and the Gateway GPRS Support Node (GGSN). The GGSN acts as the
gateway between the GPRS network and Public Data Networks (PDN) or other GPRS
networks.
It converts packets coming from the SGSN's into appropriate packets for the
corresponding external packet data network.
The SGSN provides packet routing to and
from the mobiles within the SGSN's service area.

The target of the UMTS Release 5 is an all IP core network architecture.
Within this
approach QoS issues will play an essential role in order to satisfy the user requirements.
External Networks
There are two dierent kinds of external networks to handle calls.
ISDN and ordinary
telephone systems for providing connections for circuit-switched services. Packet-switched

data services most often are handled by the IP-based Internet to the peer entity.
The external network is not part of the UMTS standardization.
2.2 UMTS Protocol Architecture

The protocol stack of a connection in the packet-switched domain is shown in Figure 2.3.
Additionally the termination of each protocol can be seen.
TCP
TCP
IP
IP
PDCP
PDCP
GTPU
GTPU GTPU
GTPU
RLC
RLC
UDP/IP
UDP/IP UDP/IP
UDP/IP
MAC
MAC
AAL5
AAL5
Layer 2
Layer 2
PHY
PHY
ATM
ATM
Layer 1
Layer 1
UE
SRNC
3GSGSN
3GGGSN
IP
IP
external
network
TE
Figure 2.3: Protocol architecture, PS domain [UMTS-23.060]

In the following the signicance of the dierent protocols is explained:
The Asynchronous Transfer Mode (ATM) technology is used in UTRAN and the core
network. ATM is capable of supporting both circuit-switched and packet-switched trac
as well as isochronous and asynchronous trac. In ATM dierent Adaption Layers (AAL)
are dened to enable transmission of dierent services.
With AAL-2 connections with
variable bit rate in a connection-oriented mode are supported. This layer is intended for
real time services. AAL-5 is used to carry the packet- switched user trac in the Iu-PS
domain. ATM also ensures stringent Quality of Service requirements.
The User Datagram Protocol UDP is used for routing user data and control information in
the backbone network. This layer doesn't provide a reliable link.
The GPRS Tunneling Protocol-User plane (GTP-U) is the protocol for tunneling user data
between UTRAN and SGSN's, and between the GSN's in the backbone.
Nowadays the combination of the network layer protocol IP and the transport layer protocol TCP is the dominant protocol stack for data communication. The Internet Protocol
(IP) is responsible for routing packets through the network. It oers a connectionless and
unreliable link between sender and receiver, i.e., each packet is routed independently and
no error correction mechanisms are included. Upon IP, the Transmission Control Protocol (TCP) provides a reliable, connection-oriented end-to-end service.
TCP is designed
for communication links with the very low packet loss ratio of less than 1%. So applying
TCP over wireless links causes many problems. In [Taferner00] and [Loem00], TCP/IP
behavior in the wireless environment is investigated.
The radio interface protocols indicated by PHY, MAC, RLC and PDCP are presented in
more detail in the next section.
2.3 Radio Interface Protocol Architecture

In Figure 2.4 the UMTS radio interface protocol stack is shown. The termination of each
protocol can be seen in Figure 2.5. The radio interface protocol is comprised of three layers:

the physical layer PHY (layer 1)

the data link layer (layer 2)
network layer (layer 3).
There is also the division into control and user plane. The control plane provides services for
transmitting signalling messages. The user plane is responsible for user data transmission.
I will mainly focus on the user plane.
The physical layer is based on WCDMA technology with a chip rate of 3.84 Mchip/s. It
oers data transport services to the MAC layer via transport channels. Transport channels
are characterized by how the information is transferred to the radio interface. They are
divided into common and dedicated transport channels.
Layer 2 is split into the following sublayers: Medium Access Control (MAC), Radio Link
Control (RLC), Packet Data Convergence Protocol (PDCP) and the Broadcast/Multicast

controlplane
RRC
userplane
higher
layers
Radio Bearers
layer 3
10
PDCP
RLC
RLC
RLC
layer 2
logical
channels
RRC ... Radio Resource Control

PDCP... Packet Data
Convergence Protocol
RLC ... Radio Link Control
MAC ... Medium Access Control
PHY ... Physical Layer
MAC
transport
channels
layer 1
PHY
Figure 2.4: Radio interface protocol architecture (after [UMTS-25.301])
PDCP
PDCP
RLC
RLC
MACd
MACd
MACc/sh
PHY
UE
MACc/sh
PHY
Node B
CRNC
SRNC
Figure 2.5: Protocol termination for a common channel (after [UMTS-25.301])
Control (BMC) layer. The BMC layer is responsible for the management of broadcast and
multicast messages like the SMS Cell Broadcast Service.
The MAC layer oers logical channels to the RLC layer. A logical channel is dened by
what type of information is transferred. A general classication of logical channels is into
control channels and trac channels.
Control channels are used to transfer higher layer
signalling messages. Trac channels are used for transfer of user information. There is a
Dedicated Trac Channel (DTCH) and a Common Trac Channel. The CTCH is used
for broadcasting messages. The DTCH is a point-to-point channel, dedicated to one user.
Layer 3 consists of one protocol in the control plane. This protocol is the radio resource
control. It handles all messages required to set up, modify and release layer 1 and layer 2
entities.
The radio interface oers its services to higher layers via so called Radio Bearers. The role
of the Radio Bearer Service is to cover all the aspects of the radio interface transport for
one user data ow.
11
Packet data transmission

In UMTS packet data can be transmitted either via dedicated, common or shared channels.
If a dedicated channel is used, fast power control and soft handover can be applied.
So
power consumption is lower and less interference is produced in neighboring cells. But due
to the long setup times for dedicated channels, this channel type is not suitable for bursty
trac transmitted in packet-switched mode. Common channels do have the disadvantage
that neither fast power control nor soft handover is applicable. So their radio performance is
rather worse. Therefore, common channels are only suitable for transmitting small packets.
A typical application for example could be short message service or sending a request of a
web page.
For transmitting bursty packet data the designated channel is the shared channel. With
this channel type one physical channel is shared between many users in a time division
manner. So, only a single code or a single code subtree is used. In the FDD mode, shared
channels are always associated with a dedicated channel of low bit rate.
This dedicated
channel mainly provides fast power control as well as transport format indication.
Soft
handover is not provided for shared channels in Release 99.
2.3.1 Physical (PHY) Layer

The physical layer converts transport channel information into signals transferred to the
antenna and vice versa. Data on trac channels is transferred in form of transport block
sets once every transmission interval.
In Figure 2.6 an overview of the activities in the physical layer for a transmitting situation
is presented. Details can be found in [UMTS-25.211], [UMTS-25.212] and [UMTS-25.213].
transport
channels
baseband
signal
processing
physical
channel
mapping
baseband
signal
processing
TrCh
Mux
physical
channels
cos(wt)
physical
channels
S
P
split
Re
&
Im
pulse
shaping
to tx
antenna
pulse
shaping
Im
spreading
sin(wt)
scrambling
modulation
Figure 2.6: Physical layer for transmitting situation

The rst baseband signal processing entity includes channel coding, rate matching, interleaving and others. Channel coding can be applied as either convolutional coding or turbo
12
coding with rate 1/2 or 1/3. It's also possible that no coding is done. Further the data
stream is segmented into 10ms blocks which are multiplexed with blocks of other transport channels.
The transport channel multiplexing entity combines all coded transport
channels into one special channel, called Coded Composite Transport Channel (CCTrCH),
which is split up into one or several physical channels later on. These physical channels
are separately spreaded and scrambled. Spreading is done with an OVSF code which ensures orthogonality between the dierent physical channels of a user and which enables
dierent data rates for them. In addition to spreading, scrambling is provided in order to
separate terminals or base stations from each other.
The symbol rate is not aected by
the scrambling operation anymore. After scrambling all the data sequences are summed
up and modulated. In the downlink direction, QPSK modulation is applied. The transmit
pulse-shaping lter is a root-raised cosine with roll-o factor of 0,22.
2.3.1.1
Physical Channels
Physical channels are dened by a certain carrier frequency, scrambling code and spreading
code. In this section I explain the structure of two physical channels in the downlink, the
downlink dedicated physical channel (DPCH) and the physical downlink shared channel
(PDSCH). Physical channels are typically structured into radio frames. A radio frame is
a unit which consists of 15 slots. The length of a radio frame corresponds to 38400 chips,
which equals 10ms. Therefore one slot takes 2560 chips.
Downlink Dedicated Physical Channel (DPCH)

DPDCH
Data 1
DPCCH
TPC
DPDCH
TFCI
Data 2
DPCCH
Pilot
2560 chips, SF=4..512
Slot #0
Slot #1
Slot #i
Slot #14
1 radio frame = 10ms

Figure 2.7: Frame structure for downlink DPCH [UMTS-25.211]
In Figure 2.7 the frame structure of the DPCH is shown. The DPCH transmits Layer 2
user data and physical layer control information in a time multiplexed manner. The control
information tranmitted on the downlink Dedicated Physical Control Channel (DPCCH)
consists of TPC, TFCI, and pilot bits. This control information is generated at Layer 1 and
provides Transmit Power Control (TPC) and Transport Format Indication (TFCI). The
pilot is used for channel estimation. The exact number of bits of each eld may vary and
it is xed when the connection is established. The spreading factor ranges from 512 down
to 4.
13
Physical Downlink Shared Channel (PDSCH)

PDSCH
Data
2560 chips, SF=4..256
Slot #0
Slot #1
Slot #i
Slot #14
1 radio frame = 10ms

Figure 2.8: Frame structure for downlink PDSCH [UMTS-25.211]
In Figure 2.8 the frame structure of the PDSCH is shown. A PDSCH always is associated
with a downlink DPCH. So each user which shares a PDSCH requires an active DPCH.
The PDSCH doesn't carry Layer 1 information, all this information is transmitted on the
DPCCH part of the associated DPCH. Since the PDSCH is shared among several users,
a user has to be informed that it should listen to the PDSCH. This is done by the TFCI
eld in the associated DPCCH. Power control for both DPCH and PDSCH is performed
by the TPC eld. The spreading factor for this channel ranges from 256 to 4. In Table
2.1 bit rates of the PDSCH with dierent spreading factors are shown. Consider that the
modulation scheme on downlink channels is QPSK.
SF
Symbol Rate (ksymb/s)
Bit Rate (kbit/s)
Bits/Frame
Bits/Slot
256
15
30
300
20
128
30
60
600
40
64
60
120
1200
80
32
120
240
2400
160
16
240
480
4800
320
480
960
9600
640
960
1920
19200
1280
Table 2.1: PDSCH spreading factor and bit rates [UMTS-25.211]

The bit rates shown in Table 2.1 are raw bit rates. Due to channel coding and puncturing
the bit rates for transport channels are reduced.
DPCH/PDSCH Timing
The relative timing between a DPCH frame and the associated PDSCH is shown in Figure
2.9. This time lag is necessary because the user equipment has to decode the TFCI eld
in the DPCCH rst in order to know if the PDSCH is addressed to it.
The TFCI eld
includes additional information about transport format and scrambling code.
14
10ms
DPCH frame
10ms
associated PDSCH frame
> 46080 chips = 12 ms
Figure 2.9: PDSCH timing [Holma00]
PDSCH Code Management

SF=4
SF=4
PDSCH root
code
PDSCH root
code
SF=8
SF=8
SF=16
SF=16
SF=32
SF=32
Spreading codes of the
DSCH subtree
(a) 1 user with SF=8
Spreading codes of the

DSCH subtree
(b) 1 user with SF=16, 2 users with

SF=32
Figure 2.10: DSCH code tree examples [Holma00]

If a PDSCH is established within a cell, a PDSCH root channelization code is dened.
This means that every PDSCH is restricted to spreading codes from the subtree below this
root. In Figure 2.10 it is shown how the codes can be assigned. The cross marks indicate
that the corresponding spreading code is utilized. Spreading codes beneath a used code are
not orthogonal any more and therefore they cannot be assigned. In Figure 2.10(a) all the
available PDSCH resources are assigned to a single user. Figure 2.10(b) depicts a situation
where three users share the available codes. With this in mind every radio frame the codes
can be assigned again, i.e. a PDSCH is allocated on a radio frame basis to a single user.
2.3.1.2
Transport Channels
In this section I explain those transport channels which are important for transmission of
packet-switched trac in downlink direction.
15
As already mentioned, transport channels are characterized by how the data is transferred
and they are divided into common and dedicated transport channels. The dierence is that
dedicated channels are identied by their code and frequency and only one user has access
to the channel. Common transport channels are addressed additionally by an inband identication ag because they are shared by several users. The characteristics of a transport
channel are dened by its transport format or a format set specifying the physical layer
processing.
There is only one dedicated transport channel type called Dedicated Channel (DCH). It is
assigned exclusively to one user.
Common transport channels for packet data transmission in downlink direction are the
Forward Access Channel (FACH) and the Downlink Shared Channel (DSCH). The FACH
is a common downlink channel used for transmission of relatively small amount of data.
The DSCH is the designated channel to transfer bursty packet data in the downlink. This
channel is shared by several users.
Mapping of channels from dierent layers

Logical channel
Transport channel
Physical channel
DCH
DPCH
DSCH
PDSCH
FACH
SCCPCH
DTCH
Figure 2.11: Mapping of logical channels, transport channels and physical channels in the
downlink
In Figure 2.11 the mapping of channels from dierent layers in the downlink is shown.
It can be seen that there is a straight forward mapping of transport channels to the corresponding physical channels.
I.e., the Dedicated Channel (DCH) is mapped onto the
Dedicated Physical Channel and the Downlink Shared Channel (DSCH) is mapped onto
the Physical Downlink Shared Channel (PDSCH). The same is applied for the Forward
Access Channel (FACH) which is mapped onto the Secondary Common Control Physical
Channel (S-CCPCH). I mentioned this channel only for completeness reasons.
Thus, a
PDSCH associated with a DPCH involves a DSCH associated with a DCH. Above the
MAC layer I consider dedicated user data trac, i.e. the Dedicated Trac Channel DTCH
is signicant. This DTCH is either mapped onto DCH, FACH, or onto DSCH associated
with a DCH.
Transport Channel Characteristics

All transport channels are dened as unidirectional, i.e. one UE needs transport channels
in both uplink as well as in downlink direction.
There may be simultaneously several

transport channels in both directions.
16
How data is transferred on transport channels is
shown in Figure 2.12.
TB
TB
DCH1
TB
TB
TTI
TTI
TB
DCH2
TB
TB
TB
TTI
DCH3
TB
TB
TB
TB
TTI
TB
TTI
TTI
TTI
TB
TTI
Figure 2.12: Transport formats [UMTS-25.302]

The basic unit exchanged between physical and MAC layer is a Transport Block (TB). A
group of TB's transferred on one transport channel at the same time instance is called a
Transport Block Set (TBS). The interarrival time between Transport Block Sets is denoted
as transmission time interval (TTI). TTI can be set to 10ms, 20ms, 40ms or 80ms and may
vary between dierent transport channels.
The physical layer oers a Transport Format (TF) to the MAC layer which denes the way
a TBS is transferred on a transport channel. This includes the size of a transport block, the
number of TB's each TTI, the transmission time interval TTI, a coding scheme and the size
of the CRC. Further a Transport Format Set (TFS) is dened as a group of TF's associated
to a transport channel. The physical layer handles several transport channels, but not all
TF combinations are possible simultaneously. One allowed combination which contains one
TF for each transport channel is gathered by the Transport Format Combination (TFC).
The set of TFC's which contains all concurrently valid transport format combinations is
denoted as Transport Format Combination Set (TFCS). TF and TFC also have an indicator
denoted as TFI and TFCI. These indicators are used for communication between layers in
order to determine the actual transport format and the actual transport format combination
respectively. Each time a TBS on a transport channel is exchanged between layer 1 and
layer 2 the TFI is used to specify the transport format. The TFCI is transferred to the
receiving side in order to state the currently valid transport format combination, and hence
the way how to decode and demultiplex.
The TFCS only consists of transport format
combinations which don't exceed a maximum total bit rate. It's up to the MAC layer, to
choose one transport format combination given in the transport format combination set.
However the assignment of the TFCS is done by the radio resource control.
17
In Appendix C, I will show transport channel parameters for a DSCH associated with a
DCH.
2.3.2 Medium Access Control (MAC) Layer

The Medium Access layer, standardized in [UMTS-25.321], consists of three dierent entities:
MAC-b is responsible for handling the broadcast channel BCH. On this channel system information is broadcasted into the entire cell. There is both one MAC-b entity
in the UE and one in the Node B.
MAC-c/sh controls access to common and shared transport channels. There is one
such entity in each UE and one for each cell in the UTRAN located in the CRNC
opposed to the MAC-b entity which is located in the Node B, i.e., the CRNC contains
one MAC-c/sh entity for each connected Node B.
MAC-d controls access to dedicated transport channels.
This entity exists once in
each UE and once in the SRNC for each user in the cell, i.e., one SRNC contains as
many MAC-d entities as there are users in its serving area.
logical
channels
BCCH
common
channels
DCCH
DTCH
Transport Channel Type selection

CT Mux
CT Mux
Priority setting
Ciphering
Flow control
MACd
MACb
Flow control
UEID Mux
TCTF Mux
Scheduling/priority handling
TFC selection
TFC selection
DL code allocation
MACc/sh
transport
channels
BCH
FACH
DSCH
DCH
Figure 2.13: MAC protocol suite [UMTS-25.321]
user 3
user 2
user 1
18
In Figure 2.13 the architecture of the MAC layer is shown. I want to point out the MAC
layer of the UTRAN side and I will focus on downlink transmission of a dedicated logical
channel over a Downlink Shared Channel (DSCH). Every time a logical channel of dedicated
type is mapped to common channels, MAC-d has to pass the data to MAC-c/sh via the
connection between the two entities.
I will explain this interconnection in Section 2.3.6
precisely.
The blocks shown in Figure 2.13 do have the following functionality:
Transport Channel Type Selection: Based on the settings of RRC, set either during
radio bearer establishment or during reconguration, the mapping of logical channels
onto either dedicated or common transport channels is done. In our case a DTCH is
mapped onto DSCH.
The CT Multiplexing unit is used when several logical channels are multiplexed onto
one transport channel in order to assign the PDU's to the correct logical channel. If
there is only one logical channel mapped onto a transport channel neither multiplexing
nor a header entry is necessary. The number for logical channels mapped onto one
transport channel is limited to 15.
With priority setting each PDU is assigned a priority value which is evaluated at the
priority handling entity in MAC-c/sh.
Ciphering is performed in the MAC layer in the case of transparent RLC transmission.
This is done only if the logical channels are mapped onto dedicated transport channels.
It's only the MAC-SDU which is ciphered because the header has to remain readable.
The ow control unit performs data transfer between MAC-d and MAC-c/sh.
In
order to avoid buering in the MAC layer, a handshake mechanism is performed

which indicates the number of PDU's a SRNC is allowed to transmit to a certain user
every transmission time interval.
The UE-ID Multiplexing unit provides an unambiguous identication of a user if

dedicated logical channels are transferred over common transport channels. Therefore
two entries in the header are added. The entries are a user identier UE-ID and a
UE-ID-type eld because the identication can appear in dierent forms.
The TCTF Multiplexing unit adds an entry in the MAC header which indicates
the type of the logical channel which is transferred over the RACH or the FACH.
For transmission over DSCH this entry is not necessary because only DTCH's and
DCCH's are possible and their type is indicated by the C/T eld.
The scheduling entity manages resources between data ows according to their quality
of service requirements. How scheduling is done is up to the operator. Some important
scheduling mechanisms are presented in Chapter 4.
19
Priority handling on the one hand is done in order to dierentiate the UE's. On the
other hand it is done to assign dierent priorities to the data ows of one UE. Priority
handling can be seen as part of scheduling.
The TFC selection block selects between the dierent Transport Format Combinations
given in the Transport Format Combination Set. With this means the bit rate can
be changed very fast without any needs for RRC signalling.
Downlink code allocation is used for transmission of DSCH and it performs the management of codes used by the channel.
MAC SDU = RLC PDU
TCTF
UEID
TYPE
UE
ID
C/T
MAC SDU
MAC PDU = TB
Figure 2.14: MAC PDU and SDU [Loem00]

Figure 2.14 shows how the MAC PDU is built and how the MAC header looks like. The
elds in the header are already explained implicitly at the explanation of the MAC entities.
2.3.3 Radio Link Control (RLC) Layer

The RLC layer is standardized in the document [UMTS-25.322]. This layer provides three
dierent transfer modes to higher layer data ows: transparent mode (TR), unacknowledged mode (UM) and acknowledged mode (AM). All these three modes provide buering
of higher layer messages.
The TR and the UM entity have separated transmitting and
receiving entities. The AM entity is realized as one combined transmitting and receiving
entity due to retransmission management.
The transparent transfer mode provides a simply streaming transmission of higher layer
data.
No protocol overhead is added to the data therefore the RLC PDU size must be
equal the UMTS bearer SDU size.
However simple segmentation can be performed, but
how this is done has to be stated during the radio bearer establishment. If there occur errors
during transmission no retransmission is possible. So the transparent mode transmits higher
layer PDU's without any guarantee. This mode is used for delay sensitive services because
these services don't require retransmissions and so the TR mode is most ecient.
The unacknowledged transfer mode doesn't provide a reliable link either. This mode provides means for segmentation and concatenation, see Figure 2.17, i.e., received higher layer
PDU's are lled as good as possible into the RLC SDU's.
A sequence number is added
to every RLC PDU in order to enable error identication. If RLC PDU's are lost due to
Concatenation
Segmentation
20
Reassembly
Remove RLC header

Add RLC header
Retransmission
Buffer
Transmission
Buffer
Status
message
Receiver
Buffer
PDUs
Piggybacked
information
RLC Control Unit

and
Retransmission
management
Mux
Deciphering
Set Header bits
Demux
Ciphering
Transmitting Side
Receiving Side
DCCH
DTCH
DCCH
DTCH
Figure 2.15: RLC AM entity [UMTS-25.322]
erroneous transmission, the whole RLC SDU shall be discarded.
This mode is used for
services where retransmission is part of the higher layer or for services like broadcasting.
The acknowledged transfer mode provides a reliable link. In Figure 2.15 a block diagram
of the RLC AM entity is shown.
This mode is used for delay insensitive services like
interactive and background trac. I will focus on the acknowledged mode because this is
the signicant one for web trac which I want to investigate.
The transmitting side of the AM-entity receives higher layer PDU's. These PDU's are cut
into RLC payload units (PU) of xed size and stored in the transmission buer. If possible,
the rst PU of a higher layer data unit is concatenated to the last PDU stored in the buer.
If some remaining space can't be used, this block is marked as padding. In order to be able to
reassemble the higher layer PDU's a header with appropriate indicators is appended to the
PU. If the MAC layer requests PDU's for transmission, a multiplexer decides which PDU's
are transferred.
When data PDU's are transmitted the rst time, they are additionally
stored into the retransmission buer.
Before transmission, the header bits are set.
If
there is some status information to transmit and one or several PDU's contain padding
blocks, padding can be replaced by the status messages in order to increase the transmission
21
eciency, otherwise extra status PDU's are transmitted to the peer entity. This is called
piggybacked status transmission. Immediately before transmission, the payload of the PDU
is ciphered in case of data PDU's, status information shall not be ciphered.
RLC SDU = PDCP PDU
PID IP TCP
SN PID IP TCP
RLC PDU = MAC SDU
RLC SDU = PDCP PDU
Data
SN LI
PID IP TCP
Data
PID IP TCP
SN LI
RLC PDU = MAC SDU
Pad
RLC PDU = MAC SDU
Figure 2.16: RLC segmentation and concatenation [Loem00]

At the receiving side the AM-block receives PDU's through the logical channels from the
MAC layer. Status PDU's and piggybacked status PDU's are forwarded to the RLC control
unit. Others are stored in the receiver buer until a complete SDU has been received. For
correctly received PDU's the RLC control unit causes the transmitting side to send status
messages for acknowledgment. If some PDU's get lost, negative acknowledgments are sent
to the peer entity. Upon reception of acknowledgments either PDU's are retransmitted or
they are deleted from the retransmission buer. When all the PDU's of one higher layer
SDU have been received, headers are removed, the SDU is reassembled and the SDU is
transmitted to higher layers. In case the RLC is unable to deliver all PDU's pertaining to
one SDU, these PDU's are discarded and the upper layers are notied.
2.3.3.1
Format of AM PDU and Status PDU
The AM data PDU, shown in Figure 2.17(a), transfers user data and piggybacked status
information. A status report can be requested by setting the Poll bit P. The status PDU,
depicted in Figure 2.17(b), provides means for control information transfer between receiver
and transmitter of peer entities. There can be both receiver and transmitter status information included in the same Status PDU. Additionally there are PDU's for reseting the
two RLC peer entities, which are operating in acknowledged mode.
The bits and bit combinations in the PDU's do have the following meaning [UMTS-25.322]:

The D/C eld indicates if the PDU is a data or a control PDU.

The PDU type eld indicates the type of control PDU.
The polling bit (P) is used to request a status report form the peer entity.
The HE and E bit indicate the extension of the header within the PDU.
The sequence number indicates the number of the payload unit and depends on the
variable VT(S).

D/C
Sequence Number
Sequence Number
22
Oct 1
HE
Oct 2
Length Indicator
Length Indicator
Oct 3
D/C
PDU type
SUFI 1
SUFI 1
Data
Oct 1
Oct 2
SUFI K
PAD or piggybacked STATUS PDU
Oct N
PAD
Oct N
Figure 2.17: AM data PDU (a) and Status PDU (b) [UMTS-25.322]
The length indicator (LI) eld indicates the ending of an SDU within the payload. It
also refers to a padding block or a piggybacked status PDU. There are as many LI
elds as there are blocks to refer to. If one SDU occupies several RLC PDU's only
the end of a SDU is indicated in the last PDU. So implicitly the starting position of
a further SDU is marked. There are many specialties to take care of. Since the size
of the LI is in most cases 15 bits it is tricky to treat SDU's where the end of the last
segment exactly lls a PDU or only one octet is remaining. In these cases the LI eld
doesn't t into the PDU anymore so the end of the PDU is indicated in the following
one with a special LI.
The data block represents RLC SDU's or segments of them. In acknowledged mode
the size of this block is restricted to a multiple of 8 bits.
Padding lls up the PDU's which are not fully utilized in order to get PDU's with
equal lengths.
A piggybacked status PDU enhances the eciency of the protocol because these
status messages are transferred without using additional resources because padding
is replaced. The structure of a piggybacked status PDU is almost the same as those
of a status PDU.
With the super elds (SUFI's), status information is transferred to the peer entity.
Up to now there are eight dierent SUFI's dened:
No more data SUFI (NO_MORE): This eld is the boundary between the SUFI's
and the padding part in the status PDU. It is used as the last SUFI except the
acknowledgment SUFI also may denote the boundary.
Acknowledgment SUFI (ACK): This eld acknowledges the correct reception of

all PDU's with sequence numbers less than the LSN parameter (last sequence
number) within this SUFI.

23
Window size SUFI (WINDOW): With this eld the transmitter window size of
the peer entity is set. The new value must be within a certain range dened by
the RRC.
List SUFI (LIST): This eld is intended for sending negative acknowledgments.
It consists of a list that contains always paired values which indicate the sequence
number of a not correctly received PDU and the number of consecutive missing
ones.
Bitmap SUFI (BITMAP): This eld is also for negative acknowledging.
The
dierence is that missing PDU's are indicated by a bit within a bitmap eld.
Relative list SUFI (RLIST): This eld is a third method for negative acknowledging. Here the missing PDU's are indicated by a relative addressing method.
Move receiving window SUFI (MRW): This eld forces the receiving side to move
its receiver window. This is applied in the case that PDU's can't be transmitted
for several times. It also indicates the number of discarded SDU's.
Move receiving window acknowledgment SUFI (MRW_ACK): It acknowledges

the reception of a MRW SUFI.
2.3.3.2
State Variables, Parameters and Timers
Additionally, the RLC sublayer and the protocol functionality depend on a lot of state
variables. Many of these variables are aected by the modulo operation with the modulus
of 4096 in acknowledged mode. So the sequence number cycles through the entire range from
0 to 4095 in ascending order. There is a set of variables assigned to both the transmitting
side and the receiving side.
When performing comparisons there is an ambiguity due to the cyclic structure. In order
to avoid such ambiguity a base must be dened. For comparisons of transmitter variables
VT(A) is assumed to be the base, for comparisons of receiver variables VT(R) should be
the base.
The following variables are responsible for the transmitting side functionality:
VT(S) - The send state variable contains the sequence number of the PDU, which is
waiting for transmission next, retransmissions are excluded. This variable is updated
after the PDU is transmitted.
VT(A) - The acknowledge state variable contains the sequence number of the rst
PDU which is not acknowledged yet.
This value represents the lower edge of the
transmit window.
VT(DAT) - With this variable the number of transmissions of each PU is counted.

There is one such counter for each PU.
24
VT(MS) - The maximum send state variable denotes the sequence number of the rst
PU which is not allowed for transmission, VT(MS) = VT(A) + VT(WS). This value
forms the upper edge of the transmit window.
VT(PU) - This variable counts the number of transmitted PU's, both new and retransmitted ones.

VT(SDU) - This variable counts the number of transmitted SDU's.

VT(WS) - The transmitter window size state variable contains the size of the transmit
window. This variable is set initially to the parameter Congured_Tx_Window_size
and it is changed upon a window size SUFI.
The following variables are responsible for the receiving side functionality:
VR(R) - The receive state variable contains the sequence number of the next insequence PU expected to be received, i.e, this is the sequence number of the farthest
apart PU. This value represents the lower edge of the receive window.
VR(MR) - The maximum acceptable receive state variable contains the rst PU not
allowed to be received, VR(MR) = VR(R) + Congured_Rx_Window_Size. PDU's
with sequence numbers greater than VR(MR) shall be discarded. This value forms
the upper edge of the receiver window.
Further there are parameters which control the behavior of the RLC entity. These parameters are set by the RRC.
MaxDat - This value indicates the maximum number of retransmissions of a PU.

It is an upper limit of the counter VT(DAT). When the value of VT(DAT) reaches
MaxDat, the transmitting side either initiates a RLC reset or the concerned SDU's
are discarded and the peer entity is informed with a move receiving window SUFI.
Poll_PU - This parameter determines how often the transmitter should poll the
receiver. If VT(PU) reaches this value the poll bit is set and VT(PU) is reset, so this
value represents the upper limit of VT(PU).
Poll_SDU - This parameter also triggers the polling function. Every time VT(SDU)
reaches this value a poll is transmitted to the peer entity.
Poll_Window - This parameter indicates a relative position within the transmitter

window beyond that the transmitter should poll the peer entity, i.e., if the actual
sequence number is near the upper edge of the transmitter window a poll is triggered.
Actually a poll is trigger if
J=
J P oll_W indow,
(4096 + V T (S )
V T (A)) mod 4096

100% :
V T (W S )
25
Congured_Tx_Window_Size - This value denotes the maximum allowed transmit

window size. The transmit window is initially set to this value, but it can be changed
by the peer transmitting entity.
Congured_Rx_Window_Size - This value denotes the receiver window size. The

receiver window is set to this value and can only be changed by the RRC. Normally
the receiver window size and the transmitter window size are set equally.
In addition to the yet mentioned variables and parameters, a set of timers inuence the
functionality and performance of the RLC protocol.
All the expiration values of these
timers are signalled by RRC.
Timer_Poll_Prohibit - This timer is used in order to prohibit transmission of consecutive polls within a certain period. The timer is started every time a PDU with a
set poll bit is transmitted. The next poll is postponed until the expiry of this timer.
Only one poll shall be transmitted when the prohibit timer expires even if several
polls were triggered during the prohibit time.
Timer_Poll_Periodic - This timer ensures a periodically triggered polling. If there

is no PU for tranmission and all PU's have already been acknowledged, the timer
should be restarted without polling the peer entity.
Timer_Status_Prohibit - This timer prohibits the receiving side from sending consecutive status reports within a certain period containing any of the SUFI's LIST,
BITMAP, RLIST or ACK. The timer is started every time a status message is transmitted. No further status message containing the mentioned SUFI's may be transmitted until the timer is expired.
Timer_Status_Periodic - Each time this timer expires the transmission of a status

report is triggered and the timer is restarted.
Timer_Discard - In the transmitter, this timer is started upon reception of a higher

layer SDU. One timer belongs to each SDU. If the SDU has not been acknowledged
when the timer expires, the SDU is discarded and a MRW SUFI is sent to the peer
entity.
In this Section many system parameters are listed which control the functionality of the
RLC layer. Not all of these mechanisms are in use concurrently. The RRC controls which
system variables should be evaluated.
2.3.3.3
Polling Function
The transmitter of AM PDU's can poll the receiver for a status report by setting the poll
bit within the PDU header. There are several triggers for setting the poll bit. RRC controls
which triggers should be used. The following triggers are possible:
26
Last PU in buer - The sender triggers a poll when the last PU in the transmission
buer is transmitted.
Last PU in retransmission buer - The sender triggers a poll when the last PU in the
retransmission buer is transmitted.

Timer based - This trigger produces polls periodically.

Window based - The sender triggers a poll when it reaches a threshold towards the upper edge of the transmission window. This mechanism is performed by the parameter
Poll_Window.
Every Poll_PU - The sender triggers a poll ever Poll_PU PU. Both new and retransmitted PU's are counted.
Every Poll_SDU - The sender triggers a poll every Poll_SDU SDU.
RRC also controls if the poll prohibit function with timer Timer_Poll_Prohibit shall be
used.
2.3.3.4
Status Transmission
The receiver transmits status reports to the sender in order to inform about received and not
received PU's. There are several triggers for sending a status report. RRC again controls
which triggers should be in use. The following triggers are possible:
Receiving a poll request - Every time the poll bit of a PDU header is set, a status
report shall be transmitted.
Detection of missing PU's - If the receiver detects one or several missing PU's it shall
trigger the transmission of a status report to the sender.
Timer based status transfer - This trigger produces status reports periodically.
There is again the capability to delay the transmission of a status report. If the function
Timer_Status_Prohibit is in use, the receiver is prohibited from sending a status report
till the expiry of the timer.
2.3.4 Packet Data Convergence Protocol (PDCP) Layer

This sublayer is standardized in [UMTS-25.323]. It exists only in the user plane and only
for packet-switched services.
It is responsible for the transmission and reception of net-
work layer data units. UMTS supports several network layer protocols providing protocol
transparency for the users of the service. At the moment, IPv4 and IPv6 are supported.
27
Introduction of new network layer protocols to be transferred over UTRAN shall be possible without any changes to UTRAN protocols. Therefore all functions related to transfer
packets from higher layers shall be carried out in a transparent way by the UTRAN network
entities. One task of the PDCP layer is this transparent transmission.
PDCP SDU = IP Packet

IP
TCP
Data
PID CH
Data
PDCP PDU = RLC SDU
Figure 2.18: PDCP SDU and PDU [Loem00]

Another function is to perform header compression and decompression of data streams in
order to increase channel eciency.
The header compression method is specic for each
network layer protocol type. The header compression algorithms and their parameters are
negotiated by RRC for each PDCP entity during connection establishment. How higher
layer protocol data units are treated by the PDCP layer is shown in Figure 2.18. The PID
value within the PDCP header indicates the compression algorithm. The CH eld denotes
the compressed header.
2.3.5 Radio Resource Control (RRC) Layer

The RRC layer, standardized within [UMTS-25.331], handles the control plane signalling
of layer 3 between the UE's and UTRAN. As shown in Figure 2.4, RRC is attached to
all logical channels that transfer control information. Further the RRC layer is connected
to all entities within the UTRAN in order to exchange signalling information. The RRC
protocol handles a large number of signaling tasks. One of those tasks is the establishment,
reconguration and release of radio bearers. At establishment and reconguration of radio
bearers so called radio bearer information elements are assigned to the bearer. These are
values for parameters which inuence the behavior of the whole protocol stack. Table 2.2
presents possible values for RLC parameters and timers.
Some important parameters for the MAC layer are summarized in Table 2.3.
2.3.6 Interaction between Layers

Interaction between layers often is described by means of primitives. Such primitives represent a logical exchange of information between two communicating entities. The primitives
shall not specify or constrain the actual implementation. This slight denition is sucient
for communication between layers within a closed area. Interaction between two entities

Information Element
value
28
unit
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15,
MaxDat (max. number
20, 25, 30, 35, 40
of retransmissions)
Poll_PU
PDU
1, 4, 16, 64
SDU
Poll_SDU
1, 2, 4, 8, 16, 32, 64, 128
Poll_Window
50, 60, 70, 80, 85, 90, 95, 99
1, 8, 16, 32, 64, 128, 256, 512, 768, 1024,
Congured_Tx_Window_Size
1536, 2047, 2560, 3072, 3584, 4095

1, 8, 16, 32, 64, 128, 256, 512, 768, 1024,
Congured_Rx_Window_Size
1536, 2047, 2560, 3072, 3584, 4095

10 - 550 by step of 10,
Timer_Poll_Prohibit
PDU
ms
600 - 1000 by step of 50
Timer_Poll_Periodic
PDU
100, 200, 300, 400, 500, 750, 1000, 2000
ms
Timer_Status_Prohibit
10 - 550 by step of 10
ms
Timer_Status_Periodic
100, 200, 300, 400, 500, 750, 1000, 2000
ms
100, 250, 500, 750, 1000, 1250, 1500,

1750, 2000, 2500, 3000, 3500, 4000,
Timer_Discard
ms
4500, 5000, 7500

Table 2.2: Parameter values for RLC layer [UMTS-25.331]
Information Element
value
unit
TTI
10, 20, 40, 80
ms
max. MAC SDU length
5000
bit
Table 2.3: MAC layer parameters [UMTS-25.331]
which may reside in blocks provided from dierent vendors has to be standardized in much
more detail.
In primitives the common abbreviations are used: Ind : indication, Req :
Request, Resp : Response, Conf : Conrmation.

In the following elaboration I mainly concentrate on user data ows.
A simplied ow
diagram with all mention primitives is shown in Figure 2.20.
2.3.6.1
Interaction between MAC and PHY
The physical layer is terminated at the Node B and the MAC layer protocol is terminated
at the RNC. So interaction between these two layer take place over the connection between
RNC and Node B. This connection is denoted as Iub-interface [UMTS-25.435].
In this
section I briey describe the user plane protocol for DSCH over the Iub-interface.
The
structure of the data frame for DSCH is shown in Figure 2.19(a). The elements within the
data frame do have the following meaning:
Header CRC and payload CRC provide error identication.

29
The frame type (FT) bit indicates whether the frame is a data or a control frame.
The connection frame number (CFN) is the frame counter used for transport channel
synchronization between UE and UTRAN. A CFN value is associated to each TBS.
The TFI describes length and number of transport blocks transmitted within one
TTI.

Power oset indicates the preferred PDSCH transmission power level.

Code number, spreading factor and MC info are used in order to indicate the actual
PDSCH code management to the Node B, see Section 2.3.1.1.
Additionally to the data frame explained above, there is a control frame for DSCH TFCI
signalling. This frame is used in order to inform the Node B of the currently used TFCI.
The DSCH TFCI signalling frame is sent once every frame interval (10ms) as long as there
is DSCH data for transmission.
Header CRC
FT
CFN
Spare
Spare bits 74
Header
(cont)
Header
User Buffer Size
Spare
(cont)
First TB
Spare bits 74
(cont)
(cont)
Spare bits 20
Num of SDU
Code number
MC Info
CmCHPI
MACc/sh SDU Length
TFI
Power Offset
SF
FT
Header CRC
MACc/sh SDU 1
(cont)
Pad
(cont)
Last TB
Payload
(cont)
(cont)
Pad
Spare Extension
Payload CRC
Spare bits 74
MACc/sh SDU n
Payload
(cont)
(cont)
Payload CRC
(cont)
(cont)
(a) Iub-Frame
(b) Iur-Frame
Figure 2.19: DSCH Data Frames on Iub-interface (a) [UMTS-25.425], and Iur-interface (b)
[UMTS-25.435]
2.3.6.2
Interaction between MAC-d and MAC-c/sh
In handover situations the functionality of the RNC is split into a SRNC and a DRNC.
In those situations, MAC-d resides in the SRNC and MAC-c/sh is placed in the DRNC
30
because MAC-c/sh is responsible for scheduling and this has to be done in the CRNC which
is also the DRNC.
As already mentioned above, the link between two RNC's is denoted as Iur-interface, which
is standardized in [UMTS-25.425]. In this section I describe how a common channel, particularly the DSCH, is transmitted over this link. This protocol has to be standardized in
detail because the concerned entities can reside in two dierent RNC's. These RNC's may
have been developed from dierent vendors. In Figure 2.19(b) the structure of the DSCH
data frame on the Iur-interface is shown. The new entries within this frame do have the
following meaning:
The common transport channel priority indicator (CmCh-PI) is a relative priority of

the data frame and the SDU's included. The value ranges from 0 which indicates low
priority to 15 which indicates highest priority.

The number of SDU's within the frame is also indicated.

The user buer size indicates the amount of data in the buer for a given common
transport channel priority. This value ranges from 0 to 65535 bytes.
A MAC-c/sh SDU in this case additionally denotes the C/T eld of the MAC header.
It's length is also transmitted to the MAC-c/sh.
Further there are several control frames which are responsible for ow control, capacity
request and capacity allocation. A capacity request message is sent by the SRNC to the
DRNC in order to indicate the actual user buer size. This knowledge is necessary since
scheduling is done in the DRNC and therefore the amount of data for transmission must
be known. A capacity allocation message is sent by the DRNC to the SRNC in order to
assign resources to the users within the cell.
2.3.6.3
Interaction between RLC and MAC
The following primitives are used between MAC and RLC:
The MAC-DATA-Req primitive is used by RLC to forward RLC PDU's for transmission to the MAC layer.
Additionally the parameter Buer Occupancy (BO) is
indicated. This parameter indicates the amount of data that is currently queued for
transmission in the transmission buer.
The MAC-DATA-Ind primitive is used by MAC to forward received RLC PDU's to

the RLC layer.
The MAC-STATUS-Ind primitive is used by MAC to permit the RLC layer to send
a certain number of PDU's to MAC.
The MAC-STATUS-Resp primitive is used by RLC to acknowledge a MAC-STATUSInd primitive in the case that there is nothing to send. This primitive is also used to
indicate the current buer occupancy to MAC.

2.3.6.4
31
Interaction between PDCP and RLC
The following primitives between the RLC and the PDCP layer are used for user data
transfer in acknowledged mode:
The RLC-AM-DATA-Req primitive is used by higher layers to request transmission

of a higher layer PDU in acknowledged mode.
RLC-AM-DATA-Ind is used by RLC either to deliver transmitted PDU's to higher

layers or to indicate discarded ones.
RLC-AM-DATA-Conf is used by RLC to conrm to higher layers the transmission of

a higher layer PDU.
2.3.6.5
Interaction between Higher Layers and PDCP
The PDCP-DATA-Req primitive is used by the higher user-plane protocol layer in order to
request transmission of a higher layer PDU. PDCP-DATA-Ind is used by the PDCP layer
in order to deliver a PDCP SDU which has been correctly received from the peer entity.
2.3.6.6
Summary
Concluding this section, in Figure 2.20 an example of acknowledged-mode data transfer on

DSCH is presented. In order to denote transmission over either the Iub or the Iur interface
I introduce the following primitives:
Iur-Cap-Req : The DSCH capacity request provides means for the SRNC to request
DSCH capacity.
Iur-Cap-Alloc : DSCH capacity allocation is generated within the DRNC in order to

assign resources to the SRNC.
Iur-Data-Req : DSCH data request indicates the transmission of a data frame from
the SRNC to the DRNC in the UTRAN.
Iub-Data-Req : DSCH data request indicates the transmission of a data frame from
the DRNC to the Node B in the UTRAN.
I further introduce the primitive PHY-Data-Ind for transmission of a received data frame
from the physical to the MAC layer within the UE. Status messages are sent back on the
DCH indicated by the primitive Data ACK.
It's important that every TTI the scheduling entity in the MAC-c/sh layer assigns credits
to the RLC, i.e., the PDU's remain in the transmission buer within RLC till the RLC
block gets credits for transmission.
RLCDATAConf
IurDataReq
MACDATAReq
IurDataReq
Radio
Transmission
DCH: Data ACK
IubDataReq
PHY
Node B
IubDataReq
Scheduling
IurCapAlloc
MACSTATInd
MACDATAReq
MAC
c/sh
DRNC
Scheduling
IurCapReq
MACd
SRNC
MACSTATResp
RLC
SRNC
RLCDATAReq
PDCP
higher
layer
PDCP_DATA_Req
SRNC
SRNC
PHYDataInd
PHYDataInd
PHY
UE
UE
MACDATAInd
UE
higher
layer
UE
PDCPDATAInd
PDCP
RLCDATAInd
RLC
MACDATAInd
MAC
UE
Figure 2.20: Data transfer over RLC acknowledged mode
32
Chapter 3
Propagation Environment
Simulations including higher layer protocols are computationally very costly even for trac
limited to one cell. For each user the whole UTRAN protocol stack has to be established.
Since radio conditions in a CDMA system depend on the interference caused by neighboring
cells, it is necessary to observe at least one tier around the concerned cell.
But it is
computationally not possible to simulate the whole protocol stack for each user within this
area. Therefore I consider inuences of neighboring cells with several parameters. I provide
a model which determines the interference from other cells depending on the location of the
user. I further calculate the power consumption of certain services depending on distance
between mobile and base station.
3.1 Cell Conguration

In the following computations I assume a hexagonal network structure with 19 cells, i.e,
two tires around the considered cell. The distance between two base stations is assumed to
be 2000 meter, hence the cell radius is 1155 meter. The cell structure is shown in Figure
3.1. I assume omni-directional antennas.
11
12
13
15
16
14
10
19
17
18
Figure 3.1: Cell conguration
33
CHAPTER 3. PROPAGATION ENVIRONMENT
34
3.2 Channel Model

In this section I provide the calculation of the received signal power in a macrocellular
environment. The channel model I use is proposed in [UMTS-25.942]. This model is based
on the COST-Walsch-Ikegami-Model [COST231] from the COST action 231. Additionally
shadow fading is added.
3.2.1 COST-Walsch-Ikegami-Model
This model is suitable for macro cell propagation in urban and suburban areas where the
buildings are more or less equally high. In NLOS-situation the transmission loss is composed
L0 , multiple screen diraction loss Lmsd and roof-top-to-street diraction

and scatter loss Lrts [COST231]:
of free space loss
L = L0 + Lmsd + Lrts :
(3.1)
Free space loss is determined for a distance of 20m. The multiple screen diraction takes
the width of the streets and their orientation into account. The heights of the buildings and
their spatial separations along the radio path are considered by
Lrts .
With the following
assumptions,

the base station antenna height is 15 meters above the average rooftop
the dierence between the average rooftop height and the mobile antenna height is
10.5 meters

the average separation between rows of buildings is 80 meters

the horizontal distance between the mobile and the diracting edge is 15 meters
and the carrier frequency is 2 GHz
the formula becomes [UMTS-25.942]:
L = 128:1 + 37:6 Log10 (R) ;
(3.2)
where L denotes the path loss in dB, and R denotes the distance between base station and
user equipment in kilometers. Additionally, the path loss is lower bounded by the free space
loss.
35
3.2.2 Shadow Fading

Shadow Fading is the slowly varying component of propagation caused due to obstructions
from buildings, hills or something else. It is modelled log-normal distributed with a mean
of 0 dB and a standard deviation of
db.
In [UMTS-25.942] a standard deviation of 10 db
is proposed. So additionally to the path loss calculated from the COST-Walsch-IkegamiModel, log-normally distributed shadow fading (
LogF ) with zero mean and standard devi-
ation of 10 dB is added. Hence the resulting path loss becomes
P athloss = L + LogF :
(3.3)
This model is suitable for static simulations. In my simulation, the moving mobile observes
variations of the shadow fading.
3.2.3 Spatially Correlated Shadow Fading

Due to movement of the users, shadow fading varies depending on the location of the users
[Kazmi01]. In the following
LogF (t) is
the shadow fading random variable at time t. dt
denotes the time step due to time discrete processing units. Then the shadowing variable
LogF (t) at time t can be calculated as follows
LogF (t) = a LogF (t dt) + b X
(3.4)
where a and b are constants and X is a random variable and has a log-normal distribution
with 0 dB mean and
dB standard deviation.
The random variables
LogF
and
in
Equation 3.4 are independent random variables. Using Equation 3.4 the second moments
can be derived:
E [LogF 2 (t)] = a2 E [LogF 2 (t dt)] + b2 E [X 2 ]

p
1 = a2 + b2 or b = 1 a2
(3.5)
(3.6)
Inserting Equation 3.6 into Equation 3.4 and solving the dierential equation leads to
LogF (t) = a LogF (t dt) +

a = exp(
a2 X
0:5 dd )
(3.7)
(3.8)
d denotes the distance covered by the

mobile within the time interval dt depending on its velocity v . In [COST259] a correlation
distance dc of 11 meters for macro cell environment is proposed. In Figure 3.2 the compariwhere
dc
is the correlation distance and parameter
son of uncorrelated shadow fading and spatially correlated shadow fading with a correlation
distance
dc of 11 meters, a user velocity v of 3 km/h is shown.
as 10 ms.
The time step
dt is assumed
36
uncorrelated shadow fading, dt=0.01s
Log F
correlated shadow fading, dt=0.01s, v=3km/h, dc=11m
30
30
20
20
10
10
Log F
10
10
20
20
30
0
10
20
30
40
50
30
0
10
20
t in s
30
40
50
t in s
Figure 3.2: Spatially uncorrelated (left side) and correlated (right side) shadow fading
3.2.4 Received Signal Power

The
received
signal
(T x_P ower ), the

G_Rx) as well as
power
path loss
Rx_P ower) depends

(P athloss), transmitter
(
on
the
transmitted
signal
power
G_T x,
and receiver antenna gain (
losses in cables and connectors. So
Rx_P ower
is calculated in dB as
[UMTS-25.942]:
Rx_P ower = T x_P ower Max(P athloss G_T x G_Rx ; MCL) :
(3.9)
Since the base station antenna is placed much higher than the antenna of the mobile, the
path loss cannot fall below a certain value, which is denoted as minimum coupling loss
MCL).
It is dened as the minimum path loss including antenna gains and cable losses.
For my simulation I take the proposed values from [UMTS-25.942], shown in Table 3.1.
Tx_Power
43 dBm
Tx_Power
43 dBm
G_Tx (including cable loss)
11 dB
G_Rx
0 dB
MCL
70 dB
Table 3.1: Simulation parameters (1)
3.3 Interference Calculations

In this section I estimate the interference within the central cell of Figure 3.1. I propose
a method for calculating the ratio of other cell to own cell interference depending on the
users position.
In the downlink, users are separated by orthogonal codes. Without multipath propagation,
the orthogonality between the codes remain and there would be only interference from
37
neighboring cells. Due to the high delay spread in macro cells, orthogonality is lost and
the mobile will observe signals of other users within the cell as interference. This fact is
described by the orthogonality factor
, which is typically 0.4 in macro cells. = 0 indicates
perfectly orthogonal intra-cell users.
Iown is simply calculated by the path loss to the own base station
L1 (x; y ), the base station power P1 , the signal power of the dedicated application PApp and
the orthogonality factor :
P1
P PApp
=

K
(3.10)
Iown(x; y ) = 1
L1 (x; y )
L1 (x; y )
The intracell interference
with
K=
P1
PApp
P1
(3.11)
Iother is the accumulated received power of all base stations

in the rst and the second tier. This depends on the path loss Li (x; y ) between base station
i to the considered position (x,y) and the base stations transmit power Pi .
The interference from other cells
Iother (x; y ) =
Pi
:
i=2 Li (x; y )
19
X
I (x; y ) can be determined as follows:
Then the ratio of other cell to own cell interference
I
I (x; y ) = other
Iown
(3.12)
P19
Pi
Li (x;y)
P1
L1 (x;y) K
= i
=2
(3.13)
If we make the following assumptions:

1. All base stations do have equal transmit power:
P1 = P2 = : : : = P19 .
2. Cells are highly loaded without dominant users. Then the signal power of the con-
PApp is small against the

station, so K ! 1.
sidered user
overall transmit power
P1
of the serving base
Then Equation 3.13 is independent from transmit powers and becomes
I (x; y ) =
19
1 :
L1 (x; y ) X

i=2 Li (x; y )
(3.14)
I (r) = I (x; y ) with r = x2 + y 2
I (x; y ) is evaluated with the path loss from Equation 3.2 in Figure 3.3.
(3.15)
If we further take
the mean value over constant distances from the base station according to Equation 3.15
the average ratio of other cell to own cell interference
I (r) depending only on the distance
between user and base station is obtained. This is shown in Figure 3.4. With this result it
is possible to evaluate the power consumption of certain services depending on the location
of the user.
38
other cell to own cell interference
40
30
I(x,y)
20
10
0
1000
1000
500
500
0
y
500
500
1000
1000
Figure 3.3: Interference ratio depending on the position of the user

other cell to own cell interference
12
10
8
I(r)
6
0
0
200
400
600
800
Distance from BS
1000
1200
Figure 3.4: Average interference ratio depending on the distance between base station and
the mobile
3.4 Coverage Evaluations

The signal to noise and interference ratio can be calculated from the following equation
SINR =
where
Eb
Eb
I0 + N0
= (P
is the energy per user bit,
N0
SF PApp=L1
PApp)=L1 (1 + I (r)) + N0
(3.16)
is the noise energy within the system bandwidth,
I0 is the total interference power, PApp is the power of the considered application, P1 is the
total transmit power of the base station, L1 is the path loss, is the orthogonality factor,
SF is the spreading factor and I (r) is the other cell to own cell interference ratio.
39
Link level simulations are performed at chip level, including all aspects such as coding,
power control, diversity, the receiver architecture, . . . . They provide the required
SINR
for dierent types of services. The evaluations in most cases are done for several channel
models.
The results from the ARIB IMT-2000 Study Committee [ARIB98] for the Pedestrian A
channel model for the downlink are shown in Table 3.2.
They don't provide a value for
UDD 144, but compared with the simulation results from the Vehicular A channel it seems
reasonable to assume the same value as for UDD 64. Detailed conditions and assumptions
for these simulations can be found in [ARIB98, Annex3]. The term UDD is the abbreviation
for unconstrained delay data service and denotes packet switched background data.
Service
required
SINR @ BLER = 10%
UDD 64
1.2 dB
UDD 144
1.2 dB
UDD 384
0.1 dB
Table 3.2: Link level simulation results for UDD services, Pedestrian A channel in downlink
direction [ARIB98, Annex3]
Now the required power for a certain service depending on the actual transmit power can
be calculated. Equation 3.16 leads to
PApp(r) =
SINR N0 L1 + SINR (1 + I (r)) P1

:
SF + SINR (1 + I (r))
(3.17)
Evaluating Equation 3.17 with the parameters in Table 3.3 and Table 3.2 and the calculated
path loss including shadow fading provides the required power for the designated service.
max. transmit power
orthogonality factor
noise power
N0
P1

20 W
0.4
-105 dBm
Chapter 4
Scheduling Algorithms
In future mobile networks many dierent types of applications will be available.
Some
applications require certain characteristics from the assigned resources in order to work,
others are more insensitive. Further, there will be dierent kinds of users, which do have
distinct quality demands. This arises the need for assigning resources in a smart way. On
the one hand in order to meet the requirements of the users, and on the other hand in order
to utilize resources most eciently.
4.1 Introduction
Applications can be classied into two groups [Keshav97]:
Best-eort
applications don't require certain performance in order to work, they accept
whatever the network assigns to them. For example, a le or a web page download of
course would prefer high bandwidth and low end-to-end delay, but it also works with
little resources.
Guaranteed-service
applications need a certain amount of resources in order to work
well, e.g., interactive multimedia requires a certain bandwidth as well as a small

round-trip delay.
Now it's the schedulers task to provide guaranteed-service applications with their demanded
resources and to share the remaining resources equally among all best-eort applications.
A scheduling discipline must satisfy four, sometimes contradictory, requirements [Keshav97]:
performance bounds, fairness and protection, admission control and ease of implementation.
1. Performance bounds:
An operator can guarantee performance only by reserving some network resources.
40
CHAPTER 4. SCHEDULING ALGORITHMS
41
Performance bounds can be expressed deterministically or statistically. A deterministic bound holds for every packet. Whereas a statistical bound is either expressed as
a mean value or a 95-percentile. This percentile expresses that the bound is met by
95% of all packets. Deterministic bounds of course require more network resources to
be reserved than statistical bounds.
General performance parameters are bandwidth, delay, delay jitter, and packet loss
due to transmission errors or full queues.
2. Fairness and protection:
Fairness is a desirable property of scheduling algorithms serving equal services.
If
there are several classes of services, fairness should be provided within every class.
Fairness means that resources are shared equally among all services which are ready
to send.
Protection means that a misbehaving user must not aect the performance of other
connections.
3. Admission Control:
Quality can be provided to the services only if the number of users within the network is bounded. Therefore, the admission control entity decides for a new service,
depending on the current load, whether it is accepted or not. By means of a schedulable regions, as shown in Figure 4.1, admission control can easily be performed. The
schedulable region includes all combinations of services which can be served. If the
resulting combination lies outside the schedulable region, the new service has to be
denied. The combination shown in Figure 4.1 depicts the case that no further service
can be accepted. The dimension of the schedulable region equals the number of trac
classes.
This technique also reveals the eciency of the scheduler and therefore by means of
schedulable regions, dierent schedulers can be compared.
# Class 2 users
C2
# Class 1 users
C1
Figure 4.1: Schedulable region [Keshav97]
4. Ease of implementation:
The scheduling algorithm has to do its decisions in real time, so the complexity of the
42
algorithm determines the hardware requirements. Therefore it is necessary to compose

fast and easy implementable algorithms in order to keep hardware requirements and
time for computation low.
The design of a scheduler oers several degrees of freedom.
First of all, the number of
priority levels in the system depends on the number of delay classes which are supported.
In general there are at least three priority levels: high priority for status messages, medium
priority for guaranteed services trac and low priority for best-eort trac. Another degree
of freedom is the service order within one priority level. The scheduler either serves packets
from the same level in the order of their arrival or it oers means of reordering which lead
to a higher complexity.
Schedulers are capable of improving transmission for certain services.
However, this im-
provement is at the expense of worse performance for other services. This fact is revealed
by the conservation law [Kleinr75]:
N connections at a scheduler. Trac at connection i arrives at a mean

i and the mean service time for a packet from connection i is xi . Then i = i xi is
the mean utilization of the link due to connection i. If the mean waiting time for packets
of connection i is denoted as qi , then the conservation law becomes:
Consider a set of
rate
N
X
i=1
i qi = const
for schedulers which are only idle if all queues are empty. Since this equation is independent
of the scheduling discipline, reduction of the delay for a certain connection results in a higher
delay of other connections.
4.2 Scheduling Best-Eort Applications

In this section scheduling schemes for serving best-eort applications are presented
[Keshav97].
Of course a combination of several methods is possible by combining their
individual requirements.
4.2.1 First-In-First-Out Scheduling

First In First Out (FIFO) is the simplest scheduling scheme. There is only one queue for
all the users sharing the same resources. Packets of all users are stored in the order of their
arrival into the queue, and they are transmitted in the same order as well. The scheduler
cannot dierentiate between packets from dierent users, hence there is no possibility to
assign higher priorities.
There is also no protection against misbehaving users.
So this
scheme is only applicable for equal users and in the case the common shared resource is
immensely oversized.
43
4.2.2 Weighted Round Robin

The simplest form of a fair scheduling scheme is Round Robin. Therefore every user requires
its own queue. The scheduler assigns the same amount of resources to all users successively
in a cyclic manner, empty queues are skipped. If a user provides less data, the remaining
part is shared among all the others. Simple Round Robin only can serve equal users. If
users have dierent requirements, weighted Round Robin shall be applied. Thereby every
user is served according to its data rate requirements. Due to the granularity of at least
one packet and due to the restriction to certain transport formats, fairness can be provided
only over longer periods.
4.2.3 Priority Scheduling

Priorities can either be assigned statically to services, or dynamically to single packets
according to their delay and rate requirements.
Even in systems without sophisticated
resource sharing mechanisms, status messages do have higher priority than user data. In
a priority scheduling scheme packets of a certain priority are only served if there are no
packets for transmission with higher priority. This method is called priority with exhaustive
service.
According to the scheduler architecture, either Round Robin or rst-in-rst-out
scheduling shall be applied for packets within the same priority level.
4.2.4 Queue Length Dependent Scheduling

With this approach the users are served according to their queue size. Therefore every user
requires its own queue and a mechanism to count the number of packets stored in it. So
either users with long queues or users with short queues can be prioritized, which is denoted
as Long Queue First (LQF) respectively Short Queue First (SQF) scheduling.
4.2.5 Channel State Dependent Scheduling

Due to fading, the wireless channel is subject to strong variations of the received signal
strength. By the means of power control, the received signal is kept more the less constantly
at each mobile equipment at the expense of power consumption at the base station. But the
available power at the base station is limited. Hence it is advantageous to serve those users
which do have good channel conditions at the present time. This scheduler gives higher
priority to users with good channel conditions. Therefore, radio link measurements must
be accessible to the scheduler.
4.3 Scheduling Guaranteed-Service Applications

Scheduling algorithms for guaranteed-service applications [Keshav97] ensure to meet the
negotiated service requirements. This algorithms can be optimized for certain parameters
44
like packet delay in the case of earliest-due-date scheduling or transmission rate in the case
of rate-controlled scheduling.
4.3.1 Earliest-Due-Date Scheduling

This scheduling scheme provides quality of service regarding to a maximum packet delay.
Hence, at the arrival of each packet an expiration deadline is calculated depending on the
connection state which is assigned to the packet.
this deadline.
The packets are served according to
If the system is overloaded, some packets will miss their deadline. Hence
admission control has to prevent such situations. This scheme could be implemented by
means of a linked list. However, inserting a packet into the list is computationally expensive.
Another approach is to realize this scheme with several late queues which do have distinct
priorities. Packets are moved to queues according to their remaining time till expiration.
The nearer the expiration deadline of a packet, the higher the priority becomes.
4.3.2 Rate-Controlled Scheduling

A rate-controlled scheduler consists of a regulator and a scheduler.
The regulator is re-
sponsible for shaping the trac of each service in order to guarantee conformance with the
desired trac pattern. Hence, the scheduler receives packets with a predened rate. The
scheduler then controls the transmission order of packets belonging to dierent services.
With this approach it is possible to assign to one service simultaneously a lower bandwidth
with higher delay requirements.
4.4 Comparison of Scheduling Algorithms

In Table 4.1 the scheduling algorithms described in Section 4.2 and 4.3 are summarized.
4.5 Scheduling in UMTS

In UMTS release 99, IP packets are segmented into RLC PDU's within the RLC layer.
These PDU's are stored into the transmission buer which is also located in the RLC layer,
whereas the scheduler resides in the MAC layer. Due to the fact that the interaction between
layers is standardized, the MAC layer doesn't know when packets arrive at the RLC layer.
Sophisticated scheduling algorithms, like Earliest-Due-Date, require this information. So,
without extensions to the current standard, algorithms for guaranteed-service application
scheduling are not feasible.
In Figure 4.2, a general overview of scheduling in UMTS is presented. For my simulations
I assume that the scheduler is aware of the buer occupancy, the nominal rate and power

name
summary
First In
Packets are served in
First Out
the order of their ar-
(FIFO)
rival.
Round
Resources
Robin
tributed
(RR)
and fair manner.
45
advantages
disadvantages
No protection between
Easy to implement.
users.
No priorities possible.
are
in
discyclic
Provides fairness and

protection.
In case of several user

classes weitghted RR
shall be applied.
Priorities are assigned

to packets either statically or dynamically.
Priority
Packets with a higher
Scheduling
priority
are
rst.
served
Within
one
priority class, RR or
Flexible
priority
as-
signment
possible.
Protection
between
dierent
priority
High
implementation
complexity.
classes.
FIFO shall be applied.

Queue
Length
Dependent
Scheduling
Channel
State
Dependent
Scheduling
Users are served
cording to their queue
Easy to implement.
length.
Users are served
ac-
cording to their actual

channel condition.
Each
site queue size often

have very poor performance.
packet
Earliest-
signed
Due-Date
deadline.
Scheduling
served
an
is
as-
expiration
Packets are
according
to
this deadline.
Rate-
Users with the oppo-
ac-
Less power consump-
Higher delay, and less
tion.
throughput.
This scheme provides
Computationally
absolute QoS in terms
expensive
and
high
of a maximum packet
implementation
com-
delay.
plexity.
Combination of a reg-
Enables
Controlled
ulator
of
Scheduling
uler.
and
sched-
combination
dierent
quirements.
QoS
re-
Very high implemenation complexity.
Table 4.1: Comparison of scheduling algorithms
measurements of each user. In the following subsections I will present the scheduling algorithms I investigated in the further elaboration of my thesis. I also explain the transport
formats my simulator is allowed to use.
4.5.1 Transport Format Selection

In Section 2.3.1.1 transport format selection is explained and in Appendix C some examples
of possible transport formats are shown. In this section I describe how transport format
46
User 1
User N
IP
RLC
RLClayer
credit assignments
DTCH
DTCH
Scheduling algorithm
MAClayer
buffer occupancy
channel measurements
past allocated resources
Figure 4.2: Scheduling in UMTS
selection is done within my simulator.

My simulator is allowed to assign transport format TF5 from Table C.1, TF5 from Table C.2
and TF4 from Table C.3. This results in one of the following transport format combinations:

1 user can send 12 PDU's every 10 ms,

2 users can send 9 PDU's every 20 ms,
4 users can send 4 PDU's every 20 ms, or
2 users can send 9 PDU's and 2 users can send 4 PDU's every 20 ms.
The RLC PDU length is xed to 336 bytes, see Appendix C.

of assigned PDU's varies between these formats.
The aggregate number
This results from dierent coding and
interleaving schemes performed for dierent transport formats in the physical layer.
If a user has less PDU's waiting for transmission than it is permitted to send, then padding
PDU's are transmitted.
4.5.2 Round Robin

As already mentioned, Round Robin distributes resources in a cyclic and fair manner to
all active users with PDU's waiting for transmission. Therefore the scheduler requires the
47
nominal bit rate of every user. Further, the scheduler needs to know every TTI those users
who want to transmit.
In the case of equal users, i.e.
all users belong to the same trac class, I implemented
Round Robin in two dierent versions:
RR_384:
Every TTI one user is allowed to send 12 PDU's. The users are served one by
one in a cyclic manner.
RR_64:
With this scheme, there are four users concurrently permitted to send four
PDU's each. Of course the users are again served cyclically. If there are less
than four users with PDU's waiting for transmission, the following scheme will
be applied:
3 users:
One user is allowed to send 9 PDU's, and 2 users are allowed to send
4 PDU's each. At consecutive TTI's alternate users are preferred.
2 users:
Both users are allowed to send 9 PDU's every TTI.
1 user:
In this case the single user is allowed to send 12 PDU's every TTI.
4.5.3 Short Queue First (SQF)

With this scheduler, users with only a view packets waiting for transmission are prioritized
against users with a lot of packets. Therefore, the scheduler of course needs to know the
buer occupancy and the nominal bit rate.
In the case of equal users I implemented the following two schemes:
SQF_384:
Every TTI the user with the shortest queue is allowed to transmit 12 PDU's.
With this scheme there will be a high number of padding PDU's.
SQF_64:
With this scheduler, every TTI the four shortest queues are allowed to transmit
four PDU's. If there are less than four users with PDU's waiting for transmission, a similar procedure as seen above is applied:
3 users:
The user with the shortest queue is allowed to send 9 PDU's, and
the two others are allowed to send 4 PDU's each.
2 users:
1 user:
In this case the only user with PDU's is allowed to send 12 PDU's
every TTI.
48
4.5.4 Long Queue First (LQF)

In contrast to SQF, LQF gives higher priority to those users with long queues.
Again I
provide two schemes:
LQF_384:
Every TTI the user with the longest queue is allowed to transmit 12 PDU's.
In this case the number of padding PDU's will not turn out as a problem.
LQF_64:
This scheme is equal to the scheme provided for SQF_64 except that shortest
has to be replaced by longest.
4.5.5 Weighted Scheduler (WS)

In this section I introduce two scheduling algorithms. One algorithm is based on Round
Robin and the second one is based on Short Queue First. Additionally to the standard functionality of RR and SQF, these algorithms consider buer occupancy, the current power
situation due to shadow fading and past credits allocated to the users. From these parameters weights are calculated. These weights decide which user is currently served.
Buer occupancy is considered as shown in Figure 4.3 and in Equation 4.1.
1
0.8
0.6
w
BO
0.4
0.2
0
0
200
400
600
800
1000
BO
Figure 4.3: Weight calculation for buer occupancy
wBO =
The actual power situation, i.e.
1+
BO
2 :
(4.1)
100
the shadow fading, inuences the weight calculation as
shown in Equation 4.2. Figure 4.4 also points out this relation:
wpower =
8
>
<
>
:
1
0:5
0
LogF=40 dB
: LogF < 20 dB
: 20 dB < LogF < 20 dB
: LogF > 20 dB
(4.2)
49
1.2
1
0.8
0.6
wPower
0.4
0.2
0
0.2
40
30
20
10
10
20
LogF
30
40
in dB
Figure 4.4: Weight calculation for shadow fading
A further criteria is the mean number of recently allocated credits to the users. Therefore,
every time a user has PDU's waiting for transmission, both the actual number of assigned
PDU's and the TTI are stored into a buer. In this buer the last 200 such pairs are stored.
With this, the mean number of recently allocated PDU's per 10 ms can be calculated as:
1
0.8
0.6
w
credits
0.4
0.2
0
0
4
6
credits/credits
10
12
UDD
Figure 4.5: Weight calculation for recently allocated PDU's
credits =
P200
i=1
(Num:
of P DU 0 s)i
:
P
200
=1
T T Ii
(4.3)
The target number of assigned PDU's of course depends on the nominal bit rate of the
users. Hence, the variable
creditsUDD
is introduced which indicates the target number of
PDU's assigned per 10 ms:
8
>
<
>
:
2
creditsUDD = 4:5
12
for UDD_64
for UDD_144
for UDD_384
In Equation 4.5 the calculation of the weight for recently assigned PDU's
(4.4)
wcredits is shown.
Figure 4.5 also represents this relation. It is chosen that way, that a user that obtains the
50
target PDU's results in a weight of 0.2:
wcredits =
credits
1 + 4 credits
UDD
(4.5)
These calculated weights are now linearly combined to a single weight:
w = (g1 wcredits + g2 wpower + g3 wBO )

The parameters
g1 + g2 + g3
(4.6)
g1 , g2 and g3 do have the following meaning:
By increasing parameter
g1
it is possible to reduce the number of resigned users
compared to the SQF-scheduler.
g2
it is possible to reduce the mean power consumption at
the expense of a lower active session throughput.
g3
the properties of SQF, like high throughput, come into
eect.
implemented
this
concept
in
various
realizations
(WS_SQF_64,
WS_SQF_384,
WS_RR_64 and WS_RR_384).

The Weighted Scheduler based on SQF provides the following functionality:
WS_SQF_384:
Every TTI the user with the highest weight is allowed to transmit 12
PDU's.
WS_SQF_64:
Four users with the highest weights are allowed to transmit four PDU's
each. If there are less than four users I use a similar approach as for SQF_64
and LQF_64:
3 users:
The user with the highest weight is allowed to send 9 PDU's, and
the two others are allowed to send 4 PDU's each.
2 users:
1 user:
In this case the only user with PDU's is allowed to send 12 PDU's
every TTI.
If the parameters
g1 < 0.
g2
= 0 and g = 0, this scheduler acts as SQF if g

3
So with appropriate values for parameter
> 0 and as
LQF if
g1 , g2 and g3 it is possible to get improved
scheduling performance.
The Weighted Scheduler based on RR doesn't consider BO, hence
is implemented as follows:
g 3 = 0.
This scheduler

WS_RR_384:
51
If the weights of all users are below a certain threshold
ts ,
RR_384 is
performed. Otherwise the user with the highest weight is allowed to transmit
12 PDU's. After serving users due to high weights, Round Robin continues with
that user following to the last one served by the previous Round Robin cycle.
WS_RR_64:
If the weights of all users are below a certain threshold
ts ,
RR_64 is per-
formed. If not, the following will be performed:

1 weight >
ts :
This user is allowed to transmit 12 PDU's. If its buer occu-
pancy is less or equal 9, only 9 credits are assigned and the remaining
PDU's are distributed by the Round Robin algorithm. If
BO 4,
then only 4 credits are assigned and again the remaining PDU's are
used for RR_64.
ts : These two users are allowed to transmit up to 9 PDU's each. If

BO of a user is less or equal 4, the remaining PDU's are distributed
2 weights >
by RR_64.
3 weights >
ts :
Two users are allowed to transmit 4 PDU's each, the user with
the highest weight is assigned 9 credits. If its
BO 4, the remaining
PDU's are distributed by RR_64.

4 weights >
ts :
Each user is allowed to transmit 4 PDU's.
more than 4 weights >
ts :
The 4 users with the highest weights are allowed to
transmit 4 PDU's each.
g1 = 0 and g2 = 0, this scheduler acts as RR. So with appropriate values

for parameter g1 , g2 and ts it is possible to get improved scheduling performance.
If the parameters
Chapter 5
Simulation Environment
For investigations of the protocol behavior and the performance of the scheduling algorithms I use the discrete event simulator OMNET++ . OMNET++ consists of a rich
C++ library which enables convenient generation of simulation programs. The simulation
tool OMNET++ is described in Appendix B.
In Section 5.1, I describe the basic structure of my simulation environment. In Section 5.2,
the implementation details are shown.
5.1 Simulation Procedure

Initialization
start
session
start
session
start
session
GEN
Sender
RLC
MAC
Radio Resource
Control
Evaluation
start next
packet call
send
statistics
send
statistics
send
statistics
Data ACK
MAC
Receiver
RLC
SINK
user 3
user 2
user 1
Figure 5.1: Schematic owchart of the simulation procedure
A simulation run consists of three phases: Initialization, Simulation and Evaluation. These
phases are described in the following:
1. Initialization
During the initialization phase the Radio Resource Control (RRC), which controls
and monitors the whole simulation, is established. Simulation parameters are loaded
and initial values for random generators are set.
52
CHAPTER 5. SIMULATION ENVIRONMENT
53
2. Simulation
The simulation phase is controlled by the RRC. Users are generated according to a
Poisson process. Every time a new user enters the system, the whole protocol stack for
this user is established. This includes RLC, MAC-d and MAC-c/sh on both UTRAN
and UE side, as well as the trac generator at the UTRAN side and the sink at the
UE side. MAC-c/sh at the UTRAN side is established only once, since this entity is
common to all users in the system.
When the protocol stack is established, the trac generator is set up in order to start
the session by generating IP packets from the rst packet call.
These packets are
segmented into RLC PDU's and stored at the RLC layer. Transmission to the peer
RLC entity is performed according to Figure 2.20. The RLC PDU's are reassembled
into IP packets at the RLC entity of the receiver and transmitted to the sink. After
the last IP packet of a packet call is received by the sink, the reading time is started.
After this time, the sink sends a request to the trac generator in order to start the
next packet call.
If the last packet call from the session is completely received at the sink, the receiver
sends statistics to the RRC and the user is deleted from the system.
The simulation phase is terminated after a certain, predened simulation time limit.
If this time limit is reached, all users are deleted from the system.
3. Evaluation
In the evaluation phase, mean values and distribution functions are calculated and
written into log-les.
5.2 UMTS Simulator

In Figure 5.2, the graphical representation of my simulator with ve users is shown. This
is the topmost window of the graphical user interface. Each block can be double-clicked
which enables inspection of the topology and the variables within the dedicated module.
The dots within the network represent messages currently sent on the corresponding link.
By double-clicking these dots the type, length, source and destination module and additional
parameters of the message can be inspected.
The blocks in the upper side of the gure depict the protocol stack at the UTRAN side
including the trac generator. In the middle part there are both one MAC-c/sh block and
one RRC block for all the users within the simulated cell. In the inferior part of the gure
the protocol stack of the UE and the sink for the packets are depicted. Each of these blocks
is realized as a simple module.
In comparison with Figure 5.1, the protocol stack of one user corresponds to the blocks in
one column in Figure 5.2.
54
Figure 5.2: UMTS simulator
5.2.1 Trac Source at the UTRAN side

This block operates according to the ETSI trac source model, explained in Appendix
A. Depending on the data rate the parameters are set as shown in Table A.1. When the
protocol stack for a user is established, the trac generator remains in a standby state until
the reception of a request message from the receiving side. Then IP-packets of one packet
call are generated and sent to the RLC layer. After the last packet, the source returns back
into the standby state and waits till the next request. This request is sent by the sink after
the last packet of the previous packet call is received and the subsequent randomly chosen
reading time is expired.
As already mentioned, it is very important to keep in mind how the data rate is dened.
From [ETSI98] the following method can be deduced:
bit rate
= session time
transmitted number of bits

time in standby state within the session
(5.1)
The standby time is constituted of the reading time, the SDU delay from the trac gen-
55
erator to the receiver and the delay of the request message from the receiving side to the
trac generator.
5.2.2 RLC at the UTRAN/UE side

This block contains all functionality related to the RLC protocol in acknowledged mode.
It performs all actions described in Section 2.3.3. Parameters are taken from Table 2.2.
In my simulation the higher layer protocols are represented by the trac generator. Since
these higher layers aren't processed explicitely, interaction between the layer 2 protocol
and higher layers can't be investigated. Therefore the RLC protocol is adjusted such that
IP packets are transmitted in any case, i.e. the number of retransmissions is not limited.
This means that the parameter MaxDat is not in use, but in practice for a BLER of 10%, a
MaxDat value greater than 10 would not cause any SDU discard. Further it is reasonable to
observe only in-sequence delivery because the eects due to interaction of out-of-sequence
delivery in the RLC layer and higher layers can't be evaluated.
The following triggers for setting the poll bit, as explained in Section 2.3.3.3, are implemented: Last PDU in buer, Window based and every Poll_PU. The prohibit function for
sending polls is not enabled.
For evaluations of the RLC-layer performance the RLC entity at the UE side performs the
following measurements:
The statistics of the PDU delay, i.e., the time between the generation of a PDU in the
RLC at the transmitting side till the correct reception in the RLC at the receiving
side is measured.
The number of the padding blocks due to assignments of more PDU's than available
for transmission is measured.
The statistics of the number of transmission till a correct reception are recorded.
The link between RLC and MAC layer is assumed to be ideal because both layers will be
realized on the same host.
5.2.3 MAC-d at UTRAN side and MAC at UE side

In my simulator the dedicated MAC layer at the UTRAN side performs the mapping of
the user data in the downlink to the MAC-c/sh entity and in the uplink the mapping of
the DCH onto the DTCH. On the DCH status messages are transmitted from the receiving
side to the RLC entity at the transmitting side.
56
MAC-d and MAC-c/sh at the UE side are combined to one entity because there are both
entities for each UE. This block performs the mapping of the DSCH to the DTCH for data
in the downlink and the mapping of DTCH to DCH in the uplink.
The link from the MAC entity at the UE side and MAC-c/sh entity at the UTRAN side
contains the air interface of the DCH. The DCH is assumed with a TTI of 10 ms, thus
the interleaving is 10 ms, too. The delay due to wave propagation is negligible against this
duration so this link is congured with a delay of 10 ms. The block error ratio on the DCH
is assumed as a truncated normal distribution with a mean of 1% and a standard deviation
of 0.1%. The distribution is truncated to negative values.
The link between MAC-d and MAC-c/sh at the UTRAN side can either be internal within
one host or in case of handover situations it can be realized over the Iur-interface. For the
DSCH, soft handover is not supported, i.e., by means of a SRNC relocation it is possible
to prevent the network of handling the DSCH over the Iur-interface. In the current version
of my simulator it is assumed that instead of handovers, SRNC relocation is performed.
The 3GPP standard, [UMTS-25.321] and [UMTS-25.425], denes that the amount of data
waiting for transmission is indicated dierently between RLC and MAC-d and between
MAC-d and MAC-c/sh. In my simulation I take the parameter BO for both interactions,
instead of using CmCH-PI between MAC-d and MAC-c/sh.
5.2.4 MAC-c/sh at the UTRAN side

MAC-c/sh at the UTRAN side performs several tasks:
Scheduling is done according to the algorithms introduced in Section 4.5. Therefore

every TTI all active users are requested to send its current buer occupancy to the
MAC-c/sh.
Depending on the actual transport format used for the DSCH the corresponding power
consumption for this channel is calculated according to Equation 3.17.
Every TTI, the actual path loss and the power consumption of the DSCH are calculated according to Section 3.2.3 and Section 3.4. It is assumed that the scheduler
knows the current path loss situation due to perfect prediction.

TFC-selection is done as explained in Section 4.5.1.

MAC-c/sh measures past allocated credits to the users which serves as a further
criterion for the scheduler.
Transmission over the air interface of the DSCH is realized as a channel with propagation
delay equal to the actual TTI plus the delay due to indication on DCH (see Section 2.3.1.1).
This results in a delay of either 22 ms or 32 ms with the used transport formats from
57
Appendix C. The BLER is modelled as a truncated normal distribution with a mean of

10% and a standard deviation of 1%. The distribution is cut towards negative values. If
a user observes a transmission error, it is not able to decode any TB within the dedicated
TTI. Hence, all PDU's within these TB's are lost.
5.2.5 Sink at the UE side

The sink gathers the IP-packets transmitted through the network and generates statistics
about transport parameters. The following measurement activities are performed:
The active session throughput is evaluated according to the proposal from ETSI
[ETSI98].
At this point, ETSI proposes to measure the throughput in a more
operator specic way:
active session throughput
received number of bits

:
= sessioncorrectly
time
time when tx buer is empty
(5.2)
This means that additionally to the reading time the time within packet calls, where
there are no packets in the RLC transmit buer, is not counted in the denominator,
opposed to Equation 5.1. With this denition it is possible that a user with a nominal
bit rate of e.g. 64 kbit/s is served with an active session throughput higher than 64
kbit/s.
ETSI denes that a user is satised if the following conditions are fullled [ETSI98]:
The user doesn't get blocked when arriving to the system. If blocking is applied,
the proponent must specify used blocking criteria. In my simulator, a user gets
blocked if the maximum number of users in the system is reached.
The user doesn't get dropped during transmission. If dropping is applied, the
proponent must specify used dropping criteria. In my simulator, a user doesn't
get dropped by the system.
The active session throughput is equal or greater than a certain threshold. This
threshold is assumed to be 10% of the nominal bit rate shown in Table A.1, i.e.,
0.8, 3.2, 6.4, 14.4, 38.4 and 204.8 kbit/s for nominal bit rates of 8, 32, 64, 144,
384 and 2048 kbit/s. This criterion is evaluated after a session nished.
The network should be dimensioned for a maximum of 2% unsatised users.
During simulations it turned out that a further satisfaction criterion is necessary.

Therefore I introduced the following criterion: If a user isn't served by the network
for a certain period, the users resigns the network and feels unsatised. This period
is denoted as maximum idle period.
Further, the statistics of the SDU delay are recorded.
58
This is the time from the
generation of an SDU at the trac generator till the entire reception at the receiving
side.
The entire duration of the session is measured. A session starts when the request at
the receiving side is sent out and it ends when the last IP packet is received correctly.
5.2.6 RRC
The Radio Resource Control (RRC) in my simulation contains just a small part of the really
huge document [UMTS-25.331].
In my simulator, RRC is responsible for the following
activities:
Establishment of users is done according to a Poisson process with a certain intersession-arrival time. The mean number of users in the system is calculated as follows:
mean number of users
session duration
= meanmean
inter session arrival time
(5.3)
Since the duration of sessions depends on network parameters, the number of users
varies for dierent schedulers.
Further, each user is assigned a position equally distributed within the cell and a
velocity equally distributed in the range of 3 to 10 km/h. In the current release of
my simulator handovers are not considered. Therefore, users are not allowed to move
beyond the cell boundaries.
Users are released from the network either if the session nishes or if a user becomes
unsatised during the simulation run.
Since users are generated statistically, situations with lots of users in the system are
possible. In order to avoid congestion, a simple admission control mechanism which
limits the number of users in the system is performed.
The parameters measured in various entities of the network are sent to RRC which
calculates mean values or distribution functions. After nishing a simulation run, the
collected information is written into log-les. The following parameters are observed:

the total number of sessions generated by the Poisson process

the number of satised users
the number of unsatised users, since the active session throughput has been
below the 10% threshold

the number of resigned users

the number of blocked users

59
the mean number of users in the system, i.e. all users that entered the system
once are taken into account for this measurement
power consumption of the DSCH, i.e.
every TTI the power consumption is
calculated and the statistics are recorded
active session throughput, SDU delay, session duration, mean ratio of padding
PDU's versus correctly received PDU's and the mean number of transmissions
per correctly received PDU are collected only for satised users
Chapter 6
Results
In this chapter I provide the results evaluated with my UMTS simulator. First of all, I
adjust the parameters of the RLC-layer in order to maximize the protocol performance.
With these parameters I investigate the behavior of the scheduling algorithms in dierent
trac situations. Similar investigations for the UMTS TDD Mode are done in [Raji00].
The architecture of the simulator and conditions for performing the simulation are presented
in Section 5.2.
6.1 Optimization of the RLC-Protocol Stack

6.1.1 RLC Parameters
In this section I determine optimal values for the RLC protocol parameters:
Poll_Window,
Congured_Tx_Window_Size
Poll_PU,
and
Congured_Rx_Window_Size,
Timer_Status_Periodic and Timer_Status_Prohibit.
The size of the transmitter and
receiver window will be set equally and will be denoted as Window_Size. The main objective is to optimize the protocol with respect to the active session throughput. Adjusting
the protocol for interactive services, i.e, a further criterion would be a short round trip
time (RTT), it would lead to distinct parameters.
At rst, I investigate the protocol performance depending on the Status_Prohibit_Time
and the Window_Size parameter. The simulation is performed with the parameters shown
in Table 6.1.
The result of this simulation is shown in Figure 6.1.
In Figure 6.2 two
dimensional plots of the graphs of Figure 6.1 are shown with a Window_Size equals 1024.
In Figure 6.2 the inuence of the parameter Status_Prohibit_Time can be determined:
The mean number of transmissions per correctly received PDU, shown in Figure
6.2(d), mainly depend on the block error ratio (BLER), the RTT and the status
prohibit time.
The minimum value due to a BLER of 10% can be calculated as
follows:
60
CHAPTER 6. RESULTS
61
parameter
value
unit
max. number of users
50
max. idle period
30
inter session arrival time
3.0
user type
UDD_64
scheduling algorithm
RR_64
16, 32, 64, 128, 256, 512,
Window_Size
PDU
768, 1024, 1536, 2047
Status_Prohibit_Time
10, 20, 50, 70, 100, 150, 200, 250,

300, 350, 400, 450, 500, 550
ms
Status_Period_Time
500
ms
Poll_PU
32
PDU
Poll_Window
70
PDU
Table 6.1: Parameters for optimization of Window_Size and Status_Prohibit_Time
PDU correctly received at:
probability
0:9
0:1 0:9
0:1 0:1 0:9
1. transmission:
2. transmission:
3. transmission:
...
mean number of transmissions = 0:9
...
1
X
x=1
x 0:1x
= 1:1111 : : :
If Status_Prohibit_Time is smaller than RTT, additional unnecessary retransmissions are initiated. The RTT depends on the actual trac situation. Hence, with
a high Status_Prohibit_Time there are less situations with RTT smaller than Status_Prohibit_Time.
Therefore the number of transmissions per correctly received
PDU continuously decreases with increasing values of Status_Prohibit_Time. Due

to these retransmissions, small Status_Prohibit_Time values cause a lower active
session throughput, shown in Figure 6.2(a).
In Figure 6.2(b) it can be seen that there is a at minimum of the SDU delay for
Status_Prohibit_Time values around 0.25 seconds. This is caused once due to unnecessary retransmissions for low Status_Prohibit_Time values and secondly due to
an excessive delay of acknowledgments for high Status_Prohibit_Time values which
also yields to a higher SDU delay. In higher loaded cells this minimum moves towards
higher Status_Prohibit_Time values.
The ratio of padding PDU's to correctly received PDU's doesn't depend on the Status_Prohibit_Time, as shown in Figure 6.2(c). This variation is due to the randomness in the system.
In Figure 6.1(c) the inuence of the Window_Size can be seen:
CHAPTER 6. RESULTS
62
mean SDU delay
mean active session throughput

in bit/s
in s
4
x 10
7
14
12
10
4
2
0
0
0
200
500
1000
in ms
400
1500
2000
600
0
0
200
500
1000
in ms
400
1500
Status Prohibit Time
2000
600
Window Size
Window Size
(a) mean active session throughput
(b) mean SDU delay

mean number of transmissions per correctly received PDU
ratio of padding PDUs to overall PDUs

in %
250
1.6
200
1.5
150
1.4
100
1.3
1.2
50
0
0
0
200
500
1000
400
1500
2000
600
in ms
1.1
0
200
500
1000
400
1500
Window Size
(c) ratio of padding PDU's to all PDU's
2000
600
in ms
Window Size
(d) mean number of transmissions per correctly received PDU
Figure 6.1: RLC performance depending on the Window_Size (in PDU's) and the Status_Prohibit_Time
Errors on consecutive transport blocks of one user on the DSCH as well as errors
on the DCCH as well as a high RTT are responsible that the position within the
transmitter window pursues towards the upper edge. In the case of a small window
size the upper edge of the window size is reached more often. The MAC layer doesn't
know that the RLC protocol is at the upper edge and assigns credits to the user.
Since the user can't send data PDU's, padding PDU's are transmitted instead. This
can be seen in Figure 6.1(c). From this it follows that the active session throughput,
Figure 6.1(a), is very low and the mean SDU delay, 6.1(b), is high for small window
sizes. Simulations with a higher BLER need a Window_Size up to 2047 in order to
CHAPTER 6. RESULTS
in bit/s
4
x 10
63
in s
mean SDU delay
2.8
6.5
6
2.6
5.5
5
2.4
4.5
2.2
4
3.5
2
3
2.5
0
100
200
300
400
Status Prohibit Time in ms
500
600
1.8
0
100
(a) mean active session throughput

in %
ratio of padding PDUs to overall PDUs
1.5
6.8
1.4
6.6
1.3
6.4
1.2
200
300
400
500
600
(c) ratio of padding PDU's to all PDU's
Figure 6.2:
600
mean number of transmissions per correctly received PDU

1.6
100
500
(b) mean SDU delay
7.2
6.2
0
200
300
400
1.1
0
100
200
300
400
500
600
(d) mean number of transmissions per

correctly received PDU
RLC performance depending on the Status_Prohibit_Time with a Win-
dow_Size=1024 PDU's
work well. For a BLER of 10% a window size of 1024 is sucient. Higher values don't
change the protocol behavior for the parameter set from Table 6.1.
I further investigated the dependency of the parameters Poll_PU, Poll_Window and Status_Period_Time:
Poll_PU and Poll_Window specify the number of polls sent towards the peer entity.
Only one status message is sent when the status prohibit timer expires, even
if several polls occurred. Since high throughput is obtained with high values of Status_Prohibit_Time and Window_Size, the number of polls till expiration doesn't
CHAPTER 6. RESULTS
64
have any inuence. Only with a small status prohibit time, a small Poll_PU value
would cause additional unused retransmissions which decreases the performance.
In case of a high window size the upper edge of the transmit window is almost never
reached and therefore also Poll_Window has no signicant eect.
Status_Period_Time schedules the transmission of status messages. In combination

with the status prohibit timer also these status messages are postponed till expiration
of the status prohibit timer. So the status period timer ensures that there are status
messages sent although there is no poll upon received PDU's. Due to high values of the
Status_Prohibit_Time, the status period timer doesn't have considerable impacts.
These simulations were executed with the parameters from Table 6.1.
I also performed
the simulations with UDD_384 users. The trac class determines the inter arrival time
between packets and the threshold for the user satisfaction criterion. It turned out that the
shape of the gures is very similar for dierent trac classes, i.e. the RLC parameters for
optimum protocol performance don't depend on the trac class. Further I investigated the
protocol behavior for increasing the number of active users in the system by changing the
inter session arrival time and the maximum number of users. The results of these variations
suggest to take even higher values for Status_Prohibit_Time as well as for Window_Size.
Thus, for simulations in Section 6.2 the parameters listed in Table 6.2 are chosen.
parameter
value
unit
Window_Size
1536
PDU
Status_Prohibit_Time
550
ms
Status_Period_Time
500
ms
Poll_PU
32
PDU
Poll_Window
70
PDU
6.1.2 Maximum Window Size

In simulations with a high BLER, a Rx-Window-Size and a Tx-Window-Size greater than
2047, a very interesting problem appeared.
Due to the modulo operation with 4096 an
ambiguity of sequence numbers is possible. Let's assume that the window size is e.g. 2560
and consider the following case:
- only a PDU with a sequence number 2500 lower than the actual one is missing
- the receiver sends a negative acknowledgement to the peer transmitter
- the transmitter receives this negative acknowledgement and retransmits the corresponding PDU
CHAPTER 6. RESULTS
65
- due to congestion, the PDU remains some time longer in the network
- the timer Timer-Status-Periodic at the receiver expires and sends a further negative
acknowledgement
- the receiver gets the retransmitted PDU, moves its receiving window 2500 PDU's
higher and sends a positive ack.
- then the transmitter receives the second negative ack. and retransmits the PDU again
- the positive ack. is received by the transmitter and it moves its transmitter window
- now the receiver gets the second retransmission, and this one is now within the new
receiver window although this is not the right PDU
I posted this problem to the international discussion group,
the 3GPP mailing list
3GPP_TSG_RAN_WG2. I got some dierent replies but I mostly trust the answer which
suggests to use only window sizes lower than 2048. This was also my proposal.
The above mentioned problem could also arise for window sizes lower than 2048. That is, if
between the rst and the second retransmission of the missed PDU, in the example above,
some regular PDU's are correctly transferred. But this case never happened up to now in
my simulations.
6.2 Investigation of the Scheduling Algorithms

In this section I investigate the behavior of dierent schedulers. The parameters for these
simulations are listed in Table 6.2 and Table 6.3. In Section 6.2.1, the schedulers Round
Robin, Short Queue First and Long Queue First are investigated.
In Section 6.2.2 the
Weighted Scheduler and the inuence of its parameters are shown.

parameter
value
max. number of users
50
max. idle period
30
user type
UDD_64
unit
6.2.1 RR, SQF and LQF

The performance of dierent scheduling algorithms is analyzed depending on the inter session arrival time within the cell. The results are shown in Figure 6.3 - 6.8. The distribution
functions are shown for an inter session arrival time of 1.7 seconds.
At this value, the
CHAPTER 6. RESULTS
in %
100
66
number of unsatisfied users
90
80
70
number of blocked users
in %
60
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
50
40
60
50
30
40
20
30
20
10
10
0
1
1.5
2.5
3
3.5
inter session arrival time in s
4.5
0
1
1.5
(a) number of unsatised usersl
50
4.5
number of resigned users
in %
45
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
60
2.5
3
3.5
(b) number of blocked users
number of unsatisfied users due to less throughput
in %
70
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
40
35
30
40
25
30
20
15
20
10
10
0
1
1.5
2.5
3
3.5
4.5
(c) number of unsatised users due to less active

session throughput
0
1
1.5
2.5
3
3.5
4.5
(d) number of resigned users
Figure 6.3: Number of unsatised users depending on the inter session arrival time
RR_384 scheduler fullls the requirements for 98% of the users. The comparison of different scheduling algorithms for a certain inter session arrival time has to be done very
carefully since the number of users in the system varies. This is shown in Figure 6.4.
In Figure 6.3 the number of unsatised users for each condition within the user satisfaction
criterion is shown.
The criteria in use are pointed out in Section 5.2.5.
It exposes that
Short Queue First as well as Long Queue First doesn't consider all those users with the
CHAPTER 6. RESULTS
67
mean number of active sessions
cdf of number of users
50
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
45
40
0.9
0.8
0.7
35
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
0.6
30
0.5
25
0.4
20
0.3
15
0.2
10
5
1
0.1
1.5
2.5
3
3.5
4.5
(a) Mean number of active sessions
0
0
10
15
20
25
30
number of users
35
40
45
50
(b) cdf of number of active sessions
Figure 6.4: Mean number of active sessions depending on the inter session arrival time (a)
and cdf of the number of active sessions for an inter session arrival time of 1.7 s (b)
opposite queue size. This can be seen in Figure 6.3(d), because even for a low system load,
i.e. a high inter session arrival time, users are unsatised because they are not served for a
period longer than 30 seconds.
In Figure 6.3(c) it can be seen that SQF provides the remaining users with high data rates
since there are only a few users with a too low active session throughput. This can be seen
also in Figure 6.7. These high rates are at the expense that users with long queues are not
served.
In Figure 6.3(b) the number of users which are blocked by the admission control entity is
shown. It depends on the mean number of active users, the mean session duration, and on
the mean SDU delay. These parameters are described later in this section.
In Figure 6.3(a) the number of unsatised users due to any criteria is shown. This is the sum
of the number of users shown in sub-gure (b), (c) and (d). With the RR_384 scheduler,
the 2% level is reached for an inter session arrival time of 1.66 seconds. RR_64 has worse
performance since coding and interleaving is not as ecient.
The mean number of active users, Figure 6.4, the mean SDU delay, Figure 6.5, and the mean
session duration, Figure 6.6, are strongly interrelated. If the mean SDU delay increases, of
course it takes longer to nish a session. Longer sessions again increase the mean number of
users in the system, see Equation 5.3. Since for SQF and LQF schedulers users resign the
system even for low load, the oered trac for RR schedulers is higher than for SQF and
LQF. This results in a higher SDU delay and a higher session duration. LQF also results
in a high SDU delay and a high session duration since sessions are only nished if there
are no users with long queues in the system. With the distribution of the number of users
CHAPTER 6. RESULTS
in s
18
68
mean SDU delay
cdf of SDU delay

1
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
16
14
0.9
0.8
0.7
12
0.6
10
0.5
8
0.4
6
0.3
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
0.2
0.1
0
1
1.5
2.5
3
3.5
4.5
0
0
10
(a) Mean SDU delay
15
20
25
SDU delay in s
30
35
40
(b) cdf of SDU delay
Figure 6.5: Mean SDU delay depending on the inter session arrival time (a) and cdf of the
SDU delay for an inter session arrival time of 1.7 s (b)
in s
mean session duration
cdf of session duration
120
1
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
110
100
90
0.9
0.8
0.7
80
0.6
70
0.5
60
0.4
50
0.3
40
0.2
30
0.1
20
1
1.5
2.5
3
3.5
(a) Mean session duration
4.5
0
0
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
20
40
60
80
100
120
140
session duration in s
160
180
200
(b) cdf of session duration
Figure 6.6: Mean session duration depending on the inter session arrival time (a) and cdf
of the session duration for an inter session arrival time of 1.7 s (b)
in the system, Figure 6.4(b), the number of blocked users becomes obvious. In the cdf 's
of the session duration, Figure 6.6(b), there is an edge discernible for SQF and LQF, since
users resign if they are not served for a period longer than 30 seconds.
CHAPTER 6. RESULTS
in bit/s
4
x 10
69
cdf of active session throughput
18
16
14
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
0.9
0.8
0.7
12
0.6
10
0.5
0.4
0.3
0.2
0.1
0
1
1.5
2.5
3
3.5
4.5
(a) Mean active session throughput
0
0
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
1
3
4
5
6
7
active session throughput in bit/s
10
4
x 10
(b) cdf of active session throughput
Figure 6.7: Mean active session throughput depending on the inter session arrival time (a)
and cdf of the active session throughput for an inter session arrival time of 1.7 s (b)
In Figure 6.7 the active session throughput is shown. The comparison of dierent scheduling
algorithms has to be done together with the number of active sessions in the system because
the oered trac varies for dierent schedulers. The cdf shows that only RR doesn't provide
users with rates lower than a certain threshold. Since the cdf is almost vertical, RR assigns
resources in a fair manner to the users. The cdf for RR_384 is not as vertical as for RR_64.
The reason is, that the number of users in the system in case of RR_64 is more the less
constant since the mean number of users is near the limit set by the admission control
entity, see Figure 6.4(b). In case of RR_384, the number of users varies due to the Poisson
process, so in case of less system load users are served with higher rates. Therefore the cdf
is not completely vertical.
In Figure 6.8, it can be seen that the power consumption behaves similar for RR_64,
SQF_64 and LQF_64 and similar for RR_384, SQF_384 and LQF_384. The dependency
of the scheduler can be seen at the cdf for low power values.
If the cdf starts at values
unequal to zero, there are situations with BO=0 for all users. This of course depends on
the number of active sessions in the system. The power consumption and its distribution
further depends on the propagation environment, see Chapter 3. In my simulations users
are equally distributed, the cell radius is 2 kilometers and I use the COST-Walsch-Ikegami
propagation model. With this, my investigations show that the average power consumption
of one PDSCH with SF=8 (RR_384, SQF_384, LQF_384) is about 2.5 Watt for high load,
whereas four PDSCH with SF=32 (RR_64, SQF_64, LQF_64) require about 3.5 Watt.
CHAPTER 6. RESULTS
70
mean power for PDSCH 384
in W
4
cdf of power consumption

1
0.9
3.5
0.8
3
0.7
0.6
2.5
0.5
2
1.5
0.5
1
0.4
0.3
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
1.5
RR_64
RR_384
SQF_64
SQF_384
LQF_64
LQF_384
0.2
0.1
2
2.5
3
3.5
4.5
0
0
(a) Mean power consumption
3
4
5
power consumption in W
(b) cdf of power consumption
Figure 6.8: Mean power consumption depending on the inter session arrival time (a) and
cdf of the power consumption for an inter session arrival time of 1.7 s (b)
6.2.2 Weighted Scheduler (WS)

In this section I analyze the behavior of the Weighted Scheduler based on SQF (WS_SQF),
introduced in Section 4.5.5.
WS_SQF_384
The parameter
g2
g1 determines the inuence of the amount of past assigned credits, parameter

g3 determines the
determines the inuence of the channel condition, and parameter
inuence of the queue length.

In the following I compare the WS_SQF_384 with the best common scheduling strategy
RR_384. I choose the parameters in order to reduce the number of unsatised users and
to increase the mean active session throughput. It turned out that the parameters from
Table 6.4 fulll the postulated requirements.
parameter
g1
g2
g3
value
1.0
0.0
0.3
Table 6.4: Parameters for the Weighted Scheduler WS_SQF_384

In Figure 6.9 simulation results of the WS_SQF_384 in comparison with the RR_384
algorithm are shown. It can be seen that there is an increase of 10% in the active session
CHAPTER 6. RESULTS
throughput.
On the other hand, the mean SDU delay also increases.
71
The number of
unsatised users is almost equal to RR_384. The crossing point at an inter session arrival
time of 2.2 seconds probably would vanish in simulations with a longer simulation time
limit.
A higher mean active session throughput in combination with a higher mean SDU delay
results from the fact that WS_SQF_384 treats small sessions with higher priority than
long sessions. Sessions with only few and small SDU's will get a high throughput and a
small SDU delay opposed to sessions with long SDU's. Essential is that the statistics of
small sessions is built with one high value for the active session throughput and only a few
small SDU delays. For long sessions the statistic is built with one lower value for the active
session throughput and many high values for the SDU delay. That's the reason for high
values for both the mean active session throughput and the mean SDU delay.
CHAPTER 6. RESULTS
in bit/s
5
x 10
72
in s
12
1.8
mean SDU delay

RR_384
WS_SQF_384
RR_384
WS_SQF_384
10
1.6
1.4
1.2
1
0.8
4
0.6
0.4
0.2
0
1
1.5
2.5
3
3.5
4.5
0
1
1.5
(a) Mean active session throughput

in %
40
2.5
3
3.5
4.5
(b) mean SDU delay
number of unsatisfied users

RR_384
WS_SQF_384
35
30
25
20
15
10
5
0
1
1.5
2.5
3
3.5
4.5
(c) Number of unsatised users
Figure 6.9: Comparison of RR_384 and WS_SQF_384 ( 1 =1.0,
g2 =0.0, g3 =0.3)
Chapter 7
Summary and Conclusions
The aim of this thesis was the investigation of dierent scheduling algorithms for web
trac on the DSCH in UMTS FDD downlink. Therefore I developed a simulation tool that
consists of the whole radio interface protocol stack of UMTS and a trac generator. This
trac generator delivers IP packets according to the ETSI web trac model.
In Chapter 2, the UMTS network architecture and the protocols used for transmission
within the radio access network are explained.
This protocol stack primarily consists of
the physical layer (PHY), the medium access layer (MAC) and the radio link control layer
(RLC).
In Chapter 3, I introduce a method for considering other cell interference and calculating the
power consumption of the PDSCH in a multicell environment. Therefore two assumptions
are necessary. The rst one is that all Node B's near the target cell transmit at the same
power level. Secondly I assume that the signal power of the considered application is small
against the base station transmit power. With this, the other cell to own cell interference
ratio can be evaluated depending on the user position.
In Chapter 4, I explain standard scheduling algorithms like Round Robin, Short Queue
First and Long Queue First. I show how these algorithms can be applied within UMTS. I
also provide some extensions to them in order to enhance their performance.
After a detailed description of my simulation environment in Chapter 5, I provide the results
generated with my simulator in Chapter 6.
In the following sections I present some major insights and conclusions based on the results
in Chapter 6.
7.1 Summary
Inuence of RLC parameters
In Section 6.1, I investigated the performance of the RLC layer depending on several parameters. It turned out that for transmission of non-real time services the main parameters are
73
CHAPTER 7. SUMMARY AND CONCLUSIONS
74
the Window_Size and the Status_Prohibit_Time. In order to increase the active session
throughput, the window size and the status prohibit time must be set to high values. This
is independent of the actual trac situation.
For transmission of non-real time services
other parameters like Poll_PU, Poll_Window and Status_Period_Time do have inferior

importance.
Using high code rates

Packet scheduling shares the available resources among the active users in the cell. This can
be done in two dierent ways: in a code or a time division manner. Code division means
that a large number of users is allowed to transmit with low bit rates simultaneously. In
the time division case, only one or a few users are permitted to transmit at the same time,
however these users do have high bit rates.
RR_384 corresponds to the time division
scheduling, and RR_64 corresponds to code division scheduling in my simulations.

The results in Chapter 6 show that RR_384 works much better than RR_64. RR_64 can
cope with an inter session arrival time up to 2.57 seconds whereas RR_384 works up to
1.66 seconds at an unsatised user level of 2%. There are several reasons for this result:
Higher bit rates require less energy per bit, since coding and interleaving is more
ecient for high data rates, see Table 3.2.
The transport format of the PDSCH with SF=8 provides transmission of 12 PDU's
every 10 milliseconds, whereas four PDSCH with SF=32 only can transmit 4 4 PDU's
(=16 PDU's) every 20 milliseconds.
A small disadvantage of RR_384 is that due to credits of at least 12 PDU's more

padding PDU's are transmitted in comparison to RR_64.
User satisfaction criteria

I found out that the results mainly depend on the applied user satisfaction criteria. First
I implemented the criteria for packet-switched users according to ETSI. It includes the
following criteria:
The user doesn't get blocked when arriving to the system. If blocking is applied, the
proponent must specify used blocking criteria.
The user doesn't get dropped during transmission. If dropping is applied, the proponent must specify used dropping criteria.
The active session throughput is greater than the 10% of the nominal data rate.
75
I implemented blocking when the maximum number of users is reached. Dropping is not
applied in my simulator. With these criteria the scheduling algorithm Short Queue First
has best performance. But actually users with long queues are not served and remain in
the system till the end of the simulation. So only users with small sessions can nish and
only they are taken into the statistics.
This is not as it happens in reality. Therefore I introduced the following satisfaction criterion
which combats these deciencies:
A user must be served with at least one RLC PDU within a certain period, denoted
as maximum idle period. Otherwise the user resigns the system and feels unsatised.
With these criteria, Short Queue First has lots of unsatised users since they are not served
for a certain period, which is quite intuitive.
Round Robin, Short Queue First and Long Queue First

In my investigations the signicant criterion for performance evaluations of the scheduling
algorithms is the number of satised users for a certain system load. Thus, I use the criteria
mentioned in the previous section.
For SQF and LQF it turns out that many users are dropped even for low system load, since
users with the opposite queue size are not served. So these algorithms are not acceptable
since the number of unsatised users would be too high. Even though for SQF the users
which are served do have a high active session throughput.
Round Robin shares the resources equally among the users. So, all users are served almost
with the same active session throughput. Therefore the number of unsatised users is zero
for low system load and it increases rapidly if the system load becomes too high.
Weighted Scheduling
In Section 4.5.5, I explain the concept of a scheduler which serves the user with the highest
weight. The weight depends on the buer occupancy, the channel condition and recently
assigned credits to the users.
I tried to adjust the parameters of this scheduler in order to maximize the active session
throughput.
In Section 6.2.2, it can be seen that the active session throughput of this
scheduler exceeds RR_384 at the same level of unsatised users.
76
7.2 Conclusions
The performed simulations lead to the following conclusions:
Scheduling of non-real time trac should be performed by the algorithm Round Robin
for users with equal quality requirements.
The algorithms Short Queue First and Long Queue First are not acceptable, since
user with the opposite queue size are not served.
The Weighted Scheduling algorithm WS_SQF_384 is not recommended for implementation. It only has better performance than RR_384 in terms of the active session
throughput since it is adapted to the way statistics are built in this simulation.
Scheduling should be done in a time division manner, which means that high data
rates should be allocated to the users in a small time raster.
For simulations of mobile networks I strongly recommend to apply not only the user
satisfaction criteria proposed from ETSI. Also a criterion which considers the actual
situation of the user has to be implemented.
For scheduling of real-time trac strict delay requirements must be fullled.
IP
packets are segmented and stored in the RLC layer. Scheduling is done within the
MAC layer. In order to meet strict delay constraints, arrival times of IP packets must
be known by the scheduler. Up to now, the standard doesn't provide the exchange of
such information between MAC and RLC layer. Therefore extensions to the UMTS
Standard are necessary.
Appendix A
The ETSI Web Trac Model
Nowadays web trac is the most important application used by the Internet community.
The European Telecommunications Standards Institute (ETSI) provides a trac model for
web users in a wireless environment, see [ETSI98]. This model is recommended to be used
for performance evaluations in GPRS and UMTS.
The model is based on three levels, the session level, a packet call level and a packet level.
The session level describes the behavior of the user along the day, i.e., it determines the
statistics of starting a web session.
On the packet call level the number of web pages
the user visits during one session and its distribution as well as the idle time between
consecutive web pages is modelled.
The packet level characterizes the arrival process of
TCP/IP packets. The size and the interarrival time of the packets are determined.
session level
1 web session
1 packet call
packet call level

reading time
packet level
1 IP packet
interarrival time
between packets
Figure A.1: Typical web browsing session

In Figure A.1 a typical web browsing session is shown. A web session consists of a sequence
of packet calls. One packet call corresponds to the request of a WWW document. During
such a packet call several packets are transmitted.
One packet indicates an IP packet.
When the whole document is received at the terminal, the user takes some time for reading
the downloaded information. This time is called reading time.
The model should be able to generate trac with real characteristics. The main property
of web trac is its burstiness, i.e, the bit rate can change rapidly from zero to hundreds
77
APPENDIX A. THE ETSI WEB TRAFFIC MODEL
78
of kilobits per second. In order to describe the typical behavior of web trac, the above
mentioned parameters are modelled in the following way [ETSI98]:
The session arrival process is modelled as a Poisson process resulting in an exponentially distributed interarrival time of consecutive sessions.
This is widely used for
arrival processes because it models equally distributed time instants for the beginning
of sessions.
The process itself only generates the time instants when service calls
begin, there is no statement about the termination of the session. Together with the
mean session duration the average number of users in the system can be determined.
mean number of users

mean session duration

= mean
interarrival time
The number of packet calls within a session is modelled as geometrically distributed.

The reading time between two consecutive packet calls within a session is also modelled geometrically distributed. The reading time starts when the last packet of the
packet call is completely received by the user and it ends when the user makes a
request for the next packet call.
The distribution of the number of packets within a packet call can be adapted to
the trac case actually investigated.
[ETSI98] suggest to use again a geometrical
distribution.
The interarrival time between consecutive packets inside a packet call is geometrically
distributed as well.
The distribution of the packet size shall be again adopted to the trac case under
study. Pareto distribution with cut-o is proposed in [ETSI98].
In Table A.1 the mean values for the distributions of the parameters are provided for several
services.
The bit rate at this level
bit rate
is dened as
number of bits
= session timetransmitted
:
reading time within the session
So it can be shown easily how the parameters contribute to the designated bit rate. If we
assume that the mean packet length is 480 byte, which we will show in the next section,
we can proof for example UDD 64:
5 25 480 8 bit=s = 64000 bit=s :

5 24 0:0625
1 At
this point it is assumed that there is no delay of packets between source and receiver. The denominator actually contains the time when the source is active, so in case of packet delay also the mean packet
delay should be subtracted in the denominator.

UDD service
79
average
average
average
average inter-
parameters
number of
reading
number of
arrival time
for Pareto
distribution
packet calls
time
packets
between packets
UDD 8
4 s
25
0.5 s
UDD 32
4 s
25
0.125 s
UDD 64
4 s
25
0.0625 s
UDD 144
4 s
25
0.0277 s
UDD 384
4 s
25
0.0104 s
UDD 2048
4 s
25
0.00195 s
=1.1
k=81.5, =1.1
k=81.5, =1.1
k=81.5, =1.1
k=81.5, =1.1
k=81.5, =1.1
k=81.5,
Table A.1: Model parameters for dierent UDD services [ETSI98]
Distribution of the packet size

The normal Pareto distribution without cut-o is dened by:
fx (x) =
Fx (x) =
=
k
x+1
0
1
; x<k
; xk

k

; x<k
; xk
k
;1<<2
1
2 ! 1 ; 1 < < 2
Due to the limitation of the IP packet size to 65536 bytes the used distribution for packet
generation has to be truncated. The packet size is dened with the following formula
packet size
= min(P; m);
where P is the normal Pareto distribution random variable with parameter
= 1:1 and
= 81:5 bytes and m is the maximum allowed packet size (m=66666 bytes, dened in
[ETSI98]). This means that the packet size is lower bounded by the parameter k and upper
bounded by the parameter m. With this the probability density function of the packet size
is a truncated Pareto distribution:
2 In
the ETSI document [ETSI98] there is a misprint: the average reading time must be 4 seconds
instead of 412 seconds, [CFM00].

8
>
>
>
<
>
>
>
:
0
fn (x) = (x)
0
where
k
x+1
80
; x<k
; kxm
; x=m
; x>m
is the probability that x>m. It can easily be calculated as:
Z1
m
fx (x) dx =
k
m
; > 1:
Then the mean becomes:
n =
Z1
x fn (x) dx =
With the parameters
k
k
x +1 dx + m
m
1 x
Zm
= ::: =
k
m

k
m
= 1:1 and k = 81:5 bytes, the mean packet size is 480 bytes.
25 480 bytes = 12 kbytes.
Therefore the average size of one packet call is
Truncated pareto distribution: alpha=1.1, k=81.5 bytes, m=66666 bytes

0.014
0.012
0.01
0.008
fn(x)
0.006
0.004
0.002
0
0
100
200
300
400
500
600
700
800
packet size in bytes
Figure A.2: Pareto distribution
900
1000
Appendix B
Discrete Event Simulation System
OMNET++
OMNET++ is primarily designed to simulate communication protocols, computer networks and other distributed systems. This simulator was developed at the technical university of Budapest by Andrs Varga.
charge.
Since
OMNET++
It is an open source project and it is free of
is based on Tcl/Tk
and C++ the simulator is portable to
most platforms like Linux and most Unix systems as well as Windows 95, 98 and NT
as well as Macintosh. The whole software package can be downloaded from the web page
http://www.hit.bme/phd/vargaa/omnetpp.htm. For my thesis I use OMNET++ version
2.0 [Varga01].
B.1 Discrete Event Simulation

In a discrete event simulator there are only activities at discrete time instants.
It is as-
sumed that nothing happens between two consecutive events. The activities elapse without
consuming simulation time. Such a system contains a queue which stores events which have
to be processed in the future.
This queue is called Future Event Set (FES). The events
are stored in ascending order of their time stamps and they are processed according to the
following pseudo-code [Varga01]:
initialize (building the model and inserting initial events to FES)

while (FES not empty and simulation not yet complete)
{
retrieve first event from FES
simulation time = timestamp of this event
process event (insert new events or delete events from FES)
1 Tcl/Tk
is script language for programming graphical user interfaces
81
APPENDIX B. DISCRETE EVENT SIMULATION SYSTEM OMNET++
82
}
finish simulation (write statistical results, ...)
During the initialization phase the network structure is built and initial events are placed
into the FES in order to start the simulation. Afterwards, events are taken from the FES
successively in the correct order. Processing an event involves calls to user-supplied code.
Events normally cause further events in the FES, but they may also remove some events.
The simulation stops when there are no events left in the FES or if the simulation time or
the CPU time reaches a certain limit. At least at this time, statistical parameters measured
during the simulation can be displayed or written into les.
B.2 Simulation Structure

Network
... channels
simp
s1
s2
... gates
... simple modules
comp
... compound modules
Figure B.1: Example of a NED-structure

In OMNET++ the simulation problem is described by means of modules and links between
them. Figure B.1 shows how such a network looks like. There are two types of modules in
OMNET++ :
Simple Modules
are the lowest hierarchy, i.e.
they don't contain further submodules.
The simple modules provide actually the user-dened code.
Within these modules
the real functionality happens.
Compound Modules
consist of further submodules, either simple modules or again com-
pound modules. With this means the system can be organized in a hierarchical structure. The task of this module type is to transfer messages to their submodules. The
functional description in OMNET++ is very exible because simple modules can be

replaced by compound modules. So the hierarchical structure can be changed without
impacts on the already existing system.
The interface of modules is dened by input and output gates. These gates are connected
by channels in order to create a simulation network. Channels in OMNET++ are always

unidirectional and gates can be connected with only one channel. A channel can be characterized by three attributes:
83
Propagation delay:
The propagation delay is the amount of time the message is delayed when it travels
through the channel. Propagation delay is specied in seconds.
Bit error ratio:

The bit error ratio (BER) can be set for a channel. Thus, the block error ratio (BLER)
is
BLER = 1
(1
BER)n , if n denotes the length of the message.
Data rate:
The data rate of the channel is specied in bits per second and together with the
message length the transmission delay can be calculated. Thus, the delay between
sending a message and the reception of the last bit from this message is constituted
of the propagation delay and the transmission delay.
Modules communicate by exchanging messages.
Whenever a simple module receives a
message, an event is triggered which performs the actual functionality.
A message can
represent every information, e.g. frames or packets in a communication network, or jobs in

a queuing network or any other information element for indicating an event. Messages can
contain arbitrarily complex data structures.
B.3 Programming
The topology of the simulation system is dened by a specic Network Denition Language
(NED). The NED language supports a modular description of the network. Each module is
derived from a certain NED-declaration, which species its parameters, its submodules, its
gates and connections. Network descriptions are not used directly, they are rst translated
into C++ code by the NEDC compiler which is part of OMNET++ . Then all C++ sources
are compiled and linked with the simulation kernel and a user interface into the executable
program. There is a graphical user interface, called Tkenv, which is convenient for development, debugging but also for demonstration purposes (see Section B.4). For evaluation
purposes, the simulation will be performed in a simple and fast command line user interface,
called Cmdenv, which is designed primarily for batch execution.
In the following I provide a simple fragment of a NED program which establishes the
structure shown in Figure B.1:
simple End
gates:
in : in;
out: out;
endsimple
simple Middle
gates:
84
in: in1, in2;

out: out1, out2;
endsimple
module Comp
gates:
in: in;
out: out;
submodules:
s1: End;
s2: Middle;
connections:
--> s2.out1;
s1.in
s1.out --> s2.in1;
s2.in2 <-- in;
s2.out2 --> out;
endmodule
module Network
submodules:
comp: Comp;
simp: End;
connections:
comp.in <-- simp.out;
comp.out --> simp.in;
endmodule
Compound modules dene the hierarchical structure of the network. Simple modules contain the real functionality, which is implemented by the user. So each simple module con-
tains an additional C++ le and the appropriate header le. Simple modules are instances of
cSimpleModule. Within this class the virtual functions initialize(), finish(),

activity() and handleMessage(cMessage *) are dened2 . The initialize()-function
the class
of the modules are called before the rst event is processed.
In this function all code
which should be treated only once can be placed, like reading parameters from les. The
finish()-function
is called when the simulation completed. In this function statistics of
the simulation can be recorded. Messages in simple modules can be handled in two distinct
manners:
The
The
activity()-function is called only once and it consists of a loop which contains

the receive(cMessage *)-function. Every time receive(cMessage *) is called,
the considered activity()-function is suspended till a message is received. Then the
program proceeds at the instruction subsequent to receive(cMessage *).
handleMessage(cMessage *)-function is called every time a message is received
by the simple module.

2 Messages
are instances from the class cMessage.
85
There is a fundamental dierence how OMNET++ treats these two approaches internally.
The advantages of
activity()
is that local variables can store state information, be-
cause they are preserved across events since the function maintains in the memory. Further activity() often is more convenient
handleMessage() is that less stack memory
than
handleMessage().
The advantage of
is used.
There are further functions which are necessary in order to enable operation of the simulation network:

send()
functions are necessary to transmit messages to other modules.
wait()
suspends the execution of the subroutine for some simulation time.
With
scheduleAt()
a module can send messages to itself. This is necessary in order
to model events which occur within the module in the future.
With
cancelEvent()
messages in the FES can be deleted.
This is useful because
messages are often used to implement timeouts. If a certain event happens before the
timer expires, the expiration message has to be deleted from the FES.
end()
nishes the execution of the module.
OMNET++ also provides a rich C++ class library which supports many useful tasks, like:

collecting statistics with
estimation of distributions with
cVarHistogram,

cStdDev
and
cWeightedStdDev
classes.
cLongHistogram, cDoubleHistogram,
....
storing data in containers with
cArray, cQueue, cLinkedList
random number generation with
and
cBag
uniform(), normal(), exponential(),
discovering the network topology and support of routing with the

recording statistics into les with class
cOutVector
and function
classes.
... .
cTopology
class.
recordScalar().
When the program is started, a conguration le is loaded. This le contains settings that
control how the simulation is executed and it loads initial values of model parameters. The
conguration le can also specify several runs of the simulation with dierent parameter
sets.
With the means of script-les, the simulation process can be automated in a very
comfortable way.
86
Figure B.2: Command window of the graphical user interface
B.4 The Graphical User Interface: Tkenv

3
Tkenv is a portable graphical user interface which is based on Tcl/Tk . Tkenv supports
interactive execution of the simulation, tracing and debugging. In Figure B.2 the command
window of the simulation tool is shown. In Figure 5.2, we have seen the inspection window
which enables analyzing the network.
The following features are supported from Tkenv:
four modes for executing the simulation: STEP, RUN, FAST, EXPRESS
which implies dierent levels of tracing and animation

message ow animation

setting breakpoints
tracing of textual output and processed events
inspection of parameters during execution
which speeds up verifying the correct operation of the simulation program

inspection of the FES

creating snapshots of the current network settings
Tkenv is recommended to be used in the development stage of the simulation or for presentation purposes. For running the nal program it is better to use the faster command
user interface Cmdenv.
3 Tcl/Tk
is script language for programming graphical user interfaces
Appendix C
Transport Formats
In [UMTS-34.108], typical parameter sets are presented for several transport channels and
combinations of them. Unfortunately the list is not completely and further there are some
uncertainties. For example, there are only complete parameter sets for DCH. For DSCH
they refer to the DCH parameters, but there have to be systematic dierences which are
nowhere mentioned . Because there is no MAC header for DCH, but it is for DSCH. So
I changed this value to the correct one: 16 bit for UE-ID eld plus 2 bit for UE-ID-Type
eld plus 4 bit for the C/T eld leads to 22 bit. Therefore also the Transport Block Size
changes into 320 + 16 + 22 = 358 bits.
In Table C.1 transport channel parameters for a DSCH with 384 kbit/s are shown.
In
Table C.2 I provide the parameter sets for a DSCH with 144 kbit/s and in Table C.3 the
parameters for a 64 kbit/s DSCH.
87
APPENDIX C. TRANSPORT FORMATS
layer
parameter
RLC
Logical channel type

RLC mode
Payload sizes, bit
Max data rate, bit/s
RLC header, bit
MAC
MAC header, bit
PHY
TrCH type
TB sizes, bit
TFS
88
value
DTCH
AM
320
384000
16
22
DSCH
358
TF0,bit
0x358
TF1,bit
1x358
TF2,bit
2x358
TF3,bit
4x358
TF4,bit
8x358
TF5,bit
12x358
TTI, ms
Spreading factor
Coding Type
CRC, bit
Max number of bit/TTI after channel coding
10
8
TC
16
12684
Table C.1: Transport channel parameters for a 384 kbit/s DSCH [UMTS-34.108]
layer
parameter
RLC

RLC mode
Payload sizes, bit
RLC header, bit
MAC
MAC header, bit
PHY
TrCH type
TB sizes, bit
TFS
89
value
DTCH
AM
320
144000
16
22
DSCH
358
TF0,bit
0x358
TF1,bit
1x358
TF2,bit
2x358
TF3,bit
4x358
TF4,bit
8x358
TF5,bit
9x358
TTI, ms
20
Spreading factor
16
Coding Type
CRC, bit
TC
16
9516
layer
parameter
RLC

RLC mode
Payload sizes, bit
RLC header, bit
MAC
MAC header, bit
PHY
TrCH type
TB sizes, bit
TFS
90
value
DTCH
AM
320
64000
16
22
DSCH
358
TF0,bit
0x358
TF1,bit
1x358
TF2,bit
2x358
TF3,bit
3x358
TF4,bit
4x358
TTI, ms
20
Spreading factor
32
Coding Type
CRC, bit
TC
16
4236
Appendix D
Generation of random numbers from an
arbitrary distribution
In case of random variables for which the invers distribution function can be given explicitly
in analytical form, the inversion method gives an algorithm for generating random variables
with arbitrary distributions [Deak90]:
If the random variable
function
has the probability density function
FZ (z ), then it can be shown that

Y
fZ (z )
and the distribution
= F Z (Z )
is uniformly distributed in the interval [0,1]. With this fact, the random variable
generated by using
Z = FZ 1 (Y ), where Y
can be
has a uniform distribution.
The algorithm for generating random numbers from an arbitrary distribution can be implemented in the following way:
1. Generate
2. Compute
Z = FZ 1 (Y ), Z
3. Return
uniformly distributed in [0,1].

has the pdf
fZ (z )
D.1 Truncated Pareto Distribution

Random variables from the truncated Pareto distribution are generated by applying the
algorithm shown above, with the following distribution function
bution function
FZ 1 (Y ):
91
FZ (z ) and inverse
distri-
APPENDIX D. RANDOM NUMBERS FROM AN ARBITRARY DISTRIBUTION
8
>
>
<
>
>
:
0
= FZ (Z ) = 1
1
Z = FZ 1 (Y ) =
For calculation of
[0,1].
FZ 1 (Y )

k
Z
8
< 1k=
Y
: m
it is used that
92
; x<k
; kxm
; x>m

; mk Y 1

; Y < mk
Y
= Y , since Y
is uniformly distributed in
Appendix E
Programming Issues
Implementation of such a rich simulation tool brings up many unforseen diculties. Due
to the randomness nearly every imaginable case appears anytime after hours of simulation.
It is hard to nd problems which occur after some hours of continuous simulation because
starting the simulation in debug mode takes even much longer. In the following, I want to
list some severe problems I had to cope with during implementation:
1. In the C++ programming language it is necessary to allocate memory for each generated PDU. In order to avoid a memory overow these blocks have to be released
after they have been processed successfully. During the early development phase of
my simulator it could happen that memory of packets was already released although
these packets were in use in another part of the simulation or that some memory
never had been released. Later on, I decided to use the following memory management strategy:
Memory is allocate every time
- a PDU is inserted into the transmission buer either due to segmentation or due
to retransmission upon negative acknowledgement,
- a PDU is inserted into the retransmission buer due to sending a PDU for the
rst time,
- a padding-PDU is generated for transmission.
Memory is de-allocated every time
- a positve acknowledgement is received by the transmitting side, i.e., upon a positive acknowledgement the corresponding PDU's are deleted from the retransmission buer and possibly also from the transmission buer and their memory
is released,
- all PDU's constituting an SDU are correctly received by the receiver, then the
PDU's are deleted from the receiver buer and their memory is released.
93
APPENDIX E. PROGRAMMING ISSUES
94
With this approach no allocated memory remains unreleased and no memory blocks
are released prematurely.
2. A similar problem occurred when sessions end. If a session nishes the corresponding
user is deleted from the network. It was possible that there were still packets from
users in the network which already have been deleted. In order to avoid that problem,
every time a user gets released I search the FES for events belonging to the dedicated
user and delete them as well.
3. If the transmitter reaches the upper edge of the transmitter window and the receiver
doesn't miss any PDU, the transmitter is somehow in a dead-lock situation.
This
situation occurs if all PDU's within the transmitter window get lost during transmission. In this case the receiving side just sends positive acknowledgments and the
transmitting side is neither allowed to send new PDU's nor to retransmit old ones.
I solved this problem by copying all PDU's from the retransmission buer into the
transmission buer at the transmitting side in such situations.
4. When I performed my rst simulations, I wondered that the mean delay of PDU's is
greater than the mean delay of SDU's although the PDU-size is smaller than the mean
SDU-size. This is caused due to segmentation of the IP packets (=SDU). Consider
the case that a source sends only small IP packets except the last one is very large.
This packet is segmented into lots of PDU's. The transfer delay of this SDU is equal
to the delay of the last PDU. So the mean delay of SDU's is hardly aected by one
bigger value. Whereas the mean delay of PDU's is much more aected because many
PDU's observed a large delay.
5. Calculation of the active session throughput according Equation 5.2 causes problems
if the session consists of just one packet call with only one small IP packet.
It's
theoretically possible that the denominator vanishes if the IP packet is smaller than
the PDU size and this PDU is immediately served.
This would lead to an innite
throughput. I solved this problem by excluding unrealistic high rates for calculating
the mean.
6. A further problem appeared when I generated users by a Poisson process with a
certain inter-session-arrival time. The actual number of users depend on the mean
session duration according to Equation 5.3.
Due to the randomness of the inter-session-arrival time, the actual number of users
is subject to strong variations. Situations with too many users in the network occur
which leads to unstable conditions.
This happens because the mean inter-session-
arrival time stays constant and the mean session duration grows continuously due to
congestion in a high loaded network. Therefore, I implemented an admission control
entity in order to avoid such situations.
Glossary
3GPP
3rd Generation partnership project
AAL
ATM Adaption Layer
AM
Acknowledged mode
AMD
Acknowledged mode data
ARIB
Association of radio industries and businesses (Japan)
ATM
Asynchronous transfer mode
BCH
Broadcast channel (transport channel)
BER
Bit error ratio
BLER
Block error ratio
BMC
Broadcast/multicast control protocol
BO
Buer occupancy
CDMA
Code division multiple access
CFN
Connection frame number
CDF
Cumulative distribution function
CN
Core network
CRC
Cyclic redundancy check
CRNC
Controlling RNC
CTCH
Common trac channel (logical channel)
DCCH
Dedicated control channel (logical channel)
DCH
Dedicated channel (transport channel)
DPCCH
Dedicated physical control channel
DPCH
Dedicated physical channel
DPDCH
Dedicated physical data channel
DRNC
Drift RNC
DSCH
Downlink shared channel (transport channel)
DTCH
Dedicated trac channel (logical channel)
ETSI
European telecommunications standards institute
FACH
Forward access channel
FDD
Frequency division duplex
FES
Future event set
FIFO
First in rst out
GGSN
Gateway GPRS support node
GMSC
Gateway MSC
95

GPRS
General packet radio system
GSM
Global system for mobile communications
GTP-U
User plane part of GPRS tunneling protocol
IP
Internet protocol
ISDN
Integrated services digital network
L1
Layer 1
L2
Layer 2
L3
Layer 3
LQF
Long queue rst
MAC
Medium access control
MSC
Mobile switching center
MT
Mobile termination
NED
Network Denition
NLOS
Non line of sight
OVSF
Orthogonal variable spreading factor
PAD
Padding
PDCP
Packet data convergence protocol
PDSCH
Physical downlink shared channel
PDN
Packet data network
PDU
Protocol data unit
PHY
Physical layer
PS
Packet switched
PU
Payload unit
QoS
Quality of Service
QPSK
Quadrature phase shift keying
RACH
Random access channel (transport channel)
RLC
Radio link control
RNC
Radio network controller
RNS
Radio network subsystem
RR
Round Robin
RRC
Radio resource control
RTT
Round trip time
SDU
Service data unit
SF
Spreading factor
SGSN
Serving GPRS support node
SINR
Signal to noise and interference ratio
SMS
Short message service
SN
Sequence number
SQF
Short queue rst
SRNC
Serving RNC
SUFI
Super eld
TB
Transport block
TBS
Transport block set
TCP
Transmission control protocol
96

TCTF
Target channel type eld
TDD
Time division duplex
TE
Terminal equipment
TF
Transport format
TFC
Transport format combination
TFCI
Transport format combination indicator
TFCS
Transport format combination set
TFI
Transport format indicator
TFS
Transport format set
TPC
Transmit power control
TR
Transparent mode
TTI
Transmission time interval
UDD
Unconstrained delay data
UDP
User datagram protocol
UE
User equipment
UM
Unacknowledged mode
UMTS
Universal mobile telecommunications system
USIM
UMTS Subscriber identity module
UTRA
Universal Terrestrial radio access
UTRAN
UMTS Terrestrial radio access network
WCDMA
Wideband CDMA
WS
Weighted scheduler
WWW
World wide web
97
Bibliography
[ARIB98]
ARIB IMT-2000 Study Committee. Japan's Revised Proposal for Candidate Radio Transmission Technology on IMT-2000 : W-CDMA, Version
1.1, September 1998
[Bettst99]
Christian Bettstetter, Hans-Jrg Vgel, and Jrg Eberspcher. GSM Phase

2+ General Packet Radio Service GPRS: Architecture, Protocols, and Air
Interface. IEEE Communications Surveys, Vol.2, No.3, 3rd Quarter 1999.
[Cai97]
Jian Cai and David J. Goodman. General Packet Radio Service in GSM.
IEEE Communications Magazine, pages 122-131, October 1997
[CFM00]
C.F. Mecklenbrucker, FTW, Private Communication, Mar 2001.
[COST231]
COST Action 231 Final Report: Digital mobile radio towards future generation systems. The oce for ocial publications of the european communities, 1999
[COST259]
Luis M Correia. COST Action 259 Final Report: Wireless Flexible Personalized Communications. Wiley, March 2001
[Deak90]
Istvn Dek. Random Number Generators and Simulation. Akadmiai Kiad, Budapest, 1990
[ETSI98]
European Telecommunications Standards Institute ETSI. Universal Mobile

Telecommunications System (UMTS), Selection procedures for the choice
of radio transmission technologies of the UMTS (UMTS 30.03 version
3.2.0), April 1998
[Ebersp99]
Jrg Eberspcher, and Hans-Jrg Vgel. GSM Global System for Mobile
Communication. Teubner, 1999
[Forum00]
UMTS Forum, The UMTS Third Generation Market - Structuring the

Service Revenues Opportunities, Report 9, September 2000
[Holma00]
H. Holma and Antti Toskala. WCDMA for UMTS. Wiley & Sons, 2000
98
BIBLIOGRAPHY
[Kazmi01]
99
M. A. Kazmi. Radio Resource Control in Radio Access Networks with Distributed Coverage. PhD Thesis, cole Nationale Suprieure des Telecommunications, Paris, January 2001
[Keshav97]
S. Keshav. An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the Telephone Network, Addison Wesley Longman,
1997
[Kalden00]
Roger Kalden, Ingo Meirick, and Michael Meyer. Wireless Internet Access
Based on GPRS. IEEE Personal communications, pages 8-18, April 2000.
[Kleinr75]
Leonard Kleinrock. Queueing Systems, Volume 2: Computer Applications.

Wiley, 1975
[Loem00]
Georg Lelmann. TCP/IP over UMTS. Diploma Thesis, Technische Universitt Wien, Vienna, Sept 2000.
[Raji00]
Fariba Raji, G. Ostermayer, F. Kemler, C. Mecklenbrucker, P. Slanina,

F. Wegner, G. Papoutsis. Scheduling Performance for UTRA TDD Mode.
EPMCC 2000, Vienna, Feb 2000.
[Taferner00]
Manfred Taferner. Wireless Internet Access over GSM and UMTS. PhD
Thesis, Technische Universitt Wien, Vienna, April 2001
[UMTS-23.060] 3rd
Generation
Partnership
Project.
General
Packet
Radio
Service
(GPRS), Service description, Stage 2 (Release 1999), 3G TS 23.060, V3.6.0,

Dec 2000.
[UMTS-25.201] 3rd Generation Partnership Project. Physical layer - General description
(Release 1999), 3G TS 25.201, V3.1.0 , Dec 2000.
[UMTS-25.211] 3rd Generation Partnership Project. Physical channels and mapping of
transport channels onto physical channels (FDD) (Release 1999), 3G TS
25.211, V3.5.0 , Dec 2000.
[UMTS-25.212] 3rd Generation Partnership Project. Multiplexing and channel coding
(FDD) (Release 1999), 3G TS 25.212, V3.5.0 , Dec 2000.
[UMTS-25.213] 3rd Generation Partnership Project. Spreading and modulation (FDD)
(Release 1999), 3G TS 25.213, V3.4.0 , Dec 2000.
[UMTS-25.301] 3rd Generation Partnership Project. Radio Interface Protocol Architecture
(Release 1999), 3G TS 25.301, V3.6.0 , Dec 2000.
[UMTS-25.302] 3rd Generation Partnership Project. Services provided by the physical layer
(Release 1999), 3G TS 25.302, V3.7.0 , Dec 2000.
[UMTS-25.321] 3rd Generation Partnership Project. MAC protocol specication (Release
1999), 3G TS 25.321, V3.6.0 , Dec 2000.
BIBLIOGRAPHY
100
[UMTS-25.322] 3rd Generation Partnership Project. RLC protocol specication (Release

1999), 3G TS 25.322, V3.5.0 , Dec 2000.
[UMTS-25.323] 3rd Generation Partnership Project. Packet Data Convergence Protocol
(PDCP) Specication (Release 1999), 3G TS 25.323, V3.3.0 , Dec 2000.
[UMTS-25.324] 3rd Generation Partnership Project. Broadcast/Multicast Control BMC
(Release 1999), 3G TS 25.324, V3.3.0 , Dec 2000.
[UMTS-25.331] 3rd Generation Partnership Project. RRC Protocol Specication (Release
1999), 3G TS 25.331, V3.5.0 , Dec 2000.
[UMTS-25.425] 3rd Generation Partnership Project. UTRAN Iur Interface User Plane Protocols for Common Transport Channel Data Streams (Release 1999), 3G
TS 25.425, V3.3.0 , Dec 2000.
[UMTS-25.435] 3rd Generation Partnership Project. UTRAN Iub Interface User Plane Protocols for Common Transport Channel Data Streams (Release 1999), 3G
TS 25.435, V3.5.0 , Dec 2000.
[UMTS-25.942] 3rd Generation Partnership Project. Text (Release 1999), 3G TS 25.942,
V3.0.0 , Mar 2001.
[UMTS-34.108] 3rd Generation Partnership Project. Common Test Environments for User
Equipment (UE) (Release 1999), 3G TS 34.108, V3.2.0, Dec 2000
[Varga01]
Andrs
tem,
Varga.
User
OMNET++,
Manual
Version
2.0.
Discrete
Technical
Event
Simulation
University
of
Sys-
Budapest,
http://www.hit.bme/phd/vargaa/omnetpp.htm, February 2001

Paper

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Paper

Uploaded by

Copyright:

Available Formats

Diplomarbeit

Scheduling Algorithms for UMTS FDD Downlink

Wien, im Juli 2001

I improve these algorithms in order to enhance the active

Im speziellen betrachte ich Datenbertragung von Internet-Servern zu Mobil-

Die Teilnehmer werden innerhalb der Zelle gleich-

Dabei halte ich mich wieder an

Sitzungen fr die verschiedenen Algorithmen. Der Leistungsverbrauch sowie die mittlere

Special thanks I owe to Christoph Mecklenbrucker.

He supported my work with many

Further I express thanks to my colleagues, especially to Thomas Baumgartner, Gnther

Evolution of Wireless Telephony and Internet Access

Quality of Service (QoS) in Wireless Networks . . . . . . . . . . . . . . . . .

Motivation and Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Universal Mobile Telecommunication System UMTS

UMTS Protocol Architecture

Radio Interface Protocol Architecture . . . . . . . . . . . . . . . . . . . . . .

Physical (PHY) Layer

Medium Access Control (MAC) Layer . . . . . . . . . . . . . . . . . .

Radio Link Control (RLC) Layer

Packet Data Convergence Protocol (PDCP) Layer . . . . . . . . . . .

Radio Resource Control (RRC) Layer . . . . . . . . . . . . . . . . . .

Interaction between Layers . . . . . . . . . . . . . . . . . . . . . . . .

Spatially Correlated Shadow Fading . . . . . . . . . . . . . . . . . . .

Received Signal Power

Scheduling Best-Eort Applications . . . . . . . . . . . . . . . . . . . . . . .

Weighted Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . .

Queue Length Dependent Scheduling . . . . . . . . . . . . . . . . . .

Channel State Dependent Scheduling . . . . . . . . . . . . . . . . . .

Scheduling Guaranteed-Service Applications

Comparison of Scheduling Algorithms . . . . . . . . . . . . . . . . . . . . . .

Transport Format Selection

Short Queue First (SQF) . . . . . . . . . . . . . . . . . . . . . . . . .

Long Queue First (LQF) . . . . . . . . . . . . . . . . . . . . . . . . .

Weighted Scheduler (WS)

Trac Source at the UTRAN side . . . . . . . . . . . . . . . . . . . .

RLC at the UTRAN/UE side

MAC-d at UTRAN side and MAC at UE side

MAC-c/sh at the UTRAN side

Sink at the UE side . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Optimization of the RLC-Protocol Stack

Maximum Window Size

Investigation of the Scheduling Algorithms . . . . . . . . . . . . . . . . . . .

RR, SQF and LQF . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Weighted Scheduler (WS)

7 Summary and Conclusions

A The ETSI Web Trac Model

B Discrete Event Simulation System OMNET++

Discrete Event Simulation

The Graphical User Interface: Tkenv

D Generation of random numbers from an arbitrary distribution

Truncated Pareto Distribution . . . . . . . . . . . . . . . . . . . . . . . . . .

Worldwide subscribers to xed, mobile, and xed Internet networks [Forum00]

UMTS network architecture [Holma00]

The logical role of an RNC [Holma00] . . . . . . . . . . . . . . . . . . . . . .

Protocol architecture, PS domain [UMTS-23.060]

Radio interface protocol architecture (after [UMTS-25.301]) . . . . . . . . . .

Protocol termination for a common channel (after [UMTS-25.301]) . . . . . .

Physical layer for transmitting situation

Frame structure for downlink DPCH [UMTS-25.211]

Frame structure for downlink PDSCH [UMTS-25.211] . . . . . . . . . . . . .

PDSCH timing [Holma00]

2.10 DSCH code tree examples [Holma00]

2.12 Transport formats [UMTS-25.302] . . . . . . . . . . . . . . . . . . . . . . . .

Scheduling Best-Eort Applications . . . . . . . . . . . . . . . . . . . . . . .

Trac Source at the UTRAN side . . . . . . . . . . . . . . . . . . . .

A The ETSI Web Trac Model

Worldwide subscribers to xed, mobile, and xed Internet networks [Forum00]

2.14 MAC PDU and SDU [Loem00]

2.16 RLC segmentation and concatenation [Loem00]

2.18 PDCP SDU and PDU [Loem00] . . . . . . . . . . . . . . . . . . . . . . . .

Weight calculation for buer occupancy . . . . . . . . . . . . . . . . . . . . .

Schematic owchart of the simulation procedure . . . . . . . . . . . . . . . .

Number of unsatised users depending on the inter session arrival time

Model parameters for dierent UDD services [ETSI98]

All these needs of the user dene a set

of transmission parameters which must be fullled during a call.

Background trac also approves

Of course the 3GPP specications can be downloaded from