October 2012

Arum Setyo
sweet.arum@gmail.com
 3G Performance Analysis
 3G RF Optimization
 3G RF Optimization Cases
 3G RF Formula
 Capacity Management Concept
 Expansion Criteria
 Capacity counters & optimization
methodology
 Low CSSR CS
 Low CSSR PS
 High DCR CS
 High DCR PS
 Low CS ISHO Success Rate
 Low PS ISHO Success Rate
 Low IFHO Success Rate
 Low HSDPA Throughput
 Low HSUPA Throughput
 Low coverage (low RSCP vs. propagation delay)
 High interference (low EcNo (CQI) vs. good RSCP)
 RRC
Reject/Failure

RAB Voice Failure

alarms serving
NodeBneighbouring sites

f |- l. Ll f4K
 Transmission
problem

RRC Radio resource congestion

Reject/Failure

RF problem

f |- l. Ll f4K
Problem Classification Measurement Item Sub Items
VS.RRC.Rej.ULIUBBand.Cong,
VS.RRC.Rej.DLIUBBand.Cong
VS.RRC.Rej.ULPower.Cong,
Congestion RRC.FailConnEstab.Cong VS.RRC.Rej.DLPower.Cong
VS.RRC.Rej.ULCE.Cong,
VS.RRC.Rej.DLCE.Cong
VS.RRC.Rej.Code.Cong
RRC.FailConnEstab.NoReply
VS.RRC.Rej.Redir.Dist
RF Problem VS.RRC.Rej.Redir.InterRat
VS.RRC.Rej.Redir.IntraRat
VS.RRC.Rej.Redir.Service
VS.RRC.Rej.RL.Fail
Transmission Problem
VS.RRC.Rej.TNL.Fail
 Transmission Problem:
Relative alarms to identify faults on the
transmission path or the transmission boards of
RNC/NodeB.
 Congestion Problem:
Check the Admission Control thresholds.
Take appropriate measures to relieve congestion, e.g.
activate LDR (Load Reshuffling), OLC (Overload Control)
algorithms, and to increase capacity.
 RF Problem:
Check coverage in the failure points.
Check if most failures occur in cell border (most
probably they are).
Check FACH power.
Check DL interference in the cell: is there a
pilot pollution issue?
Check UL interference in the cell.
 Transmission
probJem

RNL related
probJem
RAB Failure

Congestion
probJem

Other Reason

f |- l. Ll f4K
Problem Classification Measurement Item Sub Items Sub Items Sub Items

Level 1 Level 2 Level 3 Level 4

VS.RAB.FailEstabCS.RNL VS.RAB.FailEstCS. VS.RAB.FailEstabCS. VS.RAB.FailEstCs.ULPower.Cong
Unsp Cong
VS.RAB.FailEstCs.DLPower.Cong

VS.RAB.FailEstCs.Code.Cong

VS.RAB.FailEstab.CS.DLIUBBand.
Congestion
VS.RAB.FailEstab.CS.ULIUBBand.

VS.RAB.FailEstCs.ULCE.Cong

VS.RAB.FailEstCs.DLCE.Cong

VS.RAB.FailEstabCS.UuFail
RF Problem
VS.RAB.FailEstabCS.IubFail
VS.RAB.FailEstabCS.TNL
Transmission
 Transmission Problem:
 Check transmission issue on Iu-CS interface; check
relative alarms and its history.
 RF Problem:
 Check invalid parameters
 Check inter-RAT HO and if the failure point is in RNC
border
 Check the relative RB Setup failure counters to get
more details on the failure cause
 Congestion Problem:
 Check the Admission Control thresholds.
 Take appropriate measures to relieve congestion, e.g.
activate LDR, OLC algorithms, and to increase
capacity.
 Refer to 3G Capacity Optimization document
 RRC
Reject/Failure

RAB PS
Failure

alarms serving
NodeBneighbouring sites

f |- l. Ll f4K
 Transmission
problem

RRC Radio resource congestion

Reject/Failure

RF problem

f |- l. Ll f4K
Problem Classification Measurement Item Sub Items
VS.RRC.Rej.ULIUBBand.Cong,
VS.RRC.Rej.DLIUBBand.Cong
VS.RRC.Rej.ULPower.Cong,
Congestion RRC.FailConnEstab.Cong VS.RRC.Rej.DLPower.Cong
VS.RRC.Rej.ULCE.Cong,
VS.RRC.Rej.DLCE.Cong
VS.RRC.Rej.Code.Cong
RRC.FailConnEstab.NoReply
VS.RRC.Rej.Redir.Dist
RF Problem VS.RRC.Rej.Redir.InterRat
VS.RRC.Rej.Redir.IntraRat
VS.RRC.Rej.Redir.Service
VS.RRC.Rej.RL.Fail
Transmission Problem
VS.RRC.Rej.TNL.Fail
 Transmission Problem:
Relative alarms to identify faults on the
transmission path or the transmission boards of
RNC/NodeB.
 Congestion Problem:
Check the Admission Control thresholds.
Take appropriate measures to relieve congestion, e.g.
activate LDR (Load Reshuffling), OLC (Overload Control)
algorithms, and to increase capacity.
 RF Problem:
Check coverage in the failure points.
Check if most failures occur in cell border (most
probably they are).
Check FACH power.
Check DL interference in the cell: is there a
pilot pollution issue?
Check UL interference in the cell.
 Transmission
problem

RNL related
problem
RAB PS
Failure
Congestion
probJem

Lack of
system
resources

Other Reason
f |- l. Ll f4K
Problem Classification Measurement Item Sub Items Sub Items
Level 1 Level 2 Level 3
Congestion VS.RAB.FailEstPS.RNL VS.RAB.FailEstPS.Unsp VS.RAB.FailEstPs.ULPower.Cong
VS.RAB.FailEstPs.Code.Cong
VS.RAB.FailEstab.PS.DLIUBBand.Cong
VS.RAB.FailEstab.PS.ULIUBBand.Cong
VS.RAB.FailEstPs.ULCE.Cong
VS.RAB.FailEstPs.DLCE.Cong
VS.RAB.FailEstPs.DLPower.Cong
RF Problem VS.RAB.FailEstabPS.UuFail
VS.RAB.FailEstabPS.IubFail
Transmission VS.RAB.FailEstPS.TNL
 Transmission Problem:
 Check relative alarms transmission issue on
Iub interface;
 RF Problem:
 Check coverage in the failure points. Check if
it is in cell border (most probably it is).
 Congestion Problem:
 Check the Admission Control thresholds.
Take appropriate measures to increase
capacity.
 Refer to this docs
 Call drop due
to bad RF
reasons
(indicate poor coverage)

. Call drop due to

non-RF reasons
 Problem
Abnormal Release Indicator Sub-indicator (Level 2) Note
Classification

RF Problem VS.RAB.AbnormRel.CS.RF VS.RAB.AbnormRel.CS.RF.

ULSync
VS.RAB.AbnormRel.CS.RF.
UuNoReply
VS.RAB.AbnormRel.CS.RF.S
RBReset
Non-RF Problem VS.RAB.AbnormRel.CS.OM CS RAB drops due to OM intervention,
e.g. cell was blocked
VS.RAB.AbnormRel.CS.Preempt CS RAB drops due to preemption
VS.RAB.AbnormRel.CS.UTRANgen CS RAB drops due to UTRAN generated
reasons; indicates hardware failure on
RAN equipment; check alarms in order
to identify the faulty part; repair or
replace the faulty part once identified.
VS.RAB.AbnormRel.CS.OLC Released Due to congestion for Cell
VS.RAB.AbnormRel.CS.IuAAL2 CS RAB drops due to AAL2 failure;
check transmission alarms to identify
possible faults in the Iu-CS
transmission path
 Check for missing neighbors
 Check for pilot pollution (adjust physical config)
 Check for UL interference. Check VS.MeanRTWP counter
in order to see the value of UL interference in the cell. If
the value is higher than -97 dBm, then interference exists
in the UL.
 Check internal interference
 Internal interference is usually caused by faulty connections in the
antenna line. Check thoroughly all relative connection
 Check external interference
 External interference is caused by external sources (e.g. TV/Radio
stations, military equipment, other network’s equipment, etc.).
 External interference will appear randomly throughout the day. Its
direction will be specific and it will affect more than one sites in
the area.
 Check neighbouring sites to see if they face the same problem.
 In case of poor coverage, adjust physical config.
  Drops due to OM intervention, cell was
blocked
 Drops due to preemption
 Drops due to UTRAN generated reasons
 Indicates hardware failure on RAN equipment
 Check alarms in order to identify the faulty part
 Repair or replace the faulty part once identified.

 Drops due to congestion for Cell

 Drops due to AAL2 failure
Check faults transmission alarms to identify possible
in the Iu-CS transmission path
 Call drop due to
bad RF reasons
(indicate poor coverage)

. Call drop due

to non-RF
reasons
f |- l. Ll f4K
 Problem
Abnormal Release Indicator Sub-indicator (Level 2) Note
Classification
RF Problem VS.RAB.AbnormRel.PS.RF VS.RAB.AbnormRel.PS.RF.SRBReset

VS.RAB.AbnormRel.PS.RF.ULSync

VS.RAB.AbnormRel.PS.RF.UuNoReply

VS.RAB.AbnormRel.PS.RF.TRBReset PS RAB drops due to RLC reset

RF Problem VS.RAB.AbnormRel.PS.OM PS RAB drops due to OM

intervention, e.g. cell was blocked

VS.RAB.AbnormRel.PS.Preempt PS RAB drops due to preemption

VS.RAB.AbnormRel.PS.OLC Released Due to congestion for

Cell
VS.RAB.AbnormRel.PS.GTPULoss PS RAB drops due to GTPU failure;
check transmission alarms to
identify possible faults in the Iu-
PS transmission path
 Check for missing neighbors
 Check for pilot pollution (adjust physical config)
 Check for UL interference. Check VS.MeanRTWP counter
in order to see the value of UL interference in the cell. If
the value is higher than -97 dBm, then interference exists
in the UL.
 Check internal interference
 Internal interference is usually caused by faulty connections in the
antenna line. Check thoroughly all relative connection
 Check external interference
 External interference is caused by external sources (e.g. TV/Radio
stations, military equipment, other network’s equipment, etc.).
 External interference will appear randomly throughout the day. Its
direction will be specific and it will affect more than one sites in
the area.
 Check neighbouring sites to see if they face the same problem.
 In case of poor coverage, adjust physical config.
  Drops due to OM intervention, cell was
blocked
 Drops due to preemption
 Drops due to UTRAN generated reasons
 Indicates hardware failure on RAN equipment
 Check alarms in order to identify the faulty part
 Repair or replace the faulty part once identified.

 Drops due to congestion for Cell

 Drops due to GTPU failure
Check faults transmission alarms to identify possible
in the Iu-PS transmission path.
 Problem Classification
Preparation phase
Failure Indicator
VS.IRATHO.FailRelocPrepOutCS.TAlExp.GCell
VS.IRATHO.FailRelocPrepOutCS.TgtFail.GCell
IRATHO.FailRelocPrepOutCS.ReloNoSup
IRATHO.FailRelocPrepOutCS.NoResAvail
Note
TRELOCalloc expiry (the timer that waits for
the “RELOCATION COMMAND” after the
“REOCATION REQUIRED” expires; check if the
RNC-MSC links are normal; check CN
transmission parameters)
Relocation Failure in target CN/RNC or target
system (check the CN configuration; check if
the BSS supports the relocation)
Relocation not supported in target RNC or
target system
No Resource Available (the BSC has no
resources for the UE access or the 2G MSC has
no information about the target cell)

IRATHO.FailRelocPrepOutCS.HigherTrafficLod Traffic load in the target cell higher than in the

IRATHO.FailRelocPrepOutCS.UKnowRNC
Execution phase IRATHO.FailOutCS.CfgUnsupp
IRATHO.FailOutCS.PhyChFail
VS.IRATHO.FailOutCS.NoReply
source cell
Unknown Target RNC (the LAI of the 2G target
cell is not configured in the MSC)
Configuration Unsupported (the configuration
assigned in the “HANDOVER FROM UTRAN
COMMAND” is not supported by the UE; check
configuration of the encryption parameters;
might also be UE problem)
Physical Channel Failure (indicates poor 2G
signal – check the handover thresholds in both
3G and 2G configurations; check for
interference in the 2G target cell)
Timeout of waiting for IU RELEASE COMMAND
messages during an outgoing inter-RAT CS
handover
 Check if the RNC-MSC links are normal
 Check if there’s any relocation failure
 Check if relocation not supported in
target RNC or target system
 No Resource Available
 BSC has no resources for the UE access
 MSC has no information about the target cell
 Need consistency checking between 2G and
3G NDB
 Congestion
 Check if there are any missing 2G neighbors
 Check the inter-RAT handover parameters
 Improper settings may cause the handover not to be
performed on time: events 2D/2F parameters, events
3A, 3C parameters
 Check the handover thresholds in both 3G and
2G configurations
 Database 2G-3G Consistecy Check
 Cross check 2G CFGMML with External 2G on 3G
CFGMML (parameter check on 2G: MCC, MNC,
LACCI, NCC, BCC, BCCH, RAC)
 Old database still not yet erased
 Check for Interference in the 2G target cell
 Check for SD and TCH blocking in the 2G target cell
Problem Classification Failure Indicator
Preparation phase VS.IRATHO.FailRelocPrepOutPS.NoResAvail
VS.IRATHO.FailRelocPrepOutPS.ReloUnSupp
VS.IRATHO.FailRelocPrepOutPS.TAlExp
VS.IRATHO.FailRelocPrepOutPS.TgtFail
VS.IRATHO.FailRelocPrepOutPS.TgtHighLoad
VS.IRATHO.FailRelocPrepOutPS.UnKnowRNC
Execution phase IRATHO.FailOutPSUTRAN.CfgUnsupp(none)
IRATHO.FailOutPSUTRAN.PhyChFail(none)
VS.IRATHO.FailOutPSUTRAN.NoReply
Note
No Resource Available (the BSC has no resources for
the UE access or the 2G MSC has no information
about the target cell)
Relocation not supported in target RNC or target
system
TRELOCalloc expiry (the timer that waits for the
“RELOCATION COMMAND” after the “REOCATION
REQUIRED” expires; check if the RNC-MSC links are
normal; check CN transmission parameters)
Relocation Failure in target CN/RNC or target system
(check the CN configuration; check if the BSS
supports the relocation)
Traffic load in the target cell higher than in the source
cell
Unknown Target RNC (the LAI of the 2G target cell is
not configured in the MSC)
Configuration Unsupported (the configuration
assigned in the “HANDOVER FROM UTRAN
COMMAND” is not supported by the UE; check
configuration of the encryption parameters; might
also be UE problem)
Physical Channel Failure (indicates poor 2G signal –
check the handover thresholds in both 3G and 2G
configurations; check for interference in the 2G
target cell)
Timeout of waiting for IU RELEASE COMMAND
messages during an outgoing inter-RAT CS handover
 Check if the RNC-SGSN links are normal
 Check if there’s any relocation failure
 Check if relocation not supported in
target RNC or target system
 No Resource Available
 BSC has no resources for the UE access
 MSC has no information about the target cell
 Need consistency checking between 2G and
3G NDB
 Congestion
 Check if there are any missing 2G neighbors
 Check the inter-RAT handover parameters
 Improper settings may cause the handover not to be
performed on time: events 2D/2F parameters, events
3A, 3C parameters
 Check the handover thresholds in both 3G and
2G configurations
 Database 2G-3G Consistecy Check
 Cross check 2G CFGMML with External 2G on 3G
CFGMML (parameter check on 2G: MCC, MNC,
LACCI, NCC, BCC, BCCH, RAC)
 Old database still not yet erased
 Check for Interference in the 2G target cell
 Check for PDCH blocking in the 2G target cell
 Failure Indicator
VS.HHO.FailInterFreqOut.CfgUnsupp
VS.HHO.FailInterFreqOut.PyhChFail
VS.HHO.FailInterFreqOut.ISR
VS.HHO.FailInterFreqOut.CellUpdt
VS.HHO.FailInterFreqOut.InvCfg
VS.HHO.FailInterFreqOut.NoReply
VS.HHO.FailInterFreqOut.PrepFail
VS.HHO.FailInterFreqOut.RLSetupFail
Note
Configuration unsupported (the UE doesn’t support the
configuration assigned by the RNC in the “PHYSICAL CHANNEL
RENONFIGURATION” message – indicates possible UE problem –
however this case almost never happens in commercial
networks)
Physical channel failure (indicates poor coverage)
Incompatible simultaneous reconfiguration (the UE feedbacks
that the HHO procedure is not compatible with other concurrent
processes. This case almost never happens; it indicates defective
UE)
Cell update occurred (this case never happens in commercial
network)
Invalid configuration (some IEs in the “PHYSICAL CHANNEL
RENONFIGURATION” message are invalid for the UE; this case
almost never happens; indicates possible UE problem)
No response on the air interface (indicates poor coverage or
even a UE problem)
 Optimizing Neighbor based on scenario given
 Blind HO setting
 Check availability/alarm on surroundings
 Check if there are any missing neighbors
 Check the inter-frequency handover
parameters
 Impropersettings may cause the handover not to
be performed on time
 Check events 2D/2F parameters
 Check events 2B, 2C parameters
 RNC level formula:
 HSDPAThroughput Kbps (RNC) =
[VS.HSDPAPSLoad.DLThruput.RNC]
 Cell level formula:
 HSDPAThroughput Kbps (Cell) =
[VS.HSDPA.MeanChThroughput]
 Check radio environment in the problematic cell
 Poor coverage is directly related with low HSDPA throughput.
 Enhance coverage by appropriate tuning of antenna parameters (tilt,
azimuth).
 Check for pilot pollution
 In case pilot pollution exists in the area, try to adjust tilts and/or
azimuths of relative sites
 Check for ping-pong serving cell change based on 1D event: ping-
pong limits throughput
 If this is the problem, tune event 1D parameters in order to eliminate
ping-pong.
 Consider also the value of the HspaTimerLen parameter.
 Check for hardware/software alarm in the site
 Check transmission whole network thoroughly
 Possibility of bottleneck in the transmission chain (e.g. too many sites
are served by a single low capacity router).
 Check Iu-PS interface.
 Check for faults (relative alarms) and its capacity. Make sure that the
configured Iu-PS capacity is not a bottleneck for PS service demands.
 RNC level formula:
 HSUPAThroughput Kbps (RNC) =
[VS.HSUPAPSLoad.ULThruput.RNC]
 Cell level formula:
 HSUPAThroughput Kbps (Cell) =
[VS.HSUPA.MeanChThroughput]
 Check radio environment in the problematic cell
 poor coverage is directly related with low HSUPA throughput.
 Enhance coverage by appropriate tuning of physical config
 Check for UL interference in the problematic area
 VS.MeanRTWP will provide average RTWP of cell
(UL interference give limits to HSUPA throughput)
 Check for ping-pong serving cell change based on 1D event
 If this is the problem, tune event 1D parameters in order
to eliminate ping-pong.
 Consider also the value of the HspaTimerLen parameter.
 Check for hardware/software alarm
 Check transmission whole network thoroughlyPossibility
of bottleneck in the transmission chain (e.g. too many
sites are served by a single low capacity router).
 Check the NodeB hardware equipment.
 Check the alarms.
 Conduct DT in the area of poor coverage to confirm the problem.
 Measure RSCP and Propagation delay.
 If RSCP is low while Propagation delay is low as well, this indicates poor
coverage close to the base station.
 Survey the environment
 Check for shadowing effect caused by object obstacles in the area.
 This might cause low signal strength close to NodeB.
 Analyse the multipath environment in the area (in dense urban strong
multipath may cause deep signal fades (fast fading))
 Adjust physical config (tilt, azimuth) appropriately in order to optimise
the coverage in the problematic area.
 Check the CPICH power setting.
 Default value is 33 dBm.
 Consider increase/decrease if needed
 Increase the power amplifier output
 usually initial 3G output is 20W. Consider upgrading to 40W or even to 60W.
 This will give extra margin to increase CPICH power and RL power.
 Check for pilot pollution in the area
 In case pilot pollution exists in the area
 Adjust tilts and/or azimuths of relative sector
 Check for missing neighbours
 Missingneighbours can cause increase of
interference in the source cell.
 Check whether the interference is from
an external source
 Check
for nearby sources of E/M radiation:
TV/Radio stations, Military, Civil aviation, etc.
 Log file & Necessary picture from field (by
DT)
 Plot PSC from scanner for pilot pollution
analyze
 Plot idle mode, short call, and long call
for analyzing network first symptoms
before optim
 Alarm list on the specific date
 Latest network data base (contains:
TSSR, physical configuration of the
network, neighbor)
 Contour Map
T

Pilot signal
Optimizing signal
coverage
coverage
optimization

3G RF
Pilot pollution Control pilot
optimization
optimization pollution

Handover Control SHO

optimization Factor based
on DT
 Index Reference Remarks
Test on the acceptance route
The planned continuous coverage
Coverage rate ≥ 95% service:
CPICH Ec/Io ≥ –12 dB
CPICH RSCP ≥ –95 dBm
Test result by scanner in outdoor
CPICH Ec/Io ≥ –12dB ≥ 95%
unloaded conditions
Test result by scanner in outdoor
CPICH RSCP ≥ –95dBm ≥ 95%
unloaded conditions
The SHO Factor based on DT
should be 5% to 10% lower than
SHO Factor based on DT 30%–40% the goal, because the following
optimizations cause the soft
handover factor to increase
Pilot pollution ratio ≤ 5% –
 15–25 NodeBs in a cluster is recommended
 A cluster must cover different areas based on density of user
traffic/clutter
 A cluster can define based on landform factor
 Mountains block signal propagation, so they are natural borders for
dividing clusters.
 Rivers causes a longer propagation distance, so they affect dividing
clusters in various aspects.
 If a river is narrow, the signals along two banks will interact. If the
transportation between two banks allows, divide sites along the two banks
in the same cluster.
 If a river is wide, the upstream and downstream will interact. In this
situation, the transportation between two banks is inconvenient,
dividing clusters by the bank according to actual situation.
 A cluster can define based on network project maintenance
 A cluster can define based on Administrative areas
 A cluster can define based on DT workload
 The DT must be performed within a day for a cluster
 Confirm the KPI DT acceptance route with the operator
before DT.
 If the operator already has a decided DT acceptance route,
you must consider this upon deciding the KPI DT acceptance
route.
 If the objective factors like network layout cannot fully
meet the coverage requirements of decided test route by
the operator, you must point this out.
 The KPI DT acceptance route must cover major streets,
important location, VIP, and VIC (Very Important Cell).
The DT route should cover all cells as possible.
 Round-trip DT is performed if possible.
 Consider actual factors like lanes and left-turn
restriction while deciding test route.
 Before negotiating with the operator, communicate
these factors with local drivers for whether the route is
acceptable.
 Weak coverage
 Cross-cell coverage
 Unbalance uplink and downlink
 No primary pilot cell
 Weak coverage define with RSCP smaller than
–95 dBm. It might be in:
 Valley areas
 Hillside back
 Elevator well
 Tunnel
 Underground garage
 Basement
 Areas inside high buildings
 Physical configuration changes:
 Increase pilot transmit power,
 Adjust antenna down tilt and azimuth,
 Increase antenna height,
 Use antennas with higher gain to optimize coverage.
 Hole coverage:
 Construct new NodeBs or expand the coverage range of
neighbor NodeBs.
 Pay attention to that increasing of coverage areas might
cause intra-frequency and inter-frequency interference.
 Add RRU in valley and hillside back areas with weak
coverage to expand coverage range.
 Dead Zone Area:
 Use RRU,
 Indoor distributed system,
 Leakage cable,
 Directional antenna
 Cross-cell coverage means the signal
from one NodeB hits the other signal
from the other nodeB.
 Drops happen due to delayed handover often
occurred because of this problem.
 Interference might occurs as well.
 Reduce cross-cell coverage areas by using
sheltering effect of adjacent buildings.
Meanwhile you must avoid intra-frequency
interference to other NodeBs.
 For over high NodeBs, change the site.
 Too large mechanism down tilt causes aberration
of antenna direction maps.
 Eliminate the "island" effect and reduce NodeB
coverage areas by adjusting pilot transmit
power and using electric down tilt.
 Unbalanced uplink and downlink refers to the
following situations:
 The downlink coverage is good but the uplink
coverage is restricted.
 More specific: the UE transmit power reaches
the maximum which still cannot meet uplink
BLER requirements.
 The downlink coverage is restricted.
 More specific, the downlink DCH transmit power
reaches the maximum which still cannot meet downlink
BLER requirements.
 If the uplink and downlink are unbalanced, call
drops easily. The probable cause is restricted
uplink coverage.
 Check for interference by monitoring RTWP
alarms of NodeB
 Brief:
 Inno primary pilot areas, UE hands over
frequently, so the system efficiency is lowered
and probability of call drop increases.
 Solution:
 Adjusting antenna down tilt and azimuth.
Pilot Pollutions Poor Coverage

Optimum Area Poor Coverage

RSCP Threshold -95dBm; Ec/No Threshold -12dB

 sc \JABFŒ OL œoinsCP HS lg •
S 2 GELONG S ïÆlMAN-1 1O7Œ
2_10HANGFLyDVER-3 1O7Œ

Eq Essa
MS1 Et Nean•ete•dRepoi6
NS1 R Neæae«maRefxxt t
NS1 R Nemaeta•dRw<•
NS1 @ Nee sete+¥ Repœt
1 NSt @ D•ePPed Cag
NS1 @ RRC Estd›¥cbed RRC St«e Cor••ected ŒLL
t4ode l5yas•I \•/C0I•ta

0 Mea»seterk Refxrt gJL4CCH)

¥4S1 RftC
st R Ïc 0 Meæaæe•a Renœt{UL-DCŒ
sJ Rdc fi lîeeaaenerc Reç¥xt gJL6CŒ)
S1 ABC s uew«w‹wd Ra 4 LocŒI
C Ueeaaæa•d RePm {UL6CCH)
TELWORKS
 Ceg Neta HS Tyne •.
Xî RJL0MA/A 3 2t3 10763
X CIRNAHG CENKDAK•3
32 PîlkURAYAN6
32 RSANGAN BARU T
X_MATRAt4AN_RAYA-1
Aî GRHANG CEı•tPEDAK-1 II
PUS IAXA RAWAt4ANGUN€

Eq

SJ R ¥•leaa•etœr4 Reoat \
S\ M Hæ<bves etd chæge d be•t Teçet SIR
New uafcrt 10763
SI P Ceg Reo¥ectx>•
SI ¥'. Ceg New •sg uARrŒ 107d. SC
Recebcio• 44 New cet UARFCN 107Œ.
SC 213
Ture 8.51

Eq PnXa N ae
Si RRC 4 ueea «•<•v Card (0L-0ŒH)
SI RRC + Phya d Chères Recay@ax {0L4
St RRC t Meax«e«erz Renat (UL€lŒHj
Si RRC Chanel Recad
s\ RRc è sxne• iaw••e@ iBCŒisŒj
S\ RRC è Sycie•i Iréomatxæ Message
{îäIB) S1 RRC 4' Syae• Irdametx IBCO4
8Œ)
TELWORKB
 Ce4 N HS Type
3G POLE UNIV I RISAK 114
X\ SROGOLFO-1

St @ f•teattxerrwrv Repxt 1 eJb. a fxmay CRCH leaved the iep jy

Rado L•d‹ Re•ovd
SI 5H0 P›o<<d•< Cor•oleie
S1 @ f•tea•uerrerz Renat 1 pt eJe a Rmey CRCH erre• ihe
@ Rec¥o L•d. SC added 297. SHO wro••
SHO Pic<ed •e Co«sA e Ad‹gan
RRC Siae

SI RRC I flea:wemert Repx* IUL'0CCH

i•lS RRC 4 A•t••c Sei Use l0L OKHI
MSI RRC t Ac‹r•c Sei Use Cue IUL OCCHI
51 RRC 6 ktea'uetrerz Cc<vid IDL-DCCH

SI RRC + Sytt‹m i i w iyCCH 8CH1

PSI RRC ñ Sy0em lr4*>Micfi t'4t:.ege ]S1t 3)
MSI RRC 6 Sv:tern IrdcxMkri k1e::aae ISIB 71

T E L W DHK S
 Ceg Neue
HS Tjoe
2 HANG TUAH RELOC J
G HALTE 8uH0ERAN SEHAYAN 1 J07b3
X• HALTE 8UNDERAN SEHAYAH
3 G iJANG 1uAH RELOC 2 l0Z6ü
¥2 HANG TUAH RELOC 3
OH G PAKUBUWONO VI GROGOL SELAT J07b3

UTRA Caixr RSSI •7t

7ogei SIR
S2 RRC A
S2 8RCC<x ecJ< A
S2 @ RRC Co»ec MA
S2 @ RRC A

S2 RRC f I oeswe <+d Repcxt UL6CCH

S2 RRC C Measwene+d Ref<rt IUL6CO4I

S2 RRC f RRC Rekasc Cor•o¥te (UL

S2 RRC 4• RRC Rehate IOL4CCH|
47 ••¥ Pac dreialvvsmd Rn

T E L VV O R < S
 3G_SENTRAL_SEN YAŃ-”OT

”3G_ARCADIA_PLA1

T E L VV O R < S
MS1 RRC ?
MS1 RRC I
MS1 RRC ?

MS1 RRC 6
MS1 RRC 6
3G DT Formula
 There are 2 type of capacity:
 Downgrade/Degrowth
 Upgrade/Growth
 This type decided by 3 factors:
 Blocking
 Utilization
 3G Resources related to blocking and
utilization:
 CE, IuB, Power, and Code
 Basic Formula
 UPGRADE
 Blocking High
 Utilization High
 DOWNGRADE
 Blocking Low
 Utilization Low
 Resource Configured more than 2
 Cek Parameter Setting if:
 Blocking High
 Utilization Low
 Cek Alarm and license:
 Blocking Low
 Utilization High
 Resource Verification Action
Iub Iub Expansion/ Modernization and Expansion
No improper
CE CE Board/License Expansion
coverage/
Power Configuration 40W/New Site/2nd Carrier
issue
HSDPA Code License Expansion
Index Triggering Criteria (Busy Hour)

1 Iub Utilization (Max of average in BH 5 conservative days) > 70%

2 RAB Blocking Rate due to Iub > 1%

3 HSDPA UE Mean Utilizations per NodeB > 70%

 Iub Expansion Notice

 Criteria of 1 AND 2 OR 3 triggered for
2 consecutive weeks
 Criteria must be fulfilled at least 3 days a week
 Coverage exercise must be done before proposing
action
Index Triggering Criteria (Busy Hour)

1 CE Utilization (Max of average in BH 5 conservative days) > 70%

2 RRC + RAB Blocking Rate due to CE > 1%

 CE Expansion Notice
 Both criteria of 1 AND 2 triggered for 2
consecutive weeks
 Criteria must be fulfilled at least 3 days a week
 Coverage exercise must be done before
proposing action
Index Triggering Criteria (Busy Hour)

1 Power Utilization (Max of average in BH 5 conservative days) > 70%

2 RAB Blocking Rate due to Power > 1%

 Power Expansion Notice

 Criteria 1 AND 2 triggered for 2 consecutive
weeks
 Criteria must be fulfilled at least 3 days a week
 Coverage exercise must be done before
proposing action
Index Triggering Criteria (Busy Hour)
1 HSDPA Code Utilization (Max of BH 5 conservative days) > 80%

 HSDPA Code Expansion Notice

 Criteria triggered for 2 consecutive weeks
 Criteria must be fulfilled at least 3 days a week
 Coverage exercise must be done before
proposing action
 BLOCKING:
 VS.RRC.Rej.UL.CE.Cong: Number of RRC Connection Reject.
 VS.RAC.NewCallRequest.Fail.ULCE.Cong: Number of failures in the RRC/RAB
SETUP procedure.
 VS.RAB.FailEstCs.ULCE.Cong: Number of CS RABs unsuccessfully established.
 VS.RAB.FailEstPs.ULCE.Cong: Number of PS RABs unsuccessfully established.
 VS.RAC.SHO.Fail.ULCE.Cong: Number of failures in the SHO procedure.
 VS.RAC.HHO.Fail.ULCE.Cong: Number of failures in the HHO procedure.
 VS.RAC.TrChSwitch.Fail.ULCE.Cong: Number of failures in the Channel Switch
procedure.
 VS.RAC.DCCC.Fail.ULCE.Cong: Number of failures in the DCCC procedure.
 VS.LCC.LDR.Num.ULCE: Number of times a cell is in LDR (Load Reshuffling)
State due to UL CE Resource Congestion.
 VS.LCC.LDR.Time.ULCE: Duration in seconds of LDR State due to UL CE
Resource Congestion.
 UTILIZATION:
 VS.LC.ULCreditUsed.CELL.Max: Maximum UL credit usage.
 UL CE Utilization Ratio(NodeB) = (VS.LC.ULMax.LicenseGroup.Shared
/ VS.LC.ULCreditAvailable.Shared)*100%.
 VS.LC.ULMax.LicenseGroup.Shared: Max usage of UL CEs.
 VS.LC.ULCreditAvailable.Shared: Number of UL CEs licensed.
 If the congestion is spread among different hours and
days, and on the same NodeB, 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): Uplink Rate Decrease Adjust
Level. If set to 3_Rates can be reduced to 2_Rates.
 UlRateUpAdjLevel (DCCC): Uplink Rate Increase Adjust Level.
If set to 2_Rates can be increased to 3_Rates.
 Additional options are:
 Decrease the Max Bit Rate
 Add more UL CEs
Direction
Spreading Number of Corresponding Typical Traffic
Factor CEs Consumed Credits Class
Consumed
UL 256 1 2 3.4 kbit/s SRB
UL 64 1 2 13.6 kbit/s SRB
UL 64 1 2 12.2 kbit/s AMR
UL 16 3 6 64 kbit/s VP
UL 32 1.5 3 32 kbps PS
UL 16 3 6 64 kbit/s PS
UL 8 5 10 128 kbit/s PS
UL 4 10 20 384 kbit/s PS
 BLOCKING:
 VS.RRC.Rej.DL.CE.Cong: Number of RRC Connection Reject.
 VS.RAC.NewCallRequest.Fail.DLCE.Cong: Number of failures in the RRC/RAB
SETUP procedure.
 VS.RAB.FailEstCs.DLCE.Cong: Number of CS RABs unsuccessfully established.
 VS.RAB.FailEstPs.DLCE.Cong: Number of PS RABs unsuccessfully established.
 VS.RAC.SHO.Fail.DLCE.Cong: Number of failures in the SHO procedure.
 VS.RAC.HHO.Fail.DLCE.Cong: Number of failures in the HHO procedure.
 VS.RAC.TrChSwitch.Fail.DLCE.Cong: Number of failures in the Channel Switch
procedure.
 VS.RAC.DCCC.Fail.DLCE.Cong: Number of failures in the DCCC procedure.
 VS.LCC.LDR.Num.DLCE: Number of times a cell is in LDR State due to DL
CE Resource Congestion.
 VS.LCC.LDR.Time.DLCE: Duration in seconds of LDR State due to DL CE
Resource Congestion.
 UTILIZATION:
 VS.LC.DLCreditUsed.CELL.Max: Maximum DL credit usage.
 DL CE Utilization Ratio(NodeB) = (VS.LC.DLMax.LicenseGroup.Shared
/ VS.LC.DLCreditAvailable.Shared)*100%.
 VS.LC.DLMax.LicenseGroup.Shared: Max usage of DL CEs.
 VS.LC.DLCreditAvailable.Shared: Number of DL CEs licensed.
 If congestion is spread among different hours and days,
and on the same NodeB, the following parameters can
be used to decrease the usage of DL CEs:
 DlMidRateThd (DCCC): Downlink Mid Bit Rate Threshold.
 DlDcccRateThd (DCCC): Downlink Bit Rate Threshold for DCCC.
 DlFullCvrRate (DCCC): Downlink Full Coverage Bit Rate.
 DlGBR (USERGBR): Downlink GBR for BE service.
 DlRateDnAdjLevel (DCCC): Downlink Rate Decrease
Adjust Level. If set to 3_Rates can be reduced to
2_Rates.
 DlRateUpAdjLevel (DCCC): Downlink Rate Increase
Adjust Level. If set to 2_Rates can be increased to
3_Rates.
 Additional options are:
 Decrease the Max Bit Rate
 Add more DL CEs
Direction Spreading Number of Corresponding Typical Traffic
Factor CEs Consumed Credits Class
Consumed
DL 256 1 1 3.4 kbit/s SRB
DL 128 1 1 13.6 kbit/s SRB
DL 128 1 1 12.2 kbit/s AMR
DL 32 2 2 64 kbit/s VP
DL 64 1 1 32 kbps PS
DL 32 2 2 64 kbit/s PS
DL 16 4 4 128 kbit/s PS
DL 8 8 8 384 kbit/s PS
 BLOCKING:
 VS.RRC.Rej.Code.Cong: Number of RRC Connection Reject.
 VS.RAB.FailEstCs.Code.Cong: Number of CS RABs unsuccessfully established.
 VS.RAB.FailEstPs.Code.Cong: Number of PS RABs unsuccessfully established.
 VS.RAC.SHO.Fail.OVSF.Cong: Number of failures in the SHO procedure.
 VS.RAC.TrChSwitch.Fail.OVSF.Cong: Number of failures in the Channel Switch procedure.
 VS.RAC.DCCC.Fail.OVSF.Cong: Number of failures in the DCCC procedure.
 VS.LCC.LDR.Num.DLCode: Number of times a cell is in LDR State due to Code Resource Congestion.
 VS.LCC.LDR.Time.DLCode: Duration in seconds of LDR State due to Code Resource Congestion.
 VS.LCC.LDR.CodeAdj: Number of UEs for Code Adjustment in Basic Congestion
 UTILIZATION:
 Code Utilization Ratio(Cell) = (VS.RAB.SFOccupy.MAX / 256)*100%.
 VS.RAB.SFOccupy.MAX: Maximum number of SFs codes in a cell. Code are occupied by the common
channels, R99 users and HS-DSCH. The code number is normalized to SF = 256, that is, converted to the
code number when SF = 256.
 Soft Handover Overhead(Cell) =
[(VS.SHO.AS.1RL+VS.SHO.AS.2RL+VS.SHO.AS.3RL+VS.SHO.AS.4RL+VS.SHO.AS.5RL+VS.SHO.AS.6RL)/(VS.S
HO.AS.1RL+VS.SHO.AS.2RL/2+VS.SHO.AS.3RL/3+VS.SHO.AS.4RL/4+VS.SHO.AS.5RL/5+VS.SHO.AS.6RL/6)-
1]*100%.
 VS.SHO.AS.xRL: Mean Number of UEs with x RL. Code resources could be wasted because of too many
cells in SHO. Optimal value is Soft Handover Overhead = 1.3 ～ 1.4, but it depends also on the area
(urban/rural).
 NodeB Performance Counters: VS.PdschCodeUsed.Max: Maximum number of codes used by HS-PDSCHs
in a cell during a measurement period.
 VS.PdschCodeAvail.Max: Maximum number of codes available for HS-PDSCHs in a cell during a
measurement period.
 In case of CAC based on code resources, the only parameter controlling triggering is:
 DlHoCeCodeResvSf (CELLCAC): DL Handover Credit and Code Reserved SF.
 [Quantity of DL code (SF) and CE resources reserved for handover UEs]
 Rule: DlHoCeCodeResvSf ≥ max(DLLDRCREDITSFRESTHD, CELLLDRSFRESTHD).

 In case of LDR based on code resources, triggering can be controlled through:

 CELLLDRSFRESTHD (CELLLDR): Cell LDR SF reserved threshold.
 [Code reshuffling could be triggered only when the minimum available SF of a cell is higher than this
threshold]
 ULLDRCREDITSFRESTHD, DLLDRCREDITSFRESTHD(CELLLDR): UL/DL LDR Credit SF reserved threshold.
 [UL/DL credit LDR could be triggered only when the SF factor corresponding to the UL/DL reserved
credit is higher than the UL or DL credit SF reserved threshold. Low value means Higher admission
success rate but easier congestion status and then Easier LDR action trigger]

 Many LDR actions can be performed. Particularly for Code Basic Congestion, Code Reshuffling is
controlled through:
 MAXUSERNUMCODEADJ (CELLLDR): Max user number of code adjust.
 [Number of users selected in code reshuffling]
 LdrCodePriUseInd (CELLLDR): LDR code priority indicator.
 [If TRUE, the codes with high priority are reserved during code reshuffling]

 Other relevant LDR actions to control code shortage are Inter-Frequency Load Handover and
BE Rate Reduction.
 BLOCKING:
 VS.RRC.Rej.Power.Cong: Number of RRC Connection Reject.
 VS.RAB.FailEstCs.Power.Cong: Number of CS RABs unsuccessfully established.
 VS.RAB.FailEstPs.Power.Cong: Number of PS RABs unsuccessfully established.
 VS.RAC.Total.Power.Cong: Number of admission failures due to Total Power resource insufficiency.
 VS.RAC.R99.Power.Cong: Number of admission failures due to R99 Power resource insufficiency.
 VS.RAC.HSDPA.Power.Cong: Number of admission failures due to HSDPA Power resource insufficiency.
 VS.RAC.HSUPA.Power.Cong: Number of admission failures due to HSUPA Power resource insufficiency.
 VS.RAC.SHO.Fail.ULLD.Cong, VS.RAC.SHO.Fail.DLLD.Cong: Number of failures in the SHO procedure.
 VS.RAC.HHO.Fail.ULLD.Cong, VS.RAC.HHO.Fail.DLLD.Cong: Number of failures in the HHO procedure.
 VS.RAC.TrChSwitch.Fail.ULLD.Cong, VS.RAC.TrChSwitch.Fail.DLLD.Cong: Number of failures in the
Channel Switch procedure.
 VS.RAC.DCCC.Fail.ULLD.Cong, VS.RAC.DCCC.Fail.DLLD.Cong: Number of failures in the DCCC
procedure.
 VS.LCC.LDR.Num.ULPower, VS.LCC.LDR.Num.DLPower: Number of times a cell is in LDR State due to
Power (Equivalent Number of Users) Congestion.
 VS.LCC.LDR.Time.ULPower, VS.LCC.LDR.Time.DLPower: Duration in seconds of LDR State due to Power
(Equivalent Number of Users) Congestion..
 UTILIZATION:
 VS.MeanTCP: Mean Transmitted Carrier Power (dBm).
 VS.MaxTCP: Max Transmitted Carrier Power (dBm).
 UL Interference Cell Ratio(RNC) = [(Number of Cells where VS.MeanRTWP>-98dBm)/Total Number Of
Cells In RNC]*100%.
 VS.MeanRTWP: Mean Received Total Wideband Power (dBm).
 In case of CAC based on power resources, the controlling parameters
depend on the Algo used.
 For Algo1&3:
 UlNonCtrlThdForAMR, DLCONVAMRTHD (CELLCAC): UL/DL threshold of Conv AMR.
 UlNonCtrlThdForNonAMR, DLCONVNAMRTHD (CELLCAC): UL/DL threshold of Conv non_AMR.
 UlNonCtrlThdForOther, DLOTHERTHD (CELLCAC): UL/DL threshold of other service.
 UlNonCtrlThdForHo, DLHOTHD (CELLCAC): UL/DL Handover access threshold.

 [These thresholds are a percentage of the 100% downlink load. If the UL/DL load of a cell
is higher than these thresholds after the access of a service, this service will be
rejected]
 Rules:
 DLHOTHD > max(DLCONVAMRTHD, DLCONVNAMRTHD) > DLOTHERTHD
 UlNonCtrlThdForHo > max(UlNonCtrlThdForAMR, UlNonCtrlThdForNonAMR) >
UlNonCtrlThdForOther
 For Algo2:
 ULTOTALEQUSERNUM, DLTOTALEQUSERNUM (CELLCAC): UL/DL total equivalent user number.
 [Total equivalent user number corresponding to the 100% uplink load]

 RRC connection request is rejected upon UL or DL admission decision by RRM.

Check VS.MeanRTWP and VS.MaxTCP of the cell to determine whether the
rejection is due to UL or DL congestion.
 In case of LDR based on power resources, triggering can be controlled through:
 ULLDRTRIGTHD, DLLDRTRIGTHD (CELLLDM): UL/DL LDR trigger threshold.
[If (UL Load / UL Capacity) of the cell is not lower than this threshold, UL load
reshuffling is triggered]
 ULLDRRELTHD, DLLDRRELTHD (CELLLDM): UL/DL LDR release threshold.
[If (UL Load / UL Capacity) of the cell is lower than this threshold, UL load
reshuffling is stopped]

 Many LDR actions can be performed. Particularly for Power Basic Congestion,
MBMS (Multimedia Broadcast Multicast Service) Power Reduction is
controlled through:
 MBMSDECPOWERRABTHD (CELLLDR): MBMS descend power RAB threshold.
[MBMS provides unidirectional point-to-multipoint multimedia services. When the
priority of the RAB of MBMS services exceeds this threshold, reconfigure the
MBMS power to the minimum power]

 Other relevant LDR actions to control power shortage are Inter-Frequency

Load Handover, BE Rate Reduction and Inter-RAT Handover in the CS Domain.
 BLOCKING:
 VS.RAC.NewCallRequest.Fail.HSDPANum.Cong: Number of failures in the RRC or RAB SETUP procedure.
 VS.RAB.RelReqPS.BE.HSDPA.Cong.Golden, VS.RAB.RelReqPS.BE.HSDPA.Cong.Silver,
VS.RAB.RelReqPS.BE.HSDPA.Cong.Copper: Number of released PS BE RABs beared on HSDPA.
 VS.RAC.HHO.Fail.HSDPANum.Cong: Number of failures in the HHO procedure.
 VS.RAC.TrChSwitch.Fail.HSDPANum.Cong: Number of failures in the Channel Switch procedure.
 VS.HSDPA.LDR.InterFreq: Number of HSDPA UEs that perform inter-frequency handover because of
Basic Congestion.
 VS.HSDPA.LDR.InterRATPS: Number of HSDPA UEs that perform PS inter-RAT handover because of Basic
Congestion.
 VS.HSDPA.OLC.UserRel: Number of UEs released due to Overload Congestion.
 UTILIZATION:
 VS.HSDPA.UE.Mean.Cell: Number of UEs in CELL_HSDPA state in a cell.
In case of CAC based on the number of HSDPA users, the controlling parameter is:
 MaxHsdpaUserNum (CELLCAC): Maximum HSDPA user number (based on cell type and available HSDPA
power and code resources). Its value is related to the presence of the following features:
 WRFD-01061016: 16 HSDPA Users per Cell.
 WRFD-010622: 32 HSDPA Users per Cell.
 WRFD-010623: 64 HSDPA Users per Cell.
 HSDPA Utilization Ratio(Cell) = [maxHours(VS.HSDPA.UE.Mean.Cell) / MaxHsdpaUserNum]*100%.
 If Basic Congestion is triggered, make sure that VS.HSDPA.LDR.InterFreq is
incremented, but not VS.HSDPA.LDR.InterRATPS (typically the PS inter-rat
handover algorithm switch is disabled, and HSDPA calls are preferred
dropping rather than handing over to 2G).
 Basic Congestion is a ‘normal’ situation and the ideal LDR action for HSDPA
users is inter-frequency handover to balance the load. Overload Congestion
instead requires the release of HSDPA users. Overload Congestion is
triggered by:
 ULOLCTRIGTHD, DLOLCTRIGTHD (CELLLDM): UL/DL OLC trigger threshold.
[If (UL Load / UL Capacity) of the cell is not lower than this threshold, UL
overload is triggered]
 ULOLCRELTHD, DLOLCRELTHD (CELLLDM): UL/DL OLC release threshold.
[If (UL Load / UL Capacity) of the cell is lower than this threshold, UL overload is
stopped]

 Additional actions to increase capacity:

 Divide users between Gold, Silver and Copper and/or modify their
priorities: UserPriority (SCHEDULEPRIOMAP).
 Specify a HSDPA-only carrier to avoid basic congestion conditions being triggered.
 Introduce an additional carrier.
 BLOCKING:
 VS.RAC.NewCallRequest.Fail.HSUPANum.Cong: Number of failures in the RRC or
RAB SETUP procedure.
 VS.RAB.RelReqPS.BE.HSUPA.Cong.Golden,
VS.RAB.RelReqPS.BE.HSUPA.Cong.Silver,
VS.RAB.RelReqPS.BE.HSUPA.Cong.Copper: Number of released PS BE RABs beared
on HSUPA.
 VS.RAC.SHO.Fail.HSUPANum.Cong: Number of failures in the SHO procedure.
 VS.RAC.HHO.Fail.HSUPANum.Cong: Number of failures in the HHO procedure.
 VS.RAC.TrChSwitch.Fail.HSUPANum.Cong: Number of failures in the Channel
Switch procedure.
 UTILIZATION:
 VS.HSUPA.UE.Mean.Cell: Number of UEs in CELL_HSUPA state in a cell.
 In case of CAC based on the number of HSUPA users, the controlling parameter is:
 MaxHsupaUserNum (CELLCAC): Maximum HSUPA user number (based on cell type
and available HSUPA power and code resources). Its value is related to the presence
of the following features:
 WRFD-01061211: 20 HSUPA Users per Cell.
 WRFD-010634: 60 HSUPA Users per Cell.
 HSUPA Utilization Ratio(Cell) = [maxHours(VS.HSUPA.UE.Mean.Cell)
/ MaxHsupaUserNum]*100%.
 Basic Congestion is a ‘normal’ situation and the ideal
LDR action for HSUPA users is inter-frequency
handover to balance the load. Overload Congestion
instead requires the release of HSUPA users.
Overload Congestion is triggered by:
 ULOLCTRIGTHD, DLOLCTRIGTHD (CELLLDM): UL/DL
OLC trigger threshold.
 ULOLCRELTHD, DLOLCRELTHD (CELLLDM): UL/DL
OLC release threshold.
 Additional actions to increase capacity:
 Divide users between Gold, Silver and Copper and/or
modify their priorities: UserPriority (SCHEDULEPRIOMAP).
 Specify a HSUPA-only carrier to avoid basic congestion
conditions being triggered.
 Introduce an additional carrier.
 BLOCKING:
 VS.RRC.Rej.ULIUBBandCong: Number of RRC Connection Reject.
 VS.RAB.FailEstab.CS.ULIUBBand.Cong: Number of CS RABs unsuccessfully established.
 VS.RAB.FailEstab.PS.ULIUBBand.Cong: Number of PS RABs unsuccessfully established.
 VS.RAC.SHO.Fail.ULIub.Cong: Number of failures in the SHO procedure.
 VS.RAC.HHO.Fail.ULIub.Cong: Number of failures in the HHO procedure.
 VS.RAC.TrChSwitch.Fail.ULIub.Cong: Number of failures in the Channel Switch procedure.
 VS.LCC.LDR.Num.ULIub: Number of times a cell is in LDR State due to UL Iub Transmission Resource
Congestion.
 VS.LCC.LDR.Time.ULIub: Duration in seconds of LDR State due to UL Iub Transmission Resource
Congestion.
 VS.IUB.CongUL: Number of UL congestions on Iub Interface.

 UTILIZATION:
 Consumed vs. configured Iub bandwidth:
 IUB UL Bandwidth Utilizing Ratio =
[(VS.ATMUlAvgUsed.1+VS.ATMUlAvgUsed.2+VS.ATMUlAvgUsed.3+VS.ATMUlAvgUsed.4+VS.IPUlAvgUsed.1+
VS.IPUlAvgUsed.2+VS.IPUlAvgUsed.3+VS.IPUlAvgUsed.4)/(VS.ATMUlTotal.1+VS.ATMUlTotal.2+VS.ATMUlT
otal.3+VS.ATMUlTotal.4+VS.IPUlTotal.1+VS.IPUlTotal.2+VS.IPUlTotal.3+VS.IPUlTotal.4)]*100%.
 VS.ATMUlAvgUsed.x: Average used UL bandwidth on an ATM physical port during a measurement
period.
 VS.IPUlAvgUsed.x: Average used UL bandwidth on an IP physical port during a measurement period.
 VS.ATMUlTotal.x: Available UL bandwidth of an ATM physical port during a measurement period.
 VS.IPUlTotal.x: Available UL bandwidth of an IP physical port during a measurement period.
  In case of CAC based on Iub resources:
 Reserved BW for RT service (signalling, voice, streaming) = MBR x Activity Factor
 Reserved BW for NRT service (interactive, background) = GBR x Activity Factor
Only GBR could be an option to avoid CAC being triggered.

 In case of LDR based on Iub resources, triggering can be controlled through:

 FWDCONGBW, BWDCONGBW: Forward/Backward congestion threshold.
[If the available forward/backward bandwidth is less than or equal to this value, forward/backward congestion
control is triggered]
 FWDCONGCLRBW, BWDCONGCLRBW: Fwd/Bwd congestion clear threshold.
[If the available forward/backward bandwidth is greater than this value,forward/backward congestion control is
stopped]

 Iub congestion control is implemented in a separate processing module, so its functionality is not controlled by
LDR switches. In the case of Iub congestion, however, LDR actions are applied to congestion resolution.
Type of Service UL/DL Default Activity
Factor (%)
 When Iub congestion counters are not null: General common channel UL 70
 Control that NodeB was not unavailable during the period of congestion: IMS SRB UL 15
SRB UL 15
 VS.NodeB.UnavailTime.OM
AMR voice UL 70
 Optimize triggering thresholds.
R99 CS conversational UL 100
 Optimize LDR actions. R99 CS streaming UL 100
 Eventually increase Iub capacity. R99 PS conversational UL 70
R99 PS streaming UL 100
R99 PS interactive UL 100
R99 PS background UL 100
HSUPA SRB UL 50
HSUPA IMS SRB UL 15
HSUPA voice UL 70
HSUPA conversational UL 70
HSUPA streaming UL 100
HSUPA interactive UL 100
HSUPA background UL 100
 BLOCKING:
 VS.RRC.Rej.DLIUBBandCong: Number of RRC Connection Reject.
 VS.RAB.FailEstab.CS.DLIUBBand.Cong: Number of CS RABs unsuccessfully established.
 VS.RAB.FailEstab.PS.DLIUBBand.Cong: Number of PS RABs unsuccessfully established.
 VS.RAC.SHO.Fail.DLIub.Cong: Number of failures in the SHO procedure.
 VS.RAC.HHO.Fail.DLIub.Cong: Number of failures in the HHO procedure.
 VS.RAC.TrChSwitch.Fail.DLIub.Cong: Number of failures in the Channel Switch procedure.
 VS.LCC.LDR.Num.DLIub: Number of times a cell is in LDR State due to DL Iub Transmission Resource
Congestion.
 VS.LCC.LDR.Time.DLIub: Duration in seconds of LDR State due to DL Iub Transmission Resource
Congestion.
 VS.IUB.CongDL: Number of DL congestions on Iub Interface.

 UTILIZATION:
 Consumed vs. configured Iub bandwidth:
IUB DL Bandwidth Utilizing Ratio =
[(VS.ATMDLAvgUsed.1+VS.ATMDLAvgUsed.2+VS.ATMDLAvgUsed.3+VS.ATMDLAvgUsed.4+VS.IPDLAvgUsed.1+VS.I
PDLAvgUsed.2+VS.IPDLAvgUsed.3+VS.IPDLAvgUsed.4)/(VS.ATMDLTotal.1+VS.ATMDLTotal.2+VS.ATMDLTotal.3+
VS.ATMDLTotal.4+VS.IPDLTotal.1+VS.IPDLTotal.2+VS.IPDLTotal.3+VS.IPDLTotal.4)]*100%.
 VS.ATMDLAvgUsed.x: Average used DL bandwidth on an ATM physical port during a measurement
period.
 VS.IPDLAvgUsed.x: Average used DL bandwidth on an IP physical port during a measurement period.
 VS.ATMDLTotal.x: Available DL bandwidth of an ATM physical port during a measurement period.
 VS.IPDLTotal.x: Available DL bandwidth of an IP physical port during a measurement period.
  METHODOLOGY:
 In case of CAC based on Iub resources:
 Reserved BW for RT service (signalling, voice, streaming) = MBR x Activity Factor
 Reserved BW for NRT service (interactive, background) = GBR x Activity Facto
 Only GBR could be an option to avoid CAC being triggered.

 In case of LDR based on Iub resources, triggering can be controlled through:

 FWDCONGBW, BWDCONGBW: Forward/Backward congestion threshold.
 FWDCONGCLRBW, BWDCONGCLRBW: Fwd/Bwd congestion clear threshold.

 Iub congestion control is implemented in a separate processing module, so its

functionality is not controlled by LDR switches. In the case of Iub congestion,
however, LDR actions are applied to congestion resolution.
Type of Service UL/DL Default Activity
Factor (%)
General common channel DL 70
 When Iub congestion counters are not null: IMS SRB DL 15
 Control that NodeB was not unavailable during the period of congestion: MBMS common channel DL 100
SRB DL 15
 VS.NodeB.UnavailTime.OM AMR voice DL 70
 Optimize triggering thresholds. R99 CS conversational DL 100
R99 CS streaming DL 100
 Optimize LDR actions. R99 PS conversational DL 70
R99 PS streaming DL 100
 Eventually increase Iub capacity. R99 PS interactive DL 100
R99 PS background DL 100
HSDPA SRB DL 50
HSDPA IMS SRB DL 15
HSDPA voice DL 70
HSDPA conversational DL 70
HSDPA streaming DL 100
HSDPA interactive DL 100
HSDPA background DL 100
EFACH channel DL 20
T ”E L W ORK S