3G KNOWLEDGE

SHARING

BASICS

WCDMA Channels

Voice Call Flow

RNC

UE

CN

User decides to
originate a call
RACH process:
accessing the system

RACH Procedures
RRC Connection Request

RRC connection:
establishing
dedicated
control link

Negotiation
with CN

RRC Connection Setup

RRC Connection Setup Complete
Authentication and Security Procedures
UL Direct Transfer
DL Direct Transfer

[CC: Setup]
[CC: Call Proceeding]
Request to establish RAB

Radio Bearer Setup

Radio Bearer Setup Complete
RB Setup:
establishing dedicated
payload link

DL Direct Transfer [CC: Alerting]

Call Release

UMTS Intra-Frequency Reselection

Qmeas,s = Serving Cell Ec/No
Qmeas,n = Neighbor Cell Ec/No
Qoffset = offset for neighbor intra-frequency
Qhyst = hysteresis for serving Cell

Concept

Intra-frequency cell reselection is

based on the relative ranking of
the serving and the neighbor
cells

Step-1: Scell1 < SIntraSearch

Measurement is initiated
Step-2: RCell1 < RCell2
Step-3: RCell1 < RCell2 < RCell3

SintraSearch

Step-4 criteria in step-3 is satisfied

for the duration of the reselection
timer (Treselection = 1 seconds)

Reselection to Cell3

UMTS Inter-RAT Reselection to GSM

Qmeas,s = Serving Cell RSCP

Qmeas,n = Neighbor Cell RSSI
Qoffset = offset for neighbor
frequency
Qhyst = hysteresis for serving Cell

UTRAN Intra-Frequency Handover

Procedure
UE

RNC
RB Setup Complete
Measurement Control

UTRAN configures event 1a, 1b and 1c

Applies new measurement configuration

Starts intra-freq measurements

Event 1a triggered

Measurement Report (1a)

Active Set Update

UE adds new cell

in to active set

Event 1b triggered

Active Set Update Complete

Measurement Report (1b)

Active Set Update

UE removes a cell
from active set

UTRAN decides to add new cell into active set

Active Set Update Complete

UTRAN decides to remove a cell from active set

UTRAN to GERAN Inter-RAT Handover

UE

RNC
RB Setup Complete
Inter-RAT MCM (2d, 2f)
Applies new measurement configuration
Starts intra-freq measurements

Measurement Report (2d)

Physical Channel Reconfig. (CM Config.)
Physical Channel Reconfig. Complete
3 CM Patterns:

Inter-RAT MCM (GSM cells, CM Act., 3a)

GSM RSSI
BSIC Ident.

Applies new measurement configuration

Starts inter-RAT measurements

Measurement Report (3a)

Handover from UTRAN command
UE connects to GSM

BSIC Reconfirm.

WCDMA Events

Event

Description

Event Type

Event 1a

Active set Addition

For SHO

Event 1b

Active set deletion

For SHO

Event 1c

Replacement of active set cell

Event 1d

Change of best cell

Event 2d

Compressed mode trigger

Event 2f

Compressed mode exit

Event 3a

iRAT execution

Event 1d(HS)

Change of serving HS cell

For SHO

For SHO

iRAT

iRAT

iRAT

HS cell Change

GOLDEN
PARAMETERS

iRAT

Idle Mode Measurements

qOffset1sn(MO: GSM
relation) : 5 dB

-6 dB

Qhyst, 2sn

FDD_Rscpmin(Threshold
for GtoU re-selection)
-106 dBm
FDD_Qmin(Threshold
for GtoU re-selection)
-111 dBm
Qhyst, 1sn
2 dB
-113 dBm

-115 dBm

QRxlevelMin

Ec/No

RSCP
Cell Selection & Re-selection parameters

iRAT Events Ec/No

CS only
-12 dB

CS + PS Multi RAB
-13 dB

2f
Hysteresis2f/2

2f
Hysteresis2f/2

-13 dB

-14 dB

UsedFreqRelThresh2fEcNo

UsedFreqRelThresh2fEcno

UsedFreqThresh2dEcNo -15 dB

-15 dB

ServiceOffset2dEcno

Hysteresis2d/2

-16 dB

UsedFreqThresh2dEcno

-16 dB

2d

Hysteresis2d/2
-17 dB

2d

3a
3a
If GSM RSSI > 95 dBm

2d

2f

3a

If GSM RSSI > 95 dBm

Start GSM Measurements

Stop GSM Measurements
iRAT HO excution

Delay the iRAT for PS only services by setting

serviceoffset2dEcno as -6 ( -21 dB)

iRAT Events RSCP

CS only
-105 dB

CS + PS Multi RAB
2f

-106 dB

Hysteresis2f/2

2f
Hysteresis2f/2

-106 dB

-107 dB

UsedFreqRelThresh2fRscp

UsedFreqRelThresh2fRscp

UsedFreqThresh2dRscp

-109 dB
Hysteresis2d/2
-110 dB

UsedFreqThresh2dRscp

-109 dB

ServiceOffset2dRscp

2d

-110 dB
Hysteresis2d/2
-111 dB

2d

3a
3a

If GSM RSSI > 95 dBm

If GSM RSSI > 95 dBm

2d

2f

3a

Start GSM Measurements

Stop GSM Measurements
iRAT HO excution

Delay the iRAT for PS only services by setting

serviceoffset2dRscp as -6 ( -115 dBm)

iRAT Events UE Tx power

CS + PS Multi RAB
CS only

6b

6b

ueTxPowerThresh6b
18 dBm

-104
dBm

ueTxPowerThresh6b
18 dBm

-105
dBm

6d
Max UE Tx power
If UMTS RSCP < UsedFreqThresh2dRscp+
utranRelThreshRscp (Offset for UE Tx power)
AND
GSM RSSI > -95 dBm

6d
Max UE Tx power

3a

If UMTS RSCP < UsedFreqThresh2dRscp+ service

offset2dRscp+ utranRelThreshRscp (Offset for UE Tx power)
AND
GSM RSSI > -95 dBm

For PS only services Event 6d trigger should

be set as 110 dBm

3a

Idle Mode Parameters

Parameter
qQualMin
qRxlevMin

Description
Minimum acceptable Quallevel in the
cell, to perform cell selection
Minimum acceptable RX level in the cell,
to perform cell selection

Recommende
d Setting
-18 dB

This is the min Ec/No level required for system acquisition

-115 dBm

This is the min RSCP level required for system acquisition

sIntrasearch

Threshold (relative to Qqualmin) to

enable intra-frequency measurements.

10 dB

sRatSearch

The decision on when measurements on

GSM frequencies shall be performed is
made using this parameter in relation
with Squal.

2 dB

qHyst2sn

qHyst1sn

Hysteresis value in the cell ranking

criteria for cell reselection when EC/N0 is
used
Hysteresis value in the cell ranking
criteria for cell reselection when RSCP is
used

Remarks

2 dB

2 dB

tReselection

Control of cell selection/reselection.

Time-to-trigger for cell reselection.

1s

qOffset1sn(MO: GSM
relation)

Signal strength offset between source

and target cells

5-7 dB

FDD_RSCP_min

Minimum RSCP threshold for UTRAN

FDD cell reselection

-106 dBm

FDD_Qmin

Minimum Ec/No threshold for UTRAN

FDD cell reselection. (4 dB difference
from Qualmin)

-14 dB

If the parameter is too low, the UE will not perform intra-frequency

measurements and may miss the opportunity to perform cell
reselection. If parameter is too high, the UE will perform intrafrequency measurements although the likelihood that the neighboring
cells will meet the cell reselection criteria is very small, thereby
wasting UE battery.
If the parameter is too small, the UE will not perform inter-RAT
measurements and may miss the opportunity to perform cell
reselection to another RAT. If parameter is too large, the UE will
perform inter-RAT measurements very often, most likely leading to
unnecessary GSM reselections.
If parameter is too small, the UE may perform frequent cell reselection
to cells only marginally better than the current serving cell, which may
lead to excessive battery consumption. If parameter is too large, the
UE may be camping on a relatively weak cell although a significantly
better cell is available
If parameter is too large, the UE may be camping on a relatively weak
cell although a significantly better cell is available, or worse it may
suffer an outage in case of a neighboring cells rising CPICH.
Defines idle mode 3G-2G cell re-selection. Too high value, will delay
the 2G cell re-selection in bad RSCP condition and too low value will
lead to faster 2G cell re-selections
If the parameter is set too low, UTRAN FDD cells may be reselected
too early, leading to ping pong. If the parameter is set too high,
UTRAN FDD cells may not be reselected compromising WCDMA
coverage.
If the parameter is set too low, UTRAN FDD cells may be reselected to
too early, leading to ping pong. If the parameter is set too high,
UTRAN FDD cells may not be reselected compromising WCDMA
coverage

Connected Mode Parameters

Parameter
usedFreqThresh2dRscp
usedFreqThresh2dEcno
hysteresis2d
timeToTrigger2dRscp
timeToTrigger2dEcno

Description
Threshold for event 2d for the used frequency when the measurement quantity is RSCP. Event 2d is
used to activate compressed mode
Threshold for event 2d for the used frequency when the measurement quantity is Ecno. Event 2d is used
to activate compressed mode
The hysteresis parameter determines when any event is trigerred as well as re-trigerred and de-trigerred
Period of time during which the Event 2d triggering condition must be satisfied before transmission of the
MEASUREMENT REPORT message can occur
Period of time during which the Event 2d triggering condition must be satisfied before transmission of the
MEASUREMENT REPORT message can occur

Recommended Setting
-109
-15
2 dB
640 ms
640 ms

usedFreqRelThresh2fRscp

Relative threshold for event 2f versus event 2d for the used frequency when the measurement quantity is
RSCP. Event 2f is used to deactivate compressed mode

3 dB

usedFreqRelThresh2fEcno

Relative threshold for event 2f versus event 2d for the used frequency when the measurement quantity is
CPICH Ec/No. . Event 2f is used to deactivate compressed mode

2 dB

hysteresis2f

The hysteresis parameter determines when 2f event is trigerred as well as re-trigerred and de-trigerred.
A relatively higher value of hysteresis helps to avoid re-trigerring the same event several times under
fluctuating radio conditions

2 dB

timeToTrigger2fRscp

Period of time during which the Event 2f triggering condition must be satisfied before transmission of the
MEASUREMENT REPORT message can occur

1280 ms

timeToTrigger2fEcno

Period of time during which the Event 2f triggering condition must be satisfied before transmission of the
MEASUREMENT REPORT message can occur

1280 ms

gsmThresh3a

It represents the minimum required GSM RSSI for reliable handover to GSM

-95 dBm

serviceOffset2dRscp

Service-specific offset for event 2d when the measurement quantity is RSCP

0(CS only and (CS+PS)

MultiRAB) /-6 for PS only

serviceOffset2dEcno

Service-specific offset for event 2d when the measurement quantity is Ecno

0(CS only and (CS+PS)

MultiRAB) /-6 for PS only

IRAT parameter settings in Delhi

Parameter

Value

usedFreqThresh2dEcno

-15 dB

usedFreqThresh2dRscp

-108 dBm

usedFreqRelThresh2fEcno

2 dB

usedFreqRelThresh2fRscp

3 dB

hysteresis2d

hysteresis2f

hysteresis3a

gsmThresh3a

-88 dBm

utranRelThresh3aRscp

utranRelThresh3aEcno

Fdd_RscpMin

-102 dBm

Fdd_QMin

-12 dBm

Parameter

CS
Only

CS+PS
multiRAB

PS
only/PS+PS
multiRAB

ServiceOffset2dEcno

-3,-7

-3,-7

ServiceOffset2dRscp

-2

-3,-5,-11-13

-3,-5,-11-13

Current parameter settings triggers IRAT HO

at:
CS only:
Ecno: -15 dB
Rscp: -110 dBm
CS+PS multiRAB:
Ecno: -18 dB or -22dB
Rscp: -111dBm or -113 dBm or -115 dBm
PS+PS multiRAB:
Ecno: -18 dB or -22dB
Rscp: -111dBm or -113 dBm or -115 dBm

Current settings will delay and almost disable the IRAT HO for CS+PS multiRAB. It will lead
to poor voice quality and high Speech DCR

SOFT HANDOVER

Soft Handover Parameters

Parameter

Description

reportingRange1a

Threshold used for addition-window in

evaluation criteria for event type 1a

reportingRange1b

Threshold used for drop window in

evaluation criteria for event type 1b

Recommended
Settings

Remarks

3 dB

With too low value, cells of relatively good quality may not trigger an Event 1a and will
have no chance of inclusion in the active set, which may lead to poor call quality and,
ultimately, a call drop. If parameter is set to a value too large, cells of relatively poor
quality may trigger an Event 1a and be unnecessarily included in the active set,
therefore degrading downlink capacity

10(5dB)

With too large value, cells of relatively poor quality may not trigger an Event 1b and
capacity will be degraded. If parameter is set to a value too small, cells of relatively
good quality may trigger an Event 1b prematurely, thereby negatively affecting call
quality
If parameter is set to a value too large, cells of relatively good quality may not trigger
an Event 1c and will not replace cells of relatively poor quality, therefore degrading
downlink capacity. If parameter is set to a value too small, cells of quality only
marginally better than that of an active set cell may trigger an Event 1c, therefore
increasing signaling load without appreciably improving the combined active set cells
quality

hysteresis1c

Hysteresis used in replacement

threshold in evaluation criteria for
event 1c to avoid ping pong effects

2(1dB)

hysteresis1d

Hysteresis used for change of best cell

evaluation criteria for event type 1d

15(7.5dB)

measQuantity1

the quantity the UE measures to

evaluate the triggering of
measurement reports for intrafrequency handover events

2(EcNo)

timeToTrigger1a

Time between detection of event 1a

11(320 ms) /10 (200
and sending the measurement report
ms)
for the same

Too low value will trigger frequent change of best cells causing UE to send
measurement reports

----

If parameter is too small, monitored cells of relatively low average quality, but whose
received CPICH EC/N0 exhibits rapid and large fluctuations, may trigger
MEASUREMENT REPORT message transmission and be added to the active set. If
parameter is too large, the UE will delay transmission of MEASUREMENT REPORT
message corresponding to monitored or detected cells of relatively good quality.

Contd
Parameter

Description

Recommended
Settings

Remarks

14(2560ms)

Measurement reporting can be reduced significantly by increasing the time to trigger

(TTT) of Event 1b. In quickly fluctuating environments (Rician or Rayleigh fading at
medium or large velocities), it is detrimental to quickly drop a cell (due to a low TTT for
Event 1b). The link might suffer until the RNC includes the cell after an Event 1a is
reported. The reduction in measurement reporting comes at the expense of a small
loss in capacity as weak cells remain in the active set.

timeToTrigger1b

Time between detection of event 1b

and sending the measurement report
for the same

timeToTrigger1c

Time between detection of event 1c

and sending the measurement report
for the same

11(320 ms)

If parameter is too small, monitored cells of relatively poor average quality, but whose
received CPICH EC/N0 exhibits rapid and large fluctuations, may trigger
MEASUREMENT REPORT message transmission and be added to the active set. If
parameter is too large, the UE will delay transmission of MEASUREMENT REPORT
message corresponding to monitored or detected cells of relatively good quality

timeToTrigger1d

Time between detection of event 1d

and sending the measurement report
for the same

14(2560ms)

Too low value trigger frequent change of best cells for soft handovers

reportingInterval1a

Transmission period of
MEASUREMENT REPORT messages
sent by the UE in case of periodic
reporting triggered by an Event 1a

reportingInterval1c

Transmission period of
MEASUREMENT REPORT messages
sent by the UE in case of periodic
reporting triggered by an Event 1c

hsHysteresis1d

Constant in the inequality criterion that

needs to be satisfied for an Event 1d
to occur.

hsTimeToTrigger1d

Period of time during which the Event

1d triggering condition must be
satisfied before transmission of the
MEASUREMENT REPORT message
can occur.

3(1sec)

If the interval is chosen too short, the UE will transmit an unnecessarily large amount
of measurement reports, thereby consuming processing power in the UTRAN. If the
interval is chosen too long, the reporting might not reflect the UEs environment
closely, thereby inhibiting the benefits of periodic reporting after an Event 1a was
detected

3(1sec)

If the interval is chosen too short, the UE will transmit an unnecessarily large amount
of measurement reports, thereby consuming processing power in the UTRAN. If the
interval is chosen too long, the reporting might not reflect the UEs environment
closely, thereby inhibiting the benefits of periodic reporting after an Event 1c was
detected

30 (3dB)

If parameter is set to a value too large, cells of relatively good quality may not trigger
an Event 1d and will not replace an HS serving cell of relatively poor quality, thereby
degrading downlink capacity. If parameter is set to a value too small, cells of quality
only marginally better than the HS serving cell may trigger an Event 1d, therefore
increasing signaling load (ping pong) without appreciably improving the downlink
capacity

640 ms

If set too low, frequent reporting of event 1d may occur (driving up signaling and
unnecessarily degrading throughput as a result of frequent but partially unnecessary
HS cell changes). If set too high, reporting of potentially suitable HSDPA serving cells
may be delayed (thereby degrading downlink throughput.

Coverage

Power Mapping for R99 Services

Relative RL power

maxPwrMax
4 dB
interPwrMax
3.5 dB

minPwrMax
0 dB

Min Rate

Max Rate

<= 15.9 Kbps

> 64 Kbps

RL Rate

Inter-Rate
<= 64 Kbps

If the max power for each DCH is set too high, the capacity of the cell might be severely limited in case multiple
UEs are at the cell edge, and if it is set too low, the coverage for that service might be severely limited
compared to the CPICH

CPICH power Ratio and Ec/No

It has been observed that majority of cells having low CPICH to max power ratio have very high percentage of Ec/Io samples < -14dB.

40 Watt cells are having very poor Ec/Io as compared to 20 Watt cells
As a rule of thumb, CPICH power should be in the range 8% to 10% of total power. Lower values may degrade EcIo distribution in the
cell, especially at high load and in the cell edge, causing problems for the UE to be able to decode Common Control Channels,
leading to accessibility and retainability issues.
CPICH Power Ratio = CPICH power/Total power ( @ antenna connector)

For Ex:
Total TX power = 40W
Ec/No @ 2.8W CPICH = 34.47 43 dBm = -9 dB (own cell)
Feeder loss = 0.5 dB
Net Ec/No considering 3dB inter cell interference = -12 dB
Required CPICH power ratio = 8%
Avg DL Power utilization = 50%
CPICH power ratio
CPICH pwr = 8%*(35.48W( equivalent of 45.5 dBm) = 2.8W Ec/No

** To be done at cluster level alongwith phy. optimization

Power utilization Vs CPCIH Power ratio (Need for

increase in CPICH)

Cpich power should be increased

Cpich power should be

increased simultaneous
with physical optimization

Cpich power should be increased

Cpich power should be

increased simultaneous
with physical optimization

93 cells out of 341 cells in DLGGN01 have CPICH Power ratio < 4% and Power utilization < 40 %
67 cells out of 453 cells in DLVKP01 have CPICH Power ratio < 4% and Power utilization < 40 %
These cells are underutilized cells in terms of power and CPICH power in these cells should be
increased to 5 %. It will also balance the load of neighboring cells.

Low CPICH power(<4%) can also be increased for the cells having power utilization > 40% but with
physical optimization

CPICH Power Ratio- Delhi Settings

Total 20 Watt Cells: 97

Total 40 Watt Cells: 535
Total 60 Watt Cells: 10

47% cells in 40 Watt category has CPICH

power ratio <4 %.
20% cells in 20 Watt category has CPICH
power ratio between 3 to 4%
Impact:
Very low CPICH power ratio might result
in significant degradation of EcIo at high
load
This degradation in EcIo may cause poor
accessibility, retainability and poor user
throughput
More power is required in all the cells to
compete with the higher interference in
DL, so achieved gain in capacity by
upgrading to 40 Watt will be lower
Recommendation: It is recommended to
increase CPICH power by 2-3 % and give Edowntilt so that the impact of increasing
CPICH on pilot pollution will be minimized. 40
Watt cells can be targeted first.

Other Control Channel Parameters

Parameter

Description

Recommended
Settings

Remarks

maxFach1Power

It defines the maximum power used for transmitting the logical

channels (BCCH, CCCH, and DCCH control signaling) relative to 18(1.8dB)
the primaryCpichPower value.

Too high value may cause high capacity

blockings.Note: The value can be increased
after identification of cells having poor RRC
success rate due to bad coverage

maxFach2Power

It defines the maximum power used for transmitting the logical

channel (DTCH traffic signaling) relative to the
primaryCpichPower value.

15(1.5dB)

Too high value may cause high capacity

blockings

bchPower

It is the power used for transmitting on the BCH, relative to the

primaryCpichPower value

-31(-3.1dB)

At Too low value UE can miss System

information send on BCCH

primarySchPower

It is the power used for transmitting on the Primary SCH, relative

-18(-1.8dB)
to the primaryCpichPower value.

At Too low value UE may not be able to

detect Primary SCH for cell search procedure

secondarySchPower

It is the power used for transmitting on the Secondary SCH,

relative to the primaryCpichPower value

-35(-3.5 dB)

At Too low value UE may not be able to

detect Secondary SCH for cell search
procedure

aichPower

Power level of the AICH relative to that of the primary CPICH.

-7 to -5dB

If parameter is too small, the probability of

acquisition indicator misdetection and false
alarm increase. Indicator misdetection leads
to increased access time and to increased
uplink interference caused by the access
attempt.If parameter is too large, downlink
capacity is unnecessarily consumed.

pichPower

PICH transmit power relative to that of the CPICH

-7 to -6 dB

If set too low, the probability of miss-detection

and probability of false alarm increase. If set
too high, downlink capacity is wasted.

Control channel Powers

Description

Delhi Settings

Recommended

maxFach1Power

It defines the maximum power used for

transmitting the logical channels (BCCH, CCCH,
and DCCH control signaling) relative to the
primaryCpichPower value.

Each cell has

different value
ranging from
1.8 dB to 5 dB

1.8

maxFach2Power

It defines the maximum power used for

transmitting the logical channel (DTCH traffic
signaling) relative to the primaryCpichPower
value.

Each Cell has

different value
ranging from 1
dB to 4 dB

Parameter

It is the power used for transmitting on the

PrimarySchPower Primary SCH, relative to the
primaryCpichPower value.

bchPower

It is the power used for transmitting on the

BCH, relative to the primaryCpichPower value.

1.5

-1.8 dB to -1.8
8.7dB

-3 dB to -7 dB

-3.1

Remarks

Too high value may cause high capacity

blocking

Too high value may cause high capacity

blocking

At Too low value UE may not able to

detect Primary SCH for cell search
procedure
At Too low value UE may miss System
information send on BCCH

Low values of sch and bch power may reduce Power congestion if any but high fach1 and fach2 power
may increase power utilization and might lead to power blocking.

UL Sync and L1 Timers

Majority of CS and HS drops in the network account for UL sync lost and procedure
timeouts

Total Time to detect Radio Link failure = nOutSyncInd + rlFailureT +

HsdschRcLostT/DchRcLost

nOutSyncInd are the # of frames to be considered for out-of-sync detection. Recommended

value is 256 frames
rlFailureT is the guard period before sending RL failure. Default value is 1 sec
HsdschRcLostT/DchRcLost is the timer that is started when all the RL(s) for a connection is
lost and after expiry of this timer, CS/PS call is dropped. Recommended setting is 10 sec for
HS and 8 sec for CS calls

Too high value of RLT will lead to mute period and poor customer experience and too low value lead
to early call drops

Throughput

Max Power Setting

MaximumTransmissionPower is the total power to be used in a cell for all downlink

channels.

MaxDlPowerCapability is the maximum downlink power capability of the cell. This

parameter is automatically calculated by subtracting attenuation from the power available at
NodeB antenna port.
Relation between maxDlPowerCapability and maxTotalOutputpower(license)
maxDlPowerCapability(at Antenna port) = maxTotalOutputPower(at RBS antenna port)- feeder loss

Recommended settings : maxTransmissionPower = maxDlPowerCapability

Since in the scheduler, Resource estimation procedure in HSDPA Scheduler takes

maximumTransmissionPower as the maximum downlink transmission power for cell to
estimate power available for HS-PDSCHs. If the maxTxPower< maxdlpowercapability, then
available power will be underutilized in these cells and if it is higher, the scheduler will
overestimate the power.

Delhi max power settings

Issue 1: 25 Cells in the DLVKP01 RNC has maximumDlPowerCapability >
maximumTransmissionPower.
In these cells maximumDlPowerCapability shows the value corresponding to 40
Watt license meaning 40 Watt license is activated in these cells but
maximumTransmissionPower shows the value corresponding to 20 Watt
license.
Impact:
NodeB available power is underutilized in these cells.
Not any benefit of activating 40 Watt license to reduce power blockings
Not any benefit of activating 40 Watt license to improve HS throughput
Issue 2: For 587 cells maximumDlPowerCapability <
maximumTransmissionPower.
But as per the recommendation maximumTransmissionPower should be equal to
maximumDlPowerCapability .
Since in Ericssons Scheduler : Resource estimation procedure in HSDPA Scheduler
takes maximumTransmissionPower as the maximum downlink transmission
power for cell to estimate power available for HS-PDSCHs.
So if maximumTransmissionPower is set higher than maxDlpowerCapability,
then Scheduler will overestimate the power and the above equation will be
misleading
There will be also minor performance degradation Alarm activated for all those
cells where maximumTransmissionPower is set 2 dB greater than
maxDlPowerCapability

Other HSPA throughput related parameters

Category

Parameter

Description

Recommended
Settings

HSDPA

CQIAdjusmentOn

it is algorithm in the system to meet the 3GPP requirement in which it adjusts

CQI so that the NACK ratio does not exceed 10%

TRUE

HSDPA

hsmeasurementpoweroffset

Measurement power offset, sent to the UE and RBS via RRC and NBAP. Used
to offset the CQI in order to utilize the whole CQI range.

HSDPA

numHsScchCodes

Parameter determines how many HS-SCCHs that must be configured

HSDPA

featureStateHsdpaDynamicCodeAllocation

HSDPA

maxNumHsPdschCodes

HSDPA

numHsPdschCodes

It determines the number of codes of SF=16 reserved for the HS-PDSCH

HSDPA

codeThresholdPdu656

Threshold for determining when to use the RLC PDU size = 656 bits for UEs
with HS-DSCH physical layer category 7 to 10, 13 or higher.

HSDPA

hsPowerMargin

It is the power margin, the HSDPA scheduler is using when allocating

remaining power

2(0.2dB) /1(0.1dB

HSDPA

ChQualoffset

It is the offset added to the adjusted CQI in the NodeB

18(0)

HSDPA

qam64Support

HSUPA

eulMaxShoRate

Support for 64QAM

It sets the maximum EUL rate in soft handover. It is quantized for 10ms or 2ms
UEs. If the value is set higher than the maximum for 10ms tti, then it is
quantized to the maximum for 10 ms

HSUPA

eulNonServHwRate

The amount of hardware resources (in terms of a bit rate) that dynamically may
be allocated, to a non-serving E-DCH radio link for processing scheduled data.
If scheduled rate > eulNonServHwRate, no macrodiversity gain is obtained

128 / 384

eulNonServingCellUsersAdm

Admission threshold for the number of E-DCH users having this cell as nonserving cell.When the number of E-DCH non-serving users in the cell is on the
limit set by this parameter, a reconfiguration of one of these users from 10ms
TTI EUL to 2ms TTI EUL will be rejected and the connection will be
reconfigured to DCH/HS.

100

HSUPA

Used as a switch to turn, the Dynamic Code Allocation feature, on or off by

setting its value to true or false enable code multiplexing between users in the
same TTI
Parameter that defines the maximum number of HS-PDSCH codes that are
allocated in a cell

60/80
6 dB / 8 dB
2,3
TRUE
15

5760

numHsScchCodes & numHsPdschCodes

numHsScchCodes
64 cells in DLVKP01 RNC were having numHsScchCodes = 1 and hence code multiplexing was
disabled in these cells
Impact:
Less Cell throughput
Under utilization of code and power per TTI in case UE categories which dont support 15
codes are scheduled
Combined setting of numHsScchCodes=1 and 64 QAM limits the maximum number of
codes that can be used to 13. So although 14 codes are available per sector but only 13 will
be utilized.

114 cells have

numHsPdschCodes<=3

Trade off: If the value of this parameter is too high, then

non HS traffic may suffer from unnecessary code
congestion.
If the value of this parameter is too low, HSDPA
throughput can be impacted.
In networks with high non-HSDPA traffic it is often
beneficial to reduce the setting compared to the normal
setting.

Too low value like 3 or less will impact HS

performance in cells having high R99 traffic.

eulNonServingCellUsersAdm
56 Cells in DLVKP01 RNC had eulNonServingCellUsersAdm <=10

56 cells have
eulNonServingCellUsersA
dm<=10

Recommended value of eulNonServingCellUsersAdm is

100

Maximum allowed EUL

serving cell
users(2ms/10ms) are 56
but admission of these
users are limited by
eulNonServingCellUsers
Adm
Impact:
Users who will be in
soft/softer HO with
atleast one of these 56
cells, EUL services will not
be available most of the
time
More users will be in
DCH/HS or DCH/DCH,
which increase the UL
R99 utilization

UL-RSSI

RLS procedure timeout

Poor UL RSSI and EC/No leads to high no. of RLS procedure timeouts and call drops

Other Parameters to improve UL RSSI

Parameter

Description

Recommended Settings

Remarks

-21 to -27

If set too small, the preamble initial transmit power

may be insufficient for reliable detection at the Node
B. This leads to a delay in the access procedure. If
set too large, the preamble initial transmit power
may be larger than needed for reliable detection at
the Node B. This causes unnecessary uplink
interference

ConstantValuePRACH

Constant value in dB used by the

UE to calculate the initial power on
the PRACH according to the Open
Loop Power Control procedure

deltaAck1

The power offset for

acknowledgement message on
HS-DPCCH when there is only
one radio link set in the active set

3dB/4dB

deltaCqi1

The power offset for the CQI report

message on the HS-DPCCH when
there is only one radio link set in
the active set

3 dB/4dB

deltaNack1

The power offset for nonacknowledgement message on

HS-DPCCH when there is only
one radio link set in the active set

4 dB

SirMax

The uplink SIR is limited by sirMax

for 10 ms users

100(10 dB)

SirMaxTti2

The uplink SIR is limited by sirMax

for EUL 2 ms users

120 (12 dB)

ulInitSirTargetLow
ulInitSirTargetSrb

Initial UL SIR target for RABs

having SF 32
Initial UL SIR target for standalone
SRB

If set too low, the probability of misdetecting an

ACK for a NACK or a DTX bit increases, causing
unnecessary retransmissions and degrading the
throughput. If set too high, the peak to average
power ratio increases. Moreover, uplink capacity is
wasted
If set too high, uplink capacity is wasted. If set too
low, CQI detection accuracy at the Node B may be
negatively impacted resulting in reduced system
capacity
If set too low, the probability of misdetecting a
NACK for an ACK is too high, necessary
retransmissions do not occur at the MAC-hs level,
thus causing retransmissions at the RLC level
which increase packet latency. If set too high, the
peak to average power ratio is increased.
Moreover, uplink capacity is wasted
Optimal settings for these parameters are important
to assure that the OuterLoop Power Control can
maintain the wanted retransmission rate for EUL
Optimal settings for these parameters are important
to assure that the OuterLoop Power Control can
maintain the wanted retransmission rate for EUL

20 (2dB)

----

30 (3dB)

----

Summary

Poor EC/No & RSCP

Potential missing neighbors

Power Congestion
Incorrect power parameter
settings
Admission thresholds
High CPICH power
Missing Neighbors
Improper neighbor
additions/deletions.
UL RSSI
High # of R99 users using
128/384 Kbps.
High UE Tx power due to poor
coverage.
Longer duration in compressed
mode,
RACH related parameters

IRAT

DCR

Pilot pollution

High UE Tx power
UL RSSI
Poor Coverage
Low service offset for
PS only RABs

THROUGHPUT

Low CPICH power ratio

Incorrect Service offsets for CS+PS

Multi Rab

Poor EC/No and RSCP

Low CPICH power ratio
Potential missing neighbors
Pilot pollution

Poor EC/No & RSCP

Low CPICH power ratio
Potential missing neighbors
Pilot pollution

HS Codes and power related parameter

settings
Leading to less remaining
power for HS services
Incorrect scheduler algorithm
Incorrect common channels
power

KEY 3G FEATURES

CPC CONTINUOUS PACKET CONNECTIVITY

Description
With the introduction of CPC, the DPCCH channel in UL and HS-SCCH channel in DL is sent and received discontinuously by the UE,
resulting in the reduction of UL RSSI and improved battery life.
CPC capable UE can now remain inactive in Cell_DCH state for longer time, and can restart transmission with much shorter delay and
also reduces the # of channel switching between DCH and FACH.
A new HSDPA inactivity timer: hsdschInactivityTimerCpc is introduced for CPC users and its value can be set higher than
hsdschinactivity Timer which is for non-CPC users.
By setting the hsdschInactivityTimerCpc parameter to a high value, the CPC UE stays longer on CELL_DCH before switching down to
CELL_FACH at inactivity
This feature has UE dependency and is supported in Rel-7 and later handsets
.

Fast Dormancy Timers

HS-DCH
Downswitch threshold
5 Kbps

DL/ULRlcBufUpswitch
256 B

Hs-DSCH inactivity Timer : 2 Sec

FACH
Direct Upswitch to
DCH
(256 Bytes)

Inactivity Timer: 15 Sec

URA_PCH
Inactivity TimerPch: 30 Min

Idle

SRB ON HSDPA

With SRB on HSDPA feature, SRBs can be mapped to HSDPA at call setup. The main impact and advantage is that less DL code and
hardware resources are needed for SRB on HSDPA, when it replaces the normal A-DCH channel.
Up to 10 separate SRB on HSDPA connections can be mapped onto one SF256 in DL, compared to that each A-DCH connection
requires one DL SF256. Internally this is implemented by each connection using different time positions, using F- DPCH function

Parameter

Description

extraHsScchPowerForSrbOnH Extra power used for HS-SCCH for a user with SRB on HS. Relative to the output
sdpa
from the HS-SCCH power control.

Recommended
Settings
2dB

extraPowerForSrbOnHsdpa

Extra power used for sending the data during a HSDPA TTI which includes SRB
data. Relative to the output from the HS scheduler.

2dB

HsHysteresis1d

HS cell change failures and procedure timeouts can increase with SRB on HS.
Decreasing the value will make early cell change before Ec/No severly degrades

3dB

Admission block redirection to GSM

Description

Triggered when SRB or Speech RAB is

RRC setup from Idle

blocked
SRB Admission Block

IFLS

Move user to another to GSM

RRC stage: If originating speech calls are

Originating speech call only

Admission Control
Redirect to GSM

blocked by RRC admission control, then UE is

GSM

redirected to GSM via idle mode.

AdmBlockRedirection.Gsmrrc= Off/On

SRB established

RAB stage: Only applicable if RAB admission

Speech RAB
Admission Block

control blocks the call. For this blind HO is used.

After failed HO to GSM, call will be dropped

RAB Admission
Blind HO

AdmBlockRedirection.speech= Off/On

Call is established in WCDMA

GSM

Directed Retry to GSM

Directed Retry will off-load traffic from the WCDMA RAN to a co-sited GSM RAN

A speech call that has no ongoing packet connection is the only service that is targeted since it
is also the only one that is safe to divert to GSM.

Triggered by D/L transmitted power only

The decision is triggered by a RAB Assignment Request from the core network. This message
contains the information needed to identify the call as a speech only call. incoming calls are
screened for suitable candidates according to following criteria.

Parameters:
LoadSharingDirRetryEnabled: TRUE
DirectedRetryTarget: One GSM target can be defined for each WCDMA cell via the cell parameter.
LoadsharingGSMThersold specifies the minimum load at which offloading to GSM begins.
Example: 85% of pwradm

above the 50% of pwradm

0- always on
100- always off
50- offloading starts as soon as the cell load rises

LoadSharingGSMfraction specifies the %age of Directed retry candidates to be diverted to GSM

while the cell load is above the specified load threshold.
0-No diversion
100-All are qualified for diversion.

Load Based HO
Load Based Handover feature provides the possibility to move speech users
to GSM or another UMTS carrier when the load in a cell is at admission level
or above.
If admission control algorithm detects high load when evaluating an
admission request in a cell, then LBHO to GSM for speech users will be
triggered.
The following load quantities are evaluated:
 Power load
 Codes
 DL/UL CE

If the high load is detected for at least one of the load quantities in the cell
and there is new incoming call, one or several ongoing speech connections
will be selected for GSM HO attempts.
Selected UE will be instructed to perform measurements for these GSM
cells (i.e. non-blind HO). If the UE detects and reports a good-enough GSM
cell, the handover attempts will be triggered.

USE CASES

Dataset required for troubleshooting

Performance counters and KPIs: Used for identifying worst cells and high level
causes of degraded KPIs
WMRR(2 hour Busy hour): Was used to get coverage and quality estimations for
the network for each RAB configuration separately
Parameter dump: Was used for getting network parameters and configuration
settings. Was used to see the licensed and activation status of various features
of the RAN release.
GPEH(2 hour busy data): GPEH data was used for in-depth analysis of all issues
by looking at Internal events and external signaling messages.
INVH dump/Hardware configurations: was used for baseline check of some of the
hardware dependent parameters.

ECIO DISTRIBUTION- 4 RNCS

In DLGGN01: 34 % cells having more than 25 % samples( < -14 dB) during busy hour
In DLVKP01: 38 % cells having more than 25 % samples( < -14 dB) during busy hour
In DLOKL01 : Only 10 % cells having more than 25 % samples( < -14 dB) during busy hour
In DLGGN02: 13.11 % cells having more than 25 % samples( < -14 dB) during busy hour

This shows that DLGGN01 and DLVKP01 RNCs have very high poor EcIo samples than other
two RNCs

RSCP Distribution- 4 RNCs

In DLGGN01: 25 % cells having more than 15 % samples( < -99 dBm) during busy hour
In DLVKP01: 44 % cells having more than 15 % samples( < -99 dBm) during busy hour
In DLOKL01 : 46 % cells having more than 15 % samples( < -99 dBm) during busy hour
In DLGGN02: 40 % cells having more than 15 % samples( < -99 dBm) during busy hour

RSCP of DLGGN01 is good as compared to other 3 RNCs.

UL RSSI Distribution- 4 RNCs

In DLGGN01: 25% cells in RNC is having average RSSI > -95dBm in busy hour
In DLVKP01: 9.3 % cells in RNC is having average RSSI > -95dBm in busy hour
In DLOKL01 : Only 1.4 % cells in RNC is having average RSSI > -95dBm in busy hour
In DLGGN02: 5.2 % cells in RNC is having average RSSI > -95dBm in busy hour

Summary-IRAT Rate
In DLGGN01, DLVKP01 and DLGGN02 majority of compressed mode are
triggered because of poor EcIo
In DLOKL01 majority of compressed modes are triggered because of poor RSCP
For CS+PS multiRAB configurations, % of Compressed modes due to UE Tx
power are very high.
Very low CPICH power settings are observed for the cells having high IRAT rate
Serviceoffset for EcIo for PS only services has been recently changed in the
network from -7 to -4. This has increased the % of EcIo driven compressed
modes and no of IRATs for PS only configuration which were earlier RSCP
driven.
Current IRAT trigger thresholds for CS is -15 dB for EcIo and -110 dBm for RSCP.
At very low CPICH settings and at very high loading, EcIo degradation will be
high and hence the IRAT rate.
Lower CPICH settings will also increase RSCP based trigger.

Summary-CS DCR Rate

CS DCR of all 4 RNCs are very good. CS call drop rate is about 0.46 % & 0.51 % in RNC
DLOKL01 & RNC DLVKP01 respectively
CS call drop rate is about 0.67 % & 0.49% in RNC DLGGN01 & RNC DLGGN02
respectively
CS-DCR From Network Counters & GPEH logs (Analysis on 4 RNCs)
About 54 % to 63 % of call drops are due to other reason category across all 4 RNCs
About 17 % to 25 % of call drops are accounted for Uplink Sync across all 4 RNCs
DLGGN01 is having very poor UL RSSI.
25% cells in RNC is having average RSSI > -95dBm in busy hour
DLOKL01 is having high percentage of poor RSCP samples than other RNCs
46 % cells having more than 15 % samples( < -99 dBm) during busy hour
DLGGN01 and DLOKL01 is also having high number of drops due to missing neighbors
DLGGN02 is having cells which contributes to very high drops due to congestions
66% of CS drops in network is happening in MultiRAB calls. Out of 66% MultiRAB drops, 42
%drops are captured in CS+PS(0/0).
DLGGN01 is having very high unspecified drops. Analysis of those drops points to the very
high UL RSSI in the cells of DLGGN01
There are very high number of unspecified drops in MultiRAB due to network configuration
issue. Separate case study is presented on this issue.
Besides physical optimization , UL RSSI, IRAT related parameters and call reestablishment
parameters might need tuning.

Summary-HS DCR

It has been observed that poor UL and DL coverage

is the main cause for HS drops. So L3, L2 and L1
timeouts are very high in the network
GGN01 and VKP01 are having high HS DCR than
other two RNCs
Only 4 cells in GGN02 and OKL01 RNC is having
average HS DCR > 3%. Also number of days in
measurement period(7days) where HS DCR was >
3% are less.
54% of HS drops in the network are due to channel
switching
78% of total channel switching drops are due
to L3 procedure timeouts. Out of these L3
procedure timeouts, 84% of procedure
timeouts happened during transition from HS
to FACH alone
~20% of HS drops are due to Layer 2 timeout with
RLC unrecoverable error
~15 % of HS drops are due to hsDschRcLost (L1)
timer expiry
L3 timers for synchronization and non
synchronization procedures are 18 sec and L1 timer
is 9 second. It has been observed that RNC is
keeping the session alive even after L1 timeouts till
18 seconds
RRC and Iu resources will be wasted
It might cause MT call failures

Summary- Cs & PS CSSR

CS CSSR for all 4 RNCs are very good. All RNCs have CS CSSR > 99%. Both CS RRC and CS
RAB success rate is > 99%.
PS CSSR for all 4 RNCs are good. All 4 RNCs have PS CSSR > 98%.
In all the RNCs PS RRC success rate is main contributor for PS CSSR degradation.
DLGGN01 has lowest PS RRC success rate: 97.07%
Out of all call setup failures detected in the RNCs for RRC and RAB, resources admission
failures are very less.
Majority of failures are pegged under After admission category.

92% of total RRC and RAB failures in DLGGN01 and DLVK01 are pegged in After admission category
75% of total RRC and RAB failures in DLGGN02 and DLOKL01 are pegged in After admission category

Admission related failures are very less in the RNCs. Majority of admission failures in all
the 4 RNCs are contributed by few cells only.
Unspecified RRC failures are very high in the network and distributed almost all cells in
the RNC. These failures are pointing towards netwok issue.
Same observation like in HS and CS DCR that L3 timers are keeping context in the RNC
too long after L1 timer expiry is also observed for RAB failures after admission.
There are few Iub related failures are also observed but those are contributed by 2 sites.

IRAT Rate(Key findings)

Compressed mode Trigger distribution

In DLGGN01 ~64 % of
Compressed modes are
triggered because of poor
EcIo
In DLVKP01 ~55 % of
Compressed modes are
triggered because of poor
EcIo
In DLGGN02 ~48% of
Compressed modes are
triggered because of poor
EcIo while in DLOKL01,
majority of CM triggered
because of poor RSCP

Compressed mode Triggers: (DLGGN01-GPEH stats)

For CS+PS MultiRAB

calls, % of CM triggers
due to UE TX power are
very high. UL MAPL for
CS+PS multiRAB will be
lower than CS only, this
might have caused
significantly higher UE Tx
power based trigger for
MultiRAB
For DLOKL01, poor RSCP
initiated CM triggers are
also very high

Top cells- IRAT rate(DLGGN01 &

DLVKP01)

Very high % of EcIo samples< -14dB

Very low CPICH power with respect
to Max power

At 100%
loading

Too low CPICH power ratio(some cells have less than 2 %) is the major reason of very poor EcIo.
CPICH power needs to be tuned in these cells to reduce the IRAT rate. Increase in CPICH should be done with down
tilting and on cluster of cells to minimize the overshooting and capacity blockings.

High UE Tx Power triggered CM in CS+PS

multiRAB states but no IRAT
For CS+PS multiRAB configurations, high number of compressed mode were
triggered due to high UE Tx power % of UE (event 6D)
IRAT handover wasnt always triggered and UE was continuously transmitted at
max power, because RSCP of current used frequency has to be below: -108 + (4) + 5 = -107dBm for 3a event to trigger. This indicates that the UE was not at
edge of coverage and UE Tx power is high due to UL RSSI
Current network configuration to trigger IRAT HO due to Poor UE Tx power is
below:
Serviceoffset2d for CS+PS multiRABs are: -4( for RSCP)
2d threshold RSCP: -108 dBm
utranRelThreshRscp(offset for UE Tx power): 5
As a result of the above configuration UE stays in CM for longer duration and
keeps transmitting at max power
Recommendation is to reduce serviceoffset2drscp for CS + PS multiRABs, so
that possibility of UE trigger early IRAT HO is higher. This will improve UL RSSI
and UEs will stay for shorter time in compressed mode

Serviceoffset for PS services

It has been observed that serviceoffsetecno for PS only
RAB combinations has been recently changed from -7
to -4 which has resulted in very high early compressed
mode trigger at EcIo: -19dB for PS RABs.
It is recommended to delay or disabled the IRAT
handover for PS services.
Trigger quantity
Ecio Trigger for serviceoffset: 0
Rscp Trigger for serviceoffset: -2
UE TX Pwr Trigger for serviceoffset: -2
Rscp Trigger for serviceoffset: -4
Ecio Trigger for serviceoffset: -2
UE TX Pwr Trigger for serviceoffset: -4
Ecio Trigger for serviceoffset: -4
Rscp Trigger for maximum service offset(at -115dBm)
Rscp Trigger for serviceoffset: -10
UE TX Pwr Trigger for serviceoffset: -10

No of CMs Percentage RAB combination

1056
361
153
140
325
309
1552
1032
5
474

19.40463065
CS
6.633590592
CS
2.811466373
CS
2.572583609 CS +PS MultiRAB
5.972069092 CS+PS MultiRAB
5.678059537 CS+PS MultiRAB
28.51892687
PS
18.96361632
PS
0.091877986
PS
8.710033076
PS

Frequent 2d and 2f

Frequent 2d and 2fs

events are observed
in the network even
within in compressed
mode.
Current settings of
hysteresis2d and
hysteresis2f are 0

HS DCR(KEY FINDINGS)

HS drop cause distribution- all 4 RNCs

HS Drop causes
Channel Switching Drops
Maximum number of RLC retransmissions is reached
Radio Connection Supervision - expiry of timer
hsDschRcLostT
Unspecified
Radio link failure indication leading to a release with
cause other than transport
Active Set Update complete message not received addition
High Speed-Downlink Shared Channel (HS-DSCH)
Cell Change failure
Active Set Update complete message not received replacement
Missing neighbor
Cell change outgoing failure Timer T_cellchange
expires
Other Radio Link Control (RLC) unrecoverable error.
Active Set Update complete message not received deletion.
Cell lock indication.
Transport issue
Congestion Failure
IRAT outgoing failure - Timer T_reloc_overall expires
Measurement control faiure

Total

~54 % of HS drops are during state transition

L1 and L2 timeouts contribution is 14.6% and 19.5% resp.

No of
drops
4460
1628
1221
804
73
42
35
27
22
11
10
8
3
3
2
2
1
8352

Sub causes: Channel Switching drops

Channel switching failure: Sub causes

Total no of
drops

PROCEDURE_TIMEOUT

4329

CELL_UPDATE_IN_DRNC

109

Unspecified channel switch failure

NODE_INTERNAL_FAILURE_6

GENERAL_FAILURE_IN_PROCEDURE

REQUESTED_REQUEST_TYPE_NOT_SUPPORTED

NODE_INTERNAL_FAILURE_2

NODE_RESOURCE_NOT_AVAILABLE_1
PROCEDURE_EXECUTION_TERMINATED_EXTERN
AL

1
1

Total

4460

Out of all Channel switch drops 78% of drops are purely Layer 3 procedure timeouts

Sub causes: Channel Switching drops

Procedure timeout
Cause: Procedure Timeout

Percentage of
drops

INACTIVITY(expiry of
hsdschinactivityTimer)

83.8

INCREASE_ACTIVITY_UL

8.8

INCREASE_ACTIVITY_DL

6.2

EUL/HS to EUL/HS(Mobility)

0.8

DECREASE_ACTIVITY_UL

0.3

UL_SOFT_CONGESTION

0.1

FALLBACK_TO_R99

0.1

Out of all L3 procedure timeouts, 83.8% drops are happening during HS to FACH transition
~ 15 % of procedure timeouts are during FACH to HS transition
24.8 % of L3 procedure timeouts are happened at UL RSSI< -95 dBm

Procedure Timeout- Inactivity(Poor UL RSSI)

RBR for
reconfiguring to
FACH

There was no cell

update received
from the UE
probably because
of high UL RSSI

UE was on EUL/HS and due to

inactivity and expiry of
hsdschinactivityTimer, RNC
triggered transition from HS to
FACH by sending RBR message to
UE and started tRrcChSwitch1:
15 sec
Since RNC didnt receive any RRC
Cell Update message from UE
during transition So after 15
seconds Channel switching
procedure failed and call was
released.
This cell was having very high UL
RSSI samples as seen from the
GPEH for that hour. Probably UE
has sent cellupdate but it was
not decoded by RNC due to very
high UL RSSI.

Cause 2: Impact of SRB on HS

Maximum number of RLC
retransmissions is reached

Maximum number of RLC retransmissions is

reached
Current procedure running while L2 Timer
Total drops Percentage
expiry( Total contribution to drops: 19.5%)
HS CELL CHANGE EXECUTION

1018

62.57

INCREASE ACTIVITY UL

228

14.01

EUL2ms to EUL 10ms

140

8.60

RLC failure(L2 timeout) without any ongoing

procedure running

130

7.99

INCREASE ACTIVITY DL

28

1.72

RL_ADDITION

26

1.60

RL_REPLACEMENT

22

1.35

RAB failure after successful admission

13

0.80

FALLBACK_TO_R99

10

0.61

INACTIVITY(hsdschinactivitytimer)

0.31

RL_DELETION

0.25

RANAP_CAUSE_NORMAL

0.18

These category of drops comes

under RLC timed out(maximum
number of RLC retransmissions is
reached)/Radio Link Control (RLC)
unrecoverable error in UTRAN
62% of these drops were happened
when HS cell change procedure was
going on and Physical channel
reconfiguration of change of serving
cell was not acknowledged by UE.
27% of these RLC drops were
happened at UL RSSI < -95 dBm
Since SRB on HS is activated, there is
not any SHO gain for SRB in DL. So
high HS cell change failures are
expected

Case study-HS cell change failures due to RLC timeout(

Very poor EcIo in serving cell)

Averge EcIo(Source cell): -19.18 dB

Average EcIo(Target cell): -13.6 dB

Averge RSCP(Source cell): -92.4 dB

Average RSCP(Target cell): -86.21 dB

Since hsQualityestimate: RSCP and hsHysteresis1d: 5dB so HS cell change is performed if

RSCP of target cell is 2.5(ie.5/2) dB higher than source cell which can be seen from the
above RSCP comparison chart. But in the network at the same time EcIo of source cells
was too low(average: -19.18 dB) that UEs didnt acknowledge Physical channel
reconfiguration and the RLC timed out during HS CC procedures. Since SRB on HS is
activated, there is not any SHO gain for SRB in DL.

Case study-HS cell change failures due to

RLC timeout
MR: 1a

Addition
successful

MR: 1d
HS serving
cell change
started

EcIo of
current
serving cell: 19dB

Call
dropped

UE was on Cellid:58759(EcIo:
-17dB and RSCP: -84 dBm. It
was only cell in the Aset. UE
triggered measurement report
for 1a for cell: 23869(EcIo:-12
dB, RSCP: -78dBm). SHO:
addition was successful
UE now triggered change of
serving cell on the basis of
RSCP and sent measurement
report for 1d
RNC initiated change of
serving cell by sending
PhysicalChannel
Reconfiguration, but
meanwhile EcIo of current cell
became too low( -19dB) that
Physical Channel
Reconfiguration might have
not decoded by the UE.
RNC tried maximum
retransmission before
declaring RLC timeout.
Ongoing Cell change was also
failed and call dropped.

Cause 3:
Radio Connection
Supervision - Expiry of
timer hsDschRcLostT

Radio Connection Supervision - Expiry of timer

hsDschRcLostT
Current procedure running while hsDschRcLostT
Total drops
expired(Total contribution to HS drops: 14.6%)

Radio link Failure without any procedure running

529

HS_CELL_CHANGE_EXECUTED

160

Poor quality detected(2d): EUL2ms to EUL 10ms

141

RAB failure after successful admission

139

RL_ADDITION

100

RL_REPLACEMENT

61

INCREASE_ACTIVITY_UL

33

RL_DELETION

23

INCREASE_ACTIVITY_DL

12

FALLBACK_TO_R99

INACTIVITY(HS to FACH)

RANAP_CAUSE_NORMAL

DECREASE_ACTIVITY_UL

UL_SOFT_CONGESTION

31.4 % of RCS drops are happened at UL

RSSI< -95 dBm
There were also very high number of HS
cell change executions failed during
these L1 procedure timeouts

These drops are due to UL/DL coverage

issue
These drops are pegged due to
L1(hsDschRcLost) timeout
43% of these drops captured were
happened when there was not any L3
procedure was going on
It has also been observed that except
Radio link failure without any procedure
running, in all other calls some L3
procedure was ongoing. L3
timer(18sec/15 sec) values are higher
than L1 timer(9sec). But after L1 timer
expiry network is not releasing the call
till L3 timer expiry of 18 sec. This is
leading to extended call sessions
maintained for the UEs in the network
keeping Iu resources, UE context etc. It
may also impact paging for voice
because UE seems to be in idle while
network will page via DCH (paging
type2) as its session is alive in the RNC.

L3 timer keeping context in RNC too long

Measurement
report 1a

Successful
SHO
Failed Cell
change

Channel
switching
from EUL
2ms to 10
ms
Change of
serving cell

UE triggered SHO for 1a

for cell id: 6165(RSCP 98dBm, EcIo: -13dB)
Since added cell is also
better than serving cell
by 2.5 dB (hshteresis1d)
so RNC tried to change
the serving cell also, but
cell change failed because
of max EUL 2ms users in
the cell
RNC reconfigured the
2ms connection to 10 ms
Then RNC initiated
serving cell change by
sending Physical channel
reconfiguration and
initiated L3 timer(18 sec)

L3 timer keeping context in RNC too long

rlFailureT expired

hsdschRcLost
expired

Serving cell
change failed and
dropped call

Meanwhile in the process of serving cell change,

RF of active set was degraded Cell id1(-22dB, 104dBm), Cell id2(-23 dB, -104dBm) and cell id3(23 dB, -104 dBm).
New cell PSC: 254 became strong ( -7dB, -88dBm)
and UE sent measurement report for 1c.
But since DL was too bad probably UE didnt
receive the physical channel reconfiguration. Poor
DL also triggered RL supervision in UL after
stopped transmission from UE(N313 indication)
First Internal RC supervision gives Radio link
failure (rLFailureT: 1sec expires) indication for all
radio links
Second Internal RC supervision gives the
indication of hsDschRcLost timer: 9 sec in the
RNC. It generates the cause code: overall RRC
connection should be released. Third Internal RC
supervision is the periodic event generated after
expiry of hsDschRcLost and gives the same cause
code. But RNC has not released the call at this
point and waiting for L3 timer(18 sec) to expire.
Finally after expiry of L3 timer(18 sec), RNC
generated failed HS cell change indication and
released the call.

RNC has released this call with cause : L1 timer expiry(from its internal event), but from the
signaling, we can see that RNC didnt release the call after L1 expiry but at L3 expiry. Needs to
check with vendor about this behavior. Since these types of HS drops are high in number, it might
impact paging type 2 success rate.

CAUSE 4:
UNSPECIFIED
DROPS

Unspecified
Unspecified HS drops(Total contribution to RNC drops:
9.4%)

In 88% of unspecified drops RNC generated

the error code:
Requested_request_type_not_supported

Requested_request_type_not_supported:
It has been observed that if in RNC the UE
context for UE is alive but UE initiates the
new call during the same duration, then
RNC releases the old call and the old call
pegs as a drop.

1%
1%
1% 1%

1%

0%
0%

7%

REQUESTED_REQUEST_TYP
E_NOT_SUPPORTED
NODE_INTERNAL_FAILURE_
2
PROCEDURE_TIMEOUT
NOT_APPLICABLE
EXTERNAL_PROTOCOL_ENC
ODING_FAILURE
NODE_INTERNAL_FAILURE_
6

88%

GENERAL_FAILURE_IN_PRO
CEDURE
IUB_AAL2_SETUP_FAILURE
_REMOTE
LOGICAL_ERROR_IN_MESS
AGE

These types of drop behavior confirms that there

are several instants where UE came earlier in idle
mode(by UEs L1/L2) timer expiry and initiate new
interactive sessions before RNC terminate the old
session. RLC timers and parameter values yet to
be received from vendor. Needs to check UEs as
well as RNCs L2 settings if they are aligned with
L1 and L3 settings and if there is scope for
improvement. Also since call reestablishment for
PS is not available in Ericsson W13B and UEs L1
timer: n313(1s)+ T313(5s), possibility of UE
coming in idle mode early because of poor DL is
higher.
RNCs L1 timer: noutsync (100ms) + rlFalureT(1s)
+hsDchRcLost(9s)

CS DCR
(KEY FINDINGS)

CS Call Drop Reasons Distribution per each RNC

RNC DLGGN01 CS Call Drop Reasons
Distribution
Drop call
Drop call IRAT
missing nbr
6%
6%
Drop call soft
handover
3%

Drop call
congestion
0%

Drop call
uplink sync
18%

RNC DLGGN02 CS Call Drop

Reasons Distribution
Drop call
soft
handover
Drop2%
call
IRAT
7%
Drop call
congestion
8%
Drop call
uplink sync
19%

Drop call
other
67%

Drop call
missing nbr
5%

RNC DLOKL01 CS Call Drop

Reasons Distribution
Drop call
soft
handover
3%
Drop call
IRAT
9%
Drop call
uplink
sync
17%

Drop call
missing
nbr
4%
Drop call
congestio
n
0%
Drop call
other
67%

Drop call
other
59%

About 58 % to 63 % of call drops are not defined (other)

across all 4 RNCs
About 17 % to 25 % of call drops are accounted for Uplink
Sync across all 4 RNCs
RNC DLVKPO1 has 12 % of call drops due to IRAT
RNC DLGGN01 has 9 % of call drops due to Soft handover &
missing neighbor
RNC DLGGN02 has 8 % of call drops due to call congestion

RNC DLVKP01 CS Call Drop

Reasons Distribution

Drop call
soft
handover
Drop call
2%
IRAT
12%

Drop call
uplink sync
25%

Drop call
missing
nbr
2%
Drop call
congestion
1%

Drop call
other
58%

Worst cell missing neighbors

(DLGGN01)
Cell
DLFP3BX

N01 missing nbrs

Average of Speech call drop rate % Drop call congestion % Drop call missing nbr % Drop call uplink sync % Drop call IRAT % Drop call soft handover % Drop call other
2.193977444

0%

28%

10%

10%

2%

50%

There were 4
CS call drop
captured during
the recording
period for
DLFP3BX due
to missing
neighbors.
There were 4
different PSCs
detected for
each drop.

Worst cell missing

neighbors(DLOKL01)

OKL01 missing
neighbors

There was not any call drop captured

in GPEH for this cell because there
was not any missing neighbor
detected at greater than 12 dB higher
EcIo relative to serving cell. But there
were 20 samples of two missing
neighbors recoreded at greater than
6dB relative to serving cell.Average
EcIo of these samples were 7.5 dB
higher than serving cell and average
RSCP of these missing neighbors
were 10 dB higher than serving cell.
Cell id identified for these missing
neighbors through site database is
coming more than 3.5 km. So need to
check the overshooting of these cells.
Also needs to check whether some
new cells of the PSC: 83 and 35 came
nearby to serving cell: 41600

Drop due to congestion- Top cell:

DLGGN02

ADCH
signaling

Recommendation: set minPwrMax

for these 2 cells: 0 dB

mimimumRate of 3.7 kbps is for ADCH signaling. For cells with high HSDPA
load (many HSDPA users) the A-DCH power can constitute of a large part
of the used downlink. minpwrmax for these two cells are set to 3 dB
higher than CPICH power(34 dBm). This might be creating high congestion
in these two cells.
Counter stats for these cells shows, these cells have very high HS traffic
and HS RAB attempts. CS traffic is also high in these cells.
HS traffic: ~4 GB per day
HS RAB attempts: ~13000 per day

CS drops due to IRAT failures

Two RNCs: DLVKP01 and DLOKL01 has high IRAT

drops. DLVKP01 has 12% of drops and DLOKL01 has
9% of drops due to IRAT.
Analysis of these drops have common signature that
after triggering IRAT(3G to 2G), UE doesnt
successfully established call in the 2G and also not
able to return back to 3G with in 5 sec of (RNC timer:
tRelocoverall). So RNC releases the call.
RSSI of the target GSM cell in all the failures at the
time of handover is very good(average: -74dBm)
These IRAT failures are distributed across the RNCs
and not only happening in certain cell relations.
Possible reasons for this issue are
UE took longer time to synchronize / remains in
3G for longer time before synchronizing to 2G
and tRelocoverall(5sec) timer expired
Never went to 2G because IRAT HO command
not decoded due to poor DL and after expiry of
tRelocoverall(5sec) call released
Co BCCH/BSIC (ie. BSC has reserved the
resources in wrong cell having same BCCH/BSIC
but UE tried to synchronize on different cell

*Attached is the list of all IRAT Ho failures captured in the

GPEH for 3 worst RNCs(DLGGN01,DLVKP01,DLOKL01)

CS drops due to IRAT

(abnormal call: 1)
MR: 3a(ncc: 6, bcc:5,
bcch: 7)

Resource
reservation in 2G
cell

IRAT HO
command

5
sec

RNC didnt receive any

insync frame from UE. This
means UE probably left the
3G and tried to synchronize
2G

RNC didnt receive Handover complete from the BSC

and UE didnt return to old 3G channel within 5 sec and
call dropped

UE detected poor DL
and triggered MR for
3a for 2G cell
BSC reserved the
resources in the 2G
cell and sent
Relocation Command.
RNC sent
HANDOVER_FROM
UTRAN_COMMAND
and UE attempted
IRAT HO. RNC started
trelocoverall timer of
5sec.
IRAT HO to 3G
probably didnt
successful within 5 sec
and RNC released the
call abnormally.

CS drops due to IRAT(abnormal call: 2)

MR :
3a
Resource
reservation in 2G
cell

Measurement
reports 3a

Serving cell EcIo: 19dB, RSCP: -94

dBm
5
sec

Measurement
reports 3a

Dropped
call

UE detected poor DL and

triggered MR for 3a for 2G
cell
BSC reserved the resources
in the 2G cell and sent
Relocation Command.
RNC sent HANDOVER_FROM
UTRAN_COMMAND and UE
attempted IRAT HO. RNC
started trelocoverall timer of
5sec.
But UE probably didnt
receive the IRAT HO
command due to poor DL
and continuously sending
Measurement reports: 3a
UE didnt leave 3G channel
till 5sec so after 5 sec, since
RNC didnt receive Handover
complete from 2G BSC, it
released the call abnormally

Recommendation
Co BCCH/BSIC needs to be checked for the cells having IRAT failures at
very good 2G RSSI
Since IRAT HO threshold for CS+PS(0/0) -17dB/-112dBm, possibility of
decoding failure of IRAT HO command from the network is higher. IRAT
HO threshold for CS+ PS(0/0) can be aligned with CS only .
Probability of successful IRAT handover in poor coverage can be
improved by increasing trelocoverall to 7 sec, if UE took longer time to
decode IRAT HO command from the network

CS call & MRAB drop distribution

GPEH CS
CS CALL & MRAB DROPS DISTRIBUTION CAPTURED
FROM GPEH
CS Conv--Speech
12.2 + PS Interactive
64--HS
3%

CS Conv.--Speech
(12.2--12.2) + PS
Interact. (16--HS)
21%

CS Conv--Speech
12.2 + PS Interactive
0--0
42%

CS Conv--Speech
12.2
34%

Majority of MRAB call drops captured from GPEH are from CS +PS 0/0
66% of CS drops in network is happening in MultiRAB calls. Out of 66% MultiRAB drops,
42 %drops are captured in CS+PS(0/0).

MRAB analysis

MRAB drops: Below are the major causes of MRAB drops:

Channel Switching: 26.6 %
Procedure Timeout(L1): 20.1 %
Unspecified(majority of CS normal release in high UL
RSSI scenario) : 17.3 %
IRAT trelocoverall (5sec) expiry: 12 %

MRAB-Unspecified drops
Majority of unspecified drops are categorized into two reasons:
1.) Transition to FACH from CS+PS(0/0) failed after user disconnects the call
normally. This type of unspecified drops are not user perceived drops. DLGGN01
has highest percentage of these drops due to very high UL RSSI among cells

2.) Abnormal call released by network at successful HS cell change/successful

channel switching in MRAB. 80 % of unspecified drops in DLOKL01 and DLVKP01
are due to these abnormal releases. This behavior of sudden dropped call points to
network configuration issue.

L1 Procedure timeouts
UTRAN RL failure detection is controlled by the Radio Connection Supervision
(RCS) and Radio Link Set (RLS) Supervision functions: after receiving
nOutSyncInd consecutive frames, UTRAN starts timer rlFailureT. If rlFailureT
expires, the RLS function considers the connection as out-of-sync and report RL
Failure to RNC. When RL Failure is received, the SRNC starts timer dchRcLostT
and if this timer expires the connection is considered lost by RCS. The total time
for UTRAN to detect RL Failure: nOutSyncInd * 10msec + rlFailureT +
dchRcLostT
These drops are due to UL/DL coverage issue
These drops are pegged due to L1(dchRcLostT) timeout
It has also been observed like in HS DCR RCS drops , after L1 timer expiry
network is not releasing the call till L3 timer expiry of 18 sec. This is leading to
extended call sessions maintained for the UEs in the network keeping Iu
resources, UE context etc. It may also impact paging for voice because UE
seems to be in idle while network will page via DCH (paging type2) as its session
is alive in the RNC. These L3 procedures are identified as Active set update,
Radio bearer reconfiguration(multiRAB), HS cell change(multiRAB).

L3 timer keeping context in RNC too long

18
sec

UE was in Poor DL EcIo: -20dB and RSCP 112dBm and triggered event 1a. Network
sent Active set Update.
But since DL was too bad probably UE didnt
decode the Active Set Update. Poor DL also
triggered RL supervision in UL after stopped
transmission from UE(N313 indication)
First Internal RC supervision gives Radio link
failure (rLFailureT: 1sec expires) indication
for all radio links
Other Internal RC supervision gives the
indication of dchrclostT timer: 10 sec in the
RNC. It generates the cause code: overall
RRC connection should be released. But RNC
has not released the call at this point and
waiting for L3 timer(18 sec) to expire.
Finally after expiry of L3 timer(18 sec), RNC
generated failed Soft Handover execution
and released the call.

RNC has released this call with cause: L1 timer expiry(from its internal event). But from signaling, we can see that RNS didnt
release the call after L1 expiry but L3 expiry. Need to check behavior with vendor. Since these types of HS drops are higher in
number, it might impact paging type 2 success rate.

CS & PS CSSR
(KEY FINDINGS)

Admission Vs After Admission Failures

RNC

Count of After
Admission
Failures

Count of
Admission
Failures

DLGGN01

19334

1734

DLGGN02

9125

2836

DLOKL01

19910

6909

DLVKP01

18748

1626

After admission failures

are distributed in all
cells across the RNCs
but majority of
Admission failures are
contributed by few cells
in each RNC.

ADMISSION FAILURES

Admission Failures contribution

Cell- WPROTCX (Admission failure due to lack of

DL CE)
UCell Id

WPROTCX

RNC

DLGGN01

Total RRC and RAB attempts

Total Admission Failure
Admission failures rate
Admission Resource contributor

1959.45

786.55

40.14
DL CE

numHsCodeResources: This parameter reserves the

resource ids available for HSDPA in DUW board. Each
resource id provides
30 HS-PDSCH codes per site

128 CEs for DL R99 including ADCH

Each DUW 20 board provides 5 resource ids out of which 1
resource id is reserved for EUL
Out of remaining 4 resource ids, numHsCodeResources
reserve the resource id for HS which provides codes for HS.
Remaining resource ids will be available for R99 which
provides CEs for DL R99 including ADCH.
Since 1 sector site has 16 HS PDSCH codes, so
numHsCodeResources for single sector site should not be
set greater than 1. If value is set greater than 1 then there
will be shortage of DL CEs in the DL

Cell: WPROTCX

Current site is having only one sector

All Failures are happening because of shortage of DL CE

availableRbsChannelElementsDownlink parameter is showing

value 83. This means that only 83 DL CEs are available from
Hardware limit of 384 DL CEs.

Wrong parameter setting of numHsCodeResources is found in the

cell. Current setting of numHsCodeResources is 3. Recommended
value of numHsCodeResources is 1 for single sector site.

Since site is having DUW 20 board having 5 resource ids. 1

Resource id is reserved for EUL. 3 resource ids are reserved for
HS(numHsCodeResources is 3), So only 1 resource id is left for
R99 service which can provide only 128 CEs in the DL. After
subtracting ADCH reservation CEs, only 83 DL CEs are available
which is too less for a site.

Recommendation: Set numHsCodeResources:1

Cell- CENTRAX and CENTRAY(Admission failure due to

lack of DL Power)
UCell Id

CENTRAX

RNC

DLGGN02

Total RRC and RAB attempts

Total Admission Failure
Admission failures rate
Admission Resource contributor

mimimumRate of 3.7 kbps is for ADCH signaling. For cells with high
HSDPA load (many HSDPA users) the A-DCH power can constitute of a
large part of the used downlink. minpwrmax for these two cells are set
to 3 dB higher than CPICH power(34 dBm). This might be creating high
congestion in these two cells.
Counter stats for these cells shows, these cells have very high HS traffic
and HS RAB attempts. CS traffic is also high in these cells.
HS traffic: ~4 GB per day
HS RAB attempts: ~13000 per day

5402.45
402.18
7.44
Power

ADCH
signaling

Recommendation: set minPwrMax for these 2 cells: 0 dB

AFTER ADMISSION FAILURES

After admission failures: RRC(GPEH

analysis)
PS and CS RRC Failures

Majority of RRC and RAB failures were in the

Failure after admission category. Since
there are not any specific counters are
available to distinguish among these failures,
analysis of these has been done on GPEH
data.
RRC: Unspecified failures are pointing
towards network issue in which without
waiting for the response from the UE, network
is releasing the call after successful
admission.
RRC: Procedure Timeouts are purely
coverage related failures
All Iub setup failures in DLVKP01 and
DLOKL01 are contributed by 1 site in each
RNC.

After admission cause

DLVKP0 DLGGN DLGGN DLOKL0

1
01
02
1

Unspecified

655

1037

380

786

Procedure Timeout

204

457

147

199

IUB_AAL2_SETUP_FA
ILURE

45

30

RRC: Unspecified
Call 1

These type of failures are

very high in the network and
these are not coverage
dependent. RNC is
releasing the calls itself
without waiting the response
of RRC_Connection_Setup
from UE.

UL RSSI: -98 dBm and DL

EcIo: -13dB are also very
good.

Call 2

Need to check with Ericsson regarding these failures

L2 RLC timeout

RNC initiated the RAB

procedure by sending Radio
Bearer Setup to UE but RBS
Complete message is not
received from the UE. UL
RSSI at the time of failure
was: -82 dBm
RNC tried maximum
retransmission before
declaring RLC timeout and
RAB setup was failed

RCS- L1 Timeout
L3 timer keeping context alive despite L1 timeout

RNC initiated the RAB

procedure by sending Radio
Bearer Setup to UE and
started L3 timer of 18sec
but RBS Complete
message is not received
from the UE.
L1 supervision shows that
after getting nOutSync
frames and after expiry
hsdschRcLostT(9sec), RNC
generated event which says
RRC connection should be
released. But RNC is not
releasing the call at this
time and releasing the call
after L3 timer(18 sec).

THANK YOU