UMTS Traning - 3G Basic 2

October 2012 Arum Setyo [email protected]

 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) 

Problem Classification

Congestion

RF Problem

Transmission Problem

Measurement Item

RRC.FailConnEstab.Cong

RRC.FailConnEstab.NoReply VS.RRC.Rej.Redir.Dist VS.RRC.Rej.Redir.InterRat VS.RRC.Rej.Redir.IntraRat VS.RRC.Rej.Redir.Service VS.RRC.Rej.RL.Fail VS.RRC.Rej.TNL.Fail

Sub Items 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



Transmission Problem: 



Congestion Problem:  



Relative alarms to identify faults on the transmission path or the transmission boards of RNC/NodeB. 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.

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 Transmission

VS.RAB.FailEstabCS.IubFail 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.  Refer to 3G Capacity Optimization document 

Problem Classification

Congestion

RF Problem

Transmission Problem

Measurement Item

RRC.FailConnEstab.Cong

RRC.FailConnEstab.NoReply VS.RRC.Rej.Redir.Dist VS.RRC.Rej.Redir.InterRat VS.RRC.Rej.Redir.IntraRat VS.RRC.Rej.Redir.Service VS.RRC.Rej.RL.Fail VS.RRC.Rej.TNL.Fail

Sub Items 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



Transmission Problem: 



Congestion Problem:  



Relative alarms to identify faults on the transmission path or the transmission boards of RNC/NodeB. 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.

Problem Classification

Congestion

Measurement Item

Sub Items

Sub Items

Level 1

Level 2

Level 3

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 

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:

Problem:

Check the Admission Control thresholds. Take appropriate measures to increase capacity. Refer to this docs

Problem Classification RF Problem

Abnormal Release Indicator VS.RAB.AbnormRel.CS.RF

Sub-indicator (Level 2)

Note

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. Released Due to congestion for Cell

VS.RAB.AbnormRel.CS.OLC 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 



Check external interference 







Internal interference is usually caused by faulty connections in the antenna line. Check thoroughly all relative connection 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 transmission alarms to identify possible faults in the Iu-CS transmission path

Problem Classification RF Problem

Abnormal Release Indicator VS.RAB.AbnormRel.PS.RF

Sub-indicator (Level 2)

Note

VS.RAB.AbnormRel.PS.RF.SRBReset

VS.RAB.AbnormRel.PS.RF.ULSync VS.RAB.AbnormRel.PS.RF.UuNoReply

VS.RAB.AbnormRel.PS.RF.TRBReset RF Problem

PS RAB drops due to RLC reset

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 PS RAB drops due to GTPU failure; check transmission alarms to identify possible faults in the IuPS transmission path

VS.RAB.AbnormRel.PS.GTPULoss



 

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 



Check external interference 







Internal interference is usually caused by faulty connections in the antenna line. Check thoroughly all relative connection 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 transmission alarms to identify possible faults 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

Execution phase

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 source cell IRATHO.FailRelocPrepOutCS.UKnowRNC Unknown Target RNC (the LAI of the 2G target cell is not configured in the MSC) 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

 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 Preparation phase

Failure Indicator VS.IRATHO.FailRelocPrepOutPS.NoResAvail

Note 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 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)

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

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

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)

VS.HHO.FailInterFreqOut.PyhChFail VS.HHO.FailInterFreqOut.ISR

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)

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 

HSDPA Throughput Kbps (RNC) = [VS.HSDPAPSLoad.DLThruput.RNC]

 Cell 

level formula:

level formula:

HSDPA Throughput 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: pingpong 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 

HSUPA Throughput Kbps (RNC) = [VS.HSUPAPSLoad.ULThruput.RNC]

 Cell 

level formula:

level formula:

HSUPA Throughput Kbps (Cell) = [VS.HSUPA.MeanChThroughput]



Check radio environment in the problematic cell  



Check for UL interference in the problematic area 



poor coverage is directly related with low HSUPA throughput. Enhance coverage by appropriate tuning of physical config 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.  



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.  



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.

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: 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

Index

Reference

Remarks Test on the acceptance route

Coverage rate

≥ 95%

CPICH Ec/Io ≥ –12dB

≥ 95%

CPICH RSCP ≥ –95dBm

≥ 95%

SHO Factor based on DT 30%–40%

Pilot pollution ratio

≤ 5%

The planned continuous coverage service: CPICH Ec/Io ≥ –12 dB CPICH RSCP ≥ –95 dBm Test result by scanner in outdoor unloaded conditions Test result by scanner in outdoor unloaded conditions 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 

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:    



Hole coverage:   



Increase pilot transmit power, Adjust antenna down tilt and azimuth, Increase antenna height, Use antennas with higher gain to optimize 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. 



The downlink coverage is restricted. 



More specific: the UE transmit power reaches the maximum which still cannot meet uplink BLER requirements. 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: 

Adjusting antenna down tilt and azimuth.

Pilot Pollutions

Poor Coverage

Optimum Area

Poor Coverage

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

 There  

Downgrade/Degrowth Upgrade/Growth

 This  

are 2 type of capacity:

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 Iub CE Power HSDPA Code

Verification No improper coverage/ Configuration issue

Action Iub Expansion/ Modernization and Expansion CE Board/License Expansion 40W/New Site/2nd Carrier 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:   



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:    



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).

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:  



For Algo2:  



DLHOTHD > max(DLCONVAMRTHD, DLCONVNAMRTHD) > DLOTHERTHD UlNonCtrlThdForHo > max(UlNonCtrlThdForAMR, UlNonCtrlThdForNonAMR) > UlNonCtrlThdForOther

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: 





Many LDR actions can be performed. Particularly for Power Basic Congestion, MBMS (Multimedia Broadcast Multicast Service) Power Reduction is 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]

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:  



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







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.

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 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.

General common channel

UL

Factor (%) 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.

Type of Service



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.

UL/DL

Default Activity Factor (%) 70

General common channel

DL

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