You are on page 1of 599

System Information: Network

Health Analyst

68P02900W36-P May 2008


1900.2AS
© 1994-2008 Motorola, Inc. All Rights Reserved
Accuracy
While reasonable efforts have been made to assure the accuracy of this document, Motorola, Inc. assumes no
liability resulting from any inaccuracies or omissions in this document, or from use of the information obtained
herein. Motorola, Inc. reserves the right to make changes to any products described herein to improve reliability,
function, or design, and reserves the right to revise this document and to make changes from time to time in content
hereof with no obligation to notify any person of revisions or changes. Motorola, Inc. does not assume any liability
arising out of the application or use of any product, software, or circuit described herein; neither does it convey
license under its patent rights or the rights of others. It is possible that this publication may contain references to, or
information about Motorola products (machines and programs), programming, or services that are not announced
in your country. Such references or information must not be construed to mean that Motorola intends to announce
such Motorola products, programming, or services in your country.
Copyrights
This document, Motorola products, and 3rd Party Software products described in this document may include
or describe copyrighted Motorola and other 3rd Party supplied computer programs stored in semiconductor
memories or other media. Laws in the United States and other countries preserve for Motorola, its licensors, and
other 3rd Party supplied software certain exclusive rights for copyrighted material, including the exclusive right
to copy, reproduce in any form, distribute and make derivative works of the copyrighted material. Accordingly,
any copyrighted material of Motorola, its licensors, or the 3rd Party software supplied material contained in the
Motorola products described in this document may not be copied, reproduced, reverse engineered, distributed,
merged or modified in any manner without the express written permission of Motorola. Furthermore, the purchase
of Motorola products shall not be deemed to grant either directly or by implication, estoppel, or otherwise, any
license under the copyrights, patents or patent applications of Motorola or other 3rd Party supplied software,
except for the normal non-exclusive, royalty free license to use that arises by operation of law in the sale of a
product.
A list of 3rd Party supplied software copyrights are contained in the Supplemental information section of this
document.
Restrictions
Software and documentation are copyrighted materials. Making unauthorized copies is prohibited by law. No part
of the software or documentation may be reproduced, transmitted, transcribed, stored in a retrieval system, or
translated into any language or computer language, in any form or by any means, without prior written permission
of Motorola, Inc.
License Agreements
The software described in this document is the property of Motorola, Inc and its licensors. It is furnished by express
license agreement only and may be used only in accordance with the terms of such an agreement.
High Risk Materials
Components, units, or 3rd Party products used in the product described herein are NOT fault-tolerant and are NOT
designed, manufactured, or intended for use as on-line control equipment in the following hazardous environments
requiring fail-safe controls: the operation of Nuclear Facilities, Aircraft Navigation or Aircraft Communication
Systems, Air Traffic Control, Life Support, or Weapons Systems (High Risk Activities). Motorola and its supplier(s)
specifically disclaim any expressed or implied warranty of fitness for such High Risk Activities.
Trademarks

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.

1900.2AS May 2008


Table
of
Contents

Contents
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

System Information: Network Health Analyst


Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Version information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Resolution of Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Incorporation of Change Notices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Contacting Motorola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
24–hour support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Questions and comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Security advice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Warnings, cautions, and notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
General safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Electromagnetic energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Caring for the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
In EU countries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
In non-EU countries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CMM labeling and disclosure table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Motorola document set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Ordering documents and CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Document banner definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 1: Overview of the NHA


Overview of the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Introduction to the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Problem detection and monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Introduction to problem detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Problem detection process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Introduction to the detection process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Cause analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Corrective action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Devices monitored by NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
NHA detection mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

68P02900W36-P i
May 2008 1900.2AS
Contents

Introduction to NHA detection mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 1-8


Daily Roll-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Introduction to Daily Roll-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Detector components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Fixed Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Introduction to Fixed Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Detector components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Sample Roll-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Introduction to Sample Roll-up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Detector components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Interval Roll-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Introduction to Interval Roll-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Detector components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Sliding scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Introduction to sliding scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Detector components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Long-term detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Overview of long-term detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Event pattern analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Overview of event pattern analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
NHA problem clearing mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Introduction to problem clearing mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Knowledge based clearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Default event based clearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Default immediate type clearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Default very fast type clearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Default daily type clearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Default hourly clearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Default end of next working day clearance. . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Automatic blacklisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Introduction to automatic blacklisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Initial automatic blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Automatic blacklist maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
NHA detection examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Introduction to NHA detection examples. . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
The GSM call process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Example of a network fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Examples of the NHA detecting network faults . . . . . . . . . . . . . . . . . . . . . . . 1-28
Cell grouping in the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Introduction to NHA cell groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Dividing cells into groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Manual and Automatic cell grouping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31

Chapter 2: Using the NHA


Using the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Introduction to using the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
In this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Starting the NHA user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Starting the UIs on a GUI server or client with menu . . . . . . . . . . . . . . . . . . . . 2-3
Starting the UIs on a GUI server or client without menu. . . . . . . . . . . . . . . . . . . 2-3
Starting the user interfaces on a PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
NHA UI utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Copying and pasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Permissions and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Introduction to NHA security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
NHA UI Client Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

ii 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents

Security access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6


Security levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
User omcadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
The Problem window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Introduction to the Problem window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
In this section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Using the Problem window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Overview of using the Problem window . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Multi-OMC support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Displaying problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Managing problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Repeating problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Values of problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Ranking problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Sending messages to all other NHA users . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
The Problem window menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Overview of menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Subscriptions, sorting, and filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Introduction to managing lists of problems . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Using REGIONS to monitor the problem list . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Using problem subscriptions to monitor problem list . . . . . . . . . . . . . . . . . . . . 2-18
Filtering problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Using the Recent Problems filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Sorting problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Filtering problem types and values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Introduction to the Problem Type and Value Filter . . . . . . . . . . . . . . . . . . . . . . 2-25
Using the Problem Type and Value Filter . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Properties files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
User profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Introduction to the User Profile feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Using the Profile feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
The Problem pop-up menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Introduction to the Problem pop-up menu . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Pop-up menu options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Problem Information window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Introduction to the Problem Information window . . . . . . . . . . . . . . . . . . . . . . 2-32
Using the Problem Information window . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
Menu options on the Problem Information window . . . . . . . . . . . . . . . . . . . . . 2-33
Problem causes and corrective actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Line of Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Detector information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Other device, neighbor and site problems . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36
Changing the status of a problem using the Seen option . . . . . . . . . . . . . . . . . . . . . 2-37
Introduction to the Seen option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Using the Seen option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Adding comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
Introduction to Comment option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
Using the Comment option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
Viewing statistics history and event history . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Introduction to statistics history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Viewing statistics history for a problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Viewing statistics history for a problem cell . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Changing to different views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Viewing statistics history for a neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Viewing statistics history for a single interval . . . . . . . . . . . . . . . . . . . . . . . . 2-43
Viewing statistics history for a single statistic . . . . . . . . . . . . . . . . . . . . . . . . 2-44
Exporting and printing statistics data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45
Configuring statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46

68P02900W36-P iii
May 2008 1900.2AS
Contents

Viewing event history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49


Viewing long term statistics and other problem information . . . . . . . . . . . . . . . . . . . 2-51
Introduction to long term statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51
Configuring additional key statistics for daily export. . . . . . . . . . . . . . . . . . . . . 2-51
Viewing long term statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52
Event history. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
Viewing a list of Neighbor cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
Remote login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
Action scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-55
Adding to the blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
Printing problem details from the Problem pop-up menu . . . . . . . . . . . . . . . . . . 2-58
Exporting problem details from the Problem pop-up menu. . . . . . . . . . . . . . . . . . 2-58
Exporting and printing problem reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-59
Introduction to exporting problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-59
Manual exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-59
Automatic exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-59
Printing a list of problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-60
Loading export files into Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-60
Importing problems into spreadsheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
Modifying the macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
Abbreviations used in the Daily Export Report . . . . . . . . . . . . . . . . . . . . . . . . 2-61
Summary report of problems detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-63
Overview of the summary report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-63
The NHA web page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65
Overview of the NHA web page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-66
NHA network issue reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-66
NHA administration reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
NHA help pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68
Parameter Check Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-69
Introduction to the Parameter Check Report. . . . . . . . . . . . . . . . . . . . . . . . . 2-69
Background functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-69
The Parameter Check configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70
The Parameter Check Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73
Site Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
Introduction to Site Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
Using Site Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
Viewing the Site Health Check report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-78
Supported detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-79
BSS Detector Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
Introduction to BSS Detector Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
Using the BSS Detector Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
Viewing the BSS Detector Check report . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-82
Supported detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83
Using the In Service Monitor (INSM) tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-84
Introduction to the INSM tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-84
Common INSM procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-84
Viewing the status of network devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85
Introduction to the INSM graphical display . . . . . . . . . . . . . . . . . . . . . . . . . 2-85
G2 interface limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85
Device status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-86
Real-time display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-88
OOS indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-88
Viewing INSM reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-89
Introduction to INSM reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-89
Displaying a configuration report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-89
Displaying an OOS report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-90
Displaying a historical OOS report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-92

iv 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents

Scheduled OOS reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-93


Manually blacklisting a device on the network display . . . . . . . . . . . . . . . . . . . . . . 2-95
Introduction to blacklisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-95
Blacklisting from an OOS report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-95
Blacklisting from a configuration report . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-95
Removing a device from a blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-95
Using Worst Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
Overview of Worst Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
Displaying the worst cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-96
Worst cells report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-98
Printing, exporting, and copying worst cells details . . . . . . . . . . . . . . . . . . . . . 2-98
Configuring the Worst Cells feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-99
Using the Scoreboard feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
Introduction to the Scoreboard feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
Using the Scoreboard feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
Printing and exporting Scoreboard details . . . . . . . . . . . . . . . . . . . . . . . . . . 2-101
Frequency Clash Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-102
Overview of the Frequency Clash Report . . . . . . . . . . . . . . . . . . . . . . . . . . 2-102
Report details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-103
Configuring the NHA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-104
Introduction to the Configure menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-104
Cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-106
Introduction to cell grouping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-106
NHA cell groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-106
Manual and Automatic Cell Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-107
Default cell groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-108
Moving cells from one group to another . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-108
Configuring group properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-110
The Group Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-110
Creating cell groups on the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-111
Changing groups from Manual to Automatic . . . . . . . . . . . . . . . . . . . . . . . . . 2-112
Exporting cell group names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-112
Importing cell group names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-112
Manual cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-115
Introduction to manual cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-115
Manually moving cells between groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-115
Additional features of the Cell View window . . . . . . . . . . . . . . . . . . . . . . . . . 2-118
Exporting cell group files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-120
Importing cell group files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-120
Automatic cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-122
Introduction to automatic cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-122
Automatic cell grouping scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-122
Manually running automatic cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-124
Introduction to running automatic cell grouping manually . . . . . . . . . . . . . . . . . . 2-124
Configuring the NHA to run automatic cell grouping manually . . . . . . . . . . . . . . . 2-124
Background functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-126
Automatically running automatic cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . 2-128
Introduction to automatic cell grouping functionality . . . . . . . . . . . . . . . . . . . . 2-128
Configuring the NHA to run automatic cell grouping automatically . . . . . . . . . . . . . 2-128
Background functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-130
Checking the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-130
Scripts for automatic cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-131
Multiple OMC systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-132
Modifying detectors and thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-133
Introduction to modifying detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-133
Modifying detector thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-133
Extra options on the Thresholds window . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-136
Importing thresholds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-136

68P02900W36-P v
May 2008 1900.2AS
Contents

Automatic export and import of thresholds . . . . . . . . . . . . . . . . . . . . . . . . . 2-138


Configuring BSS Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-139
Introduction to BSS regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-139
Creating a BSS region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-139
Modifying or viewing a BSS region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-140
Deleting a BSS region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-141
Verifying BSS regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-141
Configuring Cell Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-142
Introduction to Cell Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-142
Creating a Cell region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-142
Modifying or viewing a Cell region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-145
Deleting a Cell region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-147
Verifying Cell regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-147
Configuring problem subscriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-148
Introduction to problem subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-148
Creating a problem subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-148
Modifying or viewing a problem subscription . . . . . . . . . . . . . . . . . . . . . . . . 2-150
Deleting a problem subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-150
Verifying problem subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-150
User-defined causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-151
Introduction to user-defined causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-151
Adding a user-defined cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-152
Editing a user-defined cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-154
Deleting a user-defined cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-154
Statistics per problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-155
Viewing statistics per problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-155
Neighbor Cell statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-156
Configuring Neighbor Cell statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-156
Blacklisting devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-157
Introduction to blacklisting devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-157
Viewing and modifying the blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-157
Exporting blacklist details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-158
Importing blacklist details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-159
Automatic blacklist file import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-159
Daily Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-160
Configuring Daily Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-160
Reporting NHA problems to the OMC as alarms . . . . . . . . . . . . . . . . . . . . . . . . . 2-161
Configuring Report to OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-161
Editing Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-162
Overview of Editing Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-162
The Knowledge Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-163
Introduction to the Knowledge Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-163
Launching the Knowledge Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-163
G2 interface limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-164
Importing and exporting detectors and formulae . . . . . . . . . . . . . . . . . . . . . . 2-164
Creating custom formulae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-165
Introduction to custom formulae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-165
Creating a custom formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-166
Editing a custom formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-166
Using the Formula Version Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-168
Introduction to the Formula Version Editor . . . . . . . . . . . . . . . . . . . . . . . . . 2-168
Building new formulae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-169
Creating a custom detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-171
Introduction to custom detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-171
Creating custom detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-172
Edit a custom detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-174
Introduction to editing custom detectors . . . . . . . . . . . . . . . . . . . . . . . . . . 2-174
Editing a custom detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-174

vi 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents

Example of a custom detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-176


Introduction to worked example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-176
Formula and detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-176
Build the formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-177
Name the formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-178
Create the detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-178
Apply detector threshold values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-179
Create a default cause for the detector . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-179
Validate the new detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-179
External interfaces to detect problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-180
Introduction to external scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-180
Script directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-180
Creating a script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-182
Output file fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-183
Example user-created script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-184
Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-189
External Interface for Causes and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-190
Introduction to External Interface for Causes and Actions . . . . . . . . . . . . . . . . . . 2-190
Cause Analysis scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-190
Manual Action scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-191
Automatic Action scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-191
Configuration of the External Interface for Causes and Actions . . . . . . . . . . . . . . . 2-191
Configuration file entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-191
Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-192
Parameters for scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-192
External Interface for Cause Analysis Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 2-195
Associating Cause Analysis Scripts with problems . . . . . . . . . . . . . . . . . . . . . . 2-195
Output file format for Cause Analysis Scripts . . . . . . . . . . . . . . . . . . . . . . . . 2-196
Sample Cause Analysis Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-198
External Interface for Manual Action Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 2-201
Associating Manual Action Scripts with causes . . . . . . . . . . . . . . . . . . . . . . . 2-201
Using the DISPLAY variable with Manual Action scripts . . . . . . . . . . . . . . . . . . . 2-203
Sample Manual Action scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-203
External Interface for Automatic Action Scripts . . . . . . . . . . . . . . . . . . . . . . . . . 2-206
Associating Automatic Action Scripts with causes . . . . . . . . . . . . . . . . . . . . . . 2-206
Automatic Action scripts output files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-207
Sample Automatic Action scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-207
User Interface Action scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-209
Introduction to User Interface Action scripts . . . . . . . . . . . . . . . . . . . . . . . . 2-209
Adding additional user-defined scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-209
Cyclic Neighbor Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-211
Introduction to Cyclic Neighbor Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 2-211
Configuring Cyclic Neighbor Statistics on the NHA . . . . . . . . . . . . . . . . . . . . . 2-212
The feature in action - overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-213
Using the output on the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-213
Displaying recent alarms and events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-215
Overview of alarms and events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-215

Chapter 3: Problem guide


Problem guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Introduction to NHA problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
NHA problem solving process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
List of problems detected by the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Statistics based problems on cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Knowledge Editor problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
External interface problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Call success problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

68P02900W36-P vii
May 2008 1900.2AS
Contents

List of call success problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9


Call success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Dropped call rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Path balance tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
RF issue tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
High second assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Low mean time between drop calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
Low TCH mean holding time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
Immediate assignment problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
List of immediate assignment problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
High immediate assignment failure rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Formula used to detect this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Low immediate assignment success rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
Formulae used to detect this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
SDCCH RF loss rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31

viii 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents

Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32


Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
Outage problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
List of outage problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33
Channel requests but no calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
Call setup troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
Very low call activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40
Low number of mobile terminated calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41
Out of service timeslots in cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Effects of dummy carriers on NHA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43
Very low TCH usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45
One-way MTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47
Overload problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
List of overload problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
High GPROC utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Threshold values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
High immediate assignment blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

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

Low Inter-BSS handover attempt rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Threshold values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71
Low mean time between handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72
Outgoing handover success rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73
Formulae for detecting handover problems . . . . . . . . . . . . . . . . . . . . . . . . . 3-73
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75
Low outgoing Inter-RAT handover success rate . . . . . . . . . . . . . . . . . . . . . . . . . 3-76
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77
Handover reason problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78
List of handover reason problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78
High handover rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-82
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-82
Low handover rate - power budget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84
Carrier problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-85
List of carrier problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-85
High bit error rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86
Threshold values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-87
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-87
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-87
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-87
High frame erasure rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-88
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-88
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-88
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-89
Threshold values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-89
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-89

68P02900W36-P xi
May 2008 1900.2AS
Contents

Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-90


Path balance problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-91
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-91
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-91
Threshold values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-91
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-92
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-92
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-92
High RF losses imbalance on odd or even timeslots . . . . . . . . . . . . . . . . . . . . . . . 3-93
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-94
High interference on idle rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96
High BER imbalance on odd or even timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-98
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-98
High RF Losses Out of Proportion to Traffic Carried . . . . . . . . . . . . . . . . . . . . . . . 3-99
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-100
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-100
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-100
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-101
GPRS problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-102
List of GPRS problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-102
GPRS requests but no data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-103
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-103
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-103
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-104
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-104
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-104
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-105
High GPRS utilization by allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-106
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-106
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-106
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-106
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-107
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-107
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-107
No GPRS activity in cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-108
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-108
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-108
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-109
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-109
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-109

xii 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents

Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-110


High GPRS timeslot congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-112
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113
GPRS Out of Service (OOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114
Problem detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-115
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-115
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-115
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-116
High GPRS utilization by Traffic (uplink/downlink). . . . . . . . . . . . . . . . . . . . . . . . 3-117
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-118
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-119
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-120
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-120
High PRP load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-122
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-122
Uplink TBF Setup Success Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-124
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-125
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-125
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-126
Reduced GPRS capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-127
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-127
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-127
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128
High downlink block error rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-130
High DPROC utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131
Formula for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-132
Infrastructure problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-133

68P02900W36-P xiii
May 2008 1900.2AS
Contents

List of infrastructure problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-133


Device not in the MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-134
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-134
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-134
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-134
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-134
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-135
No statistics from BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-137
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-137
No statistics from Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-138
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-138
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-138
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-138
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-139
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-139
No statistics from Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-141
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-141
Event based problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-142
List of event based problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-142
Database upload required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-144
GCLK recalibration required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-146
Repeated cell failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147
Repeated DRI failure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-148
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-148
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-148
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-148
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-148
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-149
Repeated DRI-61-62-63 alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-151
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-151
Script based problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-152

xiv 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents

Overview of script based problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-152


Device out of service (OOS and Locked) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-153
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-153
Problem detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-154
Configuring Device OOS scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-155
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158
Long term detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159
Problem detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159
Detection mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-160
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-162
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-162
Configuring long term detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-162
BSS-level detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-164
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-164
Formulae used to detect this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-164
Problem detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-171
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-171
Problem auto-clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-171
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-172
Consolidated problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173
Problem detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173
Formulae for detecting this problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-174
Problem confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-177
Problem causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-177
Problem clearing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-177
Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-177
Customized problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-179
Introduction to customized problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-179
External interface problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-180
Introduction to external interface problems . . . . . . . . . . . . . . . . . . . . . . . . . 3-180
NHA default thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-181
Introduction to default thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-181
Threshold files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-181
NHA automated thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-182
Introduction to NHA automated thresholds . . . . . . . . . . . . . . . . . . . . . . . . . 3-182
Using the Problem Reducer script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-183
Using the Thresholds Calculator script . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-185
Audit log information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-187

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

Configurable startup options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10


NHA directory structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Introduction to NHA directory structures . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
On the NHA machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
On the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
On GUI servers or clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Scripting utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
NHA licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Introduction to NHA licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
NHA license feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Checking NHA license details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Updating NHA license files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
NHA hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Introduction to NHA hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Hardware specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
NHA UI client requirements on a GUI server or client . . . . . . . . . . . . . . . . . . . . 4-20
NHA UI client requirements on a PC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
NHA troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
Introduction to NHA troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
Check NHA status and health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
Investigate an NHA shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Check NHA processes and log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Check if audit log files are written to . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Check error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Check disk space usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Check event logs processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Check statistics processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Performance troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Check for "too many" problem messages. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Check NHA system performance statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Get the best performance from the UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Troubleshooting mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Introduction to troubleshooting mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Check sharing from the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Generating a new ssh key in NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Introduction to ssh in NHA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Generating a new ssh key in NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Check OMC Informix settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
Introduction to checking OMC Informix settings . . . . . . . . . . . . . . . . . . . . . . . 4-32
Running the verify_informix script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
NHA log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
Introduction to NHA log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
Importing problems into spreadsheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
Audit files - eaAudit<date> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Daily Export files - DailyExport<date>.csv . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Problem logs - eaProblems<date> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Anomaly logs - eaAnomaly<date> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Clearance logs - eaClear<date> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Clean up of log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Configurable files exported on shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Daily exports of key statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37
Overview of the Daily Exports of Key Statistics feature . . . . . . . . . . . . . . . . . . . 4-37
Configuring the Daily Exports of Key Statistics feature . . . . . . . . . . . . . . . . . . . 4-42
Configuring additional key statistics for daily export. . . . . . . . . . . . . . . . . . . . . 4-42
Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
Running daily exports of key statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
Web access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
Web help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44

xvi 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Contents

The NHA as a web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44


NHA web page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
NHA configuration files (ea.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
Introduction to ea.cfg files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
Global ea.cfg file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
OMC specific ea.cfg file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46
User added statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
Overview of user added statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
Viewing problems as alarms on the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51
NHA problems on the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51
Setting up NHA to send problems to the OMC as alarms . . . . . . . . . . . . . . . . . . 4-51
NHA Monitoring Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55
Description of the NHA Monitoring Schedule feature . . . . . . . . . . . . . . . . . . . . 4-55
Configuring the Monitoring Schedule feature . . . . . . . . . . . . . . . . . . . . . . . . 4-55
Using the cell grouping script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-57
Introduction to cell grouping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-57
Running the cell grouping script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-57
Importing the grouped cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58
NHA threshold files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
Introduction to NHA threshold files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
Using sample threshold files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
Guidelines for setting thresholds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-60
Setting up the NHA for printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-61
Configuring the NHA for printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-61
Configuring printers not connected to the GUI server . . . . . . . . . . . . . . . . . . . . 4-61
Checking OMC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-62
Introduction to OMC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-62
Resyncing the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-62
Enabling a resync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-63
Enabling appropriate statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-65
Required cell statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-65
Required carrier statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-70
GPRS statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-70
User added statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-74
Configuring the recent alarms and events feature . . . . . . . . . . . . . . . . . . . . . . . . 4-75
Overview of alarms and events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-75
Introduction to setting up tags and filters . . . . . . . . . . . . . . . . . . . . . . . . . . 4-75
Editing the filterEvents file to exclude events . . . . . . . . . . . . . . . . . . . . . . . . 4-76
Editing the filterEvents file to tag events as VIP . . . . . . . . . . . . . . . . . . . . . . . 4-77
Running Active Alarm and Event reports separately . . . . . . . . . . . . . . . . . . . . . 4-78
Configuring NHA for long term statistics viewing and monitoring . . . . . . . . . . . . . . . . 4-79
Introduction to the Long Term Statistics feature . . . . . . . . . . . . . . . . . . . . . . 4-79
Enable the Long Term Statistics feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-79
Generate MARS report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-79
Transfer MARS report to NHA server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-80
Convert MARS report using lgConvertMARS.pl . . . . . . . . . . . . . . . . . . . . . . . 4-80
Time on the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-81
Time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-81
Changing to and from daylight saving time . . . . . . . . . . . . . . . . . . . . . . . . . 4-81
Sending E-mail from the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-82
Introduction to sending E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-82
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-82
Setting up the NHA to send E-mail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-82
Using the NHA to send E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-83
Installing NHA UI software on a GUI server or client . . . . . . . . . . . . . . . . . . . . . . 4-84
Introduction to installing NHA software on a GUI server or client . . . . . . . . . . . . . 4-84
Installing NHA UI software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-84
Setting up the NHA menu option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-86

68P02900W36-P xvii
May 2008 1900.2AS
Contents

Introduction to the NHA menu option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-86


Setting up the NHA menu option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-86
Installing NHA UI software on a PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-88
System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-88
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-88
Deleting previous versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-89
Downloading NHA UI software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-89
Installing NHA UI software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-90
Setting up the PC environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-90
More than one NHA processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-90
Uninstalling NHA UI software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-91
Setting client machines for remote login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-92
GSR8 OMC-R remote login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-92
GSR9 OMC-R remote login onwards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-94
Troubleshooting advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-94
Configure password file location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-95
Adding an OMC to be monitored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-96
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-96
Installing an additional OMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-97
Deleting an OMC from the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-98
Before removing an OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-98
Deleting an OMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-98
Uninstalling the NHA from a GUI server or client . . . . . . . . . . . . . . . . . . . . . . . . 4-101
Procedure for uninstalling from a GUI server or client. . . . . . . . . . . . . . . . . . . . 4-101
Adding new users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-102
Introduction to adding new users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-102
New users on a primary OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-102
New users on a secondary OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-102
Backing up file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-104
Introduction to file system backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-104
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-104
Complete file system backup on the NHA processor (automatic). . . . . . . . . . . . . . . 4-104
NHA system recovery for SunFire V440 and Netra N440 . . . . . . . . . . . . . . . . . . . . 4-108
Introduction to rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-108
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-108
Shutting down the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-108
JumpStarting the NHA processor for SunFire V440 or Netra N440 . . . . . . . . . . . . . 4-109
Restoring NHA file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-109
Recreating the BOOT system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-112
Reattaching devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-113
Rolling back NHA client software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-115
Rolling back PC client software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-115
Starting the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-116

xviii 68P02900W36-P
1900.2AS May 2008
List
of
Figures

List of Figures
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Figure 1-1: NHA process illustration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3


Figure 1-2: NHA problem detection process . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Figure 1-3: Daily roll-up detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Figure 1-4: Fixed Threshold detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Figure 1-5: Sample Roll-up detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Figure 1-6: Interval Roll-up detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Figure 1-7: Threshold level decreased for a “greater than” comparison . . . . . . . . . . . . . 1-18
Figure 1-8: Threshold level increased for a "less than" comparison . . . . . . . . . . . . . . . 1-18
Figure 1-9: Call process model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Figure 1-10: Immediate Assignment Failure Rate . . . . . . . . . . . . . . . . . . . . . . . . 1-27
Figure 1-11: Daily detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Figure 1-12: Interval based detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
Figure 1-13: Default cell groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Figure 2-1: NHA UI Client login window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Figure 2-2: Problem window - displaying problems . . . . . . . . . . . . . . . . . . . . . . . 2-10
Figure 2-3: Filter window (partial view) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Figure 2-4: Sort window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Figure 2-5: Problem Type and Value Filter window . . . . . . . . . . . . . . . . . . . . . . . 2-27
Figure 2-6: Configure menu - Profile option . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Figure 2-7: Problem window and pop-up menu . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Figure 2-8: The Problem Information window . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Figure 2-9: Selecting Unseen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38
Figure 2-10: Selecting the Comment option . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
Figure 2-11: Statistics History - Cell window . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Figure 2-12: Statistics History - Neighbor window. . . . . . . . . . . . . . . . . . . . . . . . 2-43
Figure 2-13: Cell & Neighbor - Single Interval window . . . . . . . . . . . . . . . . . . . . . 2-44
Figure 2-14: Cell & Neighbor - Single Statistic window . . . . . . . . . . . . . . . . . . . . . 2-45
Figure 2-15: Exporting to a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Figure 2-16: Statistics Selection window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47
Figure 2-17: Carrier Statistics window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
Figure 2-18: Neighbor Cell Statistics Selection window . . . . . . . . . . . . . . . . . . . . . 2-49
Figure 2-19: Viewing long term statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52
Figure 2-20: Neighbors window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
Figure 2-21: BSS Remote Login Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-55
Figure 2-22: Selecting the Action Scripts option . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
Figure 2-23: Confirm execution of Action Scripts . . . . . . . . . . . . . . . . . . . . . . . . 2-56
Figure 2-24: Default NHA web page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65
Figure 2-25: Example of a Parameter Check Report in HTML format . . . . . . . . . . . . . . 2-74
Figure 2-26: Selecting Site Health Check from the Problem window . . . . . . . . . . . . . . 2-77
Figure 2-27: Site Health Check report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-78
Figure 2-28: Selecting the BSS Detector Check option from the pop-up menu . . . . . . . . . . 2-82
Figure 2-29: INSM network display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-88
Figure 2-30: Configuration report window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-90
Figure 2-31: Options pop-up menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-91
Figure 2-32: Example OOS Report (All) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-91

68P02900W36-P xix
May 2008 1900.2AS
List of Figures

Figure 2-33: OOS History window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-93


Figure 2-34: Worst Cells Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-97
Figure 2-35: Worst Cells window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-98
Figure 2-36: Scoreboard Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-100
Figure 2-37: Scoreboard window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-101
Figure 2-38: Example of a Frequency Clash Report . . . . . . . . . . . . . . . . . . . . . . . 2-102
Figure 2-39: Configure menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-105
Figure 2-40: Cell View window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-107
Figure 2-41: Group Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-110
Figure 2-42: Group Creation window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-111
Figure 2-43: Import Group names window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-113
Figure 2-44: Import Cell Grouping window . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-113
Figure 2-45: Open Cell Grouping window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-116
Figure 2-46: Change Cell Group Confirmation window . . . . . . . . . . . . . . . . . . . . . 2-117
Figure 2-47: Configuring cell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-118
Figure 2-48: Export to File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-120
Figure 2-49: Regroup Cells Automatically window . . . . . . . . . . . . . . . . . . . . . . . . 2-125
Figure 2-50: Thresholds Filter window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-134
Figure 2-51: Thresholds window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-135
Figure 2-52: Import Thresholds window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-137
Figure 2-53: New Region window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-140
Figure 2-54: Open Cell Region window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-143
Figure 2-55: New Cell Region window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-144
Figure 2-56: Modify Cell Region Confirmation window . . . . . . . . . . . . . . . . . . . . . 2-146
Figure 2-57: Problem subscriptions window . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-149
Figure 2-58: User-defined cause window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-152
Figure 2-59: Corrective Action for local cause window . . . . . . . . . . . . . . . . . . . . . 2-153
Figure 2-60: Select Problem window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-155
Figure 2-61: Statistics Selection window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-156
Figure 2-62: Blacklisted Devices window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-157
Figure 2-63: Exporting blacklist details to a file . . . . . . . . . . . . . . . . . . . . . . . . . 2-158
Figure 2-64: Importing a blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-159
Figure 2-65: Confirm Automatic Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-159
Figure 2-66: Daily Export dialog box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-160
Figure 2-67: Report to OMC dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-161
Figure 2-68: Custom Formulae window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-165
Figure 2-69: Formula Editor window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-166
Figure 2-70: Formula Version Editor window . . . . . . . . . . . . . . . . . . . . . . . . . . 2-170
Figure 2-71: Custom Detector window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-172
Figure 2-72: Detector Editor window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-175
Figure 2-73: Example of a Cause Action script. . . . . . . . . . . . . . . . . . . . . . . . . . 2-202
Figure 4-1: Shutting down the OMC NHA server . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Figure 4-2: Shutdown warning message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Figure 4-3: Remote login scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-92
Figure 4-4: BSS Rlogin Option Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-95

xx 68P02900W36-P
1900.2AS May 2008
List
of
Tables

List of Tables
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Table 1: Manual version history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2


Table 2: Service requests resolved in this manual . . . . . . . . . . . . . . . . . . . . . . . . 2
Table 1-1: Default cell groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Table 2-1: Desktop description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Table 2-2: File menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Table 2-3: Edit menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Table 2-4: View menu user options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Table 2-5: Problem menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Table 2-6: Data menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Table 2-7: Tools menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Table 2-8: Configure menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Table 2-9: Shutdown menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Table 2-10: Help menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Table 2-11: Problem Type and Value Filter window - layout . . . . . . . . . . . . . . . . . . . 2-27
Table 2-12: Profile user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Table 2-13: Pop-up menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
Table 2-14: File menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
Table 2-15: View menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
Table 2-16: Problem menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
Table 2-17: Help menu user options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
Table 2-18: Daily Export Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-62
Table 2-19: Configuration file format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-71
Table 2-20: Site health check - supported detectors . . . . . . . . . . . . . . . . . . . . . . . 2-79
Table 2-21: Worst Cells window - menu options . . . . . . . . . . . . . . . . . . . . . . . . . 2-99
Table 2-22: Scoreboard window - menu options . . . . . . . . . . . . . . . . . . . . . . . . . 2-101
Table 2-23: Cell View menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-119
Table 2-24: Cell Grouping pop-up menu options . . . . . . . . . . . . . . . . . . . . . . . . . 2-119
Table 2-25: Thresholds window - menu options . . . . . . . . . . . . . . . . . . . . . . . . . 2-136
Table 2-26: Output file fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-183
Table 2-27: Parameters for scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-193
Table 3-1: Problem list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Table 3-2: Causes investigated by the NHA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Table 3-3: Problem causes - dropped call rate . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Table 3-4: Path balance tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Table 3-5: RF issue tests - dropped call rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Table 3-6: RF issues - high second assignment. . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Table 3-7: Problem causes - low TCH mean holding time . . . . . . . . . . . . . . . . . . . . 3-24
Table 3-8: Problem causes - High immediate assignment failure rate . . . . . . . . . . . . . . 3-27
Table 3-9: Problem causes - Low immediate assignment success rate . . . . . . . . . . . . . . 3-30
Table 3-10: Problem causes - SDCCH RF loss rate . . . . . . . . . . . . . . . . . . . . . . . . 3-32
Table 3-11: Problem causes - OOS timeslots in cell . . . . . . . . . . . . . . . . . . . . . . . 3-43
Table 3-12: Problem causes - high GPROC utilization . . . . . . . . . . . . . . . . . . . . . . 3-49
Table 3-13: Problem causes - high immediate assignment blocking . . . . . . . . . . . . . . . 3-52
Table 3-14: Problem causes - high TCH blocking. . . . . . . . . . . . . . . . . . . . . . . . . 3-54
Table 3-15: Paging overflow - parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56

68P02900W36-P xxi
May 2008 1900.2AS
List of Tables

Table 3-16: Signaling message sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60


Table 3-17: Problem causes - high estimated RSL utilization. . . . . . . . . . . . . . . . . . . 3-61
Table 3-18: Problem causes - low incoming handover success rate . . . . . . . . . . . . . . . 3-69
Table 3-19: Problem causes - low mean time between handovers . . . . . . . . . . . . . . . . 3-72
Table 3-20: Problem causes - low outgoing Inter-RAT handover success . . . . . . . . . . . . . 3-77
Table 3-21: Problem causes - high bit error rate . . . . . . . . . . . . . . . . . . . . . . . . . 3-87
Table 3-22: Problem causes - RF losses out of proportion to traffic carried . . . . . . . . . . . 3-100
Table 3-23: GPRS congestion values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-112
Table 3-24: Problem causes - High GPRS timeslot congestion . . . . . . . . . . . . . . . . . . 3-113
Table 3-25: Problem causes - high GPRS utilization by traffic (uplink) . . . . . . . . . . . . . . 3-119
Table 3-26: Problem causes - high GPRS utilization by traffic (downlink) . . . . . . . . . . . . 3-120
Table 3-27: Problem causes - High PRP load . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-122
Table 3-28: Problem causes - uplink TBF setup success rate . . . . . . . . . . . . . . . . . . . 3-125
Table 3-29: Problem causes - reduced GPRS capacity . . . . . . . . . . . . . . . . . . . . . . 3-128
Table 3-30: Problem causes - high downlink block error rate . . . . . . . . . . . . . . . . . . 3-129
Table 3-31: Problem causes - high DPROC utilization . . . . . . . . . . . . . . . . . . . . . . 3-131
Table 3-32: Problem causes - no statistics from BSS . . . . . . . . . . . . . . . . . . . . . . . 3-136
Table 3-33: Problem causes - no statistics from SITE . . . . . . . . . . . . . . . . . . . . . . 3-140
Table 3-34: Problem causes - database upload required . . . . . . . . . . . . . . . . . . . . . 3-143
Table 3-35: Problem causes - GCLK recalibration required . . . . . . . . . . . . . . . . . . . 3-145
Table 3-36: Problem causes - repeated DRI failure . . . . . . . . . . . . . . . . . . . . . . . . 3-148
Table 3-37: Problem causes - repeated DRI-61-62-63 alarms. . . . . . . . . . . . . . . . . . . 3-150
Table 3-38: Statistics substituted by PMGUI names when implemented . . . . . . . . . . . . . 3-170
Table 3-39: Consolidated problems - value displayed per problem type . . . . . . . . . . . . . 3-177
Table 3-40: Definitions in the problem-threshold.csv file . . . . . . . . . . . . . . . . . . . . . 3-183
Table 3-41: Calculating new thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-186
Table 4-1: NHA directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Table 4-2: Directory structure on the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Table 4-3: Directory structure on the GUI servers or clients . . . . . . . . . . . . . . . . . . . 4-13
Table 4-4: Platform configuration - SUN SunFire V440 and Netra N440 . . . . . . . . . . . . . 4-19
Table 4-5: Content of exported configurable files . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Table 4-6: List of rules calculated by daily exports feature. . . . . . . . . . . . . . . . . . . . 4-38
Table 4-7: Directories in nha_cell_analysis directory . . . . . . . . . . . . . . . . . . . . . . . 4-43
Table 4-8: Monitoring schedule section in ea.cfg file . . . . . . . . . . . . . . . . . . . . . . . 4-55
Table 4-9: NHA default thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
Table 4-10: Required cell statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-65
Table 4-11: Required carrier statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-70
Table 4-12: GPRS statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-71
Table 4-13: Partition locations for backed up file systems . . . . . . . . . . . . . . . . . . . . 4-107

xxii 68P02900W36-P
1900.2AS May 2008
About
This
Manual

System Information: Network Health


Analyst
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

What is covered in 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:

• GSR9 (1900) OMCR


• GSR8 (1800) OMCR
• GSR9 (1900) BSS
• GSR8 (1800) BSS
• GSR7 (1760) BSS

Information about installation and upgrade procedures, including pre-installation, system


checks and NHA system installation, is provided in the NHA Install and Upgrade Guide
which is printed in the same binding as the Software Release Notes: Network Health Analyst
(68P02900W77) manual.

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

Table 1 Manual version history

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)

Resolution of Service Requests

The following Service Requests are now resolved in this manual:

Table 2 Service requests resolved in this manual

Service
CMBP Number Remarks
Request
NA NA NA

Incorporation of Change Notices

The following Change Notices (CN) are incorporated in this document:

CN Date CN Number Title

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

Characters typed in at the keyboard are shown like this.

Output

Messages, prompts, file listings, directories, utilities, and environmental


variables that appear on the screen are shown like this.

68P02900W36-P 3
May 2008 1900.2AS
Text conventions

Special key sequences

Special key sequences are represented as follows:

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Motorola appreciates feedback from the users of our documents.

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.

Questions and comments

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

• The document title, part number, and revision character

• The page number with the error

• A detailed description of the error and if possible the proposed solution

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.

In certain instances, Motorola makes specific recommendations regarding security practices.


The implementation of these recommendations and final responsibility for the security of the
system lies with the operator of the system.

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

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

A note means that there is a possibility of an undesirable situation or provides additional


information to help the reader understand a topic or concept. A note has the following format:

NOTE
Note text.

68P02900W36-P 7
May 2008 1900.2AS
Safety

Safety
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

General safety

The following general safety guidelines apply to Motorola equipment:


• The power jack and mating plug of the power cable must meet International
Electrotechnical Commission (IEC) safety standards.

NOTE
Refer to Grounding Guideline for Cellular Radio Installations – 68P81150E62.

• Power down or unplug the equipment before servicing.

• Using non-Motorola parts for repair could damage the equipment or void warranty.
Contact Motorola Warranty and Repair for service and repair instructions.

• Portions of Motorola equipment may be damaged from exposure to electrostatic discharge.


Use precautions to prevent damage.

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.

• Council recommendation of 12 July 1999 on the limitation of exposure of the general


public to electromagnetic fields (0 Hz to 300 GHz) (1999/519/EC) and respective national
regulations.

• 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

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.

Disposal of Motorola equipment

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.

Disposal of surplus packaging

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

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.

The label is placed in a customer visible position on the product.


• Logo 1 means the product contains no substances in excess of the maximum concentration
value for materials identified in the China Management Methods regulation.

• 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

Motorola document set


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

The Motorola document sets provide the information to operate, install, and maintain the
Motorola equipment.

Ordering documents and CD-ROMs

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.

Document banner denitions

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

Overview of the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

68P02900W36-P 1-1
May 2008 1900.2AS
Overview of the NHA Chapter 1: Overview of the NHA

Overview of the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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:

• GSR9 (1900) OMCR


• GSR8 (1800) OMCR
• GSR9 (1900) BSS
• GSR8 (1800) BSS
• GSR7 (1760) BSS

The NHA performs a real-time analysis of event and statistic information to detect faults,
covering areas such as:
• Call success rate

• Immediate assignment failure rate

• SDCCH RF loss rate

• Repeated cell outage

• Repeated DRI failure

• Low call activity

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.

Figure 1-1 NHA process illustration

N
O
H
M
A
C

68P02900W36-P 1-3
1900.2AS May 2008
Problem detection and monitoring Chapter 1: Overview of the NHA

Problem detection and monitoring


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to problem detection

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

• NHA detection mechanisms on page 1-8

• NHA problem clearing mechanisms on page 1-21

• Automatic blacklisting on page 1-24

• NHA detection examples on page 1-25

• Cell grouping in the NHA on page 1-30

1-4 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detection process

Problem detection process


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the 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.

Conrmation

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

Devices monitored by 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

Figure 1-2 NHA problem detection process

PROBLEM TO US ER INTERFACE

CORRECTIVE ACTION

CAUSE

CAUSE ANALYS IS

PROBLEM

CONFIRMATION

ANOMALY

DETECTIO N

DATA FROM OMC

68P02900W36-P 1-7
1900.2AS May 2008
NHA detection mechanisms Chapter 1: Overview of the NHA

NHA detection mechanisms


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to NHA detection mechanisms

NHA detectors use the following detection mechanisms to find problems in a network:
• Daily Roll-up on page 1-9

• Fixed Threshold on page 1-11

• Sample Roll-up on page 1-13

• Interval Roll-up on page 1-15

• Sliding scale on page 1-17

• Long-term detection on page 1-19

• Event pattern analysis on page 1-20

1-8 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Daily Roll-up

Daily Roll-up
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

The daily roll-up detection mechanism comprises the following:


• Formula (F) calculated over 24 hours.

• Minimum sample size (S) to rule out false alarms.

• Threshold value (T).

Formula

The formula (F) is constructed as follows, where A and B are statistics:


Total A x 100%
---------
Total B

Detection

The detection works as follows:


If the Total of B is greater than (>) the minimum sample size (S), then calculate
F, if the result of F is greater than (>) the threshold (T), then raise the
problem.

68P02900W36-P 1-9
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA

Figure 1-3 Daily roll-up detection

00.30 01.00 01.30 02.00 02.30... ... 00.00

midnight to midnight

1-10 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Fixed Threshold

Fixed Threshold
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

The Fixed Threshold detection mechanism comprises the following:


• Formula (F) calculated over the last interval.

• Threshold value (T).

• Repeat count intervals (I).

Formula

The formula (F) is constructed as follows, where A and B are statistics:


Total A
-------
Total B

Detection

The detection works as follows:


Calculate F, if the result of F is greater than (>) the threshold (T) for I
number of intervals, then raise the problem.

68P02900W36-P 1-11
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA

Figure 1-4 Fixed Threshold detection

00.30 01.00 01.30 02.00 02.30 03.00 03.30

F>T F>T F>T

Repeats for I intervals

1-12 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sample Roll-up

Sample Roll-up
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

The Sample Roll-up detection mechanism comprises the following:


• Formula (F) used when the sample size is reached.

• Minimum sample size (S).

• Threshold value (T).

Formula

The following is an example of a simple dropped calls formula (F):


Dropped Calls
---------------
Number of calls

Detection

The detection works as follows (using the dropped calls scenario):


Collect intervals until the minimum sample of calls is reached (S), or if the
limit of 24 intervals is reached (the detector then quits), then calculate F, if
the result of F is greater than (>) the threshold (T), then raise the problem.

68P02900W36-P 1-13
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA

Figure 1-5 Sample Roll-up detection

10.30 11.00 11.30 12.00 12.30 13.00 13.30

300 300 600

roll-up until sample size of


1000 is reached

1-14 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Interval Roll-up

Interval Roll-up
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

The Interval Roll-up detection mechanism comprises the following:


• Formula (F).

• Minimum sample size (S).

• Threshold value (T).

• Number of hours (H).

Formula

The formula (F) is constructed as follows, where A and B are statistics:


Total A
-------
Total B

Detection

The detection works as follows:


Over H Hours, if the Total of B is greater than (>) the minimum sample size (S),
then calculate F, if the result of F is greater than (>) the threshold (T), then
raise the problem.

68P02900W36-P 1-15
1900.2AS May 2008
Detector components Chapter 1: Overview of the NHA

Figure 1-6 Interval Roll-up detection

14.30 15.00 15.30 16.00 16.30 17.00 17.30

Continuous monitoring every


interval over the H Hours

1-16 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sliding scale

Sliding scale
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

This detection mechanism consists of:


• Low sample size

• Low sample threshold

• High sample size

• High sample threshold

• Repeat count intervals

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

Figure 1-7 Threshold level decreased for a “greater than” comparison

55 Threshold
High Sample Reached
Threshold

Threshold
NOT
Reached

5
Low Sample
Threshold

50 1000
Low Sample High Sample
Size Size

Figure 1-8 Threshold level increased for a "less than" comparison

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of 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.

Two methods are used for long term detection:


• 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 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 pattern analysis


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of event pattern analysis

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

NHA problem clearing mechanisms


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

• Default event based clearance

• Default Immediate Type clearance

• Default Very Fast Type clearance

• Default Daily clearance

• Default Hourly clearance

• Default End of Next Working Day 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.

Knowledge based clearance

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

Default event based clearance

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.

Default immediate type clearance

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.

Default very fast type clearance

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.

Default daily type clearance

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

Default hourly clearance

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.

Default end of next working day clearance

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Initial automatic blacklist

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.

Automatic blacklist maintenance

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

NHA detection examples


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to NHA detection examples

This section provides information about the following topics:


• The GSM call process model

• Example of NHA detecting network faults

• Example of a daily roll-up detector firing

The GSM call process model

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

Figure 1-9 Call process model

Example of a network fault

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

Figure 1-10 Immediate Assignment Failure Rate

Mobiles use SDCCH signaling channels to:


• Make a call

• Receive a call

• Update location

• Send and receive SMS messages


TCH (Traffic Channels) are used to carry encoded speech or user data.

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:

Immediate Assignment Failures * 100%


-------------------------------------
Channel requests

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

Examples of the NHA detecting network faults

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

• Very High Immediate Assignment Failure Rate

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.

High Daily Immediate Assignment Failure Rate

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.

Figure 1-11 Daily detection

Threshold

Network fault started NHA raises Network fault NHA clears


problem resolved problem

30%

Day 1 Day 2 Day 3 Day 4

1-28 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Examples of the NHA detecting network faults

Very High Immediate Assignment Failure Rate

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.

Figure 1-12 Interval based detection

Thresholds NHA raises problem NHA clears problem

Network fault Network fault


started resolved

60%

06:00 12:00 18:00 24:00

68P02900W36-P 1-29
1900.2AS May 2008
Cell grouping in the NHA Chapter 1: Overview of the NHA

Cell grouping in the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to NHA cell groups

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.

Dividing cells into groups

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.

Table 1-1 Default cell groups

Default Cell
Denition 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

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.

Figure 1-13 Default cell groups

BUSY

FRINGE

QUIET

DEFAULT GROUP NORMAL

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

Using the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

68P02900W36-P 2-1
May 2008 1900.2AS
Using the NHA Chapter 2: Using the NHA

Using the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

This chapter describes the key functions of the NHA UI.


• Starting the NHA user interface on page 2-3

• The Problem window on page 2-8

• Using the In Service Monitor (INSM) tool on page 2-84

• Configuring the NHA on page 2-104

• Editing Knowledge on page 2-162

2-2 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Starting the NHA user interface

Starting the NHA user interface


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Starting the UIs on a GUI server or client with menu

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.

Starting the UIs on a GUI server or client without menu

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.

2. Run the following commands on the GUI server or client:

setenv DISPLAY <terminal IP address>:0.0

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.

Starting the user interfaces on a PC

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.

Copying and pasting

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

Permissions and security


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to NHA 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.

NHA UI Client Login

Introduction to NHA UI Client Login feature

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.

Using the NHA UI Client Login feature

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

Figure 2-1 NHA UI Client login window

Security access

An NHA operator with read-only permissions is unable to:


• Create, modify, or delete cell groups, detectors and thresholds.

• Import thresholds, detectors, group names.

• Add and remove devices from the Blacklist.

• Create, modify, or delete subscriptions.

• Create, modify, delete user-defined causes.

• Turn on problems to the OMC as alarms.

• Create, modify, or delete custom detectors and custom formula in the Knowledge Editor.

• Set a time for a Daily export.

• Schedule OOS reports.

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.

• Start and shut down the NHA.

68P02900W36-P 2-7
1900.2AS May 2008
The Problem window Chapter 2: Using the NHA

The Problem window


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Problem window

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

• The Problem window menu options on page 2-13

• Subscriptions, sorting, and filtering on page 2-18

• The Problem pop-up menu on page 2-30

• Problem Information window on page 2-32, including:


Problem causes and corrective action

Line of reasoning

Detector information

Other device, neighbor and site problems

• Viewing statistics history and event history on page 2-41

• Viewing long term statistics and other problem information on page 2-51

• Exporting and printing problem reports on page 2-59

• Summary report of problems detected on page 2-63

• The NHA web page on page 2-65

2-8 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Problem window

Using the Problem window


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of 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.

This section provides information about the following topics:


• Multi-OMC support

• Displaying problems

• Managing problems

• Repeating problems

• Values of problems

• Ranking problems

• Sending messages to other NHA users

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.

Figure 2-2 Problem window - displaying problems

It also displays the following information across the bottom of the window (refer to Table 2-1):

Table 2-1 Desktop description

Desktop icon Function


Total The number of problems within the NHA on the subscription
being viewed.
Filter The number of problems remaining on the problem window after
the filter has been activated.
Unsorted Toggles to Sorted if the sort function is used.
Unfiltered Toggles to Filtered if the filter function is used.
New Problem This box is ticked if new problems appear on the display since
the last time it was unticked.

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.

If a problem is Handled, the operator's username appears in the Operator column as in


Figure 2-2.

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.

Filtering and sorting

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;

2. The Dropped Call Rate is higher;

3. The Total Calls is higher.

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.

Sending messages to all other NHA users

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.

• To check if other users are aware of problems or changes to a site or cell.

2-12 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The Problem window menu options

The Problem window menu options


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of menu options

The following overview describes the user options available in each menu on the main Problem
window.

File menu

The File menu user options are displayed in Table 2-2:

Table 2-2 File menu user options

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

The Edit menu user options are displayed in Table 2-3:

Table 2-3 Edit menu user options

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

The View menu user options are displayed in Table 2-4:

Table 2-4 View menu user options

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

The Problem menu user options are displayed in Table 2-5:

Table 2-5 Problem menu user options

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

The Data menu user options are displayed in Table 2-6:

Table 2-6 Data menu user options

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

The Tools menu user options are displayed in Table 2-7:

Table 2-7 Tools menu user options

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

Congure menu

The Configure menu user options are displayed in Table 2-8:

Table 2-8 Congure menu user options

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

The Shutdown menu user option is displayed in Table 2-9:

Table 2-9 Shutdown menu user options

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

The Help menu user options are displayed in Table 2-10:

Table 2-10 Help menu user options

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, sorting, and ltering


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to managing lists of problems

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.

• Using a problem subscription, consisting of a set of problem types to be monitored.

Lists of problems can also be filtered and sorted on the Problem window using the following
menu options:
• Filter

• Sort

Using REGIONS to monitor the problem list

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.

Using problem subscriptions to monitor problem list

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.

For further information on creating, viewing or modifying problem subscriptions, refer to


Configuring problem subscriptions on page 2-148 in this chapter.

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

Figure 2-3 Filter window (partial view)

2-20 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Filtering problems

The following abbreviations are used on the Filter window:

Inc. Include
Exc. Exclude
Bef. Before
Aft. After

Problems are filtered by:


• OMC

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.

• Time (using First Time/Last Time filters)

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.

The Last Time filter has the following extra options:


Last 35 mins

Last 65 mins

Last 125 mins

Last 185 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

• Problem Type and Value

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.

Comments can also be filtered by selecting:


Problem(s) with comment: to display problems that have comments.

Problem(s) without comment: to display problems that do not have comments.

Using the Recent Problems lter

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

• Last 125 mins

• Last 185 mins

• Off (default mode)


When the Recent Problems filter is applied, only problems that have been raised in the last
selected time period are displayed in the Problem window. The options on the pull-down menu
are synchronized with the “Last Time” options on the Filter window. For example, if “Last 65
mins” is selected from the pull-down menu, the same setting is shown on the Filter window.

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.

To sort problems, use the following steps:

Procedure 2-1 Sorting problems

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

Procedure 2-1 Sorting problems (Continued)

Figure 2-4 Sort window

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

Filtering problem types and values


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Problem Type and Value Filter

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.

Using the Problem Type and Value Filter

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)

• Upper Threshold Value (for Path Balance)

• Threshold Value Cpu Mean (for High DPROC utilization)

• Threshold Value Cpu Mean (for High GPROC utilization)

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

Figure 2-5 Problem Type and Value Filter window

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 proles Chapter 2: Using the NHA

User proles
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the User Prole feature

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.

Figure 2-6 Congure menu - Prole option

2-28 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Prole feature

The Profile user options are displayed in Table 2-12.


Table 2-12 Prole user options

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.

Using the Prole feature

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

The Problem pop-up menu


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Problem pop-up menu

Right click a problem row in the Problem window to display the Problem pop-up menu for
that problem (refer to Figure 2-7).

Figure 2-7 Problem window and pop-up menu

Pop-up menu options

In addition to the Handle/Unhandle, Clear/Unclear, and Unseen options outlined in The


Problem window menu options on page 2-13, the pop-up menu also provides the following
functions as in Table 2-13:

2-30 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Pop-up menu options

Table 2-13 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

Problem Information window


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Problem Information window

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

• Access additional data such as Statistics History and Neighbors

• Run Action and Cause Action scripts

• Manage the problem list

• Import or export problem data

Figure 2-8 The Problem Information window

2-32 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the Problem Information window

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.

• Other Problems on Device


Displays other problems on the device on which the selected problem has occurred.

• Problems on Neighbors
Displays other problems on neighbors.

• Problems on Site
Displays other site problems.

Menu options on the Problem Information window

The following overview describes the user options available in each menu on the Problem
Information window.

File menu

The File menu user options are displayed in Table 2-14:

Table 2-14 File menu user options

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

The View menu user options are displayed in Table 2-15:

Table 2-15 View menu user options

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

The Problem menu user options are displayed in Table 2-16:

Table 2-16 Problem menu user options

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

The Help menu user options are displayed in Table 2-17:

Table 2-17 Help menu user options

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

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

Other device, neighbor and site problems

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

Changing the status of a problem using the Seen option


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Using the Seen option

The Seen option is available from:


• The Problem window.

• The Problem popup window.

• Automatically performed on problem selection.

The status of the problem automatically changes to SEEN on selection.

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.

• The status of the problem reverts to NEW.

68P02900W36-P 2-37
1900.2AS May 2008
Using the Seen option Chapter 2: Using the NHA

Figure 2-9 Selecting Unseen

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to Comment option

The Comment option allows users to add and modify comments for any problems selected
on the NHA UI.

Using the Comment option

The Comment option can be launched from the NHA UI as follows:


• From the Problem menu

• From the Problem popup menu

Adding a new comment

To add a new comment to a problem, use the following steps:

Procedure 2-2 Adding a new comment

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

Procedure 2-2 Adding a new comment (Continued)

Figure 2-10 Selecting the Comment option

2 Type any comment into the text area.


3 Click OK to save comment or Cancel to cancel the operation.

Modifying an existing comment

To modify an existing problem comment, use the following steps:

Procedure 2-3 Modifying a comment

1 Right click the required problem row to display the pop-up


menu and select the Comment option from the pop-up menu.
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 is displayed.
2 Edit the comment in the text area.
3 Click OK to save comment or Cancel to cancel the operation.

2-40 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing statistics history and event history

Viewing statistics history and event history


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to statistics 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.

Viewing statistics history for a problem

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.

• Statistics History - Neighbor


Select this option to view the statistics of neighbor cells for the selected cell.

• Statistics History - Cell & Neighbor - Single Interval


Select this option to view the statistics for the selected cell and its neighbors for
a specific interval.

• Statistics History - Cell & Neighbor - Single Statistic


Select this option to view a single statistic over 24 intervals for the selected cell
and its neighbors.

Viewing statistics history for a problem cell

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

Figure 2-11 Statistics History - Cell window

Changing to different views

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.

Viewing statistics history for a neighbor

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

Figure 2-12 Statistics History - Neighbor window

Conguring 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.

Viewing statistics history for a single interval

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

Figure 2-13 Cell & Neighbor - Single Interval window

Conguring 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.

Viewing statistics history for a single statistic

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

Figure 2-14 Cell & Neighbor - Single Statistic window

Conguring 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.

Exporting and printing statistics data

Use the following procedures to print or export statistics data.

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
Conguring statistics Chapter 2: Using the NHA

Figure 2-15 Exporting to a le

Conguring 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:

Procedure 2-4 Selecting additional cell statistics

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.

3 Select a statistic from the Available column, as shown in Figure 2-16.


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.

2-46 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring statistics

Figure 2-16 Statistics Selection window

68P02900W36-P 2-47
1900.2AS May 2008
Conguring 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.

Figure 2-17 Carrier Statistics window

2-48 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing event history

Neighbor cell statistics

To select neighbor cell statistics for the problem, use the following steps:

Procedure 2-5 Selecting neighbor cell statistics

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.

Figure 2-18 Neighbor Cell Statistics Selection window

Viewing 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.

68P02900W36-P 2-49
1900.2AS May 2008
Viewing event history Chapter 2: Using the NHA

The available options available are:


• First to screen: Select this option to display the event history for the 24 hours before the
problem was first raised.

• 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

Viewing long term statistics and other problem


information
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to long term statistics

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.

By default, only the following key statistics are exported daily:


• Call Setup Success Rate

• Call Volume

• Drop Call Rate

• Mean Time Between Drop Calls

• Traffic Carried

Conguring additional key statistics for daily export

The list of default key statistics cannot be modified or deleted. However,


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 -l as shown in the following example:

Usage: lgConfig [ -arl ]


Options:
-a Adds keystats for long term monitoring by NHA.
-r Removes keystats that have been configured for long term monitoring by NHA.
-l Prints a list of all keystats already configured for long term
monitoring by NHA.

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

Viewing long term statistics

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.

Figure 2-19 Viewing long term statistics

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.

The available options available are:


• First to screen: Select this option to display the event history for the 24 hours before the
problem was first raised.

• 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.

68P02900W36-P 2-53
1900.2AS May 2008
Viewing a list of Neighbor cells Chapter 2: Using the NHA

Viewing a list of Neighbor cells

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.

Figure 2-20 Neighbors window

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

Figure 2-21 BSS Remote Login Dialog

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

Figure 2-22 Selecting the Action Scripts option

Once the script is selected, a confirmation window is displayed before the script is initiated as in
Figure 2-23. Click Yes to continue.

Figure 2-23 Conrm execution of Action Scripts

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.

Previous problems on this device

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.

The following is an example of the output of a problem_history.sh script:

Problem History Report:


Tue Apr 26 11:28:48 GMT 2005 BSS_Cork_4 Site_1 543-21-333-333
====================================
22/03/2005 00:23 | High daily DROPPED CALL rate | 5.9
22/03/2005 00:23 | Low daily INTRA BSS HANDOVER success rate| 33.6
21/03/2005 13:24 | Very low INTRA-BSS HANDOVER success rate | 29.6
21/03/2005 12:23 | Very low INTRA-BSS HANDOVER success rate | 25.0
21/03/2005 11:24 | Very low INTRA-BSS HANDOVER success rate | 30.5
21/03/2005 10:24 | Very low INTRA-BSS HANDOVER success rate | 43.2
21/03/2005 09:24 | Very low INTRA-BSS HANDOVER success rate | 39.0
21/03/2005 00:23 | High daily DROPPED CALL rate | 3.2
21/03/2005 00:23 | Low daily INTRA-BSS HANDOVER success rate | 64.2
18/03/2005 18:24 | High Immediate Assignment Blocking Rate | 10.2
18/03/2005 17:24 | High Immediate Assignment Blocking Rate | 13.5
15/03/2005 00:23 | High daily DROPPED CALL rate | 3.568
11/03/2005 00:23 | High daily DROPPED CALL rate | 3.172

68P02900W36-P 2-57
1900.2AS May 2008
Adding to the blacklist Chapter 2: Using the NHA

Statistics viewing from OMC PM GUI

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.

Adding to the blacklist

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.

Printing problem details from the Problem pop-up menu

To print problem details, select the Print Problem option from the Problem pop-up menu.
Select a printer and click OK.

Exporting problem details from the Problem pop-up menu

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

Exporting and printing problem reports


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to exporting problems

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:

/usr/gsm/OMCs/<omcname>/ea_logs/DailyExport<mmdd-hhmmss>.csv (OMC specific)


/usr/gsm/config/local/<omcname>-daily.csv (OMC specific)
/usr/gsm/config/local/daily.csv (All OMCs)

Every 15 minutes, all the problems active at that time are automatically exported to files as
follows:

/usr/gsm/config/local/<omcname>-current.csv (OMC specific)


/usr/gsm/config/local/current.csv (All OMCs)

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

Printing a list of problems

Click the Print button to print the list of problems in the Problem window.

Loading export les into Excel

The following is a suggested method for taking NHA export files and loading them into Microsoft
Excel.

For single OMC

For a single OMC, use the following steps:

Procedure 2-6 Loading export les into Excel - single OMC

1 Extract the problems displayed on the Problem window by pressing the


Export button.
2 Transfer this export file to an area which the PC can access.
3 Transfer the NHA macro -
/usr/gsm/current/ea_tools/nha-1pagemacro.xls to an area which
the PC can access.
4 Start Microsoft Excel.
5 Open NHA macro.
6 Open the export file.
7 Select Ctrl+A.
Or, select Tools - Macro - Macros.

Select the nha-1pagemacro.xls and Run.

For multiple OMCs

For multiple OMCs, use the following steps:

Procedure 2-7 Loading export les into Excel - multiple OMCs

1 Transfer this export file to an area which the PC can access.


2 Transfer the NHA macro - /usr/gsm/current/ea_tools/nha-multi-omcs.xls
to an area which the PC can access.
3 Start Microsoft Excel.
4 Open NHA macro

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.

Select the nha-multi-omcs.xls and Run.

Importing problems into spreadsheets

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:

% sed 's/,/<TAB>/g' filename.csv > filename.txt

Modifying the macro

The macro is created in Visual Basic. To modify the macro, perform the following steps in
Microsoft Excel:

Procedure 2-8 Modifying the macro

1 Open the macro file, nha-1pagemacro.xls, by selecting Tools àMacro à


Macro.
2 Select the ReportReplace macro.
3 Click the Edit button.
From this point, it is possible to edit the macro to create the required
changes.
4 Click Save to save any changes made to the document.

Abbreviations used in the Daily Export Report

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

Table 2-18 Daily Export Report

Field name Description


Problem Contains the problem name.
Val Contains the value associated with the problem,
for example, Call Setup Success Rate = 69.9%.
Note: No values given for Database upload; Device not in MIB; GCLK
recalibration; Repeated Cell Outages or Repeated DRI failures.
Int The number of intervals per statistics used for detecting a problem. This
number is generally 24 for daily problems and the interval count for the
’Very’ problem. A low number of intervals counts indicates a busy cell.
First The first time and date that the NHA detected the problem.
Last The last time and date that the NHA detected the problem.
Rpt The number of times that the problem has repeated. For example, Daily
Problems the number given refers to days.
BSS The BSS (or RXCDR) that the problem is related to.
Site The Site that the problem is related to.
Cell/Devices The Cell or DRI that the problem relates to.
Group The NHA cell group that problem cell relates to, for example, NO-GRP
= no group for event based problems (database upload, GCLK
recalibration, repeated outages) or NONE = No group for No stats from
BSS or no stats from site.
Status The current status of the problem, for example, NEW = new problem,
HANDLED = handled problem, CLEARED = cleared problem, SEEN
= seen problem.
Severity The severity of the problem.
Causes The cause name of the problem and a mnemonic for the Confidence
Factor, for example, V.High = Very High Confidence; High = High
Confidence; Medium = Medium Confidence; Low = Low Confidence.
Comment The current comment of the problem.

2-62 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Summary report of problems detected

Summary report of problems detected


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of the summary report

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.

A sample report is provided as follows:

NHA Summary Report 20021201


---------------------------
TABLE 1 : NUMBER OF PROBLEM CELLS
OMC1 OMC2 OMC3 OMC4
Low Call Setup Success Rate 3 1 2 17
High daily Dropped Call Rate 0 1 0 0
High daily SDCCH RF Loss Rate 1 1 0 0
Low Immediate Assignment Success Rate 0 0 11 0
Low Incoming Handover Success 22 23 24 62
Low Mean Time Dropped Calls 15 9 41 30
Low TCH Mean Holding Time 2 0 10 6
Low Inter-BSS handover succ. 7 11 4 12
Low Intra-BSS handover succ. 10 15 27 62
Low IntraCell handover succ. 1 2 4 3

TOTAL DAILY PROBLEMS DETECTED 73 63 123 192

TABLE 2 : WORST VALUES OF PROBLEMS DETECTED


OMC1 OMC2 OMC3 OMC4
Low Call Setup Success Rate 84.2 83.8 81.3 79.9
High daily Dropped Call Rate - 10.25 - -
High daily SDCCH RF Loss Rate 7.28 8.62 - -
Low Immediate Assignment Success Rate - - 12.3 -
Low Incoming Handover Success 24.2 10.5 10.2 1.1
Low Mean Time Dropped Calls 430 302 150 360
Low TCH Mean Holding Time 13.2 - 12.6 13.7
Low Inter-BSS handover succ. 62.6 34.0 70.3 0.3
Low Intra-BSS handover succ. 71.9 26.5 24.8 13.5
Low IntraCell handover succ. 38.3 50.7 32.9 0.2

68P02900W36-P 2-63
1900.2AS May 2008
Overview of the summary report Chapter 2: Using the NHA

TABLE 3 : NUMBER OF BUSY PROBLEM CELLS


OMC1 OMC2 OMC3 OMC4
Low Call Setup Success Rate 0 1 1 9
High daily Dropped Call Rate 0 0 0 0
High daily SDCCH RF Loss Rate 0 0 0 0
Low Immediate Assignment Success Rate 0 0 3 0
Low Incoming Handover Success 2 1 1 8
Low Mean Time Dropped Calls 3 0 5 8
Low TCH Mean Holding Time 0 0 4 9
Low Inter-BSS handover succ. 4 1 1 4
Low Intra-BSS handover succ. 5 1 5 6
Low IntraCell handover succ. 1 0 0 1

BUSY DAILY PROBLEMS DETECTED 18 4 21 45

The script is found at /usr/gsm/current/ea_tools/execscript. Administrators can modify the


script to produce different output formats, if necessary. It can also be modified to send the
report by E-mail to a distribution list.

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

The NHA web page


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of 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.

Figure 2-24 Default NHA web page

68P02900W36-P 2-65
1900.2AS May 2008
Links Chapter 2: Using the NHA

Links

The NHA web page comprises three main sections:


• NHA Network Issue Reports

• NHA Administration Reports

• NHA Help Pages

NHA network issue reports

This section provides links to network issue reports as follows:

Long Term Statistics Analysis

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.

The following reports are produced for each OMC:


• Increased Call Volume

• Increased Drop Call Rate

• Trend in Call Setup Success Rate

• Trend in Drop Call Rate

• Reduced Call Setup Success Rate

• Reduced Call Volume

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.

Latest Problems Reports

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.

Daily Problem Report

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.

Frequency Clash 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.

NHA Parameter Checking Report

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.

NHA administration reports

This section provides links to NHA administration reports as follows:

NHA System Status

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.

NHA Health Report

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

NHA help pages

This section provides links to the following NHA web pages:

NHA Online Help

This hyperlink links to the online help pages of the NHA.

NHA Problem Information Views

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.

Instructions for Installing the NHA UI client on a PC

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

Parameter Check Report


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the 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

The Parameter Check Report performs two types of check:


• Simple checks

• 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 conguration 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:

bts_power_control_allowed=1 AND l_rxlev_dl_p>30


bts_power_control_allowed=1 AND u_rxlev_dl_p>35
bts_power_control_allowed=1 AND u_rxqual_dl_p=0

The Parameter Check conguration le

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.

• Add new simple Type A parameter checks.

• Delete or disable simple Type A parameter checks.

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.

Conguration le format

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 conguration le

Table 2-19 Conguration le format

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 conguration 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

Adding a new simple parameter check

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.

Deleting or disabling simple parameter checks

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

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.

Figure 2-25 Example of a 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

• Yellow: Medium severity

• Black: Lowest severity


A key to these color codes is provided at the bottom of the Parameter Check Report.

Viewing a text report

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.

Saving the report as a text le

It is possible to save the Parameter Check Report as a plain text file when viewing the text report:

Procedure 2-9 Saving the Parameter Check Report as a text le

1 From the File menu, select Save As.


2 Choose Text File (*.txt) in the Save as type field.
3 Specify the path and name in the File name: field and click Save.

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

Site Health Check


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to Site Health Check

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.

Using Site Health Check

The Site Health Check can be launched from the NHA UI as follows:

• From the Problem pop-up menu.

If the selected row is BSS only, the option is disabled.

• From the Cell View window.

• From the Blacklist window.

If the selected row is BSS/RXCDR, the option is disabled.

To perform a Site Health Check from the Problem window, Cell View or Blacklisted Devices
windows, use the following steps:

Procedure 2-10 Performing a Site Health Check

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:

• If Last interval is selected, the non-daily roll-up detector thresholds


are used; otherwise, the daily roll-up detector thresholds are used. For
example: If Last interval is selected, the Very Low Call Setup Success
Rate detector threshold is used.

• If Last 24 intervals is selected, the Low Daily Call Setup Success


Rate detector threshold is used.

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

Viewing the Site Health Check report

The results of the site health check are output in HTML format to the browser window as
in Figure 2-27.

Figure 2-27 Site Health Check report

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

Detector group Detectors


Call Success Call Setup Success Rate
Dropped Call Rate
Second Assignment Rate
TCH Mean Holding Time
Mean Time Between Drop Calls
Immediate Assignment Immediate Assignment Failure Rate
Immediate Assignment Success Rate
SDCCH RF Loss Rate
Outage Call Activity
Channel Requests But No Calls
Number of Mobile Terminated Calls
Out of Service Timeslots in Cell
TCH Usage
Overload Immediate Assignment Blocking Rate
TCH Blocking at Call Setup Rate
Paging Overflow Rate
Handover Incoming Handover Success Rate
Outgoing Intra-Cell Handover Success Rate
Outgoing Intra-BSS Handover Success Rate
Outgoing Inter-BSS Handover Success Rate
Handover Success Rate to PGSM900
Handover Success Rate to EGSM900
Handover Success Rate to GSM1800
Handover Attempt Rate - Power Budget
Handover Attempt Rate - Uplink Quality
Handover Attempt Rate - Uplink Level
Handover Attempt Rate - Downlink Quality
Handover Attempt Rate - Downlink Level
Handover Attempt Rate - Distance
Handover Attempt Rate - Uplink Interference
Handover Attempt Rate - Downlink Interference
Handover Attempt Rate - Congestion
Handover Attempt Rate - Adjacent Channel
Interference

Continued

68P02900W36-P 2-79
1900.2AS May 2008
Supported detectors Chapter 2: Using the NHA

Table 2-20 Site health check - supported detectors (Continued)


Detector group Detectors
Handover Attempt Rate - Band Reassign
Handover Attempt Rate - Interband
Handover Mean Time Between Handovers
Inter-BSS Handover Attempt Rate
Outgoing Inter-RAT Handover Success Rate
GPRS Uplink TBF Setup Success Rate
GPRS utilization by Traffic (Uplink)
GPRS utilization by Traffic (Downlink)
GPRS utilization by Allocation (Uplink)
GPRS utilization by Allocation (Downlink)
GPRS Requests but no Data
GPRS Congestion
Downlink Block Error Rate

Note the Site Health Check does not include customized detectors or the following script-based
detectors:
• One-Way MTL

• Low Activity in Timeslot

• High Interference On Idle

• High BER Imbalance on Odd Even Timeslots

• High RF Losses Imbalance on Odd Even Timeslots

• Device Out of Service

• BSS-Level Detectors

• Consolidated Problems

2-80 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst BSS Detector Check

BSS Detector Check


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Using the BSS Detector Check

The BSS Detector Check can be launched from the NHA UI in the following ways:
• From the Problem pop-up menu.

The option is disabled if the selected row is RXCDR.

• From the Cell View window.

• From the Blacklist window.

The option is disabled if the selected row is RXCDR.


To perform a BSS Detector Check from the Problem window, Cell View or Blacklisted Devices
windows, right click the required problem row to display 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

Viewing the BSS Detector Check report

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

• Call Setup Success Rate

• Drop Call Rate

• Call Success Rate

• Immediate Assignment Success Rate

• RF Assignment Success Rate

• Mean Time Between Drop Calls

• TCH RF Loss Rate

• SDCCH RF Loss Rate

• Immediate Assignment Blocking Rate

• TCH Blocking at Call Setup Rate

• TCH Blocking Rate

• SDCCH Blocking Rate

• Intra-Cell Handover Success Rate

• Outgoing Inter-Cell Handover Success Rate

• Outgoing Intra-BSS Handover Success Rate

• Outgoing Inter-BSS Handover Success Rate

68P02900W36-P 2-83
1900.2AS May 2008
Using the In Service Monitor (INSM) tool Chapter 2: Using the NHA

Using the In Service Monitor (INSM) tool


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the INSM tool

The INSM tool is used to monitor the network. It provides:


• A summary of the status of all RF devices in the network.

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

• Configuration reports on the status of devices.

• Reports on out-of-service devices.

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.

Common INSM procedures

This section describes how to use the INSM tool:


• Viewing the status of network devices on page 2-85

• Viewing INSM reports on page 2-89

• Manually blacklisting a device on the network display on page 2-95

2-84 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing the status of network devices

Viewing the status of network devices


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the INSM graphical display

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)

• Remote transcoders (RXCDRs)

• Sites (BTSs)

• Cells

• Receive Transmit Functions (RTFs)

• Digital Radio Interfaces (DRIs)

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:

For all devices under the BSS/RXCDR

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.

Sites and Cells

If Then
BUSY and UNLOCKED and containing BSS or RXCDR Site or Cell is INS.
is INS
All else Site or Cell is OOS.

BSSs and RXCDRs

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.

Figure 2-29 INSM network display

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

Viewing INSM reports


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to INSM reports

INSM reports identify the states of RF devices in a GSM network. This section describes the
following tasks:
• Displaying a configuration report

• Displaying an OOS report

• Displaying a historical OOS report

• Scheduled OOS reports

Displaying a conguration report

This report provides a graphical display of the associated Sites, Cells, RTFs, and DRIs for
a selected BSS.

To display a configuration report, use the following steps:

Procedure 2-11 Displaying a conguration report

1 Select Show Network Display from the INSM menu.


2 Click a device in the Network Display. A pop-up menu is displayed as in
Figure 2-31.
3 Select Configuration Report to display a configuration report for the
highlighted device, as shown in Figure 2-30.

68P02900W36-P 2-89
1900.2AS May 2008
Displaying an OOS report Chapter 2: Using the NHA

Figure 2-30 Conguration report window

Displaying an OOS report

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.

To display an out-of-service (OOS) report, use the following steps:

Procedure 2-12 Displaying an OOS report

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

Procedure 2-12 Displaying an OOS report (Continued)

Figure 2-31 Options pop-up menu

3 Select OOS Report, then choose All or Selection.

• OOS Report (All)


All displays a report of all out-of-service NE devices under
the selected BSS as in Figure 2-32.

• OOS Report (Selection)


Selection displays a report of the out-of-service
devices under and including the device selected. For example, if an
RTF is selected, any OOS RTFs are reported.

Figure 2-32 Example OOS Report (All)

68P02900W36-P 2-91
1900.2AS May 2008
Displaying a historical OOS report Chapter 2: Using the NHA

Displaying a historical OOS report

The INSM tool produces reports giving all the OOS information applicable to a device. To
produce a historical OOS report, use the following steps:

Procedure 2-13 Displaying a historical OOS report

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.

• All available - ALL available OOS information.

• Last 24 Hours - OOS information for the last 24 hours.

• Yesterday - OOS information for yesterday.


4 Click OK to create the report.

The report is presented in a UNIX text editor window as in the following


sample. It shows the devices that were OOS in the selected period of time.
For each device, the report shows the number of minutes per statistics
interval that the device was OOS. The units for outages are in minutes. The
following is an example of an output of a historical OOS report:

BSS_A / Site_21 / 123-45-6789-12345


Total OOS Time = 3.4
11/06/2004 06:00:00 - 3.4

BSS_A / Site_25 / 123-45-9876-54321


Total OOS Time = 66.4
11/06/2004 19:00:00 - 0.5
11/06/2004 18:30:00 - 15.7
11/06/2004 18:00:00 - 30.0
11/06/2004 17:30:00 - 20.2

BSS_M / Site_20 / 123-45-5566-27651


Total OOS Time = 63.5
11/06/2004 03:00:00 - 4.183
11/06/2004 02:30:00 - 30.0
11/06/2004 02:00:00 - 29.317

BSS_A / Site_21 / RSL 0


Total OOS Time = 2.117
11/06/2004 06:00:00 - 2.117

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

Figure 2-33 OOS History window

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.

The following is an example of an oos_cells.csv file:

68P02900W36-P 2-93
1900.2AS May 2008
Scheduled OOS reports Chapter 2: Using the NHA

OMC,Device,OOS Since,Opstate,Adminstate,Reason Code,27/02/2004 16:00:02


omcone,bss01 / Site_3 / 543-21-1313-1313,25/02/2004 16:56:48,1,4,0
omcone,bss01 / Site_2 / 543-21-1212-1212,25/02/2004 17:55:21,0,4,0
omcone,bss01 / Site_1 / 543-21-1111-1111,25/02/2004 17:24:50,1,4,0

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

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.

Blacklisting in INSM is user-protected. Refer to Permissions and security on page 2-5.

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.

Blacklisting from an OOS report

To blacklist an NE from an OOS report, use the following steps:

Procedure 2-14 Blacklisting from an OOS report

1 Display the OOS report window using the procedure described in


Displaying an OOS report on page 2-90.
2 Select the Add to Blacklist option from the Blacklist pop-up menu.

Blacklisting from a conguration report

To blacklist an NE from a configuration report, use the following steps:

Procedure 2-15 Blacklisting from a conguration report

1 Display the configuration report window using the procedure described in


Displaying a configuration report on page 2-89.
2 Select the Add to Blacklist option from the Blacklist pop-up menu.

Removing a device from a blacklist

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

Using Worst Cells


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of Worst Cells

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.

This section provides the following information:


• Displaying the worst cells

• Worst cells report

• Printing, exporting, and copying worst cell details

• Configuring the Worst Cells feature

Displaying the worst cells

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

Figure 2-34 Worst Cells Filter

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.

• Number of cells to show

Enter the number of cells to show. The default is 50.

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.

• Filter Cells: Statistic (if an additional filter is needed)

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.

Worst cells report

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.

Figure 2-35 Worst Cells window

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.

Printing, exporting, and copying worst cells details

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 Conguring the Worst Cells feature

Table 2-21 Worst Cells window - menu options

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.

Conguring the Worst Cells feature

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

Using the Scoreboard feature


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Scoreboard feature

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 - Call Success Rate) ^ 2 * Total Calls


---------------------------------------
Call Setup Success Rate

This section provides the following information:


• Using the Scoreboard feature

• Printing and exporting Scoreboard details

Using the Scoreboard feature

To use the Scoreboard feature, follow these steps:

Procedure 2-16 Using the Scoreboard feature

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.

Figure 2-36 Scoreboard Filter

Continued

2-100 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Printing and exporting Scoreboard details

Procedure 2-16 Using the Scoreboard feature (Continued)


2 Select a specific OMC or all OMCs connected to the NHA and the number of
cells to be displayed on the Scoreboard window.
3 When the criteria have been selected on the Scoreboard Filter window,
click OK. The Scoreboard window is then displayed as in Figure 2-37. The
Scoreboard window displays a list of cells and their corresponding key
statistics.

Figure 2-37 Scoreboard window

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.

Table 2-22 Scoreboard window - 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

Frequency Clash Report


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of the Frequency Clash Report

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.

Refer to Figure 2-38 for an example of a frequency clash report.

Figure 2-38 Example of a Frequency Clash Report

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
Conguring the NHA Chapter 2: Using the NHA

Conguring the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Congure menu

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

• Group Properties - refer to Configuring group properties on page 2-110

• Thresholds - refer to Modifying detectors and thresholds on page 2-133

• Regions - refer to Configuring BSS Regions on page 2-139

• Problem Subscriptions - refer to Configuring problem subscriptions on page 2-148

• User-Defined Causes - refer to User-defined causes on page 2-151

• Stats Per Problem - refer to Statistics per problem on page 2-155

• Neighbor Cell Statistics - refer to Neighbor Cell statistics on page 2-156

• Blacklist - refer to Blacklisting devices on page 2-157

• Daily Export - refer to Daily Export on page 2-160

• 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 Congure menu

Figure 2-39 Congure menu options

68P02900W36-P 2-105
1900.2AS May 2008
Cell grouping Chapter 2: Using the NHA

Cell grouping
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to cell grouping

This section describes the following topics:


• NHA cell groups

• Manual and automatic cell groups

• Default cell groups

• Moving cells from one group to another

NHA cell groups

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

Figure 2-40 Cell View window

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

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

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.

Default cell groups

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.

Moving cells from one group to another

There are four methods of moving cells from one cell group to another. These methods are:
• Manually using Modify Cell Grouping

• Manually using Import Cell Grouping

• Manually using the Automatic Cell Grouping

• Automatically using the Cell Grouping scripts

Each method is described in the following sections.

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
Conguring group properties Chapter 2: Using the NHA

Conguring group properties


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

The Group Properties window

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:

Figure 2-41 Group Properties window

Configuring group properties includes the following procedures :


• Creating a cell group.

• Changing groups from Manual to Automatic.

• Exporting cell group names.

• Importing cell group names.

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

Creating cell groups on the NHA

To create a cell group on the NHA system, use the following steps:

Procedure 2-17 Creating a cell group

1 Select Group Properties from the Configure menu.


2 In Edit mode, select the New button. A Group Creation window is displayed
as in Figure 2-42.

Figure 2-42 Group Creation window

3 Select an OMC or OMCs.


4 Enter a Group Name. Ensure that this name is a meaningful one.
5 Select the grouping mechanism from the Cell Grouping drop-down list. The
choices available are Manual or Automatic. If Manual is chosen, then the
cells in this group are not affected by the Automatic Cell grouping scripts.
6 Copy the initial detector settings from an existing cell group by selecting a
cell group from the drop-down list.
7 Click OK to save the new cell group.

68P02900W36-P 2-111
1900.2AS May 2008
Changing groups from Manual to Automatic Chapter 2: Using the NHA

Changing groups from Manual to Automatic

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:

Procedure 2-18 Changing groups from Manual to Automatic

1 Select the Configure-Group Properties menu option to open the Group


Properties window.
2 In Edit mode, click the Automatic Regrouping column of the group to be
changed.
3 Select MANUAL or AUTOMATIC as required.
4 Press Apply to apply the changes without closing the window. Press OK to
save the changes and close the window.

Exporting cell group names

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.

Select the default file name /usr/gsm/ea_logs/gnames.csv.

Importing cell group names

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

Figure 2-43 Import Group names window

Figure 2-44 Import Cell Grouping window

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

Manual cell grouping


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Manually moving cells between groups

To move cells between groups on the NHA system, use the following steps:

Procedure 2-19 Moving cells between groups

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

Procedure 2-19 Moving cells between groups (Continued)

Figure 2-45 Open Cell Grouping window

2 Select the appropriate cell Groups and OMCs.

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 (except blacklisted cells)

• All cells

• Blacklisted cells

• All cells with problems

Continued

2-116 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Manually moving cells between groups

Procedure 2-19 Moving cells between groups (Continued)


The second list allows users to decide which columns are populated when
the Cell View window is launched. Options are:

• No. of probs

• Exclude No. of probs (provides the fastest result)


3 Click OK to apply selections.

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.

Figure 2-46 Change Cell Group Conrmation 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

Figure 2-47 Conguring cell grouping

Additional features of the Cell View window

The additional features of the Cell View window are:


• Menu options

• Pop-up menu options

2-118 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Additional features of the Cell View window

Menu options

The Cell View menu options are displayed in Table 2-23:


Table 2-23 Cell View 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.

Cell View pop-up menu options

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:

Table 2-24 Cell Grouping pop-up menu options

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

Table 2-24 Cell Grouping pop-up menu options (Continued)


Select To
Problems on Neighbors List the problems on all neighbor cells for the selected cell,
even if they exist on a different OMC or NHA. 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 further information.
Problems on Site List any site problems related to 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 further information.
Remote Login Remote login to the BSS.
Statistics History View the Statistics History window.
Long Term Statistics Display the long term statistics available for the selected cell.
Neighbors View the neighbor list on the Neighbors window.

Exporting cell group les

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.

Figure 2-48 Export to File

Importing cell group les

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

Automatic cell grouping


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to automatic cell grouping

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.

Automatic cell grouping scripts

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:

Procedure 2-20 Setting up cell groups

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

Manually running automatic cell grouping


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to running automatic cell grouping manually

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.

Conguring the NHA to run automatic cell grouping manually

To run Automatic Cell Grouping manually, perform the following steps:

Procedure 2-21 Manually run Automatic Cell Grouping

1 Ensure that any user-defined cell grouping scripts to be run are in place
in the directory /usr/gsm/OMCs/<omcname>/nha_grouping/.

Each file to be run must:

• Have a name that starts with autogroup (for example,


autogroupDCS1800.sh).

• Be owned by user omcadmin and have read and execute permissions


for user omcadmin.

• Be in the correct alphabetical order in relation to other scripts to be


run (for example, autogroup1 is run before autogroup2 so output from
autogroup2 could overwrite output from autogroup1).

• Produce an output file in


/usr/gsm/OMCs/<omcname>/nha_grouping/
named output<filename>, where filename is the name of the
original script file (for example, autogroup1.sh would have an
output file called outputautogroup1.sh). Each line in the output
file must be in the format:
OMC,BSS,Site,Cell GSMCellid,Group Name
For example, OMC,BSS_City,Site_Suburb_1,123-45-1-100,DCS1800

Continued

2-124 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring the NHA to run automatic cell grouping manually

Procedure 2-21 Manually run Automatic Cell Grouping (Continued)

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.

Figure 2-49 Regroup Cells Automatically window

3 Press the Edit Mode button to go into edit mode, then select the
OMC on which the cells are to be regrouped automatically.

A Warning message alerts the user that taking this action


overwrites the current cell grouping. Automatic regrouping
of cells takes approximately 60 minutes to complete. Cells
are regrouped according to the automatic cell grouping scripts.

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

Procedure 2-21 Manually run Automatic Cell Grouping (Continued)


4 Click the Start button to run the cell grouping scripts.
5 Check that the intended outcome of the automatic cell grouping actually
ensued. Several checks can be performed:

• 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>.

• Check for errors in the scripts in the files


in the NHA automatic cell grouping logs:
/usr/gsm/OMCs/<omcname>/ea_logs/autogrouping<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).

nongrouping.csv contains a list of cells that are BLACKLISTED or in MANUAL


groups (these cells are not regrouped automatically).

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.

3. All the files in the directory /usr/gsm/OMCs/<omcname>/nha_grouping/ that have


names beginning with autogroup are run (in alphabetical order) with output going to
/usr/gsm/OMCs/<omcname>/nha_grouping. For example, autogroupDCS1800.sh
produces output in a file called outputautogroupDCS1800.sh.

NOTE
To run DCS1800.sh, rename it as autogroupDCS1800.sh.

4. The file importgroup.csv is created in directory /usr/gsm/OMCs/<omc-


name>/nha_grouping/. This file contains only cells that were in exportgroup.csv
(cells in AUTOMATIC groups) and is a consolidated version of ea_group.csv and
output<scriptname> files.

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

Automatically running automatic cell grouping


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to automatic cell grouping functionality

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.

Automatic cell grouping includes the following topics:


• Configuring the NHA to run automatic cell grouping automatically

• Background functionality

• Checking the results

• Scripts for automatic cell grouping

• Multiple OMC systems

Conguring the NHA to run automatic cell grouping


automatically

To configure the NHA to run automatic cell grouping automatically, perform the following steps:

Procedure 2-22 Automatically run automatic cell grouping

1 Edit the Automatic Cell Grouping parameters in the OMC-specific NHA


configuration file /usr/gsm/OMCs/<omcname>/config/ea.cfg as follows:

Change the value for AUTO-EXPORT-ON to ON to allow the NHA to export


files of cells that are to be included or excluded from the cell grouping.

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.

Change the value for AUTO-IMPORT-ON to ON to allow


the NHA to import the file containing the changed cell grouping.

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 Conguring the NHA to run automatic cell grouping automatically

Procedure 2-22 Automatically run automatic cell grouping (Continued)


2 Ensure that the configurable values for the default traffic usage
script are set correctly. These values are found at the top of the file
/usr/gsm/OMCs/<omcname>/config/ea.cfg.

• AUTO-NO-DAYS is the number of days statistics that the script checks


for (the default = 7).

• AUTO-MAX-QUIET is the maximum average tch_mean value for a


cell to be put in the QUIET group (the default is 1).

• AUTO-MAX-NORMAL is the maximum average tch_mean value for a


cell to be put in the NORMAL group (the default is 4). Cells with values
above the default are put in the BUSY group.
Values in this file can be edited and changed appropriately. It is not
necessary to restart the NHA to pick up these changes.
3 As user omcadmin, select the option Configure - Read ea.cfg files to
apply any changes to the AUTO-EXPORT-ON, AUTO-EXPORT-TIME, or
AUTO-IMPORT-ON variables.
4 Ensure that any user-defined cell grouping scripts to be run are in place in
the directory: /usr/gsm/OMCs/<omcname>/nha_grouping/.

Ensure that each file to be run:

• Has a name that starts with autogroup (for example,


autogroupDCS1800.sh)

• Is owned by user omcadmin and has read and execute permissions


for user omcadmin.

• Is in the correct alphabetical order in relation to other scripts to be run


(for example, autogroup1 is run before autogroup2 so output from
autogroup2 could overwrite output from autogroup1).

• Produces an output file in


/usr/gsm/OMCs/<omcname>/nha_grouping/
that is named output<filename> where filename is the name of the
original script file (for example, autogroup1.sh would have an output
file called outputautogroup1.sh). Each line in the output file must be
in the format OMC, BSS, Site, Cell GSMCellid, Group Name, (for
example, OMC1,BSS_City,Site_Suburb_1,123–45–1–100,DCS1800).

NOTE

• If there are no user-defined cell grouping scripts,


then automatic cell grouping is run only on
the basis of the default traffic usage script
(/usr/gsm/current/ea_tools/ea_group.sh).
• The user-defined scripts can be modified, renamed, or
added as necessary without restarting the NHA.

68P02900W36-P 2-129
1900.2AS May 2008
Background functionality Chapter 2: Using the NHA

Background functionality

If the feature is turned on (AUTO-EXPORT-ON is ON), then at the specified time


(AUTO-EXPORT-TIME), the following steps occur automatically:
1. Two files are created in the directory /usr/gsm/OMCs/<omcname>/nha_grouping/
exportgroup.csv contains a list of all cells in AUTOMATIC groups (these cells are
automatically regrouped)

nongrouping.csv contains a list of cells that are BLACKLISTED or in MANUAL


groups (these cells are not automatically regrouped).

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.

3. All the files in the directory /usr/gsm/OMCs/<omcname>/nha_grouping/ that


have names beginning with autogroup are run (in alphabetical order) with output to
/usr/gsm/OMCs/<omcname>/nha_grouping. For example, autogroupDCS1800.sh
produces output in a file called outputautogroupDCS1800.sh.

NOTE
To run DCS1800.sh, rename it to autogroupDCS1800.sh; if not renamed,
the script does not run.

4. The file importgroup.csv is created in directory /usr/gsm/OMCs/<omc-


name>/nha_grouping/. This file contains only cells that were in exportgroup.csv
(cells in AUTOMATIC groups) and is a consolidated version of ea_group.csv and
output<scriptname> files.

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.

Checking the results

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

Various checks can be performed as follows:

Procedure 2-23 Checking the results of 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>

Scripts for automatic cell grouping

NHA administrators can define custom scripts to be included as part of the automatic cell
grouping cycle using the following guidelines:

Procedure 2-24 Dening custom scripts

1 Move any user-defined cell grouping scripts to be run to the directory


/usr/gsm/OMCs/<omcname>/nha_grouping/.
2 Make sure that each file to be run:

• Has a name that starts with autogroup (for example,


autogroupDCS1800.sh)

• Is owned by user omcadmin and has read and execute permissions


for user omcadmin.

• Is in the correct alphabetical order in relation to other scripts to be


run (for example, autogroup1 is run before autogroup2 so output from
autogroup2 could overwrite output from autogroup1).

• Produces an output file in


/usr/gsm/OMCs/<omcname>/nha_grouping/
named output<filename> where filename is the name of the original
script file (for example, autogroup1.sh would have an output file
called outputautogroup1.sh).

Continued

68P02900W36-P 2-131
1900.2AS May 2008
Multiple OMC systems Chapter 2: Using the NHA

Procedure 2-24 Dening custom scripts (Continued)


3 The format used for the output files is the same as for the Import
and Export Group Details format. That is, the file has 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
4 To turn off a custom automatic cell grouping script, rename the
script so that it does not begin with the string autogroup.
For example:
cd /usr/gsm/OMCs/<omcname>/nha_grouping/
mv autogroupdcs1800.sh saveautogroupdcs1800.sh
5 A sample script (for identifying DCS 1800 cells and putting them into a group
called DCS1800) is located at /usr/gsm/current/ea_tools/ and is called
/usr/gsm/current/ea_tools/dcs1800.sh. This script can be used, copied,
or cloned as an example for other custom scripts.

NOTE
It is good practice to debug scripts by running them manually
before scheduling them to be run in the automatic cell grouping
script.

Multiple OMC systems

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

Modifying detectors and thresholds


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to modifying detectors

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 too many problems are being raised, tighten 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.

Modifying detector thresholds

To modify detector thresholds, perform the following steps:

Procedure 2-25 Modifying detector thresholds

1 Select Thresholds - Open Thresholds from the Configure menu to open


the Thresholds Filter window as in Figure 2-50.
2 Select the required OMCs and Groups and click OK. Click the All or
Clear buttons to select or deselect all OMCs and Groups.

The Thresholds window is displayed as in Figure 2-51.

To view the configurable values of a detector, select the appropriate


detector from the Detector drop-down list. The Detector Type is displayed
by default. All users have Read Only permissions and can view detector
threshold settings. However, the ability to modify detector thresholds is
user protected. Refer to Permissions and security on page 2-5 for
further information on security levels.

Continued

68P02900W36-P 2-133
1900.2AS May 2008
Modifying detector thresholds Chapter 2: Using the NHA

Procedure 2-25 Modifying detector thresholds (Continued)


Authorized users can modify detector thresholds by selecting the Edit Mode
button. The user is then in Edit mode which is indicated in red on the
Threshold window. Only one user can be in Edit mode at any one time. Edit
mode is surrendered automatically when the user closes the Thresholds
window.
3 In Edit mode, select the required row on the Thresholds window.

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:

Reconfigure the Threshold values, or the Sample sizes by selecting


the Value field and enter a new value.
5 Click Return to move to the next field.
6 Right click in the Enabled column to display the On/Off list-box and select
On or Off as required.
7 Click Apply to apply the changes and OK to save and close.

NOTE
If the selected custom detector has been renamed or deleted by
another client while changes are being made, these changes are
not saved.

Figure 2-50 Thresholds Filter window

2-134 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Modifying detector thresholds

Figure 2-51 Thresholds window

Making bulk changes

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

Extra options on the Thresholds window

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:

Procedure 2-26 Importing thresholds

1 Select Thresholds - Import Thresholds from the Configure menu to open


the Thresholds Filter window as in Figure 2-52.

Continued

2-136 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Importing thresholds

Procedure 2-26 Importing thresholds (Continued)

Figure 2-52 Import Thresholds window

2 Press the Edit mode button.

The ability to import detector thresholds is user protected. Refer to


Permissions and security on page 2-5 for further information on security
levels. Authorized users can import detector thresholds by selecting the
Edit Mode button on the Import Thresholds window. The user is then in Edit
mode as indicated in red. Only one user can be in Edit mode at any
one time. Edit mode is automatically surrendered when the user
closes the Import Thresholds window.
3 In Edit mode, select one or more OMCs into which to import the detector
thresholds. A Warning message that this action overwrites current detector
settings is displayed.
4 Click the Start button to begin importing. A prompt is displayed, showing
the default import location.

Continued

68P02900W36-P 2-137
1900.2AS May 2008
Automatic export and import of thresholds Chapter 2: Using the NHA

Procedure 2-26 Importing thresholds (Continued)


5 Click OK to continue.

NOTE
A useful UNIX command for copying threshold files from one
OMC to another for re-importing is:

sed 's/omcone/omctwo/g' thresone.csv > threstwo.csv

An alternative is to use the keyword All if the same thresholds


are to be applied to all OMCs. This imports the thresholds into
any NHA or OMC.

Automatic export and import of thresholds

To configure the NHA to export and import thresholds automatically, edit the OMC-specific
configuration file /usr/gsm/OMCs/<omcname>/config/ea.cfg.

AUTO-EXPORT-THRESHOLD-TIME is set to 0 by default. It automatically exports threshold


configurable values (to export-thres.csv) at the time specified. Set the time to a value between
0 and 23 hours, for example, AUTO-EXPORT-THRESHOLD-TIME 23 where 23 = 23:00.

If AUTO-IMPORT-THRESHOLD-ON is ON, the automatic import of threshold configurable values


(from import-thres.csv) happens 60 minutes after the automatic export of thresholds.

2-138 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring BSS Regions

Conguring BSS Regions


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Creating a BSS region

To create a BSS region to be monitored, use the following steps:

Procedure 2-27 Creating a new BSS region

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

Figure 2-53 New Region window

Modifying or viewing a BSS region

To modify a BSS region, use the following steps:

Procedure 2-28 Modifying a BSS region

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

Deleting a BSS region

To delete a region, use the following steps:

Procedure 2-29 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.

Verifying BSS regions

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
Conguring Cell Regions Chapter 2: Using the NHA

Conguring Cell Regions


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to Cell Regions

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.

Creating a Cell region

To create a Cell region to be monitored, follow these steps:

Procedure 2-30 Creating a Cell region

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.

The Open Cell Region Filter window is displayed as in Figure 2-54.

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

Procedure 2-30 Creating a Cell region (Continued)

Figure 2-54 Open Cell Region window

4 Select the BSSs in which the required cells are located.


5 Select the filtering criteria to be used by Site, cell name, or GSM cell Id.

Continued

68P02900W36-P 2-143
1900.2AS May 2008
Creating a Cell region Chapter 2: Using the NHA

Procedure 2-30 Creating a Cell region (Continued)


6 Click OK.

The New Cell Region window is then displayed as in Figure 2-55.

Figure 2-55 New Cell Region window

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

Procedure 2-30 Creating a Cell region (Continued)


7 From the list, select the cells to be included
in the cell subscription and click OK.

If the number of cells in the subscription exceeds the number set


in the MAX-NO-OF-CELL-SUB field of the ea.cfg file, a warning
message is displayed.

NOTE
The default value of MAX-NO-OF-CELL-SUB in the ea.cfg file
is 200.

Modifying or viewing a Cell region

To modify a Cell region, follow these steps:

Procedure 2-31 Modifying a Cell region

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

Procedure 2-31 Modifying a Cell region (Continued)

Figure 2-56 Modify Cell Region Conrmation window

3 To modify previously selected cells in BSSs in the cell region, click Yes.

The Modify Cell Region window is displayed as in Figure 2-55.

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

Deleting a Cell region

To delete a Cell region, follow these steps:

Procedure 2-32 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.

Verifying Cell regions

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
Conguring problem subscriptions Chapter 2: Using the NHA

Conguring problem subscriptions


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to problem subscriptions

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.

Problems can also be configured by BSS Regions or Cell Regions.

Creating a problem subscription

To create a subscription list of problems, use the following steps:

Procedure 2-33 Creating a problem subscription

1 Select the Problem Subscriptions option from the Configure menu to


display the Problem Subscriptions window.
2 Click the New button. The New Problem Subscription dialog box is
displayed.
3 Enter a subscription Name (without spaces) and click OK.

The New Problem Subscription window (Figure 2-57) is displayed.

Continued

2-148 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating a problem subscription

Procedure 2-33 Creating a problem subscription (Continued)

Figure 2-57 Problem subscriptions window

4 Select the problems to be included in the new subscription list.

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

Modifying or viewing a problem subscription

To modify a problem subscription list, use the following steps:

Procedure 2-34 Modifying a problem subscription

1 Open the Problem Subscriptions window and select the subscription to be


modified.
2 Click the Modify button. The Modify Problem Subscription window is
opened for the selected subscription.
3 Modify the subscription by selecting or deselecting a problem or problems.
4 Click OK to update the subscription and close the Modify Problem
Subscription window.

Deleting a problem subscription

To delete a subscription, use the following steps:

Procedure 2-35 Deleting a problem subscription

1 Select Problem Subscriptions from the Configure menu to display the


Problem subscriptions window.
2 Select the subscription to be removed.
3 Click Delete to delete the unwanted problem subscription.

Verifying problem subscriptions

A Verify button is provided on the Subscriptions window to recover from subscription-related


errors. It is unlikely to be needed. However, in the event of subscription-related errors
occurring, this button can be used to verify that the subscriptions 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.

2-150 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst User-dened causes

User-dened causes
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to user-dened 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.

This section describes the following tasks:


• Adding a user-defined cause.

• Editing a user-defined cause.

• Deleting a user-defined cause.

68P02900W36-P 2-151
1900.2AS May 2008
Adding a user-dened cause Chapter 2: Using the NHA

Adding a user-dened cause

To add a user-defined cause to the NHA, use the following steps:

Procedure 2-36 Adding a user-dened cause to 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.

Figure 2-58 User-dened cause window

Continued

2-152 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Adding a user-dened cause

Procedure 2-36 Adding a user-dened cause to the NHA (Continued)


2 Click the problem associated with the new cause. Right-click
that problem, then select New from the pop-up menu.

The Corrective Action window is displayed as in Figure 2-59.

Figure 2-59 Corrective Action for local cause window

Continued

68P02900W36-P 2-153
1900.2AS May 2008
Editing a user-dened cause Chapter 2: Using the NHA

Procedure 2-36 Adding a user-dened cause to the NHA (Continued)


3 Enter the details of the new cause as follows:

• Name (up to a maximum of 45 characters)

• Confidence factor

• Corrective action (up to a maximum of 5000 characters)


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.

Editing a user-dened cause

To edit a user-defined cause, use the following steps:

Procedure 2-37 Editing a user-dened cause

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.

Deleting a user-dened cause

To delete a user-defined cause to the NHA, use the following steps:

Procedure 2-38 Deleting a user-dened cause

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

Statistics per problem


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Viewing 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.

Figure 2-60 Select Problem window

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

Neighbor Cell statistics


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Conguring Neighbor Cell statistics

To configure and view neighbor cell statistics for the problem, use the following steps:

Procedure 2-39 Conguring Neighbor Cell statistics

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.

The Available, Selected, and Default statistics for the selected


problem are displayed.
3 Select a statistic in the Available column, as shown in Figure 2-61.
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.

Figure 2-61 Statistics Selection window

2-156 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Blacklisting devices

Blacklisting devices
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Viewing and modifying the blacklist

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.

Figure 2-62 Blacklisted Devices window

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

Run a Site Health Check on a device

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.

Run a BSS Detector Check

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.

Exporting blacklist details

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.

Figure 2-63 Exporting blacklist details to a le

2-158 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Importing blacklist details

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.

Figure 2-64 Importing a blacklist

Automatic blacklist le import

To import blacklisted devices automatically, select the Blacklist-Automatic Blacklist option


from the Configure menu on the Problem window. The Confirm Automatic Import dialog box
opens and a message is displayed as in Figure 2-65. Click Yes to continue.

Figure 2-65 Conrm Automatic Import

68P02900W36-P 2-159
1900.2AS May 2008
Daily Export Chapter 2: Using the NHA

Daily Export
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Conguring 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.

• Change the time that the Daily Export occurs.

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.

Figure 2-66 Daily Export dialog box

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

Reporting NHA problems to the OMC as alarms


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Conguring Report to OMC

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.

Figure 2-67 Report to OMC dialog box

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of Editing Knowledge

This section provides information on the following topics:


• Knowledge Editor

• External Script Interface for Detectors

• External Script Interface for Causes and Actions

• User Interface Action Scripts

• Cyclic Neighbor Statistics

• Recent events and alarms

2-162 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst The Knowledge Editor

The Knowledge Editor


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Using the Knowledge Editor, the operator can:

• Create, edit, and remove a custom detector.

• Create, edit, and remove a custom formula.

Creating and modifying custom detectors and custom formula is user protected. For further
information, refer to Permissions and security on page 2-5.

Launching the Knowledge Editor

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.

Importing and exporting detectors and formulae

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

Creating custom formulae


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Figure 2-68 Custom Formulae window

68P02900W36-P 2-165
1900.2AS May 2008
Creating a custom formula Chapter 2: Using the NHA

Creating a custom formula

To create a custom formula, use the following steps:

Procedure 2-40 Creating a custom formula

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.

For further information about using the Formula Version Editor,


refer to Figure 2-69.

Figure 2-69 Formula Editor window

Editing a custom 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:

Procedure 2-41 Editing a custom formula

1 Select the formula to be edited.


2 Click the Modify button to open the Formula Editor window.
3 Select the version of the formula to be edited from the Formula column and
click the Modify button. The Formula Version Editor window is displayed.
4 Edit the custom formula as required (refer to Using the Formula Version
Editor on page 2-168 for further information).
5 Click OK to save the new formula configuration and quit the window.

68P02900W36-P 2-167
1900.2AS May 2008
Using the Formula Version Editor Chapter 2: Using the NHA

Using the Formula Version Editor


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Formula Version Editor

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.

The elements of the formula comprise:


• Raw statistics (inserted into the custom 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

Building new formulae

To build or edit a custom formula, use the following steps:

Procedure 2-42 Building new formulae

1 Open the Formula Version Editor (refer to Creating custom formulae


on page 2-165). The mid-right column is used to build the formula, as in
Figure 2-70, the Formula Version Editor window. The Numerator button is
selected by default. It toggles between Numerator and Denominator. The
formula is presented in the bottom right scroll area as it is being built.
2 With the Numerator button (top line in the formula) selected, select the
required statistics from the NHA Raw Statistics column.
3 Use the numbers and mathematical operators as required. For example, to
add two raw statistics, click the + button after selecting the first statistic
and before selecting a second statistic.
4 Click the Numerator button to toggle to the Denominator expression (below
the line). Create an expression as in step 2 and step 3.

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:

• If the formula applies to a specific BSS version:


1. Click in the Applies from box in the Starting
BSS version field, and enter a valid BSS release.
2. Click in the Applies up to box in the Ending BSS version,
and enter a valid BSS release.

• If the formula applies to all BSS versions:


Click in the No limit box in both the Starting BSS version, and Ending
BSS version fields.
6 Click the OK button to create the custom formula.
7 Name the new formula in the Formula Editor window.

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

Figure 2-70 Formula Version Editor window

2-170 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Creating a custom detector

Creating a custom detector


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to custom detectors

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.

The maximum number of enabled detectors is 25.

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

Creating custom detectors

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.

Figure 2-71 Custom Detector window

Use the following steps to create a custom detector:

Procedure 2-43 Creating a custom detector

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

Procedure 2-43 Creating a custom detector (Continued)

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.

For further information on custom detectors, refer to Example of a custom detector on


page 2-176 in this chapter.

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

Edit a custom detector


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to editing custom detectors

The Custom Detector edit function is used to change the way custom problems are detected and
displayed on the Problem window.

Editing a custom detector

To edit a custom detector, open the Custom Detectors window (Figure 2-72) then use the
following steps:

Procedure 2-44 Editing a custom detector

1 Select the detector to be edited.


2 Click the Modify button to open the Detector Editor window as shown in
Figure 2-72.
3 Change the custom detector as required and click OK to save the new
configuration and quit the window.

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

Figure 2-72 Detector Editor window

68P02900W36-P 2-175
1900.2AS May 2008
Example of a custom detector Chapter 2: Using the NHA

Example of a custom detector


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to worked example

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.

The process has seven stages as follows:


1. Decide on a formula.

2. Decide on a detector.

3. Create the formula and detector using the Knowledge Editor.

4. Apply the detector values on the Thresholds window.

5. Enable the detector for one OMC on the Thresholds window.

6. Monitor the problems raised by the new detector on the Thresholds window.

7. Enable the detector for all OMCs on the Thresholds window.

Formula and detectors

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:

Procedure 2-45 Steps for creating a detector

1 Build the formula on page 2-177.


2 Name the formula on page 2-178.
3 Create the detector on page 2-178.
4 Apply detector threshold values on page 2-179.
5 Create a default cause for the detector on page 2-179.
6 Validate the new detector on page 2-179.

2-176 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Build the formula

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:

Procedure 2-46 Build the formula (example)

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.

• Click the + button on the keypad.

• Select BUSY_TCH_MAX from the Raw Statistics scroll-down list.

• Click the ) button on the keypad.

• Click the * button on the keypad.

• Enter 100 using the keypad.

• Toggle to the denominator button (bottom line), click the numerator


button.

• Select the TCH_SERVICE_REQUEST statistic from the Raw Statistics


scroll-down list.
This formula is applicable to all BSS versions.
If the formula created is only applicable to a certain BSS release, identify the
range for this release in the Starting BSS version and Ending BSS version
fields. Refer to Using the Formula Version Editor on page 2-168.
6 Click OK to complete the first phase.

68P02900W36-P 2-177
1900.2AS May 2008
Name the formula Chapter 2: Using the NHA

Name the formula

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.

Create the detector

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:

Procedure 2-47 Create the detector (example)

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

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:

Procedure 2-48 Applying detector threshold values (example)

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.

Create a default cause for the detector

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.

Refer to User-defined causes on page 2-151.

Validate the new detector

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

External interfaces to detect problems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to external scripts

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.

This section provides information about:


• Script directories.

• Short-term problems.

• Daily problems.

• Creating a script.

• Default values.

Script directories

Store user-created scripts in the following directory:

/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/.

Each script takes three parameters as follows:


• Hostname of the OMC system processor

• Output directory where the script creates a file containing information on the problems
that it wants to report to the NHA

• Date and start time of the most recent statistic interval

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

Subscription and lter dialogues

Edit the global configuration file /usr/gsm/config/customer/extprobs.txt with a line that


includes the problem name. This problem name must exactly match the problem name used in
the external script detector. Separate the problem name with dashes, that is, there must be no
spaces between words. If the problem name contains a hyphen (such as Low Inter-BSS Handover
Success Rate), then replace the hyphen (-) with two hyphens (--) when editing. For example,
if adding the Low Inter-BSS Handover Success Rate problem to the global configuration file,
enter the problem name as low-inter--bss-handover-success-rate. If adding the Low Daily
Activity in Timeslot problem, enter the problem name as low-daily-activity-in-timeslot.

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/

• All output files must begin with D or S.

• 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.

• Multiple problem types can be added to one output file.

2-182 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Output le elds

• The format is ATTRIBUTE VALUE (separated by TAB)

• The Keywords are:


PROBLEM-TYPE, DEVICE-NAME, or DEVICE-DN (these three are compulsory),
NUMBER-OF-INTERVALS, SEVERITY, VALUE, ADDITIONAL-INFORMATION,
CLEAR-AFTER.

• 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.

Output le elds

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.

Example user-created script

The following is an example of a .sh file (S_ea_slc.sh) found in the directory


/usr/gsm/current/knowledge/external_problems/example_scripts. Use this as a guide
when using the external interface feature:

#!/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

echo "ERROR: cannot rsh into OMC host $splat_host."


if [ -f ${logs} ]
then
echo >> ${logs} "${end_time}|Warning |external|scripting| Cannot rsh into
OMC host $splat_host in S_ea_${script_body_name}.sh."
fi
exit 1
fi
#
# Find out where the home directory for omcadmin is kept. This is so
# that we can copy files to the omc_splat temporarily
#
omcadmin_dir=‘rsh ${splat_host} pwd‘
#
# Copy files to the MIB, run the queries there and copy the results back
#
/bin/rm -f $CURRENT_DIR/ea_${script_body_name}.arc
$CURRENT_DIR/ea_${script_body_name}.tmp $CURRENT_DIR/ea_${script_body_name}.rep
rsh ${splat_host} >/dev/null 2>&1 "/bin/rm -f ea_${script_body_name}.*"
rcp $CURRENT_DIR/ea_${script_body_name}.* ${splat_host}:${omcadmin_dir}
echo
echo
echo "Generating database query. Please wait."
echo
echo
# If the time was not entered then use the latest date. Send this into the ace
# file. The ace file will worry about rounding it down to the
# last hour or half hour.
if [ "X$maxdate" = "X" ]
then
maxdate=‘date '+%Y-%m-%d %H:%M'‘;
fi
# rsh into the omc_splat and saceprep the ace file. saceprep will compile the
# ace file and create an arc file.
rsh ${splat_host} >/dev/null "source /usr/gsm/config/global/pmAdminConfig.csh ;
saceprep ea_${script_body_name}.ace"
#Now that the arc file is created we must run it. This is done using sacego.
rsh ${splat_host} "source /usr/gsm/config/global/pmAdminConfig.csh ; sacego -s
ea_${script_body_name}.arc \"$maxdate\""
# The running of the ea_${script_body_name}.arc file will have created a .tmp
file on the splat
# Note that the name of the tmp file is specified in the ace file in the output

68P02900W36-P 2-187
1900.2AS May 2008
Example user-created script Chapter 2: Using the NHA

# section, preceded with report to ...


# Copy the tmp file back to the NHA machine
# rsh to the splat and clean up the mess we made.
rcp ${splat_host}:${omcadmin_dir}/ea_${script_body_name}.tmp $CURRENT_DIR
rsh ${splat_host} "/bin/rm -f ea_${script_body_name}.*"
#
# mv the tmp file into a rep file in the correct directory.
#
mv $CURRENT_DIR/ea_${script_body_name}.tmp
${output_directory}/S_ea_${script_body_name}.rep
echo
echo "Processing complete - output written to:
${output_directory}/S_ea_${script_body_name}.rep"

The following is an example of a .ace file (script ea_alc.ace). Use this as a


guide when using the external interface feature: database omc_db end

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

This is the sample output (S_ea_slc.rep) for the preceding script:

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


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to External Interface for Causes and Actions

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.

The interface provides scripts for three problem scenarios:


• Cause Analysis scripts to provide additional cause analysis and corrective actions.

• 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

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

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 Action scripts

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.

Conguration of the External Interface for Causes and Actions

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.

Conguration le entries

The OMC-specific configuration file /usr/gsm/OMCs/<omcname>/config/ea.cfg is used to


switch the feature on or off, set the paths for the description files and output files, and set the
character limit for corrective action and line of reasoning. If any of these entries in ea.cfg
are changed, it is necessary to read in the configurable values by selecting the menu option
Configure - Read ea.cfg file on the NHA UI as user omcadmin.

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.

Parameters for scripts

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

Table 2-27 Parameters for scripts

Parameter Name Description


1 UNIQUE_ID (for Cause A unique ID used to identify the script when it
Analysis and Automatic returns to the NHA, for example: 41cecc11cfb5a0
Action 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

Table 2-27 Parameters for scripts (Continued)


Parameter Name Description
16 PROBLEM_TYPE The type of the NHA Problem that triggered the
script, for example: "Repeated Cell Outages".
17 CALCULATED_VALUE The calculated value of the raised problem (a floating
point number).
18 FIRST_TIME The first time the problem occurred. The format is:
YYYY-MM-DD-HH:MM.
19 LAST_TIME The time of the most recent occurrence of the
problem. The format is: YYYY-MM-DD-HH:MM.
20 FIRST_ANOMALY_ The time at which the anomaly causing the problem
TIMESTAMP was raised. The format is YYYY-MM-DD-HH:MM, for
example: 2004-06-11-19:45.
21 NUMBER_OF_REPEATS The number of repeats of the problem (an integer).
22 PREVIOUS_VALUE The previous calculated value (a floating point
number).
23 DETECTION_TYPE The detection mechanism used, for example:
SAMPLE-ROLLUP.
24 INTERVAL_COUNT The number of statistics intervals over which the
detection took place (an integer).
25 SEVERITY The severity of the problem: CRITICAL or MAJOR.

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

External Interface for Cause Analysis Scripts


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Associating Cause Analysis Scripts with problems

To allow cause analysis scripts to be called, set the CAUSE-ANALYSIS-SCRIPTS-ENABLED


variable to TRUE.

To associate a cause analysis script with a problem, there must be a description


file in the directory specified by the CAUSE-ANALYSIS-PATH variable (usually,
external_causes/description-files/) and a script in the directory specified by a PATH in the
description file (usually external_causes/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

(Optional - can have more than one)

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.

Sample descriptor le

The file /usr/gsm/config/customer/external_causes/description-files/clever_


script_descriptor contains the following problems and problem causes:

PATH /usr/gsm/config/customer/external_causes/scripts/clever_script.sh

PROBLEM Very high TCH Blocking (%)


CAUSE TCH blocking without congestion
CAUSE RTF outage

PROBLEM High SDCCH Blocking Rate (%)

PROBLEM Very high DROPPED CALL rate (%)


CAUSE Neighbor cell OOS

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.

Output le format for Cause Analysis Scripts

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.

• Optionally, one CAUSE-NAME statement containing a name of a cause to appear in the


NHA, related to the problem referenced by PROBLEM-ID.

CAUSE-NAME cause name for user interface

If there is a CAUSE-NAME statement, then there must be a corresponding


CONFIDENCE-FACTOR statement. This statement must contain the confidence factor
relating to the cause referenced by CAUSE-NAME. It must be one of the following: V.
High, High, Medium, Low, N/A.

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

The field is limited to 500 characters (configurable, using the LINE-OF-REASONING-LIMIT


in the OMC-specific configuration file). If this limit is exceeded, a warning is logged and
truncation of the text occurs.

• 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

This field is limited to 5000 characters (configurable, using the CORRECTIVE-ACTION-


LIMIT in the OMC-specific configuration file). If the Corrective-Action field exceeds this
limit, a warning is logged and truncation of the text occurs.

• 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.

DELETE-CAUSE exact cause name

68P02900W36-P 2-197
1900.2AS May 2008
Sample Cause Analysis Scripts Chapter 2: Using the NHA

Sample output le

The file /usr/gsm/OMCs/OMCONE/external-cause-output/clever_script_


output.txt contains the following problems and problem causes:

PROBLEM-ID 41ceb9alc63d110

CAUSE-NAME Clever Cause


CONFIDENCE-FACTOR High

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

DELETE-CAUSE TCH blocking without congestion

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

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.

• List the active alarms on a device into a cause for a problem.

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.

#Read in available parameters.

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

#Create a temporary output file.


touch /tmp/new.$$

#Problem name is needed to associate with problem in NHA UI.


echo "PROBLEM-ID $PROBLEM_ID" >> /tmp/new.$$

#Enter a cause name if you want a new cause


to be displayed for the problem raised.
#The confidence factor can also be entered here.
echo "CAUSE-NAME Test NHA cause" >> /tmp/new.$$
echo "CONFIDENCE-FACTOR Low" >> /tmp/new.$$

#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

External Interface for Manual Action Scripts


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Associating Manual Action Scripts with causes

To allow manual action scripts to be called, set the MANUAL-ACTION-SCRIPTS-ENABLED


variable to TRUE.

To associate a manual action script with a cause, there must be a description


file in the directory specified by the MANUAL-ACTION-PATH variable (usually,
cause_action_scripts/manual/description-files/) and a script in the directory specified by a
PATH in the description file (usually, cause_action_scripts/manual/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

• Separate the PATH/PROBLEM/CAUSE tag from the path/problem/cause


names with a single space only.
• There must be no white space at the end of any PATH, CAUSE, or
PROBLEM statements.

Sample descriptor le

The file usr/gsm/config/customer/knowledge/cause_action_scripts/manual/description-


files/unknown_cause_descriptor contains the following problems and problem causes:

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

CAUSE No known cause - use CALL TRACE

CAUSE ARFCN frequency planning issue


PROBLEM High daily DROPPED CALL rate (%)

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

• No known cause - use CALL TRACE (with any problem type).

• 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.

Figure 2-73 Example of a Cause Action script

2-202 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Using the DISPLAY variable with Manual Action scripts

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.

• The DISPLAY variable is exported.

• A command is called to launch the application.

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 Manual Action scripts

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.

• List the active alarms on a device to a dtpad window on the UI


(Manual Action scripts only)

• Launch a Call Trace on the device.

• Launch the OMC-R PM GUI in context to the UI


(Manual Action scripts only)

• 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

#Create a temporary output file.


touch /tmp/new.$$

#Some example text


echo "This is a test example action script that
outputs all 23 parameter values." >> /tmp/new.$$
echo "" >> /tmp/new.$$
echo "" >> /tmp/new.$$

#Populate the output file with the below details.

2-204 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Sample Manual Action scripts

echo "INVALID $INVALID" >> /tmp/new.$$


echo "OUTPUT_PATH $DISPLAY" >> /tmp/new.$$
echo "OMC_HOSTNAME $OMC_HOSTNAME" >> /tmp/new.$$
echo "OMC_NAME $OMC_NAME" >> /tmp/new.$$
echo "BSS_NAME $BSS_NAME" >> /tmp/new.$$
echo "SITE_RDN $SITE_RDN" >> /tmp/new.$$
echo "SITE_NAME $SITE_NAME" >> /tmp/new.$$
echo "GSM_CELL_ID $GSM_CELL_ID" >> /tmp/new.$$
echo "CELL_RDN $CELL_RDN" >> /tmp/new.$$
echo "CELL_NAME $CELL_NAME" >> /tmp/new.$$
echo "RDN_CLASS $RDN_CLASS" >> /tmp/new.$$
echo "RDN_INSTANCE $RDN_INSTANCE" >> /tmp/new.$$
echo "DEVICE_DN $DEVICE_DN" >> /tmp/new.$$
echo "BSS_RDN $BSS_RDN" >> /tmp/new.$$
echo "CAUSE_TYPE $CAUSE_TYPE" >> /tmp/new.$$
echo "PROBLEM_TYPE $PROBLEM_TYPE" >> /tmp/new.$$
echo "FIRST_TIME $FIRST_TIME" >> /tmp/new.$$
echo "CALCULATED_VALUE $CALCULATED_VALUE" >> /tmp/new.$$
echo "LAST_TIME $LAST_TIME" >> /tmp/new.$$
echo "FIRST_ANOMALY_TIMESTAMP $FIRST_ANOMALY_TIMESTAMP" >> /tmp/new.$$
echo "NUMBER_OF_REPEATS $NUMBER_OF_REPEATS" >> /tmp/new.$$
echo "PREVIOUS_VALUE $PREVIOUS_VALUE" >> /tmp/new.$$
echo "DETECTION_TYPE $DETECTION_TYPE" >> /tmp/new.$$
echo "INTERVAL_COUNT $INTERVAL_COUNT" >> /tmp/new.$$
echo "SEVERITY $SEVERITY" >> /tmp/new.$$

68P02900W36-P 2-205
1900.2AS May 2008
External Interface for Automatic Action Scripts Chapter 2: Using the NHA

External Interface for Automatic Action Scripts


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Associating Automatic Action Scripts with causes

To allow automatic action scripts to be called, set the AUTOMATIC-ACTION-SCRIPTS-ENABLED


variable to TRUE.

To associate an automatic action script with a cause, there must be a description


file in the directory specified by the AUTOMATIC-ACTION-PATH variable (usually,
cause_action_scripts/automatic/description-files/) and a script in the directory specified by
a PATH in the description file (usually, cause_action_scripts/automatic/scripts/).

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.

Additionally, it is recommended that Automatic Action scripts are tested on a limited


number of problems and causes before setting them up to be run in a widespread
manner.

2-206 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Automatic Action scripts output les

Sample descriptor le

The file /usr/gsm/config/customer/cause_action_scripts/automatic/


description-files/automatic_upload_descriptor contains the following problems and problem
causes:

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.

Automatic Action scripts output les

The Automatic Action script MUST produce an output file to the location specified in the second
parameter ($2) containing one line as follows:

UNIQUE_ID [text of id]

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 Automatic Action scripts

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


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Three sample scripts are provided:


• problem_history.sh which produces a report of previous problems on the selected device
cell

• 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.

These scripts are stored in /usr/gsm/current/knowledge/ui_action_scripts/all/ and, as such,


are provided to NHA users for all problem types.

Adding additional user-dened scripts

To add additional user-defined scripts so that they are available from the Problem pop-up menu,
follow Procedure 2-49:

Procedure 2-49 Adding additional user-dened scripts

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-dened scripts Chapter 2: Using the NHA

Procedure 2-49 Adding additional user-dened scripts (Continued)


3 Store the script in the directory:
/usr/gsm/config/customer/ui_action_scripts/all/
for example:
/usr/gsm/config/customer/ui_action_scripts/all/all_test_script.sh
The script is then available from the user interface.

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

Cyclic Neighbor Statistics


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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
Conguring Cyclic Neighbor Statistics on the NHA Chapter 2: Using the NHA

Conguring Cyclic Neighbor Statistics on the NHA

To configure the Cyclic Neighbor Statistics feature on the NHA, use the following steps:

Procedure 2-50 Conguring Cyclic Neighbor Statistics

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:

• NO-OF-NEIGH-CELLS is used to limit the number of cells per OMC


that the NHA identifies for enabling neighbor statistics on. The default
value is 400.

• NEIGH-STATS-FEATURE is used to turn the feature ON or OFF. By


default, it is OFF.

• In between [NEIGH-STATS-PROBLEMS-BEGIN] and


[NEIGH-STATS-PROBLEMS-END], specify the criteria for
choosing the cells to select. Each line has three comma separated
fields which include the names of problem types, the sort order of the
problem type. They are either ascending (for success rate problems
where the worst values are low) or descending (for failure rate
problems where the worst values are high). The default problem types
and sort orders are as shown in the following example. When editing
the problem names, ensure that the problem names that are put in the
configuration file are the same as the problem types that appear in
the Daily Export file.
For example:
NO-OF-NEIGH-CELLS 400
NEIGH-STATS-FEATURE ON
[NEIGH-STATS-PROBLEMS-BEGIN]
High daily DROPPED CALL rate,1,descending
Low Incoming Handover Success Rate Problem,2,ascending
Low Outgoing INTER-BSS HANDOVER success rate (%),3,ascending
Low Outgoing INTRA-BSS HANDOVER success rate (%),4,ascending
[NEIGH-STATS-PROBLEMS-END]
The feature is now enabled and ready to produce its first output file
on the next occasion the daily export occurs. To disable the feature,
simply edit the OMC-specific configuration file and change the value
of NEIGH-STATS-FEATURE from ON to OFF.
3 Check that the directory /usr/gsm/ne_data/nha_nbrs/ exists on the OMC. If
the directory does not exist then, as user root, create it on the OMC as follows:

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 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.

• It outputs an enable file of recommended cells to the NHA at /usr/gsm/OMCs/<om-


cname>/ea_logs/nha_neighbours[yyyymmdd] and to the OMC at
/usr/gsm/ne_data/nha_nbrs/nha_neighbours.

• 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.

Sample nha_neighbors le

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.

123-45-6789-12345,problem name: Low Incoming Handover Success Rate


Problem,value 62.3
123-45-6789-12346,problem name: Low Incoming Handover Success Rate
Problem,value 71.4
123-45-6789-20341,problem name: Low Outgoing INTER-BSS HANDOVER success
rate (%),value 67.8

NOTE
The OMC only uses the cell name part of the output file. It ignores anything that
is after the first comma.

Using the output on the OMC

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.

OMC users can view the neighbor statistics enable file at


/usr/gsm/ne_data/nha_nbrs/nha_neighbours. This file contains a list of
cells for which the NHA recommends that neighbor cell statistics are enabled. Neighbor cell
statistics can be manually enabled for those cells, using the OMC PM GUI.

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

Displaying recent alarms and events


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of 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.

• Display the number of alarms and events for a SITE.

• Filter the type of alarms and events to be displayed.

• 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

The following is a sample output:

NHA ACTIVE ALARMS AND RECENT EVENTS REPORT 04/02/2005 18:19


BSS: BSS_Cork
Site 27-Mahon
Cell: 123-45-183-12742
Problem: NONE

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

List of Recent Events after Filtering out Excluded

| #0| NOT APPL| *NONE*.| communicationFailureEvent| MMS-NIU|


BSS_Cork(27-Mahon): 27 MMS-NIU 0 0| 30/01/2005 06:02:00.| [13] Bit Error
Hourly Threshold Exceeded| Intermittent (0)| Warning 0/0.| Kit No.
SWLN4403CBC| Device Serial No. X12F1M0TY5| SITE 27 : (27-Mahon): Warning|

| #0| NOT APPL| *NONE*.| communicationFailureEvent| MMS-NIU| BSS_CORK(27-Mahon):


27 MMS-NIU 0 0| 30/01/2005 06:02:00.| [12] Bit Error Daily Threshold Exceeded|
Intermittent (0)| Warning 0/0.| Kit No. SWLN4403CBC| Device Serial No.
X12F1M0TY5| SITE 27 : (27-Mahon): Warning|

| #0| NOT APPL| *NONE*.| equipmentFailureEvent| IAS|


BSS_CORK(27-Mahon): 27 IAS 1| 30/01/2005 09:09:38.| [93] Door Open|
FMIC| Investigate -/-.| SITE 27 : (27-Mahon): Investigate|

| #0| NOT APPL| *NONE*.| equipmentFailureEvent| IAS| BSS_CORK(27-Mahon): 27 IAS


1| 30/01/2005 09:11:22.| [93] Door Open| FMIC| Clear -/-.| SITE 27 :
(27-Mahon): Clear|

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to NHA problems

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.

NHA problem solving process

The NHA provides the following information on each problem it detects:


• Causes identified by the NHA and the suggested corrective actions for these causes.

• Problems occurring on neighbor cells.

• Detector information - this displays formulae and values used to detect the problem.

• Other problems occurring on this device.

• Statistics/Event history - view all the statistics/events for this problem over the previous
24 hours.

• Line of Reasoning used by the NHA during the cause analysis.

3-2 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst List of problems detected by the NHA

List of problems detected by the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Statistics based problems on cells

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

- Very high immediate assignment failure rate 40021


Low immediate assignment success rate problems:
- Low daily immediate assignment success rate 40036
- Very low immediate assignment success rate 40037
SDCCH RF loss rate problems:
- High daily SDCCH RF loss rate 40006
- Very high SDCCH RF loss rate 40022

Continued

68P02900W36-P 3-3
1900.2AS May 2008
Statistics based problems on cells Chapter 3: Problem guide

Table 3-1 Problem list (Continued)


Problem Alarm
Problem type
category number
Outage Channel requests but no calls 40034
Very low call activity 40019
Low number of mobile terminated calls 40072
Timeslots out-of-service on cell 40033
Very low TCH usage 40089
One-Way MTL 40947
Overload Very high TCH blocking 40009
High immediate assignment blocking rate 40035
High GPROC utilization 40043
Paging overflow 40050
High MTL utilization 40087
High estimated RSL utilization 40088
High RSL Utilization 40110
Handover Inter-band handover success problems:
- Low daily handover success rate to GSM1800 40038
- Very low handover success rate to GSM1800 40039
- Low daily handover success rate to PGSM900 40040
- Very low handover success rate to PGSM900 40041
- Low daily handover success rate to EGSM900 40097
- Very low handover success rate to EGSM900 40098
Low Inter-BSS handover attempt rate 40073
Low incoming handover success rate 40051
Low mean time between handovers 40059
Very low mean time between handovers 40060
Outgoing handover success problems:
- Low outgoing Inter-BSS handover success rate (%) 40024
- Low outgoing Intra-BSS handover success rate (%) 40025
- Low outgoing Intra-Cell handover success rate (%) 40026
- Very low outgoing Inter-BSS handover success rate (%) 40027
- Very low outgoing Intra-BSS handover success rate (%) 40028
- Very low outgoing Intra-Cell handover success rate (%) 40029
Low outgoing Inter-RAT handover success rate 40099

Continued

3-4 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Statistics based problems on cells

Table 3-1 Problem list (Continued)


Problem Alarm
Problem type
category number
Handover High handover rate problems:
reason
- Handover attempt rate - Adjacent channel interference 40069
- Handover attempt rate - Band reassign 40070
- Handover attempt rate - Congestion 40068
- Handover attempt rate - Distance 40065
- Handover attempt rate - Downlink interference 40067
- Handover attempt rate - Downlink level 40064
- Handover attempt rate - Downlink quality 40063
- Handover attempt rate - Interband handover 40071
- Handover attempt rate - Uplink interference 40066
- Handover attempt rate - Uplink level 40062
- Handover attempt rate - Uplink quality 40061
Low handover rate problems:
- Low daily handover attempt rate - power budget 40052
- Very low handover attempt rate - power budget 40053
Carrier High Bit Error Rate (BER) 40046
High Frame Erasure Rate (FER) 40045
Path balance issue 40044
High RF losses imbalance on odd or even timeslots 40957
High BER imbalance on odd or even timeslots 40958
High IOI rate - Interference 40959
High IOI rate - Hardware 40960
High RF Losses Out of Proportion to Traffic Carried 40102
GPRS GPRS Requests But No Data 40081
GPRS utilization by Allocation problems:
- High GPRS utilization by Allocation on the downlink% 40083
- High GPRS utilization by Allocation on the uplink% 40082

Continued

68P02900W36-P 3-5
1900.2AS May 2008
Statistics based problems on cells Chapter 3: Problem guide

Table 3-1 Problem list (Continued)


Problem Alarm
Problem type
category number
No GPRS Activity in Cell 40084
High GPRS Timeslot Congestion 40086
GPRS Out Of Service (OOS) problems:
- GPRS OOS in BSS 40049
- GPRS OOS in Cell 40047
- GPRS OOS in Site 40048
High GPRS utilization by Traffic - Uplink 40090
High GPRS utilization by Traffic - Downlink 40091
High PRP load 40096
GPRS Uplink TBF Setup Success Rate problems:
- Low Daily Uplink TBF Setup Success Rate 40100
- Very Low Uplink TBF Setup Success Rate 40101
GPRS Reduced Capacity 40095
High DPROC utilization 40056
High Downlink Block Error Rate 40085
Infrastructure Device not in the MIB 40042
No statistics from BSS 40030
No statistics from Cell 40032
No statistics from Site 40031
Event based Database upload required 40001
GCLK recalibration required problems:
- GCLK recalibration required (multiple sites) 40002
- GCLK recalibration required (single site) 40003
Repeated cell outages 40016
Repeated DRI failure 40017
Repeated DRI-61-62-63 alarms 40015
Timeslot Health detectors:
- Low Daily Activity In Timeslot 40103

Continued

3-6 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Statistics based problems on cells

Table 3-1 Problem list (Continued)


Problem Alarm
Problem type
category number
Script based Device out-of-service (OOS) 40999
Long term detection problems:
- Increased Call Volume 40961
- Increased Dropped Call Rate 40962
- Reduced Call Volume 40963
- Reduced Call Setup Success Rate 40964
BSS-level Low BSS call setup success rate 40931
High BSS drop call rate 40932
High BSS TCH blocking rate at call setup 40933
Low BSS immediate assignment success rate 40934
Low BSS Call Success Rate 40935
Low BSS RF Assignment Success Rate 40936
Low BSS Mean Time Between Drop Calls 40937
High BSS TCH RF Loss Rate 40938
High BSS SDCCH RF Loss Rate 40939
High BSS Immediate Assignment Blocking Rate 40940
High BSS TCH Blocking Rate 40941
High BSS SDCCH Blocking Rate 40942
Low BSS Intra-Cell Handover Success Rate 40943
Low BSS Outgoing Inter-Cell Handover Success Rate 40944
Low BSS Outgoing Intra-BSS Handover Success Rate 40945
Low BSS Outgoing Inter-BSS Handover Success Rate 40946
Consolidated Broken cell issue 40948
problems
BSS-level problem 40999
Capacity issue 40949
Coverage issue 40950
Frequency issue 40951
GCLK issue 40952
GPRS issue 40953
Handover issue 40954
Hardware issue 40955
OOS issue 40956

68P02900W36-P 3-7
1900.2AS May 2008
Knowledge Editor problems Chapter 3: Problem guide

Knowledge Editor problems

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.

External interface problems

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

Call success problems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of call success problems

This section provides information about call success problems, including:


• Low daily call success rate

• Very low call success rate

• High daily dropped call rate

• Very high dropped call rate

• High second assignment rate

• Very high second assignment rate

• Low TCH mean holding time

• Low mean time between drop calls

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.

Formula for detecting this problem

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.

For BSS 1760 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

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.

• Very Low Call Success rate

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

• TCH blocking at call setup

• Call setup assignment success 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

The causes investigated by the NHA are outlined in Table 3-2:

Table 3-2 Causes investigated by the NHA

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

Table 3-2 Causes investigated by the NHA (Continued)


Cause CF
Analysis of Low Call Setup Assignment Success
RF Assignment Success:
- Path balance issues (see Path balance issues, Table 3-4)
- RF issues (see RF issues, Table 3-5)
- Inactive Timeslot Very High
- TCH RF Assignment Failure Very High
Low Directed Retry Success Rate High
Multiband Reassignment Failure High
Detector Statistics Disabled High
Missing Call Setup Assignment Attempts Medium
Low Call Setup Assignment Success Rate High
Low Call Setup Cause Unknown High

Problem auto-clearing

These problems are automatically cleared by the NHA as follows:


• The Low Daily Call Success rate is cleared using the default Daily problem clearance
mechanism.

• 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

Dropped call rate


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

The NHA uses the following formulae to detect this problem:

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]

If OUT_INTER_BSS_HO_FAIL is not NULL, OUT_INTER_BSS_HO_LOSTMS is equal to:

CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_FAIL]
+ CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]

If OUT_INTER_BSS_HO_FAIL is NULL, OUT_INTER_BSS_HO_LOSTMS is equal to:

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.

• Very High Dropped Call rate

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

The causes investigated by the NHA are outlined in Table 3-3:

Table 3-3 Problem causes - dropped call rate

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

These problems are automatically cleared by the NHA as follows:

• 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.

Path balance tests

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

RF issues are outlined in Table 3-5:


Table 3-5 RF issue tests - dropped call rate

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

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.

Formula for detecting this problem

The following formula is used to detect this problem.

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

THEN return TRUE

Problem detectors

For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.

Problem auto-clearing

These problems are automatically cleared by the NHA as follows:


• The High Daily Second Assignment rate problem is automatically cleared from the Problem
window using the default Daily problem clearance mechanism.

• 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

The causes investigated by the NHA are outlined in Table 3-6:

Table 3-6 RF issues - high second assignment

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

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.

Formula for detecting this problem

The following formula is used to detect this problem.

BUSY_TCH_MEAN * Interval Length In Seconds


----------------------------------------------------- < = threshold
RF_LOSSES_TCH + INTRA_CELL_HO_LOSTMS + OUT_INTRA_BSS_HO_LOSTMS +
OUT_INTER_BSS_HO_LOSTMS

If OUT_INTER_BSS_HO_FAIL is not NULL, OUT_INTER_BSS_HO_LOSTMS is equal to:

CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_FAIL]
+ CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]

If OUT_INTER_BSS_HO_FAIL is NULL, OUT_INTER_BSS_HO_LOSTMS is equal to:

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

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.

Formula for detecting this problem

The following formula is used to detect this problem:

BUSY_TCH_MEAN * Detection time in seconds


----------------------------------------------- < = threshold
TOTAL_CALLS + IN_INTER_BSS_HO_SUC + IN_INTRA_BSS_HO_SUC

That is:

Seconds of TCH traffic


----------------------------------
Calls setup + Call handed into the cell

Problem detectors

This problem uses the Daily Roll-up detection mechanism.

For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.

Problem causes

No automatic analysis is performed by the NHA.

The causes investigated by the NHA are outlined in Table 3-7:

68P02900W36-P 3-23
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide

Table 3-7 Problem causes - low TCH mean holding time

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

Immediate assignment problems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of immediate assignment problems

This section provides information about immediate assignment problems, including:


• High daily immediate assignment failure rate

• Very high immediate assignment failure rate

• Low daily immediate assignment success rate

• Very low immediate assignment success rate

• High daily SDCCH RF loss rate

• Very high SDCCH RF loss rate

68P02900W36-P 3-25
1900.2AS May 2008
High immediate assignment failure rate Chapter 3: Problem guide

High immediate assignment failure rate


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula used to detect this problem

The following formula is used to detect this problem:

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

This detector uses the Daily Roll-up detection mechanism.

• Very High Immediate Assignment Failure Rate

3-26 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes

This detector uses the Sample Roll-up detection mechanism.

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

The causes investigated by the NHA are outlined in Table 3-8:

Table 3-8 Problem causes - High immediate assignment failure rate

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

These problems are automatically cleared by the NHA as follows:


• The High Daily Immediate Assignment Failure Rate is cleared using the default Daily
problem clearance mechanism.

• 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

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.

Formulae used to detect this problem

The following formulae are used to detect this problem:

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:

(OK_ACC_PROC [CM_SERV_REQ_CALL + CM_SERV_REQ_SMS + CM_SERV_REQ_SUPP


+ CM_SERV_REQ_EMERG + CM_REESTABLISH + LOCATION_UPDATE +
IMSI_DETACH + PAGE_RESPONSE + LOCATION_SERVICES] ) * 100%
---------------------------------------------------------------------------------
OK_ACC_PROC_SUC_RACH - CHAN_REQ_MS_BLK

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

This detector uses the Daily Roll-up detection mechanism.

• Very Low Immediate Assignment Success Rate

This detector uses the Sample Roll-up detection mechanism.

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.

The causes investigated by the NHA are outlined in Table 3-9:

Table 3-9 Problem causes - Low immediate assignment success rate

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

These problems are automatically cleared by the NHA as follows:


• The Low Daily Immediate Assignment Success Rate problem is cleared using the default
Daily problem clearance mechanism.

• 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

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.

Formula for detecting this problem

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:

RF losses on an SDCCH for mobiles which do appear on the SDCCH


-----------------------------------------------------------------------------------------
Allocated SDCCHs - Mobiles failing to appear on SDCCH

Problem detectors

Two SDCCH RF loss rate problems are reported by the NHA. These are:
• High Daily SDCCH RF Loss rate.

This detector uses the Daily Roll-up detection mechanism.

• Very High SDCCH RF Loss rate.

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.

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.

The causes investigated by the NHA are outlined in Table 3-10:

Table 3-10 Problem causes - SDCCH RF loss rate

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

These problems are automatically cleared by the NHA as follows:


• The High Daily SDDCH RF Loss rate is cleared using the default Daily problem clearance
mechanism.

• 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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of outage problems

This section provides information about outage problems, including:


• Channel requests but no calls

• Very low call activity

• Low number of mobile terminated calls

• Out-of-service timeslots in cell

• Very low TCH usage

• One-way MTL

68P02900W36-P 3-33
1900.2AS May 2008
Channel requests but no calls Chapter 3: Problem guide

Channel requests but no calls


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Call setup troubleshooting

The following description is useful for troubleshooting the stages involved in Call Setup. The
formulae which NHA uses at each stage are shown.

Check if the volume of RACHs is normal

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.

Check if there is a problem getting an Immediate Assignment

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

Procedure 3-1 Allocating an SDCCH or (Fast) TCH channel

1 The mobile must first be sent and acknowledge an Immediate Assignment. If


there are no channels available (blocking), the statistic CHAN_REQ_MS_BLK
is pegged. The mobile does not get an Immediate Assignment message
from the BSS. The Immediate Assignment Blocking Rate is given by:
CHAN_REQ_MS_BLK * 100%
----------------------
OK_ACC_PROC_SUC_RACH

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.

Check the SDCCH RF Loss Rate

After the mobile has successfully accessed the SDCCH, the call can be dropped while still
on the SDCCH.

The SDCCH RF Loss Rate is given by:

RF_LOSSES_SD * 100%
-------------------
ALLOC_SDCCH - CHAN_REQ_MS_FAIL_SDCCH

Drops could be caused by interference, parameter settings, equipment problems, or neighbor


outages.

Check the Call Success Rate

The Call Setup Success Rate measures the success rate in getting from SDCCH (or fast TCH) to
TCH. The formula is:

TOTAL_CALLS + ASSIGNMENT_REDIRECTION[all bins] * 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

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:

Procedure 3-2 Detecting call setup failure

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

MA_REQ_FROM_MSC is pegged when the assignment request for a


TCH is received from the MSC. Some of the reasons for a low MSC
Assignment Attempt Rate are:

• The call drops while it is still on the SDCCH channel (RF_LOSSES_SD).

• The MSC is overloaded.

• The terrestrial links to the MSC are overloaded.

• The MSC refuses the connection (CONN_REFUSED).

• Ciphering fails (CIPHER_MODE_FAIL).

• The MTLs are congested.


2 When an Assignment Request is received from the MSC, the call cannot
be set up if there is TCH blocking and MA_CMD_TO_MS_BLKD is
pegged. The Call Setup TCH Blocking Rate is given by:
MA_CMD_TO_MS_BLKD * 100%
------------------------
MA_REQ_FROM_MSC
Lack of TCH is caused by equipment or neighbor outages, or poor
configuration. (The cell may not have enough capacity for the demand, but this
is not the case when there are no calls.)

Continued

3-36 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae for detecting this problem

Procedure 3-2 Detecting call setup failure (Continued)


3 If a TCH is available, an assignment command is sent to the mobile on
the channel telling the mobile to access the allocated TCH.
The Call Setup Assignment Success Rate measures the
percentage of Channel Requests sent from the MSC during call
setup that result in a successful call setup. The formula is:
(MA_COMPLETE_TO_MSC + ASSIGNMENT_REDIRECTION[all bins]) * 100%
---------------------------------------------------------- X 100%
(MA_REQ_FROM_MSC - MA_CMD_TO_MS_BLKD)

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

Failure in TCH assignment can be due to interference or equipment problems.

Formulae for detecting this problem

The following formulae are used to detect this problem:

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:

OK_ACC_PROC_SUC_RACH - OK_ACC_PROC[LOCATION_UPDATE - IMSI_DETACH -


CM_SERV_REQ_SUPP - LOCATION_SERVICES] - SMS_INIT_ON_SDCCH + SMS_INIT_ON_SD-
CCH_HO_IN - SMS_INIT_ON_TCH_FCS

> a threshold number of channel requests and the total number of calls is zero.

Problem detectors

This problem is detected using 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-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

Very low call activity


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description

This detects a rare condition where there is no mobile activity over a long time.

Formulae for detecting this problem

The following formulae are used to detect this problem:

If cell allows originations:

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:

For BSS version 1760:

OK_ACC_PROC_SUC_RACH - INV_EST_CAUSE_ON_RACH <= tRACH


THEN return TRUE

For BSS version 1800 and 1900:

OK_ACC_PROC_SUC_RACH <= tRACH


THEN return TRUE

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

No analysis is performed by the NHA.

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

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.

Formula for detecting this problem

The following formula is used to detect this problem:

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

No automatic analysis is performed by the NHA.

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

Out of service timeslots in cell


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description

This problem detects out-of-service (OOS) timeslots which reduce a cell's capacity. This can
contribute to congestion issues.

Formula for detecting this problem

The following formulae are used to detect this problem:

For BSS version 1760, the NHA uses the following formula:

Total Timeslots Equipped - GPRS_AVAIL_PDTCH_MEAN - EGPRS_AVAIL_PDTCH_MEAN -


AVAILABLE_TCH_MEAN >= THRESHOLD

For BSS versions 1800 and 1900, the NHA uses the following formula:

IF NOT (cell uses ITS) AND Total Timeslots Equipped


- GPRS_AVAIL_PDTCH_MEAN - EGPRS_AVAIL_PDTCH_MEAN
- AVAILABLE_TCH_MEAN >= THRESHOLD

That is:

The actual number of available traffic channels in the cell is less than the number of TCH
configured in the cell.

The statistic GPRS_AVAILABLE_PDTCH_MEAN counts timeslots configured for GPRS, timeslots


configured for EGPRS are counted by the EGPRS_AVAILABLE_PDTCH_MEAN statistic.

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.

This problem is not raised if the cell is out-of-service.

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

The causes investigated by the NHA are outlined in Table 3-11:


Table 3-11 Problem causes - OOS timeslots in cell

Cause CF
RTF outage Very High
Out of service timeslot Very High
Reduced cell capacity High

Effects of dummy carriers on NHA

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

Very low TCH usage


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

BUSY_TCH_MEAN < = 0

The NHA operator can reconfigure the default threshold value.

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

This problem uses the default Immediate problem clearance mechanism.

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

For every In Service MTL in BSS


IF
mtp_msu_rx = 0
OR
mtp_msu_tx = 0 then
Raise the One-Way MTL problem

Problem detectors

The problem is detected using the Fixed Threshold detection mechanism.

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

No automatic analysis is performed by the NHA.

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of overload problems

This section provides information about overload problems, including:


• High GPROC utilization

• High immediate assignment blocking rate

• High TCH blocking

• Paging overflow

• High MTL utilization

• High estimated RSL utilization

• High RSL utilization

3-48 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High GPROC utilization

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

FOR any GPROC in all SITEs that are not in RXCDRs:


IF CPU_USAGE_MEAN is greater than/equal to the MEAN threshold
AND the CPU_USAGE_MAX is greater than/equal to the MAX threshold
Raise the High GPROC CPU utilization Problem

Threshold values

For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.

Problem causes

The causes investigated by the NHA are outlined in Table 3-12.

Table 3-12 Problem causes - high GPROC utilization

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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

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:

Blocked requests for SDCCH


-----------------------------------------
(Number of RACHs - RACHs with invalid cause)

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

The causes investigated by the NHA are outlined in Table 3-13:

Table 3-13 Problem causes - high immediate assignment blocking

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

High TCH blocking


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description

This problem is concerned with blocking on TCHs at call setup.

TCH blocking results in reduced call processing which prevents mobiles from accessing the
network.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

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

The causes investigated by the NHA are outlined in Table 3-14:

Table 3-14 Problem causes - high TCH blocking

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 overow

Paging overow
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

PCH_Q_PAGE_DISCARD
------------------ X 100
PAGE_REQ_FROM_MSC

That is:

Pages discarded from PCH queue


----------------------------------------------
Paging requests from the MSC

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

No automatic analysis is performed by the NHA.


• Consider either increasing the paging resources in the cell, or reducing the paging load,
for example, replanning the location areas.

• Examine the configuration of paging resources in the problem cell, for example, the values
of ccch-conf and bs_ag_blks_res.

These parameters are outlined in Table 3-15:

68P02900W36-P 3-55
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide

Table 3-15 Paging overow - parameters

Access Grant
CCCH Conguration 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

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.

Formulae for detecting this problem

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

(MTP_MSU_TX * 6 + MTP_SIF_SIO_TX) + (SIB_TX * 7)


------------------------------------------------------------- * 100%
(MTP_LINK_INS * 8)

MTL utilization RX

(MTP_MSU_RX * 6 + MTP_SIF_SIO_RX) + (SIB_RX * 7)


------------------------------------------------------------- * 100%
(MTP_LINK_INS * 8)

For BSS version 1900, the NHA uses the following formulae:

IF MTL::mtl_rate==1

MTL utilization TX

(MTP_MSU_TX * 6 + MTP_SIF_SIO_TX) + (SIB_TX * 7)


------------------------------------------------------------- * 100%
(MTP_LINK_INS * MTL::mtl_rate * 8)

MTL utilization RX

(MTP_MSU_RX * 6 + MTP_SIF_SIO_RX) + (SIB_RX * 7)


------------------------------------------------------------- * 100%
(MTP_LINK_INS * MTL::mtl_rate * 8)

68P02900W36-P 3-57
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide

ELSE IF MTL::mtl_rate==31

HSP MTL Utilisation TX

(MTP_MSU_TX * 9 + MTP_SIF_SIO_TX) + (SIB_TX * 10)


------------------------------------------------------------- * 100%
(MTP_LINK_INS * MTL::mtl_rate * 8)

HSP MTL Utilisation RX

(MTP_MSU_RX * 9 + MTP_SIF_SIO_RX) + (SIB_RX * 10)


------------------------------------------------------------- * 100%
(MTP_LINK_INS * MTL::mtl_rate * 8)

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

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.

Formula for detecting this problem

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:

Estimated RSL utilization Uplink

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

Estimated RSL utilization Downlink

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

Signaling message sizes

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.

Table 3-16 Signaling message sizes

Procedure Uplink Bytes Downlink Bytes


Paging 41
Inter-BSC Handovers 296 262
Intra-BSC Handovers 292 242
Location Updates 191 162
SMS 172 131
Call Setup (Mobile Originating) 417 355
Call Setup (Mobile Terminating) 471 351
Location Services (LCS) 179 165

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

The causes raised by the NHA are outlined in Table 3-17:


Table 3-17 Problem causes - high estimated RSL utilization

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

High RSL Utilization


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of handover problems

This section provides information about handover problems, including:


• Low daily Handover Success rate to GSM1800

• Low daily Handover Success rate to PGSM900

• Very Low Handover Success rate to GSM1800

• Very Low Handover Success rate to PGSM900

• Low handover success rate to EGSM900

• Very low handover success rate to EGSM900

• Low Incoming Handover Success rate (Inter/Intra-BSS)

• Low Inter-BSS Handover Attempt rate

• Low Mean Time between Handovers

• Very Low Mean Time between Handovers

• Low Outgoing Inter-BSS Handover Success rate (%)

• Low Outgoing Intra-BSS Handover Success rate (%)

• Low Outgoing Intra-Cell Handover Success rate (%)

• Very low Outgoing Inter-BSS Handover Success rate (%)

• Very low Outgoing Intra-BSS Handover Success rate (%)

• Very low Outgoing Intra-Cell Handover Success rate (%)

• Low Outgoing Inter-RAT Handover Success rate

3-64 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Interband handover success

Interband handover success


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description

This detector uses the INTERBAND_ACTIVITY statistics to monitor outgoing handovers to


each frequency band.

The statistic PGSM_HO_ATMPT counts all intercell handover attempts, both intra-BSS and
inter-BSS, to a channel in the GSM900 frequency band.

Formula for detecting this problem

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.

Handover Success rate to PGSM900

The NHA uses the following formula:

INTERBAND_ACTIVITY[PGSM_HO_ATMPT] - INTERBAND_ACTIVITY[PGSM_HO_FAIL]
----------------------------------------------------- * 100% < THRESHOLD
INTERBAND_ACTIVITY [PGSM_HO_ATMPT]

and

INTERBAND_ACTIVITY[EGSM_HO_ATMPT] + INTERBAND_ACTIVITY[DCS1800_HO_ATMPT] > 0

Handover Success rate to GSM1800

The NHA uses the following formula:

INTERBAND_ACTIVITY[DCS1800_HO_ATMPT] - INTERBAND_ACTIVITY[DCS1800_HO_FAIL]
------------------------------------------------------ * 100% < THRESHOLD
INTERBAND_ACTIVITY[DCS1800_HO_ATMPT]

and

INTERBAND_ACTIVITY[PGSM_HO_ATMPT] + INTERBAND_ACTIVITY[EGSM_HO_ATMPT] > 0

68P02900W36-P 3-65
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide

Handover Success rate to EGSM900

The NHA uses the following formula:

INTERBAND_ACTIVITY[EGSM_HO_ATMPT] - INTERBAND_ACTIVITY[EGSM_HO_FAIL]
------------------------------------------------------ * 100% < THRESHOLD
INTERBAND_ACTIVITY[EGSM_HO_ATMPT]

and

INTERBAND_ACTIVITY[PGSM_HO_ATMPT] + INTERBAND_ACTIVITY[DCS1800_HO_ATMPT] > 0

that is:

(Unsuccessful intercell handover attempt to a particular frequency band)


----------------------------------------------------------
(Intercell handover attempts to the frequency band)

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.

• Very Low Handover Success rate to PGSM900.

• Low Daily Handover Success rate to GSM1800.

• Very Low Handover Success rate to GSM1800.

• Low Daily Handover Success rate to EGSM900

• Very Low Handover Success rate to EGSM900

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

These problems are automatically cleared by the NHA as follows:


• The Low Daily Handover Success rate problem is automatically cleared from the Problem
window using the default Daily problem clearance mechanism.

• 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

Low incoming handover success rate (inter/intra BSS)


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

This problem is detected using the following formulae:

IN_INTRA_BSS_HO_SUC + IN_INTER_BSS_HO_SUC * 100%


---------------------------------------------------------------------
HO_REQ_ACK_TO_MSC + IN_INTRA_BSS_EQUIP_FAIL + IN_INTRA_BSS_HO_LOSTMS +
IN_INTRA_BSS_HO_RETURN + IN_INTRA_BSS_HO_SUC + IN_INTRA_BSS_HO_CLEARED

That is:

Incoming handover success


------------------------
Incoming handover attempts

Problem detectors

This problem is detected using a Daily 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 causes investigated by the NHA are outlined in Table 3-18:

3-68 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing

Table 3-18 Problem causes - low incoming handover success rate

Cause CF

Inactive timeslot Very high


TCH RF assignment failure Very high
t3105*ny1 timer not optimized High
ho_complete timer not optimized Medium
rr_t3103 timer not optimized Medium
Low incoming handover success rate Very high

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

Low Inter-BSS handover attempt rate


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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)

2. HO_ATMPT (a handover is attempted)

3. HO_SUC (the handover succeeds)

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.

Formula for detecting this problem

This problem is detected using the following formula:

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

This problem uses the default Daily problem clearance method.

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

Low mean time between handovers


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

The NHA detects this problem using the following formula:

BUSY_TCH_MEAN * Interval Length in seconds


------------------------------------------------------------
(OUT_INTER_BSS_HO_SUC + OUT_INTRA_BSS_HO_SUC + INTRA_CELL_HO)

Problem detectors

For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.

Problem causes

The causes investigated by the NHA are outlined in Table 3-19:

Table 3-19 Problem causes - low mean time between handovers

Cause CF
Low mean time between handovers High

Problem auto-clearing

These problems are automatically cleared by the NHA as follows:


• The Low Daily Mean Time Between Handovers problem is automatically cleared from the
Problem window using the default Daily problem clearance mechanism.

• 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

Outgoing handover success rate


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description

The NHA detects poor outgoing handover performance at intra-cell, intra-BSS, and inter-BSS
levels.

Handovers have different outcomes as follows:


• Success.

• Fail and recover.

• Fail and drop.

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.

Formulae for detecting handover problems

The NHA uses the following formulae to detect this problem:

Outgoing Intra-cell handover success

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]

Outgoing Intra-BSS handover success

The NHA uses the following formula to detect this problem:

CELL::OUT_INTRA_BSS_HO [OUT_INTRA_BSS_HO_SUC] * 100%


-----------------------------------------------------
CELL::OUT_INTRA_BSS_HO [OUT_INTRA_BSS_HO_ATMPT]

68P02900W36-P 3-73
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide

Outgoing Inter-BSS handover success

The NHA uses the following formula to detect this problem:

CELL::OUT_INTER_BSS_HO [OUT_INTER_BSS_HO_SUC] * 100%


-----------------------------------------------------
CELL::OUT_INTER_BSS_HO [OUT_INTER_BSS_HO_ATMPT]

In all these cases the formulae can be described as:

(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.

The problems raised are:


• Low outgoing INTER-BSS HANDOVER success rate (%)

• Low outgoing INTRA-BSS HANDOVER success rate (%)

• Low outgoing INTRA-CELL HANDOVER success rate (%)

• Very low outgoing Inter-BSS HANDOVER success rate (%)

• Very low outgoing INTRA-BSS HANDOVER success rate (%)

• Very low outgoing INTRA-CELL HANDOVER success rate (%)

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.

If this problem occurs, enable the per-neighbor statistic OUT_HO_NC_CAUSE_ATTMPT and


OUT_HO_NC_SUC on the problem cell. These statistics detail which neighbor boundary has a
poor handover success rate and what is triggering the handover attempt to that neighbor. Then
examine the handover to that neighbor cells to find the cause of the problem.

3-74 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem auto-clearing

Problem auto-clearing

These problems are automatically cleared by the NHA as follows:


• The Low Handover success rate is cleared using the default Daily problem clearance
mechanism.

• 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

Low outgoing Inter-RAT handover success rate


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

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

This problem is detected using a Daily Roll-up detection mechanism.

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

The causes investigated by the NHA are outlined in Table 3-20.


Table 3-20 Problem causes - low outgoing Inter-RAT handover success

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

Handover reason problems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of handover reason problems

This section provides information about handover reason problems, including:


• High handover rate - Adjacent channel interference

• High handover rate - Band reassign

• High handover rate - Congestion

• High handover rate - Distance

• High handover rate - Downlink interference

• High handover rate - Downlink level

• High handover rate - Downlink quality

• High handover rate - Interband handover

• High handover rate - Uplink interference

• High handover rate - Uplink level

• High handover rate - Uplink quality

• Low daily handover attempt rate - power budget

• Very low handover attempt rate - power budget

3-78 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst High handover rate

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.

Formulae for detecting this problem

The following formulae are used to detect this problem:

Handover Attempt Rate - Uplink Quality

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[UPQUAL] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Uplink Level

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[UPLEVEL] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Downlink Quality

The NHA uses the following formula:

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

Handover Attempt Rate - Downlink Level

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[DOWNLEVEL] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Distance

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[DISTANCE] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Uplink Interference

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[UPINTERF] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Downlink Interference

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[DOWNINTERF] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Congestion

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[CONGESTION] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Adjacent Channel Interference

The NHA uses the following formula:

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

Handover Attempt Rate - Band Reassign

The NHA uses the following formula:

OUT_HO_CAUSE_ATMPT[BAND_RE_ASSIGN] * 100%
------------------------------------
OUT_HO_CAUSE_ATTMPT

Handover Attempt Rate - Interband Handover

The NHA uses the following formula:

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

No automatic analysis is performed by the NHA.

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.

DOWNLEVEL is the number of times an outgoing inter-cell handover is attempted due to


the downlink signal level 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.

DOWNINTERF is the number of times an intra-cell handover is attempted due to downlink


signal interference in the source cell.

POWERBDGT is the number of times an outgoing inter-cell handover is attempted due to


power budget assessment of the signal strength of the source cell compared with neighbor cells.

CONGESTION is the number of times an outgoing inter-cell handover is attempted due to


TCH congestion in the source cell.

ADJ_CHAN_INTF is the number of times an outgoing inter-cell handover is attempted due to


adjacent channel interference, that is, due to the Type 7 microcellular handover algorithm.

BAND_RE_ASSIGN is the number of times a mobile on an SDCCH channel in the non-preferred


band is assigned a TCH channel in the preferred band. See the cell parameters band_pref_mode
and band_preference.

BAND_HANDOVER is the number of times a mobile on a TCH channel in the non-preferred


band is handed over to a TCH channel in the preferred band. See the cell parameters
band_pref_mode and band_preference.

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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

OUT_HO_CAUSE_ATMPT [POWER BUDGET] * 100%


----------------------------------------
OUT_HO_CAUSE_ATMPT

That is:

Handover attempts triggered by Power Budget


---------------------------------------------------
Handover attempts

Problem detectors

For information on default threshold values for each detector, refer to NHA default thresholds
on page 3-181.

Problem causes

No automatic analysis is performed by the NHA.

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

These problems are automatically cleared by the NHA as follows:


• The Low Daily Handover Rate problem is automatically cleared from the Problem window
using the default Daily problem clearance mechanism.

• 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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of carrier problems

This section provides information about carrier statistics problems including:


• High Bit Error Rate

• High Frame Erasure Rate

• Path Balance problem

• High RF Losses Imbalance on Odd or Even Timeslots

• High IOI Rate - Interference

• High IOI Rate - Hardware

• High BER Imbalance on Odd or Even Timeslots

• High RF Losses Out of Proportion to Traffic Carried

68P02900W36-P 3-85
1900.2AS May 2008
High bit error rate Chapter 3: Problem guide

High bit error rate


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

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:

RXQUAL BER (minimum to maximum)


0 0 to 0.2
1 0.2 to 0.4
2 0.4 to 0.8
3 0.8 to 1.6
4 1.6 to 3.2
5 3.2 to 6.4
6 6.4 to 12.8
7 greater than 12.8

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

The causes investigated by the NHA are outlined in Table 3-21:


Table 3-21 Problem causes - high bit error rate

Cause CF
Frequency Planning Issue Medium
General RF Issue Medium
General RF or Coverage Issue Medium

Problem auto-clearing

This problem uses a default Daily type clearance method.

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

High frame erasure rate


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description

This detector finds RF carriers with high frame erasure rate.

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.

Formula for detecting this problem

This formula calculates the percentage of uplink frames, per carrier, that are discarded because
they cannot be decoded.

The NHA uses the following formula to detect this problem:

IF 1760 <= BSS version < 1900


THEN
For every INS radio carrier in CELL (that is, opState/adminState = BUSY/EQUIPPED)
Full Rate: Sum the values of FER_GSM_FR_EFR and FER_AMR_FR for each bin over
the rollup period. Combine the values for the two stats to give an array of
values, BinFR[0..9], for full rate calls on the carrier over the period.
Half Rate: Sum the values of FER_AMR_HR and FER_GSM_HR for each bin over the
rollup period. This gives an array of values, BinHR[0..9], for all half
rate calls on the carrier over the period.
Apply:
100 * ( Sum [i = 1 to 9] (i * contents of BinFR[i] )
+ Sum [i = 1 to 9] (i * contents of BinHR[i]) )
FER = --------------------------------------------------------
( 24 * ( Sum [i = 0 to 9] (contents of BinFR[i]) +
Sum [i = 0 to 9] (contents of BinHR[i]) ) )
ENDIF

3-88 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors

IF BSS version >=1900


THEN
For every INS radio carrier in CELL (that is, opState/adminState = BUSY/EQUIPPED)
Full Rate: Sum the values of FER_GSM_FR_EFR and FER_AMR_FR for each bin over the
rollup period. Combine the values for the two stats to give an array of
values, BinFR[0..9], for full rate calls on the carrier over the period.
Half Rate: Sum the values of FER_AMR_HR and FER_GSM_HR for each bin over the
rollup period. This gives an array of values, BinHR[0..9], for all half
rate calls on the carrier over the period.
Apply:
100 * ( Sum [i = 1 to 9] (i * contents of BinFR[i] )
+ Sum [i = 1 to 9] (i * contents of BinHR[i]) )
FER = --------------------------------------------------------
24 * bss::fer_meas_period * ( Sum [i = 0 to 9] (contents of BinFR[i])
+ Sum [i = 0 to 9] (contents of BinHR[i]) )
ENDIF

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

No automatic analysis is performed by the NHA.

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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

For each Cell


For each Carrier in the Cell
For each statistics interval in the day
IF the path_balance_mean statistic is available (for that carrier in
that interval)
AND the carrier has had sufficient traffic for that interval THEN
count a valid statistics interval
IF path_balance_mean > High Threshold THEN count a high interval ELSE
IF path_balance_mean < Low Threshold THEN count a low interval ENDIF
ENDIF
{ After processing every statistics interval of the day for this carrier }
IF the majority of valid statistics intervals exceeded the High Threshold
OR the majority of valid statistics intervals exceeded the Low Threshold
THEN raise a Path Balance anomaly for the cell ENDIF

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

A number of causes identifying either receiver or transmitter problems can be raised.

The causes investigated by the NHA are:


• Rx Fault - One Carrier Cell

• Tx Fault - One Carrier Cell

• Rx Fault - All Carriers

• Tx Fault - All Carriers

• Rx Fault - One Known Bad Carrier

• Rx Fault - One Bad Carrier

• Tx Fault - One Known Bad Carrier

• Tx Fault - One Bad Carrier

• Rx Fault - N Known Bad Carriers

• Rx Fault - N Bad Carriers

• Tx Fault - N Known Bad Carriers

• Tx Fault - N Bad Carriers

• Possible Radio Equipment fault (default)

For further information about problem causes, refer to Dropped call rate on page 3-14.

Problem auto-clearing

This problem uses the default Daily type clearance method.

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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

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

This problem is detected 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

No causes are reported for script based detectors.

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

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.

This detector can be used to find hardware problems or interference-related problems. By


examining the IOI behavior it is possible to show:
• Interference issues, where the IOI was very low but had high peaks during the day.

• 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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

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

• High IOI Rate - Hardware

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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

For every radio carrier in cell


Calculate the daily total ber_mean values
for each timeslot in the carrier as follows:
Let ts0 = sum(ber_mean0),
Let ts1 = sum(ber_mean1),
Let ts2 = sum(ber_mean2),
Let ts3 = sum(ber_mean3),
Let ts4 = sum(ber_mean4),
Let ts5 = sum(ber_mean5),
Let ts6 = sum(ber_mean6),
Let ts7 = sum(ber_mean7)
Let berrf_total = ts0 + ts1 + ts2 + ts3 + ts4 + ts5 + ts6 + ts7
If berrf_total > 0 then
begin
let berrf_even_per = (ts0 + ts2 + ts4 + ts6) * 100 / berrf_total
let berrf_odd_per = (ts1 + ts3 + ts5 + ts7) * 100 / berrf_total
end

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

This problem is detected 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

No causes are reported for scripts based detectors.

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 Trafc Carried

High RF Losses Out of Proportion to Trafc 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.

Formulae for detecting this problem

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

Sufcient Trafc Test

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.

IF TRAF_CARR_RTF{X} > (625 * total number of intervals in a day)


THEN return TRUE

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

The causes investigated by the NHA are outlined in Table 3-22.


Table 3-22 Problem causes - RF losses out of proportion to trafc carried

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of GPRS problems

This section deals provides information about the following GPRS problems:
• GPRS Requests but no Data

• High GPRS utilization by Allocation (Uplink/Downlink)

• No GPRS Activity in Cell

• High GPRS Timeslot Congestion

• GPRS Out of Service (OOS)

• High GPRS utilization by Traffic (Uplink/Downlink)

• High PRP Load

• GPRS Reduced Capacity

• High Downlink BER

• High GPROC utilization

• High DPROC utilization

• Low Daily Uplink TBF Setup Success Rate

• Very Low Uplink TBF Setup Success Rate

3-102 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst GPRS requests but no data

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.

Formula for detecting this problem

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:

GPRS Requests but no Data

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

High GPRS utilization by allocation


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formulae for detecting this problem

The NHA uses the following formulae to detect this problem:

GPRS utilization by Allocation (Uplink)

UL_BUSY_PDTCH_MEAN
----------------------------------------------------- * 100%
GPRS_AVAILABLE_PDTCH_MEAN + EGPRS_AVAILABLE_PDTCH_MEAN

GPRS utilization by Allocation (Downlink)

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

• High GPRS utilization by Allocation on the Downlink

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:

High GPRS utilization by Allocation

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

No GPRS activity in cell


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Formula for detecting this problem

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 )

The threshold default is 0.

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

This problem is detected using the Interval Roll-up detection mechanism.

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

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:

Used GPRS Cell Bandwidth


------------------------------------------------------
The maximum available GPRS cell bandwidth

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

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

IF GPRS_CONGESTION > y Threshold for the detection period


THEN raise a High GPRS Timeslot Congestion Rate Anomaly

68P02900W36-P 3-111
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide

Calculating the formula

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

Bin Display name Range


0 GPRS_CELL_CONGESTION_25 >= 0%, < 25%
1 GPRS_CELL_CONGESTION_30 >= 25%, < 30%
2 GPRS_CELL_CONGESTION_35 >= 30%, < 35%
3 GPRS_CELL_CONGESTION_40 >= 35%, < 40%
4 GPRS_CELL_CONGESTION_45 >= 40%, < 45%
5 GPRS_CELL_CONGESTION_50 >= 45%, < 50%
6 GPRS_CELL_CONGESTION_55 >= 50%, < 55%
7 GPRS_CELL_CONGESTION_60 >= 55%, < 60%
8 GPRS_CELL_CONGESTION_65 >= 60%, < 65%
9 GPRS_CELL_CONGESTION_70 >= 65%, < 70%
10 GPRS_CELL_CONGESTION_75 >= 70%, < 75%
11 GPRS_CELL_CONGESTION_80 >= 75%, < 80%
12 GPRS_CELL_CONGESTION_85 >= 80%, < 85%
13 GPRS_CELL_CONGESTION_90 >= 85%, < 90%
14 GPRS_CELL_CONGESTION_95 >= 90%, < 95%
15 GPRS_CELL_CONGESTION_100 >= 95%, <= 100%

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

The causes investigated by the NHA are outlined in Table 3-24:


Table 3-24 Problem causes - High GPRS timeslot congestion

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

GPRS Out of Service (OOS)


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Three problem types are detected:


• GPRS OOS in Cell

• GPRS OOS in Site

• GPRS OOS in BSS

Detection

The NHA uses the following formula:

For any cell where GPRS is enabled


If GPRS was OOS in the cell
then raise GPRS OOS in Cell Anomaly against the cell

Anomaly conrmation

The NHA uses the following formula:

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

The NHA uses the following formula:

GPRS is considered OOS


for BSS version >= 1740, if GPRS_AVAILABLE_PDTCH_MEAN +
EGPRS_AVAILABLE_PDTCH_MEAN <= 0

NOTE
The threshold (0) value above is configurable.

Problem detectors

This problem is 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

The default causes are:


• GPRS OOS in Cell
GPRS has been out-of-service in this cell for at least one complete statistics interval and
the cell itself was in service for at least part of this statistics interval. There is at least one
other GPRS cell at this site where GPRS was NOT out-of-service.

• GPRS OOS in Site


GPRS has been out-of-service for at least one complete statistics interval in all the GPRS
cells at this site. GPRS has stayed in service in most of the GPRS cells in the BSS.

• GPRS OOS in BSS


GPRS has been out-of-service for at least one complete statistics interval on most or
all of the in-service GPRS cells in the BSS.

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 Trafc (uplink/downlink)

High GPRS utilization by Trafc (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.

Formulae for detecting this problem

This problem is detected using the following formulae:

68P02900W36-P 3-117
1900.2AS May 2008
Problem detectors Chapter 3: Problem guide

High GPRS utilization by Trafc (Uplink)

For BSS versions 1760 and 1800, the NHA uses the following formula:

((UL_RLC_ACK_NEW_BLKS + UL_RLC_UNACK_NEW_BLKS + UL_RLC_RETX_BLKS) * 100 +


AIR_UL_CONTROL_BLKS)
-------------------------------------------------------------- * 100%
((GPRS_AVAILABLE_PDTCH_MEAN + EGPRS_AVAILABLE_PDTCH_MEAN) * 50 *
Stats interval length in seconds)

For BSS version 1900, the NHA uses the following formula:

((UL_RLC_ACK_NEW_BLKS + UL_RLC_UNACK_NEW_BLKS + UL_RLC_RETX_BLKS +


UL_RLC_NACK_BLKS) * 100 + AIR_UL_CONTROL_BLKS)
-------------------------------------------------------------- * 100%
((GPRS_AVAILABLE_PDTCH_MEAN + EGPRS_AVAILABLE_PDTCH_MEAN)
* 50 * Stats interval length in seconds)

High GPRS utilization by Trafc (Downlink)

For BSS versions 1760 and 1800, the NHA uses the following formula:

((DL_RLC_ACK_NEW_BLKS + DL_RLC_UNACK_NEW_BLKS + DL_RLC_NACK_BLKS +


DL_RLC_RETX_BLKS + DL_RLC_DDTR_BLKS) * 100 + AIR_DL_CONTROL_BLKS)
-------------------------------------------------------------- * 100%
((GPRS_AVAILABLE_PDTCH_MEAN + EGPRS_AVAILABLE_PDTCH_MEAN) * 50 *
Stats interval length in seconds)

For BSS version 1900, the NHA uses the following formula:

((DL_RLC_ACK_NEW_BLKS + DL_RLC_UNACK_NEW_BLKS + DL_RLC_NACK_BLKS +


DL_RLC_RETX_BLKS + DL_RLC_DDTR_BLKS) * 100 + AIR_DL_CONTROL_BLKS)
-------------------------------------------------------------- * 100%
((GPRS_AVAILABLE_PDTCH_MEAN + EGPRS_AVAILABLE_PDTCH_MEAN)
* 50 * Stats interval length in seconds)

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

The problems raised are:


• High GPRS utilization by Traffic (Uplink)

• High GPRS utilization by Traffic (Downlink)

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 trafc (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

Table 3-26 Problem causes - high GPRS utilization by trafc (downlink)

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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

For any PRP and PXP (GSR9) DPROC


IF the PRP_LOAD_MEAN > Threshold
THEN raise High PRP Load Problem

Problem detectors

This problem is 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

The causes investigated by the NHA are outlined in Table 3-27:

68P02900W36-P 3-121
1900.2AS May 2008
Problem auto-clearing Chapter 3: Problem guide

Table 3-27 Problem causes - High PRP load

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

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

The detector uses two statistics; CHANNEL_REQS_REC and UL_PDTCH_SEIZURE, both of


which are pegged by different messages, depending on the type of procedure.

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.

Formula for detecting this problem

The following formula is used to detect this problem.

IF Uplink TBF Setup Success Rate < Threshold


THEN raise an Uplink TBF Setup Success Rate Anomaly against the
Cell

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%

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]

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

This detector uses the Daily Roll-up detection mechanism.

• Very Low Uplink TBF Setup Success Rate

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.

3-124 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem causes

Problem causes

The causes investigated by the NHA are outlined in Table 3-28:


Table 3-28 Problem causes - uplink TBF setup success rate

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

These problems are automatically cleared by the NHA as follows:


• The Low Daily Uplink TBF Setup Success Rate problem is cleared using the default Daily
problem clearing mechanism.

• 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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem.

For any Cell where GPRS Is Enabled


IF ("Maximum number of available GPRS timeslots" > 0)
AND
([ "Maximum number of available GPRS timeslots" < Reserved GPRS Timeslots]
OR
["Maximum number of available GPRS timeslots" < "Number of GPRS timeslots
configured in the Cell"
AND
(AVAILABLE_TCH_MAX - (BUSY_TCH_MAX - (BUSY_TCH_HR_MAX
/ 2) - CELL::gprs_rec_idle_tch) > 0 ])
Then report an Anomaly

Note on the formula

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:

Reserved GPRS Timeslots + Switchable GPRS Timeslots

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

This problem is 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

The causes investigated by the NHA are outlined in :

Table 3-29 Problem causes - reduced GPRS capacity

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

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.

Formula for detecting this problem

The NHA uses the following formula:

DL_RLC_NACK_BLKS * 100
------------------------------------------------------------------------
DL_RLC_ACK_NEW_BLKS + DL_RLC_NACK_BLKS

Problem detectors

This problem is detected using a Daily 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 causes investigated by the NHA are outlined in Table 3-30.


Table 3-30 Problem causes - high downlink block error rate

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

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.

Formula for detecting this problem

The NHA uses the following formula to detect this problem:

For any DPROC in any PCU


If CPU_USAGE_MEAN >= MEAN threshold
AND the CPU_USAGE_MAX is >= MAX threshold
then raise a DPROC utilization Anomaly against the BSS

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

The causes investigated by the NHA are outlined in Table 3-31.


Table 3-31 Problem causes - high DPROC utilization

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of infrastructure problems

This section provides information about infrastructure problems, including:


• Device not in the MIB

• No statistics from BSS

• No statistics from Cell

• No statistics from Site

68P02900W36-P 3-133
1900.2AS May 2008
Device not in the MIB Chapter 3: Problem guide

Device not in the MIB


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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

No automatic analysis is performed by the NHA.

Problem auto-clearing

These problems are automatically cleared by the NHA as follows:


• The problem is automatically cleared from the Problem window using the default
Immediate problem clearance mechanism.

• 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

No statistics from BSS


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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

Disabling this problem

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

This problem is caused when no statistics are received from this


cell even though it is in service. Refer to Table 3-32 for details.

Table 3-32 Problem causes - no statistics from BSS

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

These problems are automatically cleared by the NHA as follows:


• This problem is automatically cleared from the Problem window using the default
Immediate problem clearance mechanism.

• 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

No statistics from Cell


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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 automatic analysis is performed by the NHA.

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

These problems are automatically cleared by the NHA as follows:


• The NHA automatically clears this problem from the Problem window using the default
Immediate problem clearance mechanism.

• 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

No statistics from Site


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

Disabling this problem

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.

Table 3-33 Problem causes - no statistics from SITE

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

These problems are automatically cleared by the NHA as follows:


• This problem is automatically cleared from the Problem window using the default
Immediate problem clearance mechanism.

• 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

Event based problems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

List of event based problems

This section provides information about event based problems, including:


• Database upload required

• GCLK recalibration required (multiple sites)

• GCLK recalibration required (single site)

• Repeated cell failure

• Repeated DRI failure

• Repeated DRI-61-62-63 alarms

3-142 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Database upload required

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.

System generated attributeValueChangeEvents with a username of root or CM MIB are ignored.

Problem causes

There is only one cause for this problem, that is, no database upload.

The causes investigated by the NHA are outlined in Table 3-34:

Table 3-34 Problem causes - database upload required

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

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

• GCLK Recalibration (Multiple site)

depending on whether GCLKs need calibration in one or more sites.

Problem causes

The NHA recommends that GCLKs are recalibrated at one or more sites and identifies the sites.

The causes investigated by the NHA are outlined in Table 3-35:

Table 3-35 Problem causes - GCLK recalibration required

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

Repeated cell failure


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description

This problem identifies cells which are repeatedly taken out-of-service.

Cells repeatedly going OOS are undesirable because:


• There is less call processing and hence loss of revenue in the cell itself.

• 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

Repeated DRI failure


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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.

The causes investigated by the NHA are outlined in Table 3-36:


Table 3-36 Problem causes - repeated DRI failure

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

Repeated DRI-61-62-63 alarms


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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

The problem is detected by:


• More than four alarms of any one number (for example, 4 x DRI 61) occurring in a
30-minute interval on the same DRI,

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.

The causes investigated by the NHA are outlined in Table 3-37:


Table 3-37 Problem causes - repeated DRI-61-62-63 alarms

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

Script based problems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of script based problems

This section provides information about the following script based problems:
• Device out-of-service (OOS and Locked)

• Long term detection including:

- Increased Call Volume

- Increased Dropped Call Rate

- Reduced Call Volume

- Reduced Call Setup Success Rate

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

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.

Two types of problem are reported: OOS and Locked.

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.

Key features of the Device OOS detector

The following is an overview of how the OOS Device detector works:


• The Device OOS detector is run as an external script, the scripts are run each interval.

• 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 algorithm works as follows:


Determine if the device is OOS from the state of the device in the MIB., for example,
if a device is not Busy/Unlocked.

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.

If Site 0 is OOS, then the BSS is OOS.

• 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.

• Problems are not raised for dummy devices.

• 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

The basic algorithm used in the Device OOS scripts is as follows:

{SCRIPT PER DEVICE - Unlocked}


Run this script every statistics interval
IF the deviceState in the MIB_DB is OOS and the adminState is 'Unlocked'
AND IF the device is not a Dummy Device
AND IF the Related Device is INS
THEN raise a problem 'OOS <class_name>' against the Device Class
IF the Device Class is NOT in NHA, then report the problem against the
appropriate device. Report the problem only once per site per interval.
{SCRIPT PER DEVICE - Locked}

3-154 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring Device OOS scripts

IF the adminState of the device in the MIB_DB is 'Locked'


AND IF the Related Device (Site) is not OOS
AND IF the time of last transition was X (Default = 2) hours ago
THEN raise the problem 'Locked <class_name>' against the Device Class
IF the Device Class is NOT in NHA, then report the problem against the
appropriate device. Report the problem only once per site per interval.

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.

Conguring Device OOS scripts

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.

The types of files found on the /usr/gsm/current/knowledge/external_problems directory


are both permanent and created.

68P02900W36-P 3-155
1900.2AS May 2008
Conguring Device OOS scripts Chapter 3: Problem guide

Permanent les in /usr/gsm/current/knowledge external_problems

The permanent files are as follows:


• S_driver_oos.sh - the driver to start the Device OOS detector.

• M _device_oos.sh - the script that operates on the ace files.

• 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.

• commonperl.pl - a file of perl code common to other perl scripts.

• lockfile.pl - creates a lockfile called .lockedfile.txt to ensure that only one iteration
of the script runs every interval.

Created les

The created files in /usr/gsm/OMC<omcname>/external_problems are as follows:


• nha<device>-states-current.txt - the product of the querydevicestatus.pl file.

• nha<device>-dummy-original.txt - the product of querydevicestatus.pl

• Snha-<device>-related.txt - the file containing related device data created by


querydevicestatus.pl

• lockedfile.txt - an invisible file containing a timestamp to ensure that only


one iteration of the S_driver_oos.sh script runs per OMC. This file is found in
/usr/gsm/current/knowledge external_problems.

The created files in /usr/gsm/OMC<omcname>/external_problems/oos-device-data are


as follows:
• .memorylogdevice.txt - tells the script to create a dummy file when removed.

The created files in /usr/gsm/current/knowledge external_problems are as follows


• Snha-<device>-site-Locked.rep - the NHA problem file removed by NHA automatically

• Snha-<device>-site-Unlocked.rep - the NHA problem file removed by NHA


automatically.

NOTE
Errors are logged to the eaAudit file.

3-156 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring Device OOS scripts

Starting and stopping the Device OOS detector

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.

Modifying dummy device lists manually

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

3. Exit and save.

Updating the dummy device lists

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

There are no causes reported for Device OOS problems.

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

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 following problems are detected using long term statistics:


• Reduced Daily Call Setup Success Rate

• Increased Daily Call Volume

• Increased Daily Dropped Call Rate

• Reduced Daily Call Volume

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.

A detailed description of the algorithm for each detector is given below.

Reduced Call Setup Success Rate

For Reduced Call Setup Success Rate, the algorithm is:

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

The configurable defaults are:

REPEATDAYS = 1
THRESHOLD = 3%
DETECTION_PERIOD = 14
MAX_STDDEV = 4
LOW_TRAFFIC_THRESHOLD = 1

Increased Daily Dropped Call Rate

For Increased Daily Dropped Call Rate, the algorithm is:

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.

Lets S = standard deviation of the mean D.

IF S > MAX_STDDEV AND detector is configured to ignore highly variable data

THEN ignore this CELL;

ELSE IF dropped call rate > ( D + (D * 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 Increased Daily Dropped Call Rate directly.

The configurable defaults are:

REPEATDAYS = 1
THRESHOLD = 1.8
DETECTION_PERIOD = 14
MAX_STDDEV = 0.5
LOW_TRAFFIC_THRESHOLD = 1

Call Volume

For Call Volume, the algorithm is:

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

THEN Ignore this CELL


Let CV = mean Call Volume for the DETECTION_PERIOD days previous to today .

IF Call Volume < (CV - (CV * 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 Volume directly.

ELSE IF Call Volume > (CV + (CV * 2.0)) or 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 Increased Daily Call Volume directly.

The configurable defaults are:

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.

Conguring long term detectors

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:

##### Configurables #####

3-162 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Conguring long term detectors

The values are assigned using the Perl syntax

$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.

The following key statistics are calculated at BSS level:


• Call Setup Success Rate

• Drop Call Rate

• TCH Blocking at Call Setup

• Immediate Assignment Success Rate

• Call Success Rate

• RF Assignment Success Rate

• Mean Time Between Drop Calls

• TCH RF Loss Rate

• SDCCH RF Loss Rate

• Immediate Assignment Blocking Rate

• TCH Blocking Rate

• SDCCH Blocking Rate

• Intra-Cell Handover Success Rate

• Outgoing Inter-Cell Handover Success Rate

• Outgoing Intra-BSS Handover Success Rate

• Outgoing Inter-BSS Handover Success Rate

Formulae used to detect this problem

The formulae are the same as the cell-level formulae.

3-164 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae used to detect this problem

BSS Call Setup Success Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Call Setup Success Rate for most recent interval < Threshold
THEN
Raise Low BSS Call Setup Success Rate Problem against this BSS directly.

BSS Drop Call Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Drop Call Rate for most recent interval > Threshold
THEN
Raise High BSS Drop Call Rate Problem against this BSS directly.

BSS TCH Blocking Rate at Call Setup

The NHA uses the following formula:

FOR any BSS


IF BSS::Call Setup TCH Blocking Rate for most recent interval > Threshold
THEN
Raise High BSS TCH Blocking Rate at Call Setup Problem against this BSS directly.

BSS Immediate Assignment Success Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Immediate Assignment Success Rate for most recent interval < Threshold
THEN
Raise Low BSS Immediate Assignment Success Rate Problem against
this BSS directly.

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.

BSS Call Success Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Call Success Rate for most recent interval < Threshold
THEN
Raise Low BSS Call Success Rate Problem against this BSS directly.

68P02900W36-P 3-165
1900.2AS May 2008
Formulae used to detect this problem Chapter 3: Problem guide

BSS RF Assignment Success Rate

The NHA uses the following formula: FOR any BSS


IF BSS::RF Assignment Success Rate for most recent interval < Threshold
THEN
Raise Low BSS RF Assignment Success Rate Problem against this BSS directly.

BSS Mean Time Between Drop Calls

The NHA uses the following formula: FOR any BSS


IF BSS::Mean Time Between Drop Calls for most recent interval < Threshold
THEN
Raise Low BSS Mean Time Between Drop Calls Problem against this BSS directly.

BSS TCH RF Loss Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::TCH RF Loss Rate for most recent interval > Threshold
THEN
Raise High BSS TCH RF Loss Rate Problem against this BSS directly.

BSS SDCCH RF Loss Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::SDCCH RF Loss Rate for most recent interval > Threshold
THEN
Raise High BSS SDCCH RF Loss Rate Problem against this BSS directly.

BSS Immediate Assignment Blocking Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Immediate Assignment Blocking Rate for most recent interval > Threshold
THEN
Raise High BSS Immediate Assignment Blocking Rate Problem against
this BSS directly.

BSS TCH Blocking Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::TCH Blocking Rate for most recent interval > Threshold
THEN
Raise High BSS TCH Blocking Rate Problem against this BSS directly.

3-166 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae used to detect this problem

BSS SDCCH Blocking Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::SDCCH Blocking Rate for most recent interval > Threshold
THEN
Raise High BSS SDCCH Blocking Rate Problem against this BSS directly.

BSS Intra-Cell Handover Success Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Intra-Cell Handover Success Rate for most recent interval < Threshold
THEN
Raise Low BSS Intra-Cell Handover Success Rate Problem against this BSS directly.

BSS Outgoing Inter-Cell Handover Success Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Outgoing Inter-Cell Handover Success Rate for most recent interval
< Threshold
THEN
Raise Low BSS Outgoing Inter-Cell Handover Success Rate Problem against
this BSS directly.

BSS Outgoing Intra-BSS Handover Success Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Outgoing Intra-BSS Handover Success Rate for most recent interval
< Threshold
THEN
Raise Low BSS Outgoing Intra-BSS Handover Success Rate Problem against
this BSS directly.

BSS Outgoing Inter-BSS Handover Success Rate

The NHA uses the following formula:

FOR any BSS


IF BSS::Outgoing Inter-BSS Handover Success Rate for most recent interval
< Threshold
THEN
Raise Low BSS Outgoing Inter-BSS Handover Success Rate Problem against
this BSS directly.

68P02900W36-P 3-167
1900.2AS May 2008
Formulae used to detect this problem Chapter 3: Problem guide

BSS Drop Call Rate formulae

The BSS Drop Call Rate is calculated using the following formulae:

(RF_LOSSES_TCH + INTRA_CELL_HO[INTRA_CELL_HO_LOSTMS] + OUT_IN-


TRA_BSS_HO[OUT_INTRA_BSS_HO_LOSTMS] + OUT_INTER_BSS_HO_LOSTMS) * 100%
------------------------------------------------------------------------
TOTAL_CALLS + ASSIGNMENT_REDIRECTION[DIRECTED_RETRY] + ASSIGNMENT_REDI-
RECTION[DURING_ASSIGNMENT] + ASSIGNMENT_REDIRECTION[MULTIBAND_BAND]+
IN_INTER_BSS_HO[IN_INTER_BSS_HO_SUC]

If OUT_INTER_BSS_HO_FAIL is not NULL, OUT_INTER_BSS_HO_LOSTMS is equal to:

CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_FAIL]
+ CELL::OUT_INTER_BSS_HO[OUT_INTER_BSS_EQUIP_FAIL]

If OUT_INTER_BSS_HO_FAIL is NULL, OUT_INTER_BSS_HO_LOSTMS is equal to:

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]

RF Assignment Success Rate

RF Assignment Success Rate is calculated using this formula:

The following formula is used:

MA_COMPLETE_FROM_MS
----------------------------------- * 100%
MA_CMD_TO_MS

BSS TCH RF Loss Rate

BSS TCH RF Loss Rate is calculated using this formula:

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.

The ASSIGNMENT_REDIRECTION statistics are included in BSS TCH RF Loss Rate


to include call setups which have handed over before being allocated a TCH and
therefore are not already counted in TOTAL_CALLS.

TCH Blocking Rate

For OMC release 1800.56 or later, TCH Blocking Rate is calculated using the following formulae:

For BSS releases prior to 1760.2b-t3, the following formula is used:

ALLOC_TCH_FAIL - ASSGN_RES_REQ_PRE_GSR17602bt3 - HO_REQ_PRE_GSR17602bt3


------------------------------------------------------------------------ x 100 %
ALLOC_TCH + ALLOC_TCH_FAIL - ASSGN_RES_REQ_PRE_GSR17602bt3 -
HO_REQ_PRE_GSR17602bt3

For 1760 BSS releases after 1760.2b-t3, the following formula is used:

ALLOC_TCH_FAIL - ASSIGN_REQ_OZ_OZ_PRE_GSR8 - ASSIGN_REQ_IZ_IZ_PRE_GSR8 -


ASSIGN_REQ_OZ_IZ_PRE_GSR8 - ASSIGN_REQ_IZ_OZ_PRE_GSR8 - HO_REQ_OZ_OZ_PRE_GSR8
------------------------------------------------------------------------ x 100 %
ALLOC_TCH + ALLOC_TCH_FAIL - ASSIGN_REQ_OZ_OZ_PRE_GSR8 -
ASSIGN_REQ_IZ_IZ_PRE_GSR8 - ASSIGN_REQ_OZ_IZ_PRE_GSR8 - ASSIGN_REQ_IZ_OZ_PRE_GSR8
- HO_REQ_OZ_OZ_PRE_GSR8

For 1800 BSS releases after BSS 1800, the following formula is used:

ALLOC_TCH_FAIL - ASSGN_RES_REQ_PRE_GSR18002a - HO_REQ_PRE_GSR18002a


------------------------------------------------------------------- x 100 %
ALLOC_TCH + ALLOC_TCH_FAIL - ASSGN_RES_REQ_PRE_GSR18002a - HO_REQ_PRE_GSR18002a

For BSS release 1800.2a or later, the following formula is used:

ALLOC_TCH_FAIL - ASSIGN_REQ_OZ_OZ - ASSIGN_REQ_IZ_IZ - ASSIGN_REQ_OZ_IZ -


ASSIGN_REQ_IZ_OZ - HO_REQ_OZ_OZ - TCH_PREEMPT_NO_Q_ALLOC_ALL
------------------------------------------------------------------- x 100 %
ALLOC_TCH + ALLOC_TCH_FAIL - ASSIGN_REQ_OZ_OZ - ASSIGN_REQ_IZ_IZ -
ASSIGN_REQ_OZ_IZ - ASSIGN_REQ_IZ_OZ - HO_REQ_OZ_OZ - TCH_PREEMPT_NO_Q_ALLOC_ALL

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:

For BSS 1760, the following formula is used:

ALLOC_TCH_FAIL - TCH_Q_REMOVED[ASSIGNMENT_RESOURCE_REQ] - TCH_Q_REMOVED[HO_REQ]


---------------------------------------------------------------------- x 100 %
ALLOC_TCH + ALLOC_TCH_FAIL - TCH_Q_REMOVED[ASSIGNMENT_RESOURCE_REQ] -
TCH_Q_REMOVED[HO_REQ]

For BSS 1800 and 1900, the following formula is used:

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

SDCCH Blocking Rate

SDCCH Blocking Rate is calculated using this formula:


ALLOC_SDCCH_FAIL
------------------------------ x 100 %
ALLOC_SDCCH + ALLOC_SDCCH_FAIL

Outgoing Inter-Cell Handover Success Rate

Outgoing Inter-Cell Handover Success Rate is calculated using this formula:


(OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_SUC] +
OUT_INTRA_BSS_HO[OUT_INTRA_BSS_HO_SUC] ) * 100%
----------------------------------------------------
OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_ATMPT] + OUT_INTRA_BSS_HO[OUT_IN-
TRA_BSS_HO_ATMPT]

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

Statistic PMGUI name


OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_SUC] OUT_INTER_BSS_HO_SUC
OUT_INTRA_BSS_HO[OUT_INTRA_BSS_HO_SUC] OUT_INTRA_BSS_HO_SUC
OUT_INTER_BSS_HO[OUT_INTER_BSS_HO_ATMPT] OUT_INTER_BSS_HO_ATMPT
OUT_INTRA_BSS_HO[OUT_INTRA_BSS_HO_ATMPT] OUT_INTRA_BSS_HO_ATMPT

3-170 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem detectors

Problem detectors

This detector is used to find the following problems:


• Low BSS Call Setup Success Rate

• High BSS Drop Call Rate

• High BSS TCH Blocking Rate at Call Setup

• Low BSS Immediate Assignment Success Rate

• Low BSS Call Success Rate

• Low BSS RF Assignment Success Rate

• Low BSS Mean Time Between Drop Calls

• High BSS TCH RF Loss Rate

• High BSS SDCCH RF Loss Rate

• High BSS Immediate Assignment Blocking Rate

• High BSS TCH Blocking Rate

• High BSS SDCCH Blocking Rate

• High BSS Intra-Cell Handover Success Rate


• High BSS Outgoing Inter-Cell Handover Success Rate

• High BSS Outgoing Intra-BSS Handover Success Rate

• High BSS Outgoing Inter-BSS Handover Success Rate

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

No causes are reported for script based detectors.

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 consolidation is achieved through an external script-based detector that provides a


simple mechanism to consolidate related problems. The script identifies related problem(s) on
the same cell, using the problem log files as a source. Depending on the types of problem found
on the cell, a single “umbrella” external problem is raised. Subscriptions can then be created on
the UI that contain only these consolidated problems. Operators who use these subscriptions
should see a much reduced number of problems. However, by viewing a problem in the Problem
window they can still see every other problem raised against the cell.

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.

The data sources for the scripts are:


• The NHA problem logs (eaProblems) stored in the OMC-specific logs directory:
/usr/gsm/OMCs/<omcname>/ea_logs.

These provide the information on the problem types raised.

• A list of all cells and their neighbor cells from the MIB in the following format:

Site | CELL | Neighbour-CELL of CELL | Site containing Neighbour-CELL

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]

These are infrastructure issues and are treated separately.

• BSS level problems

Refer to BSS-level detectors on page 3-164.

• 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.

Formulae for detecting this problem

This NHA detector raises problems in the order listed below. The following formulae are used:

Broken Cell

The NHA uses the following formula:

IF a CELL has any of the following problems for the interval:


Channel requests but no calls
Very Low TCH Usage
Low Number of Mobile Terminated Calls
Low Daily Activity In Timeslot
Very low call activity
Repeated cell outages
THEN raise Broken Cell Consolidated Problem against the CELL.
Do not raise any other consolidated problems
(except GPRS problems) against this CELL.
ENDIF

BSS level problem

The NHA uses the following formula:


IF a BSS has 10 or more instances of the same <problem
type> for the interval (excluding consolidated problems)
THEN raise BSS <problem type> Consolidated against the BSS.

Do not raise any other consolidated problems (except


GPRS problems) against the BSS or cells under this BSS.
ENDIF

3-174 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Formulae for detecting this problem

OOS Site/Cell problem

The NHA uses the following formula:


IF a SITE has an OOS Site problem for the interval OR has an
OOS Cell Problem for a cell contained in the SITE for the interval:
THEN raise OOS Issue Consolidated against SITE.
Do not raise any other consolidated problems (except GPRS problems) against SITE.
Do not raise any other consolidated problems (except
GPRS problems) against neighbors of cells at SITE.
ENDIF

Hardware issues

The NHA uses the following formula:


IF a CELL has any of the following problems raised for the current interval:
Path Balance Issue
High IOI Rate Hardware
High Rf Losses Imbalance On Odd Or Even Timeslots
High BER Imbalance on Odd Or Even Timeslots
THEN raise Hardware Issue Consolidated against CELL.
Do not raise any other consolidated problems (except
GPRS problems) against CELL or neighbors of CELL.
ENDIF

Frequency related problem

The NHA uses the following formula:


IF a CELL has any of the following causes raised
against any problem for the current interval:
High BER with Frequency Reuse
High BER but no Frequency Reuse
High FER with Frequency Reuse
High FER but no Frequency Reuse
High IOI with Frequency Reuse
High IOI but no Frequency Reuse
AND NOT the following cause for any problem:
General RF or coverage issue
THEN raise Frequency Issue Consolidated against CELL.
Do not raise any other consolidated problems (except
GPRS problems) against CELL or neighbors of CELL.
ENDIF

68P02900W36-P 3-175
1900.2AS May 2008
Formulae for detecting this problem Chapter 3: Problem guide

Handover issues

The NHA uses the following formula:


IF any CELL has any of the following problems raised for the current interval:
Low Outgoing INTER-BSS HANDOVER Success Rate (%)
Low Outgoing INTRA-BSS HANDOVER Success Rate (%)
Very low outgoing INTER-BSS HANDOVER success rate (%)
Very low outgoing INTRA-BSS HANDOVER success rate (%)
AND any neighbor of the cell has a Low Incoming Handover
Success Rate Problem (%) for the current interval
THEN raise Handover Issue Consolidated against CELL.
Do not raise any other consolidated problems (except GPRS problems) against CELL.
ENDIF

Coverage related problem

The NHA uses the following formula:


IF any CELL that has a problem with the cause
"General RF or coverage issue" for the current interval
THEN raise Coverage Issue Consolidated against CELL.
Do not raise any other consolidated problems (except GPRS problems) against CELL.
ENDIF

Capacity related problem

The NHA uses the following formula:


IF any CELL has any of the following problems for the current interval:
High Immediate Assignment Blocking Rate
Very high TCH Blocking (%)
High Handover Rate - Congestion (%)
Paging Overflow Problem (%)
THEN raise Capacity Issue Consolidated against CELL.
Do not raise any other consolidated problems (except
GPRS problems) against CELL or neighbors of CELL.
ENDIF

GPRS related problem

The NHA uses the following formula:


If a CELL has any GPRS problem for the current interval
THEN raise GPRS Issue Consolidated against CELL.
ENDIF

GCLK related problem

The NHA uses the following formula:


IF any SITE has a GCLK recalibration required (multiple sites)
or GCLK recalibration required (single site) problem for the current interval
THEN raise a GCLK Issue Consolidated against SITE.
Do not raise any other consolidated problems (except
GPRS problems) against SITE or cells within SITE.
ENDIF

3-176 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Problem conrmation

Problem conrmation

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 type Value displayed


Broken Cell Issue Consolidated Number of problems on the problem cell in
ALL-PROBLEMS list
Hardware Issue Consolidated
Frequency Issue Consolidated
Handover Issue Consolidated
Coverage Issue Consolidated
Capacity Issue Consolidated
BSS <problem> Consolidated Consolidated Number of problems on
problem BSS in ALL-PROBLEMS of type
<problem>
OOS Issue Consolidated Number of problems on problem SITE in
ALL-PROBLEMS list
GCLK Issue Consolidated
GPRS Issue Consolidated Number of problems on problem cell in
GPRS-PROBLEMS list

Problem causes

No cause is reported for these problems.

Problem clearing

There are two clearing times for consolidated problems:


• Short clearing time: 2 hours

• Long clearing time: 25 hours

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:

BSS | Site | Cell | Problem Type | Date and Time | Value

3-178 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Customized problems

Customized problems
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

For further information, refer to Editing Knowledge on page 2-162.

68P02900W36-P 3-179
1900.2AS May 2008
External interface problems Chapter 3: Problem guide

External interface problems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to external interface problems

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

NHA default thresholds


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

• T2 - Default thresholds for an average network

• T3 - Thresholds for a good network

• T4 - Thresholds for a very good 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

NHA automated thresholds


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to NHA automated thresholds

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.

• Thresholds Calculator script

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

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.

• Global detectors, script-based detectors, and customer-defined detectors are excluded.

• 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:

Detector Name, Problem Name, Sort-type, Max, Busy, Normal, Quiet

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 Denitions 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

This is not a requirement and is not validated by the script.


sort-type This is either blank or “-r” depending on the problem type. For “Failure”
type problems it should be -r (higher values are worse) and for “Success”
type problems it should be blank (higher values are better).

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.

The default values to be used are contained in the file /usr/gsm/cdrom_install/tem-


plates/problem-threshold.csv.

Algorithm

The Problem Reducer script uses the following algorithm:

Create a list of all problem types, ALL_PROBLEMS,


raised for the previous day (from the eaProblems file)
FOR EACH PROBLEM_TYPE in ALL_PROBLEMS {
IF PROBLEM_TYPE is not included in the configuration file
THEN
Skip this PROBLEM_TYPE
ELSE Adjust the thresholds for PROBLEM_TYPE
ENDIF
} FOR EACH

Adjusting the thresholds

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.

The configurable AUTO-IMPORT-THRESHOLD-ON must be set to ON for the thresholds to be


automatically imported from this file. The value of the threshold is modified per cell group
using the following algorithm:

FOR EACH cell group (BUSY, NORMAL, QUIET) {


Sort the problems of type PROBLEM_TYPE by value, worst values first
Set COUNTER = 0
FOR EACH sorted VALUE {
Increment COUNTER IF COUNTER = maximum number of problems
for this cell group (max_busy, max_normal or max_quiet)
THEN
Change the threshold for this PROBLEM_TYPE for this cell group to VALUE
Add message to the audit log file that the
thresholds have been adjusted for this problem type
Exit loop
ENDIF
} FOR EACH
} FOR EACH

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

Customer-defined changes must be maintained through NHA upgrades. In particular, any


changes to the script configuration file should not be lost. However any Motorola-defined
changes in a future release (such as new problem types in the configuration file, or changes to
detector names) could also be included by modifying the configuration file.

Using the Thresholds Calculator script

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:

(For each detector formula F in the list of formulae (


Calculate the mean (m) and standard deviation (sd) of F for all cells in GROUP
over the past D days where D is the number of days of statistics available in
the PM database (by default D = 7; but see note below). This results in a
single mean and standard deviation for each formula for the whole cell group.
Calculate the new threshold for this detector.
Update the thresholds with the new threshold value for this detector for GROUP.
Add message to the audit log file that the thresholds have been adjusted for this
problem type and cell group. ) )

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

Calculation of new thresholds

New thresholds are calculated as follows:

m ± (sd * (weight + x))

The value of weight is dependent on the cell group. The default values are as follows:

Cell Group Weight


BUSY 2
NORMAL 3
QUIET 4

These values are configured by the user.

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.

Table 3-41 Calculating new thresholds

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

Adjusting the thresholds

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.

Audit log information

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

The following administration tasks are described:


• Introduction to starting and stopping the NHA on page 4-4

• Starting the NHA on page 4-5

• Stopping and restarting the NHA on page 4-7

• NHA directory structures on page 4-11

• NHA licenses on page 4-14

• NHA hardware requirements on page 4-19

• NHA troubleshooting on page 4-21

• Troubleshooting mounts on page 4-28

• Generating a new ssh key in NHA on page 4-30

• Check OMC Informix settings on page 4-32

• NHA log files on page 4-33

• Daily exports of key statistics on page 4-37

• Web access on page 4-44

The following configuration tasks are described:


• NHA configuration files (ea.cfg) on page 4-45

• User added statistics on page 4-49

• Viewing problems as alarms on the OMC on page 4-51

• NHA Monitoring Schedule on page 4-55

• Using the cell grouping script on page 4-57

• NHA threshold files on page 4-59

4-2 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst In this chapter

• Setting up the NHA for printing on page 4-61

• Checking OMC configuration on page 4-62

• Configuring the recent alarms and events feature on page 4-75

• Configuring NHA for long term statistics viewing and monitoring on page 4-79

The following system administration tasks are described:


• Time on the NHA on page 4-81

• Sending E-mail from the NHA on page 4-82

• Installing NHA UI software on a GUI server or client on page 4-84

• Setting up the NHA menu option on page 4-86

• Installing NHA UI software on a PC on page 4-88

• Setting client machines for remote login on page 4-92

• Adding an OMC to be monitored on page 4-96

• Deleting an OMC from the NHA on page 4-98

• Uninstalling the NHA from a GUI server or client on page 4-101

• Adding new users on page 4-102

• Backing up file systems on page 4-104

• 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

Introduction to starting and stopping the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Starting and stopping the NHA - overview

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.

Only user omcadmin is allowed to start or stop the NHA.

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.

• Stopping and restarting the NHA on page 4-7.

4-4 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Starting the NHA

Starting the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Starting the NHA from the command line

To start the NHA from the command line, perform the following steps:

Procedure 4-1 Starting NHA from the command line

1 Log on to the NHA processor as user omcadmin.


2 At the system prompt, execute the following command:
NHA start
If more than one OMC is available, a list of current OMCs is displayed.
3 Select the OMC to which the NHA is to be connected.
NHA% NHA start

Which OMC do you want to connect to?

1. OMCONE
2. OMCTWO

[1-2,i=more info,q=quit] 1

Please enter a name for this NHA: [OMCONE]

Please enter a code for this NHA: [OE]

NHA%
Checking TCP/IP port availability.

NHA component Port no. Status


-------------------------------------
EvA 1392 available
Ipm 1393 available
Diag 28220 available

All ports available.

Starting NHA

Continued

68P02900W36-P 4-5
1900.2AS May 2008
Starting the NHA from the command line Chapter 4: Administration

Procedure 4-1 Starting NHA from the command line (Continued)

NOTE

• It is not possible to connect more than one NHA from the


same NHA processor to any one OMC. However, if the need
arises, it is possible to connect NHAs from different NHA
processors to a single OMC.
• If /usr/gsm is 100% full, the NHA does not initialize.

4-6 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Stopping and restarting the NHA

Stopping and restarting the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Stopping the NHA from the NHA UI

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:

Procedure 4-2 Stopping NHA from the UI

1 As user omcadmin, select the <omcname> shutdown option from the


Shutdown menu.
A message is displayed on the Shutdown OMC NHA Server window as in
Figure 4-1.

Figure 4-1 Shutting down the OMC NHA server

2 Click Yes to restart the NHA automatically after shutdown or No if


the NHA is to be restarted manually. For further information on
restarting the NHA, refer to Restarting the NHA below.

If Yes is selected, a shutdown warning message is displayed. Refer to


Figure 4-2. The operator is reminded that the NHA automatically
restarts after five minutes. Click Yes to continue. A Connections Lost
message is displayed.

Continued

68P02900W36-P 4-7
1900.2AS May 2008
Stopping the NHA from the command line Chapter 4: Administration

Procedure 4-2 Stopping NHA from the UI (Continued)

Figure 4-2 Shutdown warning message

Otherwise, if No is selected, a similar warning message is displayed but the


operator is reminded to restart the NHA manually. Click Yes to continue. A
Connections Lost message is displayed.
3 Click OK to dismiss the Connections Lost dialog box.

Stopping the NHA from the command line

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:

Procedure 4-3 Stopping NHA from the command line

1 Log on as user omcadmin.


2 At the system prompt, execute the following
command NHA stop as in the following example.

NHA% NHA stop


Only one NHA available.
3 Select the NHA to be stopped if more than
one NHA is running and confirm this choice.

NHA selected: OMCONE


This option is only provided as a means to stop
the NHA Processor because of a network problem or
Telewindows cannot be run to shut down the NHA
WARNING: if you proceed, current problems will be lost.
4 To shut down the NHA, type Yes; otherwise, type No.

Continued

4-8 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Restarting the NHA

Procedure 4-3 Stopping NHA from the command line (Continued)


Are you sure you want to kill this NHA (Type Yes to confirm) ?
Yes
Shutting down, Please wait ...
Do you wish to restart this NHA? (Type Yes to confirm)
No
NHA OMCONE: processes have shut down.
Shutdown complete.
NHA processes will only be stopped after answering both questions.
5 To restart the NHA automatically after shutdown, type Yes; otherwise, type
No.

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 the NHA is not functioning properly.

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

Automatic NHA restarts

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.

Shutdown of the OMC-R or NHA

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
Congurable 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.

Congurable startup options

It is possible to configure the NHA (on a per OMC basis) in different ways that determine how
it behaves after a startup:

Number of statistic intervals to read

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.

Restoring problems from before the restart

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

NHA directory structures


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

• On GUI servers or clients.

On the NHA machine

The following directories are present on the NHA machine (refer to Table 4-1):
Table 4-1 NHA directory structure

Directory Sub-directory Contents


NHA startup scripts
/usr/gsm/current/ bin
miscellaneous global
config configuration data
tools provided with the NHA
ea_tools
all G2 code
g2
all bridge executables - EB,
gsi SB, CB
installation scripts
install
all G2 knowledge code
knowledge
libraries required by the
lib1800/lib1900 config bridge
licensing tools
nha_lc_tools
maintenance scripts
sbin
startup script for the config
cb.start bridge

Continued

68P02900W36-P 4-11
1900.2AS May 2008
On the OMC Chapter 4: Administration

Table 4-1 NHA directory structure (Continued)


Directory Sub-directory Contents
config data relating to OMC
/usr/gsm/OMCs/<omcname>/ config
logs stored for NHA for this
ea_logs OMC
external problem files
external problems
mounted from OMC
mibconfig (usr/gsm/current/config)
mounted from the
ne_data OMC processor
(/usr/gsm/ne_data)
automatic cell grouping files
nha_grouping
NHA-wide configuration data
/usr/gsm/config
NHA web home directory
/usr/gsm/config local
location for customer defined
/usr/gsm/config customer scripts
installation scripts
/usr/gsm/cdrom_install
cutover script
/usr/gsm/sbin
NHA-wide logs
/usr/gsm/ea_logs
Gensym software
/opt/gensym/current
Java engine
/opt/java

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

Table 4-2 Directory structure on the OMC (Continued)


Directory/le Contents
Informix configuration files
/usr/informix/etc/sqlhosts_OMC
sqlhosts_MIB
port numbers for Informix access
/etc/services
OMC host table
/etc/hosts

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.

• Tcl/tk scripting language installed in /usr/local/bin/

• Apache web server installed in /usr/local/apache2/

68P02900W36-P 4-13
1900.2AS May 2008
NHA licenses Chapter 4: Administration

NHA licenses
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to NHA licenses

This section advises the NHA administrator about the operation of the NHA licenses.

The NHA requires two license files to operate correctly:


• G2 license file

• NHA license file

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.

NHA license feature

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 NHA UI clients that are run simultaneously.

• The number of Traffic Channels (TCHs) on the OMCs that the NHA monitors.

• The expiry date.

Motorola allocates these licenses depending on the commercial agreements with the customer.

Checking NHA license details

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

Output like the following is displayed:

4-14 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Checking NHA license details

SERVER snhasys1 80ca0226 1760


VENDOR omcd /usr/gsm/current/nha_lc_tools/omcd
FEATURE nha_server omcd 1.000 30-apr-2005 3 91FF62964FE6 \
VENDOR_STRING="REMINDER_PERIOD=30 CUSTOMER_CODE=0" \
ISSUED=07-aug-2004 ck=160
FEATURE nha_client omcd 1.000 30-apr-2005 20 F04895F05E48 \
VENDOR_STRING="REMINDER_PERIOD=30 CUSTOMER_CODE=0" DUP_GROUP=D \
ISSUED=07-aug-2004 ck=56
FEATURE nha_omcmax omcd 1.000 30-apr-2005 3 507CD50D78A1 \
VENDOR_STRING="REMINDER_PERIOD=30 CUSTOMER_CODE=0 \
RTF_LIMIT=60000 THRESHOLD_PERCENTAGE=10" ISSUED=07-aug-2004 \
ck=187

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

Output like the following is displayed:

lmstat - Copyright (C) 1989-1997 Globetrotter Software, Inc.


Flexible License Manager status on Tue 4/26/2005 11:23
License server status: 1760@snhasys1
License file(s) on snhasys1: /usr/gsm/config/local/license_file:
snhasys1: license server UP (MASTER) v6.0
Vendor daemon status (on snhasys1):
omcd: UP v6.0
Feature usage info:

Users of nha_server: (Total of 2 licenses available)


"nha_server" v1.000, vendor: omcd
floating license
omcadmin snhasys1 /dev/tty (v1.0) (snhasys1/1760 119), start Tue 4/26 10:56
omcadmin snhasys1 /dev/tty (v1.0) (snhasys1/1760 319), start Tue 4/26 11:18

Users of nha_client: (Total of 6 licenses available)


"nha_client" v1.000, vendor: omcd
floating license
omcadmin snhasys1 234.5.67.151 (v1.0) (snhasys1/1760 604), start Tue 4/26 11:19
keane snhasys1 234.5.67.153 (v1.0) (snhasys1/1760 606), start Tue 4/26 11:21
beckham snhasys1 234.5.67.154 (v1.0) (snhasys1/1760 607), start Tue 4/26 11:23

68P02900W36-P 4-15
1900.2AS May 2008
Updating NHA license les Chapter 4: Administration

Users of nha_omcmax: (Total of 2 licenses available)


"nha_omcmax" v1.000, vendor: omcd
floating license
omcadmin snhasys1 /dev/tty (v1.0) (snhasys1/1760 219), start Tue 4/26 11:00
omcadmin snhasys1 /dev/tty (v1.0) (snhasys1/1760 419), start Tue 4/26 11:22

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 about licenses

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

08:46:13| |ipm |cui | <NHA_LC> Allocated a client license for CUI


( 19.556.118.160:0 ).
09:12:36| |ipm |nha-lice| <NHA_LC> _nha_lc_check_handles -
successfully returned client license ( "19.556.118.160:0", "3")
17:45:22| |diag |prui | <NHA_LC> Allocated a PRUI client license
( 19.556.118.162:0.0 )
19:07:40| |eva |nha-lice| <NHA_LC> nha_omcmax: Invalid parameter

Updating NHA license les

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 NHA UI clients that are allowed to run simultaneously.

• The number of Traffic Channels (TCHs) on the OMCs that the NHA monitors.

• The expiry date of the NHA license.


(Normally, these licenses are issued annually.)

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

Procedure 4-4 Installing license details

1 Enter the following command on the NHA processor as user root:


/usr/gsm/current/sbin/nha_populate_license
The following output is displayed:

===============================
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 license issued date, for example, 01-nov-2005.

• The license expiry date, for example, 31-oct-2006.

• The number of server licenses, for example, 4.

• The NHA server license key, for example, 69839A881CF9.

• The NHA server license checksum, for example, 81.

• The number of NHA client licenses, for example, 22.

• The NHA client license key, for example, 0F1933B790096.

• The NHA client license checksum, for example, 104.

• The NHA OMC traffic channel limit, for example, 30000.

• 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

Procedure 4-4 Installing license details (Continued)


The following output is displayed:
lmstat - Copyright (C) 1989-1997 Globetrotter Software, Inc.
Flexible License Manager status on Tue 4/26/2005 11:23
License server status: 1760@snhasys1
License file(s) on snhasys1:
/usr/gsm/config/local/license_file:
snhasys1: license server UP (MASTER) v6.0
Vendor daemon status (on snhasys1):
omcd: UP v6.0
Feature usage info:Users of nha_server:
(Total of 2 licenses available)
"nha_server" v1.000, vendor: omcd
floating license
omcadmin snhasys1 /dev/tty (v1.0)
(snhasys1/1760 119), start Tue 4/26 10:56
omcadmin snhasys1 /dev/tty (v1.0) (snhasys1/1760 319), start Tue
4/26 11:18Users of nha_client: (Total of 6 licenses available)
"nha_client" v1.000, vendor: omcd
floating license
omcadmin snhasys1 234.5.67.151 (v1.0)
(snhasys1/1760 604), start Tue 4/26 11:19
keane snhasys1 234.5.67.153 (v1.0)
(snhasys1/1760 606), start Tue 4/26 11:21
beckham snhasys1 234.5.67.154 (v1.0)
(snhasys1/1760 607), start Tue 4/26 11:23

Users of nha_omcmax: (Total of 2 licenses available)


"nha_omcmax" v1.000, vendor: omcd
floating license
omcadmin snhasys1 /dev/tty (v1.0)
(snhasys1/1760 219), start Tue 4/26 11:00
omcadmin snhasys1 /dev/tty (v1.0) (snhasys1/1760 419),
start Tue 4/26 11:22
7 Check that the new license file is operating properly by launching a NHA UI.
Ensure that the NHA UI launches correctly, with an appropriate message
in the Audit files.

4-18 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst NHA hardware requirements

NHA hardware requirements


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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 specication

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.

NHA platforms supported

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

SUN SunFire V440 and Netra N440

This platform is shipped in two configurations:

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 conguration - SUN SunFire V440 and Netra N440

Maximum number Total kTCH @ Total kTCH @


Platform
of cells supported 2RTF/cell 4RTF/cell
SunFire V440 and Netra N440 medium 13000 180 360
configuration
SunFire V440 and Netra N440 large 16440 225 450
configuration

NHA diskspace requirements

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

NHA UI client requirements on a GUI server or client

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.

NHA UI client requirements on a PC

The minimum recommended configuration of the PC is:


• Pentium II 266 MHz

• 128 MB of RAM

• 256-bit color display

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

• Investigate an NHA shutdown.

• Check NHA processes and log files.

• Check if audit log files are written to.

• Check error messages.

• Check disk space usage.

• Check event logs processes.

• Check statistics processing.

• Troubleshoot performance issues.

• Check for "too many" problem messages.

• Check NHA system performance statistics.

• Get the best performance from the UI.

Check NHA status and health

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

Output like the following is displayed:

NHA% NHA status


The following NHAs are running on this machine:

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.

Output like the following is displayed:

NHA% NHA health


Current time: Tue Apr 26 10:42:55 GMT 2005
Status of NHA processor ea-mid based on log files for Mon Apr 25 2005
Date and time of last reboot: Apr 18 01:31

=====================================================
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.

Investigate an NHA shutdown

If the NHA is regularly shutting down, check the audit logs for FATAL errors as follows:

cd /usr/gsm/OMCs/<omcname>/ea_logs

grep FATAL /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<yyyymmdd>

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

Check NHA processes and log les

Check the NHA processes using the following command:

/usr/ucb/ps -auxww | grep <omcname>

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

Check if audit log les are written to

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>

Use CTRL+C to exit from this command.

Check error messages

To check the audit log files for errors, use the following command:

grep ERROR /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<yyyymmdd>

Investigate errors that are unexplained with the local support engineer and/or the relevant
Customer Network Resolution Centre (CNRC).

Check disk space usage

The automatic script /usr/gsm/current/sbin/monitor_diskspace is run as a root cron job. The


script measures the disk usage on the root (/) and /usr/gsm/ partitions. If the disk usage is
greater than a configurable upper limit (default 95%), then it removes the oldest files from the
/usr/gsm/OMCs/<omcname>/ea_logs directories until a configurable lower limit (default
85%) is reached. If files are removed automatically, an E-mail is sent to the omcadmin user.

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

Check event logs processes

To check that event log files are being read properly by the NHA, use the following command:

grep 20107 /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<yyyymmdd>

Entries must correspond with the OMC event log files being opened.

Check statistics processing

To check that statistics from the OMC are being processed by the NHA, use the following
command:

grep 30017 /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<yyyymmdd>

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

Check for "too many" problem messages

To check the audit logs for messages that indicate that too many problems are being raised,
use the following command:

grep 40019 /usr/gsm/OMCs/<omcname>/ea_logs/eaAudit<yyyymmdd>

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.

2. Problems where there are more than 10% of MAX-NO-OF-PROBLEMS-THRESHOLD of


the same problem type, least recent one first so that each problem type has a maximum of
10% of MAX-NO-OF-PROBLEMS-THRESHOLD.

3. Least recently reported problem.

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

For example, if the MAX-NO-OF-PROBLEMS-THRESHOLD is set to 800 and 870 problems


are reported (50 of which are cleared, 185 are Very Low Call Setup Success Rate problems
and 92 are High Daily Dropped Call Rate problems), the NHA first removes the 50 cleared
problems to bring the total to 820. Then the NHA removes 105 Very Low Call Setup Success
Rate problems and 12 High Daily Dropped Call Rate problems to get to 703 problems. Warnings
in the NHA log file then advise users that the thresholds for the Very Low Call Setup Success
Rate and High Daily Dropped Call Rate detectors must be adjusted.

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

Check NHA system performance statistics

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

Get the best performance from the UI

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:

/usr/sbin/ping -s [hostname of the NHA 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 the speed of the UI computer using the following command:


/usr/sbin/psrinfo -v
The faster the computer from which the UI was launched, the faster the performance
of the UI. The ideal is 170 MHz or greater.

• 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.

• Check how much memory is available using the following command:


/bin/vmstat 5 (gives free memory size in kilobytes).

• 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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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.

Check sharing from the OMC

To check the directory sharing from the OMC, carry out the following steps:

Procedure 4-5 Checking directory sharing

1 On the NHA, enter the command:

/usr/sbin/showmount -e <OMC hostname> | grep <nha hostname>

A list of the directories shared out on the OMC


and the hosts they are shared out to is displayed.
For example, on a primary OMC, output like the following is displayed:
/usr/omc/1.9.0.0.19/config <nha hostname>
/usr/omc/ne_data <nha hostname>
/home <nha hostname>

On a secondary OMC, output like the following is displayed:

/usr/omc/1.9.0.0.19/config <nha hostname>


/usr/omc/ne_data <nha hostname>
2 If the necessary directories are not listed as being shared, check the
file /etc/dfs/dfstab on the OMC. Ensure that there are entries for the
correct directories and that the NHA is included in the list of hosts.
If there is no entry for a directory, add an entry as follows:

share -F nfs -o rw=<nha_hostname>,root=<nha_hostname>


<directory>
3 If all the appropriate directories are listed and the NHA processor is
included, try unsharing and sharing the directories as follows:

Continued

4-28 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Check sharing from the OMC

Procedure 4-5 Checking directory sharing (Continued)


On the OMC, as user root enter the following commands:

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

indicating that the top-level /usr/omc


directory is already shared, then enter:

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

Check the /etc/auto_direct file to confirm


that it contains the following directories:
/usr/omc/<current>/config
/usr/omc/ne_data
where <current> is OMC release, for example, 1.9.0.0.19.
5 If, after an OMC software upgrade, the relevant directories
from the OMCs are not mounted to the NHA, use the
nha_omcmounts.sh utility to rectify the problem as follows:

cd /usr/gsm/current/sbin
./nha_omcmounts.sh <omc_hostname>
Messages like the following are then displayed:

Network connection to OMC ea3002 OK.


Unpassworded connection to OMC ea3002 OK.
All NFS shares on OMC ea3002 unshared.
All NFS shares on OMC ea3002 shared.

Investigate errors, if any, in the logfile located at /usr/gsm/ea_logs/


nha_omcmounts.log.<ddmmyyy>-<hhmmss>.

where <ddmmyyy>-<hhmmss>is the timestamp for the script.

68P02900W36-P 4-29
1900.2AS May 2008
Generating a new ssh key in NHA Chapter 4: Administration

Generating a new ssh key in NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to ssh in NHA

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.

Generating a new ssh key in NHA

Ssh key is generated when NHA is jumpstarted or upgraded to 1900.2AS.

Procedure 4-6 Generating a new ssh key

1 Log on to the NHA as root.


2 Go to directory /usr/gsm/cdrom_install.
cd /usr/gsm/cdrom_install
3 Generate new ssh key with the following command:
./nha_ssh_install.sh new
4 Enter y when the following prompt is displayed:
/usr/gsm/config/.ssh_root already exists.Existing RSA
keys will be overwritten. Proceed (y/N)? y
5 New ssh key has been generated successfully
if the following message is displayed:
RSA keys generated successfully
Otherwise, contact your system administrator for help.
6 Update the ssh key in the GSR9 OMC server’s authorized_keys
file for user root with the following command:
./nha_ssh_install.sh add <gsr9_omc_hostname>
Where <gsr9_omc_hostname>indicates the hostname of the GSR9 OMC
server.
7 Enter yes when the following prompt is displayed:

The authenticity of host 'omcserver1 (10.228.333.224)'


can't be established. RSA key fingerprint is
c1:76:d4:c0:07:2a:1f:89:c6:c9:c5:65:73:c6:72:f8.
Are you sure you want to continue
connecting (yes/no)? yes

Continued

4-30 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Generating a new ssh key in NHA

Procedure 4-6 Generating a new ssh key (Continued)


8 Enter the root password for the OMC server if the password prompt is
displayed.
9 The ssh key update is successful if the following messages are displayed:

SSH key successfully added to root@omcserver1.


Setup ssh connection successfully to root@omcserver1.

Otherwise, contact your system administrator for help.


10 Switch to user omcadmin with the following command:
su – omcadmin
11 Update the ssh key in the GSR9 OMC server’s authorized_keys
file for user omcadmin with the following command:

/usr/gsm/cdrom_install/nha_ssh_install.sh add <gsr9_omc_hostname>


Where <gsr9_omc_hostname> indicates the hostname of the GSR9 OMC
server.
12 Enter yes when the following prompt is displayed:

The authenticity of host 'omcserver1 (10.228.333.224)'


can't be established. RSA key fingerprint is
c1:76:d4:c0:07:2a:1f:89:c6:c9:c5:65:73:c6:72:f8.
Are you sure you want to continue connecting (yes/no)? yes
13 Enter the omcadmin password for the OMC server if the password prompt
is displayed.
14 The ssh key update is successful if the following messages are displayed:

SSH key successfully added to omcadmin@omcserver1.


Setup ssh connection successfully to omcadmin@omcserver1.

Otherwise, contact your system administrator for help.

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

Check OMC Informix settings


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to checking OMC Informix settings

Users can check Informix settings on the OMC after an upgrade by running the verify_informix
script located in /usr/gsm/current/sbin.

Running the verify_informix script

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 modications made affect all OMCs congured 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 les


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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

• Configurable files exported on shutdown

Importing problems into spreadsheets

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:

% sed 's/,/<TAB>/g' filename.csv > filename.txt

68P02900W36-P 4-33
1900.2AS May 2008
Audit les - eaAudit<date> Chapter 4: Administration

Audit les - eaAudit<date>

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.

Daily Export les - DailyExport<date>.csv

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,

Problem logs - eaProblems<date>

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:

cut -c1-1000 eaProblems20001127 > eaprobscut.csv

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:

Problem id,Status,EA Alarm,Devicetype,OMC,BSS,Site,Cell,Group,


Date,Time,Number of causes,Problem Name,Severity,Ranking,
Detection type,Intervals,Value,Line of Reasoning,Cause id 1,
Cause type 1,Confidence factor 1,Corrective action 1,Cause id 2,
Cause type 2,Confidence factor 2,Corrective action 2, ...

Anomaly logs - eaAnomaly<date>

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>

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:

Date,Time,Problem Id,Last Status,Operator,Problem,Last Value,


BSS,Site,Cell,First Date,First Time,Last Date,Last Time,Repeats,
Cause1,Cause2, ...

Clean up of log les

Automatic system administration housekeeping scripts clean up the NHA log files as follows:
• Log files older than three days are compressed.

• Log files older than fourteen days are deleted.

To keep a log file, copy the file to an alternate location before 14 days have elapsed.

Congurable les exported on shutdown

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.

The files are written to the /usr/gsm/OMCs/<omcname>/ea_logs/ directory. A summary of


the content of these files is displayed in Table 4-5.

Table 4-5 Content of exported congurable les

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
Congurable 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

Daily exports of key statistics


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of the Daily Exports of Key Statistics feature

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.

The export files are stored in the directory /usr/gsm/OMCs/<omc-


name>/ne_data/nha_cell_analysis/log

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)

• CatDailySummary_<ruleset>_C_C.<ddmmyyyy>.rep (for Cell level summaries)

These files are in tab-separated format. An example of the file output is as follows:

BSSName SiteName CellName Rule1 Rule2 Rule3 ... Rule N

68P02900W36-P 4-37
1900.2AS May 2008
Overview of the Daily Exports of Key Statistics feature Chapter 4: Administration

Table 4-6 List of rules calculated by daily exports feature

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

Table 4-6 List of rules calculated by daily exports feature (Continued)


Description
Rule
(I = Integer P = Percentage D = Decimal C = Carrier)
HC Health Check
HC1 (P SDCCH Blocking)
HC2 (P SDCCH Access Success Rate)
HC3 (P Call Setup Success Rate)
HC4 (P TCH Blocking Rate)
HC5 (I Call Volume)
HC6 (D Traffic Carried)
HC7 (P Drop Call Rate)
HC8 (P Call Success Rate)
HC9 (D Mean Time Between Drop Calls)
HCA (P Call Setup TCH Blocking Rate)
HO Handover
HO1 (I HO Incoming Volume)
HO2 (I HO Outgoing Volume)
HO3 (D HO Per Call)
HO4 (D HO Mean Time Between Handovers)
HO5 (P HO Internal Success)
HO6 (P HO Internal Recovered)
HO7 (P HO Internal Lost)
HO8 (P HO External Success)
HO9 (P HO External Recovered)
HOA (P HO External Lost)
HOB (P HO Intra-cell Success)
HOC (P HO Intra-cell Recovered)
HOD (P HO Intra-cell Lost)
HOE (P Inter-cell Success)
HOF (P Inter-cell Recovered)
HOG (P Inter-cell Lost)
HOH (D Intracell Volume)
HOI (P Percentage Intra-cell)
HOJ (P Percentage Intra-BSS)
HOK (P Percentage Inter-BSS)
HOL (P Incoming Handover Success Rate)
HR Handover Reasons
HR1 (P Uplink Quality)
HR2 (P Uplink Level)
HR3 (P Downlink Quality)
HR4 (P Downlink Level)
HR5 (P Distance)
HR6 (P Uplink Interference)
HR7 (P Downlink Interference)
HR8 (P Power Budget)
HR9 (P Congestion)
HRA (P Adjacent Channel Interference)
HRB (P Band Reassignment)
HRC (P Band Handover)

Continued

68P02900W36-P 4-39
1900.2AS May 2008
Overview of the Daily Exports of Key Statistics feature Chapter 4: Administration

Table 4-6 List of rules calculated by daily exports feature (Continued)


Description
Rule
(I = Integer P = Percentage D = Decimal C = Carrier)
IN Carrier Level Intf (Interference) on Idle
IN0 (C Interf. On idle (TS 0))
IN1 (C Interf. On idle (TS 1))
IN2 (C Interf. On idle (TS 2))
IN3 (C Interf. On idle (TS 3))
IN4 (C Interf. On idle (TS 4))
IN5 (C Interf. On idle (TS 5))
IN6 (C Interf. On idle (TS 6))
IN7 (C Interf. On idle (TS 7))
IN8 (C Interf. On idle for the Carrier)
PB Carrier Level Path Balance
PB0 (C Path Balance Mean (weak uplink))
PB1 (C Path Balance Mean (weak downlink))
PG Paging
PG1 (I MSC Paging)
PG2 (I Air-Interface Paging)
PG3 (I Paging Response)
PG4 (P Paging Success Rate)
PG5 (P Paging Compression Rate)
PG6 (P Paging Overflow Rate)
PM Performance Model
PM1 (I Low originations but traffic)
PM2 (I Low cell activity)
PM3 (I page_req_from_msc is zero)
PM4 (I Low traffic but channel requests)
PM5 (P High failure rate in reaching SDCCH)
PM6 (I Low RACH activity)
PM7 (P High imm assign rejects)
PM8 (P Levels of successful RACHs)
PM9 (P MSC Assignment Attempt)
RP Radio Performance
RP1 (P SDCCH Access Failure Rate)
RP2 (P SDCCH RF Loss Rate)
RP3 (P RF Assignment Failure Rate (Recovered MS))
RP4 (P RF Assignment Failure Rate (Lost MS))
RP5 (P TCH RF Loss Rate)
RP6 (P Handover Failure Rate (Recovered MS))
RP7 (P Handover Failure Rate (Lost MS))
SD SDCCH Congestion
SD1 (P SDCCH Blocking Rate)
SD2 (I SDCCH Accesses)
SD3 (D SDCCH Traffic Carried)
SD4 (D Low SDCCH Mean Holding Time)
SD5 (D No SDCCHs Available)
SD6 (D High SDCCH Mean Holding Time)
SI Site Based
SI1 (C Mean CPU Usage)

Continued

4-40 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Overview of the Daily Exports of Key Statistics feature

Table 4-6 List of rules calculated by daily exports feature (Continued)


Description
Rule
(I = Integer P = Percentage D = Decimal C = Carrier)
SU SDCCH Usage
SU1 (P SDCCH Activations due to CM_SERV_REQ_CALL)
SU2 (P SDCCH Activations due to CM_SERV_REQ_EMERG)
SU3 (P SDCCH Activations due to CM_SERV_REQ_SUPP)
SU4 (P SDCCH Activations due to CM_SERV_REQ_SMS)
SU5 (P SDCCH Activations due to CM_REESTABLISH)
SU6 (P SDCCH Activations due to Mobile Terminated Calls)
SU7 (P SDCCH Activations due to IMSI_DETACH)
SU8 (P SDCCH Activations due to LOCATION_UPDATE)
SU9 (P SDCCH Activations due to CHAN_REQ_MS_FAIL)
SUA (P SDCCH Activations due to Mobile Terminated SMS)
TC TCH Congestion
TC1 (P TCH Blocking Rate)
TC2 (I TCH Accesses)
TC3 (D TCH Mean Holding Time)
TC4 (D TCH Traffic Carried)
TC5 (I Maximum TCHs Busy)
TC6 (D No TCHs Available)
TC7 (P Spill Over Factor (Directed Retry Only))
TC8 (P Spill Over Factor (Attempts at Congestion Relief Only))
TC9 (P Spill Over Factor (Multiband only))
TCA (P TCH Blocking Rate for Inner Zone)
TCB (P TCH Blocking Rate for Outer Zone)
TCC (I TCH not utilized)
GPAS GPRS Accessibility
GPAS1 (P GPRS Uplink TBF Rejection Rate)
GPAS2 (P EGPRS Uplink TBF Rejection Rate)
GPBS GPRS Bandwidth
GPBS1 (D PRP Load)GPBS2 (D Mean TBF Load)
GPTT GPRS Throughput
GPTT1 (D Downlink Mean User Throughput per Timeslot)
GPTT2 (D Uplink Mean User Throughput per Timeslot)
GPTV GPRS Traffic Volume
GPTV1 (D GPRS Downlink User Traffic Volume)
GPTV2 (D EGPRS Downlink User Traffic Volume)
GPTV3 (D GPRS Uplink User Traffic Volume)
GPTV4 (D EGPRS Uplink User Traffic Volume)
GPTV5 (P GPRS Downlink Bias)
GPTV6 (P EGPRS Downlink Bias)
GPTV7 (D Mean Number of Downlink Active PDTCHs)
GPTV8 (D Mean Number of Uplink Active PDTCHs)
GPUS GPRS utilization
GPUS1 (P Downlink PDTCH utilization by Allocation)
GPUS2 (P Uplink PDTCH utilization by Allocation)
GPUS3 (D Downlink TBF Interleaving Activity)
GPUS4 (D Uplink TBF Interleaving Activity)
GPUS5 (P Downlink TBF Drop Rate)
GPUS6 (P Uplink TBF Drop Rate)
GPUS7 (D Cell Congestion Time)

68P02900W36-P 4-41
1900.2AS May 2008
Conguring the Daily Exports of Key Statistics feature Chapter 4: Administration

Conguring the Daily Exports of Key Statistics feature

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.

Conguring additional key statistics for daily export

By default only the following key statistics are exported daily


• Call Setup Success Rate

• Call Volume

• Drop Call Rate

• Mean Time Between Drop Calls

• 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:

Usage: lgConfig [ -arl ]


Options:
-a Adds keystats for long term monitoring by NHA.
-r Removes keystats that have been configured for long term monitoring by NHA.
-l Prints a list of all keystats already configured for long term
monitoring by NHA.

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:

Table 4-7 Directories in nha_cell_analysis directory

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.

Running daily exports of key statistics

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/.

This product includes software developed by the Apache Software Foundation


(http://www.apache.org/).

The NHA as a web server

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 file /usr/gsm/config/local/index.htmlcan be edited appropriately to link to other files,


such as http://snhasys1/interesting.html.

NHA web page

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 conguration les (ea.cfg)

NHA conguration les (ea.cfg)


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to ea.cfg les

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 local ea.cfg file, which is at /usr/gsm/OMCs/<omcname>/config/ea.cfg and applies


to all individual OMCs.

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/.

Global ea.cfg le

The global configuration file is at /usr/gsm/config/local/ea.cfg. The following variables are


read from this file and apply to all OMCs:

# A security level 2 will prevent users other than omcadmin from


creating/deleting/modifying Subscriptions, changing the time for daily
export of problems, etc.
# A security level 1 = level 2 except that trusted users will also have
same power as omcadmin creating/deleting/modifying Subscriptions
SECURITY-LEVEL 1
# Defines a list of trusted users apart from omcadmin.
# Only valid for SECURITY-LEVEL 1. Otherwise ignored.
# Usernames must be separated by spaces.
SECURITY-TRUSTED-USERS bloggsj murphyk
# Defines whether historical OOS is on or off.
# "OFF" means that any user can access historical oos.
# "ON" means that only OMCADMIN can access historical oos.
SECURITY-RESTRICT-HISTORICAL-OOS OFF

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 specic ea.cfg le Chapter 4: Administration

Import, export, and log le eld separators

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:

# Separator for exports. The following separators can be


# used - COMMA, SEMICOLON, DOT and PIPE. Default is COMMA.
# WARNING: DOT separator will conflict with a decimal point.
EXPORT-SEPARATOR PIPE
# Separator for imports. The following separators can be
# used - COMMA, SEMICOLON, DOT and PIPE. Default is COMMA.
IMPORT-SEPARATOR PIPE

OMC specic ea.cfg le

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.

Modifying auto-clearing hours

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 specic ea.cfg le

Conguring 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).

#********** Configuring IMSI-DETACH **********


#
# Does the MSC generate Connection Refused for every IMSI detach?
# If the answer is 'yes' then the value of IMSI-DETACH should be set
# to TRUE. Otherwise ('no') it should be set to FALSE.
#
IMSI-DETACH TRUE

Using the NHA to monitor GPRS statistics

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 specic ea.cfg le Chapter 4: Administration

Conguring statistics collection cycle offset

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.

#********* Stats collection cycle offset *********


# Valid range is 0 - 8
# E.g. Setting this to 8 means IPM_STORING_STATS shall start at XX:28 and XX:58 for
# 30 minutes statistics interval and XX:28 for 60 minutes statistics interval
# Cell grouping, daily export, import/export thresholds, blacklist or other
# operations that start at XX:00 and XX:30 may be affected
STATS-COLLECTION-CYCLE-OFFSET 0

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

User added statistics


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of 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.

The NHA administrator configures this feature as follows:

Procedure 4-7 Conguring the NHA to read additional statistics

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

Procedure 4-7 Conguring the NHA to read additional statistics (Continued)


4 Perform an NHA stop/start for the changes to take effect in the NHA.
For example, if the administrator added three additional statistics named
my_stat_01, my_stat_02, and my_stat_03 to the PM database, the entry
in the ea.cfg file would look like the following:
USER-ADDED-STATS-ENABLED TRUE
#
USER_STAT_01 my_stat_01
USER_STAT_02 my_stat_02
USER_STAT_03 my_stat_03
The NHA would then store values for the three statistics for each cell. These
statistics could then be used to create new formulae or detectors with the
NHA Knowledge Editor.

4-50 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Viewing problems as alarms on the OMC

Viewing problems as alarms on the OMC


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

NHA problems 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.

Setting up NHA to send problems to the OMC as alarms

To set up the NHA to send problems as alarms to an OMC, use the following steps:

Procedure 4-8 Setting up NHA to send problems as alarms to an OMC

1 Edit the NHA OMC-specific configuration file


(usr/gsm/OMCs/<omcname>/config/ea.cfg) as follows:

• Set the REPORT-NHA-PROBLEMS-TO-THE-OMC variable to ON.

• Set the REPORT-NEW-NHA-PROBLEMS-TO-THE-OMC variable to ON.

• Set the REPORT-REPEAT-NHA-PROBLEMS-TO-THE-OMC variable to either


ON or OFF, depending on whether each repeat of each problem is to
be sent to the OMC or not. The recommended setting is OFF.

• Set the REPORT-RESYNC-NHA-PROBLEMS-TO-THE-OMC variable to


either ON or OFF, depending on whether all NHA alarms are to be
automatically resynced and resent to the OMC at 04.15 am every day
or not. The recommended setting is OFF.

Continued

68P02900W36-P 4-51
1900.2AS May 2008
Setting up NHA to send problems to the OMC as alarms Chapter 4: Administration

Procedure 4-8 Setting up NHA to send problems as alarms to an OMC (Continued)


The ea.cfg file now looks like the following:
#
# Turns on reporting of NHA problems to an OMC
# ON = turned on
# Otherwise = turned off
REPORT-NHA-PROBLEMS-TO-THE-OMC ON
#
# Turns on reporting of repeat NHA problems to an OMC
# Ignored if REPORT-NHA-PROBLEMS-TO-THE-OMC is off
# ON = turned on
# Otherwise = turned off
REPORT-REPEAT-NHA-PROBLEMS-TO-THE-OMC OFF
#
# REPORT-NEW-NHA-PROBLEMS-TO-THE-OMC
# Reports NHA problems to OMC in expanded format.
# Important: This format will only
be sent to OMC version 1620 or later.
# Example of new format alarm:
#
# 19 - SEEN - *NONE*.
# NHAEvent - DRI - Integration_1(Site:Int:1): 1 DRI 1 1 -
21/01/2005 14:00:27.
# [40015] EA-NHA: Problem 15 - FMIC - Major -/-.
# Repeated DRI-61-62-63 alarms
# 21/01/2005 13:57 - default
# 0121-00005.
#
# ON = new format alarms
# Otherwise = old format alarms
REPORT-NEW-NHA-PROBLEMS-TO-THE-OMC ON
#
# Turns on resynchronizing of NHA problems to an OMC
# When on, all nha problems will be sent to the OMC
# at 0415 hours every day.
# Ignored if REPORT-NHA-PROBLEMS-TO-THE-OMC is off
# ON = turned on
# Otherwise = turned off
REPORT-RESYNC-NHA-PROBLEMS-TO-THE-OMC OFF
2 Restart the NHA if changes were made to any of the three
variables: REPORT-NEW-NHA-PROBLEMS-TO-THE-OMC,
REPORT-REPEAT-NHA-PROBLEMS-TO-THE-OMC
or REPORT-RESYNC-NHA-PROBLEMS-TO-THE-OMC.

Restart the NHA by selecting the <omcname> shutdown


option from the Shutdown menu on the NHA UI.

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

Procedure 4-8 Setting up NHA to send problems as alarms to an OMC (Continued)


3 Select the Report to OMC option from the Configure menu on
the NHA UI (refer to Reporting NHA problems to the OMC as
alarms on page 2-161. Tick the check box for the appropriate OMC.

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 Subscriptions window, select the


PROBLEMS-TO-REPORT-TO-THE-OMC-<OMCNAME> subscription
and click the Modify button to open the Modify Subscription window.

• On the Modify Subscription window, select the Problem types that are
to be forwarded to the OMC as alarms.

• Click OK and return to the NHA UI.


5 On the NHA UI, select Regions from the Configure menu to open the
Regions window.

• On the Regions window, select the


PROBLEMS-TO-REPORT-TO-THE-OMC-<OMCNAME>region and click
the modify button to open the Modify Region window.

• On the Modify Region window, select the BSSs for which problems
should be forwarded to the OMC as alarms.

• Click OK and return to the NHA UI.


6 Check that the appropriate problems are sent to the OMC by selecting the
PROBLEMS-TO-REPORT-TO-THE-OMC-<OMCNAME> subscription
and the PROBLEMS-TO-REPORT-TO-THE-OMC-<OMCNAME>
region for viewing on the Problem window.

The problems displayed are the problems


sent to the OMC "OMCNAME" 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

Sample of OMC alarm format

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

NHA Monitoring Schedule


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Description of the NHA Monitoring Schedule feature

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.

Conguring the Monitoring Schedule feature

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

Table 4-8 Monitoring schedule section in ea.cfg le

Name Description

MONITOR_SCHEDULE OFF Enables or disables the feature for all detectors.


The default is OFF.
MONITOR_START 0 The time after which the NHA should not report
problems, where 0 = 12.00 A.M., 19 = 7.00 P.M.,
and so on. The default is 0.
MONITOR_END 7 The time before which the NHA should not report
any problems.
MOTOROLA-MONITOR- The directory and file that stores the Motorola
PROBLEM-TYPE-PATH recommended default list of problems using the
/usr/gsm/current/knowledge/monitor/ monitoring schedule.
motorola-monitor-problem.txt
CUSTOMER-MONITOR- The directory and file that stores the customer list
PROBLEM-TYPE-PATH of problems using the monitoring schedule.
/usr/gsm/config/customer/monitor
/customer-monitor-problem.txt

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
Conguring 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

• Very Low TCH Usage

• No GPRS Activity in Cell

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

Using the cell grouping script


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to cell grouping

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.

Running the cell grouping script

Cells can be grouped, based on the activity in the cells, using the following steps:

Procedure 4-9 Running the cell grouping script

1 Log on to the NHA as omcadmin.


2 Change directory as follows (if not already in this directory):
cd /usr/gsm/current/ea_tools
3 Execute the following command:
ea_group.sh <omcname>
Where <omcname> is the hostname of the OMC.
4 Follow the prompts and enter the appropriate
details, for example (operator entries in bold):

Enter maximum busy_tch_mean for QUIET cells for 1 interval:1


Enter maximum busy_tch_mean for NORMAL cells for 1 interval:4
Enter start date/time (format
YYYY-MM-DD HH:MM): 2005-04-18 10:00
Enter end date/time (format YYYY-MM-DD HH:MM): 2005-04-24 10:00

Continued

68P02900W36-P 4-57
1900.2AS May 2008
Importing the grouped cells Chapter 4: Administration

Procedure 4-9 Running the cell grouping script (Continued)


Processing complete - output written to:
/usr/gsm/OMCs/OMCONE/ea_logs/ea_group.csv
Number of Busy Cells = 92
Number of Normal Cells = 422
Number of Quiet Cells = 180
Number of Blacklisted Cells = 0
Number of Cells with no statistics available = 6
5 A .CSV file is created in
/usr/gsm/OMCs/<omcname>/ea_logs/ea_group.csv as follows:
OMC1,BSS-1,Site2,Cell-A,BUSY
OMC1,BSS-1,Site2,Cell-B,BUSY
OMC1,BSS-1,Site3,Cell-C,BUSY
OMC1,BSS-1,Site3,Cell-D,QUIET

Importing the grouped cells

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

NHA threshold les


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to 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 too many problems are being raised, tighten 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.

Using sample threshold les

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.

The detector levels are stored in /usr/gsm/current/ea_tools/mot_thresholds. The NHA


administrator can copy and edit these files to replace "OMC" on every line with the appropriate
<omcname>. The files can then be imported using the Thresholds - Import Thresholds
option in the Configure menu.

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

Refer to Table 4-9 for detector levels and file names.

Table 4-9 NHA default thresholds

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

Guidelines for setting thresholds

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.

Over time, configure the NHA to move up the levels.

The Daily Summary Report of Problems detected which is produced in


/usr/gsm/ea_logs/NHASumm[date] is a useful report. It can give an indication of how many
problems of each type are being found on a daily basis. The information in this report is
useful for anyone setting thresholds. Refer to Summary report of problems detected on
page 2-63 for more details.

4-60 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Setting up the NHA for printing

Setting up the NHA for printing


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Conguring 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.

To run the automated script, log on to the NHA processor as root.

Execute the following command:

/usr/gsm/current/sbin/Configure_EA_Printer <print server>


Where <print server> is the hostname for the GUI server with a default printer configured.

Conguring printers not connected to the GUI server

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:

Procedure 4-10 Conguring printers not connected to the GUI server

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 conguration Chapter 4: Administration

Checking OMC conguration


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to OMC conguration

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.

This section provides information on the following topics:


• Resyncing the OMC.

• Enabling a resync (autoresync and periodic).

• Enabling appropriate statistics (running the S85check_stats script ).

Resyncing the OMC

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

The environment variable ENABLERESYNC can be set to Y or N to turn resyncing on or off.


By default this variable is set to N.

TIMER

The environment variable TIMER sets the amount of time Resync Controller waits for a resync
to complete. It specifies the time in seconds.

It can be set from 150 through 3600. By default it is set to 600.

4-62 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Enabling a resync

AUTORESYNC

The environment variable AUTORESYNC can be set to Y or N to enable or disable autoresyncs.

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

Resync and autoresync

Ensure that resync and automatic resync are enabled on the OMC-R as follows:

Procedure 4-11 Enabling resync and autoresync

1 View the file /usr/gsm/config/global/RC.CNFG.


2 Set the entry for the ENABLERESYNC variable to Y.
3 Set the entry for the AUTORESYNC variable to Y.
4 Set the TIMER variable to 600.
5 For example:ENABLERESYNC Y
TIMER 600
AUTORESYNC Y

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:

Procedure 4-12 Enabling a periodic resync

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:

• Select Periodic in the Execute Mode field.

• Enter Start time and End time in the appropriate fields.


Ideally, set the Start Time for a time when there is low activity on the
network.

• Set the Interval field to 24 hours.


7 Select File-Create to create the new Scheduled resync.
8 Select File-Close to close the rsSchedule Detailed View window and check
that the schedule is in the Resync scheduler window.
9 Select File-Close to close the Resync Scheduler window.

Resync (state only)

To update the state information in the OMC Configuration Database without having to schedule
a resync of alarms, use the following steps:

Procedure 4-13 Enabling a resync (state only)

1 On the OMC-R, change directory to /usr/gsm/config/global.


2 In the mibProcConfig.csh file, set the environment variable:

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

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.

Procedure 4-14 Enabling appropriate statistics

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.

Run this script periodically in case the required statistics have


become disabled on new or existing cells.

Required cell statistics

Table 4-10 displays a list of the required cell statistics as follows:

Table 4-10 Required cell statistics

Name in database Also known as


access_per_agch ACCESS_PER_AGCH
access_per_pch ACCESS_PER_PCH
air_dl_cntrl_blks AIR_DL_CONTROL_BLKS
air_dl_tbf_fl_tot AIR_DL_TBF_FAILURES
air_ul_cntrl_blks AIR_UL_CONTROL_BLKS

Continued

68P02900W36-P 4-65
1900.2AS May 2008
Required cell statistics Chapter 4: Administration

Table 4-10 Required cell statistics (Continued)


Name in database Also known as
air_ul_tbf_fl_tot AIR_UL_TBF_FAILURES
alloc_sdcch ALLOC_SDCCH
alloc_sdcch_fail ALLOC_SDCCH_FAIL
alloc_tch ALLOC_TCH
alloc_tch_fail ALLOC_TCH_FAIL
avail_pdtch_max AVAIL_PDTCH_MAX
avail_pdtch_mean AVAIL_PDTCH_MEAN
avail_tch_max AVAILABLE_TCH_MAX
avail_tch_mean AVAILABLE_TCH_MEAN**
bad_ho_refnum_ms BAD_HO_REFNUM_MS
busy_sdcch_mean BUSY_SDCCH_MEAN**
busy_tch_max BUSY_TCH_MAX**
busy_tch_mean BUSY_TCH_MEAN**
calls_queued CALLS_QUEUED
chan_req_ms_blk CHAN_REQ_MS_BLK**
chan_req_ms_fail_rol CHAN_REQ_MS_FAIL_ROLL**
ch_req_pcu_tot CH_REQ_UNSVCD_PCU
chan_reqs_rec_b_c CHANNEL_REQS_REC
ch_reqs_succ CHANNEL_REQS_SUCCESS
cipher_mode_fail CIPHER_MODE_FAIL
cm_lcs_request LOCATION_SERVICES
cm_reestablish CM_REESTABLISH
cm_serv_req_call CM_SERV_REQ_CALL
cm_serv_req_emerg CM_SERV_REQ_EMERG
cm_serv_req_sms CM_SERV_REQ_SMS
cm_serv_req_supp CM_SERV_REQ_SUPP
cong_stand_ho_atm CONGEST_STAND_HO_ATTEMPT
conn_refused CONN_REFUSED
conn_req_to_msc CONN_REQ_TO_MSC
dl_busy_pdtch_mean DL_BUSY_PDTCH_MEAN
dl_radio_blks_1_ts DL_RADIO_BLKS_1_TS
dl_radio_blks_2_ts DL_RADIO_BLKS_2_TS
dl_radio_blks_3_ts DL_RADIO_BLKS_3_TS
dl_radio_blks_4_ts DL_RADIO_BLKS_4_TS

Continued

4-66 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Required cell statistics

Table 4-10 Required cell statistics (Continued)


Name in database Also known as
dl_rlc_ack_new_blks 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
dl_pdtch_seizure DL_PDTCH_SEIZURE
dl_rlc_ddtr_blks DL_RLC_DDTR_BLKS
dl_rlc_retx_blks DL_RLC_RETX_BLKS
dl_rlc_nak_new_bks DL_RLC_UNACK_NEW_BLKS
g_rach_bts_tot G_RACH_UNSVCD_BTS
gprs_acc_per_rach GPRS_ACCESS_PER_RACH
gprs_av_pdtch_mn GPRS_AVAIL_PDTCH_MEAN
gprs_av_pdtch_max GPRS_AVAIL_PDTCH_MAX
gprs_cellcong_25 GPRS_CELL_CONGESTION
gprs_ch_switched GPRS_CHANNELS_SWITCHED
gprs32k_ch_switch GPRS_32K_CHANNELS_SWITCHED
ho_fail_no_resourc HO_FAIL_NO_RSOURCES
ho_req_ak_msc_tot HO_REQ_ACK_TO_MSC
ho_req_msc_ok HO_REQ_MSC_OK
i_inter_bs_eq_fa IN_INTER_BSS_EQUIP_FAIL
i_inter_bs_ho_clr IN_INTER_BSS_HO_CLEARED
i_inter_bs_ho_suc IN_INTER_BSS_HO**
i_inter_bs_ms_ns IN_INTER_BSS_MS_NO_SEIZE
i_intra_bs_eq_fa IN_INTRA_BSS_EQUIP_FAIL
i_intra_bs_ho_clr IN_INTRA_BSS_HO_CLEARED
i_intra_bs_ho_los IN_INTRA_BSS_HO_LOSTMS
i_intra_bs_ho_ret IN_INTRA_BSS_HO_RETURN
i_intra_bs_ho_suc IN_INTRA_BSS_HO**
ia_dcs1800_atm DCS1800_HO_ATMPT
ia_dcs1800_fail DCS1800_HO_FAIL
ia_egsm_ho_atm EGSM_HO_ATMPT
ia_egsm_ho_fail EGSM_HO_FAIL
ia_pgsm_ho_atm PGSM_HO_ATMPT

Continued

68P02900W36-P 4-67
1900.2AS May 2008
Required cell statistics Chapter 4: Administration

Table 4-10 Required cell statistics (Continued)


Name in database Also known as
ia_pgsm_ho_fail PGSM_HO_FAIL
imsi_detach IMSI_DETACH
intra_cell_ho_atm INTRA_CELL_HO_ATMPT
intra_cell_ho_f_f INTRA_CELL_HO_ATMPT_FR_FR
intra_cell_ho_f_h INTRA_CELL_HO_ATMPT_FR_HR
intra_cell_ho_h_f INTRA_CELL_HO_ATMPT_HR_FR
intra_cell_ho_h_h INTRA_CELL_HO_ATMPT_HR_HR
intra_cell_ho_los INTRA_CELL_HO_LOSTMS
intra_cell_ho_ret INTRA_CELL_HO_RETURN
intra_cell_ho_suc INTRA_CELL_HO**
loc_flw_req_nrm LOC_FLW_ON_REQ_NORM
loc_flw_req_sms LOC_FLW_ON_REQ_SMS
location_update LOCATION_UPDATE
ma_cmd_to_ms MA_CMD_TO_MS**
ma_cmd_to_ms_blkd MA_CMD_TO_MS_BLKD**
ma_complet_to_msc MA_COMPLETE_TO_MSC**
ma_complete_frm_ms MA_COMPLETE_FROM_MS**
ma_fail_from_ms MA_FAIL_FROM_MS
ma_req_from_msc MA_REQ_FROM_MSC**
mt_lcs_on_sdcch MT_LCS_ON_SDCCH
num_ho_to_3g_atts NUM_HO_TO_3G_ATTEMPTS
num_ho_to_3g_succ NUM_HO_TO_3G_SUCCESS
num_ho2_3g_ressucc NUM_HO_TO_3G_RES_ALLOC_SUCC
o_inter_bs_eq_fa OUT_INTER_BSS_HO_EQUIP_FAIL
o_inter_bs_ho_fail OUT_INTER_BSS_HO_FAIL
o_inter_bs_ho_atm OUT_INTER_BSS_HO_ATMPT
o_inter_bs_ho_los OUT_INTER_BSS_HO_LOSTMS
o_inter_bs_ho_ret OUT_INTER_BSS_HO_RETURN
o_inter_bs_ho_suc OUT_INTER_BSS_HO_SUC**
o_inter_bs_rq_msc OUT_INTER_BSS_REQ_TO_MSC
o_intra_bs_ho_atm OUT_INTRA_BSS_HO_ATMPT
o_intra_bs_ho_los OUT_INTRA_BSS_HO_LOSTMS
o_intra_bs_ho_req OUT_INTRA_BSS_HO_REQ
o_intra_bs_ho_ret OUT_INTRA_BSS_HO_RETURN

Continued

4-68 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Required cell statistics

Table 4-10 Required cell statistics (Continued)


Name in database Also known as
o_intra_bs_ho_suc OUT_INTRA_BSS_HO_SUC**
ohoa_adj_chn_intf ADJACENT_CHANNEL_INTERFERENCE
ohoa_band_reasign BAND_REASSIGNMENT
ohoa_bandhandover BAND_HANDOVER
ohoa_congestion CONGESTION
ohoa_distance DISTANCE
ohoa_downinterf DOWNLINK_INTERFERENCE
ohoa_downlevel DOWNLINK_LEVEL
ohoa_downqual DOWNLINK_QUALITY
ohoa_powerbdgt POWER_BUDGET
ohoa_upinterf UPLINK_INTERFERENCE
ohoa_uplevel UPLINK_LEVEL
ohoa_upqual UPLINK_QUALITY
ok_acc_proc OK_ACC_PROC**
ok_acc_proc_suc_r OK_ACC_PROC_SUC_RACH**
out_ho_caus_atmpt OUT_HO_CAUSE_ATMPT**
page_req_from_msc PAGE_REQ_FROM_MSC**
page_response PAGE_RESPONSE
pch_page_q_discrd PCH_PAGE_Q_DISCARD**
rf_loss_tch_roll RF_LOSSES_TCH_ROLL
rf_losses_sd RF_LOSSES_SD**
sdcch_congestion SDCCH_CONGESTION**
sec_assign_atmpt SECOND_ASSIGN_ATMPT
sms_init_on_sdcch SMS_INIT_ON_SDCCH**
sms_init_on_tch SMS_INIT_ON_TCH
sms_init_sdcch_ho SMS_INIT_SDCCH_HO
tch_congestion TCH_CONGESTION**
tch_q_removed TCH_Q_REMOVED**
tch_usage TCH_USAGE
total_calls TOTAL_CALLS**
ul_busy_pdtch_mean UL_BUSY_PDTCH_MEAN
ul_pdtch_seizure UL_PDTCH_SEIZURE
ul_rf_bks_gmsk_1ts UL_RADIO_BLKS_GMSK_1_TS
ul_rf_bks_gmsk_2ts UL_RADIO_BLKS_GMSK_2_TS

Continued

68P02900W36-P 4-69
1900.2AS May 2008
Required carrier statistics Chapter 4: Administration

Table 4-10 Required cell statistics (Continued)


Name in database Also known as
ul_rlc_nack_blks UL_RLC_NACK_BLKS
ul_rlc_ack_new_bks UL_RLC_ACK_NEW_BLKS
ul_rlc_retx_blks UL_RLC_RETX_BLKS
ul_rlc_una_new_bks UL_RLC_UNACK_NEW_BLKS

(** indicates the most important statistics to enable from an NHA perspective)

Required carrier statistics

Table 4-11 displays a list of the required carrier statistics as follows:

Table 4-11 Required carrier statistics

Name in database Also known as


ber_bin0_ts0 BER**
busy_tch_mean BUSY_TCH_CARR_MEAN
chan_req_ms_fail0 CHAN_REQ_MS_FAIL**
chanreq_fail_sdch0 CHAN_REQ_MS_FAIL_SDCCH
fer_amr_fr_bin0 FER_AMR_FR
fer_min0 FER
fer_non_amr_bin0 FER_GSM_FR_EFR
intf_on_idle_mean0 INTF_ON_IDLE_MEAN
path_balance_mean PATH_BALANCE_MEAN**
rf_losses_tch0 RF_LOSSES_TCH**

(** 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.

Table 4-12 displays a list of GPRS statistics as follows:


Table 4-12 GPRS statistics

Name in database Also known as


air_dl_blks_q1_cs1 AIR_DL_DATA_BLKS_QOS1_CS1
air_dl_blks_q2_cs1 AIR_DL_DATA_BLKS_QOS2_CS1
air_dl_blks_q3_cs1 AIR_DL_DATA_BLKS_QOS3_CS1
air_dl_blks_q4_cs1 AIR_DL_DATA_BLKS_QOS4_CS1
air_dl_cntrl_blks AIR_DL_CONTROL_BLKS
air_dl_data_blks AIR_DL_DATA_BLKS **
air_dl_tbf_fl_dr AIR_DL_TBF_FAILURES_DR
air_dl_tbf_fl_dt AIR_DL_TBF_FAILURES_DT
air_dl_tbf_fl_t AIR_DL_TBF_FAILURES_T
air_dl_tbf_fl_tot AIR_DL_TBF_FAILURES
air_ul_blks_q1_cs1 AIR_UL_DATA_BLKS_QOS1_CS1
air_ul_blks_q2_cs1 AIR_UL_DATA_BLKS_QOS2_CS1
air_ul_blks_q3_cs1 AIR_UL_DATA_BLKS_QOS3_CS1
air_ul_blks_q4_cs1 AIR_UL_DATA_BLKS_QOS4_CS1
air_ul_cntrl_blks AIR_UL_CONTROL_BLKS
air_ul_data_blks AIR_UL_DATA_BLKS **
air_ul_tbf_fl_et AIR_UL_TBF_FAILURES_ET
avail_pdtch_max AVAILABLE_PDTCH_MAX
avail_pdtch_mean AVAILABLE_PDTCH_MEAN
ch_req_pcu_p_ir CH_REQ_PCU_P_IR
ch_req_pcu_p_rtd CH_REQ_PCU_P_RTD
ch_req_pcu_pd_ir CH_REQ_PCU_PD_IR
ch_req_pcu_pr_ir CH_REQ_PCU_PR_IR
ch_req_pcu_pr_rtd CH_REQ_PCU_PR_RTD
ch_req_pcu_r_bw CH_REQ_PCU_R_BW
ch_req_pcu_r_ir CH_REQ_PCU_R_IR
ch_req_pcu_r_rtd CH_REQ_PCU_R_RTD
ch_req_pcu_tot CH_REQ_UNSVCD_PCU
ch_reqs_succ CHANNEL_REQS_SUCCESS
ch_reqs_succ_b_c CH_REQS_SUCC_B_C
ch_reqs_succ_b_p CH_REQS_SUCC_B_P

Continued

68P02900W36-P 4-71
1900.2AS May 2008
GPRS statistics Chapter 4: Administration

Table 4-12 GPRS statistics (Continued)


Name in database Also known as
chan_reqs_rec CHANNEL_REQS_REC **
chan_reqs_rec_b_c CHANNEL_REQS_REC_SINGLE_CCCH
chan_reqs_rec_b_p CHANNEL_REQS_REC_SINGLE_PCCCH
chan_reqs_rec_p_c CHAN_REQ_REC_PHASE_PCCCH
channel_reqs_rej CHANNEL_REQS_REJECT
chanreqsuccesbccc CHANNEL_REQS_SUCCESS_E_SB_CCC
chanreqsuccesbpccc CHANNEL_REQS_SUCCESS_E_SB_PCCC
chnlrqrecegprs1ppc CHANNEL_REQS_REC_EGPRS_1PH_PCC
chnlrqrecegprssbc CHANNEL_REQS_REC_EGPRS_SBK_CC
chnlrqrecegprssbpc CHANNEL_REQS_REC_EGPRS_SBK_PCC
dl_busy_pdtch_mean DL_BUSY_PDTCH_MEAN
dl_pdtch_con_tot DL_PDTCH_CONGESTION
dl_pdtch_seizure DL_PDTCH_SEIZURE
dl_radio_blks_1_ts DL_RADIO_BLKS_1_TS**
dl_radio_blks_2_ts DL_RADIO_BLKS_2_TS**
dl_radio_blks_3_ts DL_RADIO_BLKS_3_TS**
dl_radio_blks_4_ts DL_RADIO_BLKS_4_TS**
dl_rf_bks_1ts_cs1 DL_RADIO_BLKS_1_TS_CS_1
dl_rf_bks_2ts_cs1 DL_RADIO_BLKS_2_TS_CS_1
dl_rf_bks_3ts_cs1 DL_RADIO_BLKS_3_TS_CS_1
dl_rf_bks_4ts_cs1 DL_RADIO_BLKS_4_TS_CS_1

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

Table 4-12 GPRS statistics (Continued)


Name in database Also known as
g_rach_bts_tot G_RACH_UNSVCD_BTS
gprs_acc_per_rach GPRS_ACCESS_PER_RACH
gprs_av_pdtch_max GPRS_AVAIL_PDTCH_MAX
gprs_av_pdtch_mn GPRS_AVAIL_PDTCH_MEAN
gprs_cellcong_25 GPRS_CELL_CONGESTION_25
gprs_cellcong_30 GPRS_CELL_CONGESTION_30
gprs_cellcong_35 GPRS_CELL_CONGESTION_35
gprs_cellcong_40 GPRS_CELL_CONGESTION_40
gprs_cellcong_45 GPRS_CELL_CONGESTION_45
gprs_cellcong_50 GPRS_CELL_CONGESTION_50
gprs_cellcong_55 GPRS_CELL_CONGESTION_55
gprs_cellcong_60 GPRS_CELL_CONGESTION_60
gprs_cellcong_65 GPRS_CELL_CONGESTION_65
gprs_cellcong_70 GPRS_CELL_CONGESTION_70
gprs_cellcong_75 GPRS_CELL_CONGESTION_75
gprs_cellcong_80 GPRS_CELL_CONGESTION_80
gprs_cellcong_85 GPRS_CELL_CONGESTION_85
gprs_cellcong_90 GPRS_CELL_CONGESTION_90
gprs_cellcong_95 GPRS_CELL_CONGESTION_95
gprs_cellcong_100 GPRS_CELL_CONGESTION_100
gprs_ch_switched GPRS_CHANNELS_SWITCHED
gprs_dl_asgn_p GPRS_DL_ASGN_PCCCH
gprs32k_ch_switch GPRS_32K_CHANNELS_SWITCHED
ul_busy_pdtch_mean UL_BUSY_PDTCH_MEAN
ul_pdtch_con_tot UL_PDTCH_CONGESTION
ul_pdtch_seizure UL_PDTCH_SEIZURE
ul_rf_bks_8psk_1ts UL_RADIO_BLKS_8PSK_1_TS**
ul_rf_bks_8psk_2ts UL_RADIO_BLKS_8PSK_2_TS**
ul_rf_bks_gmsk_1ts UL_RADIO_BLKS_GMSK_1_TS**
ul_rf_bks_gmsk_2ts UL_RADIO_BLKS_GMSK_2_TS**
ulrfbk8psk1ts_cs1 UL_RADIO_BLKS_8PSK_1_TS_CS_1
ulrfbk8psk2ts_cs1 UL_RADIO_BLKS_8PSK_2_TS_CS_1
ulrfbkgmsk1ts_cs1 UL_RADIO_BLKS_GMSK_1_TS_CS_1
ulrfbkgmsk2ts_cs1 UL_RADIO_BLKS_GMSK_2_TS_CS_1

** indicates the most important statistics to enable from an NHA perspective.

68P02900W36-P 4-73
1900.2AS May 2008
User added statistics Chapter 4: Administration

indicates the statistics that are available when GPRS-IS-ENABLED

User added statistics

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 Conguring the recent alarms and events feature

Conguring the recent alarms and events feature


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Overview of 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.

The following topics are described in this section:


• Setting up tags and filters

• Editing the filterEvents file (to exclude events)

• Editing the filterEvents file (to tag events 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.

Introduction to setting up tags and lters

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

Example lter script

The following provides an example of a filter script:

# File name: filterEvents.txt


# Updated 21-Apr-05, JHK & PM.
# This is the config file for the Recent Alarms/Events feature.
# The script recentConfig.sh is run from the UI as an action script.
# It uses this file to tag events and alarms as VIP, or to set Exclude filters,
on alarms and event events for any problem-type.
#
# You need to use 1 line per separate condition (VIP / Exclude) for each
Problem-type.
# If there are no settings present for a problem-type in this file, the
Default filter line is used instead.
#
# Notes:
# - You must include both Event and Alarm pipe separators on the Problem-name
line. That is, you must use a pipe to separate the 'Problem-Name, FilterType'
| the 'Events' | and the 'Alarms' |.
# - This file is not case sensitive.
#
# An Example:
#Problem-Name, FilterType |Events | Alarms |
#Path Balance Issue, VIP |equipmentFailureEvent, CM MIB|Synchronize Loss|
#Path Balance Issue, Exclude |pmProxyDisconnectedFromDB | Serial Bus |
#
####################
# DEFAULT SETTINGS
####################
#
Default, VIP |||
Default, Exclude |||
#
########################
# PROBLEM TYPE SETTINGS
########################
#
Channel requests but no calls,
Channel requests but no calls,
Database upload required,
Database upload required,
Device not in the MIB,
Device not in the MIB,,

Editing the lterEvents le to exclude events

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:

Procedure 4-15 Editing the lterEvents le to exclude events

1 As user omcadmin, edit the filterEvents file at


/usr/gsm/current/knowledge/external_problems
2 Scroll down to the Very Low TCH Usage problem type.
3 Enter the word Exclude after the first comma and before the first | (pipe).
4 Enter the event types to be excluded, after the first | and before the second |.
5 Separate each event type with a comma as seen in the following example:
# Problem-Name, FilterType |Events |Alarms|
"Very Low TCH Usage", Exclude |objectDeletionEvent, CM MIB| |
"Very Low TCH Usage",
6 Save and close the filterEvents file.
The change takes effect immediately.

Editing the lterEvents le to tag events as VIP

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:

Procedure 4-16 Editing the lterEvents le to tag events as VIP

1 As user omcadmin, edit the filterEvents file at


/usr/gsm/current/knowledge/external_problems.
2 Scroll down to the Very Low TCH Usage problem type.
Note there are two entries: one for Exclude settings, the other for VIP
settings.
3 Enter the word VIP after the first comma and before the first | (pipe).
4 Enter the event type to be tagged after the first | and before the second |.
5 Separate each event type with a comma as seen in the following example:
# Problem-Name, FilterType |Events |Alarms|
"Very Low TCH Usage", Exclude |objectDeletionEvent, CM MIB| |
"Very Low TCH Usage", VIP |stateChangeEvent |PCH Queue Page
Discard|
6 Save and close the filterEvents file.
The change takes effect immediately.

68P02900W36-P 4-77
1900.2AS May 2008
Running Active Alarm and Event reports separately Chapter 4: Administration

Running Active Alarm and Event reports separately

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.

To run these reports separately, use the following steps:

Procedure 4-17 Running Active Alarm and Event reports separately

1 Edit the file


/usr/gsm/current/knowledge/ui_action_scripts/all/recentConfig.sh
using a text editor.
2 Set the variable runActiveAlarms= to 1 (set to 1 by default).
3 Set the variable runRecentEvents= to 0 (set to 1 by default).
4 Save and close the file.
The change takes effect immediately.

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 Conguring NHA for long term statistics viewing and monitoring

Conguring NHA for long term statistics viewing and


monitoring
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the Long Term Statistics feature

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.

Enable the Long Term Statistics feature

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.

Generate MARS report

To generate a MARS report, log on to the MARS machine and start MARS. On the main window:

Procedure 4-18 Generating a MARS report

1 Select the OMC for which the statistics are required.


2 For Summarise By, select the Cell radio button.
3 Select Interval: Day.
4 Select All BSCs, All Sites, All Cells.
5 For start and end times, select the last 60 days (maximum).
6 Under Actions, click the Table button.
7 In the Select Statistics dialog box, select the following statistics:

• Call Setup Success Rate

• Call Volume

Continued

68P02900W36-P 4-79
1900.2AS May 2008
Transfer MARS report to NHA server Chapter 4: Administration

Procedure 4-18 Generating a MARS report (Continued)

• Dropped Call Rate

• Mean Time Between

• TCH Traffic Carried (Erlangs)


8 Click OK and wait for the query to complete. This action can take some time.
9 When the table is displayed, click File-Save as and save the
table as a CSV file on the MARS server using the filename:

MARS-NHA-<omcname>.csv

Transfer MARS report to NHA server

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>/.

Convert MARS report using lgConvertMARS.pl

Use the following steps to convert the MARS report:

Procedure 4-19 Converting a MARS report

1 Log on to the NHA server as user omcadmin.


2 Enter the following (all one line):

/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 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).

Changing to and from daylight saving time

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.

To check that the system is OK, perform the following steps:

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

Sending E-mail from the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to sending E-mail

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:

Filtering on TCP/Port 25 disabled to allow SMTP

• Ensure that the mail server has the SMTP service configured and running, with every
mailbox assigned an SMTP.

Setting up the NHA to send E-mail

To set up the NHA to send E-mail to a mail server user, carry out the following procedure:

Procedure 4-21 Setting up the NHA to send E-mail

1 Log on to the NHA as user root.


2 Using a preferred editor (for example, vi), edit the file/etc/hosts
by adding a mailhost entry with the following format:

<ip_address> <mail_server> mailhost


where <ip_address>is the IP address of the mail server and <mail_server>
is the hostname of the mail server.
3 Run the following commands to update the NIS maps:

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

Using the NHA to send E-mail

The NHA uses the mail server functionality in two ways:


• To forward E-mail from an account on the NHA to external mail addresses.

• To mail reports or files from the NHA to users automatically, using scripts.

Forward E-mail from an NHA account to outside mail addresses

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.

Use scripts to automatically mail reports or les

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

Installing NHA UI software on a GUI server or client


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to installing NHA software on a GUI server or


client

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.

Installing NHA UI software

Ensure that the NHA and the GUI server or client trust each other by carrying out the following
steps:

Procedure 4-23 Setting up NHA software on a GUI server or client

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

Procedure 4-23 Setting up NHA software on a GUI server or client (Continued)


7 To set up the NHA as a menu option on the GUI server or client desktop,
refer to the section on Setting up the NHA menu option in this chapter.

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

Setting up the NHA menu option


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to the NHA menu option

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.

Setting up the NHA menu option

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:

Procedure 4-24 Setting up the NHA menu option

1 Log on to the GUI server or client as root.


2 Edit the file /etc/dt/config/C/sys.dtwmrc using the text editor of your
choice.
3 Insert the following lines in the DtRightMenu section:

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

Procedure 4-24 Setting up the NHA menu option (Continued)


6 Edit the file $HOME/.dt/dtwmrc using the editor of your choice.
7 Insert the lines from step 3 in the DtRightMenu section.
These changes take effect the next time the user logs in.
8 To use the menu option, log off the GUI server
or client and log on. Right-click the CDE desktop.

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

Installing NHA UI software on a PC


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

System requirements

The minimum recommended configuration of the PC is:


• Pentium II 266 MHz

• 128 MB of RAM

• 256-bit color display

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.

• Hostname of the PC: Run the DOS command hostname.

• IP address of the PC: Run the DOS command ipconfig.

The following conditions must exist:


• The script /usr/gsm/cdrom_install/Add_PC_Clients must be run as user root on the NHA.
This script asks for the hostnames and IP addresses of any PCs to be used to run the NHA
UI. Check that the PC can be reached from the NHA by running the following command:
ping <PC hostname>

• 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 the hostname returned in the output:


64 bytes from <PC hostname> (4.xx.xx.xx): icmp_seq=0. time=1. ms

• 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.

Deleting previous versions

Delete any previous versions of the NHA UI software as follows:

Procedure 4-25 Deleting previous versions of software

1 Uninstall the old shortcuts by running C:\nhaui\UNINSTALL.BAT.


2 Delete any desktop shortcuts manually.
3 Delete the directory C:\nhaui.

Downloading NHA UI software

Download the NHA UI software from the NHA processor, using the following steps:

Procedure 4-26 Downloading NHA UI software

1 Access the NHA web page by entering http://[hostname of the NHA


machine] in a browser window.
2 In NHA Help Pages section, click Download NHAUI for PC client. Save
nhaui.exe to a local folder.

68P02900W36-P 4-89
1900.2AS May 2008
Installing NHA UI software Chapter 4: Administration

Installing NHA UI software

Use the following procedure to install the NHA UI software on a PC:

Procedure 4-27 Installing NHA UI software on a PC

1 Double click nhaui.exe that you have downloaded.


2 Click the Unzip button to extract the contents of the file to the default
directory C:\nhaui. The message Unzipped successfully is displayed
when the process is complete.
3 Click Close to close WinZip.
4 Double click INSTALL.BAT in C:\nhaui to install the menu shortcuts.
5 From the Start menu, select Programs, then right click Motorola NHA
and copy and paste the shortcut to the desktop.

For further information about installing the NHA UI on a PC, refer to the README file at
/usr/gsm/current/nhaui/pc/README.txt.

Setting up the PC environment

From the Start menu, select the environment setting as follows:

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

Use the following steps to set up the PC environment:

Procedure 4-28 Setting up the PC environment

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.

More than one NHA processor

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

1 Copy and paste the Motorola NHA shortcut on the desktop.


2 Right-click the new Motorola NHA shortcut.
3 Select Properties-Shortcut.
4 Append <NHA hostname> to the text in the Target field.
For example, if the NHA hostname to be connected is nhasys1, edit the
contents of the Target field so that it changes from C:\nhaui\bin\nhaui.BAT
to C:\nhaui\bin\nhaui.BAT nhasys1.

Uninstalling NHA UI software

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

Setting client machines for remote login


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

GSR8 OMC-R remote login

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.

Figure 4-3 Remote login scenario

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

To enable a remote login to multi-OMC NHAs, use the following steps:

Procedure 4-30 Enabling remote login to multi-OMC NHAs

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:

rsh [omchostname] /usr/openwin/bin/xterm -d [user's IP


address]:0.0 -e /usr/gsm/current/bin/RLstart [BSSname]

Modifying permissions to allow remote login from PC clients

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]

GSR9 OMC-R remote login onwards

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

Carry out the following checks:


1. SSH to OMC server using any SSH client application. (For example, PuTTY for PC, ssh
command for UNIX)

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

Carry out the following checks:


• Check that you can ping your PC from the OMC and that you can ping the OMC from the PC.

• 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 Congure password le location

Congure 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.

Figure 4-4 BSS Rlogin Option Dialog

68P02900W36-P 4-95
1900.2AS May 2008
Adding an OMC to be monitored Chapter 4: Administration

Adding an OMC to be monitored


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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

1 Ensure that there are sufficient processors and memory


by checking the hardware on the NHA against the
hardware requirements in the pre-installation checklist.

If adding a fifth OMC, refer to the Note in NHA troubleshooting on


page 4-21.
2 Check that there sufficient licenses to monitor the number of OMCs needed
as follows:

• Check the G2 license file:


more /opt/gensym/current/g2/g2.ok

• Check number-of-processes-authorized. Three licenses are needed


for every OMC being monitored.

• Check the NHA license file:


more /usr/gsm/config/local/license_file
One NHA server license is required for every OMC being
monitored.

One NHA client license is required for every display, whether it


is on a terminal or a PC.
Assuming that commercial agreements are in order, order updated
G2 and NHA licenses by mailing softdist@motorola.com.
3 If required, update the licenses. Once new licenses are received, update
them using the procedures outlined in the Installation and Upgrade Guide,
provided with the manual Software Release Notes: Network Health Analyst
(68P02900W77).

4-96 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Installing an additional OMC

Installing an additional OMC

To install an additional OMC, carry out the following procedure:

Procedure 4-33 Installing an additional OMC

1 Insert the NHA software CD-ROM.


2 Log on as user root and run the installation script as follows:

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:

The Install script finds the configuration information


from the OMC and outputs the following summary:
Host information
-------------
System Processor: [OMC]
MIB Processor: [OMC]
MMI Server: [MMI_Name]
NHA Config. file: /usr/gsm/OMCs/<omcname>/config/ea.cfg
After the summary, the operator is asked for any corrections. At this stage,
change all or some of the hosts found (if necessary) as follows:
Is this information correct [Y/N]

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

Deleting an OMC from the NHA


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Before removing an OMC

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:

Procedure 4-34 Reassigning the primary OMC

1 Stop the NHA for all OMCs.


2 As user root, enter:
cd /usr/gsm/cdrom_install
./Configure_NIS
and specify the new primary OMC at the prompt.
3 As user root execute the following commands on the NHA processor:
/usr/lib/netsvc/yp/ypstop
/usr/lib/netsvc/yp/ypstart
4 As user root, enter:
cd /usr/gsm/cdrom_install
./Configure_Hosts
and specify the new primary OMC at the prompt.
5 Reboot the NHA.
6 Start the NHA on the OMCs which are not to be removed and continue
the procedure.

Otherwise, if the NHA to be removed is the secondary OMC, do the following:

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

Procedure 4-35 Reassigning the secondary OMC

1 Stop the NHA on the OMC to be uninstalled.


2 As user root on the NHA, enter the following:
cd /usr/gsm/cdrom_install
./OMCmanager delete
3 Select the appropriate OMC and confirm by typing Yes.

On the OMC

Modify files on the OMC as follows:

Procedure 4-36 Modifying les on the OMC

1 Remove the NHA from:


/etc/hosts
/etc/hosts.equiv
/.rhosts
2 Back up the /etc/dfs/dfstab file. Edit the original file and then do the
following:

• Search for lines containing the NHA hostname.

• 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.

• Save the file and execute shareall.

• Delete the backup file.

On the GUI servers or clients for this OMC

Remove files from the GUI servers or clients for this OMC as follows:

Procedure 4-37 Removing les from the GUI servers or clients

1 Remove /usr/gsm/nhacurrent and the directory it points to.


2 Remove /usr/opt/gensym.
3 Remove /gen/nha.
4 Remove NHA from /etc/hosts, /etc/hosts.equiv and /.rhosts.

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

Uninstalling the NHA from a GUI server or client


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Procedure for uninstalling from a GUI server or client

To disconnect the NHA from a GUI server or client, perform the following steps:

Procedure 4-38 Disconnecting the NHA from a GUI server or client

1 As user root on the NHA, remove references (if the references


exist) to the GUI server or client from the following files:
/etc/hosts
/etc/hosts.equiv
/.rhosts
/usr/gsm/config/local/OMCs.cfg
2 As user root on the NHA, enter the following command:

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

Adding new users


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to adding new users

The NHA uses the primary OMC for its Network Information Services (NIS) information,
including user accounts.

New users on a primary OMC

If a new user is created on the primary OMC, update the NIS maps as follows:

Run the following command on the OMC as user root:

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.

New users on a secondary OMC

To add users to the NHA who do not have accounts on the primary OMC, perform the following
steps:

Procedure 4-39 Adding new users on a secondary OMC

1 Log on to the NHA as user root.


2 Once only, set up a directory for home
directories and a group called nha as follows:
mkdir -p /gen/home (Make a directory for home directories)
groupadd -g 112 nha (Create a group called nha with groupid112).

Continued

4-102 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst New users on a secondary OMC

Procedure 4-39 Adding new users on a secondary OMC (Continued)


3 Add the new users, giving them the same username and userid as they have
on the secondary OMC.

• Ensure that their home directory on the NHA is /gen/home

NOTE
Their home directory must not be /home as this is NFS
mounted from the primary OMC.

• Create users on the NHA in a separate nha group with a separate


groupid (for example, 112).

• 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

Backing up le systems


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Introduction to le system backup

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

• System shutdown procedure

• JumpStart NHA processor

• Full file system recovery on the NHA processor

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.

Complete le system backup on the NHA processor (automatic)

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.

To back up the file systems on the NHA processor, do the following:

Procedure 4-40 Backing up the le systems on the NHA processor

1 Log on to the NHA processor as user root.


2 Bring the system down to single user mode:
init 1
3 Insert a new tape (DAT) into the tape drive, after ensuring that it is not
write-protected.
4 Enter the following command to change to
the /usr/gsm/current/sbin directory:
cd /usr/gsm/current/sbin

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.

Enter R for a remote backup to the Single Platform processor if


a remote backup is required. The following prompt is displayed:
Valid Backup Tape Types
D. DAT
Q. QUIT
Enter Backup Tape Type:

Enter D as the backup tape type. The following prompt is displayed:


Is there a writable DAT tape loaded in the Tape Drive ??
Y to continue
Q to quit
Enter Choice:

Enter Y to continue. The following prompt is displayed:


Enter Local Tape Device (Default is /dev/rmt/0) (Q to Quit):

Enter the backup tape device name as /dev/rmt/0n.

Output like the following is displayed:


Attempting to archive the following partitions :
/,
/usr,
/var,
/usr/gsm
Attempting to backup / filesystem...
DUMP: Date of this level 0 dump:
Wed 27 Jun 2007 07:03:10 PM GMT
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d0 (sf440-2:/) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 608918 blocks (297.32MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 608894 blocks (297.31MB) on 1 volume at 1630 KB/sec
DUMP: DUMP IS DONE
DUMP: Level 0 dump on Wed 27 Jun 2007
07:03:10 PM GMT 608896+0 records in
9514+0 records out

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.

Table 4-13 Partition locations for backed up le systems

File system Backup partitions


/ /dev/md/dsk/d0
/usr /dev/md/dsk/d10
/var /dev/md/dsk/d15
/usr/gsm /dev/md/dsk/d20

68P02900W36-P 4-107
1900.2AS May 2008
NHA system recovery for SunFire V440 and Netra N440 Chapter 4: Administration

NHA system recovery for SunFire V440 and Netra N440


■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

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:

• Shut down the system.

• Jumpstart the NHA processor for SunFire V440 or Netra N440.

• Restore the NHA file systems.

• Recreate the BOOT system.

• Roll back the client software.

• Start the NHA.

Prerequisites

Before starting the restore procedure, obtain the following items:


• The most recent set of complete file system level 0 backup tapes.

• The Solaris 10 NHA JumpStart DVD-ROM (NHAJS19002AS.1.00).

Shutting down the system

To shut down the NHA processor, follow Procedure 4-41:

Procedure 4-41 Shut down the NHA processor

1 Log on to the NHA processor as user root.

Continued

4-108 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst JumpStarting the NHA processor for SunFire V440 or Netra N440

Procedure 4-41 Shut down the NHA processor (Continued)


2 Enter the following commands to inform all users
that a complete system restore is to be carried out:
wall
System coming down immediately
^d
3 Bring the system to the OK prompt by entering:
/usr/sbin/shutdown -i0 -g0 -y

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.

Restoring NHA le systems

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.

Procedure 4-42 Restore NHA le systems

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

Procedure 4-42 Restore NHA le systems (Continued)


4 Mount the partitions to their appropriate mount points:
mount /dev/dsk/c1t2d0s0 /mnt
mount /dev/dsk/c1t2d0s3 /mnt/usr
mount /dev/dsk/c1t2d0s4 /mnt/var

NOTE
Use the metastat command to ensure that the partitions used
for/, /usr, /var, and /usr/gsm are identical to those partitions
used previously

Restoring the / le system

To restore the root (/) file system, follow Procedure 4-43:

Procedure 4-43 Restore the / le system

1 To restore the first volume on the tape, the


/ file system, enter the following command:
cd /mnt
ufsrestore xvfs /dev/rmt/0 1
The following prompt is displayed:
Specify next volume #
2 Enter 1. The following prompt is displayed:
Set directory mode, owner and times
set owner / mode for ’.’? [yn]
3 Enter y. The following prompt is displayed:
Directories already exist, set mode anyway? [yn]
4 Enter y.

Restoring the /usr le system

To restore the /usr file system, follow Procedure 4-44:

Procedure 4-44 Restore the /usr le system

1 To restore the second volume on the tape,


the /usr file system, enter the following:
cd /mnt/usr
ufsrestore xvfs /dev/rmt/0 2
The following prompt is displayed:
Specify next volume #:

Continued

4-110 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Restoring NHA le systems

Procedure 4-44 Restore the /usr le system (Continued)


2 Enter 1. The following prompt is displayed:
Set directory mode, owner and times
set owner / mode for ’.’? [yn]
3 Enter y. The following prompt is displayed:
Directories already exist, set mode anyway? [yn]
4 Enter y.

Restoring the /var lesystem

To restore the /var file system, follow Procedure 4-45:

Procedure 4-45 Restore the /var lesystem

1 To restore the third volume on the tape,


the /var file system, enter the following:
cd /mnt/var
ufsrestore xvfs /dev/rmt/0 3
The following prompt is displayed:
Specify next volume #:
2 Enter 1. The following prompt is displayed:
Set directory mode, owner and times
set owner / mode for ’.’? [yn]
3 Enter y. The following prompt is displayed:
Directories already exist, set mode anyway? [yn]
4 Enter y.

Restoring the /usr/gsm lesystem

To restore the /usr/gsm file system, follow Procedure 4-46:

Procedure 4-46 Restore the /usr/gsm lesystem

1 To restore the fourth volume on the tape,


the /var file system, enter the following:
cd /usr/gsm
ufsrestore xvfs /dev/rmt/0 4
The following prompt is displayed:
Specify next volume #:
2 Enter 1. The following prompt is displayed:
Set directory mode, owner and times
set owner / mode for ’.’? [yn]
3 Enter y. The following prompt is displayed:
Directories already exist, set mode anyway? [yn]
4 Enter y.

68P02900W36-P 4-111
1900.2AS May 2008
Recreating the BOOT system Chapter 4: Administration

Unmount and fsck lesystems

To unmount and fsck the filesystems, follow Procedure 4-47:

Procedure 4-47 Unmount and fsck lesystems

1 To unmount the filesystems, enter the following:


umount /mnt/var
umount /mnt/usr
umount /mnt
2 To fsck the filesystems, enter the following:
fsck -y /dev/rdsk/c1t2d0s0
fsck -y /dev/rdsk/c1t2d0s3
fsck -y /dev/rdsk/c1t2d0s4
3 To mount back the filesystems, enter the following:
mount /dev/dsk/c1t2d0s0 /mnt
mount /dev/dsk/c1t2d0s3 /mnt/usr
mount /dev/dsk/c1t2d0s4 /mnt/var

Recreating the BOOT system

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.

To make the appropriate changes, follow Procedure 4-48:

Procedure 4-48 Recreate the BOOT system

1 Open /mnt/etc/vfstab for editing by executing the following command:


vi /mnt/etc/vfstab
2 Find the following lines:
/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no logging
/dev/md/dsk/d10 /dev/md/rdsk/d10 /usr ufs 1 no logging
/dev/md/dsk/d15 /dev/md/rdsk/d15 /var ufs 1 no logging
3 Change these lines to:
/dev/dsk/c1t2d0s0 /dev/rdsk/c1t2d0s0 / ufs 1 no logging
/dev/dsk/c1t2d0s3 /dev/rdsk/c1t2d0s3 /usr ufs 1 no logging
/dev/dsk/c1t2d0s4 /dev/rdsk/c1t2d0s4 /var ufs 1 no logging/
4 Open the /mnt/etc/system for editing by executing the following command:
vi /mnt/etc/system

Continued

4-112 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Reattaching devices

Procedure 4-48 Recreate the BOOT system (Continued)


5 Change the following line in the /mnt/etc/system
file in c1t2d0s0 using the asterisk key (*):
from
rootdev:/pseudo/md@0:0,0,blk
to
*rootdev:/pseudo/md@0:0,0,blk

Rebooting the NHA processor

To reboot the NHA processor, follow Procedure 4-49:

Procedure 4-49 Reboot the NHA processor

1 Bring the NHA machine to the OK prompt by


executing the following command as user root:
/usr/sbin/shutdown -i0 -g0 -y
2 At the OK prompt, type the following command:
boot mirrordisk -s

Reattaching devices

Any errors found after booting up for the first time can be safely ignored.

To reattach devices, follow Procedure 4-50:

Procedure 4-50 Reattach devices

1 As user root on the NHA processor, run the


following commands to reset the mirror devices:
metaclear -r d0
metaclear -r d10
metaclear -r d15
2 Re-create and link the mirrors:
metainit d0 -m d2
metainit d10 -m d12
metainit d15 -m d17
3 Reset the root partition:
metaroot d0

68P02900W36-P 4-113
1900.2AS May 2008
Reattaching devices Chapter 4: Administration

Rebooting the NHA processor

To reboot the NHA processor, follow Procedure 4-51:

Procedure 4-51 Reboot the NHA processor

1 Bring the NHA machine to the OK prompt by


executing the following command as user root:
/usr/sbin/shutdown -i0 -g0 -y
2 At the OK prompt, type the following command:
boot mirrordisk -s

Reattaching devices (continued)

To continue reattaching devices, follow Procedure 4-52:

Procedure 4-52 Reattach devices (continued)

1 As user root on the NHA processor, run the following


commands to relink the rest of the mirror devices:
metainit d1 1 1 c1t0d0s0
metattach d0 d1
metainit d11 1 1 c1t0d0s3
metattach d10 d11
metainit d16 1 1 c1t0d0s4
metattach d15 d16
..
At this stage of the rollback, the mirrors are reattached to their appropriate
meta-devices. This synchronization process can take some time to
complete and during this time processor performance is not at
its optimum level. To verify that the synchronization process is
complete, run the metastat command.
2 Redo the boot block:
cd /usr/platform/‘uname -i‘/lib/fs/ufs
/usr/sbin/installboot bootblk /dev/rdsk/c1t0d0s0
3 Open the vfstab file for editing by executing this command:
vi /etc/vfstab
4 Find the following line:
/dev/dsk/c1t2d0s3 /dev/rdsk/c1t2d0s3 /usr ufs 1 no logging
/dev/dsk/c1t2d0s4 /dev/rdsk/c1t2d0s4 /var ufs 1 no logging
5 Edit the line as follows:
/dev/md/dsk/d10 /dev/md/rdsk/d10 /usr ufs 1 no logging
/dev/md/dsk/d15 /dev/md/rdsk/d15 /var ufs 1 no logging
6 Save the file and exit the vi editor.

4-114 68P02900W36-P
1900.2AS May 2008
System Information: Network Health Analyst Rolling back NHA client software

Fsck the newly mirrored lesystem

To fsck the newly mirrored filesystems, follow Procedure 4-53:

Procedure 4-53 Fsck the newly mirrored lesystems

1 To fsck the filesystems, enter the following:

fsck -y /dev/rdsk/c1t0d0s0
fsck -y /dev/rdsk/c1t0d0s3
fsck -y /dev/rdsk/c1t0d0s4

Rebooting the NHA processor

Before rebooting the NHA processor, ensure that the synchronization process has finished. Run
the metastat command to verify this action.

To reboot the NHA processor, execute the following command:

/usr/sbin/shutdown -i6 -g0 -y

Rolling back NHA client software

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.

Rolling back PC client software

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

Starting the NHA

To start the NHA, follow Procedure 4-54:

Procedure 4-54 Start the NHA

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
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Action scripts option . . . . . . . . . . . 2-55 Automatic cell grouping. . . . . . . . . . 2-122


User interface action scripts . . . . . . 2-209 Automatic cell grouping scripts . . . . . 2-122
Adding a comment . . . . . . . . . . . . 2-39 Automatic export from Problem window. . 2-59
Adding an OMC . . . . . . . . . . . . . . 4-96 Automatically running automatic cell
Administration tasks . . . . . . . . . . . . 4-2 grouping . . . . . . . . . . . . . . . . . 2-128
Alarm and event reports, run separately. . 4-78 background functionality . . . . . . . . 2-130
Applying detector threshold values . . . . 2-179 multiple OMCs . . . . . . . . . . . . . 2-132
Automated thresholds . . . . . . . . . . . 3-182 results . . . . . . . . . . . . . . . . . 2-130
problem reducer script . . . . . . . . . 3-183 scripts . . . . . . . . . . . . . . . . . 2-131
thresholds calculator script . . . . . . . 3-185 Autoresync the OMC . . . . . . . . . . . 4-63
Automatic blacklisting . . . . . . . . . . 1-24
maintenance . . . . . . . . . . . . . . 1-24

Blacklist menu option . . . . . . . . . . . 2-16 BSS Regions, configuring (contd.)


Blacklisting devices . . . . . . . . . . . . 2-157 delete . . . . . . . . . . . . . . . . . . 2-141
Broadcast menu option . . . . . . . . . . 2-15 modify . . . . . . . . . . . . . . . . . 2-140
Broadcast messages . . . . . . . . . . . 2-12 verify . . . . . . . . . . . . . . . . . . 2-141
BSS detector check . . . . . . . . . . . . 2-81 BSS-level detectors . . . . . . . . . . . . 3-164
BSS Regions, configuring . . . . . . . . . 2-139 Building new formulae . . . . . . . . . . 2-169
create . . . . . . . . . . . . . . . . . . 2-139 Bulk changes on Thresholds window . . . 2-135

Call success problem . . . . . . . . . . . 3-10 Cell groups (contd.)


Call success problem list . . . . . . . . . . 3-9 moving cells. . . . . . . . . . . . . . . 2-108
Carrier statistics . . . . . . . . . . . . . 4-70 Cell Regions, configuring . . . . . . . . . 2-142
Carrier statistics on the Problem win create . . . . . . . . . . . . . . . . . . 2-142
dow . . . . . . . . . . . . . . . . . . . . 2-48 delete . . . . . . . . . . . . . . . . . . 2-147
Carrier statistics problem list . . . . . . . 3-85 modify . . . . . . . . . . . . . . . . . 2-145
Cell grouping . . . . . . . . . . . . 1-30, 2-106 verify . . . . . . . . . . . . . . . . . . 2-147
Cell grouping . . . . . . . . . . . . . . 4-57 Cell statistics . . . . . . . . . . . . . 2-46, 4-65
Creating cell groups . . . . . . . . . . 1-30 Cell View menu option . . . . . . . 2-15 to 2-16
Cell groups Cell View window . . . . . . . . . . . . . 2-115
automatic cell groups . . . . . . . . . . 2-107 menu options . . . . . . . . . . . . . . 2-118
automatically running automatic cell pop-up menu options . . . . . . . . . . 2-119
grouping . . . . . . . . . . . . . . . . 2-128 Channel requests but no calls . . . . . . . 3-34
creating a cell group . . . . . . . . . . 2-111 Clear menu option . . . . . . . . . . . . 2-14
default groups . . . . . . . . . . . . . 2-108 Columns . . . . . . . . . . . . . . . . . 2-14
manual cell groups . . . . . . . . . . . 2-107 Comments, adding . . . . . . . . . . . . 2-39
manually running automatic cell group Configurable files exported on shut
ing . . . . . . . . . . . . . . . . . . . 2-124 down . . . . . . . . . . . . . . . . . . . 4-35

68P02900W36-P IX-1
May 2008 1900.2AS
Index

Configuration reports . . . . . . . . . . . 2-89 Configuring statistics . . . . . . . . . . . 2-46


Configuration setup Configuring the NHA . . . . . . . . . . . 2-104
Configuration setup . . . . . . . . . . . 4-45 Configuring the NHA to run automatic cell
Configure for printing . . . . . . . . . . . 4-61 grouping automatically . . . . . . . . . . 2-128
Configure menu . . . . . . . . . . . . . . 2-104 Configuring the NHA to run automatic cell
blacklisting devices . . . . . . . . . . . 2-157 grouping manually . . . . . . . . . . . . 2-124
cell groups . . . . . . . . . . . . . . . 2-106 Connections status . . . . . . . . . . . . 2-17
daily export . . . . . . . . . . . . . . . 2-160 Consolidated problems . . . . . . . . . . 3-173
group properties . . . . . . . . . . . . 2-110 Contents menu option. . . . . . . . . . . 2-17
neighbor cell statistics . . . . . . . . . 2-156 Copy problems . . . . . . . . . . . . . . 2-13
report to OMC . . . . . . . . . . . . . 2-161 Creating a custom formula . . . . . . . . 2-166
statistics per problem . . . . . . . . . . 2-155 Custom detectors . . . . . . . . . . . . . 2-171
subscriptions . . . . . . . . . . . . . . 2-148 creating new . . . . . . . . . . . . . . 2-172
thresholds. . . . . . . . . . . . . . . . 2-133 editing . . . . . . . . . . . . . . . . . 2-174
automatic export and import . . . . . 2-138 example . . . . . . . . . . . . . . . . . 2-176
user defined causes . . . . . . . . . . . 2-151 Custom formulae . . . . . . . . . . . . . 2-165
Configure the NHA to read GPRS statis Customised causes . . . . . . . . . . . . 2-151
tics . . . . . . . . . . . . . . . . . . . . 4-47 Customised problems . . . . . . . . . . . 3-179
Configuring IMSI-DETACH . . . . . . . . 4-47 Cyclic Neighbor statistics . . . . . . . . . 2-211
Configuring NHA for long term statistics viewing configuring on the NHA . . . . . . . . . 2-212
and monitoring . . . . . . . . . . . . . . 4-79 using output on OMC . . . . . . . . . . 2-213

Daily export . . . . . . . . . . . . . . . . 2-160 Detection mechanisms (contd.)


Daily Export menu option . . . . . . . . . 2-16 interval roll-up . . . . . . . . . . . . . 1-15
Daily key statistics, export . . . . . . . . 4-37 long term detection . . . . . . . . . . . 1-19
Database upload required. . . . . . . . . 3-143 sample roll-up. . . . . . . . . . . . . . 1-13
Default cell groups . . . . . . . . . 1-30 to 1-31 sliding scales . . . . . . . . . . . . . . 1-17
Default threshold levels . . . . . . . . . . 4-59 Detectors, modifying . . . . . . . . . . . 2-133
Deleting an OMC from the NHA . . . . . 4-98 Device not in the MIB . . . . . . . . . . . 3-134
Detection and monitoring . . . . . . . . . . 1-4 Device out of service (OOS) . . . . . . . . 3-153
Detection mechanisms . . . . . . . . . . . 1-8 Device status . . . . . . . . . . . . . . . 2-86
daily roll-up . . . . . . . . . . . . . . . . 1-9 Directory structures . . . . . . . . . . . 4-11
event pattern analysis. . . . . . . . . . 1-20 Disk space usage . . . . . . . . . . . . . 4-23
fixed threshold . . . . . . . . . . . . . 1-11 Dropped call rate . . . . . . . . . . . . . 3-14

E-mail from the NHA . . . . . . . . . . . 4-82 Example custom detector (contd.)


prerequisites . . . . . . . . . . . . . . 4-82 formula and detectors. . . . . . . . . . 2-176
sending e-mail . . . . . . . . . . . . . 4-83 Example external interface scripts . . . . 2-184
setup . . . . . . . . . . . . . . . . . . 4-82 Example of a network fault . . . . . . . . 1-26
ea.cfg file . . . . . . . . . . . . . . . . . 4-45 detecting faults . . . . . . . . . . . . . 1-28
Edit a custom detector . . . . . . . . . . 2-174 Exit from the Problem window . . . . . . 2-13
Editing a custom formula . . . . . . . . . 2-166 Export displayed problems . . . . . . . . 2-13
Enabling a resync . . . . . . . . . . . . . 4-63 Export key statistics . . . . . . . . . . . 4-37
Enabling statistics . . . . . . . . . . . . 4-65 Exporting cell group files . . . . . . . . . 2-120
Event based problem list . . . . . . . . . 3-142 Exporting cell group names . . . . . . . . 2-112
Event history . . . . . . . . . . . . . . . 2-49 Exporting problem details. . . . . . . . . 2-58
Example custom detector . . . . . . . . . 2-176 Exporting problem reports
building the formula . . . . . . . . . . 2-177 Exporting problem reports . . . . 2-59 to 2-61
creating the detector . . . . . . . . . . 2-178

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

File system backup . . . . . . . . . . . . 4-104 Find problems. . . . . . . . . . . . . . . 2-13


automatic file system backup . . . . . . 4-104 Font size . . . . . . . . . . . . . . . . . 2-14
Filter menu option . . . . . . . . . . . . 2-15 Formula version editor . . . . . . . . . . 2-168
Filter problem type and value . . . . . . . 2-25 Frequency clash report . . . . . . . . . . 2-102
Filtering problems . . . . . . . . . . . . 2-19 Frequency Clash Report menu option . . . 2-15

G2 interface limitations . . . . . . . 2-85, 2-164 GPRS no activity in cell . . . . . . . . . . 3-108


GCLK recalibration required . . . . . . . 3-145 GPRS Out of Service (OOS) . . . . . . . . 3-114
Generating a new ssh key in NHA. . . . . 4-30 GPRS problem list. . . . . . . . . . . . . 3-102
Getting Started - an introduction to the NHA GPRS requests but no data . . . . . . . . 3-103
Getting started - an introduction to the Group properties
NHA . . . . . . . . . . . . . . . . . . . 2-2 configuring . . . . . . . . . . . . . . . 2-110
Global ea.cfg file, configuring . . . . . . . 4-45 Group Properties menu option . . . . . . 2-16
GPRS high timeslot utilization . . . . . . 3-106 GSM call process model. . . . . . . . . . 1-25

Handle problems . . . . . . . . . . . . . 2-14 High GPRS Utilization by Traffic (Uplink/Down


Handover problem list . . . . . . . . . . 3-64 link) . . . . . . . . . . . . . . . . . . . . 3-117
Handover reason problem list . . . . . . . 3-78 High handover rate . . . . . . . . . . . . 3-79
Hardware installation . . . . . . . . . . . 4-19 High immediate assignment blocking . . . 3-51
Help. . . . . . . . . . . . . . . . . . . . . 2-4 High immediate assignment failure rate. . 3-26
High BER imbalance on odd/even times High interference on idle rate. . . . . . . 3-95
lots . . . . . . . . . . . . . . . . . . . . 3-97 High MTL utilization . . . . . . . . . . . 3-57
High bit error rate . . . . . . . . . . . . 3-86 High PRP load. . . . . . . . . . . . . . . 3-121
High downlink block error rate . . . . . . 3-129 High RF losses imbalance on odd or even
High DPROC utilization . . . . . . . . . . 3-131 timeslots . . . . . . . . . . . . . . . . . 3-93
High estimated RSL utilization . . . . . . 3-59 High RSL Utilization . . . . . . . . . . . 3-62
High frame erasure rate . . . . . . . . . 3-88 High second assignment . . . . . . . . . 3-19
High GPROC utilization . . . . . . . . . . 3-49 High TCH blocking . . . . . . . . . . . . 3-53
High GPRS timeslot congestion . . . . . . 3-111 Historical OOS reports . . . . . . . . . . 2-92

Importing cell group files . . . . . . . . . 2-120

68P02900W36-P IX-3
May 2008 1900.2AS
Index

Importing cell group names . . . . . . . . 2-112 INSM UI menu option . . . . . . . . . . . 2-15


Importing problems into spreadsheets . . 2-61, Installing an additional OMC . . . . . . . 4-97
4-33 Installing NHA on a GUI server or client. . 4-84
IMSI-DETACH. . . . . . . . . . . . . . . 4-47 Installing NHA on an MMI
In Service Monitor (INSM) tool . . . . . . 2-84 Installing NHA on a GUI server or
Infrastructure problem list . . . . . . . . 3-133 client . . . . . . . . . . . . . . . . . . 4-84
INSM graphical display . . . . . . . . . . 2-85 Installing NHA UI software on a PC . . . . 4-88
INSM logic . . . . . . . . . . . . . . . . 2-86 download NHA UI software . . . . . . . 4-89
INSM network display . . . . . . . . . . 2-88 more than one NHA processor . . . . . 4-90
manually blacklisting a device . . . . . 2-95 setup PC environment. . . . . . . . . . 4-90
viewing reports . . . . . . . . . . . . . 2-89 Interband handover success . . . . . . . 3-65
INSM reports . . . . . . . . . . . . . . . 2-89

Key statistics, daily export . . . . . . . . 4-37 Knowledge Editor (contd.)


Knowledge editing . . . . . . . . . . . . 2-162 import/export detectors and formu
Knowledge Editor . . . . . . . . . . . . . 2-163 lae . . . . . . . . . . . . . . . . . . . 2-164
G2 interface limitations . . . . . . . . . 2-164 Knowledge Editor menu option . . . . . . 2-15
Knowledge Editor problems. . . . . . . . 3-179

List of problems . . . . . . . . . . . . . . . 3-3 Low immediate assignment success rate. . 3-29


Log files . . . . . . . . . . . . . . . . . . 4-35 Low incoming handover success (inter/intra-
Long term problem detection . . . . . . . 3-159 BSS) . . . . . . . . . . . . . . . . . . . 3-68
Long term statistics . . . . . . . . . . . . 2-51 Low Inter-BSS handover attempt rate. . . 3-70
configuring additional statistics . . . . . 2-51 Low mean time between dropped calls . . 3-21
viewing . . . . . . . . . . . . . . . . . 2-52 Low mean time between handovers . . . . 3-72
viewing neighbor cells . . . . . . . . . 2-54 Low number of mobile terminated calls . . 3-41
Long term statistics viewing and monitoring, Low outgoing Inter-RAT handover success
configuring . . . . . . . . . . . . . . . . 4-79 rate . . . . . . . . . . . . . . . . . . . . 3-76
Long-term detection . . . . . . . . . . . 1-19 Low TCH mean holding time . . . . . . . 3-23
Low handover rate - power budget . . . . 3-83

Macro for Excel . . . . . . . . . . . . . . 2-60 Menu options (contd.)


Manual cell grouping . . . . . . . . . . . 2-115 Edit . . . . . . . . . . . . . . . . . . . 2-13
exporting cell group files . . . . . . . . 2-120 File . . . . . . . . . . . . . . . . . . . 2-13
importing cell group files . . . . . . . . 2-120 Help. . . . . . . . . . . . . . . . . . . 2-17
manually moving cells Problem . . . . . . . . . . . . . . . . . 2-14
manually moving cells . . . . . . . . 2-115 Shutdown . . . . . . . . . . . . . . . . 2-16
Manual export from Problem window . . . 2-59 Tools . . . . . . . . . . . . . . . . . . 2-15
Manually blacklisting a device . . . . . . 2-95 View . . . . . . . . . . . . . . . . . . 2-14
Manually running automatic cell group MMI menu option . . . . . . . . . . . . . 4-86
ing . . . . . . . . . . . . . . . . . . . . 2-124 Modifying detectors and thresholds
background functionality . . . . . . . . 2-126 importing thresholds . . . . . . . . . . 2-136
Menu options . . . . . . . . . . . . . . . 2-13 menu options . . . . . . . . . . . . . . 2-136
Configure . . . . . . . . . . . . . . . . 2-16 Monitoring schedule . . . . . . . . . . . 4-55
Data. . . . . . . . . . . . . . . . . . . 2-15

IX-4 68P02900W36-P
1900.2AS May 2008
Index

Neighbor cell statistics . . . . . . . 2-49, 2-156 NHA performance checks


Neighbor Cell Statistics menu option . . . 2-16 disk space usage . . . . . . . . . . . . 4-23
Neighbor cells, viewing . . . . . . . . . . 2-54 health . . . . . . . . . . . . . . . . . . 4-21
Network devices, view status . . . . . . . 2-85 performance troubleshooting . . . . . . 4-24
New users - adding to primary OMC . . . 4-102 response time . . . . . . . . . . . . . . 4-26
New users on primary OMC. . . . . . . . 4-102 shutdown . . . . . . . . . . . . . . . . 4-22
NHA and time . . . . . . . . . . . . . . . 4-81 status . . . . . . . . . . . . . . . . . . 4-21
NHA configuration file . . . . . . . . . . 4-45 NHA UI Client Login . . . . . . . . . . . . 2-5
NHA default thresholds . . . . . . . . . . 3-181 Introduction to NHA UI Client Login
NHA detection examples . . . . . . . . . 1-25 feature . . . . . . . . . . . . . . . . . . 2-5
NHA detection mechanisms Using the NHA UI Client Login feature . . 2-5
Call process model . . . . . . . . . . . 1-25 NHA web page . . . . . . . . . . . . . . 2-65
NHA licenses . . . . . . . . . . . . . . . 4-14 NHA web page menu option . . . . . . . 2-15
NHA log files . . . . . . . . . . . . . . . 4-33 No statistics from BSS . . . . . . . . . . 3-136
configurable files exported on shut No statistics from Cell . . . . . . . . . . 3-138
down . . . . . . . . . . . . . . . . . . 4-35 No statistics from site . . . . . . . . . . . 3-140

OMC configuration . . . . . . . . . . . . 4-62 OOS reports


GPRS statistics . . . . . . . . . . . . . 4-70 displaying . . . . . . . . . . . . . . . . 2-90
required statistics. . . . . . . . . . . . 4-65 historical
resync function . . . . . . . . . . . . . 4-62 historical . . . . . . . . . . . . . . . 2-92
OMC Informix settings, check. . . . . . . 4-32 scheduled . . . . . . . . . . . . . . . . 2-93
OMC problems . . . . . . . . . . . . . . 4-51 Options, setting . . . . . . . . . . . . . . 2-14
OMC Shutdown menu option . . . . . . . 2-16 Out of service timeslots in cell . . . . . . 3-42
OMC specific ea.cfg file, configuring . . . 4-46 Outage problem list . . . . . . . . . . . . 3-33
One-way MTL . . . . . . . . . . . . . . . 3-46 Outgoing handover success rate . . . . . 3-73
Online help . . . . . . . . . . . . . . . . . 2-4 Overload problem list . . . . . . . . . . . 3-48
OOS indicator button . . . . . . . . . . . 2-88 Overview menu option . . . . . . . . . . 2-17

Paging overflow . . . . . . . . . . . . . . 3-55 Problem Information window (contd.)


Parameter check report . . . . . . . . . . 2-69 line of reasoning . . . . . . . . . . . . 2-35
Path balance problem . . . . . . . . . . . 3-91 problem causes and corrective ac
Performance checks. . . . . . . . . . . . 4-21 tions . . . . . . . . . . . . . . . . . . 2-35
Performance statistics check . . . . . . . 4-26 problems on device, neighbor and site. . 2-36
Periodic resync . . . . . . . . . . . . . . 4-64 Problem list . . . . . . . . . . . . . . . . . 3-3
Print displayed problems . . . . . . . . . 2-13 BSS-level detectors . . . . . . . . . . . 3-164
Printer setup . . . . . . . . . . . . . . . 4-61 Channel requests but no calls . . . . . . 3-34
Printing problem details . . . . . . . . . 2-58 Consolidated problems . . . . . . . . . 3-173
Problem clearing mechanisms . . . . . . 1-21 Database upload required. . . . . . . . 3-143
Problem detection process . . . . . . . . . 1-5 Device not in the MIB . . . . . . . . . . 3-134
Call process model . . . . . . . . . . . . 1-5 Device out of service (OOS) . . . . . . . 3-153
Problem detection, long term . . . . . . . 3-159 GCLK recalibration required (multiple
Problem guide . . . . . . . . . . . . . . . 3-2 sites) . . . . . . . . . . . . . . . . . . 3-145
Problem history reports . . . . . . . . . . 2-57 GCLK recalibration required (single
Problem Information window . . . . . . . 2-32 site) . . . . . . . . . . . . . . . . . . . 3-145
detector information . . . . . . . . . . 2-35

68P02900W36-P IX-5
May 2008 1900.2AS
Index

Problem list (contd.) Problem list (contd.)


GPRS Out of Service (OOS) in BSS, Cell, High RF losses out of proportion to traffic
Site . . . . . . . . . . . . . . . . . . . 3-114 carried . . . . . . . . . . . . . . . . . 3-99
GPRS requests but no data . . . . . . . 3-103 Increased daily call volume . . . . . . . 3-159
High BER imbalance on odd/even Increased daily dropped call rate . . . . 3-159
timeslots . . . . . . . . . . . . . . . . 3-97 Low daily call success rate . . . . . . . 3-10
High bit error rate . . . . . . . . . . . 3-86 Low daily handover attempt rate - power
High daily dropped call rate . . . . . . 3-14 budget . . . . . . . . . . . . . . . . . 3-83
High daily immediate assignment failure Low daily handover success rate to
rate . . . . . . . . . . . . . . . . . . . 3-26 GSM1800 . . . . . . . . . . . . . . . . 3-65
High daily SDCCH RF loss rate . . . . . 3-31 Low daily handover success rate to
High daily second assignment rate . . . 3-19 PGSM900 . . . . . . . . . . . . . . . . 3-65
High downlink block error rate . . . . . 3-129 Low daily immediate assignment success
high DPROC utilization . . . . . . . . . 3-131 rate . . . . . . . . . . . . . . . . . . . 3-29
High estimated RSL utilization . . . . . 3-59 Low daily mean time between han
High frame erasure rate . . . . . . . . 3-88 dovers. . . . . . . . . . . . . . . . . . 3-72
High GPROC utilization . . . . . . . . . 3-49 Low daily uplink TBF setup success
High GPRS timeslot congestion (Uplink/Down rate . . . . . . . . . . . . . . . . . . . 3-123
link) . . . . . . . . . . . . . . . . . . . 3-111 Low handover success rate to
High GPRS utilization by allocation - EGSM900 . . . . . . . . . . . . . . . . 3-65
Downlink . . . . . . . . . . . . . . . . 3-106 Low incoming handover success rate . . 3-68
High GPRS utilization by allocation - Low Inter-BSS handover attempt rate. . 3-70
Uplink. . . . . . . . . . . . . . . . . . 3-106 Low mean time between drop calls . . . 3-21
High GPRS Utilization by Traffic (Uplink/Down Low number of mobile terminated
link) . . . . . . . . . . . . . . . . . . . 3-117 calls . . . . . . . . . . . . . . . . . . . 3-41
High handover attempt rate - Adjacent channel Low outgoing Inter-BSS handover success rate
interference (%) . . . . . . . . . . . . . . . . . . . 3-73
High handover attempt rate - Adjacent Low outgoing Inter-RAT handover success
channel interference . . . . . . . . . 3-79 rate . . . . . . . . . . . . . . . . . . . 3-76
High handover attempt rate - Band Low outgoing Intra-BSS handover success rate
reassign . . . . . . . . . . . . . . . . . 3-79 (%) . . . . . . . . . . . . . . . . . . . 3-73
High handover attempt rate - Congestion Low outgoing Intra-Cell handover success rate
High handover attempt rate - Conges (%) . . . . . . . . . . . . . . . . . . . 3-73
tion . . . . . . . . . . . . . . . . . . 3-79 Low TCH mean holding time . . . . . . 3-23
High handover attempt rate - Distance. . 3-79 No GPRS activity in cell . . . . . . . . . 3-108
High handover attempt rate - Downlink No statistics from BSS . . . . . . . . . 3-136
interference . . . . . . . . . . . . . . . 3-79 No statistics from Cell . . . . . . . . . 3-138
High handover attempt rate - Downlink No statistics from Site . . . . . . . . . 3-140
level. . . . . . . . . . . . . . . . . . . 3-79 One-way MTL . . . . . . . . . . . . . . 3-46
High handover attempt rate - Downlink Paging overflow . . . . . . . . . . . . . 3-55
quality . . . . . . . . . . . . . . . . . 3-79 Path balance issue . . . . . . . . . . . 3-91
High handover attempt rate - Interband Reduced daily call setup success rate . . 3-159
handover . . . . . . . . . . . . . . . . 3-79 Reduced daily call volume . . . . . . . 3-159
High handover attempt rate - Uplink Reduced GPRS capacity. . . . . . . . . 3-127
interference . . . . . . . . . . . . . . . 3-79 Repeated cell failure . . . . . . . . . . 3-147
High handover attempt rate - Uplink Repeated DRI failure . . . . . . . . . . 3-148
level. . . . . . . . . . . . . . . . . . . 3-79 Repeated DRI-61-62-63 alarms . . . . . 3-150
High handover attempt rate - Uplink Timeslots out of service on cell . . . . . 3-42
quality . . . . . . . . . . . . . . . . . 3-79 Very high dropped call rate . . . . . . . 3-14
High immediate assignment blocking . . 3-51 Very high immediate assignment failure
High interference on idle rate. . . . . . 3-95 rate . . . . . . . . . . . . . . . . . . . 3-26
High MTL utilization . . . . . . . . . . 3-57 Very high SDCCH RF loss rate . . . . . 3-31
High PRP load . . . . . . . . . . . . . 3-121 Very high second assignment . . . . . . 3-19
High RF losses imbalance on odd/even Very high TCH blocking . . . . . . . . . 3-53
timeslots . . . . . . . . . . . . . . . . 3-93 Very low call activity . . . . . . . . . . 3-39
Very low call success rate . . . . . . . . 3-10

IX-6 68P02900W36-P
1900.2AS May 2008
Index

Problem list (contd.) Problem pop-up menu (contd.)


Very low handover attempt rate - power neighbor cells . . . . . . . . . . . . . . 2-54
budget . . . . . . . . . . . . . . . . . 3-83 print problem details . . . . . . . . . . 2-58
Very low handover success rate to problem information . . . . . . . . . . 2-32
EGSM900 . . . . . . . . . . . . . . . . 3-65 corrective actions . . . . . . . . . . . 2-35
Very low handover success rate to detector information . . . . . . . . . 2-35
GSM1800 . . . . . . . . . . . . . . . . 3-65 line of reasoning . . . . . . . . . . . 2-35
Very low handover success rate to menu options . . . . . . . . . . . . . 2-33
PGSM900 . . . . . . . . . . . . . . . . 3-65 other device, neighbour, site . . . . . 2-36
Very low immediate assignment success problem causes . . . . . . . . . . . . 2-35
rate . . . . . . . . . . . . . . . . . . . 3-29 remote login . . . . . . . . . . . . . . 2-54
Very low mean time between han statistics history . . . . . . . . . . . . 2-41
dovers. . . . . . . . . . . . . . . . . . 3-72 Problem reducer script . . . . . . . . . . 3-183
Very low outgoing Inter-BSS handover success Problem solving process . . . . . . . . . . 3-2
rate (%) . . . . . . . . . . . . . . . . . 3-73 Problem subscriptions, using . . . . . . . 2-18
Very low outgoing Intra-BSS handover success Problem type and value, filtering . . . . . 2-25
rate (%) . . . . . . . . . . . . . . . . . 3-73 Problem window . . . . . . . . . . . . . . 2-8
Very low outgoing Intra-Cell handover success displaying problems. . . . . . . . . . . 2-10
rate (%) . . . . . . . . . . . . . . . . . 3-73 managing problems . . . . . . . . . . . 2-10
Very low TCH usage. . . . . . . . . . . 3-44 clearing . . . . . . . . . . . . . . . . 2-11
Very low uplink TBF setup success filtering . . . . . . . . . . . . . . . . 2-11
rate . . . . . . . . . . . . . . . . . . . 3-123 sorting . . . . . . . . . . . . . . . . 2-11
Problem lists, managing . . . . . . . . . 2-18 menu options . . . . . . . . . . . . . . 2-13
Problem pop-up menu. . . . . . . . . . . 2-30 problem values . . . . . . . . . . . . . 2-11
action scripts . . . . . . . . . . . . . . 2-55 ranking value . . . . . . . . . . . . . . 2-12
add to blacklist . . . . . . . . . . . . . 2-58 repeating problems . . . . . . . . . . . 2-11
event history . . . . . . . . . . . . . . 2-49 send messages to other users . . . . . . 2-12
export problem details . . . . . . . . . 2-58 using . . . . . . . . . . . . . . . . . . . 2-9
long term statistics . . . . . . . . . . . 2-51 Problems on the OMC . . . . . . . . . . . 4-51

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

SDCCH RF loss rate. . . . . . . . . . . . 3-31 Statistics history (contd.)


Security and permissions . . . . . . . . . . 2-5 viewing for a problem cell. . . . . . . . 2-41
Seen problem status . . . . . . . . . . . 2-37 viewing for a single interval. . . . . . . 2-43
Send problems to OMC as alarms . . . . . 4-51 viewing for a single statistic . . . . . . 2-44
Shutdown the NHA . . . . . . . . . . . . . 4-7 Statistics per problem. . . . . . . . . . . 2-155
Site health check . . . . . . . . . . . . . 2-76 Statistics, enabling required statistics . . 4-65
Sort menu option . . . . . . . . . . . . . 2-15 Stats Per Problem menu option . . . . . . 2-16
Sorting a problem list . . . . . . . . . . . 2-23 Stopping the NHA. . . . . . . . . . . . . . 4-4
Starting the NHA . . . . . . . . . . . 4-4 to 4-5 automatic restarts . . . . . . . . . . . . 4-9
configurable startup options . . . . . . 4-10 from the command line . . . . . . . . . . 4-8
from the command line . . . . . . . . . . 4-5 from the NHA UI . . . . . . . . . . . . . 4-7
restart after shutdown . . . . . . . . . . 4-9 Subscriptions menu option . . . . . . . . 2-16
Starting the NHA user interfaces Subscriptions, configuring . . . . . . . . 2-148
Getting started - an introduction to the creating . . . . . . . . . . . . . . . . . 2-148
NHA . . . . . . . . . . . . . . . . . . . 2-3 deleting . . . . . . . . . . . . . . . . . 2-150
Statistics history . . . . . . . . . . . . . 2-41 modifying . . . . . . . . . . . . . . . . 2-150
configuring statistics . . . . . . . . . . 2-46 verifying . . . . . . . . . . . . . . . . 2-150
different views . . . . . . . . . . . . . 2-42 viewing . . . . . . . . . . . . . . . . . 2-150
exporting data . . . . . . . . . . . . . 2-45 Summary report of problems . . . . . . . 2-63
printing statistics data . . . . . . . . . 2-45 System recovery . . . . . . . . . . . . . 4-108
viewing for a neighbor . . . . . . . . . 2-42

Thresholds calculator script. . . . . . . . 3-185 Time, changing (contd.)


Thresholds menu option. . . . . . . . . . 2-16 synchronizing OMCs . . . . . . . . . . 4-81
Thresholds, modifying. . . . . . . . . . . 2-133 Timeslots out of service in cell . . . . . . 3-42
Time of day monitoring . . . . . . . . . . 4-55 Troubleshooting mounts . . . . . . . . . 4-28
Time, changing Troubleshooting the NHA . . . . . . . . . 4-21
daylight saving time. . . . . . . . . . . 4-81

Unclear menu option . . . . . . . . . . . 2-14 User Profile feature . . . . . . . . . . . . 2-28


Unhandle problems . . . . . . . . . . . . 2-14 User-defined causes. . . . . . . . . . . . 2-151
Uninstalling the NHA from GUI client or GUI adding . . . . . . . . . . . . . . . . . 2-152
server . . . . . . . . . . . . . . . . . . . 4-101 deleting . . . . . . . . . . . . . . . . . 2-154
Uplink TBF Setup Success Rate . . . . . . 3-123 editing . . . . . . . . . . . . . . . . . 2-154
User added statistics, configuring. . . . . 4-49 Using scripts . . . . . . . . . . . . . . . 2-180
User Defined Causes menu option . . . . 2-16 Using the INSM tool . . . . . . . . . . . 2-84
User interface action scripts . . . . . . . 2-209 Using the NHA . . . . . . . . . . . . . . . 2-2

verify_informix script . . . . . . . . . . . 4-32 View the network configuration . . . . . . 2-89


Very low call activity . . . . . . . . . . . 3-39 Viewing an OOS report . . . . . . . . . . 2-90
Very low TCH usage. . . . . . . . . . . . 3-44

IX-8 68P02900W36-P
1900.2AS May 2008
Index

Web access . . . . . . . . . . . . . . . . 4-44 Worst cells . . . . . . . . . . . . . . . . 2-96


Web page . . . . . . . . . . . . . . . . . 2-65 Worst Cells menu option . . . . . . . . . 2-15

68P02900W36-P IX-9
May 2008 1900.2AS
Standard Printing Instructions

Part Number 68P02900W36-P

Manual Title System Information: Network Health Analyst

A4 Ring Bound - GSD (UK)

Binder • 4 D-ring binder - A4 size (210mm x 297mm) white PVC.


• 40mm or 65mm capacity depending on the size of the manual.
• Clear pockets on front and spine.

Printing • Cover / spine text printed in colour.


• Body- printed double sided onto white A4 (210mm x 297mm) 80g
4 hole paper.

Finishing • A4 size (210mm x 297mm) clear PVC sheet front page for
protection.
• Bag wrapped with clear polythene.

If this is to be used by manufacturing as an Inbox document, then refer to appropriate


Materials or Methods Specification.
System Information
Network Health Analyst

Network Health Analyst

System Information

GSR9
1900.2AS

68P02900W36-P
1900.2AS
GSR9
68P02900W36-P

Cutting
datum point

Spine Front cover

You might also like