3g ran optimization

WCDMA Radio Access Network Optimization

LZT 123 8297 R1C © Ericsson 2006 - 1 -


STUDENT BOOK LZT 123 8297 R1C


- 2 - © Ericsson 2006 LZT 123 8297 R1C

DISCLAIMER This book is a training document and contains simplifications. Therefore, it must not be considered as a specification of the system. The contents of this document are subject to revision without notice due to ongoing progress in methodology, design and manufacturing. Ericsson assumes no legal responsibility for any error or damage resulting from the usage of this document. This document is not intended to replace the technical documentation that was shipped with your system. Always refer to that technical documentation during operation and maintenance.

© Ericsson 2006 This document was produced by Ericsson. • It is used for training purposes only and may not be copied or

reproduced in any manner without the express written consent of Ericsson.

This Student Book, LZT 123 8297, R1C supports course number LZU 108 6489 .

Table of Contents

LZT 123 8297 R1C © Ericsson 2006 - 3 -

Table of Contents

1 PERFORMANCE MONITORING OF A WCDMA RADIO ACCESS NETWORK.....................................................................9

INTRODUCTION..................................................................................13

KEY PERFORMANCE INDICATORS ..................................................15 PERFORMANCE MONITORING....................................................................17 QUALITY OF SERVICE ..................................................................................18 PERFORMANCE ANALYSIS..........................................................................20

WCDMA RAN OPTIMIZATION WORKFLOW .....................................21 PREPARATIONS ............................................................................................21 ACCESSIBILITY MODULE .............................................................................23 RETAINABILITY MODULE .............................................................................23 INTEGRITY MODULE.....................................................................................23

WCDMA RAN OPTIMIZATION MODULE WORKFLOW .....................24 PERFORMANCE MEASUREMENTS - STATISTICS.....................................24 PERFORMANCE ANALYSIS..........................................................................25 RECOMMENDATION & IMPLEMENTATION.................................................27 VERIFICATION OF CHANGES ......................................................................27

STATISTICAL TEST METHODS..........................................................28

2 DATA COLLECTION...................................................................33

DATA COLLECTION............................................................................37 BUSY HOUR...................................................................................................37 TYPES OF COUNTERS .................................................................................39 COUNTER CLASSIFICATION........................................................................41 STATISTICS SETUP ......................................................................................42 ACTIVATION...................................................................................................49

STATISTICAL DATA MART .................................................................50

3 SERVICE ACCESSIBILITY .........................................................51

ACCESSIBILITY ..................................................................................55

ACCESSIBILITY WORKFLOW ...........................................................55


- 4 - © Ericsson 2006 LZT 123 8297 R1C

WORST PERFORMING CELLS ..........................................................56

UE IN IDLE MODE...............................................................................58 PLMN SELECTION.........................................................................................59 CELL SELECTION..........................................................................................59 LA AND RA UPDATE......................................................................................60 PAGING ..........................................................................................................62 SYSTEM INFORMATION ...............................................................................66

RANDOM ACCESS..............................................................................68 UL OPEN LOOP POWER CONTROL ............................................................70

RRC CONNECTION SETUP................................................................72 EMERGENCY CALLS.....................................................................................73 MODULE MP LOAD........................................................................................73 ADMISSION CONTROL BLOCK ....................................................................74 LACK OF TRANSMISSION RESOURCES.....................................................90 LOAD SHARING .............................................................................................90 RADIO LINK SETUP.......................................................................................95

NAS PROCEDURES..........................................................................100 CM SERVICE REJECT.................................................................................100

RADIO BEARER SETUP...................................................................101 UE CELL RESELECTION DURING HANDOVER ........................................105 UE CELL RESELECTION.............................................................................106

TEMS INVESTIGATION FINDINGS...................................................108 PDP REJECTED...........................................................................................108 PPP LINK CONTROL TERMINATED ...........................................................108

4 SERVICE RETAINABILITY .......................................................111

RETAINIBILITY ..................................................................................115

RETAINABILITY WORKFLOW..........................................................115

WORST CELLS .................................................................................116 SPEECH .......................................................................................................116 VIDEO ...........................................................................................................116 PACKET SWITCHED DATA .........................................................................117

DROPPED CALLS.............................................................................117

Table of Contents

LZT 123 8297 R1C © Ericsson 2006 - 5 -

UL OUT OF SYNCH .....................................................................................118 CONGESTION ..............................................................................................126 WCDMA RAN HANDOVER ..........................................................................129 SOFT/SOFTER HANDOVER........................................................................130 HSDPA MOBILITY ........................................................................................146 INTER-FREQUENCY HANDOVER ..............................................................149 INTER-RAT HANDOVER..............................................................................152 MISSING NEIGHBOUR RELATIONS...........................................................155 OTHER REASONS .......................................................................................156

WNCS (WCDMA NEIGHBOURING CELL SUPPORT) .....................157

TEMS INVESTIGATION FINDINGS...................................................159 LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS....................159 INTER-RNC HANDOVER FAILURE.............................................................161 UE RELATED PROBLEM .............................................................................162

5 SERVICE INTEGRITY ...............................................................165

INTEGRITY ........................................................................................169

INTEGRITY WORKFLOW..................................................................169

WORST CELLS .................................................................................171 FORMULAS ..................................................................................................171

WCDMA POWER CONTROL ............................................................172 CRC – CYCLIC-REDUNDANCY CHECK .....................................................173 DL INNER LOOP ..........................................................................................174 UL INNER LOOP ..........................................................................................175 UL OUTER LOOP .........................................................................................176 POWER CONTROL ON HSDPA CHANNELS..............................................179

BLER PARAMETERS........................................................................180

PACKET THROUGHPUT...................................................................181

HSDPA ...............................................................................................194 HW AND SW PREPARATIONS....................................................................194 OPTIMIZING THE HSDPA............................................................................195

TEMS INVESTIGATION FINDINGS...................................................200 HIGH DL BLER - NO RAB SETUP ...............................................................200


- 6 - © Ericsson 2006 LZT 123 8297 R1C

HIGH DL BLER – DROPPED CALL .............................................................201

6 UETR AND GPEH .....................................................................203

UE TRAFFIC RECORDING (UETR) ..................................................207 UETR RECORDABLE MESSAGES AND MEASUREMENTS......................208 ADD A UETR SUBSCRIPTION PROFILE ....................................................210 RETRIVE THE UETR LOGFILES .................................................................214 ANALYZE THE UETR LOGFILES ................................................................214

GENERAL PERFORMANCE EVENT HANDLING (GPEH)...............219 INITIATION OF GPEH ..................................................................................220 GPEH FILES COLLECTION AND STORAGE..............................................222 GPEH FILE STRUCTURE ............................................................................223 GPEH FILE ANALYSIS USING RED............................................................227 GPEH FILE ANALYSIS USING TEMS .........................................................232

7 ABBREVIATIONS .....................................................................237

8 APPENDIX A: CELL PARAMETER AND CONFIGURATIONS ..................................................................243

APPENDIX B: FORMULAS FOR KEY PERFORMANCE INDICATORS.............................................................................249

KEY PERFORMANCE INDICATORS ................................................253

ACCESSIBILITY ................................................................................255 SERVICE SUCCESS SETUP RATE ............................................................255 IDLE MODE ..................................................................................................257 RANDOM ACCESS ......................................................................................257 ADMISSION CONTROL ...............................................................................258

RETAINABILITY ................................................................................260 DROPPED CALL RATE................................................................................260 MINUTES PER DROP ..................................................................................261 HANDOVER FAILURE RATE .......................................................................262 INTER-FREQUENCY HANDOVER ..............................................................263 IRAT HANDOVER.........................................................................................264 CONGESTION ..............................................................................................265 OTHER REASONS .......................................................................................265

INTEGRITY ........................................................................................267

Table of Contents

LZT 123 8297 R1C © Ericsson 2006 - 7 -

BLER.............................................................................................................267 THROUGHPUT.............................................................................................267

APPENDIX C: PREDEFINED STATISTICS PROFILES COUNTERS...............................................................................271

SUMMARY.........................................................................................275

APPENDIX D: TABLE OF FIGURES.................................................291

APPENDIX E: INDEX.........................................................................297


- 8 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

1 Performance Monitoring of a WCDMA Radio Access Network

LZT 123 8297 R1C © 2006 Ericsson - 9 -


Objectives

Upon completion of this chapter the student will be able to:

• Explain the difference between RAN Tuning and RAN Optimization

• Describe how to monitor the RAN performance

• Describe the definition of Network Quality

• Describe the general optimization process


- 10 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank


LZT 123 8297 R1C © 2006 Ericsson - 11 -

INTRODUCTION..................................................................................13

KEY PERFORMANCE INDICATORS ..................................................15 PERFORMANCE MONITORING....................................................................17 QUALITY OF SERVICE ..................................................................................18 PERFORMANCE ANALYSIS..........................................................................20

WCDMA RAN OPTIMIZATION WORKFLOW .....................................21 PREPARATIONS ............................................................................................21 ACCESSIBILITY MODULE .............................................................................23 RETAINABILITY MODULE .............................................................................23 INTEGRITY MODULE.....................................................................................23

WCDMA RAN OPTIMIZATION MODULE WORKFLOW .....................24 PERFORMANCE MEASUREMENTS - STATISTICS.....................................24 PERFORMANCE ANALYSIS..........................................................................25 RECOMMENDATION & IMPLEMENTATION.................................................27 VERIFICATION OF CHANGES ......................................................................27

STATISTICAL TEST METHODS..........................................................28


- 12 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank


LZT 123 8297 R1C © 2006 Ericsson - 13 -

INTRODUCTION This book is aimed for network engineers who need to understand the main issues in optimizing an Ericsson WCDMA radio network. It explains the different steps and tools needed to achieve this from an Ericsson perspective. Common radio related problems are presented and analyzed and the purpose is to create a deeper understanding of radio network optimization, resulting in improvements in radio network performance.

RAN tuning is done to provide operators with a detailed understanding of the underlying problems to address, such as network design, UEs and system. It is performed when all necessary nodes in the area are installed and operational and when the network is stable and not yet commercially used. It is also performed when new sites are installed in already commercially launched areas.

Figure 1-1 Overview of the Radio Network evolution

RAN Optimization is starting when the radio network has been tuned RAN Optimization identifies and solves radio network problems in live networks together with the rising of subscribers in the network.


- 14 - © Ericsson 2006 LZT 123 8297 R1C

Data from various system sources are analyzed and recommendations are made. Ericsson offers different tools that are used such as performance statistics, User Equipment Traffic Recording (UETR), Cell Traffic Recording (CTR) and General Performance Event Handling (GPEH). Information from drive tests as well as subscriber feedback is also used.

– TuningEstablish network performance mainly using drive tests:

– To ensure it is possible to drive in the network without dropping calls– To ensure it is possible to set up calls in the coverage area

Analyze and describe underlying problems related to:– Design– UEs– Systems

– OptimizationIdentify and improve radio network problems using statistics, recordings and eventsEstablish subscriber behavior and perception

Ensure that traffic growth can be handled

Figure 1-2. The difference between RAN tuning and RAN optimization

RAN Tuning is required to ensure good network quality and identifies and solves radio network problems after the network has been installed.

RAN tuning is done to provide operators with a detailed understanding of the underlying problems to address, such as network design, UEs and system. It is performed when all necessary nodes in the area are installed and operational and when the network is stable and not yet commercially used. It is also performed when new sites are installed in already commercially launched areas.

RAN Optimization can result in changes in the parameter setting for the different functionalities such as idle mode, radio connection supervision, power control, capacity management, handover and channel switching.


LZT 123 8297 R1C © 2006 Ericsson - 15 -

KEY PERFORMANCE INDICATORS To efficiently manage the performance of a cellular network, one must be able to navigate through the data that is collected in the network and determine the areas where improvement is needed. Due to the vast amount of performance statistical data that is collected by the WCDMA network, it can be confusing to correlate all the data for the entire network and build a coherent picture. The solution is to extract and calculate Key Performance Indicators (KPIs), which are directly connected to the quality.

Observability covers all functions in UTRAN that serves to monitor and analyze the performance and characteristics of the UTRAN system. This can be done on various levels with different target groups and requirements. The figure below illustrates a model for Observability in UTRAN.

Figure 1-3 UTRAN Observability Model

The Key Performance Indexes represents the End-user perception of a network on a macro level and are of typical interest for top-level management as well as others within an operator. These numbers are typically used to benchmark networks against each other and to detect areas of problem.

The Performance Indicator level represents information on a system level that does not explicitly qualifies in the macro level end-user perspective model, but can indicate whether the system performs good or bad. Performance Indicators do not necessarily give enough details to allow a full detailed troubleshooting. The data can also be used for planning and dimensioning. This data, typically PM counters and also RES counters, is collected continuously.


- 16 - © Ericsson 2006 LZT 123 8297 R1C

The Procedure level represents deeper troubleshooting and measure system characteristics measurements. It involves measurement on signaling and procedure/function levels to investigate problems detected on higher levels. The amount of data on this level is enormous and these measurements are generally user-initiated for a specific purpose and area of the network, thereby limiting the scope of the measurements. The typical source for this data is GPEH events and the recording functions UETR and CTR.

Examining the KPIs for a network is a primary function of day-to-day performance management. This will give the operator the information regarding how the network is functioning:

• Does the network fulfill the performance requirements?

• Has the performance changed? Improved? Degraded?

• Where are the problem areas?

• What types of problems are being experienced?

Network performance monitoring is illustrated in Figure 1-4 below.

Goal:Perceive the performance at a glance

Solution:• Extract and calculate, of all available information, Key Performance

Indicators (KPI), which are directly connected to the quality

• Information about why the network is performing as it is does not need to be provided during this step

Good?

Bad?Information

Overflow!!!

Figure 1-4 Network performance Monitoring

After determining the most pressing issues, the operator can then utilize other statistical and event measurements to isolate issues, troubleshoot the causes, and take the necessary corrective actions. The operator can then use the KPIs to verify that the corrective actions taken resolved the performance issues.


LZT 123 8297 R1C © 2006 Ericsson - 17 -

PERFORMANCE MONITORING

The sources for performance monitoring are:

• Statistical information counters from the network elements

• Traffic recordings (e.g. UETR, GPEH)

• Downlink information from single test mobiles (e.g., TEMS Investigation)

• Downlink information from several special mobiles distributed to selected users

• Autonomous measurements with special mobile / fixed units (e.g. TEMS Automatic)

• Customer input (e.g., trouble tickets)Since drive testing can be expensive, it isbeneficial to get the information to monitor the radio network performance from the network elements, see Figure 1-5 below.

UE

UEUE

M SC SGSN

RNC RNC RNC

RBSRBSRBSRBSRBSRBS

Network Inform ation M obile Inform ation

Figure 1-5. Measuring Network Quality

A great deal of performance management information is available in the Core Network (CN) and the Universal Terrestrial Radio Access Network (UTRAN). Some information, such as idle mode and geographic information, is only directly available from the User Equipment (UE). This information that is not directly available from the network elements can often be estimated by other information that is collected from the network elements.


- 18 - © Ericsson 2006 LZT 123 8297 R1C

RBS

RNC

RNC

TEMS

Core Network

RBS

RBS

Radio AccessNetwork

IubIub

IuIur

Uu

RANAG

OSS-RC

Mub

MutMur

Mun

Other Management

Systems

Mun

NetworkManagementEnvironment

UE User EquipmentRNC Radio Network ControllerRBS Radio Base StationOSS-RC Operation Support System – Radio CoreTEMS Test Equipment Mobile System RANAG Radio Access Network AggregatorUE

Uu

UE

Figure 1-6. WCDMA RAN Architecture

Note that the counters are implemented in the network elements (e.g. Radio Network Controller (RNC), Radio Base Station (RBS) and Radio Access Network Aggregator (RANAG), as illustrated in Figure 1-6 above. Hence, statistics are generated by the network elements but stored in a database within OSS. A post-processing tool is needed for analyzing the data and for generating reports.

QUALITY OF SERVICE

The definition of Quality of Service (QoS) is how the user is satisfied with the overall service. The QoS concept consists of six different requirements (see Figure 1-7):

Service Accessibility Performance

The ability of a service to be obtained within specific tolerances and other given conditions, when requested by the user. E.g. to be able to get in contact with the network. In other words, the operator has to observe the call setup success rate, paging success rate, blocking probability etc.

Service Retainability Performance

The ability of a service, once obtained, to continue to be provided under given conditions for the requested duration. E.g., the operator has to observe the drop call rate.

Service Integrity Performance


LZT 123 8297 R1C © 2006 Ericsson - 19 -

The degree to which a service is provided without excessive impairments, once obtained. E.g., the operator has to observe the BLER and the throughput.

Service Support Performance

The ability of the operator to provide the service and assists in its utilization.

Service Operability Performance

The ability of a service to be successfully and easily operated by a user

Service Security Performance

The protection provided against unauthorized monitoring, fraudulent use, malicious impairment, misuse, human mistake and natural disaster.

These six QoS areas are illustrated in Figure 1-7 below.

User (subscriber)

ServiceIntegrityperformance

Qualityof service

Service Support

performance

ServiceOperability

performance

ServiceAccessibilityperformance

ServiceRetainabilityperformance

Serveability performance

Provider (operator)

Service Security

performance

Quality of Service

Network Performance

Figure 1-7. Network Quality of Service (QoS).

By continuously measuring the QoS through monitoring the KPIs, the operator should be able to:

• Detect problems in the network, and determine if the quality requirements are not fulfilled.


- 20 - © Ericsson 2006 LZT 123 8297 R1C

• Locate problems geographically by isolating which area, cell, or transceiver shows a problem.

• Detect areas for expansion by monitoring traffic levels and determining where hardware addition is needed.

• Identify cells that are “money makers” as a function of traffic carried. This is important in determining the severity of a cell being out of service.

PERFORMANCE ANALYSIS

Performance Analysis is based on statistics (counters), field DL measurement (TEMS), recordings (e.g., CTR and UETR) and events (GPEH). The measurement results are correlated with information as to how the network is defined (e.g., Configuration Management (CM) data, CM change log) and how the hardware is performing (e.g., Alarm logs).

While Performance Monitoring is a function of detecting and localizing performance issues, Performance Analysis is a function of determining the reason(s) for the performance issues and possible solutions. Some of the areas that might need to be addressed are illustrated in Figure 1-8 below: yWhat creates the problem?• How can the problem be solved

Problems related to the radio network:• Dimensioning, Planning, and Architecture• Hardware Problems• Uplink (UL) and/or Downlink (DL) Interference• Handover (HO)/Inter Radio Access Technology (IRAT) HO• Pilot Pollution• Idle Mode Parameters• Code Allocation• Admission Control• Connection Handling• Power Control• Security• Other Cell Parameters

Figure 1-8 Performance Analyses


LZT 123 8297 R1C © 2006 Ericsson - 21 -

WCDMA RAN OPTIMIZATION WORKFLOW The main purpose of optimizing a network is to ensure that any service affecting faults related to the traffic load in the network after initial tuning are corrected.

Figure 1-9 Optimization Process

The WCDMA RAN Optimization activity includes the following main tasks shown in Figure 1-9

PREPARATIONS

Parameter Settings

In order to find this problem and to monitor it is to do a parameter check. There are many problems that can be reduced from start if this is done. (e.g. wrong power settings, wrong handover parameter etc.)

Neighbor Relations

In order to find this problem and to monitor it is to do a neighbor relations check. There are many problems that can be reduced from start if this is done. If the neighbors are correctly defined, less dropped calls will occur due to missing neighbors or too long neighbor lists. Single defined neighbors will also be identified which reduces the dropped calls.

Integrity module

Retainability module

Accessibilitymodule

Preparations

Consistency Check

• Parameters

• Nei

Idle mode Random Access RRC Connection NAS RAB Assignments

HO Performance Neighbour

BLER Throughput SF Usage


- 22 - © Ericsson 2006 LZT 123 8297 R1C

Scrambling codes

In order to find this problem and to monitor it is to do a parameter check. If the scrambling codes are reused to often this can affect the accessibility but also the handover performance due to the UE problem to detect the interfering SC.

Statistics

In order to find the problems in the network, the counters in the NE must be activated, which means that profiles have to be created. More information about this can be found in chapter 2, Data Collection.


LZT 123 8297 R1C © 2006 Ericsson - 23 -

Cell Downtime

In order to select the worst performing cells, all cells have to be available for the statistics. If some maintenance has been done on some of the cells, this could have a large impact on the network statistics. These cells should therefore be excluded from the statistics during the maintenance period.

pmCellDowntimeMan - shows how many seconds during the measurement period cell was manually blocked. During manual downtime cell will not be available for service -

pmCellDowntimeAuto - shows how many seconds during the measurement period cell was automatically blocked. During downtime cell will not be available for service.

Alarms

Before looking for the problem causing sites it is important to fully understand the sites performance in regards of HW faulty. If checking the cells alarms it would give a good indication whether there is a hardware problem at some of the sites.

ACCESSIBILITY MODULE

During this module the WCDMA RAN Network accessibility is analyzed. The UE Idle mode behavior as well as the Random Access process is analyzed in order to make the best performance of the network. More information about this module can be found in chapter 3, Service Accessibility

RETAINABILITY MODULE

During this module the WCDMA RAN Network retainability is analyzed. The UE mobility behavior as well as the handover performance is analyzed in order to make the best performance of the network. More information about this module can be found in chapter 4, Service Retainability

INTEGRITY MODULE

During this module the WCDMA RAN Network integrity is analyzed. The BLER is analyzed in order to make the best performance of the network. More information about this module can be found in chapter 3, Service Integrity


- 24 - © Ericsson 2006 LZT 123 8297 R1C

WCDMA RAN OPTIMIZATION MODULE WORKFLOW Each module in Figure 1-9 has an own workflow which is shown in the Figure 1-10.

Figure 1-10. Module process

The process is repeated for each module, where each module represents one area of the service Observability blocks, like accessibility, retainability and integrity (see Figure 1-7. Network Quality of Service (QoS).).

PERFORMANCE MEASUREMENTS - STATISTICS

Radio network statistics data, i.e. RNC and cell level data should be collected during both busy hours and normal traffic hours. For performance statistics (counters) normally a predefined system profile is up and running in RNC. If this predefined system profile does not cover all counters that are needed for performance monitoring, a user-defined profile should be setup and used during analysis.

The following performance areas should be in the performance statistics profile (predefined system profile or/and user-defined profile):

RAB Handling, Admission, Admission Monitoring, Cell Availability, Channel Quality, Congestion, Handover, Inter Frequency Handover, IRAT Handover, Processor Supervision, RRC Handling, Iur Channel Handling, Cell update, Connection supervision and Channel Switching

Transport network performance statistics (counters) should be collected during the same period that radio network performance statistics is collected. Aal2Ap and VplTp are Managed Objects of interest for transport network that should be monitored.

Performance Measurements

Performance Analysis

Recommendation &

Implementation

Verification of changes

Other M

odules


LZT 123 8297 R1C © 2006 Ericsson - 25 -

The duration of data collection should be for 3-4 days, 16-18 hours including the busy hours for each day. Data related to the maintenance window’s hour should not be used for analysis.

OSS- RC

OSS-RC is needed for creating of new performance statistics or/and UETR/GPEH profiles. The defined profiles will also be activated from OSS. ROP files will be fetched automatically and stored in OSS-RC. Normally the data should be found in the following directors:

Performance Statistics .xml files /var/opt/ericsson/nms_umts_pms_seg/segment1/SubNetwork

Performance Recording .bin files /var/opt/ericsson/nms_umts_red_reg/downloaded

For further information on location of the rop files, please see the PM, Subscription Profiles and Performance Monitoring, Function Description - 1/155 34-APR 901 91/3)

PERFORMANCE ANALYSIS

During this performance analysis, KPI from the Performance measurements are evaluated in order to find problem cells or problem geographical areas.

Worst cells

The worst cells are divided into several types of “worst performing cells” and should also be optimized in this specific order.

1. Random access function. The methodology to optimize the random access procedure is very passive due to lack of performance monitoring counter. What can be done is just to adjust the random access parameters and then to observe the variations. Is the number of RRC connection request increased after modifying random access parameters? Is the number of missing RACH message reduced?

2. Accessibility load-sharing (inter-frequency and directed retry to GSM). Is the number of denied admission high in the network?

3. RAB functionality. Identify RAB’s that are not performing in line with targets, regarding retainability and integrity.


- 26 - © Ericsson 2006 LZT 123 8297 R1C

Review radio parameter settings (points below). Make consistency check of the parameter settings and verify settings against Ericsson default/recommended values.

Site configuration

Collect the site and antenna configuration information for every type of these worst cells.

Geographic location

Check on map where the worst performing cells are located. Could they be dependent on each other?

Drive Tests

Normally performance statistics used in the first place to give an overall RNC status and show worst performance cells. During the troubleshooting of call setup problem for worst performing cells, other performance measurements are also needed in order to provide more detailed information to facilitate analysis work.

Trouble shooting drive test with TEMS Investigation will be used whenever it is needed to get detailed DL information.

UETR, GPEH, CTR

Performance Recording applications are used to collect performance events and radio related measurements used for detailed network performance analysis, troubleshooting and network optimization.

UETR (User Equipment Traffic Recording) will be used in combination with TEMS Investigation drive test data to provide UL information (excluding reference drive test). UETR performance recording data will be collected after the worst performing cells are identified.

If more detailed information is needed, GPEH (General Performance Event Handler) can be used together with the TEMS Visualization. Then multiple calls on the cells guide the optimizer in the right direction in order to implement the changes needed.

GPEH is an optional feature and not all operators will have purchased the feature.


LZT 123 8297 R1C © 2006 Ericsson - 27 -

Activate GPEH for more information if needed. GPEH should be used for providing detailed information for worst performing cells. GPEH performance recording data will be collected after the worst performing cells are identified.

CTR (Cell Traffic Recording) is a recording of selected performance events, and/or radio related measurements, covering specific cell, usually referred to as the recording area. The main difference between CTR and UETR is that in UETR it is the operator who decides which User Equipments (UEs) to record, while in CTR any UE in a selected area may be recorded. The RNC adds each received measurement and event into the CTR or UETR file (depending on which is activated). The recordings are then accumulated into files for the duration of Report Output Period (ROP), and are stored in the network elements (NEs). The duration of ROP is 15 minutes.

RECOMMENDATION & IMPLEMENTATION

Generally, there will be two types of finding from the data analysis. Either the findings are related to Cell/RBS/RNC parameter settings, or they are related to hardware configuration such as antenna tilt or antenna height etc. A brief report should be produced and presented to the customer, outlining the findings, recommendations and arguments to justify the network changes. The report should provide the customer with necessary input data to be able to understand the nature of the problem, and why the Change Requests (CR) is needed.

For every change which is identified as necessary a CR should be raised and submitted to the RND or/and the Operation and Maintenance organization and be agreed upon. Short lead times are expected for implementing short-term changes such as parameters, whilst long-term changes such as hardware configurations may require lead times, which fall outside the time frame of the retainability service.

VERIFICATION OF CHANGES

After implementation of changes (parameters, hardware etc) network performance should be monitored in order to verify the impact of changes. Performance statistics data should be collected after change implementation and evaluate the network performance in problem areas and RNC. If for any reason the implemented changes caused any degradation of connection setup in RNC or/and concerned problems areas, the changes should be rolled back and other possible solutions need to be investigated.


- 28 - © Ericsson 2006 LZT 123 8297 R1C

The statistic data should be collected again after both trouble shooting and function. The results should be compared before and after optimization. The paging performance should be checked if it has been improved after previous changes.

STATISTICAL TEST METHODS When performing measurements in a radio network it is important to understand that the system performance can change drastically during a day. When comparing data sets before and after a change it is important to select the measurement occasions so that the different occasions have as equal conditions as possible.

There are two commonly used statistical methods when comparing measurements before and after a change in a radio system i.e. adjustment of a parameter or similar.

The statistical test methods should give some information on how to judge whether or not a performance improvement has been reached in the system after the change.

However these test methods presented below are recommended to use when an improvement after a change in a network is not very obvious statistically due to hourly/daily fluctuation of data. Whenever an improvement is obvious statistically in a network after a change, there is no need to use any test method.

Student’s t-test

Student's t-test, often known simply as the t-test, is one of the most commonly used statistical tests for testing a hypothesis based on a difference between sample means. The t-test determines a probability that two populations are the same with respect to the variable tested. It comes in two versions, the paired t-test and the unpaired t-test.

Both versions are used to test the hypothesis that some variable differs between two groups, but the paired test is specifically used when each data point in one group corresponds to a matching data point in the other group. The unpaired t-test is more general.

The t-test can be performed knowing just the means, standard deviation, and number of data points.


LZT 123 8297 R1C © 2006 Ericsson - 29 -

The unpaired t-test the most general technique that can be used to test whether a variable differs between two groups, and does not require that the two groups be paired in any way. The samples can also be of different sizes. In simple terms, the t-test compares the actual difference between two means in relation to the variation in the data expressed as the standard deviation of the difference between the means.

Unpaired t-test process

For the t-test for independent samples, the same number of data points in each group is not needed i.e. the sample taken before may have more data point than the sample taken after. The assumption is that the population follows a normal distribution, or more correct, a t-distribution when the variances are estimated.

Below is an example of a network performance improvement activity where a parameter change to reduce dropped call has been verified for the same RNC during different hours before and after parameter change.

Hour Drop

Before Drop After1 3.93 0.9 2 2.82 1.33 3 2.72 1.1 4 2.26 1.03 5 2.8 1.81 6 3.59 2.58 7 1.73 0.74 8 2.79 1.86 9 2.83 1.65

10 2.82 2.13 11 1.24 3.05 12 2.19 13 3.75

Table 1- Speech Call Drop for RNC

1. Arrange the data under consideration in two columns as in Table 1.

It is assumed that Column Before (column B) contains the sample before and Column After (Column C) contains the sample after a network change.

2. From the Tools option at the top of the Excel screen, select Data analysis to display Analysis options. If Data Analysis is not available, load the Analysis ToolPak from Add-Ins under the tools menu.


- 30 - © Ericsson 2006 LZT 123 8297 R1C

3. From the drop-down menu select t-Test: Two-Sample Assuming Equal Variances

4. Click OK and enter cells B2-B14 for Variable range 1.

5. Select cells C2-C10 for Variable range 2.

6. Set Hypothesized Mean difference = 0

7. Tick the label box

8. Enter a free cell (e.g. E2) for the output range. Choose the top-left cell of the area where the results of the analysis will be displayed. Then click OK and the printout appears as in Table 2.

9. The test will ask what is the probability of obtaining our given results by chance if there is no difference between the means i.e. our Hypothesized Mean Difference is zero or our null-hypothesis zero difference between the samples.

Two-Sample Assuming Equal Variances

Before After Mean 2.7146 1.6527 Variance 0.5541 0.5305 Observations 13 11 Pooled Variance 0.5434 Hypothesized Mean Difference 0 Df 22 t Stat 3.5163 P(T<=t) one-tail 0.0010 t Critical one-tail 1.7171 P(T<=t) two-tail 0.0019 t Critical two-tail 2.0739

Table 2- Output from unpaired t-test

As output from the analysis, the column means are given, the variances of each sample, the number of observations, the hypothesized mean difference, the degree of freedom (df), the calculated t-value (t Stat) and four other entries.

The first two of these refer to a one-tailed t-test i.e. if testing only that one particular mean is larger or smaller than the other. The final two entries refer to a two-tailed test, where the direction of the test i.e. is not specified, we do not know if the performance will be better or worse a priori.


LZT 123 8297 R1C © 2006 Ericsson - 31 -

For most purposes, the two-tailed test is used. In each case the probability, P(T<=t) are shown, that the calculated t-value is equal to or less than the tabulated t-value, shown as the t critical.

If the P-value associated with the t-test is small i.e. below the risk level of alpha = 0.05, there is evidence to reject the null hypothesis in favor of the alternative. In other words, there is evidence that the means are significantly different than assumed in out null hypothesis.

If the P-value associated with the t-test is not small i.e. P(T<=t) > 0.05, there is not enough evidence to reject the null hypothesis, and the conclusion are that there is evidence that the means are not different from the hypothesized value. Thus the reported P(T<=t) two-tail gives the probability of getting the calculated t-value by chance alone.

In the example that probability is lower than the risk level of alpha = 0.05, so the sample means are significantly different. It can be stated that the result is 0.19% risk that we reject a null-hypothesis that is true. The conclusion is thus that the drop rate is significant lower afterwards on 5 % risk level.


- 32 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 33 -

2 Data Collection

Objectives

Upon completion of this chapter the student will be able to:

• Understand what types of counters are available

• Understand the counter classification

• Explain how to activate the counters

• Understand how to calculate busy hour


- 34 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 35 -

DATA COLLECTION............................................................................37 BUSY HOUR...................................................................................................37 TYPES OF COUNTERS .................................................................................39 COUNTER CLASSIFICATION........................................................................41 STATISTICS SETUP ......................................................................................42 ACTIVATION...................................................................................................49

STATISTICAL DATA MART .................................................................50


- 36 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 37 -

DATA COLLECTION Performance Statistics are continuously collected from all Network Elements (NE) and stored persistently in Operation Support System, Radio and Core (OSS-RC). Statistics are mainly used for the detection of problem areas and for monitoring the performance of the network on a daily basis.

The complete WCDMA Radio Access Network (RAN) Performance Management (PM) functionality receives support from all WCDMA RAN nodes:

• Radio Base Station (RBS)

• Radio Network Controller (RNC)

• Radio Access Network Aggregator (RANAG – RXI)

• OSS-RC.

The traffic nodes provide the performance information through a file interface. This information is collected by OSS-RC. Performance Management Statistical files are stored in OSS-RC for a predefined period of time, where they can be retrieved by interested users. Open interfaces are provided so that report generators and visualizing tools can retrieve the necessary data.

BUSY HOUR

The busy hour (BH) can be evaluated per cell for all selected cells. Two alternative approaches can be used for the BH calculation. In both cases, the counters values must be aggregated per cell and per hour (that is for four Recording Output Periods, ROP).

• BH calculation based on the total number of successful RRC Connection requests

• BH calculation based on the total payload concerning the traffic carried in both UL and DL on dedicated and common channels, both for PS and CS services.

In the first case, the BH evaluation can be based on the pmTotNoRrcConnectReqSuccess counter. This counter increases at every successfully established RRC connection. Per cell and within the period under observation, the counter values must be aggregated per hour (normalized to the available ROP periods).


- 38 - © Ericsson 2006 LZT 123 8297 R1C

The BH must be defined as the hour for which the aggregated value is maximum.

In the second case, the BH can be evaluated by considering the total payload considering the traffic carried both in UL and DL on dedicated and common channels (both for PS and CS services). However there are no payload counters specific for HSDPA. The payload traffic counters carried by dedicated and common channels that can be considered for the BH calculation are specified in the table below.

Radio Connection type UL Payload counter DL Payload counter Speech pmUlTrafficVolumeCs12 pmDlTrafficVolumeCs12 PS64/64 pmUlTrafficVolumePs64 pmDlTrafficVolumePs64 PS64/128 pmUlTrafficVolume Ps128 pmDlTrafficVolume Ps128 PS 64/384 pmUlTrafficVolume Ps384 pmDlTrafficVolume Ps384 CS 57.6 (streaming) pmUlTrafficVolumeCs57 pmDlTrafficVolumeCs57 CS 64 (UDI) pmUlTrafficVolumeCs57 pmDlTrafficVolumeCs57 Speech/PS 64 multirab pmUlTrafficVolumeCs12Ps64 pmDlTrafficVolumeCs12Ps64 PS Common pmUlTrafficVolumePsCommon pmDlTrafficVolumePsCommon

Table 2-1. Counters used for BH calculation

Figure 2-2. Example of traffic distributed over 10 days

Please note that the BH can occur at different times for different types of services, as shown in the figure above

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 39 -

Please note that counter values for all cells might not be available for all of the days and not always for all ROP periods during the day. This could be due to that the RBS can be down, manually or automatically and therefore not available regarding carrying traffic.

TYPES OF COUNTERS

The names of all the counters created in NEs start with pm, while the names of the OSS-RC calculated statistics counters in start with cm.

The following seven types of counters are available in a WCDMA system:

Peg counters

A Peg counter is a counter that is increased by one at each occurrence of a specific activity.

Gauge counters

A Gauge counter is a counter that can be increased or decreased depending on the activity in the system. This can be a ATM Adaptation Layer 2 Access Point Counters, pmExisOrigConns, which is the number of existing connections for the AP originating in this node.

Accumulator counters

An Accumulator counter is a counter that is increased by the value of a sample. It indicates the total sum of all sample values taken during a certain time. The name of an accumulator counter begins either with pmSum or pmSumOfSamp.

Scan counters

A Scan counter is a counter that is increased by one each time the corresponding accumulator counter is increased. It indicates how many samples have been read, and added to the related accumulator counter. A scan counter can therefore be considered a specific kind of peg counter.

Due to these types of counters, it is possible to get the average value of all samples by dividing the accumulator counter by the scan counter. The name of a scan counter begins with pmSamples or pmNoOfSamp.


- 40 - © Ericsson 2006 LZT 123 8297 R1C

ATrigAcc counters

ATrigAcc counter is a counter that is increased by the value of a sample and the sampling is only done when there is some activity. It indicates the total sum of all sample values taken during a certain time. The sampling is only done if there is some activity ongoing for the measured entity. The name of an TrigAcc counter begins with pmSumAct.

ATrigAcc counters

ATrigScan counter is a counter that is increased by 1 each time the corresponding TrigAcc counter is increased. It indicates how many samples have been read, and added to the related TrigAcc counter. The sampling is only done if there is some activity ongoing for the measured entity. A TrigScan counter can therefore be considered a specific kind of peg counter. Due to these types of counters, it is possible to get the average value of all samples by dividing the TrigAcc counter by the trigScan counter. The name of a TrigScan counter begins with pmSamplesAct.

Probability Density Function counters

A Probability Density Function (PDF) counter is a list of range values. A value is sampled (read) periodically. If the value falls within a certain range, the range counter for that range is increased. All range counter values are collected and stored in a ROP file at the end of each reporting period.

For example, if SIR values are split into three ranges: Range1 = [-11 dB – -4 dB], Range2 = [-4 dB – +4 dB], Range3 = (+4 dB – +20 dB], and a value is read every 3 minutes over a 15 minute period (values = -10, -3, +5, +5, +6), then the three Range Counters are reported as RangeCounter1 = 1, RangeCounter2 = 1, RangeCounter3 = 3

Figure 2-3. Example of statistics from a PDF counter

Discrete distributed measurements

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 41 -

Discrete distributed measurements (DDM) are series of values recorded during a reporting period. Each series of values may be of one of the following measurement types:

• Accumulated over a measurement period and read at the end of each measurement period (a gauge or peg counter)

• Averaged over the duration of a measurement period

• Read at a specific time (the measurement time), within the measurement period (at a specific frame)

• At the end of a series of consecutive measurement periods (the reporting period) all measurement values are collected and stored in a ROP file.

For example, if a SIR value is read every 3 minutes over a 15–minute period (values = -10, -3, +5, +5, +6), then 5 DDM measurements are reported as Meas1 = -10, Meas2 = -3, Meas3 = 5, Meas4 = 5, Meas5 = 6.

Calculated Statistics counters

A Calculated Statistics counter is a counter whose value is determined by other counters. The calculation is performed in the OSS-RC Statistics database. The ROP files are opened in order to be transferred into the database and the calculations are made by the database itself during this process. This means that these counters are not available when the Statistics Database is not present.

Note: The names of all the counters created in NEs start with pm, while the names of the OSS-RC calculated statistics counters in start with cm.

COUNTER CLASSIFICATION

There are two general classifications of the statistic counters. First, they can be grouped depending on where they are generated, that is at which NE or they can be grouped depending on the area of interest that is if they are:

• Radio Network – RNC specific counters

• Radio Network – RBS specific counters

• Transport Network counters.


- 42 - © Ericsson 2006 LZT 123 8297 R1C

In the following Figure, the grouping of counters into different NE and different areas of interest is shown.

Table 2-4. Grouping the counters based on their NE Origin (SDM = Statistical Data Mart)

STATISTICS SETUP

In order to monitor the statistics counter values throughout the time, specific counters have to be active. Only when a counter is active values are generated, collected and can be analyzed.

An overview is presented of the counter activation process using the OSS-RC GUI but please note that it is also possible to activate counters through the CORBA interface.

Statistics profiles

For the activation of one or more counters the user has to define a statistics profile. A statistics profile is an entity in the OSS-RC GUI that helps users to manipulate counter administration. The process of creating a new statistics profile is shown in the following figure.

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 43 -

Figure 2-5. Statistics profile activation

One profile is typically defined in the steps shown corresponding to the figure above:

1. NE type (RNC, RBS or RXI)

2. One or more NE instances

It is possible to include one, more or all NE instances into a profile. All the actions performed at the profile will be automatically performed for all the selected NE.

Note that if a new NE is setup in the RAN, it will not automatically be included in the existing user-defined profiles. In P4 the user can modify an existing profile and adding NE without suspending the profile (see 4.3.4 Modify Active (Admin state) Statistics Subscription Profile in doc USER GUIDE 1/1553-APR 901 91/3 Uen B)

3. MO Class (Standard) or MO Instance type (Cell/Cell Relation)


- 44 - © Ericsson 2006 LZT 123 8297 R1C

The MO Class is normally selected, that is all the existing MO Instances are wanted for a statistics profile. In addition to this it is possible to select only specific cells to be performance monitored. This choice is available only for the RNC for Utran Cell and Utran Relation counters.

4. Cell selection

If the MO Instance type is selected for a profile in the previous step, it is possible to select the wanted cells. Only for these cells, the counters (selected in the next step) will be possible to handle through the profile.

Note that the MO instance selection is always done on the cell level by the user. The selection of Utran Relations is done automatically based on the cell selection in the following way – all the Utran Relations where the selected cells appear as best serving (soft/softer handover) or as source (inter-frequency handover) cells are selected.

5. One or more selected counters (only the counters available to the NE type of the profile)

Note that for RNC specific and Transport Network counters it is possible to include and activate more than once the same counter for the same NE for the same MO Instance. This would result in duplicating the data in the statistics ROP files, causing unnecessary increase of their size. It is highly recommended that each counter is activated only once, that is through only one profile. For RBS specific counters this is not valid – duplicated subscriptions to already active counters will fail.

6. Scheduling

A user-defined statistics profile can be defined as:

• Continuous – the profile state changes only by the user

• Scheduled – the profile starts at a specified point in time and stops after a specified duration

• Periodical – the profile starts at a specified point in time, stops after a specified duration. This is repeated a specified number of times in regular intervals.

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 45 -

Example: The profile “XYZ” is an RNC type profile of type Standard (MO Class) for the RNC01 and RNC02 and is including the counters pmCellDowntimeAuto and pmCellDowntimeMan. It is of type continuous. Once created, the profile may be resumed (state changed to active) or suspended (state changed to suspended). It can also be modified, but only while in state suspended.

User-defined and Pre-defined profiles

When a profile is created by a user in OSS-RC it is called user-defined profile. As opposed to user-defined there are pre-defined profiles, which are available immediately after the start-up of new NEs. They do not have to be specially created and they cannot be modified. In the table below, the list and description of pre-defined profiles is given.

Network Element

Pre-defined Profile

Content

RNC Primary Counters needed for main Radio Network KPIs

RNC Secondary Most important counters for troubleshooting

RBS Primary Most important Radio Network counters on the RBS level

Table 2-6. Pre-defined profiles

In the following table, the main differences between user-defined and pre-defined profiles from the user perspective are shown.

Action User-defined Profiles Pre-defined Profiles

Create Possible Not Possible

Modify Partially * Not Possible

Schedule Possible Continuous only

Suspend Possible Possible

Resume Possible Possible

Delete Possible Not Possible**

Type MO Instance Possible for RNC for Utran Utran Cell and Utran Relation counters

Not Possible

Table 2-7. Main differences between user-defined and pre-defined profiles

* The operator is allowed to change the attributes of all unlocked user-defined Subscription Profiles with Inactive Admin state and/or change the network element selection for an unlocked, standard user defined standard statistics profile with Active Admin state.


- 46 - © Ericsson 2006 LZT 123 8297 R1C

** Pre-defined profiles can still be deleted but only via direct PM IRP operations. Since they cannot be recreated it is strongly recommended to perform the deletion with a great caution and awareness.

For more information on what counters that are included in the different predefined profiles, please see Appendix D in this student book.

Statistics Scanner

Normally, users only need to know about profiles and counters in order to use performance statistics.

The statistics profiles are only visible in the OSS-RC GUI. The actual communication between OSS-RC and NEs is performed on another level – through statistics scanners. A statistics scanner is a sort of instance of a specific profile at a specific NE.

Figure 2-8. Profiles, Scanners and Counters – RNC example

In the figure above, the concept of profiles, scanners and counters is shown on the example of an RNC node (same applies to RBS and RXI nodes).

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 47 -

One profile (for example the RNC Profile “A”) may be mapped to a corresponding scanner (“A”) at several NE instances (RNC1 and RNC2). Another profile (RNC Profile “B”) may be mapped to only one NE instance, and so on.

Profiles can be active or suspended. When active, all corresponding scanners at selected NEs are also active. When a profile is inactive, all its scanners are also inactive.

Normally, the users are handling all the performance statistics administration through profiles. For troubleshooting purposes, or other special cases, it is also possible to resume, suspend and monitor each scanner individually through the OSS-RC GUI and EM. Note that through the EM it is not possible to resume a scanner.

Counter limitations

There are only two predefined scanners in the RNC. The first, PREDEF.PRIMARY.STATS, contains only the most important RNC radio network counters. These counters are typically used to calculate high-level KPIs. The second, PREDEF.SECONDARY.STATS, contains important counters, typically used for troubleshooting.

Both PRIMARY and SECONDARY scanners are initially active on startup of the RNC

Which counters that are available in the predefined scanners can be found in the CPI, of Performance Statistics Description 25/1551-AXD 105 03/1 Uen H

There are limitations on the total amount of counter instances that can be simultaneously active in each NE:

• RNC – 750,000 incrementing counters with R4 HW or later on the O&M board. The RNC can handle 1,700,000 counters in total during a ROP, including counters that have been incremented and zero-value counters.

• RBS – 17,000 counters

• RXI – 65,000 counters

Note that these limits apply when up to five scanners are running on the RNC, including the two predefined scanners. With more scanners active, the capacity is lower.


- 48 - © Ericsson 2006 LZT 123 8297 R1C

For more details on counter limitations please see section 3.4 Counter Limitations in CPI 85/1553-HSD 101 02/4 Uen. Rev C.

Before activating statistics profiles it is recommended to check if the number of counters would exceed the limits for each NE.

It is recommended to, at least initially, do the counter dimension, assuming that all Triggerable counters also are incremented. That means that the dimensioning counter limit, depending on the HW. It is very likely that a quite substantial percentage of the Triggerable counters are not incremented for a specific ROP due to that the triggering conditions for some of the counters are not fulfilled. These non-incremented counters will then be an extra margin.

To calculate the Total number of counters and the number of Triggerable counters, a Spreadsheet exists, 5/1553-AXD 105 03/1 Uen E.

Counter Dimensioning

The counter capacities of the RBS and RXI are sufficient for detailed Observability of the nodes. Due to the much higher demand for counters in the RNC, there is a need to carefully optimize the number of active RNC counters.

Due to the limitations on the maximum number of simultaneously active counters in one RNC, it may be required to set some rules, depending on the size of the RNC. For small RNC configurations, all defined counters may be simultaneously active everywhere, so the dimensioning is not necessary.

For large RNC configurations it is recommended to set the following rules:

• Keep the primary profile active all the time, thus allowing the radio network KPI performance monitoring on cell and higher levels.

• Keep the secondary profile active all the time if possible. If not, keep it active all the time when there is no other competing activity.

• Keep the most important UniSaalTp, Aal2Ap, NniSaalTp, AtmPort, ImaGroup, ImaLink, VclTp, VpcTp and VplTp counters active all the time.

This is for the continuous transport network KPI performance monitoring.

2 Data Collection

LZT 123 8297 R1C © 2006 Ericsson - 49 -

• Define Radio Network troubleshooting clusters, typically about 20 RBSs.

Note that when doing a MO instance activation, i.e. selecting a sub-set of the cells, etc., the maximum limit for each performance monitoring is 72, 000 counter instances.

• Perform Radio Network troubleshooting on specific clusters, not on the whole RNC.

Troubleshoot a function at a time, typically choose between troubleshooting inter-frequency handover, soft/softer handover, inter-RAT handover, transport network functions or all other radio network functions. The reason for this is that some functions contribute with a substantial number of counters, so their belonging counters cannot be simultaneously active.

Note that some functions’ counters (handover and all cell based counters) can be activated per cluster and some not (transport network counters).

To not create unnecessary large files, use only one measurement (scanner) each for MO class initiated UtranRelation measurements and GsmRelation measurements. If two or more measurements (scanners) are used for MO class initiated UtranRelation measurements, the identity of the UtranRelations are repeated in the file and that will increase the file size considerably.

Set the parameter counterAlarmThreshold so that a warning alarm is issued when that allowed limit for the Total number of counters is reached. It is by default set to 80%.

ACTIVATION

Once the wanted profiles and counters are activated, their values are generated and being collected after each reporting period. A reporting period is always set to 15min starting at the 00, 15, 30 or 45 minute in an hour. When all profiles at one NE get suspended, the generation and collection stops for that NE.

When a counter is active, a value is generated every Result Output Period (ROP). At the end of each ROP, all the counter values produced during that period are stored in one ROP file at the NE. This file is in XML format and compressed using GZIP. The ROP period is 15 minutes.


- 50 - © Ericsson 2006 LZT 123 8297 R1C

The statistics ROP files are then collected by the OSS-RC and stored in its file system for a configurable period of time (these values can be changed by modifying OSS-RC parameters. If the Statistical Data Mart (SDM) is present, the data can be stored for up to one year.

STATISTICAL DATA MART The Statistics Data Mart is a database available for storing the statistics counters. It provides the ability to store the data for up to one year. All stored data can be accessed through the SQL interface. The SDM offers the ability to aggregate the raw data based on time and object, provides data reliability indicators, and generates the Calculated Statistics counters.

The SDM is an optional feature in OSS-RC3 and not standard.

The time aggregation is performed for different periods – hour, day, peak hours/day and week.

The object aggregation is performed only for the Utran Cell counters as they are aggregated on the RNC and then together with other RNC counters up-to System level.

3 Service Accessibility

LZT 123 8297 R1C © 2006 Ericsson - 51 -


Objectives

Upon completion of this chapter, the student will be able to:

• Understand how to analyze and interpret the collected data in order to improve the Call Setup process

• Analyze RAN performance and propose adjustments related to accessibility


- 52 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank


LZT 123 8297 R1C © 2006 Ericsson - 53 -

ACCESSIBILITY ..................................................................................55

ACCESSIBILITY WORKFLOW ...........................................................55

WORST PERFORMING CELLS ..........................................................56

UE IN IDLE MODE...............................................................................58 PLMN SELECTION.........................................................................................59 CELL SELECTION..........................................................................................59 LA AND RA UPDATE......................................................................................60 PAGING ..........................................................................................................62 SYSTEM INFORMATION ...............................................................................66

RANDOM ACCESS..............................................................................68 UL OPEN LOOP POWER CONTROL ............................................................70

RRC CONNECTION SETUP................................................................72 EMERGENCY CALLS.....................................................................................73 MODULE MP LOAD........................................................................................73 ADMISSION CONTROL BLOCK ....................................................................74 LACK OF TRANSMISSION RESOURCES.....................................................90 LOAD SHARING .............................................................................................90 RADIO LINK SETUP.......................................................................................95

NAS PROCEDURES..........................................................................100 CM SERVICE REJECT.................................................................................100

RADIO BEARER SETUP...................................................................101 UE CELL RESELECTION DURING HANDOVER ........................................105 UE CELL RESELECTION.............................................................................106

TEMS INVESTIGATION FINDINGS...................................................108 PDP REJECTED...........................................................................................108 PPP LINK CONTROL TERMINATED ...........................................................108


- 54 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank


LZT 123 8297 R1C © 2006 Ericsson - 55 -

RRC Connection Setup

NAS procedures: Service Request

Authentication Security

RAB Assignment

Random Access

Mobile Originating Call Setup

ACCESSIBILITY This is the first module that should be optimized. Accessibility is defined as the ability of a user to obtain requested service from the system. The figure below is showing a mobile originating call setup and all the different actions taken before a call is established.

Figure 3-1 A mobile originating call setup and the different action taken

ACCESSIBILITY WORKFLOW Below the Figure 3-2 is showing the Accessibility workflow.

At performance monitoring the worst cells regarding accessibility is sorted out.

At performance analysis the worst cells are analyzed in the same order as the mobile will originate a call setup.

Through the Recommendation and Implementation phase parameters will be looked upon in order to make a change of the networks performance.


- 56 - © Ericsson 2006 LZT 123 8297 R1C

Through the Verification phase, the collected statistics before anything is implemented is compared to the statistics collected after the implementation is done. This is to ensure that there have been an improvement.

Figure 3-2 A The Accessibility workflow

At the end of the workflow, when the verification of the implemented changes is done, then the optimizer should continue to the other modules, in this case the retainability module.

WORST PERFORMING CELLS The most important is to find the worst cells regarding accessibility. It can be tricky because there are many setup success rates for RRC connection,

• CS RRC connection,

• PS RRC connection,

• CS RAB and

• PS RAB.



Recommendation &

Implementation


Other M

odules

pmTotNoRrcConnectCsSucc pmTotNoRrcConnectPsSucc pmNoRabEstablishAttempt<RAB> pmNoRabEstablishSuccess<RAB> pmNoPageDiscardCmpLoadC pmNoPagingAttemptUtranRejected

Idle mode RRC Connection Random Access NAS RAB Assignment

Squal, Srxlev, qQualmin, qRxLevMin, maxTxPowerUl, t3212, t3312, aichPower, powerOffsetP0, preambleRetransMax, constantValueCprach


LZT 123 8297 R1C © 2006 Ericsson - 57 -

There are two categories of KPIs:

• 1st category KPIs is to identify which cells/RBSs having accessibility problems (e.g. RRC connection successful rate and RAB establishment successful rate)

• 2nd category KPIs is to imply the reasons of failures (e.g. admission control deny).

In order to find areas with high RRC or RAB establishment failures, the 1st category KPIs should be used to identify the 10-15 worst performing cells and their surrounding cells. Afterwards, using 2nd category KPIs estimates the reasons of failures.

The issue is which setup success rate(s) should be used for finding worst cells. Therefore, a formula to combine all individual success rates is needed.

Then from the result of the formula, “worst” performing cell can be found by analyzing the setup success rate of a cell with the weight factor (in terms of percentage of RRC attempt, e.g. total number of RRC attempts of that cell / total number of RRC attempts in whole RNC) in a certain time period, for example consequent 7 days.

If the optimization strategy is to handle all the worst cells regarding a certain service, then formulas for each service should be used.

Accessibility for CS services:

⎟⎟⎠

⎞⎜⎜⎝

⎛><><

×⎟⎟⎠

⎞⎜⎜⎝

⎛×

RABAttemptbEstablishpmmTotNoRaRABuccessEstablishSpmTotNoRab

CsConnectReqpmTotNoRrcCsSuccessConnectReqpmTotNoRrc100

Where <RAB> = Speech, CS64 or CS57

Accessibility for PS services:

⎟⎟⎠

⎞⎜⎜⎝

⎛><><

×⎟⎟⎠

⎞⎜⎜⎝

⎛×

RABAttemptbEstablishpmmTotNoRaRABuccessEstablishSpmTotNoRab

PsConnectReqpmTotNoRrcPsSuccessConnectReqpmTotNoRrc100

Where <RAB> = PacketStream or PacketInteractive

Due to the fact that UE may perform cell re-selection during RRC Connection, it may repeat RRC Connection Request message N300 times which may arrive at different cell, and the fact that WCDMA RAN does not double count the duplicated RRC Connection Request message, there is a chance that access success rate for some cells may show larger than 100% success rate.


- 58 - © Ericsson 2006 LZT 123 8297 R1C

The access success rate of better than 100% happens when the attempt registered at different cell than where the success registered. The end result is slightly larger success rate for the cell that completes the access and a slightly less success rate for the cell that starts the access.

UE IN IDLE MODE The Idle mode tasks may be divided in five different processes:

• PLMN selection and reselection

• Cell selection and reselection

• Location area (LA) and routing area (RA) registration

• Paging procedure

• Reading system information

Most of the faults in a network appear after the cell has selected the PLMN and made a cell selection. However sometimes problems can occur that are related to the UE idle mode behavior.

Figure 3-3 illustrates the relationship between PLMN selection, cell selection and reselection and LA and RA registration.

PLMN Selection

Cell Selection/Reselection

Locationregistration

LR Response

Registrationarea changes

PLMN selected

Automatic/Manual mode selection

Indication to user

PLMNsavailable

Figure 3-3 The relationship between some of the idle mode tasks.


LZT 123 8297 R1C © 2006 Ericsson - 59 -

PLMN SELECTION

PLMN selection is the first step in the registration process that allows a UE to carry out or receive services from an operator. The UE normally operates on its home PLMN. However, a Visited PLMN (VPLMN) may be selected if the UE loses coverage. A UE successfully registers on a PLMN if it finds a suitable cell to camp on within the selected PLMN. The UE will then obtain a location or routing registration acknowledgement in the area of the cell on which it is camped. The UE displays to the user that this PLMN is registered.

When a UE does not find a suitable cell in the selected PLMN, it tries to camp on any other acceptable cell within an allowed PLMN.

When there is a suitable cell available normal services can be obtained in the cell. If there is an acceptable cell available only emergency calls are available.

CELL SELECTION

One of the requirements for a suitable cell is to fulfill cell selection criteria. The UE bases its evaluation on two quantities: Squal and Srxlev. The cell selection criteria are fulfilled when:

Squal = Qqualmeas- qQualMin > 0

Srxlev = Qrxlevmeas – qRxLevMin – Pcompensation > 0

Where Pcompensation = max(maxTxPowerul – P;0)

• qQualmin is sent in the broadcast information (SIB 3 for serving cell and SIB 11 for adjacent cells) and indicates the minimum required quality value. The UE measures the received quality, “Qqualmeas”; on the CPICH (CPICH Ec/No) and calculates Squal. This is only done for WCDMA cells.

• qRxLevMin is also sent in the system information (SIB 3 for serving cell and in SIB 11 for adjacent cells) and indicates the minimum required signal strength. The UE measures the received signal Code Power (CPICH RSCP) and obtains Srxlev


- 60 - © Ericsson 2006 LZT 123 8297 R1C

• maxTxPowerUl is the maximum transmission power during random access on the RACH and that value is sent in the system information (SIB 3).

• P is the UE maximum output power according to its class.

Quantities measured and parameters used are shown in Figure 3-4.

• Qqualmeas

• Qrxlevmeas P-CCPCH

CPICH

• qQualmin

• qRxLevMin

• maxPowerul

Figure 3-4 Determination of Cell Selection Criteria

The UE shall measure the CPICH Ec/No and the CPICH RSCP of the serving cell and evaluate the cell selection criterion, S, at least every DRX cycle. The UE shall filter the Ec/No and RSCP measurements of the serving cell using at least two measurements.

If both criteria are fulfilled and other requirements for a suitable cell are fulfilled the UE will camp on the cell. The UE will enter the state “camped normally” where it performs intra-, inter- and intersystem radio measurements to evaluate if a neighbouring cell is better than the serving one.

LA AND RA UPDATE

Location and routing areas are used by the CN for mobility functionality. A paging message for a CS call to a certain UE is broadcasted to all cells belonging to the LA in which the UE is registered. Accordingly, a paging message for a PS connection is broadcasted to all cells in the RA in which the UE is registered.


LZT 123 8297 R1C © 2006 Ericsson - 61 -

The CN has to keep track of the location of the UE. To make this possible the UE registers to the CN at certain instances. Specifically when moving from one LA to another, the UE performs an LA and/or RA Update (LAU/RAU). If the LAs/RAs are small, there will be more LAUs/RAUs in the system. On the other hand, if the LAs/RAs are large the number of paging messages will increase.

There are three types of LA and RA registration updates:

1. International Mobile Subscriber Identity (IMSI) attach or detach

2. Normal LA and RA updating

3. Periodic LA and RA updating

Periodic registration (LA and RA updating) is used to locate the UE to avoid unnecessary paging attempts for a UE that has lost coverage and is not able to inform the CN that it is inactive. A timer t3212 controls the periodic LA update procedure and gives the time interval between two consecutive periodic location area updates. The timer is sent in the system information.

When the UE is in connected mode and t3212 expires no periodic update is performed. When the UE enters Idle mode again a LA update is performed, see Figure 3-5

UE moves to connected mode

t3212

LA Update LA Update LA Update

UE moves to idle modeUE in idle mode

t3212

Figure 3-5 Periodic Registration

A timer, called t3312, which gives the time interval between two consecutive periodic routing updates, controls the periodic RA update. The value of the timer is sent by the CN to the UE in the IMSI attach or in the routing area update message accept (this is not a radio parameter).


- 62 - © Ericsson 2006 LZT 123 8297 R1C

The intensity of RRC connection establishments is considerably higher for RBSs placed at the LA/RA border compared to RBSs placed inside the LA/RA. A border RBS can therefore handle less traffic than an RBS placed inside the LA, due to the increased signalling load. Therefore, it is recommended that he LA/RA borders should be placed in areas with low traffic.

A high number of border RBSs will increase the signalling load in the RNC for the same number of subscribers. If the LAs/RAs are small, the number of border RBSs will be large. Therefore, the LAs/RAs must not be too small.

Different PLMNs and thus different Location/Routing Area Identification (LAI/RAI) should be used for the GSM and WCDMA networks. If the same LAI/RAI is used for the GSM and WCDMA networks, the consequence is heavy paging load in the WCDMA network arising from the GSM subscribers.

PAGING

Paging is initiated upon request from the CN or triggered in UTRAN. It is used to notify the UE of different events. In WCDMA RAN P4 these are:

• UE terminating service request for PS or CS services (CN initiated). CN initiated paging is applicable to UEs in idle mode.

• UTRAN initiated broadcast to inform UEs when System Information is modified. UTRAN initiated paging is used whenever System Information (e.g. information about cell selection/ reselection, addition/replacement of neighbors, handover etc.) has been updated.

The paging message has the following characteristics:

• Type of paging message: Paging Type 1 or Paging Type 2

• UE identity used in the message (IMSI, TMSI, P-TMSI)

• The physical radio channels and type of resource required

• The area in which the page will be broadcasted (LA or globally)

The paging record varies in length depending on whether it includes the UE identity in terms of IMSI, TMSI, or P-TMSI. A PCH frame can carry one “Paging Type 1” message of 10 ms and may contain between 3-5 paging records, depending on whether the paging uses IMSI or TMSI/P-TMSI.


LZT 123 8297 R1C © 2006 Ericsson - 63 -

When the UE mode is Cell_FACH or Cell_DCH common or dedicated physical channels are already in use and the paging message “Paging Type 2” will be used.

For paging, the capacities of the FACH and the RACH are assumed to be enough, but there is a risk of congestion in the PCH due to heavy paging load. Therefore, the probability of congestion in the PCH must be calculated in order to dimension the LA/RA. If the operator wants to check the paging success rate, this should be done on MSC level. Notice that even if a UE does not response to a paging in a certain Location Area, a second paging might be sent throughout the whole MSC area (depending on configuration) and UE can be finally reached. For this reason the most reliable indicator for paging is the one obtained at MSC level. Successful First and Repeated Page attempts of total number of first attempts, Paging success rate in a MSC

⎟⎠⎞

⎜⎝⎛

++

×NPAG1LOTOT NPAG1GLTOT

CNPAG2RESUC CNPAG1RESUC100

Paging start in the core network but the paging flow in the RAN network is only considered.

Total number of pages discarded due to central MP load control for a RNC pmNoPageDiscardCmpLoadC

Pages request rejection for a cell pmNoPagingAttemptUtranRejected

Paging intensity per cell in a RNC (if RNC, LA and RA consist of exact same cells):

RNC that incells of number total period tmeasuremenUegingToIdlepmCnInitPa UeRagingToIdlepmCnInitPa UeLagingToIdlepmCnInitPa

×++


- 64 - © Ericsson 2006 LZT 123 8297 R1C

In the Figure 3-6 the dashed arrows and boxes considers the packet switched paging.

For all counter flow, the following are applied:

RBS counters: <Counter Name> (Green color)

RNC Counters: <Counter Name> (Blue color)

MSC Counters: <COUNTER NAME> (Orange color, capital letters)

Exceptions, Failures:

Successful Outcomes:

Counter Scope: (Scope) <Counter Name>


LZT 123 8297 R1C © 2006 Ericsson - 65 -

Figure 3-6 The Paging counter flowchart

RNC received Paging message from the CN

Idle

(RNC) pmcNoPagingAttemptCnInitDcch +

Connected

RNC Sends to the UE Paging Type 2 Message

Check UE status

MP Overload?

Paging is not sent

No

Yes

No

Paging Area is a defined LA?

Yes

No

Yes Paging Area is a defined RA?

Paging que full?

(Cell) pmcnInitPagingAttemptUtranRejected +

Paging is not Sent

No

Paging is Sent

Yes

(RNC) pmInitPagingToIdleUE +

(RNC) pmcNoPagDiscardCmpLoadC +

(RA) pmcnInitPagingToIdleUeRA +

(RNC) pmCnInitPagingToIdleLA +


- 66 - © Ericsson 2006 LZT 123 8297 R1C

SYSTEM INFORMATION

The System Information Block (SIB) messages are sent on BCCH logical channel, which can be mapped to the BCH for UEs in idle mode, Cell_PCH and URA_PCH or the FACH transport channel for UEs in Cell_FACH. The system information explains for the UE how to behave in the cell and it carries for example information that the UE needs for cell reselection. The system information elements are broadcasted in System Information Blocks. A SIB groups together system information elements of the same nature, for example cell selection and reselection parameters. The SIBs are sent in System Information messages. Different system information blocks may have different characteristics for instance regarding their repetition rate and the requirements on UEs to re-read the SIBs. The SIBs are organized as a tree. A Master Information Block (MIB) gives references to a number of SIBs in a cell, including scheduling information for those SIBs. In addition to scheduling information of other SIBs, the MIB contains only information of supported PLMN types (which can be GSM and/or ANSI 41) and PLMN identity information. The MIB is transmitted according to standardized scheduling parameters, so a UE is always able to find the MIB on the BCCH. The MIB carries information of when the UE can expect to find the different SIBs. To inform the UE if a change in System information has occurred, the MIB also delivers a value tag for each SIB. This is to prevent unnecessary decoding of same information. The tag is used by the UE to detect a change in SIB. If the tag is changed, UE needs to re-read the information. If no change in the value tag, the SIB is discarded or not read. To inform UEs in idle mode, Cell_PCH and URA_PCH of a change in the system information, paging in used. In this case, a “Paging type 1” message is sent to deliver the IE “BCCH modification info” to notify the new value tag for the MIB. WCDMA RAN can also inform of the change in the system information with a System Information Change Indication message on the FACH transport channel.


LZT 123 8297 R1C © 2006 Ericsson - 67 -

The table below contains a description of the information that is carried by the MIB and the SIBs.

Contents MIB SIB 1

SIB 3

SIB 5

SIB 7

SIB 11

SIB 12

PLMN Identity X LA and RA updating X Cell Selection and Reselection Parameters X X Power Control on Common Channel X Paging Parameters X Measurement Management X X Cell and common channel configuration X Timers and counters in Idle mode X

When a suitable cell is found, the UE camps on it in a state defined as “camped normally”. In this state, the UE monitors paging and system information, performs radio measurements, and evaluates cell reselection criteria. If the UE finds a better cell, the cell reselection process selects that cell. The change of cell may imply a change of the Radio Access Technology (RAT).


- 68 - © Ericsson 2006 LZT 123 8297 R1C

RANDOM ACCESS Random Access is the same for every kind of service: CS, PS, Registrations, Signaling, SMS, etc. The UE is in idle state when it is sending the RRC Connection Request message. The RNC has correctly received the request over the Random Access Channel (RACH). However if the RNC does not receive the RRC Connection Request message the UE returns in Idle state.

Figure 3-7 The Random Access counter flowchart

UE sends preambles sequences

Negative AICH is sent No response is sent and/or received by UE over AICH

Positive AICH is sent

(Cell) pmNegativeMessages +

(Cell) pmPositiveMessages +

UE does not receive positive AICH

UE sends message “RRC Connection Request”

UE receives positive AICH

RNC does not receive the message

RNC receives the message

(Cell) pmTotNoRrcConnectReq + (Cell) pmTotNoRrcConnectReqCs + (Cell) pmNoRecRandomAccSuccess + (Cell) pmTransportBlocks +

NAttemptsi > N300 (=5)?

NAttempts =0

NAttempts =+1

No

Random Access Failure

Yes

(Cell) pmFaultyTransportBlocks +


LZT 123 8297 R1C © 2006 Ericsson - 69 -

There is no statistic counter to directly present that random access procedure failure behaviour. However, the preamble or AICH counters can be analyzed in order to determine the probability of occurring random access procedure failure problem.

If maximum allowed attempts (N300=5) has been reached the cause of failure is that the RBS has blocked the access (negative AICH) or preambles sent by the UE are not received or ignored (no AICH is sent) or UE does not receive the AICH positive for any reason.

During the RACH procedure, the UE is allowed to make a cell reselection, so it is possible that a few attempts have to be repeated because the cell changed. In case of cell reselection or when the response from the RNC is delayed more than T300 (=1 sec) more than one RRC Connection Request could be sent to the RNC. Only the first attempt is counted by pmTotNoRrcConnectReq and pmTotNoRrcConnectReqCs counters.

In case trouble-shooting drive test is done, from TEMS, the symptoms of this problem are:

1. UE repeatedly prepares RRC connection request messages in L3.

2. UE camps onto a cell and does not change cells.

3. However, the UE does not receive RRC connection setup or RRC connection reject message.

Please note that under random access problem, the UE TX power does not reach to the maximum allowed UE TX power. This should be compared when the UE does ramp up the UE TX power to its maximum allowed TX power. The reason for this can be an UL/DL unbalance or swapped feeders.

The possible reasons why UL/DL is in imbalance are “too large CPICH power setting”, “imbalance in UL/DL feeder loss”, “high UL RSSI noise rise” and “cell down”. The primaryCpichPower could be set too large or the UL RSSI is too high.

It is also important to verify if there is any mistake in the antenna system configuration and feeder attenuation settings in the system.

If the preamble and RACH message part are wrongly recognized or lost, it could also be that the AICH power is not large enough.

The solution is to check if the aichPower is set as default. If needed, increase aichPower.


- 70 - © Ericsson 2006 LZT 123 8297 R1C

UL OPEN LOOP POWER CONTROL

Power Control is essential for the smooth operation of a WCDMA system, because all users share the same radio frequency band using different codes.

There are three types of power control in WCDMA as illustrated in Figure 3-8.

RNC

Uplink SIR-Target

Uplink SIR error

SIR-Targetmodified

Uplinkouter loop

BLER-Measured

BLER:Block Error Rate

SIR: S ignal to Interference Ratio

TPC: Transmit Power ControlUplink SIR target

DownlinkSIR target

Inner loop

Downlink TPC UplinkTPC

Starting power

Open loop

SIR-Targetmodified

Downlinkouter loop

BLER-Measured

Figure 3-8 WCDMA Power Control

Open Loop Power Control is performed in the uplink and downlink to calculate a minimum starting power for setting up a connection. In doing so the interference and power required is minimized.

The suitable settings should fulfill below criteria:

powerOffsetP0 x preambleRetransMax + constantValueCprach >= predefined preamble threshold, and

n x powerOffsetP0 + powerOffsetPpm >= 0, where n can be in 0 to preambleRetransMax range

Number/percentage of false detections, which is the case that preamble is detected but there is no enough energy in message part, due to noise on the random access channel for a carrier (it could be due to loss of AICH, wrong recognition of preamble or loss of RACH message part after the UE sends message out):

pmNoPreambleFalseDetection or

100%MessagespmPositive

ectionleFalseDetpmNoPreamb×


LZT 123 8297 R1C © 2006 Ericsson - 71 -

Signal-to-interference ratio of all access attempts above the preamble threshold (except false detection) on RACH for a carrier: pmReceivedPreambleSir and Number of samples of pmReceivedPreambleSir

The solution to the problems is to check if the parameters are set properly. If needed, increase constantValueCprach or/and powerOffsetPpm


- 72 - © Ericsson 2006 LZT 123 8297 R1C

RRC CONNECTION SETUP The RNC has received “RRC Connection Request” message from the UE and the UE has successfully establish a RRC connection. The RNC receives both the Radio Link Restore Indication from the RBS and the RRC Connection Setup Complete from the UE.

Figure 3-9 A mobile originating call setup and the different action taken

Processor Load control (MP)

Admission Control

Radio Link Setup (UL BBP) pmSetupAttemptsSf64 + (DL BBP) pmSetupAttemptsSf128 +

RNC sends the message RRC Connection Reject

(Cell) pmNoRejRrcConnMmpLoadC +

(Cell) pmTotNoUtranRejRrcConnReq+

(Cell) pmNoReqDeniedAdm +

(Cell) pmNoFailedAfterAdm +

OK

OK

OK

Access not allowed

RNC sends the message RRC Connection Setup

RAX or TXB Congestion

Channel code allocation (Cell) pmNoDlChCodeAllocAttemptSf128 +

(Cell) pmNoDlChCodeAllocFailureSf128+

Code not available

OK

Access not allowed

RNC receives the message RRC Connection Request

UE context allocation Context allocation failure

Emergency Call

No

OK

Redirection of Emergency Call

(Cell) pmNoOfRedirectedEmergencycalls +

No

Multifrequency Load Sharing Load Sharing RRC Redirection

Load Sharing

AAL2 SetupAAL2 Failure

(UL BBP) pmSetupFailureSf64 + (DL BBP) pmSetupFailureSf128 +


LZT 123 8297 R1C © 2006 Ericsson - 73 -

EMERGENCY CALLS

The UE always initiates the establishment of an RRC connection by sending the RRC Connection Request message with an establishment code (Emergency call, Registration, Originating Call, IRAT Cell Reselection...). When the redirect of emergency calls to GSM feature is turned on, the request to establish an RRC connection shall be rejected for all UEs indicating 'Emergency call'.

The following RNC counters, counts the number of successful emergency positioning attempts.

100%sAgpsingReqAttEpmPosition

EsAgpsingReqSuccpmPosition×

In P5 Emergency calls can be served and positioned in UMTS if the operator has confidence in AGPS in UMTS otherwise the call is handed over to GSM

When the feature is 'on' and in operation the following parameter settings are needed in order for the call to have the possibility to be served in UMTS and positioned by UMTS: ecCnSbhoRequestIgnore = TRUE, ecLocationAttemptUmts = Yes

For UMTS cells where the operator is confident AGPS is performing well enough to meet the positioning requirements of emergency calls set the agpsEnable= True.

Congestion control and admission control will not block emergency calls.

MODULE MP LOAD

RRC connection rejection rate due to module MP load control for a cell could be found in the following formula:

100%nnaringRrcCopmNoLoadSh-ConnectReqpmTotNoRrc

CConnMpLoadpmNoRejRrc×

Note that RRC connection rejection due to module MP load control happens before inter-frequency load sharing.

One reason for MP load can be too many periodic registrations


- 74 - © Ericsson 2006 LZT 123 8297 R1C

ADMISSION CONTROL BLOCK

Admission control is together with Congestion control part of the WCDMA Capacity Management. The setting of parameters associated with Admission control can have a serious effect on Network Capacity and revenue generated.

Admission control blocks new incoming calls as well as handover attempts when the load in the system is high. By doing that, the call dropping probability is reduced. Admission control is used in both the uplink and downlink. The admission decision is based on air interface load, by using measurements of uplink interference, downlink output power as well as the actual number of users. The admission functionality is also capable of including priority, for instance emergency calls, in the admission decision.

In the illustration in Figure 3-10 the last UE is blocked because the cell load has reached the defined ‘admission limit’.

RBS

Cell Load

Admissionlimit

Figure 3-10 WCDMA Capacity Management (Admission Control)

Admission Control blocks due to improper admission threshold settings. There are nine admission policies to control the blocking. They are UL ASE, DL ASE, DL TX cell power, spreading factor usage, code usage, Hw usage, amount of HS users, congestion and number of users in compressed mode. Understanding of which cause(s) to trigger blocking is necessary to solve the problem.


LZT 123 8297 R1C © 2006 Ericsson - 75 -

Figure 3-11 The Admission control flow

When new resources are needed for a radio connection, (a new radio link is set up or an existing radio link is modified), the Admission Control function receives a request for admission. The request specifies the estimated amount of dedicated monitored resources that the radio connection needs. This estimation is compared to the available resources and the configured limits for admission set by the operator, and a response is sent out to grant or deny the new radio link access to a cell.

To decide on the requests, the Admission Control function requires information about the load on the dedicated monitored resources and the amount of resources needed by the requester.

Check if the requested DL pwr + estimated pwr

> pwrAdm

Check if the requested ASE dl + estimated ASE dl

> AseDlAdm

Check if the requested HW + estimated HW

> ulHwAdm, dlHwAdm

Check if the requested + estimated # HS users > hsdpaUsersAdm

Check if the requested ASE Ul + estimated ASE Ul

> AseUlAdm

YES, then block

Is admission control blocked by congestion

control?

YES, then block

YES, then block

YES, then

YES, then block

YES, then block

YES, then block

YES, then block

NO

NO

NO

NO

NO

NO NO

NO

Check if the requested + est # compressed mode RL

> CompModeAdm

Check if the requested + estimated code usage

> DlCodeAdm

Check if the requested DL SF + estimated Dl SF

> SfXAdm,

RESOURCE REQUEST

Sf = 8 sf =16 sf = 32

NO, then accept


- 76 - © Ericsson 2006 LZT 123 8297 R1C

Admission Control has different policies regarding the maximum level of the dedicated monitored resources it rejects or admits radio links. Admission Control is responsible for dividing the available resources among the non-guaranteed service class connections, and for differentiating access to resources between guaranteed and non-guaranteed service class connections, as well as reserving part of the dedicated monitored resources for hand over of connections.

Counter Description

pmNoReqDeniedAdm Number of RAB establishment and RRC requests denied due to AC, both drifting and non-drifting UEs. This counter is increased when admission is denied for radio resources.

pmNoFailedAfterAdm Number of RRC establishment requests and RAB establishment requests failed after being admitted, both drifting and non-drifting UEs. This counter is increased after the admission is accepted for radio resources issue, but when it is denied due to a shortage of transport network resources/channel elements

The counter pmNoReqDeniedAdm shows the number of RRC establishment requests and RAB establishment requests denied for a cell. Please note that this counter is stepped up for RRC establishment, RAB establishment or channel up-switching if admission control triggers the blocking in a cell.

The solution to the admission control blocking problem is to check if the admission thresholds (i.e. ulHwAdm, hsdpaUsersAdm maximumTransmissionPower, aseUlAdmOffset, beMarginAseDl, beMarginAseUl, beMarginDlCode, compModeAdm, dlCodeAdm) match to the original planned capacity.

If the thresholds do not match to the original planned capacity, the admission thresholds have to be corrected. Otherwise, re-do the radio network dimensioning to increase the system capacity or activate the inter-frequency load sharing to increase the trucking efficiency.


LZT 123 8297 R1C © 2006 Ericsson - 77 -

Congestion control blocks

Congestion control is used to resolve overload in both the uplink and the downlink. As shown in the figure below, congestion due to radio overload in uplink is detected when the uplink Received Total Wideband Power (RWTP) exceeds a certain configurable threshold for a longer time than the hysteresis time. The threshold for detection of uplink congestion is determined by iFCong + iFOffset and the hysteresis time is determined by iFHyst.

Congestion Control considers uplink congestion to be resolved when the uplink RTWP for a particular cell is below iFCong for a longer time than the hysteresis time (or until the next periodic event-based measurement report for uplink RTWP arrives indicating that the resource level is below the threshold).

Figure 3-12 Detection of Uplink Cell Congestion Due to Uplink Received Total Wideband Power

The current default setting is defined so that guaranteed-hs users are never released (releaseAseDlGhs=0). The reason for this strategy is that one HS contributes marginally to the downlink cell congestion because there is only one A-DCH channel per HSDPA user in downlink. Acting on the non-guaranteed and guaranteed service class is, under normal circumstances, sufficient to resolve the congestion in the cell.

The admission control also controls the blocks due to congestion. Therefore is it important to look at the congestion counters.

• Number of times congestion control is triggered due to high DL power for a cell: pmSumOfTimesMeasOlDl

• Number of times congestion control is triggered due to high UL interference for a cell: pmSumOfTimesMeasOlUl


- 78 - © Ericsson 2006 LZT 123 8297 R1C

• pmNoOfTermHsCong & pmNoOfIurTermHsCong - RNC counters monitoring no. of HSDPA users released due to congestion

• The total amount of time (sec) was congested in DL during a reporting period for a cell: pmTotalTimeDlCellCong

• The total amount of time (sec) was congested in UL during a reporting period for a cell:pmTotalTimeUlCellCong

Samples of the UL RSSI for a cell-carrier could be found in the counter pmAverageRssi. By using these samples the formulas for getting the average DL and UL.

Average DL TX power for a cell-carrier:

∑

∑

=

=⎥⎦

⎤⎢⎣

⎡⎟⎠⎞

⎜⎝⎛×

102

0ii

102

0ii

PowertedCarrierpmTransmit

2iPowertedCarrierpmTransmit

Average UL RSSI for a cell-carrier:

( )[ ]

∑

∑

=

=

−××

62

0ii

62

0ii

ssipmAverageR

110.5i0.5ssipmAverageR

For averaging RSSI and carrier power, these values must be checked close to the maximum allowed values. If the average values are close to these thresholds, it implies the chance of having congestion/admission block is high. In fact, it will be more interesting to look at max RSSI and carrier power sampled values. Still as RL setup is taking very short time to establish, it will be very hard to say how those max values are related to RL failures.

In TEMS Investigation, this can be found by verifying that the UE send RRC Connection Request, UTRAN send RRC Connection Reject with cause = congestion.


LZT 123 8297 R1C © 2006 Ericsson - 79 -

Figure 3-13 TEMS Investigation with high UTRA Carrier RSSI

The UL RSSI can be high due to the following:

– non-traffic interference

– High TX power from a UE that are connected to a far cell. This can happen due to missing neighbors.

RBS HW

The RBS Hardware Monitor provides Admission Control with the estimation of the hardware usage in a local cell group, separately for the uplink and the downlink

The relation among the RBS hardware admission policy parameters, the downlink resource usage in the relevant local cell group and the admission request parameters are almost the same as the uplink resource check as shown below.


- 80 - © Ericsson 2006 LZT 123 8297 R1C

Figure 3-14 The Uplink RBS HW Admission Policy

It is worth noting that the soft congestion mechanism on the downlink hardware resource will consider the connections in the related cells on cell group level as possible targets. For example, if an admission request is blocked on downlink hardware, one connection in the cells connected to the same hardware group is possibly targeted with a down-switch (in case there is a valid candidate).

If there are a lot of admission blocks due to RBS HW the solution to this is either a parameter change or adding new hardware with the license keys that are retrieved by contacting Ericsson product management.

The total amount of RBS hardware that can be used might be limited by the following capacity keys:

WCDMA RBS key for Capacity UL CXC4010071/4002 WCDMA RBS key for Capacity DL CXC4010071/4003

The keys set a limit on the available amount of Channel Elements that may be utilized simultaneously in the RBS, separately for uplink and downlink.

Three parameters, ulHwAdm, dlHwAdm, beMarginUlHw and beMarginDlHw, are related to the RBS HW resource control.


LZT 123 8297 R1C © 2006 Ericsson - 81 -

HS Users

The HS-DSCH is a shared transport channel. If a very large amount of users simultaneously are assigned to this channel the throughput per user can become very low. If that is the case, no user might experience a sufficient end-to-end quality. Therefore, it can be beneficial to the operator to be able to limit the number of users that can be allocated to the HS-DSCH in a cell.

Admission Control blocks new radio link admission requests which involve the allocation to HS-PDSCH/HS-SCCH when the number of users assigned to the HS-DSCH in the cell exceeds hsdpaUsersAdm.

If UL 384 is active, an HSDPA RAB establishment is attempted first on the 384/HS RAB. If for some reason (admission, failed path loss check) the packet call cannot be setup on the 384/HS RAB, an attempt is made on the 64/HS RAB provided that the hsdpaUsersAdm value is not exceeded.

Note that the HSDPA admission policy is only applied to requests for new HSDPA connections, which follow the Serving HS-DSCH Cell Selection during RAB Establishment. Therefore, requests related to mobility of existing HSDPA connections, which follow the Serving HS-DSCH Cell Change, are never blocked by the HSDPA admission policy.

DL TX Power

Three parameters, pwrAdm, beMarginDlPwr and pwrAdmOffset, are related to downlink transmitted carrier power and are used by Admission Control to decide which admission requests to admit or reject.

The operator can limit the total maximum power utilized by R99 connections that is allowed to be transmitted by an RBS in a cell by setting maximumTransmissionPower. The remaining power can then be used for transmission of HS-PDSCH/HS-SCCH channels to HSDPA users

This parameter is used when setting up or reconfiguring a cell; when maximumTransmissionPower is higher than the maximum downlink power capability reported by the RBS maxDlPowerCapability, the latter is automatically taken as limit of the total maximum power allowed in the cell. This mechanism simplifies setup and reconfiguration of cells and enables the UTRAN to handle changes in RBS maximum downlink power capability in a transparent fashion.


- 82 - © Ericsson 2006 LZT 123 8297 R1C

By changing the pwrAdm setting, the portion of downlink power reserved for HSDPA connections can be increased or decreased. The default settings balance a mix of R99 and available power for HSDPA, providing a minimum of 25% power to HSDPA, except for those cases when R99 takes part of that power due to mobility and power variations of users in the cell.

For a cell with predominantly R99 traffic, it is possible to increase the power admission threshold in order to maximize capacity. An option is to make use of the complete capability before the congestion resolve mechanism is activated, which is possible thanks to the fast congestion control mechanism in the RBS. This is achieved by setting pwrAdm + pwrAdmOffset + pwrOffset equal to 99% (so that congestion resolve actions can still be triggered). The pwrAdm can be set to 84% maintaining pwrAdmOffset at 10% and pwrOffset at 5%. In order to make sure that no negative impact is produced by such a change, dropped calls and soft handover failures should be carefully monitored.

Figure 3-15 The Downlink Transmitted Carrier Power Admission Policy

When admission requests are blocked by Admission Control, the soft congestion mechanism is activated. This mechanism consists of down-switching an existing non-guaranteed service class connection to a lower bit rate in downlink, after blocking a (non-guaranteed <any>) admission request of a lower rate or a (guaranteed <any>) request. Soft congestion mechanism allows the control of the accessibility for guaranteed service class connections in the system, and the control of the sharing of the available resources among non-guaranteed service class connections in the system.


LZT 123 8297 R1C © 2006 Ericsson - 83 -

The default admission threshold for guaranteed service class connections (pwrAdm) has been set to limit the risk of running into too frequent downlink cell congestion situations under the conditions mentioned. Depending on mobility and service mix situation in the cell (and the specific behavior of the UEs), the admission limit can be increased or decreased. Note that, when changing, it might be required to reconsider the settings for the hand over margin (pwrAdmOffset), the margin for non-guaranteed service class connections (beMarginPwrAdm) and the cell congestion detection margin (pwrOffset).

The default hand over margin for the downlink transmitted carrier power resource (pwrAdmOffset) has been set to have a trade off between the smallest possible reservation for hand over connections and the reasonable blocking for hand over connections. In case of a higher percentage of connections in hand over in a cell and a high experienced blocking of those connections (i.e. resulting in connections being dropped), this margin should be increased.

The margin for non-guaranteed service class connections in a cell beMarginDlPwr has to be tuned according to the required reservation of downlink air-interface resources for guaranteed service class connections in a cell. Note that the setting will influence the intensity of the soft congestion actions on non-guaranteed service class connections in the cell.

Samples of the DL TX power for a cell-carrier could be found in the counter pmTransmittedCarrierPower. This counter is an RBS PDF counter, this includes the power used for HSDPA as well. If checking the nonHS users transmitted carrier power the counter pmTransmittedCarrierPowerNonHs should be used.

How many down-switches due to best effort clean up, which is triggered by DL TX power and code usage admission policies can be found in the counter pmNoOfSwDownNgAdm.


- 84 - © Ericsson 2006 LZT 123 8297 R1C

ASE block

The ASE of a single radio link depends on the radio connection type and is expressed in terms of the equivalent number of speech radio bearers that generate the same amount of air-interface load. Using this definition, a radio link that has, for example, an ASE of three in downlink is expected to generate as much interference in downlink as three speech radio bearers in the cell.

The default setting for the admission policy for the Air Interface Speech Equivalents (ASE) in uplink aseUlAdm is based on the characteristic dimensioning of the system not to be loaded more than 60% of its pole capacity.

In the downlink, the downlink transmitted carrier power is the main dedicated monitored resource used to control the air interface load. aseDlAdm is a complement to the load control when the cell can support so many users that it is close to the pole capacity, which can cause instability. Therefore, if the downlink transmitted carrier power is the limiting resource, aseDlAdm can be set very high, so it does not interfere with the control strategy used for the downlink transmitted carrier power.

In uplink, besides uplink Congestion Control, ASE is the only resource that is controlled to allow admission and modifications. Therefore, the parameters that regulate the uplink ASE admission policy need to be set in order to minimize the risk of going into uplink overload.

Figure 3-16 The Uplink ASE Admission Policy


LZT 123 8297 R1C © 2006 Ericsson - 85 -

For downlink, there is a similar pattern to uplink between the parameters and the ASE monitor policy.

Counter Description

pmSumOfSampAseUl Total ASE UL, that is sum of all sample values recorded

pmSumOfSampAseDl Total ASE DL, that is sum of all sample values recorded

pmNoOfSampAseUl Number of samples of ASE UL increased at every occasion when the corresponding Sum counter is increased, sampled every 30 seconds

pmNoOfSampAseDl Number of samples of ASE DL increased at every occasion when the corresponding Sum counter is increased, sampled every 30s

The formulas for checking the average usage of ASE in the downlink and uplink for a cell can be found below.

Average UL ASE for a cell: AseUlpmNoOfSamppAseUlpmSumOfSam

Average DL ASE for a cell: AseDlpmNoOfSamppAseDlpmSumOfSam

Spreading Factor usage policy

Admission Control controls the spreading factor usage in the downlink at cell level and the number of radio links in compressed mode.

Admission Control blocks non-guaranteed service class radio links depending on the spreading factor usage monitored by the Histogram Monitor.


- 86 - © Ericsson 2006 LZT 123 8297 R1C

Figure 3-17 The Spreading Factor Admission Policy for Non-guaranteed Service Class Radio Links

Note that (guaranteed, <any>) access requests are not influenced by the admission policy, but their contribution to the resource utilization is considered in the monitor.

Admission Control blocks (guaranteed, <any>) admission requests demanding spreading factor 16 in downlink (streaming PS16/128 radio connection type) when the usage of this spreading factor exceeds sf16gAdm. By limiting the amount of streaming PS16/128 users that can share the system resources with other guaranteed service class radio connection types, it is possible to differentiate accessibility of system resources between high (streaming PS16/128) and low consuming radio links within the guaranteed service class.

Admission Control blocks (guaranteed-hs, <any>) admission requests demanding spreading factor 4 in uplink (PS384/HS radio connection type) when the usage of this spreading factor exceeds sf4AdmUl. In cells where the optional PS384/HS radio connection type is activated, sf4AdmUl can be reduced if the uplink is experienced as problematic, for example due to high RTWP or transport network problems.

To prevent unavailability of the transport resources for guaranteed service class connections, the spreading factor usage policy could be defined by setting sf8Adm, sf16Adm, and sf32Adm in a certain way. Note that this could increase the blocking in the radio network, while blocking on the transport network resources is reduced (although that is the reason for blocking).


LZT 123 8297 R1C © 2006 Ericsson - 87 -

The 384/HS RAB is enabled by setting the parameters allow384HsRab to TRUE and sf4AdmUl to a value higher than zero. In cells without any R99 load, field tests have shown that up to four simultaneous UL 384 connections with high activity can be handled without generating excessive interference.

In reality, assuming that the probability of having as many UL 384 connections with the highest activity at the same time is very low, sf4AdmUl can be set to a value up to 4, taking into consideration that:

As no UL channel switching is implemented in P4, allowing many 384/HS users in a cell implies a high channel element consumption, which reduces the amount of hardware resources that could be allocated to other services.

sf4AdmUl should be low in cells where there are no separate AAL2 path resources configured for HSDPA traffic in order to save transport network resources for non-HSDPA traffic.

Uplink interference should be constantly monitored as increased activity in the uplink can create system instability and dropped calls.

Note that the aseUlAdm default value needs to be increased so that four UL 384 users can be accommodated.

Downlink code allocation policy

To reserve codes for users in hand over, there is code blocking for non-hand over requests, while requests for hand over are not blocked by the downlink channelization code admission policy. It should be noted that hand over requests can fail on the allocation of the downlink code and this is detected when allocating the downlink code.

The default admission limit dlCodeAdm is set to 80% (reserving 20% of the code tree for new handover legs). This setting is intended for HSDPA enabled cells and is equivalent to a dlCodeAdm of 75% when HSDPA is not enabled in the cell. In a network with a high degree of R99 packet users or cells with both HSDPA and R99 traffic, this value needs to be increased even further in order to avoid unnecessary code blocking. Setting dlCodeAdm to 85% and beMarginDlCode to 5% will maximize the code tree usage and still allow a margin for new soft handover legs.


- 88 - © Ericsson 2006 LZT 123 8297 R1C

The operator can configure the number of HS-PDSCH codes (SF=16) that should be allocated for a HSDPA capable cell by setting numHsPdschCodes. The maximum number of HS-PDSCH codes is five. Note that the number of HS-SCCH codes (SF=128) is fixed to one, since code multiplexing is not supported, that is never more than one user is transmitting per subframe.

The operator has the possibility to configure and change the number of HS-PDSCH codes allocated in a cell for HSDPA by tuning numHsPdschCodes . The default value (5) aims at maximizing the peak rate of users using the HSDPA feature.

When reducing the number of HS-PDSCH codes numHsPdschCodes, the codes that are to be released are transparently de-allocated, without affecting ongoing traffic. Conversely, in case of an increase, the cell will temporarily be disabled due to its implicit lock/unlock, leading to the release of all the ongoing traffic in the cell.

Figure 3-18 The Downlink Channelization Code Admission Policy

Non-guaranteed, non-handover admission requests are blocked when the resource usage exceeds dlCodeAdm - beMarginDlCode. These service classes can be Packet Switched data and multirab speech service

Guaranteed, non-handover and guaranteed-hs, non-handover admission requests are blocked when the resource usage exceeds dlCodeAdm. These service classes can be Circuit Switched data, HSDPA as well as the packet switched streaming service


LZT 123 8297 R1C © 2006 Ericsson - 89 -

The counter shows the number of RRC connection requests and RAB establishment denied by admission control due to lack of power, code utilization limit, ASE limit and compressed mode limit.

pmNoReqDeniedAdm

The blocking probability can be used together with Erlang metric to measure the cell capacity for a given service. Since a cell serves a mixed traffic, this measure must be used with respect to the amount of traffic measured for other services.

When a request is blocked on the downlink channelization code admission policy, the soft congestion mechanism is triggered.

Code allocation failure for SFn, where n is the spreading factor for a cell could be found in the following formula (as an example the SF128 was used):

100%emptSf128deAllocAttpmNoDlChColureSf128deAllocFaipmNoDlChCo

×

The solution to this problem is to add more carriers or sectorization to reduce the code usage of the cell

Compressed mode

The setting for the compressed mode admission policy, compModeAdm, restricts the number of users in compressed mode. If the presence of compressed mode connections using SF/2 compressed mode technique is high and the quality of the common channels in a cell is degrading, it can be desirable to restrict the number of radio links that are allowed in compressed mode in the cell

How many users are in compressed mode? Well the average number of user in compressed mode for a cell:

mpModepmSampesCo

odepmSumCompM


- 90 - © Ericsson 2006 LZT 123 8297 R1C

LACK OF TRANSMISSION RESOURCES

In P4, transmission resource is not checked in admission control. Therefore, there is probability of having blocking due to lack transmission resources.

The number of setup failures on the downlink baseband pool due to TXB congestion for a RBS, pmSetupFailuresSf4, pmSetupFailuresSf8, pmSetupFailuresSf16, pmSetupFailuresSf32, pmSetupFailuresSf64, pmSetupFailuresSf128, pmSetupFailuresSf256

Normally, in mobile network, the bottleneck for accessibility should not be on transmission part, i.e. 100% AAL2 establishment success rate. However, in WCDMA, requested bandwidth for high data rate services becomes high and as a result, some cells can perform badly. AAL2 establishment failure can be observed by:

• Non-zero radio link setup failure rate in RRC establishment with no admission control blocking, no code allocation failure, no HW failure

• High number of interactive RAB failure (= low interactive RAB establishment successful rate) but not much admission control blocking.

Suggestions to the transmission problems are to add additional E1 (The temporary solution is to set sf8Adm = zero so as to reduce the critical in E1 bandwidth usage) and if necessary, further study on GPEH’s admission control internal event to obtain the exact reason why admission control blocks the setup

LOAD SHARING

Load sharing (see Figure 3-19) enhances the performance of a Radio Access Network by pooling together resources from different parts of the entire network. Currently, two load-sharing features are available in the WCDMA RAN:

• Inter-Frequency Load Sharing

• Directed Retry to GSM

The Inter-Frequency Load Sharing is activated in an RNC by setting the parameter loadSharingRrcEnabled to TRUE. Load-sharing neighbors must be defined before any load-sharing action can take place.


LZT 123 8297 R1C © 2006 Ericsson - 91 -

Directed Retry to GSM is activated in an RNC by setting the flag loadSharingDirRetryEnabled to TRUE.

Inter-Frequency Load Sharing diverts incoming traffic from a more loaded cell in one WCDMA carrier to a less loaded one in another WCDMA carrier. Directed Retry to GSM is a one-way diversion from WCDMA to GSM. Both features are implemented entirely in the RNC.

Figure 3-19 Load sharing

Idle state cell-reselection can also balance cell load to some extent. The 3GPP standard specifies two alternatives for selecting the best cell for a UE in the idle state: the measured quality (Ec/N0) or the measured signal strength (RSCP) of the CPICH. In Ericsson systems, Ec/N0 is used. This indirectly takes into account the cell load.

The load of a WCDMA cell depends on many factors, such as downlink power, uplink interference, code utilization, etc. For load-sharing purpose, only the downlink transmitted carrier power is considered since that is most often the limiting factor on the capacity of a cell.

To better reflect the available resource in a cell, cell load is measured as the ratio between the downlink transmitted carrier power and the admission limit, as given by the cell parameter pwrAdm.

For HSDPA cells, only the non-HSDPA part is counted, i.e., the cell load for load-sharing purpose does not include the power used for HS-PDSCH and HS-SCCH. The downlink transmitted carrier power for the non-HSDPA part is measured by the RBS and periodically reported to the RNC.


- 92 - © Ericsson 2006 LZT 123 8297 R1C

In order to perform the necessary evaluation for making a load sharing decision, a cell has to be aware of the load of all of its load-sharing neighbors. Inter-Frequency Load Sharing is performed during the RRC connection establishment procedure and Directed Retry to GSM during the RAB establishment procedure.

With Inter-Frequency Load Sharing, the cell load is measured directly in terms of the actual downlink power. A UE will be guided to the most suitable cell during the RRC connection establishment.

The load sharing can be monitored by the counters: pmNoOfReturningRrcConn, pmNoLoadSharingRrcConn

Figure 3-20 The load sharing counter flow

(Cell) pmNoLoadSharingRrcConn + (Cell) pmTotNoUtranRejRrcConnReq +

Load Sharing

(Cell) pmNoOfReturningRrcConn +

RNC sends RRC Connection Reject message including the Redirection Info IE

that tells the mobile to try to access the network via the specified frequency

The UE succeeds to

setup RRC conn. in the new freq?

The UE reselects a cell in the specified frequency and tries to access the network

Does the UE return back to

the original frequency?

(Cell) pmTotNoRrcConnectReqSuccess + (Cell) pmTotNoRrcConnectReqCsSuc +

RRC Conn. Setup Failure.

UE goes back to idle state

Random Access Load Sharing is not allowed in this 2nd access attempt

Yes Yes

No No


LZT 123 8297 R1C © 2006 Ericsson - 93 -

Ratio between RRC connection returning and redirection due to load sharing for a cell:

RrcConn aringpmNoLoadShnnrningRrcCopmNoOfRetu

RRC Connection Redirection

In order to reduce RRC Connection direction problems is to do a parameter check. There are many problems that can be reduced from start if this is done.

If there is a too large difference of the pilot power setting between two carriers, it will cause a higher redirection rate. The parameter primaryCpichPower should be checked between the carriers. Reduce the power if the difference is too large.

If there is a too large difference of the RF patterns between two carriers (e.g. due to big difference in tilt angles between cells) it will cause a higher rate. The radio coverage should be checked between the carriers.

Improper inter-frequency cell re-selection parameter setting can also cause a high rate of RRC Connection directions. The inter-frequency cell reselection parameters (e.g. interFreqFddMeasIndicator, qHyst2, qOffset2sn and sInterSeach) should be checked so that they are set properly. If not, correct them.

Improper capacity management parameter setting will also cause a high rate. Check if capacity management parameters (i.e. maximumTransmissionPower and pwrAdm) are set correctly because they affect the decision of redirection. If not, correct them.

Other parameters that should be checked are fachMeasOccaCycLenCoeff, qQualMin, qRxLevMin, maxTxpowerUl,

Incorrect definition of a target cell candidate will increase the ratio. If the coverage of target cell candidate collocates to the source cell. If not, remove this candidate, loadSharingCandidate. Repeaters can also cause incorrect RRC connection redirection to a carrier, which is no coverage.


- 94 - © Ericsson 2006 LZT 123 8297 R1C

Directed Retry to GSM

Speech calls with no ongoing packet connections are considered for Directed Retry during RAB establishment. If the UE supports GSM handover and the load of the WCDMA cell exceeds a certain threshold, the WCDMA RAN will request a blind inter-RAT handover to a pre-configured GSM cell via the core network. The RAN operator has considerable control over this feature. Both the load threshold and the fraction of speech calls to be diverted to GSM are configurable.

The success rate can be monitored by two counters:

pmNoDirRetryAtt gives the total number of Directed Retry attempts and the pmNoDirRetrySuccess gives the number of successful attempts.

The failures can be observed by the successful rate of directed retry to GSM for a cell:

100%edRetryAttpmNoDirectrySuccesspmNoDirRet

×

Note that unsuccessful attempts are picked up by the WCDMA RAN if the call returns to the source cell. The call will then be set up according to the normal call-setup procedure.

If the GSM cell is congested, another TRU can be added or remove the GSM redirection candidate. The loadSharingGsmThreshold can be increased or loadSharingGsmFraction can be reduced so that not many speech connections are redirected to GSM.

There might be GSM coverage problems due to low coverage or to that, a repeater is deployed for the WCDMA resource cell. Either the coverage for the cell should be improved or the GSM redirection candidate should be removed.

Relative parameter: directedRetryTarget,

Note that RRC connection rejection caused by inter-frequency load sharing or re-direction of emergency calls to GSM is not considered as RRC connection setup failure.


LZT 123 8297 R1C © 2006 Ericsson - 95 -

RADIO LINK SETUP

Radio link setup happens when establishing RRC connection or a RAB during FACH -> DCH, e.g. FACH -> PS + voice or FACH -> PS + PS streaming. The channel type up-switching during channel switching , also needs radio link setup procedure.

Power control, admission control, etc.

UE RNC RBS

Radio Link Setup Request

Radio Link Setup Response

Resource allocation

Start Rx and radio connection supervision

AAL2 connection setup

Radio link setup

Figure 3-21 Radio link setup procedures

There is no statistic counter to directly present that radio link setup failure problem during RAB establishment. What that can be done is to analyze the admission control and code allocation counters to determine the probability of occurring such problem.

Radio link synchronization happens during RRC connection establishment. The radio link synchronizations also takes place during new RAB establishment, such as channel type up-switching, for FACH -> DCH, e.g. FACH -> PS + voice or FACH -> PS + PS streaming

UE RNC RBS

Transport channel synch.

Start Tx

L1 synch. Radio Link Restore Indication

Radio link synchronization

Figure 3-22 Radio link synchronization procedures


- 96 - © Ericsson 2006 LZT 123 8297 R1C

Radio link synchronization procedure happens both during RRC connection establishment but also during RAB establishment.

Figure 3-23 Radio Link setup counter flow, continued from the Random Access flow figure Figure 3-7

Loss of RBS Contact

RNC sends “radio link setup request” to RBS; however, the RNC does not receive any response from RBS and the timer expires. This problem is classified as “loss of RBS contact”.

The solution to this problem is to check if the configuration of the transport network is correct. Re-dimension the transmission bandwidth (if needed).

L1 Synchronization failure

It is very difficult to trouble-shoot the radio link synchronization failure. With L1 Synchronization failure, the RRC Setup will fail for the Location Area Update (LAU), as an example.

AAL2 Setup

RNC sends the message RRC Connection Reject

(Cell) pmTotNoUtranRejRrcConnReq

(Cell) pmNoFailedAfterAdm +OK

RNC sends the message RRC Connection Setup

Restore Indication received from RBS

(Cell)pmNoFailedAfterAdm +RRC Conn. Setup Failure. UE goes back to idle state

No

Yes

(Cell) pmTotNoRrcConnectReqSuccess + (Cell) pmTotNoRrcConnectReqCsSuc +

AAL2 failure

Redirection of Emergency

Calls?

Yes

No

Call Redirected to GSM

“RRC Connection Setup Complete”

received

No

(Cell)pmNoCellDchDisconnectAbnorm +

Yes


LZT 123 8297 R1C © 2006 Ericsson - 97 -

The L1 synchronization has to be achieved in both DL and UL. To achieve this, correct power settings are needed for DlinitSirTarget and UlInitSirTarget. The synchronization is first achieved in the DL. The UE will then wait SRBdelay number of frames (1 to 7) before it sends the RRC Connection Setup Complete message. If this fails, no RRC Connection Setup Complete is received from the UE and the RRC Connection is not established.

In TEMS, the L1 synchronization problems can be found when the UE does not send the RRC Connection Setup Complete message. However, some other problems may occur at the same time, as the UE ramps up its transmitting power to the maximum, due to the increased interference.

The UE ramps up its power to the maximum.

The UE ramps up its power to the maximum.

Figure 3-24 L1 synchronization problem

There are several methods to handle these L1 synchronization failure caused due to coverage issues on SRB and/or DCH, to drive test, check the parameter settings of dlattenuation and ulattenuation as well as the antenna configuration. The main thin is to find out if the system is balanced regarding UL and DL cell coverage.


- 98 - © Ericsson 2006 LZT 123 8297 R1C

Note that if antenna configuration and attenuation settings are incorrect, the impact should be in RRC establishments for both signaling and traffic. The parameters cPO and cBackOff can also be increased in order to obtain larger initial DL DPDCH and UL DPCCH powers.

The DL SRB / DCH maximum power, i.e. minPwrMax (only for DL coverage issue) can be increased and the CPICH power can be reduced in order to get a system that is more balanced.

In TEMS Investigation Radio Link Synchronization, failure can be visualized by the figure below.

Figure 3-25 Radio Link Synchronization failure

In the AS, there are two SC’s, RF conditions become very good for one of them and bad for the other, UE TX power is low. It is assumed that the good radio link is out of synchronization because the DL BLER is increasing while the RF conditions become better for one SC. Finally the call drops because high DL BLER.

The initial power setup power parameters ulInitSirTargetSrb, ulInitSirTargetLow, ulInitSirTargetHigh, dlInitSirTarget, should be checked.


LZT 123 8297 R1C © 2006 Ericsson - 99 -

S-CCPCH (FACH1) power

Due to lack of S-CCPCH power, the UE cannot receive the RRC connection setup message.

The following formula should only be used if drive tests have been performed in order to verify the S-CCPCH power.

Percentage of getting AICH but no RRC connection setup, excluding cell (re)selection:

%100AICH_ACK of No

entestablishm RRC duringion (re)select cell of No-setup connection RRC of No -AICH_ACK of No×

Note that above observations cannot absolutely reflect “not enough S-CCPCH power” because losing preamble message could affect the result.

As an example of an AICH problem can be found in TEMS Investigation.

6 RRC Connection request

Very good RF conditions

6 RRC Connection request

Very good RF conditions

Figure 3-26 Radio Link setup failure: AICH problem in TEMS Investigation


- 100 - © Ericsson 2006 LZT 123 8297 R1C

The UE sends out several RRC Connection request but it does not receive the RRC Connection setup from the UTRAN. The RF conditions could be fairly. The UE does not get the AICH. It can be seen in the Random access reports, in the mode reports window.

One solution to the problem is to increase maxFach1Power.

NAS PROCEDURES The Signaling Connection is used to carry the Non Access Stratum (NAS) call setup message between the CN and UE.

The setup of the first Signaling Connection is followed by the procedure Report of Common ID where a permanent NAS UE identity is received by the SRNC from the CN. The permanent NAS UE identity is really the IMSI.

The establishment is initiated by the reception of a RRC message that contains the NAS message that originally triggered the Signaling Connection setup.

Most of the faults regarding the NAS procedures are core network problems and are therefore not discussed further.

CM SERVICE REJECT

During the call setup procedure, the UE receives the CM service reject message with cause network failure, just after that, the system sends the RRC Connection release message.


LZT 123 8297 R1C © 2006 Ericsson - 101 -

CM Service reject with cause:

Network failure

CM Service reject with cause:

Network failure

Figure 3-27 NAS failure: CM service reject in TEMS Investigation

This is not an RF problem, is a network problem

RADIO BEARER SETUP The RAB establishment is done in two parts, the first is the setup of an Iu bearer and the second is the setup of the Radio Bearer (RB).

The establishment and the mapping onto physical channels for each of the different supported RABs will be explained below.

In Figure 3-28 the general procedure of establishing a speech, a CS64 or a streaming 57.6 RAB is shown.


- 102 - © Ericsson 2006 LZT 123 8297 R1C

DPDCH/DPCCH

DPDCH/DPCCH

New Signaling Connection

User plane Radio Bearer

UE State SRB

Cell_DCH

DPDCH/DPCCH

DPDCH/DPCCH

Signaling Connection

Non Access Stratum call setup

RAB assignment request

id= Speech,CS64 or streaming 57.6

1

Setup Iu bearer (AAL2) 2

Setup new Radio Bearer

UE State SPEECH

Cell_DCH

3

Figure 3-28 Speech, CS 64, Streaming 57.6 RAB establishment

1. A ‘RAB ASSIGNMENT REQUEST’ is received from the CN indicating the RAB ID to be ‘speech’. The SRNC determines the new RC configuration (taking into account the existing one) and check the UE capabilities (to check if the new configuration can be supported by the UE).

2. The SRNC initiates the setup of an AAL2 connection for the Iu bearer.

3. The UE is ordered to setup a new Radio Bearer (RB) and activate the new configuration at the desired Current Frame Number (CFN). In the SRNC the MAC shall be reconfigured without waiting for the RLC acknowledge. When finished the UE acknowledges the successful RB setup and the UE will be in CELL_DCH state.

The interactive PS RAB can be set up on either a common or a dedicated channel. The streaming RAB must be setup on dedicated channel. The steps taken to establish an Interactive PS RAB are shown in Figure 3-29 below.


LZT 123 8297 R1C © 2006 Ericsson - 103 -

R A B assignm ent request

id= Interactive1

Existing A AL5 Iu bearer is used

2

UE State SR B

C ell_D CH

D PD CH /D PCCH

D PD CH /D PCCH

Signaling C onnection

Non Access Stratum call setup

N ew Signaling Connection

U ser plane Radio Bearer

FA C H /DC H

R AC H /DC H

D ata Buffers

Setup new R adio Bearer

UE State Cell_FAC H

or C ell_D CH

3

Figure 3-29 Interactive RAB Establishment

1. A ‘RAB ASSIGNMENT REQUEST’ is received from the CN indicating the RAB ID to be ‘interactive’. The SRNC determines the new RC configuration (taking into account the existing one) and check the UE capabilities (to check if the new configuration can be supported by the UE).

2. The existing AAL5 signaling Iu bearer is used to carry the user plane traffic.

3. The UE is ordered by the SRNC to set up a new RB. In the case of Cell_FACH, the UE will also perform a Cell Update after the RB is set up.

Data buffers are used for retransmissions and packet data.


- 104 - © Ericsson 2006 LZT 123 8297 R1C

The RRC has been established and the UE sends the Activate PDP Context Request message to the system. The Radio Bearer Setup message in the DL is never sent, the network eventually sends, and Activate PDP Context Reject message with cause “unspecified”.

Act. PDP Cont. Req. Sent RRC Established

Radio Bearer Setup Message never sent

PDP Context Activation Failure

Act. PDP Cont. Req. SentAct. PDP Cont. Req. Sent RRC EstablishedRRC Established



PDP Context Activation FailurePDP Context Activation Failure

Figure 3-30 PDP Context Activation Failure. Cause: Radio Bearer Setup not sent.


LZT 123 8297 R1C © 2006 Ericsson - 105 -

The RRC has been established and the UE sends the Activate PDP Context Request message to the system. The Radio Bearer setup and Radio Bearer Reconfiguration are performed. The Downlink Direct Transfer message is sent to the UE followed by an Activate PDP Context Reject message with cause “User authentication failed”.

Radio Bearer Setup Complete

User authentication

failed

Radio Bearer Setup CompleteRadio Bearer Setup Complete

User authentication

failed

User authentication

failed

Figure 31: PDP Context Activation Failure. Cause: User Authentication Failed

UE CELL RESELECTION DURING HANDOVER

Accuracy to reflect the “connection setup failure” issue by call setup failures could be affected due to handover. Actually, these equations contain two components: RRC establishment successful rate and RAB establishment successful rate. For RRC establishment, UE camps onto one cell only. Oppositely, UE could be in soft or softer handover during RAB establishment and the RAB attempt and success counters are just stepped referred to the best cell in the active set. Thus, if the cell camped for RRC establishment is not the best cell in active set during RAB establishment these equations cannot reflect the actual setup problem for the cell.


- 106 - © Ericsson 2006 LZT 123 8297 R1C

Attempt to SC122, but SC267 is the

best server

The UE has no time to HO to the best

server

Attempt to SC122, but SC267 is the

best server

The UE has no time to HO to the best

server

Figure 3-32 UE Cell reselection during handover

The UE makes a call attempt to a SC that is not the best server and later it does not have time make the HO because the Ec/No are very bad. This is a cell reselection problem because the UE should make the attempt to the best cell.

UE CELL RESELECTION

The RRC connection can fail if the UE does the cell reselection too often. Possible reason of having always cell reselections is idle ping-pong, which may be caused due to improper cell reselection parameter setting and/or pilot pollution

The UE sends only one RRC Connection Request and does not receive the RRC Connection setup from the UTRAN. Immediately after this, the UE starts to read SIB. RF conditions are good. It is a UE problem because the UE does not re-transmit the RRC Connection Request.


LZT 123 8297 R1C © 2006 Ericsson - 107 -

Good RF Conditions

Only one RRC Connection Request

and the UE reads SIBGood RF Conditions

Only one RRC Connection Request

and the UE reads SIB

Figure 3-33 UE Cell Reselection

Note that the UE may perform cell re-selection during RRC Connection, it may repeat RRC Connection Request message N300 times which may arrive at different cell, and the fact that WCDMA RAN does not double count the duplicated RRC Connection Request message, there is a chance that access success rate for some cells may show larger than 100% success rate. The access success rate of better than 100% happens when the attempt registered at different cell than where the success registered. The end result is slightly larger success rate for the cell that completes the access and a slightly less success rate for the cell that starts the access.

Normally, treSelection will affect UL RSSI performance because if the UE camps onto a cell, which is not the best cell, the UE will transmit slight larger UE TX power during RRC establishment and it will consequently generate more UL RSSI to the adjacent cells.

To solve the reselection problem, the pilot pollution has to be reduced and re-plan the cell coverage if needed. The cell reselection parameters (i.e. qQualMin, qRxLevMin, maxTxpowerUl, qHyst2, qOffset2sn, treSelection and sIntraSeach) must be checked if they are set properly.


- 108 - © Ericsson 2006 LZT 123 8297 R1C

TEMS INVESTIGATION FINDINGS Below in the following sections there are several different problems found with TEMS Investigation in a WCDMA network.

PDP REJECTED

The RRC has been established and the UE sends the Activate PDP Context Request message to the system. The Radio Bearer setup and Radio Bearer Reconfiguration are performed. The Downlink Direct Transfer message is sent to the UE followed by an Activate PDP Context Reject message with cause “unspecified”.

Radio Bearer Setup Complete

Activation rejected,

unspecified

Radio Bearer Setup CompleteRadio Bearer Setup Complete


unspecified


unspecified

Figure 3-34 PDP Context Activation Failure. Cause: Radio Bearer setup then PDP rejected

PPP LINK CONTROL TERMINATED

The RRC has been established and the UE sends the Activate PDP Context Request message to the system. A Downlink Direct Transfer message is sent to the UE followed by the Activate PDP Context Reject one with cause “The PPP link control terminated”.


LZT 123 8297 R1C © 2006 Ericsson - 109 -

Radio Bearer Setup Not Sent

Activate PDP Context Reject

after DL Direct Transfer

Radio Bearer Setup Not SentRadio Bearer Setup Not Sent


after DL Direct Transfer


after DL Direct Transfer Figure 3-35 PDP Context Activation Failure. Cause: PPP Link Control terminated


- 110 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

4 Service Retainability

LZT 123 8297 R1C © 2006 Ericsson - 111 -


Objectives


• Understand how to analyze and interpret the collected data in order to improve the Neighbor handling and the Hanover Performance

• Analyze RAN performance and propose adjustments related to retainability


- 112 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank


LZT 123 8297 R1C © 2006 Ericsson - 113 -

RETAINIBILITY ..................................................................................115

RETAINABILITY WORKFLOW..........................................................115

WORST CELLS .................................................................................116 SPEECH .......................................................................................................116 VIDEO...........................................................................................................116 PACKET SWITCHED DATA .........................................................................117

DROPPED CALLS.............................................................................117 UL OUT OF SYNCH .....................................................................................118 CONGESTION ..............................................................................................126 WCDMA RAN HANDOVER ..........................................................................129 SOFT/SOFTER HANDOVER........................................................................130 HSDPA MOBILITY ........................................................................................146 INTER-FREQUENCY HANDOVER ..............................................................149 INTER-RAT HANDOVER..............................................................................152 MISSING NEIGHBOUR RELATIONS...........................................................155 OTHER REASONS .......................................................................................156

WNCS (WCDMA NEIGHBOURING CELL SUPPORT) .....................157

TEMS INVESTIGATION FINDINGS...................................................159 LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS....................159 INTER-RNC HANDOVER FAILURE.............................................................161 UE RELATED PROBLEM .............................................................................162


- 114 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank


LZT 123 8297 R1C © 2006 Ericsson - 115 -

RETAINIBILITY This module is done after the accessibility module. Retainability is defined as the ability of a user to retain its requested service once connected for the desired duration.

There are a number of factors that influence Retainability performance after call establishment in the network. These factors include:

• Handover performance (soft/softer/Iur/IFHO/IRAT) and missing neighbor cell

• UL/DL imbalance

• Incorrect parameter settings (power, admission, release)

• Congestion

• Radio environment impact (corner effect, fast Ec/No drop, Pilot pollution etc)

• Node Hardware failure

• E1/T1 Congestion

RETAINABILITY WORKFLOW Below the Figure 3-2 is showing the Retainability workflow.

At performance monitoring the worst cells regarding retainability is sorted out.

At performance analysis the worst cells are analyzed in the same order as shown in the Figure 4-2, the network initiated abnormal call releases. First the Synchronization performance is analyzed, then the Congestion control, SHO functions, IRAT Handovers


Through the Verification phase, the collected statistics before anything is implemented is compared to the statistics collected after the implementation is done. This is to ensure that there has been an improvement.


- 116 - © Ericsson 2006 LZT 123 8297 R1C

Figure 4-1 A The Retainability workflow

At the end of the workflow, when the verification of the implemented changes is done, then the optimizer should continue to the other modules, in this case the integrity module.

WORST CELLS In terms of the ranking of the worst performing cell, both the number of drop calls and the dropped call rate should be considered. Alternatively, ranking can be done based on the net contribution of each individual cell to the total dropped call on RNC level.

Check where worst performing cells are located. If they are in border area between two RNCs, Iur handover performance should be monitored.

In order to identify the worst performing cells due to dropped call the following formulas could be used.

SPEECH

Shows speech call drop rate for originating and terminating calls.

)chleaseSpeecReRabpmNoSystemhleaseSpeecReRabpmNoNormal(hleaseSpeecReRabpmNoSystem

+×100

VIDEO

Shows video call drop rate for originating and terminating calls.



Recommendation &

Implementation

Verification of changes O

ther Modules

pmSystemRabRelease<RAB> pmNormalRabRelease<RAB> pmNoSysRelSpeechULSynch pmNoOfTermSpeechCong pmNoSysRelSpeechSoHo

UL out of Synch Congestion control, SHO functions IFHO functions IRAT Handovers

ReleaseConnOffset maxTxPowerUl,SirMax, MinPwrRl, treselection, timetotrigger1, reportingrange1


LZT 123 8297 R1C © 2006 Ericsson - 117 -

) Cs64RabReleasepmNoSystemleaseCsReRabpmNoNormal(Cs64RabReleasepmNoSystem

+×

64100

PACKET SWITCHED DATA

Shows dropped call for Interactive PS calls regardless of DCH or FACH state including HSDPA calls:

( ))Packet RabReleasepmNoSystemRe(

Packet RabReleasepmNoSystem100+

×tleasePackeRabpmNoNormal

Shows dropped call for PS 64 streaming calls.

( )tStreamleasePackeRabpmNoSystemtStreamleasePackeRabpmNoNormaltStreamleasePackeRabpmNoSystem

ReReRe100+

×

DROPPED CALLS There are several known reasons for speech drop that can be analyzed in order to understand the root causes for drop and find out how to reduce drop call due to these reasons.

1- Drop due to UL out of sync (Radio Connection supervision)

2- Drop due to congestion (Congestion control)

3- Drop due to soft/softer handover (Soft Handover Functions)

4- Drop due to IRAT Handovers (IRAT Handover Functions)

5- Drop due to other reasons

Abnormal call releases for speech, CS64 and CS 57 calls can be initiated either by the UE or by the UTRAN (RNC).

For speech, CS64 and CS57 calls the abnormal release leads in any case to the Signaling Connection Release procedure in the counter flow charts. The Signaling Connection Release is the release of the connection of the UE with the CN; it includes the release of all radio resources (RRC Connection Release).


- 118 - © Ericsson 2006 LZT 123 8297 R1C

In Figure 4-2 the network initiated abnormal call releases are shown. Any abnormal release due to RNC algorithms (Radio Connection Supervision, Congestion Control, Soft-Handover functions, IRAT Handover Functions) or other unrecoverable failures (signaling failures, detected UE failures, etc) are contained in this group.

Figure 4-2 Network Initiated abnormal call releases

The “Other Failures Detected” blocks collecting any other unrecoverable failures, those are not included by the first line blocks. These failures will not be further investigated in this document since there are no counters related. Some specific information about these failures can be obtained by the cause of the Iu Release Request or the Iu Release Command messages sent in the Signaling Connection Release or by other specific trace in the RNC and/or CN.

UL OUT OF SYNCH

Out of synch drops are found through the function Radio connection supervision.

The aim of this function is to monitor the status of the radio connection and to initiate the release of signaling connection in case of radio connection is lost.

Three different supervision algorithms can trigger the condition of “radio connection lost”:


LZT 123 8297 R1C © 2006 Ericsson - 119 -

• Supervision of radio link synchronization status

• Supervision of RLC protocol (Layer 2 failures)

• Supervision of connections on common channels

The supervision of radio link synchronization status is performed on dedicated channels only. The supervision of RLC protocol is performed on all channels (dedicated and common). The supervision of connection on common channels is performed (obviously) only on common channel. The RLC supervision works in parallel with the others.

One of the other reasons for dropped call is drop due to uplink out of synch. Out of synch is a symptom for other problems such as lack of DL coverage, lack of UL coverage, high UL interference and etc in the network.

There is no straightforward approach to identify reasons behind out of synch problem. However, it is still possible to try the following methods to find lack of coverage.

Figure 4-3 Radio Link Set Supervision States

Idle state is the default state and entered after a dedicated RLS Release. Resources for dedicated RLS have not been allocated or configured.


- 120 - © Ericsson 2006 LZT 123 8297 R1C

Initial Synchronization state is entered when the resource for the dedicated RLS is allocated and configured, but synchronization has not yet been reached. This state can only be entered from the idle state

In sync state is entered when the UL synchronization is achieved from the Initial Synchronization, Out-of-Sync state, or Wait for In-Sync. When the BER is below the threshold value for a number of consecutive frames, the RLS is considered re-established. The RBS resumes regulating the output power according to the Power Control mode

Wait for In-sync is a state where the criteria for out of sync has been met. The RBS starts a timer (timerlost) in order to wait for the synchronization to be re-established. Whenever the RLS becomes synchronized, this timer is stopped. If the RBS does not re-establish UL synchronization during the period of time given by the timer timerlost, the "Out-of-Sync" state is entered and the RLS Supervision algorithm sends the NBAP message RADIO LINK FAILURE INDICATION to the SRNC.

Out-of-Sync state is entered when the UL synchronization is lost. When the pilot BER threshold value has been exceeded for a number of consecutive frames, the RLS is considered out of sync.

When nOutSyncInd number of consecutive frames are out-of-sync a timer rlFailureT is started and at expiry the RLS is considered out-of-sync and Radio Link Failure is reported to the SRNC. When the RLS is out-of-sync and nInSyncInd number of frames are in-sync, the RLS is considered in-sync and Radio Link Restore is reported to the SRNC.

The connection is considered lost by the RCS when the last RLS, for the connection, has been out-of-sync for a time given by the parameter dchRcLostT. However, for an HSDPA connection, the connection is considered lost by the RCS when the RLS that contains the Serving HS-DSCH cell, has been out-of-sync for a time given by the parameter hsDschRcLostT, the timer dchRcLostT is not used in this case. In both cases, when the timer expires, the signalling connection is released. The RNC level parameter hsDschRcLostT can be set to a lower value than default so that the HSDPA performance does not degrade drastically before the connection is released. This can be a way of tuning HSDPA borders (Iur or when entering a non-HSDPA coverage area), where the HSDPA call is released and re-established on either HSDPA or R99.

The RBS, in order to retain synchronization, generates UL-TPC bits in a pattern that gradually increases the output power. TPC received in UL (DL-TPC) are not used


LZT 123 8297 R1C © 2006 Ericsson - 121 -

Shows fraction of drop due to uplink Out of Sync reason.

( )( )hleaseSpeecReRabpmNoSystemhleaseSpeecReRabpmNoNormal

ynchlSpeechULSRepmNoSys+

×100

The amount of dropped call due to UL out of synch is depended on the value of ReleaseConnOffset parameter. If this parameter is set high, then the uplink RSSI will increase and will impact drop due to uplink Out of Sync.

There are a number of parameters that impact in- and out of synch issues. These parameters could be of interest when study out of synch and its impact. Changing parameters such as nInSyncInd, nOutSyncInd and rlFailureT might help to recover out of synch when it lasts for short period of time and it not caused due to lack of coverage.

In TEMS Investigation, the problem of UL out of Synch can be found through high UE TX power. In soft handover, the UE connects to a distant cell in the active set and this distant cell is the best serving in active set.

Figure 4-4 UE TX Power vs. CPICH Ec/No and RSCP

CPICH_RSCP CPICH_Ec/No

Tim

Cell A

HO area HO area

Overshooting cell, e.g. cell

UE Tx PWR

TimHO area HO area

Max allowed UE Tx PWR

Drop


- 122 - © Ericsson 2006 LZT 123 8297 R1C

The trend of UL performance of the best serving cell is very good, e.g. CPICH_RSCP is increasing. However, the UE is always requested to transmit its maximum transmission power.

When all other cells have been released and only that distant cell is kept in the active set, the connection will drop due to UL out of synchronization. It should be noted that UTRAN sends rrcConnectionRelease message with cause = normalEvent to the UE to release the connection if UL out of synchronization.

This problem is caused due to cell overshooting. The direct solution is to remove the coverage caused by this overshooting cell

Increasing the RBS search window size could overcome this problem. However, it is not good solution because overshooting will cause interference (i.e. lower capacity) and handover sequence problem.

Dropping the connection implies the RBS really receives not enough power. Thus, it always sends power up TPC commands.

In the measurement report the timing from the RBS is quite high


LZT 123 8297 R1C © 2006 Ericsson - 123 -

Figure 4-5 UL out of synch

Downlink supervision is carried out by a similar supervision function located in the UE. The control time constant for the Radio Connection Supervision algorithm must be set longer in WCDMA RAN than in the UE (cchWaitCuT > t305), to allow the UE to have time to detect failure and try to restore radio connectivity.

UL Coverage

Check the value of maxTxPowerUl and sirMax parameters. maxTxPowerUl parameter should be set based on the most used mobile class type in the network and sirMax parameter should be set to its maximum value (17.3 dB). These two parameters have impact on uplink coverage. Low setting of maxTxPowerUl and sirMax parameters will limit UE to transmit enough power when it needed to maintain the radio link connection and might cause lack of uplink coverage in the network.

Note that bad performing UEs in situation when the coverage gets poor might rapidly increase SIR target and consequently gives spikes in uplink RSSI. Setting sirMax on maximum value might contribute to increase of uplink RSSI for this kind of UEs. sirMax is a RNC level parameter. A very high setting of this parameter might cause increase in UL RSSI where bad performing UEs increase rapidly their SIR target to the maximum allowed SIR target or where UEs get into very poor radio coverage area and increase their SIR target to compensate lack of coverage (anti windup function can not control this type of UE behavior).

Out of uplink coverage may be caused not only by low CPICH_RSCP but also by high UL_RSSI. In TEMS Investigation the symptoms of poor UL coverage (i.e. CPICH_RSCP < -100dBm) is that the DL performance could be either good or bad (i.e. CPICH_Ec/No = any value). The UE always ramps up its power to maximum from a very low calculated initial UE Tx power. Due to this UL poor coverage issue, even the UE ramps up its power to maximum, the network still cannot receive request message.


- 124 - © Ericsson 2006 LZT 123 8297 R1C

Figure 4-6 UL/DL Imbalance

After a while, the UTRAN normally sends the rrcConnectionRelease message with cause = normalEvent to the UE to release the connection. One of the timers that are checking the RL supervision, the rlFailureT, times out.

The UL and DL coverage imbalance can be solved by reducing the pilot power. Often by turning the pilot power down there will be a coverage hole and in the end a new site has to be added. Imbalance will cause Inner loop power control problems to due UE ray combining inefficiency and UL easy become Out-Of-Synch.

UTRAN sends rrcConnectionRelease message with cause = normalEvent to the UE to release the connection.

The UE ramps up its power to max from a very low calculated initial UE Tx power. The network can’t receive request messages.


LZT 123 8297 R1C © 2006 Ericsson - 125 -

By using GPEH event “INTERNAL_MEASUREMENT_HANDLING_ EVALUATION” it is possible to get number of times event6a is reported. Event6a shows maximum transmitted power reported from UE based on the value of ueTxPowerThresh6a parameter in best serving cell. If ueTxPowerThresh6a parameter is set to 21 and event6a is reported in GPEH, then there is a risk for end-users to be located in area with lack of coverage in the concerned cell.

DL Coverage

The following approach might be used to give some indications about lack of downlink coverage.

By using GPEH events:

“INTERNAL_MEASUREMENT_HANDLING_ EVALUATION” it is possible to get number of times event2d is reported. Event2d shows how bad measured pilot Ec/No is in best serving cell.

“INTERNAL_RADIO_QUALITY_MEASUREMENT” it is possible to get downlink code power per call basis. This power reporting is not so frequently but it still gives indications on used code power on downlink. For cases where GPEH trace shows high code power usage close to max power available on concerned RAB, it is a good indication of lack of downlink coverage in recording cells.

If the conclusion is that there is lack of downlink coverage, maximum allowed downlink code power on relevant RAB should be increased for concerned cells

UL RSSI

High uplink RSSI will influence uplink radio quality and increase risk of getting into out of synch problem.

MinPwrRl is a cell level parameter. This parameter impacts uplink RSSI and should not be set less than –150. Other setting such as –120 can be tested to see how much uplink RSSI will be reduced. At the same time total carrier power should be monitored to see eventual increase in power consumption when changing minPwrRl parameter. A trade off can be done to see drop call or uplink RSSI reduction in relation to eventual carrier power increase for concerned cells.


- 126 - © Ericsson 2006 LZT 123 8297 R1C

For the worst performing cells a number of RBS counters such as pmAverageRssi, pmTransmittedCarrierPower and pmOutOfSynch can be activated before changing minPwrRl parameter to monitor the performance of worst performing cells.

CONGESTION

A reason for dropped call seen through statistic is congestion. If any portion of drop caused by congestion it will mean that more HW is needed for RBS based band pool capacity.

Shows fraction of speech drop due to congestion action


SpeechCongpmNoOfTerm+

×100

Shows fraction of video call drop due to congestion action

( )( )6464

100leaseCsReRabpmNoSystemleaseCsReRabpmNoNormal

CsCongpmNoOfTerm+

×

Congestion control is used to resolve overload in the uplink and the downlink. It uses Power and uplink Received Total Wideband Power (RTWP) measurements. In case of overload, congestion control reduces bit rates of delay tolerant existing connections or as a second option, removes existing connections.

The threshold for detection of downlink congestion is determined by pwrAdm + pwrAdmOffset + pwrOffset and the Hysteresis time pwrHyst.

Congestion due to radio overload in uplink is detected when the uplink Received Total Wideband Power (RWTP) exceeds a certain configurable threshold for a longer time than the Hysteresis time. The threshold for detection of uplink congestion is determined by iFCong + iFOffset and the Hysteresis time is determined by iFHyst.

Congestion Control considers uplink congestion to be resolved when the uplink RTWP for a particular cell is below iFCong for a longer time than the Hysteresis time (or until the next periodic event-based measurement report for uplink RTWP arrives indicating that the resource level is below the threshold).


LZT 123 8297 R1C © 2006 Ericsson - 127 -

The parameter pwrHyst should cope with short length peaks in the downlink transmitted carrier power that in general do not lead to downlink cell congestion situations, so that unnecessary blocking of the cell and (even worse) unnecessary congestion resolve actions are avoided.

Field tests have shown that the default setting is acceptable in most cases. Nevertheless, pwrHyst can be modified depending on the duration of the peaks in the downlink transmitted carrier power, which may be influenced by the UE behavior, radio environment and power control settings.

The detection level for uplink cell congestion is determined by iFCong + iFOffset and by the Hysteresis time setting iFHyst.

In general, the expected level of uplink Received Total Wideband Power (RTWP) is formed by the sum of the following components:

• Thermal noise floor (for example, -107.5 dBm)

• RBS noise figure (typically 2 dB with Ericsson ASC/TMA or 3 dB without ASC/TMA)

• Noise rise due to load (60% loading in uplink corresponds to 4 dB)

• Compensation for innacuracies in Radio Network algorithms (around 2 dB)

Detection of uplink cell congestion could be on a level which is around 2 dB extra noise rise (parameter iFCong).

By default, the uplink cell congestion detection is disabled by setting iFCong to -49.9 dBm, iFOffset to 0 and iFHyst to 10 ms. In many networks, UL interference is not the main limitation and this setting is acceptable in most cases. If there is a high degree of uplink interference in a cell, it can be relevant to tune these parameters to resolve excessive cell breathing.

When setting the parameter iFHyst, short duration UL interference peaks should be disregarded as, in general, they do not lead to uplink cell congestion. Unnecessary detection of uplink congestion leads to unnecessary blocking of the cell. Field tests have shown that there might be special conditions in a cell or specific UE behaviors that may require this parameter to be tuned.

Another reason for dropped call seen through statistic is congestion. If any portion of drop caused by congestion it will mean that more HW is needed for RBS based band pool capacity.


- 128 - © Ericsson 2006 LZT 123 8297 R1C

This can also be monitored by using for instance RBS counters such as pmSetupFailuresSF128 in downlink and pmSetupFailuresSF64 in uplink for speech calls to identify capacity shortage in downlink or uplink based band pool.

Other counters that should be checked if the drop rate due to high congestion is listed in the table below:

Counter name Function Description

pmNoReqDeniedAdm

RRC request and RAB establishment deny

The counter shows the number of RRC connection requests and RAB establishment denied by admission control due to lack of power, code utilization limit, ASE limit and compressed mode limit.

pmNoOfTermSpeechCong

Speech call termination

The counter shows the number of times speech call terminated due to cell congestion

pmNoOfTermCsCong

Cs call termination

The counter shows the number of times CS call (excluding speech) terminated due to cell congestion

pmTotalTimeDlCellCong DL Cell Congestion Duration

It shows amount of time in seconds during the measurement period that cell was congested in DL

pmTotalTimeUlCellCong UL Cell Congestion Duration

It shows amount of time in seconds during the measurement period that cell was congested in UL

PmSumOfTimesMeasO1D1 Magnitude of High DL Power

It shows number of times congestion control is triggered due to high DL carrier power

pmNoOfSwDownNgCong Down switch from DCH to common channel due to congestion control

The counter shows number of times packet data connection down switches to common channel initiated by congestion control. If the down switch is not allowed to common, then the counter shows number of packet data system release due to congestion

pmNoOfSwDownNgAdm Down switch from DCH to DCH due to admission control

The counter shows number of times packet data connection down switches from DCH 64/384 to DCH 64/128 and DCH 64/128 to DCH 64/64 initiated by admission control due to lack of downlink power or code limit


LZT 123 8297 R1C © 2006 Ericsson - 129 -

WCDMA RAN HANDOVER

There are four types of handover supported in the WCDMA RAN:

• Soft/Softer Handover

• Inter-Frequency Handover

• Inter Radio Access Technology (Inter-RAT) handover

• HS-DSCH Handover

In reality a handover drop cause includes due to same trigger points missing neighbor/overshooting. The same triggers are used for both drop reasons.

Figure 4-7 Entities Involved in Reporting, Evaluation, and Execution of Handover-Related Functions


- 130 - © Ericsson 2006 LZT 123 8297 R1C

SOFT/SOFTER HANDOVER

The soft/softer handover functionality includes decision on how many cell carriers to connect in soft/softer handover and functionality for setting up and releasing connections between the RBS and the UE. Soft/softer handover is supported for dedicated channels.

RBS 1 RBS 2

RNC

Figure 4-8 Soft Handover

In soft handover the UE is communicating with two or more sectors on different RBSs as illustrated in Figure 4-8. In softer handover the UE is communicating with two or more sectors on the same RBS. The counter flow for the cell reselection for Inter-frequency handovers are shown in the

Figure 4-9


LZT 123 8297 R1C © 2006 Ericsson - 131 -

Figure 4-9 The counter flow for soft/softer handover

A valid cell is a cell that is included in the neighbor set.

Soft/Softer HO replacement procedure is made up of both Soft/Softer HO addition and removal in sequence. Upon successful Soft/Softer HO replacement the counters pmNoTimesRlRepInActSet and pmNoTimesRlDelFrActSet are incremented for the cell that is removed from the AS and pmNoTimesRlAddToActSet is stepped in the cell that is added.

Intrafrequency Measurement Report Evaluation

1c event including quality measure and

cell synch info

1d event including quality measure and

cell synch info

Soft/Softer HO Removal

Soft/Softer HO Replacement

Abnormal Call Release

Soft/Softer HO Addition

Best cell Update

Not valid cell and reported cell exceeds

best cell + Rel. Conn. Offset

quantity?

Not valid cell and reported cell exceeds

best cell + Rel. Conn. Offset

quantity?

1 b event 1a event including quality measure

and cell synch info

Speech call only (Cell) pmNoSysRelSpeechNeighbr + (Cell) pmNoSysRelSpeechSoHo +

Not a

valid cell?

Yes Yes

Yes

No No

No


- 132 - © Ericsson 2006 LZT 123 8297 R1C

The first thing to check is to see if any fraction of drop call is related to handover. The following formula shows the fraction of drops due to HO action when a valid or non-valid cell cannot be added to active set. This also includes drops due to missing neighbour.

( )SpeechRabReleasepmNoNormal SpeechRabReleasepmNoSystemSpeechSoHopmNoSysRel+

×100

The following formula shows the failure rate for RL addition/replacement to active set

( )etlAddToActSpmNoTimesR ToActSetellFailAddpmNoTimesCToActSetellFailAddpmNoTimesC

+×100

The UE reselects the new cell, if the cell reselection criteria are fulfilled during the time interval treSelection, see Figure 4-10.

Qmeas(n)

Qmeas(s)

qoffset(s)

qHyst(s)

R(s)

R(n)

treSelection

Cell reselection

time

Quality

Figure 4-10 The cell reselection evaluation process.

The cell reselection criteria are used for intra-frequency, inter-frequency and inter-RAT cells.

The decision on when measurements on intra-frequencies should be performed is made by the parameter sIntraSearch in relation to Squal.


LZT 123 8297 R1C © 2006 Ericsson - 133 -

If Squal > sIntraSearch the UE does not need to performintrafrequency measurements.

If Squal ≤ sIntraSearch the UE performs intrafrequencymeasurements.

If the sIntraSearch is not sent to the serving cell, the UE performs intrafrequency measurements.

The UE shall measure CPICH Ec/No and CPICH RSCP at least every TMeasureFDD for intra-frequency cells. The UE shall filter Ec/No and RSCP measurements of each measured intra-frequency cell using at least 2 measurements, which are taken so that the time difference between the measurements is at least TMeasureFDD/2.The UE shall evaluate this intra-frequency cell for the treSelection time and if it is still better than the serving cell the UE shall reselect that cell.

UE Cell reselection

The RRC connection can fail if the UE does the cell reselection too often. Possible reason of having always cell reselections is idle ping-pong, which may be caused due to improper cell reselection parameter setting and/or pilot pollution.

Areas with many equally strong CPICHs, so-called "pilot pollution areas", should be avoided. Preferably only one dominant CPICH should exist. UEs in pilot-polluted areas may experience unreasonable high Active Set update rates and a higher probability that the Active Set does not at all times contain the most appropriate cells. With extensive pilot pollution in the system the signaling load increases. Pilot pollution gives a high average number of active radio links, which decreases the traffic capacity and reduces the probability that the UE gets all neighboring cells included due to the size limited monitored set.

It is recommended to design the system so that the idle mode cell selection/reselection borders coincide with the connected mode HO borders.

It is also recommended that the CPICH power setting initially balances the UL and DL in the handover area. A balanced system in this context means that the pathloss is equal at the handover borders for every cell to be included, or are already included in the Active Set. The handover areas and where the handover decisions are taken can be changed by changing CPICH power levels for the cells.


- 134 - © Ericsson 2006 LZT 123 8297 R1C

The UE sends only one RRC Connection Request and does not receive the RRC Connection setup from the UTRAN. Immediately after this, the UE starts to read SIB. RF conditions are good. It is a UE problem because the UE does not re-transmit the RRC Connection Request.

Note that the UE may perform cell re-selection during RRC Connection, it may repeat RRC Connection Request message N300 times which may arrive at different cells, and the fact that WCDMA RAN does not double count the duplicated RRC Connection Request message, there is a chance that access success rate for some cells may show larger than 100% success rate. The access success rate of better than 100% happens when the attempt registered at a different cell than where the success registered. The end result is slightly larger success rate for the cell that completes the access and a slightly less success rate for the cell that starts the access.

Normally, treSelection will affect UL RSSI performance because if the UE camps onto a cell, which is not the best cell, the UE will transmit slight larger UE TX power during RRC establishment and it will consequently generate more UL RSSI to the adjacent cells.

To solve the reselection problem, the pilot pollution has to be reduced and re-plan the cell coverage if needed. The cell reselection parameters (i.e. qQualMin, qRxLevMin, maxTxpowerUl, qHyst2, qOffset2sn, treSelection and sIntraSeach) must be checked if they are set properly.

In TEMS Investigation the cell reselection problem can be found in many ways. As an example the UE has sent out the rrcConnectionRequest message for access. During the UE is waiting for rrcConnectionSetup message It detects another better (i.e. better CPICH_Ec/No) cell and tries to do a cell re-selection. It happens when the number of rrcConnectionRequest is still less than (N300 + 1).

When the UE tries to do cell reselection the number of rrcConnectionRequest finally reaches to maximum (i.e. n300 + 1).

The setting for treSelection can be too short. Optimization is needed in order to avoid the idle mode pilot pollution.

If the UE does not send out the rrcConnectionRequest after cell re-selection., it could be an UE problem, which is not RF related.

The table below is showing the rrcConnectionRequest messages together with the scrambling code and the corresponding EcNo value of the example below.


LZT 123 8297 R1C © 2006 Ericsson - 135 -

Time Type of message Content

11:26:49.87 rrcConnectionRequest SC=82 CPICH_Ec/No=-4dB

11:26:51.91 rrcConnectionRequest SC=98 CPICH_Ec/No=-8dB

11:26:51.95 rrcConnectionRequest SC=98 CPICH_Ec/No=-8.5dB



Figure 4-11 Cell re-selection was done between SC98 and SC82


- 136 - © Ericsson 2006 LZT 123 8297 R1C

Handover parametes

The recommended setting of maxActiveSet parameter is 3. Increasing the value leads to an increase in the average number of active radio links. The difference will be minor in some areas, whereas in areas with many strong CPICHs, the average number of active radio links will increase considerably. In UL more active radio links on average gives a slightly lower transmitted power. In DL more active radio links gives a lower transmitted power per link, but the sum of transmitted power on active links might not be lower.

The number of Active Set updates per minute is dependent on the radio environment and there is no direct relation to the setting of the maxActiveSet parameter

Figure 4-12 shows the parameters involved with a handover.

Figure 4-12 Cell re-selection

TimeToTrigger1- and reportingRange1- parameters might be reviewed and other settings than the default (current) setting might be used. Note that these parameters are RNC level parameters and influence the whole RNC. Hence it might not be possible to change these parameters due to negative impact on other cells that handover functions well there.


LZT 123 8297 R1C © 2006 Ericsson - 137 -

The size of the soft and softer handover area can be changed by the reportingRange1a and reportingRange1b parameters. The recommended parameter values are 3 dB and 5 dB, respectively. Increasing reportingRange1a or reportingRange1b results in larger soft/softer handover area, that is, more UEs will be in soft/softer handover on average. The average number of active radio links in the network can grow very large when increasing the value of reportingRange1a and reportingRange1b.

Figure 4-13 Field tests with settings of the reportingRange parameters

Figure 4-13 shows an example from field measurements. The actual Active Set size has been logged when driving a 10-minute route through a pilot-polluted area. The same route was driven four times, each time with different settings of reportingRange1a and reportingRange1b, but keeping the delta between them constant. maxActiveSet was set to 3 during all measurements. As seen in the figure, the distribution of measurement points having different Active Set sizes change gradually. Using reportingRange1a = 3 [dB] and reportingRange1b = 5 [dB], the average number of cells in the Active Set is expected to have the following distribution: 60% for AS=1, 30% for AS=2, and 10% for AS=3. The highest parameter settings cause the UE to be in soft/softer handover in basically all spots along the route, a situation that is unfavorable for system capacity.


- 138 - © Ericsson 2006 LZT 123 8297 R1C

The recommended value for hysteresis1c is 1 dB. A higher value causes a decreased Active Set update rate, that is, a higher CPICH signal is required from a new cell to replace the weakest cell in Active Set. What would make the Active Set update rate decrease is the reduction of event1c, since event1a and event1b are kept fairly constant. But a higher value of hysteresis1c may cause too late an addition of new cells in Active Set.

It is important to remember that the measurements used for handover event evaluation are made on the downlink CPICH. This means that using different settings for primaryCpichPower (power assigned to the CPICH) on neighboring cells will create a more complicated situation. Unnecessary destructive interference might be the result in the UL, since the UE will not be power controlled by the weaker cell until it has been added to the Active Set.

The UE face problems in areas were many pilots have similar received Ec/No (especially in low RSCP areas). In order to help the UE, the time to trigger for events e1a, e1b and e1c can be raised. However, as stated above, the parameters affect the whole RNC and should be carefully considered. The increase reduces the number of handover attempts, especially for the undesired flashing pilots. It can also lead to a higher drop rate with highways in the area of fast fading.

timeToTrigger1a indicates the time in ms between event detection and sending of Measurement Report, for event 1a (New candidate cell for addition in Active Set)

timeToTrigger1b indicates the time in ms between event detection and sending of Measurement Report, for event 1b (Removal of an existing cell in Active Set)

timeToTrigger1c indicates the time in ms between event detection and sending of Measurement Report, for event 1c (A cell outside Active Set becomes better than a Cell in Active Set)

The change of the timeToTrigger values have been made in order to avoid ping-pong effect in cell additions and replacements, and possible call drops.

For example, if there is a call in “Cell A” and the signal of it’s neighbor “Cell B” becomes stronger for a moment and at the same time “Cell A” becomes weaker, “Cell B” would be added and “Cell A” would be removed from the active set. If “Cell A” becomes strong immediately after removal this could interfere the connection and can lead to a drop.


LZT 123 8297 R1C © 2006 Ericsson - 139 -

When timeToTrigger1a is increased, the signal of the neighbor cell has to be strong for a longer time before making the decision to add it to the active set. This will avoid adding cells that become strong only for a very short time. If we set timeToTrigger1b higher than timeToTrigger1a we delay the removal of a cell from the Active Set to reduce the probability that fading effect will force the removal of a cell that could become stronger soon after the removal. This should reduce the probability for the drops mentioned above to happen. At the same time timeToTrigger1c is set equal to timeToTrigger1a to replace weaker cells that are being delayed for removal.

Even with the increase of the timeToTrigger there is still the possibility that flashing neighbours (far away sites that cannot be added to the neighbour list and cannot be tilted) are being reported for addition by the UE.

Whenever the value for one of these cells is higher than the best cell in the active set by an amount equal or greater than ReleaseConnOffset, the connection would be released. The increase of the parameter allows for a greater tolerance on UL interference for a short time in the system before releasing the call. Both the change in timeToTrigger and ReleaseConnOffset reduce the probability for this kind of release to happen. Note a high value for ReleaseConnOffset will reduce the capacity in the RBS due to higher interference and affects the HSDPA performance.

ReportingInterval1a is the interval of event-triggered periodical reporting in case of “cell addition failure” or “cell replacement failure”. Indicates the interval in sec. of periodical reporting, triggered by event 1a

ReportingInterval1c is the interval of event-triggered periodical reporting in case of “cell addition failure” or “cell replacement failure”. Indicates the interval in sec. of periodical reporting, triggered by event 1c.

Both of the timers have been shortened to cope with the increase in the value for the relative timeToTrigger. Since the measurement Report is being delayed, it is preferred to send the periodic repetition of the same measurement Report earlier than with the default settings in the event there is no answer from the RNC. Having both a longer timeToTrigger and a long ReportingInterval could lead to excessive delays in the handover and possible drops.

Too short timeToTrigger values will cause mismatch between neighbor set in the UE and the neighbor set in the RNC.


- 140 - © Ericsson 2006 LZT 123 8297 R1C

Inconsistent neighbor set

When the UE is setup on a dedicated channel, during the RRC signaling connection establishment, the SRNC sends a MEASUREMENT CONTROL message, with "setup" indicator to the UE. This message is the first MEASUREMENT CONTROL message the UE receives for this particular connection and it contains the list of cells and the measurement criteria to be used. The list of cells and the measurement criteria for support of Soft/Softer handover are also broadcasted in the system information on the BCCH channel, in SIB11/SIB12. This allows the UE to start Intra frequency measurement on configured neighbors Intra frequency for the cell where the RRC connection was setup before receiving the MEASUREMENT CONTROL message from the SRNC.

In TEMS Investigation can be seen that the active set lists in the UTRAN and the UE are inconsistent. As a result, the UE might not connect to the best cell. Then the UE suffers interference from that cell and finally the connection drops. Alternatively, the UE tries to add a better cell into active set; but the UTRAN ignores it because it thinks the cell has been in the active set already.

Figure 4-14 The Measurement reports and ASU complete can vanish in case of a bad timeToTrigger setting

Measurement Control

UE RNC

Measurement Report

Active Set Update

Active Set Update Complete

Measurement Control

Measurement Report


LZT 123 8297 R1C © 2006 Ericsson - 141 -

Figure 4-15 Inconsistent Lists

The possible reason for this case can be that the uplink performance is poor. As a result, the sent active set update complete might not be received from the UTRAN; due to this the inconsistent active set problem could happen. The solution is to improve the coverage, e.g. tilting, reducing the pilot power so as to remove the uplink and downlink imbalance issue, etc. It is also recommended to check the timeToTrigger parameter settings

UE only has two active set cells,

SC9 and SC1

UTRAN requests the UE to do replacement

handover, i.e. UTRAN thinks the UE has 3 AS cells


- 142 - © Ericsson 2006 LZT 123 8297 R1C

Figure 4-16 Inconsistent Lists between UE and RNC

In the figure above the UE is requested to remove SC 148, in the Active Set Update (DL-DCCH) even if the UE only have SC35 and SC 116 in the Active Set. Therefore, the UE replies UTRAN with active set update failure.

In another case, the UE sends several measurement reports to propose SC148. However, the UTRAN does not reply the UE.

UE only has two active set cells, SC35 and SC116

UTRAN requests to remove SC148. The UE doesn’t have SC148. UE replies with active set update failure.


LZT 123 8297 R1C © 2006 Ericsson - 143 -

Figure 4-17 Removal of incorrect cell Cause: Inconsistent Lists

In another case, the UE sends a measurement report to propose to remove a cell, see Figure 4-17 and Figure 4-18. The UTRAN replies the UE with active set update but it requests the UE to remove the best serving cell in the active set.

UE only has one cell in active set

cells SC77

UTRAN requests the UE to remove SC85, which is much better than SC77, while the UE want to remove SC77


- 144 - © Ericsson 2006 LZT 123 8297 R1C

Figure 4-18 Removal of incorrect cell Cause: Inconsistent Lists

After the handover, the UE is connected to a cell with poor CPICH_Ec/No. Then the UE sends many measurement reports to propose to add the better cell back into active set. However, due to poor downlink performance (i.e. pilot channel failure Ec/No ~ -16dB), maybe the UE cannot receive the active set update message.

The area is also having many pilots in the area, which could lead to the problem described above. The first solution to this problem is to make sure the pilot pollution is reduced to the minimum in the network.

UTRAN requests the UE to remove SC85, which is much better

than SC77

UE requests to remove SC77


LZT 123 8297 R1C © 2006 Ericsson - 145 -

Other parameter checks

For IndividualOffset parameter verify if other setting than default could improve handover performance for worst performing cells. Keep in mind IndividualOffset is cell based and not cell relation-based parameter which means changes to IndividualOffset parameter can move handover border back or forth in relation to all neighbors and not one specific neighbor. This will limit the usage of this parameter.

Check the value of InitShoPowerParam parameter. Settings other than the default can be tested and verified. A lower setting than zero can reduce UL RRSI due to the fact the new radio link starts with lower initial power before it has synchronized. InitShoPowerParam is used in the initial downlink power setting during soft handover.

Other things that should be checked are the following

1- Check whether the pilot power of worst performing cells and their neighbors are set equally. More than 1-2 dB difference between pilot powers of neighbors might impact call drop.

2- Check the value of releaseConnOffset parameter. A low setting will give more call drop for cases where a reported detected cell is not in RNC neighbor cell list.

3- Investigate how accurately the DL and UL attenuation parameters are set.

4- Neighbor cell offset (serving, neighbor) is used to move the border between cells. qoffset1 and qoffset2 is the offset between the two cells that is read in the system information of the serving cell. In P4 there are now two separate measurements running to detect bad quality, one is using Ec/No, and another is using RSCP. Either of these might trigger, and when one of them does, then the following IF or GSM measurement is started using the same measurement quantity that triggered bad quality. In P3 the parameter qualMeasQuantity could be set by the operator in order to measure either on the Ec/No or RSCP


- 146 - © Ericsson 2006 LZT 123 8297 R1C

Soft Handover Overhead per RAB

In order to find to large handover areas in the system and to find out the average number of RL per user the following formula should be used:

habEstablispmSamplesRtablishpmSumRabEs

shRabEstabliRABpmSamplesshRabEstabliRABpmSum

dSHOoverhea allcells∑ ><

><

=

Figure 4-19 Example of different services and their overlapping areas

Theoretically the cell overlapping area of high bitrate services (e.g. PS128, PS384) should be reduced compared with low bitrate (Ps64 or speech). It depends on network dimensioning (site to site distance and load).

HSDPA MOBILITY

There is no Admission Control needed for doing HS-DSCH Cell Change; Admission Control is however needed when HS-DSCH RAB is established.

When the UE moves between cells which are HSDPA enabled (that is, when hsdpaCapability = HSDPA_CAPABLE), the HSDPA connection is maintained by means of the serving HS-DSCH cell change functionality or, shortly, HS cell change. HS-DSCH Cell Change can be seen as a handover to a dedicated place in a queue to a common channel (HS-DSCH) in a new cell. Note however that HS-DSCH Cell Change can not be performed over Iur.

UtranCell counters

RNC counters


LZT 123 8297 R1C © 2006 Ericsson - 147 -

HS-DSCH Cell Change evaluation performs the evaluation of a valid target cell within the current Active Set, if a change of the best cell or a removal of the Serving HS-DSCH has been triggered by the A-DCH Soft Handover evaluation. The Cell Change evaluation is triggered only if the parameter hsCellChangeAllowed is set to TRUE.

HS-DSCH does not use soft handover as the dedicated channels (DCH) do. There is a trade-off between optimizing the radio quality of HS-DSCH (that is, frequent enough cell changes) and minimizing the impact on throughput at cell change (that is, as few cell changes as possible).

HS-DSCH Handover event 1d

When the Ue is using HSDPA, the MEASUREMENT CONTROL orders an extra event that supports Serving HS-DSCH Cell Change (event 1 d HS) to be reported by the UE.

The reason for having a separate event 1d HS is to be able to get UE reports triggered by only Active Set cells and to be able to use different Hysteresis and time to trigger parameters to trigger HS-DSCH Cell Change. It is also possible to use a different quality criteria than used for the conventional event 1d. The default quality criteria used for the event 1d HS is the CPICH RSCP. The parameter hsQualityEstimate indicates whether it is CPICH Ec/No or CPICH RSCP that should be used for indicating "best cell" for HS-DSCH Cell Change.

The event 1d HS does not imply any Active Set Update since the change of the best cells triggered by the event 1d HS can be related only to a cell already included in the Active Set.

HS-DSCH - IRAT and IFHO

When the Ue is PS Interactive using HSDPA, the MEASUREMENT CONTROL includes only neighbor cells of type intra-frequency and no Compressed Mode is triggered, that means that Inter-Frequency and Inter-RAT Handover are not possible to be performed. When the UE leaves PS Interactive using HSDPA, a full neighbor list is used (as well as Compressed Mode).

HS-DSCH Handover

If the Serving HS-DSCH Cell Change has been disabled by parameter hsCellChangeAllowed (FALSE) the change of the best cell in the Active Set will not have any effect. On the other hand,


- 148 - © Ericsson 2006 LZT 123 8297 R1C

the removal of the Serving HS-DSCH cell will trigger an RRC connection release. The call will then be set up on an HSDPA RAB, if the new cell is HSDPA enabled, but it will take longer than if cell change was allowed, leading to a certain throughput degradation.

If the best cell is not an HSDPA capable cell and the current HS-DSCH serving cell needs to be removed from AS (that is, an HSDPA coverage border), the connection will be released and automatically re-established by the packet application on R99.

If the best cell is not an intra-RNC cell (that is, when the UE moves over Iur) and the current HS-DSCH serving cell needs to be removed from the AS, an RRC connection release with the cause "directed signaling connection re-establishment" is triggered. With this cause value, the call will be immediately setup either on HSDPA or on R99 in the best cell belonging to the new RNC, depending on if the best cell is HSDPA capable or not. In order to avoid releases and setups following a ping-pong pattern, the Iur borders should be carefully defined.

HS-DSCH cell change for a 384/HS connection can only take place if the target HS-DSCH cell has UL 384 enabled and 384/HS resources available. If not, the call will be kept until it is released, probably due to an event 1b or to loss of synchronization.

The Serving HS-DSCH Cell Change can introduce a delay in the A-DCH Soft and Soft Handover execution in case of a removal of the Serving HS-DSCH has been triggered. In that case the Active Set Update evaluation will trigger a Serving HS-DSCH Cell Change first and then trigger Active Set Update execution.


LZT 123 8297 R1C © 2006 Ericsson - 149 -

INTER-FREQUENCY HANDOVER

Inter-frequency handover allows an ongoing call to be transferred from one frequency to another in a case where a UE is moving out of coverage of the source frequency. The feature covers functions for both inter-frequency handover for UEs on dedicated channel and for inter-frequency cell re-selection on common channel and in Idle Mode.

f1f2

f2f2

f1

f1

Figure 4-20 WCDMA Handover (Inter Frequency Handover & Cell Re-selection)

The IRAT or IFHO functionality can be enabled per cell. When bad connection quality has been triggered, the type of HO to be attempted is configurable per cell. The parameter hoType can be set per cell to GsmPreferred, IfPreferred or to None, and a setting to None means that no IRAT or IFHO can be done from this cell, and compressed mode shall not be started. If for some reason the preferred HO type can not be initiated, then the other HO type might be attempted instead.

IRAT and IFHO are both triggered by coverage. The purpose with both functions is to save the connection by making a HO to either GSM or to another WCDMA frequency, when the coverage on the original WCDMA frequency deteriorates. Instead of dropping, the connection should preferably continue on another WCDMA frequency or in GSM.

In order to detect deteriorating coverage, the connection quality monitoring uses events 2d and 6a to trigger bad coverage in DL or UL. When either event is triggered, the UE will start new measurements for either IF or GSM cells, to try to detect a new candidate cell to make a HO to. This usually also involves starting compressed mode.


- 150 - © Ericsson 2006 LZT 123 8297 R1C

The time required for the UE to detect a new cell varies between approximately 2 to 8 seconds, measured from the detection of bad coverage to detection of the new HO candidate cell. This time depends on signal-levels, the UE measurement performance and the length of the neighbor cell lists. In order to make a reliable HO, instead of dropping the call, the deteriorating coverage must be detected early enough, and the neighbor cell lists should not be longer than necessary. It should be noted that the UE measurement performance might also vary between different manufacturers.

IFHO Neighbour list

The UE can measure on a maximum of 32 IF cells, and on a maximum of two other frequencies. When a second carrier f2 is introduced in clusters as co-located cells, the initial IF (f2 to f1) neighbour list for the f2 cell could be defined by copying the corresponding f1 neighbour list from the co-located f1 cell, and adding the co-located f1 cell.

However, if the coverage for the IF cell deteriorates quickly and it is important that the IFHO can be performed fast, then the IF neighbor lists should be as short as possible. The time it takes for a UE to find a candidate IF cell generally increases with longer neighbor cell lists, and keeping the list short should generally lead to less time in compressed mode and better retainability performance.

When a second carrier is deployed as a hotspot cell, two-way neighbor cell relationships should be defined only between the under-laying f1 cell and the over-laying f2 cell. One-way neighbor cell relationships are defined from the f2 cell to all the surrounding f1 cells. The main benefits with this setup are the elimination of IFHO from the surrounding f1 cell to the f2 cell, the decreased risk of CPM starts in the f1 layer, and the shorter neighbor lists. With one-way definitions, all surrounding f1 cells become blind to the f2 cell.

It should also be noted that the P-CPICH power settings should initially be set to the same values for the f2 cells as for the co-located f1 cells. The f2 to f2 neighbor lists for the second carrier cells could also initially be determined by using the f1 neighbor lists for the corresponding co-located cells


LZT 123 8297 R1C © 2006 Ericsson - 151 -

IFHO Parameter check

The first step is to locate the WCDMA cells which are coverage limited and decide if either GSM HO or IFHO should be enabled in these cells in order to reduce the dropped calls caused by the coverage limitation. For these cells the GSM and/or the IF neighbor cell lists should be defined, keeping the lists short if possible and without defining unnecessary neighbor relations.

The next step is to set parameters for the IRAT and IFHO functions. The event 2d threshold can be adjusted per cell, and can be used if an early detection of the coverage problem is necessary in some cells or locations in order to make a successful HO. For example, a cell which has locations where the coverage falls quickly for many users, leading to dropped calls, might need a higher threshold setting for the 2d event. The thresholds 2f, 2b (used frequency) and 3a are relative thresholds to the event 2d and will also be per cell level. The relative parameter values are set on RNC level.

The purpose with this procedure is to decrease the amount of coverage generated dropped calls, so that most of these calls instead can continue in GSM or on another WCDMA frequency, but without causing too many false triggers or too many users in compressed mode. Frequent starts and stop of compressed mode always come with a cost in terms of power and HW resources. The dropped calls should be monitored during these procedures, and the total number of drops per cell should be calculated before and after the GSM or IFHO functionality is enabled

IFHO Handover Speech

Drop due to IFHO failure for speech: Outgoing IFHO failure when UE failed to return to present active set.

ch12eqHoCsSpeeindInterFrpmAttNonBlech12evertCsSpereqHoFailRlindInterFpmFailNonB

×100

The following formula might give slightly lower result:

⎟⎟⎠

⎞⎜⎜⎝

⎛ ++×

ech12evertCsSpereqHoFailRlindInterFpmFailNonB2tCsSpeech1reqHoReverlindInterFpmFailNonB ech12reqHoCsSpelindInterFpmSuccNonB

ech12evertCsSpereqHoFailRlindInterFpmFailNonB100

Drop due to IFHO failure for CS except speech: Outgoing IFHO failure when UE failed to return to present active set.


- 152 - © Ericsson 2006 LZT 123 8297 R1C

ersationaleqHoCsConvindInterFrpmAttNonBllversationaevertCsConreqHoFailRlindInterFpmFailNonB

×100

Drop due to IFHO failure for PS less or equal to 64 kbps: Outgoing IFHO failure when UE failed to return to present active set.

s64ractiveLeseqHoPsInteindInterFrpmAttNonBlss64eractiveLeevertPsIntreqHoFailRlindInterFpmFailNonB

×100

Drop due to IFHO failure for PS greater than 64 kbps: Outgoing IFHO failure when UE failed to return to the present active set.

ater64ractiveGreeqHoPsInteindInterFrpmAttNonBleater64eractiveGrevertPsIntreqHoFailRlindInterFpmFailNonB

×100

Drop due to IFHO failure for PS streaming and others: Outgoing IFHO failure when UE failed to return to the present active set.

ingOthereqHoStreamindInterFrpmAttNonBlmingOtherevertStreareqHoFailRlindInterFpmFailNonB

×100

INTER-RAT HANDOVER

The significant difference between handover and Inter-RAT Cell Change or Cell Reselection is that for handover dedicated resources must first be allocated in the target cell and then the UE is ordered to go to the allocated resources. For Inter-RAT Cell Change or Cell Reselection the UE is ordered (Inter-RAT Cell Change), or it takes the initiative (Cell Reselection) to go to the target cell and after arrival to the target cell use common channels, to inform the system of the Inter-RAT Cell Change and request for dedicated resources, if needed.

The WCDMA RAN also supports handover to/from GSM for coverage reasons. In later releases, it will be possible to perform this Inter Radio Access Technology (Inter-RAT) handover for capacity or priority reasons, as illustrated in Figure 4-21.


LZT 123 8297 R1C © 2006 Ericsson - 153 -

GSM Network

Multi RAT terminal

UMTS GSM

Handover from GSM to UMTS because of high load or system priority

Handover from UMTS to GSM because of bad coverage

Figure 4-21 WCDMA Handover (Inter RAT Handover)

The IRAT handover and cell reselection functionality enables the system to move the connection from the UMTS to the GSM system and vice versa. The most common scenario with the introduction of UMTS systems would be when moving out of the UMTS coverage and then transfer the call to GSM system before/without dropping the connection since GSM initially will have a larger coverage footprint. IRAT functionality also enables the operator in a “basic” way to steer traffic between the GSM and the UMTS systems.

The default system behavior is that GSM HO is not supported for the higher interactive DL rates 384 and 128. These rates will normally be downswitched to 64 when the coverage deteriorates, and when the connection has been switched to 64 the GSM HO functionality will work normally. If an event 2d was triggered earlier, the GSM measurements will start as soon as the switch to 64 occurs.

The UE can measure on a maximum of 32 GSM cells. There are reasons to be restrictive when defining GSM neighbors, and it is recommended to not define GSM neighbors if it is not needed. The time it takes for a UE to find a candidate GSM cell generally increases with longer neighbor cell lists, and keeping the list short should generally lead to less time in compressed mode and better retainability performance. If the WCDMA coverage falls quickly, the probability of quickly finding a suitable GSM candidate cell will increase if there are fewer GSM cells to measure on.

In this section, the equations for Inter Radio Access Technology (GSM) Handover success rate per service are covered.


- 154 - © Ericsson 2006 LZT 123 8297 R1C

Therefore, it is of importance to set the IRAT parameters for the GSM and the UMTS systems so that the resulting functionality meets the intended strategy of the operator for its 2G/3G subscribers and services.

IRAT Handover Speech

The following metric measures hard handover success rate between UtranCell and target GSM cell for speech calls. The formula is considering the GsmRelation.

chIratHoSpeepmNoAttOutSpeechsOutIratHopmNoSucces

×100

IRAT Handover CS57

The following metric measures hard handover success rate between UtranCell and target GSM cell for CS streaming calls. The formula is considering the GsmRelation.

IratHoCs57pmNoAttOutCs57sOutIratHopmNoSucces

×100

IRAT Handover Multi-RAB

The following metric measures hard handover success rate between UtranCell and target GSM cell for Multi-RAB calls. The formula is considering the GsmRelation.

iIratHoMultpmNoAttOutMultisOutIratHopmNoSucces

×100

IRAT Handover Packet Data

The WCDMA to GSM cell change for PS interactive services normally experience quite long outage times before the session can be reestablished on the GSM side. There are no normal tuning activities that can be performed to shorten this time.

The outage time can be divided into 2 parts. The first radio-outage part depends largely on the UE and consists of the time it takes for the UE to reselect to the GSM cell and then perform LA and RA updates. This typically takes 8-10 seconds. The second part is the Application outage that depends on the application, the protocol and on the TCP-IP procedures, before the application is running normally again. For some applications, like FTP download, this time could in the worst case be around 10 seconds


LZT 123 8297 R1C © 2006 Ericsson - 155 -

The following metric measures cell change failure rate between UtranCell and target GSM cell for PS calls when the UE successfully returns to UtranCell. The formula is considering the GsmRelation.

tCcAttpmNoOutIraldChtCcReturnOpmNoOutIra

×100

MISSING NEIGHBOUR RELATIONS

The amount of dropped call due to missing neighbor is depended on the value of releaseConnOffset parameter. If this parameter is set high, the number of drop due to missing neighbor will be low but the trade of is that the interference level will be increased due to overshooting.

One of the reasons for dropped call that can be seen through statistics is drop due to missing neighbor relation. Normally a missing neighbor is reported to RNC as a detected cell. If the detected cells are not in RNC neighbor list for a concerned cell and the reported Ec/No value is greater than the serving cell plus the value of releaseConnOffset parameter, the call will be released (drop from end-user point of view) to reduce the interference level of this area.

Shows fraction of speech drop due to HO action when a valid or non-valid cell cannot be added to active set. This includes also drop due to missing neighbor.

( )SpeechRabReleasepmNoNormal SpeechRabReleasepmNoSystem SpeechSoHopmNoSysRel

+×100

Shows fraction of speech drop due to missing neighbor reason when a non-valid cell cannot be added to active set.

( )SpeechRabReleasepmNoNormal SpeechRabReleasepmNoSystem hbrSpeechNeigpmNoSysRel

+×100

In order to find missing neighbor relation the GPEH recording function could be used. The event that is interesting for this case and provides relevant information is “INTERNAL_SOHO_DS_MISSING_NEIGHBOUR”. By activation of this event and collection of enough data (2-3 days), a number of potential missing cells will be identified. This list needs to be review to exclude overshooting cells that needs to erased.


- 156 - © Ericsson 2006 LZT 123 8297 R1C

For cells with full neighbor list (32 entries) it is necessary to monitor the current handover statistics in order to know the usage of existing neighbor list. Note that Ericsson does not recommend to put in more than 20 entries in the neighbor list.

New relations found through missing relation analysis can replace neighbor relations with low usage. In order to do the ranking of cell usage it is possible to use “INTERNAL_SOFT_HANDOVER_EXECUTION” event in GPEH for 2-3 days with efficient load to get enough data.

It is also possible to use cell relation based counters such as pmRlAddSuccessBestCellSpeech and pmRlAddAttemptsBestCellSpeech from performance statistic counters. Cell relation based counters should be activated for concerned cells and their neighbors to provide information regarding how often an existing neighbor relation is used.

OTHER REASONS

Drop due to other reasons, could be anything else such as UE problem, active set update failure (timer expiration), network malfunctioning, congestion on transport side during handover, RNC queues (Buffer_1A_1C or Buffer_1B) are full, etc.. This portion of dropped calls is calculated based on subtraction of known reasons for drop from the total dropped call.

Dropped calls due to other reasons than uplink out of sync and missing neighbor can be calculated through using counters. In reality, there is no known reason behind this part of drop when looking at counters.

Shows fraction of speech drop due to other reasons than HO action, UL out of sync and congestion.


SpeechCongpmNoOfTermynchlSpeechULSRepmNoSysolSpeechSoHRepmNoSyshleaseSpeecReRabpmNoSystem+

−−−×100


LZT 123 8297 R1C © 2006 Ericsson - 157 -

Transport Network

The dropped calls due to transport network is not a radio problem, however it is important to find where that faults are so it could be solved.

Shows percentage of rejected incoming/outgoing Aal2 connection establishment requests on transport network.

( )( )XYmoteonnspmSuccOutCmotennspmSuccInCo

XY+++

+×

ReRe100

Where

X = pmUnSuccOutConnsLocal + pmUnSuccOutConnsRemote

Y = pmUnSuccInConnsLocal + pmUnSuccInConnsRemote

WNCS (WCDMA NEIGHBOURING CELL SUPPORT) WNCS is a tool included in the RNO product family.

The purpose of WNCS is to evaluate the neighboring cell relations and to provide an easy and efficient way to keep the neighbor relations in the WCDMA Radio Network optimized. This means that support is provided to find missing neighboring cells that should to be defined as neighbors, and to find currently defined neighbor relations that can be removed.

WNCS is mainly used for:

Trouble shooting: Missing neighboring cell relations can be detected.

Supervision: The neighboring cell relations can be evaluated continuously.

Planning areas with new cells: WNCS can be used to evaluate new cell relations when new cells are added to the network.

Only neighbor relations between WCDMA cells using the same frequency (ARFCN), that is the neighbor relations used for soft/softer handovers, can be optimized with WNCS.


- 158 - © Ericsson 2006 LZT 123 8297 R1C

It is recommended to include maximum 300 cells belonging to 5 RNCs in one WNCS recording.

The User Equipment (UE) continuously monitors the radio environment. Not only defined neighbor cells are measured, but also cells that are undefined neighbors can be detected with the background scanning process. The UE is configured to evaluate and send measurement reports to the system only when certain events occur, such as when the measurement result for a cell fulfills certain criteria.

This concept is called event-triggered reporting. Events are collected by the General Performance Event Handling (GPEH) function in the RNC and sent on to Performance Management Support (PMS) in the OSS, where they are included in a Result Output Period (ROP) file. One file is created for each RNC and Result Output Period.

WNCS schedules recordings of GPEH events via PMS, collects the files, and processes the events related to the measurements of surrounding WCDMA cells. It also collects and presents counters that measure the extent of defined WCDMA neighbor relations usage. The results are presented in various reports.


LZT 123 8297 R1C © 2006 Ericsson - 159 -


LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS

UE has sent active set update complete message to the UTRAN. However, the UTRAN does not reply the UE with measurement control to update the new monitored set cells list.

Figure 4-22 Loss of ASU complete. Possible Cause: DL/UL Imbalance

The uplink RF performance is very bad. UTRAN cannot

receive the measurement


- 160 - © Ericsson 2006 LZT 123 8297 R1C

The UE sends many measurement reports to request adding a cell; however, the UTRAN does not reply the measurement report by sending active set update message.

Figure 4-23 Loss of measurement reports.

If the uplink RF performance is very bad, e.g., CPICH_RSCP is low and UE_Tx_PWR is high. Thus, it can be assumed the UTRAN cannot receive the active set update complete message. If the serving CPICH_Ec/No is still good, the problem then is the UL / DL coverage imbalance. The problem can be solved by reducing the pilot power and by adding new site.

If the serving CPICH_Ec/No is bad as well, it is poor coverage issue. The unique solution is to add new site.

If the serving CPICH_Ec/No is good as well as the CPICH_Ec it can be the timeToTrigger parameter settings. The unique solution is to change the timers to a different value.

The uplink RF performance is very bad. UTRAN cannot

receive the measurement


LZT 123 8297 R1C © 2006 Ericsson - 161 -

INTER-RNC HANDOVER FAILURE

In TEMS Investigation, inter-RNC handovers can be monitored as well as all types of handovers. However, in this case below, the UE sends many measurement reports to request adding a cell, which is in the other RNC, into active set. The UTRAN does not reply the measurement report.

After connection drop, the UE can be connected to that cell. If the UE then sends measurement reports to request adding the previous cell, which is located in the first RNC. The UTRAN does not reply the UE.

Figure 4-24 RC Handover failure. Possible Cause: Network configuration


- 162 - © Ericsson 2006 LZT 123 8297 R1C

The RF conditions for the new cell, SC75 is good however the AS SC56 is getting worse. Due to the many pilots in the area they might affect the inter-RNC handover. In this case the handover failed in both directions due to the fact that the UTRAN did not reply to the UE requests. Regarding the inter-RNC handover, the Iur link between the RNC can also be wrongly configured or that the neighbors are not correctly defined in the different RNC.

UE RELATED PROBLEM

The UE sends a MR to remove the best SC from the AS. After this SC is removed, the other ones in the AS become very bad in terms of Ec/No and the UE has no time to add it back to the AS.

The UE sends a MR to remove SC204,which is the best server SC.

The UE sends a MR to remove SC204,which is the best server SC.

Figure 4-25 Inconsistent Lists. Possible Cause: DL/UL Imbalance


LZT 123 8297 R1C © 2006 Ericsson - 163 -

In the AS, there are two SC’s, RF conditions become very good for one of them and bad for the other, and UE Tx power is low. It is assumed that the good radio link is out of synchronization because the DL BLER is increasing while the RF conditions become better for one SC. Finally the call drops because high DL BLER.

Figure 4-26 TEMS Investigation DL BLER Increases and the call is dropped.

DL BLER increases while SC183 is gets better and

SC308 is gets worse

DL BLER increases while SC183 is gets better and

SC308 is gets worse


- 164 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 165 -

5 Service Integrity

Objectives


• Understand how to analyze and interpret the collected data in order to improve the BLER and throughput

• Analyze RAN performance and propose adjustments related to integrity


- 166 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 167 -

INTEGRITY ........................................................................................169

INTEGRITY WORKFLOW..................................................................169

WORST CELLS .................................................................................171 FORMULAS ..................................................................................................171

WCDMA POWER CONTROL ............................................................172 CRC – CYCLIC-REDUNDANCY CHECK .....................................................173 DL INNER LOOP ..........................................................................................174 UL INNER LOOP ..........................................................................................175 UL OUTER LOOP .........................................................................................176 POWER CONTROL ON HSDPA CHANNELS..............................................179

BLER PARAMETERS........................................................................180

PACKET THROUGHPUT...................................................................181

HSDPA ...............................................................................................194 HW AND SW PREPARATIONS....................................................................194 OPTIMIZING THE HSDPA............................................................................195

TEMS INVESTIGATION FINDINGS...................................................200 HIGH DL BLER - NO RAB SETUP ...............................................................200 HIGH DL BLER – DROPPED CALL .............................................................201


- 168 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 169 -

INTEGRITY This module is done after the retainability module. Integrity is defined as the ability of user to retain its requested service at a certain quality once connected for the desired duration.

The performance is measured by the BLER (BLock Error Rate) and by throughput. The purpose of Integrity check-up is to track down excessive BLER problem and analyze them in a WCDMA network.

INTEGRITY WORKFLOW Below the Figure 3-2 is showing the Integrity workflow.

At performance monitoring the worst cells regarding integrity is sorted out.

At performance analysis the worst cells are analyzed to find the BLER problems and then the throughput of the cells are checked


Through the Verification phase, the collected statistics before anything is implemented is compared to the statistics collected after the implementation is done. This is to ensure that there has been an improvement.

Figure 5-1 A The Integrity workflow



Recommendation &

Implementation


pmFaultyTransportBlocksBcUl pmTransportBlocksBcUl pmNoOfSwDownNgCong PmNoOfSwDownNgAdm PmDl Traffic volume counters

BLER, power, SIR parameters Throughput

Test the settings Check statistics If not OK, roll back

BLER counters and Down Switching counters


- 170 - © Ericsson 2006 LZT 123 8297 R1C

At the end of the workflow, when the verification of the implemented changes is done.

Below is the proposed scenario how Integrity service can be performed.

1. Through performance statistics data (RNC counters) identify RAB’s that are not performing in line with targets (blerQualityTargetUl). That means - uplink BLER derived from counters is higher than UL BLER Target value set by parameter. Usually this should not be the case.

2. Review radio parameter settings (points below). Perform a consistency check of the parameter settings and verify settings against Ericsson default/recommended values.

NOTE: WCDMA technology in Power Control has mechanisms to keep BLER lower then blerQualityTargetUl/Dl (UeRc parameter). If this is not the case it can be that parameters related to RAB’s and Power Control have wrong values. Most of the mature networks have these values checked several times in the Consistency check procedures.

- Check RAB parameters on the RNC level (blerQualityTargetUl and blerQualityTargetDl) (also in Retainability module)

- Check the values of the Power Mapping parameters, Maximum Downlink Transmitted Code Power.

- Check UL Outer Power loop parameters (SIRMax, ul SIR Step). (also in Retainability module)

3. Check if it makes sense to investigate different blerQualityTarget settings (for example, what is happening changing target from 1 to 2% for voice)

The performance can be verified after modifying BLER target by

- Integrity counters, on RNC level after combining per RAB

- Counters related to congestion, admission control and number of simultaneous users

- RBS counters related to carrier, code power and RSSI

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 171 -

Generally, there will be 2 types of finding from these analyses. Either the findings are related to Cell/RBS/RNC parameter settings, or they are related to hardware configuration such as antenna tilt or antenna height etc.

WORST CELLS Observability of Integrity is very limited, only UL BLER per RAB on RNC level can be monitored. The system is designed to fight against BLER deviations from the set BLER targets. The ability to influence Integrity is somehow very small.

There are two counters on cell level before combining pmFaultyTransportBlocksBcUl and pmTransportBlocksBcUl. These counters are measured also during the time when cell is not the best in the active set. These counters do also contain BLER information for all RAB’s.

The method for finding worst performing cells is based on top to down analysis. Initially worst 10-15 performing cells can be identified based on the Uplink Block Error rate before combining.

ltBlocksBcUpmTransporcksBcULansportBlopmFaultyTr100×

FORMULAS

Below is described formula that is based on counters after macro diversity combining in uplink.

The Formula below shows Block Error rate after uplink combining at RNC level. That means blocks in RNC coming from different legs in SHO are compared, each radio connection.

l[UeRc]tBlocksAcUpmTransporRc]cksAcUl[UeansportBlopmFaultyTr100×

UeRc stands for different RAB’s (UeRc=2, Speech; UeRc=3, Video Call; UeRc=4, Packet Common Channel; UeRc=5, PS 64/64; UeRc=6, PS64/128, UeRc=7, PS 64/384; UeRc=10 multirab Speech+PS 0 or PS 64/64).


- 172 - © Ericsson 2006 LZT 123 8297 R1C

WCDMA POWER CONTROL Power Control is essential for the smooth operation of a WCDMA system, because all users share the same radio frequency band through the use of different codes.

There are three types of power control in WCDMA as illustrated in Figure 3-8.

RNC

Uplink SIR-Target

Uplink SIR error

SIR-Targetmodified

Uplinkouter loop

BLER-Measured

BLER:Block Error Rate

SIR: S ignal to Interference Ratio

TPC: Transmit Power ControlUplink SIR target

DownlinkSIR target

Inner loop

Downlink TPC UplinkTPC

Starting power

Open loop

SIR-Targetmodified

Downlinkouter loop

BLER-Measured

Figure 5-2 WCDMA Power Control

Open Loop Power Control is performed in the uplink and downlink to calculate a minimum starting power for setting up a connection. In doing so the interference and power required is minimized.

Inner loop Power Control minimizes the power and interference of ongoing connections by maintaining a minimum Signal to Interference Ratio (SIR).

The Outer Loop Power Control algorithm is used to maintain the required Block Error Rate (BLER) for a service by modifying the SIR target of Inner Loop Power Control.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 173 -

CRC – CYCLIC-REDUNDANCY CHECK

In the WCDMA Transmitter, the voice channel is passed through a vocoder, which produces a digital representation of the input analogue signal. After error protection this is fed into a data multiplexer where it is multiplexed with synchronization bits and control/signaling data and user data channels. This combined signal is passed to the transmit gating device. Finally, filtering and RF modulation is performed and the signal is passed to an antenna system.

The Error detection and error protection of the data channels are performed using Cyclic Redundancy Check (CRC) coding, Forward Error Correction (FEC) and interleaving.

In all radio systems the air interface will add noise to the signal, which will produce a distortion in the received signal. This noise will result in bit errors, that are what left the transmitter as logic 1 could be interpreted as a logic 0 if the level of noise lowers the amplitude below the threshold for logic 0. The same could be the case for a transmitted logic 0 being interpreted as logic 1.

Cyclic Redundancy Check (CRC) is used to detect if there are any uncorrected errors left after error correction.

Figure 5-3 CRC Generator

Blocks of data are passed through a CRC generator Figure 5-3, which will perform a mathematical division on the data producing a remainder or checksum. This is added to the block of data and transmitted.

Checksum 12 bits 110010110011

Original Data 244 bits

CRC Generator

Original Data 1001011010..

CRC Generator

Re-Generated Checksum 110010110001

Transmitter

Receiver

If Checksums do not match, there is an error

Received Data 1001010010..

Received Checksum 110010110011

RF Transmission Path


- 174 - © Ericsson 2006 LZT 123 8297 R1C

The same division is performed on the data block in the receiver. If a different checksum is produced the receiver will know that there is an error in the block of data (alternatively there is an error in the received checksum). This knowledge is used to calculate Block Error Ratio (BLER) used in the outer loop power control.

The longer the checksum, the greater is the accuracy of the process. In the example the checksum is twelve bits long. Twelve bits of binary information represents 4096 (2

12) different combinations. It

could be imagined that various combinations of errors on the data and the checksum would produce the same checksum. The longer the checksum the less likely it is for this to happen.

DL INNER LOOP

During a period of soft handover with downlink Inner Loop Power Control, starting the radio link at the correct power level coordinates the power of the radio links. Each RBS in the active set listen to the same sequence of TPC commands from the UE. Received TPC commands, however, may be affected by different errors, due to the different radio propagation conditions experienced by each of the soft handover links. Consequently, the transmitted power at different RBSs will start to drift, eventually leading to uncoordinated links. Power Balancing prevents this power drift problem by using a modified type of power control during soft handover.

The UE maintains the QoS by sending Transmit Power Control (TPC) commands in every slot (i.e., 1500 times per second), requesting a power adjustment.

The RNC calculates a reference power based on the transmitted code power measured in each radio link, and periodically sends it to the RBSs. The RLs belonging to an out-of-sync RLS are excluded from the calculation of reference power. If all RLSs are out of sync, the last available reference power is used. The RLs belonging to RBSs that do not support transmitted code power measurements are also excluded from the calculation of reference power. Each RBS involved in soft handover makes synchronized adjustments of the downlink power of the radio links according to the received reference powers. These adjustments are superimposed on the power changes due to downlink Inner Loop Power Control, and performed regardless of RLS synchronization status.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 175 -

UL INNER LOOP

As soon as the RBS starts transmitting the downlink DPCCH, it begins to regulate the uplink power of the radio link by sending TPC commands to the UE in each slot. The UE responds by slowly increasing power until uplink synchronization is reached. Immediately, the RBS starts estimating the SIR on the DPCCH. The TPC commands are derived according to the following scheme:

If estimated SIR >= target SIR, the RBS sends a down command.

If estimated SIR < target SIR, the RBS sends an up command.

Figure 5-4 Uplink Inner Loop Power Control

The UE responds to the command by changing the DPCCH power by 1 dB in the direction indicated by the command. The ratio between DPCCH and DPDCH power is determined by gain factors.

In case of soft handover, if TPC commands from all RBSs in the active set are up commands, UE increases the DPCCH power by 1 dB. Otherwise, if at least one TPC command is a down command, it decreases the DPCCH power by 1 dB.


- 176 - © Ericsson 2006 LZT 123 8297 R1C

UL OUTER LOOP

There are two alternative algorithms for uplink Outer Loop Power Control implemented. The parameter ulOuterLoopRegulator determines whether to use the Constant Step Regulator algorithm (ulOuterLoopRegulator=CONSTANT STEP) or the Jump Regulator algorithm (ulOuterLoopRegulator=JUMP). The interaction between uplink Inner Loop Power Control and uplink Outer Loop Power Control is shown in Figure 5-5.

Figure 5-5 Uplink Outer Loop Power Control

The two configurable parameters sirMax and sirMin set the limits of the uplink SIR target, expressed in dB.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 177 -

The start point of SIR target regulation is determined by the Initial Uplink SIR Target (ulInitSirTargetLow or ulInitSirTargetHigh) depending on the Spreading Factor of DPDCH. The Initial Uplink SIR Target is a configurable parameter defined according to the minimum Spreading Factor (SF) of the uplink Dedicated Physical Data Channel (DPDCH): ulInitSirTargetSrb for stand-alone SRB, ulInitSirTargetLow for RABs having minimum DPDCH SF equal to or higher than 32 and ulInitSirTargetHigh for RABs having minimum DPDCH SF equal to 16 or 8. ulInitSirTargetExtraHigh for RABs having minimum DPDCH SF equal to or lower than 4, i.e. dedicated (SRB) to dedicated (384/HS-DSCH) RAB establishment. Note ulInitSirTargetExtraHigh is not used for uplink initial power setting but used for uplink outer loop power control

To avoid windup effects on the uplink SIR target, the anti-windup mechanism prevents changes of the uplink SIR target in one direction if the uplink Inner Loop Power Control cannot make the uplink SIR reach the target in the same direction. E.g., if the uplink SIR is lower than the target by 5 dB as the UE transmits at maximum power, no further increases of the uplink SIR target are allowed until the Inner Loop Power Control is back on track.

Constant Step regulator

Whenever the Cyclic Redundancy Check (CRC) indicates that the reception of a transport block is erroneous, the uplink SIR target is increased by configurable increment ulSirStep, expressed in dB. Whenever NBR_OF_CRC_OK consecutive transport blocks are correctly received, the uplink SIR target is decreased by an equal step. The number of consecutive correct transport blocks needed to trigger a decrease of the uplink SIR target depends on the BLER target.

The SIR target value in the Constant Step Regulator algorithm is controlled as shown


- 178 - © Ericsson 2006 LZT 123 8297 R1C

Figure 5-6 SIR Target Behaviour According to the Constant Step Regulator algorithm

Jump regulator

The Jump Regulator increases the uplink SIR target by a configurable increment ulSirStep, expressed in dB, whenever a transport block is erroneously received. When a block is correctly received, the uplink SIR target is decreased by a fraction of ulSirStep. This fraction, denoted UP_DOWN_STEP_RATIO, depends on the BLER target.

If several transport blocks are received in one Transmission Time Interval (TTI), the change in the uplink SIR target will be based on the accumulated change individually caused by each of the transport blocks.

To reduce the variations of the uplink SIR target, the change of uplink SIR target is always scaled by the number of transport blocks received in the corresponding TTI, as described by the following general equation:

( ) ⎥⎦

⎤⎢⎣

⎡+

∗−+=

ZY

RATIOSTEPDOWNUPZXulSirStepSIRSIR ettnewett ___arg:arg

Where: ulSirStep is the configurable parameter that defines the size of SIR target increment. Z is the total number of received transport blocks. X is the number of transport blocks that have a CRC=OK. Y is the number of transport blocks that have a CRC=NG.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 179 -

SIR target behaviour according to the Jump Regulator algorithm is shown in the figure below.

Figure 5-7 SIR Target Behaviour According to the Jump Regulator algorithm

POWER CONTROL ON HSDPA CHANNELS

The principles and functionality of the power control for the HSDPA associated dedicated channels are the same as for the DPCH power control in previous releases. However, there is a new uplink dedicated control channel, HS-DPCCH, which is used for feedback information to the hybrid ARQ processes and for channel quality information

The power of the HS-DPCCH is given as an offset relative to the DPCCH . The offset has different values depending on if the UE is in soft handover or not.

Updates of the parameters for CQI and ACK/NACK transmissions can be done by Physical channel reconfiguration. The update can be triggered in two different ways:

• Triggered by RNC when the number of Radio Link Sets are changed

• Triggered by a request from RBS

In a first establishment, the radio bearer setup procedure, the parameters related to CQI are signaled in "Measurement Feedback info" which is a part of the "downlink HS-PDCCH information" message and the parameters related to ACK/NACK are included in the Uplink DPCH power control info fields. CQI, ACK, NACK are the power offset factors related to power control. A closed-loop-like update of the CQI/ACK/NACK Repetition Factors can further improve the reception quality on the HS-DPCCH.


- 180 - © Ericsson 2006 LZT 123 8297 R1C

The parameters deltaAck1, deltaAck2, deltaNack1, deltaNack2, deltaCqi1, deltaCqi2, initialCqiRepetitionFactor, initialAcknackRepetitionFactor, and cqiFeedbackCycle are all configurable and set per cell. The parameter setting in use is decided by the HS-DSCH serving cell

The RBS can initiate updates of the CQI Repetition Factor, CQI Feedback Cycle and ACK/NACK Repetition Factors using the Radio Link Parameter update procedure.

The parameter updates are initiated by the CQI reception performance. If the CQI report is regarded as non-reliable this is logged as a CQI error event in the RBS. Note that if the CQI Repetition Factor is set to a value higher than one (1) only the soft-combined result of the CQI report is counted.

BLER PARAMETERS blerQualityTargetUl - This parameter decides the quality target of the different RABs in uplink.

blerQualityTargetDl - This parameter decides the quality target of the different RABs in downlink.

The blerQualityTargetUl/Dl is calculated according to:

( )rgetquality ta BLER10Log10 UlyTargetDl/blerQualit =

for example when BLER quality target is 1% (0.01)

( ) 200,0110Log10 UlyTargetDl/blerQualit −==

The purpose of configurable BLER targets is to enable the operator to trade quality of the connections versus resource usage.

Note: These parameters can be set per TrCh for every radio connection. Recommended values for these parameters can be found below.

Default values for parameters blerQualityTarget UL/DL set on TrCH .

RAB Type TrCH Default Value SRB SRB -20 ( 1% BLER) Speech 12.2 Speech

SRB -20 (1% BLER) -20 (1% BLER)

Conversational CS data 64 CS64 SRB

-25 (0.3% BLER) -20 (1% BLER)

CS Streaming 57.6 CS57.6 -20 (1% BLER)

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 181 -

SRB -20 (1% BLER) PS Interactive 64/64 PS64

SRB -20 (1% BLER) -20 (1% BLER)

PS Interactive 64/128 PS128 SRB

-20 (1% BLER) -20 (1% BLER)

PS Interactive 64/384 PS384 SRB

-20 (1% BLER) -20 (1% BLER)

Speech+ PS Interactive 64/64 Speech PS64 SRB

-20 (1% BLER) -20 (1% BLER) -20 (1% BLER)

Speech+ PS Interactive 0/0 Speech PS64 SRB

-20 (1% BLER) -20 (1% BLER) -20 (1% BLER)

PS Streaming 16/64 +PS Int 8/8

PS Streaming PS8/8 SRB

-13 (5% BLER) -13 (5% BLER) -20 (1% BLER)

Conversational CS data 64 + PS Int 8/8

CS64 PS8/8 SRB

-25 (0,3% BLER) -20 (1% BLER) -20 (1% BLER)

PS Interactive 64/HS Int 64 (UL) SRB (UL) SRB (DL)

-20 (1% BLER) -20 (1% BLER)

-30 (0,1% BLER) PS Interactive 384/HS Int 384 (UL)

SRB (UL) SRB (DL)

-20 (1% BLER) -20 (1% BLER)

-30 (0,1% BLER)

PACKET THROUGHPUT Throughput is defined as the perceived user data rate from the application layer. This means that the throughput will never reach the peak rate, since the TCP and IP overhead, and retransmissions, have to be taken into account. The throughput can be expressed per session, per bearer or per cell.

It is important when dimensioning to know if these overheads have been taken into account in the requirement.

Session throughput and THold are illustrated in Figure 5-8 below.


- 182 - © Ericsson 2006 LZT 123 8297 R1C

Figure 5-8 Packet Call showing Session throughput and THold

Throughput is associated with the speed and time the data is transferred in the system on the radio interface. However a closer look for the accessibility and the channel switching statistics should be done when examining the throughput statistics for the packet data sessions.

Distribution chart of PS Application Downlink Throughput Range

7%

37%56%

App throughput < 64 kps 64 kps <= App throughput < 128 kbps

128 kps <= App throughput < 384 kbps

Figure 5-9 PS Application Downlink throughput from TEMS Investigation

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 183 -

In TEMS Investigation the Best Server throughput is measured and reported in a table that shows the application throughput and RLC/transport channel (low-level) throughput per cell. Please note that the low-level throughput is measured differently for different handsets.

The Application (end-to-end) throughput is also measured and reported in different tables and charts.

PS Binned Application Throughput Statistics Min (kbps)

Average (kbps)

Max (kbps)

Average Application DL 1,0 65,7 367,0 Average Application UL 1,0 7,0 39,0 Median Application DL Throughput for spreading factor = 32 1,0 38,6 122,0 Median Application DL Throughput for spreading factor = 16 1,0 49,7 169,0 Median Application DL Throughput for spreading factor = 8 4,0 92,5 367,0

Table 9 PS Binned Application-level Throughput Statistics

Channel Switching

Congestion control is used to resolve overload in both the uplink and the downlink. It uses Power and RSSI (Received Signal Strength Indicator) measurements. In case of overload, congestion control reduces bit rates of delay tolerant existing connections or as a second option, removes existing connections. When the Cell load rises due to the increased power requirement of for e.g. the UE that is moving away from the RBS. When this load reaches a defined limit the RBS must reduce it by switching non-guaranteed users to lower rate common channels.

Channel Switching applies only to packet traffic on the interactive RAB, which has little or no quality of service attributes that apply. It belongs to the Interactive and Background Quality of Service classes, which have no guaranteed bit rates and no packet delay requirements. When sufficient resources are available, the interactive RAB receives high bit rates but when the system is heavily loaded and not many resources are available, the bit rates offered may be low. In a heavily loaded situation, it may not be given any bandwidth at all, since there are no guarantees on resource allocation for the RAB.

Channel Switching switches only between transport channels. The logical channels are not affected. When large amounts of data are being sent or received, the DCH transport channel with various rates is available on both the uplink and the downlink. In addition, the HS-DSCH is available on the downlink and E-DCH is available on the uplink, both depending on UE and cell capability.


- 184 - © Ericsson 2006 LZT 123 8297 R1C

For small amounts of data, the common transport channels RACH and FACH are used. In this case, for downlink, a maximum of 32 kbps is shared between all users in a cell.

For no data activity, the interactive RAB is switched to URA state, where no transport channels are allocated and thus no data transmission is possible.

Channel switching function works both on a Single RAB and on a Multi RAB combination.

The Channel Switching function optimizes the resource usage by dynamically allocating different transport channels to the Interactive RAB of a UE. It consists of two parts: evaluation and execution. The evaluation part is responsible for monitoring the resource and coverage needs of a UE through measurement reports received from the UE, the RBS, and the RNC. A request to switch up or down in rates is made to the execution part when a need is detected. The execution part is responsible for (1) allocating the needed resources according to UE and cell capability and (2) executing the Radio Bearer Reconfiguration procedure for making the switch

The Channel Switching evaluation is based on two criteria: user activity and coverage condition. User activity is measured in terms of either channel throughput or RLC buffer load and coverage in terms of downlink code power.

The Channel Switching Algorithms can be triggered either by the UE or the RNC, depending on the behavior of the uplink and downlink, respectively. All of the Channel Switching evaluation algorithms have event triggered measurements, meaning that measurement reports are sent only when necessary. This means that the actual measurements are processed before reporting. The Channel Switching Algorithms use RLC buffer load, throughput, and transmitted code power as input to the algorithms.

Not all Channel Switching algorithms are active in every state. An algorithm corresponding to a certain state is started once the state is entered successfully and stopped when a new state has been entered successfully.

The switching is initiated by either the UE or the WCDMA RAN and is triggered by the Channel Switching Common to Dedicated Evaluation Algorithm based on measurements made by the WCDMA RAN or the UE.

The Channel Switching algorithm group consists of the following sub-algorithms:

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 185 -

• Common to Dedicated Evaluation

• Dedicated to Common Evaluation

• Common to URA Evaluation (in P5)

• URA to Idle Evaluation (in P5)

• Coverage Triggered Downswitch Evaluation

• CELL_DCH to CELL_DCH Upswitch Evaluation

• Throughput based CELL_DCH to CELL_DCH Downswitch Evaluation (in P5)

• Multi RAB Downswitch Evaluation

• Multi RAB Upswitch Evaluation

There are two states in connected mode: Dedicated state (Cell_DCH) and common state (Cell_FACH). These are associated with the transport channel on which the user data is sent. Channel Switching is activated in connected mode and handles switches between the different states or to idle mode. The switches between dedicated and common states are handled by WCDMA RAN without the involvement of the Core Network. The possible state transitions are shown in the figure below.

Figure 5-10. WCDMA Channel Switching


- 186 - © Ericsson 2006 LZT 123 8297 R1C

An UE on a common channel can be switched down to idle mode if it shows no activity during a certain time interval. In this way, resources are made free and common transport channel (FACH/RACH) signaling over the Iur interface is avoided. It also decreases the power consumption of the UE, since the UE does not have to monitor the FACH for long periods of time. This switching is initiated by the WCDMA RAN and is triggered by the Channel Switching Common to Idle Evaluation Algorithm based on measurements made by the WCDMA RAN. The timer is used to release UEs that has been inactive too long.

The Dedicated Channel (DCH) is well suited for high bit rate traffic, since it is reserved for one user and provides closed loop power control. High user bit rates create a lot of interference and power control is essential to keep the interference on an acceptable level.

It is also important to keep the common transport channels free from everything but control information and small portions of user data, in order to keep system function execution times sufficiently low. The use of a common transport channel would negatively affect the throughput of other users.

Common to Dedicated UpSwitch

RLC Buffer load: The buffer load is defined as the minimum of the Radio Link Control (RLC) transmission window and the sum of bytes in the SDU buffers and retransmission buffers of some of the RLC instances (each interactive RAB connection consists of five RLC instances). When the RLC buffer load in the uplink exceeds the threshold value set by the parameter ulRlcBufUpswitch, a measurement report is sent from the UE. An upswitch request is issued upon reception of the measurement report. A request is also issued when the RLC buffer load (in the RNC) in the downlink exceeds the threshold value set by the parameter dlRlcBufUpswitch. Channel Switching execution thereafter performs the upswitch when permission is given from Admission Control. Only one radio link is set up, since it is the responsibility of Soft and Softer Handover to add radio links after switching is complete

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 187 -

When setting dlRlcBufUpswitch it is important to consider how much of the TCP signalling should be done on common and how much signalling should be done on DCH. For example, when a UE is used for web browsing, uplink traffic is started by a short DNS message. If ulRlcBufUpswitch is set to a value smaller than the size of the DNS look-up message, an upswitch to DCH will be issued by the very first signaling from the UE which decreases the response time. On the other hand, a low setting of this parameter could make signaling from other applications trigger an upswitch when the UE is used as a modem for a laptop computer.

Dedicated to Common DownSwitch

Throughput: Uplink throughput is defined as the number of bits received to the RLC layer from the MAC layer. Downlink throughput is defined as the number of bits transmitted from the RLC layer to the MAC layer. The RLC instances to be considered for the buffer load and throughput measure depends on the UE state and the algorithm using the measurement. When the throughput on both the uplink and downlink is below the threshold value set by the parameter downswitchThreshold, the timer downswitchTimer starts (when on DCH/DCH) or the timer hsdschInactivityTimer starts (when on DCH/HS or EUL/HS). If the throughput increases above a second threshold set by the parameter downswitchTimerThreshold before the timer expires, the timer is stopped and no switch is issued. See Figure 5-11

Figure 5-11. The dedicated to common channel switching evaluation

If the downswitchTimer parameter is set to 0, the Dedicated to Common Evaluation algorithm is turned off, meaning that no down switches from dedicated to common will occur, irrespective of how long throughput has been below the threshold.


- 188 - © Ericsson 2006 LZT 123 8297 R1C

Optimization of the down switch from dedicated to common channels is a direct trade-off between resource utilization and user throughput. The goal is to achieve a parameter setting that correctly estimates when transmission for a user has ended in order to release assigned resources as fast as possible. The behavior of this algorithm is determined by the setting of the downswitchThreshold and downswitchTimer parameters.

The downswitchThreshold parameter determine how the radio access network should behave in the end of a TCP transmission. In general, when, e.g., a FTP download is over, throughput rapidly decreases to 0 kbps and then does not increase again until a new TCP transmission is started. Therefore, the default setting of this parameter is 0 kbps.

However, the setting of this parameter is strongly dependent on the characteristics of the TCP traffic. If, for example, a UE is used as a modem connected to a laptop it can very well be the case that applications on the laptop creates a low rate background traffic. The combined TCP traffic caused by e.g. a FTP download and the background traffic could make it necessary to set a higher value of downswitchThreshold . This is to avoid that a TCP transmission - that after transmitting with a throughput close to 384 kbps during the FTP download goes down to the e.g. 4 kbps created by the background traffic - holds the resources associated to the 384 rate unnecessarily long.

The downswitchTimer defines the time a user will stay on DCH with low throughput before being switched down to FACH. If this timer is set long, the probability that a user is switched down to FACH during short periods of inactivity decreases. This improves the user throughput, but also increases resource utilization and thereby decreases system capacity. It is therefore not recommended that this timer is used for generally improving user throughput. There are however traffic cases that can be improved by a slightly increased timer setting. For example, FTP transmissions can be split into several TCP transmissions. If the UE (or the laptop when the mobiles used as modem) uses this for FTP transmissions the user perception of the FTP transmission can be improved by a small increase of this timer. It should however be remembered that this then is done on the cost of system capacity.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 189 -

URA Evaluation (P5)

URA Evaluation: The Common to URA Evaluation releases UEs with no activity in order to free resources. It also decreases the power consumption of the UE, since the UE does not have to monitor the FACH for long periods of time. The algorithm is activated at the entry of the CELL_FACH state. Uplink and downlink activity is monitored and the algorithm requests a switch to URA_PCH state if no uplink or downlink activity has been detected (i.e. no data has been transmitted) during inactivityTimer seconds. The request is issued to the Channel Switching execution function, which handles the further processing of the transition to URA_PCH state.

The URA to Idle Evaluation releases UEs with no activity in order to free resources. The algorithm is activated at the entry of the URA_PCH state. The algorithm requests a switch to Idle mode if a UE has been allocated to URA_PCH state for InactivityTimerPch minutes. The request is issued to the Signaling Connection Handling function, which handles the further processing of the transition to Idle mode. Signaling Connection Handling issues an Iu release request to the Core Network, which in turn decides whether the connection should be released.

Coverage Triggered Downswitch

Transmitted Code Power: Transmitted code power is defined as the downlink power of the pilot bits of the DPCCH field.

The Coverage Triggered Down switch Evaluation algorithm monitors the code power utilization on the downlink. If the code power increases so that a switch to a lower rate dedicated channel on the downlink is required due to coverage reasons, a down switch request is sent to the Channel Switching Execution function. The goal is to minimize dropping due to bad link quality.

When downlink transmitted code power increases too close to its maximum, there is a risk that the link quality cannot be maintained. In this situation, a user should be switched down to a lower rate to decrease the needed downlink transmitted code power. The function will control that no user is using a rate in an area where there is risk for no coverage of that particular rate. It is therefore important that the mapping for maximum downlink power is tuned so that desired coverage is achieved


- 190 - © Ericsson 2006 LZT 123 8297 R1C

The algorithm monitors the downlink transmitted code power of all legs in the active set and the code power is then filtered by each RBS in the active set. A down switch request is issued when all handover legs use a power above the power alarm threshold. The power alarm threshold is defined by the parameter downswitchPwrMargin. If the transmitted downlink code power falls below the power alarm threshold while the timer coverageTimer runs, the request will be cancelled and no downswitch is executed.

The actual coverage of each rate is given by the maximum downlink power per radio link. This maximum downlink power per radio link is determined through a per-cell definable mapping based on the maximum rate of the radio link. By adjusting the mapping, coverage can be increased or decreased. When adjusting the mapping, some restrictions apply. For the coverage testing before upswitch, the downlink maximum transmitted code power is the maximum code power of the current rate. Consequently, the mapping should not be defined so that the resulting downlink maximum transmitted code power of a lower rate is higher that the downlink maximum transmitted code power of a higher rate. If this is done, the coverage tester functionality could fail and it could happen that the link quality cannot be maintained after an upswitch have been granted.

The average amount of transmitted code power is not only dependent on the used transmission rate and attenuation to the UE, but also on the blerQualityTarget parameters. By setting these parameters, average link quality can be traded for decreased resource consumption (i.e. transmitted code power). It is however then also important to notice that with decreased average link quality, user throughput will be decreased. From user throughput point of view it is therefore proposed that the blerQualityTarget is kept to a low vale (e.g. 1%).

This evaluation algorithm is started at the entry of the single RAB states CELL_DCH 64/384 and 64/128 and Multi RAB states speech + 64/384 , speech + 64/128 and 64/128 + 64/128

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 191 -

Channel Rate Switching

The Dedicated to Dedicated Upswitch Evaluation algorithm determines whether a switch to a higher rate channel should be made. The same algorithm applies both for Single RAB and for Multi RAB. The algorithm monitors the uplink and the downlink throughput separately. A channel switch request to a higher uplink rate Radio Bearer (uplink triggered) or to a higher downlink rate Radio Bearer (downlink triggered) is issued if all of the following conditions are fulfilled:

• The downlink throughput increases above the threshold specified by bandwidthMargin or the uplink throughput increases above the threshold specified by bandwidthMarginUl.

• For a trigger on the downlink, the transmitted code power consumption on the current rate is below the power upswitch threshold for all legs in the active set.

• The maximum bitrate capability for QoS profiling does not indicate that the current rate is the maximum bitrate for the user.

• After a throughput based downswitch, the downlink throughput has fallen below the threshold specified by dlThroughputAllowUpswitchThreshold or the uplink throughput has fallen below the threshold specified by ulThroughputAllowUpswitchThreshold.

The upswitch timer is specified by the parameter upswitchTimer for a downlink trigger and upswitchTimerUl for an uplink trigger.

The power upswitch threshold is defined from the power alarm threshold (described below) through the parameter upswitchPwrMargin and the estimated power increase. The estimated power increase is based on the relative rate difference between the current and a higher rate.

If the bandwidthMargin parameter is set to 0 or the bandwidthMarginUl is set to 0, the Dedicated to Dedicated Upswitch evaluation is turned off for downlink or uplink respectively.

If the dlThroughputAllowUpswitchThreshold parameter is set to 0 or the ulThroughputAllowUpswitchThreshold is set to 0, this condition is not used for downlink or uplink respectively.


- 192 - © Ericsson 2006 LZT 123 8297 R1C

The Dedicated to Dedicated Down switch Evaluation algorithm determines whether a switch to a lower rate channel should be made. The same algorithm applies both for Single RAB and for Multi RAB. The algorithm monitors the uplink and the downlink throughput separately. A channel switch request to the next lower uplink rate Radio Bearer (uplink triggered) or to the next lower downlink rate Radio Bearer (downlink triggered) is issued in the following situation:

• The downlink throughput decreases below the threshold specified by dlDownswitchBandwidthMargin or the uplink throughput decreases below the threshold specified by ulDownswitchBandwidthMargin .

If the above conditions holds for the duration of a down switch timer, a down switch request is executed by the Channel Switching function. The downswitch timer is specified by the parameter dlThroughputDownswitchTimer for a downlink trigger and ulThroughputDownswitchTimer for an uplink trigger.

If the dlDownswitchBandwidthMargin parameter is set to 0 or the ulDownswitchBandwidthMargin parameter is set to 0 the Dedicated to Dedicated Downswitch evaluation is turned off for downlink or uplink respectively.

TEMS Investigation and Statistics

In TEMS Investigation the events PS Channel Type Switch Complete, PS Channel Type Switch Failure, PS RAB Channel Rate Switch Complete and PS RAB Channel Rate Switch Failure indicates however the channel switching was successful or not. The Channel rate switch is done according to a spreading factor change.

pmNoOfSwDownNgCong

The counter shows number of times packet data connection downswitches from a dedicated channel to a common channel initiated by congestion control. If the down switch is not allowed to common, then the counter shows number of packet data system release due to congestion.

PmNoOfSwDownNgAdm

The counter shows number of times packet data connection downswitches from DCH 64/384 to DCH 64/128 and DCH 64/128 to DCH 64/64 initiated by admission control due to lack of downlink power or code limit.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 193 -

Figure 5-12. Channel Switching in TEMS Investigation

To compare the measured throughput (by TEMS Investigation) to the average throughput at the cell and at the RNC level could be done by looking at the traffic counters in at RBS and RNC level.

Average throughput per cell and RAB in the DL:

⎟⎟⎠

⎞⎜⎜⎝

⎛><

><><

=sec* ROP

shRabEstabliRABpmSamplesshRabEstabliRABpmSumRABcVolumepmDlTraffiThroughput

The RAB efficiency can also be checked

x per UeRc Bitrate NominalRABper Bitrate Actual

==EfficiencyRAB

The results gives the percentage of bitrate used compared with the maximum allowed by the RAB. In particular the speech RAB can be considered as the activity factor of the RAB. However this formula can not be used for HSDPA traffic.

The throughput for HSDPA is calculated differently from the other RAB due to the fact that there is a new protocol involved, the MAC-HS.

However if looking at transmitted bits the average HS cell throughput can be obtained:

SubFramesveRequiredpmNoInactisubFramespmNoActive500 * bits mittedpmSumTrans

+

The Average HS Cell throughput:

SubFramesveRequiredpmNoInactisubFramespmNoActive500 * BitspmSumAcked

+

DCH 64/384 DCH 64/128 DCH 64/64

FACH

Packet RAB establishment

RA

B S

ate

actual throughput


- 194 - © Ericsson 2006 LZT 123 8297 R1C

HSDPA The operators will implement WCDMA High-Speed Downlink Packet Access to gain more throughput per cell and higher bit rate per user. HSDPA is useful mainly in good radio channel conditions (e.g. high C/I, Low speed). On the other hand HSDPA will use whole remaining power all the time, which means lower C/I.

The HSDPA concept is based on the following features:

Shared channel transmission

Higher-order modulation

Short transmission time interval (TTI)

Fast link adaptation

Fast scheduling

Fast hybrid automatic-repeat-request (ARQ).

The new transport channel type, using multi-code transmission, is shared dynamically in time and code domain among multiple users. HS-DSCH is rate controlled, higher bit rates: 2 - 14.2 Mbps. Encoding rate, number of channelization codes and modulation type adapted, are based on available power. The adaptation is on 2 ms transmission time interval (TTI), e.g. 500 times/sec. This means the round trip delay is reduced on the air interface and the Fast Link Adaptation, Fast Radio Channel-dependent Scheduling and Fast hybrid ARQ with soft combining are possible.

HW AND SW PREPARATIONS

There are no need for new sites or for extra spectrum/carrier at the first deployment of HSDPA due to the fact that there are few UE available.

However the software for the RNC, RXI and RANOS has to be upgraded as well as the RBS. In the RBS there are also a need for HW upgrade to new Baseband boards (HS-TXB and HS-RAXB).

New and more efficient transmission solutions are necessary in order to serve the much higher bit rates. A wide range of ATM transmission interfaces e.g. E1, E3 & STM-1 as well as aggregation on Hub RBS and RXI level has to be installed

Transport network efficiency features provided through SW upgrade.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 195 -

OPTIMIZING THE HSDPA

Most of the existing WCDMA Networks are tuned/optimised to handle 60-70% of the downlink load during busy hours. Their current power parameter setting is for handling that load as well. Implementing HSDPA the network can most of the time be loaded 100%.

HSDPA feature tuning

A higher-order modulation, 16QAM in complement to QPSK is used for higher peak bit rates. 16QAM allows for twice the peak data rate compared to QPSK but it will be more sensitive to interference. With HSDPA higher system capacity is achieved, 2 - 3 times more. The 16QAM is an optional feature in the Node B that will be implemented in P5.

Fast Link Adaptation, data rate adapted to radio conditions on 2 ms time basis, adjusts transmission parameters to match instantaneous radio channel conditions, i.e. path loss, shadowing, interference variations and fast multi-path fading. There is no power control as such at the channels but the adaptation is based upon the CQI, Channel Quality Indicator.

In order to increase the throughput the more channelization codes can be dedicated to the HS traffic. However in P4 the codes will then not be available for R99 traffic.

With Fast Hybrid ARQ will re-transmissions of erroneous packets processed in the RBS be faster and soft combining of multiple transmission attempts to improve performance is used in the UE.

With Fast Radio Channel-dependent Scheduling is scheduling of users on 2 ms time basis. Scheduling implies which UE to transmit to at a given time instant based on radio channel quality and targeting fading peaks. In P4 there are only Round Robin and the Proportional Fair scheduling algorithm available.

Power parameters

HSDPA will take whatever power that is left in RBS after common channels and dedicated channels has taken their part

The average power utilization in the network will increase with HSDPA


- 196 - © Ericsson 2006 LZT 123 8297 R1C

Figure 5-13. HSDPA will take whatever power that is left in RBS

Power of the Common Channels, e.g. CPICH and SCH should be increased and verified. This because with 100% cell load the Pilot (CPICH) or other common channel should remain their quality in the cell. The power of non-HSDPA common channels is always set relatively to the primary common pilot channel power (primaryCpichPower). These settings are chosen so that they ensure sufficient quality where the CPICH can be detected. Current deployed networks show that the default settings are robust and give good performance, both in terms of accessibility and retainability. Tuning common channel settings should be done primarily through modifying primaryCpichPower, hence trading coverage for capacity

In areas with poor coverage it is possible to increase the success of the random access procedure by maximizing the number of transmitted preambles. This is achieved by setting the parameter powerOffsetP0 to 1 dB, preambleRetransMax to 32, and maxPreambleCycle to 32. These settings ensure that the UE transmits the maximum number of preambles before aborting the attempt, thus ensuring maximum detection probability in the RBS. Tests have shown that the coverage improvement with this setting is in the order of 1 - 3 dB.

Power

time

CCH power

HSDPA power

DCH power

Admission control threshold

Max cell power

Power

time

CCH power

HSDPA power

DCH power

Admission control threshold

Max cell power

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 197 -

Changing the powerOffsetP0 to 1 dB lowers the power ramp step size from 3 dB. This enables the UE to transmit more preambles at maximum UE power since the terminal aborts the ramping if the calculated UE power (P_PRACH) is 6 dB above the maxTxpowerUl. With 1 dB power steps the UE will send 6 preambles at maximum power compared to 2 preambles with a powerOffsetP0 at 3 dB. The potential drawback here is that the call set up time is slightly increased, since smaller power increase steps are taken. There is a trade off between call set up time, delay when in CELL_FACH state and coverage. Each preamble takes in the order of 5 ms. With an ideal initial power setting, the added delay in call set up will be 10 ms in the worst case.

With a smaller power step size, the number of preambles must be increased to ensure that it is possible to reach the maximum power. For this reason maxPreambleRetransMax is set to 32.

Max power of the DCH (other RABs) should be increased and verified. This because with 100% cell load the DCH channel should remain their quality in the cell border, where they are using their max power. The uplink (UL) dedicated control channel HS-DPCCH provides fast feedback of HARQ acknowledgements and the Channel Quality Indicator (CQI) on the UL. Reliable reception of the HS-DPCCH is essential for good HSDPA performance.

Power control of HS-DPCCH is given as an offset relative to DPCCH and there are different values depending on whether or not the UE is in soft handover. The reason for this is that the HS-DPCCH terminates in the RBS and is only received in the serving HS-DSCH cell. This implies that HS-DPCCH might have performance degradation when it is power controlled by multiple cells and the serving cell is not the best cell in the UL. Therefore higher power offset values are used when the UE is in soft handover and lower offsets otherwise. The drawback with the higher settings necessary for successful reception of HS-DPCCH is the higher resource cost (UL interference will increase). Therefore it is important to set these parameters correctly considering this trade-off.

The updates of the power offset parameters are triggered by the RNC when the numbers of Radio Link Sets are changed.

The power offset parameters are grouped into two namely deltaCqi1, deltaAck1, deltaNack1 and deltaCqi2, deltaAck2, deltaNack2. The first group is used when the number of Radio Link Sets (RLS) is equal to one (that is RLS=1) and the second when it is greater than one (that is RLS>1).


- 198 - © Ericsson 2006 LZT 123 8297 R1C

The power setting of HS-SCCH is fixed. The parameter hsScchMaxCodePwr determines the power level of HS-SCCH and is expressed as an offset relative to the PCPICH. The information element "HS-SCCH power offset" that can be carried over NBAP shall not be used.

With HS-DSCH there is a new Radio Bearer defined for the A-DCH corresponding to a 3.4 kbps SRB in the downlink and a 64 kbps bearer in the uplink.

Uplink initial power setting for the Interactive PS RAB 384/HS id cone with the parameter ulInitSirTargetExtraHigh.

Interference

After implementing HSDPA and having full load system the overall interference floor will increase and consequently the overall C/I will be lower. This because the network most probably as a best had been tuned to handle around 70% of the load but now the load can go up to 100%.

Increasing a non-power-control-channel, e.g. pilot, means more power into the neighboring cells and hence higher interference in them as well. This high interference will cause higher power consumption per user and therefore lower cell capacity. The only way then to have lower interference is to retune the network.

To have cells with as less coverage “islands” and as less overlapping (outside SHO areas) as possible. Then the power is located in areas where it is used and minimized the power in areas when it disturbs as interference. This means need of retuning.

High sites generate interference outside the planned coverage area

Tilting antenna is an efficient way of achieving confined cells

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 199 -

Depending on the operators design and tuning the whole network needs to be retuned to get better C/I everywhere. This because the network most probably as a best has been tuned to handle around 70% of the load but now the load can go up to 100%. This should not be mixed with above where it is based on a user/RAB (or common channels), when here covers the capacity in the cell.

Handover parameters

HSDPA will not use SHO but hard HO (no macro diversity). This means in the SHO areas (cell borders) the HSDPA, which is already sensitive to interference, will be more sensitive and therefore retuning may be needed to optimize the original SHO regions more.

After implementing HSDPA high data speed PS radio bearers e.g. PS384 may not need same coverage requirement as before and need to be retuned.

HS-DSCH is not power but rate controlled, higher bit rates: 2 - 14.2 Mbps. Encoding rate, number of channelization codes and modulation type adapted, are based on available power. To have a higher bit rates more power is needed.

System Load

The DL Load is here measured as the percentage of used DL Power compared to the available one (including Common and Dedicated Channels). Two Load Condition Scenarios can be defined:

Low Load represents the Off-Peak Hours. It is generally assumed that the transmitted cell carrier power mostly includes the DL Common Channel Power.

High Load represents the Peak Hours with high transmitted cell carrier power

By considering the additional interference generated by HSDPA Traffic from each cell, at both the Ec/Io and DL RSSI.

The traffic load is considered in terms of DL Cell Transmitted Carrier Power. DL Cell Transmitted Carrier Power is the total DL transmitted power by a cell and it includes both Common and Dedicated Channel Power. The data can be obtained from the RBS counter pmTransmittedCarrierPower.


- 200 - © Ericsson 2006 LZT 123 8297 R1C


HIGH DL BLER - NO RAB SETUP

In TEMS Investigation the High DL BLER problem can be found. The last downlink message which the UE gets its ”Call Proceeding”. After this, the connection drops.

Before the drop, the DL BLER rapidly increases. However, the CPICH_RSCP and CPICH_Ec/No are good.

There are no other interference cells over the problematic location.

Figure 5-14 Example of high DL BLER and no radio bearer setup

One possible cause could be that the UTRAN failed to prepare the radio bearer and the UE time expired and then terminated the connection.

5 Service Integrity

LZT 123 8297 R1C © 2006 Ericsson - 201 -

Another possible cause could be that the UE was faulty and caused high DL BLER. Then the UE did not receive the RB Setup message from the UTRAN. Finally, the UE terminated the call setup.

HIGH DL BLER – DROPPED CALL

In TEMS Investigation the High DL BLER problem can be found. The connection is dropped after UE sends Radio Bearer Setup Complete message.

Before the drop, the DL BLER rapidly increases. However, the CPICH_RSCP and CPICH_Ec/No are good. Typically, UE Tx power increase high but not all time.

There are no other interference cells over the problematic location, but in some cases there were many handovers during call setup.

Figure 5-15 There is no DL signalling after the Radio Bearer Setup Complete

There is no DL signaling after the Radio Bearer Setup Complete message

The UE TX power is high


- 202 - © Ericsson 2006 LZT 123 8297 R1C

One possible cause could be that the UTRAN failed to synchronize the radio bearer in UL.

Another possible cause could be that the UE failed to properly establish the radio bearer and caused high DL BLER

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 203 -

6 UETR and GPEH

Objectives


• Understand which tools that are available for optimizing a network

• Understand how to setup and retrieve UE Traffic Recording (UETR)

• Understand how to analyze the UETR files using the TEMS Investigation RAN analysis

• Understand how to setup General Performance Event Handling (GPEH) and analyze the GPEH files


- 204 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 205 -

UE TRAFFIC RECORDING (UETR) ..................................................207 UETR RECORDABLE MESSAGES AND MEASUREMENTS......................208 ADD A UETR SUBSCRIPTION PROFILE ....................................................210 RETRIVE THE UETR LOGFILES .................................................................214 ANALYZE THE UETR LOGFILES ................................................................214

GENERAL PERFORMANCE EVENT HANDLING (GPEH)...............219 INITIATION OF GPEH ..................................................................................220 GPEH FILES COLLECTION AND STORAGE..............................................222 GPEH FILE STRUCTURE ............................................................................223 GPEH FILE ANALYSIS USING RED............................................................227 GPEH FILE ANALYSIS USING TEMS .........................................................232


- 206 - © Ericsson 2006 LZT 123 8297 R1C

Intentionally Blank

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 207 -

UE TRAFFIC RECORDING (UETR) UETR is a performance recording function in WCDMA RAN. It allows the operator to record the important events and behaviour on a selected UE or UEs traveling through a network. Only one UE may be selected per UETR recording, but one RNC gives the possibility of running up to 16 UETR simultaneously. If the UE crosses a RNC border, the UETR needs to be activated for both. The UEs to be traced are identified by the operator using their respective IMSI numbers.

The operator can send out a test mobile (in particular after changes or extensions to the network) to record live traffic to investigate the performance of the network in a certain area. Event data in the RNC and measurement data from the RBS and UE, related to the air interface, are recorded.

This function allows monitoring of specific information sent to and from the UEs. For example, the operator can check the data used to make handover decisions and from it identify parameters that need to be adjusted to achieve improved performance.

The UETR administration is supported by OSS-RC, which provides capabilities for:

1. Starting a UETR recording for one RNC.

2. Viewing a UETR performance recording.

3. Modifying a UETR performance recording.

4. Activating and deactivating a UETR performance recording.

5. Listing all UETR performance recordings.

6. Starting UETR for multiple RNCs.

7. Viewing performance monitoring filters.

The procedures related to the RANOS operation for UETR will be described below.


- 208 - © Ericsson 2006 LZT 123 8297 R1C

The output file of UETR uses a proprietary Ericsson binary format with embedded protocol messages, internal events and measurements. The protocol messages are represented in the transfer syntax specified by the protocol standards as they appear on the RNC interfaces. The internal messages are specified by a proprietary ASN.1 definition and encoded in a BASIC-PER aligned variant.

Note the file size for the UETR are limited in the RNC the parameter to control this is uetrFileSize.

UETR RECORDABLE MESSAGES AND MEASUREMENTS

Recordable messages

The UETR function can be chosen to record one or more of the messages within one or more of the following protocol groups:

1. NBAP, between RNC and node B (Iub)

2. RANAP, between RNC and core network (Iu)

3. RNSAP, between RNCs (Iur)

4. RRC, between RNC and UE (Uu)

UETR measurements

The following measurements are reported through the RNC internal event:

1. Transport Channel BER, measured on DCH after radio link combination (ordered for all DCHs relating to the UE connections being recorded). Measurement period = 1xTTIs, reporting period = 5xTTIs. The measurement period is the frequency with which the measurement is received in band in the RNC from the RBS. The reporting period is the frequency with which sequences of values are reported to the RNC PM recording application internally in the RNC.

2. Transport Channel BLER: uplink DCH (ordered for all DCHs relating to the UE connections being recorded). Measurement period = 10s, reported period = 10s.

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 209 -

3. RLC Buffer information, number of discarded DCCH SDUs, number of discarded DTCH SDUs, number of retransmitted DCCH PDUs and number of retransmitted DTCH SDUs (ordered for each downlink logical channel -per DCCH, per DTCH- associated with the UE being recorded). Report Period 10 s. This measurement is not reported from the UE, but is recorded in the RNC per UE. This is reported as an RNC internal event in the ROP file.

The following two measurements are reported through NBAP Dedicated Measurement Report. For the user to receive any of these measurements in the recording ROP file, the measurements and the NBAP Dedicated Measurement Report message must be selected.

1. Uplink SIR per radio link set, measured on DPCCH after radio link combination in the RBS. All values recorded within a 960 ms period are averaged and reported every 960 ms (ordered for all RLs relating to the UE connections being recorded).

2. Transmitted Code Power, measured on the pilot bits of one channelization code for a DPCH. One average value is reported every 1000 ms (ordered for all DPCHs relating to the UE connections being recorded).

The following two measurements are reported through RRC Measurement Report. For the user to receive any of these measurements in the recording ROP file, the measurements and the RRC Measurement Report message must be selected.

1. Transport channel BLER: downlink DCH is reported periodically every eight s (ordered for all DCHs relating to the UE connections being recorded).

2. UE transmitted power, reported periodically every second.


- 210 - © Ericsson 2006 LZT 123 8297 R1C

ADD A UETR SUBSCRIPTION PROFILE

The following procedure is used to add a UETR subscription profile:

1. Log into OSS-RC

2. Run the RANOS Network Explorer

3. Access the Data collection – Subscription profiles window from the Data collection choice on the Performance menu of RANOS Explorer. The following window appears:

Figure 6-1. Data Collection – Subscription profiles

4. Click on the Profile in the main drop down menu; then click Add. A create subscription profile wizard appears. For example:

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 211 -

Figure 6-2. Selecting the UETR profile

5. Select User equipment traffic recording profile (UETR); then click Next. The window Enter subscription profile name and comment pops up as shown below:

Figure 6-3. Entering a profile name and comments

6. Enter a profile name and comment; then click Next. A window to select the RNC to be included, Step 3 of 6 pops up. For example:


- 212 - © Ericsson 2006 LZT 123 8297 R1C

Figure 6-4. Selecting the involved RNC

7. Select the involved RNCs and then click Next. Select events for the UETR recording, Step 4 of 6 windows appears. For example:

Figure 6-5. Selecting the protocols to be measured on

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 213 -

8. Select necessary events and then click Next. The “Enter IMSI number for the UETR recording”- window pops up:

Figure 6-6. Step Entering the IMSI number

In order to get the IMSI number for a subscriber in the network connect to the MSC and type the following command in the command handler.

Mgtrp:msisdn = <mobile number>

The mobile number should be the full number, including the country code MCC and the mobile network code MNC

9. Enter the IMSI number of the test UE and then click Next. The “Select profile schedule wizard dialog”-window appears.

10. Choose relative profile schedule and enter the duration, then click on the FINISH button. This is the last wizard step and the created profile is included in the Data collection – Subscription profile dialog box.


- 214 - © Ericsson 2006 LZT 123 8297 R1C

RETRIVE THE UETR LOGFILES

On collection, the PMS renames the UETR files according to the convention below:

A<Date>.<StartTime>-<EndTime>_<ShortNodeId>_< ShortScannerId>_<IMSI>_uetrfile.bin

The files are stored in the folder: ‘var/opt/ericsson/nms_umts_pms_seg/segment1/Subnetwork=RNC01/MeContext=RNC01’ for 1 day.

ANALYZE THE UETR LOGFILES

The UETR function traces the behavior of an individual phone by recording event data produced in the RNC, as well as measurement data from the RBS and from the phone itself. The phone-originated data is also a subset of what is found in the TEMS log file, although in the UETR file it is not tagged with any positioning information. The remainder of the UETR file data is referred to as "uplink data" within the TEMS Investigation framework. It should be noted that UETR files contain no idle mode data, only data from calls.

The files can be recorded for voice calls only, not when running a data service. At present, TEMS Investigation is not capable of reading uplink data from other manufacturers' equipment.

Uplink files can be replayed as-is in TEMS Investigation. They can however also be merged with the corresponding TEMS log files, producing output in the form of an augmented log file which can be replayed in the usual manner. The contents of the uplink file can thus be viewed concurrently with the downlink data recorded in the TEMS log file. A further advantage of merging the files is that geographic positioning can be obtained for the uplink data.

The uplink data is presented as a separate class of information elements.

Merging the files

The task of the merging algorithm is to time-align – synchronize – the information in the uplink files with that in the log files. A time offset can be expected between the clock that governs uplink file time-stamping (for UETR files, the RNC clock) and the clock in the PC on which the log files were recorded.

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 215 -

While an uplink file contains (usually) one complete call involving a specific phone (actually a specific IMSI, i.e. subscriber identity), a log file can comprise an arbitrary number of calls made by one or several phones. The typical situation, therefore, is that a log file corresponds to multiple uplink files, each covering a log file segment that concerns a single call.

Figure 6-7. One TEMS Log file corresponds to several Uplink files.

For each call in the log file, the merging algorithm extracts a number of key characteristics: start time, stop time, and information about handovers (time of occurrence and serving cells involved). Then, each uplink file is compared to each call in the log file with respect to these characteristics. The uplink files for which a reliable match has been found are finally incorporated into the log file, aligned as indicated by the calculated time offset. The output is a new log file (extension .log), augmented with the uplink information, which is represented as being reported by a fictitious phone "MS5".

The merging algorithm may sometimes fail for certain uplink files; when this happens, additional information can be provided to align the uplink files manually.

If the merging algorithm has enough to go on, that is, if all calls in the files can be readily distinguished from each other by means of the characteristics considered, the procedure is straightforward. However, if this is not the case for some uplink file, so that there is difficulty in finding an obvious best match for it, the procedure will fail for this file.

Problems will thus arise with sets of similar calls, especially if they are short and lack distinctive features (namely, handover events). Fragments of calls, whether in uplink files or log files, are also more likely to be problematic, because either the start time or stop time and thus the call duration is unknown.


- 216 - © Ericsson 2006 LZT 123 8297 R1C

Furthermore, the algorithm does not handle day transitions. Therefore, it cannot correctly process calls beginning before and ending after midnight, or deal with time offsets that are so large as to place part of the calls on a different day. In other respects, the size of the time offset does not affect the performance of the algorithm.

The following procedure is used to load the UETR files into TEMS Investigation Data Collection.

1. Open the Export Log file window

2. Under Input files, enter the log file names, or click "Browse file" and select your files. (If several log files is chosen, the merge will be done separately for each log file.)

3. Under Directory, specify a directory for the output.

Figure 6-8. Step 1 to 3 of 5

4. In the Format combo box, choose "Log file with uplink data". Click the Setup button. In the dialog that follows, it is setup how to perform the merge (Method tab) and what uplink files to include in it (Uplink files tab).

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 217 -

Figure 6-9. Step 4 of 5

Unless the exact time offset is known beforehand, the merging should begin by running the algorithm described in the previous sections. (If the offset is known, the alignment can be carried out manually).

Mobile to match in log file determines what log file data is considered when comparing it with the uplink files. If there are data from several phones in the log file, but uplink files for a single phone, it is appropriate to disregard the data from the other phones: this eliminates a source of uncertainty in the matching process and speeds it up.

Place bounds on uplink file offset can be used if the size of the offset is fairly known and with this lower and upper bounds can be entered. This, too, increases the reliability and speed of the algorithm.

5. Start the merge

The procedure will take some time. When it has completed, a message ("Export Result") stating success or failure for each uplink file will be received.

If all uplink files have been successfully matched, the merge is done. If the algorithm has failed for some files, the Export Result window should not be closed.


- 218 - © Ericsson 2006 LZT 123 8297 R1C

If no sufficiently reliable match is found for an uplink file, it is not included in the output log file. There are two possibilities: Either there is no match – the data in the uplink file simply does not exist in the log file –, or there is indeed a match to be found, but the algorithm has problems identifying it.

In the latter case, the algorithm needs more precise information about the offset. Often several calls in the log file are good matches and there is a problem figuring out which is the correct one. Now, the offsets calculated for the successfully aligned uplink files (which should be nearly identical) should be similar to that of the remaining files as well.

On the Method tab, check "Place bounds on uplink file offset" and enter upper and lower bounds based on the values observed in the Export Result window. The bounds should be tight enough to ensure that a call in the log file cannot be mistaken for an adjacent call

If the procedure still fails for some files, they probably do not correspond to anything in the log file. It might be the case, however, that some files are corrupt (for instance, they might be truncated). Even so, you might want of course want to use them. There may also be a day transition problem. As a last resort, therefore, the alignment can be assigned by brute force, simply assuming an offset.

On the Method tab, choose "Assume static offset time" and enter a value in the box. (The offsets obtained for the successfully aligned files should still be a good clue.). The remaining files will then be aligned unconditionally with the log file according to the chosen offset.

There are limits to the accuracy that can be achieved in time aligning the uplink files. The accuracy is affected by the following factors

• The time offset for an uplink file is computed as the average of the offsets for all characteristic events detected in the call (call start, call end, handovers, etc.). Therefore, the longer the call, the more reliable the offset, and vice versa

• Measurement reports in UETR files are not tagged with time-of-day information, but merely with a counter that is reset after each handover. This may have the effect that the UETR measurement reports are imperfectly synchronized with the measurement reports from the phone

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 219 -

• Older UETR file formats only contain timestamps with a resolution of 1 s, but in P4 the resolution is 1 ms. This places a general limit on alignment precision, since a lot of messages may be written to the log file within one second

Analyzing the files

The merged files can then be analyzed in TEMS Investigation

GENERAL PERFORMANCE EVENT HANDLING (GPEH) This chapter describes the General Performance Event Handling (GPEH) function and events for the Radio Network Controller (RNC) 3810 and RBS 3000.

The GPEH function handles the management and collection of predefined events in the WCDMA RAN. These events are either Node-Internal or Inter-Node as listed below:

• RNC-Internal Events

• RBS-Internal Events

• RRC Inter-Node Events

• NBAP Inter-Node Events

• RANAP Inter-Node Events

• RNSAP Inter-Node Events

The Node-internal events are events produced within the RNC or RBS, due to a specific occasion, for example in an algorithm. The Inter-node events are protocol messages sent or received from UE, RBS or RNC.

The term Performance Management Subsystem (PMS) is used to describe the how the OSS-RC handles the performance management of the WCDMA RAN. For GPEH, the PMS function can be divided into three areas:

• Initiation of GPEH

• GPEH files collection and storage

• GPEH files notification


- 220 - © Ericsson 2006 LZT 123 8297 R1C

INITIATION OF GPEH

The PMS system can be used to initiate the GPEH in the RNC and RBS. This collection is carried out by an entity known as a ‘Performance Monitoring (PMn)’, also sometimes called a "Scanner".

The RNC provides 24 scanners at node startup, whereas the RBS provides only one. These pre-defined scanners are all empty. The Operations Support System Radio and Core (OSS-RC) is used to specify the contents and activate the scanners. Recording starts at the beginning of the next 15-minute Result Output Period (ROP) after activation from OSS-RC. The recorded data from all active scanners is collected in a common data file per Main Processor (MP).

The cell filter specifies in which cells in the RNC events shall be recorded. If an event does not include any cell identifier, it will match the filter anyway and be reported.

To select GPEH file settings:

1. Launch OSS-RC for a selected RNS

2. Select WCDMA RAN measurements from the dropdown selection, see figure below.

Figure 6-10. WCDMA RAN measurements – OSS_RC workspace menu

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 221 -

3. Create a performance profile for each selected RNC. Select WCDMA RAN measurements from the dropdown selection, The following window appears:

Figure 6-11. Select the General performance profiles

Figure 6-12. Selecting the GPEH events


- 222 - © Ericsson 2006 LZT 123 8297 R1C

4. Selecting the GPEH events are similar to the UETR configuration; however there are two filter parameters in GPEH to be selected, Ue_Fraction and Cell. If an event is not related to a specific UE, the event will match the Ue_Fraction filter anyway and be reported. The cell filter specifies in which cells in the RNC events shall be recorded. If an event does not include any cell identifier, it will match the filter anyway and be reported.

5. Start the recording

For further information, see General Performance Event Handler CPI documentation, 23/1551-AXD 105 03/1.

GPEH FILES COLLECTION AND STORAGE

The events are collected in GPEH data files, also called GPEH ROP files. The events are written to file in the order they appear in the buffers and are not ordered chronologically. For each 15-minute ROP period, the following two types of file are generated:

Main File The main file contains administrative information about the GPEH recording and links to sub files.

Sub file A sub file contains recorded events for all active scanners.

One main file generated on the O&M MP and one sub file per Module MP concludes each ROP. Each file has a unique name.

Type Always set to "A" - single Network Element

and single recording/granularity period

start_date YYYYMMDD

start_time HHMM

end_time HHMM

Main file: <Type><Date>.<StartTime>-<EndTime>_gpehfile:2.lnk

Subfile: <Type><Date>.<StartTime>-<EndTime>_GPEH.lnk

Example:

Main File: A20060122.18:00-18:15_gpehfile:2.lnk

Subfile: A20060122.18:00-18:15_GPEH.lnk

Figure 6-13 GPEH File naming convention

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 223 -

In the RNC events are recorded in the GPEH files until the end of the ROP or until the file has reached its maximum allowed size. The GPEH Main files are stored the same directory as the statistics and recording files, until the maximum allowed space in this directory has been reached, at which point the oldest files will be deleted.

NOTE: If the OSS-RC cannot read GPEH file storage location attribute from the node it will assume the files are stored in the default location specified by the parameters listed below: • RbsGpehDefaultFileLocation

• RncDefaultFileLocation

The GPEH binary files are collected by PMS from the NEs using standard ftp/s-ftp services on TCP ports 20/22. Collection starts 5 minutes after each ROP end. This 5-minute delay allows the node to close the file with the data reported for the relevant ROP.

Once the main files are collected from the node they are renamed by PMS and stored in a separate subdirectory for each RNC and RBS. Sub-folders are sorted per Radio Network Subsystem (RNS) and each RNS subdirectory is further divided into subdirectories per RNC and RBS. Subfolders names match names of the Sub-networks, RNSs and nodes defined by the configuration management application in OSS-RC.

GPEH FILE STRUCTURE

The Main File contains the following records: • Header Administrative information about the file.

• Recording Scope of the recording.

• Protocol The name and version of the protocol from which messages can be recorded (RRC, NBAP, RANAP, RNSAP).

• Link A link from the main file to a GPEH sub file on another MP.

• Footer Administrative information about the time of normal termination of the ROP file.

• Error Contains the time and cause of an abnormal termination of a recording. The error record replaces the footer record if the file is terminated abnormally.


- 224 - © Ericsson 2006 LZT 123 8297 R1C

Along with a footer or error, the sub file contains the numerous ‘Body’ records, explained below: • Body The body contains event records. The event record

contains details about inter-node events and RNC-internal events. It is only the sub file that has a body record.

A detailed explanation of the events can be found in the ‘General Performance Event Handling RBS (61/1551-HRB 105 102/1 Uen) document in the ‘Operation and Maintenance/Performance Management’ directory in the RBS library (CXP 901 0811/2 R6A) and in the RNC library (CXP 901 2011, from R6A).

An example of GPEH RNC-Internal event id 386 is shown in Figure 6-14 below.

EVENT

Hour: 22 Minute: 45 Second: 00 Millisecond: 677

Event_ID: 386

Name: INTERNAL_RADIO_QUALITY_MEASUREMENTS_RNH

C_ID_1: 4241

RNC_ID_1: 41

EVENT_TRIGGER: 9

MEASURED_ENTITY: 4

MEASURED_VALUE: 18

Figure 6-14 GPEH RNC-Internal Event Example

The ‘EVENT TRIGGER’ number relates to one of 52 triggers listed below: Event Parameter Trigger No. EVENT_VALUE_BELOW_NEG_UL_SIR_GUARD 0 EVENT_VALUE_ABOVE_POS_UL_SIR_GUARD 1 EVENT_VALUE_BETWEEN_POS_NEG_UL_SIR_GUARD 2 EVENT_VALUE_DL_POWER_INCREASE 3 EVENT_VALUE_DL_POWER_DECREASE 4 EVENT_VALUE_COMMON_MEASUREMENT_REPORT 5 EVENT_VALUE_LOAD_INCREASE 6 EVENT_VALUE_LOAD_DECREASE 7 EVENT_VALUE_EVENT_TRIGGERED_REPORT 8 EVENT_VALUE_PERIODIC_REPORT 9 EVENT_VALUE_REQUEST_FOR_DL_CODES_FOR_NORMAL_MODE 10 EVENT_VALUE_RELEASE_OF_DL_CODES_IN_NORMAL_MODE 11 EVENT_VALUE_ALLOC_FAILED_EXCESS_RATE_REQUEST 12 EVENT_VALUE_ALLOC_FAILED_NO_SUITABLE_CODE_FREE 13

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 225 -

EVENT_VALUE_REQUEST_FOR_DL_CODES_NORM_TREE_COMP_MODE 14 EVENT_VALUE_REQUEST_FOR_DL_CODES_ALT_TREE_COMP_MODE 15 EVENT_VALUE_RELEASE_OF_DL_CODES_IN_COMP_MODE 16 EVENT_VALUE_EVENT_1A 17 EVENT_VALUE_EVENT_1B 18 EVENT_VALUE_EVENT_1C 19 EVENT_VALUE_EVENT_1D 20 EVENT_VALUE_EVENT_2D 21 EVENT_VALUE_EVENT_2F 22 EVENT_VALUE_ADD_CELL_PROPOSAL 23 EVENT_VALUE_REMOVE_CELL_PROPOSAL 24 EVENT_VALUE_REPLACE_CELL_PROPOSAL 25 EVENT_VALUE_UE_LEAVES_DCH_STATE 26 EVENT_VALUE_CELL_UPDATE_RECEIVED 27 EVENT_VALUE_CELL_UPDATE_CONFIRMED_SENT 28 EVENT_VALUE_RCS_CU_TIMER_EXPIRED 29 EVENT_VALUE_RL_SETUP_OR_ADDITION_RESPONSE_RECEIVED 30 EVENT_VALUE_RL_RESTORE_RECEIVED 31 EVENT_VALUE_RL_FAILURE_RECEIVED 32 EVENT_VALUE_RL_DELETION_RESPONSE_RECEIVED 33 EVENT_VALUE_RCS_WAIT_TIMER_EXPIRED 34 EVENT_VALUE_PROPOSED_HO_TO_GSM 35 EVENT_VALUE_PROPOSED_CC_TO_GSM 36 EVENT_VALUE_EVENT_3A 37 EVENT_VALUE_IU_RELEASE_COMMAND 38 EVENT_VALUE_RAB_ASSIGNMENT_REQUEST 39 EVENT_VALUE_REQ_FOR_NORMAL_UL_SCRAMBLING_CODE 40 EVENT_VALUE_REQ_FOR_REDUCED_UL_SCRAMBLING_CODE 41 EVENT_VALUE_OTHER_TRIGGER 42 EVENT_VALUE_EVENT_6A 43 EVENT_VALUE_EVENT_6B 44 EVENT_VALUE_START_IEF_MEASUREMENTS_PROP 45 EVENT_VALUE_STOP_IEF_MEASUREMENTS_PROP 46 EVENT_VALUE_START_GSM_MEASUREMENTS_PROP 47 EVENT_VALUE_STOP_GSM_MEASUREMENTS_PROP 48 EVENT_VALUE_EVENT_2B 49 EVENT_VALUE_PROPOSED_IFHO 50 EVENT_VALUE_COMPLETED_IFHO_ATTEMPT 51

The ‘MESURED_ENTITY’ number relates to one of the five entities listed below: Measured Entity No. EVENT_VALUE_UL_SIR_ERROR 0 EVENT_VALUE_DL_TX_CODE_POWER 1 EVENT_VALUE_UL_INTERFERENCE 2 EVENT_VALUE_DL_TX_CARRIER_POWER 3 EVENT_VALUE_NON_HS_POWER 4

The ‘MEASURED-VALUE’ is the estimated percentage Downlink Power in the cell.

The RRC, NBAP, RANAP and RNSAP inter-node events are sometimes called ‘protocol events’ since they contain the Layer 3 protocol messages as specified by 3rd Generation Partnership Project (3GPP). Each L3 protocol message is given an ‘Event_id.


- 226 - © Ericsson 2006 LZT 123 8297 R1C

An example of a RBS-Internal Event 257 (gpehRlsSupStartedEv) is illustrated in Figure 6-15 below.

EVENT

Hour: 20 Minute: 23 Second: 09 Millisecond: 467

Event_ID: 257

Name: gpehRlsSupStartedEv

Number of cells: 1

RNC cell id 1: 4153

RNC cell id 2: 0

RNC cell id 3: 0

RNC cell id 4: 0

Figure 6-15 GPEH RBS-Internal Event Example

In this example Radio Link Set supervision has started on Cell 4153.

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 227 -

GPEH FILE ANALYSIS USING RED

The Recording and Event Data (RED) subsystem also known as the ‘Recording Events Interface’ (REI) provides the following main functions:

1. RED listens for notifications from PMS.

2. Once notified RED will extract the ROP file and store it in either the CTR, UETR or GPEH subdirectory of the parent directory below: /var/opt/ericsson/nms_umts_red_reg/downloaded.

3. The user can use the WCDMA Recording File Viewer to convert these binary ROP files to ASCII text files or tab delimited files.

An example of these functions being performed for a UETR file collected from RNC01 is illustrated in Figure 6-16 below. g

PMS

RBS

/SubNetwork=RNC01

/var/opt/ericsson/nms_umts_pms_seg/segment1

/MeContext=RNC01

/var/opt/ericsson/nms_umts_red_reg/downloaded RED

UETR.bin

Notification from PMS

UETR.bin

WCDMA Recording File

ViewerUETR.txt

Figure 6-16 WCDMA Recording File Viewer


- 228 - © Ericsson 2006 LZT 123 8297 R1C

The Recording File Viewer window is launched from the ‘Performance’ menu in the OSS Network Explorer Graphical User Interface (GUI).

From the ‘Performance’ drop down menu, choose ‘WCDMA Recording file viewer…’ as illustrated in Figure 6-17 below.

Figure 6-17 Launching WCDMA Recording file viewer

The Recording File Viewer main window is divided into two panes with a menu bar along the top of the window as illustrated in Figure 6-18 below.

Search Criteria

Search Results

Menu Bar

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 229 -

Figure 6-18 Recording file viewer graphical user interface

The top pane is used to select the search criteria. The lower pane is used to display details of files relevant to the selection criteria specified. The information in some columns will vary depending on the type of recording that is being represented.

The main Recording File Viewer window asks the user to input a number of fields to specify what criteria to use when outputting the recording results.

The fields are:

• Type *: Select the Type of recording result file you wish to view: - CTR - UETR - GPEH You must at least select a Type in order to activate the search (This field is mandatory as indicated by the asterisk).

The period you wish the recording result file to be viewed is specified with:

• From: start date/time interval for recording files

• To: end date/time interval for recording files

Log entries can be filtered by date by selecting the earliest log entries with the ‘From’ option and the latest log entries with the ‘To’ option.

The ‘From’ and ‘To’ dates are expressed as year, month and day. To change these click on the box. This will display the Calendar Dialog GUI.

To change the year click on the arrows, to change the month click on the month drop down menu and select the month required. Finally to change the day click on the required day on the calendar. Once the required date has been selected click ‘Apply’.

Select the desired time by clicking on it or highlight it by holding down the left button on the mouse and type in the desired time.

• NE: Specify the NE (Network Element) from which the recording file is to be retrieved.

Depending on the Type of recording selected one of the following fields will be enabled:


- 230 - © Ericsson 2006 LZT 123 8297 R1C

• Performance monitoring ID (for CTR and UETR) or Node Type (for GPEH)

• Source: The Recording Source is also dependent on the recording type: - Cell/RDN for CTR - IMSI for UETR - Main Processor Number for GPEH

Click ‘Search’ to view a log of result files. If none of the above fields are filled in then Search will return all files relevant to the Type specified.

Figure 6-19 below shows all the fields of the Recording File Viewer Search criteria.

Specify Network Element

Specify ID for UETR and CTR

Specify Node Type for UETR

- Cell/RDN for CTR

- IMSI for UETR

- Main Processor Number for GPEH Figure 6-19 Recording File Viewer Search Criteria

The ‘File’ menu contains ‘Open…’, ‘Save’, ‘Open Merge’, ‘Save Merge’ and ‘Properties’ drop down options as illustrated in Figure 6-20 below.

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 231 -

Figure 6-20 File drop down menu options

Click ‘Open…’ to open the selected recording file in the predefined editor. This can also be achieved by clicking on the icon in the menu bar.

Click ‘Save’ to save (download) the selected recording file to predefined path. This can also be achieved by clicking on the icon in the menu bar.

Click ‘Open Merge’ to parse and convert into tab delimited format a group of recording files selected by the user. Merge these files together into a single file and download this to the editor set as default.

Click ‘Save Merge’ to parse and convert a group of recording files selected by the user into tab delimited format. Merge these files together into a single file and download this to the editor set as default and save to filename set as default.

Note: Recommended Editor for Merged Files is a spreadsheet editor.

Open recording file in predefined editor

Save (download) file to a predefined path

Parse, convert, and merge group of files

Parse, convert, merge, and save to default filename

View properties of a job

or


- 232 - © Ericsson 2006 LZT 123 8297 R1C

GPEH FILE ANALYSIS USING TEMS

TEMS Visualization quickly displays a large volume of data about calls made on an Ericsson WCDMA network. The enhanced capabilities in TEMS Visualization will identify quality problems and congestion by switching between WCDMA and GSMA modes. The effects of recent network changes and to get a better understanding of radio network behaviour. The problem spots, root causes will be identified and the trouble shooting can start.

Following is a list of things that can be done with TEMS Visualization:

• Mode switch between WCDMA and GSM

• Load multiple Recording Output Periods (ROP) files sets into one database

• View and compare RF measurements, messages and events for calls including the flow of handovers for WCDMA networks

• See the WCDMA network infrastructure of cells on a map, including serving cells, neighbors, and the flow of a call among cells

• See the events, radio environment and graphical position of serving cells

• Identify abnormal events such as drops, blocks and handover failures

• Identify issues faced by subscribers by analyzing the data

The operations are supported from system version OSS-RC2.2 and the UMTS Radio Access Network P3 by TEMS Visualization.

.

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 233 -

Setting up TEMS Visualization for analysis

The workflow for the setup and the analysis can be visualized in the figure below.

Figure 6-21 Workflow for analysis of the GPEH log files

1. During this first phase the different data files should be imported through the import wizard in order to create a database

The cell files are showing cell infrastructure of the tested area and should be in the format of .cel or .xml.

TEMS Visualization uses the GPEH log files that are created with a performance recording in the OSS and the log files should have a .bin or a .bin.gz filename extension. The folders where the GPEH files are stored will be asked for.

The user can choose to filter some of the calls and/or call messages by the WCDMA Call filter.


- 234 - © Ericsson 2006 LZT 123 8297 R1C

2. If the user has already created a database, the first step is skipped by just loading the database.

3. The maps are imported. They can be MapInfo tables (.tab), MapInfo workspace (.mws) or MapInfo geoset (.gst)

Figure 6-22 TEMS Visualization User interface with all files loaded

The TEMS Visualization analysis

Once a log file has been processed and the data is in a database, all calls can be selected in order to be analyzed. The calls can be searched through criteria or calls analyzed for a specific cell.

Figure 6-21 shows the workflow and as shown, there are three major paths to follow. Normally all the pilot pollution should be analyzed first, secondly the missing neighbors and last the call analysis part.

6 UETR and GPEH

LZT 123 8297 R1C © 2006 Ericsson - 235 -

In the call analysis part, the user can either display the data or use the Analysis tools in TEMS Visualization.

By displaying the data, call messages with the details, RF measurements, the phone data, cell data, all will be visualized on the map geographically.

By using the Analysis Tools, the multiple data types can be viewed as well as comparing different multiple calls data. The user can step through calls and apply different filters to the data.

The analysis is not further discussed in this course.

Objectives


• Understand how to analyze and interpret the collected data in order to improve the BLER and throughput

• Analyze RAN performance and propose adjustments related to integrity

7 Abbreviations

LZT 123 8297 R1C © 2006 Ericsson - 239 -

AAL2 ATM Adaptation Layer type 2 ACK Acknowledgement AICH Acquisition Indicator Channel ALCAP Access Link Control Application Part AM Acknowledged Mode AMR Adaptive MultiRate speech codec AP Access Preamble ARQ Automatic Repeat Request AS Access Stratum AS Active Set ASC Access Service Class ASC Antenna System Controller ASE Air Interface Speech Equivalents ATM Asynchronous Transfer Mode BCCH Broadcast Control Channel BCH Broadcast Control Channel BER Bit Error Rate BH Busy Hour BLER Block Error Rate CM Connection Management CM Configuration Management CN Core Network CPCH Common Packet Channel CPICH Common Pilot Channel CR Change Request CRC Cyclic Redundancy Check CRNC Controlling RNC CS Circuit Switched CTCH Common Traffic Channel CTR Cell Traffic Recording DCA Dynamic Channel Allocation DCCH Dedicated Control Channel DCFE Dedicated Control Functional Entity DCH Dedicated Channel DDM Discrete distributed measurements DL Downlink DPCCH Dedicated Physical Control Channel DPCH Dedicated Physical Channel DRAC Dynamic Resource Allocation Control DRNC Drift RNC DRNS Drift RNS DRX Discontinuous Reception DSCH Downlink Shared Channel DTCH Dedicated Traffic Channel


- 240 - © Ericsson 2006 LZT 123 8297 R1C

DTX Discontinuous Transmission FACH Forward Access Channel FN Frame Number FP Frame Protocol ID Identifier GP General Processor GPEH General Performance Event Handling GSM Global System for Mobile Communication GUI Graphical User Interface HO Handover HW Hard Ware IE Information element IFHO Intra Frequency HandOver IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity IP Internet Protocol IRAT Inter Radio Access Technology KPI Key Performance Indicators KSI Key Set Identifier L1 Layer 1 L2 Layer 2 L3 Layer 3 LA Location Area MAC Medium Access Control MAC The Message Authentication Code included in AUTN,

computed using f1 MCC Mobile Country Code MM Mobility Management MNC Mobile Network Code MO Mobile Originating Call MO Managed Object MP Main Processor MR Measurement Report MS Mobile Station MSC Mobile services Switching Centre MT Mobile Terminal MTC Mobile Terminated Call NAS Non Access Stratum NBAP Node B Application Protocol NE Network Element OSS-RC Operation Support System – Radio Core PCCH Paging Control Channel P-CCPCH Primary Common Control Physical Channel PCH Paging Channel PDF Probability Density Function PDSCH Physical Downlink Shared Channel

7 Abbreviations

LZT 123 8297 R1C © 2006 Ericsson - 241 -

PDU Protocol Data Unit PICH Paging Indicator Channel PLMN Public Land Mobile Network PNFE Paging and Notification Control Functional Entity PPP PRACH Physical Random Access Channel PS Packet Switched PSCH Physical Synchronisation Channel PSTN Public Switched Telephone Network P-TMSI Packet Temporary Mobile Subscriber Identity QoS Quality of Service RA Routing Area RAB Radio Access Bearer RACH Random Access Channel RAI Routing Area Identity RAN Radio Access Network RANAG Radio Access Network Aggregator RANAP Radio Access Network Application Part RB Radio Bearer RBS Radio Base Station RFE Routing Functional Entity RL Radio Link RLC Radio Link Control RLS Radio Link Set RNC Radio Network Controller RND Radio Netwrok Design RNS Radio Network Subsystem RNSAP Radio Network Subsystem Application Part RNTI Radio Network Temporary Identifier ROP Recording Output Periods RRC Radio Resource Control RSCP Received Signal Code Power RSSI Received Signal Strength Indicator SCCP Signalling Connection Control Part S-CCPCH Secondary Common Control Physical Channel SCH Synchronization Channel SDM Statistical Data Mart SDU Service Data Unit SF Spreading Factor SGSN Serving GPRS Support Node SHCCH Shared Control Channel SIB System Information Block SIR Signal to Interference Ratio SMS Short Message Service SRNC Serving RNC SRNS Serving RNS


- 242 - © Ericsson 2006 LZT 123 8297 R1C

TCP TEMS CellPlanner TEMS Test Moile System TF Transport Format TFC Transport Format Combination TFCI Transport Format Combination Indicator TFCS Transport Format Combination Set TFS Transport Format Set TME Transfer Mode Entity TM Transparent Mode TMD Transparent Mode Data TMSI Temporary Mobile Subscriber Identity TPC Transmit Power Control Tr Transparent TrCH Transport Channel TTI Transmission Time Interval Tx Transmission UARFCN UMTS Absolute Radio Frequency Channel Number UE User Equipment UEA UMTS Encryption Algorithm UETR User Equipment Traffic Recording UIA UMTS Integrity Algorithm UL Uplink UM Unacknowledged Mode UMD Unacknowledged Mode Data UMTS Universal Mobile Telecommunication System UNACK Unacknowledgement URA UTRAN Registration Area UTRA UMTS Terrestrial Radio Access UTRAN UMTS Terrestrial Radio Access Network VLR Visitor Location Register WCDMA Wideband Code Division Multiple Access

0Appendix A: Cell Parameter and Configurations

LZT 123 8297 R1C © 2006 Ericsson - 243 -

Appendix A: Cell Parameter and Configurations


LZT 123 8297 R1C © Ericsson 2006 - 245 -

HW configuration

Cell name

Geographical height

Antenna Height

antenna gain

Antenna azimuth Antenna tilt

Feeder length

Feeder type ASC Transmission RNC

cell1 10 30 18 300 2 EDT 35 7/8" YES one E1 RNC1 cell2 50 25 18 240 4 MDT 30 7/8" YES one E1 RNC4 cell3 5 25 18 120 2 EDT + 2 MDT 30 7/8" YES one E1 RNC1 cell4 2 25 18 120 0 DT 30 7/8" YES one E1 RNC1 cell5 25 25 18 35 0 DT 30 7/8" NO one E1 RNC4 cell6 45 25 18 60 0 DT 30 7/8" YES one E1 RNC4 cell7 90 25 18 270 0 DT 30 7/8" YES one E1 RNC1 cell8 12 25 18 90 0 DT 30 7/8" YES one E1 RNC2 cell9 10 25 18 45 0 DT 30 7/8" YES one E1 RNC4 cell10 25 25 18 0 0 DT 30 7/8" NO one E1 RNC2


- 246 - © Ericsson 2006 LZT 123 8297 R1C

Cell Parameters, neighbouring cells

Cell name Ncell#1 Ncell#2 Ncell#3 Ncell#4 Ncell#5 Ncell#6 Ncell#7 Ncell#8 Ncell#9 Ncell#10 Ncell#11 Ncell#12 Ncell#13 Ncell#14 cell1 cell3 cell2 cell4 cell5 cell6 cell10 cell7 cell15 cell49 cell38 cell50 cell40 cell31 cell2 cell6 cell7 cell8 cell9 cell10 cell4 cell3 cell1 cell3 cell4 cell4 cell1 cell3 cell2 cell15 cell49 cell38 cell50 cell40 cell31 cell5 cell1 cell9 cell3 cell7 cell24 cell16 cell50 cell40 cell45 cell36 cell37 cell15 cell49 cell6 cell1 cell3 cell5 cell7 cell25 cell31 cell37 cell12 cell49 cell38 cell29 cell22 cell28 cell7 cell1 cell2 cell3 cell6 cell5 cell9 cell20 cell28 cell41 cell7 cell29 cell21 cell26 cell45 cell8 cell2 cell3 cell21 cell26 cell14 cell22 cell41 cell9 cell5 cell2 cell22 cell7 cell41 cell26 cell10 cell1 cell2 cell46 cell26 cell14 cell22 cell20


LZT 123 8297 R1C © 2006 Ericsson - 247 -

Cell Parameters

Cell name SC

primary Cpich Power bchPower

primary Sch Power

secondary SchPower

max Fach1 Power

max Fach2 Power

aich Power

pch Power

pich Power

Maximum Transmission Power

maxTx PowerUl

qualMeas Quantity

cell1 368 306 -31 -18 -35 18 15 -6 -4 -7 405 24 2 cell2 376 315 -31 -18 -35 18 15 -5 -4 -7 414 24 2 cell3 384 309 -31 -18 -35 18 15 -6 -4 -7 408 24 2 cell4 152 318 -31 -18 -35 18 15 -6 -4 -7 417 24 2 cell5 160 325 -31 -18 -35 18 15 -4 -2 -5 410 24 2 cell6 168 311 -31 -18 -35 18 15 -6 -4 -7 410 24 2 cell7 441 306 -31 -18 -35 18 15 -4 -2 -5 405 24 2 cell8 449 275 -31 -18 -35 18 15 -5 -4 -7 404 24 2 cell9 272 305 -31 -18 -35 18 15 -6 -4 -7 404 24 2 cell10 457 306 -31 -18 -35 18 15 -5 -4 -7 405 24 2

Cell name qHyst1 qHyst2 qQualMin

qRx LevMin

sInter Search

sIntra Search

sRat Search

Tre Selection

Individual Offset

ase DlAdm

ase UlAdm

ase UlAdm Offset

beMargin AseDl

beMargin AseUl

comp Mode Adm

cell1 2 2 -18 -115 0 0 -32 1 0 300 200 40 100 20 15 cell2 2 2 -18 -115 0 0 -32 1 0 300 200 40 100 20 15 cell3 2 2 -18 -115 0 0 -32 1 0 300 200 40 100 20 15 cell4 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15 cell5 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15 cell6 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15 cell7 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15 cell8 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15 cell9 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15 cell10 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15


- 248 - © Ericsson 2006 LZT 123 8297 R1C

Cell name

dlCode Adm

Pwr Adm

Pwr Adm Offset

sf8 Adm

sf32 Adm

sf16 Adm

max Pwr Max

min Pwr Max

Pwr Hyst

Pwr Offset

release AseDl

Constant Value Cprach

max Preamble Cycle

power Offset P0

power Offset Ppm

Aich Transmission Timing

preamble Retrans Max

cell1 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell2 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell3 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell4 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell5 70 65 35 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell6 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell7 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell8 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell9 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8 cell10 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8

Cell name spreadingFactor

sccpchOffset (FACH)

sccpchOffset (PCH) minPwrRl

beMargin DlPwr

beMargin DlCode

pOffset 1Fach

pOffset 3Fach

usedFreq Thresh2dEcno

usedFreq Thresh2dRscp

cell1 64 0 20 -150 10 2 0 0 -11 -97 cell2 64 0 20 -150 10 2 0 0 -11 -97 cell3 64 0 20 -150 10 2 0 0 -11 -97 cell4 64 0 20 -150 10 2 0 0 -11 -97 cell5 64 0 20 -150 2 2 0 0 -11 -97 cell6 64 0 20 -150 10 2 0 0 -11 -97 cell7 64 0 20 -95 10 2 0 0 -11 -97 cell8 64 0 20 -150 10 2 0 0 -11 -97 cell9 64 0 20 -150 10 2 0 0 -11 -97 cell10 64 0 20 -150 10 2 0 0 -11 -97


LZT 123 8297 R1C © 2006 Ericsson - 251 -

KEY PERFORMANCE INDICATORS ................................................253

ACCESSIBILITY ................................................................................255 SERVICE SUCCESS SETUP RATE ............................................................255 IDLE MODE ..................................................................................................257 RANDOM ACCESS ......................................................................................257 ADMISSION CONTROL ...............................................................................258

RETAINABILITY ................................................................................260 DROPPED CALL RATE................................................................................260 MINUTES PER DROP ..................................................................................261 HANDOVER FAILURE RATE .......................................................................262 INTER-FREQUENCY HANDOVER ..............................................................263 IRAT HANDOVER.........................................................................................264 CONGESTION ..............................................................................................265 OTHER REASONS .......................................................................................265

INTEGRITY ........................................................................................267 BLER.............................................................................................................267 THROUGHPUT.............................................................................................267


LZT 123 8297 R1C © 2006 Ericsson - 253 -

KEY PERFORMANCE INDICATORS In the sections that follow, UE radio Connection Configuration (UeRc) is used in various equations. The following table shows the mapping of UeRc to radio connection configuration.

UeRc Radio Connection Configuration 0 Idle 1 RRC Only 2 Speech (12,2/12,2 kbps) 3 CS data (64/64 kbps) 4 Packet (RACH/FACH) 5 Packet (64/64 kbps) 6 Packet (64/128 kbps) 7 Packet (64/384 kbps) 8 Streaming CS data (57,6/57,6 kbps) 9 Speech (12,2/12,2 kbps) + Interactive Packet (0/0 kbps) 10 Speech (12,2/12,2 kbps) + Interactive Packet (64/64 kbps) 11 RRC (13,6/13,6 kbps) 12 Preconfigured Speech (12,2/12,2 kbps) 13 PS Streaming (16/64 kbps) + Interactive Packet (8/8 kbps) 14 CS Data (64/64 kbps) + Interactive Packet (8/8 kbps) 15 PS Interactive (64/HS kbps) 16 PS Interactive (384/HS kbps) 17 PS Streaming (16/128 kbps) + Interactive Packet (8/8 kbps) 18 PS Interactive (128/128 kbps) 19 Speech (12,2/12,2 kbps) + Interactive Packet (64/HS kbps) 20 Speech (12,2/12,2 kbps) + Interactive Packet (384/HS kbps) 21 PS Interactive URA-PCH 22 PS Streaming (128/16 kbps) + Interactive Packet (8/8 kbps) 23 Speech (12,2/12,2 kbps) + PS Streaming (128/16 kbps) + Interactive Packet

(8/8 kbps) 24 Speech (12,2/12,2 kbps) + PS Streaming (16/128 kbps) + Interactive Packet

(8/8 kbps) 25 PS Interactive EUL/HS 26 PS Interactive (64/64 kbps) + Interactive Packet (64/64 kbps) 27 Speech (12,2/12,2 kbps) + PS Interactive (64/64 kbps) + Interactive Packet

(64/64 kbps) 28 PS Interactive (128/64 kbps) 29 PS Interactive (384/64 kbps) 30 PS Interactive (384/128 kbps) 31 PS Interactive (128/384 kbps) 32 PS Interactive (384/384 kbps) 33 Speech AMR (7,95/7,95 kbps)


- 254 - © Ericsson 2006 LZT 123 8297 R1C

34 Speech AMR (5,9/5,9 kbps) 35 Speech AMR (4,75/4,75 kbps) 36 Speech (12,2/12,2 kbps) + Interactive Packet (64/128 kbps) 37 Speech (12,2/12,2 kbps) + Interactive Packet (128/64 kbps) 38 Speech (12,2/12,2 kbps) + Interactive Packet (64/384 kbps) 39 Interactive Packet (64/128 kbps) + Interactive Packet (64/128 kbps)


LZT 123 8297 R1C © 2006 Ericsson - 255 -

ACCESSIBILITY

Accessibility is defined as the ability of a user to obtain requested service from the system. In WCDMA RAN, this metric can be measured by calculating the product of the probability of RRC Connection success and the probability of RAB establishment success. This metric can be calculated per cell and per RNC for all supported services. The RNC KPI is calculated by aggregating all the cell counters to RNC level and then applying the formula. The service Success setup rate will give the 1st category KPI. If the rate is low then the 2nd category KPi should be looked into further

SERVICE SUCCESS SETUP RATE

In this section all formulas are from an Utrancell perspective, if not otherwise stated.

Speech

⎟⎟⎠

⎞⎜⎜⎝

⎛×⎟⎟⎠

⎞⎜⎜⎝

⎛×

echAttemptSpebEstablishpmmTotNoRachuccessSpeeEstablishSpmTotNoRab

CsConnectReqpmTotNoRrcCsSuccConnectReqpmTotNoRrc100

where directed-retry is counted as access failure and inter-frequency load sharing is not considered. Alternatively, one can exclude directed-retry to GSM from the RAB establishment attempt, so that it is not counted as access failure on WCDMA RAN, and use the following equation.

⎟⎟⎠

⎞⎜⎜⎝

⎛×⎟⎟⎠

⎞⎜⎜⎝

⎛×

ryAttpmNoDirRet -ech AttemptSpebEstablishpmmTotNoRachuccessSpeeEstablishSpmTotNoRab


Circuit-Switched 64

⎟⎟⎠

⎞⎜⎜⎝

⎛×⎟⎟⎠

⎞⎜⎜⎝

⎛×

4AttemptCS6bEstablishpmmTotNoRauccessCS64EstablishSpmTotNoRab



- 256 - © Ericsson 2006 LZT 123 8297 R1C

Circuit-Switched 57

⎟⎟⎠

⎞⎜⎜⎝

⎛×⎟⎟⎠

⎞⎜⎜⎝

⎛×

7AttemptCS5bEstablishpmmTotNoRauccessCS57EstablishSpmTotNoRab


Packet-Switched Data Streaming

( ) ⎟⎟⎠

⎞⎜⎜⎝

⎛++

××am128PacketStreishAttemptmRabEstabl etStreamttemptPackEstablishApmTotNoRab

eam128sPacketStrlishSuccespmRabEstabetStreamuccessPackEstablishSpmTotNoRabY100p

Where Y = PsConnectReqpmTotNoRrc

PsSuccessConnectReqpmTotNoRrc

Packet-Switched Data Interactive

( ) ⎟⎟⎠

⎞⎜⎜⎝

⎛+

××FlowHardHOHS __1 iveetInteractttemptPackEstablishApmTotNoRab

ractiveuccessInteEstablishSpmTotNoRabY100

Where

Y = PsConnectReqpmTotNoRrc

PsSuccessConnectReqpmTotNoRrc

HS1_HardHO_Flow =

⎟⎟⎠

⎞⎜⎜⎝

⎛dChTargetHoReturnOlpmNoHsHard -AttemptngHsHardHopmNoIncomi -

dSourceHoReturnOipmNoHsHard -AttemptngHsHardHopmNoOutgoi

Packet-Switched Data Interactive HS

⎟⎟⎠

⎞⎜⎜⎝

⎛×⎟⎟⎠

⎞⎜⎜⎝

⎛×

eHSInteractivet ttemptPackEstablishApmTotNoRabiveHsetInteractuccessPackEstablishSpmTotNoRab

PsConnectReqpmTotNoRrcPsSuccConnectReqpmTotNoRrc100

Note that if the HS cell is on a separate frequency then the RRC contribution to the formula might be small or even zero, depending on parameter settings.


LZT 123 8297 R1C © 2006 Ericsson - 257 -

IDLE MODE


Paging

Successful First and Repeated Page attempts of total number of first attempts, Paging success rate in a MSC

⎟⎠⎞

⎜⎝⎛

++

×NPAG1LOTOT NPAG1GLTOT

CNPAG2RESUC CNPAG1RESUC100

Paging intensity per cell in a RNC (if RNC, LA and RA consist of exact same cells):

RNC that incells of number total period tmeasuremenUegingToIdlepmCnInitPa UeRagingToIdlepmCnInitPa UeLagingToIdlepmCnInitPa

×++

MP Load

RRC connection rejection rate due to module MP load control for a cell could be found in the following formula:

100%nnaringRrcCopmNoLoadSh-ConnectReqpmTotNoRrc

CConnMpLoadpmNoRejRrc×

RANDOM ACCESS


Preamble detections

Number/percentage of false detections, which is the case that preamble is detected but there is no enough energy in message part, due to noise on the random access channel for a carrier (it could be due to loss of AICH, wrong recognition of preamble or loss of RACH message part after the UE sends message out):

pmNoPreambleFalseDetection or


- 258 - © Ericsson 2006 LZT 123 8297 R1C

100%MessagespmPositive

ectionleFalseDetpmNoPreamb×

AICH detections

Percentage of getting AICH but no RRC connection setup, excluding cell (re)selection:

%100AICH_ACK of No

entestablishm RRC duringion (re)select cell of No-setup connection RRC of No -AICH_ACK of No×

ADMISSION CONTROL


DL transmission carrier power

Average DL TX power for a cell-carrier:

∑

∑

=

=⎥⎦

⎤⎢⎣

⎡⎟⎠⎞

⎜⎝⎛×

102

0ii

102

0ii

PowertedCarrierpmTransmit

2iPowertedCarrierpmTransmit

UL RSSI

Average UL RSSI for a cell-carrier:

( )[ ]

∑

∑

=

=

−××

62

0ii

62

0ii

ssipmAverageR

110.5i0.5ssipmAverageR

ASE usage

The formulas for checking the average usage of ASE in the downlink and uplink for a cell can be found below.

Average UL ASE for a cell: AseUlpmNoOfSamppAseUlpmSumOfSam


LZT 123 8297 R1C © 2006 Ericsson - 259 -

Average DL ASE for a cell: AseDlpmNoOfSamppAseDlpmSumOfSam

Code allocation

Code allocation failure for SFn, where n is the spreading factor for a cell could be found in the following formula (as an example the SF128 was used):

100%emptSf128deAllocAttpmNoDlChColureSf128deAllocFaipmNoDlChCo

×

Compressed mode

How many users are in compressed mode? Well the average number of user in compressed mode for a cell:

mpModepmSampesCo

odepmSumCompM

Loadsharing

In the following equations, RRC connection attempts are not corrected for redirections due to emergency calls. The counter pmNoOfRedirectedEmergencyCalls can be used to estimate the percentage of emergency call redirections on RNC level.

Ratio between RRC connection returning and redirection due to load sharing for a cell:

RrcConn aringpmNoLoadShnnrningRrcCopmNoOfRetu

To consider redirections due to inter-frequency load sharing, when the functionality is enabled, an example of equation is given below. A correction is then made to eliminate duplicated CS RRC connection attempts resulting from load sharing redirection orders. An equivalent formula can be defined to calculate all services.

The failures can be observed by the successful rate of directed retry to GSM for a cell:

100%edRetryAttpmNoDirectrySuccesspmNoDirRet

×


- 260 - © Ericsson 2006 LZT 123 8297 R1C

RETAINABILITY

Retainability is defined as the ability of user to retain its requested service once connected for the desired duration. This metric can be calculated per cell and per RNC for all supported services. In the following subsections, the formula for drop rate is given per UtranCell. The user can calculate the retainability by subtracting the following numbers from 100%. The drop rate will give the 1st category KPI. If the rate is low then the 2nd category KPI should be looked into further.

DROPPED CALL RATE

The dropped calls are for originating and terminating calls.

Speech

)ReRe(Re100

chleaseSpeecRabpmNoSystemhleaseSpeecRabpmNoNormalhleaseSpeecRabpmNoSystem

+×

Circuit-switched 64

) Cs64RabReleasepmNoSystem64Re(Cs64RabReleasepmNoSystem

100+

×leaseCsRabpmNoNormal

Circuit-switched Streaming

) CsStreamRabReleasepmNoSystemRe(CsStreamRabReleasepmNoSystem100

+×

eamleaseCsStrRabpmNoNormal

Packet Switched data Streaming

( )128ReReRe128ReRe100

tStreamleasePackeRabpmNosystemtStreamleasePackeRabpmNoSystemtStreamleasePackeRabpmNoNormaltStreamleasePackeRabpmNoSystemtStreamleasePackeRabpmNoSystem

+++

×

Packet Switched data Interactive

The drop rate of PS Interactive from user perspective can be approximated by the product of Packet-Switched system release rate and the access failure rate. That is, a user can complete its packet session completely if it can access the system even though there may be interruption during the


LZT 123 8297 R1C © 2006 Ericsson - 261 -

session. In this approximation, the assumption is that the application retries once after abnormal release. The Packet-Switched drop rate per UtranCell for all PS interactive services is given by Shows dropped call for all types of packet calls, including HSDPA calls.

( )tleasePackeRabpmNoSystemtleasePackeRabpmNoNormaltleasePackeRabpmNoSystem

ReReRe100

+×

MINUTES PER DROP

Speech

××chleaseSpeecRabpmNoSystem

UserUSpRe__100 number of minutes

Circuit-switched CS64

××64Re

__64100leaseCsRabpmNoSystem

UserUCs number of minutes

Circuit-switched Streaming

××eamleaseCsStrRabpmNoSystem

UserUCsRe

__57100 No of minutes

Packet Switched data Streaming

×+

×128ReRe

__8_100tStreamleasePackeRabpmNoSystemtStreamleasePackeRabpmNoSystem

UserUPPstr No of minutes

Packet Switched data Interactive

×++

×tleasePackeRabpmNoSystem

UserUPIntFachUserUPIntHsUserUPIntDCHRe

______100 No of minutes

Packet Switched data Interactive HS

××leaseHsRabpmNoSystem

UserUPIntHsRe

__100 No of minutes


- 262 - © Ericsson 2006 LZT 123 8297 R1C

HANDOVER FAILURE RATE

The following formula shows the failure rate for RL addition/replacement to active set

( )etlAddToActSpmNoTimesR ToActSetellFailAddpmNoTimesCToActSetellFailAddpmNoTimesC

+×100

HS Cell Change

The following metric measures the success rate for HS Cell Change in target cell

mptpmHsCcAtteesspmHsCcSucc100×

OUT of synch

Shows fraction of drop due to uplink Out of Sync reason. ( )

( )hleaseSpeecReRabpmNoSystemhleaseSpeecReRabpmNoNormalynchlSpeechULSRepmNoSys

+×100

Missing neighbours

The following formula shows the fraction of drops due to HO action when a valid or non-valid cell cannot be added to active set. This also includes drops due to missing neighbour.

( )SpeechRabReleasepmNoNormal SpeechRabReleasepmNoSystemSpeechSoHopmNoSysRel+

×100

shows fraction of speech drop due to HO action when a valid or non-valid cell cannot be added to active set. This includes also drop due to missing neighbour.

( )SpeechRabReleasepmNoNormal SpeechRabReleasepmNoSystem SpeechSoHopmNoSysRel

+×100

Shows fraction of speech drop due to missing neighbour reason when a non-valid cell cannot be added to active set.


LZT 123 8297 R1C © 2006 Ericsson - 263 -

( )SpeechRabReleasepmNoNormal SpeechRabReleasepmNoSystem hbrSpeechNeigpmNoSysRel

+×100

Soft handover overhead

In order to find to large handover areas in the system and to find out the average number of RL per user the following formula should be used:

habEstablispmSamplesRtablishpmSumRabEs

shRabEstabliRABpmSamplesshRabEstabliRABpmSum

dSHOoverhea allcells∑ ><

><

=

INTER-FREQUENCY HANDOVER

Speech

Drop due to IFHO failure for speech: Outgoing IFHO failure when UE failed to return to present active set.

ch12eqHoCsSpeeindInterFrpmAttNonBlech12evertCsSpereqHoFailRlindInterFpmFailNonB

×100

The following formula might give slightly lower result:

⎟⎟⎠

⎞⎜⎜⎝

⎛ ++×

ech12evertCsSpereqHoFailRlindInterFpmFailNonB2tCsSpeech1reqHoReverlindInterFpmFailNonB ech12reqHoCsSpelindInterFpmSuccNonB

ech12evertCsSpereqHoFailRlindInterFpmFailNonB100

CS Services

Drop due to IFHO failure for CS except speech: Outgoing IFHO failure when UE failed to return to present active set.

ersationaleqHoCsConvindInterFrpmAttNonBllversationaevertCsConreqHoFailRlindInterFpmFailNonB

×100

UtranCell counters

RNC counters


- 264 - © Ericsson 2006 LZT 123 8297 R1C

PS Services

Drop due to IFHO failure for PS less or equal to 64 kbps: Outgoing IFHO failure when UE failed to return to present active set.

s64ractiveLeseqHoPsInteindInterFrpmAttNonBlss64eractiveLeevertPsIntreqHoFailRlindInterFpmFailNonB

×100

Drop due to IFHO failure for PS greater than 64 kbps: Outgoing IFHO failure when UE failed to return to the present active set.

ater64ractiveGreeqHoPsInteindInterFrpmAttNonBleater64eractiveGrevertPsIntreqHoFailRlindInterFpmFailNonB

×100

Drop due to IFHO failure for PS streaming and others: Outgoing IFHO failure when UE failed to return to the present active set.

ingOthereqHoStreamindInterFrpmAttNonBlmingOtherevertStreareqHoFailRlindInterFpmFailNonB

×100

IRAT HANDOVER

Speech

The following metric measures hard handover success rate between UtranCell and target GSM cell for speech calls. The formula is considering the GsmRelation.

chIratHoSpeepmNoAttOutSpeechsOutIratHopmNoSucces

×100

CS57

The following metric measures hard handover success rate between UtranCell and target GSM cell for CS streaming calls. The formula is considering the GsmRelation.

IratHoCs57pmNoAttOutCs57sOutIratHopmNoSucces

×100


LZT 123 8297 R1C © 2006 Ericsson - 265 -

IRAT Handover Multi-RAB

The following metric measures hard handover success rate between UtranCell and target GSM cell for Multi-RAB calls. The formula is considering the GsmRelation.

iIratHoMultpmNoAttOutMultisOutIratHopmNoSucces

×100

IRAT Handover Packet Data

The following metric measures cell change failure rate between UtranCell and target GSM cell for PS calls when the UE successfully returns to UtranCell. The formula is considering the GsmRelation.

tCcAttpmNoOutIraldChtCcReturnOpmNoOutIra

×100

CONGESTION

Shows fraction of speech drop due to congestion action


SpeechCongpmNoOfTerm+

×100

Shows fraction of video call drop due to congestion action

( )( )6464

100leaseCsReRabpmNoSystemleaseCsReRabpmNoNormal

CsCongpmNoOfTerm+

×

OTHER REASONS

Shows fraction of speech drop due to other reasons than HO action, UL out of sync and congestion.


SpeechCongpmNoOfTermynchlSpeechULSRepmNoSysolSpeechSoHRepmNoSyshleaseSpeecReRabpmNoSystem+

−−−×100

Transport network

Shows percentage of rejected incoming/outgoing Aal2 connection establishment requests on transport network.


- 266 - © Ericsson 2006 LZT 123 8297 R1C

( )( )XYmoteonnspmSuccOutCmotennspmSuccInCo

XY+++

+×

ReRe100

Where

X = pmUnSuccOutConnsLocal + pmUnSuccOutConnsRemote

Y = pmUnSuccInConnsLocal + pmUnSuccInConnsRemote


LZT 123 8297 R1C © 2006 Ericsson - 267 -

INTEGRITY

Integrity is defined as the ability of a user to receive the requested service at desired quality. The drop rate will give the 1st category KPI. If the rate is low then the 2nd category KPI should be looked into further.

BLER

The method for finding worst performing cells is based on top to down analysis. Initially worst 10-15 performing cells can be identified based on the Uplink Block Error rate before combining.

ltBlocksBcUpmTransporcksBcULansportBlopmFaultyTr100×

The Formula below shows Block Error rate after uplink combining at RNC level. That means blocks in RNC coming from different legs in SHO are compared, each radio connection.

l[UeRc]tBlocksAcUpmTransporRc]cksAcUl[UeansportBlopmFaultyTr100×

UeRc stands for different RAB’s which can be found in the table in the beginning of this Appendix

THROUGHPUT

Packet-Switched DCH/FACH Interactive average throughput

The following equation measures the Average Throughput for PS interactive DCH/FACH.

Counters for small packets, pmSentPacketData1 and pmTotalPacketDurationHs are not included in the formula as there is a constant one-way delay for each packet affecting latency for the small packets, which gives a worse measured performance than user perceived performance, if these counters are used.

n4ketDuratiopmTotalPacn3ketDuratiopmtotalPac n2ketDuratiopmTotalPacetData4pmSentPacketData3pmSentPack000)ketData2/1(pmSentPac8000

++++

×


- 268 - © Ericsson 2006 LZT 123 8297 R1C

The counters in the formula above is from the RNCFuntion.

Packet-Switched Interactive HS average throughput

The following equation measures the Average Throughput for PS interactive HS. Counters for small packets, pmSentPacketDataHs1, pmSentPacketDataHs2, pmTotalPacketDurationHs1 and pmTotalPacketDurationHs2 are not included in the formula as there is a constant one-way delay for each packet affecting latency for the small packets, which gives a worse measured performance than user perceived performance, if these counters are used.

nHs4ketDuratiopmTotalPac nHs3ketDuratiopmTotalPac

tDataHs4mSentPackeketDataHs3(pmSentPac8000++

×p


Packet-Switched DCH/FACH Interactive Retransmission Rate

The following equation measures the retransmission rate for PS interactive DCH/FACH.

etrans4etDataIncRpmSentPacketrans3etDataIncRpmSentPack00)etrans2/10etDataIncRpmSentPack(000)Retrans1/1ketDataInc(pmSentPacetData4pmSentPacketData3pmSentPack00)etData2/10pmSentPack(000)ketData1/1(pmSentPac

++++++


Packet-Switched Interactive HS Retransmission Rate

The following equation measures the retransmission rate for PS interactive HS.

etransHs4etDataIncRpmSentPacketransHs3etDataIncRpmSentPack1000)etransHs2/etDataIncRpmSentPack(/1000)RetransHs1ketDataInc(pmSentPacetDataHs4pmSentPacketDataHs3pmSentPack1000)etDataHs2/pmSentPack(/1000)ketDataHs1(pmSentPac

++++++


RAB throughput excluding HSDPA

Average throughput per cell and RAB in the DL, excluding HSDPA:

⎟⎟⎠

⎞⎜⎜⎝

⎛><

><><

=sec* ROP

shRabEstabliRABpmSamplesshRabEstabliRABpmSumRABcVolumepmDlTraffiThroughput


LZT 123 8297 R1C © 2006 Ericsson - 269 -

RAB efficiency excluding HSDPA

The RAB efficiency can also be checked

x per UeRc Bitrate NominalRABper Bitrate Actual

==EfficiencyRAB


LZT 123 8297 R1C © 2006 Ericsson - 273 -

SUMMARY.........................................................................................275


LZT 123 8297 R1C © 2006 Ericsson - 275 -

SUMMARY There are only two predefined scanners in the RNC. The first, PREDEF.PRIMARY.STATS, contains only the most important RNC radio network counters. These counters are typically used to calculate high-level KPIs. The second, PREDEF.SECONDARY.STATS, contains important counters, typically used for troubleshooting.

Both PRIMARY and SECONDARY scanners are initially active on startup of the RNC

Scanner Performance Management Areas

Counter Name

Primary Scanner

Admission pmNoOfNonHoReqDeniedCs

pmNoOfNonHoReqDeniedInteractive

pmNoOfNonHoReqDeniedPsStreaming

pmNoOfNonHoReqDeniedSpeech

pmNoOfNonHoReqDeniedHs

pmNoOfNonHoReqDeniedEul

pmNoOfNonHoReqDeniedPsStr128

Admission Monitoring -

Cell Availability pmCellDowntimeAuto

pmCellDowntimeMan

pmHsDowntimeMan

pmHsDowntimeAuto

pmEulDowntimeMan

pmEulDowntimeAuto

Cell Update -

Channel Switching pmChSwitchFachIdle

Channel Quality pmFaultyTransportBlocksAcUl

pmTransportBlocksAcUl

Code Control -

Compressed Mode -

Congestion pmTotalTimeDlCellCong

pmTotalTimeUlCellCong

Diversity -

Frame Synchronization -

Handover -

Inter-Frequency Handover

pmNoIncomingHsHardHoAttempt

pmNoOutgoingHsHardHoAttempt

pmNoHsHardHoReturnOldChSource

pmNoHsHardHoReturnOldChTarget

pmNoIncomingEulHardHoAttempt

pmNoEulHardHoReturnOldChSource


- 276 - © Ericsson 2006 LZT 123 8297 R1C

pmNoEulHardHoReturnOldChSource

IRAT Handover, Outgoing

pmNoDirRetryAtt

IRAT Incoming -

IRAT Cell Change, Outgoing

-

IRAT Cell Change, Incoming

-

UE Positioning -

Iu Ranap Handling pmNoIuSigEstablishAttemptCs

pmNoIuSigEstablishSuccessCs

pmNoIuSigEstablishAttemptPs

pmNoIuSigEstablishSuccessPs

Iur Channel Handling -

Iur Channel Error Handling

-

Paging -

Packet Data pmSentPacketData1

pmSentPacketDataInclRetrans1

pmTotalPacketDuration1

pmNoOfPacketCallDuration1

pmSentPacketData2




pmSentPacketData3




pmSentPacketData4




pmSentPacketDataHs1

pmSentPacketDataInclRetransHs1

pmTotalPacketDurationHs1

pmNoOfPacketCallDurationHs1

pmSentPacketDataHs2




pmSentPacketDataHs3




pmSentPacketDataHs4


LZT 123 8297 R1C © 2006 Ericsson - 277 -




pmSamplesActUlRlcTotPacketThp

pmSumActUlRlcTotPacketThp

pmSamplesActDlRlcTotPacketThp

pmSumActDlRlcTotPacketThp

pmSamplesActUlRlcUserPacketThp

pmSumActUlRlcUserPacketThp

pmSamplesActDlRlcUserPacketThp

pmSumActDlRlcUserPacketThp

Payload Traffic -

Processor Supervision -

RAB Handling pmNoNormalRabReleaseCs64

pmNoNormalRabReleaseCsStream

pmNoNormalRabReleasePacket

pmNoNormalRabReleasePacketStream

pmNoNormalRabReleaseSpeech

pmNoRabEstablishAttemptPacketInteractiveEul

pmNoRabEstablishSuccessPacketInteractiveEul

pmRabEstablishEcAttempt

pmRabEstablishEcSuccess

pmNoRabEstablishAttemptCs57

pmNoRabEstablishAttemptCs64

pmNoRabEstablishAttemptPacketInteractive

pmNoRabEstablishAttemptPacketStream

pmNoRabEstablishAttemptSpeech

pmNoRabEstablishSuccessCs57

pmNoRabEstablishSuccessCs64

pmNoRabEstablishSuccessPacketInteractive

pmNoRabEstablishSuccessPacketStream

pmNoRabEstablishSuccessSpeech

pmNoNormalRabReleasePacketUra

pmNoSystemRabReleaseCs64

pmNoSystemRabReleaseCsStream

pmNoSystemRabReleasePacket

pmNoSystemRabReleasePacketStream

pmNoSystemRabReleaseSpeech

pmNoTpSwitchSp64Speech

pmSamplesBestCs12Establish

pmSamplesCs12RabEstablish

pmSumBestCs12Establish

pmSumCs12RabEstablish

pmNoRabEstablishAttemptPacketInteractiveHs

pmNoRabEstablishSuccessPacketInteractiveHs

pmNoNormalRbReleaseHs


- 278 - © Ericsson 2006 LZT 123 8297 R1C

pmNoSystemRbReleaseHs

pmNoNormalRbReleaseEul

pmNoSystemRbReleaseEul

pmSumBestPsEulRabEstablish

pmSamplesBestPsEulRabEstablish

pmSamplesBestPsHsAdchRabEstablish

pmSumBestPsHsAdchRabEstablish

pmNoRabEstablishSuccessPacketStream128

pmNoRabEstablishAttemptPacketStream128

pmSamplesBestPsStr128Ps8RabEstablish

pmSumBestPsStr128Ps8RabEstablish

PmNoNormalRabReleasePacketStream128

PmNoSystemRabReleasePacketStream128

pmSamplesBestCs57RabEstablish

pmSumBestCs57RabEstablish

pmSamplesBestCs64RabEstablish

pmSumBestCs64RabEstablish

pmSamplesFachPsIntRabEstablish

pmSumFachPsIntRabEstablish

pmSamplesBestDchPsIntRabEstablish

pmSumBestDchPsIntRabEstablish

pmSamplesBestPsStr64Ps8RabEstablish

pmSumBestPsStr64Ps8RabEstablish

pmSamplesPsInteractive

pmSumPsInteractive

pmSumAmr12200RabEstablish




pmSumBestAmr12200RabEstablish





Radio Connection Supervision

-

RLC Handling -

RRC Handling pmNoOfRedirectedEmergencyCalls

pmNoCsStreamDchDiscAbnorm

pmNoCsStreamDchDiscNormal

pmNoLoadSharingRrcConn

pmNoPsStream64Ps8DchDiscAbnorm

pmNoPsStream64Ps8DchDiscNormal

pmTotNoRrcConnectReq

pmTotNoRrcConnectReqCs

pmTotNoRrcConnectReqCsSucc


LZT 123 8297 R1C © 2006 Ericsson - 279 -

pmTotNoRrcConnectReqPs

pmTotNoRrcConnectReqPsSucc

pmTotNoRrcConnectReqSuccess

Security -

Radio Link Addition -

Counters Not Reporting for Drift UEs

-

Secondary Scanner

Admission pmNoFailedAfterAdm

pmNoOfSwDownNgAdm

pmNoReqDeniedAdm

Admission Monitoring pmNoOfSampAseDl

pmNoOfSampAseUl

pmSumOfSampAseDl

pmSumOfSampAseUl

Cell Availability -

Cell Update pmNoCellUpdAttempt

pmNoCellUpdSuccess

Channel Switching pmChSwitchAttemptFachUra

pmChSwitchSuccFachUra

pmChSwitchAttemptUraFach

pmChSwitchSuccUraFach

pmDownSwitchAttempt

pmDownSwitchSuccess

pmUlUpswitchSuccessMedium

pmUlUpswitchAttemptMedium

pmUpswitchFachHsSuccess

pmUpswitchFachHsAttempt

pmUlUpswitchSuccessLow

pmUlUpswitchAttemptLow

pmUlUpswitchSuccessHigh

pmUlUpswitchAttemptHigh

pmDlUpswitchSuccessHs

pmDlUpswitchAttemptHs

pmDlUpswitchAttemptLow

pmDlUpswitchAttemptMedium

pmDlUpswitchAttemptHigh

pmDlUpswitchSuccessLow

pmDlUpswitchSuccessMedium

pmDlUpswitchSuccessHigh

Channel Quality pmSamplesUlRssi

pmSumUlRssi

pmEulHarqTransmTti10PsInteractive

pmEulHarqTransmTti10Srb

pmEulHarqTransmTti10Failure

Code Control -


- 280 - © Ericsson 2006 LZT 123 8297 R1C

Compressed Mode -

Congestion pmSumOfTimesMeasOlDl

pmSumOfTimesMeasOlUl

Diversity pmNoOfRlForDriftingUesPerDrnc

pmNoOfRlForDriftingUes

pmNoOfRlForNonDriftingUes

Frame Synchronization -

Handover pmNoTimesCellFailAddToActSet

pmNoTimesRlAddToActSet

pmNoTimesRlDelFrActSet

pmNoTimesRlRepInActSet


pmNoIncomingHsHardHoSuccess

pmNoOutgoingHsHardHoSuccess

pmNoOutgoingEulHardHoSuccess

pmNoIncomingEulHardHoSuccess

Inter-Radio Access Technology Handover, Outgoing

pmNoDirRetrySuccess

Inter-Radio Access Technology Handover, Incoming

-

Inter-Radio Access Technology Cell Change, Outgoing

-

Inter-Radio Access Technology Cell Change, Incoming

-

UE Positioning -

Iur Channel Handling -


-

Paging pmUtranInitPagingToUraU

pmCnInitPagingToUraUe

Packet Data pmUlRlcUserPacketThp

pmDlRlcUserPacketThp

Processor Supervision pmSamplesMeasuredLoad

pmSumMeasuredLoad

pmSamplesMeasuredCcSpLoad

pmSumMeasuredCcSpLoad

pmSamplesMeasuredDcSpLoad

pmSumMeasuredDcSpLoad

pmSamplesMeasuredPdrSpLoad

pmSumMeasuredPdrSpLoad

RAB Handling pmSamplesRabUra

pmSumRabUra

pmSamplesPsEulRabEstablish


LZT 123 8297 R1C © 2006 Ericsson - 281 -

pmSumPsEulRabEstablish

pmNoRabEstablishFailureUeCapability

pmNoFailedRabEstAttemptExceedConnLimit

pmNoFailedRabEstAttemptLackDlPwr

pmNoFailedRabEstAttemptLackDlChnlCode

pmNoFailedRabEstAttemptLackDlAse

pmNoFailedRabEstAttemptLackUlAse

pmSamplesCs64Ps8RabEstablish

pmSumCs64Ps8RabEstablish

pmSamplesPsHsAdchRabEstablish

pmSumPsHsAdchRabEstablish

pmSamplesPsStr128Ps8RabEstablish

pmSumPsStr128Ps8RabEstablish

pmInactivityPsStreamIdle

pmSamplesBestCs12PsIntRabEstablish

pmSumBestCs12PsIntRabEstablish

pmSamplesBestCs64PsIntRabEstablis

pmSumBestCs64PsIntRabEstablish

pmNoNormalRabReleaseSpeech

pmNoNormalRabReleasePacket

pmNoNormalRabReleaseCs64

pmNoNormalRabReleaseCsStream

pmNoNormalRabReleasePacketStream

pmNoSystemRabReleaseSpeech

pmNoSystemRabReleasePacket

pmNoSystemRabReleasePacketUra

pmNoSystemRabReleaseCs64

pmNoSystemRabReleaseCsStream

pmNoSystemRabReleasePacketStream

pmUlUpswitchAttemptEul

pmUlUpswitchSuccessEul


pmNoReleaseCchWaitCuT

pmNoReleaseDchRcLostT

pmNoRlcErrors

RLC Handling -

RRC Handling pmNoCellDchDisconnectAbnorm

pmNoCellDchDisconnectNormal

pmNoCellFachDisconnectAbnorm

pmNoCellFachDisconnectNormal

pmNoCs64DchDiscAbnorm

pmNoCs64DchDiscNormal

pmNoOfReturningEmergencyCalls

pmNoOfReturningRrcConn

pmNoPacketDchDiscAbnorm

pmNoPacketDchDiscNormal


- 282 - © Ericsson 2006 LZT 123 8297 R1C

pmNoRejRrcConnMpLoadC

pmNoSpeechDchDiscAbnorm

pmNoSpeechDchDiscNormal

pmNoSysRelSpeechNeighbr

pmNoSysRelSpeechSoHo

pmNoSysRelSpeechUlSynch

pmTotNoUtranRejRrcConnReq

Security -


HS-DSCH Cell Change pmNoHsCcAttempt

pmNoHsCcSuccess

Ura Update pmNoUraUpdAttempt

pmNoUraUpdSuccess

Not included in any predefined scanner

Admission pmNoOfDiscardedNbapMessages

Admission Monitoring -

Cell Availability -

Cell Update -

Channel Switching pmChSwitchDch128Fach

pmChSwitchDch384Fach

pmChSwitchDch64Fach

pmChSwitchFachDch

pmChSwitchP128P384

pmChSwitchP128P64

pmChSwitchP384P128

pmChSwitchP64P128

pmChSwitchSp0Sp64

pmChSwitchSp64Sp0

pmFailedChSwitch

pmFailedDchChSwitch

pmNoOfSwDownNgHo

pmFailedDchChSwitch

Channel Quality pmFaultyTransportBlocks

pmNoRecRandomAccSuccess

pmTransportBlocks

pmFaultyTransportBlocksBcUl

pmTransportBlocksBcUl

Code Control pmNoDlChCodeAllocAltCodeCm

pmNoDlChCodeAllocAttemptCm

pmNoDlChCodeAllocAttemptSf128





LZT 123 8297 R1C © 2006 Ericsson - 283 -



pmNoDlChCodeAllocFailureSf128






Compressed Mode pmCmAttDlHls

pmCmAttDlSf2

pmCmAttUlHls

pmCmAttUlSf2

pmCmStop

pmCmSuccDlHls

pmCmSuccDlSf2

pmCmSuccUlHls

pmCmSuccUlSf2

pmInterFreqMeasCmStart

pmInterFreqMeasCmStop

pmSamplesCompMode

pmSumCompMode

Congestion pmNoOfIurSwDownNgCong

pmNoOfIurTermCsCong

pmNoOfIurTermSpeechCong

pmNoOfSwDownNgCong

pmNoOfTermCsCong

pmNoOfTermSpeechCong

pmNoOfIurTermHsCong

pmNoOfSwDownHsCong

CN Hard Handover pmNoAttOutCnhhoSpeech

pmNoSuccOutCnhhoSpeech

pmNoAttOutCnhhoCsNonSpeech

pmNoSuccOutCnhhoCsNonSpeech

pmNoAttOutCnhhoPsConnRelease

pmNoAttIncCnhhoSpeech

pmNoSuccIncCnhhoSpeech

pmNoAttIncCnhhoCsNonSpeech

pmNoSuccIncCnhhoCsNonSpeech

Diversity pmSamplesUesWith1Rls1RlInActSet

pmSamplesUesWith1Rls2RlInActSet








- 284 - © Ericsson 2006 LZT 123 8297 R1C


pmSumUesWith1Rls1RlInActSet









Frame Synchronization pmNoCchDiscardedDataFramesE

pmNoCchDiscardedDataFramesL

pmNoCchTimingAdjContrFrames

pmNoDchDlTimingAdjContrFrames

pmNoDchUlDataFramesOutsideWindow

pmNoDlDchDiscardedDataFramesE

pmNoDlDchDiscardedDataFramesL

pmNoUlDchDiscardedDataFramesE

pmNoUlDchDiscardedDataFramesL

Handover pmInterFreqMeasNoCmStart

pmInterFreqMeasNoCmStop

pmRlAddAttemptsBestCellCsConvers

pmRlAddAttemptsBestCellPacketHigh

pmRlAddAttemptsBestCellPacketLow

pmRlAddAttemptsBestCellSpeech

pmRlAddAttemptsBestCellStandAlone

pmRlAddAttemptsBestCellStream

pmRlAddSuccessBestCellCsConvers

pmRlAddSuccessBestCellPacketHigh

pmRlAddSuccessBestCellPacketLow

pmRlAddSuccessBestCellSpeech

pmRlAddSuccessBestCellStandAlone

pmRlAddSuccessBestCellStream

pmTotNoSbHo

pmNoSbHoMeasStart

pmNoSuccessSbHo


pmAttNonBlindInterFreqHoCsConversational

pmAttNonBlindInterFreqHoCsSpeech12

pmAttNonBlindInterFreqHoPsInteractiveGreater64

pmAttNonBlindInterFreqHoPsInteractiveLess64

pmAttNonBlindInterFreqHoStreamingOther

pmFailNonBlindInterFreqHoFailRevertCsConversational

pmFailNonBlindInterFreqHoFailRevertCsSpeech12

pmFailNonBlindInterFreqHoFailRevertPsInteractiveGr


LZT 123 8297 R1C © 2006 Ericsson - 285 -

eater64

pmFailNonBlindInterFreqHoFailRevertPsInteractiveLess64

pmFailNonBlindInterFreqHoFailRevertStreamingOther

pmFailNonBlindInterFreqHoRevertCsConversational

pmFailNonBlindInterFreqHoRevertCsSpeech12

pmFailNonBlindInterFreqHoRevertPsInteractiveGreater64

pmFailNonBlindInterFreqHoRevertPsInteractiveLess64

pmFailNonBlindInterFreqHoRevertStreamingOther

pmSuccNonBlindInterFreqHoCsConversational

pmSuccNonBlindInterFreqHoCsSpeech12

pmSuccNonBlindInterFreqHoPsInteractiveGreater64

pmSuccNonBlindInterFreqHoPsInteractiveLess64

pmSuccNonBlindInterFreqHoStreamingOther

pmNoTimesIfhoRlAddToActSet

pmNoTimesIfhoCellFailAddToActSet

pmNoRlDeniedAdm

pmEnableHsHhoAttempt

pmEnableHsHhoSuccess

IRAT, Outgoing pmIratHoGsmMeasCmStart

pmIratHoGsmMeasNoCmStart

pmNoAttOutIratHoSpeech

pmNoAttOutIratHoCs57

pmNoAttOutIratHoMulti

pmNoAttOutIratHoStandalone

pmNoSuccessOutIratHoSpeech

pmNoSuccessOutIratHoCs57

pmNoSuccessOutIratHoMulti

pmNoSuccessOutIratHoStandalone

pmNoFailOutIratHoSpeechReturnOldChPhyChFail

pmNoFailOutIratHoCs57ReturnOldChPhyChFail

pmNoFailOutIratHoMultiReturnOldChPhyChFail

pmNoFailOutIratHoStandaloneReturnOldChPhyChFail

pmNoFailOutIratHoSpeechReturnOldChNotPhyChFail

pmNoFailOutIratHoCs57ReturnOldChNotPhyChFail

pmNoFailOutIratHoMultiReturnOldChNotPhyChFail

pmNoFailOutIratHoSpeechUeRejection

pmNoFailOutIratHoCs57UeRejection

pmNoFailOutIratHoMultiUeRejection

pmNoFailOutIratHoStandaloneUeRejection

pmNoAttOutSbHoSpeech

pmNoSuccessOutSbHoSpeech

pmNoFailOutSbHoSpeechReturnOldChPhyChFail

pmNoFailOutSbHoSpeechReturnOldChNotPhyChFail

pmNoFailOutSbHoSpeechGsmFailure


- 286 - © Ericsson 2006 LZT 123 8297 R1C

pmNoFailOutSbHoSpeechUeRejection

IRAT, Incoming pmNoInCsIratHoAdmFail

pmNoInCsIratHoAtt

pmNoInCsIratHoSuccess

IRAT Cell Change, Outgoing

pmNoOutIratCcReturnOldCh

pmNoOutIratCcSuccess

pmNoOutIratCcAtt

IRAT Cell Change, Incoming

pmTotNoRrcConnectAttIratCcOrder

pmTotNoRrcConnectAttIratCellResel

pmTotNoRrcConnectFailCongIratCcOrder

pmTotNoRrcConnectFailCongIratCellResel

pmTotNoRrcConnectSuccessIratCcOrder

pmTotNoRrcConnectSuccessIratCellResel

Iu Ranap Handling pmNnsfNriRouted

pmNnsfLoadDistributionRouted

UE Positioning pmPositioningReqAtt

pmPositioningReqAttCellId

pmPositioningReqAttEsCellId

pmPositioningReqSucc

pmPositioningReqSuccCellId

pmPositioningReqSuccCellIdQoSSucc

pmPositioningReqAttAgps

pmPositioningReqSuccAgps

pmPositioningReqSuccAgpsQosSucc

pmPositioningReqUnsuccAgpsAbort

pmPositioningReqReAttCellId

pmPositioningReqReAttSuccCellId

pmPositioningReqAttEsAgps

pmPositioningReqSuccEsAgps

pmPositioningReqSuccEsAgpsQosSucc

pmPositioningReqReAttEsCellId

Iur Channel Handling pmIurCommonEstAttExistTranspBearer

pmIurCommonEstAttNewTranspBearer

pmIurCommonEstSuccExistTranspBearer

pmIurCommonEstSuccNewTranspBearer

pmIurCommonRelease

pmIurTranspBearerRelease


pmIurCommonControlFrames

pmIurCommonControlFramesFaulty

pmIurCommonDlFrames

pmIurCommonDlFramesFaulty

pmIurCommonFachControlFrames

pmIurCommonFachControlFrameTimeout


LZT 123 8297 R1C © 2006 Ericsson - 287 -

pmIurCommonFachDataFrames

pmIurCommonFachDataFramesFaulty

pmIurCommonUlFrames

pmIurCommonUlFramesFaulty

Paging pmCnInitPagingToIdleUeLa

pmCnInitPagingToIdleUe

pmNoPageDiscardCmpLoadC

pmCnInitPagingToIdleUeRa

pmNoPagingType1AttemptUtran

pmNoPagingType1AttemptUtranCs

pmNoPagingType1AttemptUtranPs

pmNoPagingAttemptCnInitDcch

pmNoPagingAttemptUtranRejected

Packet Data pmNoFaultyIpPackets

pmNoRoutedIpBytesDl

pmNoRoutedIpBytesUl

pmNoRoutedIpPacketsDl

pmNoRoutedIpPacketsUl

pmSamplesPacketDataRab

pmSumPacketDataRab

Payload Traffic pmUlTrafficVolumeAmr7950

pmDlTrafficVolumeAmr7950

pmUlTrafficVolumeAmr5900


pmUlTrafficVolumeAmr4750


pmDlDchTrafficVolumeBeforeSplit

pmDlFachTrafficVolume

pmUlDchTrafficVolumeAfterComb

pmUlRachTrafficVolume

pmDlTrafficVolumeCs12



pmDlTrafficVolumePs128



pmDlTrafficVolumePsCommon

pmUlTrafficVolumeCs12



pmUlTrafficVolumePs128



pmUlTrafficVolumePsCommon

pmUlTrafficVolumePsStr128Ps8

pmDlTrafficVolumePsStr128Ps8


- 288 - © Ericsson 2006 LZT 123 8297 R1C

Processor Supervision pmAdmittedRequestsB0

pmAdmittedRequestsB1

pmAdmittedRequestsF0





pmRefusedRequestsB0

pmRefusedRequestsB1

pmRefusedRequestsF0

pmRefusedRequestsF1

pmRefusedRequestsF2

pmRefusedRequestsF3

pmRefusedRequestsF4

RAB Handling pmNoInvalidRabEstablishAttempts

pmNoInvalidRabReleaseAttempts

pmNoRabEstablishAttempts

pmNoRabEstablishSuccess

pmNoRabReleaseAttempts

pmNoRabReleaseSuccess

pmSamplesRabEstablish

pmSumRabEstablish





pmSamplesPs128RabEstablish



pmSamplesPsStr64Ps8RabEstablish

pmSamplesRabFach

pmSamplesRrcOnlyEstablish





pmSumPs128RabEstablish



pmSumPsStr64Ps8RabEstablish

pmSumRabFach

pmSumRrcOnlyEstablish

pmHsToDchAttempt

pmHsToDchSuccess

pmNoRabEstablishAttemptAmrNb

pmNoRabEstablishSuccessAmrNb


LZT 123 8297 R1C © 2006 Ericsson - 289 -

pmNoNormalRabReleaseAmrNb

pmNoSystemRabReleaseAmrNb

pmSamplesAmr12200RabEstablish




pmSamplesBestAmr12200RabEstablish





RLC Handling pmSamplesBestAmr4750RabEstablish

pmNoDiscardSduDtch

pmNoReceivedSduDcch

pmNoReceivedSduDtch

pmNoRetransPduDcch

pmNoRetransPduDtch

pmNoSentPduDcch

pmNoSentPduDtch

RRC Handling pmTotNoRrcConnectReqSms

pmNoPsStream128Ps8DchDiscNormal

pmNoPsStream128Ps8DchDiscAbnorm

pmNoRrcCsReqDeniedAdm

pmNoRrcPsReqDeniedAdm

pmNoRrcReqDeniedAdm

pmTotNoTermRrcConnectReq

pmTotNoTermRrcConnectReqCs

pmTotNoTermRrcConnectReqPs

Security pmIntegrityFailureRrcMsg


Counters Not Reporting for Drift UEs

-


LZT 123 8297 R1C © 2006 Ericsson - 293 -

Figure 1-1 Overview of the Radio Network evolution...................................................................... 13 Figure 1-2. The difference between RAN tuning and RAN optimization......................................... 14 Figure 1-3 UTRAN Observability Model.......................................................................................... 15 Figure 1-4 Network performance Monitoring .................................................................................. 16 Figure 1-5. Measuring Network Quality .......................................................................................... 17 Figure 1-6. WCDMA RAN Architecture........................................................................................... 18 Figure 1-7. Network Quality of Service (QoS)................................................................................. 19 Figure 1-8 Performance Analyses .................................................................................................. 20 Figure 1-9 Optimization Process..................................................................................................... 21 Figure 1-10. Module process ......................................................................................................... 24 Table 1- Speech Call Drop for RNC................................................................................................ 29 Table 2- Output from unpaired t-test............................................................................................... 30 Figure 2-2. Example of traffic distributed over 10 days................................................................... 38 Figure 2-3. Example of statistics from a PDF counter .................................................................... 40 Table 2-4. Grouping the counters based on their NE Origin (SDM = Statistical Data Mart) ........... 42 Figure 2-5. Statistics profile activation ............................................................................................ 43 Table 2-6. Pre-defined profiles........................................................................................................ 45 Table 2-7. Main differences between user-defined and pre-defined profiles .................................. 45 Figure 2-8. Profiles, Scanners and Counters – RNC example ....................................................... 46 Figure 3-1 A mobile originating call setup and the different action taken ....................................... 55 Figure 3-2 A The Accessibility workflow ......................................................................................... 56 Figure 3-3 The relationship between some of the idle mode tasks................................................. 58 Figure 3-4 Determination of Cell Selection Criteria......................................................................... 60 Figure 3-5 Periodic Registration ..................................................................................................... 61 Figure 3-6 The Paging counter flowchart ........................................................................................ 65 Figure 3-7 The Random Access counter flowchart ......................................................................... 68 Figure 3-8 WCDMA Power Control ................................................................................................. 70 Figure 3-9 A mobile originating call setup and the different action taken ....................................... 72 Figure 3-10 WCDMA Capacity Management (Admission Control) ................................................. 74 Figure 3-11 The Admission control flow.......................................................................................... 75 Figure 3-12 Detection of Uplink Cell Congestion Due to Uplink Received Total Wideband Power 77 Figure 3-13 TEMS Investigation with high UTRA Carrier RSSI ...................................................... 79 Figure 3-14 The Uplink RBS HW Admission Policy........................................................................ 80 Figure 3-15 The Downlink Transmitted Carrier Power Admission Policy........................................ 82 The Uplink ASE Admission Policy .................................................................................................. 84 Figure 3-17 The Spreading Factor Admission Policy for Non-guaranteed Service Class Radio Links

................................................................................................................................................. 86 Figure 3-18 The Downlink Channelization Code Admission Policy ................................................ 88 Figure 3-19 Load sharing................................................................................................................ 91 Figure 3-20 The load sharing counter flow ..................................................................................... 92 Radio link setup procedures ........................................................................................................... 95 Radio link synchronization procedures ........................................................................................... 95 Figure 3-23 Radio Link setup counter flow, continued from the Random Access flow figure Figure

3-7............................................................................................................................................ 96 Figure 3-24 L1 synchronization problem......................................................................................... 97 Figure 3-25 Radio Link Synchronization failure .............................................................................. 98 Figure 3-26 Radio Link setup failure: AICH problem in TEMS Investigation................................... 99 Figure 3-27 NAS failure: CM service reject in TEMS Investigation............................................... 101 Figure 3-28 Speech, CS 64, Streaming 57.6 RAB establishment ................................................ 102 Figure 3-29 Interactive RAB Establishment .................................................................................. 103 Figure 3-30 PDP Context Activation Failure. Cause: Radio Bearer Setup not sent. .................... 104 Figure 31: PDP Context Activation Failure. Cause: User Authentication Failed........................... 105


- 294 - © Ericsson 2006 LZT 123 8297 R1C

Figure 3-32 UE Cell reselection during handover ......................................................................... 106 Figure 3-33 UE Cell Reselection................................................................................................... 107 Figure 3-34 PDP Context Activation Failure. Cause: Radio Bearer setup then PDP rejected...... 108 Figure 3-35 PDP Context Activation Failure. Cause: PPP Link Control terminated...................... 109 Figure 4-1 A The Retainability workflow ....................................................................................... 116 Figure 4-2 Network Initiated abnormal call releases..................................................................... 118 Figure 4-3 Radio Link Set Supervision States .............................................................................. 119 Figure 4-4 UE TX Power vs. CPICH Ec/No and RSCP ................................................................ 121 Figure 4-5 UL out of synch............................................................................................................ 123 Figure 4-6 UL/DL Imbalance......................................................................................................... 124 Figure 4-7 Entities Involved in Reporting, Evaluation, and Execution of Handover-Related

Functions ............................................................................................................................... 129 Figure 4-8 Soft Handover.............................................................................................................. 130 The counter flow for the cell reselection for Inter-frequency handovers are shown in the............ 130 Figure 4-9 The counter flow for soft/softer handover .................................................................... 131 Figure 4-10 The cell reselection evaluation process..................................................................... 132 Figure 4-11 Cell re-selection was done between SC98 and SC82............................................... 135 Figure 4-12 Cell re-selection......................................................................................................... 136 Figure 4-13 Field tests with settings of the reportingRange parameters ...................................... 137 Figure 4-14 The Measurement reports and ASU complete can vanish in case of a bad

timeToTrigger setting............................................................................................................. 140 Figure 4-15 Inconsistent Lists ....................................................................................................... 141 Figure 4-16 Inconsistent Lists between UE and RNC................................................................... 142 Figure 4-17 Removal of incorrect cell Cause: Inconsistent Lists .................................................. 143 Figure 4-18 Removal of incorrect cell Cause: Inconsistent Lists .................................................. 144 Figure 4-19 Example of different services and their overlapping areas........................................ 146 Figure 4-20 WCDMA Handover (Inter Frequency Handover & Cell Re-selection) ....................... 149 Figure 4-21 WCDMA Handover (Inter RAT Handover)................................................................. 153 Figure 4-22 Loss of ASU complete. Possible Cause: DL/UL Imbalance ...................................... 159 Figure 4-23 Loss of measurement reports.................................................................................... 160 Figure 4-24 RC Handover failure. Possible Cause: Network configuration .................................. 161 Figure 4-25 Inconsistent Lists. Possible Cause: DL/UL Imbalance .............................................. 162 Figure 4-26 TEMS Investigation DL BLER Increases and the call is dropped.............................. 163 Figure 5-1 A The Integrity workflow .............................................................................................. 169 Figure 5-2 WCDMA Power Control ............................................................................................... 172 Figure 5-3 CRC Generator............................................................................................................ 173 Figure 5-4 Uplink Inner Loop Power Control................................................................................. 175 Figure 5-5 Uplink Outer Loop Power Control ................................................................................ 176 Figure 5-6 SIR Target Behaviour According to the Constant Step Regulator algorithm............... 178 Figure 5-7 SIR Target Behaviour According to the Jump Regulator algorithm............................. 179 Figure 5-8 Packet Call showing Session throughput and THold ..................................................... 182 Figure 5-9 PS Application Downlink throughput from TEMS Investigation ................................... 182 Table 9 PS Binned Application-level Throughput Statistics .......................................................... 183 WCDMA Channel Switching ......................................................................................................... 185 The dedicated to common channel switching evaluation.............................................................. 187 Channel Switching in TEMS Investigation .................................................................................... 193 HSDPA will take whatever power that is left in RBS ..................................................................... 196 Figure 5-14 Example of high DL BLER and no radio bearer setup............................................... 200 Figure 5-15 There is no DL signalling after the Radio Bearer Setup Complete............................ 201 Intentionally Blank......................................................................................................................... 206 Figure 6-1. Data Collection – Subscription profiles....................................................................... 210 Figure 6-2. Selecting the UETR profile ......................................................................................... 211


LZT 123 8297 R1C © 2006 Ericsson - 295 -

Figure 6-3. Entering a profile name and comments...................................................................... 211 Figure 6-4. Selecting the involved RNC........................................................................................ 212 Figure 6-5. Selecting the protocols to be measured on ................................................................ 212 Figure 6-6. Step Entering the IMSI number .................................................................................. 213 One TEMS Log file corresponds to several Uplink files................................................................ 215 Figure 6-8. Step 1 to 3 of 5 ........................................................................................................... 216 Figure 6-9. Step 4 of 5 .................................................................................................................. 217 Figure 6-10. WCDMA RAN measurements – OSS_RC workspace menu ................................... 220 Figure 6-11. Select the General performance profiles .................................................................. 221 Figure 6-12. Selecting the GPEH events ...................................................................................... 221 Figure 6-13 GPEH File naming convention .................................................................................. 222 Figure 6-14 GPEH RNC-Internal Event Example ......................................................................... 224 Figure 6-15 GPEH RBS-Internal Event Example.......................................................................... 226 Figure 6-16 WCDMA Recording File Viewer ................................................................................ 227 Figure 6-17 Launching WCDMA Recording file viewer................................................................. 228 Figure 6-18 Recording file viewer graphical user interface........................................................... 229 Figure 6-19 Recording File Viewer Search Criteria ...................................................................... 230 Figure 6-20 File drop down menu options .................................................................................... 231 Figure 6-21 Workflow for analysis of the GPEH log files .............................................................. 233 Figure 6-22 TEMS Visualization User interface with all files loaded............................................. 234

Appendix E: Index

LZT 123 8297 R1C © Ericsson 2006 - 299 -

2nd Generation .........................................155 3rd Generation ..........................................155 Adjunct processor or Application platform ..39 American National Standards Institute........66 American Standard Code for Information

Interchange ...........................................227 Application System ....98, 132, 138, 149, 163,

164 Asynchronous Transfer Mode.............39, 194 Circuit Switching ....37, 38, 56, 57, 60, 62, 68,

102, 117, 128, 152, 155, 180, 181 Common Object Request Broker Architecture

................................................................42 Connection Management......20, 53, 100, 101 Core Network ...17, 60, 61, 62, 100, 102, 103,

118 Customer Product Information e ...47, 48, 222 Element Management.................................47 File Transfer Protocol........................155, 188 Global System for Mobile Communication.25,

62, 66, 73, 90, 91, 92, 94, 146, 150, 152, 153, 154, 155, 156, 225, 232

Graphical User Interface, 42, 46, 47, 228, 229 Hardware .....23, 47, 48, 79, 80, 90, 126, 128,

152, 167, 194 Identification......................100, 102, 103, 230 Integration Reference Points ......................46 Intelligent Network ............................224, 225 International Mobile Subscriber Identity.....61,

62, 100, 207, 213, 214, 215, 230 Internet Protocol................................155, 181 Location Area........58, 60, 61, 62, 63, 67, 155 Location Area Identity .................................62 Main Processor .......53, 63, 73, 220, 222, 223 Media Access Control ...............102, 187, 193 Mobile Country Code ................................213 Mobile Network Code Digits......................213 Mobile Originated......................43, 44, 45, 49 Mobile Services switching Centre .63, 64, 213 Network Operator......................................224 Operation and Maintenance................47, 222 Operation and Support System18, 25, 37, 39,

41, 42, 45, 46, 47, 50, 159, 207, 210, 219, 220, 223, 228, 232, 233

Packet Data Protocol ..53, 104, 105, 108, 109

Packet Switching ... 37, 38, 56, 57, 60, 62, 68, 95, 102, 117, 148, 153, 155, 156, 171, 181, 182, 183, 192, 198, 199

Performance Measurement..... 15, 25, 37, 46, 208

Personal Computer .................................. 214 Point-to-Point Protocol ............... 53, 108, 109 Public Land Mobile Network53, 58, 59, 66, 67 Radio Access Bearer... 24, 25, 56, 57, 76, 81,

87, 89, 90, 92, 94, 95, 96, 101, 102, 103, 105, 125, 128, 147, 149, 155, 167, 170, 171, 177, 180, 183, 184, 185, 186, 190, 191, 192, 193, 198, 199, 200, 225

Radio Access Network .. 9, 11, 13, 14, 18, 21, 23, 24, 37, 43, 51, 57, 62, 63, 66, 90, 94, 107, 111, 113, 123, 129, 135, 153, 165, 184, 185, 186, 203, 207, 219, 220, 221, 235

Radio Access Network Application Protocol...................................... 208, 219, 223, 225

Radio Access Network Operation System.............................................. 194, 207, 210

Radio Network Controller .. 18, 24, 26, 27, 29, 37, 41, 43, 44, 45, 46, 47, 48, 49, 50, 57, 62, 63, 64, 68, 69, 72, 73, 78, 90, 91, 96, 113, 116, 117, 118, 120, 124, 137, 139, 140, 143, 146, 149, 152, 156, 157, 159, 162, 163, 170, 171, 174, 179, 184, 186, 193, 194, 197, 207, 208, 209, 211, 212, 214, 219, 220, 221, 222, 223, 224

Service Capability 22, 98, 106, 136, 143, 163, 164

Short Message Service .............................. 68 Software ........................................... 167, 194 Synchronous Transfer Mode .................... 194 Synchronous Transfer Mode 155 Mbit/s .. 194 Temporary Mobile Subscriber Identity........ 62 Third Generation Partnership Project. 91, 225 Transmission Control Protocol 155, 181, 187,

188, 223 Universal Mobile Telecommunication System

........................................ 73, 154, 155, 232 Unrestricted Digital Information UE ............ 38 UTRAN Registration Area .. 66, 184, 185, 189


- 300 - © Ericsson 2006 LZT 123 8297 R1C

Wideband Code Division Multiple Access....9, 11, 13, 15, 18, 21, 23, 24, 37, 39, 57, 59, 62, 66, 70, 74, 80, 90, 91, 94, 107, 108, 113, 123, 129, 135, 150, 152, 153, 154,

155, 158, 159, 160, 167, 169, 170, 172, 173, 184, 185, 186, 194, 195, 200, 207, 219, 220, 221, 227, 228, 232, 233

3g ran optimization

Technology

r1c ericsson

optimization module

optimization workflow

accessibility module

performance monitoring

performance analysis

table of contents lzt

r1c disclaimer