CSSR Improvement case

Security Level: Internal

CSSR improvement case analysis

Summary: In country X, Project Y, during the bad cell KPI analysis, we find so many cells have Poor accessibility rate mainly CSCSSR and PS-CSSR. Customer has given target to improve CSSR. Target given by customer for CSSR (CS/PS) >95%
Alarm: whenever we go for Cell level KPI optimization first step must be alarm checking, in my case I have checked alarm and found
no current /history alarm.
RTWP: RTWP checked and I found few sites having high RTWP but these sites have high traffic, RTWP get poor during the high
utilization only. In this case I will explain how to optimize RTWP, coz in case of 3G this is most common problem.
KPI analysis: - when we talk about CSSR, then 2 components are responsible for poor CSSR 1st is RRC and 2nd is RAB.
If any one of them get poor and CSSR will get affected. These components help me to know problem at which stage, either at RRC
or RAB stage.
In case of WCDMA, there is mainly 4 radio resource which limits the accessibility. 1st Power, 2nd CE, 3rd Codes and 4th is IUB.
Power limitation can be DL Power and UL Power limitation.
Same case is for CE & IUB, DL & UL CE limitation, DL & UL IUB limitation.
If we find poor CSSR, then after alarm & RTWP checking, 2nd step which comes in the mind that is congestion. In this case mainly I
will focus on PS-CSSR but if you find CS-CSSR poor then reason for poor CSSR are same for CS and PS are almost same.
Understanding about component involved in CS-PS Radio Access success ratio:Formula for CSSR
= RRC setup success rate * RAB Setup success rate (CS/PS)/ 100
RRC setup success rate (%) = (Number of RRC setup success / Number of RRC connection Attempt)*100
RRC setup success ratio can be for service request or other causes.
For service request: - The RRC Connection Attempt for service Procedure is complete when the RNC receives an RRC
CONNECTION REQUEST message from the UE. The message contains information about one of the following service
types requested by the UE: Conversational Call, Streaming Call, Background Call, Interactive Call, Originating Subscribed Traffic
Call, Emergency Call, High Priority Signaling, Low Priority Signaling, Unknown cause, Call Re-Establishment.RRC setup success
for service procedure complete when RNC receive an RRC CONNECTION SETUP COMPLETE message from the UE.
For other cause: - RRC Connection Attempt for Other reasons Procedure is complete when the RNC receives an RRC
CONNECTION REQUEST message from the UE. The message contains information about one of the following service
Types requested by the UE: Inter-RAT cell re-selection, Inter-RAT cell change order, Registration and Detach. The RRC Setup
Success for Other reasons Procedure is complete when the RNC receives an RRC CONNECTION SETUP COMPLETE message
from the UE.
RAB success ratio formula:Radio access Success ratio= {RRC setup success ratio (Service) + [(CS/PS RAB success)/(CS/PS RAB setup Attempt)]*100}

The RAB Setup Attempt Procedure starts when the CN sends an RAB ASSIGNMENT REQUEST message to the RNC. The
message contains information about one of the following service types: CS Conversational RAB Establishments, CS Streaming RAB
Establishments, PS Conversational RAB Establishment, PS Background RAB Establishments, PS Interactive RAB Establishments,
PS Streaming RAB Establishments. The RAB Setup Attempt Procedure is complete when the RNC receives an RAB ASSIGNMENT
REQUEST message from the CN network. The RAB Setup Success Procedure is complete when the RNC sends to the CN an RAB
ASSIGNMENT RESPONSE message.
PS-CSSR:PS Radio Access success Ratio=RRC setup success ratio*PS RAB setup Success ratio*100 %
The PS RRC Setup Attempt Procedure is complete when the RNC receives an RRC CONNECTION REQUEST message from the
UE. The message contains information about one of the following service types: Originating Interactive Call, Terminating Interactive
Call, Originating Background Call, and Terminating Background Call. The PS RRC Setup Success Procedure is complete when the
RNC receives an RRC CONNECTION SETUP COMPLETE message from the UE.
PS Radio Access Success Ratio (Cell) =RRC Setup success ratio* PS RAB setup success Ratio * 100%
=[(RRC.SuccConnEstab.OrgBkgCall+RRC.SuccConnEstab.OrgInterCall +RRC.SuccConnEstab.TmBkgCall
+RRC.SuccConnEstab.TmItrCall )/(RRC.AttConnEstab.OrgBkgCall+RRC.AttConnEstab.OrgInterCall
+RRC.AttConnEstab.TmBkgCall +RRC.AttConnEstab.TmInterCall )]* [(VS.RAB.SuccEstabPS.Conv+VS.RAB.SuccEstabPS.Str
+VS.RAB.SuccEstabPS.Int +VS.RAB.SuccEstabPS.Bkg )/(VS.RAB.AttEstabPS.Conv+VS.RAB.AttEstabPS.Str
+VS.RAB.AttEstabPS.Int +VS.RAB.AttEstabPS.Bkg )] x 100%
The PS RAB Setup Attempt Procedure is complete when the RNC receives an RAB ASSIGNMENT REQUEST message from the
SGSN in the PS domain, the message contains information about one of the following service types: Conversational services,

CSSR Improvement case

Security Level: Internal

Streaming services, Interactive Services, Background Services. The PS RAB Setup Success Procedure starts when the RNC
receives a RADIO BEARER SETUP COMPLETE message from the UE. This procedure is complete when the RNC sends an RAB
ASSIGNMENT RESPONSE message to the SGSN in the PS domain.

CS-CSSR:CS Radio Access Success Ratio= RRC Setup Success ratio*CS RAB setup success ratio *100%
= [(RRC.SuccConnEstab.OrgConvCall+RRC.SuccConnEstab.TmConvCall +RRC.SuccConnEstab.EmgCall )/
(RRC.AttConnEstab.OrgConvCall+RRC.AttConnEstab.TmConvCall +RRC.AttConnEstab.EmgCall )]*
[(VS.RAB.SuccEstabCS.Conv+ VS.RAB.SuccEstabCS.Str)/(VS.RAB.AttEstabCS.Conv+ VS.RAB.AttEstabCS.Str)] x 100%
Please note that, Streaming call is under both CS & PS. depending upon real time service or non real time service. For example 3G
real time video call is under CS. Whenever you need real time service then have to make circuit switch coz in real time service delay
is not allowed.
The CS RRC Setup Attempt Procedure is complete when the RNC receives an RRC CONNECTION REQUEST message from the
UE. The message contains information about one of the following service types: Originating Conversational Call, Terminating
Conversational Call, and Emergency Call. The CS RRC Setup Success Procedure is complete when the RNC receives an RRC
CONNECTION SETUP COMPLETE message from the UE.
The CS RAB Setup Attempt Procedure is complete when the RNC receives an RAB ASSIGNMENT REQUEST message from the
CN in the CS domain. The message contains information about one of the following service types: Conversational Services,
streaming Services. The CS RAB Setup Success Procedure starts when the RNC receives a RADIO BEARER SETUP COMPLETE
message from UE. This procedure is complete when the RNC sends an RAB ASSIGNMENT RESPONSE message to the CN in the
CS domain.

CSSR Improvement case

KPI Analysis:Possible reason for RRC failure

Possible reason for CS RAB failure

Security Level: Internal

CSSR Improvement case

Security Level: Internal

Possible reason for PS RAB failure

From the Above KPI analysis, we can see the many counter failed in case of PS RAB. Here I will focus on PS _CSSR so my
concern is with RRC and PS RAB failure counters.
Solution:UL CE Congestion (VS.RRC.Rej.ULCE.Cong/ VS.RAB.FailEstabCS/PS.ULCE.Cong)

Most of time you will see RRC or RAB failure due to UL CE congestion, solution given below to solve the UL CE congestion issue
Node B level optimization,
What is CE (Channel Element)?
A band Channel Element is the resource base required in the Node-B to Provide for one voice channel capacity, including the
control plane to Provide for one voice channel capacity, including the control plane signaling, compressed mode, the transmit
diversity and softer handover.
For Ex , in the right picture you can see, compared to DL CE
Consumption in UL is times more. That is the main reason for UL CE
Congestion in 3G
CEs consumption in UL is always greater than DL the reason is, in UL
direction due to diversity Node B BBU card has to do a lot of
manipulations to combine the diversity signals and enhance UL.
This is the main reason behind high consumption of CEs in UL
direction. But in HUAWEI system does not need extra CE for UL
Direction due to diversity may be needed in Ericsson and NSN.
(I am not sure)

If you are wondering why UL CE is bigger than DL CE?

In UL, HSUPA uses a lot of CE, PS R99 uses CE, voice uses CE
In DL, HSDPA does not use CE, PS R99 uses CE, voice uses CE.

UL: No. CE support on the each Node B, interference, Node B sensitivity

DL: No. CE support on the each Node B, Iub interface, capacity, power DL, OVSF,

I hope now we have clarity that why there is more UL CE Congestion rather than DL CE.

CSSR Improvement case

Security Level: Internal

If congestion is spread among different hours and days, and on the same Node-B, the following parameters can be used to
decrease the usage of UL CEs
UlMidRateThd (DCCC): Uplink Mid Bit Rate Threshold.
UlDcccRateThd (DCCC): Uplink Bit Rate Threshold for DCCC.
UlFullCvrRate (DCCC): Uplink Full Coverage Bit Rate.
UlGBR (USERGBR): Uplink GBR for BE service.
UlRateDnAdjLevel (DCCC): set to 3_Rates can be reduced to 2_Rates.
UlRateUpAdjLevel (DCCC): set to 2_Rates can be increased to 3_Rates.
Other Option:
Decrease the Max Bit Rate
Shift R99 traffic HSPA
Reduce Initial bit Rate from 64 to 32kbs
Enable the DCCC Algorithm
Enable cell & Node B credit LDR with first action as BE rate reduction & if your network is having multiple frequencies then 2nd
action as inter frequency load ho.
Change HSUPAINITIALRATE from D64 to D32.
Change UL & DL GBR to D32 by command SET UUSERGBR.
Step1- Check if uplink CE utilization is balance between different groups
We can create template in M2000 to check the utilization for CE groups. This utilization is reference for CE group balance.
We can check Baseband resource group balancing by using M2000. To check to BB resource group at node b level we can
use LST LOCELL command and after knowing group we can have knowledge about which group have high UL CE congestion
and then we can do UL BB grouping balancing by shifting Cell from one highly congested group to lower congested group and
distribute traffic among different baseband group.
Step -2, Modify ULTTICREDITSFRESTHD to 4SF4 or 8SF4
MOD UCELLLDR: CELLID=1, ULTTICREDITSFRESTHD=4SF4;
MOD UNODEBLDR: NODEBNAME="aaa", ULTTICREDITSFRESTHD=4SF4;
Step-3 , Active NODEB LDR switch
How to set LDR algorithms:
a) ADD NODEBALGOPARA : NodeBLdcAlgoSwitch=NODEB_CREDIT_LDR-1; (Node B level)
b) SET LDCALGOPARA: LdcSwitch=NODEB_CREDIT_LDR_SWITCH-1; (NodeBlevel)
c) ADD CELLALGOSWITCH: NBMLdcAlgoSwitch=CELL_CREDIT_LDR-1; (Celllevel)
d) MOD UNODEBALGOPARA: NODEBNAME="aa", NODEBLDCALGOSWITCH=NODEB_CREDIT_LDR1&LCG_CREDIT_LDR-1;
If we enable the LDR algorithms, and DCCC Algorithm should be enable at the same time. How to set the DCCC algorithms:
a) SET CORRMALGOSWITCH: ChSwitch=DCCC_SWITCH-1; (RNC level)
b) BE service reduction: ADD CELLLDR: CellId=11111,UlLdrFirstAction=BERateRed, UlLdrSecondAction=NoAct;
Step-4 Modify LDR threshold and ULLDRBERATEREDUCTIONRABNUM
RNC Level Optimization:
Step -1
Level

Command

RNC

SET UUSERGBR

Parameter
ULGBR

Current Value
D64

Recommend
Value
D32

Remark
Improve CE congestion

Step-2
We can change the HSUPA initial rate to improve the UL CE congestion
Level
RNC

Command
SET UFRC

Parameter
HsupaInitial
Rate

Current Value
D256

Recommend
Value
D64

Remark
HSUPA Initial rate

CSSR Improvement case

Security Level: Internal

Step-3
Enabling LDR Algorithms to Reduce the CE Congestion Case

Level

Command

RNC

SET ULDCALGOPARA

RNC

SET ULDCALGOPARA

RNC

SET ULDCALGOPARA

Parameter

Current
Value

Recommend
Value

LDCSWITCH_NODEB_CREDIT_LDR_SWITC
H
LDCSWITCH_LCG_CREDIT_LDR_SWITCH
LDCSWITCH_LC_CREDIT_LDR_SWITCH

Remark
LDR
Switch
LDR
Switch
LDR
Switch

Step-4
To improve CE congestion we can modify the DCCC thresholds.

Level

Command

RNC

ULDCCCRATETH
D

Parameter
SET UDCCC

Current Value

Recommend
Value

D64

D32

Remark
DCCC Threshold

Note: - If above solution not helped much in UL CE congestion Optimization then we can make request to customer to increase the
WBBP board on site. By this way we can increase the CE capacity and problem will get resolved.
Solution:UL Power Congestion (VS.RRC.Rej.ULPower.Cong, VS.RAB.FailEstabCS/PS.ULPower.Cong)
This is most important cause of degrading CSSR (CS/PS), most of time you will see KPI get affected due to UL Power Congestion.
HUAWEI system has ENU (Total Equivalent user Number) feature, we can change this setting, and Maximum ENU value is 200.
If you see in the system this ENU value already 200 then we can switch off the algorithm and see the result.
As per my understanding, if we switch of Algorithm, what happened, the entire user will get access and will be no control based on
ENU, but now system will check RTWP and CAC will be based on RTWP. If after getting more user access RTWP maintained then
rejection due to UL power congestion will be reduced and CSSR (CS, PS) will get improved, if RTWP get worst, then what will
happened there will be more RAB rejection due to UL power congestion and CSSR will get worst. This measurement will be done by
RNC based on ENU load factor, RTWP and threshold set in the RNC. RNC will keep comparing the threshold and actual loading
factor, based on this make decision. In UL measurement is based on RTWP while in DL measurement based on TCP. In case of
rejection due to UL power congestion means level of UL interference or load.
(ENU total + ENU New)/ENU Max= loading factor
In HUAWEI system, in case of UL, ALGORITHM_SECOND is used which is based On ENU, That means Call Admission control
based on the Equal user number.
As soon as user keep increasing we keep increasing the ENU, but limit is 200, till 200 CAC work. But if still user counts increase
then it get rejected due to parameter setting or Algorithm setting.
If we turn off algorithm then there will be no restriction of call admission control in UL. System will keep accepting the call unless
system gets congested. In HUAWEI system we have 4 kind of algorithm.
ALGORITHM_OFF: Disable uplink call admission control algorithm.
ALGORITHM_FIRST: The load factor prediction algorithm will be used in uplink CAC.
ALGORITHM_SECOND: The equivalent user number algorithm will be used in uplink CAC.
ALGORITHM_THIRD: The loose call admission control algorithm will be used in uplink CAC.
Note: - After changing ENU Value, we must monitor the RTWP. If RTWP get affected then Other KPI will get affected and not a good
idea to continue with changed ENU Value.
Step -1, to change the ENU Value

CSSR Improvement case

Level

Command

CELL

MOD UCELLCAC
MOD
UCELLALGOSWI
TCH

CELL

Security Level: Internal

Parameter

Current Value

Recommend
Value

ULTOTALEQUSERNUM

160

200(max)

NBMULCACALGOSELS
WITCH

ALGORITHM_
ON

ALGORITHM_O
FF

Remark
Equivalent user
Number
CAC Algorithm

Step-2, we can change Uplink LDR threshold to improve the UPLINK Congestion.
Level

Command

CELL
CELL

MOD UCELLLDM
MOD UCELLLDM

Parameter

Current Value

ULLDRTRIGTHD
ULLDRRELTHD

55
45

Recommend
Value
45
35

Remark
UPLINK Congestion
UPLINK Congestion

DL Power Congestion (VS.RRC.Rej.DLPower.Cong,VS.RAB.FailEstabCS/PS.DLPower.Cong)

If site is heavily utilized then you will see CSSR get affected due to DL power congestion. We can optimize downlink
power congestion somehow with parameters but not much. Some step is given below to optimize the Downlink
power congestion.
Step1- Balance traffic between carriers ( i.e. F1,F2,F3)
A)

Check inter frequency neighbor :

IDLEQOFFSE
T2SN

BLINDHOFLAG

HOCOVPRIO

TRUE

For Example: IDLEQOSSFET2SN: F1 to F2/F3: IDLEQOSSFET2SN -50, F2/F3 to F1: IDLEQOSSFET2SN 50, if congestion,
it can be modified to 0;
Between F2 and F3: IDLEQOSSFET2SN 0
B)

WBBP board abnormal issue:

1) Cell enables DC-HSDPA;
2) F1, F2, F3 are not balance on HSDPA number;
3) HSDPA number is less than HSUPA number
If you meet above problems, please reset WBBP board in NODEB, Not in RNC!

Step-2, Check DRD

Add UCELLDRD
SERVICEDIFFDRDS
WITCH

LDBDRDSWITCH
DCH

LDBDRDSWITCHH
SDPA

LDBDRDCHOICE

OFF

OFF

ON

User Number

ADD UCELLCAC

CSSR Improvement case

Security Level: Internal

MAXHSDPAUSERN
UM
96

Note -F1:F2:F3: set to same value on MAXHSDPAUSERNUM, such as 128:128:128

Step-3 Increase CAC Threshold (MOD UCELLCAC)
Level

Command

CELL
CELL
CELL
CELL
CELL

MOD
MOD
MOD
MOD
MOD

Parameter

Current Value

DLCONVAMRTHD
DLCONVNONAMRTHD
DLOTHERTHD
DLHOTHD
DLCELLTOTALTHD

UCELLCAC
UCELLCAC
UCELLCAC
UCELLCAC
UCELLCAC

80
80
75
85
90

Recommend
Value
85
85
80
90
93

Remark
Downlink
Downlink
Downlink
Downlink
Downlink

Power
Power
Power
Power
Power

CAC
CAC
CAC
CAC
CAC

Script: MOD UCELLCAC: CELLID=XXXXX, DLCONVAMRTHD=85, DLCONVNONAMRTHD=85, DLOTHERTHD=80,

DLHOTHD=90, DLCELLTOTALTHD=93;

If still congestion, we can consider to deploy command:

MOD UCELLCAC: CELLID=XXXXX, DLCONVAMRTHD=90, DLCONVNONAMRTHD=90, DLOTHERTHD=85,
DLHOTHD=95, DLCELLTOTALTHD=95;

Step-4, Modify LDM (MOD UCELLLDM)

DLLDRTRIGTH
D

DLLDRRELT
HD

55

45

Step-5, Modify CELLLDR

DLLDRFIRSTACTION

DLLDRSECONDACTION

DLLDRTHIRDACTION

InterFreqLDHO

BERateRed

CodeAdj

Step-6, Reduce Common channel power:

Level

Command

CELL

MOD UCELL

CELL

MOD UCELL

CELL

MOD UCELL
MOD
UCHPWROFFSET
MOD

CELL
CELL

Parameter

Current Value

Recommend Value

PSCHPower

-5

-8

SSCHPower

-5

-8

BCHPower

-2

-5

AICHPowerOffset

-6

-9

PICHPowerOffset

-7

-10

Reduce
power
Reduce
power
Reduce
power
Reduce
power
Reduce

Remark
Common channel
Common channel
Common channel
Common channel
Common channel

CSSR Improvement case

Security Level: Internal

UCHPWROFFSET
CELL

MOD UPCH

PCHPower

-2

-5

power
Reduce Common channel
power

Note: These parameters will impact paging success rate

Step-7, Limit R99 PS power: (MOD UCELLRLPWR)
CNDOMAINI
D
PS_DOMAIN
PS_DOMAIN
PS_DOMAIN

MAXBITRAT
E
64000
128000
384000

RLMAXDLP
WR
-20
-20
-20

Step-8, change downlink LDR thresholds, LDM parameter changing to make UE entry LDR status quicker
Level
CELL
CELL

Command
MOD UCELLLDM
MOD UCELLLDM

Parameter
DLLDRTRIGTHD
DLLDRRELTHD

Current Value
70
60

Recommend Value
55
45

Remark
Downlink Congestion
Downlink Congestion

Code Congestion (VS.RRC.Rej.Code.Cong/ VS.RAB.FailEstabCS/PS.Code.Cong)

Number of HS-PDSCH Codes:
The maximum number of codes is dependent on license of the network. The maximum number of HS-PDSCH codes
can reach 15 codes but increasing this number from the RNC will increase the probability of code blocking,
especially if manual allocation is configured. This is why a dynamic code allocation can be used to avoid code
blocking. This will set minimum and maximum number of codes with dynamic allocation.
Some vendors add code adjustment algorithms to support the dynamic allocation and avoid blocking.
HS Power:
PHS = P max - P non-HS - hsPowerMargin [dB]
As shown in the equation above, the HS power is the remaining power after removing the Non-HS power from the
maximum power. Usually an HS power margin is used to control the HS power.
We can set it to zero and leave all the remaining power to HS (but this is not recommended). The better action is to
optimize this margin case by case to provide more power for HS and avoid any power shortage.
We can also note here that increasing the pilot power will also help in allocating less power to traffic channels
(including HS) and this can affect the throughput.
Note: HS-Power Margin is relative to the maximum available power of the cell.
To improve the code congestion we can borrow 1 or 2 codes from the minimum HSPDSCH code value.
Action: Change Min HSPDSCH Code number from 5 to 3 or 4.
Script: MOD UCELLHSDPA: CELLID=XXXX, ALLOCCODEMODE=Manual, HSPDSCHCODENUM=3;
IUB Congestion (VS.RRC.Rej.UL/DLIUBBand.Cong, VS.RAB.FailEstabPS.UL/DLIUBBand.Cong)
Mainly IUB congestion get occur due to high traffic, in that case first action must be to increase the IUB capacity. If
customer is capacity limited then we can reduce traffic by load balancing between cells. Or we can make down tilt
to those sectors which have high utilization.
RTWP Optimization:
During my analysis, I dont find direct counter by which I can understand CSSR failure due to RTWP issue. But still
whenever we get KPI degradation first thing I do, check alarm and RTWP. If site have RTWP then we have to analyze
what is the reason behind bad RTWP.

CSSR Improvement case

Security Level: Internal

RTWP can be poor due to high traffic. There are some parameters by which we can optimize that cell that have bad
RTWP due to high traffic.
Cell level optimization
Level
Command

Parameter

Current Value

Recommend Value

-20

-30

CELL

MOD
UPRACHUUPARA
S

Constantvalue

CELL

MOD
UPRACHUUPARA
S

PowerRampStep

CELL

MOD
UPRACHUUPARA
S

PreambleRetransMa
x

20

40

CELL

ADD URACH

Mmax

8,3

CELL

ADD URACH

NB01max

10,0

10

Remark
Modify this value for high
RTWP cells only which
was caused by high
traffic
Modify this value for high
RTWP cells only which
was caused by high
traffic
Modify this value for high
RTWP cells only which
was caused by high
traffic
Modify this value for high
RTWP cells only which
was caused by high
traffic
Modify this value for high
RTWP cells only which
was caused by high
traffic

RNC level optimization

Level
RNC

RNC

RNC

RNC

RNC

RNC

Current
Value

Recommend
Value

UM_RRCRELCMP_RLDEL_DELAY_SWIT
H

Improve RTWP

BeThd6A1

Improve RTWP

BeThd6B1

Improve RTWP

BeThd6A2

Improve RTWP

BeThd6B2

Improve RTWP

RESERVEDSWITCH0_RESERVED_SWITC
H_0_BIT2

Improve RTWP

Command
SET
URRCTRLSWIT
CH
SET
UEDCHTTIREC
FG
SET
UEDCHTTIREC
FG
SET
UEDCHTTIREC
FG
SET
UEDCHTTIREC
FG
SET
UCORRMPARA

Parameter

Understanding of counter relationship

Remark

CSSR Improvement case

Security Level: Internal

Suggestion:- I have tried to describe the all the case which I faced during my project work. I hope this document will help you to
solve the CSSR issue. I suggest , before change the parameter , make proper Change request and take approval from Technical
director , supervisor , customer etc. also make sure parameter change doesnt no impact at live network if have impact at live
network then change only in night time during wee hours only. thank you