3G Key Performance Indicators (KPI)

Key Performance Indicators (KPI)

2

• For radio network optimization, it is necessary to have decided on key performance indicators.

• These KPIs are parameters that are to be observed closely when the network monitoring is going on.

• Mainly, the term KPI is used for parameters related to voice and data channels, but network performance can be broadly characterized into coverage, capacity and quality criteria also that cover speech and data aspects.

• KPIs are collected from network management system along with field measurements such as drive tests.

12/20/12

Key Performance Indicators…..continued

• For the field measurements, the tools used are ones that can analyze the traffic, capacity and quality of the calls, and the network as a whole.

• For drive testing, a test mobile is used.• This test mobile keeps on making calls in moving vehicle that goes around

various parts of the network to measure Drop Call Rate (DCR), CSR (Call Success Rate), HO (Handover) etc. parameters.

• Apart from drive testing, the measurements can also be generated by the network management system.

• Network Management system (NMS) can generate various reports which can be analysed, processed and used to found problematic parameters in network.

312/20/12

3G KPI’s Detail

4

Following main KPIs are monitored for UMTS:

• Accessibility ( Setup Failures-RAB and RRC, CSSR)

• Retainability ( Drops-RAB and RRC)

• Mobility ( SHO,ISHO)

• Throughput

• Usage (Resources)

12/20/12

5

Possible Reason Resolution

1: Poor coverage issue1: Change physical antenna parameters (tilt, Azimuth and height), If required Increase TCP and CPICH power to increase coverage and capacity.

2: Neighbour planning issue 2: check for Neighbour planning of the cells in that area. (Missing neighbours)

3: RTWP issue (Receive Total wideband power)3: Check and resolve the issue by tracing the source of external interference through YBT or spectrum Analyzer or get the hardware checked

4: Alarms 4: Forward alarms to BSS team for Rectification.

5: Overshooting issue5: Check RF conditions in and check Source and Target Cells to have a feel of overshoot. Make physical changes on the basis of results.

6. PSC Clash- Same PSC in cells having overlapping coverage 6. Replan the PSC of the cells

CS Call Drop

12/20/12

6

Possible Reason Resolution

1. Poor RF conditions1. change physical antenna changes or If required Increase TCP and CPICH power to increase coverage and capacity.

2: Missing Neighbour Issue 2: check for Neighbour planning of the cells in that area. (Missing neighbours)

3: RTWP issue3: Check and resolve the issue by tracing the source of external interference through YBT or spectrum Analyzer or get the hardware checked

4: Alarms 4: Forward alarms to BSS team for Rectification.

5: Tracing the particular UE. 5: Check CHR data and see if the drops are taking place on one particular UE or different UE

RRC Connection Setup Failure

Possible Reason Resolution1. RRC Failure 1. Do Cell RRC Reject Analysis

2: Power congestion 2: Check for RTWP issue or Increase the power

3: CE Congestion 3: Load Balancing/physical optimization or add carrier.

4: Code Congestion 4: Load Balancing/physical optimization or add carrier or play with HSDPA codes.

5: No Reply 5: This includes reasons like RF conditions and UE issue

6. Dongle/UE issue 6. Cell Scenario analysis report and check if the failures are interactive call failures

PS Call Drop

12/20/12

7

Possible Reason Resolution

1: Overshooting issue1: Check RF conditions in Omstar and check Source and Target Cells to have a feel of overshoot. Make physical changes on the basis of results.

2: Missing Neighbour Issue 2: check for Neighbour planning of the cells in that area. (Missing neighbours)

3. Handover event threshold and parameter settings

3. Retune the handover event threshold and parameter settings

4. PSC Clash- Same PSC in cells having overlapping coverage 4. Replan the PSC of the cells

5: Poor coverage issue5: Change physical antenna parameters (tilt, Azimuth and height), If required Increase TCP and CPICH power to increase coverage and capacity.

IRAT HO Failure (3G Network to 2G Network)

Possible Reason Resolution1. GSM Cell Discrepancies 1. Remove all GSM cell Discrepancies

2: Interference on GSM Cell 2: Remove interference issue on 2G cell

3: Alarms on 2G or 3G cell 3: Remove all alarms either on 2G or 3G side.

4: IRAT parameters 4: Retune IRAT parameters.

5: Particular cell issue5: Filter the cells having continuous high IRAT failures. Enable the IRAT attempt and IRAT success counter from M2000 to find out failures are with which cells

6. Blocking on 2G cell 6. Resolve the issue of blocking in 2G cell

HO Failure (3G-3G)

12/20/12

8

Possible Reason Resolution

1. RTWP issue1. Check and resolve the issue by tracing the source of external interference through YBT or spectrum Analyzer or get the hardware checked

2: Power issue 2: Increase TCP and CPICH power to increase coverage and capacity.

3: Carrier addition 3: Add new carrier

4: Overshooting cell4: Check RF conditions in Omstar and check Source and Target Cells to have a feel of overshoot. Make physical changes on the basis of results.

Power congestion Issue

12/20/12

9

Information Element Accept Limit (%)CSV Access Failure Rate < 1.0 %

CSV Drop Rate <1%

CSV Quality (DL) 95th percentile of samples ≤ 2.0 % BLER

CSV Quality (UL) 95th percentile of samples ≤ 2.0 % BLER

Soft/Softer Handover Overhead < 1.6

*Voice Call Setup time (Mobile to PSTN) 95th percentile ≤ 5 seconds

*Voice Call Setup time (Mobile to Mobile) 95th percentile ≤ 9 seconds

HSDPA Access Failure Rate ≤ 1.0 %

HSUPA Access Failure Rate ≤ 1.0 %

CSD Call Setup Time 95th percentile ≤ 7 seconds

CSD Access Failure Rate <1.0 %

HSDPA Drop Call Rate <1.0 %HSUPA Drop Call Rate <1.0 %

CSD Drop Call Rate ≤ 1.0 %PSD average DL Throughput ≥ 210PSD average UL Throughput ≥ 180

PSD Call Setup time 95th percentile sessions ≤ 3 secondsStationary Maximum DL HSDPA Bit Rate(kbps) > 6 Mbps

Stationary Maximum UL HSUPA Bit Rate(kbps) > 1.2 Mbps

HSDPA Latency 95th percentile sessions ≤ 100 ms

PSD Latency 95th percentile sessions ≤ 100 ms

3G KPI’s and acceptance Limit (different for different operators)

12/20/12

• Adjustment Recommendation and Implementation– Common Control Channel Power Allocation parameters– RL Maximum Power parameters– Intra-frequency Handover parameters – Inter-frequency Handover parameters– Inter-RAT Handover parameters – Power Control parameters– Access parameters

10

Parameters Adjustment Recommendation and Implementation

12/20/12

PROCEDURE- ANALYSING COUNTERS

• Available on an RNC, RXI and RBS basis, the FACTS tool is available to interface to and represent the relevant counters. Counters are collected on a quarterly (15 minute) basis (known as a reporting period) and are stored from the operational date of the cell thereby allowing for past analysis.

• There are numerous counters available from an RNC/RXI/RBS.

However, this procedure concentrates on counters reflecting the critical performance of the cells. These counters (and formulae derived there from) are best analysed graphically through the use of FACTS. The formulae used for statistics such as DCR and CSSR may be obtained within the FACTS.

1112/20/12

PROCEDURE- ANALYSING COUNTERS

• Both the NMC and the Planning & Optimization Engineer are responsible for monitoring counters. The NMC has the responsibility of maintaining the active status of all cells and therefore must act in accordance to all such related counters. The Planning and Optimization Engineer monitors and acts on counters reflecting the cell’s active performance.

• It is possible to configure alarms to be generated for counters exceeding specific values. These alarms would then be monitored by the NMC.

• For the Radio Planning & Optimisation Engineer the focus is on maintaining adequate cell performance in terms of Accessibility (call setup analysis), Retainability (drop call analysis) and Integrity (speech quality/video quality/packet throughput analysis)

1212/20/12

ACCESSIBILITY

• If a cell has poor accessibility it is typically due to either some form of congestion or a hardware/software fault or a misconfiguration. It is also possible that there is some external source of interference (such as a microwave link on the same frequency) affecting the accessibility.

• • Accessibility should be monitored independently for the different

RAB types (e.g. Speech, CS Video, PS Interactive R99, PS Interactive HSDPA, etc.) as in certain situations only one of the RAB types will be affected. For example, a disabled HS-TXB will affect the accessibility of the PS Interactive HSDPA RAB, but if the RBS also has a TXB (non-HS) installed then the other RABs may continue to have an acceptable accessibility.

1312/20/12

ACCESSIBILITY..continued

• When a low CSSR is detected on a cell the first thing to check is if Admission Control is rejecting the RRC/RAB setup attempt (pmNoReqDeniedAdm) or if it is failing after admission (pmNoFailedAfterAdm). For high pmNoReqDeniedAdm refer to the “Admission Control” sections below. For high pmNoFailedAfterAdm refer to the “Failure After Admission” sections below.

1412/20/12

Example: FACTS Report showing a low CSSR Speech caused by a high pmNoReqDeniedAdm. Note that pmNoReqDeniedAdm is not RAB specific so other RABs will most likely be affected in this case too.

1512/20/12

Admission Control: DL Power

• If Admission Control rejects a RAB establishment due to a lack of DL power then the counter pmNoFailedRabEstAttemptLackDlPwr is incremented. Check that the feeder losses are configured correctly in the RBS and that the parameter maximumTransmissionPower is set correctly (typically to maxDlPowerCapability minus 0.2dBm). The value of parameter pwrAdm should also be verified (typically set to 75%). Also, check for MCPA alarms i.e. sometimes RBS 3202 sites with high feeder losses are configured with two MCPAs per sector and one of the MCPAs fails resulting in a large reduction in the maxDlPowerCapability of the sector and, hence, causing a lack of DL power. Long term solutions are to increase the power capability of the sector by adding or upgrading an MCPA (RBS 3203) or RU (RBS 3206), re-engineering the site to reduce feeder lengths, or perhaps to change the RBS type to one using RRUs (RBS 3402 or RBS 3412) if this provides higher power at the reference point. The short term solution is to reduce the traffic carried by the site (See the “Traffic Offload” sections).

1612/20/12

Admission Control: DL Channelisation Codes

• If Admission Control rejects a RAB establishment due to a lack of DL channelisation codes then the counter pmNoFailedRabEstAttemptLackDlChnlCode is incremented. This will typically affect the PS Interactive R99 (DCH/FACH) CSSR worse than the Speech CSSR as the PS Interactive R99 RAB requires channelisation codes at a lower spreading factor (using more of the code tree). In the P4 software release a cell that supports R99 and HSDPA typically has 5 spreading factor 16 DL channelisation codes reserved for HSDPA. This means that approximately 32% of available codes are reserved for HSDPA. When this is the case it is common for DL channelisation code congestion too occur. Check the setting of parameter dlCodeAdm (typically set to 85% on MTN’s network). The long term solution is to add another cell in the coverage area to take some of the traffic; this may be achieved by introducing a second carrier, another sector, or another site. The short term solution is to reduce the traffic carried by the site (See the “Traffic Offload” sections).

1712/20/12

Admission Control: Connection Limits

• If Admission Control rejects a RAB establishment due to exceeding the configured connection limit for SF 8, SF 16, or SF 32 then the counter pmNoFailedRabEstAttemptExceedConnLimit is incremented. These spreading factors are used by the PS64/384, PS64/128, and PS64/384 RBs so the connection limit blocking typically applies to channel switching between these RBs for an R99 packet interactive RAB. The connection limits are configured by parameters sf8Adm, sf16Adm and sf32Adm. The default settings allow the maximum possible number of RL’s for each spreading factor in which case Admission Control will not block for this reason. Lower settings have been tested (in combination with adjusted Class B QoS settings on the Iub interface) in which case some connection limit rejections were obtained. But this is a special situation and for the purpose of this document such connection limit rejections are not worth further consideration.

1812/20/12

Admission Control: Hardware Usage (Channel Elements)

• It is possible for Admission Control to reject a RAB establishment attempt due to insufficient UL or DL RBS hardware capacity i.e. too few channel elements available. The channel element capacity of an RBS may be software limited (according the software license configured for the RBS) or hardware limited (according to the TXBs and RAXBs installed in the RBS). The two parameters that control the RBS hardware admission policy are ulHwAdm and dlHwAdm. By default these parameters should be set to 100% in which case no hardware is reserved for handovers and Admission Control will not block RAB establishment attempts for this reason (see “Failure After Admission: Hardware Usage”). In software revision P4 there is no specific counter to indicate this type of Admission Control rejection, so if pmNoReqDeniedAdm is triggered without any of the other relevant counters indicating a reason then it is likely that this is the cause and that ulHwAdm or dlHwAdm is incorrectly configured to a value below 100%. In the P5 software release there are new counters that indicate when lack of hardware capacity causes RAB establishment failures in a cell: pmNoFailedRabEstAttemptLackDlHw, pmNoFailedRabEstAttemptLackDlHwBest, pmNoFailedRabEstAttemptLackUlHw, pmNoFailedRabEstAttemptLackUlHwBest.

1912/20/12

Soft Handover Drops

• Typically a cell that has a high number of dropped calls due to SOHO failures (pmNoSysRelSpeechSoHo) will also have a high number of drops due to missing neighbours (pmNoSysRelSpeechNeighbr) indicting that the SOHO failures are due to missing neighbour relations; however, there are situations where SOHO failures happen for other reasons. Two common reasons are a neighbouring cell that is misbehaving (often due to faulty hardware/software) or a misconfiguration resulting in a failure to perform an inter-RNC SOHO across the Iur interface.

2012/20/12

Drive Test Based Service Quality Measurements

• From TEMS Investigation,the ability to measure the speech and video streaming service quality is introduced through two new KPIs: the WCDMA Speech Quality Index (SQI) and the Video Streaming Quality Index (VSQI). These two KPIs may be used to benchmark the service quality for speech and video streaming from drive test data. In addition to the above the DL BLER may also be obtained for

2112/20/12

R99 & HSDPA PS Interactive Throughput (RNC Level)

• The throughput obtained on the packet interactive RABs (HSDPA and R99) are a good indication of the Integrity offered by these services. Counters are available at an RNC level to obtain the PS Interactive Average Throughput for R99 (DCH/FACH) and HSDPA, as well as the retransmission rate for these two services.

2212/20/12

Test for Special Areas/ Hot-spots

• Special area refers to a small district or indoors environment– Operator offices, residence of VIP. – Key hotels or entertainment location. – Government location. – Locations of large company or group subscribers .– Locations tend to be cared , such as railway station or airport.

2312/20/12

Optimization Report

• The 《 optimization report 》 should be presented after the project passes the customer acceptance. The optimization report should include: – Project background introduction.– Existing network status.– Acceptance criteria.– Optimization process.– Problem analysis, adjustment recommendation and the effect

for the implemented part.– Acceptance test and result.– Leftover problems and suggestions from the optimization point

of view.

2412/20/12

THANKS

2512/20/1225

25