UM641 Appendix B v03.02

APPENDIX B
APPENDIX B
Wireless Gateway Alarms
"Confidential information -- may not be copied or disclosed without permission".
UM641 03.02 July 2003

B-1
APPENDIX B
"Confidential information -- may not be copied or disclosed without permission".
UM641 03.02 July 2003

B-2
411-8111-500
UMTS
Reference Manual
UMTS 3.0 Standard 02.05 June 2003 411-8111-500_S02.05
What’s inside...
Alarms overview
Alarms
MDM alarm screening macro
test
UMTS
Reference Manual
Document number: 411-8111-500

Product release: UMTS 3.0
Document version: Standard 02.05
Date: June 2003
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright  2002–2003 Nortel Networks, All Rights Reserved

Originated in Canada
NORTEL NETWORKS CONFIDENTIAL
The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees
with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree
of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in
writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
*Nortel Networks, the Nortel Networks logo, the Globemark, How the World Shares Ideas, Unified Networks, Passport, DMS, DMS-
HLR, and MAP are trademarks of Nortel Networks.GSM is a trademark of GSM MOU Association.
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
iv
Nortel Networks Confidential Copyright  2002–2003 Nortel Networks
411-8111-500 Standard 02.05 June 2003

v
Publication history
June 2003
UMTS 3.0, Standard 02.05. Modified alarms: 7068 1016, 7068 1515, 7068
1516, 7068 1517, 7068 1519, 7068 1520 as per Chris Welch’s email (March
26th).
Added alarms 7068 0102, 7068 0103. Modified alarm 7068 1527, 7068 1528
from WG Fault Management LDD Ver1.3.15.
Corrected alarm 7067 0003 to message status.
Added alarms 7068 1531, 7068 1532, 7068 1028, 7068 1029, 7068 1523, 7068
1540 as per WG Fault Management LDD Ver1.3.16 and minor changes is
version 1.3.17
March 2003
UMTS 3.0, Standard 02.04. Updated information from WG Fault Management
LDD Ver1.3.13
Added alarm 7068 1535.
February 2003
UMTS 3.0, Standard 02.03. Updated information from WG Fault Management
LDD Ver1.3.12
Modified 7068 1501, 7068 1521 and many TcapStack alarms.
Removed obsoleted alarms including: 7068 1000, 7068 1004, 7068 1512, 7068
1513, 7068 1514.
Updated the Probable cause and Type for most alarms.
November 2002
UMTS 3.0, Preliminary 02.02. Updated information from WG Fault
Management LDD Ver1.3.10
Modified 7068 1530 DNSAgent Server redundancy alarm with notes.
Re-numbered TDM Link Failure Alarm to 7056 1300.
October 2002
UMTS 3.0, Draft 02.01. Updated information from WG Fault Management
LDD Ver1.3.6
UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

vi Publication history
Added LI alarms. Updated the alarm details for 7067 0002. Added Probable
cause and Type to each alarm. Obsoleted SAS alarms. Replaced 7068 1016
with the new SAS Initialization Failure Alarm. Renamed Primary CGF Link
Failure Alarm to CGF Link Failure. Renamed SAS Disk Full Alarm to SAS
Disk High Usage Alarm. Added MapClient warning message Alarm. Added
second DNSAgent Server Alarm.
September 2002
UMTS 2.0, Standard 01.03. Up-issued document without any new technical
updates available.
April 2002
UMTS 2.0, Preliminary 01.02.
Updated information from WG Fault Management Ver1.2.6.
Updated Framebuilder document template to 3.61.
March 2002
UMTS 2.0, Draft 01.01. This document was created for the UMTS2.0 release.
411-8111-500 Standard 02.05 June 2003

vii
Contents 1
About this document ix

Purpose ix
Audience ix
Organization ix
Software release applicability ix
Related documents x
UMTS Core Network x
Specifications x
Passport x
Preside for Wireless Internet, Solution for GPRS xii
Preside Multiservice Data Manager (MDM) release 12.5 documentation xii
Related training xii
Indication of hypertext links xii
Alarms overview 1-1

Passport alarms 1-1
Alarms specific to the Wireless Gateway 1-2
Conditions that trigger alarms 1-3
Alarms 2-1
7056 1300 - TDM Link Failure Alarm 2-5
7065 0000 - Mapping Table Full Alarm 2-6
7066 0000 - Connections Exhausted Alarm 2-7
7066 0100 - Signalling Link Test Failed Alarm 2-8
7066 0101 - Destination Inaccessible Alarm 2-9
7066 0102 - MTP3 Link Incorrect Mapping Alarm 2-10
7066 0103 - MTP3 Link Incorrect Mapping Alarm 2-11
7066 0300 - Alignment Failure Alarm 2-12
7066 0301 - Layer 2 Peer Disconnect Alarm 2-13
7067 0000 - Media Gateway Heartbeat Alarm 2-14
7067 0001 - MgIf Claim Failure Alarm 2-15
7067 0002 - Tdmc Claim Failure Alarm 2-16
7067 0003 - Q.2630 Blocking Failure Alarm 2-17
7067 0004 - Vmg High Resource Usage Alarm 2-18
7068 1001 - SAS Disk High Usage Alarm 2-19
7068 1002 - SAS Disk Failure Alarm 2-20
7068 1003 - CGF Link Failure Alarm 2-21

viii Contents
7068 1016 - SAS Initialization Failure Alarm 2-22

7068 1028 - Attach Reject Cause Code Report Alarm 2-23
7068 1029 - Sgsn-Initiated Session Deactivations Cause Code Reporting Alarm
2-24
7068 1500 - Context Memory Exhausted Alarm 2-25
7068 1501 - GMM Max Attaches Exceeded Alarm 2-26
7068 1502 - SM Max Active Sessions Exceeded Alarm 2-27
7068 1503 - Context Memory Exhausted Alarm 2-28
7068 1504 - Max Active Sessions Exceeded Alarm 2-29
7068 1505 - TcapStack Out of Subsystem Resources Alarm 2-30
7068 1506 - MapStack Out of SGSN MAP Subsystem Resources Alarm 2-31
7068 1507 - Initialization Failure 2-32
7068 1508 - Initialization Failure 2-33
7068 1509 - TcapStack Out of SGSN MSC Subsystem Resources Alarm 2-34
7068 1510 - TcapStack Out of SGSN CAP Subsystem Resources Alarm 2-35
7068 1511 - Max MAP Client Dialogues Exceeded Alarm 2-36
7068 1515 - SGSN MAP Subsystem Bind Failed Alarm 2-37
7068 1516 - SGSN MSC Subsystem Bind Failed Alarm 2-38
7068 1517 - CAP Subsystem Bind Failed Alarm 2-39
7068 1518 - SSF SCP Communication Failure Alarm 2-40
7068 1519 - SSF Max Camel Dialogues Exceeded Alarm 2-41
7068 1520 - MAP Notice Indication Display Alarm 2-42
7068 1521 - USC CPU Overload Alarm 2-43
7068 1522 - Loss of Communication with DnsAgent Servers 2-44
7068 1523 - Loss of Connection with SIG 2-45
7068 1524 - LIAF Out Of Resources Alarm 2-46
7068 1525 - LIAF Maximum Subscribers Reached Alarm 2-47
7068 1526 - LIAF Initialization Failure Alarm 2-48
7068 1527 - Loss of Communication with Lawful Intercept Gateway
Administration Function (LIGA) Server Alarm 2-49
7068 1528 - Loss of Communication with Lawful Intercept Gateway Delivery
Function (LIGD) Server Alarm 2-50
7068 1529 - Invalid PDP Context Received Alarm 2-51
7068 1530 - Loss of Redundancy with DnsAgent Servers 2-52
7068 1531 - Attach Requests Rejected or not Received Alarm 2-53
7068 1532 - PDP Activations Requests Rejected or not Received Alarm 2-54
7068 1535 - HLR Reset Received Alarm 2-56
7068 1540 - Usc GtpM Keep-Alive Alarm 2-57
MDM alarm screening macro A-1

Starting a trigger A-1
AlarmTrigger options A-1
Example macro A-2
411-8111-500 Standard 02.05 June 2003

ix
About this document

Purpose 0
This Nortel Networks Technical Publication (NTP) describes alarms on the
15000 Passport* platform functioning as a Wireless Gateway.
Audience 0
This publication is intended for persons involved in the administration or
maintenance of the Wireless Gateway system.
It is assumed that the reader has a general familiarity with GPRS networks
and standards, and a similar familiarity with the 15000 Passport platform.
Organization 0
This publication consists of the following chapters:
• Chapter 1, “Alarms overview” describes types of Passport alarms, and
conditions that trigger alarms on the Wireless Gateway.
• Chapter 2, “Alarms” lists all Wireless Gateway alarms in sequential order.
Each alarm description provides details on the condition(s) that generated
the alarm, and the remedial action to be taken.
• Appendix A, “MDM alarm screening macro” describes how to set up an
MDM trigger for improved visibility of selected alarms.
Software release applicability 0

This publication is applicable to the UMTS 3.0 software release. Unless this
publication is revised, it also applies to offices that have software releases
greater than UMTS 3.0.

x About this document
Related documents 0
UMTS Core Network
Refer to the following documents for more information on the UMTS network
entities:
• 411-8111-804:UMTS Terminology
• 411-8111-907:About the UMTS OAM Main and Performance Servers
• 411-8111-903:UMTS Wireless Gateway User Guide
• 411-2231-010:Circuit Core Networks Call Server Product Guide
• 411-2831-010:Circuit Core Networks HLR Product Guide
• 411-5221-926:Shasta GGSN User Guide
• 411-8111-510:About the UMTS Access Network OAM
• 411-8111-512:UMTS Access Network OAM Commands
• 411-8111-503:UMTS Circuit Core Network OAM Overview
• 411-8111-504:UMTS Packet Core Network OAM Module Overview
• 450-3031-338:Preside for UMTS Solution Guide
Specifications
For more information about the UMTS interfaces and protocols referred to in
this document, refer to the UMTS specifications at
http://www.3gpp.org/specs/specs.htm.
Passport
Refer to the following NTPs in the Passport suite (PCR 2.2) for additional
information relative to the Passport platform:
• 241-1501-030, Passport 15000 Overview
• 241-1501-200, Passport 15000 Hardware Description
• 241-1501-205, Passport 15000 Site Requirements and Preparation Guide
• 241-1501-210, Passport 15000 Hardware Installation Guide
• 241-1501-215, Passport 15000 Hardware Maintenance Guide
• 241-5701-001, Passport 7400, 15000 Documentation Guide
• 241-5701-005, Passport 7400, 15000 List of Terms
• 241-5701-035, Passport 15000-VSS (Variable Speed Switch) Overview
• 241-5701-045, Passport 7400, 15000 Management System User Interface
Guide
• 241-5701-050, Passport 7400, 15000 Commands
• 241-5701-053, Passport 7400, 15000 Command Summary Card
411-8111-500 Standard 02.05 June 2003

About this document xi
• 241-5701-060, Passport 7400, 15000 Components

• 241-5701-270, Passport 7400, 15000 Software Installation Guide
• 241-5701-275, Passport 7400, 15000 Commissioning Guide
• 241-5701-500, Passport 6400, 7400, 15000 Alarms
• 241-5701-510, Passport 7400, 15000 Trace Guide
• 241-5701-520, Passport 7400, 15000 Troubleshooting Guide
• 241-5701-600, Passport 7400, 15000 Configuration Guide
• 241-5701-605, Passport 7400, 15000 User Access Guide
• 241-5701-611, Passport 7400, 15000 Data Collection Guide
• 241-5701-615, Passport 7400, 15000 FP Configuration Reference
• 241-5701-700, Passport 7400, 15000 ATM Overview
• 241-5701-702, Passport 7400, 15000 ATM Routing and Signaling
Fundamentals
• 241-5701-705, Passport 7400, 15000 ATM Traffic Management
Fundamentals
• 241-5701-706, Passport 7400, 15000 ATM CQC Traffic Management
Fundamentals
• 241-5701-707, Passport 7400, 15000 ATM IP Traffic Management
Fundamentals
• 241-5701-710, Passport 7400, 15000 ATM Configuration Guide
• 241-5701-715, Passport 7400, 15000 ATM Fault Management Guide
• 241-5701-805, Passport 7400, 15000 Understanding IP
• 241-5701-810, Passport 7400, 15000 Configuring IP
• 241-5701-900, Passport 7400, 15000 Frame Relay UNI Guide
• 241-5701-910, Passport 7400, 15000 Frame Relay NNI Guide
• 241-5701-920, Passport 7400, 15000 Frame Relay to ATM Interworking
Guide
• 241-7401-030, Passport 7400 Overview
• 241-7401-200, Passport 7400 Hardware Description
• 241-7401-210, Passport 7400 Hardware Installation Guide
• 241-7401-215, Passport 7400 Hardware Maintenance Guide

xii About this document
Preside for Wireless Internet, Solution for GPRS

Refer to the following NTPs for information specific to the Preside for Wireless
Internet, Solution for GPRS:
• 450-3101-338, Preside for Wireless Internet, Solution for GPRS 3.0.0
Overview
• 450-3101-638, Preside for Wireless Internet, Solution for GPRS 3.0.0
Engineering Planning Guide
• Preside for Wireless Internet, Solution for GPRS 3.0.0 Operational
Considerations
Preside Multiservice Data Manager (MDM) release 12.5 documentation

Refer to the following NTPs in the Preside MDM suite (release 12.5) for
additional information about Passport OA&M:
• 241-6001-011, Preside MDM Advisor User Guide
• 241-6001-023, Preside MDM Architect for Passport User Guide
• 241-6001-303, Preside MDM Administrator Guide
• 241-6001-309, Preside MDM Management Data Provider User Guide
• 241-6001-801, Preside MDM Overview
• 241-6001-804, Preside MDM Workstation Utilities User Guide
• 241-6001-806, Preside MDM MDP Data Formats Reference Guide
Related training 0
For questions regarding training courses for the Wireless Gateway, please
contact your local Nortel Networks representative for the latest course
identification, availability, and training center location.
Here are the courses that are currently available for the Wireless Gateway:
• UM030 Wireless Gateway Detailed Description
• UM100 Wireless Gateway First Line Maintenance
• UM641 Wireless Gateway Commissioning and Troubleshooting
Indication of hypertext links 0

Hypertext links in this document are indicated in blue. If viewing a PDF
version of this document, click on the blue text to jump to the associated
section or page.
411-8111-500 Standard 02.05 June 2003

1-1
Alarms overview 1
Alarms are the primary indication that there is a problem on the Wireless
Gateway node. This chapter gives a general description of alarms on the
Passport and on the Wireless Gateway.
Passport alarms 1
When a component detects a problem it issues an alarm, which by default
displays on all operator sessions. A component generates an alarm in the
following situations:
• quality of service degradation
• processing error
• hardware failure
• change of administrative OSI state
• security violation
• software error
Note: For information about Wireless Gateway component OSI states,

refer to NTP 411-8111-903, Wireless Gateway User Guide.
There are three types of alarms: SET, CLR, and MSG. A component generates
a SET alarm when it detects a problem and a CLR alarm when the problem
clears. To clear some problems, an action is required by the operator; for
example, replacing a failed piece of hardware. Other problems can clear on
their own; for example, congestion.
A component generates a MSG or SET/CLR alarm when a significant event

occurs about which nothing can be done. A MSG alarm can indicate a
transient problem or an non-repairable problem. A software error is an
example of an non-repairable problem. MSG alarms can be used any place a
set/clear alarm is use, but it isn't as effective, since it only notes the problem.
MSG alarms do not change the state or color of the component on the MDM
viewer.

1-2 Alarms overview
To help identify the cause of a problem, only the component that detects the
problem or is at the source of the problem generates an alarm. Other
components impacted by the problem do not generate alarms. For example, a
logical processor fails, which causes all its ports to fail. The LogicalProcessor
component generates an alarm, but the port components do not generate
alarms because the unavailability of the logical processor causes their failure.
This alarm-generation strategy minimizes the number of alarms and helps the
operator focus on the cause of the problem.
Alarms contain a great deal of information to assist in troubleshooting. Alarm

information includes the OSI state and status values at the time the
component generated the alarm as well as the severity, type, and probable
cause of the alarm. An alarm can also include a comment that contains brief
information about the cause, impact, and recovery of the problem.
For information describing alarms specific to the Passport node, refer to NTP
241-5701-500, Passport 6400, 7400, 15000, 20000 Alarms. This referenced
document contains
• alarm philosophy and potential causes
• reference information on Passport alarms
• how to interpret alarms
Anyone responsible for operating and maintaining an Wireless Gateway

should be familiar with this document.
Alarms specific to the Wireless Gateway 1

The functions within the Wireless Gateway that have alarm surveillance
implemented are:
• USC (Usc component)
• USD (Usd component)
• SGSN Accounting Server (Sas component)
• Map Client (Usc MapClient component)
Alarms that have the potential for repetitive generation for the same root
cause employ a high/low water mark mechanism to ensure the operator does
not receive an alarm “flood”. All Wireless Gateway alarms include the
current Logical Processor (LP) in the Related Components field to ensure that
the LP’s hierarchical clear applies to outstanding alarms in the event of an LP
reset/restart.
411-8111-500 Standard 02.05 June 2003

Alarms overview 1-3
Conditions that trigger alarms

Wireless Gateway faults currently fall into two general categories:
connectivity loss and resource unavailability.
Loss of connectivity
The Wireless Gateway interface in which a loss of connectivity may occur
resulting in a fault condition is between the Wireless Gateway Accounting
Server (SAS) and Charging Gateway Function (CGF). The loss of the
primary and/or secondary link will result in the possible loss of subscriber
billing data.
Loss of resources
The loss of certain critical resources within the Wireless Gateway may also
result in a fault condition. These critical resources may include:
• The SAS hard disk may fill up or fail, resulting in the SAS being unable to
save or send the CGF any collected billing data.
• USC’s pool of available subscriber attaches or active sessions may be
consumed, resulting in the inability to service additional subscribers.
• USD’s pool of available active session contexts may be consumed,
resulting in the inability to service additional sessions.
Threshold conditions
Threshold conditions generate alarms in the form of “message” (MSG) or
SET/CLR alarms. MSG alarms are not displayed in active alarm list of MDM
and instead are put in the log where it can lose its visibility. It is suggested
that an MDM trigger be set up if those MSG alarms require better visibility
(refer to Appendix A, “MDM alarm screening macro”).
Threshold conditions generally generate alarms only if the resource that is

“exhausted” is a single point of failure. In the case of the USC, the exhaustion
of available subscriber attach resources results in the USC being operational
with the currently attached subscribers, but unable to allow attachment of
additional subscribers. When a number of subscriber attach resources are
freed due to detaches, then the USC will return to normal status. Similar
scenarios apply to USC activations and USD active sessions.
Initialization problems
Initialization problems may also result in alarms. In the USC and USD,
exhaustion of available memory resources during initialization results in a
SET alarm being generated. This condition prohibits the components from
operating normally.

1-4 Alarms overview
411-8111-500 Standard 02.05 June 2003

2-1
Alarms 2
This section describes alarms that may be generated by the Wireless
Gateway. Alarms are listed in sequential order by alarm index.
The alarm number is an eight-digit BCD value which consists of two parts.
The first part of the alarm number is the index group. For GPRS and UMTS
Sgsn, the index group has the assigned value of 7068. The second part of the
alarm number is a local file that we use to assign values for individual alarms
in the Sgsn index group. An alarm number, is an entry from the appropriate
range [1000 - 1499, for GPRS SGSN; 1500 - 1999 for UMTS SGSN] Alarms
that are used in both the GPRS SGSN and the UMTS SGSN, can be in either
range.
The alarms generated by Wireless Gateway components are largely caused by

the unavailability of a critical resource or a problem with a communication
link between two Wireless Gateway entities. Alarms which have the potential
for repetitive generation for the same root cause will employ a high/low water
mark mechanism to ensure the operator does not receive an alarm flood. All
Wireless Gateway components that may be locked by the operator will use
the DCS ability to automatically generate an alarm on Administrative state
changes. These components include MgIf, CsDomain, RncIf, Sccp, and Link.
All Wireless Gateway alarms will include the current Logical Processor (LP)
in the Related Components field to ensure the LP’s hierarchical clear will
clear outstanding alarms in the event of an LP reset/restart. The following
alarms may be generated by the Wireless Gateway:
The 8-digit alarm index for all Wireless Gateway alarms begins with 7068.

2-2 Alarms
The following alarms are detailed in this section (in numerical order):
• PSDomain Alarms
— Mapping Table Full Alarm - 7065 0000
• SCCP Alarms
— Connections Exhausted Alarm - 7066 0000
• MTP3 Alarms
— Signalling Link Test Failed Alarm - 7066 0100
— Destination Inaccessible Alarm - 7066 0101
— MTP3 Link Incorrect Mapping Alarm - 7066 0102
— MTP3 Link Buffering Error Alarm - 7066 0103
• MTP2 Alarms
— TDM Link Failure Alarm - 7056 1300
• SAAL-NNI Alarms
— Alignment Failure Alarm - 7066 0300
— Layer 2 Peer Disconnect Alarm - 7066 0301
• MGIF Alarms
— Media Gateway Heartbeat Alarm - 7067 0000
• VSP Partitioning Alarms
— MgIf Claim Failure Alarm - 7067 0001
— Tdmc Claim Failure Alarm - 7067 0002
— Q.2630 Blocking Failure Alarm - 7067 0003
— Vmg High Resource Usage Alarm - 7067 0004
• Billing Alarms
— SAS Disk High Usage Alarm - 7068 1001
— SAS Disk Failure Alarm - 7068 1002
— CGF Link Failure Alarm - 7068 1003
— SAS Initialization Failure Alarm - 7068 1016
• USC Alarms
— Context Memory Exhausted Alarm - 7068 1500
— USC CPU Overload Alarm - 7068 1521
— GMM Max Attaches Exceeded Alarm - 7068 1501
— SM Max Active Sessions Exceeded Alarm - 7068 1502
411-8111-500 Standard 02.05 June 2003

Alarms 2-3
— Initialization Failure - 7068 1507

— SSF SCP Communication Failure Alarm - 7068 1518
— SSF Max Camel Dialogues Exceeded Alarm - 7068 1519
• Usc MapClient Alarms
— Max MAP Client Dialogues Exceeded Alarm - 7068 1511
— Invalid PDP Context Received Alarm - 7068 1529
— Attach Requests Rejected or not Received Alarm - 7068 1531
— PDP Activations Requests Rejected or not Received Alarm - 7068
1532
— Sgsn-Initiated Session Deactivations Cause Code Reporting - 7068
1029
— HLR Reset Received Alarm - 7068 1535
— Attach Reject Cause Code Reporting Alarm - 7068 1028
— Usc GtpM Keep-Alive Alarm 7068 1540
• USD Alarms
— Context Memory Exhausted Alarm - 7068 1503
— Max Active Sessions Exceeded Alarm - 7068 1504
— Initialization Failure - 7068 1508
• TcapStack and TcapStack MapStack alarms
— TcapStack Out of Subsystem Resources Alarm - 7068 1505
— MapStack Out of SGSN MAP Subsystem Resources Alarm
- 7068 1506
— TcapStack Out of SGSN MSC Subsystem Resources Alarm
- 7068 1509
— Max CAP transactions Exceeded Alarm - 7068 1510
— SGSN MAP Subsystem Bind Failed Alarm - 7068 1515
— SGSN MSC Subsystem Bind Failed Alarm - 7068 1516
— CAP Subsystem Bind Failed Alarm - 7068 1517
— MAP Notice Indication Display Alarm - 7068 1520
• DnsAgent Alarms
— Loss of Communication with DnsAgent Servers - 7068 1522
— Loss of Redundancy with DnsAgent Servers - 7068 1530
• Ss7IpIf Alarms

2-4 Alarms
— Loss of Connection with SIG - 7068 1523

• State Change Notifications
Proxy State Change Notifications (SCNs) will be generated for each
Wireless Gateway component that maintains OSI state and has a link to
the LP. The generation of the proxy SCNs will occur in the event of an LP
failure. All Wireless Gateway components that maintain OSI state will
have SCNs automatically generated by DCS in the event of an
Operational state change (i.e. Enabled to Disabled or vice versa).
• Lawful Intercept Access Function Alarms

— LIAF Out Of Resources Alarm - 7068 1524
— LIAF Maximum Subscribers Reached Alarm - 7068 1525
— LIAF Initialization Failure Alarm - 7068 1526
— Loss of Communication with Lawful Intercept Gateway
Administration Function (LIGA) Server Alarm - 7068 1527
— Loss of Communication with Lawful Intercept Gateway Delivery
Function (LIGD) Server Alarm - 7068 1528
411-8111-500 Standard 02.05 June 2003

Alarms 2-5
7056 1300 - TDM Link Failure Alarm
Component Severity Status

Nsta/<x> Vgs Brag/<y> Mtp2 major message
Legend
<x> = Nsta instance identifier
<y> = Brag instance identifier
Details
The TDM link failure alarm is generated by MTP2 when an error occurs on
the TDM link resulting in the link being taken out of service. The link failure
could be due to an error in the provisioning of the link, such as a bad timeslot,
or to a physical connectivity problem.
Probable cause
Call establishment error
Type
Communications
Remedial action
Confirm provisioning is correct for the link. Verify the health of the physical
connectivity of the link.

2-6 Alarms
7065 0000 - Mapping Table Full Alarm

Sg/<x>PsDomain minor message
Legend
<x> = instance identifier of the Signalling Gateway
Details
The Mapping Table Full alarm is generated by Signalling Gateway’s
RANAP-PS when the mapping table storing the context data for ongoing
signalling connections has reached a full threshold. If the mapping table
completely fills up, subsequent connection requests from either SCCP or
GPRS Mobility Management (GMM) are rejected. There are two possible
reasons for this to occur. First, the provisioned mapping table size may be
insufficient for the networkís demand for connections. A second, and less
likely reason, is that stale signalling connections may stay in the mapping
table because of the loss of disconnect requests from either SCCP or GMM.
Probable cause
outOfMemoryCause_c
Type
processingType_c
Remedial action
Verify that the mapping table size is provisioned to an adequate size.
411-8111-500 Standard 02.05 June 2003

Alarms 2-7
7066 0000 - Connections Exhausted Alarm

Sas/<x> major/cleared set/clear
Legend
<x> = instance identifier of the SCCP
Details
When the status is set, all of the provisioned connections are consumed and
are in use. This results in the connections exhausted alarm being generated by
the SCCP because an SCCP user requested a connection but was denied. The
connections are from the local SCCP to the remote SCCP. The connection
request is failed by SCCP and the connection is not established. All future
connection requests will fail until an adequate number of in-use connections
are relinquished.
When the status is clear, a low water mark has been reached for in-use
connections providing an adequate pool of connections available for use.
Probable cause
atOrNearCapacityCause_c
Type
operatorType_c
Remedial action
When the status is set, increase the number of available connections
provisioned in SCCP. Or, determine why an excessive number of connections
are being used and decrease the number of connection requests by SCCP
users.
When the status is clear, no remedial action is necessary.

2-8 Alarms
7066 0100 - Signalling Link Test Failed Alarm

Mtp3/<x> Linkset/<y> Link/<z> major message
Legend
<x> = MTP3 instance identifier
<y> = linkset instance identifier
<z> = link instance identifier; z = 0 - 15
Details
The signalling link test failed alarm is generated by an MTP3 Link when the
Signalling Link Test (SLT) fails indicating the Signalling Link Test
Controller (SLTC) detected a bad link. Once the bad link is detected it will be
restarted.
Probable cause
callEstablishmentErrorCause_c
Type
communicationsType_c
Remedial action
Monitor the bad link to ensure the link comes back into service.
411-8111-500 Standard 02.05 June 2003

Alarms 2-9
7066 0101 - Destination Inaccessible Alarm

Mtp3/<x> Linkset/<y> critical/cleared set/clear
Legend
Details
The Destination Inaccessible Alarm is raised by the Mtp3/ Linkset
component when a destination (i.e. remote MTP3) is inaccessible due to all
links in the linkset being inaccessible. The destination is considered
inaccessible when all links in the linkset are either locked or disabled.
The alarm is cleared when a destination becomes accessible due to one or

more links in the linkset becoming accessible. The destination becomes
accessible when a locked linked becomes unlocked or a disabled link
becomes enabled.
Probable cause
localTransmissionErrorCause_c
Type
Remedial action
When the status is set, links that are locked may be unlocked as appropriate.
For disabled links, they should be monitored to ensure the links come back
into service.

2-10 Alarms
7066 0102 - MTP3 Link Incorrect Mapping Alarm

Mtp3/<x> Linkset/<y> Link/<z> major set
Legend
Details
When the status is set, an MTP3 link has failed because the link has been
mapped incorrectly. The link is incorrectly mapped since it is disabled and
carrying payload traffic.
Probable cause
Type
Remedial action
When the status is set, the MTP3 link is disabled. The mapping for this MTP3
linkset is incorrect. Reset the card to recover this linkset.
411-8111-500 Standard 02.05 June 2003

Alarms 2-11
7066 0103 - MTP3 Link Incorrect Mapping Alarm

Mtp3/<x> Linkset/<y> Link/<z> minor message
Legend
Details
This alarm has been raised since an audit of the MTP3 links has detected a
problem scenario. The audit will detect if an enabled MTP3 link is buffering
payload traffic. The alarm will notify the operator that this condition has been
encountered on an MTP3 link. The link may be marked as failed when the
alarm is generated (Look in the remedial action section for more details). This
will allow the MTP3 link to clean up this error scenario and come up to a
stable state.
Probable cause
Type
Remedial action
The MTP3 link audit is implemented in debug and action mode. In debug
mode, the alarm will be generated to notify the operator that the above
scenario has been detected, no action will be taken to recover this link. In
action mode, the link will be marked as failed, along with the generated
alarm. The audit action mode will be controlled by a toggle bool on the WG
that can be set by the operator. This action will require the operator to turn on
this bool if they wish to recover the MTP3 link whenever the error scenario is
detected.

2-12 Alarms
7066 0300 - Alignment Failure Alarm

SaalNni/<x> major/cleared set/clear
Legend
<instance> = Saal-Nni instance identifier
Details
The Alignment Failure alarm is raised by the SaalNni component when
alignment fails with the peer SaalNni layer.
The alignment fails when the operational attribute SaalNni/

currentProvingPdus is lower than operational attribute SaalNni/
targetProvingPdus. If SaalNni receives less than the expected value then there
is a communication problem which could be due to congestion.
When currentProvingPdus is equal to the targetProvingPdus, then the link is

working properly, since there was no loss of PDUS during the proving
process.
The alarm is cleared when alignment on the link completes successfully as a

result of increased bandwidth or the reduction of traffic.
Probable cause
Type
Remedial action
When the status is set, verify the bandwidth is sufficient to support the link
and increase it if necessary. Verify the health of the physical connectivity
(e.g. optical link or interface).
411-8111-500 Standard 02.05 June 2003

Alarms 2-13
7066 0301 - Layer 2 Peer Disconnect Alarm

SaalNni/<x> major message
Legend
<x> = Saal-Nni instance identifier
Details
The layer 2 peer disconnect alarm is generated by SaalNni when a peer
SaalNni releases the link and disconnects. The disconnect occurs as a result of
the peer SaalNni sending a release indication to the local SaalNni which
ultimately results in the link being taken out of service.
Probable cause
remoteTransmissionErrorCause_c
Type
Remedial action
Determine what incompatibility or engineering change has occurred at the
peer SaalNni to cause it to generate a release indication.

2-14 Alarms
7067 0000 - Media Gateway Heartbeat Alarm

Vmg/<x> MgIf/<y> major/cleared set/clear
Legend
<x> = Virtual Media Gateway instance identifier
<y> = Media Gateway interface identifier
Details
When the status is set, the Virtual Media Gateway has lost the signalling
connection with the Media Gateway indicated by failed heartbeat messages.
As a result no Aspen messaging to or from the Media Gateway will occur.
While the condition persists, the Virtual Media Gateway will discard any
unsendable messages and reject any new calls. Possible causes for the loss of
heartbeat is a Media Gateway Reset or a loss of physical connectivity with the
Media Gateway.
When the status is clear, the component has re-established its connection with
the Media Gateway indicated by the success of heartbeat messages.
Probable cause
lossOfSignalCause_c
Type
Remedial action
When the status is set, verify the Media Gateway is available and connectivity
is correct.
411-8111-500 Standard 02.05 June 2003

Alarms 2-15
7067 0001 - MgIf Claim Failure Alarm

Vmg/<x> MgIf/<y> major/cleared set/clear
Legend
Details
This alarm indicates that an MGIfController instance needs to be provisioned
on the Media Gateway. The alarm will trigger if SG fails to claim a partition
on the MG. That means there are a less partitions provisioned on the MG than
the number of SGs trying to claim them. MG will accept a partition claim
from SG if it has a free partition. If there is no free partition available it will
Nack the claim message from SG, and SG will generate Mgif Claim Failure
Alarm. When the status is clear, the component has re-established its
connection with the Media Gateway indicated by the success of heartbeat
messages.
Probable cause
operationalConditionCause_c
Type
operatorType_c
Remedial action
The corresponding Media Gateway MGIfController instance has to be
provisioned.

2-16 Alarms
7067 0002 - Tdmc Claim Failure Alarm

Vmg/<x> MgIf/<y> TdmRes/<z> major/cleared set/clear
Legend
<z> = TDM Resource instance number
Details
The TDM resource component will try to acquire the TDM Resource (E1) by
sending a claim message to the MediaGateway.This alarm indicates this
Mediagateway Interface (MgIf) on Signalling Gateway failed to claim the
TdmResource (E1) on the Media Gateway. This could happen if this E1 or
one or more timeslots on this E1 are not provisioned or have been claimed by
other MgIf's. The alarm will be "set" when the problem is detected and it will
be "cleared" when the remedial action is taken on the Media Gateway.
Probable cause
Type
operatorType_c
Remedial action
When this alarm comes out, the customer shall check corresponding Media
Gateway (VSP card) by displaying Nsta Vgs AmrBrag or Nsta Vgs CsdBrag
component to find out which time slots on this E1 have been claimed or not
provisioned. The timeslots of the TDMResource have to be reprovisioned.
411-8111-500 Standard 02.05 June 2003

Alarms 2-17
7067 0003 - Q.2630 Blocking Failure Alarm

Vmg/<x> major/cleared message
Legend
Details
This alarm is “set” and shows “Block was sent, and no Block Confirm was
received.” upon the Block timer expricy after the Q.2630 Block is sent to the
RNC.
This alarm is “set” and shows “Unlock was sent, and no Unblock Confirm
was recieved.” upon the Unblock timer expricy after the Q.2630 Block is sent
to the RNC.
The alarm is cleared after the information is displayed.
Probable cause
Type
Remedial action
This is an information alarm. No remedial action is expected.

2-18 Alarms
7067 0004 - Vmg High Resource Usage Alarm

Vmg/<x> major message
Legend
Details
This alarm indicates that the DS0 resource usage has exceeded the provsioned
Threshold. The alarm will trigger if the total DS0 in used, this include actual
call connections, blocked channels or out of service channels, has exceeded
the threshold percentage set by the provisionable attribute. i.e if there is 100
DS0s provisioned and the alarm threshold is set to 75%, then when more than
75 DS0s has been used either by call connection, blocked or Out of Service,
the alarm will trigger.
Vice versa, the alarm will clear when the usage percentage has dropped below
the provisionable clear threshold.
Probable cause
thresholdCrossedCause_c
Type
qualityOfServiceType_c
Remedial action
Provision additional TDM.
Unlock resources.
Clear “Out of Service” resources.
411-8111-500 Standard 02.05 June 2003

Alarms 2-19
7068 1001 - SAS Disk High Usage Alarm

Sas/<x> minor/major/critical/clear set/clear
Legend
<x> = instance identifier of the SGSN Accounting Server (SAS)
Details
The SAS disk high usage alarm is generated by the SAS when disk usage
thresholds are crossed on the SAS’s hard disk. This indicates that there is a
danger of rendering the SAS inoperable if the disk runs out of space. Since
the disk will fill up if the SAS is unable to offload collected charging
information to the CGF, the likely cause is a problem with the network path to
the CGF or the CGF itself. The severity of disk high usage alarm is raised to a
higher level as the disk fills up.
Minor -- when the disk usage reached 85% full.
Major -- when the disk usage reached 90% full.
Critical -- when the disk usage reached ~100% full.
Clear -- when the disk usage below 75% full.
Probable cause
Type
Remedial action
Verify the health of the network path to the CGF. Verify the CGF is
functioning properly.

2-20 Alarms
7068 1002 - SAS Disk Failure Alarm

Sas/<x> critical/clearedset/clear
Legend
Details
The SAS disk failure alarm is generated by the SAS when a hard disk failure
(such as a crash) is detected, rendering the hard disk inaccessible. As a result,
the SAS will be unable to save collected charging information or to send the
Charging Gateway Functionality (CGF) any collected charging information
already saved to disk.
Probable cause
equipmentFailureCause_c
Type
equipmentType_c
Remedial action
Replace the disk drive or the entire FP card.
411-8111-500 Standard 02.05 June 2003

Alarms 2-21
7068 1003 - CGF Link Failure Alarm

Sas/<x> critical/minor/clear set/clear
Legend
Details
The CGF link failure alarm is generated by the SAS when a loss of
communication is detected with the either primary, secondary, or both
Charging Gateway Functionality (CGF). The communication link problem is
detected by the SAS when a GTP protocol message is not ack’d by the CGF
or if the CGF fails to respond to a heartbeat message from the SAS. When a
communication problem is detected with primary CGF, the SAS will start
sending collected charging information to the secondary CGF if it is
available. When a communication problem is detected with the secondary
CGF, the SAS will start sending collected charging information to the
primary CGF if it is available. The alarm severity is determined as followed:
Minor -- when two CGFs are provisioned, and one of the CGF is unreachable.
Critical -- When both CGFs are provisioned and unreachable, or when only
one CGF is provisioned and it went down.
Clear -- When both CGFs are provisioned and the CGFs are reachable again,
or when only one CGF is provisioned and it became reachable.
Probable cause
underlyingResourceUnavailableCause_c
Type
Remedial action
Verify the health of the network path to the CGF. Verify the primary CGF is

2-22 Alarms
7068 1016 - SAS Initialization Failure Alarm

Sas/<x> critical/clear set
Legend
Details
The SAS initialization failure alarm is generated by the SAS when SAS
initialization failed and the SAS application is not ready. This in turn may
lead to a card reset.
Probable cause
configurationErrorCause_c
Type
processingType_c
Remedial action
The alarm is cleared by SAS after the shelf or card is reset.
411-8111-500 Standard 02.05 June 2003

Alarms 2-23
7068 1028 - Attach Reject Cause Code Report Alarm

Usc/<x>Gmm warning message
Legend
<x> = instance identifier of the Usc.
Details
This alarm is raised by the Gmm component for each DCS cycle when alarm
generation is enabled, and the number of attach requests rejected due to
packet network failure is greater than zero. The message text lists the reject
counts for packet network and SGSN congestion causes.
Packet Network failure counts:

• noPrimCtxt
• canNotAllocateTempCtxt
• genFailureFromLlc
• canNotAllocateHlrcCtxt
• assignReqFailure
• msResetProcFailure
• deactReqFailure
• iovReqFailure
• mapClientFailure
SGSN Congestion failure counts:

• maxSubsReached
• mapResourceError
• tlliCollision
• actConfirmFailure
Probable cause
Type
Remedial action
Verify the health of the network based on the counters listed. This alarm is
informational in nature.

2-24 Alarms
7068 1029 - Sgsn-Initiated Session Deactivations

Cause Code Reporting Alarm

Usc/<x> Sm warning message
Legend
Details
This alarm is raised by the Sm component for each DCS cycle when alarm
generation is enabled, and the number of SGSN-initiated session deactivations
is greater than zero.
The message text lists the deactivation cause counts:
usdFailure
cancelLoc
duplActReq
statusFromSndcp
trafficVolQuery
Probable cause
Type
Remedial action
Verify the health of the network based on the counters listed. This alarm is
informational in nature.
411-8111-500 Standard 02.05 June 2003

Alarms 2-25
7068 1500 - Context Memory Exhausted Alarm

Usc/<x> major/clear set/clear
Legend
<x> = instance identifier of the USC.
Details
When the status is set, the context memory exhausted alarm is generated by
the USC caused by the Context Manager being unable to acquire any more
memory from the Pool Manager.
When the status is clear, sufficient memory resources have been freed, and
the USC has available Pool Manager capacity.
Probable cause
outOfMemoryCause_c
Type
processingType_c
Remedial action
When the status is set, verify the USCís provisioned attributes for the
maximum number of attached subscribers and maximum number of active
sessions, since the amount of memory allocated is derived from these
provisioned attributes.

2-26 Alarms
7068 1501 - GMM Max Attaches Exceeded Alarm

Usc/<x> minor/major/critical/clearedset/clear
Legend
Details
When the status is set with a severity level of minor, means that the number of
attached subscribers on the USC has reached the minor water mark for USC
attached subscribers.
When the status is set with a severity level of major, means that the number of
attached subscribers on the USC has reached the major water mark for USC
attached subscribers.
When the status is set with a severity level of critical, means that the number
of attached subscribers on the USC has reached its limit on the number of
allowable attached subscribers. In this situation future subscriber attaches are
rejected.
When the status is clear, a low water mark has been reached for current
number of subscribers and the USC has available capacity.
The default exit/entry thresholds for each level are:

• Minor: exit(88%) entry(90)
• Major: exit(93%) entry(95%)
• Critical: exit(98%) entry(100%)
These thresholds can be changed by Nortel support personnel upon request.
Probable cause
Type
processingType_c
Remedial action
When the status is set with critical severity, verify the provisioned attribute
for the maximum number of attached subscribers is sufficient to handle the
level of subscriber demand and increase the maximum if necessary (assumed
that increase is possible).
411-8111-500 Standard 02.05 June 2003

Alarms 2-27
7068 1502 - SM Max Active Sessions Exceeded Alarm

Usc/<x> major set/clear
Legend
Details
When the status is set, the max active sessions exceeded alarm is generated by
the USC caused by the Session Management (SM) function receiving a
session activation request when the USC has reached its limit on the number
of allowable active sessions.
number of active sessions and the USC has available capacity.
Probable cause
Type
processingType_c
Remedial action
When the status is set, verify the provisioned attribute for the maximum
number of active sessions is sufficient to handle the level of demand and
increase the maximum if necessary.
When the status is clear, no remedial action is necessary

2-28 Alarms
7068 1503 - Context Memory Exhausted Alarm

Usd/<x> major set/clear
Legend
<x> = instance identifier of the USD.
Details
When the status is set, the context memory exhausted alarm is generated by
the USD caused by the Context Manager being unable to acquire any more
memory from the Pool Manager.
When the status is clear, sufficient memory resources have been freed, and
the USD has available Pool Manager capacity.
Probable cause
outOfMemoryCause_c
Type
processingType_c
Remedial action
When the status is set, verify the USD’s provisioned attribute for the
maximum number of active sessions, since the amount of memory allocated
is derived from this provisioned attribute.
411-8111-500 Standard 02.05 June 2003

Alarms 2-29
7068 1504 - Max Active Sessions Exceeded Alarm

Usd/<x> major set/clr
Legend
Details
When the status is set, the max active sessions exceeded alarm is generated by
the USD because it received a session activation request when the USD has
reached its limit on the number of allowable active sessions.
number of active sessions and the USD has available capacity.
Probable cause
Type
processingType_c
Remedial action
When the status is set, verify the provisioned attribute for the maximum
number of active sessions is sufficient to handle the level of demand and
increase the maximum if necessary.

2-30 Alarms
7068 1505 - TcapStack Out of Subsystem Resources

Alarm

TcapStack/<x> critical/minor set/clear
Legend
<x> = instance identifier of the TcapStack component
Details
The TcapStack Out of Subsystem Resources alarm is raised by the TcapStack
component when the sum of TCAP transactions allocated for all of the SGSN
subsystems exceeds 95% of the sum of the values of the provisionable
attribute maxTransactionsBySubsystem for each subsystem that is under this
TcapStack component.
TCAP transactions for these subsystems will continue to be allowed until the
number of concurrent TCAP transactions for each subsystem reaches the
value of the maxTransactionsBySubsystem attribute for each subsystem.
Once reached, no new TCAP transactions for that subsystem will be allowed
on this TcapStack component until at least one TCAP transaction for that
subsystem has been relinquished.
This alarm is cleared when the sum of concurrent TCAP transactions for all
subsystems falls below 90% of the sum of the values of the
maxTransactionsBySubsystem attribute for each subsystem.
The MapStack Out of SGSN MAP Subsystem Resources Alarm (alarm index
7068 1506), TcapStack Out of SGSN MSC Subsystem Resources Alarm
(alarm index 7068 1509) and TcapStack Out of SGSN CAP Subsystem
Resources Alarm (alarm index 7068 1510) raise out of resources alarms for
the individual subsystems.
Probable cause
atOrNearCapacityCause_c (set)
outOfMemoryCause_c (clear)
Type
qualityOfServiceType_c (set)
processingType_c (clear)
Remedial action
Verify that the maxTransactionsBySubsystem provisionable attribute under
this TcapStack component is provisioned to an adequate size.
411-8111-500 Standard 02.05 June 2003

Alarms 2-31
7068 1506 - MapStack Out of SGSN MAP Subsystem

Resources Alarm

TcapStack/<x> MapStack critical/minor set/clear
Legend
<x> = instance number
Details
The MapStack Out of SGSN MAP Subsystem Resources alarm is raised by
the MapStack component when the number of TCAP transactions allocated
for the SGSN MAP subsystem exceeds 95% of the value of the provisionable
attribute maxTransactionsBySubsystem that is under this TcapStack
component.
TCAP transactions for this subsystem will continue to be allowed until the
number of concurrent TCAP transactions for this subsystem reaches the value
of the maxTransactionsBySubsystem attribute. Once reached, no new TCAP
transactions for this subsystem will be allowed on this TcapStack component
until at least one TCAP transaction for this subsystem has been relinquished.
This alarm is cleared when the number of concurrent TCAP transactions for
this subsystem falls below 90% of the value of the
maxTransactionsBySubsystem attribute.
Probable cause
Type
Remedial action
If more than one MapStack component is being used, verify that MAP Clients
are evenly distributed across the available MapStack applications. Some of
the alarming MapStack’s MAP Clients may need to be re-distributed to a
different MapStack components.

2-32 Alarms
7068 1507 - Initialization Failure

Usc/<x> major set
Legend
Details
The USC or one of its subcomponents failed to initialize or provision
properly resulting in the Uscís inability to operate correctly.
Probable cause
Type
processingType_c
Remedial action
Reinitialize the Usc by resetting the card or replace the FP.
411-8111-500 Standard 02.05 June 2003

Alarms 2-33
7068 1508 - Initialization Failure

Usd/<x> major set
Legend
Details
The USD or one of its subcomponents failed to initialize or provision
properly resulting in the Usdís inability to operate correctly.
Probable cause
Type
processingType_c
Remedial action
Reinitialize the Usd by resetting the card or replace the FP.

2-34 Alarms
7068 1509 - TcapStack Out of SGSN MSC Subsystem

Resources Alarm

Legend
<x> = instance identifier of the TCAP Stack
Details
The TcapStack Out of SGSN MSC Subsystem Resources alarm is raised by
the TcapStack component when the number of TCAP transactions allocated
for the SGSN MSC subsystem exceeds 95% of the value of the provisionable
component.
This alarm may only be raised if the provisionable attribute

mscEmulationMode under the Sgsn Gsc component is set to ‘on’.
TCAP transactions for this subsystem will continue to be allowed until the
Probable cause
Type
Remedial action
411-8111-500 Standard 02.05 June 2003

Alarms 2-35
7068 1510 - TcapStack Out of SGSN CAP Subsystem

Resources Alarm

Legend
Details
The TcapStack Out of SGSN MSC Subsystem Resources alarm is raised by
the TcapStack component when the number of TCAP transactions allocated
for the SGSN CAP subsystem exceeds 95% of the value of the provisionable
component.
TCAP transactions will continue to be allowed for this subsystem until the
Probable cause
Type
Remedial action

2-36 Alarms
7068 1511 - Max MAP Client Dialogues Exceeded

Alarm

USC/<x>, MapClient critical/cleared set/clear
Legend
<x> = instance identifier of the USC
Details
When the internal alarm is set, the number of map dialogues reaches the high
water mark of the static maximum number of dialogues allowed. Additional
map dialogues may be established until the maximum limit is reached at
which time the MapClient will start failing requests from the MapClient or
MapStack until in-use dialogues are relinquished.
When the alarm is clear, a low water mark has been reached for in-use MAP
dialogues providing an adequate pool of dialogues available for use.
Probable cause
Type
Remedial action
When the internal alarm is set, verify whether MapClient has enough memory
allocated to handle the traffic, if yes, it could add another USC card to
alleviate the bottleneck.
411-8111-500 Standard 02.05 June 2003

Alarms 2-37
7068 1515 - SGSN MAP Subsystem Bind Failed Alarm

TcapStack/<x> MapStack minor/minor set/clear
Legend
Details
The SGSN MAP Subsystem Bind Failed alarm is raised on the MapStack
component when the MapStack is unable to bind to the SGSN MAP
subsystem.
Once this alarm is raised, the SGSN MAP subsystem cannot be used and any
MapClient trying to register with this SGSN MAP subsystem will receive
registration failures.
Probable cause
outOfMemoryCause_c
Type
processingType_c
Remedial action
Verify that the provisionable attribute maxTransactionsBySubsystem for the
SGSN MAP under the TcapStack component is set to a value greater than
zero.
If the SGSN MAP subsystem is not needed, the alarm may be manually
cleared and the MapStack will continue to work for any MapClient that
registers with the SGSN MSC subsystem.
If the SGSN MAP subsystem is needed, the FP this MapStack is provisioned

upon should be reset.

2-38 Alarms
7068 1516 - SGSN MSC Subsystem Bind Failed Alarm

TcapStack/<x> minor/minor set/clear
Legend
Details
The SGSN MSC Subsystem Bind Failed alarm is raised on the TcapStack
component when the MapStack is unable to bind to the SGSN MSC
subsystem.
Once this alarm is raised, the SGSN MSC subsystem cannot be used and any
MapClient trying to register with this SGSN MSC subsystem will receive
registration failures.
Probable cause
outOfMemoryCause_c
Type
processingType_c
Remedial action
SGSN MSC under this TcapStack component is set to a value greater than
zero.
If the SGSN MSC subsystem is not needed, the alarm may be manually
registers with the SGSN MAP subsystem.
If the SGSN MSC subsystem is needed, the FP this MapStack is provisioned

411-8111-500 Standard 02.05 June 2003

Alarms 2-39
7068 1517 - CAP Subsystem Bind Failed Alarm

TcapStack/<x> major/minor set/clear
Legend
Details
The SGSN CAP Subsystem Bind Failed alarm is raised on this TcapStack
component when the MapStack is unable to bind to the SGSN CAP
subsystem.
Once this alarm is raised, the SGSN CAP subsystem cannot be used and any
Service Switching Function (SSF) trying to register with this SGSN CAP
subsystem will receive registration failures.
Probable cause
outOfMemoryCause_c
Type
processingType_c
Remedial action
SGSN CAP under the TcapStack component is set to a value greater than
zero.
If the SGSN CAP subsystem is not needed, the alarm may be manually
registers with the SGSN MAP subsystem or the SGSN CAP subsystem.
If the SGSN CAP subsystem is needed, the FP this MapStack is provisioned


2-40 Alarms
7068 1518 - SSF SCP Communication Failure Alarm

Usc/<x> major message
Legend
Details
The SCP communication failure alarm is generated by the USC SSF when the
USC SSF is no longer able to communicate with the specified SCP. The
communication failure is detected by the USC SSF because a cap dialogue
with the SCP timed out during each of the provisioned retries. If this
communication link is lost, it could indicate a temporary or permanent link
failure between the SGSN and the SCP or indicate that the SCP is down.
Probable cause
Type
communicationType_c
Remedial action
Verify the health of the network path to the SCP. Verify the SCP is
411-8111-500 Standard 02.05 June 2003

Alarms 2-41
7068 1519 - SSF Max Camel Dialogues Exceeded

Alarm

Usc/<x> major/major set/clear
Legend
Details
When the status is set, all of the provisioned camel dialogues are consumed
and are in use. This results in the max camel dialogues exceeded alarm being
generated by the USC SSF because a SCP requested a camel dialogue but was
denied. No new camel dialogues will be established by the USC SSF once the
maximum number of concurrent dialogues is exceeded. All future attempts to
establish a camel dialogue will fail until in-use dialogues are relinquished.
When the status is clear, a low water mark has been reached for in-use camel
dialogues providing an adequate pool of dialogues available for use.
Probable cause
Type
Remedial action
When the status is set, verify that the maximum number of dialogues is
provisioned to an adequate size. If more than one USC is being used, verify
that SCPs are evenly distributed across the available USCs.

2-42 Alarms
7068 1520 - MAP Notice Indication Display Alarm

TcapStack/<x> minor message
Legend
<x> = instance identifier of the TCAP Stack.
Details
The MAP Notice Indication Display alarm is raised to display the following
MAP message counters destined for the SS7 Network Entity:
• AFR-- noTranslationSpecific, otherReturnCause
• ISD -- noTranslationSpecific, otherReturnCause
• MOFSM -- noTranslationSpecific, otherReturnCause
• MTFSM -- noTranslationSpecific, otherReturnCause
• RFSM -- noTranslationSpecific, otherReturnCause
• SAI -- noTranslationSpecific, otherReturnCause
• UGL -- noTranslationSpecific, otherReturnCause
This alarm is displayed every 60 minutes.
There are two counter values displayed for each MAP message. The
noTranslationSpecific counter displays how many times an SCCP Notice
Indication with Return Cause = “No Translation Specific” is received, and the
otherReturnCause displays the number of times any other SCCP Notice
Indication Return Cause value is received for a particular message.
Once the alarm has been raised, the counters for these values are reset to zero.
Probable cause
debuggingCause_c
Type
debugType_c
Remedial action
When any of the message counter values is not equal to zero, this means that
there was a failure to route the message destined for the SS7 Network Entity.
Verify that all routing tables are provisioned correctly on both the SIG and
the SS7 Network Entity and ensure that an active connection exists between
the SIG and the SS7 Network Entity. If message counter values are equal to
zero, no remedial action is necessary.
411-8111-500 Standard 02.05 June 2003

Alarms 2-43
7068 1521 - USC CPU Overload Alarm

Usc/<x> minor/major/critical set/clear
Legend
Details
When the status is set with a severity level of minor, means that the CPU
usage on the USC has reached the minor water mark for USC CPU overload.
When the status is set with a severity level of major, means that the CPU
usage on the USC has reached the major water mark for USC CPU overload.
When the status is set with a severity level of critical, means that the CPU
usage on the USC has reached the critical water mark for USC CPU overload.
In this situation if USC CPU overload discard functionality is enabled may
mean that new subscriber attach requests are rejected.
When the status is clear, a low water mark has been reached for USC CPU
overload meaning that the USC is not considered to be CPU overloaded.
The default exit/entry thresholds for each level are:

• Minor: exit(78%) entry(80%)
• Major: exit(83%) entry(85%)
• Critical: exit(88%) entry(90%)
These thresholds can be changed by Nortel support personnel upon request.
Probable cause
Type
processingType_c
Remedial action
When the status is set with critical severity, verify that there are enough USC
cards present to satisfy the level of subscriber activity. In addition verify that
the critical USC CPU overload water mark is set correctly.

2-44 Alarms
7068 1522 - Loss of Communication with DnsAgent

Servers

dnsAg/<x>,<y> major, critical, cleared set/clear
Legend
<x> = instance identifier of the VR
<y> = instance identifier of the dnsAgent
Details
The alarm is generated by the dnsAgent when dnsAgent can not communicate
with any Name Servers caused by the following condition:
1. ICMP network errors:

— Bad Net
— Host is unreachable
— Protocol error
— Port is unreachable
— Fragmentation is needed
— Source Failed
2. IP Server is unavailable
3. Name Severs’ failure
If DnsAgent does not support static query, the severity is set to Critical,
otherwise, the severity is set to Major.
Note: The alarm will only change status when dns Agent queries the
server.
Probable cause
lossOfSignalCause_c
Type
Remedial action
Verify the IP Server, Network and Name Server availability.
411-8111-500 Standard 02.05 June 2003

Alarms 2-45
7068 1523 - Loss of Connection with SIG

Tcap/<x> Ss7ipif/<y>
Usc/<n> Bssap Ss7ipif/<m> critical/cleared set/clear
Legend
<x> = instance identifier of the tcap
<y> = instance identifier of the ss7IpIf
<n> = instance identifier of the Usc
<m> = instance identifier of the ss7IpIf
Details
The Loss of Connection with the SIG alarm is raised by the Ss7IpIf
component when the SGSN loses TCP connection with the SIG.
The alarm is cleared when the TCP connection between Ss7IpIf component
and the SIG is restored.
Probable cause
lossOfSignalCause_c
Type
Remedial action
Verify the connection of Usc component or Tcap component with SIG.

2-46 Alarms
7068 1524 - LIAF Out Of Resources Alarm

Liaf/<x> major/cleared set/clear
Legend
<x> = instance identifier of the Liaf component.
Details
The LIAF out of Resources alarm is raised by the Liaf component when it fail
to initialize because it is unable to acquire memory resources.
The alarm is clear when the card is reset.
Probable cause
outOfMemeoryCause_c
Type
ProcessingType_c
Remedial action
Verify that the components that share this FP card with the Liaf component
are provisioned within their engineering limits, and then reset the card.
411-8111-500 Standard 02.05 June 2003

Alarms 2-47
7068 1525 - LIAF Maximum Subscribers Reached

Alarm

Liaf/<x> major/cleared set/clear
Legend
<x> = instance identifier of the Liaf.
Details
The LIAF Maximum Subscribers Reached alarm is raised by the Liaf
component when the number of subscribers to intercept reaches the limit
specified by the provisionable attribute nsInterceptions under the Liaf
component.
The alarm is cleared when the number of subscribers to intercept falls below
the limit.
Probable cause
Type
Remedial action
Verify the provisionable attribute nsInterceptions is sufficient to handle the
level of subscriber interception demands and increase the maximum if
necessary.

2-48 Alarms
7068 1526 - LIAF Initialization Failure Alarm

Liaf/<x> major set/clear
Legend
<x> = instance identifier of the LIAF.
Details
The LIAF Initialization Failure alarm is raised by the Liaf component when
the Liaf application fails to initialize properly.
The alarm is cleared when the card is reset.
Probable cause
Type
ProcessingType_c
Remedial action
Verify that the components that share this FP card with the Liaf component
are provisioned within their engineering limits, and then reset the card.
411-8111-500 Standard 02.05 June 2003

Alarms 2-49
7068 1527 - Loss of Communication with Lawful

Intercept Gateway Administration Function (LIGA)
Server Alarm

Liaf/<x> major set/clear
Legend
<x> = instance identifier of the Liaf component.
Details
The Loss of Communication with LIG ADMF alarm is raised by the Liaf
component when its TCP connection is lost, and it can not communicate with
the provisioned Lawful Intercept Gateway (LIG) Administrative Function
(ADMF) network device.
This results in the loss of a target’s interception provisioning information

being retrieved from the LIG ADMF.
The alarm is cleared when the TCP connection is restored.
If this communication link is lost, it could mean a temporary or permanent

link failure between the SGSN and LIGA or indicate that the LIGA is down.
If the communication loss is due to a permanent failure of the link (e.g.
Ethernet cable cut or disconnected) then it may take up to 18 minutes to
generate the alarm from the time of the failure.
Probable cause
lossOfSignalCause_c
Type
Remedial action
Verify that the IP address and IP port number specified by the provisionable
attributes admfAddr and admfPortIP respectively under this Liaf component
are set correctly.
Verify the supporting network’s physical connection, and the availability of

the LIG ADMF network device.

2-50 Alarms
7068 1528 - Loss of Communication with Lawful

Intercept Gateway Delivery Function (LIGD) Server
Alarm

Liaf/<x> major message
Legend
<x> = instance identifier of the Liaf.
Details
The Loss of Communication with the LIG DF alarm is raised by the LIAF
component when the Lawful Intercept Access Function (LIAF) process can
not communicate with the Lawful Intercept Gateway (LIG) Delivery
Function (DF) network device.
The LIAF process delivers intercepted data to a LIG DF network device.
There may be multiple, simultaneous LIG DF connections and an alarm is

generated for each connection failure. This connection failure results in the
loss of intercepted target data destined for the LIG DF.
If this communication link is lost, it could mean a temporary or permanent

link failure between the SGSN and LIGD or indicate that the LIGD is down.
If the communication loss is due to a permanent failure of the link (e.g.
Ethernet cable cut or disconnected) then it may take up to 18 minutes to
generate the alarm from the time of the failure.
Probable cause
lossOfSignalCause_c
Type
Remedial action
Verify the IP Server, the supporting network’s physical connection and the
LIG DF network device are functioning properly.
411-8111-500 Standard 02.05 June 2003

Alarms 2-51
7068 1529 - Invalid PDP Context Received Alarm

USC/<x>, MapClient warning message
Legend
Details
The alarm is generated by the MapClient when the Mapclient receives the
invalid PDP contexts from HLR and try to insert the PDP contexts into
HLRC.
Probable cause
Type
operatorType_c
Remedial action
none

2-52 Alarms
7068 1530 - Loss of Redundancy with DnsAgent

Servers

dnsAg/<x>,<y> minor/cleared set/clear
Legend
<x> = instance identifier of the VR
<y> = instance identifier of the dnsAgent
Details
The Loss of Redundancy with the DnsAgent Servers alarm is raised by the
DnsAg component when there is more than one Name Server provisioned and
the DNS Agent application can only communicate with one of the Name
Servers.
The following are possible causes of this condition:

• ICMP network errors:
— Bad Net
— Host is unreachable
— Protocol error
— Port is unreachable
— Fragmentation is needed
— Source Failed
• IP Server is unavailable
• Name Server failure
The alarm is cleared when the DNS Agent application is able to communicate
with all of the provisioned Name Servers.
Note: The alarm will only clear when dns Agent queries the server.
Probable cause
lossOfSignalCause_c
Type
Remedial action
Verify the IP Server, Networks or Servers availability.
411-8111-500 Standard 02.05 June 2003

Alarms 2-53
7068 1531 - Attach Requests Rejected or not

Received Alarm

Usc/<x> Gmm Critical/ Major/Minor/Cleared message
Legend
<x> = instance identifier of the Usc
Details
This alarm is raised by the Gmm component at the end of the collection interval
when the number of Attach Request rejections exceeds the thresholds
mentioned below or when the total number of Attach Request messages
received is zero. The successful attaches percentage is recalculated each
collection period.
A Major alarm is raised when the number of Attach Request rejections
reaches 10% or more of the total number of Attach Request messages
received.
A Minor alarm is raised when the number of Attach Request rejections
reaches 5% or more of the total number of Attach Request messages
received.
A Critical alarm is raised when the number of Attach Request messages
received is zero.
The successful attaches percentage is calculated using the following formula:

% Successful Attaches = (attachesSuccessful /(attachesSuccessful +
attachRejPacketNetworkFailure + attachRejSgsnCongestion) ) * 100
These values correspond to the indicated collected statistics for the DCS
interval just concluded.
The alarm is cleared when the number of Attach Request rejections is below
5% of the total number of Attach Request and the total number of Attach
Request messages received is greater than zero.
Probable cause
Type
Remedial action
Examine the GMM attach failure counters (for UMTS03 and later, include the
counters reported in alarm 70681028). Verify the health of the network.

2-54 Alarms
7068 1532 - PDP Activations Requests Rejected or

not Received Alarm

USC/<x> Sm Critical/ Major/Minor/Clearedmessage
Legend
Details
This alarm is raised by the Sm component at the end of the collection interval
when the number of PDP Activation rejections exceeds the thresholds
mentioned below or when the total number of PDP Activation Request
messages received is zero. The success activation percentage is recalculated
each collection period.
The alarm is cleared at the end of the collection interval when the total number
of PDP Activation Request messages is more than zero.
A Major alarm is raised when the number of PDP Activation rejections
reaches 10% or more of the total number of PDP Activation request messages
received.
A Minor alarm is raised when the number of PDP Activation rejections

reaches 5% or more of the total number of PDP Activation request messages
received.
A Critical alarm is raised when the total number of PDP Activation Request
messages received is zero.
The successful activation percentage is calculated using the following formula:

% Successful Activations = (mobileinitActivations /
totalDataSessionActivations) * 100
totalDataSessionActivations = mobileInitActivations +
insufficientResources +
missingOrUnknownApn +
unknownPdpAddrOrPdpType +
userAuthenticationsFailed +
activationRejectedByGgsn +
activationRejectedUnspecified +
serviceOptionTempOutOfOrder +
nsapiAlreadyUsed +
semanticallyIncorrectMessage +
invalidMandatoryInfoElement +
411-8111-500 Standard 02.05 June 2003

Alarms 2-55
msgTypeNotCompWithProtState +
protocolErrorUnspecified
The alarm is cleared when the number of PDP Activation rejections is below
5% of the total number of PDP Activation requests or when the total number
of PDP Activation Request messages is greater than zero.
Probable cause
Type
Remedial action
Examine the SM activation failure counters. Verify the health of the network.

2-56 Alarms
7068 1535 - HLR Reset Received Alarm

USC/<x> HlrC Warning message
Legend
Details
The HLR Reset Received alarm is raised by the HlrC component when a
MAP Reset message is received from the HLR.
The alarm will display the E.164 HLR address and the number of subscribers
stored in HlrC that are associated with this HLR.
The HLR sends a Reset message to the SGSN when the HLR experiences a
failure. The SGSN, in reponse to the Reset message, requests subscription
information from the HLR for all subscribers attached on the SGSN in order
to restore the subscribers. This process may impact the USC's utilization and
performance. The level of impact varies with the number of subscribers to be
restored and USC utilization prior to receiving the Reset request.
Probable cause
equipmentFailureCause_c
Type
equipmentType_c
Remedial action
Verify that the HLR is functioning properly.
411-8111-500 Standard 02.05 June 2003

Alarms 2-57
7068 1540 - Usc GtpM Keep-Alive Alarm

USC/<x> minor/cleared set/clear
Legend
Details
This alarm is raised by the Usc component to declare a path failure to an IP
address of a GSN. The declaration of the path failure will be shortly after the
detection of the path failure (that is defined in the spec 3GPP 29.060) in the
case the other GSN is having a very short period of congestion.
Minor - when at least one GTP path has declared failure
Clear - when all of the failed GTP paths have recovered or are deleted
Probable cause
remoteTransmissionErrorCause_c
Type
Remedial action
Verify the health of the GSN with the reported IP address. Verify the health of
the network.

2-58 Alarms
411-8111-500 Standard 02.05 June 2003

A-1
MDM alarm screening macro A

This section describes how to set up an MDM trigger for improved visibility
of selected alarms. For more information about MDM macros, refer to NTP
241-6001-301, MDM 12.5 Customization Administrator Guide.
This macro will bring up a warning window and ring a bell upon receiving
specified kinds of alarms, and log the alarm to a file. The pop up window will
stand for 10 seconds (configurable) then disappear. You can stop this
screening anytime you want without affecting normal MDM logging.
Starting a trigger
The following example shows how to start a trigger:
1. Go to /opt/MagellanNMS/cfg/macros/nms
2. Enter
AlarmTrigger -pfault "7068" -cmd "/opt/MagellanNMS/cfg/
macros/user/screen"
where “7068” are the first four digits of NTP indices assigned to SGSN
alarms, -pfault is the screening option (more options are listed below), and
screen is the script (shown below) that generates a new log. The final log
is "screenedAlarm" under the current directory.
AlarmTrigger options
# Synopsis : AlarmTrigger [-fault "<faultcode>"]*
# [-pfault "<faultcode pattern (post filtered)>"]*

# [-pref "<component prefix>"]*
# [-comp "<component>"]*
# [-pcomp "<component pattern (post filtered)>"]*
# [-cfile "<component pattern file (post filtered)>"]
# [-event set|clear|message]*
# [-sev critical|major|minor|warning|cleared|indeterminate]*
# [-serv <GMDR service name>]
# [-host <GMDR hostname>]

A-2 MDM alarm screening macro
# [-or (alternative filters)]*
Example macro
$ cat /opt/MagellanNMS/cfg/macros/user/screen
/opt/MagellanNMS/bin/xmsg "SGSN Alarm! Go check log file

screenedAlarm" -title AlarmWarning -pixmap /usr/dt/include/
bitmaps/xm_warning -delay 10 -bell
tail -7 /opt/MagellanNMS/data/log/MDMalarmtest >>
screenedAlarm
411-8111-500 Standard 02.05 June 2003

test
Family Product Manual Contacts Copyright Confidentiality Legal
UMTS
Reference Manual
To order documentation from Nortel Networks Global Wireless Knowledge Services, call
(1) (877) 662-5669
To report a problem in this document, call

(1) (877) 662-5669
or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at
http://www.nortelnetworks.com/td
Copyright  2002–2003 Nortel Networks, All Rights Reserved
NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its
employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the
same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly
authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
*Nortel Networks, the Nortel Networks logo, the Globemark, How the World Shares Ideas, Unified Networks, Passport, DMS,
DMS-HLR, and MAP are trademarks of Nortel Networks.GSM is a trademark of GSM MOU Association.
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
Document number: 411-8111-500
Product release: UMTS 3.0
Document version: Standard 02.05
Date: June 2003
Originated in Canada

UM641 Appendix B v03.02

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UM641 Appendix B v03.02

Uploaded by

Copyright:

Available Formats

APPENDIX B

Wireless Gateway Alarms

"Confidential information -- may not be copied or disclosed without permission".

UM641 03.02 July 2003

"Confidential information -- may not be copied or disclosed without permission".

UM641 03.02 July 2003

UMTS 3.0 Standard 02.05 June 2003 411-8111-500_S02.05

Document number: 411-8111-500

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright  2002–2003 Nortel Networks, All Rights Reserved

NORTEL NETWORKS CONFIDENTIAL

411-8111-500 Standard 02.05 June 2003

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

411-8111-500 Standard 02.05 June 2003

About this document ix

Alarms overview 1-1

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

7068 1016 - SAS Initialization Failure Alarm 2-22

MDM alarm screening macro A-1

411-8111-500 Standard 02.05 June 2003

About this document

Software release applicability 0

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

411-8111-500 Standard 02.05 June 2003

• 241-5701-060, Passport 7400, 15000 Components

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

Preside for Wireless Internet, Solution for GPRS

Preside Multiservice Data Manager (MDM) release 12.5 documentation

Indication of hypertext links 0

411-8111-500 Standard 02.05 June 2003

Note: For information about Wireless Gateway component OSI states,

A component generates a MSG or SET/CLR alarm when a significant event

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

Alarms contain a great deal of information to assist in troubleshooting. Alarm

Anyone responsible for operating and maintaining an Wireless Gateway

Alarms specific to the Wireless Gateway 1

411-8111-500 Standard 02.05 June 2003

Conditions that trigger alarms

Threshold conditions generally generate alarms only if the resource that is

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

411-8111-500 Standard 02.05 June 2003

The alarms generated by Wireless Gateway components are largely caused by

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

411-8111-500 Standard 02.05 June 2003

— Initialization Failure - 7068 1507

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

— Loss of Connection with SIG - 7068 1523

• Lawful Intercept Access Function Alarms

411-8111-500 Standard 02.05 June 2003

7056 1300 - TDM Link Failure Alarm

Component Severity Status

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

7065 0000 - Mapping Table Full Alarm

Component Severity Status

411-8111-500 Standard 02.05 June 2003

7066 0000 - Connections Exhausted Alarm

Component Severity Status

When the status is clear, no remedial action is necessary.

UMTS Wireless Gateway Alarms Reference Manual UMTS 3.0

7066 0100 - Signalling Link Test Failed Alarm

Component Severity Status

411-8111-500 Standard 02.05 June 2003

7066 0101 - Destination Inaccessible Alarm

Component Severity Status