Network Performance Monitoring Guide Book V02.03

GSM
Network Performance Monitoring Guide Book

Reference : 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
GSM
Reference : Version : Date :
NETWORK PERFORMANCE MONITORING GUIDE BOOK
DRAFT DOCUMENT
TABLE 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
Page 2/156
DRAFT DOCUMENT
4.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...............................................................................................125
Page 3/156
DRAFT DOCUMENT
7. 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. INTRODUCTION
1.1 OBJECT
This document is the Network performance monitoring Guide Book. It aims at helping for performance monitoring of a GSM network.
1.2 SCOPE
This 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 DOCUMENTS
2.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 & DEFINITIONS

3.1 ABBREVIATIONS
NMO NEO RSV QOS Network Monitoring and Optimisation NEtwork Optimisation Radio Site Verification Quality Of Service
3.2 DEFINITIONS
Radio Survey Cell Planning Radio Site Verification Site Survey Network Optimisation
Page 7/156
DRAFT DOCUMENT
4. NETWORK PERFORMANCE MONITORING

4.1 INTRODUCTION
4.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.2
4.2.1
PERFORMANCE MONITORING OVERVIEW

WHAT 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 MONITORING
There 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 DOCUMENT
5.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 DOCUMENT
5.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 OBSERVATIONS

Data 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 DOCUMENT
It 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 class
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 logclass
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 >2
Page 19/156
DRAFT DOCUMENT
Start 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 Platform

DATA 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 DEFINITION

To 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 evolution
100 99 98 97 96 95 94
2-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 DOCUMENT
5.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 TOOL
This 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 DOCUMENT
5.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 Call

Call_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 PROCESS

It 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 DOCUMENT
5.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 DOCUMENT
5.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
12/06/97
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 DOCUMENT
Power 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 DOCUMENT
The 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 DOCUMENT
Modifying 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 DOCUMENT
5.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 description
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
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 DOCUMENT
A 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.
Page 36/156
D -7
DRAFT DOCUMENT
y 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 of
Page 37/156
DRAFT DOCUMENT
the 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 RACH
Identify 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 Output
High Cell Erlang
50.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 DOCUMENT
5.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 DOCUMENT
5.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 DOCUMENT
Our 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 DOCUMENT
TOP N CELLS : TCH ALLOCATIONFAILURE RATIO
Date : 23/09/97
TCH allocation TCH allocation failure

50000
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)

Page 44/156
D -7
DRAFT DOCUMENT
5.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 DOCUMENT
5.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 DOCUMENT
TCH 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 DOCUMENT
SDCCH Congestion Figure 2.13 : SDCCH Congestion
C1036/(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 << Cell capacity (Erl) ?
After 1 week observation, still C1036/(C1036 + C1034) > x% ?
Reconfigure the TDMA by adding an SDCCH TS
Enough Tch TS? i.e. C1052/0 at BH << Cell capacity (Erl) ?
Cell at maximum configuration ?
Study the possibility of reducing LocUp by reparenting the site.
Add a TRX.
Page 48/156
DRAFT DOCUMENT
5.5.5.5 Call drop (TCH) Call drop is experienced when the call cuts during the conversation phase, i.e. after a TCH has been assigned. Usually, there are 3 major reasons for call drop: - Radio Link Failure (Radio Link Timeout in Nortels system) - Handover timer T3103 expiry - Other system faults 5.5.5.5.1 Problem description a) Radio Link Time-out
MSC BSC BTS MS
(1)
MEASUREMENT RESULT
(2)
MEASUREMENT REPORT
...
CONNECTION FAILURE CLEAR REQ (Radio Interface Failure)
(3)
(1) Dedicate channel (TCH or SDCCH) is established (2) If Abis spy is activated (3) SACCH block not decoded, Radio Link Timeout expiry
The SACCH blocks (MEASUREMENT REPORT messages) couldnt be sent by the mobile, or were not decoded by the network (BTS) for a time computed from Radio Link Time-out and before any suitable handover occurred to save the call. Counters C1164/13 and 14 count the number of Connection Failure Indication due to Radio Interface Failure and Radio Link Failure (in V8 version).
Page 49/156
DRAFT DOCUMENT
b) T3103 expiry (ex for IntraBSS HO):
Handover Indication Channel Activate Channel Activate Ack Handover Command Handover Command Handover Access Physical Info (TA) SABM UA Handover complete Handover detection Establish Indication Handover complete Reset T3103 HO performed Set T3103
The BSC sets the timer T3103, just when the Handover Command message is sent to the BTS. The timer is Reset on reception of either a Handover complete (the handover succeeded), or Handover failure (the handover failed on air interface, but the mobile can revert to the old channel). If the timer expires before reception of any of these two messages, then the BSC will release the radio channels, thus leading to a call drop. The counter C1164/24 in V8 (C8020 in V7), is increased every time the T3103 expires. Therefore, this counter gives the number of mobiles lost during a handover procedure.
c) System failures Call drop can be due to other system failures, such as O&M, A interface timers expiry,.. These cases which are not directly linked to the radio interface can be investigated apart, and may involve the BSS as well as the NSS. In this document we will restrain our analysis to the causes directly linked to the quality of the radio interface, i.e. Radio Link Timeout and T3103 expiry. 5.5.5.5.2 Detection The Ratio of Call Drop is the combination at the busy hour of Radio Link Timeout and Handover drop (V7), and the combination of all possible causes for V8. The exact formula for calculating the Call Drop for every cell is: C8020 C1025 Call _ Drop _ cell ! (BSS V7) C1055 C1074 C1073
Page 50/156
DRAFT DOCUMENT
C1164 _ i C1164 _ 20
Call _ Drop _ cell !
i!0
30
C1055 C1074 C1073
(BSS V8)
Note that for the cell level, the number of TCH allocated for incoming handovers is taken into account. Otherwise, the ratio of call drop may be far greater than 100% if the number of calls leaving a cell by Outgoing Handover is greater than the number of calls established in the cell. If the ratio of call drops has to be checked on the whole network, only the number of call is taken into account. The number of TCH allocated for incoming handovers is not taken into account. As the whole network is considered, the number of incoming handovers will be equivalent to the number of outgoing handovers. For the whole network, the formula for call drop will be:
Call _ Drop _ ratio !
C8020 C1080 / 0 C1080 / 1 C1080 / 2 C1080 / 3 C1080 / 4

BSC cell
(C1050 C1083)
BSC
cell
30 C1164 _ i C1164 _20 BSC cell i ! 0 Call _ Drop _ ratio ! (C1050 C1083) BSC cell
(V8)
Page 51/156
DRAFT DOCUMENT
An example of the output of the TOP 30 for Call drop:
Call_Drop Tch_Com
Call drop ratio (Cell level)
700 600 500 400 300 200 100 0
Figure 2.14 : Call drop ratio (cell level)
Page 52/156
DRAFT DOCUMENT
5.5.5.5.3 Investigation
5.5.5.5.3.1 Coverage holes
Coverage holes are either real ones (end of covered area) or fake ones (due to missing neighbouring for instance). In some places where a fast decreasement of level is expected (tunnels accesses, buildings doors, Metro,...) it can be an indication that the handover that should have occurred wasnt decided fast enough. So, the serving cell has been lost before being able to hook on the new one. If the handover command was sent by the BTS, then the counter C1164/24 in V8 (C8020 in V7) will be incremented, otherwise, the counter C1025 will be incremented. Coverage holes can be due to a temporary missing cell (a cell is down for any maintenance reason). Coverage holes can be due to a missing neighbouring (drag in the call even if another cell would be suitable to carry on). A resurgency can appear if you hooked on the cell and at the time you should be leaving it for another cell, no proper handover relation is available for that : One may then drag in the call until the limits of the resurgency. And as usual, if the rate is very high (near 100%), think of any hardware problem.
5.5.5.5.3.2 Interference
Interference can be either internal (created by the network), or external created by intermodulation from other networks (GSM, AMPS, TACS,..). When severe interference is experienced on the network, the BTS and the MS cannot decode the SACCH blocks because of the high Bit Error Rate, and the call cuts because of the Radio LinkTimeout. Interference will have also a negative impact on handovers, because if the Bit Error Rate is very high on the downlink direction, then the Handover Command sent by the BTS will not be decoded by the mobile. The call drop will be recorded at the OMC-R with the cause T3103 expiry. In order to confirm the interference on the 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 .
See Annex B for more details.
Page 53/156
DRAFT DOCUMENT
5.5.5.5.4 Corrective action
5.5.5.5.4.1 Coverage Holes
y If the problem seems to be temporary, check if neighboring of the cell were on for that time (see TCH availability)
y Check that the neighbouring relations are all declared (Netconf) with all the
reciprocities.
y Check with the design teams predictions if any coverage hole is expected in
the area (no need to work on perfectly well known problems that may find a solution in a couple of months by the installation of a new site)
y Check with the design teams the existence of specific conditions : Tunnels, big
building entries (commercial centres ...), metro entries, big slopes (the problem may appear more in one direction than another relatively to the speed of the vehicles => 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 DOCUMENT
5.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 ping
o 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 :
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 DOCUMENT
HO failure rate > 6% at a cell level
HO selection failure rate > 6%
Check HO selection failure rate by pair of cell
HO success failure rate > 6%
For each target cell, check the load
Correct it at the OMC-R
Check database
Check any system trouble (BSC BTS)
Check HO success failure rate by pair of cell
Cancel it (downtilt, new frequency...)
Detect resurgencies (Abis trace, call perf)
Check HO for UL, DL level, correct weak cells overlap
Reestablishment rate > % Call drop ratio >% in originating cell
Check C1164/24 Correct interferences in originating cell
Check RACCH level Assignment failure, HO for UL quality in target cell
Confirm UL interferences and cancel them
Page 60/156
DRAFT DOCUMENT
Assignment failures HO for DL quality in target cell Confirm DL interferences and cancel them
Figure 2.16 : Corrective actions (handover failure)
Page 61/156
DRAFT DOCUMENT
5.5.5.7 Handovers for downlink quality
5.5.5.7.1 Problem description This is one case of on alarm handover : the handover is performed not because he had a neighbouring becoming a better cell , on the contrary of Power budget handovers, but because the conditions on its serving cell are becoming too poor. There, the BSC elects the best neighbouring cell as the target of the handover. Here the alarm is due to L_RXQUAL_DL_H (Ref. [R8]), the threshold configured in the network for downlink quality. 5.5.5.7.2 Detection Counter C1038[3] counts the nb of HO triggerred when Downlink Quality Threshold L_RxQual_DLH is crossed. Note : When both thresholds, Quality and Level are crossed, the priority is given to Quality. Also, when both L_RxQual_DLH and L_RXQUAL_ULH are crossed, it is the counter that counts the nb of HO for UPLINK that is incremented (C1038[2]). Rate_ Of _ HO_ on _ DL_ Quality ! C1038[ 3]
C1038[i]
Be carrefull : The Rate_Of_HO_on_DL_Quality highly depends on the HO Parameters. So some care has to be taken when interpreting the above rate (10% when L_RxQual_DLH=5 is different than 10% when L_RxQual_DLH=4 ! ! !)
Monday 13 Jan 1997 Minimum Nb. of values : Thresholds : 50 30,00%
HO Downlink Quality
%Qual CI 1151 1294 266 438 1021 857 436 145 la c 2 3 9 8 3 4 8 7 netbscid BSC020 4 BSC020 6 BSC000 5 BSC000 8 BSC020 2 BSC010 7 BSC000 8 BSC000 3 Site 398 448 189 375 373 240 375 337 Cell B A B C A B A A %DQ 94,78% 93,26% 86,19% 80,40% 80,00% 79,65% 73,88% 71,07% %UQ 5,02% 2,47% 3,82% 5,24% 2,70% 2,82% 5,04% 4,41% Tot HO 498 890 811 1087 185 850 892 1725 D-1 96,18% 95,62% 83,05% 82,74% 87,63% 84,93% 80,28% 75,69% %Qual D-2 98,91% 95,11% 85,67% 81,51% 82,25% 83,92% 85,46% 76,51% %Qual D-3 90,08% 98,17% 87,75% 84,69% 81,93% 84,65% 78,61% 72,56% %Qual D-4 97,72% 100,00 % 88,02% 85,88% 65,80% 85,44% 73,48% 74,33% %Qual D-5 99,12% 100,00 % 87,79% 84,95% 77,51% 85,81% 75,19% 73,05%
Page 62/156
DRAFT DOCUMENT
5.5.5.7.3 Investigation y Too strict configuration of the Handover parameters y Hardware problems : Especially if the rates are high (around 100%) it can be due to the radio parts of the BTS on the downlink (TRX, transmission antenna, feeders ...) y GSM interference : co-channel or adjacent channel y Radio Coverage : HO for UL Quality as well as HO for Level reasons (UL and/or DL) shall be observed on the cell.
Page 63/156
DRAFT DOCUMENT
5.5.5.7.4 Corrective action Parameters suspected: y Verify with Netconf that the handover parameters set for that cell are relevant Hardware problems suspected : y If there is a hardware problem on the downlink, the cell should be nearly mute, at least on some of its timeslots, so, it can be interesting to check the quantity of traffic, especially to compare incoming and outgoing handovers. y If there is a hardware problem on the downlink, there may be handovers for downlink level, assignment failures, radio link failures, more on that cell than in general. y If there is a hardware problem on the downlink, there may be VSWR alarms at the OMC-R. y Do Abis traces to check the balance uplink/downlink and the distribution of the level on the downlink. y On site, measure VSWR, check the cabling of the transmission part y GSM Interference : y Abis traces analyzed with ABIS software should show bad quality with high level on the downlink. y f there is a lot of traffic on the cell, there may be the same behavior on the uplink => handovers for uplink quality. y Study cell planing maps to try to find out which other cell could be interfering (it may not be binary, it could be a resurgency of a cell) If the problem appeared recently, it could correspond to a new site put in service. y Do drive tests to try to identify the cell interfering. y To check the founded interfering cell, switch it off and check if it remains bad. Radio Coverage : y See Call Drop Analysis
Page 64/156
DRAFT DOCUMENT
5.5.5.8 Handovers for uplink quality
5.5.5.8.1 Problem description This is one case of on alarm handover : the handover is performed not because a neighbouring is becoming a better cell , on the contrary of Power budget handovers, but because the conditions on its serving cell are becoming too poor. There, the BSC elects the best neighbouring cell as the target of the handover. Here the alarm is due to L_RXQUAL_UL_H (Ref. [R8]), the threshold configured in the network for uplink quality. 5.5.5.8.2 Detection Counter C1038[2] counts the nb of HO triggerred when Uplink Quality Threshold L_RxQual_ULH is crossed. Note : When both thresholds, Quality and Level are crossed, the priority is given to Quality. Also, when both L_RxQual_DLH and L_RXQUAL_ULH are crossed, it is the counter that counts the nb of HO for UPLINK that is incremented (C1038[2]). C1038[2]
Rate _ Of _ HO _ on _ UL _ Quality !
C1038[i]
Be carrefull : The Rate_Of_HO_on_UL_Quality highly depends on the HO Parameters. So some care has to be taken when interpreting the above rate (10% when L_RxQual_ULH=5 is different than 10% when L_RxQual_ULH=4 ! ! !)
5.5.5.8.3 Investigation y Bad parameters settings y If rates are high, it is probably a hardware problem on the radio uplink transmission part (TRX, antenna, diversity, feeders) y Coverage problems (if also associated to handover for uplink level) y Jamming on the uplink (especially if confirmed by bad RACH efficiency) y GSM interference : if theres an equivalent rate of handovers for downlink quality
Page 65/156
DRAFT DOCUMENT
5.5.5.8.4 Corrective action Parameters suspected: y Verify with Netconf that the handover parameters set for that cell are relevant Hardware problems suspected : y If there is a hardware problem on the uplink, the cell should be nearly deaf, at least on some of its timeslots. So it can be interesting to check the handover failures on incoming (the downlink is correct so the handover is executed, but its barely successful for the uplink is bad). y If there is a hardware problem on the uplink, there may be handovers for uplink level, assignment failures, radio link failures, more on that cell than in general. y Check the indicators of RACH efficiency y Do Abis traces or Call Path Trace to check the balance uplink/downlink and the distribution of the level on the uplink. y On site, check the cabling of the transmission part y Check for possible near Repeater, Antennas from other Operators : BS_Power may have to be decreased (Especially if Bad RxQual is observed at High levels and is better at weaker levels), repeater Gain can be tuned (lowerred a litlle bit) Jamming suspected : y Check the indicators of RACH efficiency y Go on site with a spectrum analyzer and check the GSM uplink frequency band, over a day when high rates where found (the phenomenon can be transient) GSM Interference : Same verifications as for downlink quality
Page 66/156
DRAFT DOCUMENT
5.5.5.9 Handovers for Downlink Level
5.5.5.9.1 Problem description This is one case of on alarm handover : The handover is performed not because a neighbouring is becoming a better cell , on the contrary of Power budget handovers, but because the conditions on its serving cell are becoming too poor. There, the BSC elects the best neighbouring cell as the target of the handover. Here the alarm is due to L_RXLEV_DL_H (Ref. [R8]), the threshold configured in the network for downlink level. 5.5.5.9.2 Detection Counter C1038[1] counts the nb of HO triggerred when Downlink Level Threshold L_RxLev_DLH is crossed. Note : When both thresholds, Quality and Level are crossed, the priority is given to Quality. C1038[1] Rate _ Of _ HO _ on _ DL _ Level ! C1038[i ]
5.5.5.9.3 Investigation In normal cases, this should be very rare so if the rates are high it is probably : y Bad parameters settings y Hardware problems on the downlink 5.5.5.9.4 Corrective action Same checkings as for downlink quality in case of bad settings or hardware problems.
Page 67/156
DRAFT DOCUMENT
5.5.5.10 Handovers for uplink level
5.5.5.10.1 Problem description This is one case of on alarm handover : the handover is performed not because a neighbouring is becoming a better cell , on the contrary of Power budget handovers, but because the conditions on its serving cell are becoming too poor. There, the BSC elects the best neighbouring cell as the target of the handover. Here the alarm is due to L_RXLEV_UL_H (Ref. [R8]), the threshold configured in the network for uplink level. Note : When both thresholds, Quality and Level are crossed, the priority is given to Quality. 5.5.5.10.2 Detection Counter C1038[0] counts the nb of HO triggerred when Uplink Level Threshold L_RxLev_ULH is crossed. Note : When both thresholds, Quality and Level are crossed, the priority is given to Quality. C1038[0] Rate _ Of _ HO _ on _ UL _ Level ! C1038[i] 5.5.5.10.3 Investigation y Insufficient coverage (if associated also with an equivalent rate of uplink quality) y Bad handover parameters settings for the cell y Hardware problems (high rates) if the downlink and the uplink are not balanced y Could come from ping pong handover between two cells (one leaves one of the cells for quality, then comes back for level and so on, for example) 5.5.5.10.4 Corrective action Parameters suspected: y Verify with Netconf that the handover parameters set for that cell are relevant Hardware problems suspected : y Abis traces to check the link budget of the cell Coverage or problems between 2 cells : y Check with Design predictions
Page 68/156
DRAFT DOCUMENT
y Do drive tests if that problem is unexpected with the help of timing advance found in the Abis traces to help localizing the problem y Try to find the responsible neighbouring, the causes of its outgoing handovers and, especially if quality, the cause of that bad quality on the neighbouring.
Page 69/156
DRAFT DOCUMENT
5.5.5.11 Handovers for distance
5.5.5.11.1 Problem description This is one case of on alarm handover : the handover is performed not because he had a neighbouring becoming a better cell , on the contrary of Power budget handovers, but because the conditions on its serving cell are becoming to poor. There, the BSC elects the best of the neighboring cells as the target of the handover. Here the alarm is due to MS_RANGE_MAX (Ref. [R8]), the threshold configured in the network for estimated to far distance. 5.5.5.11.2 Detection Counter C1038[4] counts the nb of HO triggerred when TA crosses the threshold MS_RANGE_MAX Rate _ Of _ HO _ on _ Dis tan ce ! C1038[ 4] C1038[i ]
Note : Distance has a lower priority than Quality and Level happens, the level and quality are necessarily better than the thresholds set for the cell. 5.5.5.11.3 Investigation y Bad parameters settings (especially if it is set to a very small distance =. The parameter range is the same as the one for timing advance, 1 mean 500m and not 1km. y Resurgency of the cell y Wrong neighbouring : One is dragging in the call very far, maybe at some point a handover should have been done to avoid this, but one didnt. So, now, the handovers are tempted from further. y Hardware problems : on one of the neighbouring (same behavior as previous point) 5.5.5.11.4 Corrective action y Check parameters y Check that the fault is remaining (if a maintenance problem happened to one of the neighbouring, it is pointless to get worried for this one) y Check the other indicators (Radio link failure, handover failures ...)
Page 70/156
DRAFT DOCUMENT
y Do Abis traces to confirm and determinate the area of a possible resurgency y With A traces determinate the cell with which the handovers are tempted, that will give information on the BSIC/BCCH of a possible cell in the neighbouring of the resurgency, if any.
Page 71/156
DRAFT DOCUMENT
5.5.5.12 RACH Efficiency
5.5.5.12.1 Problem description

MSC BSC CHANNEL REQUIRED BTS RACH/CHANNEL REQUEST MS
(2)
CHANNEL ACTIVATION CHANNEL ACTIVATION ACK IMMEDIATE ASSIGNEMENT
(1) (3)
IMMEDIATE ASSIGNEMENT SABM UA
ESTABLISH INDICATION
(4)
(1) RACH decoded (2) RACH transmitted to the BSC (3) SDCCH Allocation (4) LapDm established
A RACH can be considered as efficient if it is sent by a real mobile station (there will be an ESTABLISH INDICATION for any reason) Burst RACH are small, with not a lot of information, so it is likely that parasites can be taken as RACH burst, leading to a useless SDCCH allocation, but, in general, if one cant avoid parasites of that type, they shouldnt be too numerous or with a too high level. 5.5.5.12.2 Detection y High level for the non decoded RACH (noise RACH) : the level is high, but the BTS cant decode the inside (information badly coded) y Rate of decoded RACH (RACH transmitted to the BSC / Total RACH) y Low rate of LapDm establishments compare to SDCCH allocations (<70%) y High rate of CHANNEL REQUEST (non GSM) compare to the normal ones. Be carrefull to have sufficient traffic in the cell first. y (*** to be completed ***) 5.5.5.12.3 Investigation y Jamming on the uplink y H/W pb in the receiving path y Downlink/Uplink badly balanced
Page 72/156
DRAFT DOCUMENT
y Bad parameters (RxLev Access Min)
Page 73/156
DRAFT DOCUMENT
RACH Level too high: Under normal radio conditions, the BTS should be able to decode all the RACH bursts received with a level higher than its sensitivity in the given radio propagation profile (Typical Urban 3, Typical Urban 50, Rural Area 250,...). In a non interfered environment, the sensitivity of the BTS depends on its noise factor, and its thermal noise power. Usually the sensitivity (without taking into account the fading margin), is around -115 dBm. Uplink interference and jamming, reduce the sensitivity of the BTS, which cannot decode properly the bursts received at very low level (around -115 dBm). RACH Level too low: Low level of Undecode RACH (<120) usually shows Path Balance Problem with the Uplink.
Avg Level of non decoded RACH

Most likely causes: - Very severe jamming - H/W pb in the receiver Possible causes: - HW pb in the receiver - Jamming - Very severe UL interference -110 dBm -115 dBm The most likely cause: Uplink Interference Normal Uplink Interference Possible cause : Path Balance Pb
-105 dBm
-120 dBm
Page 74/156
DRAFT DOCUMENT
Low rate of Establish Indications : Only a few SDCCH are allocated for a mobile channel request. The problem could be one these two possibilities: Most likely cause: Signal losses in the receiving path at the BTS (cables, RxSplitters, connectors, DRX for S8000..) so that Access bursts sent by the mobile are not received by the BTS, or their level is too low (<-110 dBm) to be decoded. The uplink path was good enough for the CHANNEL REQUEST (small message), it cant reach the LapDm level of the connection (quality problem on the uplink) SDCCH for non GSM : A high rate of them, associated to a low rate of establish indications confirms jamming or uplink hardware problems. Under normal radio conditions, this counter shall not exceed 1 to 5% of the total SDCCH allocations. 5.5.5.12.4 Corrective action y Check the persistency of the fault y Check the rate of handovers for uplink quality y Check the failures in incoming handovers (if there is a hardware problem on the uplink, there should be a lot of failures : the downlink is seen good, so a handover is tried, but the uplink doesnt permit its successful completion) y Compare the number of operations : handovers incoming, establish indication, assign command : if theres a problem on the uplink, there should be a few establish indication and assign command compared to the number of incoming handovers. y Check the link budget with Abis interface traces OR Call Path Trace y Check the site and in particular the uplink part (TRX, antenna, feeders) y Check for interference with a spectrum analyzer
Page 75/156
DRAFT DOCUMENT
Case 1: Low number of Establishment Indications
Low number of Establish Indication : C1195+C1196 << Normal avg value of this counter ? High nbr of Non GSM SDCCH allocations ? C1191[1+2+3+]>> its normal avg value ? Jamming test : - Scanning of the frequency band
Verify the Uplink level of received signals by doing: - Call path trace test (V8) - Call monitoring or Abis trace (V7) Weak Uplink level ?
Alert O&M team, and verify after site intervention that the problem is fixed.
Figure 2.17 : low number of Establishment Indications
Page 76/156
DRAFT DOCUMENT
Case 2: High value of Avg Lev. of Non decoded RACH
High Avg Level of non decoded RACH: C1033>> Normal avg value of this counter ?
Avg Level of non decoded RACH > -105 dBm ? Check with O&M team : Problem seen on that site?
Perform a Call Path Trace on the cell. Is the problem proper to one particular TRX?
Check after O&M intervention Scan the frequency band around the cell to check for external jamming or intermodulation
Alert O&M team, and verify after that problem fixed after faulty TRX was replaced
High ratio of Handover on RxQual UL ?
Variation of this level with traffic?
Pb might be due to external jamming
The problem is due to UL interference. Check the frequency plan, and determine solution to fight the interference. Figure 2.18 : High Value of Average level of nondecoded RACH
Page 77/156
DRAFT DOCUMENT
5.5.5.13 No traffic/Handovers/SDCCH 5.5.5.13.1 Problem description Compared to the proportions of the network, there is y y y 5.5.5.13.2 Detection Handovers Here is considered the incoming Handovers C1074 computes the nb of incoming inter BSS HO Complete C1073 computes the nb of incoming intra BSS HO Complete only a few of handovers (up to none) only a few of establish indications (up to none) only a few of assign complete (up to none)
Establish Indication Establish Indication on SDCCH is computed with the formula : C1195+C1196 Assign Complete C1050 computes the number of Assign Complte 5.5.5.13.3 Investigation y Bad settings : cell barred but handovers enabled, or vice versa ... y Hardware problems : a few calls for a lot of incoming handovers, could be a problem on the uplink 5.5.5.13.4 Corrective action y Depending on the dimension of the problem (none or a few), check the settings y Check other rates (handover for uplink quality in particular) y Do Abis traces and link budget verification to detect hardware problems.
Page 78/156
DRAFT DOCUMENT
6. PARAMETERS AUDIT
6.1 INTRODUCTION
6.1.1 OBJECT The aim of this chapter is to describe a process to evaluate the validity of the parameters for a network. It gives some indications to correct them. First are described main OMC-R objects and corresponding parameters to audit. For some of these parameters, a recommended value is given. Then the method is to determine default values for the infuential parameters, at network level. These network default values are compared to available recommended values. These newly determined network default values must be compared with all corresponding items in the network configuration database. The consistency of the database must be checked: all data have to be coherent, some simple rules have to be observed.
Page 79/156
DRAFT DOCUMENT 6.2 BSS PARAMETERS

Each BSS parameter is defined in an OMC-R object, with a particular value. For some parameters, a recommended value is given. Hereafter are described the most important BSS parameters to audit the network configuration consistency. 6.2.1 CLASSIFICATION The OMC-R objects are classified in five families : y cells parameters y neighbor cell parameters y handover parameters y power control parameters y TRX parameters. 6.2.1.1 Cells parameters This family contains the following OMC-R objects: y bts. In the OMC-R, the bts object defines all configuration parameters for a unique cell. y btsSiteManager. This object defines all the configuration parameters for a site. Typically, a site is composed of three cells, which means that the btsSiteManager object is often linked to the three corresponding bts objects. 6.2.1.2 Neighbor Cells parameters This family contains the following OMC-R objects: y adjacentCellHandOver. In this object, for each cell of the network, the neighbor cells here a handover can be performed are defined. Some parameters allow to identify the cell and the neighbor cell. The other ones are elated to handover process. y adjacentCellReselection. In this object, for each cell of the network, the BCCH of neighbor cells is given for the reselection process.
Page 80/156
DRAFT DOCUMENT
6.2.1.3 Handover parameters This family contains the following OMC-R object: y handOverControl. In this object, for each cell of the network, the parameters for intracell, intercell handovers are defined. 6.2.1.4 Power control parameters This family contains the following OMC-R object : y powerControl. In this object, for each cell of the network, the parameters for power control process are defined. 6.2.1.5 TRX parameters This family contains the following OMC-R objects: y channel. This object gives configuration parameters for each radio Time Slot (channel type, hopping parameters if needed...). y transceiver. This object gives configuration parameters for each TRX. y pcmBtsSiteManager. This object gives configuration parameters for PCMs linked to the sites. 6.2.2 RECOMMENDED VALUES For some parameters, a value is recommended (cf [R1]). This value is consistent for the main networks in the world, but in some specific configurations (environment...), a better setting can be determined. That is why default values have to be defined for each network. Hereafter are given the general recommended values for some parameters of the OMC-R objects described before. 6.2.2.1 Cells parameters
Page 81/156
DRAFT DOCUMENT
Table: bts
Parameter bscId btsSiteManagerId btsId CELLNBR MobileCountryCode MobileNetworkCode locationAreaCode cellIdentity networkColourCode baseColourCode bCCHFrequency cellReselectHysteresis msTxPwrMax rxLevAcessMin radioLinkTimeOut RACHBTHRESH raCHLoadAveragingSlots thresholdCCCHLoadIndication PeriodicCCCHLoadIndicationU PeriodicCCCHLoadIndicationV ADMSTATE ctrlStatus CREASTATE maxNumberRetransmission numberOfSlotsSpreadTrans NY1 noOfBlocksForAcessGrant noOfMultiframesBetweenPaging msTxPwrMaxCCCH cellBarred callReestablishment emergencyCall smsCB dtxMode btsIsHopping iMSIAttachDetach timerPeriodicUpdateMS SDCCHSAPI0 FACCHTCHF FACCHTCHH SACCHTCHSAPI0 SACCHSDCCH SDCCHSPAI3 SACCHTCHSAPI3 t3101 t3103 t3105 t3107 Recommended Value
4 dB (rural), 6 dB (urban) 33 dBm (GSM 900) 30 dBm (GSM 1800) -101 to -100 (GSM 900) -99 to -98 (GSM 1800) 20 SACCH
33 dBm (GSM 900) 30 dBm (GSM 1800) not allowed
Page 82/156
DRAFT DOCUMENT
t3109 t3111 t3113 bsMsmtProcessingMode unknownNCellWarning callClearing Diversity powerControlIndicator t3122 runCallClear runHandOver runPowerControl cellDeletionCount CELLTHRESHOLD cellType cellDtxDownlink allocPriorityThreshold answerPagingPriority assignRequestPriority callReestablishmentPriority emergencyCallPriority interCellHoExtPriority interCellHoIntPriority intraCellHoIntPriority otherServicesPriority allOtherCasesPriority IntraCellQueuing cellName MICROCSPARE1 MICROCSPARE2 SOINDEX cellBarQualify cellReselInd cellReselectOffset penaltyTime temporaryOffset rlf1 rlf2 rlf3 btsThresholdHopReconf btsHopReconfRestart abisSpyFlag radResSupervision delayBetweenretrans nbOfRepeat retransDuration rndAccTimAdvTreshold minTimeHO minTimeHOunsuccess microCellInstabilityTimer microCellStability
1.5 cell diameter or best cell distance coverage server
16 SACCH 2 SACCH 4 SACCH 5 SACCH normal type
5 to 10 dB 20s 70 dB 4 2 1
desactivated
63 dB
Page 83/156
DRAFT DOCUMENT
y Table : btsSiteManager
parameters bscId btsSiteManagerId siteName lapdLinkOMLRef teiBtsSiteManage r ADMSTATE CTRLSTATUS CREASTATE radioSiteMask redundantPcmPre sence_omc maxNbOfCells hardwareRef siteArchitecture_o mc NETWORKTYPE SOINDEX pcmTimeSlotNum ber configRef Recommend ed Value
Page 84/156
DRAFT DOCUMENT
6.2.2.2 Neighbor Cells parameters Table : adjacentCellHandOver
Parameters bscId btsSiteManagerId btsId adjacentCellId MobileNetworkCode MobileCountryCode LocationAreaCode CellIdentity NetworkColourCode BaseColourCode synchronised rxLevAccessMin msTxPwrMax hoMargin cellType MICROCSPARE1 MICROCSPARE2 microCellStability microCellCaptureTimer bCCHFrequency SOINDEX hoMarginRxLev hoMarginRxQual hoMarginDist Recommended Value
-101 to -100 (GSM 900) -99 to -98 (DCS 1800) 33 dBm (GSM 900) 30 dBm (GSM 1800) 4 dB normalType
63 dB 8s
3 to 6 (urban), 1 to 3 rural -4 dB -2 dB
Page 85/156
DRAFT DOCUMENT
Table : adjacentCellReselection
Parameter bscId btsSiteManagerId btsId adjacentCellRId bCCHFrequency SOINDEX recommended Value
Page 86/156
DRAFT DOCUMENT
6.2.2.3 Handover parameters Table : handOverControl
Parameter bscId btsSMId btsId handOCtrlId incomingHOEnabled intraCellEnabled msBDICEnabled powerBICEnabled sDCCHHOEnabled lRxLevDLH lRxLevULH rxLevHreqave rxLevHreqt lRxQualDLH lRxQualULH rxQualHreqave rxQualHreqt rxLevDLIH rxLevULIH averagingNum boundary0 boundary1 boundary2 boundary3 msRangeMax distHreqt missRxLevWt missRxqualWt missDistWt rxNCellHreqave SOIndex intracellSDCCH radChanSelintTreshold Recommended Value
-101 to -100 (GSM 900) -99 to -98 (DCS 1800) -101 to -100 (GSM 900) -99 to -98 (DCS 1800) 4 SACCH (urban) 8 SACCH (rural) 1 1.6 to 3.2 % (=4 RxQual unit) 1.6 to 3.2 % (=4 RxQual unit) 4 SACCH 1 -85 to -84 dBm -85 to -84 dBm 20 SACCH -100 dBm -90 dBm -80 dBm -70 dBm call clearing - 1km 4 90 110 110 4 SACCH (urban) 8 SACCH (rural) false 1
Page 87/156
DRAFT DOCUMENT
6.2.2.4 Power control parameters Table : powerControl

Parameters bscId btsSMId btsId powerCId pwrCtrlEnbl bsTxPwrMax pwrIncSSize pwrRedSSize lRxLevDLP lRxLevULP uRxLevDLP uRxLevULP lRxQualDLP lRxQualULP uRxQualDLP uRxQualULP SOIndex uplinkPowerControl Recommended Value
43 dBm 4 dBm 2 dBm -95 to -94dBm -95 to -94dBm -95 to -94 dBm + Max (pwrIncSSize, pwrRedSSize -95 to -94dBm 1.6 to 3.2 % (=4 RxQual unit) 0.4 to 0.8 % (=2 RxQual unit) 1.6 to 3.2 % (=4 RxQual unit) 0.2 to 0.4 % (=1 RxQual unit)
Page 88/156
DRAFT DOCUMENT
6.2.2.5 TRX parameters For TRX, there are only configuration paarmeters. So that no particular values are recommended. Table : channel
Parameters bscId btsSMId btsId transcvId channelId channelType freqUsage hoppingGroup maio nonHopping SOIndex Recommended Value
Table : transceiver
Parameter bscId btsSMId btsId transcvEId trxNbr lapdLOMLId lapdLRSLId tei hardwareRef admState ctrlStatus createState SOIndex configRef Recommended Value
Table : pcmBtsSiteManager
Parameter bscId btsSMId pcmCId btsPcmNbr Recommended Value
Page 89/156
DRAFT DOCUMENT
posElem
6.3 BSS PARAMETERS CONTROL

6.3.1 NETWORK DEFAULT VALUE CONTROL The network default value for a parameter is the value applied in the main part of the network to this parameter. These values are defined after a complete database analysis. Each network default value has to be compared to the corresponding recommended value (cf RECOMMENDED VALUES). Any difference has to be explained (radio environment, subscribers profile....). Then, for some objects of the database, the network default values can be compared with each item of these objects. Such a process allows to detect any bad setting inside the BDE database. The tool NETCONF is very useful to conduct this process. 6.3.1.1 Cells parameters To analyze the database and determine the network default values, you can use the function Read Cell Parameters from Read BDE in NETCONF (cf [R10]). Enter the determined network default values in Modify Default Cell Parameters from Modify Default Parameters in NETCONF. In Check Cell Parameters from Check BDE in NETCONF, each value of the OMC-R table BTS is compared to the corresponding network default value. NETCONF displays parameters where differences have been detected.
Page 90/156
DRAFT DOCUMENT
Parameter bscId btsSiteManagerId btsId CELLNBR MobileCountryCode MobileNetworkCode locationAreaCode cellIdentity networkColourCode baseColourCode bCCHFrequency cellReselectHysteresis msTxPwrMax rxLevAcessMin radioLinkTimeOut RACHBTHRESH raCHLoadAveragingSlots thresholdCCCHLoadIndication PeriodicCCCHLoadIndicationU PeriodicCCCHLoadIndicationV ADMSTATE ctrlStatus CREASTATE maxNumberRetransmission numberOfSlotsSpreadTrans NY1 noOfBlocksForAcessGrant noOfMultiframesBetweenPaging msTxPwrMaxCCCH cellBarred callReestablishment emergencyCall smsCB dtxMode btsIsHopping iMSIAttachDetach timerPeriodicUpdateMS SDCCHSAPI0 FACCHTCHF FACCHTCHH SACCHTCHSAPI0 SACCHSDCCH SDCCHSPAI3 SACCHTCHSAPI3 t3101 t3103 t3105
Recommended Value
Checked Value
Default Network Value Default Network Value
Default Network Value
4 dB (rural), 6 dB (urban) 33 dBm (GSM 900) 30 dBm (GSM 1800) -101 to -100 (GSM 900) -99 to -98 (GSM 1800) 20 SACCH
Default Network Value Default Network Value Default Network Value Default Network Value
33 dBm (GSM 900) 30 dBm (GSM 1800) not allowed Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value
Page 91/156
DRAFT DOCUMENT
t3107 t3109 t3111 t3113 bsMsmtProcessingMode unknownNCellWarning callClearing Diversity powerControlIndicator t3122 runCallClear runHandOver runPowerControl cellDeletionCount CELLTHRESHOLD cellType cellDtxDownlink allocPriorityThreshold answerPagingPriority assignRequestPriority callReestablishmentPriority emergencyCallPriority interCellHoExtPriority interCellHoIntPriority intraCellHoIntPriority otherServicesPriority allOtherCasesPriority IntraCellQueuing cellName MICROCSPARE1 MICROCSPARE2 SOINDEX cellBarQualify cellReselInd cellReselectOffset penaltyTime temporaryOffset rlf1 rlf2 rlf3 btsThresholdHopReconf btsHopReconfRestart abisSpyFlag radResSupervision delayBetweenretrans nbOfRepeat retransDuration rndAccTimAdvTreshold minTimeHO minTimeHOunsuccess microCellInstabilityTimer microCellStability Default Network Value Default Network Value Default Network Value Default Network Value 1.5 cell diameter or best cell distance coverage server Default Network Value Default Network Value Default Network Value 16 SACCH 2 SACCH 4 SACCH 5 SACCH normal type Default Network Value* Default Network Value* Default Network Value Default Network Value Default Network Value
5 to 10 dB 20s 70 dB 4 2 1 desactivated Default Network Value
Default Network Value Default Network Value 63 dB
Page 92/156
DRAFT DOCUMENT
* RunHandOver is ckecked by Check Handover Parameters from Check BDE in NETCONF. y RunPowerControl is checked by Check PowerControl Parameters from Check BDE in NETCONF. y Each detected difference has to be justified : special configuration, optimization setting on a special area...If it could not be explained, or if the detected different setting is inconsistent, the parameter setting has to be changed. 6.3.1.2 Neighbor Cells parameters To analyze the database and determine the network default values, you can use the function Read Neighbouring Cells Parameters from Read BDE in NETCONF (cf [R10]). Enter the determined network default values in Modify Default Neighbouring Cells Parameters from Modify Default Neighbouring Cells Parameters in NETCONF. In Check Neighbouring Cells Parameters from Check Neighbouring Cells... from Check BDE in NETCONF, each value of the OMC-R table AdjacentCellhandOver is compared to the corresponding network default value. NETCONF displays parameters where differences have been detected.
Parameters Recommended Value Check ed Value
bscId btsSiteManagerId btsId adjacentCellId MobileNetworkCo de MobileCountryCo de LocationAreaCod e CellIdentity NetworkColourCo de BaseColourCode synchronised rxLevAccessMin
-101 to -100 (GSM 900) -99 to -98 (DCS
Defau lt Netwo
Page 93/156
DRAFT DOCUMENT
1800) msTxPwrMax 33 dBm (GSM 900) 30 dBm (GSM 1800) 4 dB rk Value Defau lt Netwo rk Value Defau lt Netwo rk Value Defau lt Netwo rk Value
hoMargin
cellType
normalType
MICROCSPARE1 MICROCSPARE2 microCellStability microCellCapture Timer bCCHFrequency SOINDEX hoMarginRxLev
63 dB 8s
3 to 6 (urban), 1 to 3 rural
hoMarginRxQual
-4 dB
hoMarginDist
-2 dB
Defau lt Netwo rk Value Defau lt Netwo rk Value Defau lt Netwo rk Value
Each detected difference has to be justified : special configuration, optimization setting on a special area...If it could not be explained, or if the detected different setting is inconsistent, the parameter setting has to be changed. 6.3.1.3 Handover parameters To analyze the database and determine the network default values, you can use the function Read Handover Parameters from Read BDE in NETCONF (cf [R10]).
Page 94/156
DRAFT DOCUMENT
Enter the determined network default values in Modify Default Handover Parameters from Modify Default Parameters in NETCONF. In Check Handover Parameters from Check BDE in NETCONF, each value of the OMC-R table BTS is compared to the corresponding network default value. NETCONF displays parameters where differences have been detected.
Parameter bscId btsSMId btsId handOCtrlId incomingHOEnabled intraCellEnabled msBDICEnabled powerBICEnabled sDCCHHOEnabled lRxLevDLH lRxLevULH rxLevHreqave rxLevHreqt lRxQualDLH lRxQualULH rxQualHreqave rxQualHreqt rxLevDLIH rxLevULIH averagingNum boundary0 boundary1 boundary2 boundary3 msRangeMax distHreqt missRxLevWt missRxqualWt missDistWt rxNCellHreqave SOIndex intracellSDCCH radChanSelintTreshold Recommended Value Checked Value
-101 to -100 (GSM 900) -99 to -98 (DCS 1800) -101 to -100 (GSM 900) -99 to -98 (DCS 1800) 4 SACCH (urban) 8 SACCH (rural) 1 1.6 to 3.2 % (=4 RxQual unit) 1.6 to 3.2 % (=4 RxQual unit) 4 SACCH 1 -85 to -84 dBm -85 to -84 dBm 20 SACCH -100 dBm -90 dBm -80 dBm -70 dBm call clearing - 1km 4 90 110 110 4 SACCH (urban) 8 SACCH (rural) false 1
Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value
Page 95/156
DRAFT DOCUMENT
Each detected difference has to be justified : special configuration, optimization setting on a special area...If it could not be explained, or if the detected different setting is inconsistent, the parameter setting has to be changed. 6.3.1.4 Power control parameters To analyze the database and determine the network default values, you can use the function Read Power Control Parameters from Read BDE in NETCONF (cf [R10]). Enter the determined network default values in Modify Default Power Control Parameters from Modify Default Parameters in NETCONF. In Check Power Control Parameters from Check BDE in NETCONF, each value of the OMC-R table BTS is compared to the corresponding network default value. NETCONF displays parameters where differences have been detected.
Parameters bscId btsSMId btsId powerCId pwrCtrlEnbl bsTxPwrMax pwrIncSSize pwrRedSSize lRxLevDLP lRxLevULP uRxLevDLP uRxLevULP lRxQualDLP lRxQualULP uRxQualDLP uRxQualULP SOIndex uplinkPowerControl Recommended Value Checked Value
43 dBm 4 dBm 2 dBm -95 to -94dBm -95 to -94dBm -95 to -94 dBm + Max (pwrIncSSize, pwrRedSSize -95 to -94dBm 1.6 to 3.2 % (=4 RxQual unit) 0.4 to 0.8 % (=2 RxQual unit) 1.6 to 3.2 % (=4 RxQual unit) 0.2 to 0.4 % (=1 RxQual unit)
Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value Default Network Value
Default Network Value
Each detected difference has to be justified : special configuration, optimization setting on a special area...If it could not be explained, or if the detected different setting is inconsistent, the parameter setting has to be changed.
Page 96/156
DRAFT DOCUMENT
Page 97/156
DRAFT DOCUMENT
6.3.2 NETWORK DATABASE CONSISTENCY For the adjacentCellHandOver and adjacentCellReselection objects, their consistency with others objects of the OMC-R must be checked. 6.3.2.1 Handover and reselection of neighbour cells It is interesting to compare adjacentCellHandOver and adjacentCellReselection tables, to detect differences and understand them. Coherence idle and dedicated neighbor lists in Check Neighbouring Cells... from Check BDE in NETCONF, displays all cells where Reselection neighbor cells and Handover neighbor cells are different. 6.3.2.2 Cells and neighbor cells It is necessary to compare adjacentCellHandOver and bts objects, to check that BSIC and BCCH parameters defined in both objects for a same cell are identical. It is necessary to check that cells in the same site are synchronous and cells from different sites are asynchronous. For both controls, Check Neighbouring Cells Coherence in Check Neighbouring Cells... from Check BDE in NETCONF, allows to detect these inconsistencies. 6.3.2.3 Neighbour cells reciprocity It is necessary to check reciprocity for neighbor cell relationship inside adjacentCellHandOver object. You can use List not reciprocal relationships in Check Neighbouring Cells... from Check BDE in NETCONF. All not reciprocal relationships will be displayed. 6.3.2.4 Interferences To detect any interference between TRXs of different neighbor cells in the same site or in different site, it is necessary to compare their frequencies (no hopping case). You can use Check Frequency Planning from Check BDE in NETCONF. In different neighbor cells in the same site, all TRX frequencies differences below or equal to 2 are displayed. In different neighbor cells in different sites, all TRX frequencies differences below or equal to 1 are displayed.
Page 98/156
DRAFT DOCUMENT
6.3.3 BDE - BDA CONSISTENCY The previous described process allows to check OMC-R objects relationship and validity. But it is necessary to check that parameters database at the OMCR and parameters in the equipment are exactly the same. To control it, you can type a command from the OMC-R : PROCESS
CHECK BDE - BDA
Network Default Values Control
Compare Network Values with Network Default Value
Check Database Coherence
Page 99/156
DRAFT DOCUMENT
7. TRAFFIC AND MOBILITY ANALYSIS

7.1 INTRODUCTION
The traffic and mobility analysis has the following objectives: y determine the Subscriber Profile, which represents the average amount of traffic (radio resource occupancy) generated by each subscriber at the busy hour. y determine the Call Profile, which represents the distribution and success ratio of the calls (L-M, M-L,..)
y determine the Mobility Profile, which represents the ratio between the calls
(revenue generating) and the mobility procedures (Handover, Location Update) which are resource consuming, but not revenue generating.
7.2 BSS TRAFFIC AND MOBILITY ON BSS SIDE

7.2.1 INTRODUCTION TO CALL PROFILE A call profile provides information about the traffic distribution of the MSC which is essential for determining the system capacity and the network partitioning. It also provides information about traffic distribution of the BSS and cells, which is essential for determining the BSCs capacity, and the cells capacity (radio channels: SDCCH and TCH). It finally provides information about the mobility on the network, and therefore allows to optimize the partitioning of the network (Location area boundaries, MSCs boundaries,..) FIGURE 3.1 : BDE-BDA CONSISTENCY CHECK MSC 1 MSC 2 MSC Call profile
BSC 1 BSC 3 BSC 4 BSC 5 BSC 6 BSC 7 BSC 8
BSC 2
BSC Call profile
BTS1
BTS2
BTS1
BTS2
BTS1
BTS2
BTS1
BTS2
Cell Call profile Figure 5.1 : Call profiles

Page 100/156
DRAFT DOCUMENT
7.2.2 CALL PROFILE CALCULATION The call profile is always calculated at the busy hour. MSC call profile is calculated based on the OM counters of the target MSC during the busy hour using predefined equations. Tools such as ADEPT-G or CT7200 can be used to generate the call profile given the OM data collected from an MSC (see 8). BSC and Cell call profile are calculated based on OMC-R counters during busy hour using pre-defined equations. The tool used to generate BSC and Cell call profile is CT7200.
7.2.2.1 Cell Call profile

7.2.2.1.1 Detrmining the Busy Hour
The first step when calculating a call profile, is to determine the busy hour at which this call profile will be generated. The busy hour can be determined on a cell basis, BSC basis or network basis. For the cell basis, the only way is to monitor the distribution in time of the counter C1052/0, which measured during the busy hour gives the carried traffic in Erlang for the corresponding cell. The busy for the cell will be: Busy_Hour_Cell = Hour_of_day where C1052/0 = Max (C1052/0) over the day.
Page 101/156
DRAFT DOCUMENT
Example of curve used to determine the busy hour of a cell:
Network cell erlang
1600 1400 1200 1000 Erlang 800 600 400 200 0 00:00-01:00 01:00-02:00 02:00-03:00 03:00-04:00 04:00-05:00 05:00-06:00 06:00-07:00 07:00-08:00 08:00-09:00 09:00-10:00 10:00-11:00 11:00-12:00 12:00-13:00 13:00-14:00 14:00-15:00 15:00-16:00 16:00-17:00 17:00-18:00 18:00-19:00 19:00-20:00 20:00-21:00 21:00-22:00 22:00-23:00 23:00-24:00 Friday 31/01 Saturday 01/02
Figure 5.2 : Busy hour of a cell Comparing the same curve for all the days of the week, allows to determine the BBH: Busiest Busy Hour of the week. 7.2.2.1.2 Structure of the call profile Hereunder is the standard format for cell call profile : Cell call profile
Traffic Busy hour Traffic Carried (Erl) TCH Blocking rate (%) Traffic Offered (Erl) SDCCH carried (Erl) SDCCH Blocking rate (%) TCH allocated : Overflow Total TCH allocations Average duration of TCH (s) Cell Establishment Mobile Originated Call ratio Mobile Terminated Call ratio Location Update ratio Other services ratio Mobility Analysis Intra-BSC HO/Call Inter-BSC HO/Call
Page 102/156
DRAFT DOCUMENT
The cell call profile is used to dimension the radio channels (number of TRX)in the cell, and to optimize the partitioning of the network: y Boundaries of location Areas set with respect to the profile of the cells y MSC load balacing, taking into account the call profile of the cells. The different items that are used are : TRAFFIC Carried traffic (Erl): It is the average traffic (expressed in Erlang) measured over the busy hour on the cell. It represents the average occupancy of TCH channels during busy hour. It is directly measured at the V8 OMC-R by the counter: C1052/0.
Blocking rate TCH(%): It is the average blocking ratio measured in the cell at the busy hour. It represents the ratio of call attempt that could not be serviced by the system due to lack of resources in the cell. It is calculated using the follwing formula: TCH _ Re ssource _ Failure TCH _ blocking _ rate ! TCH _ Re ssource _ Failure Total _ TCH _ allocations TCH_Ressource_Failure : Total number of TCH allocations refused because of lack of resources. It is given directly at the OMC-R by the counter C1039. Total_TCH_allocations : Total number of TCH channels successfully allocated in the cell. It is given directly at the OMC-R by the following counters: C1051/0 + C1051/1 + C1051/2.
Offered traffic (Erl): This is the real demand of traffic in the cell. It is the traffic that would be carried by the cell if the blocking ratio was null. For this calculation we assume that the profile (duration and frequency) of the rejected calls would be the same as the one of carried calls. It is calculated as follows: Carried _ Traffic Offered _ traffic ! 1 TCH _ blocking _ rate
Carried traffic on SDCCH (Erl) It is the average traffic (expressed in Erlang) carried by SDCCH channels. It is directly given at the OMC-R by the counter: ....
Page 103/156
DRAFT DOCUMENT
Blocking rate SDCCH(%): It is the average SDCCH blocking ratio measured in the cell at the busy hour. It represents the ratio of call attempt that could not be serviced by the system due to lack of SDCCH resources in the cell. It is calculated using the follwing formula: SDCCH _ Re ssource _ Failure SDCCH _ blocking _ rate ! SDCCH _ Re ssource _ Failure Total _ SDCCH _ allocations SDCCH_Ressource_Failure : Total number of SDCCH allocations refused because of lack of resources. It is given directly at the V8 OMC-R by the counter C1036. Total_SDCCH_allocations : Total number of SDCCH channels successfully allocated in the cell. It is given directly at the V8 OMC-R by the counter C1034. TCH allocations for overflow This is the total number of TCH channels allocated due to shortage in SDCCH channels. The analysis of this number with respect to the total number of TCH allocations gives an idea of the amount of TCH congestion created by the overflowing mechanism. It is measured at the V8 OMC-R by the counter C1051/1. Average duration of TCH (s): The average duration of TCH is the result of : The average call duration (subscriber dependent), and the ratio of handovers (network engineering dependent). Due to handovers, the average duration of TCH is lower than the average duration of a call. Therefore, this value cannot be used to calculate a subscriber profile (needs the effective average duration of a call). It is given by: Carried _ traffic v 3600 TCH _ average _ duration ! Total _ TCH _ allocations
CALL ESTABLISHMENT Mobile Originated Call (M.O.C.): This is the ratio of Mobile originated calls in the cell. It includes originating Mobile->Land and Mobile->Mobile calls. It is given by the following formula: M . O. C _ ratio ! M . O. C _ number M . O. C _ number M . T . C _ number
Page 104/156
DRAFT DOCUMENT
M.O.C_number: This is the absolute number of Mobile originated calls in the cell. It should be measured at the OMC-R with the counter giving the cause value: Other Calls of the Establish Indication message. In V8 the direct counter giving this information is the C... M.T.C_number: This is the absolute number of Mobile Terminated calls in the cell, i.e. the number of calls in reply to a paging (L->M and M->M). It should be measured at the OMC-R with the counter giving the cause value: Reply to Paging of the Establish Indication message. In V8 this counter is the C... Mobile Terminated Call This is the ratio of Mobile terminted calls in the cell (calls as reply to paging). It includes terminating Land->Mobile and Mobile->Mobile calls. It is given by the following formula: M . T . C _ ratio ! M . T . C _ number M . O. C _ number M . T . C _ number
M.O.C_number: This is the absolute number of Mobile originated calls in the cell. It should be measured at the OMC-R with the counter giving the total number of Establish Indication messages sent with the cause value: Other Calls. In V8 the direct counter giving this information is the C... M.T.C_number: This is the absolute number of Mobile Terminated calls in the cell, i.e. the number of calls in reply to a paging (L->M and M->M). It should be measured at the OMC-R with the counter giving the total number of Esatblish Indication messages sent with the cause value: Reply to Paging. In V8 this counter is the C...
Location Update This is the ratio of Location Update with respect to the total number of Establish Indication sent from the BSS to the NSS. It is given by the folowing formula: LocUp _ number LocUp _ ratio ! M . O. C _ number M . T . C _ number LocUp _ number Other _ service _ number LocUp_number : It is the total number of Location Update attempts made inside the cell during the observation period (busy hour). It is measured at the OMC-R with the counter giving the total number of Establish Indication messages sent by the BSS with the cause value: Location Update. In V8, the relevant counter is: Other services
Page 105/156
DRAFT DOCUMENT
This is the ratio of all other services with respect to the total number of Establish indication sent from the BSS to the NSS. It is given by the following formula:
LocUp _ ratio !
Other _ Services_ number M . O. C _ number M . T . C _ number LocUp _ number Other _ service _ number
Other_Services_number : Total number of links established between BSS and NSS for reasons other than MOC, MTC, LocUp. This includes emergency calls,... It is measured at the OMC-R by the counter giving the total number of of Establish Indication messages sent with the cause value : Emergency calls, ...In V8, the relevant counter is...
MOBILITY The mobility is a resource consuming event at the OMC-R. The mobility analysis is used in order to optimize the partitioning of the network-both BSS and NSS). intra-BSC HO / Call: This is the ratio of intra-BSC handovers with respect to the number of calls processed in the cell. It is given by the following formula: int raBSCHO_ number int raBSCHO / Call _ ratio ! Calls_ assign _ complete _ number intraBSCHO_number : It is the total number of successful incoming intraBSC Handover measured in the cell. At the V8 OMC-R it is measured by the counter C... Calls_Assign_Complete_number : It is the total number of Assign complete (resulting from a call attempt) measured in the cell. It is measured at the V8 OMC-R by the formula : C1050 - C1083.
inter-BSC HO / Call This is the ratio of inter-BSC handovers with respect to the number of calls processed in the cell. It is given by the following formula: int erBSCHO _ number int erBSCHO / Call _ ratio ! Calls_ assign _ complete _ number
Page 106/156
DRAFT DOCUMENT
interBSCHO_number : It is the total number of successful incoming interBSC Handover measured in the cell. At the V8 OMC-R it is measured by the counter C... Calls_Assign_Complete_number : It is the total number of Assign complete (resulting from a call attempt) measured in the cell. It is measured at the V8 OMC-R by the formula : C1050 - C1083. Global HO / Call This is the global ratio of handovers/call. It is given by the formula:
Global _ HO / Call _ ratio ! int erBSCHO _ number int raBSCHO _ number Calls_ assign _ complete _ number
7.2.2.1.3 Typical values for different environments a) Urban environment Cell call profile
b) rural environment
Page 107/156
DRAFT DOCUMENT
Cell call profile
c) indoor cells Cell call profile

Page 108/156
DRAFT DOCUMENT 7.2.2.2

BSC Call profile
7.2.2.2.1 Detemining the busy hour The first step when calculating a call profile, is to determine the busy hour at which this call profile will be generated. The busy hour can be determined on a cell basis, BSC basis or network basis. For the BSC call profile, the busy hour must be the one corresponding to the maximum CPU occupancy of the BSC. Busy_Hour_BSC = Hour_of_day where Avg_CPU_occupancy is at max value.
Avg _ CPU _ occupancy !
Avg[ BIFP1_ CPU _ occupancy ] Avg[ BIFP 2 _ CPU _ occupancy ] 2
Example of curve used to determine the busy hour of a BSC:

Avg CPU occupancy BSC 1
45 40 35 30 25 % 20 15 10 5 0 00:00 - 01:00 01:00 - 02:00 02:00 - 03:00 03:00 - 04:00 04:00 - 05:00 05:00 - 06:00 06:00 - 07:00 07:00 - 08:00 08:00 - 09:00 09:00 - 10:00 10:00 - 11:00 11:00 - 12:00 12:00 - 13:00 13:00 - 14:00 14:00 - 15:00 15:00 - 16:00 16:00 - 17:00 17:00 - 18:00 18:00 - 19:00 19:00 - 20:00 20:00 - 21:00 21:00 - 22:00 22:00 - 23:00 23:00 -24:00
Figure 5.3 : Average CPU BSC occupancy In this case the busy hour for BSC1 is 11:00 - 12:00
Page 109/156
DRAFT DOCUMENT
7.2.2.2.2 Structure of BSC call profile BSC call profile

Traffic Busy hour CIC traffic Carried (Erl) TCH tarffic carried (Erl) Traffic Offered (Erl) Total TCH allocations Average duration of TCH (s) Total CIC allocations Average duration of CIC (s) BSC establishment Mobile Originated Call (%) Mobile Terminated Call (%) Location Update (%) Other services (%) Mobility Analysis Intra-BSC HO/Call Inter-BSC HO/Call Global HO/Call
The BSC call profile is used to dimension the BSCs CPU and SICD capacity, and to optimize the partitioning of the network: Boundaries of location Areas set with respect to the profile of the BSCs MSC load balacing, taking into account the call profile of the cells. The different items that are used are:
TRAFFIC Carried traffic (Erl): It is the sum of the average traffic (expressed in Erlang) carried on TCH channels on all the cells of the BSC. It is measured at V8 OMC-R using the formula: 7C1052/0. Blocking rate TCH(%): It is the average blocking ratio measured on all the cells of the BSC at the busy hour. It represents the ratio of call attempts that could not be serviced by the
Page 110/156
DRAFT DOCUMENT
system due to lack of resources in the cell. It is calculated using the follwing formula: TCH _ Re source _ failure cells TCH _ blocking _ rate ! TCH _ Re source_ failure Total _ TCH _ allocations
cells cells
TCH_Ressource_Failure : Total number of TCH allocations refused because of lack of resources. It is given for each cell directly at the OMC-R by the counter C1039. Total_TCH_allocations : Total number of TCH channels successfully allocated in the cell. It is given directly at the OMC-R by the following counters: C1051/0 + C1051/1 + C1051/2.
Offered traffic (Erl): This is the real demand of traffic on the BSC. It is the traffic that would be carried by the BSC if the blocking ratio was null on all the cells. For this calculation we assume that the profile (duration and frequency) of the rejected calls would be the same as the one of carried calls. It is calculated as follows: Offered _ traffic ! Carried _ Traffic 1 TCH _ blocking _ rate
CIC carried traffic (Erl): It is the average traffic carried on all the CIC (terrestrial circuits) of the BSC. It represents the average occupancy of the CIC during the busy hour. For a V8 OMC-R, it is measured by the counter C... CIC average duration (s): The average duration of CIC is the result of : The average call duration (subscriber dependent), and the ratio of inter-BSC handovers (network engineering dependent). Due to intra-BSC handovers, the average duration of TCH is lower than the average duration of a CIC, which in turn is lower than the average duration of a call because of the inter-BSC handovers.Therefore, this value cannot be used to calculate a subscriber profile (needs the effective average duration of a call). It is given by: CIC _ average _ duration ! CIC _ Carried _ traffic v 3600 Total _ CIC _ allocations
Total_CIC_Alloactions : Total number of CIC allocations during the busy hour at the BSC. It is measured at the V8 OMC-R by the counter C...
Page 111/156
DRAFT DOCUMENT
Carried traffic on SDCCH (Erl): It is the average traffic (expressed in Erlang) carried by SDCCH channels. It is directly given at the OMC-R by the counter: ....
Blocking rate SDCCH(%): It is the average SDCCH blocking ratio measured in all the cells of the BSC at the busy hour. It represents the ratio of call attempts that could not be serviced by the system due to lack of SDCCH resources in the cell. It is calculated using the follwing formula:
SDCCH _ Re source _ Failure SDCCH _ blocking _ rate ! SDCCH _ Re source_ failure Total _ SDCCH _ alloactions
cells cells cells
SDCCH_Ressource_Failure : Total number of SDCCH allocations refused because of lack of resources. It is given directly at the V8 OMC-R by the counter C1036. Total_SDCCH_allocations : Total number of SDCCH channels successfully allocated in the cell. It is given directly at the V8 OMC-R by the counter C1034.
TCH allocations for overflow This is the total number of TCH channels allocated due to shortage in SDCCH channels. The analysis of this number with respect to the total number of TCH allocations gives an idea of the amount of TCH congestion created by the overflowing mechanism. It is measured at the V8 OMC-R using the sum on all the cells of the BSC: 7C1051/1. Average duration of TCH (s): The average duration of TCH is the result of : The average call duration (subscriber dependent), and the ratio of handovers (network engineering dependent). Due to intra-BSC handovers, the average duration of TCH is lower than the average duration of a CIC, which in turn is lower than the average duration of a call because of the inter-BSC handovers.Therefore, this value cannot be used to calculate a subscriber profile (needs the effective average duration of a call). It is given by:
Page 112/156
DRAFT DOCUMENT
TCH _ average _ duration ! Carried _ traffic v 3600 Total _ TCH _ allocations
BSC ESTABLISHMENT Mobile Originated Call (M.O.C.): This is the ratio of Mobile originated calls calculated on all the cells of the BSC. It includes originating Mobile->Land and Mobile->Mobile calls. It is given by the following formula:
M . O. C _ number M . O. C _ ratio ! M . O. C _ number M . T. C _ number

cells cells cells
M.O.C_number: This is the absolute number of Mobile originated calls in the cell. It should be measured at the OMC-R with the counter giving the cause value: Other Calls of the Establish Indication message. In V8 the direct counter giving this information is the C... M.T.C_number: This is the absolute number of Mobile Terminated calls in the cell, i.e. the number of calls in reply to a paging (L->M and M->M). It should be measured at the OMC-R with the counter giving the cause value: Reply to Paging of the Establish Indication message. In V8 this counter is the C... Mobile Terminated Call This is the ratio of Mobile terminted calls (calls as reply to paging) calculateed on all the cells of the BSC. It includes terminating Land->Mobile and Mobile>Mobile calls. It is given by the following formula:
M . T . C _ number M . O. C _ ratio ! M . O. C _ number M . T. C _ number

cells cells cells
M.O.C_number: This is the absolute number of Mobile originated calls in the cell. It should be measured at the OMC-R with the counter giving the total number of Establish Indication messages sent with the cause value: Other Calls. In V8 the direct counter giving this information is the C... M.T.C_number: This is the absolute number of Mobile Terminated calls in the cell, i.e. the number of calls in reply to a paging (L->M and M->M). It should be measured at the OMC-R with the counter giving the total number of Esatblish Indication messages sent with the cause value: Reply to Paging. In V8 this counter is the C...
Page 113/156
DRAFT DOCUMENT
Location Update This is the ratio of Location Update with respect to the total number of Establish Indication sent from the BSC to the NSS. It is given by the folowing formula:
LocUp_ number
LocUp _ ratio !
LocUp_ number M . O. C _ number M . T . C _ number Other _ service_ number

cells
cells
LocUp_number : It is the total number of Location Update attempts made inside each cell of this BSC during the observation period (busy hour). It is measured at the OMC-R with the counter giving the total number of Establish Indication messages sent by the BSC with the cause value: Location Update. In V8, the relevant counter is:
Other services This is the ratio of all other services with respect to the total number of Establish indication sent from the BSS to the NSS. It is given by the following formula:
Other _ services_ number

LocUp _ ratio !
LocUp _ number M . O. C _ number M . T . C _ number Other _ service_ number

cells
cells
Other_Services_number : Total number of links established between the BSC and NSS for reasons other than MOC, MTC, LocUp. This includes emergency calls,... It is measured at the OMC-R by the counter giving the total number of of Establish Indication messages sent with the cause value : Emergency calls, ...In V8, the relevant counter is...
MOBILITY The mobility is a resource consuming event for the system. The mobility analysis is used in order to optimize the partitioning of the network-both BSS and NSS).
Page 114/156
DRAFT DOCUMENT
intra-BSC HO / Call: This is the ratio of intra-BSC handovers with respect to the number of calls processed in the BSC. It is given by the following formula:
inc_ int raBSC _ HO

int raBSCHO / Call _ ratio !
Calls_ assign_ complete_ number

cells
cells
inc_intraBSCHO_number : It is the total number of successful incoming intraBSC Handover measured in each cell of the BSC. At the V8 OMC-R it is measured by the counter C... Calls_Assign_Complete_number : It is the total number of Assign complete (resulting from a call attempt) measured in each cell of the BSC. It is measured at the V8 OMC-R by the formula : C1050 - C1083.
inter-BSC HO / Call This is the ratio of intra-BSC handovers with respect to the number of calls processed in the BSC. It is given by the following formula:
inc_ int erBSC _ HO

int erBSCHO / Call _ ratio !
Calls_ assign_ complete_ number

cells
cells
inc_interBSCHO_number : It is the total number of successful incoming interBSC Handover measured in each cell of the BSC. At the V8 OMC-R it is measured by the counter C... Calls_Assign_Complete_number : It is the total number of Assign complete (resulting from a call attempt) measured in each cell of the BSC. It is measured at the V8 OMC-R by the formula : C1050 - C1083.
Global HO / Call This is the global ratio of handovers/call. It is given by the formula:
inc_ int erBSC _ HO inc_ int raBSC _ HO int erBSCHO / Call _ ratio ! Calls_ assign_ complete_ number
cells cells cells
Page 115/156
DRAFT DOCUMENT
7.2.2.2.3 Typical values for different environments a) Urban environment Urban BSC call profile
b) Rural environment Rural BSC call profile

Page 116/156
DRAFT DOCUMENT
7.3 NSS TRAFIC AND MOBILITY MONITORING

7.3.1 DATA COLLECTION To determine the call profile, OM registers data are necessary. The OMs are organized in groups. Each group contains several registers. Each register count some events (ex: nb of calls) or describe a status updated by some events (ex: nb of subs). OMs are impacted by two important parameters: OM transfer period (OMXFR from OFCENG)= During the transfer period, the metric corresponding to an OM register is measured. OM accumulation period = each OMs registers is the summation of all on an OM transfer period measurements done during the OM accumulation period. It is necessary to have OM transfer period = OM accumulation period = 30mn The OMs have to be collected during all the day. To make the traffic and mobility analysis through adept-G, it is necessary to collect the following OM groups: CP, CP2, EXT, TRMTCM, TRMTER, TRMTFR, TRMTFR2, TRMTFR3, TRMTRS, STORE, BRSTAT, C7SCCP, C7SCCPCO, TCAPUSAG, TCAPERRS, ISUPERRS, MSCCP, MSCCP2, MSCCPSRV, MSCDSRV, GSMLUSAG, GSMLERRS, MSCCFSS, MSCHO, MSCSMS, VLR, VLR3, GMAPCH, GMAPEMGT, GMAPMMGT, GMAPSMGT, GMAPSMS, GMAPSS, GMAPSS2, MSCCP3, VLR2, VLR4, MSCHO2, EXHOCA, GMEANTM, GMEANTM2, GMMLTRN, GTASOM, TRK, SYSPERF. Activity logs (ACT102) must be collected also to determine the busy hour, as they contain the CPU occupancy. Activity logs have to be configured to sample the CPU occupancy at least each 30 mn (the best configuration is each 15 mn).
Page 117/156
DRAFT DOCUMENT
7.3.2 PROCESSING The NSS data must be collected every day during at least 2 weeks. The aim is to determine the busy hour of the busiest day of each week. We need at least two weeks of data to confirm the analyzed weekly trends. Trending analysis A chart of the CPU occupancy has to be drawn to show the halfhourly evolution during each day of a week. It determines the busiest hour of the busiest day. Same trending could be done for BHCA, Location Update and HO, to point on the impact of the busy hour study. Adept-G Once the busy hour is determined a call profile is calculated through Adept-G with the BH corresponding data. Some parameters have to be filled, when the OM are loaded: y OM transfer period : check in OFCENG table, OMXFR, the advised value is 30mn. y Percentage of voice calls: look directly in the OM file at the busy hour to the group GMEANTM, registers HTVCCNT and HTDCCNT. The first one counts the number of voice calls to calculate the voice call mean holding time, the second one counts the number of data calls to calculate the data call mean holding time. The rate HTVCCNT/( HTVCCNT+ HTDCCNT) gives the percentage of voice calls on the MSC. y Authentication frequency: The parameter AUTH_CONTROL_PARM in table OFCVAR shows the number of calls an authentication is done. For example, a 5 means each 5 calls an authentication is done: frequency = 1/5 = 0.2 . y Subscriber detach failure. It concerns the number of subscribers who are not reachable but not properly detached, because of a coverage hole for example. It can not be measured. An advised value is 70%. It is used to determined the causes of some paging time out (repartition detach, time out des unsuccessful). Then a call profile is calculated. It is important to check on two weeks if the results are similar.
Page 118/156
DRAFT DOCUMENT
7.3.3 CALL PROFILE DEFINITION For the NSS, we consider the ADEPT-G call profile as a reference. The MSC call profile specifies per subscribers calls, mobility, supplementary services and short messages services. It specifies per calls the handovers. For calls, is given the percentage composition of each type of calls. There are four major categories of calls: mobile-to-land, land-to-mobile, mobile-to-mobile, and land-to-land. The percentage of calls that belong to each of these categories are given in the call profile. Within each category, the calls are divided into GMSC, VMSC and GVMSC calls. They are further subdivided into successful and unsuccessful calls and various types of call forwarding. GMSC is the MSC which has direct connection to the PSTN. VMSC is the MSC where the mobile is currently visiting. A call from the PSTN are first routed to one of the GMSCs. If the GMSC is different from the visiting MSC of the called mobile, the call is routed to the VMSC. If the called mobile is located at the GMSC, the call is terminated locally and the GMSC is called GVMSC (Gateway and Visiting MSC). More details are also available for y mobility, y handovers, y SMS,
Page 119/156
DRAFT DOCUMENT
7.3.3.1 Key indicators They are some key elements from the call profile: Observed CPU Occupancy' Subscribers Active in the VLR Busy Hour Call Attempts/Sub' Mili-Erlangs per subscriber' Voice Successful Holding Time(sec)
Observed CPU occupancy It gives the time percentage the CPU is occupied to process calls, mobility...It is reported by the activity logs. The measurement period is defined when activity logs are set up. The minimum value is 15 mn. Depending of the type of the MSC, the CPU occupancy engineering limit is fixed between 70% and 80%. The CPU occupancy must never overpass this limit. Subscribers active in the VLR It gives the number of subscribers active in the VLR. It corresponds to the number of active subscribers in the MSC covered area. When a MS arrived on a new VLR area, it is detected through the location update inter-VLR. After a request to the HLR, it is then recorded in the new VLR. It has a status of active subscriber. Each VLR_mobile_audit_period, the VLR determines if the MS could be detached or removed. If the MS has not any activity since attached_mobile_audit period, the mobile is detached. It is not any more an active subscriber. If the MS has not any activity since detached_mobile_audit period, the mobile is removed from the VLR. Busy hour call attempts per subscribers It is the number of all call attempts (L-M, M-M, M-L, L-L voice calls) divided by the total number of active subscribers in the VLR, during the busy hour. It gives a good idea about the subscriber behavior. It is linked to the billing and marketing strategies. It then varies a lot between different networks. Voice successful holding time Average hold time for an answered voice call in seconds. Milli-erlangs per subscribers Erlang demand per subscriber.
Page 120/156
DRAFT DOCUMENT
7.3.3.2 Call profile details Calls It is necessary to define what is a gateway MSC, gateway visitor MSC, visitor MSC calls. A call is considered as successful when the MSC receives a Assign complete message from MS for MS terminating calls in LM and MM calls, and for MS originating calls in ML calls. LL calls are considered as successful. For MS terminated calls, unsuccess causes are mainly : y paging time out, y lack of radio resources on BSS, y lack of CIC resources (A interface).
GMSC
VMSC
PSTN
GMSC
PSTN
VMSC
GVMSC
GVMSC
MS
MS Land to Mobile calls on a 2 MSCs network:
Page 121/156
DRAFT DOCUMENT
GMSC VMSC
VMSC VMSC
MS
MS
VMSC GMSC
Mobile to Mobile calls on a 2 MSCs network The Gateway calls are consuming more resources as a query o the HLR is necessary to route the call. That is why it is important to separate these different kinds of calls. Mobile to Land calls Calls from a mobile to the PSTN Land to Land calls Transit calls through the MSC as the mobile is not present in the MSC. There is no query to the HLR for this kind of calls.
Mobility Intra VLR location updates are counting both periodic location updates and inter LAC location updates. Handover
Page 122/156
DRAFT DOCUMENT
7.3.3.3 Network references To appreciate the call profile it is necessary to compare it with references coming from other networks. The spread of GMSC, VMSC, GVMSC calls is strongly dependent of the number of MSCs in the network. The inter MSC Handover and inter VLR location updates are strongly dependent of the MSC number in the network.
FOR n number of MSCs
Call Profile
BHCA 'Percentage Voice Calls' 'Mobile to Land - Voice' ' Successful Traffic Ratio' ' Answered' ' Not Answered' ' Unsuccessful Traffic Ratio' ' Unreachable' 'Land to Mobile - Voice' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' GMSC Calls' Successful Traffic Ratio' Successful with MSRN' Subscriber Not Active to CFNRC' Call Forward Unconditional Succe Unsuccessful Traffic Ratio' Terminate to VM' Terminate to RANN/Tone' VMSC Calls' Successful Traffic Ratio' Answered' Subscriber No Reply to VM' Call Forward Busy Successful' Call Forward No Reply Successfu Unsucccessful Traffic Ratio' Detached to VM' Page Timeout to VM' Page Timeout, CFNRC Successfu Detached, CFNRC Successful' GVMSC Calls' 0.8 1 0.51 1 0.65 0.35 0 0 0.36
0.05
1 0.87 0.01 0.12 0 0 0
0.05
0.335-0.4
0.4
0.1
0.8 0.8 0.05 0.05 0.1 0.2 0.5 0.05 0.05 0.4 0.85 0.04
0.1
0.335-0.3
0.4
0.85 0.5
0.33-0.3 0.5-0.4
0.2 0.67-0.33
'Mobile to Mobile - Voice' ' GMSC Calls' ' ' ' ' ' ' ' ' ' ' ' Successful Traffic Ratio' Successful with MSRN' Subscriber Not Active to CFNRC' Call Forward Unconditional Succe Unsuccessful Traffic Ratio' Terminate to VM' Terminate to RANN/Tone' GVMSC Calls' Successful Traffic Ratio' Answered' Subscriber No Reply to VM'
0.5
1 0.87 0.01 0.12 0 0 0
0.95
0.75 0.8 0.05 0.05 0.1 0.25 0.5 0.05 0.05 0.4 0.09 0 0
0.95
0.5-0.4 0.33-.0.67
' Call Forward Busy Successful' ' Call Forward No Reply Successfu ' Unsuccessful Traffic Ratio' ' Detached to VM' ' Page Timeout to VM' ' Page Timeout, CFNRC Successfu ' Detached, CFNRC Successful' 'Land to Land - Successful' 'Mobile to VM Retrieval' 'Land to VM Retrieval'
Misc. Profile
'Authentication Frequency' 'EIR Query Frequenc y' 'Send Parameters Frequency' 'Send ID Request' (per active sub) 0.2 0 0.2 0.5
Page 123/156
DRAFT DOCUMENT
Handover Profile - Per Call

'Intra-BSC Handovers' 'Inter-BSC Handovers' Inter-MSC Handovers - Outgoing' 'Inter-MSC Handovers - Incoming' 'Subsequent Handovers - Incoming' 'Subsequent Handovers - Outgoing' 0.8 0.12
0 0
0 0
0 0 0 0
0.03 0.03 0.01 0.01
0.05 0.05 0.01 0.01
Mobility Profile - Per Active Sub

'Intra-VLR Location Update - Periodic 0.8 'Inter-VLR Location Update - Incomin 0.05 'Inter-VLR Location Update - Outgoin 0.002 'Attach Subscriber' 'Detach Subscriber' 'Additional ISD Requests' 0.12 0.1 0.35 0.08 0.03 0.05 0.2 0 0 0 0.003 0.003 0 0 0.003 0 0 37.50% 62.50% 100.00% 0.05 0.002 0.3 0.3 0.6 0.6
SMS Profile - Per Sub

' ' ' ' MT SMS Successful' MT SMS Unsuccessful' MO SMS Successful' MO SMS Unsuccessful'
CISS Profile - Per Active Sub

'SS Activation' 'SS Deactivation' 'SS Registration' 'SS Erase' 'SS Interrogation' 'SS Get Password Attempts' 'SS Structured Data Request' 'SS Process Structured Request' 'SS Structured Request'
7.3.4 TRENDING It is interesting to see the hourly evolution of each kind of processes along the day: call attempts, handovers, SMS and location updates.
Page 124/156
DRAFT DOCUMENT
7.4 NETWORK SUBSCRIBER PROFILE

7.4.1 DEFINITION The susbcriber profile is the key input needed to dimension the capacity of the network (MSC, BSC, cell) using the traffic growth forecast (in number of subscribers). According to the Erlang B law, the subscriber profile (in mErlang) is given by: Pvt A( Erl ) ! 3600 where: l = Busy Hour Call attempt / subscriber t = Effective communication mean time (Conversation + setup on TCH and ringing mean time) Measurement This subscriber profile must be measured at the BBH, and can be expressed by the formula: Sub_Profile = BHCA*Avg_Call_Duration where: BHCA = Busy Hour Call Attempt per subscriber Avg_Call_Duration = Average Call duration per subscriber The subscriber profile is measured on both NSS and BSS. We need to measure on both sides, because neither BSS nor NSS give direct access to the Effective communication mean time. Therefore, the Total BHCA and BHCA/sub will be measured at the NSS side, and the mean traffic (in mEr) per subscriber will be measured at the BSS side At the OMC-R level, we have no direct access to the Call_Duration which is a key parameter for computing the subscriber profile. However, the Call_Duration value can be approached with a good confidence margin by the counter CIC_Avg_Duration (Cxxx) From that we can deduce the Erlang_CIC carried on the network. As far as Radio channels dimensioning is concerned, we can use the following approximation: Sub_Profile (Erl) = CIC_Erlang / Number of subscribers
Page 125/156
DRAFT DOCUMENT
BHCA measurement Total BHCA will be given directly by the following combination of MSC OMs: Total BHCA = MSCCP_MLBID + MSCCP-LMBID + MSCCP_MMBID + MSCCP2_LLSUCC The BHCA/sub, will the be deduced by: BHCA/sub = Total BHCA / Avg. subs in VLR where:
Avg.subs in VLR = (VLR_SUBSREG + VLR_SUBREGR) / (sample duration / OM transfer period)
Page 126/156
DRAFT DOCUMENT
8. CAPACITY ANALYSIS
8.1 FOR ONE MSC
cpocc type of MSCs MSC, MSC/STP MSC/Iden demander df Engineering limits df comparer calculated et measured cpocc Prvision subs
8.2 FOR SEVERAL MSC

Network limit = impact du MSC le plus charg growth planning MSC balancing et nouveau MSC
8.3 BSS CAPACITY ANALYSIS
Justify
Justify
Correct
Justify
Correct
Page 127/156 Correct
DRAFT DOCUMENT
9. LINK BUDGET MONITORING

9.1 DEFINITION
The aim of Path Balance verification, is to compare the path balance measured on field to the link budget design, in order to validate the RF design, and detect hardware or installation problems at the BTS. Path balance verification can be used as a procedure for measuring the quality of site installation.
9.2 INPUTS
Inputs are the necessary information and documents provided by other Nortel entities or by the operator (for non turnkey projects), concerning: RF design Link budget sheet. If not available, at least the following items (as computed in the link budget sheet): y MS & BTS sensitivity. y Total Uplink, Total Downlink & Worst link budget. y Diversity Gain y Network Information y GSM features activated: Power Control,VAD-DTX, .. y Main cell parameters. y Site acceptance y Site commissioning report
Page 128/156
DRAFT DOCUMENT
9.3 DATA COLLECTION

Data are collected at the Abis interface, (with the SPY mode activated if measurements done with a protocol analyzer) and preferably the Power Control disabled for the cell concerned with the measurements. The data to collect are the Measurements Results (MR) which gather the downlink and uplink measurements. The quantity to measure is RxLev DL RxLev UL. Data collection can be done by means of either a Protocol analyzer (e.g. MA10 from W&G), or Call Monitoring (V7)/ Call Tracing (V8) functions provided by the Nortel system. 9.3.1 Protocol Analyzer The MA10 should be connected to the distribution frame, in order not to disturb the service. Launch the Capture application MA_10 Control with the following options: y Filter the L2 and Paging messages y Be sure to record Measurements Results (MR)
B T S
Uplink & ownlink D me asu re me nt
B S C A b is Analyse r rrrr
MS
PC
Vehi ul c e
P ost P roce ssin g nn nn nn nn nn nn n
Page 129/156
DRAFT DOCUMENT
Figure 4.1 : Protocol Analyzer 9.3.2 Call Tracing (V8) Call Monitoring in V7 or Call Tracing in V8 is a function implemented at the BSC level, enabling to collect all measurement results (MR) and layer 3 protocol messages for a single communication. The advantage compared to the protocol analyzer is the possibility to link both UL and DL measurements to localisation system data. The main steps of the data collection are the following: y Declare the IMSI of the test mobile at the MSC in the GSMTRACE table. y Specify a reference record for your IMSI in the table. y At the OMC-R, launch the Call monitoring on the BSCs involved in the drive test y Drive to the starting point, and start recording with the localisation system just when you start the call. y Stop recording localisation system after the end of test calls. y Call monitoring should be stopped at last. 9.3.3 Call Path Tracing V8 Call path trace functionnality, provided by Nortel system (available only from V8), allows to trace all the calls sharing the same media at the BSS (TRX, cell, CIC, ..). It is a powerful mean to measure the path balance on a given cell by tracing all the calls in progress inside that cell. The output of Call Path trace includes all Abis L3 mesages, and all measurements results. Main steps of data collection are the following : y Create the Path trace object at the BSC y Specify the entity to be traced 9.3.4 Measurements constraint Herebelow is a typical Rayleigh envelop , with , in dashed line, a potential diversity path. The y axis is in dB, the x axis is in meter( or wavelenght), where
Page 130/156
DRAFT DOCUMENT
the scale is given by the distance between two minima, which is about
01
P/
Figure 4.2 : Rayleighs Fading Rayleighs fading being a spatial phenomenon, it is mandatory for the mobiles measuring (RxLev DL - RxLev UL) to be in motion in order to average this fading. Even a speed of 5 km/h allows to approach the mean value of the signal with a standard deviation less than 2.5 dB. If the mobiles generating the measurements are motionless (keep the same spatial position), all the measurements will be spoilt by the same error (ex. of the mobile located in a fading hole). Due to the dynamic environment of the BTS and the MS, the result will be a gaussian distribution centered on a wrong value. In this case, measurements with 2 motionless mobiles would give a distribution with two peaks, each one corresponding to the fading at the position of the mobile. In order to improve the reliability of the measurements, it is recommended to use 2 moving MS (if protocol analyzer or call trace/call monitoring is used), and to collect at least 5000 samples (20 mn communication for each MS). 9.3.5 Power Control Impact Since the Power Control alters path balance analysis, it should be disabled on the concerned cell before starting the measurements. - Downlink Power Control disabling :
5 0 50151025203-
Page 131/156
DRAFT DOCUMENT
V7 release: Set at the OMC the parameter PowerControl to disabled for the measured cell. V8 release: Set at the OMC the parameter bsPowerControl to disabled for the measured cell - Uplink Power Control disabling : V7 release: Set the parameters uRxLevULP, uRxQualULP, lRxLevULP & lRxQualULP for the measured cell so as to disable the power control. V8 release: Set the parameter uplinkPowerControl to disabled for the measured cell. All these modifications are done on-line (class 3 parameters) and do not require the BTS to be put out of service. However, if for some reason it is impossible to disable the power control, then its impact will be compensated by the post-processing application according to the following principle : For each measurement result, if the output power is decreased by X dB, the compensated value of RxLev will be computed: RxLev := RxLev + X. Despite this compensation process available in the post-processing software, it is recommended to disable the power control at the OMC-R, since this approach guarantees a higher reliability of the results.
Page 132/156
DRAFT DOCUMENT 9.4 POST-PROCESSING & ANALYSIS

9.4.1 Post-processing 9.4.1.1 Protocol Analyzer The post-processing procedure is the following: y Post-process the MA_10 output file TEST.sig with the software ABIS. y Import the resulting file TEST.xls into Mapinfo. y Open the file TEST.tab in Mapinfo. y Launch the menu Abis Statistics. For more details on post-processing, refer to document [A1]. One of the outputs under Mapinfo will be the distribution function of the quantity RxLev DL - RxLev UL. ex:
Figure 4.3 : RxLev link budget distribution 9.4.1.2 Call Trace/Call Path Trace y Repatriate Call Trace / Call path trace data to the OMC-R server. y Launch the post-processing with Call Perf tool (ref.[R11]) y Example of Call perf output under Excel (RxQual Distribution v.s. RxLev) :
Page 133/156
DRAFT DOCUMENT
Quality distribution profile.
Figure 4.4 : RxQual distribution Another output under of Call Perf : Distribution of <RxLev DL - RxLev UL>:
RF Path Balance WAN030 Sector 1

1000 500 0 1 2 3 4 5 6 7 8 9 0 -2 -1 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1.00 0.50 0.00
Figure 4.5 : RF Path Balance
9.4.2 Analysis 9.4.2.1 Prediction equation The first step is to determine the median of this gaussian distribution. The next and very important step is to determine, derived from the theoretical link budget calculation, the mean value of RxLev DL - RxLev UL that should be obtained on field. The analysis of the difference between this predicted mean value and the measured mean value allows to depict design problems or BTS faults. Hereafter is the formula to predict the mean value of RxLev DL - RxLev UL . RxLev_DL - RxLev_UL =
Page 134/156
DRAFT DOCUMENT
(Sensitivity_MS - Sensitivity_BTS) + Diff_Gain + LB_PWR_Excess mw_to_dB (1) with: Sensitivity_BTS : Value of the BTS sensitivity (defined in [R3]) given in the theoretical link budget calculation. It is very important to take the value considered in the theoretical calculations, because this value is often different from the default values, and contains corrective factors taking into account: Sensitivity improvement due to DLNA, margins to guarantee better RxQual on the cell edge. Sensitivity_MS : Value of the MS sensitivity (defined in [R3]) considered in the theoretical link budget. As for the BTS we should take the value given in the theoretical calculations. Diff_Gain : Difference between the real gain provided by the diversity, and the value of this gain considered in the link budget calculations. In an urban environment we will have: Gain in the theoretical link budget (NMC calculations): 3-4 dB for the BTS 1G, 5 dB for the BTS 2G. Real gain on field: 5-6 dB so : Diff_Gain = 0 to 3 dB depending on each case. LB_PWR_Excess :+ DL_PWR_Excess if uplink limited - UL_PWR_Excess if downlink limited 0 if balance on cell edge. mW_to_dB : The averaging at the BTS done in mW, introduces an artificial gain of up to 2.5 dB for uplink measurements. Therefore we will compensate this effect by introducing the parameter mW_to_dB = 1.5 dB. 9.4.2.2 Important remarks 1) These values are spoilt by measurement errors in the MS and the BTS. Commonly, the tolerance admitted between measured budget and calculated budget is around +/- 3 dB. 2) 2) When a DLNA is used, it should be integrated in the calculations both sensitivity improvement and power gain. If the sensitivity improvement hasnt been taken into account in the theoretical calculation, then the sensitivity should be re-calculated. The new value will then be used in the formula (1). However, with the S8000 product, the sensitivity gain provided by the DLNA is practically null due to the very low noise factor of the BTS receiver. (3 dB).
Page 135/156
DRAFT DOCUMENT
In case there are no particular problems in the design or in the BTS, the distribution should be centered on the value predicted by (1). However, as mentioned before, a deviation of up to +/- 3 dB will be tolerated 9.4.2.3 Example using a standard link budget sheet Herebelow is a standard link budget sheet, used for an indoor-designed network
Exampl
CONTRACT: SHAANXI e ENVIRONMENT: DENSE URBAN SITE TYPE: S4000 IN/OUTDOOR DPX INDOOR
Ref:
LINK BUDGET CALCULATION

TX PA OUTPUT POWER: "" COMBINER SPECIFIC LOSSES: TX CABLE RX LOSSES: ANTENNA GAIN SENSITIVITY: (ISO.): COMMON CABLE BODY LOSSES: LOSSES: RX DIVERSITY OVERLAPPING GAIN: IN CAR PENETRATION MARGIN: INDOOR FACTOR:PENETRATION OPERATING FACTOR: EQUIVALENT FREQUENCY: TOTAL UPLINK E.I.R.P: TOTAL DOWNLINK BUDGET: WORST LINK BUDGET: OUTDOOR BUDGET: MINIMUM BTS 20.00 W ############ 43.0 dBm 3.3 dB 0.0 dB -107.0 dBm 18.0 dBi 3.7 dB None 4.0 dB 0.0 dB 0.0 dB 18.0 dB 900 MHz 54.0 dBm 135.3 dB 133.0 dB 133.0 dB -79.0 dBm MS 2.00 W 33.0 dBm None None -102.0 dBm -2.0 dBi 0.0 dB 3.0 dB
(57.3 dBV/m)
For this example: y Sensitivity_MS = -102 dBm y Sensitivity_BTS = -107 dBm y LB_PWR_Excess = -2.7 dBm y mw_to_dB = 1.5 dBm The predicted median of the RxLev DL - RxLev UL distribution would be: <RxLev DL - RxLev UL> = 5 - 2.7 -1.5 = 0.8 dB. 9.4.2.4 Impact of coupling system The coupling system has a direct impact on the path balance, since it concerns only the downlink direction. Coupling systems with higher losses will affect the
Page 136/156
DRAFT DOCUMENT
downlink signal strength, thus shifting the median of the <RxLevDL - RxLev UL> distribution to the left. For example, an H2D hybrid combiner introduces 3 dB loss, while an H4D introduces 7 dB loss. Therefore : y H2D: <RxLev DL - RxLev UL> = xx dB y H4D: <RxLev DL - RxLev UL> = xx - 4 dB
9.4.3 Application to check the BTS In case of a hardware failure (losses in a RxSplitter or a hybrid combiner,..), or an installation problem (losses in connectors, V.S.W.R.,..) the link budget will be highly unbalanced. In practice, as soon as the deviation between the measured median of (RxLev DL - RxLev UL) and the value predicted by (1) exceeds 5 dB, the result is considered bad, and the site has to be checked. Depending on the sign of the deviation (+ or -), the transmission modules or reception modules would have to be checked. Basically a potential problem is either located on the uplink or on the downlink. It is possible that when fixing a problem on the uplink (resp. downlink), we discover a new problem on the downlink (resp. uplink) that was hidden before. note: In the following diagram when it is written " X module is faulty" we have to understand that either the module or one of the cables and connectors going to or from the module is faulty. This will be checked replacing one by one these cables.
Page 137/156
DRAFT DOCUMENT
9.4.4 DIAGRAM FOR UPLINK PROBLEM
u p l i n k p r ob l e m s u s p ec t ed
t e s t wi t h m a i n a n t e n n a d i s c on n ec t ed on RX
t e s t wi t h d i ve r s i t y a n t e n n a d i s c on n ec t ed on RX
com p a r e t h e 3 t e s t s
main li n k i s faul t y t e s t d i ver s i t y a n t e n n a on m a i n s p l i t t e r on l y
d i ve r s i t y l i n k i s fa u l t y
r esu l t i s b ad test antenna main+ diplexer + main splitter on rx div
r e s u l t i s ok
d i p l ex e r or t h e ca b l e f au l t y
r esu l t i s b ad m ai n s p l i t t er i s
r e s u l t i s ok RX i s f au l t y
Figure 4.6- : Uplink problem (1)
Page 138/156
DRAFT DOCUMENT
A
diversity link is faulty
test diversity antenna on main splitter only
test with main antenna on div splitter only
compare the 3 tests
diversity receive is faulty test antenna div + main splitter on rx div diversity feeder + antenna is faulty
result is bad
result is ok RX is faulty
diversity splitter is faulty
Figure 4.7 : Uplink problem (2)
Page 139/156
DRAFT DOCUMENT
9.4.5 DIAGRAM FOR DOWNLINK PROBLEM
d own l i n k p r ob l em s u s p e ct e d
s wa p t h e a n t e n n a e
c om p a r e t h e 2 t e s t s
s wa p p e d a n t e n n a i s good ( e x c e p t d i v ef f ec t ) check again bulk head output power ( m a i n an t en n a + f e ed e r ) f au l t y
test diplexer by passed and div antenna connected only
r es ul t is bad TX is faulty
r e s u l t i s ok Di p l ex er i s f au l t y
Figure 4.8 : Downlink problem 9.4.6 Uplink limited or downlink limited ? 9.4.6.1 Design considerations Case Uplink limited : If in the link budget calculations, Total Downlink Link Budget > Total Uplink Link Budget, it is the case "Uplink limited", thus the design has two possibilities: a) Take: Worst Link Budget = Total Uplink Link Budget to determine the cell range. Then it will be an excess power in the downlink which value is:
Page 140/156
DRAFT DOCUMENT
DL_PWR_Excess = Total Downlink Budget - Total Uplink Budget. b) Reduce BTS TX Power until: Total Uplink Link Budget = Total Downlink Link Budget= Worst Link Budget. Then use this common value to determine the cell range. In this case there is no power excess. Case downlink limited: If in the Link budget calculations, Total Uplink Budget > Total Downlink budget, we are "Downlink limited", In this case there is only one possibility: a) Take: Worst Link Budget = Total Downlink Link Budget to determine the cell range. We will then have an excess power in the uplink, which value is: UL_PWR_Excess = Total Uplink Link Budget - Total Downlink Link Budget. 9.4.6.2 Field verification The Path balance measurements can be used to determine whether it is uplink limited or downlink limited. This analysis aims at validating the design, and is used as a starting point to counterbalance the link budget limitation (if any) by increasing the TX power, or by adding a DLNA. The principle is to assume that the theoretical difference between the sensitivity of the MS and the sensitivity of the BTS can be assimilated to a measured performance RxQual vs RxLev (see graph below). This is only achievable in a non interfered environment.
In practice, as RxQual and RxLev are measured, the real diversity gain is included in the relative difference (Sensitivity_MS - Sensitivity_BTS), and there is no more measuremet bias (mw_to dB) because the artificial gain on the RxLev UL measurement is counterbalanced by the measurement Sensitivity_BTS. Thus the equation defined in Analysis becomes: RxLev_DL - RxLev_UL = Sensitivity_MS - Sensitivity_BTS + LB_PWR_Excess The aim is now to determine the LB_PWR_Excess as experienced on field. RxLev_DL - RxLev_UL will be measured as described in Data Collection and Post-Processing & Analysis. The Sensitivity_MS - Sensitivity_BTS will be measured as described in Analysis, however we will restrain the procedure to the RxQual only. Thus the steps of this analysis would be: y From the .xls array produced by the software ABIS, extract the measurement results satisfying: RxQual = 4 or (RxQual = 5 & 6), and RxLev >= -90 dBm. The choice of the RxQual value depends on the objectives of the design.
Page 141/156
DRAFT DOCUMENT
y Import the resulting .xls file into Mapinfo. Launch the Abis Statistics application under Mapinfo. y Consider the graph representing the cdf of both RxLev DL and RxLev UL. The difference at 50% between the two curves would give the difference of sensitivities. Example 1: (using Abis protocoal Analyzer + ABIS/Mapinfo tool)
Figure 4.9 : Link Budget In this example, Sensitivity_MS - Sensitivity_BTS = -102 - (-105) = 3 dB. Finally: LB_PWR_Excess Sensitivity_BTS) = RxLev_DL RxLev_UL (Sensitivity_MS -
If LB_PWR_Excess = 0, there are no limitations, the Link Budget is balanced. If LB_PWR_Excess > 0, LB_PWR_Excess uplink limited. If LB_PWR_Excess < 0, -(LB_PWR_Excess) downlink limited. In the example above, if the mean value of measured (RxLev_DL - RxLev_UL) = 10 dB then:
Page 142/156
DRAFT DOCUMENT
Figure 4.10 : Link Budget Distribution LB_PWR_EXcess = 10 - 3 = 7. It is the case 7 dB uplink limited. If it is observed that UL performances need to be improved, a DLNA may be added in order to balance the link budget. If RxLev_DL - RxLev_UL = 2 dB, then: LB_PWR__Excess = 2 - 3 = -1. It is the case 1 dB downlink limited. The TX power at the BTS may be increased (if possible) by 1 dB. ATT: In Practice, the BTS TX Power can be modified only by 2 dB steps. Example 2 (using Call Path trace + Call Perf tool):
RF Path Balance WAN030 Sector 1

1000 500 0 1 2 3 4 5 6 7 8 9 0 -2 -1 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1.00 0.50 0.00
UL RXQUAL WAN061 Sector 1

100% 50% 0 2 4 6 8 0% 10 12 14 16 18 20 22 24 26 28 30 32
Page 143/156
DRAFT DOCUMENT
DL RXQUAL WAN061 Sector 1

100% 50% 0 2 4 6 8 0% 10 12 14 16 18 20 22 24 26 28 30 32
Figure 4.11 : RF Path Balance In this example: <RxLev DL - RXLev UL> = 7 dB (measured value) Sensitivity_MS - Sensitivity BTS = 11 - 7 = 4 dB and therefore : LB_PWR_Excess Sensitivity_BTS) = <RxLev DL RxLev UL> (Sensitivty_MS -
= 7 - 4 = 3 dB.
The cell is 3 dB uplink limited.
Page 144/156
DRAFT DOCUMENT
10. APPENDICES
10.1 APPENDIX A : FORMULA USED IN CT7200
Call assignment failure (TCH) Call assignment failure rate Call attempts C1049 - C1050 - (C1082 - C1083)
C1049 - C1050 - C1082 + C1083 C1195 + C1196
C1191/ 4 + C1191 / 5 + C1191/ 6 + C1191 / 7 SDCCH blocking rate C1164/x -C1164/20

call drop tch comm. C1049 - C1050 + C1083 + Est fail C1195 C1196
Successfull call attempts + C1073 + C1074 - C1068 - C1067 - Call drop
Call drop Call drop ratio Call establishment failure ratio Call releases Calls rejected for CPU overload Connection failure rate Double allocation Establishment failure Establishment indication Global blocking rate Global QOS
C1185/0..3 1 - ((1 - Global blocking rate) * (1 - Call assign fail rate)) C1034 + C1051/2 - (C1195 + C1196) C1163/x - (C1163/5 + C1163/6 + C1163/20) C1195 + C1196 1 - ((1 - SDCCH blocking rate) * (1 - TCH blocking rate)) 100 - ( 50*call drop ratio + 10*call establishment ratio + 10*TCH blocking rate + 10*SDCCH blocking rate + 10* Incoming intra BSS HO execution failure ratio + 10 *Incoming inter BSS HO execution failure ratio )
C1070-C1074+C1069-C1073+C1076-C1068+C1075-C1067
Handover failure (TCH) Handover request Handover request Capture Handover request Capture Handover request Distance Handover request Distance ratio Handover request Downlink IntraCell Handover request Downlink IntraCell ratio Handover request Downlink Level
C1138/0..9 C1138/6
C1138 / 6 C1138 / 0..9
C1138/4
C1138 / 4 C1138 / 0..9
C1138/9
C1138 / 9 C1138 / 0..9
C1138/1
Page 145/156
DRAFT DOCUMENT
Handover request Downlink Level ratio Handover request Downlink Quality Handover request Downlink Quality ratio Handover request Power Budget Handover request Power Budget ratio Handover request Software Blocking Handover request Software Blocking ratio Handover request Uplink IntraCell Handover request Uplink IntraCell ratio Handover request Uplink Level Handover request Uplink Level ratio Handover request Uplink Quality Handover request Uplink Quality ratio Immediate assignment failure ratio
IMSI
C1138 / 1 C1138 / 0..9
C1138/3
C1138 / 3 C1138 / 0..9
C1138/5
C1138 / 5 C1138 / 0..9
C1138/7
C1138 / 7 C1138 / 0..9
C1138/8
C1138 / 8 C1138 / 0..9
C1138/0
C1138 / 0 C1138 / 0..9
C1138/2
C1138 / 2 C1138 / 0..9
detach
C1193/3 C1072 C1074 C1070 C1072 - C1074

1 C1074 C1072
Incoming inter BSS handover command Incoming inter BSS handover complete Incoming inter BSS handover request Incoming inter BSS HO execution failure Incoming inter BSS HO execution failure ratio Incoming inter BSS HO selection failure Incoming inter BSS HO selection failure ratio Incoming intra BSS handover command Incoming intra BSS handover complete Incoming intra BSS handover request Incoming intra BSS handover request Incoming intra BSS handover return
C1070 - C1072
1 C1072 C1070
C1071 C1073 C1069 C1069 C1137
Page 146/156
DRAFT DOCUMENT
Incoming intra BSS HO execution failure Incoming intra BSS HO execution failure ratio Incoming intra BSS HO selection failure Incoming intra BSS HO selection failure ratio Inter BSS handover complete (TCH) Inter BSS handover failure C1071 - C1073
1 C1073 C1071
C1069 - C1071
1 C1071 C1069
C1068 + C1074 1 (C1174 + C1068) (C1072 + C1066)
Intra BSS handover complete (TCH) Intra BSS handover failure
C1067 + C1073
1 (C1172 + C1067) (C1071 + C1065)
IntraCell handover complete (TCH) IntraCell handover failed ratio

LAPD
C1083
1 C1083 C1082
level 1 errors
C1084 / 0..4
C1033 C1193/1 C1066 C1068 C1076 C1136
1 (C1068 + C1136) C1066
Level of RACH non decoded Location Update Outgoing inter BSS handover command Outgoing inter BSS handover complete Outgoing inter BSS handover request Outgoing inter BSS handover return Outgoing inter BSS HO drop ratio Outgoing inter BSS HO execution failure Outgoing inter BSS HO execution failure ratio Outgoing inter BSS HO selection failure Outgoing inter BSS HO selection failure ratio Outgoing intra BSS handover command Outgoing intra BSS handover complete Outgoing intra BSS handover request Outgoing intra BSS handover return
C1066 - C1068
1 C1068 C1066
C1076 - C1066
1 C1066 C1076
C1065 C1067 C1075 C1135
Page 147/156
DRAFT DOCUMENT
Outgoing intra BSS HO drop ratio Outgoing intra BSS HO execution failure Outgoing intra BSS HO execution failure ratio Outgoing intra BSS HO selection failure Outgoing intra BSS HO selection failure ratio Paging Paging Abis
PCM
1
(C1067 + C1135) C1065
C1065 - C1067
1 C1067 C1065
C1075 - C1065
1 C1065 C1075
C1028 + C1029 + C1030 + C1031 C1028 + C1029 + C1030 + C1031 C8700 (cumulated) C1026 C1027
1 C1195 + C1196 C1027
unavailability access (decoded) sent to BSC without establishment indication
RACH RACH RACH
Resource load
SCCP
Traffic carried Traffic offered C1106 C1104 + C1106
failure ratio available (Avg) available (Max)
SDCCCH SDCCCH SDCCH SDCCH SDCCH
C1059/0 (Avg) C1059/0 (Max) C1036 C1034

C1036 C1036 + C1034 + C1051/ 2 C1036 C1036 + C1034 + C1051/ 2 sdcch alloc fail C1036 = sdcch alloc fail + sdcch alloc C1036 + C1034 C1035 * 3600 C1034
alloc failure allocation allocation failure ratio blocking rate congestion holding time radio link failure sig carried
SDCCH
SDCCH
SDCCH
SDCCH SDCCH
C1163/14 C1044 (Avg) C1193/6 C1193 / 0.2.4.5.7 C1050 - C1083 + C1051/ 2 * C11095 C1196 ((2 * C1049) + (3 * (C1083 + C1073 + C1074))) / 3600
Short Message Service (SMS) Successfull call attempts
SUP
connection
Page 148/156
DRAFT DOCUMENT
TCH TCH TCH TCH
alloc failure allocation allocation average allocation failure ratio available (Avg) available (Max) blocking rate communication (BSC level) communication (Cell level) communication (Network level) congestion holding time
C1039 C1051/0 + C1051/1 + C1051/2 C1052/0

C1039 C1039 + C1051/ 0 + C1051/ 2
TCH TCH TCH
C1056 (Avg) C1056 (Max)

C1039 C1039 + C1051/ 0 + C1051/ 2
TCH TCH TCH TCH
C1050 - C1083 + C1074 C1050 - C1083 + C1074 + C1073 C1050 - C1083

tch alloc fail C1039 = tch alloc fail + tch alloc C1051/ 0..2 + C1039 C1052 / 0 (Avg) * 3600 successfull call attempts C1051 / 2 C1034 + C1036 + C1051 / 2
TCH
TCH
overflow rate radio link failure radio link failure ratio
TCH TCH
C1164/14
tch rl fail C1164 / 14 = tch alloc C1051/ 0..2
Traffic carried Traffic offered
tch allocation average = C1052/0 ErlangB( C1056 (Avg) , threshold)
Page 149/156
DRAFT DOCUMENT 10.2 ANNEX B. DETECT AND CORRECT INTERFERENCES

10.2.1 UPLINK INTERFERENCES Uplink interference is created by mobiles, and is therefore linked to the volume of the traffic on the network. The more is the traffic, the more uplink interference will be experienced. This can be a good mean to differentiate internal from external interference. Identification process should be:
Avg Level Of Non decoded RACH & Ratio of HO on RxQual UL vary significantly between low traffic period and high traffic period?
yes No
Internal interference
Uplink External interference
Uplink
An interesting confirmation of uplink interference, can be done using the temporary counters on the Interference level on Idle channels . The principle behind this measure is the following:
When a TimeSlot is idle (i.e. no call is proceeding on it), the Signal level measured by the BTS on that timeSlot, should ideally be -110 dBm. However, a certain level will be measured due to frequency reuse, radio environment and TDMA partitioning. This signal level measured in idle mode, represents the level of interference experienced on the timeslot. Thre level is measured every 480 ms (1 SACCH block).
Page 150/156
DRAFT DOCUMENT
External Uplink interference can be confirmed by this measurement.
-100 dBm -95 dBm -85 dBm
Interf. Level on idle TS
Normal
Possible cause: Most likely y Uplink Interference cause: y External jamming y External jamming Confirm by comparing the y H/W failure value of this counter during low traffic period and high traffic period.
H/W problems: (VSWR, Receiver, RxSplitter)
10.2.2 DOWNLINK INTERFERENCES

1st step: Cell range verification
This is the very first step you have to go through whenever bad quality is experienced on a network. The aim is to verify that there is no resurgency, strong canyoning effects or shadowing. These phenomena would modify the best server partition requested by the design team, and would therefore alter the C/I ratio. During this phase, the main modifications that can be applied are: y Cross feeder correction y Antenna bearing and down-tilt modification y Handover improvement by tuning some parameters. The test will be performed using a test mobile (R&S, TEMS,...), and assessing the geographical coverage of each cell either by using a paper map + markers, or with the GPS coupled to radio measurements. 2nd step: Adjacent channel scanning During this step, you try to see if the bad quality is the consequence of adjacent channel interference. A scanning has to be performed in the area where bad quality has been experienced. If the measured C/Ia in that area exceeds -9 dB, then according to the frequency, the interferer site can de identified. To confirm the finding, this interfering site may be shut down (when possible) and the test performed again. If the problem disappears, then
we have three possible solutions:
Page 151/156
DRAFT DOCUMENT
y Down tilt (if we have enough overlapping margin) the interfering site to reduce the interference. y Reduce the power (if not degrading much the path balance) of the interfering site. y Modify the frequency of the interferer. Any one of these solutions requires a second test to confirm that the problem is solved, and that no degradation has been introduced elsewhere on the network. The equivalent co-channel interfering energy in the useful band will be: RxLev (Adjacent interferer) - 18 dB.
3rd step: Co-channel interference verification If the interference is not due to adjacent channel, then co-channel interference has to be checked. The proper way to do it, is to determine on the frequency planning map the suspect interferer site, and then to shut it down (when possible). If new measurements show that the interference has disappeared, then the frequency of the interferer must be changed. Otherwise, if no suspect site can be found on the frequency planning map, then the serving cell has to be shut down, and a measurement of its frequency done. If the RxLev is significant, then the interference may come either from other site, or from an external jammer. When it is impossible to shut down the sites, then the co-channel interference will be tackled by other means, such as counters observation (C5000, geographical analysis, neighbouring analysis,..) If the level is very low, then all hypothesis of interference have to be discarded, and investigation should be turned toward intermodulation.
Page 152/156
DRAFT DOCUMENT
ANNEX C Counters list
It is mainly the list of BSS counters provided by BSCs and BTSs of the network, through the OMC-R and permanent, daily or hourly observations.
For V8 system versions, the list of the mainly used counters for QOS monitoring is : CCCH observation y C1026 y C1027 y C1028 y C1029 y C1030 y C1031 y C1033 number of RACHs received from MS and decoded number of RACHs transmitted to the BSC number of paging requests which have a time slot immediately number of paging requests which have a time slot after waiting once number of paging requests which have a time slot after waiting twice number of paging requests which have a time slot after waiting more average level of non decoded RACHs
Radio resources allocation y C1034 y C1035 y C1036 y C1059 y C1039 y C1051/0 y C1051/1 y (reestablishment) y C1051/2 y overflowing y C1052/0 y C1056 average number of TCHs allocated in the cell average number of available TCHs in the cell number of full rate TCH allocations for a SDCCH on total number of SDCCHs allocated in the cell average number of SDCCHs allocated in the cell number of allocation failures due to a lack of SDCCHs in the cell average number of available SDCCHs in the cell number of allocation failures due to a lack of TCHs in the cell number of full rate TCH allocations in the cell number of full rate TCH allocations in the cell
Channel mode observation y C1044 average signaling link phase duration
Page 153/156
DRAFT DOCUMENT
Dedicated channel assignment observation y C1049 y C1050 No of assignment command messages sent from cell to mobile No of assignment complete messages received from mobile to cell
Handover observation y C1065 y C1066 y C1067 y C1068 y C1069 y C1070 y C1071 y C1072 y C1073 y C1074 y C1075 y C1076 y C1082 y C1083 y C1135 y C1136 y C1137 y C1138/0 y C1138/1 y C1138/2 y C1138/3 y C1138/4 y C1138/5 y C1138/6 y C1138/7 y C1138/8 y C1138/9 hoExecutionOutgoingIntraBss hoExecutionOutgoingInterBss hoSuccessOutgoingIntraBss hoSuccessOutgoingInterBss hoRequestIncomingIntraBss hoRequestIncomingInterBss hoExecutionIncomingIntraBss hoExecutionIncomingInterBss hoSuccessIncomingIntraBss hoSuccessIncomingInterBss hoRequestOutgoingIntraBss hoRequestOutgoingInterBss hoExecutionIntraBts hoSuccessIntraBts hoUnsuccessReestOutgoingIntraBssTch hoUnsuccessReestOutgoingInterBssTch hoUnsuccessReestIncomingInterBssTch hoRequiredTchUplinkStrength hoRequiredTchDownlinkStrength hoRequiredTchUplinkQuality hoRequiredTchDownlinkQuality hoRequiredTchDistance hoRequiredTchPowerBudgetQuality hoRequiredTchCapture hoRequiredTchTrxOmHs hoRequiredTchIntraBtsUplink hoRequiredTchIntraBtsDownlink
Page 154/156
DRAFT DOCUMENT
Abis interface observation y C1084/x No of level1 errors
A interface observation y C1104 y C1106 total number of SCCP connections total number of SCCP connection refusals
Release of communication observation y C1163 0/./30 y C1164 0/./31 number of releases while the communication is in "signaling" phase number of releases while the communication is in "traffic" phase
BSC observation y C1185/0 y C1185/1 y C1185/2 y C1185/3 No of rejected calls for overload (MOC) No of rejected calls for overload (MTC) No of rejected calls for overload (incoming external ho) No of rejected calls for overload (location update)
Establishment observation y C1191/4 y C1191/5 y C1191/6 y C1191/7 y C1193/0 y C1193/1 y C1193/2 y C1193/4 No of receipts of channel request answering to paging No of receipts of channel requests for emergency call No of receipts of channel requests for call reestablishment No of receipts of channel requests for MOC, SMS, SS for MS phase 1 ;MOC for MS phase2 No of receipts of an establishment indication in call establishment received in a paging response No of receipts of an establishment indication in call No of receipts of an establishment indication in call establishment received in a cm reestablishment request No of receipts of an establish indication in call establishment received of a CM service request for MOC
establishment received in a location updating request
Page 155/156
DRAFT DOCUMENT
y C1193/5 y C1193/6 y C1193/7 No of receipts of an establishment indication in call establishment received in a CM service request for emergency call No of receipts of an establishment indication in call establishment received in a CM service request for SMS No of receipts of an establishment indication in call establishment received of a CM service request for SS y C1195 No of receipts of an establishment indication in call establishment for mobile phase 1 y C1196 No of receipts of an establishment indication in call establishment for mobile phase 2 y C8700 milliseconds
11. END OF DOCUMENT
Page 156/156

Network Performance Monitoring Guide Book V02.03

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Network Performance Monitoring Guide Book V02.03

Uploaded by

Copyright:

Available Formats

GSM

Network Performance Monitoring Guide Book

NMO Team A.M Le Berre P. Braut

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

Monitoring Guide Book

NETWORK PERFORMANCE MONITORING GUIDE BOOK

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

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

2.2 REFERENCE DOCUMENTS

Network Performance Monitoring Guide Book

3. ABBREVIATIONS & DEFINITIONS

Network Performance Monitoring Guide Book

4. NETWORK PERFORMANCE MONITORING

Network Performance Monitoring Guide Book

PERFORMANCE MONITORING OVERVIEW

Network Performance Monitoring Guide Book

2.1 Performance monitoring & Trouble shooting

2.1.4 Capacity analysis 2.1.7 Jammers tracking

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Figure 2 : QOS Monitoring Global Process

Data Retrieving Definition

Network Performance Monitoring Guide Book

5.2 MONITORING OBSERVATIONS

Network Performance Monitoring Guide Book

5.2.2 NSS OBSERVATIONS : OM (OPERATIONAL MEASUREMENTS)

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Figure 3 Network Optimisation Platform

Access Data Base Processing

Network Performance Monitoring Guide Book

5.2.3 BSS OBSERVATIONS : BSS COUNTERS

Network Performance Monitoring Guide Book

DRAFT DOCUMENT 5.3 METRICS DEFINITION

QUALITY OF SERVICE Indicator

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Figure 2.6 : Evolution charts of QOS and metrics

Network Performance Monitoring Guide Book

Example : TOP 30 Drop Call

Call drop ratio (Cell level)

700 600 500 400 300 200 100 0

Network Performance Monitoring Guide Book

DRAFT DOCUMENT 5.5 PROCESS

Figure 4 : QOS Monitoring Process

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book

Network Performance Monitoring Guide Book Page 31/156

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

Intra BSC outgoing handover drop

Inter BSC outgoing handover drop

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

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

C1036 C1036 C1034 C1051_ 2

C1039 C1039 (C1049 C1082)