Thesis Hurtado

University of Twente
Faculty of Electrical Engineering, Mathematics and Computer Science (EEMCS)
UMTS Capacity simulation study Andrs 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, Andrs 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/nonmobile 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 uplinklimited. 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.
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 couldnt 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 didnt 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; Im 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! Im 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 Roco, my sister Mara 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 Radioplans WIreless NEtwork System
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 (ITUS 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 3.2 SUMMARY OF CHAPTER 3 39 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 4.5 SUMMARY OF CHAPTER 4 55
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 KPIS (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 5.9 SUMMARY OF CHAPTER 5 81 6. DESCRIPTION OF THE SECOND SIMULATION SCENARIO (NONHOMOGENEOUS) .......................................................................................................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 6.4 SUMMARY OF CHAPTER 6 90 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: 7.4 MOBILITY STUDY 7.4.1 Blocking and Dropping probabilities (Voice service) 7.4.2 Uplink load (Voice service) 7.4.3 Downlink Power usage (Voice service) 7.4.4 Throughput (Web service) 7.5 SUMMARY OF CHAPTER 7 7.5.1 Single service experiments 7.5.2 Traffic mix homogeneous scenario 7.5.3 Power study 7.5.4 Mobility study
156 158 159 160 161 161 163 163 164 164 165
8. SIMULATION RESULTS SECOND SCENARIO (NONHOMOGENEOUS) 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 183 PERFORMANCE OF THE UTRAN 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 6 CONCEPTS IN UMTS [VOUREKAS] 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 Table 16: Estimation of the users per cell according to the simulation output, Downlink 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
Table 20: Estimation of the users per cell according to the simulation output, Web-only service, parameter sf8Adm=8, Blocking probability target = 1% ..................................110 Table 21: Estimation of the users per cell according to the simulation output, Web-only 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 Table 23: Estimation of the users per cell according to the simulation output, Web-only 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 Table 25: Estimation of the users per cell according to the simulation output, Web-only service, DL code tree usage target = 60% ......................................................................117 Table 26: Estimation of the users per cell according to the simulation output, Web-only 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 Table 30: Estimation of the users per cell according to the simulation output, FTP-only service, target DL and UL CE usage: 256, 64. ...............................................................123 Table 31: Estimation of the users per cell according to the simulation output, FTP-only service, target DL throughput =1.07 Mbps.....................................................................124 Table 32: Estimation of the users per cell according to the simulation output, FTP-only service, target UL load = 60% ........................................................................................125 Table 33: Estimation of the users per cell according to the simulation output, FTP-only service, target Downlink power = 38.7 dBm..................................................................126 Table 34: Estimation of the users per cell according to the simulation output, FTP-only 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 Table 38: Estimation of the users per cell according to the simulation output, video call service, Uplink load target = 0.6 (60%)..........................................................................131
xi
Table 39: Estimation of the users per cell according to the simulation output, video call 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 Table 73: List of KPIs for the non-homogeneous scenario, ordered by the occurrence of the target threshold ...............................................................................................................200 Table 74: List of KPIs for the homogeneous scenario, ordered by the occurrence of the target 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 Table 79: List of KPIs for the non-homogeneous scenario, ordered by the occurrence of the target threshold ...............................................................................................................206 Table 80: List of KPIs for the homogeneous scenario, ordered by the occurrence of the target 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 dimensioning in UMTS Networks: challenges when performing capacity
In UMTS capacity changes dynamically according to several factors (network load, characteristics of the antennas used, bit rates, multipath 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 (KPIs)) 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 doesnt include the radio-planning stages Optimization and Monitoring which are out of the scope of it. of
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 doesnt 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 UMTSWCDMA 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 KPIs 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, its 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 KPIs, 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 users 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 fi i h
System
System
System l
User Starts
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 doesnt depend on the interference levels as much as in the UMTS case). This single-value number is known as the GSMs 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 doesnt 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 softcapacity 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. Speechonly 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 multiservice 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 ), doesnt 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, its 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 interrelations 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, its 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 users 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 (ITUs IMT-2000) vision

The following graph illustrates the key steps of the UMTS W-CDMA Radio Planning process according to [ITU]
30
1 2 3
Definition of the radio parameters, WCDMA and marketing
Traffic prediction
Dimensioning
Number of sites Inter-site distance
Capacity and coverage planning
Base station configuration,
4 5
Network performance simulation
Network analysis Theorical validation
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 nce of Ic and Ico?

Current Radius is UL cell radius
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 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 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 )]] 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=1k) Rj is the bit rate of service j vj is the activity factor of the service j. ( 3-4) (3-3) (3-2)
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 cant 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 its 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. In UMTS, the detection/prevention of capacity problems in the network is not 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. In UMTS, the detection/prevention of capacity problems in the network is not 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 doesnt 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 Where: SIRUL,I = level of the SIR at the iteration i SIRUL target = predefined SIR target
( 4-1)
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 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) all the radio-resource
In the dynamic simulator, the users are making calls (according to the socalled 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 doesnt 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 users 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 simulators 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 modes 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 Forks 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 Bs and cells). 3) Run the corresponding simulation(s) and store the results in the programs 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
WiNeS-WCC
Analysis
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 users 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 users 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 Mean UL datagram size [byte] Mean number of packet call requests / user Mean reading time [s] Mean DL datagram count
Distribution Negative exponential
Geometric
Geometric geometric
Mean DL datagram inter arrival time [s] Mean DL Datagram Size [byte] Server response time
geometric
Pareto with cut-off
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 Bs of the company. These parameters appear in the appendix 4 (confidential: system parameters).
54

Static simulation vs. Dynamic simulation Static simulations dont 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 Bs, 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 intersite 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 doesnt 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 Voice Videocall Web Ftp MobileTv
percentage 77,00%
12,50
3,00
0,00
7,50% 12,50% 3,00% 0.00%
7,50
Voice Video calls www ftp Mobile Tv
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 alreadyknown 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. errorfree) 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. errorfree) 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 Speech Web FTP Video-call Mobile TV
Wines Traffic Model Speech/video WWW File Speech/video 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 cells and hence the networks 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 ) 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 doesnt 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) (5-3)
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) ASEUL= Sum rl (ASErl Where: ASEDL is the air interface speech equivalent in downlink for the cell ASErl link
DL UL/
( 5-4) nb radio links per RNC) (5-5)
is the air interface speech equivalent in downlink for a radio
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 interarrival 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 [Ericssoncapacity]:
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 KPIs (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 circuitswitched 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
KPI
Threshold
Value 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 (PS64/384, in our simulations correspond to Voice Service, FTP and Web Service) 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 (PS64/384, in our simulations correspond to Voice Service, FTP and Web Service)
Reason / Source
% of Blocked calls
% of Blocked calls at a given BLER level
Ericsson
% of Dropped calls
% of Dropped calls at a given BLER level
Ericsson
DL Channel Elements
Pool of maximum available CEs in UL and DL (not shared among directions) per each Node B, we assume congestion (in UL or DL) if these limits are passed in UL and DL respectively
number of CE UL / number of CE DL
Vodafone Hardware Department
Table 3:(1/4): KPI definition
68
KPI definition Threshold Value Reason / Source
DL Code Usage (No second code tree used for simulations): percentage of DL Code Usage before triggering soft congestion mechanism
The main monitor is the Downlink Channelization Code Admission Policy. There is blocking for nonhandover requests (i.e. new users) in order to reserve some codes for users in handover which are not blocked. The soft congestion mechanism is triggered when non-guaranteed service requests are blocked, This value is equal to dlCodeAdm - beMarginDLCode (See Figure). Additionaly, there is the histogram admission policy, which controls when non-guaranteed (handover and non-handover) admission requests demanding spreading factor 8, 16 or 32 are blocked if the usage of this spreading factor exceeds sf8Adm, sf16Adm and sf32 Adm respectively. Defined counters: sf8Adm,sf16Adm,sf32Adm.
For the Downlink Channelization Code Admission Policy: Percentage of DL Code Tree used, given per cell [%].
The percentage of codes in use is calculated as follows: Sum [all-user] (1/SF[user]) + Sum [allCCH] (1/SF[CCH])
SF[user] is the SF of the User, SF[CCH] is the SF of the common control channel.
For the Histogram Admission Policy = number of admission requests demanding a given spreading factor [8,16,32]
Ericsson
UL Congestion: RTWP measured level more than a given threshold for a given amonut of time
Ericsson detects this measuring Received Total Wideband Power in UL, congestion is detected when RTWP exceeds iFcong+iFOffset during a time longer than iFHyst, see the corresponding Figure
Power level [dBm] per cell within a time interval.
Ericsson.
Table 3 (2/4): KPI definition
69
KPI Definition Threshold Unit Reason / Source
DL Power Usage: Congestion in DL when DL transmitted power exceeds a certain configurable threshold for a longer time than the hysteresis time. Throughput (perceived by the user): minimum acceptable throughput, values below this level indicate a bad performance
Ericssons indicator of Downlink congestion, congestion in DL detected when DL power exceeds pwrAdm+pwrAdmO ffset+pwrOffset during a time longer than pwrHyst, see Figure
Power level [dBm] per cell within a time interval.
Ericsson.
Vodafone Internal Target
Average throughput per service [Kbps]
Vodafone Internal Marketing Document
70
KPI Definition Threshold Unit 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 among the three cells of the Node B. Reason / Source
DL Iub capacity
% of Iub reserved bandwidth
[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 shouldnt 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 Voice Video call Www Ftp Mobile tv
% 77 7.5 12.5 3 0.00
Erl 10.00 0.97 1.62 0.39 0.00
Erl 20.00 1.95 3.25 0.78 0.00
Erl 40.00 3.90 6.49 1.56 0.00
Erl 80.00 7.79 12.99 3.12 0.00
Erl 160.00 15.58 25.97 6.23 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 affect the size of the Handover Zones and the Pilot Polluted zones, so study is aimed to check which settings are better in terms of these indicators (distribution of the Handover Zones (i.e. active set size >1) distribution of the pilot polluted zones).
and this two and
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 If feeder loss > 3 dBm then PCICH Power = 33 dBm Feeder loss And the rule applied in Germany is: PCICH Power = 33 dBm Feeder loss, for all feeder losses (5-8) (5-6) (5-7)
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 40.00
Web density 6,49
FTP density 1,56
Video call density 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 path loss PCICH Power NL PCICH Power Germany
Site
Wines CPICH settings GE PCICH Power = 33 dBm, cable loss DL = 4 PCICH Power = 33 dBm, cable loss DL = 0 PCICH Power = 33 dBm, cable loss DL = 0 PCICH Power = 33 dBm, cable loss DL = 0 PCICH Power = 33 dBm, cable loss DL = 2 PCICH Power = 33 dBm, cable loss DL = 1 PCICH Power = 33 dBm, cable loss DL = 2
Wines CPICH settings NL
4 dB
29
29
PCICH Power = 33 dBm, cable loss DL = 4
0 dB
30
33
14
0 dB
30
33
10
0 dB
30
33
2 dB
30
31
1 dB
30
32
13
2 dB
30
31
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 e 40.0
Scaling Factor 0.506329114
We b 6.49
FT P 1.5
Scaling factor 0.019746835
Video call 3.90
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
Site
U000751 U000752 U000753 U000791 U000793 U000801 U000802 U000803 U009641 U009642 U009643 U009651 U009652 U009653 U011031 U011032 U011033 U011071 U011072 U011073 U011381 U011382 U011383 U014671
path loss (from ATOLL)

3 1.595 3.7 2.935 2.54 2.325 2.28 1.85 3.105 3.57 3.47 2.69 2.69 2.69 1.275 2.49 1.27 2.51 2.42 2.66 4 4 4 3.275
PCICH Power NL (Reference 2) 30 30 26.3 30 30 30 30 30 26,895 26,43 26,53 30 30 30 30 30 30 30 30 30 26 26 26 26.725
PCICH Power Germany (Reference 2) 30 31.405 29.3 30.065 30.46 30.675 30.72 31.15 29.895 29.43 29.53 30.31 30.31 30.31 31.725 30.51 31.73 30.49 30.58 30.34 29 29 29 29.725
WinesPCICH settings GE (Reference 1) 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
WinesPCICH settings NL (Reference 2) 33 31.595 30 32.935 32.54 32.325 32.28 31.85 30 30 30 32.69 32.69 32.69 31.275 32.49 31.27 32.51 32.42 32.66 30 30 30 30
77
U014672 U014673 U020731 U020732 U020733 U030761 U030762 U030763 U030771 U030772 U030773 U030801 U030802 U030803 U030821 U030822 U030823 U030841 U030842 U030843 U030851 U030852 U030853 U032311 U032312 U032313 U035701
3.32 3.32 1.905 1.645 1.86 2.31 2.44 1.675 1.3 1 1.3 3.01 3 3.01 3.65 3.7 3.65 2 2 2 3.51 2.91 1.15 3.015 3.02 3.02 2.755
26.68 26.68 30 30 30 30 30 30 30 30 30 26.99 30 26.99 26.35 26.3 26.35 30 30 30 26,49 30 30 26.985 26.98 26,98 30
29.68 29.68 31.095 31.355 31.14 30.69 30.56 31.325 31.7 32 31.7 29.99 30 29.99 29.35 29.3 29.35 31 31 31 29.49 30.09 31.85 29.985 29.98 29,98 30.245
33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
30 30 31.905 31.645 31.86 32.31 32.44 31.675 31.3 31 31.3 30 33 30 30 30 30 32 32 32 30 32.91 31.15 30 30 30 32.755
78
U035702 U035703 U046611 U046612 U046613 U051651 U051652 U051653 U052011 U052012 U052013
2.74 2.35 1.365 1.375 1.365 3 3 3 0.6 0.6 0.6
30 30 30 30 30 30 30 30 30 30 30
30.26 30.65 31.635 31.625 31.635 30 30 30 32.4 32.4 32.4
33 33 33 33 33 33 33 33 33 33 33
32.74 32.35 31.365 31.375 31.365 33 33 33 30.6 30.6 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 Jains 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 intrafrequency 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 (nonhomogeneous)

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 Bs 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 nonhomogeneous 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 Default Suburban: <6m Garden Suburban: <6m Suburban: <6m Dense Suburban: <9m Wooded Suburban: 6-9m Garden Suburban: 6-9m Suburban: 6-9m Dense Urban: 9-12m Open Urban: 9-12m Urban: 12-18m Open Urban: 12-18m Urban: 18-27m Open Urban: 18-27m Urban: 18-27m Dense City: 27-40m Open City: 27-40m City: >40m
Weight 0 10 10 10 10 10 10 10 15 15 15 15 15 15 15 20 20 20
% Indoor 0 30 30 30 30 30 30 30 50 50 50 50 50 50 50 60 60 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 Ys 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 didnt 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% 0.0400% 0.0200% 0.0000% 10.0000 20.0000 40.0000 80.0000 160.0000 Blocked services [%]
Traffic Density [Erl/Km^2]
Figure 25: Blocking probability, voice only service
94
dropped probability [%] 0.0006 0.0005 0.0004 0.0003 0.0002 0.0001 0.0000 10.0000 20.0000 40.0000 80.0000 160.0000
dropped probability [%]

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= b= c= d= Level at Y = 0.01 Number of users per cell Linear Fit: y=a+bx Coefficient Data: a= b= -0.0002 7.2446E-06 49 -2.62E+02 3.20E+01 -9.56E-01 7.48E-04 281.71 Erl/Km^2
95
Level at Y = 0.01 Number of users per cell 248
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) 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 (7-1)
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 A = cell area (hexagonal cell) = K*r
2
(7-2) (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:
Target threshold = 1% (Y=0.01 in linear scale) 3rd degree Polynomial Fit: y=a+bx+cx^2+dx^3... a= b= c= D= Level at Y = 0.01 Number of users per cell Linear Fit: y=a+bx a= b= Level at Y = 0.01 Number of users per cell -0.0001 3.29E-06 3068 538 Erl/Km^2 -1.19E-05 1.46E+06 -4.35E-08 3.40E-10 352.673 62 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 100,0000 50,0000 0,0000
00 00 00 00 ,0 0 ,0 0 ,0 0 ,0 0 0, 00 00
DL Channel Elements usage [mean] DL Channel Elements usage [max]
10
20
40
80
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 100,0000 80,0000 60,0000 40,0000 20,0000 0,0000
00 00 00 00 ,0 0 ,0 0 ,0 0 ,0 0 0, 00 00
16
UL Channel Elements usage [mean] UL Channel Elements usage [max]
10
20
40
80
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
16
extrapolation is used and therefore a range of values is given. The results are summarized in the following tables.
CE Downlink Linear Fit: y=a+bx Coefficient Data: a= b= Level at Y = 256 Number of users per cell Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Level at Y = 256 Number of users per cell
Target = 256 CE
17.6737 0.8078 295 52 Erl/Km^2
15.544373 0.90265331 -0.0005 334.509 59 Erl/Km^2
Table 12: Estimation of the users per cell according to the simulation output, Downlink Channel elements target = 256
CE Uplink Quadratic Fit: y=a+bx+cx^2 a= b= c= Level at Y= 64 Number of users per cell Target = 64 CE Coefficient Data: 0.5444 0.9027 -0.0005 73.5965 13 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 Kbps 600,0000 400,0000 200,0000 0,0000 Iub traffic [DL]
00
00
00
00 ,0 0 80 16
,0 0
,0 0
,0 0
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
20
40
10
0, 00
00
Target for Iub DL throughput = 2786 cells/sec * 48 bytes/cell * 8 bits/byte = 1.07 Mbps Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Level at Y= 1070 Number of users per cell Linear Fit: y=a+bx Coefficient Data: a= b= Level at Y= 1070 Number of users per cell 15.5115 5.0227 209.9440 37 Erl/Km^2 3 6 -0.0031 218.8070 39 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% 70,0000% 60,0000% 50,0000% 40,0000% 30,0000% 20,0000% 10,0000% 0,0000%
00 00 00 00 0, 00 ,0 0 ,0 0 ,0 0 ,0 0 00
UL Load [%]
UL Load [%]
10
20
80
40
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 ) Where: NR represents the Noise Rise. nul is the uplink load factor. ( 7-6)
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
16
Uplink Noise Rise Linear Fit: y=a+bx Coefficient Data: a= b= Level at Y= 0.60 Number of Users/cell Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Level at Y= 0.60 Number of Users/cell
Target Value = 0.60
0.02258 0.0059 99.7655 18 Erl/Km^2
-0.0240 0.0079 -1.20E+02 92.4429 16 Erl/Km^2
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 36,5000 36,0000 35,5000
00 00 00 00 0, 00 ,0 0 ,0 0 ,0 0 ,0 0 00
DL_TxPower [dBm]
40
10
20
80
traffic density [Erl/Km^2]
Figure 31: Downlink transmitted power, voice only service
103
16
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= b= Level at Y = 38.7 dBm Number of users per cell Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Level at Y = 38.7 dBm Number of users per cell 363.747 0.0116 -1.06E+01 205 36 Erl/Km^2 36.3788 0.01140 203.68 36 Erl/Km^2
Table 16: Estimation of the users per cell according to the simulation output, Downlink transmitted power congestion target = 38.7 dBm
104
7.1.1.6 Downlink Code Tree Usage

DL_Code tree usage[%] 45,0000% 40,0000% 35,0000% 30,0000% 25,0000% 20,0000% 15,0000% 10,0000% 5,0000% 0,0000%
Code tree usage [%]
DL_Code tree usage[%]
00
00
00
00
10
20
40
80
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= b= Level at Y = 0.6 Number of users per cell Quadratic Fit: y=a+bx+cx^2 a= b= c= Level at Y = 0.6 Number of users per cell 0.0320 0.0026 -1.70E+01 258.188 45 Erl/Km^2 0.03858 0.0023 239.89 42 Erl/Km^2
Table 17: Estimation of the users per cell according to the simulation output, Downlink Code Tree usage congestion target = 60%
105
16
0, 00
,0 0
,0 0
,0 0
,0 0
00
7.1.1.7 Summary of Voice Service Next table presents the summary with the KPIs 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 CE UL UL Load DL power Iub DL code tree Blocking prob CE DL Dropping prob
Target Level 64 60% 38.7 dBm 1070 Kbps 60% 1% 256 1%
No. users to reach the target 13 16 36 37 42 49 51 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 KPIs 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. 7.1.2.1 Blocking and Dropping probability The following Figures illustrate the obtained simulation results in terms of Blocking and Dropping Probabilities:
106
Blocking probability [%] 60,0000% 50,0000% 40,0000% 30,0000% 20,0000% 10,0000% 0,0000%
00 00 00 00 1, 62 3, 25 6, 49 ,9 9 ,9 7 00
Blocked services [%]
Figure 33: Blocking Probability Web service, sf8Adm=1
dropped services [%] 100,0000% 80,0000% % 60,0000% dropped services [%] 40,0000% 20,0000% 0,0000%
12
0 90 ,9 12 25 ,9
25
70 0
00
00 25 3, 6,
62
1,
Figure 34: Dropping Probability Web service, sf8Adm=1
107
49
00
Blocking Probability, Target =0.01 a) MMF Model: y=(a*b+c*x^d)/(b+x^d) a= b= c= d= Value at Y=1% (0.01) Number of users per cell b) Linear Fit: y=a+bx a= b= Value at Y=1% (0.01) Number of users per cell -0.3167 0.0975 3.3526 1 Erl/Km^2 -246.7280 1.2024 50.1275 1.5127 3.292 1 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 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] ( 7-7)
108
The formula reflects that in Downlink the Data Rate for each user and the Eb/No are specific for each users 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.
Blocking probability [%] 14.0000% 12.0000% 10.0000% 8.0000% 6.0000% 4.0000% 2.0000% 0.0000% 1.6200 3.2500 6.4900 12.9900 25.9700 Blocked probability [%]
Figure 35: Blocking Probability Web service, sf8Adm=8
109
Target threshold = 1% (Y=0.01 in linear scale) Quadratic Fit: y=a+bx+cx^2 a= b= c= Value at Y=1% (0.01) Number of users per cell 3rd degree Polynomial Fit: y=a+bx+cx^2+dx^3... a= b= c= d= Value at Y=1% (0.01) Number of users per cell 0.0023 -0.0015 0.0002 3.13E-06 11.0839 2 Erl/Km^2 0.0047 -0.0027 0.0003 11.0888 2 Erl/Km^2
Table 20: Estimation of the users per cell according to the simulation output, Web-only service, 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 UEs 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. 7.1.2.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).
110

DL channel elements 80,0000 70,0000 60,0000 50,0000 40,0000 30,0000 20,0000 10,0000 0,0000 DL Channel Elements usage [mean] DL Channel Elements usage [max]
00
00
00
00 ,9 9 25 12
62
49
25
1,
3,
Figure 36: DL channel elements usage, Web-only service

UL channel elements 60,0000 50,0000 40,0000 30,0000 20,0000 10,0000 0,0000 UL Channel Elements usage [mean] UL Channel Elements usage [max]
6,
00
00 ,9 9 25 12
00
00
49
1,
Figure 37: UL channel elements usage, Web-only service
a) Downlink Linear Fit: y=a+bx a= b= Value at Y = 256 Number of users per cell Quadratic Fit: y=a+bx+cx^2 A= B= C= 17.966051 1.774063 -0.01442546 19.438376 1.3701932 173.648 30 Erl/Km^2
111
3,
6,
,9 7
62
25
00
,9 7
00
Value at Y = 256 Number of users per cell b) Uplink Quadratic Fit: y=a+bx+cx^2 A= B= C= Value at Y = 64 Number of users per cell Linear Fit: y=a+bx A= B= Value at Y = 64 Number of users per cell
218.0280 38
Erl/Km^2
1.1074 1.5842 -0.0108 71.8009 13 Erl/Km^2
2.2047 1.2832 48.1573 8 Erl/Km^2
Table 21: Estimation of the users per cell according to the simulation output, Web-only service, 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
7.1.2.3 Downlink Iub usage
Iub traffic [DL] 1200,0000 1000,0000 800,0000 600,0000 400,0000 200,0000 0,0000
Kbps
Iub traffic [DL]
00
00
00
00 ,9 9 25
62
25
49
1,
3,
6,
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= b= Level at Y= 1070 Number of users per cell 137.3714 33.6504 27.7152 5 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
12
,9 7
00
7.1.2.4 Uplink Load

UL Load [%] 3.0000% Uplink Load [%] 2.5000% 2.0000% 1.5000% 1.0000% 0.5000% 0.0000% UL Load [%]
1. 62 00
3. 25 00
6. 49 00
12 .9 90
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= b= Value at Y=60% (0.6) Number of users per cell
0.005193252 0.065165121 72.8858 13
25 .9 70
Erl/Km^2
Table 23: Estimation of the users per cell according to the simulation output, Web-only service, uplink load target = 60 %
114
7.1.2.5 Downlink Transmitted Power

DL_TxPower [dBm] 38,0000 37,8000 37,6000 37,4000 37,2000 37,0000 36,8000 36,6000 36,4000 36,2000 36,0000 35,8000
Power [dBm]
DL_TxPower [dBm]
00
00
00
3, 25
1, 62
6, 49
00
,9 9
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 Target threshold = 90% (43 dBm) = 38.7 dBm Linear Fit: y=a+bx a= b= Value at Y=38.7 Number of users per cell Exponential Fit: y=ae^(bx) a= b= Value at Y=38.7 Number of users per cell 36.5313 0.0013 45.6290 8 Erl/Km^2 36.528181 0.047020985 46.1883 8 Erl/Km^2
115
12
25
,9 7
00
Quadratic Fit: y=a+bx+cx^2 a= b= c= Value at Y=38.7 Number of users per cell 36.504102 0.0536 -0.0002 53.5761 9 Erl/Km^2
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. 7.1.2.6 Downlink Code Tree Usage
DL_Code tree usage, homogeneous scenario [%] 25.0000% 20.0000% 15.0000% 10.0000% 5.0000% 0.0000% 6.4900 12.9900 traffic density [Erl/Km^2] 25.9700 DL_Code tree usage[%]
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 doesnt 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
Code tree usage [%]
DL Code Tree usage target =60% Linear Fit: y=a+bx Coefficient Data: a= b= Value at Y=60% (0.6) 87.49 Number of users per cell 16
0.043132 0.006364 Erl/Km^2
Table 25: Estimation of the users per cell according to the simulation output, Web-only service, DL code tree usage target = 60% 7.1.2.7 Throughput
Web Indoor Application DL Throughput per user

350.0000 300.0000 250.0000 200.0000 150.0000 100.0000 50.0000 0.0000 1.6200 6.4900 12.9900 25.9700 Traffic Density [Erl/Km^2]
Kbps
DL Throughput
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 0.0000 1.6200 6.4900 12.9900 25.9700 Traffic Density [Erl/Km^2] DL Throughput
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 dBs 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 Exponential Fit: y=ae^(bx) Coefficient Data: a= b= Value at Y=100 Number of users per cell Outdoor users Exponential Fit: y=ae^(bx) Coefficient Data: a= b= Value at Y=100 Number of users per cell
341.31176 -0.013965516 87.9041 15
Erl/Km^2
380.60388 -0.019331111 69.1419 12
Erl/Km^2
Table 26: Estimation of the users per cell according to the simulation output, Web-only service, throughput target = 100 Kbps
118
7.1.2.8 Summary of Web service Next table presents the summary of the Web Service with the KPIs ordered by the traffic densities which reach first their target level:
KPI
Target Level 1% 1070 Kbps 38.7 dBm 64
No. users to reach the target 2
Blocking prob DL Iub DL power CE UL
5 8 8 12
DL 100 kbps throughput (outdoor) UL Load DL code tree CE DL 60% 60% 256
13 16
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

7.1.3.1 Blocking and Dropping probability
Blocking probability [%] 3.0000% 2.5000% 2.0000% 1.5000% 1.0000% 0.5000% 0.0000% 0.3900 0.7800 1.5600 3.1200 6.2300 Traffic Density [Erl/Km^2] Blocking probability [%]
Figure 44: Blocking probability, FTP only service
Blocking probability Target threshold = 1% Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value at Y=1% (0.01) Number of users per cell 0.001576177 -0.002396161 0.001062297 4.1627 1 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
dropped services [%] 0,6000% 0,5000% 0,4000% % 0,3000% 0,2000% 0,1000% 0,0000% 0,3900 0,7800 1,5600 3,1200 6,2300 Traffic Density [Erl/Km^2]
Figure 45: Dropping probability, FTP only service
dropped services [%]
Dropping probability Target threshold = 1% Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value at Y=1% (0.01) Number of users per cell 0.0004 -0.0008 0.0003 8.1451 Erl/Km^2
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. 7.1.3.2 Channel Elements usage

DL channel elements 120,0000 100,0000 80,0000 60,0000 40,0000 20,0000 0,0000 DL Channel Elements usage [mean] DL Channel Elements usage [max]
00
00
00
00 3, 12 6,
39
78
0,
0,
Figure 46: DL CE usage, FTP only service

80,0000 70,0000 60,0000 50,0000 40,0000 30,0000 20,0000 10,0000 0,0000 0,3900 0,7800 1,5600 3,1200 6,2300 Traffic Density [Erl/Km^2] UL channel elements
1,
23
56
00
Figure 47:UL CE usage, FTP only service
122
Target levels: 64 CE UL 256 DL a) Downlink Linear Fit: y=a+bx a= b= Value at Y=256 Number of users per cell b) Uplink Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value at Y=64 Number of users per cell -0.0530 5 0.1415 9.83 2 Erl/Km^2 15.5037 7.0251 34.234 6 Erl/Km^2
Table 30: Estimation of the users per cell according to the simulation output, FTP-only service, 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
7.1.3.3 Downlink Iub usage

Iub traffic [DL] 1400,0000 1200,0000 1000,0000 Kbps 800,0000 600,0000 400,0000 200,0000 0,0000 0,3900 0,7800 1,5600 3,1200 6,2300 Traffic Density [Erl/Km^2] Iub traffic [DL]
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= b= Level at Y= 1070 Number of users per cell 34,4036 204,8369 5,0550 1 Erl/Km^2
Table 31: Estimation of the users per cell according to the simulation output, FTP-only service, 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% UL load [%] 8,0000% 6,0000% 4,0000% 2,0000% 0,0000% 0,3900 0,7800 1,5600 3,1200 6,2300 Traffic Density [Erl/Km^2] UL Load [%]
Figure 49: Uplink load, FTP only service
UL Load threshold = 0.60 = 60% Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Level at Y= 0.60 Number of users per cell -0.0012 0.01575 0.0001 30.363 5 Erl/Km2
Table 32: Estimation of the users per cell according to the simulation output, FTP-only service, 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
7.1.3.5 Downlink Transmitted Power

DL_TxPower [dBm] 39,0000 38,5000 Power [dBm] 38,0000 37,5000 37,0000 36,5000 36,0000 35,5000 35,0000 0,3900 0,7800 1,5600 3,1200 6,2300 traffic density [Erl/Km^2] DL_TxPower [dBm]
Figure 50: DL Transmitted power, FTP only service
Target threshold = 90% (43 dBm) = 38.7 dBm Linear Fit: y=a+bx Coefficient Data: a= b= Level at Y = 38.7 dBm Number of users per cell 36 0.3438 6.7843 1 Erl/Km2
Table 33: Estimation of the users per cell according to the simulation output, FTP-only service, 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
7.1.3.6 Downlink Code Tree Usage

DL_Code tree usage[%] 30,0000% Code tree usage [%] 25,0000% 20,0000% 15,0000% 10,0000% 5,0000% 0,0000% 0,3900 0,7800 1,5600 3,1200 6,2300 traffic density [Erl/Km^2] DL_Code tree usage[%]
Figure 51: DL Code Tree usage, FTP only service
Target Level to trigger soft congestion mechanism = 60% (0.6 in linear scale) Linear Fit: y=a+bx a= b= Level at Y = 0.6 Number of users per cell 0.03295 0.03975 14.2658 3 Erl/Km^2
Table 34: Estimation of the users per cell according to the simulation output, FTP-only service, 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= b= Value at Y = 100 Number of users per cell b) outdoor users Exponential Fit: y=ae^(bx) Coefficient Data: a= b= Value at Y = 100 Number of users per cell 318 -0.1038 11.1251 2 Erl/Km^2 238 -0.027463913 12.4942 2 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 KPIs 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 Level
No. users to reach the target 1 1 1 1 2 2 3 5 6
Traffic Density Level
Blocking prob Iub DL DL power Dropped prob CE UL
1% 1070 Kbps 38.7 dBm 1% 64
4.1627 5.0550 6.7843 8.1450 9.83 11.1251 14.2658 30.363 34.234
throughput 100 kbps DL code tree UL Load CE DL 60% 60% 256
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). 7.1.4.1 Blocking and Dropping probability
Blocking probability, target: y =0.01 (1%) Linear Fit: y=a+bx Coefficient Data: a= b= Value at Y=0.01 Number of users per cell -0.0031 0.0004 32.19 6 Erl/Km^2
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. 7.1.4.2 Channel Elements usage 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. 7.1.4.3 Downlink Iub usage 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% 20,0000% 10,0000% 0,0000% 0,9700 1,9500 3,9000 7,7900 15,5800 Traffic Density [Erl/Km^2] UL Load [%]
Figure 52: Uplink Load, video-call only service
UL Load threshold = 0.60 = 60% Linear Fit: y=a+bx a= b= Value when Y=0.60 Number of users per cell Quadratic Fit: y=a+bx+cx^2 a= b= c= Value when Y=0.60 Number of users per cell -0.0094 0.0362 -0.0001 17.83 3 Erl/Km^2 -0.0051 0.0343 17.46 3 Erl/Km^2
Table 38: Estimation of the users per cell according to the simulation output, video call service, 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. 7.1.4.5 Downlink Transmitted Power
Target threshold = 90% (43 dBm) = 38.7 dBm Linear Fit: y=a+bx a= b= Value when Y = 38.7 Number of users per cell Exponential Fit: y=ae^(bx) Coefficient Data: a= b= Value when Y = 38.7 Number of users per cell 36.4057 0.0031 19.4338 3 Erl/Km^2 36,398187 0.11769338 19.55 3 Erl/Km^2
Table 39: Estimation of the users per cell according to the simulation output, video call service, 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. 7.1.4.6 Downlink Code Tree Usage 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 KPIs 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 Level 60% 64 38.7 dBm 60% 1070 Kbps 1% 256
No. users to reach the target 3
Traffic density level

17,46
UL Load CE UL DL power DL code tree Iub Blocking prob. CE DL
17.74
3
19.55
3
27.1968
5
32
6
32.19
6
49.7967
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 CE UL UL Load DL power Iub DL code tree Blocking prob. CE DL Dropped prob.
Video call UL Load CE UL DL power DL code tree Iub Blocking prob. CE DL 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. DL Iub DL power Dropping prob. CE UL throughput DL code tree UL Load CE DL
Blocking prob. DL Iub DL power CE UL DL throughput (outdoor) UL Load DL code tree 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 * Where is the call arrival rate [calls / second]. On the other hand, the Offered Poisson Traffic can be defined as: A [Erlangs] = / (7-10) (7-9)
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 (Xaxis of the graphs of KPI vs. ODV).
137
Experiment
Service
Traffic density [Erl/Km^2]
Service Bandwidth (DL) [Mbit] = BW [Kbps]/1000
Activity Factor
Offered Data Volume [Mbit/busy hour/Km^2]
1 1 1 1
total ODV Experiment 1
Speech Videocall FTP Web
10 0.97 0.39 1.62
0.0122 0.064 0.25 0.31
0.5 1 1 1
219.6 223.488 347.3916069 1827.212255 2617.691861
2 2 2 2
total ODV Experiment 2
20 1.95 0.78 3.25
0.0122 0.064 0.22 0.24
0.5 1 1 1
439.2 449.28 605.020308 2826.786672 4320.28698
3 3 3 3 total ODV Experiment 3
40 3.9 1.56 6.49
0.0122 0.064 0.17 0.19
0.5 1 1 1
878.4 898.56 933.4731671 4485.439296 7195.872463
138
4 4 4 4 total ODV Experiment 4 5 5 5 5 total ODV Experiment 5
80 7.79 3.12 12.99
0.0122 0.064 0.12 0.11
0.5 1 1 1
1756.8 1794.816 1330.948855 4998.538791 9881.103646
160 15.58 6.23 25.97
0.0122 0.064 0.06 0.04
0.5 1 1 1
3513.6 3589.632 1317.665429 3355.780886 11776.67832
Table 43: Calculation of the ODV for the Service Mix, non-homogeneous scenario
139
Experiment 1 2 3 4 5
ODV [Mbit/busy hour / Km^2] 2617.691861 4320.28698 7195.872463 9881.103646 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
Blocking probability [%] 60.0000% 50.0000% 40.0000% 30.0000% 20.0000% 10.0000% 0.0000% 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783 Blocked services [%]
Offered Data Volum e [Mbit/busy hour/Km ^2]
Figure 53: Blocking probability service mix, target =0.01 (1%)

Target threshold = 1% Harris Model: y=1/(a+bx^c) a= b= c= Standard Error: 0.01022 0.9994 2568.9699 -1608.3547 0.0500
Correlation Coefficient:
141
Value at Y=0.01
5279.6000
Mbit/hour/Km^2 Mbit/hour/cel l Mbit/sec/cell
ODV per cell per hour ODV per cell per second
926.2456 0.2572 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 Data Rate [kbps]
Average Number of Users 2 1 2 1 22 4
Web indoor FTP indoor Web outdoor FTP outdoor Voice Video-call
163,759 237,7139 156,9783 241,8718 11,97 63,65
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
dropped services [%] 10.000000% 8.000000% 6.000000% 4.000000% 2.000000% 0.000000% 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783
dropped services [%]
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= b= Standard Error: 0.0007945 0.9998536 10660 1870.1754 0.5194 519.4931 Mbit/hour/Km^2 Mbit/hour/cell Mbit/sec/cell Kbps/cell 10.937.20 -1.168.57
Correlation Coefficient: Value at Y=0.01 ODV per cell per hour ODV per cell per second ODV 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 200.0000 150.0000 100.0000 50.0000 0.0000 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783 DL Channel Elements usage [mean] DL Channel Elements usage [max]
Figure 55: Channel Elements usage service mix, Downlink target 256

180.0000 160.0000 140.0000 120.0000 100.0000 80.0000 60.0000 40.0000 20.0000 0.0000 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783 UL channel elements
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) Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value at Y=256 ODV per cell per hour ODV per cell per second ODV Kbps/cell Uplink Channel Elements (target 256) Exponential Fit: y=ae^(bx) Coefficient Data: a= b= Value at Y=64 ODV per cell per hour ODV per cell per second ODV Kbps/cell 12.8075 0.0002 6518.6300 1143.619298 0.317672027 317.6720 Mbps/hour/Km^2 Mbit/hour/cell Mbit/sec/cell Kbps/cell 18.3079 5.11E-03 7.27E-07 14899.40 2613.929825 0.7260 726.0916 Mbps/hour/Km^2 Mbit/hour/cell Mbit/sec/cell Kbps/cell
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 1000.0000 800.0000 600.0000 400.0000 200.0000 0.0000 2617.6919 4320.2870 7195.8725 9881.1036
Kbps
Iub traffic [DL]
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= b= Value at Y=1070 ODV per cell per hour ODV per cell per second ODV Kbps/cell -132.5321 0.1951 6164.99 1081.577193 0.300438109 300.4381 Mbit/hour/Km^2 Mbit/hour/cell Mbit/sec/cell Kbps/cell
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% 80.0000% 70.0000% 60.0000% 50.0000% 40.0000% 30.0000% 20.0000% 10.0000% 0.0000% 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783
Noise Rise [%]
UL Load [%]
Figure 58: Uplink load, service mix
UL Load threshold = 0.60 = 60% Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value at Y=0.6 ODV per cell per hour ODV per cell per second ODV Kbps/cell -0.1363 8.39E-05 8.16E-10 8135.76 1427.3263 0.39647 396.4795 Mbit/hour/Km^2 Mbit/hour/cell Mbit/sec/cell Kbps/cell
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 41.0000 40.0000 39.0000 38.0000 37.0000 36.0000 35.0000 34.0000 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783
Power [dBm]
DL_TxPower [dBm]

Figure 59: Downlink transmitted power usage, service mix
Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value when Y=38.7 ODV per cell per hour ODV per cell per second ODV Kbps/cell 3.68 -1.97E-05 3.75E-08 7360.59 1291.331579 0.3587 358.7032 Mbit/hour/Km^2 Mbit/hour/cell Mbit/sec/cell Kbps/cell
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
DL_Code tree usage[%] Code tree usage [%] 0.6000 0.5000 0.4000 0.3000 0.2000 0.1000 0.0000 2617.6919
Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value when y = 0.6 ODV per cell per hour ODV per cell per second ODV Kbps/cell 0.009300566 4.19E-05 8.67E-10 11406.08 2001.066667 0.555851852 555.851852 Mbit/hour/Km^2 Mbit/hour/cell Mbit/sec/cell Kbps/cell
Figure 60: Downlink code tree usage, service mix
Target Level to trigger soft congestion mechanism = 60% (0.6 in linear scale)
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
4320.2870
7195.8725
9881.1036
11776.6783
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 Blocking probability Iub utilization Downlink Power usage Uplink load Dropping probability Code Tree usage
Load to reach the target (ODV Kbps/cell)

257.2904 300.4381 358.7032 396.4795 519.4931 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 200.0000 150.0000 100.0000 50.0000 0.0000 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783
Kbps
DL Throughput
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 150.0000 100.0000 50.0000 0.0000 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783
Kbps
DL Throughput
Figure 62: Web outdoor application downlink throughput
151
FTP Indoor Application DL Throughput per user

300.0000 250.0000 200.0000 150.0000 100.0000 50.0000 0.0000 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783
Kbps
DL Throughput
Figure 63: FTP indoor application downlink throughput
FTP outdoor Application DL throughput per user
Kbps
250.0000 200.0000 150.0000 100.0000 50.0000 0.0000 2617.6919 4320.2870 7195.8725 9881.1036 11776.6783 DL Throughput
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 [Haverkampcpichstudy] 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% 40,00% 30,00% 20,00% 10,00% 0,00% 10
UL Noise Rise [%] vehicular UL Noise Rise [%] pedestrian
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 Power level [dBm] 37,2000 37,0000 36,8000 36,6000 36,4000 36,2000 36,0000 10,0000 20,0000 40,0000 80,0000 Traffic Density [Er;/Km^2] DL_TxPower [dBm] pedestrian DL_TxPower [dBm] vehicular
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 150,0000 100,0000 50,0000 0,0000 12,99 25,97 Traffic Density [Erl/Km^2]
DL Throughput (vehicular) DL Throughput (pedestrian)
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 doesnt 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 Blocking probability Iub utilization Downlink Power usage Uplink load Dropping probability Code Tree usage
Load to reach the target (ODV Kbps/cell)

257.2904 300.4381 358.7032 396.4795 519.4931 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 nonhomogeneous 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 5 4 count 3 2 1 0 42 41,65 41,3 40,95 40,6 40,25 39,9 39,55 39,2 38,85 38,5 38,15 37,8 37,45 37,1 36,75 36,4 36,05 35,7 35,35 35,00 Dow nlink Pow er [dBm] 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 Count cum ulative dis tribution function
Figure 76: Histogram of the Downlink Transmitted Power per cell, non homogeneous scenario, 160 Erl/Km2 Voice only users
Uplink Load histogram

7 6 5 count 4 3 2 1 0 86,00% 81,70% 77,40% 73,10% 68,80% 64,50% 60,20% 55,90% 51,60% 47,30% 43,00% 38,70% 34,40% 30,10% 25,80% 21,50% 17,20% 12,90% 8,60% 4,30% 0,00% Uplink Load [%] 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 Count cum ulative dis tribution function
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 U000751 U000752 U000753 U000791 U000793 U000801 U000802 U000803 U009641 U009642 U009643 U011031 U011032 U011033 U011071 U011072 U011073 U011381 U011382 U011383 U014671 U014672 U014673 U030761 U030762 U030763 U030771 U030772 U030773 U030821 U030822 U030823 U030841 U030842 U030843 U030851 U030852 U030853 U032311 U032312 U032313 U035701 U035702 U035703 U046611 U046612 U046613 U051651 U051652 U051653 U052011
DL Transmitted power [dBm] 40.34 41.21 36.79 39.47 41.37 40.01 37.75 37.99 36.47 40.65 37.37 37.09 37.80 40.98 41.36 41.64 37.89 41.19 39.79 38.47 36.98 36.55 38.58 41.37 40.06 35.96 40.81 41.17 39.63 37.97 36.64 37.22 37.73 39.95 36.76 36.37 38.44 39.43 40.67 38.04 39.77 37.23 37.05 40.47 40.76 40.13 38.12 36.60 36.13 36.29 38.81
168
U052012 U052013 average: Std. dev:
39.52 39.42
38.80 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. 8.1.1.2 Blocking and Dropping probability 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) Quadratic Fit: y=a+bx+cx^2 a= b= c= Value with Y=0.01 Number of Users per cell Linear Fit: y=a+bx Coefficient Data: a= b= Value with Y=0.01 Number of Users per cell -0.0145 0.0004 53.4073 35 Erl/Km^2 0.0068 -0.00049 5.51E-06 95.226 62 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 The cell layout has strong influence in the handover performance case the layout is not perfectly hexagonal; indeed higher probability was experienced because of the blocked radio link (handover event 1A). scenario. as in this dropping additions
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. 8.1.1.3 Channel Elements usage

DL channel elements 160,0000 140,0000 120,0000 100,0000 80,0000 60,0000 40,0000 20,0000 0,0000
00 00 00 00 ,0 0 ,0 0 ,0 0 ,0 0 0, 00 00
DL Channel Elements usage [mean] DL Channel Elements usage [max]
40
10
20
80
Figure 78: DL Channel elements usage, voice only service, non homogeneous scenario
UL channel elements 140,0000 120,0000 100,0000 80,0000 60,0000 40,0000 20,0000 0,0000
00 00 00 00 ,0 0 ,0 0 ,0 0 ,0 0 0, 00 00
16
10
20
40
80
Figure 79: UL Channel elements usage, voice only service, non homogeneous scenario
CE Usage, Downlink Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value at Y=256 Number of Users per cell Linear Fit: y=a+bx 9 0.98891575 -0.00183311 343.365 223 Erl/Km^2
171
16
Coefficient Data: a= b= Value at Y=256 Number of Users per cell CE usage, Uplink Quadratic Fit: y=a+bx+cx^2 Coefficient Data: a= b= c= Value at Y=64 Number of Users per cell Linear Fit: y=a+bx Coefficient Data: a= b= Value at Y=64 Number of Users per cell 4.6884 0.6727 88.1687 57 Erl/Km^2 -2 0.9889 -0.0018 78.6144 51 Erl/Km^2 17 0.67270421 355.964 231 Erl/Km^2
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 400,0000 300,0000 200,0000 100,0000 0,0000
Kbps
Iub traffic [DL]
00
00
00
00
,0 0
,0 0
,0 0
,0 0
20
10
40
80
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% 35,0000% 30,0000% 25,0000% 20,0000% 15,0000% 10,0000% 5,0000% 0,0000%
Noise Rise [%]
16
0, 00
00
UL Load [%]
00
00
00
00
20
40
80
10
Figure 81: Uplink load, voice only service, non homogeneous scenario
173
16
0, 00
,0 0
,0 0
,0 0
,0 0
00
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. 8.1.1.6 Downlink Transmitted Power
DL_TxPower [dBm] 40,0000 39,0000 Power [dBm] 38,0000 37,0000 36,0000 35,0000 34,0000
00 00 00 00 0, 00 ,0 0 ,0 0 ,0 0 ,0 0 00
DL_TxPower [dBm]
20
10
40
80
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
16
8.1.2 Web Service

8.1.2.1 Downlink code tree usage
DL_Code tree usage[%] 40,0000% 35,0000% 30,0000% 25,0000% 20,0000% 15,0000% 10,0000% 5,0000% 0,0000%
00 00 00 00 0, 00 ,0 0 ,0 0 ,0 0 ,0 0 00
Code tree usage [%]
20
40
10
80
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
DL_Code tree usage[%] 40,0000% 35,0000% 30,0000% 25,0000% 20,0000% 15,0000% 10,0000% 5,0000% 0,0000%
Code tree usage [%]
16
00
00
00
00
10
20
40
80
Figure 84: Downlink code tree usage, web service only, non homogeneous scenario
175
16
0, 00
,0 0
,0 0
,0 0
,0 0
00
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 Kbps 200,0000 150,0000 100,0000 50,0000 0,0000 DL Throughput
00
00 ,9 9 25 12
62
25
Figure 85: Downlink throughput, web-only service, non homogeneous scenario, indoor user
web outdoor Application DL throughput
400,0000 Kbps 300,0000 200,0000 100,0000 0,0000 DL Throughput
00
6,
62
25
49
00
6,
12
,9 9
Downlink throughput, web-only service, non homogeneous scenario, outdoor user
176
25
,9 7
1,
3,
00
,9 7
49
1,
3,
00
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.
KPI blocking probability Dropping probability Iub utilization DL power usage channel elements, UL UL Load DL code tree usage channel elements, DL
target level 1% 1% 1070 Kbps 38,7 dBm 64 60% 60% 256
ODV at target level* (Mbit/busy hour/Km^2) 3868,06 6041,83 6322,14 6646,23 9146,39 12004,6 15482,6 20656
Table 58: List of KPIs for the non-homogeneous scenario, ordered by the occurrence of the target threshold
177
KPI blocking probability Iub utilization channel elements, UL DL power usage UL Load Dropping probability DL code tree usage channel elements, DL
target level 1% 1070 Kbps 64 38.7 dBm 60% 1% 60% 256
ODV at target level* (Mbit/busy hour/Km^2) 5279.6000 6033.81 6518.6300 7360.59 8052,83 10660 11406.08 14899.40
Table 59: List of KPIs for the homogeneous scenario, ordered by the occurrence of the target threshold Comparing both tables, the main differences in order are the presence of the Dropping probability as a second element in the table of nonhomogeneous 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% 35.0000% 30.0000% 25.0000% 20.0000% 15.0000% 10.0000% 5.0000% 0.0000%
Uplink load [%]
UL Load, vehicular [%] UL Load, pedestrian [%]
00
00
00
00
.0 0
.0 0
.0 0
.0 0
10
20
40
80
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
16
0. 00
00
8.4.2 Downlink Power usage (Voice service)
comparison DL_TxPower [dBm] vehicular vs pedestrian mobility profile 40.0000 Power [dBm] 39.0000 38.0000 37.0000 36.0000 35.0000 34.0000 10.0000 20.0000 40.0000 80.0000 160.0000 traffic density [Erl/Km^2] DL_TxPower [dBm] DL_TxPower [dBm] pedestrian
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 [kbps], vehicular profile 168.62 165.40 165.24 183.67 62.79 62.63 11.93 11.93
DL Throughput [kbps], pedestrian profile 175.0435182 195.8084226 192.7750935 196.7226692 63.04505226 63.03418639 11.93639358 11.9366576
FTP UE indoor FTP UE Outdoor Internet UE indoor Internet UE outdoor Video call indoor Video call outdoor voice UE indoor voice UE outdoor
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.
de No c Se r to 1
Sector
Node B 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 (PCPICH) 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 Event Event Event 1A : add new cell 1B : remove cell 1C : replace cell (if the active set is full) 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 Bs 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.
.
Measurement Quantity
Equivalent to Timetotrigger 1A
T
CPICH 1
As_Th + As_Th_Hyst
AS_Th AS_Th_Hyst
As_Rep_Hyst
CPICH 2
CPICH 3
CPICH 2 > CPICH1 (AS_Th AS_Th_Hyst) Cell 1 Connected for a time > tAdd Cell
Time Event 1A Add Cell 2 Event 1C Replace Cell 1 with Cell 3 Event 1B Remove Cell 3
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 Value from Vodafone Netherlands (same as default value) Value from Vodafone Global Maximum value
0 millisecond 200 millisecond 320 milliseconds 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:
= + j + Bi Y ij
(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 , js and Bis 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 Where: SSA = b * (j)2 where b= number of rows
(8-5)
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) MSB = SSB / (b-1) MSE = SSE/ ((a-1)*(b-1)) (8-6) (8-7) (8-8)
At this point we can also calculate the Standard Deviation of each of the factors: SSE = STANDAR DEVIATION OF ERRORS = (MSE) Standard DEVIATION = Se/ (ab) Standard DEVIATION j = Se* ((a-1)/ab) Standard DEVIATION Bi = Se ((b-1)/ab) (8-9) (8-10) (8-11) (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 Fb = MSA/MSE (8-14) (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 (0 msec) MIX1_10Erl MIX2_20Erl MIX3_40Erl MIX4_80Erl MIX5_160E rl
199 2132 1240 3019 139329
Netherlands level (200 msec)

191 403 879 1777 8282
global level (320 msec)

191 424 873 2704 7202
max-level (5000 msec)

174 372 1785 1658 2770
Table 62: Original table for ANOVA, Cell HO attempts
191
min-level (0 msec) MIX1_10Erl MIX2_20Erl MIX3_40Erl MIX4_80Erl MIX5_160Erl

10.27% 20.30% 42.32% 72.99% 88.61%
netherlands level (200 msec)

10.20% 20.44% 43.02% 77.48% 89.38%

10.18% 20.52% 42.61% 73.75% 90.02%

10.47% 20.95% 47.21% 76.90% 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 Rows Columns Error
SS 4695850801 2778331540 10558442984
df 4 3 12
MS 1173962700 926110513.2 879870248.7
F 1.33424525 1.052553504
F crit 3.25916 3.4903
Total
18032625325
19
Table 64: ANOVA of Handover attempts, additive model
Source of Variation Rows Columns Error Total
SS 1.866556606 0.001438522 0.001846767 1.869841895
df 4 3 12 19
MS 0.466639151 0.000479507 0.000153897
F 3032.14678 3.115761269
F crit 3.25916 3.4903
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 If we take logarithm at both sides, we have an additive model: Log (Yij) = Log(Vi) + Log(Wj) (8-17) (8-16)
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 Therefore, the output in linear fashion would be: (8-19)
193
Yi = 10
* 10
* 10
Bi
* 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 msec) MIX1_10 Erl MIX2_20 Erl MIX3_40 Erl MIX4_80 Erl MIX5_160 Erl
2,298853076

2,281033367

2,281033367

2,240549248
3,3287872
2,605305046
2,627365857
2,57054294
3,093421685
2,943988875
2,941014244
3,25163822
3,479863113
3,249687428
3,432006687
3,219584526
5,14404152
3,918135226
3,857453117
3,442479769
Table 66: Logarithm transformation of the measured variable Handover attempts
min-level (0 msec) MIX1_10 Erl MIX2_20 Erl MIX3_40 Erl MIX4_80 Erl MIX5_160 Erl
-0.99

-0.99

-0.99

-0.98
-0.69
-0.69
-0.69
-0.68
-0.37
-0.37
-0.37
-0.33
-0.14
-0.11
-0.13
-0.11
-0.05
-0.05
-0.05
-0.04
Table 67: Logarithm transformation of the measured variable Uplink load
194
SS 2,041006383 0.017800402 0.208023309 2,266830094
df 3 2 6 11
MS 0.680335461 0.008900201 0.034670552
F 19,62286238 0.256707802
F crit 4,757055 5,143249
Table 68: ANOVA of Handover attempts with the multiplicative model
SS 0.745806368 0.00070624 0.000843614 0.747356222
df 3 2 6 11
MS 0.248602123 0.00035312 0.000140602
F 1768,122551 2,511480684
F crit 4,757055 5,143249
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 16 11 6 1 17 7 12 13 8 3 19 9 18 2 14 20 4 15 10 5
Load MIX1_10Erl MIX1_10Erl MIX1_10Erl MIX1_10Erl MIX2_20Erl MIX2_20Erl MIX2_20Erl MIX3_40Erl MIX3_40Erl MIX3_40Erl MIX4_80Erl MIX4_80Erl MIX3_40Erl MIX2_20Erl MIX4_80Erl MIX5_160Erl MIX4_80Erl MIX5_160Erl MIX5_160Erl MIX5_160Erl
time to trigger 5000 320 200 0 5000 200 320 320 200 0 5000 200 5000 0 320 5000 0 320 200 0
HO attempts
174 191 191 199 372 403 424 873 879 1240 1658 1777 1785 2132 2704 2770 3019 7202 8282 139329
UL Load
10.47% 10.18% 10.20% 10.27% 20.95% 20.44% 20.52% 42,61% 43,02% 42,32% 76,90% 77,48% 47,21% 20.30% 73,75% 90.28% 72,99% 90.02% 89,38% 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 11 6 7 12 13 8 9 14 15 10
Load MIX1_10Erl MIX1_10Erl MIX2_20Erl MIX2_20Erl MIX3_40Erl MIX3_40Erl MIX4_80Erl MIX4_80Erl MIX5_160Erl MIX5_160Erl
time to trigger 320 200 200 320 320 200 200 320 320 200
HO attempts
191 191 403 424 873 879 1777 2704 7202 8282
UL Load
10.18% 10.20% 20.44% 20.52% 42,61% 43,02% 77,48% 73,75% 90.02% 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 best MIX 10 Erl MIX 20 Erl MIX 40 Erl MIX 80 Erl MIX 160 Erl COUNT 0 1 0 1 0 2
Time to trigger =320 is the best 1 0 1 0 1 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)

Blocking probability 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 nonhomogeneous 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:
KPI Blocking probability Dropping probability Iub utilization DL power usage Channel elements, UL UL Load DL code tree usage channel elements, DL target level 1% 1% 1070 Kbps 38,7 dBm ODV at target level* (Mbit/busy hour/Km^2) 3868.06 6041.83 6322.14 6646.23
64 60% 60% 256
9146.39 12004.6 15482.6 20656
200
KPI Blocking probability Iub utilization Channel elements, UL DL power usage UL Load Dropping probability DL code tree usage Channel elements, DL
target level 1% 1070 Kbps
ODV at target level* (Mbit/busy hour/Km^2) 5279.6000 6033.81
64 38,7 dBm 60% 1% 60%
6518.6300 7360.59 8052.83 10660 11406.08
256
14899.40
Table 74: List of KPIs for the homogeneous scenario, ordered by the occurrence of the target threshold Comparing both tables, the main differences in order are the presence of the Dropping probability as a second element in the table of nonhomogeneous 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 doesnt 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:
KPI CE UL UL Load DL power Iub DL code tree Blocking prob CE DL Dropped prob
Target Level 64 60% 38.7 dBm 1070 Kbps 60% 1% 256 1%
No. of users to reach the target 13 16 36 37 42 49 52 62
Table 75: Ordered KPIs by number of users to reach the target, Voice-0nly service
KPI UL Load CE UL DL power DL code tree Iub Blocking prob. CE DL
Target Level 60% 64 38.7 dBm 60% 1070 Kbps 1% 256
No. users to reach the target 3 3 3 5 6 6 9
Traffic density level 17,46 17.74 19.55 27.1968 32 32.19 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 Level 1% 1070 Kbps 38.7 dBm 64 100 kbps
No. users to reach the target 2 5 8 8 12
Blocking prob. DL Iub DL power CE UL DL throughput (outdoor) UL Load DL code tree CE DL Dropping probability
60% 60% 256 1%
13 16 30 No dropping was experienced
Table 77: Ordered KPIs by number of users to reach the target, Web-only service
204
KPI
Target Level
No. users to reach the target 1 1 1 1 2 3 5 6
Traffic Density Level
Blocking prob. DL Iub DL power Dropping prob. CE UL DL code tree UL Load CE DL
1% 1070 Kbps 38.7 dBm 1% 64 60% 60% 256
4.1627 5.0550 6.7843 8.1450 9.83 14.2658 30.363 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 doesnt 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 nonhomogeneous). The next two tables summarize the results.
KPI blocking probability Dropping probability Iub utilization DL power usage channel elements, UL UL Load DL code tree usage channel elements, DL
target level 1% 1% 1070 Kbps 38,7 dBm 64 60% 60% 256
ODV at target level* (Mbit/busy hour/Km^2) 3868,06 6041,83 6322,14 6646,23 9146,39 12004,6 15482,6 20656
KPI blocking probability Iub utilization channel elements, UL DL power usage UL Load Dropping probability DL code tree usage channel elements, DL target level 1% 1070 Kbps 64 38.7 dBm 60% 1% 60% 256 ODV at target level* (Mbit/busy hour/Km^2) 5279.6000 6033.81 6518.6300 7360.59 8052,83 10660 11406.08 14899.40
Table 80: List of KPIs for the homogeneous scenario, ordered by the occurrence of the target 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 nonhomogeneous 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 nonhomogeneous scenario

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 nonhomogeneous scenario

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. 183191, 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 Mder, 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, Dsseldorf, Germany, July 2004
210
[Schneider-2] Peter Schneider, Determination of the UMTS Cell Capacity Part 2. Vodafone D2, Dsseldorf, Germany, January 2005. [Staelhe2004] Andreas Mder 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 dont 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. Deiner, 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. Deiner, J. Hbner, 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 circuitswitched (e.g. speech and new services like video calls) or packetswitched, 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
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 dont 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.
Bandwidth of baseband
Power
Bandwidth after spreading
1 Voltage -1
f 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 crosscorrelation 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. Thats 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 And also, in Frequency Domain: SF = W / R (A1.2) (A1.1)
*: 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 doesnt corresponds
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 shouldnt be possible to solve in a reasonable time. Finally, in the reception side the same transmitters 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 transmitters 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 SIDE RX SIDE
Recovered bits
Transmission medium
Spreading code
Spreading code
Scrambling code
Scrambling code
Figure 1-3: Simplified Transmission and Reception process in UMTS
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:
SIR =
S 1 = (N 1)S (N 1)
(A1.3)
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.
S Wrf EB 1 R = = N o ( N 1)S ( N 1) R Wrf
(A1.4)
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:
Gp =
TotalSpreadBandwidth Wrf = InformationBitRate R
(A1.5)
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 No
In another form:
(A1.6)
SIR =
1 Eb GP N o
(A1.6.1)
Equation (1.6.1), when the quantities are expressed in dBs, becomes:
SIR =
Eb Gp No
(A1.7)
The following figure summarizes graphically this physical process.
W Tx antenna
RF output
f 0 Data, Rb Rc f0 W= 5MHz f0
Spreading Code
Ec/Io + Gp = Eb/No, in dB or SIRtarget + Gp = Eb/No in dB

W Eb/No
Noise & interfering signals
RF input
Rx antenna
Ec/Io This is negative!

f f0 Rc W= 5MHz Spreading Code 0
Data, Rb
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:
Rc 3.84 10 6 2 = G p = 10 log 10 log 12.2 10 3 = 10 log 3.15 10 = 25dB R b
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).
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. SIRtarget = 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.
Ec Ec Ec 1 10 log = 2 N = 10 2 N o = 100 Ec N = 20dB log N o o o
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.
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 [Umtsforum6] 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
Iub Node B RNC Iu-CS MSC/V
CN
CS-Domain
GMSC
.... Node B
Iub
HLR Iur RNC ... Iu-PS SGSN GGSN
Uu (air interface)
.... Node B
Iub
PS-Domain
Simulation Scope
Figure 1-6: UMTS Architecture (Rel-99) UE (User Equipment)
PS Networks (Internet..)
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 Bs 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 Bs; 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 Bs. When a mobile is connected to Node Bs controlled by different RNCs, 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 users 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 circuitswitched 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 Bs 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 1 () 10
Default Class Water 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 georeferenced 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 Default Suburban: <6m Garden Suburban: <6m Suburban: <6m Dense Suburban: <9m Wooded Suburban: 6-9m Garden Suburban: 6-9m
Weight 0 10 10 10 10 10 10
% Indoor 0 30 30 30 30 30 30
21
Suburban: 6-9m Dense Urban: 9-12m Open Urban: 9-12m Urban: 12-18m Open Urban: 12-18m Urban: 18-27m Open Urban: 18-27m Urban: 18-27m Dense City: 27-40m Open City: 27-40m City: >40m
10 15 15 15 15 15 15 15 20 20 20
30 50 50 50 50 50 50 50 60 60 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. Deiner, J. Hbner, 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

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, Mathematics and Computer Science (EEMCS)

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

1.2 Problem Statement

1.3 Objectives and scope this work

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

1.4 Problem Solving Approach

1.4.2 Activities before simulation

1.4.3 Activities during Simulation

1.4.4 Activities after Simulation

1.5 Document Structure

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

2. Capacity and Simulation (introductory) concepts

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

2.2 Soft capacity vs. hard capacity

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

2.3 Capacity management vs. capacity planning

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

2.4 Performance Evaluation Techniques

2.4.1 Why Simulations are the right option in this case?

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

2.4.2 Limitations of the simulations

2.5 Summary of Chapter 2

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

3. The Radio Planning Process (literature study)

3.1 The Radio Planning Process (ITUs IMT-2000) vision

Definition of the radio parameters, WCDMA and marketing

Number of sites Inter-site distance

Capacity and coverage planning

Base station configuration,

Network performance simulation

Network analysis Theorical validation

Real sites search

Radio site validation

Radio planning process

3.1.1 Definition of the radio Parameters, WCDMA and marketing

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

Assume Initial Interference Noise Rise, e.g. Ico = 3 dB

Choose the limiting cell range (smallest one)

Apply System-level simulation for a given cell load (e.g. ul=99%)

Calculate Interference level

Try with new value of Ico Converge nce of Ic and Ico?

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

3.1.3 Detailed Capacity, Coverage Planning and Network Performance Simulation

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

3.1.4 Real sites search

3.2 Summary of chapter 3

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

4. Introduction to Wines Dynamic System-level Simulator

4.1 Different Simulation Approach: Static vs. Dynamic

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

4.3 Discrete Event Simulation vs. Continuous Time Simulation

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

Figure 4: Wines Workflow [Schneider]

4.4 Wines Main Features

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

4.4.1 Dynamic User Traffic Modeling