Sie sind auf Seite 1von 105
BSC3153 Nokia GSM/EDGE BSS, Rel. BSS13, BSC and TCSM, Rel. S13, Product Documentation, v.1 Handling
BSC3153 Nokia GSM/EDGE BSS, Rel. BSS13, BSC and TCSM, Rel. S13, Product Documentation, v.1 Handling

BSC3153

Nokia GSM/EDGE BSS, Rel. BSS13, BSC and TCSM, Rel. S13, Product Documentation, v.1

Handling Common Problem Situations in BSC

DN05104459

# Nokia Siemens Networks

1 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC The information in this document is subject to change without

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 2008. All rights reserved.

2 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Contents

Contents Contents Contents 3 List of tables 6 List of figures 7 Summary of changes 9

Contents

Contents 3

List of tables 6

List of figures 7

Summary of changes 9

1

Overview of common problem situations in BSC 11

2

Problems with radio network configuration and recovery 15

2.1

Modifying radio network configuration fails because of lack of resources 15

2.2

Outputting or modifying radio network configuration fails without obvious reason 17

2.3

Radio network object is not found in BSDATA 18

2.4

BCF configuration with EDGE and non-EDGE TRXs in the same BTS fails 20

2.5

TRX LAPD links remain in the UA-AD RN RECOV state without an active alarm 21

3

Problems with circuit-switched calls 23

3.1

Inter-system handover BSC-RNC-BSC fails 23

3.2

Activating AMR HR (HR3) with parameter HR_FEATURE_IN_BSC fails 24

3.3

Cell Broadcast Centre does not work 24

3.4

Circuit-switched call fails with alarm 1582 CONNECTION OR RELEASE ERROR 25

3.5

BSC-BSC interface configuration to only one BCSU unit causes problems during BCSU switchover 26

3.6

Alarm 7737 INCONSISTENT DATA IN RADIO RESOURCE MANAGEMENT STATE FILES is raised 26

3.7

Alarm 7741 MEAN HOLDING TIME ABOVE DEFINED THRESHOLD is raised 27

3.8

Alarm 2725 ADJACENT CELL IDENTIFIER CONFIGURATION ERROR is raised 28

3.9

SIGTRAN A interface is down (UA-INS) 30

4

Problems with packet-switched calls 35

4.1

Problems with TBF establishment 35

4.1.1

TBF establishment fails due to lack of Abis channel resources 35

4.2

Problems with GPRS/EDGE cell changes 36

4.2.1

High NCCR failure rate 36

4.3

Problems with transmission in the Abis interface 38

4.3.1

Continuous resynchronisation 39

4.3.2

Unsuccessful initial synchronisation or resynchronisation 40

4.3.3

No PCU synchronisation frames received from the BTS 41

4.3.4

BPN jump in synchronisation time 42

DN05104459

# Nokia Siemens Networks

3 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 4.3.5 TBFs do not have enough EDAP resources 43  

4.3.5

TBFs do not have enough EDAP resources 43

 

4.3.6

EDAP configuration fails 45

4.4

Problems with transmission in the Gb interface 46

 

4.4.1

Inconsistent BVCI states between the BSC, the PCU and the SGSN 46

4.4.2

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

4.4.3

BVCI operational state remains UNBLOCKED 48

 

4.4.4

Gb over IP: DX error 16246 appears 49

4.5

Problems with performance 50

4.5.1

Low downlink GPRS/EDGE throughput 50

 

4.6

Problems with territory operations 52

4.6.1

GPRS/EDGE territory failures 52

5

Problems with synchronisation 55

 

5.1

Incoming synchronisation from an external source fails 55

5.2

Clock and Synchronisation Unit fails 58

5.3

Timing signal distribution fails 60

6

Problems with transmission 63

6.1

Problems with PCM transmission 63

 

6.1.1

Transmission line between the BSC and a transmission node is broken 63

6.2

Problems with IP transport 66

6.2.1

Signal in the IP network does not go through 66

 

7

Problems with operation and maintenance 77

7.1

Problems with Q3 connections 77

7.1.1

BSC alarms are missing from Nokia NetAct 77

7.1.2

BSC measurement result files are missing from Nokia NetAct 78

7.1.3

Creating, modifying, or uploading RNW objects with Nokia NetAct applications fails 80

7.1.4

All connections from the BSC to Nokia NetAct are lost 81

 

7.2

Problems with software package handling 81

7.2.1

Change delivery installation fails 81

7.2.2

Multiple change delivery installation fails 82

7.3

Problems with licence handling 83

7.3.1

Licence installation fails, licence file not found 83

7.3.2

Licence installation fails, licence file already found 84

7.3.3

Licence installation fails, licence is not valid 84

7.3.4

Licence installation succeeds, but copying or deleting the licence file fails 85

7.3.5

Interrogating installed licences or features fails 86

 

7.3.6

Licence database is corrupted

86

7.3.7

Licence file handling with Nokia NetAct Licence Manager fails 87

8

Problems with location-based services 89

 

8.1

Problems with the internal SMLC 89

8.1.1

BSC gives inaccurate location estimates or returns the location response with an error cause 89

8.2

Problems with the Lb interface 90

 

8.2.1

Lb interface is down (UA-INS) 90

9

Problems with LAN Device Integration 95

 

4 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Contents

Contents 9.1 Problems with Telnet 95 9.1.1 Accessing the ESB switch fails 95 9.2 Problems with

9.1

Problems with Telnet 95

9.1.1

Accessing the ESB switch fails 95

9.2

Problems with DHCP 102

9.2.1

Negotiating an IP address fails 102

DN05104459

# Nokia Siemens Networks

5 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC List of tables 6 (105) # Nokia Siemens Networks DN05104459

List of tables

6 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

List of figures

List of figures List of figures Figure 1. Common PCM transmission problem situations 64 DN05104459 #

List of figures

Figure 1. Common PCM transmission problem situations 64

DN05104459

# Nokia Siemens Networks

7 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 8 (105) # Nokia Siemens Networks DN05104459   Issue 2-0

8 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Summary of changes

Summary of changes Summary of changes Changes between document issues are cumulative. Therefore, the latest document

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

DN05104459

# Nokia Siemens Networks

9 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Problems with location-based services : Sections 'Problems with the

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.

10 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Overview of common problem situations in BSC

Overview of common problem situations in BSC 1 Overview of common problem situations in BSC Problem

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.

DN05104459

# Nokia Siemens Networks

11 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Analyse and categorise the symptoms and list possible causes for

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.

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.

12 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Overview of common problem situations in BSC

Overview of common problem situations in BSC Based on the principles of the general troubleshooting actions,

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

.

.

.

Problems with radio network configuration and recovery

Problems with circuit-switched calls

Problems with packet-switched calls

DN05104459

# Nokia Siemens Networks

13 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC . . . . . Problems with synchronisation Problems with

.

.

.

.

.

Problems with synchronisation

Problems with transmission

Problems with operation and maintenance

Problems with location-based services

Problems with LAN Device Integration

Other related topics in BSC/TCSM documentation

.

.

.

.

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.

14 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with radio network configuration and recovery

Problems with radio network configuration and recovery 2 Problems with radio network configuration and recovery For

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.

DN05104459

# Nokia Siemens Networks

15 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Instructions 1. Check the state of the BSS RNW plan

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.

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.

16 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with radio network configuration and recovery

Problems with radio network configuration and recovery 2.2 Outputting or modifying radio network configuration fails

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

UNLOCKED

BL-USR

5 171-

4

1

TCHD

0

UNLOCKED

BL-USR

6 171-

4

2

TCHD

0

UNLOCKED

BL-USR

7 171-

4

3

TCHD

0

UNLOCKED

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.

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.

DN05104459

# Nokia Siemens Networks

17 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 1. Copy the BSDATA to a disk. ZDBC:BSDATA,0; 2. Prevent

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

18 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with radio network configuration and recovery

Problems with radio network configuration and recovery Example /*** DX ERROR: 10540 ***/ /*** BTS NOT

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.

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

DN05104459

# Nokia Siemens Networks

19 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 2.4 BCF configuration with EDGE and non-EDGE TRXs in the

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 non-EDGE-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:

.

.

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

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.

20 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with radio network configuration and recovery

Problems with radio network configuration and recovery ZEQS:<BTS identification or BTS name>:L; 3. Repair the

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

DN05104459

# Nokia Siemens Networks

21 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC ZDTC:<D-channel link set name>:BL; ZDTC:<D-channel link set

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

. Lock and unlock the Base Control Function (BCF).

ZEFS:<BCF identification>:L;

ZEFS:<BCF identification>:U;

22 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with circuit-switched calls

Problems with circuit-switched calls 3 Problems with circuit-switched calls For an overview, see Overview of common

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.

DN05104459

# Nokia Siemens Networks

23 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 3.2 Activating AMR HR (HR3) with parameter HR_FEATURE_IN_BSC fails Symptoms

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:

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

24 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with circuit-switched calls

Problems with circuit-switched calls Possible causes The network user authority information is not correct. There is

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 for a macro that can be used

to investigate the failure further.

DN05104459

# Nokia Siemens Networks

25 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 3.5 BSC-BSC interface configuration to only one BCSU unit causes

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

26 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with circuit-switched calls

Problems with circuit-switched calls Possible causes The alarm is raised because there is an internal error

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

3. If the alarm occurs repeatedly in the same BTS, collect all the information needed for a Problem Report and contact Nokia 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.

DN05104459

# Nokia Siemens Networks

27 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Possible causes This alarm is raised when the mean holding

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 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 contains the broadcast control channel

28 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with circuit-switched calls

Problems with circuit-switched calls (BCCH) frequency and the base station identity code (BSIC) of the target

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

BSCSG9902

**

ALARM BCSU-2

Example

BCSU-2

1A002-27

SWITCH

HAS_BX

2004-03-24 09:45:36.96

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

2

BACKGROUND NETWORK COLOUR CODE

(BNCC)

-

DN05104459

# Nokia Siemens Networks

29 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC BTS COLOUR CODE (BCC) 2 BACKGROUND BTS COLOUR CODE (BBCC)

BTS COLOUR CODE

(BCC)

2

BACKGROUND BTS COLOUR CODE

(BBCC)

-

FREQUENCY NUMBER OF BCCH

(FREQ)

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 09:45:36.96

**

ALARM BCSU-2

1A002-27

HAS_BX

(0004) 2725 ADJACENT CELL IDENTIFIER CONFIGURATION ERROR

111d 01 06 02 623d

LOCATION AREA CODE

(LAC)

1000

CELL IDENTIFICATION

(CI)

27926

NETWORK COLOUR CODE

(NCC)

2

BACKGROUND NETWORK COLOUR CODE

(BNCC)

-

BTS COLOUR CODE

(BCC)

2

BACKGROUND BTS COLOUR CODE

(BBCC)

-

FREQUENCY NUMBER OF BCCH

(FREQ)

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

30 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with circuit-switched calls

Problems with circuit-switched calls Possible causes The A interface may be down because transmission is not

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

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;

DN05104459

# Nokia Siemens Networks

31 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Example NSI:NA0,; BSC3i BSC21 2007-08-07 10:09:09 INTERROGATING

Example

NSI:NA0,;

BSC3i

BSC21

2007-08-07 10:09:09

INTERROGATING SIGNALLING LINK SET DATA

IP LINK

--- ------------------ ---------- --------------------- -------- -------

NA0 0201/00513

NET

SP CODE H/D

LINK SET

16 MSCI

ASSOCIATION SET

LS STATE

UA

0 TOMSCI LINK TEST NOT ALLOWED

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;

OYI:NBR=0:A:;

Example

LOADING PROGRAM VERSION 5.8-0

BSC3i

BSC21

2007-08-07 10:12:15

INTERROGATING ASSOCIATION SET DATA

ASSOCIATION SET NAME

ASSOC SET ID

SCTP USER

ROLE

--------------------

------------

---------

--------

TOMSCI

0

M3UA

CLIENT

ASSOC.

ASSOC ID PARAMETER SET

 

IND

UNIT

IN UNIT

NAME

STATE

---

------- --------- ---------------- --------------------

0

BCSU-1

2 SS7

UP-PROCEEDING

SOURCE ADDRESS 1 SOURCE ADDRESS 2

SOURCE PORT

. PRIMARY DEST. ADDRESS

SECONDARY DEST. ADDRESS . : 10.16.143.133/26

DESTINATION PORT DATA STREAM COUNT

: 10.16.153.85 : 10.16.153.101 . : EPHEMERAL : 10.16.143.69/26

: 2905

.

:

16

.

.

.

.

.

.

.

.

ASSOC.

ASSOC ID PARAMETER SET

 

IND

UNIT

IN UNIT

NAME

STATE

---

------- --------- ---------------- --------------------

1

BCSU-5

1 SS7

UP-PROCEEDING

32 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with circuit-switched calls

Problems with circuit-switched calls SOURCE ADDRESS 1 SOURCE ADDRESS 2 SOURCE PORT . PRIMARY DEST. ADDRESS

SOURCE ADDRESS 1 SOURCE ADDRESS 2

SOURCE PORT

. PRIMARY DEST. ADDRESS

SECONDARY DEST. ADDRESS . : 10.16.143.134/26

: 10.16.153.86 : 10.16.153.102 . : EPHEMERAL : 10.16.143.70/26

.

.

.

.

.

DESTINATION PORT

: 2905

DATA STREAM COUNT

.

.

.

.

: 16

SPECIFICATION VERSION TRAFFIC MODE ASP MESSAGES REGISTRATION REQUEST

SSNM MESSAGES BROADCAST . :

: 1.0 (RFC) : LOAD-SHARE : YES : YES NO

.

.

NETWORK APPEARANCE

 

:

8

ASP MESSAGES IN IPSP

 

:

NO

ROUTING CONTEXT

.

.

.

.

.

:

---

FIRST DATA STREAM NUMBER . :

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.

DN05104459

# Nokia Siemens Networks

33 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 34 (105) # Nokia Siemens Networks DN05104459   Issue 2-0

34 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls 4 Problems with packet-switched calls All the problem situations listed below may

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 Problems with TBF establishment

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

 

Counters 072079 NO RADIO RES AVA UL TBF and 072080 NO RADIO RES AVA DL TBF are also updated.

DN05104459

# Nokia Siemens Networks

35 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC In this situation, no Abis channel resources are allocated to

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.

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

4.2 Problems with GPRS/EDGE cell changes

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

36 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls . . . The cause may be an MS fault where the

.

.

.

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:

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

DN05104459

# Nokia Siemens Networks

37 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Instructions A high NCCR failure rate does not necessarily require

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

38 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls 4.3.1 Continuous resynchronisation Symptoms In continuous resynchronisation, an active

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

DN05104459

# Nokia Siemens Networks

39 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC For more information on EDAP configuration, see Dynamic Abis System

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

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.

40 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls Instructions 1. Check the transmission. Especially, pay attention to the ETs and

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

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.

DN05104459

# Nokia Siemens Networks

41 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC . . There are internal or external faults in the

.

.

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.

2. If nothing seems to be wrong with the transmission, collect all the information needed for a Problem Report and contact Nokia 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:

42 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls Example USER TEXT: PCU block synchronization timeout (F) USER DATA: Synchronization

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.

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

DN05104459

# Nokia Siemens Networks

43 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Counters 076019 UL MCS LIMITED BY PCU or 076020 DL

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

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 .

44 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls 4.3.6 EDAP configuration fails Symptoms Alarm 3068 EGPRS DYNAMIC ABIS POOL FAILURE

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 USER DATA: pcu_edap_info_s is received in illegal DAM state <no.>

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.

DN05104459

# Nokia Siemens Networks

45 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Instructions 1. Check all MML commands given before the alarms

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 4.6.1 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 for further investigations. For instructions, see Collecting EDAP configuration failure logs (PCU1) or Collecting EDAP configuration failure logs (PCU2) in BSC

Problem Reporting.

Workarounds

Perform a BCSU switchover.

ZUSC:BCSU,<WO_index>:SP,;

4.4 Problems with transmission in the Gb interface

4.4.1 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 Un-known).

Possible causes

 

Inconsistent BVCI states may be caused by failures in BVC-RESET, BVC- BLOCK, or BVC-UNBLOCK procedures.

46 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls Instructions 1. Collect information needed for a Problem Report. For instructions, see

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

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

DN05104459

# Nokia Siemens Networks

47 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Instructions To solve the root cause of the problem, collect

Instructions

To solve the root cause of the problem, collect all the information needed for a Problem Report and contact Nokia 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;

48 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls 5. If the problem persists, collect all the information needed for a

5. If the problem persists, collect all the information needed for a Problem Report and contact Nokia for further investigations. For instructions, see 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.

DN05104459

# Nokia Siemens Networks

49 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Instructions 1. Check the active alarms and the alarm history,

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

4.5 Problems with performance

4.5.1 Low downlink GPRS/EDGE throughput

Symptoms

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

50 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls . . . EDGE key performance indicators (KPI) dap_7a, tbf_16, blck_33, trf_235b,

.

.

.

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 volume-weighted counters 090007 090012. 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 4.3.5 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.

DN05104459

# Nokia Siemens Networks

51 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC For more information, see Gb EDGE Dimensioning . 4. To

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 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 for further investigations. For instructions, see Reporting problems with performance (PCU1) or Reporting problems with performance (PCU2) in BSC Problem Reporting.

4.6 Problems with territory operations

4.6.1 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

the failures, see 4.6.1.1 Possible causes .

r

function. For individual examples of

52 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with packet-switched calls

Problems with packet-switched calls Possible causes If alarm 3068 is active, the cause can be a

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

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:

DN05104459

# Nokia Siemens Networks

53 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC USER TEXT: DAM: dam_delete_tsls USER DATA: DAM DSP params …

USER TEXT: DAM: dam_delete_tsls

USER DATA: DAM DSP params

invalid for PCU_TRX <no.>, RTSL <no.>

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 4.3.6 EDAP configuration fails .

2. If log writings indicating unsuccessful territory upgrades appear in the PCU1 log, see 4.3.5 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 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,;

54 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with synchronisation

Problems with synchronisation 5 Problems with synchronisation When the BSC and/or TCSM synchronisation fails, the

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.

DN05104459

# Nokia Siemens Networks

55 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC Possible causes The cause is more likely to be located

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

1.

2.

3.

alarm 2632 OSCILLATOR FAILURE is raised, do the following:

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.

Remove the loopback, or, if it cannot be removed, change the PCM used for the synchronisation input.

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.

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

the supplementary information fields of the alarm to detect the origin of the

alarm 2641 FAILURE IN SYNCHRONIZATION SIGNAL is raised, check

 

alarm.

56 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with synchronisation

Problems with synchronisation . . . 00 frequency of connected input below 3.7 kHz indicates that

.

.

.

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.

Tipsynchronisation signal frequency and the CLS frequency. You can also calculate the frequency difference using the

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.

Tipand note down the time between the slip counter increments. To detect which transmission directions suffer

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:

DN05104459

# Nokia Siemens Networks

57 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 1. Start forced use of input. It makes the CLS

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.

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 plug-in unit or the Clock and Synchronisation Cartridge (CLOC), for example, in the power feed of the CLOC cartridge.

58 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with synchronisation

Problems with synchronisation Instructions If alarm 2636 FAILURE IN OUTGOING CLOCK SIGNAL, 1630 RAM FAILURE IN

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

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.

DN05104459

# Nokia Siemens Networks

59 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 5.3 Timing signal distribution fails Symptoms A failure in timing

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.

2.

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.

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

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

several 2755 CARTRIDGE CLOCK FAILURE alarms are raised within

60 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with synchronisation

Problems with synchronisation If only one 2755 CARTRIDGE CLOCK FAILURE alarm is raised within the CLAB,

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.

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 .

DN05104459

# Nokia Siemens Networks

61 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC 62 (105) # Nokia Siemens Networks DN05104459   Issue 2-0

62 (105)

# Nokia Siemens Networks

DN05104459

 

Issue 2-0 en

Problems with transmission

Problems with transmission 6 Problems with transmission For an overview, see Overview of common problem situations

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

DN05104459

# Nokia Siemens Networks

63 (105)

Issue 2-0 en

Handling Common Problem Situations in BSC

Handling Common Problem Situations in BSC . . . 2900 INCOMING SIGNAL MISSING (both ETSI and

.

.