UMTS RAN Performance Trouble

Shooting and Optimization Guidelines –

Ericsson UMTS Capacity
National & Region Performance Engineering

Document Initiated Mar 03, 2009

Revision Number 1.1
Revision Date June 5, 2009

© Copyright 2009 T-Mobile USA, Inc. All rights reserved.

Confidential and proprietary information of T-Mobile USA, Inc. Not for distribution outside T-Mobile.
 Document Information
The information in these materials is confidential and proprietary to T-Mobile USA, Inc. These materials are authorized for the use of T-Mobile USA
service providers and their employees and agents, solely for the purposes of the agreement under which these materials are provided. The rights
granted hereunder constitute a limited, nonexclusive, revocable license and not a transfer of title. Authorized T-Mobile USA service providers and
their employees and agents may view, copy or print pages of these materials solely for the purposes set forth herein, but may not otherwise use,
modify, copy, print, display, reproduce, distribute, transmit, publish, license, sublicense or create derivative works from these materials in whole or in
part, or remove any copyright or other proprietary notices set forth herein, without the express written permission of T-Mobile USA. The information
in these materials is subject to change without notice. T-Mobile USA's liability for any errors in these materials is limited to the documentary
correction of errors. T-Mobile USA will not be responsible in any event for errors in these materials or for any damages, incidental or consequential
(including monetary losses), that might arise from the use of these materials or the information in them. T-Mobile, the T-Mobile logo and the World
Class logo are registered or unregistered trademarks of Deutsche Telekom AG.

Acknowledgements
The following individuals are responsible for contribution to the specifications, design and implementations
represented in the various revisions:
Declan Quinn (FSC)
Justin Clayden (West)
Dominador Galicinao (West)
Tim Zhang (FSC)

Protection of Information Credibility

This document contains confidential material critical to the business and is therefore a controlled document.
Outdated copies must be destroyed to prevent erroneous use of obsolete information and compromised security
of confidential material. Do not e-mail this file. Do send the link to correspondents so they are assured of seeing
the latest revision. The most recent revision of this file is always in softcopy and can be accessed at the following
link.
http://docs.eng.t-mobile.com/InfoRouter/docs/~DXXXXXX
Note to revisers: For the above link to remain valid, you must use proper check out / check in procedures when
you update this document.

Revision Code
The revision number will reflect the modifications by following the format Rev. x, y, where
X is the first digit, incremented for changes of substance, i.e. technical/procedural issues.
Y is the second digit, incremented when editorial only changes have been incorporated.
All draft/preliminary versions are 0.n; the first final version is Revision 1.0.

Revision History
Rev. Date Author Information
1.0 5/22/2009 Declan Quinn/Justin Initial Draft
Clayden (WR)
1.1 6/5/2009 Declan Quinn 1. Minor typo corrections
2. Addition of Scope section
3. Addition of 384/128 RAB Reduction for expanding
capacity
 Table of Contents
1. Introduction............................................................................................................................4
1.1. Purpose & Scope 4
1.2. Definitions for this Document 4
2. Capacity..................................................................................................................................7
2.1. T-PIM Reports 7
2.2. Scope 7
2.2.1. In Scope 7
2.2.2. Out of Scope 7
2.3. Troubleshooting Flowchart 8
3. Radio/Air Interface Capacity.......................................................................................................9
3.1.1. RNC/Market/Region Level Reporting and Overview 13
3.1.1.1. Admission Control Issues 13
3.1.1.2. DL Power/DL Channelization Codes Issues 13
3.1.1.3. Soft Handover Overhead (SHO) 14
3.1.1.4. Cell Congestion 14
3.1.1.5. Received Total Wideband Power (RTWP) 15
3.1.2. Cell/RBS Analysis 16
3.1.2.1. Failures due to Admission Control 16
1.3.1.2.1. Voice Admission Control Failures 16
1.3.1.2.2. HSDPA Interactive Admission Control Failures 17
1.3.1.2.3. PS Interactive Admission Control Failures 17
3.1.2.2. Failures due to Lack of DL Power/DL Channelization Codes 17
3.1.2.3. High Soft/Softer Handover Overhead 18
3.1.2.4. Cell Congestion 18
3.1.2.5. High RTWP 19
4. RBS/Baseband Capacity...........................................................................................................21
4.1.1. RNC/Market/Region Level Reporting and Overview 25
4.1.1.1. RAB failures due a Lack of hardware resources 25
4.1.1.2. RRC denied - Insufficient Licensed Capacity 25
4.1.1.3. RRC denied – Node Blocking 25
4.1.2. RBS Analysis 25
4.1.2.1. Lack of hardware resources /Insufficient Licensed Capacity 25
4.1.2.2. RRC denied – Node Blocking 25
5. Transport/Backhaul Capacity....................................................................................................26
5.1.1. RNC/Market/Region Level Reporting and Overview 35
5.1.2. Iub/Transport Link Analysis 35
5.1.2.1. RRC and RAB TN Congestion/Blocking (All Service Types) 35
5.1.2.2. Iub Congestion (UL and DL) 35
5.1.2.3. AAL2 QoS A – D Setup Failures 36
5.1.2.4. ATM Lost Cells (Transmitted and Received) 36
6. RNC Capacity.........................................................................................................................37
7. Capacity Management Tool......................................................................................................40
8. Troubleshooting Tools.............................................................................................................41
9. References.................................................................................................................................42
1. Introduction
1.1. Purpose & Scope
The intent of this document is to provide UMTS Trouble Shooting and Optimization from KPI and
Counter perspectives for Ericsson (E///) Capacity and provide detailed analysis strategies for
identifying reason for the KPI trends and offering guidelines for improving performance.
The KPI/Counters described here are applicable to the P6 release of the Ericsson UTRAN.
This document is not all inclusive and is only intended to provide a quick cook book to understand
available E/// for trouble shooting and optimization best practices Guideline Document. For any
information not covered here, the Ericsson product documentation (CPI/ALEX Libraries) should be
referenced.

1.2. Definitions for this Document

Term or Acronym Definition

3GPP Third Generation Partnership Project

AS Active Set

BH Busy Hour

BSIC Base Station Identity Code

BTS Base Transceiver Station

CN Core Network

CPICH Common Pilot Channel

DCH Dedicated Channel

DL Downlink

DPCCH Dedicated Physical Control Channel

DPCH Dedicated Physical Channel

DRNC Drift Radio Network Controller

FCP Flexible Capacity Upgrade Program

FACH Forward Access Channel

FIFO First In First Out

 Term or Acronym Definition

GERAN GSM EDGE RAN

GSM Global System for Mobile Communications

HCS Hierarchical Cell Structure

HSDPA High Speed Data Packet Access

IAF Intra Frequency

IE Information Element

IEF Inter Frequency

IFHO Inter Frequency Handover

Inter-RAT Inter Radio Access Technology

IRAT Inter Radio Access Technology

Iur Interface between two RNC’s

KPI Key Performance Indicator

LA Location Area

LAI Location Area Indicator

NBAP Node B Application Part

Logical node responsible for radio transmission
Node B and reception in one or several cells

OCNS Orthogonal Channel Noise Simulator

PLMN Public Land Mobile Network

RA Routing Area

RAB Radio Access Bearer

RAI Routing Area Indicator

RAN Radio Access Network

RAT Radio Access Technology

RB Radio Bearer
RBS Radio Base Station – another name for the
 Term or Acronym Definition
Node B

RF Radio Frequency

RL Radio Link

RNC Radio Network Controller

RRC Radio Resource Control

RSCP Received Signal Code Power

RSSI Received Signal Strength Indicator

SIB System Information Block

SIR Signal to Interference Ratio

TRX Transceiver

TX Transmit

UE User Equipment

UL Uplink

UMTS Universal Mobile Telecommunication Services

UTRAN UMTS Terrestrial Radio Access Network

WCDMA Wideband Code Division Multiple Access

2. Capacity
Capacity Management aims to control the load in the WCDMA RAN. The purpose of Capacity
Management is to maximize the capacity in WCDMA RAN while maintaining the requested Quality of
Services (QoS) and coverage. The metrics within the Ericsson RNC and OSS provide counters and KPI’s
that describe the behaviors and experience of the subscribers on the UMTS network and the capacity
usage of the network elements.
Capacity can be divided up into a number of primary areas. The main items which affect capacity on the
UMTS network include:
 Radio/Air Interface Capacity
 RBS/Baseband Capacity
 Transmission/Backhaul Capacity
 RNC Capacity
Capacity issues can also be caused by Radio Optimisation issues such as overshooting etc.

2.1. T-PIM Reports

The primary T-PIM Reports used for the Capacity metrics are:
 Accessibility (Admission Control/Code and Power Rejections)
 Capacity I
 Capacity II
 Code I
 Code II
 Congestion
 Quality (RTWP)
 HSDPA Node B Report (Iub Congestion)
 Transport RNC Report
These reports are explained in detail in the T-PIM Report Documentation.

2.2. Scope
2.2.1. In Scope
The scope of this document includes methods to improve capacity by optimization of the existing
resources.

2.2.2. Out of Scope

This document does not include details of the FCP (Flexible Capacity Program) provided by Ericsson to
ensure baseband capacity is sufficient to meet T-Mobile’s current and future baseband capacity needs.
2.3. Troubleshooting Flowchart
The following flowchart may be useful for troubleshooting the capacity issues based on the problem
areas

Capacity Issues Capacity Issue Breakdown/

Worst Cells Analysis
Accessibility/Capacity/Code/
Quality/Congestion/Node B
Reports

Capacity Issues
Radio/Air RBS/ Transmission
RNC
Interface Baseband /Backhaul
Capacity
Capacity
Capacity Capacity

Failures due to RAB failures

Admission RRC and RAB
due a Lack of Rejects due to
Control TN Congestion/
hardware MP Load
Blocking
resources

Failures due to
Lack of DL RRC denied -
Power/DL Insufficient MP Load
Channelization Iub Congestion
Licensed Trending
Codes Capacity

High Soft AAL2 QoS

RRC denied –
Handover Setup Failures
Node Blocking
Overhead

ATM Lost Cells

Cell Congestion (TX and RX)
Time

High RTWP

Flow chart in PowerPoint

Ericsson Capacity
Flowchart.pptx
3. Radio/Air Interface Capacity
The main metrics for the Radio and Air Interface Capacity are contained in the following reports in T-
PIM:
 Accessibility
 Quality
 Congestion
The main report for identifying and troubleshooting Radio and Air Interface capacity issues in T-PIM is
the Accessibility Report. This contains the Admission Control and Lack of Downlink Power/
Channelization Codes Access Failure counters.
Most of these KPI’s are made up of single counters taken from the RNC or RBS. The list of Radio/Air
Interface KPI’s are shown below:

Report KPI Counters/Formula

Accessibility PS Interactive RAB Failures due to pmNoOfNonHoReqDeniedInteract
Admission Control
Accessibility Voice RAB Failures due to Admission pmNoOfNonHoReqDeniedSpeech
Control
Accessibility HSDPA Interactive RAB Failures due to pmNoOfNonHoReqDeniedHs
Admission Control
Accessibility PS RAB failures - Exceeded connection pmNoFailedREstAttExcConnLimit
limit
Accessibility PS RAB failures - Exceeded connection pmNoFailedREstAttExcConnLimit
limit
Accessibility RAB failures - Lack of DL power pmNoFailedREstAttLackDlPwr
Accessibility RAB failures - Lack of DL pmNoFailedREAttLackDlChnlCode
Channelization code
Accessibility RAB failures - Lack of DL ASE pmNoFailedRabEstAttLackDlAse
Accessibility RAB failures - Lack of UL ASE pmNoFailedREstAttLackUlAse
Accessibility CS RRC rejects due to Admission pmNoRrcCsReqDeniedAdm
control
Accessibility PS RRC rejects due to Admission pmNoRrcPsReqDeniedAdm
control
Capacity I Soft/Softer Handover Overhead (pmSumUesWith1Rls1RlInActSet
+(2*(pmSumUesWith1Rls2RlInActSet +
pmSumUesWith2Rls2RlInActSet))
+(3*(pmsumueswith1rls3rlinactset +
pmSumUesWith2Rls3RlInActSet +
pmSumUesWith3Rls3RlInActSet))
+(4*(pmsumueswith2rls4rlinactset +
pmSumUesWith3Rls4RlInActSet +
pmSumUesWith4Rls4RlInActSet)))/(pmSumUes
With1Rls1RlInActSet +
pmSumUesWith1Rls2RlInActSet +
pmSumUesWith2Rls2RlInActSet +
pmsumueswith1rls3rlinactset +
 pmSumUesWith2Rls3RlInActSet +
pmSumUesWith3Rls3RlInActSet +
pmsumueswith2rls4rlinactset +
pmSumUesWith3Rls4RlInActSet +
pmSumUesWith4Rls4RlInActSet)
Capacity II Carrier Tx Power (dBm) (Summation of i from 1 to 51 of ( [i] *
pmTransmittedCarrierPower_[i])) / Summation
of i from 0 to 51 of
(pmTransmittedCarrierPower_[i])
Capacity II HS-PDSCH Power Shortage pmRemainingResourceCheck_2
Code I DL Channelization code tree usage pmSumDlCode/pmSamplesDlCode
Code I HS-SCCH Code Shortage pmRemainingResourceCheck_0
Code I HS-PDSCH Code Shortage pmRemainingResourceCheck_1
Congestion Cell Congestion DL + UL (sec) pmTotalTimeDlCellCong +
pmTotalTimeUlCellCong
Congestion Congestion control triggered--High DL pmSumOfTimesMeasOlDl
Power
Congestion Speech radio connections terminated-- pmNoOfTermSpeechCong
Congestion
Congestion Congestion control triggered--High UL pmSumOfTimesMeasOlUl
interference
Congestion Speech radio terminated over IuR-- pmNoOfIurTermSpeechCong
Congestion
Congestion Total time the cell was congested in DL pmTotalTimeDlCellCong
Congestion Total time the cell was congested in UL pmTotalTimeUlCellCong
Congestion HS downswitches due to congestion pmNoOfSwDownHsCong
Congestion EUL downswitches due to congestion pmNoOfSwDownEulCong
Congestion Total time HSDSCH is Overloaded (sec) RESpmTotalTimeHsdschOverload
Channel Switching Downswitches Non-Guaranteed Users pmNoOfSwDownNgHo
due to SHO
Channel Switching Downswitches due to Congestion pmNoOfSwDownNgCong
Channel Switching Downswitches due to Admission pmNoOfSwDownNgAdm
Quality UL RTWP Level (dBm) -112 + 0.1*(pmSumUlRssi / pmSamplesUlRssi)

Individual counter description for those counters not found below can be found in the ALEX
Libraries.

Counter Description Condition MO Class

pmNoOfNonHoReqDeniedInteractive Number of Interactive Incremented by one UtranCell
RAB establishments when admission is
rejected by admission rejected.
control Note: The counter is not
incremented when
admission is rejected in a
DRNC cell
pmNoOfNonHoReqDeniedSpeech Number of Speech RAB Incremented by one UtranCell
establishments when admission is
rejected by admission rejected.
Counter Description Condition MO Class
control
pmNoOfNonHoReqDeniedHs Number of Interactive Incremented by one UtranCell
RAB establishments on when admission is
a (High Speed) HS rejected
configuration rejected by
admission control
pmNoFailedRabEstAttemptLackDlPwr Number of failed RAB Counter is stepped when UtranCell
establishment attempts admission control fails
due to lack of DL power with reject reason
lack of DL power
pmNoFailedRabEstAttemptLackDlChnlCo Number of failed RAB Counter is stepped when UtranCell
de establishment attempts admission control fails
due to lack of DL with reject reason
channelization codes lack of DL channelization
codes
pmSumUesWith1Rls1RlInActSet* A snapshot of the total It is based on an internal UtranCell
number of UEs with one level counter which is
(Repeated for various combinations of RL RL set and one RL in maintained by RNC.
Set and RL’s) the active set is recorded Values are read
once every minute periodically, every
This counter contains the minute, from the
sum of all the snapshot internal level
values taken in a counter. Each read
ROP period added results in the pmSamples
together counter being increased
by one, and the actual
value read from the level
counter being added
to the pmSum counter.
The level counter
maintains a snapshot of
the
number UEs with one RL
set and one RLs in the
active set at any given
instant in time, that is
the counter can be
decreased or increased.
The
level counter is updated
by RRC Connection
Setup, RRC Connection
Release, Inter-RAT
Handover GSM to
UTRAN, Inter-RAT
Handover
UTRAN to GSM, RAB
Establishment, RAB
Release, Inter-frequency
Handover, Channel
Counter
pmSamplesUesWith1Rls1RlInActSet
pmTotalTimeDlCellCong
pmTotalTimeUlCellCong
pmSumUlRssi
pmSamplesUlRssi
Description Condition MO Class
Switching, Soft
Handover, and Softer
Handover
Number of samples This counter is increased UtranCell
recorded within the ROP at every occasion when
period for number of the corresponding
UEs with one RL set and sum counter is stepped
one RL in the active set,
sampled once every
minute
The total amount of time The counter is increased UtranCell
(seconds) a cell was by 1 every second the
congested in DL during cell is in congestion.
a reporting period The counter will be
incremented in the
CRNC
The total amount of time The counter is increased UtranCell
(sec) a cell was by 1 every second the
congested in UL during cell is in congestion.
a reporting period The counter will be
incremented in the
CRNC
Sum of valid RTWP At reception of an NBAP UtranCell
values as received in Common Measurement
NBAP Common Report message
Measurement Reports. containing a valid RTWP
RTWP range: 0-621 value the RTWP value is
(corresponding to -112 ... added to this
-50dB). Received Total counter. RTWP range: 0-
Wideband Power (RTWP) 621 (corresponding to
is a measurement -112 ... -50dB).
of uplink RSSI and is
defined in 3GPP TS
25.433 (NBAP)
Number of received Counter is stepped on UtranCell
NBAP Common reception of an NBAP
Measurement Report Common Measurement
messages Report message
containing valid RTWP containing a valid RTWP
value. Received Total value.
Wideband Power
(RTWP) is a
measurement of uplink
RSSI and is defined in
3GPP
TS 25.433 (NBAP).
 3.1.1. RNC/Market/Region Level Reporting and Overview
The metrics described in the previous pages can be used as an indication of issues that should be
investigated further on a Cell/RBS basis. Radio and Air Interface congestion should be investigated at
this level, RNC level congestion will be investigated in other counters.

Admission Control Issues

These metrics can be used to determine the breakdown of admission control issues on an RNC, Market
or Region level and can be shown as follows.
Admission Control Per RAB Type
12000

10000

8000

6000

4000

2000

0
05.01.2009 05.02.2009 05.03.2009 05.04.2009 05.05.2009 05.06.2009 05.07.2009 05.08.2009 05.09.2009 05.10.2009

Sum of PS Interactive RAB Failures due to Admission Control Sum of Voice RAB Failures due to Admission Control Sum of HSDPA Interactive RAB Failures due to Admission Control

The Admission Control failure reasons can be broken down by bearer type. Individual troubleshooting
for these issues should be carried out on an individual cell level.

DL Power/DL Channelization Codes Issues

Another issue that will occur on the cell level but that can be monitored at a higher aggregated level.
The lack of DL Power and DL Channelization codes should also be investigated on a Cell level.
Lack of DL Power and DL Channelization Codes
4000

3500

3000

2500

2000

1500

1000

500

0
05.01.2009 05.02.2009 05.03.2009 05.04.2009 05.05.2009 05.06.2009 05.07.2009 05.08.2009 05.09.2009 05.10.2009

Sum of RAB failures - Lack of DL power Sum of RAB failures - Lack of DL Channelization code
Soft Handover Overhead (SHO)
One metric which can be used for capacity is the SHO metric. This shows when a UE has one or more
Radio Links (RL).
Soft Handover Ratio
1.8 44.5

1.6
44

1.4

43.5
1.2

43
1

0.8
42.5

0.6
42

0.4

41.5
0.2

0 41
05.02.2009 05.03.2009 05.04.2009 05.05.2009 05.06.2009 05.07.2009 05.08.2009 05.09.2009 05.10.2009 05.11.2009

Sum of Soft/Softer Handover Overhead Sum of Percentage of UEs in Soft/softer HO

The % of UE’s in SHO can also be used to determine the possible capacity requirement. The limitation is
a trade-off between the capacity used by a single UE compared to the risk of dropping the call by losing
the Radio Link if there is only one in the Active Set.

Cell Congestion
This metric gives an indication of when the cell is in congestion in either the UL or the DL. This may be an
indication of High UL RTWP (UL Congestion), High TX Power [Non-HS Capable Cell] (DL Congestion), Non
HS Dl DCH Power Overload (Dl Congestion) or HS Overload (DL Congestion).
These can be found in the Common Measurement reports. A number of actions may be taken
automatically by the RNC to reduce congestion including the rate downswitch of Non-Guaranteed
services, release of calls occurring over the Iur and release of calls served on the RNC.
Cell Congestion - Aggregated
2500

2000

1500

1000

500

0
05.03.2009 05.04.2009 05.05.2009 05.06.2009 05.07.2009 05.08.2009 05.09.2009 05.10.2009 05.11.2009 05.12.2009

Sum of Cell Congestion DL + UL (sec) Sum of Total time the cell was congested in DL Sum of Total time the cell was congested in UL
 On an RNC level, the Cell Congestion counter will be rolled up to provide an overall figure for the RNC’s
Cell’s Congestion. Much like the other metrics, this is useful for reporting at a high level, but cell level
analysis is required for troubleshooting.

Received Total Wideband Power (RTWP)

This metric is related to the congestion metric in . A rise in the RSSI/RTWP can be caused by a large
number of UE’s in the cell, localized UL Noise rise or an external interferer. RTWP is a combination of
 Power received from all the UEs in the RBS’s vicinity
 Any internal and/or external interference
 Thermal noise
 System Noise Figure (Including BTS and Antenna system)

Typically, the RTWP should be in the general range of -100 - -110 dBm.

UL RTWP - RNC Average

05.03.2009 05.04.2009 05.05.2009 05.06.2009 05.07.2009 05.08.2009 05.09.2009 05.10.2009 05.11.2009 05.12.2009
-106.153

-106.3662

Total

-106.5793

-106.7925
 3.1.2. Cell/RBS Analysis
All of the metrics shown above should be used on a Cell level to accurately identify the worst offending
cells. The Worst Offenders in an RNC/Market/Region level should be ranked by the following metrics:
 Number of Failures due to Admission Control
 Number of Failures due to Lack of DL Power/DL Channelization Codes
 High Soft Handover Overhead
 Amount of time a cell is congested (UL, DL or Combined)
 Cells with High RTWP (Hot Cells i.e. > -100 dBm)

Failures due to Admission Control

As part of the set of counters provided to give more information on the access failures, the failures due
to admission control can occur for any of the RAB types. If these counters are pegging, it is likely to be
either the cell attempting to exceed the number of users specified by parameter or due to a lack of
power to service the requests. The causes can include:
 Power
 Code utilization limits
 ASE limit
 Compressed mode limit

Voice Admission Control Failures

Voice Admission control failures can be caused by a number of issues. These however do not include:
 RL and NNI-SAAL Congestion
 Load Sharing
 Presence of Non Guaranteed traffic in the cell (This should be down-switched to allow the voice
call)
The following steps are a suggestion for troubleshooting:
1. Investigate if the failures due to lack of DL Power or DL Channelization Codes are also pegging
a. If the counters are pegging for these issues, continue to
b. If not, there may be an issue with UL (RAX Board) or DL (TX Board) Hardware resource
availability (Lack of Channel Elements). Check in the Node B Report to determine the CE
utilization % for the UL and DL. If usage is high, raise a TT to the Regional Capacity team.
2. If there are a large number of IRAT attempts on the cell, the Compressed Mode usage and use of
DL Spreading factors may be high. This should be investigated in the Mobility Report.
a. If the number of Compressed Mode users is high and the use of DL Channelization
Codes requested for Compressed mode is high, the IRAT Boundary may need to be
investigated
 b. Analysis for a new UMTS Site (Or upgrade of an existing GSM Site) may be required for
capacity purposes. A TT should be raised to the Regional RF Planning group for analysis
3. If the issues are not related to any if the above, admission control failures for the other service
types must also be investigated

HSDPA Interactive Admission Control Failures

HSDPA Admission control failures can be caused by similar issues to the Voice examples. These however
include
 The number of allowed users to establish a new HS session on the Utran Cell
The following steps are a suggestion for troubleshooting:
1. The hsdpaUsersAdm parameter on a UtranCell level must be verified against the FSC Baseline
parameter set (Note: The related rbsLocalCell parameter maxNumHsdpaUsers must be set to
the correct equivalent value)
a. 20 for a 1 T1 Site (maxNumHsdpaUsers = 26)
b. 25 for > 1 T1 Site (maxNumHsdpaUsers = 32)
2. HSDPA Access failures may also occur due to the failure to receive an A-DCH in the UL. This may
be due to Resource allocation on the RAX board. Check in the Node B Report to determine the
CE utilization % for the UL and DL. If usage is high, raise a TT to the Regional Capacity team
3. If the issues are not related to any if the above, admission control failures for the other service
types must also be investigated

PS Interactive Admission Control Failures

PS Interactive Admission control failures can be influenced by the HSDPA Admission control failures.
The following steps are a suggestion for troubleshooting:
1. Investigate if the issues are occurring on the HSDPA Admission Control failures. If they are,
follow the troubleshooting steps in
After these any changes are performed, monitoring should continue on a cluster of cells around the
affected cell to determine the performance improvement on both the affected cell and the surrounding
area.

Failures due to Lack of DL Power/DL Channelization Codes

If a large number of the Access Failures are due to either of these issues,
The following steps are a suggestion for troubleshooting:
1. If the Failures due to a lack of DL Channelization Codes are high (Failures due to Lack of DL
Power may also be apparent), the HSDPA Admission Control Failures must also be checked for
the cell. If users are not accessing the HS Bearer, they will be forced to use a PS Interactive R99
DCH. This will use more DL Power and Channelization codes than the shared HS Channel.
a. The number of HS Users admission control settings must be verified against the FSC
Baseline as per
 2. If the Failures due to a lack of DL Channelization Codes and lack of DL Power are both high,
another possible solution is a reduction in the number of 384 and 128 kbps RAB’s allowed on the
cell in both the UL and the DL.
a. This is reduced by reducing the sf4UlAdm (384 UL RAB), sf8UlAdm (128 UL RAB), sf8Adm
(384 DL RAB) or sf16Adm (128 DL RAB).
b. This should not be done without consultation of the regional SME’s
3. If the DL Power failures are high but there is no issue with HSDPA Admission Control or DL
channelization Codes, the CPICH settings should checked and Feeder Loss verified on the cell
concerned. The following must be checked:
a. Ensure that the feeder loss entered in the RBS correctly reflects the Feeders on site
b. If the CPICH is set @ 35.1 dBm, discuss with the regional team the possibility of
decreasing the CPICH. This must not be set more than 3dB less than surrounding CPICH’s
as this may cause ‘interfering’ neighbours
c. If the CPICH is lower than 35.1 dBm, there still may be scope to reduce the CPICH
further to enhance capacity on the site
d. If CPICH is reduced, uptilts may be required to ensure the coverage area of the cell
remains the same. RF analysis and drive tests may be required for these changes
After these any changes are performed, monitoring should continue on a cluster of cells around the
affected cell to determine the performance improvement on both the affected cell and the surrounding
area.

High Soft/Softer Handover Overhead

High Soft Handover Overhead can be an indication of the overuse of radio resources (Too many Radio
links used where not required) however it should be noted that by reducing this number too much
creates a risk of further dropped calls. The SHO value for an individual cell can be compared to that of
the RNC/Market to determine if it is an outlier from the normal values in the area. A good SHO value is
between 1.3 and 1.5. Some methods of reducing SHO for a cell are:
1. Increasing dominance of a cell in an area by modifying tilts and drive testing
2. For problem areas, antenna configurations (azimuth and beam width changes) may be made to
reduce the SHO further
After these steps are performed, monitoring should continue on a cluster of cells around the affected
cell to determine the performance improvement.

Cell Congestion
Cell congestion in the UL and DL can be counted for a number of issues. For UL Time in Congestion, the
primary cause is High RTWP. This will be dealt with in Section .
For DL Time in Congestion, the main causes are:
 High TX Power [Non-HS Capable Cell]
 Non HS Dl DCH Power Overload
 HS Overload
 The following steps are a suggestion for troubleshooting:
1. Investigation of the Failures due to lack of DL Power (similar to )
a. Discussion with Regional team over a possible reduction in CPICH to reduce the overall
Power Per RL in the cell
2. Investigation into the transport counters to determine if there is congestion or resource
availability issues on the Iub. This may cause users to retain their RSBs for longer periods than
necessary
3. Investigation into the number of users/HS RAB’s in the cell to determine if the traffic is high
a. Work with the Regional Capacity team to determine if a new site will be required or if a
case for a 2nd carrier can be used for additional capacity
After these steps are performed, monitoring should continue on a cluster of cells around the affected
cell to determine the performance improvement.

High RTWP
RTWP gives total amount of UL power received by the Node B in the carrier (5 MHz) frequency. This
includes the following:
 Power received from all the UEs in the Node-B’s vicinity
 Any internal and/or external interference
 Thermal noise
 System Noise Figure (Including BTS and Antenna system)
High RTWP can cause a number of issues such as:
 A Reduction in Node-B Sensitivity
 An Imbalance between downlink and uplink
 A Reduction in the UL capacity
 A Reduction in a UE’s battery life
 UE may need to transmit more power which would consume more battery
The following steps are a suggestion for troubleshooting:
1. Audit and correct the Incorrect ulAttenuation parameter
a. Note that RBS 3518 / 3418 with remote RRUs, typically, do not have a main feeder and
hence ulAttenuation parameter should be calculated based on Jumper cable length only
b. But if a 3518 /3418 has RRUs installed close to the Baseband unit, it might have main
feeder cable. Accurate feeder length needs to be identified to calculate ulAttenuation
and electricalulDelay parameters
2. If there is an External TMA (Non Ericsson ASC), the ExternalTMA Mo must be correctly
configured
a. The ulGain parameter must also be set correctly for these sectors
b. Sites without TMA must have the MO ExternalTma deleted
 c. Incorrect settings for internalPower can also affect the TMA functions – If it is set to NO,
the TMA may be powered off
3. Audit the CIQ Database and rectify any incorrect configuration issues
a. Incorrect electricalulDelay and ulTrafficDelay parameter can have an indirect impact on
RTWP. Incorrect delay could reduce the Macro diversity gain which might make UE’s to
transmit more power
After these steps are performed, monitoring should continue on a cluster of cells around the affected
cell to determine the performance improvement.
4. RBS/Baseband Capacity
Other than the Radio and Air Interface Capacity metrics, a number of RBS Baseband elements can cause
capacity issues. Counter and metrics to indicate these issues are contained in the following reports in T-
PIM:
 Accessibility
 Node B
 HSDPA Node B
The main report for identifying Baseband capacity issues where they relate to Radio in T-PIM is the
Accessibility Report. This contains the RAB Failure counters due to a lack of Ul or DL hardware,
insufficient licensed capacity or Node Blocking.
The Node B Report also displays the usage % of the RAX and TX Board Channel elements. This is an
average usage over the period the report is run.
Most of these KPI’s are made us of single counters taken from the RNC or RBS. The list of main RBS
Baseband KPI’s are shown below:

Report KPI Counters/Formula

Accessibility RAB failures - Lack of DL hardware pmNoFailedRabEstAttLakDlHwBest
resources
Accessibility RAB failures - Lack of UL hardware pmNoFailedRabEstAttLakUlHwBest
resources
Accessibility CS RRC denied - Insufficient Licensed pmNoFailedRrcConnectReqCsHw
Capacity
Accessibility PS RRC denied - Insufficient Licensed pmNoFailedRrcConnectReqPsHw
Capacity
Accessibility CS RRC Fails - NodeB Blocking pmNoRrcConnReqBlockNodeCs
Accessibility PS RRC Fails - NodeB Blocking pmNoRrcConnReqBlockNodePs
Accessibility HS Int RAB Block - Node pmNoRabEstBlockNodePsIntHsBest
Congestion/Failure (Best Cell)
Accessibility Speech RAB Block - Node pmNoRabEstBlockNodeSpeechBest
Congestion/Failure (Best Cell)
Accessibility R99 Int RAB Block - Node pmNoRabEstBlkNodePsIntNoHsBest
Congestion/Failure (Best Cell)
Node B UL Channel Element Utlization pmSumUlCredits/pmSamplesUlCredits
Node B DL Channel Element Utlization pmSumDlCredits/pmSamplesDlCredits
HSDPA Node B Total Seconds Code Shortage triggered pmRbsHsPdschCodePrio
-- (Priority resolve)
Individual counter description for those not found below can be found in the ALEX Libraries.
Counter Description
pmNoFailedRabEstAttLakDlHwBest Number of failed RAB
establishment attempts
due to lack of DL
hardware resources, for
the best cell in the active
set
pmNoFailedRabEstAttLakUlHwBest Number of failed RAB
establishment attempts
due to lack of UL
hardware resources, for
the best cell in the active
set.
pmNoFailedRrcConnectReqCsHw Number of CS calls
denied by admission
control due to
insufficient
licensed capacity in the
RBS
pmNoFailedRrcConnectReqPsHw Number of PS calls
denied by admission
control due to
insufficient
licensed capacity in the
RBS
pmNoRrcConnReqBlockNodeCs Number of RRC
Connection Setup
attempts for Circuit
Switched calls
that fail due to node
blocking
pmNoRrcConnReqBlockNodePs Number of RRC
Condition MO Class
The counter is stepped UtranCell
for the IubLink
containing the best cell
in the
active set
The counter is stepped UtranCell
for the IubLink
containing the best cell
in the
active set
Incremented by one Utran Cell
when an RRC connection
request with cause
Originating
Conversational Call,
Terminating
Conversational call, or
emergency call is denied
by admission control due
to insufficient
licensed capacity in the
RBS.
Incremented by one Utran Cell
when an RRC connection
request with cause
Originating
Conversational Call,
Terminating
Conversational call, or
emergency call is denied
by admission control
This counter is stepped if UtranCell
the establishment of an
RRC Connection
Request - with
Establishment Cause
equal to
Originating/Terminating
Conversational or
Emergency - fails due to
node configuration
error,
node limitations or
transport network layer
service unavailability
This counter is stepped if UtranCell
Counter
pmNoRabEstBlkNodePsIntNoHsBest
pmNoRabEstBlockTnPsIntNonHs
pmNoRabEstBlkNodePsIntNoHsBest
pmSumUlCredits
Description Condition MO Class
Connection Setup the establishment of an
attempts for Packet RRC Connection
Switched calls Request - with
that fail due to node Establishment Cause
blocking. equal to
Originating/Terminating
Interactive, or
Background or
Originating Subscribed
Traffic Call - fails
due to node
configuration error,
node limitations or
transport network
layer service
unavailability.
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type PS of a PS Interactive RAB,
Interactive that are excluding PS Interactive
blocked due to node for HS, RAB fails due to
congestion or node node configuration
failure, counted on the error, node limitation or
best cell. transport network layer
service unavailability
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type PS of a PS Interactive RAB,
Interactive that are not including PS
blocked due to TN Interactive for HS, fails
congestion or TN failure, due to congestion on the
counted on the blocking user plane (AAL2) or
cell control plane (UniSaal or
SCTP) of the transport
network layer as a result
of user dimensioned
transport network
capacity
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type PS of a PS Interactive RAB,
Interactive that are excluding PS Interactive
blocked due to node for HS, RAB fails due to
congestion or node node configuration
failure, counted on the error, node limitation or
best cell transport network layer
service unavailability
Aggregate of total N/A IubLink
consumed RBS UL credit
measurements (in
Counter Description Condition MO Class
credits).
pmSamplesUlCredits Number of samples in N/A IubLink
pmSumUlCredits (that is,
pmSamplesUlCredits
= pmSamplesUlCredits
+1, whenever
pmSumUlCredits is to be
updated). Reset at each
ROP period.
pmSumDlCredits Aggregate of total N/A IubLink
consumed RBS DL credit
measurements (in
credits).
pmSamplesDlCredits Number of samples in N/A IubLink
pmSumDlCredits (that is,
pmSamplesDlCredits
= pmSamplesDlCredits
+1, whenever
pmSumDlCredits is to be
updated). Reset at each
ROP period
pmRbsHsPdschCodePrio The number of times Dynamic code allocation IubDataStrea
there is an HS-PDSCH runs every second. Each ms
HW shortage. The time priority resolve is
number of codes that entered in the algorithm
can be for
used on a processing unit dynamic code allocation
is limited. If this limit increases the count by 1.
is exceeded, owing to the Attribute
configuration or to a dynamicHsPdschCodeAll
high level of Dedicated ocation in MO
Channel (DCH) traffic in RbsLocalCell needs to be
the cells, then priority set to TRUE, otherwise
resolve is entered in the the counter will not be
algorithm for dynamic pegged
code allocation, and the
counter is pegged. This is
checked every second
and if the code shortage
situation remains, then
the counter is pegged
every second. Priority
resolve can be entered in
cells where there is
no traffic at all, since the
dynamically allocated
codes are redistributed
among the cells even if
there is no traffic in some
of the cells.
 4.1.1. RNC/Market/Region Level Reporting and Overview
The metrics described in the previous pages can be used as an indication of issues that should be
investigated further on a RBS basis. RBS congestion should be investigated at an RBS level.

RAB failures due a Lack of hardware resources

These counters indicate the failure of RAB access attempts due to the lack of UL (RAX) or DL (TX Board)
hardware – Channel Element Shortage. If these issues are seen on an RBS, a TT should be raised to the
Regional Capacity team. These resources are governed by the FCP.
Notes:
** Currently these counters are not working in P6.0.0
** For this counter to peg, the ulHwAdm and dlHwAdm parameters must be set <100%

RRC denied - Insufficient Licensed Capacity

These counters indicate the failure of RRC access attempts due to the lack of licensed capacity on RBS. If
these issues are seen on an RBS, a TT should be raised to the Regional Capacity team. These resources
are governed by the FCP.

RRC denied – Node Blocking

These counters indicate the failure of RRC access attempts due to a number of possible issues on the
RBS including:
 Node configuration error
 Node limitations
 Transport network layer service unavailability

4.1.2. RBS Analysis

All of the metrics shown above should be used on an RBS level to accurately identify the worst offending
nodes. The Worst Offenders in an RNC/Market/Region level should be ranked by the metrics detailed in
the high level reporting above.

Lack of hardware resources /Insufficient Licensed Capacity

For the failures due to Lack of Hardware or Insufficient Licensed capacity, a TT should be raised to the
Region Capacity team as this is a function of FCP.

RRC denied – Node Blocking

For the failures due to Node Blocking, all RBS parameters should be verified to ensure there are no
configuration issues. If these are found to be at the FSC baseline, a TT should be raised to the Region
Capacity.
5. Transport/Backhaul Capacity
The main metrics for the Transport and Backhaul Capacity are contained in the following reports in T-
PIM:
 Accessibility
 HSDPA Node B
 Transport RNC
The main report for identifying and troubleshooting Radio related Transport capacity issues in T-PIM is
the Accessibility Report. RRC and RAB failures due to Transport Blocking. Other reports show the Iub,
NBAP and AAL2 congestion.
Most of these KPI’s are made us of single counters taken from the RNC or RBS. The list of Transport KPI’s
are shown below:

Report KPI Counters/Formula

Accessibility CS RRC fails - TN Congestion/Blocking
Accessibility PS RRC fails - TN Congestion/Blocking
Accessibility CS RRC Block - TN Congestion/Failure
(Best Cell)
Accessibility PS RRC Block - TN Congestion/Failure
(Best Cell)
Accessibility R99 Int RAB Block - TN
Congestion/Failure (Blocking cell)
Accessibility R99 Int RAB Block - TN
Congestion/Failure (Best Cell)
Accessibility HS Int RAB Block - TN
Congestion/Failure (Blocking cell)
Accessibility HS Int RAB Block - TN
Congestion/Failure (Best Cell)
Accessibility Speech RAB Block - TN
Congestion/Failure (Blocked cell)
Accessibility Speech RAB Block - TN
Congestion/Failure (Best Cell)
HSDPA Node B Severe HS Congestion-IUB
HSDPA Node B Tot time IuB Congested DL (sec)
HSDPA Node B Tot time IuB Congested UL (sec)
HSDPA Node B Total time IuB link unavailable (sec)
HSDPA Node B Nbapc messages discarded due to
Congestion
HSDPA Node B Percentage of time HSDPA traffic
limited by Iub
HSDPA Node B HSDPA frame loss ratio on IuB
Transport RNC AAL2 Setup failure for QoS Class A
(CS-- High Priority-Delay 2-10 ms)
pmNoRrcConnReqBlockTnCs
pmNoRrcConnReqBlockTnPs
pmNoRrcConnReqBlockTnCsBest
pmNoRrcConnReqBlockTnPsBest
pmNoRabEstBlockTnPsIntNonHs
pmNoRabEstBlockTnPsIntNoHsBest
pmNoRabEstBlockTnPsIntHs
pmNoRabEstBlockTnPsIntHsBest
pmNoRabEstBlockTnSpeech
pmNoRabEstBlockTnSpeechBest
pmHsSevereCong
pmTotalTimeIubLinkCongestedDl
pmTotalTimeIubLinkCongestedUl
pmTotalTimeIubLinkUnavail
pmNoOfDiscardedNbapcMessages
∑ (pmCapAllocIUBHsLimitRatioSpiXX) where
XX = 0 to 15
100*(pmHsDataFramesLostSpiXX)/
(pmHsDataFramesReceivedSpiXX+pmHsDataF
ramesLostSpiXX) where XX = 0 to 15
100*(pmUnSuccOutConnsLocalQoSClassA +
pmUnSuccInConnsLocalQoSClassA +

Transport RNC AAL2 Setup failure for QoS Class B
(PS--Medium Priority Best effort-Delay
5-20ms)
Transport RNC AAL2 Setup failure for QoS Class C
(High Priority-Unspecified Delay)
Transport RNC Iub - Control Plane Congestion
Transport RNC Tot Time Signalling Link in Service
Transport RNC Discarded CPS packet Rate
Transport RNC ATM Vpc Transmitted Cell Loss Ratio
Transport RNC ATM Vpc Received Cell Loss Ratio
pmUnSuccOutConnsRemoteQosClA +
pmUnSuccInConnsRemoteQosClassA)/(pmSu
ccOutConnsRemoteQosClassA +
pmSuccInConnsRemoteQosClassA +
pmUnSuccOutConnsLocalQoSClassA +
pmUnSuccInConnsLocalQoSClassA +
pmUnSuccOutConnsRemoteQosClA +
pmUnSuccInConnsRemoteQosClassA)
100*(pmUnSuccOutConnsLocalQoSClassB +
pmUnSuccInConnsLocalQoSClassB +
pmUnSuccOutConnsRemoteQosClB +
pmUnSuccInConnsRemoteQosClassB)/(pmSuc
cOutConnsRemoteQosClassB +
pmSuccInConnsRemoteQosClassB +
pmUnSuccOutConnsLocalQoSClassB +
pmUnSuccInConnsLocalQoSClassB +
pmUnSuccOutConnsRemoteQosClB +
pmUnSuccInConnsRemoteQosClassB)
100*(pmUnSuccOutConnsLocalQoSClassC +
pmUnSuccInConnsLocalQoSClassC +
pmUnSuccOutConnsRemoteQosClC +
pmUnSuccInConnsRemoteQosClassC)/(pmSuc
cOutConnsRemoteQosClassC +
pmSuccInConnsRemoteQosClassC +
pmUnSuccOutConnsLocalQoSClassC +
pmUnSuccInConnsLocalQoSClassC +
pmUnSuccOutConnsRemoteQosClC +
pmUnSuccInConnsRemoteQosClassC)
pmNoOfLocalCongestions
pmLinkInServiceTime
100*(pmDiscardedEgressCpsPackets/PMEGR
ESSCPSPACKETS+pmDiscardedEgressCpsPack
ets)
100*(pmBwlostcells/pmTransmittedATMcells
)
100*(pmFwlostcells/pmreceivedATMcells)

Individual counter description for those not found below can be found in the ALEX Libraries.

Counter Description Condition MO Class

pmNoRrcConnReqBlockTnCs
Number of RRC This counters is stepped
Connection Setup if the establishment of
attempts for Circuit an RRC Connection
Switched calls that fail Request with
due to Transport Establishment Cause =
Network blocking Originating/Terminating
Conversational or
Emergency, fails due to
congestion on the user
plane (AAL2) or control
plane (UniSaal or SCTP)
of the transport network
Counter
pmNoRrcConnReqBlockTnPs
pmNoRabEstBlockTnPsIntNonHs
pmNoRabEstBlockTnPsIntNoHsBest
pmNoRabEstBlockNodePsIntHsBest
Description Condition MO Class
as a result of user
dimensioned transport
network resource
shortages
Number of RRC This counters is stepped
Connection Setup if the establishment of
attempts for Packet an RRC Connection
Switched calls that fail Request with
due to Transport Establishment Cause =
Network blocking Originating/Terminating
Interactive or
Background or
Originating Subscribed
Traffic Call, fails due to
congestion on the user
plane (AAL2)or control
plane (UniSaal or SCTP)
of the transport network
as a result of user
dimensioned transport
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type PS of a PS Interactive RAB,
Interactive that are not including PS
blocked due to TN Interactive for HS, fails
congestion or TN failure, due to congestion on the
counted on the blocking user plane (AAL2) or
cell control plane (UniSaal or
SCTP) of the transport
network layer as a result
of user dimensioned
transport network
capacity
Number of RAB Step counter when the UtranCell
establishment attempts establishment of a PS
for RAB-type PS Interactive (excluding
Interactive that are HS) RAB fails due to UNI-
blocked due to TN SAAL or AAl2 congestion,
congestion or TN failure, IP resource limitations or
counted on the best cell blocking as a result of
user dimensioned
transport network
configured capacity
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type PS of a PS Interactive RAB
Interactive for HS that for HS RAB fails due to
are blocked due to node node configuration
congestion or node error, node limitation or
failure, counted on the transport network layer
Counter
pmNoRabEstBlockNodeSpeechBest
pmNoRabEstBlockTnPsIntHs
pmNoRabEstBlockTnPsIntHsBest
pmNoRabEstBlockTnSpeech
pmNoRabEstBlockTnSpeechBest
pmHsSevereCong
Description Condition MO Class
best cell service unavailability.
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type CS Speech of a CS Speech RAB fails
that are blocked due to due to node
node congestion or node configuration error,
failure, counted on the node limitation, or
best cell transport network layer
service unavailability
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type PS of a PS Interactive RAB
Interactive for HS that for HS, fails due to
are blocked due to TN congestion on the user
congestion or TN failure, plane (AAL2) or control
counted on the blocking plane (UniSaal or SCTP)
cell of the transport network
layer as a result of user
dimensioned transport
network capacity
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type PS of a PS Interactive RAB
Interactive for HS that for HS RAB fails due to
are blocked due to node node configuration
congestion or node error, node limitation or
failure, counted on the transport network layer
best cell service unavailability.
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type Speech that of a Speech RAB fails due
are blocked due to TN to congestion on the
congestion or TN failure, user plane (AAL2) or
counted on the blocking control plane (UniSaal or
cell SCTP) of the transport
network as a result of
user dimensioned
transport network
resource shortages
Number of RAB This counter is stepped UtranCell
establishment attempts when the establishment
for RAB-type Speech that of a Speech RAB fails due
are blocked due to TN to UNI-SAAL or AAl2
congestion or TN failure, congestion, IP resource
counted on the best limitations or blocking as
a result of user
dimensioned transport
network configured
capacity
This counter counts the This counter counts the IubLink and
Counter
pmTotalTimeIubLinkCongestedDl
pmTotalTimeIubLinkCongestedUl
Description Condition MO Class
number of severe number of severe IurLink
congestion occurrences congestion occurrences
detected by the detected by the
"CAPACITY ALLOCATION "CAPACITY ALLOCATION
Presence Supervision" Presence Supervision"
function in RNC. This is function in RNC. This is
done per Iub/Iur done per Iub/Iur
interface. A CAPACITY interface.
ALLOCATION control
frame is expected at A CAPACITY
least every one second ALLOCATION control
from RBS per flow frame is expected at
controlled HS flow. If a least every one second
CA has not been received from RBS per flow
for a longer period of controlled HS flow. If a
time, an HS Severe CA hasn't been received
Congestion is detected. for a longer period of
These interface counters time, an HS Severe
shall normally be zero Congestion is detected
These interface counters
shall normally be zero
The time in seconds that This counter is increased IubLink
the Iublink is congested once every second that
on the NBAP Common the Iub link is congested
part of the control plane for the NBAP Common
part of the control plane.
Note that if the Iub link
gets unavaliable, this
counter will not be
increased any more, but
the
pmTotalTimeIubLinkUna
vail will be increased
instead
The time in seconds that WHEN IUB OVER IP Iub
the Iub link is congested Step the counter once
for the NBAP Common every second from when
part of the control plane a Congestion_Ind signal
in the uplink direction is received over the
SCTPI interface for an
NBAP Common SCTP
association.
Stop stepping the
counter when a
Congestion_Cease_Ind
signal is received
OR when a
Comm_Lost_Ind signal is
received
Counter Description
pmTotalTimeIubLinkUnavail The time in seconds that
the Iub link is unavailable
for the NBAP Common
part of the control plane,
due to network or node
internal problems.
Condition MO Class
for any reason.
Note1: The reception of
the Congestion_Ind
signal indicates that the
SCTP association for
NBAP Common is
temporarily congested
and
cannot transmit data.
Note2: The counter
ceases stepping when
a comm_lost_ind is
received for any reason
because the link shall be
considered unavailable
from that time onwards
and the Iub Link
Unavailability counter
shall be stepped instead.
The converse situation
does not apply since
it is not possible to be
congested if the link is
unavailable.
WHEN IUB OVER ATM
1) Start timer when a
congestion indication
is received AND
NbapCommon
operational
state=enabled
2) Step counter once per
second until 3)
3) Stop timer when:
3.1 A congestion cease
indication is received
AND NbapCommon
operational
state=enabled
OR
3.2 there is a state
change to NbapCommon
operational
state=disabled
This counter is increased IubLink
once every second that
the Iub link is
unavailable for the NBAP
Common part of the
control plane. Note that
Counter
pmNoOfDiscardedNbapcMessages
pmCapAlloclubHsLimitingRatioSpiXX
where XX = 0 to 15
pmHsDataFramesLostSpiXX
where XX = 0 to 15
pmHsDataFramesReceivedSpiXX
where XX = 0 to 15
pmUnSuccOutConnsLocalQoSClassA*
pmUnSuccInConnsLocalQoSClassA*
Description Condition MO Class
the counter is not
stepped for
unavailability due to
operator initiated
activities (for example
manual blocking of Iub
link)
Number of NBAP The counter is stepped IubLink
Common messages when an NBAP Common
rejected by Admission messages is rejected due
Control due to L2 to L2 signaling bearer
signaling bearer congestion
congestion.
The relative number of The relative number of IubDataStrea
occurrences when the occurrences when the ms
calculated capacity calculated capacity
allocation figure is allocation figure is
limited by limited
the Iub high-speed by the Iub high-speed
bandwidth during a 100 bandwidth every 100 ms
ms (compared with the total
period. number of 100 ms
periods in the report
output period).
The number of high- Each high-speed data IubDataStrea
speed data frames lost frame that is lost over ms
by the
the RBS in the Iub Iub interface increases
interface the count by 1.
The total number of Each high-speed data IubDataStrea
high-speed data frames frame received by the ms
received by the RBS over RBS
the Iub interface over the Iub interface
increases the count by 1.
Number of unsuccessful Unsuccessful outgoing Aal2Ap
attempts to allocate connection
AAL2 resources establishment caused by
(Common Part sublayer) CAC rejects
during establishment of
outgoing connections on
this Access Point (AP).
Caused by Rejects in
Connections Admission
Control (CAC). The
granularity period of 60
minutes is not supported
Number of unsuccessful Unsuccessful incoming Aal2Ap
attempts to allocate connection
AAL2 path resources establishment caused by
(Common Part Sublayer) unsuccessful resource
Counter
pmUnSuccOutConnsRemoteQosClA*
pmUnSuccInConnsRemoteQosClassA*
pmSuccOutConnsRemoteQosClassA*
pmSuccInConnsRemoteQosClassA*
Description Condition MO Class
during establishment of allocation (CID, B/W,
incoming connections on CAC)
this Access Point (AP)
caused by Channel
Identifier (CID) and/or
bandwidth collision or
mismatch of Call
Admission Control (CAC)
between peers. The
granularity period of 60
minutes is not supported
Number of unsuccessful The counter increments Aal2Ap
establishments of when any of the
outgoing connections on following events occur
this AAL2 Access Point after Q.2630 establish
(AP). The granularity request message has
period of 60 minutes is been sent from this
not supported. AAL2 Access Point :
- reject from remote side
- reset from remote side
- no reply (time out)
- signalling link failure
Number of unsuccessful The counter increments Aal2Ap
establishments of in a Terminating node or
incoming connections on in a Transit node as soon
this AAL2 Access Point as the connection has
caused by the reject from been rejected by the
the AAL2 Access Point in other node due to any of
the remote node. The the events :
granularity period of 60 - release connect from
minutes is not remote side
supported. - release from remote
side
- reset from remote side
Number of successful The counter increments Aal2Ap
establishments of in a Terminating node or
outgoing connections on in a Transit node when a
this AAL2 Access Point Q.2630 establishment
(AP). The granularity confirm message is sent
period of 60 minutes is (i.e. as soon as the
not supported connection goes to
CONNECTED state)
Number of successful The counter increments Aal2Ap
establishments of in a Terminating node
incoming connections on and in a Transit node
this AAL2 Access Point when a Q.2630
(AP). The granularity establishment confirm
period of 60 minutes is message is sent (i.e. as
not supported soon as the connection
goes to CONNECTED
Counter
pmNoOfLocalCongestions
pmLinkInServiceTime
pmDiscardedEgressCpsPackets
pmEgressCpsPackets
pmBwlostcells
pmTransmittedATMcells
pmFwlostcells
Description Condition MO Class
state)
Number of local Out buffers filled above NniSaalTp,
congestions. This counter congestion level UniSaalTp
is incremented when the
sum of SAAL send and
retransmission buffers is
filled to more than what
the congestionOnSet
attribute is configured
for
The accumulated time (in Signalling link in service NniSaalTp,
seconds) the signalling UniSaalTp
link has been in service
(in assured data transfer
mode) since it was
created. If the link is
down, the value is 0.
Number of discarded This counter is Aal2PathVcc
AAL2 Common Part incremented for each Tp
Sublayer (CPS) packets in egress AAL2 CPS packet
egress direction. The towards the remote
granularity period of 60 AAL2 path end point that
minutes is not supported is discarded due to
congestion in the ATM
layer. The counter is
reset at the beginning of
the interval
Number of AAL2 This counter is Aal2PathVcc
Common Part Sublayer incremented for each Tp
(CPS) egress packets AAL2 CPS packet that is
sent. The granularity sent towards the remote
period of 60 minutes is AAL2 path end point.
not supported The counter is reset at
the beginning of the
interval
Number of lost backward This counter is VpcTp,
cells on the Virtual incremented for each Aal0TpVccTp,
Channel Connections block with one or more Aal1TpVccTp,
(VCC) and Virtual Path errored cells received by Aal2PathVcc
Connections (VPC). The the Termination Point. Tp,
granularity period of 60 The counter is reset at Aal5TpVccTp
minutes is not supported the beginning of the
interval
Number of transmitted An ATM cell is sent AtmPort
ATM cells through the
ATM port
Number of lost forward This counter is VpcTp,
cells on the Virtual incremented with the Aal0TpVccTp,
Channel Connections number of cells Aal1TpVccTp,
(VCC) and Virtual Path transmitted in a block, Aal2PathVcc
 Counter Description Condition MO Class
Connections (VPC). The but not received in the Tp,
granularity period of 60 block by the Termination Aal5TpVccTp
minutes is not supported Point. The counter is
reset at the beginning of
the interval
pmreceivedATMcells Number of received ATM An ATM cell is received AtmPort
cells through the ATM
port
*Repeated for B, C and D QoS

5.1.1. RNC/Market/Region Level Reporting and Overview

The metrics described in the previous pages can be used as an indication of issues that should be
investigated further on an Iub level, possibly at an ATM Level. These metrics are more useful on an
individual node/link basis and should be analyzed at this level.
The areas that can be used for analysis are:
 RRC and RAB TN Congestion/Blocking (All Service Types)
 Iub Congestion (UL and DL)
 AAL2 QoS A – D Setup Failures
 ATM Lost Cells (Transmitted and Received)

5.1.2. Iub/Transport Link Analysis

All of the metrics shown above should be used on an Cell or Transport level to accurately identify the
worst offending nodes or links. The Worst Offenders in an RNC/Market/Region level should be ranked by
the metrics detailed in the high level reporting above.

RRC and RAB TN Congestion/Blocking (All Service Types)

Speech, PS Interactive and HSDPA RRC and RAB’s may be affected by a number of issues related
to transport blocking or unavailability. These include:
 Failures due to congestion on the user plane (AAL2) or control plane (UniSaal or SCTP)
of the transport network as a result of user dimensioned transport network resource
shortages
 transport network layer service unavailability
If failures on a Cell or RBS level are found with these causes, a TT must be raised to the Region
Capacity team for resolution.

Iub Congestion (UL and DL)

Al services may be affected by a number of Iub issues. These include:
 Iub Congestion
 NBAP-C Message Discards
  HSDPA Frame Loss on the Iub
If failures on a Cell or RBS level are found with these causes, a TT must be raised to the Region
Capacity team for resolution.

AAL2 QoS A – D Setup Failures

If failures on a Cell or RBS level are found with these causes, a TT must be raised to the Region
Capacity team for resolution.

ATM Lost Cells (Transmitted and Received)

If failures on a Cell or RBS level are found with these causes, a TT must be raised to the Region
Capacity team for resolution.
6. RNC Capacity
From an RF perspective, there is only one main KPI related to the RNC Capacity/Load which affects the
Accessibility. This list does not include general capacity issues on the RNC. The main KPI may be found in
the following report:
 Accessibility
The Capacity I report can also be used to investigate the MP Load on the RNC if required.
The list of RNC Capacity KPI’s are shown below:

Report KPI Counters/Formula

Accessibility RRC reject due to MP load control pmNoRejRrcConnMpLoadControl
Capacity I MP Load pmSumMeasuredLoad/pmSamplesMeasured
Load

Individual counter description for those not found below can be found in the ALEX Libraries.

Counter Description Condition MO Class

pmNoRejRrcConnMpLoadControl Number of rejected RRC Sending of the RRC UtranCell
connections due to message RRC
module MP load control Connection Reject with
(includes incoming Inter- rejection cause
RAT CC congestion when the
congestion cause has
been indicated by
internal load control.
pmSumMeasuredLoad The sum of samples of Every time the processor LoadControl
the measured load. The load is sampled, the
load is measured counter is incremented
in percentage (%). by the sampled load
pmSamplesMeasuredLoad Number of samples of This counter is LoadControl
the measured processor incremented by 1 at
load every sample of the
processor
load. The processor load
is sampled once every 1
seconds
If consistent issues are detected with MP load, a Homer TT must be raised with the Regional Capacity
team. Before raising this issue, it must be investigated if there were individual spikes for short durations
or a sustained MP Load issue. An example of these daily failures can be seen in the next graphic. The
RNC had MP Load issues spiking at >85% which caused this issue. (Hourly stats are not available for this
time period but the failures were predominantly seen during BH.
 RRC reject due to MP load control
120000

100000

80000

60000

40000

20000

RRC reject due to MP load control

In the second chart, following the RNC upgrade, we can drill down to an hourly level and the issue only
occurs for a short period (One ROP @ 0000). This may have been related to an upgrade or parameter
changes on the RNC.
RRC Reject Due to MP Load Control - Post RNC Upgrade
45000

40000

35000

30000

25000

20000

15000

10000

5000

Total
The MP Load can also be checked to determine if there were any issues with RNC Load during this
period.
7. Capacity Management Tool
Capacity Management tools and methods should also be used in improving capacity. These items
include:
– OSS-RC
– Measurement Results Recording – WCDMA (WMRR)
– This is a special measurement report run on any number of cells in the RNC and run for less
than 24 hours. This data provides:
• BLER for all service combinations
• UE Tx Power
• DL CPICH Ec/No & RSCP
xConfig should also be used to ensure all parameters are consistent with the FSC Baseline Set unless
otherwise agreed for performance reasons.
8. Troubleshooting Tools
The following tools can be used for troubleshooting:
 Tektronix K-18
 This is a protocol analyzer used for analysis of the Iu and Iub links and the layer 1, 2 and
3 messaging. This can be used for further analysis of the call flows
 More detailed information on this can be found in the Tektronix Documentation
 GPEH
 The General Performance Event Handling (GPEH) tool is a feature in the Ericsson OSS
that provides capability similar to a protocol analyzer.
 This can be run on an RNC level
 More detail on this tool can be found in ALEX
 CTR
 The Call Trace (CTR) tool is a feature in the Ericsson OSS that provides capability similar
to the GPEH Tool
 This can be run on a Cell level for specific cell troubleshooting. These files can be read in
Actix
 More detail on this tool can be found in ALEX
 UETR
 The User Equipment Trace (UETR) tool is a feature in the Ericsson OSS that provides
capability similar to the GPEH Tool
 This is run on a particular IMSI for specific issue troubleshooting, typically a test SIM
attempting to recreate problem conditions. These files can be read in Actix
 More detail on this tool can be found in ALEX
9. References
1. 3GPP TS 25.331 V 5.19.0 “UMTS Radio Resource Control Protocol Specification”.
2. Ericsson ALEX
3. Allan Orbigo, Christophe Vidal, .
4. Alejandro Aguirre, Sireesha Panchagnula Ericsson UTRAN Parameters.
5. 3GPP TS 25.304 V 5.9.0 “UMTS UE Procedures in Idle Mode and Procedures for Cell Reselection
in Connected Mode”.
6. UMTS Network KPI, U12 UMTS Network KPI v6.14 080406TMO LR.doc
7. UMTS Network KPI Level 2, UMTS Network KPI Level-2_v1_20070205ERI_Updated.doc
8. UMTS RNC LCS KPI definitions and Formulas, Michael Gebretsadik
9. 3GPP TS 25.331, UMTS RRC protocol specification.
10. 3GPP TS 25.211 V 5.8.0, “UMTS Physical channels and mapping of transport channels onto
physical channels”.
11. 3GPP TS 25.413 V 5.12.0, “UTRAN Iu Interface RANAP Signaling”.
12. 3GPP TS 25.214, ”UMTS Physical Layer Procedures FDD”.
13. Ericsson Product Documentation, EN/LZN 733 0017  R4A.
14. Ericsson Product Documentation, “Guidelines for LA/RA/URA planning”
15. Ericsson Product Documentation 58/1551-AXD 105 03/1 Uen G, “Performance Statistics RNC
3810”.
16. Nabeel Lughmani, Pradeep Singh, Tim Zhang, “Paging Performance Guidelines”.
17. Sireesha Panchagnula, “UMTS Paging Concepts”.