Thesis Hurtado

University of Twente
Faculty of Electrical Engineering,

Mathematics and Computer Science
(EEMCS)
UMTS Capacity simulation study

Andrés Felipe Cosme Hurtado
Master of Science in Telematics
Thesis
(Carried out at Vodafone Netherlands)
Project Supervisors:
• Dr. ir. Geert Heijenk, University of Twente
• Prof. Dr. ir. Boudewijn Haverkort, University of
Twente
• Dr. ir. Bert Haverkamp, Vodafone Netherlands
Copyright © October 2005, Andrés Felipe Cosme Hurtado, Maastricht, The Netherlands
Abstract
The purpose of this report is to investigate the performance, measured in

terms of Key Performance Indicators (KPIs) of a UMTS radio network
(UTRAN) under different traffic and mobility scenarios (i.e.
homogeneously/ non homogeneously distributed traffic, mobile/non-
mobile traffic) and develop some general guidelines for dimensioning the
UMTS network optimally.
In this work, simulations are performed using the Wines simulator, which
is a dynamic simulator that models all the radio-resource management
functionality of the UTRAN. Two main series of experiments have been
performed. In the first series simulations have been performed on an
analysis area defined in common agreement with international colleagues
at Vodafone. The distribution of the traffic in this simulation scenario is
homogeneous and the main purpose is to find capacity figures when
increasing the traffic density of one of the four possible defined services
(WWW, FTP, voice and video-call) and also with a given traffic mix
involving all services together. Two mobility profiles are used (pedestrian
and vehicular).
In the second series of experiments, a more realistic scenario, based on

detailed geographical characteristics relevant for signal propagation, and
traffic densities based on traffic maps, has been simulated. The purpose
was to analyze the possible differences in capacity between the “ideal”
model and the more “realistic” model.
For the single-service scenario analysis, circuit-switched services (speech

and video-call), it can be observed that the capacity is mainly uplink-
limited. The corresponding results for the packet-switched services (FTP,
WEB) have shown that capacity is mostly downlink-limited, as it was
expected due to the more asymmetrical data rates in the downlink
compared to the uplink for both services.
For the service mix analysis in both scenarios (homogeneous and non
homogeneous) it was found that the capacity is mostly downlink-limited
(i.e. the downlink power target level is exceeded before the uplink load
target level).
In terms of the power-rule usage, no significant differences between the

two analyzed rules were found, provided that the downlink path loss
between the Node B connector and the antenna is below 4 dB in all the
sites.
Finally, for the mobility study in both scenarios (homogeneous, non

homogeneous) the theoretically expected behavior was confirmed.
i
A.F. COSME. UMTS CAPACITY SIMULATION STUDY
Acknowledgements
I want to express my gratitude to my Direct Supervisor at University of

Twente, Dr. Geert Heijenk. His knowledge, experience and valuable
suggestions and corrections gave me the effective support when I couldn’t
find an answer by myself. Special thanks also to Prof. Dr. Boudewijn
Haverkort who was also part of my evaluation committee.
I wish to thank also my supervisor at Vodafone-NL, Dr. Bert Haverkamp,

for giving me the opportunity to be part of this excellent group of people.
Your help was very important to me, not only in the technical side but also
with the support in everyday tasks, especially at the beginning of my
internship when everything was totally new to me and I didn’t know
anyone except you. Thank you very much.
I would like to express also my gratitude to all the Vodafone IT-Network

Department (and in general, to all the people at Vodafone that I had the
opportunity to meet) as they always gave me support and were always
willing to help me whenever I need it and besides, they were cheering me
up and encouraging me to make a good work. I hope not to accidentally
omit anyone in my list: I want to say many thanks to Greg Vourekas,
Jamaal Tajaate, Ralph Thijssen, Roy Crutsen, Roy Hermans, Bianca
Wouters, Simon De Kerpel, Yvonne Lemeer, Zoltan Pitman, Tjitte
Ploegstra, Debbie Smits and Arjen Meuers. It was a great experience and
a real pleasure to work with such nice persons and high-level
professionals like you; I’m going to miss you! I wish you all the best in
your professional careers. Special Thanks also to Peter Schneider and Kai
Pannhorst from Vodafone Germany for all the Support with the Wines
Simulator Tool. One of the nicest experiences of working here was to be
able to work with great people from many other countries!
I’m also very grateful to my Lord Jesus Christ, in whose name and in
whose precepts I try to aim every action in my life.
And last but not least, I want to thank all the support and understanding
from my friends in Colombia, Spain and The Netherlands and to all my
family, specially to my mother Imelda Rocío, my sister María Claudia, and
my father Galo Alberto, who always encourage me to pursue higher goals
and cheer me up in the difficult moments. God bless you all and this work
is dedicated to you.
ii
List of Abbreviations
3G Third Generation
3GPP Third Generation Partnership Project
ATOLL UMTS RF planning solution by Forsk
BER Bit Error Rate
BLER Block Error Rate
BSC Base Station Controller
BTS Base Transceiver Station
CE Channel Elements
CDMA Code Division Multiple Access
CRC Cyclic Redundancy Check
CRNC Controlling RNC
CPICH Common Pilot Channel
CS Circuit Switched service
DL Downlink
DPCCH Dedicated Physical Control Channel
DPDCH Dedicated Physical Data Channel
DRNC Drift RNC
DS Direct Sequence
DSSS Direct Sequence Spread Spectrum
FACH Forward Access Channel
FDMA Frequency Division Multiple Access
GGSN Gateway GPRS Support Node
GSM Global System for Mobile telecommunications
GPRS General Packet Radio Service
iii
HLR Home Location Register
HSS Home Subscriber Server
IMS IP Multimedia System
IMT-2000 International Mobile Telecommunications 2000
IP Internet Protocol
ITU International Telecommunication Union
KPI Key Performance Indicator
ME Mobile Equipment
MRC Maximum Ratio Combining
MS Mobile Station
MT Mobile Termination/Terminal
OVSF Orthogonal Variable Spreading Factor
P-CPICH Primary CPICH
PDF Probability Density Function
PN Pseudo-Noise
PS Packet Switched service
QoS Quality of Service
RNC Radio Network Controller
RNS Radio Network Subsystem
RRC Radio Resource Control
RRM Radio Resource Management
RSCP Received Signal Code Power
RSSI Received Signal Strength Indicator
SF Spreading Factor
SGSN Serving GPRS Support Node
SIP Session Initiation Protocol
SIR Signal to Interference Ratio
iv
SRNC Serving RNC
TDMA Time Division Multiple Access
TE Terminal Equipment
TPC Transmission Power Control
UE User Equipment
UL Uplink
UMTS Universal Mobile Telecommunications System
UTRAN UMTS Terrestrial Radio Access Network
VoIP Voice over IP
W-CDMA Wideband - Code Division Multiple Access
Wines Radioplan’s WIreless NEtwork System
v
Table of contents
1. INTRODUCTION .........................................................................................................15
1.1 PRELIMINARY CONCEPTS ABOUT UMTS CAPACITY 15
1.2 PROBLEM STATEMENT 16
1.3 OBJECTIVES AND SCOPE THIS WORK 17
1.3.1 General Objective 17
1.3.2 Scope 17
1.4 PROBLEM SOLVING APPROACH 18
1.4.1 Assignment parts 18
1.4.2 Activities before simulation 18
1.4.3 Activities during Simulation 19
1.4.4 Activities after Simulation 19
1.5 DOCUMENT STRUCTURE 19
2. CAPACITY AND SIMULATION (INTRODUCTORY) CONCEPTS .........21

2.1 THE CAPACITY AND KPI CONCEPTS 21
2.2 SOFT CAPACITY VS. HARD CAPACITY 23
2.3 CAPACITY MANAGEMENT VS. CAPACITY PLANNING 25
2.4 PERFORMANCE EVALUATION TECHNIQUES 26
2.4.1 Why Simulations are the right option in this case? 27
2.4.2 Limitations of the simulations 28
2.5 SUMMARY OF CHAPTER 2 29
3. THE RADIO PLANNING PROCESS (LITERATURE STUDY)..................30

3.1 THE RADIO PLANNING PROCESS (ITU’S IMT-2000) VISION 30
3.1.1 Definition of the radio Parameters, WCDMA and marketing 31
3.1.2 Dimensioning 32
3.1.3 Detailed Capacity, Coverage Planning and Network
Performance Simulation 36
3.1.4 Real sites search 38
4. INTRODUCTION TO WINES DYNAMIC SYSTEM-LEVEL

SIMULATOR ..................................................................................................................40
4.1 DIFFERENT SIMULATION APPROACH: STATIC VS. DYNAMIC 40
4.2 THE LEVEL OF DETAIL OF THE SIMULATION: SYSTEM LEVEL VS. LINK LEVEL 43
4.3 DISCRETE EVENT SIMULATION VS. CONTINUOUS TIME SIMULATION 43
4.4 WINES MAIN FEATURES 45
4.4.1 Dynamic User Traffic Modeling 46
4.4.2 The Service Arrival (Activation +Service) process and the
initial arrival (transient) process 47
4.4.3 The UE profile 48
4.4.4 The Service Profile 49
4.4.5 The data unit arrival process (“Traffic Models”) 51
vi
5. DESCRIPTION OF THE FIRST SIMULATION SCENARIO AND
GENERAL SETUP OF THE SIMULATION EXPERIMENTS.......................56
5.1 SIMULATION AND ANALYSIS AREAS 56
5.2 ENVIRONMENT ASSUMPTIONS 57
5.3 DEFINED SERVICES AND TRAFFIC MIX 58
5.4 SERVICE CONFIGURATION 59
5.4.1 Radio Bearer Properties 59
5.4.2 Signal to Interference Ratio 60
5.4.3 Service Prioritization 61
5.4.4 Optional Semi-Dynamic Mode 61
5.4.5 Physical Layer parameters 61
5.4.6 Traffic Model parameters 62
5.4.7 Traffic Matrices 64
5.5 GENERAL NETWORK LAYOUT ASSUMPTIONS 65
5.5.1 RNC assumptions 65
5.5.2 Node B assumptions 65
5.5.3 Cell assumptions 66
5.6 DEFINED KPI’S (KEY PERFORMANCE INDICATORS) 66
5.6.1 KPIs for Circuit switched services (Voice, Video Tel): 67
5.6.2 KPIs for Packet switched services (WWW, FTP) 67
5.6.3 Defined KPI Thresholds 67
5.7 GENERAL SIMULATION SETTINGS 72
5.8 SIMULATION PLAN 72
5.8.1 Homogeneous Scenario 73
5.8.2 Non-homogeneous Scenario 76
5.8.3 Analysis of a specific network parameter 79
6. DESCRIPTION OF THE SECOND SIMULATION SCENARIO (NON-

HOMOGENEOUS) .......................................................................................................82
6.1 SIMULATION AREA AND ANALYSIS AREA 82
6.2 CLUTTER CLASSES AND DEM (DIGITAL ELEVATION MODEL) 84
6.3 NON – HOMOGENEOUS TRAFFIC MAP GENERATION 85
7. SIMULATION RESULTS FIRST SCENARIO (HOMOGENEOUS) .........91

7.1 FIGURES PER SERVICE 91
7.1.1 Voice Service 94
7.1.2 Web Service 106
7.1.3 FTP Service 120
7.1.4 Video-call Service 130
7.1.5 Summary single-service experiments 134
7.2 FIGURES USING THE DEFINED TRAFFIC MIX PERCENTAGES 136
7.2.1 Blocking and Dropping probability 141
7.2.2 Channel Elements usage 144
7.2.3 Downlink Iub usage 146
7.2.4 Uplink Load 147
7.2.5 Downlink Transmitted Power 148
7.2.6 Downlink Code Tree Usage 149
7.2.7 Perceived user throughput 151
7.3 POWER-RULE STUDY 153
7.3.1 CPICH Power –Germany Settings 154
vii
7.3.2 NETHERLANDS SETTINGS: 156

7.4 MOBILITY STUDY 158
7.4.1 Blocking and Dropping probabilities (Voice service) 159
7.4.2 Uplink load (Voice service) 160
7.4.3 Downlink Power usage (Voice service) 161
7.4.4 Throughput (Web service) 161
7.5.1 Single service experiments 163
7.5.2 Traffic mix homogeneous scenario 164
7.5.3 Power study 164
7.5.4 Mobility study 165
8. SIMULATION RESULTS SECOND SCENARIO (NON-

HOMOGENEOUS) AND COMPARISON WITH THE HOMOGENEOUS
SCENARIO ...................................................................................................................166
8.1 SUMMARY OF THE SINGLE-SERVICE SIMULATIONS 166
8.1.1 Voice Service 166
8.1.2 Web Service 175
8.2 SERVICE MIX 177
8.3 POWER STUDY, TRAFFIC DENSITIES FOR GERMANY AND THE NETHERLANDS 179
8.4 MOBILITY STUDY 180
8.4.1 Uplink load (Voice service) 181
8.4.2 Downlink Power usage (Voice service) 182
8.4.3 Downlink Throughput 182
8.5 ANALYSIS OF THE IMPACT OF A PARAMETER SETTING IN THE OVERALL
PERFORMANCE OF THE UTRAN 183
8.5.1 The parameter Timetotrigger1a and its influence on the
Handover algorithm 183
8.5.2 The Analysis framework 187
8.5.3 Simulation Results 191
8.6 SUMMARY, CHAPTER 8 199
8.6.1 Circuit switched services (voice service) 199
8.6.2 Packet Switched Services 200
8.6.3 Traffic Mix Analysis 200
8.6.4 Power study 201
8.6.5 Mobility study 201
8.6.6 Analysis of the impact of a parameter setting in the overall
performance of the UTRAN 202
9. CONCLUSIONS AND FUTURE WORK ............................................................203

9.1 SINGLE SERVICE ANALYSIS 203
9.1.1 Circuit switched services, homogeneous scenario 203
9.1.2 Packet switched services, homogeneous scenario 204
9.2 SERVICE MIX ANALYSIS 206
9.3 POWER RULE USAGE, HOMOGENEOUS AND NON-HOMOGENEOUS SCENARIO 207
9.4 MOBILITY STUDY, HOMOGENEOUS AND NON-HOMOGENEOUS SCENARIO 207
9.5 ANALYSIS OF THE PARAMETER TIME TO TRIGGER 1A 208
9.6 OPEN ISSUES AND FURTHER RESEARCH TOPICS 208
1. APPENDIX: UMTS FUNDAMENTAL CONCEPTS ...........................................1

1.1 WHAT IS UMTS? 1
1.2 TECHNICAL CHARACTERISTICS 1
viii
1.3 CHANNELIZATION (SPREADING) CODES 3
1.4 SCRAMBLING CODES 5
1.5 THE PROCESSING GAIN, SIR (SIGNAL TO INTERFERENCE RATIO) AND EB/NO
CONCEPTS IN UMTS [VOUREKAS] 6
1.6 UMTS ARCHITECTURE (REL99) 10
1.7 RADIO RESOURCE MANAGEMENT ALGORITHMS 13
2. APPENDIX: PROCEDURE FOR EXPORTING A TRAFFIC MAP BASED

ON CLUTTER DATA FROM ATOLL TO WINES.............................................16
2.1 PROJECT EXPORT TO A *.MDB FILE 16
2.2 EXPORT OF THE COMPUTATION ZONE AND FOCUS ZONE 17
2.3 EXPORT THE PATH LOSS DATA TO RASTER DATA FILES 17
2.4 EXPORT THE CLUTTER MAP AND CLUTTER CLASSES DEFINITION 18
2.5 EXPORTING BACKGROUND MAPS WITH ATOLL 19
2.6 EXPORTING DEM (DIGITAL ELEVATION MODEL) INFORMATION 19
2.7 TRAFFIC MAP(S) AND ENVIRONMENT CODES DEFINITION 19
ix
List of Tables
Table 1: Parameters and Probability distribution for the Wines' WWW Traffic Model ..........53
Table 2: Defined Services and Wines Traffic Models used .....................................................62
Table 3:(1/4): KPI definition ....................................................................................................68
Table 4: Defined Traffic Densities [Erl/Km^2]........................................................................73
Table 5: Assumed traffic densities (in Erlangs/Km2) for the two simulations of the Power rule
study .................................................................................................................................75
Table 6: Assumed DL losses and PCICH Power for the Power Level experiments ................75
Table 7: Assumed traffic densities and scaling factors for the power rule study, non
homogeneous scenario......................................................................................................76
Table 8: CPICH and DL Losses for the power experiment, non homogeneous scenario ........79
Table 9: Clutter weights definition example inside a given Environment ...............................87
Table 10: Estimation of the users per cell according to the simulation output, blocking
probability target = 1%.....................................................................................................96
Table 11: Estimation of the users per cell according to the simulation output, dropped
probability target = 1%.....................................................................................................97
Table 12: Estimation of the users per cell according to the simulation output, Downlink
Channel elements target = 256 .........................................................................................99
Table 13: Estimation of the users per cell according to the simulation output, Uplink Channel
elements target = 64..........................................................................................................99
Table 14: Estimation of the users per cell according to the simulation output, Downlink Iub
congestion target= 1070 Mbps. ......................................................................................101
Table 15: Estimation of the users per cell according to the simulation output, Uplink Noise
Rise congestion target = 60% .........................................................................................103
transmitted power congestion target = 38.7 dBm...........................................................104
Table 17: Estimation of the users per cell according to the simulation output, Downlink Code
Tree usage congestion target = 60%...............................................................................105
Table 18: Ordered KPI's, voice-only service..........................................................................106
Table 19: Estimation of the users per cell according to the simulation output, Web-only
service, parameter sf8Adm=1, Blocking probability target = 1% ..................................108
x
service, parameter sf8Adm=8, Blocking probability target = 1% ..................................110
service, Downlink and Uplink channel element target: 256, 64.....................................112
Table 22:Estimation of the users per cell according to the simulation output, Web-only
service, DL Iub congestion target = 1.07 Mbps .............................................................113
service, uplink load target = 60 % ..................................................................................114
Table 24:Estimation of the users per cell according to the simulation output, Web-only
service, DL Transmitted power congestion target = 38.7 dBm......................................116
service, DL code tree usage target = 60% ......................................................................117
service, throughput target = 100 Kbps ...........................................................................118
Table 27: Ordered KPI's, Web-only service...........................................................................119
Table 28: Estimation of the users per cell according to the simulation output, FTP-only
service, target threshold for blocking = 1%....................................................................120
Table 29: Estimation of the users per cell according to the simulation output, FTP only
service, target threshold for dropping = 1% ...................................................................121
service, target DL and UL CE usage: 256, 64. ...............................................................123
service, target DL throughput =1.07 Mbps.....................................................................124
service, target UL load = 60% ........................................................................................125
service, target Downlink power = 38.7 dBm..................................................................126
service, target DL code tree usage = 60% ......................................................................127
Table 35 :Estimation of the users per cell according to the simulation output, FTP-only
service, target throughput = 100 Kbps............................................................................128
Table 36: Ordered KPI's, FTP-only service............................................................................129
Table 37: Estimation of the users per cell according to the simulation output, video call
service, blocking probability target=0.01 .......................................................................130
service, Uplink load target = 0.6 (60%)..........................................................................131
xi
service, Downlink Transmitted Power target = 38.7 dBm .............................................132
Table 40: Ordered KPI's, Video call--only service.................................................................133
Table 41: Comparison Limiting factors, CS services, single-service experiments,

homogeneous scenarios ..................................................................................................134
Table 42: Comparison Limiting factors, PS services, single-service experiments,

homogeneous scenarios ..................................................................................................135
Table 43: Calculation of the ODV for the Service Mix, non-homogeneous scenario............139
Table 44: Summary table with the ODV Figures to be used for the analysis.........................141
Table 45: Blocking probability service mix, target =0.01 (1%) .............................................142
Table 46: Estimation of the supported number of users per service.......................................142
Table 47: Dropping probability service mix, target =0.01 (1%) ...........................................143
Table 48: Channel Elements usage, service mix, uplink and downlink channel elements target:
256, 64 ............................................................................................................................145
Table 49: Downlink Iub utilization, service mix, Downlink target 1070 Kbps......................146
Table 50: Uplink load, service mix, target 60% .....................................................................147
Table 51: Downlink power usage, service mix, target 38.7 dBm...........................................148
Table 52: Downlink code tree usage, service mix, target 0.6 (60%)......................................149
Table 53: Summary Table, capacity limiting factors .............................................................150
Table 54: List of KPIs organized by order of occurrence of their target levels .....................164
Table 55: Downlink Transmitted Power levels per cell, non homogeneous scenario ............169
Table 56: Estimation of the number of users until reaching the blocking target (1%), non
homogeneous scenario, voice only service.....................................................................170
Table 57: Estimation of the number of users until reaching the CE targets (256 DL, 64 UL),
non homogeneous scenario, voice only service..............................................................172
Table 58: List of KPIs for the non-homogeneous scenario, ordered by the occurrence of the
target threshold ...............................................................................................................177
Table 59: List of KPIs for the homogeneous scenario, ordered by the occurrence of the target
threshold .........................................................................................................................178
Table 60: Downlink Throughput levels for all services, traffic mix with voice 40 Erl/Km2,
non homogeneous scenario.............................................................................................182
Table 61: Chosen levels for the parameter Time to Trigger 1A.............................................188
Table 62: Original table for ANOVA, Cell HO attempts.......................................................191
xii
Table 63: Original table for ANOVA, Uplink Load ..............................................................192
Table 64: ANOVA of Handover attempts, additive model ....................................................192
Table 65: ANOVA of Uplink load, additive model ...............................................................192
Table 66: Logarithm transformation of the measured variable Handover attempts ...............194
Table 67: Logarithm transformation of the measured variable Uplink load ..........................194
Table 68: ANOVA of Handover attempts with the multiplicative model..............................195
Table 69: ANOVA of Uplink load with the multiplicative model .........................................195
Table 70: Ranking method applied over the simulation outcomes.........................................196
Table 71: Ranking method removing the two worst options..................................................197
Table 72: Main results for the analysis of the parameter Time to trigger 1a..........................198
threshold .........................................................................................................................201
Table 75: Ordered KPIs by number of users to reach the target, Voice-0nly service ............203
Table 76: Ordered KPIs by number of users to reach the target, Video call-only service .....203
Table 77: Ordered KPIs by number of users to reach the target, Web-only service ..............204
Table 78: Ordered KPIs by number of users to reach the target, FTP-only service...............205
threshold .........................................................................................................................206
Table 2-1: Example of assigned clutter class weights ..............................................................22
xiii
1. Introduction
1.1 Preliminary concepts about UMTS capacity
UMTS capacity, understood as the maximum number of users per cell that
can be supported while meeting the performance objectives set per each
service, is a crucial factor to have into account in the network expansion
because it allows estimating the required resources to meet future workload
demands. It is also important to ensure that at the present time, with the
current resources, the current traffic demand is being covered with the
sufficient quality per each service. At the first stages of a network roll-out,
operators try to focus their initial cellular design to get as much coverage as
possible. But then, when the traffic starts increasing, problems can arise if
they are not somehow prevented or detected.
In UMTS, the detection/prevention of capacity problems in the network is not

quite straightforward because the capacity changes dynamically and it is
always in a trade-off with the coverage: when a cell becomes heavily loaded,
its coverage “shrinks” (phenomena known as “cell breathing”). The dynamics
in capacity (and therefore in coverage) are given because in UMTS each
transmitted signal increases the noise level of the overall system. As capacity
is related to the signal over noise ratio, a noise increase reduces overall
capacity [Eurescom]. Besides, the load level in a UMTS system depends on
several factors/parameters that sometimes are difficult to measure/quantify,
among them the type of service (each service normally has a different
coverage area), the traffic pattern of each service (data arrival process), the
user speed / mobility profile, the spatial distribution of the traffic demand
(hot-spots, railways, etc), the environment (urban, sub-urban, rural) and
some other radio physical parameters related with the propagation
phenomena, such as macro-diversity gains, efficiency of Rake Receivers, etc.
Therefore, methods have to be developed to guarantee two fundamental
issues:
a. Ensure that the currently available resources are used to provide the
highest performance (also known as capacity management [Jain])
b. Ensure that enough resources will be available to meet the future
workload demands (also known as capacity planning [Jain]).
15
1.2 Problem Statement
The capacity dimensioning of the GSM/GPRS networks at Vodafone

Netherlands (i.e. the maximum number of users per cell that can be
supported while meeting the performance objectives set per each service) is
based on simulation studies. For GSM/GPRS results have been available for
some time that enables the operator to dimension the capacity of the radio
network efficiently. For the next generation of mobile telephony (UMTS)
these results are not yet produced. The technology of UMTS radio access is
so different from GSM that new methods need to be developed to dimension
these networks. Besides, previous 2G networks have been designed mostly
to support only-voice applications, where well-known models (Erlang) can be
applied to estimate the capacity of the network. With UMTS, new multimedia
services are introduced and there is not yet a standardized method that allow
us to estimate the capacity of the network with such a mix of services with
different characteristics (different traffic models).
Specifically, there are two big challenges when performing capacity

dimensioning in UMTS Networks:
• In UMTS capacity changes dynamically according to several factors

(network load, characteristics of the antennas used, bit rates, multi-
path conditions) which makes the analysis of such networks an
extremely complex task if traditional methods are applied. Besides, the
cell edge in UMTS is constantly moving, so there is no fixed cell
coverage (and therefore there is no fixed capacity as capacity and
coverage is always a tradeoff in UMTS networks).
• It is difficult to dimension multiple data rates, switching modes and

service mixes, all working together at the same time. Different
services have also a different coverage area depending on the data
rates and the type of Bearer Service being used. Estimations about
service usage patterns in space and time are hard to predict and/or
calculate with standard methods.
Summarizing, the problem statement is, taking into account these

challenges; try to develop some guidelines for UMTS capacity dimensioning
based on the analysis of simulation results of a UMTS network.
16
1.3 Objectives and scope this work
1.3.1 General Objective
The main goal/objective of this assignment is to investigate the performance

(measured on a defined set of Key Performance Indicators (KPI’s)) of a
UMTS terrestrial radio access network (UTRAN) under different scenarios and
perform an analysis of the simulation results in order to develop methods for
dimensioning the network optimally.
Examples of such scenarios are:
• Homogeneously distributed, non-mobile traffic

• Homogeneously distributed, mobile traffic
• Non-homogeneously distributed, non-mobile traffic
• Non-homogeneously distributed, mobile traffic
Part of the assignment is also to verify the behavior of the UMTS network
with a limited number of parameters in the simulator using and/or mapping
the UMTS current network settings in the real Vodafone UTRAN (Ericsson
RRM parameters).
1.3.2 Scope
• The assignment is aimed to perform a capacity simulation study.

Although it will also mention some coverage issues as these two terms
are unavoidable inter related in UMTS-WCDMA, the main focus is
capacity analysis (how many users can be safely supported by the
UTRAN in each scenario with certain traffic mix and mobility
characteristics) and not about coverage predictions.
• The assignment doesn’t include the radio-planning stages of

Optimization and Monitoring which are out of the scope of it.
• The tool to use to perform the Dynamic Simulations will be Radio Plan
Wines.
• The UMTS-WCDMA part of the system to study includes the radio

network part (UTRAN) and its corresponding RRM algorithms. It
doesn’t include the Core Network dimensioning.
17
1.4 Problem Solving Approach
1.4.1 Assignment parts
For the first part of the assignment, simulations are going to be performed
over an analysis area defined in common agree with our international
colleagues of Vodafone. The distribution of the traffic in this simulation
scenario is homogeneous and the main purpose is to find capacity Figures
when increasing the traffic density of one of the four possible defined
services (WWW, FTP, Voice and Video-call) and also with a given traffic mix
involving all services together. Two mobility profiles are used (pedestrian and
vehicular).
In the second part of the assignment, a more “realistic” scenario (scenario

based on real clutter data) is simulated (the traffic density is no longer
homogeneously distributed). The purpose is to analyze the possible
differences in capacity between the “ideal” model and the more “realistic”
model.
Part of the assignment is to verify a number of parameters in the simulator

regarding Vodafone current UMTS network settings.
To achieve the proposed objectives, the project involved a lot of different

activities that had to be performed before, during and after the simulations.
A summary list with these activities is provided here:
1.4.2 Activities before simulation
• Understand the UMTS-WCDMA Radio Resource Management

algorithms (including Power Control, channel switching, handover,
capacity management and connection handling).
• Understand how the different propagation phenomena (like path loss,
shadowing, fast fading, intra-cell interference, inter-cell interference,
pilot pollution) impact the performance of a UMTS RAN and how they
are modeled and what assumptions are made for the simulation of
these phenomena.
• Get acquainted with the whole radio-planning process (specially with
the capacity dimensioning part) which is aimed to balance coverage
and capacity while meeting the KPIs (Key Performance Indicators)
thresholds
• Investigate the state-of-art of radio capacity planning for UMTS-
WCDMA and, according to the simulation analysis, propose some
general guidelines for Vodafone Engineers.
• Get acquainted with the Dynamic Simulation Tool (Radio Plan), its
different options and parameters, the models they use internally to
18
make the simulation, understand its limitation and capabilities and try
to determine how different should be a real-world scenario compared
with a simulation-scenario.
• Get acquainted with statistical techniques (especially design of
experiments, 2^k factorial designs) to perform a systematic analysis
of the simulation results.
• Propose different simulation scenarios, agree in the Traffic Mix to be
used (service and service portion definition), Agree in the Traffic Model
(Data arrival process) for each service and estimate the corresponding
traffic densities to be simulated.
• Get acquainted with Ericsson Documentation of Vodafone Netherlands
UMTS-WCDMA equipments; understand its different parameters and
how they should be mapped to Wines in order to perform simulations
with realistic network settings.
1.4.3 Activities during Simulation
• Perform the corresponding experiments (simulations) under different

conditions (different traffic distributions, different mobility profiles).
1.4.4 Activities after Simulation
• Collect the results and perform comparative analysis using specific

KPI’s of the simulations under those different scenarios.
• Perform sensitivity analysis over a limited set of UTRAN parameters.
• Give conclusions that help to dimension the radio-access network
optimally having into account the obtained results.
1.5 Document Structure
The structure of the chapters is as follows:
Chapter 1 Presents the problem statement, the objectives and scope of the
work and the approach used to solve it.
Chapter 2 Introduces the required concepts about simulations and capacity

studies.
Chapter 3 presents the results of the literature study concerning radio

planning methods for UMTS including the capacity analysis and capacity
planning parts.
19
Chapter 4 is an introduction to the Wines Dynamic Simulator and its main

features.
Chapter 5 introduces the first simulation scenario, it’s main characteristics,

the list of assumptions, including the load parameters (traffic models) and
the system parameters (UMTS Network parameters of the RNC, Node Bs and
Cells), and the design of the experiments required to collect the information.
Chapter 6 introduces the second simulation scenario with its main

characteristics, list of assumptions and the corresponding design of the
experiments.
Chapter 7 presents the analysis of the simulation results of the 1st

simulation scenario.
Chapter 8 presents the analysis of the simulation results of the 2d

simulation scenario.
Chapter 9 presents a comparison between the results obtained for the “ideal
model” and for the “more realistic” one.
Chapter 10 draws the conclusion of this work and proposes the future work.
Moreover, the following appendixes are also provided:
Appendix 1: UMTS fundamental concepts (it is aimed to introduce the

required concepts for the reader who is not familiar with UMTS).
Appendix 2: Procedure for exporting a simple traffic map based on clutter

data from ATOLL to Wines
Appendix 3 (confidential): Traffic Model parameters
Appendix 4 (confidential): System parameters
Additionally, all the Excel sheets containing the simulation outputs and the
summary sheets where the statistical analysis was performed per each
Scenario /KPI level are also provided.
20
2. Capacity and Simulation
(introductory) concepts
2.1 The capacity and KPI concepts
One of the first tasks of this work was to clearly define what is understood by
capacity within the scope of the project. In the consulted literature [Jain]
[Holma], [Madder], [ITU], several different definitions about capacity were
found. The idea of “capacity” therefore, is not a single one as far as literature
about system performance concerns.
Generally speaking, capacity is a measure of how able a system is to provide

an acceptable response to its users, when the conditions of the load are
varied from low to high. This response has to be measured in what is called a
KPI (Key Performance Indicator). Two of the most common KPI’s, present in
almost every telecommunications system, are throughput and response
time. For the purpose of measuring each performance indicator, each KPI
has to be clearly defined (the “what”) as well as in the specific system, one
has to be able to define the mechanism(s) to measure it (the “how”).
About throughput and response time, which are commonly used in this type
of studies, two very concise definitions can be found in [Jain] and they are as
follows:
Response Time is defined as the interval between a user’s request and the
system response. However, one has to take into account that the requests as
well as the responses are not instantaneous: the user takes time generating
a request, and the system also takes time to produce a response. Then, two
possible definitions of the response time would be:
• Definition 1: The time interval between the end of a request

submission and the beginning of the corresponding response from the
system
• Definition 2: The time interval between the end of a request

submission and the end of the corresponding response of the system.
21
Both definitions are acceptable, however the last one seems to be the most
widely used. Both are illustrated in the next graph.
User
User User System System System
Starts
fi i h l
time
Reaction
Think
Response Time
Response Time
Figure 1: Different definitions of Response Time KPI [Jain]
Throughput is defined as the rate (requests per unit of time) at which

requests are serviced by the system. For batch streams, it is measured in
jobs/sec. If we are talking about networks, then the common measure is bits
per second (bps) or packets per second (pps).
Some of the definitions related to UMTS capacity found in the literature which
talks about UMTS system dimensioning are as follows:
• Pole capacity [Jaber]: the pole capacity is defined as the maximum

capacity of a UMTS cell, which referrers to the 100% cell load.
• 3GPP full capacity [30.03]: traffic loading in a cell which results in 1%

call blocking with BER =0.001 maintained.
• Capacity [Mader] means the maximum possible offered load for a Base
Station (Node B) with a particular service mix while meeting
predefined blocking probabilities.
Making an abstraction out of the available definitions about capacity, we can

say that for the context of this study, capacity refers to the Maximum
number of users per cell that can be supported while meeting the
performance objectives (set per each service).
22
2.2 Soft capacity vs. hard capacity
In WCDMA systems, the capacity has a very important feature: it has no

single-fixed value; system capacity in UMTS is a stochastic value that
depends on several factors: multi-path propagation, orthogonality in UL/DL,
thermal noise, received interference at the mobiles and Node B, among the
main ones.
This dynamic characteristic presents a big difference regarding systems like

GSM, where the capacity is considered deterministic (it has a single value
determined by the number of carriers per cell and the number of timeslots
per carrier and it doesn’t depend on the interference levels as much as in the
UMTS case). This single-value number is known as the GSM’s hard
capacity, because on these systems the capacity of the system is limited by
hardware but not by the interference scenario, which can degrade the
communications of the users but doesn’t influence the capacity limit of the
system.
In contrast, in 3G systems, the capacity cannot be expressed as a single

value; it has to be defined as a set of resources interacting among them.
Among the most important ones, we can mention Soft capacity resources
and hard capacity resources:
• Soft capacity resources: refers to the resources limited by the load

of the system in Uplink and Downlink that change according the
interference situation and the power consumption and
position/mobility profile of the users, the two most important soft-
capacity resources are Interference Level at node B (known as Uplink
Noise Rise or Interference above thermal noise level) and Downlink
Transmission Power at node B. The number of available codes is
considered also a Downlink soft capacity resource because it changes
dynamically according to the network load.
• Hard capacity resources: refers to the hardware resources

associated to each radio link, normally known as channel elements
(although this name varies according to the manufacturers). Each
manufacturer defines a given number of channel elements per each
Radio Access Bearer, and these number of channel elements are also
an indicator of how many Hardware Boards are required per each Node
B. Hard capacity includes also the capacity of the link(s) between
every node B and its controlling RNC; this link is defined in the UMTS
architecture as the Iub interface.
23
Therefore, having defined both “soft” and “hard” capacity resources, one can
also talk about “soft blocking probabilities” and “hard blocking probabilities”:
Hard blocking probabilities are easy to calculate in hard capacity limited
systems using known models (Erlang B or Erlang C). This models are very
accurate when calculating single service, circuit switched traffic (e.g. Speech-
only service), given that the assumptions made in the model (exponential
inter arrival times and exponential call duration) are generally true for
Telephony systems.
On the other hand, Soft Blocking probabilities cannot be calculated from

Erlang-B formula, given that it would give too pessimistic results. Besides,
the resource consumption of a single connection depends on the interference
situation as well as the type of service (voice, CS-64, PS-384, etc) and it is
not quantizable, which is one of the basic assumptions of the Erlang Model.
In contrast, for hard capacity, each connection consumes always the same
amount of hardware resources depending on the service, independent on the
interference situation and the position of the mobile regarding the Node B
Antenna.
Summarizing, the capacity of a 3G cell is described not by a single number

but by the utilization of a set of hard and soft resources, being the most
relevant ones:
Soft Resources:
• Uplink Interference
• Downlink Power
• Downlink Spreading code usage
Hard Resources
• Baseband capacity (channel elements)

• Iub capacity (UL and DL, Kbps)
For each one of these quantities, a threshold value must be defined

reflecting the target quality objectives (for instance, we can define a
threshold for Uplink Interference of 70%). Then the corresponding counters
(monitors) have to be implemented in the system so when the system is
close to any of the threshold levels, the operator, by collecting the proper
statistics, can determine whether or not to perform a capacity expansion in
the network. However, as it has been described, in UMTS capacity cannot be
defined just by one indicator, so a proper statistical analysis which involves
all the hard/soft resources have to be performed from time to time in order
to determine in advance when it is time to upgrade the system with more
capacity.
24
2.3 Capacity management vs. capacity planning
Capacity management is a term that denotes the activity to ensure that

the currently available resources are used to provide the highest
performance to the users.
On the other hand, Capacity planning refers to the activity of ensuring that
adequate resources will be available to meet the future workload demands
while meeting the performance objectives.
Therefore, capacity planning, which is a fundamental part of the Radio

planning process, it is concerned mainly with the future performance,
whereas capacity management is concerned with the present time.
Capacity management as described in [Ericsson-capacity] controls the load

in the WCDMA cell, by performing:
• Monitoring the utilization of critical resources (e.g. downlink power,

number of available codes) for the new radio link connections in a cell
• Enforcing of admission policies on critical system resources
• Detect and resolve overload situations on critical resources
In both activities (planning management), the steps involved are basically

the same [Jain]:
• Instrument the system (i.e. define counters)

• Monitor usage (i.e. gather system data, for instance log files)
• Characterize workload: For capacity planning, the workload is
forecasted based on long term monitoring of the system.
measurements are currently not an option because at this moment of
time (September 2005) there is still not enough traffic in the UMTS
Networks that allows us to forecast how the network is going to grow
and what capacity upgrades are going to be required, therefore this
workload characterization is done either empirically (making
assumptions) or based on collected GSM-GPRS measurements.
• Performance prediction: different configuration alternatives and future
workloads are input to a model (e.g. a dynamic network simulator
modeling a specific UTRAN) in order to predict the performance.
• Select the lowest-cost and high-performance alternative.
25
2.4 Performance Evaluation Techniques
The capacity planning and capacity analyses are by themselves two cases of
performance evaluation over complex systems with complex dynamics in
space and time.
We could say, generally speaking, that there are three techniques to face the
performance evaluation of a system like UMTS RAN:
Analytical Modeling
Simulation
Measurements
There are advantages and disadvantages for each one of the techniques, so
basically the selection of one, or a combination of such techniques (in
practical problems, the use of two or more techniques is a common
approach), depends very much on the problem and it has to take into
account important considerations, such as:
life-cycle stage of the system

Time and knowledge required
Costs
Availability of Tools
Accuracy
A complete discussion about these considerations is presented in [Jain]. As it

is mentioned there, the key consideration in deciding the evaluation
technique is the life-cycle stage in which the system is. For instance,
measurements are possible only if something similar to the proposed system
already exists. In the case of UMTS, at the present time there are not
enough measurement studies that deal with the complexity of a system
trading off dynamically the cell capacity and cell coverage with a mix of
different services with different data rates, different traffic distributions and
different usage profiles. Besides, it is very difficult and costly to test, for
instance, an overload situation in a live network or even a test network. As
the UMTS traffic in the current networks is not enough (at the present time)
to see overload situations and other kinds of very specific performance
problems, measurements are still not an option to undertake a capacity
study because the load level is still not representative.
In terms of statistical and probabilistic complexity, we are facing a system

with a dynamic mix of services, with different rates and switching modes;
and a system that changes dynamically its coverage and capacity. Currently,
there are no closed-form well-known analytical solutions for modeling multi-
service traffic in UMTS. The traditional static approach used in voice-only
26
networks, the Erlang-B and Erlang C models, works well in such kind of
single-service voice-only networks, but there is no way to apply directly the
Erlang model when we have a mix of circuit-switched and packet-switched
services sharing the air interface, as in the UMTS case.
Besides, the data arrival models, also known as traffic models, are very
different between circuit-switched and packet-switched services. The way we
traditionally model circuit-switched services with a Poisson arrival process
(process that states that call arrivals are mutually independent and the call
inter-arrival times are all exponentially distributed with one and the same
parameter λ), doesn’t fit very well with packet-switched services, because
Poisson arrival cannot cope with the burstiness (i.e. high variability: from
extremely short service times to extremely long ones and from extremely
low-rate to extremely high-rate connections) of these services. Some
interesting approaches to cope with the burstiness of data traffic using fractal
distributions are presented by Willinger and Paxon in their papers
[Mathforinternet] and [Wedontknow].
Therefore, in this very complex scenario where a single closed-form

analytical model cannot be used and also a measurement over the current
system is not representative, one could say that Simulations can be the best
approach to deal with UTRAN air interface capacity-related issues. The
argumentation about the Simulation approach is presented in the next
section.
However, in practice, the best combination is to validate simulation with

analytical modeling, in order to verify and validate the results of each one. To
this respect, [Jain] presents three practical simple validation rules:
• Do not trust the results of a simulation model until they have been
validated by analytical modeling or measurements.
• Do not trust the results of an analytical model until they have been
validated by a simulation model or measurements.
• Do not trust the results of a measurement until they have been validated
by simulation or analytical modeling.
One of the future-work activities that are proposed on this report is the
validation of Simulation Results using measurements. This was considered
out of the scope of this project due the limited amount of time.
2.4.1 Why Simulations are the right option in this case?
First of all, simulations are an easy way to predict the performance or

compare several alternatives.
27
For instance, with simulations, it’s easy to answer questions like “What
happens if we modify X parameter at Y value?” without performing costly live
lab tests or making test over the production network (a practice that should
be avoided at all given the serious effects that can be caused on it).
Secondly, a simulation also has the advantage over the analytical approach
that the model can be more detailed (i.e. with less simplifying assumptions)
and therefore its results more close to the reality.
Thus, if we have a tool that mimics the Radio Resource Management

Algorithms with a good level of detail, we can try different configuration
settings in the network elements and see the performance of the network,
before making any change in the real network setup.
Simulations are also a good option when modeling system dynamics based
on stochastic processes: in the tool being used, each user of the system is
modeled as a random process that asks for a service and moves in space and
time and at every time interval the contribution of the other users to the
overall network performance is being tested; this would be something very
difficult to model just with the help of analytical techniques.
Finally, simulations allow us to test the system under different workloads and
environments; i.e. changing the environment parameters, we can observe
how the network with the same system parameters setting behaves in terms
of KPIs.
2.4.2 Limitations of the simulations
As it was mentioned before, we cannot provide absolute Figures with

simulations: all the Figures that we get are valid just for the scenario being
tested and under the assumptions being made.
We cannot ask also for accuracy in the results, unless we have some
feedback (measurements) from a real system to make a comparative
analysis of the outcomes (simulation tuning).
Third disadvantage of the simulations is the time that they take and the
knowledge required to parameterize the system (as simulations can model
the system in a more detailed way than the analytical approach); usually the
more detailed the simulation tool, the longer time it takes. Also, when
making statistical analysis over the simulation results that involves inter-
relations among parameters, the complexity (and time) of these analysis
depends on the number of parameters (factors) to be analyzed and the
number of levels (values) defined for each parameter. There are some
statistical techniques, as the ones mentioned in [Jain] that try to reduce the
complexity and deal with these kinds of analysis. These techniques are going
to be applied in this report whenever it is possible.
28
2.5 Summary of Chapter 2
Why to use simulations?
With simulations, it’s easy to answer questions like “What happens if we

modify X parameter at Y value?” without performing costly live tests.
Simulations are also a good option to test systems with complex dynamics in
space and time (as the UMTS RRM algorithms), whose analysis, based on
stochastic processes, is almost impossible to perform with pure analytical
techniques. With UMTS dynamic simulations is possible to model user’s
dynamics in space and time and therefore it is possible to mimic different
mobility profiles (e.g. vehicular, pedestrian) and different traffic distributions
(distribution of the active users per area unit) and check the performance of
the network in different load and usage profile scenarios.
Simulations also allow us to test the system under different environment

settings (i.e. urban, rural, with/without shadowing, etc); then changing the
environment parameters, we can observe how the network with the same
system parameter setting behaves in terms of KPIs in the new environment.
Detailed environment data can be exported from common radio planning
tools to Wines Dynamic simulator.
Currently, two simulation approaches regarding the time dependence of the

results are used in Radio Planning: Static (also called Snapshot or Montecarlo
simulations) and Dynamic simulations. The main difference between them is
presented in the corresponding section of the chapter 4.
Limitations of the simulations
We cannot provide absolute Figures with simulations: all the Figures that we
get are valid just for the scenario being tested and under the assumptions
being made.
We cannot ask also for accuracy in the results, unless we have some
feedback (measurements) from a real system to make a comparative
analysis of the outcomes (simulation tuning). As a future work, it is proposed
a study that allows testing the accuracy of the simulation results with Wines
comparing them with measurements from the live UMTS network.
Another disadvantage of the simulations is the time that they take (specially
Dynamic simulations are very time and resource consuming) and the
knowledge required to parameterize the system.
29
3. The Radio Planning Process

(literature study)
The process of UMTS-WCDMA Radio Planning is well described in the
literature [Holma], [ITU], [Alcatel], [Jaber], [Dinan]. All of them make
reference to the required steps of
Dimensioning
Detailed Capacity and Coverage planning
Network Optimization
The differences in the descriptions are basically in the way those steps are
connected and how they implement the feedback. For this study, I will
introduce the Radio Planning Process using the ITU IMT-2000 vision
presented in [ITU], although the description of each activity is complemented
with all the information mentioned in all the literature consulted regarding
this process.
3.1 The Radio Planning Process (ITU’s IMT-2000)

vision
The following graph illustrates the key steps of the UMTS W-CDMA Radio
Planning process according to [ITU]
30
Traffic prediction
1 Definition of the radio parameters,
WCDMA and marketing
Number of sites
2 Dimensioning
Inter-site distance
Capacity and coverage planning

Base station
3 configuration,
Network performance simulation Network analysis

4 Theorical validation
5 Real sites search Radio site validation
Radio planning process Results
Figure 2: ITU's IMT-2000 Radio Planning Process
The steps are performed as follows:
3.1.1 Definition of the radio Parameters, WCDMA and

marketing
In this first step, the main (radio) features of the mobiles and Base Stations
(Node-Bs) are defined (for instance: power levels, noise Figures, antenna
gains, sensitivity), together with the definition of the services and a first
estimation of the traffic.
However, this last estimation is very difficult to predict, because at the

present time there is not enough data about the usage (in space and time) of
these new multi-media services. Two approaches are being taken for the
traffic estimation:
a) Uniform Traffic Distribution: in this case, we associate to an area

uniform traffic densities (Erl/Km2) for the different services considered in
the analysis. This approach is taken normally to generate a rough traffic
prediction for the dimensioning process, given that in an area with the
same uniform traffic distribution, one cell is representative for the whole
network, meaning that all parameters are valid for all cells. Of course, the
31
impact from other cells (interference, soft handover) is also taken into
account.
b) Non-uniform Traffic Distribution: This approach uses demographic

databases and real traffic estimation are used (for instance, statistics
collected from GSM/GPRS networks), so for each elementary calculation
area, known as pixel, there is information about its traffic distribution.
The outcomes of this approach are the so-called Traffic Maps. However,
there is not yet an standardized method to perform this, the generation of
UMTS traffic maps is currently a research area within Vodafone and other
companies.
The output of this first step is the Traffic Prediction (traffic densities per area
unit, normally given in Erl/Km2) for each one of the services of the network.
3.1.2 Dimensioning
This important step includes:
• radio link budget and coverage analysis

• capacity estimation (initial capacity planning)
• Estimations on the number of sites required.
All of them are going to be briefly explained in the coming sections.
3.1.2.1 Radio Link Budget and Coverage Analysis
In GSM networks, the link budget is used to estimate the expected cell radius
in a given environment. This link budget in GSM constitutes a relative simple
operation and can be performed manually since it only deals with
propagation parameters.
In UMTS networks, the situation is much more complex, as every user is

generating interference for other users in the network (all of them are
sharing the same frequency band). Therefore, the cell radius is dependent on
the traffic load at any given time, and it has to be estimated in an iterative
way in both Uplink and Downlink, analyzing each one separately. Both
Uplink and Downlink analysis will result in a cell range value, and the
final cell range will be the smaller of the two outcomes.
The following graph illustrates the Uplink Iteration Process and it is based on
the description provided by (Alcatel). The Downlink Iteration process has
some important differences, mostly because the main reference for the
calculations is not the interference level but the total Downlink Power. Details
are not mentioned here for the sake of brevity; however the reader is invited
to take a look at (Alcatel) to obtain more information about it.
32
Assume Initial Interference
Noise Rise, e.g. Ico = 3 dB
Calculate UL cell range

with maximum mobile Tx
power for all services
Choose the limiting cell

range (smallest one)
Deduce mean traffic

per cell (knowing cell
range and user density)
Apply System-level
simulation for a given
cell load (e.g. ηul=99%)
Calculate Interference
level
Try with new value of

Ico
Converge
Current Radius is
nce of Ic
UL cell radius
and Ico?
Figure 3: UL iteration process
Continuing with the UL iteration process example, to calculate the cell range,
one has to define first the sensitivity (minimum required power level at the
receiver in order to be decoded) for a reference user i of each service k:
Required_Leveli [dBm] = NF + 10 Log (No) + 10 Log (ioi) + 10 Log [ Eb/No k] + 10 Log Rk
(3-1)
33
Where:
• NF = Node B noise Figure [dB]

• No = thermal noise density, normally assumed to be -174 dBm/Hz
• Eb/No k = Eb/No for the service k (linear Figure)
• Rk: Service k bit rate (bps)
• ioi = Noise Rise due to interference (linear Figure)
To calculate the Maximum path loss, the following equation is used

Lmax, i = PULk – Required_Leveli – Σ losses – Σ margins + Σ gains (3-2)
Where:
PULk is the mobile power valid for service k [dBm]. In equation 3-2, all the
Losses, margins and gains are given in dBs.
Once determined this Figure for all services, the smallest Lmax is chosen as
the limiting maximum path loss. And applying a propagation model (e.g.
Okumura-Hata, Walfisch-Ikegami); we can derive the corresponding cell
range.
Now, we have to find the cell load to be able to determine the interference
over noise rise and compare this Figure, at the end of the UL iteration
process (the final decision symbol of Figure 11), with the initial assumption .
First, for each service, we can deduce the traffic per cell as the number of
subscribers per square kilometer is known or assumed from the previous
step in the radio planning process and the area can be expressed in terms of
the cell range found; for instance for an hexagonal cell with omni-directional
antenna, the area is around 2.6R2, where R = cell range [Kms].
The next step is to calculate the load in the cell, several approaches are
mentioned in [Alcatel], [Holma], [Jabber], the one presented in [Jaber]
which is based on a modified stochastic knapsack model for multi-service
UMTS capacity analysis says:
ηul (uplink load factor) = number of active users / Pole Capacity (3-3)
Where “Pole Capacity” means 100 % cell load and is given by:
Npole, UL = W / (1 + ful) Σ j=1..k Vj * Rj * Pj [Eb/No j / (1 + Eb/No j *Rj /W )]] ( 3-4)
Where:
• W : chip rate, in W-CDMA is fixed to 3.84 Mchips/sec
• K = number of offered services
• Eb/No j is the required Eb/No for the service j (j=1…k)
• Rj is the bit rate of service j
• vj is the activity factor of the service j.
34
• Pj is the percentage of the total active users who are using service j
• f = other cell / own cell interference ratio, as seen by the Node B
receiver, usually is assumed a value of 0.55 (55%) for a macro cell
with omni-directional antennas, although more precise methods to
calculate the other cell interference can be seen in [Staelhe2004].
Once we have cell load, we can calculate easily the Interference Noise Rise
because is given by:
NR [dB] = - 10 Log10 (1 - ηul) (3-5)
And then proceed to estimate the convergence of this value with the
assumed one in the initial step.
The output of the Radio Link Budget and coverage analysis is the cell range
(and the corresponding cell area coverage).
3.1.2.2 UMTS Capacity Estimation
UMTS capacity, understood as the maximum number of users per cell that
can be supported while meeting the performance objectives set per each
service, is a crucial factor to take into account in the network expansion
because it allows estimating the required resources to meet future workload
demands. The capacity planning thus has to be done before setting the real
network (in which case corresponds to the capacity estimation or initial
capacity planning described here) and also when capacity management
(capacity analysis) detects that it is moment to improve the capacity of a site
or the network in general.
The major differences in UMTS capacity planning, regarding GSM networks, is

that whereas in GSM coverage is planned separately after the network
capacity has been dimensioned (based on market studies), in UMTS
coverage and capacity must be planned at the same time, because
coverage and capacity are constantly influencing each other, giving rise to
phenomena like the “cell breathing” effect where the cell coverage area
“shrinks” (i.e. mobile phones in the cell border that are transmitting at their
maximum power cannot increase their power levels more and thus eventually
they get disconnected unless a handover to other cell takes place) if there is
a higher interference in the cell (caused by the arrival of more users within
the cell-coverage area and the current users of the cell (intra-cell
interference) and also caused by some mobiles connected to another base
stations (inter-cell interference)).
Since in WCDMA each user is influencing each other, the whole prediction (of
capacity and coverage) have to be analyzed at the same time and has to be
done iteratively until the transmission powers stabilize.
35
3.1.2.3 Estimation of the number of required cells
Based on the capacity and link budget, the number of cells required to cover
a given area can be calculated. A UMTS network can either act as a coverage
or capacity limited in any given moment. Capacity limited means that the
maximum cell radius can’t support the total offered traffic because there are
not enough resources to do it. Coverage limited means that there is
enough capacity in the cell to support the traffic, but the maximum cell range
of a mobile (because it’s limited transmission power) limits it. [ITU]
3.1.3 Detailed Capacity, Coverage Planning and Network

Performance Simulation
After the cell count has been obtained in the previous step, detailed radio
network planning, taking into account the exact radio environment (with high
resolution geographical data and accurate propagation models) can start with
the goal to calculate the optimum base station locations, configurations and
parameters; and to analyze the network global performance in terms of
capacity and coverage [ITU]. Both planning processes (capacity and
coverage) are performed with the help of a specialized Tool (the system-level
simulator), which corresponds to the “Network performance simulation”
element mentioned in the ITU's IMT-2000 Radio Planning Process. Both
processes are going to be described as Detailed Coverage and Capacity
Planning in the next sections. The output of both processes (which are
performed simultaneously in UMTS) is the analysis of the simulation results
in terms of network performance.
3.1.3.1 Detailed Coverage Planning
Once we have the Figures of the previous steps, detailed radio planning,
taking into account information about the radio environment (high resolution
geographical data, clutter information and accurate propagation models as
Walfisch-Ikegami, Okumura-Hata, among others) can be started (normally
this is done with the help of a specialized tool, namely a System-level
simulator) with the goal to calculate the optimum base station locations,
configuration and parameters and to analyze the global network performance
in terms of capacity and coverage [ITU]. This includes advanced studies to
avoid undesirable situations as the pilot pollution (the presence of too many
pilots with significant power levels in the same area, that can cause problems
in the user terminals because normally the receivers cannot handle more
than 4 pilots at the same time, and also brings an increase of Interference, a
higher rate of Errors, the so-called “ping-ponging” effect causing excessive
usage of unnecessary handovers and increased dropped-call rates. Those
studies can be carried with the help of specialized tools such ATOLL [Atoll].
The whole planning process thus includes activities such as:
36
• Detailed characterization of the radio environment
• Channel Power Planning (to avoid Pilot Pollution)
• Soft Handover Parameter Planning
• Iterative network coverage analysis based on simulations
• Network Optimization (to ensure that the network resources are used
efficiently)
3.1.3.2 Detailed Capacity Analysis
As it is very important to be able to dimension the network for future load

(capacity planning), it is also important to ensure that at the present time,
with the current resources, the current traffic demand is being covered with
the sufficient quality per each service (capacity management). At the first
stages of a network roll-out, operators try to focus their initial cellular design
to get as much coverage as possible. But then, when the traffic starts
increasing, problems can arise if they are not somehow prevented or
detected.

quite straightforward because the load in the system depends on several
factors/parameters, among them the traffic pattern of each service (data
arrival process), the user speed / mobility profile, the spatial distribution of
the traffic demand, the environment (urban, sub-urban, rural) and some
other radio physical parameters related with the propagation phenomena,
such as macro-diversity gains, efficiency of Rake Receivers, etc. Therefore,
methods have still to be developed to guarantee two fundamental issues:
a. Ensure that the currently available resources are used to provide the
highest performance (capacity management)
b. Ensure that enough resources will be available to meet the future

workload demands (capacity planning).
The process that ensures to guarantee these two capacity issues is known as
Capacity Analysis.
Compared with capacity analysis in 2G networks, UMTS capacity analysis

seems to be more challenging because two main reasons:
• Firstly, the existing coverage-capacity trade-off due that capacity

requirements and traffic load influences coverage, makes the cell edge
in UMTS to be constantly moving according to these factors; this is
because each user is influencing the others and causing their
transmission powers to change (power control) because they are
37
sharing the same interference resources in the air interface, and

consequently the range of the cell decreases when the load of the cell
(and so, the noise level) increases (phenomenon known as “cell
breathing”)
• The second challenge is how to dimension the multiple data rates,
switching modes and service mixes supported by 3rd Generation
systems. Traffic analysis for such mixed services is a relatively new
concept that is being studied at the moment with the help of advanced
tools such as simulators. The estimations about service usage patterns
in space and time are, however, hard to predict and/or calculate with
standard methods. That is why dynamic simulators, that are advanced
tools able to model a group of users being modeled each one as a
stochastic process representing the activation of users and their
activity during a service session, seem to be a good alternative to
determine the behavior of a UMTS network under different service,
traffic, environment and propagation, and user mobility conditions.
3.1.4 Real sites search
This step deals with site acquisition according to the initial plan given by the
theoretical validation of the step before.
As this is an issue that is not always easy to settle among the operator and
the owner of the sites, sometimes the physical element has to be placed in
another place regarding the initial planning. Therefore, the plan has to be
updated accordingly and the Steps 3 and 4 have to be redone as well to
ensure again an overall good network performance.
38
3.2 Summary of chapter 3
The major differences in UMTS capacity planning, regarding GSM networks, is

that whereas in GSM coverage is planned separately after the network
capacity has been dimensioned (based on market studies), in UMTS
coverage and capacity must be planned at the same time, because
coverage and capacity are constantly influencing each other, giving
rise to phenomena like the so-called “cell breathing”.

quite straightforward because the load in the system depends on several
factors/parameters, among them the traffic pattern of each service (data
arrival process), the user speed / mobility profile, the spatial distribution of
the traffic demand, the environment (urban, sub-urban, rural) and some
other radio physical parameters related with the propagation phenomena,
such as macro-diversity gains, efficiency of Rake Receivers, etc. Therefore,
methods have to be developed to guarantee two fundamental issues:
• Ensure that the currently available resources are used to provide the
highest performance (also known as capacity management)
• Ensure that enough resources will be available to meet the future

workload demands (also known as capacity planning).
39
4. Introduction to Wines
Dynamic System-level
Simulator
This chapter will explain in short the main characteristics of the Simulator
being used for the study (Dynamic, System Level, Discrete Event), the
advantages, disadvantages, and the main features about System Modeling
(including the RRM algorithm modeling and Environment Modeling
(shadowing, multi-path propagation, orthogonality in DL, etc) and User
Modeling (including call generation process and data arrival (traffic models)
). A more complete guide and description of the tool can be found on
[Winesuserguide], [Winestechref], [atollsyncmod] and [RRMEricsson].
4.1 Different Simulation Approach: Static vs. Dynamic
A UTRAN Static Simulator is a simulator that represents the UMTS Radio

Network behavior at a certain moment of time, the so-called “snapshot” of
the system. The snapshots represent, among other things, the spatial
distribution of users in the network at a certain moment in time. However,
the snapshots doesn’t have any common time reference among them, so it is
not possible to answer questions about the system status in the “previous”
snapshot because there is not such “previous” and “following” concepts in
this kind of simulations.
In each of the snapshots, a random user distribution with a configurable

service mix is generated. Then the power control and some RRM algorithms
are performed which can lead to rejected or blocked users. Since in a
snapshot it is not clear whether a user just entered to the network or had
already been in the network for a certain time (because of the lack of a time
reference), a general distinction between blocking and dropping is not
possible, as it is possible in the Dynamic case. [Winessnapshot]
Within every snapshot, multiple iterations are run until certain convergence
conditions are met and the snapshot can be considered to be in a steady
state. For instance, uplink transmission power for every user is calculated in
an iterative process, as well as Downlink transmission power for every cell.
The iterations continue by incrementing the corresponding quantity, until the
convergence is met. In the case of the Uplink transmission power, the
convergence for the uplink transmission power for a user is met when:
40
Abs (SIRUL,i – SIRUL target) / SIRUL target < convergence_threshold ( 4-1)
Where:
• SIRUL,I = level of the SIR at the iteration i
• SIRUL target = predefined SIR target
• Convergence threshold: Denotes the maximally tolerated deviation of

consecutive results within a snapshot, thus it defines the criterion
when to stop the iterative process within the snapshot. It is a
simulation input parameter, and it has values between [0.1, 100.0]
[Winessnapshot]. Smaller values require more iterations but are also
more accurate. It must be mentioned that besides the Dynamic mode,
Wines Control Center also includes an Static Simulator which the user
can select.
The problem with the static approach is that the snapshots are not connected
along a time line, so it is not possible to reproduce accurately the status of
the network as it evolves over time when a certain traffic load is offered to
the network and when the RRM algorithms are working with very complex
interactions among them in order to maintain the pre-defined quality targets.
However, the degree of abstraction in the Static Simulations is still enough to

allow for meaningful statistical evaluations of the network KPIs
[Winessnapshot]. In fact, this is the method currently used for initial
dimensioning for large networks (more than 100 sites) because it is much
more efficient (in terms of time and computational resources) than the
current Dynamic Simulators in those scenarios because of the simplified
modeling approach.
The Dynamic simulator, on the other hand, is a tool that is able to track the
network status as it evolves over time. The status at a certain point in time is
the accumulated result of the entire simulation run until that point
[Winessnapshot]. This goes in line with the Dynamic Nature of the UMTS
RAN. As it is mentioned in [Ramsden], a Dynamic system is the one where
the outputs are a function of both the present values of the input and
internal state variables, which are themselves functions of historical data, as
is the case of the real UTRAN and its RRM algorithms.
Therefore, a Dynamic simulator is an ideal tool for:
-) Design and Test of RRM algorithms
-) RRM parameter optimization, specially those based on time (e.g. handover

timers), which is not possible with Static Simulation because the lack of the
time reference of that approach
-) Detailed Capacity, Coverage and Quality Analysis
41
Troubleshooting of concrete problem Areas
-) Tests of the capacity-coverage tradeoff with different service mixes and

with different user profiles
-) Analyze packet data throughput
Wines is a Dynamic Simulator that models all the radio-resource

management functionality of the UTRAN, such as
• Admission control
• Congestion control
• Power control
• Soft Handover
• Channel Switching (from common to dedicated channels and vice
versa (e.g. from DCH to FACH and vice versa), and also up and down
switching as a result of admission control and congestion control
orders)
In the dynamic simulator, the users are making calls (according to the so-
called “service arrival” processes) and transmitting data according to the
traffic models (data unit arrival processes). In Wines, the call-generation
process for real-time services (e.g. speech, video) follows a Poisson process
and other probabilistic process are applied over the non-real time services
(FTP, WWW, they are called non-real time since they doesn’t have a
maximum defined delay).
In Dynamic simulators, there are also mobility models (e.g. pedestrian,

vehicular) characterized by a certain movement model (static, straight
movement, targeted movement) and speed with a certain distribution, to
represent a complete dynamic user behavior.
The spatial distribution of the initial user positions is weighted with the traffic
density values of the Traffic Matrix pixels. Consequently, the user distribution
is, for example, uniform if the Traffic Matrix is uniform and covers the entire
simulation area.
The disadvantage of the dynamic approach is that it requires high

computational resources due to the complexity of the necessary algorithms
and therefore the time required to perform dynamic simulations is
considerably higher, which means that for networks with several hundreds or
thousands of sites, the Dynamic Simulation is not the best approach. A nice
summary of the characteristics of the static and dynamic approach can be
found on the section 2.2. of [Holmathesis].
42
4.2 The Level of Detail of the simulation: System level
vs. Link Level
Generally speaking, when we are Simulating Radio Networks we find two

different level of detail: Link Level and System Level simulation. This is
because a single simulator approach, which would model everything from
transmitted waves to the dynamics of a multi-cell network would be too
complex. Therefore, for the detailed simulation that requires accurate
modeling of one receiver performance at chip level or symbol level
(resolution = 1/3.84 Mchips = 260 nsec), a Link Level Simulator is used. The
link level simulation includes a single mobile station connected to
one or a few Node Bs, and its aim is to be able to predict the user’s
receiver FER/BER performance, taking into account the physical layer process
(channel estimation, interleaving and decoding). Its typical elements are
transmitter, fading channel and a receiver.
On the other hand, when we need to simulate a large number of mobiles

and base stations (as it is the case for this project), a more efficient
approach should be used, otherwise the simulation time would be too high:
this is the aim of the System Level Simulators. System Level Simulators
model in detail the interference situation generated by users moving around
an area, with different mobility profiles, different services and different data
arrival process (traffic models) per service. As modeling such kind of complex
scenario would be very time consuming using a resolution of a chip, normally
the System Level Simulations operate with the resolution of the Power
Control Algorithm (which is the feature that change most often at this level of
detail), which is 1500 times per second. As the power control is done every
slot, the resolution time in this case is 10 msec (time of the frame) / 15
(slots per frame) = 666.66 µsec. Even simulating the state of the system
every slot, the time required is still somewhat high, so in practice, some
Dynamic Simulators (as in the case of Wines) work with a resolution time of
1 frame (10 msec).
4.3 Discrete Event Simulation vs. Continuous Time

Simulation
Wines is also characterized for the usage of a discrete-state model of the

RAN (its state variables (e.g. Number of users in the system at a given
moment, blocked users, dropped users) are discrete), therefore is defined as
Discrete Event Simulator. Of course, there are variables as throughput that
theoretically should be defined as continuous because in “real” life they are
(in theory, the throughput could be something like 283,51 Kbps or
283,50999), but as far as the simulator concerns they change internally in
discrete steps, therefore they are also considered discrete state variables.
43
This is opposite of continuous-event simulations, in which the state of the

system takes continuous values [Jain]. In a discrete event simulation, the
simulator schedule events to occur at particular times in the future. The
simulator looks at the “list” of pending events and decides which one is the
next event. Once the event is chosen, the simulator advances its simulation
time to the next event, executes it and schedule the next event, and so on.
We can see then that in this type of simulations, the simulator’s clock
advances in irregular fashion, depending on the order of occurring events, in
contrast with continuous-event simulations, where the simulator clock is
advanced by an small, discrete change, and an update of the simulation
mode’s state occurs only when the simulation time advances by this discrete
change. Continuous-event simulations are useful for instance when a set of
equations is tried to be solved numerically by a computer.
Wines Workflow
Having introduced the required concepts, we can describe now Wines as a

Dynamic –System Level – Discrete Event Radio Network Simulator. The
workflow that one normally follows to make a Radio Network study using
Wines Dynamic simulator is as follows:
1) Define the area which is going to be simulated. This is normally

done exporting the Network layout (Node Bs, Antennas and cells),
path loss predictions, environment definition (clutter data, Digital
Elevation Maps) and Traffic Matrices from a Radio Planning Tool
Project. The concrete process to export a Project from Fork’s ATOLL to
Radioplan Wines is described in the Appendix 2 of this Thesis.
2) Configure the Environment (Clutter, Streets, DEM), Users
(Equipment Profiles, Mobility Profiles, Service Profiles and User
Profiles), and UTRAN (including Antennas, RNC, Node B’s and cells).
3) Run the corresponding simulation(s) and store the results in the
program’s data base and the defined simulation folders.
4) Perform the Analysis with the Tools that Wines provides, or
alternatively use a spreadsheet and/or database to make some
specialized analysis with the results of step 3.
The following Figure illustrates these 4 steps.
44
ATOLL
Configuration
Analysis
WiNeS-WCC
Workflow
WiNeS-WCC
Simulation
Figure 4: Wines Workflow [Schneider]
4.4 Wines Main Features
Wines (an abbreviation for Wireless Network Simulator) is a tool that covers
a model of the radio network layout and its environment.
For the analysis of a UMTS Terrestrial Radio Access Network (UTRAN), the
radio network layout is represented by the Radio Network Controller (RNC)
and the locations of the Node Bs and their antennas and corresponding cell
configurations. It is assumed that all Node Bs
are controlled by one and the same RNC. The radio network model supports
multiple services.
The environment of the radio network layout is characterized by the clutter

(or morphology), i.e. whether the area is covered by buildings, forests, lakes,
etc., including streets and by the resulting propagation characteristics
[Winesuserguide]. The following Figure illustrates the configuration Tab for
both Environment and Network layout (UTRAN).
45
Figure 5: Wines' configuration tab [Winesuserguide]
In Wines, the system level model also incorporates a link level model in order
to determine the performance measures based on the interference analysis.
However, instead of simulating at link level, a link level interface defines
rules for mapping the interference statistics to bit or block error probabilities
with respect to the relevant environment and receiver characteristics
[Winesuserguide].
4.4.1 Dynamic User Traffic Modeling
Dynamic user traffic modeling can be distinguished into three levels:
4.4.1.1 1st level: The Network Element Activation level
This level describes at what times the user switches his terminal equipment
on or off and includes both active and idle periods. The basic time period is a
“switched-on”-period, equivalent for simulation purposes to the user’s
lifetime (for the simulator, the user is “alive” while he has his UE turned on
and using the corresponding service). This modeling level is characterized by
the arrival process of the mobiles at the time instants when they are
switched on. All the calls are assumed mobile originated, therefore there is
no simulation of the idle-mode behavior (idle mode behavior corresponds to
a User Equipment (UE) that is powered on, but does not have a connection to
the radio network and it is reachable by the system. In wines all the users
originate calls, but not receive them).
46
4.4.1.2 2d level: The Service (or Session) level
This level describes at what times the user requests certain services while
the terminal equipment is switched on. The basic period is a service session
(active mode period).This modeling level is characterized by the arrival
process of service requests. A user is assumed to use only one kind of
service at a time. In case of a multi-service user, this has to be modeled as
two or more users (depending on the number of multiple services) making
use of these services at a time.
As idle mode operation is out of scope of Wines and the active time
corresponds basically to the session time (because at the moment of the
activation the user immediately request a service, and when the user ends
the service it also corresponds to the user de-activation or the UE turned
“off”) the Network Activation and the Service level of the user traffic are
jointly modeled, and this joint process is denoted in the Wines
documentation as the service arrival process.
4.4.1.3 3d level: The Data Unit level (Traffic Model level)
This level describes the characteristics of the data transmission while the
service is active. The basic period is a data unit (e.g. a packet). This
modeling level is characterized by the arrival process of data units (or
packets). The simulator includes pre-defined Traffic Models, which the user
can parameterize.
Summarizing, the particularities (assumptions) of Wines regarding the user

dynamic modeling are:
• All the calls are mobile originated

• Each user request a single service
• Multiple services are modeled by multiple users of different types
4.4.2 The Service Arrival (Activation +Service) process and the

initial arrival (transient) process
Wines generally models the Service Arrival process as a Poisson arrival

process (negative exponential distribution of the inter arrival times and,
therefore, a Poisson distribution of the number of arrivals per time unit).
Therefore, the inter arrival time of the Poisson Service Arrival Process in
Wines models the time difference between the activation of two subsequent
users with the same UE Profile [Winestechref].
Additionally to this process (which is used throughout all the steady-state of

the simulation), a continuous service arrival process is implicitly applied at
the beginning of the simulation to more quickly reach the expected steady-
47
state service load. This process is loaded automatically and it last

approximately a number of frames equal to the expected number of users in
the network, and it should be removed from the simulations in order to get
just the results in steady-state.
4.4.3 The UE profile
A UE type describes a type of user including his terminal equipment, traffic,

and movement characteristics and is defined by the UE Profile, which has to
be configured before starting any simulation. The UE profile summarizes the
compound properties of a user’s behavior. Wines models each UE type by
means of an independent Poisson process.
A UE Profile is composed of an Equipment Profile, a Mobility Profile, and a

Service Profile, as illustrated in the following Figure.
Figure 6: User Profile generation in Wines
Therefore, the UE profile is a “template” that is used in the simulations to

create consecutive users of the same UE type. Each UE profile is associated
to one and only one Service, Equipment and Mobility profile, but one service
profile can be used by two or more UE Profiles (for example, for defining two
types of users of the same service, one could define a UE profile for the
Indoor users and another UE profile for the Outdoor ones). The equipment
and mobility profiles can be defined from scratch (providing input for the
required power (min and max) levels, the speed distribution, mean speed,
type of movement) or using one of the predefined templates. The following
Figure illustrates the configuration dialog of a UE Profile.
48
Figure 7: Wines UE Profile configuration
4.4.4 The Service Profile
The service profile is the other element regarding the user configuration
that needs to be carefully parameterized, because it contains information
about the service arrival process and the traffic model, the assigned radio
bearer, and some physical layer parameters. The components of a service
profile and their influence on the user/network behavior are shown in the
Figure [Winesuserguide]
Figure 8: Service Profile components and their influence in user's behavior
The mapping of each one of the QoS classes defined by the 3gPP
(conversational/speech, conversational/unknown, streaming,
49
Interactive/Background) can be done selecting in Wines the different

switching modes (circuit switched vs. packet switched), RLC Modes
(Transparent, Acknowledged, Unacknowledged), Transport Channel(s) (DCH,
HSDPA, RACH), and the corresponding Traffic Model (from the ones
implemented in the simulator).
TRIPS (Typical Radio Interface Parameter Settings) define sets of possible

parameter settings for different UTRAN protocol layers. These sets represent
typical adjustments for a large variety of services, and in Wines these values
are based on the recommendation 3GPP 34.108. In the Service Profile
context, TRIPS define the service parameter allowed combinations that can
be selected from the Service Profile configuration window.
About the traffic matrices, these can be defined in Wines or imported from
existing matrices coming from other radio-planning Tools. In this study, for
the first scenario (homogeneously distributed traffic densities, i.e. the same
traffic density for the whole simulation area) the matrix was defined in Wines
itself. For the second part of the study (non-homogeneously distributed
traffic, which means that the traffic density is not the same over the whole
simulation area), a Traffic Map based on clutter data was generated in ATOLL
and exported to Wines. The next Figure illustrates the Service Profile
configuration window.
Figure 9: Service Profile configuration window
50
In the next section, a short introduction to the built-in Traffic models is
explained. The complete description of these models, together with all their
parameters, can be found on [Winestechref].
4.4.5 The data unit arrival process (“Traffic Models”)
All services modeled in Wines are supported by a dynamic model for the
arrival of data units on both link directions (UL/DL), where applicable. “Traffic
Model” is used as a synonym for this data unit arrival process in Wines.
Basically, we can distinguish between two categories of Traffic Models:
Interactive and Non-interactive.
4.4.5.1 Non- Interactive Traffic Models
Non-interactive models are the models where UL and DL can be considered

independent, i.e. it is possible to model each transmission direction with one
data arrival model which is independent from the traffic model in the other
transmission direction. These models are used in the simulator to represent
the data arrival process of a speech service. For instance, the Speech Service
is modeled in Wines with a symmetric non-Interactive Voice Activity Model
(the same model in both transmission directions but working independently).
The Voice-activity feature means that the activity of the codec is modeled
when it monitors the data transmission to reduce or interrupt it during silent
voice periods.
As a speech connection is a conversation of two users, actually two voice

activity models are applied per connection, one for each link direction. The
voice activity (per link direction) is modeled by a 2-state Markov chain. The
two states represent a period of active voice (so-called talk spurt) and a
period of silent voice (break between two consecutive talk spurts),
respectively. The Non-interactive Voce-activity model for Uplink direction
(the one for Downlink direction is completely identical but totally independent
from this) is shown in the next Figure.
tactive
active silent
tsilent
Figure 10: Non-interactive Voice Activity factor, UL direction
51
In order to parameterize this model in Wines, the Voice Activity Factor is

defined as:
Voice Activity Factor = tactive / (tactive+tsilent) ( 4-2)
This Voice Activity Factor and the mean holding time define the effective
mean service time for a voice call, which is the multiplication of the voice
activity factor and the mean holding time (specified as an explicit parameter
for CS services in the simulator).
4.4.5.2 Interactive traffic models
Those are the models where there is a (clear) interaction between UL and DL.
One example is the WWW service, where the user sends requests through
the UL direction and receives the responses in the DL direction. The Wines
model for interactive traffic models is an extension of [30.03]. This model is
illustrated in the next Figure and a further explanation is provided.
Figure 11: Wines' WWW traffic model
In Wines, it is assumed that a WWW browsing session is interactive and

consists of a sequence of packet requests by the user on the uplink (1) each
followed by a processing delay in the server (2) known as Server Response
time (configurable), and the so-called packet call (3) (data sent from the
RNC to the UE) on the downlink. A packet call corresponds to the
downloading of a WWW document. During a packet call, several packets, also
52
called datagrams, may be generated leading to a bursty sequence of packets
[Winestechref].
After the document has entirely arrived to the terminal, the user consumes a
certain amount of time for studying it, called the reading time (4). At the end
of the reading time the user may request the next WWW document (5).
Each event in the system (request arrivals, packet call arrivals, etc) it is
characterized by its own probability distribution and its main parameter (the
mean) is configurable. The summary of distributions used for the concrete
case of the WWW traffic model is shown in the next table. For details, refer
to the [Winestechref]
Parameter Distribution
Mean UL datagram size Negative exponential

[byte]
Mean number of packet Geometric

call requests / user
Mean reading time [s] Geometric
Mean DL datagram count geometric
Mean DL datagram inter geometric

arrival time [s]
Mean DL Datagram Size Pareto with cut-off

[byte]
Server response time constant
Table 1: Parameters and Probability distribution for the Wines' WWW Traffic Model
The corresponding window where these values can be configured in Wines is

shown in the Figure below.
53
Figure 12: Wines WWW traffic model parameters configuration window
The parameterization of the (different) traffic models for the defined services
of this study (WWW, FTP, Video-call, Speech and Mobile TV) was an activity
done in close cooperation with France SFR and it is shown in the appendix 3
(Traffic Models parameters).
Also the parameterization of the System Parameters was done in cooperation

with SFR. The assumptions regarding the propagation conditions are
explained in the next two chapters (for each corresponding scenario:
homogeneously and non-homogeneously distributed traffic), as well as the
other system parameters, which mostly were mapped from the real-settings
of the Vodafone UMTS network to try to reflect as close as possible the
configuration of RNCs and Node B’s of the company. These parameters
appear in the appendix 4 (confidential: system parameters).
54
Static simulation vs. Dynamic simulation
Static simulations don’t have a time reference and therefore are not suitable
to simulate algorithms that have a strong dependence of time (like RRM
algorithms). However, the degree of abstraction in the Static Simulations is
still enough to allow for meaningful statistical evaluations of the network
KPIs. In fact, this is the method currently used for initial dimensioning for
large networks because they are more efficient in terms of time required to
complete a simulation (given its more simplistic modeling approach).
The Dynamic simulator, on the other hand, is a tool that is able to track the
network status as it evolves over time. Dynamic simulator is therefore an
ideal tool for:
-) Design and Test of RRM algorithms
-) RRM parameter optimization, specially those based on time (e.g. handover

timers), which is not possible with Static Simulation because the lack of the
time reference of that approach
-) Detailed Capacity, Coverage and Quality Analysis of specific areas
-) Tests of the capacity-coverage tradeoff with different service mixes and

with different user profiles
-) Analyze packet data throughput
The disadvantage of the dynamic approach is that requires high

computational resources due to the complexity of the necessary algorithms
and therefore the time required to perform dynamic simulations is
considerably higher, which means that for networks with several hundreds or
thousands of sites, the Dynamic Simulation is not the best approach at the
present time.
55
5. Description of the First

Simulation Scenario and
General Setup of the Simulation
Experiments
This chapter describes the Radio Network Layout and Environment chosen for
the 1st simulation scenario, including the assumptions made for the defined
services, the traffic mix of the services and the assumed traffic distribution
matrices. It also includes the simulation plan, which describes what has to be
done in each of the proposed experiments per each scenario. The complete
list with all the configured system parameters and traffic model parameters is
given in the confidential annexes [system parameters] and [traffic model
parameters] respectively.
5.1 Simulation and Analysis areas
Figure 13: First Simulation Scenario, simulation (red) and analysis (yellow) area
56
The Figure above illustrates the first Simulation Scenario. The Network
Layout (including RNC, Node B’s, Antennas) as well as the path-loss
prediction was imported from a Project created in ATOLL radio planning Tool,
and it is based on a real scenario (it is an area taken from the radio planning
map of the city of Bordeaux, France). This scenario was selected because it
was defined as the Base for common capacity dimensioning studies between
the branches of Vodafone in different countries, including The Netherlands.
The network layout itself consists on:
-) 7 node Bs in the Analysis Area (with 3 cells each one = 21 cells)

-) 19 node Bs in total in the simulation Area.
-) Inter-site distance = 900 meters
The Simulation Area represents the area in where the users are created
and once created they are moving in. This Area is represented in the Figure
13 with red borders and has an area of 12 Km2.
The Analysis Area, which is the area where data is collected, is shown in
the Figure 13 with yellow borders. It has an area of 5 Km2.
5.2 Environment Assumptions
The main assumptions for this first scenario are a flat landscape (No Digital
Elevation Model is used) and the Homogeneously-distributed traffic for
each of the defined services, therefore no clutter definition and neither traffic
maps based on clutter data were used for this scenario.
This assumption results in identical sites per simulation area, and given the
symmetry in the geometrical distribution of the nodes regarding their inter-
site distances, each one may be considered a “prototype” site at the initial
dimensioning stage, as it is correctly mentioned in [Jaber].
Another consequence of the assumption is that as the model is considered to

be flat, it doesn’t make sense then to include the shadowing model (i.e. the
fading in the signal caused by the varying nature of particular obstructions
between Node Bs and UEs, particularly tall buildings or dense woods). This
phenomenon is well described in [anntena-saunders] and it has more
importance in the coverage studies (because it affects directly the path-loss).
The difference in performance terms between this symmetric and

homogeneously distributed scenario and another more “realistic scenario”
(i.e. scenario including clutter, DEM and traffic matrices based on clutter
data) is going to be studied further in chapter 9 of this thesis.
57
5.3 Defined Services and Traffic Mix
In Wines simulator, several services can be created based on the defined

radio bearers in the TRIPS settings (as it was described in the previous
chapter).
For the purpose of this study, five services were defined because they
correspond with the current UMTS services offered by Vodafone, although
only four of them were considered in the study. The defined services were:
-) Speech: circuit-switched symmetrical service (12.2 Kbps UL/DL)
-) FTP: packet switched asymmetrical service (64 Kbps UL/384 Kbps DL)
-) Web: packet switched asymmetrical service (64 Kbps UL/384 Kbps DL)
-) Video-call: circuit-switched symmetrical service (64 Kbps UL/DL)
-) Mobile TV: circuit-switched symmetrical service (64 Kbps UL/DL)
The traffic mix, i.e. the percentage of usage of each service relative to the
total usage of services, was defined as it is shown in the following Figure.
This traffic mix was based on internal discussions within members of
Vodafone in different countries and it is assumed to approximately reflect the
current service mix (year 2005). As the users are becoming familiar with the
new Data Services, this traffic mix is expected to change, as it is mentioned
in [umts-forum6].
Traffic Mix [% ]
Service percentage
3,00
0,00
Voice 77,00% 12,50
Video-
call 7,50% 7,50 Voice
Video calls
Web 12,50% www
ftp
Ftp 3,00% Mobile Tv
MobileTv 0.00%
77,00
Figure 14: Traffic Mix assumption
58
Additionally, within each service, 2 kinds of users were assumed:
• Indoor Users (with an additional penetration loss of 18 dBs).

• Outdoor users.
The Indoor Users were defined as the 2/3 (66.7%) of the total of users of the
corresponding service, and the Outdoor users were defined as the remaining
1/3 (33.3%). This was conveniently modeled in Wines defining two different
User Terminals per each service (each one with different additional losses)
and the different service portion (i.e. the corresponding 2/3 and 1/3) was
modeled by creating two UE Profiles (indoor, outdoor) per each one of the
defined services.
About mobility types, all simulations were performed with pedestrian mobility
type, except in the specific experiments dealing with the differences between
the two mobility types pedestrian-vehicular (the experiments are specified in
the simulation plan to be presented also in this chapter), a vehicular mobility
type was applied to the Outdoor users.
5.4 Service Configuration
Continuing with the Service Configuration, each service has to be defined in

terms of the following data:
5.4.1 Radio Bearer Properties
The Radio Bearer is the service provided by the RLC for the transfer of user
data between the UE and the UTRAN [21.905]. The Radio Bearer contains
RLC parameters, MAC parameters, Transport Format Set(s) (TFS), physical
channel parameters, and the information bit rate. Upon reception of a service
request, the RNC performs a mapping of UMTS service parameters to Radio
Bearer parameters – called Radio Bearer Translation. According to the
specifications, a UMTS service may be mapped to a signaling Radio Bearer or
a combination of a (service-specific) Radio Bearer and a signaling Radio
Bearer [34.108].
As Wines is focused on the performance of the user data transmission, it is

dominated by modeling the non-signaling Radio Bearers which carry the user
data. Nevertheless, signaling Radio Bearers associated with user data
transmission are considered, e.g., for resource allocation. The non-signaling
Radio Bearer configurations required to support the UMTS services are
provided in the Trip Settings.
59
Among the radio bearer properties, these have to be defined in the Service
configuration Tab:
• The switching type: either circuit or packet switched

• The Transport Channel and the Maximum Data Rate (UL/DL): these
have to be selected from the list of the Service Configuration Dialog.
This list is based on the values defined on the TRIPS which can be also
modified by the user of the simulator.
• The RLC Mode (Transparent, Acknowledged, Unacknowledged). For
circuit-switched services, the transparent mode it is the only possible
mode. This mode means that the system accepts the information
coming from the transmitter and delivers it to the receiver in an
unchanged form. For packet-switched services, Transparent,
Acknowledged or unacknowledged mode are available.
5.4.2 Signal to Interference Ratio
• Initial Target Eb/N0 UL: The target Eb/N0 value in uplink for the
respective service. This value is used as target for the inner loop
Power Control as long as no outer loop Power Control is applied.
• Initial Target Eb/No DL: The target Eb/No value in uplink for the
respective service.
The values used for Downlink values for this study are based on a
measurement study performed by Vodafone UK [Moret] and appear in the
confidential appendix 3.
For the Uplink values, an adaptation from the appendix 3 was used.
The adaptation of values for Uplink had into account the following
characteristic of the UL and DL characteristics:
Target Eb/No Uplink < Target Eb/No Downlink (5-1)
This is given because the better reception techniques in the Node B (in
Uplink, Tx = mobile, Rx = Node B), and it is in line with the assumptions
presented in [Alcatel], [25.942] and Wines default values.
If the target values for UL and DL need to be given in terms of the target SIR
(as is the case of another Simulation Tools as Prismo), the target Eb/No can
easily converted into a corresponding target SIR according to the following
relationship:
SIR [dB] = Eb/N0 [dB] - 10 * log10(3840 / (spreading factor * user data
rate [kb/s])). (5-2)
60
5.4.3 Service Prioritization
This value determines the order how services are processed by the
Congestion Control and the Inter-Frequency Handover Control. This is a
value between 1 and 15 where 1 gives the highest priority. The default
service priority is 3. In this study the default value was used, in order to not
interfere with the admission and congestion control implemented in the
Ericsson P3 RRM algorithms.
5.4.4 Optional Semi-Dynamic Mode
This mode, applicable only to circuit-switched services, allows us to generate

a traffic load (service arrival process) where the users are not moving but
static. It is useful when one wants to test the soft capacity when an already-
known hard-capacity (e.g. voice users) is already present in the system. As it
is also a simplification of the interference modeling, it also helps to reduce
simulation times. In some simulations (as it is going to be explained in the
simulation plan), this mode was used.
5.4.5 Physical Layer parameters
Decoding Limit Offset UL[dB]: The Eb/N0 threshold for correct (i.e. error-
free) detection of signaling messages in uplink for the respective service,
given as an offset to the target Eb/N0. This value should be negative (in dB)
such that a received data packet that meets the target Eb/N0 condition is
detected correctly. The reference for this Decoding limit was the Capacity
Study performed in Vodafone Germany by Peter Schneider [Schneider-2]
Decoding Limit Offset DL[dB]: The Eb/N0 threshold for correct (i.e. error-
free) detection of signaling messages in downlink for the respective service.
This value should be negative (in dB) such that a received data packet that
meets the target Eb/N0 condition is detected correctly. The reference for this
Decoding limit was the Capacity Study performed in Vodafone Germany by
Peter Schneider [Schneider-2]
Both definitions are in line with the “satisfied user” definition presented in
[25.942] where a user is “satisfied” when the measured Eb/No of his
connection is higher than a value equal to Eb/No target – 0.5 dB. Otherwise,
if it is lower than this limit, the user is considered in outage.
Target BLER UL: It is the target BLER for the outer loop Power Control in
uplink. The value ranges between 0 and 1.
61
Target BLER DL: It is the target BLER for the outer loop Power Control in
Downlink. The value ranges between 0 and 1.
The target BLER levels in Downlink were based on the same document from
Vodafone UK [Moret] where the DL Eb/No levels were based. For the Uplink
direction the same values for Downlink were assumed.
5.4.6 Traffic Model parameters
The traffic model parameters were first defined according to the selection of
the corresponding traffic models implemented in Wines according to the
service. The following Table summarizes this first characterization step. A
complete description of each one of the traffic models is provided in
[Winestechref].
Service Wines Traffic Model
Speech Speech/video
Web WWW
FTP File
Video-call Speech/video
Mobile TV Speech/video
Table 2: Defined Services and Wines Traffic Models used
Once the corresponding traffic model was selected, its parameterization was
the outcome of discussions with colleagues in SFR (France). The agreed
values are presented in the corresponding appendix 3, together with the
description of the source taken to establish the value. Some of them were
based on existing measurements from the GPRS network.
One thing to mention here is the association that Wines makes between a
Service and ASE values which is slightly different than the definition of ASE
provided by Ericsson.
ASE (Air Speech Equivalent) is a measure of air-interface utilization relative

to the utilization of one Speech User (for instance, a connection using 3 ASEs
in DL generates the same interference level as the one generated by three
voice users). This definition is used by Ericsson within the Capacity
Management monitors (ASE UL/DL utilization); the ASE usage applies hard
62
limits to a cell’s and hence the network’s capacity. Technically, it is calculated
per radio link connection and defined according to [Ericsson-capacity] as:
ASErl = (max. rate DCH)/(max. rate DCH speech) * ( AF DCH )/(AF DCH speech ) (5-3)
Where:
• ASErl is the air interface speech equivalent for a radio link
• Max.rate DCH is the expected maximum DCH rate for the radio link
(DCH rate takes into account the overhead introduced by coding
techniques and it doesn’t corresponds directly to the information rate,
for the corresponding DCH Rate per Radio Link see appendix 3)
• Max.rate DCH Speech is the expected maximum DCH rate for a
speech radio link connection
• AFDCH is the activity factor of the considered DCH
• AFDCH,Speech is the activity factor of the voice service (assumed to be

0.67)
The ASE for a radio connection is the sum of the ASE of all services on the
radio connection. For example, the Speech radio connection consists of both
the speech service (ASE=1) and the Dedicated Control Channel (DCCH)
service (ASE=0.61), so the ASE for Speech becomes ASEspeech= 1 + 0.61 =
1.61.
The estimation of ASEs in the cell for monitoring purposes is performed as

follows:
ASEDL= Sum rl (ASErl Dl) ( 5-4)
ASEUL= Sum rl (ASErl UL/ nb radio links per RNC) (5-5)
Where:
• ASEDL is the air interface speech equivalent in downlink for the cell
• ASErl DL is the air interface speech equivalent in downlink for a radio
link
• ASEUL is the air interface speech equivalent in uplink for the cell
• ASErl ul is the air interface speech equivalent in uplink for a radio link
• nb radio links per RNC is the number of radio links within respective
RNC
The number of ASEs for a radio link per cell in uplink is divided by the
number of radio links involved in the connection. The principle is that the
average uplink interference a UE creates in the respective cell, is proportional
to the number of cells to which it is connected. This means that if a UE is
connected to two cells, it only requires approximately half the ASEs in each
cell, compared to using one cell.
63
This is something that it is not modeled in Wines as the number of ASEs is

associated to the Service, independent on the number of radio links (radio
bearers). For the next release of Wines, Radioplan is going to change this
approach by separating the service and the radio bearer control. This is going
also to allow to model correctly the “slow start” mechanism defined in
Ericsson, where the packet oriented connections start with the lowest-defined
radio bearers for those connections (e.g. 64 Kbps) and progressively acquire
better speed changing the bearer if and only if the radio conditions allow to
do that (i.e. if there is enough soft capacity). In the current version of the
simulator, the packet oriented connections still start asking for the highest
possible data rate (which is often 384 kbps). This leads to a very high
blocking rate for those bearers if the Ericsson parameter sf8Adm (which
defines the maximum number of connections using SF-8, i.e. connections of
384 Kbps) is defined very low. In order to not affecting the simulation
outcomes because of this non-realistic implementation, this parameter
sf8Adm has been configured to its maximum value (8) which means no
limitation, only the soft-capacity limit. Anyway, the results are going to be
somewhat pessimistic for this kind of high-speed packet services because the
mentioned Slow Start mechanism is not correctly implemented nowadays in
Wines Simulator.
5.4.7 Traffic Matrices
A traffic matrix is location-based data of traffic density values. Each Service

has a Traffic associated to it. The traffic density values are given in
Erlang/km2. The traffic matrix assigns a traffic density value to each “pixel”
or minimum area unit (area size configurable within the simulator).
The traffic values in the traffic matrices are used for several purposes
[WinesTechRef]:
• UE activation: New UEs are activated during a network simulation

according to the spatial distribution of the relative traffic values in the
traffic matrices. That is, UEs are created with higher probability at
positions with higher traffic values.
• Targeted movement: Users in a dynamic network simulation move
preferably along paths with higher traffic, if paths are defined (not in
this study). The relative traffic values in the traffic matrices are used
for this directly.
• Inter-arrival time of the service arrival process: The mean inter-
arrival time of UE activations for a certain service is calculated from
the given mean holding time (also known as the “service time”) of the
service and the total traffic density (given through the traffic matrix).
64
In Wines, a traffic matrix is defined per service and it can be either created
directly in the tool (as it was the case for the 1st simulation scenario) or can
be imported from a Radio Planning Tool (as it was in the case of the 2d
simulation scenario).
For the first simulation, each service was associated with a traffic matrix
homogeneously distributed over the whole simulation area. The value of the
(mean) traffic densities were varied according to the simulation plan
explained in the next section.
5.5 General Network Layout Assumptions
In this section the summary of assumptions regarding different features

provided in the Simulator that have not been used for this simulation setup is
given. Due to shortage in space, the work performed matching the
parameters in Ericsson Domain with the corresponding ones in the Wines
Domain is not shown here, however the complete parameterization is
provided as the confidential annex [System Parameters].
5.5.1 RNC assumptions
• No neighbor list support, which means that every Site is potentially a

neighbor for the other ones.
• No Power Balancing (Power Drift prevention). Power drift prevention
ensures that the ratio between the downlink power of each radio link
and the corresponding PCPICH power is the same for every cell in the
active set. It is an algorithm defined in [ericssonpowercontrol] that is
superimposed to the inner-loop power control and it used only when
handover connections are present.
• Transport Channel Switching :activated, from Common to Dedicated
and vice versa
• No HSDPA channel
• No DL Radio Link Failure Detection [Out of synchronization and cell
update procedure, defined in ([25.331])
5.5.2 Node B assumptions
• No DL capacity limited due to ASE (ASE DL =480. maximum = 500).

This was configured according to what was found in [Ericsson-
capacity]:
65
“In the downlink, the Downlink Transmitted Carrier Power is the main
monitor used to control the air interface load. ASEDlAdm is a complement to
the load control when:
• Hardware resources are the limiting resource
• The cell can support so many users that it is close to the pole
capacity, which can cause Instability.
Therefore, if the Downlink Transmitted Carrier Power is the limiting resource,

aseDlAdm can be set very high so it does not interfere with the control
strategy used for the Downlink Transmitted Carrier Power.”
As with the first (preliminary) simulations it was found that DL ASE utilization
was the main blocking reason and knowing that the expected reason was
Downlink Transmitted Carried Power, it was decided to follow the
recommendation of Ericsson and put the aseDlAdm parameter near its
maximum value (default value=240. configured value = 480. maximum
value = 500).
• Assumed Costs of RLS in terms of CE (DL, dedicated channels), per

SF: 16,8,4,2,1,1,1,1 (for SF 4,8,16,32,64,128,256,512).
5.5.3 Cell assumptions
• Number of available FACH = 1

• SF8Adm =8, SF16Adm=16, SF32Adm=32 (Absolute admission limit on
the number of radio links with SF 8, 16 or 32 respectively, applicable
to non guaranteed (i.e. interactive/background services) access
requests.
5.6 Defined KPI’s (Key Performance Indicators)
The Key Performance Indicators (in this document abbreviated as KPIs) are
the quantities to be measured whether to evaluate the resource utilization
per cell (e.g. DL power usage, UL Noise Rise, DL code tree usage, Channel
Elements usage) as to measure general performance of the UTRAN elements
(Blocking and Dropping Probabilities per RNS/ per cell in case of circuit-
switched connections, and for packet switched connections the throughput
and delay are better performance indicators). Wines Simulator presents a
whole gamma of KPIs to be selected, but to restrict our analysis to the most
important KPIs, the following KPIs have been selected depending on the
switching type of the Services:
66
5.6.1 KPIs for Circuit switched services (Voice, Video Tel):
• % of blocked calls
• % of dropped calls
• number of DL channel elements
• DL Iub capacity
• DL code tree usage
• DL power usage
• UL noise rise
5.6.2 KPIs for Packet switched services (WWW, FTP)
The same KPIs as in the case of circuit switched services were defined,
additionally the throughput per service was also considered.
5.6.3 Defined KPI Thresholds
The thresholds (i.e. the values that define the situation that starts to indicate
a bad network performance (e.g. excessive dropped or blocked calls) and
that for our study represent the operational point to determine the maximum
number of supported users given a certain traffic density and service/service
mix) have been taken after internal discussions with the Engineers of
Vodafone-IT Department. The following table summarizes them.
67
Reason /
KPI Threshold Value Source
The BLER level is defined per

Radio Bearer, as follows: CS 64
BLER Target (UL/DL, in case of
our Simulations this corresponds
to Video-call service), Speech
and all the other bearers
% of % of Blocked calls (PS64/384, in our simulations
Blocked at a given BLER correspond to Voice Service, FTP
calls level and Web Service) Ericsson
The BLER level is defined per

Radio Bearer, as follows: CS 64
BLER Target (UL/DL, in case of
our Simulations this corresponds
to Video-call service), Speech
and all the other bearers
% of % of Dropped calls (PS64/384, in our simulations
Dropped at a given BLER correspond to Voice Service, FTP
calls level and Web Service) Ericsson
Pool of maximum
available CEs in UL
and DL (not shared
among directions)
per each Node B,
we assume
congestion (in UL or
DL DL) if these limits Vodafone
Channel are passed in UL number of CE UL / number of CE Hardware
Elements and DL respectively DL Department
Table 3:(1/4): KPI definition
68
KPI
Reason /
definition Threshold Value Source
For the Downlink

Channelization Code
Admission Policy:
Percentage of DL Code
Tree used, given per cell
The main monitor is the [%].
Downlink Channelization
Code Admission Policy.
There is blocking for non-
handover requests (i.e. new
users) in order to reserve
some codes for users in The percentage of codes
handover which are not in use is calculated as
blocked. The soft congestion follows: Sum [all-user]
mechanism is triggered when (1/SF[user]) + Sum [all-
non-guaranteed service CCH] (1/SF[CCH])
requests are blocked, This
value is equal to dlCodeAdm
- beMarginDLCode (See
Figure). Additionaly, there is SF[user] is the SF of the
the histogram admission User, SF[CCH] is the SF
policy, which controls when of the common control
non-guaranteed (handover channel.
DL Code Usage and non-handover) admission
(No second code requests demanding
tree used for spreading factor 8, 16 or 32
simulations): are blocked if the usage of For the Histogram
percentage of DL this spreading factor exceeds Admission Policy =
Code Usage before sf8Adm, sf16Adm and sf32 number of admission
triggering soft Adm respectively. Defined requests demanding a
congestion counters: given spreading factor
mechanism sf8Adm,sf16Adm,sf32Adm. [8,16,32] Ericsson
Ericsson detects this

measuring Received Total
UL Congestion: Wideband Power in UL,
RTWP measured congestion is detected when
level more than a RTWP exceeds
given threshold for iFcong+iFOffset during a time
a given amonut of longer than iFHyst, see the Power level [dBm] per
time corresponding Figure cell within a time interval. Ericsson.
Table 3 (2/4): KPI definition
69
KPI
Definition Threshold Unit Reason / Source
DL Power Ericsson’s indicator

Usage: of Downlink
Congestion in congestion,
DL when DL congestion in DL
transmitted detected when DL
power exceeds power exceeds
a certain pwrAdm+pwrAdmO
configurable ffset+pwrOffset
threshold for a during a time
longer time longer than
than the pwrHyst, see Power level [dBm] per cell
hysteresis time. Figure within a time interval. Ericsson.
Throughput
(perceived by
the user):
minimum
acceptable
throughput,
values below
this level Vodafone Internal
indicate a bad Vodafone Internal Average throughput per Marketing
performance Target service [Kbps] Document
70
KPI
Definition Threshold Unit Reason / Source
Required inputs from Wines:

Number of users of SF=8,
SF=16 and SF=32 at a given
time. The % of Iub reserved
bandwidth can be calculated
using the internal VF-NL
formula given by Greg
Vourekas in [Iub observability]:
% of Iub reserved BW = 100 *
(reserved capacity/available
capacity) where reserved
capacity [cells/sec] =
NusersSF8*PCRSF8+NusersS
F16*PCR16+NusersSF32*PCR
32 (PCR=peak cell rate per
each spreading factor, see
table of PCR per spreading
factors) and available capacity
[cells/sec] = Num_E1s *
PCR_E1 - PCRcommon and
signalling channels
*Num_sectors_per_NodeB. To
measure this in wines, we can
take advantage of the
information provided in the
RRM.AdmissionControl.Cell.Co
detree, parameter
DL_UsedCodes - SF [Num],
which indicates, per cell, The
number of channelization codes
of a given spreading factor
currently used from the Cells
code tree, therefore as all the
sites have 3 cells, the number
of users per spreading factor
would be DL_UsedCodes -
SF8/64, DL_UsedCodes -
SF16/32,
DL_UsedCodesSF32/16 and
the calculation has to be added
% of Iub reserved among the three cells of the
DL Iub capacity bandwidth Node B. [Iub-observability]
71
5.7 General Simulation Settings
• Simulation Mode selected: Dynamic Simulator. Wines has also the

option of static (Monte Carlo) simulations, but for the purpose of this
study, all the performed simulations were Dynamic.
• Stop Time: The number of UMTS frames to be simulated. The number

of frames is a compromise between the simulation run time and how
significant could be the data obtained. Generally the recommendation
is the more, the better, but also taking into account that it is going to
take longer to simulate more frames. The lower boundary is that
simulation times shouldn’t be shorter than any of the defined service
times. For this study, all the simulations were performed with 50.000
frames which corresponds to 500 seconds or 8.33 minutes (compare
for instance with the 60 seconds of service time taking into account
voice activity factor). After internal discussions it was found that it was
a good compromise between the significance of the measurement
interval and the simulation time.
• Default Code Orthogonality Factor alpha (αc): This is a factor that

takes into account that WCDMA employs orthogonal codes in the
downlink to separate users, and without any multi path propagation
the orthogonality remains when the base station signal is received by
the mobile. However, if there is multi path in the radio channel, the
mobile will see part of the base station signal as multiple access
interference and then the “loss” of perfect orthogonality is expressed
as a fraction of the original (perfect) orthogonality at the node B. αc is
defined as the default intra-cell orthogonality factor between OVSF
codes under the same scrambling code. It is a value between 0 and 1,
where 0 in Wines means full orthogonality (no interference) and 1
means full interference (no orthogonality). For the simulations, a value
of 0.4 was agreed (0=full orthogonality, 1=no orthogonality).
• Default Inter-Scrambling-Code Orthogonality Factor (αsc): The

default intra-cell orthogonality factor αsc between OVSF codes under
different scrambling codes. As in this study different scrambling codes
per cell were not used, the value of this parameter is irrelevant for the
study purposes. Practical values for αc lie between 0.05 and 0.4 (with
decreasing code orthogonality), and between 0.7 and 0.9 for αsc.
5.8 Simulation Plan
The following section describes the simulation setup for each one of the 5
different experiments performed per each scenario (homogeneous and non
homogeneous). Also includes the description of the proposed Analysis of the
72
selected network parameter. It must be mentioned that due to the high
number of performed simulations and the time required to collect and
analyze the results, no repetitions per each experiment have been performed
(i.e. there are no replications per each traffic density level) and therefore the
calculation of the confidence intervals (if required) for the Figures obtained is
left for a further study.
The base for all the experiments was defined in the following Table, where
the traffic densities are scaled regarding the service mix percentages and the
value of the density of the voice (main) service.
service % Erl Erl Erl Erl Erl

Voice 77 10.00 20.00 40.00 80.00 160.00
Video call 7.5 0.97 1.95 3.90 7.79 15.58
Www 12.5 1.62 3.25 6.49 12.99 25.97
Ftp 3 0.39 0.78 1.56 3.12 6.23
Mobile tv 0.00 0.00 0.00 0.00 0.00 0.00
Table 4: Defined Traffic Densities [Erl/Km^2]
5.8.1 Homogeneous Scenario
5.8.1.1 Figures per service
These Figures are calculated for 5 different traffic densities per service,
collecting the defined KPIs for the circuit switched services (Voice, Video Tel)
and for the Packet switched services (WWW, FTP). Therefore, the simulations
are performed according the rows of the Table 3, i.e. with 5 different traffic
densities (Erl/Km2) per each service. The main idea is to evaluate the
operational point for each service, given the defined thresholds.
The Total number of required simulations for this step is: Number of services
* 5 = 20 simulations.
5.8.1.2 Figures using the defined traffic mix percentages:
In order to test all possible combinations, we would need to test 5^4=625

possibilities. For this study, only the traffic densities defined in the “columns”
of the Table 3. Number of required simulations = 5.
5.8.1.3 Power-rule study
The purpose of this study is to check the effects (measured in performance

terms) of the two different rules applied to define the PCICH Power level in
Vodafone Netherlands and in Vodafone Germany. Theoretically, different
73
PCICH power levels per each cell can create unbalance in the network and
affect the size of the Handover Zones and the Pilot Polluted zones, so this
study is aimed to check which settings are better in terms of these two
indicators (distribution of the Handover Zones (i.e. active set size >1) and
distribution of the pilot polluted zones).
To define the PCICH Power, there are two possible Reference Points as it is
illustrated in the following Figure:
Figure 15: reference points for PCICH level
Wines defines its reference point for the PCICH as the reference point
number one, however the PCICH values provided by the Netherlands and
Germany are given in the Reference Point Number 2, so it means that one
has to take into account the Downlink Losses. The uplink losses are assumed
to be zero.
The rule applied in The Netherlands is:

If feeder loss <= 3 dBm then PCICH Power = 30 dBm (5-6)
If feeder loss > 3 dBm then PCICH Power = 33 dBm – Feeder loss (5-7)
And the rule applied in Germany is:

PCICH Power = 33 dBm – Feeder loss, for all feeder losses (5-8)
74
To test this feature, one has to create a simulation with different feeder
losses in the cells, calculate the PCICH power level that the cell would have
according to this rule and test the results for The Netherlands against the
same scenario but applying the rule of Vodafone Germany.
Number of required simulations = 2. The assumed traffic densities for both

simulations are as follows:
Voice Density Web density FTP density Video call density
40.00 6,49 1,56 3,90
Table 5: Assumed traffic densities (in Erlangs/Km2) for the two simulations of the Power rule
study
The setup for the homogeneous case is summarized in the following table.
assumed PCICH PCICH

path Power Power Wines CPICH
Site loss NL Germany settings GE Wines CPICH settings NL
PCICH Power = 33
dBm, cable loss DL = PCICH Power = 33 dBm,
9 4 dB 29 29 4 cable loss DL = 4
PCICH Power = 33
PCICH Power = 33
14 0 dB 30 33 0 cable loss DL = 3
PCICH Power = 33
10 0 dB 30 33 0 cable loss DL = 3
PCICH Power = 33
PCICH Power = 33
PCICH Power = 33
13 2 dB 30 31 2 cable loss DL = 3
Table 6: Assumed DL losses and PCICH Power for the Power Level experiments
75
5.8.1.4 Mobility Study
In this study, one has to create the same Figures per voice service (main
service) and per traffic mix of the third column of the Table 3, but now with a
vehicular mobility profile for the outdoor users. Then, one has to compare
the results with the pedestrian profile. Only Soft-handover type has been
activated so far. Number of required simulations: 5 (voice densities) + 1
(traffic mix of the third column)
Total number of simulations, Homogeneous Scenario = 33
5.8.2 Non-homogeneous Scenario
5.8.2.1 Figures per service
A non homogeneous traffic map has to be created, with maximum traffic

densities scaled according to the table 3. For this purpose, one has to test
separately each service with the 3 (maximum) traffic densities given by the
table 3. Number of required simulations: 12
5.8.2.2 Traffic Mix
Using the same traffic map, a replica of this map must be associated to each
service and the maximum traffic densities must be scaled according to the
“columns” of the table 3. Number of required simulations: 5
5.8.2.3 Power rule study
Study the power rule, analogous to 1.3. Number of required simulations:2.

The used traffic densities (together with the corresponding scaling factors
used) were as follows:
Voic Scaling We Scaling FT Scaling Video Scaling

e Factor b Factor P factor call Factor
40.0 0.506329114 6.49 0.082151899 1.5 0.019746835 3.90 0.049367089

Table 7: Assumed traffic densities and scaling factors for the power rule study, non homogeneous
scenario
The setup of the different power levels (regarding the same reference points
of the Figure 15) is shown in the table below.
76
PCICH
path Power WinesPCICH
loss PCICH Power Germany settings GE WinesPCICH
(from NL (Reference (Reference (Reference settings NL
Site ATOLL) 2) 2) 1) (Reference 2)
U000751 3 30 30 33 33
U000752 1.595 30 31.405 33 31.595
U000753 3.7 26.3 29.3 33 30
U000791 2.935 30 30.065 33 32.935
U000793 2.54 30 30.46 33 32.54
U000801 2.325 30 30.675 33 32.325
U000802 2.28 30 30.72 33 32.28
U000803 1.85 30 31.15 33 31.85
U009641 3.105 26,895 29.895 33 30
U009642 3.57 26,43 29.43 33 30
U009643 3.47 26,53 29.53 33 30
U009651 2.69 30 30.31 33 32.69
U009652 2.69 30 30.31 33 32.69
U009653 2.69 30 30.31 33 32.69
U011031 1.275 30 31.725 33 31.275
U011032 2.49 30 30.51 33 32.49
U011033 1.27 30 31.73 33 31.27
U011071 2.51 30 30.49 33 32.51
U011072 2.42 30 30.58 33 32.42
U011073 2.66 30 30.34 33 32.66
U011381 4 26 29 33 30
U011382 4 26 29 33 30
U011383 4 26 29 33 30
U014671 3.275 26.725 29.725 33 30
77
U014672 3.32 26.68 29.68 33 30
U014673 3.32 26.68 29.68 33 30
U020731 1.905 30 31.095 33 31.905
U020732 1.645 30 31.355 33 31.645
U020733 1.86 30 31.14 33 31.86
U030761 2.31 30 30.69 33 32.31
U030762 2.44 30 30.56 33 32.44
U030763 1.675 30 31.325 33 31.675
U030771 1.3 30 31.7 33 31.3
U030772 1 30 32 33 31
U030773 1.3 30 31.7 33 31.3
U030801 3.01 26.99 29.99 33 30
U030802 3 30 30 33 33
U030803 3.01 26.99 29.99 33 30
U030821 3.65 26.35 29.35 33 30
U030822 3.7 26.3 29.3 33 30
U030823 3.65 26.35 29.35 33 30
U030841 2 30 31 33 32
U030842 2 30 31 33 32
U030843 2 30 31 33 32
U030851 3.51 26,49 29.49 33 30
U030852 2.91 30 30.09 33 32.91
U030853 1.15 30 31.85 33 31.15
U032311 3.015 26.985 29.985 33 30
U032312 3.02 26.98 29.98 33 30
U032313 3.02 26,98 29,98 33 30
U035701 2.755 30 30.245 33 32.755
78
U035702 2.74 30 30.26 33 32.74
U035703 2.35 30 30.65 33 32.35
U046611 1.365 30 31.635 33 31.365
U046612 1.375 30 31.625 33 31.375
U046613 1.365 30 31.635 33 31.365
U051651 3 30 30 33 33
U051652 3 30 30 33 33
U051653 3 30 30 33 33
U052011 0.6 30 32.4 33 30.6
U052012 0.6 30 32.4 33 30.6
U052013 0.6 30 32.4 33 30.6

Table 8: CPICH and DL Losses for the power experiment, non homogeneous scenario
5.8.2.4 Mobility study
Study the different mobility profile, analogous to 1.4. Number of required

simulations: 6
Total number of simulations, non homogeneous Scenario = 25
5.8.3 Analysis of a specific network parameter
This is analysis was performed with one of the parameters that have not
been harmonized between Vodafone Global and Vodafone Netherlands.
Applying the technique of two-factor analysis in Jain’s book (the two factors
here are the traffic load and the parameter being tested), one has to test the
parameter with 5 (5 or less, i.e. in case that some of them are the same
value) possible values:
• Minimum value of the parameter
• Maximum value of the parameter
• Default Value (given by Ericsson)
• Value in The Netherlands
• Value in Vodafone Global
79
The 5 different levels of workload correspond to the 5 columns in the table 3.

The semi-dynamic mode will be used for voice users to speed up simulation
times (this mode means that the voice users are created according to the
specified traffic density matrix and they generate calls according to the traffic
models, but they are not really moving around the simulation scenario, each
one makes the call without moving and ends the service).
The parameter to be analyzed is Timetotrigger 1a, a timer used in the intra-

frequency handover for the handover algorithm. The required number of
experiments in this study parameter is: number of workloads * number of
levels of the parameter which would be 5*5= 25 simulations per analyzed
parameter.
80
The main results of this chapter are the definition of the main KPIs for
circuit-switched and packet-switched services, the target thresholds (defined
on Table 3), the characterization of the network and environment layout for
the homogeneous scenario, and the design of the simulation plan required to
make the analysis of the proposed studies.
81
6. Description of the Second

Simulation Scenario (non-
homogeneous)
The purpose of this chapter is to introduce the second scenario of the
simulation experiments, related to its main changes regarding the first
scenario. At the UTRAN configuration level, i.e. the configuration of the RNC,
Node B and cell elements (described in the appendix 4 is exactly the same as
the first scenario. Also the definition of the user profiles and service profiles
(except now for the traffic matrices that are non-homogeneous) has been
configured with the same Equipment Profiles, Mobility Profiles, Service
Profiles and UE profiles. Due to different regional settings on the machines
where the analysis was performed, through all the report both "," and “.””
have the same meaning (to separate decimals), and the number of decimals
used has no relation with the accuracy of the results.
6.1 Simulation Area and Analysis Area
Figure 16: Simulation (red) and Analysis (yellow) Area for the Second Scenario
82
For this second scenario, a non-homogeneous traffic distribution, no – flat
area (a Digital Elevation Model was used) was chosen. The traffic densities
were generated based on the Clutter information also available from the
Database of the Radio Planning Tool (ATOLL).
The simulation Area (area with red border in Figure 24) has an extension of
59.71 Km2, whereas the analysis area (area with yellow border in Figure 24)
has an extension of 34.75 Km2. The area corresponds with the active
transmitters (antennas) deployed in the downtown of the city of Maastricht.
The following image illustrates the selection of the computation zone
(equivalent to the simulation area in Wines) and the focus zone (equivalent
to the analysis area in wines) in ATOLL radio planning tool.
Figure 17: Selection of the computation and focus zone in ATOLL radio planning Tool
Regarding the number of Node B’s and cells, they reflect the number of
active transmitters in the selected area:
-) 21 Node Bs in the Simulation Area, all with 3 cells/Node B except for the
Site S00079.
-) 18 Node Bs in the Analysis Area, all with 3 cells/Node B except for the
Site S00079 (53 cells in total).
83
-) Due to the asymmetrical distribution of the network layout, inter-site

distances varies between 900 and 3000 meters.
The physical characteristics of the antennas (azimuth, mechanical down-tilt,

height, noise Figure, Transmission and Reception Losses) have been
imported directly from the Radio planning Tool as well.
6.2 Clutter Classes and DEM (Digital Elevation

Model)
The two main differences in the environment modeling, regarding the first
scenario, is the inclusion of the Clutter Information and the Digital Elevation
Model Information. That means that every clutter class can be parameterized
with different propagation conditions, which in wines include:
Fading Profile (4 options: RA (Rural Area), TU (Typical Urban suburban and

urban areas), BU (Bad Urban areas), HT (Hilly Terrain areas))
Intra-cell orthogonality factor (αc) considering three different speed

ranges (v<2 m/s, 2 m/s <v <15 m/s, v>15 m/s)
Intra-cell inter-scrambling orthogonality factor (αsc, for the cells with

more than one scrambling code, not applicable for this study) considering
three different speed ranges (v<2 m/s, 2 m/s <v <15 m/s, v>15 m/s).
The clutter map for this second scenario is shown in the next Figure.
Figure 18: Clutter Map for the second scenario
84
As this is a study target mostly at determining capacity Figures and the
purpose of the second scenario is to test the network regarding a non-
homogeneous traffic matrix, the clutter classes are used just for the purpose
of assigning different traffic densities to each of the clutter classes, not to
test the effect of different propagation conditions in each clutter-class.
Therefore, the clutter classes’ properties were all configured with the same
characteristics, as it is shown in the next Figure.
Figure 19: definition of the clutter classes properties in Wines for the 2d scenario
About the DEM, this is a map that represents the height of the terrain, so it
influences also mostly coverage issues, allowing to model in a more detailed
way phenomenon like multi-path propagation and shadowing (i.e. fading
caused by obstructing objects). The DEM used is the one defined in the
Database of the Radio planning Tool and it was imported also in Wines.
6.3 Non – homogeneous Traffic Map generation
In this section an overview of the process followed in the Radio Planning Tool
(ATOLL) to generate a non-homogeneous traffic map is presented. The
complete procedure is described in the appendix 2.
Traffic data can be represented in Atoll in different ways. For the purpose of
importing the traffic data into Wines, two options are supported:
85
• Environment traffic maps, where each pixel is associated with an

environment, which in ATOLL represents a certain service mix. Each
environment (e.g. Urban, Sub-urban, etc) has associated a list of
clutter classes and possible weights for each class, as it is going to be
explained later in this chapter.
• Cell traffic maps (based on transmitters and services), where the

best server coverage area of each transmitter is associated with
service-specific traffic values, which may additionally be subject to
clutter-based weighting factors.
The association of each environment code number (and color) with an

Environment (as defined in the Atoll UMTS Parameters) is defined in the
properties of the respective environment traffic map, e.g. as shown in the
next Figure:
Figure 20: Example Environment Codes definition in the Atoll Environment Traffic map
properties
This Environment codes definition must be saved in addition to each

environment traffic map in a separated *.mnu file per each environment
traffic map. This file simply contains the Environment code and the
associated Environment name separated by a blank or tabs. For example, the
corresponding *.mnu file for the Figure 28 Environment Definition would
contain the following list:
• 0 no data
• 1 Urban
• 2 Rural
86
The approach followed to create a non-homogeneous traffic Map is
summarized in the following list (again, details are provided in the appendix
2.
1. Select one of the Environments (so the traffic map would be based just
in that environment)
2. Assign weights to the clutter classes associated to this Environment,
for instance as it was done in the following Table:
Clutter class Weight % Indoor
Default 0 0
Suburban: <6m Garden 10 30
Suburban: <6m 10 30
Suburban: <6m Dense 10 30
Suburban: <9m Wooded 10 30
Suburban: 6-9m Garden 10 30
Suburban: 6-9m 10 30
Suburban: 6-9m Dense 10 30
Urban: 9-12m Open 15 50
Urban: 9-12m 15 50
Urban: 12-18m 15 50
Urban: 18-27m 15 50
Urban: 18-27m Dense 15 50
City: 27-40m Open 20 60
City: 27-40m 20 60
City: >40m 20 60
Table 9: Clutter weights definition example inside a given Environment
87
3. The combined weights, together with the area size of each clutter class
determine the final number of users per each pixel. The way it is calculated is
explained in the appendix 2.
As a result of the procedure, a non-homogeneous Traffic Map was generated,

which can be conveniently scaled up or down in Wines making use of the
parameter “scaling factor” associated to each Traffic Matrix. The next Figure
shows how this Traffic Map looks inside wines with Scaling Factor = 1 (i.e. no
scaling at all).
Figure 21: non-homogeneous Traffic Map in Wines
As it can be seen in the Figure, the maximum traffic density of this Map is 79
Erl/Km2. This can be scaled (down or up) to match with the defined traffic
densities in the Reference Table defined in the previous chapter.
For instance, to obtain a Maximum Traffic Density of 20 Erl/Km2, we have to

adjust the scaling factor as follows:
88
Required Max Traffic Density = Maximum Traffic Map Density * scaling factor
20 Erl/Km2 = 79 Erl/Km2 * scaling factor
Scaling factor = 20 / 79 = 0.2531
The following Figure shows the same Traffic Map after applying the scaling
factor of 0.2531.
Figure 22: Traffic Matrix after applying the scaling factor 0.2531
For the simulation experiments, each service (FTP, Voice, WWW, Video-call)
was assigned to the same non-homogeneous traffic map and its maximum
levels were varied according to Table 4 of the previous chapter making use of
the corresponding scaling factors.
89
6.4 Summary of Chapter 6
Connected to this chapter, the main findings are also in the appendix 2 which
describes how to generate a traffic map based on clutter data and how to
export it from ATOLL radio planning tool to Wines Dynamic simulator.
Once the traffic map is defined in the simulator, we can scale easily the
densities according to our simulation plan, knowing that:
Required Max Traffic Density = Maximum Traffic Map Density * scaling

factor
Where Maximum Traffic Map Density is defined in the Radio Planning Tool
and Scaling Factor is a parameter (from 0 to 1) defined in Wines to scale
traffic accordingly.
90
7. Simulation results first
Scenario (homogeneous)
The purpose of this chapter is to present the analysis of the simulation
results in the 1st simulation scenario described in chapter 5 and according to
the simulation plan already mentioned in that chapter.
7.1 Figures per service

The purpose of this section was to determine under which load conditions
(traffic densities expressed in Erlangs/Km2) the UTRAN reaches each one of
the capacity thresholds, making the analysis for each one of the proposed
services. The traffic densities were varied according to the table 4. To be able
to determine at which level the load in the network reaches a specific
capacity threshold, one software application, Curve Expert v1.3. (© Daniel
Hyams) was used. This software allows to analyze which is the best
mathematical interpolation fit given a dataset as the input, and with the
obtained mathematical fit, it allows to analyze what input level produces a
specific output level (x = f(y)). Several fits can be tried and they are ranked
in terms of “goodness” or “badness” of the fit. Two quantities are used to
express the "goodness" of a particular curve fit - the correlation coefficient
and the standard error of the estimate. The correlation coefficient has a
range from 0 to 1, with a correlation coefficient of 1 being the best fit, and
the standard error has a variable range, with a smaller standard error
(smaller regarding the Y’s or obtained values of the dataset) representing the
better curve fit. Explanations about how these two indicators are
mathematically defined can be found in [curveexperthelp]. The following
Figures present the main screens of the software.
91
Figure 23: Curve Expert mathematical fits ranked according the correlation coefficient and
standard error.
92
Figure 24: Curve Expert Analysis feature X= f(y)
Sometimes, the assumed input traffic densities were not high enough to
produce the desired threshold levels. In those particular cases, and because
restrictions in time and processing power didn’t allow to make more
simulation with higher loads, different “cases” were proposed, i.e. different
interpolation models (mainly linear, quadratic and exponential fits because
they represent, for the range of simulated (positive) loads, the corresponding
non-negative increasing or decreasing functions as it is required) were tried
for each KPI Figure as a way to extrapolate results from the interpolation
curve fit. As the dynamics of the system are so complex and theoretical
models about what kind of behavior in mathematical terms can be expected
in those indicators are not easily available, there is no way to predict with
accuracy which is the right traffic density that produces the true threshold
93
level. Therefore, for those cases two or three fits are calculated and finally a
range of traffic densities (together with the analytical expression used to
calculate those values) is proposed according to these results. Verification
with values within these range are proposed for further simulation studies
where more time and computational resources can be allocated. All the
analyses were performed in Microsoft Excel and all input data, graphs and
formulas are given as an annex to this thesis. For the sake of brevity, only
Voice and Web service are detailed in this report and a summary of the main
findings is provided for FTP and Video call services, but the reader is invited
to check the Excel annexes with all the detailed service analysis results.
7.1.1 Voice Service
7.1.1.1 Blocking and Dropping probability
The following Figures illustrate the obtained simulation results in terms of

Blocking and Dropping Probabilities:
Blocking probability [%]
0.1200%
0.1000%
0.0800%
0.0600% Blocked services [%]
0.0400%
0.0200%
0.0000%
10.0000
20.0000
40.0000
80.0000
160.0000
Traffic Density [Erl/Km^2]
Figure 25: Blocking probability, voice only service
94
dropped probability [%]
0.0006
0.0005
0.0004
%
0.0003 dropped probability [%]

0.0002
0.0001
0.0000
10.0000
20.0000
40.0000
80.0000
160.0000
Figure 26: Dropped probability, voice only service
As it can be seen in Figure 25 and 26, even for a relatively high traffic
density per square kilometer as 160 active users / Km2, the obtained
blocking and dropping Figures were still far from the target level (1% of
Blocking and Dropping respectively). The best fits tried for the blocking
probability were as follows:
Target threshold = 1% (Y=0.01 in linear scale)
3rd degree Polynomial Fit: y=a+bx+cx^2+dx^3...
Coefficient Data:
a= -2.62E+02
b= 3.20E+01
c= -9.56E-01
d= 7.48E-04
Level at Y = 0.01 281.71 Erl/Km^2
Number of users per cell 49
Linear Fit: y=a+bx
Coefficient Data:
a= -0.0002
b= 7.2446E-06
95
Level at Y = 0.01 1411.970 Erl/Km^2

Table 10: Estimation of the users per cell according to the simulation output, blocking
probability target = 1%
As it can be seen, the range [281,76 , 1411,970] is still very wide to try to
accurately define the traffic load that produces the 1% blocking, and
therefore more simulations need to be accomplished in further studies in
order to get more accurate results. Because of limitations in the hardware
(out of memory problems), simulations with traffic densities within this range
were not possible to verify. However, as a way of comparison, an
alternatively approach, the approach based on load factors to calculate cell
capacity mentioned in [Holma] was used to find the theoretical capacity of a
cell given a only-voice service. Working with the KPI threshold for uplink load
equal to 60% and the Eb/No value the same as in the simulations (6.91 dB)
and assuming i-ratio ( other cell interference / own cell interference) as 0.65
for a macro-cell environment ([Holma]), the number of users per cell (N) can
be calculated according to the following equation:
N = n UL / (Eb/No * υ * (1+i) / W / R) (7-1)
Where:
• n UL = uplink load factor (assumed to be 60%)
• υ = voice activity factor (assumed to be 0.5)
• W = chip rate (3.84 Mchips/sec)
• R = user data rate = 12.2 Kbps
Substituting these values in the formula, we get the value of nearly 47

users per cell.
Now, to compare this Figure with the number of users per cell according
to simulation results, first we have to calculate the cell area. The result of
this calculation is going to be used to convert the traffic densities given in
Erl/Km2 into number of users per cell in the remaining part of the
homogeneous analysis. The cell area is calculated as follows:
r = cell radius = inter-site distance / 3 = 900 m / 3 = 0.3 Km (7-2)
2
A = cell area (hexagonal cell) = K*r (7-3)
Where K=1.95 for a 3 sector node B ([Laiho]), therefore:
Cell area (hexagonal, 3 sectors per node) = 1.95 * (0.3)2 = 0.1755 Km2
Then, the number of users per cell is calculated according to the following
formula:
Number of users per cell = Round (users density [Erl (active users)/ Km2]
* cell area Size [Km2]) (7-4)
96
Where the round operator indicates approximation to the nearest integer
depending on the fractional part (above or equal to 0.5 it is approximated
up, less than 0.5 is approximated down).
Trying with the lowest range-limit:
Number of users per cell = 281.716 * 0.1755 = 49 users/cell.
Trying with the upper range-limit:
Number of users per cell = 1411,970 * 0.1755 = 248 users/cell.
Therefore, the lower limit obtained with the polynomial fit seems to be
more appropriate because it is in the same order of magnitude of the
theoretical result, and it is the Figure which is going to be selected as the
best estimate for the summary table.
Following a similar approach, the following values were found for the
dropping probability:
a= -1.19E-05
b= 1.46E+06
c= -4.35E-08
D= 3.40E-10
Level at Y = 0.01 352.673 Erl/Km^2
Linear Fit: y=a+bx
a= -0.0001
b= 3.29E-06
Level at Y = 0.01 3068 Erl/Km^2

Table 11: Estimation of the users per cell according to the simulation output, dropped probability
target = 1%
As it can be concluded from this section, dropped services occur with higher
traffic loads than when blocking occurs, which is well in line with the RRM
97
procedures defined by Ericsson and parameterized in the simulator with the

current live network values, although simulations with such traffic densities
are proposed in order to verify them.
7.1.1.2 Channel Elements usage
The following Figures illustrate the mean and maximum channel elements
usage in Uplink and Downlink (target thresholds: 256 DL, 64 UL).
DL Channel Elements usage [mean, max]

DL channel elements
200,0000
150,0000 DL Channel Elements
usage [mean]
100,0000
DL Channel Elements
50,0000 usage [max]
0,0000
00
00
00
00
00
0
00
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 27: channel elements usage, Downlink direction, voice only service
UL Channel Elements usage [mean, max]

UL channel elements
160,0000
140,0000
120,0000 UL Channel Elements
100,0000 usage [mean]
80,0000
60,0000 UL Channel Elements
40,0000 usage [max]
20,0000
0,0000
00
00
00
00
00
0
00
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 28: channel elements usage, Uplink direction, voice only service
In this case, the Figure that reaches the 64 channel elements in Uplink is
within the interpolation range so the interpolation fits with similar correlation
coefficient produce a very similar Figure (therefore only the case with the
highest correlation coefficient is provided). In the case of Downlink,
98
extrapolation is used and therefore a range of values is given. The results are
summarized in the following tables.
CE Downlink Target = 256 CE
Linear Fit: y=a+bx
Coefficient Data:
a= 17.6737
b= 0.8078
Level at Y = 256 295 Erl/Km^2
Quadratic Fit: y=a+bx+cx^2
Coefficient Data:
a= 15.544373
b= 0.90265331
c= -0.0005
Level at Y = 256 334.509 Erl/Km^2

Table 12: Estimation of the users per cell according to the simulation output, Downlink Channel
elements target = 256
CE Uplink Target = 64 CE
Quadratic Fit: y=a+bx+cx^2 Coefficient Data:
a= 0.5444
b= 0.9027
c= -0.0005
Level at Y= 64 73.5965 Erl/Km^2

Table 13: Estimation of the users per cell according to the simulation output, Uplink Channel
elements target = 64
99
As it can be seen, the Uplink Channel Elements utilization target is reached

with almost 13 voice users per cell, whereas for Downlink Channel Elements
it is reached when the number of users is between 51 and 59, which is in line
with the proportion of the allocation of Downlink Channel Elements vs. Uplink
channel Elements (256 CE DL/64 CE UL = 4 times, 51 users for DL target/13
users for UL target = 3.92 times).
7.1.1.3 Downlink Iub usage
Iub traffic [DL]
1000,0000
800,0000
600,0000
Kbps
Iub traffic [DL]

400,0000
200,0000
0,0000
00
00
00
00
00
0
00
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 29: Downlink Iub usage, voice only service
With the current version of the Wines Simulator, it was found that the Iub
measurements are only monitored as a mean value of the amount of data
present on the Iub traffic. As in the definition of KPIs the proposal was to
monitor the Iub utilization according to the number of reserved radio bearers
(as it is currently implemented in VF-NL), then the Max. PCR (Peak Cell Rate)
was taken into account as the Iub limit which indicates congestion in the Iub.
In the next version of Wines (to be released in October 2005) the Iub
utilization based on reservation will be implemented, but as far as this study
concern, the Iub threshold is set to the Max. PCR = 2786 cells/sec * 48
bytes/cell * 8 bits/byte = 1.07 Mbps, assuming 1 E1 link between each Node
B and the RNC [Iub-observability]. The obtained results are presented in the
following table.
100
Target for Iub DL throughput = 2786 cells/sec * 48 bytes/cell * 8 bits/byte = 1.07 Mbps
Coefficient Data:
a= 3
b= 6
c= -0.0031
Level at Y= 1070 218.8070 Erl/Km^2
Linear Fit: y=a+bx
Coefficient Data:
a= 15.5115
b= 5.0227
Level at Y= 1070 209.9440 Erl/Km^2

Table 14: Estimation of the users per cell according to the simulation output, Downlink Iub
congestion target= 1070 Mbps.
To prove that this number is realistic, we can perform the following

calculation that gives us the amount of Kbps consumed by the number of
users obtained by our simulation model (linear fit):
Iub Consumed Capacity [Kbps] = Data Rate (DPDCH voice connection,
Downlink) * Number of users ( 7-5)
This gives:
• 30 Kbps * 36.84 = 1105.2 Kbps, which is a very close value to our

target of 1070 Kbps.
Note that in the calculation we use 30Kbps and not 12.2 because we have to
take into account the coded channel (which includes the overhead caused by
coding and protection techniques) and not just the end-user data rate.
101
7.1.1.4 Uplink Load
UL Load [%]
100,0000%
90,0000%
80,0000%
UL Load [%]
70,0000%
60,0000%
50,0000% UL Load [%]
40,0000%
30,0000%
20,0000%
10,0000%
0,0000%
00
00
00
00
00
00
0
0
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 30: UL Load [percent], voice only service
For this case, it was also proposed in the KPIs definition to measure the
RTWP and see if its level exceeds the target (given by the two Ericsson
parameters) for a time higher than the hysteresis time (defined by the
Ericsson parameter iFHyst) . That is how Uplink load is determined in the real
system. For the simulation analysis however, it was difficult to try to average
these results because congestion happens at a different times in different
cells, it was decided to work with the approach presented in [Holma, Jabber]
which is to assume a maximum Noise Rise (in dB) and then calculate the
target UL Load in terms of the uplink load factor (nul) using the following
equation:
NR [dB] = - 10 * Log (1- nul ) ( 7-6)
Where:
NR represents the Noise Rise.
nul is the uplink load factor.
Assuming a Noise Rise level of 4 dBs [Holma], we get nul = 0.6 (60%) which
will be our target level for the Uplink Load. The results of the interpolation
are mentioned in the following table.
102
Target Value =
Uplink Noise Rise 0.60
Linear Fit: y=a+bx
Coefficient Data:
a= 0.02258
b= 0.0059
Level at Y= 0.60 99.7655 Erl/Km^2
Number of Users/cell 18
Quadratic Fit:
y=a+bx+cx^2
Coefficient Data:
a= -0.0240
b= 0.0079
c= -1.20E+02
Level at Y= 0.60 92.4429 Erl/Km^2
Number of Users/cell 16
Table 15: Estimation of the users per cell according to the simulation output, Uplink Noise Rise
congestion target = 60%
7.1.1.5 Downlink Transmitted Power
DL_TxPower [dBm]
38,5000
38,0000
Power [dBm]
37,5000
37,0000 DL_TxPower [dBm]
36,5000
36,0000
35,5000
00
00
00
00
00
00
0
0
,0
,0
,0
,0
0,
10
20
40
80
16
traffic density [Erl/Km^2]
Figure 31: Downlink transmitted power, voice only service
103
According to Ericsson Documentation, the target threshold for Downlink

Transmitted Power is 90% of the Maximum Transmission Power, which is 43
dBm in the simulation series; therefore the target threshold is 38.7 dBm. As
this value is not within the interpolation range, the two best fits are
presented as estimations.
Target threshold = 90% (43 dBm) = 38.7 dBm
Linear Fit: y=a+bx
Coefficient Data:
a= 36.3788
b= 0.01140
Level at Y = 38.7 dBm 203.68 Erl/Km^2
Coefficient Data:
a= 363.747
b= 0.0116
c= -1.06E+01
Level at Y = 38.7 dBm 205 Erl/Km^2

transmitted power congestion target = 38.7 dBm
104
7.1.1.6 Downlink Code Tree Usage
DL_Code tree usage[%]
45,0000%
40,0000%
Code tree usage [%]
35,0000%
30,0000%
25,0000% DL_Code tree
20,0000% usage[%]
15,0000%
10,0000%
5,0000%
0,0000%
00
00
00
00
00
00
0
0
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 32: DL Code tree usage [%], voice only service
The utilization of the Downlink Code Tree is calculated in percentage

according to the description found in [WinesTechRef]. Having into account
the Ericsson RRM algorithms, the Target level to trigger soft congestion
mechanism in the DL channelization codes monitor is 60% of utilization. The
results are summarized in the table below.
Target Level to trigger soft congestion mechanism = 60% (0.6 in linear scale)
Linear Fit: y=a+bx
a= 0.03858
b= 0.0023
Level at Y = 0.6 239.89 Erl/Km^2
a= 0.0320
b= 0.0026
c= -1.70E+01
Level at Y = 0.6 258.188 Erl/Km^2

Table 17: Estimation of the users per cell according to the simulation output, Downlink Code
Tree usage congestion target = 60%
105
7.1.1.7 Summary of Voice Service
Next table presents the summary with the KPI’s ordered by the traffic
densities that reach first the target level (only considering the lower values
for the number of users of each KPI, i.e. taking the most restrictive
approach):
KPI Target Level No. users to reach

the target
CE UL 64 13
UL Load 60% 16
DL power 38.7 dBm 36
Iub 1070 Kbps 37
DL code tree 60% 42
Blocking prob 1% 49
CE DL 256 51
Dropping prob 1% 62
Table 18: Ordered KPI's, voice-only service
According to the previous results, the Voice-only service is mainly uplink –

limited. Next to the uplink limiting factors are the DL transmitted power and
the Iub utilization. The KPI’s that reach their target levels at the end are the
Downlink Channel Elements number and the Dropping probability, whose
target value were not reached within the simulated traffic densities.
7.1.2 Web Service
After the analysis of the Speech service, the analysis corresponding to this
Packet Switched service is presented next.
The following Figures illustrate the obtained simulation results in terms of

Blocking and Dropping Probabilities:
106
60,0000%
50,0000%
40,0000%
30,0000% Blocked services [%]
20,0000%
10,0000%
0,0000%
00
00
00
00
00
62
25
49
7
,9
,9
1,
3,
6,
12
25
Figure 33: Blocking Probability Web service, sf8Adm=1
dropped services [%]
100,0000%
80,0000%
60,0000%
%

40,0000%
20,0000%
0,0000%
0
0
00
00
00
90
70
62
25
49
,9
,9
1,
3,
6,
12
25
Figure 34: Dropping Probability Web service, sf8Adm=1
107
Blocking Probability, Target =0.01
a) MMF Model:
y=(a*b+c*x^d)/(b+x^d)
a= -246.7280
b= 1.2024
c= 50.1275
d= 1.5127
Value at Y=1% (0.01) 3.292 Erl/Km^2
b) Linear Fit: y=a+bx
a= -0.3167
b= 0.0975
Value at Y=1% (0.01) 3.3526 Erl/Km^2

Table 19: Estimation of the users per cell according to the simulation output, Web-only service,
parameter sf8Adm=1, Blocking probability target = 1%
Analyzing the results, very low Figures were found, near 1 user / cell. In
order to check the results, an analytical approach was used again, assuming
that the main limitation for packet-switched services is Downlink Power
consumption as it was shown in [Schneider-1]. According to [Holma], the
Downlink load factor is defined as:
ndl = Σ υj * (Eb/No)j / W/Rj [1-α+i], j=1 to N ( 7-7)
Where:
• N = number of users in the cell
• υj = service activity factor (for PS services assumed to be 1)
• W = chip rate = 3.84 Mchips/sec
• Rj = Data Rate of user j
• Eb/Noj = Eb/No for user j
• α = Downlink Orthogonality factor, for the formula, 1 means
maximum orthogonality (for the simulator 0.4 is used but 0
means in the simulator context full orthogonality, so for the
formula calculation a value of 0.6 is assumed)
• i = Other cell/ Own cell interference factor, assumed 0.65 for a
macro-cell scenario [Holma]
108
The formula reflects that in Downlink the Data Rate for each user and the
Eb/No are specific for each user’s location. To make it possible to have an
estimation of the number of users per cell, it will be assumed that Eb/No and
R is the same for all users (4.56 dBs and 384 Kbps respectively). With these
assumptions, replacing the values in the formula and setting the Downlink
Load Factor as the congestion threshold defined by the Ericsson parameters
(90% of the Downlink Power so assumed ndl =0.9), we found that the
number of users supported per cell is 3 and the corresponding traffic density
would be 17.09 Erl/Km2, both far from the obtained values of 0.58 users and
3.35 Erl/Km2. For admission control settings (ndl =0.75), we obtain 2 users
per cell and the corresponding traffic density of 11.39 Erl/ Km2.
Taking a deeper look at the simulation results, the cause of such low traffic
densities to reach the capacity threshold (and the corresponding number of
users per cell) was found: There is a parameter defined by Ericsson and
called sf8Adm, which controls the maximum number of connections per
spreading factor. As the current implementation of the simulator tries always
to get the maximum possible data rate per each service request (next
release it will include the “slow-start” approach mentioned in [Holma]), then
having the sf8Adm with the real setting in the network (sf8Adm=1) is the
main blocking cause (more than 80% of the times), as it can be checked in
the summary for each simulation, where the main reason for blocking found
was “DL SF8 usage limit exceeded” in all the simulations with the 5 different
traffic densities. Therefore, a new simulation series was programmed with
the sf8Adm with its maximum value (8) which means no restriction due to SF
8 usage. Next Figure and table shows the new results. Intuitively, due to the
simulation implementation already mentioned, it is expected that the traffic
density that reaches the 1% blocking would be reached earlier than in the
case of the analytical approach, as currently there is no way to simulate the
slow-start mechanism.
14.0000%
12.0000%
10.0000%
8.0000% Blocked probability
6.0000% [%]
4.0000%
2.0000%
0.0000%
1.6200
3.2500
6.4900
12.9900
25.9700
Figure 35: Blocking Probability Web service, sf8Adm=8
109
a= 0.0047
b= -0.0027
c= 0.0003
Value at Y=1% (0.01) 11.0888 Erl/Km^2
a= 0.0023
b= -0.0015
c= 0.0002
d= 3.13E-06
Value at Y=1% (0.01) 11.0839 Erl/Km^2

parameter sf8Adm=8, Blocking probability target = 1%
As it can be seen, the number of users and traffic densities obtained are now
quite close to the Figures obtained in analytical way for the admission control
settings (ndl =0.75). Checking also the main blocking reason, this is in most
of the cases, “Downlink Transmit Power Exceeded”. The errors due to
timeout were discarded as it was discovered by Vodafone D2 that the
timeout implementation does not work correctly and it will be replaced during
the next Version of WiNeS.
About the dropping probability, it was found in the simulation that when
using Ericsson P3.0 RRM algorithm, there is no dropping of PS services
because the UE’s are normally switched to the FACH channel instead of being
dropped. Vodafone D2 is currently clarifying if this handling is equal to the
real handling in Ericsson hardware, because so far it is not clear if Ericsson
supports data transmissions on the FACH.
The following Figures illustrate the mean and maximum channel elements
usage in Uplink and Downlink (target thresholds: 256 DL, 64 UL).
110
DL channel elements
80,0000
70,0000 DL Channel
60,0000 Elements usage
50,0000 [mean]
40,0000
30,0000 DL Channel
10,0000 [max]
0,0000
00
00
00
00
00
62
25
49
7
,9
,9
1,
3,
6,
12
25
Figure 36: DL channel elements usage, Web-only service

UL channel elements
60,0000
UL Channel
50,0000
Elements usage
40,0000
[mean]
30,0000
UL Channel
20,0000
Elements usage
10,0000
[max]
0,0000
00
00
00
00
00
62
25
49
7
,9
,9
1,
3,
6,
12
25
Figure 37: UL channel elements usage, Web-only service
a) Downlink
Linear Fit: y=a+bx
a= 19.438376
b= 1.3701932
Value at Y = 256 173.648 Erl/Km^2
A= 17.966051
B= 1.774063
C= -0.01442546
111
Value at Y = 256 218.0280 Erl/Km^2
b) Uplink
A= 1.1074
B= 1.5842
C= -0.0108
Value at Y = 64 71.8009 Erl/Km^2
Linear Fit: y=a+bx
A= 2.2047
B= 1.2832
Value at Y = 64 48.1573 Erl/Km^2

Downlink and Uplink channel element target: 256, 64
In the Figures 36 and 37, we can appreciate a lower channel element usage,
both in UL and DL regarding the same usage in the voice service. This is
because a low number of users per cell is supported, although it has to be
taken into account that the number of channel elements used in a 384 Kbps
DL connection regarding the number of channel elements used in a speech
connection has a relation 8:1 (for UL this relation is 2:1). But even with that
relationship, the maximum number of users times the channel elements per
user connection in UL or DL, which would be an estimation of the number of
CE is given by 3 * 8 = 24 CE in DL for the web service whereas for the voice
service is given by 47 * 1 = 47 CE in DL, which is greater.
112
Iub traffic [DL]
1200,0000
1000,0000
800,0000
Kbps
Iub traffic [DL]

600,0000
400,0000
200,0000
0,0000
00
00
00
00
00
62
25
49
7
,9
,9
1,
3,
6,
12
25
Figure 38: DL Iub utilization, Web only-service
Target for Iub DL throughput = 2786 cells/sec * 48 bytes/cell * 8 bits/byte = 1.07 Mbps
Linear Fit: y=a+bx
Coefficient Data:
a= 137.3714
b= 33.6504
Level at Y= 1070 27.7152 Erl/Km^2

Table 22:Estimation of the users per cell according to the simulation output, Web-only service,
DL Iub congestion target = 1.07 Mbps
According to the simulation results, approximately 5 users would cause

congestion in the Iub interface. Checking the results assuming full time
maximum utilization of the channel (and therefore Data Rate of the coded
channel for a 384 Kbps data rate = 480 Kbps), we would have 5 users * 480
Kbps = 2400 Kbps (which would theoretically exceed the maximum capacity
available of the E1 circuit), but assuming a reasonable utilization of about
50% of the time, the Figure would be 1200 Kbps which is close to the defined
target of 1070 Kbps.
113
7.1.2.4 Uplink Load
UL Load [%]
3.0000%
Uplink Load [%]
2.5000%
2.0000%
1.5000% UL Load [%]
1.0000%
0.5000%
0.0000%
0
00
00
00
90
70
62
25
49
.9
.9
1.
3.
6.
12
25
Figure 39: UL Load, Web only service
Taking a look at the simulation results, we can clearly see that UL load
seems not to be a problem for the Web Service. Even with the highest
simulated load for Web Service (25.97 Erl/Km2), the Uplink load is about
6%, quite far away from the target (60%). In these conditions, the
different fits produce very different results, but for the purpose of this
analysis the most restrictive setting among linear, quadratic and
exponential fit is presented in the next table.
Uplink Load
Exponential Fit: y=ae^(bx)
Coefficient Data:
a= 0.005193252
b= 0.065165121
Value at Y=60% (0.6) 72.8858 Erl/Km^2
uplink load target = 60 %
114
DL_TxPower [dBm]
38,0000
37,8000
37,6000
37,4000
Power [dBm]
37,2000
37,0000
36,6000
36,4000
36,2000
36,0000
35,8000
00
00
00
00
00
62
25
49
7
,9
,9
1,
3,
6,
12
25
Figure 40: DL Transmitted power usage, Web-only service
The Downlink transmitted power usage shows the same behavior trend as
in the case of voice-only usage, although the levels are lower. This can be
also due to the smaller number of Web users per cell. As the target value
it is not present in the interpolation range, three estimated values are
presented in the next table using extrapolation with the obtained
analytical expressions.
Downlink Transmitted
Power
Linear Fit: y=a+bx
a= 36.528181
b= 0.047020985
Value at Y=38.7 46.1883 Erl/Km^2
a= 36.5313
b= 0.0013
115
Quadratic Fit:
y=a+bx+cx^2
a= 36.504102
b= 0.0536
c= -0.0002

Table 24:Estimation of the users per cell according to the simulation output, Web-only service,
DL Transmitted power congestion target = 38.7 dBm
According to these results, to reach the target for congestion in Downlink

due to Transmitted Power usage, the required number of users is between
8 and 9.
DL_Code tree usage, homogeneous scenario [%]
25.0000%
Code tree usage [%]
20.0000%
15.0000%
10.0000%
5.0000%
0.0000%
6.4900 12.9900 25.9700
Figure 41: DL code tree usage, Web only service
According to the Figure, the code tree usage is lower than the code tree
usage for voice, but this has to do also with the current implementation of
the simulator that doesn’t model the slow-start mechanism (i.e. PS
services start with a data rate of 64 Kbps and as soon as there is capacity
available in the cell they upgrade their data rate with a smaller spreading
factor), therefore in a real-network the expected code tree usage would
be higher than the value obtained in the simulations. It is proposed to try
the same feature once the simulator includes the slow-start mechanism in
its internal implementation. In the Figure, only the part corresponding to
the range [6.49, 25.97] is presented due to no output data was obtained
for DL Code Tree usage with the first two traffic densities. The
corresponding fit for the range presented is summarized below.
116
DL Code Tree usage target =60%
Linear Fit: y=a+bx
Coefficient Data:
a= 0.043132
b= 0.006364
Value at Y=60% (0.6) 87.49 Erl/Km^2
DL code tree usage target = 60%
7.1.2.7 Throughput
Web Indoor Application DL Throughput per user
350.0000
300.0000
250.0000
Kbps
200.0000
DL Throughput
150.0000
100.0000
50.0000
0.0000
1.6200 6.4900 12.9900 25.9700
Figure 42: Downlink throughput, Web only service, indoor users
Web outdoor Application DL Throughput per

user
400.0000
300.0000
Kbps
200.0000
100.0000
DL Throughput
0.0000
1.6200 6.4900 12.9900 25.9700
Figure 43: Downlink throughput, Web only service, outdoor users
117
Intuitively, it was expected that the performance in terms of throughput

may be lower for Indoor users (due to the assumed penetration loss of 18
dB) than with outdoor users, but simulation results show a different
behavior as it can be seen in Figures 42 and 43: Although the Downlink
Throughput starts in a higher level for outdoor users, the throughput
decreases faster than the throughput for indoor users, and for the
maximum considered load, the Downlink throughput for the indoor users
is slightly better than for the outdoor ones. Therefore it can be concluded
that the 18 dB’s of assumed losses for the indoor users have more impact
in coverage terms rather than in the throughput experienced by the end
user, and as there is almost no dropping probability because the channel
switching to FACH, the indoor users experience on average the same
throughput as their outdoor counter parts with the same mobility profile
(both group of users with pedestrian mobility profile). In any case, with
all the simulated traffic densities the throughput is above the internal
target (100 Kbps), therefore estimations based on the best interpolation
fits are provided. The results obtained for the data point corresponding to
the traffic density of 3.25 Erl/Km2 were discarded due to some internal
error in the simulator when simulating this load level.
Indoor users

Coefficient Data:
a= 341.31176
b= -0.013965516
Value at Y=100 87.9041 Erl/Km^2
Number of users per
cell 15
Outdoor users

Coefficient Data:
a= 380.60388
b= -0.019331111
Number of users per
cell 12
throughput target = 100 Kbps
118
7.1.2.8 Summary of Web service
Next table presents the summary of the Web Service with the KPI’s ordered
by the traffic densities which reach first their target level:
KPI Target No. users to

Level reach the
target
Blocking 1% 2
prob
DL Iub 1070 Kbps 5
DL power 38.7 dBm 8
CE UL 64 8
DL 100 kbps 12
throughput
(outdoor)
UL Load 60% 13
DL code 60% 16
tree
CE DL 256 30
Table 27: Ordered KPI's, Web-only service
In the previous table, we can see that Blocking Probability is the first KPI to
reach the target. Theoretically, allowing a higher Blocking Probability for PS
services would increase the capacity of the cell and it would be possible to
allow more blocking for the PS services, given the more flexible
characteristics of the packet switched services to tolerate a higher BLER
compared with the circuit switched services. In the second and third place we
can observe that the capacity for the Web Service is now Downlink limited
(Iub, DL power) rather than Uplink limited as in the Voice Service.
119
7.1.3 FTP Service
3.0000%
2.5000%
2.0000%
Blocking probability
1.5000%
[%]
1.0000%
0.5000%
0.0000%
0.3900 0.7800 1.5600 3.1200 6.2300
Figure 44: Blocking probability, FTP only service
Target threshold = 1%
Coefficient Data:
a= 0.001576177
b= -0.002396161
c= 0.001062297
Value at Y=1% (0.01) 4.1627 Erl/Km^2

Table 28: Estimation of the users per cell according to the simulation output, FTP-only service,
target threshold for blocking = 1%
120
0,6000%
0,5000%
0,4000%
%
0,3000% dropped services [%]

0,2000%
0,1000%
0,0000%
0,3900 0,7800 1,5600 3,1200 6,2300
Figure 45: Dropping probability, FTP only service
Dropping probability
Coefficient Data:
a= 0.0004
b= -0.0008
c= 0.0003
Value at Y=1% (0.01) 8.1451 Erl/Km^2
Number of users per

cell 1
Table 29: Estimation of the users per cell according to the simulation output, FTP only service,
target threshold for dropping = 1%
The FTP service has the lowest number of users per cell and this can be
explained due to its intensive usage of the air interface. The corresponding
traffic model is based on the WWW traffic model; however it considers just
one “big” packet call, therefore the service remains mostly making usage of
the dedicated channels (DCH) although it can be Down-switched in case of
congestion. For the WWW however, in low activity periods the call is “handed
over” to the forward access channel. This also has an influence on the user
121
throughput as a FTP channel always uses at least the 64 Kbps bearer,

whereas the WWW service can have 32 Kbps or less when it is making use of
the FACH, so it is expected higher throughput for the FTP service than the
throughput for the WWW service. This usage of a dedicated channel leads
also to some dropping probability. Also, being more flexible with the achieved
Block Error Rate, it is expected to have more capacity in both Uplink and
Downlink. Experimentation with different levels of BLER for packet switched
services is proposed for further studies.
120,0000
DL channel elements
100,0000 DL Channel
Elements usage
80,0000
[mean]
60,0000
DL Channel
40,0000
Elements usage
20,0000 [max]
0,0000
00
00
00
00
00
39
78
56
12
23
0,
0,
1,
3,
6,
Figure 46: DL CE usage, FTP only service
80,0000
UL channel elements
70,0000
UL Channel
60,0000
Elements usage
50,0000
[mean]
40,0000
30,0000 UL Channel
Elements usage
20,0000
[max]
10,0000
0,0000
0,3900 0,7800 1,5600 3,1200 6,2300
Figure 47:UL CE usage, FTP only service
122
Target levels: 64 CE UL 256 DL
a) Downlink
Linear Fit: y=a+bx
a= 15.5037
b= 7.0251
b) Uplink
Coefficient Data:
a= -0.0530
b= 5
c= 0.1415

target DL and UL CE usage: 256, 64.
According to the Figures 46 and 47, the mean number of Downlink channel
elements for the maximum FTP traffic density is approximately in the same
order of magnitude of the mean number of Downlink channel elements for
the maximum Web traffic density (59 and 54 respectively). For the uplink
however, the supported number of users per cell is lower than in the case of
the Web service and this can be explained by the channel switching methods
applied to one and another service (dedicated to dedicated channel switching
in FTP services and dedicated to dedicated and dedicated to FACH in Web
services).
123
Iub traffic [DL]
1400,0000
1200,0000
1000,0000
Kbps
800,0000
Iub traffic [DL]
600,0000
400,0000
200,0000
0,0000
0,3900 0,7800 1,5600 3,1200 6,2300
Figure 48: Iub traffic, FTP only service
Target for Iub DL throughput = 2786 cells/sec * 48 bytes/cell * 8 bits/byte = 1,07 Mbps
Linear Fit: y=a+bx
Coefficient Data:
a= 34,4036
b= 204,8369
Level at Y= 1070 5,0550 Erl/Km^2

target DL throughput =1.07 Mbps
According to Figure 48 and table 31, again a lower traffic density causes
congestion in the DL, the obtained results suggest that near 1 Erlang per cell
is enough to reach the congestion in the Iub interface (maximum channel
utilization).
124
7.1.3.4 Uplink Load
UL Load [%]
12,0000%
10,0000%
8,0000%
UL load [%]
6,0000% UL Load [%]
4,0000%
2,0000%
0,0000%
0,3900 0,7800 1,5600 3,1200 6,2300
Figure 49: Uplink load, FTP only service
UL Load threshold = 0.60 = 60%
Coefficient Data:
a= -0.0012
b= 0.01575
c= 0.0001
Level at Y= 0.60 30.363 Erl/Km2

target UL load = 60%
We can appreciate, according to the previous table, that UL load usage

seems not to be a big issue for data services (Web, FTP) within the range
of the traffic densities observed, as the target level is still quite far away
from the target level (60%), so according to the simulation output,
Downlink direction seems to be the most scarce resource for Packet
Switched services.
125
DL_TxPower [dBm]
39,0000
38,5000
38,0000
Power [dBm]
37,5000
36,5000
36,0000
35,5000
35,0000
0,3900 0,7800 1,5600 3,1200 6,2300
Figure 50: DL Transmitted power, FTP only service
Linear Fit: y=a+bx
Coefficient Data:
a= 36
b= 0.3438
Level at Y = 38.7 dBm 6.7843 Erl/Km2

target Downlink power = 38.7 dBm
The Downlink transmitted power is, in terms of blocking reason, the most
frequent one found in the simulation results for the FTP service. This can be
expected as the asymmetrical demand of the current services makes the
Downlink to consume more radio resources than the Uplink counterpart. The
situation can be different for symmetric services (Speech, Video telephony)
where the UL and DL load is more balanced.
126
30,0000%
25,0000%
Code tree usage [%]
20,0000%
DL_Code tree
15,0000%
usage[%]
10,0000%
5,0000%
0,0000%
0,3900 0,7800 1,5600 3,1200 6,2300
Figure 51: DL Code Tree usage, FTP only service
Linear Fit: y=a+bx
a= 0.03295
b= 0.03975
Level at Y = 0.6 14.2658 Erl/Km^2

target DL code tree usage = 60%
Downlink code tree usage is the second most frequent blocking reason and
this can be explained by the higher demand of code resources made by the
PS services, compared with the CS services where this issue is not very
problematic.
127
7.1.3.7 Throughput
Target (Indoor, Outdoor) = 100 Kbps
a) Indoor users
Geometric Fit: y=ax^(bx)
Coefficient Data:
a= 238
b= -0.027463913
Value at Y = 100 12.4942 Erl/Km^2
b) outdoor users
Coefficient Data:
a= 318
b= -0.1038
Value at Y = 100 11.1251 Erl/Km^2

Table 35 :Estimation of the users per cell according to the simulation output, FTP-only service,
target throughput = 100 Kbps
According to the previous table, we can see less supported users per cell
(near 2) than in the case of Web Service (between 3 and 9), and again these
differences can be attributed to the type of channel switching performed on
each service.
7.1.3.8 Summary FTP Service
In the next table, a summary with the KPI’s ordered by the number of users
that reaches first the target level is provided. In the case of KPIs with the
same number of users, the order has been set according to the
corresponding traffic density levels (without truncation).
128
KPI Target No. Traffic
Level users to Density
reach Level
the
target
Blocking 1% 1 4.1627
prob
Iub DL 1070 1 5.0550

Kbps
DL power 38.7 1 6.7843

dBm
Dropped 1% 1 8.1450
prob
CE UL 64 2 9.83
throughput 100 2 11.1251

kbps
DL code 60% 3 14.2658

tree
UL Load 60% 5 30.363
CE DL 256 6 34.234
Table 36: Ordered KPI's, FTP-only service
As in the Web Service, the capacity is Downlink-limited for the FTP service.
After blocking probability, Iub DL utilization and DL power are the main
limiting factors. Uplink load has definitely not the significance that it has in
the case of circuit switched services (e.g. voice), as it can be also concluded
from the previous table. And the CE DL in the last place indicates that with
the current provisioning of hardware in Downlink Direction (Channel
Elements) there are no hardware-related capacity problems. However Uplink
CE occupies an intermediate position and given that in the voice service turns
out to be one of the main limiting factors, special attention shall be given to
the number of channel elements in uplink. Simulations testing Node Bs with
more than 64 CE in UL are proposed for further studies.
129
7.1.4 Video-call Service
Next section presents the analysis of the experiments performed with the
video call service (Circuit Switched service).
Blocking probability, target: y

=0.01 (1%)
Linear Fit: y=a+bx
Coefficient Data:
a= -0.0031
b= 0.0004

Table 37: Estimation of the users per cell according to the simulation output, video call service,
blocking probability target=0.01
The average number of users per cell obtained was around 6 users per
cell which is higher than the expected theoretical value of 4 assuming
again Uplink load factor of 0.6 and applying the analytical approach.
About the dropping probability, some inconsistencies were found in the
outcomes so no analysis was performed with this data.
In order to reach the target thresholds by interpolation results, a high

variation was found in Downlink (8 to 27 users per cell to use the full
capacity in Downlink, 256 channel elements) whereas in Uplink the
number of required users is around 3, which can be an indicator that the
number of channel elements can become a very important capacity
limiting factor in Uplink for the video call service.
The best fit that was found suggest an average number of users to reach
the Downlink Iub target of 6 users/cell, which was more or less the level
found to reach the target blocking in the air interface, then it seems to be
a strong relationship between the target for blocking and the target to
produce congestion in the Iub.
130
7.1.4.4 Uplink Load
UL Load [%]
60,0000%
50,0000%
UL Load [%]
40,0000%
30,0000% UL Load [%]
20,0000%
10,0000%
0,0000%
0,9700 1,9500 3,9000 7,7900 15,5800
Figure 52: Uplink Load, video-call only service
Linear Fit: y=a+bx
a= -0.0051
b= 0.0343
Value when Y=0.60 17.46 Erl/Km^2
a= -0.0094
b= 0.0362
c= -0.0001
Value when Y=0.60 17.83 Erl/Km^2

Uplink load target = 0.6 (60%)
131
According to the Figure and table shown above, Uplink Load is again, as in
the case of speech, the most important capacity limiting factor, this can
be observed because it is the factor that according to the number of
users, reaches the target value first. The extrapolation results give very
close results to each other because the highest traffic density used was
quite close to produce the 60% uplink load target.
Linear Fit: y=a+bx
a= 36,398187
b= 0.11769338
Value when Y = 38.7 19.55 Erl/Km^2
Coefficient Data:
a= 36.4057
b= 0.0031
Value when Y = 38.7 19.4338 Erl/Km^2

Downlink Transmitted Power target = 38.7 dBm
Downlink transmitted power was another reason found for blocking attempts,
although the number of users to reach the target threshold is still higher than
in the case of Uplink Load. This is a very specific characteristic in CS services,
as for PS services according to the simulation results the Downlink
Transmitted power is the main capacity limitation.
The code tree utilization with the proposed traffic densities is still very low
(around 17% with the highest considered traffic density) compared with the
target of 60%, therefore again it seems not to be a very big problem. No
blockings were registered because of Downlink Codes shortage.
132
7.1.4.7 Summary of video-call service
In the next table, a summary with the KPI’s ordered by the number of users
that reaches first the target level is provided. In the case of KPIs with the
same number of users, the order has been set according to the
corresponding traffic density levels (without truncation).
KPI Target No. users to Traffic

Level reach the density level
target
17,46
UL Load 60% 3
17.74
CE UL 64 3
19.55
DL power 38.7 3
dBm
27.1968
DL code 60% 5
tree
32
Iub 1070 6
Kbps
32.19
Blocking 1% 6
prob.
49.7967
CE DL 256 9
Table 40: Ordered KPI's, Video call--only service
Comparing this table with the table for Voice only service, we can appreciate
that in both Video call and Voice service, UL Load is the main capacity
limiting factor and then both circuit switched services are mainly uplink
limited. DL channel elements are again at the bottom of the list, indicating
that in both services the main limitation is not the hard resources but the
interference limited resources (soft resources). There were some
inconsistencies however with the dropping probability results and therefore it
is proposed to verify them with new simulations.
133
7.1.5 Summary single-service experiments
According to the analysis performed over the results, the capacity limiting
factors for the different services are ordered according to the traffic density
level that reaches first the target threshold, as follows:
7.1.5.1 Circuit-Switched Services:
Voice service Video call
CE UL UL Load
UL Load CE UL
DL power DL power
Iub DL code tree
DL code tree Iub
Blocking prob. Blocking prob.
CE DL CE DL
Dropped prob. Dropped prob.

Table 41: Comparison Limiting factors, CS services, single-service experiments, homogeneous
scenarios
Besides the clear fact that the capacity is uplink limited for both services, DL
Power must be also considered a critical resource for circuit switched services
(is in the 3rd place for both Voice and Video call). The critical factors with
middle importance are Iub Downlink utilization and DL code Tree utilization.
The less critical factors according to the results are DL Channel Elements
(therefore the capacity is “soft” limited rather than “hard” limited for CS
services) and Dropped Probability, although for video-call service more
experiments are required to verify this.
134
7.1.5.2 Packet-Switched Services:
FTP Service Web Service
Blocking prob. Blocking prob.
DL Iub DL Iub
DL power DL power
Dropping prob. CE UL
CE UL DL throughput
(outdoor)
throughput UL Load
DL code tree DL code tree
UL Load CE DL
CE DL Dropping prob.
Table 42: Comparison Limiting factors, PS services, single-service experiments, homogeneous
scenarios
Apart from the clear difference regarding CS services about the main
capacity limitation factors in Downlink instead of Uplink direction (something
that was expected because of the higher data rates in Downlink for the PS
services, which indeed consume more radio resources than their
corresponding resources in Uplink Direction), we can notice additionally that
for both kinds of services (CS, PS) the limitation is not mainly the “hard” but
the “soft” resources , with exception of the Uplink Channel Elements usage
which is an important limiting factor for both type of services.
Between the two simulated PS services, the main difference is the place of
the Dropping Probability, in the Web Service no dropping probability was
found with the simulated traffic loads (and therefore no estimation was
possible for the load that reaches the 1% threshold); however, as it was
mentioned before, this is in line with the RRM channel switching algorithms
(switching from DCH to FACH), when the Web users can still keep the
connection with data rates of 32 Kbps without been dropped by the system,
as it happens with the FTP users that keep using mostly the DCH channels.
However, in order to get more realistic results, new simulations have to be
performed when the simulator includes the slow start mechanism which has
a direct impact in the blocking and dropping probabilities.
135
7.2 Figures using the defined traffic mix percentages
To be able to perform this analysis, a consistent traffic unit has to be found,

we cannot add directly the Erl/Km2 for each service because the resource
utilization inter-arrival and service times are different for each service,
therefore, we have to perform a conversion to a single unit. That unit was
defined based on [umts-forum6] and it is called Offered Data Volume. The
Offered Data Volume (ODV) is given in [Mbit/(busy) hour/Km2] and
theoretically is defined as:
ODV = BHCA * service penetration * potential users / Km2 * Service
Throughput [Mbps] * effective call duration [sec] (7-8)
Where:
BHCA = Busy Hour call attempts, which represents the number of calls per
user (offered traffic per user) in the busy hour. This quantity, as defined in
[Ericsson-tutorial] is equivalent to:
BHCA = 3600 * λ (7-9)
Where λ is the call arrival rate [calls / second].
On the other hand, the Offered Poisson Traffic can be defined as:
A [Erlangs] = λ / µ (7-10)
Where µ = service rate = 1/ E[s], where E[s] is the mean expected service
time. Therefore:
A = λ * E [s] ( 7-11)
Putting λ in terms of A and E[s] and replacing in the definition of BHCA, we

have:
BHCA = 3600 A / E [s] (7-12)
In this case, A would represent the offered traffic by each user. Putting
everything together:
ODV = 3600 A / E[s] * service penetration/Km2 * potential users / Km2 *

service throughput * effective call duration (7-13)
But:
Effective call duration = υ * E [s], where υ is the service activity factor,

therefore:
136
ODV (offered traffic density) in Erlangs/Km2 = A * service penetration/Km2 *
potential users / Km2 = active users/ Km2 (7-14)
Finally,
ODV = 3600 * Offered Traffic Density * Service throughput * υ (7-15)
υ was defined as 0.5 in the case of voice and 1 for all other services, and the
Service throughput was defined averaging the throughput of the indoor and
outdoor users obtained in the simulation results. The next table shows the
calculations performed and the summary of ODV Figures to be analyzed (X-
axis of the graphs of KPI vs. ODV).
137
Offered Data
Volume
[Mbit/busy
Experiment Service Traffic density [Erl/Km^2] Service Bandwidth (DL) [Mbit] = BW [Kbps]/1000 Activity Factor hour/Km^2]
1 Speech 10 0.0122 0.5 219.6
1 Videocall 0.97 0.064 1 223.488
1 FTP 0.39 0.25 1 347.3916069
1 Web 1.62 0.31 1 1827.212255
total ODV Experiment 1 2617.691861
2 Speech 20 0.0122 0.5 439.2
2 Videocall 1.95 0.064 1 449.28
2 FTP 0.78 0.22 1 605.020308
2 Web 3.25 0.24 1 2826.786672
3 Speech 40 0.0122 0.5 878.4
3 Videocall 3.9 0.064 1 898.56
3 FTP 1.56 0.17 1 933.4731671
3 Web 6.49 0.19 1 4485.439296
138
4 Speech 80 0.0122 0.5 1756.8
4 Videocall 7.79 0.064 1 1794.816
4 FTP 3.12 0.12 1 1330.948855
4 Web 12.99 0.11 1 4998.538791
5 Speech 160 0.0122 0.5 3513.6
5 Videocall 15.58 0.064 1 3589.632
5 FTP 6.23 0.06 1 1317.665429
5 Web 25.97 0.04 1 3355.780886

Table 43: Calculation of the ODV for the Service Mix, non-homogeneous scenario
139
ODV [Mbit/busy hour /
Experiment Km^2]
1 2617.691861
2 4320.28698
3 7195.872463
4 9881.103646
5 11776.67832
Table 44: Summary table with the ODV Figures to be used for the analysis
After having defined the common measurement unit, we proceed to

analyze each KPI in order to find which of them is the limiting factor for
the given traffic mix, i.e. which is the one that happens first in terms of
the required offered load to reach the target KPI. The following section
presents the results for each KPI.
7.2.1 Blocking and Dropping probability
60.0000%
50.0000%
40.0000%
Blocked
30.0000%
services [%]
20.0000%
10.0000%
0.0000%
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
Offered Data Volum e [Mbit/busy

hour/Km ^2]
Figure 53: Blocking probability service mix, target =0.01 (1%)
Harris Model: y=1/(a+bx^c)
a= 2568.9699
b= -1608.3547
c= 0.0500
Standard Error: 0.01022
Correlation Coefficient: 0.9994
141
Value at Y=0.01 5279.6000 Mbit/hour/Km^2
Mbit/hour/cel
ODV per cell per hour 926.2456 l
ODV per cell per second 0.2572 Mbit/sec/cell
257.2904
ODV Kbps/cell Kbps/cell

Table 45: Blocking probability service mix, target =0.01 (1%)
As the target of 1% was reached within the interpolation range, only the
best fit in terms of the correlation coefficient is presented. Then, we
obtain the 1% blocking with the offered data volume of 5279.600
Mbit/hour/Km2. To be able to analyze the performance per cell, we have
to convert this Figure, and the way to do it was to take into account that
the cell area is 0.1755 Km2, so in 1 Km2 there are approximately 5.7 cells.
Applying this conversion factor we obtained the ODV per cell per hour,
and dividing it by 3600 seconds/hour and multiplying by 1000 we finally
got the Offered Data Volume in Kbps/cell. Dividing this value with the
mean value of the RLC layer performance “DL Transmission Data Rate
[kbps]” for each service, we could have a rough estimate of the number of
users supported by the cell per each service:
Service RLC DL Transmission Average

Data Rate [kbps] Number of
Users
Web indoor 163,759 2
FTP indoor 237,7139 1
Web outdoor 156,9783 2
FTP outdoor 241,8718 1
Voice 11,97 22
Video-call 63,65 4
Table 46: Estimation of the supported number of users per service
This IS in line with the simulation results obtained by Vodafone Germany

in [Schneider-1] and it represents a big change in the supported number
of Voice Users obtained in the Voice-only service, where the theoretical
value (and the obtained value) was around 42 users per cell, now the
Figure is about a half of it, but we have to take into account that the
Figures presented in the table 34 are just an estimation because the
offered traffic was a traffic mix and not a single-service offered traffic.
142
10.000000%
8.000000%
% 6.000000%
4.000000% dropped services [%]
2.000000%
0.000000%
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
Offered Data Volume [Mbit/busy
hour/Km^2]
Figure 54: Dropping probability service mix, target =0.01 (1%)
Dropping probability, target threshold = 0.01 (1%)
Reciprocal Logarithm Fit: y=1/(a+b*ln(x))
Coefficient Data:
a= 10.937.20
b= -1.168.57
Standard Error: 0.0007945
Correlation Coefficient: 0.9998536
Value at Y=0.01 10660 Mbit/hour/Km^2
ODV per cell per hour 1870.1754 Mbit/hour/cell
ODV Kbps/cell 519.4931 Kbps/cell

Table 47: Dropping probability service mix, target =0.01 (1%)
For the dropped services, we can see that the Load required to reach the
target is higher (almost twice as much) than in the case of blocking
probabilities. This goes in line with the behavior defined in the Ericsson
RRM Algorithms were dropping calls is the last option at all while soft
blocking of non-guaranteed connections (i.e. data connections) is the first
option to free radio resources in case of congestion.
143
7.2.2 Channel Elements usage
DL channel elements DL Channel Elements usage [mean, max]
200.0000 DL Channel
150.0000 Elements usage
[mean]
100.0000
DL Channel
50.0000
Elements usage
0.0000 [max]
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
Offered Data Volume
[Mbit/busy hour/Km^2]
Figure 55: Channel Elements usage service mix, Downlink target 256
180.0000
UL channel elements
160.0000
140.0000 UL Channel
120.0000 Elements usage
100.0000 [mean]
80.0000 UL Channel
60.0000
Elements usage
40.0000
[max]
20.0000
0.0000
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783

hour/Km^2]
Figure 56: Channel Elements usage service mix, Uplink target 64
In both graphs, we see that the target thresholds (256 CE in Downlink and
64 CE in UL) were reached within the interpolation range. Therefore, only
the best fit for both cases (using the mean values as a data set) are
presented in the next table.
144
Downlink Channel Elements (target 256)
Coefficient Data:
a= 18.3079
b= 5.11E-03
c= 7.27E-07
Value at Y=256 14899.40 Mbps/hour/Km^2
Uplink Channel Elements (target 256)
Coefficient Data:
a= 12.8075
b= 0.0002
Value at Y=64 6518.6300 Mbps/hour/Km^2

Table 48: Channel Elements usage, service mix, uplink and downlink channel elements
target: 256, 64
So far we can appreciate that the Downlink Channel Element threshold is

reached after the Blocking and Dropping Target, but the UL channel
Element threshold is reached before the Dropping Target. However, we
must continue with the analysis to see which the order of occurrence of
each target is.
145
7.2.3 Downlink Iub usage
Iub traffic [DL]
2000.0000
1800.0000
1600.0000
1400.0000
1200.0000
Kbps
1000.0000 Iub traffic [DL]

800.0000
600.0000
400.0000
200.0000
0.0000
2617.6919
4320.2870
7195.8725
9881.1036
hour/Km^2]
Figure 57: Iub utilization, Traffic Mix, Target = 1.07 Mbps
For this analysis, only a data set with 4 points was considered as the
corresponding simulation with the highest traffic density level presented
errors in the results. However, the Iub target is reached within the 4
selected points. The result of the analysis with the best fit is presented in
the next table.
Linear Fit: y=a+bx
Coefficient Data:
a= -132.5321
b= 0.1951
Value at Y=1070 6164.99 Mbit/hour/Km^2

Table 49: Downlink Iub utilization, service mix, Downlink target 1070 Kbps
Therefore, Iub downlink utilization, so far, is the second factor after the
blocking target that is reached first.
146
7.2.4 Uplink Load
UL Load [%]
100.0000%
90.0000%
Noise Rise [%]
80.0000%
70.0000%
60.0000%
50.0000% UL Load [%]
40.0000%
30.0000%
20.0000%
10.0000%
0.0000%
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
Offered Data Volume [Mbit/busy hour/Km^2]
Figure 58: Uplink load, service mix
Coefficient Data:
a= -0.1363
b= 8.39E-05
c= 8.16E-10
Value at Y=0.6 8135.76 Mbit/hour/Km^2

Table 50: Uplink load, service mix, target 60%
According to the graph we clearly see that the threshold level for soft
congestion triggering (60% Uplink load) is reached within the interpolation
range, therefore only the best fit is provided. Taking a look at the results,
we see that so far Uplink load is, after Dropping probability, the least
frequent reached KPI threshold.
147
7.2.5 Downlink Transmitted Power
DL_TxPower [dBm]
43.0000
42.0000
Power [dBm]
41.0000
40.0000
39.0000 DL_TxPower [dBm]
38.0000
37.0000
36.0000
35.0000
34.0000
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
hour/Km^2]
Figure 59: Downlink transmitted power usage, service mix
Coefficient Data:
a= 3.68
b= -1.97E-05
c= 3.75E-08
Value when Y=38.7 7360.59 Mbit/hour/Km^2

Table 51: Downlink power usage, service mix, target 38.7 dBm
According to the Figure 60, again the target threshold level (38.7 dBm) is
reached within the interpolation range, therefore only the best fit is
presented. The Downlink transmitted power, which was the main limiting
factor especially for Data Services in the single-service simulations, now it
is still important but in the place after Downlink Channel Elements
utilization according to the simulation results.
148
7.2.6 Downlink Code Tree Usage
0.6000
Code tree usage [%]
0.5000
0.4000
0.3000 DL_Code tree
usage[%]
0.2000
0.1000
0.0000
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
Offered Data Volume [Mbit/busy hour/Km^2]
Figure 60: Downlink code tree usage, service mix
Coefficient Data:
a= 0.009300566
b= 4.19E-05
c= 8.67E-10
Value when y = 0.6 11406.08 Mbit/hour/Km^2

Table 52: Downlink code tree usage, service mix, target 0.6 (60%)
In this experiment, the last simulation presented some errors so the value
corresponding to the highest load had to be discarded and an
extrapolation is provided based on the interpolation of the first four points
of the data set. According to the best fit, the Downlink code tree usage
would be, with the assumed traffic densities, the less important capacity
limiting factor. Next table shows the order of capacity factors according to
the number of supported users, i.e. according to the Figure ODV
149
Kbps/cell. This order would be the order of occurrence of the factors in the
simulated scenario, ordered for lowest ODV Figure (the one that reaches
first the target level) to highest ODV.
KPI Load to reach the target (ODV Kbps/cell)
Blocking probability 257.2904
Iub utilization 300.4381
Downlink Power usage 358.7032
Uplink load 396.4795
Dropping probability 519.4931
Code Tree usage 555.8518
Table 53: Summary Table, capacity limiting factors
The first result is not surprising, as there are many sources that causes
blocking, not only to new calls but also is possible to have some blocking
level for hand-over calls, although the priority to block calls is given to the
non-guaranteed, non-handover calls according to Ericsson RRM
algorithms. The most frequent blocking reasons that were found are as
follows:
• DL transmit power limit exceeded (cell)

• DL Code usage limit exceeded
• 21: DL congestion
• DL ASE usage limit exceeded
Iub Downlink utilization is another expected result, as it was assumed just

1 E1 of capacity between Node B and RNC, from which there is just 1070
Kbps available, which means that few users working at their maximum
data transfer rate would be able to block the complete cell.
Given the presence of Data Services and given that in the conversion of
units the service that presents major contribution in the calculated ODV is
the web service, the Downlink Load, more than the Uplink, is expected to
be one of the most important capacity limitations. In fact, no call blocked
or dropped due to the Uplink load was registered in the simulation output.
About dropping probability, it was expected to be one of the last factors to

happen, mostly because the Ericsson RRM algorithms specify the dropping
of a call as the last action to take to resolve congestion situations, before
dropping can happen, a series of corrective measurements that involves
Down switching of the non guaranteed connections have to be tried in the
system with the aim of freeing radio resources.
150
The surprise was to see the Downlink Code Usage as one of the last
factors. However in this case we must remember that the last part
presented an error so the extrapolation performed may not be accurate.
Simulations with higher loads than the assumed ones are proposed in
order to verify the number for Downlink Code usage.
7.2.7 Perceived user throughput
Web Indoor Application DL Throughput per user
400.0000
350.0000
300.0000
250.0000
Kbps
200.0000 DL Throughput
150.0000
100.0000
50.0000
0.0000
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
Offered Data Volume Mbit/busy

hour/Km^2]
Figure 61: Web indoor application downlink throughput
Web outdoor Application DL throughput per

user
300.0000
250.0000
200.0000
Kbps
100.0000
50.0000
0.0000
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783

hour/Km^2]
Figure 62: Web outdoor application downlink throughput
151
FTP Indoor Application DL Throughput per user
300.0000
250.0000
200.0000
Kbps
100.0000
50.0000
0.0000
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783
hour/Km^2]
Figure 63: FTP indoor application downlink throughput
FTP outdoor Application DL throughput per user
250.0000
200.0000
Kbps
150.0000
50.0000
0.0000
2617.6919
4320.2870
7195.8725
9881.1036
11776.6783

hour/Km^2]
Figure 64: FTP outdoor application downlink throughput
Some conclusions can be drawn by taking a look at the Figures 61 to 64:
The critical value of 100 Kbps is always reached for any of the data
services, between 9881 and 11776 Mbit/hour/Km^2
The performance, in terms of throughput of the indoor and outdoor
users of the respective users is almost equivalent; this shows then
that the 18 additional dBs for the indoor users has more impact on
coverage rather than on capacity.
152
Surprisingly, the performance of the FTP service was lower than the
performance (in Kbps) of the Web service for the given scenario.
This is something that needs to be verified with more simulations in
a further study.
7.3 Power-rule study
The Power Study, with the setup for the homogeneous scenario defined in
Chapter 5, was performed checking the following three Handover
performance indicators. The definition of them is presented here as they
are defined in [WinesTechRef]:
• Pilot Polution [num]: The number of polluting pilots. A pilot is

considered polluting if it is transmitted by a cell in either the
monitored or the detected set and its RSCP level is within a
configurable margin below the best pilot's RSCP level.
• Active Set Size [num] : The number of active cells, i.e. the
number of soft handover branches for the referred UE.
• SHO Blocked_Add_Link [reason]: Reason for a blocked soft

handover Replace Link request for the referred requested cell.
The expected behavior, as it was also mentioned in [Haverkamp-

cpichstudy] is that the unbalance in the power levels caused by the
different downlink losses (and therefore different CPICH levels per each
cell) creates zones where the mobile is forced to transmit with its highest
power even though it is close in distance to a cell where theoretically it
could be connected to, and because of this at some point in time the
power of the mobile is not sufficient and the call is dropped. Additionally,
as it is mentioned in [Ericssonhandover], unbalance in the CPICH powers
causes also bigger zones with Pilot Pollution problems, i.e. zones where
there are many potentially dominant CPICH levels that causes problems
for the receiver to determine which one is the best one and probably
cause ping-ponging effects changing back and forth of best CPICH (high
Handover signaling). Then, preferably only one dominant CPICH per area
should exist. Pilot pollution gives a high average number of active radio
links, which decrease the traffic capacity and reduce the probability that
the UE get all neighboring cells included due to the size limited monitored
set [Ericssonhandover].
153
7.3.1 CPICH Power –Germany Settings
Next Figures show the active set size spatial distribution in the analysis
area (Handover Zones are those with an active size bigger than 1) and the
corresponding histogram. The setup of the experiment was already
described in chapter 5 where details about this experiment and its
purpose can be found.
Figure 65: Active set size (spatial distribution)
Figure 66: Active set size (histogram)
154
Taking a look at the first two graphs, we can see that the active set size
and hand-over areas are symmetrically distributed over all the cells in the
analysis area and the hand-over zones (zones in green and red in the first
zone) are almost equally defined for each cell. Taking a look at the
histogram we can also determine that the soft handover probability is
around 30% (active set size 2 and 3). Thus, so far the system seems to
have almost homogeneously distributed handover zones, even though the
assumed downlink losses were different among some sites.
Figure 67: Pilot Pollution, Germany Settings
The histogram in the previous Figure shows that in nearly 55% of the
cases, there is no pilot pollution at all, and around 30% has 1 pilot and
the rest has up to 3 pilots. According to [Castro], more than 4 pilots with
nearly equal strength start to cause serious problems in the corresponding
area, then according to the histogram the situation is actually quite good
in terms of pilot pollution as nearly 80% there is 1 pilot or not even pilot
pollution at all.
155
Figure 68: Blocked Add Link requests
The previous Figure shows the Blocked soft hand over requests when
trying to add a new link and the main reason. In this case, main reasons,
in order, were Downlink Transmit Power level exceeded, Downlink
congestion and DL ASE usage limited exceed.
7.3.2 NETHERLANDS SETTINGS:
Figure 69: Active set size (spatial distribution)
156
Figure 70: Active set size (histogram)
In the spatial distribution, we cannot see big differences regarding the

same diagram for the German settings. However, taking a look over the
histogram, we can see a slight difference in the Soft Handover cases as
now it is about 34% compared with the 30% with the settings in
Germany.
Figure 71: Pilot Pollution (histogram).
157
Comparing this Figure with the one in Germany, there is a very small
difference in the frequency of no-pollution at all (0.55 vs 0.52), while the
distribution of 1, 2 and 3 pilots is more or less equivalent. That means
that with the assumed level of link losses (up to 4 dBs), there is no big
difference between both settings (Netherlands vs. Germany).
Figure 72: Blocked Add Link requests
Again, the higher number of Blocking was produced between cells 5 and
10. The main reason was “DL transmit power limit exceeded (cell)”.
The main concussion of this study after the comparison of all the graphs
corresponding to the two different settings, is that in the assumed
(symmetric and homogeneous) scenario, with the assumed levels of link
losses (up to 4 dB) there are no significant differences between the PCICH
power rule of The Netherlands and the PCICH power rule of Germany.
Further conclusions can be drawn once the non homogeneous scenario is
analyzed.
7.4 Mobility Study
In this study, one has to create the same Figures per voice service (main
service) and per traffic mix of the third column of the Table 4, but now
with a vehicular mobility profile. Then, one has to compare the results
with the pedestrian profile. The study is aimed to evaluate the impact of
the mobility in the soft-handover algorithm. Other types of handover
(inter-frequency, inter-RAT) are not going to be analyzed.
158
The expected behavior, as mentioned in [Holma2004] is that when mobile
stations are moving at vehicular level (e.g. 50 Km/h), fewer can be
served, the throughput is lower and the resulting loading is higher
than when mobile stations are moving at 3 km/h. However, in coverage
terms, the faster-moving mobile stations experience better quality
than the slow-moving ones, because for the latter headroom is needed in
the mobile transmission power to be able to maintain the fast power
control [Holma].
The better capacity with the slower-moving mobile stations can be

explained by the better Eb/N0 performance. The fast power control is able
to follow the fading signal and the required Eb/N0 target is reduced. The
lower target value reduces the overall interference level and more users
can be served in the network.
To check the expected behavior, we would compare the Figures of

throughput (with the Internet Service using two traffic densities, 12.99
and 25.97 Erl/Km), uplink and downlink load and blocking and dropping
probability with the voice service traffic densities (the reader is invited to
take a look over the excel results with the remaining KPIs for the
vehicular scenario). As the results for the pedestrian profile have been
already shown, only the graphs corresponding to the vehicular profile are
going to be shown in this section. One restriction was found as it was not
possible to test the highest voice traffic density (160 Erl/Km2) because
internal problems with the simulator, therefore all the results are based on
the first 4 points of the dataset.
7.4.1 Blocking and Dropping probabilities (Voice service)
According with the available data from the first 4 traffic densities
simulated, there is no blocking or dropping up to 80 Erl/Km2. With the
pedestrian profile, no blocking or dropping was experienced up to that
traffic density level, and as it was not possible to obtain the simulation for
the 160 Erl/ Km2 vehicular voice users, we cannot make further
conclusions other than the performance, in terms of blocking and
dropping, is similar for both mobility profiles up to 80 Erl/Km2 of voice
service users.
159
7.4.2 Uplink load (Voice service)
Uplink Load [%]

80,00%
70,00%
60,00%
50,00%
UL Noise Rise [%]
vehicular
40,00%
UL Noise Rise [%]
pedestrian
30,00%
20,00%
10,00%
0,00%
10 20 40 80 Traffic De nsity [Erl / Km^2]
Figure 73: comparison of Uplink Load, vehicular and pedestrian mobility profile
In the previous Figure we can clearly see the reduction of capacity per cell
when using a vehicular mobility profile. For traffic densities lower than 20
Erl/Km2 the performance is more or less similar, but the difference
becomes much larger with higher traffic densities. With the highest traffic
density simulated, there is a difference of almost 15% in Uplink Load
between the two profiles. Then the theoretical expected result is
confirmed with the simulation results.
160
7.4.3 Downlink Power usage (Voice service)
Downlink Transmitted Power, Vehicular and pedestrian

profiles
37,6000
37,4000
37,2000
Power level [dBm]

pedestrian
36,8000
DL_TxPower [dBm]
36,6000 vehicular
36,4000
36,2000
36,0000
10,0000 20,0000 40,0000 80,0000
Traffic Density [Er;/Km^2]
Figure 74: comparison of Downlink Load, vehicular and pedestrian mobility profile
In the previous Figure, we see just a slight difference in Downlink

transmitted power between pedestrian and vehicular mobility profiles,
making the comparison up to 80 Erl/Km2 we can say that about Downlink
power, the performance is almost equivalent.
7.4.4 Throughput (Web service)
Comparison Downlink throughput vehicular vs

pedestrian mobility profile, outdoor user
300,0000
Downlink Throughput [Kbps]
250,0000
200,0000
DL Throughput
(vehicular)
150,0000
DL Throughput
(pedestrian)
100,0000
50,0000
0,0000
12,99 25,97
Figure 75: comparison of Downlink throughput vehicular vs. pedestrian profile
In the previous Figure, we can see a better performance of the Downlink

throughput for the pedestrian mobility profile for the range of evaluated
161
traffic densities, around 12 to 18% of difference. The data for indoor users
was discarded because of some inconsistencies but it is proposed to
perform a new simulation series with both UE types and more traffic
densities in order to have a better impression of the throughput
difference. Then, for the range of simulated traffic densities, we confirm
the theoretical result presented in [Holma] about lower throughput for the
vehicular user.
162
7.5.1 Single service experiments
The main findings for Circuit Switched (CS) only-service experiments

(from Voice series) were as follows:
Blocking probability: more simulations with higher traffic loads are

suggested to test the extrapolation results and to try to achieve the
blocking target (1%). The lower range estimation obtained with
extrapolation is in line with the theoretical result obtained via analytical
procedure, as described in [Holma].
Iub utilization: The target level was reached within the simulation range
of traffic densities. For the simulation series, Iub utilization is the 2nd KPI
that is reached first in its target level. 1 E1 circuit was assumed to make
the calculations.
Downlink Power usage: the usage was slightly higher for CS instead of
PS services for the range of simulated traffic densities.
Uplink load: it shows to be more critical for CS rather than PS services

for the simulated traffic density levels.
Dropping probability: More simulations are required to achieve the

target (1%) and verify the estimated values.
Code Tree usage (DL): It is not very critical for CS services according to
the simulation results.
Channel element usage (UL/DL): UL Channel elements target was

reached within the simulations range, DL channel elements target not.
Simulations with higher loads are required to check the estimations and to
try to reach the DL target of 256 within the range of simulated loads.
The main findings for packet switched-only services (from the web service
results) were as follows:
Blocking probability: with sf8Adm parameter set to 1, the simulator

presents unrealistic results because the implementation of the packet
access doesn’t follow exactly the slow start mechanism implemented in
the real networks (this feature is going to be implemented in the next
release of the simulator). With sf8Adm =8 (which means no restrictions
because Ericsson’ histogram admission policy) the number of users per
cell is around 2 which is close to the number obtained by analytical
methods.
Iub utilization: the target utilization is reached with about 2.5 users (5
users with an activity of 50%)
Downlink Power usage: Slightly lower for PS than for CS services
163
Uplink load: Very low levels obtained with the simulated traffic densities.
Experiments with higher loads are proposed in order to reach further
conclusions.
Dropping probability: no dropping due to P3 algorithm (down-switching)
Code Tree usage (DL): It was lower for PS rather than for CS
Channel element usage (UL/DL): for the CE usage in DL, simulations

with higher traffic densities are required to reach further conclusions, for
UL CE usage, around 8 to 12 users reach the target usage of 64 CE.
Throughput: mean value of around 150 Kbps for the range of input
traffic densities.
7.5.2 Traffic mix homogeneous scenario
As traffic densities from different services cannot be added, the unit

chosen to make the analysis was Offered Data Volume, defined as:
ODV = 3600 * Offered Traffic Density * Service throughput * υ
The main results (i.e. KPI ordered by occurrence of its target level) are
summarized in the next table:
KPI Load to reach the target (ODV Kbps/cell)
Blocking probability 257.2904
Iub utilization 300.4381
Downlink Power usage 358.7032
Uplink load 396.4795
Dropping probability 519.4931
Code Tree usage 555.851852
Table 54: List of KPIs organized by order of occurrence of their target levels
7.5.3 Power study
The main concussion of this study after the comparison of all the graphs,
is that in the assumed (symmetric and homogeneous) scenario, with the
assumed levels of link losses (up to 4 dB) there are not significant
differences between the PCICH power rule of The Netherlands and the
PCICH power rule of Germany.
164
7.5.4 Mobility study
It was verified through simulations that when mobile stations are moving
at vehicular level (e.g. 50 Km/h), fewer users can be served, the
throughput is lower and the resulting loading is higher than when
mobile stations are moving at 3 km/h.
165
8. Simulation results Second

Scenario (non-homogeneous)
and comparison with the
homogeneous scenario
The purpose of this chapter is to present the main findings of the
simulation results in the 2nd simulation scenario described in chapter 6 and
make a direct comparison with the simulation results presented in the
previous chapter (ideal homogeneous scenario). This second simulation
series has fewer experiments; therefore the level of detail is somewhat
more restricted than the previous chapter. Only the main findings are
going to be presented, however the reader is invited to take a look at the
Excel annexes where all the information regarding the analyzed KPIs was
registered. The approach is, for the single-service studies, to provide a
comparison with the homogeneous single service studies using the main
KPIs defined for the voice service (KPIs for the circuit switched services)
and comparing the throughput results for the Web-only service in both
scenarios. For the service mix, a comparison between both scenarios is
going to be provided as well, identifying their order according to which KPI
target is reached first. Afterwards, the results of the Power-rule test and
the handover test are presented. To conclude the chapter, the exercise
with the analysis of the impact of the parameter settings in the overall
performance of the UTRAN is presented.
8.1 Summary of the Single-service simulations
8.1.1 Voice Service
8.1.1.1 Preliminary considerations about the Real Scenario

analyses
As is pointed out in [Schneider-2], in a real scenario with non-

homogeneous traffic densities, the analysis is more complex compared
with the homogeneous scenario, as one cell is no longer representative for
the whole network, therefore, ideally one should perform an analysis per
each cell. However, as we have 53 cells in the analysis area and because
of the restrictions in time, it was not possible to make such detailed
analysis. To give an impression of how the KPIs can differ from cell to cell,
a histogram of the Downlink Transmitted Power and the Uplink Load was
created, together with the cumulative density function for all the 5
166
different voice traffic densities. The following graphs illustrate the results
for the maximum of those densities (160 Erl/Km2).
Downlink Transmission Power histogram
6 1
0,9
5
0,8
0,7
4
0,6
Count
count
3 0,5
cum ulative dis tribution function
0,4
2
0,3
0,2
1
0,1
0 0
35,00
35,35
35,7
36,05
36,4
36,75
37,1
37,45
37,8
38,15
38,5
38,85
39,2
39,55
39,9
40,25
40,6
40,95
41,3
41,65
42
Dow nlink Pow er [dBm]
Figure 76: Histogram of the Downlink Transmitted Power per cell, non homogeneous
scenario, 160 Erl/Km2 Voice only users
Uplink Load histogram
7 1
0,9
6
0,8
5 0,7
4 0,6
count
0,5
3 0,4
2 0,3
0,2
1
0,1
0 0
0,00%
4,30%
8,60%
12,90%
17,20%
21,50%
25,80%
30,10%
34,40%
38,70%
43,00%
47,30%
51,60%
55,90%
60,20%
64,50%
68,80%
73,10%
77,40%
81,70%
86,00%
Count
cum ulative dis tribution function
Uplink Load [%]
Figure 77: Histogram of the Uplink per cell, non homogeneous scenario, 160 Erl/Km2 Voice
only users
The next table presents the simulation results of the Downlink Transmitted
Power in each one of the cells within the analysis area, together with the
calculation results of the average and standard deviation of this data set.
167
Cell DL Transmitted power [dBm]

U000751 40.34
U000752 41.21
U000753 36.79
U000791 39.47
U000793 41.37
U000801 40.01
U000802 37.75
U000803 37.99
U009641 36.47
U009642 40.65
U009643 37.37
U011031 37.09
U011032 37.80
U011033 40.98
U011071 41.36
U011072 41.64
U011073 37.89
U011381 41.19
U011382 39.79
U011383 38.47
U014671 36.98
U014672 36.55
U014673 38.58
U030761 41.37
U030762 40.06
U030763 35.96
U030771 40.81
U030772 41.17
U030773 39.63
U030821 37.97
U030822 36.64
U030823 37.22
U030841 37.73
U030842 39.95
U030843 36.76
U030851 36.37
U030852 38.44
U030853 39.43
U032311 40.67
U032312 38.04
U032313 39.77
U035701 37.23
U035702 37.05
U035703 40.47
U046611 40.76
U046612 40.13
U046613 38.12
U051651 36.60
U051652 36.13
U051653 36.29
U052011 38.81
168
U052012 39.52
U052013 39.42
average: 38.80
Std. dev: 1.7321
Table 55: Downlink Transmitted Power levels per cell, non homogeneous scenario
According to what we can see in the Figure 76, nearly 70% of the cells are
in congestion situation (in other words, nearly 30% of the cells have a
power levels below 37.8 dBm which is the congestion limit), so the mean
value of 38.80 dBm and the standard deviation of 1.7321 (from the table
53) are just a rough estimate of the real power levels per cell. We have to
take into account this restriction when performing a complete analysis (for
instance in a concrete area that requires optimization), because with our
mean value assumption we are assuming that for this particular traffic
density, all the cells are in congestion, when the true situation is that
around 70% are in this situation and 30% are not, but this is only possible
to determine only when taking a detailed look at the cumulative
distribution function of each KPI.
The same situation can be observed with the uplink load illustrated in
Figure 77, where near 60% of all the cells have an uplink level below the
target uplink load level (60% of load in the X-axis). When we take the
average Uplink Load (46.73%) we are assuming that the 100% are not in
Uplink load situation but the true situation is that near 40% of the cells
are above the (soft) congestion limit.
Having in mind these restrictions, we proceed to make our analysis based

on the mean values of the whole network inside the analysis area.
Another assumption to make possible this analysis is the cell area size: as
in the homogeneous scenario the plot of the best serving cell shows
different cell sizes (from 900 to 1300 meters), this would lead to an
individual analysis per cell; due the restrictions of time and resources to
do this, the assumed cell area size was calculated simply by dividing the
analysis area size (34.75 Km2) by the number of cells in the area (53)
which gives around 0.65 Km2 per cell; therefore, multiplying this area by
the obtained traffic density that triggers the threshold level, one can
estimate the approximate number of users per cell that can be supported
with good quality. In a more complete analysis, each cell should be
analyzed separately to calculate the real cell area.
The target level of 1% blocking was reached within our interpolation

range, so we present the two-best fits in the next table.
169
Target threshold = 1% (0.01 linear scale)
a= 0.0068
b= -0.00049
c= 5.51E-06
Value with Y=0.01 95.226 Erl/Km^2
Number of Users per cell 62
Linear Fit: y=a+bx
Coefficient Data:
a= -0.0145
b= 0.0004
Value with Y=0.01 53.4073 Erl/Km^2

Table 56: Estimation of the number of users until reaching the blocking target (1%), non
homogeneous scenario, voice only service
As the target blocking was reached within the interpolation range, a

narrower (and more realistic) range was found in the non-homogeneous
scenario, from 35 to 62 users, which is much closer to the theoretical
Figure of 42 users per cell provided by [Holma] than the range obtained
by extrapolation of results with the homogeneous scenario (from 49 to
248 users).
The “real” network experienced higher blocking than the ideal scenario.
The cell layout has strong influence in the handover performance as in this
case the layout is not perfectly hexagonal; indeed higher dropping
probability was experienced because of the blocked radio link additions
(handover event 1A).
The traffic density for the dropping probability target produced around 54
users per cell which is close to the lowest limit obtained in the
homogeneous scenario (61). Besides, according to the RRM expected
behavior, dropping always happens after blocking has been experienced,
so the results are in line with this. However, comparing traffic densities
between both scenarios, the traffic densities to reach the target blocking
and dropping levels are lower in the non-homogeneous case. Making the
exercise of calculating the number of supported users per cell with the cell
area of the homogeneous case (0.1755 Km2 ) with our upper limit from
the non-homogeneous case (95.26 Erl/Km2) would result in around 17
voice users per cell which is low compared with the theoretical value of 42
users. However, in the homogeneous case it was pointed out that more
170
simulations are needed to come up with a better estimation of the number
of supported users per cell.
DL channel elements
160,0000
140,0000 DL Channel
100,0000 [mean]
80,0000
60,0000 DL Channel
20,0000 [max]
0,0000 00
00
00
00
00
0
00
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 78: DL Channel elements usage, voice only service, non homogeneous scenario

UL channel elements
140,0000
120,0000 UL Channel
80,0000 [mean]
60,0000 UL Channel
20,0000 [max]
0,0000
00
00
00
00
00
0
00
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 79: UL Channel elements usage, voice only service, non homogeneous scenario
CE Usage, Downlink
Coefficient Data:
a= 9
b= 0.98891575
c= -0.00183311
Linear Fit: y=a+bx
171
Coefficient Data:
a= 17
b= 0.67270421
CE usage, Uplink
Coefficient Data:
a= -2
b= 0.9889
c= -0.0018
Linear Fit: y=a+bx
Coefficient Data:
a= 4.6884
b= 0.6727

Table 57: Estimation of the number of users until reaching the CE targets (256 DL, 64 UL),
non homogeneous scenario, voice only service
With the non-homogeneous scenario, again the target of 256 DL CE was

not reached within the simulation range and therefore a extrapolated
values from the best-fit analysis are presented, the obtained traffic
densities (223 to 335 Erl/Km2) are more or less in line with the range
obtained in the homogeneous scenario (295 to 334 Erl/ Km2). In the case
of the Uplink, as in the homogeneous scenario, the target was reached
with around 78 Erlangs/Km2 (the corresponding traffic density for the
homogeneous scenario was 73.32). The levels of required traffic density
to reach the target in Uplink are very close in both scenarios.
172
8.1.1.4 Iub utilization
Iub traffic [DL]
700,0000
600,0000
500,0000
Kbps
400,0000
300,0000 Iub traffic [DL]
200,0000
100,0000
0,0000
00
00
00
00
00
0
00
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 80: Downlink Iub utilization, voice only service, non homogeneous scenario
As in the case of the homogeneous scenario, the target level of 1070 Kbps
was not reached with the offered traffic densities, therefore extrapolation
was used. The obtained extrapolation range of the best fit for the non
homogeneous scenario was [102.787, 254.39] Erl/Km2; compared with
the range obtained in the homogeneous scenario [209.9440; 218.8070]
the non homogeneous one exhibits more variation in the results; however
the range coming from the homogeneous scenario is included in the wider
range of the more “realistic” one. In terms of approximate number of
users with our estimation of 0.65 Km2 per cell we get from 66 to 165
voice users per cell to reach the Iub congestion level.
8.1.1.5 Uplink Load
UL Load [%]
50,0000%
45,0000%
40,0000%
Noise Rise [%]
35,0000%
30,0000%
25,0000% UL Load [%]
20,0000%
15,0000%
10,0000%
5,0000%
0,0000%
00
00
00
00
00
00
0
0
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 81: Uplink load, voice only service, non homogeneous scenario
173
The traffic density to reach the target level of 60% Uplink load was not
reached within the simulation range, therefore, applying the analysis over
the best interpolation fits, the range of [201.298, 280.022] Erl/Km2 was
found, which is somewhat different from the range found in the
homogeneous scenario, [130.8437, 182.0143] Erl/Km2, and so is the
expected number of users. This difference can be attributed to the
averaging process mentioned in section 8.1.1.1, where we clearly saw
how our assumption for averaging purposes in the sense that all the cells
are not experiencing congestion, it is not true for almost 40% of the cells
in the realistic scenario. Therefore, interference analysis is quite difficult to
analyze over the whole network as the interference situation is very
particular for every cell and a more complete analysis is proposed for
further studies.
DL_TxPower [dBm]
40,0000
39,0000
Power [dBm]
38,0000
36,0000
35,0000
34,0000
00
00
00
00
00
00
0
0
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 82: Downlink Transmitted power, voice only service, non homogeneous scenario
In this case, the congestion level (38.7 dBm) was found within the
simulation range, therefore, the best fit gave a value of 139.45 Erl/Km2.
The obtained value in the homogeneous situation was in a range from
[184,97; 205] Erl/Km2 but in the homogeneous case it shows more
variation given that the threshold level was not obtained within the
offered traffic densities so extrapolation of the best fit analysis is being
used, which can be somewhat imprecise. The main conclusion of this very
important KPI is that Downlink power usage threshold is reached in the
non homogeneous scenario before than in the homogeneous scenario.
174
8.1.2 Web Service
8.1.2.1 Downlink code tree usage
40,0000%
Code tree usage [%]
35,0000%
30,0000%
25,0000%
DL_Code tree
20,0000%
usage[%]
15,0000%
10,0000%
5,0000%
0,0000%
00
00
00
00
00
00
0
0
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 83: Downlink Code tree usage, voice only service, non homogeneous scenario
Again, as in the case of the homogeneous scenario, the Code Tree usage
level was not reached within the range of the offered traffic densities.
Extrapolation of results in both cases (homogeneous and non
homogeneous) shows similar results [239.89, 258,188] and [213.981,
282.201] Erl/Km2, respectively. Then for voice-only service we see that in
both scenarios there are no problems with Downlink code Tree. We will
then make the same comparison with a PS service (Web service) to
examine Downlink Code Tree usage in some more detail.
8.1.2.2 Downlink code tree usage, Web service
40,0000%
Code tree usage [%]
35,0000%
30,0000%
25,0000%
DL_Code tree
20,0000%
usage[%]
15,0000%
10,0000%
5,0000%
0,0000%
00
00
00
00
00
00
0
0
,0
,0
,0
,0
0,
10
20
40
80
16
Figure 84: Downlink code tree usage, web service only, non homogeneous scenario
175
As it can be seen in Figure 41, the target of 60% Downlink code tree was
not reached with the offered web service traffic densities in the
homogeneous scenario. The extrapolation based on the best fits
interpolation analysis showed a range of [42.9068, 181.145] Erl/Km2. In
the non-homogeneous scenario, the target level of 60% was neither
reached, however the extrapolation results showed a range around
[32.767, 36.3202] Erl/Km2. Therefore, lower traffic density values that
reach the Downlink code tree target were found in the non homogeneous
case. However, these are estimation based on extrapolations, so it is
suggested to try with higher traffic densities in the simulator further
studies to see how the network behaves in terms of Downlink Code Tree
usage.
8.1.2.3 Throughput, Web service
web Indoor Application DL Throughput
300,0000
250,0000
200,0000
Kbps
150,0000 DL Throughput
100,0000
50,0000
0,0000
00
00
00
62
25
49
7
1,
3,
,9
,9
6,
12
25
Figure 85: Downlink throughput, web-only service, non homogeneous

scenario, indoor user
web outdoor Application DL throughput
400,0000
300,0000
Kbps
200,0000 DL Throughput
100,0000
0,0000
00
00
00
62
25
49
7
1,
3,
,9
,9
6,
12
25
Downlink throughput, web-only service, non homogeneous scenario, outdoor

user
176
The target of 100 Kbps as indicator of bad throughput performance was
not reached with the offered traffic densities in the non homogeneous
case (neither was done in the homogeneous counterpart), then the
extrapolation based on the interpolation best fits shows a range of
[37.6249 , 61.3206] Erl/Km2 for Web users indoor and [59.7381,82.0918]
Erl/Km2 for Web users outdoor, which in the case of the homogeneous
was around [18.9152, 23.093] Erl/Km2 for Web users indoor and [51.639;
58.8578] Erl/Km2 for Web users outdoor. Therefore for outdoor web users
of the non homogeneous scenario, the obtained results are similar to the
results in the homogeneous scenario, but for indoor users in the case of
the non homogeneous scenario the Figures are somewhat higher. Again, it
is suggested to test the obtained traffic densities with more simulations to
reach the 100Kbps target within the range of the traffic densities of the
experiments.
8.2 Service Mix
The service mix is going to be analyzed based on the next summary table.
In the case of the presence of ranges ([min [ max]) in the KPIs, only the
more restrictive values (i.e. the lower traffic density that would reach the
KPI target value) have been taken into account for this table.
ODV at target level* (Mbit/busy

KPI target level hour/Km^2)
blocking probability 1% 3868,06
Dropping probability 1% 6041,83
Iub utilization 1070 Kbps 6322,14
DL power usage 38,7 dBm 6646,23
channel elements, UL 64 9146,39
UL Load 60% 12004,6
DL code tree usage 60% 15482,6
channel elements, DL 256 20656

target threshold
177

blocking probability 1% 5279.6000
Iub utilization 1070 Kbps 6033.81
channel elements, UL 64 6518.6300
DL power usage 38.7 dBm 7360.59
UL Load 60% 8052,83
Dropping probability 1% 10660
DL code tree usage 60% 11406.08
channel elements, DL 256 14899.40
threshold
Comparing both tables, the main differences in order are the presence of
the Dropping probability as a second element in the table of non-
homogeneous scenario and the uplink channel elements utilization that
appears before the downlink power usage in the homogeneous scenario.
About the level of ODV, the non homogeneous scenario reaches first its
first target, blocking probability at 1% with 3868.06 Mbit/busy hour/Km2
compared with 5279 of the homogeneous counterpart, but to reach the
last target threshold, the situation is the other way around, the target is
first reached at 14899,40 Mbit/busy hour/Km2 in the homogeneous
scenario, whereas the non-homogeneous scenario reaches this threshold
at 20656 Mbit/busy hour/Km2. Then we can say, according to the
simulation results, that in the realistic scenario, the first threshold is
reached before the homogeneous level (then the homogeneous level is
giving somewhat optimistic values for this first KPI), but to reach the last
KPI threshold, DL channel elements, the homogeneous scenario results
somewhat pessimistic as with the realistic scenario the target is reached
at a higher level of ODV.
Going a bit further when trying to explain why in the homogeneous

scenario we had more dropping, the following reasons where found:
With the traffic mixes with up to 160 Erl/Km2 of voice users (and the
corresponding densities for the rest of services given as the 5th column in
the Table 4), the main reasons for dropping, in the non homogeneous
scenario, were as follows:
• 14: Blocked radio link addition
• 21: DL congestion
178
Especially with the highest traffic densities, those two reasons were the
main ones and 41 out of the 53 cells had these problems (although with
different number of occurrences per cell).
Therefore, we can think that the asymmetry of the non homogeneous

scenario (compared with the perfect “cookie cutter” grid of the
homogeneous one) was the reason for the difference of place of the
dropping probability threshold between the two scenarios, because the
fact that sometimes when performing handovers the situation of Blocked
radio link addition can happen in the realistic scenario and then high
dropping (compared with the ideal case) is experienced. In the
homogeneous study, this reason (Blocked radio link addition) was found,
but less frequently, and only starting with the mixes from 80 and 160 Erl/
Km2 for voice users (and the other corresponding densities for the other
services specified in the columns of Table 4). An analysis removing the
worst-performing cells is also suggested to get more conclusions about
this fact.
8.3 Power study, Traffic Densities for Germany and

The Netherlands
As it was done in the previous chapter, the performance for each rule is
going to be measured by the active set size and the pilot pollution. The
next Figure shows a histogram with the active set size and Pilot pollution
histogram with the power rule applied in Germany:
Figure 86: Active set size and Pilot pollution histograms, Germany power rule
179
From the previous Figure, we can appreciate a handover probability of

50% (active set size 2 and 3) and a very low Pilot pollution indicator as
nearly 90% of the number of pilots is below 3.
Figure 87: Active set size and Pilot pollution histograms, Netherlands power rule
As in the homogeneous scenario, the differences in active set size and

polluting pilots are clearly not significant; therefore we can conclude that
even in the non-homogeneous scenario, the Power Rule of both countries
gives equivalent performance due to the low Downlink losses (less than 4
dB).
8.4 Mobility study
Analogous to the section 7.4, the Uplink Load and the Downlink
Transmitted Power are going to be compared for both pedestrian and
vehicular profile in the non-homogeneous scenario using the voice service,
and the throughput performance is going to be compared for both profiles
with the traffic mix simulation with voice traffic density 40 Erl/Km2 (and
the corresponding traffic densities for the other services as they were
specified in Table 4). The expected theoretical behavior regarding the
difference in performance between vehicular and pedestrian profile is the
same one explained in the section 7.4.
180
8.4.1 Uplink load (Voice service)
comparison UL Load -vehicular vs pedestrian profile [%]
50.0000%
45.0000%
40.0000%
Uplink load [%]
35.0000%
30.0000% UL Load, vehicular [%]
25.0000%
20.0000% UL Load, pedestrian [%]
15.0000%
10.0000%
5.0000%
0.0000%
00
00
00
00
00
0
00
.0
.0
.0
.0
0.
10
20
40
80
16
Figure 88: comparison Uplink Load pedestrian vs. vehicular mobility profiles
As it can be seen in the previous figure, the Uplink load for a vehicular
profile was slightly higher in the range from 20 to 80 Erl/Km2 but with the
load of 10 and 160 Erl/Km2 the levels obtained were almost equal. As the
target of interference load in uplink (60%) was not reached in both
homogeneous and non homogeneous scenario, more simulations with
loads higher than 160 Erl/Km2 are proposed in order to reach further
conclusions about the Uplink load for both profiles, but for the simulated
range it is clear that the Load is, on average, lower for the pedestrian
than from the vehicular profile, as it was expected.
Also in the homogeneous scenario the differences in load between both

profiles showed an increasing trend with the increase of traffic densities,
i.e. the difference found in Uplink load for both profiles was bigger for
bigger traffic densities. This trend was not observed in the non
homogeneous scenario, as the load for each cell is not the same on
average (some cells have higher load than other ones, whereas in the
homogeneous scenario the load is almost equal in all the cells within the
analysis area).
181
8.4.2 Downlink Power usage (Voice service)
comparison DL_TxPower [dBm] vehicular vs pedestrian mobility profile
40.0000
39.0000
Power [dBm]
38.0000 DL_TxPower [dBm]
37.0000
DL_TxPower [dBm]
36.0000 pedestrian
35.0000
34.0000
10.0000 20.0000 40.0000 80.0000 160.0000
Figure 89: comparison Downlink Transmitted Power, vehicular and pedestrian mobility
profile
Comparing this Figure with the corresponding one in the homogeneous

case, the difference in Power levels between both profiles is larger in the
non-homogeneous case, and in overall the consumed power is lower for
the pedestrian profile, as it was also theoretically expected.
8.4.3 Downlink Throughput
UE Profile DL Throughput DL Throughput

[kbps], vehicular [kbps], pedestrian
profile profile
FTP UE indoor 168.62 175.0435182
FTP UE Outdoor 165.40 195.8084226
Internet UE indoor 165.24 192.7750935
Internet UE outdoor 183.67 196.7226692
Video call indoor 62.79 63.04505226
Video call outdoor 62.63 63.03418639
voice UE indoor 11.93 11.93639358
voice UE outdoor 11.93 11.9366576

Table 60: Downlink Throughput levels for all services, traffic mix with voice 40 Erl/Km2,
non homogeneous scenario
182
Comparing each entry in the table, we can clearly see that for this
particular traffic mix with the specified traffic densities in the 3rd column of
Table 4, the Downlink throughput perceived by the user is always higher
for the pedestrian profile (packet switched services). For the circuit
switched service the registered throughput is the same as those services
(Speech and Video call) have guaranteed service bandwidth.
8.5 Analysis of the impact of a parameter setting in

the overall performance of the UTRAN
This part of the study is going to be performed with one of parameters

that have not been harmonized between Vodafone Global and Vodafone
Netherlands settings. Similar approach can be taken to analyze any other
parameter with different values (levels) and under different traffic load
conditions.
Applying the technique of two-factor analysis explained in [Jain] (in this

concrete case, the two factors are the traffic load and the parameter being
tested), the Ericsson RRM parameter TimetoTrigger1a (minimum time to
trigger event 1A (radio link addition)) is going to be analyzed with 5 (or
less, i.e. in case that some of them are the same value) possible values:
• Minimum value of the parameter

• Maximum value of the parameter
• Default Value (given by Ericsson)
• Value in The Netherlands
• Value in Vodafone Global
The 5 different levels of workload correspond to the 5 columns in the table

4 (traffic mix with different increasing traffic densities). Semi-dynamic
mode for voice users was used to speed up simulation times. In this test,
for indoor users the mobility profile was defined as pedestrian and for
outdoor users the mobility profile was configured as vehicular.
The required number of experiments (simulations) for the analysis of each

parameter with this method is number of workloads (5) * number of
levels of the parameter which would be (at most) 5 levels = 25
simulations per parameter.
8.5.1 The parameter Timetotrigger1a and its influence on

the Handover algorithm
As it is well known, Handover is a fundamental RRM algorithm that

supports the mobility of users and enable the interoperability between
different radio systems (e.g. between UMTS and GSM).
183
As it is mentioned in [Handoverthesis], a handover is generally performed

when the quality of the link (measured in terms of the power of the
received pilot) between the Node B and the UE on the move is decreasing
and it is possible to hand over the connection to another cell with better
radio characteristics. In previous 2G systems like GSM, the handover
process tears down (i.e. literarily interrupts the connection for a short
period of time, not noticeable by the end user) an existing connection and
replaces it with a new connection to a new cell where the user is handed
over with a different frequency (concept known as “hard handover”). This
cell where the user is handed over is so-called the “”target” cell. Since all
cells in W-CDMA use the same frequency, in 3G systems it is possible to
make the connection to the new cell before leaving the current cell and
keeping always at least one radio link with a Node B. This concept is
known as "soft" handover. Hard Handover however, is also used in 3G
systems when it is needed to change the frequency of the carrier, either
performing inter-frequency handover (i.e. change of UMTS carrier
frequency for balancing load purposes) or performing Inter-RAT (Radio
Access Technology) handover from UMTS to GSM.
In summary, in 3G systems there are two new handover concepts: Soft

and Softer handover, and they basically mean that it is possible to keep
two or more concurrent connections with different Node Bs (Soft
handover) or with the same Node B (e.g. when multi-path propagation
between the UE and Node B makes the Node B to receive the signal sent
from the UE from two different sectors). In both soft/softer handover,
the UE always keeps at least one radio link to the UTRAN. Both
concepts are illustrated in the next Figure.
1
B
de
No
r 1
c to
Se
Sector Node B
2 2
RNC
RNC
Softer Handover Soft Handover
Figure 90: Differences between Soft and Softer Handover
To keep track of the number of connections, the concept of the Active Set
is required. The Active Set, as it is defined in [Ericssonhandover], is the
set of cells used for a particular UE connection. The UE has a radio link
184
established to each of the cells present in its Active Set. This set is
updated dynamically (event based) during all the time that a connection is
alive, based on the measurements of the strength of the Primary Common
Pilot Channel (P-CPICH) Ec/Io or the Primary Common Pilot Channel (P-
CPICH) RSCP (Received Signal Code Power).
Ec/Io can be defined in terms of RSCP in the following way:
Ec/Io = RSCP/RSSI (8-1)
Where RSCP is the power (measured in the UE) carried by the decoded
pilot channel and RSSI (Received Signal Strength Indicator) is the total
wideband received power (measured in the UE) within the channel
bandwidth.
So basically, during a user service session, there are these possible events
related to Active set updating (using the name of the events described in
[25.922]:
• Event 1A : add new cell

• Event 1B : remove cell
• Event 1C : replace cell (if the active set is full)
• Event 1D : change best cell
Best Cell, according to [Ericssonhandover], is defined as the cell, among

the ones in the Active Set, having a measured P-CPICH with the highest
quality Ec/No.
From a Node B’s point of view, an incoming handover request is similar to

an incoming call, although the RRM algorithms can differentiate whether
the request comes from a Handover Connection or not, as it is the case in
the Ericsson RRM algorithms. Given that using handover in an appropriate
way leads to an improvement in capacity because of the soft hand over
gain, the handover connections have less probability to be blocked than
new incoming non-handover calls. This feature can be seen clearly in all
the Ericsson Diagrams where different thresholds for blocking are set
depending if the connection is guaranteed (e.g. voice) or not guaranteed
(e.g. Web), handover or non handover (i.e. new request) call. The inability
to establish a new connection in the target cell is referred to as a
“handover failure” and it occurs when no new resources are available in
the target cells or when the radio link quality has decreased below
acceptable levels before the call could be handed-over [Handovertesis].
The first reason leads to Handover Blocked attempts and the last one
leads to Handover Dropped attempts and both are good measures of the
Handover Performance in the network.
The parameter Timetotrigger1a, as documented in [Ericssonhandover]

is a timer that represents the minimum time required to trigger the
Event 1a. Event1a represents the Addition of a new cell to the
active set. The Handover Algorithm example in [25.922] is presented
185
again here, pointing out when the Timetotrigger1a parameter is used, to

illustrate how the cell addition works. For the description of the Soft
Handover algorithm the following parameters are needed:
- AS_Th: Threshold for macro diversity (reporting range);
- AS_Th_Hyst: Hysteresis for the above threshold;
- AS_Rep_Hyst: Replacement Hysteresis;
- ∆T: Time to Trigger;
- AS_Max_Size: Maximum size of Active Set.
Equivalent to Timetotrigger 1A
.
∆T ∆T ∆T
Measurement
Quantity CPICH 1
As_Th + As_Th_Hyst
AS_Th – AS_Th_Hyst
As_Rep_Hyst
CPICH 2
CPICH 3
CPICH 2 >
CPICH1 – Time
(AS_Th –
AS_Th_Hyst) Event 1A Event 1C ⇒ Event 1B ⇒
Cell 1 Connected for a time > ⇒ Add Cell 2 Replace Cell 1 with Cell 3 Remove Cell 3
∆t→Add Cell
Figure 91: WCDMA handover example [3gpp25.922]
As described in the Figure above:
- If Meas_Sign is below (Best_Ss - As_Th - As_Th_Hyst) for a period of ∆T

remove Worst cell in the Active Set (Event 1B).
- If Meas_Sign is greater than (Best_Ss – (As_Th - As_Th_Hyst)) for

a period of ∆T and the Active Set is not full add Best cell outside the
Active Set in the Active Set (Event1A).
- If Active Set is full and Best_Cand_Ss is greater than (Worst_Old_Ss +

As_Rep_Hyst) for a period of ∆T add Best cell outside Active Set and
Remove Worst cell in the Active Set (Event 1C).
186
Where:
- Best_Ss :the best measured cell present in the Active Set;
- Worst_Old_Ss: the worst measured cell present in the Active Set;
- Best_Cand_Set: the best measured cell present in the monitored set.
- Meas_Sign :the measured and filtered quantity.
The “hysteresis” parameter is defined as a sort of “guard band” in order to

avoid event triggering due to insignificant measurement fluctuations.
Event-triggered periodic measurement reporting is setup for event 1a and

event 1c. This means that if the UE sends a report to UTRAN and the UE
does not get any ACTIVE SET UPDATE message, the UE will start to report
the same event every repInterval1a until the Active Set is updated, or
until the condition for event triggering is not valid anymore.
When a MEASUREMENT REPORT message is received at the SRNC from

the UE, and the MEASUREMENT REPORT message has been triggered on
event 1a, Soft/Softer Handover evaluation algorithm (SHO_Eval)
processes the report and evaluates if the proposed candidate can be
added to the Active Set.
After knowing the working principle of the Soft Handover algorithm we

could say that event1a affects the handover performance in the following
ways:
According to Ericsson, too short settings for this timer cause update
events of the active set to occur too quickly after each other, leading to
high signaling load, and in the other hand too long settings cause that
although the criteria have been fulfilled, the active set will not be updated.
Less optimal cells will be used which leads to unnecessary interference.
This will waste UTRAN resources.
Additionally, Ericsson mentions that if this parameter is changed without

complete knowledge of all system internal interactions the effects may be
unexpected and fatal. They also mention that most radio networks are
non-homogeneous and a change of a parameter value does not
necessarily have the same effect on the UE or RAN in all parts of the
network.
It is important to remember that the measurements used for handover

event evaluation is made on the downlink CPICH. This means that using
different settings for primaryCpichPower (power assigned to the CPICH)
on neighboring cells will create a more complicated interference situation.
8.5.2 The Analysis framework
The experiment setup was done according to the Design Technique called
“Two-factor full factorial design without replications” presented in [Jain].
187
This means that we use two variables (or factors) which are carefully
controlled and varied to study their impact on the performance. In our
case, these two variables are the Traffic Densities (corresponding to the 5
columns of the Table 4) and the parameter TimetoTrigger1a with its
possible levels. The following Table shows the levels (values) chosen for
this parameter.
Minimum Value 0 millisecond
Value from Vodafone Netherlands 200 millisecond

(same as default value)
Value from Vodafone Global 320 milliseconds
Maximum value 5000 millisecond

Table 61: Chosen levels for the parameter Time to Trigger 1A
Once the input variables have been chosen, we have to define the output
variables, i.e. the “measured” data as referred in [Jain], although in this
case there is not measured data as such but simulated. Knowing the
expected behavior from Ericsson, we can monitor the performance in
terms of:
Uplink Interference Load [%]

Soft Handover Attempts [num]
Each of the indicators is provided by the simulator so an independent

analysis for each one was performed, i.e. wit was constructed a different
matrix and ANOVA (Analysis of Variance) Table for each one of these two
indicators. The statistical ANOVA Test calculations are greatly simplified
using the Microsoft Excel Data Analysis Pack, which implements the tests
“ANOVA: Two factors without replication” and “ANOVA: Two factors with
replication”. The difference between both analyses is the number of
repetitions for each experiment, in our case, due to time restrictions only
one experiment was performed per each combination of input levels.
To make the analysis, the Data has to be organized in a matrix where

each column represents each of the parameter Timetotrigger1a levels
(named factor A in this description) and each row represents the different
levels of traffic densities (identified as Mix1_10Erl, Mix2_20Erl,
Mix3_40Erl, Mix4_80Erl and Mix5_160Erl respectively, named factor B in
this description). Each entry in the matrix, Yij, represents the response in
the experiment where factor A is at level I and factor B at level j. For
instance, Y12 would be equivalent in our setup to Y (Minimum Value,
Mix2).
188
The “grand mean” µ is obtained by averaging all observations. Averages
per rows and columns are also required. Once these averages are
calculated, the “column effect” or αj (effect of the factor A at value j) are
obtained by subtracting the “grand mean” from each column mean, and
the Bi or row effects (effect of the factor B at value i) are calculated in the
same way, subtracting the “grand mean” from each row mean. This gives
us a first indication about how different is the performance for each of the
parameter/load alternatives regarding the average performance
represented by µ.
Next step is to build the matrix of the estimated response, defined as:
Yˆij = µ + αj + Bi (8-2)
Once this is defined, the Error Matrix can be found by subtracting position
to position the estimated response matrix from the “measured” response
matrix. Each entry of the error matrix is defined as follows:
Errorij = Yij (measured) - Yˆij (8-3)
As the values of the µ, αj’s and Bi’s are computed such as the error has
zero mean, this matrix has the property that the sum of all the entries in
a row or column must be zero.
Next step is to calculate the sum of squared errors (SSE) which is defined
as
SSE = Σ (eij2) (8-4)
Where this sum is performed including all entries in the error matrix.
Next, the total variation SST (which is different from the total variance) is
calculated as:
SST = SSA + SSB + SSE (8-5)
Where:
• SSA = b * Σ (αj)2 where b= number of rows
189
• SSB = a Sum (Bi)2 where a=number of columns
At this point, we can also calculate the percentage of variation explained

by each factor (which should be higher than the percentage of variation
explained by errors to consider that a parameter has a significant impact
in the performance). The percentage of variations by each factor is
defined as:
Percentage of variation explained by A = SSA/SST
Percentage of variation explained by B = SSB/SST
Percentage of variation explained by errors =SSE/SST
To statistically test the SIGNIFICANCE of a factor, we must divide the sum

of squares by their corresponding degrees of freedom (Df). In this case,
the corresponding Dfs are:
• SSA Df = (a-1)
• SSB Dfs = (b-1)
• SSB Errors = (a-1)*(b-1)
The degrees of freedom of the factors A and B are because the errors in
each column should add 0 and in each row as well and for the errors the
degrees of freedom is the product of DfA and DfB.
Next we proceed to calculate the mean squares of all factors as follows:

MSA = SSA / (a-1) (8-6)
MSB = SSB / (b-1) (8-7)
MSE = SSE/ ((a-1)*(b-1)) (8-8)
At this point we can also calculate the Standard Deviation of each of the
factors:
SSE = STANDAR DEVIATION OF ERRORS = √(MSE) (8-9)
Standard DEVIATION µ = Se/ (ab) (8-10)
Standard DEVIATION αj = Se* √ ((a-1)/ab) (8-11)
Standard DEVIATION Bi = Se √ ((b-1)/ab) (8-12)
190
Variance of each factor = (Standard deviation of the factor)2 (8-13)
After mean and variance of each parameter are known, a confidence

interval (defined as a function of the mean and the standard deviation)
can be calculated using statistical methods.
The last part is to calculate the F-ratios to test the statistical significance
of the factors (a systematic confirmation from the previous results based
on a statistical test). F-ratios are defined as follows:
Fa = MSA/MSE (8-14)
Fb = MSA/MSE (8-15)
Then, the factor A is considered significant at level alpha (significance

level, an alpha 0.05 is defined for a 95% confidence interval) if the
computed ratio is more than FcritA = F[1-alpha,a-1, (a-1)(b-1)], where F
is computed from the table of quantiles of F variates. Accordingly, the
factor B is considered significant at level alpha if the computed ratio is
more than FcritB = F[1-alpha,b-1, (a-1)(b-1)] from the table of quantiles
of F variates. All these values are conveniently arranged by Excel so after
knowing the procedure, we would present the results and provide the
conclusions using the criteria presented.
8.5.3 Simulation Results
First of all, we are going to show the original matrices with the
“measured” results with the Uplink Interference Load and the Soft
Handover Attempts. Next two tables illustrate the original matrices.
min-level Netherlands level global level (320 max-level (5000

(0 msec) (200 msec) msec) msec)
MIX1_10Erl 199 191 191 174
MIX2_20Erl 2132 403 424 372
MIX3_40Erl 1240 879 873 1785
MIX4_80Erl 3019 1777 2704 1658
MIX5_160E 139329 8282 7202 2770

rl
Table 62: Original table for ANOVA, Cell HO attempts
191
min-level netherlands level (200 global level (320 max-level (5000

(0 msec) msec) msec) msec)
MIX1_10Erl 10.27% 10.20% 10.18% 10.47%
MIX2_20Erl 20.30% 20.44% 20.52% 20.95%
MIX3_40Erl 42.32% 43.02% 42.61% 47.21%
MIX4_80Erl 72.99% 77.48% 73.75% 76.90%
MIX5_160Erl 88.61% 89.38% 90.02% 90.28%
Table 63: Original table for ANOVA, Uplink Load
Next, we show the Analysis of Variance after applying the Excel Data
Analysis Toolkit over the original tables and afterwards we draw the main
conclusions.
8.5.3.1 Analysis of Variance (ANOVA)
the results obtained for each measured response (i.e. Handover attempts
and Uplink Load interference) after applying the ANOVA-2 factor without
replication analysis were as follows:
Source of Variation SS df MS F F crit
Rows 4695850801 4 1173962700 1.33424525 3.25916
Columns 2778331540 3 926110513.2 1.052553504 3.4903
Error 10558442984 12 879870248.7
Total 18032625325 19
Table 64: ANOVA of Handover attempts, additive model
Rows 1.866556606 4 0.466639151 3032.14678 3.25916
Columns 0.001438522 3 0.000479507 3.115761269 3.4903
Error 0.001846767 12 0.000153897
Total 1.869841895 19
Table 65: ANOVA of Uplink load, additive model
192
The ROWS factor corresponds to the different traffic densities (5 levels)
and the COLUMNS factor corresponds to the 4 levels of the parameter
time to trigger 1a (0.200. 320 and 5000 msec). The columns are
respectively:
• SS = Squared Sum of each factor

• Df = degrees of freedom (number of independent terms to obtain
the Squared Sum)
• MS = Mean Square value = SSparameter / Dfparameter
• F = Computed F factor = MSfactor /MSE where MSE is the Mean
Square Error (SSE/Dferror).
According to the ANOVA test of the Handover attempts (table 62), the
percentage of variation explained by each factor is as follows:
• Percentage explained by Rows (load) = SSrows / SStotal = 26%

• Percentage explained by columns (time to trigger levels) =
SScolumns/SStotal = 15 %
• Percentage explained by errors = SSerrors/ SStotal = 59%
According to this first calculation, from the point of view of VARIATION

(which is not the same as variance), the time to trigger level of the set of
performed experiments is not significant. This was confirmed when
checking the obtained F (MScolumns/MSerror) for the Time to trigger
parameter, which is not higher than the Fcrit in any of the response
variables, therefore, with the assumed additive model, one cannot confirm
the statistical significance for the columns (time to trigger levels). This is
an indication that some transformation of the output variable must be
tried in order to reduce the variance of the data. In fact, taking a look at
the Maximum output / Minimum output ratio, specially in the Handover
Attempts output variable, one can see that is rather high compared with
the order of magnitude of the data obtained: in this case [Jain] suggests
to try a logarithmic transformation over the output data (multiplicative
model). The multiplicative model with two factors assumes a model as it is
described in the next equation:
Yij = Vi * Wj (8-16)
If we take logarithm at both sides, we have an additive model:

Log (Yij) = Log(Vi) + Log(Wj) (8-17)
In the case of two-factor experiments, the additive model assumed so far

was:
Yi = µ + αj + Bi + eij (8-18)
If we assume a logarithmic transformation, this means that the model

would be:
Log (Yi) = Log µ + Log αj + Log Bi + Log eij (8-19)
Therefore, the output in linear fashion would be:
193
µ αj Bi
Yi = 10 * 10 * 10 * 10 eij (8-20)
Where µ, αj , Bi ,eij are obtained from the ANOVA 2-factor analysis

performed over the Logarithm of each one of the output levels. The
transformed Tables for both variables and the corresponding ANOVA test
are shown below.
min-level (0 netherlands level (200 global level (320 max-level (5000

msec) msec) msec) msec)
MIX1_10 2,298853076 2,281033367 2,281033367 2,240549248

Erl
MIX2_20 3,3287872 2,605305046 2,627365857 2,57054294

Erl
MIX3_40 3,093421685 2,943988875 2,941014244 3,25163822

Erl
MIX4_80 3,479863113 3,249687428 3,432006687 3,219584526

Erl
MIX5_160 5,14404152 3,918135226 3,857453117 3,442479769

Erl
Table 66: Logarithm transformation of the measured variable Handover attempts
min-level (0 netherlands level (200 global level (320 max-level (5000

msec) msec) msec) msec)
MIX1_10 -0.99 -0.99 -0.99 -0.98

Erl
MIX2_20 -0.69 -0.69 -0.69 -0.68

Erl
MIX3_40 -0.37 -0.37 -0.37 -0.33

Erl
MIX4_80 -0.14 -0.11 -0.13 -0.11

Erl
MIX5_160 -0.05 -0.05 -0.05 -0.04

Erl
Table 67: Logarithm transformation of the measured variable Uplink load
194
Rows 2,041006383 3 0.680335461 19,62286238 4,757055
Columns 0.017800402 2 0.008900201 0.256707802 5,143249
Error 0.208023309 6 0.034670552
Total 2,266830094 11
Table 68: ANOVA of Handover attempts with the multiplicative model
Rows 0.745806368 3 0.248602123 1768,122551 4,757055
Columns 0.00070624 2 0.00035312 2,511480684 5,143249
Error 0.000843614 6 0.000140602
Total 0.747356222 11
Table 69: ANOVA of Uplink load with the multiplicative model
Again, the obtained F for the levels of the parameter time to trigger is not
higher than Fcrit, therefore with the multiplicative model it is not possible
either to guarantee statistical significance. In the chapter 15 of [Jain]
there are a list of graphical tests to determine which kind of
transformation would be required, three of these tests were tried but the
criteria to apply the given transformation were not fulfilled with the
collected information. Therefore, due to the limitations of time and
resources of this project, this verification with more transformations in
order to reduce the variance of the experiment is still open. It is also
suggested to perform more than one simulation per each traffic density
level and then apply the ANOVA 2 factor analysis with replication, which
was not possible in this project due to the limitations of time and
hardware.
Therefore, to conclude the analysis of the given parameter another

approach also mentioned in [Jain] is going to be used. This method is
particularly useful when the goal of the experiment is simply to find the
best combination of factor levels (the combination that produces the best
performance). The name of the method is the Ranking method and
consists to organize the experiments in the order of increasing or
decreasing responses so that the experiment with the best response is
first and the worst response is last. Then, the factor columns are observed
to find levels that consistently produce good or bad results.
195
For this analysis, the best experiment is defined as the one with the
lowest handover attempts measurement and the lowest uplink load.
Therefore, we present below a table where the rows have been sorted in
order of increasing number of handovers and increasing uplink load:
experiment Load time to trigger HO attempts UL Load
16 MIX1_10Erl 5000 174 10.47%
11 MIX1_10Erl 320 191 10.18%
6 MIX1_10Erl 200 191 10.20%
1 MIX1_10Erl 0 199 10.27%
17 MIX2_20Erl 5000 372 20.95%
7 MIX2_20Erl 200 403 20.44%
12 MIX2_20Erl 320 424 20.52%
13 MIX3_40Erl 320 873 42,61%
8 MIX3_40Erl 200 879 43,02%
3 MIX3_40Erl 0 1240 42,32%
19 MIX4_80Erl 5000 1658 76,90%
9 MIX4_80Erl 200 1777 77,48%
18 MIX3_40Erl 5000 1785 47,21%
2 MIX2_20Erl 0 2132 20.30%
14 MIX4_80Erl 320 2704 73,75%
20 MIX5_160Erl 5000 2770 90.28%
4 MIX4_80Erl 0 3019 72,99%
15 MIX5_160Erl 320 7202 90.02%
10 MIX5_160Erl 200 8282 89,38%
5 MIX5_160Erl 0 139329 88,61%
Table 70: Ranking method applied over the simulation outcomes
The first interesting thing that we can notice in Table 68 is that in the
Load column, nearly all the experiments are ordered from the lowest load
(10 Erlangs) to highest Load (160 Erlangs) including all the time to trigger
levels per each traffic load level (exception made with the experiments 2,
18 an 4 that can be attributed to random errors in the simulator).
Therefore the effects of the increased traffic load on the system
196
performance, measured in terms of Hand-over attempts and Uplink Load,
can be seen: the highest load, the worse.
Taking a look at the second column, we can observe the pattern 5000.
320. 200 and 0 (with the 320 and 200 alternating position in some cases)
in mostly all the table. Again, variations of this pattern can be attributed
to experimental errors in the simulator.
Then, we can appreciate that for the same level of traffic load, the worst
results in terms of Handover Attempts are with the value 0 for the Time to
trigger parameter. So we clearly discard this setting as the best value
among the proposed four.
Next, we take a look at the values of Handover Attempts and Uplink Load
for the value 5000 of Time to Trigger: Although in some cases the number
of handovers is the lowest with this setting (as in the experiment 16), the
Uplink Load with this parameter, for the same traffic density, is the
highest (experiment 16 and 20. for instance). Therefore, this setting has a
tradeoff with the Uplink Load and it is also not the best option for the best
value among the proposed 4.
Next, we start making comparison of the levels 200 and 320. In order to
do this, the following table has been constructed, removing all the levels
corresponding to the values 0 and 5000 of the parameter Time to Trigger:
experiment Load time to trigger HO attempts UL Load
11 MIX1_10Erl 320 191 10.18%
6 MIX1_10Erl 200 191 10.20%
7 MIX2_20Erl 200 403 20.44%
12 MIX2_20Erl 320 424 20.52%
13 MIX3_40Erl 320 873 42,61%
8 MIX3_40Erl 200 879 43,02%
9 MIX4_80Erl 200 1777 77,48%
14 MIX4_80Erl 320 2704 73,75%
15 MIX5_160Erl 320 7202 90.02%
10 MIX5_160Erl 200 8282 89,38%
Table 71: Ranking method removing the two worst options
Now we have the table ordered by Handover attempts and Uplink Load
and it is also automatically ordered by Load levels, which simplifies our
197
analysis because now we can count the times that one parameter is better
than the other for each level of traffic density. The results of this
examination by each traffic level are shown in the next table. For doing
the evaluation, we have to assume that the main factor is the number of
handover attempts and then if this level is the same, the next factor to
consider is the Uplink load. However, this assumption is left to be
validated statistically in further studies.
Time to trigger =200 is the Time to trigger =320 is the

best best
MIX 10 Erl 0 1
MIX 20 Erl 1 0
MIX 40 Erl 0 1
MIX 80 Erl 1 0
MIX 160 Erl 0 1
COUNT 2 3
Table 72: Main results for the analysis of the parameter Time to trigger 1a
Therefore, according to our assumption in the order of the outputs, the

parameter 320 has better performance having into account the number of
handover attempts and the Uplink Load. Of course this is an informal
method that has to be combined with more simulations with different
traffic densities or the same traffic densities but with different
transformation in order to reduce the variance and then to be able to
guarantee the results in statistical way providing the corresponding
confidence intervals for the factors.
198
8.6 Summary, chapter 8
Some findings from the comparison of results homogeneous vs. non

homogeneous scenario:
In a complete analysis of a given non-homogeneous scenario, each cell

should be analyzed separately in order to calculate the level of
interference, downlink power usage and cell area.
8.6.1 Circuit switched services (voice service)
The target blocking (1%) was reached within the interpolation range,
which is narrower than the one obtained in the homogeneous scenario
simulations. The interpolation range, close to the theoretical value of 42
users [Holma] goes from 34 to 62 voice users per cell for the non-
homogeneous scenario.
Dropping probability
The non-homogeneous scenario experienced higher blocking than the

homogeneous scenario. It was found that the cell layout has strong
influence in the Handover performance, and as it is not perfectly
hexagonal, higher dropping is experienced because of blocked radio link
additions.
Channel Elements usage
With the non-homogeneous scenario, the target of 256 DL CE was not

reached within the simulation range and therefore extrapolated values
from the best-fit analysis were presented. In the case of the Uplink, the
target was reached within the simulation range and the corresponding
traffic density was 78 Erlangs/Km2 (compared with the 73.32 Erlangs/Km2
for the homogeneous scenario).
Iub utilization, Downlink
The results in the non-homogeneous scenario exhibit more variation in

terms of this KPI, more simulations with higher traffic densities and
repetitions per each experiment are proposed in order to reduce the
variation.
Uplink Load
Uplink load is somewhat different from the range found in the

homogeneous scenario, but this was expected because in the non
homogeneous scenario, the distribution of load is not the same through all
the cells in the analysis area (due to the presence of zones with more
199
traffic than the others). However, simulations with higher traffic loads are
suggested in order to reach the threshold (60%).
Downlink power
Downlink power usage threshold is reached in the non homogeneous

scenario much before than in the idealistic case (homogeneous).
Downlink code tree usage
For voice-only service we see that in both scenarios (homogeneous and

non homogeneous) there are not many problems with downlink code tree
usage within the range of simulated traffic loads.
8.6.2 Packet Switched Services
Throughput
For web users outdoor the results are similar in both scenarios, but for
indoor users, in the non homogeneous scenario the figures are somewhat
better (i.e. the target threshold of 100 Kbps is reached after the
corresponding traffic density level for the homogeneous scenario). This
means that according to this specific non homogeneous scenario
configuration, indoor users experienced better throughput than their
homogeneous counter part.
8.6.3 Traffic Mix Analysis
Next table shows the KPIs ordered by which traffic density reaches first its
target level:

Blocking probability 1% 3868.06
Dropping probability 1% 6041.83
DL power usage 38,7 dBm 6646.23
Channel elements,
UL 64 9146.39
UL Load 60% 12004.6

target threshold
200
Blocking probability 1% 5279.6000
Channel elements,
UL 64 6518.6300
DL power usage 38,7 dBm 7360.59
UL Load 60% 8052.83
Channel elements,
DL 256 14899.40
threshold
Comparing both tables, the main differences in order are the presence of
the Dropping probability as a second element in the table of non-
homogeneous scenario and the uplink channel elements utilization that
appears before the downlink power usage in the homogeneous scenario.
We can think that the asymmetry of the non homogeneous scenario

(compared with the perfect “cookie cutter” grid of the homogeneous one)
was the reason for the difference of place of the dropping probability
threshold between the two scenarios. Most of the dropping was due to
blocked radio link additions.
8.6.4 Power study
As in the homogeneous scenario, the differences in active set size and

polluting pilots are clearly not significant; therefore we can conclude that
even in the non-homogeneous scenario, the Power Rule of both countries
gives equivalent performance due to the low downlink losses (less than 4
dBs).
8.6.5 Mobility study
The difference in Downlink Power levels between both profiles (pedestrian,

vehicular) is larger in the non-homogeneous case, and in overall the
consumed power is lower for the pedestrian profile, as it was also
theoretically expected.
201
8.6.6 Analysis of the impact of a parameter setting in the

overall performance of the UTRAN
With the common approach (additive model), the ANOVA test doesn’t give
statistical significance to the levels of Time to Trigger parameter for the
analyzed set of experiments. Three more transformations were evaluated,
however the statistical significance was not found. More transformations
should be applied in order to reduce the variance and provide the
corresponding confidence interval for the analyzed parameters. A result
based on informal methods (applying the so-called “ranking” method
described in [Jain]) is provided and the conclusion is that the 320
milliseconds setting for the Time to Trigger 1a parameter has the best
performance of all the 4 tested levels, but this is something that has to be
guaranteed statistically (more simulations with perhaps different traffic
density settings must be tried).
202
9. Conclusions and future
work
This section is aimed to present the main conclusions of the work and also
to discuss the open issues and future work after this project is finished.
9.1 Single Service Analysis
9.1.1 Circuit switched services, homogeneous scenario
The next two tables summarize the main results for the Voice and Video
call services:
No. of users to reach the

KPI Target Level target
CE UL 64 13
UL Load 60% 16
DL power 38.7 dBm 36
Iub 1070 Kbps 37
DL code tree 60% 42
Blocking prob 1% 49
CE DL 256 52
Dropped prob 1% 62
Table 75: Ordered KPIs by number of users to reach the target, Voice-0nly service
KPI Target Level No. users to reach the target Traffic density level
UL Load 60% 3 17,46
CE UL 64 3 17.74
DL power 38.7 dBm 3 19.55
DL code tree 60% 5 27.1968
Iub 1070 Kbps 6 32
Blocking prob. 1% 6 32.19
CE DL 256 9 49.7967
Table 76: Ordered KPIs by number of users to reach the target, Video call-only service
203
For the single-service scenario analysis, it can be observed that for both
circuit-switched services the capacity is mainly Uplink Limited (UL Load
and CE UL are the first two KPIs to reach their target levels). DL Power is
the third main capacity limiting factor and CE DL seems to be the one of
the least significant factors. Special attention must be paid to the CE UL
because it is also one of the main limiting factors for packet-switched
services as well. More experiments are required with the Video Call service
in order to present more conclusions about the dropping probability. Iub
utilization in Downlink and Downlink code tree usage, have intermediate
importance according to the simulation results.
9.1.2 Packet switched services, homogeneous scenario
KPI Target No. users to

Level reach the
target
Blocking 1% 2
prob.
DL Iub 1070 Kbps 5
DL power 38.7 dBm 8
CE UL 64 8
DL 100 kbps 12
throughput
(outdoor)
UL Load 60% 13
DL code 60% 16
tree
CE DL 256 30
Dropping 1% No dropping
probability was
experienced
Table 77: Ordered KPIs by number of users to reach the target, Web-only service
204
KPI Target No. Traffic
Level users to Density
reach Level
the
target
Blocking 1% 1 4.1627
prob.
DL Iub 1070 1 5.0550

Kbps
DL power 38.7 1 6.7843

dBm
Dropping 1% 1 8.1450
prob.
CE UL 64 2 9.83
DL code 60% 3 14.2658

tree
UL Load 60% 5 30.363
CE DL 256 6 34.234
Table 78: Ordered KPIs by number of users to reach the target, FTP-only service
For the Packet Switched Services with the current threshold settings
(Blocking probability level set to the same level for voice service), the
Blocking Probability is the first KPI to reach the target. Theoretically,
allowing a higher Blocking Probability for PS services would increase the
capacity of the cell and this should be possible to implement, given the
characteristics of the packet-switched transmission which doesn’t put high
requirements about low delays.
After blocking probability, Downlink Power and DL Iub utilization seem to

be the next most important capacity limiting factors. Downlink CE usage
seems to be one of the last threshold levels to be reached. Therefore,
according to the results, the capacity in Packet Switched services is mostly
Downlink limited, as it was expected due to the high asymmetrical data
rates in Downlink for both services.
Among the two simulated PS services, the main difference is the place of
the Dropping Probability, in the Web Service no dropping probability was
found with the simulated traffic loads (and therefore no estimation was
possible for the load that reaches the 1% threshold); however, as it was
mentioned before, this is in line with the RRM channel switching
algorithms (switching from DCH to FACH), when the Web users can still
keep the connection with data rates of 32 Kbps without been dropped by
the system, as it happens with the FTP users that keep using mostly the
205
DCH channels. However, in order to get more realistic results, new

simulations have to be performed when the simulator includes the slow
start mechanism which has a direct impact in the blocking and dropping
probabilities.
9.2 Service Mix analysis
Next section presents the main conclusions of the comparison between

the service mix experiments in both scenarios (homogeneous and non-
homogeneous). The next two tables summarize the results.

blocking probability 1% 3868,06
Dropping probability 1% 6041,83
Iub utilization 1070 Kbps 6322,14
DL power usage 38,7 dBm 6646,23
channel elements, UL 64 9146,39
UL Load 60% 12004,6
DL code tree usage 60% 15482,6

target threshold

blocking probability 1% 5279.6000
channel elements, UL 64 6518.6300
DL power usage 38.7 dBm 7360.59
UL Load 60% 8052,83
channel elements, DL 256 14899.40

threshold
206
According to both tables, capacity in both scenarios (homogeneous, non
homogeneous) is mostly Downlink Limited when all the services are
working together (i.e. Downlink Power target level occurs before than the
Uplink Load target level). DL Code tree usage and DL channel elements,
however, seems to be the last KPI to be reached. Iub utilization seems to
be also an important factor to be considered given that the assumption
made of just 1 E1 link between each Node B and the RNC (Iub interface)
gives this factor the 2d place (homogeneous) and 3rd place (non
homogeneous) in the order of the KPIs that are reached first.
Comparing both tables, the main difference in order is the presence of the
Dropping probability as a second element in the table of non-
homogeneous scenario.
The main reasons for dropping, in the non homogeneous scenario, were
as follows:
14: Blocked radio link addition
21: DL congestion
Especially with the highest traffic densities, those two reasons were the
main ones in 41 out of the 53 cells in the analysis area.
Therefore, we can think that the asymmetry of the non homogeneous

scenario (compared with the perfect “cookie cutter” grid of the
homogeneous one) was the reason for the difference of place in the order
of the KPIs of the dropping probability threshold between the two
scenarios.
9.3 Power rule usage, homogeneous and non-
No significant differences were found with the two analyzed CPICH Power
rules in both homogeneous and non-homogeneous scenarios, therefore
the performance of the handover in terms of active set size distribution
and pilot pollution zones is equivalent, provided that the Downlink Path
loss between the Node B output port and the Antenna connector for all the
node Bs in the analysis area is below 4 dB.
9.4 Mobility study, homogeneous and non-

In both scenarios (homogeneous, non homogeneous) the results are in

line with the theoretical expected behavior: when mobile stations are
moving at vehicular speed (e.g. 50 Km/h), fewer can be served, the
throughput is lower and the resulting loading is higher than when mobile
stations are moving with pedestrian profile (assumed speed of 3 km/h).
207
9.5 Analysis of the parameter Time to Trigger 1A
The best setting (out of the four levels tested) was found using the
“Ranking” method and it corresponds to 320 milliseconds, although no
statistical significance could be derived using the ANOVA test with the
current load levels.
9.6 Open Issues and Further research topics
Besides the proposed verification of the estimations provided by

mathematical fits, it would be interesting to test capacity improvement
mechanisms that are possible to simulate with Wines Dynamic simulator,
among them:
• Inter-frequency Handover (definition of a second carrier)

improvements
• Inter-system Handover (Handover to GSM) improvements,
comparison of the performance in a network where all the Speech is
carried in GSM but all the data services are carried in UMTS
• Comparison on the performance of the network with a fixed traffic
density for circuit switched service and variable traffic densities for
packet switched services.
• Comparison on the performance of the network with different traffic
mixes
• HSDPA improvements in cell capacity
• Definition of a Second Scrambling code in a cell
Additionally, some other studies can be performed with the Simulator

following the same methodology applied on this thesis, for instance,
parameter analysis with different levels (e.g. Vodafone Global Settings,
Vodafone Netherlands Settings, Max and Min Values), especially those
parameters that have a strong dependency on time (e.g. handover timers)
which are not possible simulate with snapshot (static) simulations. A
verification of the simulator results with measurements from the live
network is also important to perform.
208
References
[21.905] 3GPP. Vocabulary for 3GPP Specifications (TR 21.905 v 6.9.0). Sophia Antipolis,
June 2005.
[25.331] 3GPP, Radio Resource Control (RRC), Protocol Specification (TS 25.331 V6.4.0),
Sophia Antipolis, December 2004
[25.922] 3GPP, Radio resource management strategies (Release 6) (TR 25.922 V6.1.0),
Sophia Antipolis, May 2005.
[25.942] 3GPP, Radio Frequency (RF) system scenarios (Release 6) (TR 25.942 V6.4.0),
Sophia Antipolis, March 2005
[30.03] 3GPP. Universal Mobile Communication Systems (UMTS); Selection procedures for
the choice of radio transmission technologies of the UMTS (UMTS 30.03 version 3.2.0). TR
101 112 V3.2.0. Sophia Antipolis, 1998.
[34.108]3GPP, Common test environments for User Equipment (UE), Conformance Testing
(TS 34.108 V5.3.0), Sophia Antipolis, December 2004
[Alcatel] O. Aydin et al. UMTS Radio Network planning guideline. Alcatel, Ludwigsburg,
Germany, 2001.
[Anntena-saunders] Simon R. Saunders. Antennas and Propagation for Wireless

Communication Systems. Wiley, UK, 1999.
[ATOLL] ATOLL: Technical Reference Guide, Version 2.1.3, Forsk, 2004.
[Castro] Jonathan P. Castro. The UMTS Network and Radio Access Technology: Air Interface
Techniques for Future Mobile Systems. Wiley, England, 2001.
[curveexperthelp] Daniel Hyams. Curve Expert 1.3 Help, 2001
[Dinan] Esmael Dinan, Aleksey Kurochkin and Sam Kettani. UMTS Radio Interface System
Planning and Optimization. Bechtel Telecommunications Technical Journal, Volume 1,
Number 1, p 1 – 10. 2002.
[Ericsson-capacity] Various authors .Capacity Management WCDMA RAN User Description.

Document 73/1551-HSD 101 02/1. Ericsson AB, 2004
[Ericssonhandover] Various authors. Handover WCDMA RAN User Description and

Engineering Guidelines. Document 75/1551-HSD 101 02/1. Ericsson AB, 2004.
[ericssonpowercontrol] Various authors. Power Control WCDMA RAN User Description.

Document 74/1551-HSD 101 02/1. Ericsson AB, 2004.
[Eurescom] Eurescom Project 921- D2. Guidelines For UMTS Radio Access Network Design
(summary). http://ftp.eurescom.de/~public-web-deliverables/P900-series/P921/D2/index.html
209
[Exportingatolltowines] WiNeS Atoll™ Synchronization Module (ASM) version 3.2.

Radioplan GmbH, Dresden, Germany, 2004.
[Handoverthesis] Stijn N. P. Van Cauwenberge. Study of soft handover in UMTS (Master

Thesis). Danmarks Tekniske Universitet, Denmark, July 2003.
[Haverkamp-cpichstudy] Bert Haverkamp. CPICH balance study. Traffic modeling group

Vodafone NL, Maastricht, The Netherlands, October 2004.
[Holma] Harri Holma and Antti Toskala. WCDMA for UMTS, Radio Access for Third
Generation Mobile Communications (3rd Edition). Wiley, Chichester, England, 2004.
[Holmathesis] Harri Holma. A study of UMTS terrestrial radio access performance (PHd.
Thesis). Helsinki University of Technology, Department of Electrical and Communications
Engineering, Espoo, Finland, 2003.
[ITU] Philippe Mege. Document 1-HNB-SM/50-E. Chapter 3 (frequency assignment and

licensing), Addendum 1: IMT 2000/ UMTS Radio Planning Procedures. International
Telecommunication Union, Radiocommunication Study Groups, Switzerland, 2003.
[Iub-observability] Greg Vourekas. Iub Observability via STS Counters. Vodafone

Netherlands, Maastricht, The Netherlands, 2004.
[Jaber] Mona Jaber, Syed Ammar Hussain and Adel Rouz. Modified Stochastic Knapsack for
UMTS capacity analysis. Fujitsu Science and Technology Journal number 38Vol 2, p. 183-
191, 2002.
[Jain] Raj Jain. The art of computer systems performance analysis. Techniques for
experimental design, measurement, simulation, and modeling. Wiley, Massachusetts, United
States, 1991.
[Laiho] Jaana Laiho, Achim Wacker. Radio Network Planning Process and Methods for
WCDMA. Nokia Networks, Finland, 2001
[Madder] Andreas Mäder, Dirk Staehle. Analytic Modelling of the WCDMA Downlink
Capacity in Multi-Service Environments (Technical Report No. 330). University of Wurzburg,
Institute of Computer Science, Wurzburg, Germany, April 2004.
[Mathforinternet] Walter Willinger and Vern Paxson. Where Mathematics Meets the Internet.
Notices of the American Mathematical Society Volume 45, Number 8, p. 961-970. 1998.
[Moret] Alexandre Moret, Silmar Palmeira and Phil Jones. EbNt versus BLER
characterisation – Results. Vodafone Group Plc Confidential, July 2004.
[Ramsden] Edward Ramsden. Imitating Life: An Introduction to Computer Simulation and

Modeling. Sensors Magazine Online, http://www.sensorsmag.com/articles/0502/14/, May
2002.
[RRMEricsson] WiNeS Dynamic Network Simulator Module, Radio Resource Management

(RRM) Algorithms Library Version 3.3 – Ericsson. Radioplan GmbH, Dresden, Germany,
2005.
[Schneider-1] Peter Schneider, Determination of the UMTS Cell Capacity – Part 1. Vodafone
D2, Düsseldorf, Germany, July 2004
210
[Schneider-2] Peter Schneider, Determination of the UMTS Cell Capacity – Part 2. Vodafone
D2, Düsseldorf, Germany, January 2005.
[Staelhe2004] Andreas Mäder and Dirk Staehle. Uplink Blocking Probabilities in

Heterogenous WCDMA Networks considering Other-Cell Interference (Technical Report No.
333). University of Wurzburg, Institute of Computer Science, Wurzburg, Germany, May
2004.
[Umts-forum6] UMTS/IMT-2000 Spectrum (Report number 6). UMTS Forum, London,

England, 1998.
[Wedontknow] Vern Paxson and Sally Floyd. Why we don’t know how to simulate the
internet. Proceedings of the 1997 Winter Simulation Conference, Network Research Group,
Lawrence Berkeley National Laboratory, University of California, Berkeley, U.S.A., p 1037 –
1044, 1997.
[Winessnapshot] J. Deißner, J. Voigt. WiNeS Snapshot Network Simulator Module

Technical Reference Version 3.3. Radioplan GmbH, Dresden, Germany, 2005.
[Winestechref] WiNeS Dynamic Network Simulator Module, Technical Reference Version

3.3. Radioplan GmbH, Dresden, Germany, 2005.
[Winesuserguide] J. Deißner, J. Hübner, D. Hunold, D. Stachorra, J. Voigt. User Guide for

WiNeS Control Center User version 3.3. Radioplan GmbH, Dresden, Germany, 2005.
211
1. Appendix: UMTS
fundamental concepts
1.1 What is UMTS?
UMTS (Universal Mobile Telecommunications System) represents the

choice for the 3rd Generation Global Mobile Communications System in
several countries/regions including almost all European countries, Japan
and Australia. 3rd Generation mobile communication systems are intended
to provide advanced global services to the customer, either circuit-
switched (e.g. speech and new services like video calls) or packet-
switched, new mobile multimedia services (e.g. streaming/mobile TV,
location based services, Downloads, multi-user games and many more)
giving more flexibility for the operator to introduce these new services to
its portfolio and from the user point of view, more service choices and a
variety of higher, on-demand data rates compared with current 2-2.5G
mobile systems. The “global” feature means that the system is designed
to reach global coverage (if required) through the use of Satellite Links,
Macro-cells, Micro-Cells and Pico-Cells.
From the Standards point of view, UMTS is a mobile communications

system standardized by the 3GPP and the specifications are at the present
time in their Release Number 6. The mobile operators that bought 3G
licenses in Europe have already deployed their UMTS W-CDMA (Wideband
CDMA: the chosen multiple access technology for UMTS) based networks,
although the coverage is still not comparable with the currently huge,
transnational coverage of GSM-GPRS networks. In fact, at least in the first
years of deployment, UMTS networks are going to rely on GSM networks
to reach zones where there is still no UMTS coverage, using a technique
called Inter-RAT (RAT: Radio Access Technology) handovers.
About the UMTS services, some commercial services have been available
for the general customers, in the concrete case of The Netherlands, since
the last year.
1.2 Technical characteristics
Technically speaking, the radio-access part (also called “the air interface”)
is the most important difference regarding to the so-called 2-2.5G
systems (e.g. GSM, GSM+GPRS). Instead of using the FDMA-TDMA
combination (i.e. carriers and timeslots per carrier) as the access
technology like in GSM, UMTS uses Wideband-CDMA, a technology based
on the Direct Sequence (DS) Spread Spectrum principle. Direct Sequence
makes reference to the usage of a special code to separate the signals
(opposite to “frequency hopping” which is the other Spread Spectrum
1
method and which is used for instance in Bluetooth technology). Spread

Spectrum means that because of the special signal processing method of
CDMA, the original information signal is spread in the frequency domain
within the wider frequency range of the W-CDMA channel.
In W-CDMA Systems, users belonging to a cell are separated by codes

(i.e. special sequences of bits) and not by timeslots as in TDMA (timeslots
in W-CDMA systems are not used for user separation, but to support
periodic functions, e.g. UE reception of power control commands each
timeslot).
Another characteristic of W-CDMA is that the users share the complete

frequency spectrum of near 5 MHz per UMTS channel all the time during
their communication.
In general, in CDMA systems, the way the uplink (i.e. mobile station to
base station transmission) and downlink (i.e. base station to mobile
station transmission) connections are separated is referred either by FDD
(Frequency Division Duplex) or TDD (Time Division Duplex) modes
respectively.
For the UMTS public mode (W-CDMA), the choice has been the FDD mode,
which uses different frequencies for both uplink and downlink (i.e. the
mobile transmits in one frequency and receives in another). FDD is used
for large outdoor cells because it can support more users than TDD mode.
TDD uses the same frequency but different timeslots for each type of
connection (UL-DL) and W-CDMA in TDD mode is intended to provide
private indoor low-range communications.
In practice, an operator needs 2 to 3 channels (2x5x2 or 2x5x3 MHz) to

be able to build a high-speed, high-capacity network, probably using a
layering approach, such as the so-called Hierarchical Cell Structure (HCS)
scenarios, using different carriers for micro-cells and macro-cells. In the
next graph, we can see the allocated spectrum in the concrete case of The
Netherlands [Umtsworld].
Figure 1-1: Allocated UMTS spectrum in The Netherlands
About the code usage, it is important to mention that CDMA requires two
kinds of codes for its operation: channelization (spreading) code and
2
scrambling code. The usage of these codes depends on the direction of
the communication (in Uplink, the transmitter is the mobile whereas in
Downlink the transmitter is the Base station). The purpose of the
channelization (spreading) codes in both UL and DL directions is to
separate channels from a single transmitter, whereas the purpose of the
scrambling codes is to separate transmitters (also applies to both UL and
DL directions).
The main difference in the frequency domain between both kinds of codes
is that the Scrambling codes don’t modify the bandwidth of the
Information Signal, whereas the channelization codes do. As this is
something very important in order to understand how UMTS works, in the
next section the code usage is explained both in UL and DL.
1.3 Channelization (Spreading) codes
In UL direction (UE transmits and Node B receives), channelization codes

are used to separate physical data and control (i.e. signaling) channels
from the same terminal. In DL (Node B transmits, UE Receives),
channelization codes are used to separate connections to different users
within one cell (users of the cell are sharing the “code tree” of that cell,
that is, the pool of DL code resources of the tree). Once a channelization
code is applied to the information signal, the Bandwidth of the information
signal changes (in frequency domain) to a higher bandwidth, in other
words is “spread” over the UMTS bandwidth channel (hereby the name of
“spread spectrum”).
In time domain, the effect is the change of rate of the information signal.
To distinguish from the Information Rate, 3GPP calls the Rate of the
channelization code as the Chip Rate, although physically the chips are
also bits (although of higher frequency (smaller period) than the data or
information bits). Therefore, after the channelization code is applied to the
information signal, the result is a signal with a bit rate equal to the chip
rate (the reference chip rate in UMTS is fixed to 3.84 Megachips / sec, and
varying the number of chips per information bit we obtain different user
speeds). The next figure helps to clarify the effects of the channelization
code in both frequency and time domain.
3
Bandwidth of baseband
Power
Bandwidth
after spreading
1 f
Voltage
-1 t
Figure 1-2: Effects of the channelization code in Time and Frequency domain
The codes used for the channelization operations must have a special
property called orthogonality. Orthogonal code means that the inner
product of the code with the codes from the other users (called cross-
correlation property) or the product of the code with a shifted version of
the code itself (called auto-correlation) has to be as small as possible.
These codes are also known as OVSF (Orthogonal Variable Spreading
Factor) codes.
For orthogonality to work, the signals must be properly synchronized in

time. That’s why in DL for instance, due to multi-path propagation, some
of the orthogonality property is lost. This is had into account in CDMA
capacity equations with the so-called orthogonality factor, which is a
factor that varies between 0 (full orthogonality, no interference) and 1 (no
orthogonality, full interference)*.
The number of chips used for each data bit is known as the spreading
factor (SF). Also, in the frequency domain, SF = W / R, where W =
Bandwidth of the spread signal [Hz] and R = Bandwidth of baseband data
[Hz].
Summarizing, in Time Domain:
SF = Chip Rate / Data Rate coded channel (A1.1)
And also, in Frequency Domain:
SF = W / R (A1.2)
*: This definition is in line with the definition in Wines simulator documentation. However in some
other references, for instance [Holma], 0 means no orthogonality and 1 means full orthogonality.
Where Data Rate coded channel means that this data rate has into account
the overhead introduced by coding techniques and it doesn’t corresponds
4
directly to the information rate (unless the coding factor is 1 of course).
This is important to know because it is a common source of mistakes in
calculations.
If we have a low spreading factor it means that it is consuming more code

resources from the code tree and the bit rate is higher, for instance with
SF = 8, the data rate of the spread signal would be 480 Kbps, whereas
with SF=256, the data rate of the spread signal would be 15 Kbps.
Therefore, in Downlink, the number of codes (given by the maximum SF)
is a scarce resource that can be in shortage and therefore must be
carefully considered in any capacity analysis.
1.4 Scrambling codes
Scrambling codes separate different mobiles (in uplink) and different

Node-B cells/sectors (in downlink). This is a code that does not affect the
transmission bandwidth which was already transformed by the usage of
the channelization code. The codes used for scrambling codes are known
as Gold codes and there are two versions (long and short) depending on
the features of the terminal/Node B either one or another version is used.
In Uplink, the number of codes available is in the order of millions of
codes (that guarantees no code shortage when trying to separate the
transmitting users), but in Downlink this number is limited to 512;
otherwise the cell-search procedure shouldn’t be possible to solve in a
reasonable time.
Finally, in the reception side the same transmitter’s channelization code is

applied and that allows the receiver to reconstruct the original transmitted
signal. W-CDMA also involves a certain degree of security, in the sense
that without the transmitter’s channelization code available, it is almost
impossible to reconstruct the original signal, thus preventing tampering
attacks in the air interface.
Summarizing, the following schematic illustrates in a simple way the

process of transmission and reception in UMTS involving all the elements
mentioned.
Data bits TX RX Recovered

SIDE SIDE bits
Transmission medium Σ
Spreading Scrambling Scrambling Spreading

code code code code
Figure 1-3: Simplified Transmission and Reception process in UMTS
5
As the radio access part has changed with respect to previous 2-2.5G
systems as GSM-GPRS, new methods have to be developed to estimate
capacity and coverage of the W-CDMA system.
1.5 The processing Gain, SIR (Signal to Interference

Ratio) and Eb/No concepts in UMTS [Vourekas]
Consider a single-cell CDMA system with N users where ideal power

control is applied and consequently the signal from all the users reaches
the node B demodulator with the same intensity S (figure 1-4).
N users
Figure 1-4: Derivation of the SIR and Eb/No relationship
The demodulator of the Node B processes one desired signal S, and N-1
interfering signals with total power equal to S*(N-1). The desired signal is
shown in the graph as a continuous line and the rest in dotted lines. The
interference sums up to (N-1)* S.
The signal-to-interference power ratio, denoted SIR, is then:
S 1
SIR = = (A1.3)
(N − 1)S (N − 1)
The bit energy to noise ratio, denoted as Eb/No, is obtained by dividing the
signal power by the information (baseband) bit rate, and the interference
power by the total RF frequency.
6
S
EB R 1 Wrf
= = ⋅ (A1.4)
N o ( N − 1)S ( N − 1) R
Wrf
In the last part of equation (A1.4), the first term is equal to the signal to
interference ratio (as defined in equation A1.3) and the second term is
defined as the processing gain:
TotalSpreadBandwidth Wrf
Gp = = (A1.5)
InformationBitRate R
Comparing (A1.5) with (A1.2), we see that the definition of Gp is

equivalent to the definition of SF. The processing gain is a Gain achieved
at the receiver during the de-spreading process and it is due to the fact
that the W-CDMA receiver can sum-up coherently the multiple copies of
the original data generated by the multi-path propagation, by means of a
special receiver technique known as Rake Receiver. Therefore, making the
equivalence between SF and Gp, we can say that the high data rate
transmissions have low processing gain (low spreading factor).
From the equations (A1.3), (A1.4) and (A1.5), we derive a relationship

between the SIR and Eb/No that also involves the processing gain. So after
de-spreading process:
Eb
= SIR ⋅ GP (A1.6)
No
In another form:
1 Eb
SIR = ⋅ (A1.6.1)
GP N o
Equation (1.6.1), when the quantities are expressed in dBs, becomes:
Eb
SIR = − Gp (A1.7)
No
The following figure summarizes graphically this physical process.
7
W
W
Tx
antenna
RF output
f
0 f0
f0
Rc W= 5MHz
Data, Rb
Spreading Noise &

Code Ec/Io + Gp = Eb/No, in dB interfering
signals
or SIRtarget + Gp = Eb/No in dB
W
Eb/No
Rx Ec/Io
RF input antenna This is
negative!
f
f0 0
Rc
Data, Rb
W= 5MHz
Spreading
Code
Figure 1-5: Physical meaning of SIR and Eb/No [Vourekas]
To put a practical example: consider a speech signal with a bit-rate of

12.2kbps. So Rb=12.2 kbps and Rc= 3.84 Mchips/sec. Then the processing
gain of the signal is:
⎛R ⎞ ⎛ 3.84 ⋅10 6 ⎞
G p = 10 ⋅ log⎜⎜ c ⎟⎟ = 10 ⋅ log⎜⎜ 3 ⎟
(
⎟ = 10 ⋅ log 3.15 ⋅10 2 = 25dB )
⎝ Rb ⎠ ⎝ 12.2 ⋅10 ⎠
After despreading, the baseband (own) signal needs to be typically a few

dB above the interference and noise power. This required signal power
density above the noise power density after despreading is designated as
Eb/No. This quantity is of capital importance because the quality targets
are always expressed as a function of Eb/No as can be seen in the
analysis presented in [Castro] where the Bit Error Rate probability is
derived in terms of this figure. As the quality targets are expressed as
function of Eb/No , the CDMA equations regarding capacity also use this
important figure as it is going to be shown in a later section.
The required signal power density below the interference power density
before despreading is designated as SIR (Signal to Interference Ratio),
and it is also known as Ec/Io (In fact, Ec/Io and Ec/No are the same thing.
3GPP just had to use different nomenclature than the IS-95 community).
8
For speech service Eb/No is typically in the order of 5dB. That means that
after despreading the resulting baseband signal must be 5dB above noise
in order to be successfully reconstructed at the decoder. Therefore, the
required wideband SIR must 5 dB minus the processing gain. This follows
also from equation A1.7.
SIR“target” = 5dB-25dB = -20dB.
In other words:
SIR + G p = Eb / N o ⇒
⇒ −20dB + 25dB = 5dB
(Gains or ratios that are expressed in dBs can be added and subtracted.
In the dB scale multiplication is translated into addition).
But, what exactly does SIR of –20dB mean? It means that the signal can
be buried far below the interference. In fact for our example the chip
power density signal is 100 times smaller than the noise +interference
level.
⎛E ⎞ ⎛E ⎞ E 1
10 ⋅ log⎜⎜ c ⎟⎟ = −20dB ⇒ log⎜⎜ c ⎟⎟ = −2 ⇒ c = 2 ⇒ N o = 100 ⋅ Ec
⎝ No ⎠ ⎝ No ⎠ N o 10
Thus the required wideband SIR is so tolerant that the signal can be
buried in interference of a power density that is 100 times larger! Still is
that SIR good enough for the signal to be recovered. Compare this with
the 9 to 18 dBs of SIR required for good voice quality in GSM systems
[Holma].
As we have seen so far, within any given channel bandwidth (chip rate)
we will have a higher processing gain for lower user data bit rates
than for high. With high data rates some robustness of the WCDMA
against interference is clearly compromised.
Summarizing, we have to remember the equation (all quantities in dBs):
SIRtarget + Gp = Eb/No (A1.8)
Expressed in dB the received SIR is negative. It is then multiplied with the

processing gain, an addition in dB scale. If now the processing gain is not
large enough the resulting Eb/No will be too small and will not “rise” above
the interference. In case the Eb/No < 0 there is no detection at all.
9
This fact gives us the first impression of why the Interference levels in the
network are so important in the radio planning process of UMTS systems,
because if the interference level is high in some cells (because the
interference contribution of many users sharing the air interface and
probably using different data rates), then the Eb/No level of some links is
not going to be enough to make their signal to “rise” above the
interference level and therefore the call would be dropped (i.e. the
capacity in terms of number of supported users per cell is modified) and
the cell-size (coverage) would be reduced (phenomena known as “cell
breathing” effect). This is the main reason why in UMTS capacity and
coverage planning cannot be separated processes, as it can be done
for instance in other mobile systems such as GSM where first predictions
of the path loss are evaluated in order to ensure the coverage of the
desired area, and then capacity is dimensioned as a second step (capacity
in a GSM cell it is given by the number of available channels, which is a
function of the reuse factor and the number of carriers per cell [Umts-
forum6] and therefore the sensitivity level at the base stations (i.e. the
minimum power level of the incoming signal at the receiver in order to be
detected) can be assumed as a constant.
On the contrary, in UMTS the sensitivity of the base stations is a random

variable that depends on the number of users and the bit rates / services
being used at any given time, then it is clear that capacity influences
coverage and a separate planning of capacity and coverage cannot be
performed, as the interference should be taken into account already in the
coverage prediction.
1.6 UMTS Architecture (Rel99)
The following section aims to introduce shortly the network elements and
interfaces of the UMTS architecture (Release 99), including UTRAN and
Core Network. The Core Network however, it is presented here just for the
sake of the architecture completeness but its analysis is out of the scope
of this study.
10
CS
Networks
(PSTN,
UE UTRAN CN
CS-Domain
Iub Iu-CS
Node B MSC/V GMSC
RNC
.... HLR
Iub Iur
Node B RNC ... Iu-PS
SGSN GGSN
Uu ....
Iub
(air interface) PS-Domain
Node B
Simulation PS
Scope Networks
(Internet..)
Figure 1-6: UMTS Architecture (Rel-99)
UE (User Equipment)
The UE, as defined in [21.905] is the mobile equipment with one or

several UMTS Subscriber Identity Modules (USIMs). Therefore, the UE
consists of two parts, the ME which is the radio terminal itself, and the
USIM which is the “smartcard”, analog to the SIM cards of the GSM
phones but with some advanced extra-features (secure downloading of
applications, possible inclusion of payment methods, etc).
UTRAN (UMTS Radio Access Network)
UTRAN is a logical grouping that includes one or more Radio Network

Subsystem (RNS). Two of them (RNS1, RNS2) are depicted in the figure
4. A RNS is a sub-network within UTRAN and consists of one Radio
Network Controller (RNC) and one or more Node Bs. For simulation
purposes, only one RNS is simulated. In the following section, the main
components of the RNS are explained.
Node B
The Node-B is analog in functionality to the BTS in GSM networks. Its

main function is to provide the radio link between the UE and the UMTS
network. It performs radio functions related to the “air interface”, which is
the logical interface (known as Uu interface in 3GPP specifications)
between the UE and the Node B. Higher layer functions (e.g. Medium
Access Control) and control of the Node Bs is performed by the RNC.
Some of its main tasks are the implementation of Radio Resource
11
Management algorithms such as the Fast Power Control Algorithm which is

crucial to make CDMA works (keeps away the known “” in UL) and the
Softer Handover (a special Handover type when the UE is connected to
cells belonging to the same node B, as it is going to be explained later).
Node B’s are connected to the RNCs through the Iub interface which
physically corresponds to one or more ATM links.
RNC
The RNC is the element responsible for most of the Radio Resource
Management in the UTRAN (Umts Terrestrial Radio Access Network). For
instance, the RNC is the element that solves the congestion situations by
issuing the corresponding congestion resolve actions directed towards the
congested Node B’s; also it is the key element in the Handover process;
performs a special power control known as “outer loop power control” and
handles admission control and code allocation for the cells served by the
controlled node B’s.
When a mobile is connected to Node Bs controlled by different RNC’s, the

RNC that has the active connection to the core network through the Iu-CS
or Iu-PS interface is known as the Serving RNC (SRNC) and the other RNC
(the one that just routes information) is known as Drift RNC (DRNC). Also,
from a Node B point of view, the RNC that controls it is known as the
Controller RNC (CRNC). Physically there is no difference between SRNC,
DRNC and CRNC, in fact it is only one equipment that in any given
moment of time can assume any of the described roles.
Two RNCs are connected through the logical Iur interface, which
corresponds physically to ATM links and allows soft handover between
RNCs and some other additional advanced functionality as described in
[Holma].
Core Network
The core network is the “all-in-one” network that connects the mobile
users of a given UTRAN with other mobile users from other companies,
with fixed phones and with other Data Networks. From the technical point
of view, the core network is the backbone of the mobile communication
system that provides connectivity to different radio access and fixed
networks. The Release 99 core network is just an evolution of the GSM
backbone; although with newer releases, starting from Release 4 with the
introduction of the IMS (IP Multimedia Subsystem, see [Umtsforum] for
more information), and Release 5, the ideas are converging towards an
all-IP core network, where the traditional signaling system (SS7) will be
replaced by SIP. As the focus of the simulation is in the UTRAN part, this
part of the architecture is mentioned only for reference and it is not going
to be explained in further sections.
The main components of the core network (Rel-99) are:
HLR: The Home Location Register is a database that contains the master
copy of the user’s service profile.
12
MSC/VLR: The Mobile Services Switching Center and Visitor Location
Register are the switch (MSC) and database (VLR) serving the UE in its
current location when it is using a circuit-switched service (e.g. speech).
GMSC: The Gateway MSC is a MSC which interfaces with external circuit-
switched networks. From the architectural point of view it can be seen as
a router that routes information between the PLMN of the UMTS network
(the network of MSCs) and its external interfaces connected to other
circuit-switched services (e.g. ISDN networks).
SGSN: The Serving Gateway Support Node is the counterpart of the

MSC/VLR but in the packet switched domain.
GGSN: The Gateway GPRS Support Node is the counterpart of the GMSC
but in the packet switched domain.
1.7 Radio Resource Management Algorithms
The Radio Resource Management functionality (RRM, in short) is a set of

algorithms used for optimal utilization of the air interface (the so-called
“soft” resources) and Hardware resources (also known as “hard”
resources). Among them, the main RRM algorithms are:
• Admission Control
• Congestion Control (Load Control)
• Radio Resource Allocation and Management
• Power Control
• Handover Control
• channel switching
The purposes of the RRM algorithms are to ensure planned coverage for
each service, providing the best capacity-coverage tradeoff; to
ensure required connection quality, to ensure the planned (low) blocking
and to optimize the system usage in run time.
Different elements in the UMTS architecture (UE + UTRAN) execute

different RRM algorithms; this is illustrated in the next graph: [Castro]
13
Figure 1-7: RRM algorithms performed by the different UE and UTRAN elements
14
References:
[21.905] 3GPP. Vocabulary for 3GPP Specifications (TR 21.905 v 6.9.0). Sophia Antipolis,
June 2005.
[Castro] Jonathan P. Castro. The UMTS Network and Radio Access Technology: Air Interface
Techniques for Future Mobile Systems. Wiley, England, 2001.
[Holma] Harri Holma and Antti Toskala. WCDMA for UMTS, Radio Access for Third
Generation Mobile Communications (3rd Edition). Wiley, Chichester, England, 2004.
[Umts-forum6] UMTS/IMT-2000 Spectrum (Report number 6). UMTS Forum, London,

England, 1998.
[Umtsworld] www.umtsworld.com
[Vourekas] Greg Vourekas. UMTS fundamental concepts. Vodafone Maastricht, The

Netherlands (internal document). 2004.
15
2. Appendix: procedure for

exporting a traffic map based
on clutter data from ATOLL to
Wines
This appendix describes the process to export an ATOLL traffic map based
on clutter data to Wines format (ATOLL version used: 2.3.1) and it is
based on [ATOLL] and [winesusermanual]. When ATOLL and Wines are
installed on the same machine, Wines installs an add-in button in ATOLL
so the selected project can be automatically opened in Wines just by
pressing this button and therefore there is no need to follow the process
described in this annex. This annex however, assumes that ATOLL and
Wines are installed on different machines and therefore the project in
ATOLL must be saved first in the specific formats described in this annex.
The required steps to export the ATOLL project to Wines are as follows:
2.1 Project Export to a *.mdb file
Atoll allows to export a UMTS project to a Microsoft Access Database

(*.mdb) file. This database contains Atoll UMTS radio data, including:
• Network layout (Node Bs, Antennas, cells)

• Environments definition
• User configuration
To export the currently open project in ATOLL to a mdb file, use

the menu entry:
File -> Database -> Export….
16
2.2 Export of the Computation Zone and Focus Zone
The computation zone and the focus zone are not stored in the project
database, so they need to be exported separately.
The computation zone (equivalent to Wines simulation area) can

be exported using the menu entry:
Tools -> Computation Zone -> Save as …. Enter a file name and
save the zone in *.shp format.
The focus zone (equivalent to Wines Analysis Area) can be

exported using the menu entry:
Tools -> Focus Zone -> Save as…. Enter a file name and save the
zone in *.shp format.
2.3 Export the path loss Data to Raster Data Files
Atoll uses a separate path loss map for each antenna. The antenna
pattern is included in the path loss values.
To filter a group of Node Bs in the ATOLL Project: Go to Data -> Sites ->
Filter Inside a polygon. You will have two options:
• Computation zone
• Draw
The first option filters the node Bs and only the Node B’s inside the
computation zone (simulation zone in wines) are taken into account.
The second option allows you to draw a polygon selecting only the nodes
you want to work with.
17
To be able to export the path loss data, first you have to make sure that a
prediction study already exists. If not, go to the “prediction folder” and
generate a prediction of “coverage by signal level”. Create the prediction,
then right click to execute the prediction and then you can export the path
loss data.
In order to export the path loss data, right-click on the predictions

item in the Data tab, select the “Result Storage” option. A dialog
appears that allows for a selection of one or more transmitters.
Use the select all and then Export items from the Actions button.
In the calculation results export dialog, please specify a directory,
select Path loss(dB) in the exported values box, choose binary
format (*.bil) from the format box, and press OK
2.4 Export the Clutter map and Clutter Classes Definition
The clutter map must be saved as a raster file (e.g. BIL file).
To export the clutter map, use the menu entry Save as… in the
context menu of the Clutter folder of the Geo tab. It is
recommended to save the clutter map as a BIL file because Atoll
may crash in some cases when trying to save it as TIFF file.
The association of each clutter code with a clutter class is defined in the
Clutter classes properties of the Atoll clutter map.
The clutter class definition (e.g. 0: default class, 1: water,

2:agriculture, 3:urban, etc) must be saved in addition to the
clutter map. It can be stored in the same directory like the clutter
map file to a *.mnu file. This *.mnu file must have the same name
like the corresponding clutter map file, but with the extension
*.mnu. It simply contains the clutter code and the associated
clutter class name separated by a blank or tab.
For example, a *.mnu file could be as follows:
18
0 Default Class
1 Water
(…)
10 Coniferous Forest
2.5 Exporting background Maps with ATOLL
If you have a background map that you wish to use in an external

application:
a) Click the “select area” button
b) define the area to be exported
c) Select File -> Export Image command, and save it as a geo-

referenced image choosing “TIFF format” as the output format.
2.6 Exporting DEM (Digital Elevation Model) information
To export the DEM terrain map, select it in the GEO TAB, Digital Terrain
Model folder, and select “save as” option, saving it as BIL file (ATOLL
crashes some times when trying to generate a TIF file).
2.7 Traffic Map(s) and Environment Codes Definition
Traffic data can be represented in Atoll in different ways. For the

importing process into WiNeS, two of these options are supported:
• Environment traffic maps, where each pixel is associated with an

environment, which represents a certain service mix (each
environment (e.g. Urban, Sub-urban, etc) has defined a list of
clutter classes and weights).
• Cell traffic maps (based on transmitters and services), where the

best server coverage area of each transmitter is associated with
service-specific traffic values, which may additionally be subject to
clutter-based weighting factors.
19
If Environment traffic maps are used in Atoll, each map must be saved as
a raster file, e.g. in TIF format. This can be done using the menu entry
Save as in the context menu of the respective Environment map in the
UMTS Traffic folder of the Geo tab.
The association of each environment code number (and color) with an

Environment (as defined in the Atoll UMTS Parameters) is defined in the
properties of the respective environment traffic map, e.g. as shown in Fig.
1.
Figure 2-1: Example Environment Codes definition in the Atoll Environment

Traffic map properties
That Environment codes definition must be saved in addition to each

environment traffic map. There are two ways to provide that information
to the WiNeS ASM import process: either through a *.mnu file for each
environment traffic map or if only one environment traffic map is used or
several environment traffic maps with the same environment codes
definition, through the ASM configuration file (atollimportmodule.ini).
The preferred way is the export of *.mnu files − one for each environment
map, which must be stored in the same directory like the environment
map files. Such a *.mnu file must have the same name like the
corresponding environment map file, but with the extension *.mnu . It
simply contains the Environment code and the associated
Environment name separated by a blank or tab (refer also to [A-UM]

section III.5.3).
For the example in Figure 2-1 the *.mnu file contents must be:
0 no data
1 Urban
2 Rural
If there is only one environment traffic map defined in the Atoll project or
if all defined environment traffic maps have the same Environment Codes
definition, an alternative way is the definition in the [EnvironmentCodes]
20
section of the ASM configuration file (atollimportmodule.ini) in the
following format:
EnvironmentName = CodeNumber
For the example in Fig. 1, the appropriate definition is as follows:
[EnvironmentCodes]
no data = 0
Urban = 1
Rural = 2
For the most convenient usage of the ASM in connection with Atoll
environment traffic maps it is recommended to create a *.mnu file for
each environment traffic map.
If Cell traffic maps are used in Atoll the traffic data should be imported to
WiNeS using the traffic matrix import function based on raster layers,
which is described as creating a Traffic Matrix from a Surface Plot Layer in
[W-UG].
Below a simple procedure is given to create an “inhomogeneous” traffic

Map with ATOLL, based on the clutter weights defined per each
environment:
a) Go to Data Tab, Environments; Select for instance just one of

them (e.g. Dense Urban). Assign weights to the clutter
inside, something like this:
Clutter class Weight % Indoor
Default 0 0
Suburban: <6m Garden 10 30
Suburban: <6m 10 30
Suburban: <6m Dense 10 30
Suburban: <9m Wooded 10 30
Suburban: 6-9m Garden 10 30
Suburban: 6-9m 10 30
21
Suburban: 6-9m Dense 10 30
Urban: 9-12m 15 50
Urban: 12-18m 15 50
Urban: 18-27m 15 50
Urban: 18-27m Dense 15 50
City: 27-40m Open 20 60
City: 27-40m 20 60
City: >40m 20 60
Table 2-1: Example of assigned clutter class weights
The combined weights together with the area size of each clutter class
determine the final number of users per each pixel. This number of users
is given by the formula:
Nk = Nclass x Wk Sk / Σ( Wj * Sj)
Where
• Nk = Number of users in the k clutter
• Nclass = Number of users in an environment class
(defined in the “environments” Tab).
• Wk = k clutter weight at a fixed surface (value
assigned for each Environment)
• Sk = k clutter surface.
For more information, consult ATOLL user guide section VIII.5.2.e.v, page
287.
b) In the GEO Tab, select UMTS Traffic, right click and then
select “new map”. Afterwards select “map based on
environments (raster)” option.
c) Now you have a box open. Replace the entry “no data” of the
list with the environment that you defined (in this case,
“Dense Urban”).
d) Select the “draw polygon” tool. Use this tool to draw the
polygon where this traffic map is going to be created (usually
we can take the same simulation area). When finish press
double click.
22
e) In “UMTS Traffic” folder, select the option “export cumulated
traffic”.
f) To check that it is working, we can export it first as BMP
image and check if the image shows the different traffic
densities in the map.
g) After the check, to be able to work with it in Wines, we have
to “export cumulated traffic” but now we are going to save it
as “BIL” file.
Finally, in Wines select the appropriate “service profile”, right click over it,
Select the option “import traffic from Raster Image” and select the BIL file
created in step g.
23
References:
[ATOLL] ATOLL: Technical Reference Guide, Version 2.1.3, Forsk, 2004.
[WINESUSERMANUAL] J. Deißner, J. Hübner, D. Hunold, D. Stachorra, J. Voigt. User

Guide for WiNeS Control Center User version 3.3. Radioplan GmbH, Dresden, Germany,
2005.
24

Thesis Hurtado

Uploaded by

Document Information

Original Description:

Original Title

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

Thesis Hurtado

Uploaded by

Copyright:

Available Formats

University of Twente

Faculty of Electrical Engineering,

UMTS Capacity simulation study

The purpose of this report is to investigate the performance, measured in

In the second series of experiments, a more realistic scenario, based on

For the single-service scenario analysis, circuit-switched services (speech

In terms of the power-rule usage, no significant differences between the

Finally, for the mobility study in both scenarios (homogeneous, non

I want to express my gratitude to my Direct Supervisor at University of

I wish to thank also my supervisor at Vodafone-NL, Dr. Bert Haverkamp,

I would like to express also my gratitude to all the Vodafone IT-Network

3GPP Third Generation Partnership Project

ATOLL UMTS RF planning solution by Forsk

BER Bit Error Rate

BLER Block Error Rate

BSC Base Station Controller

BTS Base Transceiver Station

CDMA Code Division Multiple Access

CRC Cyclic Redundancy Check

CRNC Controlling RNC

CPICH Common Pilot Channel

CS Circuit Switched service

DPCCH Dedicated Physical Control Channel

DPDCH Dedicated Physical Data Channel

DRNC Drift RNC

DSSS Direct Sequence Spread Spectrum

FACH Forward Access Channel

FDMA Frequency Division Multiple Access

GGSN Gateway GPRS Support Node

GSM Global System for Mobile telecommunications

GPRS General Packet Radio Service

HLR Home Location Register

HSS Home Subscriber Server

IMS IP Multimedia System

IMT-2000 International Mobile Telecommunications 2000

ITU International Telecommunication Union

KPI Key Performance Indicator

MRC Maximum Ratio Combining

OVSF Orthogonal Variable Spreading Factor

P-CPICH Primary CPICH

PDF Probability Density Function

PS Packet Switched service

QoS Quality of Service

RNC Radio Network Controller

RNS Radio Network Subsystem

RRC Radio Resource Control

RRM Radio Resource Management

RSCP Received Signal Code Power

RSSI Received Signal Strength Indicator

SGSN Serving GPRS Support Node

SIP Session Initiation Protocol

SIR Signal to Interference Ratio

TDMA Time Division Multiple Access

TPC Transmission Power Control

UMTS Universal Mobile Telecommunications System

UTRAN UMTS Terrestrial Radio Access Network

VoIP Voice over IP

W-CDMA Wideband - Code Division Multiple Access

Wines Radioplan’s WIreless NEtwork System

2. CAPACITY AND SIMULATION (INTRODUCTORY) CONCEPTS .........21

3. THE RADIO PLANNING PROCESS (LITERATURE STUDY)..................30

4. INTRODUCTION TO WINES DYNAMIC SYSTEM-LEVEL