Verifying Network Performance and KPIs

NTC TAN 84262/1 en
1
Copyright Nokia Telecommunications Oy Document number/Issue
NOKIA NMS/2000
FOR MANAGING CELLULAR NETWORKS
VERIFYING NETWORK PERFORMANCE AND KPIS
TAN 84262/1 en
NTC TAN 84262/1 en
2
Document number/Issue Copyright Nokia Telecommunications Oy
The information in this document is subject to change without notice and describes only the product dened
i n t he i nt roduct i on of t hi s document at i on. Thi s document i s i nt ended for t he use of Noki a
Telecommunications' customers only for the purposes of the agreement under which the document is
submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written
permission of Nokia Telecommunications. The document has been prepared to be used by professional and
properly trained personnel, and the customer assumes full responsibility when using it. Nokia
Telecommunications welcomes customer comments as part of the process of continuous development and
improvement of the documentation.
The information or statements given in this document concerning the suitability, capacity, or performance of
the mentioned hardware or software products cannot be considered binding but shall be defined in the
agreement made bet ween Noki a Tel ecommuni cat i ons and t he cust omer. However, Noki a
Telecommunications has made all reasonable efforts to ensure that the instructions contained in the
document are adequate and free of material errors and omissions. Nokia Telecommunications will, if
necessary, explain issues which may not be covered by the document.
Nokia Telecommunications' liability for any errors in the document is limited to the documentary correction of
errors. Nokia Telecommunications WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS
DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY
LOSSES), that might arise from the use of this document or the information in it.
This document and the product it describes are considered protected by copyright according to the
applicable laws.
NOKIA logo is a registered trademark of Nokia Corporation.
Other product names mentioned in this document may be trademarks of their respective companies, and
they are mentioned for identication purposes only.
Copyright Nokia Telecommunications Oy 1999. All rights reserved.
No. of Edited by Author Approved by Previous issue
pages (-) approved
T Heikkinen M Ganszauge P Pielismaa
52/THe 12 Oct 1999 12 Oct 1999 12 Oct 1999
Copyright Nokia Telecommunications Oy 1999. All rights reserved.
NTC TAN 84262/1 en
3
TABLE OF CONTENTS
1 ABOUT THIS DOCUMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 About network performance monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 What you need to know first . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Where to find more . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 How to use this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 CREATING AND ANALYSING QUALITY OF SERVICE REPORTS
10
2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Minimum software requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Recommended software requirements . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Other requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Procedure for creating reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Creating BSS quality of service reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Quality of Service indicators for BSS . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Quality of the radio network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4 Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Creating NSS quality of service reports. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Quality of Service indicators for NSS . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Quality of Service reports for NSS . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Analysing Quality of Service Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Trend Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2 Identifying the performance problems. . . . . . . . . . . . . . . . . . . . . 19
2.5.2.1 Cell level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2.2 MSC/VLR, HLR, BSC and SMSC . . . . . . . . . . . . . . . . 20
2.5.3 Monitoring speech channel capacity . . . . . . . . . . . . . . . . . . . . . . 21
2.5.4 Monitoring signalling link capacity. . . . . . . . . . . . . . . . . . . . . . . 21
2.5.5 Capacity in general. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.6 Priority categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 INTERPRETING MSC CLEAR CODES . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Clear codes related to voice calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Radio I/F failure / 0B13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Radio I/F msg failure / 0B1B. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Radio I/F congestion / 0205. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 Circuit congestion / 080F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5 Outgoing circuit congestion / 0804 . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.6 Overload congestion / 060B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.7 Remote equipment failure / 0B16 . . . . . . . . . . . . . . . . . . . . . . . . 26
NTC TAN 84262/1 en
4
3.2.8 Handover failure / 0B14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.9 No Paging Response / 0012H . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Clear codes related to DATA calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Modem error / 70B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 V.110 frame synchronous fails / B10. . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Modem communication error / B11. . . . . . . . . . . . . . . . . . . . . . . 28
4 VERIFYING BTS PERFORMANCE. . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Flowchart of the procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Identifying the BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Verifying that the required performance measurements are running. . . . . 31
4.5 Setting up a new Maintenance Region for specific BTSs . . . . . . . . . . . . . 32
4.6 Setting thresholds for BTSs performance . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Configuring Alarm Monitor for specific BTSs . . . . . . . . . . . . . . . . . . . . . 34
4.8 Configure Alarm Monitor for other related alarms . . . . . . . . . . . . . . . . . . 34
4.9 Setting up a TRX loop test for BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.10 Setting thresholds for TRX Loop Test results . . . . . . . . . . . . . . . . . . . . . . 36
4.11 Creating a report on BTS Bit Error Ratio . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.12 Using Network Doctor for monitoring BTSs. . . . . . . . . . . . . . . . . . . . . . . 38
5 MONITORING CELL INTERFERENCE. . . . . . . . . . . . . . . . . . . . . . 41
5.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Flowchart of the procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Running consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4 Activating the Resource Availability measurement. . . . . . . . . . . . . . . . . . 43
5.5 Setting configurable thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6 Configuring Alarm Monitor for monitoring interference . . . . . . . . . . . . . 45
5.7 Checking that sufficient PM data is available . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Generating reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.9 Activating Radio Resource Online Monitoring . . . . . . . . . . . . . . . . . . . . . 47
5.10 Activating Initial Tracing and Trace Viewer . . . . . . . . . . . . . . . . . . . . . . . 47
5.11 Using Network Doctor reports for analysing interference. . . . . . . . . . . . . 48
6 VERIFYING TRANSMISSION NETWORK PERFORMANCE. . . 49
6.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Activating transmission measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3 Creating a transmission report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4 Monitoring radio links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4.1 Setting Thresholds for DMR equipment . . . . . . . . . . . . . . . . . . . 50
NTC TAN 84262/1 en
5
6.4.2 Creating reports for DMR equipment . . . . . . . . . . . . . . . . . . . . . 51
NTC TAN 84262/1 en
6
Summary of changes
This document is new for Nokia NMS/2000 release T11. In future releases, the
changes made to this document will be listed here.
For more information on software and hardware changes between releases,
please see
Software Development between Releases T10 and T11, and
Hardware Development between Releases T10 and T11.
About this document
NTC TAN 84262/1 en
7
1 ABOUT THIS DOCUMENT
This document gives you an NMS system-level view with example procedures
of how to monitor and check the performance of a GSM network. The
information in this manual relates to the following software releases:
Nokia NMS T11
Nokia BSC S7 and S8
Nokia MSC M8
We recommend that you do not use this manual with any other Nokia software
releases.
1.1 About network performance monitoring
Maintaining a GSM network often translates to continuous enhancement of a
networks operational efficiency. Improvements in operational efficiency can be
achieved through monitoring network faults and performance, taking
appropriate action, and reporting the status of the network to other units within
the operator organisation. Reporting plays a key role in ensuring adequate
feedback to business, service and network management, all of which, in turn,
provide input for the development and maintenance of the network.
This document:
Provides you with examples of how to verify the performance of the
network.
Describes how to analyse the results that you obtain.
Gives suggestions on a few example procedures that can be developed
further and tailored to suit your specific needs for network monitoring and
performance reporting.
1.2 What you need to know first
This document assumes that you are familiar with:
Nokia GSM networks
Nokia NMS
Nokia DX200 technology
1.3 Where to find more
For more information, please refer to the following documents:
About this document
NTC TAN 84262/1 en
8
For more information on Nokias performance management tools and the
concepts associated with managing performance data, please see
Performance Management Basic Operating Principles and Procedures.
For information on how to locate and troubleshoot faults in a GSM
network with the help of Nokia NMS, refer to Locating Network Faults.
For more information on using Nokias BSS Network Doctor and the
reports available in the application, refer to BSS Network Doctor Users
Guide, TAN 0935.
For more information on using Nokias NSS Network Doctor and the
reports available in the application, refer to NSS Network Doctor Users
Guide, TAN 1550.
For information on the architecture of the Nokia NMS database for BSS
measurements, refer to Database Description for BSC Measurements.
For information on the architecture of the Nokia NMS database for NSS
measurements, refer to Database Description for MSC/HLR
Measurements
For information on using Nokia Network Data Warehouse for long-term
performance reporting, see Nokia Network Data Warehouse Users Guide,
TAN 0644.
For information on using Nokia Traffica for real-time monitoring of
network performance, see Nokia Traffica Basic Operating Principles and
Procedures, TAN 1453.
1.4 How to use this document
How this document is organised
The subsequent chapters describe what is needed for the operator to be able to
verify that a GSM network performs as it is expected. The chapters give you
information on what kinds of reports are needed to verify that the set Quality of
Service targets are met and suggest procedures that could be used for verifying
the level of network performance.
Creating and analysing Quality of Service reports gives you our
suggestion of the most important Key Performance Indicators (KPI) for
both BSS and NSS. It also outlines the reports that you can generate with
the NMS tools to analyse the performance of the network.
Interpreting MSC clear codes lists the most interesting MSC Clear codes
that can be used in the analysis of your networks performance. The list of
MSC clear codes is by no means comprehensive but it contains the most
common clear codes that can be used as indicators of capacity and
coverage problems, for example.
About this document
NTC TAN 84262/1 en
9
Verifying BTS performance gives you an example procedure on how to
monitor specific BTS sites. You should note that the procedure is an
illustrative example of a monitoring procedure that usually has to be
tailored according to restrictions set by each individual network.
Monitoring cell interference gives you an example procedure on how to
monitor cell interferences. You should note that the procedure is an
illustrative example of a monitoring procedure that usually has to be
tailored according to restrictions set by each individual network.
Verifying transmission network performance gives you an example
procedure on how to monitor the performance of transmission equipment.
You should note that the procedure is an illustrative example of a
monitoring procedure that usually has to be tailored according to
restrictions set by each individual network
Creating and analysing quality of service reports
NTC TAN 84262/1 en
10
2 CREATING AND ANALYSING QUALITY OF
SERVICE REPORTS
The quality of service (QoS) comprises one of the most important aspects that
should be monitored in the GSM network. The QoS goals have to be
communicated throughout the organisation to guarantee that everyone has a clear
understanding of the objectives and strategy for achieving the desired QoS level.
The factors and criteria comprising the QoS of a network are many and varied.
The criteria for the QoS do not remain constant throughout the life cycle of the
network because the network itself evolves with time. New networks have less
tight QoS criteria whereas a mature network has to have stricter criteria to be able
to meet the challenges other operators network pose to it. Below is an example
of typical QoS indicators and their criteria for a mature network:
Example 1.
Dependability Network availability > 97%
Capability Blocked call ratio < 5% during peak hours
Serveability Dropped call rate < 3%
Customer
satisfaction Customer complaints < 1/1000 subscribers a day
Billing complaints Compensation due to fault < 1/1000 customers a year
It is generally accepted that the QoS of the network should be better or equal to
that of the competitors.
2.1 Prerequisites
This section lists the minimum requirements that enable you to complete report
creation successfully. Read this chapter carefully to avoid unnecessary
troubleshooting later.
2.1.1 Minimum software requirements
Measurement Data Postprocessing in UNIX (PM Data Reporter) or PC:
used for viewing PM data
Administration of BSS Measurements: used for starting the required BSS
measurements
Alarm Statistics in PC: used for finding out the most frequent alarms and
the sites generating the most alarms
NTC TAN 84262/1 en
11
BSS and NSS Network Doctor: used for generating periodic textual reports
2.1.2 Recommended software requirements
Nokia Network Data Warehouse: used for storing long-term PM, FMand
RNW data
Note:
Nokia Network Data Warehouse is a separate product that contains long-
term data for following trends and creating forecasts. However, for report
generation it uses Measurement Postprocessing in PC and AlarmStatistics
in PC.
2.1.3 Other requirements
There must be enough statistical fault and performance data available in the
NMS database.
2.2 Procedure for creating reports
Quality of service reports are typically created on a daily or weekly basis,
including availability reports, trafficability reports, traffic reports in relation to
the service met to name but a few. When enough consistent statistical data is
available, you may run the reports and analyse the results, and then take any
necessary actions based on the results. After this, you should verify the impact
of actions by a new run of reports and carry out a new analysis. The cycle of
running reports, analysing them and modifying the network on the basis of the
actions, continues through the whole lifespan of the network. Only the set of key
performance indicators (KPI) and their target values are modified from time to
time.
The procedure for creating quality of service and other reports is fairly similar in
all cases. Depending on the type of the report you may have to define logical
counters or move from the PLMN level to more detailed reports to get a better
view of the networks performance. The flowchart below outlines the creation
procedure.
NTC TAN 84262/1 en
12
NTC TAN 84262/1 en
13
Figure 1. Creating quality of service reports
To create quality of service reports
1. Verify that the required measurement is active. If the measurement is not
active, it has to be started.
If you need to activate a BSS measurement, start Administration of BSS
Measurements.
If you need to activate an NSS measurement, please refer to NSS Statistics,
CAG 62260 in the MSC document library for instructions.
Depending on the measurement type, there can be a delay of 1 to 24 hours
before any meaningful results can be obtained from the data produced by
the measurement.
2. Start the reporting application. We recommend that you use Measurement
Data Postprocessing in PC or PM Data Reporter.
3. Generate the report. You can
use ready-made report definitions, or
edit existing or create new report definitions.
You can save your own report definitions as a new template for later use.
4. Analyse the report. If necessary, generate more detailed or other related
reports to obtain more information.
For more information on the default reports, please refer to Measurement Data
Postprocessing in PC Report Descriptions, TAN 85121.
2.3 Creating BSS quality of service reports
There are several factors that affect the overall perception of service quality:
RNW parameter settings
Traffic capacity
Network element availability and faults
The quality of service reports can be divided into PLMN and area level reports,
BTS level reports across the PLMN and detailed reports on a specific BTS.
PLMN and area level reports
To ascertain trends in the network you have to examine the performance
indicators across the network and areas. The reports on this level should combine
all KPIs into one report that gives you an overview of an area or the whole
network.
NTC TAN 84262/1 en
14
BTS level across the PLMN or area
To pinpoint problems in BTSs you have to study the performance indicators on
the BTS level across the network or area. These reports typically comprise Top
10 or 15 BTS exceeding the defined quality of service thresholds. The reports
bring the most problematic sites into focus when locating faults and provide a
basis for further analysis.
Note:
When creating top 10 or 15 reports, you can filter out BTSs with only limited
traffic, number of handover attempts, or whatever the report relates to. For
example, if you generate a report showing the worst BTSs in terms of TCH drop
rate, you can exclude BTSs having e.g. less than 50 seizure attempts.
Detailed reports on BTSs
From the Top 10 or 15 lists it is easy to identify the most problematic sites and
further examination can be then carried out by creating detailed reports on
specific BTSs. The reports run on specific BTSs show the behaviour of the cells
in relation to time and different performance indicators.
2.3.1 Quality of Service indicators for BSS
The quality of service can be best assessed by looking at the most important
KPIs. If even one of the KPIs does not meet the target value, the overall QoS
cannot be met.
KPIs are different in each network and they, as well as their target values, must
be modified during the life cycle of the network. The list below shows some of
the central KPIs that can be used to evaluate the QoS level of the BSS:
TCH Availability
SDCCH Success Ratio
Call Setup Success Rate
Call Success Ratio
SDCCH Blocking
TCH Call Blocking
TCH HO Blocking
AGCH Blocking
TCH Drop Ratio
Cumulative UL Quality
NTC TAN 84262/1 en
15
Cumulative DL Quality
Average Interference Band
BSC Controlled Outgoing HO Success
MSC Controlled Outgoing HO Success
Intra-cell HO Success
SMS Success Rate
The following sections look at the different components of the GSMnetwork and
give suggestions what KPIs could be used to evaluate their quality.
2.3.2 Quality of the radio network
The quality of the radio network indicates the networks ability to meet the set
coverage and capacity targets during normal loading. The quality of the radio
network can be assessed by examining the following quality of service KPIs:
Handover failure rate
Dropped call ratio (SDCCH and TCH)
RX quality
MS and BTS power levels
The following list suggests the types of reports available on the NMS that can be
used to study the performance indicators described above.
Call success ratio
HO failure%/BSC
SDCCH drop/BSC
TCH drop/BSC
Average UL signal quality
Average DL signal quality
For more information on the reports above and example reports, please refer to
Performance Management: Basic Operating Principles and Procedures and BSS
Network Doctor Users Guide, TAN 0935.
2.3.3 Capacity
Cell dimensioning is one of the aspects that affect the quality of service in a cell
through capacity and capability. In the most severe cases the user may not be able
to access the network at all because of low SDCCH and TCH availability.
NTC TAN 84262/1 en
16
Problems that indicate insufficient capacity and network element functionality
are:
High dropped call rate
Poor call setup success rate
High handover failure rate
Number of alarms
The capacity and capability of a cell can be studied by running reports on the
following KPIs:
SDDCH congestion and blocking
TCH congestion and blocking
AGCH blocking
Paging channel loading
RACH loading
Top 15 alarming sites
Performance Management: Basic Operating Principles and Procedures and BSS
Network Doctor Users Guide, TAN 0935
2.3.4 Transmission
The quality of transmission can be assessed on the basis of alarms from the
transmission system and the bit-error ratio (BER), which indicates the actual
performance of the transmission system. Typical alarms indicating that there is
something wrong with the transmission system are:
LAPD link failure, (alarm number 7707)
BCCH missing (alarm number 2567)
To find out the occurrence of these alarms, you can run an alarm breakdown
report with Alarm Statistics or Network Doctor.
2.4 Creating NSS quality of service reports
NSS QoS reports should be produced on a daily or weekly basis. The reports
should include reports on the signalling network, network element availability
and trafficability.
NTC TAN 84262/1 en
17
2.4.1 Quality of Service indicators for NSS
The quality of service can be best assessed by looking at the most important
KPIs. If even one of the KPIs does not meet the target value, the overall QoS
cannot the be met.
KPIs are different in each network and they, as well as their target values, must
be modified during the life cycle of the network. The following list shows some
of the KPIs that can be used to evaluate the NSS Quality of Service:
Intra and Inter-MSC HO Success Ratio
Paging Success Ratio
MSC CGR Availability and Blocking
PSTN CGR Availability and Blocking
A-Interface CGR Availability and Blocking
VMS CGR Availability and Blocking
Paging Time
Originating Call Success Ratio
Note:
In order to measure the average paging time in an MSC, the MSC Cell
Measurement must be running. As the MSC Cell measurement is very heavy,
however, it should never be run on all BTSs under the MSC, but only on a very
limited number of BTSs.
2.4.2 Quality of Service reports for NSS
The quality of service provided by NSS network elements can be measured
according to their availability, which is mostly affected by faults and user
actions. The signalling network, transmission network and synchronisation
network are also important and they have an effect on the overall Quality of
Service of the NSS. The following list shows some of the NSS reports that can
be used to assess the Quality of Service of the NSS:
Traffic load of the MSC
Traffic in CGs
Most frequent alarms
Traffic - MOC/MTC
Call Success in CG
NTC TAN 84262/1 en
18
Call Success MOC/MTC
MSC clear codes
MSC Benchmark
CG Statistics
Performance Management: Basic Operating Principles and Procedures and
NSS Network Doctor Users Guide, TAN 1550.
2.5 Analysing Quality of Service Reports
All reports need to be analysed regularly and in the case of rapid changes in the
NW the reason needs to be found. This is especially important at PLMN,
Maintenance Region and MSC level. At the cell level, problematic cells are
investigated daily and in greater detail. In the case of sudden changes it is
important to know what has happened; was it because of planned work, external
interference or HWfault. The first step is to analyse if the problem was caused
by:
fault in any GSM NE
fault in transmission
planned work procedure
blocking
misuse
parameter error
lack of coverage
interference
If the problem was not due to planned work already known to affect service,
more investigations are needed. When the reason for the problem has been
located, corrective actions must be started as soon as possible.
2.5.1 Trend Analysis
The decision-making processes at any level of a telecommunication organisation
can be divided into three distinct categories: those of every day operations that
guarantee quality for end-users, those that govern technical developments to
cope with capacity and coverage demands and those for long-term forecasting
for future network growth. The trend analysis basically covers the second and the
third categories.
NTC TAN 84262/1 en
19
In a larger context, the trend analysis of the network has been divided into three
groups which are: 1) the trend followed by the network in terms of network
growth, 2) QoS indicators and 3) other indicators which are defined by the
Operator to make visible the usage patterns, network profiles, network
bottlenecks etc. This enables the forecasting of a trend based on time-based
history information.
For a performance trend analysis, it is important that a history database of all the
events is kept over a sufficient period of time. This database is the basis for all
trend analysis statistics.
2.5.2 Identifying the performance problems
Normally performance related problems can be found by checking the alarms,
traffic statistics and customer complaint reports. When a problem has been
discovered, a more detailed traffic statistics analysis will be carried out and
detailed information collected from the network for further analysis. Sometimes
the reason cannot be found fromthe statistics and then more information must be
collected e.g. with drive tests or by monitoring signalling between different
network elements.
2.5.2.1 Cell level
When poorly performing cells have been located, the alarmhistory of the site and
BSC must be checked. If there are no service affecting alarms, a more detailed
statistics analysis is needed.
Some examples of what to check for common problems:
SYMPTOM ITEMS TO CHECK
High Drop Call Rate Main reasons for drops (e.g. RF, Abis, TC)
Main causes for outgoing HO
Interference at TRX level
UL/DL quality at TRX level
UL/DL Rx levels at TRX level
TA statistics
UL/DL balance
HO failures
High SDCCH/TCH
Blocking
Average availability of SDCCH/TCH TSLs
Any faulty TRXs
Are both SDCCH and TCH congested
The LU/Call set-up ratio
NTC TAN 84262/1 en
20
Table 1. Common cell performance problems and items to check
2.5.2.2 MSC/VLR, HLR, BSC and SMSC
In cases of PLMN, Maintenance Region, MSC or BSC level problems, the
following things can be checked:
Alarm history of a particular Network Element.
Adjacent cells belong to other LAs
The cell re-select hysteresis value
Transmission problems
BTS TX power
Bad UL/DL Quality UL/DL quality at TRX level
Interference internal or external
Interference during the whole day or just during
a specific time of the day/week
BTS alarms
UL interference
Neighbour definitions (coverage area)
No call bids, only HOs If cell is barred
Not Allowed Access Classes
SDCCH status
HO failures/no HOs Are all neighbours realistic
UL interference
UL/DL quality per TRX
PLMN permitted and NCC parameters
Adjacent list parameters (mainly target cell
information)
HO parameters
UL/DL link balance
HO reasons
Incoming or outgoing HOs failed or both
TA statistics
BTS alarms
Site information in MSC
SYMPTOM ITEMS TO CHECK
NTC TAN 84262/1 en
21
Have there been any Change Deliveries installed in any of the NEs
Have there been any SW upgrades in any of the NEs
Have there been any transmission modifications or failures
Have there been any (major) parameter changes
Have PSTN or any other operators made any major changes in their NW
Are there any alarms in the NEs which could cause these problems.
2.5.3 Monitoring speech channel capacity
The dimensioning of the traffic network is calculated according to the estimated
busy hour traffic. As a rule of thumb, 2%blocking is allowed in the Air-interface
and 0.1% on the trunk lines.
It is important to regularly monitor the capacity and load of all interfaces during
the busy hour so that too high blocking levels can be avoided by installing more
capacity beforehand.
Well before traffic network resources reach the congestion level, it can be
estimated how long it takes to reach that level.
In practice this means a capability to predict traffic growth (TCH, A-if, PSTN)
over a period of six months.
2.5.4 Monitoring signalling link capacity
In general, signalling blocking cannot be allowed except in the SDCCHchannel.
The dimensioning of the signalling network is calculated according to the
estimated busy hour traffic. As a rule of thumb, 0.2%blocking is allowed on the
Air-interface SDCCH channel.
The SDCCH channel should not have much blocking because this channel is
used also for other purposes than call set-up. These are activation/deactivation of
supplementary services, short messages, location updates and also Directed
Retry.
It is important to regularly monitor the capacity and load of all interfaces during
the busy hour so that too high blocking levels can by avoided by installing more
capacity beforehand.
The table below contains the most important signalling links with the maximum
busy hour load allowed. When the traffic is approaching this value, more
signalling links must be created.
NTC TAN 84262/1 en
22
Table 2. Maximum busy hour load allowed on signalling links
2.5.5 Capacity in general
It is important to follow and estimate the needed capacity in different network
elements. Normally it takes a minimum of six months from the moment a
decision about capacity increase is made to the moment the capacity is ready for
use. Figure 2 shows an example of different subscriber growth scenarios with
planned capacity expansions. Similar pictures and scenarios can be made for
other NEs as well.
Figure 2. Network growth scenario
2.5.6 Priority categories
Network Elements, BTS sites and BSCs should be divided into different priority
categories to guarantee that the problems are solved in the right order. Some sites
are more important than others because of high traffic and revenue, or because
they are serving VIPs, hospitals, fire brigades, major business customers, holiday
resorts, airports, etc.
For the same reason, the equipment inside the NSS should be divided into
different priority categories. Possible internal elements are equipment for
synchronisation, modem/fax pools and echo cancellers affecting the service met
by end-users and equipment for statistics and billing affecting the operators
business. The problems should be categorised according to their severity.
Link Traffic
[Erlang]
A-if signalling links 0.2
PSTN signalling links 0.2
MSC-MSC signalling links 0.2
HLR signalling links 0.2
Interpreting MSC clear codes
NTC TAN 84262/1 en
23
3 INTERPRETING MSC CLEAR CODES
This section introduces some of the most important MSC clear codes that can be
used as indicators of network performance. You should be aware that the list of
clear codes is by no means comprehensive. The clear codes listed here are typical
and suggestive of the problems described in the clear code description below.
3.1 Prerequisites
used for viewing PM data
Administration of BSS Measurements: used for starting required
measurement
Network Doctor: used for locating and analysing faults
NMS database.
3.2 Clear codes related to voice calls
3.2.1 Radio I/F failure / 0B13
Practical meaning
This clear code usually indicates a coverage problem.
If your network is growing fast, it is better to wait for some time and see howthis
value behaves as time passes. Because this cause code is generally a result of
failures related to radio coverage, improvement in it should result in lower value
of 0B13.
The clear code may be triggered at any time after the CMSERVICE REQUEST
or PAGING RESPONSE from the MS has been received. When this clear code
is triggered, it is always also visible to the end user (either a failed call setup, or
a dropped call). Looking at the phase of the clear code gives some understanding
of the phase of the call, however whether this happened while the MS was on
SDCCH or TCH can not be separated. This clear code is affected by the traffic
NTC TAN 84262/1 en
24
distribution of the MSC, thus a direct comparison between different networks is
not possible.
How to analyse further
To see where TCH and SDCCH failures happen and what particular failure is
dominating, use PM Data Reporter or Measurement Data Postprocessing in PC
to generate Top 15 SDCCHand TCHdrop reports, for example.You can also use
Network Doctor for BSS reports Cells Having High TCH Drop Call Ratio (163)
and SDCCD Drop Ratio per Cell (166) for locating the most problematic cells.
The BSS traffic measurement must be running in order to get the data needed for
these reports.
3.2.2 Radio I/F msg failure / 0B1B
Practical meaning
This clear code usually indicates a coverage problem.
This code is caused by a situation where a message belonging to a call
transaction is missing, hence clearing because of it. The clear code may be
related to degradation of the connection quality because of interference, for
example.
To see where TCH and SDCCH failures happen and what particular failure is
dominating, use PM Data Reporter or Measurement Data Postprocessing in PC
to generate Top 15 SDCCH and TCH drop reports, for example. You can also
use Network Doctor for BSS reports Cells Having High TCH Drop Call Ratio
(163) and SDCCD Drop Ratio per Cell (166) for locating the most problematic
cells.
these reports.
3.2.3 Radio I/F congestion / 0205
Practical meaning
This clear code indicates a capacity problem. The TCH resources are not
sufficient in a BTS and a site extension is needed.
Note that the percentage of radio interface congestion from clear code statistics
is an average over the whole MSC area, and most often also an average over 24
hours at least, not only the busy hour. Therefore even slight congestion on the
MSC level may be visible as more serious problems in some areas or at some
periods.
NTC TAN 84262/1 en
25
To see where TCH blocking happens, use PM Data Reporter or Measurement
Data Postprocessing in PC to generate a Top 15 TCH blocking report, or
generate Network Doctor for BSS report Cells Having High TCH Blocking
(138), for example.
these reports.
When considering issues such as congestion, you have to remember that the
cause code data is an average over the whole of the MSC area. Some areas will
definitely suffer from heavy congestion even if the average value is low.
3.2.4 Circuit congestion / 080F
Practical meaning
The circuits on 2M links are overloaded. Extension of the circuits is needed.
To analyse further, use Network Doctor for NSS report Circuit Group Statistics
(602) to identify the problematic circuits. When using alternative circuits the real
congestion is shown only for the latest hunted circuit. The MSC Circuit Group
measurement must be running in order to get the data needed for this report.
3.2.5 Outgoing circuit congestion / 0804
Practical meaning
The circuits on 2M links are overloaded. Extension of the circuits is needed.
Use Network Doctor for NSS report Circuit Group Statistics (602) to spot the
problematic circuits. The MSC Circuit Group measurement must be running in
order to get the data needed for this report.
3.2.6 Overload congestion / 060B
Practical meaning
Call set-up fails.
The clear code 60B 'OVERLOAD CONGESTION' is used for the following
reasons:
1. When there is no resource for a call, that is, the hand reservation of a
program block fails. This overloading is due to configuration error. The
alarm 2668 CALL ESTABLISHMENT FAILURE is also generated.
NTC TAN 84262/1 en
26
2. The limit of unhandled DX 200 internal messages is exceeded in a partner
program block (system overload). The alarm 1667 UNHANDLED
MESSAGES OVERFLOW is also generated.
3. A program block fails to get a call identifier reserved for a call (call
identifier is used to identify an individual call through the exchange). If
call identifier reservation fails, it may be caused by overload in statistics
unit.
4. A program block fails to get 'ticket' reserves for a call, that is, overload
control prevents call establishment (system overload).
You can Network Doctor for NSS report MSCNetwork Benchmark (600) to find
out the share of overload congestion on network level, and for example report
Clear Code Set per MSC (617) to study overload congestion per MSC.
3.2.7 Remote equipment failure / 0B16
Practical meaning
Commonly related to BSS transmission problems.
In the MSC, clear code observations help to identify the source of the problem.
In the BSC, TCH observations or clear code statistics may help to identify the
most common causes.
You can analyse the BSS observation data by using the Network Doctor for BSS
report TCH, SDCHH and BSC out HO Observation Statistics (217). From this
report, you can find out what is the actual point of failure in the message flow as
defined by phase and cause.
3.2.8 Handover failure / 0B14
Practical meaning
May be caused by a number of reasons.
To analyse further, use BSC HO measurement and HO success reports on
Measurement Postprocessing on PC.You can also use Network Doctor for BSS
report Cells Having High HOFailure Ratio (150) to locate problematic cells. Use
BSC HO adjacent cell measurement and Network Doctor for BSS report
Adjacencies Having High HO Failure Ratio (153) to locate problematic
adjacencies.
NTC TAN 84262/1 en
27
3.2.9 No Paging Response / 0012H
Practical meaning
The MS has not answered to paging in a call attempt (failure to answer paging in
a terminating SMS will not trigger 0012). Call has not been diverted to voice
mail (successful voice mail will result in 0000 Normal end of call). If
announcement is given, in most cases 0012 is still the result.
The amount of No paging response can be affected by:
Usage of voice mail
The ratio of mobile terminated traffic to originated
Coverage problems
SDCCH congestion (if SDCCH congested, mobile can not send paging
response)
Usage of IMSI attach/detach & implicit IMSI detach
Because of the different usage of voice mail, different traffic distributions and
differences in national signalling do not compare No Paging Response between
networks.
Use VLR measurements to measure the paging success rate. Use Network
Doctor for NSS report VLR Failure Profiles (632) to find out the paging failure
rate
3.3 Clear codes related to DATA calls
The most common clear code is 0 (normal end of call) because terminal
equipment clear the call. The number of data calls is still relatively lowcompared
with the normal calls. Therefore the number of these clear codes must be
compared with the amount of data calls, not all calls.
The number of data calls can be counted from the modem circuits in Circuit
group measurement or calls handled by IWCU fromControl Unit Measurement.
3.3.1 Modem error / 70B
The problemnormally lies in the IWF modem, FAXMO or DASA. It is possible
to get the clear code in a DDA call and then the problem is in the DASA or the
device connected to the DDA port.
3.3.2 V.110 frame synchronous fails / B10
The problem could be in the DASA, MS or in between.
NTC TAN 84262/1 en
28
3.3.3 Modem communication error / B11
The problem normally lies in the modem or fax of pool or on the PSTN side.
Verifying BTS performance
NTC TAN 84262/1 en
29
4 VERIFYING BTS PERFORMANCE
The purpose of this procedure is to give you an example of how to monitor the
performance of BTSs with Nokia NMS features. This procedure can be used for
monitoring BTSs that are not performing in an optimum way.
4.1 Prerequisites
This section lists the minimum requirements that enable you to carry out the
subsequent procedure successfully. Read this section carefully to avoid
unnecessary troubleshooting later.
AlarmMonitor: used for viewing threshold and loop test generated alarms
Scheduled BTS Tests: used for automatic running of TRX Loop Tests
measurements
Thresholds for Measurements: used for generating alarms based on PM
data analysis
Managed Object Browser: used for locating BTSs for use in the
applications
Measurement Data Postprocessing in UNIX (PM Data Reporter): used
viewing loop test results graphically
BSS Network Doctor: used to run periodic textual reports
Working Set Manager: used for separating the desired BTSs for
monitoring
NMS database.
4.2 Flowchart of the procedure
The following flowchart gives you an overview of the procedure as well as the
tools that you can use in the steps of the procedure.
NTC TAN 84262/1 en
30
Figure 3. Verifying BTS performance
4.3 Identifying the BTSs
If you want to monitor a specific type of BTSs, you can identify them with
Managed Object Browser using the following instructions.
denti fy BTSs
Ensure that requi red
measurements are runni ng
Create new MR for BTSs
Defi ne threshol ds for BTSs
Confi gure Al arm Moni tor
Moni tor other rel ated al arms
Set up Antenna Loop Test
Set threshol ds for TRX
Loop Test resul ts
Create report on BER
Run rel evant Network
Doctor Reports
BSS
Measurement
Admi ni strati on
Network Edi tor
Threshol ds for
Measurements
Al arm Moni tor
Al arm Moni tor
Thrshol ds for
Measurements
Network
Doctor for BSS
Start
PM Data Post-
Processi ng
Schedul ed
TRX Loop
Test
Managed
Obj ect
Browser
Fi ni sh
NTC TAN 84262/1 en
31
To identify the BTSs
1. Start Managed Object Browser fromApplication Manager or the Top-level
User Interface.
2. Search by criteria for BTSs to get a listing of all the BTS in the PLMN:
Click Cancel in Opening Working Set dialog.
Select BCF in the Class pane.
Set the BTS site type in the Search Attributes pane.
If you need more detailed instructions, please see Managed Object
Browser Help.
Note:
Do not close the Search Results dialog. The results will be needed at a later
phase.
4.4 Verifying that the required performance measurements
are running
When a BTS is not performing in an optimum way, it does not always generate
alarms. For that reason it is necessary to study the performance data being
generated by those sites.
To verify that the required measurements are running
1. Start Administration of BSS Measurements from Application Manager or
the Top-level User Interface.
2. Ensure that the following BSS measurements are running on each BSC:
RX Level measurement (heavy measurement - can be used but its
use is not recommended)
RX Quality measurement
Power control measurement
The measurements should be turned on 7 days a week, 24 hours each day
and the reporting period should be set to 60 minutes.
If you need more detailed instructions, please see Administration of BSS
Performance Measurements Help.
NTC TAN 84262/1 en
32
Note:
Turning on these measurements in addition to the other measurements
already running, can cause a considerable load on the NMS platform. You
should therefore consult the system administrator before turning new
measurements on. Otherwise you might overload the systemwith network
data.
For information on the Nokias measurement set recommendations and output
intervals of the measurements, see Measurement Data Postprocessing in PC
Report Descriptions, TAN 85121, and Performance Management: Basic
Operating Principles and Procedures.
4.5 Setting up a new Maintenance Region for specific BTSs
To effectively monitor specific BTSs, you must set up a special MR and attach
the BTSs to it. If you do not do this, it is difficult to isolate the data generated by
the specific BTSs from all the other BTSs in the network.
To create a new Maintenance Region
1. Start Network Editor from Application Manager or the Top-level User
Interface.
2. Create a new view and add the following objects:
PLMN
MR
For more instructions on how to create managed objects, please see
Network Editor Help.
3. Select all BTSs listed in the Search Results dialog and drag and drop them
into Network Editor.
4. In Network Editor, update the object details of all BCFs by assigning them
to the newMR. Remember to select Update All Children in the MR pane.
For more instructions on how to modify object information, please see
Network Editor Help.
4.6 Setting thresholds for BTSs performance
One of the problems with monitoring BTS performance is that when the
performance is getting worse, you may not see any related alarms in the control
room. For this reason we can try using Thresholds for Measurements in the
NMS. This feature scans PM data received in the NMS, and if certain user
defined criteria are exceeded, alarms are generated to the appropriate element in
the user interface.
NTC TAN 84262/1 en
33
The thresholds can be applied to specific BTS elements when setting up the
thresholds in the graphical application but if you have hundreds of BTSs in the
network, it might be easier to use the Maintenance Regions. You need customise
Alarm Monitor to view certain results only from the BTSs and allow the
threshold to be calculated at all sites.
The suggested threshold looks at Rx quality. Fromthe subscribers point of view,
the quality band 0-5 is acceptable. Above 5 is not acceptable. It is recommended
that for BTSs at least 50%of the calls should be in quality band 0. This threshold
will generate a three star alarm if less than 50% are in this band 0.
To set up thresholds for BTS performance
1. Start Thresholds for Measurements fromApplication Manager or the Top-
level User Interface.
If you need detailed instructions on how to use Thresholds for
Measurements, please refer to Thresholds for Measurements Help.
2. Create a new BTS-level threshold rule for a critical class alarm with the
following formula:
100 * (p_nbsc_rx_qual.FREQ_UL_QUAL0) /
(p_nbsc_rx_qual.FREQ_UL_QUAL0 + p_nbsc_rx_qual.FREQ_UL_QUAL1 +
p_nbsc_rx_qual.FREQ_UL_QUAL2 + p_nbsc_rx_qual.FREQ_UL_QUAL3 +
p_nbsc_rx_qual.FREQ_UL_QUAL6 + p_nbsc_rx_qual.FREQ_UL_QUAL7) < 50
Example 2. Threshold formula for a critical class alarm
3. Use the sampling period of 100 minutes and set time schedule from 00:00
-23:59 for the threshold.
4. Fill in any other required information in the Defining Threshold dialog.
5. Save and close the definition dialog.
6. Start the threshold and select the whole PLMN as the managed object.
7. As above, define a threshold rule for a major class alarm using the
following formula:
100 * (p_nbsc_rx_qual.FREQ_UL_QUAL0 + p_nbsc_rx_qual.FREQ_UL_QUAL1
+ p_nbsc_rx_qual.FREQ_UL_QUAL2 + p_nbsc_rx_qual.FREQ_UL_QUAL3 +
p_nbsc_rx_qual.FREQ_UL_QUAL4 + p_nbsc_rx_qual.FREQ_UL_QUAL5) /
(p_nbsc_rx_qual.FREQ_UL_QUAL0 + p_nbsc_rx_qual.FREQ_UL_QUAL1 +
p_nbsc_rx_qual.FREQ_UL_QUAL6 + p_nbsc_rx_qual.FREQ_UL_QUAL7) < 95
Example 3. Threshold formula for a major class alarm
8. Define another rule for a minor class alarm by setting the limits between
95% and 99%.
NTC TAN 84262/1 en
34
The following alarms will nowbe generated by the Threshold for Measurements.
9000 (one-star (*) threshold alarm for bad UL quality)
9105 (two-star (**) threshold alarm for bad UL quality)
9206 (three-star (***) threshold alarm for bad UL quality)
4.7 Configuring Alarm Monitor for specific BTSs
The NMS system now automatically generates alarms when it detects the
thresholds being exceeded. To be able to concentrate on monitoring the alarms
generated by the selection of BTSs we recommend that you configure an
instance of Alarm Monitor for viewing the alarms from the specific BTSs only.
To configure Alarm Monitor to display the alarms of specific BTSs only
1. Start Alarm Monitor from Application Manager or the Top-level User
Interface.
2. Set your monitoring criteria to include the created MR only.
3. Add the following alarms into the Alarm Numbers list:
4. Save your criteria and activate the criteria.
If you need more detailed instructions on how to use Alarm Monitor,
please refer to Alarm Monitor Help
4.8 Configure Alarm Monitor for other related alarms
BTSs which are not performing properly may start generating at least the
following two DX alarms which are associated with antenna performance:
7590 ANTENNA PERFORMANCE DEGRADED
7591 ANTENNA FAULTY
These two alarms should be added to the Alarm Monitor using the
instructions from the above section.
Another alarmwhich should be included into the monitoring criteria is the
BTS WITH NO TRANSACTIONS. This means we will spot if the BTS
starts to take no traffic at all, that is, total failure.
2535 BTS WITH NO TRANSACTIONS
NTC TAN 84262/1 en
35
For detailed descriptions of these alarms, start Modifiable Alarm Manual.
4.9 Setting up a TRX loop test for BTSs
TRX loop tests can be run from the NMS in a regulated and scheduled manner.
The tests especially enable you to study the BER (bit error rates).
The loop tests can be set up to be run periodically each night at times of low
traffic density. You can also use some criteria in the NMS configuration files
which allows an alarm to be generated if the BER values exceed a user-defined
threshold. If you customise the NMS to store the loop test results, you can use
PM Data Reporter to examine the results in graphical format
Scheduled TRX Loop Test tests the operation of the RF unit and checks the
correctness of the A/D and D/A conversions. In the test the test data generated
by the software in the digital parts of the BTS is looped internally from the TX
side to the RX side so that complete TX and RX chains are tested. The TRX SW
checks the looped data and the test result is given as BER values.
The TRX Loop Test can be run in full rate (TCH/FR) timeslots only. It can be
performed at all TX output power levels. For DE45/DF45 BTS sites (4th
generation), the test can be carried out fromthe main TXto the diversity RX, and
from the diversity TX to the main RX. The test uses a static TX power level as
defined in the HW database.
When the test is run on DE45/DF45 BTS sites, no special equipment is needed
on the BTS site. When running the test on DE34/DF34 or DF21/DE12 BTSs, you
need test equipment as specified in Scheduled TRX Loop Test Help.
To set up Scheduled TRX loop tests for BTSs
1. Start Scheduled Loop Test Management from a BSC pop-up in the Top-
level User Interface and create a new test for the specific BTSs with the
following test parameters:
TX Timeslot: Circulated
Attenuation: Without
Diversity: Averaged
STM Antenna Attenuation: No Attenuation
Test Schedule
Sunday - Saturday
Dates and times of your choice
NTC TAN 84262/1 en
36
Note:
You might just select all BSCs which have BTSs connected and then let
the test run in all BTSs.
If you need help on how to define tests, please see Scheduled TRX Loop
Test Help.
4.10 Setting thresholds for TRX Loop Test results
Note:
These instructions assume you have the authority and skills needed to examine
the NMS platform. If you do not, contact your system administrator
With the instructions that follow, you can set the BER threshold to 0.2 to
generate alarm9005 when the BER in the TRX Loop Test results exceeds 0.2%.
You can also set the history option on to store the test results for report
generation in PM Data Reporter.
To set thresholds for the Scheduled TRX Loop Test results
1. Edit the TRXLoop Test Event Handler configuration file (sr5mgrmx.cf)
on the Database Server to include the following definitions:
dummyManageThisEventType "2.2.2.4.5.106")
(dummyManageThisEventType "2.2.2.4.5.104")
(failedThreshold "0")
(inconclusiveThreshold "0")
(cuResultThreshold "0")
(lnaResultThreshold "0")
(rteResultThreshold "0")
(bitErrorRatioThreshold "0.2")
(bitErrorRatioDelta "0.1")
(rxLevelWithAttDelta "2")
(rxLevelWithoutAttDelta "2")
(msRxLevelDelta "3")
(bitErrorRatioNonprotectedDelta "0.1")
(standingWaveRatioDelta "0.1")
(bsTxPowerDelta "5")
(eventTimeDelta "30")
(historyOption "1")
Example 4. sr5mgrmx.cf configuration file definitions
2. Restart the TRX Loop Test Event Handler process (sr5mgrmx) on the
Database Server.
NTC TAN 84262/1 en
37
For more information how to stop and start processes, see System
Management Tasks
The loop test alarm is now generated each time the BER becomes worse
than 0.2%. This criteria setting could be modified if needed. The alarm
9005 will be sent to the Top-level User Interface. Alarm Monitor should
also be further customised so that it goes to the instance of AlarmMonitor
if one of the BTSs shows poor performance in this area.
For additional information on alarm9005, start Modifiable AlarmManual.
Including the alarms mentioned earlier in this procedure, the customised
Alarm Monitor should now include the following specific alarms:
2535 (BTS with no transactions)
7590 (Antenna Performance Degraded)
7591 (Antenna Faulty)
7511 (Radio Test Loop Failure in TRX)
9005 (TRX Loop Test Thresholds Exceeded)
The TRX and Antenna Loop Test results can also be viewed directly from
the application itself. Start the application from the BSC pop-up menu on
4.11 Creating a report on BTS Bit Error Ratio
You may wish to see in a graphical format the results of the test. The NMS/2000
application PMData Reporter contains a predefined template for this reporting.
(Note that Measurement Data Postprocessing in PC cannot be used for viewing
the loop test results.)
This report shows the averaged BER fromone week for every TRX having TRX
Loop Test history data. The history option must be turned on before it is possible
to generate this report (see instructions above in section Setting thresholds for
TRX Loop Test results).
How to generate this report
1. Start PM Data Reporter from Application Manager or the Top-level User
Interface.
2. Expand the Scheduled TRX Loop Test reports and select Multiple TRX,
Bit error ratio.
NTC TAN 84262/1 en
38
3. Add PLMN to the Study objects list.
4. Generate the report.
Unfortunately PM Data Reporter does not support the use of MR, so you
have to 'attach' the BTSs yourself, which means knowing which were the
BTSs.
For more detailed information on how to use PM Data Reporter, refer to
PM Data Reporter Help.
4.12 Using Network Doctor for monitoring BTSs
Network Doctor is useful because it can be operated by Maintenance Region, so
the MR created earlier can be used to ensure that only the desired BTSs are taken
into account when running the reports.
The instructions below take advantage of Working Set Manager and its features.
If you do not have this, just skip those steps and use MR as a criteria for site
selection.
To automatically generate reports with Network Doctor for BSS
1. Start Managed Object Browser fromApplication Manager or the Top-level
User Interface.
2. Search by criteria for BTSs to get a listing of all the BTSs in the PLMN:
Click Cancel in Opening Working Set dialog.
Select BCF in the Class pane.
Set the BTS site type in the Search Attributes pane.
If you need more detailed instructions, please see Managed Object
Browser Help.
Note:
Do not close the Search Results dialog. The results will be needed at a later
phase.
3. Start Working Set Manager from Application Manager or the Top-level
User Interface.
4. Create a new working set including all BTSs. You can drag and drop the
BTSs from Managed Object Browsers search dialog to the new working
set.
If you need more detailed instructions on how to create working sets,
please refer to Working Set Manager Help.
NTC TAN 84262/1 en
39
5. Fill in the Description field and save the working set.
6. Start an xterm session.
7. Start Network Doctor by giving the following commands:
omc>% cd $OMCROOT/lib/ndplus
omc>% ./ndp001mx.sh
8. Log into the NMS database as the omc user.
9. Generate auto script with the following parameters:
Select report 196
Select option 11 (Working Set (manual, with BCFs))
Enter your working set name
Select option: 3
Number of days: 1
Set threshold: 0
Set threshold: 100
Set threshold: 1
Select sorting: UL quality 5
Select output: Not shown
Select output: Not shown
10. When an editor window opens with the temporary script file, save the file
to another name (quality.sh, for example).
11. Edit the script to include the following:
#######################################################
#
# Definition of script name and output file name:
#
#######################################################
#
DATE=`date +%m%d`
SCRIPT=$OMCROOT/lib/ndplus/ndp196mx.sql
OUTFILE=$HOME/ndp196_$DATE.lst
#
#######################################################
Example 5. Data to be added to the script.
12. Save the file and exit the editor.
NTC TAN 84262/1 en
40
13. Insert the following entry to the omc users crontab and activate the cron:
0 1 * * * csh -c '/home/omc/quality.sh omc <passwd>' > /dev/null
2>&1
<passwd>: omc users password for the NMS database
If you need more information on how to modify crontabs, please refer to
System Management Tasks.
The report is generated once a day. The report is stored in
ndp196_<mmdd>.lst.
<mmdd>: month and day as 1121 (November 21)
14. Exit Network Doctor for BSS.
Monitoring cell interference
NTC TAN 84262/1 en
41
5 MONITORING CELL INTERFERENCE
With new networks especially, interference is a common factor that causes
degradation in the Quality of Service observed by subscribers. Therefore
optimising the network by pruning out the most obvious sources of interference
and monitoring its level for some time can greatly enhance your networks
performance. The sections that follow show you by way of an example how you
can monitor interference with Nokia NMS features.
5.1 Prerequisites
AlarmMonitor: used for viewing threshold and loop test generated alarms
measurements
Thresholds for Measurements: used to generate alarms based on PM data
analysis
used to graphically view PM data
Consistency Check: used for detecting inappropriate parameter settings
Radio Resource Online Monitoring: used for monitoring the radio
resources of problematic cells
Initial Tracing: used for verifying the functionality of new parameter
settings
Trace Viewer: used for verifying the functionality of new parameter
settings
Performance Measurement Database Contents: used for verifying that
there is enough PM data in the NMS database for generating reports
NMS database.
NTC TAN 84262/1 en
42
5.2 Flowchart of the procedure
The following picture shows a flowchart of the procedure. If you are familiar
with the detailed steps involved in this procedure, you can use the flowchart as
quick reference to the main phases of the procedure.
Figure 4. Monitoring interference
Acti vate Resource Avai l abi l i ty
Measurement
Defi ne and acti vate threshol d
rul e
Moni tor faul ts
Check i f PM data i s avai l abl e
Generate report on F
Moni tor radi o resources
Modi fy RNW parameters
Veri fy parameter changes
Start
Fi ni sh
Anal yse report
Admi ni strati on
of BSS
Measurements
Threshol d for
Measurements
Al arm Moni tor
DB Contents
Measurement
Post Processi ng
BSS Radi o
Resource
Onl i ne Di spl ay
RNW tool s
TraceVi ewer
Check RNW parameters
Consi stency
Checks
NTC TAN 84262/1 en
43
5.3 Running consistency checks
When you have sorted out problems due to faulty equipment or faulty
configuration, the remaining problematic cells may have problems with the radio
network plan. You may have to tune the cell parameters or check the plan in
general for the frequencies used or the environment. Consistency Check contains
several tools with which you can locate possible sources of interference caused
by incorrect parameter settings.
To run Consistency Checks
1. Start Consistency Check from Application Manager or the Top-level User
Interface.
2. Run the following checks to weed out the most obvious parameter faults
Interfering Frequencies of Adjacent TRXs
Interfering Frequencies within BTS
IUO Interfering Cells in TRX (if IUO is in use)
If you need more information on using Consistency Check, please refer to
Consistency Check Help.
3. If the checks reports interfering frequencies, contact your radio network
planner to adjust the parameters.
4. Re-run the checks to verify the changes.
5.4 Activating the Resource Availability measurement
The Resource Availability measurement collects information about the
availability of the radio resources in each cell under the BSC in which the
measurement is activated. This measurement also collects data about the
interference bands and provides you with suitable counters to get information on
network interference. We recommend that you have the Resource Availability
measurement active all the time, and the measurement output interval should be
one hour. If you have activated this measurement earlier, the data for this purpose
already exists in the NMS database.
If the Resource Availability measurement is not yet active, you can activate it
using the Administration of BSS Measurements application. You should specify
the measurement to be active in all of the BSCs in your network, for 24 hours a
day and seven days a week, with the output interval of one hour.
To activate the Resource Availability measurement
NTC TAN 84262/1 en
44
2. Ensure that the following BSS measurement is running on each BSC:
Resource Availability measurement
The measurement should be turned on 7 days per week, 24 hours each day
and the reporting period should be set to 60 minutes.
If you need more detailed instructions, please see Administration of BSS
Performance Measurements Help.
Note:
Turning on measurements in addition to the other measurements already
running, can cause a considerable load on the NMS platform. You should
therefore consult the system administrator before turning new
measurements on. Otherwise you might overload the systemwith network
data.
For information on the Nokias measurement set recommendation and output
intervals of the measurements, see Measurement Data Postprocessing in PC
Report Descriptions, TAN 85121, and Performance Management: Basic
Operating Principles and Procedures.
5.5 Setting configurable thresholds
When the required measurement data is available in the NMS database, you can
start using the Thresholds for Measurements application. With this application
you can create an alarm rule that generates an alarm when a certain interference
level is exceeded in the network.
Note that you should not create very tight rules at the beginning of the network
life cycle, because you might get a huge amount of alarms; later on, when the
network is more developed and stabilised, the limits for the alarms can be tighter.
The threshold percentage value is also highly network specific. It may well be
that the value of 2%is much too optimistic and if set it causes the application to
flood your system with alarms.
To set up thresholds for interference
2. Create a new BTS-level threshold rule for a major class alarm with the
following formula:
NTC TAN 84262/1 en
45
(1 -(sum(p_nbsc_res_avail.ave_idle_f_tch_1/
p_nbsc_res_avail.res_av_denom4)/sum(
p_nbsc_res_avail.ave_idle_f_tch_1/
p_nbsc_res_avail.res_av_denom4+p_nbsc_res_avail.ave_idle_f_tch_2/
p_nbsc_res_avail.res_av_denom8)))*100 > 2
Example 6. Threshold formula for a major class alarm
Note:
You can use the threshold formula based on the logical counter
Interference, I/F level>1 under the logical counter group LCG Resource
Availability.
You can find the counter and counter group by using the Handling of
Logical Counters application. Start the application from the main window
of PM Data Reporter.
3. Use the sampling period of 60 minutes and set time schedule from 00:00 -
23:59 for the threshold.
7. As above, define a cancel rule for a major class alarm using the same
formula but setting the threshold value to be < 1.5%:
After you have defined and activated the thresholds, they are automatically
monitored by the system, and you get an alarm (** 9105) when the specified
interference level is exceeded.
5.6 Configuring AlarmMonitor for monitoring interference
The NMS system now automatically generates alarms when it detects the
thresholds being exceeded. The alarms will be seen on the graphical user
interface, but so, of course, will all the other alarms coming from the network.
That is why we recommend viewing the alarms in the Alarm Monitor
application.
To configure Alarm Monitor to display the interference alarms only
1. Start Alarm Monitor from Application Manager or the Top-level User
Interface.
2. Set your monitoring criteria to include the MR you wish to monitor.
NTC TAN 84262/1 en
46
3. Add the following alarm into the Alarm Numbers list:
9105 (two-star (**) threshold alarm for interference)
4. Save and activate the criteria.
When an alarm is generated indicating that there is too much interference in one
cell, you should start examining the cause of the alarm in detail to try to find out
the reason for the high interference level.
5.7 Checking that sufficient PM data is available
Before generating reports, you can check if there is enough statistical data
available in the NMS database.
To check that enough PM data is available in the NMS database
1. Start Database Contents from Application Manager or the Top-level User
Interface.
2. Select the BSC you are studying and the Resource Availability
measurement, and check if there is sufficient PM data for reporting.
If you need more detailed instructions, please refer to Performance
Measurement Database Contents Help.
5.8 Generating reports
With the PM Data Reporter or Measurement Data Postprocessing in PC
application, you can generate a report on the cell with high interference.
To generate a report on interference
Interface.
2. Expand the Scheduled Nokia BTS reports and select BTS Profile,
Interference.
3. Add the BTS you want to the Study objects list.
4. Generate the report.
This report gives information on the interference level of each day within
the current month, and in this way, it is possible to see howthe interference
levels have changed during the month and when the problem occurred for
the first time. This may correlate with certain network configuration
changes.
For more detailed information on how to use PM Data Reporter, refer to
PM Data Reporter Help.
NTC TAN 84262/1 en
47
You can also generate a report which lists the top 15 cells having the most
interference in the BSC where the alarm was raised. In this way, you can get an
overall picture of the interference in the BSC in question; there may be other
problematic cells in the area as well. The report shows in which particular cells
of this BSC there are problems.
You can investigate cell interference also by generating Network Doctor report
UL and DL Quality and UL Interference per TRX, 24-hour/10-day Breakdowns
(196).
5.9 Activating Radio Resource Online Monitoring
To investigate the problem further, you should start monitoring the radio
resource information of the problematic cells using the BSS Radio Resource
Online Display application. This application can be activated to collect data from
the TCHs which use interference band 5.
To monitor radio resources
1. Start Radio Resource Online Monitoring fromApplication Manager or the
Top-level User Interface.
2. Add the BCF you want to monitor to the Network Element list.
3. Use the following selections:
Observation type: Channel search
Channel type: TCH
Search criteria: I/F level 0
If the results showthat there are TRXwith the same frequency, for example, you
may have to escalate the problem and inform network planning about required
frequency changes.
5.10 Activating Initial Tracing and Trace Viewer
After the network parameters have been reconfigured, you should run some tests
to make sure that the network is functioning correctly after the adjustments. In
addition to performance measurements, you can obtain useful information by
using Trace Viewer.
To get detailed information on the functioning of a cell, you can send a test
mobile equipment to the area where the cells are located. After that it is possible
to activate the Initial Tracing feature with Trace Viewer or through a remote
MMI session from the Nokia NMS workstation to the HLR or to the MSC.
The observation reports in this application give useful data concerning the test
mobile equipment and the related calls: you obtain information about signal
NTC TAN 84262/1 en
48
strength (for example strength of the best six adjacent cells), quality and power
(uplink/downlink directions), and timing advance.
In addition, you can use another tool, Network Doctor, for getting more
information on the problem. This application has several scripts which produce
useful textual reports concerning network interference. According to the radio
resource data received from these applications, you can start reconfiguring the
network by using the Nokia Configuration Management tools.
5.11 Using Network Doctor reports for analysing interference
Network Doctor for BSS also contains some useful reports that can be used to
analyse cell interference. We recommend that you use the following Network
Doctor reports:
Adjacent cells with the same or adjacent frequency (062)
Adjacent cell double frequencies (069)
Network performance statistics (200)
Cells having UL interference, 24-hour/10-day breakdowns (190)
UL and DL Quality and UL Interference per TRX, 24-hour/10-day
Breakdowns (196)
Cell analyser (216)
For information on how to run these reports, see the Network Doctor for BSS
documentation.
Based on the data received fromthe observation results and the reports generated
by the applications PM Data Reporter or Measurement Data Postprocessing in
PC and Network Doctor, you can make sure that your network is reconfigured
correctly and the interference level is normal in the cell under study.
Verifying transmission network performance
NTC TAN 84262/1 en
49
6 VERIFYING TRANSMISSION NETWORK
PERFORMANCE
The quality of the transmission can be measured as a count of different
transmission alarms. The purpose of this procedure is to give you an example of
how to monitor the performance of transmission equipment with Nokia NMS
tools.
6.1 Prerequisites
This section lists the minimum requirements that enable you to monitor your
transmission network efficiently. Read this chapter carefully to avoid
unnecessary troubleshooting later.
measurements
Measurement Data Postprocessing in UNIX (PMData Reporter): used for
viewing PM data
Thresholds for Measurements
6.2 Activating transmission measurements
The measurements in the transmission elements are managed by using
Administration of BSS Measurements.
For more detailed information on how to use this application, refer to
Administration of BSS Performance Measurements Help.
To activate the transmission measurements
2. Create a new measurement. Fill in the Creating a Measurement dialog,
referring to the Online Help if needed.
The following transmission measurements are available:
TRU measurement
DMR measurement
DN2 measurement
All nodes have the same measurement interval within the same BSC.
NTC TAN 84262/1 en
50
3. Activate the measurement.
6.3 Creating a transmission report
To create a transmission report
Interface.
2. Create a newreport. Fill in the dialog, select the base object level and study
object level. The base object level for cellular transmission measurements
is PLMN-BSC-TRE-TRE PORT.
3. On the option button in the Axes pane select the Counters - Time option.
4. Fill in the Report Definition window, referring to the PM Data Reporter
Help if needed.
5. After you have filled in all necessary information in the Report Definition
window, generate the report.
6.4 Monitoring radio links
6.4.1 Setting Thresholds for DMR equipment
You can set thresholds for DMR equipment using the Thresholds for
Measurements application.
The following procedures can be used to set thresholds when errored seconds,
severely errored seconds, degraded minutes in DMR equipment exceed a certain
threshold value and when the RF level drops under a certain threshold value.
The precondition is that the measurement collection has started in the network
and measurements are coming into the NMS database.
For more detailed instructions on using Thresholds for Measurements, refer to
Thresholds for Measurements Help.
To set the counter (errored seconds, severely errored seconds, degraded
minutes, or min./max. RF level) to exceed a certain threshold value
2. Create a threshold rule. Select a threshold table and select a counter that
relates to errored seconds, severely errored seconds, degraded minutes,
min. RF input level, or max. RF input level.
Close the Editing Rule dialog after you have filled in all necessary
information.
NTC TAN 84262/1 en
51
The alarmis directed to the DMR view object if the threshold value is exceeded.
You can find the problematic DMR in the network and use PMData Reporter to
find out more information about the problematic
DMR.
6.4.2 Creating reports for DMR equipment
This procedure is for a network operator who is creating reports using PMData
Reporter, which displays the DMR equipment and the counters. This procedure
is for listing 10 devices that have had the most errored seconds, severely errored
seconds, degraded minutes or the lowest RF levels during last the 24 hours. The
report displays the DMR equipment and the counters.
The precondition is that the measurement data has been collected into the
database for the last 24 hours.
For more detailed information on how to use PM Data Reporter, refer to PM
Data Reporter Help.
To create a report for DMR equipment
Interface.
2. Create a new report.
Select the base object level and study object level. The base object level for
cellular transmission measurements is PLMN-BSC-TRE-TRE PORT. On
the option button in the Axes pane, select the Study Objects - Counters
option. Click OK. The Report Definition window opens.
3. Fill in the Report Definition window:
Select the counters by clicking the Counter(s) button and the Report
Counters dialog opens. Fill in the Report Counters dialog. Select the
measurement tables and counters that you want. After you have
filled in all necessary information in the Report Counters dialog,
click OK.
Select the study objects by clicking the Add... button in the Study
Object(s) pane and the Selecting Study Objects dialog opens. After
you have selected the study objects, click Apply and Close.
Define the number limitation in the Number Limitation pane, by
selecting 10 as the Maximum Number.
Define the counter by which the study objects are ordered by
clicking the Order button and the Order of Study Objects dialog
NTC TAN 84262/1 en
52
opens. Fill in the Order of Study Objects dialog. Click the Counter...
button. The Selecting Counter(s) dialog opens. After you have
selected one counter, click Apply and Close. Then click the option
button next to Method and select Summarisation, Maximum or
Minimum. Then select either the Ascending or Descending option.
After you have filled in all necessary information in the Order of
Study Objects dialog, click OK.
Define the report period by clicking the Report Period... button and
the Report Period dialog opens. Fill in the Report Period dialog. In
the Study Period pane, select Relative with a Length of 1 day and
from the End option button select Current Time. After you have
filled in all necessary information in the Report Period dialog, click
OK.
4. After you have filled in all necessary information in the Report Definition
window, generate the report

Verifying Network Performance and KPIs

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Verifying Network Performance and KPIs

Enviado por

Direitos autorais:

Formatos disponíveis

NTC TAN 84262/1 en

Você também pode gostar