Method Desc Dropped Calls A

00021-FAY 201 691 Rev A 2000-11-03 1(12)

© Ericsson. For limited internal use only

RADIO NETWORK IMPROVEMENTMODULE DESCRIPTION

DROPPED CALLS, GSM

Abstract

The purpose of this document is to describe how to analyze dropped callperformance in a radio network and suggests methods on how to improve theradio network performance, within the scope of dropped calls.

The Dropped Calls module is a part of the Radio Network Performance (RNI)service.

The result of the activities, together with both long and short-termimprovement recommendations are provided to the Customer in the RNIservice report.

Table of Contents1 INTRODUCTION...............................................................................................3

2 GENERAL DESCRIPTION...............................................................................3

2.1 PURPOSE OF THE MODULE..............................................................................32.2 REASONS FOR DROPPED CALLS ......................................................................3

3 PREPARATION..................................................................................................4

3.1 DATA COLLECTION........................................................................................43.2 TOOLS............................................................................................................43.3 DATA PROCESSING ........................................................................................5

4 PROCEDURE......................................................................................................6

4.1 WORK FLOW..................................................................................................64.2 PROBLEM IDENTIFICATION ............................................................................64.3 ANALYSIS ......................................................................................................74.4 IMPLEMENTATION CONSIDERATIONS.............................................................94.5 EVALUATION ...............................................................................................104.6 REPORT........................................................................................................10

5 REFERENCES ..................................................................................................11

RADIO NETWORK IMPROVEMENT MODULE DESCRIPTION, GSM

2(12) 00021-FAY 201 691 Rev A 2000-11-03


ABBREVIATIONSBA BCCH Allocation

BCCH Broadcast Control Channel

BSC Base Station Controller

BTS Base Transceiver Station

CDD Cell Design Data

FAS Frequency Allocation Support

FOX Frequency allocation Optimization eXpert

MRR Measurement Result Recording

MSC Mobile Switching Center

NCS Neighbouring Cell Support

NOX Neighbouring cell list Optimization eXpert

NPI Network Performance Improvement

NWS Network Statistics

OSS Operation and Support System

RNI Radio Network Improvement

RNO Radio Network Optimization

SDCCH Stand Alone Dedicated Control Channel

SRP Statistics Report Package

STS Statistics and Traffic Measurement Subsystem

TCH Traffic Channel

TCP Tems Cell Planner

TEMS Test Mobile System

DROPPED CALLS

00021-FAY 201 691 Rev A 2000-11-03 3(12)


1 IntroductionThe purpose of this document is to serve as an Ericsson internal guideline onhow to analyze the dropped call performance within the RNI service for GSMsystems.

This document describes the requirements and actions for carrying out adropped calls performance analysis for an Ericsson GSM system in an RNIservice.

A network with high a dropped call rate will impact customer perceivedquality and performance, thus it is vital for any network to provide a servicewith as low dropped call rate as possible.

2 General Description

2.1 Purpose of the moduleThe purpose of this module is to investigate the dropped calls performance in aGSM radio network, find possible reasons for high drop call rates and reducethe drop call rate.

The dropped calls investigation in this document includes both TCH droppedcall analysis and SDCCH dropped call analysis. SDCCH dropped call analysisis also a part of the Call Set-up module, please refer to RNI ModuleDescription, Call Setup, GSM [1].

Dropped calls are one of the most important indicators to control theperformance of a radio network and how subscribers perceive the quality ofthe network.

2.2 Reasons for dropped callsPossible reasons for a high rate of dropped calls could be:

• TCH Congestion

• Parameter Settings

• HW problems

• Interference

• Poor signal strength

• Missing cell relations and/or missing measurement frequencies


4(12) 00021-FAY 201 691 Rev A 2000-11-03


3 Preparation

3.1 Data CollectionWhen doing the initial analysis for a specific module, the same data as for thePre-analysis can be used, see RNI Pre-analysis [2], and no extra data collectionneeds to be done. The details of the required data for the Pre-analysis arestated in Data Collection Instructions R7 [3] and Data Collection Instructions,R8 [4]. The following data is needed for the initial analysis of this module:

• Statistics and Measurement Subsystem (STS) data should be collected for24 hours and analyzed for 4-6 hours daily, including busy hour period, for2-3 days. The STS object types needed are stated in the Data CollectionInstructions.

• Several different Mobile Switching Center (MSC) and Base StationController (BSC) printouts are required. The printouts needed are stated inthe Data Collection Instructions.

• Site data base with site locations (preferably also on a map) are neededtogether with information on antenna types and antenna directions.

• Coverage and interference plots with the current cell plan should, ifavailable, be provided.

STS formulas can be found in BSC STS User Formulas R7 [5] or BSC STSUser Formulas R8 [6].

Store the data according to Data Storage Guidelines [7].

During the on-site activities, STS data should be collected regularly, normallyon an hourly basis and analyzed on a daily basis, using the same busy hours asfor the Pre-analysis.

Measurement Result Recording (MRR) should regularly be used in the on-sitework. Normally, MRR measurements should be performed for all cells duringa couple of hours every day during the RNI. The time interval of themeasurement should be correlated with the time interval used for the STSmeasurements.

Neighboring Cell Support (NCS) or Neighbouring Cell List OptimizationeXpert (NOX) should be used whenever needed during the on-site activities.

Frequency Allocation Support (FAS) or Frequency allocation OptimizationeXpert (FOX) should be used whenever needed during the on-site activities.

3.2 Tools• IPOS - or other Cell Design Data (CDD) tool

• SPOS - or other STS parser

• Turtle - or other STS formula calculating tool

DROPPED CALLS

00021-FAY 201 691 Rev A 2000-11-03 5(12)


• TurtleXL, Excel Macro - or other STS formula presentation tool

If Operation and Support System (OSS) is used

• Statistical Report Package (SRP) or Network Statistics (NWS)

Other useful tools:

• MCOM

• TEMS cell planner

• TEMS Investigation or TEMS Classic test mobile for drive test purposes.

• OSS with Radio Network Optimization (RNO) including:

• MRR

• NCS or NOX

• FAS or FOX

3.3 Data ProcessingIf SPOS/Turtle are used:

1. Run SPOS and Turtle for the days required according to Guidelines toSPOS and Turtle [8].

2. Use TurtleXL macro to display the cells with the worst performance.

If IPOS is used:

Run IPOS for the collected printouts according to IPOS User Instruction R7[9].

If MCOM is used, see the MCOM User Guide [10].

If OSS is used:

Run SRP or NWS for the days required. For information on how to use thetools, see SRP User Guide R7 [11] or NWS, Analysis User Guide [12].

If the RNO features are used:

1. See the RNO Set-up Guide [13] for assistance on how to set up thefeatures. Note that the implementation and activation of the RNO featuresshould be done by authorized Ericsson support personnel, see also chapter4.4 regarding activation of features.

2. See the NCS User Description R7 [14] or NOX User Description R8 [15],FAS User Description R7 [16] or FOX User Description R8 [17] andMRR User Description R8 [18], MRR User Guide OSS R7 [19] and MRRUser Guide OSS R8 [20] for more details on how to use these features.


6(12) 00021-FAY 201 691 Rev A 2000-11-03


4 Procedure

4.1 Work Flow1. Collect and Post process the data according to the description for each tool

2. Problem Identification

3. Analysis

4. Implementation considerations

5. Evaluation

6. Report

4.2 Problem IdentificationThe list below describes ways of identifying cells with high dropped call ratesand how to find the cause of the problems.

• Run a consistency check in IPOS to verify the cell parameter settings andcheck which radio network features that are active (this is normally donealready in the Pre-analysis). Use NPI Radio Related Data Check [21] andNPI Radio Network Features Utilisation [22] as a help in the checks.

• Run NCS or NOX to find missing neighboring cell relations. Missingneighboring cell relations can affect the radio network performance in anegative way.

• Use STS to identify cells with high TCH and SDCCH drop call rates andidentify the reasons for the high drop call rates. The worst cellsidentification should not include cells with extremely low traffic. See NPIDescription for Dropped Calls [23] for more information on how toidentify cells with high drop call rates (the document contains a quiteextensive description on how to identify dropped call problems and alsosuggestions on further analysis). The reasons for dropped calls can,according to STS, be:

- Low signal strengthBad qualitySudden loss of connection (only TCH)OtherExcessive timing advance

Check if the dropped calls due to Low signal strength and Bad qualityare related to the uplink or the downlink.

• Use STS to identify cells with high drop call rates due to dropped callsduring handover. For more information on how to analyze the Handoverperformance, see NPI Description for Handover [24] and RNI ModuleDescription, Handover [25].

DROPPED CALLS

00021-FAY 201 691 Rev A 2000-11-03 7(12)


• Use STS to identify cells with high TCH time congestion. TCH congestionwill directly lead to SDCCH drop connections and indirectly cause TCHdropped calls, as Handovers might be delayed or even inhibited due tocongestion. For more information on how to identify cells with congestion,see the NPI description for SDCCH and TCH analysis [26].

• Use MRR to verify if the worst performing cells have many measurementreport samples with low signal strength or high bit error rate (highRXQUAL values), indicating either poor coverage or high interference.See NPI Description for Dropped Calls [23] to find out how to do theMRR analysis and the documents MRR User Description R8 [18], MRRUser Guideline OSS R7 [19] and OSS R8 [20] to see how to perform themeasurements.

• If time allows, TEMS drive tests can be performed in the poor performingarea/cells to get more information regarding the problem. See RNI FieldMeasurements [27] for more information on how to perform fieldmeasurements.

4.3 Analysis

4.3.1 High interferenceIf interference is causing the dropped calls problems, check the frequency planto see if there are adjacent or co-channel frequencies near the cell. If this is thecase, frequency changes might solve the problem. See NPI Description forInterference [28] and RNI Interference Module [29] for more information onhow to solve interference related problems. The NPI Cell plan evaluation [30]can also be used when analyzing interference problems related to cellplanning.

In some cases a cell is covering an area far away from its site, causinginterference problems. Down tilting the antenna or reduction of output powerare examples of actions that could solve the problem. See Antenna DowntiltGuideline [31] for more information regarding downtilt.

4.3.2 Poor coverageCheck if cells indicating high drop call rates due to poor signal strength and/ormany MRR measurement samples with low signal strength, are located in theoutskirts of the network. Use the coverage analysis in Cell plan evaluation [30]for this analysis. See also RNI Module Description, Coverage [32] for somemore information on what can be done in this area.

4.3.3 Hardware problemsFor the cells showing a high percentage dropped calls due to “other” reasons inthe STS measurement, check the BTS error log for hardware faults, see NPIBTS Performance Analysis [33] for more information on how to interpret theerror log.


8(12) 00021-FAY 201 691 Rev A 2000-11-03


4.3.4 Excessive Timing AdvanceDropped TCH due to excessive timing advance should in normal cases notoccur in the network. The reasons for timing advance drops are site location(close to open water, desert or hilly terrain) and the setting of the cellparameters MAXTA and TALIM. Setting MAXTA to 63 and TALIM to 62could solve the problem. If the cell is really covering far away from the site,other options are reducing the coverage by down tilting the antennas, reducingantenna height, changing antenna or reducing output power.

4.3.5 TCH CongestionTCH congestion will increase the SDCCH drop rate. It is however possible inSTS to study the “true” SDCCH drop rate by subtracting the drops due tocongestion from the total number of drops.

TCH Congestion might have the affect that Handovers are not performed at thecorrect position and the calls are dragged. Mobiles that are not served by thebest cell candidate are prone to bad quality and are at a higher risk ofexperiencing dropped calls.

For information on how to decrease congestion, see RNI Module Traffic andCapacity Module [34] and the NPI description for SDCCH and TCH analysis[26]

4.3.6 Handover related problemBelow is a list of some Handover related issues that might affect the TCHdropped call rate. For a more in-dept analysis see NPI Description forHandover [24] and RNI Module Description, Handover [35].

• Missing neighboring cell relations or missing measurement frequencies inthe active (BCCH Allocation) BA list

The effect of missing neighbor relations is that the mobile may not be servedby strongest cell, which increases the risk of dropped calls. If the Handoverscan not be performed, due to missing neighbor cell relations or measurementfrequencies, there is also a risk that the call will eventually drop when the callis dragged too far away from the serving cell.

• Handover Reversion

In a Handover reversion the MS returns to the old cell after a failed Handoverattempt to a neighboring cell. Repeated reversions may lead to the same typeof problems as described above for missing neighboring cell relations.

• Faulty Locating parameter setting

Faulty parameter settings in locating (OFFSET parameters, parameters relatedto K/L criterion, etc) will affect the Handover decision made by the BSC andthis can lead to a degradation in the selection of the best candidate cell.

• TCH Congestion

See chapter 4.3.5, TCH Congestion above.

DROPPED CALLS

00021-FAY 201 691 Rev A 2000-11-03 9(12)


4.3.7 Incorrect cell parameter settings and use of radio networkfeaturesCheck Cell Design Data for the concerned cells. Check if interference-reducing features are activated and configured according to recommendedvalues. Check also other parameter settings such as locating parameters. SeeRadio Network Parameters and Cell Design Data for Ericsson’s GSM SystemR7 [36] or R8 [37] for more information on recommended cell parametervalues.

4.4 Implementation Considerations

4.4.1 GeneralThe following considerations should be taken into account when implementingalterations in the network:

• Alterations to the network should be avoided during high traffic hours.

• Before the implementation of an alteration in all concerned areas, applythe changes to a limited area to verify the impact. If the results meet theexpected results, the alteration can be implemented in a larger area.

• Alterations can be tested for a limited time to verify the impact of thealterations. The performance before, during and after the test can then beevaluated to consider if to permanently make the alteration.

• The different types of alterations to the system should be done one by oneand evaluated individually to be able to conclude the reason behind achange in a particular performance area.

• Before activating a specific feature, the Ericsson Local Company must becontacted to verify if the Customer has bought the particular feature. If theCustomer has not bought the feature it might still be possible to activatethe feature for a limited time to demonstrate the benefits with the feature.However, even if the feature is only activated for a limited time, thedecision to activate a feature must be taken by the Ericsson LocalCompany.

• If a specific feature should be activated, this must be approved by theCustomer. The way the feature should be activated must also be agreedupon. Normally, feature activation is done by Customer Switch personnelor Ericsson Local Company support personnel.

4.4.2 SpecificWhen adding measurement frequencies to the BA lists, note that if a BA listcontains too many frequencies this might degrade the precision of handoverdecisions.


10(12) 00021-FAY 201 691 Rev A 2000-11-03


4.5 EvaluationWhen evaluating the impact of the alterations the following things should beconsidered:

• Following all parameter adjustments and other changes in the softwaredefinitions during the optimization phase, cell data should be collected anda design check should be run to ensure that no errors were made in theoptimization process.

• Before and after alterations to the system, statistics should be collected andcompared against the same or similar time period. A comparison should bemade to see how the alterations affected the performance.

• When doing a comparison of the performance before and after analteration, it is essential that enough measurement data is collected to beable to clearly state that an improvement detected from the statistics is dueto the alteration, and not to normal fluctuations.

• After completion of all alterations, statistics should again be collected andcompared against the same or similar time period before the initiation ofthe alterations. A comparison should be made to see how the serviceimproved the performance.

4.6 ReportWhen the work is completed a report that highlights the findings andimplemented/proposed changes should be written and delivered to thecustomer. The report should cover the following:

• Scope of the project

• Problem analysis and findings

• Implemented changes and the result

• Conclusions and Short/Long term recommendations

The RNI Report Template [38] is a suggestion on how structure the report.The template gives a proposal on how to present the result of the RNI.

DROPPED CALLS

00021-FAY 201 691 Rev A 2000-11-03 11(12)


5 REFERENCES[1] RNI Module Description Call Setup, GSM, 00021-FAY 201 685, Rev. A

[2] Radio Network Improvement, Pre-analysis GSM, 00021-FAY 201 686,Rev. A

[3] Data Collection Instructions for NPI Services, Ericsson GSM System R7,LVR/P-98:0038 Rev D

[4] Data Collection Instructions for NPI Services, Ericsson GSM System R8,GPD/P-00:0087 Rev A

[5] BSC STS User Formulas, Ericsson GSM System R7 LVR/P-98:0376Rev B

[6] BSC STS User Formulas, Ericsson GSM System R8 GPD/P-00:0047Rev A

[7] Data Storage Guideline LVR/P-97:0431 Rev B

[8] Guideline to SPOS and Turtle ERA/GPD/P-00:0409 Rev A

[9] IPOS /R7 User Guide

[10] MCOM User Guide, Version 3.4, NDC-2000:007, Rev. B

[11] SRP User Guidelines 2/1553-CRA 114 410 Uen G

[12] NWS, Analysis User Guide, 1553-APR 102 64/1A, Rev H

[13] Radio Network Optimization Setup Guide, LVR/P-99:0554, Rev. A

[14] User Description Neighboring Cell Support, R7, 22/1553-CRA 114 13Uen C

[15] User Description Neighboring Cell List Optimization Expert, R8,49/1553-CRA 114 13 Uen D

[16] User Description, Frequency Allocation Support, 23/1553-HSC 103 12Uen, Rev. C

[17] User Description, Frequency Allocation Optimization Expert, 61/1553-HSC 103 12 Uen, Rev. A

[18] User Description Measurement Result Recording, R8, 71/1553-HSC10312 Rev. B

[19] TMOS User Guide Measurement Result Recording OSS R7, 1553-CRA114 28, Rev. C3

[20] TMOS User Guide Measurement Result Recording OSS R8, 1553-CRA114 28, Rev. F

[21] Network Performance Improvement Description for the Area RadioRelated Data Check LVR/P-97:0531 Rev B


12(12) 00021-FAY 201 691 Rev A 2000-11-03


[22] Network Performance Improvement Description for the Area RadioNetwork Features Utilisation LVR/P-97:0532 Rev, B

[23] Network Performance Improvement description for the area DroppedCalls LVR/P 97:0437 Rev B

[24] Network Performance Improvement description for the area Handoverperformance. LVR/P-97:0472 Rev B

[25] RNI Module Description Handover, GSM, 00021-FAY 201 690, Rev. A

[26] NPI Description for the area SDCCH and TCH, LVR/P-97:0475 Rev B

[27] Radio Network Investigation of an Ericsson GSM System, FieldMeasurements, LVR/P-97:076, Rev.B

[28] Network Performance Improvement description for the areaInterference.LVR/P-97:0438 Rev B

[29] Radio Network Improvement, Module Description. Interference, 00021-FAY 201 689, Rev A

[30] Network Performance Improvement Cell plan evaluation ERA.GPD/P-00051 Rev A

[31] Antenna Downtilt Guideline, Rev. A

[32] Radio Network Improvement, Module Description, Coverage, GSM,00021-FAY 201 687, Rev. A

[33] Network Performance Improvements for the area BTS PerformanceAnalysis, LVR/P-99:0433, Rev. A

[34] Radio Network Improvement, Module Description, Traffic and Capacity,GSM, 00021-FAY 201 692, Rev. A

[35] Radio Network Improvement, Module Description, Handover, GSM,00021-FAY 201 690, Rev. A

[36] Radio Network Parameters and Cell Design Data for Ericsson’s GSMSystem, R7, 6/100 56-HSC 103 12 Uen Rev. B

[37] Radio Network Parameters and Cell Design Data for Ericsson’s GSMSystem, R8, 90/1551-HCS 103 12 Uen Rev. A

[38] Radio Network Improvement Technical Report Template, 1/0363-FAB102 710, Rev A

Method Desc Dropped Calls A

Documents

Transcript of Method Desc Dropped Calls A