huawei-performance-monitoring-and-analysis

1 © Nokia Siemens Networks Presentation / Author / DateFor internal use

HUAWEI 3G PERFORMANCE MONITORING AND ANALYSIS


Contents

1. Overview2. 3G Performance Monitoring and Analysis


Document Information

Document Version: 1.0

Issue Date: August 20, 2010

Document Owner: Ville Salomaa

SOFTWARE RELEASE: RAN11

SCOPE: 3G performance monitoring and analysis

CONVENTION: Raw counters are marked in BLUE Formulas are marked in GRAY Parameters are marked in RED MML commands are marked in GREEN


Contents



Overview (1)

The purpose of this document is to describe the RAN KPI performance monitoring and analysis of problems that bad KPI values indicate.

The following analysis contains a list of the most common KPIs used in Huawei networks. These KPIs are monitored constantly. When the value of a KPI goes below the defined threshold, then detailed analysis should be performed in order to identify the reasons of this deterioration. Once the reasons are found, proper solutions will be proposed and implemented.

This document focuses more in the analysis of failure causes rather than the KPI monitoring itself.

The most common use cases for monitoring and analysis of bad KPI values are presented for 3G RAN.


Overview (2)

3G Performance Analysis Use Cases:

1. Low Call Setup Success Rate for Voice2. Low Call Setup Success Rate for PS3. High Call Drop Rate for AMR4. High Call Drop Rate for PS5. Low HSDPA Accessibility6. Low HSDPA Retainability7. Low HSDPA Serving Cell Change Success Rate8. Low HSDPA Throughput9. Low HSUPA Accessibility10. Low HSUPA Retainability11. Low HSUPA Serving Cell Change Success Rate12. Low HSUPA Throughput13. Low CS ISHO Success Rate14. Low PS ISHO Success Rate15. Low IFHO Success Rate16. Low HSDPA IFHO Success Rate17. Low coverage (low RSCP vs. propagation delay)18. High interference (low EcNo (CQI) vs. good RSCP)


Overview (3)

General Methodology:

1. Define RAN KPI class required (Accessibility, Retainability, Mobility, Resource Usage).2. Define KPI per service (AMR, Video Call, R99 PS, HSDPA, HSUPA).3. Define KPI formulas.4. Define target or guaranteed KPI values.5. Assess weekly average PLMN/RNC KPI performance in order to identify KPIs below target.6. Assess RNC/Area level performance in order to check if bad performance occurs across network or only in specific areas.7. Analyze bad performing KPIs in cell level in order to identify failure causes. (this point is the focus of this document)8. Use TopN cell approach to identify the worst performers. Identify top 20 worst cells.9. Look at failure distribution in network topology (urban, rural, motorway, RNC border, etc.).10. Propose solution to improve KPI value.


Contents



1. Low CSSR Voice (1)

Background info:• RRC Establishment

- RRC setup procedure, is the process that establishes the L3 connection

between UE and RNC that is used for signalling traffic only.- After RNC receives the RRC CONNECTION REQUEST, processes it and allocates relevant resources on L1, L2 and L3 of the air interface for this signalling connection.- The RNC notifies the UE for the prepared configuration with the RRCCONNECTION SETUP message.- The UE reports its capabilities to the RNC with the RRC CONNECTIONSETUP COMPLETE.

• RAB Establishment

- RAB setup procedure is the process that establishes the higher-layer connection between UE and CN that is used to transfer the user data only (not signalling).- When the RNC receives the RAB ASSIGNMENT REQUESTallocates the necessary resources for the requested service,after successful call admission. Resources include Codes, CE, Power, Iub bandwidth.- Then the RB is setup which is the UTRAN part of the RAB.- Upon successful completion of the RB setup, the RNC responds to the CN with the RAB ASSIGNMET RESPONDmessage.


1. Low CSSR Voice (2)

- RNC level formula:CS AMR Call Setup Success Rate (RNC) = (([VS.RRC.SuccConnEstab.OrgConv]+[VS.RRC.SuccConnEstab.TrmConv]+[VS.RRC.SuccConnEstab.Emg])/([VS.RRC.AttConnEstab.OrgConv]+[VS.RRC.AttConnEstab.TrmConv]+[VS.RRC.AttConnEstab.Emg]))*([VS.RAB.SucEstCSConv0.32.RNC]/[VS.RAB.AttEstCSConv0.32.RNC])*{100}

- Cell level formula:CS AMR Call Setup Success Rate (Cell) = (([RRC.SuccConnEstab.OgConvCall]+[RRC.SuccConnEstab.TmConvCall]+[RRC.SuccConnEstab.EmgCall])/([RRC.AttConnEstab.OrgConvCall]+[RRC.AttConnEstab.TmConvCall]+[RRC.AttConnEstab.EmgCall]))*([VS.RAB.SuccEstab.AMR]/[VS.RAB.AttEstab.AMR])*{100}

Analysis process:1. Check which part of the CSSR KPI causes the low value: RRC setup, RAB setup or both. The 2 distinct

parts RRC Setup Success Rate and RAB Setup Success Rate that are composing the CSSR can be used for this purpose.

2. To check the above, check the corresponding KPIs for RRC Setup Success Rate and AMR RAB Setup Success Rate.

3. Check the alarms for the serving NodeB and neighbouring sites in order to identify any hardware faults.4. In case that RRC Setup is causing the low value, identify the root cause of high RRC Setup failures by

following counters:• Transmission problem: following counters indicate transmission issue on Iub interface; check relative

alarms to identify faults on the transmission path or the transmission boards of RNC/NodeB.- VS.RRC.Rej.RL.Fail: RRC establishment failures due to RL setup failure.- VS.RRC.Rej.TNL.Fail: RRC establishment failures due to TNL (Transport Network Layer) setup failure.


1. Low CSSR Voice (3)• Radio resource congestion: following counters indicate lack of radio resources or Iub bandwidth. 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. Refer to Huawei 3G Capacity Optimisation document in IMS [1] for more details on how to battle congestion and improve capacity.

- VS.RRC.Rej.Power.Cong: RRC establishment failures due to power load congestion- VS.RRC.Rej.UL.CE.Cong: RRC establishment failures due to UL CE congestion- VS.RRC.Rej.DL.CE.Cong: RRC establishment failures due to DL CE congestion- VS.RRC.Rej.Code.Cong: RRC establishment failures due to code congestion- VS.RRC.Rej.ULIUBBandCong: RRC establishment failures due to UL Iub bandwidth congestion- VS.RRC.Rej.DLIUBBandCong: RRC establishment failures due to DL Iub bandwidth congestion- VS.RRC.Rej.Other.Cong: RRC establishment failures due to other congestion except from the previous 6 reasons

• RF problem: following counter indicate failure due to RF issue. 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.

- RRC.FailConnEstab.NoReply: RRC establishment failures due to no reply from the UE during the RRC setup flow.

5. In case that AMR RAB Setup is causing the low value, identify the root cause of high RAB Setup failures by following counters:

• Transmission problem: following counter indicate transmission issue on Iu-CS interface; check relative alarms.

- VS.RAB.FailEstabCS.TNL: CS RAB establishment failures due to TNL problem.


1. Low CSSR Voice (4)• RNL related problem: following counters indicate that the failure is due to a RNL (Radio Network Layer)

procedure problem; includes congestion counters.- VS.RAB.FailEstCS.Relo: CS RAB establishment failures due to relocation; check inter-RAT HO and if the failure point is in RNC border.- VS.RAB.FailEstCS.RIPFail: CS RAB establishment failures due to failure in a radio interface procedure; check the relative RB Setup failure counters to get more details on the failure cause:

- VS.FailRBSetup.CfgUnsup: unsupported configuration (e.g.: UE receives an RB setup request for Video Call while is doing a PS downlink data service. Many terminals do not support simultaneous Video Call and high-speed PS service on the downlink)- VS.FailRBSetup.PhyChFail: physical channel failure; indicates poor coverage- VS.FailRBSetup.CellUpd: cell update occurs (never happens in commercial networks)- VS.FailRBSetup.IncCfg: invalid configuration; some UEs, mainly Sony Ericsson, may cause this- VS.FailRBSetup.NoReply: mainly RF related issue


1. Low CSSR Voice (5)• Congestion problem: following counters indicate lack of radio recourses or Iub bandwidth. Check the

Admission Control thresholds. Take appropriate measures to relieve congestion, e.g. activate LDR, OLC algorithms, and to increase capacity. Refer to Huawei 3G Capacity Optimisation document in IMS [1] for more details on how to battle congestion and improve capacity.

- VS.RAB.FailEstCs.Code.Cong: CS RAB establishment failures due to code congestion- VS.RAB.FailEstCs.Power.Cong: CS RAB establishment failures due to power congestion- VS.RAB.FailEstCs.ULCE.Cong: CS RAB establishment failures due to UL CE congestion- VS.RAB.FailEstCs.DLCE.Cong: CS RAB establishment failures due to DL CE congestion- VS.RAB.FailEstab.CS.DLIUBBand.Cong: CS RAB establishment failures due to UL Iub bandwidth congestion- VS.RAB.FailEstab.CS.ULIUBBand.Cong: CS RAB establishment failures due to DL Iub bandwidth congestion- VS.RAB.FailEstabCS.Unsp.Other: CS RAB establishment failures due to congestion in other resources than the previous 6 cases- VS.RAB.FailEstabCS.RNL.Other: CS RAB establishment failures due to any RNL related reason other than the previous 9 cases

• Any other reason: following counter indicate failure due to any other reason apart from the previous ones

- VS.RAB.FailEstabCS.Other.Cell: CS RAB establishment failures due to any other reason except the previous 11 cases

Note: All previous RAB failure counters include all CS services: AMR and Video Call.

[1] https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D420188465


2. Low CSSR PS (1)

- RNC level formula:PS Call Setup Success Rate (RNC) = (([VS.RRC.SuccConnEstab.OrgInt]+[VS.RRC.SuccConnEstab.OrgBkg]+[VS.RRC.SuccConnEstab.TrmInt]+[VS.RRC.SuccConnEstab.TrmBkg])/([VS.RRC.AttConnEstab.OrgInt]+[VS.RRC.AttConnEstab.OrgBkg]+[VS.RRC.AttConnEstab.TrmInt]+[VS.RRC.AttConnEstab.TrmBkg]))*(([RAB.SuccEstabPSNoQueuing.Intact]+[RAB.SuccEstabPSNoQueuing.Bgrd]+[RAB.SuccEstabPSQueuing.Intact]+[RAB.SuccEstabPSQueuing.Bgrd])/([RAB.AttEstabPS.Intact]+[RAB.AttEstabPS.Bgrd]))*{100}

- Cell level formula:PS Call Setup Success Rate (Cell) = (([RRC.SuccConnEstab.OrgItrCall]+[RRC.SuccConnEstab.OrgBkgCall]+[RRC.SuccConnEstab.TmItrCall]+[RRC.SuccConnEstab.TmBkgCall])/([RRC.AttConnEstab.OrgInterCall]+[RRC.AttConnEstab.OrgBkgCall]+[RRC.AttConnEstab.TmInterCall]+[RRC.AttConnEstab.TmBkgCall]))*(([VS.RAB.SuccEstabPS.Inter]+[VS.RAB.SuccEstabPS.Bkg])/([VS.RAB.AttEstabPS.Inter]+[VS.RAB.AttEstabPS.Bkg]))*{100}

Analysis process:1. Check which part of the CSSR KPI causes the low value: RRC setup, RAB setup or both. The 2 distinct

parts RRC Setup Success Rate and RAB Setup Success Rate that are composing the CSSR can be used for this purpose.

2. To check the above, check the corresponding KPIs for RRC Setup Success Rate and AMR RAB Setup Success Rate.

3. Check the alarms for the serving NodeB and neighbouring sites in order to identify any hardware faults.


2. Low CSSR PS (2)

4. In case that RRC Setup is causing the low value, identify the root cause of high RRC Setup failures by following counters:

• Transmission problem: following counters indicate transmission issue on Iub interface; check relative alarms

- VS.RRC.Rej.RL.Fail: RRC establishment failures due to RL setup failure- VS.RRC.Rej.TNL.Fail: RRC establishment failures due to TNL setup failure

• Radio resource congestion: following counters indicate lack of radio resources or Iub bandwidth. Check the Admission Control thresholds. Take appropriate measures to increase capacity.

- VS.RRC.Rej.Power.Cong: RRC establishment failures due to power load congestion- VS.RRC.Rej.UL.CE.Cong: RRC establishment failures due to UL CE congestion- VS.RRC.Rej.DL.CE.Cong: RRC establishment failures due to DL CE congestion- VS.RRC.Rej.Code.Cong: RRC establishment failures due to code congestion- VS.RRC.Rej.ULIUBBandCong: RRC establishment failures due to UL Iub bandwidth congestion- VS.RRC.Rej.DLIUBBandCong: RRC establishment failures due to DL Iub bandwidth congestion- VS.RRC.Rej.Other.Cong: RRC establishment failures due to other congestion except from the previous 6 reasons

• RF problem: following counter indicate failure due to RF issue. Check coverage in the failure points. Check if it is in cell border (most probably it is).

- RRC.FailConnEstab.NoReply: RRC establishment failures due to no reply from the UE during the RRC setup flow


2. Low CSSR PS (3)

5. In case that R99 PS RAB Setup is causing the low value, identify the root cause of high RAB Setup failures by following counters:

• Transmission problem: following counter indicate transmission issue on Iu-PS interface; check relative alarms

- VS.RAB.FailEstPS.TNL: PS RAB establishment failures due to TNL problem

• RNL related problem: following counters indicate that the failure is due to a RNL procedure problem; includes congestion counters

- VS.RAB.FailEstPS.Par: PS RAB establishment failures due to invalid parameters- VS.RAB.FailEstPS.Relo: PS RAB establishment failures due to relocation; check inter-RAT HO and if the failure point is in RNC border- VS.RAB.FailEstPS.RIPFail: PS RAB establishment failures due to failure in a radio interface procedure; indicates poor RF; check the relative RB Setup failure counters to get more details on the failure cause:

- VS.FailRBSetup.CfgUnsup: unsupported configuration (e.g.: UE receives an RB setup request for Video Call while is doing a PS downlink data service. Many terminals do not support simultaneous Video Call and high-speed PS service on the downlink)- VS.FailRBSetup.PhyChFail: physical channel failure; indicates poor coverage- VS.FailRBSetup.CellUpd: cell update occurs (never happens in commercial networks)- VS.FailRBSetup.IncCfg: invalid configuration; some UEs, mainly Sony Ericsson, may cause this- VS.FailRBSetup.NoReply: mainly RF related issue


2. Low CSSR PS (4)

• Congestion problem: following counters indicate lack of radio recourses or Iub bandwidth. Check the Admission Control thresholds. Take appropriate measures to increase capacity.

- VS.RAB.FailEstPs.Code.Cong: PS RAB establishment failures due to code congestion- VS.RAB.FailEstPs.Power.Cong: PS RAB establishment failures due to power congestion- VS.RAB.FailEstPs.ULCE.Cong: PS RAB establishment failures due to UL CE congestion- VS.RAB.FailEstPs.DLCE.Cong: PS RAB establishment failures due to DL CE congestion- VS.RAB.FailEstab.PS.DLIUBBand.Cong: PS RAB establishment failures due to UL Iub bandwidth congestion- VS.RAB.FailEstab.PS.ULIUBBand.Cong: PS RAB establishment failures due to DL Iub bandwidth congestion- VS.RAB.FailEstabPS.Unsp.Other: PS RAB establishment failures due to congestion in other resources than the previous 6 cases- VS.RAB.FailEstabPS.RNL.Other: PS RAB establishment failures due to any RNL related reason other than the previous 10 cases

• Lack of system resources like memory, high CPU load, etc.- VS.RAB.FailEstPS.NResAvail: PS RAB establishment failures due to shortage on system resources

• Any other reason: following counter indicate failure due to any other reason apart from the previous ones

- VS.RAB.FailEstabPS.Other.Cell: PS RAB establishment failures due to any other reason except the previous 13 cases


3. High Call Drop Rate AMR (1)- RNC level formula:CS AMR Call Drop Rate (RNC) = ([VS.RAB.Loss.CS.AMR.RNC]/[VS.RAB.SucEstCSConv0.32.RNC])*{100}

- Cell level formula:CS AMR Call Drop Rate (Cell) = ([VS.RAB.Loss.CS.AMR]/([VS.RAB.Loss.CS.AMR]+[VS.RAB.Loss.CS.Norm.AMR]))*{100}

Analysis process:1. Identify the call drop causes by checking the following counters:• Call drop due to bad RF: following counters indicate poor coverage- VS.RAB.Loss.CS.RF.RLCRst: CS RAB drops due to RLC reset- VS.RAB.Loss.CS.RF.ULSync: CS RAB drops due to UL synchronization failure- VS.RAB.Loss.CS.RF.UuNoReply: CS RAB drops due to no reply from the UE- VS.RAB.Loss.CS.RF.Oth: CS RAB drops due to other RF reason except from the previous 3 cases

• Call drop due to non-RF reasons- VS.RAB.RelReqCS.OM: CS RAB drops due to OM intervention, e.g. cell was blocked.- VS.RAB.RelReqCS.RABPreempt: CS RAB drops due to preemption; indicates congestion issue in the cell.- VS.RAB.RelReqCS.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.Loss.CS.Aal2Loss: CS RAB drops due to AAL2 failure; check transmission alarms to identify possible faults in the Iu-CS transmission path.- VS.RAB.Loss.CS.Congstion.CELL: CS RAB drops due to overload congestion in the cell (drops are due to OLC algorithm releasing calls in order to decrease the load in the cell); expand system capacity.- VS.Call.Drop.CS.Other: CS RAB drops due to any reason other than the previous 5 cases.


3. High Call Drop Rate AMR (2)

2. In case that the drop is due to RF reasons:- Check for missing neighbors: it is one of the most common causes of drops especially in the initial

launch of a 3G network.- Check for pilot pollution (there should be at least 4 pilots, all of them with CPICH_RSCP higher than -95

dBm and (CPICH_RSCP 1st - CPICH_RSCP 4th)< 5dB) in the area. Strong DL interference can cause call drops. In case pilot pollution exists in the area, try to solve the problem by creating one dominant carrier (adjust tilts and/or azimuths of relative sites).

- Check for UL interference. Strong UL interference can cause drops. 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 whether the interference is internal (from the system) or external.- 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 tilt and/or azimuth appropriately in order to improve signal quality in the area.

3. Check the distribution of call drops in the network; do they appear in specific areas only or throughout the network? Take the list of the TopN worst cells in AMR drops and analyze case by case based on the previous counters.

4. Check the traffic distribution in the problematic areas. Check if there was an abnormal increase of the traffic due to some event.


3. High Call Drop Rate AMR (3)

5. Check alarms/availability not only of the current NodeB but also of the neighbouring ones. Unavailability or faults of neighbouring sites will cause drops due to failed handovers.


4. High Call Drop Rate PS (1)

- RNC level formula:PS Call Drop Rate (RNC) = (([VS.RAB.Loss.PS.RF.RNC]+[VS.RAB.Loss.PS.Abnorm.RNC])/([VS.RAB.Loss.PS.RF.RNC]+[VS.RAB.Loss.PS.Abnorm.RNC]+[VS.RAB.Loss.PS.Norm.RNC]))*{100}

- Cell level formula:PS Call Drop Rate (Cell) = (([VS.RAB.Loss.PS.RF]+[VS.RAB.Loss.PS.Abnorm])/([VS.RAB.Loss.PS.RF]+[VS.RAB.Loss.PS.Abnorm]+[VS.RAB.Loss.PS.Norm]))*{100}

Analysis process:1. Identify the call drop causes by checking the following counters:• Call drop due to bad RF: following counters indicate poor coverage- VS.RAB.Loss.PS.RF.RLCRst: PS RAB drops due to RLC reset- VS.RAB.Loss.PS.RF.ULSync: PS RAB drops due to UL synchronization failure- VS.RAB.Loss.PS.RF.UuNoReply: PS RAB drops due to no reply from the UE- VS.RAB.Loss.PS.RF.Oth: PS RAB drops due to other RF reason except from the previous 3 cases

• Call drop due to non-RF reasons- VS.RAB.RelReqPS.OM: PS RAB drops due to OM intervention, e.g. cell was blocked.- VS.RAB.RelReqPS.RABPreempt: PS RAB drops due to preemption; indicates congestion issue in the cell.- VS.RAB.Loss.PS.GTPULoss: PS RAB drops due to GTPU failure; check transmission alarms to identify possible faults in the Iu-PS transmission path.- VS.RAB.Loss.PS.Congstion.CELL: PS RAB drops due to overload congestion in the cell (drops are due to OLC algorithm releasing calls in order to decrease the load in the cell); expand system capacity.- VS.Call.Drop.PS.Other: PS RAB drops due to any reason other than the previous 4 cases.



2. In case that the drop is due to RF reasons:- Check for missing neighbors: it is one of the most common causes of drops especially in the initial

launch of a 3G network.- Check for pilot pollution (there should be at least 4 pilots, all of them with CPICH_RSCP higher than -95

dBm and (CPICH_RSCP 1st - CPICH_RSCP 4th)< 5dB) in the area. Strong DL interference can cause call drops. In case pilot pollution exists in the area, try to solve the problem by creating one dominant carrier (adjust tilts and/or azimuths of relative sites).

- Check for UL interference. Strong UL interference can cause drops. 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 whether the interference is internal (from the system) or external.- 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 tilt and/or azimuth appropriately in order to improve signal quality in the area.

3. Check the distribution of call drops in the network; do they appear in specific areas only or throughout the network? Take the list of the TopN worst cells in PS drops and analyze case by case based on the previous counters.

4. Check the traffic distribution in the problematic areas. Check if there was an abnormal increase of the traffic due to some event.


5. Low HSDPA Accessibility

- Cell level formula:HSDPA RAB Establishment Success Rate (Cell) = ([VS.HSDPA.RAB.SuccEstab]/[VS.HSDPA.RAB.AttEstab])*{100}

Analysis process:1. Identify the RAB establishment failure causes by checking the following counters:

- HSDPA RAB Establishment Failures Total (Cell)=[VS.HSDPA.RAB.AttEstab]-[VS.HSDPA.RAB.SuccEstab]- VS.HSDPA.RAB.AttEstab: number of HSDPA RAB establishment attempts- VS.HSDPA.RAB.SuccEstab: number of HSDPA RAB establishment successes

• HSDPA RAB establishment failures due to specific reasons:- VS.RAC.NewCallRequest.Fail.HSDPANum.Cong: HSDPA RAB establishment failure due to violation in max HSDPA users allowed. Check if max HSDPA users in the license is equal to the max allowed by the software release (96 users for RAN11).- VS.RAC.HSDPA.Power.Cong: HSDPA RAB establishment failure due to insufficient power resources;

indicates power congestion in the cell. Refer to Huawei 3G Capacity Optimisation document in IMS [1], for details on how to battle power congestion.

Note: There are no HSDPA-specific failure causes apart from the 2 above; the rest of the causes are included in the PS RAB setup failures.



6. Low HSDPA Retainability (1)

- Cell level formula:HSDPA Call Drop Rate (Cell) = (([VS.HSDPA.RAB.Loss.Abnorm.NonRF]+[VS.HSDPA.RAB.Loss.RF])/([VS.HSDPA.RAB.Loss.Abnorm.NonRF]+[VS.HSDPA.RAB.Loss.RF]+[VS.HSDPA.RAB.Loss.Norm]+[VS.HSDPA.RAB.Loss.InActivity]+[VS.HSDPA.ChR.HSDSCHtoDCH]+[VS.HSDPA.ChR.HSDSCHtoFACH]+[VS.HSDPA.HHO.H2D.SuccOutIntraFreq]+[VS.HSDPA.HHO.H2D.SuccOutInterFreq]))*{100}

Analysis process:1. Identify the HSDPA drop causes by checking the following counters:• Call drops due to RF and non-RF reasons:- VS.HSDPA.RAB.Loss.RF: HSDPA RAB drops due to RF reasons; indicates poor coverage- VS.HSDPA.RAB.Loss.Abnorm.NonRF: HSDPA RAB drops due to other than RF reasons- VS.HSDPA.OLC.UserRel: Number of HSDPA users released due to overload congestion control; from user point of view this is a drop, from network’s point of view is a release due to an algorithm (OLC) action

• HSDPA RAB releases due to normal reasons; the following releases are not considered drops- VS.HSDPA.RAB.Loss.Norm: HSDPA RAB normal releases (normal release)- VS.HSDPA.RAB.Loss.InActivity: HSDPA RAB release due to inactivity (normal release)- VS.HSDPA.ChR.HSDSCHtoDCH: HSDPA RAB release due to channel change from HS-DSCH to DCH (normal release)- VS.HSDPA.ChR.HSDSCHtoFACH: HSDPA RAB release due to channel change from HS-DSCH to FACH (normal release)- VS.HSDPA.HHO.H2D.SuccOutIntraFreq: HSDPA RAB release due to intra-frequency hard handover when the target cell does not support HSDPA (normal release)- VS.HSDPA.HHO.H2D.SuccOutInterFreq: HSDPA RAB release due to inter-frequency hard handover when the target cell does not support HSDPA (normal release)


6. Low HSDPA Retainability (2)

2. Check for missing neighbors: it is one of the most common causes of drops especially in the initial launch of a 3G network.

3. Check for pilot pollution (there should be at least 4 pilots, all of them with CPICH_RSCP higher than -95 dBm and (CPICH_RSCP 1st - CPICH_RSCP 4th)< 5dB) in the area. Strong interference can cause call drops.

4. In case pilot pollution exists in the area, try to solve the problem by creating one dominant carrier (adjust tilts and/or azimuths of relative sites).

5. In case of poor coverage, adjust tilt and/or azimuth appropriately in order to improve signal quality in the area.



7. Low HSDPA Serving Cell Change Success Rate

- Cell level formula:HSDPA Service Cell Change Success Ratio with SHO (H2H) = ([VS.HSDPA.SHO.CellChg.SuccOut]/[VS.HSDPA.SHO.CellChg.AttOut])*{100}

Analysis process:1. Check the neighbor configuration: is there a missing neighbor?2. Check the settings of the parameters related to event 1D: Hystfor1D, TrigTime1D. Event 1D is the

event on which the HSDPA serving cell change is based. If the event is not triggered on time the cell change might fail.


8. Low HSDPA Throughput

- RNC level formula:HSDPA Throughput Kbps (RNC) = [VS.HSDPAPSLoad.DLThruput.RNC]

- Cell level formula:HSDPA Throughput Kbps (Cell) = [VS.HSDPA.MeanChThroughput]

Analysis process:1. Check radio environment in the problematic cell; poor coverage is directly related with low HSDPA

throughput.2. Enhance coverage by appropriate tuning of antenna parameters (tilt, azimuth).3. Check for pilot pollution (there should be at least 4 pilots, all of them with CPICH_RSCP higher than -95

dBm and (CPICH_RSCP 1st - CPICH_RSCP 4th)< 5dB) in the area; strong interference limits HSDPA throughput.

4. In case pilot pollution exists in the area, try to solve the problem by creating one dominant carrier (adjust tilts and/or azimuths of relative sites).

5. Check for ping-pong serving cell change based on 1D event: ping-pong limits throughput6. If this is the problem, tune event 1D parameters in order to eliminate ping-pong. Consider also the

value of the HspaTimerLen parameter.7. Check for hardware/software problem in the site: check relative alarms.8. Check transmission network thoroughly: it is not uncommon that there is a bottleneck in the

transmission chain (e.g. too many sites are served by a single low capacity router).9. 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.


9. Low HSUPA Accessibility

- Cell level formula:HSUPA RAB Establishment Success Rate (Cell) = ([VS.HSUPA.RAB.SuccEstab]/[VS.HSUPA.RAB.AttEstab])*{100}

Analysis process:1. Identify the RAB establishment failure causes by checking the following counters:

- HSUPA RAB Establishment Failures Total (Cell)=[VS.HSUPA.RAB.AttEstab]-[VS.HSUPA.RAB.SuccEstab]- VS.HSUPA.RAB.AttEstab: number of HSUPA RAB establishment attempts- VS.HSUPA.RAB.SuccEstab: number of HSUPA RAB establishment successes

• HSUPA RAB establishment failures due to specific reasons:- VS.RAC.NewCallRequest.Fail.HSUPANum.Cong: HSUPA RAB establishment failure due to violation in max HSUPA users allowed. Check if max HSUPA users in the license is equal to the max allowed by the software release (20 users for RAN11).- VS.RAC.HSUPA.Power.Cong: HSUPA RAB establishment failure due to insufficient power resources; indicates power congestion in the cell. Refer to Huawei 3G Capacity Optimisation document in IMS [1], for details on how to battle power congestion.

Note: There are no HSUPA-specific failure causes apart from the 2 above; the rest of the causes are included in the PS RAB setup failures



10. Low HSUPA Retainability

- Cell level formula:HSUPA Call Drop Rate (Cell) = (([VS.HSUPA.RAB.Loss.Abnorm])/([VS.HSUPA.RAB.Loss.Abnorm]+[VS.HSUPA.RAB.Loss.Norm]+[VS.HSUPA.ChR.IntraCell.EDCHtoDCH.Succ]+[VS.HSUPA.ChR.IntraFreq.EDCHtoDCH.Succ]+[VS.HSUPA.ChR.InterFreq.EDCHtoDCH.Succ]+[VS.HSUPA.ChR.EDCHtoFACH.Succ]))*{100}

Analysis process:1. Identify the HSUPA drop causes by checking the following counters:• Call drops:- VS.HSUPA.RAB.Loss.Abnorm: Number of HSUPA RAB abnormal releases (drops)- VS.LCC.OLC.HSUPA.UserRel: Number of HSUPA users released due to overload congestion control; from user point of view this is a drop, from network’s point of view is a release due to an algorithm (OLC) action

• HSUPA RAB releases due to normal reasons; the following releases are not considered drops- VS.HSUPA.RAB.Loss.Norm: HSUPA RAB normal releases (normal release)

2. Check for missing neighbors: it is one of the most common causes of drops especially in the initial launch of a 3G network.

3. Check for UL interference in the problematic area: VS.MeanRTWP will provide average RTWP of cell. Strong UL interference may cause drops.

4. In case of poor coverage, adjust tilt and/or azimuth appropriately in order to improve signal quality in the area.


11. Low HSUPA Serving Cell Change Success Rate

- Cell level formula:E-DCH Service Cell Change Success Ratio with SHO = ([VS.HSUPA.SHO.ServCellChg.Succ]/[VS.HSUPA.SHO.ServCellChg.Att])*{100}

Analysis process:1. Check the neighbor configuration: is there a missing neighbor?2. Check the settings of the parameters related to event 1D: Hystfor1D, TrigTime1D. Event 1D is the

event on which the HSUPA serving cell change is based. If the event is not triggered on time the cell change might fail.


12. Low HSUPA Throughput

- RNC level formula:HSUPA Throughput Kbps (RNC) = [VS.HSUPAPSLoad.ULThruput.RNC]

- Cell level formula:HSUPA Throughput Kbps (Cell) = [VS.HSUPA.MeanChThroughput]

Analysis process:1. Check radio environment in the problematic cell; poor coverage is directly related with low HSUPA

throughput.2. Enhance coverage by appropriate tuning of antenna parameters (tilt, azimuth).3. Check for UL interference in the problematic area: VS.MeanRTWP will provide average RTWP of cell.

UL interference limits HSUPA throughput.4. Check for ping-pong serving cell change based on 1D event: ping-pong limits throughput5. If this is the problem, tune event 1D parameters in order to eliminate ping-pong. Consider also the

value of the HspaTimerLen parameter.6. Check for hardware/software problem in the site: check relative alarms.7. Check transmission network thoroughly: it is not uncommon that there is a bottleneck in the

transmission chain (e.g. too many sites are served by a single low capacity router).


13. Low CS ISHO Success Rate (1)

- RNC level formula:• Preparation phase: CS Inter System HO Preparation Success Rate (RNC) =

([VS.SRELOC.SuccPrep.IRHOCS]/[VS.SRELOC.AttPrep.IRHOCS])*{100}• Execution phase: CS Inter System HO Success Rate (RNC) =

([VS.IRATHO.SuccCSOut.RNC]/[VS.IRATHO.AttCSOut.RNC])*{100}

- Cell level formula:• Preparation phase: CS Inter System HO Preparation Success Rate (Cell) =

[IRATHO.SuccRelocPrepOutCS]/[IRATHO.AttRelocPrepOutCS]*{100}• Execution phase: CS Inter System HO Success Rate (Cell) =

([IRATHO.SuccOutCS]/[IRATHO.AttOutCS])*{100}

CS iRAT handover procedure:- Handover preparation: from point A to B- Handover execution: from point C to D



Analysis process:1. Identify the handover failure cause by checking the following counters:• Preparation phase:- IRATHO.FailRelocPrepOutCS.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)- IRATHO.FailRelocPrepOutCS.TgtFail: 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.HigherTrafficLod: Traffic load in the target cell higher than in the source cell - 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.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.Nrply: Timeout of waiting for IU RELEASE COMMAND messages during an outgoing inter-RAT CS handover



2. Check if there are any missing 2G neighbors

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


14. Low PS ISHO Success Rate (1)

- RNC level formula:Execution phase: PS Inter System HO Success Rate (RNC) = ([VS.IRATHO.SuccPSOutUTRAN.RNC]/[VS.IRATHO.AttPSOutUTRAN.RNC])*{100}

- Cell level formula:Execution phase: PS Inter System HO Success Rate (Cell) = ([IRATHO.SuccOutPSUTRAN]/[IRATHO.AttOutPSUTRAN])*{100}

PS iRAT handover procedure:- Handover preparation: from point A to B- Handover execution: from point B to C


14. Low PS ISHO Success Rate (2)

Analysis process:1. Identify the handover failure cause by checking the following counters:- VS.IRATHO.PSOut.CfgUnsup: unsupported configuration (the configuration assigned in the “CELL CHAGE ORDER FROM UTRAN” is not supported by the UE; check configuration of the encryption parameters; might also be UE problem)- VS.IRATHO.PSOut.PhyCHFail: physical channel failure (indicates RF problem: check interference in

target 2G cell; also indicates problem in 2G cell; check alarms and KPIs in the target 2G cell; check iRAT HO configuration of target cell)- VS.IRATHO.PSOut.Unpec: unspecified (check SGSN configuration; might also be UE problem)- VS.IRATHO.PSOut.NoReply: no reply (check RF of target cell; check how long the RAU procedure takes

(a DT is needed for that), if too long the relative timer expires and the counter measures)

2. Check if there are any missing 2G neighbors

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


15. Low IFHO Success Rate (1)

- RNC level formula:Inter Frequency HO Success Rate (RNC) = ([VS.HHO.InterFreq.Succ.RNC]/[VS.HHO.InterFreq.Att.RNC])*{100}

- Cell level formula:• Outgoing: Inter Frequency HO Success Rate (Cell) =

[VS.HHO.InterFreq.SuccOut]/[VS.HHO.InterFreq.AttOut]*{100}• Incoming: Inter Frequency HO Success Rate (Cell) =

([VS.HHO.InterFreqIn.Succ]/[VS.HHO.InterFreqIn.Att])*{100}

Analysis Process:1. Identify the inter-frequency handover failure cause by checking the following counters:- VS.HHO.InterFreqOut.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.InterFreqOut.PyhChFail: Physical channel failure (indicates poor coverage)- VS.HHO.InterFreqOut.FailUSR: 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.InterFreqOut.CellUpdt: Cell update occurred (this case never happens in commercial network)- VS.HHO.InterFreqOut.CfgInvalid: Invalid configuration (some IEs in the “PHYSICAL CHANNEL RENONFIGURATION” message are invalid for the UE; this case almost never happens; indicates possible UE problem)


15. Low IFHO Success Rate (2)

- VS.HHO.InterFreqOut.DLCodeRej: DL code resource allocation failure- VS.HHO.InterFreqOut.ULAdmsnDeny: UL admission rejected (indicates UL congestion in the target cell)- VS.HHO.InterFreqOut.DLAdmsnDeny: DL admission rejected (indicates DL congestion in the target cell)- VS.HHO.InterFreqOut.NoReply: No response on the air interface (indicates poor coverage or even a UE problem) 2. Check if there are any missing neighbors

3. Check the inter-frequency handover parameters; improper settings may cause the handover not to be performed on time: events 2D/2F parameters, events 2B, 2C parameters


16. Low HSDPA IFHO Success Rate

- RNC level formula:HS-DSCH Service Cell Change Success Rate with Inter HHO (RNC) = (SUM[VS.HSDPA.HHO.SuccOutInterFreq]/SUM[VS.HSDPA.HHO.AttOutInterFreq])*{100}

- Cell level formula:HS-DSCH Service Cell Change Success Rate with Inter HHO (Cell) = ([VS.HSDPA.HHO.SuccOutInterFreq]/[VS.HSDPA.HHO.AttOutInterFreq])*{100}

Analysis Process:1. Check if there are any missing neighbors

2. Check the inter-frequency handover parameters; improper settings may cause the handover not to be performed on time: events 2D/2F parameters, events 2B, 2C parameters

3. Check the IFHO failure counters to get more info on the possible failure causes (there are not IFHO HSDPA-specific failure counters)


17. Low coverage (low RSCP vs. propagation delay)

Analysis Process:1. Contact drive test in the area of poor coverage to confirm the problem. From drive test measure RSCP

vs. Propagation delay. If RSCP is low while Propagation delay is low as well, this indicates poor coverage close to the base station.

2. Survey the environment: check for shadowing effect caused by big obstacles in the area. This might cause low signal strength even close to the NodeB. Analyse the multipath environment in the area: in dense urban strong multipath may cause deep signal fades (fast fading).

3. Adjust antenna parameters (tilt, azimuth) appropriately in order to optimise the coverage in the problematic area.

4. Check the NodeB hardware equipment. Faulty TRX may cause poor signal strength. Check the alarms.5. Check the CPICH power setting. Default value is 33 dBm. Consider increase of the value if possible.6. Consider 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.


18. High interference (low EcNo (CQI) vs. good RSCP)

Analysis Process:1. Check for pilot pollution in the area: there should be at least 4 pilots, all of them with CPICH_RSCP

higher than -95 dBm and (CPICH_RSCP 1st - CPICH_RSCP 4th)< 5dB.2. In case pilot pollution exists in the area, try to solve the problem by creating one dominant carrier

(adjust tilts and/or azimuths of relative sites).3. Check for missing neighbours: missing neighbours can cause increase of interference in the source

cell.4. Check whether the interference is from an external source: check for nearby sources of E/M radiation:

TV/Radio stations, Military, Civil aviation, etc.


THANK YOU

huawei-performance-monitoring-and-analysis

Technology