Network Performance Monitoring Guide Book V02.03

GSM

Network Performance Monitoring Guide BookReference : Version : Date : Ext. ref. : Type : Product : Cat : Status : Author : Documentalist : Approved by : Quality manager : Abstract / Comments : .... TYP PRD

NMO Team A.M Le Berre P. Braut

Distribution lists :

This confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation

DOCUMENT AMENDMENTS VERSION DATE COMMENTS Creation Complement on QOS Monitoring chapter New chapters : Path Balance Traffic and Mobility Analysis V02.03/ EN 09/02/98 Complement on QOS Monitoring New chapters : MSC Call Profile NSS Capacity Analysis J. Pandion O. Berchon AUTHOR I. Desages M. Ladki M. Ladki

V01.01/ EN 30/01/97 V02.01/ EN 30/09/97 V02.02/ EN 05/12/97


Monitoring Guide Book

Page I.2

GSMReference : Version : Date :

NETWORK PERFORMANCE MONITORING GUIDE BOOK


DRAFT DOCUMENTTABLE OF CONTENTS 1. INTRODUCTION .................................................................................................................5 1.1 OBJECT ....................................................................................................................5 1.2 SCOPE ...................................................................................................................... 5 2. RELATED DOCUMENTS ....................................................................................................6 2.1 APPLICABLE DOCUMENTS.....................................................................................6 2.2 REFERENCE DOCUMENTS ....................................................................................6 3. ABBREVIATIONS & DEFINITIONS ....................................................................................7 3.1 ABBREVIATIONS ......................................................................................................7 3.2 DEFINITIONS ............................................................................................................7 4. QUALITY OF SERVICE MONITORING ..............................................................................8 4.1 INTRODUCTION .......................................................................................................8 4.1.1 OBJECT .........................................................................................................8 4.1.2 SCOPE ..........................................................................................................8 4.2 PERFORMANCE MONITORING OVERVIEW ..........................................................9 4.2.1 WHAT IS PERFORMANCE MONITORING ...................................................9 4.2.2 QOS MONITORING ..................................................................................... 11 4.2.3 WHAT TO MONITOR ? ...............................................................................12 4.2.4 CUSTOMER BENEFITS ..............................................................................12 4.2.5 DELIVERABLES .......................................................................................... 13 4.2.6 HOW TO MONITOR .................................................................................... 14 4.3 QOS MONITORING SET UP ..................................................................................16 4.3.1 DATA DEFINITION ...................................................................................... 16 4.3.2 METRICS DEFINITION................................................................................ 23 4.3.3 TOOL ........................................................................................................... 26 4.4 PROCESS ...............................................................................................................28 4.4.1 OBSERVATION ........................................................................................... 29 4.4.2 ANALYSIS ................................................................................................... 30 4.4.3 CORRECTION .............................................................................................33 4.4.4 VALIDATION................................................................................................ 34


Network Performance Monitoring Guide Book

Page 2/156

DRAFT DOCUMENT4.5 METRICS OBSERVATION AND ANALYSIS........................................................... 35 4.5.1 ASSIGNMENT FAILURES ........................................................................... 35 4.5.2 38 4.5.2 39 4.5.3 TCH AVAILABILITY ..................................................................................... 39 4.5.4 TCH/SDCCH LACK OF RESOURCES ........................................................42 4.5.5 CALL DROP (TCH) ...................................................................................... 49 4.5.6 HANDOVERS FAILURES ............................................................................ 56 4.5.7 HANDOVERS FOR DOWNLINK QUALITY ................................................. 62 4.5.8 HANDOVERS FOR UPLINK QUALITY........................................................65 4.5.9 HANDOVERS FOR DOWNLINK LEVEL ..................................................... 67 4.5.10 HANDOVERS FOR UPLINK LEVEL .......................................................... 68 4.5.11 HANDOVERS FOR DISTANCE ................................................................. 70 4.5.12 RACH EFFICIENCY...................................................................................72 4.5.13 NO TRAFFIC/HANDOVERS/SDCCH ........................................................78 5. PARAMETERS AUDIT ...................................................................................................... 79 5.1 INTRODUCTION .....................................................................................................79 5.1.1 OBJECT ....................................................................................................... 79 5.2 BSS PARAMETERS ................................................................................................ 80 5.2.1 CLASSIFICATION .......................................................................................80 5.2.2 RECOMMENDED VALUES .........................................................................81 5.3 BSS PARAMETERS CONTROL ............................................................................. 90 5.3.1 NETWORK DEFAULT VALUE CONTROL ..................................................90 5.3.2 NETWORK DATABASE CONSISTENCY .................................................... 98 5.3.3 BDE - BDA CONSISTENCY ........................................................................ 99 6.TRAFFIC AND MOBILITY ANALYSIS .............................................................................100 6.1 INTRODUCTION ...................................................................................................100 6.2 TRAFFIC AND MOBILITY ON BSS SIDE .............................................................100 6.2.1 INTRODUCTION TO CALL PROFILE .......................................................100 6.2.2 CALL PROFILE CALCULATION................................................................101 6.3 TRAFIC AND MOBILITY NSS SIDE......................................................................117 6.3.1 DATA COLLECTION .................................................................................117 6.3.2 PROCESSING ...........................................................................................118 6.3.3 CALL PROFILE DEFINITION ....................................................................119 6.3.4 TRENDING ................................................................................................124 6.4 NETWORK SUBSCRIBER PROFILE....................................................................125 6.4.1 DEFINITION...............................................................................................125This confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 3/156

DRAFT DOCUMENT7. CAPACITY ANALYSIS ....................................................................................................127 7.1 FOR ONE MSC .....................................................................................................127 7.2 FOR SEVERAL MSC ............................................................................................127 8. 127

8. 6 LINK BUDGET MONITORING .....................................................................................128 8.1 DEFINITION ..........................................................................................................128 8.2 INPUTS .................................................................................................................128 8.3 DATA COLLECTION .............................................................................................129 8.3.1 Protocol Analyzer.......................................................................................129 8.3.2 Call Tracing (V8) ........................................................................................130 8.3.3 Call Path Tracing V8 ..................................................................................130 8.3.4 Measurements constraint...........................................................................130 8.3.5 Power Control Impact ................................................................................131 8.4 POST-PROCESSING & ANALYSIS ......................................................................133 8.4.1 Post-processing .........................................................................................133 8.4.2 Analysis .....................................................................................................134 8.4.3 Application to check the BTS .....................................................................137 8.4.4 DIAGRAM FOR UPLINK PROBLEM .........................................................138 8.4.5 DIAGRAM FOR DOWNLINK PROBLEM ...................................................140 8.4.6 Uplink limited or downlink limited ? ............................................................140 9. APPENDICES ..................................................................................................................145 9.1 APPENDIX A : FORMULA USED IN CT7200 .......................................................145 9.2 ANNEX B. DETECT AND CORRECT INTERFERENCES ....................................150 9.2.1 UPLINK INTERFERENCES .......................................................................150 9.2.2 DOWNLINK INTERFERENCES ................................................................151 10. END OF DOCUMENT ................................................................................................156



Page 4/156

DRAFT DOCUMENT

1. INTRODUCTION1.1 OBJECTThis document is the Network performance monitoring Guide Book. It aims at helping for performance monitoring of a GSM network.

1.2 SCOPEThis document applies to V8 BSSs and a V8 OMC-R. Rfrences of Applicable and rfrence documents are available in chapter 2. Chapter 3 describes the abbreviations and definitions of main terms used in this document. Chapter 4 describes the QOS monitoring. It gives a global overview of the QOS monitoring, describes its setup, the process, the metrics observation and analysis. Chapter 5 explains the Parameters Audit. It describes the BSS parameters : classification, recommended values and the BSS parameters control. Chapter 6 describes the Path Balance Verification : inputs, data collection, post-processing and analysis. Chapter 7 describes the Traffic and Mobility Analysis. : traffic and mobility call profile, network suscriber profile. The appendices give formulas used in CT7200 and how to detect and correct interferences.



Page 5/156

DRAFT DOCUMENT

2. RELATED DOCUMENTS2.1 APPLICABLE DOCUMENTS[A1] PE/DCL/DD/07 BSS Operating principles CT 7200 User Manuel for V8 Network

[A2] PEI/IRC/APP/0060 Monitoring [A3] [A4] [A5] PE/RSV/APP/0004 PRJ/DOM/CLA/NNNN PE/IRC/APP/0063

ABIS Software users manual NSS Counters description GSM Customer Services Volume III : Inservice Network Services

2.2 REFERENCE DOCUMENTS[R1] [R2] [R3] [R4] [R5] [R6] [R7] [R8] [R9] [R10] [R11] PE/IRC/APP/0064 SQ/GEN/APP/0056 Rec GSM 04.08 Rec GSM performance monitoring Rec GSM on service quality Rec GSM 08.08 Rec GSM 08.58 Rec GSM 04.06 Rec GSM 05.08 PE/IRC/APP/0060 CT7200 User Manual CT7400 User Manual CT7300 User Manual Cellular Network Engineering Process



Page 6/156

DRAFT DOCUMENT

3. ABBREVIATIONS & DEFINITIONS3.1 ABBREVIATIONSNMO NEO RSV QOS Network Monitoring and Optimisation NEtwork Optimisation Radio Site Verification Quality Of Service

3.2 DEFINITIONSRadio Survey Cell Planning Radio Site Verification Site Survey Network Optimisation



Page 7/156

DRAFT DOCUMENT

4. NETWORK PERFORMANCE MONITORING4.1 INTRODUCTION4.1.1 OBJECT This chapter presents thePperformance Monitoring Process, it describes : - the methods - the datas - the tools - the Analysis used for monitoring activity, the way it is performed by NMO team. 4.1.2 SCOPE Network Performance monitoring is to be seen as a recurrent activity performed during the whole life of a network. It is generally more efficient when the operator has enough subscribers, so, few weeks after the commercial launch (depending on the traffic growth). But it appears also useful at the very beginning of the in service time. (See Figure 1) For an efficient quality of service monitoring, maintenance has to be properly performed. The QOS team must be kept informed about maintenance results



Page 8/156

DRAFT DOCUMENT

4.24.2.1

PERFORMANCE MONITORING OVERVIEWWHAT IS PERFORMANCE MONITORING Performance monitoring is part of the Performance engineering services level (Level 2) as described in the In services network services book.Level 3 : Advanced services Business planning End-user services planning Growth planning Network optimisation Level 2 : Performance engineering services Network fine tuning Network monitoring Network assessment Level 1 : Operational support services Emergency technical assistance service Technical assistance service Field support engineering Network expansion First line maintenance First line operations



Page 9/156

DRAFT DOCUMENT

The goal of this level is to provide services in the areas of : y Developing a complete view of network performance, with special focus on subscriber perceived network performance. y Auditing the parameters that control network performance, identify and correct any major errors. y Assessing the capacity buffer available in the various network elements. y Performing a competitive analysis of network performance in comparison to competition.

2.1 Performance monitoring & Trouble shooting

2.1.1 QoS monitoring 2.1.3 Traffic & Mobility analysis 2.1.6 Link budget monitoring

2.1.2 Parameters audit 2.1.5 Voice quality monitoring 2.1.8 Network Competitive analysis

2.1.4 Capacity analysis 2.1.7 Jammers tracking



Page 10/156

DRAFT DOCUMENT

5. QOS MONITORINGThere is no chance for a network to remain the same its whole life long : y Subscribers are changing (new profiles, new locations, new pricing ...) y Environment is changing (new buildings, new highways, new radio networks ...) y Design of the network is changing (new subscribers, coverage extensions, ...) y Technics are improving (new features, new equipments, new kinds of mobile phones ...)

To guarantee the appropriate services to the subscribers, it is first necessary to evaluate the network performances. It allows to detect any degradation, bad spots or needed improvements in the network, and then to correct or improve them. Monitoring the quality of service regularly helps operators to determine what to improve in the network (detection) and how to improve it (analysis and solutions).



Page 11/156

DRAFT DOCUMENT5.1.1 WHAT TO QOS MONITOR ? It provides a complete set of metrics (using observations on both NSS and BSS parts of the network) representing the perception of the users of the network. The monitoring and reporting are performed at different levels (network level, cell level, etc.) and for different time intervals (busy hour, daily, weekly). The reporting will have detailed sections but will also have summaries specifically aimed at (a) Executives (b) Marketing (c) Engineering. Some of the key metrics that are monitored are : BSS y Call drop rates y Call completion rates y Paging Timeouts y SCCP connections refusal y Handover completion rates y TCH blocking rates y SDCCH bloking rates y RXQUAL statistics y etc. NSS y PSTN blocking y Page timeouts y A interface connection refuse, trunk blocking y Interface trunk blocking y SS7 signalling timeouts y MAP message failures y Inter-MSC handover failures, number overflow, y MSRN overflow y etc .. Apart from monitoring, the evolution of some of the key metrics are trended over time. Moreover, cells which are key offenders are reported through identifying the top 30 cells that contribute to each metric.

5.1.2 CUSTOMER BENEFITS y Reporting of the network behavior to various levels of the customers organization (management oriented reports, customer satisfaction oriented reports ...). y Identification of network troubles, not visible at the OSS level. y Providing a source of information which can be used by the customer to improve Quality of Service.



Page 12/156

DRAFT DOCUMENT5.1.3 DELIVERABLES Huge quantities of data are coming from all the interfaces of the activity, though, to make sure of detecting any evolution of the network, a panel of indicators have to be set up, with the following mandatory characteristics : Reliable : Stable enough when nothing happens but able to detect any change as well as able to help quantifying the change. Synthetic : Able to sort the main information through the quantity of data used. Complete : Able to take into account any information coming from the network

The set of indicators used by NMO team is brought by the experience on various networks and takes into account all the indicators that were particularly useful in practical situations.



Page 13/156

DRAFT DOCUMENT

5.1.4 HOW TO MONITOR The basic method for monitoring is based on a detection method : A problem or a need of improvement will be detected when, part of the network doesnt fit the required performances : - Performances not in accordance with the operators needs or expectetions. - Difference of performances with the rest of the network - Sudden degradation of performances

Performances could be defined as rates of operations completion or usage of the resources. All of them are described by NMO indicators.



Page 14/156

DRAFT DOCUMENT

Figure 2 : QOS Monitoring Global Process

Data Retrieving Definition

Engineering

Criteria Definition

observation

analyse

O&M

correction

O&M

validation



Page 15/156

DRAFT DOCUMENT

5.2 MONITORING OBSERVATIONSData Retrieving Definition 5.2.1 DATA DEFINITION To measure information about the Network performances, counters are available. Each counter measures a number of specific events, which occurs in an entity of the BSS, during a period. These counter values are stored at the OMC-R. The selected counters provide information about the main sensitive processes : CCCH Radio resources allocation Channel mode Dedicated channel assignment Handover Release of communication Establishment

Engineering

and some entities : - Abis interface, - A interface, - BSC, - cells, - pairs of cells, - neighboring cells. For further information about counters, refer to [A1] document.

5.2.1.1 Periods for counters It is the duration of the events counting in the selected entity of the network. It can be modified. The QOS monitoring daily and hourly periods are used. Busy hour period



Page 16/156

DRAFT DOCUMENTIt corresponds to the hour of the day when the traffic is the highest. It allows to analyze performances of the cells, when the traffic is higher. It is really important for congestion/capacity analysis and also forecasting. Daily period It gives global information on the day. To compare busy hour and daily data, is necessary to check the influence of the traffic. 5.2.1.2 Counters limits y The raw data collected through the counters have to be analyzed from a statistical point of view. It means that it is necessary to have a sufficient quantity of data to trust them. y There is no counter for TRXs. y They depend on the BSS release. This document only applies to V8 release.

5.2.2 NSS OBSERVATIONS : OM (OPERATIONAL MEASUREMENTS)

5.2.2.1 DMS EMULATION It is possible to do it with a PC through every available remote login software. It can also be done with HP unix server. The DMS emulation allows to define an OM class, to define a report containing OM classes, to define where to store the data (device), to start the recording and stop it. All data are recorded in a LOG file which is stored in a device. To use the collected data in netperf, it is necessary to define the MFINGER class, with an OM duration of 30 mn. [name]= MFINGER 5.2.2.2 How to define OM classes? y Check existing classes, and enabled ones >table omacc >lis all y Create a OM class >omclass MFINGER y Activation of a classThis confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 17/156

DRAFT DOCUMENT>pos MFINGER >cha >y y Observation window: It defines the OM duration of a class. >halfhourly >C00 (minutes of the start time) >y (to confirm) >quit y Definition of OM groups belonging to the class MFINGER. The group names are defined in the DMS (ex: MSCCP, TRK...). By default, all groups are attributed to a class. They must be deleted and then delared one by one. >omaccgrp MFINGER delete all >omaccgrp MFINGER add group [groupname] Repeat this command for each group. >quit 5.2.2.3 How to define a report for a class? y definition of the report associated to a class. To each class a report has to be defined. It is identified by an index. It defines which OM groups are recorded in the report (normally, all) and the report duration. This report is described in the table omprt. >table omprt >lis all allows to identify non enabled reports >pos 204 You have to chose a number corresponding to non enabled report. >cha >y (activate it) > >allclass MFINGER all OM groups of class MFINGER are recorded by the report. >daily The report is done every day >hhCmm (start time of the process every day) >hhCmm (start time of the process every day) > > >quite all y This process has to be recorded in the table logclass. >table logclassThis confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 18/156

DRAFT DOCUMENT>add ompr 204 Add the process in the log class >1 >0 >n >0 >n >y (to confirm) 5.2.2.4 Where to record the data? y For each kind of report, a place where to store the data in the DMS has to be selected. Here are the commands to have informations on the device >logutil If you want to evaluate space on DDU >dskut >dv 0 Display the space on the device d000XXXX >dv 1 Display the space on the device d010XXXX If you want to to evaluate space on SLM >diskut >lv 0 Display the space on the device s000XXXX >lv 1 Display the space on the device s010XXXX To see all enabled devices (enabled = outputting log) >listdevs Then chose a disabled device y Add the report 204 in the chosen device [devicename] >addrep [devicename] ompr 204 5.2.2.5 Activity log y To add an activity report to the device: >mapci;mtc;activity >3 forever Start recording process >yes >2This confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 19/156

DRAFT DOCUMENTStart measurement process >addrep [devicename] act 102 Add the act 102 (summary informations) to the selected device

5.2.2.6 Data recording y To record in a file all data coming from the report process or from the Activity report, the device has to be enabled. Then a LOG file is created containing all informations provided by the reports and the activity reports. >startdev [devicename] y When the report is ended, the device has to be disabled. Then the LOG file can be read or imported. >stopdev [devicename] 5.2.2.7 To retrieve the data A nortel software is available to import the LOG files stored in the devices in the DMS. Its name is gws. It is available only on a unix server. From a PC connected to the DMS via a modem, you can just display your LOG file. It is then possible to record these displayed data on your PC. But the validity of your data will depend on the quality of the connection to the DMS. y List your LOG files: On d0x0xxx devices >liv [devicename] all On s0x0xxx devices >lf [devicename] y Print the LOG file : >logutil >print [logfilename]

Criteria Definition



Page 20/156

DRAFT DOCUMENT

Figure 3 Network Optimisation PlatformDATA BASE ACCESS

Report

OMC

Access Data Base Processing

Query

Storage



Page 21/156

DRAFT DOCUMENT

5.2.3 BSS OBSERVATIONS : BSS COUNTERS



Page 22/156

DRAFT DOCUMENT 5.3 METRICS DEFINITIONTo interpret the data coming from the counters, it is necessary to define some metrics. 5.3.1 METRICS CHARACTERISTICS The metrics should reflect the quality of service as it is perceived by the subscribers, at the different levels of the network (cells, town, road, region, global network). A subscriber estimates the quality of service through the following phenomena : call drop (lost) during a communication, difficulties to attempt a call (congestion, interference...), good access to the network (large coverage, indoor coverage...), voice quality.

These criteria can be perceived by the subscribers in a very local place (shopping center, street...), or in a large area (town) or everywhere. Thats why the metrics should be calculated at these different level of the network (cell, group of cells and network). Some processes like handovers have a great impact on the quality of service as perceived by the subscribers. Then it is necessary to define metrics to evaluate handover performances in the network. They should also show an evolution of the quality of service on the network, and allow to assess the impact of network upgrade/optimization (version upgrade, wide parameters change, reparenting, densification...). example : Quality Of Service evolution100 99 98 97 96 95 942-jun 4-jun 6-jun 8-jun 10-jun 11-mai 13-mai 15-mai 17-mai 19-mai 21-mai 23-mai 25-mai 27-mai 29-mai 31-mai 12-avr 15-avr 17-avr 19-avr 21-avr 23-avr 25-avr 27-avr 29-avr 13-jun 1-mai 3-mai 5-mai 7-mai 9-mai

QUALITY OF SERVICE Indicator


Change1

Change2


Page 23/156

DRAFT DOCUMENT

5.3.2 METRICS TARGETS Metrics help for troubleshooting and for improving the network. 5.3.2.1 Troubleshooting All troubles occurring on the network should be detected. A good mean to detect problems, is to compare metrics values with thresholds. The metrics can then be understood as alerts of the network, to troubleshoot bad spot in the network. When a metric underpasses the threshold on a cell or a BSC, this entity has to be pointed out. The threshold crossing is similar to an alarm . The thresholds can be evaluated : y according to the global performances of the network (each network elements performances shouldnt be far from the performances of a bigger entity) y for variation, according to the standard deviation of the indicator of the concerned element y according to the status of the network (maintenance operations can change the performances ) Another method is to classify the cells in function of the metrics values, and to select the worst cells. For each metric a set of the worst cells is obtained that have to be troubleshooted.

5.3.2.2 Improvement To improve the quality of service, the metrics can be compared with target values. They can be defined by the optimization team, according to the operators policy. Another way is to observe evolution of the metrics. It helps to estimate needed improvements, particularly for capacity analysis. By knowing the trend of traffic on cells, capacity increasing can be planned.



Page 24/156

DRAFT DOCUMENT5.3.3 METRICS EXAMPLES (see Also Annex A) Call Drop It is the calculation with counters data of the number of call drop per call exactly as it is perceived by a subscriber. It is defined as the ratio of the call drops divided by the number of communications. It can be calculated at the network level, but also at a cell level. Call Establishment Failure It gives an estimation of the subscriber difficulties to attempt a call, if the capacity of the cell is not full. It is defined as the ratio of the establishment failure divided by the number of establishment indications. TCH assignment failure It is linked to the subscriber difficulties to attempt a call, if the capacity of the cell is not full. But it is different of the call establishment failure rate. It is the rate of TCH assignment failures. The mobile can not get hooked on the proposed channel. Blocking rate TCH & Blocking rate SDCCH They are linked to the subscriber difficulties to attempt a call, because the radio capacity of the cell is full. The Blocking rate TCH (SDCCH) is the rate of allocation failures due to lack of TCH (SDCCH) divided by the number of TCH (SDCCH) allocations attempted. Handover failure rate It gives an estimation of the handover process, which has a great impact on the quality of service, especially on call drop ratio. It is not directly perceived by the subscriber. This rate is of the number of handover failures divided by the number of handovers requested. Average level of non decoded RACHs It is not directly perceived by the subscriber. It is a good indicator to detect jamming interference or hardware problems. Cell Erlang It is not directly perceived by the subscriber. This metrics is useful in two ways. First, if there is no traffic in a cell, it means that something is wrong. Secondly, if the traffic is very high, increasing the radio capacity of the cell has to be studied. A very high traffic has influence on the blocking TCH and SDCCH rates, directly perceived by the subscriber.



Page 25/156

DRAFT DOCUMENT

5.4 TOOLThis chapter describes briefly CT7200 (Netperf) Nortel tool used to process the inputs available to monitor the QOS. CT7200 allows : - to detect bad spots or needed improvements in the network through Top 30 indicators and thresholds - to detect degradation in the network through evolution of some indicators - to analyze the detected problems through numerous indicators and for some of them their evolution.

All needed data coming from the network are stored in a PC and can be post processed through Access, with help of the numerous functionalities of CT7200 tool. 5.4.1.1 Evolution With CT7200, the evolution for each indicators can be seen. They can be estimated for the whole network or only for a group of cells. The evolution period can be selected by the user.TCH Com. allocation 1000000 900000 800000 700000 600000 500000 400000 300000 200000 100000 0 06/07/97 06/08/97 06/09/97 06/10/97 06/11/97 06/12/97 Call drop / TCH Com. allocation 3,90% 3,80% 3,70% 3,60% 3,50% 3,40% 3,30%

Figure 2.6 : Evolution charts of QOS and metrics



Page 26/156

DRAFT DOCUMENT5.4.1.2 Top 30 They represents the worse cells for a certain indicator (Call Drop, Handover Failure,...) They are calculated every day for the whole network or only for a group of cells. They are used to point out the main cells on which effort shall be done.

Example : TOP 30 Drop CallCall_Drop Tch_Com

Call drop ratio (Cell level)Bar graph for visual analysis

700 600 500 400 300 200 100 0

5.4.1.3 Thresholds They can be applied to indicators for the whole network or only for a group of cells. They are used to trigger Alarms.



Page 27/156

DRAFT DOCUMENT 5.5 PROCESSIt is assumed that the quality of service is set up. Some alarm thresholds have been defined, some target values are fixed. Used metrics are determined.

Observation

Analysis

O&M

Correction

O&M

Validation

Figure 4 : QOS Monitoring Process



Page 28/156

DRAFT DOCUMENT5.5.1 OBSERVATION To quickly react to any degradation of the quality of service and keep the satisfaction of the subscribers, it is really important to detect any trouble as soon as it occurs. For this purpose, observation has to be achieved on a daily basis.

In order to have a relevant monitoring, the results must be compared every day. The behavior of a network appears generally different depending on the time of the day, the day of the week or of the month. So, to make sure that the picture of the network is complete, data shall be taken every day. Figures have to be captured also at the times the network is the most demanded : data for busy hour are needed every day.

Data have to be reliable. It means that enough data are cumulated before taking assumptions on the network behavior, so, a serious background of network pictures is required (depending on the traffic, one month data could be needed to be sure of the network behavior and performances).

Monitoring has to be executed first at a global level, then at a BSC levels and then at the cells level with help of the top 30 and of the alarms.

Customer complaints can help to find any bad performances of the network.



Page 29/156

DRAFT DOCUMENT5.5.2 ANALYSIS To analyze a problem, many data are available. They have to be correlated together and also with the network configuration. The use of the Cell Evolution capabilities of Netperf (see [R9]) allows to have the correlation between counters.Example of Cell Evolution from Netperf



Page 30/156

Network Performance Monitoring Guide Book Page 31/156

DRAFT DOCUMENT

1000

2000

3000

4000

5000

6000

10,00%

15,00%

20,00%

25,00%

30,00%

10,00%

15,00%

20,00%

25,00%

10000

15000

20000

25000

0,00%

0,50%

1,00%

1,50%

2,00%

2,50%

3,00%

3,50%

4,00%

4,50%

0,00%

5,00%

0,00%

5,00%

5000

06/97

12/06/97

12/06/97

12/06/97

0

12/06/97

0


08/97

12/08/97

12/08/97

12/08/97

12/08/97

09/97

12/09/97

12/09/97

12/09/97

12/09/97

10/97

12/10/97

12/10/97

12/10/97

12/10/97

11/97

12/11/97

12/11/97

12/11/97

12/11/97

12/12/97 12/97 12/12/97 12/12/97 12/13/97 13/97 12/13/97 12/13/97 12/14/97 14/97 Inter BSC incoming handover failure 12/14/97 Intra BSC incoming handover failure 12/14/97 12/15/97 12/15/97 Call Drop Ratio (Cell) Assignment complete 12/16/97

12/12/97

12/13/97

Establishment Indication

12/14/97

12/15/97

15/97

12/15/97

16/97

12/16/97

12/16/97

12/16/97 Establishment failure / Establishment indication (%)

12/17/97

17/97

12/17/97

12/17/97

12/17/97

12/18/97

12/18/97

18/97

12/18/97

12/18/97 12/19/97 Assignment failure ratio (%) Call Drop Ratio (Group of cells) 12/19/97

19/97

12/19/97

12/19/97

Intra BSC outgoing handover drop

Inter BSC outgoing handover drop

12/20/97

12/20/97

20/97

12/20/97

12/20/97

12/21/97

12/21/97

21/97

12/21/97

12/21/97

12/22/97

12/22/97

22/97

12/22/97

12/22/97

12/23/97 12/23/97 12/24/97

12/23/97

23/97

12/23/97

12/24/97

24/97

12/24/97

12/24/97 12/25/97 12/25/97

25/97

12/25/97

12/25/97 12/26/97 12/26/97

26/97

12/26/97

12/26/97 12/27/97 12/27/97

27/97

12/27/97

12/27/97 12/28/97 12/28/97

28/97

12/28/97

12/28/97 12/31/97 12/31/97

31/97

12/31/97

12/31/97 01/01/98 01/01/98

01/98

01/01/98

01/01/98 01/02/98 01/02/98

02/98

01/02/98

01/02/98 01/03/98 01/03/98

03/98

01/03/98

01/03/98 01/04/98 01/04/98

04/98

01/04/98

01/04/98

01/05/98 0,00% 5,00% 10,00% 15,00% 20,00% 25,00%

01/05/98 0,00% 0,50% 1,00% 1,50% 2,00% 2,50% 3,00% 3,50% 4,00% 4,50% 5,00%

05/98

01/05/98

01/05/98

DRAFT DOCUMENTPower Budget 100,00% 80,00% 60,00% 40,00% 20,00% 0,00% 12/06/97 12/08/97 12/09/97 12/10/97 12/11/97 12/12/97 12/13/97 12/14/97 12/15/97 12/16/97 12/17/97 12/18/97 12/19/97 12/20/97 12/21/97 12/22/97 12/23/97 12/24/97 12/25/97 12/26/97 12/27/97 12/28/97 12/31/97 01/01/98 01/02/98 01/03/98 01/04/98 01/05/98 35,00% 30,00% 25,00% 20,00% 30000 15,00% 20000 10000 0 12/06/97 12/08/97 12/09/97 12/10/97 12/11/97 12/12/97 12/13/97 12/14/97 12/15/97 12/16/97 12/17/97 12/18/97 12/19/97 12/20/97 12/21/97 12/22/97 12/23/97 12/24/97 12/25/97 12/26/97 12/27/97 12/28/97 12/31/97 01/01/98 01/02/98 01/03/98 01/04/98 01/05/98 01/04/98 01/05/98 10,00% 5,00% 0,00% Downlink Quality Downlink Level Uplink Quality Uplink Level

RACH decoded 60000 50000 40000

RACH sent to BSC without Establishment indication (%)

116,00 115,50 115,00 114,50 114,00 113,50 113,00 112,50 112,00 12/06/97 12/08/97 12/09/97 12/10/97 12/11/97 12/12/97 12/13/97 12/14/97 12/15/97 12/16/97 12/17/97 12/18/97

Level of RACH non decoded (-db)

12/19/97

12/20/97

12/21/97

12/22/97

12/23/97

12/24/97

12/25/97

12/26/97

12/27/97

12/28/97

12/31/97

01/01/98

01/02/98

If this first step of the analysis is not enough, or if some hypothesis have to be confirmed, further investigations are necessary : - System check - Verify Operation and Maintenance reporting. - Air/Abis/A interface traces

System Check Operation and Maintenance Reporting Operation and Maintenance has to report of every action conducted on the network. So, only problems which are not related to maintenance actions or operations are analyzed. Air Interface traces They will provide information on the Downlink radio path, as well as protocol information on the completion of operations (calls, location pdates, handovers). Several kinds of mobiles can be used, from simple debug mobiles, which just give basic information (BSIC, BCCH, Neighboring, levels ...) in real time, to sophisticated trace mobiles like R&S suitcase or TEMS.



Page 32/156

01/03/98

DRAFT DOCUMENTThe Nortel BSS/OMC-R also offers possibilities of following one mobile network wildly through its call trace features. This allows to have traces for all normal mobiles used by the subscribers. The call path trace feature records information on a cell, or a TRX. After post processing, many statistics can be calculated, especially the link budget. Abis interface traces (between BSC and BTS) They will allow to monitor the radio performances of one or several calls in both directions: Uplink and Downlink. They will show also the mechanism of resources allocations (TCH or SDCCH) as well as the process of intra BSC handovers. Traces can be done with various analyzers (MA10, K11 or HP), they allow traces display, filters, triggers and some statistics, more or less advanced, depending on the brand, but they all permit to extract the behavior of a specific call, location update or handover. Only MA10 traces are compatible with NMC post processing software ABIS that allows detailed statistical on the traces. Call path trace feature records information on a cell, or a TRX.I t gives statistics on protocol messages. A interface traces (between MSC and BSC) They are used as a complement of investigation because they provide a detailed protocol approach of the problems. It is really efficient to detect any problem between BSS and NSS systems. Traces can be done with various analyzers (MA10, K11or HP), they allow traces display, filters, triggers and some statistics, more or less advanced, depending on the brand. Only MA10 traces are compatible with NMC post processing software AIDA that allows detailed statistics on the traces.

5.5.3 CORRECTION After analysis, some solutions are proposed. A report describing the problem, its analysis and the correctve actions is written, to keep a trace in the network history. In case of a BSS H/W failure suspected, a correction is asked to the Operation and Maintenance team. In case of BSS S/W failure suspected, upgraded versions or patches can be installed. A solution can be a parameters fine tuning for a process and/or in a part of the network. New setting of the parameters is loaded at the OMC-R. To correct radio problems, actions on the radio designed are proposed : tilting antennas, changing the frequency planning, modifying the output power...



Page 33/156

DRAFT DOCUMENTModifying the network configuration may be necessary. For example, by adding TRX in a cell to increase the radio capacity. 5.5.4 VALIDATION When the corrective action has been implemented, it has to be validated. Monitoring must show that the problem has disappeared, on a long term period (one week). No more alarms, or absence of the top 30, or evolution in a good trend. Monitoring has to confirm that the other parts of the network have not been degraded by the correction action : no side effects. It must be observed during several days. If the corrective action can not be validated, another one ,with help of the new results, is proposed, until it can be validated.



Page 34/156

DRAFT DOCUMENT5.5.5 METRICS OBSERVATION AND ANALYSIS 5.5.5.1 Assignment Failures The assignment command is sent to require the mobile switching from SDCCH channel to TCH channel. It is therefore sent only for Mobile originated Calls and Mobile terminated Calls, and not for Handovers (except for intra-cell handover) or Location Update. 5.5.5.1.1 Problem descriptionMSC ASSIGN REQUEST ASSIGN FAILURE (1) ASSIGN FAILURE (2) BSC CHANNEL ACTIVATION CHANNEL ACTIVATION ACK ASSIGN COMMAND ASSIGN COMMAND SABM UA ASSIGN COMPLETE ASSIGN FAILURE (3) ASSIGN COMPLETE ASSIGN COMPLETE BTS MS

(1) The BSC cant allocate the resource requested by the NSS (2) The BTS cant activate the channel requested by the BSC (3) The mobile cant get hooked on the proposed channel

Our case corresponds to (3) since we are looking to Assign Failure after an Assign Command message. In this part we treat only the failures occuring on air interface.

5.5.5.1.2 Detection C1049 (Assignment Command) and C1050 (Assignment Complete) are used to compute the rate of assignment failure shown in the Top 30. Example of the output :



Page 35/156

DRAFT DOCUMENTA S S IG N _ FA IL _R A TIO

sectorN am e

ASS_CM D

ASS_CM P

A S S _ FA IL

om cN am e

B sc N ame

D ate

D -1

D -2

D -3

.NetWork. OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1

xxx XYGBSC1 HANBSC1 XIABSC1 XIABSC2 BAOBSC1 HANBSC1 XYGBSC1 XIABSC3 XIABSC3 XYGBSC1 XYGBSC1 XIABSC3 XIABSC2 ANKBSC1 XIABSC1 XIABSC1 XIABSC1 XIABSC2 XIABSC3 XYGBSC1 XIABSC3 YANBSC1 XYGBSC1 XIABSC3 XIABSC2 XIABSC1 XIABSC3 XIABSC1 XIABSC2 XIABSC1

xxx SXB73_1 SXB85-LY_0 SXB07_4_0 SXB018_4_3_4_1 SXB62_1 SXB82-NZ_0 SXB76_0 SXB027_4_4_4_1 SXB028_4_4_4_0 SXB71_1 SXB73_0 SXB031_4_4_4_2 SXB018_4_3_4_2 SXB92_0 SXB09_4_4_4_0 SXB08_4_2_3_0 SXB011_4_4_4_0 SXB019_4_0 SXB028_4_4_4_2 SXB75_0 SXB030_4_4_4_0 SXB42_0 SXB72_1 SXB032_4_4_4_0 SXB015_4_4_4_0 SXB01_4_4_4_0 SXB029_4_4_4_0 SXB03_4_0 SXB022_2_0 SXB012_2_2_0

29-jul-97 1008115 995955 8718 1.21% 1.23% 1.04% 1.16% 1.19% 29-jul-97 1 0 0 100.00% 0.84% 1.44% 1.04% 1.89% 29-jul-97 1565 1316 244 15.91% 15.55% 6.43% 0.42% 0.00% 29-jul-97 5942 5125 763 13.75% 14.20% 12.90% 13.13% 10.54% 29-jul-97 5258 4599 605 12.53% 11.57% 9.41% 11.73% 1.33% 29-jul-97 2927 2613 289 10.73% 13.36% 9.34% 10.66% 14.90% 29-jul-97 1263 1193 47 5.54% 8.76% 12.31% 9.42% 1.71% 29-jul-97 8425 8148 238 3.29% 3.45% 3.44% 3.64% 3.16% 29-jul-97 8752 8503 219 2.85% 2.81% 1.38% 2.32% 3.32% 29-jul-97 5993 5830 136 2.72% 2.46% 1.81% 2.03% 2.86% 29-jul-97 13121 12772 278 2.66% 2.32% 1.75% 2.12% 2.37% 29-jul-97 1350 1315 20 2.59% 2.02% 2.98% 2.19% 1.86% 29-jul-97 8965 8760 154 2.29% 2.76% 1.24% 1.82% 3.87% 29-jul-97 18452 18038 357 2.24% 2.54% 1.93% 2.59% 2.95% 29-jul-97 314 307 6 2.23% 0.00% 0.90% 1.22% 2.08% 29-jul-97 20387 19937 369 2.21% 1.75% 1.55% 2.06% 1.76% 29-jul-97 3917 3835 65 2.09% 2.44% 1.21% 1.75% 1.83% 29-jul-97 17497 17135 296 2.07% 2.19% 1.91% 1.94% 2.83% 29-jul-97 12300 12047 147 2.06% 3.11% 1.59% 1.78% 2.12% 29-jul-97 18694 18337 300 1.91% 2.23% 1.05% 2.16% 2.57% 29-jul-97 4913 4822 62 1.85% 1.61% 1.62% 1.71% 1.04% 29-jul-97 7619 7480 94 1.82% 1.72% 1.22% 1.29% 1.39% 29-jul-97 1891 1858 25 1.75% 2.15% 3.39% 2.51% 1.54% 29-jul-97 2887 2839 37 1.66% 1.58% 1.68% 1.36% 0.69% 29-jul-97 18996 18694 231 1.59% 1.28% 0.95% 1.05% 1.82% 29-jul-97 12467 12272 115 1.56% 1.29% 1.36% 1.63% 1.13% 29-jul-97 10556 10393 131 1.54% 1.25% 0.61% 1.12% 1.62% 29-jul-97 9595 9447 121 1.54% 1.73% 0.68% 0.81% 1.18% 29-jul-97 6789 6686 69 1.52% 1.43% 1.24% 1.52% 1.07% 29-jul-97 1736 1711 3 1.44% 1.56% 1.16% 1.48% 1.29% 29-jul-97 4940 4871 47 1.40% 1.36% 1.78% 1.33%

Typical metric value for this indicator : 3% and 10%

5.5.5.1.3 Investigation y TRX failures : Some or all of the RTS of a TRX are not working (seen with all the RTS, only the even RTS, only one RTS). The failure rate is proportional to the TCH represented by the faulty RTS compared to all the available TCHs. The problem often comes from the receiver, unable to decode properly the messages sent by the mobile. y Jamming : in some cases, jamming on the uplink or downlink can lead to troubles during assignment.This confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 36/156

D -7

DRAFT DOCUMENTy Interference : because of interference, the mobile may not be able to establish the level 2 link with the BTS, and therefore the assignment fails.

In most of cases, the analysis can be proceeded as follows:Assign Failure ratio Most likely cause:

y Faulty TRX 10%Possible cause: y Faulty TRX y Jamming, interference

3%

y Normal, radio environment impact

y If the assignment failure ratio is greater than 10% or above, then there is a very high probability of a TRX failure. y If the failure ratio is greater than 5%, then there is a high probability of a TRX failure, or severe interference. y If the failure ratio ranges from 3% to 5 %, then it may be due to jamming or interference. y Rates below 3%, are usually due to radio environment. 5.5.5.1.4 Corrective action Incoming handover execution failure : Confirms the trouble on assignment for the rate of handovers failures (HO executed - HO successful)/HO executed must be equivalent to the assignment failures. The execution here, means the execution of the handover on the air interface, where the mobile has to establish a layer 2 link with the BTS, just like during the assignment procedure. High rates of assignment failures (rate greater than 5%) : y Suspect first a TRX problem. Check if the problem has been detected by Operation & maintenance team (alarm, notifications at the OMC-R). y If the problem cannot be seen at the OMC-R (sometimes the case when we have faulty Rx module), Abis interface traces (V7), and Call path trace function (V8), can help finding which RTS of which TRX (TEI) are having no ASSIGN COMPLETE after ASSIGN COMMAND. The problem may be caused by uplink signal losses, caused by a failure in the receiving path. A Path balance measurement of the cell may show the origin ofThis confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 37/156

DRAFT DOCUMENTthe problem. The path balance measurement can be done using either Abis traces, or Call Path Trace functionality (V8). Interference &/or jamming can be verified by other indicators : Handover for quality, RACH efficiency .. and field test with a test mobile.

A global investigation approach when high rate of Assignment Failure is experienced on a cell, is the following:

5.5.5.2

Confirmation with Handover execution failure rate : (HO CMD - HO CMP) / HO CMD equivalent to Assign Failure ratio ?

Assign Failure ratio > 5% ?

Verify if Jamming problem, with the counter on Avg Level of non decoded RACHIdentify the jammer and take appropriate actions

Is there any TRX Failure in that cell seen at the OMC-R ? Verify if it is Interference pb, by looking at Call Drop ratio in the cell, and at HO on UL Quality ratio.

Abis or Call PathTrace to detect which TRX in the cell is causing the failure.

Faulty TRX found?

Verify if it is an Uplink loss, by looking at the ratio of HO on UL level, and confirm by Path balance test.

Identify the interferer, and take action: Tilt, change frequency,..

Inform the O&M team to replace the faulty TRX, and check that Failure rate is back to normal.

Alert O&M team to check the receiving path (cables, connectors, Splitter,.)

Check that Failure rate is back to normal.



Page 38/156

DRAFT DOCUMENT

5.5.5.3 TCH Availability 5.5.5.3.1 Problem description TCH availability (C1056) represents the average number of TCH channels available for a cell. In daily observations the value will range from 0 to the number of TCHs configured for the cell. The gap between the value of the counter C1056 and the maximum shows the outage of the cell. 5.5.5.3.2 Detection The difference between the average value of available channels, and the max number of configured channels reveals the outage of the cell. Hereafter is an example of Nortels engineering tool output (see Figure 2.9)Example of OutputHigh Cell Erlang50.00 TCH Available (Avg) TCH Allocation (Avg)

45.00

40.00

35.00

30.00

25.00

20.00

15.00

10.00

5.00

0.00 X A42_1 X A44_2 X A45_2 X A72_1 X A42_0 X A72_0 X A72_2 X A83_1 X A93_1 X A64_0 X A43_1 X A73_2 X A73_0 X A83_2 X A93_0 X A92_1 X A52_2 X A61_1 X A43_0 X A63_0 X A62_2 SXB61_2 SXB41_0 SXB31_0 SXB71_1 SXB31_1 X A82_2 SXB81-HZ_1 SXB714_1 SXB74_0

Outgoing Intra BSC Handovers

Outgoing Inter BSC Handovers

Incoming Intra BSC Handovers

Incoming Inter BSC Handovers

SDCCH Allocation (Avg)

SDCCH Available (Max)

SDCCH Available (Avg)

SDCCH Radio Failures

SDCCH Blocking Rate

Global Blocking Rate

TCH Allocation (Avg)

Non Decoded RACH

TCH Available (Max)

TCH Available (Avg)

TCH Radio Failures

TCH Blocking Rate

.Network. OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1

xxxx XABSC24 XABSC24 XABSC25 XABSC27 XABSC24 XABSC27 XABSC27 XABSC28 BAOBSC1 YANBSC1 XABSC29 HANBSC1 XABSC26 XABSC24 XABSC27 WEIBSC1 XYBSC XABSC27 XABSC28 XYBSC XABSC29 XABSC29

xxxx XA42_1 XA44_2 XA45_2 XA72_1 XA42_0 XA72_0 XA72_2 XA83_1 SXB61_2 SXB41_0 XA93_1 SXB81-HZ_1 XA64_0 XA43_1 XA73_2 SXB31_0 SXB71_1 XA73_0 XA83_2 SXB714_1 XA93_0 XA92_1

09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97 09/29/97

16:00 16:00 11:00 16:00 11:00 16:00 11:00 11:00 11:00 16:00 11:00 11:00 11:00 10:00 11:00 16:00 10:00 11:00 10:00 10:00 11:00 11:00

4990.36 5029 1814.77 9.79% 322.84 1722.73 1737 8.60% 17.55% 115.07 31678 15905 31890 15934 144 1259 2557 103883 46.00 46 32.91 0.97% 4.19 8.00 8 1.58% 2.54% 114.00 1016 144 1109 125 1 24 11 2031 38.00 38 26.51 4.11% 3.63 7.00 7 2.54% 6.54% 112.00 610 130 560 108 0 11 2 1315 46.00 46 26.42 0.03% 3.63 7.00 7 0.08% 0.11% 114.00 442 940 452 1031 2 23 33 1451 30.00 30 25.03 45.61% 6.00 8.00 8 20.89% 56.97% 112.00 432 0 400 0 1 9 4 1330 46.00 46 24.21 0.00% 3.53 8.00 8 0.00% 0.00% 110.00 724 652 688 656 4 21 8 1441 30.00 30 23.86 30.41% 5.96 8.00 8 16.91% 42.18% 111.00 506 370 421 438 0 17 9 1217 30.00 30 23.76 39.21% 6.23 8.00 8 22.54% 52.91% 113.00 637 106 704 164 3 11 6 1418 30.00 30 23.62 16.04% 5.11 8.00 8 5.31% 20.49% 114.00 212 273 178 252 5 6 3 1229 30.00 30 23.58 33.78% 4.87 7.00 7 19.18% 46.48% 116.00 408 0 423 0 0 12 8 1198 30.00 30 23.57 7.17% 3.42 8.00 8 1.41% 8.48% 117.00 0 0 0 0 1 13 4 1529 30.00 30 23.35 24.50% 6.08 8.00 8 25.76% 43.95% 115.00 557 539 518 561 2 5 18 1086 30.00 30 23.00 13.50% 2.50 7.00 7 4.35% 17.26% 117.00 50 0 48 0 0 10 1 1553 30.00 30 22.74 16.89% 5.09 7.00 7 15.47% 29.75% 113.00 362 495 284 456 1 4 1 979 30.00 30 22.66 13.77% 4.64 7.00 7 12.57% 24.61% 115.00 496 493 432 461 2 5 3 1116 30.00 30 22.61 19.93% 5.09 7.00 7 18.02% 34.36% 105.00 323 510 271 450 1 10 3 978 30.00 30 21.90 8.71% 2.95 7.00 7 1.48% 10.06% 117.00 50 0 45 0 0 5 1 1275 30.00 30 21.57 2.82% 3.34 8.00 8 1.19% 3.97% 116.00 67 3 0 0 2 16 14 1321 30.00 30 21.27 26.95% 5.72 7.00 7 31.95% 50.29% 109.00 402 424 357 399 1 12 3 874 30.00 30 20.75 1.05% 3.36 8.00 8 0.24% 1.28% 111.00 842 259 910 290 2 10 12 1227 30.00 30 20.27 2.74% 2.19 7.00 7 0.04% 2.78% 116.00 220 0 2 0 0 9 5 1034 30.00 30 20.27 27.53% 6.89 8.00 8 37.59% 54.77% 112.00 199 860 234 800 3 15 12 818 30.00 30 19.91 3.00% 3.84 8.00 8 0.56% 3.55% 114.00 369 305 380 321 0 5 3 1082



Page 39/156

Assign Complete

Assign Failures

sectorName

omcName

bscName

Time

Date

DRAFT DOCUMENT

5.5.5.3.3 Investigation It necessarily corresponds to problems on the cell, the site, the BSC, the PCMs that were seen at OMC-R as alarms or actions from the OMC-R operator. It could also be a TRX deactivated or not connected physically inside the shelf. Even if it is redundant with the OMC notifications, it is useful when you dont have access to them directly or when the trouble is old.



Page 40/156

DRAFT DOCUMENT5.5.5.3.4 Corrective action remove these cases from optimization cases, try to evaluate the impact of these problems on other alerts and do not take them into consideration for optimization purposes (It can be useful to detect linked troubles on neighboring equipment (especially for handovers, RLT, Blocking rates ...)) Check, if possible, with the OMC-R notifications Try to group the non maximum cases by sites, BSCs, PCM ... to better identify the place of the problem. Do statistics on the stability of the concerned equipment (cell, site, BSC, PCM) and in case of regular outages, you can ask for a maintenance intervention to clean the problem.



Page 41/156

DRAFT DOCUMENT5.5.5.4 TCH/SDCCH Lack of resources

5.5.5.4.1 Problem description SDCCH Channel :MSC BSC CHANNEL REQUIRED CHANNEL ACTIVATION CHANNEL ACTIVATION NACK IMMEDIATE ASSIGNEMENT REJECT (1) IMMEDIATE ASSIGNEMENT REJECT T3122 starts at the MS BTS RACH/CHANNEL REQUEST MS

(1) The BSC cant allocate the resource requested by the Mobile

The counter C1036 SDCCH Allocation Failure will be incremented every time the BSC sends the message Immediate Assignment Reject , with the cause value Channel Activation Nack . In fact, when no more SDCCH resources are available, the BSC will send an Assignment Reject instead of the Immediate Assignment every time a request is sent by the mobile. The Mobile cannot attempt to access the network again until the timer T3122 elapses.

TCH Channel :MSC ASSIGN REQUEST ASSIGN FAILURE (1) ASSIGN FAILURE (2) BSC CHANNEL ACTIVATION CHANNEL ACTIVATION ACK ASSIGN COMMAND ASSIGN COMMAND SABM UA ASSIGN COMPLETE ASSIGN FAILURE (3) ASSIGN COMPLETE ASSIGN COMPLETE BTS MS

(1) The BSC cant allocate the resource requested by the NSS (2) The BTS cant activate the channel requested by the BSC (3) The mobile cant get hooked on the proposed channel



Page 42/156

DRAFT DOCUMENTOur case corresponds to (1). The counter C1039 TCH allocation Failure is incremented each time it happens as well as a message ASSIGN FAILURE (cause = No radio resource) is sent to the MSC. 5.5.5.4.2 Detection Blocking rate is the ratio of the Allocation failures, with respect to the total allocation requests. Note that the total number of requests for TCH should include as well the overflowing, and the re-establishment. The exact calculation of TCH blocking rate and SDCCH blocking rate (for every cell) is:

SDCCH _ Blocking !

C1036 C1036 C1034 C1051_ 2

TCH _ Blocking !

C1039 C1039 (C1049 C1082)

example of a daily output, concerning TCH blocking:



Page 43/156

DRAFT DOCUMENTTOP N CELLS : TCH ALLOCATIONFAILURE RATIODate : 23/09/97

TCH allocation TCH allocation failure50000

TCH Allocation Failure ratio

45000

40000

35000

30000

25000

20000

15000

10000

5000

0 SB 0 X 31_ SB 0 X 72_ SB 2 X 61_ SB 0 X 63_ SB 0 X 77_ SB 0 X 61_ SB 0 X 36_ SB 0 X 41_ SB 0 X 59_ SB 0 X 78_ S B Z_1 X 81-H S B _2_0 X 022 S B _2_0 X 014 S B _0 X 310 S B 4_4_4_0 X 09_ S B _4_3_4_2 X 018 S B _4_4_4_0 X 026 S B _4_4_4_1 X 026 S B 4_4_4_2 X 09_ S B _4_4_4_0 X 011 S B _4_4_4_1 X 015 S B _4_4_4_2 X 028 S B _4_4_4_2 X 032 S B _4_4_4_0 X 032 S B _3_3_4_1 X 020 S B _2_2_1 X 012 SB 1 X 71_

T H L C IL_R T C _A LO _FA A IO

TH L C C _A LO

TH ES C _R E T

sectorN ame

TH VR C _O E

o mcN me a

T H IL C _FA

B am scN e

D ate

D -1

D -2

D -3

.NetWork. OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1 OMC1

xxx WEIBSC1 XYGBSC1 BAOBSC1 BAOBSC1 XIABSC2 HANBSC1 XIABSC3 XIABSC3 XIABSC2 XYGBSC1 XIABSC1 BAOBSC1 XIABSC1 XIABSC1 XIABSC1 XIABSC2 XIABSC3 WEIBSC1 WEIBSC1 YANBSC1

xxx SXB31_0 SXB72_0 SXB61_2 SXB63_0 SXB018_4_3_4_2 SXB81-HZ_1 SXB026_4_4_4_0 SXB026_4_4_4_1 SXB022_2_0 SXB77_0 SXB014_2_0 SXB61_0 SXB09_4_4_4_0 SXB09_4_4_4_2 SXB011_4_4_4_0 SXB015_4_4_4_1 SXB028_4_4_4_2 SXB36_0 SXB310_0 SXB41_0

29-jul-97 1820813 3339 51643 164995 8.08% 8.39% 2.34% 2.57% 5.36% 29-jul-97 11924 17 1054 20454 61.15% 59.82% 38.21% 48.85% 52.47% 29-jul-97 12298 27 843 16895 56.20% 54.85% 32.14% 37.86% 54.34% 29-jul-97 22974 14 4417 18926 40.85% 40.34% 22.30% 27.64% 48.87% 29-jul-97 18221 6 1116 12891 39.99% 44.15% 24.62% 28.75% 33.83% 29-jul-97 48531 6 4663 22660 29.87% 30.61% 5.44% 10.43% 25.17% 29-jul-97 16742 78 1368 7495 29.18% 32.55% 14.75% 12.46% 42.33% 29-jul-97 20629 38 187 8444 28.82% 0.00% 0.00% 0.00% 0.00% 29-jul-97 29074 7 750 8463 22.10% 15.59% 0.67% 0.25% 7.01% 29-jul-97 2705 9 0 703 20.57% 14.36% 20.22% 16.89% 9.75% 29-jul-97 7851 3 61 1836 18.83% 12.24% 6.83% 8.21% 16.33% 29-jul-97 8152 6 105 1660 16.73% 15.07% 6.49% 7.05% 13.42% 29-jul-97 14032 11 181 2525 15.08% 10.55% 2.53% 2.77% 3.15% 29-jul-97 49078 28 1487 6007 10.61% 11.90% 0.10% 1.36% 10.98% 29-jul-97 41306 16 808 4569 9.78% 20.49% 1.79% 1.07% 9.00% 29-jul-97 42859 27 8307 4945 8.81% 11.22% 0.05% 0.85% 0.93% 29-jul-97 38903 39 819 3419 7.92% 5.35% 0.00% 0.00% 0.00% 29-jul-97 44200 68 2606 3845 7.58% 2.03% 0.14% 0.20% 1.68% 29-jul-97 6576 18 20 520 7.29% 10.82% 0.74% 3.06% 5.46% 29-jul-97 7288 13 32 567 7.18% 7.77% 4.44% 3.20% 7.26% 29-jul-97 18679 8 1042 1472 6.94% 7.53% 1.98% 1.25% 14.53%

Figure 2.10 : TCH blocking (daily output)This confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 44/156

D -7

DRAFT DOCUMENT5.5.5.4.3 Investigation Generally, a lack of resources corresponds to predictable cases : high traffic places, underdimensionned areas ... If not, it can indicate an equipment for which unstability leads to have less resources than configured. It can also show an accident of design like resurgencies, bad frontiers, bad Cell Reselect Hysteresis parameter (too many SDCCH allocations when supposed to be in the middle of a LAC and according to the call profile) or also like handover ping pong execution due to radio, or bad parameters, or bad frontiers (when too many TCHs are coming from a large number of handovers). 5.5.5.4.4 Corrective action y Compare with design teams predictions and parameters y Check that the cell and its neighbors are working correctly. See TCH availability to check the level of stability of the equipment, for the concerned cell and for its neighbors. If a neighboring cell is not working, traffic can be diverted artificially to the serving cell. y Verify the call profile for that cell according to the kind of problem (Location update / Calls or Handovers / Call) and try to find the reasons it could be different. y Detect resurgencies, by checking with Abis traces the distribution of Timing advance in the measurements messages. The rates of Radio Link Failure of that cell can confirm presence of a resurgency in the area (no handover is possible and so a lot of call drops are occurring). To avoid staying hooked on the resurgencing cell, you can : * set the distance parameter for handover to a smaller value. * Tilt the antenna to reduce/eliminate the resurgencies * declare some neighbouring declarations to use the resurgencies (be carefull of possible interferences to and from other cells) y If only SDCCH congestion is experienced, then we can try to minimize the number of Location Update procedures, otherwise we can attempt to reconfigure the TDMA. y Increase the timer T3122 (it avoids successive call attempts) to reduce the load on the system If no optimization solution is found to be efficient, then calculate the missing capacity by determining the required traffic (missing capacity = Required traffic - Offered traffic), and add radio resources accordingly.



Page 45/156

DRAFT DOCUMENT5.5.5.4.5 Calculation of the Missing capacity when a cell is congested: y X% = Measured Blocking rate y y% = Target blocking rate (e.g. 5%) y Alloc_Channels_x = Traffic channels successfully allocated during busy hour (C1051_0) with the x% blocking rate y Block_Channels = Number of allocation requests refused because of lack of channels (C1039) y Overflow_Channels = Number of TCH allocated for signaling purpose. y Global_Channels_request = Alloc_Channels_x + Block_Channels + Overflow_Channels y Carried_Traffic_x = Traffic in Erl measured in the cell with the x% blocking rate (C1052). y Alloc_Channels_y = Traffic channels that should be allocated successfully in the cell to give a y% blocking rate on the global channel requests = (C1051_0 + C1051_2 + C1039) y Offered_Traffic_y = The traffic (Erl) that the cell must be able to carry, in order to give a y% blocking rate on the Global_Channels_request. The first step is to calculate Alloc_Channels_y : y Alloc_Channels_y = Global_Channels_request * y% = (C1051_0 + C1051_2 + C1039)*y% The cell must therefore offer a capacity with y% blocking equivalent to: y Offered_Traffic_y = (Alloc_Channels_y / Alloc_Channels_x) * Carried_Traffic_x = {[(C1051_0 + C1051_2 + C1039)*y%] / C1051_0} * C1052

Using Erlang B table with y% blocking rate, we determine the total required number of TRX, and therefore we determine the number of missing TRX.

Hereafter is the global approach for the investigation when SDCCH or TCH congestion are experienced.



Page 46/156

DRAFT DOCUMENTTCH Congestion Figure 2.12 : TCH congestion

C1039/(C1039+C1051_0+C1051_2) > x% ?

Verify with O&M team if a neighbour of this cell is out of service ?

Check the ratio again after the neighbour is back to service. Alert O&M team, and check the ratio again, after all the TRX are back to service.

all the TRX & Channels of this cell are available (C1056 < nbr of channels in this cell) ?

[C1051_0/(C1051_0 + C1051_2)]*C1052 > Cell capacity in Erl (at BH) ?

The congestion is due to signalling. Go to 2 to treat the SDCCH congestion

Examine the Call mobility profile : Is TCH congestion due to excess of incoming HO : (C1070 + C1069)/C1051_0 > z%

Congestion is due to normal traffic. The site is at max. configuration ?

Identify with geographical map, and counter C1200, if 2 or 3 neighbours have the highest nbr of HO toward the congested cell

Congestion is due to normal traffic. The site is at max. configuration ?

Calculate the missing capacity to handle all the traffic with the target blocking rate (i.e. 5%) * Study the possibility of reducing the nbr of handovers (increase HO_Margin,..)

Add the corresponding number of TRX If no site planned in future phases, verify if enough overlapping to downtilt the antenna or reduce the power of the BTS

1 week observation: C1039/(C1039+C1051_0+C1051_2)> x% ?



Page 47/156

DRAFT DOCUMENTSDCCH Congestion Figure 2.13 : SDCCH CongestionC1036/(C1036+C1034) > x% ?

Examine the mobility Profile: Is the congestion due to excess of Loc Up? C1053_5/7C1053_i > y% ? The congestion is due to traffic.

Increase the parameter Cell Reselect Hysteresis up to 8 dB

Enough TCH TS? i.e. C1052/0 at BH x% ?

Reconfigure the TDMA by adding an SDCCH TS

Enough Tch TS? i.e. C1052/0 at BH depending on the direction of the traffic during the day, the calls dropped there may be concentrated during a couple of hours only). The best for that would be to check with maps first, to take the advice of commissioners and RF teams, then, to go and check on the field. y In order to detect resurgencies or missing neighbouring, program RSV drive tests (cell tests and cluster tests). Abis interface or Call Path trace (V8) traces can help in locating the problem by looking at the timing advance value of the MEASUREMENT RESULT messages just before the CONNECTION FAILURE one.

5.5.5.5.4.2 Interference

It is necessary to identify all sources of interferences and to determine their nature. A lot of measurements on field (RSV, scanning...) are necessary to tackle interferences. Then some actions can be taken such as: Downtilting antennas, cancel an external source, new frequency planning... See Annex B for more details



Page 54/156

DRAFT DOCUMENT

Figure 2.15 : Interference Check

Call_Drop_Cell > 3%

Neighbor Cell Status : See TCH available max

O&M

Neighbor Cell Relationships

Database Check CT7400

Coverage Problem : Hole, Resurgences, Specific Configuration

Cell planing, RSV tests Check TA for Resurgencies

Check Interferences

Check Avg Level of Non decoded RACH To Detect UL Intereferences, UL quality

Check if Bad DL Quality : High ratio of HO on RxQual DL?

Scanning to Detect Uplink External Interference Source

Check internal interference (adjacent or co-channel interf)

Cancel External Source or New Frequency Planning

New Frequency Planning



Page 55/156

DRAFT DOCUMENT

5.5.5.6 Handovers Failures 5.5.5.6.1 Problem description

Handover Indication Channel Activate Channel Activate Ack Handover Command Handover Command Handover Access Physical Info (TA) SABM UA Handover complete Handover Failure Handover detection Establish Indication Handover complete Handover Failure Reset T3103 HO performed HO Failure Set T310

5.5.5.6.2 Detection Two ratios are important to detect any handovers problems. The Handover Selection Failure ratio is the number of HO_COMMAND messages sent from the BSC to the BTS divided by the HO_INDICATION messages received from the BTS by the BSC. It helps to detect any failures due to the load in the target cell, or to a system problem (difficulties to establish the L2 connection between BSC and BTS). At a cell level, we calculate it for both incoming and outgoing handovers. The Handover Execution Failure ratio is the number of HO_COMPLETE messages received by the BSC divided by the number of HO_COMMAND sent by the BSC to the BTS. It is useful to detect any bad radio conditions. At a cell level, we calculate it for both incoming and outgoing handovers.



Page 56/156

DRAFT DOCUMENT5.5.5.6.3 Investigation y Hardware problems : when the rates are very high and correspond to a full hardware entity proportion (see Assignment failures) y Neighboring relations problems y Load of neighbor cells y Bad radio conditions y others Neighboring relations problems If two cells have the same (BSIC, BCCH) with one declared as the neighbor and the other not (first BSIC,BCCH corresponds to a resurgencing cell and the other to a neighbor or both BSIC, BCCH correspond to nearly cells), and if the MS reports the best measurements on the not declared neighbor cell, the handover will be attempted to the declared cell which is not the best one. Then the handover execution can fail. If for a neighbor cell, their BSIC, BCCH, CellId, LAC declared in the adjacent cells table of the BTS, are not coherent with the corresponding BSIC, BCCH, CellId, LAC of the cells table in the BSC, the handover selection will fail also. Load of neighbor cells If the HO selection failure rate is high, it can be due to the load of the neihbor cells, toward which a handover is required. No TCH are available in the target cells (best one, second one...) when the HO_INDICATION message arrives to the BSC. Then the BSC does not send any HO_COMMAND message to the target cell. For each couple (cell, neighbor cell), it is interesting to study the handover selection failure rate and to correlate it with the load of the target cells. Bad radio conditions If the HO execution failure rate is high, it may be due to bad radio conditions in the target or originating cell. y Coverage : if theres not enough overlap between the originating cell and the target cell, the handover can fail. But in this case, the rate of reversion to the old channel may be low, ...... Low overlap pingo r i t a r



Page 57/156

DRAFT DOCUMENT

y Interferences: The level of the neighbor cell was seen good, but the UL or DL quality is bad in the target cell, due to interferences. Then the mobile will fail to complete the handover to the target cell.

If the incoming handover success failure rate for a cell is high, interferences in this cell have to be checked. It is important to check for all pairs of cells, the handover success failure rate to identify if the interferences are located at the limits of two cells or spread on the whole cell. If the outgoing handover success failure rate is too high, it can be DL interferences in the originating cell then the mobile will not receive the HANDOVER_COMMAND message sent by the BTS, and the MS will have a call drop with cause T3103 expiry (cf counter C1164/24). It can also be due to DL or UL interferences in the target cell. It is necessary for each pair of cells to study the handover success failure rate, to identify which cell(s) are interfered. Compare this handover success failure rate with the assignment failure rate for the target cell. They must be similar in case of interferences. In order to confirm the interference on a cell, examine the counters Average Level of Non decoded RACH which reflects uplink jamming, and the counters Ratio of HO on UL Quality and Ratio of HO on DL Quality . Be carrefull with % of HO on RxQual : it depends on RxQual HO Parameters and especially lowerRxQual_XXH

others For Handover Selection Failure, It can be necessary to compare Outgoing Ho Selection Failure from one cell to a neighbor and the Incoming HO Selection failure in the target cell (maybe diffficult to check since no Counters on pair). If Outgoing_Ho_selection_failure>Incoming_Ho_selection_failure : it can means 2 pb : * Database pb (LAC, CellId,... see Neighboring relations problems) : easy to see on A interface with the message HO_Required_Reject (Invalid cell) * NSS pb : Load,.. : It will be Also some Ho_Required_Reject on A interface (possible causes on A interface : Requested Terrestrial ressouce unavailable, equipment failure,...). In order to find out the pb, some NSS Logs (with NSS Nortel) may be necessary. 5.5.5.6.4 Corrective action Neighboring relation problem :This confidential document is the property of NORTEL MATRA CELLULAR and may not be copied or circulated without permission Ce document confidentiel est la proprit de NORTEL MATRA CELLULAR et ne peut tre reproduit ou communiqu sans autorisation


Page 58/156

DRAFT DOCUMENT

y For a pair of cells, check if the handover success failure rate too high is due to resurgencies. Check the timing advance to detect any resurgencies. Discard it by downtilting the resurgencing cell antennas or by changing the frequency plan for the two cells. Another way to avoid those pb is to simply change the BSIC. y Check the database to detect any unconsistencies between adjacent cells table and BTS table. Correct it at the OMC-R if necessary. Cells Load If all cells selected by the bts in the HO_INDICATION message, are too loaded, it will increase the HO selection failure rate. see Corrective action for TCH/SDCCH lack of resources Radio problems y In case of weak overlapping, check it on prediction maps or particular conditions of execution (tunnels ...) and do drive tests to understand better the problem, once identified the place it is located. An issue is to increase the coverage of a cell by decreasing the tilt or increasing the altitude of the antennas. But such modifications will have impacts on all the neighbor cell of the modified one. y Possibly HO Parameters could be optimised (Reduce HoMargin, Reduce RxLevHreqAve or Hreqt, Decrease RxLevMinNcell,...) y Interferences: see Corrective Action for call drop.



Page 59/156

DRAFT DOCUMENTHO failure rate > 6% at a cell level

HO

Date post:	15-Jul-2015
Category:	Documents
Upload:	muhammad-rehan
View:	125 times
Download:	0 times

Network Performance Monitoring Guide Book V02.03

Documents