October 2012
Arum Setyo
3G Performance Analysis
3G RF Optimization
3G RF Optimization Cases
3G RF Formula
Capacity Management Concept
Expansion Criteria
Capacity counters & optimization
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)
Problem Classification Measurement Item Sub Items Congestion RRC.FailConnEstab.Cong VS.RRC.Rej.ULIUBBand.Cong, VS.RRC.Rej.DLIUBBand.Cong VS.RRC.Rej.ULPower.Cong, VS.RRC.Rej.DLPower.Cong VS.RRC.Rej.ULCE.Cong, VS.RRC.Rej.DLCE.Cong VS.RRC.Rej.Code.Cong RF Problem RRC.FailConnEstab.NoReply VS.RRC.Rej.Redir.Dist VS.RRC.Rej.Redir.InterRat VS.RRC.Rej.Redir.IntraRat VS.RRC.Rej.Redir.Service Transmission Problem VS.RRC.Rej.RL.Fail 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?
Problem Classification Measurement Item Sub Items Sub Items Sub Items
Level 1 Level 2 Level 3 Level 4
Congestion VS.RAB.FailEstabCS.RNL VS.RAB.FailEstCS. Unsp VS.RAB.FailEstabCS. Cong VS.RAB.FailEstCs.ULPower.Cong VS.RAB.FailEstCs.DLPower.Cong VS.RAB.FailEstCs.Code.Cong VS.RAB.FailEstab.CS.DLIUBBand. VS.RAB.FailEstab.CS.ULIUBBand. VS.RAB.FailEstCs.ULCE.Cong VS.RAB.FailEstCs.DLCE.Cong RF Problem VS.RAB.FailEstabCS.UuFail VS.RAB.FailEstabCS.IubFail Transmission VS.RAB.FailEstabCS.TNL
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.
Problem Classification Measurement Item Sub Items Congestion RRC.FailConnEstab.Cong VS.RRC.Rej.ULIUBBand.Cong, VS.RRC.Rej.DLIUBBand.Cong VS.RRC.Rej.ULPower.Cong, VS.RRC.Rej.DLPower.Cong VS.RRC.Rej.ULCE.Cong, VS.RRC.Rej.DLCE.Cong VS.RRC.Rej.Code.Cong RF Problem RRC.FailConnEstab.NoReply VS.RRC.Rej.Redir.Dist VS.RRC.Rej.Redir.InterRat VS.RRC.Rej.Redir.IntraRat VS.RRC.Rej.Redir.Service Transmission Problem VS.RRC.Rej.RL.Fail 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?
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.
Problem
Classification
Abnormal Release Indicator Sub-indicator (Level 2)
Note
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.
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 transmission alarms to identify possible
Problem
Classification
Abnormal Release Indicator
Sub-indicator (Level 2)
Note
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.
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 transmission alarms to identify possible
Problem Classification Failure Indicator Note
Preparation phase VS.IRATHO.FailRelocPrepOutCS.TAlExp.GCell 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)
VS.IRATHO.FailRelocPrepOutCS.TgtFail.GCell Relocation Failure in target CN/RNC or target system (check the CN configuration; check if the BSS supports the relocation)
IRATHO.FailRelocPrepOutCS.ReloNoSup Relocation not supported in target RNC or target system
IRATHO.FailRelocPrepOutCS.NoResAvail 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 source cell
IRATHO.FailRelocPrepOutCS.UKnowRNC Unknown Target RNC (the LAI of the 2G target cell is not configured in the MSC)
Execution phase IRATHO.FailOutCS.CfgUnsupp 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)
IRATHO.FailOutCS.PhyChFail 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)
VS.IRATHO.FailOutCS.NoReply 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
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
Problem Classification Failure Indicator Note
Preparation phase VS.IRATHO.FailRelocPrepOutPS.NoResAvail No Resource Available (the BSC has no resources for the UE access or the 2G MSC has no information about the target cell)
VS.IRATHO.FailRelocPrepOutPS.ReloUnSupp Relocation not supported in target RNC or target system
VS.IRATHO.FailRelocPrepOutPS.TAlExp 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)
VS.IRATHO.FailRelocPrepOutPS.TgtFail Relocation Failure in target CN/RNC or target system (check the CN configuration; check if the BSS
supports the relocation)
VS.IRATHO.FailRelocPrepOutPS.TgtHighLoad Traffic load in the target cell higher than in the source cell
VS.IRATHO.FailRelocPrepOutPS.UnKnowRNC Unknown Target RNC (the LAI of the 2G target cell is not configured in the MSC)
Execution phase IRATHO.FailOutPSUTRAN.CfgUnsupp(none) 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)
IRATHO.FailOutPSUTRAN.PhyChFail(none) 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)
VS.IRATHO.FailOutPSUTRAN.NoReply 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
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
Failure Indicator
Note
VS.HHO.FailInterFreqOut.CfgUnsupp
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)
VS.HHO.FailInterFreqOut.PyhChFail
Physical channel failure (indicates poor coverage)
VS.HHO.FailInterFreqOut.ISR
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)
VS.HHO.FailInterFreqOut.CellUpdt
Cell update occurred (this case never happens in commercial
network)
VS.HHO.FailInterFreqOut.InvCfg
Invalid configuration (some IEs in the “PHYSICAL CHANNEL
RENONFIGURATION” message are invalid for the UE; this case
almost never happens; indicates possible UE problem)
VS.HHO.FailInterFreqOut.NoReply
No response on the air interface (indicates poor coverage or
even a UE problem)
VS.HHO.FailInterFreqOut.PrepFail
VS.HHO.FailInterFreqOut.RLSetupFail
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
Improper settings may cause the handover not to
be performed on time
Check events 2D/2F parameters
Check events 2B, 2C parameters
RNC level formula:
HSDPA Throughput Kbps (RNC) =
[VS.HSDPAPSLoad.DLThruput.RNC]
Cell level formula:
HSDPA Throughput Kbps (Cell) =
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 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
RNC level formula:
HSUPA Throughput Kbps (RNC) =
[VS.HSUPAPSLoad.ULThruput.RNC]
Cell level formula:
HSUPA Throughput Kbps (Cell) =
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
Missing neighbours 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:
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)
Index
Reference
Remarks
Coverage rate
≥ 95%
Test on the acceptance route
The planned continuous coverage
service:
CPICH Ec/Io ≥ –12 dB
CPICH RSCP ≥ –95 dBm
CPICH Ec/Io ≥ –12dB
≥ 95%
Test result by scanner in outdoor
unloaded conditions
CPICH RSCP ≥ –95dBm ≥ 95%
Test result by scanner in outdoor
unloaded conditions
SHO Factor based on DT 30%–40%
The SHO Factor based on DT
should be 5% to 10% lower than
the goal, because the following
optimizations cause the soft
handover factor to increase
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
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
Weak coverage define with RSCP smaller than
–95 dBm. It might be in:
Valley areas
Hillside back
Elevator well
Tunnel
Underground garage
Basement
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,
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.
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:
In no primary pilot areas, UE hands over
frequently, so the system efficiency is lowered
and probability of call drop increases.
Solution:
RSCP Threshold -95dBm; Ec/No Threshold -12dB
Pilot Pollutions Poor Coverage
Poor Coverage Optimum Area
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:
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
No improper
coverage/
Configuration
issue
Iub Expansion/ Modernization and Expansion
CE
CE Board/License Expansion
Power
40W/New Site/2
ndCarrier
HSDPA Code
License Expansion
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
Iub Utilization (Max of average in BH 5 conservative days) > 70%
2
RAB Blocking Rate due to Iub > 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
CE Utilization (Max of average in BH 5 conservative days) > 70%
2
RRC + RAB Blocking Rate due to CE > 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
Power Utilization (Max of average in BH 5 conservative days) > 70%
2
RAB Blocking Rate due to Power > 1%
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
Index
Triggering Criteria (Busy Hour)
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 Factor Number of CEs Consumed Corresponding Credits Consumed Typical Traffic Class 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 Factor Number of CEs Consumed Corresponding Credits Consumed Typical Traffic Class 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
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
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%.
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
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.
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.
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.
When Iub congestion counters are not null:
Control that NodeB was not unavailable during the period of congestion:
VS.NodeB.UnavailTime.OM Optimize triggering thresholds. Optimize LDR actions.
Eventually increase Iub capacity.
Type of Service UL/DL Default Activity Factor (%) General common channel UL 70 IMS SRB UL 15 SRB UL 15 AMR voice UL 70 R99 CS conversational UL 100 R99 CS streaming UL 100 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.
When Iub congestion counters are not null:
Control that NodeB was not unavailable during the period of congestion:
VS.NodeB.UnavailTime.OM
Optimize triggering thresholds.
Optimize LDR actions.
Eventually increase Iub capacity.
Type of Service UL/DL Default Activity Factor (%)
General common channel DL 70
IMS SRB DL 15 MBMS common channel DL 100 SRB DL 15 AMR voice DL 70 R99 CS conversational DL 100 R99 CS streaming DL 100 R99 PS conversational DL 70 R99 PS streaming DL 100 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
