Professional Documents
Culture Documents
Health Analyst
Motorola and the Stylized M Logo are registered in the US Patent & Trademark Office. All other product or service
names are the property of their respective owners.
The CE mark confirms Motorola, Inc. statement of compliance with EU directives applicable to this product. Copies
of the Declaration of Compliance and installation information in accordance with the requirements of EN50385 can
be obtained from the local Motorola representative or by contacting the Customer Network Resolution Center
(CNRC). The 24 hour telephone numbers are listed at https://mynetworksupport.motorola.com. Select Customer
Network Resolution Center contact information. Alternatively if you do not have access to CNRC or the
internet, contact the Local Motorola Office.
Contents
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P i
May 2008 1900.2AS
Contents
ii 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
68P02900W36-P iii
May 2008 1900.2AS
Contents
iv 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
68P02900W36-P v
May 2008 1900.2AS
Contents
vi 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
68P02900W36-P vii
May 2008 1900.2AS
Contents
viii 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
68P02900W36-P ix
May 2008 1900.2AS
Contents
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52
High TCH blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54
Paging overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56
High MTL utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58
High estimated RSL utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
Signaling message sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61
High RSL Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63
Handover problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64
List of handover problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64
Interband handover success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67
Low incoming handover success rate (inter/intra BSS). . . . . . . . . . . . . . . . . . . . . . 3-68
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69
x 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
68P02900W36-P xi
May 2008 1900.2AS
Contents
xii 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
68P02900W36-P xiii
May 2008 1900.2AS
Contents
xiv 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
Chapter 4: Administration
NHA administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Introduction to NHA administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
In this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Introduction to starting and stopping the NHA . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Starting and stopping the NHA - overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Starting the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Starting the NHA from the command line . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Stopping and restarting the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Stopping the NHA from the NHA UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Stopping the NHA from the command line . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Restarting the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Automatic NHA restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Shutdown of the OMC-R or NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
68P02900W36-P xv
May 2008 1900.2AS
Contents
xvi 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents
68P02900W36-P xvii
May 2008 1900.2AS
Contents
xviii 68P02900W36-P
1900.2AS May 2008
List
of
Figures
List of Figures
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P xix
May 2008 1900.2AS
List of Figures
xx 68P02900W36-P
1900.2AS May 2008
List
of
Tables
List of Tables
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P xxi
May 2008 1900.2AS
List of Tables
xxii 68P02900W36-P
1900.2AS May 2008
About
This
Manual
This manual provides information about the Network Health Analyst (NHA) product.
• Chapter 1 provides an overview of the product and describes the mechanisms used by the
NHA to analyze GSM network data. It gives some examples of problems detected by the
NHA and provides details of the NHA cell grouping function.
• Chapter 2 describes how the NHA user interfaces are run. It describes the Problem
window and menu options, the In Service Monitor (INSM) tool, configuration options, and
methods for editing Knowledge.
• Chapter 3 describes the problems detected by the NHA. It includes an overview of the
problem, the detection method and default threshold settings, a list of possible causes,
and the default problem clearing time-outs.
• Chapter 4 describes the administrative procedures performed on the NHA; some relate to
system administration and others to NHA configuration.
NOTE
The Network Health Analyst supports N-1 OMCRs and N-2 BSSs. In other words
the GSR9 (1900) NHA is able to monitor:
68P02900W36-P 1
May 2008 1900.2AS
Revision history
Revision history
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The following shows the issue status of this manual since it was first released.
Version information
Manual
Date of issue Remarks
issue
M Jul 2004 GSM Software Release 7 Half-Rate
N Nov 2006 GSM Software Release 8 (1800.2GS)
P Nov 2007 GSM Software Release 9 (1900.1GS)
P May 2008 GSM Software Release 9 (1900.2AS)
Service
CMBP Number Remarks
Request
NA NA NA
NA NA NA
2 68P02900W36-P
1900.2AS May 2008
General information
General information
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Motorola cellular communications documents are intended to instruct and assist personnel in
the operation, installation and maintenance of the Motorola cellular infrastructure equipment
and ancillary devices. It is recommended that all personnel engaged in such activities be
properly trained by Motorola.
Motorola disclaims all liability whatsoever, implied or express, for any risk of damage, loss or
reduction in system performance arising directly or indirectly out of the failure of the customer,
or anyone acting on the customer's behalf, to abide by the instructions, system parameters,
or recommendations made in this document.
These documents are not intended to replace the system and equipment training offered by
Motorola. They can be used to supplement and enhance the knowledge gained through such
training.
NOTE
If this document was obtained when attending a Motorola training course, it will
not be updated or amended by Motorola. It is intended for TRAINING PURPOSES
ONLY. If it was supplied under normal operational circumstances, to support a major
software release, then corrections are supplied automatically by Motorola and posted
on the Motorola customer website.
Cross references
References made to external publications are shown in italics. Other cross references,
emphasized in blue text in electronic versions, are active links to the references.
This document is divided into numbered chapters that are divided into sections. Sections are
not numbered, but are individually named at the top of each page, and are listed in the table of
contents.
Text conventions
The following conventions are used in the Motorola cellular infrastructure manuals to represent
keyboard input text, screen output text, and special key sequences.
Input
Output
68P02900W36-P 3
May 2008 1900.2AS
Text conventions
CTRL-c or CTRL+C Press the Ctrl and C keys at the same time.
CTRL-SHIFT-c or Press the Ctrl, Shift, and C keys at the same time.
CTRL+SHIFT+C
ALT-f or ALT+F Press the Alt and F keys at the same time.
ALT+SHIFT+F11 Press the Alt, Shift and F11 keys at the same time.
¦ Press the pipe symbol key.
RETURN or ENTER Press the Return or Enter key.
4 68P02900W36-P
1900.2AS May 2008
Contacting Motorola
Contacting Motorola
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
24–hour support
If you have problems regarding the operation of your equipment, contact the Customer Network
Resolution Center (CNRC) for immediate assistance. The 24–hour telephone numbers are listed
at https://mynetworksupport.motorola.com. Select Customer Network Resolution Center
contact information. Alternatively if you do not have access to CNRC or the internet, contact
the Local Motorola Office.
Send questions and comments regarding user documentation to the email address:
mydocs@motorola.com.
Errors
To report a documentation error, call the CNRC (Customer Network Resolution Center) and
provide the following information to enable CNRC to open an SR (Service Request):
• The document type
68P02900W36-P 5
May 2008 1900.2AS
Security advice
Security advice
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Motorola systems and equipment provide security parameters that can be configured by the
operator based on their particular operating environment. Motorola recommends setting and
using these parameters following industry recognized security practices. Security aspects
to be considered are protecting the confidentiality, integrity, and availability of information
and assets. Assets include the ability to communicate, information about the nature of the
communications, and information about the parties involved.
Contact the Customer Network Resolution Center (CNRC) for assistance. The 24–hour
telephone numbers are listed at https://mynetworksupport.motorola.com. Select Customer
Network Resolution Center contact information, from the menu located to the left of the
Login box. Alternatively if you do not have access to CNRC or the internet, contact the Local
Motorola Office.
6 68P02900W36-P
1900.2AS May 2008
Warnings, cautions, and notes
The following describes how warnings and cautions are used in this document and in all
documents of this Motorola document set.
Warnings
Warnings precede instructions that contain potentially hazardous situations. Warnings are
used to alert the reader to possible hazards that could cause loss of life or physical injury. A
warning has the following format:
WARNING
Warning text and consequence for not following the instructions in the warning.
Cautions
Cautions precede instructions and are used when there is a possibility of damage to systems,
software, or individual items of equipment within a system. However, this damage presents
no danger to personnel. A caution has the following format:
CAUTION
Caution text and consequence for not following the instructions in the caution.
Notes
NOTE
Note text.
68P02900W36-P 7
May 2008 1900.2AS
Safety
Safety
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
General safety
NOTE
Refer to Grounding Guideline for Cellular Radio Installations – 68P81150E62.
• Using non-Motorola parts for repair could damage the equipment or void warranty.
Contact Motorola Warranty and Repair for service and repair instructions.
Electromagnetic energy
Relevant standards (USA and EC) applicable when working with RF equipment are:
• ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to Human Exposure
to Radio Frequency Electromagnetic Fields, 3 kHz to 300 GHz.
• Directive 2004/40/EC of the European Parliament and of the Council of 29 April 2004 on
the minimum health and safety requirements regarding the exposure of workers to the
risks arising from physical agents (electromagnetic fields) (18th individual Directive within
the meaning of Article 16(1) of Directive 89/391/EEC).
8 68P02900W36-P
1900.2AS May 2008
Caring for the environment
The following information describes national or regional requirements for the disposal of
Motorola supplied equipment and for the approved disposal of surplus packaging.
Contact the Customer Network Resolution Center (CNRC) for assistance. The 24–hour
telephone numbers are listed at https://mynetworksupport.motorola.com. Select Customer
Network Resolution Center contact information. Alternatively if you do not have access
to CNRC or the internet, contact the Local Motorola Office.
In EU countries
The following information is provided to enable regulatory compliance with the European Union
(EU) directives identified and any amendments made to these directives when using Motorola
equipment in EU countries.
European Union (EU) Directive 2002/96/EC Waste Electrical and Electronic Equipment (WEEE)
Do not dispose of Motorola equipment in landfill sites. In the EU, Motorola in conjunction
with a recycling partner ensures that equipment is collected and recycled according to the
requirements of EU environmental law.
European Parliament and Council Directive 94/62/EC Packaging and Packaging Waste
Do not dispose of surplus packaging in landfill sites. In the EU, it is the individual recipient’s
responsibility to ensure that packaging materials are collected and recycled according to the
requirements of EU environmental law.
In non-EU countries
In non-EU countries, dispose of Motorola equipment and all surplus packaging in accordance
with national and regional regulations.
68P02900W36-P 9
May 2008 1900.2AS
CMM labeling and disclosure table
The People’s Republic of China require that our products comply with China Management
Methods (CMM) environmental regulations. (China Management Methods refers to the
regulation Management Methods for Controlling Pollution by Electronic Information Products.)
Two items are used to demonstrate compliance; the label and the disclosure table.
• Logo 2 means that the product may contain substances in excess of the maximum
concentration value for materials identified in the China Management Methods regulation,
and has an Environmental Friendly Use Period (EFUP) in years, fifty years in the example
shown.
Logo 1 Logo 2
The Environmental Friendly Use Period (EFUP) is the period (in years) during which the Toxic
and Hazardous Substances (T&HS) contained in the Electronic Information Product (EIP)
will not leak or mutate causing environmental pollution, or bodily injury from the use of the
EIP. The EFUP indicated by the Logo 2 label applies to a product and all its parts. Certain
field-replaceable parts, such as battery modules, can have a different EFUP and are marked
separately.
The Disclosure table is intended only to communicate compliance with China requirements.
It is not intended to communicate compliance with EU RoHS or any other environmental
requirements.
10 68P02900W36-P
1900.2AS May 2008
Motorola document set
The Motorola document sets provide the information to operate, install, and maintain the
Motorola equipment.
With internet access available, to view, download, or order documents (original or revised), visit
the Motorola Lifecycles Customer web page at https://mynetworksupport.motorola.com, or
contact your Motorola account representative.
Without internet access available, order hard copy documents or CD-ROMs with your Motorola
Local Office or Representative.
If Motorola changes the content of a document after the original printing date, Motorola
publishes a new version with the same part number but a different revision character.
A banner (oversized text on the bottom of the page, for example, PRELIMINARY — UNDER
DEVELOPMENT) indicates that some information contained in the document is not yet approved
for general customer use.
Data encryption
In order to avoid electronic eavesdropping, data passing between certain elements in the
network is encrypted. In order to comply with the export and import requirements of particular
countries, this encryption occurs at different levels as individually standardized, or may not be
present at all in some parts of the network in which it is normally implemented. The document
set, of which this document is a part, covers encryption as if fully implemented. Because the
rules differ in individual countries, limitations on the encryption included in the particular
software being delivered, are covered in the Release Notes that accompany the individual
software release.
68P02900W36-P 11
May 2008 1900.2AS
Data encryption
12 68P02900W36-P
1900.2AS May 2008
Chapter
68P02900W36-P 1-1
May 2008 1900.2AS
Overview of the NHA Chapter 1: Overview of the NHA
The NHA is an advanced data analysis product that is used to detect faults in an operational
GSM network as illustrated in Figure 1-1.
NOTE
The Network Health Analyst supports N-1 OMCRs and N-2 BSSs. In other words
the GSR9 (1900) NHA is able to monitor:
The NHA performs a real-time analysis of event and statistic information to detect faults,
covering areas such as:
• Call success rate
Fault detection is based on monitoring events and statistics over a period of time until a clear
trend can be seen. The NHA moderates the normal statistical variations in any given statistic
and improves its fault reporting accuracy.
In addition to fault detection, the NHA attempts to establish the root cause of the problem by
further analysis of configuration statistics and event data.
1-2 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Introduction to the NHA
The NHA also provides additional information about the problem cell, such as statistics history,
event history, and line of reasoning.
N
O
H
M
A
C
68P02900W36-P 1-3
1900.2AS May 2008
Problem detection and monitoring Chapter 1: Overview of the NHA
This chapter outlines the mechanisms used by the NHA to detect and identify causes of problems
in a GSM network. It provides information about the following topics:
• Problem detection process on page 1-5
1-4 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detection process
The problem detection process is best summarized by the example illustrated in Figure 1-2. It
consists of four distinct stages: detection, confirmation, cause analysis, and corrective action.
Detection
The detection process incorporates Event Analysis where the NHA detects patterns in the
events and alarms received by the OMC that indicate problems of which the OMC operator may
not be aware. This process also includes Intelligent performance monitoring where the OMC
performance management database is monitored for anomalous sets of statistics.
If these anomalous patterns of events and anomalous sets of statistics exceed the threshold
settings, then the anomaly is further analyzed at the confirmation stage.
Conrmation
The confirmation stage of the process filters out anomalies that are not real problems and does
not report causes already known to the operator. For example, the Low Call Activity problem is
not raised if it is evident that the cell is OOS.
The monitoring schedule feature is also implemented in the Confirmation phase. If this feature
is turned on, then certain NHA problem types (for example, Very Low Call Activity in Cell)
are prevented from being raised at particular (configurable) times of the day. For further
information about setting up this feature, refer to NHA Monitoring Schedule on page 4-55.
Cause analysis
The cause analysis stage of the process identifies the specific cause of the problem. At this stage,
the NHA explores known causes and runs a series of tests to identify the most probable cause.
Corrective action
The Corrective Action stage of the process provides instructions to the operator on how to fix
the underlying problem. Corrective Action can include instructions and/or suggestions for the
operator to manually narrow down the cause (tests that cannot be performed by the NHA).
68P02900W36-P 1-5
1900.2AS May 2008
Devices monitored by NHA Chapter 1: Overview of the NHA
Currently, the NHA only monitors devices that are in the OMC CM MIB. Thus it only detects
problems on those devices. If new cells are added to the network or sites are reparented, the
NHA does not monitor the new equipment until the OMC CM MIB is updated by performing
an audit.
1-6 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Devices monitored by NHA
PROBLEM TO US ER INTERFACE
CORRECTIVE ACTION
CAUSE
CAUSE ANALYS IS
PROBLEM
CONFIRMATION
ANOMALY
DETECTIO N
68P02900W36-P 1-7
1900.2AS May 2008
NHA detection mechanisms Chapter 1: Overview of the NHA
NHA detectors use the following detection mechanisms to find problems in a network:
• Daily Roll-up on page 1-9
1-8 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Daily Roll-up
Daily Roll-up
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The Daily Roll-up detection mechanism is used to detect problems based on a 24-hour summary.
This detection mechanism monitors the performance of a cell over a day, from midnight to
midnight, and only raises the problem after midnight.
Problems detected using Daily Roll-up provide a useful analysis of network performance over
the long term. A minimum sample size is used to prevent false alarms, that is, to avoid raising
problems if a cell has carried little traffic, for example, if a cell was out-of-service for most
of the day.
Detector components
Formula
Detection
68P02900W36-P 1-9
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA
midnight to midnight
1-10 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Fixed Threshold
Fixed Threshold
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The Fixed Threshold detection mechanism is used to detect problems for the last interval,
therefore the problem is raised straight away. This detection mechanism is straightforward to
execute and allows for fast problem detection.
Use this detection mechanism for problems like TCH Blocking where there is a lot of activity
on the cell.
Detector components
Formula
Detection
68P02900W36-P 1-11
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA
1-12 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sample Roll-up
Sample Roll-up
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The Sample Roll-up detection mechanism is used to detect problems over one or more intervals.
This detection mechanism looks back over recent intervals until a minimum sample size is
reached - a problem is then raised. The number of intervals is restricted to a maximum of 24.
Sample Roll-up reports problems quickly and limits the number of false alarms. However, if the
sample size is set too high, very quiet cells can be ignored.
Detector components
Formula
Detection
68P02900W36-P 1-13
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA
1-14 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Interval Roll-up
Interval Roll-up
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The Interval Roll-up detection mechanism is used to detect problems over a set number of
intervals.
This detection mechanism does not report problems as quickly as the fixed threshold detector
but it reduces the chances of false alarms. It monitors cells over short periods and reports
problems based on an average value for a number of hours.
If the network has 30-minute statistics intervals, then the NHA rolls up two statistics intervals
per hour.
Detector components
Formula
Detection
68P02900W36-P 1-15
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA
1-16 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sliding scale
Sliding scale
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The sliding scale detection mechanism looks at the latest interval. Thresholding against a
sliding scale takes the number of samples acquired for the formula into account. It increases the
needed threshold level for a greater than (>) comparison, or decreases the needed threshold
level for a less than (<) comparison for a smaller number of samples.
Detector components
If the threshold is reached, a problem is raised. If it is raised for the same cell, 3 out of 3
intervals in a row, the problem is confirmed. Refer to Figure 1-7 and Figure 1-8 for examples.
68P02900W36-P 1-17
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA
55 Threshold
High Sample Reached
Threshold
Threshold
NOT
Reached
5
Low Sample
Threshold
50 1000
Low Sample High Sample
Size Size
55
High Sample Threshold
Threshold NOT
Reached
Threshold
25 Reached
Low Sample
Threshold
75 400
Low Sample High Sample
Size Size
1-18 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Long-term detection
Long-term detection
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Long term detectors can show statistical trends over a long period, as well as recent changes
in performance compared with the average. They are used to find cases where performance
degrades over several days or weeks without the impact being severe enough to trigger an
existing short-term or daily NHA detector.
The main difference between this detector and other NHA detection mechanisms is that there
is no absolute threshold defined. Instead, the current performance is compared to what is
expected for a particular cell based on past data.
• Regression analysis, which attempts to fit a straight line through the data and determine if
the values are increasing or decreasing over time.
The first method detects sudden changes in performance while the second detects more gradual
changes.
Long term detectors are implemented using external scripts. The long-term statistical data used
by the detectors is generated by a script that calculates daily key statistics and stores them for
up to 60 days. By default, these scripts do not generate NHA problems but produce reports
which can be accessed from the NHA web server.
For further information about long term detection, refer to Script based problems on page
3-152.
68P02900W36-P 1-19
1900.2AS May 2008
Event pattern analysis Chapter 1: Overview of the NHA
Event-based problems are detected using patterns of events, for instance, the Repeated DRI
Failure problem is detected when a pattern of more than four DRI states change over a 24-hour
period. See the Problem guide on page 3-2 for more details of all problems.
Currently, it is not possible to configure these detectors, either to turn them on or off.
Furthermore, it is not possible to change the number of events or the time period to control
how the detectors are triggered.
1-20 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA problem clearing mechanisms
Operators can manually clear problems on the NHA (on the Problem window) or the problems
can be left to clear automatically when the NHA determines that they are no longer issues. Once
the problems are cleared, they are removed from the User Interface within 30 minutes.
The NHA uses seven different methods for determining that problems are no longer issues,
depending on the following problem types:
• Knowledge based clearance
The Problem Guide indicates which clearance method is used for each problem type.
For some methods, the NHA relies on the problem not repeating within a certain time-out.
These time-outs are controlled by variables which are defined in the NHA configuration file for
each OMC (/usr/gsm/OMCs/<omcname>/config/ea.cfg). For further information, refer to
NHA configuration files (ea.cfg).
NOTE
The NHA also clears problems are also cleared when the maximum number of
problems for a particular OMC is reached. For further information, refer to NHA
troubleshooting in the Administration chapter.
In some cases, the NHA can determine, using knowledge implemented in the software, that
the issue can be cleared. For example, for Database Upload Required problems, the NHA
clears the problem when a successful database upload event is received. The NHA user cannot
adjust or configure this clearance method.
68P02900W36-P 1-21
1900.2AS May 2008
Default event based clearance Chapter 1: Overview of the NHA
The EVENT-EXP-TIMEOUT is the time-out in hours for clearing problems that are detected
typically from event patterns, for example, Repeated Cell Outage, GCLK Recalibration required.
It is independent of what day of the week the problem was last detected. The default setting is
25 hours.
Formula:
Time for clearing = Time problem was last reported + EVENT-EXP-TIMEOUT
For example, GCLK Recalibration required problem last reported at 13:15 on Monday clears at
approximately 14:15 on Tuesday if it does not repeat.
These problems are cleared after 1.5 statistics intervals. The time-out is not configurable. This
problem clearing method is used for problems reported in EVERY statistics interval until the
problem is fixed, for example, when no statistics are being received from a site. The idea is that
these problems should be cleared as soon as they are resolved.
Formula:
Time for clearing = Time problem was last reported + 1.5 * (statistics interval length)
For example, if the problem does not repeat in the meantime and assuming that the statistics
interval for the BSS is 30 minutes, a No Statistics from Site last reported on Monday at 13.21
clears on Monday at 14.06.
The VERY-EXP-TIMEOUT value is the time-out in hours for clearing problems, detected typically
by the Interval Roll-up detection mechanism. These are problems where the issue is not
necessarily expected to repeat at the same time every day. It is used for most of the Very
type of problems, for example, Very High Dropped Call Rate, Very Low Call Success Rate. It
is cleared independently of the day of the week the problem was last detected. The idea is
that these problems are cleared as soon as they are resolved to avoid cluttering the Problem
UI. The default setting is six hours.
Formula:
Time for clearing = Time problem was last reported + VERY-EXP-TIMEOUT.
For example, a Very Low Call Success Rate problem last reported at 13:22 on Monday clears at
approximately 19:22 on Monday, if it does not repeat.
These seven time-outs in the form XXX-DAILY-EXP-TIMEOUT (XXX corresponds with MON,
TUE, WED, THU, FRI, SAT, SUN) are specific time-outs as defined for a particular day in the
week. Time-outs are in hours for clearing problems detected, typically by the Daily Roll-up
detection mechanism. For example, High Daily Dropped Call Rate, Low Daily Immediate
Assignment Success Rate.
1-22 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Default hourly clearance
A different time-out is provided for each day of the week so that the NHA can be configured
not to clear daily problems that fail to repeat on weekend days. As daily problems are raised
at approximately 00:25 on the next day, these problems get cleared if they do not repeat on
the next working day at approximately 01:25.
The default settings are 25 hours for Monday, Tuesday, Wednesday, Thursday, and Friday; 73
hours for Saturday and 49 hours for Sunday. These settings can be adjusted if local customs are
to have the weekends on days other than Saturday and Sunday.
Formula:
Time for clearing = Time problem was last reported + XXX-DAILY-EXP-TIMEOUT (Day last
reported)
For example, a High Daily Dropped Call Rate problem (on Tuesday) is reported at 00:25 on
Wednesday and clears at approximately 01:25 on Thursday, if it does not repeat. (25 hour
Wednesday time-out is used).
For example, a Low Daily Immediate Assignment Success Rate problem (on Friday) is reported
at 00:25 on Saturday and clears at approximately 01:25 on Tuesday, if it does not repeat.
(73-hour Saturday time-out is used.)
HOURLY-EXP-TIMEOUT is the time-out in hours for clearing lower urgency non-daily problems
where the issue is not necessarily expected to repeat at the same time every day but is wanted
on daily reports. It is currently used for the High Handover Attempt Rate problems. For
example, High Handover Attempt Rate - Uplink Quality. This problem is cleared independently
of what day of week the problem was last detected. The default setting is 25 hours.
Formula:
Time for clearing = Time problem was last reported + HOURLY-EXP-TIMEOUT
For example, a High Handover Attempt Rate, Uplink Quality problem last reported at 13:22 on
Friday clears at approximately 14:22 on Saturday, if it does not repeat.
Problems cleared by this clearance method are cleared at approximately 23:00 on the next
working day if they fail to repeat. This clearance mechanism is used for congestion and blocking
type problems, for example, Very High TCH Blocking, High SDCCH Congestion. The reason is
that these problems typically happen over a short period of time but can repeat at the same time
every day (or every working day). The intention is to leave them on the user interface until a full
working day has passed. This method also makes use of the XXX-DAILY-EXP-TIMEOUT so that
the next working day is correctly calculated.
Formula:
Time for clearing = Time problem was last reported + XXX-DAILY-EXP-TIMEOUT (Day
after day last reported) rounded up to 23:00
For example, a High SDCCH Congestion problem last reported at 13:25 on Tuesday clears at
approximately 23:00 on Wednesday, if it does not repeat.
For example, a Very High TCH blocking problem last reported at 13:25 on Friday clears at
approximately 23:00 on Monday, if it does not repeat.
68P02900W36-P 1-23
1900.2AS May 2008
Automatic blacklisting Chapter 1: Overview of the NHA
Automatic blacklisting
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The purpose of automatic blacklisting is to automatically blacklist devices when they are no
longer carrying traffic. The NHA automatically removes these devices from the blacklist once
they start to carry traffic, that is, once they satisfy the removal criteria.
Currently, only one blacklist exists across all the UIs. In addition to the existing functionality,
where users can add devices to the blacklist from the Configuration Report using the INSM tool,
they can now add devices to the blacklist from the Problem window and Cell View window.
When a newly installed NHA is first started up on an OMC, a report listing all equipment that
has not carried traffic over the last number (X) of days is produced. The path to the report is
/usr/gsm/OMCs/<omcname>/ea_logs/ blacklist.csv. This file is automatically imported into
the NHA blacklist. From then on, the blacklist is automatically maintained.
X is configured through the OMC-specific ea.cfg file; the default value is four days. However, if
a device is less than four days old, the value of X is equal to the age of the device. A cell has not
carried any traffic if the busy_tch_mean parameter has had a constant value of zero for four
consecutive days. This information can be found in the PM database.
NHA monitors new devices and new network components are automatically blacklisted using the
INSM tool. Any changes to existing components are continually monitored and are propagated
to the NHA UI. The NHA monitors these devices every two hours by default and, if they are
carrying traffic, they are automatically removed from the blacklist. The NHA aims not to report
problems from dummy cells until it starts carrying traffic.
If a device is blacklisted, all its contained devices are automatically blacklisted, if not already
blacklisted. For example, if a site is blacklisted then its contained cells are automatically
blacklisted. If the site is removed from the blacklist, then all its cells are automatically removed
from the blacklist.
A device is automatically removed from the blacklist if it is carrying traffic for 75% of the last 12
hours, or for as long as the device has existed (this caters for reparented devices). This 12-hour
value is configurable through the ea.cfg file.
Devices can be manually added to and removed from the blacklist through the NHA UI and the
INSM tool. Refer to the sections Manually blacklisting a device on the network display on
page 2-95 and Blacklisting devices on page 2-157. Devices can be exported or imported to
or from a text file from the NHA UI.
1-24 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA detection examples
The following illustration (Figure 1-9) outlines the range of problems that can occur during
the call process.
To understand the nature of the GSM call process, consider the analogy of a long pipe to
represent the route a call must make before "ringing" at the other end.
During its journey, a call has to negotiate a series of potential blockages along the route,
each representing a possible fault in the network. The NHA concentrates on these potential
blockages and reads the statistics for each instance.
The NHA uses these statistics in its detectors which are designed to alert operators to network
faults. The various stages along the route of a call that are affected by these detectors can be
seen in the call process model as illustrated in Figure 1-9. A complete list of NHA detectors
is provided in Chapter 3, Problem Guide.
68P02900W36-P 1-25
1900.2AS May 2008
Example of a network fault Chapter 1: Overview of the NHA
The Immediate Assignment message is used to assign an SDCCH or TCH directly to a mobile.
The High Immediate Assignment Rate detector can be seen as a typical example of how the
NHA measures Immediate Assignment failures, which can include both attempts to access an
SDCCH as well as direct assignments to TCH.
This High Immediate Assignment Rate detector monitors the rate of channel (SDCCH and fast
call setup TCH) “immediate assignment” type failures. It measures the failure rate of the
Immediate Assignment command. The command is used to assign a mobile to an SDCCH or,
bypassing the SDCCH signaling, to a TCH. This means that for a significant number of times
when a channel is assigned to a mobile, the mobile does not establish communication on the
SDCCH or TCH channel as in Figure 1-10.
1-26 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Example of a network fault
• Receive a call
• Update location
When the network receives a channel request from a mobile, it allocates a channel (SDCCH or
TCH) to the mobile, then starts a timer. If the mobile fails to communicate with the network on
the assigned channel before the timer expires, the network cancels the channel assignment.
Statistics are pegged by the BSS for each attempt to access an SDCCH or TCH and also for
each failure. These statistics are passed to the OMC-R and then to the NHA for use in detecting
whether a large proportion of SDCCH or TCH channel assignments fail in this manner for a
particular cell.
A formula defined in the NHA is used to detect this problem and is written as:
For further information about this detector and the exact statistics used, refer to High
immediate assignment failure rate on page 3-26.
68P02900W36-P 1-27
1900.2AS May 2008
Examples of the NHA detecting network faults Chapter 1: Overview of the NHA
The NHA provides two detectors for High Immediate Assignment Failure Rate problems:
• High Daily Immediate Assignment Failure Rate
This problem is detected on a daily basis using the Daily Roll-up detection mechanism
(refer to Daily Roll-up on page 1-9). It is cleared using the default daily type clearance
mechanism (refer to NHA problem clearing mechanisms on page 1-21).
This problem is detected over a shorter period using the Sample Roll-up detection
mechanism (refer to Sample Roll-up on page 1-13). It is cleared using the default hourly
clearance mechanism (refer to NHA problem clearing mechanisms on page 1-21).
Typically, Daily Roll-up problems are designed to detect network issues that can be addressed
within a day. Sample Roll-up problems are designed to detect network faults that need an
immediate response. Thresholds and minimum sample sizes can be configured per cell group
appropriately for the network in question. Typically, Sample Roll-up detectors have higher
minimum sample sizes (to avoid false alarms) and higher thresholds for failures than Daily
Roll-up detectors.
Shortly after midnight every day, the High Daily Immediate Assignment Failure Rate detector
calculates the Immediate Assignment Failure Rate using statistics for the previous 24 hours.
In this example, the threshold is 30% and the minimum sample size is 500. If both of these
figures are exceeded for any cell (that is, more than 500 attempts and more than 30% failure),
then NHA raises a High Daily Immediate Assignment Failure Rate problem against that cell.
In Figure 1-11, for example, the network fault began on Day 1 and degraded to bad by Day 2.
The NHA raised a problem shortly after midnight on Day 3 and the NHA cleared the problem
shortly after 1:00 AM on Day 4.
Threshold
30%
1-28 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Examples of the NHA detecting network faults
Every statistics interval, the Very High Immediate Assignment Failure Rate detector calculates
the Immediate Assignment Failure Rate formula using statistics for the previous intervals and
rolls up those statistics until the minimum sample size is met.
In this example, the threshold is 60% and the minimum sample size is 1000. If both of these
figures are exceeded for any cell (that is, more than 1000 attempts and more than 60% failures
for the intervals used in getting to 1000 attempts), the NHA raises a Very High Immediate
Assignment Failure Rate problem against that cell.
In Figure 1-12, it can be seen that the network fault started at 8:10 and that the NHA raised a
problem at 9:20. The fault was resolved by 12:10 and the problem cleared by the NHA at 19:20.
60%
68P02900W36-P 1-29
1900.2AS May 2008
Cell grouping in the NHA Chapter 1: Overview of the NHA
The NHA is shipped with a set of default groups. (Refer to Table 1-1 for a description of each
group. Figure 1-13 illustrates the default cell groups.) Each is configured with loose thresholds
which apply equally to all cells. These groups can be tuned to suit the network after the operator
gets a better idea of the number and type of problems being raised.
When the NHA is started, it automatically places all the cells in the DEFAULT cell group. Also, if
any new cells are added to the network, they are automatically added to the DEFAULT cell group.
One of the first steps in retuning the NHA is to set up cell groups so that different thresholds
can be applied to cells of different type.
To create a preliminary grouping of cells, refer to Using the cell grouping script on page
4-57.
For further information on cell grouping, including automatic and manual cell grouping see
Using the NHA, Chapter 2.
NOTE
Any number of cell groups can be created using the Group Properties option in the
Configure menu. However, a cell can only exist in one group at a time. For further
information about creating a cell group, refer to Configuring group properties on
page 2-110.
Default Cell
Denition Example
Groups
BUSY The cell is active with a high rate of calls. Business district
NORMAL The cell has a normal rate of calls. Suburban area
QUIET The cell has a low rate of calls. Rural area
MICRO A small cell covering a specific district. Inner city
FRINGE The cell is on the edge of the network. Edge of city or
country
DEFAULT These cells are configured as a NORMAL cell group. Suburban area
1-30 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Manual and Automatic cell grouping
When creating a cell group, use the Cell Grouping drop-down list to define whether the new
group is manually or automatically grouped.
For further information on cell grouping see Using the NHA, Chapter 2.
BUSY
FRINGE
QUIET
Default
MICRO threshold
values
DEFAULT
68P02900W36-P 1-31
May 2008 1900.2AS
Manual and Automatic cell grouping Chapter 1: Overview of the NHA
1-32 68P02900W36-P
1900.2AS May 2008
Chapter
68P02900W36-P 2-1
May 2008 1900.2AS
Using the NHA Chapter 2: Using the NHA
Once the NHA is configured and started using the NHA start command (refer to Starting
the NHA on page 4-5), it begins analyzing statistics, configuration and event data to detect
problems. Confirmed problems are displayed on the Problem window. In addition, the status of
devices can be seen using the In Service Monitor (INSM) tool.
Problem detection thresholds and cell groupings are modified using the Configure menu
options on the user interface. Knowledge can also be added, using the external interfaces
for detectors, causes and actions.
In this chapter
2-2 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Starting the NHA user interface
The following describes the normal way of starting the UI on a GUI server or client.
Click the CDE desktop background and select the appropriate menu option. For further
information about menu options, refer to Setting up the NHA menu option on page 4-86.
If the NHA menu options have not been set up on the GUI server or client or a remote login is
needed, do the following:
1. Remote login to the GUI server or client.
cd /usr/gsm/nhacurrent/bin
3. Enter the NHAUI command on the GUI server or client with an appropriate parameter.
./NHAUI <nhaname>
4. If more than one NHA is running on the system, select the NHA you wish to connect to.
For further information about menu options, refer to Setting up the NHA menu option
on page 4-86.
NOTE
The NHA UI clients cannot be run on the NHA or the OMC processor as they could
adversely affect the performance of these processors.
To start the NHA user interfaces from a PC, double-click the NHA icon.
68P02900W36-P 2-3
1900.2AS May 2008
NHA UI utilities Chapter 2: Using the NHA
NHA UI utilities
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Online Help
Online Help is web based and is presented in a web browser. Help is available from the user
interface through the Help menu option at the top of the screen. The online help also contains
an overview description of each of the NHA problems.
To copy text from the Problem window, highlight the text and press Ctrl+C. The text can then be
pasted to the appropriate place on the Problem window or to applications on the GUI server or
client (for example, text edit windows) or a PC (for example, Microsoft Excel), using Ctrl+V.
2-4 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Permissions and security
The NHA can be configured to allow restricted security access to various functions. NHA
operators can have full permissions, that is read/write access, or read-only access. Three types
of security levels control these two states.
The NHA UI Client Login feature allows the establishment of a secure SSH login connection
from the NHA UI client to the NHA server. From NHA GSR 9 onwards, NHA client startup
enforces this secure login to perform user authentication before the NHA UI is displayed.
The login dialog is displayed when the NHA client is started. In this dialog, the user is prompted
to enter the password to access the NHA server. The password should not be more than 127
characters. Empty password is not allowed. Maximum of 3 retries are allowed, failing which
the NHA application exits.
NOTE
The user must first create an account in the NHA server. The password to login to
the NHA UI client must be the same as the password created for the user’s account
in the NHA server.
68P02900W36-P 2-5
1900.2AS May 2008
Security access Chapter 2: Using the NHA
Security access
• Create, modify, or delete custom detectors and custom formula in the Knowledge Editor.
2-6 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Security levels
Security levels
The security levels are defined in the global NHA configuration file /usr/gsm/config/lo-
cal/ea.cfg. Three types of security levels control two states as follows:
• A security level of 0 gives all users full permissions.
• A security level of 1 gives only omcadmin users and nominated trusted-users (defined in
the ea.cfg file) full permissions. Other users have read-only permissions.
• A security level of 2 gives only omcadmin users full permissions. All other users have
read-only permissions.
Once the security levels are changed, the user omcadmin can make them active by selecting
Read ea.cfg files from the Configure menu.
NOTE
This option is not available from a PC.
User omcadmin
In addition to the NHA security levels, only the user omcadmin is able to:
• Update security levels and apply ea.cfg changes to running NHA.
68P02900W36-P 2-7
1900.2AS May 2008
The Problem window Chapter 2: Using the NHA
The Problem window displays a range of information about problems that have been reported by
the NHA. It maintains lists of active problems which can be filtered into subsets.
Lists of problems can be printed as reports or exported to a file. Exported files can be used by
third-party software, for example, spreadsheets.
In this section
This section describes the Problem window and covers the following topics:
• Using the Problem window on page 2-9
Line of reasoning
Detector information
• Viewing long term statistics and other problem information on page 2-51
2-8 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Problem window
All problems detected by the NHA are listed in the Problem window (refer to Figure 2-7).
These problems are presented in spreadsheet format. They appear asynchronously for problems
detected through event monitoring and approximately 30 minutes after a statistics interval for
problems detected through statistics monitoring.
• Displaying problems
• Managing problems
• Repeating problems
• Values of problems
• Ranking problems
Multi-OMC support
The NHA user interface enables the operator to monitor all the OMCs connected to the NHA
from one window.
68P02900W36-P 2-9
1900.2AS May 2008
Displaying problems Chapter 2: Using the NHA
Displaying problems
The Problem window displays a list of detected problems and the current subscription as in
Figure 2-2.
It also displays the following information across the bottom of the window (refer to Table 2-1):
Managing problems
Information about problems is displayed in the Problem window in spreadsheet format (refer to
Figure 2-2). The number of columns displayed on the spreadsheet can be configured using
the View menu.
2-10 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Repeating problems
Clearing problems
When an operator sets the status of a problem to Cleared, that problem is removed from the list
after one hour.
NOTE
To handle or clear more than one problem, select the problems using the Shift (or
Ctrl) key and select Handle or Clear from the Problem menu.
If too many problems are reported on the Problem window, the NHA cleans up the list by deleting
all Cleared problems first. It then reduces the numbers of each problem type down to 10 per
cent of the maximum. For further information, refer to NHA troubleshooting on page 4-21.
NOTE
Any of these forced deletions of problems are documented as Warnings in the OMC
specific Audit log file.
Manage the list of problems in the Problem window using the Filter and Sort functions. For
further information, refer to Subscriptions, sorting, and filtering on page 2-18.
Subscriptions
Subscription functionality for problem types, BSS name, and cell name allows an operator
to restrict what is shown on the Problem window on a long-term basis. This functionality is
set up from the Subscription option on the menu bar. Refer to Subscriptions, sorting, and
filtering on page 2-18.
Repeating problems
If a problem repeats, information about the problem displayed in the NHA user interface is
updated; in particular, the Value, the Last time and Repeat fields. If a problem does not repeat
within a configurable time period (the default is a working day), it is automatically cleared
from the Problem window.
To help manage the list of problems, change the status of the problems from New to Handled
to Cleared.
Values of problems
The value of the problem can indicate the severity of the problem. Usually, it is the value of the
formula used to detect the problem.
68P02900W36-P 2-11
1900.2AS May 2008
Ranking problems Chapter 2: Using the NHA
If multiple formulae and/or statistics are used to detect a problem, then the value of the problem
is the value of the first formula/statistic used. If no formulae are used in the detector, then the
value of the first statistic is displayed. The value of all other formulae/statistics used can be
found in the Detector Information window.
Ranking problems
NHA problems are ranked according to a ranking formula. The ranking value appears as a
column in the NHA Problem window and is calculated using the same formula as the one used in
the Cell Analysis Tool (CAT):
((1 - Call Success Rate) ^2 * Total Calls) / Call Setup Success Rate
This value is calculated for the interval that the NHA problem was raised. The formula can also
be written as:
((1 - (Call Setup Success Rate * (1 - (Dropped Call Rate) /100))) ^ 2 * Total
Calls) / (Call Setup Success Rate / 100)
A higher value for the ranking value of the problem can indicate a higher severity of a problem,
given that the value is higher when:
1. The Call Setup Success Rate is lower;
There are two limitations to be considered when using the ranking value to prioritize problems:
• The ranking value is only calculated for the interval that the NHA problem was raised, so
for "daily" problems the value is not useful.
• The ranking formula only covers GSM calls that are made or attempted. It does not cover
many other issues such as issues with the SDCCH or Outage issues or Handover issues or
GPRS issues.
Select the Broadcast option on the Tools menu to send a message to all other NHA users. This is
useful in the following situations:
• To warn other users before shutting down an NHA.
• If running short of UI licenses, to ask other users to close UIs if they do not need them.
• To alert other users when modifying and deleting subscriptions or when adding a useful
subscription.
2-12 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The Problem window menu options
The following overview describes the user options available in each menu on the main Problem
window.
File menu
Select To
Print displayed Print the list of problems displayed on the main Problem window.
Print selected Print selected problems on the main Problem window. The printer font
is read from the global ea.cfg file.
Export displayed Export the list of not cleared problems displayed on the main Problem
window to a file.
Exit Exit from the main Problem window.
Edit menu
Select To
Cut Currently unavailable.
Copy Copy selected problems from the list displayed on the main Problem
window.
Paste Currently unavailable.
Find Search for a particular problem in the list displayed on the main Problem
window.
68P02900W36-P 2-13
1900.2AS May 2008
Overview of menu options Chapter 2: Using the NHA
View menu
Select To
Columns View the list of problems by Problem, Value, Device, Cell Group, First, Last,
Repeats, Status, Operator, OMC, Severity, Ranking, Comment, ID, and Type.
Check or uncheck the columns required.
Font size Change the font size setting on the Problem window.
Options Set and/or save the Columns and Font size settings.
Problem menu
Select To
Handle Change the status of the following problems to Handled:
- Selected problem(s) only
- All problems on this Device
- All problems on this Site
Unhandle Change the status of the following handled problems to New:
- Selected problem(s) only
- All problems on this Device
- All problems on this Site
Clear Change the status of the following problems to Cleared:
- Selected problem(s) only
- All problems on this Device
- All problems on this Site
Unclear Change the status of the following cleared problems to New:
- Selected problem(s) only
- All problems on this Device
- All problems on this Site
Unseen Change the status of Seen problems to New.
Comment Add or modify comments for selected problems.
2-14 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Overview of menu options
Data menu
Select To
Sort Order subsets of problems on the Problem window.
Filter Select subsets of problems on the Problem window on a short-term basis.
Synchronous with the Recent Problems filter on the Problem window.
Tools menu
Select To
Knowledge Editor Bring up the Knowledge Editor for each OMC.
INSM UI Bring up the INSM tool for each OMC.
Broadcast Send a message to all other NHA users.
Cell View Launch a view where details of any cell on the network are displayed.
It is useful for launching statistics history for cells that do not have
problems.
Worst Cells View a report of the worst cells ordered by user-selected criteria.
Scoreboard View a report of the worst performing cells ordered by ranking value.
NHA Web Page Launch the NHA web page in a web browser.
Frequency Clash View a report of the Frequency clashes between cells and their
Report neighbors.
Parameter Check View a report of BSS parameters or groups of parameters that do not
Report match specified criteria.
68P02900W36-P 2-15
1900.2AS May 2008
Overview of menu options Chapter 2: Using the NHA
Congure menu
Select To
Cell Grouping Configure and view cell groups.
Group Properties Configure and view group properties.
Thresholds Configure and view detectors and thresholds.
Profile Use the Profile option to save a user profile, return to the default settings,
or return to the last saved profile.
NOTE
The Return to Last-Save option is not available if no profile has
yet been created for the current user.
BSS Regions Configure and view problems by BSS region.
Cell Regions Configure and view problems by Cell region.
Problem Configure and view problem subscriptions.
subscriptions
User Defined Configure and view user-defined causes.
Causes
Stats Per Problem Configure and view statistics per problem.
Neighbor Cell Configure and view neighbor cell statistics on the Statistics Selection
Statistics window.
Blacklist Configure and view blacklisted devices.
Daily Export Set the time of the daily export.
Report to OMC Turn on and off the reporting NHA problems to the OMC as alarms
feature.
Read ea.cfg files Activate changes after changing values in the Global or OMC Specific
Configuration files. (User omcadmin only.)
Shutdown menu
Select To
OMC Shutdown Shut down an NHA for a particular OMC. (User omcadmin only.)
2-16 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Overview of menu options
Help menu
Select To
Contents Display the online Help Contents window.
Overview Display online Help for using the NHA.
Using the Problem Display online Help for the Problem window.
window
Connections Display the connections status.
About Currently unavailable.
68P02900W36-P 2-17
1900.2AS May 2008
Subscriptions, sorting, and ltering Chapter 2: Using the NHA
Subscriptions enable users to set up and manage lists of problems on the Problem window.
Users can prioritize specific network problems to be monitored in two ways:
• Using Regions, consisting of a set of BSSs or Cells to be monitored.
Lists of problems can also be filtered and sorted on the Problem window using the following
menu options:
• Filter
• Sort
The Regions option is used to monitor problems on a defined subset of BSSs or specific cells.
The default ALL-REGIONS list includes all the BSSs/RXCDRs from all OMCs in the network.
To view problems that are active in a region, click the ALL-REGIONS button to open the Region
window. Select the required region to be monitored from the list presented. The Problem
window is then updated to show the active problems that match the BSSs of the selected
region or the specific cells.
To create a region to be monitored, select BSS Regions or Cell Regions from the Configure
menu and click New. To view and modify a region, select BSS Regions or Cell Regions
from the Configure menu and select the required region from the list displayed. For further
information on creating, viewing or modifying a region, refer to Configuring BSS Regions on
page 2-139 and Configuring Cell Regions on page 2-142.
The ALL-PROBLEMS option is used to monitor a defined subset of problem types. For example,
it is possible to create and monitor a problem subscription list which covers all problems
in a specific geographical area. A subscription list consists of Problem Types. The default
subscription list ALL-PROBLEMS includes all possible problem types.
2-18 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Filtering problems
To view problems that are active in a subscription, click the ALL-PROBLEMS button to open the
Problem Subscription window. Select the required subscription from the list presented. The
Problem window is then updated to show the active problems that match the Problem types of
the selected subscription.
Filtering problems
The Filter option is used to select and order subsets of problems on the Problem window on a
short-term basis. To display the Filter window (refer to Figure 2-3), select the Filter option
from the Data menu or click the Filter button.
68P02900W36-P 2-19
1900.2AS May 2008
Filtering problems Chapter 2: Using the NHA
2-20 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Filtering problems
Inc. Include
Exc. Exclude
Bef. Before
Aft. After
Activate the OMC filter by clicking the Inc or Exc option. The OMC list is displayed.
• Problem status
Activate the Problem status filter by clicking the Inc or Exc option. The Problem status list
(New, Handled, Cleared, and Seen) is displayed.
• Severity
Activate the Severity filter by clicking the Inc or Exc option. The Severity list (for example,
Critical, Major, Minor, and Warning) is displayed.
Activate the First Time/Last Time filter by clicking the Bef. or Aft. option. The Start/End
Time Date and Time data fields are displayed.
Last 65 mins
These options enable users to quickly view recent problems, for example, in the last hour,
and keep that filter applied in real time so that the NHA can show problems that have
happened or repeated in the last hour. They are synchronized with the options on the
Recent Problems pull-down menu on the Problem window so if, for example, "Last 35 mins"
is set” is set on the Filter window, the Recent Problems filter on the Problem window also
displays the current selection as "Last 35 mins".
• Device class
Activate the Device class filter by clicking the Inc or Exc option. The Device class list (for
example, Site, Cell, BSS, Neighbor) is displayed.
• Cell group
Activate the Cell group filter by clicking the Inc or Exc option. The Cell group list (for
example, QUIET, NORMAL, BUSY) is displayed.
• Device name
Activate the Device name filter by clicking the Inc or Exc option. The Device name list is
displayed.
68P02900W36-P 2-21
1900.2AS May 2008
Using the Recent Problems lter Chapter 2: Using the NHA
Activate the Problem type filter by clicking the Inc or Exc option. This opens the Problem
type list.
If text is entered in the Problem Name text field, then the Problem type list is disabled
and the filter is based on the substring entered. If no text is entered, then problem list is
enabled and the filter is on the problem selected from the Problem type list.
When the Problem Type and Value Filter option is selected, the Problem Name text field
and Problem type list are disabled. Launch the Problem Type and Value Filter window by
clicking the Edit button.
• Cause
Activate the Cause filter by clicking the Inc or Exc option. The Cause list is displayed.
If text is entered in the Cause text field, then the Cause list is disabled and the filter is
based on the substring entered. If no text is entered, then the cause list is enabled and the
filter is on the cause selected from the Problem type list.
• Comment
Activate the Comment filter by clicking Filter by keyword or Problems with comment
or Problems without comment. Text entered in the Comment text field is used as the
keyword for filtering comment contents. Select Inc to list problems whose comment
content contains the keyword, or select Exc to list problems whose comment content does
not contain the keyword. If no keyword is entered, no filtering occurs.
The Recent Problems filter provides a pull-down menu on the Problem window. It displays the
filtering mode to which the NHA is currently set and enables users to set the recent problems
mode quickly. These settings enable users to view recent problems on the NHA in real time.
The following options can be selected from the pull down menu:
• Last 35 mins
• Last 65 mins
2-22 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sorting problems
If the Aft or Before choice is selected from the Filter window, for example, if “Aft. 2006/03/21
17:15” is set on the Filter window, then the Recent Problems filter on the Problem window
also displays the current selection as “Aft. 2006/03/21 17:15”. This additional menu choice is
removed if the user chooses another setting from the Filter window or the Recent Problems pull
down menu on the Problem window.
Sorting problems
The Sort option is used to select subsets of problems on the Problem window.
1 To display the Sort window (refer to Figure 2-4), select the Sort
option from the Data menu or click the Sort button on the NHA UI.
Continued
68P02900W36-P 2-23
1900.2AS May 2008
Sorting problems Chapter 2: Using the NHA
2 Select primary and secondary sort criteria to be applied to the problem list.
3 Click OK to sort the problems according to the selected criteria.
If the None option is selected from the secondary criteria, the problems
are sorted according to the primary criteria only. The default sort order is
first by problem and then by value.
2-24 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Filtering problem types and values
The Problem Type and Value Filter enables users to configure a problem value filter on
problems in the current problem subscription. In addition, users can filter a particular problem
in a subscription by selecting the option to either display or not display the problem in the
Problem window. The system remembers the user’s configured Problem Type and Value filter
profile per the NHA client machine. The profile is restored when the Problem Type and Value
Filter window is opened.
To open the Problem Type and Value Filter window, select the Problem Type and Value Filter
radio button. Click the Edit button in the Problem Type and Value section in the Filter window.
All problems in the current problem subscription are loaded into the Problem Type and Value
Filter window. The user's problem type and value filter profile is read from the problem filter
properties file .NHA.problemfilter.properties. The default setting is used for a new problem
or if an error is encountered when reading the properties file.
NOTE
The user has to save the configuration to create .NHA.problemfilter.properties in
the home directory of the NHA UI client machine. Otherwise, a file not found error
is encountered during NHA UI startup.
NOTE
To display a user-created problem on the Problem Type and Value Filter
window, add the problem name as a line to the global configuration file
/usr/gsm/config/customer/extprobs.txt. Refer to Introduction to external
scripts on page 2-180 for information about adding a problem name to the
configuration file.
Users can select an OMC from a list of connected OMCs to refresh the Problem Type and Value
Filter window with all the threshold groups available in the selected OMC.
For custom problems that do not exist in the selected OMC, certain statistics-based problems,
script-based problems, event-based problems and infrastructure problems, the threshold group
columns display a dash (–). The same threshold value is displayed for global detectors in all the
threshold group columns.
68P02900W36-P 2-25
1900.2AS May 2008
Using the Problem Type and Value Filter Chapter 2: Using the NHA
For High GPRS Timeslot Congestion, Path Balance, High DPROC utilization, and High GPROC
utilization problems which have two thresholds, the following thresholds are displayed in the
threshold group columns:
• Threshold Value-y (for High GPRS Timeslot Congestion)
NOTE
High Uplink TBF Rejection Rate, Very High Usage of CS1 Downlink, and Very High
Usage of CS1 Uplink are disabled detectors in GSR8. However, these detectors can
still be selected for problem subscription. Therefore, these detectors can appear in
the Problem Type and Value Filter window. The High Uplink TBF Rejection Rate and
Very High Usage of CS1 Uplink detectors display the High Sample Threshold in the
threshold group columns. Very High Usage of CS1 Downlink displays the Threshold
Value in the threshold group.
The Problem Type and Value Filter window has three configurable columns Comparator,
Value and Show as in Figure 2-5.
• For a particular problem, when the Comparator column is changed to ALL, the Value
column is empty and non-editable. When the Comparator column has a value other than
ALL, the Value column is enabled for editing.
• The Show column can be checked or unchecked for a problem. When a problem is
unchecked, the Comparator and Value columns for this problem are disabled. However,
the values entered into these columns are still maintained. Detectors that are disabled in
Threshold window are not shown in the NHA UI, even if the Show column is checked.
2-26 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Properties les
The layout of the Problem Type and Value Filter window is described in Table 2-11:
Table 2-11 Problem Type and Value Filter window - layout
Select To
OK Save the configuration and exit, if the Save to
Properties file is successful.
None Uncheck the Show column for all problems.
All Check the Show column for all problems.
Cancel Abort the configuration and exit.
Help Display help to use Problem Type and Value Filter.
Properties les
The user profile is stored in the home directory of the NHA UI client machine
.NHA.problemfilter.properties. Individual users must create a home directory for their own
profile. Since the profile is stored in the file system, users can use any other user’s profile
by copying the properties file to their own home directory. Users can also copy the file to
secondary storage for backup or as a template.
Errors can be encountered during profile saving or loading. These errors are normally caused
by file system errors such as out of hard disk space, file corruption, or access rights.
68P02900W36-P 2-27
1900.2AS May 2008
User proles Chapter 2: Using the NHA
User proles
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The User Profile feature enables the system to remember a user’s preferred settings for Region
and Problem Subscriptions, Filter, Quick Filter, Sort, Font Size, Column Order, and Column
Width per NHA client machine. The user profile can be restored after the Problem window is
restarted.
The Profile option is available from the Configure menu as in Figure 2-6.
2-28 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Prole feature
Select To
Save Profile Save the current user profile.
Return to Default Settings Load the user profile with system default
settings.
Return to Last-Saved Load the user profile with last saved profile.
The current operator’s user name is shown in the status bar at the bottom of the Problem
window. To save a user profile, select Save Profile option from the Configure - Profile menu.
The current subscriptions, Filter and Quick Filter, Sort, Font Size, and column properties are
then written to the profile. When the user restarts the Problem UI, the profile is automatically
loaded on startup.
If a region or problem subscription stored in a profile is deleted by another user, the current
operator can select a new subscription on start up.
Users can also return to the default system settings or the last saved profile by selecting Return
to Default Settings or Return to Last-Saved menu from the Configure - Profile menu. Refer
to Figure 2-6. The Problem Window is then refreshed, based on the selected setting.
NOTE
The Return to Last-Saved Settings menu option is disabled if no profile has been
created for the current user.
Properties le
The user profile is stored in the home directory of the NHA UI client machine
.NHA.user.properties. Individual users must create a home directory for their own profile.
Since the profile is stored in the file system, current users can use any other user’s profile
by copying the properties file to their own home directory. Users can also copy the file to
secondary storage for backup or as a template.
Errors can be encountered during profile saving or loading. These are normally caused by file
system errors such as out of hard disk space, file corruption, or access rights.
68P02900W36-P 2-29
1900.2AS May 2008
The Problem pop-up menu Chapter 2: Using the NHA
Right click a problem row in the Problem window to display the Problem pop-up menu for
that problem (refer to Figure 2-7).
2-30 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Pop-up menu options
Select To
Comment Add, edit, or delete a comment for the selected single problem.
Add a comment for selected multiple problems.
Problem information View details of the selected problem including causes,
corrective actions, line of reasoning, detector information,
other problems on the device, problems on neighbors or other
problems on the site.
Causes View causes and corrective actions for the problem.
Other problems on device View other problems on the device.
Problems on neighbors View problems on neighbors for a problem.
Statistics History View the latest statistics from the device for the Cell,
Neighbor, Cell and Neighbors - Single Interval and Cell and
Neighbors - Single Statistic.
Event History View the Event History for the problem.
Long Term Statistics View key statistics over a period of time. This option is only
available from the Problem UI when a Cell or DRI problem
is selected.
Neighbors View the Neighbors window.
Remote Login Rlogin to the BSS that has the problem.
Action Scripts Run a user-defined Action script on the selected cell or
problem. There is a submenu on this option and a confirmation
must be provided before the script is initiated. See User
Interface Action scripts on page 2-209 in this chapter
for further information.
Parameter Check Report View a report of BSS parameters or groups of parameters
that do not match specified criteria (for the BSS in which the
problem is reported).
Site Health Check Create a Site Health Check report for a BTS Site and its cells.
BSS Detector Check View a list of BSS level detectors' values from the last interval,
based on any BSS connected to the OMC.
Add to Blacklist Add a cell with a problem to the blacklist.
Print Problem Print a problem report.
Export Problem Export a problem report.
Help View the online Help on the problem.
Problem Investigation View View additional information about the causes of the selected
problem.
NOTE
If a script is run from a PC-based User Interface that generates output to the screen,
it only gives output if a UNIX emulator program (for example, Exceed) is running
on the PC.
68P02900W36-P 2-31
1900.2AS May 2008
Problem Information window Chapter 2: Using the NHA
When the Problem Information option is selected from the pop-up menu on the Problem window,
the Problem Information window is displayed as in Figure 2-8. From this window, users can
do the following:
• View detailed information about the selected problem
2-32 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Problem Information window
The Problem Information window provides information about the selected problem as follows:
• Problem details
Problem details are displayed across the top of the window by Problem name, Value,
Device, Cell Group, First, Last, Repeats, Status, Operator, OMC, Severity,
Ranking, ID, and Type.
• Causes
Displays problem causes in order of descending confidence factor (High to Low). Click a
cause to view information about the corrective action.
• Corrective Action
Displays the recommended corrective action for the selected problem cause.
• Line of Reasoning
Displays the cause analysis path followed by the NHA to determine the causes of
thereported problem.
• Detector Information
Displays detector information for the selected problem.
• Problems on Neighbors
Displays other problems on neighbors.
• Problems on Site
Displays other site problems.
The following overview describes the user options available in each menu on the Problem
Information window.
File menu
Select To
Print Displayed Print the list of displayed data or update the printer list.
Export Displayed Export the details displayed to a file.
Close Exit from the Problem Information window.
68P02900W36-P 2-33
1900.2AS May 2008
Menu options on the Problem Information window Chapter 2: Using the NHA
View menu
Select To
Statistics History View additional data on statistics history for the selected
problem. For further information about the statistics history,
refer to Viewing statistics history and event history on
page 2-41.
Remote Login Rlogin to the BSS that has the problem.
Event History View the Event History for the selected problem. For
further information about the event history, refer to Viewing
statistics history and event history on page 2-41.
Add to Blacklist Add the selected problem to the blacklist.
Neighbors View the Neighbors window.
Action Scripts Run a user-defined Action script on the selected problem.
Cause Action Scripts Run a Cause Action script on the selected problem.
Problem menu
Select To
Handle Change the status of the selected problem to Handled.
Unhandle Change the status of the selected problem to New.
Clear Change the status of the selected problem to Cleared.
Unclear Change the status of cleared problem to New.
Unseen Change the status of Seen problem(s) to New.
Help menu
Select To
Help On Problem Display online Help for the selected problem.
Problem Investigation View Display online Problem Investigation View help for the
selected problem.
2-34 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes and corrective actions
Information about problem causes is displayed with a confidence factor rating, ranging from
Low to Very High. If more than one cause exists, the list of causes is displayed in order of
descending confidence factor and by time.
Users have the option to view problem causes by Last Occurrence Only (that is, the problem
causes raised in the last statistics interval) or All (all repeat problems). The default view is
Last Occurrence Only.
When a problem cause is selected, the recommended corrective action is displayed in the
Corrective Action panel.
Line of Reasoning
The Line of Reasoning panel displays information about the cause analysis path followed by the
NHA to determine one or more causes of the reported problem.
When the NHA performs a cause analysis on a particular problem, it runs a number of tests
to find the cause of that problem. If these tests are positive (TRUE), then the NHA raises
the results as a cause.
The Line of Reasoning feature records the results of these tests and displays the reasoning
process used. This information is useful in a situation where the NHA cannot find the cause for a
particular problem. Using the Line of Reasoning, the operator can check to see what tests it has
performed and therefore is saved from having to repeat those tests. Tests which are negative
(FALSE) or UNKNOWN are also described.
By default, Line of Reasoning information is displayed for the last occurrence of the selected
problem. To view the Line of Reasoning for the first occurrence of the problem, select the First
Occurrence option.
Detector information
The Detector Info panel displays information about the last occurrence of the selected problem.
It describes the statistical formula used to detect the problems, the values used and the results.
To view Detector Info for the first occurrence of the problem, select the First Occurrence option.
For statistic-based problems, the detector information is displayed for either the first or last
instance of the problem as follows:
Numerator =
Denominator =
Numerator Value =
Denominator Value =
Calculated Value (Numerator / Denominator) =
Threshold =
Detection Type =
Interval Count =
For event-based problems, the sequence of events that caused the problem to be raised is listed.
68P02900W36-P 2-35
1900.2AS May 2008
Other device, neighbor and site problems Chapter 2: Using the NHA
From the Problem Information window, users can view information about other device, neighbor,
or site problems on the following panels:
• Other Problems on Device
The device on which the selected problem has occurred has other problems.
• Problems on Neighbors
Neighboring cells have problems occurring on them which are related to the problem
selected in the Problem window.
• Problems on Site
The site on which the selected problem has occurred has other problems.
When a problem is selected on one of these panels, the View Problem and View in New buttons
are enabled. This enables users to view other problem information either in the current Problem
Information window or in a new Problem Information window.
If the View Problem button is selected, the current Problem Window is updated with information
about the newly selected problem. A record of any problems displayed is kept and users can
scroll through previously displayed problems using the Back and Forward buttons on the toolbar.
If the View in New button is selected, a new Problem Information window is launched, displaying
details of the newly selected problem. No record of the selected problem is kept.
2-36 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Changing the status of a problem using the Seen option
The Seen option allows the user to change the status of problems on the Problem window from
NEW to SEEN or to revert the status from SEEN to NEW.
To change the status of a NEW problem to SEEN, click the problem row. To revert the status of
a problem from SEEN to NEW, use the following steps:
• On the Problem window, left click the required problem row and select the Unseen option
from the Problem menu. Refer to Figure 2-9.
68P02900W36-P 2-37
1900.2AS May 2008
Using the Seen option Chapter 2: Using the NHA
Alternatively, right click the required problem row to display the Problem pop-up menu and
select the Unseen option.
2-38 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Adding comments
Adding comments
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The Comment option allows users to add and modify comments for any problems selected
on the NHA UI.
1 Right click the required problem row to display the pop-up menu and select
the Comment option from the pop-up menu as in Figure 2-10. Alternatively,
left click the required problem row, then select the Comment option from
the Problem menu as in Figure 2-10. The Problem Comment dialog box
is displayed.
Continued
68P02900W36-P 2-39
1900.2AS May 2008
Using the Comment option Chapter 2: Using the NHA
2-40 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing statistics history and event history
The NHA presents a range of additional data on statistics history for a problem. Using the
Statistics History option, users can view the statistics for the last 24 intervals for the problem
cell and its neighboring cells. This is useful for further debugging. Additional statistics such as
handover statistics are also available. Multi-OMC support is provided.
To view the statistics history for a problem, on the Problem window right click the problem row
to display the Problem pop-up menu. Select the Statistics History option to display a submenu
from which the following statistic views are available:
• Statistics History - Cell
Select this option to view the statistics for the selected cell across 24 intervals.
Select the Statistics History-Cell option from the Problem pop-up menu to view the values
of statistics for the selected cell across 24 intervals. The Statistics History - Cell window is
displayed as in Figure 2-11.
The information is presented in spreadsheet format. The Device Name is displayed at the top of
the window. Formula and traffic statistics are displayed by default in the upper panel and raw
statistics are displayed by default in the lower panel.
To view additional statistics for the cell, select the Carrier, Neighbor Cell Key, Neighbor
Cell and/or Neighbor Relationship check boxes as required. The additional statistics are
appended to the data already displayed.
68P02900W36-P 2-41
1900.2AS May 2008
Changing to different views Chapter 2: Using the NHA
Use the View menu on the Statistics History - Cell window to display statistics in a different
way as follows:
Select To view
Neighbor Statistics for neighbor cells for the selected
cell.
Cell & Neighbor - Single Statistic A single statistic over 24 intervals for the
selected cell and its neighbors.
Cell & Neighbor - Single Interval Statistics for the selected cell and its
neighbors for a specific interval.
Select the Statistics History-Neighbor option from the Problem pop-up menu to view statistics
for all cells (that is, the selected cell and its neighbor cells).
The Statistics History - Neighbor window is displayed as in Figure 2-12. The Device Name is
displayed and a list of neighbor cells is also displayed in the Neighbors list at the top of the
window. Users can switch between neighbors by selecting a different neighbor from the list.
2-42 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing statistics history for a single interval
Conguring statistics
Through the Configure menu, users can configure (that is, add or remove) statistics displayed
for the cell, carrier, and neighbor statistics (both formula and raw) displayed.
Select the Statistics History-Cell & Neighbor - Single Interval option from the Problem
pop-up menu to view statistics for all cells (selected cell and its neighbors) for a specific
interval. The Cell & Neighbor - Single Interval window as in Figure 2-13 is displayed. Users
can switch between the intervals.
The Device Name is displayed and a list of intervals is also displayed in the Interval list at the
top of the window. Users can cycle though statistics intervals (time), displaying the values of
statistics on the X-axis versus neighbors on the Y-axis.
68P02900W36-P 2-43
1900.2AS May 2008
Viewing statistics history for a single statistic Chapter 2: Using the NHA
Conguring statistics
Through the Configure menu, users can configure (that is, add or remove) statistics displayed
for the cell, carrier, and neighbor statistics (both formula and raw) displayed.
Select the Statistics History-Cell & Neighbor - Single Statistic option from the Problem
pop-up menu to view a single statistic, over 24 intervals, for the selected cell and all its
neighbors.
The Cell & Neighbor - Single Statistic window as in Figure 2-14 is displayed. The Device
Name is displayed and a list of statistics is also displayed in the Statistic Name list at the top
of the window.
Users can cycle through statistics, displaying statistic values over 24 intervals for the selected
cell and all its neighbors.
2-44 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Exporting and printing statistics data
Conguring statistics
Through the Configure menu, users can configure (that is, add or remove) statistics displayed
for the cell, carrier, and neighbor statistics (both formula and raw) displayed.
Printing data
Select File-Print to print the data displayed on the Statistics History window.
Exporting data
Select File-Export Displayed to export the data displayed on the Statistics History
window to a .csv file. Refer to Figure 2-15. The default export location is
/usr/gsm/OMCs/<omcname>/ea_logs/SHmmdd-hhmmss.csv.
There is also an option to Export Neighbors using the Statistics History - Neighbor view. The
default export location is: /usr/gsm/OMCs/<omcname>/ea_logs/SNmmdd-hhmmss.csv.
68P02900W36-P 2-45
1900.2AS May 2008
Conguring statistics Chapter 2: Using the NHA
Conguring statistics
The statistics initially displayed on the Statistics History - Cell window are the default statistics
for the selected problem. Through the Configure menu, users can configure (that is, add or
remove) statistics displayed for the cell, carrier, and neighbor statistics (both formula and
raw) displayed.
Cell statistics
To select additional Cell statistics for the problem, use the following steps:
1 Select the Neighbor Cell statistics option from the Configure menu to
open the Statistics Selection window as in Figure 2-16.
2 Click the Key stats or Cell tab. The Available, Selected, and Default
statistics for the selected problem are displayed.
2-46 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring statistics
68P02900W36-P 2-47
1900.2AS May 2008
Conguring statistics Chapter 2: Using the NHA
Carrier statistics
Carrier level statistics are viewed from the Statistics History - Cell window. Select the Carrier
statistics option from the Configure menu to open the Carrier Statistics window, as in
Figure 2-17, containing a list of carrier statistics.
Carrier statistics can also be viewed from the Statistics History - Neighbors window. Refer
to Figure 2-20.
2-48 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing event history
To select neighbor cell statistics for the problem, use the following steps:
1 Select the Neighbor Cell statistics option from the Configure menu to
open the Neighbor Cell Statistics Selection window as in Figure 2-18.
2 Click the Key stats or Cell tab.
The Available, Selected, and Default statistics are displayed.
3 Select a statistic from the Available column, as shown in Figure 2-18.
4 Click the right-arrow button >>. The statistic is added to the Selected
column.
To remove a statistic, select the unwanted statistic in the Selected column
and click the left-arrow button <<. The statistic is then removed from the
Selected column.
5 Click OK to complete the procedure.
Select this option to view the history of events for the problematic device over the last 24 hours.
To view the event history of a problem, select one of the Event History options from the
Problem pop-up window.
68P02900W36-P 2-49
1900.2AS May 2008
Viewing event history Chapter 2: Using the NHA
• Last to screen: Select this option to display the event history for the 24 hours before the
problem was last raised.
• First to file: Select this option to send the event history for the 24 hours before the
problem was first raised to a file.
• Last to file: Select this option to send the event history for the 24 hours before the
problem was last raised to a file.
The output is provided in a Web browser. The event history output will also include events which
are approximately 5 minutes before a problem was first raised (if First to screen/file is chosen)
or 5 minutes after the problem was last raised (if Last to screen/file is chosen).
2-50 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing long term statistics and other problem information
The Long Term Statistics option allows users to view a 60-day history of some key statistics in
graphic and tabular form. From the information displayed, operators can quickly view trends,
observe any sudden changes and are thus able to resolve network issues rapidly.
• Call Volume
• Traffic Carried
NOTE
Any key statistics added here are not displayed on the lgConfig -a Keystats window.
The lgConfig -a command displays a list of key statistics, as in the daily exports
of key statistics feature, EXCEPT the default long term statistics, site-based, and
carrier-based key statistics and some GPRS key statistics. (These key statistics are
BE, CA, IN, PB, SI, HC3, HC5, HC6, HC7, HC9, GPBS, GPSI as seen in the list of
rules calculated by daily exports feature.) For a list of available key statistics, refer
to Table 4-6.
68P02900W36-P 2-51
1900.2AS May 2008
Viewing long term statistics Chapter 2: Using the NHA
To view long term statistics for the cell related to the problem selected on the Problem window,
select the Long Term Statistics option from the Problem pop-up menu. The Keystats window is
displayed as in Figure 2-19.
NOTE
This option is only available from the Problem UI when a Cell or DRI problem is
selected.
As can be seen in Figure 2-19, the window displays the five key statistics in the table by
default. The leftmost KeyStat column shows the names of the key statistics. The remaining
columns show the daily value for each key statistic, with the date displayed in the column
header. A vertical scroll bar appears on the table if the user adds more key statistics.
2-52 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Event history
The parentage of the cell is displayed above the graph in the device label. The name of the
KeyStat displayed in the graph is also displayed above the graph. When the user selects a
different table row to the one highlighted, then the graph changes to match that row. If a
key statistic is missing on a particular date, then a gap appears on the graph and a question
mark “?" in the table for that date.
Long Term Statistics can also be launched from the Cell View window. Refer to Manual cell
grouping on page 2-115 for details.
Event history
Select this option to view the history of events for the problematic device over the last 24 hours.
To view the event history of a problem, select one of the Event History options from the
Problem pop-up window.
• Last to screen: Select this option to display the event history for the 24 hours before the
problem was last raised.
• First to file: Select this option to send the event history for the 24 hours before the
problem was first raised to a file.
• Last to file: Select this option to send the event history for the 24 hours before the
problem was last raised to a file.
68P02900W36-P 2-53
1900.2AS May 2008
Viewing a list of Neighbor cells Chapter 2: Using the NHA
To view all neighbor cells, select the Neighbors option on the Problem pop-up menu or the
Neighbors option from the pop-up menu on the Cell View window or the Neighbors option from
the View menu on the Problem Information window. The Neighbors window is then displayed
as in Figure 2-20.
The Device Name is displayed at the top of the Neighbors window. A list of neighbor cells for
the selected problem cell is displayed, sorted in the following order: OMC, BSS, Site, Cell
Name, Type, Incoming, and Outgoing.
Remote login
Users can remote login into the BSS or RXCDR of the problematic device. To remote login into
a BSS/RXCDR from the Problem window, select the Remote Login option from the Problem
pop-up menu.
The NHA determines the parent BSS/RXCDR and logs in remotely to it.
From GSR9 OMC-R onwards, BSS Remote Login dialog is displayed when a user logs in for the
first time. Upon successful remote login, password is remembered. On subsequent remote
login, BSS Remote Login dialog does not appear.
2-54 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Action scripts
NOTE
For GSR8 OMC-R, if an error message is displayed, modify the remote login
permissions. For GSR9 OMC-R onwards, if an error message is displayed, ensure that
the user has an account on the OMC and that the username is the same as that on the
PC/MMI. Refer to Setting client machines for remote login on page 4-92.
Action scripts
This option is used to run a user-defined action script on the selected cell or problem. When
the Action Scripts option is selected from the Problem pop-up menu, a submenu is displayed
as in Figure 2-22.
68P02900W36-P 2-55
1900.2AS May 2008
Action scripts Chapter 2: Using the NHA
Once the script is selected, a confirmation window is displayed before the script is initiated as in
Figure 2-23. Click Yes to continue.
2-56 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Action scripts
NOTE
If a script is run from a PC based User Interface that generates output to the screen,
it only provides output if a UNIX emulator program (for example, Exceed) is running
on the PC.
For further information, refer to User Interface Action scripts on page 2-209.
One sample Action Script provided appears on the Problem window pop-up menu as History of
Problems. When selected, it gives a chronological list of all the problems that the NHA has
detected on that device in the last ten days. It is often useful to have historical information
about a cell when troubleshooting it.
NOTE
If this script is run from a PC based User Interface, it only provides output if a UNIX
emulator program (for example, Exceed) is running on the PC.
68P02900W36-P 2-57
1900.2AS May 2008
Adding to the blacklist Chapter 2: Using the NHA
Another sample Action Script is provided, that appears on the Problem window pop-up menu as
PM GUI Cell Stats. When selected, it launches the OMC-R PM GUI in trend graphical mode,
with five days worth of values for Call Success Rate, Dropped Call Rate, TCH usage, and Total
Calls for all the cells in the problematic site (or BSS if it is a BSS problem). This functionality is
useful when users want to view statistics values for a longer time period than the 24 intervals
available in the Statistics History window.
NOTE
The two values of the Call Success Rate statistic are displayed, due to a limitation
of the OMC-R Applix interface.
If changing this script (for example, to modify the format of the report or the statistics chosen),
then administrators must be aware of the guidelines provided in the OMC-R Online Help,
Network Operation. Refer to Running a PM report from the command line.
The Action Script PM GUI Carrier Stats can also be accessed from the Problem pop-up menu.
This displays carriers statistics to the user for all carriers under a selected cell.
NOTE
Ensure that the setting for the value STAT_INTERVAL in the OMC-specific
configuration file (/usr/gsm/OMCs/<omcname>/config/ea.cfg) is correctly set to
either 30 or 60, depending on whether the statistics interval is 30 minutes or 60
minutes for the OMC. If this value is incorrectly set, then the PM graphs can display
incorrect results.
To add a device related to the problem to the blacklist, select the Add to Blacklist option from
the Problem window pop-up menu and select the required device from the list displayed. A
confirmation message is displayed.
To print problem details, select the Print Problem option from the Problem pop-up menu.
Select a printer and click OK.
To export problem details, select the Export Problem option from the Problem pop-up menu.
Select the default filename /usr/gsm/OMCs/<omcname>/ea_ logs/PB [mmdd.hhmm].txt or
choose an alternative. Click the Export button to continue.
2-58 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Exporting and printing problem reports
The NHA provides for selections of problems to be exported in .CSV (Comma Separated
Variable) format, either manually or automatically.
Operators can manipulate these exported problem lists offline using a third-party spreadsheet
or database. Equally, operators can access their content from a Web browser.
Manual exports
The operator can export problems displayed on the Problem window by selecting the Export
Displayed option in the File menu.
When this option is chosen, the problems currently displayed on the Problem window are sent to
a user-defined location. The default location is /usr/gsm/ea_logs/RB[mmdd-hhmmss].csv.
Additionally, the operator can highlight consecutive rows on the Problem window, select the
Copy option from the Edit menu (or use the shortcut key Ctrl+C) and then paste the selected
problems into a file or application where they appear in CSV format.
Automatic exports
The NHA automatically exports all problems from the NHA to various files, on a daily basis
and on a 15-minute basis.
Every day, at a specified time (using the Daily Export option on the Configure menu) all
problems active at that time are automatically exported to files as follows:
Every 15 minutes, all the problems active at that time are automatically exported to files as
follows:
The daily.csv and current.csv files are in the NHA's web accessible directory so Web browsers
can access them easily. For further information about Web access, refer to Web access on
page 4-44.
In addition to the scheduled exports, log files (in .csv format) of all detected problems are also
kept in /usr/gsm/OMCs/<omcname>/ea_logs/eaProblems<date>. These files can also be
imported to a third-party spreadsheet or database for manipulation. For further information
about NHA log files, refer to NHA log files on page 4-33.
68P02900W36-P 2-59
1900.2AS May 2008
Printing a list of problems Chapter 2: Using the NHA
Click the Print button to print the list of problems in the Problem window.
The following is a suggested method for taking NHA export files and loading them into Microsoft
Excel.
Continued
2-60 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Importing problems into spreadsheets
Procedure 2-7 Loading export les into Excel - multiple OMCs (Continued)
5 Open the export file.
6 Select CTRL-A.
Or, select Tools - Macro - Macros.
In some country-specific versions of commercial spreadsheet programs, the comma "," character
is used as a decimal point and is not accepted as a default separator. As a result, comma
separated value (.CSV) files are not read in correctly. This issue affects the exported problem
lists and can affect other exported files which are then imported into spreadsheets (for example,
Thresholds and Statistics History).
A solution is to edit the exported file to replace the comma characters with a tab character (or
any other delimiter that the spreadsheet takes). In UNIX, use the following command before
importing the file to the spreadsheet:
The macro is created in Visual Basic. To modify the macro, perform the following steps in
Microsoft Excel:
Table 2-18 provides a brief explanation of the abbreviations used in the Daily Export Report.
68P02900W36-P 2-61
1900.2AS May 2008
Abbreviations used in the Daily Export Report Chapter 2: Using the NHA
2-62 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Summary report of problems detected
A summary report of all the daily problems detected by the NHA for all OMCs is
produced at 04:00 every day. The report is stored in the directory /usr/gsm/ea_logs/
with a name NHASumm[date]. The most recent report is also copied to the Web
directory /usr/gsm/config/local/nha_summary.txt and through a Web viewer at
http://[nhaserver]/nha_summary.txt. There is a link to this report from the default NHA
web page. It is useful for a management overview of what the NHA is detecting or as an aid
to setting thresholds.
68P02900W36-P 2-63
1900.2AS May 2008
Overview of the summary report Chapter 2: Using the NHA
NOTE
If modifications are made then it is good practice to save the original and the modified
version in a safe location.
2-64 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The NHA web page
To access the default NHA web page, use the Tools - NHA Web Page menu option. Refer to
Figure 2-24. The NHA web page can also be accessed by entering http://[nhaservername]/
in a browser window. This web page provides useful access to the NHA when access to the
NHA UI is not possible.
68P02900W36-P 2-65
1900.2AS May 2008
Links Chapter 2: Using the NHA
Links
This hyperlink links to a web page that has links to the output of the long term statistics detection
scripts. This report is in the default output format for these scripts. The report is updated daily.
Problems by OMC
This hyperlink links to information about network issues reported as NHA problems on an OMC
basis in HTML format. The report is updated every 15 minutes.
To sort the report, click the appropriate heading. To filter the report by problem type, select
the problem name from a drop-down menu.
This hyperlink links to information about network issues reported as NHA problems in CSV
format. The report displays the most recent problems for all OMCs that the NHA monitors
and is updated every 15 minutes.
For PC users, Internet Explorer normally shows .CSV files in a commercial spreadsheet, making
it easier to sort the lists of problems, produce reports, and so on. It can be sorted and formatted
at a later stage using the NHA macros (for example, nha_1pagemacro.xls). Refer to Exporting
and printing problem reports on page 2-59 for more details.
2-66 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA administration reports
With Netscape, it is necessary to save the .CSV file locally at first and then load it into a
commercial spreadsheet. Alternatively, open the locally saved copy directly with a commercial
spreadsheet. The files are also available in /usr/gsm/config/local/ directory as current.csv
and daily.csv.
This hyperlink links to information about network issues reported as NHA problems in CSV
format. The report displays the most recent daily problems for all OMCs that the NHA monitors
and is updated daily.
Summary Report
This hyperlink links to a summary report of daily problems per OMC. The report is updated daily.
It is useful for getting an overview of the issues the NHA is detecting on a per OMC basis. This
report is a copy of the most recent /usr/gsm/ea_logs/NHASumm[date].txt report.
This hyperlink links to a report of cells that have frequency clashes with their neighbors. The
report is updated daily. For further information, refer to Frequency Clash Report on page
2-102.
This hyperlink links to the latest Parameter Check report of the NHA. The report is generated
once daily during the daily cycle routine of the NHA or when the operator runs the script
manually from the command line. For further information, refer to Parameter Check Report
on page 2-69.
This link displays the most recent output from the NHA system monitoring program. It is a copy
of the most recent report in /usr/gsm/ea_logs/sys_info/. It is useful for debugging the NHA.
This link runs the NHA health command and provides output in the web browser. It is useful for
getting a quick overview of the health of the NHA at any particular time.
68P02900W36-P 2-67
1900.2AS May 2008
NHA help pages Chapter 2: Using the NHA
This hyperlink links to the Problem Information Views web page. Further analysis of problems
can be carried out using the fault-finding steps in the problem investigation view. Note the
information contained in these views is not used by the NHA in its automatic analysis of a
problem.
This link displays instructions for installing the NHA UI client on a PC.
2-68 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Parameter Check Report
The Parameter Check Report checks a range of BSS database parameters and reports any
values that break certain conditions. The report is generated daily by the NHA. It is based on
parameters stored in the MIB database on the OMC-R. If a parameter or group of parameters
falls outside a recommended range of values or does not match other specified criteria, it is
reported under the relevant device in the Parameter Check Report.
The Parameter Check Report enables users to run a check and quickly identify parameter
settings that break recommended values. It can act as a “before and after” check, for example,
when modifying a BSS.
Background functionality
The Parameter Check Report runs automatically when the NHA performs its daily cycle
activities (after daily roll-up). An external problems script D_ea_ParaCheck.pl located at
/usr/gsm/current/knowledge/external_problems checks parameters for all BSCs on each
OMC monitored by the NHA. The script depends on two resource files for inputs from the
MIB database of each OMC.
Note the parameter checking script can be run manually for a single OMC using an optional
command as follows:
D_ea_ParaCheck.pl <OMC>
Where: Is:
<OMC> The host name of the OMC.
Types of check
• Complex checks
Simple checks
Simple checks (conditions) comprise three entities: a parameter, an operator, and a threshold
value. The user can expand the list of parameters to check by editing a configuration file. The
valid values for operators supported by simple checks are listed in Table 2-19. The threshold
value can be any signed number. The following list provides an example of simple checks:
68P02900W36-P 2-69
1900.2AS May 2008
The Parameter Check conguration le Chapter 2: Using the NHA
Simple checks/conditions
second_asgnmnt = 0
efr_enabled = 0
assign_successful >15000
ho_successful >15000
Complex checks
The script provided by Motorola performs some complex checks. The user does not have an
option to revise, enable, disable, or create new complex checks. The following list provides an
example of complex checks:
When the Parameter Check Report is started, a list of database parameters is read from the
configuration file ParaCheckCfg.csv which is found in /usr/gsm/config/local. All threshold
values and other condition details for simple Type A parameter checks are read from this file.
Users can modify the CSV file in the following ways:
• Edit a check condition.
NOTE
The parameter option_empreempt is renamed option_preempt in GSR8. Therefore,
this check has been moved from simple (Type A) to complex (Type B) check to
cater for BSS versions 1760, 1800 and 1900. The script ignores the parameter
option_empreempt if it is added into the configuration file.
A list of the BSS database parameters checked and the tests carried out for each parameter is
available from the Parameter Check Report on the NHA web page. For more details, refer to
The Parameter Check Report on page 2-73.
The configuration file holds information about simple Type A parameter checks in the following
format (refer to Table 2-19):
2-70 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The Parameter Check conguration le
Field Name Field Type Description Valid values Requirement Default value
Index String A unique ID Convention: Optional NA
to represent a number must
parameter check. be >=1000.
This field is only (<1000 is
used for debugging reserved by
and tracking. Motorola)
Status String Status of condition. Enable/Disable Required Enabled
If the status
is not Enable,
the condition is
not included in
the Parameter
Checking report.
DeviceType String Identifies the entity BSC, Site, Required NA
type being checked. Cell, Carrier,
Neighbor
Rating Numeric Identifies the 0 = Normal Required 0
significance of 1 = Highlight
the check, and yellow
influences the 2 = Highlight
format/appearance red
of the result in the
report.
Table String MIB table name bsstable2, Required NA
that contains the mmstable2,
attribute in the sitetable2,
condition. celltable2,
rtftables,
neighbourtable2
Column String Column name for Valid column Required NA
the attribute in the name.
condition.
Operator Symbol Logical operator of = < > <= >= Required NA
the condition
Value Signed Threshold value. Any signed Required NA
long number
numeric compatible
with SQL
number
formatting.
HeaderInfo String Header string Any Required NA
to display in the formatted
parameter checking string.
report should the
condition be true.
Detailed String More information to Any Required NA
Info append to Header formatted
Info. string.
68P02900W36-P 2-71
1900.2AS May 2008
The Parameter Check conguration le Chapter 2: Using the NHA
Editing a condition
Users can edit the check conditions in the configuration file using any text editor or other
tool capable of reading the CSV file format. The configuration file must be saved in a similar
format (refer to Table 2-19).
Threshold values can also be updated. Note the accuracy of the parameter checks depends on
the validity of the updated threshold value.
Users can make the HeaderInfo and DetailedInfo fields dynamic using the substitute keywords
# and % as follows:
• #
Substitutes the threshold value in the Value field with this keyword into any sentence
in the HeaderInfo or DetailedInfo column.
• %
Substitutes a value from the MIB of the column declared in Column field with this keyword
into any sentence in the HeaderInfo or DetailedInfo column.
The following provides an example of the output of a report using substitute keywords:
bssmap_t10 timer over 14000ms. The value of the bssmap_t10 parameter is 30000.
The recommended setting is <= 14000ms.
Where: Is:
HeaderInfo bssmap_t10 timer over (#) s.
DetailedInfo The value of the bssmap_t10 parameter is (%). The recommended
setting is <= (#)s.
Threshold value in 14000
Value
MIB value in Column 30000
To include new user-defined parameter check conditions, add a new line into the configuration
file. These conditions are read and run in a top-to-bottom order. Complete all the required fields
of the CSV file when the new condition is being added to enable the new condition. Refer to
Table 2-19 for details of required configuration file fields.
To remove an unwanted condition from the configuration, delete the entire line from the file.
Ensure that no redundant new line character is left behind.
Alternatively, to disable a condition, set the Status field value of that condition to Disable. Refer
to Table 2-19 for details. It is recommended that users disable rather than delete a check, in
case the check condition is required for future use or reference.
2-72 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The Parameter Check Report
One Parameter Check Report is generated for each OMC monitored by the NHA in HTML
format. The report can be accessed as follows:
• From the NHA UI by selecting the Parameter Check Report option from the Tools menu
which launches a browser window to view the report.
• From the Problem pop-up menu by right-clicking the required problem to bring up the
pop-up menu and then selecting the Parameter Check Report.
Note when the report is launched from this menu, it shows the results for the BSS in
which the problem is reported immediately.
• From the NHA web page by selecting NHA Parameter Checking Report from the list of
NHA Network Issue Reports.
68P02900W36-P 2-73
1900.2AS May 2008
The Parameter Check Report Chapter 2: Using the NHA
Report details
Figure 2-25 provides an example of the Parameter Check Report in HTML format.
The report header displays information about the OMC for which the report was generated.
The date and time of the report is also displayed. An information message about the report
is provided below this header which includes a link to the list of all the parameter checks
performed by the script.
Filter the report by BSS name using the drop-down menu at the top of the report. The menu
consists of the BSSs that contain devices with parameter exceptions. By default, a report on
the first BSS on the menu is displayed. If a different BSS is selected, the report excludes the
results for all other BSSs.
The main body of the report lists the devices under each BSS that have parameter exceptions
associated with them. The devices are listed in the following order:
• BSS
• Site
• MMS
2-74 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The Parameter Check Report
• Cell
- Neighbor
- Carrier
Each device is listed once, followed by the list of parameter exceptions for the device. Each
parameter exception has a brief headline description followed by a more detailed description.
Where a parameter exception is reported for a single parameter value, the detailed description
is given. It consists of the name of the parameter and its value, the threshold or recommended
value to which it is being compared, and the comparison type being used. Where a parameter
exception involves more than one parameter, the detailed description gives the names and
values of all the parameters used and a description of the test used.
NOTE
A device with no parameter exceptions is listed if it is necessary to show the location
of a child device, for example a parent Site with no parameter exceptions is listed to
show the location of a Cell with parameter exceptions.
The Parameter Check Report displays these parameter exceptions in appropriately colored text.
The text color indicates the severity of the messages as follows:
• Red: Highest severity
To view the Parameter Check Report as a plain text file, click the Text Format hyperlink located
beside the title of the report. To switch back to the HTML report from the text format, click the
Html Format hyperlink located beside the title of the report.
It is possible to save the Parameter Check Report as a plain text file when viewing the text report:
Note the plain text form of the report does not include an indication of the severity of the
parameter exceptions.
68P02900W36-P 2-75
1900.2AS May 2008
Site Health Check Chapter 2: Using the NHA
The Site Health Check provides a mechanism to run a defined set of NHA detectors
automatically. It quickly enables a health check to be performed on new sites or modified sites
and delivers a report on any problems found.
The Site Health Check can be run for a BTS Site and its cells. It is accessed from the NHA UI.
When selected, it runs through problem detection for all cells on the site and outputs the results
to a web page. It uses the NHA “Default” Group threshold settings for any detector thresholds.
The Site Health Check can be launched from the NHA UI as follows:
To perform a Site Health Check from the Problem window, Cell View or Blacklisted Devices
windows, use the following steps:
1 Right click the required problem row to display the pop-up menu.
2 Select the Site Health Check option from the pop-up menu as in Figure 2-26.
The Last interval and Last 24 intervals options are displayed. If there are
not enough intervals, a warning message is displayed.
3 Select either the Last interval or Last 24 intervals options as follows:
2-76 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using Site Health Check
Figure 2-26 Selecting Site Health Check from the Problem window
68P02900W36-P 2-77
1900.2AS May 2008
Viewing the Site Health Check report Chapter 2: Using the NHA
The results of the site health check are output in HTML format to the browser window as
in Figure 2-27.
The Site Health Check report includes the result of each test and, where relevant, the threshold
value for the test. The date, time-stamp, BSS Name, Site Name, and cell names (in each table),
for the site on which the health checks were run are displayed. Note the Site Health Check
uses the Default Group threshold settings on the NHA, and does not include a minimum sample
size check. For this reason, some of the “Investigates” listed here do not appear in the NHA
problem window.
A Quick Summary section at the top of the report shows any tests that failed and were flagged
as “Investigates”. For example, any tests that would have raised a problem under normal NHA
detection (that is, a test that has exceeded the threshold). If there are no “Investigates” flagged,
then the Quick Summary states that there are no issues to be investigated.
The list of “Current Problems for this Site on the NHA” is displayed below the Quick Summary.
The Detector Summary section lists the test results and thresholds for each NHA detector in
table format. Two “Traffic Overview” rows show the Total Calls and Busy TCH Mean values for
each cell in the Site. The Detector Summary also lists the test results and thresholds for each
NHA detector and explains the type of value by including a % sign where the value is a rate.
2-78 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Supported detectors
NOTE
For an updated report, launch the Site Health Check report again from the Problem,
Cell View, or Blacklist windows. Refer to Using Site Health Check on page 2-76.
Refreshing the page in the browser does not present the latest information.
Supported detectors
The Site Health Check runs the following statistics based detectors (refer to Table 2-20):
Table 2-20 Site health check - supported detectors
Continued
68P02900W36-P 2-79
1900.2AS May 2008
Supported detectors Chapter 2: Using the NHA
Note the Site Health Check does not include customized detectors or the following script-based
detectors:
• One-Way MTL
• BSS-Level Detectors
• Consolidated Problems
2-80 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst BSS Detector Check
The BSS Detector Check allows users to view a list of BSS level detectors' values from the last
interval, based on any BSS connected to the OMC. The BSS Detector Check option is accessed
from the NHA UI. When selected, it runs through problem detection for all cells on the site and
outputs the results to a web page.
The BSS Detector Check can be launched from the NHA UI in the following ways:
• From the Problem pop-up menu.
68P02900W36-P 2-81
1900.2AS May 2008
Viewing the BSS Detector Check report Chapter 2: Using the NHA
Select the BSS Detector Check option from the pop-up menu as in Figure 2-28.
Figure 2-28 Selecting the BSS Detector Check option from the pop-up menu
The results of the BSS Detector Check are output to the browser window in HTML format.
The BSS Detector Check report includes the OMC Name, BSS Name, OMC Period, the report
timestamp, and all detectors values and their respective thresholds for the site on which the
BSS Detector Check was run. The report presents all the detector name, values, and thresholds
in tabular format. The report highlights all the rows that break the threshold. It also explains
the type of value. It displays a percent sign % where the value type is a rate, calls where the
value type is a call and secs where the value type is time.
2-82 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Supported detectors
Supported detectors
The BSS Detector Check displays information about the following detectors:
• Total Calls
68P02900W36-P 2-83
1900.2AS May 2008
Using the In Service Monitor (INSM) tool Chapter 2: Using the NHA
The INSM - Network Display window (Figure 2-29) is color coded. Red indicates that
something is out-of-service (OOS) and Green indicates that all devices are in service (INS).
NOTE
The Device OOS external script detector expands the list of devices monitored
by the NHA to cover BSP, BSS, BTP, CBL, CELL, COMB, CSFP, DHP, DRI, GBL,
GCLK, GDS, GPROC, GSL, KSW, MMS, MTL, PATH, PCU, RSL, RTF, SITE, XBL,
RXCDR. These devices are now reported as problems on the Problem window.
For further information, refer to Device out of service (OOS and Locked)
on page 3-153.
2-84 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing the status of network devices
The INSM tool provides a real-time graphical overview of the status of RF devices in the entire
network. It shows what is currently in and out of service.
The INSM tool monitors the operational states and administrative states of each of the following
network components:
• The Base Station System (BSS)
• Sites (BTSs)
• Cells
G2 interface limitations
The In Service Monitor (INSM) user interface is currently developed in Gensym G2. As this
interface is not a standard user interface, some of the non-standard functions are described
as follows:
• The Left, Right, and Centre mouse buttons all perform the same functions.
• To move a window within the user interface, click a gray area in the window, then hold and
drag to move the window.
• To enlarge or reduce the size of the window, select the View - Larger or View - Smaller
menu items on the user interface.
• To bring the window to the top, select the View - Lift to top menu item on the user
interface.
• To close the main menu, click the black line at the top of the menu.
68P02900W36-P 2-85
1900.2AS May 2008
Device status Chapter 2: Using the NHA
Device status
The INSM Network Display window depicts the status of devices as follows:
State Definition
Gray Unknown Status
Red Out of Service (OOS)
Green In Service (INS)
Blue Blacklisted
* at least one sub device is blacklisted
For each device, a running total of in service devices over the total devices is continually
updated on the display. For example, if the Sites column shows 27/28*, this indicates that 27 out
of 28 unblacklisted sites are in service. The * indicates that at least one blacklisted site exists.
When a device is created, it is automatically blacklisted. The user can manually remove this
device from the blacklist on the Configuration Report dialogue in the INSM or from the
View/Modify Blacklist dialogue in the Problem window. When the device begins to carry traffic,
it is automatically removed from the blacklist.
INSM logic
The INSM uses the following logic to calculate whether a device is in service, out-of-service, or
unknown:
If the state of the superior device is INS then return the state of the device. If the state of the
superior device is unknown then return the state of the device. If the state of the superior device
is blacklisted then return Blacklisted. If the state of the superior device is OOS then return OOS.
RTFs
If Then
The device is not blacklisted
Op-state is BUSY and the admin-state is EQUIPPED RTF is INS.
UNDEFINED and UNDEFINED RTF is Unknown.
All else RTF is OOS.
2-86 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Device status
DRI
If Then
The device is not blacklisted
Op-state is BUSY and the admin-state is UNLOCKED DRI is INS.
Op-state is ENABLED and the admin-state is UNLOCKED DRI is INS.
and standbys are INS
UNDEFINED and UNDEFINED DRI is Unknown.
All else DRI is OOS.
If Then
BUSY and UNLOCKED and containing BSS or RXCDR Site or Cell is INS.
is INS
All else Site or Cell is OOS.
If Then
SITE 0 of the BSS/RXCDR is BUSY and UNLOCKED BSS/RXCDR is INS.
If OMC link is down (indicated by both admin and op BSS or RXCDR is UNKNOWN.
states being zero)
All else BSS/RXCDR is OOS.
68P02900W36-P 2-87
1900.2AS May 2008
Real-time display Chapter 2: Using the NHA
Real-time display
For each device, the network display shows the number of devices out of service over the total
number of devices.
OOS indicator
The OOS Devices button on the network display changes color from gray to red if a device
goes OOS in the network.
Click the button on the network display window to display the Devices Currently OOS window.
This window lists all the devices currently out-of-service (OOS) and the time the device went
out-of-service. The list of devices is sorted with the most recent to go OOS at the top.
When the Devices Currently OOS window is closed, the button (OOS Indicator) reverts to
gray from red.
2-88 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing INSM reports
INSM reports identify the states of RF devices in a GSM network. This section describes the
following tasks:
• Displaying a configuration report
This report provides a graphical display of the associated Sites, Cells, RTFs, and DRIs for
a selected BSS.
68P02900W36-P 2-89
1900.2AS May 2008
Displaying an OOS report Chapter 2: Using the NHA
The INSM OOS reports are used to identify what devices are out-of-service, why they are
out-of-service, and in some cases, how long they are out-of-service.
1 Select Show Network Display from the INSM menu. The Network Display
window is displayed.
2 Click a device in the INSM Network Display. An Options pop-up menu is
displayed as in Figure 2-31.
Continued
2-90 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Displaying an OOS report
68P02900W36-P 2-91
1900.2AS May 2008
Displaying a historical OOS report Chapter 2: Using the NHA
The INSM tool produces reports giving all the OOS information applicable to a device. To
produce a historical OOS report, use the following steps:
1 Select the Historical OOS Report option from the Reports menu. An OOS
History window is displayed as in Figure 2-33.
2 Select the device(s) to be reported.
3 Select the time period.
BSS_F / Site_10
Total OOS Time = 2.7
11/06/2004 17:30:00 - 2.7
2-92 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Scheduled OOS reports
Every hour, the NHA produces a report of the devices that are currently OOS. These reports are
written to the OMC-specific log directory /usr/gsm/OMCs/<omcname>/ea_logs/ for seven
device types (Sites, Cells, DRIs, RTFs, RSLs, OMLs, and MTLs). These filenames are named in
the format oos_[devicetype]s.csv.
68P02900W36-P 2-93
1900.2AS May 2008
Scheduled OOS reports Chapter 2: Using the NHA
These reports can be turned on and off by editing the OMC-specific ea.cfg file
(/usr/gsm/OMCs/<omcname>/config/ea.cfg) and setting the SCHEDULED-OOS-REPORTS
variable to either ON or OFF.
2-94 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Manually blacklisting a device on the network display
Introduction to blacklisting
Certain problematic devices can be excluded from the INSM display or from the Problem
window when monitoring the network, for example, test BSSs or Sites.
In addition to being able to blacklist a device manually from the INSM display, operators can
blacklist devices manually from the Problem pop-up menu and the Cell View window. Operators
can also remove devices from the blacklist on the Blacklist window. Devices can also be
blacklisted automatically.
To remove a device from the blacklist, select Blacklist - View/Modify Blacklist from the
Configure menu on the NHA UI. Alternatively, it is possible to remove a blacklisted device from
the Configuration Report in the INSM display.
68P02900W36-P 2-95
1900.2AS May 2008
Using Worst Cells Chapter 2: Using the NHA
The Worst Cells function allows users to view a report of the worst cells, ordered by
selected criteria, on the Worst Cells window. This window displays the list of cells and their
corresponding key and raw statistics.
Select the Worst Cells option from the Tools menu on the main Problem UI window. The Worst
Cells Filter window is displayed as in Figure 2-34. Users can display the worst cells for a
specific set of criteria selected from the Worst Cells Filter window (for example, Call Setup
Success Rate as in Figure 2-34).
2-96 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Displaying the worst cells
Selecting criteria
From the Worst Cells Filter window, select a key or raw statistic from the list of statistics
available and select the criteria for calculating the worst cells as follows:
• OMCs
Select a specific OMC or all OMCs connected to the NHA from the list. The default is All.
• Statistic
Select from the list of available key and raw statistics. The default is Call Setup Success
Rate.
• Worst values
Select the order of the cells to be displayed, according to the highest or lowest statistics
values. The default is Lowest.
68P02900W36-P 2-97
1900.2AS May 2008
Worst cells report Chapter 2: Using the NHA
• Statistic Interval
Select statistics to be displayed that are collected from either the last interval or from
24 intervals. The default is Last Interval.
• Cell group
Select a specific cell group or all cell groups from the list. The default is All.
Select the raw statistic to be displayed from the list of available statistics, and select the
operator and value. The default is TOTAL_CALLS >= 0.
When all the criteria have been selected on the Worst Cells Filter window, click OK. The Worst
Cells window is then displayed as in Figure 2-35.
The time-stamp indicates the interval range from which the statistics have been compiled. If
there are not enough statistics stored in the OMC, a message is displayed to notify the user
and the Worst Cell window has the word (Incomplete) appended to the time-stamp. If statistics
are missing in one or more of the statistic intervals, an asterisk * is displayed on the row for
those cells.
Users can print details of the worst cells displayed, export worst cell details to a CSV file, copy
worst cell details to another document, or reconfigure the filtering criteria from the Worst Cells
window. Refer to Table 2-21 for further information about menu options.
2-98 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring the Worst Cells feature
Menu Select To
File Print displayed Print details of the worst cells displayed.
Export displayed Export the information in the Worst Cells
window into a CSV file. The default path
is in /usr/gsm/ea_logs/. The file format is
WCmmdd-hhmmss.csv.
Edit Copy Copy and paste the selected cells to any other
document.
Configure Worst Cells Filter Reselect the filter criteria.
Depending on the key or raw statistic selected on the Worst Cells Filter, an additional standard
set of key statistics associated with each statistic is displayed on the Worst Cells window. This
additional standard set of key statistics is specified in a CSV file stored on the NHA server
at /usr/gsm/config/local/formulaSet.csv.
If the selected statistic is not found in formulaSet.csv, then a default set of formulae also
specified in the formulaSet.csv file is displayed. Additionally, if the formulaSet.csv file does
not exist, a hardcoded default set of formulae is used to display worst cell information for
any statistic selected.
68P02900W36-P 2-99
1900.2AS May 2008
Using the Scoreboard feature Chapter 2: Using the NHA
The NHA Scoreboard feature allows users to view a report of the worst cells in the network
based on a ranking formula whose default value is:
1 From the Tools menu on the Problem window, select the Scoreboard option.
The Scoreboard Filter window is then displayed as in Figure 2-36.
Continued
2-100 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Printing and exporting Scoreboard details
Details of the Scoreboard can be printed, exported to a CSV file or recalculated from the
Scoreboard window. Refer to Table 2-22 for further information about menu options.
Menu Select To
File Print displayed Print details of the cells displayed on the
Scoreboard window.
Export Displayed Export the information in the Scoreboard
window into a CSV file. The default path
is in /usr/gsm/ea_logs/. The file format is
SCmmdd-hhmmss.csv.
Tools Refresh Recalculate the scoreboard for the currently
selected OMCs, using the same number of cells.
68P02900W36-P 2-101
1900.2AS May 2008
Frequency Clash Report Chapter 2: Using the NHA
The Frequency Clash Report displays co-channel and adjacent channel frequency clashes for
each source/neighbor pairing, thus highlighting areas of possible interference. This report is for
non-hopping carriers only.
Operators can generate the report by selecting the Frequency Clash option from the Tools
menu on the Problem window.
2-102 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Report details
Report details
The report is available in two formats: an HTML version and a text version. Operators can
change the selected format from the View format drop-down menu on the report. Operators can
also switch between OMCs from the Select OMC drop-down menu on the report.
Data for the report is created daily at or around midnight when the NHA searches through each
source cell/neighbor relation in each OMC and displays clashing frequencies for non-hopping
carriers for all carrier types, both BCCH and non-BCCH.
For each pair of carriers with clashing frequencies, the report shows the BSIC, the carrier type
and the clashing frequency. It also shows the hopping status of the carrier and the BCCH
frequency.
The data contained in the most recent frequency clash report can be found at
/usr/gsm/OMCs/<omcname>/ea_logs/FreqClashes.csv.
68P02900W36-P 2-103
1900.2AS May 2008
Conguring the NHA Chapter 2: Using the NHA
The following options are available from the Configure menu on the NHA UI (as in Figure 2-39
below):
• Cell Grouping - refer to Cell grouping on page 2-106
• Report to OMC - refer to Reporting NHA problems to the OMC as alarms on page
2-161
2-104 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Introduction to the Congure menu
68P02900W36-P 2-105
1900.2AS May 2008
Cell grouping Chapter 2: Using the NHA
Cell grouping
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The NHA is designed to compare the performance of cells as measured by various formulae
against a series of thresholds. Since all cells are not the same, it does not make sense to apply
the same criteria to all cells. There are different expectations for different cells. For example, in
a city cell with good coverage there are normally few dropped calls, whereas in a rural cell with
poor coverage, some dropped calls can be expected. As a result, the NHA uses Cell Groups to
group cells in the network that behave similarly. The NHA administrator must choose a strategy
for allocating cells to cell groups that contain cells with similar characteristics.
Users can view cell groups in the Cell View window. From the Configure menu, select the Cell
Grouping-Open Cell Grouping option. Select the required OMC and click OK to open the Cell
View window as in Figure 2-40.
2-106 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Manual and Automatic Cell Groups
To take advantage of the Automatic Cell Grouping feature, each cell group is assigned to either
a MANUAL cell group or an AUTOMATIC cell group.
MANUAL cell groups are cell groups set up to contain cells that are NOT regrouped
automatically by the Automatic Cell Grouping feature. Typically these cell groups are those
containing cells to be grouped based on specific local knowledge.
For example, the VIP cell group can contain important cells that require special attention and
strict thresholds. The FRINGE cell group contains cells that are on the fringe of coverage and
can expect to have looser thresholds. The NHA administrator must select the cells manually to
be put in these cell groups.
68P02900W36-P 2-107
1900.2AS May 2008
Default cell groups Chapter 2: Using the NHA
AUTOMATIC cell groups are cell groups set up to contain cells to be regrouped automatically by
the Automatic Cell Grouping feature. Typically these cell groups are those containing cells that
do not need to be grouped based on specific local knowledge.
For example, the BUSY, NORMAL, and QUIET cell groups contain cells which can be assigned
automatically to the appropriate cell group based on the results of a script that measures traffic
usage. The MICRO or DCS1800 groups can be set up as AUTOMATIC cell groups if there are
Automatic Cell Grouping scripts set up to identify Micro cells or DCS 1800 cells. If there are
no scripts and the administrator picks out those cells manually, based on local knowledge,
then set the cells as MANUAL cell groups.
When the NHA is shipped, there are six cell groups provided. The cell groups BUSY, NORMAL,
QUIET, and DEFAULT are defined as AUTOMATIC cell groups, while the cell groups MICRO and
FRINGE are defined as MANUAL cell groups.
NOTE
Currently, there is no Modify group type menu option. Refer to Configuring
group properties on page 2-110 to change the type of a group from MANUAL to
AUTOMATIC.
The NHA contains six cell groups (BUSY, NORMAL, QUIET, MICRO, FRINGE, and DEFAULT),
with default thresholds set up for each. Initially all cells are grouped in the DEFAULT cell group.
This group is set up with thresholds that apply equally to all cells.
Later the NHA administrator can allocate each cell in the network to be monitored in a more
suitable cell group. For example, the administrator can move a busy cell from the DEFAULT
cell group to the BUSY cell group.
Also, the NHA administrator can add and define additional cell groups using the Add Cell
Group or the Import button on the Group Properties window. Any number of cell groups can be
created, however, a cell can only exist in one group at a time.
New cells or reparented cells are moved to the DEFAULT group until they are regrouped.
There are four methods of moving cells from one cell group to another. These methods are:
• Manually using Modify Cell Grouping
2-108 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Moving cells from one group to another
All users have Read Only permissions and can view cell grouping settings. However, access to
creating and modifying cell groups is user-protected. Refer to Permissions and security on
page 2-5 for further information on security levels. Authorized users can modify cell grouping
properties by selecting the Edit button. The user is then in Edit mode which is indicated in red
on the Cell View window. Only one user can be in Edit mode at any one time. Edit mode is
automatically surrendered when the user closes the Cell View window.
68P02900W36-P 2-109
1900.2AS May 2008
Conguring group properties Chapter 2: Using the NHA
The Group Properties window displays a summary of the cell groups on the NHA for all OMCs
being monitored as in Figure 2-41 below:
All users have Read Only permissions and can view Group Properties settings. However, access
to creating and modifying cell groups is user protected. Refer to Permissions and security on
page 2-5 for further information on security levels. Authorized users can modify cell grouping
properties by selecting the Edit button. The user is then in Edit mode which is indicated in red
on the Cell View window. Only one user can be in Edit mode at any one time. Edit mode is
automatically surrendered when the user closes the Group Properties window.
2-110 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating cell groups on the NHA
To create a cell group on the NHA system, use the following steps:
68P02900W36-P 2-111
1900.2AS May 2008
Changing groups from Manual to Automatic Chapter 2: Using the NHA
To change the type of a group from MANUAL to AUTOMATIC or from AUTOMATIC to MANUAL,
thus allowing it to be automatically regrouped, use the following steps:
To export Cell Group Names to a file, select the Configure-Group Properties menu option to
open the Group Properties window. Click the Export button to open the Export To File dialog
box. Enter the file name at the prompt and click the Export button again. The cell group names
are written to the file in comma-separated lines.
Import Cell Group Names from a file by selecting the Configureà àGroup Properties menu
option. The Group Properties window is displayed. In Edit mode, click the Import button to
open the Import Group Names window as shown in Figure 2-43. Click OK to display the Import
Cell Grouping window, as shown in Figure 2-44. A warning message on the window alerts
users that choosing this action overwrites the current cell grouping. Select the OMC to which
the cell groups are to be imported and click the Start button.
2-112 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Importing cell group names
68P02900W36-P 2-113
1900.2AS May 2008
Importing cell group names Chapter 2: Using the NHA
The cell group names are read from the file to the NHA, assuming that the lines in the file are
in the correct format (see the following example). Error messages, if any, are written to the
OMC-specific eaAudit file (for example, /usr/gsm/OMCs/omcone/ea_logs/eaAudit20010415).
Check this file for error messages.
The format of the Export and Import file uses the first line as a header line and the remainder of
lines in the following comma separated format: OMC, Group Name, Cell Grouping Type (where
grouping type is AUTOMATIC or MANUAL).
For example:
Version:1800.EA.2BS
OMC,Group Name,Cell Grouping type
OMC1,QUIET,AUTOMATIC
OMC1,NORMAL,AUTOMATIC
OMC2,VIP,MANUAL
OMC2,QUIET,AUTOMATIC
When the NHA is being used to monitor multiple OMCs, it is useful to Export Cell Group Names
from one OMC and import them into another to keep the cell group names consistent across all
OMCs. These functions are also used during NHA upgrades to save configurable values.
2-114 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Manual cell grouping
Cells can be manually assigned to Cell Groups in two ways from the Cell View window:
• Using the Open Cell Grouping option from the Configure menu and moving cells one by
one from one group to another.
• Using the Import Cell Grouping option from the Configure menu and importing a cell
group file to move a number of cells in one action.
To move cells between groups on the NHA system, use the following steps:
1 From the Configure menu, select the Cell Grouping-Open Cell Grouping
option as in Figure 2-47.The Open Cell Grouping window is displayed as
in Figure 2-45.
Continued
68P02900W36-P 2-115
1900.2AS May 2008
Manually moving cells between groups Chapter 2: Using the NHA
If necessary, select from the range of Filter options available. Cells can be
filtered by BSS, site, cell name, or GSM cell id. Other filtering options
are available from the two drop-down lists in the Includes section.
The first list allows users to include:
• All cells
• Blacklisted cells
Continued
2-116 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Manually moving cells between groups
• No. of probs
The Cell View window is then displayed as in Figure 2-40. From here, it is
possible to view groups or run additional features. By default, the sort order
of the devices is by OMC, BSS, Site, and Cell.
4 In Edit mode, select the cell or group of cells to be changed and select the
group they are to be moved to from the list.
5 When OK is clicked, a confirmation window is displayed as in
Figure 2-46. Click Yes to save the changes and close the
window. Click No to discard the changes and close the window.
When Apply is clicked, a confirmation window is displayed as in
Figure 2-46. Click Yes to apply the changes without closing the window.
Click No to discard the changes and keep the window.
NOTE
It is recommended that the user progressively saves the group changes made to cells.
This is to reduce the time taken for the saving operation to be completed.
68P02900W36-P 2-117
1900.2AS May 2008
Additional features of the Cell View window Chapter 2: Using the NHA
2-118 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional features of the Cell View window
Menu options
Menu Select To
File Print displayed Print the list of cell group details displayed on the Cell View
window.
Export Displayed Export selected cell group details displayed on the Cell View
window.
Export All Export all cell group details on the Cell View window.
Close Exit from the Cell View window.
Edit Cut Currently unavailable.
Copy Copy selected cells from the list displayed on the Cell View
window
Paste Currently unavailable.
Find Search for a particular cell on the Cell View window.
View Columns View the list of cells by OMC, BSS, Site, Cell Name, GSM
Cell Id, Group, Number of Problems (raised against the
selected cell) and Number of Neighbor Problems (raised
against the neighbor cells of the selected cell). Check or
uncheck the columns required.
Grouping Edit Mode Modify cell grouping properties.
Change Group Move selected cells from one group to another (in Edit
mode).
Filter Open the Open Cell Grouping window.
In Edit mode, right click the Cell View window to access the Cell Grouping pop-up menu. The
options available are displayed in Table 2-24:
Select To
Add to Blacklist Blacklist a BSS, Site, or Cell.
Action Scripts Run a user-defined Action script on the selected cell or problem.
Site Health Check Create a Site Health Check report for a BTS Site and its cells.
BSS Detector Check View a list of BSS level detectors' values from the last interval,
based on any BSS connected to the OMC.
Problems on Device List the problems raised against the selected cell. Each problem
is displayed as a separate menu option which, when selected,
opens the Problem Information window. Refer to Problem
Information window on page 2-32 for more information.
Continued
68P02900W36-P 2-119
1900.2AS May 2008
Exporting cell group les Chapter 2: Using the NHA
Cell groups can be exported to a file using the File-Export Displayed menu option
as in Figure 2-48. The operator is prompted for a filename. When selected, the cell
group details are written to the file in comma separated lines. The default location is
/usr/gsm/ea_logs/CG<dates>.csv. This file can now be viewed and manipulated externally to
the NHA, for example, by using a commercially available spreadsheet.
All cell groups can be exported to a file using the File-Export All menu option. The operator is
prompted for a filename and, when selected, details are written to the file in comma separated
lines. The default location is /usr/gsm/ea_logs/cellgrp.csv. This file can now be viewed and
manipulated externally to the NHA, for example, using a commercially available spreadsheet.
Cell Group Details can be imported from a file by selecting the Cell Grouping-Import Cell
Grouping option from the Configure menu. The operator is prompted for a filename and, when
selected, the cell group details are read from the file to the NHA, assuming that the lines in the
file are in the correct format (see the example below).
2-120 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Importing cell group les
Error messages, if any, are written to the OMC specific eaAudit file (for example,
/usr/gsm/OMCs/omcone/ea_logs/eaAudit20010415). Check this file for any errors.
Details of the cells that have changed groups are written to the OMC specific Cell Grouping log
(for example, /usr/gsm/OMCs/omcone/ea_logs/eaCellGrouping20010415). Check this file
to ensure that the intended action took place.
The format used for the Export and the correct format for the Import file is a file with the first
line as a header line and the remainder of lines in the following comma separated format:
OMC, BSS, Site, Cell GSMCellid, Group Name.
For example:
Version: 1800.EA.2BS
OMC,BSS,Site,Cell GSMCellid,Group Name
OMC1,BSS_City,Site_Suburb_1,123-45-1-100,DCS1800
OMC1,BSS_City,Site_Suburb_1,123-45-1-101,DCS1800
OMC1,BSS_City,Site_Suburb_1,123-45-1-102,DCS1800
OMC2,BSS_City,Site_Suburb_2,123-45-1-103,BUSY
OMC2,BSS_City,Site_Suburb_2,123-45-1-104,QUIET
OMC2,BSS_City,Site_Suburb_2,123-45-1-105,NORMAL
NOTE
The Import Cell Grouping functionality does not work on devices containing
the characters tilde (~), comma (,), apostrophe ('), or at-sign (@) in the
cell import group functionality on devices (BSSs, RXCDRs, Sites, or Cells).
Therefore, do NOT use the tilde, comma, apostrophe, or at-sign characters when
naming devices on the OMC. However, if it is necessary to use these characters then,
using the Cell View window, group the affected cells one by one.
68P02900W36-P 2-121
1900.2AS May 2008
Automatic cell grouping Chapter 2: Using the NHA
Using the Automatic cell grouping feature, the NHA is configured to assign cells automatically
to NHA cell groups. This functionality ensures that the administrative task of assigning cells to
NHA cell groups is easier and the cell groups are always up to date.
When cell grouping is performed manually on the Cell View window by importing files of cell
groups, diligence and care is required to ensure the most up to date configuration and traffic
patterns are used.
Using the Automatic cell grouping feature, the administrator can define scripts that allow the
cell grouping to be done automatically according to a defined strategy. This strategy can be
implemented by selecting Cell Grouping-Regroup Cells Automatically from the Configure
menu to run the scripts at any time or by choosing to have the scripts run daily. The feature also
allows for cells to be excluded from the Automatic grouping and to remain in the Manual cell
groups, for example, VIP or FRINGE cell groups.
For example, take the scenario where the administrator wants to maintain the following Cell
Groups, each with different thresholds.
BUSY - Cells which carry an average of greater than four Erlangs of traffic.
NORMAL - Cells which carry an average of between one and four Erlangs of traffic.
QUIET - Cells which carry an average of less than one Erlangs of traffic.
DCS1800 - DCS 1800 cells, no matter how much traffic they carry.
VIP - Cells which need constant monitoring to tight thresholds as they are very important.
FRINGE - Cells which are in geographical areas where bad coverage is expected (for example,
mountainous areas, international borders, and so on).
DEFAULT - Cells which are newly added and do not have characteristics defined.
2-122 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Automatic cell grouping scripts
Administrators can set up the preceding cell groups in the following way:
1 Define the VIP and FRINGE groups as MANUAL groups and populate them
based on local knowledge, using the Cell View window. Define the other
groups as AUTOMATIC to allow cells to be allocated automatically to groups.
2 Set up a script that interrogates the OMC CM MIB database to
identify DCS 1800 cells. A sample script is provided for this at
/usr/gsm/current/ea_tools/dcs1800.sh.
3 Use the standard NHA traffic usage script to identify which cells are BUSY,
NORMAL, or QUIET. By default, this script is always run.
4 Once the setup is complete, run Cell Grouping by selecting the Open
Cell Grouping menu option from the Configure menu OR configure Cell
Grouping to be run automatically every day.
As a result, general cells are assigned to BUSY, NORMAL or QUIET groups automatically as
traffic patterns change. DCS1800 cells are automatically identified and grouped. Cells in
VIP and FRINGE groups remain in their groups unless manually removed. New cells go to
the DEFAULT group initially, then are grouped automatically to BUSY, NORMAL, QUIET, or
DEFAULT unless they are put in the VIP or FRINGE cell group manually.
68P02900W36-P 2-123
1900.2AS May 2008
Manually running automatic cell grouping Chapter 2: Using the NHA
The automatic cell grouping feature can be run manually at any time using the Cell Grouping
- Regroup Cells Automatically menu option from the Configure menu. When this option
is selected, the cell grouping scripts are run. The cell groups of all cells that are in type
AUTOMATIC cell groups and are not blacklisted are updated, based on the results of the scripts.
Cells that are in cell groups of type MANUAL are unaffected.
1 Ensure that any user-defined cell grouping scripts to be run are in place
in the directory /usr/gsm/OMCs/<omcname>/nha_grouping/.
Continued
2-124 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring the NHA to run automatic cell grouping manually
NOTE
If there are no user-defined cell grouping scripts, then the
automatic cell grouping is run only on the basis of the default
traffic usage script (/usr/gsm/current/ea_tools/ea_group.sh).
2 Select the Cell Grouping-Regroup Cells Automatically menu option from
the Configure menu. The Regroup Cells Automatically window is displayed
as in Figure 2-49.
3 Press the Edit Mode button to go into edit mode, then select the
OMC on which the cells are to be regrouped automatically.
That is, when the cell grouping scripts run, all cells that were in AUTOMATIC
cell groups and not blacklisted are regrouped according to the scripts. Refer
to Background functionality on page 2-126 for further details.
Continued
68P02900W36-P 2-125
1900.2AS May 2008
Background functionality Chapter 2: Using the NHA
• View the contents of each cell group on the Cell View window and
check the cell groups reported for cells with problems on the Problem
window.
• Check for cells that change groups in the NHA Cell Grouping logs:
/usr/gsm/OMCs/<omcname>/ea_logs/eaCellGrouping<date>.
• Check for errors in the overall cell grouping process in the NHA audit
logs: /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<date>.
Background functionality
The following steps occur automatically when the Regroup Cells Automatically menu option is
selected:
1. Two files are created in directory /usr/gsm/OMCs/<omcname>/nha_grouping/.
exportgroup.csv contains a list of all cells in AUTOMATIC groups (these cells are
regrouped automatically).
NOTE
To run DCS1800.sh, rename it as autogroupDCS1800.sh.
5. After the next NHA analysis period (typically at hh:30 or hh:00, but at least 30 minutes
after the option is selected) the NHA imports the file importgroup.csv so the cell
grouping is updated.
2-126 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Background functionality
6. Temporary files used in the automatic cell grouping process are tidied up.
7. The NHA detectors use the new cell grouping in the next NHA analysis period. This occurs
typically within an hour of the option being selected.
68P02900W36-P 2-127
1900.2AS May 2008
Automatically running automatic cell grouping Chapter 2: Using the NHA
The Automatic Cell Grouping feature can be configured to be run automatically once a day.
When this feature is configured, every day at the chosen time, the NHA runs the cell grouping
scripts. Based on the results of the scripts, it automatically updates the cell groups of all cells
that are in AUTOMATIC type cell groups and are not blacklisted. Cells in MANUAL type cell
groups are unaffected.
• Background functionality
To configure the NHA to run automatic cell grouping automatically, perform the following steps:
Change the value for AUTO-EXPORT-TIME to the hour that the scripts are
scheduled to start, for example, 4 for 4:00 AM, 23 for 11:00 PM.
Stop and restart the NHA (using the menu option on the NHA UI) so
that the updated values in the OMC-specific NHA configuration
file are read in and become effective.
Continued
2-128 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring the NHA to run automatic cell grouping automatically
NOTE
68P02900W36-P 2-129
1900.2AS May 2008
Background functionality Chapter 2: Using the NHA
Background functionality
2. The script /usr/gsm/current/ea_tools/ea_group.sh is run (on all cells) with output based
on traffic usage going to /usr/gsm/OMCs/<omcname>/ea_logs/ea_group.csv.
NOTE
To run DCS1800.sh, rename it to autogroupDCS1800.sh; if not renamed,
the script does not run.
5. After the next NHA analysis period (typically one hour after the AUTO-EXPORT-TIME),
if AUTO-IMPORT-ON is ON then the NHA imports the file importgroup.csv so the
cell grouping is updated.
6. Temporary files used by the Automatic Cell Grouping are tidied up.
7. The NHA detectors use the new cell grouping at the following NHA analysis period:
typically, 50 minutes after AUTO-EXPORT-TIME for networks with 30-minute statistic
intervals and 1 hour and 20 minutes after AUTO-EXPORT-TIME for networks with
60-minute statistic intervals.
The cell grouping happens automatically but it is recommended that the administrator checks
the intended results of the Automatic Cell Grouping.
2-130 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Scripts for automatic cell grouping
1 View the contents of each cell group on the NHA UI and check the cell
groups reported for cells with problems on the Problem window.
2 Check for cells that change groups in the NHA Cell Grouping logs:
/usr/gsm/OMCs/<omcname>/ea_logs/eaCellGrouping<date>
3 Check for errors in the overall cell grouping process in the NHA audit logs:
/usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<date>
4 Check for errors in the scripts in the files in the NHA automatic cell grouping
logs: /usr/gsm/OMCs/<omcname>/ea_logs/autogrouping<date>
NHA administrators can define custom scripts to be included as part of the automatic cell
grouping cycle using the following guidelines:
Continued
68P02900W36-P 2-131
1900.2AS May 2008
Multiple OMC systems Chapter 2: Using the NHA
NOTE
It is good practice to debug scripts by running them manually
before scheduling them to be run in the automatic cell grouping
script.
Different cell grouping strategies can be defined on different OMCs, as each OMC has its
own nha_grouping directory. Ensure that the cell grouping scripts to be run on a particular
OMC are copied to the correct OMC directory.
To use the same automatic cell grouping scripts on all OMCs, copy the scripts from one OMC
directory to another.
For example:
cd /usr/gsm/OMCs/[omctwo]/nha_grouping/
cp /usr/gsm/OMCs/[omcone]/nha_grouping/autogroup1.sh autogroup1.sh
2-132 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Modifying detectors and thresholds
Once the cells are grouped and the NHA has started raising a significant number and type of
problems against the network, the thresholds can be modified to improve the NHA detection
rate or to control the number of problems being raised.
The following list provides some basic guidelines that can be applied to each detector for each
group:
• If too few problems are being raised, loosen the threshold.
• If there are too many false alarms, increase the minimum sample size.
• If there are problems being missed, reduce the minimum sample size.
Modifying detectors is user protected, refer to Permissions and security on page 2-5 for
further information.
Continued
68P02900W36-P 2-133
1900.2AS May 2008
Modifying detector thresholds Chapter 2: Using the NHA
Detector thresholds can vary between cell groups and, within a cell group,
different detectors can be enabled and disabled.
4 Change the detector threshold values as appropriate:
NOTE
If the selected custom detector has been renamed or deleted by
another client while changes are being made, these changes are
not saved.
2-134 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Modifying detector thresholds
Users can enable a detector for all cell groups in one selection or change its configurable values
and apply the changes to all the cell groups displayed.
Bulk changes can be made using the one-row spreadsheet on the bottom of the Thresholds
window. Select the OMC and Group to be modified and enter the new values. When configurable
values of the detector in this row are modified, the changes can be made to the main threshold
spreadsheet using the Copy To Row(s) button.
68P02900W36-P 2-135
1900.2AS May 2008
Extra options on the Thresholds window Chapter 2: Using the NHA
The following menu options are also available on the Thresholds window. Refer to Table 2-25.
Table 2-25 Thresholds window - menu options
Menu Select To
File Print Displayed Print the detector thresholds displayed on the main Thresholds
window.
Export Displayed Export the detector thresholds displayed on the
main Thresholds window. The default location is
/usr/gsm/ea_logs/TH<date>.csv.
Export All Export all detector thresholds. The default location is
/usr/gsm/ea_logs/thres.csv.
Close Exit from the Thresholds window.
Edit Cut Currently unavailable.
Copy Copy selected detector thresholds from the Thresholds window.
Paste Currently unavailable.
View Columns View the list of detector thresholds by OMC, Group, Enabled,
and so on (according to detector type). Check or uncheck the
columns required.
Importing thresholds
To import detector thresholds into the OMC, use the following procedure:
Continued
2-136 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Importing thresholds
Continued
68P02900W36-P 2-137
1900.2AS May 2008
Automatic export and import of thresholds Chapter 2: Using the NHA
NOTE
A useful UNIX command for copying threshold files from one
OMC to another for re-importing is:
To configure the NHA to export and import thresholds automatically, edit the OMC-specific
configuration file /usr/gsm/OMCs/<omcname>/config/ea.cfg.
2-138 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring BSS Regions
BSS Regions s used to monitor problems on a defined subset of BSSs on the Problem window.
This section describes how to create, modify, view, delete, and verify BSS regions.
For information on configuring Cell Regions, refer to Configuring Cell Regions on page
2-142.
For information on configuring problem subscriptions for the Problem window, refer to
Configuring problem subscriptions on page 2-148.
1 Select BSS Regions from the Configure menu to display the BSS Regions
window.
2 Click the New button. The New Region dialog box is displayed.
3 Enter a new BSS Region Name and click OK. The New Region window is
displayed, as shown in Figure 2-53.
NOTE
Do not prefix BSS Region Name with
PROBLEMS-TO-REPORT-TO-OMC-.
4 Select the BSSs to be included in the new region list.
5 Click OK to create the BSS region.
68P02900W36-P 2-139
1900.2AS May 2008
Modifying or viewing a BSS region Chapter 2: Using the NHA
1 Open the BSS Regions window and select the BSS region to be modified.
2 Click the Modify button. The Modify BSS Region window is displayed.
3 Modify the region by selecting or deselecting a BSS.
4 Click OK to update the region and close the Modify BSS Region window.
2-140 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Deleting a BSS region
1 Select BSS Regions from the Configure menu to display the BSS Regions
window.
2 Select the BSS region to be removed.
3 Click Delete to delete the unwanted region.
A Verify button is provided on the BSS Regions window to recover from the error or if out of
sync with other NHA UI windows. It is unlikely to be needed. However, in the event of errors
occurring, this button can be used to verify that the BSSs are OK and attempt to recover from
the error or synchronize with other NHA UI windows.
The verify procedure takes a minute or two to complete. A message on the status line at the
bottom of the NHA UI indicates when it is completed.
68P02900W36-P 2-141
1900.2AS May 2008
Conguring Cell Regions Chapter 2: Using the NHA
The Cell Regions option is used to monitor problems on a small number of cell-based regions
on the Problem window. This section describes how to create, modify, view, delete, and verify
Cell regions.
For information on configuring BSS Regions, refer to Configuring BSS Regions on page
2-139.
For information on configuring problem subscriptions for the Problem window, refer to
Configuring problem subscriptions on page 2-148.
1 Select the Cell Regions option from the Configure menu to display the
Cell Regions window.
2 Click the New button. The Cell Regions dialog box is displayed.
3 Enter a Cell Region Name and click OK.
NOTE
Do not prefix Cell Region Name with
PROBLEMS-TO-REPORT-TO-OMC-.
Continued
2-142 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating a Cell region
Continued
68P02900W36-P 2-143
1900.2AS May 2008
Creating a Cell region Chapter 2: Using the NHA
This displays a list of all the cells in the selected BSS that satisfy the filtering
criteria.
Continued
2-144 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Modifying or viewing a Cell region
NOTE
The default value of MAX-NO-OF-CELL-SUB in the ea.cfg file
is 200.
1 Open the Cell Regions window and select the region to be modified.
2 Click the Modify button. The Modify Cell Region Confirmation window is
displayed as in Figure 2-56.
Continued
68P02900W36-P 2-145
1900.2AS May 2008
Modifying or viewing a Cell region Chapter 2: Using the NHA
3 To modify previously selected cells in BSSs in the cell region, click Yes.
To reselect cells for all the BSSs connected to all OMCs, select No.
4 Modify the cells to be included in the cell subscription.
5 Click OK to update the region and close the Modify Cell Region window.
2-146 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Deleting a Cell region
1 Select Cell Regions from the Configure menu to display the Cell Regions
window.
2 Select the Cell region to be removed.
3 Click Delete to delete the unwanted region.
A Verify button is provided on the Cell Regions window to recover from errors. It is not likely to
be needed. However, in the event of errors occurring, this button can be used to verify that the
BSSs are OK and attempt to recover from the error.
The verify procedure takes a minute or two to complete. A message on the status line at the
bottom of the NHA UI indicates when it is completed.
68P02900W36-P 2-147
1900.2AS May 2008
Conguring problem subscriptions Chapter 2: Using the NHA
Problem subscriptions are used to monitor a defined subset of problems on the Problem window.
This section describes how to create, modify, view, delete, and verify problem subscriptions.
For information on choosing subscriptions for the Problem window, refer to Subscriptions,
sorting, and filtering on page 2-18.
Continued
2-148 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating a problem subscription
NOTE
BSS level problem consolidated consists of all BSS <problem>
- consolidated problems. For further information, refer to
BSS-level detectors on page 3-164
5 Click OK to create the problem subscription list.
68P02900W36-P 2-149
1900.2AS May 2008
Modifying or viewing a problem subscription Chapter 2: Using the NHA
The verify procedure takes a minute or two to complete. A message on the status line at the
bottom of the NHA UI indicates when it is completed.
2-150 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst User-dened causes
User-dened causes
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
In some cases, the NHA operator is familiar with the cause of a problem which is particular to
the host network. If the NHA has not documented this local cause, the administrator can enter a
description of the cause and a corrective action.
This user-defined cause can be edited and deleted as required. If a user-defined cause is
deleted, then all existing problems of that type no longer show the cause. Creating, editing, and
deleting user-defined causes is only open to NHA users with omcadmin access.
When a user-defined cause is defined for a problem type it can be viewed for all problems of that
problem type. An indicator on the cause name (UC) identifies that it is a local cause.
Use the user-defined causes option where a custom problem has been created to provide
additional information on the newly created problem.
Access to creating and modifying user-defined causes is user protected, refer to Permissions
and security on page 2-5 for further information.
68P02900W36-P 2-151
1900.2AS May 2008
Adding a user-dened cause Chapter 2: Using the NHA
1 Select the User defined causes option from the Configure menu. The User
Defined Causes window (Figure 2-58) is displayed. This window shows a
list of all NHA problems and all user-defined causes.
Continued
2-152 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Adding a user-dened cause
Continued
68P02900W36-P 2-153
1900.2AS May 2008
Editing a user-dened cause Chapter 2: Using the NHA
• Confidence factor
1 Select the User defined causes option from the Configure menu. The User
Defined Causes window (Figure 2-58) is displayed. This window shows a
list of all NHA problems and all user-defined causes.
2 Click the cause and select Corrective action from the pop-up menu. The
Corrective Action window is displayed as in Figure 2-59.
3 Edit the details of the cause.
4 Click OK. If any changes have been made, a confirmation dialogue is
displayed. Click Yes to save changes and update the NHA with the new
cause information.
1 Select the User defined causes option from the Configure menu. The User
Defined Causes window (Figure 2-58) is displayed. This window shows a
list of all NHA problems and all user-defined causes.
2 Click the required cause and select Corrective action from the pop-up
menu. The Corrective Action window is displayed as in Figure 2-59.
3 Click Delete. A Confirmation dialog box is displayed.
4 Click Yes to delete the cause from the NHA.
2-154 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Statistics per problem
To view statistics per problem, select the Stats Per Problem option from the Configure menu
on the Problem window. The Select Problem window is displayed as in Figure 2-60. Select
the required problem and click OK.
The Statistics Selection window is then displayed as in Figure 2-61. Additional statistics
for the problem can be selected using the procedure outlined in Neighbor Cell statistics
on page 2-156.
Click the Prob Help button on the Select Problem window to display Help for the selected
problem. Click the Help button to display Help for viewing statistics per problem.
68P02900W36-P 2-155
1900.2AS May 2008
Neighbor Cell statistics Chapter 2: Using the NHA
To configure and view neighbor cell statistics for the problem, use the following steps:
1 Select the Neighbor Cell Statistics option from the Configure menu to
open the Statistics Selection window as in Figure 2-61.
2 Click the Key stats or Cell tab.
2-156 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Blacklisting devices
Blacklisting devices
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Select the Blacklist option on the Configure menu to configure and view blacklisted devices.
When this option is selected, a submenu is displayed as follows:
• View/Modify Blacklist
Select this option to display the Blacklisted Devices window.
• Export Blacklist
Select this option to display the Export to File dialog box.
• Import Blacklist
Select this option to display the Import Blacklist dialog box.
• Automatic Blacklist
Select this option to display the Confirm Automatic Import dialog box.
From the Configure menu on the Problem window, select the Blacklist - View/Modify
Blacklist option. The Blacklisted Devices window opens and the list of blacklisted devices is
displayed as in Figure 2-62.
To remove a device from the blacklist, right-click the required row and select Remove from
Blacklist from the pop-up menu. Click Close to return to the Problem window.
For information about adding devices to the blacklist, refer to Manually blacklisting a device
on the network display on page 2-95 and Automatic blacklisting on page 1-24.
68P02900W36-P 2-157
1900.2AS May 2008
Exporting blacklist details Chapter 2: Using the NHA
From the Blacklisted Devices window, it is possible to create a Site Health Check report for a
device. Right-click the selected row and select Site Health Check from the pop-up menu.
For further information about using the Site Health Check feature and viewing the report,
refer to Site Health Check on page 2-76.
NOTE
If the selected row is BSS/RXCDR, the Site Health Check option is disabled.
From the Blacklisted Devices window, it is possible to generate a BSS Detector Check report.
Right-click the selected row and select BSS Detector Check from the pop-up menu.
For further information about using the BSS Detector Check feature and viewing the report,
refer to BSS Detector Check on page 2-81.
NOTE
If the selected row is RXCDR, the BSS Detector Check option is disabled.
To export blacklist details to a .csv file, select the Blacklist-Export Blacklist option from the
Configure menu on the Problem window. The Export to File dialog box is then displayed as in
Figure 2-63. The default export location is: /usr/gsm/ea_logs/BL[mmdd-hhmmss].csv.
Click Export to continue.
2-158 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Importing blacklist details
Blacklist details can be imported from a file using the Blacklist-Import Blacklist option from
the Configure menu on the Problem window. The Import Blacklist dialog box is then displayed
as in Figure 2-64. Click Import to continue.
68P02900W36-P 2-159
1900.2AS May 2008
Daily Export Chapter 2: Using the NHA
Daily Export
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
By choosing this option, an administrator can configure the Daily Export feature for all OMCs
that are monitored by the NHA. The administrator can:
• Turn the Daily Export feature on or off.
By default, the daily export feature is turned on and the time to export is scheduled for
04: 00.
Note the Daily Export feature also affects the Cyclic Neighbor Statistics feature which relies
on the Daily Export report to run. Refer to Cyclic Neighbor Statistics on page 2-211 for
further information.
Select the Daily Export option from the Configure menu on the Problem window to open
the Daily Export dialog box as in Figure 2-66.
To set up the daily export, select the Daily Export check box. Enter the time to export and
click OK.
For further information about using daily reports, refer to Exporting and printing problem
reports on page 2-59.
2-160 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Reporting NHA problems to the OMC as alarms
Use the Report to OMC option to turn on and off the reporting NHA problems to the OMC as
alarms feature. Select Report to OMC from the Configure menu on the Problem window to open
the Report to OMC dialog box as in Figure 2-67.
If the feature is turned on in the OMC-specific configuration file, then the administrator can
select the required options and click OK to allow alarms to be sent from the NHA to that OMC-R.
If the feature is turned off in the OMC-specific configuration file, then the option for that OMC
is grayed out as in Figure 2-67.
For example, in Figure 2-67 the feature is turned off in the omc1 OMC-specific configuration
file and it is turned on for somc37 and 3002. Therefore, alarms are sent to OMC 3002 but not
to OMCs somc37 or omc1.
For further information about sending NHA problems to the OMC as alarms, refer to Viewing
problems as alarms on the OMC on page 4-51.
68P02900W36-P 2-161
1900.2AS May 2008
Editing Knowledge Chapter 2: Using the NHA
Editing Knowledge
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
2-162 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The Knowledge Editor
The Knowledge Editor enables the NHA operator to create and edit customized problem
detectors, and to create and edit the formula used by these detectors.
The formulae and detectors created are based on cell statistics read by the NHA, that is, the
statistics that can be viewed on the Statistics History window (and not carrier or GPROC
statistics).
A detector is a combination of formulae applied to raw statistical data coming in from devices
in a GSM network, raw statistics from these devices, and a detection mechanism used in
conjunction with the formula. Using the Detector Editor it is possible to custom-design detectors
focused on detecting problems on your network. Refer to Problem detection and monitoring
on page 1-4 for further information about detectors and the problem detection process.
The operator can also specify the details of the problems raised by these detectors, such as the
name of the problem, the severity of the problem, and the confidence factor for the problem.
The Knowledge Editor also enables the operator to combine up to five formulae and three
statistics in one detector. The multi-formula capability uses AND statements to allow the
operator to analyze several statistical criteria in one detector.
NOTE
The multi-formula capability only works with the following detection mechanism:
Fixed Threshold, Interval Roll-up, Daily Roll-up.
Creating and modifying custom detectors and custom formula is user protected. For further
information, refer to Permissions and security on page 2-5.
The Knowledge Editor is launched using the root menu option or selecting the OMC Knowledge
Editor option from the Tools menu on the main Problem window. The NHA Knowledge Editor is
then displayed.
There is one Knowledge Editor for each OMC being monitored (that is, not multi-OMCs).
It shares Edit Mode permissions with users of the NHA UI Configure menu options.
68P02900W36-P 2-163
1900.2AS May 2008
G2 interface limitations Chapter 2: Using the NHA
G2 interface limitations
The Knowledge Editor is currently developed in Gensym G2. As it is not a standard user
interface, some of the non-standard functions are described as follows:
• The Left, Right, and Centre mouse buttons all perform the same functions.
• To move a window within the user interface, click in a gray area in the window, then
hold and drag to move the window.
• To enlarge or reduce the size of the window, select the View - Larger or View - Smaller
menu items on the user interface.
• To bring the window to the top, select the View - Lift to top menu item on the user
interface.
• To close the main menu, click the black line at the top of the menu.
The Custom Detectors and Custom formulae window enables the export and import of detectors
and formulae respectively. The export function saves the information to a .csv file. This function
is useful for keeping a record of detectors created and also for upgrading to newer versions of
the NHA.
NOTE
A detector can only be imported if the formula it uses is already present.
2-164 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating custom formulae
The NHA uses custom formulae in conjunction with custom detectors. It is necessary to create
a custom formula before creating its corresponding custom detector. Using the Custom
formulae window, it is possible to select, edit, and export existing formula. Formulae are
exported to a comma separated value (.CSV) file and are also imported from such files.
68P02900W36-P 2-165
1900.2AS May 2008
Creating a custom formula Chapter 2: Using the NHA
1 Select the Custom formula option from the Configure menu on the NHA UI.
The Custom Formulae window (Figure 2-68) is displayed.
2 Click the New button to open the Formula
Editor window. Refer to Figure 2-69.
A window is displayed with two fields: Formula Name
and a blank field. The Formula Name field allows users to enter a name for a
new formula. The blank field is empty when a new formula is about to be
created and lists each version of the formula. Different formula versions
can be defined for the different BSS software loaded on the network.
Any detector that uses this formula then applies the correct formula to
each BSS it encounters.
3 Click the New button in the Formula Editor window to open the Formula
Version Editor as displayed in Figure 2-70.
4 Create the formula in the Formula Version Editor. The Formula
Editor window allows you to define a name for this new formula.
The custom formula edit function is used to change the way custom problems are detected and
displayed on the Problem window.
2-166 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Editing a custom formula
To edit a custom formula, open the Custom Formulae window and use the following steps:
68P02900W36-P 2-167
1900.2AS May 2008
Using the Formula Version Editor Chapter 2: Using the NHA
The Formula Version Editor window is used to create or edit the elements of the custom formula
and also to specify the BSS version of the formula.
• Numbers and mathematical operators (used in conjunction with the raw statistics to create
a mathematical expression).
Some formulae have different versions depending on the software release. For example, one for
1760 and another for 1800 and 1900.
A maximum of 20 formulae can be created, not including formula versions. That is, a formula
can have one or more versions.
NOTE
It is not possible to delete a formula that is in use by a detector.
2-168 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Building new formulae
NOTE
To remove one or more elements from the formula, select the
element to remove and click the remove button.
5 To identify one or more BSS versions applicable to the new formula:
NOTE
When the OK button is clicked, the NHA validates the input. If
the numerator or denominator do not form a valid mathematical
expression, the user is prompted to modify them.
68P02900W36-P 2-169
1900.2AS May 2008
Building new formulae Chapter 2: Using the NHA
2-170 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating a custom detector
The Custom Detectors window enables the NHA operator to create and edit detectors. When
creating a detector, the operator can copy the settings from an existing detector using the Clone
button. Before a custom detector can be created, the formula used by this detector must first
be created using the Custom Formulae window, Figure 2-68. Refer to Creating custom
formulae on page 2-165 for further information.
By default, custom detectors are disabled and their thresholds are set to zero. After they have
been created, custom detectors can be enabled and their thresholds set in the Thresholds
window.
For an example of how to create a custom detector, build a formula and apply threshold values,
refer to Example of a custom detector on page 2-176.
68P02900W36-P 2-171
1900.2AS May 2008
Creating custom detectors Chapter 2: Using the NHA
To create a custom detector, select the Custom Detector option from the Configure menu on the
Knowledge Editor. The Custom Detectors window (Figure 2-71) is displayed.
1 Click the New button to display the Detector Editor window (Figure 2-72).
2 Enter the new detector name (used in the Thresholds window), anomaly
name (used internally), problem name (used when displaying a problem in
the Problem window), and severity in their respective fields.
3 Select a detection mechanism to be used. For a full description of each of the
detection mechanisms, refer to NHA detection mechanisms on page 1-8.
4 If the detector is to use Sample Roll-up or Sliding Scale, then select a single
formula. If the detector is to use any of the other detection mechanisms,
then use up to five formulae and three statistics.
Continued
2-172 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating custom detectors
NOTE
The formula and statistics use the AND statement. This statement
allows the operator to analyze various statistical criteria in one
detector.
5 Select the comparison type to compare the result of the formula against the
threshold value determined by the detection mechanism.
For example, the Call Success Rate problem is triggered if the result of the
Call Success Rate formula is less than or equal to (< =) the user-defined
threshold.
6 Enter a problem clearing time. If the problem does not re-occur during
the problem clearing timescale, then the problem is set to Cleared in the
Problem window.
The recommended problem clearing time is the interval time multiplied by
1.5.
7 Click the OK button to create the custom detector.
The current default value for configurable values on detectors in the Detector Editor is set to
0, for example, threshold = 0 and minimum sample = 0. If these values are not changed, the
result can be that many problems are raised. Therefore, it is important to set the threshold of
other configurable values on new detectors to an appropriate level to ensure that the detector
does not produce a large number of problems. For further information, refer to Modifying
detectors and thresholds on page 2-133.
68P02900W36-P 2-173
1900.2AS May 2008
Edit a custom detector Chapter 2: Using the NHA
The Custom Detector edit function is used to change the way custom problems are detected and
displayed on the Problem window.
To edit a custom detector, open the Custom Detectors window (Figure 2-72) then use the
following steps:
NOTE
Modifying a custom detector resets its thresholds to 0. Reset
these thresholds to their former values in the Thresholds window.
Refer to Modifying detectors and thresholds on page 2-133.
2-174 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Editing a custom detector
68P02900W36-P 2-175
1900.2AS May 2008
Example of a custom detector Chapter 2: Using the NHA
The following custom problem (under the headings Build the formula, Name the formula, Create
the detector) provides useful guidelines for the Knowledge Editor user. It includes a real
formula and specifies the detection mechanisms that can be used. When creating a detector, it
is recommended that it is activated on one OMC. When the detector has been validated, it can
then be imported into a multi-OMC environment.
2. Decide on a detector.
6. Monitor the problems raised by the new detector on the Thresholds window.
When creating a detector, work out the correct formula carefully as a badly constructed formula
could result in irrelevant problems swamping the NHA.
Perform the following procedures for creating a detector in the order in which they are listed:
2-176 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Build the formula
The following formula is intended as an example. The problem is named Call Success Rate.
Once the formula has been mapped on paper, use the Custom Formula Editor to create it in
the NHA as follows:
1 Select Knowledge Editor from the Tools menu in the main Problem
window. This action launches the Knowledge Editor.
2 Select the Custom Formula option from the Configure menu on the
Knowledge Editor.
3 Click the New button to open the Formula Editor window. The Custom
Formulae window is displayed, Figure 2-68. Do not enter a formula name
or BSS version yet.
4 Click the New button to open the Formula Version Editor as displayed
in Figure 2-70.
5 Create the formula in the Formula Version Editor by performing the
following steps:
• Click the ( button on the keypad. The keypad is located in the middle
panel of the Formula Version Editor window, Figure 2-70.
• Select TOTAL_CALLS from the Raw Statistics scroll-down list. The Raw
Statistics listing is found on the left-hand panel.
68P02900W36-P 2-177
1900.2AS May 2008
Name the formula Chapter 2: Using the NHA
In the Formula Editor window, enter a name for the formula created in the previous phase.
Ensure that this name gives a clear indication of what the formula is used to detect, for example,
name this formula Call Success Rate.
The next step is to identify how the formula is used, for example, over how many intervals must
the formula calculate a sum. To create a detector, use the following steps:
1 Select the Custom Detector option from the Configure menu (on the
Knowledge Editor) to open the Custom detector window.
2 Click the New button to display the Detector Editor window. Refer to
Figure 2-72.
3 Enter the new detector name.
This name is listed in the Custom detector window and in the Thresholds
window. For example, name this detector TCH Assignment.
4 Enter the anomaly name and problem name.
This problem name is displayed to the operator on the Problem window. For
example, name this problem TCH Assignment. The anomaly name is used
internally by the NHA. For simplicity, make the anomaly name the same
as the problem name.
5 Select a detection mechanism to be used.
For example, to get a value for one day at a time, select the Daily roll-up
detector. For a full description of each of the detection mechanisms, refer to
NHA detection examples on page 1-25.
If the detector is to use sample roll-up or sliding scale, then select a single
formula. If the detector is to use any of the other detection mechanisms,
then select up to five formulae and three statistics.
6 Select the comparison type to compare the result of the formula against the
threshold value determined by the detection mechanism.
7 Select the problem severity, for example, the Call Success Rate problem
can have a severity of Major.
8 Enter a problem clearing time. If the problem does not re-occur during
the problem clearing timescale, then the problem is set to Cleared in the
Problem window.
The recommended problem clearing time is the interval time multiplied by
1.5.
9 Click OK to save the problem.
To confirm that the detector is created, open the Custom Detector window. Refer to Figure 2-71.
2-178 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Apply detector threshold values
In step 5 above, the daily roll-up detection mechanism was applied to this problem. Next, add
the threshold value and minimum sample size for this detector. To do so, use the Thresholds
window as follows:
1 Select the Thresholds option from the Configure menu on the main Problem
window. The Thresholds window is displayed. For further information about
detector thresholds, refer to Modifying detectors and thresholds on
page 2-133.
2 Scroll down the Detector list to locate the newly created custom detector -
TCH-Assignment Failure Rate.
3 Click the new custom problem. The daily roll-up components - Threshold
and minimum sample size are displayed.
4 Enter a value for each component and enable the detector as appropriate.
Refer to NHA detection examples on page 1-25 for further information.
5 Click OK to save the new detector values.
Use the User Defined Causes window to note any information known on the newly created
detector. When the problem is raised, this user-defined cause information is displayed.
Once the detector is raising a reasonable number of significant problems on the OMC, import
the detector into all other OMCs.
68P02900W36-P 2-179
1900.2AS May 2008
External interfaces to detect problems Chapter 2: Using the NHA
Problems can also be detected and then displayed on the Problem window using user-created
scripts. However the output of these scripts must have a set format to allow the problem to be
presented effectively on the Problem window.
The information provided in this section describes the directories where the scripts are stored,
the directory to which the results of the script are output, and the values and parameters to
use when creating a script.
NOTE
This feature is used to connect external scripts to the NHA problem reporting
process. This section does not describe how to write a script. An example script is
included here as a guide.
• Short-term problems.
• Daily problems.
• Creating a script.
• Default values.
Script directories
/usr/gsm/config/customer/external_problems/
The output from the script must be written to the following directory:
/usr/gsm/OMCs/<omcname>/external_problems/
Once the output file is created, each NHA interprets the output file for its OMC and displays
the appropriate problem information on the Problem window. The output file is then removed
from the output directory.
2-180 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Script directories
NOTE
Example output files and scripts are provided in the directory /usr/gsm/cur-
rent/knowledge/external_problems. The sample output file D_ea_ioi.sh is derived
from the script ea_ioi.ace which uses SQL commands to query the OMC CM GUI
Server database.
NOTE
Motorola provided external interface scripts are found in /usr/gsm/current/knowl-
edge/external_problems. Customers must use /usr/gsm/config/customer/exter-
nal_problems/ so that their scripts are not lost in upgrades of the NHA software.
Short-term problems
For hourly or half-hourly problems, the title of the script MUST begin with an s or S.
Each interval, the NHA runs every script beginning with an s or S in /usr/gsm/config/cus-
tomer/external_problems/.
• Output directory where the script creates a file containing information on the problems
that it wants to report to the NHA
Each NHA runs the script is run for each OMC and each output is written to its own OMC
directory in /usr/gsm/OMCs/<omcname>/external_problems/.
Daily problems
For daily problems, every 24 hours, the NHA runs every script in /usr/gsm/config/cus-
tomer/external_problems/ beginning with D.
Each script takes three parameters, see the preceding section for details of each of the
parameters. Scripts are run for each OMC and each output is written to its own OMC directory
in /usr/gsm/OMCs/<omcname>/external_problems.
68P02900W36-P 2-181
1900.2AS May 2008
Creating a script Chapter 2: Using the NHA
Once the editing is done, the external problem names appear in the list of problems in the
subscription and filter dialogues. Users can add these problems to subscriptions and filter
on those problems. The problems can also be selected for sending to the OMC as alarms.
NOTE
The NHA only reports a problem on the Problem window if the device the problem is
reported against exists in the OMC-R CM MIB database. If, for example, a new cell
has been created in a BSS and the OMC-R audit has not been run to update the
OMC-R, the NHA does not display any problems reported for the new cell.
Creating a script
The script writer must be aware of the following when preparing to create a script:
• All source code must be stored in:
/usr/gsm/config/customer/external_problems/
• All source scripts to be run must begin with D or S, depending on if they are daily problems
or interval based problems.
• All output files must be stored separately for each OMC in:
/usr/gsm/OMCs/<omcname>/external_problems/
• An output file must not be moved to the output directory until the script is finished. Do
not put partially completed files into the output directory.
• Each script must include two parameters (and optionally a third). See the previous sections
for details on the types of parameters used.
• PROBLEM-TYPE must be first in the output file for each instance of a problem.
• The value for PROBLEM-TYPE must be separated by dashes, that is, no spaces between
words. For example, high-ber-per-timeslot-problem. If the value of the problem type
includes a hyphen, then replace this hyphen with two hyphens (--). For example, for Low
Inter-BSS Handover Success Rate, enter low-inter--bss-handover-success-rate.
2-182 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Output le elds
• In the case where scripts time out, their output files should not be stored in the output
directory.
• Save the output files with distinct names to prevent them from being overwritten.
When creating a script, the writer must be aware that certain fields are compulsory. The
compulsory and optional fields are outlined in Table 2-26.
The external interface scripts use the following fields in the output file (refer to Table 2-26).
PROBLEM-TYPE is mandatory. Also, use either DEVICE-NAME or DEVICE-DN, but not both.
The other parameters are optional and can be used to improve the usability of deleted problems.
Table 2-26 Output le elds
Field Description
PROBLEM-TYPE The problem type must be first in the file for each instance
of a problem (mandatory).
DEVICE-NAME The device can be a BSS, Site, or Cell (mandatory if not
using DEVICE-DN).
DEVICE-DN The device (BSS, Site, Cell) dn can be used instead of the
name (mandatory if not using DEVICE-NAME).
INTERVAL-COUNT The number of intervals over which the script bases its
calculations. If no value is specified, the default is 1.
CALCULATED-VALUE The result of a formula. If no value is specified, the default
is 0.0.
ADDITIONAL-INFORMATION Extra information (text only). The text entered in this field
can exist over multiple lines, and ends with another valid field
or, more appropriately, ENDINFO. ENDINFO is needed if it
is not the last field; if it is the last field, then it is not needed.
If no value is specified, the default is "".
CLEAR-AFTER An integer indicating how many hours the problem
should be cleared after it has stopped occurring.
Or, a keyword:
DAILY-EXP-TIMEOUT,HOURLY-EXP-TIMEOUT,
VERY-EXP-TIMEOUT.
Note these default NHA time-outs and values can be viewed
in the NHA configuration file. If no value is specified, the
default is 1.5 for interval based problems and 25 for
daily problems.
SEVERITY Can be Major or Critical. If no value is specified, the default
is Major.
68P02900W36-P 2-183
1900.2AS May 2008
Example user-created script Chapter 2: Using the NHA
The external reporting interface can only be used to report a problem against a cell, a site,
or a BSS. If the device referenced by DEVICE-NAME is not one of these, the problem is not
reported on the Problem window.
To report a problem on a different device, the problem must give the DEVICE-NAME of the
relevant cell, site, or BSS. For example, a problem on a particular carrier could be reported
against the cell the carrier is in. Details about the problem carrier can be passed on to the NHA
in the ADDITIONAL-INFORMATION for the problem.
NOTE
Tab characters can only be used as part of the ADDITIONAL-INFORMATION field
and nowhere else in the file. Do NOT use tabs to separate the fields or to align the
words in the output file.
#!/bin/sh
#
This is a sample script for the NHA External Interface.
# This script is the sh script that will call the ace file.
# The ace file in this case is called ea_slc.ace.
# i.e. the script is called ea_${script_body_name}.ace where
# script_body_name is a global parameter in this script set to "slc".
# This script can be reused by copying it to a different
# name and changing the name of the ace file that it references
# The ace file should be of the form ea_XXX.ace. Then change the global name
# script_body_name on line 25 of this file to be the new XXX
# The files should be copied to /usr/gsm/current/external_problems/
# This script takes 3 parameters, omc name, output pathname and date.
# Date is optional.
# If a date is not entered then the script takes the latest interval
# in the omc_db from the time the script is run. In this case the script only
# takes two parameters. Note comment on PR 156960 which
# means that the latest interval is always used.
# An output file is produced called S_ea_${script_body_name}.rep as a result
# of running this script. This output file is stored in the path
# specified by the 2nd parameter, pathname.
# Refer to the NHA System Information Manual, to the section External
# Interfaces to Detect Problems for more information on how to write
# external problem raising scripts in the NHA.
2-184 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Example user-created script
#
# NOTICE:
# Script that requires remote login to a 1900 OMC-R or MMI
# will need to use ssh instead of rsh.
# eg.
# rsh <hostname> "ls -l" will need to be replaced with
# ssh -i <rsa-key> -o UserKnownHostsFile=<known_host> <userid>@<hostname>
"ls -l"
#
# Calculation of date and time for log purposes
#
script_body_name="slc"
end_date=‘date '+%Y%m%d'‘
end_time=‘date '+%H:%M:%S'‘
# This section makes sure that the user running the script
# is omcadmin. If the user is not omcadmin, a warning is output
# and the script exits.
if [ "‘/usr/ucb/whoami‘" != "omcadmin" ]
then
echo "ERROR: this script must be executed by user omcadmin."
exit 1
fi
# This section makes sure that there are least two parameters entered.
# If there are less than two parameters then the script outputs correct
# usage, and exits. Note that this script can take two or three parameters
# If the third parameter, date_and_time, is not entered then the script takes
# the latest interval in the omc_db bss_datetimes table from when the script
# is run.
if [ $# -lt 2 ]
then
echo "Usage: ‘basename $0‘ <OMC_SPLAT hostname> <output-directory> [YYYY-MM-DD
HH:MM]"
exit 1
fi
# Assign $1 to be the splat_host, Assign $2 to be the output directory. The
# output directory is where the report file will be put for NHA to collect it.
# If there was three parameters then assign the third parameter to be maxdate
splat_host=$1
output_directory=$2
#This code must remain commented until pr 156960 is fixed
#if [ $# -eq 3 ]
#then
68P02900W36-P 2-185
1900.2AS May 2008
Example user-created script Chapter 2: Using the NHA
# maxdate="$3"
#fi
#
# Get the appropriate OMC system name as defined
# in the /usr/gsm/config/local/OMCs.cfg file
#
OMC_listfile=/usr/gsm/config/local/OMCs.cfg
omc_num=‘grep "^omc_sys" ${OMC_listfile} | grep -nw $splat_host | awk -F:
'{print $1}'‘
omc_ident=‘grep '^OMC' ${OMC_listfile} | awk '{print $2}' | sed -n -e
"${omc_num}p"‘
omc_homedir=/usr/gsm/OMCs/${omc_ident}
#Find the name of the NHA audit log file for today
logs="${omc_homedir}/ea_logs/eaAudit${end_date}"
# This is where the script is run from
CURRENT_DIR=/usr/gsm/current/knowledge/external_problems
# If the output directory entered was "" then go to the ea.cfg file and
# get the output file from there. Note this is going to be the name of the
# directory in which NHA will expect the output reports to be.
if [ $output_directory = "" ]
then
output_directory=‘grep "^EXTERNAL-PROBLEMS-OUTPUT-PATH"
${omc_homedir}/config/ea.cfg | awk '{print $2}'‘
fi
# Make sure that this machine can contact the omc_splat
# If not output that the splat was unreachable and exit
/usr/sbin/ping >/dev/null 2>&1 $splat_host
if [ $? -ne 0 ]
then
echo "ERROR: OMC host $splat_host is unreachable."
if [ -f ${logs} ]
then
echo >> ${logs} "${end_time}|Warning |external|scripting| OMC host
$splat_host is unreachable in S_${script_body_name}.sh."
fi
exit 1
fi
# Ensure it's networked, rsh ensures that it will accept an
# unpassworded connection if it succeeds
rsh -n $splat_host pwd >/dev/null 2>&1
if [ $? -ne 0 ]
then
2-186 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Example user-created script
68P02900W36-P 2-187
1900.2AS May 2008
Example user-created script Chapter 2: Using the NHA
define
param [1] maxdate datetime year to minute
end
output
left margin 0
right margin 0
top margin 0
bottom margin 0
report to "ea_slc.tmp"
end
# This is the ace file. It uses SQL command to select data from
# the omc_db. This select statement gets the bss name, site name and cell name
# along with the busy tch mean statistic. If it finds cases where the busy tch
# mean statistic = 0 for the last interval then it writes the bss name,
# site name, cell name to a file to be reported to the NHA via
# the NHA external interface.
select relative_log_name,busy_tch_mean
from bss_site , entity,
cell_statistics
where
(time_id = (select MAX(datetime_id) -1 datetime
from bss_datetimes
where date_and_time <= $maxdate))
and entity.rdn_class = 37
and cell_statistics.network_id = entity.network_id
and busy_tch_mean = 0
group by 1,2
end
# The following format must be adhered to. PROBLEM-TYPE, DEVICE-NAME OR
2-188 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sample output
# DEVICE-DN ARE COMPULSORY. PROBLEM-TYPE MUST NOT HAVE ANY SPACES IN IT.
# CLEAR-AFTER TELLS HOW LONG AFTER THE PROBLEM
# STOPS HAPPENING SHOULD THE NHA CLEAR IT. SEVERITY IS THE SEVERITY THAT
# WILL APPEAR WITH THE PROBLEM IN THE NHA ALARM WINDOW. CALCULATED_VALUE
# GIVES THE CALCULATED VALUE OF THE FORMULA - IN THIS CASE IT IS ALWAYS ZERO
# ADDITIONAL INFO IS A FIELD THAT ALLOWS EXTRA INFO TO BE SENT TO THE
# ALARM WINDOW. IF THERE IS MORE THAN ONE LINE IN THIS FIELD THEN IT MUST
# BE CLOSED WITH AN END-INFO LINE.
format
on every row
print "PROBLEM-TYPE SLEEPING-CELL-PROBLEM"
print "DEVICE-NAME ",relative_log_name clipped
print "CLEAR-AFTER 1"
print "SEVERITY MAJOR"
print "ADDITIONAL-INFORMATION"
print "busy_tch_mean =",busy_tch_mean
print "ENDINFO"
print "CALCULATED-VALUE 0"
end
Sample output
PROBLEM-TYPESLEEPING-CELL-PROBLEM
DEVICE-NAME Cell_1
CLEAR-AFTER 1
SEVERITY MAJOR
ADDITIONAL-INFORMATION
busy_tch_mean = 0.00
ENDINFO
CALCULATED-VALUE 0
PROBLEM-TYPE
SLEEPING-CELL-PROBLEM
DEVICE-NAMECell_3
CLEAR-AFTER 1
SEVERITY MAJOR
ADDITIONAL-INFORMATION
busy_tch_mean = 0.00
ENDINFO
CALCULATED-VALUE 0
PROBLEM-TYPE
SLEEPING-CELL-PROBLEM
DEVICE-NAMECell_2
CLEAR-AFTER 1
SEVERITY MAJOR
ADDITIONAL-INFORMATION
busy_tch_mean = 0.00
ENDINFO
CALCULATED-VALUE 0
68P02900W36-P 2-189
1900.2AS May 2008
External Interface for Causes and Actions Chapter 2: Using the NHA
External Interface for Causes and Actions is a defined interface that allows administrators to
configure the NHA so that user-written scripts can interact with problems reported by the NHA.
• Manual Action scripts to launch one or more scripts manually from the corrective action
windows of problems.
• Automatic Action scripts to launch one or more scripts automatically when a problem
with a specific cause is raised.
Using this interface, administrators can tailor the NHA to include additional knowledge (that
is defined locally) . It can also make tasks, that are regularly performed when a problem or
cause is detected, easier to carry out.
NOTE
This feature is a powerful one as it enables scripts to be run automatically.
Additionally, scripts can be written to perform many tasks. Test scripts in a controlled
manner before setting up the NHA to run them automatically (particularly for Cause
Analysis or Automatic Action scripts).
Cause Analysis scripts are executed when a specified problem is raised or when a combination
of a single problem and one or more causes occurs. The action carried out by this type of script
is decided by its creator. However, the script must return an output file containing details of the
user-defined data (for example, causes to be raised, corrective-action text and line of reasoning)
that the writer wants to add to the problem. The writer can also specify a cause to be deleted. If
this cause is already present (that is, already raised by the internal NHA analysis), it is deleted.
For example:
Every time problem P is raised with cause C1, check the configuration data in the OMC-R MIB
to determine the value of an attribute for the cell. If the value of the attribute is outside a
specified range, then raise a new cause C2 and remove cause C1. Otherwise,
raise a new cause C3 in addition to cause C1.
2-190 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Manual Action scripts
Action scripts can be executed manually when a particular cause is raised or when a combination
of a specified problem and cause occurs. If it is an action script, the type of action carried out by
the script is decided entirely by its creator. The only interface to the NHA is the execution of the
script by the NHA. No output file is necessary.
Manual action scripts are so-called because they are not executed immediately when their firing
conditions are met. Instead, they are presented to the user in the corrective action window of a
cause to run manually. The scripts are presented only when their firing conditions are met.
For example:
Every time problem P is raised with cause C1, present an option on the corrective action
window to launch Call Trace for the cell. The operator can choose to take this option or not.
Automatic scripts operate and are associated with specified causes/problems in the same way as
Manual Action scripts but the NHA executes them as soon as their firing conditions occur.
For example:
Every time problem P is raised with cause C1, immediately run a script to gather
information about the cell and store it for viewing later.
The External Interface for Causes and Actions feature has many configurable properties. These
properties are described in more detail in the following sections and consist of:
• Configuration file entries in the OMC-specific configuration file that allow the features to
be turned on or off and define the directories used for description files.
• Descriptor files in the defined format which associate problems or causes to the
user-defined scripts to be run. Note there can be many descriptor files calling many
different scripts.
• User-defined scripts which, when run, read parameters from the NHA about the problem
and produce output files (cause scripts) or initiate actions (manual or automatic action
scripts).
• Output files in the appropriate format which the NHA reads when associating causes with
existing problems and which indicate to the NHA that the scripts have completed.
The following example shows the standard entries in the ea.cfg file.
68P02900W36-P 2-191
1900.2AS May 2008
Directory structure Chapter 2: Using the NHA
CAUSE-ANALYSIS-SCRIPTS-ENABLED TRUE
MANUAL-ACTION-SCRIPTS-ENABLED TRUE
AUTOMATIC-ACTION-SCRIPTS-ENABLED FALSE
CAUSE-ANALYSIS-PATH /usr/gsm/config/customer/external_causes/description-files
MANUAL-ACTION-PATH
/usr/gsm/config/customer/cause_action_scripts/manual/description-file
AUTO-ACTION-PATH
/usr/gsm/config/customer/cause_action_scripts/automatic/description-files
CAUSE-OUTPUT-PATH /usr/gsm/OMCs/OMCONE/external-cause-output/
CORRECTIVE-ACTION-LIMIT 5000
LINE-OF-REASONING-LIMIT 500
MAXIMUM-ACTIVE-SCRIPTS 10
NOTE
Configuration file entries must have no space at the end of the line.
Directory structure
The standard directory used by the External Interface for Causes and Actions feature is at
/usr/gsm/config/customer/. The following subdirectories are used by default to contain the
description files, scripts, and their output.
external_causes/description-files
external_causes/scripts
cause_action_scripts/automatic/description-files
cause_action_scripts/automatic/scripts
cause_action_scripts/manual/description-files
cause_action_scripts/manual/scripts
To change these defaults, update the appropriate PATH variables in the OMC-specific
configuration file. Note with this structure, in NHAs that monitor multiple OMCs, the
scripts apply to all OMCs. To configure the NHA in a different way, create OMC-specific
description_file directories. The corresponding OMC-specific configuration file must have a
path to these directories.
The following parameters are automatically passed from the NHA to scripts as in Table 2-27.
The scripts then use the parameters as required.
2-192 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Parameters for scripts
Or
INVALID (for Manual Invalid for Manual Action or UI Action scripts.
Action or UI Action
scripts)
2 OUTPUT_DIRECTORY The directory in which the script
(for Cause Analysis places any output, for example:
and Automatic /usr/gsm/OMCs/OMCONE/external-cause-output/
Action scripts)
Or
DISPLAY_ID (for The Display ID of the User Interface from which the
Manual Action or UI script is launched, for example: 177.3.54.213:0.0
Action scripts)
3 OMC_HOSTNAME The hostname of the OMC, for example: somcsys3.
4 OMC_NAME The textual name used by the NHA to identify the
OMC, for example: OMCTWO.
5 BSS_NAME The name used by the NHA to identify the BSS, for
example: B_Cork_5.
6 SITE_RDN The RDN of the site, for example: 22.
7 SITE_NAME The name of the site, for example: Mahon.
8 GSM_CELL_ID The name used by the NHA to identify the GSM cell,
for example: 454-01-1234-56789.
9 CELL_RDN The RDN of the cell, for example: 5689562.
10 CELL_NAME The name of the cell, for example: T22_S.
11 RDN_CLASS The RDN Class of the device, for example: 37.
12 RDN_INSTANCE The RDN instance of the device, for example: 3.
13 DEVICE_DN The DN of the device against which the problem was
raised, for example: 100/0,31/0,30/0,37/3.
14 BSS_RDN The RDN of the BSS, for example: 5.
15 CAUSE_TYPE (for The type of the NHA Cause that triggered the script,
Manual and Automatic for example: "Lack of TCH".
Action scripts)
Or
NONE (for Cause NONE for Cause Analysis and UI Action scripts.
Analysis and UI Action
scripts)
Continued
68P02900W36-P 2-193
1900.2AS May 2008
Parameters for scripts Chapter 2: Using the NHA
NOTE
The UNIX shell scripts can only read the first nine parameters using the $n notation,
for example: $7 is the seventh parameter. For parameters 10 and above, the shift
command must be used with $9 to read parameters.
For example, if reading parameters 8 to 12, the shell script code can look like the following:
...
GSM_CELL_ID=$8
CELL_RDN=$9
shift
CELL_NAME=$9 # Parameter 10
shift
RDN_CLASS=$9 # Parameter 11
shift
RDN_INSTANCE=$9 # Parameter 12
...
"
2-194 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst External Interface for Cause Analysis Scripts
The description file must be in the appropriate format and must contain information describing
the association between the cause analysis script and the problem/problem-cause pairs for
which it is called.
The script can use parameters that are passed to it and must place its output in the
appropriate format in a file in the directory specified by CAUSE-OUTPUT-PATH (usually,
/usr/gsm/OMCs/<omcname>/external-cause-output/).
The format of each Description File for Cause Analysis Scripts must be as follows:
• One or more PATH statements containing the full UNIX path to the script to be run when
the specified problem or problem-cause pairs are raised.
PATH /unix-path/unix-filename.
The PATH statement usually points to a script in the /scripts directory on the same level,
but it can point to anywhere on the NHA. The path must be the full absolute path from the
root directory. To associate multiple scripts with a single problem, then more than one
script path can be specified using additional PATH statements.
• One or more PROBLEM statements which contain a full problem name optionally grouped
with one or more CAUSE statements which contain full cause names. These statements
define the problems or problem-cause groups that initiate the execution of the cause
analysis script specified in the PATH statements at the top of the file.
PROBLEM full-problem-name
CAUSE-full-cause-name
The problem names and cause names used here are text strings that must exactly match
the name of the problem or cause that appears in the Problem window (including units, for
example (%), if applicable). They can be obtained by copying the appropriate line from
the file /usr/gsm/current/knowledge/problem-and-cause-names.txt which contains
an alphabetical list of the names all the problems and causes provided in the NHA.
68P02900W36-P 2-195
1900.2AS May 2008
Output le format for Cause Analysis Scripts Chapter 2: Using the NHA
NOTE
• Use only a single space to separate the PATH/PROBLEM/CAUSE tag from the
path/problem/cause names. There must be no white space at the end of any
PATH, CAUSE, or PROBLEM statements.
• White space should not be present at the end of any PATH, CAUSE, or PROBLEM
statements.
PATH /usr/gsm/config/customer/external_causes/scripts/clever_script.sh
The presence of this descriptor file ensures that the script clever_script.sh runs every time the
NHA detects any of the following combinations of problems and causes:
• High SDCCH Blocking Rate (with any cause)
OR
• Very High TCH Blocking (with both TCH Blocking without congestion and RTF Outage
present as the causes for it)
OR
• Very High Dropped Call Rate (with Neighbor cell OOS as one of its causes).
NOTE
Test Cause Analysis scripts on a limited number of problems and causes before
setting them up to be run in a widespread manner.
Each time a cause analysis script is run, an output file containing, at a minimum, a PROBLEM-ID
statement is created (see below), even if no changes are to be made to the causes of the problem.
2-196 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Output le format for Cause Analysis Scripts
The NHA reads the output of Cause Analysis scripts and presents it to operators. The format of
the output file from Cause Analysis scripts must be made up of statements as follows:
• One PROBLEM-ID statement containing the identity of the problem associated with the
cause analysis. It is a unique ID assigned to each problem when it is raised. It is passed to
the Cause Analysis script as the first parameter ($1). It is used internally to identify the
problem to which the script should apply changes.
PROBLEM-ID problem-identifier
There must always be a PROBLEM-ID statement in the output file, even if no changes are
made to the causes of the problem.
CONFIDENCE-FACTOR factor
• Optionally, one LINE-OF-REASONING statement, that is, text starting with a line
containing LINE-OF-REASONING and ending with a line containing END-LOR. The text
from this field is appended to the Line of reasoning for the problem.
LINE-OF-REASONING
... text
END-LOR
• Optionally, one CORRECTIVE-ACTION statement that is text starting with a line containing
CORRECTIVE-ACTION and ending with a line containing END-CA. The text from this field
is attached to the cause and used in the corrective action window for the cause. If there is
a CORRECTIVE-ACTION statement, then there must be a corresponding CAUSE-NAME
statement.
CORRECTIVE-ACTION
... text
END-CA
• Optionally, one or more DELETE-CAUSE statements. If it has been raised against the given
problem, the effect of these statements is to delete the named cause. DELETE-CAUSE
allows external scripts to override the internal NHA cause analysis. If no cause is to be
deleted, do not use the DELETE-CAUSE tag.
68P02900W36-P 2-197
1900.2AS May 2008
Sample Cause Analysis Scripts Chapter 2: Using the NHA
PROBLEM-ID 41ceb9alc63d110
LINE-OF-REASONING
clever_script determined that the value of clever_parameter was 0
Cause Raised: Clever Cause
Cause Deleted: TCH blocking without congestion
END-LOR
CORRECTIVE-ACTION
Check the value of clever_parameter on cell 123-45-6789-12345 and correct it.
END-CA
Once the NHA processes the output file, the problem uniquely identified by 41ceb9alc63d110
(which triggered the calling of the script) has an additional cause "Clever Cause" of High
confidence factor added to its list of causes. The corrective action text is associated with it. The
Line of Reasoning has extra text appended to it. If an existing cause "TCH blocking without
congestion" exists for the problem called 41ceb9alc63d110, then it is removed.
Sample Cause Analysis scripts and descriptor files can be found on the NHA in the
/usr/gsm/current/knowledge/external_causes/example_scripts directory. These include
scripts to:
• Output all external interface parameters to a cause.
The README.txt file in the directory gives more details about the scripts and how to set them
up for use. The sample scripts in the directory can be used as a source of ideas for any other
External Interface for Cause Analysis scripts that are required.
The following example script (cause_analysis_example.sh) reads all 23 parameters from the
NHA and then adds an additional cause which lists some of those parameters. Note the use
of the shift command to read parameters after the first nine.
#!/bin/sh
#####################################################################
# Copyright 2005, Motorola Inc.
#
#This is an example script to test the NHA
External Interface for Causes and Actions.
PROBLEM_ID=$1
OUTPUT_PATH=$2
2-198 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sample Cause Analysis Scripts
OMC_HOSTNAME=$3
OMC_NAME=$4
BSS_NAME=$5
SITE_RDN=$6
SITE_NAME=$7
GSM_CELL_ID=$8
CELL_RDN=$9
shift
CELL_NAME=$9
shift
RDN_CLASS=$9
shift
RDN_INSTANCE=$9
shift
DEVICE_DN=$9
shift
BSS_RDN=$9
shift
DUMMY=$9
shift
PROBLEM_TYPE=$9
shift
CALCULATED_VALUE=$9
shift
FIRST_TIME=$9
shift
LAST_TIME=$9
shift
FIRST_ANOMALY_TIMESTAMP=$9
shift
NUMBER_OF_REPEATS=$9
shift
PREVIOUS_VALUE=$9
shift
DETECTION_TYPE=$9
shift
INTERVAL_COUNT=$9
shift
SEVERITY=$9
#Enter the LOR here which appears with the problem in the NHA UI.
echo "LINE-OF-REASONING" >> /tmp/new.$$
echo "First Instance : $FIRST_TIME" >> /tmp/new.$$
echo "This is a test cause analysis script." >> /tmp/new.$$
echo "CAUSE RAISED: Test cause." >> /tmp/new.$$
echo "END-LOR" >> /tmp/new.$$
68P02900W36-P 2-199
1900.2AS May 2008
Sample Cause Analysis Scripts Chapter 2: Using the NHA
#Enter the corrective action here which appears with the problem in the NHA UI.
echo "CORRECTIVE-ACTION" >> /tmp/new.$$
echo "This is a Test cause raised by the NHA External Interface for Causes and
Actions feature" >> /tmp/new.$$
echo "This cause was raised against CELL: $CELL_NAME on OMC: $OMC_NAME" >>
/tmp/new.$$
echo "whos DN is: $DEVICE_DN and Parent Site is: $SITE_NAME" >> /tmp/new.$$
echo "END-CA" >> /tmp/new.$$
#Copies the temporary file to the output directory specified in the ea.cfg and
removes the temporary one.
mv /tmp/new.$$ $OUTPUT_PATH$$-cause
/bin/rm -f /tmp/new.$$
2-200 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst External Interface for Manual Action Scripts
The description file must be in the appropriate format and contain information describing the
association between the action script and the causes/cause-problem pairs for which it is called.
The action script can use parameters that are passed to it. No output from the action script is
required.
The format of each description file for action scripts (both manual and automatic) must be
as follows:
• One or more PATH statements containing the full UNIX path to the scripts to be run when
the specified problem or problem-cause pairs are raised.
PATH unix-path/unix-filename
The PATH statement usually points to a script in the /scripts directory on the same level,
but it can point to anywhere on the NHA. Note the path must be the full absolute path from
the root directory. To associate multiple scripts with a single problem, then operators can
specify more than one script path using additional PATH statements.
• One or more CAUSE statements containing a full cause name, optionally grouped with
one PROBLEM statement containing a full problem name. If used, then the PROBLEM
statement must come after the CAUSE statement. These statements define the causes or
cause-problem groups that initiate the execution of the action scripts specified in the PATH
statements at the top of the file.
CAUSE full-cause-name
PROBLEM full-problem-name
The problem names and cause names used here are text strings that must exactly
match the name of the problem or cause that appears in the Problem window
(including units, if applicable). To obtain them, copy the appropriate line from the file
/usr/gsm/current/knowledge/problem-and-cause-names.txt which contains an
alphabetical list of the names of all the problems and causes provided in the NHA.
68P02900W36-P 2-201
1900.2AS May 2008
Associating Manual Action Scripts with causes Chapter 2: Using the NHA
NOTE
PATH /usr/gsm/config/customer/cause_action_scripts/manual/scripts/
manual_trace.sh
PATH /usr/gsm/current/knowledge/cause_action_scripts/manual/scripts/
manual_clever_script.sh
The presence of this descriptor file ensures that both scripts, manual_trace_script.sh and
manual_clever_script.sh, are offered to the operator in the list of menu options on the
Corrective Action window whenever any of the following combinations of causes is detected by
the NHA (refer to Figure 2-73):
• ARFCN frequency planning issue (when raised by "High daily DROPPED CALL rate %"
problems only).
NOTE
Test Manual Action scripts on a limited number of problems and causes before
setting them up to be run in a widespread manner.
2-202 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the DISPLAY variable with Manual Action scripts
Manual Action scripts are launched from the User Interface and the DISPLAY variable is passed
to scripts as a parameter, so these scripts can be used to launch applications (for example,
dtpad, PM GUI) on the User Interface. The sequence of actions is as follows:
• The script reads the DISPLAY variable from $2.
For example,
...
DISPLAY=$2
export DISPLAY
...
/usr/openwin/bin/dtpad -standAlone -display ${DISPLAY} ${filename}
...
If the manual action script is launched from an NHA UI on a UNIX terminal, then the launched
application is displayed on that terminal. If the manual action script was launched from an NHA
UI on a PC, then the launched application is displayed in an Exceed (or other equivalent UNIX
terminal emulator program) session, if one is running on that PC.
Sample Action scripts and descriptor files are found on the NHA in the /usr/gsm/cur-
rent/knowledge/cause_action_scripts/example_scripts directory. These include scripts to:
• Output all External Interface parameters to a file.
• Upload the Database of a BSS (designed in particular for the Database upload problem
type).
The README.txt file in the directory gives more details about the scripts and how to set them
up for use. The sample scripts in the directory can be used as a source of ideas for any other
External Interface for Cause Analysis scripts required.
The following example script (cause_action_example.sh) reads all 23 parameters from the
NHA and then adds an additional cause which lists some of those parameters. Note the use
of the shift command to read parameters after the first nine.
#!/bin/sh
#####################################################################
# Copyright 2005, Motorola Inc.
68P02900W36-P 2-203
1900.2AS May 2008
Sample Manual Action scripts Chapter 2: Using the NHA
#
#This is an example script to test the NHA
External Interface for Causes and Actions.
#
#Read in available parameters.
INVALID_TYPE=$1
DISPLAY=$2
OMC_HOSTNAME=$3
OMC_NAME=$4
BSS_NAME=$5
SITE_RDN=$6
SITE_NAME=$7
GSM_CELL_ID=$8
CELL_RDN=$9
shift
CELL_NAME=$9
shift
RDN_CLASS=$9
shift
RDN_INSTANCE=$9
shift
DEVICE_DN=$9
shift
BSS_RDN=$9
shift
CAUSE_TYPE=$9
shift
PROBLEM_TYPE=$9
shift
CALCULATED_VALUE=$9
shift
FIRST_TIME=$9
shift
LAST_TIME=$9
shift
FIRST_ANOMALY_TIMESTAMP=$9
shift
NUMBER_OF_REPEATS=$9
shift
PREVIOUS_VALUE=$9
shift
DETECTION_TYPE=$9
shift
INTERVAL_COUNT=$9
shift
SEVERITY=$9
2-204 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sample Manual Action scripts
68P02900W36-P 2-205
1900.2AS May 2008
External Interface for Automatic Action Scripts Chapter 2: Using the NHA
The description file must be in the appropriate format and must contain information describing
the association between the action script and the problem/problem-cause pairs for which it
is called.
The action script can use parameters that are passed to it. No output from the action script is
required.
The format of each description file for automatic action scripts is the same as the format for
description files for manual action scripts (refer to External Interface for Manual Action
Scripts on page 2-201 ).
The automatic action scripts are run immediately after the problem-cause conditions are
matched, subject to a maximum number of scripts running at any one time. This maximum
number is controlled by the MAXIMUM_ACTIVE_SCRIPTS variable in the OMC-specific
configuration file (ea.cfg).
NOTE
It is recommended that External Interface for Action scripts be tested manually
before setting them up to be run automatically.
2-206 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Automatic Action scripts output les
PATH /usr/gsm/config/customer/cause_action_scripts/automatic/scripts/
automatic_upload_script.sh
CAUSE No successful database upload following database change
PROBLEM Database upload required
The presence of this descriptor file ensures that the script automatic_upload_script.sh is run
automatically when the "No successful database upload following database change" cause is
raised for the Database upload required problem.
The Automatic Action script MUST produce an output file to the location specified in the second
parameter ($2) containing one line as follows:
This indicates to the NHA that the script has completed and that another waiting script can be
launched.
Create the output file by including code like the following at the end of the Automatic Action
script:
touch /tmp/clever_script_output.$$
echo $UNIQUE_ID >> /tmp/clever_script_output.$$
mv /tmp/clever_script_output.$$ $OUTPUT_PATH
Sample Action scripts and descriptor files are found on the NHA in the /usr/gsm/cur-
rent/knowledge/cause_action_scripts/example_scripts directory. These include scripts to:
• Output all External Interface parameters to a file.
• Upload the Database of a BSS (designed in particular for the Database upload problem
type).
The README.txt file in the directory gives more details on the scripts and how to set them up
for use. The sample scripts in the directory can be used as a source of ideas for other External
Interface for Cause Analysis scripts that are required.
68P02900W36-P 2-207
1900.2AS May 2008
Sample Automatic Action scripts Chapter 2: Using the NHA
Refer to External Interface for Manual Action Scripts on page 2-201 for an example of a
script that can also be used as an automatic script.
NOTE
It is recommended that scripts are tested as manual action scripts before setting
them up to run as automatic action scripts.
2-208 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst User Interface Action scripts
User Interface Action scripts are available from the Action Scripts pop-up menu option on the
Problem Window or the Cell View Window. Refer to The Problem pop-up menu on page
2-30 for further information.
• run_pm_report.sh which launches the OMC-R PM GUI in trend graphical mode with
values for Call Success Rate, Dropped Call Rate, TCH usage, and Total Calls for all the
cells in the problematic site for five days.
• carrier_stats.sh which displays carriers statistics to the user for all carriers under a
selected cell.
To add additional user-defined scripts so that they are available from the Problem pop-up menu,
follow Procedure 2-49:
1 Ensure that the feature is turned on and that the script path is defined in the
OMC-specific configuration file /usr/gsm/OMCs/<omcname>/config/ea.cfg
UI-ACTION-SCRIPTS-ENABLED true
UI-ACTION-PATH /usr/gsm/config/customer/ui_action_scripts/all
2 Write the script so that it uses the same parameters as the parameters used
in the External Interface for Manual Action Scripts (refer to Table 2-27).
Ensure that the script is tested in a controlled manner.
Continued
68P02900W36-P 2-209
1900.2AS May 2008
Adding additional user-dened scripts Chapter 2: Using the NHA
NOTE
This powerful feature enables any user to run scripts to do many
tasks. Administrators are recommended to test the scripts in a
controlled manner before setting them up for general use on the
user interface.
4 To obtain a more user-friendly name on the menu,
the administrator is recommended to edit the file
/usr/gsm/current/knowledge/ui_action_scripts/all/UIActionScripts.txt
in the following format:
[script name][single space][name for menu]
For example:
all_test_script.sh Test all options
2-210 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Cyclic Neighbor Statistics
The Cyclic Neighbor Statistics feature aims to identify the cells for which to enable neighbor
statistics.
Neighbor statistics consist of the following statistics for each neighbor of a cell:
• OUT_HO_NC_CAUSE_ATMPT
• OUT_HO_NC_SUC
• IN_INTRA_NC_ATMPT
• IN_INTRA_NC_SUC
Neighbor statistics are useful for analyzing the causes of network problems, especially handover
problems and optimization issues. If neighbor statistics are turned on for problematic cells
and an NHA handover problem has repeated over several days, then these statistics can be
useful for further cause analysis. The statistics are available for viewing on the OMCs PM GUI
(Performance Management Graphical User Interface).
However, there are limits to the number of cells that can have neighbor cells enabled at any
time. Currently, the maximum number of cells per BSS that can have neighbor statistics enabled
is 16. Additionally, there is a limit in the OMC PM database as defined by the environment
variable PM_MAX_NEIGHBORS and indicated by OMC alarm 30026. As a result, it is often
necessary to cycle through the cells, enabling neighbor cell statistics for different cells at
different times. The Cyclic Neighbor Statistics feature makes it easier to identify cells for
which to turn on neighbor statistics.
For further information on neighbor statistics, refer to Maintenance Information: GSM Statistics
Application (68P02901W56).
The Cyclic Neighbor Statistics feature checks the NHA Daily Export file for a specified set of
NHA problem types raised by the NHA and then outputs a list of cells to a file. This file can be
used to turn on the Neighbor statistics at the OMC manually.
The OMC can be configured to read the NHA file and enable the Neighbor statistics at the BSS
automatically.
For further information about using neighbor statistics and setting up performance management,
refer to the following OMC documentation:OMC-R Online Help, Network Operation and
Operating Information: OMC-R System Administration (68P02901W19). Information about the
Cyclic Neighbors Statistics utility is also available in the OMC-R Online Help.
68P02900W36-P 2-211
1900.2AS May 2008
Conguring Cyclic Neighbor Statistics on the NHA Chapter 2: Using the NHA
To configure the Cyclic Neighbor Statistics feature on the NHA, use the following steps:
1 Check that the NHA daily export feature is enabled by selecting the
Configure - Daily Export option on the NHA user interface. Ensure that
the feature is enabled and set to an appropriate time.
NOTE
If the Cyclic Neighbor Statistics feature is enabled in the ea.cfg
file, it is now run after the daily export is completed.
2 For each OMC that the NHA monitors, edit the OMC-specific configuration
file (/usr/gsm/OMCs/<omcname>/config/ea.cfg) with appropriate values
for the parameters:
mkdir /usr/gsm/ne_data/nha_nbrs
2-212 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The feature in action - overview
The following describes how the Cyclic Neighbor Statistics feature works:
• Every day, after the daily export of problems occurs, the feature checks the NHA Daily
Export file for that day.
• It searches for problems of the types specified in the OMC-specific configuration file.
• It selects the cells that those problems were raised against up to when there are
[NO-OF-NEIGH-CELLS] cells listed. If that maximum is reached, then the cells are chosen
by selecting the cells in the sort order: first, by the sort order of the problem type and then
by the value of the problem. That is, the cells with the worst values of the worst problem
type are selected for the enable file first.
• OMC users can view this enable file which contains a list of cells and manually enable
neighbor statistics on those cells, using the OMC PM GUI.
• The OMC can be configured to read the NHA neighbor statistics enable file automatically
and to enable neighbor statistics on those cells automatically.
The following is a sample nha_neighbors enable file that lists cells on which it is recommended
to enable neighbor statistics, together with the relevant problem name and value.
NOTE
The OMC only uses the cell name part of the output file. It ignores anything that
is after the first comma.
The OMC can be configured to read the NHA neighbor statistics enable file automatically
and to enable neighbor statistics on those cells automatically. To configure the OMC, enable
the OMCs Cyclic Neighbor Statistics utility.
68P02900W36-P 2-213
1900.2AS May 2008
Using the output on the OMC Chapter 2: Using the NHA
If the Cyclic Neighbor Statistics utility is not already set up on the OMC, then it can be set up by
logging on as user omcadmin and running the following commands on the OMC:
source /usr/gsm/config/global/pmInfxUserConfig.csh
/usr/gsm/current/sbin/setup_cyclic_nbr [x]
where x is one of the following values: 6, 12 or 24, that specifies in hours how often the cyclic
neighbor statistics utility is to be run. If no value is entered, then the 24-hour value is used
by default (and the utility runs once a day).
The OMC Cyclic Neighbor Statistics utility log files can be checked to see the commands issued
by the utility at:
/usr/gsm/logs/nbr_stats.[yyyymmdd]
To turn off the OMC Cyclic Neighbor Statistics utility, run the following commands on the
OMC as user omcadmin:
source /usr/gsm/config/global/pmInfxUserConfig.csh
/usr/gsm/current/sbin/delete_cyclic_nbr
Further information about using neighbor statistics and setting up performance management is
provided in the following OMC documentation: OMC-R Online Help, Network Operation and
Operating Information: OMC-R System Administration (68P02901W19). Information about the
Cyclic Neighbors Statistics utility is also available in the OMC Online Help.
2-214 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Displaying recent alarms and events
This option is available from the UI action script option of the pop-up menu on the Problem
window. It enables users to extract useful, timely, and relevant data from the Event Logs and
Active Alarms. It reports data on recent configuration changes, state changes, recent alarms, or
active alarms.
The administrator can configure the feature to report a subset of events and alarms and to filter
out events and alarms that are of no interest. This filtering can be done per problem type. The
administrator can also tag certain interesting events or alarms as "VIP".
For further information about configuring tags and filters for alarms and events, refer to
Configuring the recent alarms and events feature on page 4-75.
Feature summary
This feature can be set up to highlight interesting configuration changes or alarms and to filter
out irrelevant events. It is used to:
• Display a list of events and alarms for a SITE for a configurable number of days.
• Tag and display certain interesting or important events and alarms as "VIP".
• Display the number of Events and Alarms that have been tagged as "VIP".
Sample output
--------
CURRENT ACTIVE ALARMS : 2 (Total: 2, 0 Excluded, 0 VIP)
EAS 0 0 0 27 FMIC Untagged 01-04-2005 Aircraft Light Failed (11)00:14:45
IAS 0 0 0 106 FMIC Untagged 01-15-2005 Rectifier Failure 15:42:32
--------
68P02900W36-P 2-215
1900.2AS May 2008
Overview of alarms and events Chapter 2: Using the NHA
RECENT EVENTS
Total Excluded Displayed VIP
30/01/2005 57 32 25 0
29/01/2005 12 0 12 0
28/01/2005 39 0 39 0
Day 1 30/01/2005
2-216 68P02900W36-P
1900.2AS May 2008
Chapter
Problem guide
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P 3-1
May 2008 1900.2AS
Problem guide Chapter 3: Problem guide
Problem guide
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The NHA addresses and detects each problem using different formulae and detectors. This
section provides a high level description of each problem and how it is detected. It also
describes the causes identified by the NHA.
• Detector information - this displays formulae and values used to detect the problem.
• Statistics/Event history - view all the statistics/events for this problem over the previous
24 hours.
3-2 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst List of problems detected by the NHA
Table 3-1 lists the problems that can be detected by the NHA by category and type. The alarm
numbers used when the NHA problem is sent to the OMC are also listed.
Refer to the index at the back of this manual to view the problems in alphabetical order, under
the heading Problem list.
Table 3-1 Problem list
Problem Alarm
Problem type
category number
Call Success Call success problems:
- Low daily call success rate 40012
- Very low call success rate 40023
Dropped call rate problems:
- High daily dropped call rate 40004
- Very high dropped call rate 40020
High second assignment problems:
- High second assignment rate 40054
- Very high second assignment rate 40055
Low mean time between dropped calls 40058
Low TCH mean holding time 40057
Immediate High immediate assignment failure rate problems:
Assignment
- High daily immediate assignment failure rate 40007
Continued
68P02900W36-P 3-3
1900.2AS May 2008
Statistics based problems on cells Chapter 3: Problem guide
Continued
3-4 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Statistics based problems on cells
Continued
68P02900W36-P 3-5
1900.2AS May 2008
Statistics based problems on cells Chapter 3: Problem guide
Continued
3-6 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Statistics based problems on cells
68P02900W36-P 3-7
1900.2AS May 2008
Knowledge Editor problems Chapter 3: Problem guide
Up to 25 Knowledge Editor problems can be defined by NHA users. For further information,
refer to Using the Knowledge Editor in Chapter 2, Using the NHA.
Knowledge Editor problems are sent to the OMC with alarm numbers from 40901 to 40930.
NHA users can define external interface problems. For further information, refer to External
interfaces to detect problems on page 2-180. External interface problems can be sent to
the OMC with alarm number 40999.
3-8 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Call success problems
68P02900W36-P 3-9
1900.2AS May 2008
Call success Chapter 3: Problem guide
Call success
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Description
The call success problem examines call setup after an SDCCH channel has been established
successfully. This problem is reported for cells where the call success rate has dropped below a
configurable percentage.
For a breakdown of the call setup procedure, refer to Call setup troubleshooting - Channel
requests but no calls on page 3-34.
This formula looks for the percentage of call setup attempts (per-cell) that result in a successful
call setup. The call can be set up on the original cell or on a different cell.
NOTE
All BSS versions count every mobile-terminated supplementary service as a failed
call setup attempt.
TOTAL_CALLS + ASSIGNMENT_REDIRECTION[DIRECTED_RETRY
+ DURING_ASSIGNMENT + MULTIBAND_BAND]
-------------------------------------------------------------------*100%
OK_ACC_PROC [CM_SERV_REQ_CALL + CM_REESTABLISH + PAGE_RESPONSE + CM_SERV_REQ_SMS
+ CM_SERV_REQ_EMERG + LOC_FLW_ON_REQ_SMS + LOC_FLW_ON_REQ_NORM] -
SMS_INIT_ON_SDCCH - MT_LCS_ON_SDCCH + SMS_INIT_ON_SDCCH_HO_IN
For BSS 1800 and 1900 the NHA uses the following formula:
TOTAL_CALLS + ASSIGNMENT_REDIRECTION[DIRECTED_RETRY
+ DURING_ASSIGNMENT + MULTIBAND_BAND]
-----------------------------------------------------------------------------
*100%
OK_ACC_PROC[CM_SERV_REQ_CALL + CM_REESTABLISH + PAGE_RESPONSE + CM_SERV_REQ_SMS +
CM_SERV_REQ_EMERG + LOC_FLW_ON_REQ_SMS + LOC_FLW_ON_REQ_NORM] - SMS_INIT_ON_SDCCH
- MT_LCS_ON_SDCCH + SMS_INIT_ON_SDCCH_HO_IN – SMS_INIT_ON_TCH_FCS
That is:
Calls setup successfully + calls handed over due to directed retry feature*
--------------------------------------------------------------------------
Requests for TCH service
* These are call setups that started on this cell and completed successfully in a neighbor cell
because of the directed retry feature when this cell was congested.
3-10 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors
Problem detectors
There are two detectors using this formula. These detectors raise two different problems:
• Low Daily Call Success rate
This problem is raised if the daily detector is triggered. This detector uses a Daily Roll-up
detection mechanism.
This problem is raised if the very low detector is triggered. This detector uses a Sample
Roll-up detection mechanism.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181 at the end of this chapter.
Problem causes
The cause analysis for bad call setup success rates looks at the following areas:
• MSC assignment attempt rate
For further information about troubleshooting MSC assignment, refer to the Call Success
Problem Information View section in the NHA Online Help.
The NHA suggests possible causes which include various issues relating to the MSC, lack of TCH,
equipment, or neighbor problems, badly chosen configuration, and RF interference problems.
68P02900W36-P 3-11
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Cause CF
Analysis of MSC Connection
High SDCCH RF Loss:
- Neighbor Cell OOS Very High
- BSS Poor Initial Assignment Parameter Issue Medium
- BSS Carrier Configuration Change Medium
- RF issues (see RF issues, Table 3-5)
- Path balance issues (see Path balance issues, Table 3-4)
- RF Loss Guard Timer too Short High/Medium
- High SDCCH RF Loss High
Cipher Mode Failure Very High
MSC Refusing Connections High
MSC Overload Very High
MTL Congestion High
SMS Disabled Very High
RF Loss Guard Timer too Long Medium
MT_LCS_ON_SDCCH statistics Disabled Low
Low MSC Assignment Attempt Rate High
Analysis of TCH Blocking at Call Setup
TCH Congestion:
- RTF Outage Very High
- Out Of Service Timeslot Very High
- Lack of TCH Very High
- Invalid Radio Link Timeout Medium
- T3109 Invalid Medium
- T3111/T3111_TCH Parameter Not Optimised Medium
- Dynamic channel reconfiguration affecting TCH Congestion Low
- Neighbor Cell OOS Very High
- Stuck TCH Timeslot Medium
TCH Congestion Not Enabled Very High
TCH Blocking Without Congestion Very High
Continued
3-12 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Problem auto-clearing
• The Very Low Call Success rate is cleared using the default Very Fast problem clearance
mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of the problem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
68P02900W36-P 3-13
1900.2AS May 2008
Dropped call rate Chapter 3: Problem guide
Description
This problem looks at the percentage of dropped calls on the TCH, including RF loss and
dropped calls due to handover failure. A high value of dropped calls could indicate that there
is an equipment problem, frequency planning, coverage, handover problem, or software issue
at the cell.
For further information on dropped calls, refer to Low mean time between drop calls on
page 3-21.
Further analysis of the dropped call problem can be carried out using the information in the
Dropped Calls Problem Information View. Refer to the Dropped Call Rate problem in the NHA
Online Help for details. The information contained here is not used by the NHA in its automatic
analysis of this problem.
From GSR9 onwards, RF_LOSSES_TCH and RF_LOSSES_TCH_HR stats are split into bins where
the drop call classification algorithm analyzes the latest measurement report and concludes
why the call was dropped. Refer to the Statistics history for this problem for the breakdown
of the bins.
RF_LOSSES_TCH + INTRA_CELL_HO[INTRA_CELL_HO_LOSTMS] +
OUT_INTRA_BSS_HO[OUT_INTRA_BSS_HO_LOSTMS] + OUT_INTER_BSS_HO_LOSTMS) * 100%
---------------------------------------------------------------
TOTAL_CALLS + IN_INTER_BSS_HO[IN_INTER_BSS_HO_SUC] + IN_INTRA_BSS_HO[IN_IN-
TRA_BSS_HO_SUC]
CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_FAIL]
+ CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]
CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_ATMPT]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_SUC]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_RETURN]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]
3-14 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors
Problem detectors
Two dropped call rate problems are reported by the NHA. These are:
• High Daily Dropped Call rate
This problem is raised if the daily detector is triggered. This detector uses the Daily
Roll-up detection mechanism.
This problem is raised if the very high detector is triggered. This detector uses the Sample
Roll-up detection mechanism.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
The NHA suggests possible causes which include: neighbor cell outages, frequency planning
and coverage issues, congestion in neighbor cells, BSS handover parameter changes, or
changes to neighbor lists.
NOTE
In GSR9, RF_LOSSES_TCH and RF_LOSSES_TCH_HR have been broken down into
bins for different root causes of dropped calls. Refer to NHA Statistics History for
the bin values.
68P02900W36-P 3-15
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Cause CF
RF losses:
- Most RF losses on one carrier Very High
- RF loss guard timers too short High/Medium
- Full_pwr_rfloss Disabled Medium
- Link_about_to_fail Timer Medium
- High Intra-Cell HO Failed-Recovered Rate Medium
- High Intra-BSS HO Failed-Recovered with Neighbor High
- High Intra-BSS HO Failed-Recovered Rate Medium
- High Inter-BSS HO Failed-Recovered with Neighbor High
- High Inter-BSS HO Failed-Recovered Rate Medium
- Significant RF losses Very High
Dropped handovers:
- Intra-Cell Handover Failure High
- Intra-BSS Handover Failure High
- Inter-BSS Handover Failure High
- Neighbor added Medium
Path balance issues (refer to Path balance tests, Table 3-4 below).
RF issues (refer to RF issue tests, Table 3-5 below).
Neighbor Cell OOS High
Blacklisted Neighbor Cell OOS Medium
Neighbor cell congestion High
Low Intra-BSS handover attempt rate Medium
Low Inter-BSS handover attempt rate Medium
Incoming HO Disabled on Neighbor Medium
Problem cell added as neighbor Medium
Outgoing neighbor deleted Medium
Neighbor BCCH or BSIC mismatch High
Neighbors share BCCH and BSIC High
Neighbor BCCH Clash with BCCH High
Neighbor BCCH Clash with non-BCCH High
Ncc_of_plmn_allowed Conflict High
Dropped calls (default cause) Low
3-16 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Problem auto-clearing
• The High Daily Dropped Call rate is cleared using the default Daily problem clearance
mechanism.
• The Very High Dropped Call rate is cleared using the default Very Fast problem clearance
mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of the problem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
If the Path_Balance statistic is enabled, the NHA specifies one of the following as the cause of
the problem (see Table 3-4).
Table 3-4 Path balance tests
Cause CF
Rx Fault - One Carrier Cell High
Tx Fault - One Carrier Cell High
Rx Fault - All Carriers High
Tx Fault - All Carriers High
Rx Fault - One Known Bad Carrier High
Rx Fault - One Bad Carrier High
Tx Fault - One Known Bad Carrier High
Tx Fault - One Bad Carrier High
Rx Fault - N Known Bad Carriers High
Rx Fault - N Bad Carriers High
Tx Fault - N Known Bad Carriers High
Tx Fault - N Bad Carriers High
Possible Radio Equipment fault (default) Medium
68P02900W36-P 3-17
1900.2AS May 2008
RF issue tests Chapter 3: Problem guide
The NHA checks the Path_Balance of each carrier and tries to identify if there is a problem on a
particular carrier, or a common problem affecting all carriers in the cell.
NOTE
• If LNAs (Mast Head Amplifiers) are in use, the Path_Balance statistic is affected.
In some cases, the average value of the statistic is shifted into the zone where
the NHA thinks there is a transmit equipment problem.
• LNAs are not managed by the OMC so the NHA has no knowledge of when they
are in place. If the NHA suggests such a fault, check whether the cell uses LNAs
before replacing equipment.
RF issue tests
Cause CF
High Bit Error Rate:
- High BER with Frequency Reuse High
- High BER but no Frequency Reuse Medium
High Frame Erasure Rate:
- High FER with Frequency Reuse High
- High FER but no Frequency Reuse High
High Interference on Idle (IOI):
- High IOI with Frequency Reuse High
- High IOI but no Frequency Reuse Medium
Interference prone radio carrier frequencies in use Low
The NHA uses the Bit Error Rate (BER) statistic to identify a carrier with downlink interference,
then it examines neighbor cells for any co-frequencies or adjacent frequencies that might
cause interference.
3-18 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High second assignment
Description
When a TCH assignment failure occurs during call setup, the MS moves back to its SDCCH
channel. From here, if the second assignment feature is enabled, it retries for a second time. If
this second attempt fails, then a TCH call setup failure occurs.
If a significant number of second assignment failures occur then the NHA raises this problem.
The NHA uses this detector to catch a problem where TCH assignment is not working well but
the problem is being hidden by the successful operation of the second assignment feature.
It is worth fixing this problem so that the call setup success rate is not bad at times when
the cell is very busy. The second assignment feature only helps call setup and does not help
with incoming handovers.
IF
SECOND_ASSIGN_ATMPT
--------------------------------------------------- * 100 > threshold
MA_CMD_TO_MS - SECOND_ASSIGN_ATMPT - INTRA_CELL_HO_ATMPT_FR_FR -
INTRA_CELL_HO_ATMPT_HR_HR - INTRA_CELL_HO_ATMPT_HR_FR -
INTRA_CELL_HO_ATMPT_FR_HR – INTRA_CELL_HO_ATMPT_SD_TO_SD
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem auto-clearing
• The Very High Second Assignment rate problem is automatically cleared from the Problem
window using the default Very Fast problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-19
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Problem causes
Cause CF
Path balance issues (refer to Table 3-4)
RF issues (refer to RF issue tests, Table 3-5)
Inactive timeslot Very High
TCH RF Assignment Failure (default cause) Very High
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of the problem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-20 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Low mean time between drop calls
Description
This problem detects if the problem cell is suffering a very low mean time between dropped calls.
It can be used as an alternative to the High Drop Call detector which is limited in cells where
many calls hand into and out of the cell for a very short period of time. The drop call rate
on these cells can appear low even when there are many dropped calls. The Low Mean
Time Between Drop Calls detector measures the number of dropped calls against the traffic
(BUSY_TCH_MEAN) and so is a better problem detector for cells that handle many short calls
for a short time.
CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_FAIL]
+ CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]
CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_ATMPT]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_SUC]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_RETURN]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]
Problem detectors
This detector monitors the drop calls against the amount of call traffic, so that it can provide a
comparison between the cells.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Low mean time between dropped calls uses the same causes as the Dropped call rate
problem detector. Refer to Table 3-3 for further information.
68P02900W36-P 3-21
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Problem auto-clearing
The Low mean time between dropped calls problem is automatically cleared from the
Problem window using the default Daily problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of the problem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-22 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Low TCH mean holding time
Description
This problem is detected if the average TCH holding time in this cell is extremely low. For
example, if there is a serious problem regarding voice quality, then the calls are terminated
quickly.
NOTE
It is normal for some cells to have a low mean holding time, for example, a cell on a
busy highway only holds a call for a short period of time.
That is:
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
68P02900W36-P 3-23
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Cause CF
Low mean holding time Very High
Problem auto-clearing
The Low mean holding time problem is automatically cleared from the Problem window using
the default Daily problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-24 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Immediate assignment problems
68P02900W36-P 3-25
1900.2AS May 2008
High immediate assignment failure rate Chapter 3: Problem guide
Description
The Immediate Assignment Failure Rate detector monitors the rate of channel (SDCCH and fast
call setup TCH) “immediate assignment” type failures. This problem occurs when the mobile
fails to establish a connection once it has been allocated a channel on immediate assignment.
Unsuccessful channel access is a frequent problem in many networks, usually due to poor
coverage and/or radio interference.
NOTE
This detector was previously named SDCCH access failure. It has been changed
in GSR8 to encompass fast TCH channel assignments which are possible using the
Fast Call Setup feature.
For BSS version 1760, the NHA uses the following formula:
CHAN_REQ_MS_FAIL * 100%
--------------------------------------------------------------
OK_ACC_PROC_SUC_RACH - INV_EST_CAUSE_ON_RACH - CHAN_REQ_MS_BLK
For BSS versions 1800 and 1900, the NHA uses the following formula:
CHAN_REQ_MS_FAIL * 100%
-------------------------------------
OK_ACC_PROC_SUC_RACH - CHAN_REQ_MS_BLK
Problem detectors
Two high immediate assignment failure problems are reported by the NHA. These are:
• High Daily Immediate Assignment Failure Rate
3-26 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
NOTE
The detectors for this problem are disabled by default. The user can enable
these detectors using the Thresholds option from the Configure menu on the
Problem window.
For information about default threshold values for each detector, refer to NHA default
thresholds on page 3-181 at the end of this chapter.
Problem causes
Cause CF
Path balance issues (refer to Dropped call rate on page 3-14).
Radio issue:
- Radio issue (one radio in problem cell) Very High
- Multiple radio issue Very High
Carrier configuration changes High
Neighbor cell OOS Very High
T3101 cell parameter not optimized Very High
BSS poor initial assignment parameter issue Medium
RF issues (refer to RF issue tests, Table 3-5).
High immediate assignment failure rate (default cause)
Problem auto-clearing
• The Very High Immediate Assignment Failure Rate is cleared using the default Very Fast
problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-27
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-28 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Low immediate assignment success rate
Description
Unsuccessful SDCCH or “fast” TCH channel access is a frequent problem in many networks due
to poor coverage and/or radio interference.
Looking at the Low Immediate Assignment Success Rate allows the detection of a particular
scenario where the success rate is low but the failure rate is also low. This problem covers all
the cases and analysis of high failure rates. It can also detect cases where the Immediate
Assignment Success Rate is low and not detected by Immediate Assignment Failure Rate.
For BSS version 1760, the NHA uses the following formula:
(OK_ACC_PROC[CM_SERV_REQ_CALL] + OK_ACC_PROC[CM_SERV_REQ_SMS] +
OK_ACC_PROC[CM_SERV_REQ_SUPP] + OK_ACC_PROC[CM_SERV_EMERG] +
OK_ACC_PROC[CM_REESTABLISH] + OK_ACC_PROC[LOCATION_UPDATE] +
OK_ACC_PROC[IMSI_DETACH] + OK_ACC_PROC[PAGE_RESPONSE] +
OK_ACC_PROC[LOCATION_SERVICES] ) * 100%
---------------------------------------------------------------
OK_ACC_PROC_SUC_RACH - INV_EST_CAUSE_ON_RACH - CHAN_REQ_MS_BLK
For BSS version 1800 and 1900, the NHA uses the following formula:
That is:
The number of successful channel requests over the number of successful RACHs, disregarding
phantom RACHs, and channel requests blocked.
Problem detectors
Two Low immediate assignment success rate problems are reported by the NHA. These are:
• Low Daily Immediate Assignment Success Rate
68P02900W36-P 3-29
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181 at the end of this chapter.
Problem causes
This problem is normally raised when poor Initial Assignment is enabled which could account for
a discrepancy in the High immediate assignment failure rate, or where the low success rate is
not accompanied by a high failure rate and the NHA cannot provide a reason for this discrepancy.
Cause CF
Use of poor initial assignment feature Very High
Statistics inconsistency in accessing a channel Very High
Immediate assignment failure (default cause)
Problem auto-clearing
• The Very Low Immediate Assignment Success Rate problem is cleared using the default
Very Fast problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-30 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst SDCCH RF loss rate
Description
This problem looks at the percentage of calls which drop while on an SDCCH. High losses
indicate that there is an equipment, frequency planning, coverage, or software issue at the cell.
The following formula for SDCCH RF Loss rate is used to detect this problem (in simple terms,
this is the percentage of mobiles that start using an SDCCH successfully but then the SDCCH
RF is lost):
For BSS version 1760, the NHA uses the following formula:
RF_LOSSES_SD * 100%
-------------------
ALLOC_SDCCH - CHAN_REQ_MS_FAIL
For BSS version 1800 and 1900, the NHA uses the following formula:
RF_LOSSES_SD * 100%
-------------------
ALLOC_SDCCH - CHAN_REQ_MS_FAIL_SDCCH
that is:
Problem detectors
Two SDCCH RF loss rate problems are reported by the NHA. These are:
• High Daily SDCCH RF Loss rate.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
68P02900W36-P 3-31
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Problem causes
The NHA suggests possible causes which include: neighbor cell outages, interference coverage
issues, faulty mobiles, or BSS parameter issues.
Cause CF
Neighbor Cell OOS Very High
BSS Poor Initial Assignment Parameter issue Medium
Carrier Configuration Changes Medium
RF issues (refer to RF issue tests, Table 3-5).
Path balance (refer to Dropped call rate on page 3-14). Medium
RF Loss Guard Timer too short Medium
High SDCCH RF loss (default cause) High
Problem auto-clearing
• The Very High SDDCH RF Loss rate is cleared using the default Very Fast problem
clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
3-32 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Outage problems
Outage problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
• One-way MTL
68P02900W36-P 3-33
1900.2AS May 2008
Channel requests but no calls Chapter 3: Problem guide
Description
This problem monitors each stage of the call setup procedure. For a complete description,
refer to the next section Call setup troubleshooting. This problem detects when the NHA is
receiving channel requests (RACHs) for a cell but no calls are being set up in the cell.
Low Call Activity detects when there are no RACHs. Thereafter, other problems detect failure
at various stages of call setup. In particular, Call Setup detects the situation where total calls
are low in comparison with successful SDCCH accesses. Channel Requests but no calls is a
catch-all detector, from RACHs to successful calls. In particular, it captures situations where
not enough samples are available to trigger other problems.
If other problems are triggered with this one (for example, Call Setup, Low Immediate
Assignment Success Rate), the NHA operator is advised to ignore this problem and look at the
other problem.
The following description is useful for troubleshooting the stages involved in Call Setup. The
formulae which NHA uses at each stage are shown.
The mobile sends a Channel Request message (RACH) to request access to the network. The
number of RACHs received by a cell is given by the OK_ACC_PROC_SUC_RACH statistic. Some
of the RACHs can contain an invalid value in the Establishment Cause field. These are removed
and counted in the INV_EST_CAUSE_ON_RACH statistic. Low numbers of RACHs are normally
due to equipment or antenna problems.
NOTE
The INV_EST_CAUSE_ON_RACH statistic is not valid from GSR8 onwards.
After the BTS receives a Channel Request, the next step is to allocate an SDCCH or (Fast)
TCH channel, using the following procedure:
3-34 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Call setup troubleshooting
NOTE
If the channel accesses are failing, retries can cause blocking.
2 When a channel is allocated, and the Immediate Assignment message is sent
to the Mobile, the ALLOC_SDCCH is pegged. The mobile must then
access the channel. If the mobile fails to access the channel at this
stage, the statistic CHAN_REQ_MS_FAIL is pegged (per timeslot).
The OMC totals this for each cell as CHAN_REQ_MS_FAIL_ROLL.
The Immediate Assignment Failure Rate is given by:
CHAN_REQ_MS_FAIL_ROLL * 100%
----------------------------
OK_ACC_PROC_SUC_RACH - CHAN_REQ_MS_BLK
Successful accesses are pegged in OK_ACC_PROC which is a counter array with bins for page
responses, call requests, location updates, and so on. Failure to appear on the channel may be
due to interference or equipment problems, parameter settings, or neighbor cell outages.
After the mobile has successfully accessed the SDCCH, the call can be dropped while still
on the SDCCH.
RF_LOSSES_SD * 100%
-------------------
ALLOC_SDCCH - CHAN_REQ_MS_FAIL_SDCCH
The Call Setup Success Rate measures the success rate in getting from SDCCH (or fast TCH) to
TCH. The formula is:
68P02900W36-P 3-35
1900.2AS May 2008
Call setup troubleshooting Chapter 3: Problem guide
There are two formulae for the Call Success Rate problem, depending on the BSS version. For
details, refer to Call success on page 3-10.
The formula includes a term for cases when the assignment is redirected to another cell, that
is, where the call origination came on this cell but the TCH is allocated on another cell, for
example, with the directed retry procedure.
If the Call Success Rate is bad, the next step is to see what part of call setup is failing, using the
following procedure:
1 The first part of call setup involves the MSC. First, a connection is set up
to the MSC, then authentication is performed. The MSC sends an
assignment request for a TCH. The MSC Assignment Attempt Rate
at call setup shows how the percentage of call setup attempts that
survive this first step, end in an Assignment Request from the MSC:
MA_REQ_FROM_MSC - MA_COMPLETE_TO_MSC + TOTAL_CALLS * 100%
---------------------------------------------------------
OK_ACC_PROC[CM_SERV_REQ_CALL + CM_REESTABLISH + PAGE_RESPONSE +
CM_SERV_REQ_SMS + CM_SERV_REQ_EMERG + LOC_FLW_ON_REQ_SMS +
LOC_FLW_ON_REQ_NORM] -SMS_INIT_ON_SDCCH - MT_LCS_ON_SDCCH
+ SMS_INIT_ON_SDCCH_HO_IN - SMS_INIT_ON_TCH_FCS
Continued
3-36 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae for detecting this problem
During call setup, the mobile is assigned a TCH on the originating cell
or, if Multiband Reassignment is being used, the mobile is
assigned a TCH on a neighbor cell in a different frequency band.
The Call Setup RF Assignment Success Rate gives the
percentage of TCH assignments on the originating cell that
are for call setup and that are successful. The formula is:
MA_COMPLETE_FROM_MS - INTRA_CELL_HO_SUC
---------------------------------------------------------- X 100%
MA_CMD_TO_MS - INTRA_CELL_HO_ATMPT
For BSS version 1760, the NHA uses the following formula:
OK_ACC_PROC_SUC_RACH - OK_ACC_PROC[LOCATION_UPDATE] -
OK_ACC_PROC[IMSI_DETACH] - OK_ACC_PROC[CM_SERV_REQ_SUPP] -
SMS_INIT_ON_SDCCH - OK_ACC_PROC{LOCATION_SERVICES] +
SMS_INIT_ON_SDCCH_HO_IN
> a threshold number of channel requests and the total number of calls is zero.
For BSS version 1800 and1900, the NHA uses the following formula:
> a threshold number of channel requests and the total number of calls is zero.
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
68P02900W36-P 3-37
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Problem causes
No automatic analysis is performed on this problem. For further information, refer to the
previous section Call setup troubleshooting.
Problem auto-clearing
The NHA automatically clears the problem if the TOTAL_CALLS statistic is above 0 in any
subsequent interval, using the default Immediate problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of the problem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-38 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Very low call activity
Description
This detects a rare condition where there is no mobile activity over a long time.
That is, if there are no requests from mobiles to use the network for a period of several hours
and the cell is unbarred, so that mobiles can set up calls on the network. The following formulae
are used:
Problem detectors
This detector uses the Interval Roll-up detection mechanism. This detector first checks if the
cell allows originations, then looks for less than threshold values for the number of RACHs
in the interval.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
NOTE
By default, this detector is subject to the "time of day" Monitoring Schedule. For
further information, refer to NHA Monitoring Schedule on page 4-55.
Problem causes
68P02900W36-P 3-39
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
If this problem occurs, check the last time it occurred. Some cells have no traffic, for example,
in a shopping mall overnight. If this problem is raised at a time when the cells should have
traffic, then investigate the problem.
Problem auto-clearing
The NHA automatically clears problems from the Problem window using the default Immediate
problem clearance mechanism, that is, it clears after one statistics interval unless it keeps
repeating.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of the problem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
3-40 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Low number of mobile terminated calls
Description
This problem is detected when a cell has a low percentage of mobile terminated calls - but
there are mobile originated calls.
OK_ACC_PROC[PAGE_RESPONSE]
--------------------------------- * 100
OK_ACC_PROC[CM_SERV_REQ_CALL] + OK_ACC_PROC[PAGE_RESPONSE]
Problem detectors
This detector first checks if the cell allows originations, then looks at the proportion of mobile
terminated versus mobile originated requests for access.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Immediate
problem clearance mechanism, that is, it clears after one statistics interval unless it keeps
repeating.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-41
1900.2AS May 2008
Out of service timeslots in cell Chapter 3: Problem guide
Description
This problem detects out-of-service (OOS) timeslots which reduce a cell's capacity. This can
contribute to congestion issues.
For BSS version 1760, the NHA uses the following formula:
For BSS versions 1800 and 1900, the NHA uses the following formula:
That is:
The actual number of available traffic channels in the cell is less than the number of TCH
configured in the cell.
NOTE
Carrier A & B is the terminology used in the Double Density (DD) CTU2 which
represents the carrier pair.
Problem detectors
This problem is reported if a timeslot or a carrier is out-of-service (OOS) in the cell. The value of
AVAILABLE_TCH_MEAN is also reduced if an RTF goes OOS for a short time and then returns to
service. The NHA does not report the problem in this case, only if the RTF stays OOS.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
3-42 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
Problem causes
Cause CF
RTF outage Very High
Out of service timeslot Very High
Reduced cell capacity High
If the BSS database contains dummy carriers, that is, carriers which do not actually exist, the
NHA assumes that the carriers are real and that they are out-of-service. As a result, the OOS
timeslot problem can be raised and the RTF Outage cause is presented as a cause of congestion.
In the worst cases, the NHA reports many OOS timeslot problems for these dummy carriers. As
the NHA has a limit of 400 open problems, older problems are deleted.
To address this issue, there are a number of options available. Operators can disable the OOS
timeslot detector but this is not the preferred option, unless older problems are being deleted
too quickly. Alternatively, a subscription can be used to block out the OOS timeslot problems
from the Problem window.
The daily report contains details of OOS timeslot problems and should be examined. If the
cause is RTF Outage, then ignore the problem.
If the RTF Outage cause is presented for other types of problems, check the list of RTFs in the
cause to see if any of the RTFs are, in fact, dummy RTFs.
Problem auto-clearing
The NHA automatically clears problems from the Problem window using the default Immediate
problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
68P02900W36-P 3-43
1900.2AS May 2008
Very low TCH usage Chapter 3: Problem guide
Description
The NHA detects if there is no RACH activity (Low Call Activity) on a cell, and where there are
a reasonable number of RACHs but no calls (Channel Requests but No Calls). This detector
provides a further dimension to the NHA's coverage of quiet cells by looking at cells that report
very low TCH usage.
By looking at the BUSY_TCH_MEAN statistic, the Very low TCH usage detector can provide a
warning to the operator if a cell is carrying very little traffic over recent intervals. This problem
may be raised along with the Very Low Call Activity problem, so it may be necessary to
DISABLE one of these detectors.
BUSY_TCH_MEAN < = 0
Problem detectors
This problem is detected using the Interval Roll-up detector. A default value of one interval is
used. This value can be reconfigured by the operator.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181 at the end of this chapter.
NOTE
By default, this detector is subject to the "time of day" Monitoring Schedule. For
further information, refer to NHA Monitoring Schedule on page 4-55.
Problem causes
The default cause Very Low TCH Usage is raised whenever this problem is detected by the NHA.
Problem auto-clearing
3-44 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional information
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
68P02900W36-P 3-45
1900.2AS May 2008
One-way MTL Chapter 3: Problem guide
One-way MTL
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Description
This detector is another version of the One-way Message Transfer Link (MTL) script. It uses
MTL statistics to monitor the number of Message Signal Units (MSUs) that are sent and received
over the MTL. If an MTL has not either sent or received any messages over a thresholded
period of time, then the problem is raised.
Problem detectors
Threshold values for script-based detectors are stored in the script itself and not in the threshold
file. The thresholds are fixed and not configurable. For information on default threshold values
for each detector, refer to NHA default thresholds on page 3-181.
Problem causes
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily problem
clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
3-46 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional information
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
68P02900W36-P 3-47
1900.2AS May 2008
Overload problems Chapter 3: Problem guide
Overload problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
• Paging overflow
3-48 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High GPROC utilization
Description
This problem detects high GPROC utilization and alerts the operator. This problem is raised
if the CPU_USAGE_MEAN and CPU_USAGE_MAX for any GPROC in the SITE is greater
than/equal to a statistics threshold.
If the GPROC CPU usage stays very high, then call processing can be affected.
Threshold values
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Cause CF
High GPROC CPU utilization Very high
GPROC utilization should be kept at or below the levels recommended in the manual System
Information: BSS Equipment Planning (68P02900W21) to get good performance from the
network.
The operator can change the distribution of functions to processors at the site, or add more
GPROCs, to reduce the CPU utilization.
68P02900W36-P 3-49
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
It is recommended that the mean utilization of GPROCs should be maintained below 70%. The
cpu_usage_max statistic for the BSP can reach 100% (depending on the number of statistics
enabled) during statistics upload from the BSC to the OMC. This is normal performance
provided the cpu_usage_mean statistic is maintained around 70%. All GPROCs should function
normally up to 100% utilization after which inter process communication starts to slow up due
to queuing of internal BSS messages, impacting system performance. If GPROCs are showing
cpu_usage_mean values of 70% or higher then it is worth further investigation.
Utilization of GPROC and GPROC2 boards can exceed these levels. The GPROC3 board is
designed to maintain the mean utilization below 70%. Consider changing to GPROC3 if older
generation GPROCs are being used.
Problem auto-clearing
This problem uses the default End of Next Working day problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
Refer to the Statistics history for this problem for a comparison of the CPU_USAGE_MAX and
CPU_USAGE_MEAN values.
3-50 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High immediate assignment blocking
Description
The High Immediate Assignment Blocking detector looks at blocking on system access
originations only, not blocking in SDCCH handovers. A blocked SDCCH handover does not
mean a failed setup.
NOTE
This detector was previously named High SDCCH Blocking. It has been changed
in GSR8 to encompass fast TCH channel assignments which are possible using the
Fast Call Setup feature.
For BSS version 1760, the NHA uses the following formula:
CHAN_REQ_MS_BLK * 100%
------------------------------------------------------
OK_ACC_PROC_SUC_RACH - INV_EST_CAUSE_ON_RACH
For BSS versions 1800 and 1900, the NHA uses the following formula:
CHAN_REQ_MS_BLK * 100%
------------------------------------
OK_ACC_PROC_SUC_RACH
That is:
Detectors
High Immediate Assignment Blocking uses the Interval Roll-up detection mechanism.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
68P02900W36-P 3-51
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Problem auto-clearing
The NHA automatically clears problems from the Problem window using the default End of Next
Working Day problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Problem causes
Cause CF
Poor optimization at location area boundaries Very High
Invalid radio link time-out High
T3109 Invalid High
T3111 Cell Parameter Not Optimized Medium
T3111 SD Cell Parameter Not Optimized Medium
T3101 Cell Parameter Not Optimized Medium
Neighbor Cell OOS Very High
Stuck SDCCH timeslot Medium
Heavy Call Queuing High
bssmap_t11 parameter not optimized High
BSS software issue High
High Immediate Assignment Blocking (default cause) High
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-52 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High TCH blocking
Description
TCH blocking results in reduced call processing which prevents mobiles from accessing the
network.
MA_CMD_TO_MS_BLKD
----------------- x 100 %
MA_REQ_FROM_MSC
That is:
The ratio of call setups which had TCH assignment blocked to those which were successful.
Problem detectors
The TCH blocking detector tests for the presence of a minimum degree of TCH blocking on a
CELL.
The thresholds are configurable on a per cell-group basis with the following default:
• 8% blocking for 2 hours
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem auto-clearing
The NHA automatically clears problems from the Problem window using the default End of Next
Working Day problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-53
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Problem causes
Cause CF
Neighbor Cell OOS Very High
Other layer underutilized High
Inner zone underutilized High
Stuck TCH Timeslot Medium
Lack of TCH High
Invalid RADIO_LINK_TIMEOUT High
T3109 Invalid High
T3111 Cell Parameter Not Optimized Medium
T3111_TCH Cell Parameter Not Optimized Medium
Dynamic Channel Reconfiguration Affecting TCH Congestion Low
RTF Outage Very High
Out Of Service timeslot Medium
TCH congestion not enabled Very High
TCH blocking without congestion Very High
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
3-54 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Paging overow
Paging overow
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Description
This problem occurs when paging channel usage in a cell is extremely high and the paging
queue is overflowing resulting in the loss of pages. This issue can be caused by inappropriate
configuration of the BSSs paging configuration attributes for the paging traffic currently being
experienced, or by a mismatch between the BSS and MSC paging channel rates.
PCH_Q_PAGE_DISCARD
------------------ X 100
PAGE_REQ_FROM_MSC
That is:
Problem detectors
This problem is detected if the threshold exceeds 0% over a one hour time period. The minimum
sample size is set to one.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181 at the end of this chapter.
Problem causes
• Examine the configuration of paging resources in the problem cell, for example, the values
of ccch-conf and bs_ag_blks_res.
68P02900W36-P 3-55
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Access Grant
CCCH Conguration Maximum Paging Rate Maximum Paging Rate
Blocks Reserved
(ccch_conf) by IMSI per Second by TMSI per Second
(bs_ag_blk_res)
1 0 25.5 51
1 1 17.0 34
1 2 8.5 17
0 0 76.5 153
0 1 68.0 136
0 2 59.5 119
0 3 51.0 102
0 4 42.5 85
0 5 34.0 68
0 6 25.5 51
0 7 17.0 34
0 8 8.5 17
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily problem
clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-56 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High MTL utilization
Description
This problem detects when the MTL (Message Transfer Link) links are overloaded. An MTL
is deemed to be overloaded if it exceeds the recommended utilization rate (many switches
only allow a maximum link utilization of 20%).
The manual System Information: BSS Equipment Planning (68P02900W21) recommends that
C7 links are designed to operate at no more than 20% link utilization when the MTL/LMTL is
running on a GPROC2 or GPROC3. Before use of the 40% utilization for GPROC2 or GPROC3, it
is imperative that the operator verifies if the MSC vendor can also support 40% utilization at the
MSC end. If not, then only 20% link utilization should be used for GPROC2 and GPROC3.
This detector uses the lower utilization rate of 20%. It provides a warning to the operator that
additional MTL capacity is required or that MTL outages are overloading the network. If any
MTLs are out-of-service (OOS), this puts added load on the in-service MTLs.
The formulae for this problem cover uplink and downlink MTL utilization. The problem is raised
if the formula below exceeds the threshold.
For BSS versions 1760 and 1800, the NHA uses the following formulae:
MTL utilization TX
MTL utilization RX
For BSS version 1900, the NHA uses the following formulae:
IF MTL::mtl_rate==1
MTL utilization TX
MTL utilization RX
68P02900W36-P 3-57
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
ELSE IF MTL::mtl_rate==31
Problem detectors
The High MTL utilization problem detector compares the result of the MTL utilization
formulae against a configurable threshold of 20%. This detector uses the fixed threshold
mechanism and looks at one statistics interval at a time.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
The default cause High MTL utilization is raised whenever this problem is detected by the
NHA.
Problem auto-clearing
The NHA automatically clears problems from the Problem window using the default End of Next
Working Day problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-58 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High estimated RSL utilization
Description
To detect this problem, the NHA estimates the RSL utilization rate for a BTS and flags any RSLs
that exceed the recommended rate.
The manual System Information: BSS Equipment Planning (68P02900W21) recommends that
RSLs should operate at no more than a 25% utilization rate. This detector estimates the level
of signaling traffic occurring on the RSLs for a given time period and compares this to a
configurable threshold. The current RSL statistics do not allow RSL utilization to be calculated,
so this detector uses a combination of cell statistics and message sizes to give an approximate
estimation of RSL use.
The signaling procedures include call setup, SMS, incoming and outgoing handover, location
update, and paging messages. Each procedure can be broken down into a series of messages,
each with a measurable byte size. The level of utilization can be estimated in this way.
NOTE
This detector should be disabled once all the BSS are upgraded to 1900. As this
detector has been superseded by High RSL Utilization detector from GSR9 onwards,
it is recommended that the High RSL Utilization detector is used in its place. Refer
to Modifying detectors and thresholds on page 2-133 for information on how
to enable/disable the detector.
The formulae for this problem estimate uplink and downlink RSL utilization. The problem is
raised if the formula below exceeds the threshold. Refer to Table 3-16 in the next section for a
list of the signaling message sizes.
For BSS versions 1760 and 1800, the NHA uses the following formula:
Sum for all cells in the BTS [SMS * UL SMS Bytes + Intra_BSS_HOs * UL In-
tra_BSS_HO Bytes + Inter_BSS_HOs * UL Inter_BSS_HO Bytes + Location Updates * UL
Location Update Bytes + Mobile Orig Call Setups * UL MO Call Setup Bytes + Mobile
Term Call Setups * UL MT Call Setup Bytes + Location Services * UL LCS Bytes] * 8
-------------------------------------------------------------------- * 100%
Number of INS RSLs for the BTS * RSL Capacity * (Interval Length in Seconds *
No. of Intervals)
68P02900W36-P 3-59
1900.2AS May 2008
Signaling message sizes Chapter 3: Problem guide
(Sum for all cells in the BTS [SMS * DL SMS Bytes + Intra_BSS_HOs * DL
Intra_BSS_HO Bytes + Inter_BSS_HOs * DL Inter_BSS_HO Bytes + Location Updates
* DL Location Update Bytes + Mobile Orig Call Setups * DL MO Call Setup Bytes
+ Mobile Term Call Setups * DL MT Call Setup Bytes + Location Services *
DL LCS Bytes] * 8) + (Sum per BTS [Paging Requests * DL Page Bytes] * 8)
-------------------------------------------------------------------- * 100%
Number of INS RSLs for the BTS * RSL Capacity * (Interval Length in Seconds *
No. of Intervals)
The message sizes in Table 3-16 are based on a realistic model. The message sizes listed in this
table include an overhead (header) value of 12 bytes per message.
Problem detectors
The High estimated RSL utilization detector sums the signaling message sizes for all cells
under a site and compares the result of the RSL utilization formulae against a configurable
threshold. This detector uses the Interval Roll-up detection mechanism which estimates
the average RSL utilization over a configurable number of statistics intervals. The default
is one interval.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
3-60 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
Problem causes
Cause CF
RSL Out Of Service Very High
High estimated RSL utilization (default) High
Problem auto-clearing
This problem uses the default End of Next Working day problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
68P02900W36-P 3-61
1900.2AS May 2008
High RSL Utilization Chapter 3: Problem guide
Description
This feature detects when the RSL links are overloaded. An RSL link is deemed to be overloaded
if it exceeds the recommended utilization rate.
This feature provides an indication of RSL link utilization. Two RSL raw statistics
RSL_TX_OCTETS and RSL_RX_OCTETS are provided by the BSS which enables the operator to
determine the octets sent over the Abis interface. Both 16k and 64k RSL links are supported.
Another new raw statistic RSL_LINK_INS indicates the RSL link in-service duration. In this way,
the key statistic RSL link utilization can be determined at the OMC.
The formulae for this problem cover uplink and downlink RSL utilization. The problem is raised
if the formula below exceeds the threshold.
RSL_RX_UTILIZATION
RSL_RX_OCTETS * 8
------------------------------- * 100%
RSL_LINK_INS * RSL_LINK_RATE
RSL_TX_UTILIZATION
RSL_TX_OCTETS * 8
------------------------------- * 100%
RSL_LINK_INS * RSL_LINK_RATE
Problem detectors
The High RSL utilization problem detector compares the result of the RSL utilization formulae
against a configurable threshold. This detector uses the fixed threshold mechanism and
examines one statistics interval at a time.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
3-62 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
Problem causes
One or more RSLs have exceeded the configured utilization threshold. The maximum utilization
rate recommended by Motorola is 25%. Overloaded RSLs can cause poor performance across all
cells at a single site.
Problem auto-clearing
This problem uses the default End of Next Working day problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
68P02900W36-P 3-63
1900.2AS May 2008
Handover problems Chapter 3: Problem guide
Handover problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
3-64 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Interband handover success
Description
The statistic PGSM_HO_ATMPT counts all intercell handover attempts, both intra-BSS and
inter-BSS, to a channel in the GSM900 frequency band.
The statistic PGSM_HO_FAIL counts every unsuccessful outgoing intercell handover attempt
to the GSM frequency band, including cases where the call drops and the call recovers to
the original cell.
INTERBAND_ACTIVITY[PGSM_HO_ATMPT] - INTERBAND_ACTIVITY[PGSM_HO_FAIL]
----------------------------------------------------- * 100% < THRESHOLD
INTERBAND_ACTIVITY [PGSM_HO_ATMPT]
and
INTERBAND_ACTIVITY[DCS1800_HO_ATMPT] - INTERBAND_ACTIVITY[DCS1800_HO_FAIL]
------------------------------------------------------ * 100% < THRESHOLD
INTERBAND_ACTIVITY[DCS1800_HO_ATMPT]
and
68P02900W36-P 3-65
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
INTERBAND_ACTIVITY[EGSM_HO_ATMPT] - INTERBAND_ACTIVITY[EGSM_HO_FAIL]
------------------------------------------------------ * 100% < THRESHOLD
INTERBAND_ACTIVITY[EGSM_HO_ATMPT]
and
that is:
The above formula only monitors certain cases, that is, it monitors outgoing handover success
broken down according to the frequency band of the target call. It ignores calls and intervals
where all outgoing handovers go to the same frequency band because this is already queried by
the other outgoing handover success detectors.
Problem detectors
Each of the handover categories has two detectors, one detector using Daily Roll-up and one
using minimum Sample Roll-up.
• Low Daily Handover Success rate to PGSM900.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
The NHA does not perform any automated problem analysis on this detector. However, it does
present text of the default cause High Interband handover failure.
3-66 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Problem auto-clearing
• The Very Low Handover Success rate problem is automatically cleared from the Problem
window using the default Very Fast problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
68P02900W36-P 3-67
1900.2AS May 2008
Low incoming handover success rate (inter/intra BSS) Chapter 3: Problem guide
Description
This problem detects the Incoming handover success rate in all cells. The main contributing
factors for poor handover performance are neighbor cell faults, poor RF planning, and poor
database parameter settings.
That is:
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
3-68 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Cause CF
Problem auto-clearing
The Low Incoming Handover Success Rate problem is automatically cleared from the Problem
window using the default Daily problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
68P02900W36-P 3-69
1900.2AS May 2008
Low Inter-BSS handover attempt rate Chapter 3: Problem guide
Description
This detector monitors the inter-BSS handover attempt rate per cell. There are three steps to
making a handover:
1. HO_REQ (the need for a handover is recognized)
The NHA outgoing and incoming handover success rate detectors monitor between steps 2 and
3. This detector monitors step 1 to step 2 for inter-BSC handovers.
Normally, a handover is attempted every time it is needed unless the target cell is congested.
However, inter-BSC handover attempts can also be prevented by problems at the MSC.
OUT_INTER_BSS_HO_ATMPT * 100
---------------------------- < Threshold
OUT_INTER_BSS_REQ_TO_MSC
The NHA monitors this formula every statistics interval using its Sample Roll-up mechanism to
calculate a moving average value.
Threshold values
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
If neighbor cells on other BSCs are congested and reject inter-BSS handover attempts, the NHA
reports the cause as Neighbor Cell Congestion (Inter-BSS). Otherwise, the NHA reports the
cause Low Handover Attempt rate.
Problem auto-clearing
3-70 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional information
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
The Detector Information for this problem shows the formula used by the NHA, the number of
handover attempts and handovers required and the number of statistics intervals it combined
to calculate the attempt rate value. The NHA Statistics History can be used to see these
values per statistics interval.
68P02900W36-P 3-71
1900.2AS May 2008
Low mean time between handovers Chapter 3: Problem guide
Description
This problem is detected if there is low mean time between successive handovers from a cell,
that is, calls only stay on the cell for a short time before handing over to another cell. In this
case a cell is continuously handing over its calls to neighboring cells.
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Cause CF
Low mean time between handovers High
Problem auto-clearing
• The Very Low mean time between handovers problem is automatically cleared from the
Problem window using the default Very Fast problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
3-72 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Outgoing handover success rate
Description
The NHA detects poor outgoing handover performance at intra-cell, intra-BSS, and inter-BSS
levels.
This detector covers handover success rates. Whether the unsuccessful handovers are
recovered or dropped, these handovers can be recovered to the source cell and may not result
in dropped calls. The dropped call analysis looks at high losses during handover. Therefore,
investigate and high dropped call problems first.
It is possible to have poor handover success rate without dropping calls, as the failed handovers
can return to the original cell. These problems are less critical than call setup and dropped
call problems. However, it is important to fix Poor Handover Success Problems to improve
the quality of calls.
For further information, refer to the Interband Handover detector, which monitors outgoing
handovers depending on the frequency band of the target cell, and also the Low Incoming
Handover detector.
CELL::INTRA_CELL_HO[INTRA_CELL_HO_SUC] * 100%
--------------------------------------------------------
CELL::INTRA_CELL_HO[INTRA_CELL_HO_ATMPT_FR_FR + INTRA_CELL_HO_ATMPT_HR_HR
+ INTRA_CELL_HO_ATMPT_HR_FR + INTRA_CELL_HO_ATMPT_FR_HR +
INTRA_CELL_HO_ATMPT_SD_TO_SD]
68P02900W36-P 3-73
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
(Successful handovers)
-------------------------------
(Handover Attempts)
Problem detectors
There are six detectors for handover, one for each problem. Each of the handover categories
has two detectors, one detector using Daily Roll-up and one using Sample Roll-up.
The detectors use the above formulae for intra-cell, inter-cell, and inter-BSS handovers.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Further analysis of Intra-Cell, Intra-BSS, and Inter-BSS Handover success rate problems
can be carried out using the fault-finding steps in the Problem Investigation View section of
the NHA Online Help.
3-74 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Problem auto-clearing
• The Very Low Handover success is cleared using the default Very Fast problem clearance
mechanism.
For further information on problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
Currently, there are no corrective actions and additional information for these problems.
68P02900W36-P 3-75
1900.2AS May 2008
Low outgoing Inter-RAT handover success rate Chapter 3: Problem guide
Description
This detector monitors the inter Radio Access Technology (that is, 2G to 3G) handover success
rate in all cells. Once a 2G to 3G handover has been determined by the handover algorithms,
the subsequent handover stages can be summarized as follows:
1. The BSS sends a Handover Required message (with 3G candidate identified) to the MSC.
The NUM_HO_TO_3G_ATTEMPTS statistic is pegged by the BSS.
2. The BSS receives a Handover Command from the MSC once the RNC has allocated a
resource. The NUM_HO_TO_3G_RES_ALLOC_SUCC statistic is pegged by the BSS.
3. The BSS (RRSM) sends an Inter System To UTRAN Handover Command message to the MS
to perform the handover to 3G. The T3121 timer is started when this message is sent. If
there is no reply before the timer expires, then the NUM_T3121_EXPIRY statistic is pegged.
4. The BSS receives a Clear Command message from the MSC once the MS has accepted the
handover. The NUM_HO_TO_3G_SUCCESS statistic is pegged by the BSS.
This detector measures the inter-RAT handover success rate in going from stage 2 to 4.
This measures the percentage of outgoing inter-RAT (2G to 3G) handovers that were successful.
From BSS 1800 onwards, the NHA uses the following formula:
NUM_HO_TO_3G_SUCCESS * 100%
----------------------------------------------
NUM_HO_TO_3G_RES_ALLOC_SUCC
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
3-76 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
Problem causes
Cause CF
Low outgoing Inter-RAT handover success issue High
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily type
problem clearing mechanism.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
68P02900W36-P 3-77
1900.2AS May 2008
Handover reason problems Chapter 3: Problem guide
3-78 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High handover rate
Description
The NHA detects abnormal conditions in a cell by monitoring the causes of handovers in the
cell, excluding power budget causes.
For information on power budget handovers, refer to Low handover rate - power budget
in this chapter.
NOTE
These detectors are disabled by default in the NHA.
OUT_HO_CAUSE_ATMPT[UPQUAL] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[UPLEVEL] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[DOWNQUAL] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
68P02900W36-P 3-79
1900.2AS May 2008
Formulae for detecting this problem Chapter 3: Problem guide
OUT_HO_CAUSE_ATMPT[DOWNLEVEL] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[DISTANCE] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[UPINTERF] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[DOWNINTERF] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[CONGESTION] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[ADJ_CHAN_INTF] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
3-80 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors
OUT_HO_CAUSE_ATMPT[BAND_RE_ASSIGN] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
OUT_HO_CAUSE_ATMPT[BAND_HANDOVER] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Examine the handover statistics, either in the OMC Performance Management tool or in the
Statistics History presented by the Network Health Analyst. The OUT_HO_CAUSE_ATMPT statistic
contains a count of the handover attempts from the cell and a number of bins, each of which
contains the number of handovers triggered by a different reason.
In a normal macrocell, most of the handovers should be triggered by power budget. This means
that calls are being handed over to neighboring cells because they can get a better quality of
service from the neighboring cell, not because of any problems with the performance on the
source cell. In contrast, handovers triggered for example by quality, level, or interference are
indications of poor performance in the source cell; calls are being handed over to neighboring
cells because the source cell is providing poor quality.
However, the percentage of power budget handovers is usually lower on microcells than
on macrocells. Ideally, in an area that is fully covered by a continuous set of microcells, the
handovers between the microcells are triggered by power budget. Handovers triggered by level
and quality are used to return to the macrocell layer when necessary, for example, at the edge of
the area covered by the microcells or in locations with bad coverage. In the case of a single
hot-spot microcell, there may be many imperative handovers that are not triggered by power
budget because there are no neighboring microcells.
In a network with frequency hopping, there may be a higher than usual percentage of handovers
triggered by uplink and downlink quality without necessarily indicating bad performance. The
NHA thresholds for the various Handover Attempt Rates can be modified to find the cells that
are significantly different to other cells for further investigation.
The bins of the OUT_HO_CAUSE_ATMPT statistic are described below. These statistics can be
viewed in the Statistics History window of the Network Health Analyst.
68P02900W36-P 3-81
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
UPQUAL is the number of times an outgoing inter-cell handover is attempted due to the uplink
signal quality in the source cell.
UPLEVEL is the number of times an outgoing inter-cell handover is attempted due to the
uplink signal level in the source cell.
DOWNQUAL is the number of times an outgoing inter-cell handover is attempted due to the
downlink signal quality in the source cell.
DISTANCE is the number of times an outgoing inter-cell handover is attempted due to the
distance of the mobile from the base site.
UPINTERF is the number of times an intra-cell handover is attempted due to uplink signal
interference in the source cell.
Problem auto-clearing
The High Second Assignment Rate problem is automatically cleared from the Problem window
using the default Daily problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-82 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Low handover rate - power budget
Description
This problem detects abnormal conditions in a cell by monitoring the number of handovers
that are triggered by power budget. In a normal macrocell, most of the handovers should be
triggered by power budget. This means that calls are being handed over to neighboring cells
because they can get a better quality of service from the neighboring cell, not because of any
problems with the performance on the source cell.
The percentage of power budget handovers is usually lower on microcells than on macrocells.
Ideally, in an area that is fully covered by a continuous set of microcells, the handovers between
the microcells are triggered by power budget. But handovers triggered by level and quality
are used to return to the macrocell layer when necessary, for example, at the edge of the area
covered by the microcells, or in locations with bad coverage. In the case of a single hot-spot
microcell there may be many imperative handovers that are not triggered by power budget,
because there are no neighboring microcells.
In a network with frequency hopping there may be a higher than usual percentage of
handovers triggered by uplink quality and downlink quality without necessarily indicating bad
performance. The NHA thresholds for the various Handover Attempt Rates can be modified to
find the cells that are significantly different to other cells for further investigation.
That is:
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
68P02900W36-P 3-83
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Examine the handover causes statistics, OUT_HO_CAUSE_ATMPTS, for the cell to investigate what
is triggering the handovers from the cell.
Problem auto-clearing
• The Very Low Handover Rate problem is automatically cleared from the Problem window
using the default Very Fast problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-84 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Carrier problems
Carrier problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P 3-85
1900.2AS May 2008
High bit error rate Chapter 3: Problem guide
Description
This detector finds RF carriers where the Bit Error Rate (that is, the downlink quality) is bad
enough that it is likely to affect voice quality.
The High Bit Error Rate problem is reported, at most, once for each cell even if several carriers
have high Bit Error Rate. The value of the problem is the highest percentage of BER reports in
the bad bins for any carrier in the cell.
The Bit Error Rate (BER) statistic is a normal distribution type statistic. Values are stored
every statistics interval for the maximum, minimum and mean BER per timeslot. Values are
also stored for the number of BER reports in each bin, that is, bin 0 for RxQual 0, bin 1 for
RxQual 1, and so on.
The BER statistic is reported using values 0 to 7 that are derived from the downlink RXQUAL
values:
The NHA sums up the values of the BER bin statistic for every timeslot on a carrier, for all
of the previous day, generating a distribution of BER for each carrier. It then calculates the
percentage of BER values that are in the bad bins where the value is bad enough that it is
likely to affect voice quality:
• If the carrier is hopping, bins 0 to 5 are good and bins 6 and 7 are bad.
• If the carrier is not hopping, bins 0 to 4 are good and bins 5 to 7 are bad.
This is because a hopping carrier can tolerate higher BER without affecting voice quality.
If the percentage of BER with bad values is above the configurable threshold value, the NHA
reports a High Bit Error Rate problem.
3-86 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Threshold values
Threshold values
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
NOTE
The high BER detector uses a default minimum sample size of one which reports any
bad carriers even if it has very low traffic. As bad BER could be the reason for low
traffic on the carrier, a low sample size is used. Very quiet carriers are ignored.
If required, reconfigure the sample size using the Thresholds-Open Thresholds
option on the Configure menu. Refer to Modifying detectors and thresholds on
page 2-133 for further information about reconfiguring sample sizes.
Problem causes
Cause CF
Frequency Planning Issue Medium
General RF Issue Medium
General RF or Coverage Issue Medium
Problem auto-clearing
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window. This shows the
numbers of measurement reports with good and bad BER for each carrier in the cell.
The problem's Event history can be viewed from the Problem window. Viewing statistics
history and event history on page 2-41 details statistic values for this problem per interval
up to the last 24 intervals. It also describes the formula and values used to detect the problem.
It can be used to view the ber bin values for each carrier.
68P02900W36-P 3-87
1900.2AS May 2008
High frame erasure rate Chapter 3: Problem guide
Description
The Frame Erasure rate is the proportion of uplink frames (after decoding, de-interleaving, and
error correction) that are discarded because of errors. This detector monitors uplink quality per
carrier and complements the High Bit Error rate detector which monitors the downlink quality
per carrier. Frame Erasure rate is a better measure of the impact on voice quality than Bit Error
rate because many of the bit errors can be recovered by error correction.
This formula calculates the percentage of uplink frames, per carrier, that are discarded because
they cannot be decoded.
3-88 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors
The FER_GSM_HR statistic is pegged per carrier and pegs for GSM half rate calls. For GSR8
loads and below, the FER bins represent the number of erased frames in a SACCH period (24
frames for full/half rate calls. For example, Bin 6 represents six frames lost in the set of 24). For
GSR9 and above, the FER bins represent the number of erased frames in a SACCH multiframes
period. The number of SACCH multiframes is determined by the bss::fer_meas_period
parameter (24*bss::fer_meas_period frames for full or half rate calls. For example, with
bss::fer_meas_period of 2, Bin 6 represents 6 frames lost in a set of 48).
The calculation gets the total number of frames lost for the whole carrier for a day, as a
percentage of the total number of frames. The total number of frames is the sum of the bin
values multiplied by the number of frames in each measurement period.
Problem detectors
The High Frame Erasure Rate problem is reported at most once for each cell, even if several
carriers have high Frame Erasure Rate. The value of the problem is the highest Frame Erasure
Rate for any carrier in the cell.
The NHA calculates a daily summary value of Frame Erasure Rate for every carrier and reports
a problem if the Frame Erasure Rate exceeds a configurable threshold value.
The configurable minimum sample size can be used to make the NHA ignore carriers with very
little traffic. The default configuration is to report every carrier with high Frame Erasure
Rate, regardless of how busy the carrier is, because the quality problems may be the reason
that the carrier has very little traffic.
Threshold values
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
68P02900W36-P 3-89
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
The NHA default cause for this problem gives a breakdown of the Frame Erasure Rate for
every carrier in the problem cell.
NOTE
Configuring the bss level parameter fer_meas_period (FER measuring period) to
a value other than its default value of 0, should be done according to the actual
network conditions.
For example, under good network conditions, a low fer_meas_period does not yield
any significant information on frame errors because the number of erroneous frames
per measuring period is insufficient. Increase the value of fer_meas_period to
increase its sampling interval to gain better insight into the distribution of erroneous
frames. Conversely, if there are too many High Frame Erasure Rate problems
raised in the NHA, decrease the value fer_meas_period to monitor the carriers with
exceptionally high frame erasure rate. By default, the ratio between the good frames
and the bad frames within a measuring period should be 100:1 (that is, 1% of bad
frames out of the total number of frames in the measuring period).
3-90 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Path balance problem
Description
This daily detector examines the statistics for one day at a time. A problem is reported if
the path balance is outside the range in the majority of statistics intervals. The value for
path_balance is zero when there is no traffic on a carrier.
Path Balance cause analysis has been present in the NHA for a number of releases, however in
this release it is separated into its own detector because it has been found that Path Balance
issues can exist in a cell without unduly affecting the cell's call processing.
NOTE
The NHA ignores statistics intervals where the traffic on a carrier is very low (under
five minutes per carrier) or where the path_balance_mean was zero or where the
path balance statistic is not available.
The NHA only reports this problem once per cell, even if multiple carriers have bad path balance.
Threshold values
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
68P02900W36-P 3-91
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Problem causes
For further information about problem causes, refer to Dropped call rate on page 3-14.
Problem auto-clearing
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
3-92 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High RF losses imbalance on odd or even timeslots
Description
This detector works out the percentage of RF losses on the odd and even timeslots for each
carrier and reports a problem if there is a significant imbalance between them.
This detector is useful because the cell may not necessarily show a dropped call problem. For
example, if the dropped call detector threshold has not been reached or the cell is not busy
enough to require all the timeslots on all the carriers.
IF
((Rate of TCH RF loss on even timeslots > threshold) or
(Rate of TCH RF loss on odd timeslots > threshold)) and
Total TCH RF losses > Min Threshold then
Report High RF Losses On Odd Even Timeslots against the Cell
Problem detectors
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily type
problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-93
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-94 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High interference on idle rate
Description
This detector monitors the Interference on Idle (IOI) rate per carrier. The IOI statistic indicates
the amount of the interference on a channel by recording the measurements of the received
signal strength, taken when the channel is idle.
• Hardware issues, where the IOI never went very low but the levels varied significantly
during the day.
• External interference issues, where the IOI is always high but does not ever vary
significantly during the day.
NHA has some tests for IOI which are used in detectors like Dropped Calls and Call Setup. But,
unless the problem is poor enough to be raised by NHA, the IOI cause is not flagged. For
example, in a case where the IOI is flat (continually high), the carrier is not picked to carry calls,
unless the other carriers are full.
IF
(Minimum Average IOI < Minimum Threshold) AND (Maximum Average IOI >
Maximum Threshold)
Raise the problem High IOI Rate - Interference problem
ELSE IF
(Minimum Average IOI >= Minimum Threshold)
IF (the difference between the minimum and maximum average IOI is >
a thresholded amount) then
Raise the problem High IOI Rate - Hardware problem
ELSE
Raise the problem High IOI Rate - Interference problem
END
Problem detectors
This problem is detected using the Daily Roll-up detection mechanism. Two types of IOI rate
problems are raised:
• High IOI Rate - Interference
68P02900W36-P 3-95
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
This detector can be used to find the following hardware or interference-related problems:
• Interference issues (where the IOI rate is very low but has high peaks during the day).
• Hardware issues (where the IOI rate is never very low but the levels vary significantly
during the day).
• External interference issues (where the IOI rate is always high but never varies
significantly during the day).
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily type
problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on page
2-32 in Chapter 2 Using the NHA. This displays information about the causes of theproblem
and the recommended corrective action. The Line of Reasoning shows the analysis that has
been done by the NHA. Detector information can also be viewed from the Problem Information
window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-96 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High BER imbalance on odd or even timeslots
Description
The High BER Imbalance on Odd or Even Timeslots detector looks at the bit error rate (BER) per
carrier and raises a problem if there is a significant difference in the levels of BER on the odd
and even timeslots. The bit error rate value corresponds to the RXQUAL downlink measurement
reports and is measured for active channels only.
IF
((berrf_even_per > thres_evenodd) or (berrf_odd_per > thres_evenodd)) and
berrf_total > thres_min_berrf then
Report High-BER-Imbalance-On-Odd-Even-Timeslots against the Cell
Problem detectors
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
68P02900W36-P 3-97
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily type
problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-98 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High RF Losses Out of Proportion to Trafc Carried
Description
This detector monitors the percentage of RF Losses and Traffic Carried for each carrier in a
cell and raises a problem if there is significant RF Losses out of proportion to Traffic Carried in
a carrier.
The RF_LOSSES_TCH statistic is pegged per timeslot and records the number of calls that
were terminated because of RF problems (calls lost while using a TCH). The BER statistic is
pegged per timeslot and records the number of measurement reports for active channels.
It represents Traffic Carried in the carrier.
This detector is useful because the cell may not necessarily show a Dropped Call problem. For
example, if the dropped call detector threshold has not been reached or the cell is not busy
enough to require all the timeslots on all the carriers.
The NHA uses the following formula to detect this problem for each carrier (X).
NOTE
A value of 0 is used if the RF_LOSSES_TCH_HR_AMR[0..7] statistic is not available.
RF_LOSSES_RTF{X} =
sum(RF_LOSSES_TCH0) + sum(RF_LOSSES_TCH1) + sum(RF_LOSSES_TCH2)
+ sum(RF_LOSSES_TCH3) + sum(RF_LOSSES_TCH4) +
sum(RF_LOSSES_TCH5) + sum(RF_LOSSES_TCH6) + sum(RF_LOSSES_TCH7)
TRAF_CARR_RTF{X} =
sum(BER_BIN0_TCH0) + sum(BER_BIN0_TCH1) + ... + sum(BER_BIN0_TCH7) +
sum(BER_BIN1_TCH0) + sum(BER_BIN1_TCH1) + ... + sum(BER_BIN1_TCH7) + ...
sum(BER_BIN7_TCH0) + sum(BER_BIN7_TCH1) + ... + sum(BER_BIN7_TCH7)
The following formula is used to detect this problem for each cell.
RF_LOSSES_TOTAL =
Cell::RF_LOSSES_TCH_ROLL + Cell::RF_LOSSES_TCH_HR_AMR_ROLL
NOTE
A value of 0 is used if the RF_LOSSES_TCH_HR_AMR_ROLL statistic is not available.
68P02900W36-P 3-99
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
RF_LOSSES_TOTAL = Cell::RF_LOSSES_TCH_ROLL
Let TRAF_CARR_TOTAL = sum of TRAF_CARR_RTF{X} across all the carriers
Check if the total RF_LOSSES_TCH for the Cell is significant:
IF RF_LOSSES_TOTAL < 150
THEN ignore this Cell
Calculate the RF_LOSSES_TCH & BER percentage for each carrier as follows:
Let A{X} = (RF_LOSSES_RTF{X}/RF_LOSSES_TOTAL) * 100%
Let B{X} = (TRAF_CARR_RTF{X}/TRAF_CARR_TOTAL) * 100%
IF any carrier {X} in this Cell has had
sufficient traffic AND (A{X} - B{X}) > Threshold
THEN report anomaly High RF Losses Out of Proportion to Traffic
Carried against the Cell
This test ensures that problem is raised against a carrier with reasonable amount of traffic. It
prevents the NHA from raising a problem against a quiet carrier, that is, where the traffic is so
small that the RF Losses statistic is not reliable.
NOTE
The value 625 is derived using 5 minutes of traffic per carrier per interval (5 * 60 *
1000/480msecs). The BER statistic is pegged every 480msecs.
Problem detectors
The NHA detects this problem using the Daily Roll-up detection mechanism. For further
information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Cause CF
RF Losses Out of Proportion to Traffic High
Carried
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily type
problem clearing mechanism.
3-100 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional information
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
The Problem Information window provides detailed information about the problem, the causes
of theproblem, and the recommended corrective action. The NHA Line of Reasoning shows
the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window. This describes
the formula and values used to detect the problem. Statistics history details statistic values
for this problem per interval up to the last 24 intervals. It also describes the formula and
values used to detect the problem.
68P02900W36-P 3-101
1900.2AS May 2008
GPRS problems Chapter 3: Problem guide
GPRS problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
This section deals provides information about the following GPRS problems:
• GPRS Requests but no Data
3-102 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst GPRS requests but no data
Description
The NHA reports cells where requests for GPRS service are being received but no GPRS data is
transferred. The intention is to find broken cells where GPRS is not working.
The NHA detector for No GPRS Activity in Cell also tries to find broken GPRS cells. The
difference is that the No GPRS Activity in Cell detector finds any GPRS cell where there is
no data transfer. However, it can only look at cells and times where GPRS activity is expected
and the condition can continue for a period of time before it is reported as a problem to avoid
having many false alarms. The GPRS Requests but no Data detector looks at all GPRS cells
all the time and reports a problem quickly if there are many requests for GPRS activity but
no GPRS data is being transferred.
The GPRS Requests but no Data detector is similar to the NHA detector for Channel
Requests but no Calls. That detector covers mobiles accessing the cell to make
circuit-switched calls whereas the GPRS Requests but no Data detector covers mobiles
accessing the cell for GPRS.
This problem can be reported erroneously if most of the GPRS accesses in the cell use Single
Block Packet Access. However, this is unlikely to occur. Single Block Packet Access allows
mobiles to access the network to send control messages (such as measurement reports, packet
pause, and packet cell change failure). The mobile sends a GPRS Packet Channel Request to the
BSS but no Packet Resource Request. This could cause this detector to report a false alarm.
On the NHA UI, the Value field for this problem type reports the number of
GPRS_ACCESS_PER_RACHs for the detection period.
This NHA detector finds cells that have received a large number of Packet Channel Request
messages from mobiles but no GPRS data has been transferred in the cell.
For BSS versions 1760 and 1800, the NHA uses the following formula:
GPRS_ACCESS_PER_RACH
+ CHANNEL_REQS_REC[1-Phase Access on PCCCH]
+ CHANNEL_REQS_REC[Single-block access on PCCCH]
+ CHANNEL_REQS_REC[EGPRS 1-Phase on PCCCH]
+ CHANNEL_REQS_REC[EGPRS Single Block Allocation on PCCCH] >
Threshold
AND DL_RADIO_BLKS_1_TS + DL_RADIO_BLKS_2_TS
+ DL_RADIO_BLKS_3_TS + DL_RADIO_BLKS_4_TS = 0
AND UL_RADIO_BLKS_GMSK_1_TS + UL_RADIO_BLKS_GMSK_2_TS
+ UL_RADIO_BLKS_8PSK_1_TS + UL_RADIO_BLKS_8PSK_2_TS = 0
68P02900W36-P 3-103
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
For BSS version 1900, the NHA uses the following formula:
GPRS_ACCESS_PER_RACH
+ CHANNEL_REQS_REC[1-Phase Access on PCCCH]
+ CHANNEL_REQS_REC[Single-block access on PCCCH]
+ CHANNEL_REQS_REC[EGPRS 1-Phase on PCCCH]
+ CHANNEL_REQS_REC[EGPRS Single Block Allocation on PCCCH]
AND DL_RADIO_BLKS_1_TS + DL_RADIO_BLKS_2_TS
+ DL_RADIO_BLKS_3_TS + DL_RADIO_BLKS_4_TS = 0
AND UL_RADIO_BLKS_GMSK_1_TS + UL_RADIO_BLKS_GMSK_2_TS
+ UL_RADIO_BLKS_GMSK_3_TS + UL_RADIO_BLKS_GMSK_4_TS
+ UL_RADIO_BLKS_8PSK_1_TS + UL_RADIO_BLKS_8PSK_2_TS
+ UL_RADIO_BLKS_8PSK_3_TS + UL_RADIO_BLKS_8PSK_4_TS = 0
NOTE
This detector is only active when the NHA is reading GPRS statistics for the OMC
being monitored. See NHA configuration files (ea.cfg) on page 4-45 for
information on configuring the NHA to read GPRS statistics.
Problem detectors
This problem is reported against the cell if the anomaly has been reported for a configurable
number of statistics intervals in a row.
Problem causes
As yet, there is no detailed cause analysis for GPRS problems. The NHA reports the following
cause for this problem:
The NHA has reported this problem because this cell has been receiving GPRS requests from
mobiles (Packet Channel Request messages) but the statistics show that no GPRS data was
transferred in the cell. Refer to Formula for detecting this problem on page 3-103.
Problem auto-clearing
This problem is cleared using the default Immediate problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
3-104 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional information
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-105
1900.2AS May 2008
High GPRS utilization by allocation Chapter 3: Problem guide
Description
The NHA monitors the utilization of GPRS resources per cell, where GPRS traffic is high
compared with the GPRS capacity of the cell. This detector is used to monitor utilization per
cell in both Uplink and Downlink directions.
This detector may not be as relevant as the High GPRS utilization by Traffic (Uplink/Downlink)
detector since PDCH can be allocated to an MS but may not be used much. Additionally, the
High GPRS utilization by Allocation detector may be impacted by the Super Coat-tail feature or
by other features that allow timeslots to be allocated to more than one mobile at the same time.
NOTE
The two detectors can be used together to view the overall GPRS utilization on the
cell. For this reason, the High GPRS utilization by Allocation detector is Disabled by
default, in favor of the High GPRS utilization by Traffic detector.
UL_BUSY_PDTCH_MEAN
----------------------------------------------------- * 100%
GPRS_AVAILABLE_PDTCH_MEAN + EGPRS_AVAILABLE_PDTCH_MEAN
DL_BUSY_PDTCH_MEAN
------------------------------------------------------- * 100%
GPRS_AVAILABLE_PDTCH_MEAN + EGPRS_ AVAILABLE_PDTCH_MEAN
Problem detectors
This detector monitors both the Uplink and Downlink. It examines at each statistics interval
(one interval at a time) looking for utilization above a threshold of 40%.
3-106 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
Both of the problems use the Fixed Threshold detection mechanism. The problems raised are:
• High GPRS utilization by Allocation on the Uplink
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
As yet, there is no detailed cause analysis for GPRS problems. The NHA reports the following
cause for both the Uplink and Downlink problems:
The cell is showing a high rate of GPRS traffic in comparison to the GPRS capacity of the cell.
The NHA has reported a problem in the cell because the GPRS capacity is not sufficient to
support the level of GPRS resources being allocated (BUSY_PDTCH) on the cell.
Problem auto-clearing
Both problems are cleared using the default End Of Next Working Day problem clearance
mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-107
1900.2AS May 2008
No GPRS activity in cell Chapter 3: Problem guide
Description
The NHA reports cells where no GPRS data has been transferred for a period of time. The
intention is to find broken cells where GPRS is not working.
The NHA detector for GPRS requests but no data on page 3-103 also tries to find broken
GPRS cells. Refer to the description of that detector for a comparison between the two
detectors. Briefly, the GPRS Requests but no Data detector looks for a subset of problems where
the cell is receiving a reasonably high number of requests for GPRS service but no data is being
transferred. However, it does not detect every case where GPRS access is not working in a
cell. For example, a cell does not receive any GPRS service requests, or is receiving too few
for that detector to work.
It is normal for some GPRS cells to carry very little GPRS data, and there may be quiet periods
of every day or week when any cell carries little or no GPRS data. So this detector needs to
trade off reporting a problem reasonably quickly against reporting false alarms at times. This is
achieved by making the detection parameters configurable. Each network can define a set of
important/busy GPRS cells and configure the NHA to monitor them closely and report a problem
quickly if they carry no GPRS data at a time when they would normally be busy.
The NHA also has a detector for GPRS Out of Service (OOS) on page 3-114 in a cell that
works more quickly and reliably than this detector, but it only finds problems where the BSS
detects that the GPRS is out-of-service, not cases where the BSS assumes that the GPRS is in
service but some problem is preventing mobiles from sending or receiving GPRS data in the cell.
This NHA detector finds cells where no GPRS data has been transferred for a configurable
length of time during configurable days and times of each week.
For BSS versions 1760 and 1800, the NHA uses the following formula:
(DL_RADIO_BLKS_1_TS + DL_RADIO_BLKS_2_TS
+ DL_RADIO_BLKS_3_TS + DL_RADIO_BLKS_4_TS) <= Threshold
AND ( (UL_RADIO_BLKS_GMSK_1_TS + UL_RADIO_BLKS_GMSK_2_TS
+ UL_RADIO_BLKS_8PSK_1_TS + UL_RADIO_BLKS_8PSK_2_TS) <=
Threshold)
For BSS version 1900, the NHA uses the following formula:
(DL_RADIO_BLKS_1_TS + DL_RADIO_BLKS_2_TS
+ DL_RADIO_BLKS_3_TS + DL_RADIO_BLKS_4_TS) <= Threshold
AND ( (UL_RADIO_BLKS_GMSK_1_TS + UL_RADIO_BLKS_GMSK_2_TS +
UL_RADIO_BLKS_GMSK_3_TS + UL_RADIO_BLKS_GMSK_4_TS
+ UL_RADIO_BLKS_8PSK_1_TS + UL_RADIO_BLKS_8PSK_2_TS +
UL_RADIO_BLKS_8PSK_3_TS + UL_RADIO_BLKS_8PSK_4_TS) <= Threshold )
3-108 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors
NOTE
This detector is only active when the NHA is reading GPRS statistics for the OMC
being monitored. See NHA configuration files (ea.cfg) on page 4-45 for
information on configuring the NHA to read GPRS statistics.
Problem detectors
The NHA performs confirmation checks to exclude cases where the cell was OOS during the
interval, or if GPRS was OOS during the interval. The NHA does not report this problem in
either of these cases because it is seen as a false alarm
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
NOTE
By default, this detector is subject to the "time of day" Monitoring Schedule. For
further information, refer to NHA Monitoring Schedule on page 4-55.
Problem causes
As yet, there is no detailed cause analysis for GPRS problems. The NHA reports the following
cause for this problem:
No GPRS Activity
The NHA has reported this problem because the AIR_DL_DATA_BLKS and AIR_UL_DATA_BLKS
statistics show that this cell has carried no GPRS data in recent statistics intervals.
Problem auto-clearing
This problem is cleared using the default Immediate problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-109
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
3-110 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High GPRS timeslot congestion
Description
The High GPRS utilization by Allocation detector helps the operator to measure the percentage
of used GPRS cell bandwidth against the maximum possible GPRS cell bandwidth.
For data transfer, Motorola’s GPRS system allows a maximum of four mobiles to share one
PDTCH timeslot and a maximum of two mobiles to share one PBCCH/PCCCH timeslot.
Therefore, the maximum available GPRS cell bandwidth of a given cell is calculated as the sum
of (GPRS PDTCH timeslots * 4 + total PBCCH/PCCCH timeslots for data transfer * 2). So the
GPRS Congestion rate (or percentage of GPRS timeslots in use) is defined as:
The NHA uses the congestion rate statistic GPRS_CELL_CONGESTION to indicate the level of
GPRS timeslot utilization on the cell. Typically, under normal conditions, the level of congestion
should be < 25%, higher congestion rates indicate the possibility of blocking (that is, the system
has a lesser chance of establishing new TBFs).
68P02900W36-P 3-111
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
The calculation of this formula depends on the threshold setting for the detection period. Two
thresholds are compared: x, the percentage congestion, and y, the value of the statistic bin.
The raw statistic GPRS_CELL_CONGESTION has 16 bins that correspond to a range of GPRS
congestion values as in Table 3-23:
Table 3-23 GPRS congestion values
The values in these bins are the number of times in a 6-second interval that congestion fell
within the corresponding range. For example, if the threshold x is set to 85%, then bins 13,
14 and 15 are of interest as these bins correspond to congestion >= 85%. Therefore, in this
instance, the value of GPRS_CONGESTION is the sum of bins 13, 14 and 15.
The value of GPRS_CONGESTION is then compared to the y threshold, which is the number
of times that the congestion has been >x during the statistics interval. By default, the value
of y is 10 which corresponds to 60 seconds (as the GPRS_CELL_CONGESTION statistic is
pegged every 6 seconds).
Problem detectors
This detector attempts to find those cells where the sharing of GPRS timeslots is excessive and
the GPRS resources are being pushed to the limit. This problem is detected using the Interval
Roll-up detection mechanism.
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
3-112 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
Problem causes
Cause CF
RTF Outage Very High
Out of Service Timeslot Very High
Reduced GPRS Capacity High
Lack of PDTCH High
GPRS Congestion without TCH Congestion Medium
GPRS Congestion with TCH Congestion Medium
GPRS Congestion Relief Disabled Low
Network Assisted Cell Change feature Disabled Low
PRP Overload Medium
High GPRS Timeslot Congestion
Problem auto-clearing
This problem is cleared using the default End of Next Working Day problem clearance
mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
68P02900W36-P 3-113
1900.2AS May 2008
GPRS Out of Service (OOS) Chapter 3: Problem guide
Description
The NHA detects and diagnoses when GPRS capability is lost in a cell that is configured for
GPRS. The NHA raises a problem if GPRS is out-of-service in the cell, site, or BSS. See the
following section on Problem detection for more details about how the NHA detects GPRS
OOS in each of these devices.
Problem detection
This problem is detected using the statistics from the most recent interval only. It detects from
statistics that GPRS has been OOS in a cell for a whole statistics interval.
Detection
Anomaly conrmation
IF the cell was in service for 10% or more of the statistics interval THEN
BEGIN
IF GPRS was OOS in 50% or more of the GPRS enabled cells in the BSS
THEN report a problem "GPRS OOS in BSS" against the BSS
ELSE IF GPRS was OOS in all the GPRS enabled cells in the Site
THEN report a problem "GPRS OOS in SITE against the SITE
ELSE report a problem "GPRS OOS in Cell" against the cell
3-114 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors
GPRS OOS
NOTE
The threshold (0) value above is configurable.
Problem detectors
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
Problem auto-clearing
This problem is cleared using the default Immediate problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-115
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
3-116 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High GPRS utilization by Trafc (uplink/downlink)
Description
The High GPRS utilization by Traffic (Uplink/Downlink) detector monitors the utilization of
GPRS resources per cell to detect where the GPRS data transfer is high compared with the
GPRS capacity of the cell. The detector is used to monitor utilization per cell on both the Uplink
and Downlink PDTCH to find cells where GPRS capacity is overloaded.
In Motorola statistics, there is no way to distinguish the root cause of retransmissions from
RLC/MAC window stall (Stalled blocks) and retransmission due to explicit NACKs from the
PCU (NACKed blocks). Therefore, a new statistic UL_RLC_NACK_BLKS is included in the
formula in GSR9 BSS.
The NHA also provides the High GPRS utilization by Allocation detector for monitoring timeslot
utilization based on channel assignment time. This detector is not as relevant as the High
GPRS utilization by Traffic (Uplink/Downlink) detector since PDCH can be allocated to an MS
but may not be used much. Additionally, the High GPRS utilization by Allocation detector can
be impacted by the Super Coat-tail feature or by other features that allow timeslots to be
allocated to more than one mobile at the same time.
NOTE
The two detectors can be used together to view the overall GPRS utilization on the
cell. The High GPRS utilization by Allocation detector is disabled in favor of the
High GPRS utilization by Traffic detector.
68P02900W36-P 3-117
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
For BSS versions 1760 and 1800, the NHA uses the following formula:
For BSS version 1900, the NHA uses the following formula:
For BSS versions 1760 and 1800, the NHA uses the following formula:
For BSS version 1900, the NHA uses the following formula:
Problem detectors
The High GPRS utilization by Traffic detector monitors both the Uplink and Downlink. It
examines at each statistics interval (one interval at a time) looking for a data load rate above
a configurable threshold of 20%.
This detector uses the Fixed Threshold detection mechanism. This enables the operator to
change the number of consecutive intervals (repeat count) over which the anomaly must be
raised before it is flagged as a problem. The default value is equal to one interval.
3-118 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
The NHA reports the following causes for both Uplink and Downlink problems (refer to
Table 3-25 and Table 3-26):
Table 3-25 Problem causes - high GPRS utilization by trafc (uplink)
Cause CF
RTF Outage Very High
Out of Service Timeslot Very High
Reduced GPRS Capacity High
Lack of PDTCH High
GPRS Congestion without TCH Congestion Medium
GPRS Congestion with TCH Congestion Medium
GPRS Congestion Relief Disabled Low
Network Assisted Cell Change feature Disabled Low
High Percentage RLC/MAC Overhead Blocks High
High Uplink CS1 Usage Medium
PRP overload Medium
High GPRS utilization by traffic High
68P02900W36-P 3-119
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Cause CF
RTF Outage Very High
Out of Service Timeslot Very High
Reduced GPRS Capacity High
Lack of PDTCH High
GPRS Congestion without TCH Congestion Medium
GPRS Congestion with TCH Congestion Medium
GPRS Congestion Relief Disabled Low
Network Assisted Cell Change feature Disabled Low
High Percentage RLC/MAC Overhead Blocks High
Significant Retransmitted Blocks High
Significant DDTR Blocks High
High Downlink CS1 Usage for Long Duration TBFs Medium
Forced Usage of CS1 Downlink Medium
High Downlink CS1 Usage Medium
PRP overload Medium
High GPRS utilization by traffic High
Problem auto-clearing
Both problems are cleared using the Default End Of Next Working Day problem clearing
mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
3-120 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High PRP load
Description
This detector monitors the Packet Resource Processor (PRP) load (that is, the number of active
TBFs awaiting data transfer) for each PRP DPROC at the PCU. It gives the user an indication of
the level of demand for GPRS resources on the PCU and can indicate the need for increased
resources.
A PRP can originate up to 120 GPRS calls (TBFs). However, the PRP can only process data
transfer for 30 TBFs every 20 milliseconds. During this time, the remaining 90 TBFs are
deemed busy, pending service for data transfer. The PRP_LOAD statistic measures the load
on the PRP board while this activity is going on. A degradation in data rates occurs if all 30
timeslots are loaded with data.
In GSR9, with the introduction of new DPROC hardware (U-DPROC2), a DPROC can be
configured to either PRP, PICP or PXP (PRP and PICP functionality on the same board). A
PXP DPROC can originate up to 280 GPRS calls (TBFs). However, similar to PRP DPROC, a
PXP DPROC can only process data transfer for 70 TBFs every 20 ms, a further 210 TBFs are
queued for data transfer service.
The mechanism described above is only applicable for PCU with rolling blackout enabled.
In GSR9, a PCU attribute is added to disable the rolling blackout mechanism on the PCU by
reducing the fan-out of the PRP/PXP, so that the throughput is increased to the same as the
fan-out.
Problem detectors
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
68P02900W36-P 3-121
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
Cause CF
High PRP Load High
Problem auto-clearing
This problem is cleared using the default End of Next Working Day problem clearance
mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can also be viewed from the Problem window.
3-122 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Uplink TBF Setup Success Rate
Description
This detector monitors the percentage of uplink TBF setups where data transfer is started
successfully, that is, the BSS receives uplink data from the mobile. When a GPRS mobile wants
to transfer data to the network, it must first request and then be assigned some uplink TBF
resources. This is called uplink TBF setup and the procedure is outlined as follows:
1. The mobile requests a TBF resource from the BSS, pegging the statistic
CHANNEL_REQS_REC.
2. The BSS grants the mobile a resource to enable it to transfer data, pegging the statistic
CHANNEL_REQS_SUCCESS.
3. The BSS receives uplink data from the mobile, pegging the statistic UL_PDTCH_SEIZURE.
This detector monitors the overall TBF seizure rate, that is, it compares the number of TBF
requests for resources (Step 1) with the number of TBFs that are actually used to send data
(Step 3).
NOTE
UL_PDTCH_SEIZURE pegging does not mirror that of the CHANNEL_REQS_REC
statistic. It does not peg for Single Block Access on the CCCH or PCCCH. The
CHANNEL_REQS_REC statistic becomes a counter-array and pegs the Single Block
bins. These are subtracted from the total CHANNEL_REQS_REC stat in the formulae.
For BSS version 1760 and 1800, the NHA uses the following formula:
UL_PDTCH_SEIZURE
---------------------------------------------------------------- * 100%
CHANNEL_REQS_REC - CHANNEL_REQS_REC[Single Block Access on CCCH] -
CHANNEL_REQS_REC[Single Block Access on PCCCH] - CHANNEL_REQS_REC[EGPRS
Single Block Allocation on CCCH] - CHANNEL_REQS_REC[EGPRS Single Block
Allocation on PCCCH]
68P02900W36-P 3-123
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
NOTE
A value of 0 is used if either CHANNEL_REQS_REC[EGPRS Single Block Allocation
on CCCH] or CHANNEL_REQS_REC[EGPRS Single Block Allocation on PCCCH] is
not available.
For BSS version 1900, the NHA uses the following formula:
UL_PDTCH_SEIZURE
---------------------------------------------------------- * 100%
NOTE
A value of 0 is used if either CHANNEL_REQS_REC[EGPRS Single Block Allocation
on CCCH] or CHANNEL_REQS_REC[EGPRS Single Block Allocation on PCCCH] is
not available.
Problem detectors
Two detectors use this formula. These detectors raise two problems as follows
• Low Daily Uplink TBF Setup Success Rate
3-124 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes
Problem causes
Cause CF
Low Uplink TBF Assignment Success Rate:
- RSL Bandwidth Limitation at PCU High
- Roundtrip Delay Timeout at PCU High
- Insufficient Resources at PCU High
- RSL Bandwidth Limitation at BTS High
- No Reserved Blocks Available at BTS High
- AGCH Discards at BTS High
- PCU Software Issue High
- Low Uplink TBF Assignment Success Rate High
Low Uplink TBF Success to Seizure Rate:
- TBF Failures at TBF Establishment High
- Low Uplink TBF Success to Seizure Rate High
GPRS Congestion:
- RTF Outage V High
- Out of Service Timeslot V High
- Reduced GPRS Capacity High
- Lack of PDTCH High
- GPRS Congestion without TCH Congestion Medium
- GPRS Congestion with TCH Congestion Medium
- GPRS Congestion Relief Disabled Low
- Network Assisted Cell Change feature Disabled Low
PRP Overload Medium
Low Uplink TBF Setup Success Rate High
Problem auto-clearing
• The Very Low Uplink TBF Setup Success Rate problem is cleared using the default Very
Fast problem clearing mechanism.
For further information on problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-125
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
The Problem Information window provides detailed information about the problem, the causes
of theproblem, and the recommended corrective action. The NHA Line of Reasoning shows
the analysis that has been done by the Detector information can also be viewed from the
Problem Information window. This describes the formula and values used to detect the problem.
Statistics history details statistic values for this problem per interval up to the last 24 intervals.
It also describes the formula and values used to detect the problem.
3-126 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Reduced GPRS capacity
Description
This detector detects and diagnoses when the GPRS capacity of a cell is less than it is configured
to be.
With Adaptive Multi Rate (AMR), the BUSY_TCH_MAX statistic counts the maximum number of
full-rate calls. The statistic BUSY_TCH_HR_AMR_MAX counts the maximum number of half-rate
calls. As a result, it could take a longer time to detect this problem.
In the formula above, the Maximum number of available GPRS timeslots is set by the
following statistics:
GPRS_AVAILABLE_PDTCH_MAX + EGPRS_AVAILABLE_PDTCH_MAX
In the formula above, the "Number of GPRS timeslots configured in the Cell" is set by the
following:
68P02900W36-P 3-127
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide
NOTE
The maximum number of available GPRS timeslots for a given interval cannot be
measured precisely. It cannot be greater than the sum of the number of "regular"
GPRS timeslots and the number of EGPRS timeslots. In practice, this is not expected
to have an impact. In theory, it could mean that the maximum number of GPRS
timeslots is overestimated, resulting in the detector failing to fire when it should.
Problem detectors
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
Cause CF
Reduced GPRS capacity in cell High
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Immediate
type problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-128 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High downlink block error rate
Description
This is a useful indicator of poor RF conditions on the cell. The High Downlink Block Error Rate
detector monitors the rate of NACKed RLC BLKS (retransmitted blocks) to all blocks sent
during an interval or detection period. The Block Error rate is used to identify cells of poor RF
quality. Poor radio conditions result in low throughput rates as the MS is forced to transfer data
at a lower coding scheme.
DL_RLC_NACK_BLKS * 100
------------------------------------------------------------------------
DL_RLC_ACK_NEW_BLKS + DL_RLC_NACK_BLKS
Problem detectors
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Cause CF
High downlink block error rate High
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Daily type
problem clearing mechanism.
68P02900W36-P 3-129
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-130 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High DPROC utilization
Description
The High DPROC utilization detector reports on DPROC processors at the PCU where the CPU
utilization is very high. Do not overload the DPROCs. Overloading affects the quality of GPRS
service in the BSS and degrades the performance of the PCU. In 1760 and 1800 BSSs, each
BSC can manage up to three PCUs, adding increased GPRS capacity and providing redundancy
when a PCU is no longer able to process GPRS data. However, these features have been
removed from BSS 1900. From BSS 1900 onwards, each BSC can only manage one PCU and
no redundancy is allowed.
Problem detectors
This detector checks all the DPROCs at every statistics interval and reports any where the mean
CPU utilization exceeds a threshold value. The DPROCs are all at the PCU “site”.
For information on the default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
Cause CF
High DPROC utilization High
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default End of Next
Working Day type problem clearing mechanism.
68P02900W36-P 3-131
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-132 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Infrastructure problems
Infrastructure problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P 3-133
1900.2AS May 2008
Device not in the MIB Chapter 3: Problem guide
Description
This problem identifies when the NHA receives statistics from devices which are not in the OMC
CM MIB database. This issue occurs if BSS changes have not been audited into the OMC MIB.
The NHA alerts the operator so that it can start monitoring new cells.
NOTE
The NHA can only monitor statistics for cells that are known to the OMC. It is
important to handle these problems using the OMC audit feature to update the OMC.
Problem detectors
This problem is detected if the NHA receives cell statistics for a CELL which is not in the MIB.
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
Problem auto-clearing
• The NHA automatically clears this problem if it fails to re-occur over subsequent intervals
for this BSS.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
3-134 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional information
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-135
1900.2AS May 2008
No statistics from BSS Chapter 3: Problem guide
Description
This problem is raised when NHA has not received cell statistics for any cells contained by any
sites in a BSS for a particular cell for a specified number of intervals.
Problem detectors
This problem uses the No statistics from Cell detector. The problem is detected if the
OK_ACC_PROC_SUC_RACH statistic is not available for the complete detection period (default
interval is four hours) in all non-blacklisted cells for all sites for a BSS statistics interval (30
minutes or 60 minutes).
To stop this problem from being raised, turn off the No statistics from BSS detector for all
cell groups.
To stop this problem from being raised for a particular BSS, place all the cells in the BSS in
a group with the No statistics from Cell detector turned off.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
Cause CF
Bad statistics interval - the setting for the BSS statistics interval is incorrect. Very High
No fileNEavailable events - the OMC has not received any fileNEevents from Very High
the BSS.
Problem with file uploads - statistic values not uploaded successfully from Very High
the BSS.
Unknown problem with statistics. Very High
3-136 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Problem auto-clearing
• This problem is automatically cleared if the statistics used in the detection of this problem
are received for any device for which a problem exists or are contained by a device for
which a problem exists.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-137
1900.2AS May 2008
No statistics from Cell Chapter 3: Problem guide
Description
This problem is raised when NHA has not received cell statistics for a particular cell for a
specified number of intervals.
Problem detectors
This problem is detected if the OK_ACC_PROC_SUC_RACH statistic is not available for the complete
detection period (default interval is four hours) in a non-blacklisted Cell for a BSS statistics
interval (30 minutes or 60 minutes).
The detection mechanism further discounts any cells that were OOS for over 75 percent of
the interval threshold, or is currently OOS.
For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.
Problem causes
No statistics have been received for CELL (CELL::name) for (Interval Threshold) hours, from
(start time of detection) to (end time of detection). The cell has been in service sufficiently
long for statistics to be available. Statistics have been received from other CELLs under
(container-site) over the same period. Without statistics, NHA cannot monitor this cell.
Statistics cannot be enabled for the CELL. (In particular, the NHA looks for the
OK_ACC_PROC_SUC_RACH statistic to decide if statistics are unavailable.) Check if this is the case
using the OMC Performance Management tool. Statistics can also be enabled using this tool.
If any statistics are enabled or disabled, remember to upload the BSS database to the OMC
to make the changes permanent.
Run a statistics report for OK_ACC_PROC_SUC_RACH on the problem cell over the last few days to
see if this statistic is reaching the OMC from the BSS.
If the statistics report shows that OK_ACC_PROC_SUC_RACH is not being stored in the OMC then
either OK_ACC_PROC_SUC_RACH is disabled in the BSS or else there is a problem with the BSS or
the OMC.
Some CELL statistics are pegged by the BSC, for example, TOTAL_CALLS, and others are pegged
by the BTS, for example, OK_ACC_PROC_SUC_RACH. NHA complains about missing statistics even
if BSC-pegged statistics for the cell are available.
It is possible to check particular statistics, for example, OK_ACC_PROC_SUC_RACH at the cell to see
if they are actually being pegged normally, using remote login to the BSC and the disp_stats
command.
3-138 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
If the statistics report shows that OK_ACC_PROC_SUC_RACH is reaching the OMC, then the NHA is
not reading the statistics for this cell from the OMC. The NHA ignores the statistics from a cell
during any statistics interval when a DRI goes out-of-service. Check if the NHA is reporting a
Repeated DRI Failure problem for a DRI in this cell. If there is a DRI going out-of-service in
each statistics interval, then that is the reason the NHA is reporting this No Statistics from
CELL problem.
Problem auto-clearing
• This problem is automatically cleared if the statistics used in the detection of this problem
are received for any device for which a problem exists or are contained by a device for
which a problem exists.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-139
1900.2AS May 2008
No statistics from Site Chapter 3: Problem guide
Description
This problem is raised when NHA has not received cell statistics for any cells in a particular
site for a specified number of intervals. In this case separate problems are NOT raised for the
cells in the problem site.
Problem detectors
This problem uses the No statistics from Cell detector. The problem is detected if the
OK_ACC_PROC_SUC_RACH statistic is not available for the complete detection period (default
interval is four hours) in all non-blacklisted cells for a site for a BSS statistics interval (30
minutes or 60 minutes).
The detection mechanism further discounts any sites that were OOS for over 75 percent of
the interval threshold, or is currently OOS.
To stop this problem from being raised, turn off the No statistics from site detector for all
cell groups.
To stop this problem from being raised for a particular site, place all the cells in the site together
with the No statistics from Cell detector turned off.
For information on default threshold values for each detector refer to NHA default thresholds
on page 3-181.
Problem causes
This problem is caused when no statistics are received from this cell even though it is in service.
Refer to Table 3-33 for details.
Cause CF
Last RSL out-of-service High
No cell statistics from site Very High
3-140 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Problem auto-clearing
• If the statistics used in the detection of this problem are received for any device for which
a problem exists or are contained by a device for which a problem exists, then clear the
problem immediately.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-141
1900.2AS May 2008
Event based problems Chapter 3: Problem guide
3-142 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Database upload required
Description
The BSS database should be uploaded to the OMC after making configuration changes. If this
is not done, then, after a reset, the BSS reloads the old database from the OMC without the
most recent configuration changes.
The BSS reset takes longer than necessary because the BSS stays out-of-service while the
database is being downloaded.
Problem detectors
NHA detects events from the network element which signify that the database has been changed.
If the database is not uploaded within an hour after the last such event, the problem is raised.
Some configuration changes are ignored by NHA. CallTrace events are excluded because they do
not result in a database change. Similarly, if all changed attributes for an attributeValueChange
are on the following list: kitNumber, serialNumber, or FR_unit, they should be excluded
because they do not result in a database change. This hardware information can be accessed
directly from the hardware and is not stored in the database.
Problem causes
There is only one cause for this problem, that is, no database upload.
Cause CF
No Database Upload Very High
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Knowledge
Based problem clearing mechanism.
The NHA automatically clears problems from the Problem window following a database upload.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-143
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
3-144 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst GCLK recalibration required
Description
Currently network operators have to periodically recalibrate all the GCLKs at every site in the
network. Uncalibrated GCLKs cause frame slip errors which result in reduced quality on calls.
Fixing this problem should result in fewer alarms at the OMC. The NHA automatically identifies
the site with the problem instead of other sites, connected to the bad site, which also report
frame slip alarms.
Problem detectors
If there are eight MMS 9 alarms from a site in 9.5 hours or less, the detector fires. (None of
these settings can be configured.) Problems are raised for:
• GCLK Recalibration (Single site), or
Problem causes
The NHA recommends that GCLKs are recalibrated at one or more sites and identifies the sites.
Cause CF
Remote GCLK out of calibration Very High
Local GCLK out of calibration Very High
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Event Based
problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
68P02900W36-P 3-145
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
3-146 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Repeated cell failure
Description
• Neighboring cells can be affected also if, for example, a neighbor is congested, since
handovers into the problem cell are not possible.
Problem detectors
The detector for this problem looks for cells changing state (from busy unlocked to disabled
unlocked) four or more times in under 24 hours.
Problem causes
The NHA does not give a cause, it just alerts the operator that the cell has a problem and gives
the times of the first and last OOS events.
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Event Based
problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-147
1900.2AS May 2008
Repeated DRI failure Chapter 3: Problem guide
Description
This problem identifies DRIs which fail repeatedly. This occurs when a device is taken
out-of-service (Busy to Disabled) by the fault management system as opposed to either being
locked by an operator or having a function removed from it.
A DRI which frequently follows the cycle of Busy -> Disabled -> Busy affects one carrier
within a CELL.
Problem detectors
This problem is detected when there are four state changed events (from Busy unlocked to
Disabled unlocked) for a given DRI, in less than 48 hours.
Problem causes
The NHA raises a cause, which provides all the alarms for state changed events raised by the
DRI during the detection period.
Cause CF
DRI repeated failure Very High
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Event Based
problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
3-148 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional information
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-149
1900.2AS May 2008
Repeated DRI-61-62-63 alarms Chapter 3: Problem guide
Description
This problem monitors these low severity warning alarms which can be blacklisted or not
subscribed to.
The repetition of DRI 61, 62, or 63 alarms indicates a potential problem with the fiber optic links
between the DRIX and RCU. If the frequency of alarms exceeds the threshold, the DRIs can reset.
A secondary impact is that the event logs fill up unnecessarily at the OMC.
Problem detectors
OR
• More than eight alarms of any one number from the same DRI occurring in a 24-hour
period.
Problem causes
The NHA suggests possible causes which include faulty DRIX, faulty optical fiber, faulty RCU,
or incorrect DRIX jumper settings.
Cause CF
Faulty DRIX/Optic Fiber High
Incorrect DRIX Jumper Settings Low
Incorrect Optical Fiber Length Low
Faulty DRIX/Incompatible DRIX Low
Faulty RCU Low
3-150 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing
Problem auto-clearing
This problem is automatically cleared from the Problem window using the default Event Based
problem clearing mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window.
68P02900W36-P 3-151
1900.2AS May 2008
Script based problems Chapter 3: Problem guide
This section provides information about the following script based problems:
• Device out-of-service (OOS and Locked)
• BSS-level detectors
• Consolidated problems
3-152 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Device out of service (OOS and Locked)
Description
This external-script based detector reports problems if any device from the list below is
out-of-service (OOS). Currently, the NHA INSM user interface monitors the BSS, Sites, Cell,
DRIs, and RTFs. The Device OOS detector expands this monitoring function to other devices.
However, instead of reporting on the INSM, the outages are reported as problems on the
Problem Window.
Each Device OOS problem is reported once per interval per Site, that is, if more than one device
from the same class is OOS in an interval, the NHA lists them in the detector information for the
first device reported OOS for that Site. The Value field of the problem shows how many devices
of the problematic class under the problem device are OOS.
Devices monitored
The NHA Device OOS scripts monitors the following devices: BSP, BSS, BTP, CBL, CELL, COMB,
CSFP, DHP, DRI, GBL*, GCLK, GDS*, GPROC, GSL*, KSW, MMS, MTL, PATH, PCU*, RSL, RTF,
SITE, XBL, RXCDR*.
NOTE
Devices marked with an asterisk (*) above are reported per BSS. The RXCDR is
reported against the SITE 0 for the RXCDR.
NOTE
The MSI/MMS related devices behave the same as SITE/CELL,PATH, RSL related
devices. No problem is raised for an OOS MMS if the parent MSI is OOS.
• The NHA provides a detector script (a perl script using the DBI mechanism) which uses
each device class listed above and reports a problem on the Problem Window.
68P02900W36-P 3-153
1900.2AS May 2008
Problem detection Chapter 3: Problem guide
• When the script is run for the first time, all OOS (but not locked) devices are classed as
dummy devices and no problems are raised for them. A device has to have been INS
before it can raise an OOS problem.
The OOS state definitions are configurable per device class. Refer to the information
in Configuring Device OOS scripts in this section.
If the Site is OOS, a problem is not reported for any of its related RSLs, Cells, PATHs.
• The NHA reports a different type of problem for Locked devices as the device may be
under service by an operator. Locked devices cannot be dummy devices. Locked devices
are not reported for a configurable time period (the default is two hours). Refer to the
information in Configuring Device OOS scripts below.
• If the device class is not known to the NHA then a problem is raised against the BSS. This
problem lists all the out-of-service devices for that class.
• The Device OOS detector is aware of the NHA blacklist. It can take up to half an hour
before it is aware of blacklisted devices.
NOTE
As the scripts are run once every interval, it can take up to a statistics interval
after the device has gone OOS before the problem is raised in Problem window.
It can also take a statistics interval after the problem is raised before is cleared.
Problem detection
3-154 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring Device OOS scripts
NOTE
Some devices do not have an Unlocked/Locked state (for example, RTFs), so the
NHA checks for the equivalent. For example, if an RTF is not Busy/Equipped, it is
considered to be OOS. Locked problems cannot be raised against these devices.
Dummy devices
To avoid reporting problems against dummy devices, the NHA considers all devices to be
out-of-service until they come into service. Only then does the NHA begin to monitor a device.
So when the OOS device detector is initialized, there can be a lag time before OOS devices are
caught, for example, a device that is OOS when the scripts are turned on is not reported until
it comes INS, and then goes OOS.
When the OOS device detector is initialized, all devices states are monitored. Those devices
that are NOT INS or locked are noted as dummy devices. A problem cannot be raised for a
dummy device. A device needs to be INS before it can be reported as OOS. A device that
is OOS when the scripts are turned on is a dummy device until it comes INS. No problem
is reported until it then goes OOS.
To run the external scripts, the NHA calls start_scripts every interval which in turn call
up any script beginning with S or D (as the first characters in their filename) found in the
/usr/gsm/current/knowledge/external_problems directory.
For the Device OOS detector, the file S_driver_oos.sh contains a list of devices
to run which, in turn, call up the main M_device_oos.sh file. This executes two
perl files, one of which queries the OMC and returns the results as text files in the
/usr/gsm/OMC<omcname>/external_problems directory on the NHA. These text files
are then operated on by deviceOOS.pl which raises, at most, two separate problems
(Unlocked/Locked) per device on an appropriate device basis. The reports of these problems are
sent to the output directory of the specific OMC.
68P02900W36-P 3-155
1900.2AS May 2008
Conguring Device OOS scripts Chapter 3: Problem guide
• deviceOOS.pl - the main Perl script which runs the detection algorithm. Edit this file to
reconfigure the time period after which a Locked device is reported (the variable and
default setting in seconds is $time2hourstosecsGC = 7200). Also, edit this file to change
the automatic problem clearing time, that is the number of intervals after which the Device
OOS problems are cleared (the variable and default setting is $CLEAR_AFTER = 1).
• Querydevicestatus.pl - the file which queries the CMMIB database for device states.
• lockfile.pl - creates a lockfile called .lockedfile.txt to ensure that only one iteration
of the script runs every interval.
Created les
NOTE
Errors are logged to the eaAudit file.
3-156 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring Device OOS scripts
The Device OOS detector is run by default once the NHA is started.
To turn off this feature, replace the first character of S_driver_oos.sh with any character
other than S, s, or D, d.
To turn off the detector for a specific device, edit the S_driver_oos.sh file and delete the
device from the for loop containing the list of devices to be monitored.
Note if restarting the Device OOS detector, delete all memory files on the NHA side. These
files are hidden, so use ls -la on /usr/gsm/OMCs/<omcspecific>/external_problems/oos-
device-data directory to view them.
The administrator (omcadmin) can add devices to the dummy device list by editing the
appropriate dummy device file manually and adding the DN (OMC-R MIB database Device
Number) of the device as follows:
1. Type the commands:
cd /usr/gsm/OMCs/<omcname>/external_problems/
vi nha[devicetype]-dummy-original.txt
2. Add a line similar to the following with the DN in the first column:
100/0,31/40,30/0,12/0
The administrator (omcadmin) can set up the NHA to recalculate the dummy devices of a
particular device type by removing the file named .memorylog[devicetype].txt (a hidden file)
in the oos-device-data directory as follows:
cd /usr/gsm/OMCs/<omcname>/external_problems/
oos-device-data/ (all one line)
ls -al
rm .memorylog[devicetype].txt
A new set of dummy devices for that device is then created at the next statistics interval.
The administrator can set up the NHA to recalculate all dummy devices of all device types by
removing all files named .memorylog[devicetype].txt (hidden files) in the oos-device-data
directory as follows:
cd /usr/gsm/OMCs/<omcname>/external_problems/
oos-device-data/ (all one line)
ls -al
rm .memorylog*.txt
A new set of dummy devices for all devices is then created at the next statistics interval.
68P02900W36-P 3-157
1900.2AS May 2008
Problem causes Chapter 3: Problem guide
Problem causes
Problem auto-clearing
Problems are cleared using a timeout value of one statistics interval. To change this value,
edit the deviceOOS.pl file. Refer to the information in Configuring Device OOS scripts
- Permanent files above.
Additional information
The Event history is useful for this problem and can be viewed from the Problem window.
3-158 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Long term detection
Description
Long term detectors can show statistical trends over a long period, as well as recent changes in
performance compared with the average. They are used to find cases where performance is
degrading over a number of days or weeks without the impact being severe enough to trigger an
existing short-term or daily NHA detector.
The main difference between this and other NHA detection mechanisms is that there is no
absolute threshold defined. Instead, the current performance is compared to what is expected
for a particular cell based on past data. Two methods are used:
• Comparing the most recent values with the average for the previous n days
• Regression analysis, which attempts to fit a straight line through the data and determine if
the values are increasing or decreasing over time.
The first method should detect sudden changes in performance while the second would be
expected to detect more gradual changes.
Long term detectors are implemented using external scripts. The long-term statistical data used
by the detectors is generated by a script which calculates daily key statistics and stores them
for up to 60 days. By default, these scripts do not generate NHA problems but produce reports
which can be accessed from the NHA web server.
Problem detection
The scripts which detect these problems are located in the directory /usr/gsm/cur-
rent/ea_tools/lgStats on the NHA server and are named:
• D_increased_CallVolume.pl
• D_increased_DroppedCallRate.pl
• D_reduced_CallVolume.pl
• D_reduced_CallSetupSuccessRate.pl
68P02900W36-P 3-159
1900.2AS May 2008
Detection mechanism Chapter 3: Problem guide
Note by default these scripts do not report problems on the NHA. To enable the scripts to report
problems the scripts must be edited and the value of the configurable CREATE_PROBLEMS
changed from 0 to 1. It is recommended to review the daily HTML reports through the NHA
web page before enabling problem reporting on the NHA.
NOTE
For information about configuring the NHA long term statistics feature and how to
fill the graphs with data from MARS or another long term statistics gathering tool,
refer to Configuring NHA for long term statistics viewing and monitoring
on page 4-79.
Detection mechanism
Long term detectors work by calculating the mean value of a particular key statistic over a
configurable number of days (DETECTION_PERIOD). The mean value is then compared with the
values for a number of days prior to today (REPEATDAYS). If the values of the key statistics are
greater or lower than the mean by more than a threshold value (THRESHOLD), and the cell
carries traffic that is more than LOW_TRAFFIC_THRESHOLD, for each of these consecutive
days, then a problem is raised.
Let TF = mean Traffic Carried for the DETECTION_PERIOD days previous to today
IF TF of this CELL <= LOW_TRAFFIC_THRESHOLD
THEN Ignore this CELL
Let C = mean Call Setup Success Rate for the DETECTION_PERIOD days previous
to today.
Let S = standard deviation of the mean C.
IF S > MAX_STDDEV AND detector is configured to ignore highly variable data
THEN ignore this CELL;
ELSE IF CSSR < ( C - THRESHOLD ) for at least the last REPEATDAYS consecutive
days (not including the detection period)
THEN
Add the cell to the daily HTML report file
Raise a problem Reduced Daily Call Setup Success Rate directly.
3-160 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Detection mechanism
REPEATDAYS = 1
THRESHOLD = 3%
DETECTION_PERIOD = 14
MAX_STDDEV = 4
LOW_TRAFFIC_THRESHOLD = 1
Let TF = mean Traffic Carried for the DETECTION_PERIOD days previous to today
IF TF of this CELL <= LOW_TRAFFIC_THRESHOLD
THEN Ignore this CELL
Let D = mean Dropped Call Rate for the DETECTION_PERIOD days previous to today.
ELSE IF dropped call rate > ( D + (D * THRESHOLD )) for at least the last
REPEATDAYS consecutive days (not including the detection period)
THEN
REPEATDAYS = 1
THRESHOLD = 1.8
DETECTION_PERIOD = 14
MAX_STDDEV = 0.5
LOW_TRAFFIC_THRESHOLD = 1
Call Volume
Let TF = mean Traffic Carried for the DETECTION_PERIOD days previous to today
IF TF of this CELL <= LOW_TRAFFIC_THRESHOLD
68P02900W36-P 3-161
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide
IF Call Volume < (CV - (CV * THRESHOLD)) for at least the last REPEATDAYS
consecutive days (not including the detection period)
THEN
ELSE IF Call Volume > (CV + (CV * 2.0)) or at least the last REPEATDAYS
consecutive days (not including the detection period)
THEN
REPEATDAYS = 1
THRESHOLD = 0.5
DETECTION_PERIOD = 14
LOW_TRAFFIC_THRESHOLD = 1
Problem auto-clearing
The long term detectors all use the default Daily problem clearance mechanism.
For further information about problem clearance mechanisms, refer to NHA problem clearing
mechanisms on page 1-21.
Problem causes
No automatic analysis is performed by the NHA. Use the NHA Long Term Statistics viewer to
view the statistics for the cell over the detection period to determine if this problem shows a
significant reduction in performance.
The configurable parameters for these detectors can only be changed by editing the scripts in
the directory /usr/gsm/current/ea_tools/lgStats. Make a backup copy before editing any
script. The values which can be changed are listed in the Configurables section in each script.
The beginning of this section is denoted by the following heading:
3-162 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring long term detectors
$CONFIGURABLE = value;
The following variables can be modified to alter the behavior of the long term detectors:
• IGNOREWEEKENDS
The values are:
1 (default) - statistical data for weekends is ignored.
0 - statistical data for weekends is included.
• WEEKEND
Specifies the days of the week on which weekends occur. Days are represented by
numbers from 0 to 6 (0 = Sunday, 1 = Monday, and so on). By default, the
weekend is Saturday and Sunday (0 and 6).
• IGNORESTDDEV
Set IGNORESTDDEV to1 to discard data for which the standard deviation around the mean
is too high. This is set to 0 by default. The intention is to exclude data which is too variable
to show a meaningful change in performance.
• MAX_STDDEV
The maximum value of standard deviation allowed before data is discarded. This value
is used only if IGNORESTDDEV is set to 1.
• DETECTION_PERIOD
The number of days of statistics over which the mean is calculated. Set to 14 by default.
• REPEAT_DAYS
The number of consecutive days over which the statistics must be worse
before we raise a problem. Set to 1 by default.
• THRESHOLD
The percentage change in the recent statistics value compared to the mean
which triggers a problem to be reported.
• CREATE_PROBLEMS
Set to 1 to enable reporting of problems on the NHA UI for a long term script. This is
set to 0 by default.
• LOW_TRAFFIC_THRESHOLD
The threshold value for the low traffic. This is set to 1 by default.
To disable an individual long term detection script, rename the script so that its name does
not begin with D.
68P02900W36-P 3-163
1900.2AS May 2008
BSS-level detectors Chapter 3: Problem guide
BSS-level detectors
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Description
This external-script based detector provides a mechanism for detecting problems at BSS
level. It is intended to capture cases where performance is degraded over a whole BSS and
not just a single cell. These issues are more serious in terms of network performance so, by
raising them as problems at BSS level, they are more visible to operators and given priority
over problems affecting single cells.
3-164 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae used to detect this problem
NOTE
The formulae do not take account of out-of-service or blacklisted cells. If a cell
has reported statistics for the interval, these values are included in the BSS-level
formulae.
68P02900W36-P 3-165
1900.2AS May 2008
Formulae used to detect this problem Chapter 3: Problem guide
3-166 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae used to detect this problem
68P02900W36-P 3-167
1900.2AS May 2008
Formulae used to detect this problem Chapter 3: Problem guide
The BSS Drop Call Rate is calculated using the following formulae:
CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_FAIL]
+ CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]
CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_ATMPT]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_SUC]
- CELL::OUT_INTER_BSS_HO[OUT_INTE R_BSS_HO_RETURN]
- CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]
MA_COMPLETE_FROM_MS
----------------------------------- * 100%
MA_CMD_TO_MS
NOTE
Use a value of 0 if the RF_LOSSES_TCH_HR_AMR statistic is not available.
RF_LOSSES_TCH * 100%
-----------------------------------------------------------------------
TOTAL_CALLS + ASSIGNMENT_REDIRECTION[DIRECTED_RETRY]
+ ASSIGNMENT_REDIRECTION[DURING_ASSIGNMENT] +
ASSIGNMENT_REDIRECTION[MULTIBAND_BAND] + IN_INTER_BSS_HO[IN_INTER_BSS_HO_SUC]
3-168 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae used to detect this problem
NOTE
Intra-BSS handovers are not included in the denominator for BSS TCH RF Loss
Rate. This is to prevent calls which have originated within the BSS and pegged by
TOTAL_CALLS from being counted twice.
For OMC release 1800.56 or later, TCH Blocking Rate is calculated using the following formulae:
For 1760 BSS releases after 1760.2b-t3, the following formula is used:
For 1800 BSS releases after BSS 1800, the following formula is used:
68P02900W36-P 3-169
1900.2AS May 2008
Formulae used to detect this problem Chapter 3: Problem guide
For OMC releases prior to 1800.56, TCH Blocking Rate is calculated using the following
formulae:
ALLOC_TCH_FAIL - TCH_Q_REMOVED[ASSIGNMENT_RESOURCE_REQ]
- TCH_Q_REMOVED[HO_REQ] - TCH_PREEMPT_NO_Q_ALLOC
---------------------------------------------------------------------- x 100 %
ALLOC_TCH + ALLOC_TCH_FAIL - TCH_Q_REMOVED[ASSIGNMENT_RESOURCE_REQ] -
TCH_Q_REMOVED[HO_REQ] - TCH_PREEMPT_NO_Q_ALLOC
The following statistics are substituted by PMGUI names when implemented (refer to
Table 3-38).
Table 3-38 Statistics substituted by PMGUI names when implemented
3-170 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors
Problem detectors
These problems are detected using the Fixed Threshold detection mechanism.
For further information on default threshold values for each detector, refer to NHA default
thresholds on page 3-181.
Problem causes
Problem auto-clearing
The problem clearing time for all problems raised by these detectors is one hour.
68P02900W36-P 3-171
1900.2AS May 2008
Additional information Chapter 3: Problem guide
Additional information
For detailed information about the problem, refer to Problem Information window on
page 2-32. This displays information about the causes of theproblem and the recommended
corrective action. The Line of Reasoning shows the analysis that has been done by the NHA.
Detector information can also be viewed from the Problem Information window.
The problem's Event history can be viewed from the Problem window. The Statistics History
details statistic values for this problem per interval up to the last 24 intervals. It also describes
the formula and values used to detect the problem. Refer to Viewing statistics history and
event history on page 2-41.
3-172 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Consolidated problems
Consolidated problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Description
Many of the problems in the NHA are sympathetic, or have common root causes. This means
that a single network issue (such as interference) could have several NHA problems raised as
a result (for example, RF issues resulting in high BER, high drop call rate and low handover
success rate). These issues can now be consolidated into a single NHA problem so that users
can identify more easily the most important problems raised by the NHA.
Problem detection
Problem consolidation is run as an external interface script every interval. This detector does
not use conventional NHA detection mechanisms as it is not attempting to detect new network
issues.
• A list of all cells and their neighbor cells from the MIB in the following format:
A list of all problems (ALL-PROBLEMS) raised for the current interval is built from the current
eaProblems file. This list excludes the following problem types:
• No Statistics from [BSS | Site | Cell]
• GPRS problems
68P02900W36-P 3-173
1900.2AS May 2008
Formulae for detecting this problem Chapter 3: Problem guide
These problems are raised independently of other problem types as GPRS problems are
stored in a separate file. A GPRS problem can be raised against a cell even if another
consolidated problem has been raised on the cell. Note GPRS problems are consolidated
exclusively from non-GPRS based problems.
NOTE
Once a problem has been consolidated, it is not considered again for further
consolidation.
This NHA detector raises problems in the order listed below. The following formulae are used:
Broken Cell
3-174 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae for detecting this problem
Hardware issues
68P02900W36-P 3-175
1900.2AS May 2008
Formulae for detecting this problem Chapter 3: Problem guide
Handover issues
3-176 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem conrmation
Problem conrmation
One problem is raised against each device. The values displayed for each problem are listed
in Table 3-39.
Table 3-39 Consolidated problems - value displayed per problem type
Problem causes
Problem clearing
Broken Cell, BSS-level, OOS-related, GPRS-related problems always use the short clearing
time. Capacity-related problems always use the long clearing time. Hardware-related,
frequency-related, handover, coverage, and GCLK problems use the long clearing time if the
problem is raised during the first interval of the day; otherwise, the short clearing time is used.
Additional information
If the detector is running during the first interval for the day, a list of all problems on the
device for the previous day is displayed. Otherwise, a list of all problems on the device for
the current interval is displayed.
68P02900W36-P 3-177
1900.2AS May 2008
Additional information Chapter 3: Problem guide
For BSS issues, problems of the current type on cells under the BSS are listed. For GPRS issues,
only GPRS problems on the cell are listed. For handover issues, only the outgoing handover
problems on the cell are listed.
For hardware, frequency and capacity-related problem types, all problems on neighbors of the
problem cell are listed. The information is displayed in the following format:
3-178 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Customized problems
Customized problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
The NHA user creates customized problems using the Knowledge Editor. There is no help
available on this problem as it has been created locally. Please use the User-defined causes
option to add or view information about this problem.
68P02900W36-P 3-179
1900.2AS May 2008
External interface problems Chapter 3: Problem guide
The external interface problems are detected by the NHA using user-created scripts. There
is no Help available on these problems. Please use the User-defined causes option to view or
add information about this problem.
For further information, refer to External interfaces to detect problems on page 2-180.
3-180 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA default thresholds
The NHA is shipped with default threshold values for detectors. These default threshold values
can be changed using the Thresholds option on the Configure menu. There are also four
example threshold files shipped with the NHA, found at the following path:
/usr/gsm/current/ea_tools/mot_thresholds/
The files are in .CSV format, suitable for importing into the NHA. These files provide useful
starting thresholds for a variety of GSM networks of varying quality. The threshold files are
specific to each NHA release as each release contains different detectors.
Threshold les
The following are the example threshold files shipped with the NHA:
• T1 - Thresholds for a poor network
NOTE
The NHA default thresholds are continuously updated in response to customer
feedback and are available, through customer support, from the Motorola
web-site.
68P02900W36-P 3-181
1900.2AS May 2008
NHA automated thresholds Chapter 3: Problem guide
The Automated Thresholds feature provides a mechanism for the NHA to automatically change
its detector thresholds. Its purpose is to maintain the thresholds so that a reasonable number of
problems are presented to the user. This feature is based on scripts and has two components:
• Problem Reducer script
This script automatically changes the thresholds if a defined maximum number of problems
is exceeded. It performs a relatively crude reduction in the number of problems raised if
too many problems are currently being raised. It cannot increase the number of problems
raised.
This script fine-tunes the thresholds based on the mean and standard deviation of the
network-wide key statistics. Its purpose is to set more accurate thresholds based on the
overall network performance.
Both the Problem Reducer and Thresholds Calculator scripts are run per OMC as daily scripts. It
is possible to enable or disable these scripts on a per-OMC basis using the configurable settings
PROBLEM-REDUCER-SCRIPT-ENABLED and THRESHOLDS-CALCULATOR-SCRIPT-ENABLED
defined in the NHA configuration file (ea.cfg). It is not necessary to stop/start the NHA to pick
up changes to these configurable settings.
Both the Problem Reducer and Thresholds Calculator scripts must be executed after the
AUTO-EXPORT-THRESHOLD-TIME specified in the ea.cfg file and must complete before the
thresholds are automatically imported. New thresholds are calculated for each cell group based
on the mean and standard deviation of the detection formula calculated over all cells in the cell
group for the number of days for which statistics are available.
Note the Automated Thresholds mechanism is separate from the automatic deletion of problems.
Automatic removal of problems happens when the number of problems exceeds the maximum
allowed per OMC (800 by default) and is usually a result of poorly set thresholds. For further
information, refer to Check for "too many" problem messages on page 4-24.
NOTE
The effective use of this feature depends on the cells being allocated to the correct
cell groups. This is best achieved using the Automatic Cell Grouping feature. For
further information, refer to Automatic cell grouping on page 2-122.
3-182 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Problem Reducer script
The Problem Reducer script should first be used to quickly reduce the number of problems
raised. It must be executed and reach completion before using the thresholds calculator script.
Note the following limitations with the Problem Reducer script:
• Only statistics-based problems where the key threshold value is equivalent to the value of
the problem as reported in the eaProblems file are included.
• There must be an exact match between the detector and problem names listed in the script
configuration file and the names listed in the thresholds export file and eaProblems file.
Particular care needs to be taken with case sensitivity and problem names with trailing
spaces in the eaProblems file.
The data source for the script is the previous day's eaProblems log file. A “Problem Reducer
Configuration” file is also used to define the maximum number of problems for each problem
type in the BUSY, NORMAL, and QUIET cell groups. This is a CSV format file with the following
fields:
There is one copy of this file per OMC, contained in the OMC-specific config directory
problem-threshold.csv.
For each detector in the problem-threshold.csv file, the following parameters are defined
(refer to Table 3-40):
Table 3-40 Denitions in the problem-threshold.csv le
Name Description
Detector Name of detector. This must match the detector name in the exported
Name thresholds file.
Problem Name of the problem raised by this detector. This must match the problem
Name name as it appears in the eaProblems file.
max_problems Maximum number of problems of this type in a day.
max_busy Maximum number of problems of this type on BUSY cells in a day.
max_normal Maximum number of problems of this type on NORMAL cells in a day.
max_quiet Maximum number of problems of this type on QUIET cells in a day.
NOTE
It is recommended that these values comply with the relationship:
max_problems = max_busy + max_normal + max_quiet AND
max_busy > max_normal > max_quiet
68P02900W36-P 3-183
1900.2AS May 2008
Using the Problem Reducer script Chapter 3: Problem guide
Although the Problem Reducer Configuration file only defines maximum number of problems
for the BUSY, NORMAL, and QUIET cell groups currently, it is possible to define limits for
additional cell groups by editing the file. The script should be capable of reading the values
for the new cell groups without modification.
Algorithm
The current set of thresholds is defined in the export-thres.csv file. This file is automatically
generated each day by the NHA to/usr/gsm/OMCs<omcname>/ea_logs directory.
The thresholds in the exported file are modified and the updated values written to the
import-thres.csv file in the same directory.
NOTE
For the initial implementation, only BUSY, NORMAL, and QUIET cell groups have
their thresholds recalculated.
3-184 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Thresholds Calculator script
The new value is set so that the number of problems with a worse value is equal to the maximum
number of problems for each group.
For the Problem Reducer script and Thresholds Calculator script, the AUTO-EXPORT-
THRESHOLD-TIME is set to 0 and AUTO-IMPORT-THRESHOLD-ON is set to ON by default.
Additional information
The Thresholds Calculator script is run per OMC as a daily script and accepts the OMC
hostname as a parameter. The Problem Reducer script must be executed and reach completion
before the Thresholds Calculator script is run.
Algorithm
The Thresholds Calculator script uses the following algorithm to calculate new thresholds for
each cell group GROUP in the BUSY, NORMAL, and QUIET cell groups:
NOTE
For the initial implementation, only BUSY, NORMAL, and QUIET cell groups have
their thresholds recalculated.
68P02900W36-P 3-185
1900.2AS May 2008
Using the Thresholds Calculator script Chapter 3: Problem guide
The value of weight is dependent on the cell group. The default values are as follows:
The purpose of the weight value is to allocate thresholds that result in more problems for BUSY
cells and fewer problems for QUIET cells. Therefore, for BUSY cells the threshold is closer to
the mean value, so the weighting factor is lower while, for QUIET cells, the threshold is further
from the mean, so the weighting factor is higher.
The value of x is determined by the detector being adjusted. It is a measure of the relative
importance of that detector, where 1 = most important and 3 = least important. The result
should be that the more important detectors have more problems raised. This value is also
user-configurable in the configuration file thres-calculator-config.csv.
Whether to use + (plus) or - (minus) in the formula also depends on the detector type. For
success type detectors, - is used; for "failure" type detectors, + is used. The settings for each
detector are listed in Table 3-41.
Detector +/- x
Call Setup Success Rate - 1
Drop Call Rate + 1
SDCCH RF Loss Rate + 2
Inter BSS Handover Success Rate - 2
Intra BSS Handover Success Rate - 2
Intra Cell Handover Success Rate - 2
Incoming Handover Success Rate 2
Immediate Assignment Failure Rate + 2
Immediate Assignment Success Rate - 2
Handover Attempt Rate - Power Budget - 3
For information about adjusting thresholds, refer to the previous section Adjusting the
thresholds on page 3-184.
3-186 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Audit log information
Additional information
The suggested mechanism for obtaining the statistics is to use the CAT daily export files which
are automatically generated each day. By default, this stores statistics for up to seven days.
However, if the NHA has been recently installed (and not upgraded from a previous version),
seven days of exports do not become available until the NHA has been running for seven days.
In this case, the thresholds calculator uses the number of days of statistics that are available.
If the CAT daily exports script fails to run, so that there is no export file for the previous day, the
thresholds calculator uses the statistics that are available and writes a warning log message to
the audit log file stating that the statistics from the previous day are not available.
If no CAT daily export files are available, then the script has no data to use so it writes an error
message to the audit log and exits.
Users can disable a threshold calculator by setting the Status field of that detector to Disable.
By default, all of the threshold calculators are enabled. For example, in the following
setting the threshold calculator for the Call Setup Success detector is disabled: Call Setup
Success,1,Disable.
For automated thresholds, the audit log should contain the following information:
<Detector name>: <Cell Group>: This detector has had its threshold adjusted from <old
threshold> to <new threshold>
68P02900W36-P 3-187
May 2008 1900.2AS
Audit log information Chapter 3: Problem guide
3-188 68P02900W36-P
1900.2AS May 2008
Chapter
Administration
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P 4-1
May 2008 1900.2AS
NHA administration Chapter 4: Administration
NHA administration
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
This chapter describes the procedures for the post configuration of the NHA processor and the
GUI server or client. It also describes other administrative procedures that are performed on
the NHA; some relate to system administration, others to NHA configuration.
In this chapter
4-2 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst In this chapter
• Configuring NHA for long term statistics viewing and monitoring on page 4-79
• NHA system recovery for SunFire V440 and Netra N440 on page 4-108
68P02900W36-P 4-3
1900.2AS May 2008
Introduction to starting and stopping the NHA Chapter 4: Administration
The NHA can be started from an Xterm window. The NHA can be shut down and restarted from
the main NHA User Interface (NHA UI) or from an Xterm window.
The procedures for starting and stopping the NHA and for starting the UIs are given in the
following sections.
• Starting the NHA on page 4-5.
4-4 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Starting the NHA
To start the NHA from the command line, perform the following steps:
1. OMCONE
2. OMCTWO
[1-2,i=more info,q=quit] 1
NHA%
Checking TCP/IP port availability.
Starting NHA
Continued
68P02900W36-P 4-5
1900.2AS May 2008
Starting the NHA from the command line Chapter 4: Administration
NOTE
4-6 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Stopping and restarting the NHA
This method of stopping the NHA is recommended because it correctly saves the context and
immediately releases the licenses.
To shut down the NHA from the main NHA UI, use the following steps:
Continued
68P02900W36-P 4-7
1900.2AS May 2008
Stopping the NHA from the command line Chapter 4: Administration
Use this procedure only if the main NHA UI is not accessible because the most recent half-hour's
context can be lost and the licenses are not released immediately.
To stop the NHA from the command line, perform the following steps:
Continued
4-8 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Restarting the NHA
It is sometimes necessary to shut down and restart the NHA for the following reasons:
• To pick up changes to the NHA configuration file.
If necessary, select the restart option when shutting down the NHA. The NHA restarts
automatically within five minutes. Otherwise, restart the NHA manually (refer to the
procedure Starting the NHA on page 4-5).
The NHA attempts to restart automatically if it has been shut down by a process outside of its
control. For example, if the OMC shuts down, the NHA waits five minutes before attempting a
restart. If this fails, it attempts to restart every five minutes.
The NHA automatically shuts down when it detects that the OMC has shut down. Once the OMC
has restarted, the NHA restarts immediately. If the NHA shuts down for any reason other than
an OMC shutdown, then it restarts automatically.
After restarting:
• The NHA restores the problems that were present at shutdown to the Problem window.
• The NHA starts rereading statistics from the OMC, going back either two hours or 24
intervals (configurable).
• The NHA starts raising immediate problems according to the statistics that it has read
from the OMC.
• The NHA starts calculating Daily Rollup values from the statistics that it has read from
the OMC.
68P02900W36-P 4-9
1900.2AS May 2008
Congurable startup options Chapter 4: Administration
As a result, the NHA detection of new problems is sometimes slower than normal. In particular,
the detection of daily problems only examines the statistics for the part of the day loaded by the
NHA after the restart. Therefore, if there is a choice as to when to shut down the OMC (or NHA)
then, from an NHA perspective, the best time is earlier in the day rather than later.
It is possible to configure the NHA (on a per OMC basis) in different ways that determine how
it behaves after a startup:
The NHA can be configured to read in statistics from two hours before the restart OR to read
in 24 intervals of statistics before the restart. Choose the required option by editing the
OMC-specific configuration file /usr/gsm/OMCs/<omcname>/config/ea.cfg and modifying
the entry for 24-INTERVAL-STARTUP. A value of false selects the two-hour option, a value of
true selects the 24-interval option.
If the two-hour option is chosen, then the NHA starts detecting hourly problems more quickly.
However, the daily problems for the first day after the restart are less reliable because there are
fewer statistics available.
If the 24-interval option is chosen, then the daily problems for the first day after the restart
are more reliable. However, the NHA is slower at detecting hourly problems on the first day
because it has to read all the statistics.
By default, the NHA restores problems that were on the Problem Window after a restart. If this
action is not needed, then change the PROBLEM-AUTOSAVE-AND-RESTORE variable in the
OMC-specific configuration file from ON to OFF.
4-10 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA directory structures
This section outlines the directory structures that must exist following the NHA installation. It
describes the directories:
• On the NHA machine.
• On the OMC.
The following directories are present on the NHA machine (refer to Table 4-1):
Table 4-1 NHA directory structure
Continued
68P02900W36-P 4-11
1900.2AS May 2008
On the OMC Chapter 4: Administration
On the OMC
Refer to Table 4-2 to view the files on the OMC that are affected:
Table 4-2 Directory structure on the OMC
Directory/le Contents
system root menu options (NHA included)
/etc/dt/config/C/sys.dtwmrc
user menus with personalized NHA entries
/home/<username>/.dtwmrc
entries for trust (NHA-MMI, MMI-NHA)
/.rhosts
/etc/host.equiv
Continued
4-12 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst On GUI servers or clients
Refer to Table 4-3 to see the directories and files that are affected or present on the GUI
servers or clients:
Table 4-3 Directory structure on the GUI servers or clients
Directory/le Contents
entries for trust (NHA-MMI, MMI-NHA)
/.rhosts
/etc/host.equiv
Gensym telewindows software
/usr/opt/gensym/current
UI client software
/gen/nha/current
UI startup scripts
/usr/gsm/nhacurrent
Java engine
/gen/nha/java
Gensym Javalink software
/gen/nha/javalink
Scripting utilities
Various software utilities are available on the NHA for use by administrators. They can be useful
when writing scripts for the external interface for detection, cause analysis, or user interface
features (refer to the relevant sections in Chapter 2, Using the NHA) or for other scripts. These
utilities include:
• Perl scripting language, including database access modules, installed in
/usr/local/bin/perl.
68P02900W36-P 4-13
1900.2AS May 2008
NHA licenses Chapter 4: Administration
NHA licenses
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
This section advises the NHA administrator about the operation of the NHA licenses.
The G2 license file is an ASCII text file /opt/gensym/current/g2/g2.ok which allows the NHA
to run the Gensym G2 software on which it is based. To populate the file, manually edit the
details, as described in Updating NHA license files.
The NHA license file is an ASCII text file /usr/gsm/config/local/license_file which allows
NHA servers and clients to run. To populate the file, run the nha_populate_license script as
described in Updating NHA license files.
The design of the NHA license feature is like that of the OMC license feature. It is implemented
using the FLEXlm license manager which allows software licenses to be available anywhere on
the network instead of being confined to particular machines.
NHA licenses control the way the NHA is used by monitoring the following parameters:
• The number of NHA servers that are run simultaneously.
• The number of Traffic Channels (TCHs) on the OMCs that the NHA monitors.
Motorola allocates these licenses depending on the commercial agreements with the customer.
Allocated licenses
To check which NHA licenses are allocated to the NHA, the administrator can run the following
command:
more /usr/gsm/config/local/license_file
4-14 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Checking NHA license details
NOTE
If the license file information is believed to be incorrect, contact your Motorola
commercial representative to check what was ordered. If this information differs
from the details in the NHA license file, then contact the Motorola Cellular Network
Support Centre (CNRC) to arrange for a solution.
Use of licenses
To check what NHA licenses are currently in use and what licenses are available, the NHA
administrator can run the following command as omcadmin:
/usr/gsm/current/nha_lc_tools/lmstat -a
68P02900W36-P 4-15
1900.2AS May 2008
Updating NHA license les Chapter 4: Administration
NHA server licenses are freed for re-use when the NHA is shut down. NHA client licenses are
freed for re-use when all UIs on a particular display are closed.
Messages and warnings about licenses being allocated are logged in the NHA audit log
files ( /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit[date]) with the prefix <NHA_LC>.
Check these messages if there are suspected issues with the NHA licenses, for example:
grep NHA_LC /usr/gsm/OMCs/OMCone/ea_logs/eaAudit20010909
The NHA license file must be updated if any of the parameters monitored by the license are
changed. These parameters include:
• The number of NHA servers that are allowed to run simultaneously.
• The number of Traffic Channels (TCHs) on the OMCs that the NHA monitors.
To request an updated license, contact the Motorola Commercial representative and quote
the updates to the NHA licenses required.
When the new license details arrive from Motorola, install them as follows:
NOTE
NHA stop or start is not necessary for this operation.
4-16 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Updating NHA license les
===============================
NHA License Administration Tool
===============================
1. Invoke New License
2. Quit
Enter Option:
2 Enter 1 to invoke the new license.
3 Enter values for the following :
• The NHA OMC traffic channel limit license key, for example,
C23065041154.
4 Enter Y at the prompt if these entries are acceptable:
Are you happy with these entries (Y/n)?
To re-enter the license information, enter N at the prompt.
5 Enter N at the following prompt:
Are there more features to be licensed (y/N)?
The following output is displayed:
Copying license file to /usr/gsm/config/local/license_file
6 Enter the command:
su - omcadmin
/usr/gsm/current/nha_lc_tools/lmstat -a
Continued
68P02900W36-P 4-17
1900.2AS May 2008
Updating NHA license les Chapter 4: Administration
4-18 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA hardware requirements
The NHA is an adjunct product that runs on a variety of SUN platforms (running Solaris 9).
Platforms can be chosen depending on the size of the network to be managed.
Hardware specication
The NHA platform is a separate server from the OMC platform. When choosing NHA platforms,
consider the current size of the network to be managed and the size to which the network is
anticipated to grow. Then, configure the NHA platforms with the appropriate memory and CPUs
to give satisfactory performance.
There are two supported platforms for the NHA server. Whichever platform is chosen, configure
it with an appropriate number of CPUs and enough memory to support the number and size of
OMCs to be monitored (as defined in NHA CPU and memory requirements below).
Medium configuration - This has four 1.593 GHz CPUs and 8 GB of memory. The medium
configuration can support up to a maximum of eight OMCs with a total combined capacity
of 360K TCH, depending on the number of carriers per cell. Refer to Table 4-4 for further
information.
Large configuration - This has four 1.593 GHz CPUs and 16 GB of memory. The large
configuration can support up to a maximum of eight OMCs with a total combined capacity
of 450K TCH depending on the number of carriers per cell. Refer to Table 4-4 for further
information.
Table 4-4 Platform conguration - SUN SunFire V440 and Netra N440
For the Sunfire V440 and Netra N440, four 73 GB hard disks are required.
68P02900W36-P 4-19
1900.2AS May 2008
NHA UI client requirements on a GUI server or client Chapter 4: Administration
NOTE
The NHA UI client must be installed on an OMC-R GUI server.
The NHA UI client runs on Solaris 9 and 10. It requires a minimum configuration of 128 MB
of RAM. The NHA UI response time is dependent on the speed of the machine. A SUN Sparc
170 MHz machine is the recommended minimum specification.
If the NHA UI client is to execute together with other applications on, for example, a GUI server
machine, adequate free RAM must be available. A single instance of the NHA UI client can use
from 30 up to 45 MB of RAM when executing.
• 128 MB of RAM
The recommended operating system is Windows NT Version 4.0 Service Pack 5 OR Windows
2000 Service Pack 1 OR Windows XP Professional. The installed NHA UI client uses 60 MB of
disk space.
4-20 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA troubleshooting
NHA troubleshooting
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Use the procedures identified in this section to run regular checks on the NHA file systems
and log files. This section describes how to:
• Check NHA status and performance.
The following commands are useful for checking that the NHA is running correctly. Both
commands are run from the command line.
To check if the NHA is running for all OMCs and get a listing of all OMC-Rs being monitored,
enter:
NHA status
NHA name hostname code OMC name DIAG pid Start time
---------------------------------------------------------------
3002 ea-mid 32 3002 9122 Mon Apr 18 16:44:58
somc37 ea-mid S7 somc37 6819 Thu Apr 21 11:36:00
omc1 ea-mid O1 omc1 22196 Fri Apr 22 11:33:09
68P02900W36-P 4-21
1900.2AS May 2008
Investigate an NHA shutdown Chapter 4: Administration
To check the health of the NHA and get a listing of key health indicators of the NHA, enter:
NHA health
Using the NHA health command, operators can check the OMCs.cfg file for all OMCs configured
on the NHA processor. The results are then checked against the ea-runtime.cfg file for running
NHAs. For OMCs configured and running on the NHA, a full health check is performed including
checks on logs, processes and NFS mounts. For all other OMCs configured but not running on
the NHA, only the logs and NFS mounts are checked.
=====================================================
NHA 3002
=====================================================
OMC: 3002
Last event-based problem: 25/04/2005 10:04
Last stats-based problem: 25/04/2005 10:24
Last stats collection: 10:20:06
Last event log opened: 08:43:10
WARNING: 4 ERROR messages found in Audit log.
Check /usr/gsm/OMCs/3002/ea_logs/eaAudit20040621 for details.
0 problems forcibly removed today.
Checking NHA Processes :
DIAG running OK, process id = 9122
IPM running OK, process id = 9435
EvA running OK, process id = 9436
stats_br running OK, process id = 9345
config_br running OK, process id = 9362
event_br running OK, process id = 9348
Checking network connection to OMC ea3002...OK.
Checking NFS mounts...
/usr/gsm/OMCs/3002/mibconfig OK
/usr/gsm/OMCs/3002/ne_data OK
This report can also be viewed by selecting the NHA Health report link on the NHA web page.
If the NHA is regularly shutting down, check the audit logs for FATAL errors as follows:
cd /usr/gsm/OMCs/<omcname>/ea_logs
Shutdowns with auto-starts occur when the OMC shuts down. AFATAL message indicating that
the CM MIB connection has been disconnected signals this type of shutdown. Other reasons
for shutdowns can be identified and investigated with the local support engineer and/or the
relevant Customer Network Resolution Centre (CNRC).
4-22 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Check NHA processes and log les
There are normally eight entries for the OMC if there are no rlogin sessions open: three G2s
(DIAG, EvA, and IPM), three GSIs (EB, CB, and SB), one sh cb.start, and one for the grep.
If there are more than eight processes running, investigate with the local support engineer
and/or the relevant Customer Network Resolution Centre (CNRC).
To check if the audit log file is being written to, use the following command:
tail -f /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<yyyymmdd>
OR
nhalog <omcname>
To check the audit log files for errors, use the following command:
Investigate errors that are unexplained with the local support engineer and/or the relevant
Customer Network Resolution Centre (CNRC).
In addition, NHA administrators must ensure that file systems on the NHA are maintained
and that any large unused files are removed in a timely fashion. If /usr/gsm/ is 100% full,
the NHA cannot initialize.
NOTE
If there is no /usr/gsm partition, the /usr partition is checked.
68P02900W36-P 4-23
1900.2AS May 2008
Check event logs processes Chapter 4: Administration
To check that event log files are being read properly by the NHA, use the following command:
Entries must correspond with the OMC event log files being opened.
To check that statistics from the OMC are being processed by the NHA, use the following
command:
Entries for every hour and within the last hour are then displayed.
Performance troubleshooting
If performance issues are suspected, use the UNIX utility prstat to troubleshoot as follows:
/usr/bin/prstat
To check the audit logs for messages that indicate that too many problems are being raised,
use the following command:
If at any time there are more than the maximum number of problems per OMC (currently 800),
then the output is a list of problem types where many (more than 80) are being raised. Adjust
the thresholds for these problem types so that fewer problems are raised.
Algorithm used
The algorithm used to get down to 90% of the maximum number of problems is as follows:
If there are more than MAX-NO-OF-PROBLEMS-THRESHOLD problems on
the OMC, the NHA removes problems in this order until it reaches 90% of the
MAX-NO-OF-PROBLEMS-THRESHOLD:
1. Problems with status CLEARED.
When the NHA forces the removal of problems, a message is logged in the audit log
(/usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<date> ) advising users to modify the
thresholds for particular detectors.
4-24 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Check for "too many" problem messages
The default value of 800 provides a balance between the performance of the NHA User Interfaces
and allow users to view NHA problems. If the value of MAX-NO-OF-PROBLEMS-THRESHOLD
requires modification, then edit the NHA configuration file, ea.cfg, and stop and start the NHA
to effect the change. For further information about NHA UI client requirements, refer to the
section on NHA hardware requirements in the Install and Upgrade Guide provided with the
manual Software Release Notes: Network Health Analyst (68P02900W77).
The fewer the number of problems that match the selected region and problem subscription, the
quicker the response of the UI. Conversely, the greater the number of problems, the more data
must be transferred to the UI and the more time it takes. Furthermore, UI client machines with
limited free memory can run out of memory if users attempt to browse too many problems on
the NHA problem window at one time.
When more than 3,000 problems match the region and problem subscription, a confirmation
dialog appears prompting the user to avoid needless waiting or memory use by choosing a
more selective region or problem subscription.
Regardless of available free memory, the maximum number of problems that can be viewed on
a UI is 15000, while for machines with only 64 Mb of RAM, the enforced maximum is 2400
problems.
NOTE
UI client machines with only 64 Mb RAM can run out of memory if the operator
attempts to browse more than 2,400 problems. This issue only occurs if the total
number of problems on all NHA servers exceeds 2,400.
For example, if five NHAs were running on a single NHA server, each with the
default maximum of 600 problems, and an operator on a 64 Mb UI client selects
ALL-REGIONS and ALL-PROBLEMS, then the UI attempts to browse 3,000 (that
is, 5 x 600) problems and can run out of memory. If the operator selects more
discriminating subscriptions, such as OMC-specific subscriptions, so that fewer than
2,400 problems fit the subscription, the UI performs normally.
This advice also applies when increasing the maximum number of problems threshold
in an NHA. The maximum number of problems that any UI client can browse,
regardless of memory capacity is 15,000.
68P02900W36-P 4-25
1900.2AS May 2008
Check NHA system performance statistics Chapter 4: Administration
NHA system information is logged every 10 minutes and stored as compressed files in
/usr/gsm/ea_logs/sys_info. The following performance monitoring commands are run
automatically:
date
who
uname -a
/usr/sbin/psrinfo -v
/usr/ucb/ps -auxww
/usr/bin/df -k
/usr/gsm/current/nha_lc_tools/lmstat -a
/usr/ucb/vmstat 5 5
/usr/bin/prstat -n 40 1 1
/usr/bin/prstat -n 40 -s rss 1 1
/usr/sbin/swap -s
date
To view these performance log files, change to the system log file directory. Select the file with
the appropriate time stamp and display it, uncompressed, using commands like the following:
cd /usr/gsm/ea_logs/sys_info
zcat stat<timestamps>.Z | more
To view the latest output from the NHA web page, go to: http://[nhaname]/nhastatus.txt
The NHA has been engineered to give good response times at the user interface under heavily
loaded circumstances. The response times on any given machine on a network depend on the
number of problems being displayed and the number of user interfaces that are open.
If response times are slower than desired, some troubleshooting steps are available:
• If local UIs are responsive, but remote UIs are not, check the network latency of the link
between the UI computer and the NHA computer by executing the following command
on the UI computer:
The quicker the round-trip time, the quicker the response of the UI. The best UI
performance is achieved when the round-trip times are less than 40 ms on average.
• Reduce the number of problems being detected. If a large number of problems is being
detected (and displayed on the Problem window), it is useful to loosen the thresholds
(through the Configure - Threshold menu) so that fewer problems are detected. Refer to
Configuring the NHA on page 2-104 for further information.
4-26 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Get the best performance from the UI
• Accelerate the rate at which problems are automatically cleared. The automatic problem
clearance mechanisms are set up to clear problems that do not recur within a certain time
limit. To accelerate the rate at which problems are automatically cleared, change the
time limit to make it shorter. Refer to NHA configuration files (ea.cfg) on page 4-45
for further information.
• If the total number of problems in the selected subscription is large (> 400), select a
subscription with a small number (< 100) of problems and check to see if response is
faster. It is sometimes necessary to create a subscription with fewer problems or fewer
BSSs before trying this solution.
• Iconize other applications, including other NHA UIs, running on the computer from which
the UI was launched.
• Close any unnecessary applications, including other NHA UIs, running on the UI computer.
NOTE
To check for other UIs running on the computer, use the following command:
/bin/ps -ef | grep Launch
• Check how much memory is installed on the UI computer using the following command:
/usr/sbin/prtconf -v | grep Mem
The minimum memory configuration required is 64 MB for a UI
computer running one NHA. Additional NHA UIs can require up to 30 - 45 MB each.
• If the NHA UI is installed on another computer which has more free memory or is faster,
check whether the NHA UI runs faster on it.
• If another computer is available which has more free memory or is faster, try installing
the NHA UI on it and check if the UI response is quicker.
• The NHA UI can appear frozen on an Xterm which is low (< 7M free) on memory. To avoid
this situation, use a UNIX machine console instead of an Xterm or close the UI window (if
necessary, use the command: /usr/openwin/bin/xkill). Minimize Xterm memory usage
by closing as many other applications as possible. Restart the NHA UI.
68P02900W36-P 4-27
1900.2AS May 2008
Troubleshooting mounts Chapter 4: Administration
Troubleshooting mounts
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
If the relevant directories are not mounted from the OMCs to the NHA, use the following
procedure to check the mounts. This issue sometimes occurs in the event of an OMC software
upgrade.
To check the directory sharing from the OMC, carry out the following steps:
Continued
4-28 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Check sharing from the OMC
unshareall
shareall
If a message like the following is displayed:
share_nfs: /usr/omc/1.9.0.0.19/config:
parent-directory (/usr/omc) already shared
unshare /usr/omc
and delete the entry for:
/usr/omc from /etc/dfs/dfstab
4 On the NHA, as user root, enter the command:
automount -v
Check the /etc/vfstab file to confirm
that it contains the following directories:
/home
cd /usr/gsm/current/sbin
./nha_omcmounts.sh <omc_hostname>
Messages like the following are then displayed:
68P02900W36-P 4-29
1900.2AS May 2008
Generating a new ssh key in NHA Chapter 4: Administration
Ssh has been enabled by default in GSR9 system to replace rsh, telnet, and rlogin. Thus secure
connection is required between NHA and GSR9 OMCs. NHA provides utility to generate ssh key
in NHA and utility to set up no passphrase ssh connection with GSR9 OMC.
The following section provides steps to generate new ssh key in NHA.
Continued
4-30 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Generating a new ssh key in NHA
NOTE
Repeat for all GSR9 OMCs to which the NHA processor is
connected.
68P02900W36-P 4-31
1900.2AS May 2008
Check OMC Informix settings Chapter 4: Administration
Users can check Informix settings on the OMC after an upgrade by running the verify_informix
script located in /usr/gsm/current/sbin.
Log in as user root and run the verify_informix script. If there are no errors present, output
like the following is displayed.
#
/usr/gsm/current/sbin/verify_informix ea3002
Checking network connection to OMC ea3002...
Network connection to OMC ea3002 OK
Checking for unpassworded connection to OMC ea3002...
Unpassworded connection to OMC ea3002 OK
Checking Informix settings...
Informix mcMIB and mcOMC settings...
remote_MIB_entry : mcMIB010228113130 ontlitcp ea3002 mcMIB
local_MIB_entry : mcMIB010228113130 ontlitcp ea3002 mcMIB
remote_OMC_entry : mcOMC010228113130 ontlitcp ea3002 mcOMC
local_OMC_entry : mcOMC010228113130 ontlitcp ea3002 mcOMC
Informix mcMIB and mcOMC settings verified OK
Comparing NHA and OMC Informix port numbers...
remote_mcMIB_port : 5040/tcp
local_mcMIB_port : 5040/tcp
remote_mcOMC_port : 5030/tcp
local_mcOMC_port : 5030/tcp
Informix port numbers verified OK Informix settings verified OK
CAUTION
If errors are displayed in the NHA and OMC Informix port numbers, do not attempt to
edit these entries as any modications made affect all OMCs congured on the NHA.
Instead, report these errors to the OMC administrator.
Informix mcMIB and mcOMC settings on the NHA must match the settings on the OMC. If an
error is reported, then edit these settings in the /usr/informix/etc/sqlhosts file on the NHA
so that they match the entries on the OMC.
Run the verify_informix script again to ensure that there are no errors.
4-32 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA log les
NHA log files are stored on an OMC basis. Therefore, NHA log files are found for each OMC
in /usr/gsm/OMCs/<omcname>/ea_logs/.
The following log files are produced daily and are used in operations for analysis or for
debugging:
• Audit files
• DailyExport files
• Problem logs
• Anomaly logs
• Clearance logs
NHA log files are text files, some of which are in Comma Separated Value (.CSV) format. In
.CSV files, the top line of the file is a header that tells the user what is in each column. These
files import easily into commercial spreadsheets such as Excel.
In some country-specific versions of commercial spreadsheet programs, the comma ',' character
is used as a decimal point and is not accepted as a default separator. As a result, comma
separated value (.CSV) files are not read in correctly. This issue affects the exported problem
lists and can affect other exported files which are then imported into spreadsheets (for example,
Thresholds and Statistics History).
NOTE
The default field separator used in NHA log files is a comma (,). This comma
separator can be changed to a pipe (|), semi-colon (;) or period (.) by editing the
global configuration file. Refer to NHA configuration files (ea.cfg) on page 4-45
in this chapter for further information.
A workaround is to edit the exported file to replace the comma characters with a tab character
(or any other delimiter that the spreadsheet takes). To perform this workaround in UNIX, run
the following command before importing the file to the spreadsheet:
68P02900W36-P 4-33
1900.2AS May 2008
Audit les - eaAudit<date> Chapter 4: Administration
The Audit file is a text file containing error and information messages from NHA software. It
is used primarily for health checking and debugging issues.
The Daily Export file is a CSV file containing a snapshot of problems that were open at a
particular time (usually set to a time before the morning shift).
This file can be imported into Excel and formatted using a macro (nha_1-page-macro.xls and
nha-multi-omcs.xls are available in /usr/gsm/current/ea-tools/) for distribution to others.
For further information, refer to Exporting and printing problem reports on page 2-59.
The daily export files are in .CSV format with one line per problem as follows:
Problem,Value,Intervals,First,Last,Repeats,OMC ID,BSS,Site,Cell/Device,
Group,Status,Severity,Comment,Causes,
The Problem log file is a Comma Separated Value (.CSV) file containing every instance of every
problem raised by the NHA. It can be useful for an analysis of what the NHA is finding.
When analyzing the problem log file, using the standard UNIX commands grep and vi, it is
difficult to read the file properly as corrective actions can be too long. This problem arises
because the longest line that vi can handle is 4100 characters and grep 4000 characters.
The solution is to edit the problem log file to limit the number of characters per line to 1000.
For example:
The cut file can then be edited using vi and searched in using grep. The problem log files are in
.CSV format with one line per problem instance as follows:
The Anomaly log file is a Comma Separated Value (.CSV) file containing every instance of
every anomaly (unconfirmed problem) raised by the NHA. It is only useful when operators
are debugging knowledge.
4-34 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Clearance logs - eaClear<date>
The Clearance log file is a Comma Separated Value (.CSV) file containing records of when
problems are cleared. The format of the clearance log files is .CSV with one line per cleared
problem as follows:
Automatic system administration housekeeping scripts clean up the NHA log files as follows:
• Log files older than three days are compressed.
To keep a log file, copy the file to an alternate location before 14 days have elapsed.
If a controlled shutdown of the NHA occurs from the NHA user interface, then an export of the
NHA configurable values for that OMC is done. These files are useful for debugging or backup
purposes.
File Contains
export-group-names.txt Cell group names and types.
export-group-details.txt A listing of cells and the cell group they are in.
export-thresholds.txt Thresholds for all cell-related detectors.
global-detectors.csv Thresholds for all non-cell related detectors.
formula.csv Knowledge editor formulae.
detector.csv Knowledge editor detectors.
exportconfig.txt Daily export times and alarms to OMC settings.
NOTE
These files are NOT written to the directory if the NHA shuts down as a result of an
OMC shutdown or if the NHA stop command is used.
68P02900W36-P 4-35
1900.2AS May 2008
Congurable les exported on shutdown Chapter 4: Administration
If it is necessary to archive useful NHA information or logs for troubleshooting purposes, the
script /usr/gsm/current/ea_tools/archive_nha_devdata can be used. This script backs up all
the information to a tape for analysis at a later time.
4-36 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Daily exports of key statistics
Every day the NHA calculates a set of daily key statistics for each OMC using the statistics from
the previous day. These values are stored in export files in text format. Values are calculated
at cell level, BSC level, and network level.
Where: is:
<omcname> the OMC name
The values calculated are divided into categories or rule sets. These rule sets are described in
Table 4-6.
NOTE
These rule sets are calculated for OMC release 1800. Some of these rules
are not calculated for the 1760 OMC releases. A list of the rules calculated
for each OMC is kept in /usr/gsm/OMCs/<omcname>/ne_data/nha_cell_
analysis/rule.list.
Two export files are created for each rule set: one for the cell level summaries and one for
BSC/network level summaries. The files use the following naming convention:
• CatDailySummary_<ruleset>_C_B.<ddmmyyyy>.rep (for BSC/network level
summaries)
These files are in tab-separated format. An example of the file output is as follows:
68P02900W36-P 4-37
1900.2AS May 2008
Overview of the Daily Exports of Key Statistics feature Chapter 4: Administration
Description
Rule
(I = Integer P = Percentage D = Decimal C = Carrier)
BE BE Carrier Level Bit Error Rate
BE0 (C BER DownLink Mean (TS 0))
BE1 (C BER DownLink Mean (TS 1))
BE2 (C BER DownLink Mean (TS 2))
BE3 (C BER DownLink Mean (TS 3))
BE4 (C BER DownLink Mean (TS 4))
BE5 (C BER DownLink Mean (TS 5))
BE6 (C BER DownLink Mean (TS 6))
BE7 (C BER DownLink Mean (TS 7))
BE8 (C BER DownLink Mean for the Carrier)
BEU0 (C BER UpLink Mean (TS 0))
BEU1 (C BER UpLink Mean (TS 1))
BEU2 (C BER UpLink Mean (TS 2))
BEU3 (C BER UpLink Mean (TS 3))
BEU4 (C BER UpLink Mean (TS 4))
BEU5 (C BER UpLink Mean (TS 5))
BEU6 (C BER UpLink Mean (TS 6))
BEU7 (C BER UpLink Mean (TS 7))
BEU8 (C BER UpLink Mean for the Carrier)
CA Carrier Level RF Loss Rate
CA0 (C Channel 0 RF Loss)
CA1 (C Channel 1 RF Loss)
CA2 (C Channel 2 RF Loss)
CA3 (C Channel 3 RF Loss)
CA4 (C Channel 4 RF Loss)
CA5 (C Channel 5 RF Loss)
CA6 (C Channel 6 RF Loss)
CA7 (C Channel 7 RF Loss)
CA8 (C RF Loss for the Carrier)
GS General Support
GS1 (P Connection Failure Rate)
GS2 (P SDCCH Blocking Rate)
GS3 (P TCH Blocking Rate)
GS4 (P Call Failure Rate)
GS5 (P Drop Call Rate)
GS6 (P Average Call Duration)
GS7 (P Incoming Handover Failure Rate (inter))
GS8 (P Incoming Handover Failure Rate (intra))
GS9 (P Outgoing Handover Failure Rate (inter))
GSA (P Outgoing Handover Failure Rate (intra))
GSB (P Uplink Quality)
GSC (P Uplink Level)
GSD (P Downlink Quality)
GSE (P Downlink Level)
Continued
4-38 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Overview of the Daily Exports of Key Statistics feature
Continued
68P02900W36-P 4-39
1900.2AS May 2008
Overview of the Daily Exports of Key Statistics feature Chapter 4: Administration
Continued
4-40 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Overview of the Daily Exports of Key Statistics feature
68P02900W36-P 4-41
1900.2AS May 2008
Conguring the Daily Exports of Key Statistics feature Chapter 4: Administration
The Daily Exports of Key Statistics feature uses its own configuration file
/usr/gsm/OMCs/<omcname>/ne_data/nha_cell_analysis/config/cat.cfg. The configurable
values which can be modified in this file are:
• CAT_LOG_COUNT
This configurable defines the number of days for which the daily export files are kept. The
default is seven days. Any export files older than this number of days are automatically
deleted.
• CAT_SUMMARY_RULE_SETS
This configurable defines the rule sets that are calculated each day. By default, all of the
rule sets are calculated and then displayed in a comma-separated list.
To change these configurable settings, edit the cat.cfg file and modify the required values. The
changes take effect the next time the daily exports are run.
• Call Volume
• Traffic Carried
The key statistics in this list cannot be modified or deleted.
NOTE
In addition to the five pre-defined key statistics, ten extra key statistics can be added
for each OMC version.
Users can specify additional key statistics to be exported daily by running the
/usr/gsm/current/ea_tools/lgStats/lgConfig script as user omcadmin. This script accepts
one argument of either -a, -r or -las follows:
4-42 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Directory structure
Directory structure
Daily export script files and executable files are installed separately for each OMC
configured on the NHA. For each OMC, the main directory is /usr/gsm/OMCs/<omc-
name>/ne_data/nha_cell_analysis. This directory is located on the OMC processor and is
NFS-mounted on the NHA.
The directories under the nha_cell_analysis directory are described in Table 4-7:
Directory Contains
bin all the scripts and executables used to generate the export
files.
config configuration file cat.cfg as well as other configuration files
used by the feature.
log daily export files created by the feature.
tmp temporary files.
The daily exports feature is run daily by an omcadmin cron job on the NHA. By default, the cron
job runs at 2:00 A.M. The cron job calls the script /usr/gsm/current/sbin/launch_nha_cat.sh.
This script launches the daily export scripts for each OMC.
68P02900W36-P 4-43
1900.2AS May 2008
Web access Chapter 4: Administration
Web access
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Web help
HTML-based Help is launched from the NHA User Interface or found directly at
http://[nhaservername]/, for example, http://snhasys1/.
The NHA is now configured as a web server and can be used to make documents or
reports visible to other users on the network. The root directory for published documents
is /usr/gsm/config/local.
For example, editing the file /usr/gsm/config/local/index.html gives any user who can ping
the NHA server on the network the ability to browse the file, by entering the following URL in
their web browser: http://snhasys1/index.html.
It is useful for creating reports or automatically generating information in HTML format from
the NHA.
The default NHA web page is accessed from the NHA UI client using the Tools - NHA Web
Page menu option. It is also accessed by entering http://[nhaservername]/ in a browser
window. For further information, refer to The NHA web page on page 2-65.
4-44 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA conguration les (ea.cfg)
The NHA configuration file contains the default configuration settings for the NHA. There
are two types of configuration files:
• The global ea.cfg file, which is at /usr/gsm/config/local/ea.cfg and applies to all OMCs
monitored.
The operator can edit some sections of these files to suit the host network or to suit the
operator's own needs. Unless otherwise specified, an NHA stop and start is required to pick
up the changes.
The config directory is backed up every day and these backups are kept for 15 days in tarred
and compressed files. Therefore, the most recent, quality copy of the ea.cfg file can be found
from the backup directory: /usr/gsm/OMCs/<omcname>/ea_logs/config-backup/.
Once this file is modified, the changes can be applied by entering the Problem UI as user
omcadmin and selecting Read ea.cfg files from the Configure menu.
68P02900W36-P 4-45
1900.2AS May 2008
OMC specic ea.cfg le Chapter 4: Administration
The default field separator used in NHA log files and export files is a comma (,). It is possible
to configure the separators in the global configuration file and use different characters such
as semi-colons (;") or periods (.) or pipes (|) as separators. This action can make it easier
to import files into third-party products in some countries. To make this change, modify the
variables EXPORT-SEPARATOR and IMPORT-SEPARATOR to COMMA, SEMICOLON, PIPE, or
DOT as follows:
There is a separate configuration file for each OMC connected to the NHA;
/usr/gsm/OMCs/<omcname>/config/ea.cfg. When an OMC is added, the main configuration
file is copied to the new OMC and its file paths are updated to reflect the directory structure of
the new OMC.
NHA problems are cleared automatically if they do not re-occur within a certain period since
they were last raised.
The configurable values for controlling these problems are maintained in the OMC-specific
configuration file: /usr/gsm/OMCs/<omcname>/config/ea.cfg.
For example, the values below show that Saturday and Sunday are the weekend days:
EVENT-EXP-TIMEOUT 25
HOURLY-EXP-TIMEOUT 25
VERY-EXP-TIMEOUT 6
MON-DAILY-EXP-TIMEOUT 25
TUE-DAILY-EXP-TIMEOUT 25
WED-DAILY-EXP-TIMEOUT 25
THU-DAILY-EXP-TIMEOUT 25
FRI-DAILY-EXP-TIMEOUT 25
SAT-DAILY-EXP-TIMEOUT 73
SUN-DAILY-EXP-TIMEOUT 49
For further information about problem clearing, refer to Problem detection and monitoring
on page 1-4.
4-46 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst OMC specic ea.cfg le
Conguring IMSI-DETACH
The installation procedure prompts the operator to configure the NHA for IMSI-DETACH, it can
also be reconfigured in the NHA configuration file.
The NHA uses two different formulae for MSC Connection Refusal Rate depending on whether
the MSC generates a "connection refused" message in response to an IMSI-DETACH.
IMSI–DETACH is configured at the MSC, as the NHA cannot read this configuration. A
configurable exists for it in the NHA configuration file (IMSI-DETACH).
The NHA has some built-in GPRS detectors that rely upon GPRS statistics read by the NHA from
the OMC-R. Additionally, these GPRS statistics can be used in formulae for the Knowledge
Editor or viewed in the Statistics History window.
NOTE
Before enabling GPRS statistics, ensure that the NHA hardware is correctly
configured for the size of the network. This action is necessary because extra memory
is required to store these statistics and performance problems can occur if GPRS
statistics are enabled on an NHA with less memory than required.
To make GPRS statistics from the OMC-R available to the NHA, update the
GPRS-IS-ENABLED variable to true in the OMC specific-configuration file
/usr/gsm/OMCs/<omcname>/config/ea.cfg. To turn them off, set the variable to false. The
default setting is true.
[GPRS-OPTION]
#
# If GPRS-IS-ENABLED is set to true then GPRS statistics
# from the OMC-R will be available to the NHA (in knowledge
# editor and statistics history window).
#
GPRS-IS-ENABLED false
If the GPRS option is turned off or on, the NHA must be stopped and started to pick up the
change.
Once the GPRS option is enabled and the NHA has picked up the change, it reads the list
of GPRS statistics which can be used in the Knowledge Editor and viewed in the Statistics
History window.
To view the list of GPRS statistics controlled by the GPRS_IS_ENABLED option, refer to
Table 4-12, Checking OMC configuration on page 4-62.
68P02900W36-P 4-47
1900.2AS May 2008
OMC specic ea.cfg le Chapter 4: Administration
NHA is hardcoded to start storing statistics at a specific time. In a 30 minutes statistics interval,
NHA starts storing statistics at HH:20 and HH:50. In a 60 minutes statistics interval, NHA
starts storing statistics at HH:20.
To change the start time for storing statistics in NHA, update the STATS-
COLLECTION-CYCLE-OFFSET configurable in the OMC-specific configuration file
/usr/gsm/OMCs/<omcname>/config/ea.cfg. If this configurable is set to 8, NHA will start
reading statistics at HH:28 and HH:58 for 30 minutes statistics interval and HH:28 for 60
minutes statistics interval.
If the value of this configurable is changed, the NHA must be stopped and started to pick up the
change. The valid range of values is from 0 to 8. The default value is 0.
NOTE
It is not advisable to change statistics collection cycle offset unless it is found that
NHA does not pick up statistics when there is a delay in storing the statistics in OMC.
4-48 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst User added statistics
The NHA administrator can configure the NHA to read additional statistics from the OMC, in
addition to the statistics that it already stores. The Knowledge Editor uses these additional
statistics to create new custom formulae and custom detectors which the NHA later uses during
its detection cycle to raise problems. It is also possible to view the additional statistics in the
Statistics History window.
NOTE
Only cell statistics can be added.
1 Edit the OMC specific ea.cfg file and change the setting for
USER-ADDED-STATS-ENABLED from FALSE to TRUE.
2 In the ea.cfg file, add a separate line entry for each additional statistic to
be stored by the NHA.
These lines must begin with the flag USER_STAT_01 and end with
USER_STAT_XX where X is the number of additional statistics to be stored
by the NHA.
3 Add the name of each new statistic to the right of the flags described in
the previous step.
The name of the statistic MUST match the column name in the PM database
and a MAXIMUM of 15 additional statistics can be added.
NOTE
For the correct column name, refer to the manual Technical
Description: OMC-R Database Schema (68P02901W34).
Continued
68P02900W36-P 4-49
1900.2AS May 2008
Overview of user added statistics Chapter 4: Administration
4-50 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing problems as alarms on the OMC
OMC operators are able to view NHA detected problems as alarms. The format of the alarm
depends upon the version of NHA and the version of the OMC software used. The alarm
numbers are in the range 40000 - 40999; for further information refer to List of problems
detected by the NHA on page 3-3.
It is possible to configure NHA problems to send them to the Network Management Centre
(NMC) through the Q3 interface.
The NHA can also be configured to send repeat problems to the OMC and to enable the resync
feature. When the resync feature is enabled, all non-cleared problems are sent to the OMC at
4.15 am.
To set up the NHA to send problems as alarms to an OMC, use the following steps:
Continued
68P02900W36-P 4-51
1900.2AS May 2008
Setting up NHA to send problems to the OMC as alarms Chapter 4: Administration
When the NHA has restarted, the NHA problems to OMC alarms
feature can be controlled from the NHA UI.
Continued
4-52 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Setting up NHA to send problems to the OMC as alarms
When this step is complete, the Subscriptions feature can be used to select
the required problems to be sent to the OMC.
4 On the NHA UI, select Subscriptions from the Configure menu to open
the Subscriptions window.
• On the Modify Subscription window, select the Problem types that are
to be forwarded to the OMC as alarms.
• On the Modify Region window, select the BSSs for which problems
should be forwarded to the OMC as alarms.
Note only newly raised problems included in the subscription and region are
sent to the OMC and appear there as alarms.
7 To test the feature quickly, choose an existing problem in the
PROBLEMS-TO-REPORT-TO-THE-OMC-<OMCNAME> subscription and
the PROBLEMS-TO-REPORT-TO-THE-OMC-<OMCNAME>region.
Use the Clear and Unclear options in the Problem UI pop-up menu to clear
and then unclear the problem. This action forces it to be sent to the OMC.
68P02900W36-P 4-53
1900.2AS May 2008
Setting up NHA to send problems to the OMC as alarms Chapter 4: Administration
The following is an example of an NHA problem appearing as an OMC alarm on the OMC
alarm window.
<BeginEvent>
#0 - NOT APPL - *NONE*.
NHAEvent - CELL - BSS0: 0 CELL 001-01-0-3 - 01/07/2004 00:25:31.
[40006] EA-NHA: Problem 06 - FMIC - Major -/-.
High daily SDCCH RF LOSS rate (%)
Value: 8.7 First: 28/06/2004 00:25 Last: 01/07/2004 00:26 Repeats: 2 - busy
0705-00070.
<EndEvent>
4-54 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA Monitoring Schedule
The NHA Monitoring Schedule feature is designed to stop some NHA detectors from false
firing at night. The NHA administrator can configure times during when problems cannot be
raised and can also configure what problem types are not raised. For example, the Monitoring
Schedule can be configured to stop the Very Low Call detector from firing between midnight
and 07:00 A.M.
NOTE
NHA Monitoring Schedule feature is not supported for script-based problems.
The NHA administrator can configure the Monitoring Schedule feature to prevent problems
from being raised at certain times, for example, at night. The Monitoring Schedule section in
the OMC-specific configuration file (/usr/gsm/OMCs/<omcname>/config/ea.cfg) provides
the following options (refer to Table 4-8):
Name Description
The detector does not fire between the starting time and the ending time, for example, from
midnight and 06:00 A.M. By default, the feature is OFF, the start time is 0 (that is, midnight) and
the end time is 7 (that is, 7:00 A.M.).
68P02900W36-P 4-55
1900.2AS May 2008
Conguring the Monitoring Schedule feature Chapter 4: Administration
After changing any Monitoring Schedule parameters in ea.cfg, an NHA stop and start is
required to make the changes take effect.
The detectors that the monitoring schedule applies to by default are defined in
/usr/gsm/current/knowledge/monitor/motorola-monitor-problem.txt and are:
• Very Low Call Activity
The NHA administrator can add extra detectors to the list of problems to
which the monitoring schedule should apply by adding the problem names to
the file defined in the CUSTOMER-MONITOR-PROBLEM-TYPE-PATH (usually,
/usr/gsm/config/monitor/customer-monitor-problem.txt). The problem names added
to this file should be the exact same as the full text that appears on the NHA UI. A
list of the full names of problems reported by the NHA is found in the reference file
/usr/gsm/current/knowledge/problem-and-cause-names.txt. Copy the names from there, if
necessary.
4-56 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the cell grouping script
The NHA monitors the cells in a network by placing them in groups. Use the cell grouping script
to allocate cells to different groups based on the statistic busy_tch_mean.
NOTE
The busy_tch_mean statistic calculates (in erlangs) the average number of busy
traffic channels over the whole period, including night time.
Following this initial cell grouping, the groups can be modified further using the Cell Grouping
options in the Configure menu.
Cells can be grouped, based on the activity in the cells, using the following steps:
Continued
68P02900W36-P 4-57
1900.2AS May 2008
Importing the grouped cells Chapter 4: Administration
If the cell allocation is not representative of the busy, normal, and quiet cells in the network,
rerun the cell grouping script using different busy_tch_mean values.
Once the cell grouping is complete, import the ea_group.csv file into the NHA using the Import
Cell Grouping option from the Configure menu.
4-58 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA threshold les
Reset NHA detector thresholds based on the performance of the network. In general, the
following guidelines can be applied to each detector for each group:
• If too few problems are being raised, loosen the threshold.
• If there are too many false alarms, increase the minimum sample size.
• If there are problems being missed, reduce the minimum sample size.
These changes can be made manually or made using Motorola sample threshold files.
The NHA is shipped with four levels of thresholds designed to provide a basis for resetting
the existing thresholds. Motorola provides these threshold levels to suit networks at various
levels of optimization.
This step can be completed quickly using a UNIX command such as the following:
sed 's/OMC/omcone/g' mot-export-thresholds-3.txt > omcone3.csv
Filename Description
mot-export-thresholds-1.txt Level one - loose thresholds, designed for a network that has
many quality issues. Some less-critical detectors are disabled.
mot-export-thresholds-2.txt Level two - default thresholds that are set up on the NHA
initially. It is designed for a network that has a significant
number of quality issues. Using these thresholds on a good
quality network results in few problems being reported.
mot-export-thresholds-3.txt Level three - tight thresholds designed to catch problems on a
network that is performing relatively well.
mot-export-thresholds-4.txt Level four - very tight thresholds, designed to catch problems
on a network that is highly optimized. Using these thresholds
on a poor quality network overwhelms the NHA with
problems.
68P02900W36-P 4-59
1900.2AS May 2008
Guidelines for setting thresholds Chapter 4: Administration
The following is a rough guide to resetting thresholds, based on consistent NHA performance,
and is subject to the number of problems that the operator wants to be aware of.
• An NHA detecting approximately 150 problems daily on a 1000 cell OMC is configured
effectively.
• If the problem count is continually less than 50, reset the thresholds to move up a level, for
example go from level three to level four.
• If the problem count is regularly greater than 300, reset the thresholds to move down a
level, for example go from level three to level two.
4-60 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Setting up the NHA for printing
An automated script is provided to configure the NHA processor, so that the printer which
is attached to the GUI server can be used.
In some instances, OMC and NHA operators are at remote sites using printers that are not
connected to the OMC GUI server.
To add these printers to the list of printers in the NHA, use the following steps:
1 Add the printer to the NHA box using the UNIX Admintool.
2 On the NHA UI, select a print option, press Update on the printer dialogue
and the printer is now added to that NHA.
3 Repeat this procedure for each NHA if there are multiple OMCs/NHAs.
NOTE
Use the preceding procedure to add printers to the NHA box. To connect printers to
the LAN, run the Add_EA_Printer script from /usr/gsm/current/sbin.
68P02900W36-P 4-61
1900.2AS May 2008
Checking OMC conguration Chapter 4: Administration
For the NHA to perform to the best of its ability, it needs information to be available and up to
date in the OMC-R. This state is achieved by turning on resync and by having the appropriate
statistics enabled.
The resync function enables the alarm and device state information at the OMC to be updated to
reflect the actual device state and alarm information at the network elements.
For example, if an operator clears an FMIC alarm at the OMC, the INSM updates and registers
the faulty device as INS. However, the action of clearing the alarm does not fix the alarm, thus
the device is still out-of-service, contrary to the INSM display. Scheduling a resync prevents this
situation from occurring.
The environment variables that are used to control the Resync Controller features are contained
in the RC.CNFG file in /usr/gsm/config/global on the OMC System processor.
The ResyncCtrl process periodically reads the RC.CNFG file, so unlike other environment
variables, any variables changed in this file are picked up without having to perform an OMC
stop and start.
ENABLERESYNC
TIMER
The environment variable TIMER sets the amount of time Resync Controller waits for a resync
to complete. It specifies the time in seconds.
4-62 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Enabling a resync
AUTORESYNC
The default setting is Y if not set otherwise. Autoresyncs take place regardless of the setting
of ENABLERESYNC.
Enabling a resync
Resync must be enabled, automatic resync must be enabled or periodic resync must be
scheduled to execute on the entire network on a daily basis. If this action is not performed,
then the In Service Monitor (INSM) cannot show up to date information because it relies on
the information being correct in the Configuration Database.
In addition, the resync option is set for state changes only. Refer to the following section
Resync (state only).
Ensure that resync and automatic resync are enabled on the OMC-R as follows:
NOTE
In some cases, it is necessary to add a line to include the
AUTORESYNC variable.
68P02900W36-P 4-63
1900.2AS May 2008
Enabling a resync Chapter 4: Administration
Periodic resync
Check if periodic resync is enabled for the network on a daily basis. If it is not, then schedule it
as follows:
1 Select the Admin icon on the OMC Front Panel to open the Admin Options
window.
2 Select the Resync Scheduler option to open the Resync Scheduler window.
3 Select Edit-Create from this window to open the rsSchedule Detailed View
window.
4 To insert the elements to be resynchronized, click the Scheduled Element
button to open the Navigation tree.
5 Select the Network element to be synchronized and double-click to close the
Navigation tree and insert the Network element in the Scheduled Element
Name field.
6 Set the resync schedule details as follows:
To update the state information in the OMC Configuration Database without having to schedule
a resync of alarms, use the following steps:
STATE_ON_AUDIT 1
3 In the pmProcConfig.csh file, set the environment variable:
STATE_ON_AUDIT 1
4-64 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Enabling appropriate statistics
The statistics to be enabled for the NHA to function correctly are listed in the required cell
statistics (Table 4-10) and required carrier statistics sections. The statistics marked ** are the
most important as they are used in statistical problem detection mechanisms. Others must be
enabled so that cause analysis and corrective actions are optimized.
1 To check that all the required statistics are enabled, as user root run the
S85check_stats script as follows:
cd /usr/gsm/cdrom_install
/S85check_stats <hostname>
where <hostname> is the hostname of the system processor belonging to
the OMC that has been configured to work with the NHA. The output can be
checked at /usr/gsm/OMCs/<omcname>/ea_stats.report.
Check these files for each OMC. They are in comma separated value format
so can be imported into a commercial spreadsheet for ease of use.
2 If there are entries present, then address each entry using the OMC detailed
views or the BSS stat_mode command. Refer to OMC Online Help or the
Technical Description: BSS Command Reference (68P02901W23) for a
detailed description of the stat_mode command.
NOTE
The S85check_stats script incorrectly reports disabled
statistics if a cell is OOS. To avoid this situation, run
the script again at a later time to compare results.
Continued
68P02900W36-P 4-65
1900.2AS May 2008
Required cell statistics Chapter 4: Administration
Continued
4-66 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Required cell statistics
Continued
68P02900W36-P 4-67
1900.2AS May 2008
Required cell statistics Chapter 4: Administration
Continued
4-68 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Required cell statistics
Continued
68P02900W36-P 4-69
1900.2AS May 2008
Required carrier statistics Chapter 4: Administration
(** indicates the most important statistics to enable from an NHA perspective)
(** indicates the most important statistics to enable from an NHA perspective.)
GPRS statistics
To make GPRS statistics from the OMC-R available to the NHA built-in GPRS detectors,
Knowledge Editor, and the Statistics History window, turn on the configurable
GPRS-IS-ENABLED in the OMC specific ea.cfg file.
NOTE
Before enabling GPRS statistics, ensure that the NHA hardware is correctly
configured for the size of the network. This action is necessary because extra memory
is required to store these statistics and performance problems can occur if GPRS
statistics are enabled on an NHA with less memory than required.
4-70 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst GPRS statistics
For further information about GPRS statistics, refer to NHA configuration files (ea.cfg)
in this chapter.
Continued
68P02900W36-P 4-71
1900.2AS May 2008
GPRS statistics Chapter 4: Administration
dl_rlc_ack_new_bks DL_RLC_ACK_NEW_BLKS
dl_rlc_nack_blks DL_RLC_NACK_BLKS
dl_tbf_time_1_ts DL_TBF_TIME_1_TS
dl_tbf_time_2_ts DL_TBF_TIME_2_TS
dl_tbf_time_3_ts DL_TBF_TIME_3_TS
dl_tbf_time_4_ts DL_TBF_TIME_4_TS
egprs_av_pdtch_max EGPRS_AVAILABLE_PDTCH
egprs_av_pdtch_mn EGPRS_AVAIL_PDTCH_MEAN
egprs_dl_asn_pccch EGPRS_DL_ASGN_PCCH
g_rach_bts_agch G_RACH_BTS_AGCH
g_rach_bts_prr G_RACH_BTS_PRR
g_rach_bts_rsl G_RACH_BTS_RSL
Continued
4-72 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst GPRS statistics
68P02900W36-P 4-73
1900.2AS May 2008
User added statistics Chapter 4: Administration
The NHA administrator can configure the NHA to read additional statistics from the OMC for
use in the Knowledge Editor or Statistics History. Refer to NHA configuration files (ea.cfg)
on page 4-45 for further information.
4-74 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring the recent alarms and events feature
This option is available from the UI action script option of the pop-up menu on the Problem
window. It enables users to extract useful, timely, and relevant data from the Event Logs and
Active Alarms. It reports data on recent configuration changes, state changes, recent alarms, or
active alarms.
The administrator can configure the feature to report a subset of events and alarms and to filter
out events and alarms that are of no interest. This filtering can be done per problem type. The
administrator can also tag certain interesting events or alarms as VIP.
For further information about displaying recent alarms and events, refer to Displaying recent
alarms and events on page 2-215.
NOTE
Recent alarms and events feature is not supported on NHA problems raised against
BSS.
Configure the VIP tags and filter settings for each problem type using the filterEvents file at
/usr/gsm/current/knowledge/external_problems.
Note there is a Default option, which is used for all problems if there are no individual settings
present for a problem type.
68P02900W36-P 4-75
1900.2AS May 2008
Editing the lterEvents le to exclude events Chapter 4: Administration
To tag an alarm or event as VIP or to exclude some events from the output for any given problem
type, edit the filterEvents file at /usr/gsm/current/knowledge/external_problems.
4-76 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Editing the lterEvents le to tag events as VIP
For example, to exclude some events such as objectDeletionEvent and CM MIB events from
appearing in the output for the Very Low TCH Usage problem, use the following steps:
To tag certain events or alarms (such as stateChangeEvent and the alarm PCH Queue Page
Discard) as VIP when they are displayed in the output for the Very Low TCH Usage problem,
use the following steps:
68P02900W36-P 4-77
1900.2AS May 2008
Running Active Alarm and Event reports separately Chapter 4: Administration
The Alarm and Event reporting option outputs data from active alarms and recent alarms
and events (from the event logs). It is possible to run the Active alarm report separate to the
overall event and alarm report. Running separate Active alarm and Alarm and Event reports
can improve the performance speed.
Note this script maintains itself and deletes any files older than 14 days (or as configured by
the administrator).
4-78 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring NHA for long term statistics viewing and monitoring
The NHA can be configured so that long term statistics can be viewed from the user interface
and statistics monitored to detect network issues. It does this by reading statistics once a day
from the OMC. Refer to Device out of service (OOS and Locked) on page 3-153 for further
information about using long term detectors.
The NHA Long Term Statistics feature enables the NHA to store a selection of daily key statistics
for up to 60 days. As key statistics for only one day are collected at a time, this amount of data is
not immediately available to the NHA the first time it is turned on for an OMC, for example,
when a new OMC is added or after a new installation of the NHA.
However, users who have the MARS tool can apply a script provided in this NHA release to
convert data from MARS to the format used by the NHA. This data can then be used by the long
term detection scripts and the long term statistics viewer. The procedure for running this
script is described below.
To generate a MARS report, log on to the MARS machine and start MARS. On the main window:
• Call Volume
Continued
68P02900W36-P 4-79
1900.2AS May 2008
Transfer MARS report to NHA server Chapter 4: Administration
MARS-NHA-<omcname>.csv
If the NHA server is accessible over the network, use ftp to transfer the MARS report to the
NHA server in the directory /usr/gsm/OMCs/<omcname>/.
/usr/gsm/current/ea_tools/lgStats/lgConvertMARS.pl
<omcname>/usr/gsm/OMCs/<omcname>/MARS-NHA-<omcname>.csv
where <omcname> is the "friendly" OMC name on the NHA.
The long term statistics files are placed in the directory
/usr/gsm/OMCs/<omcname>/lgStats.
3 Once these files are created, delete the MARS report file as follows:
rm /usr/gsm/OMCs/<omcname>/MARS-NHA-<omcname>.csv
4-80 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Time on the NHA
Time synchronization
The NHA automatically synchronizes its time with the time of the primary OMC, using the
timesynch script which is run as a daily cronjob.
Ideally, the time of any secondary OMC in the network is synchronized to the time of the primary
OMC. This can be done manually using the date command as user root or using a timesynch
script which is run as a cronjob on the secondary OMC.
For further information about time synchronization of OMCs, refer to NHA software
installation in the Install and Upgrade Guide, provided with the manual Software Release
Notes: Network Health Analyst (68P02900W77).
If the NHA installation procedure is followed correctly, there is usually no need to make any
adjustments to the system when the time is changed according to daylight saving rules.
Procedure 4-20
1 Type date at the command prompt on the OMC and on the NHA box.
2 Compare the output on each terminal and ensure that
they are the same (that is, date, time, and time zone).
If the time zones are different, then reconfigure the settings.
For instructions on how to do this, refer to the section on Configuring the
NHA processor in the Install and Upgrade Guide, provided with the manual
Software Release Notes: Network Health Analyst (68P02900W77).
NOTE
If changing the time or date using the date command, stop
the NHA before making the change and restart the NHA after
completing the change or changes.
68P02900W36-P 4-81
1900.2AS May 2008
Sending E-mail from the NHA Chapter 4: Administration
This procedure is used to set up the NHA so that files can be sent from the NHA to other mail
users.
Prerequisites
Before beginning the procedure, prepare with the local System Administrator as follows:
• Obtain the IP address and hostname of the mail server.
• If a firewall exists between the NHA and the mail server, set the filter configuration to:
• Ensure that the mail server has the SMTP service configured and running, with every
mailbox assigned an SMTP.
To set up the NHA to send E-mail to a mail server user, carry out the following procedure:
cd /var/yp
/usr/ccs/bin/make hosts
If these steps do not work as expected, check the NIS setup of the NHA
server by viewing the /ect/nsswitch.conf file on the NHA. If the setup is
non-standard, run step 1 to step 3 on the NIS server.
4-82 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the NHA to send E-mail
• To mail reports or files from the NHA to users automatically, using scripts.
To forward E-mail from an account on the NHA to outside mail addresses, use the following
steps:
Procedure 4-22 Forwarding E-mail from an NHA account to outside mail addresses
1 Create a file called .forward in the home directory of NHA user as follows:
vi /home/omcadmin/.forward
2 Enter the following line:
user_name@domain
where user_name@domain is the E-mail address for
the forwarded E-mail, for example, user1@xxx.com.
An additional line can be added to the .forward file for every E-mail
address required.
3 Save the file.
The following example of a shell script illustrates how to send the NHA daily report from the
NHA to mail addresses. This script could be added to a cronjob so that it is sent daily.
#!/bin/sh
mailpeople="user1@xxx.com,user2@xxx.com"
filename=/usr/gsm/config/local/daily.csv
uuencode $filename $filename > /tmp/attachment
mailx -s "NHA Daily Report" $mailpeople < /tmp/attachment
68P02900W36-P 4-83
1900.2AS May 2008
Installing NHA UI software on a GUI server or client Chapter 4: Administration
The NHA installation script sets up the NHA software on a GUI server or client. However, it
is sometimes necessary, subsequent to the NHA installation, to set up the NHA software on
an additional GUI server or client.
Ensure that the NHA and the GUI server or client trust each other by carrying out the following
steps:
1 Edit the file /etc/hosts on the GSR8 GUI server or client and add the IP
address and hostname of the NHA processor. Ignore this step for GSR9
GUI server or client.
2 Add the NHA hostname to the /.rhosts and /etc/hosts.equiv files on the
GSR8 GUI server or client. Ignore this step for GSR9 GUI server or client.
3 On the NHA processor, add the IP address and hostname of the GUI server
or client to the /etc/hosts file, and add the hostname of the GUI server or
client to the /.rhosts and /etc/hosts.equiv files. Ignore this step for GSR9
GUI server or client.
4 Insert the NHA software CD-ROM in the CD drive of the NHA.
5 Log on to the NHA as user root and install the software
on the GUI server or client by running the following script:
/usr/gsm/cdrom_install/S31tw_mmi <mmi-name>
where <mmi–name>is the hostname for the GUI server or client.
6 If patches are installed for the UI client, reboot the GUI server or client
processor.
Continued
4-84 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Installing NHA UI software
NOTE
The NHA UI clients cannot be run on the NHA or the OMC
processor as they could adversely affect the performance of these
processors.
68P02900W36-P 4-85
1900.2AS May 2008
Setting up the NHA menu option Chapter 4: Administration
The NHA can be started from a GUI server or client by setting up a desktop menu option. This
menu option can be accessed by clicking with the right mouse button on the CDE desktop.
The NHA install and the S31tw_mmi scripts automatically add an NHA menu option to the
standard CDE menus on GUI clients and servers. When selected, this NHA option launches the
NHA UI. If for any reason this option needs changing, then update the CDE menus for the
NHA using the following procedure:
no-label f.separator
"Network Health Analyst" f.exec "/usr/gsm/nhacurrent/
bin/EAUI <nha hostname>
no-label f.separator
NOTE
The second entry "Network Health Analyst" ... <nha
hostname>" is all one line.
4 Save and close the file.
5 If any users have personal dtwmrc files, edit these files to include the NHA
menu option. Log in to the GUI server or client as the user whose file is
to be modified.
NOTE
If the user's personal dtwmrc file does not exist, the menu options
for that user are taken from the system dtwmrc file (sys.dtwmrc).
Continued
4-86 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Setting up the NHA menu option
The option Network Health Analyst is now displayed. Select this option
and, after a short pause, the NHA UI is initialized.
68P02900W36-P 4-87
1900.2AS May 2008
Installing NHA UI software on a PC Chapter 4: Administration
System requirements
• 128 MB of RAM
The recommended operating system is Windows NT Version 4.0 Service Pack 5 OR Windows
2000 service Pack 1 OR Windows XP Professional. The installed NHA UI client uses 60 MB of
disk space.
Prerequisites
Before running and installing the NHA UI on a PC, obtain the following information:
• Username on the PC: Run the DOS command set username.
• The NHA processor must be known to the PC. If not known, add the NHA hostname and
IP address to the file C:\WINNT\system32\drivers\etc\hosts on the PC (Windows2000
and NT) or C:\WINDOWS\system32\drivers\etc\hosts (Windows XP). To check that
this action is successful, run the following from the command prompt on the PC:
ping <NHA hostname>
4-88 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Deleting previous versions
• The PC user must have an account on the NHA processor with an identical username.
If not, then create an account for the user on the NHA processor using the useradd
command. Ensure that the home directory of the user is created. For further information,
refer to Adding new users on page 4-102.
• Check that the usernames on the PC and the NHA use the same spelling and capitalization.
To see the exact username on a PC, enter the following in a DOS or command prompt window:
set username
• Check that the PC hostname is in the /etc/hosts file on the NHA (it is added automatically
by the Add_PC_Clients script). Also, check that the NHA is not using DNS to look up
the PC hostname (by default, it does not). Execute the following command on the NHA:
ping -s <PC hostname>
• Check that the hostname from the ping output exactly matches what is in the /etc/hosts
file on the NHA (not .cig.mot.com, for example.)
Once the above checks are completed, the NHA software can be installed and run.
Download the NHA UI software from the NHA processor, using the following steps:
68P02900W36-P 4-89
1900.2AS May 2008
Installing NHA UI software Chapter 4: Administration
For further information about installing the NHA UI on a PC, refer to the README file at
/usr/gsm/current/nhaui/pc/README.txt.
If Then
NT select Settings/Control Panel/System/Environment
Win2000 select Settings/Control Panel-System/Advanced/
Environment Variables
XP select Settings/Control Panel/Advanced/Environment Variables
1 Set the hostname of the NHA machine as the value of the NHA_HOSTNAME
variable.
2 When the values for Variable and Value have been entered, click Set.
3 Click OK.
4 Double click the Motorola NHA shortcut to launch the NHA UI.
This section only applies to users who have more than one NHA processor and want to install a
UI on each one. Most users have multiple NHA servers but only one NHA processor.
4-90 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Uninstalling NHA UI software
To create a Motorola NHA shortcut on your desktop for each NHA processor:
Procedure 4-29 Creating a Motorola NHA shortcut for each NHA processor
Uninstall the NHA UI software by following the steps for Deleting previous versions on
page 4-89.
68P02900W36-P 4-91
1900.2AS May 2008
Setting client machines for remote login Chapter 4: Administration
Depending on the network configuration, it is not always possible to log in remotely to a BSS on
an OMC when running an NHA UI on a GUI server or client on another OMC. The example in
Figure 4-3 illustrates such a scenario.
When the user on MMI1 selects a problem from the BSS on OMC2 and tries to log in remotely,
UNIX prevents the rlogin from happening. This is because a user cannot log in remotely to a
BSS from a machine that is not a trusted host for the OMC to which the BSS is connected. An
error message is displayed, indicating that the user does not have permission to log in remotely
to the BSS from the OMC.
However, if security arrangements at the customer site allow, permissions can be modified so
that a remote login can be performed from GUI servers or clients on one OMC to BSSs on
another OMC.
4-92 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst GSR8 OMC-R remote login
Modifying permissions to allow remote login from GUI servers and clients
1 Check user permissions for rlogin by entering the following command from
an Xterm on MMI1:
rsh [omchostname] /usr/openwin/bin/xterm -d [user's IP
address]:0.0 -e /usr/gsm/current/bin/RLstart [BSSname]
If MMI1 is not a trusted host as in Figure 4-3, the command fails, and the
Permission Denied error message is displayed.
2 Set up remote login permissions as follows:
• To allow remote login for specific users only, as user root, edit the file
$HOME/.rhosts on OMC2 for each user. Add the hostname of MMI1
to the file.
• To allow remote login for all users, as user root, edit the file
/etc/hosts.equiv on OMC2 for each user. Add the hostname of MMI1
to the file.
3 Check that users can perform a remote login to multi-OMC
NHAs by entering the following command from MMI1:
To enable a remote login from the NHA UI on a PC client to OMCs that the NHA is monitoring,
use the following steps:
Procedure 4-31 Enabling remote login from PC clients to OMCs monitored by the NHA
1 Check user permissions for rlogin by entering the following command from
a DOS window on the PC:
rsh [omchostname] /usr/openwin/bin/xterm -d [user's IP
address]:0.0 -e /usr/gsm/current/bin/RLstart [BSSname]
If the PC is not a trusted host of the OMC, the command fails and the
Permission Denied error message is displayed.
Continued
68P02900W36-P 4-93
1900.2AS May 2008
GSR9 OMC-R remote login onwards Chapter 4: Administration
Procedure 4-31 Enabling remote login from PC clients to OMCs monitored by the
NHA (Continued)
2 Set up remote login permissions as follows:
• To allow remote login for specific users only, as user root, edit the
file $HOME/.rhosts on the OMC for each user. Add the hostname
of the PC to the file.
• To allow remote login for all users, as user root, edit the file
/etc/hosts.equiv on the OMC for each user. Add the hostname of the
PC to the file.
3 Check that users can perform a remote login to BSSs on the OMC by
entering the following command from a DOS window on the PC:
rsh [omchostname] /usr/openwin/bin/xterm -d [user's IP
address]:0.0 -e /usr/gsm/current/bin/RLstart [BSSname]
From GSR 9 OMC-R onwards, the NHA UI client login feature allows the establishment of a
secure SSH login connection from the NHA Remote Login to BSS User Security Management.
The BSS Remote Login dialog is displayed when Remote Login is selected.
Troubleshooting step
2. Check that a user can perform NHA remote login to BSS operation
by entering the following command in any SSH client application:
/usr/openwin/bin/xterm -d [user's IP address]:0.0 -e
/usr/gsm/current/bin/RLstart [BSSname]
If a user account is not properly set up, the command fails, and an error message is displayed.
Refer to Adding new users on page 4-102.
Troubleshooting advice
• Check that the PC hostname is known to the OMC (in the /etc/hosts file).
• Check that the user has an account on the OMC and that the username is exactly the
same as that on the PC.
• Check that a personal firewall (for example, BlackICE™) is not interfering with the rlogin
from the PC to the OMC.
4-94 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Congure password le location
Users can configure the location to store the remembered password for remote login into the
BSS or RXCDR. To configure the password file location from the Problem window, select the
BSS Rlogin Option from the Configure Menu.
NOTE
It is advisable to store the password file on removable media.
68P02900W36-P 4-95
1900.2AS May 2008
Adding an OMC to be monitored Chapter 4: Administration
Prerequisites
Before installing the new OMC on the NHA, complete the following steps:
Procedure 4-32 Prerequisites for installing the new OMC on the NHA
4-96 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Installing an additional OMC
cd /usr/gsm/cdrom_install
./Install
A menu is presented which enables the operator to Add, Remove, or List the
OMCs currently configured.
3 To configure a new OMC, use the following steps:
If the GUI servers or clients have not been picked up, type N here. The
operator is then prompted for the server name. More than one
GUI server or client name can be entered, separated by spaces.
NOTE
Do not add OMC with a name identical to an existing OMC or with
the same name but different capitalization.
4 Log out as user root.
5 Make any necessary configuration changes as follows:
As user omcadmin, edit /usr/gsm/OMCs/<omcname>/config/ea.cfg to
set configurable values, for example, NHA problems to OMC alarm settings.
6 Start the NHA for the new OMC by logging on to the NHA as user
omcadmin and typing NHA start.
7 Select the new OMC.
68P02900W36-P 4-97
1900.2AS May 2008
Deleting an OMC from the NHA Chapter 4: Administration
While the NHA is still connected to the OMC that is to be removed, check each region
subscription and remove any device of the OMC from the subscription. For further information
about removing a device from the subscription, refer to Modifying or viewing a Cell region
on page 2-145 or Modifying or viewing a BSS region on page 2-140.
If disconnecting the NHA from an OMC, ensure that configuration and log files needed in
the future are backed up. This is because all configuration and log files are lost when the
NHA is uninstalled.
Deleting an OMC
If the OMC to be removed is the primary OMC, then the primary OMC must first be reassigned
before proceeding as follows:
NOTE
This procedure is different from a complete uninstall since the NHA is still running on
the other OMC(s).
4-98 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Deleting an OMC
On the OMC
• Delete the NHA hostname from these lines (including any colons :)
separating it from other hosts.
• If the NHA is the only hostname mentioned on a line, delete the whole
line.
Remove files from the GUI servers or clients for this OMC as follows:
68P02900W36-P 4-99
1900.2AS May 2008
Deleting an OMC Chapter 4: Administration
On the NHA
Remove the OMC and its GUI servers and clients from /etc/hosts, /etc/hosts.equiv and
/.rhosts.
4-100 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Uninstalling the NHA from a GUI server or client
To disconnect the NHA from a GUI server or client, perform the following steps:
cd /usr/gsm/config/local/installed_software_listing
rm server_[mmi_hostname]_*
3 As user root on the GUI server or client, remove references (if
references exist) to the NHA from the following files:
/etc/hosts
/etc/hosts.equiv
/.rhosts
4 As user root on the GUI server or client, remove NHA
software from the GUI server or client as follows:
cd /usr/gsm
rm nhacurrent
rm -rf *.EA.*
cd /gen
rm -rf nha
cd /opt
rm -rf gensym
This procedure removes all the NHA software from the GUI server or client.
NOTE
Omitting Steps 3 and 4 does not affect the operation of the NHA.
68P02900W36-P 4-101
1900.2AS May 2008
Adding new users Chapter 4: Administration
The NHA uses the primary OMC for its Network Information Services (NIS) information,
including user accounts.
If a new user is created on the primary OMC, update the NIS maps as follows:
cd /var/yp
/usr/ccs/bin/make
This command propagates the change to all the NIS clients of the OMC, including the NHA. It is
not necessary to change the ea.cfg file or to stop the NHA.
NOTE
The NHA only picks up new users that are created on the primary OMC.
To add users to the NHA who do not have accounts on the primary OMC, perform the following
steps:
Continued
4-102 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst New users on a secondary OMC
NOTE
Their home directory must not be /home as this is NFS
mounted from the primary OMC.
• Create users on the NHA with the same userid as they have on the
secondary OMC to ensure that there are no conflicts between users
on different OMCs.
This step can be executed by logging on to the NHA as user root and
running the command as follows (all one line):
useradd -c "Joe Bloggs" -d /gen/home/bloggsj -g 112 –m
-s/bin/csh -u 1068 bloggsj
68P02900W36-P 4-103
1900.2AS May 2008
Backing up le systems Chapter 4: Administration
This section describes how to perform complete file system backups and restores on the NHA
processor using the ufsdump/ufsrestore procedure. The following procedures are outlined:
• Restore overview
Prerequisites
Before performing a complete file system backup on the NHA processor, the tapes to be used
must be labeled and inserted into the DAT tape drive.
A file system backup can be performed automatically, using the backup_NHA utility. This
utility is used to perform either a local backup at the NHA processor or a remote backup at the
OMC-R Single Platform processor.
Continued
4-104 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Complete le system backup on the NHA processor (automatic)
Procedure 4-40 Backing up the le systems on the NHA processor (Continued)
5 Enter the following command to run the backup_NHA utility:
./backup_NHA
The following prompt is displayed:
Please indicate whether a local backup to
the NHA Processor or remote backup to the
Single Platform Processor is required
L. Local Backup to the NHA Processor
R. Remote Backup to the Single Platform Processor
Q. Quit Utility
Enter Choice:
Enter L for a local backup to the NHA processor, if a local backup is required.
Continued
68P02900W36-P 4-105
1900.2AS May 2008
Complete le system backup on the NHA processor (automatic) Chapter 4: Administration
Procedure 4-40 Backing up the le systems on the NHA processor (Continued)
/ filesystem successfully backed up
Attempting to backup /usr filesystem...
DUMP: Date of this level 0 dump:
Wed 27 Jun 2007 07:06:20 PM GMT
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d10
(sf440-2:/usr) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 5802432 blocks (2833.22MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 36.71% done, finished in 0:17
DUMP: 69.11% done, finished in 0:08
DUMP: 5802430 blocks (2833.22MB) on 1 volume at 1631 KB/sec
DUMP: DUMP IS DONE
DUMP: Level 0 dump on Wed 27 Jun 2007
07:06:20 PM GMT 5802432+0 records in
90663+0 records out
/usr filesystem successfully backed up
Attempting to backup /var filesystem...
DUMP: Date of this level 0 dump:
Wed 27 Jun 2007 07:36:04 PM GMT
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d15
(sf440-2:/var) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 104094 blocks (50.83MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 104062 blocks (50.81MB) on 1 volume at 2180 KB/sec
DUMP: DUMP IS DONE
DUMP: Level 0 dump on Wed 27 Jun 2007
07:36:04 PM GMT 104064+0 records in
1626+0 records out
/var filesystem successfully backed up
Attempting to backup /usr/gsm filesystem...
DUMP: Date of this level 0 dump:
Wed 27 Jun 2007 07:36:30 PM GMT
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d20
(sf440-2:/usr/gsm) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 421218 blocks (205.67MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 421182 blocks (205.66MB) on 1 volume at 1799 KB/sec
Continued
4-106 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Complete le system backup on the NHA processor (automatic)
Procedure 4-40 Backing up the le systems on the NHA processor (Continued)
DUMP: DUMP IS DONE
DUMP: Level 0 dump on Wed 27 Jun 2007 07:36:30 PM GMT
421184+0 records in
6581+0 records out
/usr/gsm filesystem successfully backed up
6 Write-protect the tape now.
NOTE
A log file is kept in
/usr/gsm/ea_logs/Backup_NHA.<datestamp> for analysis. In
addition, a record of backups is kept in /etc/dumpdates.
7 Record the partition locations for each file system backed up here as shown
in Table 4-13.
68P02900W36-P 4-107
1900.2AS May 2008
NHA system recovery for SunFire V440 and Netra N440 Chapter 4: Administration
Introduction to rollback
Use the following steps to perform a rollback on the SunFire V440 or Netra N440 platform.
This procedure supports the "mirroring" functionality for systems that are different from the
legacy platform. It is sometimes necessary to go back to the most recent version of the NHA
software. To roll back to the previous release, jumpstart the NHA processor and follow with
a full system recovery from tape.
A procedure exists to recover data to an NHA processor that has been stored on backup tapes.
The data can be restored onto a brand new set of disks or disks that have become corrupt. This
procedure destroys any data on the disks and overwrites the disks with data from the backup
tape. Perform the following steps to complete the restore procedure:
Prerequisites
Continued
4-108 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst JumpStarting the NHA processor for SunFire V440 or Netra N440
Refer to the procedure for booting the NHA processor from the NHA jumpstart CD/DVD-ROM
in Chapter 1, Installing Solaris 10 in the NHA 1900.2AS Installation and Upgrade Guide
to jumpstart the NHA processor. These steps allow the SunFire V440 or Netra N440 to be
configured with the correct hard-disk partitions that are required for the system restore
to proceed.
Follow Procedure 4-42 to restore the NHA file systems to a SunFire V440 or Netra N440. This
procedure assumes that /, /usr, /var and /usr/gsm are the only file systems being restored. To
restore extra file systems, continue with a format like the following for restoring the additional
file systems. A complete NHA file system restore can be performed from the tape drive attached
locally to the NHA processor.
Ensure that the most recent level 0 backup tape is loaded in the locally attached NHA processor
tape drive.
1 As user root on the NHA processor, bring the system down to single user
mode:
init 1
2 As user root on the NHA processor, rewind the tape drive by entering the
following command:
mt –f /dev/rmt/0 rew
3 Detach the mirrors for the file systems to be restored:
/usr/sbin/metadetach d0 d2
/usr/sbin/metadetach d10 d12
/usr/sbin/metadetach d15 d17
Continued
68P02900W36-P 4-109
1900.2AS May 2008
Restoring NHA le systems Chapter 4: Administration
NOTE
Use the metastat command to ensure that the partitions used
for/, /usr, /var, and /usr/gsm are identical to those partitions
used previously
Continued
4-110 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Restoring NHA le systems
68P02900W36-P 4-111
1900.2AS May 2008
Recreating the BOOT system Chapter 4: Administration
Make the c1t2d0s0 partition bootable by executing the following command as user root:
cd /mnt/usr/platform/‘uname -i‘/lib/fs/ufs
/mnt/usr/sbin/installboot bootblk /dev/rdsk/c1t2d0s0
Change the setup in /mnt/etc/vfstab. This step is necessary so that the system boots only with
the secondary submirrors.
Continued
4-112 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Reattaching devices
Reattaching devices
Any errors found after booting up for the first time can be safely ignored.
68P02900W36-P 4-113
1900.2AS May 2008
Reattaching devices Chapter 4: Administration
4-114 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Rolling back NHA client software
fsck -y /dev/rdsk/c1t0d0s0
fsck -y /dev/rdsk/c1t0d0s3
fsck -y /dev/rdsk/c1t0d0s4
Before rebooting the NHA processor, ensure that the synchronization process has finished. Run
the metastat command to verify this action.
Roll back the NHA UI client software on the MMI processors as follows:
Execute the following commands as root on each MMI that has the UI Client installed:
cd /usr/gsm
rm nhacurrent
ln -s /usr/gsm/1900.EA.1GS nhacurrent
cd /gen/nha
rm current
ln -s /gen/nha/1900.EA.1GS current
Repeat for each GUI server that has NHA 1900.1GS installed.
The NHA PC client software must also be rolled back to the previous version. To do a rollback,
uninstall the current version and reinstall the old version. Refer to Installing NHA UI
software on a PC on page 4-88. Follow this procedure for each PC that has NHA client
software installed.
68P02900W36-P 4-115
1900.2AS May 2008
Starting the NHA Chapter 4: Administration
1 Start the NHA for each OMC, using the NHA start command as omcadmin.
2 Monitor the progress of the start by tracking the NHA audit log file:
nhalog <omcname>
The NHA normally starts up within 30 minutes.
3 Check the NHA status:
NHA health
4-116 68P02900W36-P
1900.2AS May 2008
Index
Index
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
68P02900W36-P IX-1
May 2008 1900.2AS
Index
IX-2 68P02900W36-P
1900.2AS May 2008
Index
External interface for automatic action External interface for causes and actions (contd.)
scripts. . . . . . . . . . . . . . . . . . . 2-206 manual action scripts . . . . . . . . . . 2-201
External interface for cause analysis parameters for scripts . . . . . . . . . 2-192
scripts. . . . . . . . . . . . . . . . . . . 2-195 External interface for manual action
External interface for causes and ac scripts. . . . . . . . . . . . . . . . . . . 2-201
tions . . . . . . . . . . . . . . . . . . . 2-190 External interface problems. . . . . . . . 3-180
automatic action scripts. . . . . . . . . 2-206 External interfaces to detect problems . . 2-180
cause analysis scripts . . . . . . . . . . 2-195 creating a script . . . . . . . . . . . . 2-182
configuring . . . . . . . . . . . . . . . 2-191 output file . . . . . . . . . . . . . . . . 2-183
directory structure . . . . . . . . . . . 2-192 script directories . . . . . . . . . . . . 2-180
68P02900W36-P IX-3
May 2008 1900.2AS
Index
IX-4 68P02900W36-P
1900.2AS May 2008
Index
68P02900W36-P IX-5
May 2008 1900.2AS
Index
IX-6 68P02900W36-P
1900.2AS May 2008
Index
Read ea.cfg files menu option . . . . . . . 2-16 Repeated DRI-61-62-63 alarms . . . . . . 3-150
Read/write access to NHA . . . . . . . . . 2-5 Report to OMC . . . . . . . . . . . . . . 2-161
Recent problems filter . . . . . . . . . . 2-22 Report to OMC menu option . . . . . . . 2-16
Reduced GPRS capacity. . . . . . . . . . 3-127 Required statistics . . . . . . . . . . . . 4-65
Regions menu option . . . . . . . . . . . 2-16 Requirements
Regions, configuring hardware
BSS . . . . . . . . . . . . . . . . . . . 2-139 client . . . . . . . . . . . . . . . . . 4-19
Cell . . . . . . . . . . . . . . . . . . . 2-142 Resetting thresholds . . . . . . . . . . . 4-59
Regions, using . . . . . . . . . . . . . . 2-18 Response times . . . . . . . . . . . . . . 4-26
Remote login from the Problem window. . 2-54 Restarting the NHA . . . . . . . . . . . . . 4-7
Remote login, setting up client ma Restore procedure . . . . . . . . . . . . 4-108
chines . . . . . . . . . . . . . . . . . . . 4-92 Resync the OMC . . . . . . . . . . . . . 4-63
Repeated cell failure . . . . . . . . . . . 3-147 Rollback. . . . . . . . . . . . . . . . . . 4-108
Repeated DRI failure . . . . . . . . . . . 3-148
Scheduled OOS reports . . . . . . . . . . 2-93 Scripts for automatic cell grouping . . . . 2-131
Scoreboard . . . . . . . . . . . . . . . . 2-100 Scripts to detect problems . . . . . . . . 2-180
Scoreboard menu option . . . . . . . . . 2-15 SDCCH access failure problem . . . . . . 1-26
Script based problems . . . . . . . . . . 3-152 SDCCH problem list. . . . . . . . . . . . 3-25
68P02900W36-P IX-7
May 2008 1900.2AS
Index
IX-8 68P02900W36-P
1900.2AS May 2008
Index
68P02900W36-P IX-9
May 2008 1900.2AS
Standard Printing Instructions
Finishing • A4 size (210mm x 297mm) clear PVC sheet front page for
protection.
• Bag wrapped with clear polythene.
System Information
GSR9
1900.2AS
68P02900W36-P
1900.2AS
GSR9
68P02900W36-P
Cutting
datum point