bsc problem reporting dn991432 9-1[1]

BSC Problem Reporting

DN991432Issue 9-1 en27/04/2009

# Nokia Siemens Networks 1 (92)

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted inany form or means without the prior written permission of Nokia Siemens Networks. Thedocumentation has been prepared to be used by professional and properly trained personnel,and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomescustomer comments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given “as is” and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues whichmay not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAYARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights andother intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia 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 2009. All rights reserved.

2 (92) # Nokia Siemens Networks DN991432Issue 9-1 en27/04/2009


Contents

Contents 3

Summary of changes 5

1 Overview of BSC Problem Reporting 9

2 Problem Report fields 112.1 Title and description fields in the Problem Report 112.2 Delivery field in the Problem Report 122.3 Severity field in the Problem Report 12

3 Information needed in the Problem Reports 153.1 Reporting problems with system restart 153.2 Reporting problems with unit restart 163.3 Reporting problems with process restart 173.4 Reporting problems with backup 183.5 Reporting problems with handovers 183.5.1 Collecting alarm 2725 logs 213.6 Reporting problems with power control 223.7 Reporting problems in storing and transferring statistical data 243.8 Reporting problems with alarms 243.8.1 Collecting alarm 7737 logs 253.8.2 Collecting alarm 7741 logs 263.9 Reporting problems with OSI 273.10 Reporting problems with hardware configuration 293.11 Reporting problems with I/O devices 293.12 Reporting problems with MML 303.13 Reporting problems with CCS7 313.14 Reporting problems with TCSM2 323.15 Reporting problems with TCSM3i 343.16 Reporting problems with TCSM3i for combined BSC3i/TCSM3i

installation 343.17 Reporting problems with GPRS/EDGE 343.17.1 Instructions for Capturing Alarm 1178 or 2770 logs (PCU1) 373.17.1.1 Log instructions with service terminal connection 393.17.1.2 Log instructions with serial cable connection to PCU 433.17.2 Reporting problems with Abis 483.17.2.1 Collecting synchronisation logs (alarm 7725, PCU1) 483.17.2.2 Collecting EDAP configuration failure logs (PCU1) 493.17.2.3 Collecting synchronisation logs (alarm 7725, PCU2) 533.17.2.4 Collecting EDAP configuration failure logs (PCU2) 543.17.3 Reporting problems with Gb interface (PCU1) 583.17.4 Reporting problems with Gb interface (PCU2) 603.17.4.1 Reporting problems with Gb over IP (PCU2) 633.17.5 Reporting problems with a sleeping cell (PCU1) 643.17.6 Reporting problems with a sleeping cell (PCU2) 653.17.7 Reporting problems with performance (PCU1) 673.17.8 Reporting problems with performance (PCU2) 68

DN991432Issue 9-1 en27/04/2009


Contents

3.17.9 Collecting alarm 3068 and 3273 logs 703.17.10 Reporting problems with NCCR cell changes (PCU1) 713.17.11 Reporting problems with NCCR cell changes (PCU2) 723.17.12 Reporting problems with GPRS/EDGE territory failures (PCU1) 743.17.13 Reporting problems with GPRS/EDGE territory failures (PCU2) 773.18 Reporting problems with SMSCB 803.18.1 Reporting problems with SMSCB MML interface 803.18.2 Reporting problems with CBC interface 813.19 Reporting problems with A interface signalling 823.20 Reporting problems with Abis interface signalling 833.21 Reporting problems with Q3 interface 843.22 Reporting problems with BSS Radio Network Recovery 853.23 Reporting problems with BSS Radio Network Configuration Database

(BSDATA) integrity 873.24 Reporting problems with licensing 873.25 Reporting problems with location-based services 883.26 Reporting problems with IP transport 893.27 Reporting problems with LAN Device Integration 91



Summary of changes

Changes between document issues are cumulative. Therefore, the latestdocument issue contains all changes made to previous issues.

Changes made between issues 9-1 and 9-0

In chapter Information needed in the Problem Reports :

. The title of the section Collecting alarm 1178 logs and 2770 logs hasbeen changed to Instructions for Capturing Alarm 1178 or 2770 logs(PCU1).

. Updated information in section Instructions for Capturing Alarm 1178or 2770 logs (PCU1).

. Added sections Log instructions with service terminal connectionand Log instructions with serial cable connection to PCU.


Chapter Problem Report fields: added a sentence about English being theonly language accepted in any field.

Chapter Information needed in the Problem Reports, sections Reportingproblems with a sleeping cell (PCU1) and Reporting problems with asleeping cell (PCU2): added two commands to list item 1. The sectionReporting problems with background database has been removed.

Chapter Information needed in the Problem Reports: added new sectionsReporting problems with IP transport and Reporting problems with LANdevice integration.

DN991432Issue 9-1 en27/04/2009


Summary of changes


Information on handling deficiencies in other documentation than NEDadded to chapter Overview of BSC Problem Reporting.

Section Severity field in the Problem Report updated in chapter ProblemReport fields.

Chapter Information needed in the Problem Reports:

The following sections contain major updates:

. Reporting problems with handovers

. Reporting problems with power control

. Reporting problems with alarms

. Reporting problems with (E)GPRS

. Reporting problems with SMSCB

. Reporting problems with A-interface signalling

The following sections are new:

. Reporting problems with TCSM3i

. Reporting problems with Nokia TCSM3i for combined BSC3i/TCSM3i

. Reporting problems with Q3-interface

. Reporting problems with BSS Radio Network ConfigurationDatabase (BSDATA) integrity

. Reporting problems with licensing

. Reporting problems with location-based services


The following changes have been made to chapter 3 Information neededin the Problem Reports:

Several syntaxes and commands have been improved.

Added information and steps to section 3.19 Reporting problems with BSSRadio Network Recovery.



New section 3.20 Reporting problems with background database added.

The document has been revised throughout to comply with the latestdocumentation standards.

DN991432Issue 9-1 en27/04/2009


Summary of changes

1 Overview of BSC Problem Reporting

The aim of these guidelines is to give instructions on how to fill in aProblem Report (PR) and what steps to take when collecting data for areported problem. Following these instructions improves problem locationand speeds up the correction process. Fast and reliable problem solving isbeneficial to all parties involved. These guidelines can also be used asinstructions on how to do a problem report in Nokia Online Services(NOLS).

The guidelines given here should be regarded as the minimum informationrequired in a PR. Any other information is welcome, but for examplemessage monitoring without the knowledge of the exact process causingthe problem might not be worth the effort.

You should also mention whether any special actions have taken placeprior to the problem (for example, Change Delivery installation, networkconfigurations, or extensions). As it might not be possible to execute all thecommands given as examples in these instructions, they need to beconsidered case by case. Avoid using local abbreviations and terminology,or at least explain them carefully.

These instructions do not handle hardware Problem Reports that areattached to faulty units being sent to the repair centre.

A PR can be used for many purposes other than reporting actualproblems.

Hardware problem

When you suspect that the hardware of the BSC causes the problem butyou cannot determine the faulty unit, you can report it with a PR. Includeinformation on the HW configuration and the units in use related to theproblem.

Check that the TYPE of the PR is set to the value HARDWARE.

DN991432Issue 9-1 en27/04/2009


Overview of BSC Problem Reporting

If you find the faulty unit, fill in the hardware problem report, attach it to theunit, and send them over to your local Nokia Siemens Networks HardwareServices.

System defect or problem

The most common usage of a PR is reporting system defects andproblems. They relate to the software or data configuration of the BSC.

Check that the TYPE of the PR is set to the value SOFTWARE.

Documentation problem

Whenever you discover a deficiency in BSC NED documentation in NOLS,contact the NOLS Documentation Center Feedback channel. Remembernot only to report the actual problem but also to specify the following:

. the subject where you have discovered the deficiency

. identification and issue information concerning the text (for exampleDN9912345, Issue 3–1)

. the release it is in

In the NED, click the circled blue 'i' in the top right corner of the textwindow. You can now see the identification and version informationconcerning the text.

Note that if you discover a deficiency in other BSC documentation (such asupgrade documentation, SW and HW technical notes, change deliverydocumentation) do not contact NOLS Documentation Center Feedbackchannel. Instead, handle the case as a system defect or problem.

Other

If you have a deficiency or a problem which is other than the onesmentioned above, check that the TYPE of the PR is set to value OTHER.Describe the problem in detail.

Related topics

. Problem Report fields

. Information needed in the Problem Reports



2 Problem Report fields

You are linked to the Maintenance Process through the Customer CareProcess. You approach Nokia to make a request for technical assistanceor to solve a system or product malfunction. These customer supportrequests are recorded into Electra. The troubleshooting starts as a part ofthe Customer Care Process. Your request is sent to the Product CreationProcess when the Tier3 Active Agent (Technical/Maintenance Supportengineer) has confirmed that the problem in question is a product defect.

Note that the only language accepted in any field is English.

2.1 Title and description fields in the Problem Report

Make sure that the Title field clearly describes the main content of theproblem.

When filling in the Description field, make sure that you include thefollowing important information:

. the actual problem

. the impact of the problem to the operator, mobile subscriber, or athird party

. the description of the procedures and the environment before theproblem occurred, for example, parameters of the MML commands

. description of the problem situation, how it appeared and affectedthe system

. how the situation was rectified and

. the possible cause of the problem.

DN991432Issue 9-1 en27/04/2009


Problem Report fields

Often this information is not clearly stated and, as a result, it is very difficultor even impossible to investigate the problem. This causes delay in thecorrection delivery.

Fill in the description field properly. For example, stating "See attachedfiles" is not a valid description, even if the attachments have goodexplanations.

Note that each problem needs to be reported separately, that is, only oneproblem per Problem Report. This is important because different problemsare normally handled in different software groups, and the management of"multi-PRs" is not possible.

Avoid using terms or abbreviations not commonly known in GSMvocabulary (for switch names and special services, for example), unlessyou explain them carefully.

2.2 Delivery field in the Problem Report

It is important to fill in the right C-number of the BSC (BSC id) to theDelivery field. This is important because the customer code is based on itand the software status can be checked with the help of the number. TheC-number is a unique identification given by BASK logistics.

You can find the C-number from the bottom of the cabinet or you canoutput the C-number with the following command:

ZQNI;

2.3 Severity field in the Problem Report

In addition to the visual impact described in the Description field, also usethe Severity field to indicate the scale of the impact that the problem has inrelation to all the other Problem Reports.

The severities to be used are Critical, Major and Minor. Only the mosturgent cases should be indicated as Critical.



It does not speed up the correction process if all Problem Reports arereported as Critical, because then the really important cases can be buriedunder the less important ones. However, the correct use of this field helpsdetect the most important problems and speeds up the investigation.

The following sections describe the different impact values with the help ofexamples. The examples should help you classify your problem with thecorrect impact value.

Critical problem

Conditions that severely affect the service, capacity/traffic, billing, andmaintenance capabilities and require immediate corrective action,regardless of the time of the day or day of the week, as viewed by acustomer upon discussion with the organization. For example:

. a loss of service that is comparable to the total loss of effectivefunctional capability of an entire switching or transport system

. a reduction in capacity or traffic handling capability so that expectedloads cannot be handled

. any loss of safety or emergency capability (for example emergencycalls)

Major problem

Conditions that seriously affect the system operation, maintenance, andadministration, and require immediate attention as viewed by the customerupon discussion with the organization. The urgency is not critical becauseof a lesser immediate or impending effect on the system performance,customers, and the customer's operation and revenue. For example:

. reduction in any capacity/traffic measurement function

. any loss of functional visibility and/or diagnostic capability

. short outages equivalent to system or subsystem outages withaccumulated duration of greater than two (2) minutes in any twenty-four (24) hour period, or outages that continue to repeat duringlonger periods of time

. repeated degradation of DS1 or higher rate spans or connections

. prevention of access for routine administrative activity

. degradation of access for maintenance or recovery operations

DN991432Issue 9-1 en27/04/2009


Problem Report fields

. degradation of the system's ability to provide any required Critical orMajor Trouble notification

. any significant increase in product-related customer trouble reports

Minor problem

Conditions that do not significantly impair the functioning of the system anddo not significantly affect the service to customers. These problems do notaffect the traffic.

Note that engineering complaints are classified as Minor unless otherwisenegotiated between the customer and the supplier.

Example situations are:

. activation of a new functionality fails

. single performance measurement is not working completely

. configuration changes (RNW, HW, and SW) are not workingcompletely

. alarm management of objects (BTS, functional units) are not workingcompletely

. capacity/quality related functionality is not working completely

Example cases for documentation problems are:

. alarm or description is missing from documentation

. vital subjects are missing from the BSC documentation

. pictures or tables are missing from documentation

Problems concerning documentation can have as a solution aDocumentation Change Note or a work-around solution. Enhancementand improvement proposals for existing documents can be sent to theNOLS Documentation Center Feedback channel.



3 Information needed in the ProblemReports

As it may not always be possible to execute all the commands given asexamples, they need to be considered case by case.

For most cases it is important to collect information on the problem rightaway, later it may no longer be possible and the real reason for theproblem may remain unsolved.

Whatever the problem may be, you should report the following:

. a detailed description of what was done or what happened prior tothe problem and what actions were taken during it. It is important toexplain all the operational activities, even if it seems that they are notrelated to the problem itself. Also, possible special conditions mustbe described, for example, in call profiles.

. the alarm history starting from an appropriate time before theproblem occurred. The command ZAHP can be used to print thealarm history.

. installed Change Deliveries. The command ZWNH can be used to listinformation on installed CDs.

Remember to fill in the Title, Description, and Impact fields in the ProblemReport fields.

3.1 Reporting problems with system restart

In case of problems in the system restart, you should collect the followinginformation:

DN991432Issue 9-1 en27/04/2009


Information needed in the Problem Reports

. the black boxes of working (WO) and spare (SP) computer units

. the alarm history and blocked alarms of the network element startingfrom four hours before the system restart

. the MML log files of those users which were active prior to the resetfor possible further investigations.

You can use the following commands:

ZDDE:<computer_unit>,<unit index>:"ZLE:1,BOXANAGX","Z1U";

ZAHP:::<date,time>;

ZIGO:<date,time>:USERID=ALL;

3.2 Reporting problems with unit restart

When encountering problems with unit restarts, you should collect thefollowing information:

. the blackbox of the restarted unit

. the alarm history of the unit starting from four hours before the restart

. the MML log files of those users which were active prior to the reset.


ZDDE:<computer unit>,<unit index>:"ZLE:1,BOXANAGX","Z1U";

ZAHP:::< date,time >;

ZWQO:CR;

ZWTI:P;

ZUSI;




Copy the ALHISTGX.ALF file from the used LFILES directory in the BSCdisk file and send it with the other logs.

3.3 Reporting problems with process restart

When encountering problems with process restarts, you should collect thefollowing information:

. the alarm history of the unit starting from four hours before theprocess restart

. the logs, operating system error counters, used buffers of the unit,and the version of the restarted process.


ZDDE:<computer unit>,<unit index>:"ZSLP";

ZDDE:<computer unit>,<unit index>:"ZSLE";

ZDDE:<computer unit>,<unit index>:"ZSB";

ZDDE:<computer unit>,<unit index>:"ZSCFE";

ZDDE:<computer unit>,<unit index>:"ZGSC";

ZAHP:::< date,time >;

ZWQV:<computer unit>,<unit index>:xxx%;

where

xxx = the first three letters of the process

ZWQO:CR;

ZWTI:P;

DN991432Issue 9-1 en27/04/2009



3.4 Reporting problems with backup

When encountering problems with backup, you should collect the followinginformation:

. alarms that are on, alarm history, and blocked alarms

. the MML log of the user (note that Command Calendar is also a user= COMCAL)

. used backup media

. used procedure

. computer log of the OMU.


ZAHO;

ZABO;

ZDDE:OMU:"ZGSC";

ZAHP:::<date,time>;

ZICL;

ZIAI:USERID=ALL;


ZUSI;

ZWXI;

3.5 Reporting problems with handovers

When encountering problems with handovers, you should collect thefollowing information:




. MML outputs

. computer logs.


ZAHO;

ZAHP:::<date,time>;

ZABO;

ZEQO:BTS=<source_bts_id>:ALL;

ZEQO:BTS=<target_bts_id>:ALL;

ZEAO:BTS=<source_bts_id>;

ZEHO:BTS=<source_bts_id>;

ZEQO:SEG=<source_SEG_id>:ALL;

ZEQO:SEG=<target_SEG_id>:ALL;

ZEAO:SEG=<source_SEG_id>;

ZEHO:SEG=<source_SEG_id>;

ZEEI:SEG=ALL;

ZEWO:<bcf_id>;

ZEGO:ALL;

ZEEI;

ZEEO;


ZWQO:CR;

The following monitorings are also useful:

DN991432Issue 9-1 en27/04/2009



. signalling monitorings from the Abis and A interfaces (both sourceand target BTSs)

. message monitorings from the BCSUs that control the TRXs of thesource and target BTSs

Message monitoring from the RCS program block

Monitoring messages from the RCS program block from the BCSUs thatcontrol the source and the target BTS:

Monitored BCSUs can be found in the printout of the following command:

ZEEI:BTS=<source_bts_id>;

The monitoring must be performed for all the BCSUs controlling the TRXs(BCSU in the ZEEI printout).

The message bus index of the BCSU to be monitored can be obtained byadding the number 3 in front of the BCSU index. For example, themessage bus index of BCSU-5 is 35.

All of the following commands are given in the service terminal of theOMU. Log in to the terminal with the ZDDS command.

Reserve buffer:

ZOEBR:<message bus index of the BCSU(s)>:3FFFFF

Give monitoring conditions:

ZOEC:<message bus index of the BCSU(s)>:SR:((OFAM=1B3)OR(CFAM=1B3))

Start monitoring:

ZOEM:<message bus index of the BCSU(s)>

At this point a HO failure needs to occur.

Stop monitoring:

ZOES:<message bus index of the BCSU(s)>

Print out the monitored messages:

ZOEG:<message bus index of the BCSU(s)>



Destroy monitorings:

ZOEQ:<message bus index of the BCSU(s)>

3.5.1 Collecting alarm 2725 logs

When encountering the alarm 2725 ADJACENT CELL IDENTIFIERCONFIGURATION ERROR, you should collect the following information:

. alarm information

ZAHO;

. configuration information

ZEAO:BTS=1&&248;

. information on the working BCSU

ZDDE:BCSU,<working BCSU>:"ZGSC";

. HAS monitoring from all BCSUs

Log in to the terminal:

ZDDS:BCSU,<working BCSU>;

Reserve buffer:

ZOEBR::7FFFFF


ZOEC::SR:(((CFAM=1C0)AND(NUM=9360,9368,9405,9673,9408,9369,9463,9361,9652,9483,9411))OR((OFAM=1C0)AND(NUM=9360,9368,9405,9673,9408,9369,9463,9361,9652,9483,9411)))

Start monitoring:

ZOEM

Stop monitoring:

ZOES


ZOEG

DN991432Issue 9-1 en27/04/2009




ZOEQ

3.6 Reporting problems with power control

In case of power control problems, you should collect the followinginformation:


. MML outputs

. computer logs from the BCSUs that control the BTS.


ZAHO;

ZAHP:::<date,time>;

ZABO;

ZEQO:BTS=<BTS identifier>:ALL;

ZEAO:BTS=<BTS identifier>;

ZEUO:BTS=<BTS identifier>;

ZEGO:ALL;

ZEEI;

ZEEO;

ZDDE:<computer unit>,<unit index>:”ZGSC”;

The following monitorings are also useful:

. TRX signalling monitorings of all TRXs of the problematic BTS

. message monitorings from the BCSUs of all TRXs of the problematicBTS



These monitorings are easy to perform in a test environment, but in a livenetwork it may be impossible.

Message monitoring from the RCS program block

Monitoring messages from the RCS program block from the BCSUs thatcontrol the TRXs of the problematic BTS:

Monitored BCSUs can be found in the printout of the following command:

ZEEI:BTS=<index of the problematic BTS>;

The monitoring must be performed for all the BCSUs controlling the TRXs(BCSU in the ZEEI printout).

The message bus index of the BCSU to be monitored can be obtained byadding the number 3 in front of the BCSU index. For example, themessage bus index of BCSU-5 is 35.


Reserve buffer:

ZOEBR:<message bus index of the BCSU(s)>:3FFFFF


ZOEC:<message bus index of the BCSU(s)>:SR:((OFAM=1B3)OR(CFAM=1B3))

Start monitoring:

ZOEM:<message bus index of the BCSU(s)>

At this point power control needs to occur.

Stop monitoring:

ZOES:<message bus index of the BCSU(s)>


ZOEG:<message bus index of the BCSU(s)>


DN991432Issue 9-1 en27/04/2009



ZOEQ:<message bus index of the BCSU(s)>

3.7 Reporting problems in storing and transferringstatistical data

When encountering problems in storing or transferring statistical data, youshould collect the following information:

. alarms (active and history)

. computer logs of the OMU, BCSU, and MCMU

. the connections of the logical files in the OMU

. output of the VDS status

. statuses of the I/O devices of the OMU.


ZAHO;

ZAHP:<date,time>;


ZIID:,OMU;

ZIFO:OMU:OBSERV;

ZIFO:OMU:MEASUR;

ZISI:,<unit>;

3.8 Reporting problems with alarms

When encountering problems with alarms, you should collect the followinginformation:



. alarms that are on, the alarm history, and blocked alarms

. computer log of the unit in question.


ZAHO;

ZAHP:::<date,time>;

ZABO;


ZWQO:CR;

ZIID;

ZISI;


When encountering the alarm 7737 INCONSISTENT DATA IN RADIORESOURCE MANAGEMENT STATE FILES, you should collect thefollowing information:

. First, load the Radio Resource Monitoring service terminal extensionin the working MCMU:

ZLE:<char>,E00_BXSX

<char> stands for the name of the extension. You can use any letterthat is not already linked to an extension.

You can use the ZUSI:COMP; command to find out which MCMU isin the working state.

. BTS state files by using the Radio Resource Monitoring serviceterminal extension

Print out the real-time BTS-specific data from the BTS where thealarm occurs by giving the following commands in the workingMCMU unit:

Z<char>A:1,<BTS_id>,FF;

DN991432Issue 9-1 en27/04/2009



Z<char>A:B,<BTS_id>,FF;

Note that the BTS_ID parameter is given in hexadecimal format.

. TCH and SCH state files by using the Radio Resource Monitoringservice terminal extension

Print out the real-time TCH state file (TCHSTA) and SCH state file(SCHSTA) data from BTS where the alarm occurs by giving thefollowing commands in the working MCMU unit:

Z<char>D:1,<BTS_id>,<TRX_id>,<TSL_id>,FF;


Note that the parameters BTS_ID, TRX_ID, and TSL_ID are givenin hexadecimal format.

. PCU list from BSC Traffic Meas File by using the Radio ResourceMonitoring service terminal extension

Give the following command in the working MCMU unit:

Z<char>A:6,<BTS_id>,0;

Note that the parameter BTS_ID is irrelevant because the printout isBSC-wide.

. Counter values from Traffic, Clear Code, and Resource AvailabilityMeasurements by using the BSC Measurement Counters DisplayingProgram (FOXMEA) service terminal extension or NetAct.

. Print out a version of RRM from the working MCMU with thefollowing command

ZSS:RRM;


When encountering the alarm 7741 MEAN HOLDING TIME ABOVEDEFINED THRESHOLD, you should collect the following information:

. First, take the Radio Resource Monitoring service terminal extensioninto use in the working MCMU:

ZLE:<char>,E00_BXSX




You can use the ZUSI:COMP; command to find out which MCMU isin the working state.

. TCH and SCH state files by using Radio Resource Monitoringservice terminal extension

Print out the real-time TCH state file (TCHSTA) and SCH state file(SCHSTA) data from the BTS where the alarm occurs by giving thefollowing commands in the working MCMU unit:



Note that the parameters BTS_ID, TRX_ID, and TSL_ID are givenin hexadecimal format.

. Use the Radio Resource Monitoring service terminal extensioncommand S to find out whether the channel seizure that caused thealarm is a real call or an unreleased channel. Give the followingcommand in the working MCMU unit:

Z<char>S:<BTS_id>,0,B,20=BUSY;

Note that the BTS_ID parameter is given in hexadecimal format.

3.9 Reporting problems with OSI

When encountering problems related to OSI, you should collect thefollowing information:


. OSI configuration



ZAHO;

ZAHP:::<date,time>;


ZWQO:CR;

DN991432Issue 9-1 en27/04/2009



ZWTI:P;

ZQNI;

ZQCI;

ZQBI;

ZQBL;

ZQDI::MAX;

ZQEI;

ZQLI;

ZQLP;

ZQQI;

ZQSI;

ZQTI;

ZQXI;

ZQWI::ALL;

ZQGI;

ZQHI;

ZQRI;

ZQKB;

ZQRS:OMU;

ZQHI;



3.10 Reporting problems with hardware configuration

When encountering problems related to the HW configuration, you shouldcollect the following information:


. output of the HW configuration of the unit where the problem occurs

. output of the response of the command currently used.


ZWQO:CR;


ZABO;

ZAHO;

ZAHP:::<date,time>;

ZUSI;

ZWTI:J;

ZWTI:C;

ZWTI:U;

ZWTI:P;

In addition, the serial number and interchangeability of the plug-in unit hasto be checked.

3.11 Reporting problems with I/O devices

When encountering problems related to the I/O devices, you should collectthe following information:

DN991432Issue 9-1 en27/04/2009




. statuses of the I/O devices of the unit concerned

. computer log of the unit concerned

. the connections of the logical files in the unit concerned

. device information - product name and interchangeability code.


ZWQO:CR;

ZDDE:OMU:"ZGSC";

ZABO;

ZAHO;

ZAHP:::<date,time>;

ZUSI;

ZISI;

ZIID;

ZWTI:P;

3.12 Reporting problems with MML

When encountering problems related to MMLs, you should collect thefollowing information:


. output of the response to the command currently used



ZWQO:CR;




ZABO;

ZAHO;

ZAHP:::<date,time>;

3.13 Reporting problems with CCS7

When encountering problems related to the CCS7, you should collect thefollowing information:


. CCS7 network configuration

. computer logs of the MCMU and BCSU



ZABO;

ZAHO;

ZAHP:::<date,time>;

ZNET;

ZNSI:<network number>;

ZNHI:<network number>;

ZNEL;

ZNPI;

ZOBI:<network number>;

ZOBL:<network number>;

DN991432Issue 9-1 en27/04/2009



ZNRI:<network number>;

ZNNI;

ZNMI;

ZNFI:<network number>;

ZOCI;

ZOCJ;

ZUSI;

ZWTI:P;

In addition, you should use a network analyser for A-interface monitoring.

3.14 Reporting problems with TCSM2

When encountering problems related to TCSM2, you should collect thefollowing information:


. TCSM2 network configuration


After logging in the TCSM with the command

ZDDT:TCSM,<TCSM_unit_no>;

use the following TCSM local commands:

ZCS

ZAI

ZAW

ZAF



ZLS

ZGT

ZGW

ZGI:<unit_type> (unit types TRCO, ET, and TR)

ZRC:<PCM_index>:<time_slot> (for example, output the first timeslotfrom each PCM)

ZRD

ZEO:ALL

ZEP:ALL

ZER:ALL

ZEI:ALL

ZIF:<PCM_index>

ZIU

ZIT:<PCM_index>

Use also the following BSC MML commands:

ZWGO;

ZWTI:P:TCSM,<units index>;

ZRCI:SEA=3:CGR=<A-interface circuit group number>:PRINT=5:;

ZWQO:CR;

ZDDE:OMU:"ZGSC";

ZABO;

ZAHO;

ZAHP:::<date,time>;

DN991432Issue 9-1 en27/04/2009



3.15 Reporting problems with TCSM3i

When encountering problems related to TCSM3i, use the commands listedin 3.15 Reporting problems with TCSM2 with the following exceptions:

. ZAF command is for TCSM2 only

. commands in the ZE command group and the commands ZIF andZIU should be given in the TCSM3i that controls the ET16s used bythe faulty TCSM3i

. ZLS should be given in the TCSM3i that controls the clocks.

3.16 Reporting problems with TCSM3i for combinedBSC3i/TCSM3i installation

When encountering problems related to TCSM3i, use the commands listedin 3.15 Reporting problems with TCSM2. However, commands in the ZEcommand group and the commands ZAF, ZIF, ZIU and ZLS do not apply tocombined BSC3i/TCSM3i installation.

3.17 Reporting problems with GPRS/EDGE

When encountering problems related to the PCU, you should collect thefollowing information:

. BSC release and SW level with the command:

ZWQO:CR;

. BTS version and SW release

. PCU software version CBOOTASX.IMG in the LFILES directory withthe command:

ZDPY:<computer unit>,<unit index>:PCU,<INDEX>:PID:;



ZDDE:OMU:"ZL:M","ZLP:M,MAS","ZMXP:W0-LFILES/CBOO*:*";

. the number of default GPRS channels in the cell with the command:

ZEQO:BTS=<BTS identifier>:GPRS;

. the configuration in the Gb interface (FR/IP and NS layers) with thecommands of the FU and FX command groups

. Frame Relay: FR bearer channel access rate with the command:

ZFUI;

. Frame Relay: committed information rate for NS-VC (BSC/SGSN),NSVC parameters and attached BTSs of the NSEIs with thecommands:

ZFXO:BCSU=0&&<max_BCSU_index>:BTS;

. Gb over IP: NS-VL parameters of the used NSEI with the command:

ZFXI:NSEI=<NSEI index>;

. Gb over IP: Attached BTSs of the NSEIs per created PSEIs with thecommand:

ZFXL:PSEI=0&&99:BTS;

. Gb over IP: Network interface data of the BCSUs with the command:

ZQRI:BCSU;

. used Routing Area(s) with the command:

ZEBP;

. active alarms in BSC with the commands:

ZAHO;

ZEOL;

. alarm history from the current day in the BSC with the command:

ZAHP:<date,time>;

. log information from the following using an GRPS/EDGE-capableAbis/Gb analyser:. TRXsig (GSM Abis) channels. GPRS traffic (TRAU) channels. Gb interface

. PCU log writings from all the BCSUs:

DN991432Issue 9-1 en27/04/2009



From the OMU service terminal (ZDDS;), go to the PCU serviceterminal with the command:

ZRS:3<BCSU_index>,<PCU_terminal_index+1>0BF

or

ZRS:3<BCSU_index>,<PCU_terminal_index+1>0BE

Check the PCU terminal index from the Frame Relay configurationprintout (ZFUI;).

BEARER BEARER BEARER CHANNEL EXT TIME

ID NAME RATE (KBIT/S) PCM SLOTS UNIT TERM FUNCT

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

0 SGSN1 128 41 1- 2 BCSU-7 4 0

Gb over IP:

ZFXL:PSEI=<PSEI index>:ALL;

PACKET SERVICE ENTITY DATA

PSE-01

======

ATTACHED NSE(S) TO PSE:

NSEI

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

02000

ATTACHED PCU(S) TO PSE:

PCU BCSU PCU

ID INDEX INDEX

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

00 00 03

ATTACHED BTS(S) TO PSE:

PCU ID-00 BCSU-00 PCU-03

BTS NAME

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

018

PCU service terminal commands (PCU1 only):. clog -s -a

. exit (Logout from the PCU service terminal)



PCU service terminal commands (PCU2 only):. cat log_file.txt. exit (Logout from the PCU service terminal)

. BTS information under investigation:

ZEEI;

ZEEI:SEG=ALL;

ZERO:BTS=<index>;

ZERO:SEG=<SEG_ID>;

ZESI;

ZESI:ID=<DAP_ID>:TRXS;

ZEWO:<BCF_INDEX>;

ZWQO:CR;

ZAHO;

ZEOL;

ZEOH;

ZAHP:::<date,time>;

. Additional information:

SGSN manufacturer, SW and CD level

MS manufacturer, type and SW level

3.17.1 Instructions for Capturing Alarm 1178 or 2770 logs (PCU1)

The following instructions and additional traces are needed only if thealarms 1178 or 2770 have occurred. The official SW versions must be inuse and there cannot be any special configurations. With theseinstructions, you can investigate the root cause for the alarms 1178 and2770, which can have many different origins.

Example of the alarm printout on how to track correct BCSU and PCU,irrespective of the problem you should report the following:

DN991432Issue 9-1 en27/04/2009



Example

<HIST> BSC1 BCSU-3 SWITCH 2006-09-07 19:15:50.11

* DISTUR BCSU-3 1A004-00 PS0PRB

1178 PREPROCESSOR UNIT DISTURBANCE

PCU_B 3d 13851d 0143

<HIST> BSC1 BCSU-3 SWITCH 2006-09-08 19:24:00.06

* ALARM BCSU-3 1A003-00 PS0PRB *RECOV*

(0071) 2770 PREPROCESSOR UNIT FAILURE

PCU_B 3d 127d 0585

Alarm described above has occurred on BCSU 3 and PCU 3.

Following MML commands are needed:

ZFXO:BCSU=0&&8:BTS;

ZFUI;

ZAHP:YYYY-MM-DD; (where YYYY-MM-DD is date of fault)

ZEOH;

ZEEI;

ZESI;

ZDVL:BEG:CONT;

Try to establish service terminal connection via OMU with commands.

ZDDS

ZRS:3X,Y0BE (where X is BCSU index and Y is PCU index + 1).

So in this example (above), right command is: ZRS:33,40BE..

If the service terminal connection is established via OMU, give commandslisted in section Log instructions with service terminal connection.

If the service terminal connection cannot be established via OMU, givecommands listed in section Log instructions with serial cable connection toPCU.



3.17.1.1 Log instructions with service terminal connection

Black box logs

003X-$ dxfload -n CSXBBLOG -d -u 0 -o /bin/bblog.gz

003X-$ bblog -c -a 2








003X-$ bblog -c -a 10

003X-$ bblog -c -a 11

003X-$ bblog -c -a 12

003X-$ bblog -c -a 13

003X-$ bblog -c -a 14

003X-$ bblog -c -a 15

Sysdumps

003X-$ dxfload -n CSXSDUMP -d -u 0 -o /bin/sysdump.gz

003X-$ sysdump -l -r1




DN991432Issue 9-1 en27/04/2009








003X-$ sysdump -l –r10



If sysdump above show some exceptions then give this command forevery different PC and LR register values seen in printouts:

003X-$ sysdump -f XX

where XX is PC or LR registers value without 0x seen in sysdumps. Forexample with sysdump:

0030-$ sysdump -l -r6

ChorusOS system dump tool.

Printing logs from 6 resets ago

Find LR and PC register values from the sysdump printout, for example:

lr: fa5aa288

pc: fa5b3db4

In this example case, give following commands:

003X-$ sysdump -f fa5aa288

003X-$ sysdump -f fa5b3db4

If the following sysdump below shows some exceptions then give thiscommand for every different PC and LR register values seen in print outs:

003X-$ sysdump -f XX



0000000002 ts[1160775362 0630]: execBusError : faultCtx

00009f48 faultAddr f7b71007

pc f9d37a88

lr: 00817100

pc: 00817130

In this example case, give following commands:

003X-$ sysdump -f f9d37a88

003X-$ sysdump -f 00817100

003X-$ sysdump -f 00817130

Also following commands are needed:

003X-$ sysdump -A -r1











DN991432Issue 9-1 en27/04/2009




003X-$ alist

Give the tlist command three times

003X-$ tlist

003X-$ memstat –d

Next we need to use rgnlist command where the syntax is:

rgnlist <actor_id>

Give following rgnlist command from actor_id 15 to 60.

003X-$ rgnlist 15

003X-$ rgnlist 16

.

.

.

Etc. until

.

003X-$ rgnlist 59

003X-$ rgnlist 60

003X-$ dxfload -n CSXDMXSH -d -u 0 -o /bin/dmxshow.gz

003X-$ dmxshow -l



003X-$ dmxshow -m

003X-$ dmxshow -u

003X-$ dmxshow -s

003X-$ dmxshow –a

003X-$ dxfload -n CSXTOPXX -d -u 0 -o /bin/top.gz

003X-$ top –t

Run both top commands about 10 seconds before stopping with ctrl-c +enter or q button.

003X-$ sysdump -W

003X-$ rgndump –p –o ffe00200 –l 30

3.17.1.2 Log instructions with serial cable connection to PCU

1. When 1178 is seen usually there is no answer from PCU so we needto use kernel debugger from PCU. First set the RBAN flag to allBCSU’s. with RBAN flag, only user initiated recovery actions areperformed.

ZUST:BCSU,<bcsu id>:S-RBAN:;

2. If you are able to estimate, in which PCU the failure occurs, pleaseconnect a direct service terminal cable into the failing PCU. Cabletype is CPCU and it is connected directly behind the failing PCU-Bunit into connector position 2J. Then execute following commandsbefore the failure occurs and leave the printout on until the failurehappens:

003X-$ dxfload -n CSXTOPXX -d -u 0 -o /bin/top.gz

003X-$ top –t –p 20

3. Wait for the occurrence of the alarm 1178, (2770) or GPRS outage.This might take days.

4. When the alarm is active, check the BCSU where the alarm hasrisen as instructed beginning of document.

5. If service terminal connection fails take straight connection to non-answering PCU's serial port. It should not respond at all.

DN991432Issue 9-1 en27/04/2009



6. Try to change priority of console. First write 5 to console even youcan’t see anything. Then push ctrl button and keep it down and writeidefix. If prompt appears give tlist command several times, otherwisego to step 6. 003X-$ tlist

Note to read the next step carefully.

7. Keep the ctrl button down and write DEBUG . Press ctrl-A and whenthe kernel debuggers command line (kdbg[k]>) is shown, pressEnter button within 3 second.

8. Give following commands to the kernel debugger:

kdbg[K]>=

kdbg[K]>a

kdbg[K]>A

kdbg[K]>lv

kdbg[K]>ll 500

kdbg[K]>ls

kdbg[K]>l

kdbg[K]>la 1

kdbg[K]>la 2

Then give the la command from id 15 to 60

kdbg[K]>la 15

kdbg[K]>la 16

.

.

.

Etc. until

.

kdbg[K]>la 59

kdbg[K]>la 60

Give also the s command from id 8 to 140



kdbg[K]>s 8

kdbg[K]>s 9

.

.

.

Etc. until

.

kdbg[K]>s 139

kdbg[K]>s 140

Then free list information is printed out as follows:

kdbg[K]>g freelist_freecnt

kdbg[K]>g freelist_head

Both commands will print the following lines:

abator:freeList_freecnt xxxxxxxx

abator:freeList_Head zzzzzzzz

Use the printed hexadecimal number xxxxxxxx and zzzzzzzz in thenext command for both cases:

kdbg[K]> rl xxxxxxxx 4

kdbg[K]> rl zzzzzzzz 4

Following command is needed only for zzzzzzzz fromfreeList_Head.

kdbg[K]> rl yyyyyyyy 400,

Where yyyyyyy is hhhhhhhh – fa (must be calculated manually withcalculator) fa is 250d and hhhhhhhh is first hexadecimal number infreeList_Head printout. For example:

kdbg[K]> g freelist_freecnt

DN991432Issue 9-1 en27/04/2009



abator:freeList_freecnt f8274a58

kdbg[K]> rl f8274a58 4

f8274a58: 00000fa0 00001770 00000000 00000000 .......p........

kdbg[K]> g freelist_head

abator:freeList_Head f8274a50

kdbg[K]> rl f8274a50 4

f8274a50: f7b6f24c f7abb804 00000fa0 00001770 ...L...........p

f7b6f24c - fa = f7b6f152

kdbg[K]> rl f7b6f152 400

then give rest of commands:

kdbg[K]> g rlc_pool_memory

abator:rlc_pool_memory aaaaaaaaa

kdbg[K]> rl aaaaaaaa 7200

kdbg[K]> g tmr_que

abator:tmr_que bbbbbbbb

kdbg[K]> rl bbbbbbbb 5

kdbg[K]> g g_systimer

abator:g_systimer cccccccc



kdbg[K]> rl cccccccc 30

kdbg[K]> g rlc_timer_memory

abator:rlc_timer_memory dddddddd

kdbg[K]> rl dddddddd 25100

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

kdbg[K]>c

Ctrl-A

Note that in these last commands after every ctrl-A, c must be givenwithin three seconds.

DN991432Issue 9-1 en27/04/2009



9. After this, kernel debugger session can be stopped and manualBCSU switch-over or reset must be performed.

10. After switch-over or BCSU reset, collect sysdumps from the samePCU under the faulty BCSU according to instructions of in sectionLog instructions with service terminal connection.

3.17.2 Reporting problems with Abis

3.17.2.1 Collecting synchronisation logs (alarm 7725, PCU1)

If you suspect problems with Abis synchronisation or receive the alarm7725, follow these instructions to take necessary logs for further analysisof the problem.

First of all, locate a BTS site that suffers from this problem. While theproblem is active, continue as follows:

1. Collect information on the network configuration with the followingcommands:

ZAHO;

ZEOL:<BCF identification>;

ZAHP:ET,<index of the ET connected to the BTS site>;

ZYMO:ET,<index of the ET connected to the BTS site>;

ZEEI:BTS=<BTS identification>;

ZERO:BTS=<BTS identification>;

ZEQO:BTS=<BTS identification>:ALL;


ZFUI;

ZEWO:<number of BCF>;

2. Forward the PCU log writings from all PCUs of the BSC to the OMUdisk.

ZDVR:0:3300000;

ZDVM:CRI&ERR&TES&INF::BCSU,:PCU:;



3. Open a service terminal session to the PCU that handles theproblematic BTS.

ZDDS;

ZRS:30,50BE (syntax: ZRS:<30+BCSU_INDEX>,<PCU_INDEX+1>0BE)

4. Set the test log levels in the PCU service terminal.

LGLVST PFH 30

LGLVST DAM 2

5. At the same time, monitor the Abis master and slave channels aswell as TRXSIG with a GRPS/EDGE-capable Abis analyser.

6. Let the log levels stay on for 10 minutes, for example, so that enoughinformation is collected.

7. Initialise the log levels in the PCU service terminal.

LGLVST PFH 0

LGLVST DAM 0

8. Take a printout from the PCU log buffer in the PCU service terminal.

clog -s -a

ZE;

9. Exit the PCU service terminal.

exit

ZE;

10. Collect the PCU logs from the OMU disk.

ZDVL:BEG:CONT:::0:INC:;

ZDVM:CRI::BCSU,:PCU:;

3.17.2.2 Collecting EDAP configuration failure logs (PCU1)

If you suspect problems with the EDAP configuration or receive the alarm3068, do as follows to collect all the information required to solve theproblem:

DN991432Issue 9-1 en27/04/2009



1. Collect network configuration as instructed in 3.18 Reportingproblems with GPRS/EDGE and in step 1 of 3.18.2.1 Collectingsynchronisation logs (alarm 7725).


ZDVR:0:3300000;



ZDDS;


4. Set the test log levels in the PCU service terminal:

LGLVST DAM 3122

5. Print EDAP, DSP and PCM from the PCU in the problematic BTSwith the RENFST service terminal extension:

renfst -dam -edap

renfst -dam -dsp

renfst -dam -pcm

Repeat these commands with the “-log” option that redirects theoutput to the PCU log:

renfst -dam -edap -log

renfst -dam -dsp -log

renfst -dam -pcm -log

6. Let the log levels stay on for 10 minutes, for example, so that asufficient amount of information gets collected. During this period,especially PS territory upgrades/downgrades and/or DAPmodifications are desirable.


LGLVST DAM 0

8. Repeat step 5.


clog -s -a




exit

ZE;

11. Collect the PCU logs from the OMU disk and initialise log forwarding:



Simultaneously with the monitoring described above, you should alsomonitor MCMU and BCSU messages, collecting MCMU computer log andother necessary information as follows:

. RC0's DAP table printout for all known DAP IDs

ZOSD:*,A0,,,*,*,14F,,,,,6034,,,05,08,<DAP_ID_LOW_ORDBYTE>,<DAP_ID_HI_ORD BYTE>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,

. RC0's BCSU-specific table

ZOSD:*,A0,,,*,*,14F,,,,,6034,,,05,06,03,<BCSU_INDEX>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,

. RC0's internal connection table

ZOSD:*,A0,,,*,*,14F,,,,,6034,,,05,05,02,<BCSU_INDEX>,<PCU_INDEX>,<PCM_INDEX>,<TSL_INDEX>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,

. If the problem can be repeated, you can use message monitoring.

ZOEBF:<act_MCMU>

ZOEBR:<act_MCMU>


ZOEC:<act_MCMU>:SR:(NOT(NU-M=0001,0002,6981,6982,7816,7817,7535,9173,9175,9177,91-79,9181,9183,9185,9187,9188,9301,0C918,0C919))AND((OFAM=14F)OR(CFAM=14F))

DN991432Issue 9-1 en27/04/2009



These conditions monitor all RC0 messages except theunnecessary ones. Use a sufficiently large message buffer.

Start monitoring:

ZOEM:<act_MCMU>

At this point, reproduce the problem situation.

Stop monitoring:

ZOES:<act_MCMU>


ZOEG:<act_MCMU>

. MCMU computer logs

ZGSC;

. alarm history

ZAHP;

. active alarms

ZAHO;

. DAP connections

ZESI;

. circuit groups

ZRCI; (all circuit groups)

ZRCI:SEA=3:NCGR=<Dap cgr name>:PRINT=5; (DAP circuitgroups)

. plug-in unit information

ZWTI:P;

. computer state

ZUSI;

. RC0 version information

ZSXP:RC0



3.17.2.3 Collecting synchronisation logs (alarm 7725, PCU2)

If you suspect problems with Abis synchronisation or receive the alarm7725, follow these instructions to take necessary logs for further analysisof the problem.

First of all, locate a BTS site that suffers from this problem. While theproblem is active, continue as follows:

1. Collect information on the network configuration with the followingcommands:

ZAHO;

ZEOL:<BCF identification>;

ZAHP:ET,<index of the ET connected to the BTS site>;

ZYMO:ET,<index of the ET connected to the BTS site>;





ZFUI;

ZEWO:<number of BCF>;


ZDVR:0:3300000;



ZDDS;


4. Set the required log levels in the PCU2 service terminal with thefollowing commands:

DN991432Issue 9-1 en27/04/2009



sll dsp:<dsp_id> 6:11

sll dsp:<dsp_id> :33 1:6:11

You can check the correct DSP ID with the following command:

dsegrnw <seg_id>

Make sure that logging to file is activated:

efl

5. At the same time, monitor the Abis master and slave channels aswell as TRXSIG with a GRPS/EDGE-capable Abis analyser.

6. Let the log levels stay on for 10 minutes, for example, so that enoughinformation is collected.

7. Initialise the log levels in the PCU2 service terminal.

sll dsp:<dsp_id> 11

sll dsp:<dsp_id> :33 11

8. Take a printout from the PCU2 log buffer in the PCU2 serviceterminal.

cat log_file.txt


exit

ZE;

10. Collect the PCU logs from the OMU disk.



3.17.2.4 Collecting EDAP configuration failure logs (PCU2)

If you suspect problems with EDAP configuration and/or receive the alarm3068, do as follows to collect all the information required to solve theproblem:



1. Collect network configuration as instructed in 3.18 Reportingproblems with GPRS/EDGE and in step 1 of 3.18.2.3 Collectingsynchronisation logs (alarm 7725).


ZDVR:0:3300000;



ZDDS;


4. Set the test log levels in the PCU2 service terminal:

sll pq2:15 1:2:6:11

sll pq2:16 1:2:6:11


efl

5. Print EDAP, DSP and PCM from the PCU in the problematic BTSwith the following commands:

ddapinfo

dabmtrxinfo <seg_id> <bts_id>

ddaptrxinfo <dap_id>

dpcminfo


7. Initialise the log levels in the PCU2 service terminal:

sll pq2:15 11

sll pq2:16 11

8. Repeat step 5.

9. Take a printout from the PCU2 log buffer in the PCU2 serviceterminal.

DN991432Issue 9-1 en27/04/2009



cat log_file.txt


exit

ZE;




Simultaneously with the monitoring described above, you should alsomonitor MCMU and BCSU messages, collecting MCMU computer log andother necessary information as follows.

. RC0's DAP table printout for all known DAP IDs

ZOSD:*,A0,,,*,*,14F,,,,,6034,,,05,08,<DAP_ID_LOW_ORDBYTE>,<DAP_ID_HI_ORD BYTE>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,

. RC0's BCSU-specific table

ZOSD:*,A0,,,*,*,14F,,,,,6034,,,05,06,03,<BCSU_INDEX>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,

. RC0's internal connection table

ZOSD:*,A0,,,*,*,14F,,,,,6034,,,05,05,02,<BCSU_INDEX>,<PCU_INDEX>,<PCM_INDEX>,<TSL_INDEX>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,

. If the problem can be repeated, you can use message monitoring.

ZOEBF:<act_MCMU>

ZOEBR:<act_MCMU>




ZOEC:<act_MCMU>:SR:(NOT(NU-M=0001,0002,6981,6982,7816,7817,7535,9173,9175,9177,91-79,9181,9183,9185,9187,9188,9301,0C918,0C919))AND((OFAM=14F)OR(CFAM=14F))

These conditions monitor all RC0 messages except theunnecessary ones. Use a sufficiently large message buffer.

Start monitoring:

ZOEM:<act_MCMU>

At this point, reproduce the problem situation.

Stop monitoring:

ZOES:<act_MCMU>


ZOEG:<act_MCMU>

. MCMU computer logs

ZGSC;

. alarm history

ZAHP;

. active alarms

ZAHO;

. DAP connections

ZESI;

. circuit groups

ZRCI; (all circuit groups)

ZRCI:SEA=3:NCGR=<Dap cgr name>:PRINT=5; (DAP circuitgroups)

. plug-in unit information

ZWTI:P;

. computer state

ZUSI;

. RC0 version information

DN991432Issue 9-1 en27/04/2009



ZSXP:RC0

3.17.3 Reporting problems with Gb interface (PCU1)

When encountering problems that are related to the Gb interface (PCU1),you should collect the following information:


ZWQO:CR;


. PCU software version GBHTORSX.IMG in use with the MMLcommand:

ZDPY:BCSU,<BCSU_index>:PCU,<PCU_index>:PID,GBH;



ZFUI;




ZFXI:NSEI=<NSEI_index>;




ZQRI:BCSU;


ZEBP;

. active alarms in BSC with the commands:

ZAHO;



ZEOL;


ZAHP:<date,time>;

. Gb interface monitoring with a network analyser takensimultaneously with the PCU logs when the fault occurs

. PCU log writings from the faulty BCSU:

From OMU service terminal (ZDDS;), go to the service terminal ofPCU with the command:


or


Check the correct PCU terminal index from the Frame Relayconfiguration printout ZFUI;.



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

0 SGSN1 128 41 1- 2 BCSU-7 4 0

Gb over IP:

ZFXL:PSEI=<PSEI_index>:ALL;


PSE-01

======


NSEI

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

02000


PCU BCSU PCU

ID INDEX INDEX

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

00 00 03



DN991432Issue 9-1 en27/04/2009



BTS NAME

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

018

PCU service terminal commands:. LGLVST GBH 128. clog -s -a. exit (Logout from the PCU service terminal)

. Additional information:

SGSN manufacturer, SW and CD level

3.17.4 Reporting problems with Gb interface (PCU2)

When encountering problems that are related to Gb interface (PCU2), youshould collect the following information:


ZWQO:CR;




ZFUI;




ZFXI:NSEI=<NSEI_index>;






ZQRI:BCSU;


ZEBP;

. active alarms in the BSC with the commands:

ZAHO;

ZEOL;


ZAHP:<date,time>;

. Gb interface monitoring with a network analyser takensimultaneously with the PCU logs when the fault occurs

. PCU log writings from the faulty BCSU:

From OMU service terminal (ZDDS;), go to the service terminal ofPCU with the command:


or


Check the correct PCU terminal index from the Frame Relayconfiguration printout ZFUI;.



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

0 SGSN1 128 41 1- 2 BCSU-7 4 0

Gb over IP:

ZFXL:PSEI=<PSEI_index>:ALL;


PSE-01

======


NSEI

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

02000


PCU BCSU PCU

DN991432Issue 9-1 en27/04/2009



ID INDEX INDEX

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

00 00 03



BTS NAME

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

018

PCU2 service terminal commands:. Print out Gb configuration:

dgb. Frame Relay: print out Frame Relay configuration:

dfc. Gb over IP: display the information about a certain BVC:

dgbipbvc <bvci>. Gb over IP: display the information about a certain NSE:

dgbipnsei <bvci> <nsei>. Gb over IP: display the information about a certain NSVC:

dgbipnsvc <nsvci>. Set the required log levels:

sll pq2:21 1:2:3:4:5:6:11

sll pq2:22 1:2:3:4:5:6:11

sll pq2:24 1:2:3:4:5:6:11. Make sure that logging to file is activated:

efl. Repeat the fault situation.. Initialise log levels:

sll pq2:21 11

sll pq2:22 11

sll pq2:24 11. Take a printout from the PCU2 log buffer in the PCU2 service

terminal:

cat log_file.txt. Log out from the PCU2 service terminal:

exit

ZE;

. Collect the PCU logs from the OMU disk:





3.17.4.1 Reporting problems with Gb over IP (PCU2)

When encountering problems that are related to Gb over IP (PCU2), seesection 3.18.3 Reporting problems with Gb interface (PCU1) forinformation on how to collect the required logs.

PCU2-specific service terminal commands are the following:

. Gb configuration:

dgb

. Display the information about certain BVC:

dgbipbvc

. Display the information about certain NSE:

dgbipnsei

. Display the information about certain NSVC:

dgbipnsvc

. sll pq2:21 1:2:3:4:5:6:11

sll pq2:22 1:2:3:4:5:6:11

sll pq2:24 1:2:3:4:5:6:11

. Enable System Dump:

esd

. Repeat the fault situation.

. Log out from the PCU2 service terminal:

exit

DN991432Issue 9-1 en27/04/2009



3.17.5 Reporting problems with a sleeping cell (PCU1)

Problems with a sleeping GPRS/EDGE cell are usually caused by Abissynchronisation problems that affect GPRS/EDGE traffic but are minorenough not to trigger the 7725 alarm. In all suspected sleeping cell cases,try to find out why the cell is sleeping by considering how the problem wasnoticed. It could also be useful to try to verify the sleeping cell case bydoing a data transfer test in the affected cells.

A sleeping cell can also trigger the alarm 7789 NO (E)GPRSTRANSACTIONS IN BTS, but only if the alarm monitoring is properlyconfigured. Check whether this alarm is active when investigating asleeping cell.

If the reason for a sleeping cell cannot be traced to any other problem,continue by taking the logs as instructed below. Note that the logs are quitegeneral and help to pinpoint the possible cause of the problem, but thatNokia may need more logs to solve the problem.

1. Collect information on the network configuration:




ZEQO:SEG=<SEG identification>:ALL;

ZEFO:<BCF identification>;

2. Forward the PCU log writings from all PCUs of the BSC to the OMUdisk:

ZDVR:0:3300000;


3. Open a service terminal session to the PCU that handles theproblematic BTS:

ZDDS;


4. Take a printout from the PCU log buffer in the PCU service terminal:

clog -s -a




LGLVST MAC 0x102

LGLVST RLC 1

LGLVST PFH 30

6. Let the log levels stay on for about 10 minutes.

7. Initialise the log levels in the PCU service terminal:

LGLVST MAC 0

LGLVST RLC 0

LGLVST PFH 0

8. Take another printout from the PCU log buffer in the PCU serviceterminal. This printout should contain the logs printed by the loglevels.

clog -s -a


exit

ZE;




3.17.6 Reporting problems with a sleeping cell (PCU2)

Problems with a sleeping GPRS/EDGE cell are usually caused by Abissynchronisation problems that affect GPRS/EDGE traffic but are minorenough not to trigger the 7725 alarm. In all suspected sleeping cell cases,try to find out why the cell is sleeping by considering how the problem wasnoticed. It could also be useful to try to verify the sleeping cell case bydoing a data transfer test in the affected cells.

A sleeping cell can also trigger the alarm 7789 NO (E)GPRSTRANSACTIONS IN BTS, but only if alarm monitoring is properlyconfigured. Check whether this alarm is active when investigating asleeping cell.

DN991432Issue 9-1 en27/04/2009



If the reason for a sleeping cell cannot be traced to any other problem,continue by taking the logs as instructed below. Note that the logs are quitegeneral and help to pinpoint the possible cause of the problem, but thatNokia may need more logs may to solve the problem.

1. Collect information on the network configuration:




ZEQO:SEG=<SEG identification>:ALL;

ZEFO:<BCF identification>;


ZDVR:0:3300000;


3. Open a service terminal session to the PCU2 that handles theproblematic BTS:

ZDDS;


4. Print out segment info with PCU2 service terminal command:

dsegtbf <seg_id>

5. Take a printout from the PCU2 log buffer in the PCU2 serviceterminal:

cat log_file.txt

6. Make sure that logging to file is activated:

efl


sll pq2:16 1:2:6:11

8. Let the log levels stay on for about 10 minutes.




sll pq2:16 11

10. Take another printout from the PCU log buffer in the PCU2 serviceterminal. This printout should contain the logs printed by the loglevels.

cat log_file.txt

11. Exit the PCU2 service terminal.

exit

ZE;




3.17.7 Reporting problems with performance (PCU1)

When encountering problems that are related to PCU1 performance andthroughput, you should collect the following information:

1. Collect information on the problematic BTS:





ZDVR:0:3300000;



ZDDS;



DN991432Issue 9-1 en27/04/2009



clog -s -a


LGLVST PS 1

LGLVST CHA 2

LGLVST MAC 0x102

LGLVST PFH 30

6. Let the log level stay on for about 10 minutes.


LGLVST PS 0

LGLVST CHA 0

LGLVST MAC 0

LGLVST PFH 0


clog -s -a

9. Exit the PCU service terminal:

exit

ZE;




3.17.8 Reporting problems with performance (PCU2)

When encountering problems that are related to PCU2 performance andthroughput, you should collect the following information:








ZDVR:0:3300000;



ZDDS;


4. Execute the following PCU2 service terminal command:

dpcutbf


sll pq2:16 6:11

sll pq2:24 6:11

6. Let the log level stay on for about 10 minutes.


sll pq2:16 11

sll pq2:24 11

8. Take a printout from the PCU2 log buffer in the PCU2 serviceterminal. This printout should contain the logs printed by the loglevels.

cat log_file.txt


exit

ZE;




DN991432Issue 9-1 en27/04/2009



11. Deliver also BSC counter files to measure data throughput with theabove mentioned logs.

3.17.9 Collecting alarm 3068 and 3273 logs

PCU1

In case of alarm 3068 EGPRS DYNAMIC ABIS POOL FAILURE, see3.18.2.2 Collecting EDAP configuration failure logs.

In case of alarm 3273 (E)GPRS TERRITORY FAILURE, see 3.18.12Reporting problems with GPRS/EDGE territory failures (PCU1).

PCU2

In case of alarm 3068 EGPRS DYNAMIC ABIS POOL FAILURE or 3273(E)GPRS TERRITORY FAILURE, you should collect the followinginformation:

. information on all segments and DAPs of the BSC:

ZERO;

ZEQO;

ZEEI;

ZESI;

. output of the following PCU2 service terminal commands:

ddapinfo

ddspinfo

dsegrnw (at least for the failed territory)

dabmtrxinfo <seg_id>

ddaptrxinfo <edap_id>

. if the problem is related to packet-switched territory handling (suchas upgrade or downgrade) or EDAP handling, the PCU2 logs withthe following levels:

sll pq2:20 1:2:6:11



sll pq2:17 1:2:6:11

sll pq2:15 1:2:6:11

sll pq2:16 1:2:6:11

. execute MCMU & BCSU monitoring with the following commands:

ZOEQ

ZOEBR::FFFFF

ZOEC::SR:CFAM=5434,5435,5436,5663

ZOEM

ZOES

ZOEG

Note that the BSC commands must be executed at the relevantBCSU and MCMU. Note also that the first digit 5 in the ZOECcommand may need to be replaced by 4 depending on the sectionID used within the PCU2 plug-in unit.

. ERROR logs from the DSP to check whether there is a failure in theDSP channel connection

sll dsp:<dsp_id> 6:11

3.17.10 Reporting problems with NCCR cell changes (PCU1)

When encountering problems that are related to high NCCR failure rateswith PCU1, you should collect the following information:

1. Collect general network configuration logs as instructed in 3.18Reporting problems with GPRS/EDGE.


ZDVR:0:3300000;



ZDDS;

DN991432Issue 9-1 en27/04/2009





clog -s -a


LGLVST CEK 0x48

LGLVST MAC 0x102

6. Let the log level stay on for about 10 minutes or until you are surethat NCCR failures have happened.


LGLVST CEK 0

LGLVST MAC 0


clog -s -a


exit

ZE;




3.17.11 Reporting problems with NCCR cell changes (PCU2)

When encountering problems that are related to NCCR cell changes withPCU2, you should collect the following information:








ZDVR:0:3300000;



ZDDS;



sll pq2:16 1: 6:11

sll pq2:18 1: 6:11

5. Let the log level stay on over a problematic cell re-selection on thePCUs handling the source and target cell.


sll pq2:16 11

sll pq2:28 11

7. Take a printout from the PCU2 log buffer in the PCU2 serviceterminal. This printout should contain the logs printed by the loglevels.

cat log_file.txt


exit

ZE;




10. Deliver also BSC counter files to measure data throughput with theabove-mentioned logs.

DN991432Issue 9-1 en27/04/2009



3.17.12 Reporting problems with GPRS/EDGE territory failures (PCU1)

If you suspect problems with GPRS or GPRS/EDGE territories or receivethe alarm 3273 with PCU1, do as follows to collect all the informationrequired to solve the problem:

1. Collect the network configuration as instructed in 3.18 Reportingproblems with GPRS/EDGE and in step 1 of 3.18.2.1 Collectingsynchronisation logs (alarm 7725).


ZDVR:0:3300000;



ZDDS;



LGLVST PS 1

LGLVST DAM 3122


renfst -dam -edap

renfst -dam -dsp

renfst -dam -pcm

renfst -dam -trx -s <seg_id> -b <bts_id> (for the BTSs with thealarm 3273)

Repeat these commands with the “-log” option that redirects theoutput to the PCU log:

renfst -dam -edap -log

renfst -dam -dsp -log

renfst -dam -pcm -log

renfst -dam -trx -s <seg_id> -b <bts_id> -log (for the BTSswith the alarm 3273)





LGLVST PS 0

LGLVST DAM 0

8. Repeat step 5.


clog -s -a


exit

ZE;





1. Take the Radio Resource Monitoring service terminal extension inuse in the working MCMU.

ZLE:<char>,E00_BXSX


2. Clear the computer logs in the working MCMU.

ZGC;

3. Set message monitoring in the working MCMU. Increase the buffersize.

ZOEQ

ZOEBR::50000 (buffer size 320 kb)

DN991432Issue 9-1 en27/04/2009



ZOEC::SR:NUM=09608,09609,09610,09854,09855,09856,0E4FB,0E4FA,0-E4F9,0E4F8,0E4F7,0E4F6,09605,09606,0960,09607

ZOEM

4. Repeat the problem situation.

5. Print and save message monitoring from the buffer.

ZOES

ZOEG

6. Print out logs from the working MCMU.

ZGSC;

7. Print out the real-time BTS/TRX/PCU list specific data with the RadioResource Monitoring service terminal extension in the workingMCMU.

Z<char>A:1,<bts_id>,FF; (Bts_status_file)

Z<char>A:B,<bts_id>,FF; (Bts_status_file2)

Z<char>D:1,<bts_id>,<trx_id>,FF,FF; (TCH state file)

Z<char>T:<bts_id>,<trx_id>; (TRX state, this printout should betaken from every TRX under the BTS)

Z<char>A:6,1,0; (PCU list printout)

8. Print out the BSC-specific data from the RRM with the RadioResource Monitoring service terminal extension in the workingMCMU.

ZNA:6;

9. Print out network configuration information.

ZEEI:SEG=<seg_id>;

ZEQO:BTS=<bts_id>:ALL;

ZEQO:SEG=<seg_id>:ALL;


ZERO:BTS=<bts_id>;

ZFXO:BCSU=0&&9:BTS;

ZEEO:ALL;

ZEGO:ALL;



ZEHO:BTS=<bts_id>;

3.17.13 Reporting problems with GPRS/EDGE territory failures (PCU2)

If you suspect problems with GPRS or GPRS/EDGE territories or receivethe alarm 3273 with PCU2, do as follows to collect all the informationrequired to solve the problem:

1. Collect the network configuration as instructed in 3.18 Reportingproblems with GPRS/EDGE and in step 1 of 3.18.2.1 Collectingsynchronisation logs (alarm 7725).


ZDVR:0:3300000;



ZDDS;



sll pq2:20 1:6:11

sll pq2:17 1:6:11

sll pq2:15 1:6:11

sll pq2:16 1:6:11


efl


ddapinfo

dpcminfo

ddspinfo

DN991432Issue 9-1 en27/04/2009




7. Initialise the log levels in the PCU2 service terminal.

sll pq2:20 11

sll pq2:17 11

sll pq2:15 11

sll pq2:16 11

8. Repeat step 5.


cat log_file.txt


exit

ZE;





1. Take the Radio Resource Monitoring service terminal extension inuse in the working MCMU.

ZLE:<char>,E00_BXSX


2. Clear the computer logs in the working MCMU.

ZGC;

3. Set message monitoring in the working MCMU. Increase the buffersize.

ZOEQ



ZOEBR::50000 (buffer size 320 kb)

ZOEC::SR:NUM=09608,09609,09610,09854,09855,09856,0E4FB,0E4FA,0-E4F9,0E4F8,0E4F7,0E4F6,09605,09606,0960,09607

ZOEM

4. Repeat the problem situation.

5. Print and save message monitoring from the buffer.

ZOES

ZOEG

6. Print out logs from the working MCMU.

ZGSC;

7. Print out the real-time BTS/TRX/PCU list specific data with the RadioResource Monitoring service terminal extension in the workingMCMU.

Z<char>A:1,<bts_id>,FF; (Bts_status_file)

Z<char>A:B,<bts_id>,FF; (Bts_status_file2)

Z<char>D:1,<bts_id>,<trx_id>,FF,FF; (TCH state file)

Z<char>T:<bts_id>,<trx_id>; (TRX state, this printout should betaken from every TRX under the BTS)

Z<char>A:6,1,0; (PCU list printout)

8. Print out the BSC-specific data from the RRM with the RadioResource Monitoring service terminal extension in the workingMCMU.

ZNA:6;

9. Print out network configuration information.

ZEEI:SEG=<seg_id>;

ZEQO:BTS=<bts_id>:ALL;

ZEQO:SEG=<seg_id>:ALL;


ZERO:BTS=<bts_id>;

ZFXO:BCSU=0&&9:BTS;

ZEEO:ALL;

DN991432Issue 9-1 en27/04/2009



ZEGO:ALL;

ZEHO:BTS=<bts_id>;

3.18 Reporting problems with SMSCB

When encountering problems related to the SMSCB, you should collectthe following information:

. printout of the alarm history with the command:

ZAHP:::YYYY-MM-DD;

where

YYYY = year, MM = month, DD = one day before the problem started

. printout of log writings from OMU and MCMU units with thecommands:


ZDDE:<computer unit>,<unit index>:"ZSLP";


. printout of the CB-related files CBFILE, CBAFIL, and CBNFIL withthe commands:

ZDFD:<unit_type,unit_index>:704;

ZDFD:<unit_type,unit_index>:705;

ZDFD:<unit_type,unit_index>:8CE;

3.18.1 Reporting problems with SMSCB MML interface

When encountering problems related to the MML interface, you shouldcollect the following information:



. printout of all given MML commands, especially commands from theEC command group. Too much information is better than notenough. Version number of the CBBHAN.MML is needed. Use thefollowing MML command:

ZDDE:OMU:"ZL:M","ZLP:M,MAS","ZMXP:W0-MMDIRE/CBB*:*";

. printout of the existing CB messages in BSC with the MMLcommand:

ZECP;

. If the problem can be repeated, the message monitoring is needed.


Reserve buffer:

ZOEBR::3FFFFF


ZOEC::SR:((OFAM=1EB)OR(CFAM=1EB))

Start monitoring:

ZOEM:

At this point, reproduce the fault.

Stop monitoring:

ZOES:


ZOEG:


ZOEQ:

3.18.2 Reporting problems with CBC interface

When encountering problems related to the CBC interface, you shouldcollect the following information:

DN991432Issue 9-1 en27/04/2009



. printout of existing CB messages in BSC with the command:

ZECP;

. If the problem can be repeated, the message monitoring is needed.


Reserve buffer:

ZOEBR::3FFFFF


ZOEC::SR:((OFAM=38C)OR(CFAM=38C))

Start monitoring:

ZOEM:


Stop monitoring:

ZOES:


ZOEG:


ZOEQ:

3.19 Reporting problems with A interface signalling

When encountering problems related to the A interface signalling, youshould collect the following information:

. printout of alarm history with the command:

ZAHP:::YYYY-MM-DD;

where

YYYY = year, MM = month, DD = day, two days before the problemstarted



. information from every BCSU unit with the service terminalcommands in the BCSU



ZNET;

ZNHI;

ZOBI;

ZOBL;

ZNFI;

3.20 Reporting problems with Abis interface signalling

When encountering problems related to the Abis interface signalling, youshould collect the following information:

. the signalling monitoring from the Abis interface

. alarms starting from two days before the failure situation. Use thefollowing command:

ZAHP:::YYYY-MM-DD,;

. information from both MCMUs and all BCSUs



. printouts of Abis interface configuration with the commands:

ZEEL;

ZEEI;

ZEEI::BCSU;

ZEOH;

ZDTI;

ZDSB;

ZERO:<accused BCF>

DN991432Issue 9-1 en27/04/2009



3.21 Reporting problems with Q3 interface

When encountering problems related to the operations performed withNetAct applications via the Q3 interface, you should collect the followinginformation:

. If the problem can be repeated, use message monitoring. Give thefollowing service terminal commands in the OMU:

Reserve buffer:

ZOEBR::3FFFFF


ZOEC::SR:(OFAM=21F)AND(NOT(NUM=8374));

Start monitoring:

ZOEM


Stop monitoring:

ZOES


ZOEG


ZOEQ

. If an operation fails, there is usually information in an error log in theOMU. Use the following command:

ZGSC;

When object creation/modification events are not generated from the Q3-interface and the problem can be repeated, use EHBACK monitoring tocollect the required information:



. Open a service terminal session to the OMU before running the taskfrom NetAct:

ZDDS;

. Start EHBACK monitoring:

ZOQ:1F7,FFFF,FF,FFFF

. Run the test and interrupt monitoring by pressingctrl-c .

. Get the OMU log output:

ZGSC;

. Exit the service terminal session:

ZE;

3.22 Reporting problems with BSS Radio NetworkRecovery

When encountering problems related to BSS Radio Network Recovery,you should collect the following information:

. alarms starting from four hours before the failure situation. Use thefollowing command:

ZAHO;

ZABO;

ZAHP:::<date,time>;

. configuration information of the problematic BTS. Use the followingcommands:

ZEQO:BTS=<BTS identifier>:ALL;

ZEAO:BTS=<BTS identifier>;

ZEUO:BTS=<BTS identifier>;

ZEGO:ALL;

ZEEI;

DN991432Issue 9-1 en27/04/2009



ZEEO;

. information from both MCMUs and all BCSUs



. if the problem can be repeated (it is related to locking, unlocking, orresetting the BTS), the monitorings of the program blocks GUPDAT(id. 1B5) and BTLARM (id. 01CD) are needed.

Check which unit is working (0 or 1):

ZUSI:MCMU;

If the MCMU-0 was in WO-EX state, the message bus index of theactive MCMU is 04. If the MCMU-1 was in WO-EX state, themessage bus index of the active MCMU is 05.


Reserve buffer:

ZOEBR:<message bus index of the active BCSU>:3FFFFF


ZOEC:<message bus index of the active BCSU>:SR:((OFAM=1B3)OR(CFAM=1B3))

Start monitoring:

ZOEM:<message bus index of the active BCSU>


Stop monitoring:

ZOES:<message bus index of the active BCSU>


ZOEG:<message bus index of the active BCSU>


ZOEQ:<message bus index of the active BCSU>



3.23 Reporting problems with BSS Radio NetworkConfiguration Database (BSDATA) integrity

When encountering problems with BSS Radio Network ConfigurationDatabase (BSDATA) integrity, you should collect the following information:

. the results of integrity checkings

. computer logs of the OMU and MCMUs with the following command:

ZDDE:<computer unit>:<unit index>:”ZGSC”;

. a copy of the BSDATA database files from LFILES (the filesBSD001MX ... BSD077MX). Note that the size of the BSDATA files isalmost 20 MB. For more instructions on copying files, seeSafecopying in BSC.

3.24 Reporting problems with licensing

When encountering problems with licensing, you should collect thefollowing information:

. MML command outputs

ZW7I:LIC,FULL;

ZW7I:FEA,FULL:FSTATE=<state:ON,CONF,OFF>;

. MCMU computer log outputs

ZDDE:MCMU,<active/spare>:"ZGDC;";

ZDDE:MCMU,<active/spare>:"ZGSC;";

If you encounter problems with licence installation, you should collect thefollowing information:

. Licence file (.xml) that is used in installation

. Original mail from Licence Generator with the licence file attachment

. Display Licence database files

ZDFD:MCMU,0:B700001,,N;

DN991432Issue 9-1 en27/04/2009




Or attach licence database files LIK001GX.IMG, LIK002GX.IMG andLIK003GX.IMG from the LFILES directory of the active SW packagefrom the Winchester disk.

. MML command outputs of the failing commands

If you suspect that licence database is corrupted, you should collect thefollowing information:

. Display Licence database files



Or attach licence database files LIK001GX.IMG, LIK002GX.IMG andLIK003GX.IMG from the LFILES directory of the active softwarepackage from the Winchester disk.

. MML command outputs of the failing commands

3.25 Reporting problems with location-based services

If the location estimates with the cell-based method are incorrect or if E911positioning fails, you should collect the following information:

1. Check which MCMU unit is in the WO-EX state and open a remotesession:

ZUSI:MCMU;

ZDDS:MCMU:<wo-ex MCMU>;

2. Reserve a buffer:

ZOEBR:4:14000,1

3. Give the monitoring conditions:

ZOEC:4:SAR:NUM=0D70A,0D70B,0D6FD,0D6FE,0D6FF,0D38F,0CDF1,0D6FC,0-D6FB,06981,06982,01CA7



4. Start the monitoring:

ZOEM:4;

5. Stop the monitoring:

ZOES:4;

6. Print the monitoring results on the display:

ZOEG:4;

Furthermore, in case of problems with E911 positioning, you can use theTCPDUMP program to obtain samples from the Lb interface while makingemergency calls:

1. Check which MCMU unit is in the WO-EX state and open a remotesession:

ZUSI:MCMU;

ZDDS:MCMU:<wo-ex MCMU>

2. Load the TCPDUMP program and start it:

ZLE:1,DPDUMPGX

1

3. Make emergency calls and take samples. Note that the MCMU cancrash if samples are taken for more than a few minutes at a time.

X:::::EL0;

4. Stop taking samples with ctrl-c.

5. Copy the output on the display into a text file and save it.

6. Use the dpdump2ethereal to convert the file and view it with Etherealanalyser software.

3.26 Reporting problems with IP transport

When you suspect a problem with IP transport, do as follows to collect allinformation required to solve the problem.

DN991432Issue 9-1 en27/04/2009



. Printout of LAN switch supervision

ZYFF;

. Printout of LAN switch status

ZUSI:SWU;

ZUSI:CNW;

. Printout of alarm history

ZAHO;

. Printout of network interface data (IP address)

ZQRI;

. Printout of active internet connections

ZQRS:<unit>,<index>:<unit>,<index>;

. Printout of route data (gateway IP address)

ZQKB;

ZQKO;

. Printout of host reachability test

ZQRX:<unit>,<index>:<unit>,<index>:IP=<remote hostip address>:;

ZQRX:<unit>,<index>:<unit>,<index>:IP=<gateway ipaddress>:;

. Printout of each site router data. Open a Telnet session or local CLIconnection (serial cable) to the site router and give the followingcommands:

enable

show version

show running-config

show interfaces

show vlan

show spanning-tree mst (or other used spanning-tree)

. Printout of each SWU data. Open a Telnet session (ZW6T:SWU,<index>:) or local CLI connection (serial cable) to the SWU and givethe following commands:



enable

show version

show running-config

show interface

show vlan

show mstp (or other used spanning-tree)

3.27 Reporting problems with LAN Device Integration

When you suspect a problem with LAN Device Integration, do as follows tocollect all information required to solve the problem.

. Printouts of LAN switch supervision

ZYFF;

ZYFE:ALL;

ZYFE:IFL;

. Printout of LAN switch supervision Event Log

ZYFL;

. Printout of LAN switch management

ZWYI:L;

ZWYI:U;

. Printout of LAN switch status

ZUSI:SWU;

ZUSI:CNW;

. Printout of alarm history

ZAHO;

. Printout of network interface data (IP address)

ZQRI;

DN991432Issue 9-1 en27/04/2009



. Printout of active internet connections

ZQRS:MCMU,0;

ZQRS:MCMU,1;

. Printout of each site router data. Open a Telnet session or local CLIconnection (serial cable) to the site router and give the followingcommands.

enable

show version

show running-config

show interfaces

show vlan

show spanning-tree mst (or other used spanning-tree)

. Printout of each SWU data. Open a Telnet session (ZW6T:SWU,<index>:) or local CLI connection (serial cable) to the SWU and givethe following commands.

enable

show version

show running-config

show interface

show vlan

show mstp (or other used spanning-tree)



bsc problem reporting dn991432 9-1[1]

Documents

lan device

ps territory

local cli

rcs program

service terminal

service terminal

internal connection

data transfer