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 CS-
CSSR 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 Security Level: Internal

KPI Analysis:-

Possible reason for RRC failure

Possible reason for CS RAB failure

 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_LDR-
1&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

Recommend
Level Command Parameter Current Value Remark
Value
RNC SET UUSERGBR ULGBR D64 D32 Improve CE congestion

Step-2

We can change the HSUPA initial rate to improve the UL CE congestion

Recommend
Level Command Parameter Current Value Remark
Value
HsupaInitial
SET UFRC D64 HSUPA Initial rate
RNC Rate D256
 CSSR Improvement case Security Level: Internal

Step-3

Enabling LDR Algorithms to Reduce the CE Congestion Case

Current Recommend
Level Command Parameter Remark
Value Value
LDCSWITCH_NODEB_CREDIT_LDR_SWITC LDR
RNC SET ULDCALGOPARA H 0 1 Switch
LDR
LDCSWITCH_LCG_CREDIT_LDR_SWITCH
RNC SET ULDCALGOPARA 0 1 Switch
LDR
LDCSWITCH_LC_CREDIT_LDR_SWITCH
RNC SET ULDCALGOPARA 0 1 Switch

Step-4

To improve CE congestion we can modify the DCCC thresholds.

Recommend
Level Command Parameter Current Value Remark
Value
ULDCCCRATETH
DCCC Threshold
RNC D SET UDCCC D64 D32

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 Security Level: Internal

Recommend
Level Command Parameter Current Value Remark
Value
Equivalent user
CELL MOD UCELLCAC ULTOTALEQUSERNUM 160 200(max) Number
MOD
UCELLALGOSWI NBMULCACALGOSELS ALGORITHM_ ALGORITHM_O CAC Algorithm
CELL TCH WITCH ON FF

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

Recommend
Level Command Parameter Current Value Remark
Value
CELL MOD UCELLLDM ULLDRTRIGTHD 55 45 UPLINK Congestion
CELL MOD UCELLLDM ULLDRRELTHD 45 35 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 carrier’s ( i.e. F1,F2,F3)

A) Check inter frequency neighbor :

IDLEQOFFSE
T2SN BLINDHOFLAG HOCOVPRIO

0 TRUE 0

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 LDBDRDSWITCH LDBDRDSWITCHH

WITCH DCH 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)

Recommend
Level Command Parameter Current Value Remark
Value
CELL MOD UCELLCAC DLCONVAMRTHD 80 85 Downlink Power CAC
CELL MOD UCELLCAC DLCONVNONAMRTHD 80 85 Downlink Power CAC
CELL MOD UCELLCAC DLOTHERTHD 75 80 Downlink Power CAC
CELL MOD UCELLCAC DLHOTHD 85 90 Downlink Power CAC
CELL MOD UCELLCAC DLCELLTOTALTHD 90 93 Downlink Power 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 DLLDRRELT
D HD

55 45

Step-5, Modify CELLLDR

DLLDRFIRSTACTION DLLDRSECONDACTION DLLDRTHIRDACTION

InterFreqLDHO BERateRed CodeAdj

Step-6, Reduce Common channel power:

Level Command Parameter Current Value Recommend Value Remark

Reduce Common channel
PSCHPower -5 -8
CELL MOD UCELL power
Reduce Common channel
SSCHPower -5 -8
CELL MOD UCELL power
Reduce Common channel
BCHPower -2 -5
CELL MOD UCELL power
MOD Reduce Common channel
AICHPowerOffset -6 -9
CELL UCHPWROFFSET power
CELL MOD PICHPowerOffset -7 -10 Reduce Common channel
 CSSR Improvement case Security Level: Internal

UCHPWROFFSET power
Reduce Common channel
PCHPower -2 -5
CELL MOD UPCH power

Note: These parameters will impact paging success rate

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

CNDOMAINI MAXBITRAT RLMAXDLP

D E WR
PS_DOMAIN 64000 -20
PS_DOMAIN 128000 -20
PS_DOMAIN 384000 -20

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

Level Command Parameter Current Value Recommend Value Remark

CELL MOD UCELLLDM DLLDRTRIGTHD 70 55 Downlink Congestion
CELL MOD UCELLLDM DLLDRRELTHD 60 45 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 don’t 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 Remark
Modify this value for high
MOD
RTWP cells only which
CELL UPRACHUUPARA Constantvalue -20 -30
was caused by high
S
traffic
Modify this value for high
MOD
RTWP cells only which
CELL UPRACHUUPARA PowerRampStep 2 1
was caused by high
S
traffic
Modify this value for high
MOD
PreambleRetransMa RTWP cells only which
CELL UPRACHUUPARA 20 40
x was caused by high
S
traffic
Modify this value for high
RTWP cells only which
CELL ADD URACH Mmax 8,3 3
was caused by high
traffic
Modify this value for high
RTWP cells only which
CELL ADD URACH NB01max 10,0 10
was caused by high
traffic

RNC level optimization

Current Recommend
Level Command Parameter Remark
Value Value
SET
UM_RRCRELCMP_RLDEL_DELAY_SWIT
RNC URRCTRLSWIT 1 1 Improve RTWP
H
CH
SET
RNC UEDCHTTIREC BeThd6A1 3 6 Improve RTWP
FG
SET
RNC UEDCHTTIREC BeThd6B1 3 6 Improve RTWP
FG
SET
RNC UEDCHTTIREC BeThd6A2 4 7 Improve RTWP
FG
SET
RNC UEDCHTTIREC BeThd6B2 4 7 Improve RTWP
FG
SET RESERVEDSWITCH0_RESERVED_SWITC
1 Improve RTWP
RNC UCORRMPARA H_0_BIT2 0

Understanding of counter relationship

 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 doesn’t no impact at live network if have impact at live
network then change only in night time during wee hours only. thank you