Anda di halaman 1dari 76

Nokia GSM/EDGE BSS, Rel.

BSS13, BSC and TCSM, Rel.


S13, Product Documentation,
v.5, Doc change delivery 7

Handling Common Problem Situations in


BSC
DN05104459
Issue 2-2
Approval Date 2010-06-23

Handling Common Problem Situations in BSC

The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2010. All rights reserved

Important Notice on Product Safety


Elevated voltages are inevitably present at specific points in this electrical equipment.
Some of the parts may also have elevated operating temperatures.
Non-observance of these conditions and the safety instructions can result in personal
injury or in property damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected
has to comply with the applicable safety standards.

The same text in German:


Wichtiger Hinweis zur Produktsicherheit
In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Spannung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und Sachschden fhren.
Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die
Anlagen installiert und wartet.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene
Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

Id:0900d805807a98f7

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Table of Contents
This document has 76 pages.
Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1

Overview of common problem situations in BSC. . . . . . . . . . . . . . . . . . . 8

2
2.1

Problems with radio network configuration and recovery . . . . . . . . . . . 11


Modifying radio network configuration fails because of lack of resources .
11
Outputting or modifying radio network configuration fails without obvious
reason . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Radio network object is not found in BSDATA. . . . . . . . . . . . . . . . . . . . 13
BCF configuration with EDGE and non-EDGE TRXs in the same BTS fails
14
TRX LAPD links remain in the UA-AD RN RECOV state without an active
alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2
2.3
2.4
2.5
3
3.1
3.2

3.9

Problems with circuit-switched calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17


Inter-system handover BSC-RNC-BSC fails . . . . . . . . . . . . . . . . . . . . . 17
Activating AMR HR (HR3) with parameter HR_FEATURE_IN_BSC fails .
17
Cell Broadcast Centre does not work . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Circuit-switched call fails with alarm 1582 CONNECTION OR RELEASE
ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
BSC-BSC interface configuration to only one BCSU unit causes problems
during BCSU switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Alarm 7737 INCONSISTENT DATA IN RADIO RESOURCE MANAGEMENT STATE FILES is raised. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Alarm 7741 MEAN HOLDING TIME ABOVE DEFINED THRESHOLD is
raised . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Alarm 2725 ADJACENT CELL IDENTIFIER CONFIGURATION ERROR is
raised . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
SIGTRAN A interface is down (UA-INS) . . . . . . . . . . . . . . . . . . . . . . . . 22

4
4.1
4.1.1
4.2
4.2.1
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.4
4.4.1
4.4.2
4.4.3

Problems with packet-switched calls . . . . . . . . . . . . . . . . . . . . . . . . . . .


Problems with TBF establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TBF establishment fails due to lack of Abis channel resources. . . . . . .
Problems with GPRS/EDGE cell changes . . . . . . . . . . . . . . . . . . . . . . .
High NCCR failure rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problems with transmission in the Abis interface. . . . . . . . . . . . . . . . . .
Continuous resynchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unsuccessful initial synchronisation or resynchronisation . . . . . . . . . . .
No PCU synchronisation frames received from the BTS . . . . . . . . . . . .
BPN jump in synchronisation time . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TBFs do not have enough EDAP resources . . . . . . . . . . . . . . . . . . . . .
EDAP configuration fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problems with transmission in the Gb interface. . . . . . . . . . . . . . . . . . .
Inconsistent BVCI states between the BSC, the PCU and the SGSN . .
BSSGP protocol error raised with cause code 0x20 or 0x21. . . . . . . . .
BVCI operational state remains UNBLOCKED . . . . . . . . . . . . . . . . . . .

3.3
3.4
3.5
3.6
3.7
3.8

DN05104459
Issue 2-2

Id:0900d805807a98f7

25
25
25
26
26
27
27
28
30
31
32
33
35
35
36
36

Handling Common Problem Situations in BSC

4.4.4
4.5
4.5.1
4.6
4.6.1

Gb over IP: DX error 16246 appears . .


Problems with performance . . . . . . . . .
Low downlink GPRS/EDGE throughput
Problems with territory operations . . . .
GPRS/EDGE territory failures. . . . . . . .

5
5.1
5.2
5.3

Problems with synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


Incoming synchronisation from an external source fails . . . . . . . . . . . . . 42
Clock and Synchronisation Unit fails. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Timing signal distribution fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6
6.1
6.1.1
6.2
6.2.1

Problems with transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


Problems with PCM transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Transmission line between the BSC and a transmission node is broken 47
Problems with IP transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Signal in the IP network does not go through . . . . . . . . . . . . . . . . . . . . . 49

7
7.1
7.1.1
7.1.2
7.1.3

Problems with operation and maintenance . . . . . . . . . . . . . . . . . . . . . . . 57


Problems with Q3 connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
BSC alarms are missing from Nokia NetAct . . . . . . . . . . . . . . . . . . . . . . 57
BSC measurement result files are missing from Nokia NetAct. . . . . . . . 57
Creating, modifying, or uploading RNW objects with Nokia NetAct applications fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
All connections from the BSC to Nokia NetAct are lost . . . . . . . . . . . . . 59
Problems with software package handling . . . . . . . . . . . . . . . . . . . . . . . 60
Change delivery installation fails. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Multiple change delivery installation fails . . . . . . . . . . . . . . . . . . . . . . . . 60
Problems with licence handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Licence installation fails, licence file not found . . . . . . . . . . . . . . . . . . . . 61
Licence installation fails, licence file already found. . . . . . . . . . . . . . . . . 62
Licence installation fails, licence is not valid . . . . . . . . . . . . . . . . . . . . . . 62
Licence installation succeeds, but copying or deleting the licence file fails
63
Interrogating installed licences or features fails . . . . . . . . . . . . . . . . . . . 63
Licence database is corrupted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Licence file handling with Nokia NetAct Licence Manager fails . . . . . . . 64

7.1.4
7.2
7.2.1
7.2.2
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
7.3.6
7.3.7
8
8.1
8.1.1

......
......
......
......
......

.......
.......
.......
.......
.......

......
......
......
......
......

. . . . . . 37
. . . . . . 38
. . . . . . 38
. . . . . . 39
. . . . . . 39

8.2
8.2.1

Problems with location-based services. . . . . . . . . . . . . . . . . . . . . . . . . . 65


Problems with the internal SMLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
BSC gives inaccurate location estimates or returns the location response
with an error cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Problems with the Lb interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Lb interface is down (UA-INS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

9
9.1
9.1.1
9.2
9.2.1

Problems with LAN Device Integration . . . . . . .


Problems with Telnet . . . . . . . . . . . . . . . . . . . .
Accessing the ESB switch fails . . . . . . . . . . . . .
Problems with DHCP . . . . . . . . . . . . . . . . . . . .
Negotiating an IP address fails . . . . . . . . . . . . .

Id:0900d805807a98f7

.......
.......
.......
.......
.......

......
......
......
......
......

. . . . . . 69
. . . . . . 69
. . . . . . 69
. . . . . . 74
. . . . . . 74

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

List of Figures
Figure 1

DN05104459
Issue 2-2

Common PCM transmission problem situations . . . . . . . . . . . . . . . . . . 47

Id:0900d805807a98f7

Handling Common Problem Situations in BSC

Id:0900d805807a98f7

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Summary of changes

Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Changes made between issues 2-2 and 2-1
Software package file name for ESB24_D is added in chapter Problems with LAN
Device Integration under section Problems with Telnet.
Changes made between issues 2-1 and 2-0
Problems with packet-switched calls: Examples of PCU2 logs added.
Changes made between issues 2-0 and 1-1
New chapters Problems with transmission and Problems with LAN Device Integration
added.
Problems with radio network configuration and recovery: Information on ongoing activation of File Based Plan Provisioning as one possible problem cause added to problem
situation 'Modifying radio network configuration fails because of lack of resources'.
Problems with circuit-switched calls: New problem situation 'SIGTRAN A interface is
down (UA-INS)' added.
Problems with packet-switched calls: Added that all the problem situations included in
this chapter may appear both in PCU1 and PCU2. References to alarm 7760 and
PCCCH/PBCCH removed. Information on NSE reset added to problem situation 'Inconsistent BVCI states between the BSC, the PCU and the SGSN'. Information on Gb over
IP configuration as one possible problem cause added to problem situation 'Low
downlink GPRS/EDGE throughput'. New problem situation 'Gb over IP: DX error 16246
appears' added to 'Problems with transmission in the Gb interface'.
Problems with operation and maintenance: Section 'Problems with MMLs' removed.
Problem situations 'Creating and modifying RNW objects with Nokia NetAct applications
fails' and 'Uploading RNW objects data with Nokia NetAct applications fails' merged into
one. References to problem situation 'All connections from the BSC to Nokia NetAct are
lost' added to all problem situations grouped under section 'Problems with Q3 connections'. Section 'Problems with licence handling' updated.
Problems with location-based services: Sections 'Problems with the internal SMLC' and
'Problems with the Lb interface' formed. The problem situations in these sections
updated and 'E911 positioning fails' merged with the new content 'Lb interface is down
(UA-INS)'.
Concept (E)GPRS replaced with GPRS/EDGE throughout the document, where applicable.
Changes made between issues 1-1 and 1-0
New chapter Problems with synchronisation added.

DN05104459
Issue 2-2

Id:0900d805807a98f3

Overview of common problem situations in BSC

Handling Common Problem Situations in BSC

1 Overview of common problem situations in


BSC
Problem situations in the BSC may be caused by several different error conditions.
Some problem situations are caused by human errors, such as incorrectly performed
software/hardware changes and maintenance actions; others are caused by errors in
the functioning of the software or hardware. Often it is difficult to pinpoint the actual
cause, and locating the problem is often an iterative process.
General troubleshooting actions
When you suspect that there is a problem in the BSC, use the following general troubleshooting actions as a guideline:
1. Evaluate the seriousness of the consequences.
If the problem has very serious consequences, call for the help of an expert or apply
an emergency plan immediately.
2. Make observations of the situation where the problem appeared. For example,
consider the following:
What are the symptoms? Do alarms, counters, computer logs, or error
messages indicate anything unusual?
What is the scope of the problem? Is only one element or interface affected, or
several? Do the symptoms seem to be specific to a certain call type or call
phase?
When and in what situation did the symptoms occur? Were changes in software,
hardware, or configuration done before the symptoms occurred?
It is important to make an accurate description of the problem situation. You may not
be able to solve the problem yourself, but a detailed description can help an expert
to solve the problem.
3. Study the symptoms carefully.
Analyse and categorise the symptoms and list possible causes for the symptoms.
Sometimes there can be several related or isolated problems active at the same
time. Study whether the symptoms are related or not. Prioritise symptoms and
collect further facts, if necessary.
4. Narrow down the possible causes of the problem.
Based on the information you have now available of the situation and your knowledge of the system, eliminate symptoms that are not relevant to the trouble you are
trying to solve. Examine what works and what does not.
In any situation, it is useful to eliminate the possibility of human error. Check all MML
and service terminal commands entered recently. Use the IGO command.
Also check the configuration parameters. Use the IGO and WTI commands.
If the problem appeared directly after activating new software, refer to the activating
and testing instructions of the software in question. The activating and testing
instructions list possible unexpected outcomes of the activation process and include
instructions on how to proceed.

Id:0900d8058066eb85

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Overview of common problem situations in BSC

5. Carry out corrective actions.


If you ended up with more than one probable and possible cause for the trouble,
change only one thing at a time. Otherwise you cannot be sure which change corrected the failure or problem.
Remember that random actions can make problems worse. Do not take any radical
corrective actions if you are not sure what the problem is and what the consequences of the corrective actions are.
6. Fill in a Problem Report, if needed.
Describe the problem situation in detail in the Problem Report. Include all relevant
information that is available concerning the problem situation and also describe the
corrective actions that you have carried out.
Individual problem situation descriptions
Handling Common Problem Situations in BSC lists concrete problem situations that are
known to have occurred in the BSC from time to time. The purpose of the problem situation descriptions is to ease troubleshooting by providing you with the means to identify,
analyse, and correct problems by yourself, wherever possible.
Based on the principles of the general troubleshooting actions, the following preliminary
information is provided for each problem situation, when applicable:
Symptoms
This topic lists, for example, the alarms, counters, and computer logs that are likely to
indicate that the problem is currently on. If possible, check all the potential symptoms
mentioned. Even if no specific alarms are mentioned, it is always useful to check the
current alarms and alarm history.
Possible causes
Based on the symptoms, this topic describes what the cause(s) of the problem may be.
Instructions
This topic includes instructions on how to solve the problem by tackling the causes of
the problem, if possible. For example, it may first instruct what to check to narrow down
the possible causes, and then suggest further corrective actions.
If it is not possible to define corrective actions that would help to solve the problem permanently, a workaround that helps you to overcome the problem at least for the time
being is referred to.
In case the problem still persists after the corrective actions, you are often recommended to collect information for a Problem Report and contact Nokia Siemens
Networks for further investigations.
Workarounds
Sometimes it is not possible to start proper troubleshooting, and a quick solution is
needed. This topic lists known workarounds that quickly help you to overcome the
problem. Remember that because a workaround is often a temporary solution, the
problem is likely to reappear sooner or later.
Related topics in Handling Common Problem Situations in BSC

DN05104459
Issue 2-2

Problems
Problems
Problems
Problems

with radio network configuration and recovery


with circuit-switched calls
with packet-switched calls
with synchronisation

Id:0900d8058066eb85

Overview of common problem situations in BSC

Problems
Problems
Problems
Problems

Handling Common Problem Situations in BSC

with transmission
with operation and maintenance
with location-based services
with LAN Device Integration

Other related topics in BSC/TCSM documentation

10

For information on filling in a Problem Report, see BSC Problem Reporting.


For information on displaying alarms, see Alarm system in BSC.
For information on displaying computer logs, see Service terminal overview.
For information on measurement handling, see BSC Statistics administration.

Id:0900d8058066eb85

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with radio network configuration and recovery

2 Problems with radio network configuration


and recovery
For more information on problems with radio network configuration, see Errors in radio
network configuration in Radio Network Administration.
For an overview, see Overview of common problem situations in BSC.

2.1

Modifying radio network configuration fails because of


lack of resources
Symptoms
When the radio network (RNW) configuration is modified with MML, the command execution fails, and the following DX error message is output:
Example:
/*** DX ERROR: 10824 ***/
/*** BSS-SYSTEM HAS NO RESOURCES FOR REQUESTED TASK ***/
Possible causes
There may be a momentary shortfall in resources because of another simultaneous BSS
RNW configuration management or recovery task for the requested RNW object, or for
any of the RNW objects. In this case, re-entering the command after a while may help.
However, the problem may also be of a more permanent nature.
In addition, ongoing activation of File Based Plan Provisioning may also prevent the
modification of an RNW object. During the activation phase, recovery actions and local
changes are prevented until the object has been activated.
Instructions
1. Check the state of the BSS RNW plan database.
ZEEK;
2. Depending on the outcome, implement one of the following options:
If the activation of File Based Plan Provisioning is ongoing, check the activation
state of the Base Control Function (BCF) RNW object and the object(s) under
the BCF.
ZEEK:BCF=<bcf_id>;
If the activation state of the BCF or the object(s) under the BCF is PLANNED,
wait until the state is changed to ACTIVATED.
If the activation of File Based Plan Provisioning is not ongoing, proceed to step
3 to continue troubleshooting.
3. Re-enter the command.
4. If re-entering the command does not help, and six minutes have already passed
since the problem emerged, check the active BTS alarms and BTS alarm history.
ZEOL;
ZEOH;
5. Depending on the outcome, implement one of the following options:
If there are no alarms for the requested RNW object, kill the hand with service
terminal command K: KILL/RESTART PROCESS and reset the BCF of the
requested RNW object.

DN05104459
Issue 2-2

Id:0900d8058066eb88

11

Problems with radio network configuration and recovery

Handling Common Problem Situations in BSC

If there are active alarms, study the alarms and the relevant alarm documentation for the cause of the problem.
6. If the problem persists, collect MCMU log writings and send them with the alarm
printouts and the MML log to Nokia for further investigations.
ZDDE:<computer unit>:<unit index>:ZGSC;
Workarounds
Do not apply this workaround if the activation of File Based Plan Provisioning is ongoing.
The supervision period of a hand life time is 145 minutes for recovery tasks and six
minutes for MMI tasks. As a workaround, you can either wait until the supervision period
of MMI tasks is over or kill the hand with service terminal command K:KILL/RESTART
PROCESS.

2.2

Outputting or modifying radio network configuration fails


without obvious reason
Symptoms
When the radio network (RNW) configuration is output or modified with MML, the
command execution fails, and an ambiguous DX error message indicating a logical error
in the BSS Radio Network Configuration Database (BSDATA) is output.
Example:

RTSL
PCM-TSL SUB_TSL TYPE
I.LEV ADM.STATE
OP.STATE
CH.STATUS
-----------------------------------------------------------------------------0
171
MBCCHC
UNLOCKED
BL-USR
1
171- 3
1
TCHD
0
UNLOCKED
BL-USR
2
171- 3
2
TCHD
0
UNLOCKED
BL-USR
/*** DX ERROR: 5 ***/
/*** RECORD NUMBER OUT OF FILE ***/
4
171- 4
0
TCHD
0
5
171- 4
1
TCHD
0
6
171- 4
2
TCHD
0
7
171- 4
3
TCHD
0

UNLOCKED
UNLOCKED
UNLOCKED
UNLOCKED

BL-USR
BL-USR
BL-USR
BL-USR

TRANSCEIVER HAS NO INTERFERING CELLS


...
Note that when modifying the RNW configuration, you may also receive various other
kinds of DX error messages that indicate, for example, that a software licence is missing.
These error messages are not related to this problem situation and, therefore, do not
call for those corrective actions that are described in this problem situation.
Possible causes
The primary cause of this problem is inconsistency in the BSDATA. The cause of the
inconsistency is unknown.

12

Id:0900d8058066eb88

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with radio network configuration and recovery

Instructions
Check the integrity of the BSDATA.
Before starting the integrity check in a new software build for the first time, make sure
that the database data dictionary is initialised using the BSDDDI conversion program.
1. Copy the BSDATA to a disk.
ZDBC:BSDATA,0;
2. Prevent the updating of the database to disk.
ZDBP:BSDATA,0:DISK;
3. Empty the database disk updating log.
ZDBX:BSDATA,0;
4. Start the integrity check.
ZDBV:BSDATA,0:DISK;
5. Resume the updating of the database to disk.
ZDBR:BSDATA,0:DISK;
6. Check the results of the integrity check. If there are errors in the integrity of the
BSDATA, collect all the information needed for a Problem Report and contact Nokia
Siemens Networks for further investigations. For instructions, see Reporting
problems with BSS Radio Network Configuration Database (BSDATA) integrity in
BSC Problem Reporting.

2.3

Radio network object is not found in BSDATA


Symptoms
A radio network (RNW) object cannot be created, modified, or deleted because the
object is not found in BSS Radio Network Configuration Database (BSDATA), even
though it can be output with MML. For example:

Creating a new BTS fails with the following DX error message:


Example:
/*** DX ERROR: 10538 ***/
/*** BSC OBJECT NOT FOUND IN RNW DATABASE ***/
Modifying or deleting a BTS fails, even though the BTS does exist and can be output
from BSDATA with MML. An example of a DX error message received in this situation is the following:
Example:
/*** DX ERROR: 10540 ***/
/*** BTS NOT FOUND IN RNW DATABASE ***/

Possible causes
The BSDATA manager's (ROLLER) transaction hands are probably corrupted. That is,
for some reason the memory area where the data should be located does not exist, or
the pointer is pointing at a wrong memory area.

DN05104459
Issue 2-2

Id:0900d8058066eb88

13

Problems with radio network configuration and recovery

Handling Common Problem Situations in BSC

Instructions
1. Restart the ROLLER processes in both Marker and Cellular Management Units
(MCMU). Start with the active MCMU.
After each successful command execution, the text PROCESS RESTARTED is
output.
04:OSC> ZOKR:19B,FE;
04:OSC> ZOKR:19B,FF;
04:OSC> ZOKR:19B,100;
04:OSC> ZOKR:19B,101;
04:OSC> ZOKR:19B,102;
04:OSC> ZOKR:19B,103;
04:OSC> ZOKR:19B,104;
04:OSC> ZOKR:19B,105;
2. To confirm the executions, restart the current SP MCMU.
ZUSC:MCMU,<unit index>:TE;
ZUSC:MCMU,<unit index>:SP;
3. Perform an MCMU switchover.
ZUSC:MCMU,<unit index>:WO;
4. Restart the (new) SP MCMU.
ZUSU:MCMU,<unit index>:C=DSK,;

2.4

BCF configuration with EDGE and non-EDGE TRXs in the


same BTS fails
Symptoms
After unlocking a TRX/BTS/BCF or TRX recovery, the TRXs (GTRX=Y) remain in the
BL-SYS operational state instead of the normal operational state (WO). The alarm 7730
CONFIGURATION OF BCF FAILED is raised with one of the following DX error messages:

14969 GPRS ENABLED TRX IS NOT EDGE CAPABLE


15953 GPRS ENABLED BCCH TRX IS NOT EDGE CAPABLE
15844 GPRS ENABLED TRX OF EGPRS BTS NOT IN DYNAMIC ABIS POOL
16368 GPRS ENABLED TRX NOT ATTACHED TO DYNAMIC ABIS POOL IN
CS3&CS4 BTS
15973 GPRS ENABLED BCCH TRX OF EGPRS BTS NOT IN DYNAMIC ABIS
POOL
16369 GPRS ENABLED BCCH TRX NOT ATTACHED TO DYNAMIC ABIS POOL
IN CS3&CS4 BTS

Possible causes
The TRX(s) configuration in the BTS is not correct. When unlocked EDGE and nonEDGE-capable TRXs exist in the same EGPRS or CS3 & CS4-enabled BTS, the following conditions should be taken into account to assure that the Broadcast Control
Channel (BCCH) recovery works correctly:

14

If a BCCH TRX is EDGE-capable, added to EDAP, and has the GTRX parameter
set to Y, all EDGE-capable unlocked TRXs that have GTRX set to Y should be
added to EDAP and marked with the preferred BCCH mark (PREF=Y).

Id:0900d8058066eb88

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with radio network configuration and recovery

If a BCCH TRX is non-EDGE-capable and has the parameter GTRX set to N, all
non-EDGE-capable unlocked TRXs that have GTRX set to N should be marked with
the preferred BCCH mark (PREF=Y).

Instructions
1. Check whether the TRXs in the BTS have been configured correctly, that is, whether
the recommendation above has been followed.
2. If needed, lock the BTS.
ZEQS:<BTS identification or BTS name>:L;
3. Repair the configuration.
4. Unlock the BTS.
ZEQS:<BTS identification or BTS name>:U;
Workarounds
Lock and unlock the BTS.
ZEQS:<BTS identification or BTS name>:L;
ZEQS:<BTS identification or BTS name>:U;

2.5

TRX LAPD links remain in the UA-AD RN RECOV state


without an active alarm
Symptoms
Alarm 7704 PCM FAILURE has caused the TRX(s) connected through the PCM to be
changed into the BL-RSL state and the TRX LAPD links to the UA-AD RN RECOV state.
The RNW objects whose LAPD links are part of this PCM are not functioning. Normally,
radio network recovery actions would cancel the alarm and restore the TRX LAPD link
states.
Possible causes
The radio network recovery actions have failed to restore the TRX LAPD link states.
Instructions
1. Carry out the workaround below.
2. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Reporting problems with BSS Radio Network Recovery in BSC Problem Reporting.
Workarounds
There are two alternative workarounds.

Change the TRX LAPD link state first into BL-US and then into WO-EX.
ZDTC:<D-channel link set name>:BL;
ZDTC:<D-channel link set name>:WO;
Lock and unlock the TRXs connected through the PCM.
ZERS:BTS=<BTS identification or BTS name>,TRX=<TRX
identification>:L;
ZERS:BTS=<BTS identification or BTS name>,TRX=<TRX
identification>:U;

OR

DN05104459
Issue 2-2

Id:0900d8058066eb88

15

Problems with radio network configuration and recovery

16

Handling Common Problem Situations in BSC

Lock and unlock the Base Control Function (BCF).


ZEFS:<BCF identification>:L;
ZEFS:<BCF identification>:U;

Id:0900d8058066eb88

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with circuit-switched calls

3 Problems with circuit-switched calls


For an overview, see Overview of common problem situations in BSC.

3.1

Inter-system handover BSC-RNC-BSC fails


Symptoms
A circuit-switched (CS) call is started in a 3G network, an inter-system handover to a
2G network is successfully made, but the handover back to the 3G network fails.
Possible causes
To trigger a successful BSC-RNC-BSC scenario, the MSC needs to send the Mobile
Station Classmark 3 Information Element (MS CM3 IE) to the 2G BSC in the
HANDOVER REQUEST message. This optional information tells the BSC that the 3G
user equipment (UE) concerned is FDD-capable, and that 3G neighbour cells can be
measured.
If this information is not available, measurement information is not sent to the UE, and
a handover back to the 3G network cannot be triggered.
The inadequate HANDOVER REQUEST message can be detected by monitoring A
interface signalling.
Instructions
Modify the MSC-related base station system application part (BSSAP) parameters that
have an effect on the optional information sent in the HANDOVER REQUEST message.
Note that the exact parameters depend on the MSC type and vendor used.

3.2

Activating AMR HR (HR3) with parameter


HR_FEATURE_IN_BSC fails
Symptoms
Parameter HR_FEATURE_IN_BSC has no effect on AMR HR (HR3).
Possible causes
HR_FEATURE_IN_BSC is not the correct parameter for AMR HR (HR3). It defines
whether GSM speech half rate version 1 (HR1) speech codec is supported in the BSC
or not. There is another, licence-based parameter that is used to prevent or allow AMR
HR (HR3).
Instructions
For more detailed information on implementing AMR HR (HR3), see Activating and
Testing BSS10004: AMR and Licensing in BSC.

3.3

Cell Broadcast Centre does not work


Symptoms
Cell Broadcast Centre (CBC) does not receive any acknowledgement messages from
the BSC.
The following log writings are printed to the MCMU log:

DN05104459
Issue 2-2

Id:0900d8058066eb8b

17

Problems with circuit-switched calls

Handling Common Problem Situations in BSC

Example:
CALLER : 02AA 0007 8F RETURN ADDRESS: 000C (L0001).00005B50
WRITE TIME: xxxx-xx-xx xx:xx:xx.xx
PARAMETERS: E-01 0084.00009290 00000006 000C.00003E98
USER TEXT : TPPIPE: unauthorized network user, username:
USER DATA : 00 00 00 00 00 00 00
Example:
CALLER : 02AA 0007 8F RETURN ADDRESS: 000C (L0001).00005B69
WRITE TIME: xxxx-xx-xx xx:xx:xx.xx
PARAMETERS: E-01 0084.0000927C 00000010 000C.00003EC5
USER TEXT : TPPIPE: unauthorized network user, password:
USER DATA : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Possible causes
The network user authority information is not correct. There is possibly a lack of FTAM
user rights.
Instructions
Check the FTAM user name and password settings.
For instructions, see Technical Note No. 830 (SMS Cell Broadcast and Secured FTAM
Settings).
For further information on secured FTAM settings, also see Technical Note No. 823
(Secured FTAM Settings after S11.5 upgrade).

3.4

Circuit-switched call fails with alarm 1582 CONNECTION


OR RELEASE ERROR
Symptoms
A circuit-switched (CS) call fails, after which alarm 1582 CONNECTION OR RELEASE
ERROR is raised.
Possible causes
There are two possible causes:

A CS call reservation has been made directly to a packet-switched (PS) timeslot


right after a timeslot downgrade.
A full rate (FR) call has been requested to a timeslot that still has a half rate (HR)
reservation.

In both cases, the result is an interfering connection, which is announced via alarm
1582.
Instructions
The alarm requires no actions.
If the alarm occurs repeatedly, contact Nokia Siemens Networks for a macro that can be
used to investigate the failure further.

18

Id:0900d8058066eb8b

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

3.5

Problems with circuit-switched calls

BSC-BSC interface configuration to only one BCSU unit


causes problems during BCSU switchover
Symptoms
The signalling link set remains unavailable approximately for five seconds during a Base
Station Controller Signalling Unit (BCSU) switchover. As a result, alarms 2070 LINK
SET UNAVAILABLE and 2241 SCCP SUBSYSTEM PROHIBITED may be raised.
Possible causes
The BSC-BSC interface configuration has only one signalling link set instead of two.
Instructions
1. Create another signalling link and association set for the other active BCSU.
For instructions, see Connecting and testing the BSC-BSC interface.
To ensure the optimum functioning of the BSC-BSC interface, also use Technical
Note No. 807 (A-Interface Parameters (MTP/SCCP) as a guideline when making the
changes.
2. Perform the BCSU switchover again.
ZUSC:BCSU,<WO_index>:SP,;

3.6

Alarm 7737 INCONSISTENT DATA IN RADIO RESOURCE


MANAGEMENT STATE FILES is raised
Symptoms
The BTS's traffic capacity may have decreased. Decrease in traffic capacity can be
detected from the counters of 1 Traffic Measurement: the values of counters indicating
successful TCH allocations (TCH success counters) are lower than the values of
counters indicating TCH attempts (TCH requests and attempts counters). In addition, in
case of a call setup or handover, if the state file fault occurs during a TCH allocation,
counter 001011 TCH REQUEST REJECTED DUE TO LACK is updated by one.
Possible causes
The alarm is raised because there is an internal error in the data structures of radio
resource management state files. The error that has triggered the alarm may be of
several different types, because the radio resource management (RRM) checks the
internal data structures several times during channel allocation. If there is a conflict
between BTS-level and channel-level information, an internal recovery procedure starts
automatically. The alarm is set at the end of the recovery process and the severity class
of the fault is marked to the supplementary information field of the alarm.
Instructions
1. Cancel the alarm.
ZEOR:<BCF identification>:<consecutive alarm number>...;
Note that if the alarm occurs in a spare MCMU, no other corrective actions are
needed.
2. If the BTS's traffic capacity has decreased because of the fault, perform the workaround below (deleting and recreating the BTS).

DN05104459
Issue 2-2

Id:0900d8058066eb8b

19

Problems with circuit-switched calls

Handling Common Problem Situations in BSC

3. If the alarm occurs repeatedly in the same BTS, collect all the information needed
for a Problem Report and contact Nokia Siemens Networks for further investigations. For instructions, see Collecting alarm 7737 logs in BSC Problem Reporting.
Workarounds
Delete and recreate the BTS in the BSC.
For instructions, see Deleting a BTS from the BSC and Creating a new BTS in Radio
Network Administration.

3.7

Alarm 7741 MEAN HOLDING TIME ABOVE DEFINED


THRESHOLD is raised
Symptoms
A channel is left in a busy state even though it is no longer involved in a real call. Therefore, also the call duration counters in 2 Resource Availability Measurement show
unusually high values.
Possible causes
This alarm is raised when the mean holding time for any working stand-alone dedicated
control channel (SDCCH) or TCH during a measurement period exceeds or equals the
maximum value (time period) defined by the operator.
Instructions
1. Carry out the corrective actions stated in 7741 MEAN HOLDING TIME ABOVE
DEFINED THRESHOLD in Base Station Alarms (7000-7999).
2. If the alarm is not cancelled after the end of the measurement period during which
the channel that caused the alarm is allocated or released normally, collect all the
information needed for a Problem Report, and contact Nokia Siemens Networks for
further investigations. For instructions, see Collecting alarm 7741 logs in BSC
Problem Reporting.

3.8

Alarm 2725 ADJACENT CELL IDENTIFIER CONFIGURATION ERROR is raised


Symptoms
The alarm is raised when there are problems with adjacent cell identifications. An
external handover attempt is interrupted, and the call continues in the source cell. Handovers between the cells do not work until the problem is corrected.
Either the BSC or MSC can detect the problem.

When the BSC detects the problem, counters 004100 MSC O ADJ CELL ID ERR
and 500513 ADJ CELL ID ERR are updated.
When the MSC detects the problem, counters 004100 MSC O ADJ CELL ID ERR
and 500926 M INVALID CELL are updated.

Possible causes
The source cell's adjacent cell information in the BSS Radio Network Configuration
Database (BSDATA) is incorrect. The source BSC notices this from the HANDOVER
COMMAND message received from the MSC. Layer 3 information in the message

20

Id:0900d8058066eb8b

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with circuit-switched calls

contains the broadcast control channel (BCCH) frequency and the base station identity
code (BSIC) of the target cell. The source BSC compares the BCCH frequency and the
BSIC with the original information it has on the handover candidates. If these do not
match, the handover attempt is interrupted.
There are also other possible causes. The source cell's adjacent cell information in the
RCSPRB data area may be incorrect, or the HANDOVER COMMAND message may
have been generated incorrectly in the target BSC.
The source BSC or MSC can detect the error also if the routing information has been
defined incorrectly in the MSC. The MSC can detect the error also if the error is in the
target BSC, for example, if the target cell is locked.
Instructions
In the EVENT field of the alarm, check if the fault was detected by the MSC or BSC.
If the fault was detected by the MSC, implement the following steps:
1. Ensure that the routing information is defined correctly in the MSC.
2. Ensure that the target cell in the target BSC is not locked.
ZEEI;
If the fault was detected by the BSC, implement the following steps:
1. Check the source cell's adjacent cell information in the BSDATA.
ZEAO;
If the BCCH and BSIC information in the alarm match with the adjacent cell, the
cause of the alarm may be that the source cell's adjacent cell information in the
RCSPRB data area is incorrect, or the data area is corrupted.
Example:
BSCSG9902
BCSU-2
SWITCH
2004-03-24 09:45:36.96
** ALARM BCSU-2
1A002-27
HAS_BX
(0004) 2725 ADJACENT CELL IDENTIFIER CONFIGURATION ERROR
111d 01 02 02 623d
LOCATION AREA CODE......................(LAC)... 1000
CELL IDENTIFICATION.....................(CI)....27926
NETWORK COLOUR CODE.....................(NCC)...
BACKGROUND NETWORK COLOUR CODE..........(BNCC)..
BTS COLOUR CODE.........................(BCC)...
BACKGROUND BTS COLOUR CODE..............(BBCC)..
FREQUENCY NUMBER OF BCCH................(FREQ)..

**

2
2
623

If the BCCH and BSIC information in the alarm do not match with the adjacent
cell, the HANDOVER COMMAND has probably been generated incorrectly.
Example:

BSCSG9902
BCSU-2
SWITCH
2004-03-24
ALARM BCSU-2
1A002-27
HAS_BX
(0004) 2725 ADJACENT CELL IDENTIFIER CONFIGURATION ERROR
111d 01 06 02 623d

09:45:36.96

LOCATION AREA CODE......................(LAC)... 1000


CELL IDENTIFICATION.....................(CI)....27926
NETWORK COLOUR CODE.....................(NCC)...

DN05104459
Issue 2-2

Id:0900d8058066eb8b

21

Problems with circuit-switched calls

Handling Common Problem Situations in BSC

BACKGROUND NETWORK COLOUR CODE..........(BNCC)..


BTS COLOUR CODE.........................(BCC)...
BACKGROUND BTS COLOUR CODE..............(BBCC)..
FREQUENCY NUMBER OF BCCH................(FREQ)..

2
623

In both cases, a Base Station Controller Signalling Unit (BCSU) switchover solves
the problem.
2. Perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;
3. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Collecting alarm 2725 logs in BSC Problem Reporting.

3.9

SIGTRAN A interface is down (UA-INS)


When suspecting that there is a problem with the SIGTRAN A interface, see SIGTRAN
A interface in the BSC, Signalling Transport over IP (M3UA and IUA) and BSC IP Site
Connectivity Guidelines for more information on the IP transport essentials required for
the SIGTRAN A interface.
Symptoms
The BSC is not able to provide circuit-switched (CS) services. Ongoing CS calls are
dropped and new CS call establishments fail.
Possible causes
The A interface may be down because transmission is not working. The purpose of the
following instructions is to help you to identify when the problem is caused by IP transport in the A interface.
Instructions
1. Check the status of the A interface.
a) Interrogate the signalling connection control part (SCCP) subsystem states. The
A interface uses the base station system application part (BSSAP) subsystem.
ZNHI;
b) Interrogate the A interface signalling point state.
ZNRI:<national network number>;
c) Interrogate the signalling route state.
ZNVI:<national network number>;
d) Interrogate the signalling link state.
ZNLI;
If all states related to it are AV-EX, the A interface is working normally.
If the states are UA-INS, the A interface is down, and the following alarms referring
to the signalling point code in question are also active. In the example below, the
signalling point code is 201. You can check the alarms with the following command:
ZAHO:MCMU;
Example:
ZAHO:MCMU;
2064 ROUTE SET UNAVAILABLE
00000201 08 04
2070 LINK SET UNAVAILABLE
0010 01 00000201 08

22

Id:0900d8058066eb8b

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with circuit-switched calls

2241 SCCP SUBSYSTEM PROHOBITED


01 08 00000201 01
2. Verify that IP transport is used in the A interface in question.
Check the signalling link settings in the A interface.
ZNSI:NA0;
Example:
NSI:NA0,;
BSC3i

BSC21

2007-08-07

10:09:09

INTERROGATING SIGNALLING LINK SET DATA


NET
--NA0

SP CODE H/D
-----------------0201/00513

LINK SET
---------16 MSCI

ASSOCIATION SET
LS STATE
--------------------- -------0 TOMSCI
UA
LINK TEST NOT ALLOWED

IP LINK
------0

COMMAND EXECUTED
If there is a configured association set for the signalling link, it means that IP transport is used in the A interface.
3. Investigate if the cause of the problem is in IP transport.
a) Check the association states in the association set.
ZOYI:NBR=<association set id>:A;
Example:
OYI:NBR=0:A:;
LOADING PROGRAM VERSION 5.8-0
BSC3i

BSC21

2007-08-07

10:12:15

INTERROGATING ASSOCIATION SET DATA


ASSOCIATION SET NAME
-------------------TOMSCI

ASSOC SET ID
-----------0

ASSOC.
ASSOC ID
IND
UNIT
IN UNIT
--------- --------0
BCSU-1
2

ROLE
-------CLIENT

PARAMETER SET
NAME
STATE
---------------- -------------------SS7
UP-PROCEEDING

SOURCE ADDRESS 1 . . . .
SOURCE ADDRESS 2 . . . .
SOURCE PORT . . . . . .
PRIMARY DEST. ADDRESS .
SECONDARY DEST. ADDRESS
DESTINATION PORT . . . .
DATA STREAM COUNT . . .

DN05104459
Issue 2-2

SCTP USER
--------M3UA

.
.
.
.
.
.
.

:
:
:
:
:
:
:

10.16.153.85
10.16.153.101
EPHEMERAL
10.16.143.69/26
10.16.143.133/26
2905
16

Id:0900d8058066eb8b

23

Problems with circuit-switched calls

Handling Common Problem Situations in BSC

ASSOC.
ASSOC ID
IND
UNIT
IN UNIT
--------- --------1
BCSU-5
1

PARAMETER SET
NAME
STATE
---------------- -------------------SS7
UP-PROCEEDING

SOURCE ADDRESS 1 . . . .
SOURCE ADDRESS 2 . . . .
SOURCE PORT . . . . . .
PRIMARY DEST. ADDRESS .
SECONDARY DEST. ADDRESS
DESTINATION PORT . . . .
DATA STREAM COUNT . . .
SPECIFICATION VERSION .
TRAFFIC MODE . . . . . .
ASP MESSAGES . . . . . .
REGISTRATION REQUEST . .
SSNM MESSAGES BROADCAST
NETWORK APPEARANCE . . .
ASP MESSAGES IN IPSP . .
ROUTING CONTEXT . . . .
FIRST DATA STREAM NUMBER

.
.
.
.
.
.
.
.
.

:
:
:
:
:
:
:
:
:

.
.
.
.
.
.
.

:
:
:
:
:
:
:

10.16.153.86
10.16.153.102
EPHEMERAL
10.16.143.70/26
10.16.143.134/26
2905
16

1.0 (RFC)
LOAD-SHARE
YES
YES
NO
8
NO
--1

COMMAND EXECUTED
Association states other than ASP-ACTIVE (for example, UP-PROCEEDING in
the example above) indicate defective IP addresses. Note down the addresses.
If the cause of the problem turns out to be in IP transport, you will need them in
troubleshooting later on.
b) Check active alarms.
ZAHO:MCMU;
Example:
ZAHO:MCMU,;
3159 SCTP ASSOCIATION LOST
03 0000 0000 0004 0001
If there is at least one association in the ASP-ACTIVE state, IP transport is working.
If none of the associations are in the ASP-ACTIVE state, and the alarm 3159 referring to the association set in question is also active, the cause of the problem is in
IP transport. In the example above, the association set id is 0.
4. For corrective actions, see Problems with IP transport.
When the problem is corrected, the alarms are cancelled automatically, and the A
interface returns to the AV-EX state.

24

Id:0900d8058066eb8b

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

4 Problems with packet-switched calls


All the problem situations listed below may occur both in PCU1 and PCU2. The PCU log
writings appearing in Symptoms are, however, PCU1 specific.
Also note that some of the example printouts have been truncated to include only the
information that is necessary from the point of view of the problem in question. In addition, in the example printouts, <no.> stands for the actual number displayed in the actual
problem situation.
If IP is used as the transport medium, also see Problems with IP transport when troubleshooting the problem situations below.
For an overview, see Overview of common problem situations in BSC.

4.1
4.1.1

Problems with TBF establishment


TBF establishment fails due to lack of Abis channel resources
Symptoms
Temporary block flow (TBF) establishment is terminated, and in the PCU1 log, the following kind of log print out indicates that there are no valid BTSs with active channels in
the segment:
Example:

USER TEXT: chm_select_bts


USER DATA: SEG seg_id = 157 has no valid BTSs (whose active ch count > 0)
Here is an example of the corresponding log In PCU2 at CRITICAL level:
Example:
USER TEXT
USER DATA

: [..\..\pq2\pdm\res_mgr\src\pdm_resmgr_ch_alloc.
: PDM CRITICAL ERROR:Resource allocation failed, cause [7]
Here cause = 7 denotes PDM_RES_FAIL_DUE_CH.
Counters 072079 NO RADIO RES AVA UL TBF and 072080 NO RADIO RES AVA DL
TBF are also updated.
In this situation, no Abis channel resources are allocated to the MS because there are
no timeslots available in the GPRS/EDGE territory of the segment. However, to some
extent this is quite normal. Corrective actions are needed only if the symptoms occur
repeatedly.
Possible causes
This problem may be caused by problems in synchronisation, or by some other kinds of
problems in the GPRS/EDGE territory. In general, this problem indicates that there is
something wrong in the GPRS/EDGE territory, and it should be investigated further.
Instructions
Find out if there are any problems with synchronisation or problems with the
GPRS/EDGE territory currently on. Solving them may help to solve this problem, too.

DN05104459
Issue 2-2

Id:0900d8058066eb8e

25

Problems with packet-switched calls

Handling Common Problem Situations in BSC

For more information, see synchronisation-related problems in Problems with transmission in the Abis interface and GPRS/EDGE territory failures.

4.2
4.2.1

Problems with GPRS/EDGE cell changes


High NCCR failure rate
Symptoms
After Network Controlled Cell-reselection (NCCR) has been activated, counters of 95
GPRS Cell Re-selection Measurement show a high number of failed NCCR cell
changes. This measurement type contains several failure counters, of which 095007
NCCR FAIL NO RESPONSE and 095013 NCCR FAIL NO FLUSH IN TIME may show
higher values than the other counters.
Possible causes
There are several different scenarios that may cause the PCU to update these counters.
Some counter updates are caused by MS behaviour and some are caused by the
system overall.
If counter 095007 NCCR FAIL NO RESPONSE is updated:

The cause may be an MS fault where the MS uses different temporary logical link
identity (TLLI) values in the PACKET RESOURCE REQUEST (PRR) message and
data blocks during 1-phase access contention resolution. This faulty behaviour
leads to a contention resolution failure, after which the MS moves back to the source
cell sending a PACKET CELL CHANGE FAILURE (PCCF) message with the No
response on target cell cause.
The cause may be an MS fault where an NCCR cell change fails because it is triggered based on faulty information from the MS. The MS sends a PACKET MEASUREMENT REPORT (PMR) message containing the highest possible RX level
values for neighbouring cells, which may make the PCU initiate a NCCR cell change
with the PACKET CELL CHANGE ORDER message. If the following PMR
messages by the MS show that the actual RX level is much worse than the one that
the MS reported in the first PMR message, and the decision on the cell change has
already been made, the cell change cannot be cancelled.
The cause may be a heavy multiplexing situation where the PCU does not
schedule an uplink state flag (USF) frequently enough for an MS whose contention
resolution procedure is ongoing. Usually the PCU schedules one USF turn immediately after the IMMEDIATE ASSIGN ACK message has been received from the
BTS, but with EGPRS packet channel request (EPCR) 1-phase access, the MS
uses this scheduled USF turn for sending the PACKET RESOURCE REQUEST
(PRR) message. If the MS cannot send even one data block because of a missing
USF within the T3141 timer, the uplink TBF establishment is abnormally stopped.
This causes a contention resolution failure, after which the MS moves back to the
source cell sending the PCCF message with the No response on target cell cause.

If counter 095013 NCCR FAIL NO FLUSH IN TIME is updated:

26

The cause may be a situation where the MS receives a new TLLI value from the
serving GPRS support node (SGSN) during a routing area update and attach procedure. If the MS starts to use this TLLI in PACKET MEASUREMENT REPORT
(PMR) messages, and an NCCR cell change occurs before the SGSN has sent

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

downlinkLLC PDUs in downlink direction with the new TLLI, the SGSN sends the
flush LL-PDU to the BSC with the old TLLI. This causes a situation where the PCU
is unable to merge the occurred NCCR cell change and flush LL-PDUs together
because it received the PMR message and sent the PCCO message with a different
TLLI than the SGSN used in the flush LL-PDU. As a result, the PCU updates the
counter 095013 NCCR FAIL NO FLUSH IN TIME.
Instructions
A high NCCR failure rate does not necessarily require corrective actions. If the
symptoms occur repeatedly, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see Reporting problems with NCCR cell changes (PCU1) or Reporting problems with NCCR cell
changes (PCU2) in BSC Problem Reporting.

4.3

Problems with transmission in the Abis interface


For the most part, transmission problems in the Abis interface are either related to Abis
synchronisation or Dynamic Abis configuration. Both of these problem types may seriously impair GPRS/EDGE functionality.
Abis synchronisation
The PCU needs to adapt to the radio interface time division multiple access (TDMA)
frame timing and frame numbering. In the Abis interface, this means that one PCU frame
is sent and one is received in each packet data channel (PDCH) once within every 20
ms period. The PCU implements the channel synchronisation, the frame numbering,
and the PCU frame management with digital signal processors (DSP).
When there are problems with Abis synchronisation, data transfer is not possible in the
affected cell. The following alarms may also be raised:

7725 TRAFFIC CHANNEL ACTIVATION FAILURE (cause code 2)


The problem is on a radio timeslot (RTSL) that is in GPRS data use.
7738 BTS WITH NO TRANSACTIONS (supplementary info 1, cause code 10)
The problem may be in the synchronisation of a GPRS RTSL.

Dynamic Abis configuration


The purpose of Dynamic Abis is to share Abis transmission capacity between cells so
that lower overall Abis capacity is needed. This is accomplished by using sharable
EGPRS dynamic Abis pool (EDAP) areas. Dynamic Abis configuration must be planned
carefully. Otherwise Dynamic Abis may cause problems, due to which the maximum
possible throughput is not achieved.

4.3.1

Continuous resynchronisation
Symptoms
In continuous resynchronisation, an active GPRS channel repeatedly loses block synchronisation, and then acquires it immediately back again. As a result, data transfer is
disturbed.
Even though continuous resynchronisation may block almost all traffic from the cell, it is
quite difficult to detect. No synchronisation-related alarms are necessarily raised, but the

DN05104459
Issue 2-2

Id:0900d8058066eb8e

27

Problems with packet-switched calls

Handling Common Problem Situations in BSC

failed TBF allocation counters 072079 NO RADIO RES AVA UL TBF and 072080 NO
RADIO RES AVA DL TBF may show increased values and point to this problem.
In addition, alarm 7738 BTS WITH NO TRANSACTIONS with cause code 10 (no successful GPRS transactions) may be raised.
Possible causes
There are several possible causes:

The EGPRS dynamic Abis pool (EDAP) may have been configured incorrectly.
The EDAP and the TRXs tied to it may not be using a single PCM cables. If they use
separate PCM cables, transmission timing between the cables is most likely to differ.
This causes a timing difference between the EDAP and the TRXs with the result that
synchronisation is not successful.
An ET card is out of order.
The PCU receives illegal frames from the BTS or the PCU DSP, or the frames are
missing.
There are internal and external faults in the Abis interface.
The BTS starts resynchronisation for some BTS-internal reason.

Instructions
1. Check the transmission.
Especially, pay attention to the ETs and PCM cables because they may often be the
cause of this problem.
2. Check the EDAP configuration.
Especially, make sure that the EDAPs are configured identically both in the BSC and
the BTS.
For more information on EDAP configuration, see Dynamic Abis System Feature
Description.
3. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Collecting synchronisation logs (alarm 7725, PCU1) or Collecting synchronisation
logs (alarm 7725, PCU2) in BSC Problem Reporting.

4.3.2

Unsuccessful initial synchronisation or resynchronisation


Symptoms
The PCU has an internal timer of 45 seconds for synchronisation. If this timer expires
before the packet data channel (PDCH) acquires Abis synchronisation, the following
error is printed to the PCU1 log:
Example:
USER TEXT: PCU block synchronization timeout (F)
USER DATA: Synchronization failed:
Example:
In case of GPRS channels, the following log writing appears in PCU2 logs when unsuccessful or resynchronization occurs:

USER TEXT
USER DATA

28

: [<DSP ID:0>.\pfd_psw_if.c][254][33]
:

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

PFD CRITICAL ERROR:Channel failed


Cause: Sync Loss detected for GPRS channels
SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] fail_tsl:[0x80]
configured_tsl:[0xF0]

active_tsl:[0x70]

In case of EGPRS channels, the following log writing appears in PCU2 logs when unsuccessful or resynchronization occurs:
USER TEXT
USER DATA

: [<DSP ID:0>.\pfd_psw_if.c][274][34]
:

PFD CRITICAL ERROR:Channel failed


Cause: Sync Loss detected for EGPRS channels
SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] fail_tsl:[0x80]
active_tsl:[0x70] configured_tsl:[0xF0]
SMCH SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] TSL:[7]
In these logs, the fields fail_tsl, active_tsl and configured_tsl are printed in the form of
bitmap where RTSL 7 is represented by bit 8 and RTSL 0 is represented by bit 0. For
example Failed RTSL 7 is printed as fail_tsl:[0x80].
This error may occur either in initial synchronisation or in resynchronisation.
If the error repeats itself 8 times in a row, alarm 7725 TRAFFIC CHANNEL ACTIVATION FAILURE is also raised.
Possible causes
There are several possible causes:

The EGPRS dynamic Abis pool (EDAP) may have been configured incorrectly.
The EDAP and the TRXs tied to it may not be using a single PCM cable. If they use
separate PCM cables, transmission timing between the cables is most likely to differ.
This causes a timing difference between the EDAP and the TRXs with the result that
synchronisation is not successful.
An ET card is out of order.
The PCU receives illegal frames from the BTS or the PCU DSP, or the frames are
missing.
There are internal or external faults in the Abis interface.

Instructions
1. Check the transmission.
Especially, pay attention to the ETs and PCM cables because they may often be the
cause of this problem.
2. Check the EDAP configuration.
Especially, make sure that the EDAPs are configured identically both in the BSC and
the BTS.
For more information on EDAP configuration, see Dynamic Abis System Feature
Description.
3. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Collecting synchronisation logs (alarm 7725, PCU1) or Collecting synchronisation
logs (alarm 7725, PCU2) in BSC Problem Reporting.

DN05104459
Issue 2-2

Id:0900d8058066eb8e

29

Problems with packet-switched calls

4.3.3

Handling Common Problem Situations in BSC

No PCU synchronisation frames received from the BTS


Symptoms
Synchronisation does not start because the BTS does not send uplink PCU synchronisation frames to the PCU. If this state lasts for 45 seconds, the PCU-internal synchronisation timer expires, and the following error is printed to the PCU1 log:
Example:
USER TEXT: PCU block synchronization timeout (F)
USER DATA: No synchronization frames:
In case of GPRS channels, the following log writing appears in PCU2 logs when unsuccessful or resynchronization occurs:
Example:

USER TEXT
USER DATA

: [<DSP ID:0>.\pfd_psw_if.c][254][33]
:

PFD CRITICAL ERROR:Channel failed


Cause: Sync Loss detected for GPRS channels
SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] fail_tsl:[0x80]
active_tsl:[0x70] configured_tsl:[0xF0]
In case of EGPRS channels, the following log writing appears in PCU2 logs when unsuccessful or resynchronization occurs:
Example:
USER TEXT
USER DATA

: [<DSP ID:0>.\pfd_psw_if.c][254][33]
:

PFD CRITICAL ERROR:Channel failed


Cause: Sync Loss detected for GPRS channels
SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] fail_tsl:[0x80]
active_tsl:[0x70] configured_tsl:[0xF0]
SMCH SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] TSL:[7]
If the problem repeats itself 8 times in a row, alarm 7725 TRAFFIC CHANNEL ACTIVATION FAILURE is raised.
Possible causes
There are several possible causes:

An ET card is out of order.


The PCU receives illegal frames from the BTS or the PCU DSP, or the frames are
missing.
There are internal or external faults in the Abis interface.
The BTS does not send uplink data frames.

Instructions
1. Check the transmission.
Especially, pay attention to the ETs and PCM cables because they may often be the
cause of this problem.

30

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

2. If nothing seems to be wrong with the transmission, collect all the information
needed for a Problem Report and contact Nokia Siemens Networks for further investigations. For instructions, see Collecting synchronisation logs (alarm 7725, PCU1)
or Collecting synchronisation logs (alarm 7725, PCU2) in BSC Problem Reporting.

4.3.4

BPN jump in synchronisation time


Symptoms
The PCU uses block period numbers (BPN) to follow the order in which it receives Abis
blocks from the Abis interface. BPNs are derived from PCM frame numbers.
Usually, the PCU receives Abis blocks in a sequential order one after another during
channel synchronisation. If the order of the BPNs is not sequential, or some BPNs are
missing, a BPN jump occurs, and synchronisation cannot be acquired. However, the
synchronisation procedure continues.
Every time the PCU1 notices a BPN jump during channel synchronisation, it prints the
following line to the PCU1 log:
Example:
USER TEXT: BPN jump in synchronization time
USER DATA: SEG id/BTS id/TRX id, PCU_TRX id, RTSL id
If BPN jumps disturb the synchronisation procedure to the degree that synchronisation
is not acquired within 45 seconds, the PCU-internal synchronisation timer expires, and
a synchronisation failure notification is also printed to the PCU1 log:
Example:
USER TEXT: PCU block synchronization timeout (F)
USER DATA: Synchronization failed:
If the synchronisation fails 8 times in a row, alarm 7725 TRAFFIC CHANNEL ACTIVATION FAILURE is raised. Alarm 7738 BTS WITH NO TRANSACTIONS may also be
raised.
No logs at CRITICAL level are observed at PCU2 for BPN jump in synchronization time.
If BPN jumps disturb the synchronization procedure to the degree that synchronization
is not acquired within 45 seconds, the PCU-internal synchronization timer expires, and
a synchronization failure notification is also printed to the PCU log:
Example:
In case of GPRS channels:

USER TEXT
USER DATA

: [<DSP ID:0>.\pfd_psw_if.c][254][33]
:

PFD CRITICAL ERROR:Channel failed


Cause: Sync Loss detected for GPRS channels
SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] fail_tsl:[0x80]
active_tsl:[0x70] configured_tsl:[0xF0]
In case of EGPRS channels:

DN05104459
Issue 2-2

Id:0900d8058066eb8e

31

Problems with packet-switched calls

USER TEXT
USER DATA

Handling Common Problem Situations in BSC

: [<DSP ID:0>.\pfd_psw_if.c][274][34]
:

PFD CRITICAL ERROR:Channel failed


Cause: Sync Loss detected for EGPRS channels
SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] fail_tsl:[0x80]
active_tsl:[0x70] configured_tsl:[0xF0]
SMCH SEG:[11] BTS:[111] EXT_TRX:[9] TRX_Ix:[4] TSL:[7]
Possible causes
There are two probable causes for BPN jumps:

If Abis blocks are completely missing, the problem is that the blocks are corrupted
or not correctly received from the Abis interface.
If all Abis blocks are received, but their order is wrong, the problem is usually inside
the PCU DSP block buffering.

Instructions
1. Check the transmission.
Especially, pay attention to ETs and PCM cables because they may often be the
cause of missing Abis blocks.
2. If nothing seems to be wrong with the transmission, the PCU DSP may be causing
the problem. If possible, perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;
3. If this workaround helps, but the problem keeps reappearing every now and then,
collect all the information needed for a Problem Report and contact Nokia Siemens
Networks for further investigations. For instructions, see Collecting synchronisation
logs (alarm 7725, PCU1) or Collecting synchronisation logs (alarm 7725, PCU2) in
BSC Problem Reporting.

4.3.5

TBFs do not have enough EDAP resources


Symptoms
Counters 076006 UL TBFS WITHOUT EDAP RES, 076007 DL TBFS WITHOUT EDAP
RES or 076008 DL TBFS WITH INADEQUATE EDAP RES show higher values than
expected, for example, with a single MS. Typically, a zero value is expected for counter
076008, but a non-zero value appears. Due to the inadequate EGPRS dynamic Abis
pool (EDAP) resources, throughput is smaller than expected.
Counters 076019 UL MCS LIMITED BY PCU or 076020 DL MCS LIMITED BY PCU may
also show high values.
In addition, GPRS/EDGE territory upgrade failures or partial GPRS/EDGE territory
upgrades may appear in the PCU1 log. However, note that this log writing alone is only
suggestive and needs other supporting information.
Example:
USER TEXT: DAM: dam_add_tsls_req__r
USER DATA: DPA returned psw_cause 9

32

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

Possible causes
There are two main causes:

Dynamic Abis dimensioning is not optimal. For example, there are too many or too
few EDAPs, or the EDAP sizes are not appropriate to the traffic.
The PCU suffers from internal digital signal processor (DSP) limitations; for
example, DSP grouping limitation and 20 channels/DSP limitation. These limitations
impose trade-offs on the optimisation of DSP capacity between the overall EDAP
configuration and single EDAPs.

These two causes may also interact with each other. If Dynamic Abis dimensioning is
not optimal, DSP resources may limit the multislot coding scheme (MCS) easier and
more frequently than in an optimal situation. On the other hand, ignoring the DSP limitations may lead to less optimal Dynamic Abis dimensioning.
Instructions
1. Analyse the network and EDAP configurations.
2. Based on the analysis, redimension the Dynamic Abis and/or add more DSP capacity.
For more information on Dynamic Abis dimensioning, see Abis EDGE Dimensioning.

4.3.6

EDAP configuration fails


Symptoms
Alarm 3068 EGPRS DYNAMIC ABIS POOL FAILURE is raised. This alarm implies a
missing or incomplete EDAP configuration.
In addition, alarm 3273 (E)GPRS TERRITORY FAILURE may be raised. This alarm
may imply sleeping, missing, or bouncing GPRS/EDGE timeslots, or a reduced number
of timeslot allocations.
In some cases, errors on the existing channels are printed to the PCU1 log. During
EDAP configuration procedures, the number of channels should be zero.
Example:

USER TEXT: DAM: dam_pcu_edap_table__r


USER DATA: Number of active GPRS/EGPRS channels <count> is not zero.
USER TEXT: DAM: dam_pcu_edap_info__r
USER DATA: Number of active GPRS/EGPRS channels <count> is not zero.
In some cases, an incorrect internal Dynamic Abis Manager (DAM) state in the PCU1 is
also printed to the PCU1 log. During EDAP configuration procedures, the PCU1 (DAM)
accepts only certain messages at certain stages.
Example:
USER TEXT: DAM: dam_dmx_msg_handler
USER DATA: pcu_edap_table_s is received in illegal DAM state <no.>...
USER TEXT: DAM: dam_dmx_msg_handler

DN05104459
Issue 2-2

Id:0900d8058066eb8e

33

Problems with packet-switched calls

Handling Common Problem Situations in BSC

USER DATA: pcu_edap_info_s is received in illegal DAM state <no.> ...


Following log writing appears in PCU2 logs if EDAP configuration fails because active
channels are already present.
Example:
USER TEXT
USER DATA

: [.\abm_bsc.c][109][17]
: ABM CRITICAL: EDAP_TABLE failed.
PCU_NOT_READY: ACTIVE channels present. Cause:EDAP_CAUSE_NOT_READY[4]

USER TEXT
USER DATA

: [.\abm_bsc.c][561][17]
: ABM CRITICAL: EDAP_INFO_CREATE failed.
PCU_NOT_READY: ACTIVE channels present. Cause:EDAP_CAUSE_NOT_READY[4].
Following log writing appears in PCU2 logs if EDAP configuration fails because EDAP
Id sent in the message does not exist at PCU2.
Example:
USER TEXT
: [.\abm_bsc.c][483][25]
USER DATA : ABM CRITICAL: Edap Id:72 not configured at PCU.
Cause:EDAP_CAUSE_UPDATE_ERROR[3]

Following log writing appears in PCU2 logs if EDAP configuration fails because configuration message is received in incorrect Abis Manager (ABM) state.
Example:
USER TEXT
: [.\abm_bsc.c][2238][98]
USER DATA : ABM CRITICAL: EDAP_TABLE Failed.
Message in unexpected ABM state:0. Cause EDAP_CAUSE_NOT_READY[4]
USER TEXT
: [.\abm_bsc.c][2350][156]
USER DATA : ABM CRITICAL: EDAP_INFO Failed.
Message in unexpected ABM state:0. Cause EDAP_CAUSE_NOT_READY[4]
Possible causes
The failed EDAP configuration has probably raised the alarm 3068. As a result, the PCU
has not been able to upgrade any GPRS/EGPRS channels, which has then raised the
alarm 3273. It is possible that incorrect EDAP configuration commands have been
given.
Instructions
1. Check all MML commands given before the alarms 3273 and 3068 were raised.
2. If the EDAP configuration had been done properly, see GPRS/EDGE territory
failures for further information on possible causes.
3. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Collecting EDAP configuration failure logs (PCU1) or Collecting EDAP configuration
failure logs (PCU2) in BSC Problem Reporting.

34

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

Workarounds
Perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;

4.4
4.4.1

Problems with transmission in the Gb interface


Inconsistent BVCI states between the BSC, the PCU and the SGSN
Symptoms
The BSSGP virtual connection identifier (BVCI) states are inconsistent in the MML printouts of the BSC and the SGSN. For example, the state of a BVCI at the BSC may be
WORKING, while at the SGSN its state may be UNKNOWN.
Inconsistent BVCI states can lead to a situation where GPRS/EDGE cells do not relay
data at all. This raises the alarm 7738 BTS WITH NO TRANSACTIONS.
Inconsistent BVCI states can also be the cause of alarm 3032 BSSGP VIRTUAL CONNECTION PROTOCOL ERROR with causes 0x9 (BVCI blocked) and 0x5 (BVCI Unknown).
Possible causes
Inconsistent BVCI states may be caused by failures in BVC-RESET, BVC-BLOCK, or
BVC-UNBLOCK procedures.
Instructions
1. Collect information needed for a Problem Report. For instructions, see Reporting
problems with Gb interface (PCU1) or Reporting problems with Gb interface (PCU2)
in BSC Problem Reporting.
2. Try out the workarounds below.
3. If the problem persists, collect the information for a Problem Report again and
contact Nokia Siemens Networks for further investigations.
Workarounds
Typically, recreating the BVCI solves the problem.
To recreate a BVCI, disable and enable GPRS in the segment.
ZEQV:BTS=<BTS_identification>:GENA:N;
ZEQV:BTS=<BTS_identification>:GENA:Y;
If disabling and enabling GPRS does not help, reset the network service entity (NSE).
ZFXR:NSEI=<nsei_id>;
If NSE reset does not help, perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;

DN05104459
Issue 2-2

Id:0900d8058066eb8e

35

Problems with packet-switched calls

4.4.2

Handling Common Problem Situations in BSC

BSSGP protocol error raised with cause code 0x20 or 0x21


Symptoms
The base station system GPRS protocol (BSSGP) raises the alarm 3032 BSSGP
VIRTUAL CONNECTION PROTOCOL ERROR with cause code 0x20 (Semantically
incorrect PDU) or 0x21 (Invalid mandatory information).
Possible causes
A typical cause is an erroneous, zero-length uplink LLC PDU sent by the BSC to the
SGSN. The SGSN responds with a STATUS PDU either with cause code 0x20 or 0x21,
depending on the SGSN type and manufacturer.
If the alarm reoccurs, it means that the peer entities are not compatible. An update to
the protocol software may be required.
Instructions
To solve the root cause of the problem, collect all the information needed for a Problem
Report and contact Nokia Siemens Networks for further investigations. For instructions,
see Reporting problems with Gb interface (PCU1) or Reporting problems with Gb interface (PCU2) in BSC Problem Reporting.

4.4.3

BVCI operational state remains UNBLOCKED


Symptoms
The BSC MML command ZEQO shows the BSSGP virtual connection identifier's (BVCI)
operational state as UNBLOCKED. If the operational state remains UNBLOCKED, it
may lead to a situation where GPRS cells do not relay data at all. This raises the alarm
7738 BTS WITH NO TRANSACTIONS.
Possible causes
The BVCI has been successfully created on the SGSN, but the GPRS territory does not
have any channels yet. Therefore, the initial FLOW-CONTROL-BVC PDU is not completed.
Instructions
1. Output the dedicated GPRS capacity (CDED)/default GPRS capacity (CDEF)
settings of the BTSs.
ZEQO:BTS=<BTS id>:GPRS;
2. In the CDED/CDEF settings, check if the segment has GPRS/EDGE capacity.
3. Depending on the outcome, implement one of the following options:
If the segment does not have GPRS/EDGE capacity, proceed to step 4.
If the GPRS territory has at least one channel, try out the workaround below (recreating a BVCI).
4. Add GPRS/EDGE capacity by increasing both CDED and CDEF values at least to
1%.
ZEQV:BTS=<bts_id>:GENA=N;
ZEQV:BTS=<bts_id>:CDED=1,CDEF=1;
ZEQV:BTS=<bts_id>:GENA=Y;
5. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see

36

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

Reporting problems with Gb interface (PCU1) or Reporting problems with Gb interface (PCU2) in BSC Problem Reporting.
Workarounds
If the GPRS territory has at least one channel, recreate the BVCI.
To recreate a BVCI, disable and enable GPRS in the segment.
ZEQV:BTS=<BTS_identification>:GENA:N;
ZEQV:BTS=<BTS_identification>:GENA:Y;
If disabling and enabling GPRS does not help, perform a BCSU switchover.
ZUSC:BCSU,<WO_index>:SP,;

4.4.4

Gb over IP: DX error 16246 appears


Symptoms
When the ZFXK command (creating an NS-VC), the ZFXR command (resetting an NSE),
or the ZFXI command (outputting NS-VL data) is executed, the following DX error
message appears:
Example:

/*** DX ERROR: 16246 ***/


/*** BSC DB AND PCU CONFIGURED OK BUT NO RESPONSE RECEIVED FROM SGSN, \
STILL TRYING ***/
Possible causes
Unsuccessful ZFXK or ZFXR commands hint at problems with the SGSN configuration/Gb over IP LAN, whereas the unsuccessful ZFXI command may mean that the
PCU has lost the IP address after a BCSU switchover.
Instructions
1. Check the active alarms and the alarm history, and apply the applicable alarm
instructions.
2. If the alarm data does not help in solving the problem, check whether the IP
addresses are configured.
ZQRI;
3. If the ZQRI command does not help in solving the problem, check the whole Gb over
IP LAN status and configuration. For instructions, see Problems with IP transport.
4. If checking the configuration does not help, and the fault seems to be in the BSC,
collect all the information needed for a Problem Report and contact Nokia Siemens
Networks for further investigations. For instructions, see Reporting problems with IP
transport in BSC Problem Reporting. If the fault seems to be PCU-related, see
Reporting problems with Gb interface (PCU1) or Reporting problems with Gb interface (PCU2) in BSC Problem Reporting.
There is no need to repeat the MML commands after the problem has been solved.
Workarounds
There are no known workarounds for this problem situation because the problem is most
probably in the IP LAN network.

DN05104459
Issue 2-2

Id:0900d8058066eb8e

37

Problems with packet-switched calls

4.5
4.5.1

Handling Common Problem Situations in BSC

Problems with performance


Low downlink GPRS/EDGE throughput
Symptoms
The following symptoms may indicate low downlink GPRS/EDGE throughput:

EDGE key performance indicators (KPI) dap_7a, tbf_16, blck_33, trf_235b, trf_236,
and frl_8a. For more information, see EDGE Key Performance Indicators.
Counter 090005 AVERAGE MS SPECIFIC BSSGP FLOW RATE and volumeweighted counters 090007090012. For more information, see 90 Quality of Service
Measurement.
Increased end-user download times.

Possible causes
Several factors may lower downlink throughput. For example, too small a GPRS/EDGE
territory, an incorrectly created EDAP, or bad conditions in the radio interface.
In the Gb interface (both Frame Relay and Gb over IP), low downlink throughput may
result from incorrect base station system GPRS protocol (BSSGP) flow control values.
In Gb over Frame Relay, the dimensioning of the interface may also be a limiting factor;
for example, the size of the Frame Relay bearer channel, or network service entity
(NSE) division into NS-VC(s).
In Gb over IP, a limiting factor may be user data protocol (UDP) packet dropping caused
by a duplex mode mismatch on the Gb over IP configuration.
Instructions
1. To ensure that too small a GPRS/EDGE territory is not causing the problem, check
that the territory has enough channels. If not, increase the number of dedicated
channels in the territory.
2. To ensure that insufficient EDAP resources are not causing the problem, check that
the EDAP is dimensioned correctly.
For more information, see TBFs do not have enough EDAP resources.
3. To ensure that the size of the Frame Relay bearer channel is not causing the
problem, check that its performance is high enough for fast GPRS/EDGE transfers.
The peak margin of the data volume can deviate a lot depending on, for example,
the amount of data volume, different coding schemes, throughput rates, and the
services offered. The smaller the size of the Frame Relay bearer channel, the
greater its effect on a single user. For GPRS, the Gb link should be at least 128k,
whereas for EGPRS it should be at least 256k.
For more information, see Gb EDGE Dimensioning.
4. To ensure that the values of the BSSGP flow control parameter are not causing the
problem, check the values of the parameter in the BSC.
ZWOI:49
The recommended values for BSSGP flow control in the BSC are given in Technical
Note No. 819 (BSSGP Flow Control Parameter Value Recommendation for
(E)GPRS). Note that the flow control parameters have dependencies on each other.
Therefore, the new values should be applied simultaneously.
5. The duplex-speed of the PCU is fixed to autonegotiate. To ensure that a duplex
mode mismatch on the Gb over IP configuration is not causing the problem, check

38

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

that the duplex-speed mode of the port in the other end of the Ethernet link is also
set to auto-negotiate.
For more information on the recommended duplex speed settings, see BSC LAN
topology in BSC Site IP Connectivity Guidelines.
6. If downlink throughput does not improve after these corrective actions, collect all the
information needed for a Problem Report and contact Nokia Siemens Networks for
further investigations. For instructions, see Reporting problems with performance
(PCU1) or Reporting problems with performance (PCU2) in BSC Problem Reporting.

4.6
4.6.1

Problems with territory operations


GPRS/EDGE territory failures
Symptoms
Alarm 3273 (E)GPRS TERRITORY FAILURE is active. This alarm may imply sleeping,
missing, or bouncing GPRS/EDGE timeslots, or a reduced number of timeslot allocations.
In addition, alarm 3068 EGPRS DYNAMIC ABIS POOL FAILURE may be active. This
alarm implies a missing or incomplete EDAP configuration.
The territory failures are printed to the PCU1 log. Most of these failures are written by
the dam_add_tsls_req__r function. For individual examples of the failures, see Possible
causes.
Possible causes
If alarm 3068 is active, the cause can be a failed EDAP configuration. Usually, in this
case the PCU1 (DAM) is not expecting territory upgrades yet. Therefore, the following
kind of log writing may appear in the PCU1 log:
Example:

USER TEXT: DAM: dam_add_tsls_req__r


USER DATA: DAM not ready to handle territory upgrade, dam_state = <no.>.
In the PCU2 log the following log writing appears if territory upgrade fails because EDAP
configuration has failed and alarm 3068 is active.
Example:
USER TEXT
: [.\psw_main.c][975][17]
USER DATA : [.\psw_abm_if.c][441] Territory Upgrade Failed: ABM failed
upgrade for BTS:3 with cause:16
Where cause = 16 is PSW_CAUSE_T_EDAP_NOT_READY_C
In the PCU2 log the following log writing appears if territory upgrade fails because only
partial upgrade was possible

DN05104459
Issue 2-2

Id:0900d8058066eb8e

39

Problems with packet-switched calls

Handling Common Problem Situations in BSC

Example:
USER TEXT
: [.\psw_main.c][975][17]
USER DATA : [.\psw_abm_if.c][756] Territory Upgrade Failed:
ABM managed partial upgrade for BTS: 26
In the PCU2 log the following log writing appears if there is a conflict over (E)GPRS territories
Example:
USER TEXT
: [.\psw_main.c][975][17]
USER DATA : [ .\psw_bsc_if.c] [1727]Territory Upgrade Failed:
Conflicting Information Received for BTS

It is also possible that Dynamic Abis dimensioning is not optimal. This may lead to the
rejection of territory upgrades or to partial territory upgrades due to a limited DSP capacity. In addition, EDAP traffic may also prevent upgrades temporarily. The following kinds
of PCU1 log writings may hint at these causes:
Example:
USER TEXT: DAM: dam_add_tsls_req__r
USER DATA: DPA returned psw_cause <no.> for partial upgrade

USER TEXT: DAM: dam_add_tsls_req__r


USER DATA: DPA returned psw_cause <no.>, whole upgrade unsuccessful.
Territory failures may also originate from conflicts over GPRS/EDGE territories between
the DX and the PCU, or inside the PCU. These conflicts may, in turn, be caused by
incomplete territory upgrades and downgrades. The following kinds of PCU1 log writings
may hint at conflicts over GPRS/EDGE territories:
Example:
USER TEXT: DAM: seg_bts_trx_conflict_for_pcu_trx
USER DATA:
USER TEXT: DAM: dam_delete_tsls
USER DATA: Conflict with DAM internal BTS<no.>/TRX<no.>.

USER TEXT: DAM: dam_delete_tsls


USER DATA: TRX not found in PCU TRX table:

USER TEXT: DAM: dam_delete_tsls


USER DATA: DAM DSP params invalid for PCU_TRX <no.>, RTSL <no.>

40

Id:0900d8058066eb8e

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with packet-switched calls

USER TEXT: DAM: dam_delete_tsls


USER DATA: PCU PCM params invalid for PCU_TRX <no.>, RTSL <no.>
Instructions
1. If alarm 3068 is active, ensure that the EDAP has been configured properly. For
more information, see EDAP configuration fails.
2. If log writings indicating unsuccessful territory upgrades appear in the PCU1 log, see
TBFs do not have enough EDAP resources for instructions.
3. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Reporting problems with GPRS/EDGE territory failures (PCU1) or Reporting
problems with GPRS/EDGE territory failures (PCU2) in BSC Problem Reporting.
Workarounds
Perform a BCSU switchover. It cleans the PCU's internal data structures, and thereby,
solves conflicts over GPRS/EDGE territories between the DX and the PCU.
ZUSC:BCSU,<WO_index>:SP,;

DN05104459
Issue 2-2

Id:0900d8058066eb8e

41

Problems with synchronisation

Handling Common Problem Situations in BSC

5 Problems with synchronisation


When the BSC and/or TCSM synchronisation fails, the synchronisation management
receives alarm information from several sources. This helps to locate the exact position
of the problem.
Recovery actions in synchronisation-related problems often involve replacing plug-in
units. For instructions, see Replacing plug-in units basics in Replacing Plug-in Units in
Base Station Controller and Transcoder.
For an overview, see Overview of common problem situations in BSC.

5.1

Incoming synchronisation from an external source fails


Symptoms
A failure in incoming synchronisation from an external source may raise one or several
of the following alarms:

2630 SYNCHRONIZATION SIGNAL CHANGED


2631 OPERATION MODE CHANGED TO PLESIOCHRONOUS
2632 OSCILLATOR FAILURE
2641 FAILURE IN SYNCHRONIZATION SIGNAL
1900 DEGRADED SLIP FREQUENCY
2925 SLIP FREQUENCY LIMIT EXCEEDED

The above-mentioned alarms 2630 and 2631 often occur in connection with alarm 2641.
Possible causes
The cause is more likely to be located outside than inside the BSC and/or TCSM.
Depending on the alarm(s) raised, the incoming synchronisation signal frequency may
be wrong, or there may be too much jitter, an alarm indication signal (AIS), or no signal
from the PCM used for the syncronisation input. There may also be a loopback somewhere on the PCM. It is also possible that the incoming syncronisation signal has slowly
drifted away from the nominal frequency to a frequency that is beyond the Clock and
Synchronisation Unit (CLS) capture range (+/- 2.5 ppm from the current oscillator frequency), or even beyond the CLS control range.
A faulty oscillator in the CLS may also trigger these alarms.
Instructions
If alarm 2632 OSCILLATOR FAILURE is raised, do the following:
1. Check the supplementary information field of the alarm to detect the origin of the
alarm.
If the error code in the supplementary info field is other than 01, follow the
instructions in 2632 OSCILLATOR FAILURE in Failure Printouts (2000-3999).
If the error code in the supplementary info field is 01, it may be that the alarm is
caused by a loopback somewhere on the PCM used for the synchronisation
input. Proceed to step 2 for corrective actions.
2. Remove the loopback, or, if it cannot be removed, change the PCM used for the synchronisation input.
3. If there is no loopback, check if the oscillator control word values in both the
working and spare CLS are close to the CLS control range end.

42

Id:0900d8058066eb91

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with synchronisation

If not, it may be that the oscillator of the CLS is faulty.


If yes, it may be that the incoming synchronisation signal frequency is wrong. In
this case, the origin of the problem may be in transmission outside the network
element, and troubleshooting with transmission specialists or other network
element specialists is needed to recover from the problem situation. If possible,
use the PCM analyser and frequency meter to verify the incoming synchronisation signal frequency and the CLS frequency.

If alarm 2641 FAILURE IN SYNCHRONIZATION SIGNAL is raised, check the supplementary information fields of the alarm to detect the origin of the alarm.

00 frequency of connected input below 3.7 kHz indicates that the ET has received
an AIS, that there is no signal on the PCM used for the synchronisation input, or that
the synchronisation cable between the ET and the Clock and Synchronisation Cartridge (CLOC) is missing, faulty, or misplaced. Check the condition of the trunk
circuit used for synchronisation and the cabling between the ET and the CLOC cartridge.
01 frequency of connected input over 4.5 kHz indicates that the synchronisation
cable between the ET and the CLOC cartridge is missing, faulty, or misplaced.
Check the cabling between the ET and the CLOC cartridge.
02 frequency of connected input over 3.7 kHz and below 4.5 kHz indicates that the
incoming synchronisation signal frequency is wrong. In this case, the origin of the
problem may be in transmission outside the network element, and troubleshooting
with transmission specialists or other network element specialists is needed to
recover from the problem situation. If possible, use the PCM analyser and frequency
meter to verify the incoming synchronisation signal frequency and the CLS frequency.

You can also calculate the frequency difference using the formula 125/slip
interval *2 Hz. To work out the slip interval, monitor the slip counters using the
YMO command and note down the time between the slip counter increments.

To detect which transmission directions suffer from synchronisation problems,


note down the number of ETs that trigger alarms 1900 DEGRADED SLIP FREQUENCY or 2925 SLIP FREQUENCY LIMIT EXCEEDED.
Workarounds
When encountering a problem situation where alarm 2641 FAILURE IN SYNCHRONIZATION SIGNAL is raised, and the CLS frequency has drifted beyond the CLS capture
range, but not beyond the CLS control range, try out the following steps:
1. Start forced use of input. It makes the CLS search for the input frequency from the
CLS control range.
ZDRS::U=2M1;
2. Wait for two minutes, and end the forced use of input.
ZDRS::U=OFF;
3. Wait until the synchronisation unit repair timer expires (typically 10 minutes), and
verify that the synchronisation is working again.
If alarm 2631 OPERATION MODE CHANGED TO PLESIOCHRONOUS is on, and you
cannot get the CLS synchronised, move the oscillator control word value to the centre
value. This way the oscillator frequency will remain closer to the nominal PCM frequency, and the incoming syncronisation signal is more likely to reach the CLS capture
range.

DN05104459
Issue 2-2

Id:0900d8058066eb91

43

Problems with synchronisation

Handling Common Problem Situations in BSC

DRO:CLS,<id>:W=32768;
The oscillator control word value starts slowly drifting towards the long time mean value.
Note that this is normal behaviour and requires no actions.

5.2

Clock and Synchronisation Unit fails


Symptoms
A CLS failure may raise one or several of the following alarms:

1630 RAM FAILURE IN SYNCHRONIZATION UNIT


2636 FAILURE IN OUTGOING CLOCK SIGNAL
2638 FAILURE IN BUS BETWEEN SYNCHRONIZATION UNITS
2639 FAILURE IN SYNCHRONIZATION UNIT SWITCHOVER
2642 CHECKSUM ERROR IN SYNCHRONIZATION UNIT ROM
2057 TG FAILURE IN SYNCRONIZATION UNIT
2764 CLS FAILURE

Possible causes
Depending on the alarm(s) raised, a CLS failure is caused by faults inside the CLS plugin unit or the Clock and Synchronisation Cartridge (CLOC), for example, in the power
feed of the CLOC cartridge.
Instructions
If alarm 2636 FAILURE IN OUTGOING CLOCK SIGNAL, 1630 RAM FAILURE IN SYNCHRONIZATION UNIT, or 2642 CHECKSUM ERROR IN SYNCHRONIZATION UNIT
ROM is raised, the hardware inside the CLS plug-in unit is clearly faulty. Move the CLS
plug-in unit to the SE state and replace it. For more detailed information on the conditions triggering these alarms, see Disturbance Printouts (1000-1999) and Failure Printouts (2000-3999).
If alarm 2638 FAILURE IN BUS BETWEEN SYNCHRONIZATION UNITS is raised,
there is a communication problem between the CLSs. The alarm may be raised in connection with normal maintenance actions, such as running CLS diagnostics, or removing
a plug-in unit. Other possible causes are faults in either one of the CLS plug-in units or
in the CLOC cartridge, for example, in the power feed of the CLOC. For corrective
actions, see 2638 FAILURE IN BUS BETWEEN SYNCHRONIZATION UNITS in Failure
Printouts (2000-3999).
If alarm 2639 FAILURE IN SYNCHRONIZATION UNIT SWITCHOVER is raised, it
means that a CLS switchover has failed. A typical cause is that forced control of the
CLS is on. Check if the yellow FCTRL LED is lit.

If the FCTRL LED is lit, forced control is on. Switch it off by pressing the FCTRL
switch.
If the FCTRL LED is not lit, there may be a hardware defect in either of the CLS plugin units. Replace both CLS plug-in units by using the FCTRL switch.

If alarm 2057 TG FAILURE IN SYNCRONIZATION UNIT is raised, the tone generator


programmable read-only memory (PROM) is probably missing, or the strappings
defining the PROM properties are faulty. Note that the system requires the PROMs even
if the tone generator is not used in the network element. For corrective actions, see
2057 TG FAILURE IN SYNCRONIZATION UNIT in Failure Printouts (2000-3999).

44

Id:0900d8058066eb91

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with synchronisation

If alarm 2764 CLS FAILURE is raised, there may be a failure inside the CLS plug-in unit
or in the timing signal distribution cabling between the CLOC and Clock and Alarm
(CLAC) cartridges. For corrective actions, see 2764 CLS FAILURE in Failure Printouts
(2000-3999).
Workarounds
Perform a CLS switchover. For instructions, see Performing a switchover in Recovery
and Unit Working State Administration.

5.3

Timing signal distribution fails


Symptoms
A failure in timing signal distribution may raise one or several of the following alarms:

1210 PHASE ADVANCE OF TIMING SIGNAL CHANGED


2052 SWITCH CLOCK FAILURE
2755 CARTRIDGE CLOCK FAILURE
2761 CLAB FAILURE

Possible causes
Depending on the alarm(s) raised, the problem is caused by faults inside the Clock and
Alarm Buffer (CLAB) plug-in units, inside the Clock and Alarm Cartridge (CLAC), in the
CLOC and CLAC cartridge intermediate cabling, in the cable distributing timing signals
to the functional units of the cabinet, or in the plug-in unit giving the alarm.
Instructions
If alarm 2052 SWITCH CLOCK FAILURE is raised without 2755 CARTRIDGE CLOCK
FAILURE, the problem is inside the Bit Group Switch (GSWB) timing signal distribution.
1. Check if the switching matrix plug-in units have a red clock alarm LED lit.
If only one switching matrix plug-in unit has a red clock alarm LED lit, replace
that plug-in unit.
If several switching matrix plug-in units have a red clock alarm LED lit, replace
the Switch Control Processor (SWCOP) plug-in unit.
2. If the problem persists, check the cable between the SWCOP plug-in unit and the
switching matrix plug-in units and change it, if needed.
If several 2755 CARTRIDGE CLOCK FAILURE alarms are raised within one cabinet,
the problem is probably in the working CLAB. Perform a CLAB switchover and replace
the CLAB. For more detailed information on the conditions triggering the alarm, see
2755 CARTRIDGE CLOCK FAILURE in Failure Printouts (2000-3999).
If only one 2755 CARTRIDGE CLOCK FAILURE alarm is raised within the CLAB, the
problem is probably in the plug-in unit giving the alarm, for example, the central processing unit (CPU), AS7, or the Message Bus Interface (MBIF) plug-in unit.
1. Perform a switchover and replace the plug-in unit giving the alarm.
2. If replacing the plug-in unit does not help, check if the CLAB cable distributing timing
signals to the plug-in unit is loose or faulty, and change it, if needed.
3. If changing the cable does not help, the problem is in the working CLAB. Perform a
CLAB switchover and replace the CLAB.

DN05104459
Issue 2-2

Id:0900d8058066eb91

45

Problems with synchronisation

Handling Common Problem Situations in BSC

If alarm 2761 CLAB FAILURE is raised, the problem is inside the CLAB plug-in unit, the
CLAC cartridge, or cabling.
1. Check the cables distributing timing signals between the CLOC and CLAC cartridges.
2. Replace the working CLAB.
3. If the CLAB does not respond to the supervision messages sent to it by the control
computer, check the cabling between the CLAC and the Hardware Alarm Terminal
(HWAT), as well as the HWAT functions.
If alarm 1210 PHASE ADVANCE OF TIMING SIGNAL CHANGED is raised, it is
possible that the phase advance measurement is not working. For more detailed information on the conditions triggering the alarm, see 1210 PHASE ADVANCE OF TIMING
SIGNAL CHANGED in Disturbance Printouts (1000-1999).
1. Check the phase advance measurement cabling: the CEA cables between the
CLOC and CLAC cartridges, the CEA cable as a delay loop in the base cabinet, and
the CGB cables between the CLACs.
2. Check the timing bus termination connectors (TRMC3).
3. Check the measurement logic in the CLAB and the last CLAB of the row.
4. If the problem persists, perform a CLAB switchover and replace the CLAB.
Workarounds
Perform a CLAB switchover. If it does not help, also perform a CLS switchover. For
instructions, see Performing a switchover in Recovery and Unit Working State Administration.

46

Id:0900d8058066eb91

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with transmission

6 Problems with transmission


For an overview, see Overview of common problem situations in BSC.

6.1

Problems with PCM transmission


Problems with transmission may often require a site visit. At the site, you should refer to
the troubleshooting documentation of the BTS type in question to debug the problem.
Also note the troubleshooting manuals of the different transmission equipment, for
example, digital microwave radios (DMR).
At the BSC, the alarms related to transmission are a good source of information. Alarms
related to transmission are listed in Fault conditions in trunk circuits in Trunk Network
Maintenance (BSC ETs) and in TCSM Supervision, alarms, recovery, and statistics in
TCSM Support in BSC (TCSM ETs). Transmission equipment alarms (8000-8999), in
turn, serve to indicate fault conditions in the transmission equipment connected to the
BSC.
In addition to alarms, transmission measurements listed under the Reference category
can help to locate the cause of a transmission failure. 65 BSC ET Measurement is especially useful from the BSC point of view as it provides information on the ET interfaces
controlled by the BSC.
For information on transmission essentials in general, see Transmission Management
in BSS and BSS Transmission Configuration.

6.1.1

Transmission line between the BSC and a transmission node is


broken
Symptoms
When a transmission line between the BSC and a transmission node is broken, the
following alarms may be raised in the BSC:

2900 INCOMING SIGNAL MISSING (both ETSI and ANSI)


2902 PCM LINE REMOTE END ALARM (RDI in ETSI) or 2944 YELLOW ALARM
(RDI in ANSI)
2909 AIS RECEIVED (AIS in ETSI) or 2943 BLUE ALARM (AIS in ANSI)

Possible causes
Depending on the alarm(s) raised, different scenarios are possible. Figure Common
PCM transmission problem situations illustrates common scenarios.
RX

TX

BSC

Transmission
node 1

RX

1.
Figure 1

TX

3.

2.

Transmission
node 2 / BTS

4.

Common PCM transmission problem situations

Note that the exact functioning of the transmission equipment in each scenario may vary
depending on the settings used, and the following descriptions on the sequence of
events are meant as examples only.

DN05104459
Issue 2-2

Id:0900d8058066eb94

47

Problems with transmission

Handling Common Problem Situations in BSC

Scenario 1: The TX transmission line between the BSC and the transmission node
1 is broken. In this situation, node 1 sets a 2M/1.5M signal missing alarm in the BSC
direction interface and starts sending an alarm indication signal (AIS) towards node
2. When node 2 receives the AIS, it sends a remote defect indication (RDI) towards
node 1, which then forwards the RDI to the BSC. After receiving the RDI, the BSC
sets alarm 2902/2944.
Scenario 2: Both the TX and RX transmission lines between the BSC and the transmission node 1 are broken. In this situation, the 2M/1.5M signal is missing both in
the BSC and in the node 1 BSC direction interface. The BSC sets alarm 2900, and
node 1 starts sending an AIS towards node 2. When node 2 receives the AIS, it
sends an RDI towards node 1.
Scenario 3: The TX transmission line between the transmission node 1 and node 2
is broken. In this situation, node 1 sets a 2M/1.5M signal missing alarm in the node
2 direction interface and starts sending an AIS towards the BSC. After receiving the
AIS, the BSC sets alarm 2909/2943 and starts to send an RDI towards node 1,
which then forwards it to node 2.
Scenario 4: Both the TX and RX transmission lines between the transmission node
1 and node 2 are broken. In this situation, the 2M/1.5M signal is missing in both
nodes. Node 1 sends an AIS towards the BSC. After receiving the AIS, the BSC sets
alarm 2909/2943 and starts to send an RDI towards node 1.

Instructions
The following instructions help you in locating the faulty unit in the transmission network.
1. Verify which transmission line(s) is broken and in which direction (TX, RX).
Check the supplementary information field of the alarm (2900, 2902/2944, or
2909/2943) for the number of the faulty PCM.
2. Identify the transmission equipment located along the broken transmission line.
Note that the following commands provide information only on the equipment supervised by the BSC.
a) Output the transmission equipment connected to the BSC.
ZQWL;
b) Check which transmission equipment is connected to the faulty PCM.
ZQWI::ALL;
3. Check the alarms and measurements related to transmission.

Establish a remote connection to the transmission equipment and check that


AIS and RDI forwarding is set to on. This way you can ensure that alarms are
directed to the correct transmission lines.
You can establish the remote connection using Remote Node Manager or the
BSS Transmission Equipment Handling MML (QU command group).
a) Check which transmission equipment alarms (8000-8999) and/or BTS alarms
are currently active relating to the transmission equipment and line in question.
ZAHO;
ZEOL;
b) Monitor the transmission measurements (62-69) relating to the transmission
equipment and line in question. Unusually high counter values indicate probable
error sources.
4. Check the configuration settings of the presumably faulty transmission equipment
via a remote connection and restore the default settings, if needed. If a remote connection is not sufficient, visit the site concerned.

48

Id:0900d8058066eb94

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with transmission

5. Inform the site personnel concerned of the fault and find out if further corrective
actions are needed to restore the equipment to working order.
6. When the fault has been corrected, verify that the faulty transmission line is working
again.
a) Check that the transmission equipment is in the OK state and there are no active
alarms.
ZQWL;
b) Monitor the transmission measurements relating to the transmission equipment.

6.2

Problems with IP transport


When suspecting that there is a problem with IP transport, see BSC IP Site Connectivity
Guidelines for more information on the IP connectivity settings required for interfaces
using IP.

6.2.1

Signal in the IP network does not go through


Symptoms
A problem with IP transport may often manifest itself as an application-level transmission failure. BSC application alarms may be raised. The supervision recognises that
there is problem in IP transport when the periodically requested remote host (IP
address) becomes unreachable. When the response is missing, and the application fails
because of a link failure, there is reason to suspect a problem in IP transport.
Possible BSC application alarms are, for example, the following:

3159 SCTP ASSOCIATION LOST in a SIGTRAN interface (A/Lb/BBI)


3025 NETWORK SERVICE VIRTUAL CONNECTION TEST PROCEDURE
FAILED in the Gb interface.

Possible causes
There are several possible causes:

The IP backbone router and/or the remote host cannot be reached.


Multilayer site switches, switching unit(s), or the local host cannot be reached
because of problems in the Spanning Tree Protocol (STP) or Virtual Local Area
Network (VLAN) configurations.

Instructions
The first action for solving a problem with IP transport is to identify the computer unit
affected by the problem. Pinging is the easiest method to check whether the problem
is at the IP backbone/remote site or at the local site.
The following instructions on checking the configuration for IP transport help you to
determine whether the problem is in the local site configuration.
1. Check the host connectivity.
Check if the IP address of the host port is assigned (YES) and its administrative state
UP.
ZQRI;
Example:
QRI;

DN05104459
Issue 2-2

Id:0900d8058066eb94

49

Problems with transmission

BSC3i

Handling Common Problem Situations in BSC

BSC6

2007-08-09

13:17:47

INTERROGATING NETWORK INTERFACE DATA

UNIT
NAME
------------------ -------BCSU-0
EL0
EL1
-PCU2D- 3 IFETH0
-PCU2D- 3 IFETH1
-PCU2D- 4 IFETH0
-PCU2D- 4 IFETH1
-PCU2D- 5 IFETH0
-PCU2D- 5 IFETH1
-PCU2D- 6 IFETH0
-PCU2D- 6 IFETH1

IP ADDRESS
--------------10.16.138.84
10.16.138.100
10.16.138.132
10.16.138.132
10.16.138.133
10.16.138.133
10.16.138.134
10.16.138.134
10.16.138.135
10.16.138.135

ADDR
ADM
TYPE NML ASSIGNED STATE
---- --- -------- ----L
28 YES
UP
L
28 YES
UP
L
26 YES
UP
L
26 NO
UP
L
26 YES
UP
L
26 NO
UP
L
26 YES
UP
L
26 NO
UP
L
26 YES
UP
L
26 NO
UP

MTU

PRIORISED
----- ----1500 NO
1500 NO
1500 NO
1500 NO
1500 NO
1500 NO
1500 NO
1500 NO
1500 NO
1500 NO

COMMAND EXECUTED
2. Depending on the outcome, implement the following options:
If the administrative state is not UP, change the state of the network interface
with the following command:
ZQRN:unit,index::EL0/EL1:::UP::;
If the IP address of the host port is not assigned (NO), check if it complies with
the following terms:
If SIGTRAN/SCTP multihoming is used, both the EL0 and EL1 interfaces
should have an assigned IP address of their own. See BCSU EL0 and EL1
in the example of step 1.
If SIGTRAN/SCTP multihoming is not used, or the interface in question is
Gb, the same IP address is shared by the two Ethernet interfaces (EL0/EL1,
IFETH0/IFETH1). The IP address is assigned to the interface that is active.
See PCU2D 3 IFETH0 and IFETH1 in the example of step 1.
If necessary, configure the network interface with the following command:
ZQRN:<unit>,<index>::<interface>:<ip
address>:<subnet>:UP::;
3. Test the end-to-end connection.
Send a PING to the IP address of the remote host where you suspect the problem
to be located. For example, the IP address in the SGSN, the MSC, or another BSC.
ZQRX:<computer unit>,<index>::IP=<ip address of remote host>:;
If you receive a response, it means that IP transport is working end-to-end.
If you do not receive a response, proceed to step 4.
4. Test the connection to the IP gateway.
Send a PING to the IP address of the IP gateway (the IP address of the multilayer
site switch) from the computer unit where you suspect the problem to be located.
ZQRX:<computer unit>,<index>::IP=<ip address of gateway>;
If you receive a response, it means that IP transport is working between the host
and the multilayer site switch, and the problem is located in the IP backbone or
the remote host.
If you do not receive a response, proceed to step 5.

50

Id:0900d8058066eb94

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with transmission

5. Check the IP path from the host to the multilayer site switch.
Note that the following instructions are applicable to BSC3i only.
a) Make sure that the software version of the ESB is the same as the version mentioned in the software package. Follow the instructions in Updating the software
package of a LAN switch in Maintaining LANs.
b) Open a Telnet connection to the ESB. If LAN Device Integration is used in the
BSC, you can use the ZW6T command to open the connection. The ESB needed
is the one whose cable is connected to the assigned host port of the problematic
interface.
ZW6T:SWU,0:;
Example:
LOADING PROGRAM VERSION 3.6-0
Telnet connection successfully opened to SWU 0 (ESB20_A),
IP=10.16.137.2.
SWU-0>ENABLE
c) Check the ESB port states and duplex mode settings with the show
interface command.
The port status (Link) should be up for the interfaces that use IP transport.
For the OMU/MCMU/BCSU/uplink/redundant interfaces, the port duplex mode
(DuplSpeed) should be full:
Example:
SWU-0#show interface
=================================================================
|Port |Name
|Type
|State |Link|DuplSpeed|Flow
|Backpres|
+-----+--------+--------+-------+----+---------+-------+--------+
1/1/1
100TX
enable up
full-100 disable disable
1/1/2
100TX
enable down unknown
disable disable
1/1/3 swu0-sw~ 100TX
enable up
full-100 disable disable
1/1/4
100TX
enable down unknown
disable disable
1/1/5
100TX
enable down unknown
disable disable
1/1/6
100TX
enable down unknown
disable disable
1/1/7
100TX
enable down unknown
disable disable
1/1/8
100TX
enable down unknown
disable disable
1/1/9 lb-1
100TX
enable up
full-100 disable disable
1/1/10 lb-1
100TX
enable up
full-100 disable disable
1/1/11 o&m
100TX
enable up
full-100 disable disable
1/1/12 a/bbi-1 100TX
enable up
full-100 disable disable
1/1/13 a/bbi-1 100TX
enable up
full-100 disable disable
1/1/14 a/bbi-1 100TX
enable up
full-100 disable disable
1/1/15 a/bbi-1 100TX
enable up
full-100 disable disable
1/1/16 a/bbi-1 100TX
enable up
full-100 disable disable
1/1/17 a/bbi-1 100TX
enable up
full-100 disable disable
1/1/18 a/bbi-1 100TX
enable up
full-100 disable disable
1/1/19 swu0-sw~ 100TX
enable up
full-100 disable disable
1/1/20 swu0-sw~ 100TX
enable up
full-100 disable disable

For the PCU interfaces, the port duplex mode (DuplSpeed) should be half:
Example:
SWU-2#show interface
=================================================================

DN05104459
Issue 2-2

Id:0900d8058066eb94

51

Problems with transmission

Handling Common Problem Situations in BSC

|Port |Name
|Type
|State |Link|DuplSpeed|Flow
|Backpres|
+-----+--------+--------+-------+----+---------+-------+--------+
1/1/1
100TX
enable up
full-100 disable disable
1/1/2
100TX
enable down unknown
disable disable
1/1/3 swu0-sw~ 100TX
enable up
full-100 disable disable
1/1/4
100TX
enable down unknown
disable disable
1/1/5 gb
100TX
enable up
half-100 disable disable
1/1/6 gb
100TX
enable up
half-100 disable disable
d) Check that the port you are investigating belongs to the correct VLAN. Use the
show vlan command. Also, note down the VLAN id of the port (VTag), since
you will need it in the next step.
Example:
SWU-0#show vlan
====================================================================
Name
|VTag| Tagged ports
| Untagged ports
--------------------+----+---------------------+-------------------default
|1
|
|1/1/1-1/1/20
o&m
|10 |1/1/1,1/1/2,1/1/19, |1/1/11
|
|1/1/20
|
ldi
|11 |1/1/1,1/1/2
|1/1/3,1/1/9,1/1/10
lb-1
|20 |1/1/1,1/1/2,1/1/9,
|
|
|1/1/10,1/1/19,1/1/20 |
lb-2
|21 |1/1/1,1/1/2,1/1/19, |
|
|1/1/20
|
a/bbi-1
|30 |1/1/1,1/1/2,1/1/19, |1/1/12-1/1/18
|
|1/1/20
|
a/bbi-2
|31 |1/1/1,1/1/2,1/1/19, |
|
|1/1/20
|
gb
|100 |
|
e) Identify the instance used for the VLAN, and analyse the port roles in the
instance. Use the show mstp command.
Example:
SWU-0#show mstp
MST01
VLAN mapped
= 10,20,30
Priority
= 32768
Regional Root
= 24577.00:1A:E3:65:54:00
RemainingHopCount
= 4
TopChanges
= 3
=========================================================================
Port
|Pri|Port role |State|PCost
|DCost
|Designated bridge |DPrt
--------+---+----------+-----+---------+---------+------------------+---01/01/01 128 Root
frwrd
200000
200000 24576.001AE3655400 128.003
01/01/09 128 Designated frwrd
200000
200000 32768.00A0120B0C49 128.009
01/01/10 128 Designated frwrd
200000
200000 32768.00A0120B0C49 128.010
01/01/11 128 Designated frwrd
200000
200000 32768.00A0120B0C49 128.011
01/01/12 128 Designated frwrd
200000
200000 32768.00A0120B0C49 128.012
01/01/13 128 Designated frwrd
200000
200000 32768.00A0120B0C49 128.013
01/01/14 128 Designated frwrd
200000
200000 32768.00A0120B0C49 128.014

52

Id:0900d8058066eb94

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

AG03

128 Designated frwrd

Problems with transmission

100000

0 32768.00A0120B0C49 128.023

Example:
SWU-3#show mstp
MST02
VLAN mapped
= 21,31,100
Priority
= 32768
Regional Root
= 24578.00:1A:2F:8C:95:80
RemainingHopCount
= 2
TopChanges
= 3
============================================================================
Port
|Pri|Port role |State|PCost
|DCost
|Designated bridge |DPrt
--------+---+----------+-----+---------+---------+------------------+------01/01/01 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.001
01/01/05 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.005
01/01/06 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.006
01/01/07 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.007
01/01/08 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.008
01/01/09 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.009
01/01/10 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.010
01/01/11 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.011
01/01/12 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.012
01/01/13 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.013
01/01/14 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.014
01/01/15 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.015
01/01/16 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.016
01/01/17 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.017
01/01/18 128 Designated frwrd
200000
310000 32768.00A0120B1832 128.018
AG03
128 Root
frwrd
100000
0 32768.00A0120B1820 128.023

f)

DN05104459
Issue 2-2

The following port roles and states should be available.


The switch ports connected to the OMU/MCMU/BCSU/PCU host ports
(MSTP edge ports) should be Designated, frwrd.
The uplink or redundant port should be Root, frwrd. If the redundant port role
is Root, frwrd, the uplink port role in the redundant ESB unit should also be
Root, frwrd.
Depending on the outcome of step e), implement one of the following options:
If the port roles and states are correct, it means that the Multiple Spanning
Tree Protocol (MSTP ) is working. Proceed to step 5 g).
If the port roles and states are not correct, it means that there is a problem
with the MSTP configuration. Check the configuration as follows:
1. Give the show mstp configuration command.
Example:
SWU-0#show mstp configuration
Name
[BSC]
Revision 1
Instance Vlans mapped
--------- -------------------------0
1-9,11-19,22-29,32-4094
1
10,20,30

Id:0900d8058066eb94

53

Problems with transmission

Handling Common Problem Situations in BSC

2
21,31,100
-----------------------------------Ensure that the region name, region id, instances, and VLAN mapping
are configured identically in all the switches of the MSTP region.
2. Give the show mstp command.
Example:
SWU-0#show mstp
MST00
Priority
= 32768
MST01
Priority
= 32768
MST02
Priority
= 32768
Ensure that the instance priority is higher in the multilayer site switch
than in the ESB unit. The multilayer site switch should have a smaller
value.
g) Check that the MSTP edge ports of the switch are added to the correct VLANs
as untagged ports, and that the uplink and redundant ports are added to the
correct VLANs as tagged ports. Note that the switch port connected to the
MCMU host port (see the example below) may also be added to the Lb VLAN
as a tagged port if the Lb VLAN is created to the MCMU host ports with the QRA
command. Use the show vlan command.
Example:
SWU-0#show vlan
====================================================================
Name
|VTag| Tagged ports
| Untagged ports
--------------------+----+---------------------+-------------------default
|1
|
|1/1/1-1/1/20
o&m
|10 |1/1/1,1/1/2,1/1/19, |1/1/11
|
|1/1/20
|
ldi
|11 |1/1/1,1/1/2
|1/1/3,1/1/9,1/1/10
lb-1
|20 |1/1/1,1/1/2,1/1/9,
|
|
|1/1/10,1/1/19,1/1/20 |
lb-2
|21 |1/1/1,1/1/2,1/1/19, |
|
|1/1/20
|
a/bbi-1
|30 |1/1/1,1/1/2,1/1/19, |1/1/12-1/1/18
|
|1/1/20
|
a/bbi-2
|31 |1/1/1,1/1/2,1/1/19, |
|
|1/1/20
|
gb
|100 |
|
Example:
SWU-3#show vlan
====================================================================
Name
|VTag| Tagged ports
| Untagged ports
--------------------+----+---------------------+-------------------default
|1
|
|
o&m
|10 |
|
ldi
|11 |1/1/1,1/1/2
|1/1/3

54

Id:0900d8058066eb94

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

lb-1
lb-2
a/bbi-1
a/bbi-2
gb

|20
|21
|30
|31
|100
|

Problems with transmission

|
|
|
|
|1/1/1,1/1/2,1/1/19,
|1/1/20

|
|
|
|
|1/1/5-1/1/18
|

You can use the following commands for reconfiguring the port settings, if
needed:
Example:
SWU-0#configure terminal
SWU-0#vlan
SWU-0#config o&m
SWU-0#remove ports 1/1/1-1/1/20
SWU-0#add ports 1/1/1,1/1/2,1/1/19,1/1/20 tagged
SWU-0#add ports 1/1/11 untagged
h) Check that the MSTP edge ports of the switch have the correct default VLAN ids.
Note that if the Lb VLAN is created to the MCMU host ports with the QRA
command, the LDI VLAN id is used as the default VLAN id for the switch ports
connected to the MCMU. Use the show interface command.
Example:
SWU-3#show interface
==============================================================================
|Port |Name
|Type
|State |Link|DuplSpeed|Flow
|Backpres|Default Vlan
+-----+--------+--------+-------+----+---------+-------+--------+------------1/1/1
100TX
enable up
full-100 disable disable
0001
1/1/2
100TX
enable down unknown
disable disable
0001
1/1/3 swu1-sw~ 100TX
enable up
full-100 disable disable
0011
1/1/4
100TX
enable down unknown
disable disable
0001
1/1/5 gb
100TX
enable up
half-100 disable disable
0100
1/1/6 gb
100TX
enable up
half-100 disable disable
0100
1/1/7 gb
100TX
enable up
half-100 disable disable
0100
1/1/8 gb
100TX
enable up
half-100 disable disable
0100
1/1/9 gb
100TX
enable up
half-100 disable disable
0100
1/1/10 gb
100TX
enable up
half-100 disable disable
0100
1/1/11 gb
100TX
enable up
half-100 disable disable
0100
1/1/12 gb
100TX
enable up
half-100 disable disable
0100
1/1/13 gb
100TX
enable up
half-100 disable disable
0100
1/1/14 gb
100TX
enable up
half-100 disable disable
0100
1/1/15 gb
100TX
enable up
half-100 disable disable
0100
1/1/16 gb
100TX
enable up
half-100 disable disable
0100
1/1/17 gb
100TX
enable up
half-100 disable disable
0100
1/1/18 gb
100TX
enable up
half-100 disable disable
0100
1/1/19 swu2-sw~ 100TX
enable up
full-100 disable disable
0001
1/1/20 swu2-sw~ 100TX
enable up
full-100 disable disable
0001
You can use the following commands for reconfiguring the VLAN id, if needed:
Example:
SWU-0#configure terminal
SWU-0#interface 1/1/11

DN05104459
Issue 2-2

Id:0900d8058066eb94

55

Problems with transmission

Handling Common Problem Situations in BSC

SWU-0#default vlan 10
You have now finished checking the configuration for IP transport. The IP transportrelated alarms should be cancelled.
6. If the problem still persists, collect all the information needed for a Problem Report
and contact Nokia Siemens Networks for further investigations. For instructions, see
Reporting problems with IP transport in BSC Problem Reporting.

56

Id:0900d8058066eb94

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with operation and maintenance

7 Problems with operation and maintenance


For an overview, see Overview of common problem situations in BSC.

7.1
7.1.1

Problems with Q3 connections


BSC alarms are missing from Nokia NetAct
Symptoms
Alarms can be seen in the BSC with MML commands (ZAHO, ZAHP), but not in Nokia
NetAct.
Possible causes
It may be that radio network objects are in maintenance mode in Nokia NetAct, during
which alarm handling is limited.
Instructions
1. Check the object status from the Radio Network Manager application in Nokia
NetAct.
If the objects are not in maintenance mode, alarm sending to the Q3 interface may
be blocked.
2. Check that alarm sending to the Q3 interface is not blocked.
BSC alarms: ZATL
BTS alarms: ZEOO
BCF alarms: ZEMO
3. If the alarm sending is not blocked, but the problem still persists, check that the other
O&M connections are up and running. For example, measurements and configuration events are transferred to Nokia NetAct correctly. For instructions, see All connections from the BSC to Nokia NetAct are lost.
4. If the problem still persists, restart the Operation and Maintenance Unit (OMU).
5. If the problem persists despite the OMU restart, collect all the information needed
for a Problem Report and contact Nokia Siemens Networks for further investigations. For instructions, see Reporting problems with alarms in BSC Problem Reporting.
Workarounds
Restart the Operation and Maintenance Unit (OMU).
For instructions, see Restarting a functional unit in Recovery and Unit Working State
Administration.

7.1.2

BSC measurement result files are missing from Nokia NetAct


Symptoms
BSC measurements have stopped updating to Nokia NetAct. They cannot be seen at all
or for a certain period of time, for example, in NetAct Reporting Suite.

DN05104459
Issue 2-2

Id:0900d8058066eb9a

57

Problems with operation and maintenance

Handling Common Problem Situations in BSC

Possible causes
Measurement transfer from the BSC to Nokia NetAct is not working normally. There is
possibly a lack of FTAM user rights that prevents the transfer.
Instructions
1. To verify the possible cause, check in which state the measurement result files are
on the Winchester disk (WDU) of the BSC.
ZIFO:OMU,MEASUR;
If the measurement result files have been correctly transferred, they are in TRANSFERRED state. If they are not in TRANSFERRED state, proceed to step 2.
2. Make sure that the secured FTAM settings are correctly set.
a) Check which profiles and users currently exist.
ZIAI:PROFILE=ALL;
b) If not all TRAFAD, SYSOP1, and NUPADM profiles are created, create the
missing profiles.
ZIAA:<profile>::VTIME=FOREVER;
c) Create FTAM user IDs for the new profiles.
ZIAH:<user id>:<profile>;
d) Add the new user profiles with the FS-X application.
ZIOA:TRAFAD:APPL=FS-X;
e) Check the network user authority for all existing users.
IOI:ALL;
Example:
USER ID
APPLICATION FIELD AND PERMISSION
SYSOP1

CM-X
PM-X
FM-X
FS-X

CONFIGURATION MANAGEMENT
PERFORMANCE MANAGEMENT
FAULT MANAGEMENT
SECURED FTAM

EXECUTE
EXECUTE
EXECUTE
EXECUTE

COMMAND EXECUTED
f)

If all existing users do not have FS-X user access rights, add the access rights.
ZIOM:SYSOP1:APPL=FS-X;
3. If the user rights are configured as described above, but the problem persists, check
that the other O&M connections are up and running. For example, alarms and configuration events are transferred to Nokia NetAct correctly. For instructions, see All
connections from the BSC to Nokia NetAct are lost.
4. If the problem still persists, restart the Operation and Maintenance Unit (OMU).
5. If the problem persists despite the OMU restart, collect all the information needed
for a Problem Report and contact Nokia Siemens Networks for further investigations. For instructions, see Reporting problems in storing and transferring statistical
data in BSC Problem Reporting.
Workarounds
Restart the Operation and Maintenance Unit (OMU).
For instructions, see Restarting a functional unit in Recovery and Unit Working State
Administration.

58

Id:0900d8058066eb9a

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with operation and maintenance

For more information on secured FTAM settings, see Technical Note No. 823 (Secured
FTAM Settings after S11.5 upgrade).

7.1.3

Creating, modifying, or uploading RNW objects with Nokia NetAct


applications fails
Symptoms
The BSS Radio Network Configuration Database (BSDATA) and Nokia NetAct databases are not updated with identical values.
Possible causes
This situation is usually caused by problems in message transferring or parameter value
ranges in the BSC and/or Nokia NetAct.
The BSC has to work with several Nokia NetAct (OSS) releases. Therefore, compatibility handling is needed. It is implemented by the Q3 interface object class handlers. Most
often this problem situation arises because the BSC is connected to a Nokia NetAct
release not defined as compatible in the settings of the Q3PreferredConfiguration
parameter.
Instructions
1. Check the value of the Q3PreferredConfiguration parameter in the BSC and
modify it, if needed.
For instructions, see Technical Note No. 737 (BSC Q3 interface compatibility with
different OSS SW releases).
2. If the parameter value is adequate, but the problem persists, check that the other
O&M connections are up and running. For example, alarms and configuration
events are transferred to Nokia NetAct correctly. For instructions, see All connections from the BSC to Nokia NetAct are lost.
3. If the problem still persists, restart the Operation and Maintenance Unit (OMU).
4. If the problem persists despite the OMU restart, collect all the information needed
for a Problem Report and contact Nokia Siemens Networks for further investigations. For instructions, see Reporting problems with Q3 interface in BSC Problem
Reporting.

7.1.4

All connections from the BSC to Nokia NetAct are lost


Symptoms
The O&M connection fails: there is no MML connection available, alarms and measurements are not transferred to Nokia NetAct, and the BSDATA and Nokia NetAct databases are not updated with identical values.
Possible causes
If the problem appears after maintenance work has been carried out, it is likely that
something has gone wrong when making the configuration changes.
Instructions
1. Check that the that physical interfaces are correctly connected and that the configuration changes were done according to instructions.

DN05104459
Issue 2-2

Id:0900d8058066eb9a

59

Problems with operation and maintenance

Handling Common Problem Situations in BSC

2. If the configuration is in order, carry out the basic troubleshooting steps of OSI troubleshooting in OSI Guide.
3. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Reporting problems with OSI in BSC Problem Reporting.
For more information on a related problem situation, see Problems with X.25 interface
in OSI guide.

7.2
7.2.1

Problems with software package handling


Change delivery installation fails
Symptoms
When a new change delivery is installed with the WNA command, the installation fails,
and the error code 13305 ERROR IN READING HIFILE is received.
Possible causes
The Software Package Updates History File (HIFILE) located in the Application Specific
Workfile Directory (ASWDIR) of the default software package is corrupted.
Instructions
1. Delete the HIFILE file from the ASWDIR of the default software package.
ZIWD:,OMU:WSB:ASWDIR:HIFILEGX,HST;
The previous change delivery history will be lost.
2. Add the change delivery again.
ZWNA:NAME=<destination package name>:<change deliver index>;
3. Continue the change delivery installation as instructed in the installation instructions
of the change delivery.
When a new change delivery package is created, a new HIFILE is created automatically.

7.2.2

Multiple change delivery installation fails


Symptoms
Installing several change deliveries at the same time fails.
Possible causes
The change deliveries were installed in an incorrect order.
Instructions
1. Delete the HIFILE and all the CFL files from both disks that can be found in the
ASWDIR of the default software package.
ZIWD:,OMU:WSB:ASWDIR:HIFILEGX,HST;
ZIWD:,OMU:WSB:ASWDIR:<change delivery name>,CFL;
The previous change delivery history will be lost.
2. Add all the change deliveries in correct order again.
ZWNA:NAME=<destination package name>:<change delivery
index>&<change delivery index>...;

60

Id:0900d8058066eb9a

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with operation and maintenance

3. Continue the change delivery installation as instructed in the installation instructions


of the change delivery.
When a new change delivery package is created, a new HIFILE is created automatically.

7.3

Problems with licence handling


When handling licences with BSC MML, ensure that you always enter correct parameter
values. Incorrect values may often result in a problem situation.
The ZW7L command installs all valid licence files that are in the correct location. Note
that if any of the licence files to be installed are invalid, the installation is interrupted, and
only those files that preceded the invalid licence file will be correctly installed.
To ensure that also the rest of the licence files are correctly installed, move the invalid
licence file away from the LICENCE directory under the Winchester disk root directory,
and re-enter the ZW7L command. Do not destroy the invalid licence file. It may be
needed in troubleshooting later on.
If a problem with licence handling persists despite corrective actions, fill in a Problem
Report with all relevant information attached and contact Nokia Siemens Networks for
further investigations. For instructions on collecting the information, see Reporting
problems with licensing in BSC Problem Reporting.
For information on other licensing-related problems and licensing in general, see
Licensing in BSC.

7.3.1

Licence installation fails, licence file not found


Symptoms
When a licence is being installed, a DX error message indicating that the licence file
cannot be found appears.
Example:
*** DX ERROR: 56 ***/
/*** NO SUCH FILE ***/
Possible causes
The licence file is missing or in an incorrect location, or the file name has been written
incorrectly.
Instructions
1. Check that the licence file(s) are copied to the LICENCE directory under the root
directories on the BSC's both Winchester disks.
2. If licence file name(s) were used in the installation command, check that correct file
name(s) were used, and that the file name(s) meet the DX200 file system requirements.
Note that the licence name is optional in the installation command (ZW7L). If no
parameter values are given, the command installs all valid licence files that are in
the correct location.

DN05104459
Issue 2-2

Id:0900d8058066eb9a

61

Problems with operation and maintenance

7.3.2

Handling Common Problem Situations in BSC

Licence installation fails, licence file already found


Symptoms
When a licence file is being installed, DX error message 16499 LICENCE FILE FOUND
IN DESTINATION DIRECTORY appears.
Possible causes
Either the licence you are trying to install has already been installed, or, for some
reason, another licence file with the same name already exists in the LICENCE directory
of the active software package.
Instructions
1. Check if the licence you are trying to install has already been installed.
ZW7I:LIC,LIM;
If yes, no further actions are needed.
If not, proceed to step 2.
2. Modify the name of the licence file you are trying to install.
3. Try to install the licence again.
ZW7L:<licence file name(s)>:<initial state>;

7.3.3

Licence installation fails, licence is not valid


Symptoms
When a licence file is being installed, DX error message 16527 LICENCE IS NOT VALID
appears.
Possible causes
There are incorrect values in the licence file, the licence file is corrupted, or the certificate of the licence file has expired.
Instructions
1. Check if the certificate of the licence file has expired. For instructions, see Technical
Note No. 848 (Signing certificate of the licence key has expired).
If the problem persists, proceed to step 2.
2. To ensure that the invalid licence file no longer prevents the licence installation,
move it away from the LICENCE directory under the Winchester disk root directory.
3. Examine the invalid licence file and implement one of the following options:
If the content of the target id field in the licence file (.XML) and the BSC target id
differ, order a new licence.
To output the BSC target id, use the W7N command.
If the licence file is corrupted, try the installation again with the file in the original
e-mail received from the Nokia Licence Generator (LG). If that licence file is also
corrupted, order a new licence.
4. Continue the installation with the new licence.

62

Id:0900d8058066eb9a

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

7.3.4

Problems with operation and maintenance

Licence installation succeeds, but copying or deleting the licence


file fails
Symptoms
After a successful licence installation, DX error message 16501 DELETING LICENCE
FILE FAILED or 16502 COPYING LICENCE FILE FAILED appears.
Possible causes
When the licence installation is ready, the system copies the licence file(s) from the
LICENCE directory under the Winchester disk root directory to the LICENCE directory
of the active software package, and then deletes the original file(s) from the LICENCE
directory under the Winchester disk root directory. This automatic copying or deleting
the licence file has failed.
Instructions
1. Copy the licence file manually from the LICENCE directory under the Winchester
disk root directory to the LICENCE directory of the active software package.
2. Delete the licence file manually from the LICENCE directory of the Winchester disk
root directory.

7.3.5

Interrogating installed licences or features fails


Symptoms
When interrogating installed licences or features, DX error message NO SUCH
LICENCE FILE or 16562 FEATURE RECORD NOT FOUND IN MEMORY FILE
appears.
Possible causes
You may be using incorrect search criteria. It may also be that the licence you are
searching for has not been installed yet.
Instructions
1. Check that you have the correct search criteria: status, file name.
2. If interrogation with the correct search criteria does not succeed, check if the licence
has been installed.
ZW7I:LIC,FULL;
ZW7I:FEA,FULL:FSTATE=<state:ON,CONF,OFF>;
3. If needed, install the licence.
For more detailed instructions, see Installing licences in the network element in
Licensing in BSC.

7.3.6

Licence database is corrupted


Symptoms
When a licence is being installed or a feature state modified, DX error message 16566
CORRUPTED LICENCE RECORD FOUND IN MEMORY FILE or 16567 CORRUPTED
FEATURE RECORD FOUND IN MEMORY FILE appears.

DN05104459
Issue 2-2

Id:0900d8058066eb9a

63

Problems with operation and maintenance

Handling Common Problem Situations in BSC

Possible causes
The problem may be permanent. The licence database may be corrupted because of a
disk problem. Licence handling is not possible until the licence database has been
restored.
Instructions
1. Wait for a while and continue licence handling.
If the problem persists, proceed to step 2 for recovery actions.
2. Collect the information needed for a Problem Report. For instructions, see Reporting
problems with licensing in BSC Problem Reporting.
3. Try to remove and reinstall the corrupted licence.
Removing the licence may clear the corruption in the licence database.
For instructions, see Removing licences from the network element and Installing
licences in the network element in Licensing in BSC.
4. If removing and reinstalling the corrupted licence fails, fill in a Problem Report and
contact Nokia Siemens Networks for further investigations. Complete initialisation of
the licence system may be needed.

7.3.7

Licence file handling with Nokia NetAct Licence Manager fails


Symptoms
Licence file cannot be handled by Nokia NetAct Licence Manager.
Possible causes
The content of the licence is probably incorrect: the customerId and customerName
fields in the licence file (.XML) are not exactly as defined in Nokia NetAct. If they differ,
Nokia NetAct Licence Manager is not able to handle the licence file.
Instructions
1. Check that the customerId and customerName fields in the licence file are correctly
defined.
2. If they are not, order a new licence with correct contents.
For more information on managing licences with Nokia NetAct, see Network Licence
Management in NetAct in Nokia NetAct documentation.

64

Id:0900d8058066eb9a

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with location-based services

8 Problems with location-based services


Most problems with location-based services are related to the configuration of the
internal Serving Mobile Location Centre (SMLC) or the Lb interface.
For an overview, see Overview of common problem situations in BSC.

8.1
8.1.1

Problems with the internal SMLC


BSC gives inaccurate location estimates or returns the location
response with an error cause
Symptoms
The BSC gives inaccurate location estimates or returns the location response with an
error cause.
Possible causes
The data used in location estimate calculation is not valid, or there is not enough information to provide as accurate a location estimate as expected.
Instructions
1. Make sure that the LCS element parameters antenna coordinates and antenna
bearing are optimal for each cell.
ZEXO;
2. Check that the licence covering MS Location Services has been activated.
For instructions, see Activating and Testing BSS10012: MS Location Services.
3. If the problem persists, collect all the information needed for a Problem Report and
contact Nokia Siemens Networks for further investigations. For instructions, see
Reporting problems with location-based services in BSC Problem Reporting.
Workarounds
Set the PBS_USAGE parameter to OFF. Wait for one minute and set the parameter to
ON again.
ZWOA:2,654,D;
ZWOA:2,654,A;

8.2

Problems with the Lb interface


When suspecting that there is a problem with the Lb interface, see Signalling Transport
over IP (M3UA and IUA), and BSC IP Site Connectivity Guidelines for information on the
IP transport essentials required for the Lb interface.

8.2.1

Lb interface is down (UA-INS)


Symptoms
The BSC is not able to provide SMLC services in the Lb interface; for example, E911
positioning fails. The BSC does not forward the PERFORM LOCATION REQUEST to
the stand-alone SMLC, but sends the PERFORM LOCATION RESPONSE to the MSC
with congestion.

DN05104459
Issue 2-2

Id:0900d8058066eba0

65

Problems with location-based services

Handling Common Problem Situations in BSC

The result is full outage, that is, no MSS under the BSC can be located until the problem
is corrected.
Possible causes
The Lb interface may be down because IP transport is not working.
Instructions
1. Check the status of the Lb interface.
a) Interrogate the signalling connection control part (SCCP) subsystem states. The
Lb interface uses the BSSAP-LE subsystem.
ZNHI;
b) Interrogate the Lb interface signalling point state.
ZNRI:<national network number>:<signalling point code>;
c) Interrogate the signalling route state.
ZNVI:<national network number>;
d) Interrogate the signalling link state.
ZNLI;
If all states related to it are AV-EX, the Lb interface is working normally.
If the states are UA-INS, the Lb interface is down, and the following alarms referring
to the signalling point code in question are also active. In the example below, the
signalling point code is 202. You can check the alarms with the following command:
ZAHO:MCMU;
Example:
ZAHO:MCMU;
2064 ROUTE SET UNAVAILABLE
00000202 08 04
2070 LINK SET UNAVAILABLE
0010 01 00000202 08
2241 SCCP SUBSYSTEM PROHOBITED
01 08 00000202 01
2. Check the association set id of the Lb interface. You will need it in the next step.
ZNSI:NA0;
Example:
NSI:NA0,;
BSC3i

BSC1

2007-08-29

16:02:55

INTERROGATING SIGNALLING LINK SET DATA


NET
--NA0

SP CODE H/D
-----------------0007/00007

LINK SET
---------17 SMLC

ASSOCIATION SET
LS STATE
--------------------- -------1 SMLC
UA
LINK TEST NOT ALLOWED

IP LINK
------2

COMMAND EXECUTED
3. Investigate if the cause of the problem is in IP transport.
a) Check the association states in the association set.
ZOYI:NBR=<association set id>:A;

66

Id:0900d8058066eba0

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with location-based services

Example:
OYI:NBR=1:A:;

BSC3i

BSC1

2007-08-29

15:58:54

INTERROGATING ASSOCIATION SET DATA


ASSOCIATION SET NAME
-------------------SMLC

ASSOC SET ID
-----------1

ASSOC.
ASSOC ID
IND
UNIT
IN UNIT
--------- --------0
MCMU-0
---

.
.
.
.
.
.
.
.
.

:
:
:
:
:
:
:
:
:

ROLE
-------CLIENT

PARAMETER SET
NAME
STATE
---------------- -------------------SS7
UP-PROCEEDING

SOURCE ADDRESS 1 . . . .
SOURCE ADDRESS 2 . . . .
SOURCE PORT . . . . . .
PRIMARY DEST. ADDRESS .
SECONDARY DEST. ADDRESS
DESTINATION PORT . . . .
DATA STREAM COUNT . . .
SPECIFICATION VERSION .
TRAFFIC MODE . . . . . .
ASP MESSAGES . . . . . .
REGISTRATION REQUEST . .
SSNM MESSAGES BROADCAST
NETWORK APPEARANCE . . .
ASP MESSAGES IN IPSP . .
ROUTING CONTEXT . . . .
FIRST DATA STREAM NUMBER

SCTP USER
--------M3UA

.
.
.
.
.
.
.

:
:
:
:
:
:
:

10.16.153.52
EPHEMERAL
10.16.152.63/30
2905
16

1.0 (RFC)
LOAD-SHARE
YES
YES
NO
0
NO
--1

COMMAND EXECUTED
Association states other than ASP-ACTIVE (for example, UP-PROCEEDING)
indicate defective IP addresses. Note down the addresses. If the cause of the
problem turns out to be in IP transport, you will need them in troubleshooting
later on.
b) Check active alarms.
ZAHO:MCMU;
Example:
ZAHO:MCMU,;
3159 SCTP ASSOCIATION LOST
03 0001 0000 0004 0001
If there is at least one association in the ASP-ACTIVE state, IP transport is working.
If none of the associations are in the ASP-ACTIVE state, and the alarm 3159 refer-

DN05104459
Issue 2-2

Id:0900d8058066eba0

67

Problems with location-based services

Handling Common Problem Situations in BSC

ring to the association set in question is also active, the cause of the problem is in
IP transport. In the example above, the association set id is 0.
4. For corrective actions, see Problems with IP transport.
When the problem is corrected, the alarms are cancelled automatically, and the Lb
interface returns to the AV-EX state.
5. If the problem still persists, the cause may be elsewhere than in IP transport. Try out
the following:
a) Deactivate and activate the Lb interface signalling link states.
ZNLC:<signalling link number>:,INA;
ZNLC:<signalling link number>:,ACT;
b) Deactivate and activate the Lb interface.
For instructions, see Activating and testing BSS11114: Lb interface to BSC.
6. If the problem persists despite these corrective actions, collect all the information
needed for a Problem Report and contact Nokia Siemens Networks for further investigations. For instructions, see Reporting problems with location-based services in
BSC Problem Reporting.
Workarounds
Set the LB_USAGE parameter to OFF. Wait for 30 seconds and set the parameter to
ON again.
ZWOA:2,749,D;
ZWOA:2,749,A;

68

Id:0900d8058066eba0

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with LAN Device Integration

9 Problems with LAN Device Integration


When suspecting that there is a problem with LAN Device Integration, see Integrated
LAN Administration and BSC IP Connectivity Guidelines for more information on the
essentials required for successful implementation of LAN Device Integration.
For an overview, see Overview of common problem situations in BSC.

9.1
9.1.1

Problems with Telnet


Accessing the ESB switch fails
Symptoms
The BSC is not able to provide a telnet connection from the Marker and Cellular Management Unit (MCMU) to an ESB switch. Executing the ZW6T command fails.
Example:
ZW6T:SWU,<index>;
/*** DX ERROR: 16492 ***/
/*** COULD NOT CONNECT TO TELNET SERVER ***/
Alarm 3252 LAN DEVICE SUPERVISION FAILURE is also raised.
Possible causes
There are several possible causes:

The ESB(s) may be isolated from the local network because of a Multiple Spanning
Tree Protocol (MSTP) configuration failure. The MSTP instances and the Virtual
Local Area Network (VLAN) mapped to the instances are not identically configured
in the ESB(s) and the multilayer site switches.
The IP path between the MCMU and the ESB may not be open for LAN Device Integration because of a VLAN configuration failure.
The IP address allocation may be negotiated with a wrong DHCP server at another
BSC site. For troubleshooting instructions, see Problems with DHCP.

Instructions
The following instructions on the checking the internal LAN configuration help you to
determine and eliminate the problem cause.
1. Identify the ESB(s) affected by the problem.
a) Print out LAN HW supervision file data.
ZYFF;
The supervision status of the affected ESB(s) is UNREACHABLE.
b) Print out the current alarms.
ZAHO;
The affected ESB(s) has an active alarm 3252 LAN DEVICE SUPERVISION
FAILURE. The alarm(s) is automatically cancelled when the problem is solved.
2. Check that IP addresses have been allocated to the MCMU (EL0 and EL1) and all
the ESBs.
ZWYI;

DN05104459
Issue 2-2

Id:0900d805807a9858

69

Problems with LAN Device Integration

Handling Common Problem Situations in BSC

Example:
ZWYI;
READING DATA FROM FILE ...
ID

UNIT

IF
NAME
------ ---------------- -----1
MCMU-0
EL0
EL1
2
SWU-2
2
SWU-0
3
SWU-3
3
SWU-1
TOTAL OF

5 UNITS IN

IP ADDRESS

HOST OR SUPERV
HW ID CODE
UNIT
IN HEX
--------------- ---------------- ---------10.1.6.1
10.16.138.1
10.16.138.17
10.16.138.3
MCMU-0
1A10
10.16.138.2
MCMU-0
1210
10.16.138.19
MCMU-0
1A11
10.16.138.18
MCMU-0
1211

3 LANS OR IP SUBNETS

COMMAND EXECUTED
The following IP addresses should be allocated:
an IP address to the MCMU
IP addresses to MCMU EL0 and ESB-0/-2/-4/-8, which should belong to the IP
subnet of CNW-0
IP addresses to MCMU EL1 and ESB-1/-3/-5/-9, which should belong to the IP
subnet of CNW-1.
To check the IP subnets, use the following command:
ZWYI:L::;
Example:
ZWYI:L::;
EXECUTION STARTED
READING DATA FROM FILE ...
IP ADDRESS RANGE:
START
END
DESTINATION
GATEWAY
-----------------------------------------------------------------------IP SUBNET ID: 1
10.1.6.1/29

INFO: MCMU_SN
10.1.6.6/29

LAN ID: 2
LAN UNIT TYPE AND INDEX: CNW-0
10.16.138.1/28
10.16.138.14/28

INFO: CNW-0

LAN ID: 3
LAN UNIT TYPE AND INDEX: CNW-1
10.16.138.17/28
10.16.138.30/28

INFO: CNW-1

TOTAL OF

70

3 LANS OR IP SUBNETS

Id:0900d805807a9858

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with LAN Device Integration

COMMAND EXECUTED
If the IP subnets need to be reconfigured, follow the instructions in Creating LANs in
a new network element in Integrated LAN Administration.
3. Ensure that the software version of the ESB is the same as the version mentioned
in the software package.
a) Output the version of the software package.
ZWQO:RUN;
b) Output the ESB versions available for the software package. For ESB20-A, the
file name is ESB20AGX.BIN; for ESB24-D, the file name is ESB24DGX.BIN and
for ESB26, it is ESB260GX.BIN.
ZWQL:STAT=<status>:FNAM=<file name>;
c) Open a serial cable connection from the PC to the affected ESB(s) and output
the software version of the ESB(s) with the show version command.
Example:
SWU-0#enable
SWU-0#show version
N O K I A
Switch model : NOKIA ESB20-A
SW version : 3.14.7 created Apr 20 2006 - 09:07:31
Java version : Java image not loaded
Loader version : 2.4 created Jan 30 2003 - 09:51:45
Up time : 81 days, 2 hours, 46 min, 45 sec.
d) If the software version on the ESB(s) is not correct, update the software package
to the ESB(s). Follow the instructions in Updating the software package of a LAN
switch in Integrated LAN Administration.
4. Check the ESB port states and duplex mode settings with the show interface
command.
Example:
SWU-0#show interface
==============================================================================
|Port |Name
|Type
|State |Link|DuplSpeed|Flow
|Backpres|Default Vlan
+-----+--------+--------+-------+----+---------+-------+--------+------------1/1/1
100TX
enable up
full-100 disable disable
0001
1/1/2
100TX
enable down unknown
disable disable
0001
1/1/3 swu0-sw~ 100TX
enable up
full-100 disable disable
0011
1/1/9 ldi
100TX
enable up
full-100 disable disable
0011
1/1/10 ldi
100TX
enable up
full-100 disable disable
0011
The port status (Link) should be up and the port duplex mode (DuplSpeed) full for
the MSTP edge ports of the MCMU interfaces, the management link, and the
uplink(s) that use LAN Device Integration.
5. Check that the port you are investigating belongs to the LDI VLAN. Use the show
vlan command. Also, note down the VLAN id of the port (VTag), since you will need
it in the next step.
Example:
SWU-0#show vlan
====================================================================

DN05104459
Issue 2-2

Id:0900d805807a9858

71

Problems with LAN Device Integration

Handling Common Problem Situations in BSC

Name |VTag| Tagged ports | Untagged ports


--------------------+----+---------------------+-------------------ldi |11 |1/1/1,1/1/2 |1/1/3,1/1/9,1/1/10
6. Identify the instance used for the LDI VLAN, and analyse the port roles in the
instance. Use the show mstp command. In the example below, the LDI VLAN 11
is in instance-0 (MSTP00).
Example:
SWU-0#show mstp
MST00
VLAN mapped
= 1,11
Priority
= 32768
Regional Root
= 24576.00:1A:2F:70:15:80
RemainingHopCount
= 3
TopChanges
= 6
============================================================================
Port
|Pri|Port role |State|PCost
|DCost
|Designated bridge |DPrt
--------+---+----------+-----+---------+---------+------------------+------01/01/01 128 Root
frwrd
200000
0 28672.001A2F8C9580 128.003
01/01/03 128 Designated frwrd
200000
0 32768.00A0120B0D7C 128.003
01/01/09 128 Designated frwrd
200000
0 32768.00A0120B0D7C 128.009
01/01/10 128 Designated frwrd
200000
0 32768.00A0120B0D7C 128.010
The following port roles and states should be available:
The switch ports connected to the MCMU host ports (MSTP edge ports) should
be Designated, frwrd.
The uplink port should be Root, frwrd.
The management link should be Designated, frwrd , or Alternate, block.
7. Depending on the outcome of step 6, implement one of the following options:
If the port roles and states are correct, it means that the MSTP is working.
Proceed to step 8.
If the port roles and states are not correct, it means that there is a problem with
the MSTP configuration. Check the MSTP configuration as follows:
a) Give the show mstp configuration command.
Example:
SWU-0#show mstp configuration
Name
[BSC]
Revision 1
Instance Vlans mapped
--------- -------------------------0
1-9,11-19,22-29,32-4094
1
10,20,30
2
21,31,100
-----------------------------------Ensure that the region name, region id, instances, and VLAN mapping are
configured identically in all the switches of the MSTP region.
b) Give the show mstp command.

72

Id:0900d805807a9858

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with LAN Device Integration

Example:
SWU-0#show mstp
MST00
Priority
MST01
Priority
MST02
Priority

= 32768
= 32768
= 32768

Ensure that the instance priority is higher in the multilayer site switch than in
the ESB unit. The multilayer site switch should have a smaller value.
8. Check that the MSTP edge ports of the switch (MCMU) are added to the LDI VLANs
as untagged ports, and that the uplink and redundant ports are added to the correct
VLANs as tagged ports. Use the show vlan command.
Example:
SWU-0#show vlan
==================================================
Name |VTag| Tagged ports | Untagged ports
--------------------+----+---------------------+-ldi |11 |1/1/1,1/1/2 |1/1/3,1/1/9,1/1/10
You can use the following commands for reconfiguring the port settings, if needed:
Example:
SWU-0#configure terminal
SWU-0#vlan
SWU-0#config ldi
SWU-0#remove ports 1/1/1-1/1/20
SWU-0#add ports 1/1/1,1/1/2 tagged
SWU-0#add ports 1/1/3,1/1/9-1/1/10 untagged
9. Check that the MSTP edge ports of the switch have the LDI VLAN ids as a default.
Use the show interface command.
Example:
SWU-0#show interface
==============================================================================
|Port |Name
|Type
|State |Link|DuplSpeed|Flow
|Backpres|Default Vlan
+-----+--------+--------+-------+----+---------+-------+--------+------------1/1/1
100TX
enable up
full-100 disable disable
0001
1/1/2
100TX
enable down unknown
disable disable
0001
1/1/3 swu0-sw~ 100TX
enable up
full-100 disable disable
0011
1/1/9 ldi
100TX
enable up
full-100 disable disable
0011
1/1/10 ldi
100TX
enable up
full-100 disable disable
0011
You can use the following commands for reconfiguring the VLAN id, if needed:
Example:
SWU-0#configure terminal
SWU-0#interface 1/1/9
SWU-0#default vlan 11

DN05104459
Issue 2-2

Id:0900d805807a9858

73

Problems with LAN Device Integration

Handling Common Problem Situations in BSC

10. Check the status of the IP address allocated by the DHCP in the ESB. Use the show
ip command.
Example:
SWU-0#show ip
IP-ADDR : 10.16.138.2 NET-MASK : 255.255.255.240
IP address determined by DHCP
If the IP address allocation has failed, the vendor's default IP address 192.168.0.5
is shown. Proceed to step 11.
11. Request IP address reallocation. Use the following commands:
Example:
SWU-0#clear last-saved position
SWU-0#ip address dhcp renew
SWU-0#show ip
When the IP address has been reallocated, the telnet connection should again be
ready for accessing the ESB. If the problem still persists, it may be that the IP
address has been allocated by a wrong DHCP server at another BSC site. For troubleshooting instructions, see Problems with DHCP.

9.2
9.2.1

Problems with DHCP


Negotiating an IP address fails
Symptoms
LAN Device Integration is not working because the IP address allocation may be negotiated with a wrong DHCP server at another BSC site.
Also, in this case, alarm 3252 LAN DEVICE SUPERVISION FAILURE is raised
because LAN Device Integration does not have a supervision access to the ESB switch.
This alarm is common to all ESB access problems.
Possible causes
The DHCP server is located in the BSC3i MCMU. The IP address allocation by the
DHCP should always be negotiated with the local BSC site's DHCP server. Broadcasting to other BSC sites is eliminated by a dedicated LDI VLAN id configuration at each
BSC3i site.
Several reasons may together cause the IP address to be allocated from another BSC
site. For example:

The DHCP broadcast is not prevented to access DHCP servers at other BSC sites.
This is possible if the dedicated LDI VLAN is not used, and the default VLAN is
allowed in the MSTP region uplinks.
The DHCP server at another BSC site responds to the DHCP broadcast.

Besides the above-mentioned problem cause, incorrect location coding of the ESB's
ADMODD module may also cause this problem situation.
Instructions
The following instructions on the checking the configuration help you to determine the
problem cause.

74

Id:0900d805807a9858

DN05104459
Issue 2-2

Handling Common Problem Situations in BSC

Problems with LAN Device Integration

Before you start:

Ensure that the VLAN and MSTP configurations are correct. For instructions, see
Problems with Telnet.
Ensure that the location coding of the ADMODD module is correct. For instructions
on checking the location coding, see step 3 g) Check the location of the ADMODD
module (W6I) of IP addressing failure in Integrated LAN Administration troubleshooting.

1. Open a serial cable connection to the ESB switch and check the IP address. Use the
following commands:
Example:
SWU-0#enable
SWU-0#show ip
IP-ADDR : 10.16.137.2 NET-MASK : 255.255.255.240
2. Check if the IP address has been allocated from the local BSC site. Use the BSC
MMI.
ZWYI;
Example:
ID
UNIT
IF
IP ADDRESS
HOST OR SUPERV
HW ID CODE
NAME
UNIT
IN HEX
------ ---------------- ------ --------------- ---------------- ---------1
MCMU-0
10.1.6.1
EL0
10.16.138.1
EL1
10.16.138.17
2
SWU-2
10.16.138.3
MCMU-0
1A10
2
SWU-0
10.16.138.2
MCMU-0
1210
3
SWU-3
10.16.138.19
MCMU-0
1A11
3
SWU-1
10.16.138.18
MCMU-0
If the IP address is not from the local BSC subnet mask, as in the example above, it
means that it has been allocated from another BSC site. In this case, proceed to step
3.
3. Switch back to the serial cable connection and check that the default VLAN configuration does not include any tagged/untagged ports. Use the show vlan command.
Example:
SWU-0#show vlan
====================================================================
Name
|VTag| Tagged ports
| Untagged ports
--------------------+----+---------------------+-------------------default
|1
|
|
ldi
|11 |1/1/1,1/1/2
|1/1/3,1/1/9,1/1/10
4. If there is a port definition for the default VLAN, remove the ports. Use the following
commands:
Example:
SWU-0#configure terminal
SWU-0#vlan
SWU-0#config default
SWU-0#remove ports 1/1/1-1/1/20

DN05104459
Issue 2-2

Id:0900d805807a9858

75

Problems with LAN Device Integration

Handling Common Problem Situations in BSC

5. Open a telnet connection to the multilayer site switch(es) and check the LDI VLAN
usage in the uplinks connected to the local BSC site. Use the following commands:
Example:
CISCO-1#enable
CISCO-1#show running-config
interface GigabitEthernet1/0/3
description swu0_BSC1
switchport trunk allowed vlan 11,20,21,30,31
interface GigabitEthernet1/0/4
description swu2_BSC1
switchport trunk allowed vlan 11,100
Only the local LDI VLAN (for example, 11) is allowed to be in the VLAN trunk. LDI
VLANs at other BSC sites are not allowed to be in the trunk.
6. Open a serial cable connection to the ESB and activate the DHCP. Use the following
commands:
Example:
SWU-0#clear last saved position
SWU-0#ip address dhcp renew
SWU-0#show ip
IP-ADDR : 10.16.138.2 NET-MASK : 255.255.255.240
The IP address should now be correct and the telnet access working.
7. If the problem still persists, collect all the information needed for a Problem Report
and contact Nokia Siemens Networks for further investigations. For instructions, see
Reporting problems with LAN Device Integration in BSC Problem Reporting.

76

Id:0900d805807a9858

DN05104459
Issue 2-2