contract number: ist-2000-28088ist-2000-28088-momentum-d53-pub momentum public 2/71 document history...

Contract Number: IST-2000-28088

Project Title: Models and Simulations for Network Planning and Control of UMTS

Project Acronym: MOMENTUM

n

Information Report Number: IST-2000-28088-MOMENTUM-D53-PUB Date of Delivery: 2003-12-09 Report Title: Deliverable D5.3:

Evaluation of Reference and Public Scenarios Editor: Pedro Lourenço (Vodafone Telecel)

Erik Fledderus (TNO) Authors: Erik Fledderus (TNO)

Hans-Florian Geerdes (ZIB) Eugen Lamers (UB) Pedro Lourenço (Vodafone Telecel) Ellen Meijerink (TNO) Ulrich Türke (Siemens) Stefan Verwijmeren (TNO)

Reviewers: Thomas Kürner (TU-BS)

Workpackage leaders Abstract: This document contains a wrap-up and comparison of the evaluation results as produced by the different simulation methods developed within MOMENTUM. The individual results have in most cases been described in detail in the various deliverables of the corresponding work packages. Key word list: Evaluation of Reference Scenarios Key Action: IV, Essential Technologies and Infrastructures Action Line: IV 4.1, Simulation & Visualisation Confidentiality: MOMENTUM Public

IST-2000-28088-MOMENTUM-D53-PUB MOMENTUM PUBLIC

2/71

Document History

Date Version Comment Editor

2003-08-01

1 Initial draft version PL (Vodafone)

2003-08-12

2 Framework for chapter 4 added, after “draft” meeting in Berlin

EF (TNO)

2003-10-12

3 Inclusion of results of different work packages; ready for first review by Thomas Kürner

EF (TNO)

2003-10-22

4 Inclusion of first round of comments on a complete draft; ready for review by authors

EF (TNO)

2003-10-24

5 Inclusion of second round of comments and comments from some Thomas Winter; ready for final review by external reviewers, Thomas Kürner and work package leaders

EF (TNO)

2003-12-09

6 Final EF (TNO)


3/71

Contents

Contents 3

List of Figures 5

List of Tables 8

List of Notation 9

1 Introduction 11

2 Scenarios 13

2.1 Initial Scenarios............................................................................ 13

2.2 Evaluated Scenarios..................................................................... 16

3 Scenarios Evaluation Method 20

3.1 Optimisation Process ................................................................... 20

3.2 Evaluation Process and performance indicators ...................... 22 3.2.1 Advanced Static and Short Term Dynamic simulator....................... 22

Delay .............................................................................................................. 23 Soft handover ............................................................................................................. 23 Minimum path loss plot ............................................................................................. 23 Best server area plot ................................................................................................... 23

3.2.2 Dynamic simulator ............................................................................ 23 Delay .............................................................................................................. 24 Throughput .............................................................................................................. 24 Soft handover ............................................................................................................. 25

3.2.3 Optimiser........................................................................................... 25 Soft handover ............................................................................................................. 25 Minimum path loss plot ............................................................................................. 25 Antenna admissible directions ................................................................................... 26 Network Cost.............................................................................................................. 26

3.2.4 Global Performance Indicator ........................................................... 26

4 Scenarios Evaluation 27


4/71

4.1 Berlin Reference Scenario........................................................... 27

4.2 Berlin Public Scenario ................................................................. 35

4.3 The Hague Public Scenario ......................................................... 42

4.4 Lisboa Public Scenario ................................................................ 55

5 Lessons Learned, Conclusions 64

References 66

A Global Performance Indicator 67

B Sanity Check Scenario 69

B.1 MoDySim versus analytical calculations ................................... 69

B.2 Results ........................................................................................... 70 B.1.1 SC[1/omni_UL/PS_static]................................................................. 70 B.1.2 SC[1/omni_DL/PS_static]................................................................. 71


5/71

List of Figures

Figure 2-1: Directory and XML file structure for Lisboa Public Scenario. ................. 18 Figure 2-2: Directory and shared XML file structure. XML files common to all

MOMENTUM operators scenarios. ..................................................................... 19 Figure 3-1: Reference Scenario and optimisation data flow......................................... 21 Figure 4-1: Minimum path loss map for the Berlin reference scenario........................ 27 Figure 4-2: (a) Admissible directions for the Berlin reference scenario. The square

indicates the sub area Alexanderplatz. This area is highlighted again in (b), using an aerographical image. ........................................................................................ 28

Figure 4-3: (a) UL load per BSA for Berlin – Reference, WP4. (b) UL load per BSA for Berlin – Reference, WP2 (advanced static). Note the different scaling for (a) and (b).................................................................................................................... 29

Figure 4-4: (a) DL load per BSA for Berlin – Reference, WP4; (b) DL load per BSA for Berlin – Reference, WP2 (advanced static). Note the different scaling for (a) and (b).................................................................................................................... 29

Figure 4-5: Load histogram for the Berlin – Reference scenario, based on the advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink). ............. 30

Figure 4-6: (a) SHO situation for Berlin – Reference, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 33% of the users are in soft handover, versus 10% in softer handover. ................................................ 31

Figure 4-7: Total downlink blocking for Berlin – Reference, WP2 (advanced static); the results are per pixel. ........................................................................................ 32

Figure 4-8: The throughput histograms for email (a), file download (b), location based (c), and browsing (d) traffic, based on the advanced static simulations. The resulting average data rates are: email – 91 kbps; file download – 129 kbps; location based – 91 kbps; WWW – 322 kbps....................................................... 33

Figure 4-9: Delay histograms from the WP2-STD simulator for Berlin – Reference – Alexanderplatz. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic. ..................................................................................... 34

Figure 4-10: Minimum Path Loss Map for Berlin – Public. ......................................... 35 Figure 4-11: Admissible directions for Berlin – Public. ............................................... 36 Figure 4-12: (a) UL load per BSA for Berlin – Public, WP4. (b) UL load per BSA for

Berlin – Public, WP2 (advanced static)................................................................ 37 Figure 4-13: (a) DL load per BSA for Berlin – Public, WP4; (b) DL load per BSA for

Berlin – Public, WP2 (advanced static)................................................................ 37 Figure 4-14: Load histogram for the Berlin – Reference scenario, based on the

advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink).38

Figure 4-15: (a) SHO situation for Berlin – Public, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 31% of the area is in soft handover, versus 7% in softer handover........................................................ 39


6/71

Figure 4-16: Total downlink blocking for Berlin – Public, WP2 (advanced static); the results are per pixel. .............................................................................................. 40


Figure 4-18: Delay histograms from the WP2-STD simulator for Berlin – Public. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic. 42

Figure 4-19: Minimum Path Loss Map for The Hague – Public. ................................. 43 Figure 4-20: Admissible directions for The Hague – Public, WP4. The circled sites

constitute the optimal network as simulated by the dynamic simulator. ............. 43 Figure 4-21: (a) UL load per BSA for The Hague – Public, WP4, based on the initial

set of potential sites. (b) UL load per BSA for The Hague – Public, WP4, based on an optimal selection of potential sites. (c) UL load per BSA for Berlin – Public, WP2 (advanced static), based on the initial set of potential sites. (d) UL load per BSA for The Hague – Public, WP3, based on an optimal selection of potential sites......................................................................................................... 45

Figure 4-22: (a) DL load per BSA for The Hague – Public, WP4, based on the initial set of potential sites. (b) DL load per BSA for The Hague – Public, WP4, based on an optimal selection of potential sites. (c) DL load per BSA for Berlin – Public, WP2 (advanced static), based on the initial set of potential sites. (d) DL load per BSA for The Hague – Public, WP3, based on an optimal selection of potential sites......................................................................................................... 46

Figure 4-23: Load histogram for the The Hague – Reference scenario, based on the advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink).47

Figure 4-24: Path Loss Deficiency Map for The Hague – Public ((a) – original network, (c) – optimised network) and traffic map, WP4. While in the original network configuration the coverage is distributed regularly (a), the optimised network sets some accents (c). Comparison with the traffic map (b) shows that coverage (and capacity) is focused on the high traffic areas. The automatic planning process thus manages to save a great deal of infrastructure cost by concentrating on the hot spots. ............................................................................. 47

Figure 4-25: (a) SHO situation for The Hague – Public, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 70% of the area is in soft handover, versus 10% in softer handover...................................................... 48

Figure 4-26: (a) Total DL blocking for voice for The Hague – Public, WP2 (advanced static), per pixel. (b) DL blocking for voice The Hague – Public, WP3 (optimised scenario), per cell. ................................................................................................. 49

Figure 4-27: Main performance indicators, The Hague – Public, non-optimised........ 50 Figure 4-28: Key performance indicators for The Hague – Public, optimized. ........... 51 Figure 4-29: The throughput histograms for email (a), file download (b), location

based (c), and browsing (d) traffic, based on the advanced static simulations. The resulting average data rates are: email – 127 kbps; file download – 376 kbps; location based – 126 kbps; WWW – 379 kbps .................................................... 52

Figure 4-30: Average throughput for circuit and packet switched services, (a) The Hague – Public and (b) The Hague – Public, optimised. ..................................... 53

Figure 4-31: Delay histograms from the WP2-STD simulator for The Hague – Public. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic. .................................................................................................................... 55


7/71

Figure 4-32: Minimum Path Loss Map for Lisbon – Public......................................... 56 Figure 4-33: Admissible directions for Lisbon – Public............................................... 57 Figure 4-34: (a) UL load per BSA for Lisbon – Public, WP4. (b) UL load per BSA for

Lisbon – Public, WP2 (advanced static)............................................................... 58 Figure 4-35: (a) DL load per BSA for Lisbon – Public, WP4; (b) DL load per BSA for

Lisbon – Public, WP2 (advanced static)............................................................... 58 Figure 4-36: Load histogram for the Berlin – Reference scenario, based on the

advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink).59

Figure 4-37: (a) SHO situation for Lisbon – Public, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 27% of the area is in soft handover, versus 7.5% in softer handover..................................................... 60

Figure 4-38: Total DL blocking for Lisbon – Public, WP2 (advanced static); the results are per pixel. .......................................................................................................... 61


Figure 4-40: Delay histograms from the WP2-STD simulator for Lisbon – Public. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic. 63


8/71

List of Tables

Table 2-1: List of Scenarios created for the MOMENTUM investigations and analyses14 Table 2-2: List of MOMENTUM evaluated sites. ........................................................ 17 Table 3-1: Variables for network configuration optimisation handled by the optimiser

tool. ........................................................................................................................ 22 Table 4-1: Bearer assignment in the advanced static simulator for the packet switched

services. ................................................................................................................. 32 Table 4-2: Bearer assignment probabilities, based on a “best guess”, and used for

producing the load grids........................................................................................ 34 Table 4-3: Dropping of calls, for The Hague – Public, non-optimised. ....................... 54 Table 4-4: Dropping of calls, for The Hague – Public, optimised................................ 54 Table B-1: Load factors for a different number of users .............................................. 70


9/71

List of Notation

3G 3rd Generation 3GPP 3rd Generation Partnership Project Asy Asymmetric B Back direction BCCH Broadcast Control Channel BER Bit Error Rate BHCA Busy Hour Call Attempt Bid Bi-directional BSA Best Server Area CAC Call Admission Control

CBD Central Business District CE Channel Elements

COST European Co-Operation in the Field of Scientific and Technical Research

CPICH Common Pilot Channel

CRC Cyclic Redundancy Check CS Circuit Switched DL Downlink DSCH Downlink Shared Channel DCH Dedicated Channel EDGE Enhanced Data rates for GSM Evolution ETSI European Telecommunications Standards Institute FACH Forward Access Channel

FER Frame Erasure Ratio GPRS General Packet Radio Service GSM Global System for Mobile Communications IST Information Society Technologies ITU International Telecommunications Union LBS Location Based Service

MMS Multimedia Messaging Service MHA Mast Head Amplifier

MoDySim MOMENTUM Dynamic Simulator

MOMENTUM Models and Simulations for Network Planning and Control of UMTS MS Mobile Station NRT Non-Real Time NTB Non-Time Based


10/71

O-M One to Many parties O-O One to One party PA Power Amplifier

PDF Probability Density Function P-CCPCH Primary Common Control Physical Channel

PC Power Control PCH Paging Channel PICH Page Indication Channel PRACH Primary Random Access Channel PS Packet Switched QoS Quality-of-Service OTSR Omni Transmit-Sector Receive RNC Radio Network Controller RT Real Time RX Receive SF Spreading Factor SOHO Small Office/Home Office SHO Soft Handover

S-CCPCH Secondary Common Control Physical Channel

SCH Synchronization Channel SIR Signal-to-Interference Ratio STD Short-Term Dynamic Sym Symmetric TB Time Based Tx Transmit

UL Uplink UMTS Universal Mobile Telecommunications System Uni Unidirectional WAP Wireless Access Protocol WP Work package WP1 Work package 1 - Traffic Estimation & Service Characterisation WP2 Work package 2 - Traffic Modelling and Simulations for Interference

Estimation WP3 Work package 3- Dynamic Simulations for Radio Resource

Management WP4 Work package 4 - Automatic Planning of Large-Scale Radio

Networks WP5 Work package 5 - Assessment and Evaluation WWW World Wide Web XML eXtensible Markup Language


11/71

1 Introduction

This document is the final deliverable of the Momentum project. The project has considered the main phases of the design process of UMTS radio networks, and developed new and improved existing ways of evaluation these networks. The first phase considered the creation of correct and realistic input. This has been the topic of WP1 and the first deliverables of WP5; input is not only traffic demand and service characteristics but all parameters that constitute a UMTS network. Deliverable 5.2 [2] and its appendix [3] are proud results of that, but it has taken the consortium considerable effort to bring together all the data in a uniform format that is easy to exchange between work packages, and between work packages and project external tools. One of the conclusions is that generally, most scenarios were infeasible in the sense that the offered load was far too high. The load analysis indicated this, and this was backed by simulation results. In general, a downscaling of the traffic is possible, but this may lead to inconsistencies in the traffic profile. It may be much better to include more potential sites to the initial network, as is shown in the The Hague scenario. This scenario is based on the same assumptions regarding generated traffic per customer, but contains a large number of randomly scattered potential sites. The second phase considered the optimisation and evaluation methodologies. The Momentum project considers a large range of temporal resolutions, from time slot to long term. Each methodology has its strong points, and is used to study specific aspects of the performance of the network. One of the main goals of Momentum was to start bringing harmony in all the different approaches, to incorporate fine-scale effects in a coarse approach. The project has reached in this respect successes, but left enough clearly marked challenges for future projects. This lead to the third and final phase, where the different simulation methods, developed in WP2, WP3 and WP4 were applied to the same large-scale, realistic scenarios. It turned out that these scenarios are real challenges for dynamic simulators, whether they are called short-term dynamic or full-dynamic. To obtain reliable results on pixel level, extremely long simulation times are required for the large scenarios under consideration, whereas the runs for the dynamic simulator were limited to 48 hours on a parallel computing platform. In addition, the number of parameters that needs to be checked on consistency is very large, so when finalizing the scenarios, that are published on the Momentum web-site, there was limited time available to run all scenarios. A selection of the original 50 scenarios was made, and for the dynamic simulator it was only the The Hague public scenario that provided reliable results in reasonable time. In all cases, initial results deceived the consortium, challenging their understanding of the behaviour of UMTS. Operators that currently rollout and test the first UMTS networks will recognize this. This shows immediately the potential benefit of these types of dynamic simulators: a team of engineers can safely learn and play around with the different settings before trialing the real system. The methodologies developed


12/71

within the Momentum project will bring momentum into your understanding and design of the UMTS radio network. The heart of the document is Chapter 4, where the 4 scenarios are treated and results are compared. Chapter 3 explains in detail the performance indicators that are used for this comparison, whereas Chapter 2 recalls the basics of deliverable D5.2. Finally, Chapter 5 concludes with the main lessons that the Momentum consortium has learned and want to share with you, the reader of this document.


13/71

2 Scenarios

2.1 Initial Scenarios

Scenarios are used in MOMENTUM [1] to illustrate the planning and optimisation of UMTS radio networks as developed within the project, to show the capabilities of the developed simulators, and to formulate design recommendations. To that end, the MOMENTUM consortium developed scenarios that contain highly realistic information on all aspects of wireless networks: applications and services, propagation modelling, user behaviour, and terminal and network technology. Based on the choices of the consortium, [2] proposes a list of scenarios for evaluation and optimisation. In addition, the methodology and assumptions used to build-up the scenarios are extensively described. The network configuration considered in [2] represents the initial input to the evaluation/optimisation process. Three type of scenarios were created: • The Sanity Check Scenarios are small and very basic network configurations,

and were created for software and methodology debugging purposes, to compare and tune the output of the simulators.

• The Reference Scenarios are initial configurations reflecting the experience of the operators in GSM networks and also the availability of GSM sites that could accommodate the implementation of UMTS equipment. These scenarios are medium to large size and were also selected because of the challenge they create to the simulators.

• The Public Scenarios are basically small sized Reference Scenarios. These scenarios are available for the purpose of general public benchmarking.

The scenarios list proposed in [2] was created according to the environment and configuration characteristics, and should be seen as a scenario library of possible scenarios to be tested. The full detailed description of the scenarios can be found in [2]. The complete list with scenarios is presented in Table 2-1, and follows the naming proposed in [2]. The naming of scenarios was created to give a simplified “flash” of what is included in the network configuration.

XXX_TT[CCC_S..S_R..R]

where:

XXX Operator reference scenario, e.g. TEL (Vodafone Telecel); EPL (E-Plus); KPN (KPN/TNO); Mom (for MOMENTUM Sanity Check Scenarios)

TT Type of Scenario, e.g. SC (Sanity Check); RS (Reference Scenario); PS (Public Scenario)


14/71

CCC City where the scenario has been developed, e.g. Lis (Lisboa); Por (Porto); Ber (Berlin); Kar (Karlsruhe); Han (Hannover); Hag (The Hague); Bil (Bilthoven); Mom (for Sanity Check Scenarios)

S..S Number of sites in the scenario

R..R Type of traffic scenario, e.g. common, low, medium, high, 2005, 2012, etc.

Table 2-1: List of Scenarios created for the MOMENTUM investigations and analyses

Nr Name Data Included Sanity Check Scenarios

1 Mom_SC[1/omni_voice_static] ED[Sanity]+ND[1site/1cell]+TD[Voice_No_Mob]+PCD[Sanity]

2 Mom_SC[1/omni_UL/PS_static] ED[Sanity]+ND[1site/1cell]+TD[UL_PS_No_Mob]+PCD[Sanity]

3 Mom_SC[1/omni_DL/PS_static] ED[Sanity]+ND[1site/1cell]+TD[DL_PS_No_Mob]+PCD[Sanity]

4 Mom_SC[1/3_voice_static] ED[Sanity]+ND[1site/3cells]+TD[Voice_No_Mob]+PCD[Sanity]

5 Mom_SC[1/3_UL/PS_static] ED[Sanity]+ND[1site/3cells]+TD[UL_PS_No_Mob]+PCD[Sanity]

6 Mom_SC[1/3_DL/PS_static] ED[Sanity]+ND[1site/3cells]+TD[DL_PS_No_Mob]+PCD[Sanity]

7 Mom_SC[7/omni_voice_static] ED[Sanity]+ND[7sites/7cells]+TD[Voice_No_Mob]+PCD[Sanity]

8 Mom_SC[7/omni_UL/PS_static] ED[Sanity]+ND[7sites/7cells]+TD[UL_PS_No_Mob]+PCD[Sanity]

9 Mom_SC[7/omni_DL/PS_static] ED[Sanity]+ND[7sites/7cells]+TD[DL_PS_No_Mob]+PCD[Sanity]

10 Mom_SC[1/3_voice_mob] ED[Sanity]+ND[1site/3cells]+TD[Voice_Low_Mob]+PCD[Sanity]

11 Mom_SC[1/3_UL/PS_mob] ED[Sanity]+ND[1site/3cells]+TD[UL_PS_Low_Mob]+PCD[Sanity]

12 Mom_SC[1/3_DL/PS_mob] ED[Sanity]+ND[1site/3cells]+TD[DL_PS_Low_Mob]+PCD[Sanity]

13 Mom_SC[7/21_voice_static] ED[Sanity]+ND[7sites/21cells]+TD[Voice_No_Mob]+PCD[Sanity]

14 Mom_SC[7/21_voice_mob] ED[Sanity]+ND[7sites/21cells]+TD[Voice_Low_Mob]+PCD[Sanity]

Reference Scenarios 15 TEL_RS[Lis_395sites_comm] EV[Lisboa]+

ND[Lis_395_co2G+new3G]+TD[Lis1]+PCD[Lis]

16 TEL_RS[Lis_395sites_low traffic]

EV[Lisboa]+ ND[Lis_395_co2G+new3G]+TD[Lis2]+PCD[

Lis] 17 TEL_RS[Lis_395sites_high

traffic] EV[Lisboa]+

ND[Lis_395_co2G+new3G]+TD[Lis3]+PCD[


15/71

Lis] 18 TEL_RS[Por_182sites_comm] EV[Porto]+

ND[Por_182_co2G+new3G]+TD[Por1]+PCD[Por]

19 TEL_RS[Por_182sites_high traffic]

EV[Porto]+ ND[Por_182_co2G+new3G]+TD[Por2]+PCD

[Por] 20 EPL_RS[Karl_214sites_comm] EV[Karlsruhe]+

ND[Karl_214_co2G+new3G]+ TD[Karl_comm] + PCD[Karl_Macro]

21 EPL_RS[Karl_214sites_low] EV[Karlsruhe]+ ND[Karl_214_co2G+new3G]+ TD[Karl_low]

+ PCD[Karl_Macro] 22 EPL_RS[Karl_214sites_medium] EV[Karlsruhe]+

ND[Karl_214_co2G+new3G]+ TD[Karl_med] + PCD[Karl_Macro]

23 EPL_RS[Karl_214sites_high] EV[Karlsruhe]+ ND[Karl_214_co2G+new3G]+ TD[Karl_high]

+ PCD[Karl_Macro] 24 EPL_RS[Ber_84sites_comm] EV[Berlin] + ND[Ber_84_Mic&mac] +

TD[Ber_comm] + PCD[Ber_Macro] 25 EPL_RS[Ber_84sites_low] EV[Berlin] + ND[Ber_84_Mic&mac] +

TD[Ber_low] + PCD[Ber_Macro] 26 EPL_RS[Ber_84sites_medium] EV[Berlin] + ND[Ber_84_Mic&mac] +

TD[Ber_med] + PCD[Ber_Macro] 27 EPL_RS[Ber_84sites_high] EV[Berlin] + ND[Ber_84_Mic&mac] +

TD[Ber_high] + PCD[Ber_Macro] 28 EPL_RS[Ber_77sites_comm] EV[Berlin] +ND[Ber_77_mac]+

TD[Ber_comm] + PCD[Ber_Macro] 29 EPL_RS[Ber_77sites_low] EV[Berlin] + ND[Ber_77_mac]+

TD[Ber_low] + PCD[Ber_Macro] 30 EPL_RS[Ber_77sites_medium] EV[Berlin] + ND[Ber_77_mac]+

TD[Ber_med] + PCD[Ber_Macro] 31 EPL_RS[Ber_77sites_high] EV[Berlin] + ND[Ber_77_mac]+

TD[Ber_high] + PCD[Ber_Macro] 32 EPL_RS[Han_39sites_comm] EV[Hannover_HighRes] +

ND[Han_39_In&out] + TD[Han_comm] + PCD[Han _Macro]

33 EPL_RS[Han_39sites_low] EV[Hannover_HighRes] + ND[Han_39_In&out] + TD[Han_low] +

PCD[Han _Macro] 34 EPL_RS[Han _39sites_medium] EV[Hannover_HighRes] +

ND[Han_39_In&out] + TD[Han_med] + PCD[Han _Macro]

35 EPL_RS[Han _39sites_high] EV[Hannover_HighRes] + ND[Han_39_In&out] + TD[Han_high] +

PCD[Han_Macro] 36 EPL_RS[Han_26sites_comm] EV[Hannover_HighRes] + ND[Han_26_In] +


16/71

TD[Han_comm] + PCD[Han _Micro] 37 EPL_RS[Han_26sites_low] EV[Hannover_HighRes] + ND[Han_26_In] +

TD[Han_low] + PCD[Han _Micro] 38 EPL_RS[Han _26sites_medium] EV[Hannover_HighRes] + ND[Han_26_In] +

TD[Han_med] + PCD[Han _Micro] 39 EPL_RS[Han _26sites_high] EV[Hannover_HighRes] + ND[Han_26_In] +

TD[Han_high] + PCD[Han_Micro] 40 KPN_RS[Hag_194GSM/3_3year

MixTraff] EV[The Hague] + ND[Hag_GSMonly_3sec] +

TD[Hag_norm_3year] + PCD[Hag] 41 KPN_RS[Hag_194GSM/3_3year

SpeechTraff] EV[The Hague] + ND[Hag_GSMonly_3sec] +

TD[Hag_speech_3year] + PCD[Hag] 42 KPN_RS[Hag_600/3_3yearMixT

raff] EV[The Hague] + ND[Hag_ALLpot_3sec]+

TD[Hag_norm_3year] + PCD[Hag] 43 KPN_RS[Hag_600/3_3yearMMT


TD[Hag_MM_3year] + PCD[Hag] 44 KPN_RS[Hag_OPT/3_8yearMix

Traff] EV[The Hague] + ND[Hag_OPTphase1_3sec]

+ TD[Hag_norm_8year] + PCD[Hag] 45 KPN_RS[Hag_600/3_8yearMixT


TD[Hag_norm_8year] + PCD[Hag] 46 KPN_RS[Hag_600/6_8yearMixT


TD[Hag_norm_8year] + PCD[Hag] 47 KPN_RS[Bilt_600/3_8yearMixT

raff] EV[Bilthoven] + ND[Bilt_ALLpot_3sec] +

TD[Bilt_norm_8year] + PCD[Bilt] Public Scenarios

48 TEL_PS[Lis_52sites_comm] EV[Lisboa]+ ND[Lis_Pub52_co2G+new3G]+ TD[Lis_Pub] + PCD[Lis_Pub]

49 EPL_PS[Ber_50sites_comm] EV[Berlin]+ ND[Ber_Pub50_co2G+new3G]+ TD[Ber_Pub] + PCD[Ber_Pub]

50 KPN_PS[Hag_76sites_comm] EV[The Hague] + ND[Hag_ALLpot_3sec] TD[Hag_Pub] + PCD[Hag_Pub]

2.2 Evaluated Scenarios

An important reason for having as many scenarios as listed in Table 2-1 is to be able to evaluate a number of rollout and deployment strategies. For example, one could imagine a “roll-out” network, based on an initial forecast of the market size, and investigate the robustness of this network by projecting the network over time to “5 years after roll-out”. We need then to adjust the traffic load accordingly, and find out • how the initial network needs to be expanded to carry the increased traffic • whether the original network that was rolled out is “future proof”, i.e., whether

or not the initial sites retain there usefulness in an expanded market. Similarly, the long list of sanity check scenarios was expected to play a significant role in aligning the simulation methods developed in WP2 (Monte Carlo-like) and WP3 (dynamic).


17/71

The job of getting the data for scenarios of Table 2-1 in the same MOMENTUM XML format turned out to be a more complex task than initially forecasted. This process requests a fine-tuning and integration of the tools developed and delayed the completion of the scenarios. In the time that was left only a fraction of the scenarios could be evaluated; nevertheless, the results described in this final deliverable are considered to be sufficient to show the new techniques and models developed within MOMENTUM. The scenarios used for MOMENTUM evaluation techniques are presented in Table 2-2 and linked to the XML name. The Sanity Check scenarios are not written in XML since they are quite simple and they were created before the completion of the XML structure. Table 2-2: List of MOMENTUM evaluated sites.

Nr Name XML Data Structure Sanity Check Scenarios

1 Mom_SC[1/omni_voice_static] Not available 2 Mom_SC[1/omni_UL/PS_static] Not available 3 Mom_SC[1/omni_DL/PS_static] Not available

Reference Scenarios 24 EPL_RS[Ber_84sites_comm] BER_REF

Public Scenarios 48 TEL_PS[Lis_52sites_comm] LIS_PUB 49 EPL_PS[Ber_50sites_comm] BER_PUB 50 KPN_PS[Hag_76sites_comm] HAG_PUB

As an example and for understanding the XML directory structure, the contents of the Lisboa Public Scenario is presented in Figure 2-1. The XML files and linked structure are described in detailed in [2] and in [3], and can be retrieved from the public web site [1].

Figure 2-2 presents the directory structure of the XML shared files. These files are not dependent on the operator scenario and are used (called) by all the operator reference scenarios.


18/71

LIS_PUB

LIS_PUB_anchor.XML

traffic

LIS_PUB_antennaLocations.XMLLIS_PUB_ClutterType.XMLLIS_PUB_Environment.XMLLIS_PUB_GrounHeight.XMLLIS_PUB_OperationalEnvironment.XMLLIS_PUB_Sites.XML

environment

network

LIS_PUB_NET1.XML

equipment antenna-diagrams

antenn.XMLK742265_0.msiK742265_1.msiK742265_2.msiK742265_3.msiK742265_4.msiK742265_5.msiK742265_6.msi

LIS_PUB_mobility_mainroad.XMLLIS_PUB_mobility_pedestrian.XMLLIS_PUB_mobility_railway.XMLLIS_PUB_mobility_street.XML

predictions

min

max

pref

mobility

VFT_LIS_485990_4284308_Isopred.XMLVFT_LIS_486049_4284764_Isopred.XML.........



NET1_predictions

3G1000_1_pred.XML3G1000_2_pred.XML3G1000_3_pred.XML3G1058_1_pred.XML3G1058_2_pred.XML............

al

bhca

TgCommLIS_PUB_AL_EMail.XMLLIS_PUB_AL_FileDownload.XMLLIS_PUB_AL_LBS.XMLLIS_PUB_AL_MMS.XMLLIS_PUB_AL_SpeechTelephony.XMLLIS_PUB_AL_StreamingMultiMedia.XMLLIS_PUB_AL_VideoTelephony.XMLLIS_PUB_AL_WWW.XML

TgCommLIS_PUB_BHCA_EMail.XMLLIS_PUB_BHCA_FileDownload.XMLLIS_PUB_BHCA_LBS.XMLLIS_PUB_BHCA_MMS.XMLLIS_PUB_BHCA_SpeechTelephony.XMLLIS_PUB_BHCA_StreamingMultiMedia.XMLLIS_PUB_BHCA_VideoTelephony.XMLLIS_PUB_BHCA_WWW.XML

Figure 2-1: Directory and XML file structure for Lisboa Public Scenario.


19/71

Shared Filesenvironment

Offsets.XML

equipment

antenn.XMLBearers.XMLNodeB.XML

UserEquipment.XML

antenna-diagramsK742265_0.msiK742265_1.msiK742265_2.msiK742265_3.msiK742265_4.msiK742265_5.msiK742265_6.msiK742212_0.msiiK742212_0.msii........

network

PlanningGuidelines.XML

Services

services.XMLSourceModels.XML

Figure 2-2: Directory and shared XML file structure. XML files common to all MOMENTUM operators scenarios.


20/71

3 Scenarios Evaluation Method

The selected scenarios in Table 2-2 correspond to an initial network configuration, or a set of possible network locations. This set consists of different types of locations: locations that are already occupied by a 2G site and that are suited for co-location, locations where competitors offer site-sharing, and "fresh" locations. In general, given the traffic load foreseen for the area under stay, the operator may be allowed to change the physical network configuration, corresponding to selecting particular sites and configurations. Any change, corresponding to selecting a subset of the original set of potential locations, should meet a few targets: it should be able to accommodates the traffic load in that region, and comply to the quality targets. In this way, specific questions can be answered, e.g. related to the necessity to participate in a site-sharing construction. Given the quality and load constraints, the operator tries to minimize network deployment cost. When using the different simulators and the optimizer in an operational environment, one might proceed as follows. • The first step is the optimization process, targeting the main network

parameters. This phase aims at finding out whether or not the initial network configuration is able to accommodate the offered traffic. When this is the case, the optimizer tries to obtain a design that contains fewer sites or, more generically, that is less expensive. This will lead to a small (~ 4) number of good candidate networks.

• These candidate networks are used in the second step: the evaluation process. One can use the Monte Carlo simulator or the Short-Term Dynamic Simulator, developed in WP2, which calculates a number of network Key Performance indicators.

• The Dynamic Simulator (MoDySim) is used to even further optimise the network. It is best to use the simulator to fine-tune specific problematic areas, or to use the simulator in advance to produce a set of default parameter settings.

This chapter is focused on the definition of the methodology for the optimization and evaluation process, defines the services quality targets and identifies which are the network variables that could be tuned in order to accomplish the targets.

3.1 Optimisation Process

The optimisation process can start when an initial scenario is supplied and described in XML format (Figure 2-1 and Figure 2-2), that is, the lower stage of Figure 3-1 is completed. This lower part shows a number of contributions from the various work packages.


21/71

The goal of the optimiser tool (in the automatic network planning process) is to obtain a close-to-optimal network, while minimising the deployment costs, and serving the traffic demand provided in the traffic grids. In the next stage the optimized scenario is given as input to the simulators in order to be evaluated. In [4] the internal processes of the optimiser are described in more detail. The current report is focused on the process chain that leads to the evaluation of the scenarios and not to the detailed internal functions and processes of each simulator and optimiser.

WP5

Environmental and Network Data

WP1 WP2 WP4

Traffic Grids Mobility Grids Propagation GridsCreation of the initial scenarios

initialScenario

XML format

WP5


WP1 WP2 WP4


initialScenario

WP5


WP1 WP2 WP4


initialScenario

initialScenario

XML format

WP3Dynamic Simul

WP2Monte Carlo Snap Shot

WP2Short Term Dyna Simu

Evaluation Process

WP3Dynamic Simul



WP3Dynamic Simul



Evaluation Process

Time Increasing Simulation AnalysesTime Increasing Simulation Analyses

OptimalScenario

WP4Optimiser

Optimisation Process

OptimalScenarioOptimalScenario

WP4Optimiser

Optimisation Process

Performance Indicators

Figure 3-1: Reference Scenario and optimisation data flow.

According to the goal of the optimiser, the initial input scenarios contain many potential network designs, consisting of potential site positions and a number of degrees of freedom, corresponding to variations in e.g. height, tilt, and orientation. These variables can be changed in order to better accommodate the supplied traffic load. The goal of the optimiser was not to find the location of a site necessary to cover a particular area. Instead, it receives the potential sites as initial input and selects from the candidates those sites that fulfil the targets best. This approach is more realistic from a network operator’s point of view, whereas the other approach would have represented a more academic way to solve the problem. Associated with this, deployment costs have been assigned to each candidate site. These deployment costs are related to e.g. the existence of an operator infrastructure. For example, the GSM operators have already deployed a 2G infrastructure, and will obtain synergy when they co-locate UMTS sites with GSM sites. The operators site cost definition is described in chapter 3.3 of [2]. It is now up to the optimiser tool to find the better configurations. It may for instance maximize the use of co-located GSM-UMTS, minimise the deployment cost and fulfil the traffic demand, but other possibilities are of course possible.


22/71

The variables, which could be handled by the optimiser, are described in the Table 3-1.

Table 3-1: Variables for network configuration optimisation handled by the optimiser tool.

Optimiser Variables Description Site Selection From the initial site candidates list select the ones that

fulfil the target in terms of service and costs Number of sectors Select the number of sectors from the max allowed in the

site; for all scenarios treated in this document this parameter was fixed at three.

Antenna height According to site implementation restrictions the antenna height is selected from a predefined range

Antenna azimuth Chose better azimuth to optimise coverage and minimise interference

Antenna Down-tilt Chose better down-tilt to minimize interference Number of Channel elements

Indicate number of channels elements installed in the node B required to accommodate traffic demand; this parameter was disregarded in the scenarios, since the relative costs were considered to be very low.

Pilot power -

3.2 Evaluation Process and performance indicators

The scenario evaluation is the process where the performance of the optimized network is quantified in more detail. This evaluation is done per service. The evaluation is performed by the simulators created in work packages 2 and 3, Advanced Static (AS) Simulator, based on Monte Carlo simulation, Short Term Dynamic (STD) Simulator and Dynamic Simulator (DS) respectively. The evaluation consists of the calculation of the Key Performance Indicators (KPIs) of the optimized network. As it is represented in Figure 3-1, all simulators (AS, STD and DS) will evaluate the same scenario. Due to the differences between simulator concepts, the available KPIs are not exactly the same; unfortunately, the level of tuning with the help of the Sanity Check scenarios has been rather low due to a lack of time at the end of the project. In general, the evaluation process is complete if the Key Performance Indicators are on target. Otherwise, another, somewhat more expensive, design is required and calculated by the optimizer, and is evaluated. The rest of this section provides the definition for the performance indicators available in each simulator.

3.2.1 Advanced Static and Short Term Dynamic simulator

Blocking The blocking statistics, delivered by the AS and STD simulation methods are average values given in percent. The figures are presented per cell and per service. For static simulations the percentage of blocked calls are averaged over the


23/71

snapshots. For STD simulations the rate of blocked calls are average values over the STD windows. In uplink, blocking of new calls can be due to • UL load (noise rise), i.e. insufficient capacity in uplink to serve the call • Limitation in UE power (outage) • Lack of hardware resources (channel elements) In downlink, blocking of new calls can be due to • DL load (power consumption), i.e. insufficient capacity in downlink to serve

the call • Limitation in DL power per link • Insufficient link quality (Ec/No), i.e. insufficient coverage • Lack of hardware resources (channel elements) Load per cell The load per cell is given as follows • UL load in terms of noise rise (in dB) or in percent (compared to UL pole

capacity) • DL load in terms of power consumption (in W) or in percent (compared to

maximum transmit carrier power) The load is given for static simulations, STD simulations and dynamic simulations. Delay The delay is defined as the offset in transmission time for PS services (in seconds) compared to ideal transmission time for a reference bearer. The delay in static simulations is approximated via the estimated throughput. A delay histogram per PS service is generated for the STD simulations. Soft handover The number of users (UE, calls) and the percentage of users (UE, calls) divided into soft handover and softer handover. The soft handover statistics are delivered as average numbers for the whole scenario. The soft handover statistics are given for static simulations and STD simulations. Minimum path loss plot The minimum path loss map is a plot generated from static simulations; for each pixel the minimum path loss is identified. Best server area plot The best server area map is a plot from static simulations; for each pixel the best serving cell is identified by its CPICH Ec/No.

3.2.2 Dynamic simulator

Blocking Blocking is defined strictly as the rejection of newly arriving calls by CAC


24/71

callsarrivedofnumber calls blocked ofnumber

=blockP (3.1)

The parameters that can be chosen are service, direction, and base station. The results are an average blocking and a confidence interval. Dropping There are 3 reasons of dropping: • Quality drop: calls that are dropped because they have too low quality over a

certain time • Forced drop: calls that are dropped due to congestion control • “Fractional blocking” or CAC drop: calls that are “blocked” after returning to

CAC from standby status. With reason being QD, FD or CACdrop, the dropping probability is defined as

calls dropped ofnumber total calls succesful ofnumber (reason) calls dropped ofnumber

ended that calls admitted ofnumber (reason) dropping todue ended that calls admitted ofnumber

+=

=dropP (3.2)

The parameters that can be chosen are service, direction, and base station. The results are an average dropping probability and a confidence interval. Load per cell Identical to the definition in paragraph 3.2.1. Delay “Inactive times” are e.g. reading times in a WWW session

x)(service

ratebit max bits - x)TT(service x)ED(service

x)vicetimes(serinactive-x)eTCD(servic x)TT(service

=

= (3.3)

with TT = “Transfer Time”, TCD = “Total call duration” and ED = “Excess Delay”. Cases: all calls or successful calls only Parameters: service, direction Results: PDF (probability density function), average + confidence interval, possibly percentiles with confidence intervals Throughput Throughput and delay are strongly connected:

x)(serviceimetransfer t

bits x)cehput(serviNet throug = (3.4)

The “stretch” is the realised transfer time divided by the minimal transfer time:


25/71

x)(service

ratebit max bits

imetransfer t x)rviceStretch(se

= (3.5)

In case 'bits' is zero and 'transfer time' is greater than zero (which can only happen in case a call is dropped, the registered stretch value is 999999 (in order to mimic infinity). Cases: all calls or successful calls only Parameters: service, direction Results: PDF (probability density function), average + confidence interval, possibly percentiles with confidence intervals Soft handover The dynamic simulator can in general obtain statistics for SHO, but for the reference and public scnenarios the simulation time was too limited to obtain reliable results.

3.2.3 Optimiser

Soft handover To estimate interference conditions in a network, the size of the SHO candidate set is calculated for each pixel. This set consists of the best server at the pixel along with all possible servers that lie within a certain range above the best server’s pilot signal strength. In a cell’s core area, this set should only contain one element (the cell itself). In the outer areas, the candidate set may grow to the maximum active set size without severe problems, a mobile located at the referring pixel will then most probably be in SHO. If the maximum active set size is exceeded, however, this means that there will be strong interfering signals in all cases, which is bad. Minimum path loss plot For a given network, the Minimum Path Loss Map offers a first classification of coverage critical areas. The path loss to the best server is colour-coded. A pixel-wise upper bound on the coverage any configured network may provide can be obtained using the isotropic path-loss predictions. The Best Achievable Coverage Map shows the path loss to the closest site, taking into account the antenna gain of the available antennas and possible additional losses at the antenna locations. This corresponds to assuming for each pixel, that an antenna of the “closest” site is directly pointing towards it. Areas that are poorly “illuminated” in this map have no chance of being well covered by any network (given the offered set of potential sites). The coverage situation in a given network is put into relation to the best achievable path loss map in the Path Loss Deficiency Map. The values are calculated as the difference between the network’s best server map and the best achievable path loss. A network does typically not reach the upper bound at all pixels; this map shows how the deficits are distributed across the scenario area.


26/71

Antenna admissible directions An antenna is not supposed to point directly towards a nearby building; this condition is formalised in the Freihaltewinkel constraint stating that no large obstacles may be present in the antenna’s main lobe within some distance, say 50m. This constraint leaves only a subset of the possible 360° azimuth directions for antenna configuration. The admissible directions (according to the Freihaltewinkel) are calculated as a first step during network planning with 10° resolution. Network Cost For a configured network, the Network Cost is calculated as the sum of individual costs of all involved hardware (Node B including TX/RX units and Antenna hardware) as well as the expenditure for necessary infrastructure (site exploration, mast head amplifiers, …). The expenditure is calculated as the capital expenditure plus the operational expenditure for a fixed time span (which is an optimisation parameter set to 60 months in this context). The primary objective in the automatic planning/optimization process is to minimise the network cost.

3.2.4 Global Performance Indicator

Note: at this stage the MOMENTUM GPI described in this section is only a proposal and has not been considered on the evaluation of the scenarios. The Global Performance Indicator (GPI) is a function that combines different Key Performance Indicators in a weighted manner to allow the comparison and ranking of different scenario configurations with a single measure. This function is particular useful when evaluating a scenario that has some areas with blocking problems, some areas with dropping problems and some services that suffer more delay then others. The Global Performance Indicator is described in Appendix A.


27/71

4 Scenarios Evaluation

The evaluation of the scenarios proposed in Table 2-1 had to be reduced due to project time constraints. The amount of data and specific parameter settings is quite large, and the fact that Momentum covers not just one simulation approach but a number only increases the required data. The specific standard (MOMENTUM XML) format has helped the consortium in discussing and sorting the data, and is therefore extremely useful for public use. The scenarios evaluated are presented in Table 2-2. Nevertheless, the small number of evaluated scenarios is considered sufficient to show the potential of the new techniques and models developed within the MOMENTUM simulators.

4.1 Berlin Reference Scenario

The reference scenario for Berlin, prepared by E-Plus, is completely located in a dense urban area of Berlin, with an area of 7.5 by 7.5 km2. E-Plus could provide detailed building data. The initial network that is used by WP4 to start the optimisation contains 84 sites and it is represented in the scenario number 24 of Table 2-1, described as EPL_RS[Ber_84sites_comm]. Based on the propagation loss grids and all network positions, a Minimum Path Loss Map can be produced giving an indication whether or not the network contains principal coverage holes.

© Clutter Data (2002), E-Plus Mobilfunk GmbH & Co KG

© Digital Building Model (2002), E-Plus Mobilfunk GmbH & Co KG Figure 4-1: Minimum path loss map for the Berlin reference scenario.


28/71

The picture clearly shows the large influence of penetration loss on the path loss; around the houses the minimum path loss is relatively low, whereas the houses and office buildings are clearly visible. The many red area, indicating high path loss, are a first indication that the provided network may be insufficient to meet the demand in the traffic grid. The next step is to determine the range of directions that is allowed per cell for the main antenna beam. Whereas Figure 4-1 is based on maximal gain to all directions, reality is that only certain directions are feasible. These directions are mainly determined by a non-blocking criteria (see the discussion on the Freihaltewinkel in paragraph 3.2.3). This results in Figure 4-2.

(a) (b) © Clutter Data (2002), E-Plus Mobilfunk GmbH & Co KG © Digital Building Model (2002), E-Plus Mobilfunk GmbH & Co KG

Figure 4-2: (a) Admissible directions for the Berlin reference scenario. The square indicates the sub area Alexanderplatz. This area is highlighted again in (b), using an aerographical image.

Note that this step makes really sense when detailed building data is available; as such, the indicated restrictions in Figure 4-2 reduce the computing complexity. Given the admissible directions per cell, and quality constraints on e.g. load per cell, the optimiser starts looking for a network that minimises costs for hardware and other necessary infrastructure. The success of this step is mainly bound by the quality (size, spreading) of the set of potential site locations and the total amount of offered load. In general, the result of this step is a limited number of good networks; these networks differ little in involved costs, and a definitive choice should be based on a more precise evaluation, e.g. by means of a Monte Carlo simulation. Figure 4-3 and Figure 4-4 show the uplink and downlink load,


29/71

respectively, per best server area (BSA; colour coded), as a result from a pre-processing step in the optimiser, and from the advanced static simulation.

(a)

© Clutter Data (2002), E-Plus Mobilfunk GmbH & Co KG © Digital Building Model (2002), E-Plus Mobilfunk GmbH & Co KG

(b)


Figure 4-3: (a) UL load per BSA for Berlin – Reference, WP4. (b) UL load per BSA for Berlin – Reference, WP2 (advanced static). Note the different scaling for (a) and (b).

(a)


(b)


Figure 4-4: (a) DL load per BSA for Berlin – Reference, WP4; (b) DL load per BSA for Berlin – Reference, WP2 (advanced static). Note the different scaling for (a) and (b).


30/71

From Figure 4-4, it is concluded that the network is clearly overloaded, indicating that the capacity of the potential sites is not sufficient for the provided traffic. However, although the optimiser does not provide a close-to-optimal solution that can carry the traffic, it does indicate quite precisely the “trouble”-areas (Figure 4-4(a), orange-red areas). In contrast, Figure 4-3 shows that the uplink load is within the given limits. The reason for this rather well-behaving uplink lies in the asymmetry of the provided traffic mix, which is about 1:3 (uplink vs downlink). Moreover, note that the advanced static simulator gives structurally (distribution of relative high and relative low load) similar results as the pre-processing step in the optimiser, but with lower values for the load. This is based on the fact that the pre-processing step does not have call admission control. When there are too many users, the network just cannot serve some of them. Since there is a tremendous amount of overload in the Berlin – Reference scenario, the difference between the advanced static simulator (with call admission) and the optimiser becomes very clear. In addition the optimiser does not take into account power limits on uplink and downlink power. The MOMENTUM planning scenarios deal especially with the high load cases, and there the differences are greater; in these cases the (theoretical) power needed to reach a mobile in the downlink, or the base station in the uplink, can surpass the allowed range. The effect is twofold: a) the load in the own cell (the one with overload) is increased, and b) load in other cells is increased since they have to “react” to higher interference from overloaded cells. In the advanced static simulation the overload is just not served, but it merely increases the blocking (or outage) and hence it does not initiate this “upwards spiral” off load. In addition, Figure 4-5 shows a histogram of the uplink and downlink load of the cells, which is an indication of the load balance in the network.

(a) (b)

Figure 4-5: Load histogram for the Berlin – Reference scenario, based on the advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink).

A broad range of load values can indicate a ill-balanced network with some lightly loaded areas and some heavy or over-loaded areas.


31/71

A detailed simulation of the network will reveal more specific statistics of the performance of the network, specified per service, per cell and sometimes even per pixel. The granularity and the confidence of the results that are showed depend strongly on the number of simulation steps. For the Berlin – Reference scenario however it was quite difficult to obtain enough statistics per pixel to provide reliable results from both the short-term dynamic as the dynamic simulator. The short-term dynamic simulator managed to obtain results for cell-oriented indicators, and for a part of the referece scenario, namely the area around and including Alexanderplatz.

(a)


(b) (c) (d)

Figure 4-6: (a) SHO situation for Berlin – Reference, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 33% of the users are in soft handover, versus 10% in softer handover.


32/71

The short-term dynamic simulator has no picture of the soft handover situation, because of the fact that for reliable pixel statistics in these type of scenarios very long simulation times are required. A series of key performance indicators that influences the quality as perceived by the customer is the blocking, dropping, the expected data rate and the delay. These are strongly influenced by the call admission control algorithms deployed, as was mentioned when the difference in load results between the optimiser and the advanced static simulator was explained. First of all, in Figure 4-7, we present the total downlink blocking.

© Clutter Data (2002), E-Plus Mobilfunk GmbH & Co KG

© Digital Building Model (2002), E-Plus Mobilfunk GmbH & Co KG Figure 4-7: Total downlink blocking for Berlin – Reference, WP2 (advanced static); the results are per pixel.

Depending on the call admission control and radio resource management algorithm deployed, the system can either choose for blocking circuit and packet switched services to retain a minimum performance for the ongoing calls, or to downgrade both incoming and ongoing sessions. In Figure 4-8 the bearer rate, or better, data rate assigned to the different packet switched services is depicted in case the RRM algorithm allows for downgrading, and the related expected data rate is presented. Recall that the services monitored in Figure 4-8 had the following bearer assignment (see [2]):

Service Downlink bearer

Email Location Based Services

File Download Web-browsing

DCH32 DCH64

DCH128 DCH384

Table 4-1: Bearer assignment in the advanced static simulator for the packet switched services.


33/71

Note that assignment of a certain bearer will not automatically lead to the corresponding bit rate, due to the downgrading option in the simulator.

(a)

(b)

(c)

(d)

Figure 4-8: The throughput histograms for email (a), file download (b), location based (c), and browsing (d) traffic, based on the advanced static simulations. The resulting average data rates are: email – 91 kbps; file download – 129 kbps; location based – 91 kbps; WWW – 322 kbps.

The precise bearer statistics can be obtained from the static simulator as well. For the services file download and WWW-traffic, the STD simulator obtained these specific bearer statistics as well: • File download:

384 kbps bearer: 62.2% 128 kbps bearer: 4.4% 64 kbps bearer: 33.4% This leads to a mean bit rate of 266 kbps.

• WWW:


34/71

384 kbps bearer: 38.1% 64 kbps bearer: 59.7% 32 kbps bearer: 2.2% This leads to a mean bitrate 185 kbps.

This result shows that • A lack of tuning leads to a different bearer assignment and average bit rate,

when comparing the static simulator and the short-term dynamic simulator; • the bearer assignment probabilities, as implied by presented in Table 4-2 and

used to generate the load grids, differ from the realised assignment. The realisation depends on the actual load, and from the results quoted above it observed that for both file download and web browsing the actual situation is more positive than was initially guessed. These figures are for the Berlin – Reference scenario; for Alexanderplatz, the percentages are even more positive, at the expense of blocking.

Service

Downlink bearer

File Download Web-browsing

DCH32 9 % DCH64 90 % 90 %

DCH128 9 %

DCH384 1 % 1 %

Table 4-2: Bearer assignment probabilities, based on a “best guess”, and used for producing the load grids.

Finally, the delay for packet switched services is presented in Figure 4-9.

0.01

0.1

1

10

0 2 4 6 8 10 12 14 16 18 20

hist

ogra

m

delay [sec]

Non-zero delay in ftp traffic

(a)

0.001

0.01

0.1

1

0 10 20 30 40 50 60 70 80

hist

ogra

m

delay [sec]

Non-zero delay in web traffic

(b)

Figure 4-9: Delay histograms from the WP2-STD simulator for Berlin – Reference – Alexanderplatz. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic.

The average delay for file download was 2.16 seconds, and around 9% of the traffic was downgraded during the session. For WWW-traffic these numbers were


35/71

10.8 seconds delay on average and also around 9% downgrading within the session. Due to a combination of circumstances – some inconsistencies in input files and limited simulation simulation time – the dynamic simulator was not able to obtain reliable results for the Berlin scenario.

4.2 Berlin Public Scenario

The Public scenario for Berlin, prepared by E-Plus, has been derived based on the Berlin reference scenario. The site distribution of the Berlin Public Scenario covers an area of 7.5 by 7.5 km2. Mostly a 3-sectorised site is applied with discrete antenna locations at the mounting object. In contrast to the Berlin – Reference scenario, the resolution of the propagation loss prediction in the Berlin – Public scenario is 50m x 50m. The initial network that is used by WP4 to start the optimisation contains 50 sites and it is represented in the scenario number 49 of Table 2-1, described as EPL_PS[Ber_50sites_comm]. The Minimum Path Loss Map, as shown in Figure 4-10, indicates that the potential problematic areas are mostly on the border of the area, where a limited number of sites is available.

Figure 4-10: Minimum Path Loss Map for Berlin – Public.

The next step is to determine the range of directions that is allowed per cell for the main antenna beam. Whereas Figure 4-10 is based on maximal gain to all directions, reality is that only certain directions are feasible. These directions are mainly determined by a non-blocking criteria. This results in Figure 4-11.


36/71

Figure 4-11: Admissible directions for Berlin – Public.

Note that the reduced resolution and the absence of building data results in almost no reduction of the computational complexity regarding the number of admissible directions: almost all directions are allowed on each site. Given the admissible directions per cell, and quality constraints on e.g. load per cell, the optimiser starts looking for a network that minimises costs for hardware and other necessary infrastructure. The success of this step is mainly bound by the quality (size, spreading) of the set of potential site locations and the total amount of offered load. In general, the result of this step is a limited number of good networks; these networks differ little in involved costs, and a definitive choice should be based on a more precise evaluation, e.g. by means of a Monte Carlo simulation. Figure 4-12 and Figure 4-13 show the uplink and downlink load, respectively, per best server area (colour coded), as a result from a pre-processing step in the optimiser, and from the advanced static simulation. Like the Berlin – Reference scenario, the downlink results for the load, shown in Figure 4-13, indicate an overloaded work. The “trouble”-areas (Figure 4-13(a), orange-red areas) are marked and should first be addressed by an operator. In contrast to the Berlin – Reference scenario, also the uplink results (Figure 4-12) show a clear overload in large parts of the area. In addition, Figure 4-14 shows a histogram of the uplink and downlink load of the cells, which is an indication of the load balance in the network.


37/71

(a)

(b)

Figure 4-12: (a) UL load per BSA for Berlin – Public, WP4. (b) UL load per BSA for Berlin – Public, WP2 (advanced static).

(a)

(b)

Figure 4-13: (a) DL load per BSA for Berlin – Public, WP4; (b) DL load per BSA for Berlin – Public, WP2 (advanced static).


38/71

(a)

(b)

Figure 4-14: Load histogram for the Berlin – Reference scenario, based on the advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink).

Unlike the Berlin – Reference scenario, this scenario has for the downlink only highly (over-)loaded cells, and there is certainly no possibility to carry the traffic with the offered number of sites. A detailed simulation of the network will reveal more specific statistics of the performance of the network, specified per service, per cell and sometimes even per pixel. The granularity and the confidence of the results that are showed depend strongly on the number of simulation steps. For the Berlin – Public scenario however it was quite difficult to obtain enough statistics to provide reliable results from the dynamic simulator. However, the short-term dynamic simulator managed to obtain results this Berlin scenario.


39/71

(a)

(b) (c) (d)

Figure 4-15: (a) SHO situation for Berlin – Public, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 31% of the area is in soft handover, versus 7% in softer handover.

A series of key performance indicators that influences the quality as perceived by the customer is the blocking, dropping, the expected data rate and the delay. These are strongly influenced by the call admission control algorithms deployed, as was mentioned when the difference in load results between the optimiser and the advanced static simulator was explained. First of all, in Figure 4-16, we present the total downlink blocking.


40/71

Figure 4-16: Total downlink blocking for Berlin – Public, WP2 (advanced static); the results are per pixel.

The STD simulator obtained 2.0% uplink blocking for voice and no blocking for other services. The “advantage” of the relatively high blocking rate for e.g. web-browsing in the real-time dynamic simulator can be seen in Figure 4-17, where the use of high bit rate bearers, and the related expected data rate is presented.

(a)

(b)


41/71

(c)

(d)


The STD simulator obtained specific bearer statistics for file download and WWW traffic: • FTP (file download):

384 kbps bearer: 49.5% 128 kbps bearer: 11.0% 64 kbps bearer: 39.5% This leads to a mean bit rate of around 229 kbps.

• WWW: 384 kbps bearer: 38.4% 64 kbps bearer: 53.2% 32 kbps bearer: 8.4% This leads to a mean bit rate of around 184 kbps

Note that, given the fact that the downgrading mechanisms of the two simulators (static and short-term dynamic) are not tuned, the mean bit rates obtained by the STD for file download and web-browsing are relatively in line with the advanced static simuations. Finally, the delay for packet switched services is presented in Figure 4-18.


42/71

0.01

0.1

1

10

0 5 10 15 20 25

hist

ogra

m

delay [sec]


0.001

0.01

0.1

1

0 10 20 30 40 50 60

hist

ogra

m

delay [sec]


Figure 4-18: Delay histograms from the WP2-STD simulator for Berlin – Public. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic.

The average delay for file download was 1.32 seconds, and around 21% of the traffic was downgraded during the session. For WWW-traffic these numbers were 8.9 seconds delay on average and also around 25% downgrading within the session.

4.3 The Hague Public Scenario

The Public scenario for The Hague, prepared by TNO/KPN, takes a maximum of 76 sites into consideration. The Dutch public scenario is a 4 x 4 km2 square area in the center of The Hague. The scenario is represented in the scenario number 50 of Table 2-1, described as PS[Hag_76sites_comm]. The minimum path loss for this scenario, as shown in the Minimum Path Loss Map (Figure 4-19), is very low; this is based on the facts that no building penetration is taken into account and the high base station density. The next step is to determine the range of directions that is allowed per cell for the main antenna beam. Whereas Figure 4-19 is based on maximal gain to all directions, reality is that only certain directions are feasible. These directions are mainly determined by a non-blocking criteria. This results in Figure 4-20.


43/71

Figure 4-19: Minimum Path Loss Map for The Hague – Public.

Figure 4-20: Admissible directions for The Hague – Public, WP4. The circled sites constitute the optimal network as simulated by the dynamic simulator.

Since no detailed building information is available and the resolution of the path loss predictions is only 50 m x 50 m, there is no clear reduction of the


44/71

computational complexity regarding the number of admissible directions: all directions are allowed on each site. Given the admissible directions per cell, and quality constraints on e.g. load per cell, the optimiser starts looking for a network that minimises costs for hardware and other necessary infrastructure. The success of this step is mainly bound by the quality (size, spreading) of the set of potential site locations and the total amount of offered load; a key difference between the The Hague – Public scenario and the Berlin scenarios is the large number of scattered potential sites in the area of interest. Figure 4-21 and Figure 4-22 show the uplink and downlink load, respectively, per best server area (colour coded), as a result from a pre-processing step in the optimiser, and from the advanced static simulation; the analysis is based on the large set of potential sites (Figure 4-21 and Figure 4-22, (a) and (c)) and on the optimised set (Figure 4-21 and Figure 4-22, (b) and (d)).

(a)

(b)


45/71

(c)

0.05

0.09

0.12

0.16

0.21

0.05

0.09

0.12

0.16

0.21

0.05

0.09

0.12

0.16

0.21

(d)

Figure 4-21: (a) UL load per BSA for The Hague – Public, WP4, based on the initial set of potential sites. (b) UL load per BSA for The Hague – Public, WP4, based on an optimal selection of potential sites. (c) UL load per BSA for Berlin – Public, WP2 (advanced static), based on the initial set of potential sites. (d) UL load per BSA for The Hague – Public, WP3, based on an optimal selection of potential sites.

(a)

(b)

0.05 - 0.09

0.09 - 0.12

0.12 - 0.16

0.16 - 0.21

0.21 – 0.33

0.05 - 0.09

0.09 - 0.12

0.12 - 0.16

0.16 - 0.21

0.21 – 0.33

0.05 - 0.09

0.09 - 0.12

0.12 - 0.16

0.16 - 0.21

0.21 – 0.33


46/71

(c)

2 -

2.5

3 -

3.7

4.9

2 -

2.5

3 -

3.7

4.9

2 -

2.5

3 -

3.7

4.9

(d)

Figure 4-22: (a) DL load per BSA for The Hague – Public, WP4, based on the initial set of potential sites. (b) DL load per BSA for The Hague – Public, WP4, based on an optimal selection of potential sites. (c) DL load per BSA for Berlin – Public, WP2 (advanced static), based on the initial set of potential sites. (d) DL load per BSA for The Hague – Public, WP3, based on an optimal selection of potential sites.

Clearly, the message here is that in UMTS, less can be better. A large number of cells can lead to pilot pollution and a high level of interference. Figure 4-23 shows a histogram of the uplink and downlink load of the cells, which is an indication of the load balance in the network.

2 - 2.5

2.5 - 3

3 - 3.7

3.7- 4.9

4.9 - 6

2 - 2.5

2.5 - 3

3 - 3.7

3.7- 4.9

4.9 - 6

2 - 2.5

2.5 - 3

3 - 3.7

3.7- 4.9

4.9 - 6

0.1-0.125

0 125-0 15

0 15-0 185

0 185-0 245

0 245-0 3


47/71

Figure 4-23: Load histogram for the The Hague – Reference scenario, based on the advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink).

The offered set of potential sites is more than sufficient to carry the offered traffic, so on the one hand a true optimisation is possible, and on the other hand relatively low load per cell is obtained. Based on chosen network, a more precise indication can be given about potential coverage problems. In particular, the path loss deficiency map shows how this chosen network performs as compared to the best possible one, in terms of coverage. The map is given in Figure 4-24. A detailed simulation of the network will reveal more specific statistics of the performance of the network, specified per service, per cell and sometimes even per pixel. The granularity and the confidence of the results that are shown depends strongly on the number of simulation steps. For the real-time dynamic simulator this leads to a number of indicators that can only be presented with some accuracy when accumulated on cell or even area level. In most cases the results from two different simulation approaches can be compared (Monte Carlo vs real-time dynamic, or short-term dynamic vs real-time dynamic)

(a)

(b)

(c)

Figure 4-24: Path Loss Deficiency Map for The Hague – Public ((a) – original network, (c) – optimised network) and traffic map, WP4. While in the original network configuration the coverage is distributed regularly (a), the optimised network sets some accents (c). Comparison with the traffic map (b) shows that coverage (and capacity) is focused on the high traffic areas. The automatic planning process thus manages to save a great deal of infrastructure cost by concentrating on the hot spots.

.


48/71

(a)

(b) (c) (d)

Figure 4-25: (a) SHO situation for The Hague – Public, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 70% of the area is in soft handover, versus 10% in softer handover.

Note that the soft handover statistics are based on the original set of base stations, and not on the optimised set. This has strong influence on the soft handover area which is huge, and therefore quite costly in terms of required hardware. A series of key performance indicators that influences the quality as perceived by the customer is the blocking, dropping, the expected data rate and the delay. These are strongly influenced by the call admission control algorithms deployed, as will be shown by following results. First of all, in Figure 4-26, we present the total DL blocking (advanced static simulator) and DL blocking of voice (dynamic simulator).


49/71

(a)

0

0 - 3

3 - 6

6 - 9

9 - 1

0

0 - 3

3 - 6

6 - 9

9 - 1

0

0 - 3

3 - 6

6 - 9

9 - 1

0

0 - 3

3 - 6

6 - 9

9 - 1

(b)

Figure 4-26: (a) Total DL blocking for voice for The Hague – Public, WP2 (advanced static), per pixel. (b) DL blocking for voice The Hague – Public, WP3 (optimised scenario), per cell.

The short-term dynamic simulator provides results that are in line with Figure 4-26: no UL blocking. The results of the dynamic simulator are also in line, but in addition to DL blocking, Figure 4-27 and Figure 4-28 show a large number of other Key Performance Indicators, per service. The numbers are averaged over the whole area.

0

0 - 3%

3 - 6%

6 - 9%

9 - 12%

0

0 - 3%

3 - 6%

6 - 9%

9 - 12%

0

0 - 3%

3 - 6%

6 - 9%

9 - 12%

0

0 - 3%

3 - 6%

6 - 9%

9 - 12%


50/71

Key performance indicators: The Hague Public

0%

2%

4%

6%

8%

10%

12%

14%

16%

Blocking, Total Blocking, UL Blocking, DL QualityDropping,

Total

QualityDropping, UL

QualityDropping, DL

CAC Dropping,Total

OutageProbability, UL

OutageProbability, DL

SpeechTelephony StreamingMultiMediaVideoTelephony MMSEMail FileDownloadWWW LBS

Figure 4-27: Main performance indicators, The Hague – Public, non-optimised.

The target for outage probability for circuit switched services (speech and video telephony, video streaming) is set to 1%, whereas the target for packet switched services is set at 10%. Figure 4-28 shows the main performance indicators for the The Hague optimised scenario. Important observations are: • The blocking probability is very high for LBS, especially compared to the

blocking probability for other services. However, as a result of this relatively high blocking, the system is not forced to drop users. This is indicated by the quality dropping probability of 0%. Argued opposite, insufficient (too low) call blocking by the system causes a “punishment” lateron: it will lead to relatively high dropping probabilities, which is, in terms of a global performance indicator, a much worse situation.

• For both blocking and dropping, the DL forms the bottleneck of the system. • As expected, the outage probability is similar to the BLER targets used in the

simulations (1% for circuit switched; 10% for packet switched services, both UL and DL).


51/71

Key performance indicators: The Hague Public, optimized

0,0%

5,0%

10,0%

15,0%

20,0%

25,0%

30,0%

35,0%

Blocking, Total Blocking, UL Blocking, DL Qual i ty Dr opping,Total

Qual i ty Dr opping,UL

Qual i ty Dr opping,DL

CAC Dr opping,DL

OutagePr obabi l i ty, UL

OutagePr obabi l i ty, DL

SpeechTelephony

Str eamingMul tiMedia

VideoTelephony

MMS

EMai l

Fi leDownload

WWW

LBS

Figure 4-28: Key performance indicators for The Hague – Public, optimized.

The “advantage” of the relatively high blocking rate for e.g. web-browsing in the real-time dynamic simulator can be seen in Figure 4-29, where the use of high bit rate bearers, and the related expected data rate is presented.

(a)

(b)


52/71

(c)

(d)

Figure 4-29: The throughput histograms for email (a), file download (b), location based (c), and browsing (d) traffic, based on the advanced static simulations. The resulting average data rates are: email – 127 kbps; file download – 376 kbps; location based – 126 kbps; WWW – 379 kbps




Figure 4-30(b) shows the average throughput of calls that were successfully ended. As all calls use the dedicated channel (DCH) this throughput should be the same as the ideal bit rate a user requests. Only if the system is very full, a new user receives a lower bit rate than its first choice. In the picture we see that most services experience a little lower bit rate than the first choice bit rate. This is mainly so because retransmissions lead to a lower effective bit rate, as blocks of data need to be transmitted more then once by the network, while the user only receives each block one time correctly. The results are in line with the short-term dynamic simulator and the advanced static simulator, and in the case of file download almost identical to the STD results.


53/71

Net thoughput successful calls: The Hague Public

-50,0

100,0150,0200,0250,0300,0350,0400,0

Net throughput successfulcalls, UL

Net throughput successfulcalls, DL

Kbp

sSpeechTelephony

StreamingMultiMedia

VideoTelephony

MMS

EMail

FileDow nload

WWW

LBS

(a)

Net thoughput successful calls: The Hague Public, optimized

-50,0

100,0150,0200,0250,0300,0350,0400,0

Net throughput successfulcalls, UL

Net throughput successfulcalls, DL

Kbp

s

SpeechTelephony

StreamingMultiMedia

VideoTelephony

MMS

EMail

FileDow nload

WWW

LBS

(b)

Figure 4-30: Average throughput for circuit and packet switched services, (a) The Hague – Public and (b) The Hague – Public, optimised.

The radio resource management algorithm that was employed to obtain Figure 4-30 did not downgrade services during the session, and harldly at admission. This explains the relatively high dropping (handover!) and blocking for this scenario, even though the radio quality is overall very acceptable. Dropping of ongoing sessions should kept to a minimum; Table 4-3 shows the results from the real-time dynamic simulator for the non-optimised network. Note that the size of the simulated scenarios prohibited detailed spatial analysis; in practice, this simulator should be used for this type of analysis when a smaller weak spot in your network is discovered.


54/71

Service

Spee

ch

Tel

epho

ny

Stre

amin

g M

ultiM

edia

Vid

eo

Tel

epho

ny

MM

S

EM

ail

File

D

ownl

oad

WW

W

LB

S

UL 0% 0% 0% 0% 0% 0% 0% 0% DL 5% 10% 11% 0% 0% 2% n.a. n.a. Table 4-3: Dropping of calls, for The Hague – Public, non-optimised.

In the UL there has been no quality dropping. In the DL, especially the circuit switched services show quality dropping. Most likely this is caused by the fact that they have long uninterrupted sessions causing many opportunities for errors, whereas the other services only remain in the system for a short time. For the optimised network, the results are give in Table 4-4. Service

Spee

ch

Tel

epho

ny

Stre

amin

g M

ultiM

edia

Vid

eo

Tel

epho

ny

MM

S

EM

ail

File

D

ownl

oad

WW

W

LB

S

UL 0.3% 0.0% 0.0% 1.4% 0.0% 0.0% 0.0% 0.0% DL 12.9% 33.3% 19.9% 4.2% 0.9% 0.8% n.a. n.a. Table 4-4: Dropping of calls, for The Hague – Public, optimised.

• First of all, note that the results for the optimised scenario are worse then for the non-optimised scenario. At first sight, this might seem awkward, since optimisation should lead to a better network. However, the optimised network contains less sites then the non-optimised network, so the same traffic load needs to be served by less sites. By recalling that the optimisation procedure only includes in a remote way the detailed performance indicators that are tabulated in Table 4-3 and Table 4-4, the worsening of the situation for bursty services is explained. An improved version of the model that underlies the optimiser should take this feedback of the more detailed simulators into account (see also Figure 3-1); instead of a “static” load, the burstiness of the services should be captured and included in the merit function.

• The CAC algorithm has not been tuned. It allows too many circuit switched users. This causes high quality dropping probabilities for those services. This proves the importance of having a well-tuned CAC algorithm.

Finally, the delay for packet switched services is presented in Figure 4-31.


55/71

0.01

0.1

1

10

0 5 10 15 20

hist

ogra

m

delay [sec]


0.001

0.01

0.1

1

0 10 20 30 40 50 60 70

hist

ogra

m

delay [sec]


Figure 4-31: Delay histograms from the WP2-STD simulator for The Hague – Public. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic.

The average delay for file download was 2.58 seconds, and around 5.4% of the traffic was downgraded during the session. For WWW-traffic these numbers were 10 seconds delay on average and also around 6% downgrading within the session.

4.4 Lisboa Public Scenario

The public scenario for Lisboa, prepared by Vodafone Telecel, is located in the down-town of Lisboa city. The initial network that is used by WP4 to start the optimisation contains 52 sites and it is represented in the scenario number 48 of Table 2-1 described as TEL_PS[Lis_52sites_comm]. Based on the propagation loss grids and all network positions, a Minimum Path Loss Map is produced (Figure 4-32). Like in the Berlin – Public scenario, the path loss map looks relatively fine, with some problems at the border of the area.


56/71

Figure 4-32: Minimum Path Loss Map for Lisbon – Public.

The next step is to determine the range of directions that is allowed per cell for the main antenna beam. Whereas Figure 4-32 is based on maximal gain to all directions, reality is that only certain directions are feasible. These directions are mainly determined by a non-blocking criteria. This results in Figure 4-33.


57/71

Figure 4-33: Admissible directions for Lisbon – Public.

Since no detailed building information is available and the resolution of the path loss predictions is 20 m x 20 m, there is no clear reduction of the computational complexity regarding the number of admissible directions: almost all directions are allowed on each site. Given the admissible directions per cell, and quality constraints on e.g. load per cell, the optimiser starts looking for a network that minimises costs for hardware and other necessary infrastructure. Like in the Berlin scenarios, the number of available sites is relatively limited. This is immediately translated into a high loaded network, for both uplink (Figure 4-34) and downlink (Figure 4-35). These two figures show the results for load per best server area (colour coded), from a pre-processing step in the optimiser, and from the advanced static simulation.


58/71

(a)

(b)

Figure 4-34: (a) UL load per BSA for Lisbon – Public, WP4. (b) UL load per BSA for Lisbon – Public, WP2 (advanced static).

(a)

(b)

Figure 4-35: (a) DL load per BSA for Lisbon – Public, WP4; (b) DL load per BSA for Lisbon – Public, WP2 (advanced static).


59/71

In addition, Figure 4-36 shows a histogram of the uplink and downlink load of the cells, which is an indication of the load balance in the network.

(a) (b) Figure 4-36: Load histogram for the Berlin – Reference scenario, based on the advanced static simulator. At the left the uplink load, at the right the downlink load. The maximum allowable load was set at 0.3 (uplink) and 70% (downlink).

Like the Berlin – Public scenario, this scenario has for the downlink only highly (over-)loaded cells, and there is certainly no possibility to carry the traffic with the offered number of sites. A detailed simulation of the network will reveal more specific statistics of the performance of the network, specified per service, per cell and sometimes even per pixel. The granularity and the confidence of the results that are showed depend strongly on the number of simulation steps. For the Lisbon – Public scenario however it was quite difficult to obtain enough statistics to provide reliable results from the dynamic simulator. However, the short-term dynamic simulator managed to obtain results the Lisbon scenario.


60/71

(a)

(b) (c) (d)

Figure 4-37: (a) SHO situation for Lisbon – Public, WP2 (advanced static). (b) A histogram for the average percentage of users in soft handover per cell. (c) contains this percentage for softer handover and (d) shows per cell how it performs in terms of soft and softer handover. On average, 27% of the area is in soft handover, versus 7.5% in softer handover.

A series of key performance indicators that influences the quality as perceived by the customer is the blocking, dropping, the expected data rate and the delay. These are strongly influenced by the call admission control algorithms deployed, as was mentioned when the difference in load results between the optimiser and the advanced static simulator was explained. First of all, in Figure 4-38, we present the total DL blocking.


61/71

Figure 4-38: Total DL blocking for Lisbon – Public, WP2 (advanced static); the results are per pixel.

The STD simulator obtained 2.0% uplink blocking for voice and no blocking for other services. The “advantage” of the relatively high blocking rate for e.g. web-browsing in the real-time dynamic simulator can be seen in Figure 4-39, where the use of high bit rate bearers, and the related expected data rate is presented.


62/71

(a)

(b)

(c)

(d)






63/71

Note that the mean bit rates of file download and web-browsing are very well in line with the advanced static simuations. Finally, the delay for packet switched services is presented in Figure 4-40.

0.01

0.1

1

10

0 5 10 15 20 25

hist

ogra

m

delay [sec]


0.001

0.01

0.1

1

0 10 20 30 40 50 60hi

stog

ram

delay [sec]


Figure 4-40: Delay histograms from the WP2-STD simulator for Lisbon – Public. (a) Delay histogram for file download traffic. (b) Delay histogram for web traffic.

The average delay for file download was 1.98 seconds, and around 24% of the traffic was downgraded during the session. For WWW-traffic these numbers were 10.25 seconds delay on average and also around 26.5% downgrading within the session.

. .


64/71

5 Lessons Learned, Conclusions

The first conclusion is that generally, most scenarios were infeasible in the sense that the offered load was far too high. The WP4 load analysis indicated this, and this was backed by WP2 simulation results. In general, a downscaling of the traffic is possible, but this may lead to inconsistencies in the traffic profile. It may be much better to include more potential sites to the initial network, as is shown in the The Hague scenario. This scenario is based on the same assumptions regarding generated traffic per customer, but contains a large number of randomly scattered potential sites. The use of the developed optimisation tools in these "overload" circumstances is rather limited. The pre-processing, present in the tool, is able to find the weakest spots in the offered network, so this can still be used by an operator to search specifically for certain sites that are most effective in reaching a performance target. However, in the The Hague case, the scenario was feasible, the WP4 load analyser did indeed find a good network that is far cheaper. That the network is good, is indicated by the load maps and also backed by WP2 simulations, and confirms the quality of the tool and underlying model, as laid down in the WP4 deliverables. Regarding the advanced static simulator, it showed very clearly its capabilities of handling very realistic scenarios in limited time, even though several thousands of snapshots needed to be analysed. In addition, the incorporated QoS module, taking care of call admission control and radio resource management, in particular down- and upgrading of sessions, showed its potential for all scenarios. In certain cases its results could be backed by results from the more dynamic approaches, in particular the short-term dynamic. In terms of future work, Momentum has shown that the tuning of these widely used Monte Carlo simulators to cope and reach alignment with "reality" is far from trivial, and the various Momentum deliverables show the initial steps towards a reliable static simulation approach. Due to time constraints, the results are only preliminary, but will serve as a unique starting point. The short-term dynamic but especially the dynamic simulators have been pushed to and sometimes over their limits. The size of the public and reference scenarios prevented the team not only from obtaining reliable results, but also from learning about these extremely complex algorithms that are interlinked with many feedback loops in the UMTS system. The small-scale scenarios that have been used in WP3 to generate insights proved to be more fruitful, although the time that was spend was still too limited. Very often, initial results deceived the consortium, challenging their understanding of the behaviour of UMTS. Operators that currently rollout and test the first UMTS networks will recognize this. This shows immediately the potential benefit of these types of dynamic simulators: a team of engineers can safely learn and play around with the different settings before trialing


65/71

the real system. The methodologies developed within the Momentum project will bring momentum into your understanding and design of the UMTS radio network.


66/71

References

[1] MOMENTUM (MOdels and SiMulations for NEtwork PlaNning and ConTrol of UMTS) research project, under the EU Information Society Technologies (IST) Programme, contract number IST-2000-28088, http://www.momentum.zib.de

[2] Lourenço, P. (ed.), Fledderus, E.R., Geerdes, H.-F., Heideck, B., Kürner, T., Rakoczi, B., Reference Scenarios, Momentum Deliverable 5.2, June 2003.

[3] Eisenblätter, A., Geerdes, H.-F., Koch, T. (eds.), Türke, U. XML Data Specification and Documentation, Appendix to Momentum Deliverable 5.2, September 2003.

[4] Martin, A. (ed.), Eisenblätter, A., Fügenschuh, A., Fledderus, E.R., Geerdes, H.-F., Heideck, B., Junglas, D., Koch, T., Kürner, T., Mathematical Methods for Automatic Optimisation of UMTS Radio Networks, Momentum Deliverable 4.3, September 2003.


67/71

A Global Performance Indicator

The Global Performance Indicator (GPI) proposes an approach to evaluate the scenarios in a way that the operator allows to select the most relevant Key Performance indicators and/or services to fulfil the marketing and engineering service network requirements. The Global Performance Indicator is designed to consider the following issues: • The GPI should only include Key Performance Indicators that the customer can

perceive • The GPI should penalize scenario configurations if one of the Key

Performance Indicators is not on target. • Selection of the best network configuration is based on the GPI and on the

network cost. The generic expression for the GPI is given by:

( ) ( ) K×××= ×× 21 102

101100 ww KPIPIKGPI (A.1)

where KPI1 is the Key Performance Indicator 1 and w1 is the weight of KPI1. • The use of a product allows an operator to introduce a penalty when one of the

partial indicators is low • ‘10’ is the factor used to decrease the GPI value more rapidly when very low

partial indicators exist. • If maximum admitted individual KPI values are exceeded, Scenario

Configurations shall be discarded. The MOMENTUM GPI expression is computed according to the simulator available Key Performance Indicators and includes an average value for the area under study. It should be mentioned that particular attention must be paid to bad performance indicators values in not so important areas (as rural open areas or lakes). These situations are in some cases perfectly acceptable, leading to cheap network designs, with good quality in the most important areas as urban suburban and main roads areas. The drawback of using the current GPI is that it converts the complete scenario to a single value leading to the loss of important spatial information. Nevertheless, it could give an important quantitative evaluation. The Key Performance Indicators selected for the GPI are related to three main quality drivers: • Accessibility (Block Call Ratio): percentage blocked users (UL and DL) due

to: UL load, DL load DL power Shortage of hardware resources


68/71

• Retainability (Drop Call Ratio): percentage dropped users (UL and DL) due to: UL power, DL power UL load, DL load Poor quality (bad C/I)

• Integrity (DELay): average delay The proposal for MOMENTUM GPI is the following:

( )( ) ( )( ) ( )( )( ) 20.01050.01030.010 sec5%11100 ××× <×−×−×= DELDCRBCRGPI (A.2)

The weights of the KPIs describe the emphasis that is put on a specific indicator. Note that the integrity-factor, related to delay, could be split, in order to cope with several services, each with different maximum delay times according to the type of service, weighted separately related to the importance for the operator’s commercial strategy.


69/71

B Sanity Check Scenario

In [2] and in Table 2-1, fourteen different sanity checks were described. The sanity checks were meant to compare the advanced static simulator of WP2 and the dynamic simulator of WP3. These comparisons would be used to find bugs in the simulators, but also to get insight in what the effect is of leaving out certain details in the models underlying the simulators. Due to delays in other parts of the project, a prioritisation had to be made. The choice was between running the complete list of sanity checks and no reference scenarios, or only a limited number of sanity check scenarios and the new, reduced, list of reference and public scenarios. It was decided to run the reference and public scenarios and run only some of the sanity checks. The sanity check results and the lessons learned are presented in this section.

B.1 MoDySim versus analytical calculations

CAC algorithm In MoDySim the CAC algorithm works such that if the load (load factor in UL, total DL power in DL) at arrival of a new call exceeds a certain configurable (service dependent) limit, the call is blocked. In the static simulator of WP2 a call is blocked if the load after acceptance would exceed the UL and/or DL limit. In other words the 2 methods are not directly comparable. For a network of 1 cell it is possible however to analytically calculate the UL load factor or average DL transmission power and set the MoDySim CAC parameters such that they are the same as in the static simulator. Using

IPPI

PCIR rxrx

rx

γγ+

=⇒−

=1

(B.1)

and

ηε += rxPnI (B.2)

the UL capacity of one cell can be calculated analytically as:

εη

ηγ

γ 111

max

max −+=ULmax,n

(B.3)

where γ is the CIR target of the service, ηmax is the maximum noise rise (where noise rise is defined as total interference divided by noise), rxP is the received power at the base station and ε is the activity factor. The received power and the load factor depending on the number of users, n, is:


70/71

( ) rxth

thUL

thrx

PnNN

nN

Pεεγ +

−=−−

= − 111 load and (B.4)

where Nth is the thermal noise. The DL capacity of one cell can be calculated analytically as:

( )( )linktotal

1commonpilot

link 1losspath losspath )(

PnPn

PPNP

DL

th

×==

−×−×

×+×+= −

ηωγ

ω (B.5)

where we assumed that all users have a pathloss equal to ⟨path loss⟩ and ω is the DL orthogonality factor. Power control In the static simulator an ideal power control algorithm is used. In MoDySim there are several power control mode options: realistic power control versus ideal power control for the inner loop and outer loop control on or off. As the sanity checks are mainly meant to compare the two simulators, the MoDySim simulations used the ideal power control with outer loop off mode (fixed Eb/N0 target), as this mode is closest to the power control algorithm used in the static simulator.

B.2 Results

The results were obtained for the scenarios with one cell and for packet switched services in a static environment.

B.1.1 SC[1/omni_UL/PS_static]

In this scenario the network consists of one omni-directional cell and the traffic consists of UL traffic only. Each user sends 1 packet with an average size of 1800 kbyte, and the arrival rate is 0.0356 users per second. The users use a DCH with a bitrate of 128 kbps, which leads to an average number of users in the system of 0.0356 × 1800 × 8/128 = 4.005. The maximum UL power was set to 10 Watt, to prevent the UL maximum power from being a bottleneck. For more details see [D5.2], SC[1/omni_UL/PS_static]. In this scenario, γ = 0.093, ηmax = 2 and ε = 1. The UL load factor according to equation (B.4) and according to MoDySim for different numbers of users can be found in Table B-1. Table B-1: Load factors for a different number of users

n 4 5 6 loadUL (Analytically) 0.3385 0.4231 0.5077 loadUL (MoDySim) 0.3206 0.3978 0.4726

From equation (B.3) one can derive that in the static simulator a maximum number of 5 users is allowed in the system at the same time. From Table B-1 we can find that if we want to force MoDySim to also allow a maximum of 5 users we have to


71/71

stop admitting calls when the load at arrival is higher than 0.3978 (in the simulations 0.38 was used to be on the safe side). Unfortunately we did not have time to investigate why there is a difference between the MoDySim and analytical results. With a capacity of 5 users and a load of 4 users the Erlang formula gives a blocking probability of 19.9%. With MoDySim for the blocking rate we find a 95% realibility interval of [16.6%, 26.8%], the dropping probability is 0%.

B.1.2 SC[1/omni_DL/PS_static]

This scenario is like the SC[1/omni_UL/PS_static] scenario, apart from the fact that the traffic now consists of DL traffic only and the arrival rate is 0.7 users per second which yields an average number of users of 0.7 × 1800 × 8/128 = 78.75. The maximum total DL power is 20 Watt. The resulting maximum number of users using equation (B.5) is then 100, using an average pathloss of 4.3E-14 based on an average distance of 715m (users arrive in an area of 2000 by 1732 meters). However, the CAC parameters are set such that a call is blocked when at arrival the load is higher than 15 Watt, this results in a capacity of 93 users. The Erlang formula gives for 78.75 users and 93 channels a blocking probability of 1.92% and MoDySim gives a 95% confidence interval for call blocking of [3.1972%, 5.5224%] and [0.2272%, 0.5692%] for call dropping. A likely explanation for the difference between the analytical and MoDySim results is that for the analytical calculations we used an average pathloss, whereas in the simulations the users were evenly spread over the whole area. The average distance in the simulation was not checked.

contract number: ist-2000-28088ist-2000-28088-momentum-d53-pub momentum public 2/71 document history...

Documents