Thesis Hurtado

University of Twente

Faculty of Electrical Engineering, Mathematics and Computer Science

(EEMCS)

UMTS Capacity simulation study

Andrés Felipe Cosme Hurtado

Master of Science in Telematics Thesis

(Carried out at Vodafone Netherlands)

Project Supervisors:

• Dr. ir. Geert Heijenk, University of Twente

• Prof. Dr. ir. Boudewijn Haverkort, University of Twente

• Dr. ir. Bert Haverkamp, Vodafone Netherlands

Copyright © October 2005, Andrés Felipe Cosme Hurtado, Maastricht, The Netherlands

i

Abstract

The purpose of this report is to investigate the performance, measured in terms of Key Performance Indicators (KPIs) of a UMTS radio network (UTRAN) under different traffic and mobility scenarios (i.e. homogeneously/ non homogeneously distributed traffic, mobile/non-mobile traffic) and develop some general guidelines for dimensioning the UMTS network optimally.

In this work, simulations are performed using the Wines simulator, which is a dynamic simulator that models all the radio-resource management functionality of the UTRAN. Two main series of experiments have been performed. In the first series simulations have been performed on an analysis area defined in common agreement with international colleagues at Vodafone. The distribution of the traffic in this simulation scenario is homogeneous and the main purpose is to find capacity figures when increasing the traffic density of one of the four possible defined services (WWW, FTP, voice and video-call) and also with a given traffic mix involving all services together. Two mobility profiles are used (pedestrian and vehicular).

In the second series of experiments, a more realistic scenario, based on detailed geographical characteristics relevant for signal propagation, and traffic densities based on traffic maps, has been simulated. The purpose was to analyze the possible differences in capacity between the “ideal” model and the more “realistic” model.

For the single-service scenario analysis, circuit-switched services (speech and video-call), it can be observed that the capacity is mainly uplink-limited. The corresponding results for the packet-switched services (FTP, WEB) have shown that capacity is mostly downlink-limited, as it was expected due to the more asymmetrical data rates in the downlink compared to the uplink for both services.

For the service mix analysis in both scenarios (homogeneous and non homogeneous) it was found that the capacity is mostly downlink-limited (i.e. the downlink power target level is exceeded before the uplink load target level).

In terms of the power-rule usage, no significant differences between the two analyzed rules were found, provided that the downlink path loss between the Node B connector and the antenna is below 4 dB in all the sites.

Finally, for the mobility study in both scenarios (homogeneous, non homogeneous) the theoretically expected behavior was confirmed.

A.F. COSME. UMTS CAPACITY SIMULATION STUDY

ii

Acknowledgements

I want to express my gratitude to my Direct Supervisor at University of Twente, Dr. Geert Heijenk. His knowledge, experience and valuable suggestions and corrections gave me the effective support when I couldn’t find an answer by myself. Special thanks also to Prof. Dr. Boudewijn Haverkort who was also part of my evaluation committee.

I wish to thank also my supervisor at Vodafone-NL, Dr. Bert Haverkamp, for giving me the opportunity to be part of this excellent group of people. Your help was very important to me, not only in the technical side but also with the support in everyday tasks, especially at the beginning of my internship when everything was totally new to me and I didn’t know anyone except you. Thank you very much.

I would like to express also my gratitude to all the Vodafone IT-Network Department (and in general, to all the people at Vodafone that I had the opportunity to meet) as they always gave me support and were always willing to help me whenever I need it and besides, they were cheering me up and encouraging me to make a good work. I hope not to accidentally omit anyone in my list: I want to say many thanks to Greg Vourekas, Jamaal Tajaate, Ralph Thijssen, Roy Crutsen, Roy Hermans, Bianca Wouters, Simon De Kerpel, Yvonne Lemeer, Zoltan Pitman, Tjitte Ploegstra, Debbie Smits and Arjen Meuers. It was a great experience and a real pleasure to work with such nice persons and high-level professionals like you; I’m going to miss you! I wish you all the best in your professional careers. Special Thanks also to Peter Schneider and Kai Pannhorst from Vodafone Germany for all the Support with the Wines Simulator Tool. One of the nicest experiences of working here was to be able to work with great people from many other countries!

I’m also very grateful to my Lord Jesus Christ, in whose name and in whose precepts I try to aim every action in my life.

And last but not least, I want to thank all the support and understanding from my friends in Colombia, Spain and The Netherlands and to all my family, specially to my mother Imelda Rocío, my sister María Claudia, and my father Galo Alberto, who always encourage me to pursue higher goals and cheer me up in the difficult moments. God bless you all and this work is dedicated to you.

iii

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


iv

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

v

SRNC Serving RNC

TDMA Time Division Multiple Access

TE Terminal Equipment

TPC Transmission Power Control

UE User Equipment

UL Uplink

UMTS Universal Mobile Telecommunications System

UTRAN UMTS Terrestrial Radio Access Network

VoIP Voice over IP

W-CDMA Wideband - Code Division Multiple Access

Wines Radioplan’s WIreless NEtwork System


vi

Table of contents

1. INTRODUCTION .........................................................................................................15 1.1 PRELIMINARY CONCEPTS ABOUT UMTS CAPACITY 15 1.2 PROBLEM STATEMENT 16 1.3 OBJECTIVES AND SCOPE THIS WORK 17

1.3.1 General Objective 17 1.3.2 Scope 17

1.4 PROBLEM SOLVING APPROACH 18 1.4.1 Assignment parts 18 1.4.2 Activities before simulation 18 1.4.3 Activities during Simulation 19 1.4.4 Activities after Simulation 19

1.5 DOCUMENT STRUCTURE 19

2. CAPACITY AND SIMULATION (INTRODUCTORY) CONCEPTS .........21 2.1 THE CAPACITY AND KPI CONCEPTS 21 2.2 SOFT CAPACITY VS. HARD CAPACITY 23 2.3 CAPACITY MANAGEMENT VS. CAPACITY PLANNING 25 2.4 PERFORMANCE EVALUATION TECHNIQUES 26

2.4.1 Why Simulations are the right option in this case? 27 2.4.2 Limitations of the simulations 28

2.5 SUMMARY OF CHAPTER 2 29

3. THE RADIO PLANNING PROCESS (LITERATURE STUDY) ..................30 3.1 THE RADIO PLANNING PROCESS (ITU’S IMT-2000) VISION 30

3.1.1 Definition of the radio Parameters, WCDMA and marketing 31 3.1.2 Dimensioning 32 3.1.3 Detailed Capacity, Coverage Planning and Network

Performance Simulation 36 3.1.4 Real sites search 38


4. INTRODUCTION TO WINES DYNAMIC SYSTEM-LEVEL SIMULATOR ..................................................................................................................40 4.1 DIFFERENT SIMULATION APPROACH: STATIC VS. DYNAMIC 40 4.2 THE LEVEL OF DETAIL OF THE SIMULATION: SYSTEM LEVEL VS. LINK LEVEL 43 4.3 DISCRETE EVENT SIMULATION VS. CONTINUOUS TIME SIMULATION 43 4.4 WINES MAIN FEATURES 45

4.4.1 Dynamic User Traffic Modeling 46 4.4.2 The Service Arrival (Activation +Service) process and the

initial arrival (transient) process 47 4.4.3 The UE profile 48 4.4.4 The Service Profile 49 4.4.5 The data unit arrival process (“Traffic Models”) 51


vii

5. DESCRIPTION OF THE FIRST SIMULATION SCENARIO AND GENERAL SETUP OF THE SIMULATION EXPERIMENTS.......................56 5.1 SIMULATION AND ANALYSIS AREAS 56 5.2 ENVIRONMENT ASSUMPTIONS 57 5.3 DEFINED SERVICES AND TRAFFIC MIX 58 5.4 SERVICE CONFIGURATION 59

5.4.1 Radio Bearer Properties 59 5.4.2 Signal to Interference Ratio 60 5.4.3 Service Prioritization 61 5.4.4 Optional Semi-Dynamic Mode 61 5.4.5 Physical Layer parameters 61 5.4.6 Traffic Model parameters 62 5.4.7 Traffic Matrices 64

5.5 GENERAL NETWORK LAYOUT ASSUMPTIONS 65 5.5.1 RNC assumptions 65 5.5.2 Node B assumptions 65 5.5.3 Cell assumptions 66

5.6 DEFINED KPI’S (KEY PERFORMANCE INDICATORS) 66 5.6.1 KPIs for Circuit switched services (Voice, Video Tel): 67 5.6.2 KPIs for Packet switched services (WWW, FTP) 67 5.6.3 Defined KPI Thresholds 67

5.7 GENERAL SIMULATION SETTINGS 72 5.8 SIMULATION PLAN 72

5.8.1 Homogeneous Scenario 73 5.8.2 Non-homogeneous Scenario 76 5.8.3 Analysis of a specific network parameter 79


6. DESCRIPTION OF THE SECOND SIMULATION SCENARIO (NON-HOMOGENEOUS) .......................................................................................................82 6.1 SIMULATION AREA AND ANALYSIS AREA 82 6.2 CLUTTER CLASSES AND DEM (DIGITAL ELEVATION MODEL) 84 6.3 NON – HOMOGENEOUS TRAFFIC MAP GENERATION 85 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


viii

7.3.2 NETHERLANDS SETTINGS: 156 7.4 MOBILITY STUDY 158

7.4.1 Blocking and Dropping probabilities (Voice service) 159 7.4.2 Uplink load (Voice service) 160 7.4.3 Downlink Power usage (Voice service) 161 7.4.4 Throughput (Web service) 161

7.5 SUMMARY OF CHAPTER 7 163 7.5.1 Single service experiments 163 7.5.2 Traffic mix homogeneous scenario 164 7.5.3 Power study 164 7.5.4 Mobility study 165

8. SIMULATION RESULTS SECOND SCENARIO (NON-HOMOGENEOUS) AND COMPARISON WITH THE HOMOGENEOUS SCENARIO ...................................................................................................................166 8.1 SUMMARY OF THE SINGLE-SERVICE SIMULATIONS 166

8.1.1 Voice Service 166 8.1.2 Web Service 175

8.2 SERVICE MIX 177 8.3 POWER STUDY, TRAFFIC DENSITIES FOR GERMANY AND THE NETHERLANDS 179 8.4 MOBILITY STUDY 180

8.4.1 Uplink load (Voice service) 181 8.4.2 Downlink Power usage (Voice service) 182 8.4.3 Downlink Throughput 182

8.5 ANALYSIS OF THE IMPACT OF A PARAMETER SETTING IN THE OVERALL PERFORMANCE OF THE UTRAN 183 8.5.1 The parameter Timetotrigger1a and its influence on the

Handover algorithm 183 8.5.2 The Analysis framework 187 8.5.3 Simulation Results 191

8.6 SUMMARY, CHAPTER 8 199 8.6.1 Circuit switched services (voice service) 199 8.6.2 Packet Switched Services 200 8.6.3 Traffic Mix Analysis 200 8.6.4 Power study 201 8.6.5 Mobility study 201 8.6.6 Analysis of the impact of a parameter setting in the overall

performance of the UTRAN 202

9. CONCLUSIONS AND FUTURE WORK ............................................................203 9.1 SINGLE SERVICE ANALYSIS 203

9.1.1 Circuit switched services, homogeneous scenario 203 9.1.2 Packet switched services, homogeneous scenario 204

9.2 SERVICE MIX ANALYSIS 206 9.3 POWER RULE USAGE, HOMOGENEOUS AND NON-HOMOGENEOUS SCENARIO 207 9.4 MOBILITY STUDY, HOMOGENEOUS AND NON-HOMOGENEOUS SCENARIO 207 9.5 ANALYSIS OF THE PARAMETER TIME TO TRIGGER 1A 208 9.6 OPEN ISSUES AND FURTHER RESEARCH TOPICS 208

1. APPENDIX: UMTS FUNDAMENTAL CONCEPTS ...........................................1 1.1 WHAT IS UMTS? 1 1.2 TECHNICAL CHARACTERISTICS 1

ix

1.3 CHANNELIZATION (SPREADING) CODES 3 1.4 SCRAMBLING CODES 5 1.5 THE PROCESSING GAIN, SIR (SIGNAL TO INTERFERENCE RATIO) AND EB/NO

CONCEPTS IN UMTS [VOUREKAS] 6 1.6 UMTS ARCHITECTURE (REL99) 10 1.7 RADIO RESOURCE MANAGEMENT ALGORITHMS 13

2. APPENDIX: PROCEDURE FOR EXPORTING A TRAFFIC MAP BASED ON CLUTTER DATA FROM ATOLL TO WINES .............................................16 2.1 PROJECT EXPORT TO A *.MDB FILE 16 2.2 EXPORT OF THE COMPUTATION ZONE AND FOCUS ZONE 17 2.3 EXPORT THE PATH LOSS DATA TO RASTER DATA FILES 17 2.4 EXPORT THE CLUTTER MAP AND CLUTTER CLASSES DEFINITION 18 2.5 EXPORTING BACKGROUND MAPS WITH ATOLL 19 2.6 EXPORTING DEM (DIGITAL ELEVATION MODEL) INFORMATION 19 2.7 TRAFFIC MAP(S) AND ENVIRONMENT CODES DEFINITION 19


x

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

xi

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


xii

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

xiii

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 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 2-1: Example of assigned clutter class weights ..............................................................22

15

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]).


16

1.2 Problem Statement

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

Specifically, there are two big challenges when performing capacity dimensioning in UMTS Networks:

• In UMTS capacity changes dynamically according to several factors

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

• It is difficult to dimension multiple data rates, switching modes and

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

Summarizing, the problem statement is, taking into account these challenges; try to develop some guidelines for UMTS capacity dimensioning based on the analysis of simulation results of a UMTS network.

17

1.3 Objectives and scope this work

1.3.1 General Objective

The main goal/objective of this assignment is to investigate the performance (measured on a defined set of Key Performance Indicators (KPI’s)) of a UMTS terrestrial radio access network (UTRAN) under different scenarios and perform an analysis of the simulation results in order to develop methods for dimensioning the network optimally.

Examples of such scenarios are:

• Homogeneously distributed, non-mobile traffic • Homogeneously distributed, mobile traffic • Non-homogeneously distributed, non-mobile traffic • Non-homogeneously distributed, mobile traffic

Part of the assignment is also to verify the behavior of the UMTS network with a limited number of parameters in the simulator using and/or mapping the UMTS current network settings in the real Vodafone UTRAN (Ericsson RRM parameters).

1.3.2 Scope

• The assignment is aimed to perform a capacity simulation study.

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

• The assignment doesn’t include the radio-planning stages of

Optimization and Monitoring which are out of the scope of it.

• The tool to use to perform the Dynamic Simulations will be Radio Plan

Wines.

• The UMTS-WCDMA part of the system to study includes the radio

network part (UTRAN) and its corresponding RRM algorithms. It doesn’t include the Core Network dimensioning.


18

1.4 Problem Solving Approach

1.4.1 Assignment parts

For the first part of the assignment, simulations are going to be performed over an analysis area defined in common agree with our international colleagues of Vodafone. The distribution of the traffic in this simulation scenario is homogeneous and the main purpose is to find capacity Figures when increasing the traffic density of one of the four possible defined services (WWW, FTP, Voice and Video-call) and also with a given traffic mix involving all services together. Two mobility profiles are used (pedestrian and vehicular).

In the second part of the assignment, a more “realistic” scenario (scenario based on real clutter data) is simulated (the traffic density is no longer homogeneously distributed). The purpose is to analyze the possible differences in capacity between the “ideal” model and the more “realistic” model.

Part of the assignment is to verify a number of parameters in the simulator regarding Vodafone current UMTS network settings.

To achieve the proposed objectives, the project involved a lot of different activities that had to be performed before, during and after the simulations. A summary list with these activities is provided here:

1.4.2 Activities before simulation

• Understand the UMTS-WCDMA Radio Resource Management algorithms (including Power Control, channel switching, handover, capacity management and connection handling).

• Understand how the different propagation phenomena (like path loss, shadowing, fast fading, intra-cell interference, inter-cell interference, pilot pollution) impact the performance of a UMTS RAN and how they are modeled and what assumptions are made for the simulation of these phenomena.

• Get acquainted with the whole radio-planning process (specially with the capacity dimensioning part) which is aimed to balance coverage and capacity while meeting the KPIs (Key Performance Indicators) thresholds

• Investigate the state-of-art of radio capacity planning for UMTS-WCDMA and, according to the simulation analysis, propose some general guidelines for Vodafone Engineers.

• Get acquainted with the Dynamic Simulation Tool (Radio Plan), its different options and parameters, the models they use internally to

19

make the simulation, understand its limitation and capabilities and try to determine how different should be a real-world scenario compared with a simulation-scenario.

• Get acquainted with statistical techniques (especially design of experiments, 2^k factorial designs) to perform a systematic analysis of the simulation results.

• Propose different simulation scenarios, agree in the Traffic Mix to be used (service and service portion definition), Agree in the Traffic Model (Data arrival process) for each service and estimate the corresponding traffic densities to be simulated.

• Get acquainted with Ericsson Documentation of Vodafone Netherlands UMTS-WCDMA equipments; understand its different parameters and how they should be mapped to Wines in order to perform simulations with realistic network settings.

1.4.3 Activities during Simulation

• Perform the corresponding experiments (simulations) under different

conditions (different traffic distributions, different mobility profiles).

1.4.4 Activities after Simulation

• Collect the results and perform comparative analysis using specific KPI’s of the simulations under those different scenarios.

• Perform sensitivity analysis over a limited set of UTRAN parameters. • Give conclusions that help to dimension the radio-access network

optimally having into account the obtained results.

1.5 Document Structure

The structure of the chapters is as follows:

Chapter 1 Presents the problem statement, the objectives and scope of the work and the approach used to solve it.

Chapter 2 Introduces the required concepts about simulations and capacity studies.

Chapter 3 presents the results of the literature study concerning radio planning methods for UMTS including the capacity analysis and capacity planning parts.


20

Chapter 4 is an introduction to the Wines Dynamic Simulator and its main features.

Chapter 5 introduces the first simulation scenario, it’s main characteristics, the list of assumptions, including the load parameters (traffic models) and the system parameters (UMTS Network parameters of the RNC, Node Bs and Cells), and the design of the experiments required to collect the information.

Chapter 6 introduces the second simulation scenario with its main characteristics, list of assumptions and the corresponding design of the experiments.

Chapter 7 presents the analysis of the simulation results of the 1st simulation scenario.

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

Chapter 9 presents a comparison between the results obtained for the “ideal model” and for the “more realistic” one.

Chapter 10 draws the conclusion of this work and proposes the future work.

Moreover, the following appendixes are also provided:

Appendix 1: UMTS fundamental concepts (it is aimed to introduce the required concepts for the reader who is not familiar with UMTS).

Appendix 2: Procedure for exporting a simple traffic map based on clutter data from ATOLL to Wines

Appendix 3 (confidential): Traffic Model parameters

Appendix 4 (confidential): System parameters

Additionally, all the Excel sheets containing the simulation outputs and the summary sheets where the statistical analysis was performed per each Scenario /KPI level are also provided.

21

2. Capacity and Simulation (introductory) concepts

2.1 The capacity and KPI concepts

One of the first tasks of this work was to clearly define what is understood by capacity within the scope of the project. In the consulted literature [Jain] [Holma], [Madder], [ITU], several different definitions about capacity were found. The idea of “capacity” therefore, is not a single one as far as literature about system performance concerns.

Generally speaking, capacity is a measure of how able a system is to provide an acceptable response to its users, when the conditions of the load are varied from low to high. This response has to be measured in what is called a KPI (Key Performance Indicator). Two of the most common KPI’s, present in almost every telecommunications system, are throughput and response time. For the purpose of measuring each performance indicator, each KPI has to be clearly defined (the “what”) as well as in the specific system, one has to be able to define the mechanism(s) to measure it (the “how”).

About throughput and response time, which are commonly used in this type of studies, two very concise definitions can be found in [Jain] and they are as follows:

Response Time is defined as the interval between a user’s request and the system response. However, one has to take into account that the requests as well as the responses are not instantaneous: the user takes time generating a request, and the system also takes time to produce a response. Then, two possible definitions of the response time would be:

• Definition 1: The time interval between the end of a request

submission and the beginning of the corresponding response from the system

• Definition 2: The time interval between the end of a request

submission and the end of the corresponding response of the system.


22

Both definitions are acceptable, however the last one seems to be the most widely used. Both are illustrated in the next graph.

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).

User User

fi i h

System System System

l

User

Starts

Reaction

time

Response Time

Response Time

Think

23

2.2 Soft capacity vs. hard capacity

In WCDMA systems, the capacity has a very important feature: it has no single-fixed value; system capacity in UMTS is a stochastic value that depends on several factors: multi-path propagation, orthogonality in UL/DL, thermal noise, received interference at the mobiles and Node B, among the main ones.

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

In contrast, in 3G systems, the capacity cannot be expressed as a single value; it has to be defined as a set of resources interacting among them. Among the most important ones, we can mention Soft capacity resources and hard capacity resources:

• Soft capacity resources: refers to the resources limited by the load

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

• Hard capacity resources: refers to the hardware resources

associated to each radio link, normally known as channel elements (although this name varies according to the manufacturers). Each manufacturer defines a given number of channel elements per each Radio Access Bearer, and these number of channel elements are also an indicator of how many Hardware Boards are required per each Node B. Hard capacity includes also the capacity of the link(s) between every node B and its controlling RNC; this link is defined in the UMTS architecture as the Iub interface.


24

Therefore, having defined both “soft” and “hard” capacity resources, one can also talk about “soft blocking probabilities” and “hard blocking probabilities”: Hard blocking probabilities are easy to calculate in hard capacity limited systems using known models (Erlang B or Erlang C). This models are very accurate when calculating single service, circuit switched traffic (e.g. Speech-only service), given that the assumptions made in the model (exponential inter arrival times and exponential call duration) are generally true for Telephony systems.

On the other hand, Soft Blocking probabilities cannot be calculated from Erlang-B formula, given that it would give too pessimistic results. Besides, the resource consumption of a single connection depends on the interference situation as well as the type of service (voice, CS-64, PS-384, etc) and it is not quantizable, which is one of the basic assumptions of the Erlang Model. In contrast, for hard capacity, each connection consumes always the same amount of hardware resources depending on the service, independent on the interference situation and the position of the mobile regarding the Node B Antenna.

Summarizing, the capacity of a 3G cell is described not by a single number but by the utilization of a set of hard and soft resources, being the most relevant ones:

Soft Resources:

• Uplink Interference • Downlink Power • Downlink Spreading code usage

Hard Resources

• Baseband capacity (channel elements) • Iub capacity (UL and DL, Kbps)

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

25

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.


26

2.4 Performance Evaluation Techniques

The capacity planning and capacity analyses are by themselves two cases of performance evaluation over complex systems with complex dynamics in space and time.

We could say, generally speaking, that there are three techniques to face the performance evaluation of a system like UMTS RAN:

Analytical Modeling Simulation Measurements

There are advantages and disadvantages for each one of the techniques, so basically the selection of one, or a combination of such techniques (in practical problems, the use of two or more techniques is a common approach), depends very much on the problem and it has to take into account important considerations, such as:

life-cycle stage of the system Time and knowledge required Costs Availability of Tools Accuracy

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

In terms of statistical and probabilistic complexity, we are facing a system with a dynamic mix of services, with different rates and switching modes; and a system that changes dynamically its coverage and capacity. Currently, there are no closed-form well-known analytical solutions for modeling multi-service traffic in UMTS. The traditional static approach used in voice-only

27

networks, the Erlang-B and Erlang C models, works well in such kind of single-service voice-only networks, but there is no way to apply directly the Erlang model when we have a mix of circuit-switched and packet-switched services sharing the air interface, as in the UMTS case.

Besides, the data arrival models, also known as traffic models, are very different between circuit-switched and packet-switched services. The way we traditionally model circuit-switched services with a Poisson arrival process (process that states that call arrivals are mutually independent and the call inter-arrival times are all exponentially distributed with one and the same parameter λ), doesn’t fit very well with packet-switched services, because Poisson arrival cannot cope with the burstiness (i.e. high variability: from extremely short service times to extremely long ones and from extremely low-rate to extremely high-rate connections) of these services. Some interesting approaches to cope with the burstiness of data traffic using fractal distributions are presented by Willinger and Paxon in their papers [Mathforinternet] and [Wedontknow].

Therefore, in this very complex scenario where a single closed-form analytical model cannot be used and also a measurement over the current system is not representative, one could say that Simulations can be the best approach to deal with UTRAN air interface capacity-related issues. The argumentation about the Simulation approach is presented in the next section.

However, in practice, the best combination is to validate simulation with analytical modeling, in order to verify and validate the results of each one. To this respect, [Jain] presents three practical simple validation rules:

• Do not trust the results of a simulation model until they have been validated by analytical modeling or measurements.

• Do not trust the results of an analytical model until they have been validated by a simulation model or measurements.

• Do not trust the results of a measurement until they have been validated by simulation or analytical modeling.

One of the future-work activities that are proposed on this report is the validation of Simulation Results using measurements. This was considered out of the scope of this project due the limited amount of time.

2.4.1 Why Simulations are the right option in this case?

First of all, simulations are an easy way to predict the performance or compare several alternatives.


28

For instance, with simulations, it’s easy to answer questions like “What happens if we modify X parameter at Y value?” without performing costly live lab tests or making test over the production network (a practice that should be avoided at all given the serious effects that can be caused on it).

Secondly, a simulation also has the advantage over the analytical approach that the model can be more detailed (i.e. with less simplifying assumptions) and therefore its results more close to the reality.

Thus, if we have a tool that mimics the Radio Resource Management Algorithms with a good level of detail, we can try different configuration settings in the network elements and see the performance of the network, before making any change in the real network setup.

Simulations are also a good option when modeling system dynamics based on stochastic processes: in the tool being used, each user of the system is modeled as a random process that asks for a service and moves in space and time and at every time interval the contribution of the other users to the overall network performance is being tested; this would be something very difficult to model just with the help of analytical techniques.

Finally, simulations allow us to test the system under different workloads and environments; i.e. changing the environment parameters, we can observe how the network with the same system parameters setting behaves in terms of KPIs.

2.4.2 Limitations of the simulations

As it was mentioned before, we cannot provide absolute Figures with simulations: all the Figures that we get are valid just for the scenario being tested and under the assumptions being made.

We cannot ask also for accuracy in the results, unless we have some feedback (measurements) from a real system to make a comparative analysis of the outcomes (simulation tuning).

Third disadvantage of the simulations is the time that they take and the knowledge required to parameterize the system (as simulations can model the system in a more detailed way than the analytical approach); usually the more detailed the simulation tool, the longer time it takes. Also, when making statistical analysis over the simulation results that involves inter-relations among parameters, the complexity (and time) of these analysis depends on the number of parameters (factors) to be analyzed and the number of levels (values) defined for each parameter. There are some statistical techniques, as the ones mentioned in [Jain] that try to reduce the complexity and deal with these kinds of analysis. These techniques are going to be applied in this report whenever it is possible.

29

2.5 Summary of Chapter 2

Why to use simulations?

With simulations, it’s easy to answer questions like “What happens if we modify X parameter at Y value?” without performing costly live tests.

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

Simulations also allow us to test the system under different environment settings (i.e. urban, rural, with/without shadowing, etc); then changing the environment parameters, we can observe how the network with the same system parameter setting behaves in terms of KPIs in the new environment. Detailed environment data can be exported from common radio planning tools to Wines Dynamic simulator.

Currently, two simulation approaches regarding the time dependence of the results are used in Radio Planning: Static (also called Snapshot or Montecarlo simulations) and Dynamic simulations. The main difference between them is presented in the corresponding section of the chapter 4.

Limitations of the simulations

We cannot provide absolute Figures with simulations: all the Figures that we get are valid just for the scenario being tested and under the assumptions being made.

We cannot ask also for accuracy in the results, unless we have some feedback (measurements) from a real system to make a comparative analysis of the outcomes (simulation tuning). As a future work, it is proposed a study that allows testing the accuracy of the simulation results with Wines comparing them with measurements from the live UMTS network.

Another disadvantage of the simulations is the time that they take (specially Dynamic simulations are very time and resource consuming) and the knowledge required to parameterize the system.


30

3. The Radio Planning Process (literature study)

The process of UMTS-WCDMA Radio Planning is well described in the literature [Holma], [ITU], [Alcatel], [Jaber], [Dinan]. All of them make reference to the required steps of

Dimensioning Detailed Capacity and Coverage planning Network Optimization

The differences in the descriptions are basically in the way those steps are connected and how they implement the feedback. For this study, I will introduce the Radio Planning Process using the ITU IMT-2000 vision presented in [ITU], although the description of each activity is complemented with all the information mentioned in all the literature consulted regarding this process.

3.1 The Radio Planning Process (ITU’s IMT-2000) vision

The following graph illustrates the key steps of the UMTS W-CDMA Radio Planning process according to [ITU]

31

Definition of the radio parameters,WCDMA and marketing

Dimensioning

Capacity and coverage planning

Network performance simulation

Real sites search

Number of sitesInter-site distance

Base stationconfiguration,

Network analysisTheorical validation

Radio site validation

Traffic prediction

Results

1

2

3

4

Radio planning process

5

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


32

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.

33

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)

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)

Try with new value of Ico

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

Convergence of Ic and Ico?

Current Radius is UL cell radius


34

Where:

• NF = Node B noise Figure [dB] • No = thermal noise density, normally assumed to be -174 dBm/Hz • Eb/No k = Eb/No for the service k (linear Figure) • Rk: Service k bit rate (bps) • ioi = Noise Rise due to interference (linear Figure)

To calculate the Maximum path loss, the following equation is used

Lmax, i = PULk – Required_Leveli – Σ losses – Σ margins + Σ gains (3-2)

Where:

PULk is the mobile power valid for service k [dBm]. In equation 3-2, all the

Losses, margins and gains are given in dBs.

Once determined this Figure for all services, the smallest Lmax is chosen as the limiting maximum path loss. And applying a propagation model (e.g. Okumura-Hata, Walfisch-Ikegami); we can derive the corresponding cell range.

Now, we have to find the cell load to be able to determine the interference over noise rise and compare this Figure, at the end of the UL iteration process (the final decision symbol of Figure 11), with the initial assumption .

First, for each service, we can deduce the traffic per cell as the number of subscribers per square kilometer is known or assumed from the previous step in the radio planning process and the area can be expressed in terms of the cell range found; for instance for an hexagonal cell with omni-directional antenna, the area is around 2.6R2, where R = cell range [Kms].

The next step is to calculate the load in the cell, several approaches are mentioned in [Alcatel], [Holma], [Jabber], the one presented in [Jaber] which is based on a modified stochastic knapsack model for multi-service UMTS capacity analysis says:

ηul (uplink load factor) = number of active users / Pole Capacity (3-3)

Where “Pole Capacity” means 100 % cell load and is given by:

Npole, UL = W / (1 + ful) Σ j=1..k Vj * Rj * Pj [Eb/No j / (1 + Eb/No j *Rj /W )]] ( 3-4)

Where: • W : chip rate, in W-CDMA is fixed to 3.84 Mchips/sec • K = number of offered services • Eb/No j is the required Eb/No for the service j (j=1…k) • Rj is the bit rate of service j • vj is the activity factor of the service j.

35

• 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.


36

3.1.2.3 Estimation of the number of required cells

Based on the capacity and link budget, the number of cells required to cover a given area can be calculated. A UMTS network can either act as a coverage or capacity limited in any given moment. Capacity limited means that the maximum cell radius can’t support the total offered traffic because there are not enough resources to do it. Coverage limited means that there is enough capacity in the cell to support the traffic, but the maximum cell range of a mobile (because it’s limited transmission power) limits it. [ITU]

3.1.3 Detailed Capacity, Coverage Planning and Network Performance Simulation

After the cell count has been obtained in the previous step, detailed radio network planning, taking into account the exact radio environment (with high resolution geographical data and accurate propagation models) can start with the goal to calculate the optimum base station locations, configurations and parameters; and to analyze the network global performance in terms of capacity and coverage [ITU]. Both planning processes (capacity and coverage) are performed with the help of a specialized Tool (the system-level simulator), which corresponds to the “Network performance simulation” element mentioned in the ITU's IMT-2000 Radio Planning Process. Both processes are going to be described as Detailed Coverage and Capacity Planning in the next sections. The output of both processes (which are performed simultaneously in UMTS) is the analysis of the simulation results in terms of network performance.

3.1.3.1 Detailed Coverage Planning

Once we have the Figures of the previous steps, detailed radio planning, taking into account information about the radio environment (high resolution geographical data, clutter information and accurate propagation models as Walfisch-Ikegami, Okumura-Hata, among others) can be started (normally this is done with the help of a specialized tool, namely a System-level simulator) with the goal to calculate the optimum base station locations, configuration and parameters and to analyze the global network performance in terms of capacity and coverage [ITU]. This includes advanced studies to avoid undesirable situations as the pilot pollution (the presence of too many pilots with significant power levels in the same area, that can cause problems in the user terminals because normally the receivers cannot handle more than 4 pilots at the same time, and also brings an increase of Interference, a higher rate of Errors, the so-called “ping-ponging” effect causing excessive usage of unnecessary handovers and increased dropped-call rates. Those studies can be carried with the help of specialized tools such ATOLL [Atoll]. The whole planning process thus includes activities such as:

37

• 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


38

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.

39

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).


40

4. Introduction to Wines Dynamic System-level Simulator

This chapter will explain in short the main characteristics of the Simulator being used for the study (Dynamic, System Level, Discrete Event), the advantages, disadvantages, and the main features about System Modeling (including the RRM algorithm modeling and Environment Modeling (shadowing, multi-path propagation, orthogonality in DL, etc) and User Modeling (including call generation process and data arrival (traffic models) ). A more complete guide and description of the tool can be found on [Winesuserguide], [Winestechref], [atollsyncmod] and [RRMEricsson].

4.1 Different Simulation Approach: Static vs. Dynamic

A UTRAN Static Simulator is a simulator that represents the UMTS Radio Network behavior at a certain moment of time, the so-called “snapshot” of the system. The snapshots represent, among other things, the spatial distribution of users in the network at a certain moment in time. However, the snapshots doesn’t have any common time reference among them, so it is not possible to answer questions about the system status in the “previous” snapshot because there is not such “previous” and “following” concepts in this kind of simulations.

In each of the snapshots, a random user distribution with a configurable service mix is generated. Then the power control and some RRM algorithms are performed which can lead to rejected or blocked users. Since in a snapshot it is not clear whether a user just entered to the network or had already been in the network for a certain time (because of the lack of a time reference), a general distinction between blocking and dropping is not possible, as it is possible in the Dynamic case. [Winessnapshot]

Within every snapshot, multiple iterations are run until certain convergence conditions are met and the snapshot can be considered to be in a steady state. For instance, uplink transmission power for every user is calculated in an iterative process, as well as Downlink transmission power for every cell. The iterations continue by incrementing the corresponding quantity, until the convergence is met. In the case of the Uplink transmission power, the convergence for the uplink transmission power for a user is met when:

41

Abs (SIRUL,i – SIRUL target) / SIRUL target < convergence_threshold ( 4-1)

Where:

• SIRUL,I = level of the SIR at the iteration i

• SIRUL target = predefined SIR target

• Convergence threshold: Denotes the maximally tolerated deviation of consecutive results within a snapshot, thus it defines the criterion when to stop the iterative process within the snapshot. It is a simulation input parameter, and it has values between [0.1, 100.0] [Winessnapshot]. Smaller values require more iterations but are also more accurate. It must be mentioned that besides the Dynamic mode, Wines Control Center also includes an Static Simulator which the user can select.

The problem with the static approach is that the snapshots are not connected along a time line, so it is not possible to reproduce accurately the status of the network as it evolves over time when a certain traffic load is offered to the network and when the RRM algorithms are working with very complex interactions among them in order to maintain the pre-defined quality targets.

However, the degree of abstraction in the Static Simulations is still enough to allow for meaningful statistical evaluations of the network KPIs [Winessnapshot]. In fact, this is the method currently used for initial dimensioning for large networks (more than 100 sites) because it is much more efficient (in terms of time and computational resources) than the current Dynamic Simulators in those scenarios because of the simplified modeling approach.

The Dynamic simulator, on the other hand, is a tool that is able to track the network status as it evolves over time. The status at a certain point in time is the accumulated result of the entire simulation run until that point [Winessnapshot]. This goes in line with the Dynamic Nature of the UMTS RAN. As it is mentioned in [Ramsden], a Dynamic system is the one where the outputs are a function of both the present values of the input and internal state variables, which are themselves functions of historical data, as is the case of the real UTRAN and its RRM algorithms.

Therefore, a Dynamic simulator is an ideal tool for:

-) Design and Test of RRM algorithms

-) RRM parameter optimization, specially those based on time (e.g. handover timers), which is not possible with Static Simulation because the lack of the time reference of that approach

-) Detailed Capacity, Coverage and Quality Analysis


42

Troubleshooting of concrete problem Areas

-) Tests of the capacity-coverage tradeoff with different service mixes and with different user profiles

-) Analyze packet data throughput

Wines is a Dynamic Simulator that models all the radio-resource management functionality of the UTRAN, such as

• Admission control

• Congestion control

• Power control

• Soft Handover

• Channel Switching (from common to dedicated channels and vice versa (e.g. from DCH to FACH and vice versa), and also up and down switching as a result of admission control and congestion control orders)

In the dynamic simulator, the users are making calls (according to the so-called “service arrival” processes) and transmitting data according to the traffic models (data unit arrival processes). In Wines, the call-generation process for real-time services (e.g. speech, video) follows a Poisson process and other probabilistic process are applied over the non-real time services (FTP, WWW, they are called non-real time since they doesn’t have a maximum defined delay).

In Dynamic simulators, there are also mobility models (e.g. pedestrian, vehicular) characterized by a certain movement model (static, straight movement, targeted movement) and speed with a certain distribution, to represent a complete dynamic user behavior.

The spatial distribution of the initial user positions is weighted with the traffic density values of the Traffic Matrix pixels. Consequently, the user distribution is, for example, uniform if the Traffic Matrix is uniform and covers the entire simulation area.

The disadvantage of the dynamic approach is that it requires high computational resources due to the complexity of the necessary algorithms and therefore the time required to perform dynamic simulations is considerably higher, which means that for networks with several hundreds or thousands of sites, the Dynamic Simulation is not the best approach. A nice summary of the characteristics of the static and dynamic approach can be found on the section 2.2. of [Holmathesis].

43

4.2 The Level of Detail of the simulation: System level vs. Link Level

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

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

4.3 Discrete Event Simulation vs. Continuous Time Simulation

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


44

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

Wines Workflow

Having introduced the required concepts, we can describe now Wines as a Dynamic –System Level – Discrete Event Radio Network Simulator. The workflow that one normally follows to make a Radio Network study using Wines Dynamic simulator is as follows:

1) Define the area which is going to be simulated. This is normally

done exporting the Network layout (Node Bs, Antennas and cells), path loss predictions, environment definition (clutter data, Digital Elevation Maps) and Traffic Matrices from a Radio Planning Tool Project. The concrete process to export a Project from Fork’s ATOLL to Radioplan Wines is described in the Appendix 2 of this Thesis.

2) Configure the Environment (Clutter, Streets, DEM), Users (Equipment Profiles, Mobility Profiles, Service Profiles and User Profiles), and UTRAN (including Antennas, RNC, Node B’s and cells).

3) Run the corresponding simulation(s) and store the results in the program’s data base and the defined simulation folders.

4) Perform the Analysis with the Tools that Wines provides, or alternatively use a spreadsheet and/or database to make some specialized analysis with the results of step 3.

The following Figure illustrates these 4 steps.

45

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).

Figure 4: Wines Workflow [Schneider]

ATOLL

Workflow

Configuration

Simulation

Analysis

WiNeS-WCC

WiNeS-WCC

ATOLL

Workflow

Configuration

Simulation

Analysis

WiNeS-WCC

WiNeS-WCC

Workflow

Configuration

Simulation

Analysis

WiNeS-WCC

WiNeS-WCC


46

Figure 5: Wines' configuration tab [Winesuserguide]

In Wines, the system level model also incorporates a link level model in order to determine the performance measures based on the interference analysis. However, instead of simulating at link level, a link level interface defines rules for mapping the interference statistics to bit or block error probabilities with respect to the relevant environment and receiver characteristics [Winesuserguide].

4.4.1 Dynamic User Traffic Modeling

Dynamic user traffic modeling can be distinguished into three levels:

4.4.1.1 1st level: The Network Element Activation level

This level describes at what times the user switches his terminal equipment on or off and includes both active and idle periods. The basic time period is a “switched-on”-period, equivalent for simulation purposes to the user’s lifetime (for the simulator, the user is “alive” while he has his UE turned on and using the corresponding service). This modeling level is characterized by the arrival process of the mobiles at the time instants when they are switched on. All the calls are assumed mobile originated, therefore there is no simulation of the idle-mode behavior (idle mode behavior corresponds to a User Equipment (UE) that is powered on, but does not have a connection to the radio network and it is reachable by the system. In wines all the users originate calls, but not receive them).

47

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-


48

state service load. This process is loaded automatically and it last approximately a number of frames equal to the expected number of users in the network, and it should be removed from the simulations in order to get just the results in steady-state.

4.4.3 The UE profile

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

A UE Profile is composed of an Equipment Profile, a Mobility Profile, and a Service Profile, as illustrated in the following Figure.

Figure 6: User Profile generation in Wines

Therefore, the UE profile is a “template” that is used in the simulations to create consecutive users of the same UE type. Each UE profile is associated to one and only one Service, Equipment and Mobility profile, but one service profile can be used by two or more UE Profiles (for example, for defining two types of users of the same service, one could define a UE profile for the Indoor users and another UE profile for the Outdoor ones). The equipment and mobility profiles can be defined from scratch (providing input for the required power (min and max) levels, the speed distribution, mean speed, type of movement) or using one of the predefined templates. The following Figure illustrates the configuration dialog of a UE Profile.

49

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,


50

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

51

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

tactive

active silent

tsilent

active silent

tsilent

Figure 10: Non-interactive Voice Activity factor, UL direction


52

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

53

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]

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.

constantServer response time

Pareto with cut-off Mean DL Datagram Size [byte]

geometric Mean DL datagram inter arrival time [s]

geometric Mean DL datagram count

GeometricMean reading time [s]

Geometric Mean number of packet call requests / user

Negative exponential Mean UL datagram size [byte]

DistributionParameter


54

Figure 12: Wines WWW traffic model parameters configuration window

The parameterization of the (different) traffic models for the defined services of this study (WWW, FTP, Video-call, Speech and Mobile TV) was an activity done in close cooperation with France SFR and it is shown in the appendix 3 (Traffic Models parameters).

Also the parameterization of the System Parameters was done in cooperation with SFR. The assumptions regarding the propagation conditions are explained in the next two chapters (for each corresponding scenario: homogeneously and non-homogeneously distributed traffic), as well as the other system parameters, which mostly were mapped from the real-settings of the Vodafone UMTS network to try to reflect as close as possible the configuration of RNCs and Node B’s of the company. These parameters appear in the appendix 4 (confidential: system parameters).

55


Static simulation vs. Dynamic simulation

Static simulations don’t have a time reference and therefore are not suitable to simulate algorithms that have a strong dependence of time (like RRM algorithms). However, the degree of abstraction in the Static Simulations is still enough to allow for meaningful statistical evaluations of the network KPIs. In fact, this is the method currently used for initial dimensioning for large networks because they are more efficient in terms of time required to complete a simulation (given its more simplistic modeling approach).

The Dynamic simulator, on the other hand, is a tool that is able to track the network status as it evolves over time. Dynamic simulator is therefore an ideal tool for:

-) Design and Test of RRM algorithms

-) RRM parameter optimization, specially those based on time (e.g. handover timers), which is not possible with Static Simulation because the lack of the time reference of that approach

-) Detailed Capacity, Coverage and Quality Analysis of specific areas

-) Tests of the capacity-coverage tradeoff with different service mixes and with different user profiles

-) Analyze packet data throughput

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


56

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

57

The Figure above illustrates the first Simulation Scenario. The Network Layout (including RNC, Node B’s, Antennas) as well as the path-loss prediction was imported from a Project created in ATOLL radio planning Tool, and it is based on a real scenario (it is an area taken from the radio planning map of the city of Bordeaux, France). This scenario was selected because it was defined as the Base for common capacity dimensioning studies between the branches of Vodafone in different countries, including The Netherlands.

The network layout itself consists on: -) 7 node Bs in the Analysis Area (with 3 cells each one = 21 cells) -) 19 node Bs in total in the simulation Area. -) Inter-site distance = 900 meters

The Simulation Area represents the area in where the users are created and once created they are moving in. This Area is represented in the Figure 13 with red borders and has an area of 12 Km2.

The Analysis Area, which is the area where data is collected, is shown in the Figure 13 with yellow borders. It has an area of 5 Km2.

5.2 Environment Assumptions

The main assumptions for this first scenario are a flat landscape (No Digital Elevation Model is used) and the Homogeneously-distributed traffic for each of the defined services, therefore no clutter definition and neither traffic maps based on clutter data were used for this scenario.

This assumption results in identical sites per simulation area, and given the symmetry in the geometrical distribution of the nodes regarding their inter-site distances, each one may be considered a “prototype” site at the initial dimensioning stage, as it is correctly mentioned in [Jaber].

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

The difference in performance terms between this symmetric and homogeneously distributed scenario and another more “realistic scenario” (i.e. scenario including clutter, DEM and traffic matrices based on clutter data) is going to be studied further in chapter 9 of this thesis.


58

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].

Service percentage

Voice 77,00%

Video-call 7,50%

Web 12,50%

Ftp 3,00%

MobileTv 0.00%

Traffic Mix [% ]

77,00

7,50

12,50

3,00 0,00

VoiceVideo callswwwftpMobile Tv

Figure 14: Traffic Mix assumption

59

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.


60

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)

61

5.4.3 Service Prioritization

This value determines the order how services are processed by the Congestion Control and the Inter-Frequency Handover Control. This is a value between 1 and 15 where 1 gives the highest priority. The default service priority is 3. In this study the default value was used, in order to not interfere with the admission and congestion control implemented in the Ericsson P3 RRM algorithms.

5.4.4 Optional Semi-Dynamic Mode

This mode, applicable only to circuit-switched services, allows us to generate a traffic load (service arrival process) where the users are not moving but static. It is useful when one wants to test the soft capacity when an already-known hard-capacity (e.g. voice users) is already present in the system. As it is also a simplification of the interference modeling, it also helps to reduce simulation times. In some simulations (as it is going to be explained in the simulation plan), this mode was used.

5.4.5 Physical Layer parameters

Decoding Limit Offset UL[dB]: The Eb/N0 threshold for correct (i.e. error-free) detection of signaling messages in uplink for the respective service, given as an offset to the target Eb/N0. This value should be negative (in dB) such that a received data packet that meets the target Eb/N0 condition is detected correctly. The reference for this Decoding limit was the Capacity Study performed in Vodafone Germany by Peter Schneider [Schneider-2]

Decoding Limit Offset DL[dB]: The Eb/N0 threshold for correct (i.e. error-free) detection of signaling messages in downlink for the respective service. This value should be negative (in dB) such that a received data packet that meets the target Eb/N0 condition is detected correctly. The reference for this Decoding limit was the Capacity Study performed in Vodafone Germany by Peter Schneider [Schneider-2]

Both definitions are in line with the “satisfied user” definition presented in [25.942] where a user is “satisfied” when the measured Eb/No of his connection is higher than a value equal to Eb/No target – 0.5 dB. Otherwise, if it is lower than this limit, the user is considered in outage.

Target BLER UL: It is the target BLER for the outer loop Power Control in uplink. The value ranges between 0 and 1.


62

Target BLER DL: It is the target BLER for the outer loop Power Control in Downlink. The value ranges between 0 and 1.

The target BLER levels in Downlink were based on the same document from Vodafone UK [Moret] where the DL Eb/No levels were based. For the Uplink direction the same values for Downlink were assumed.

5.4.6 Traffic Model parameters

The traffic model parameters were first defined according to the selection of the corresponding traffic models implemented in Wines according to the service. The following Table summarizes this first characterization step. A complete description of each one of the traffic models is provided in [Winestechref].

Service Wines Traffic Model

Speech Speech/video

Web WWW

FTP File

Video-call Speech/video

Mobile TV Speech/video

Table 2: Defined Services and Wines Traffic Models used

Once the corresponding traffic model was selected, its parameterization was the outcome of discussions with colleagues in SFR (France). The agreed values are presented in the corresponding appendix 3, together with the description of the source taken to establish the value. Some of them were based on existing measurements from the GPRS network.

One thing to mention here is the association that Wines makes between a Service and ASE values which is slightly different than the definition of ASE provided by Ericsson.

ASE (Air Speech Equivalent) is a measure of air-interface utilization relative to the utilization of one Speech User (for instance, a connection using 3 ASEs in DL generates the same interference level as the one generated by three voice users). This definition is used by Ericsson within the Capacity Management monitors (ASE UL/DL utilization); the ASE usage applies hard

63

limits to a cell’s and hence the network’s capacity. Technically, it is calculated per radio link connection and defined according to [Ericsson-capacity] as:

ASErl = (max. rate DCH)/(max. rate DCH speech) * ( AF DCH )/(AF DCH speech ) (5-3)

Where:

• ASErl is the air interface speech equivalent for a radio link

• Max.rate DCH is the expected maximum DCH rate for the radio link (DCH rate takes into account the overhead introduced by coding techniques and it doesn’t corresponds directly to the information rate, for the corresponding DCH Rate per Radio Link see appendix 3)

• Max.rate DCH Speech is the expected maximum DCH rate for a speech radio link connection

• AFDCH is the activity factor of the considered DCH

• AFDCH,Speech is the activity factor of the voice service (assumed to be 0.67)

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

The estimation of ASEs in the cell for monitoring purposes is performed as follows:

ASEDL= Sum rl (ASErl Dl) ( 5-4)

ASEUL= Sum rl (ASErl UL/ nb radio links per RNC) (5-5)

Where:

• ASEDL is the air interface speech equivalent in downlink for the cell

• ASErl DL is the air interface speech equivalent in downlink for a radio link

• ASEUL is the air interface speech equivalent in uplink for the cell

• ASErl ul is the air interface speech equivalent in uplink for a radio link

• nb radio links per RNC is the number of radio links within respective RNC

The number of ASEs for a radio link per cell in uplink is divided by the number of radio links involved in the connection. The principle is that the average uplink interference a UE creates in the respective cell, is proportional to the number of cells to which it is connected. This means that if a UE is connected to two cells, it only requires approximately half the ASEs in each cell, compared to using one cell.


64

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

5.4.7 Traffic Matrices

A traffic matrix is location-based data of traffic density values. Each Service has a Traffic associated to it. The traffic density values are given in Erlang/km2. The traffic matrix assigns a traffic density value to each “pixel” or minimum area unit (area size configurable within the simulator).

The traffic values in the traffic matrices are used for several purposes [WinesTechRef]:

• UE activation: New UEs are activated during a network simulation

according to the spatial distribution of the relative traffic values in the traffic matrices. That is, UEs are created with higher probability at positions with higher traffic values.

• Targeted movement: Users in a dynamic network simulation move preferably along paths with higher traffic, if paths are defined (not in this study). The relative traffic values in the traffic matrices are used for this directly.

• Inter-arrival time of the service arrival process: The mean inter-arrival time of UE activations for a certain service is calculated from the given mean holding time (also known as the “service time”) of the service and the total traffic density (given through the traffic matrix).

65

In Wines, a traffic matrix is defined per service and it can be either created directly in the tool (as it was the case for the 1st simulation scenario) or can be imported from a Radio Planning Tool (as it was in the case of the 2d simulation scenario).

For the first simulation, each service was associated with a traffic matrix homogeneously distributed over the whole simulation area. The value of the (mean) traffic densities were varied according to the simulation plan explained in the next section.

5.5 General Network Layout Assumptions

In this section the summary of assumptions regarding different features provided in the Simulator that have not been used for this simulation setup is given. Due to shortage in space, the work performed matching the parameters in Ericsson Domain with the corresponding ones in the Wines Domain is not shown here, however the complete parameterization is provided as the confidential annex [System Parameters].

5.5.1 RNC assumptions

• No neighbor list support, which means that every Site is potentially a neighbor for the other ones.

• No Power Balancing (Power Drift prevention). Power drift prevention ensures that the ratio between the downlink power of each radio link and the corresponding PCPICH power is the same for every cell in the active set. It is an algorithm defined in [ericssonpowercontrol] that is superimposed to the inner-loop power control and it used only when handover connections are present.

• Transport Channel Switching :activated, from Common to Dedicated and vice versa

• No HSDPA channel • No DL Radio Link Failure Detection [Out of synchronization and cell

update procedure, defined in ([25.331])

5.5.2 Node B assumptions

• No DL capacity limited due to ASE (ASE DL =480. maximum = 500). This was configured according to what was found in [Ericsson-capacity]:


66

“In the downlink, the Downlink Transmitted Carrier Power is the main monitor used to control the air interface load. ASEDlAdm is a complement to the load control when:

• Hardware resources are the limiting resource

• The cell can support so many users that it is close to the pole capacity, which can cause Instability.

Therefore, if the Downlink Transmitted Carrier Power is the limiting resource, aseDlAdm can be set very high so it does not interfere with the control strategy used for the Downlink Transmitted Carrier Power.”

As with the first (preliminary) simulations it was found that DL ASE utilization was the main blocking reason and knowing that the expected reason was Downlink Transmitted Carried Power, it was decided to follow the recommendation of Ericsson and put the aseDlAdm parameter near its maximum value (default value=240. configured value = 480. maximum value = 500).

• Assumed Costs of RLS in terms of CE (DL, dedicated channels), per

SF: 16,8,4,2,1,1,1,1 (for SF 4,8,16,32,64,128,256,512).

5.5.3 Cell assumptions

• Number of available FACH = 1 • SF8Adm =8, SF16Adm=16, SF32Adm=32 (Absolute admission limit on

the number of radio links with SF 8, 16 or 32 respectively, applicable to non guaranteed (i.e. interactive/background services) access requests.

5.6 Defined KPI’s (Key Performance Indicators)

The Key Performance Indicators (in this document abbreviated as KPIs) are the quantities to be measured whether to evaluate the resource utilization per cell (e.g. DL power usage, UL Noise Rise, DL code tree usage, Channel Elements usage) as to measure general performance of the UTRAN elements (Blocking and Dropping Probabilities per RNS/ per cell in case of circuit-switched connections, and for packet switched connections the throughput and delay are better performance indicators). Wines Simulator presents a whole gamma of KPIs to be selected, but to restrict our analysis to the most important KPIs, the following KPIs have been selected depending on the switching type of the Services:

67

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.


68

KPI Threshold Value Reason / Source

% of Blocked calls

% of Blocked calls at a given BLER level

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) Ericsson

% of Dropped calls

% of Dropped calls at a given BLER level

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) 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

69

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 non-handover 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 [all-CCH] (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


70

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.

Ericsson’s indicator of Downlink congestion, congestion in DL detected when DL power exceeds pwrAdm+pwrAdmOffset+pwrOffset during a time longer than pwrHyst, see Figure

Power level [dBm] per cell within a time interval. Ericsson.

Throughput (perceived by the user): minimum acceptable throughput, values below this level indicate a bad performance

Vodafone Internal Target

Average throughput per service [Kbps]

Vodafone Internal Marketing Document


71

KPI

Definition Threshold Unit Reason / Source

DL Iub capacity % of Iub reserved bandwidth

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+NusersSF16*PCR16+NusersSF32*PCR32 (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.Codetree, 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. [Iub-observability]



72

5.7 General Simulation Settings

• Simulation Mode selected: Dynamic Simulator. Wines has also the option of static (Monte Carlo) simulations, but for the purpose of this study, all the performed simulations were Dynamic.

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

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

• Default Inter-Scrambling-Code Orthogonality Factor (αsc): The default intra-cell orthogonality factor αsc between OVSF codes under different scrambling codes. As in this study different scrambling codes per cell were not used, the value of this parameter is irrelevant for the study purposes. Practical values for αc lie between 0.05 and 0.4 (with decreasing code orthogonality), and between 0.7 and 0.9 for αsc.

5.8 Simulation Plan

The following section describes the simulation setup for each one of the 5 different experiments performed per each scenario (homogeneous and non homogeneous). Also includes the description of the proposed Analysis of the

73

selected network parameter. It must be mentioned that due to the high number of performed simulations and the time required to collect and analyze the results, no repetitions per each experiment have been performed (i.e. there are no replications per each traffic density level) and therefore the calculation of the confidence intervals (if required) for the Figures obtained is left for a further study.

The base for all the experiments was defined in the following Table, where the traffic densities are scaled regarding the service mix percentages and the value of the density of the voice (main) service.

service % Erl Erl Erl Erl Erl

Voice 77 10.00 20.00 40.00 80.00 160.00Video call 7.5 0.97 1.95 3.90 7.79 15.58Www 12.5 1.62 3.25 6.49 12.99 25.97Ftp 3 0.39 0.78 1.56 3.12 6.23Mobile tv 0.00 0.00 0.00 0.00 0.00 0.00

Table 4: Defined Traffic Densities [Erl/Km^2]

5.8.1 Homogeneous Scenario

5.8.1.1 Figures per service

These Figures are calculated for 5 different traffic densities per service, collecting the defined KPIs for the circuit switched services (Voice, Video Tel) and for the Packet switched services (WWW, FTP). Therefore, the simulations are performed according the rows of the Table 3, i.e. with 5 different traffic densities (Erl/Km2) per each service. The main idea is to evaluate the operational point for each service, given the defined thresholds.

The Total number of required simulations for this step is: Number of services * 5 = 20 simulations.

5.8.1.2 Figures using the defined traffic mix percentages:

In order to test all possible combinations, we would need to test 5^4=625 possibilities. For this study, only the traffic densities defined in the “columns” of the Table 3. Number of required simulations = 5.

5.8.1.3 Power-rule study

The purpose of this study is to check the effects (measured in performance terms) of the two different rules applied to define the PCICH Power level in Vodafone Netherlands and in Vodafone Germany. Theoretically, different


74

PCICH power levels per each cell can create unbalance in the network and affect the size of the Handover Zones and the Pilot Polluted zones, so this study is aimed to check which settings are better in terms of these two indicators (distribution of the Handover Zones (i.e. active set size >1) and distribution of the pilot polluted zones).

To define the PCICH Power, there are two possible Reference Points as it is illustrated in the following Figure:

Figure 15: reference points for PCICH level

Wines defines its reference point for the PCICH as the reference point number one, however the PCICH values provided by the Netherlands and Germany are given in the Reference Point Number 2, so it means that one has to take into account the Downlink Losses. The uplink losses are assumed to be zero.

The rule applied in The Netherlands is:

If feeder loss <= 3 dBm then PCICH Power = 30 dBm (5-6)

If feeder loss > 3 dBm then PCICH Power = 33 dBm – Feeder loss (5-7)

And the rule applied in Germany is:

PCICH Power = 33 dBm – Feeder loss, for all feeder losses (5-8)

75

To test this feature, one has to create a simulation with different feeder losses in the cells, calculate the PCICH power level that the cell would have according to this rule and test the results for The Netherlands against the same scenario but applying the rule of Vodafone Germany.

Number of required simulations = 2. The assumed traffic densities for both simulations are as follows:

Voice Density Web density FTP density Video call density

40.00 6,49 1,56 3,90

Table 5: Assumed traffic densities (in Erlangs/Km2) for the two simulations of the Power rule study

The setup for the homogeneous case is summarized in the following table.

Site

assumed path loss

PCICH Power NL

PCICH Power Germany

Wines CPICH settings GE Wines CPICH settings NL

9 4 dB 29 29

PCICH Power = 33 dBm, cable loss DL = 4


5 0 dB 30 33



14 0 dB 30 33



10 0 dB 30 33



4 2 dB 30 31



8 1 dB 30 32



13 2 dB 30 31



Table 6: Assumed DL losses and PCICH Power for the Power Level experiments


76

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:

Voice

Scaling Factor

Web

Scaling Factor

FTP

Scaling factor

Video call

Scaling Factor

40.0 0.506329114 6.49 0.082151899 1.5 0.019746835 3.90 0.049367089

Table 7: Assumed traffic densities and scaling factors for the power rule study, non homogeneous scenario

The setup of the different power levels (regarding the same reference points of the Figure 15) is shown in the table below.

77

Site

path loss

(from ATOLL)

PCICH Power NL (Reference

2)

PCICH Power

Germany (Reference

2)

WinesPCICH settings GE (Reference

1)

WinesPCICH settings NL

(Reference 2)

U000751 3 30 30 33 33

U000752 1.595 30 31.405 33 31.595

U000753 3.7 26.3 29.3 33 30

U000791 2.935 30 30.065 33 32.935

U000793 2.54 30 30.46 33 32.54

U000801 2.325 30 30.675 33 32.325

U000802 2.28 30 30.72 33 32.28

U000803 1.85 30 31.15 33 31.85

U009641 3.105 26,895 29.895 33 30

U009642 3.57 26,43 29.43 33 30

U009643 3.47 26,53 29.53 33 30

U009651 2.69 30 30.31 33 32.69

U009652 2.69 30 30.31 33 32.69

U009653 2.69 30 30.31 33 32.69

U011031 1.275 30 31.725 33 31.275

U011032 2.49 30 30.51 33 32.49

U011033 1.27 30 31.73 33 31.27

U011071 2.51 30 30.49 33 32.51

U011072 2.42 30 30.58 33 32.42

U011073 2.66 30 30.34 33 32.66

U011381 4 26 29 33 30

U011382 4 26 29 33 30

U011383 4 26 29 33 30

U014671 3.275 26.725 29.725 33 30


78

U014672 3.32 26.68 29.68 33 30

U014673 3.32 26.68 29.68 33 30

U020731 1.905 30 31.095 33 31.905

U020732 1.645 30 31.355 33 31.645

U020733 1.86 30 31.14 33 31.86

U030761 2.31 30 30.69 33 32.31

U030762 2.44 30 30.56 33 32.44

U030763 1.675 30 31.325 33 31.675

U030771 1.3 30 31.7 33 31.3

U030772 1 30 32 33 31

U030773 1.3 30 31.7 33 31.3

U030801 3.01 26.99 29.99 33 30

U030802 3 30 30 33 33

U030803 3.01 26.99 29.99 33 30

U030821 3.65 26.35 29.35 33 30

U030822 3.7 26.3 29.3 33 30

U030823 3.65 26.35 29.35 33 30

U030841 2 30 31 33 32

U030842 2 30 31 33 32

U030843 2 30 31 33 32

U030851 3.51 26,49 29.49 33 30

U030852 2.91 30 30.09 33 32.91

U030853 1.15 30 31.85 33 31.15

U032311 3.015 26.985 29.985 33 30

U032312 3.02 26.98 29.98 33 30

U032313 3.02 26,98 29,98 33 30

U035701 2.755 30 30.245 33 32.755

79

U035702 2.74 30 30.26 33 32.74

U035703 2.35 30 30.65 33 32.35

U046611 1.365 30 31.635 33 31.365

U046612 1.375 30 31.625 33 31.375

U046613 1.365 30 31.635 33 31.365

U051651 3 30 30 33 33

U051652 3 30 30 33 33

U051653 3 30 30 33 33

U052011 0.6 30 32.4 33 30.6

U052012 0.6 30 32.4 33 30.6

U052013 0.6 30 32.4 33 30.6

Table 8: CPICH and DL Losses for the power experiment, non homogeneous scenario

5.8.2.4 Mobility study

Study the different mobility profile, analogous to 1.4. Number of required simulations: 6

Total number of simulations, non homogeneous Scenario = 25

5.8.3 Analysis of a specific network parameter

This is analysis was performed with one of the parameters that have not been harmonized between Vodafone Global and Vodafone Netherlands.

Applying the technique of two-factor analysis in Jain’s book (the two factors here are the traffic load and the parameter being tested), one has to test the parameter with 5 (5 or less, i.e. in case that some of them are the same value) possible values:

• Minimum value of the parameter

• Maximum value of the parameter

• Default Value (given by Ericsson)

• Value in The Netherlands

• Value in Vodafone Global


80

The 5 different levels of workload correspond to the 5 columns in the table 3. The semi-dynamic mode will be used for voice users to speed up simulation times (this mode means that the voice users are created according to the specified traffic density matrix and they generate calls according to the traffic models, but they are not really moving around the simulation scenario, each one makes the call without moving and ends the service).

The parameter to be analyzed is Timetotrigger 1a, a timer used in the intra-frequency handover for the handover algorithm. The required number of experiments in this study parameter is: number of workloads * number of levels of the parameter which would be 5*5= 25 simulations per analyzed parameter.

81


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.


82

6. Description of the Second Simulation Scenario (non-homogeneous)

The purpose of this chapter is to introduce the second scenario of the simulation experiments, related to its main changes regarding the first scenario. At the UTRAN configuration level, i.e. the configuration of the RNC, Node B and cell elements (described in the appendix 4 is exactly the same as the first scenario. Also the definition of the user profiles and service profiles (except now for the traffic matrices that are non-homogeneous) has been configured with the same Equipment Profiles, Mobility Profiles, Service Profiles and UE profiles. Due to different regional settings on the machines where the analysis was performed, through all the report both "," and “.”” have the same meaning (to separate decimals), and the number of decimals used has no relation with the accuracy of the results.

6.1 Simulation Area and Analysis Area

Figure 16: Simulation (red) and Analysis (yellow) Area for the Second Scenario

83

For this second scenario, a non-homogeneous traffic distribution, no – flat area (a Digital Elevation Model was used) was chosen. The traffic densities were generated based on the Clutter information also available from the Database of the Radio Planning Tool (ATOLL).

The simulation Area (area with red border in Figure 24) has an extension of 59.71 Km2, whereas the analysis area (area with yellow border in Figure 24) has an extension of 34.75 Km2. The area corresponds with the active transmitters (antennas) deployed in the downtown of the city of Maastricht. The following image illustrates the selection of the computation zone (equivalent to the simulation area in Wines) and the focus zone (equivalent to the analysis area in wines) in ATOLL radio planning tool.

Figure 17: Selection of the computation and focus zone in ATOLL radio planning Tool

Regarding the number of Node B’s and cells, they reflect the number of active transmitters in the selected area:

-) 21 Node Bs in the Simulation Area, all with 3 cells/Node B except for the Site S00079.

-) 18 Node Bs in the Analysis Area, all with 3 cells/Node B except for the Site S00079 (53 cells in total).


84

-) 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

85

As this is a study target mostly at determining capacity Figures and the purpose of the second scenario is to test the network regarding a non-homogeneous traffic matrix, the clutter classes are used just for the purpose of assigning different traffic densities to each of the clutter classes, not to test the effect of different propagation conditions in each clutter-class. Therefore, the clutter classes’ properties were all configured with the same characteristics, as it is shown in the next Figure.

Figure 19: definition of the clutter classes properties in Wines for the 2d scenario

About the DEM, this is a map that represents the height of the terrain, so it influences also mostly coverage issues, allowing to model in a more detailed way phenomenon like multi-path propagation and shadowing (i.e. fading caused by obstructing objects). The DEM used is the one defined in the Database of the Radio planning Tool and it was imported also in Wines.

6.3 Non – homogeneous Traffic Map generation

In this section an overview of the process followed in the Radio Planning Tool (ATOLL) to generate a non-homogeneous traffic map is presented. The complete procedure is described in the appendix 2.

Traffic data can be represented in Atoll in different ways. For the purpose of importing the traffic data into Wines, two options are supported:


86

• 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

87

The approach followed to create a non-homogeneous traffic Map is summarized in the following list (again, details are provided in the appendix 2.

1. Select one of the Environments (so the traffic map would be based just

in that environment) 2. Assign weights to the clutter classes associated to this Environment,

for instance as it was done in the following Table:

Clutter class Weight % Indoor

Default 0 0

Suburban: <6m Garden 10 30

Suburban: <6m 10 30

Suburban: <6m Dense 10 30

Suburban: <9m Wooded 10 30

Suburban: 6-9m Garden 10 30

Suburban: 6-9m 10 30

Suburban: 6-9m Dense 10 30

Urban: 9-12m Open 15 50

Urban: 9-12m 15 50


Urban: 12-18m 15 50


Urban: 18-27m 15 50

Urban: 18-27m Dense 15 50

City: 27-40m Open 20 60

City: 27-40m 20 60

City: >40m 20 60

Table 9: Clutter weights definition example inside a given Environment


88

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:

89

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.


90

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.

91

7. Simulation results first Scenario (homogeneous)

The purpose of this chapter is to present the analysis of the simulation results in the 1st simulation scenario described in chapter 5 and according to the simulation plan already mentioned in that chapter.

7.1 Figures per service

The purpose of this section was to determine under which load conditions (traffic densities expressed in Erlangs/Km2) the UTRAN reaches each one of the capacity thresholds, making the analysis for each one of the proposed services. The traffic densities were varied according to the table 4. To be able to determine at which level the load in the network reaches a specific capacity threshold, one software application, Curve Expert v1.3. (© Daniel Hyams) was used. This software allows to analyze which is the best mathematical interpolation fit given a dataset as the input, and with the obtained mathematical fit, it allows to analyze what input level produces a specific output level (x = f(y)). Several fits can be tried and they are ranked in terms of “goodness” or “badness” of the fit. Two quantities are used to express the "goodness" of a particular curve fit - the correlation coefficient and the standard error of the estimate. The correlation coefficient has a range from 0 to 1, with a correlation coefficient of 1 being the best fit, and the standard error has a variable range, with a smaller standard error (smaller regarding the Y’s or obtained values of the dataset) representing the better curve fit. Explanations about how these two indicators are mathematically defined can be found in [curveexperthelp]. The following Figures present the main screens of the software.


92

Figure 23: Curve Expert mathematical fits ranked according the correlation coefficient and standard error.

93

Figure 24: Curve Expert Analysis feature X= f(y)

Sometimes, the assumed input traffic densities were not high enough to produce the desired threshold levels. In those particular cases, and because restrictions in time and processing power didn’t allow to make more simulation with higher loads, different “cases” were proposed, i.e. different interpolation models (mainly linear, quadratic and exponential fits because they represent, for the range of simulated (positive) loads, the corresponding non-negative increasing or decreasing functions as it is required) were tried for each KPI Figure as a way to extrapolate results from the interpolation curve fit. As the dynamics of the system are so complex and theoretical models about what kind of behavior in mathematical terms can be expected in those indicators are not easily available, there is no way to predict with accuracy which is the right traffic density that produces the true threshold


94

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.0000%

0.0200%

0.0400%

0.0600%

0.0800%

0.1000%

0.1200%

10.0000

20.0000

40.0000

80.0000

160.0000

Traffic Density [Erl/Km^2]

Blocked services [%]

Figure 25: Blocking probability, voice only service

95

dropped probability [%]

0.00000.00010.00020.00030.00040.00050.0006

10.0000

20.0000

40.0000

80.0000

160.0000Traffic Density [Erl/Km^2]

% 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 = -2.62E+02

b = 3.20E+01

c = -9.56E-01

d = 7.48E-04

Level at Y = 0.01 281.71 Erl/Km^2

Number of users per cell 49

Linear Fit: y=a+bx

Coefficient Data:

a = -0.0002

b = 7.2446E-06


96

Level at Y = 0.01 1411.970 Erl/Km^2


Table 10: Estimation of the users per cell according to the simulation output, blocking probability target = 1%

As it can be seen, the range [281,76 , 1411,970] is still very wide to try to accurately define the traffic load that produces the 1% blocking, and therefore more simulations need to be accomplished in further studies in order to get more accurate results. Because of limitations in the hardware (out of memory problems), simulations with traffic densities within this range were not possible to verify. However, as a way of comparison, an alternatively approach, the approach based on load factors to calculate cell capacity mentioned in [Holma] was used to find the theoretical capacity of a cell given a only-voice service. Working with the KPI threshold for uplink load equal to 60% and the Eb/No value the same as in the simulations (6.91 dB) and assuming i-ratio ( other cell interference / own cell interference) as 0.65 for a macro-cell environment ([Holma]), the number of users per cell (N) can be calculated according to the following equation:

N = n UL / (Eb/No * υ * (1+i) / W / R) (7-1)

Where: • n UL = uplink load factor (assumed to be 60%) • υ = voice activity factor (assumed to be 0.5) • W = chip rate (3.84 Mchips/sec) • R = user data rate = 12.2 Kbps

Substituting these values in the formula, we get the value of nearly 47 users per cell.

Now, to compare this Figure with the number of users per cell according to simulation results, first we have to calculate the cell area. The result of this calculation is going to be used to convert the traffic densities given in Erl/Km2 into number of users per cell in the remaining part of the homogeneous analysis. The cell area is calculated as follows:

r = cell radius = inter-site distance / 3 = 900 m / 3 = 0.3 Km (7-2)

A = cell area (hexagonal cell) = K*r2 (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)

97

Where the round operator indicates approximation to the nearest integer depending on the fractional part (above or equal to 0.5 it is approximated up, less than 0.5 is approximated down).

Trying with the lowest range-limit:

Number of users per cell = 281.716 * 0.1755 = 49 users/cell.

Trying with the upper range-limit:

Number of users per cell = 1411,970 * 0.1755 = 248 users/cell.

Therefore, the lower limit obtained with the polynomial fit seems to be more appropriate because it is in the same order of magnitude of the theoretical result, and it is the Figure which is going to be selected as the best estimate for the summary table.

Following a similar approach, the following values were found for the dropping probability:



a = -1.19E-05

b = 1.46E+06

c = -4.35E-08

D = 3.40E-10

Level at Y = 0.01 352.673 Erl/Km^2


Linear Fit: y=a+bx

a = -0.0001

b = 3.29E-06

Level at Y = 0.01 3068 Erl/Km^2


Table 11: Estimation of the users per cell according to the simulation output, dropped probability target = 1%

As it can be concluded from this section, dropped services occur with higher traffic loads than when blocking occurs, which is well in line with the RRM


98

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]

0,0000

50,0000

100,0000

150,0000

200,0000

10,00

00

20,00

00

40,00

00

80,00

00

160,0

000


DL c

hann

el e

lem

ents

DL Channel Elementsusage [mean]DL Channel Elementsusage [max]

Figure 27: channel elements usage, Downlink direction, voice only service

UL Channel Elements usage [mean, max]

0,000020,000040,000060,000080,0000

100,0000120,0000140,0000160,0000

10,00

00

20,00

00

40,00

00

80,00

00

160,0

000


UL c

hann

el e

lem

ents

UL Channel Elementsusage [mean]UL Channel Elementsusage [max]

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,

99

extrapolation is used and therefore a range of values is given. The results are summarized in the following tables.

CE Downlink Target = 256 CE

Linear Fit: y=a+bx

Coefficient Data:

a = 17.6737

b = 0.8078

Level at Y = 256 295 Erl/Km^2


Quadratic Fit: y=a+bx+cx^2

Coefficient Data:

a = 15.544373

b = 0.90265331

c = -0.0005

Level at Y = 256 334.509 Erl/Km^2


Table 12: Estimation of the users per cell according to the simulation output, Downlink Channel elements target = 256

CE Uplink Target = 64 CE

Quadratic Fit: y=a+bx+cx^2 Coefficient Data:

a = 0.5444

b = 0.9027

c = -0.0005

Level at Y= 64 73.5965 Erl/Km^2


Table 13: Estimation of the users per cell according to the simulation output, Uplink Channel elements target = 64


100

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]

0,0000200,0000400,0000600,0000800,0000

1000,0000

10,00

00

20,00

00

40,00

00

80,00

00

160,0

000


Kbp

s

Iub traffic [DL]

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.

101

Target for Iub DL throughput = 2786 cells/sec * 48 bytes/cell * 8 bits/byte = 1.07 Mbps


Coefficient Data:

a = 3

b = 6

c = -0.0031

Level at Y= 1070 218.8070 Erl/Km^2


Linear Fit: y=a+bx

Coefficient Data:

a = 15.5115

b = 5.0227

Level at Y= 1070 209.9440 Erl/Km^2


Table 14: Estimation of the users per cell according to the simulation output, Downlink Iub congestion target= 1070 Mbps.

To prove that this number is realistic, we can perform the following calculation that gives us the amount of Kbps consumed by the number of users obtained by our simulation model (linear fit):

Iub Consumed Capacity [Kbps] = Data Rate (DPDCH voice connection, Downlink) * Number of users ( 7-5)

This gives:

• 30 Kbps * 36.84 = 1105.2 Kbps, which is a very close value to our

target of 1070 Kbps.

Note that in the calculation we use 30Kbps and not 12.2 because we have to take into account the coded channel (which includes the overhead caused by coding and protection techniques) and not just the end-user data rate.


102

7.1.1.4 Uplink Load

UL Load [%]

0,0000%10,0000%20,0000%30,0000%40,0000%50,0000%60,0000%70,0000%80,0000%90,0000%

100,0000%

10,0000

20,0000

40,0000

80,0000

160,0000


UL

Load

[%]

UL Load [%]

Figure 30: UL Load [percent], voice only service

For this case, it was also proposed in the KPIs definition to measure the RTWP and see if its level exceeds the target (given by the two Ericsson parameters) for a time higher than the hysteresis time (defined by the Ericsson parameter iFHyst) . That is how Uplink load is determined in the real system. For the simulation analysis however, it was difficult to try to average these results because congestion happens at a different times in different cells, it was decided to work with the approach presented in [Holma, Jabber] which is to assume a maximum Noise Rise (in dB) and then calculate the target UL Load in terms of the uplink load factor (nul) using the following equation:

NR [dB] = - 10 * Log (1- nul ) ( 7-6)

Where:

NR represents the Noise Rise.

nul is the uplink load factor.

Assuming a Noise Rise level of 4 dBs [Holma], we get nul = 0.6 (60%) which will be our target level for the Uplink Load. The results of the interpolation are mentioned in the following table.

103

Uplink Noise Rise Target Value =

0.60

Linear Fit: y=a+bx

Coefficient Data:

a = 0.02258

b = 0.0059

Level at Y= 0.60 99.7655 Erl/Km^2

Number of Users/cell 18


Coefficient Data:

a = -0.0240

b = 0.0079

c = -1.20E+02

Level at Y= 0.60 92.4429 Erl/Km^2

Number of Users/cell 16

Table 15: Estimation of the users per cell according to the simulation output, Uplink Noise Rise congestion target = 60%

7.1.1.5 Downlink Transmitted Power

DL_TxPower [dBm]

35,5000

36,0000

36,5000

37,0000

37,5000

38,0000

38,5000

10,0000

20,0000

40,0000

80,0000

160,0000

traffic density [Erl/Km^2]

Pow

er [d

Bm

]

DL_TxPower [dBm]

Figure 31: Downlink transmitted power, voice only service


104

According to Ericsson Documentation, the target threshold for Downlink Transmitted Power is 90% of the Maximum Transmission Power, which is 43 dBm in the simulation series; therefore the target threshold is 38.7 dBm. As this value is not within the interpolation range, the two best fits are presented as estimations.

Target threshold = 90% (43 dBm) = 38.7 dBm

Linear Fit: y=a+bx

Coefficient Data:

a = 36.3788

b = 0.01140

Level at Y = 38.7 dBm 203.68 Erl/Km^2



Coefficient Data:

a = 363.747

b = 0.0116

c = -1.06E+01

Level at Y = 38.7 dBm 205 Erl/Km^2


Table 16: Estimation of the users per cell according to the simulation output, Downlink transmitted power congestion target = 38.7 dBm

105

7.1.1.6 Downlink Code Tree Usage

DL_Code tree usage[%]

0,0000%5,0000%

10,0000%15,0000%20,0000%25,0000%30,0000%35,0000%40,0000%45,0000%

10,0000

20,0000

40,0000

80,0000

160,0000


Cod

e tre

e us

age

[%]

DL_Code treeusage[%]

Figure 32: DL Code tree usage [%], voice only service

The utilization of the Downlink Code Tree is calculated in percentage according to the description found in [WinesTechRef]. Having into account the Ericsson RRM algorithms, the Target level to trigger soft congestion mechanism in the DL channelization codes monitor is 60% of utilization. The results are summarized in the table below.

Target Level to trigger soft congestion mechanism = 60% (0.6 in linear scale)

Linear Fit: y=a+bx

a = 0.03858

b = 0.0023

Level at Y = 0.6 239.89 Erl/Km^2



a = 0.0320

b = 0.0026

c = -1.70E+01

Level at Y = 0.6 258.188 Erl/Km^2


Table 17: Estimation of the users per cell according to the simulation output, Downlink Code Tree usage congestion target = 60%


106

7.1.1.7 Summary of Voice Service

Next table presents the summary with the KPI’s ordered by the traffic densities that reach first the target level (only considering the lower values for the number of users of each KPI, i.e. taking the most restrictive approach):

KPI Target Level No. users to reach the target

CE UL 64 13

UL Load 60% 16

DL power 38.7 dBm 36

Iub 1070 Kbps 37

DL code tree 60% 42

Blocking prob 1% 49

CE DL 256 51

Dropping prob 1% 62

Table 18: Ordered KPI's, voice-only service

According to the previous results, the Voice-only service is mainly uplink – limited. Next to the uplink limiting factors are the DL transmitted power and the Iub utilization. The KPI’s that reach their target levels at the end are the Downlink Channel Elements number and the Dropping probability, whose target value were not reached within the simulated traffic densities.

7.1.2 Web Service

After the analysis of the Speech service, the analysis corresponding to this Packet Switched service is presented next.


The following Figures illustrate the obtained simulation results in terms of Blocking and Dropping Probabilities:

107


0,0000%

10,0000%

20,0000%

30,0000%

40,0000%

50,0000%

60,0000%

1,6200

3,2500

6,4900

12,9900

25,9700


Blocked services [%]

Figure 33: Blocking Probability Web service, sf8Adm=1

dropped services [%]

0,0000%

20,0000%

40,0000%

60,0000%

80,0000%

100,0000%

1,620

0

3,250

0

6,490

0

12,99

00

25,97

00


% dropped services [%]

Figure 34: Dropping Probability Web service, sf8Adm=1


108

Blocking Probability, Target =0.01

a) MMF Model: y=(a*b+c*x^d)/(b+x^d)

a = -246.7280

b = 1.2024

c = 50.1275

d = 1.5127

Value at Y=1% (0.01) 3.292 Erl/Km^2


b) Linear Fit: y=a+bx

a = -0.3167

b = 0.0975

Value at Y=1% (0.01) 3.3526 Erl/Km^2


Table 19: Estimation of the users per cell according to the simulation output, Web-only service, parameter sf8Adm=1, Blocking probability target = 1%

Analyzing the results, very low Figures were found, near 1 user / cell. In order to check the results, an analytical approach was used again, assuming that the main limitation for packet-switched services is Downlink Power consumption as it was shown in [Schneider-1]. According to [Holma], the Downlink load factor is defined as:

ndl = Σ υj * (Eb/No)j / W/Rj [1-α+i], j=1 to N ( 7-7)

Where: • N = number of users in the cell • υj = service activity factor (for PS services assumed to be 1) • W = chip rate = 3.84 Mchips/sec • Rj = Data Rate of user j • Eb/Noj = Eb/No for user j • α = Downlink Orthogonality factor, for the formula, 1 means

maximum orthogonality (for the simulator 0.4 is used but 0 means in the simulator context full orthogonality, so for the formula calculation a value of 0.6 is assumed)

• i = Other cell/ Own cell interference factor, assumed 0.65 for a macro-cell scenario [Holma]

109

The formula reflects that in Downlink the Data Rate for each user and the Eb/No are specific for each user’s location. To make it possible to have an estimation of the number of users per cell, it will be assumed that Eb/No and R is the same for all users (4.56 dBs and 384 Kbps respectively). With these assumptions, replacing the values in the formula and setting the Downlink Load Factor as the congestion threshold defined by the Ericsson parameters (90% of the Downlink Power so assumed ndl =0.9), we found that the number of users supported per cell is 3 and the corresponding traffic density would be 17.09 Erl/Km2, both far from the obtained values of 0.58 users and 3.35 Erl/Km2. For admission control settings (ndl =0.75), we obtain 2 users per cell and the corresponding traffic density of 11.39 Erl/ Km2.

Taking a deeper look at the simulation results, the cause of such low traffic densities to reach the capacity threshold (and the corresponding number of users per cell) was found: There is a parameter defined by Ericsson and called sf8Adm, which controls the maximum number of connections per spreading factor. As the current implementation of the simulator tries always to get the maximum possible data rate per each service request (next release it will include the “slow-start” approach mentioned in [Holma]), then having the sf8Adm with the real setting in the network (sf8Adm=1) is the main blocking cause (more than 80% of the times), as it can be checked in the summary for each simulation, where the main reason for blocking found was “DL SF8 usage limit exceeded” in all the simulations with the 5 different traffic densities. Therefore, a new simulation series was programmed with the sf8Adm with its maximum value (8) which means no restriction due to SF 8 usage. Next Figure and table shows the new results. Intuitively, due to the simulation implementation already mentioned, it is expected that the traffic density that reaches the 1% blocking would be reached earlier than in the case of the analytical approach, as currently there is no way to simulate the slow-start mechanism.


0.0000%

2.0000%

4.0000%6.0000%

8.0000%

10.0000%12.0000%

14.0000%

1.6200

3.2500

6.4900

12.9900

25.9700


Blocked probability[%]

Figure 35: Blocking Probability Web service, sf8Adm=8


110



a = 0.0047

b = -0.0027

c = 0.0003

Value at Y=1% (0.01) 11.0888 Erl/Km^2



a = 0.0023

b = -0.0015

c = 0.0002

d = 3.13E-06

Value at Y=1% (0.01) 11.0839 Erl/Km^2


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 UE’s are normally switched to the FACH channel instead of being dropped. Vodafone D2 is currently clarifying if this handling is equal to the real handling in Ericsson hardware, because so far it is not clear if Ericsson supports data transmissions on the FACH.


The following Figures illustrate the mean and maximum channel elements usage in Uplink and Downlink (target thresholds: 256 DL, 64 UL).

111


0,000010,000020,000030,000040,000050,000060,000070,000080,0000

1,620

0

3,250

0

6,490

0

12,99

00

25,97

00


DL c

hann

el e

lem

ents

DL ChannelElements usage[mean]DL ChannelElements usage[max]

Figure 36: DL channel elements usage, Web-only service


0,000010,000020,000030,000040,000050,000060,0000

1,620

0

3,250

0

6,490

0

12,99

00

25,97

00


UL

chan

nel e

lem

ents

UL ChannelElements usage[mean]UL ChannelElements usage[max]

Figure 37: UL channel elements usage, Web-only service

a) Downlink

Linear Fit: y=a+bx

a = 19.438376

b = 1.3701932

Value at Y = 256 173.648 Erl/Km^2



A = 17.966051

B = 1.774063

C = -0.01442546


112

Value at Y = 256 218.0280 Erl/Km^2


b) Uplink


A = 1.1074

B = 1.5842

C = -0.0108

Value at Y = 64 71.8009 Erl/Km^2


Linear Fit: y=a+bx

A = 2.2047

B = 1.2832

Value at Y = 64 48.1573 Erl/Km^2


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.

113


Iub traffic [DL]

0,0000200,0000400,0000600,0000800,0000

1000,00001200,0000

1,620

0

3,250

0

6,490

0

12,99

00

25,97

00


Kbps Iub traffic [DL]

Figure 38: DL Iub utilization, Web only-service

Target for Iub DL throughput = 2786 cells/sec * 48 bytes/cell * 8 bits/byte = 1.07 Mbps

Linear Fit: y=a+bx

Coefficient Data:

a = 137.3714

b = 33.6504

Level at Y= 1070 27.7152 Erl/Km^2


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

According to the simulation results, approximately 5 users would cause congestion in the Iub interface. Checking the results assuming full time maximum utilization of the channel (and therefore Data Rate of the coded channel for a 384 Kbps data rate = 480 Kbps), we would have 5 users * 480 Kbps = 2400 Kbps (which would theoretically exceed the maximum capacity available of the E1 circuit), but assuming a reasonable utilization of about 50% of the time, the Figure would be 1200 Kbps which is close to the defined target of 1070 Kbps.


114

7.1.2.4 Uplink Load

UL Load [%]

0.0000%0.5000%1.0000%1.5000%2.0000%2.5000%3.0000%

1.620

0

3.250

0

6.490

0

12.99

00

25.97

00


Upl

ink

Load

[%]

UL Load [%]

Figure 39: UL Load, Web only service

Taking a look at the simulation results, we can clearly see that UL load seems not to be a problem for the Web Service. Even with the highest simulated load for Web Service (25.97 Erl/Km2), the Uplink load is about 6%, quite far away from the target (60%). In these conditions, the different fits produce very different results, but for the purpose of this analysis the most restrictive setting among linear, quadratic and exponential fit is presented in the next table.

Uplink Load Exponential Fit: y=ae^(bx) Coefficient Data: a = 0.005193252 b = 0.065165121 Value at Y=60% (0.6) 72.8858 Erl/Km^2 Number of users per cell 13

Table 23: Estimation of the users per cell according to the simulation output, Web-only service, uplink load target = 60 %

115


DL_TxPower [dBm]

35,800036,000036,200036,400036,600036,800037,000037,200037,400037,600037,800038,0000

1,6200

3,2500

6,4900

12,9900

25,9700


Pow

er [d

Bm

]DL_TxPower [dBm]

Figure 40: DL Transmitted power usage, Web-only service

The Downlink transmitted power usage shows the same behavior trend as in the case of voice-only usage, although the levels are lower. This can be also due to the smaller number of Web users per cell. As the target value it is not present in the interpolation range, three estimated values are presented in the next table using extrapolation with the obtained analytical expressions.

Downlink Transmitted Power


Linear Fit: y=a+bx

a = 36.528181

b = 0.047020985

Value at Y=38.7 46.1883 Erl/Km^2


Exponential Fit: y=ae^(bx)

a = 36.5313

b = 0.0013




116


a = 36.504102

b = 0.0536

c = -0.0002



Table 24:Estimation of the users per cell according to the simulation output, Web-only service, DL Transmitted power congestion target = 38.7 dBm

According to these results, to reach the target for congestion in Downlink due to Transmitted Power usage, the required number of users is between 8 and 9.


DL_Code tree usage, homogeneous scenario [%]

0.0000%

5.0000%

10.0000%

15.0000%

20.0000%

25.0000%

6.4900 12.9900 25.9700


Cod

e tr

ee u

sage

[%]


Figure 41: DL code tree usage, Web only service

According to the Figure, the code tree usage is lower than the code tree usage for voice, but this has to do also with the current implementation of the simulator that doesn’t model the slow-start mechanism (i.e. PS services start with a data rate of 64 Kbps and as soon as there is capacity available in the cell they upgrade their data rate with a smaller spreading factor), therefore in a real-network the expected code tree usage would be higher than the value obtained in the simulations. It is proposed to try the same feature once the simulator includes the slow-start mechanism in its internal implementation. In the Figure, only the part corresponding to the range [6.49, 25.97] is presented due to no output data was obtained for DL Code Tree usage with the first two traffic densities. The corresponding fit for the range presented is summarized below.

117

DL Code Tree usage target =60% Linear Fit: y=a+bx Coefficient Data: a = 0.043132 b = 0.006364 Value at Y=60% (0.6) 87.49 Erl/Km^2


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

0.000050.0000

100.0000150.0000200.0000250.0000300.0000350.0000

1.6200 6.4900 12.9900 25.9700


Kbps DL Throughput

Figure 42: Downlink throughput, Web only service, indoor users

Web outdoor Application DL Throughput per user

0.0000

100.0000

200.0000

300.0000

400.0000

1.6200 6.4900 12.9900 25.9700


Kbps

DL Throughput

Figure 43: Downlink throughput, Web only service, outdoor users


118

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

Indoor users Exponential Fit: y=ae^(bx) Coefficient Data: a = 341.31176 b = -0.013965516 Value at Y=100 87.9041 Erl/Km^2


Outdoor users Exponential Fit: y=ae^(bx) Coefficient Data: a = 380.60388 b = -0.019331111 Value at Y=100 69.1419 Erl/Km^2


Table 26: Estimation of the users per cell according to the simulation output, Web-only service, throughput target = 100 Kbps

119

7.1.2.8 Summary of Web service

Next table presents the summary of the Web Service with the KPI’s ordered by the traffic densities which reach first their target level:

KPI Target Level

No. users to reach the target

Blocking prob

1% 2

DL Iub 1070 Kbps 5

DL power 38.7 dBm 8

CE UL 64 8

DL throughput (outdoor)

100 kbps 12

UL Load 60% 13

DL code tree

60% 16

CE DL 256 30

Table 27: Ordered KPI's, Web-only service

In the previous table, we can see that Blocking Probability is the first KPI to reach the target. Theoretically, allowing a higher Blocking Probability for PS services would increase the capacity of the cell and it would be possible to allow more blocking for the PS services, given the more flexible characteristics of the packet switched services to tolerate a higher BLER compared with the circuit switched services. In the second and third place we can observe that the capacity for the Web Service is now Downlink limited (Iub, DL power) rather than Uplink limited as in the Voice Service.


120

7.1.3 FTP Service



0.0000%

0.5000%

1.0000%

1.5000%

2.0000%

2.5000%

3.0000%

0.3900 0.7800 1.5600 3.1200 6.2300


Blocking probability[%]

Figure 44: Blocking probability, FTP only service

Blocking probability

Target threshold = 1%


Coefficient Data:

a = 0.001576177

b = -0.002396161

c = 0.001062297

Value at Y=1% (0.01) 4.1627 Erl/Km^2


Table 28: Estimation of the users per cell according to the simulation output, FTP-only service, target threshold for blocking = 1%

121


0,0000%

0,1000%

0,2000%

0,3000%

0,4000%

0,5000%

0,6000%

0,3900 0,7800 1,5600 3,1200 6,2300



Figure 45: Dropping probability, FTP only service

Dropping probability



Coefficient Data:

a = 0.0004

b = -0.0008

c = 0.0003

Value at Y=1% (0.01) 8.1451 Erl/Km^2


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


122

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.



0,000020,000040,000060,000080,0000

100,0000120,0000

0,390

0

0,780

0

1,560

0

3,120

0

6,230

0


DL c

hann

el e

lem

ents


Figure 46: DL CE usage, FTP only service


0,000010,000020,000030,000040,000050,000060,000070,000080,0000

0,3900 0,7800 1,5600 3,1200 6,2300


UL c

hann

el e

lem

ents


Figure 47:UL CE usage, FTP only service

123

Target levels: 64 CE UL 256 DL

a) Downlink

Linear Fit: y=a+bx

a = 15.5037

b = 7.0251

Value at Y=256 34.234 Erl/Km^2


b) Uplink


Coefficient Data:

a = -0.0530

b = 5

c = 0.1415



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).


124


Iub traffic [DL]

0,0000200,0000400,0000600,0000800,0000

1000,00001200,00001400,0000

0,3900 0,7800 1,5600 3,1200 6,2300



Figure 48: Iub traffic, FTP only service

Target for Iub DL throughput = 2786 cells/sec * 48 bytes/cell * 8 bits/byte = 1,07 Mbps

Linear Fit: y=a+bx

Coefficient Data:

a = 34,4036

b = 204,8369

Level at Y= 1070 5,0550 Erl/Km^2


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).

125

7.1.3.4 Uplink Load

UL Load [%]

0,0000%

2,0000%

4,0000%

6,0000%

8,0000%

10,0000%

12,0000%

0,3900 0,7800 1,5600 3,1200 6,2300


UL

load

[%]

UL Load [%]

Figure 49: Uplink load, FTP only service

UL Load threshold = 0.60 = 60%


Coefficient Data:

a = -0.0012

b = 0.01575

c = 0.0001

Level at Y= 0.60 30.363 Erl/Km2


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.


126


DL_TxPower [dBm]

35,000035,500036,0000

36,500037,000037,500038,0000

38,500039,0000

0,3900 0,7800 1,5600 3,1200 6,2300


Pow

er [d

Bm

]

DL_TxPower [dBm]

Figure 50: DL Transmitted power, FTP only service


Linear Fit: y=a+bx

Coefficient Data:

a = 36

b = 0.3438

Level at Y = 38.7 dBm 6.7843 Erl/Km2


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.

127



0,0000%

5,0000%

10,0000%

15,0000%

20,0000%

25,0000%

30,0000%

0,3900 0,7800 1,5600 3,1200 6,2300


Cod

e tre

e us

age

[%]


Figure 51: DL Code Tree usage, FTP only service


Linear Fit: y=a+bx

a = 0.03295

b = 0.03975

Level at Y = 0.6 14.2658 Erl/Km^2


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.


128

7.1.3.7 Throughput

Target (Indoor, Outdoor) = 100 Kbps

a) Indoor users

Geometric Fit: y=ax^(bx)

Coefficient Data:

a = 238

b = -0.027463913

Value at Y = 100 12.4942 Erl/Km^2


b) outdoor users


Coefficient Data:

a = 318

b = -0.1038

Value at Y = 100 11.1251 Erl/Km^2


Table 35 :Estimation of the users per cell according to the simulation output, FTP-only service, target throughput = 100 Kbps

According to the previous table, we can see less supported users per cell (near 2) than in the case of Web Service (between 3 and 9), and again these differences can be attributed to the type of channel switching performed on each service.

7.1.3.8 Summary FTP Service

In the next table, a summary with the KPI’s ordered by the number of users that reaches first the target level is provided. In the case of KPIs with the same number of users, the order has been set according to the corresponding traffic density levels (without truncation).

129

KPI Target Level


Traffic Density Level

Blocking prob

1% 1 4.1627

Iub DL 1070 Kbps

1 5.0550

DL power 38.7 dBm

1 6.7843

Dropped prob

1% 1 8.1450

CE UL 64 2 9.83

throughput 100 kbps

2 11.1251

DL code tree

60% 3 14.2658

UL Load 60% 5 30.363

CE DL 256 6 34.234

Table 36: Ordered KPI's, FTP-only service

As in the Web Service, the capacity is Downlink-limited for the FTP service. After blocking probability, Iub DL utilization and DL power are the main limiting factors. Uplink load has definitely not the significance that it has in the case of circuit switched services (e.g. voice), as it can be also concluded from the previous table. And the CE DL in the last place indicates that with the current provisioning of hardware in Downlink Direction (Channel Elements) there are no hardware-related capacity problems. However Uplink CE occupies an intermediate position and given that in the voice service turns out to be one of the main limiting factors, special attention shall be given to the number of channel elements in uplink. Simulations testing Node Bs with more than 64 CE in UL are proposed for further studies.


130

7.1.4 Video-call Service

Next section presents the analysis of the experiments performed with the video call service (Circuit Switched service).


Blocking probability, target: y =0.01 (1%)

Linear Fit: y=a+bx

Coefficient Data:

a = -0.0031

b = 0.0004



Table 37: Estimation of the users per cell according to the simulation output, video call service, blocking probability target=0.01

The average number of users per cell obtained was around 6 users per cell which is higher than the expected theoretical value of 4 assuming again Uplink load factor of 0.6 and applying the analytical approach. About the dropping probability, some inconsistencies were found in the outcomes so no analysis was performed with this data.


In order to reach the target thresholds by interpolation results, a high variation was found in Downlink (8 to 27 users per cell to use the full capacity in Downlink, 256 channel elements) whereas in Uplink the number of required users is around 3, which can be an indicator that the number of channel elements can become a very important capacity limiting factor in Uplink for the video call service.


The best fit that was found suggest an average number of users to reach the Downlink Iub target of 6 users/cell, which was more or less the level found to reach the target blocking in the air interface, then it seems to be a strong relationship between the target for blocking and the target to produce congestion in the Iub.

131

7.1.4.4 Uplink Load

UL Load [%]

0,0000%

10,0000%

20,0000%

30,0000%

40,0000%

50,0000%

60,0000%

0,9700 1,9500 3,9000 7,7900 15,5800


UL

Load

[%]

UL Load [%]

Figure 52: Uplink Load, video-call only service


Linear Fit: y=a+bx

a = -0.0051

b = 0.0343

Value when Y=0.60 17.46 Erl/Km^2



a = -0.0094

b = 0.0362

c = -0.0001

Value when Y=0.60 17.83 Erl/Km^2


Table 38: Estimation of the users per cell according to the simulation output, video call service, Uplink load target = 0.6 (60%)


132

According to the Figure and table shown above, Uplink Load is again, as in the case of speech, the most important capacity limiting factor, this can be observed because it is the factor that according to the number of users, reaches the target value first. The extrapolation results give very close results to each other because the highest traffic density used was quite close to produce the 60% uplink load target.



Linear Fit: y=a+bx

a = 36,398187

b = 0.11769338

Value when Y = 38.7 19.55 Erl/Km^2



Coefficient Data:

a = 36.4057

b = 0.0031

Value when Y = 38.7 19.4338 Erl/Km^2


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.


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.

133

7.1.4.7 Summary of video-call service

In the next table, a summary with the KPI’s ordered by the number of users that reaches first the target level is provided. In the case of KPIs with the same number of users, the order has been set according to the corresponding traffic density levels (without truncation).

KPI Target Level


Traffic density level

UL Load 60% 3 17,46

CE UL 64 3 17.74

DL power 38.7 dBm

3 19.55

DL code tree

60% 5 27.1968

Iub 1070 Kbps

6 32

Blocking prob.

1% 6 32.19

CE DL 256 9 49.7967

Table 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.


134

7.1.5 Summary single-service experiments

According to the analysis performed over the results, the capacity limiting factors for the different services are ordered according to the traffic density level that reaches first the target threshold, as follows:

7.1.5.1 Circuit-Switched Services:

Voice service Video call

CE UL UL Load

UL Load CE UL

DL power DL power

Iub DL code tree

DL code tree Iub

Blocking prob. Blocking prob.

CE DL CE DL

Dropped prob. Dropped prob.

Table 41: Comparison Limiting factors, CS services, single-service experiments, homogeneous scenarios

Besides the clear fact that the capacity is uplink limited for both services, DL Power must be also considered a critical resource for circuit switched services (is in the 3rd place for both Voice and Video call). The critical factors with middle importance are Iub Downlink utilization and DL code Tree utilization. The less critical factors according to the results are DL Channel Elements (therefore the capacity is “soft” limited rather than “hard” limited for CS services) and Dropped Probability, although for video-call service more experiments are required to verify this.

135

7.1.5.2 Packet-Switched Services:

FTP Service Web Service

Blocking prob. Blocking prob.

DL Iub DL Iub

DL power DL power

Dropping prob. CE UL

CE UL DL throughput (outdoor)

throughput UL Load

DL code tree DL code tree

UL Load CE DL

CE DL Dropping prob.

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

Apart from the clear difference regarding CS services about the main capacity limitation factors in Downlink instead of Uplink direction (something that was expected because of the higher data rates in Downlink for the PS services, which indeed consume more radio resources than their corresponding resources in Uplink Direction), we can notice additionally that for both kinds of services (CS, PS) the limitation is not mainly the “hard” but the “soft” resources , with exception of the Uplink Channel Elements usage which is an important limiting factor for both type of services.

Between the two simulated PS services, the main difference is the place of the Dropping Probability, in the Web Service no dropping probability was found with the simulated traffic loads (and therefore no estimation was possible for the load that reaches the 1% threshold); however, as it was mentioned before, this is in line with the RRM channel switching algorithms (switching from DCH to FACH), when the Web users can still keep the connection with data rates of 32 Kbps without been dropped by the system, as it happens with the FTP users that keep using mostly the DCH channels. However, in order to get more realistic results, new simulations have to be performed when the simulator includes the slow start mechanism which has a direct impact in the blocking and dropping probabilities.


136

7.2 Figures using the defined traffic mix percentages

To be able to perform this analysis, a consistent traffic unit has to be found, we cannot add directly the Erl/Km2 for each service because the resource utilization inter-arrival and service times are different for each service, therefore, we have to perform a conversion to a single unit. That unit was defined based on [umts-forum6] and it is called Offered Data Volume. The Offered Data Volume (ODV) is given in [Mbit/(busy) hour/Km2] and theoretically is defined as:

ODV = BHCA * service penetration * potential users / Km2 * Service Throughput [Mbps] * effective call duration [sec] (7-8)

Where:

BHCA = Busy Hour call attempts, which represents the number of calls per user (offered traffic per user) in the busy hour. This quantity, as defined in [Ericsson-tutorial] is equivalent to:

BHCA = 3600 * λ (7-9)

Where λ is the call arrival rate [calls / second].

On the other hand, the Offered Poisson Traffic can be defined as:

A [Erlangs] = λ / µ (7-10)

Where µ = service rate = 1/ E[s], where E[s] is the mean expected service time. Therefore:

A = λ * E [s] ( 7-11)

Putting λ in terms of A and E[s] and replacing in the definition of BHCA, we have:

BHCA = 3600 A / E [s] (7-12)

In this case, A would represent the offered traffic by each user. Putting everything together:

ODV = 3600 A / E[s] * service penetration/Km2 * potential users / Km2 * service throughput * effective call duration (7-13)

But:

Effective call duration = υ * E [s], where υ is the service activity factor, therefore:

137

ODV (offered traffic density) in Erlangs/Km2 = A * service penetration/Km2 * potential users / Km2 = active users/ Km2 (7-14)

Finally,

ODV = 3600 * Offered Traffic Density * Service throughput * υ (7-15)

υ was defined as 0.5 in the case of voice and 1 for all other services, and the Service throughput was defined averaging the throughput of the indoor and outdoor users obtained in the simulation results. The next table shows the calculations performed and the summary of ODV Figures to be analyzed (X-axis of the graphs of KPI vs. ODV).


138

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 Speech 10 0.0122 0.5 219.6

1 Videocall 0.97 0.064 1 223.488

1 FTP 0.39 0.25 1 347.3916069

1 Web 1.62 0.31 1 1827.212255

total ODV Experiment 1 2617.691861

2 Speech 20 0.0122 0.5 439.2

2 Videocall 1.95 0.064 1 449.28

2 FTP 0.78 0.22 1 605.020308

2 Web 3.25 0.24 1 2826.786672


3 Speech 40 0.0122 0.5 878.4

3 Videocall 3.9 0.064 1 898.56

3 FTP 1.56 0.17 1 933.4731671

3 Web 6.49 0.19 1 4485.439296


139

4 Speech 80 0.0122 0.5 1756.8

4 Videocall 7.79 0.064 1 1794.816

4 FTP 3.12 0.12 1 1330.948855

4 Web 12.99 0.11 1 4998.538791


5 Speech 160 0.0122 0.5 3513.6

5 Videocall 15.58 0.064 1 3589.632

5 FTP 6.23 0.06 1 1317.665429

5 Web 25.97 0.04 1 3355.780886


Table 43: Calculation of the ODV for the Service Mix, non-homogeneous scenario

141

Experiment ODV [Mbit/busy hour / Km^2]

1 2617.6918612 4320.286983 7195.8724634 9881.1036465 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


0.0000%

10.0000%

20.0000%

30.0000%

40.0000%

50.0000%

60.0000%

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


Blockedservices [%]

Figure 53: Blocking probability service mix, target =0.01 (1%)


Harris Model: y=1/(a+bx^c)

a = 2568.9699

b = -1608.3547

c = 0.0500

Standard Error: 0.01022

Correlation Coefficient: 0.9994


142

Value at Y=0.01 5279.6000 Mbit/hour/Km^2

ODV per cell per hour 926.2456Mbit/hour/cell

ODV per cell per second 0.2572 Mbit/sec/cell

ODV Kbps/cell

257.2904

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

Web indoor 163,759 2

FTP indoor 237,7139 1

Web outdoor 156,9783 2

FTP outdoor 241,8718 1

Voice 11,97 22

Video-call 63,65 4

Table 46: Estimation of the supported number of users per service

This IS in line with the simulation results obtained by Vodafone Germany in [Schneider-1] and it represents a big change in the supported number of Voice Users obtained in the Voice-only service, where the theoretical value (and the obtained value) was around 42 users per cell, now the Figure is about a half of it, but we have to take into account that the Figures presented in the table 34 are just an estimation because the offered traffic was a traffic mix and not a single-service offered traffic.

143


0.000000%2.000000%4.000000%6.000000%8.000000%

10.000000%

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783



Figure 54: Dropping probability service mix, target =0.01 (1%)

Dropping probability, target threshold = 0.01 (1%)

Reciprocal Logarithm Fit: y=1/(a+b*ln(x))

Coefficient Data:

a = 10.937.20

b = -1.168.57

Standard Error: 0.0007945

Correlation Coefficient: 0.9998536

Value at Y=0.01 10660 Mbit/hour/Km^2

ODV per cell per hour 1870.1754 Mbit/hour/cell


ODV Kbps/cell 519.4931 Kbps/cell

Table 47: Dropping probability service mix, target =0.01 (1%)

For the dropped services, we can see that the Load required to reach the target is higher (almost twice as much) than in the case of blocking probabilities. This goes in line with the behavior defined in the Ericsson RRM Algorithms were dropping calls is the last option at all while soft blocking of non-guaranteed connections (i.e. data connections) is the first option to free radio resources in case of congestion.


144

7.2.2 Channel Elements usage


0.0000

50.0000100.0000

150.0000

200.0000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783

DL

chan

nel e

lem

ents



Figure 55: Channel Elements usage service mix, Downlink target 256


0.000020.000040.000060.000080.0000

100.0000120.0000140.0000160.0000180.0000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


UL

chan

nel e

lem

ents


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.

145

Downlink Channel Elements (target 256)


Coefficient Data:

a = 18.3079

b = 5.11E-03

c = 7.27E-07

Value at Y=256 14899.40 Mbps/hour/Km^2




Uplink Channel Elements (target 256)


Coefficient Data:

a = 12.8075

b = 0.0002

Value at Y=64 6518.6300 Mbps/hour/Km^2




Table 48: Channel Elements usage, service mix, uplink and downlink channel elements target: 256, 64

So far we can appreciate that the Downlink Channel Element threshold is reached after the Blocking and Dropping Target, but the UL channel Element threshold is reached before the Dropping Target. However, we must continue with the analysis to see which the order of occurrence of each target is.


146

7.2.3 Downlink Iub usage

Iub traffic [DL]

0.0000200.0000400.0000600.0000800.0000

1000.00001200.00001400.00001600.00001800.00002000.0000

2617.6919

4320.2870

7195.8725

9881.1036


Kbp

s

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 = -132.5321

b = 0.1951

Value at Y=1070 6164.99 Mbit/hour/Km^2




Table 49: Downlink Iub utilization, service mix, Downlink target 1070 Kbps

Therefore, Iub downlink utilization, so far, is the second factor after the blocking target that is reached first.

147

7.2.4 Uplink Load

UL Load [%]

0.0000%10.0000%20.0000%30.0000%40.0000%50.0000%60.0000%70.0000%80.0000%90.0000%

100.0000%

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


Noi

se R

ise

[%]

UL Load [%]

Figure 58: Uplink load, service mix



Coefficient Data:

a = -0.1363

b = 8.39E-05

c = 8.16E-10

Value at Y=0.6 8135.76 Mbit/hour/Km^2




Table 50: Uplink load, service mix, target 60%

According to the graph we clearly see that the threshold level for soft congestion triggering (60% Uplink load) is reached within the interpolation range, therefore only the best fit is provided. Taking a look at the results, we see that so far Uplink load is, after Dropping probability, the least frequent reached KPI threshold.


148

7.2.5 Downlink Transmitted Power

DL_TxPower [dBm]

34.000035.000036.000037.000038.000039.000040.000041.000042.000043.0000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


Pow

er [d

Bm

]

DL_TxPower [dBm]

Figure 59: Downlink transmitted power usage, service mix


Coefficient Data:

a = 3.68

b = -1.97E-05

c = 3.75E-08

Value when Y=38.7 7360.59 Mbit/hour/Km^2




Table 51: Downlink power usage, service mix, target 38.7 dBm

According to the Figure 60, again the target threshold level (38.7 dBm) is reached within the interpolation range, therefore only the best fit is presented. The Downlink transmitted power, which was the main limiting factor especially for Data Services in the single-service simulations, now it is still important but in the place after Downlink Channel Elements utilization according to the simulation results.

149

7.2.6 Downlink Code Tree Usage


0.00000.10000.20000.30000.40000.50000.6000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


Cod

e tre

e us

age

[%]


Figure 60: Downlink code tree usage, service mix



Coefficient Data:

a = 0.009300566

b = 4.19E-05

c = 8.67E-10

Value when y = 0.6 11406.08 Mbit/hour/Km^2




Table 52: Downlink code tree usage, service mix, target 0.6 (60%)

In this experiment, the last simulation presented some errors so the value corresponding to the highest load had to be discarded and an extrapolation is provided based on the interpolation of the first four points of the data set. According to the best fit, the Downlink code tree usage would be, with the assumed traffic densities, the less important capacity limiting factor. Next table shows the order of capacity factors according to the number of supported users, i.e. according to the Figure ODV


150

Kbps/cell. This order would be the order of occurrence of the factors in the simulated scenario, ordered for lowest ODV Figure (the one that reaches first the target level) to highest ODV.

KPI Load to reach the target (ODV Kbps/cell)

Blocking probability 257.2904

Iub utilization 300.4381

Downlink Power usage 358.7032

Uplink load 396.4795

Dropping probability 519.4931

Code Tree usage 555.8518

Table 53: Summary Table, capacity limiting factors

The first result is not surprising, as there are many sources that causes blocking, not only to new calls but also is possible to have some blocking level for hand-over calls, although the priority to block calls is given to the non-guaranteed, non-handover calls according to Ericsson RRM algorithms. The most frequent blocking reasons that were found are as follows:

• DL transmit power limit exceeded (cell) • DL Code usage limit exceeded • 21: DL congestion • DL ASE usage limit exceeded

Iub Downlink utilization is another expected result, as it was assumed just 1 E1 of capacity between Node B and RNC, from which there is just 1070 Kbps available, which means that few users working at their maximum data transfer rate would be able to block the complete cell.

Given the presence of Data Services and given that in the conversion of units the service that presents major contribution in the calculated ODV is the web service, the Downlink Load, more than the Uplink, is expected to be one of the most important capacity limitations. In fact, no call blocked or dropped due to the Uplink load was registered in the simulation output.

About dropping probability, it was expected to be one of the last factors to happen, mostly because the Ericsson RRM algorithms specify the dropping of a call as the last action to take to resolve congestion situations, before dropping can happen, a series of corrective measurements that involves Down switching of the non guaranteed connections have to be tried in the system with the aim of freeing radio resources.

151

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

0.000050.0000

100.0000150.0000200.0000250.0000300.0000350.0000400.0000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783

Offered Data Volume Mbit/busy hour/Km^2]

Kbp

s

DL Throughput

Figure 61: Web indoor application downlink throughput

Web outdoor Application DL throughput per user

0.000050.0000

100.0000150.0000200.0000250.0000300.0000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


Kbp

s

DL Throughput

Figure 62: Web outdoor application downlink throughput


152

FTP Indoor Application DL Throughput per user

0.000050.0000

100.0000150.0000200.0000250.0000300.0000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


Kbp

s

DL Throughput

Figure 63: FTP indoor application downlink throughput

FTP outdoor Application DL throughput per user

0.000050.0000

100.0000150.0000200.0000250.0000

2617.6919

4320.2870

7195.8725

9881.1036

11776.6783


Kbp

s

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.

153

Surprisingly, the performance of the FTP service was lower than the performance (in Kbps) of the Web service for the given scenario. This is something that needs to be verified with more simulations in a further study.

7.3 Power-rule study

The Power Study, with the setup for the homogeneous scenario defined in Chapter 5, was performed checking the following three Handover performance indicators. The definition of them is presented here as they are defined in [WinesTechRef]:

• Pilot Polution [num]: The number of polluting pilots. A pilot is

considered polluting if it is transmitted by a cell in either the monitored or the detected set and its RSCP level is within a configurable margin below the best pilot's RSCP level.

• Active Set Size [num] : The number of active cells, i.e. the

number of soft handover branches for the referred UE.

• SHO Blocked_Add_Link [reason]: Reason for a blocked soft handover Replace Link request for the referred requested cell.

The expected behavior, as it was also mentioned in [Haverkamp-cpichstudy] is that the unbalance in the power levels caused by the different downlink losses (and therefore different CPICH levels per each cell) creates zones where the mobile is forced to transmit with its highest power even though it is close in distance to a cell where theoretically it could be connected to, and because of this at some point in time the power of the mobile is not sufficient and the call is dropped. Additionally, as it is mentioned in [Ericssonhandover], unbalance in the CPICH powers causes also bigger zones with Pilot Pollution problems, i.e. zones where there are many potentially dominant CPICH levels that causes problems for the receiver to determine which one is the best one and probably cause ping-ponging effects changing back and forth of best CPICH (high Handover signaling). Then, preferably only one dominant CPICH per area should exist. Pilot pollution gives a high average number of active radio links, which decrease the traffic capacity and reduce the probability that the UE get all neighboring cells included due to the size limited monitored set [Ericssonhandover].


154

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)

155

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.


156

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)

157

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).


158

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.

159

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.


160

7.4.2 Uplink load (Voice service)

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

10 20 40 80

UL Noise Rise [%]vehicularUL Noise Rise [%]pedestrian

Traffic Density [Erl / Km^2]

Uplink Load [%]

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.

161

7.4.3 Downlink Power usage (Voice service)

Downlink Transmitted Power, Vehicular and pedestrian profiles

36,0000

36,2000

36,4000

36,6000

36,8000

37,0000

37,2000

37,4000

37,6000

10,0000 20,0000 40,0000 80,0000

Traffic Density [Er;/Km^2]

Pow

er le

vel [

dBm

]

DL_TxPower [dBm]pedestrianDL_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

0,0000

50,0000

100,0000

150,0000

200,0000

250,0000

300,0000

12,99 25,97


Dow

nlin

k Th

roug

hput

[Kbp

s]

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


162

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.

163


7.5.1 Single service experiments

The main findings for Circuit Switched (CS) only-service experiments (from Voice series) were as follows:

Blocking probability: more simulations with higher traffic loads are suggested to test the extrapolation results and to try to achieve the blocking target (1%). The lower range estimation obtained with extrapolation is in line with the theoretical result obtained via analytical procedure, as described in [Holma].

Iub utilization: The target level was reached within the simulation range of traffic densities. For the simulation series, Iub utilization is the 2nd KPI that is reached first in its target level. 1 E1 circuit was assumed to make the calculations.

Downlink Power usage: the usage was slightly higher for CS instead of PS services for the range of simulated traffic densities.

Uplink load: it shows to be more critical for CS rather than PS services for the simulated traffic density levels.

Dropping probability: More simulations are required to achieve the target (1%) and verify the estimated values.

Code Tree usage (DL): It is not very critical for CS services according to the simulation results.

Channel element usage (UL/DL): UL Channel elements target was reached within the simulations range, DL channel elements target not. Simulations with higher loads are required to check the estimations and to try to reach the DL target of 256 within the range of simulated loads.

The main findings for packet switched-only services (from the web service results) were as follows:

Blocking probability: with sf8Adm parameter set to 1, the simulator presents unrealistic results because the implementation of the packet access doesn’t follow exactly the slow start mechanism implemented in the real networks (this feature is going to be implemented in the next release of the simulator). With sf8Adm =8 (which means no restrictions because Ericsson’ histogram admission policy) the number of users per cell is around 2 which is close to the number obtained by analytical methods.

Iub utilization: the target utilization is reached with about 2.5 users (5 users with an activity of 50%)

Downlink Power usage: Slightly lower for PS than for CS services


164

Uplink load: Very low levels obtained with the simulated traffic densities. Experiments with higher loads are proposed in order to reach further conclusions.

Dropping probability: no dropping due to P3 algorithm (down-switching)

Code Tree usage (DL): It was lower for PS rather than for CS

Channel element usage (UL/DL): for the CE usage in DL, simulations with higher traffic densities are required to reach further conclusions, for UL CE usage, around 8 to 12 users reach the target usage of 64 CE.

Throughput: mean value of around 150 Kbps for the range of input traffic densities.

7.5.2 Traffic mix homogeneous scenario

As traffic densities from different services cannot be added, the unit chosen to make the analysis was Offered Data Volume, defined as:

ODV = 3600 * Offered Traffic Density * Service throughput * υ

The main results (i.e. KPI ordered by occurrence of its target level) are summarized in the next table:

KPI Load to reach the target (ODV Kbps/cell)

Blocking probability 257.2904

Iub utilization 300.4381

Downlink Power usage 358.7032

Uplink load 396.4795

Dropping probability 519.4931

Code Tree usage 555.851852

Table 54: List of KPIs organized by order of occurrence of their target levels

7.5.3 Power study

The main concussion of this study after the comparison of all the graphs, is that in the assumed (symmetric and homogeneous) scenario, with the assumed levels of link losses (up to 4 dB) there are not significant differences between the PCICH power rule of The Netherlands and the PCICH power rule of Germany.

165

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.


166

8. Simulation results Second Scenario (non-homogeneous) and comparison with the homogeneous scenario

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

8.1 Summary of the Single-service simulations

8.1.1 Voice Service

8.1.1.1 Preliminary considerations about the Real Scenario analyses

As is pointed out in [Schneider-2], in a real scenario with non-homogeneous traffic densities, the analysis is more complex compared with the homogeneous scenario, as one cell is no longer representative for the whole network, therefore, ideally one should perform an analysis per each cell. However, as we have 53 cells in the analysis area and because of the restrictions in time, it was not possible to make such detailed analysis. To give an impression of how the KPIs can differ from cell to cell, a histogram of the Downlink Transmitted Power and the Uplink Load was created, together with the cumulative density function for all the 5

167

different voice traffic densities. The following graphs illustrate the results for the maximum of those densities (160 Erl/Km2).

Downlink Transmission Power histogram

0

1

2

3

4

5

6

35,0035,3535,736,0536,436,7537,137,4537,838,1538,538,8539,239,5539,940,2540,640,9541,341,6542

Downlink Power [dBm]

coun

t

0

0,10,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

Countcum 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

0

1

2

3

4

5

6

7

0,00%4,30%8,60%12,90%17,20%21,50%25,80%30,10%34,40%38,70%43,00%47,30%51,60%55,90%60,20%64,50%68,80%73,10%77,40%81,70%86,00%

Uplink Load [%]

coun

t

0

0,10,2

0,3

0,4

0,50,6

0,7

0,80,9

1

Count

cumulative 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.


168

Cell DL Transmitted power [dBm] U000751 40.34 U000752 41.21 U000753 36.79 U000791 39.47 U000793 41.37 U000801 40.01 U000802 37.75 U000803 37.99 U009641 36.47 U009642 40.65 U009643 37.37 U011031 37.09 U011032 37.80 U011033 40.98 U011071 41.36 U011072 41.64 U011073 37.89 U011381 41.19 U011382 39.79 U011383 38.47 U014671 36.98 U014672 36.55 U014673 38.58 U030761 41.37 U030762 40.06 U030763 35.96 U030771 40.81 U030772 41.17 U030773 39.63 U030821 37.97 U030822 36.64 U030823 37.22 U030841 37.73 U030842 39.95 U030843 36.76 U030851 36.37 U030852 38.44 U030853 39.43 U032311 40.67 U032312 38.04 U032313 39.77 U035701 37.23 U035702 37.05 U035703 40.47 U046611 40.76 U046612 40.13 U046613 38.12 U051651 36.60 U051652 36.13 U051653 36.29 U052011 38.81

169

U052012 39.52 U052013 39.42 average: 38.80Std. dev: 1.7321

Table 55: Downlink Transmitted Power levels per cell, non homogeneous scenario

According to what we can see in the Figure 76, nearly 70% of the cells are in congestion situation (in other words, nearly 30% of the cells have a power levels below 37.8 dBm which is the congestion limit), so the mean value of 38.80 dBm and the standard deviation of 1.7321 (from the table 53) are just a rough estimate of the real power levels per cell. We have to take into account this restriction when performing a complete analysis (for instance in a concrete area that requires optimization), because with our mean value assumption we are assuming that for this particular traffic density, all the cells are in congestion, when the true situation is that around 70% are in this situation and 30% are not, but this is only possible to determine only when taking a detailed look at the cumulative distribution function of each KPI.

The same situation can be observed with the uplink load illustrated in Figure 77, where near 60% of all the cells have an uplink level below the target uplink load level (60% of load in the X-axis). When we take the average Uplink Load (46.73%) we are assuming that the 100% are not in Uplink load situation but the true situation is that near 40% of the cells are above the (soft) congestion limit.

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


The target level of 1% blocking was reached within our interpolation range, so we present the two-best fits in the next table.


170

Target threshold = 1% (0.01 linear scale)


a = 0.0068

b = -0.00049

c = 5.51E-06

Value with Y=0.01 95.226 Erl/Km^2

Number of Users per cell 62

Linear Fit: y=a+bx

Coefficient Data:

a = -0.0145

b = 0.0004

Value with Y=0.01 53.4073 Erl/Km^2


Table 56: Estimation of the number of users until reaching the blocking target (1%), non homogeneous scenario, voice only service

As the target blocking was reached within the interpolation range, a narrower (and more realistic) range was found in the non-homogeneous scenario, from 35 to 62 users, which is much closer to the theoretical Figure of 42 users per cell provided by [Holma] than the range obtained by extrapolation of results with the homogeneous scenario (from 49 to 248 users).

The “real” network experienced higher blocking than the ideal scenario. The cell layout has strong influence in the handover performance as in this case the layout is not perfectly hexagonal; indeed higher dropping probability was experienced because of the blocked radio link additions (handover event 1A).

The traffic density for the dropping probability target produced around 54 users per cell which is close to the lowest limit obtained in the homogeneous scenario (61). Besides, according to the RRM expected behavior, dropping always happens after blocking has been experienced, so the results are in line with this. However, comparing traffic densities between both scenarios, the traffic densities to reach the target blocking and dropping levels are lower in the non-homogeneous case. Making the exercise of calculating the number of supported users per cell with the cell area of the homogeneous case (0.1755 Km2 ) with our upper limit from the non-homogeneous case (95.26 Erl/Km2) would result in around 17 voice users per cell which is low compared with the theoretical value of 42 users. However, in the homogeneous case it was pointed out that more

171

simulations are needed to come up with a better estimation of the number of supported users per cell.



0,000020,000040,000060,000080,0000

100,0000120,0000140,0000160,0000

10,00

00

20,00

00

40,00

00

80,00

00

160,0

000


DL c

hann

el e

lem

ents


Figure 78: DL Channel elements usage, voice only service, non homogeneous scenario


0,000020,000040,000060,000080,0000

100,0000120,0000140,0000

10,00

00

20,00

00

40,00

00

80,00

00

160,0

000


UL

chan

nel e

lem

ents


Figure 79: UL Channel elements usage, voice only service, non homogeneous scenario

CE Usage, Downlink


Coefficient Data:

a = 9

b = 0.98891575

c = -0.00183311



Linear Fit: y=a+bx


172

Coefficient Data:

a = 17

b = 0.67270421



CE usage, Uplink


Coefficient Data:

a = -2

b = 0.9889

c = -0.0018



Linear Fit: y=a+bx

Coefficient Data:

a = 4.6884

b = 0.6727



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

With the non-homogeneous scenario, again the target of 256 DL CE was not reached within the simulation range and therefore a extrapolated values from the best-fit analysis are presented, the obtained traffic densities (223 to 335 Erl/Km2) are more or less in line with the range obtained in the homogeneous scenario (295 to 334 Erl/ Km2). In the case of the Uplink, as in the homogeneous scenario, the target was reached with around 78 Erlangs/Km2 (the corresponding traffic density for the homogeneous scenario was 73.32). The levels of required traffic density to reach the target in Uplink are very close in both scenarios.

173

8.1.1.4 Iub utilization

Iub traffic [DL]

0,0000100,0000200,0000300,0000400,0000500,0000600,0000700,0000

10,00

00

20,00

00

40,00

00

80,00

00

160,0

000



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 [%]

0,0000%5,0000%

10,0000%15,0000%20,0000%25,0000%30,0000%35,0000%40,0000%45,0000%50,0000%

10,0000

20,0000

40,0000

80,0000

160,0000


Noi

se R

ise

[%]

UL Load [%]

Figure 81: Uplink load, voice only service, non homogeneous scenario


174

The traffic density to reach the target level of 60% Uplink load was not reached within the simulation range, therefore, applying the analysis over the best interpolation fits, the range of [201.298, 280.022] Erl/Km2 was found, which is somewhat different from the range found in the homogeneous scenario, [130.8437, 182.0143] Erl/Km2, and so is the expected number of users. This difference can be attributed to the averaging process mentioned in section 8.1.1.1, where we clearly saw how our assumption for averaging purposes in the sense that all the cells are not experiencing congestion, it is not true for almost 40% of the cells in the realistic scenario. Therefore, interference analysis is quite difficult to analyze over the whole network as the interference situation is very particular for every cell and a more complete analysis is proposed for further studies.


DL_TxPower [dBm]

34,0000

35,0000

36,0000

37,0000

38,0000

39,0000

40,0000

10,0000

20,0000

40,0000

80,0000

160,0000


Pow

er [d

Bm

]

DL_TxPower [dBm]

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.

175

8.1.2 Web Service

8.1.2.1 Downlink code tree usage


0,0000%5,0000%

10,0000%15,0000%20,0000%25,0000%30,0000%35,0000%40,0000%

10,0000

20,0000

40,0000

80,0000

160,0000


Cod

e tre

e us

age

[%]


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


0,0000%5,0000%

10,0000%15,0000%20,0000%25,0000%30,0000%35,0000%40,0000%

10,0000

20,0000

40,0000

80,0000

160,0000


Cod

e tre

e us

age

[%]


Figure 84: Downlink code tree usage, web service only, non homogeneous scenario


176

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

0,000050,0000

100,0000150,0000200,0000250,0000300,0000

1,62

3,25

6,490

0

12,99

00

25,97

00


Kbp

s

DL Throughput

web outdoor Application DL throughput

0,0000100,0000200,0000300,0000400,0000

1,62

3,25

6,490

0

12,99

00

25,97

00


Kbp

s

DL Throughput

Figure 85: Downlink throughput, web-only service, non homogeneous scenario, indoor user

Downlink throughput, web-only service, non homogeneous scenario, outdoor user

177

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 target level ODV at target level* (Mbit/busy

hour/Km^2)

blocking probability 1% 3868,06

Dropping probability 1% 6041,83

Iub utilization 1070 Kbps 6322,14

DL power usage 38,7 dBm 6646,23

channel elements, UL 64 9146,39

UL Load 60% 12004,6

DL code tree usage 60% 15482,6

channel elements, DL 256 20656

Table 58: List of KPIs for the non-homogeneous scenario, ordered by the occurrence of the target threshold


178


hour/Km^2)

blocking probability 1% 5279.6000

Iub utilization 1070 Kbps 6033.81

channel elements, UL 64 6518.6300

DL power usage 38.7 dBm 7360.59

UL Load 60% 8052,83

Dropping probability 1% 10660

DL code tree usage 60% 11406.08

channel elements, DL 256 14899.40

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 non-homogeneous scenario and the uplink channel elements utilization that appears before the downlink power usage in the homogeneous scenario. About the level of ODV, the non homogeneous scenario reaches first its first target, blocking probability at 1% with 3868.06 Mbit/busy hour/Km2 compared with 5279 of the homogeneous counterpart, but to reach the last target threshold, the situation is the other way around, the target is first reached at 14899,40 Mbit/busy hour/Km2 in the homogeneous scenario, whereas the non-homogeneous scenario reaches this threshold at 20656 Mbit/busy hour/Km2. Then we can say, according to the simulation results, that in the realistic scenario, the first threshold is reached before the homogeneous level (then the homogeneous level is giving somewhat optimistic values for this first KPI), but to reach the last KPI threshold, DL channel elements, the homogeneous scenario results somewhat pessimistic as with the realistic scenario the target is reached at a higher level of ODV.

Going a bit further when trying to explain why in the homogeneous scenario we had more dropping, the following reasons where found:

With the traffic mixes with up to 160 Erl/Km2 of voice users (and the corresponding densities for the rest of services given as the 5th column in the Table 4), the main reasons for dropping, in the non homogeneous scenario, were as follows:

• 14: Blocked radio link addition

• 21: DL congestion

179

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


180

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.

181

8.4.1 Uplink load (Voice service)

comparison UL Load -vehicular vs pedestrian profile [%]

0.0000%5.0000%

10.0000%15.0000%20.0000%25.0000%30.0000%35.0000%40.0000%45.0000%50.0000%

10.00

00

20.00

00

40.00

00

80.00

00

160.0

000


Upl

ink

load

[%]

UL Load, vehicular [%]UL Load, pedestrian [%]

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).


182

8.4.2 Downlink Power usage (Voice service)

comparison DL_TxPower [dBm] vehicular vs pedestrian mobility profile

34.0000

35.0000

36.0000

37.0000

38.0000

39.0000

40.0000

10.0000 20.0000 40.0000 80.0000 160.0000


Pow

er [d

Bm

]

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

DL Throughput [kbps], pedestrian profile

FTP UE indoor 168.62 175.0435182

FTP UE Outdoor 165.40 195.8084226

Internet UE indoor 165.24 192.7750935

Internet UE outdoor 183.67 196.7226692

Video call indoor 62.79 63.04505226

Video call outdoor 62.63 63.03418639

voice UE indoor 11.93 11.93639358

voice UE outdoor 11.93 11.9366576

Table 60: Downlink Throughput levels for all services, traffic mix with voice 40 Erl/Km2, non homogeneous scenario

183

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).


184

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.

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

Sector 1

Sector 2

RNC

Node B 1

Node B 2RNC

Softer Handover Soft Handover

Sector 1

Sector 2

RNC

Node B 1

Node B 2RNC

Softer Handover Soft Handover

Figure 90: Differences between Soft and Softer Handover

185

established to each of the cells present in its Active Set. This set is updated dynamically (event based) during all the time that a connection is alive, based on the measurements of the strength of the Primary Common Pilot Channel (P-CPICH) Ec/Io or the Primary Common Pilot Channel (P-CPICH) RSCP (Received Signal Code Power).

Ec/Io can be defined in terms of RSCP in the following way:

Ec/Io = RSCP/RSSI (8-1)

Where RSCP is the power (measured in the UE) carried by the decoded pilot channel and RSSI (Received Signal Strength Indicator) is the total wideband received power (measured in the UE) within the channel bandwidth.

So basically, during a user service session, there are these possible events related to Active set updating (using the name of the events described in [25.922]:

• Event 1A : add new cell • Event 1B : remove cell • Event 1C : replace cell (if the active set is full) • Event 1D : change best cell

Best Cell, according to [Ericssonhandover], is defined as the cell, among the ones in the Active Set, having a measured P-CPICH with the highest quality Ec/No.

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

The parameter Timetotrigger1a, as documented in [Ericssonhandover] is a timer that represents the minimum time required to trigger the Event 1a. Event1a represents the Addition of a new cell to the active set. The Handover Algorithm example in [25.922] is presented


186

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.

.

AS_Th – AS_Th_HystAs_Rep_Hyst

As_Th + As_Th_Hyst

Cell 1 ConnectedEvent 1A

⇒ Add Cell 2Event 1C ⇒

Replace Cell 1 with Cell 3Event 1B ⇒

Remove Cell 3

CPICH 1

CPICH 2

CPICH 3

Time

MeasurementQuantity

∆T ∆T ∆T

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).

Equivalent to Timetotrigger 1A

CPICH 2 > CPICH1 – (AS_Th – AS_Th_Hyst) for a time > ∆t→Add Cell

187

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].


188

This means that we use two variables (or factors) which are carefully controlled and varied to study their impact on the performance. In our case, these two variables are the Traffic Densities (corresponding to the 5 columns of the Table 4) and the parameter TimetoTrigger1a with its possible levels. The following Table shows the levels (values) chosen for this parameter.

Minimum Value 0 millisecond

Value from Vodafone Netherlands (same as default value)

200 millisecond

Value from Vodafone Global 320 milliseconds

Maximum value 5000 millisecond

Table 61: Chosen levels for the parameter Time to Trigger 1A

Once the input variables have been chosen, we have to define the output variables, i.e. the “measured” data as referred in [Jain], although in this case there is not measured data as such but simulated. Knowing the expected behavior from Ericsson, we can monitor the performance in terms of:

Uplink Interference Load [%] Soft Handover Attempts [num]

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

To make the analysis, the Data has to be organized in a matrix where each column represents each of the parameter Timetotrigger1a levels (named factor A in this description) and each row represents the different levels of traffic densities (identified as Mix1_10Erl, Mix2_20Erl, Mix3_40Erl, Mix4_80Erl and Mix5_160Erl respectively, named factor B in this description). Each entry in the matrix, Yij, represents the response in the experiment where factor A is at level I and factor B at level j. For instance, Y12 would be equivalent in our setup to Y (Minimum Value, Mix2).

189

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:

ijY = µ + αj + Bi (8-2)

Once this is defined, the Error Matrix can be found by subtracting position to position the estimated response matrix from the “measured” response matrix. Each entry of the error matrix is defined as follows:

Errorij = Yij (measured) - ijY (8-3)

As the values of the µ, αj’s and Bi’s are computed such as the error has zero mean, this matrix has the property that the sum of all the entries in a row or column must be zero.

Next step is to calculate the sum of squared errors (SSE) which is defined as

SSE = Σ (eij2) (8-4)

Where this sum is performed including all entries in the error matrix.

Next, the total variation SST (which is different from the total variance) is calculated as:

SST = SSA + SSB + SSE (8-5)

Where:

• SSA = b * Σ (αj)2 where b= number of rows


190

• SSB = a Sum (Bi)2 where a=number of columns

At this point, we can also calculate the percentage of variation explained by each factor (which should be higher than the percentage of variation explained by errors to consider that a parameter has a significant impact in the performance). The percentage of variations by each factor is defined as:

Percentage of variation explained by A = SSA/SST

Percentage of variation explained by B = SSB/SST

Percentage of variation explained by errors =SSE/SST

To statistically test the SIGNIFICANCE of a factor, we must divide the sum of squares by their corresponding degrees of freedom (Df). In this case, the corresponding Dfs are:

• SSA Df = (a-1)

• SSB Dfs = (b-1)

• SSB Errors = (a-1)*(b-1)

The degrees of freedom of the factors A and B are because the errors in each column should add 0 and in each row as well and for the errors the degrees of freedom is the product of DfA and DfB.

Next we proceed to calculate the mean squares of all factors as follows:

MSA = SSA / (a-1) (8-6)

MSB = SSB / (b-1) (8-7)

MSE = SSE/ ((a-1)*(b-1)) (8-8)

At this point we can also calculate the Standard Deviation of each of the factors:

SSE = STANDAR DEVIATION OF ERRORS = √(MSE) (8-9)

Standard DEVIATION µ = Se/ (ab) (8-10)

Standard DEVIATION αj = Se* √ ((a-1)/ab) (8-11)

Standard DEVIATION Bi = Se √ ((b-1)/ab) (8-12)

191

Variance of each factor = (Standard deviation of the factor)2 (8-13)

After mean and variance of each parameter are known, a confidence interval (defined as a function of the mean and the standard deviation) can be calculated using statistical methods.

The last part is to calculate the F-ratios to test the statistical significance of the factors (a systematic confirmation from the previous results based on a statistical test). F-ratios are defined as follows:

Fa = MSA/MSE (8-14)

Fb = MSA/MSE (8-15)

Then, the factor A is considered significant at level alpha (significance level, an alpha 0.05 is defined for a 95% confidence interval) if the computed ratio is more than FcritA = F[1-alpha,a-1, (a-1)(b-1)], where F is computed from the table of quantiles of F variates. Accordingly, the factor B is considered significant at level alpha if the computed ratio is more than FcritB = F[1-alpha,b-1, (a-1)(b-1)] from the table of quantiles of F variates. All these values are conveniently arranged by Excel so after knowing the procedure, we would present the results and provide the conclusions using the criteria presented.

8.5.3 Simulation Results

First of all, we are going to show the original matrices with the “measured” results with the Uplink Interference Load and the Soft Handover Attempts. Next two tables illustrate the original matrices.

min-level (0 msec)

Netherlands level (200 msec)

global level (320 msec)

max-level (5000 msec)

MIX1_10Erl 199 191 191 174

MIX2_20Erl 2132 403 424 372

MIX3_40Erl 1240 879 873 1785

MIX4_80Erl 3019 1777 2704 1658

MIX5_160Erl

139329 8282 7202 2770

Table 62: Original table for ANOVA, Cell HO attempts


192

min-level (0 msec)

netherlands level (200 msec)



MIX1_10Erl 10.27% 10.20% 10.18% 10.47%

MIX2_20Erl 20.30% 20.44% 20.52% 20.95%

MIX3_40Erl 42.32% 43.02% 42.61% 47.21%

MIX4_80Erl 72.99% 77.48% 73.75% 76.90%

MIX5_160Erl 88.61% 89.38% 90.02% 90.28%

Table 63: Original table for ANOVA, Uplink Load

Next, we show the Analysis of Variance after applying the Excel Data Analysis Toolkit over the original tables and afterwards we draw the main conclusions.

8.5.3.1 Analysis of Variance (ANOVA)

the results obtained for each measured response (i.e. Handover attempts and Uplink Load interference) after applying the ANOVA-2 factor without replication analysis were as follows:

Source of Variation SS df MS F F crit

Rows 4695850801 4 1173962700 1.33424525 3.25916

Columns 2778331540 3 926110513.2 1.052553504 3.4903

Error 10558442984 12 879870248.7

Total 18032625325 19

Table 64: ANOVA of Handover attempts, additive model


Rows 1.866556606 4 0.466639151 3032.14678 3.25916

Columns 0.001438522 3 0.000479507 3.115761269 3.4903

Error 0.001846767 12 0.000153897

Total 1.869841895 19

Table 65: ANOVA of Uplink load, additive model

193

The ROWS factor corresponds to the different traffic densities (5 levels) and the COLUMNS factor corresponds to the 4 levels of the parameter time to trigger 1a (0.200. 320 and 5000 msec). The columns are respectively:

• SS = Squared Sum of each factor • Df = degrees of freedom (number of independent terms to obtain

the Squared Sum) • MS = Mean Square value = SSparameter / Dfparameter

• F = Computed F factor = MSfactor /MSE where MSE is the Mean Square Error (SSE/Dferror).

According to the ANOVA test of the Handover attempts (table 62), the percentage of variation explained by each factor is as follows:

• Percentage explained by Rows (load) = SSrows / SStotal = 26% • Percentage explained by columns (time to trigger levels) =

SScolumns/SStotal = 15 % • Percentage explained by errors = SSerrors/ SStotal = 59%

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

Yij = Vi * Wj (8-16)

If we take logarithm at both sides, we have an additive model:

Log (Yij) = Log(Vi) + Log(Wj) (8-17)

In the case of two-factor experiments, the additive model assumed so far was:

Yi = µ + αj + Bi + eij (8-18)

If we assume a logarithmic transformation, this means that the model would be:

Log (Yi) = Log µ + Log αj + Log Bi + Log eij (8-19)

Therefore, the output in linear fashion would be:


194

Yi = 10 µ * 10 αj * 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_10Erl

2,298853076 2,281033367 2,281033367 2,240549248

MIX2_20Erl

3,3287872 2,605305046 2,627365857 2,57054294

MIX3_40Erl

3,093421685 2,943988875 2,941014244 3,25163822

MIX4_80Erl

3,479863113 3,249687428 3,432006687 3,219584526

MIX5_160Erl

5,14404152 3,918135226 3,857453117 3,442479769

Table 66: Logarithm transformation of the measured variable Handover attempts

min-level (0 msec)




MIX1_10Erl

-0.99 -0.99 -0.99 -0.98

MIX2_20Erl

-0.69 -0.69 -0.69 -0.68

MIX3_40Erl

-0.37 -0.37 -0.37 -0.33

MIX4_80Erl

-0.14 -0.11 -0.13 -0.11

MIX5_160Erl

-0.05 -0.05 -0.05 -0.04

Table 67: Logarithm transformation of the measured variable Uplink load

195


Rows 2,041006383 3 0.680335461 19,62286238 4,757055

Columns 0.017800402 2 0.008900201 0.256707802 5,143249

Error 0.208023309 6 0.034670552

Total 2,266830094 11

Table 68: ANOVA of Handover attempts with the multiplicative model


Rows 0.745806368 3 0.248602123 1768,122551 4,757055

Columns 0.00070624 2 0.00035312 2,511480684 5,143249

Error 0.000843614 6 0.000140602

Total 0.747356222 11

Table 69: ANOVA of Uplink load with the multiplicative model

Again, the obtained F for the levels of the parameter time to trigger is not higher than Fcrit, therefore with the multiplicative model it is not possible either to guarantee statistical significance. In the chapter 15 of [Jain] there are a list of graphical tests to determine which kind of transformation would be required, three of these tests were tried but the criteria to apply the given transformation were not fulfilled with the collected information. Therefore, due to the limitations of time and resources of this project, this verification with more transformations in order to reduce the variance of the experiment is still open. It is also suggested to perform more than one simulation per each traffic density level and then apply the ANOVA 2 factor analysis with replication, which was not possible in this project due to the limitations of time and hardware.

Therefore, to conclude the analysis of the given parameter another approach also mentioned in [Jain] is going to be used. This method is particularly useful when the goal of the experiment is simply to find the best combination of factor levels (the combination that produces the best performance). The name of the method is the Ranking method and consists to organize the experiments in the order of increasing or decreasing responses so that the experiment with the best response is first and the worst response is last. Then, the factor columns are observed to find levels that consistently produce good or bad results.


196

For this analysis, the best experiment is defined as the one with the lowest handover attempts measurement and the lowest uplink load. Therefore, we present below a table where the rows have been sorted in order of increasing number of handovers and increasing uplink load:

experiment Load time to trigger HO attempts UL Load

16 MIX1_10Erl 5000 174 10.47%

11 MIX1_10Erl 320 191 10.18%

6 MIX1_10Erl 200 191 10.20%

1 MIX1_10Erl 0 199 10.27%

17 MIX2_20Erl 5000 372 20.95%

7 MIX2_20Erl 200 403 20.44%

12 MIX2_20Erl 320 424 20.52%

13 MIX3_40Erl 320 873 42,61%

8 MIX3_40Erl 200 879 43,02%

3 MIX3_40Erl 0 1240 42,32%

19 MIX4_80Erl 5000 1658 76,90%

9 MIX4_80Erl 200 1777 77,48%

18 MIX3_40Erl 5000 1785 47,21%

2 MIX2_20Erl 0 2132 20.30%

14 MIX4_80Erl 320 2704 73,75%

20 MIX5_160Erl 5000 2770 90.28%

4 MIX4_80Erl 0 3019 72,99%

15 MIX5_160Erl 320 7202 90.02%

10 MIX5_160Erl 200 8282 89,38%

5 MIX5_160Erl 0 139329 88,61%

Table 70: Ranking method applied over the simulation outcomes

The first interesting thing that we can notice in Table 68 is that in the Load column, nearly all the experiments are ordered from the lowest load (10 Erlangs) to highest Load (160 Erlangs) including all the time to trigger levels per each traffic load level (exception made with the experiments 2, 18 an 4 that can be attributed to random errors in the simulator). Therefore the effects of the increased traffic load on the system

197

performance, measured in terms of Hand-over attempts and Uplink Load, can be seen: the highest load, the worse.

Taking a look at the second column, we can observe the pattern 5000. 320. 200 and 0 (with the 320 and 200 alternating position in some cases) in mostly all the table. Again, variations of this pattern can be attributed to experimental errors in the simulator.

Then, we can appreciate that for the same level of traffic load, the worst results in terms of Handover Attempts are with the value 0 for the Time to trigger parameter. So we clearly discard this setting as the best value among the proposed four.

Next, we take a look at the values of Handover Attempts and Uplink Load for the value 5000 of Time to Trigger: Although in some cases the number of handovers is the lowest with this setting (as in the experiment 16), the Uplink Load with this parameter, for the same traffic density, is the highest (experiment 16 and 20. for instance). Therefore, this setting has a tradeoff with the Uplink Load and it is also not the best option for the best value among the proposed 4.

Next, we start making comparison of the levels 200 and 320. In order to do this, the following table has been constructed, removing all the levels corresponding to the values 0 and 5000 of the parameter Time to Trigger:

experiment Load time to trigger HO attempts UL Load

11 MIX1_10Erl 320 191 10.18%

6 MIX1_10Erl 200 191 10.20%

7 MIX2_20Erl 200 403 20.44%

12 MIX2_20Erl 320 424 20.52%

13 MIX3_40Erl 320 873 42,61%

8 MIX3_40Erl 200 879 43,02%

9 MIX4_80Erl 200 1777 77,48%

14 MIX4_80Erl 320 2704 73,75%

15 MIX5_160Erl 320 7202 90.02%

10 MIX5_160Erl 200 8282 89,38%

Table 71: Ranking method removing the two worst options

Now we have the table ordered by Handover attempts and Uplink Load and it is also automatically ordered by Load levels, which simplifies our


198

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

Time to trigger =320 is the best

MIX 10 Erl 0 1

MIX 20 Erl 1 0

MIX 40 Erl 0 1

MIX 80 Erl 1 0

MIX 160 Erl 0 1

COUNT 2 3

Table 72: Main results for the analysis of the parameter Time to trigger 1a

Therefore, according to our assumption in the order of the outputs, the parameter 320 has better performance having into account the number of handover attempts and the Uplink Load. Of course this is an informal method that has to be combined with more simulations with different traffic densities or the same traffic densities but with different transformation in order to reduce the variance and then to be able to guarantee the results in statistical way providing the corresponding confidence intervals for the factors.

199

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 non-homogeneous scenario.


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


200

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:


hour/Km^2)

Blocking probability 1% 3868.06

Dropping probability 1% 6041.83


DL power usage 38,7 dBm 6646.23

Channel elements, UL 64 9146.39

UL Load 60% 12004.6




201


hour/Km^2)

Blocking probability 1% 5279.6000


Channel elements, UL 64 6518.6300

DL power usage 38,7 dBm 7360.59

UL Load 60% 8052.83



Channel elements, DL 256 14899.40


Comparing both tables, the main differences in order are the presence of the Dropping probability as a second element in the table of non-homogeneous scenario and the uplink channel elements utilization that appears before the downlink power usage in the homogeneous scenario.

We can think that the asymmetry of the non homogeneous scenario (compared with the perfect “cookie cutter” grid of the homogeneous one) was the reason for the difference of place of the dropping probability threshold between the two scenarios. Most of the dropping was due to blocked radio link additions.

8.6.4 Power study

As in the homogeneous scenario, the differences in active set size and polluting pilots are clearly not significant; therefore we can conclude that even in the non-homogeneous scenario, the Power Rule of both countries gives equivalent performance due to the low downlink losses (less than 4 dBs).

8.6.5 Mobility study

The difference in Downlink Power levels between both profiles (pedestrian, vehicular) is larger in the non-homogeneous case, and in overall the consumed power is lower for the pedestrian profile, as it was also theoretically expected.


202

8.6.6 Analysis of the impact of a parameter setting in the overall performance of the UTRAN

With the common approach (additive model), the ANOVA test doesn’t give statistical significance to the levels of Time to Trigger parameter for the analyzed set of experiments. Three more transformations were evaluated, however the statistical significance was not found. More transformations should be applied in order to reduce the variance and provide the corresponding confidence interval for the analyzed parameters. A result based on informal methods (applying the so-called “ranking” method described in [Jain]) is provided and the conclusion is that the 320 milliseconds setting for the Time to Trigger 1a parameter has the best performance of all the 4 tested levels, but this is something that has to be guaranteed statistically (more simulations with perhaps different traffic density settings must be tried).

203

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 Target Level No. of users to reach the

target CE UL 64 13UL Load 60% 16DL power 38.7 dBm 36Iub 1070 Kbps 37DL code tree 60% 42Blocking prob 1% 49CE DL 256 52Dropped prob 1% 62

Table 75: Ordered KPIs by number of users to reach the target, Voice-0nly service

KPI Target Level No. users to reach the target Traffic density level

UL Load 60% 3 17,46 CE UL 64 3 17.74

DL power 38.7 dBm 3 19.55 DL code tree 60% 5 27.1968

Iub 1070 Kbps 6 32 Blocking prob. 1% 6 32.19

CE DL 256 9 49.7967

Table 76: Ordered KPIs by number of users to reach the target, Video call-only service


204

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


Blocking prob.

1% 2

DL Iub 1070 Kbps 5

DL power 38.7 dBm 8

CE UL 64 8

DL throughput

(outdoor)

100 kbps 12

UL Load 60% 13

DL code tree

60% 16

CE DL 256 30


1% No dropping was

experienced

Table 77: Ordered KPIs by number of users to reach the target, Web-only service

205

KPI Target Level


Traffic Density Level

Blocking prob.

1% 1 4.1627

DL Iub 1070 Kbps

1 5.0550

DL power 38.7 dBm

1 6.7843

Dropping prob.

1% 1 8.1450

CE UL 64 2 9.83

DL code tree

60% 3 14.2658

UL Load 60% 5 30.363

CE DL 256 6 34.234

Table 78: Ordered KPIs by number of users to reach the target, FTP-only service

For the Packet Switched Services with the current threshold settings (Blocking probability level set to the same level for voice service), the Blocking Probability is the first KPI to reach the target. Theoretically, allowing a higher Blocking Probability for PS services would increase the capacity of the cell and this should be possible to implement, given the characteristics of the packet-switched transmission which doesn’t put high requirements about low delays.

After blocking probability, Downlink Power and DL Iub utilization seem to be the next most important capacity limiting factors. Downlink CE usage seems to be one of the last threshold levels to be reached. Therefore, according to the results, the capacity in Packet Switched services is mostly Downlink limited, as it was expected due to the high asymmetrical data rates in Downlink for both services.

Among the two simulated PS services, the main difference is the place of the Dropping Probability, in the Web Service no dropping probability was found with the simulated traffic loads (and therefore no estimation was possible for the load that reaches the 1% threshold); however, as it was mentioned before, this is in line with the RRM channel switching algorithms (switching from DCH to FACH), when the Web users can still keep the connection with data rates of 32 Kbps without been dropped by the system, as it happens with the FTP users that keep using mostly the


206

DCH channels. However, in order to get more realistic results, new simulations have to be performed when the simulator includes the slow start mechanism which has a direct impact in the blocking and dropping probabilities.

9.2 Service Mix analysis

Next section presents the main conclusions of the comparison between the service mix experiments in both scenarios (homogeneous and non-homogeneous). The next two tables summarize the results.


hour/Km^2)

blocking probability 1% 3868,06

Dropping probability 1% 6041,83

Iub utilization 1070 Kbps 6322,14

DL power usage 38,7 dBm 6646,23

channel elements, UL 64 9146,39

UL Load 60% 12004,6

DL code tree usage 60% 15482,6




hour/Km^2)

blocking probability 1% 5279.6000


channel elements, UL 64 6518.6300

DL power usage 38.7 dBm 7360.59

UL Load 60% 8052,83



channel elements, DL 256 14899.40


207

According to both tables, capacity in both scenarios (homogeneous, non homogeneous) is mostly Downlink Limited when all the services are working together (i.e. Downlink Power target level occurs before than the Uplink Load target level). DL Code tree usage and DL channel elements, however, seems to be the last KPI to be reached. Iub utilization seems to be also an important factor to be considered given that the assumption made of just 1 E1 link between each Node B and the RNC (Iub interface) gives this factor the 2d place (homogeneous) and 3rd place (non homogeneous) in the order of the KPIs that are reached first.

Comparing both tables, the main difference in order is the presence of the Dropping probability as a second element in the table of non-homogeneous scenario.

The main reasons for dropping, in the non homogeneous scenario, were as follows:

14: Blocked radio link addition

21: DL congestion

Especially with the highest traffic densities, those two reasons were the main ones in 41 out of the 53 cells in the analysis area.

Therefore, we can think that the asymmetry of the non homogeneous scenario (compared with the perfect “cookie cutter” grid of the homogeneous one) was the reason for the difference of place in the order of the KPIs of the dropping probability threshold between the two scenarios.

9.3 Power rule usage, homogeneous and non-homogeneous 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 non-homogeneous 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).


208

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.

209

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


210

[Exportingatolltowines] WiNeS Atoll™ Synchronization Module (ASM) version 3.2. Radioplan GmbH, Dresden, Germany, 2004. [Handoverthesis] Stijn N. P. Van Cauwenberge. Study of soft handover in UMTS (Master Thesis). Danmarks Tekniske Universitet, Denmark, July 2003. [Haverkamp-cpichstudy] Bert Haverkamp. CPICH balance study. Traffic modeling group Vodafone NL, Maastricht, The Netherlands, October 2004. [Holma] Harri Holma and Antti Toskala. WCDMA for UMTS, Radio Access for Third Generation Mobile Communications (3rd Edition). Wiley, Chichester, England, 2004. [Holmathesis] Harri Holma. A study of UMTS terrestrial radio access performance (PHd. Thesis). Helsinki University of Technology, Department of Electrical and Communications Engineering, Espoo, Finland, 2003. [ITU] Philippe Mege. Document 1-HNB-SM/50-E. Chapter 3 (frequency assignment and licensing), Addendum 1: IMT 2000/ UMTS Radio Planning Procedures. International Telecommunication Union, Radiocommunication Study Groups, Switzerland, 2003. [Iub-observability] Greg Vourekas. Iub Observability via STS Counters. Vodafone Netherlands, Maastricht, The Netherlands, 2004. [Jaber] Mona Jaber, Syed Ammar Hussain and Adel Rouz. Modified Stochastic Knapsack for UMTS capacity analysis. Fujitsu Science and Technology Journal number 38Vol 2, p. 183-191, 2002. [Jain] Raj Jain. The art of computer systems performance analysis. Techniques for experimental design, measurement, simulation, and modeling. Wiley, Massachusetts, United States, 1991. [Laiho] Jaana Laiho, Achim Wacker. Radio Network Planning Process and Methods for WCDMA. Nokia Networks, Finland, 2001 [Madder] Andreas Mäder, Dirk Staehle. Analytic Modelling of the WCDMA Downlink Capacity in Multi-Service Environments (Technical Report No. 330). University of Wurzburg, Institute of Computer Science, Wurzburg, Germany, April 2004. [Mathforinternet] Walter Willinger and Vern Paxson. Where Mathematics Meets the Internet. Notices of the American Mathematical Society Volume 45, Number 8, p. 961-970. 1998. [Moret] Alexandre Moret, Silmar Palmeira and Phil Jones. EbNt versus BLER characterisation – Results. Vodafone Group Plc Confidential, July 2004. [Ramsden] Edward Ramsden. Imitating Life: An Introduction to Computer Simulation and Modeling. Sensors Magazine Online, http://www.sensorsmag.com/articles/0502/14/, May 2002. [RRMEricsson] WiNeS Dynamic Network Simulator Module, Radio Resource Management (RRM) Algorithms Library Version 3.3 – Ericsson. Radioplan GmbH, Dresden, Germany, 2005. [Schneider-1] Peter Schneider, Determination of the UMTS Cell Capacity – Part 1. Vodafone D2, Düsseldorf, Germany, July 2004

211

[Schneider-2] Peter Schneider, Determination of the UMTS Cell Capacity – Part 2. Vodafone D2, Düsseldorf, Germany, January 2005. [Staelhe2004] Andreas Mäder and Dirk Staehle. Uplink Blocking Probabilities in Heterogenous WCDMA Networks considering Other-Cell Interference (Technical Report No. 333). University of Wurzburg, Institute of Computer Science, Wurzburg, Germany, May 2004. [Umts-forum6] UMTS/IMT-2000 Spectrum (Report number 6). UMTS Forum, London, England, 1998. [Wedontknow] Vern Paxson and Sally Floyd. Why we don’t know how to simulate the internet. Proceedings of the 1997 Winter Simulation Conference, Network Research Group, Lawrence Berkeley National Laboratory, University of California, Berkeley, U.S.A., p 1037 – 1044, 1997. [Winessnapshot] J. Deißner, J. Voigt. WiNeS Snapshot Network Simulator Module Technical Reference Version 3.3. Radioplan GmbH, Dresden, Germany, 2005. [Winestechref] WiNeS Dynamic Network Simulator Module, Technical Reference Version 3.3. Radioplan GmbH, Dresden, Germany, 2005. [Winesuserguide] J. Deißner, J. Hübner, D. Hunold, D. Stachorra, J. Voigt. User Guide for WiNeS Control Center User version 3.3. Radioplan GmbH, Dresden, Germany, 2005.

1

1. Appendix: UMTS fundamental concepts 1.1 What is UMTS?

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

From the Standards point of view, UMTS is a mobile communications system standardized by the 3GPP and the specifications are at the present time in their Release Number 6. The mobile operators that bought 3G licenses in Europe have already deployed their UMTS W-CDMA (Wideband CDMA: the chosen multiple access technology for UMTS) based networks, although the coverage is still not comparable with the currently huge, transnational coverage of GSM-GPRS networks. In fact, at least in the first years of deployment, UMTS networks are going to rely on GSM networks to reach zones where there is still no UMTS coverage, using a technique called Inter-RAT (RAT: Radio Access Technology) handovers.

About the UMTS services, some commercial services have been available for the general customers, in the concrete case of The Netherlands, since the last year.

1.2 Technical characteristics

Technically speaking, the radio-access part (also called “the air interface”) is the most important difference regarding to the so-called 2-2.5G systems (e.g. GSM, GSM+GPRS). Instead of using the FDMA-TDMA combination (i.e. carriers and timeslots per carrier) as the access technology like in GSM, UMTS uses Wideband-CDMA, a technology based on the Direct Sequence (DS) Spread Spectrum principle. Direct Sequence makes reference to the usage of a special code to separate the signals (opposite to “frequency hopping” which is the other Spread Spectrum


2

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

3

scrambling code. The usage of these codes depends on the direction of the communication (in Uplink, the transmitter is the mobile whereas in Downlink the transmitter is the Base station). The purpose of the channelization (spreading) codes in both UL and DL directions is to separate channels from a single transmitter, whereas the purpose of the scrambling codes is to separate transmitters (also applies to both UL and DL directions).

The main difference in the frequency domain between both kinds of codes is that the Scrambling codes don’t modify the bandwidth of the Information Signal, whereas the channelization codes do. As this is something very important in order to understand how UMTS works, in the next section the code usage is explained both in UL and DL.

1.3 Channelization (Spreading) codes

In UL direction (UE transmits and Node B receives), channelization codes are used to separate physical data and control (i.e. signaling) channels from the same terminal. In DL (Node B transmits, UE Receives), channelization codes are used to separate connections to different users within one cell (users of the cell are sharing the “code tree” of that cell, that is, the pool of DL code resources of the tree). Once a channelization code is applied to the information signal, the Bandwidth of the information signal changes (in frequency domain) to a higher bandwidth, in other words is “spread” over the UMTS bandwidth channel (hereby the name of “spread spectrum”).

In time domain, the effect is the change of rate of the information signal. To distinguish from the Information Rate, 3GPP calls the Rate of the channelization code as the Chip Rate, although physically the chips are also bits (although of higher frequency (smaller period) than the data or information bits). Therefore, after the channelization code is applied to the information signal, the result is a signal with a bit rate equal to the chip rate (the reference chip rate in UMTS is fixed to 3.84 Megachips / sec, and varying the number of chips per information bit we obtain different user speeds). The next figure helps to clarify the effects of the channelization code in both frequency and time domain.


4

Figure 1-2: Effects of the channelization code in Time and Frequency domain

The codes used for the channelization operations must have a special property called orthogonality. Orthogonal code means that the inner product of the code with the codes from the other users (called cross-correlation property) or the product of the code with a shifted version of the code itself (called auto-correlation) has to be as small as possible. These codes are also known as OVSF (Orthogonal Variable Spreading Factor) codes.

For orthogonality to work, the signals must be properly synchronized in time. That’s why in DL for instance, due to multi-path propagation, some of the orthogonality property is lost. This is had into account in CDMA capacity equations with the so-called orthogonality factor, which is a factor that varies between 0 (full orthogonality, no interference) and 1 (no orthogonality, full interference)*.

The number of chips used for each data bit is known as the spreading factor (SF). Also, in the frequency domain, SF = W / R, where W = Bandwidth of the spread signal [Hz] and R = Bandwidth of baseband data [Hz].

Summarizing, in Time Domain:

SF = Chip Rate / Data Rate coded channel (A1.1)

And also, in Frequency Domain:

SF = W / R (A1.2)

*: This definition is in line with the definition in Wines simulator documentation. However in some other references, for instance [Holma], 0 means no orthogonality and 1 means full orthogonality.

Where Data Rate coded channel means that this data rate has into account the overhead introduced by coding techniques and it doesn’t corresponds

Bandwidth after spreading

f t

1

-1 Voltage

Power

Bandwidth of baseband

5

directly to the information rate (unless the coding factor is 1 of course). This is important to know because it is a common source of mistakes in calculations.

If we have a low spreading factor it means that it is consuming more code resources from the code tree and the bit rate is higher, for instance with SF = 8, the data rate of the spread signal would be 480 Kbps, whereas with SF=256, the data rate of the spread signal would be 15 Kbps. Therefore, in Downlink, the number of codes (given by the maximum SF) is a scarce resource that can be in shortage and therefore must be carefully considered in any capacity analysis.

1.4 Scrambling codes

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

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

Summarizing, the following schematic illustrates in a simple way the process of transmission and reception in UMTS involving all the elements mentioned.

Spreading code

Data bits

Scrambling code

Transmission medium Σ

Recoveredbits

RX SIDE

TX SIDE

Scrambling code

Spreading code

Figure 1-3: Simplified Transmission and Reception process in UMTS


6

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).

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:

( ) ( )11

1 −=

−=

NSNSSIR (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.

Figure 1-4: Derivation of the SIR and Eb/No relationship

N users

7

( ) ( ) RW

NW

SNRS

NE rf

rf

o

B ⋅−

=−

=1

11 (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:

RW

nBitRateInformatiodBandwidthTotalSpreaG rf

p == (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:

Po

b GSIRNE

⋅= (A1.6)

In another form:

o

b

P NE

GSIR ⋅=

1 (A1.6.1)

Equation (1.6.1), when the quantities are expressed in dBs, becomes:

po

b GNESIR −= (A1.7)

The following figure summarizes graphically this physical process.


8

RF input

Rc

W= 5MHz

SpreadingCode

W

f0

Data, Rb

f 0

RF output

W= 5MHz

W

f0

Data, Rb Rc

SpreadingCode

f 0

EEcc//IIoo ++ GGpp == EEbb//NNoo,, iinn ddBB

Rx antenna

Tx antenna

Noise & interfering

signals

W

f0

EEbb//NNoo

EEcc//IIoo This is

negative!

oorr SSIIRRttaarrggeett ++ GGpp == EEbb//NNoo iinn ddBB

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:

( ) dBRRG

b

cp 251015.3log10

102.121084.3log10log10 2

3

6

=⋅⋅=⎟⎟⎠

⎞⎜⎜⎝

⎛⋅⋅

⋅=⎟⎟⎠

⎞⎜⎜⎝

⎛⋅=

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).

9

For speech service Eb/No is typically in the order of 5dB. That means that after despreading the resulting baseband signal must be 5dB above noise in order to be successfully reconstructed at the decoder. Therefore, the required wideband SIR must 5 dB minus the processing gain. This follows also from equation A1.7.

SIR“target” = 5dB-25dB = -20dB. In other words:

dBdBdB

NEGSIR obp

52520

/

=+−⇒

⇒=+

(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.

coo

c

o

c

o

c ENNE

NEdB

NE

⋅=⇒=⇒−=⎟⎟⎠

⎞⎜⎜⎝

⎛⇒−=⎟⎟

⎠

⎞⎜⎜⎝

⎛⋅ 100

1012log20log10 2

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.


10

This fact gives us the first impression of why the Interference levels in the network are so important in the radio planning process of UMTS systems, because if the interference level is high in some cells (because the interference contribution of many users sharing the air interface and probably using different data rates), then the Eb/No level of some links is not going to be enough to make their signal to “rise” above the interference level and therefore the call would be dropped (i.e. the capacity in terms of number of supported users per cell is modified) and the cell-size (coverage) would be reduced (phenomena known as “cell breathing” effect). This is the main reason why in UMTS capacity and coverage planning cannot be separated processes, as it can be done for instance in other mobile systems such as GSM where first predictions of the path loss are evaluated in order to ensure the coverage of the desired area, and then capacity is dimensioned as a second step (capacity in a GSM cell it is given by the number of available channels, which is a function of the reuse factor and the number of carriers per cell [Umts-forum6] and therefore the sensitivity level at the base stations (i.e. the minimum power level of the incoming signal at the receiver in order to be detected) can be assumed as a constant. On the contrary, in UMTS the sensitivity of the base stations is a random variable that depends on the number of users and the bit rates / services being used at any given time, then it is clear that capacity influences coverage and a separate planning of capacity and coverage cannot be performed, as the interference should be taken into account already in the coverage prediction.

1.6 UMTS Architecture (Rel99)

The following section aims to introduce shortly the network elements and interfaces of the UMTS architecture (Release 99), including UTRAN and Core Network. The Core Network however, it is presented here just for the sake of the architecture completeness but its analysis is out of the scope of this study.

11

Figure 1-6: UMTS Architecture (Rel-99)

UE (User Equipment)

The UE, as defined in [21.905] is the mobile equipment with one or several UMTS Subscriber Identity Modules (USIMs). Therefore, the UE consists of two parts, the ME which is the radio terminal itself, and the USIM which is the “smartcard”, analog to the SIM cards of the GSM phones but with some advanced extra-features (secure downloading of applications, possible inclusion of payment methods, etc).

UTRAN (UMTS Radio Access Network)

UTRAN is a logical grouping that includes one or more Radio Network Subsystem (RNS). Two of them (RNS1, RNS2) are depicted in the figure 4. A RNS is a sub-network within UTRAN and consists of one Radio Network Controller (RNC) and one or more Node Bs. For simulation purposes, only one RNS is simulated. In the following section, the main components of the RNS are explained.

Node B

The Node-B is analog in functionality to the BTS in GSM networks. Its main function is to provide the radio link between the UE and the UMTS network. It performs radio functions related to the “air interface”, which is the logical interface (known as Uu interface in 3GPP specifications) between the UE and the Node B. Higher layer functions (e.g. Medium Access Control) and control of the Node Bs is performed by the RNC. Some of its main tasks are the implementation of Radio Resource

Node B

Node B

....

Uu (air interface)

Node B

....

RNC

RNC

Iur

Iub

Iub

Iub

Iu-CS

Iu-PS

MSC/V GMSC

CS Networks (PSTN,

SGSN GGSN

PS Networks (Internet..)

PS-Domain

CS-Domain

HLR

UTRAN

CN

...

UE

Simulation Scope


12

Management algorithms such as the Fast Power Control Algorithm which is crucial to make CDMA works (keeps away the known “” in UL) and the Softer Handover (a special Handover type when the UE is connected to cells belonging to the same node B, as it is going to be explained later).

Node B’s are connected to the RNCs through the Iub interface which physically corresponds to one or more ATM links.

RNC

The RNC is the element responsible for most of the Radio Resource Management in the UTRAN (Umts Terrestrial Radio Access Network). For instance, the RNC is the element that solves the congestion situations by issuing the corresponding congestion resolve actions directed towards the congested Node B’s; also it is the key element in the Handover process; performs a special power control known as “outer loop power control” and handles admission control and code allocation for the cells served by the controlled node B’s.

When a mobile is connected to Node Bs controlled by different RNC’s, the RNC that has the active connection to the core network through the Iu-CS or Iu-PS interface is known as the Serving RNC (SRNC) and the other RNC (the one that just routes information) is known as Drift RNC (DRNC). Also, from a Node B point of view, the RNC that controls it is known as the Controller RNC (CRNC). Physically there is no difference between SRNC, DRNC and CRNC, in fact it is only one equipment that in any given moment of time can assume any of the described roles.

Two RNCs are connected through the logical Iur interface, which corresponds physically to ATM links and allows soft handover between RNCs and some other additional advanced functionality as described in [Holma].

Core Network

The core network is the “all-in-one” network that connects the mobile users of a given UTRAN with other mobile users from other companies, with fixed phones and with other Data Networks. From the technical point of view, the core network is the backbone of the mobile communication system that provides connectivity to different radio access and fixed networks. The Release 99 core network is just an evolution of the GSM backbone; although with newer releases, starting from Release 4 with the introduction of the IMS (IP Multimedia Subsystem, see [Umtsforum] for more information), and Release 5, the ideas are converging towards an all-IP core network, where the traditional signaling system (SS7) will be replaced by SIP. As the focus of the simulation is in the UTRAN part, this part of the architecture is mentioned only for reference and it is not going to be explained in further sections.

The main components of the core network (Rel-99) are:

HLR: The Home Location Register is a database that contains the master copy of the user’s service profile.

13

MSC/VLR: The Mobile Services Switching Center and Visitor Location Register are the switch (MSC) and database (VLR) serving the UE in its current location when it is using a circuit-switched service (e.g. speech).

GMSC: The Gateway MSC is a MSC which interfaces with external circuit-switched networks. From the architectural point of view it can be seen as a router that routes information between the PLMN of the UMTS network (the network of MSCs) and its external interfaces connected to other circuit-switched services (e.g. ISDN networks).

SGSN: The Serving Gateway Support Node is the counterpart of the MSC/VLR but in the packet switched domain.

GGSN: The Gateway GPRS Support Node is the counterpart of the GMSC but in the packet switched domain.

1.7 Radio Resource Management Algorithms

The Radio Resource Management functionality (RRM, in short) is a set of algorithms used for optimal utilization of the air interface (the so-called “soft” resources) and Hardware resources (also known as “hard” resources). Among them, the main RRM algorithms are:

• Admission Control • Congestion Control (Load Control) • Radio Resource Allocation and Management • Power Control • Handover Control • channel switching

The purposes of the RRM algorithms are to ensure planned coverage for each service, providing the best capacity-coverage tradeoff; to ensure required connection quality, to ensure the planned (low) blocking and to optimize the system usage in run time.

Different elements in the UMTS architecture (UE + UTRAN) execute different RRM algorithms; this is illustrated in the next graph: [Castro]


14

Figure 1-7: RRM algorithms performed by the different UE and UTRAN elements

15

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.


16

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….

17

2.2 Export of the Computation Zone and Focus Zone

The computation zone and the focus zone are not stored in the project database, so they need to be exported separately.

The computation zone (equivalent to Wines simulation area) can be exported using the menu entry:

Tools -> Computation Zone -> Save as …. Enter a file name and save the zone in *.shp format.

The focus zone (equivalent to Wines Analysis Area) can be exported using the menu entry:

Tools -> Focus Zone -> Save as…. Enter a file name and save the zone in *.shp format.

2.3 Export the path loss Data to Raster Data Files

Atoll uses a separate path loss map for each antenna. The antenna pattern is included in the path loss values.

To filter a group of Node Bs in the ATOLL Project: Go to Data -> Sites -> Filter Inside a polygon. You will have two options:

• Computation zone • Draw

The first option filters the node Bs and only the Node B’s inside the computation zone (simulation zone in wines) are taken into account.

The second option allows you to draw a polygon selecting only the nodes you want to work with.


18

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:

19

0 Default Class 1 Water

(…) 10 Coniferous Forest

2.5 Exporting background Maps with ATOLL

If you have a background map that you wish to use in an external application:

a) Click the “select area” button

b) define the area to be exported

c) Select File -> Export Image command, and save it as a geo-referenced image choosing “TIFF format” as the output format.

2.6 Exporting DEM (Digital Elevation Model) information

To export the DEM terrain map, select it in the GEO TAB, Digital Terrain Model folder, and select “save as” option, saving it as BIL file (ATOLL crashes some times when trying to generate a TIF file).

2.7 Traffic Map(s) and Environment Codes Definition

Traffic data can be represented in Atoll in different ways. For the importing process into WiNeS, two of these options are supported:

• Environment traffic maps, where each pixel is associated with an

environment, which represents a certain service mix (each environment (e.g. Urban, Sub-urban, etc) has defined a list of clutter classes and weights).

• Cell traffic maps (based on transmitters and services), where the

best server coverage area of each transmitter is associated with service-specific traffic values, which may additionally be subject to clutter-based weighting factors.


20

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]

21

section of the ASM configuration file (atollimportmodule.ini) in the following format:

EnvironmentName = CodeNumber

For the example in Fig. 1, the appropriate definition is as follows:

[EnvironmentCodes]

no data = 0

Urban = 1

Rural = 2

For the most convenient usage of the ASM in connection with Atoll environment traffic maps it is recommended to create a *.mnu file for each environment traffic map.

If Cell traffic maps are used in Atoll the traffic data should be imported to WiNeS using the traffic matrix import function based on raster layers, which is described as creating a Traffic Matrix from a Surface Plot Layer in [W-UG].

Below a simple procedure is given to create an “inhomogeneous” traffic Map with ATOLL, based on the clutter weights defined per each environment:

a) Go to Data Tab, Environments; Select for instance just one of

them (e.g. Dense Urban). Assign weights to the clutter inside, something like this:

Clutter class Weight % Indoor

Default 0 0

Suburban: <6m Garden 10 30

Suburban: <6m 10 30

Suburban: <6m Dense 10 30

Suburban: <9m Wooded 10 30

Suburban: 6-9m Garden 10 30

Suburban: 6-9m 10 30


22

Suburban: 6-9m Dense 10 30


Urban: 9-12m 15 50


Urban: 12-18m 15 50


Urban: 18-27m 15 50

Urban: 18-27m Dense 15 50

City: 27-40m Open 20 60

City: 27-40m 20 60

City: >40m 20 60

Table 2-1: Example of assigned clutter class weights

The combined weights together with the area size of each clutter class determine the final number of users per each pixel. This number of users is given by the formula:

Nk = Nclass x Wk Sk / Σ( Wj * Sj)

Where • Nk = Number of users in the k clutter • Nclass = Number of users in an environment class

(defined in the “environments” Tab). • Wk = k clutter weight at a fixed surface (value

assigned for each Environment) • Sk = k clutter surface.

For more information, consult ATOLL user guide section VIII.5.2.e.v, page 287.

b) In the GEO Tab, select UMTS Traffic, right click and then

select “new map”. Afterwards select “map based on environments (raster)” option.

c) Now you have a box open. Replace the entry “no data” of the list with the environment that you defined (in this case, “Dense Urban”).

d) Select the “draw polygon” tool. Use this tool to draw the polygon where this traffic map is going to be created (usually we can take the same simulation area). When finish press double click.

23

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.


24

References: [ATOLL] ATOLL: Technical Reference Guide, Version 2.1.3, Forsk, 2004. [WINESUSERMANUAL] J. Deißner, J. Hübner, D. Hunold, D. Stachorra, J. Voigt. User Guide for WiNeS Control Center User version 3.3. Radioplan GmbH, Dresden, Germany, 2005.

Thesis Hurtado

Documents

Transcript of Thesis Hurtado