122642277 performance monitoring

8/12/2019 122642277 Performance Monitoring

http://slidepdf.com/reader/full/122642277-performance-monitoring 1/98

For internal use only

1 © Nokia Siemens Networks /

Ericsson 3G Radio Performance MonitoringRadio Performance Monitoring, Instructions

Multivendor Program

July 2010




2 © Nokia Siemens Networks

Document InfoTitle Radio Performance monitoring, Ericsson 3G

Reference NSN MS, CM, MV team

Target Group NPO UTRAN

Technology WCDMA, Ericsson

Software Release P7

Service 3G RAN network optimization

Service Item Radio Network Optimization Service delivery

Related Working Items RAN Optimization

Author Tommy Lundgren

Email [email protected]

Version Ver. 1.0

Version Date 28 July 2010

Presentation / Author / Date

Version Date Edited by Section Comment

0.9 28 July 2010 Tommy Lundgren All First Draft

1.0 14 August 2010 Tommy Lundgren All Second Draft

mailto:[email protected]

mailto:[email protected]





Contents Objectives

Scope of document

Prerequisites/ requirements for performance monitoring

Service Delivery, Online modeo Items Checklist

o Introduction to OSS-RC tools

oTask in Step-by-step

oPerformance monitoring outputs, reporting

Appendix:o Appendix 1: Embedded reference documentation

oEricsson OSS-RC overview






Objective

The objective of the performance monitoring is to monitor RAN performance and identify

faulty, non performing or poor performing network elements, RNC, Node B’s, cells etc. RANperformance will be monitored for the following types of performance “checks” :

Accessibility, RAN accessibility at initial network access, call setup and other services establishment.

Retainability, call or other bearer service completion successes or failures.

Mobility, successes or failures whilst UE’s are transported within the network.

Integrity, call or other bearer services transmission quality, speech quality, throughput rates etc.

Performance monitoring activity identifies problematic network elements, investigates rootcauses to problems based on available input data( mainly performance statistics) andsuggests changes that needs to be made in order to correct non optimal operation ofnetwork elements.

Output

The output of the Performance monitoring activity is:

List of network elements that are faulty, non performing or poor performing, that needs to be fixed.

Suggested actions to resolve problems or non optimal operation, based on initial root cause analysis


Objective





Contents Objectives

Scope of document













Scope of document

Performance Monitoring, Radio performance

The Scope of the instruction includes:• RAN KPI monitoring and analysis• Problem identification and problem solution

The following is not-within the scope of this instruction:

• Drive test KPI Monitoring• ISHO/IRAT optimization• Detailed troubleshooting• Solution implementation verification

Typically there are 3 levels of KPI monitoring1. KPI/PI from RNC/BSS2. OSS Special measurement/Traces

3. Detailed Troubleshooting (protocol analyzer etc)

Scope





Radio performance monitoring procedure, “On-line mode”

BSCBSC

BSCBSCNEM “On-line mode”, direct connection or access to OSS-RC

GUI and tools. Using the OSS GUI and tools for PM work

Performance monitoringScope

OSS

PM export

interface

-Import

- Export

Save report

template

RNO (ONE)NWS or BO

Generate report

External/ Officeapplications, MS

Access, MS Excel,Business Objects

Etc.

Output:

RANPerformanceReport

Analysis

Manipulation

PM – • Performance monitoring

CM –

• Parameter check

•Parameter changes

Create report:

NW element,

KPI, date -

selection





Radio performance monitoring procedure, “Offline mode”

BSCBSC

BSCBSCNEM

“Off -line mode”, no direct connection or access to OSS-RC GUI and tools. Using OSS “external” tools for work.


OSS

OSS export,CLI

PM stats file

(3GPP XML files)

RAN performancestatistical data

File Postprocessing

XML parsing

AnalysisPM –

• Performance monitoring•

Manipulation

Office applications,MS Access, MS

Excel Etc.

Output:






Contents Objectives

Scope of document













Radio performance monitoring


Prerequisites/ Inputs for the Radio Performance monitoringThe following scope and information must already be agreed and in the scope of work, or similar service contract

documentation, for the service delivery and available as inputs to the Radio Performance monitoring(procedures as described in this document). The service delivery and methodologies in this document cannot be executed without this information agreed and available as input:

Scope of the project Agreed Network element level/ depth to be assessed

Geographical area set by OSS, RNC’s etc (Optional)

RAN Feature Functionality, if any specific features in or out of scope of delivery

Customer inputsInformation/ data provided to service delivery by customer based on scope of work or delivery contract/

specification.

1. List of NEs (RNCs or BTS)s to be included in performance monitoring activity

2. Agreed KPI thresholds and targets

3. Other supporting vendor documentation (on a need be basis e.g. counter and/ or KPI dictionary)

Performance monitoring method based on available tools and OSS access Direct OSS access - online assessment

PM statistics file dump - offline assessment

Note: In case of offline assessment customer parameter dump file and formats needs to have beenagreed in scope of work or service delivery contract discussions.

RNC-01

RNC-03

RNC-02

Prerequisites





Contents Objectives

Scope of document













Radio performance monitoring procedure, “On-line mode”

BSCBSC

BSCBSCNEM “On-line mode”, direct connection or access to OSS-RC

GUI and tools. Using the OSS GUI and tools for PM work


OSS

PM export

interface

-Import

- Export

Save report

template

RNO (ONE)NWS or BO

Generate report

External/ Officeapplications, MS

Access, MS Excel,Business Objects

Etc.

Output:


Analysis

Manipulation

PM – • Performance monitoring

CM –

• Parameter check

•Parameter changes

Create report:

NW element,

KPI, date -

selection





Procedure performance monitoringChecklist, Service delivery


STEP TYPE DESCRIPTION TOOL RESPONSIBLE

1 Input Get Customer Input data (SW level, Service, Technology) N/A Customer Team

2 Activity Define KPIs + KPI formulas N/A Radio Planner

3 Input Get agreement on KPI target/Guarantees for assessment N/A Customer Team

4 Activtity Implement and activate measurement data collection ( Move to Annex) OSS RC Radio Planner

4.1 Activity Activate standard measurement from OSS

OSS RC

Radio Planner

4.2 Activity Activating optional measurement from OSS OSS RC Radio Planner

5 Activity Perform Data analysis and Assessment Business Object Radio Planner

6 Decision Low Call Setup Succes Rate for Voice and Rel99 NRT DCH (flow chart with new RU10counters) N/A Radio Planner

7 Decision High Call Drop Rate for AMR and Rel99 NRT DCH (flow chart with new RU10 counters) N/A Radio Planner

8 Decision Low HSDPA Accessibility N/A Radio Planner

9 Decision Low HSDPA Retainability N/A Radio Planner

10 Decision Low HSDPA Serving Cell Change Success Rate N/A Radio Planner

11 Decision Low HSDPA Throughput N/A Radio Planner

12 Decision Low HSUPA Accessibility N/A Radio Planner

13 Decision Low HSUPA Retainability N/A Radio Planner

14 Decision Low HSUPA SCC success ratio N/A Radio Planner

15 Decision Low HSUPA Throughput N/A Radio Planner

16 Decision Low ISHO success rate N/A Radio Planner

17 Decision Low AMR/Rel99 NRT DCH IFHO Success rate N/A Radio Planner

18 Decision Low HSDPA IFHO Success Rate N/A Radio Planner

19 Activity Next Step Proposal Word Doc Radio Planner

20 Output Produce Executive Summary KPI Report





3G KPI performance analysis use cases

1. Low Call Setup Success Rate for Voice and Rel99 NRT DCH

2. High Call Drop Rate for AMR and Rel99 NRT DCH3. Low HSDPA Accessibility

4. Low HSDPA Retainability

5. Low HSDPA Serving Cell Change Success Rate

6. Low HSDPA Throughput

7. Low HSUPA/EUL Accessibility8. Low HSUPA/EUL Retainability

9. Low HSUPA/EUL SCC success ratio

10. Low HSUPA/EUL Throughput

11. Low ISHO success rate

12. Low AMR/Rel99 NRT DCH IFHO Success rate

13. Low HSDPA IFHO Success Rate14. Low coverage (low RSCP vs propagation delay)

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





Performance Analysis

Methodology Performance analysisThis document is using a drill down approach to performance monitoring and analysis. Starting with analysis

of KPI’ at the highest level in the RAN hierarchy, then drilled down to lower levels based on root causeanalysis:

Analysis

Weekly KPI( PLMN)

< X %

No action

needed

No

Yes

Yes

No

System level, PLMN

WeeklyKPI

(RNC)< X % ?

RAN level, RNC, BSC

Daily

KPI(WCEL)

< X%

Identify Call failurephases of badperforming KPIs,for example CSSR

Identify failures root-causes and failuredistribution of bad KPIs

Identify Top50 WorstCells based on

highest number ofroot causes failures

Node level, WCEL, BTS Other 3G RAN Reports

Other 3G RAN Reports YesNode level, WCEL, BTS

Solution

Proposal






Low CSSR, voice and NRT R99PLMN and RAN level

1. Trigger: Call Setup Success rate low based on aggregated cell level KPI’s: voice:E_CRRC_CSASR_1, NRT R99: E_CRAB_PSASR_1

2. Root cause analysis, signaling:

a) Low signaling success rate RNC’s:

Signaling success rate, total CS and PS RNC, E_CRRC_CSPS_SSR_1 < xx %Analysis and potential solution:

Check core and transmission network outage and performance stats, any major networkreconfigurations?

b) Non-signaling related, continue root cause at node level.

3. Root cause analysis, mobility:

a) Low HO success rate

RNC aggregated multi RAB SHO stats, E_CSHO_SR_1 < zz %

RNC aggregated speech IFHO stats, E_SPIFHO_SR_1 < zz %

RNC aggregated multi RAB IRAT stats, E_CMSIRAT_SR_1 < zz %

Analysis and potential solution:

Has there been any major parameter change to RNC’s or LA/ RA i.e. re-home, re-dimensioning or redesign of LA or RNC plan? Or just inconsistent RNC border area HO parameter settings. System SWupgrade?

Analysis






Low CSSR, voice and NRT R99PLMN and RAN level

4. Root cause analysis, capacity:

a) Abnormal RRC/ RAB blocking, RNC:

RNC aggregated CS RRC blocking stats, E_CCSRRC_BLK_1 > zz %

RNC aggregated PS RRC blocking stats, E_CPSRRC_BLK_1 > zz %

RNC aggregated CS RAB blocking stats, E_CCSRAB_BLK_1 > zz %RNC aggregated PS RAB blocking stats, E_CPSRAB_BLK_1 > zz %


Non-sufficient capacity in area, resource upgrade necessary.

Analysis






Low CSSR, voice and NRT R99Cell level

1. Trigger: Call Setup Success rate low based on cell level KPI’s: voice:E_CRRC_CSASR_1, NRT R99: E_CRAB_PSASR_1

2. Check cell and neighbor cell alarms and performance alarms

3. Root cause analysis, RRC/ RAB establishment failures:

a) Low RRC/ RAB establishment success rate cell: RRC establishment success rate: E_CRRC_RRCSR_1 < xx %

RAB establishment success rate voice: E_CCSRAB_RABSR_1 < zz%

RAB establishment success rate NRT: E_CPSRAB_RABSR_1 < zz%

b) RRC establishment failures due to blocking:

RRC blocking due to Admission: Rrc_Blocking > xz %

RRC blocking due to CE: RRC_blocking_CE_rate > xz %

c) RAB establishment failures due to blocking:

RAB blocking due to max number of connections: Cell_Conn_limit_R > zx %

RAB blocking due to code blocking: Rab_Blocking > zx %


RRC/ RAB establishment failures excessive, blocking/ congestion indicated and additional capacityneeds to be added, alternatively parameterization for cell load sharing or traffic distribution. Reference

Ericsson 3G Capacity optimization process…..

Analysis






Low CSSR, voice and NRT R99Cell level

5. Root cause analysis, coverage or interference limited cell: Numbering…

a) Coverage limited cell:

Reported low average RSSI, AvgRssiAvg_BH < -95 dBm

b) Interference limited cell:

Reported high distribution of UE’s at cell edge or at coverage border: Cell_UE_dist _Dy Reported potential cell breathing/ interference limited cell, based on UE distribution:Cell_UE_dist_norm_Dy - Cell_UE_dist_norm_BH > 15 [%]


Then UE traffic distribution is indicating cell shrinkage during busy hour, UE’s served closer to cell in BH vs. nonbusy hour.

This might in turn indicate cell and neighbors are interference limited, UL or DL and hence soft capacity blocking.

This is verified with for example: SUP_fail , Setup failures increasing significantly in Busy hour for these cells.

Are there options of redistributing traffic to neighbor cells?

More likely and effective option might be changing physical configuration to contain serving cell or neighboring cells,by changing cell coverage areas, downtilts, azimuth or antenna model changes. In order to minimize the cellbreathing effect in the area, by re-distributing RF( interference) and UE’s to better contained cells.

Analysis






High DCR, AMR and NRT R99 DCHPLMN and RAN level

1. Trigger: excessive call drop rate based on aggregated cell level KPI’s: AMR:E_CCSDCR_1, NRT R99: E_CPSDCR_1

2. Root cause analysis, poor drop call performance RNC level:

a) Drop due to sync and transmission network:

Drop call rate due to sync, aggregated cell statistics, E_CCSDCR_US_1 > xx %Analysis and potential solution:

Drops due to synch indicating issues in transmission or core network.

Verify RNC, LA and RA area based changes, has there been any major system wide changes, re-homing, RNC’s added or redesigned.

Known performance issues on this RNC, transmission network?

3. Root cause analysis RNC, mobility:

a) Drops due mobility issues:

Drops due to inability to add AS neighbor, aggregated cell stats, E_CCSDCR_AN_1 > zz %

Drops due to missing neighbor, aggregated cell stats, E_CCSDCR_MN_1 > zz %


Statistics indicating cells in RNC having abnormal level of drops due to active set or neighbordefinitions. Has there been any major parameter change to RNC’s or LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan? SW update?

Analysis






High DCR, AMR and NRT R99 DCHCell level

1. Trigger: excessive call drop rate based on cell level KPI’s: AMR: E_CCSDCR_1, NRTR99: E_CPSDCR_1


3. Root cause analysis, poor performance HW, transmission or core NW:

a) Drop due to sync and transmission network: Drop call rate due to sync, cell statistics, E_CCSDCR_US_1 > xx %


Drops due to synch indicating issues in transmission, core network or WRBS HW issues.

Verify synch related alarms on WRBS. Verify RNC, LA and RA area based changes, has there beenany major system wide changes, re-homing, RNC’s added or redesigned.

Known performance issues on RNC or transmission network?

Analysis








a) Drops due mobility issues:

Drops due to inability to add AS neighbor, cell stats, E_CCSDCR_AN_1 > zz %

Drops due to missing neighbor, cell stats, E_CCSDCR_MN_1 > zz %

Analysis and potential solution:Statistics indicating cells in RNC having abnormal level of drops due to active set or neighbordefinitions. Has there been any major parameter change to RNC’s or LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan?

5. Root cause analysis, missing neighbors:

a) Drops due to missing neighbors, WNCS statistics:

Missing neighbors leading to a dropped connection: numberOfDrops < zz (kbps)

Analysis and potential solution:WNCS report can be used to identify missing neighbors that if added could have avoided a droppedconnection. Missing neighbors with reported dropped connections, should preferably be added asneighbors.

Analysis







6. Root cause analysis, problematic neighbor cell relations:

a) Excessive RL addition failures, WNCS statistics:

Non-coverage limited cell: averageRSCP > 85 [dBm]

Non-interference limited cell: averageCPICHEcNo > 12 [dB]

Missing neighbors leading to a dropped connection: Rladd_fail_R_Wncs > 2 [%]Analysis and potential solution:

WNCS report can be used to identify problematic neighbor relations. Coverage and interference limitedcells should be filtered out, non-relevant, since poor coverage or excessive interference leads toperformance issues aswell.

If problem neighbor is located in different RNC or OMC, check external neighbor definitions andrelevant RNC/ system parameter settings.

If cell is in same RNC, LAC and RAC, investigate problem further, if no problem can be identified,remove neighbor from neighbor list and re-run WNCS recording and re evaluate removal.


a) Drops due to capacity limitations:

Drops due to congestion, cell stats, E_CCSDCR_BLK_1 < zz %


Cell seems to have a high rate of dropped calls due to congestion. Verify cell capacity and ensure there

is sufficient resources for served traffic.

Analysis







8. Root cause analysis, RF performance:




Reported high distribution of UE’s at cell edge or at coverage border: Cell_UE_dist _DyReported potential cell breathing/ interference limited cell, based on UE distribution:Cell_UE_dist_norm_Dy - Cell_UE_dist_norm_BH > 15 [%]







Analysis








a) Correlation of BER and RF statistics, WMRR measurements:

Detailed cell level BLER measurements: UL and DL BLER measurements

Detailed cell level UE TX measurements: UE Tx power measurement:

Detailed cell level EcIo measurements: CPICH Ec/NoDetailed cell level RSCP measurements: CPICH RSCP


Performing WMRR measurements for problem cells is an additional source for trouble shooting, drops and RF relatedissues.

Looking at UE reported BLER, TX pwr, EcIo and RSCP can give an indication if it really is the RF environment thatare causing excessive dropped connections, or if the problem is at a higher level.

Correlation of these performance measurements is a good way of identifying RF related problems.

Analysis






Low HSDPA AccessibilityPLMN and RAN level

1. Trigger: excessive call drop rate based on aggregated cell level KPI’s:E_CRAB_HSASR_1 & E_CRAB_HSASR_1



Signaling success rate, total CS and PS RNC, E_CRRC_CSPS_SSR_1 < xx %Congestion or transport network related issues: pmNoOfIurTermHsCong > yy %,pmHsSevereCong(IubLink) > yy %, pmHsSevereCong(IurLink) > yy %




3. Root cause analysis, availability:a) Low HS availability

RNC aggregated HS availability stats, Av_HS(Hsdsch) < zz (sec)


Abnormally Low HS availability in an RNC could indicate system wide problems and outages,transmission or core network interruptions? Has there been any major parameter change to RNC’sor LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan? Or just inconsistent RNC

border area HO parameter settings.

Analysis






Low HSDPA AccessibilityPLMN and RAN level


a) Low CC and HO success rate

RNC aggregated cell HS cell change stats, PSb_M _ HSCC _ S(UtranCell ) < zz %

RNC aggregated cell HS IFHO stats, E_SPIFHO_SR_1 < zz %


Abnormal mobility success rate might indicate system wide performance or configuration issue, orperformance issues related to controller border.

Has there been any major parameter change to RNC’s or LA/ RA i.e. re-home, re-dimensioning or redesign of LA or RNC plan? Or just inconsistent RNC border area HO parameter settings.

4. Root cause analysis, low throughput:

a) Low average throughput

RNC aggregated cell HS stats, E_CHS_DLTH_1 < zz (kbps)RNC aggregated cell HS stats, Rab_Blocking_Hs(UtranCell) > xx %


Abnormal low throughput in an RNC should be investigated further, is there a system wide or RNCperformance issue, or are there cells in RNC with exceptional bad performance?

Has there been any major parameter change to RNC’s or LA/ RA i.e. re-home, re-dimensioning or redesign of LA or RNC plan? Or just inconsistent RNC HS parameter settings.

Analysis






Low HSDPA AccessibilityCell level

1. Trigger: excessive call drop rate based on cell level KPI’s: E_CRAB_HSASR_1 &E_CRAB_HSASR_1


3. Root cause analysis, availability:

a) Low HS availabilityCell HS availability stats, Av_HS(Hsdsch) < zz (sec)


Check serving and neighbor cells for abnormally Low HS availability is an obvious performanceimpacting issue. Cell having outages regularly? HW fault?



Signaling success rate, total CS and PS RNC, E_CRRC_CSPS_SSR_1 < xx %

Congestion or transport network related issues: pmNoOfIurTermHsCong > yy %,pmHsSevereCong(IubLink) > yy %, pmHsSevereCong(IurLink) > yy %



Analysis









Cell HS cell change stats, PSb_M _ HSCC _ S(UtranCell ) < zz %

Cell HS IFHO stats, E_SPIFHO_SR_1 < zz %




Verify or update neighbor lists, check external cell definitions on controller border cells.


a) Low average throughputCell HS stats, E_CHS_DLTH_1 < zz (kbps)

Cell HS stats, Rab_Blocking_Hs(UtranCell) > xx %


Abnormal low throughput in a cell, is the average throughput decreased? Is there sufficient capacity,cell having blocking problems?

If cell is resource limited, increase license limits or add resources, HW elements.

Analysis











Reported high distribution of UE’s at cell edge or at coverage border: Cell_UE_dist _Dy

Reported potential cell breathing/ interference limited cell, based on UE distribution:Cell_UE_dist_norm_Dy - Cell_UE_dist_norm_BH > 15 [%]







Analysis






Low HSDPA RetainabilityPLMN and RAN level

1. Trigger: excessive drop rate based on aggregated cell level KPI’s: E_CHSDCR_1 &E_CPSDCR_1













Analysis






Low HSDPA RetainabilityPLMN and RAN level














Analysis






Low HSDPA RetainabilityCell level

1. Trigger: excessive call drop rate based on cell level KPI’s: E_CHSDCR_1 &E_CPSDCR_1












Analysis
















a) Drops due to missing neighbors, WNCS statistics:Missing neighbors leading to a dropped connection: numberOfDrops < zz (kbps)


WNCS report can be used to identify missing neighbors that if added could have avoided a droppedconnection. Missing neighbors with reported dropped connections, should preferably be added asneighbors.

Analysis

P f A l i







7. Root cause analysis, problematic neighbor cell relations:




Missing neighbors leading to a dropped connection: Rladd_fail_R_Wncs > 2 [%]




If cell is in same RNC, LAC and RAC, investigate problem further, if no problem can be identified,remove neighbor from neighbor list and re-run WNCS recording and re evaluate removal.

Analysis

P f A l i














When UE traffic distribution is indicating cell shrinkage during busy hour, UE’s served closer to cell in BH vs. nonbusy hour.





Analysis

P f A l i






Low HSDPA Serving Cell Change Success RatePLMN and RAN level

1. Trigger: Low Serving cell change success rate based on aggregated cell level KPI’s:E_CHSCCI_SR_1 & E_CHSCCS_SR_1













Analysis

P f A l i



For internal use only38 © Nokia Siemens Networks /


Low HSDPA Serving Cell Change Success RatePLMN and RAN level














Analysis

P f A l i





Low HSDPA Serving Cell Change Success RateCell level

1. Trigger: Low HSDPA Serving Cell Change Success rate based on cell level KPI’s:E_CHSCCI_SR_1 & E_CHSCCS_SR_1





Check serving and neighbor cells for abnormally low HS availability is an obvious performanceimpacting issue. Cell having outages regularly? HW fault?







Analysis

P f A l i


















Analysis

P f A l i










Detailed cell level EcIo measurements: CPICH Ec/No

Detailed cell level RSCP measurements: CPICH RSCP


Performing WMRR measurements for problem cells is an additional source for trouble shootingmobility, drops etc related to RF issues.

Looking at UE reported BLER, TX pwr, EcIo and RSCP can give an indication if it really is the RFenvironment that are causing poor cell change performance connections, or if the problem is at ahigher level.


Analysis





Low HSDPA ThroughputPLMN and RAN level

1. Trigger: Low HSDPA throughput based on aggregated cell level KPI’s: E_CHS_DLTH_1 & Avg_Pkt_Thpt_HS













Analysis






Low HSDPA ThroughputPLMN and RAN level














Analysis






Low HSDPA ThroughputCell level

1. Trigger: Low HSDPA Throughput based on cell level KPI’s: E_CHS_DLTH_1 & Avg_Pkt_Thpt_HS



a)Low HS availability

Cell HS availability stats, Av_HS(Hsdsch) < zz (sec)


Check serving and neighbor cells for abnormally low HS availability is an obvious performanceimpacting issue. Cell having outages regularly? HW fault?







Analysis








a) Cell in blocking/ congestion

RRC CS/ PS blocking, E_CCSRRC_BLK_1 > 2 [%], E_CPSRRC_BLK_1 > 4 [%]

RAB CS/ PS blocking, E_CCSRAB_BLK_1 > 2 [%], E_CPSRAB_BLK_1 > 4 [%]


Thresholds indicating cell is experiencing congestion, heavily loaded in general. Continue root cause toidentify what the capacity bottle neck is and ensure blocking/ capacity is addressed and prevented.

b) Licensed max number of users exceeded

Number of HS users, Hs_Users > 16 [simultanous users]


If suggested threshold is exceeded, verify license, increase if possible, else add HW, HS-TX card.

License/ parameter upgrade 32, 48 or 96.c) Excessive number of users cell

If HS_Users increases( trending up) and Pint HS _ I _ DlTp _User increases (trending up) ORAvg_HS_Users_Sched_2ms_TTI increases


Verify hardware configuration and consider HS-TX card upgrade.

Analysis







6. Root cause analysis, RF performance 1:










Are there options of redistributing traffic to neighbor cells?More likely and effective option might be changing physical configuration to contain serving cell or neighboring cells,by changing cell coverage areas, downtilts, azimuth or antenna model changes. In order to minimize the cellbreathing effect in the area, by re-distributing RF( interference) and UE’s to better contained cells.

Analysis







7. Root cause analysis, RF performance 2:










Analysis






Low HSUPA/ EUL AccessibilityPLMN and RAN level

1. Trigger: Low accessibility rate based on aggregated cell level KPI’s: E_CRAB_EFASR_1









a) Low EUL availabilityRNC aggregated EUL availability stats, E_CCEFUAV_1 < zz [sec] & pmEulDowntimeMan < yy[sec]


Abnormally Low Eul availability in an RNC could indicate system wide problems and outages,transmission or core network interruptions? Has there been any major parameter change to RNC’sor LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan?

Analysis






Low HSUPA/ EUL AccessibilityPLMN and RAN level



RNC aggregated cell Eul cell change stats, E_CEFCCSI_SR_1 < zz %

RNC aggregated cell Eul IFHO stats, PS_M_Eul_Hho_R < zz %






RNC aggregated cell Eul stats, Avg_Pkt_Thpt_Eul < zz [kbps]RNC aggregated cell Eul stats, Rab_Blocking_Eul(UtranCell) > xx [%]




Analysis






Low HSUPA/ EUL AccessibilityCell level

1. Trigger: Low accessibility rate based on cell level KPI’s: E_CRAB_EFASR_1



a) Low EUL availability

Cell EUL availability stats, E_CCEFUAV_1 < zz [sec] & pmEulDowntimeMan < yy[sec]Analysis and potential solution:

Check serving and neighbor cells for abnormally Low EUL availability is an obvious performanceimpacting issue. Cell having outages regularly? HW fault?




Congestion or transport network related issues: pmNoUlIubLimitEul , pmNoOfIurTermHsCong > yy %,pmHsSevereCong(IubLink) > yy %, pmHsSevereCong(IurLink) > yy %



Analysis





Low HSUPA/ EUL AccessibilityCell level












Analysis






Low HSUPA/ EUL RetainabilityPLMN and RAN level

1. Trigger: excessive drop rate based on aggregated cell level KPI’s: PintEul_R_D



Signaling success rate, total CS and PS RNC, E_CRRC_CSPS_SSR_1 < xx [%]

Congestion or transport network related issues: pmNoUlIubLimitEul > zz[%],pmNoOfIurTermHsCong > yy[%], pmHsSevereCong(IubLink) > yy[%], pmHsSevereCong(IurLink) >yy[%]




3. Root cause analysis, availability:a) Low EUL availability

RNC aggregated EUL availability stats, E_CCEFUAV_1 < zz [sec] & pmEulDowntimeMan < yy[sec]


Abnormally Low EUL availability in an RNC could indicate system wide problems and outages,transmission or core network interruptions? Has there been any major parameter change to RNC’sor LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan? Or just inconsistent RNC


Analysis






Low HSUPA/ EUL RetainabilityPLMN and RAN level4. Root cause analysis, mobility:


RNC aggregated cell EUL cell change stats, E_CEFCCSI_SR_1 < zz [%]

RNC aggregated cell EUL IFHO stats, PS_M_Eul_Hho_R < zz [%]










Analysis






Low HSUPA/ EUL RetainabilityCell level1. Trigger: excessive call drop rate based on cell level KPI’s: PintEul_R_D



a) Low HS availability

Cell EUL availability stats, E_CCEFUAV_1 < zz [sec] & pmEulDowntimeMan < yy[sec]Analysis and potential solution:

Check serving and neighbor cells for abnormally Low EUL availability is an obvious performanceimpacting issue. Cell having outages regularly? HW fault?




Congestion or transport network related issues: pmNoUlIubLimitEul , pmNoOfIurTermHsCong > yy %,pmHsSevereCong(IubLink) > yy %, pmHsSevereCong(IurLink) > yy %



Analysis






Low HSUPA/ EUL RetainabilityCell level5. Root cause analysis, mobility:


Cell EUL cell change stats, E_CEFCCSI_SR_1 < zz [%]

Cell EUL IFHO stats, PS_M_Eul_Hho_R < zz [%]






a) Drops due to missing neighbors, WNCS statistics:Missing neighbors leading to a dropped connection: numberOfDrops < zz [numb]



Analysis





Low HSUPA/ EUL RetainabilityCell level8. Root cause analysis, RF performance:











Analysis






Low HSUPA/ EUL Serving Cell Change Success Rate

PLMN and RAN level1. Trigger: Low Serving cell change success rate based on aggregated cell level KPI’s:E_CEFCCSI_SR_1 < zz [%] & PS_M_Eul_Hho_R < zz [%]








3. Root cause analysis, availability:a) Low EUL availability



Abnormally Low EUL availability in an RNC could indicate system wide problems and outages,transmission or core network interruptions? Has there been any major parameter change to RNC’sor LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan? Or just inconsistent RNCborder area HO parameter settings.

Analysis






Low HSUPA/ EUL Serving Cell Change Success RatePLMN and RAN level4. Root cause analysis, mobility:













Analysis






Low HSUPA/ EUL Serving Cell Change Success RateCell level1. Trigger: Low HSDPA Serving Cell Change Success rate based on cell level KPI’s:

E_CEFCCSI_SR_1 < zz [%] & PS_M_Eul_Hho_R < zz [%]




Cell EUL availability stats, E_CCEFUAV_1 < zz [sec] & pmEulDowntimeMan < yy[sec]


Check serving and neighbor cells for abnormally low EUL availability is an obvious performanceimpacting issue. Cell having outages regularly? HW fault?




Congestion or transport network related issues: pmNoUlIubLimitEul > zz[%], pmNoOfIurTermHsCong> yy[%], pmHsSevereCong(IubLink) > yy[%], pmHsSevereCong(IurLink) > yy[%]



Analysis






Low HSUPA/ EUL Serving Cell Change Success RateCell level5. Root cause analysis, mobility:


Cell EUL cell change stats, E_CEFCCSI_SR_1 < zz [%]

Cell EUL IFHO stats, PS_M_Eul_Hho_R < zz [%]









Analysis





e o a ce a ys s

Low HSUPA/ EUL Serving Cell Change Success RateCell level7. Root cause analysis, RF performance:










Analysis




y

Low HSUPA/ EUL ThroughputPLMN and RAN level1. Trigger: Low HSDPA throughput based on aggregated cell level KPI’s:

Cell_User_Thpt_Eul & Avg_Pkt_Thpt_Eul









a) Low Eul availability



Abnormally Low EUL availability in an RNC could indicate system wide problems and outages,transmission or core network interruptions? Has there been any major parameter change to RNC’s

or LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan? Or just inconsistent RNCborder area HO parameter settings.

Analysis





y

Low HSUPA/ EUL Throughput

PLMN and RAN level4. Root cause analysis, mobility:













Analysis





y


Cell level1. Trigger: Low HSDPA Throughput based on cell level KPI’s: Cell_User_Thpt_Eul &

Avg_Pkt_Thpt_Eul




Cell HS availability stats , E_CCEFUAV_1 < zz [sec] & pmEulDowntimeMan < yy[sec]


Check serving and neighbor cells for abnormally low EUL availability is an obvious performanceimpacting issue. Cell having outages regularly? HW fault?



Signaling success rate, total CS and PS RNC, E_CRRC_CSPS_SSR_1 < xx %Congestion or transport network related issues: pmNoUlIubLimitEul > zz[%], pmNoOfIurTermHsCong> yy[%], pmHsSevereCong(IubLink) > yy[%], pmHsSevereCong(IurLink) > yy[%]



Analysis





y


Cell level5. Root cause analysis, capacity I(II):

a) Cell in blocking/ congestion

RRC CS/ PS blocking, E_CCSRRC_BLK_1 > 2 [%], E_CPSRRC_BLK_1 > 4 [%]

RAB CS/ PS blocking, E_CCSRAB_BLK_1 > 2 [%], E_CPSRAB_BLK_1 > 4 [%]


Thresholds indicating cell is experiencing congestion, heavily loaded in general. Continue root cause toidentify what the capacity bottle neck is and ensure blocking/ capacity is addressed and prevented.

b) EUL specific blocking

EUL RAB blocking, Rab_Blocking_Eul(UtranCell) > zz [%]


Excessive EUL blocking, see next steps if licensing limit on number of users is exceeded. Considerreconfiguration of cells dependent on load on the various RAB’s.

c) EUL specific code utilization

Code utilization high for EUL, Code_util_EUL > xx [%]


EUL code utilization is excessively high and needs to be addressed, possibility to reconfigure carrier?Else verify cell configuration and consider carrier upgrade, if possible.

Analysis





y


Cell level5. Root cause analysis, capacity II(II):

d) Licensed max number of users exceeded

Number of EUL users, EUL_Users > 4 [simultaneous users]


If suggested threshold is exceeded, verify license, increase if possible, else add HW, HS-TX card.

License/ parameter upgrade 8, 16 or 32.e) Excessive number of users cell

If EUL_Users increases( trending up) and Cell_User_Thpt_Eul decreases (trending down) OR


Verify hardware configuration and consider HS-TX card upgrade.

Analysis





y


Cell level6. Root cause analysis, RF performance 1:











Analysis





y


Cell level7. Root cause analysis, RF performance 2:










Analysis




Low ISHO Successrate

Cell level1. Trigger: excessive call drop rate based on cell level KPI’s, all aggregated to cell level:

E_CMSIRAT_SR_1(GsmRelation) & IRAT_Tot_CS(GsmRelation) &PS_M_IRATCC_S_CR(GsmRelation) & IRAT_Inc_R(UtranCell)







Low HO success rate in cell in general, verify external cell definitions and that neighbor lists are up todate.


Analysis





Low ISHO Successrate

Cell level3. Root cause analysis, RF performance:











Analysis




Low AMR/Rel99 NRT DCH IFHO Success rate

PLMN and RAN level1. Trigger: excessive call drop rate based on aggregated cell level KPI’s: E_SPIFHO_SR_1

& P_IFHO_S_CR(Utran Relation)







Analysis







PLMN and RAN level3. Root cause analysis, mobility:








a) Abnormal RRC/ RAB blocking, RNC:

RNC aggregated CS RRC blocking stats, E_CCSRRC_BLK_1 > zz %

RNC aggregated PS RRC blocking stats, E_CPSRRC_BLK_1 > zz %RNC aggregated CS RAB blocking stats, E_CCSRAB_BLK_1 > zz %

RNC aggregated PS RAB blocking stats, E_CPSRAB_BLK_1 > zz %


Excessive blocking RNC wide, might lead to unnecessary large number of IFHO in order to offloadcapacity to the 2nd layer. Make sure there is sufficient capacity in area, resource upgrade necessary.

Analysis







Cell level1. Trigger: excessive call drop rate based on cell level KPI’s: E_SPIFHO_SR_1 &

P_IFHO_S_CR(Utran Relation)

2. Root cause analysis, mobility I(II):






Low HO success rate in cell in general, verify external cell definitions and that neighbor lists are up todate.


Analysis







Cell level2. Root cause analysis, mobility II(II):

b) Low HO success rate, per RAB successrate

Cell aggregated stats, Sp_M_IFHO_S(UtranRelation) < zz %

Cell aggregated stats, Pint64OrLess_M_IFHO_S_CR(Utran Relation)< zz %

Cell aggregated stats, Pint64Plus_M_IFHO_S_CR(UtranRelation) < zz %


Is there a specific RAB that is having IFHO issues?

If so troubleshooting continues for that specific RAB, parameter tuning?

Analysis







Cell level3. Root cause analysis, capacity:

a) Neighbor cells RRC/ RAB blocking:

Neighbor cell CS RRC blocking stats, E_CCSRRC_BLK_1 > zz %

Neighbor cell PS RRC blocking stats, E_CPSRRC_BLK_1 > zz %

Neighbor cell CS RAB blocking stats, E_CCSRAB_BLK_1 > zz %

Neighbor cell PS RAB blocking stats, E_CPSRAB_BLK_1 > zz %


Neighbor cell(s) being congested and hence therefore the low IFHO successrate?

Analysis













Performing WMRR measurements for problem cells is an additional source for trouble shooting, drops, HO and otherRF related issues.

Looking at UE reported BLER, TX pwr, EcIo and RSCP can give an indication of the RF environment. If themeasurement statistics shows poor RF environment, it is likely the IFHO is a “rescue” HO and that the other layer RFenvironment is also at is edge, which might then cause bad performing IFHO in difficult RF environment.

Analysis






Low HSDPA IFHO Success Rate

PLMN and RAN level1. Trigger: Low HSDPA IFHO success rate based on aggregated cell relational KPI’s:

Pint_HS_M _ IFHO _ S _CR(Utran Relation ) & PStrHS _M _ IFHO _ S _CR(UtranRelation )



Signaling success rate, total CS and PS RNC, E_CRRC_CSPS_SSR_1 < xx %Congestion or transport network related issues: pmNoOfIurTermHsCong > yy %,pmHsSevereCong(IubLink) > yy %, pmHsSevereCong(IurLink) > yy %








Abnormally Low HS availability in an RNC could indicate system wide problems and outages,transmission or core network interruptions? Has there been any major parameter change to RNC’sor LA/ RA i.e. re-home, re-dimensioning or re design of LA or RNC plan? Or just inconsistent RNCborder area HO parameter settings.

Analysis






Cell level1. Trigger: excessive call drop rate based on aggregated to cell, cell relational level KPI’s:

Pint_HS _M _ IFHO _ S _CR(Utran Relation) & PStrHS _M _ IFHO _ S _CR(UtranRelation)




Cell HS availability stats, Av_HS(Hsdsch) < zz (sec)




a) Low signaling success rate RNC’s: Signaling success rate, total CS and PS RNC, E_CRRC_CSPS_SSR_1 < xx %




Analysis







Cell level5. Root cause analysis, mobility:


Cell HS IFHO stats, P_HS _M _ IFHO _ SOut_CR(UtranCell) < zz [%]

Cell HS IFHO stats, P_HS _M _ IFHO _ SIn_CR(UtranCell) < yy [%]


Outgoing or Incoming IFHO that is the problem?

Direction gives an indication on where to look next, if it’s outgoing, the problem is likely to be in thetarget cell. Incoming faults are typical on source cell.


a) Drops due to missing neighbors, WNCS statistics:

Missing neighbors leading to a dropped connection: numberOfDrops < zz (kbps)

Analysis and potential solution:WNCS report can be used to identify missing neighbors that if added. Even looking at ISHO missingrelations gives an idea of what IFHO missing neighbors there might be to add.

Missing neighbors might be the reason for unsuccessful IFHO’s, non-optimal neighbor, might be moresuitable that is missing.

Analysis



Performance AnalysisA l i






Cell level8. Root cause analysis, problematic neighbor cell relations:




Missing neighbors leading to a dropped connection: Rladd_fail_R_Wncs > 2 [%]




If cell is in same RNC, LAC and RAC, investigate problem further, if no problem can be identified,

remove neighbor from neighbor list and re-run WNCS recording and re evaluate removal.Looking at Intra system neighbors and HO performance gives some leads on what is expected in termsof neighbors and neighbor performance also for IFHO.

Analysis















Looking at UE reported BLER, TX pwr, EcIo and RSCP can give an indication of the RF environment. If themeasurement statistics shows poor RF environment, it is likely the IFHO is a “rescue” HO and that the other layer RFenvironment is also at is edge, which might then cause bad performing IFHO in difficult RF environment.

Analysis






Low coverage (low RSCP vs propagation delay)




UE distribution: Prop_delay_Avg, Prop_delay_Max


Cell is having reported low average RSCP.Looking at Max and average propagation delay, is the cell in fringe of network coverage?

High propagation delay value indicates cell with large coverage area. If average propagation delay is less then maxpropagation delay / 2, it is typically a cell at fringe of coverage. If average is greater then max propagation delay / 2,is there a way of distributing coverage and traffic to neighbor sectors?

b) Non optimal serving area, low RSCP in fringe of coverage area:

Served traffic far field: if Prop_delay_Avg > Cell_UE_dist _norm_BH = 80 [%]

Analysis and potential solution:Statistics shows that cells served traffic is in the fringe of cell coverage area, 80% of max propagation delay for allUE’s served in cell.

This is non optimal for various reasons, power, interference, capacity etc and traffic or coverage should be optimizedin order to serve traffic closer to cell center.

Analysis

Performance AnalysisAnal sis














Looking at UE reported BLER, TX pwr, EcIo and RSCP can give an indication of the RF environment. If themeasurement statistics shows poor RF environment, it is likely the ISHO is a “rescue” HO and that the 2G networkRF environment is also at is edge, which might then cause bad performing ISHO in difficult RF environment.

Analysis

Performance AnalysisAnalysis







a) Coverage and prop delay, GPEH measurements:

Coverage statistics based on Propagation delay distribution:


Using GPEH for coverage and interference analysis is a very powerful tool for detailed trouble shooting.

GPEH measurements provides per call type analysis including both event based statistics and measurements, butalso RF KPI’s as measured RSCP and propagation delay etc.

Analysis






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


a) Cell breathing, interference limited cells:



Metric above looks at difference of average propagation delay and normalized daily propagationdelay distribution, if UE distribution changes significantly during busy hour, average traffic closer cellcenter in busy hour. This might be an indication that cell is interference limited and experiencing softblocking, RF blocking.

Analysis












Detailed cell level RSCP measurements: CPICH RSCPAnalysis and potential solution:


Looking at UE reported BLER, TX pwr, EcIo and RSCP can give an indication of the RF environment. If themeasurement statistics shows poor RF environment, it is likely the ISHO is a “rescue” HO and that the 2G networkRF environment is also at is edge, which might then cause bad performing ISHO in difficult RF environment.

Analysis








a) interference and prop delay, GPEH measurements:

Coverage statistics based on Propagation delay distribution:


Using GPEH for coverage and interference analysis is a very powerful tool for detailed trouble shooting.

GPEH measurements provides per call type analysis including both event based statistics and measurements, butalso RF KPI’s as measured RSCP and propagation delay etc.

Analysis

References:



List of Reference material:1. Ericsson_Rec_3G_KPI_v1.1.xls, NSN SM/CM/Multivendor team, March 2010

https://sharenet-ims.inside.nokiasiemensnetworks.com/Download/D416894845

2. Ericsson 3G Capacity optimization process

Update IMS link…





122642277 performance monitoring

Documents