411-9001-131 (BSC TCU Fault Clearing) PDF

Global System for Mobile Communications (GSM)
Nortel GSM BSC 3000/TCU

3000 Fault Clearing
Release: 18.0
Document Revision: 18.07
www.nortel.com
411-9001-131
.
Release: 18.0
Publication: 411-9001-131
Document release date: 12 March 2010
Copyright © 1999-2009 Nortel Networks. All Rights Reserved.
While the information in this document is believed to be accurate and reliable, except as otherwise expressly
agreed to in writing NORTEL PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OR CONDITION OF
ANY KIND, EITHER EXPRESS OR IMPLIED. The information and/or products described in this document are
subject to change without notice.
Nortel, Nortel Networks, the Nortel logo, and the Globemark are trademarks of Nortel Networks.
All other trademarks are the property of their respective owners.
.
3
.
Contents
New in this release 7
Features 7
Other Changes 7
Introduction 9
Chapter 1 How to use this manual 11
1.1 Introduction 11
1.2 Description of a fault number sheet 12
Chapter 2 BSC 3000 fault numbers 15

2.1 Fault number: 47 15
2.3 Fault number 1310 17
2.8 Fault number: 2000 (BSC 3000) 25
2.9 Fault number: 2001 (BSC 3000) 31
2.14 Fault number: 2008 (BSC 3000) 44
2.15 Fault number: 2009 (BSC 3000) 51
2.16 Fault number: 2010 (BSC 3000) 62
2.17 Fault number: 2011 (BSC 3000) 63
2.20 Fault number: 2014 (BSC 3000) 65
2.24 Fault number: 2019 (BSC 3000) 70

Nortel GSM BSC 3000/TCU 3000 Fault Clearing
411-9001-131 18.07 12 March 2010

4

2.29 Fault number: 2024 (BSC 3000) 77
2.31 Fault number: 2027 (BSC 3000) 81
2.32 Fault number: 2028 (BSC 3000) 83
2.33 Fault number: 2030 (BSC 3000) 84
2.34 Fault number: 2031 (BSC 3000) 84
2.35 Fault number: 2032 (BSC 3000) 85
2.37 Fault number: 2034 (BSC 3000) 97
2.45 Fault number: 2046 (BSC 3000) 106
2.46 Fault number: 2047 (BSC 3000) 108
2.59 Fault number: 2068 (BSC 3000) 125
2.60 Fault number: 2069 (BSC 3000) 127
Chapter 3 TCU 3000 fault numbers 131

3.1 Fault number: 2000 (TCU 3000) 131
3.2 Fault number: 2001 (TCU 3000) 133
3.3 Fault number: 2008 (TCU 3000) 135
3.4 Fault number: 2009 (TCU 3000) 137
3.5 Fault number: 2010 (TCU 3000) 145
3.6 Fault number: 2011 (TCU 3000) 146

411-9001-131 18.07 12 March 2010

5
3.7 Fault number: 2014 (TCU 3000) 147

3.8 Fault number: 2019 (TCU 3000) 148
3.9 Fault number: 2024 (TCU 3000) 150
3.11 Fault number: 2027 (TCU 3000) 155
3.12 Fault number: 2028 (TCU 3000) 156
3.13 Fault number: 2030 (TCU 3000) 157
3.14 Fault number: 2031 (TCU 3000) 157
3.15 Fault number: 2032 (TCU 3000) 158
3.16 Fault number: 2034 (TCU 3000) 168
3.19 Fault number: 2046 (TCU 3000) 172
3.20 Fault number: 2047 (TCU 3000) 174
3.22 Fault number: 2068 (TCU 3000) 177
3.23 Fault number: 2069 (TCU 3000) 179
Chapter 4 Informational messages 183

411-9001-131 18.07 12 March 2010

6

411-9001-131 18.07 12 March 2010

7
.
New in this release

The following section describes what is new in this release for Nortel GSM
BTS S8006 Troubleshooting (411-9001-131) for V18.0 P&C 2 release.
• “Features” (page 7)
Features
This document contains no feature updates in this release.
Other Changes
See the following section for information about changes that are not
feature-related:
• added 2.3 “Fault number 1310” (page 17)

411-9001-131 18.07 12 March 2010

8 New in this release

411-9001-131 18.07 12 March 2010

9
.
Introduction
This document explains how to clear a BSC 3000 or TCU 3000 fault on the
OMC-R. It contains all the fault numbers of the BSC 3000 and TCU 3000.
Prerequisites
The readers must be familiar with the following technical documents:
Nortel GSM BSS Documentation Roadmap (411-9001-000)
Nortel GSM BSS Fault Management — Maintenance Principles

(411-9001-039)
Nortel GSM BSS Fault Clearing — Advanced Maintenance Procedures

(411-9001-105)
Nortel GSM BSC 3000/TCU 3000 Fundamentals (411-9001-126)
Nortel GSM BSC 3000/TCU 3000 Troubleshooting (411-9001-132)
Navigation
This document consists of 3 chapters:
• Chapter 1 “How to use this manual” (page 11), describes how to use
this maintenance manual.
• Chapter 2 “BSC 3000 fault numbers” (page 15), contains the fault
number description and the corrective maintenance procedures
applicable to the BSC 3000.
• Chapter 3 “TCU 3000 fault numbers” (page 131), contains the fault
number description and the corrective maintenance procedures
applicable to the TCU 3000.

411-9001-131 18.07 12 March 2010

10 Introduction

411-9001-131 18.07 12 March 2010

11
.
Chapter 1 How to use this manual

1.1 Introduction
This manual contains the fault number description and corrective
maintenance procedures that are only applicable to the BSC 3000 and the
TCU 3000.
The general principles and messages required for BSS maintenance

are described in Nortel GSM BSS Fault Management — Maintenance
Principles (411-9001-039).
Network maintenance is based on graphical supervision of the network.
It is also based on the identification and replacement of faulty items of

equipment, using the alarms and notifications.
This process is divided into two steps:

• locating and identifying the faulty items of equipment, using information
given in this manual
• replacing the faulty items of equipment, using the replacement
procedures given in the manual that describe on-site procedures (refer
to Nortel GSM BSC 3000/TCU 3000 Troubleshooting (411-9001-132))
When a faulty item of equipment sends an alarm to the OMC-R, this

alarm is identified by a fault number. This manual gives the procedures
associated with the various fault numbers.
Description of the representation n+p:

• n : shows the minimum number of TMU so that all core processes are
at least in simplex mode.
• n+p : shows the necessary number of TMU so that all core processes
are in duplex mode.

411-9001-131 18.07 12 March 2010

12 Chapter 1 How to use this manual
1.2 Description of a fault number sheet

A corrective maintenance sheet contains the following information:
• the header
• the main body composed of eight main paragraphs explaining the fault
number treatment
1.2.1 Header of the sheet

The header contains the following information:
• the fault number and possibly the cause
• the alarm type
1.2.2 Main body of the sheet

The main body contains the following information:
• Fault analysis
This paragraph describes the fault and gives the alarm severity,
indicated by the system state.
— MINOR: when an unbalanced distribution is detected by the Load
Balancing application with no resource missing
— MAJOR: when the system is in "exposure"
– all the active core groups are running
– some of the passive core groups are not present
— CRITICAL: when some of the active core groups are not present
— CLEARED: when Load Balancing considers that the applications
are well balanced on the Control Node
Always : Warning/Cleared for every elements.
Only Control Node, Interface Node and TCU object can be associated
with Minor, Major or Critical level.
If fault number leads to the replacement of modules or boards, Nortel

GSM BSC 3000/TCU 3000 Troubleshooting (411-9001-131) indicates
localization of these elements for each rack from BSC 3000 and TCU
3000.
• Reaction of the system
— Equipment units defense:
This paragraph describes the defense actions taken by the
equipment units.
— Impact on service

411-9001-131 18.07 12 March 2010

1.2 Description of a fault number sheet 13
This paragraph gives the consequences of the alarm for service.

• Troubleshooting:
This paragraph gives the procedures or the flow charts to be followed
to repair the fault and return the equipment to operational conditions.
Two conditions indicate failure:

• Maintenance task is necessary each time a fault has critical level
(Major or Critical)
• If it lasts more than 10 minutes (Disable failed)
Each procedure or flow chart is composed of three parts:

• preliminary checks that are used to ensure that the fault is confirmed
and that the messages identifying a faulty element are in the OMC-R
logs before the start of repair work
• on-site maintenance (possibly using the OMC-R) that is used to start
the repair work and to ensure that the exchanged component will
operate correctly
• additional checks, showing how to check that the fault has been
cleared
If the fault number is still present after modules or boards replacement,

move to the next highest level of support.

411-9001-131 18.07 12 March 2010

14 Chapter 1 How to use this manual

411-9001-131 18.07 12 March 2010

15
.
Chapter 2 BSC 3000 fault numbers

2.1 Fault number: 47
Fault number:
47 : Cessation of active alarms
Type : communicationsAlarm, environmentalAlarm, equipmentAlarm,
processingErrorAlarm, qualityOfServiceAlarm
FAULT ANALYSIS
This notification can be sent in response to the following conditions:
• after a BSC, TCU, PCUSN, or BTS restart (probable cause number 64)
• when the OMC-R performs a purge of alarms as defined in the OMC-R
static configuration. The purge type can be purgeOnSaturation
(Probable Cause 65) or dailyPurge (Probable Cause 66).
If the anomaly that triggered these alarms is still present after the BSC,
TCU, or BTS restart, new alarms will be sent to the OMC-R. Thus, no
information is lost.
If the anomaly that triggered these alarms is still present after purge
on saturation or daily purge, no new alarm is sent to the OMC-R and
information is lost.
The notification concerns one alarm type (see the list given above in the
title box).
The notification concerns one of the following objects: bsc,

btsSiteManager, transcoder, pcu.
The type of alarm clearing is displayed in the probableCause field of the

notification.

411-9001-131 18.07 12 March 2010

16 Chapter 2 BSC 3000 fault numbers
probable probableCause
Type of alarm clearing
Cause No. wording
64 bscRequest • notification sent by the BSC
• Purge performed by the BSC: consists
in sending a list of alarms which may be
cleared by the OMC-R if they are still
active
65 purgeOnSaturation • notification sent by the MD
• The defense purge consists in clearing
the oldest alarms. The threshold is fixed
by the static configuration.
66 dailyPurge • notification sent by the MD
• The daily purge consists in clearing
the alarms that are older than N days,
every day. N is fixed by the static
configuration.
REACTION OF THE SYSTEM

BSC defense
None.
Impact on the service

None.
TROUBLESHOOTING
No maintenance is required.

Fault number:
1074 : Indication of non activated features on specific instances
Type : equipmentAlarm
FAULT ANALYSIS
After a "Display all" command, the BSC sends a global notification that
lists all the TDMA where one (or more) feature is not activated. This fault
also gives the number of non activated features and the feature identifier.
Values of features_id field :

• Cell tiering (0)
• New L1m (1)
• GPRS service (2)

411-9001-131 18.07 12 March 2010

2.3 Fault number 1310 17
• AMR (3)
• Call drop analysis (4)
• Distribution (5)
• GSM to UMTS handover (6)
• EMR-Enhanced Measurement report (7)
• AMR-HR on pre-empted PDTCH (8)
• A5/3 encryption algorithm (9)
• Not used (10)
• DTM support (11)
• Not used (12-31)
TROUBLESHOOTING
The notification shows the incompatibilities between the features

configured by the operator and the hardware possibilities. Despite
hardware compatibility, "GPRS service" is shown as disabled if:
• GPRS service is not activated on this cell
• there is at least one PDTCH missing in the TDMA configuration
2.3 Fault number 1310

Fault number:
1310 : An interface protocol error indication
Type : communicationsAlarm
FAULT ANALYSIS
This warning notification is caused by a software anomaly on the A

interface and the MSC. The BSC receives an unknown message from the
MSC. Most often there is an incompatibility between what the MSC sends
and what the BSC knows. The "Source" field of the notification can contain
the following values:
• 10 -Unknown CIC (in this case, data length (lg_data) = 2, and
the received CIC which is incorrect is dumped. This dump is in
hexadecimal representation and appears in a form similar to 0x0799).
• 26 - Unknown IEI
• 27 - Bad length of element
• 51 - Unknown message in this way
• 52 - Too short reserved length - imperative reserved area

411-9001-131 18.07 12 March 2010

• 53 - Minimum length not respected

• 54 - Unknown message type
• 55 - Unknown message group
• 65 - Essential element missing
• 66 - Wrong mandatory element
The MSC version is incompatible with the BSC. The "Circuit Identity
Code" field contains the CIC coded number declared at the MSC level but
unknown to the BSC. This is true for all of the 1310 fault.
BSC defense
None. The TMG does not use these channels.
The communication cannot be established on the considered channels.
TROUBLESHOOTING
Maintenance using the OMC-R
Step Action
1 Look at the source given in the "Source" field of the notification.

• If the source is "10 Unknown CIC", go to step 2.
• If the source is "26", "27", 1"51", "52", 1"53", "54", "55", "65",
or "66", it is a transient problem. If this notification is often
emitted, call the manufacturer.
2 Search for the reason why there is such an inconsistent

configuration.
• If it was configured this way on purpose, to prepare a network
extension for instance, this fault number emission is normal,
and no maintenance is required. Go to step 4.
• If it was not configured this way on purpose, then there is an
error in the configuration. Go to step 3.

411-9001-131 18.07 12 March 2010

3 Correct the inconsistent configuration in one of the following

ways:
• At the OMC-S, delete the CIC indicated in the notification, OR
• At the OMC-R, create the equivalent CIC for the BSC, and
the xtp objects as well.
Additional Checks
4 Check the notification state in the "Current alarm list" window.
• If the notification has disappeared, go to step 7.
• If the notification persists, go to step 5.
5 Check the state of the TCU, by performing a "Display all"

command on the object concerned.
• If the operationalState of the object is "enabled", the fault is
not confirmed. Go to step 6.
• If the operationalState of the object is "disabled", and the
availabilityStatus is "failed", call the manufacturer.
6 Clear the notification.

7 The procedure is complete.
--End--

Fault number:
1315 : Path information for calls released by TCU or BTS
Type : communicationsProtocolError
FAULT ANALYSIS
Perceived severity: WARNING
In cases where there is a loss of communication between the TCU and

the BTS, the user would hear only silence and would eventually terminate
the call. The system now detects these types of failures and releases the
call automatically.
This warning notification is sent to indicate the path associated with the
dropped call to facilitate troubleshooting the problem.
This notification indicates that either the BTS or the TCU has detected
a loss of frame synchronization. The call is released and the following
counters are incremented:

411-9001-131 18.07 12 March 2010

• C1164/32 if the BTS detects the fault

• C1164/28 if the TCU detects the fault
The warning is subject to a threshold: 100 occurrences (of call released

per cellGroup) affecting the same path will result in 1 warning at the
OMC-R.
The fault could be indicative of Transmission Line failure, Transmission

Equipment failure (i.e. DACS) or a failure within the BSC 3000 or TCU
3000 or BTS.
BSC defense
None.
Calls have been dropped.
TROUBLESHOOTING
Preliminary checks
Step Action
1 Monitor counter C1164 to determine the frequency of occurrence

and which transmission direction is affected:
• C1164/28: Indicates a failure in the path from BTS to TCU.
• C1164/32: Indicates a failure in the path from TCU to BTS.
ATTENTION
Either one may be caused by a failure of either ABIS or ATER PCM.
2 Check for any notifications relating to the BSC, TCU or

Transmission links (PCM), treat these symptoms first then verify
if counters are still incremented.
• If the counters are no longer incremented, the fault is not
confirmed, go to step 8.
• If the counters are still incremented, go to step 3.
3 Use the information provided in the notification 1315 to know the

failing path:

411-9001-131 18.07 12 March 2010

• date: date of the drop call

• cic: identifies the BSC/MSC CIC
• trm: the TRM board number in the TCU 3000
• archipel: archipelago of the used TRM
• architecture: (4) TCU 3000
• pcm_ater: ATER PCM number
• ts_ater: timeslot on ATER PCM
• tcu_circ: internal Ater TCU circuit (16K channel) number
• pcm_abis: ABIS PCM number
• ts_abis: timeslot on ABIS PCM
• pcm_circ: internal Abis pcm circuit (16K channel) number
• cell_group: cell group number
• cell: BSC internal cell Id
• TDMA: TDMA number
• channel: channel number on TDMA
Then go to step 4.
On-site maintenance using the OMC-R
4 Using the decoded path information provided in the notification
1315, look for reoccurring instances of the same object (i.e.
TRM, PCM, Timeslot).
• If the most commonly failing object is a PCM or Timeslot,
determine if it is an ATER or ABIS PCM. Go to step 5.
• If failure is associated with the same TRM, replace the TRM.
Refer to Nortel GSM BSC 3000/TCU 3000 Troubleshooting
(411-9001-132).
5 Confirm the failing path:

• Try to physically swap PCMs, or lock one PCM at a time.
• Try to lock impacted Radio Channels.
• Verify if counter C1164 is still incremented.
— If counters are no longer incremented, fault on Abis or
Ater PCM is confirmed, go to step 6.
— If counters are still incremented, the fault on Timeslots is
confirmed, go to step 7.
6 If either the ATER or ABIS PCM pass through intermediate

equipment such as a DACS:

411-9001-131 18.07 12 March 2010

• Check the DACS board that manages the PCM and the
DACS configuration.
• The DACS (and many other types of transmission equipment)
will often have counters indicating errors, errored seconds,
BPV’s, slips, or Frame errors. Use these to localize the
source of the problem.
ATTENTION
Depending on the type of DACS, it may re-frame the signal, which
would tend to “mask” alarms and some types of errors (slips, notably).
• All transmission facilities should be configured to use

appropriate zero-code suppression (i.e., B8ZS for DS1
facilities).
7 Using suitable test equipment, perform end-to-end quality test of

failing PCM, ensuring that all Timeslots are checked.
• If the failing PCMs are associated with the same LSA,
perform a SWACT of the associated IEM.
• If problem is not identified, call the manufacturer.
--End--

Fault number:
1502 : Access attempt to a non operational cell
Type : qualityOfServiceAlarm
FAULT ANALYSIS
This message warns the operator that an access attempt to a non

operational cell has been made. This can be due to:
• an access attempt to a non-created cell
• paging attempted on a cell in which paging is not authorized
• paging on a cell in which all System Information messages have been
acknowledged
This notification indicates a configuration problem.
When Cell is created, but not operational then the fault number 1502 is
sent to the OMC-R. This could happen when:

411-9001-131 18.07 12 March 2010

1. Cell has been created, attributed and then de-attributed.

After the creation of the cell, a cell in Operational state is attributed after
receiving Sys Info Acknowledgments from BTS.
A Cell in Operational state is de-attributed, when the cell is out of service
in BSC.
Fault number 1502 is sent to OMC-R, after one of the following call flows
occurs:
Call Flow 1
A Channel Required message is sent to the BSC (Traffic Management).
Traffic management issues fault number 1502.
Call Flow 2
An inter-cell handover is requested for a call setup on its destination cell
(inter or intra BSC).
An Access Request message is sent to the BSC (Traffic Management).
Traffic management issues fault number 1502.
Fault number 1502 is issued for the following reason:

If the CCCH downlink channel is not initialized and if the BSC is in the
active mode, fault number 1502 is triggered. The warning is issued, if
this scenario is executed more than 100 times. The limitation of 100
times exists because of a warning threshold present in RADCEL warning
management.
2. Cell has been created but not attributed.

The cell has not been attributed by SPR (Radio supervision), i.e., Sys Info
Exchange has not happened between BSC and BTS for this cell.
FIELD DESCRIPTION
Target CGI:
Example
cell parameters: mcc, LAC, mnc, and ci
Cell Admin State:
Example
0: not created
205: created
Cell Paging State:
Example
0: not significant
1: not allowed because BCCH information not acknowledged
2: paging request allowed

411-9001-131 18.07 12 March 2010

Radio Data Consistency for TMG point of view:
Example
0: consistent
1: inconsistent
TS Carrying Common Channel:
Example
TS carrying common channel
BSC defense
None.
None.
ATTENTION
Service is reduced.
TROUBLESHOOTING
Check the configuration against the information given in the notification.

Fault number:
1503 : Access Attempt to an unknown BCCH or BSIC
FAULT ANALYSIS
This anomaly is sent when a handover is required towards a (bsic,bcch)

not belonging to the neighboring cells of the originated cell.
This alarm indicates that a mobile sent measurement reports with

measures reported from an unknown neighbor cell identified by the couple
(BCCH, BSIC) which is not declared in the adjacent handover cell list at
the OMC-R.
BSC defense

411-9001-131 18.07 12 March 2010

2.8 Fault number: 2000 (BSC 3000) 25
None
None.
TROUBLESHOOTING
To solve this problem, check the frequency plan and the frequency bands.
For the cells found in the Session Log, verify the accuracy of the datafill
(BSIC/BCCH) for the impacted cell (on the bts object) and its neighboring
cells.

Fault number:
1525 : Modification of Agprs configuration
Type : warning
FAULT ANALYSIS
After running Agprs cell allocation online and offline algorithms, if there
is a change in Agprs configuration, this warning "Modification of Agprs
configuration" is sent by SPP to the OMC-R. This warning describes
exhaustively the Agprs interface configuration. The OMC-R treats the
notification and stores the information in a configuration file on SDO.
This warning indicates the new mapping of cells on Agprs interface,

allowing monitoring tools to perform Agprs statistics per PCM.
TROUBLESHOOTING
No maintenance is required.
The configuration of the Agprs being automatically reported to the OMC-R,

the operator has access to new configuration data that can be processed
by PrOptima. Agprs metrics per PCM can then be computed allowing
improving monitoring and optimization processes.
2.8 Fault number: 2000 (BSC 3000)

Fault number:
2000 : Power failure
Type : EquipmentAlarm
FAULT ANALYSIS

411-9001-131 18.07 12 March 2010

ATTENTION
This fault number also applies to TCU 3000. See 3.1 “Fault number: 2000 (TCU
3000)” (page 131).
Perceived severity: MAJOR/CLEARED
This notification can appear for the Control Node or the Interface Node in
two different cases:
• after a period of normal operating (only after reset of the module)
• on board insertion and incorrect MIM reading
Fault number 2000 can come either from the Interface Node or from the
Transcoder Node.
The managed objects (MOs) are: atmRm, cc, cem, cem3, controlNode,
hsaRc, , iem, interfaceNode, iom, lsaRcBsc, mms, omu, sw8kRm, tmu.
The managed objects (MOs) are: atmRm, cc, cem, cem3, controlNode,
hsaRc, , iem, igm, interfaceNode, iom, ipgRc, lsaRcBsc, mms, omu,
sw8kRm, tmu.
The type, position and slot number of the module are given in the
notification.
The modules are involved in the Control Node can be one of the following:
• OMU
• MMS
• TMU
• TMU3
• ATM-SW (CC1)
The modules involved in the Interface Node can be one of the following
• CEM
• CEM3
• ATM-RM
• LSA-RC
• HSA-RC
• 8K-RM
• IGM
• IPG

411-9001-131 18.07 12 March 2010

2.8 Fault number: 2000 (BSC 3000) 27
The modules are redundant.
If the first module is involved, there is no impact on the service.
Case of the shared MMS module and notification after a period of

normal operating
CAUTION
Service interruption
When the second module is involved, service is lost.
Case of the TMU module (with configuration)
ATTENTION
There is a potential service degradation if less than "n" boards are available.
Otherwise, there is no impact on service.
A 2004 fault number may appear.
Case of OMU module or its private MMS
In the case of a fault on the active OMU module, restart is automatic on

the other OMU module.
In the case of a fault on the passive OMU module, redundancy is lost.
Case of ATM-SW module
CAUTION
If one ATM-SW module is faulty, as soon as the other ATM-SW
module is faulty, service is lost.
TROUBLESHOOTING
Fault 2000 can occur either at the control node or the interface node.
If the fault originates in the control node, refer to the following flow chart.
If the fault originates in the interface node, perform a "display all"

command to confirm the status of the modules and replace the module
identified in the notification. (The red LED on the failed module will be lit).

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.8 Fault number: 2000 (BSC 3000) 29

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.9 Fault number: 2001 (BSC 3000) 31

Fault number:
2001 : Hardware not supported
FAULT ANALYSIS
ATTENTION
3000)” (page 133).
This diagnosis event is mapped Control Node object and is sent as Major
(for BSC 3000) to OMC-R in the following cases:
• At module insertion when the module "PEC code" is not supported by
the Control Node software (not referenced in MIB)
• At module insertion when the synchronization with the module software
cannot be done (time-out)
• After an upgrade procedure, for modules with a "PEC code" that is no
longer supported (no more referenced in MIB)
• After a replacement procedure, for modules that are not compatible
with the existing configuration (for example when the disk size doesn’t
match, because a MMS2 can only be replaced by a MMS2, and not
by a MMS1)
• If a TML user attempts to set the parameter BscSharedDiskCapacity to
High for an MMS that does not support it (for example, an MMS1 or an
MMS2 serving as a spare for a MMS1)
• After reset or restart, if the synchronization with the module software
cannot be done (time-out)
This diagnosis event is cleared when, after an upgrade, a not supported

"PEC code" becomes supported (referenced in the new MIB).
It must be purged when a purge event including this codano is sent on the
object this diagnosis event is mapped on.
In this diagnosis event, the concerned module is given in the hardware

slot position field.
The type, position, and slot number of the module are given in the
notification.

411-9001-131 18.07 12 March 2010

The managed Object is: controlNode, transcoder, inode
For the interfaceNode, this fault is not sent.
The modules are involved in the controlNode. They can be one of the
following:
• OMU module
• MMS module
• TMU module
• ATM-SW module
BSC 3000 defense
None.
TROUBLESHOOTING
For the troubleshooting of the 2001 fault number, refer to the following flow
chart.

411-9001-131 18.07 12 March 2010

2.9 Fault number: 2001 (BSC 3000) 33

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.9 Fault number: 2001 (BSC 3000) 35

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010


Fault number:
2004 : Load balancing performed
Type : QualityOfServiceAlarm
FAULT ANALYSIS
Perceived severity: MINOR/MAJOR/CRITICAL/CLEARED
The notification 2004 warns the operator that the current Core Process
distribution is not satisfactory. It is automatically cleared by the BSC when
the Core Process distribution becomes satisfactory.
This notification can appear in two cases:

• Capacity increase problem: btsSiteManager or transceiverEquipment
objects are created and the system cannot support them. A load
balancing operation is performed. Supplementary TMU modules are
required. Refer to the "Number of TMU" field of the notification to
determine the number of TMU modules inserted in the cabinet.
• Hardware problem. Two different cases are possible:
— some TMU modules are faulty: the load balancing operation allows
allocation of resources on the remaining TMU modules
— some TMU are added: the load balancing operation allows
allocation of resources on all the TMU modules
The Managed Object is: controlNode.
The three additional problems which could occur in notification are: Add
objects, Add/Remove modules from TMU, Software failure.
Reminder:
A core process is duplex when TMUs, in term of load, can manage both
the active and passive processes.
A core process is simplex when TMUs, in term of load, can manage only
the active process ("Error type" field: simplex).
A core process is nullex when TMUs, if any, can manage neither the active
process nor the passive process ("Error type" field: nullex).
Here is the list of the core group types:

411-9001-131 18.07 12 March 2010

• Current core group type: SS7

• Current core group type: PCU
• Current core group type: TCUe3
• Current core group type: CellGroup
"Number of present TMU" field: indicates the number of TMU currently

installed in the BSC.
"Number of missing TMU" field: indicates the number of potentially missing

TMU. This number is defined as follows:
1. If the current Core Process distribution is such that all Core Groups are
duplex, then the number of potentially missing TMU is equal to 0.
2. Otherwise, the number of potentially missing TMU is defined as
the smallest number of TMU required such that the Core Process
distribution is full duplex after an online load reconfiguration or a BSC
restart. Refer to the Troubleshooting section when this number is not
equal to 0, and in all cases when the notification is "Major" or Critical".
"Reconfiguration recommendation" field: quantifies the benefit of applying

an online load reconfiguration (0 : negative, 1 : null, 2 : low, 3 : strong,
4 : mandatory).
This notification is declared:

• "MINOR" when an unbalanced distribution is detected by the Load
Balancing application with no resource missing. In that case, the
"Number of TMU missing" field is equal to 0 for the current distribution.
• "MAJOR" when the system is likely to be impacted:
— All the active Core Groups are running
— Some of the passive Core Groups are not present:
– the "Number of bad core groups" field of the current distribution
is not equal to 0
– the "Error type" field is equal to SIMPLEX for all the Core
Groups in error.
• "CRITICAL" when the system capacity is reduced:
— some of the active Core Groups are not present

411-9001-131 18.07 12 March 2010

– the "Number of bad core groups" field of the current distribution

is not equal to 0
– at least one of the "Error type" fields is equal to MISSING for
the Core Groups in error
• "CLEARED" automatically when Load Balancing considers that
applications are well balanced on the Control Node. In that case, the
"Number of bad core groups" field of the current distribution is 0.
When this alarm 2004 is raised, the state of the ControlNode Managed
Object is changed to “Enabled / { degraded }”.
When some Core Groups are NULLEX, the state of the corresponding
GSM objects (btsSiteManager, bts, transceiverEquipment, etc..) is
changed to "Disabled/Dependency".
When this alarm 2004 is cleared, the state of the ControlNode Managed
Object is changed to "Enabled".
TROUBLESHOOTING
For the troubleshooting of the "MAJOR" or "CRITICAL" 2004 fault number,

refer to Figure 1 "Flowchart for the major or critical 2004 fault number"
(page 40).

411-9001-131 18.07 12 March 2010

Figure 1
Flowchart for the major or critical 2004 fault number
For the troubleshooting of the "MINOR" 2004 fault number, refer to Figure
2 "Flowchart for the minor 2004 fault number" (page 41).

411-9001-131 18.07 12 March 2010

Figure 2
Flowchart for the minor 2004 fault number

Fault number:
2005 : Load balancing result
FAULT ANALYSIS
This notification gives the result after each load balancing operation.
It gives the current process distribution over the available TMUs. This
notification gives the following information:
• the call processing load (given in Erlangs) of the TMU after execution
of load balancing
• the number of used active and passive internal LAPD ports
• the list of active and passive of the CellGroup present on this TMU
Reminder:

411-9001-131 18.07 12 March 2010

A core process is duplex when TMUs, in term of load, can manage both
the active and passive processes.
A core process is simplex when TMUs, in term of load, can manage only
the active process (Error type: simplex).
A core process is nullex when TMUs, if any, can manage neither the active
process nor the passive process (Error type: nullex).
Here is the list of the core group types:

• Current core group type : SS7
• Current core group type : PCU
• Current core group type : TCUe3
• Current core group type : TCU2g
• Current core group type : Cell
• Current core group type : PLG (PCU LAPD Group)
TROUBLESHOOTING
Maintenance action is not applicable.

Fault number:
2006 : End of load reconfiguration
FAULT ANALYSIS
The warning 2006 notifies the operator that a load reconfiguration has
been either completed or aborted, as indicated in the "Status" field:
• 0 : "completed"
• 1 : "aborted on board event" if the reconfiguration was aborted due to a
TMU event:
— Failure or recovery of a TMU: in this case, the TMU event is
processed normally and, as a consequence, as much as is
reasonably possible of the active or passive Core Processes which
might still be interrupted are recreated.
— Failure of a Core Process termination, service-preserving migration
or creation during the reconfiguration (note that such a failure
results in a TMU reset).

411-9001-131 18.07 12 March 2010

BSC defense
None.
None.
TROUBLESHOOTING
No maintenance action is required.

Fault number:
2007 : Overload threshold crossed
FAULT ANALYSIS
This is a software capacity problem on the OMU or TMU modules.
The software capacity of the modules is involved. There are three overload
thresholds:
• Overload level 1 and level 2:
These are the predefined overload thresholds which carry out of
different defenses in the GSM applications. They damage the service,
but this damage is not perceived by the OMC-R operator.
• Overload level 3:
This is a predefined overload threshold. It is sent when a predefined
overload threshold is crossed. In this case an alarm appears. The
alarm is cleared when the overload value return to less than the
threshold (which can be seen on a hysteresis). This overload level
causes a loss of some service.

411-9001-131 18.07 12 March 2010

Overload threshold notifications are sent or cleared under the following

circumstances:
• Notification is sent with severity Major when Overload level 3 is
crossed.
• Notification is cleared when Overload returns to a level lower than 3.
• No notification is sent when level 1 or level 2 are crossed.
Notification contains the following data:

• list of modules which have crossed level 3
• resource in overload level 3 for each module in overload.
The overload levels 1 and 2 cause a damage of service (for example

reduction of service: paging).
The overload level 3 causes a loss some of service (for example, only one
cell is managed).
TROUBLESHOOTING

Fault number:
2008 : Hardware failure
FAULT ANALYSIS
ATTENTION
3000)” (page 135).
Perceived severity: MINOR/MAJOR/CLEARED
This diagnosis event (ANO_HARDWARE_FAILURE ON HARDWARE

OBJECTS) is sent in the following cases:
• After module insertion, if the "flash" of the module cannot be
downloaded
• At module insertion, when the "BIST" of the module are failed

411-9001-131 18.07 12 March 2010

2.14 Fault number: 2008 (BSC 3000) 45
• After a reset or a restart, when the "BIST" of the module are failed
• When an "OC3 fiber" is detected as failed (in fact that may be a
disconnection done by the craft person or a real "OC3 fiber" failure)
This diagnosis event is mapped on the hardware object associated to the

faulty module or supporting the faulty "OC3 fiber".
This diagnosis event is sent as Warning (for BSC 3000) or Major to

OMC-R.
This diagnosis event is cleared when the concerned object is no more in

fault and must be purged when a purge event including this codano is sent
on the object this diagnosis event is mapped on.
In this diagnosis event, the concerned module is given in the hardware

slot position field.
In this diagnosis event, the cause of the failure ("flashing", "BIST" or "OC3
fiber" problem) is given in the MANUF information field.
This diagnosis event (ANO_HARDWARE_FAILURE ON CONTROL NODE

OBJECT) is sent as Major (for BSC 3000 and to OMC-R in the following
cases:
• When a "Power connection and Interface Unit (PCIU)" failure is
detected for a BSC 3000
• When an "Ethernet-Ethernet link" failure is detected (time-out)
This diagnosis event is mapped on Control Node object and is cleared

when the cause of this diagnostic event is no more applicable and must
be purged when a purge event including this codano is sent on the object
this diagnosis event is mapped on.
In this diagnosis event, the passive concerned equipment (not

described as an object managed by the OMC-R) is given in the
Additional_Info_On_Faulty_Equipment field.
This notification appears each time the Hardware Management detects a

hardware failure.
This notification provides the following information for the Control Node:
• it specifies if the event is sent immediately after a restart or not
• it contains the shelf number (0 or 1) and the slot number (from 1 to 15)
of the faulty module.
• it contains the following data if it is available:

411-9001-131 18.07 12 March 2010

— serial number
— PEC number of the IEM board
— hardware release
ATTENTION
If the software application is not able to determine which component is faulty,
one or two modules which might be impacted by the failure can also appear in
the notification.
For the Interface Node, this failure information is transmitted by the fault
number 2032: Miscellaneous SPM alarm.
The managed objects (MOs) (MO) are: atmRm, cc, cem, cem3,
controlNode, hsaRc, iem, interfaceNode, iom, lsaRcBsc, mms, omu,
sw8kRm, tmu.
The managed objects (MOs) (MO) are: atmRm, cc, cem, cem3,
controlNode, hsaRc, iem, igm, igprc, interfaceNode, iom, lsaRcBsc, mms,
omu, sw8kRm, tmu.
The elements involved can be any of the following:

• in the frame assembly:
— PCIU assembly
— inter control card link
• in the Control Node:
— OMU module
— MMS module
— TMU module
— ATM-SW (called CC1) module
If the first module is involved, there is no impact on the service.

normal operating

411-9001-131 18.07 12 March 2010

2.14 Fault number: 2008 (BSC 3000) 47
CAUTION
Case of the TMU module (with n+p configuration)
Reminder:
• - n : shows the minimum number of TMU so that all the core processes
should be at least simplex.
• - n+p : shows the number of necessary TMU so that all the core
processes should be duplex.
ATTENTION
Case of the OMU module or its private MMS

In case of a fault on the passive OMU module, redundancy is lost.
Case of the ATM-SW module
These modules are redundant.
CAUTION
If one ATM-SW module is faulty, as soon as the other ATM-SW
module is faulty, the service is lost.
TROUBLESHOOTING
The troubleshooting depends on the module implication in the hardware

failure. The action associated with the fault may differ. Most of the time,
the action to be carried out is the replacement of the impacted module.
If fault 2008 occurs in the control node, use the following flow chart.

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.14 Fault number: 2008 (BSC 3000) 49

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.15 Fault number: 2009 (BSC 3000) 51

Fault number:
2009 : PCM failure
Type : CommunicationsAlarm
FAULT ANALYSIS
ATTENTION
3000)” (page 137).
A PCM link is faulty if any of the following alarms are triggered for FBT
(Fault Begin Time) consecutive seconds: LOS, AIS, LFA, FE, CRC, RAI,
E-Bits.
The alarms are listed by priority, from the highest (LOS) to the lowest
(E-Bits).
An alarm is cleared when no alarm threshold (LOS, AIS, LFA, FE, CRC,
RAI, E-bits) is detected for at least FET (Fault End Time) consecutive
seconds.
The Managed Object (MO) is pcmCircuit.
This notification provides the following information:

• it specifies whether the event is sent right after a restart or not
• it contains the shelf number (from 0 to 1) hosting the LSA-RC
connecting the PCM and its position within the shelf (from 1 to 15)
• it contains the type of PCM: E1 or T1
• it contains the Threshold value:
— FBT value if alarm severity is major
— FET value if alarm severity is cleared
• the time elapsed in faulty state:
this information is significant when the severity is cleared
• the length of time the alarms are triggered (in seconds):
— the length of time the LOS alarm is triggered (nd_sec_LOS)
— the length of time the AIS alarm is triggered (nd_sec_AIS)
— the length of time the LFA alarm is triggered (nd_sec_LFA)

411-9001-131 18.07 12 March 2010

— the length of time the FE alarm is triggered (nd_sec_FE)

this number is not significant for T1
— the length of time the CRC alarm is triggered (nd_sec_CRC)
— the length of time the RAI alarm is triggered (nd_sec_RAI)
— the length of time the E-Bits alarm is triggered (nd_sec_E-Bits)
At the given time, if multiple alarms are detected, only the alarm with the
highest priority is logged.
In this case for example, the alarm is raised with the following values for
the different errors:
• nd_sec_LOS=3 seconds
• nd_sec_AIS=1 second
• nd_sec_LAF=2 seconds
• nd_sec_FE=1 second
• nd_sec_CRC=1 second
• nd_sec_RAI=0 second
• nd_sec_E-Bits=1 second
The reaction of the system depends on the type of PCM links (Ater,
Abis...).
TROUBLESHOOTING
chart.

411-9001-131 18.07 12 March 2010

2.15 Fault number: 2009 (BSC 3000) 53

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.15 Fault number: 2009 (BSC 3000) 55

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.15 Fault number: 2009 (BSC 3000) 57

411-9001-131 18.07 12 March 2010

The following tables give the relation between PCM links and
LSA-RC/CTU modules (or HSA-RC modules). For more information
on logical slot numbering inside BSC 3000 cabinet (whether electrical
or optical), see Nortel GSM BSC 3000/TCU 3000 Troubleshooting
(411-9001-132).
Table 1
Relation between the PCM E1 link number and the LSA-RC/CTU module in use located in the
BSC 3000
Physical port Logical PCM number
Port number number on
LSA 0 LSA 1 LSA 2 LSA 3 LSA 4 LSA 5
displayed at a LSA-RC
the OMC-R module CTU 4 CTU 0 CTU 1 CTU 2 CTU 5 CTU 3
0 0 0 21 42 63 84 105

411-9001-131 18.07 12 March 2010

2.15 Fault number: 2009 (BSC 3000) 59
Table 1
Relation between the PCM E1 link number and the LSA-RC/CTU module in use located in
the BSC 3000 (cont’d.)
1 1 1 22 43
64 85 106
2 2 2 23 44
65 86 107
| | | | | | | |
| | | | | | | |
| | | | | | | |
19 19 19 40 61
82 103 124
20 20 20 41 62
83 104 125
Table 2
Relation between the PCM T1 link number and the LSA-RC/CTU module in use located in the
BSC 3000
0 0 0 28 56 84 112 140
1 1 1 29 57 85 113 141
2 2 2 30 58 86 114 142
| | | | | | | |
| | | | | | | |
| | | | | | | |
26 26 26 54 82 110 138 166

27 27 27 55 83 111 139 167
Table 3
Relation between the STM1 virtual PCM number and the HSA-RC module in use located in the
BSC 3000
Logical PCM number
Port number displayed Virtual port number on
at the OMC-R a HSA-RC module HSA 0 HSA 1
0 0 147 210

411-9001-131 18.07 12 March 2010

Table 3
Relation between the STM1 virtual PCM number and the HSA-RC module in use located in
the BSC 3000 (cont’d.)
Logical PCM number
1 1 148 211
2 2 149 212
| | | |
| | | |
| | | |
61 61 208 271
62 62 209 272
Table 4
Relation between the OC3 virtual PCM number and the HSA-RC module in use located in the
BSC 3000
Logical PCM number
0 0 196 280
1 1 197 281
2 2 198 282
| | | |
| | | |
| | | |
82 82 278 362
83 83 279 363
Table 5
HSA-RC and STM1 port mapping
Location in the hierarchy Standards equivalents
Virtual port
number on a K (See Note L (See M (See
HSA-RC 1) Note 2) Note 3) KLM number ITU-T Number
0 21 42 1 2 3 1 1 1 22 43 1 2 3
1 22 43 1 2 3 2 1 4 25 46 4 5 6
2 23 44 1 2 3 3 1 7 28 49 7 8 9
3 24 45 1 2 3 4 1 10 31 52 10 11 12
4 25 46 1 2 3 5 1 13 34 55 13 14 15
5 26 47 1 2 3 6 1 16 37 58 16 17 18

411-9001-131 18.07 12 March 2010

2.15 Fault number: 2009 (BSC 3000) 61
Table 5
HSA-RC and STM1 port mapping (cont’d.)
Location in the hierarchy Standards equivalents
Virtual port
number on a K (See Note L (See M (See
HSA-RC 1) Note 2) Note 3) KLM number ITU-T Number
6 27 48 1 2 3 7 1 19 40 61 19 20 21
7 28 49 1 2 3 1 2 2 23 44 22 23 24
8 29 50 1 2 3 2 2 5 26 47 25 26 27
9 30 51 1 2 3 3 2 8 29 50 28 29 30
10 31 52 1 2 3 4 2 11 32 53 31 32 33
11 32 53 1 2 3 5 2 14 35 56 34 35 36
12 33 54 1 2 3 6 2 17 38 59 37 38 39
13 34 55 1 2 3 7 2 20 41 62 40 41 42
14 35 56 1 2 3 1 3 3 24 45 43 44 45
15 36 57 1 2 3 2 3 6 27 48 46 47 48
16 37 58 1 2 3 3 3 9 30 51 49 50 51
17 38 59 1 2 3 4 3 12 33 54 52 53 54
18 39 60 1 2 3 5 3 15 36 57 55 56 57
19 40 61 1 2 3 6 3 18 39 60 58 59 60
20 41 62 1 2 3 7 3 21 42 63 61 62 63
Note 1: Tributary Unit Group 3
Note 2: Tributary Unit Group 2
Note 3: Virtual Tributary
Table 6
HSA-RC and OC3 VT1.5 port mapping
Location in the hierarchy
Virtual port number on a HSA-RC STS Group VT
0 28 56 1 2 3 1 1
1 29 57 1 2 3 2 1
2 30 58 1 2 3 3 1
3 31 59 1 2 3 4 1
4 32 60 1 2 3 5 1
5 33 61 1 2 3 6 1
6 34 62 1 2 3 7 1
7 35 63 1 2 3 1 2
8 36 64 1 2 3 2 2

411-9001-131 18.07 12 March 2010

Table 6
HSA-RC and OC3 VT1.5 port mapping (cont’d.)
Location in the hierarchy
Virtual port number on a HSA-RC STS Group VT
9 37 65 1 2 3 3 2
10 38 66 1 2 3 4 2
11 39 67 1 2 3 5 2
12 40 68 1 2 3 6 2
13 41 69 1 2 3 7 2
14 42 70 1 2 3 1 3
15 43 71 1 2 3 2 3
16 44 72 1 2 3 3 3
17 45 73 1 2 3 4 3
18 46 74 1 2 3 5 3
19 47 75 1 2 3 6 3
20 48 76 1 2 3 7 3
21 49 77 1 2 3 1 4
22 50 78 1 2 3 2 4
23 51 79 1 2 3 3 4
24 52 80 1 2 3 4 4
25 53 81 1 2 3 5 4
26 54 82 1 2 3 6 4
27 55 83 1 2 3 7 4

Fault number:
2010 : ISIMA failure
Type : Equipment alarm
FAULT ANALYSIS
ATTENTION
3000)” (page 145).

411-9001-131 18.07 12 March 2010

2.17 Fault number: 2011 (BSC 3000) 63
Diagnostic event ANO_ALIMA_FAILURE is sent as Major (for BSC 3000)

to the OMC-R, when the Control Node [shelf0/slot15] or Interface Node
[shelf0/slot15] "ALIM" module is either not present, or extracted, or faulty
(the Control Node and Interface Node software can not distinguish these
cases).
This diagnostic event is mapped on the Control Node or Interface Node

object and is cleared when its cause is removed. This diagnostic event is
purged when a purge event including its fault number is sent to the object
which is mapped with the diagnostic event.
The managed objects (MOs) are: controlNode, interfaceNode
A state change on the interfaceNode object occurs when the alarm 2010
is raised at the OMC-R : the operationalState is still "enabled", but the
availabilityStatus becomes "degraded".
TROUBLESHOOTING
The following maintenance is required:

• If the power module is extracted, insert it and turn it on.
• If the power module is turn off, turn it on.
• In other cases, replace the SIM module. Refer to its procedure in
Nortel GSM BSC 3000/TCU 3000 Troubleshooting (411-9001-132).

Fault number:
2011 : ISIMB failure
FAULT ANALYSIS
ATTENTION
3000)” (page 146).

411-9001-131 18.07 12 March 2010

Diagnostic event ANO_ALIMB_FAILURE is sent as Major (for BSC 3000)

to the OMC-R, when the Control Node [shelf1/slot15] or Interface Node
[shelf1/slot15] "ALIM" module is either not present, or extracted, or faulty
(the Control Node and Interface Node software can not distinguish these
cases).

TROUBLESHOOTING


Fault number:
2012 : Loss of A interface (or no establishment) with MSC
FAULT ANALYSIS
Perceived severity: CRITICAL
This fault is sent to indicate that SCCP configuration is not valid (especially
when "SCCP routing indicator" is not set correctly).
This fault is effectively sent if SCCP layer cannot be connected between

the BSC 3000 and the MSC.

411-9001-131 18.07 12 March 2010

2.20 Fault number: 2014 (BSC 3000) 65
This fault can be sent after a Control node startUp, after an IN restart or
after two TCU restarts. It can also be raised if all SS7 links are lost to an
operating BSC.
The Managed Object is: signallingLinkSet
SS7 service is not present (loss of service).
TROUBLESHOOTING

• Check the SCCP configuration on the BSC side and on the MSC side.
• This fault could also occur if all of the SS7 links are out of service. In
this case, a 2012 potential fault is transmitted.

Fault number:
2013 : SS7 SSN LCS
FAULT ANALYSIS
This notification is sent when a client of the SS7 protocol becomes

available or becomes unavailable (at each state change of the SSN LCS).
The Managed Object (MO) is: signalingLinkSet.
TROUBLESHOOTING

Fault number:
2014 : IFan failure
FAULT ANALYSIS

411-9001-131 18.07 12 March 2010

ATTENTION
3000)” (page 147).
Diagnostic event ANO_FAN_FAILURE is sent as Major (for BSC 3000) to

the OMC-R, when a "Cooling Unit" failure is detected on the Control Node
or Interface Node.

The managed objects (MOs) are: controlNode are interfaceNode.
The state change does not occur on the controlNode object.
TROUBLESHOOTING

• If a FAN is extracted, insert it.
• In other cases, check each FAN and replace the faulty one(s). Refer
to its procedure in Nortel GSM BSC 3000/TCU 3000 Troubleshooting
(411-9001-132).

Fault number:
2015 : ATM path failure plan 0
FAULT ANALYSIS
This notification indicates a problem on an ATM path (using AAL-1 or

AAL-5 plane 0). The ATM path can be one of the following:

411-9001-131 18.07 12 March 2010

• inter-TMU link
• OMU and TMU link
• inter ATM-SW link
• OMU and ATM-SW link
• TMU and ATM-SW link
A state changed notification appears simultaneously.
The managed objects (MOs) (MO) are: omu, tmu and cc.
This notification gives the following information:

• It specifies if the event is sent right after a restart or not.
• The only one cause of error for this release of BSC 3000 is loopBack
test.
• It indicates the shelf/slot of the ATM-SW module from which the fault
is sent.
• It contains the serial number of the module, the PEC number and
hardware release.
Generally, loss of capacity and, in certain cases (in particular when tests
done for the plane used by SS7 stack are failed due to CC1-7 failure),
loss of service.
TROUBLESHOOTING
The maintenance action required is to check the ATM path.
The first level of maintenance is to verify if backplane and modules are

correctly placed in the shelf (and screwed to the shelf).
The second level of maintenance (if the fault is always effective) is

effectively to change either the faulty module (i.e. OMU, TMU or ATM-SW
module) or if the problem goes on, the ATM-SW module that has emitted
the alarm.
Fault could occur in two cases :

• fault is local : Suspect in fault finding a faulty TMU
• fault is global, applying to one or all modules from TMU : Replace
CC1-7 faulty board

411-9001-131 18.07 12 March 2010


Fault number:
2017 : ATM path failure plan 1
FAULT ANALYSIS
This notification indicates a problem on an ATM path (using AAL-1 or

AAL-5 plane 1). The ATM path can be one of the following:
• inter-TMU link
• OMU and TMU link
• inter ATM-SW link
• OMU and ATM-SW link
• TMU and ATM-SW link
A state changed notification appears simultaneously.
The managed objects (MOs) (MO) are: omu, tmu and cc.

• It specifies if the event is sent right after a restart or not.
• The only one cause of error for this release of BSC 3000 is loopBack
test.
• It indicates the shelf/slot of the ATM-SW module from which the fault
is sent.
• It contains the serial number of the module, the PEC number and
hardware release.
Generally, loss of capacity and, in certain cases (in particular when tests
done for the plane used by SS7 stack are failed due to CC1-8 failure),
loss of service.
TROUBLESHOOTING
The maintenance action required is to check the ATM path.
The first level of maintenance is to verify if backplane and modules are

correctly placed in the shelf (and screwed to the shelf).

411-9001-131 18.07 12 March 2010

The second level of maintenance (if the fault is always effective) is

effectively to change either the faulty module (that is, OMU, TMU or
ATM-SW module) or if the problem goes on, the ATM-SW module that has
emitted the alarm.
Fault could occur in two cases :

• fault is local : Suspect in fault finding the faulty TMU
• fault is global, applying to one or all modules from TMU : Replace
CC1-8 faulty board

Fault number:
2018 : Loss of Lb interface (or no establishment) with SMLC
FAULT ANALYSIS
This fault is sent to indicate that SCCP configuration has failed.
This fault is effectively sent if SCCP layer cannot be connected or is lost

between the BSC 3000 and the SMLC.
This fault can also be raised if all SS7 links are lost to an operating BSC.
The Managed Object is: signallingLinkSet
BSC defense
None.
SS7 service is not present (loss of service).
TROUBLESHOOTING
• Check the SCCP configuration on the BSC side and on the SMLC side.
• This fault could also occur if all of the SS7 links are out of service.
In this case, a 2018 potential fault is transmitted. Depending on the

411-9001-131 18.07 12 March 2010

configuration, check all the PCMA_Lb links or the PCM_Lb links (look
for alarms on PCM links).

Fault number:
2019 : Synchronizing PCM indication
Type : Communications alarm
FAULT ANALYSIS
ATTENTION
3000)” (page 148).
Perceived severity: CRITICAL/CLEARED/WARNING
Reminder: An Interface Node can be synchronized on:

• a PCM port (among the six synchronizer PCM ports of LSA 0)
• a local clock (internal to the node)
The Interface Node selects the best synchronization source among the
possible PCM synchronizer ports (6 first ports of LSA 0) and optical ports.
The Interface Node will preferably synchronize on optical ports. If it detects
a clock instability, it selects one of the PCM synchronizer port among the
six possible PCM ports. If none of the optical ports and of the six possible
synchronizer ports are suitable, the Interface Node selects the local clock
as a synchronization source (the local clock is provided by the active CEM
module).
For the BSC 3000 cabinet, the Managed Object is: interfaceNode and
"hardware transcoder 3G"
This notification (ANO_SYNCHRONIZING_PCM_INDICATION) can

appear in two different cases:
• after the restart of the relevant equipment (no maintenance action is
required)
• on a change of the PCM synchronization source (possible sources are
all the possible synchronizer PCM ports and the local clock)
This notification gives the following information on the event and its
causes:
• due to restart or not
• synchronization type (on a PCM port, on the local clock)

411-9001-131 18.07 12 March 2010

2.24 Fault number: 2019 (BSC 3000) 71
• synchronizer PCM port number (if any)

• hsaRc number: the "HsaRC number" is given if the fault number 2019
was emitted by the interfaceNode. Otherwise, "0XFFFF" is indicated if
a hsaRC is not used as the clock reference.
The perceived severity depends on the previous clock and newly selected
clock:
• Severity is set to CRITICAL when the local clock is selected. In this
case, the IN node or TCU node switch to DEGRADED status.
• Severity is set to CLEARED when the system was synchronized to its
local clock and selects an optical or PCM clock.
• Severity is set to WARNING when the clock is selected from another
PCM.
ATTENTION
A CLEARED notification can occur before a new clock notification on the first
clock change after an OMU restart.
None (due to a smooth clock-switching device).
TROUBLESHOOTING
chart.
Perform the troubleshooting associated with the 2009 fault number for
the CTU 4 - LSA 0 module. Refer to procedure 2.15 “Fault number: 2009
(BSC 3000)” (page 51)

411-9001-131 18.07 12 March 2010


Fault number:
2020 : Supervision failure
FAULT ANALYSIS

411-9001-131 18.07 12 March 2010

A "Supervision failure" notification is sent whenever the operator presses

the push button located on the OMU or MMS front panel. This button is
pressed to prepare the OMU or MMS module for an extraction from its
shelf.
If the faulty module is not removed, the OMU is reinserted in the hardware
configuration after the maintenance period (about 15 minutes). The red
LED stops to blink.
notification.
For the BSC 3000 cabinet, the Managed Object is controlNode,"hardware

transcoder 3G".
The modules involved in the Control Node can be one of the following:
• OMU module
• shared MMS module
• private MMS module
There is a restart of the faulty module.

Fault number:
2021 : IN Access failure
FAULT ANALYSIS
This notification appears when the link between the Interface Node and the
Control Node is lost.
The Managed Object is: interfaceNode.
There are two fiber-optic links between the Control Node and the Interface
Node. Each link is made of an ATM-SW module, a Tx fiber cable, a Rx
fiber cable, and an ATM-RM module. When both links are faulty (for
example, if the ATM-SW faulty on one link and the ATM-RM faulty on the
other link, the service is lost and the "IN Access Failure" notification is
displayed at the OMC-R.

411-9001-131 18.07 12 March 2010

CAUTION
The service is lost.
TROUBLESHOOTING
chart.

411-9001-131 18.07 12 March 2010

Service_interruption
Perform the troubleshooting associated with this fault. Refer to
procedure in 2.14 “Fault number: 2008 (BSC 3000)” (page 44)

Fault number:
2022 : Clock failure
Type : Equipment Alarm
FAULT ANALYSIS
Identifier/Number set by the local Fault Management
Causes:
• incorrect time (for example, hour = 25) (0)
• failure to read time (1)
• time value not advancing (2)

411-9001-131 18.07 12 March 2010

Post mortem: Specify if the event is sent after a restart or not. The post
mortem values are
• fmNormal (0)
• fmEventSentAfterRestart (1)
Alarm on the clock chip of the active OMU
The Managed Object is: omu.
TROUBLESHOOTING
Replace the faulty chip.
This alarm can only be purged by an ANO_PURGE_PREVIOUS_EVENTS

emitted after an OMU swact.

Fault number:
2023 : Signalling fault
FAULT ANALYSIS
Unused LAPD or SS7 channels of each TMU module are periodically

tested. The "Signalling fault" notification appears when the result of this
test is wrong.
The PcmId, position, and slot number of the faulty TMU module are given
in the notification.
The PmcId (Identifier of the PMC board on the TMU) can be 0 or 1 for a
TMU1 and will always be 0 for a TMU2.
ATTENTION
There is a potential service degradation if less than "n" boards are available (n +
p configuration). Otherwise, there is no impact on service.
TROUBLESHOOTING
On-site maintenance

411-9001-131 18.07 12 March 2010

2.29 Fault number: 2024 (BSC 3000) 77
Replace the TMU module mentioned in the notification.

• Refer to the replacement procedure given in Nortel GSM BSC
3000/TCU 3000 Troubleshooting (411-9001-132).
• The alarm is automatically cleared.

Fault number:
2024 : SPM Download failure
FAULT ANALYSIS
ATTENTION
3000)” (page 150).
Reminder: Control Node, Interface Node and Transcoder Node software

can be upgraded using the OMC-R. The files are downloaded from the
OMC-R to the shared MMS module. Then the Control Node is upgraded.
Then the Interface Node. Then the Transcoder Nodes.
"SPM Download failure" means "SPectruM Download failure". It appears

on Interface Node downloading operation failure. This notification gives:
• the type, position, and slot number of the module
• the name of the file the downloading has failed
For the BSC 3000 cabinet, the Managed Object (MO) is: interfaceNode,
and "hardware transcoder 3G"
None. The service is not lost.
ATTENTION
The module which is pointed out in the notification is not upgraded.
TROUBLESHOOTING
chart.

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

2.29 Fault number: 2024 (BSC 3000) 79

411-9001-131 18.07 12 March 2010


Fault number:
2026 : Observation FTAM: Disk fail
Type : QualityOfService
FAULT ANALYSIS
This notification appears when it is impossible to store a general

permanent observation message on the disk of the BSC 3000.
None. The traffic is not lost.
This alarm will appear on each failed storage attempt of the message.
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010

2.31 Fault number: 2027 (BSC 3000) 81
chart.

Fault number:
2027 : Restart Cause
FAULT ANALYSIS
ATTENTION
This fault number also applies to TCU 3000. See 3.11 “Fault number: 2027
(TCU 3000)” (page 155).
Hardware slot position is not significant if the notification is related to a

code. Otherwise, contains the shelf number (0 or 1) and the slot number (1
to 15) of the module the notification is related to.
Indication of the cause of a node or module restart due to an OMC/TML

request or an internal malfunction.
List of cause values:

411-9001-131 18.07 12 March 2010

• Power on (0)
• Reset command from OMC (1)
• Reset command from TML (2)
• RAZ build (3)
• Upgrade (4)
• Swact when passive supervision module not yet synchronized (5)
• Build error (6)
• Simultaneous restarting of the supervision modules (7)
• Module reset at end of maintenance period (8)
• Critical processing error alarm signal received (9)
• Processing error alarm threshold exceeded (10)
• Module supervision signal lost (11)
• Module application signal lost (12)
• Simultaneous lost of CC1 modules (13)
• Active supervision module flashed (14)
• Module flashed (15)
• Bad module restarting (16)
• OMC-Link failure (17)
• OMU swact due to loss of active one (18)
• Passive OMU reset after IP@ update (19)
• New bscArchitecture (electrical/optical) is taken into account (20)
• NS (Not Significant) (255)
notification.
For the BSC 3000 cabinet, the managed objects (MOs) are: atmRm, cem,
cem3, cc, controlNode, iem, interfaceNode, iom, lsaRc, mmu, omu, tmu,
sw8kRm.
For the BSC 3000 cabinet, the managed objects (MOs) are: atmRm, cem,
cem3, cc, controlNode, iem, igm, interfaceNode, iom, ipgRc, lsaRc, mmu,
omu, tmu, sw8kRm.
No service interruption.

411-9001-131 18.07 12 March 2010

2.32 Fault number: 2028 (BSC 3000) 83
TROUBLESHOOTING

Fault number:
2028 : Restart context
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 156).
This notification appears each time that a board starts correctly after an
insertion, a reset or a restart.
For the BSC 3000 cabinet, the managed objects (MOs) are: controlNode,
interfaceNode, and transcoder, omu, "mmu", tmu, cc cem "srt" "iem’, ’atm".
The board type (see below), position, and slot number of the module are
given in the notification.
• Board type:
— SBC (0) for TMU1 or TMU2
— PMC (1) for TMU1
— TM (2) for TMU1
— (255) not significant
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010


Fault number:
2030 : SPM message error
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 157).
This notification (SPectruM message error) appears when an incorrect

message concerning a Control Node-Interface Node interface or a
TCU-BSC interface is received.
For the BSC 3000 cabinet, the Managed Object (MO) is: interfaceNode
and transcoder
This event probably is the result of a communications protocol error.
TROUBLESHOOTING
Maintenance diagnosis must be performed by manufacturer.

Fault number:
2031 : SPM nack
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 157).
This notification (SPectruM Negative ACKnowledgement) appears when a

NACK is received from an Interface Node.
For the BSC 3000 cabinet, the Managed Object is: interfaceNode and
transcoder.
This event probably is the result of corrupt data detection.

411-9001-131 18.07 12 March 2010

2.35 Fault number: 2032 (BSC 3000) 85
CAUTION
This event may result in a potential capacity loss.
TROUBLESHOOTING
Check CRC coherence with the MIB.

Fault number:
2032 : Miscellaneous SPM alarm
Type : EquipmentAlarm emitted by the IN software
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 158).
The notification gives a description of the anomaly (this description is

provided by the Interface Node).
This notification can appear when another notification originated from the
Control Node appears; the faults corresponding to these notifications are
described in the rest of the document.
For the BSC 3000 cabinet, the managed object (MO) is: interfaceNode or
one of the following sub-objects: atmRm, cem, cem3, cemRc, hsaRc, iem,
iom, lsaRc, pcm, sw8kRm.
For the BSC 3000 cabinet, the managed object (MO) is: interfaceNode or
one of the following sub-objects: atmRm, cem, cem3, cemRc, hsaRc, iem,
igm, iom, ipgRc, lsaRc, pcm, sw8kRm.
notification (when significant).
BSC defense

411-9001-131 18.07 12 March 2010

It depends on the cause of the alarm.
TROUBLESHOOTING
It depends on the description of the anomaly given by the notification in the

Manufacturer Information field. It can be one of the following:
• "AAE TDM Data Path"
— Equipment: ATM
— Action: Replace ATM board if the problem occurs several times.
• "AAL5MsgLoss"
— Equipment: ATM
— AAL5 message loss can be reported in the following cases:
– The PDUs coming from CN are not valid (CRC error or ABORT
bit is set).
– There is a length violation on the PDU coming from CN.
– No free buffers are available to handle the messages.
– Channel information is not valid.
— Actions
Case 1: if the alarm is observed on the passive ATM-RM module,

no action will be performed by the system.
– If this alarm is observed continuously for the passive module
then perform the following actions.
1. Reset the module and observe for some time whether the
alarm is gone permanently or not.
2. Reseat the module if step 1 does not work out and observe
whether the alarm is cleared or not.
3. If step 2 does not work out then replace this ATM-RM with a
known working ATM-RM.
a. If alarm is cleared then the problem was with ATM-RM.
b. If same alarm is coming, then the problem is with
corresponding CC1 and it is to be examined with next
level of support.
Case 2: if the alarm is observed on the active ATM-RM module,

a warm SWACT will be initiated by the system when the passive
ATM-RM module is fault-free and ready to take the activity. The
alarm will be cleared by itself in the next audit performed by
the System (after 30 minutes), if the problem no longer exists.
Connection information (Channel/VPI/VCI) and count of errored

411-9001-131 18.07 12 March 2010

2.35 Fault number: 2032 (BSC 3000) 87
PDUs will be added in the footprint logs for every minute as long
as the problem persists.
• "Activating new load: INSV->SYSB"
— Equipment: all RMs
— Action: No maintenance action is required.
• "AIS alarm"
— Equipment: IEM
— Action: Check the secondary state of carriers. If it is stuck in
"TSTF" state, this can result in "AIS Alarm" on the passive IEM.
• "All IEM RMs exceeded recovery threshold, initiated CEM swact"
— Equipment: CEM
— Action: If swact happens more than one time, it is necessary
either to understand why that protection group does not recover or
remove all the cards from that protection group.
• "Application fault cleared"
— Equipment: ATM
• "Atlas: VC(1,3xxx) AAL1 traffic non-compliant"
— Equipment: ATM
— Action: Call the manufacturer if the problem happens more than
once.
• "ATM Spare triggered by Plane Resolution from active slot "
— Equipment: ATM
— Action: Potential problem with the plan associated to the newly
spare ATM. Call the manufacturer.
• "clock oscillator tuning range has reached 70%"
— Equipment: CEM
— Action: Call the manufacturer to check the quality of the clock on
the network if this problem persists.
— Equipment: CEM
• "Cluster reports out of frame"

411-9001-131 18.07 12 March 2010

— Equipment: All RMs

— Action: Check if no user injected this critical fault on that board, if
not, you have a potential hardware issue on that RM board.
• "Config_Timed_Out By: CarrierMtc"
— Equipment: IEM
— Action: Check if the IEM type match the PCM type on that node. if
yes, call the manufacturer.
• "Double Activity Fault Detected"
— Equipment: IEM
— This cause value indicates that both IEMs of same LSA are "Active"
simultaneously, which is detected by "testDoubleActivity" Diag.
— The "testDoubleActivity" diag is part of the hardware diagnostic. It
checks whether both IEMs of the same LSA are driving the relays.
Only the active IEM is supposed to drive the "relays". If both
IEMs are driving the relays at a time, this indicates there is some
hardware fault on LSA-RC.
— Possible root cause: HW fault on the TIM.
— Action: Replace the TIM. See Nortel GSM BSC 3000/TCU 3000
Troubleshooting (411-9001-132).
• "DS512 LINK STATUS 1: NO_FLT 2: UNPROV 3: UNPROV 4:
UNPROV"
— Equipment: SRT
— Action: Do a "display dynamic data" on the SRT to check if that
DS512 still has an issue. If yes, try to change the optical fiber.
• "Egress Payload RAM Full"
— Equipment: ATM
— Action: Call the manufacturer.
• "Exceeded 0 No test reply from RM"
• "Fail to create AAL1 on RM slot=19"
— Equipment: ATM
— Action: Call the manufacturer if it happens more than once.
• "Fail to delete AAL1 on RM slot=19"
— Equipment: ATM

411-9001-131 18.07 12 March 2010

2.35 Fault number: 2032 (BSC 3000) 89
• "Fail AAL1 Purge to RM slot=19"

— Equipment: ATM
• "Fail BULK Download to RM slot=19"
— Equipment: ATM
• "Fail ClearConfig to RM slot=19"
— Equipment: ATM
• "Flash integrity error detected"
— Equipment: All cards
— Action: If the board already restarted once, call the manufacturer.
• "iem_lsacnx"
— Equipment: IEM
— Action: Check if all cables and connections between the CTU, the
SAI, the TIM card, and the Iems are properly connected.
• "iem_lsacnx: check TIM cable"
— Equipment: IEM
• "Inactive CEM to RM loopback test time-out"
— Action: None. This is just an information notification.
• "Inactive CEM to RM messaging issue cleared"
• "INSV Mate Loading TMO waiting for loading complete"
— Equipment: All boards
— Action: if the problem often occurs, call the manufacturer.
• "INSV->SYSB Inactive CEM to RM message recovery attempt"
• "Invalid Relay State on RM Spare"

411-9001-131 18.07 12 March 2010

— Equipment: IEM
— Action: If the board already restarted once, call the manufacturer
to change the TIM card or IEM.
• "ITM HAL flt while flt hndl off" or "7A: ITM HAL flt while flt hndl off"
— 7A is the slot of the active CEM board that is reporting the fault
— this is a non-critical fault affecting the ITM component (Intelligent
Test Master) on the TRM card.
If it occurs more than once on the same card, call the
manufacturer.
• "Line BERSD"
— Equipment: ATM
Start by cleaning the optical fiber then change that fiber then the
CC1.
• "Line RDI"
— Equipment: ATM
• "Load name mismatch"
— Action: If you see this notification several times on the same board,
the board has not been upgraded properly. Call the manufacturer.
• "LOCAL_ITM_ERR"
— Equipment: CEM
• "Mate system clock signal lost"
— Equipment: CEM
— Action: If fault is not cleared automatically, check that a mate CEM
is present. If yes, change that CEM board.
• "Max Available DS0 4056, … "
— Equipment: SRT
— This cause value provides information related to the maximum
capacity and utilization of the switching matrix:

411-9001-131 18.07 12 March 2010

2.35 Fault number: 2032 (BSC 3000) 91
— "Max Available DS0": represents the call handling capacity of the

switching matrix. Depends on (the DS512) feature activation, either
2268 or 4056.
— "Current DS0 consumption": represents the current usage of the
switching matrix.
— "Max DS0 consumed": represents the peak usage of DS0 in the
metering period (last 24 hours).
— "Avg Consumption Per Hour": represents the average usage of the
switching matrix.
— "Missed DS0 0": represents the number of connections the IN was
not able to handle. Theoretically with the DS512 extension this
should never be different than 0.
— Action: In any case, no maintenance action is required.
• "MC68307 was RESET"
— Equipment: CEM
— Action: Check the quality of the clock on the network, if problems
occurred more than once.
• "No load in flash: Auto mate load from"
• "Node achieved network quality synchronization"
— The cause value indicates that the node has achieved
synchronization, which is not a problem.
— Equipment: CEM
• "No reply from RM during test/message loopback" or "A: No reply from
RM during test/message loopback."
— This cause value indicates that the active cem failed to get a reply
from the RM while running a loopback test on the RM.
• "No test reply from RM"
— Action:
• "Out Of Frame Alarm"

411-9001-131 18.07 12 March 2010

— Equipment: IEM
— Action: If problem persists, change the board, otherwise, it is
probably a bogus fault.
• "Passive CEM: loss of communication with active"
— Equipment: CEM
— The passive CEM loses communication with the active one.
— Action: Most likely passive CEM did reset. One occurrence is not
an issue. If the problem persists, call the manufacturer.
• "PEC name mismatch"
• "Pec Code and Carrier Type mismatch"
— Equipment: IEM
— Action: Remove the board
• "PCM Path: Local Loop"
— Equipment: IEM
— Action: If board reset only once, do nothing. Otherwise, replace
the board.
• "Processor access error" or "8A: Processor access error"
— Equipment: IEM
— This cause value is raised when there is a failure in reading the
Version ID stored in the firmware registers.
— If this notification is seen prior to V15.1.1, then it can be ignored,
unless multiple occurrences are observed and/or the IEM
fails to recover - in which case the replacement of the IEM is
recommended.
— If seen in V15.1.1 or above, please report any failure to the
manufacturer for further investigation.
• "RAM to Flash Restore Failure"
— Action: If the problem often occurs, call the manufacturer.
• "Relay Control Signal Mismatch"
— Equipment: IEM

411-9001-131 18.07 12 March 2010

2.35 Fault number: 2032 (BSC 3000) 93
• "RPOP B3_1PER_G1_1PER_MANYPER"
— Equipment: ATM
• "RM card removed from slot" or "7A: RM card removed from slot"
• "RM diagnostics passed" or "7A: RM diagnostics passed"
— Diagnostics passed on the board.
• "Rm non-critical fault report exceeded 60 second threshold"
— Action: If the problem happens more than once, call the
manufacturer.
• "RM reset reason: Last Gasp" or "A: RM reset reason: Last Gasp"
— This cause value indicates the card reset because RM went into a
bad state due to a software issue. Call the manufacturer for further
information on the reset cause.
manufacturer.
• "RM Test time out"
• "Running load matched datafill"
• "Section LOS"
— Equipment: ATM
• "Section OOF"

411-9001-131 18.07 12 March 2010

— Equipment: ATM
— Action:
• "Section SEF"
— Equipment: ATM
— Action:
• "Slifs Far-end PCM loopback fail"
• "Slifs Near-end PCM loopback fail"
• "Slif-S Parity Errors"
— Equipment: IEM
— Action: Call the manufacturer to isolate the faulty equipment.
• "SLIF-S r/w access failed"
manufacturer.
• "Slink hardware fault detected"
— Action: Try to reset the board. If the problem persists, replace the
board.
• "Slink LoopBack Test Fail"
board.
• "Slink pin stuck - CEM0"
• "Slink state changed to OOS"
• "SPI -MTM Lockout"

411-9001-131 18.07 12 March 2010

2.35 Fault number: 2032 (BSC 3000) 95
— Equipment: all boards

• "SPI port time out"
— Equipment: CEM
• "Srv Sanity audit failure"
— This error is reported when field debug commands are executed
when the RM diagnostics are running. This indicates the Service
Sanity Audit is failed and RM is being reset.
— Action: If the RM has already been reset once, call the
manufacturer.
• "SYNC DAC Error"
— Equipment: CEM
• "sync has entered a holdover condition"
— The IN has entered a holdover condition, and is no longer clocking
of the clocking source.
— Equipment: CEM
• "SYNC Hold/Acq. mode unexp."
— Equipment: CEM
— Action: Check the quality of the clock on the clocking PCMs. Also
change the clock source to a different PCM if this problem persists.
• "SYNC OOSpec: prim. ref. NA."
— This indicates that the active CEM clock has entered a holdover
state.
— Equipment: CEM
• "TIC access protocol violation"
— Equipment: CEM
• "TIC_HAL_CMD_ERROR"

411-9001-131 18.07 12 March 2010

— Equipment: CEM
• "UBC 32 Bit Access"
— Equipment: ATM
— Action: Change the ATM if the problem happens more than once.
• "Unexpected WAI from RM" or "7A: Unexpected WAI from RM"
— The notification with this cause value should be accompanying a
card reset.
— Action: If this card is resetting many times, contact manufacturer.
The card is experiencing spurious signals.
• "VCXO Over 70% of Tuning Range"
— Equipment: CEM
— Equipment: CEM
• "WAS time-out detected"
once.

Fault number:
2033 : Application failure
Type : Quality of Service Alarm
FAULT ANALYSIS
This message follows the crash of a single application.
The notification gives some details on the application when the crash
occurred.
The following data is provided:

411-9001-131 18.07 12 March 2010

2.37 Fault number: 2034 (BSC 3000) 97
• The ID of the crashed task

• The call stack
• The Task Switching History
This data is stored with the manufacturers information and is used to

understand the reason of the crash.
The Type, Position, and Slot Number of the card hosting the failed
application are given in the notification (when significant).
At each startup, all the TRAPINFO records (old and new) are sent to the
OMC-R in 2033 notifications. Please check the TRAPINFO timestamp,
contained in the Manufacturer Info field, to ensure the notification is not
related to an old issue. The TRAPINFO timestamp is not printed in the
notification monitor, please use a notification log to see it.
For the BSC 3000 cabinet, the managed objects (MOs) are: controlNode,
interfaceNode, transcoder.
It depends on the application which crashed.
TROUBLESHOOTING
Maintenance diagnosis must be performed by the manufacturer.

Fault number:
2034 : Upgrade status
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 168).
Perceived severity: WARNING/MINOR/MAJOR/CLEARED

411-9001-131 18.07 12 March 2010

This diagnosis event is sent to the OMC-R to indicate the beginning and
the end of an upgrade procedure and also to indicate the beginning and
the end of a fallback procedure.
This diagnostic event is mapped on the Control Node object.
This diagnosis event is sent as WARNING to OMC-R (for BSC 3000) to

indicate begin/end of the upgrade.
This diagnosis event is sent as MINOR to OMC-R (for BSC 3000) to

indicate begin/end of the fallback.
This diagnosis event is CLEARED when the problem detected by the

upgrade is no more available. It must be purged when a purge event
including this codano is sent on the object this diagnosis event is mapped
on.
This notification gives the BSC upgrade/downgrade state; it appears for

the Control Node in different cases:
• upgrade start (0)
• upgrade end (1)
• fallback start (2)
• fallback end (3)
The order of the notifications 2034 on controlNode and interfaceNode can

change and is not guaranteed. The completion of the IN upgrade can be
received at the OMC-R before the completion of the CN upgrade and
conversely. It depends on the time needed to upgrade TMUs to IN.
If the CN upgrade freezes due to a TMU failure (but after at least one TMU
has been upgraded), the OMC-R receives a 2034 notification even though
the CN is frozen (some TMUs are in release N others are in release N+1).
If the CN remains frozen due to a permanent module failure, the operator
must replace the faulty module to resume the upgrade.
If the IN upgrade fails for any reason, the IN sends a 2034 notification to
the OMC-R and continues the upgrade of IN boards in the background.
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010


Fault number:
2035 : Suspended upgrade
FAULT ANALYSIS
Perceived severity: WARNING/MAJOR/CLEARED
This diagnosis event is sent to the OMC-R to indicate that the running
upgrade action is suspended due to a module failure during the upgrade
sequence.
This diagnostic event is mapped on Control Node object.
This diagnosis event is sent as MAJOR (for BSC 3000) to the OMC-R.
This diagnosis event is CLEARED when the problem detected by upgrade

is no more available. It must be purged when a purge event including this
fault number is sent on the object this diagnosis event is mapped on.
ATTENTION
The Control Node software automatically clears this diagnosis event and restarts
the upgrade sequence if the faulty module becomes operational after a reset
due to an internal defense or to the craft person.
This notification appears for the Control Node after a suspended BSC
upgrade/downgrade.
This notification gives the cause why the upgrade is suspended (in
the PLMNO information field). The cause number, PLMNO cause, and
meaning are shown in the following table.
Table 7
Fault number 2035 causes
Cause
PLMNO cause Meaning
No.
0 Board upgrade failure This is the default freeze cause being sent from
the BSC.
If there is no specific error like the ones given
below, then this would be the cause that would be
sent across the 2035 notification.

411-9001-131 18.07 12 March 2010

Cause
PLMNO cause Meaning
No.
1 OMU upgrade failure This cause is sent if the OMU modules are not
duplex.
This cause would be sent if the passive OMU
didn’t come back after upgrade within the
expected time.
2 CC1 upgrade failure This cause is sent if there is a failed or empty
CC1 module.
3 TMU application not Duplex This cause is sent if the following two conditions
are satisfied:
- one of the SS7 CP’s or non-SS7 CP’s are not
duplex
- the number of upgraded TMUs is less than two.
4 ATM_RM not hot Duplex This cause is sent if the ATM-RM modules are
not hot duplex.
5 CC1 link failure This cause is sent if the CC1 links are not duplex
or if there is an alarm on one of the CC1 links.
7 Permanent Freeze State on This cause is sent if the following two conditions
TMU are satisfied:
- one of the SS7 CP’s or non-SS7 CP’s are not
duplex
- the number of upgraded TMUs is equal to or
more than two.
TROUBLESHOOTING
If there is no fault number 2008 "ANO_HARDWARE_FAILURE", no

maintenance action is required.
If there is a fault number 2008 "ANO_HARDWARE_FAILURE" and the

Managed Object is "Control Node", remove the faulty board.

Fault number:
2037 : Board restart
FAULT ANALYSIS
This notification indicates the restart state of a Control Node board, but for
the interface Node, this fault is not sent.
The managed objects (MOs) (MO) are: omu, tmu or cc.

411-9001-131 18.07 12 March 2010


• the startup step reached by the board specified in the "Restart Cause"
and in the "manufacturer information" of the notifications
• the list of boards detected by the Hardware Management
For a TMU module, a correct startup on a build BSC 3000 is composed

of the following steps.
"Restart Cause" "manufacturer information"

(130) Minimal non--FT platform start of init "Minimal Non FT Platform group -
Start of initialization. Board type: SBC"

(131) Minimal non-FT platform end of init OK "Minimal Non FT Platform group -
end of initialization. Board type: SBC"

(130) Minimal non-FT platform start of init "Minimal Non FT Platform group -
Start of initialization. Board type: PMC1"

end of initialization. Board type: PMC1"

For a passive OMU module, a correct startup on a build BSC 3000 is
composed of the following steps.

(100) Activity group start of init "Activity group - Start of initialization
Board type: SBC"

(103) End of disk mounting OK "Disks mounting performed successfully
(Passive OMU)"


For an active OMU module, a correct startup on a build BSC 3000 is
composed of the following steps.

411-9001-131 18.07 12 March 2010


(100) Activity group start of init "Activity group - Start of initialization
Board type: SBC"

(101) Messaging OMU activity election OK "OMU is ACTIVE"
(103) End of disk mounting OK "Disks mounting performed successfully
(Passive OMU)"


(110) Minimal FT platform start of init
(112) MIB state is NOMINAL
(108) Boards detection OK The detected modules (TMU, CC1, OMU, MMS)
are listed in the "manufacturer information"
(113) Minimal FT platform end of init OK
(117) LB distribution start
For a CC1 module, a correct startup on a build BSC 3000 is composed of
the following steps: (Note that notification with "Restart Cause" (151) Start
of supervision" is on the on the managed object active OMU.)

(151) Start of supervision For CC1 in shelf 01 slot 07:
"Start of CC1 supervision. CC1 position : 231."

For CC1 in shelf 01 slot 08:
"Start of CC1 supervision. CC1 position : 232."

(150) Start
TROUBLESHOOTING

Fault number:
2039 : PCIU AND OR FMU FAILURE
FAULT ANALYSIS

411-9001-131 18.07 12 March 2010

This alarm is emitted when a failure is detected for PCIU or FMU modules
on BSC 3000 frame.
This alarm is cleared when PCIU or FMU modules are operational.
Perceived severity: MAJOR / CLEARED
The Managed Object (MO) is: controlNode
TROUBLESHOOTING

Fault number:
2040 : FEEDER A FAILURE
FAULT ANALYSIS
This alarm is emitted when a failure is detected for power Supply A of

controlNode (power termination A2 on PCIU).
It is cleared when Power Supply A is operational for controlNode.
TROUBLESHOOTING

Fault number:
2041 : FEEDER B FAILURE
FAULT ANALYSIS
This alarm is emitted when a failure is detected for power Supply B of

controlNode (power termination B2 on PCIU).
It is cleared when Power Supply B is operational for controlNode.

411-9001-131 18.07 12 March 2010

TROUBLESHOOTING

Fault number:
2043 : OMU load inconsistency
FAULT ANALYSIS
The managed object is: omu
The software running on the control node raises this alarm when the active
OMU and the passive OMU have different OMU software loads.
BSC defense
No automatic defensive action taken.
If an OMU SWACT occurs while the passive OMU has an incompatible

software load, the BSC will go out of service. If this occurs during an
upgrade, the upgrade may fail.
TROUBLESHOOTING
If this alarm appears during a BSC upgrade, the load mismatch must be
resolved before the upgrade is completed.

Fault number:
2045 : CC1 or TMU or OMU are faulty in a communication
standpoint
FAULT ANALYSIS

411-9001-131 18.07 12 March 2010

In the event of a local node transmission error, this notification indicates

that some CC1, TMU, or OMU are faulty from a communication standpoint.
Perceived severity: WARNING, CLEARED
BSC Defense
None
Status
Status by board and communication path are as shown in the following

table.
Field Meaning
Common PostMortem Specify if the event is sent right after restart of not.
• ? fmNormal (0)
• ? fmEventSentAfterRestart (1)
Hardware slot position The concerned board slot position
Hardware conf Not significant
PLMNO DPLL/VCXO issue Integer type: 0 = no; 1 = yes; 2 = undef; 3 =
(If cc1 object) limit_of_tuning
PHY-A SAR issue Integer type: 0 = no; 1 = yes; 2 = undef
PHY-A SAR issue Integer type: 0 = no; 1 = yes; 2 = undef
Number of faulty PHY-xMU 1 to 18 (2 OMUs, 14 TMUs, 2 CC1)
per faulty Hardware slot Shelf number (0 or 1) and slot number (from 1 to 14)
PHY position of the corresponding xMU
towards
xMU
PLMNO 8kHz status for A plane Integer type: 0 = KO; 1 = OK; 2 = undef
(If xMU
object
8kHz status for B plane Integer type: 0 = KO; 1 = OK; 2 = undef
PHY status for A plane Integer type: 0 = KO; 1 = OK; 2 = undef
PHY status for B plane Integer type: 0 = KO; 1 = OK; 2 = undef
Correlated notification: The associated state changes are directly managed by Sup-CN.
Maintenance action For the xMUs: First change the indicated boards since it is
required impossible to know whether or not the problem is due to potential
backplane connections (backplane degradation).
Troubleshooting

411-9001-131 18.07 12 March 2010

When one board becomes “Enabled”/{Degraded} with the corresponding

ANO_AUTOTEST_CC1, the board needs to be changed at least once
even if there may be a doubt concerning the back-panel. If the same
problem appears after several changes, there can be a justified suspicion
about the back-panel.
When one CC1 becomes “Enabled”/{Degraded} while the other CC1 is

“Disabled”/{Failed} or {not installed} this second CC1 must be replaced
first. If the first CC1 is still declared as “Enabled”/{Degraded} after this
replacement then the first CC1 must also to be changed.
If both CC1 are declared “Enabled”/{Degraded}, it is recommended to

change only one CC1 and check that the unchanged CC1 is still declared
in fault before replacing it. These mutual diagnostics between CC1 can
lead to repeat these "plug and play" type operations until you find the real
issue.

Fault number:
2046 : CONFIGURATION NOT SUPPORTED BY CEM
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 172).
The notification 2046 can be received at the OMC-R in the following cases:
• If the BSC 3000 is optical (the "bscArchitecture" parameter is set to
"bsc30000Optical") and if the IN of the BSC is not equipped with CEM2
or CEM3 (but is equipped with CEM), the IN sends this notification
2046.
• If the BSC 3000 is electrical (the "bscArchitecture" parameter is set to
"bsc30000") and if the IN of the BSC is not equipped with legacy CEM
(but is equipped with CEM2), the IN sends this notification 2046.
•
As a reminder, the following table summarizes the CEM, CEM2, and
CEM3 support cases.
The following table shows the CEM variants that are available for the
electrical and optical configurations of the BSC:

411-9001-131 18.07 12 March 2010

2.45 Fault number: 2046 (BSC 3000) 107
Table 8
CEM, CEM2 and CEM3 support for electrical and optical BSC 3000
Electrical BSC Optical BSC
Legacy CEM Yes No
NTLX82BA
NTLX82BB
CEM No No
NTQE82BB
CEM2 No Yes
NTQE82BC
CEM2 No No
NTLX82BC
(used in wireline)
CEM3 No Yes
NTQE82CA
The Managed Object (MO) is: interfaceNode (IN)
BSC defense
• If the BSC 3000 is optical:
— If the IN is equipped with two CEMs, the IN becomes
disabled/failed and all its children are disabled/dependency.
— If the IN is equipped with one CEM and one CEM2 or CEM3, the
CEM becomes disabled/failed.
• If the BSC 3000 is electrical:
— If the IN is equipped with two CEM2, the IN becomes
disabled/failed and all its children are disabled/dependency.
— If the IN is equipped with one legacy CEM and one CEM2, the
CEM2 becomes disabled/failed.
The two CEM (or CEM2 or CEM3) are redundant.
If only one CEM (or CEM2 or CEM3) is faulty, there is no impact.

411-9001-131 18.07 12 March 2010

CAUTION
If both CEM (or CEM2 or CEM3) are faulty, the service is lost.
TROUBLESHOOTING
Modify the BSC 3000 hardware configuration:

• The electrical BSC 3000 can only be populated with legacy CEM
• The optical BSC 3000 can only be populated with CEM2 (NTQE82BC)
or CEM3 (NTQE82CA).

Fault number:
2047 : OPTICAL FIBER FAILURE
Type : Communication Alarm
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 174)
An optical fiber is reported as faulty if, for FBT (Fault Begin Time)
consecutive seconds, at least one of the following alarms is triggered:
LOF, AIS, CRE, RAI, LLCMA, BER.
The alarm is cleared when no alarm threshold (LOF, AIS, CRE, RAI,
LLCMA, BER) is detected for at least FET (Fault End Time) consecutive
seconds.
When a fault occurs on a fiber linked to the passive IOM:

• A state change “enabled/degraded” and the notification 2047
(OPTICAL_FIBER_FAILURE) is sent on the iom object
• The PCMs are not affected since they are managed by the active IOM
and hence PCMs remain “enabled/online”
When a fault occurs on a fiber linked to the active IOM:

• Moreover, in case the passive IOM is neither "disabled/failed" nor
"enabled/degraded" with a degradation level at least equal to the fault

411-9001-131 18.07 12 March 2010

2.46 Fault number: 2047 (BSC 3000) 109
priority of the active IOM, an automatic IOM switchover (hot standby)

on passive IOM is executed. See Table 9 "IOM degradation levels"
(page 109).
• The PCMs are not affected by a switchover since they are
now managed by the new active IOM and hence PCMs remain
“enabled/online”
Table 9
IOM degradation levels
Carrier Hierarchy Associated degradation level
OC3 / STM1R Degradation level 5
STS3 / STM1M Degradation level 4
STS1 / VC4 Degradation level 3
DS3 Degradation level 2
Special level for clock synchronization Degradation level 1
No fault (see Note 1) / Clear Degradation level 0
Note 1: VT1.5/VC1.2/DS1/E1 do not raise any degradations, and hence
associated IOM degradation level is 0.
The Managed Object (MO) is: iom
BSC defense
An automatic switchover is executed when the 2047 alarm is emitted for a

fiber linked to the active IOM (see Fault analysis).
A fault on the fiber link causes a loss of redundancy when the passive IOM
is functioning normally. If the passive IOM is defective or does not have a
working fiber connection, the PCM connections served by the HSA-RC
are broken.
TROUBLESHOOTING
If an iom object is “disabled/failed”, it means that the IOM module is faulty

(hardware) and must be replaced, see Nortel GSM BSC 3000/TCU 3000
If an iom object is “enabled/degraded”, it means that the optical fiber

attached to this IOM module is faulty. Contact the transmission operator.

411-9001-131 18.07 12 March 2010


Fault number:
2048 : AAL-1 test results
Type : Communication alarm
FAULT ANALYSIS
A notification is sent in the event of a failure of one or more AAL-1 paths

for a TMU.
Perceived severity: MAJOR (if at least one port is confirmed KO);

WARNING (not a confirmed fault); CLEARED (end of fault).
Status

table.
Field Meaning
Common PostMortem Specify if the event is sent right after a restart
or not.
Hardware slot This is the concerned board’s slot position
position
Hardware conf TMU type (1 or 2)
PLMNO Not used
Correlated notification: The attached states change is directly managed by
Sup-CN.
TROUBLESHOOTING
As the hardware (as well as the software) path which is tested is quite long
(TMU_PMC, TMU_TM, Backplane CN, optical OC3 between CN and IN,
ATM_RM, backplane IN, CEM), there are numerous things that may fail.
Particular attention should be focused on TMUs, CC1 and ATM-RM.
Correlations with other results (AAL-5 tests, CN/IN supervision and

associated notifications and alarms, counters) may be useful in this way.
Such notification may be raised temporarily in very rare cases when for
example OC3 links between CN and IN are lost twice while testing the
same port and before the OC3 link fault is seen. In any case, call the
manufacturer.

411-9001-131 18.07 12 March 2010


Fault number:
2049 : AAL-1 ATM plane state
FAULT ANALYSIS
This notification provides information about the state of the two ATM
planes from an AAL-1 viewpoint about clock state, traffic asymmetry and
switch-over.
Perceived severity: MAJOR if at least one plane is KO, potentially with a

switch; CLEARED if the planes are OK.
Status

table.
Field Meaning
Common PostMortem Specify if the event is sent right after a restart
or not.
Hardware slot This is the concerned board’s slot position
position
Hardware conf TMU type (1 or 2)
PLMNO Not used in first step
Correlated notification: The attached states change is directly managed by
Sup-CN.
TROUBLESHOOTING
As the hardware (as well as the software) path which is tested is quite long
(TMU_PMC, TMU_TM, Backplane CN, optical OC3 between CN and IN,
ATM_RM, backplane IN, CEM), there are numerous things that may fail.
Particular attention should be focused on TMUs, CC1 and ATM-RM.
Correlations with other results (AAL-5 tests, CN/IN supervision and

associated notifications and alarms, counters) may be useful in this way.
Such notification may be raised temporarily in very rare cases when for
example OC3 links between CN and IN are lost twice while testing the
same port and before the OC3 link fault is seen. In any case, call the
manufacturer.

411-9001-131 18.07 12 March 2010


Fault number:
2050 : BSC software upgrade status
Type : Notification of end of install
FAULT ANALYSIS
This notification is sent indicating the end of the file transfer and the file
uncompress.
The Managed Object is: BSC (BSC MO is used for BSC events 2050).
Must be CN in further release(CN4?)
Status: OK (0), KO (1), StartInstall (2) StatusReserved1 (3) for future

usage.
In case status = KO, cause of failure: NoMoreDiskSpace (0),

MissingPackage (1),
CorruptedPackage (2),
InstallationFailed (3)
(CauseReserved1 (4),
CauseReserved2 (5) for future usage
package_name: Name (up to 52 character) of the faulty package in case
of missing or corrupted package.
Not Applicable

Fault number:
2053 : BSC MMS DISK SCAN STATUS
FAULT ANALYSIS
The alarm 2053 was created to help the operator follow-up the disk scan
procedure.
To know more about the disk scan procedure, see Nortel GSM BSC
3000/TCU 3000 Troubleshooting (411-9001-132)
The disk scan status can be one of the following (they are indicated in the
"Disk Scan Status" field of the notification):

411-9001-131 18.07 12 March 2010

• (0) "No Scan In Progress", see remark 2 below

• (1) "Scan in Progress", see remark 2 below
• (2) "Scan Aborted", see remark 1 and remark 3 below
• (3) "Scan Performed", see remark 3 below
The causes of the disk scan status are indicated in the "Cause" field of
the notification:
• (0) "Non Significant", see remark 3 below
• (1) "Abort by operator action", see remark 3 below
• (2) "Abort by other actions"
• (3) "Pre-Conditions failed during scan", see remark 1 below
• (4) "Bad Block Issue"
• (5) "Copy failure", see remark 3 below
Remark 1: Before proceeding with the scan of the shared disks, the BSC
makes sure that the system is able to undergo it. This is done by checking
the following conditions:
• the two OMU are duplex
• the two shared MMS are duplex
Accordingly, if one of these conditions is not fulfilled, then the BSC

behavior is as follow: during its execution, the shared disks scan is
immediately aborted. A notification 2053 BSC MMS DISK SCAN STATUS
(state: (2) "Scan aborted", Cause: (3) "Pre-conditions failed during scan",
Scan Result: last scan result) is sent to the OMC-R.
Remark 2: At any time, the operator can get the scan disk status thanks to
the action "Get status" on MMS object. Then the BSC sends a notification
2053 BSC MMS DISK SCAN STATUS (severity: WARNING). It contains
the current status of the MMS object concerned, plus the last complete
scan result. The status possibilities are the following ones:
• (0) "No Scan In Progress": this is the default disk scan status meaning
that no scan is on-going on the equipment.
• (1) "Scan in Progress": this status means that there is a scan in
progress on equipment.
Remark 3: When a scan is in progress, the BSC spontaneously sends

to OMC-R notifications 2053 BSC MMS DISK SCAN STATUS about disk
scan status to help the operator to follow-up the process. There is one
notification per disk. Therefore, for a complete shared disk scan or upon
status request from the operator, two notifications are sent to the operator,

411-9001-131 18.07 12 March 2010

and the disk serial number contained in "Hardware Conf" field of the
notification allows to distinguish between the two disks. The scan status
may take the following states:
• (2) "Scan Aborted"
— If during an on-going disk scan, the pre-conditions are not fulfilled.
This is transient state and the disk scan status is set to (0) "No
Scan In Progress" as soon as the notification 2053 BSC MMS
DISK SCAN STATUS (severity: WARNING, status: (2) "Scan
Aborted", Cause: (3) "Pre-conditions failed during scan", Scan
Result: last scan result) has been sent.
— If a request to abort the disk scan has been received. This is
transient state and the disk scan status is set to (0) "No Scan In
Progress" as soon as the notification 2053 BSC MMS DISK SCAN
STATUS (severity: WARNING) status: (2) "Scan Aborted", Cause:
(1) "Abort by operator action", Scan Result: last scan result) has
been sent.
— If the copy failed. This is transient state and the disk scan status is
set to (0) "No Scan In Progress" as soon as the notification 2053
BSC MMS DISK SCAN STATUS (severity: MAJOR) state: (2)
"Scan Aborted", Cause: (5) "Copy failure", Scan result: last scan
result) has been sent.
• (3) "Scan Performed" is set as soon as the disk scan is done with
success. This is transient state and the disk check is set to (0) "No
Scan In Progress" as soon as the notification 2053 BSC MMS DISK
SCAN STATUS (severity: WARNING) state: (3) "Scan Performed",
Cause: (0) "Non Significant", Scan Result: new scan result) has been
sent.
Perceived severity: MAJOR (if bad blocks are not relocated), WARNING,
CLEARED
The Managed Object (MO) is: MMS
BSC defense
None.
None.
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010


Fault number:
2060 : Abis Ethernet link failure
FAULT ANALYSIS
The managed object is: igm
The IGM sends this notification when the Ethernet driver on Abis Ethernet
port detects that physical signal is no longer present. It is cleared when
physical signal comes back
BSC defense
If the fault occurs on the active IGM, the BSC takes the following defensive
actions:
1. If passive IGM is Disabled, no defense action is taken.
2. if passive IGM is Enabled / Online:
a. IGM sparing : the BSC performs a SWACT to make the passive
IGM active and the active IGM becomes passive
b. If HSA 0 is connected to IPG, HSA 0 sparing occurs (passive IOM
becomes active)
c. If HSA 1 is connected to IPG, HSA 1 sparing occurs (passive IOM
becomes active)
d. No further defensive action is taken.
The BSC always resets any active IOM even if the passive IOM is not
enabled.
3. If passive IGM is Enabled / Degraded
— If Abis Ethernet link is OK on passive IGM, same defense action
as 2b.
— If Abis Ethernet link is KO on passive IGM, no defense action.
If the fault occurs on the passive IGM, no defensive action is taken.

411-9001-131 18.07 12 March 2010

The state of the affected IGM changes to Enabled / Degraded.
TROUBLESHOOTING
1. Check the status of the physical device to which the Ethernet port is
connected (switch, router, or hub). If the device is failed or if there is a
failure on the corresponding port, take corrective action.
2. Check the connection medium between the IGM and the Ethernet
device (switch, router, or hub). If the connection medium has failed,
repair or replace it.
3. Replace the IGM
The alarm is cleared when the fault condition no longer exists.

Fault number:
2061 : Traffic aggregation Ethernet link failure
FAULT ANALYSIS
The IGM sends this notification when the Ethernet driver on Aggregate
Ethernet port detects that the physical signal is no longer present.
Notification is managed only if ipAggregateEthernetPortUsed parameter on
IPGRC object is set to “used.” It is cleared when physical signal comes
back.
BSC defense
actions:
becomes active)

411-9001-131 18.07 12 March 2010


becomes active)
enabled.
3. If passive IGM is Enabled / Degraded, no defense action.
as 2b.
TROUBLESHOOTING
3. Replace the IGM

Fault number:
2062 : IBOS Ethernet link failure
FAULT ANALYSIS
The IGM sends this notification when the Ethernet driver on the IBOS
Ethernet port detects that the physical signal is no longer present.
Notification is managed only if ipIBOSEthernetPortUsed parameter on
IPGRC object is set to “used.” It is cleared when physical signal comes
back.

411-9001-131 18.07 12 March 2010

BSC defense
actions:
becomes active)
becomes active)
enabled.
as 2b.
TROUBLESHOOTING
3. Replace the IGM

411-9001-131 18.07 12 March 2010


Fault number:
2063 : IGM-IPM connection error
FAULT ANALYSIS
An error has occurred on the interface between an IGM and an IPM:

• an IPM has NACK a message sent by an IGM
• an incorrect message has been received from an IPM (formatting error,
unexpected message)
• IGM receives ipmUnknownMessage from IPM
PLMNO identifies the error (message and cause).
Incorrect message is provided in the MANU INFO.
Cause codes:
The cause codes for this alarm are as shown in the following table.
1 ipTdmConfigRspNack BTS PCM number out of range

2 ipTdmConfigRspNack BSC PCM number out of range
3 ipTdmConfigRspNack socket creation failure
10 ipTdmDisconfigRspNack BTS PCM number out of range
11 ipTdmDisconfigRspNack BSC PCM number out of range
12 ipTdmDisconfigRspNack PCM not configured
13 ipTdmDisconfigRspNack parameter inconsistency
20 ipTdmStartNack - BTS PCM number out of range
21 ipTdmStartNack - BSC PCM number out of range
22 ipTdmStartNack PCM not configured
23 ipTdmStartNack parameter inconsistency
30 ipTdmStopNack - BTS PCM number out of range
31 ipTdmStopNack - BSC PCM number out of range
32 ipTdmStopNack parameter inconsistency
40 ipIpmSynchroConfigNack wrong synchro mode

411-9001-131 18.07 12 March 2010

41 ipIpmSynchroConfigNack uplink synchro flow not supported

42 ipIpmSynchroConfigNack wrong uplink synchro flow activation
50 ipIpmCompressionConfigNack wrong compression mode
60 ipIpmPDVConfigNack wrong IP self tunning
61 ipIpmPDVConfigNack parameter inconsistency
100 incorrect message received from IPM unknown message
101 incorrect message received from IPM out of sequence message
102 incorrect message received from IPM parameter inconsistency
103 incorrect message received from IPM format error
110 IPM has received an unknown message from IPG (ipmUnknownMessage
sent by IPM)
BSC defense
None
None
TROUBLESHOOTING
No troubleshooting required.

Fault number:
2064 : IPM reset request
FAULT ANALYSIS
A reset request command has been sent to an IPM
BSC defense
None

411-9001-131 18.07 12 March 2010

None
TROUBLESHOOTING
No troubleshooting required.

Fault number:
2065 : Optical fiber failure port 0
FAULT ANALYSIS
An Optical fiber is reported as faulty if, for FBT (fault begin time)
LLCMA, BER) is detected for at least FET (fault end time) consecutive
seconds.
BSC defense
actions:
becomes active)
becomes active)

411-9001-131 18.07 12 March 2010

enabled.
— If port 0 optical link is OK on passive IGM, same defense action
as 2b.
— If port 0 optical link is KO on passive IGM, no defense action.
TROUBLESHOOTING
1. Check the status of the physical device to which the optical port
is connected. If the device is failed or if there is a failure on the
corresponding port, take corrective action.
2. Check the connection medium between the IGM and the remote
device. If the connection medium has failed, repair or replace it.
3. Replace the IGM

Fault number:
2066 : Optical fiber failure port 1
FAULT ANALYSIS
An Optical fiber is reported as faulty if, for FBT (fault begin time)
LLCMA, BER) is detected for at least FET (fault end time) consecutive
seconds.

411-9001-131 18.07 12 March 2010

BSC defense
actions:
becomes active)
becomes active)
enabled.
— If port 1 optical link is OK on passive IGM, same defense action
as 2b.
— If port 1 optical link is KO on passive IGM, no defense action.
TROUBLESHOOTING
1. Check the status of the physical device to which the optical port
is connected. If the device is failed or if there is a failure on the
corresponding port, take corrective action.
2. Check the connection medium between the IGM and the remote
device. If the connection medium has failed, repair or replace it.
3. Replace the IGM

411-9001-131 18.07 12 March 2010


Fault number:
2067 : IGM-IPM service channel failure
FAULT ANALYSIS
Notification sent by IGM to manage IPM supervision; sent each time

• an IPM is authenticated by IBOS but is not reachable from IGM
• an IPM supervision failure (using ipStatusReq/Rsp) occurs
The notification contains a list of unreachable IPM units, with the

corresponding btsSiteManager ID for each IPM. The list can hold a
maximum of 100 IPM. If there are 101 or more unreachable IPM, the
Truncation Status field is set to 01, which signifies that the list has been
truncated.
Notification is raised as major when

• a new IPM is declared not reachable from IGM; in this case, IPM is
added to the list
• a IPM is declared reachable but there is still at least one IPM which is
not reachable; in this case, IPM is removed from the list
Notification is cleared when there are no more IPM authenticated by IBOS

which are not reachable from IGM.
BSC defense
None
The PCM links carried by this IGM-IPG pair are unavailable.
TROUBLESHOOTING
From the IPM TML, attempt to ping the unreachable IPM. If the you can
ping the IPM from the OMC-R but not from the IPM, check for IP network
faults between the BSC and the BTS. If the OMC-R can still communicate

411-9001-131 18.07 12 March 2010

2.59 Fault number: 2068 (BSC 3000) 125
with the IPM, check the operational and administrative status of the IPM
and note any other active alarms. If the OMC-R cannot communicate with
the IPM, it may be necessary for a technician to visit the remote site and
verify the status and configuration of the IPM by use of the TML and visual
inspection of the LEDs.

Fault number:
2068 : Optical link failure - port 0
FAULT ANALYSIS
ATTENTION
(TCU 3000)” (page 177)
This fault indicates a failure on the first fiber connected on the CEM3
through the port 0.
seconds.
When a fault occurs on a fiber linked to the passive CEM3:

• A state change “enabled/degraded” is sent on the cem3 object.
• The notification 2068 (OPTICAL_FIBER_FAILURE_PORT_0) is sent
on the cem3 object
• The notification 2069 (OPTICAL_FIBER_FAILURE_PORT_1 - in V18
only) is sent on the cem3 object
• The PCMs are not affected since they are managed by the active
CEM3 and hence PCMs remain “enabled/online”
When a fault occurs on a fiber linked to the active CEM3:

on the cem3 object

411-9001-131 18.07 12 March 2010

• Moreover, in case the passive CEM3 is neither "disabled/failed" nor

"enabled/degraded" with a degradation level at least equal to the
fault priority of the active CEM3, an automatic CEM3 switchover (hot
standby) on passive CEM3 is executed. See CEM3 degradation levels.
• The PCMs are not affected by a switchover since they are now
managed by the new active CEM3 and hence PCMs remain
“enabled/online”.
Table 10
CEM3 degradation levels
OC12 / STM4R Degradation level 5 (initiates
Automatic Protection Switch (APS))
STS12 / STM4M Degradation level 4 (initiates APS)
No fault/Clear Degradation level 0
Perceived severity: MAJOR / MINOR/CLEARED
The severity is major if the fault is global to the fiber: the whole traffic is
impacted.
The severity is minor if the fault is partial: only a part of the traffic is
impacted.
The Managed Object (MO) is: cem3.
BSC defense
An automatic switchover is executed when the 2068 alarm (or 2069 in V18
only) is emitted for a fiber linked to the active CEM3 (see Fault analysis).
A fault on the fiber link causes a loss of redundancy when the passive
CEM3 is functioning normally. If the passive CEM3 is defective or does
not have a working fiber connection, the PCM connections served by the
CEM3 are broken.
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010

2.60 Fault number: 2069 (BSC 3000) 127
If a cem3 object is “disabled/failed”, it means that the CEM3 module is

faulty (hardware) and must be replaced, see Nortel GSM BSC 3000/TCU
3000 Troubleshooting (411-9001-132).
If a cem3 object is “enabled/degraded”, it means that the optical fiber

attached to this CEM3 module is faulty. The notifications 2068 and 2069
(in V18 only) are sent. Contact the transmission operator.

Fault number:
FAULT ANALYSIS
ATTENTION
This fault does not apply to V17, but only to V18.
ATTENTION
(TCU 3000)” (page 179)
This fault indicates a failure on the second fiber connected on the CEM3
through the port 1.
seconds.

on the cem3 object

411-9001-131 18.07 12 March 2010


on the cem3 object
Table 11
OC12 / STM4R Degradation level 5 (initiates
Automatic Protection Switch (APS))
impacted.
impacted.
BSC defense

411-9001-131 18.07 12 March 2010

2.60 Fault number: 2069 (BSC 3000) 129
CEM3 are broken.
TROUBLESHOOTING



411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

131
.
Chapter 3 TCU 3000 fault numbers

3.1 Fault number: 2000 (TCU 3000)
Fault number:
2000 : Power failure
FAULT ANALYSIS
ATTENTION
This fault number also applies to BSC 3000. See 2.8 “Fault number: 2000 (BSC
3000)” (page 25).
This notification can appear in two different cases:

• after a period of normal operating (only after reset of the module)
• on board insertion and incorrect MIM reading
notification.
The managed objects (MOs) are: transcoder, "lsaRcTcu", "trm", cem3.
The modules involved can be one of the following:

• in the controlNode:
— OMU module
— MMS module
— TMU module
— ATM-SW module (CC1 module)
• in the interfaceNode:
— ATM-RM module
— CEM module

411-9001-131 18.07 12 March 2010

132 Chapter 3 TCU 3000 fault numbers
— 8K-RM module (SRT-RM module)

— IEM module

normal operating
CAUTION
Case of the TMU module (with n+p configuration)
ATTENTION
Case of OMU module or its private MMS

In the case of a fault on the passive OMU module, redundancy is lost.
Case of ATM-SW and ATM-RM modules
These modules are redundant.
CAUTION
If one ATM-SW module is involved, as soon as another module
(ATM-SW or ATM-RM associated) gets involved, service is lost.
Case of the other modules (CEM, 8K-RM, IEM)
The other modules are redundant.
If the first module is involved, there is no impact on service.

411-9001-131 18.07 12 March 2010

3.2 Fault number: 2001 (TCU 3000) 133
CAUTION
TROUBLESHOOTING
Step Action
Preliminary checks
1 Perform a "Display all" or "Display chain information" command
to check the state of the modules.
On-site maintenance
2 Replace the module mentioned in the notification. The red LED
of the faulty module is on.
a Refer to the replacement procedure given in Nortel GSM BSC
3000/TCU 3000 Troubleshooting (411-9001-132):
• modules located in the Control Node:
— OMU module
— Shared MMS module
— Private MMS module
— TMU module
— ATM-SW module
• modules located in the Interface Node:
— ATM-RM module
— CEM module
— 8K-RM module
— IEM module
b The alarm is automatically cleared.

--End--

Fault number:
2001 : Hardware not supported
FAULT ANALYSIS

411-9001-131 18.07 12 March 2010

ATTENTION
This fault number also applies to BSC 3000. See 2.9 “Fault number: 2001 (BSC
3000)” (page 31).
This notification appears in two cases:

• the hardware release of the inserted module is too recent in
comparison with the present software
• the hardware release of the inserted module is no longer supported by
the present software
It also appears after a TCU software upgrade: the hardware release of a

module is no longer supported.
The Managed Object is: "hardware transcoder 3G".
The type, position and the slot number of the module are given in the
notification.
The modules concerned can be one of the following:

• LSA module
• TRM module
• CEM module
TCU defense
None.
TROUBLESHOOTING
Step Action
Preliminary checks
1 Identify the problem:
• obsolete module: the module is no longer supported by the
current TCU software version. Go to step 2.
• recent module: the module is too recent to be supported by
the current TCU software: perform an upgrade of the TCU.
Go to step 3.
On-site maintenance
2 Replace the equipment mentioned in the notification.

411-9001-131 18.07 12 March 2010

3.3 Fault number: 2008 (TCU 3000) 135
a Refer to the replacement procedure given in Nortel GSM BSC

3000/TCU 3000 Troubleshooting (411-9001-132). The red
LED of the faulty module is on:
• IEM module
• TRM module
• CEM module
b The operations for return to service are performed by the

system.
3 Perform an upgrade of the TCU.
Additional checks
--End--

Fault number:
2008 : Hardware failure
FAULT ANALYSIS
ATTENTION
This fault number also applies to BSC 3000. See 2.14 “Fault number: 2008
(BSC 3000)” (page 44).
This notification appears each time the Hardware Management detects a

hardware failure.

• it specifies if the event is sent right after a restart or not
• it contains the shelf number (0 or 1) and the slot number (from 1 to 15)
of the faulty module
• it contains the following data if it is available:
— serial number
— PEC number of the IEM board
— the hardware release

411-9001-131 18.07 12 March 2010

ATTENTION
If the software application is not able to determine which component is faulty,
one or two modules which might be impacted by the failure can also appear in
the notification.
For the TCU 3000 cabinet, the managed objects (MOs) (MO) are:
"hardware transcoder 3G", cem, "lsaRc", iem, "trm", cem3.
The elements involved can be any of the following:

• in the frame assembly:
— cooling unit
— PCIU assembly
— inter control card link
• in the Transcoder Node:
— IEM module
— TRM module
— CEM module
If the first module is involved, there is not any impact on service.
CAUTION
When the second module is involved, the service is lost.
TROUBLESHOOTING
Preliminary checks
Perform a "Display all" or "Display" command to check the state of the

modules.
On-site maintenance
Replace the module mentioned in the notification. The red LED of the
faulty module is on.
3000/TCU 3000 Troubleshooting (411-9001-132):

411-9001-131 18.07 12 March 2010

3.4 Fault number: 2009 (TCU 3000) 137
— IEM module
— TRM module
— CEM module
— SIM module
• The alarm is automatically cleared.
Additional checks
The procedure is complete.

Fault number:
2009 : PCM failure
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 51).
A PCM link is faulty if any of the following alarms are triggered for FBT
(Fault Begin Time) consecutive seconds: LOS, AIS, LFA, FE, CRC, RAI,
E-Bits.
The alarms are listed by priority, from the highest (LOS) to the lowest
(E-Bits).
An alarm is cleared when no alarm threshold (LOS, AIS, LFA, FE, CRC,
RAI, E-bits) is detected for at least FET (Fault End Time) consecutive
seconds.
The Managed Object (MO) is pcmCircuit.
This notification provides the following information:

• it specifies whether the event is sent right after a restart or not
• it contains the shelf number (from 0 to 1) hosting the LSA-RC
connecting the PCM and its position within the shelf (from 1 to 15)
• it contains the type of PCM: E1 or T1
• it contains the threshold value:

411-9001-131 18.07 12 March 2010

— FBT value if alarm severity is major

— FET value if alarm severity is cleared
• the time elapsed in faulty state: this information is significant when the
severity is cleared.
• the length of time the alarms are triggered (in seconds):
— the length of time the LOS alarm is triggered (nd_sec_LOS)
— the length of time the AIS alarm is triggered (nd_sec_AIS)
— the length of time the LFA alarm is triggered (nd_sec_LFA)
— the length of time the FE alarm is triggered (nd_sec_FE). This
number is not significant for T1.
— the length of time the CRC alarm is triggered (nd_sec_CRC)
— the length of time the RAI alarm is triggered (nd_sec_RAI)
— the length of time the E-Bits alarm is triggered (nd_sec_E-Bits)
At the given time, if multiple alarms are detected, only the alarm with the
highest priority is logged.
In this case, for example, the alarm is raised with the following values for
the different errors:
• nd_sec_LOS=3 seconds
• nd_sec_AIS=1 second
• nd_sec_LAF=2 seconds
• nd_sec_FE=1 second
• nd_sec_CRC=1 second
• nd_sec_RAI=0 second
• nd_sec_E-Bits=1 second
The reaction of the system depends on the type of PCM links (Ater or A).
TROUBLESHOOTING
chart.

411-9001-131 18.07 12 March 2010

3.4 Fault number: 2009 (TCU 3000) 139

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

3.4 Fault number: 2009 (TCU 3000) 141

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

3.4 Fault number: 2009 (TCU 3000) 143

411-9001-131 18.07 12 March 2010

Table 12
Relation between the A PCM E1 link number and the LSA-RC/CTU module in use located in
the TCU 3000
Logical PCM number
LSA 0 shelf LSA 1 shelf LSA 2 shelf LSA 3 shelf
CTU 3 up CTU 0 up CTU 1 up CTU 2 up
Physical port number
on a LSA-RC module CTU 7 down CTU 4 down CTU 5 down CTU 6 down
20 0 16 32 48
19 1 17 33 49
18 2 18 34 50
| | | | |
| | | | |
| | | | |
6 14 30 46 62
5 15 31 47 63
4 N/A N/A 64 65
Table 13
Relation between the A PCM T1 link number and the LSA-RC/CTU module in use located in
the TCU 3000
Logical PCM number
LSA 0 shelf LSA 1 shelf LSA 2 shelf LSA 3 shelf
CTU 3 up CTU 0 up CTU 1 up CTU 2 up
Physical port number
on a LSA-RC module CTU 7 down CTU 4 down CTU 5 down CTU 6 down
27 0 22 44 66
26 1 23 45 67
25 2 24 46 68
| | | | |
| | | | |
| | | | |
7 20 42 64 86
6 21 43 65 87

411-9001-131 18.07 12 March 2010

3.5 Fault number: 2010 (TCU 3000) 145
Table 14
Relation between the STM1 A virtual PCM number and the HSA-RC module in use located in
the optical TCU
Logical PCM number
Virtual port number on a HSA-RC
module HSA 0 HSA 1
62 0 49
61 1 50
60 2 51
| | |
| | |
| | |
15 47 96
14 48 97
Table 15
Relation between the OC3 A virtual PCM number and the HSA-RC module in use located in
the optical TCU
Logical PCM number
Virtual port number on a HSA-RC
module HSA 0 HSA 1
83 0 66
82 1 67
81 2 68
| | |
| | |
| | |
19 64 130
18 65 131

Fault number:
2010 : ISIMA failure
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 62).

411-9001-131 18.07 12 March 2010

Diagnostic event ANO_ALIMA_FAILURE is sent as Major (for TCU 3000)

to the OMC-R, when the Transcoder Node [shelf0/slot15] "ALIM" module is
either not present, or extracted, or faulty (the Transcoder Node software
can not distinguish these cases).
This diagnostic event is mapped on the Transcoder Node object and is

cleared when its cause is removed. This diagnostic event is purged when
a purge event including its fault number is sent to the object which is
mapped with the diagnostic event.
A state change on the hardware transcoder 3G object occurs when the

alarm 2010 is raised at the OMC-R : the operationalState is still "enabled",
but the availabilityStatus becomes "degraded".
TROUBLESHOOTING


Fault number:
2011 : ISIMB failure
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 63).
Diagnostic event ANO_ALIMB_FAILURE is sent as Major (for TCU 3000)

to the OMC-R, when the Transcoder Node [shelf1/slot15] "ALIM" module is
either not present, or extracted, or faulty (the Transcoder Node software
can not distinguish these cases).

411-9001-131 18.07 12 March 2010

3.7 Fault number: 2014 (TCU 3000) 147


TROUBLESHOOTING


Fault number:
2014 : IFan failure
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 65).
Diagnostic event ANO_FAN_FAILURE is sent as Major (for TCU 3000) to

the OMC-R, when a "Cooling Unit" failure is detected on the Transcoder
Node.
This alarm is emitted as soon as one of the FANs is in failure or when at

least one FAN is extracted. It is cleared when all the FANs are operational.

411-9001-131 18.07 12 March 2010



TROUBLESHOOTING

• If a FAN is extracted, insert it.
• In other cases, check each FAN and replace the faulty one(s). Refer
to its procedure in Nortel GSM BSC 3000/TCU 3000 Troubleshooting
(411-9001-132).

Fault number:
2019 : Synchronizing PCM indication
Type : Communications alarm
FAULT ANALYSIS
This fault number also applies to BSC 3000. See 2.24 “Fault number:
2019 (BSC 3000)” (page 70).
Perceived severity: CRITICAL/CLEARED/WARNING
Reminder: A Transcoder Node can be synchronized on:

• a PCM port (among the six synchronizer PCM ports of LSA 0)
• a local clock (internal to the node)
The Transcoder Node selects the best synchronization source among

the possible PCM synchronizer ports and optical ports. The TCU will
preferably synchronize on optical ports.. If it detects a clock instability, it
selects another PCM synchronizer port among the remaining five possible
PCM ports. If none of the optical ports or the six possible synchronizer

411-9001-131 18.07 12 March 2010

3.8 Fault number: 2019 (TCU 3000) 149
ports are suitable, the Transcoder Node selects the local clock as a
synchronization source (the local clock is provided by the active CEM
module).
This notification can appear in two different cases:

• after the restart of the relevant equipment (no maintenance action is
required)
• on a change of the PCM synchronization source (possible sources are
all the possible synchronizer PCM ports and the local clock)
This notification provides the following information on the event and its
causes:
• due to restart or not
• synchronization type (on a PCM port, on the local clock)
• synchronizer PCM port number (if any)
• the HSA-RC number (or 0xFFFF if no HSA-RC is providing a clock
reference)
The perceived severity depends on the previous clock and newly selected
clock:
• Severity is set to MAJOR when the local clock is selected.
• Severity is set to CLEARED when the system was synchronized to its
local clock and selects a PCM clock.
• Severity is set to WARNING when the clock is selected from another
PCM.
ATTENTION
A CLEARED notification can occur before a new clock notification on the first
clock change after an TMU restart.
None (due to the smooth clock-switching device).
TROUBLESHOOTING
chart.

411-9001-131 18.07 12 March 2010


Fault number:
2024 : SPM Download failure
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 77).

411-9001-131 18.07 12 March 2010

3.9 Fault number: 2024 (TCU 3000) 151
Reminder: Control Node, Interface Node and Transcoder Node software

can be upgraded using the OMC-R. The files are downloaded from the
OMC-R to the shared MMS module of the BSC 3000. Then the Control
Node is upgraded. Then the Interface Node. Then the Transcoder nodes.
"SPM Download failure" means "SPectruM Download failure". It appears

on Transcoder Node downloading operation failure. This notification gives:
• the type, position, and slot number of the module
• the name of the file the downloading has failed.
The managed objects (MOs) is: "hardware transcoder 3G".
None. The Service is not lost.
ATTENTION
The module which is pointed out in the notification is not upgraded.
TROUBLESHOOTING
chart.

411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

3.9 Fault number: 2024 (TCU 3000) 153

411-9001-131 18.07 12 March 2010


Fault number:
2025 : Level 2 TEI
FAULT ANALYSIS
This notification can appear when a TCU 3000 remote level2 is lost.
The Managed Object is: “G3transcoderEqp”
Case of an ATER PCM: possible redundancy without service interruption

(if other LAPD circuit available).
TROUBLESHOOTING
The operator has to take into account the other information that has
appeared (faults on IEMs, TMUs, PCMs).

411-9001-131 18.07 12 March 2010

3.11 Fault number: 2027 (TCU 3000) 155

Fault number:
2027 : Restart cause
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 81).
Hardware slot position is not significant if the notification is related to a

code. Otherwise, contains the shelf number (0 or 1) and the slot number (1
to 15) of the module the notification is related to.
Indication of the cause of a node or module restart due to an OMC/TML

request or an internal malfunction.
notification.
List of cause values:

• Power on (0)
• Reset command from OMC (1)
• Reset command from TML (2)
• RAZ build (3)
• Upgrade (4)
• Swact when passive supervision module not yet synchronized (5)
• Build error (6)
• Simultaneous restarting of the supervision modules (7)
• Module reset at end of maintenance period (8)
• Critical processing error alarm signal received (9)
• Processing error alarm threshold exceeded (10)
• Module supervision signal lost (11)
• Module application signal lost (12)
• Simultaneous lost of CC1 modules (13)
• Active supervision module flashed (14)

411-9001-131 18.07 12 March 2010

• Module flashed (15)

• Bad module restarting (16)
• OMC-Link failure (17)
• OMU swact due to loss of active one (18)
• Passive OMU reset after IP@ update (19)
• New transcoderArchitecture (electrical/optical) is taken into account
(20)
• NS (Not Significant) (255)
The managed objects (MOs) are: "hardware transcoder 3G", cem, iem,
iom, "trm", cem3.
TROUBLESHOOTING

Fault number:
2028 : Restart context
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 83).
This notification appears each time that a board starts correctly after an
insertion, a reset or a restart.
For the TCU 3000 cabinet, the Managed Object is: transcoder.
The board type, position, and slot number of the module are given in the
notification.

411-9001-131 18.07 12 March 2010

3.14 Fault number: 2031 (TCU 3000) 157
TROUBLESHOOTING

Fault number:
2030 : SPM message error
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 84).
This notification (SPectruM message error) appears when an incorrect

message concerning a Control Node-Interface Node interface or a TCU
3000-BSC 3000 interface is received.
This event probably is the result of a communications protocol error.
CAUTION
This event may result in a loss of service.
TROUBLESHOOTING

Fault number:
2031 : SPM nack
FAULT ANALYSIS

411-9001-131 18.07 12 March 2010

ATTENTION
(BSC 3000)” (page 84).
This notification (SPectruM Negative ACKnowledgement) appears when a

NACK is received from a Transcoder Node.
The Managed Object is: interfaceNode, "hardware transcoder 3G".
This event probably is the result of corrupt data detection.
CAUTION
This event may result in a loss of service.
FAULT TREATMENT

Fault number:
2032 : Miscellaneous SPM alarm
Type : EquipmentAlarm emitted by the Transcoder node
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 85).
The notification gives a description of the anomaly (this description is

provided by the Transcoder node).
The Managed Object is: "hardware transcoder 3G" or one of the following
sub-objects: cem, iem, iom, pcm, hsaRc, trm, lsaRc, cemRc, cem3.
notification (when significant).

411-9001-131 18.07 12 March 2010

3.15 Fault number: 2032 (TCU 3000) 159
BSC defense
It depends on the cause of the alarm.
TROUBLESHOOTING
It depends on the description of the anomaly given by the notification in the

Manufacturer Information field. It can be one of the following:
• "8A: Arch1 HARD_ERROR"
— This indicates a dsp trap.
— 8A is the slot of the active CEM board that is reporting the fault.
— arch is the archipelago number on the TRM that is reporting the
fault.
— Call the manufacturer.
• "Activating new load: INSV->SYSB"
• "AIS alarm"
— Equipment: IEM
— Action: Check the secondary state of carriers. If it is stuck in
"TSTF" state, this can result in "AIS Alarm" on the passive IEM.
• "All IEM RMs exceeded recovery threshold, initiated CEM swact"
— Equipment: CEM
— Action: If swact happens more than one time, it is necessary
either to understand why that protection group does not recover or
remove all the cards from that protection group.
• "Arch1 HAL_ERROR"
— Equipment: TRM
fault.
— Action: If the problem persists after a reset of the board, change
the board.
• "8A: Arch2 HARD_ERROR"
— This indicates a dsp trap.
— 8A is the slot of the active CEM board that is reporting the fault.

411-9001-131 18.07 12 March 2010


fault.
— Call the manufacturer.
• "Arch2 HARD_ERROR T-410-10-3"
— Equipment: TRM
fault.
• "Arch3 TIMEOUT_RSP"
— Equipment: TRM
fault.
— Action: If the problem persists after a reset of the board, change
the board.
• "ARCHI_CONFIG_FAILED CONFIG "
— Equipment: TRM
fault.
once.
— Equipment: CEM
— Equipment: CEM
• "Cluster reports out of frame"
— Action: Check if no user injected this critical fault on that board, if
not, you have a potential hardware issue on that RM board.
• "Config_Timed_Out By: CarrierMtc"
— Equipment: IEM
— Action: Check if the IEM type match the PCM type on that node. if
yes, call the manufacturer.

411-9001-131 18.07 12 March 2010

3.15 Fault number: 2032 (TCU 3000) 161
• "Double Activity Fault Detected"

— Equipment: IEM
— This cause value indicates that both IEMs of same LSA are "Active"
simultaneously, which is detected by "testDoubleActivity" Diag.
— The "testDoubleActivity" diag is part of the hardware diagnostic. It
checks whether both IEMs of the same LSA are driving the relays.
Only the active IEM is supposed to drive the "relays". If both
IEMs are driving the relays at a time, this indicates there is some
hardware fault on LSA-RC.
— Possible root cause: HW fault on the TIM.
— Action: Replace the TIM. See Nortel GSM BSC 3000/TCU 3000
• "Exceeded 0 No test reply from RM"
• "Flash integrity error detected"
• "iem_lsacnx"
— Equipment: IEM
• "iem_lsacnx: check TIM cable"
— Equipment: IEM
• "Inactive CEM to RM loopback test time-out"
• "Inactive CEM to RM messaging issue cleared"
• "INSV Mate Loading TMO waiting for loading complete"
— Action: if the problem often occurs, call the manufacturer.

411-9001-131 18.07 12 March 2010

• "INSV->SYSB Inactive CEM to RM message recovery attempt"

• "Invalid Relay State on RM Spare"
— Equipment: IEM
— Action: If the board already restarted once, call the manufacturer
to change the TIM card or IEM.
• "ITM HAL flt while flt hndl off" or "7A: ITM HAL flt while flt hndl off"
— this is a non-critical fault affecting the ITM component (Intelligent
Test Master) on the TRM card.
If it occurs more than once on the same card, call the
manufacturer.
• "Load name mismatch"
— Action: If you see this notification several times on the same board,
the board has not been upgraded properly. Call the manufacturer.
• "LOCAL_ITM_ERR"
— Equipment: CEM
• "Mate system clock signal lost"
— Equipment: CEM
— Action: If fault is not cleared automatically, check that a mate CEM
is present. If yes, change that CEM board.
• "MC68307 was RESET"
— Equipment: CEM
• "No load in flash: Auto mate load from"
• "Node achieved network quality synchronization"

411-9001-131 18.07 12 March 2010

3.15 Fault number: 2032 (TCU 3000) 163
— The cause value indicates that the node has achieved

synchronization, which is not a problem.
— Equipment: CEM
• "No reply from RM during test/message loopback" or "A: No reply from
RM during test/message loopback."
— This cause value indicates that the active cem failed to get a reply
from the RM while running a loopback test on the RM.
• "No test reply from RM"
— Action:
• "Out Of Frame Alarm"
— Equipment: IEM
— Action: If problem persists, change the board, otherwise, it is
probably a bogus fault.
• "Passive CEM: loss of communication with active"
— Equipment: CEM
— The passive CEM loses communication with the active one.
— Action: Most likely passive CEM did reset. One occurrence is not
an issue. If the problem persists, call the manufacturer.
• "PEC name mismatch"
• "Pec Code and Carrier Type mismatch"
— Equipment: IEM
— Action: Remove the board
• "PCM Path: Local Loop"
— Equipment: IEM
— Action: If board reset only once, do nothing. Otherwise, replace
the board.
• "Processor access error" or "8A: Processor access error"

411-9001-131 18.07 12 March 2010

— Equipment: IEM
— This cause value is raised when there is a failure in reading the
Version ID stored in the firmware registers.
— If this notification is seen prior to V15.1.1, then it can be ignored,
unless multiple occurrences are observed and/or the IEM
fails to recover - in which case the replacement of the IEM is
recommended.
— If seen in V15.1.1 or above, please report any failure to the
manufacturer for further investigation.
• "RAM to Flash Restore Failure"
• "Relay Control Signal Mismatch"
— Equipment: IEM
• "RM card removed from slot" or "7A: RM card removed from slot"
• "RM diagnostics passed" or "7A: RM diagnostics passed"
— Diagnostics passed on the board.
• "Rm non-critical fault report exceeded 60 second threshold"
manufacturer.
• "RM reset reason: Last Gasp" or "A: RM reset reason: Last Gasp"

411-9001-131 18.07 12 March 2010

3.15 Fault number: 2032 (TCU 3000) 165
— This cause value indicates the card reset because RM went into a
bad state due to a software issue. Call the manufacturer for further
information on the reset cause.
manufacturer.
• "RM Test time out"
• "Running load matched datafill"
• "SLEEPYTCU Threshold crossed…”
— The notification is raised when an internal TCUe3 audit detects
more than 5% of connections have a synchorError (corresponding
to counter 1164-28) or 5% have a NackEstablish for an elapsed
period of 10 minutes.
— If counters 1164/28 and 1164/32 are having high values,
investigate and correct the cause of the dropped calls.
— EstablishReq=165,
— EstablishNack=0,
— EstablishAck=165,
— SyncError=12,
— ThresholdEstablishNack=5,
— ThresholdSyncError=5,
— Sample=10
— Total:EstablishAck=6789184 EstablishNack=34715 SyncErr=3287"
• "Slifs Far-end PCM loopback fail"
• "Slifs Near-end PCM loopback fail"
• "Slif-S Parity Errors"

411-9001-131 18.07 12 March 2010

— Equipment: IEM
• "SLIF-S r/w access failed"
manufacturer.
• "Slink hardware fault detected"
board.
• "Slink LoopBack Test Fail
board.
• "Slink pin stuck - CEM0"
• "Slink state changed to OOS"
• "SPI -MTM Lockout"
— Equipment: all boards
• "SPI port time out"
— Equipment: CEM
• "Srv Sanity audit failure"
— This error is reported when field debug commands are executed
when the RM diagnostics are running. This indicates the Service
Sanity Audit is failed and RM is being reset.
— Action: If the RM has already been reset once, call the
manufacturer.
• "SYNC DAC Error"

411-9001-131 18.07 12 March 2010

3.15 Fault number: 2032 (TCU 3000) 167
— Equipment: CEM
• "sync has entered a holdover condition"
— Equipment: CEM
• "SYNC Hold/Acq. mode unexp."
— Equipment: CEM
— Action: Check the quality of the clock on the clocking PCMs. Also
change the clock source to a different PCM if this problem persists.
• "SYNC OOSpec: prim. ref. NA"
— This indicates that the active CEM clock has entered a holdover
state.
• "TIC access protocol violation"
— Equipment: CEM
• "TIC_HAL_CMD_ERROR"
— Equipment: CEM
• "TRM: Arch1 BIST_KO Arch2 BIST_KO Arch3 BIST_KO"
— This problem occurs when bist tests are performed on the board.
There may be two causes for this problem:
– S-link problem: change the TRM board to the other shelf. If the
problem clears (BIST_KO in arch 2) it’s S-link related, call the
manufacturer.
– A hardware issue in the board - in this case if you put the RM
board in other slot and it is still showing BIST_KO for arch -2,
then its a hardware issue, and the board needs to be replaced.
• "TRM:Arch1 NO_ERROR Arch2 NO_ERROR Arch3 HAL_ERROR"

411-9001-131 18.07 12 March 2010

— Equipment: TRM
— Action: If the problem continues after a reset of the board, replace
the board.
• "UBC 32 Bit Access"
— Equipment: ATM
— Action: Change the ATM if the problem happens more than once.
• "Unexpected WAI from RM" or "7A: Unexpected WAI from RM"
— The notification with this cause value should be accompanying a
card reset.
— Action: If this card is resetting many times, contact manufacturer.
The card is experiencing spurious signals.
— Equipment: CEM
— Equipment: CEM
• "WAS time-out detected"
once.

Fault number:
2034 : Upgrade status
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 97).
This notification gives the TCU upgrade/downgrade state; it appears in

different cases:
• upgrade start/end
• fallback start/end

411-9001-131 18.07 12 March 2010

In this diagnosis event, the cause why the upgrade application starts a
fallback procedure is given in the PLMNO information field:
• the operator request
• the probatory phase refusal
• the board upgrade failure
• the Interface Node upgrade failure
• the new version failure
TROUBLESHOOTING

Fault number:
2036 : TCU Access failure
FAULT ANALYSIS
This notification appears when the link between the Interface Node and
the TCU is lost.
This notification indicates the restart state of a Control Node board, but for
the Interface Node, this fault is not sent.
When the link is faulty, the service is lost and the "TCU Access Failure"
notification is displayed at the OMC-R.
CAUTION
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010

It could be the result of two hardware failures leading to a cut of the path
between the IN and the TCU.
Identify the faulty equipment by the correlated alarms and act upon it.
Post Mortem: Specify if the event is sent right after a restart or not.
fmNormal (0)
fmEventSentAfterRestart (1)
Cause: Specify the loss cause of the equipment.
level2Loss (0)
noMoreLevel2Response (1)
level3Loss (2)
noMoreLevel3Response (3)
incompleteTCUConfiguration (4)

Fault number:
2042 : CALLP TCU TRAU resources not available
FAULT ANALYSIS
Perceived severity: Major/CLEARED
This alarm is raised at the OMC-R on reception of a state change on the

hardware transcoder 3G object: the operationalState is still "enabled", but
the availabilityStatus has become "degraded".
This alarm and state change occur when the minimum calls are not
respected by TCU 3000 using its TRM resources currently available.
BSC defense
None.
The service is reduced.
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010

Step Action
1 Perform a "Display Dynamic Data" command on the transcoder

object, the hardware transcoder 3G object.
• If the "operationalState is "enabled" but the "availabilityStatus
" has become "degraded", the fault is confirmed. Go to step
2.
• If the "operationalState is "enabled" and the "availabilityStatus
" is still empty, the fault is not confirmed. Go to step 9.
2 Check the current configuration:

• Perform a “Display Dynamic Data” command on the trm
object.
— If one or several trm objects are "disabled/failed", the
global capacity of the TCU is reduced and this is the
reason why the alarm 2042 has been sent. Go to step 3.
— If all the trm objects are "enabled", the problem lies with
the TCU configuration itself. Go to step 5.
3 Wait for up to three minutes, until TRM recover.

• If TRM recover (after a short software issue), the trm objects
become "enabled" again. Then go to step 6.
• If TRM never recover, check whether they have been
unplugged.
— If necessary, plug them again. Then go to step 6.
— If they were correctly plugged, go to step 4.
4 Replace the failed TRM mentioned in the notification.

3000/TCU 3000 Troubleshooting (411-9001-132).
• The alarm is automatically cleared. Go to step 9.
5 Modify the TCU configuration:

a Perform a “Display Dynamic Data” command on the hardware
transcoder 3G object, and note the current value of the
coderPoolList parameter. For each codec provided, a
boolean is given to indicate which TCU codec does not have
enough capacity.
b Lock the hardware transcoder 3G object.

411-9001-131 18.07 12 March 2010

CAUTION
c Perform a “Set” command on the hardware transcoder

3G object: based on the codec type that does not
respect the capacity, modify the current value of the
coderPoolConfiguration parameter
d Unlock the hardware transcoder 3G object. Then go to step
6.
6 Check the new configuration:
a Perform a “Display Dynamic Data” command on the hardware
transcoder 3G object, and note the current value of the
coderPoolList parameter.
b Perform a “Display Dynamic Data” command on the trm
object, and note the current value of the trmArchipelagoCalls
parameter. Then go to step 7.
7 Check the alarm state in the “Current Alarm List” window.
a If the alarm has disappeared automatically, go to step 9.
b If the alarm persists, go to step 8.
8 If necessary, add more TRMs to the TCU shelf.
a If the alarm has disappeared, go to step 9.
b If the alarm persists, call the manufacturer.
--End--

Fault number:
2046 : CONFIGURATION NOT SUPPORTED BY CEM
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 106) and in 3.19 “Fault number: 2046 (TCU 3000)” (page
172).
The notification 2046 can be received at the OMC-R in two different cases:

411-9001-131 18.07 12 March 2010

3.19 Fault number: 2046 (TCU 3000) 173
• If the TCU 3000 is optical and if the Transcoder Node is not equipped
with new CEM2 (but is equipped with either CEM or CEM2 for wireline
(NTLX82BC)), the notification 2046 is sent at the OMC-R.
• If the TCU 3000 is electrical and if theTranscoder Node is not equipped
with either CEM or new CEM2 (but is equipped with CEM2 for wireline
(NTLX82BC)), the notification 2046 is sent at the OMC-R.
The following table shows the CEM variants that are available for the
electrical and optical configurations of the BSC:
Table 16
CEM and CEM2 support for electrical and optical TCU 3000
Electrical TCU Optical TCU
Legacy CEM Yes No
NTLX82BA
NTLX82BB
CEM Yes Yes
NTQE82BB
CEM2 No No
NTQE82BC
CEM2 No No
NTLX82BC
(used in wireline)
The Managed Object (MO) is: transcoder
BSC defense
• If the TCU 3000 is optical:
— If the Transcoder Node is equipped with two CEM, the transcoder
object becomes disabled/failed since the dialog cannot be
established with the BSC.
— If the Transcoder Node is equipped with one CEM and one CEM2,
the CEM becomes disabled/failed.
• If the TCU 3000 is electrical:
— If the Transcoder Node is equipped with two CEM2 for wireline
(NTLX82BC), the transcoder object becomes disabled/failed since
the dialog cannot be established with the BSC.
— If the Transcoder Node is equipped with one CEM and one
CEM2for wireline (NTLX82BC), the CEM2 becomes disabled/failed.

411-9001-131 18.07 12 March 2010

The two CEM (or CEM2) are redundant.
If only one CEM (or CEM2) is faulty, there is no impact.
CAUTION
If both CEM (or CEM2) are faulty, the service is lost.
TROUBLESHOOTING
Modify the TCU 3000 hardware configuration:

• The electrical TCU 3000 can be populated with either legacy CEM,
or new CEM, or new CEM2 (NTQE82BC). Mixity is supported when
several CEM types are allowed.
• The optical TCU 3000 can only be populated with new CEM2
(NTQE82BC).

Fault number:
2047 : OPTICAL FIBER FAILURE
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 106) and in 3.19 “Fault number: 2046 (TCU 3000)” (page
172).
seconds.
When a fault occurs on a fiber linked to the passive IOM:

411-9001-131 18.07 12 March 2010

3.20 Fault number: 2047 (TCU 3000) 175

• The PCMs are not affected since they are managed by the active IOM
and hence PCMs remain “enabled/online”
When a fault occurs on a fiber linked to the active IOM:

(OPTICAL_FIBER_FAILURE) is sent on the iom object.
• Moreover, in case the passive IOM is neither "disabled/failed" nor
"enabled/degraded" with a degradation level at least equal to the fault
priority of the active IOMan automatic IOM switchover (hot standby)
on passive IOM is executed. See Table 17 "IOM degradation levels"
(page 175).
• The PCMs are not affected by a switchover since they are
now managed by the new active IOM and hence PCMs remain
“enabled/online.”
Table 17
IOM degradation levels
OC3 / STM1R Degradation level 5
STS3 / STM1M Degradation level 4
No fault (see Note 1) / Clear Degradation level 0
Note 1: VT1.5/VC1.2/DS1/E1 do not raise any degradations, and hence
associated IOM degradation level is 0.
The Managed Object (MO) is: iom
BSC defense
An automatic switchover is executed when the 2047 alarm is emitted for a

fiber linked to the active IOM (see Fault analysis).

411-9001-131 18.07 12 March 2010

A fault on the fiber link causes a loss of redundancy when the passive IOM
is functioning normally. If the passive IOM is defective or does not have a
working fiber connection, the PCM connections served by the HSA-RC
are broken.
TROUBLESHOOTING
If an iom object is “disabled/failed”, it means that the IOM module is faulty

(hardware) and must be replaced. See Nortel GSM BSC 3000/TCU 3000
If an iom object is “enabled/degraded”, it means that the optical fiber

attached to this IOM module is faulty. Contact the transmission operator.

Fault number:
2051 : TCU software upgrade status
Type : Notification of end of install
FAULT ANALYSIS
This notification is sent indicating the end of the file transfer and the file
uncompress.
The Managed Object is: bsc
Status: OK (0), KO (1), StartInstall (2) StatusReserved1 (3) for future

usage.
In case status = KO, cause of failure: NoMoreDiskSpace (0),

MissingPackage (1),
CorruptedPackage (2),
InstallationFailed (3)
(CauseReserved1 (4),
CauseReserved2 (5) for future usage)
package_name: Name (up to 52 character) of the faulty package in case
of missing or corrupted package.
TROUBLESHOOTING
No maintenance is required

411-9001-131 18.07 12 March 2010

3.22 Fault number: 2068 (TCU 3000) 177

Fault number:
FAULT ANALYSIS
ATTENTION
(BSC 3000)” (page 125)
This fault indicates a failure on the first fiber connected on the CEM3
through the port 0.
seconds.

on the cem3 object

on the cem3 object

411-9001-131 18.07 12 March 2010


Table 18
OC12 / STM4R Degradation level 5 (initiates Automatic
Protection Switch (APS))
impacted.
impacted.
TCU defense
CEM3 are broken.
TROUBLESHOOTING

411-9001-131 18.07 12 March 2010

3.23 Fault number: 2069 (TCU 3000) 179



Fault number:
FAULT ANALYSIS
ATTENTION
This fault does not apply to V17, but only to V18.
ATTENTION
(BSC 3000)” (page 127)
This fault indicates a failure on the second fiber connected on the CEM3
through the port 1.
seconds.

on the cem3 object

411-9001-131 18.07 12 March 2010


on the cem3 object
Table 19
OC12 / STM4R Degradation level 5 (initiates Automatic
Protection Switch (APS))
impacted.
impacted.
BSC defense

411-9001-131 18.07 12 March 2010

3.23 Fault number: 2069 (TCU 3000) 181
CEM3 are broken.
TROUBLESHOOTING



411-9001-131 18.07 12 March 2010


411-9001-131 18.07 12 March 2010

183
.
Chapter 4 Informational messages

"COM : delete several whole subtree bsc : forbidden action response?"
This message is generated when a user tries to delete a BSC 3000

hardware object of a BSC. It is displayed in a session log, but the deletion
should complete successfully.

411-9001-131 18.07 12 March 2010

184 Chapter 4 Informational messages

411-9001-131 18.07 12 March 2010

185
.
Index
B 2027 Restart cause 81

BSC 3000 2028 Restart context 83
1074 Indication of non activated 2030 SPM message error 84
features on specific instances 16 2031 SPM nack 84
1315 Path information for calls 2032 Miscellaneous SPM alarm 85
released by TCU or BTS 19 2033 Application failure 96
1502 Access Attempt to a non 2034 Upgrade status 97
operational cell 22 2035 Suspended upgrade 99
1503 Access attempt to an unknown 2037 Board restart 100
BCCH or BSIC 24 2039 PCIU and or FMU failure 102
1525 Modification of Agprs 2040 Feeder A failure 103
configuration 25 2041 Feeder B failure 103
2000 Power failure 25 2045 CC1 or TMU or OMU are faulty
2001 Hardware not supported 31 in a communication standpoint 104
2004 Load balancing performed 37 2050 BSC software upgrade status 112
2005 Load balancing result 41 47 Cessation of active alarms 15
2007 Overload threshold crossed 43
2008 Hardware failure 44
2009 PCM failure 51 T
2010 SIMA failure 62 TCU 3000
2011 SIMB failure 63 2000 Power failure 131
2012 Loss of A interface (or no 2001 Hardware not supported 133
establishment) with MSC 64 2008 Hardware failure 135
2013 SS7 SSN LCS 65 2009 PCM failure 137
2014 Fan failure 65 2010 SIMA failure 145
2015 ATM path failure plan 0 66 2011 SIMB failure 146
2017 ATM path failure plan 1 68 2014 Fan failure 147
2018 Loss of Lb interface (or no 2019 Synchronizing PCM indication 148
establishment) with SMLC 69 2024 SPM Download failure 150
2019 Synchronizing PCM indication 70 2027 Restart cause 155
2020 Supervision failure 72 2028 Restart context 156
2021 IN Access failure 73 2030 SPM message error 157
2022 Clock failure 75 2031 SPM nack 157
2023 Signalling fault 76 2032 Miscellaneous SPM alarm 158
2024 SPM Download failure 77 2034 Upgrade status 168
2026 Observation FTAM 2036 TCU Access failure 169
Disk fail 80 2042 CALLP TCU TRAU resources
not available 170

411-9001-131 18.07 12 March 2010

186
2046 Configuration not supported by

CEM 172
2051 TCU software upgrade status 176

411-9001-131 18.07 12 March 2010


Release: 18.0
Publication: 411-9001-131
Document revision: 18.07
Document release date: 12 March 2010
While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed to in writing
NORTEL PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OR CONDITION OF ANY KIND, EITHER EXPRESS
OR IMPLIED. The information and/or products described in this document are subject to change without notice.
Nortel, Nortel Networks, the Nortel logo, and the Globemark are trademarks of Nortel Networks.
All other trademarks are the property of their respective owners.
To provide feedback or to report a problem in this document, go to www.nortel.com/documentfeedback.
www.nortel.com

411-9001-131 (BSC TCU Fault Clearing) PDF

Uploaded by

Document Information

Original Title

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

411-9001-131 (BSC TCU Fault Clearing) PDF

Uploaded by

Copyright:

Available Formats

Global System for Mobile Communications (GSM)

Nortel GSM BSC 3000/TCU

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

All other trademarks are the property of their respective owners.

Chapter 2 BSC 3000 fault numbers 15

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

2.25 Fault number: 2020 72

Chapter 3 TCU 3000 fault numbers 131

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

3.7 Fault number: 2014 (TCU 3000) 147

Chapter 4 Informational messages 183

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

New in this release

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

Nortel GSM BSS Documentation Roadmap (411-9001-000)

Nortel GSM BSS Fault Management — Maintenance Principles

Nortel GSM BSS Fault Clearing — Advanced Maintenance Procedures

Nortel GSM BSC 3000/TCU 3000 Fundamentals (411-9001-126)

Nortel GSM BSC 3000/TCU 3000 Troubleshooting (411-9001-132)

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

Chapter 1 How to use this manual

The general principles and messages required for BSS maintenance

Network maintenance is based on graphical supervision of the network.

It is also based on the identification and replacement of faulty items of

This process is divided into two steps:

When a faulty item of equipment sends an alarm to the OMC-R, this

Description of the representation n+p:

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

1.2 Description of a fault number sheet

1.2.1 Header of the sheet

1.2.2 Main body of the sheet

If fault number leads to the replacement of modules or boards, Nortel

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

This paragraph gives the consequences of the alarm for service.

Two conditions indicate failure:

Each procedure or flow chart is composed of three parts:

If the fault number is still present after modules or boards replacement,

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

Chapter 2 BSC 3000 fault numbers

The notification concerns one of the following objects: bsc,

The type of alarm clearing is displayed in the probableCause field of the

Global System for Mobile Communications (GSM)

Copyright © 1999-2009 Nortel Networks. All Rights Reserved.

REACTION OF THE SYSTEM

Impact on the service

2.2 Fault number: 1074

Values of features_id field :